kern/56461: FreeBSD client rpc.lockd incompatible with Linux server rpc.lockd

[Bruce M Simpson]

The following reply was made to PR kern/56461; it has been noted by GNATS.

From: Bruce M Simpson <bms at spc.org>
To: freebsd-net at FreeBSD.org
Cc: alfred at FreeBSD.org, kris at FreeBSD.org,
	Jonathan Lennox <lennox at cs.columbia.edu>,
	freebsd-gnats-submit at FreeBSD.org
Subject: Re: kern/56461: FreeBSD client rpc.lockd incompatible with Linux server rpc.lockd
Date: Fri, 18 Jun 2004 12:49:30 +0100

 --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--