[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080402234043.GR9785@ZenIV.linux.org.uk>
Date: Thu, 3 Apr 2008 00:40:43 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Trond Myklebust <trond.myklebust@....uio.no>
Cc: Miklos Szeredi <miklos@...redi.hu>, akpm@...ux-foundation.org,
dave@...ux.vnet.ibm.com, ezk@...sunysb.edu,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 01/10] vfs: add path_create() and path_mknod()
On Wed, Apr 02, 2008 at 07:19:58PM -0400, Trond Myklebust wrote:
> I'm just suggesting splitting out the namespace-specific part of struct
> file into a separate structure that would be private to the VFS.
> Something like
>
> struct file_descriptor {
> struct file *file;
> struct vfsmount *mnt;
> atomic_t refcount;
> };
>
> and then having the 'struct file' hold a reference to the superblock
> instead of holding a reference to the vfsmount.
>
> Why would that be problematic for SCM_RIGHTS? We don't allow people to
> send arbitrary references to 'struct file' using SCM_RIGHTS now; they
> have to send descriptors.
HUH? Descriptor is a number. There is no struct file_descriptor,
let alone refcounting for such. There is a table, indexed by number
and containing references to struct file.
If you want to shove pointer to vfsmount in there (what for? to waste
some memory and make SMP protection on access more interesting?), you
could do that, but IMO it's too ugly to consider.
Anyway, what the hell for? It's more complex and buys you nothing
useful.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists