Date: Thu, 30 Jul 2020 07:03:27 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Ian Lepore <ian@freebsd.org>, Brooks Davis <brooks@FreeBSD.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-stable@freebsd.org" <svn-src-stable@freebsd.org>, "svn-src-stable-12@freebsd.org" <svn-src-stable-12@freebsd.org> Subject: Re: svn commit: r363625 - stable/12/usr.sbin/mountd Message-ID: <QB1PR01MB3364F79AB0FD28107B3AD341DD710@QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <4d5b871fad9412661c3914a64c8ca0b7a01d1dc6.camel@freebsd.org> References: <202007272318.06RNIFjV005206@repo.freebsd.org> <QB1PR01MB3364334927A6502C76338B42DD710@QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM>, <4d5b871fad9412661c3914a64c8ca0b7a01d1dc6.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ian Lepore wrote: >On Thu, 2020-07-30 at 01:52 +0000, Rick Macklem wrote: >> Brooks Davis wrote: >> > Author: brooks >> > Date: Mon Jul 27 23:18:14 2020 >> > New Revision: 363625 >> > URL: https://svnweb.freebsd.org/changeset/base/363625 >> > >> > Log: >> > MFC r363439: >> > >> > Correct a type-mismatch between xdr_long and the variable "bad". >> > >> > [...] >> --> I can't see how the xdr.c code would work for a machine that is >> BIG_ENDIAN and where "long" is 64bits, but we don't have any of >> those. >> > >mips64 and powerpc64 are both big endian with 64-bit long. Oops, I didn't know that. In the past, I've run PowerPC and MIPS, but thought they both were little endian. (I recall the arches can be run either way.) Anyhow, take a look at head/lib/libc/xdr/xdr.c and it looks to me like it has been broken "forever" (ever since we stopped using a K&R compiler that would have always made "long" 32bits). If anyone has either of these and can set up an NFS server on one of them and then try and do an NFSv3 mount that is not allowed, it would be interesting to see the packet trace and if the MNT RPC fails, because it looks like it will put the high order 32bits on the wire and they'll always be 0? Just to clarify. The behaviour wasn't broken by this commit. I just don't see how the commit fixes anything? rick, who doesn't have these arches to test on. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?QB1PR01MB3364F79AB0FD28107B3AD341DD710>