[PATCH] block: Fix race during disk initialization

[PATCH] block: Fix race during disk initialization

[Jan Kara]

When a new disk is being discovered, add_disk() first ties the bdev to gendisk
(via register_disk()->blkdev_get()) and only after that calls
bdi_register_bdev(). Because register_disk() also creates disk's kobject, it
can happen that userspace manages to open and modify the device's data (or
inode) before its BDI is properly initialized leading to a warning in
__mark_inode_dirty().

Fix the problem by registering BDI early enough.

This patch addresses https://bugzilla.kernel.org/show_bug.cgi?id=16312

Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Jan Kara <jack@suse.cz>
---
 block/genhd.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

 Jens, would you consider merging this fix? The kernel boots with it but
I'm not too familiar with this area of kernel so there can be something subtle
I've missed. So please review. Thanks.

diff --git a/block/genhd.c b/block/genhd.c
index 59a2db6..315afd2 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -541,13 +541,15 @@ void add_disk(struct gendisk *disk)
 	disk->major = MAJOR(devt);
 	disk->first_minor = MINOR(devt);
 
+	/* Register BDI before referencing it from bdev */
+	bdi = &disk->queue->backing_dev_info;
+	bdi_register_dev(bdi, disk_devt(disk));
+
 	blk_register_region(disk_devt(disk), disk->minors, NULL,
 			    exact_match, exact_lock, disk);
 	register_disk(disk);
 	blk_register_queue(disk);
 
-	bdi = &disk->queue->backing_dev_info;
-	bdi_register_dev(bdi, disk_devt(disk));
 	retval = sysfs_create_link(&disk_to_dev(disk)->kobj, &bdi->dev->kobj,
 				   "bdi");
 	WARN_ON(retval);
-- 
1.6.4.2

Re: [PATCH] block: Fix race during disk initialization

[Jens Axboe]

On 2010-09-16 20:20, Jan Kara wrote:
> When a new disk is being discovered, add_disk() first ties the bdev to gendisk
> (via register_disk()->blkdev_get()) and only after that calls
> bdi_register_bdev(). Because register_disk() also creates disk's kobject, it
> can happen that userspace manages to open and modify the device's data (or
> inode) before its BDI is properly initialized leading to a warning in
> __mark_inode_dirty().
> 
> Fix the problem by registering BDI early enough.
> 
> This patch addresses https://bugzilla.kernel.org/show_bug.cgi?id=16312
> 
> Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
> Signed-off-by: Jan Kara <jack@suse.cz>
> ---
>  block/genhd.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
>  Jens, would you consider merging this fix? The kernel boots with it but
> I'm not too familiar with this area of kernel so there can be something subtle
> I've missed. So please review. Thanks.

It looks sane. How about we add it to the .37 lineup and mark it for
stable backport?

-- 
Jens Axboe

Re: [PATCH] block: Fix race during disk initialization

[Jan Kara]

On Thu 16-09-10 20:33:39, Jens Axboe wrote:
> On 2010-09-16 20:20, Jan Kara wrote:
> > When a new disk is being discovered, add_disk() first ties the bdev to gendisk
> > (via register_disk()->blkdev_get()) and only after that calls
> > bdi_register_bdev(). Because register_disk() also creates disk's kobject, it
> > can happen that userspace manages to open and modify the device's data (or
> > inode) before its BDI is properly initialized leading to a warning in
> > __mark_inode_dirty().
> > 
> > Fix the problem by registering BDI early enough.
> > 
> > This patch addresses https://bugzilla.kernel.org/show_bug.cgi?id=16312
> > 
> > Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
> > Signed-off-by: Jan Kara <jack@suse.cz>
> > ---
> >  block/genhd.c |    6 ++++--
> >  1 files changed, 4 insertions(+), 2 deletions(-)
> > 
> >  Jens, would you consider merging this fix? The kernel boots with it but
> > I'm not too familiar with this area of kernel so there can be something subtle
> > I've missed. So please review. Thanks.
> 
> It looks sane. How about we add it to the .37 lineup and mark it for
> stable backport?
  OK with me. Thanks.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR