Re: bug in blkdev <-> VFS interaction. (oops)

[Tigran Aivazian]

hang on a second - isn't the blkdev_get() interface broken? The inode we
are looking for is in fact nd.dentry->d_inode found by path_walk() on
get_sb_bdev() level. So why don't we pass that inode to
blkdev_get() instead of inventing a fake_inode internally? In fact, the
bdev argument is irrelevant as it is visible through inode->i_bdev anyway.

So probably the solution is to have blkdev_get() accept inode as an
argument and not a bdev. Alternatively we can add a bd_sb field to
block_device structure and fill in fake_inode->i_sb from there.

Any thoughts?

 On Sun, 6 Aug 2000, Tigran Aivazian wrote:

> I do realize that there are two sb's we are talking about here - the
> read_super() is for sb for filesystem being mounted and has nothing to do
> with the fake_inode->i_sb which should contain the sb of the filesystem
> that contains the device node. So my reference to read_super() in
> get_sb_bdev() is irrelevant but nevertheless the problem is real and still
> needs thought and fixing.
> 
>  On Sun, 6 Aug 2000, Tigran Aivazian wrote:
> 
> > Hi Alexander,
> > 
> > I have just found an interesting bug. Try mounting read/write a
> > write-protected floppy in 2.4.0-test6-pre5 (probably also other
> > kernels). The oops is attached.
> > 
> > The reason is quite clear. When blkdev_get() calls block device open
> > routine it passes a fake_inode as 'inode' argument and therefore it's
> > inode->i_sb is not set because it is not known yet (sb=read_super()
> > happens later than blkdev_get() in get_sb_bdev()). Now, the device open
> > routine, for example drivers/block/floppy.c:floppy_open() is free to call
> > permission(inode, mask) on that inode which will in turn do
> > IS_RDONLY(inode) which dereferences inode->i_sb->s_flags off NULL
> > inode->i_sb - hence the oops.
> > 
> > So, it looks like to get a bdev we need to blkdev_get it which needs a
> > superblock but to get a superblock we need a bdev. What do we do?
> > 
> > Regards,
> > Tigran
> > 
> 
>