Re: [PATCH 6.18 044/108] block: invalidate cached plug timestamp after task switch

[Jens Axboe <axboe@kernel.dk>]

On 7/4/26 12:45 AM, Greg Kroah-Hartman wrote:
> On Fri, Jul 03, 2026 at 08:35:46PM -0600, Jens Axboe wrote:
>> On 7/3/26 8:05 PM, Sasha Levin wrote:
>>> On Thu, Jul 03, 2026 at 05:32:35AM -0700, Usama Arif wrote:
>>>> It looks like this patch was backported, but the preceding patch [1]
>>>> in the series was not bacported to the stable branches. Both this and its
>>>> prerequisite have the same Fixes tag.
>>>> Not having the prerequisite will result in a NULL derefernce.
>>>> Could we please add [1] to the stable branches?
>>>
>>> Now queued the prerequisite fd38b75c4b43 ("kernel/fork: clear PF_BLOCK_TS
>>> in copy_process()") for 7.1.y, 6.18.y, and 6.12.y, thanks!
>>
>> This is a problem. Can some light be shed on why only 1 patch of the 2
>> got applied? This could lead to big problems, which seems to be the
>> case for this one in fact.
> 
> This is on me, I only took a "subset" of the patches tagged for stable
> for this round of releases as I was facing a huge backlog of stuff
> (everyone loves to wait for -rc1 for cc: stable fixes), combined with me
> having travelled for 6 weeks straight for conferences which didn't allow
> me a ton of time to do stable kernel work to keep on top of the pile.
> 
> The patch wasn't lost, and is still in my queue to process (along with
> 748 other patches) it just wasn't obvious that there was a dependancy
> and that I had to take them both in order, that's on me, sorry.  This is

At least this one would've been avoided if patches marked as fixing the
same upstream commit would never get split. Which does seem like a
(very) sane default! Particularly when they are part of the same
posting, it's not like they landed at separate times.

People get busy and life gets in the way, I do think some fixed rules
like that might be helpful.

> also why we have review, to catch things when I do something stupid like
> this :)

Agree, but at the same time, requiring review to catch these is fraught
with error. Not only do maintainers and developers get a lot of emails
from stable, we need to carefully sift through them. And rely on the
original patch author to do the same. Which in this case thankfully did
happen, but... People also don't necessarily pay full attention all the
time, there's work and vacation and a bunch of other things that get in
the way.

This is different than normal review, where inclusion is gated on the
review. If nobody says anything, it'll go in.

>> A Depends-on could be used here, but it's pretty hard for a submitter
>> to do that, as the sha isn't known before it goes into the maintainers
>> tree.
> 
> Agreed, that wouldn't really work, and isn't normally needed.
> 
> But again, maybe trying to get patches that are cc: stable into Linus
> _before_ -rc1 is better?  Hey, I can dream...

I send out fixes _every week_, -rc1 or -rcX changes nothing in my
workflow.

-- 
Jens Axboe