1. 02 Dec, 2022 1 commit
    • Linus Torvalds's avatar
      v4l2: don't fall back to follow_pfn() if pin_user_pages_fast() fails · 6647e76a
      Linus Torvalds authored
      The V4L2_MEMORY_USERPTR interface is long deprecated and shouldn't be
      used (and is discouraged for any modern v4l drivers).  And Seth Jenkins
      points out that the fallback to VM_PFNMAP/VM_IO is fundamentally racy
      and dangerous.
      
      Note that it's not even a case that should trigger, since any normal
      user pointer logic ends up just using the pin_user_pages_fast() call
      that does the proper page reference counting.  That's not the problem
      case, only if you try to use special device mappings do you have any
      issues.
      
      Normally I'd just remove this during the merge window, but since Seth
      pointed out the problem cases, we really want to know as soon as
      possible if there are actually any users of this odd special case of a
      legacy interface.  Neither Hans nor Mauro seem to think that such
      mis-uses of the old legacy interface should exist.  As Mauro says:
      
       "See, V4L2 has actually 4 streaming APIs:
              - Kernel-allocated mmap (usually referred simply as just mmap);
              - USERPTR mmap;
              - read();
              - dmabuf;
      
        The USERPTR is one of the oldest way to use it, coming from V4L
        version 1 times, and by far the least used one"
      
      And Hans chimed in on the USERPTR interface:
      
       "To be honest, I wouldn't mind if it goes away completely, but that's a
        bit of a pipe dream right now"
      
      but while removing this legacy interface entirely may be a pipe dream we
      can at least try to remove the unlikely (and actively broken) case of
      using special device mappings for USERPTR accesses.
      
      This replaces it with a WARN_ONCE() that we can remove once we've
      hopefully confirmed that no actual users exist.
      
      NOTE! Longer term, this means that a 'struct frame_vector' only ever
      contains proper page pointers, and all the games we have with converting
      them to pages can go away (grep for 'frame_vector_to_pages()' and the
      uses of 'vec->is_pfns').  But this is just the first step, to verify
      that this code really is all dead, and do so as quickly as possible.
      Reported-by: default avatarSeth Jenkins <sethjenkins@google.com>
      Acked-by: default avatarHans Verkuil <hverkuil@xs4all.nl>
      Acked-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      Cc: David Hildenbrand <david@redhat.com>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6647e76a
  2. 01 Dec, 2022 7 commits
  3. 30 Nov, 2022 3 commits
  4. 29 Nov, 2022 21 commits
  5. 28 Nov, 2022 8 commits