Re: New Patch series for the UBD Driver

From: Jens Axboe <axboe@kernel.dk>
To: Anton Ivanov <anton.ivanov@cambridgegreys.com>,
	linux-um@lists.infradead.org
Cc: richard@nod.at, hch@lst.de
Subject: Re: New Patch series for the UBD Driver
Date: Mon, 12 Nov 2018 11:04:35 -0700	[thread overview]
Message-ID: <880075e6-1032-fe4f-0001-085d7409eb54@kernel.dk> (raw)
In-Reply-To: <58614d39-8c3b-4e8e-7b41-633bb52b533e@cambridgegreys.com>

On 11/12/18 11:00 AM, Anton Ivanov wrote:
> 
> On 11/12/18 5:50 PM, Jens Axboe wrote:
>> On 11/12/18 10:41 AM, anton.ivanov@cambridgegreys.com wrote:
>>> This is the revised patchset for the ubd driver. Known issues:
>>>
>>> 1. If an error is returned to an operation different from READ/WRITE/SYNC
>>> the block subsystem goes south finishing with a crash. I have tried everything
>>> I can think of and whatever I could lift out of the loop and nbd driver. I do
>>> not think that the problem is in the ubd driver. I am lost here, Jens can you
>>> please give me a hand in handling the case when ubd_handler() gets an error in
>>> reply to a discard.
>> It would help if you showed a crash from doing that, and an example of
>> how you are doing that.
> 
> Test case - 1G ext4 image on MS DOS filesystem.
> 
> With the present patch, the logic around line 844 should be commented 
> out so that DISCARD is always enabled. I can send a patch where this is 
> always enabled for testing purposes.
> 
> Mount filesystem - mount /dev/ubdb /mnt
> 
> Try fstrim /mnt
> 
> Crash is immediate,  but different in each case.
> 
> Some cases contain the WARN from line 439 in blk.h . Some contain 
> spinlock recursion BUG(). Some do not contain anything - it just 
> crashes. Or hangs.
> 
> I tried various combinations (and code theft from loop and nbd) of 
> blk_update_request, __blk_mq_end_request, blk_mq_end_request, etc - the 
> flavor of the crash changes a bit, but not the essence.

Sorry, all of this isn't very clear to me. It definitely sounds like
you are doing something wrong. Where are you calling falloc_punch()
from? It's not even safe from ->queue_rq(), you'd need to add
BLK_MQ_F_BLOCKING to your mq_ops flags to ensure that blk-mq
always calls you from a context that can block. If you're doing
it from the irq handler, well then...

> Firsts question - is any of that expected to be invoked out of an 
> interrupt handler in the first place?

What is "that" here?

-- 
Jens Axboe

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um