On Sun, Sep 09, 2018 at 02:53:29PM -0700, Bart Van Assche wrote: > > While running blktests against kernel v4.19-rc2 the circular locking > complaint shown belown appeared. I never saw this complaint for any previous > kernel version, including v4.18. Could this be an ext4 regression? It's possible, although there wasn't any Direct I/O changes in ext4 between v4.18 and v4.19-rc2. I can't see any changes that would involve the code paths referenced in the lockdep: % git log --oneline v4.18..v4.19-rc2 -- fs/ext4 ac22b46a0b65 ext4: readpages() should submit IO as read-ahead e1fb4a086495 dax: remove VM_MIXEDMAP for fsdax and device dax 73ba2fb33c49 Merge tag 'for-4.19/block-20180812' of git://git.kernel.dk/linux-block 863c37fcb14f (tag: ext4_for_linus, ext4/origin, origin, d) ext4: remove unneeded variable "err" in ext4_mb_release_inode_pa() bc716523462f ext4: improve code readability in ext4_iget() 1a5d5e5d51e7 ext4: fix spectre gadget in ext4_mb_regular_allocator() 7d95178c7701 ext4: check for NUL characters in extended attribute's name 5ef2a6999367 ext4: use ext4_warning() for sb_getblk failure 9af0b3d12577 ext4: fix race when setting the bitmap corrupted flag f39b3f45dbcb ext4: reset error code in ext4_find_entry in fallback 430657b6be89 ext4: handle layout changes to pinned DAX mappings 62bbdd997467 ext4: use swap macro in mext_page_double_lock 21ac738ede0b ext4: check allocation failure when duplicating "data" in ext4_remount() 7f144fd046d9 ext4: fix warning message in ext4_enable_quotas() 6a0678a79bb3 ext4: super: extend timestamps to 40 bits 7b62b293200f ext4: use timespec64 for all inode times 5ffff8343222 ext4: use ktime_get_real_seconds for i_dtime af123b371859 ext4: use 64-bit timestamps for mmp_time a4d2aadca184 ext4: sysfs: print ext4_super_block fields as little-endian dbae2c551377 block: Define and use STAT_READ and STAT_WRITE Do you know which test triggered the lockdep failure? I've been looking at blktests, and the fact that they require modules means it's going require making changes in how I test my kernels if I want to use it easily. The problem is that I normally run the kernel test either launching it directly from kvm, or when I'm using gce, I upload the kernel image to the VM and then use kexec. This means I can run tests by plucking the kernel directly from the build tree --- there's no need for me to install kernel modules before I run a test.h In some cases, there's it's clear loading a module is required, because module parameters are needed to configure the module (null_blk, scsi_debug). In other cases, most notably loop, it's perfectly fine to run with the block driver compiled into the kernel. Until I can figure out a clean and fast way to install the necessary modules into my test appliance VM's, if I know which specific blktests triggered the failure, I can try to manually run the test. So if you can determine whether the lockdep failure is reproducible, preferably via running a single specific test in blktests, that'd be really helpful. Thanks, - Ted
