[OpenAFS-devel] keyring/pag support for linux

[chas williams - CONTRACTOR]

In message <26800.1154527782@warthog.cambridge.redhat.com>,David Howells writes
:
>> what we really need from the linux kernel: the keyring key_type exported,
>
>Whilst I could do that, I'm not sure it'd help you as you'd need to use the
>RCU interface to access keyrings directly.

i am not sure about that.  i dont need direct access to the keyrings
just access to the keyring key_type so that i can create a keyring
(this doesnt involve rcu).  while the keyring key_type does have 
functions that involve rcu, they do not get 'included' in my binary.
my only need for rcu comes when i need to modify the keyring pointers.

>> the keyring primitives exported,
>
>That should be possible for the most part.  Which ones were you thinking of?

keyring_alloc() is all i need really to make keyrings.  then i dont
need to see the keyring key_type (and no one should need to see it really).

>> or join_session_keyring() exported.
>
>That should be possible.

that would be be fine as well.  either is a solution.  i imagine that
others might wish to create/delete keyrings from inside the kernel.
there is no mechanism for that now.

>	static inline _syscall2(long, keyctl, int, option, void*, arg2)
>	long serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING, NULL);
>
>Which isn't very nice, but which ought to work.

this is a userspace thing which i cannot use a completely compatible interface
to existing users of the afs syscall.

>> the first time might suffer a bit when it comes to safely inserting the
>> session_key into the user task since the rcu primitives are not available to
>> openafs, so the third option is preferred.
>
>The first is a definite no-go if you can't use RCU - you could cause other
>parts of the kernel to oops.

so export install_session_keyring() (and possibly some other functions
like install_thread_keyring(), install_process_keyring()) so that users
dont need to figure out how to safely duplicate the code in these functions.

>Another alternative might be to try putting the PAG stuff in the main kernel,
>and add a keyctl function to set or get a pag.

unfortunately we need to make the existing afs pioctl/syscall interface
work.  this is also a joke right?

>The main thing I'm not sure about how to do is to change the PAG to which a
>process's parent subscribes.  It is possible, but the locking is interesting.

i am not completely certain, but i believe afs needed this feature 
because the pags were inserted in the group list and the group list
wasnt a single shared object.  the session keyring seems to solve this
problem.