* Re: + mm-page_alloc-protect-pcp-lists-with-a-spinlock-fix.patch added to mm-unstable branch
2022-07-07 22:21 ` Vlastimil Babka
@ 2022-07-08 0:20 ` Andrew Morton
2022-07-08 0:22 ` Hugh Dickins
2022-07-08 7:41 ` Dan Carpenter
2 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2022-07-08 0:20 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Yu Zhao, mm-commits, Nicolas Saenz Julienne, Marcelo Tosatti,
Marek Szyprowski, Minchan Kim, Michal Hocko, Mel Gorman,
kernel test robot, Hugh Dickins, dan.carpenter
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: + mm-page_alloc-protect-pcp-lists-with-a-spinlock-fix.patch added to mm-unstable branch
2022-07-07 22:21 ` Vlastimil Babka
2022-07-08 0:20 ` Andrew Morton
@ 2022-07-08 0:22 ` Hugh Dickins
2022-07-08 0:35 ` Yu Zhao
2022-07-08 0:40 ` Andrew Morton
2022-07-08 7:41 ` Dan Carpenter
2 siblings, 2 replies; 12+ messages in thread
From: Hugh Dickins @ 2022-07-08 0:22 UTC (permalink / raw)
To: Andrew Morton
Cc: Vlastimil Babka, Yu Zhao, mm-commits, Nicolas Saenz Julienne,
Marcelo Tosatti, Marek Szyprowski, Minchan Kim, Michal Hocko,
Mel Gorman, kernel test robot, Hugh Dickins, dan.carpenter
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: + mm-page_alloc-protect-pcp-lists-with-a-spinlock-fix.patch added to mm-unstable branch
2022-07-08 0:22 ` Hugh Dickins
@ 2022-07-08 0:35 ` Yu Zhao
2022-07-08 0:52 ` Andrew Morton
2022-07-08 0:40 ` Andrew Morton
1 sibling, 1 reply; 12+ messages in thread
From: Yu Zhao @ 2022-07-08 0:35 UTC (permalink / raw)
To: Hugh Dickins
Cc: Andrew Morton, Vlastimil Babka, mm-commits,
Nicolas Saenz Julienne, Marcelo Tosatti, Marek Szyprowski,
Minchan Kim, Michal Hocko, Mel Gorman, kernel test robot,
dan.carpenter
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/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: + mm-page_alloc-protect-pcp-lists-with-a-spinlock-fix.patch added to mm-unstable branch
2022-07-08 0:35 ` Yu Zhao
@ 2022-07-08 0:52 ` Andrew Morton
2022-07-08 0:58 ` Yu Zhao
0 siblings, 1 reply; 12+ messages in thread
From: Andrew Morton @ 2022-07-08 0:52 UTC (permalink / raw)
To: Yu Zhao
Cc: Hugh Dickins, Vlastimil Babka, mm-commits, Nicolas Saenz Julienne,
Marcelo Tosatti, Marek Szyprowski, Minchan Kim, Michal Hocko,
Mel Gorman, kernel test robot, dan.carpenter
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: + mm-page_alloc-protect-pcp-lists-with-a-spinlock-fix.patch added to mm-unstable branch
2022-07-08 0:52 ` Andrew Morton
@ 2022-07-08 0:58 ` Yu Zhao
0 siblings, 0 replies; 12+ messages in thread
From: Yu Zhao @ 2022-07-08 0:58 UTC (permalink / raw)
To: Andrew Morton
Cc: Hugh Dickins, Vlastimil Babka, mm-commits, Nicolas Saenz Julienne,
Marcelo Tosatti, Marek Szyprowski, Minchan Kim, Michal Hocko,
Mel Gorman, kernel test robot, dan.carpenter
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: + mm-page_alloc-protect-pcp-lists-with-a-spinlock-fix.patch added to mm-unstable branch
2022-07-08 0:22 ` Hugh Dickins
2022-07-08 0:35 ` Yu Zhao
@ 2022-07-08 0:40 ` Andrew Morton
1 sibling, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2022-07-08 0:40 UTC (permalink / raw)
To: Hugh Dickins
Cc: Vlastimil Babka, Yu Zhao, mm-commits, Nicolas Saenz Julienne,
Marcelo Tosatti, Marek Szyprowski, Minchan Kim, Michal Hocko,
Mel Gorman, kernel test robot, dan.carpenter
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: + mm-page_alloc-protect-pcp-lists-with-a-spinlock-fix.patch added to mm-unstable branch
2022-07-07 22:21 ` Vlastimil Babka
2022-07-08 0:20 ` Andrew Morton
2022-07-08 0:22 ` Hugh Dickins
@ 2022-07-08 7:41 ` Dan Carpenter
2022-07-08 9:04 ` Vlastimil Babka
2 siblings, 1 reply; 12+ messages in thread
From: Dan Carpenter @ 2022-07-08 7:41 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Yu Zhao, Andrew Morton, mm-commits, Nicolas Saenz Julienne,
Marcelo Tosatti, Marek Szyprowski, Minchan Kim, Michal Hocko,
Mel Gorman, kernel test robot, Hugh Dickins
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: + mm-page_alloc-protect-pcp-lists-with-a-spinlock-fix.patch added to mm-unstable branch
2022-07-08 7:41 ` Dan Carpenter
@ 2022-07-08 9:04 ` Vlastimil Babka
0 siblings, 0 replies; 12+ messages in thread
From: Vlastimil Babka @ 2022-07-08 9:04 UTC (permalink / raw)
To: Dan Carpenter
Cc: Yu Zhao, Andrew Morton, mm-commits, Nicolas Saenz Julienne,
Marcelo Tosatti, Marek Szyprowski, Minchan Kim, Michal Hocko,
Mel Gorman, kernel test robot, Hugh Dickins
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
^ permalink raw reply [flat|nested] 12+ messages in thread