[PATCH] siano: make it work again with CONFIG_VMAP_STACK

[PATCH] siano: make it work again with CONFIG_VMAP_STACK

[Mauro Carvalho Chehab]

Reported as a Kaffeine bug:
	https://bugs.kde.org/show_bug.cgi?id=375811

The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.

On Kernel 4.9, the default is to not accept DMA on stack anymore.

Tested with USB ID 2040:5510: Hauppauge Windham

Cc: stable@vger.kernel.org # For 4.9+
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
 drivers/media/usb/siano/smsusb.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/media/usb/siano/smsusb.c b/drivers/media/usb/siano/smsusb.c
index a4dcaec31d02..8c1f926567ec 100644
--- a/drivers/media/usb/siano/smsusb.c
+++ b/drivers/media/usb/siano/smsusb.c
@@ -218,22 +218,30 @@ static int smsusb_start_streaming(struct smsusb_device_t *dev)
 static int smsusb_sendrequest(void *context, void *buffer, size_t size)
 {
 	struct smsusb_device_t *dev = (struct smsusb_device_t *) context;
-	struct sms_msg_hdr *phdr = (struct sms_msg_hdr *) buffer;
-	int dummy;
+	struct sms_msg_hdr *phdr;
+	int dummy, ret;
 
 	if (dev->state != SMSUSB_ACTIVE) {
 		pr_debug("Device not active yet\n");
 		return -ENOENT;
 	}
 
+	phdr = kmalloc(size, GFP_KERNEL);
+	if (!phdr)
+		return -ENOMEM;
+	memcpy(phdr, buffer, size);
+
 	pr_debug("sending %s(%d) size: %d\n",
 		  smscore_translate_msg(phdr->msg_type), phdr->msg_type,
 		  phdr->msg_length);
 
 	smsendian_handle_tx_message((struct sms_msg_data *) phdr);
-	smsendian_handle_message_header((struct sms_msg_hdr *)buffer);
-	return usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 2),
-			    buffer, size, &dummy, 1000);
+	smsendian_handle_message_header((struct sms_msg_hdr *)phdr);
+	ret = usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 2),
+			    phdr, size, &dummy, 1000);
+
+	kfree(phdr);
+	return ret;
 }
 
 static char *smsusb1_fw_lkup[] = {
-- 
2.9.3

Re: [PATCH] siano: make it work again with CONFIG_VMAP_STACK

[Greg KH]

On Tue, Feb 14, 2017 at 05:32:11PM -0200, Mauro Carvalho Chehab wrote:
> Reported as a Kaffeine bug:
> 	https://bugs.kde.org/show_bug.cgi?id=375811
> 
> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> On Kernel 4.9, the default is to not accept DMA on stack anymore.
> 
> Tested with USB ID 2040:5510: Hauppauge Windham
> 
> Cc: stable@vger.kernel.org # For 4.9+

Unless there is some major reason, this should go into _all_ stable
releases, as the driver would be broken on them all for platforms that
can't handle USB data that is not DMA-able.  This has been a requirement
for USB drivers since the 2.2 days.

thanks,

greg k-h

Re: [PATCH] siano: make it work again with CONFIG_VMAP_STACK

[Mauro Carvalho Chehab]

Em Tue, 14 Feb 2017 11:41:46 -0800
Greg KH <gregkh@linuxfoundation.org> escreveu:

> On Tue, Feb 14, 2017 at 05:32:11PM -0200, Mauro Carvalho Chehab wrote:
> > Reported as a Kaffeine bug:
> > 	https://bugs.kde.org/show_bug.cgi?id=375811
> > 
> > The USB control messages require DMA to work. We cannot pass
> > a stack-allocated buffer, as it is not warranted that the
> > stack would be into a DMA enabled area.
> > 
> > On Kernel 4.9, the default is to not accept DMA on stack anymore.
> > 
> > Tested with USB ID 2040:5510: Hauppauge Windham
> > 
> > Cc: stable@vger.kernel.org # For 4.9+  
> 
> Unless there is some major reason, this should go into _all_ stable
> releases, as the driver would be broken on them all for platforms that
> can't handle USB data that is not DMA-able.  This has been a requirement
> for USB drivers since the 2.2 days.

Good point! No, there's no particular reason why not backporting it
to older Kernel releases. I suspect that this particular part of
the driver hasn't changed for a while. So, it can very likely be
backported to all stable releases.

I'll fix the C/C message when submitting it upstream.

Thanks,
Mauro