zvol: Fix uses of uninitialized variables in zvol_rename_minors_impl()
Reported-by: GitHub Copilot
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Mark Johnston <markj at FreeBSD.org>
Closes #18191
(cherry picked from commit 943a05528494b2f4585541089606796476fb229e)
Make zvol_set_common() block until the operation has completed
This is motivated by a FreeBSD AIO test case which create a zvol with -o
volmode=dev, then immediately tries to open the zvol device file. The
open occasionally fails with ENOENT.
When a zvol is created without the volmode setting, zvol_create_minors()
blocks until the task is finished, at which point OS-dependent code will
have created a device file. However, zvol_set_common() may cause the
device file to be destroyed and re-created, at least on FreeBSD, if the
voltype switches from GEOM to DEV. In this case, we do not block
waiting for the operation to finish, causing the test failure.
Fix the problem by making zvol_set_common() block until the operation
has finished. In FreeBSD zvol code, use g_waitidle() to block until
asynchronous GEOM operations are done. This fixes a secondary race
where zvol_os_remove_minor() does not block until the zvol device file
is removed, and the subsequent zvol_os_create_minor() fails because the
(to-be-destroyed) device file already exists.
[6 lines not shown]
zvol: Hold the zvol state writer lock when renaming
Otherwise nothing serializes updates to the global zvol hash table.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Mark Johnston <markj at FreeBSD.org>
Closes #18191
(cherry picked from commit d7b8eef9d281f6831ac7d9cb27362509ec434fb2)
FreeBSD: Fix zvol teardown races
zvol_geom_open() may be called to taste an orphaned provider. The test
for pp->private == NULL there is racy as no locks are synchronizing the
test.
Use the GEOM topology lock to interlock the pp->private == NULL test
with the zvol state checks. This establishes a new lock order but I
believe this is necessary. Set pp->private = NULL under the GEOM
topology lock instead of the per-zvol state lock. Modify
zvol_os_rename_minor() to drop the zvol state lock to avoid a lock order
reversal with the topology lock.
Also reverse the order of tests in zvol_geom_open() and zvol_cdev_open()
as at least zvol_geom_open() may race with zvol_os_remove_minor(), which
sets zv->zv_zso = NULL. Testing for ZVOL_REMOVING first avoids a race
which can lead to a NULL pointer dereference.
Add a new OS-specific flag to handle the case where zvol_geom_open()
[9 lines not shown]
Merge commit 26bf39cdba0b from llvm-project (by Jessica Clarke):
[ELF][PowerPC] Don't assume TOC pointer is valid in IPLT entries (#207555)
Unlike normal PLT entries, IPLT entries can be called indirectly even
when in PIEs/DSOs, and so there's no guarantee on what's in the TOC
pointer register at that time. Therefore we must emit variants of the
existing code that work without it, whether r12-relative (playing the
same role as MIPS's $25) in the same number of instructions, or first
retrieving PC in an i386-like manner, being careful not to clobber LR.
On 32-bit PowerPC even direct calls to IPLT entries face the same issue,
since we'd use the TOC base of the resolver, which may not be the same
as the caller, even within the same object.
Normal canonical PLTs still look broken on 64-bit PowerPC as they use
the TOC pointer register too, and similarly on 32-bit PowerPC for PIEs.
We should probably treat these cases the same as PIE on i386 (except
including PDEs for 64-bit PowerPC), where it's an error due to the use
of %ebx in PLT entries.
[7 lines not shown]
Merge commit cbf48349e3e1 from llvm-project (by Jessica Clarke):
[NFC][ELF][PPC64] Pass address not offset to writePPC64LoadAndBranch (#212275)
Every caller currently subtracts the TOC base in its argument, so move
that into common code inside writePPC64LoadAndBranch. This will also
allow a different computation to be used in some cases in a future
commit.
Note that offset is now unsigned not signed; even previously, all
arguments were uint64_t, and all uses are unsigned, so making it signed
doesn't make much sense.
MFC after: 1 week
pthread_cond_timedwait.3: use .Fo/.Fc for long arguments list
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58463
libthr/thread/thr_cond.c: some style
Also use bool for the 'cancel' argument for cond_wait_common().
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58463
_umtx_op.2: document the CVWAIT_UMTX_TIME flag for the UMTX_OP_CV_WAIT_UC request
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58463
umtx_op(2): add the CVWAIT_UMTX_TIME flag for the UMTX_OP_CV_WAIT_UC request
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58463
mknod.2: update the man page
State that FIFOs can be created, document the requirement that
dev must be zero then. Mention whiteouts.
PR: 297082
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Differential revision: https://reviews.freebsd.org/D58478
databases/datui: Unbreak build with recent Rust
Bump the vendored ethnum crate to 1.5.3: 1.5.1 built a TryFromIntError
by transmuting from (), which is now a hard error since the type is no
longer zero-sized.
devel/gwm: Update to 1.4.0
Move CARGO_CRATES to Makefile.crates: the list grew to 321 crates, which
buried the port's actual metadata under 300 lines of mechanical output.
Keeping it separate makes future updates a wholesale replacement of a
generated file (make cargo-crates > Makefile.crates) and leaves diffs to
the Makefile readable.
