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  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]
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.

Powered by blists - more mailing lists