On Tue, Jul 12, 2011 at 10:04:55AM +0200, Pavel Herrmann wrote: > On Tuesday 12 of July 2011 09:36:06 Jean Delvare wrote: > > Honestly, I have no idea what "causing one thread having pointers to > > memory on or above other threads stack" means (nor why this would be > > bad.) > the long-winded story is that thread A writes a pointer onto its stack into > the drvdata as part of spi_sync call, then thread B comes in and puts a > pointer onto its stack into the drvdata, at the end of spi_sync thread A uses > this pointer (assuming it is unchanged), which is pointing either onto valid > stack of thread B or somewhere above it (if thread B already returned) That's just a use after free bug, the fact that the variables are on the stacks of other threads isn't the issue, the issue is that the two threads that are sharing state arne't properly synchronized. _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
