From owner-freebsd-bugs@freebsd.org Tue Oct 29 01:43:11 2019 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5333A1640BA for ; Tue, 29 Oct 2019 01:43:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 472Dqz1bVkz3Hrt for ; Tue, 29 Oct 2019 01:43:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 36B2C1640B8; Tue, 29 Oct 2019 01:43:11 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 367031640B7 for ; Tue, 29 Oct 2019 01:43:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 472Dqz0hkqz3Hrs for ; Tue, 29 Oct 2019 01:43:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D62D61A86F for ; Tue, 29 Oct 2019 01:43:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x9T1hAV6079839 for ; Tue, 29 Oct 2019 01:43:10 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x9T1hAI5079835 for bugs@FreeBSD.org; Tue, 29 Oct 2019 01:43:10 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 241559] cat(1) endless loop when writing to special device file Date: Tue, 29 Oct 2019 01:43:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 12.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sigsys@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 01:43:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241559 Bug ID: 241559 Summary: cat(1) endless loop when writing to special device file Product: Base System Version: 12.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: sigsys@gmail.com Using cat to write to a disk directly loops forever when it reaches the end= of the disk and there's still data to write (like when using /dev/zero or /dev/random for example). write() returns 0 (without setting errno) when t= hat happens (one of the very rare cases where that can happen it seems) and cat handles this by retrying the write forever. It would be better to error ou= t in this case AFAIK. There must be tons of programs that react very poorly when making them write to a device file directly like that, but one might expect that cat always work (more or less). $ mdconfig -s 1m -u 10 $ cat /dev/zero > /dev/md10 # loops forever cp seems to handle it better: $ cp /dev/zero /dev/md10 cp: /dev/md10: No error: 0 Which isn't a very good error message but still better since it doesn't loop forever. With this change: Index: bin/cat/cat.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- bin/cat/cat.c (revision 354128) +++ bin/cat/cat.c (working copy) @@ -327,7 +327,7 @@ } while ((nr =3D read(rfd, buf, bsize)) > 0) for (off =3D 0; nr; nr -=3D nw, off +=3D nw) - if ((nw =3D write(wfd, buf + off, (size_t)nr)) < 0) + if ((nw =3D write(wfd, buf + off, (size_t)nr)) <=3D= 0) err(1, "stdout"); if (nr < 0) { warn("%s", filename); It errors out like cp instead: $ cat /dev/zero > /dev/md10 cat: stdout: No error: 0 That's when cat is in "raw mode". In "cooked mode", it already errors out,= but it picks up a bogus errno for it: $ cat -v /dev/zero > /dev/md10 cat: stdout: Inappropriate ioctl for device Which comes from an isatty() call in stdio. errno should be saved at some point, dunno if it should be done by cat or stdio (before its call to isatt= y() in __smakebuf()). Not very important though I guess. --=20 You are receiving this mail because: You are the assignee for the bug.=