On Mon, Sep 07, 2026 at 07:57:15PM +0200, Oleg Nesterov wrote:
> On 09/07, Gregory Price wrote:
> >
> > On Mon, Sep 07, 2026 at 04:13:31PM +0800, Ye Liu wrote:
> > > --- a/kernel/hung_task.c
> > > +++ b/kernel/hung_task.c
> > > @@ -315,13 +315,12 @@ static void
> > > check_hung_uninterruptible_tasks(unsigned long timeout)
> > > return;
> > >
> > > this_round_count = 0;
> > > - rcu_read_lock();
> > > - for_each_process_thread(g, t) {
> > > + for_each_process_thread_rculock(g, t) {
> > > if (!max_count--)
> > > - goto unlock;
> > > + goto out;
> > ... snip ...
> > > - unlock:
> > > - rcu_read_unlock();
> > > -
> > > +out:
> > > if (!this_round_count)
> > > return;
> > >
> >
> > The sunken rcu_read_lock()/unlock() + scoped_guard usage makes this goto
> > at a minimum very confusing, if not actually broken.
>
> I am afraid I misunderstood you concerns...
>
This might be my - admittedly shallow - understanding of scoped_guard,
but does scoped guard handle goto correctly?
On the surface it looks like it would skip the unlock entirely.
That is what i mean by "at a minimum very confusing, if not broken"
and why it's generally discouraged to mix cleanup.h and goto.
~Gregory
