From: Wols Lists <antlists@youngman.org.uk>
To: Song Liu <liu.song.a23@gmail.com>,
"Guilherme G. Piccoli" <gpiccoli@canonical.com>
Cc: linux-block@vger.kernel.org,
linux-raid <linux-raid@vger.kernel.org>,
dm-devel@redhat.com, axboe@kernel.dk,
Gavin Guo <gavin.guo@canonical.com>,
Jay Vosburgh <jay.vosburgh@canonical.com>,
kernel@gpiccoli.net, Ming Lei <ming.lei@redhat.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
stable@vger.kernel.org
Subject: Re: [PATCH 2/2] md/raid0: Do not bypass blocking queue entered for raid0 bios
Date: Wed, 8 May 2019 10:29:22 +0100 [thread overview]
Message-ID: <5CD2A172.4010302@youngman.org.uk> (raw)
In-Reply-To: <CAPhsuW6ahmkUhCgns=9WHPXSvYefB0Gmr1oB7gdZiD86sKyHFg@mail.gmail.com>
On 06/05/19 22:07, Song Liu wrote:
> Could you please run a quick test with raid5? I am wondering whether
> some race condition could get us into similar crash. If we cannot easily
> trigger the bug, we can process with this version.
Bear in mind I just read the list and write documentation, but ...
My gut feeling is that if it can theoretically happen for all raid
modes, it should be fixed for all raid modes. What happens if code
changes elsewhere and suddenly it really does happen for say raid-5?
On the other hand, if fixing it in md.c only gets tested for raid-0, how
do we know it will actually work for other raids if they do suddenly
start falling through.
Academic purity versus engineering practicality :-)
Cheers,
Wol
next prev parent reply other threads:[~2019-05-08 9:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-30 22:37 [PATCH 1/2] block: Fix a NULL pointer dereference in generic_make_request() Guilherme G. Piccoli
2019-04-30 22:37 ` [PATCH 2/2] md/raid0: Do not bypass blocking queue entered for raid0 bios Guilherme G. Piccoli
2019-05-06 16:50 ` Song Liu
2019-05-06 18:48 ` Guilherme G. Piccoli
2019-05-06 21:07 ` Song Liu
2019-05-07 21:51 ` Guilherme G. Piccoli
2019-05-08 9:29 ` Wols Lists [this message]
2019-05-08 14:52 ` Guilherme G. Piccoli
2019-05-08 16:52 ` Wols Lists
2019-05-17 16:19 ` Guilherme G. Piccoli
2019-05-20 16:23 ` Song Liu
2019-05-20 19:25 ` Guilherme Piccoli
2019-04-30 22:55 ` [PATCH 1/2] block: Fix a NULL pointer dereference in generic_make_request() Bart Van Assche
2019-05-17 3:33 ` Eric Ren
2019-05-17 16:17 ` Guilherme G. Piccoli
2019-05-20 2:43 ` Eric Ren
2019-05-17 22:04 ` Ming Lei
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=5CD2A172.4010302@youngman.org.uk \
--to=antlists@youngman.org.uk \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=gavin.guo@canonical.com \
--cc=gpiccoli@canonical.com \
--cc=jay.vosburgh@canonical.com \
--cc=kernel@gpiccoli.net \
--cc=linux-block@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=liu.song.a23@gmail.com \
--cc=ming.lei@redhat.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=stable@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).