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]
Date:   Tue, 11 Dec 2018 11:21:17 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 201631] WARNING: CPU: 11 PID: 29593 at fs/ext4/inode.c:3927
 .ext4_set_page_dirty+0x70/0xb0

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

Jan Kara (jack@...e.cz) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |benh@...nel.crashing.org,
                   |                            |jack@...e.cz,
                   |                            |michael@...erman.id.au

--- Comment #8 from Jan Kara (jack@...e.cz) ---
The lockups and ext4 warnings are likely a different thing. So please report
the lockup to linux-fsdevel@...r.kernel.org and also CC Al Viro
<viro@...iv.linux.org.uk> on it.

The WARN_ON we hit in ext4 is likely:

WARN_ON_ONCE(!PageLocked(page) && !PageDirty(page));

because we don't expect page cache page to be marked dirty when unmapping it
from page tables. It could be a powerpc specific race in handling of page table
entry (PTE) flags as I don't see how PTE could be marked dirty without a page
being already dirty.

Seeing you hit this already twice on 4.20-rc's and never on 4.19.x, it could be
some recent powerpc change that is triggering this. I've skimmed through
powerpc changelogs and didn't find anything obviously matching but there were
quite some mm changes pulled in this merge window. Powerpc guys, any idea how
could _PAGE_DIRTY PTE bit get spuriously set? Normally, we should clear the
_PAGE_DIRTY bit in page_mkclean() together with write-protecting the PTE and we
are marking the page dirty whenever writeable PTE is created... So clean
pagecache page with _PAGE_DIRTY in PTE is an invalid combination.

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

Powered by blists - more mailing lists