Messages in this thread | | | Subject | Re: [RFC] mm: gup: add helper page_try_gup_pin(page) | From | David Hildenbrand <> | Date | Tue, 5 Nov 2019 09:56:51 +0100 |
| |
On 04.11.19 20:03, Jerome Glisse wrote: > On Mon, Nov 04, 2019 at 06:20:50PM +0800, Hillf Danton wrote: >> >> On Sun, 3 Nov 2019 22:09:03 -0800 John Hubbard wrote: >>> On 11/3/19 8:34 PM, Hillf Danton wrote: >>> ... >>>>> >>>>> Well, as long as we're counting bits, I've taken 21 bits (!) to track >>>>> "gupers". :) More accurately, I'm sharing 31 bits with get_page()...please >>>> >>>> Would you please specify the reasoning of tracking multiple gupers >>>> for a dirty page? Do you mean that it is all fine for guper-A to add >>>> changes to guper-B's data without warning and vice versa? >>> >>> It's generally OK to call get_user_pages() on a page more than once. >> >> Does this explain that it's generally OK to gup pin a page under >> writeback and then start DMA to it behind the flusher's back without >> warning? > > It can happens today, is it ok ... well no but we live in an imperfect > world. GUP have been abuse by few device driver over the years and those > never checked what it meant to use it so now we are left with existing > device driver that we can not break that do wrong thing. > > I personaly think that we should use bounce page for writeback so that > writeback can still happens if a page is GUPed. John's patchset is the > first step to be able to identify GUPed page and maybe special case them. > >> >>> And even though we are seeing some work to reduce the number of places >>> in the kernel that call get_user_pages(), there are still lots of call sites. >>> That means lots of combinations and situations that could result in more >>> than one gup call per page. >>> >>> Furthermore, there is no mechanism, convention, documentation, nor anything >>> at all that attempts to enforce "for each page, get_user_pages() may only >>> be called once." >> >> What sense is this making wrt the data corruption resulting specifically >> from multiple gup references? > > Multiple GUP references do not imply corruption. Only one or more devices > writing to the page while writeback is happening is a cause of corruption. > Multiple device writting in the same page concurrently is like multiple > CPU thread doing the same. Either the application/device drivers are doing > this rightfully on purpose or the application has a bug. Either way it is > not our problem (note here i am talking about userspace portion of the > device driver). >
If I'm not completely off, we can have multiple GUP references easily by using KVM+VFIO.
--
Thanks,
David / dhildenb
| |