RE: Question about clearing of tsk->robust_list in clone

[Thomas Gleixner <tglx@linutronix.de>]

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