linux-kernel - Re: [RFC PATCH 0/2] mm/gup: fix gup_fast with dynamic page table folding

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]

Date:   Mon, 31 Aug 2020 13:53:36 +0200
From:   Christian Borntraeger <borntraeger@...ibm.com>
To:     Gerald Schaefer <gerald.schaefer@...ux.ibm.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-mm <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        linux-s390@...r.kernel.org, Heiko Carstens <hca@...ux.ibm.com>,
        Claudio Imbrenda <imbrenda@...ux.ibm.com>
Subject: Re: [RFC PATCH 0/2] mm/gup: fix gup_fast with dynamic page table
 folding



On 28.08.20 16:03, Gerald Schaefer wrote:
[...]
> We came up with two possible fix-ups, both will introduce some gup-specific
> helper functions, which will have no effect on other archs than s390.
> 
> Patch 1 is the solution that has already been discussed in
> https://lkml.kernel.org/r/20190418100218.0a4afd51@mschwideX1
> It will additionally pass along pXd pointers in gup_pXd_range, and
> also introduce pXd_offset_orig for s390, which takes an additional
> pXd entry value parameter. This allows correctly returning / incrementing
> pointers while still preseving the READ_ONCE logic for gup_fast.
> 
> Patch 2 would instead introduce new gup_pXd_addr_end helpers, which take
> an additional pXd entry value parameter, that can be used on s390
> to determine the correct page table level and return corresponding
> end / boundary. With that, the pointer iteration will always
> happen in gup_pgd_range.
> 

> Comments / preferences are welcome. As a last resort, we might also
> revert back to the s390-specific gup_fast code, if none of the options
> are agreeable.

given that this is a data integrity issue, I think it would be good to 
have some feedback soon if option 1 or option 2 would be acceptable 
from a common code perspective. Andrew, who of the mm people would 
be the right one to decide?