Re: [PATCH] Allow userspace block device implementation [LWN.net]

From:		Zachary Amsden <zamsden-AT-redhat.com>
To:		Tejun Heo <tj-AT-kernel.org>
Subject:		Re: [PATCH] Allow userspace block device implementation
Date:		Mon, 27 Jul 2009 17:53:50 -1000
Message-ID:		<4A6E764E.80805@redhat.com>
Cc:		Alan Cox <alan-AT-lxorguk.ukuu.org.uk>, Peter Zijlstra <peterz-AT-infradead.org>, linux-kernel-AT-vger.kernel.org, torvalds-AT-linux-foundation.org, axboe-AT-kernel.dk, hch-AT-infradead.org, akpm-AT-linux-foundation.org, Paul.Clements-AT-steeleye.com, tytso-AT-mit.edu, miklos <miklos-AT-szeredi.hu>
Archive‑link:		Article

Tejun Heo wrote:
> Hello,
> 
> Alan Cox wrote:
>>> Somehow this made me think of FUSE/CUSE... should this be named aBUSE?
>>> Oh wait it is :-), what I'm after is I guess is, can we share some of
>>> the FUSE/CUSE code?
>> It reminds me of the existing and perfectly functional network block
>> device (nbd) we already have and which has also been present for years.
> 
> Yeah, I think this is the biggest hurdle against (a)BUSE.  Is it
> sufficiently different from nbd?  nbd-like functionality can be
> implemented something via FUSE and maybe it can be said that things
> are cleaner that way but nbd has been in the kernel for a long time
> now and it's definitely much easier to do swap over it when the whole
> thing is in kernel.

The only real difference from this and the nbd is that the nbd is
explicitly connection oriented, while this is intentionally
connectionless.  That was an interesting property, but turned out to be
not to be the best for what I was trying to do.

I'm actually going to go ahead and use nbd instead.  All I need a block
device that supports partitions with a userspace driver.

So maybe someone will find this useful, for now it is preserved in LKML
archives and the patch should continue to apply for some time.

BTW, implementing something like this via FUSE would be extremely
unpleasant.  I'd need another layer on top, probably via the loop
device, to get to the actual partitions of the block devices.

Zach

to post comments

Re: [PATCH] Allow userspace block device implementation

Posted Jan 30, 2018 12:44 UTC (Tue) by korneliuszo (guest, #122263) [Link]

First glance, combination of all bad practices from different parts implemented on saned interfaces.

Looks like it could run even swap ... if
- userspace won't swap out on backed by abuse'd interface.
- no forced preemption enabled? (preempt in spinlock(taken mutex) on getabuse, second thread in make_request(no mutex) (does even here mutex needed/spinlock used only on list operations (rewritten ops from scratch ... docs says spinlock bad think rcu ... and also AFAIR there were macros for list defining and handling)))
- wake_up before spin_unlock? not sure but smells like can hang when ctrl process has lower prio than block operation (other places also smells like race conditions)

Whole bio_list list smells like duplicating ab_queue data ... abusing hidden linked list.
pktcdvd has done this via copy of bio for new linked list!
There is need to clone and add clone to seperate lists for pending for getabuse and pending for putabuse. (Like 3 states in v4l2 buffers) Or just get bio from one list and move it to another? only putabuse would need lookup in queue. (userspace can reorder incoming replies)

Not fully sure need to spend a little more time.

Korneliusz