From kris@obsecurity.org  Wed Mar  8 22:58:18 2006
Return-Path: <kris@obsecurity.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 0044416A420
	for <FreeBSD-gnats-submit@freebsd.org>; 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 <FreeBSD-gnats-submit@freebsd.org>; 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 <FreeBSD-gnats-submit@freebsd.org>; 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 <kris@FreeBSD.org>
Reply-To: Kris Kennaway <kris@FreeBSD.org>
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:
