Re: [PATCH] address_space_operations unification

From: Linus Torvalds (torvalds@transmeta.com)
Date: Sun May 07 2000 - 14:16:13 EST


On Sun, 7 May 2000, Alexander Viro wrote:
>
> > Opaque handles don't have that kind of behaviour.
>
> That's different. The problem with struct file * is very simple: what
> it _tries_ to do is distinguishing between openers. And sometimes the
> opener is just "VFS" and that's fscking it - nobody who would open the file
> anywhere in sight.
>
> Natural solution for that is to use NULL. I have no problems with struct file *
> _IF_ ->readpage() on everything that doesn't need to distiguish between the
> users of pagecache will be able to pick everything it needs from the page
> itself. IOW, I think that if we change the first argument of ->readpage()
> from struct dentry* to struct file* we must make sure that symlinks will
> use the *!@#! ->host and be happy with getting NULL as the first argument.

I think the proper way of thinking about the problem is simply that we do
a "best effort" to give the specific _instance_ (ie "file") information if
we have it.

The only case where we cannot point to a specific instance is when paging
out memory-mapped dirty data. Because we simply do not know which instance
the dirtying was associated with.

So a filesystem should always be able to rely on just "page" if possible
(which it is, in quite a lot of cases), but should be able to get, and
use, the extra "instance" information if it is available.

I don't see a real problem with this.

The one thing we could do, is that we split up "writepage" into two
separate actions: one that always gets "file" and one that never gets
"file". The second would be a "writeback" operation, and while 99% of all
filesystems would just do exactly the same thing as for a regular write,
the separation would make it explicit that certain cases do not have
instance information. And it would make it less likely to have a bug where
the low-level filesystem looks at the file struct without verifying that
it actually exists at all (ie it would make some of the tests static
rather than dynamic).

> > otherwise hard to carry around. Like "who opened this file originally?"
> The answer may very well be "nobody".

Exactly. But even that can be useful information to be used for security
purposes.

> c) everything that doesn't care about pagecache sharing (e.g. all
> symlinks - by necessity; there is _no_ struct file * there and creating a
> phoney one just to pass ->f_dentry->d_inode that already _is_ available in
> page->mapping->host just plain sucks) must be happy with NULL. Same goes
> for directories, etc.

I'd be happy with this - admit up front that the data is not always
available. Sometimes the filesystem might _wish_ for it, but we can't
always have what we wish for ;)

                Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:21 EST