Mike Isely wrote:
> Mauro:
>
> You are reading too much into that comment.
>
> I never said it was valid to do what had been done, only that for the
> longest time this is what the driver did and it never caused a problem
> that I was made aware of. What I said there was correct, that this is
> what the driver had been doing in the past, that it's definitely causing
> a problem now and thus that is why this patch exists.
As I said, this is not right:
"Apparently later kernels don't like this behavior"
It is not "later kernels". DMA over stack were never supported. Your driver
had a bug that you didn't noticed for long time, probably because nobody
reported you this issue, since it appears only on some non-Intel archs and
on i386 with more than 3.12 Gb of RAM, and when the stack happens to be after
the first 3.12 Gb (with is a somewhat rare condition).
If you take a look at the old logs, you'll see, at commit
a6c2ba283565dbc9f055dcb2ecba1971460bb535 (nov, 2005) the fix on one of the
drivers:
+int em2820_write_regs_req(struct em2820 *dev, u8 req, u16 reg, char *buf,
+ int len)
+{
+ int ret;
+
+ /*usb_control_msg seems to expect a kmalloced buffer */
+ unsigned char *bufs = kmalloc(len, GFP_KERNEL);
The same bug hit me in 2006/2007 when writing tm6000 driver. Due to a problem
at the videobuf free logic, on that time, it were very frequent to hit this
bug, as, with memory being spent, eventually stack address would be above the
3Gb address.
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
