Messages in this thread | | | Date | Wed, 16 Feb 2011 00:01:24 +0100 (CET) | From | Thomas Gleixner <> | Subject | RE: Question about clearing of tsk->robust_list in clone |
| |
On Tue, 15 Feb 2011, Kenneth Albanowski (Palm GBU) wrote:
> On Tue, 15 Feb 2011, Thomas Gleixner wrote: > > > The sanity checks in exit_robust_list will catch that mutex_1 > > owner is not matching, but that makes it not more correct. > > Yes, that's my remaining question: whether the intention was that the > owner filter would often be preventing erroneous unlocks, or whether > there should never be an inappropriate list in normal usage. The owner > check does seem sufficient to prevent mayhem if the list pointer is > copied to the child.
It's task state, so we cannot keep state around which belongs to some other task.
Of course we have nevertheless sanity checks in place as we have no idea what kind of crap user space hands us as "robust_list" pointer.
Ideally we never need to walk that list at all in the normal exit case when user space behaves nicely.
> On Tue, 15 Feb 2011, Peter Zijlstra wrote: > > > Realistically libpthread should register an on_fork() callback to > > ensure the state is properly propagated. > > Agreed, that seems reasonable, with only the minor impact of an > additional set_robust_list call. That resolves this as a libc issue, > not a kernel issue.
As I said, I don't understand that argument of the additional call at all. We do it on every process start and on every pthread_create already, just fork() was forgotten somehow.
Thanks,
tglx
| |