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:=0A= >On Thu, 2020-07-30 at 01:52 +0000, Rick Macklem wrote:=0A= >> Brooks Davis wrote:=0A= >> > Author: brooks=0A= >> > Date: Mon Jul 27 23:18:14 2020=0A= >> > New Revision: 363625=0A= >> > URL: https://svnweb.freebsd.org/changeset/base/363625=0A= >> >=0A= >> > Log:=0A= >> > MFC r363439:=0A= >> >=0A= >> > Correct a type-mismatch between xdr_long and the variable "bad".=0A= >> >=0A= >> > [...]=0A= >> --> I can't see how the xdr.c code would work for a machine that is=0A= >> BIG_ENDIAN and where "long" is 64bits, but we don't have any of=0A= >> those.=0A= >>=0A= >=0A= >mips64 and powerpc64 are both big endian with 64-bit long.=0A= Oops, I didn't know that. In the past, I've run PowerPC and MIPS, but thoug= ht=0A= they both were little endian. (I recall the arches can be run either way.)= =0A= =0A= Anyhow, take a look at head/lib/libc/xdr/xdr.c and it looks to me like it= =0A= has been broken "forever" (ever since we stopped using a K&R compiler=0A= that would have always made "long" 32bits).=0A= =0A= If anyone has either of these and can set up an NFS server on one of=0A= them and then try and do an NFSv3 mount that is not allowed, it would=0A= be interesting to see the packet trace and if the MNT RPC fails, because=0A= it looks like it will put the high order 32bits on the wire and they'll=0A= always be 0?=0A= =0A= Just to clarify. The behaviour wasn't broken by this commit. I just=0A= don't see how the commit fixes anything?=0A= =0A= rick, who doesn't have these arches to test on.=0A= =0A= -- Ian=0A= =0A= =0A= =0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?QB1PR01MB3364F79AB0FD28107B3AD341DD710>