Why? Most trivial point, it shaves around 600 bytes from the dynamic
binaries on amd64. Less trivial, the removed code is no longer part of
the ABI, and we can ship updates to it with libc updates. Right now most
of the csu is linked into the binaries and require us to do somewhat
tricky ABI compat when it needs to change. For instance, the init_array
change would be much simpler and does not require note tagging if we
have init calling code in libc.
This could be improved more, by splitting dynamic and static
initialization. For instance, &_DYNAMIC tests can be removed then.
Such change, nonetheless, would require building libc three times.
I left this for later, after this change stabilizes, if ever.
Reviewed by: markj
Discussed with: jrtc27 (some objections, see the review), imp
Tested by: markj (aarch64)
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
Differential revision: https://reviews.freebsd.org/D37220
In my tests during buildkernel fs->m was always NULL at that stage.
Note the change has no impact on vm obj contention during said workload.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D39027
In function boundary tracing the link register is not yet saved to the
save stack location, so the save point contains whatever the previous
'lr' save was, or even garbage, at the time the trap is taken. Address
this by explicitly loading the link register from the trap frame instead
of the stack, and propagate that out.
This is almost the simplest patch which manages to avoid write locking
for backing objects, as a result mostly fixing vm object contention
problems.
What is not fixed:
1. cacheline ping pong due to read-locks
2. cacheline ping pong due to pip
3. cacheling ping pong due to object busying
4. write locking on first object
On top of it the use of VM_OBJECT_UNLOCK instead of explicitly tracking
the state is slower multithreaded that it needs to be, done for
simplicity for the time being.
Sample lock profiling results doing -j 104 buildkernel on tmpfs:
before:
71446200 (rw:vmobject)
14689706 (sx:vm map (user))
4166251 (rw:pmap pv list)
2799924 (spin mutex:turnstile chain)
after:
19940411 (rw:vmobject)
8166012 (rw:pmap pv list)
6017608 (sx:vm map (user))
1151416 (sleep mutex:pipe mutex)
Reviewed by: kib
Reviewed by: markj
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D38964
- In the msgctl tests, there is no point in sleeping after a fork().
Just block immediately in wait().
- In non-blocking send/recv tests, just wait for the child to exit once
it's reached a message limit. If a bug prevents the child from
exiting promptly, the test will time out.
MFC after: 1 week
Mark ZFS broken here too, add comment about why. Add comments about
OFED being disabled on 32-bit arm, add comment about why too.
Sponsored by: Netflix
Remove redundant CPUARCH test: we really just want a plain MACHINE_ARCH
here.
Second, always turn off LOADER_ZFS when we turn off ZFS. Not 100%
required, but we did it some places and not others. There's no current
mechanism to say that if X is disabled then X_Y must be too.
Sponsored by: Netflix
Just like stdin and stdout, stderr is a copy of the listen socket inherited from inetd. We need to close it so inetd can process further requests, be restarted, etc.
Sponsored by: Klara, Inc.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D38968
We've already consumed one request, which is sufficient to prevent inetd from endlessly restarting us in this particular and extremely unlikely case.
Sponsored by: Klara, Inc.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D38967
While there, don't log an error when timing out waiting for a possible retransmit after a successful transfer.
Sponsored by: Klara, Inc.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D38966
This version contains a fix for an issue that can affect complex
bc scripts that use multiple read() functions that receive input from
an interactive user. The same value could be returned multiple times.
MFC after: 2 weeks
... if the region we're adding is an exact match to one that we already
have. Simply extend the flags of the existing entry as needed so that
we don't end up with duplicate regions.
It could be that we got the exclusion through two different means, e.g.,
FDT memreserve and the EFI memory map, and we may derive different
characteristics from each. Apply the most restrictive set to the
region.
Reported by: Mark Millard <marklmi yahoo com>
Reviewed by: mhorne
Summary:
All cap_* system calls would fail when capability mode support is
not present.
MFC after: 2 weeks
Reviewed by: emaste, pauamma
Differential Revision: https://reviews.freebsd.org/D38976
Use SHA256_Fd and SHA256_Data instead of home made equivalent.
wrap those functions into hash.c to avoid header collition between
openssl and libmd
Suggested by: kevans
With the removal of NgATM it no longer controls anything.
Reviewed by: manu, emaste
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D38882
This standalone module is the last vestage of ATM support in the tree so
send it on its way.
Reviewed by: manu, emaste
Relnotes: yes
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D38880
Most ATM support was removed prior to FreeBSD 12. The netgraph support
was kept as it was less intrusive, but it is presumed to be unused.
Reviewed by: manu
Relnotes: yes
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D38879
OpenSSL 3.0 has deprecated the sha256 api, let's use libmd which has the
same API instead.
In order to avoid the collision in definitions (sha256.h cannot be
included in the same file as a file where openssl headers has been
included) let's move the sha256 related code in its own file
PR: 270023
Reported by: ngie
It's possible for Xen to switch the video mode set by the boot loader,
so that the information passed in the kernel metadata is no longer
valid. Fetch the video mode used by Xen using an hypercall and update
the medatada for the kernel to use the correct video mode.
Sponsored by: Citrix Systems R&D
This is required for a further change that will make use of a field
that was added in version 0x00040d00.
No functional change expected.
Sponsored by: Citrix Systems R&D
