Re: Linux 2.4.10-pre11

Andrea Arcangeli
2001-09-18T10:17:08Z

On Tue, Sep 18, 2001 at 06:02:27AM -0400, Alexander Viro wrote:
>
>
> On Tue, 18 Sep 2001, Andrea Arcangeli wrote:
>
> > 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?
>
> It sees an active inode for superblock we are destroying. _Not_ a good
> thing, for very obvious reasons. There is a reason for "Self-destruct in
> 5 seconds" printk...
>

very clear now, thanks. I though the fs you were talking about was
mounted on the blkdev, while it is instead the one where the blkdev
inode cames from. Usually people keeps bldkev in /dev and nobody
unmounts /dev that's why I didn't noticed and thought about it, sorry.

> > 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
>
> What are you going to use as mapping->host for it?

the only info we'd need from the host is the host->i_rdev, so why can't
we get it from the file->f_dentry->d_inode->i_rdev? In general I don't
like very much the fake inodes with the zillon of unused fields (they
just looks confusing due their unused fields), but well if you for
whatever reason prefer to keep doing page->mapping->host->i_rdev or if
file->f_dentry->d_inode->i_rdev has a problem I'm pretty much ok with
the fake_inode there too.

Andrea