linux-kernel - Re: [PATCH v2 03/10] mm/thp: try_to_unmap() use TTU

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: <20210609102544.lua6zb6j5g4gpsxx@box.shutemov.name>
Date:   Wed, 9 Jun 2021 13:25:44 +0300
From:   "Kirill A. Shutemov" <kirill@...temov.name>
To:     Hugh Dickins <hughd@...gle.com>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 03/10] mm/thp: try_to_unmap() use TTU_SYNC for safe
 splitting (fwd)

On Tue, Jun 08, 2021 at 09:12:20PM -0700, Hugh Dickins wrote:
> 
> 
> ---------- Forwarded message ----------
> Date: Tue, 8 Jun 2021 21:10:19 -0700 (PDT)
> From: Hugh Dickins <hughd@...gle.com>
> To: Andrew Morton <akpm@...ux-foundation.org>
> Cc: Hugh Dickins <hughd@...gle.com>,
>     Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>,
>     Yang Shi <shy828301@...il.com>, Wang Yugui <wangyugui@...-tech.com>,
>     Matthew Wilcox <willy@...radead.org>,
>     Naoya Horiguchi <naoya.horiguchi@....com>,
>     Alistair Popple <apopple@...dia.com>, Ralph Campbell <rcampbell@...dia.com>,
>     Zi Yan <ziy@...dia.com>, Miaohe Lin <linmiaohe@...wei.com>,
>     Minchan Kim <minchan@...nel.org>, Jue Wang <juew@...gle.com>,
>     Peter Xu <peterx@...hat.com>, Jan Kara <jack@...e.cz>,
>     Shakeel Butt <shakeelb@...gle.com>, Oscar Salvador <osalvador@...e.de>
> Subject: [PATCH v2 03/10] mm/thp: try_to_unmap() use TTU_SYNC for safe splitting
> 
> Stressing huge tmpfs often crashed on unmap_page()'s VM_BUG_ON_PAGE
> (!unmap_success): with dump_page() showing mapcount:1, but then its
> raw struct page output showing _mapcount ffffffff i.e. mapcount 0.
> 
> And even if that particular VM_BUG_ON_PAGE(!unmap_success) is removed,
> it is immediately followed by a VM_BUG_ON_PAGE(compound_mapcount(head)),
> and further down an IS_ENABLED(CONFIG_DEBUG_VM) total_mapcount BUG():
> all indicative of some mapcount difficulty in development here perhaps.
> But the !CONFIG_DEBUG_VM path handles the failures correctly and silently.
> 
> I believe the problem is that once a racing unmap has cleared pte or pmd,
> try_to_unmap_one() may skip taking the page table lock, and emerge from
> try_to_unmap() before the racing task has reached decrementing mapcount.
> 
> Instead of abandoning the unsafe VM_BUG_ON_PAGE(), and the ones that
> follow, use PVMW_SYNC in try_to_unmap_one() in this case: adding TTU_SYNC
> to the options, and passing that from unmap_page().
> 
> When CONFIG_DEBUG_VM, or for non-debug too?  Consensus is to do the same
> for both: the slight overhead added should rarely matter, except perhaps
> if splitting sparsely-populated multiply-mapped shmem.  Once confident
> that bugs are fixed, TTU_SYNC here can be removed, and the race tolerated.
> 
> Fixes: fec89c109f3a ("thp: rewrite freeze_page()/unfreeze_page() with generic rmap walkers")
> Signed-off-by: Hugh Dickins <hughd@...gle.com>
> Cc: <stable@...r.kernel.org>

Acked-by: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>

-- 
 Kirill A. Shutemov