lkml.org 
[lkml]   [2020]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: ARM: vmsplit 4g/4g
    On Sun, Jun 7, 2020 at 2:59 PM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:
    > On Sat, May 16, 2020 at 09:35:57AM +0200, Arnd Bergmann wrote:
    > > On Sat, May 16, 2020 at 8:06 AM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:
    >
    > > > Okay, so the conclusion i take is,
    > > > 1. VMSPLIT 4G/4G have to live alongside highmem
    > > > 2. For user space copy, do pinning followed by kmap
    >
    > > Right, though kmap_atomic() should be sufficient here
    > > because it is always a short-lived mapping.
    >
    > get_user_pages_fast() followed by kmap_atomic() & then memcpy() seems
    > to work in principle for user copy.

    Nice!

    I think you have to use get_user_pages() though instead of
    get_user_pages_fast(),
    in order to be able to check the permission bits to prevent doing a
    copy_to_user()
    into read-only mappings.

    > Verified in a crude way by pointing TTBR0 to a location that has user
    > pgd's cleared upon entry to copy_to_user() & restoring TTBR0 to
    > earlier value after user copying was done and ensuring boot.

    Do you want me to review the uaccess patch to look for any missing
    corner cases, or do you want to do the whole set of user access helpers
    first?

    > Meanwhile more testing w/ kernel static mapping in vmalloc space
    > revealed a major issue, w/ LPAE it was not booting. There were issues
    > related to pmd handling, w/ !LPAE those issues were not present as pmd
    > is in effect equivalent to pgd. The issues has been fixed, though now
    > LPAE boots, but feel a kind of fragile, will probably have to revisit
    > it.

    Ok.

    Arnd

    \
     
     \ /
      Last update: 2020-06-07 21:27    [W:5.113 / U:0.096 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site