Date: Mon, 19 Apr 2021 13:00:02 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Alexander Richardson <arichardson@freebsd.org> Cc: =?utf-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCd0LXQtNC+0YbRg9C60L7Qsg==?= <bland@bbnest.net>, freebsd-current <freebsd-current@freebsd.org>, Brad Davis <brd@freebsd.org> Subject: Re: NSS issues after locking fixes Message-ID: <YH1Uosn6cudjlgmI@kib.kiev.ua> In-Reply-To: <CA%2BZ_v8or7sVXQxpJnFzi0qjMF0rAGcVOy3TkTfipooET4n1bBQ@mail.gmail.com> References: <2160831618773765@mail.yandex.ru> <CA%2BZ_v8or7sVXQxpJnFzi0qjMF0rAGcVOy3TkTfipooET4n1bBQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 19, 2021 at 10:06:28AM +0100, Alexander Richardson wrote: > On Sun, 18 Apr 2021 at 20:58, Александр Недоцуков <bland@bbnest.net> wrote: > > > > Hi All, > > > > After supposed locking fixes done in this commit: 5245bf7b92b74e556527b4916a8deba386fe5772 > > we have a broken nsdispatch(3) when system has a threaded nss module plugged in. > > > > To illustrate the problem: > > > > $id bland > > id: bland: no such user > > t$LD_PRELOAD=/usr/lib/libthr.so id bland > > uid=1001(bland) gid=500(domainusers) groups=500(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 threading model can never be changed during run-time, while previous code was taking care of it by taking a copy of __isthreaded. > > > > I can not reach out Alex Rechardson who authored this change. Perhaps someone 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=738314e445ceac4d3dd6c77c636044141623b8dc > 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. Just to be pedantic. Proper way to handle process-private locks and fork is to lock in pthread_atfork prepare(), and unlock both in parent and child.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YH1Uosn6cudjlgmI>