[OpenAFS-devel] keyring/pag support for linux

[chas williams - CONTRACTOR]

In message <12903.1154532637@warthog.cambridge.redhat.com>,David Howells writes
:
>	+        /* install the keyring */
>	+        spin_lock_irq(&current->sighand->siglock);
>	+        old = current->signal->session_keyring;
>	+        current->signal->session_keyring = keyring;
>	+        spin_unlock_irq(&current->sighand->siglock);
>
>is _not_ correct.  The rcu_assign_pointer() you've removed is quite important
>if you want your code to work on, say, PPC64 or Alpha - especially Alpha.

i know that.  its what i have though.  the rcu usage is a different issue.
that problem might be solved a different way.

>No - it's calling a system call in kernel context.  It's possible, though the
>clone syscall is usually the subject (kernel threads).

see my other message about this.

>> so export install_session_keyring()
>
>join_session_keyring() is better, I think.

so do i, but its not general purpose but its certainly sufficient.

>Hmmm...  When setting up a new PAG, should the other contents of the existing
>session keyring be copied across, I wonder...

session keyring management is an issue.  there doesnt seem to be a clear
answer since there are not enough users of the keyring facility to decide
what the preferred behavior should be.  if you get a new session keyring
should the slate be wiped completely clean?  i would argue that this
is the typical case, but people always find exceptions.

>> (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.
>
>Users shouldn't really be using these.  The intention was that request_key()
>is the only interface that should be necessary.  I envisioned things like
>keyring replacement being driven from PAM.

we need to make an existing interface work.  i can make it work with
changes to the user space utilities but its an inferior solution.

>No.  Just a suggestion.  It still may be feasible that it be placed in the
>main kernel, with a way for it to be driven from a module also.

its unlikely the kernel maintainers would accept a patch for a feature
this is not used by any existing kernel code.  particularly, something
that would be used by openafs.