Messages in this thread |  | | Date | Tue, 18 Sep 2001 11:57:13 +0200 | From | Andrea Arcangeli <> | Subject | Re: Linux 2.4.10-pre11 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |