Re: [PATCH] pipe_read: don't wake up the writer if the pipe is still full
From: Mateusz Guzik
Date: Mon Mar 03 2025 - 14:07:06 EST
On Mon, Mar 3, 2025 at 7:56 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, 3 Mar 2025 at 08:33, Mateusz Guzik <mjguzik@xxxxxxxxx> wrote:
> >
> > The stock code already has a dedicated routine to advance the tail,
> > adding one for head (instead of an ad-hoc increment) is borderline
> > just clean up.
>
> There's currently a fair number of open-coded assignments:
>
> git grep -E 'pipe->((tail)|(head)).*=' fs/
>
> and some of those are under specific locking rules together with other
> updates (ie the watch-queue 'note_loss' thing.
>
> But hey, if some explicit empty/full flag is simpler, then it
> certainly does fit with our current model too, since we already do
> have those other flags (exactly like 'note_loss')
>
> I do particularly hate seeing 'bool' in structures like this. On alpha
> it is either fundamentally racy, or it's 32-bit. On other
> architectures, it's typically 8 bits for a 1-bit value.
>
> But we do have holes in that structure where it slots.
>
I was thinking about just fs/pipe.c.
These helpers being used elsewhere is not something I was aware of (or
thought would be a thing). The relevant git grep makes me self-nak
that patch. :->
But that's some side stuff. Not only it is your call how to proceed,
but per the previous e-mail I agree 16-byte head/tail and a 32-byte
read would be best.
Hopefully the AMD guys will want to take a stab. Otherwise I'll hack it up.
--
Mateusz Guzik <mjguzik gmail.com>