[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgYC-iAp4dw_wN3DBWUB=NzkjT42Dpr46efpKBuF4Nxkg@mail.gmail.com>
Date: Sun, 9 Feb 2025 09:26:37 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Christian Brauner <brauner@...nel.org>, Jeff Layton <jlayton@...nel.org>,
David Howells <dhowells@...hat.com>, "Gautham R. Shenoy" <gautham.shenoy@....com>,
K Prateek Nayak <kprateek.nayak@....com>, Mateusz Guzik <mjguzik@...il.com>,
Neeraj Upadhyay <Neeraj.Upadhyay@....com>, Oliver Sang <oliver.sang@...el.com>,
Swapnil Sapkal <swapnil.sapkal@....com>, WangYuli <wangyuli@...ontech.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] pipe: change pipe_write() to never add a zero-sized buffer
On Sun, 9 Feb 2025 at 07:08, Oleg Nesterov <oleg@...hat.com> wrote:
>
> This is no longer necessary after c73be61cede5 ("pipe: Add general notification
> queue support"), pipe_write() checks pipe_has_watch_queue() and returns -EXDEV
> at the start. And can't help in any case, pipe_write() no longer takes this
> rd_wait.lock spinlock.
Ack. This code all goes back to the two-level locking thing with
notifications using just the spinlock side.
The locking was removed from this code in commit dfaabf916b1c
("fs/pipe: remove unnecessary spinlock from pipe_write()"), but the
"pre-allocate" logic remained.
This patch seems to be the right thing to do and removes the vestiges
of the old model.
But I don't think you need that pipe_buf_assert_len() thing. And if
you do, please don't make it a pointless inline helper that only hides
what it does.
Linus
Powered by blists - more mailing lists