linux-kernel - Re: [git pull] drm fixes for 6.11-rc6

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]

Message-ID: <CAHk-=wivPvBbaTnKgdH84gtWD-VXUD529L8t8-BxhPEwJvY+4w@mail.gmail.com>
Date: Mon, 2 Sep 2024 12:37:34 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Christian König <christian.koenig@....com>
Cc: Thomas Hellström <thomas.hellstrom@...ux.intel.com>, 
	Dave Airlie <airlied@...il.com>, Daniel Vetter <daniel.vetter@...ll.ch>, 
	dri-devel <dri-devel@...ts.freedesktop.org>, LKML <linux-kernel@...r.kernel.org>, 
	Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@....com>, Alex Deucher <alexdeucher@...il.com>, 
	lingshan.zhu@....com, Matthew Brost <matthew.brost@...el.com>
Subject: Re: [git pull] drm fixes for 6.11-rc6

On Mon, 2 Sept 2024 at 03:34, Christian König <christian.koenig@....com> wrote:
>
> Am 02.09.24 um 11:32 schrieb Thomas Hellström:
> >
> > The remap_pfn_range was last tried, at least in the context of the i915
> > driver IIRC by Christoph Hellwig but had to be ripped out since it
> > requires the mmap_lock in write mode. Here we have it only in read
> > mode.

Yeah, that does make things much more fragile. The "fill in multiple
pages" helpers are really meant to be used at mmap() time, not as some
kind of fault-around.

So remap_pfn_range() sets the vma flags etc, but it also depends on
being the only one to fill in the ptes, and will be *very* unhappy if
it finds something that has already been filled in.

And fault-around is *much* more fragile because unlike the mmap time
thing, it can happen concurrently with other faults, and you cannot
make assumptions about existing page table layout etc.

> The pre-faulting was increased because of virtualization. When KVM/XEN
> is mapping a BO into a guest the switching overhead for each fault is so
> high that mapping a lot of PFNs at the same time becomes beneficial.

Honestly, from a pure performance standpoint, if you can just do all
the page mapping at mmap() time, that would be *much* much better.

Then you can easily use that remap_pfn_range() function, and latencies
are much less of an issue in general (not because it would be any
faster, but simply because people don't tend to use mmap() in
latency-critical code - but taking a page fault is *easily* very
critical indeed).

                Linus