From owner-freebsd-bugs@FreeBSD.ORG Wed Mar 8 23:00:18 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D96AE16A427 for ; Wed, 8 Mar 2006 23:00:18 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E17E643D48 for ; Wed, 8 Mar 2006 23:00:17 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k28N0Hnm068380 for ; Wed, 8 Mar 2006 23:00:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k28N0HvO068378; Wed, 8 Mar 2006 23:00:17 GMT (envelope-from gnats) Resent-Date: Wed, 8 Mar 2006 23:00:17 GMT Resent-Message-Id: <200603082300.k28N0HvO068378@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Kris Kennaway 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 To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: bin/94252: rpc.lockd cannot cancel lock requests X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kris Kennaway List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2006 23:00:19 -0000 >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: