ohci at pci: Don't detach on shutdown.
If there's some USB device that requires detach on shutdown (which
would be surprising, because USB devices should generally be safe to
yank at any time, and _storage_ drivers such as ld(4) or sd(4) should
already be synced at shutdown some other way) then that driver should
have DVF_DETACH_SHUTDOWN -- not the entire HCI.
PR port-amd64/59180: System reboots instead of shutting down
PR kern/59179: DVF_DETACH_SHUTDOWN: audit drivers for unnecessary use
ohci(4): Rework detach logic and justify the ordering.
Handle failed attach when we detach.
This changes the signature of the ohci_detach function, but it is
only ever used by statically linked ohci bus attachments, never by
modules so far, so no kernel revbump.
PR port-amd64/59180: System reboots instead of shutting down
ehci(4): Make usb_*_rem work as noop on zero-initialized input.
This way, if some *hci_attach function fails before usb_*_add, the
caller need not maintain boolean state to decide whether to call
usb_*_rem on detach -- it'll just work without extra effort.
Cleanup in preparation for:
PR port-amd64/59180: System reboots instead of shutting down
ehci(4): Sprinkle KERNEL_LOCKED_P and KNF on usb_*_add/rem.
Mark with XXXSMP comments to be fixed later without the kernel lock.
No functional change intended: callers generally do this from
autoconf *_attach/detach routines, which run kernel-locked anyway
(for the moment).
Cleanup in preparation for:
PR port-amd64/59180: System reboots instead of shutting down
usbdivar.h: Add missing usbdi.h include for usbd_status &c.
Sort includes while here.
Prompted by:
PR port-amd64/59180: System reboots instead of shutting down
libpthread(3): Add missing cancellation points.
- accept4
- tcdrain
XXX Should our nonstandard alias paccept(2) also be a cancellation
point?
PR lib/59240: POSIX.1-2024: cancellation point audit
pthread_cancel(3): Add some automatic tests.
PR lib/59240: POSIX.1-2024: cancellation point audit
PR lib/59134: POSIX-1.2024: pthread_setcancelstate must be
async-signal-safe
Wrap up lc040 compatability nops in a macro.
Also add a comment describing why they are there so they wont be accidently
removed in the future.
Addresses PR port-mac68k/13078.
nd6: send packets through the fast path even if DELAY and PROBE
If there is a valid ND cache, we can send packets for the destination
of the cache. If the state of the cache is STALE, we need to go
through the slow path to change its state. In the other cases
including the DELAY and PROBE states, we can send packets through
the fast path.
tests/lib/libpthread/t_once: Test fork and pthread_once race.
Test is disabled by default because it triggers only with very low
probability in each trial, but let's make it easy to run if you want.
PR lib/59125: pthread_once(3) races with concurrent fork
make: POSIX mode, check for sysV style modifiers first
A POSIX compatible makefile should not be using any
of our native modifiers, so give preference to the sysV style modifier
and only check the others as a fallback.
Reviewed by: rillig
ctype(3): Sprinkle _C_LABEL_STRING in a few more places.
Mostly for hygiene and to avoid raising questions about inconsistent
usage; this doesn't actually affect the build any more.
PR lib/58208: ctype(3) provides poor runtime feedback of abuse
ctype(3): Actually conditionalize guard page on shared libc.
Apparently we build the libc .o files with -fPIC too (I guess this is
so that libc.a works in position-independent executables? but why
don't they just use libc_pic.a?), so use a purpose-built cpp macro
_CTYPE_DYNAMIC for this instead of using __PIC__.
Now this shows the right symbol sizes:
$ readelf -s ctype_.pico | grep _C_ctype_tab_guarded_
3: 0000000000000000 4610 OBJECT LOCAL DEFAULT 11 _C_ctype_tab_guarded_
$ readelf -s ctype_.po | grep _C_ctype_tab_guarded_
3: 0000000000000000 514 OBJECT LOCAL DEFAULT 7 _C_ctype_tab_guarded_
$ readelf -s ctype_.o | grep _C_ctype_tab_guarded_
3: 0000000000000000 514 OBJECT LOCAL DEFAULT 7 _C_ctype_tab_guarded_
PR lib/58208: ctype(3) provides poor runtime feedback of abuse
ctype(3): Disable guard page in static libc.
Adding the guard page may have overflown several small installation
media. Let's try to keep this case small.
Update the tests to detect the cases where we will be running against
a libc without a guard page on the LC_CTYPE=C tables, and skip
testing abuse detection when it would rely on the guard page.
PR lib/58208: ctype(3) provides poor runtime feedback of abuse
efi(8)/efi(9): Rename EFI_VARNAME_MAXLENGTH -> EFI_VARNAME_MAXBYTES.
This should help avoid potential confusion over the units.
No functional change intended.
Prompted by (but will not fix):
PR kern/59235: efi(8) panics
efi(8): EFI_VARNAME_MAXLENGTH is in bytes, not CHAR16.
Same with struct efi_var_ioc::namesize.
This shouldn't change the semantics of the program -- it was just
allocating twice the maximum buffer space that the kernel would ever
actually use; now it only allocates exactly the maximum buffer space
that the kernel will ever actually use.
Prompted by (but will not fix):
PR kern/59235: efi(8) panics
make: use '"filename" line 123' for locations instead of 'filename:123'
The format 'filename:123' is commonly used for identifying a location in
a file. Text editors recognize it and allow quick navigation through it.
The previous format was specific to make and would have required custom
support in editors.
The new format was already used in stack traces, except for the first
line. Now all lines use the same format.
Sprinkle nop.
This is the kernel part of addressing the issue with fpu emulation on lc040
cpus.
The idea is that we might be switch from or to an f-line (MMU/FPU Trap)
instruction so prepend a nop to flush the caches.
Addresses part of PR/13078.
The second part to this (patch to binutils/gas) has been submitted upstream
and will be fixed when this part is reviewed and included in our local copy
of binutils or (hopefully) in a later version of binutils from upstream.
See:
https://sourceware.org/pipermail/binutils/2025-March/140270.html
Always read LIF volume/directory from stage1 even on cd9660 stage2 case.
mmap(2) against the bootstrap file in the target cd9660 could fail
because the sector size of ISO9660 is 2048 so each file could be
allocated at an offset not pagesize (4096 or 8192) aligned.
This could fail if stage1 (specified via "primary" arg on command line)
and stage2 (on the target filesystem) files are different, but
in "build.sh iso-image" case they are always identical.
The problem (build failures in auotomated builds for hp300 on Linux)
was reported by Jan-Benedict Glaw.
Should also be pulled up to netbsd-10.
tests/make: fix test for printing the stack trace
Depending on the exact environment in which the test is run, the "./"
path component may or may not be trimmed from the output. Use an
absolute path instead.
