linux-kernel - Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200311142905.GI3216816@arrakis.emea.arm.com>
Date:   Wed, 11 Mar 2020 14:29:05 +0000
From:   Catalin Marinas <catalin.marinas@....com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Nishanth Menon <nm@...com>,
        Santosh Shilimkar <santosh.shilimkar@...cle.com>,
        Tero Kristo <t-kristo@...com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Michal Hocko <mhocko@...e.com>,
        Rik van Riel <riel@...riel.com>,
        Santosh Shilimkar <ssantosh@...nel.org>,
        Dave Chinner <david@...morbit.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>,
        Yafang Shao <laoar.shao@...il.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Johannes Weiner <hannes@...xchg.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        kernel-team@...com, Kishon Vijay Abraham I <kishon@...com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Roman Gushchin <guro@...com>
Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker
 LRU

On Mon, Mar 09, 2020 at 08:46:18PM +0100, Arnd Bergmann wrote:
> On Mon, Mar 9, 2020 at 5:09 PM Russell King - ARM Linux admin
> <linux@...linux.org.uk> wrote:
> > On Mon, Mar 09, 2020 at 03:59:45PM +0000, Catalin Marinas wrote:
> > > On Sun, Mar 08, 2020 at 11:58:52AM +0100, Arnd Bergmann wrote:
> > > > - revisit CONFIG_VMSPLIT_4G_4G for arm32 (and maybe mips32)
> > > >   to see if it can be done, and what the overhead is. This is probably
> > > >   more work than the others combined, but also the most promising
> > > >   as it allows the most user address space and physical ram to be used.
> > >
> > > A rough outline of such support (and likely to miss some corner cases):
> > >
> > > 1. Kernel runs with its own ASID and non-global page tables.
> > >
> > > 2. Trampoline code on exception entry/exit to handle the TTBR0 switching
> > >    between user and kernel.
> > >
> > > 3. uaccess routines need to be reworked to pin the user pages in memory
> > >    (get_user_pages()) and access them via the kernel address space.
> > >
> > > Point 3 is probably the ugliest and it would introduce a noticeable
> > > slowdown in certain syscalls.
> 
> There are probably a number of ways to do the basic design. The idea
> I had (again, probably missing more corner cases than either of you
> two that actually understand the details of the mmu):
> 
> - Assuming we have LPAE, run the kernel vmlinux and modules inside
>   the vmalloc space, in the top 256MB or 512MB on TTBR1
> 
> - Map all the physical RAM (up to 3.75GB) into a reserved ASID
>   with TTBR0
> 
> - Flip TTBR0 on kernel entry/exit, and again during user access.
> 
> This is probably more work to implement than your idea, but
> I would hope this has a lower overhead on most microarchitectures
> as it doesn't require pinning the pages. Depending on the
> microarchitecture, I'd hope the overhead would be comparable
> to that of ARM64_SW_TTBR0_PAN.

This still doesn't solve the copy_{from,to}_user() case where both
address spaces need to be available during copy. So you either pin the
user pages in memory and access them via the kernel mapping or you
temporarily map (kmap?) the destination/source kernel address. The
overhead I'd expect to be significantly greater than ARM64_SW_TTBR0_PAN
for the uaccess routines. For user entry/exit, your suggestion is
probably comparable with SW PAN.

-- 
Catalin