linux-ext4 - [Bug 203317] WARNING: CPU: 2 PID: 925 at fs/ext4/inode.c:3897 ext4_set_page

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: <bug-203317-13602-Wwee071Xam@https.bugzilla.kernel.org/>
Date:   Mon, 09 Sep 2019 08:19:54 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 203317] WARNING: CPU: 2 PID: 925 at fs/ext4/inode.c:3897
 ext4_set_page_dirty+0x39/0x50

https://bugzilla.kernel.org/show_bug.cgi?id=203317

--- Comment #8 from howaboutsynergy (howaboutsynergy@...me) ---
But, I 've already tested that reverting that commit gets rid of the freeze.
Even if the cause is somewhere else, it appears that the regression is
introduced by the very commit I mentioned:
aa56a292ce623734ddd30f52d73f527d1f3529b5 (and that commit mentions this issue -
which is why I'm posting here)

I mean, the only thing I could try to do is to somehow find a way to get a
stacktrace while the system is frozen, but for some reason even manually
causing kernel to crash(sysrq+c) fails to allow me to read the dump via 'crash'
afterwards ...

Also, I've encountered the freeze during chromium compilation (possibly because
it uses at least 15+GiB of 32G of RAM due to jumbo). Even though it's easier
for me to trigger the freeze via the 'memfreeze' script. So I expect users will
hit this soon. (assuming they use some kind of ext4, I use it on the /tmp and
/var/tmp zram)

Not sure how else to say it. I used bisect to find the commit(a while ago),
tested with and without it. 

Ahh forgot to mention that what I said in Comment 6 (that freeze/race) happens
when the commit is NOT reverted.

But this isn't the same freeze that happens during the memory pressure which
simply does a ton of disk reading. I know because I'm already patching against
it by keeping Active(file) above 300MiB. (see Comment 4)

I'm happy to try other things to help with this. Please let me know what I
could do.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.