[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f593d3ac-b28e-3593-3cd8-8983b27e47a7@I-love.SAKURA.ne.jp>
Date: Wed, 30 Mar 2022 11:49:07 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Dominique Martinet <asmadeus@...ewreck.org>
Cc: Andrew Perepechko <andrew.perepechko@....com>,
Andreas Dilger <adilger@...ger.ca>,
"Theodore Ts'o" <tytso@....edu>,
syzbot <syzbot+bde0f89deacca7c765b8@...kaller.appspotmail.com>,
linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
v9fs-developer@...ts.sourceforge.net,
"open list:EXT4 FILE SYSTEM" <linux-ext4@...r.kernel.org>
Subject: Re: [syzbot] possible deadlock in p9_write_work
On 2022/03/30 11:29, Dominique Martinet wrote:
> Tetsuo Handa wrote on Wed, Mar 30, 2022 at 10:57:15AM +0900:
>>>> Please don't use schedule_work() if you need to use flush_scheduled_work().
>>>
>>> In this case we don't call flush_scheduled_work -- ext4 does.
>>
>> Yes, that's why I changed recipients to ext4 people.
>
> Sorry, I hadn't noticed.
> 9p is the one calling schedule_work, so ultimately it really is the
> combinaison of the two, and not just ext4 that's wrong here.
Calling schedule_work() itself does not cause troubles (unless there are
too many pending works to make progress). Calling flush_scheduled_work()
causes troubles because it waits for completion of all works even if
some of works cannot be completed due to locks held by the caller of
flush_scheduled_work(). 9p is innocent for this report.
Powered by blists - more mailing lists