Hello, On Wednesday 09 Aug 2017 00:49:40 Kuninori Morimoto wrote: > Hi Anton > > # add Laurent > > > While searching for races in the Linux kernel I've come across > > "drivers/dma/sh/rcar-dmac.ko" module. Here is a question that I came > > up with while analyzing results. Lines are given using the info from > > Linux v4.12. > > > > Consider the following case: > > > > Thread 1: Thread 2: > > rcar_dmac_probe > > ->rcar_dmac_chan_probe > > > > (&dmac->channels[i]) > > > > rchan = &dmac->channels[i] > > chan = &rchan->chan > > devm_request_threaded_irq(rchan) > > chan->device = &dmac->engine rcar_dmac_isr_channel > > > > ->rcar_dmac_isr_transfer_end(chan) > > > > ->rcar_dmac_chan_start_xfer(chan) > > > > engine->dev = &pdev->dev; <READ chan->chan.device->dev> > > (rcar-dmac.c: line 1828) (rcar-dmac.c: line 351) > > > > As far as I understand engine->dev is NULL before its initialization > > in probe. Thus there might be a NULL pointer dereference in > > rcar_dmac_chan_start_xfer while accessing chan->chan.device->dev which > > is equal to (&dmac->engine)->dev. Is this possible from your point of > > view? > > Very rare case, but not impossible (?). > I think these engine->xxx initialize should be done before > of_dma_controller_register(); > engine.channels is initialized independently somehow... There should be no interrupt pending at the time the interrupt handler is registered, but to be safe it's indeed a good practice to register the interrupt handler after everything else has been initialized. Patches are welcome :-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
