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

[Luca Barbieri <ldb@ldb.ods.org>]

[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]

On Sun, 2002-09-01 at 21:40, Trond Myklebust wrote:
> >>>>> " " == Luca Barbieri <ldb@ldb.ods.org> writes:
> 
>      > And, in the common case of open, why do you need to copy the
>      > structure to check permissions?  I think that open should just
>      > check the current values.  open might want to copy credentials
> 
> Because, as has been explained to you, we have things like Coda,
> Intermezzo, NFS, for which this is insufficient.
If they only need them at open, and the open is synchronous, you don't
need to copy them.

Otherwise, if you need them in other syscall, or in another context, you
probably need to copy them, that only costs an additional 2 long copies.

>      > in case you want to do the inode lookup asynchronously but then
>      > it doesn't make sense to optimize for this since you already
>      > have the huge disk read penalty.  BTW, the 2.5.32 open does the
>      > check in vfs_permission without copying anything.  Anyway it's
>      > just a 3 long copy plus an atomic inc vs. 1 long copy and
>      > atomic inc.  And if you don't need the groups array, it's just
>      > a 2 longs copy that on some architectures with very slow atomic
>      > operations (e.g. sparc) is much better.
> 
> But we we do need to check the groups array in the VFS. And as Linus
> pointed out, there is a good case for passing info from the
> user_struct too (crypto), etc...
There is copy-on-write for the groups array.
The idea is that anything that takes little time to use should be in the
copy-always structure, while things that need a long time to access
(e.g. groups, lsm data) and/or are big, stay in the copy-on-write
structure referenced from the copy-always one.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]