Re: NSS issues after locking fixes
On Sun, 18 Apr 2021 at 20:58, Александр Недоцуков 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. Sorry for the breakage! Alex ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71
On Sun, 22 Nov 2020 at 16:06, Kyle Evans wrote:
>
> On Sun, Nov 22, 2020 at 6:00 AM Dimitry Andric wrote:
> >
> > On 22 Nov 2020, at 08:06, Graham Perrin wrote:
> > >
> > > On 20/11/2020 09:57, Graham Perrin wrote:
> > >> On 16/11/2020 09:27, Graham Perrin wrote:
> > >>> Attempting to build r367615 on Friday 13th:
> > >>>
> > >>> …
> > >>>
> > >>> ===> lib/libprocstat/zfs (install)
> > >>> install -U -C -o root -g wheel -m 444
> > >>> /usr/src/lib/libprocstat/libprocstat.h
> > >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/include/
> > >>> ===> lib/libc (obj,all,install)
> > >>> install -U -C -o root -g wheel -m 444 libc.a
> > >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/
> > >>> install -U -s -o root -g wheel -m 444 -S libc.so.7
> > >>> /usr/obj/usr/src/amd64.amd64/tmp/lib/
> > >>> install -U -o root -g wheel -m 444libc.so.7.debug
> > >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/
> > >>> install: short write to
> > >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug:
> > >>> 393216 bytes written, 7462472 bytes asked to write
> > >>> *** [_libinstall] Error code 71
> > >>>
> > >>> make[4]: stopped in /usr/src/lib/libc
> > >>> 1 error
> > >>>
> > >>> make[4]: stopped in /usr/src/lib/libc
> > >>> root@mowa219-gjp4-8570p:/usr/src #
> > >>
> > >> The same problem – short write to
> > >> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug –
> > >> when attempting buildworld of r367847.
> > >>
> > >> If it's relevant: I'm using r367081 for these attempts.
> > >
> > > The same problem when attempting buildworld of r367923. Prior to this I
> > > performed a fresh checkout of /usr/src
> > >
> > > What might cause these failures?
> > >
> > > If it's relevant: I have compression set to gzip-9 for the ZFS dataset
> > > that mounts at /usr
> >
> > I'd guess it's an unintended side-effect of
> > https://svnweb.freebsd.org/base?view=revision=366697
> > ("install(1): Avoid unncessary fstatfs() calls and use mmap() based on
> > size").
> >
>
> Almost certainly -- before, we would never attempt to mmap() on ZFS.
>
> Tossing arichardson@ into CC as the committer
> Tossing mmacy@ and freqlabs@ into CC as ZFS folks
>
> Looking through sys/contrib/openzfs, there's special handling for mmap
> on linux because it bypasses the page cache and relies on caching in
> ARC. AFAICT the FreeBSD side seems to handle write() to mmap'd
> regions, but doesn't do anything with VOP_MMAPPED which might be
> needed to sync the file when it's mmap'd for reading like this. My
> understanding of how this is supposed to actually work on FreeBSD is
> limited, though, so I defer...
>
I'm quite surprised by this, I simply re-used the logic that bin/cp also has.
However, it's possible that this is no longer used in cp due to copy_file_range?
To be honest I'm not sure whether mmap() even improves performance
compared to read/write since the all the MMU setup might be quite
expensive and the data might not even be available so we end up
copying anyway. Maybe we should change install to use read/write
unconditionally? It might also make sense to factor out the
copy_file_range+read/write fallback logic in bin/cp to a library that
can be used in usr.bin/install.
Alex
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mips32 + gcc9 -- still broken
On Mon, 21 Sep 2020, 07:38 Adrian Chadd, wrote: > So, the big list of unknown symbols was my fault! Whoops. > > i've gotten further using gcc-6.4 by fixing some of the warnings/issues > that have crept up. > > Here's a review for one of them: > > https://reviews.freebsd.org/D26504 > > However, now I've hit: > > /usr/local/bin/mips-unknown-freebsd13.0-ld: > > /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: > undefined reference to `__atomic_fetch_sub_8' > /usr/local/bin/mips-unknown-freebsd13.0-ld: > > /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: > undefined reference to `__atomic_load_8' > /usr/local/bin/mips-unknown-freebsd13.0-ld: > > /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: > undefined reference to `__atomic_fetch_add_8' > > .. looks like we need some 64 bit atomics now in mips32 for libc++ / devd > Those are now provided by compiler-rt when using clang. With GCC you'll have to link libatomic. I had a quick look at the code in libc++ that uses the 64-bit atomics a few weeks ago and I believe it's the futex fallback code. The best solution would probably be to port it to use umtx but for MIPS32 it might be fine to use a 32 bit atomic instead. Alex > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools
In my testing 338129 fixed the issue. Seems like the problem is that
bsd.crunchgen.mk iterates over all directories to do a make obj when
it does the bootstrap-tools phase.
On Tue, 21 Aug 2018 at 14:49, Warner Losh wrote:
>
>
>
> On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin wrote:
>>
>> On 8/20/18 9:00 PM, O. Hartmann wrote:
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA512
>> >
>> > Am Mon, 20 Aug 2018 21:24:21 +0200
>> > "O. Hartmann" schrieb:
>> >
>> >> -BEGIN PGP SIGNED MESSAGE-
>> >> Hash: SHA512
>> >>
>> >> Building NanoBSD world on CURRENT r338113 fails due to:
>> >>
>> >> [...]
>> >> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde && MK_TESTS=no
>> >> UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1
>> >> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/pool/sources/CURRENT/src/amd64.amd64/rescue/rescue
>> >> make MK_AUTO_OBJ=no DIRPRFX=rescue/rescue/gbde/ -DRESCUE
>> >> CRUNCH_CFLAGS=-DRESCUE
>> >> MK_AUTO_OBJ=no obj make[5]:
>> >> "/pool/sources/CURRENT/src/tools/build/mk/Makefile.boot"
>> >> line 18: Do not include ${SRCTOP}/sys when building bootstrap tools.
>> >> Copy the header to
>> >> ${WORLDTMP}/legacy in tools/build/Makefile instead. Error was caused by
>> >> Makefile
>> >> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde] Error
>> >> code 1
>> >>
>> >> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue
>> >> [...]
>> >>
>> >>
>> >> This problem occured during today's source updates since I was able to
>> >> build the NanoBSD
>> >> image I intend to build yesterday ~ r338060.
>> >>
>> >> What is going wrong?
>> >
>> > It seems the problem has been introduced after r338095, since r338095
>> > builds ok, while
>> > r338096 doesn't.
>>
>> 338096 added this check to catch a kind of error in our Makefiles. Alex
>> (cc'd) can
>> help with figuring out what the error is.
>
>
> Except we're not building anything, we're making obj in rescue... It looks
> like a false positive...
>
> Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools
I think relaxing the check to just avoid includes of "${SRCTOP}/sys" is
probably the best solution. It would be nice to also handle the
${.CURDIR}/../../sys case but since it's just there to prevent ABI issues
that's probably fine.
Alex
On Tue, 21 Aug 2018 at 15:19 Warner Losh wrote:
> On Tue, Aug 21, 2018 at 8:16 AM, Warner Losh wrote:
>
>> There's a half a dozen special targets, however. clean comes to mind...
>>
>>
>> However, this test is needlessly restrictive:
>>
>> .if
>> !empty(CFLAGS:M*${SRCTOP}/sys*:N*${SRCTOP}/sys/cddl/compat*:N*${SRCTOP}/sys/crypto*)
>>
>> since it matches
>>
>> CFLAGS+=-I${SRCTOP}/sys/sys/disk
>>
>> which is totally legit. It's designed to be legit everywhere for building
>> on Linux...
>>
>> .if
>> !empty(CFLAGS:M*${SRCTOP}/sys:N*${SRCTOP}/sys/cddl/compat:N*${SRCTOP}/sys/crypto)
>>
>> would be a better test, imho.
>>
>
> Although, I could passively agressively work around it with
>
> CFLAGS+=-I${.CURDIR}/../../sys/sys/disk
>
> which also kinda defeats its purpose...
>
> Warner
>
>
>> Warner
>>
>> On Tue, Aug 21, 2018 at 8:11 AM, Alexander Richardson <
>> arichard...@freebsd.org> wrote:
>>
>>> In my testing 338129 fixed the issue. Seems like the problem is that
>>> bsd.crunchgen.mk iterates over all directories to do a make obj when
>>> it does the bootstrap-tools phase.
>>> On Tue, 21 Aug 2018 at 14:49, Warner Losh wrote:
>>> >
>>> >
>>> >
>>> > On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin
>>> wrote:
>>> >>
>>> >> On 8/20/18 9:00 PM, O. Hartmann wrote:
>>> >> > -BEGIN PGP SIGNED MESSAGE-
>>> >> > Hash: SHA512
>>> >> >
>>> >> > Am Mon, 20 Aug 2018 21:24:21 +0200
>>> >> > "O. Hartmann" schrieb:
>>> >> >
>>> >> >> -BEGIN PGP SIGNED MESSAGE-
>>> >> >> Hash: SHA512
>>> >> >>
>>> >> >> Building NanoBSD world on CURRENT r338113 fails due to:
>>> >> >>
>>> >> >> [...]
>>> >> >> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde &&
>>> MK_TESTS=no
>>> >> >> UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1
>>> >> >>
>>> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/pool/sources/CURRENT/src/amd64.amd64/rescue/rescue
>>> >> >> make MK_AUTO_OBJ=no DIRPRFX=rescue/rescue/gbde/ -DRESCUE
>>> CRUNCH_CFLAGS=-DRESCUE
>>> >> >> MK_AUTO_OBJ=no obj make[5]:
>>> "/pool/sources/CURRENT/src/tools/build/mk/Makefile.boot"
>>> >> >> line 18: Do not include ${SRCTOP}/sys when building bootstrap
>>> tools. Copy the header to
>>> >> >> ${WORLDTMP}/legacy in tools/build/Makefile instead. Error was
>>> caused by Makefile
>>> >> >> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde]
>>> Error code 1
>>> >> >>
>>> >> >> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue
>>> >> >> [...]
>>> >> >>
>>> >> >>
>>> >> >> This problem occured during today's source updates since I was
>>> able to build the NanoBSD
>>> >> >> image I intend to build yesterday ~ r338060.
>>> >> >>
>>> >> >> What is going wrong?
>>> >> >
>>> >> > It seems the problem has been introduced after r338095, since
>>> r338095 builds ok, while
>>> >> > r338096 doesn't.
>>> >>
>>> >> 338096 added this check to catch a kind of error in our Makefiles.
>>> Alex (cc'd) can
>>> >> help with figuring out what the error is.
>>> >
>>> >
>>> > Except we're not building anything, we're making obj in rescue... It
>>> looks like a false positive...
>>> >
>>> > Warner
>>>
>>
>>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Tool Chain Migration: objdump users, please test llvm-objdump
On Wed, 20 Jun 2018 at 16:50 Brooks Davis wrote: > On Wed, Jun 20, 2018 at 10:46:46AM -0400, Ed Maste wrote: > > Work is in progress to migrate fully to modern and permissively > > licensed components for the tool chain. This includes moving away from > > the three obsolete binutils components that are still in the base > > system (as, ld, objdump). objdump is a tool to report information > > about binary objects (such as headers, symbols, etc.), is not required > > as a build tool, and in any case many uses of objdump are better > > served by readelf. > > > > For FreeBSD 12 I intend to remove GNU objdump 2.17.50. PR 229046[1] is > > open to track tasks related to its removal, and users who need GNU > > objdump can install an up-to-date version from the ports tree or the > > binutils package. > > > > That said, llvm includes a somewhat equivalent llvm-objdump, and it is > > built by default in FreeBSD now. If llvm-objdump's command line option > > support and output format is "close enough" to GNU objdump for most > > users we may decide to install it as /usr/bin/objdump. Therefore, I > > would like to ask users of GNU objdump in FreeBSD to give llvm-objdump > > a try. Please let me know if it works for your uses, or describe > > deficiencies that you found. > > I think we've changed our flag us in CheriBSD to accommodate llvm-objdump > so at least a few months ago flag compatibility was poor. The output is > different, but fine for my uses (producing human readable assembly > output). > > When I made the change to use llvm-objdump in CheriBSD I had to change the objdump flags from -xrsSd to -r -s -p -S -d -h -l -t. This is because llvm-objdump doesn't support the -x option and doesn't accept joined single-character options. I've been meaning to submit a patch upstream for -x but haven't got around to it yet. Otherwise the only noticeable change was that creating a full dump of any binary is MUCH faster. Alex ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
