Message ID | 20210316153303.3216674-3-daniel.vetter@ffwll.ch (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | switch to unsafe_follow_pfn | expand |
On Tue, Mar 16, 2021 at 4:46 PM Christoph Hellwig <hch@infradead.org> wrote: > > On Tue, Mar 16, 2021 at 04:33:02PM +0100, Daniel Vetter wrote: > > The media model assumes that buffers are all preallocated, so that > > when a media pipeline is running we never miss a deadline because the > > buffers aren't allocated or available. > > > > This means we cannot fix the v4l follow_pfn usage through > > mmu_notifier, without breaking how this all works. The only real fix > > is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and > > tell everyone to cut over to dma-buf memory sharing for zerocopy. > > > > userptr for normal memory will keep working as-is, this only affects > > the zerocopy userptr usage enabled in 50ac952d2263 ("[media] > > videobuf2-dma-sg: Support io userptr operations on io memory"). > > Maybe I'm missing something, but wasn't the conclusion last time that > this hackish early device to device copy support can just go away? My understanding is mostly, but with some objections. And I kinda don't want to let this die in a bikeshed and then not getting rid of follow_pfn as a result. There's enough people who acked this, and the full removal got some nack from Mauro iirc. Maybe if no bug report ever shows up for 1-2 years we can sunset it for real&completely. -Daniel
On Wed, Mar 17, 2021 at 8:22 AM Christoph Hellwig <hch@infradead.org> wrote: > On Tue, Mar 16, 2021 at 04:52:44PM +0100, Daniel Vetter wrote: > > My understanding is mostly, but with some objections. And I kinda > > don't want to let this die in a bikeshed and then not getting rid of > > follow_pfn as a result. There's enough people who acked this, and the > > full removal got some nack from Mauro iirc. > > Hmm, ok I must have missed that. I defintively prefer your series over > doing nothing, but killing the dead horse ASAP would be even better. I have a bunch of slow-burner things I need to fix in this area of driver mmaps vs get_user_/follow_ conflicts anyway, I'll add a note to put the horse out of it's misery in due time. We have a few problems still where things might get pinned or used where it really shouldn't be. Can I count that as an ack on the series? You've touched this quite a bit recently. Thanks, Daniel
diff --git a/drivers/media/common/videobuf2/frame_vector.c b/drivers/media/common/videobuf2/frame_vector.c index a0e65481a201..1a82ec13ea00 100644 --- a/drivers/media/common/videobuf2/frame_vector.c +++ b/drivers/media/common/videobuf2/frame_vector.c @@ -70,7 +70,7 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames, break; while (ret < nr_frames && start + PAGE_SIZE <= vma->vm_end) { - err = follow_pfn(vma, start, &nums[ret]); + err = unsafe_follow_pfn(vma, start, &nums[ret]); if (err) { if (ret == 0) ret = err; diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c b/drivers/media/v4l2-core/videobuf-dma-contig.c index 52312ce2ba05..821c4a76ab96 100644 --- a/drivers/media/v4l2-core/videobuf-dma-contig.c +++ b/drivers/media/v4l2-core/videobuf-dma-contig.c @@ -183,7 +183,7 @@ static int videobuf_dma_contig_user_get(struct videobuf_dma_contig_memory *mem, user_address = untagged_baddr; while (pages_done < (mem->size >> PAGE_SHIFT)) { - ret = follow_pfn(vma, user_address, &this_pfn); + ret = unsafe_follow_pfn(vma, user_address, &this_pfn); if (ret) break;