linux-ext4 - [v4.14-rc1 regression] ext4 failed fstests generic/233 quota test

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-next>] [day] [month] [year] [list]

Date:   Sun, 8 Oct 2017 13:42:36 +0800
From:   Eryu Guan <eguan@...hat.com>
To:     linux-ext4@...r.kernel.org
Cc:     linux-fsdevel@...r.kernel.org, Jan Kara <jack@...e.cz>,
        Eric Whitney <enwlinux@...il.com>
Subject: [v4.14-rc1 regression] ext4 failed fstests generic/233 quota test

Hi all,

After generic/232 failure has been reported and resolved[1], I still
could see fstests generic/233 failure on ext4 with v4.14-rc3 kernel.
This is not 100% reproduced (block usage needs to exceed soft limit) but
reliably.

 seed = S
 Comparing user usage
-Comparing group usage
+4c4
+< #1001     +-   32064   32000   32000            998  1000  1000       
+---
+> #1001     +-   32064   32000   32000  7days     998  1000  1000

Grace time was not printed by repquota right after the fsstress run when
we exceeded the block soft limit, and only printed after a quotacheck
was run.  With v4.13 kernel, block grace time could be printed
immediately after the fsstress run.

git bisect pointed the first bad to commit 7b9ca4c61bc2 ("quota: Reduce
contention on dq_data_lock"). And I've confirmed the bisection result by
converting the commit in question and running generic/233 for 20
iterations without a failure.

Thanks,
Eryu

[1] https://www.spinics.net/lists/linux-ext4/msg58372.html