All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Linton <jeremy.linton@arm.com>
To: Greg KH <gregkh@linuxfoundation.org>, Christoph Hellwig <hch@lst.de>
Cc: Hillf Danton <hdanton@sina.com>,
	syzbot <syzbot+353be47c9ce21b68b7ed@syzkaller.appspotmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	syzkaller-bugs@googlegroups.com, x86@kernel.org
Subject: Re: Validating dma_mmap_coherent() parameters before calling (was Re: WARNING in memtype_reserve)
Date: Thu, 14 May 2020 06:17:41 -0500	[thread overview]
Message-ID: <d4657561-63b2-21a3-9db3-99f3f91aea3e@arm.com> (raw)
In-Reply-To: <20200514074659.GA1569055@kroah.com>

On 5/14/20 2:46 AM, Greg KH wrote:
> On Thu, May 14, 2020 at 08:31:58AM +0200, Christoph Hellwig wrote:
>> On Thu, May 14, 2020 at 08:27:50AM +0200, Greg KH wrote:
>>> On Thu, May 14, 2020 at 08:14:17AM +0200, Christoph Hellwig wrote:
>>>> Guys, can you please start formal thread on this?  I have no
>>>> idea where this came from and what the rationale is.  Btw, if the
>>>> pfn is crap in dma_direct_mmap then the dma_addr_t passed in is
>>>> crap, as it is derived from that.  What is the caller, and how is
>>>> this triggered?
>>>
>>>
>>> Ok, to summarize, commit 2bef9aed6f0e ("usb: usbfs: correct kernel->user
>>> page attribute mismatch") changed a call from remap_pfn_range() to
>>> dma_mmap_coherent() for usb data buffers being sent from userspace.
>>
>> I only need to look at the commit for 3 seconds to tell you that it is
>> completely buggy.  While using dma_mmap_coherent is fundamentally the
>> right thing and absolutely required for dma_alloc_* allocations, USB
>> also uses it's own local gen pool allocator or plain kmalloc for not
>> DMA capable controller.  This need to use remap_pfn_range.  I'm pretty
>> sure you hit one of those cases.
>>
>> The logic should be something like:
>>
>> 	if (hcd->localmem_pool || !hcd_uses_dma(hcd))
>> 		remap_pfn_range()
>> 	else
>> 		dma_mmap_coherent()
> 
> Ok, that's simple enough, patch is below.
> 
> Jeremy, any objection to this change?

No, thats fine but since I just translated usb_alloc_coherent() to 
dma_map_coherent in my not fully away head. Putting this as 
"usb_map_cohernet()" sort of makes more sense.


> 
> thanks,
> 
> greg k-h
> 
> 
> diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> index b9db9812d6c5..d93d94d7ff50 100644
> --- a/drivers/usb/core/devio.c
> +++ b/drivers/usb/core/devio.c
> @@ -251,9 +251,19 @@ static int usbdev_mmap(struct file *file, struct vm_area_struct *vma)
>   	usbm->vma_use_count = 1;
>   	INIT_LIST_HEAD(&usbm->memlist);
>   
> -	if (dma_mmap_coherent(hcd->self.sysdev, vma, mem, dma_handle, size)) {
> -		dec_usb_memory_use_count(usbm, &usbm->vma_use_count);
> -		return -EAGAIN;
> +	if (hcd->localmem_pool || !hcd_uses_dma(hcd)) {
> +		if (remap_pfn_range(vma, vma->vm_start,
> +				    virt_to_phys(usbm->mem) >> PAGE_SHIFT,
> +				    size, vma->vm_page_prot) < 0) {
> +			dec_usb_memory_use_count(usbm, &usbm->vma_use_count);
> +			return -EAGAIN;
> +		}
> +	} else {
> +		if (dma_mmap_coherent(hcd->self.sysdev, vma, mem, dma_handle,
> +				      size)) {
> +			dec_usb_memory_use_count(usbm, &usbm->vma_use_count);
> +			return -EAGAIN;
> +		}
>   	}
>   
>   	vma->vm_flags |= VM_IO;
> 


  reply	other threads:[~2020-05-14 11:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-09  7:20 WARNING in memtype_reserve syzbot
2020-05-09  7:45 ` Greg KH
2020-05-09 10:00   ` Thomas Gleixner
2020-05-09 13:41     ` Alan Stern
2020-05-13 16:21       ` Thomas Gleixner
2020-05-13 12:44     ` Greg KH
2020-05-13 16:22       ` Thomas Gleixner
2020-05-13 16:55         ` Greg KH
     [not found]         ` <20200514035458.14760-1-hdanton@sina.com>
2020-05-14  6:14           ` Christoph Hellwig
2020-05-14  6:19             ` Dmitry Vyukov
2020-05-14  6:27             ` Validating dma_mmap_coherent() parameters before calling (was Re: WARNING in memtype_reserve) Greg KH
2020-05-14  6:31               ` Christoph Hellwig
2020-05-14  7:46                 ` Greg KH
2020-05-14 11:17                   ` Jeremy Linton [this message]
2020-05-14 11:22                     ` Greg KH
2020-05-14 11:10                 ` Jeremy Linton
2020-05-14 11:14                   ` Christoph Hellwig
2020-05-14 11:16                     ` Jeremy Linton
2020-05-14  9:08           ` WARNING in memtype_reserve syzbot
2020-05-09 17:42 ` Jeremy Linton
     [not found] ` <20200509154728.1548-1-hdanton@sina.com>
2020-05-13 12:41   ` Greg KH
2020-05-14  9:20 ` Greg KH
2020-05-14 10:44   ` syzbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d4657561-63b2-21a3-9db3-99f3f91aea3e@arm.com \
    --to=jeremy.linton@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=hdanton@sina.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=syzbot+353be47c9ce21b68b7ed@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.