From owner-freebsd-net@FreeBSD.ORG Mon Apr 4 19:45:06 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6227C1065673 for ; Mon, 4 Apr 2011 19:45:06 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id 4035A8FC0A for ; Mon, 4 Apr 2011 19:45:05 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp024.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LJ5001W38661Y40@asmtp024.mac.com> for freebsd-net@freebsd.org; Mon, 04 Apr 2011 12:44:30 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-04-04_05:2011-04-04, 2011-04-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1104040105 From: Chuck Swiger In-reply-to: Date: Mon, 04 Apr 2011 12:44:29 -0700 Message-id: <0DFEE2E6-1E0B-420B-9519-3C81F3FD9F22@mac.com> References: <0F56F33B-C492-4723-B7EC-713AD64E856C@mac.com> To: "Marc G. Fournier" X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: 7-STABLE NFS: fatal: "select lock: Permission denied" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:45:06 -0000 On Apr 4, 2011, at 12:37 PM, Marc G. Fournier wrote: > Okay, next question ... if lockd is running, should fcntl locks work? My read of the NFS_README.html above indicates to me that they should ... but if that is the case, then it comes back to why doesn't it? If rpc.lockd was bug-free and didn't suffer from an inherent design mismatch between NFS being stateless (prior to NFSv4, anyway) and locking being stateful, then sure, fcntl locking should work as well on an NFS filesystem as it does on a local UFS filesystem. In practice, rpc.lockd is infamously buggy. For that matter, fnctl-style locking is also fairly broken per SysV/POSIX mandate: " This interface follows the completely stupid semantics of System V and IEEE Std 1003.1-1988 (``POSIX.1'') that require that all locks associated with a file for a given process are removed when any file descriptor for that file is closed by that process. This semantic means that applica- tions must be aware of any files that a subroutine library may access. For example if an application for updating the password file locks the password file database while making the update, and then calls getpwname(3) to retrieve a record, the lock will be lost because getpwname(3) opens, reads, and closes the password database. The data- base close will release all locks that the process has associated with the database, even if the library routine never requested a lock on the database. Another minor semantic problem with this interface is that locks are not inherited by a child process created using the fork(2) function. The flock(2) interface has much more rational last close semantics and allows locks to be inherited by child processes. Flock(2) is recommended for applications that want to ensure the integrity of their locks when using library routines or wish to pass locks to their children. Note that flock(2) and fcntl(2) locks may be safely used con- currently." Regards, -- -Chuck