Date: Fri, 18 Jun 2004 10:51:21 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: freebsd-net@FreeBSD.org, kris@FreeBSD.org, Jonathan Lennox <lennox@cs.columbia.edu>, freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/56461: FreeBSD client rpc.lockd incompatible with Linux server rpc.lockd Message-ID: <20040618175121.GZ61448@elvis.mu.org> In-Reply-To: <20040618114929.GE58783@empiric.dek.spc.org> References: <20040618114929.GE58783@empiric.dek.spc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@mu.org cell: 408-480-4684
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040618175121.GZ61448>