From: Luis Chamberlain <mcgrof@kernel.org>
To: Bart Van Assche <bvanassche@acm.org>
Cc: axboe@kernel.dk, ming.lei@redhat.com, yukuai3@huawei.com,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC v1 0/6] block: add error handling for *add_disk*()
Date: Sat, 9 May 2020 03:43:12 +0000 [thread overview]
Message-ID: <20200509034312.GH11244@42.do-not-panic.com> (raw)
In-Reply-To: <896ca55e-0daa-fb62-f9cb-0714389936a5@acm.org>
On Tue, May 05, 2020 at 06:18:22PM -0700, Bart Van Assche wrote:
> On 2020-04-29 00:48, Luis Chamberlain wrote:
> > While working on some blktrace races I noticed that we don't do
> > error handling on *add_disk*() and friends. This is my initial
> > work on that.
> >
> > This is based on linux-next tag next-20200428, you can also get this
> > on my branch 20200428-block-fixes [0].
> >
> > Let me know what you think.
> Hi Luis,
>
> Thank you for having done this work.
My pleasure, I just made one minor change to this series, but that's
all so far. Note that break-blktrace run_0004.sh still yields:
debugfs: Directory 'loop0' with parent 'block' already present!
And so I suspect something else is up, this is even after. That's using
my latest:
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20200508-block-fixes
Some more eyebealls on that would be useful.
> Since triggering error paths can be
> challenging, how about adding fault injection capabilities that make it
> possible to trigger all modified error paths and how about adding
> blktests that trigger these paths? That is the strategy that I followed
> myself recently to fix an error path in blk_mq_realloc_hw_ctxs().
Sure thing, but I get the impression that adding this may make it odd
to or harder to review. Shouldn't this be done after we have *some*
error handling? Right now we shouldn't regress as we never fail, and
that seemss worse.
Let me know, either way, I'll start work on it.
Luis
prev parent reply other threads:[~2020-05-09 3:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-29 7:48 [RFC v1 0/6] block: add error handling for *add_disk*() Luis Chamberlain
2020-04-29 7:48 ` [RFC v1 1/6] block: refcount the request_queue early in __device_add_disk() Luis Chamberlain
2020-04-29 7:48 ` [RFC v1 2/6] block: move disk announce work from register_disk() to a helper Luis Chamberlain
2020-04-29 7:48 ` [RFC v1 3/6] block: move disk invalidation from del_gendisk() into " Luis Chamberlain
2020-04-29 7:48 ` [RFC v1 4/6] block: move disk unregistration work from del_gendisk() to " Luis Chamberlain
2020-04-29 7:48 ` [RFC v1 5/6] block: add initial error handling for *add_disk()* and friends Luis Chamberlain
2020-04-29 7:48 ` [RFC v1 6/6] loop: add error handling support for add_disk() Luis Chamberlain
2020-05-06 1:18 ` [RFC v1 0/6] block: add error handling for *add_disk*() Bart Van Assche
2020-05-09 3:43 ` Luis Chamberlain [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=20200509034312.GH11244@42.do-not-panic.com \
--to=mcgrof@kernel.org \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=yukuai3@huawei.com \
/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.