lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 20 Nov 2020 11:38:55 +0100 From: Hans Verkuil <hverkuil@...all.nl> To: Daniel Vetter <daniel.vetter@...ll.ch> Cc: DRI Development <dri-devel@...ts.freedesktop.org>, LKML <linux-kernel@...r.kernel.org>, KVM list <kvm@...r.kernel.org>, Linux MM <linux-mm@...ck.org>, Linux ARM <linux-arm-kernel@...ts.infradead.org>, linux-samsung-soc <linux-samsung-soc@...r.kernel.org>, "open list:DMA BUFFER SHARING FRAMEWORK" <linux-media@...r.kernel.org>, Tomasz Figa <tfiga@...omium.org>, Daniel Vetter <daniel.vetter@...el.com>, Jason Gunthorpe <jgg@...pe.ca>, Kees Cook <keescook@...omium.org>, Dan Williams <dan.j.williams@...el.com>, Andrew Morton <akpm@...ux-foundation.org>, John Hubbard <jhubbard@...dia.com>, Jérôme Glisse <jglisse@...hat.com>, Jan Kara <jack@...e.cz>, Pawel Osciak <pawel@...iak.com>, Marek Szyprowski <m.szyprowski@...sung.com>, Kyungmin Park <kyungmin.park@...sung.com>, Laurent Dufour <ldufour@...ux.ibm.com>, Vlastimil Babka <vbabka@...e.cz>, Daniel Jordan <daniel.m.jordan@...cle.com>, Michel Lespinasse <walken@...gle.com>, Mauro Carvalho Chehab <mchehab@...nel.org> Subject: Re: [PATCH v6 09/17] media/videbuf1|2: Mark follow_pfn usage as unsafe On 20/11/2020 10:18, Daniel Vetter wrote: > On Fri, Nov 20, 2020 at 9:28 AM Hans Verkuil <hverkuil@...all.nl> wrote: >> >> On 20/11/2020 09:06, Hans Verkuil wrote: >>> On 19/11/2020 15:41, 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"). >>>> >>>> Acked-by: Tomasz Figa <tfiga@...omium.org> >>> >>> Acked-by: Hans Verkuil <hverkuil-cisco@...all.nl> >> >> Actually, cancel this Acked-by. >> >> So let me see if I understand this right: VM_IO | VM_PFNMAP mappings can >> move around. There is a mmu_notifier that can be used to be notified when >> that happens, but that can't be used with media buffers since those buffers >> must always be available and in the same place. >> >> So follow_pfn is replaced by unsafe_follow_pfn to signal that what is attempted >> is unsafe and unreliable. >> >> If CONFIG_STRICT_FOLLOW_PFN is set, then unsafe_follow_pfn will fail, if it >> is unset, then it writes a warning to the kernel log but just continues while >> still unsafe. >> >> I am very much inclined to just drop VM_IO | VM_PFNMAP support in the media >> subsystem. For vb2 there is a working alternative in the form of dmabuf, and >> frankly for vb1 I don't care. If someone really needs this for a vb1 driver, >> then they can do the work to convert that driver to vb2. >> >> I've added Mauro to the CC list and I'll ping a few more people to see what >> they think, but in my opinion support for USERPTR + VM_IO | VM_PFNMAP >> should just be killed off. >> >> If others would like to keep it, then frame_vector.c needs a comment before >> the 'while' explaining why the unsafe_follow_pfn is there and that using >> dmabuf is the proper alternative to use. That will make it easier for >> developers to figure out why they see a kernel warning and what to do to >> fix it, rather than having to dig through the git history for the reason. > > I'm happy to add a comment, but otherwise if you all want to ditch > this, can we do this as a follow up on top? There's quite a bit of > code that can be deleted and I'd like to not hold up this patch set > here on that - it's already a fairly sprawling pain touching about 7 > different subsystems (ok only 6-ish now since the s390 patch landed). > For the comment, is the explanation next to unsafe_follow_pfn not good > enough? No, because that doesn't mention that you should use dma-buf as a replacement. That's really the critical piece of information I'd like to see. That doesn't belong in unsafe_follow_pfn, it needs to be in frame_vector.c since it's vb2 specific. > > So ... can I get you to un-cancel your ack? Hmm, I really would like to see support for this to be dropped completely. How about this: just replace follow_pfn() by -EINVAL instead of unsafe_follow_pfn(). Add a TODO comment that this code now can be cleaned up a lot. Such a clean up patch can be added on top later, and actually that is something that I can do once this series has landed. Regardless, frame_vector.c should mention dma-buf as a replacement in a comment since I don't want users who hit this issue to have to dig through git logs to find that dma-buf is the right approach. BTW, nitpick: the subject line of this patch says 'videbuf' instead of 'videobuf'. Regards, Hans > > Thanks, Daniel > >> >> Regards, >> >> Hans >> >>> >>> Thanks! >>> >>> Hans >>> >>>> Signed-off-by: Daniel Vetter <daniel.vetter@...el.com> >>>> Cc: Jason Gunthorpe <jgg@...pe.ca> >>>> Cc: Kees Cook <keescook@...omium.org> >>>> Cc: Dan Williams <dan.j.williams@...el.com> >>>> Cc: Andrew Morton <akpm@...ux-foundation.org> >>>> Cc: John Hubbard <jhubbard@...dia.com> >>>> Cc: Jérôme Glisse <jglisse@...hat.com> >>>> Cc: Jan Kara <jack@...e.cz> >>>> Cc: Dan Williams <dan.j.williams@...el.com> >>>> Cc: linux-mm@...ck.org >>>> Cc: linux-arm-kernel@...ts.infradead.org >>>> Cc: linux-samsung-soc@...r.kernel.org >>>> Cc: linux-media@...r.kernel.org >>>> Cc: Pawel Osciak <pawel@...iak.com> >>>> Cc: Marek Szyprowski <m.szyprowski@...sung.com> >>>> Cc: Kyungmin Park <kyungmin.park@...sung.com> >>>> Cc: Tomasz Figa <tfiga@...omium.org> >>>> Cc: Laurent Dufour <ldufour@...ux.ibm.com> >>>> Cc: Vlastimil Babka <vbabka@...e.cz> >>>> Cc: Daniel Jordan <daniel.m.jordan@...cle.com> >>>> Cc: Michel Lespinasse <walken@...gle.com> >>>> Signed-off-by: Daniel Vetter <daniel.vetter@...ll.ch> >>>> -- >>>> v3: >>>> - Reference the commit that enabled the zerocopy userptr use case to >>>> make it abundandtly clear that this patch only affects that, and not >>>> normal memory userptr. The old commit message already explained that >>>> normal memory userptr is unaffected, but I guess that was not clear >>>> enough. >>>> --- >>>> drivers/media/common/videobuf2/frame_vector.c | 2 +- >>>> drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +- >>>> 2 files changed, 2 insertions(+), 2 deletions(-) >>>> >>>> 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; >>>> >>>> >>> >> > >
Powered by blists - more mailing lists