linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: "Jun'ichi Nomura" <j-nomura@ce.jp.nec.com>
Cc: Neil Brown <neilb@suse.de>, Alasdair Kergon <agk@redhat.com>,
	Lars Marowsky-Bree <lmb@suse.de>,
	linux-kernel@vger.kernel.org,
	device-mapper development <dm-devel@redhat.com>
Subject: Re: [PATCH 0/3] sysfs representation of stacked devices (dm/md) (rev.2)
Date: Wed, 22 Feb 2006 10:47:29 -0800	[thread overview]
Message-ID: <20060222184729.GA13638@suse.de> (raw)
In-Reply-To: <43FC8C00.5020600@ce.jp.nec.com>

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

      parent reply	other threads:[~2006-02-22 18:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-22 16:06 [PATCH 0/3] sysfs representation of stacked devices (dm/md) (rev.2) Jun'ichi Nomura
2006-02-22 16:13 ` [PATCH 1/3] sysfs representation of stacked devices (common) (rev.2) Jun'ichi Nomura
2006-02-22 18:48   ` Greg KH
2006-02-22 22:22     ` Jun'ichi Nomura
2006-02-22 22:28       ` Greg KH
2006-02-23 19:15         ` Jun'ichi Nomura
2006-02-24  3:40           ` Greg KH
2006-02-27 16:09             ` Jun'ichi Nomura
2006-02-22 16:13 ` [PATCH 2/3] sysfs representation of stacked devices (dm) (rev.2) Jun'ichi Nomura
2006-02-22 16:34   ` Alasdair G Kergon
2006-02-22 17:13     ` Jun'ichi Nomura
2006-02-22 18:13       ` Alasdair G Kergon
2006-02-22 19:32         ` Jun'ichi Nomura
2006-02-22 16:13 ` [PATCH 3/3] sysfs representation of stacked devices (md) (rev.2) Jun'ichi Nomura
2006-02-22 18:47 ` Greg KH [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060222184729.GA13638@suse.de \
    --to=gregkh@suse.de \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=j-nomura@ce.jp.nec.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lmb@suse.de \
    --cc=neilb@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).