Re: [BUG 2.6.17-git] kmem_cache_create: duplicate cache scsi_cmd_cache

[Al Viro <viro@ftp.linux.org.uk>]

On Fri, May 12, 2006 at 04:04:53PM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 12 May 2006, Al Viro wrote:
> > 
> > PS: it _is_ OK to trigger than puppy from add_disk()/del_gendisk() and in
> > between.  I'm not sure if anyone needs it for anything, though.  Triggering
> > it from bdev_uevent() is definitely bogus.
> 
> Wouldn't it be perfectly ok if we just made sure to keep the disk device 
> refcount elevated by the _mount_?
> 
> Ie Russell's patch to elevate it around everything didn't work, but 
> elevating the bdev->bd_disk reference count by a mount, and dropping it on 
> umount (after doing the umount event) should be ok. No?

->bd_disk _is_ pinned down.  However, it's not the problem - we keep
gendisk for as long as anyone uses it.  Which might be after the underlying
object is gone; that one is controlled by driver and driver calls
del_gendisk() when it decides that we are through.

The problem is with disk->driverfs_dev, not disk itself.  Block layer
has no fscking business touching it after del_gendisk() - if nothing else,
we might have _no_ underlying object at all from the very beginning.

So anything that wants events related to partitions, let alone mounting,
can't expect to see PHYSDEV... crap.  Moreover, it can bloody well
get to PHYSDEV... itself *if* it wants to and if it's there.  There's
a reason why we have that symlink in sys/block/<device> and userland can
bloody well access it on its own.