Hi Tigran,
From: "Tigran Aivazian" <tigran@veritas.com>
>
> the problem is not a deadlock but the fact that locking algorithms refer
> to 'current' explicitly - see the problem now?
>
Where?
The locking algorithm is:
* if you want to _change_ current->{fs,files}, you must be "current" _and_
you must acquire the task_lock spinlock. See linux/kernel/exit.c,
__exit_files()
* if you want to read current->fs, you must either acquire the spinlock, or
be "current".
>
> yes, it can from userspace. when you move to kernel space and to a
> different context you must lock files->file_lock (which is what
> put_unused_fd() or do_close() do and what the closefd.o module didn't),
> otherwise you are broken :)
>
Obviously you must lock files_lock, but all necessary spinlocks exist:
read_lock(&tasklist_lock);
tsk = find_task_by_pid();
get_task_struct(tsk);
read_unlock(&tasklist_lock);
task_lock(&tsk);
files = tsk->files;
atomic_inc(&files->count);
task_unlock(&tsk);
free_task_struct(tsk);
__do_close(files, fd, release); /* do_close, but on files instead of
* current->files */
put_files_struct(files);
If there is a flaw in the locking, we must fix it asap: proc uses that
locking and several distros poll /proc/<pid>/* during shutdown. We'll see
crashes if the locking is wrong.
--
Manfred
-
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/
This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:04 EST