Message ID | 20241108104217.3759904-1-bigeasy@linutronix.de (mailing list archive) |
---|---|
Headers | show |
Series | scftorture: Avoid kfree from IRQ context. | expand |
On Fri, Nov 08, 2024 at 11:39:30AM +0100, Sebastian Andrzej Siewior wrote: > Hi, > > Paul reported kfree from IRQ context in scftorture which is noticed by > lockdep since the recent PROVE_RAW_LOCK_NESTING switch. > > The last patch in this series adresses the issues, the other things > happened on the way. > > v2...v3: > - The clean up on module exit must not be done with thread numbers. > Reported by Boqun Feng. > - Move the clean up on module exit prior to torture_cleanup_end(). > Reported by Paul. > > v1...v2: > - Remove kfree_bulk(). I get more invocations per report without it. > - Pass `cpu' to scf_cleanup_free_list in scftorture_invoker() instead > of scfp->cpu. The latter is the thread number which can be larger > than the number CPUs leading to a crash in such a case. Reported by > Boqun Feng. > - Clean up the per-CPU lists on module exit. Reported by Boqun Feng. > > Sebastian > For the whole series: Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Regards, Boqun
On Fri, Nov 08, 2024 at 09:46:07AM -0800, Boqun Feng wrote: > On Fri, Nov 08, 2024 at 11:39:30AM +0100, Sebastian Andrzej Siewior wrote: > > Hi, > > > > Paul reported kfree from IRQ context in scftorture which is noticed by > > lockdep since the recent PROVE_RAW_LOCK_NESTING switch. > > > > The last patch in this series adresses the issues, the other things > > happened on the way. > > > > v2...v3: > > - The clean up on module exit must not be done with thread numbers. > > Reported by Boqun Feng. > > - Move the clean up on module exit prior to torture_cleanup_end(). > > Reported by Paul. > > > > v1...v2: > > - Remove kfree_bulk(). I get more invocations per report without it. > > - Pass `cpu' to scf_cleanup_free_list in scftorture_invoker() instead > > of scfp->cpu. The latter is the thread number which can be larger > > than the number CPUs leading to a crash in such a case. Reported by > > Boqun Feng. > > - Clean up the per-CPU lists on module exit. Reported by Boqun Feng. > > > > Sebastian > > > > For the whole series: > > Reviewed-by: Boqun Feng <boqun.feng@gmail.com> > Tested-by: Boqun Feng <boqun.feng@gmail.com> Thank you both! Sebastian, I am guessing that the Kconfig change exposing the bugs fixed by your series is headed to mainline for the upcoming merge window? If so, I should of course push these in as well. Thanx, Paul
On 2024-11-08 10:33:29 [-0800], Paul E. McKenney wrote: > Sebastian, I am guessing that the Kconfig change exposing the bugs fixed > by your series is headed to mainline for the upcoming merge window? Yes. It is in tip/locking/core. > If so, I should of course push these in as well. That would be nice ;) > Thanx, Paul Sebastian
On Fri, Nov 08, 2024 at 07:45:10PM +0100, Sebastian Andrzej Siewior wrote: > On 2024-11-08 10:33:29 [-0800], Paul E. McKenney wrote: > > Sebastian, I am guessing that the Kconfig change exposing the bugs fixed > > by your series is headed to mainline for the upcoming merge window? > > Yes. It is in tip/locking/core. > > > If so, I should of course push these in as well. > > That would be nice ;) Very well, I have started testing and if that goes well (as I expect that it will), I will rebase them and put them into -next. Thanx, Paul