On 09/07, Gregory Price wrote:
>
> 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?
Yes, it does,
> and why it's generally discouraged to mix cleanup.h and goto.
Hmm, why? I didn't know...
Oleg.
