On Tue, Nov 22, 2022 at 09:41:07AM -0800, Mike Kravetz wrote: > On 11/22/22 10:05, David Hildenbrand wrote: > > On 21.11.22 22:33, Andrew Morton wrote: > > > On Mon, 21 Nov 2022 09:05:43 +0100 David Hildenbrand <david@xxxxxxxxxx> wrote: > > > > > > > > > MikeK do you have test cases? > > > > > > > > > > Sorry, I do not have any test cases. > > > > > > > > > > I can ask one of our product groups about their usage. But, that would > > > > > certainly not be a comprehensive view. > > > > > > > > With > > > > > > > > https://lkml.kernel.org/r/20221116102659.70287-1-david@xxxxxxxxxx > > > > > > > > on it's way, the RDMA concern should be gone, hopefully. > > > > > > > > @Andrew, can you queue this one? Thanks. > > > > > > This is all a little tricky. > > > > > > It's not good that 6.0 and earlier permit unprivileged userspace to > > > trigger a WARN. But we cannot backport this fix into earlier kernels > > > because it requires the series "mm/gup: remove FOLL_FORCE usage from > > > drivers (reliable R/O long-term pinning)". > > > > > > Is it possible to come up with a fix for 6.1 and earlier which won't > > > break RDMA? > > > > Let's recap: > > Thanks! > > > > > (1) Nobody so far reported a RDMA regression, it was all pure > > speculation. The only report we saw was via ptrace when fuzzing > > syscalls. > > > > (2) To trigger it, one would need a hugetlb MAP_PRIVATE mappings without > > PROT_WRITE. For example: > > > > mmap(0, SIZE, PROT_READ, > > MAP_PRIVATE|MAP_ANON|MAP_HUGETLB|MAP_HUGE_2MB, -1, 0) > > or > > mmap(0, SIZE, PROT_READ, MAP_PRIVATE, hugetlbfd, 0) > > > > While that's certainly valid, it's not the common use case with > > hugetlb pages. > > FWIW, I did check with our product teams and they do not knowingly make use > of private mappings without write. Of course, that is only a small and > limited sample size. Yeah, if it is only this case I'm comfortable as well Jason
