On Thu, Dec 29, 2022 at 02:04:53PM +0100, Thorsten Leemhuis wrote:
> On 28.12.22 19:57, Vlastimil Babka wrote:
> > On 12/28/22 16:45, Greg Kroah-Hartman wrote:
> >> On Wed, Dec 28, 2022 at 04:02:57PM +0100, Holger Hoffstätte wrote:
> >>> On 2022-12-28 15:25, Greg Kroah-Hartman wrote:
> >>>> This is the start of the stable review cycle for the 6.1.2 release.
> >>>> There are 1146 patches in this series, all will be posted as a response
> >>>> to this one. If anyone has any issues with these being applied, please
> >>>> let me know.
> >>>
> >>> I know this is already a large set of updates, but it would be great if
> >>> commit 6f12be792fde994ed934168f93c2a0d2a0cf0bc5 ("mm, mremap: fix mremap()
> >>> expanding vma with addr inside vma") could be added as well; it applies and
> >>> works fine on top of 6.1.1.
> >>> This fixes quite a few annoying mmap-related out-of-memory failures.
> >>
> >> It's set up for future releases. If this was such a big issue for
> >> 6.1-final, why wasn't it sent to Linus before 6.2-rc1?
> >
> > Thorsten did question its upstreaming speed elsewhere. But it actually
> > is in 6.2-rc1. Andrew sent the PR on 22th and Linus merged on 23th [1].
> > I didn't try to accelerate it to stable as IIRC people already pointed
> > it out and you acknowledged it's on your radar, and it was a tracked
> > regression. Sucks that it didn't make it to 6.1.2.
>
> Yup. I've been thinking somewhat what I could or should do to ensure
> things work more smoothly when similar situations arise in the future;
> ideally without me stepping on maintainer's toes too much. ;)
>
> Currently I consider doing the following two things:
>
> (1) if I notice something that looks like an important regression fix,
> reply with a "how fast do you think this fix should process through the
> ranks" inquiry to the developer. With such information I'd feel way more
> comfortable sending a "Linus, could you maybe pick this up directly"
> after some time in case the maintainer leaves the patch longer in -next.
>
> (2) once Linus merged the fix, send a quick mail to Greg/the stable team
> asking them to immediately queue it for the next release (in case
> problems show up it can still be de-queued).
>
> Does that sound sane? Or anyone any better idea?
Sounds sane to me!
thanks,
greg k-h
