[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44ab9f7d-8f00-5f80-210e-f65f02f6fd82@nvidia.com>
Date: Wed, 7 Sep 2022 14:40:57 +0000
From: Chaitanya Kulkarni <chaitanyak@...dia.com>
To: "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-raid@...r.kernel.org" <linux-raid@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: Dusty Mabe <dusty@...tymabe.com>, Christoph Hellwig <hch@....de>,
Jens Axboe <axboe@...nel.dk>, Ming Lei <ming.lei@...hat.com>
Subject: Re: regression caused by block: freeze the queue earlier in
del_gendisk
Hi all,
On 9/7/22 01:38, Ming Lei wrote:
> On Wed, Sep 07, 2022 at 09:33:24AM +0200, Christoph Hellwig wrote:
>> On Thu, Sep 01, 2022 at 03:06:08PM +0800, Ming Lei wrote:
>>> It is a bit hard to associate the above commit with reported issue.
>>
>> So the messages clearly are about something trying to open a device
>> that went away at the block layer, but somehow does not get removed
>> in time by udev (which seems to be a userspace bug in CoreOS). But
>> even with that we really should not hang.
>
> The new device should be allocated from md_probe() via blk_request_module(),
> and the underlying devices are virtio-blk from the fedora BZ2121791.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2121791
>
> Thanks,
> Ming
>
It would be really helpful if mdraid experts can write blktests so it
will get tested in the nightly builds along with other tests with
different distros.
-ck
Powered by blists - more mailing lists