Handling of VM_IO vma in omap_vout_uservirt_to_phys()
Hello,
I was auditing get_user_pages() users and I've noticed thatomap_vout_uservirt_to_phys() is apparently called for arbitrary address passed from userspace. If this address is in VM_IO vma, we use vma->vm_pgoff for mapping the virtual address to a physical address. However I don't think this is a generally valid computation for arbitrary VM_IO vma. So do we expect vma to come from a particular source where this is true? If yes, where do we expect vma comes from? Thanks for clarification.
Honza
Signature · 2 lines
Jan Kara <[email protected]> SUSE Labs, CR
Hi,
Quoted 10 lines · Jan Kara
Hello,
I was auditing
get_user_pages()users and I've noticed thatomap_vout_uservirt_to_phys()is apparently called for arbitrary address passed from userspace. If this address is inVM_IOvma, we usevma->vm_pgofffor mapping the virtual address to a physical address. However I don't think this is a generally valid computation for arbitraryVM_IOvma. So do we expect vma to come from a particular source where this is true? If yes, where do we expect vma comes from? Thanks for clarification.
I don't know much about this domain, so I might be wrong here.
The function omap_vout_uservirt_to_phys() is used in the mode 'V4L2_MEMORY_USERPTR', to recieve a virtual address from the user.
The driver hardware only works with physically contiguous buffers. So I'm guessing this vma maps to a buffer mmaped by the user application by some other device(like a camera or something). This way, the user doesn't need to copy the buffer between the 2 devices. I guess the computation works in that case. We don't have any safety checks for this though.
This driver is currenlty using the videobuf() framework, we would eventually switch to videobuf2(), and hopefully this code shouldn't even exist then.
Archit
Quoted 19 lines · Archit Taneja
Hi,
Quoted 10 lines · Jan Kara
Hello,
I was auditing
get_user_pages()users and I've noticed thatomap_vout_uservirt_to_phys()is apparently called for arbitrary address passed from userspace. If this address is inVM_IOvma, we usevma->vm_pgofffor mapping the virtual address to a physical address. However I don't think this is a generally valid computation for arbitraryVM_IOvma. So do we expect vma to come from a particular source where this is true? If yes, where do we expect vma comes from? Thanks for clarification.I don't know much about this domain, so I might be wrong here.
The function
omap_vout_uservirt_to_phys()is used in the mode 'V4L2_MEMORY_USERPTR', to recieve a virtual address from the user.
Quoted 6 lines
The driver hardware only works with physically contiguous buffers. So I'm guessing this vma maps to a buffer mmaped by the user application by some other device(like a camera or something). This way, the user doesn't need to copy the buffer between the 2 devices. I guess the computation works in that case. We don't have any safety checks for this though.
OK, so you really expect vma to be setup in a particular way. In
videobuf2 framework this seems to correspond to what drivers/media/v4l2-core/videobuf2-vmalloc.c is doing (although that one is checking the range is really physically contiguous in vb2_get_contig_userptr()).
Quoted 3 lines
This driver is currenlty using the
videobuf()framework, we would eventually switch tovideobuf2(), and hopefully this code shouldn't even exist then.
This is good to know but if that isn't happening soon I guess I'll
convert the code somehow because I want to do some changes to the way get_user_pages() is called.
Thanks for your explanation.
Honza
Signature · 2 lines
Jan Kara <[email protected]> SUSE Labs, CR
Quoted 32 lines · Jan Kara
Quoted 19 lines · Archit Taneja
Hi,
Quoted 10 lines · Jan Kara
Hello,
I was auditing
get_user_pages()users and I've noticed thatomap_vout_uservirt_to_phys()is apparently called for arbitrary address passed from userspace. If this address is inVM_IOvma, we usevma->vm_pgofffor mapping the virtual address to a physical address. However I don't think this is a generally valid computation for arbitraryVM_IOvma. So do we expect vma to come from a particular source where this is true? If yes, where do we expect vma comes from? Thanks for clarification.I don't know much about this domain, so I might be wrong here.
The function
omap_vout_uservirt_to_phys()is used in the mode 'V4L2_MEMORY_USERPTR', to recieve a virtual address from the user.Quoted 6 lines
The driver hardware only works with physically contiguous buffers. So I'm guessing this vma maps to a buffer mmaped by the user application by some other device(like a camera or something). This way, the user doesn't need to copy the buffer between the 2 devices. I guess the computation works in that case. We don't have any safety checks for this though.
OK, so you really expect vma to be setup in a particular way. In
videobuf2 framework this seems to correspond to whatdrivers/media/v4l2-core/videobuf2-vmalloc.cis doing (although that one is checking the range is really physically contiguous invb2_get_contig_userptr()).
Quoted 6 lines
Quoted 3 lines
This driver is currenlty using the
videobuf()framework, we would eventually switch tovideobuf2(), and hopefully this code shouldn't even exist then.This is good to know but if that isn't happening soon I guess I'll
convert the code somehow because I want to do some changes to the wayget_user_pages()is called.
I think the conversion will take some time.
I don't think we have tested user pointer support on omap_vout for quite a while. Anyway, I can still test to see if the change works fine or not.
Archit