Date: Mon, 19 Apr 2021 10:06:28 +0100 From: Alexander Richardson <arichardson@freebsd.org> To: =?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCd0LXQtNC+0YbRg9C60L7Qsg==?= <bland@bbnest.net> Cc: freebsd-current <freebsd-current@freebsd.org>, Brad Davis <brd@freebsd.org> Subject: Re: NSS issues after locking fixes Message-ID: <CA%2BZ_v8or7sVXQxpJnFzi0qjMF0rAGcVOy3TkTfipooET4n1bBQ@mail.gmail.com> In-Reply-To: <2160831618773765@mail.yandex.ru> References: <2160831618773765@mail.yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 18 Apr 2021 at 20:58, =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0= =B4=D1=80 =D0=9D=D0=B5=D0=B4=D0=BE=D1=86=D1=83=D0=BA=D0=BE=D0=B2 <bland@bbn= est.net> wrote: > > Hi All, > > After supposed locking fixes done in this commit: 5245bf7b92b74e556527b49= 16a8deba386fe5772 > we have a broken nsdispatch(3) when system has a threaded nss module plug= ged in. > > To illustrate the problem: > > $id bland > id: bland: no such user > t$LD_PRELOAD=3D/usr/lib/libthr.so id bland > uid=3D1001(bland) gid=3D500(domainusers) groups=3D500(domainusers),... > > $cat /etc/nsswitch.conf > group: files ldap > hosts: files mdns dns > netgroup: comapt > networks: files > passwd: files ldap > shells: files > services: files > protocols: files > rpc: files > > It seems that the commit in question was done under asumption that thread= ing model can never be changed during run-time, while previous code was tak= ing care of it by taking a copy of __isthreaded. > > I can not reach out Alex Rechardson who authored this change. Perhaps som= eone else can step in and take care of it? > > Thanks, > Alexander. Hi Alexander, I was away over the weekend so I wasn't able to revert it then. I've committed the revert as https://cgit.freebsd.org/src/commit/?id=3D738314e445ceac4d3dd6c77c636044141= 623b8dc and I am not convinced that __isthreaded changing is the real problem. This can only happen with fork() (which calls _thr_setthreaded(0)) since if it's currently false, the main thread is executing and we can't be spawning a new thread. I think the problem could be that fork() is called while the lock is held in one thread and therefore the new process ends up with a locked rwlock. I think the solution could be to add a pthread_atfork() callback that unlocks the rwlock. Sorry for the breakage! Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BZ_v8or7sVXQxpJnFzi0qjMF0rAGcVOy3TkTfipooET4n1bBQ>