In message <[EMAIL PROTECTED]>,David Howells writes : > + /* install the keyring */ > + spin_lock_irq(¤t->sighand->siglock); > + old = current->signal->session_keyring; > + current->signal->session_keyring = keyring; > + spin_unlock_irq(¤t->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. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
