Date: Wed, 8 Mar 2006 17:58:16 -0500 (EST) From: Kris Kennaway <kris@FreeBSD.org> To: FreeBSD-gnats-submit@FreeBSD.org Subject: bin/94252: rpc.lockd cannot cancel lock requests Message-ID: <20060308225816.EB5B0524AA@obsecurity.dyndns.org> Resent-Message-ID: <200603082300.k28N0HvO068378@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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@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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060308225816.EB5B0524AA>