From: "Theodore Ts'o" <tytso@mit.edu>
To: syzbot <syzbot+18b2ab4c697021ee8369@syzkaller.appspotmail.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
syzkaller-bugs@googlegroups.com, viro@zeniv.linux.org.uk,
Christian Brauner <brauner@kernel.org>
Subject: Re: INFO: task hung in do_truncate (2)
Date: Mon, 1 May 2023 14:59:55 -0400 [thread overview]
Message-ID: <20230501185955.GA604757@mit.edu> (raw)
In-Reply-To: <0000000000003fa24b05b84a0886@google.com>
On Wed, Jan 06, 2021 at 11:03:09PM -0800, syzbot wrote:
> syzbot suspects this issue was fixed by commit:
>
> commit dfefd226b0bf7c435a58d75a0ce2f9273b9825f6
> Author: Alexey Dobriyan <adobriyan@gmail.com>
> Date: Tue Dec 15 03:15:03 2020 +0000
>
> mm: cleanup kstrto*() usage
This is a nonsense bisect result; I've filed a bug against syzbot[1].
[1] https://github.com/google/syzkaller/issues/3855
Looking more closely at this reproducer, it looks like it is setting
up a and configuring userfaultd on a large number of threads:
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x11ad690)
res = syscall(__NR_userfaultfd, 0ul);
syscall(__NR_ioctl, r[0], UFFDIO_API, {api=0xaa, features=0, ... });
syscall(__NR_ioctl, -1, PPPIOCGMRU, 0ul) returns -EBADF
(don't know why the syzbot minimizer didn't get rid of this...)
syscall(__NR_ioctl, r[0], UFFDIO_REGISTER, {range={start=0x20909000, len=0x4000}, mode=UFFDIO_REGISTER_MODE_MISSING ...)
...
It does this in a tight loop, spawning many threads each time, and
while it doesen't always end up reporting an rcu preempt stall, and
locking up the kernel, I have manage to trigger a similar crash when
the underlying file system is btrfs, with the stack traces being
similar. So I don't believe it is an ext4-specific bug.
#syz set subsystems: fs
I'm not an expert on userfaultd, but I'm not at all convinced what
this reproducer is doing is valid and it may be a "root an screw
itself" kind of issue. Maybe someone who knows more about userfaultfd
can comment?
There is a C reproducer[2], but it suffers from the standard
obfuscation via ultra-non-portable-C-so-much-it-might-as- well-be-asm
problem. The syzbot dashboard page for this can be found here[3].
[2] https://syzkaller.appspot.com/text?tag=ReproC&x=153a741e100000
[3] https://syzkaller.appspot.com/bug?id=d38f8eae55e27aaef60b4748bc77ecb712dba4b9
Thanks,
- Ted
prev parent reply other threads:[~2023-05-01 19:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-11 4:48 INFO: task hung in do_truncate (2) syzbot
2021-01-07 7:03 ` syzbot
2023-05-01 18:59 ` Theodore Ts'o [this message]
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=20230501185955.GA604757@mit.edu \
--to=tytso@mit.edu \
--cc=brauner@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzbot+18b2ab4c697021ee8369@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).