From kris@obsecurity.org Wed Mar 8 22:58:18 2006 Return-Path: Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0044416A420 for ; Wed, 8 Mar 2006 22:58:17 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id C550E43D45 for ; Wed, 8 Mar 2006 22:58:17 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id AAB7B1A4D84 for ; Wed, 8 Mar 2006 14:58:17 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id EB5B0524AA; Wed, 8 Mar 2006 17:58:16 -0500 (EST) Message-Id: <20060308225816.EB5B0524AA@obsecurity.dyndns.org> Date: Wed, 8 Mar 2006 17:58:16 -0500 (EST) From: Kris Kennaway Reply-To: Kris Kennaway To: FreeBSD-gnats-submit@freebsd.org Cc: Subject: rpc.lockd cannot cancel lock requests X-Send-Pr-Version: 3.113 X-GNATS-Notify: >Number: 94252 >Category: bin >Synopsis: [rpc] 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: Thu Mar 09 00:05:28 GMT 2006 >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: