linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.com>,
	Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <chao@kernel.org>,
	linux-f2fs-devel@lists.sourceforge.net,
	syzbot <syzbot+20d7e439f76bbbd863a7@syzkaller.appspotmail.com>,
	Oleg Nesterov <oleg@redhat.com>,
	Mateusz Guzik <mjguzik@gmail.com>,
	paulmck@kernel.org, Hillf Danton <hdanton@sina.com>,
	rcu@vger.kernel.org, frank.li@vivo.com,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	syzkaller-bugs@googlegroups.com, viro@zeniv.linux.org.uk
Subject: Re: [syzbot] [f2fs?] WARNING in rcu_sync_dtor
Date: Mon, 29 Jul 2024 09:58:47 -0400	[thread overview]
Message-ID: <20240729135847.GB557749@mit.edu> (raw)
In-Reply-To: <20240729132721.hxih6ehigadqf7wx@quack3>

On Mon, Jul 29, 2024 at 03:27:21PM +0200, Jan Kara wrote:
> 
> So in ext4 we have EXT4_FLAGS_SHUTDOWN flag which we now use
> internally instead of SB_RDONLY flag for checking whether the
> filesystem was shutdown (because otherwise races between remount and
> hitting fs error were really messy). However we still *also* set
> SB_RDONLY so that VFS bails early from some paths which generally
> results in less error noise in kernel logs and also out of caution
> of not breaking something in this path. That being said we also
> support EXT4_IOC_SHUTDOWN ioctl for several years and in that path
> we set EXT4_FLAGS_SHUTDOWN without setting SB_RDONLY and nothing
> seems to have blown up. So I'm inclined to belive we could remove
> setting of SB_RDONLY from ext4 error handling. Ted, what do you
> think?

Well, there are some failures of generic/388 (which involves calling
the shutdown ioctl while running fsstress).  I believe that most of
those failures are file system corruption errors, as opposed to other
sorts of failures, but we don't run KASAN kernels all that often,
especially since generic/388 is now on the exclude list.

The failure rate of generic/388 varies depending on the storage device
involved, but it varies from less than 10% to 50% of the time, if
memory serves correctly.  Since EXT4_IOC_SHUTDOWN is used most of the
time as a debugging/test (although there are some users use it in
production, but the failure rate when you're not doing something
really aggressive like fsstress is very small), this has been on the
"one of these days, when we have tons of free time, we should really
look into this.  The challenge is fixing this in a way that doesn't
involve adding new locking in various file system hotpaths.

So "nothing seems to have blown up" might be a bit strong.  But it's
something we can try doing, and see whether it results in more rather
than less syzbot complaints.

> Also as the "filesystem shutdown" is spreading across multiple
> filesystems, I'm playing with the idea that maybe we could lift a
> flag like this to VFS so that we can check it in VFS paths and abort
> some operations early.  But so far I'm not convinced the gain is
> worth the need to iron out various subtle semantical differences of
> "shutdown" among filesystems.

I think that might be a good idea.  Hopefully subtle semantic
differences are ones that won't matter in terms of the VFS aborting
operations early.

						- Ted

  reply	other threads:[~2024-07-29 13:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-26  7:54 [syzbot] [f2fs?] WARNING in rcu_sync_dtor syzbot
2024-07-26 15:23 ` syzbot
2024-07-29  9:10   ` Christian Brauner
2024-07-29 13:27     ` Jan Kara
2024-07-29 13:58       ` Theodore Ts'o [this message]
2024-07-30 12:38         ` Jan Kara
2024-08-01 22:28       ` Dave Chinner
2024-09-11  1:48 ` Chao Yu
2024-09-11  2:12   ` syzbot

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=20240729135847.GB557749@mit.edu \
    --to=tytso@mit.edu \
    --cc=brauner@kernel.org \
    --cc=chao@kernel.org \
    --cc=frank.li@vivo.com \
    --cc=hdanton@sina.com \
    --cc=jack@suse.com \
    --cc=jack@suse.cz \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjguzik@gmail.com \
    --cc=oleg@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=syzbot+20d7e439f76bbbd863a7@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).