>Hi,
>
>On Sun, 14 Mar 1999 20:02:40 +0100 (CET), Andrea Arcangeli
><andrea@e-mind.com> said:
>
>> I think to have just fixed _safely_ all races of array.c at 2.2.0 time.
>> They all are in my arca-tree patches from ages. I don't know if Linus
>> wants to add them to the stock kernel.
>
>You reinstate the down(&mm->mmap_sem). That was removed after 2.2.0
>for a very good reason: it basically makes proc unusable under heavy
>load. This is bad. Also,
I don't think this is true. The code was just running with the lock_kernel
held. And anyway avoiding /proc to play with the tsk->mm of the process
while another part of the kernel is just owning the mm semaphores is the
feature.
>> +static void release_mm(struct mm_struct *mm)
>> {
>> + if (current->mm != mm)
>> + {
>> + up(&mm->mmap_sem);
>> + mmput(mm);
>> + }
>> +}
>
>looks broken: the condition for releasing the mm is different from the
>condition for grabbing it in the first place.
?? I don't understand. I simply mmput if I run mmget some time before.
>However, my biggest grumble is the one which I have every time I see
>your patches go past: you have presented a whole pile of diffs without
>describing what problem you think you have addressed. What races do
I described it at 2.2.0 time.
>you believe are in array.c as it stands in 2.2.3? What compelling
>reasons do you have for reintroducing the horrendous mmap semaphore
>locking?
It automagically fixes the FIXME that Tigran was thinking about
(read_lock/schedule issue). As second it avoids the task struct to go away
under us if wait4() is run in another CPU while we are in /proc.
In general my approch looks better to me beacuse it gives you a safe
interface to grab a task or an mm. Then you can sleep or do whatever you
want without releasing it. Once you have finished you'll only have to
release_mm(). This completly avoid all mistakes and any kind of future
bugs in array.c.
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/