Date: Wed, 22 Aug 2018 00:01:57 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Matthew Macy <mmacy@freebsd.org> Cc: freebsd-current <freebsd-current@FreeBSD.org> Subject: Re: panic excl->shared for an AF_LOCAL socket Message-ID: <YTOPR0101MB1820C5AA86BBC8C51ECEE858DD310@YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <CAPrugNraEBBWDkfjJeN5mhLJUz9GDTBPzR98yqrozcP-fwUj6Q@mail.gmail.com> References: <YTOPR0101MB1820866679A7017CC189D0EADD330@YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM>, <CAPrugNraEBBWDkfjJeN5mhLJUz9GDTBPzR98yqrozcP-fwUj6Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Macy wrote: [stuff snipped] >I don't know what's special in this case, but I did revamp the locking the= re several >months back so I'll take a look next weekend. Thanks but don't worry about it for now. I think I figured out how the pani= c() occurred. If the nfsd was accessing /var/run/nfsuserd.sock for a client and= then tried to soconnect() to it to do the upcall, the nfsd thread would already = have /var/run/nfsuserd.sock vnode locked. The old way (and what FreeBSD-11 still does) was to use a UDP socket, which isn't in the file system namespace. (I switched the default to AF_LOCAL so = that nfsuserd could be used in jails where 127.0.0.1 doesn't work, but I now thi= nk it isn't safe to use an AF_LOCAL socket, since it is in the file system's n= amespace and, therefore, can be accessed directly by the NFS code. I think I'll revert the "switch to AF_LOCAL socket" patch. Hopefully the reporter can help confirm this "theory", rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTOPR0101MB1820C5AA86BBC8C51ECEE858DD310>