linux-ext4 - [Bug 201631] WARNING: CPU: 11 PID: 29593 at fs/ext4/inode.c:3927 .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-201631-13602-72DMTbeQQ3@https.bugzilla.kernel.org/>
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.