Re: [PATCH v4 00/15] follow_pfn and other iomap races

2020-10-29 Thread Christoph Hellwig
On Thu, Oct 29, 2020 at 10:38:16AM +0100, Daniel Vetter wrote: > Hm so Jason and me discussed this, but e.g. the s390 is safe with with > just the pagetable locks. So we'd need two versions. > > The more practical problem is that I haven't found a reasonable way to > check that a passed in

Re: [PATCH v4 00/15] follow_pfn and other iomap races

2020-10-29 Thread Daniel Vetter
On Thu, Oct 29, 2020 at 10:28 AM Christoph Hellwig wrote: > > On Thu, Oct 29, 2020 at 10:25:16AM +0100, Daniel Vetter wrote: > > On Thu, Oct 29, 2020 at 9:57 AM Christoph Hellwig > > wrote: > > > > > > Maybe I'm missing something, but shouldn't follow_pfn be unexported > > > at the end of the

Re: [PATCH v4 00/15] follow_pfn and other iomap races

2020-10-29 Thread Christoph Hellwig
On Thu, Oct 29, 2020 at 10:25:16AM +0100, Daniel Vetter wrote: > On Thu, Oct 29, 2020 at 9:57 AM Christoph Hellwig wrote: > > > > Maybe I'm missing something, but shouldn't follow_pfn be unexported > > at the end of the series? > > kvm is a legit user and modular afaict. But since you can't use

Re: [PATCH v4 00/15] follow_pfn and other iomap races

2020-10-29 Thread Daniel Vetter
On Thu, Oct 29, 2020 at 9:57 AM Christoph Hellwig wrote: > > Maybe I'm missing something, but shouldn't follow_pfn be unexported > at the end of the series? kvm is a legit user and modular afaict. But since you can't use this without an mmu_notifier anyway (or digging around in pagetable

Re: [PATCH v4 00/15] follow_pfn and other iomap races

2020-10-29 Thread Christoph Hellwig
Maybe I'm missing something, but shouldn't follow_pfn be unexported at the end of the series?

[PATCH v4 00/15] follow_pfn and other iomap races

2020-10-26 Thread Daniel Vetter
Hi all Round 3 of my patch series to clamp down a bunch of races and gaps around follow_pfn and other access to iomem mmaps. Previous version: v1: https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/ v2: