Re: [PATCH 0/3] sysfs representation of stacked devices (dm/md) (rev.2)

[Greg KH <gregkh@suse.de>]

On Wed, Feb 22, 2006 at 11:06:24AM -0500, Jun'ichi Nomura wrote:
> Hello,
> 
> This is a revised set of pathces which provides common
> representation of dependencies between stacked devices (dm and md)
> in sysfs.
> 
> Variants of bd_claim/bd_release are added to accept a kobject
> and create symlinks between the claimed bdev and the holder.
> 
> dm/md will give a child of its gendisk kobject to bd_claim.
> For example, if dm-0 maps to sda, we have the following symlinks;
>    /sys/block/dm-0/slaves/sda --> /sys/block/sda
>    /sys/block/sda/holders/dm-0 --> /sys/block/dm-0
> 
> Comments are welcome.
> 
> A few points I would appreciate comments/reviews from maintainers:
>   About sysfs
>     - I confirmed sysfs_remove_symlink() and kobject_del() don't
>       allocate memory in 2.6.15 and it seems true on the git head.
>       I would like to make sure it's true in future versions of kernel
>       because they are called during device-mapper's table swapping
>       where I/O to free memory could deadlock on the dm device.
>       What is the recommended way to do that?

But it can possibly sleep.

Hm, wait, the put_device stuff can possibly sleep, the "raw"
kobject_del() stuff looks safe.  Either way, they don't create new
memory, unless you do something really wierd in your release callback.

So you should be safe here.

But if you want to be absolutly safe, look at the thread on lkml about
changing the scsi code to do the final release in a non-interrupt
context.  That looks like it might be the same thing you want to do
here to guarantee that nothing bad happens.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/