linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Johannes Thumshirn <jthumshirn@suse.de>
Cc: David Sterba <dsterba@suse.com>,
	Linux BTRFS Mailinglist <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 0/5] remove BUG_ON()s in btrfs_close_one_device()
Date: Tue, 12 Nov 2019 13:49:39 +0100	[thread overview]
Message-ID: <20191112124939.GW3001@twin.jikos.cz> (raw)
In-Reply-To: <20191112122416.30672-1-jthumshirn@suse.de>

On Tue, Nov 12, 2019 at 01:24:11PM +0100, Johannes Thumshirn wrote:
> This series attempts to remove the BUG_ON()s in btrfs_close_one_device().
> Therefore some reorganization of btrfs_close_one_device() and
> close_fs_devices() was needed.
> 
> Forthermore a new BUG_ON() had to be temporarily introduced but is removed
> again in the last patch of theis series.

Yeah, that's fine.

> Although it is generally legal to return -ENOMEM on umount(2), the error
> handling up until close_ctree() as neither close_ctree() nor btrfs_put_super()
> would be able to handle the error.
> 
> This series has passed fstests without any deviation from the baseline and
> also the new error handling was tested via error injection using this snippet:

This BUG_ON is one of the syzbot reports so once this patchset is
reviewed, we can ask for a retest.

I have a WIP fix that tries to avoid ENOMEM completely as it's not
strictly necessary. The empty device is like a placeholder in the list
while the real device is RCU-removed. The fix is to mark the device as
"being deleted" so it can be skipped but this is more intrusive and more
error prone than handling the error.

As this is not a frequent error at all, syzbot artifically limits the
amount of memory, otherwise we haven't seen the ENOMEM in practice. So
the fix is IMO sufficient for now.

      parent reply	other threads:[~2019-11-12 12:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-12 12:24 [PATCH 0/5] remove BUG_ON()s in btrfs_close_one_device() Johannes Thumshirn
2019-11-12 12:24 ` [PATCH 1/5] btrfs: decrement number of open devices after closing the device not before Johannes Thumshirn
2019-11-12 12:24 ` [PATCH 2/5] btrfs: handle device allocation failure in btrfs_close_one_device() Johannes Thumshirn
2019-11-12 12:24 ` [PATCH 3/5] btrfs: handle allocation failure in strdup Johannes Thumshirn
2019-11-12 12:24 ` [PATCH 4/5] btrfs: handle error return of close_fs_devices() Johannes Thumshirn
2019-11-12 12:24 ` [PATCH 5/5] btrfs: remove final BUG_ON() in close_fs_devices() Johannes Thumshirn
2019-11-12 12:41   ` Qu Wenruo
2019-11-12 12:55     ` David Sterba
2019-11-12 12:59       ` Johannes Thumshirn
2019-11-12 12:40 ` [PATCH 0/5] remove BUG_ON()s in btrfs_close_one_device() Qu Wenruo
2019-11-12 12:57   ` Johannes Thumshirn
2019-11-12 12:49 ` David Sterba [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=20191112124939.GW3001@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=dsterba@suse.com \
    --cc=jthumshirn@suse.de \
    --cc=linux-btrfs@vger.kernel.org \
    /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).