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
[email protected]
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);
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.