public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	stable <stable@vger.kernel.org>
Subject: Re: FAILED: patch "[PATCH] pipe: increase minimum default pipe size to 2 pages" failed to apply to 4.4-stable tree
Date: Mon, 9 Aug 2021 18:57:20 +0200	[thread overview]
Message-ID: <20210809165720.GA22893@1wt.eu> (raw)
In-Reply-To: <1628527244.3ckns4zvnz.none@localhost>

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@linuxfoundation.org> 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

      reply	other threads:[~2021-08-09 16:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-09  9:52 FAILED: patch "[PATCH] pipe: increase minimum default pipe size to 2 pages" failed to apply to 4.4-stable tree gregkh
2021-08-09 16:23 ` Linus Torvalds
2021-08-09 16:27   ` Greg Kroah-Hartman
2021-08-09 16:36     ` Linus Torvalds
2021-08-09 16:46       ` Linus Torvalds
2021-08-09 17:40         ` Greg Kroah-Hartman
2021-08-09 19:04           ` Willy Tarreau
2021-08-10  6:54             ` Greg Kroah-Hartman
2021-08-10  8:39               ` Willy Tarreau
2021-08-09 16:51     ` Alex Xu (Hello71)
2021-08-09 16:57       ` Willy Tarreau [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210809165720.GA22893@1wt.eu \
    --to=w@1wt.eu \
    --cc=alex_y_xu@yahoo.ca \
    --cc=gregkh@linuxfoundation.org \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox