On Thu, 7 Jul 2022 17:22:06 -0700 (PDT) Hugh Dickins <hughd@xxxxxxxxxx> wrote:
> > I'm not aware of a lkp report for v5 (found only Dan's) but yeah, hitting
> > the (similar but not identical) bug fixed by this -fix would indeed be
> > possible in v5 if patch 7 was not applied.
>
> This is all very confusing.
>
> For whatever reason, Mel's 7/7 (and its -fix per Yu Zhao) was not
> included in next-20220706 or next-20220707 (I never tried 0705, and
> 0704 had none of Mel's series, so no problem in this regard; and
> in weeks before that, no time for testing here).
>
> So when I tried testing on 0706, got plenty of rcu_preempt stalls or
> sleeping function called from invalid context (irqs_disabled(): 1) or
> other alternative warnings. And found that applying the missing 7/7
> plus -fix (I've never tried 7/7 without -fix) got rid of all those,
> allowing to move forward and look into other bugs.
>
> But now we have a different fix going in, though I thought Andrew
> said he wanted to move 7/7 to mm-stable tomorrow (despite its not
> even reaching mm-unstable?). Maybe the Oliver Sang lkp testing (on
> out-of-date version) cast doubt on v5 7/7 and delayed it going in.
Yes, 7/7 ("mm/page_alloc: replace local_lock with normal spinlock") has
had a number of issues (most recently
"BUG:sleeping_function_called_from_invalid_context_at_mm/gup.c") so 7/7
has been shelved for now. Unfortunately 7/7 accidentally fixed a bug
which was added by 2/7.
> This relentless drive towards mm-stable: I for one cannot keep up.
> I'd like to ask for slowing down a bit - my intention had been to
> reach testing maple tree again (it's not yet what I'd call stable),
> but this and a couple of other issues got in the way. More mails
> to write.
I'm not happy with it.
We're in -rc4 and still only a small amount of the queue look stable
enough to be moved into mm-stable. Major patch series still have
question marks and red flags on them. Things are being left to dangle
for days or weeks.
I addressed this at lsf/mm - asked that we drive things to completion
more promptly before moving onto other things.
I can (and do) hold things over if they don't seem sufficiently
stabilized. This results in fairly major patch reordering/redoing but
at least that happens during mid-rc rather than at -rc7.
If I have to route around mapletree this time then that's going to be
fairly nasty - quite a lot of succeeding material depends on it. We do
think mapletree is just about there, so please do concentrate your
testing and reviewing on that if poss.
Slow down? Maybe we'll have to. That would involve blocking
significant new work somewhat earlier, around -rc5 perhaps. But at
-rc4 we're still in firehose mode.
