[PATCH] 2.5.34-bk fcntl lockup

[PATCH] 2.5.34-bk fcntl lockup

[Petr Vandrovec]

Hi Linus,
   please apply this. 

Fixes endless loop without schedule which happens as soon as smbd 
invokes fcntl64(7, F_SETLK64, ...). fcntl_setlk64 gets cmd F_SETLK64,
not F_SETLK tested in the loop;

Maybe return value from posix_lock_file should be changed to -EINPROGRESS 
or -EJUKEBOX instead of testing passed cmd in callers, but this oneliner 
works too. If you preffer changing posix_lock_file return value to clearly 
distinugish between -EAGAIN and lock request queued, I'll do that.
					Best regards,
						Petr Vandrovec
						vandrove@vc.cvut.cz


diff -urdN linux/fs/locks.c linux/fs/locks.c
--- linux/fs/locks.c	2002-09-13 21:49:17.000000000 +0200
+++ linux/fs/locks.c	2002-09-14 11:19:37.000000000 +0200
@@ -1588,7 +1588,7 @@
 
 	for (;;) {
 		error = posix_lock_file(filp, file_lock);
-		if ((error != -EAGAIN) || (cmd == F_SETLK))
+		if ((error != -EAGAIN) || (cmd == F_SETLK64))
 			break;
 		error = wait_event_interruptible(file_lock->fl_wait,
 				!file_lock->fl_next);

Re: [PATCH] 2.5.34-bk fcntl lockup

[Matthew Wilcox]

On Sat, Sep 14, 2002 at 12:18:11PM +0200, Petr Vandrovec wrote:
> Hi Linus,
>    please apply this. 

agreed, please apply.

> Fixes endless loop without schedule which happens as soon as smbd 
> invokes fcntl64(7, F_SETLK64, ...). fcntl_setlk64 gets cmd F_SETLK64,
> not F_SETLK tested in the loop;

i guess the LTP testsuite isn't quite comprehensive enough yet, it should
have caught this.

> Maybe return value from posix_lock_file should be changed to -EINPROGRESS 
> or -EJUKEBOX instead of testing passed cmd in callers, but this oneliner 
> works too. If you preffer changing posix_lock_file return value to clearly 
> distinugish between -EAGAIN and lock request queued, I'll do that.

i'll look at that idea, hadn't occurred to me before.

-- 
Revolutions do not require corporate support.