Re: [PATCH v8 04/22] Change direct_access calling convention

[Zwisler, Ross]

On Thu, 2014-07-31 at 14:30 -0600, Ross Zwisler wrote:
> On Thu, 2014-07-31 at 21:04 +0300, Boaz Harrosh wrote:
> > On 07/31/2014 08:19 PM, Matthew Wilcox wrote:
> > > On Thu, Jul 31, 2014 at 06:28:37PM +0300, Boaz Harrosh wrote:
> > >> Matthew what is your opinion about this, do we need to push for removal
> > >> of the partition dead code which never worked for brd, or we need to push
> > >> for fixing and implementing new partition support for brd?
> > > 
> > > Fixing the code gets my vote.  brd is useful for testing things ... and
> > > sometimes we need to test things that involve partitions.
> > > 
> > 
> > OK I'm on it, its what I'm doing today.
> > 
> > rrr I manged to completely trash my vm by doing 'make install' of
> > util-linux and after reboot it never recovered, I remember that
> > mount complained about a now missing library and I forgot and rebooted,
> > that was the end of that. Anyway I installed a new fc20 system wanted
> > that for a long time over my old fc18
> 
> Ah, I'm already working on this as well.  :)  If you want you can wait for my
> patches to BRD & test - they should be out this week.
> 
> I'm planning on adding get_geo() and doing dynamic minors as is done in NVMe.

Ugh, it turns out that if you remove the "*part = 0" bit from brd_probe(),
attempts to create new BRD devices using mknod hit a deadlock.  Removal of
that code, ie:

@@ -550,7 +549,6 @@ static struct kobject *brd_probe(dev_t dev, int *part, void *data)
        kobj = brd ? get_disk(brd->brd_disk) : NULL;
        mutex_unlock(&brd_devices_mutex);

-       *part = 0;
        return kobj;
 }

is necessary if we want to do any sort of partitioning.

This isn't a use case for PRD, so I'll move over to that and try to add
dynamic minors there instead.  If we really do want partitions to work in BRD,
though, eventually we'll have to debug the deadlock.

- Ross