Re: [PATCH RFC] mm/kmemleak: avoid soft lockup when scanning task stacks
From: Breno Leitao
Date: Fri Jun 12 2026 - 07:59:01 EST
On Fri, Jun 12, 2026 at 07:22:38PM +0800, Lance Yang wrote:
>
>
> On 2026/6/12 18:39, Breno Leitao wrote:
> > On Fri, Jun 12, 2026 at 05:57:12PM +0800, Lance Yang wrote:
> >
> > > > If we go this route, the aborted round has to suppress reporting, reusing
> > > > kmemleak's existing "scan was interrupted -> don't report" path:
> > > >
> > > > if (need_resched() && !kmemleak_stack_scan_break(g, p)) {
> > > > aborted = true;
> > > > goto unlock;
> > > > }
> > >
> > > I'd expect the normal case to just drop RCU, cond_resched(), take RCU
> > > again, see both cursors still alive, and keep walking :)
> > >
> > > > ...
> > > > if (scan_should_stop() || aborted)
> > > > return;
> > >
> > > And yeah, you're right. If we do lost a cursor, bailing out and
> > > skipping reporting fot that incomplete root scan should be the
> > > right thing, I guess :D
> >
> > Thanks! Under what circumstances would the cursor actually be lost?
>
> It should be race, but possible, that we happen to stop on g/p,
> drop RCU, and one of them is gone by the time we come back.
ACk, that makes sense, with that, I think this approach might be better
than the original one in this patchset. Let me play with it.
Thanks for the suggestion,
--breno