From: Dominique Martinet <asmadeus@codewreck.org>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Andrew Perepechko <andrew.perepechko@hpe.com>,
Andreas Dilger <adilger@dilger.ca>, Theodore Ts'o <tytso@mit.edu>,
syzbot <syzbot+bde0f89deacca7c765b8@syzkaller.appspotmail.com>,
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
v9fs-developer@lists.sourceforge.net,
"open list:EXT4 FILE SYSTEM" <linux-ext4@vger.kernel.org>
Subject: Re: [syzbot] possible deadlock in p9_write_work
Date: Wed, 30 Mar 2022 08:51:21 +0900 [thread overview]
Message-ID: <YkObebLZMp5AyRpr@codewreck.org> (raw)
In-Reply-To: <385ce718-f965-4005-56b6-34922c4533b8@I-love.SAKURA.ne.jp>
Tetsuo Handa wrote on Wed, Mar 30, 2022 at 07:35:47AM +0900:
> This seems to be an example of
> https://lkml.kernel.org/r/49925af7-78a8-a3dd-bce6-cfc02e1a9236@I-love.SAKURA.ne.jp
> introduced by "ext4: truncate during setxattr leads to kernel panic".
Thanks for the pointer
> 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.
The problem is mixing in the two subsystems when someone (e.g. syzbot)
opens an ext4 file and passes that fd to 9p when mounting with e.g.
mount -t 9p -o rfdno=<no>,wfdno=<no>
Frankly that's just not something I consider useful, interacting through
9p to a local file doesn't make sense except for testing.
If that is a real problem, the simplest way out would be to just forbid
non-socket FDs if it's something we can check.
--
Dominique
next prev parent reply other threads:[~2022-03-29 23:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-29 21:23 [syzbot] possible deadlock in p9_write_work syzbot
2022-03-29 22:05 ` asmadeus
2022-03-29 22:35 ` Tetsuo Handa
2022-03-29 23:51 ` Dominique Martinet [this message]
2022-03-30 1:57 ` Tetsuo Handa
2022-03-30 2:29 ` Dominique Martinet
2022-03-30 2:49 ` Tetsuo Handa
[not found] ` <PH7PR84MB167995181252E4B7E4541B64F51F9@PH7PR84MB1679.NAMPRD84.PROD.OUTLOOK.COM>
2022-03-30 23:43 ` Tetsuo Handa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YkObebLZMp5AyRpr@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=adilger@dilger.ca \
--cc=andrew.perepechko@hpe.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=syzbot+bde0f89deacca7c765b8@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tytso@mit.edu \
--cc=v9fs-developer@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.