[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4a47b044-3660-48e6-647d-4a2217cfa287@shipmail.org>
Date: Tue, 23 Mar 2021 16:51:31 +0100
From: Thomas Hellström (Intel)
<thomas_os@...pmail.org>
To: Jason Gunthorpe <jgg@...dia.com>, dri-devel@...ts.freedesktop.org,
Christian Koenig <christian.koenig@....com>,
David Airlie <airlied@...ux.ie>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 2/2] mm,drm/ttm: Use VM_PFNMAP for TTM vmas
On 3/23/21 3:04 PM, Jason Gunthorpe wrote:
> On Tue, Mar 23, 2021 at 12:47:24PM +0100, Daniel Vetter wrote:
>
>>> +static inline bool is_cow_mapping(vm_flags_t flags)
>> Bit a bikeshed, but I wonder whether the public interface shouldn't be
>> vma_is_cow_mapping. Or whether this shouldn't be rejected somewhere else,
>> since at least in drivers/gpu we have tons of cases that don't check for
>> this and get it all kinds of wrong I think.
>>
>> remap_pfn_range handles this for many cases, but by far not for all.
>>
>> Anyway patch itself lgtm:
>>
>> Reviewed-by: Daniel Vetter <daniel.vetter@...ll.ch>
> I would like it if io_remap_pfn_range() did not allow shared mappings
> at all.
You mean private mappings?
>
> IIRC it doesn't work anyway, the kernel can't reliably copy from IO
> pages eg the "_copy_from_user_inatomic()" under cow_user_page() will
> not work on s390 that requires all IO memory be accessed with special
> instructions.
>
> Unfortunately I have no idea what the long ago special case of
> allowing COW'd IO mappings is. :\
Me neither, but at some point it must have been important enough to
introduce VM_MIXEDMAP...
/Thomas
> Jason
Powered by blists - more mailing lists