linux-kernel - Re: [RESEND PATCH] fs/pipe: Introduce a check to skip sleeping processes during pipe read/write

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: <CAHk-=wiCRwRFi0kGwd_Uv+Xv4HOB-ivHyUp9it6CNSmrKT4gOA@mail.gmail.com>
Date: Tue, 31 Dec 2024 14:31:54 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Manfred Spraul <manfred@...orfullife.com>, WangYuli <wangyuli@...ontech.com>, 
	linux-fsdevel <linux-fsdevel@...r.kernel.org>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Christian Brauner <brauner@...nel.org>, 1vier1@....de
Subject: Re: [RESEND PATCH] fs/pipe: Introduce a check to skip sleeping
 processes during pipe read/write

On Tue, 31 Dec 2024 at 12:25, Oleg Nesterov <oleg@...hat.com> wrote:
>
> But let me ask another question right now. what do you think about another
> minor change below?

Probably ok. Although I'm not convinced it makes things any more readable.

> Again, mostly to make this logic more understandable. Although I am not
> sure I really understand it...

So see commit fe67f4dd8daa ("pipe: do FASYNC notifications for every
pipe IO, not just state changes") on why that crazy poll_usage thing
exists.

Basically, epoll (and FASYNC) create *events*, not "state
transitions". And people have sadly depended on getting an event for
each pipe write, rather than getting an event on state transition.

So epoll and FASYNC can't depend on "users only care about the pipe
becoming readable". Which is why we have that poll_usage thing, and
why the SIGIO is unconditional.

The

  #ifdef CONFIG_EPOLL

addition is straightforward enough and matches the existing comment.

But you adding the FMODE_READ test should probably get a new comment
about how we only do this for epoll readability, not for writability..

Technically epoll might notice "read done" vs "became writable", but
nobody ever reported that, so we never did that poll_usage hack for
the pipe_read() side. So "poll_usage" realyl is very much a hack for
"user space depended on _this_ particular thing being an event, not
that other thing".

              Linus