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?
Ciao, Thorsten
