Re: Linux 2.4.10-pre11

[Andrea Arcangeli <andrea@suse.de>]

On Tue, Sep 18, 2001 at 05:44:18AM -0400, Alexander Viro wrote:
> Bumping ->i_count on inode is _not_ an option - think what it does if
> you umount the first fs.

what it does? Unless I'm missing something the fs never cares and never
sees the bd_inode. the fs just does a bdget and then it works only on
the bdev. What should I run to get the oops exactly?

> _If_ you need an inode for block_device - allocate a new one instead of
> reusing the inode that had been passed to ->open().

If we need to avoid the bumping of i_count and to allocate something
dynamically that will be the bd_mapping address space, we don't need a
new fake_inode there too, we just need to share the new physical
pagecahce address space. Such physical i_mapping address space is the
same thing that the buffer cache will have to use to map its legacy
buffer cache buffer headers on top of it (then we can cleanup away the
few lines in blkdev_close that do the update_buffers() and checks the
MS_RDONLY bit).

Andrea