bin/94258: O_NONBLOCK may block with rpc.lockd

[Kris Kennaway]

>Number:         94258
>Category:       bin
>Synopsis:       O_NONBLOCK may block with rpc.lockd
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Mar 09 02:40:07 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:

When the rpc.lockd server is unreachable, locks acquired with
O_NONBLOCK may block.  They also block for a few minutes after
rpc.lockd is restarted, but they eventually complete.

>How-To-Repeat:

On the server:

dosirak# killall -KILL rpc.lockd

On the client:

haessal# lockf -t 0 -k pid echo Yay
load: 0.00  cmd: lockf 1467 [lockd] 0.00u 0.00s 0% 528k
[hangs forever]

After rpc.lockd is restarted, it still takes a few minutes for the
lock operation to complete successfully.  New locks acquired in this
period also block.

>Fix:

Unsure.  Returning EWOULDBLOCK may not be correct since this means

     [EWOULDBLOCK]      O_NONBLOCK and one of O_SHLOCK or O_EXLOCK is speci-
                        fied and the file is locked.

and the file may or may not be locked.  Perhaps blocking is even
correct behaviour according to the relevant standards, though this is
counter-intuitive.
>Release-Note:
>Audit-Trail:
>Unformatted: