linux-kernel - Re: [PATCH 1/9] usb: gadget: add generic map/unmap request utilities

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.1112191116320.1746-100000@iolanthe.rowland.org>
Date:	Mon, 19 Dec 2011 11:27:21 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Felipe Balbi <balbi@...com>
cc:	Linux USB Mailing List <linux-usb@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Dahlmann <dahlmann.thomas@...or.de>,
	Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
	"open list:DESIGNWARE USB3 D..." <linux-omap@...r.kernel.org>,
	open list <linux-kernel@...r.kernel.org>,
	"open list:AMD GEODE CS5536..." <linux-geode@...ts.infradead.org>
Subject: Re: [PATCH 1/9] usb: gadget: add generic map/unmap request utilities

On Mon, 19 Dec 2011, Felipe Balbi wrote:

> > > +		if (dma_mapping_error(&gadget->dev, req->dma)) {
> > > +			dev_err(&gadget->dev, "failed to map buffer\n");
> > > +			return -EFAULT;
> > > +		}
> > > +	}
> > > +
> > > +	return 0;
> > 
> > You forgot to set req->mapped.
> 
> actually there's no 'mapped' field on struct usb_request. That's a

Whoops, you're right.  It's part of the UDC-private structure.

> nonsense added to all struct my_controller_request just because of that
> DMA_ADDR_INVALID hackery. I'm dropping that completely. There were no
> gadget drivers allocating memory from coherent or mapping requests
> themselves, so req->mapped becomes useless.

There's more to it than that.  A controller might support DMA on some
endpoints but not others, or for certain request lengths but not
others.  Hence when a request finishes, the driver needs to know
whether the request was mapped for DMA.

For example, your net2280 patch needs to be fixed.  Here's how it looks
now:

> --- a/drivers/usb/gadget/net2280.c
> +++ b/drivers/usb/gadget/net2280.c
> @@ -806,12 +806,8 @@ done (struct net2280_ep *ep, struct net2280_request *req, int status)
>  		status = req->req.status;
>  
>  	dev = ep->dev;
> -	if (req->mapped) {
> -		pci_unmap_single (dev->pdev, req->req.dma, req->req.length,
> -			ep->is_in ? PCI_DMA_TODEVICE : PCI_DMA_FROMDEVICE);
> -		req->req.dma = DMA_ADDR_INVALID;
> -		req->mapped = 0;
> -	}
> +	if (req->mapped)
> +		usb_gadget_unmap_request(&dev->gadget, &req->req, ep->is_in);

This code will never be executed because you never set req->mapped.  
And after that's fixed, when the unmapping occurs, req->mapped has to
be set back to 0.

> @@ -857,10 +853,13 @@ net2280_queue (struct usb_ep *_ep, struct usb_request *_req, gfp_t gfp_flags)
>  		return -EOPNOTSUPP;
>  
>  	/* set up dma mapping in case the caller didn't */
> -	if (ep->dma && _req->dma == DMA_ADDR_INVALID) {
> -		_req->dma = pci_map_single (dev->pdev, _req->buf, _req->length,
> -			ep->is_in ? PCI_DMA_TODEVICE : PCI_DMA_FROMDEVICE);
> -		req->mapped = 1;
> +	if (ep->dma) {
> +		int ret;
> +
> +		ret = usb_gadget_map_request(&dev->gadget, &req->req,
> +				ep->is_in);
> +		if (ret)
> +			return ret;

You probably need to set req->mapped right here.  Or rather, avoid 
removing the line that sets it.

>  	}

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/