linux-ext4 - Re: v4.19-rc2: ext4 direct I/O recursive locking complaint

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180915224410.GC8652@thunk.org>
Date:   Sat, 15 Sep 2018 18:44:10 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Bart Van Assche <bvanassche@....org>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: v4.19-rc2: ext4 direct I/O recursive locking complaint

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