walter harms wrote: > > Dan Carpenter schrieb: >> I changed the dma buffers to use allocated memory instead of stack >> memory. >> >> The reason for this is documented in Documentation/DMA-API-HOWTO.txt >> under the section: "What memory is DMA'able?" That document was only >> added a couple weeks ago and there are still lots of modules which >> haven't been corrected yet. Btw. Smatch includes a pretty good test to >> find places which use stack memory as a dma buffer. That's how I found >> these. (http://smatch.sf.net). >> >> Signed-off-by: Dan Carpenter <error27@xxxxxxxxx> >> >> diff --git a/drivers/media/dvb/dvb-usb/az6027.c b/drivers/media/dvb/dvb-usb/az6027.c >> index 8934788..baaa301 100644 >> --- a/drivers/media/dvb/dvb-usb/az6027.c >> +++ b/drivers/media/dvb/dvb-usb/az6027.c >> @@ -417,11 +417,15 @@ static int az6027_ci_read_attribute_mem(struct dvb_ca_en50221 *ca, >> u16 value; >> u16 index; >> int blen; >> - u8 b[12]; >> + u8 *b; >> >> if (slot != 0) >> return -EINVAL; >> >> + b = kmalloc(12, GFP_KERNEL); >> + if (!b) >> + return -ENOMEM; >> + >> mutex_lock(&state->ca_mutex); >> >> req = 0xC1; > > > Hi Dan, > i am not sure if that is the way to go. > iff i understand the code correctly the b[12] seems to overcommit only > blen bytes (not 12) is needed. There must be a cheaper way to send a few bytes > of space to send a command to a device. Perhaps gregKH has a hint ? There is: you can add an array on a device private structure to hold those memory transfers. For now, I'll add this patch, as it corrects a real bug. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
