[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2f956a72-7704-6394-4408-26c3f502524e@nvidia.com>
Date: Wed, 7 Sep 2022 15:53:13 +0000
From: Chaitanya Kulkarni <chaitanyak@...dia.com>
To: Ming Lei <ming.lei@...hat.com>
CC: "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>
Subject: Re: regression caused by block: freeze the queue earlier in
del_gendisk
On 9/7/22 07:58, Ming Lei wrote:
> On Wed, Sep 07, 2022 at 02:40:57PM +0000, Chaitanya Kulkarni wrote:
>> 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.
>
> Can't agree more, and Cc linux-raid and our raid guys.
>
along with linux-block, Shin'ichiro and me.
-ck
Powered by blists - more mailing lists