Maps a dev_t like wd3e to an autoconf instance number like 3, with no
partition. Same as DISKUNIT macro, but is a symbol whose pointer can
be taken. Meant for use with struct bdevsw, cdevsw::d_devtounit.
If set, then bdev_open/cdev_open will use d_devtounit to map the
dev_t to an autoconf instance (e.g., /dev/wd0a -> wd0) and hold a
reference with device_lookup_acquire across the call to d_open.
This guarantees that the autoconf instance cannot be detached while
the devsw's d_open function is trying to open it (and also that the
autoconf instance has finished *_attach before anyone can open it).
Of course, if the underlying hardware has gone away, there will be
I/O errors, but this avoids software synchronization bugs between
open and detach for drivers that opt into it. It's up to the driver
and bus to figure out how to deal with I/O errors from operations on
hardware that has gone away while the software hasn't finished
notifying everything that it's gone yet.
XXX kernel ABI change to struct bdevsw/cdevsw requires bump
device_lookup_acquire looks up an autoconf device instance, if found,
and acquires a reference the caller must release with device_release.
If attach or detach is still in progress, device_lookup_acquire waits
until it completes. While references are held, the device's softc
will not be freed or reused until the last reference is released.
The reference is meant to be held while opening a device in the short
term, and then to be passed off to a longer-term reference that can
be broken explicitly by detach -- usually a device special vnode,
which is broken by vdevgone in the driver's *_detach function.
Sleeping while holding a reference is allowed, e.g. waiting to open a
tty. A driver must arrange that its *_detach function will interrupt
any threads sleeping while holding references and cause them to back
out so that detach can complete promptly.
Subsequent changes to subr_devsw.c will make bdev_open and cdev_open
automatically take a reference to an autoconf instance for drivers
that opt into this, so there will be no logic changes needed in most
drivers other than to connect the autoconf cfdriver to the
bdevsw/cdevsw I/O operation tables. The effect will be that *_detach
may run while d_open is in progress, but no new d_open can begin
until *_detach has backed out from or committed to detaching.
XXX kernel ABI change to struct device requires bump -- later change
will make struct device opaque to ABI, but we're not there yet
(`dev' means either `bdev' or `cdev' for brevity here, e.g. in
`devsw_lookup' (bdevsw_lookup, cdevsw_lookup), `dev_open' (bdev_open,
cdev_open), `maxdevsws', &c., except for `devsw_attach' and
`devsw_detach' which are taken literally.)
- Use atomic_store_release and atomic_load_consume for devsw and
tables and their entries, which are read unlocked and thus require
memory barriers to ensure ordering between initialization in
devsw_attach and use in dev_lookup.
- Use pserialize(9) and localcount(9) to synchronize dev_open and
devsw_detach.
=> Driver must ensure d_open fails and all open instances have been
closed by the time it calls devsw_detach.
=> Bonus: dev_open is no longer globally serialized through
device_lock.
- Use atomic_store_release and atomic_load_acquire for max_devsws,
which is used in conditionals in the new devsw_lookup_acquire.
=> It is safe to use atomic_load_relaxed in devsw_lookup because
the caller must guarantee the entry is stable, so any increase
of max_devsws must have already happened.
=> devsw_lookup and devsw_lookup_acquire assume that max_devsws
never goes down. If you change this you must find some way to
adapt the users, preferably without adding much overhead so that
devsw operations are cheap.
This change introduces an auxiliary table devswref mapping device
majors to localcounts of opens in progress. The auxiliary table only
occupies one pointer's worth of memory in a monolithic kernel, and is
allocated on the fly for dynamically loaded modules. We could ask
the module itself to reserve storage for it, but I don't see much
value in that, and it would require some changes to the ABI and to
config(8).
- Omit needless boolean indirection.
Prune a whole lotta dead branches as a result of this. (Some logic
calling this is also wrong for other reasons; devsw_detach is final
-- you should never have any reason to decide to roll it back. To be
cleaned up in subsequent commits...)
XXX kernel ABI change to devsw_detach signature requires bump
an error for MAP_ANON too but unfortunately our /libexec/ld.elf_so
sometimes creates an empty anon mapping for the bss of a shared library.
At least FreeBSD and Solaris return this error too and according to POSIX
"If len is zero, mmap() shall fail and no mapping shall be established".
Fixes PR pkg/56338 Installing qt5-qtdeclarative leaves a dangling reference
The dangling reference here originates from vn_mmap() taking a vnode
reference for this empty mapping that will never be released.
Previously I used xc_barrier to ensure the initialization of the
struct octeon_intrhand was witnessed on all CPUs before publishing
it, in order to avoid needing any barrier on the usage side to be
issued by the interrupt handler.
But there's no need to avoid atomic_load_consume at time of
interrupt: on MIPS it's the same as atomic_load_relaxed anyway, so
there's no additional memory barrier cost here.
When sorting the words of an expression numerically using the modifier
':On' (added on 2021-07-30), use 64-bit numbers even on 32-bit
platforms. A typical use case is comparing file sizes.
When tracing the execution of jobs, fix an integer overflow after 2038.
32-bit platforms that use a pre-C99 compiler still have this problem.
No change to the test suite since most tests simply skip any potential
differences between 32-bit platforms and 64-bit platforms (see
varmod-order-numeric.mk) or already account for both variants (see
varmod-localtime.mk).
to the end of the BAR space), but instead follow the tuples and stop
reading once we reach the end of the list.
I have a card
bwi0 at cardbus0 function 0: Broadcom Wireless
bwi0: BBP id 0x4306, BBP rev 0x2, BBP pkg 0
where the BAR claims 8k space but seems to only implement 6k (but that
is impossible to report as the spec only allows 2^n sizes) and the CIS
starts at a bit over 4k (so the old code tried reading beyound the 6k
limit and caused pci bus errors).
An alternative would be to avoid reporting bus errors during this access,
but since we are only interested in the CIS chain anyway (and that ends
way earlier) this is a simpler solution.
By previous commit (r1.116), the assersion no longer fires even without
this modification. But the condition was a bit inaccurate.
There is no need to check the data length must be aligned to blocks here
(though it also should be aligned now). What we should check here is that
the tail must be aligned.
audio_track_record() must be called when usrbuf has at least one free block.
I hope that this will fix the panic reported in PR kern/56644.
When an user process specifies the hardware format as its recording format
(i.e., there is no track conversions), if the user process read(2) a small
amount of data and the rmixer_process then runs, depending on the conditions,
the panic may happen. I have never reproduced it because it's difficult to
do intentionally.
Thanks Y.Sugahara and riastradh@ for help and comments.
Add support for the 'userconf' command at the boot prompt and in boot.cfg,
and for FDT based booting, pass the commands as a string list property
named "netbsd,userconf" on the /chosen node.
Since .POSIX: is required to be the first non-comment line
in a Makefile, including ${MAKE_POSIX_MK} or whatever _PATH_POSIX_MK is
set to at this point is equivalent to an extension of sys.mk
This is a minimal change that can allow a better approximation of
POSIX compliance
Reviewed by: rillig
If NetBSD were built with -DHAVE_MALLOC_ERRNO=0, the previous code would
have resulted in a compile error due to the extra '}'. Fix this by
copying the upstream code.
No binary change.
riastradh