<sys/types.h>: Get rid of udev_t. In a time long long ago, dev_t was a pointer, which later became cdev_t during the great cleanups, until it ended up being a uint32_t, just like udev_t. See for example the definitions of __dev_t in <sys/stat.h>. This commit cleans up further by removing the udev_t type, leaving just the POSIX dev_t type for both kernel and userland. Put it inside a _DEV_T_DECLARED to prepare for further cleanups in <sys/stat.h>.
kernel: Remove explicit dependencies on <sys/malloc.h> in headers. All except <net/if_var.h> for now, it needs decoupling in drm first. * Include <sys/malloc.h> in foo.c if they have kmalloc()/kfree() calls. * Consistently check if MALLOC_DECLARE was declared before. * <sys/mountctl.h>: include <sys/thread.h> for _KERNEL_STRUCTURES too since the "struct journal" embeds "struct thread". * <sys/tty.h>: Only two kernel sources makes use of M_TTYS. * <sys/socketvar2.h>: Make it kernel only header.
sys/dev/disk/dm: Remove dm_dev::dev_type This is unused, and also not necessary. dm core shouldn't need to be aware of target driver type. Target dependent actions are handled by target dependent handlers. dm targets have oop-like structure, so we don't want/need dm core to be able to do things like below. Also see d471f1f9 and 49784e7d. switch (dev->dev_type) { case DM_LINEAR_DEV: do_something_specific_to_linear(); break; case DM_STRIPE_DEV: do_something_specific_to_striped(); break; case ...: ...; break; }
sys/dev/disk/dm: Add dm-flakey target This commit adds a new dm target dm-flakey. This target simulates failing devices for testing purposes. See dm_target_flakey(4) for details. Note that using this dm target may results in some unstable status including kernel panic. For example hammer is likely to cause kernel panic by write data corruption by dm-flakey. Don't use this target over any block device in production. ===== Example1 - Error write I/Os # kldload dm_target_flakey # dmsetup create flakey1 --table "0 234436482 flakey ${DEV} 0 1 1" # newfs_hammer -L TEST /dev/mapper/flakey1 Volume 0 DEVICE /dev/mapper/flakey1 size 111.79GB initialize freemap volume 0 initializing the undo map (504 MB) newfs_hammer: Write volume 0 (/dev/mapper/flakey1): Input/output error # dmsetup remove /dev/mapper/flakey1 ===== Example2 - Silently drop write I/Os # newfs_hammer -L TEST ${DEV} > /dev/null # mount_hammer ${DEV} /HAMMER # cd /HAMMER # git clone /usr/local/src/dragonfly Cloning into 'dragonfly'... done. Checking out files: 100% (34434/34434), done. # cd # umount /HAMMER # dmsetup create flakey2 --table "0 234436482 flakey ${DEV} 0 1 1 1 drop_writes" # mount_hammer /dev/mapper/flakey2 /HAMMER # dmesg | tail -3 HAMMER() Critical error inode=-1 error=5 while flushing meta-data HAMMER() Forcing read-only mode HAMMER(TEST) mounted clean, no recovery needed # hammer volume-list /HAMMER /dev/mapper/flakey2 # mount | grep "/HAMMER" TEST on /HAMMER (hammer, local, read-only) # cd /HAMMER/dragonfly # git log -p > /dev/null; echo $? 0 # cd # umount /HAMMER # dmsetup remove /dev/mapper/flakey2 ===== Example3 - Corrupt read I/Os # dd if=/dev/zero of=${DEV} bs=1024 count=10000 >/dev/null 2>&1 # dmsetup create flakey3 --table "0 234436482 flakey ${DEV} 0 1 1 5 corrupt_bio_byte 1 r 65 0" # od -tx1 /dev/mapper/flakey3 | head -10 0000000 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0010000 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0010020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0020000 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0030000 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # dmsetup remove /dev/mapper/flakey3 # kldunload dm_target_flakey
sys/dev/disk/dm: Fix/refactor alloc/free functions [3/6] dm_dev_alloc()/free() * Make them static. * Make alloc() take name and uuid just like dm_pdev_alloc(). * Refactoring. dm_pdev_alloc()/free() * Fix memory leak. * Rename dm_pdev_rem() to dm_pdev_free(). A simple kfree function should be xxx_free() but not xxx_rem(). xxx_rem() isn't necessarily a name used for just kfree() in other files, which makes naming very confusing. * Refactoring.
sys/dev/disk/dm: Fix/refactor alloc/free functions [2/6] Rename dm_dev_rem() to dm_dev_lookup_evict(). There is dm_dev_remove(), and having remove()/rem() is confusing. Refactor dm_dev_lookup()/dm_dev_lookup_evict() using a common lookup function. Disable dm_dev_lookup_evict() by #if0. This function is only used for renaming, but renaming is not implemented.
sys/dev/disk/dm: Fix/refactor alloc/free functions [1/6] There are way too many functions with similar names that do something related to removing and/or freeing dm device. dm_dev_rem_dev() doesn't need to be a function so get rid of it. dm_dev_destroy() can be a static function.
sys/dev/disk/dm: Check if target has registered handlers Define which handlers are mandatory or optional. init(), destroy(), strategy() are (or should be) mandatory. Others aren't needed by all targets hence should be optional. Add sanity checks in dm_target_insert() to make sure targets have implemented and registered mandatory handlers. Cleanup struct dm_target by removing obvious comments and adding comments on mandatory/optional handlers.
sys/dev/disk/dm: Add dm_alloc_string() Add dm_alloc_string() which kmallocs char* from M_DM. It was confusing that targets had to use M_DM for status purpose while targets had their own M_DMXXX. Using this wrapper function makes target code less error prone when allocating a string without an extra comment on usage.
sys/dev/disk/dm: Remove upcall handler dm target's upcall() handler int (*upcall)(dm_table_entry_t *, struct buf *); implemented by dm targets acutally do nothing other than returning 0. Also note that upcall() is not used by dm core. The targets that are supposed to be relying on this api are obviously not working at the moment, however things aren't as simple as just implementing missing upcall() handler. upcall() is supposed to be something to do with targets like snapshot, but it lacks documentation and purpose of this api is not clear at all. Whoever tries to implement snapshot/etc will have to re-design dm core and appropriate handlers from scratch anyway without using the existing one.