Re: [rfc] "fair" rw spinlocks

[Eric W. Biederman]

Oleg Nesterov <oleg@xxxxxxxxxx> writes:

> On 12/05, Eric W. Biederman wrote:
>>
>> Atomically sending signal to every member of a process group, is the
>> big fly in the ointment I am aware of.  Last time I looked I could
>> not see how to convert it rcu.
>
> I am not sure, but iirc we can do this lockless (under rcu_lock).
> We need to modify pid_link to use list_entry and attach_pid() should
> add the new task to the end. Of course we need more changes, but
> (again iirc) this is not too hard.

The problem is that even adding to the end of the list, we could run
into a deleted entry and not see the new end of the list.

Suppose when we start iterating the list we have:

  A -> B -> C -> D

Then someone deletes some of the entries while we are iterating the list.

A ->
 B' -> C' -> D'

We will continue on traversing through the deleted entries.

Then someone adds a new entry to the end of the list.

A-> N

Since we are at B', C' or D' we will never see the new entry on the
end of the list.

If there was a way to iterate a list with a guarantee that we always saw
new entries while we are traversing it I would love to see it.

Additionally we have the other possibility that if a child is forking
we send the signal to the parent after the child forks away but before
the child joins whichever list we are walking, and we complete our
traversal without seeing the child.

>> This is a pain because we occasionally signal a process group from
>> interrupt context.
>
> Only send_sigio/etc does so, right?

That seems right.  My memory is vague and as I recall you were the one
who found the senders in interrupt context.

> I didn't read the previous discussion yet (will try tomorrow), sorry
> if I am off-topic. But I think the nastiest problem with tasklist
> is that it protects parent/child relationship. We need per-process
> lock, but first we should change ptrace to avoid this lock somehow.
> (this is one of the goals of ptrace-utrace, but not "immediate").

That is another good one.  The discussion was roughly:
We should get rid of rwlocks.
tasklist_lock is a rwlock.
What prevents us from making tasklist_lock a spinlock etc.

On that score since we take tasklist_lock for write in ptrace_attach
and I presume in the other parent/child cases  I don't think that
issue prevents us from moving off of rwlocks for tasklist_lock.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/