Re: FAILED: patch "[PATCH] pipe: increase minimum default pipe size to 2 pages" failed to apply to 4.4-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 09, 2021 at 12:51:48PM -0400, Alex Xu (Hello71) wrote:
> Excerpts from Greg Kroah-Hartman's message of August 9, 2021 12:27 pm:
> > On Mon, Aug 09, 2021 at 09:23:00AM -0700, Linus Torvalds wrote:
> >> On Mon, Aug 9, 2021 at 2:52 AM <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >> >
> >> > The patch below does not apply to the 4.4-stable tree.
> >> 
> >> It shouldn't.
> >> 
> >> The pipe buffer accounting and soft limits that introduced the whole
> >> "limp along with limited pipe buffers" behavior that this fixes was
> >> introduced by
> >> 
> >> > Fixes: 759c01142a ("pipe: limit the per-user amount of pages allocated in pipes")
> >> 
> >> ..which made it into 4.5.
> >> 
> >> So 4.4 is unaffected and doesn't want this patch.
> > 
> > But that commit showed up in 4.4.13 as fa6d0ba12a8e ("pipe: limit the
> > per-user amount of pages allocated in pipes") which is why I asked about
> > this.  The code didn't look similar at all, so I couldn't easily figure
> > out the backport myself :(
> > 
> > Willy, any ideas?
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> alloc_pipe_info was heavily modified in 09b4d19900 ("pipe: simplify 
> logic in alloc_pipe_info()") and a005ca0e68 ("pipe: fix limit checking 
> in alloc_pipe_info()"), which I think landed in 4.9 and weren't 
> backported. The backported patch should look similar to this:
> 
> @@ -621,7 +621,7 @@
> 
>                 if (!too_many_pipe_buffers_hard(user)) {
>                         if (too_many_pipe_buffers_soft(user))
> -                               pipe_bufs = 1;
> +                               pipe_bufs = 2;
>                         pipe->bufs = kzalloc(sizeof(struct pipe_buffer) * pipe_bufs, GFP_KERNEL);
>                 }
> 
> I can send a rebased patch, but I think we can also leave it the way it 
> is. It's a bit of an edge case; if nobody's hit it so far on 4.4, maybe 
> it can just stay this way until February. There's SLTS, but I don't 
> think they're interested in this kind of patch. Thoughts?

I tend to think that if the patch spent 5 years in 4.4 without anyone
hitting the problem it's likely that most of the applications found on
these distros are not affected either. Doubling the number of pages
could however increase the amount of memory used on some small machines
heavily using pipes (e.g. for splicing), reducing their stability, which
is probably not desirable if nobody complained about the current behavior
on that version.

Thus while I think that this fix should do the job I think it's better
to leave it out of 4.4 until someone *really* wants it.

Just my two cents,
Willy



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux