linux-kernel - Re: [RFC PATCH 08/14] pipe: Allow buffers to be marked read-whole-or-error for notifications [ver #2]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4649.1573150984@warthog.procyon.org.uk>
Date:   Thu, 07 Nov 2019 18:23:04 +0000
From:   David Howells <dhowells@...hat.com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     dhowells@...hat.com,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Casey Schaufler <casey@...aufler-ca.com>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        Nicolas Dichtel <nicolas.dichtel@...nd.com>, raven@...maw.net,
        Christian Brauner <christian@...uner.io>,
        keyrings@...r.kernel.org, USB list <linux-usb@...r.kernel.org>,
        linux-block <linux-block@...r.kernel.org>,
        LSM List <linux-security-module@...r.kernel.org>,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 08/14] pipe: Allow buffers to be marked read-whole-or-error for notifications [ver #2]

Andy Lutomirski <luto@...nel.org> wrote:

> > Allow a buffer to be marked such that read() must return the entire buffer
> > in one go or return ENOBUFS.  Multiple buffers can be amalgamated into a
> > single read, but a short read will occur if the next "whole" buffer won't
> > fit.
> >
> > This is useful for watch queue notifications to make sure we don't split a
> > notification across multiple reads, especially given that we need to
> > fabricate an overrun record under some circumstances - and that isn't in
> > the buffers.
> 
> Hmm.  I'm not totally in love with introducing a new error code like
> this for read(), especially if it could affect the kind of pipe that
> is bound to a file in a filesystem.  But maybe it's not a problem.

EMSGSIZE might be better?

David