TBH though, I’m not sure about the tw686x_init going to the error: label though, so am curious as to your thoughts on this as well. It was just something I thought might be occurring due to the fact that the error trace in our tool ends in tw686x_memcpy_dma_free (i.e. dma_ops->free).
Please see the other indications I made toward the codes of tw686x-core.c and tw686x-audio.c in the message below. Thank you, Mark > On Jul 24, 2019, at 5:25 AM, Mark Balançian <mbala...@gmail.com> wrote: > > Hi Ezequiel, > > (sorry didn't include linux-media in first email) > I'm not sure yet if I have my supervisor's permission to declare our tool as > open source, but I'll tell you the possible code paths that I think may be > leading our tool to think what it's thinking. > > First off, it detects a write access to desc->virt without locks inside > tw686x_memcpy_data_free, after it is called in the calling chain tw686x_probe > -> allocate an interrupt line -> tw686x_video_init -> tw686x_set_format -> > tw686x_memcpy_dma_free. Further, spin_lock_init(&dev->lock) (line 319 of > tw686x-core.c) isn't correspondingly closed in the function. Is this intended? > > Second, there is a possibility according to how I have traced a call chain > that tw686x_init is going to the error: label since tw686x_memcpy_dma_free is > getting called inside another possible calling chain, going tw686x_init -> > tw686x_video_free (error: label) -> dma_ops->free (i.e. > tw686x_memcpy_dma_free). I would assume this would not be intended either. > > In addition, our tool detects a read access without locks to desc->virt > inside tw686x_audio_irq (line 72 of tw686x-audio.c). Not sure what you make > of that, but I'd be keen on hearing about that as well from you. > > Thank you in advance, > > Mark
