October 4, 2017 6:57 PM, "Mauro Carvalho Chehab" <[email protected]> wrote:
> Em Sun, 25 Jun 2017 14:31:50 +0200 > David Härdeman <[email protected]> escreveu: > >> lirc_zilog uses a chunk_size of 2 and ir-lirc-codec uses sizeof(int). >> >> Therefore, using stack memory should be perfectly fine. >> >> Signed-off-by: David Härdeman <[email protected]> >> --- >> drivers/media/rc/lirc_dev.c | 8 +------- >> 1 file changed, 1 insertion(+), 7 deletions(-) >> >> diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c >> index 1773a2934484..92048d945ba7 100644 >> --- a/drivers/media/rc/lirc_dev.c >> +++ b/drivers/media/rc/lirc_dev.c >> @@ -376,7 +376,7 @@ ssize_t lirc_dev_fop_read(struct file *file, >> loff_t *ppos) >> { >> struct irctl *ir = file->private_data; >> - unsigned char *buf; >> + unsigned char buf[ir->buf->chunk_size]; > > No. We don't do dynamic buffer allocation on stak at the Kernel, > as this could cause the Linux stack to overflow without notice. While the general policy is to avoid large stack allocations (in order to not overflow the 4K stack), I'm not aware of a general ban on *any* stack allocations - that sounds like an overly dogmatic approach. If such a generic ban exists, could you please point me to some kind of discussion/message to that effect? The commit message clearly explained what kind of stack allocations we're talking about here (i.e. sizeof(int) is the maximum), so the stack allocation is clearly not able to cause stack overflows. And once the last lirc driver is gone, this can be changed to a simple int (which would also be allocated on stack). Regards, David
