to respect the teardown lock.
Enter z_teardown_lock as reader and ZFS_EXIT().
Instead of ZFS_VERIFY_ZP() return without writing and without
error from zfs_putapage() if "z_sa_hdl == NULL".
deadlock with another reclaim.
Add vfs operation zfs_newvnode() to create a new zfs node and
hold the zfs object in zfs_loadvnode() and zfs_newvnode() only.
ZFS expects a null-terminated name.
Always create a copy with PNBUF_GET()/strlcpy()/PNBUF_PUT().
For LOOKUP use a small buffer on stack and allocate/free compomnent names
longer than 30 chars.
further dmu_tx_assign() fails because over quota or no space.
Use the emulated uiocopy() and uioskip() like illumos does.
Fix the uiocopy() emulation to not clobber the iovecs.
Use user flag UF_NODUMP instead of UF_IMMUTABLE for the test as it
is the only user flag supported by all tested file systems.
PR kern/47656 test zfs_flags.
It turns out this code always sees __HAVE_MM_MD_DIRECT_MAPPED_PHYS as
disabled on amd64, for reasons that I shall address forthwith, but it
is enabled on aarch64 and so the MKZFS=yes build breaks.
As it happens, on x86 both _HARDKERNEL and _KERNEL get defined; see
the conditional in sys/rump/Makefile.rump that _refrains_ from
defining _RUMPKERNEL on x86.
So the only version of this code that has been tested is the one with
all of it included. But on, e.g., aarch64, we do not get _HARDKERNEL
here, and the code fails to build because some things use the field
struct spa::spa_deadman_cycid under _KERNEL when it is declared only
under _HARDKERNEL.
If there's a reason _not_ to use this in rump -- and it's not obvious
to me why -- then all access to the field needs to agree to use
_HARDKERNEL.
Rather than write out a table for each architecture, rely on the C
compiler to define _LP64 for 64-bit ones, on the assumption that
anything not LP64 is ILP32, and on CTASSERTs to verify this
assumption so that if it's wrong it'll fail safely with a noisy build
failure.
Gives zfs half a chance of building on, e.g., powerpc.
These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.
HOWEVER! Some subsystems have
#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))
even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.
To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.
I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:
cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))
It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.
Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)
