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

[Linus Torvalds]

On Fri, 12 May 2006, Greg KH wrote:
> 
> No, I don't know, that's why I just asked :)
> 
> And this bug doesn't have anything to do with why my mmc/sd cards are
> suddenly not showing up at all anymore in my laptop, right?  I need to
> track that regression from 2.6.17-rc1 down...

Well, that's certainly an interesting regression to look into too..

Here's all I know as back-ground.. Russell's patch certainly _looked_ ok, 
which is why it then got acked and merged, but that was before we had 
multiple people reporting that it breaks things for them.

		Linus

--
On Thu, 4 May 2006, Russell King wrote:
>
> Linus,
> 
> This has been confirmed to fix an issue which Mikkel discovered, and
> I'm now seeing reports from other people about this.
> 
> I'm not getting any response on it from either Al or Jens and it
> appears to be otherwise ignored - help!  Would you take this patch
> direct from me?
> 
> ----- Forwarded message from Russell King <rmk+lkml@xxxxxxxxxxxxxxxx> -----
> 
> Date:	Fri, 7 Apr 2006 15:40:46 +0100
> From:	Russell King <rmk+lkml@xxxxxxxxxxxxxxxx>
> To:	Pierre Ossman <drzeus-list@xxxxxxxxx>,
> 	Al Viro <viro@xxxxxxxxxxxxxxxx>, Jens Axboe <axboe@xxxxxxx>
> Cc:	Mikkel Erup <mikkelerup@xxxxxxxxx>, Greg KH <greg@xxxxxxxxx>,
> 	linux-kernel@xxxxxxxxxxxxxxx, Andrew Morton <akpm@xxxxxxxx>
> Subject: Re: sdhci driver produces kernel oops on ejecting the card
> 
> On Fri, Apr 07, 2006 at 10:47:54AM +0200, Pierre Ossman wrote:
> > Mikkel Erup wrote:
> > > 
> > > It happens with 2.6.16-git20 as well.
> > > Attached are the log file and kernel .config
> > > 
> > 
> > Since it ooopses during umount, I'm guessing that it's a problem
> > somewhere in mmc_block. I'll try to get some time to look closer at it
> > during the weekend. Perhaps Russell has some idea until then?
> 
> $ grep -n driverfs_dev block/genhd.c
> 558:    physdev = disk->driverfs_dev;
> $
> 
> Hmm, okay, genhd contains a reference to a device object, but there's
> no sign of _any_ refcounting in sight.
> 
> What's happening is that the MMC card block device is setup and registered
> with genhd.  We set md->disk->driverfs_dev to point at the owning device
> structure.
> 
> This generates a uevent, which causes disk->driverfs_dev to be dereferenced.
> All fine here.  We mount the partition, which causes another uevent to be
> generated, again dereferencing disk->driverfs_dev.
> 
> If we remove the MMC card, we destroy the MMC card block device.  This
> seems to generate another uevent for the block device.  At this point,
> the counted references to the MMC card block device fall to zero.
> 
> But wait!  There's still uncounted disk->driverfs_dev reference waiting
> for...
> 
> You unmount the partition.  This calls block_uevent, which dereferences
> disk->driverfs_dev.  You know what happens now.
> 
> The levels above genhd can't do the refcounting because they don't know
> when stuff has finished with driverfs_dev.  So the only place for sane
> refcounting seems to be genhd.c, as per the patch below.
> 
> Comments?
> 
> diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x *.orig -x *.rej -x .git a/block/genhd.c b/block/genhd.c
> --- a/block/genhd.c	Sat Feb 18 10:31:37 2006
> +++ b/block/genhd.c	Fri Apr  7 15:22:21 2006
> @@ -262,6 +262,7 @@ static int exact_lock(dev_t dev, void *d
>   */
>  void add_disk(struct gendisk *disk)
>  {
> +	get_device(disk->driverfs_dev);
>  	disk->flags |= GENHD_FL_UP;
>  	blk_register_region(MKDEV(disk->major, disk->first_minor),
>  			    disk->minors, NULL, exact_match, exact_lock, disk);
> @@ -507,6 +508,7 @@ static struct attribute * default_attrs[
>  static void disk_release(struct kobject * kobj)
>  {
>  	struct gendisk *disk = to_disk(kobj);
> +	put_device(disk->driverfs_dev);
>  	kfree(disk->random);
>  	kfree(disk->part);
>  	free_disk_stats(disk);
> 
> 
> -- 
> Russell King
>  Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
>  maintainer of:  2.6 Serial core
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> ----- End forwarded message -----
> 
> -- 
> Russell King
> 

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