Re: [PATCH] memcg: Don't call schedule_work when no spinning is allowed

[David Stevens]

On Mon, Aug 31, 2026 at 5:10 PM Shakeel Butt <shakeel.butt@xxxxxxxxx> wrote:
>
> On Mon, Aug 31, 2026 at 04:43:39PM -0700, David Stevens wrote:
> > Memcg charging can be done from any context, but calling schedule_work()
> > isn't safe from an NMI. If memory.high is breached from a context where
> > spinning isn't allowed, use irq_work to schedule the reclaim work.
> >
> > Fixes: 3ac4638a734a ("memcg: make memcg_rstat_updated nmi safe")
> > Signed-off-by: David Stevens <stevensd@xxxxxxxxxx>
>
> Did you hit this issue or just code inspection? I assume this is the
> done_restock code path.

I just found this via code inspection. I spent a little bit trying to
trigger it for real, but the only way I managed was by writing a hacky
driver absuing alloc_pages_nolock().

> > ---
> >  include/linux/memcontrol.h |  1 +
> >  mm/memcontrol.c            | 12 +++++++++++-
> >  2 files changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> > index 8170bb8066a2..036d973ceca6 100644
> > --- a/include/linux/memcontrol.h
> > +++ b/include/linux/memcontrol.h
> > @@ -219,6 +219,7 @@ struct mem_cgroup {
> >       spinlock_t       peaks_lock;
> >
> >       /* Range enforcement for interrupt charges */
> > +     struct irq_work high_irq_work;
>
> Instead of adding more complexity, let's just return if we can not spin on
> done_restock path.
>

There would be no guarantee that memcg reclaim would ever be
triggered, which also would also stop MEMCG_HIGH events from being
generated. Overall that seems a more serious than just dropping
userspace notifications like is done for MEMCG_MAX.

That said, it is very much an edge case. I can send a patch with the
simpler fix if dropping the events is preferred.

-David