bin/94252: rpc.lockd cannot cancel lock requests

Kris Kennaway kris at FreeBSD.org
Wed Mar 8 15:00:19 PST 2006


>Number:         94252
>Category:       bin
>Synopsis:       rpc.lockd cannot cancel lock requests
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Mar 08 23:00:17 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     Kris Kennaway
>Release:        FreeBSD 6.0-STABLE i386
>Organization:
FreeBSD
>Environment:
System: FreeBSD xor.obsecurity.org 6.0-STABLE FreeBSD 6.0-STABLE #13: Sun Nov 6 12:45:25 EST 2005 kkenn at xor.obsecurity.org:/mnt/src/sys/i386/compile/XOR i386

>Description:

rpc.lockd doesn't know how to cancel lock requests, so if a lock
acquisition blocks, the process cannot be signalled and remains so
until the lock operation completes (or the system reboots).

>How-To-Repeat:

In one terminal, 

# lockf -k /nfs/filesystem/with/lockd/lock sh
# 

In a second terminal

# lockf -k -t 1 /nfs/filesystem/with/lockd/lock echo Yay
^C^C^C^Cdammit

Note that the timeout doesn't work because lockf issues a blocking
lock request and expects to signal itself after the timer expires.

In the first terminal, exit the shell to release the lock.  The second
lockf will then complete its lock acquisition and return successfully.

The same thing happens if rpc.lockd on the server crashes or becomes
unresponsive (e.g. the system goes offline).  In that case client lock
requests will hang forever, or until the server comes back online.

>Fix:



>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list