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 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.