Thank you for your comments.
On Wed, 24 Nov 1999, Petr Vandrovec Ing. VTEI wrote:
> We should apply it. If only one thread of application is broken,
> others can continue ahead with enough resources. I do not see problems
> with calling sys_close(). Thread doing pipe() allocated two descriptors,
> but did not pass them to userspace yet, so if another thread closes
> them, program is broken and it is program's problem. Only thing which
> can happen is that sys_close() return -EBADFD. And what? That's not
> problem.
I was just unwilling to create a situation where buggy program
writers start blaming totally innocent Linux kernel for "race conditions
in pipe(2) system call". It is obviously up to Linus to decide on which
approach is wiser:
1. total correctness in single-threaded case and allowing broken
multi-threaded programs to break in flames and smoke. (i.e. with my patch)
or
2. conservative approach in single-threaded case but preventing broken
programs from breaking things even worse and in a non-deterministic
manner, i.e. depending on timing of threads scheduling.
> 'unlock_kernel()' precede copy_to_user() on all other archs.
> Or is there something different on m68k?
Even if he decides not to include the whole patch (it's not in 2.3.30-1)
he can still include the m68k bit because we don't drop the lock there. I
don't know m68k reasons for not dropping the lock.
Regards,
Tigran.
-
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/