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

[Alfred Perlstein]

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

From: Alfred Perlstein <alfred at freebsd.org>
To: freebsd-net at FreeBSD.org, kris at FreeBSD.org,
	Jonathan Lennox <lennox at cs.columbia.edu>,
	freebsd-gnats-submit at FreeBSD.org
Cc:  
Subject: Re: kern/56461: FreeBSD client rpc.lockd incompatible with Linux server rpc.lockd
Date: Fri, 18 Jun 2004 10:51:21 -0700

 This fucking sucks.
 
 *Sigh* make it a sysctl, but can someone please lay the smack
 down on the linuxiots and have them fix thier crap?
 
 
 
 * Bruce M Simpson <bms at spc.org> [040618 04:50] wrote:
 > 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
 
 > 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.
 
 
 
 
 -- 
 - Alfred Perlstein
 - Research Engineering Development Inc.
 - email: bright at mu.org cell: 408-480-4684