[<prev] [next>] [day] [month] [year] [list]
Message-ID: <87v92t65r1.ffs@tglx>
Date: Tue, 21 Sep 2021 22:19:46 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Stephen Boyd <sboyd@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
syzbot <syzbot+d6c75f383e01426a40b4@...kaller.appspotmail.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
syzkaller-bugs@...glegroups.com, Waiman Long <llong@...hat.com>,
"Paul E. McKenney" <paulmck@...nel.org>,
Al Viro <viro@...iv.linux.org.uk>,
Jens Axboe <axboe@...nel.dk>, linux-block@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [syzbot] WARNING in __init_work
Stephen,
On Tue, Sep 21 2021 at 11:38, Stephen Boyd wrote:
> Quoting Thomas Gleixner (2021-09-19 05:41:18)
>> Even if debug objects would support objects on irq stacks, the above is
>> still bogus. But it does not and will not because the operations here
>> have to be fully synchronous:
>>
>> init() -> queue() or arm() -> wait() -> destroy()
>>
>> because you obviously cannot queue work or arm a timer which are on stack
>> and then leave the function without waiting for the operation to complete.
>
> Is there some way to make it more obvious that initializing a timer or
> work on the stack in an irq context is a NONO because we can't wait for
> it? Maybe some sort of debugobjects call to might_sleep() when it's
> being told the object is on the stack, or throwing a might_sleep() into
> the initialization of any stack based timer or workqueue, or both?
Let me have a look.
Powered by blists - more mailing lists