Olaf Kirch wrote:

>On Mon, Jul 11, 2005 at 08:32:05AM -0400, Peter Staubach wrote:
>  
>
>>A different patch was submitted upstream already to address the fcntl/close
>>race.  It was accepted into the '-mm' kernel on June 28'th.  That patch is
>>attached.
>>    
>>
>
>I see, it seems this customer has been spamming just about everyone
>about this problem :)
>
>I just wonder how the following can work - your patch seems to drop
>local book-keeping of locks completely, unless I misread it:
>
>
>  
>
>>+	if (filp->f_op && filp->f_op->lock != NULL)
>> 		error = filp->f_op->lock(filp, cmd, file_lock);
>>+	else {
>>+		for (;;) {
>>+			error = __posix_lock_file(inode, file_lock);
>>+			if ((error != -EAGAIN) || (cmd == F_SETLK))
>>+				break;
>>+			error = wait_event_interruptible(file_lock->fl_wait,
>>+					!file_lock->fl_next);
>>+			if (!error)
>>+				continue;
>>+	
>>+			locks_delete_block(file_lock);
>> 			break;
>>+		}
>>+	}
>>    
>>
>
>This means if the application establishes an NFS lock, this will not
>be reflected locally - and as a consequence, when the application just
>exits, the lock will never be released.
>

I didn't change the way that the code works in this area, I just changed the
indentation.  As far as I can tell, the new code works the same way as the
old code did, except that it also doesn't leave dangling locks 
around...  :-)

I wrote a small program to reproduce the race that I thought that the 2.6
code was not already handling.  It is attached.  (Please note that it needs
to run with a large-ish delay value, something like 40 or 45 seconds.  There
is some interaction with the Linux threading which I haven't had/made time
to investigate yet.)  I can also attach the email that I sent upstream
which describes my analysis, if you like.

    Thanx...

       ps