From: Hugh Dickins <hughd@google.com>
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Hugh Dickins <hughd@google.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
syzbot <syzbot+cd2073ee6d958a8d0fcd@syzkaller.appspotmail.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [mm?] WARNING in __mod_zone_page_state
Date: Sun, 30 Aug 2026 10:29:46 -0700 (PDT) [thread overview]
Message-ID: <4793259a-00da-ea31-8cbd-a6cb5bf48692@google.com> (raw)
In-Reply-To: <apO7GDwIgyhdn3t7@linux.dev>
On Sat, 29 Aug 2026, Shakeel Butt wrote:
> On Sat, Aug 29, 2026 at 08:26:02PM -0700, Hugh Dickins wrote:
...
> >
> > Thanks for looking into this, Shakeel, but I don't think complicating
> > __munlock_folio() is at all the right fix. This is peculiar to the use
> > by mlock_drain_remote(), isn't it? Which is not taking the usual local_lock
> > because the CPU is going offline. I would say, just take the local_lock in
> > mlock_drain_remote(), but (I haven't read the history) for all I know,
> > there may be PREEMPT_RT reasons why that would be completely wrong.
> >
> > Hugh
>
> Thanks Hugh, I will explore the local_lock approach.
Please do. But we may need input from Sebastian. So far as I can see,
page_alloc_cpu_dead()'s neighbouring use of lru_add_drain_cpu(cpu)
would suffer from the exact same issue, there are __counts there too.
Maybe syzbot has not discovered that yet, or maybe I'm confused.
(But you'll understand that I don't particularly welcome a reorg of
the local_locking around the lru_add_drains at the moment; and there's
at least one among them which takes advantage of the fbatch local_lock
to lock something else too.)
Oh for the good old days when we were allowed to say preempt_disable()!
> BTW I simplified the
> fix to the following. is this still making things more complicated?
That is less distracting than your first one, but it's still not the
right fix: the right fix is to have the function called under the
proper conditions in all cases.
>
> diff --git a/mm/mlock.c b/mm/mlock.c
> index efa6716e4dfb..fa30ffed76ab 100644
> --- a/mm/mlock.c
> +++ b/mm/mlock.c
> @@ -141,11 +141,16 @@ static struct lruvec *__munlock_folio(struct folio *folio, struct lruvec *lruvec
>
> munlock:
> if (folio_test_clear_mlocked(folio)) {
> - __zone_stat_mod_folio(folio, NR_MLOCK, -nr_pages);
> + /*
> + * This runs both with and without the lruvec lock held, and
> + * mlock_drain_remote() reaches it fully preemptible, so use
> + * the accessors that serialize themselves.
I'm very far from being a good advisor on PREEMPT_RT,
but I think that comment about lruvec lock would be wrong there.
Hugh
> + */
> + zone_stat_mod_folio(folio, NR_MLOCK, -nr_pages);
> if (isolated || !folio_test_unevictable(folio))
> - __count_vm_events(UNEVICTABLE_PGMUNLOCKED, nr_pages);
> + count_vm_events(UNEVICTABLE_PGMUNLOCKED, nr_pages);
> else
> - __count_vm_events(UNEVICTABLE_PGSTRANDED, nr_pages);
> + count_vm_events(UNEVICTABLE_PGSTRANDED, nr_pages);
> }
>
> /* folio_evictable() has to be checked *after* clearing Mlocked */
> --
next prev parent reply other threads:[~2026-08-30 17:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-29 17:52 [syzbot] [mm?] WARNING in __mod_zone_page_state syzbot
2026-08-29 23:03 ` Shakeel Butt
2026-08-30 1:08 ` Shakeel Butt
2026-08-30 3:26 ` Hugh Dickins
2026-08-30 5:15 ` Shakeel Butt
2026-08-30 17:29 ` Hugh Dickins [this message]
2026-08-31 10:28 ` Sebastian Andrzej Siewior
2026-08-31 20:11 ` Shakeel Butt
2026-08-31 10:04 ` Sebastian Andrzej Siewior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4793259a-00da-ea31-8cbd-a6cb5bf48692@google.com \
--to=hughd@google.com \
--cc=bigeasy@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shakeel.butt@linux.dev \
--cc=syzbot+cd2073ee6d958a8d0fcd@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.