Re: [PATCH v2 08/17] s390/pci: Remove races against pte updates

2020-10-22 Thread Daniel Vetter
On Wed, Oct 21, 2020 at 09:55:57AM +0200, Niklas Schnelle wrote: > Hi Daniel, > > friendly ping. I haven't seen a new version of this patch series, > as I said I think your change for s390/pci is generally useful so > I'm curious, are you planning on sending a new version soon? > If you want you

Re: [PATCH v2 08/17] s390/pci: Remove races against pte updates

2020-10-21 Thread Niklas Schnelle
Hi Daniel, friendly ping. I haven't seen a new version of this patch series, as I said I think your change for s390/pci is generally useful so I'm curious, are you planning on sending a new version soon? If you want you can also just sent this patch with the last few nitpicks (primarily the mail

Re: [PATCH v2 08/17] s390/pci: Remove races against pte updates

2020-10-12 Thread Niklas Schnelle
... snip ... >>> Cc: linux-me...@vger.kernel.org >>> Cc: Niklas Schnelle >>> Cc: Gerald Schaefer >>> Cc: linux-s...@vger.kernel.org >>> -- >>> v2: Move VM_IO | VM_PFNMAP checks around so they keep returning EINVAL >>> like before (Gerard) >> >> I think the above should go before the

Re: [PATCH v2 08/17] s390/pci: Remove races against pte updates

2020-10-12 Thread Daniel Vetter
On Mon, Oct 12, 2020 at 04:03:28PM +0200, Niklas Schnelle wrote: > Hi Daniel, > > freshly back from my vacation I've just taken a look at your patch. > First thanks for this fix and the detailed commit description. > Definitely makes sense to fix this and you can add my > > Acked-by: Niklas

Re: [PATCH v2 08/17] s390/pci: Remove races against pte updates

2020-10-12 Thread Niklas Schnelle
Hi Daniel, freshly back from my vacation I've just taken a look at your patch. First thanks for this fix and the detailed commit description. Definitely makes sense to fix this and you can add my Acked-by: Niklas Schnelle Content wise it all looks sane and clear and since Gerald did the

[PATCH v2 08/17] s390/pci: Remove races against pte updates

2020-10-09 Thread Daniel Vetter
Way back it was a reasonable assumptions that iomem mappings never change the pfn range they point at. But this has changed: - gpu drivers dynamically manage their memory nowadays, invalidating ptes with unmap_mapping_range when buffers get moved - contiguous dma allocations have moved from