Re: [PATCH 0/2] mm: kmemleak: avoid long RCU read-side sections in reports

[Weilin Tong <tongweilin@linux.alibaba.com>]

Hi Andrew,

Thanks for the review.

Yes, this was observed while reading /sys/kernel/debug/kmemleak on
our downstream distribution's 6.6-based debug kernel, without injected
delays. Here are excerpts from the original log:

[1023772.105996] rcu: INFO: rcu_preempt self-detected stall on CPU
[1023772.152485] rcu: 	(t=65047 jiffies g=357990333 q=711371 ncpus=96)
[1023772.491019]  get_object+0x1e/0x70
[1023772.501186]  kmemleak_seq_next+0x91/0xe0
[1023772.512982]  seq_read_iter+0x482/0x1160

With CONFIG_HZ=1000, the grace period had lasted about 65 seconds.
I should have included this evidence in the cover letter.

You're right about *pos: it does not advance when get_object() fails,
so an unaligned position can miss the periodic checks throughout the
skip loop. Our deleted-chain tests checked safety, but missed this
progress issue.

I'll address this in v2, preserving safe traversal across concurrent
deletion, and add targeted coverage for this case.

Thanks,
Weilin