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
| ||
|
Message-ID: <20171008054236.GA10593@eguan.usersys.redhat.com> 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
Powered by blists - more mailing lists