From: Josef Bacik <josef@toxicpanda.com>
To: Aditya Pakki <pakki001@umn.edu>
Cc: kjlu@umn.edu, Chris Mason <clm@fb.com>,
David Sterba <dsterba@suse.com>,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] btrfs: remove BUG_ON used as assertions
Date: Wed, 18 Dec 2019 11:38:18 -0500 [thread overview]
Message-ID: <2f9d6549-47cf-fb71-3bff-50b51093e757@toxicpanda.com> (raw)
In-Reply-To: <20191215171237.27482-1-pakki001@umn.edu>
On 12/15/19 12:12 PM, Aditya Pakki wrote:
> alloc_extent_state_atomic() allocates extents via GFP_ATOMIC flag
> and cannot fail. There are multiple invocations of BUG_ON on the
> return value to check for failure. The patch replaces certain
> invocations of BUG_ON by returning the error upstream.
>
> Signed-off-by: Aditya Pakki <pakki001@umn.edu>
I already tried this a few months ago and gave up. There are a few things if
you want to tackle something like this
1) use bpf's error injection thing to make sure you handle every path that can
error out. This is the script I wrote to do just that
https://github.com/josefbacik/debug-scripts/blob/master/error-injection-stress.py
2) We actually can't fail here. We would need to go back and make _all_ callers
of lock_extent_bits() handle the allocation error. This is theoretically
possible, but a giant pain in the ass. In general we can make allocations here
and we need to be able to make them.
3) We should probably mark this path with __GFP_NOFAIL because again, this is
locking and we need locking to succeed.
Thanks,
Josef
next prev parent reply other threads:[~2019-12-18 16:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-15 17:12 Aditya Pakki
2019-12-15 17:42 ` Nikolay Borisov
2019-12-18 16:31 ` David Sterba
2019-12-18 16:38 ` Josef Bacik [this message]
2019-12-18 16:47 ` David Sterba
2019-12-18 19:54 ` Josef Bacik
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=2f9d6549-47cf-fb71-3bff-50b51093e757@toxicpanda.com \
--to=josef@toxicpanda.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=kjlu@umn.edu \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pakki001@umn.edu \
/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
all inboxes | Powered by JetHome®