On Sun, Mar 27, 2016 at 8:23 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: > On Sun, Mar 27, 2016 at 05:03:44AM -0700, Linus Torvalds wrote: >> >> Unless you're using overlayfs or per-file encryption, I'm not seeing >> that any of that should make any difference (but it's entirely >> possible I'm missing something). >> >> Was it entirely repeatable before? Maybe it just happened to happen >> without that update, and then happened to _not_ happen after you >> rebooted with that 'dev' branch pulled in? >> >> Anyway, I don't think that DEBUG_LOCKS_WARN_ON() in >> >> kernel/locking/lockdep.c:2017 __lock_acquire >> >> would be an ext4 issue, it looks more like an internal lockdep issue. > > That's my guess. I've been doing a lot of regression testing with > lockdep enabled, and I haven't seen the problem which Sedat has > reported. > > At the moment I'm testing my ext4 bug fixes on top of 243d5067858310 > (Merge branch 'overlayfs-linus'....) dating from March 22nd, and the > lockdep merges came much earlier than that, on March 15th, just two > days after v4.5 was released, and I'm not noticing any lockdep issues > with ext4 while running all of my regression tests. > So far I can say, that I am *not* seeing this with ext4.git#dev on top of v4.6-rc1. Not sure how I can force/reproduce the lockdep call-trace. Any idea on how to check/test lockdep issues like this? LTP? (Latest tarball: ltp-full-20160126.tar.xz? xfstests? xfstests-bld? Does the linux-sources ship some test-suite? - Sedat - -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
