Date: Fri, 18 Jun 2004 12:49:30 +0100 From: Bruce M Simpson <bms@spc.org> To: freebsd-net@FreeBSD.org Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/56461: FreeBSD client rpc.lockd incompatible with Linux server rpc.lockd Message-ID: <20040618114929.GE58783@empiric.dek.spc.org>
next in thread | raw e-mail | index | archive | help
--10jrOL3x2xqLmOsH Content-Type: multipart/mixed; boundary="mJm6k4Vb/yFcL9ZU" Content-Disposition: inline --mJm6k4Vb/yFcL9ZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've attached my thoughts on this issue. I haven't gone ahead and committed the fix in the PR as it makes us just as braindead as Linux, but it would be good to be able to have this in GENERIC so that it can be enabled in those situations where it's needed. Regards, BMS --mJm6k4Vb/yFcL9ZU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="lockd-linux-compat.txt" Synopsis: Linux NFS advisory locks are broken and incompatible with the rest of the world. FreeBSD 5.x in particular uses BSD/OS derived NFS code and thus is affected. FreeBSD 4.x does not implement client-side NFS advisory locks. This problem is also documented as existing for MacOS X, IRIX and BSD/OS: http://www.netsys.com/bsdi-users/2002-04/msg00036.html http://www.uwsg.iu.edu/hypermail/linux/kernel/0311.0/0498.html http://lists.freebsd.org/pipermail/freebsd-hackers/2003-July/001833.html http://lists.freebsd.org/pipermail/freebsd-hackers/2003-April/000592.html The patch provided in the PR is verified to solve the problem, but it would be good to make this functionality optional at run-time, as many people are likely to be using Linux NFS shares read/write with advisory locks. Walkthrough: The addition of pid_start to struct lockd_msg_ident is what triggered this problem. The offending member is referenced by the NFS code, and rpc.lockd itself. The kernel interface code for rpc.lockd resides in src/usr.sbin/rpc.lockd/kern.c. LOCKD_MSG is what gets passed from the kernel to rpc.lockd via the named pipe /var/run/lock. NFSCLNT_LOCKDANS is used by lockd to send a response back. struct lockd_ans is the structure passed via this syscall. The kernel code for this is in nfslockdans(), in src/sys/nfsclient/nfs_lock.c. Proposed solution: Actual NLM request conversion to/from the kernel happens in rpc.lockd; there are several places in kern.c, notably test_request() and lock_request(), which reference struct nlm4_testargs, struct nlm_testargs, struct nlm_lockargs, and struct nlm4_lockargs. These are defined in src/include/rpcsvc/nlm_prot.x. XXX Are the lockd cookies different from the regular NFS filehandles? arg4.cookie.n_bytes = (char *)&msg->lm_msg_ident; arg4.cookie.n_len = sizeof(msg->lm_msg_ident); There's no need to change this structure, just the number of bytes provided by it; the lm_msg_ident structure needs to change if we're doing Linux compatbility, and is probably best served by adding a sysctl to keep track of whether we're in this mode or not. So embedding a union of structs in lm_msg_ident is probably the way to go, and taking the sizeof() the embedded struct as appropriate. I would suggest adding a sysctl to the tree: vfs.nfs.pid_start_locks, "Use process start time as well as PID to differentiate client-side NFS locks". This should be referenced from nfslockdans() as per the original patch to check if the timercmp comparison should be skipped. --mJm6k4Vb/yFcL9ZU-- --10jrOL3x2xqLmOsH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFA0tbJueUpAYYNtTsRApOvAJ0eHzIGWVsy1AZr47L8NuOgd3K5PQCeIseX w+UzIFGJW52FfeV2PsmXw+U= =7hCl -----END PGP SIGNATURE----- --10jrOL3x2xqLmOsH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040618114929.GE58783>