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

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

[Andrew Morton]

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@linux-foundation.org>
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

Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nicolas Saenz Julienne <nsaenzju@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/page_alloc.c |    1 +
 1 file changed, 1 insertion(+)

--- a/mm/page_alloc.c~mm-page_alloc-protect-pcp-lists-with-a-spinlock-fix
+++ a/mm/page_alloc.c
@@ -3792,6 +3792,7 @@ static struct page *rmqueue_pcplist(stru
 	pcp_trylock_prepare(UP_flags);
 	if (!spin_trylock(&pcp->lock)) {
 		pcp_trylock_finish(UP_flags);
+		local_unlock_irqrestore(&pagesets.lock, flags);
 		return NULL;
 	}
 
_

Patches currently in -mm which might be from akpm@linux-foundation.org are

android-binder-stop-saving-a-pointer-to-the-vma-fix.patch
mm-remove-the-vma-linked-list-fix-2-fix.patch
mm-drop-oom-code-from-exit_mmap-fix-fix.patch
mm-add-merging-after-mremap-resize-checkpatch-fixes.patch
mm-factor-helpers-for-memory_failure_dev_pagemap-fix.patch
xfs-support-cow-in-fsdax-mode-fix.patch
mm-thp-kill-transparent_hugepage_active-fix.patch
mm-thp-kill-transparent_hugepage_active-fix-fix.patch
mm-page_alloc-protect-pcp-lists-with-a-spinlock-fix.patch
x86-mm-move-protection_map-inside-the-platform-fix.patch

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

[Vlastimil Babka]

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@linux-foundation.org>
> 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.

> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Cc: Hugh Dickins <hughd@google.com>
> Cc: Marcelo Tosatti <mtosatti@redhat.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Mel Gorman <mgorman@techsingularity.net>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Minchan Kim <minchan@kernel.org>
> Cc: Nicolas Saenz Julienne <nsaenzju@redhat.com>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Yu Zhao <yuzhao@google.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  mm/page_alloc.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> --- a/mm/page_alloc.c~mm-page_alloc-protect-pcp-lists-with-a-spinlock-fix
> +++ a/mm/page_alloc.c
> @@ -3792,6 +3792,7 @@ static struct page *rmqueue_pcplist(stru
>  	pcp_trylock_prepare(UP_flags);
>  	if (!spin_trylock(&pcp->lock)) {
>  		pcp_trylock_finish(UP_flags);
> +		local_unlock_irqrestore(&pagesets.lock, flags);
>  		return NULL;
>  	}
>  
> _
> 
> Patches currently in -mm which might be from akpm@linux-foundation.org are
> 
> android-binder-stop-saving-a-pointer-to-the-vma-fix.patch
> mm-remove-the-vma-linked-list-fix-2-fix.patch
> mm-drop-oom-code-from-exit_mmap-fix-fix.patch
> mm-add-merging-after-mremap-resize-checkpatch-fixes.patch
> mm-factor-helpers-for-memory_failure_dev_pagemap-fix.patch
> xfs-support-cow-in-fsdax-mode-fix.patch
> mm-thp-kill-transparent_hugepage_active-fix.patch
> mm-thp-kill-transparent_hugepage_active-fix-fix.patch
> mm-page_alloc-protect-pcp-lists-with-a-spinlock-fix.patch
> x86-mm-move-protection_map-inside-the-platform-fix.patch
> 

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

[Yu Zhao]

On Thu, Jul 7, 2022 at 3:58 PM Vlastimil Babka <vbabka@suse.cz> 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@linux-foundation.org>
> > 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.

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

[Vlastimil Babka]

On 7/8/22 00:09, Yu Zhao wrote:
> On Thu, Jul 7, 2022 at 3:58 PM Vlastimil Babka <vbabka@suse.cz> 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@linux-foundation.org>
>> > 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.

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

[Andrew Morton]

On Fri, 8 Jul 2022 00:21:45 +0200 Vlastimil Babka <vbabka@suse.cz> wrote:

> >> > 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.

Patch 7 ("mm/page_alloc: replace local_lock with normal spinlock") has
been dropped for now due to ongoing issues, most recently
"BUG:sleeping_function_called_from_invalid_context_at_mm/gup.c".  This
droppage exposed the issue which this patch
(mm-page_alloc-protect-pcp-lists-with-a-spinlock-fix.patch) addresses.

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

[Hugh Dickins]

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@suse.cz> 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@linux-foundation.org>
> >> > 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.

Hugh

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

[Yu Zhao]

On Thu, Jul 7, 2022 at 6:22 PM Hugh Dickins <hughd@google.com> 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@suse.cz> 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@linux-foundation.org>
> > >> > 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@linux-foundation.org/
[3] https://lore.kernel.org/r/202207071103.r5a2F97A-lkp@intel.com/

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

[Andrew Morton]

On Thu, 7 Jul 2022 17:22:06 -0700 (PDT) Hugh Dickins <hughd@google.com> 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.

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

[Andrew Morton]

On Thu, 7 Jul 2022 18:35:12 -0600 Yu Zhao <yuzhao@google.com> wrote:

> > 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.

As Vlastimil has sleuthed out that the
"BUG:sleeping_function_called_from_invalid_context_at_mm/gup.c"
reporter was using the v4 series, I've restored 7/7 ("mm/page_alloc:
replace local_lock with normal spinlock") for tomorrow's linux-next.

I retained this fix against 2/7 and reworked 7/7 appropriately.  So it
is now

/* Lock and remove page from the per-cpu list */
static struct page *rmqueue_pcplist(struct zone *preferred_zone,
			struct zone *zone, unsigned int order,
			gfp_t gfp_flags, int migratetype,
			unsigned int alloc_flags)
{
	struct per_cpu_pages *pcp;
	struct list_head *list;
	struct page *page;
	unsigned long flags;
	unsigned long __maybe_unused UP_flags;

	/*
	 * spin_trylock may fail due to a parallel drain. In the future, the
	 * trylock will also protect against IRQ reentrancy.
	 */
	pcp_trylock_prepare(UP_flags);
	pcp = pcp_spin_trylock_irqsave(zone->per_cpu_pageset, flags);
	if (!pcp) {
		pcp_trylock_finish(UP_flags);
		return NULL;
	}

	/*
	 * On allocation, reduce the number of pages that are batch freed.
	 * See nr_pcp_free() where free_factor is increased for subsequent
	 * frees.
	 */
	pcp->free_factor >>= 1;
	list = &pcp->lists[order_to_pindex(migratetype, order)];
	page = __rmqueue_pcplist(zone, order, migratetype, alloc_flags, pcp, list);
	pcp_spin_unlock_irqrestore(pcp, flags);
	pcp_trylock_finish(UP_flags);
	if (page) {
		__count_zid_vm_events(PGALLOC, page_zonenum(page), 1);
		zone_statistics(preferred_zone, zone, 1);
	}
	return page;
}

btw, the leading comment implies (to me) that the page is to be locked.
The comment could do with a rethink.

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

[Yu Zhao]

On Thu, Jul 7, 2022 at 6:52 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 7 Jul 2022 18:35:12 -0600 Yu Zhao <yuzhao@google.com> wrote:
>
> > > 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.
>
> As Vlastimil has sleuthed out that the
> "BUG:sleeping_function_called_from_invalid_context_at_mm/gup.c"
> reporter was using the v4 series, I've restored 7/7 ("mm/page_alloc:
> replace local_lock with normal spinlock") for tomorrow's linux-next.

Yes, the bot initially tried v4 without the fix and reported the
problem. And Oliver manually tried again under the impression he had
the fix [1]. But that's the real fix [2]; it's just a cleanup.

[1] https://lore.kernel.org/r/YsRB3fZHAfik0M%2Fq@xsang-OptiPlex-9020/
[2] https://lore.kernel.org/r/20220615160446.be1f75fd256d67e57b27a9fc@linux-foundation.org/

> I retained this fix against 2/7 and reworked 7/7 appropriately.  So it
> is now

Awesome.

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

[Dan Carpenter]

On Fri, Jul 08, 2022 at 12:21:45AM +0200, Vlastimil Babka wrote:
> >> > ------------------------------------------------------
> >> > From: Andrew Morton <akpm@linux-foundation.org>
> >> > 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.

My report is the LKP report?

Some of the Smatch warnings from LKP get sent to me and then I look them
over and either delete them or hit forward.  I don't have visibility
into the LKP process more than just looking over the warnings so I can't
say how it picks which patches to test off the mailing list.

regards,
dan carpenter

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

[Vlastimil Babka]

On 7/8/22 09:41, Dan Carpenter wrote:
> On Fri, Jul 08, 2022 at 12:21:45AM +0200, Vlastimil Babka wrote:
>> >> > ------------------------------------------------------
>> >> > From: Andrew Morton <akpm@linux-foundation.org>
>> >> > 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.
> 
> My report is the LKP report?

Oh, right, sorry, I missed that the mail from you contains also Reported-by:
kernel test robot <lkp@intel.com>

> Some of the Smatch warnings from LKP get sent to me and then I look them
> over and either delete them or hit forward.  I don't have visibility
> into the LKP process more than just looking over the warnings so I can't
> say how it picks which patches to test off the mailing list.

Thanks for the clarification!
Vlastimil

> regards,
> dan carpenter