lkml.org 
[lkml]   [1997]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: File locking anomaly under 2.0.30
Date
"Theodore Y. Ts'o" <tytso@MIT.EDU> writes:
> Yup, you're quite right. POSIX states,
>
> "All locks associated with a file for a given process shall be
> removed when a file descriptor for that file is closed by that
> process or the process holding that file descriptor terminates.
> Locks are not inherited by a child process created using the
> fork() function."
>
By extension, this should hold for Linux' clone() too. Hence the patch.

BTW, this points to a potential problem if we ever try to do async I/O with
mandatory locks. Thread A locks something, then starts an async I/O
request, which spawns Thread B, which fails to actually read/write the
data because it doesn't own the lock. Ugh.

This is not a problem in a "genuine" threaded program because a thread
typically needs those data in order to continue and thus there's no need
for async I/O in the first place. However, a "normal" program which
requests some data and then tries to do something else until the data
arrive will lose.

A possible solution would be to have a flag for clone() which gets stored
in the child's task_struct and which would instruct the kernel to use
current->pptr instead of current for lock checks. This would mean that
async-I/O threads wouldn't be managed with the standard threading code,
which (under LinuxThreads, anyway) collects all "work" threads under one
common managing thread, no matter which subthread actually spawned off
another thread, which may or may not be a problem.

Better ideas, anybody?


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.070 / U:0.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site