aboutsummaryrefslogtreecommitdiff
path: root/sys/cddl
Commit message (Collapse)AuthorAgeFilesLines
* arm64: Improve DDB backtrace supportJessica Clarke2021-02-011-10/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | The existing implementation relies on each trap handler saving a normal stack frame record, which is a waste of time and space when we're already saving a trapframe to the stack. It's also wrong as it currently saves LR not ELR. Instead of patching it up, rewrite it based on the RISC-V implementation with inspiration from the amd64 implementation for how to handle vectored traps to provide an improved implementation. This includes compressing the information down to one line like other architectures rather than the highly-verbose old form that repeats itself by printing LR and FP in one frame only to print them as PC and SP in the next. It also includes printing out actually useful information about the traps that occurred, though FAR is not saved in the trapframe so we cannot print it (in general it can be clobbered between when the trap happened and now), only ESR. The AAPCS also allows the stack frame record to be located anywhere in the frame, not just the top, so the caller's SP is not at a fixed offset from the callee's FP like on almost all other architectures in existence. This means there is no way to derive the caller's SP in the unwinder, and so we have to drop that bit of (unused) state everywhere. Reviewed by: jhb, markj Differential Revision: https://reviews.freebsd.org/D28026
* riscv: fix kernel buildMitchell Horne2021-01-151-0/+2
| | | | | | | A more complete fix for this function is being worked on in D28054. Fix the uninitialized variable error so that builds can at least proceed. Reported by: several
* Handle using a sub instruction in the arm64 fbtAndrew Turner2021-01-123-1/+31
| | | | | | | | Some stack frames are too large for a store pair instruction we already detect in the arm64 fbt code. Add support for handling subtracting the stack pointer directly. Sponsored by: Innovate UK
* Only allow a store through sp in the arm64 fbtAndrew Turner2021-01-122-4/+16
| | | | | | | | | | | | | | | | When searching for an instruction to patch out in the arm64 function boundary trace we search for a store pair with a write back. This instruction is commonly used to store two registers to the stack and update the stack pointer to hold space for more. This works in many cases, however not all functions use this, e.g. when the stack frame is too large. In these cases we may find another instruction of the same type that doesn't store through the stack pointer. Filter these instructions out and assume if we see one we are past the function prologue. Reported by: rwatson Sponsored by: Innovate UK
* dtrace: Blacklist riscv exception handlers for fbtKristof Provost2021-01-121-0/+13
| | | | | | | | | We can't safely instrument those exception handlers, so blacklist them. Test case: dtrace -n ::: Reviewed by: markj (previous version) Differential Revision: https://reviews.freebsd.org/D27754
* Changes that improve DTrace FBT reliability on freebsd/arm64:Robert Watson2021-01-115-3/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Implement a dtrace_getnanouptime(), matching the existing dtrace_getnanotime(), to avoid DTrace calling out to a potentially instrumentable function. (These should probably both be under KDTRACE_HOOKS. Also, it's not clear to me that they are correct implementations for the DTrace thread time functions they are used in .. fixes for another commit.) - Don't allow FBT to instrument functions involved in EL1 exception handling that are involved in FBT trap processing: handle_el1h_sync() and do_el1h_sync(). - Don't allow FBT to instrument DDB and KDB functions, as that makes it rather harder to debug FBT problems. Prior to these changes, use of FBT on FreeBSD/arm64 rapidly led to kernel panics due to recursion in DTrace. Reliable FBT on FreeBSD/arm64 is reliant on another change from @andrew to have the aarch64 instrumentor more carefully check that instructions it replaces are against the stack pointer, which can otherwise lead to memory corruption. That change remains under review. MFC after: 2 weeks Reviewed by: andrew, kp, markj (earlier version), jrtc27 (earlier version) Differential revision: https://reviews.freebsd.org/D27766
* dtrace: Fix /"string" == NULL/ comparisons using an uninitialized value.Bryan Drewery2021-01-081-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A test of this is funcs/tst.strtok.d which has this filter: BEGIN /(this->field = strtok(this->str, ",")) == NULL/ { exit(1); } The test will randomly fail with exit status of 1 indicating that this->field was NULL even though printing it out shows it is not. This is compiled to the DTrace instruction set: // Pushed arguments not shown here // call strtok() and set result into %r1 07: 2f001f01 call DIF_SUBR(31), %r1 ! strtok // set thread local scalar this->field from %r1 08: 39050101 stls %r1, DT_VAR(1281) ! DT_VAR(1281) = "field" // Prepare for the == comparison // Set right side of %r2 to NULL 09: 25000102 setx DT_INTEGER[1], %r2 ! 0x0 // string compare %r1 (strtok result) to %r2 10: 27010200 scmp %r1, %r2 In this case only %r1 is loaded with a string limit set to lim1. %r2 being NULL does not get loaded and does not set lim2. Then we call dtrace_strncmp() with MIN(lim1, lim2) resulting in passing 0 and comparing neither side. dtrace_strncmp() handles this case fine and it already has been while being lucky with what lim2 was [un]initialized as. Reviewed by: markj, Don Morris <dgmorris AT earthlink.net> Sponsored by: Dell EMC Differential Revision: https://reviews.freebsd.org/D27671
* Install dtrace.h and dependenciesAlex Richardson2021-01-071-2/+12
| | | | | | | | | | | | | This makes the minimum amount of changes to allow inclusion of dtrace.h without all the solaris compatibility headers. Installing dtrace.h allows compiling consumers of libdtrace (e.g. https://github.com/tmetsch/python-dtrace) without requiring a copy of the source tree. For python-dtrace I worked around this in https://github.com/tmetsch/python-dtrace/commit/58019c9a12022203a9ffda286dd8b41f1a5ace42 but being able to build the library without installed sources would be extremely useful. Reviewed By: gnn Differential Revision: https://reviews.freebsd.org/D27884
* Check that the frame pointer is within the current stack.John Baldwin2020-12-082-13/+8
| | | | | | | | | | | | | | This same check is used on other architectures. Previously this would permit a stack frame to unwind into any arbitrary kernel address (including unmapped addresses). Reviewed by: andrew, markj Obtained from: CheriBSD Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D27362 Notes: svn path=/head/; revision=368455
* Stack unwinding robustness fixes for RISC-V.John Baldwin2020-12-082-4/+13
| | | | | | | | | | | | | | | | - Push the kstack_contains check down into unwind_frame() so that it is honored by DDB and DTrace. - Check that the trapframe for an exception frame is contained in the traced thread's kernel stack for DDB traces. Reviewed by: markj Obtained from: CheriBSD Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D27357 Notes: svn path=/head/; revision=368454
* sdt: Create providers and probes in separate passes when loading sdt.koMark Johnston2020-12-031-17/+39
| | | | | | | | | | | | | | | | | | | | | The sdt module's load handler iterates over SDT linker sets for the kernel and all loaded modules to create probes and providers defined by SDT(9). Probes in one module may belong to a provider in a different module, but when a probe is created we assume that the provider is already defined. To maintain this invariant, modify the load handler to perform two separate passes over loaded modules: one to define providers and the other to define probes. The problem manifests when loading linux.ko, which depends on linux_common.ko, which defines providers used by probes defined in linux.ko. Reported by: gallatin MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=368306
* Fix syntaxKonstantin Belousov2020-12-011-2/+3
| | | | Notes: svn path=/head/; revision=368269
* Fix syntaxKonstantin Belousov2020-12-011-2/+2
| | | | Notes: svn path=/head/; revision=368263
* Use uintptr_t instead of uint64_t for pointers in stack frames.John Baldwin2020-12-011-4/+4
| | | | | | | | | | Reviewed by: andrew Obtained from: CheriBSD Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D27361 Notes: svn path=/head/; revision=368245
* Use uintptr_t for pointers in stack frames.John Baldwin2020-12-011-4/+4
| | | | | | | | | | | | This catches up to the changes made to struct unwind_state in r364180. Reviewed by: mhorne Obtained from: CheriBSD Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D27360 Notes: svn path=/head/; revision=368242
* Add a kstack_contains() helper function.John Baldwin2020-12-012-22/+10
| | | | | | | | | | | | | This is useful for stack unwinders which need to avoid out-of-bounds reads of a kernel stack which can trigger kernel faults. Reviewed by: kib, markj Obtained from: CheriBSD Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D27356 Notes: svn path=/head/; revision=368240
* [cddl] Fix lz4 function definitions to not tri pup compile.Adrian Chadd2020-11-172-2/+7
| | | | | | | | | | | This tripped up in llvm compilation on amd64 noting that lz4_init/lz4_fini were lacking in being previously defined. Reviewed by: emaste, freqlabs, brooks Differential Revision: https://reviews.freebsd.org/D27240 Notes: svn path=/head/; revision=367770
* malloc: move malloc_type_internal into malloc_typeMateusz Guzik2020-11-061-1/+1
| | | | | | | | | | | | | | | | According to code comments the original motivation was to allow for malloc_type_internal changes without ABI breakage. This can be trivially accomplished by providing spare fields and versioning the struct, as implemented in the patch below. The upshots are one less memory indirection on each alloc and disappearance of mt_zone. Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D27104 Notes: svn path=/head/; revision=367432
* Drop "All rights reserved" from all my stuff. This includesEdward Tomasz Napierala2020-10-281-1/+0
| | | | | | | | | | | | Foundation copyrights, approved by emaste@. It does not include files which carry other people's copyrights; if you're one of those people, feel free to make similar change. Reviewed by: emaste, imp, gbe (manpages) Differential Revision: https://reviews.freebsd.org/D26980 Notes: svn path=/head/; revision=367105
* Fix build after r367020Mitchell Horne2020-10-241-3/+3
| | | | | | | | | DTrace also relies on these definitions. Reported by: jenkins Notes: svn path=/head/; revision=367033
* Update OpenZFS to 2.0.0-rc3-gfc5966Matt Macy2020-10-171-2130/+0
| | | | | | | | | | | - fix panic due to tqid overflow - Improve libzfs_error_init messages - Expose zfetch_max_idistance tunable - Make dbufstat work on FreeBSD - Fix EIO after resuming receive of new dataset over an existing one Notes: svn path=/head/; revision=366780
* Turn off zstd on aarch64Warner Losh2020-10-131-1/+4
| | | | | | | | loader support for zstd and zfs doesn't work for aarch64. Disable it to unbreak the build. Notes: svn path=/head/; revision=366658
* Add zstd support to the boot loader.Warner Losh2020-10-123-245/+59
| | | | | | | | | | | | | | | Add support to the _STANDALONE environment enough bits of the kernel that we can compile it. We still have a small zstd_shim.c since there were 3 items that were a bit hard to nail down and may be cleaned up in the future. These go hand in hand with a number of commits to sys/sys in the past weeks, should this need be MFCd. Discussed with: mmacy (in review and on IRC/Slack) Reviewed by: freqlabs (on openzfs repo) Differential Revision: https://reviews.freebsd.org/D26218 Notes: svn path=/head/; revision=366657
* loader: zfs should support bootonce an nextbootToomas Soome2020-09-211-20/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bootonce feature is temporary, one time boot, activated by "bectl activate -t BE", "bectl activate -T BE" will reset the bootonce flag. By default, the bootonce setting is reset on attempt to boot and the next boot will use previously active BE. By setting zfs_bootonce_activate="YES" in rc.conf, the bootonce BE will be set permanently active. bootonce dataset name is recorded in boot pool labels, bootenv area. in case of nextboot, the nextboot_enable boolean variable is recorded in freebsd:nvstore nvlist, also stored in boot pool label bootenv area. On boot, the loader will process /boot/nextboot.conf if nextboot_enable is "YES", and will set nextboot_enable to "NO", preventing /boot/nextboot.conf processing on next boot. bootonce and nextboot features are usable in both UEFI and BIOS boot. To use bootonce/nextboot features, the boot loader needs to be updated on disk; if loader.efi is stored on ESP, then ESP needs to be updated and for BIOS boot, stage2 (zfsboot or gptzfsboot) needs to be updated (gpart or other tools). At this time, only lua loader is updated. Sponsored by: Netflix, Klara Inc. Differential Revision: https://reviews.freebsd.org/D25512 Notes: svn path=/head/; revision=365938
* dtrace: fix fbt return probes on RISC-VKristof Provost2020-09-112-7/+13
| | | | | | | | | | | | | | | | Return values are passed in a0, so read it from there. We also pass a1 through to userspace, as the ABI allows small structs to be returned in registers a0/a1. While here read the register values directly from the trapframe rather than rtval, and remove the now unneeded argument from dtrace_invop(). Set fbtp_roffset so that we get the correct return location in arg0. Reviewed by: markj Sponsored by: Axiado Differential Revision: https://reviews.freebsd.org/D26389 Notes: svn path=/head/; revision=365626
* Tighten frame pointer checking in DTrace's amd64 stack unwinder.Mark Johnston2020-09-011-5/+9
| | | | | | | | | | | | Avoid assuming that the kernel was compiled with -fno-omit-frame-pointer. MFC after: 1 week Sponsored by: NetApp, Inc. Sponsored by: Klara, Inc. Notes: svn path=/head/; revision=365048
* ZFS: band-aid for -DNO_CLEANMatt Macy2020-08-251-1/+3
| | | | | | | | | Submitted by: Neal Chauhan Approved by: imp@ Differential Revision: https://reviews.freebsd.org/D26183 Notes: svn path=/head/; revision=364788
* Merge OpenZFS support in to HEAD.Matt Macy2020-08-25332-200595/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The primary benefit is maintaining a completely shared code base with the community allowing FreeBSD to receive new features sooner and with less effort. I would advise against doing 'zpool upgrade' or creating indispensable pools using new features until this change has had a month+ to soak. Work on merging FreeBSD support in to what was at the time "ZFS on Linux" began in August 2018. I first publicly proposed transitioning FreeBSD to (new) OpenZFS on December 18th, 2018. FreeBSD support in OpenZFS was finally completed in December 2019. A CFT for downstreaming OpenZFS support in to FreeBSD was first issued on July 8th. All issues that were reported have been addressed or, for a couple of less critical matters there are pull requests in progress with OpenZFS. iXsystems has tested and dogfooded extensively internally. The TrueNAS 12 release is based on OpenZFS with some additional features that have not yet made it upstream. Improvements include: project quotas, encrypted datasets, allocation classes, vectorized raidz, vectorized checksums, various command line improvements, zstd compression. Thanks to those who have helped along the way: Ryan Moeller, Allan Jude, Zack Welch, and many others. Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D25872 Notes: svn path=/head/; revision=364746
* amd64 pmap: LA57 AKA 5-level pagingKonstantin Belousov2020-08-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since LA57 was moved to the main SDM document with revision 072, it seems that we should have a support for it, and silicons are coming. This patch makes pmap support both LA48 and LA57 hardware. The selection of page table level is done at startup, kernel always receives control from loader with 4-level paging. It is not clear how UEFI spec would adapt LA57, for instance it could hand out control in LA57 mode sometimes. To switch from LA48 to LA57 requires turning off long mode, requesting LA57 in CR4, then re-entering long mode. This is somewhat delicate and done in pmap_bootstrap_la57(). AP startup in LA57 mode is much easier, we only need to toggle a bit in CR4 and load right value in CR3. I decided to not change kernel map for now. Single PML5 entry is created that points to the existing kernel_pml4 (KML4Phys) page, and a pml5 entry to create our recursive mapping for vtopte()/vtopde(). This decision is motivated by the fact that we cannot overcommit for KVA, so large space there is unusable until machines start providing wider physical memory addressing. Another reason is that I do not want to break our fragile autotuning, so the KVA expansion is not included into this first step. Nice side effect is that minidumps are compatible. On the other hand, (very) large address space is definitely immediately useful for some userspace applications. For userspace, numbering of pte entries (or page table pages) is always done for 5-level structures even if we operate in 4-level mode. The pmap_is_la57() function is added to report the mode of the specified pmap, this is done not to allow simultaneous 4-/5-levels (which is not allowed by hw), but to accomodate for EPT which has separate level control and in principle might not allow 5-leve EPT despite x86 paging supports it. Anyway, it does not seems critical to have 5-level EPT support now. Tested by: pho (LA48 hardware) Reviewed by: alc Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D25273 Notes: svn path=/head/; revision=364527
* Use devctl.h instead of bus.h to reduce newbus pollution.Warner Losh2020-08-211-1/+1
| | | | | | | | | | There's no need for these parts of the kernel to know about newbus, so narrow what is included to devctl.h for device_notify_*. Suggested by: kib@ Notes: svn path=/head/; revision=364442
* zfs: add an option to the bootloader to rewind the ZFS checkpointMariusz Zaborski2020-08-184-5/+28
| | | | | | | | | | | | | | | | | | The checkpoints are another way of keeping the state of ZFS. During the rewind, the pool has to be exported. This makes checkpoints unusable when using ZFS as root. Add the option to rewind the ZFS checkpoint at the boot time. If checkpoint exists, a new option for rewinding a checkpoint will appear in the bootloader menu. We fully support boot environments. If the rewind option is selected, the boot loader will show a list of boot environments that existed before the checkpoint. Reviewed by: tsoome, allanjude, kevans (ok with high-level overview) Differential Revision: https://reviews.freebsd.org/D24920 Notes: svn path=/head/; revision=364355
* Fix linker error in libuutil with recent LLVMAlex Richardson2020-08-073-11/+2
| | | | | | | | | | | | | | | | Not marking the function as static can result in a linker error: undefined reference to __assfail [--no-allow-shlib-undefined] I noticed this error after updating our CHERI LLVM to the latest upstream LLVM HEAD revision. This change effectively reverts r329984 and marks dmu_buf_init_user as static (which keeps the GCC build happy). Reviewed By: #zfs, asomers, freqlabs, mav Differential Revision: https://reviews.freebsd.org/D25663 Notes: svn path=/head/; revision=364027
* Fix cddl tools bootstrapping on macOS and LinuxAlex Richardson2020-08-073-3/+20
| | | | | | | | Reviewed By: brooks Differential Revision: https://reviews.freebsd.org/D25979 Notes: svn path=/head/; revision=364022
* MFOpenZFS: Add support for boot environment data to be stored in the labelToomas Soome2020-08-056-14/+242
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We are building new bootonce mechanism (previously zfs bootnext) and it is based on this OpenZFS change. Since this patch is nicely self contained, I am commiting it as is, and we can stack our changes. Original patch description follows: Modern bootloaders leverage data stored in the root filesystem to enable some of their powerful features. GRUB specifically has a grubenv file which can store large amounts of configuration data that can be read and written at boot time and during normal operation. This allows sysadmins to configure useful features like automated failover after failed boot attempts. Unfortunately, due to the Copy-on-Write nature of ZFS, the standard behavior of these tools cannot handle writing to ZFS files safely at boot time. We need an alternative way to store data that allows the bootloader to make changes to the data. This work is very similar to work that was done on Illumos to enable similar functionality in the FreeBSD bootloader. This patch is different in that the data being stored is a raw grubenv file; this file can store arbitrary variables and values, and the scripting provided by grub is powerful enough that special structures are not required to implement advanced behavior. We repurpose the second padding area in each label to store the grubenv file, protected by an embedded checksum. We add two ioctls to get and set this data, and libzfs_core and libzfs functions to access them more easily. There are no direct command line interfaces to these functions; these will be added directly to the bootloader utilities. Reviewed-by: Pavel Zakharov <pavel.zakharov@delphix.com> Reviewed-by: Matthew Ahrens <mahrens@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Paul Dagnelie <pcd@delphix.com> Closes #10009 Obtained from: OpenZFS Sponsored by: Netflix, Klara Inc. Notes: svn path=/head/; revision=363911
* zfs_keys_nextboot array is missing ZPOOL_CONFIG_POOL_GUID and ZPOOL_CONFIG_GUIDToomas Soome2020-08-051-1/+3
| | | | | | | | | | | | As we do check the incomint nvlist, we either need to list all possible keys or use wildcard. PR: 248462 Reported by: larafercue@gmail.com Sponsored by: Netflix, Klara Inc. Notes: svn path=/head/; revision=363910
* vfs: remove the obsolete privused argument from vaccessMateusz Guzik2020-08-051-1/+1
| | | | | | | | This brings argument count down to 6, which is passable without the stack on amd64. Notes: svn path=/head/; revision=363893
* zfs: add support for lockless lookupMateusz Guzik2020-07-255-10/+147
| | | | | | | | Tested by: pho (in a patchset, previous version) Differential Revision: https://reviews.freebsd.org/D25581 Notes: svn path=/head/; revision=363522
* vfs: introduce vnode sequence countersMateusz Guzik2020-07-251-0/+3
| | | | | | | | | | | Modified on each permission change and link/unlink. Reviewed by: kib Tested by: pho (in a patchset) Differential Revision: https://reviews.freebsd.org/D25573 Notes: svn path=/head/; revision=363517
* dtrace/fbt: fix return probe arguments on armAndriy Gapon2020-07-212-7/+13
| | | | | | | | | | | | | | | | | | | | | arg0 should be an offset of the return point within the function, arg1 should be the return value. Previously the return probe had arguments as if for the entry probe. Tested on armv7. andrew noted that the same problem seems to be present on arm64, mips, and riscv. I am not sure if I will get around to fixing those. So, platform users or anyone looking to make a contribution please be aware of this opportunity. Reviewed by: markj MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D25685 Notes: svn path=/head/; revision=363383
* Fix a memory leak in dsl_scan_visitbp().Mark Johnston2020-07-201-1/+1
| | | | | | | | | | | | This should be triggered only if arc_read() fails, i.e., quite rarely. The same logic is already present in OpenZFS. PR: 247445 Submitted by: jdolecek@NetBSD.org MFC after: 1 week Notes: svn path=/head/; revision=363373
* Don't overflow the trap frame when accessing lr or xzr.Andrew Turner2020-07-171-4/+29
| | | | | | | | | | | | | | | | When emulating a load pair or store pair in dtrace on arm64 we need to copy the data between the stack and trap frame. When the registers are either the link register or the zero register we will access memory past the end of the trap frame as these are encoded as registers 30 and 31 respectively while the array they access only has 30 entries. Fix this by creating 2 helper functions to perform the operation with special cases for these registers. Sponsored by: Innovate UK Notes: svn path=/head/; revision=363272
* Fix page fault in zfsctl_snapdir_getattrAlan Somers2020-07-021-1/+2
| | | | | | | | | | | | | | | Must acquire the z_teardown_lock before accessing the zfsvfs_t object. I can't reproduce this panic on demand, but this looks like the correct solution. PR: 247668 Reviewed by: avg MFC after: 2 weeks Sponsored by: Axcient Differential Revision: https://reviews.freebsd.org/D25543 Notes: svn path=/head/; revision=362891
* Fix "current" variable name conflict with openzfsMatt Macy2020-06-271-39/+39
| | | | | | | | | The variable "current" is an alias for curthread in openzfs. Rename all variable uses of current in dtrace.c to curstate. Notes: svn path=/head/; revision=362667
* MFOpenZFS: Add basic zfs ioc input nvpair validationToomas Soome2020-06-232-79/+376
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want newer versions of libzfs_core to run against an existing zfs kernel module (i.e. a deferred reboot or module reload after an update). Programmatically document, via a zfs_ioc_key_t, the valid arguments for the ioc commands that rely on nvpair input arguments (i.e. non legacy commands from libzfs_core). Automatically verify the expected pairs before dispatching a command. This initial phase focuses on the non-legacy ioctls. A follow-on change can address the legacy ioctl input from the zfs_cmd_t. The zfs_ioc_key_t for zfs_keys_channel_program looks like: static const zfs_ioc_key_t zfs_keys_channel_program[] = { {"program", DATA_TYPE_STRING, 0}, {"arg", DATA_TYPE_UNKNOWN, 0}, {"sync", DATA_TYPE_BOOLEAN_VALUE, ZK_OPTIONAL}, {"instrlimit", DATA_TYPE_UINT64, ZK_OPTIONAL}, {"memlimit", DATA_TYPE_UINT64, ZK_OPTIONAL}, }; Introduce four input errors to identify specific input failures (in addition to generic argument value errors like EINVAL, ERANGE, EBADF, and E2BIG). ZFS_ERR_IOC_CMD_UNAVAIL the ioctl number is not supported by kernel ZFS_ERR_IOC_ARG_UNAVAIL an input argument is not supported by kernel ZFS_ERR_IOC_ARG_REQUIRED a required input argument is missing ZFS_ERR_IOC_ARG_BADTYPE an input argument has an invalid type Reviewed by: allanjude Obtained from: OpenZFS Sponsored by: Netflix, Klara Inc. Differential Revision: https://reviews.freebsd.org/D25393 Notes: svn path=/head/; revision=362531
* MFOpenZFS: Add zio_ddt_free()+ddt_phys_decref() error handlingAllan Jude2020-06-222-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | The assumption in zio_ddt_free() is that ddt_phys_select() must always find a match. However, if that fails due to a damaged DDT or some other reason the code will NULL dereference in ddt_phys_decref(). While this should never happen it has been observed on various platforms. The result is that unless your willing to patch the ZFS code the pool is inaccessible. Therefore, we're choosing to more gracefully handle this case rather than leave it fatal. http://mail.opensolaris.org/pipermail/zfs-discuss/2012-February/050972.html https://github.com/openzfs/zfs/commit/5dc6af0eec29b119b731c793037fd77214fc9438 Reported by: Pierre Beyssac Obtained from: OpenZFS MFC after: 2 weeks Sponsored by: Klara Inc. Notes: svn path=/head/; revision=362505
* loader: create single zfs nextboot implementationToomas Soome2020-06-201-3/+32
| | | | | | | | | | | | | | | | | | | | We should have nextboot feature implemented in libsa zfs code. To get there, I have created zfs_nextboot() implementation based on two sources, our current simple textual string based approach with added structured boot label PAD structure from OpenZFS. Secondly, all nvlist details are moved to separate source file and restructured a bit. This is done to provide base support to add nvlist add/update feature in followup updates. And finally, the zfsboot/gptzfsboot disk access functions are swapped to use libi386 and libsa. Sponsored by: Netflix, Klara Inc. Differential Revision: https://reviews.freebsd.org/D25324 Notes: svn path=/head/; revision=362431
* ZFS: Allow setting checksum=skein on boot poolsAllan Jude2020-06-191-10/+1
| | | | | | | | | PR: 245889 Reported by: delphij Sponsored by: Klara Inc. Notes: svn path=/head/; revision=362396
* Fix export_args ex_flags field so that is 64bits, the same as mnt_flags.Rick Macklem2020-06-141-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since mnt_flags was upgraded to 64bits there has been a quirk in "struct export_args", since it hold a copy of mnt_flags in ex_flags, which is an "int" (32bits). This happens to currently work, since all the flag bits used in ex_flags are defined in the low order 32bits. However, new export flags cannot be defined. Also, ex_anon is a "struct xucred", which limits it to 16 additional groups. This patch revises "struct export_args" to make ex_flags 64bits and replaces ex_anon with ex_uid, ex_ngroups and ex_groups (which points to a groups list, so it can be malloc'd up to NGROUPS in size. This requires that the VFS_CHECKEXP() arguments change, so I also modified the last "secflavors" argument to be an array pointer, so that the secflavors could be copied in VFS_CHECKEXP() while the export entry is locked. (Without this patch VFS_CHECKEXP() returns a pointer to the secflavors array and then it is used after being unlocked, which is potentially a problem if the exports entry is changed. In practice this does not occur when mountd is run with "-S", but I think it is worth fixing.) This patch also deleted the vfs_oexport_conv() function, since do_mount_update() does the conversion, as required by the old vfs_cmount() calls. Reviewed by: kib, freqlabs Relnotes: yes Differential Revision: https://reviews.freebsd.org/D25088 Notes: svn path=/head/; revision=362158
* fix up r362047: a call to zvol_*_minors() was not hidden from userlandAndriy Gapon2020-06-111-0/+2
| | | | | | | | | Reported by: CI/FreeBSD-head-powerpc64-build MFC after: 5 weeks X-MFC with: r362047 Notes: svn path=/head/; revision=362048
* rework how ZVOLs are updated in response to DSL operationsAndriy Gapon2020-06-1110-72/+212
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this change all ZVOL updates are initiated from the SPA sync context instead of a mix of the sync and open contexts. The updates are queued to be applied by a dedicated thread in the original order. This should ensure that ZVOLs always accurately reflect the corresponding datasets. ZFS ioctl operations wait on the mentioned thread to complete its work. Thus, the illusion of the synchronous ZVOL update is preserved. At the same time, the SPA sync thread never blocks on ZVOL related operations avoiding problems like reported in bug 203864. This change is based on earlier work in the same direction: D7179 and D14669 by Anthoine Bourgeois. D7179 tried to perform ZVOL operations in the open context and that opened races between them. D14669 uses a design very similar to this change but with different implementation details. This change also heavily borrows from similar code in ZoL, but there are many differences too. See: - https://github.com/zfsonlinux/zfs/commit/a0bd735adb1b1eb81fef10b4db102ee051c4d4ff - https://github.com/zfsonlinux/zfs/issues/3681 - https://github.com/zfsonlinux/zfs/issues/2217 PR: 203864 MFC after: 5 weeks Sponsored by: CyberSecure Differential Revision: https://reviews.freebsd.org/D23478 Notes: svn path=/head/; revision=362047
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-16 14:27:49 +0000