linux-kernel - [PATCH 0/2] Try to release mmap_lock temporarily in smaps

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-next>] [day] [month] [year] [list]

Message-ID: <1597120955-16495-1-git-send-email-chinwen.chang@mediatek.com>
Date:   Tue, 11 Aug 2020 12:42:33 +0800
From:   Chinwen Chang <chinwen.chang@...iatek.com>
To:     Matthias Brugger <matthias.bgg@...il.com>,
        Michel Lespinasse <walken@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Daniel Jordan <daniel.m.jordan@...cle.com>,
        Davidlohr Bueso <dbueso@...e.de>,
        Chinwen Chang <chinwen.chang@...iatek.com>,
        Alexey Dobriyan <adobriyan@...il.com>,
        "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        Jason Gunthorpe <jgg@...pe.ca>,
        Steven Price <steven.price@....com>,
        Song Liu <songliubraving@...com>,
        Jimmy Assarsson <jimmyassarsson@...il.com>,
        Huang Ying <ying.huang@...el.com>
CC:     <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-mediatek@...ts.infradead.org>,
        <linux-fsdevel@...r.kernel.org>, <wsd_upstream@...iatek.com>
Subject: [PATCH 0/2] Try to release mmap_lock temporarily in smaps_rollup

Recently, we have observed some janky issues caused by unpleasantly long
contention on mmap_lock which is held by smaps_rollup when probing large
processes. To address the problem, we let smaps_rollup detect if anyone
wants to acquire mmap_lock for write attempts. If yes, just release the
lock temporarily to ease the contention.

smaps_rollup is a procfs interface which allows users to summarize the
process's memory usage without the overhead of seq_* calls. Android uses
it to sample the memory usage of various processes to balance its memory
pool sizes. If no one wants to take the lock for write requests, smaps_rollup
with this patch will behave like the original one.

Although there are on-going mmap_lock optimizations like range-based locks,
the lock applied to smaps_rollup would be the coarse one, which is hard to
avoid the occurrence of aforementioned issues. So the detection and temporary
release for write attempts on mmap_lock in smaps_rollup is still necessary.

Chinwen Chang (2):
  mmap locking API: add mmap_lock_is_contended()
  mm: proc: smaps_rollup: do not stall write attempts on mmap_lock

 fs/proc/task_mmu.c        | 21 +++++++++++++++++++++
 include/linux/mmap_lock.h |  5 +++++
 2 files changed, 26 insertions(+)