Re: + mm-page_alloc-protect-pcp-lists-with-a-spinlock-fix.patch added to mm-unstable branch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 7, 2022 at 6:22 PM Hugh Dickins <hughd@xxxxxxxxxx> wrote:
>
> On Fri, 8 Jul 2022, Vlastimil Babka wrote:
> > On 7/8/22 00:09, Yu Zhao wrote:
> > > On Thu, Jul 7, 2022 at 3:58 PM Vlastimil Babka <vbabka@xxxxxxx> wrote:
> > >>
> > >> On 7/7/22 22:09, Andrew Morton wrote:
> > >> > The patch titled
> > >> >      Subject: mm-page_alloc-protect-pcp-lists-with-a-spinlock-fix
> > >> > has been added to the -mm mm-unstable branch.  Its filename is
> > >> >      mm-page_alloc-protect-pcp-lists-with-a-spinlock-fix.patch
> > >> >
> > >> > This patch will shortly appear at
> > >> >      https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-page_alloc-protect-pcp-lists-with-a-spinlock-fix.patch
> > >> >
> > >> > This patch will later appear in the mm-unstable branch at
> > >> >     git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> > >> >
> > >> > Before you just go and hit "reply", please:
> > >> >    a) Consider who else should be cc'ed
> > >> >    b) Prefer to cc a suitable mailing list as well
> > >> >    c) Ideally: find the original patch on the mailing list and do a
> > >> >       reply-to-all to that, adding suitable additional cc's
> > >> >
> > >> > *** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
> > >> >
> > >> > The -mm tree is included into linux-next via the mm-everything
> > >> > branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> > >> > and is updated there every 2-3 working days
> > >> >
> > >> > ------------------------------------------------------
> > >> > From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> > >> > Subject: mm-page_alloc-protect-pcp-lists-with-a-spinlock-fix
> > >> > Date: Thu Jul  7 01:06:35 PM PDT 2022
> > >> >
> > >> > add missing local_unlock_irqrestore() on contention path
> > >>
> > >> Doh, that's true and something to fix, although patch 7 did remove the bug
> > >> later in the same series so that wouldn't explain the lkp report for patch
> > >> 7. The reason lkp test robot complained was AFAICS that it was testing v4,
> > >> as I just replied there.
> > >
> > > Sorry I didn't bother to reply until now: it did test v5, at this
> > > commit, not the whole series.
> >
> > I meant this report that appears to be for v4 (full series including patch 7):
> > https://lore.kernel.org/all/YsFk%2FqU+QtWun04h@xsang-OptiPlex-9020/
> > That reported a bug due to missing unpin that was previously reported for v4
> > and fixed in v5.
> >
> > 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.
>
> 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.

Sorry for not being clear (it doesn't seem confusing to me because I
don't trust the bot):

There were two reports, the first one [1] tested v4 without the fix
[2]; the second one [3] tested v5 at patch 5/7 (not the whole series).

v4 + the fix is good; v5 the whole series is good.

Please do not drop patch 7/7 and do not add this fix.

Thanks.

[1] https://lore.kernel.org/r/YsFk%2FqU+QtWun04h@xsang-OptiPlex-9020/
[2] https://lore.kernel.org/r/20220615160446.be1f75fd256d67e57b27a9fc@xxxxxxxxxxxxxxxxxxxx/
[3] https://lore.kernel.org/r/202207071103.r5a2F97A-lkp@xxxxxxxxx/



[Index of Archives]     [Kernel Archive]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]

  Powered by Linux