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?
