[Bug 203317] WARNING: CPU: 2 PID: 925 at fs/ext4/inode.c:3897 ext4_set_page_dirty+0x39/0x50

[bugzilla-daemon@bugzilla.kernel.org]

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

--- Comment #8 from howaboutsynergy (howaboutsynergy@pm.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.