linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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