Re: [PATCH] Initial support for struct vfs_cred [0/1]

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == Luca Barbieri <ldb@ldb.ods.org> writes:

     > Then the rest of the code doesn't need to know at all that
     > credentials are shared and is simpler and faster.  We have
     > however a larger penalty on credential change but, as you say,
     > that's extremely rare (well, perhaps not necessarily extremely,
     > but still rare).

What if I, in a fit of madness/perversion, decide to use CLONE_CRED
between 2 kernel threads (i.e. no 'kernel entry')?


Leaving CLONE_CRED aside, please do not forget that most of the
motivation for vfs_cred is the need to *cache* credentials.
This is something which we already do today in several filesystems:
Coda, Intermezzo, NFS, to name but the most obvious.
The result of the lack of a VFS-sanctioned credential is that we have
to use 'struct file' as a vehicle for passing credentials in, for
instance, the address_space_operations, and that each filesystem ends
up having to keep its own private copies of those credentials in
file->private_data.

Cheers,
  Trond