| Message ID | 1412014009-13315-10-git-send-email-bigeasy@linutronix.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 09/29/2014 09:06 PM, Sebastian Andrzej Siewior wrote: > I added book keeping of whether or not the 8250-dma driver has an RX > transfer pending or not so we don't BUG here if it calls > dmaengine_pause() on a channel which has not a pending transfer. Guess > what, this is not enough. > The following can be triggered with a busy RX channel and hackbench in > background: > - DMA transfer completes. The callback is delayed via > vchan_cookie_complete() into a tasklet so it das not happen asap. > - hackbench keeps the system busy so the tasklet does not run "soon". > - the UART collected enough data and generates an "timeout"-interrupt. > Since 8250-dma *thinks* the DMA-transfer is still pending it tries to > cancel it via invoking dmaengine_pause() first. This causes the segfault > because echan->edesc is NULL now that the transfer completed (however > the callback did not run yet). > > With this patch we don't BUG in the scenario described. Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> > > Cc: vinod.koul@intel.com > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> > --- > drivers/dma/edma.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c > index 7b65633f495e..123f578d6dd3 100644 > --- a/drivers/dma/edma.c > +++ b/drivers/dma/edma.c > @@ -288,7 +288,7 @@ static int edma_slave_config(struct edma_chan *echan, > static int edma_dma_pause(struct edma_chan *echan) > { > /* Pause/Resume only allowed with cyclic mode */ > - if (!echan->edesc->cyclic) > + if (!echan->edesc || !echan->edesc->cyclic) > return -EINVAL; > > edma_pause(echan->ch_num); >
On Mon, Sep 29, 2014 at 08:06:45PM +0200, Sebastian Andrzej Siewior wrote: > I added book keeping of whether or not the 8250-dma driver has an RX > transfer pending or not so we don't BUG here if it calls > dmaengine_pause() on a channel which has not a pending transfer. Guess > what, this is not enough. > The following can be triggered with a busy RX channel and hackbench in > background: > - DMA transfer completes. The callback is delayed via > vchan_cookie_complete() into a tasklet so it das not happen asap. > - hackbench keeps the system busy so the tasklet does not run "soon". > - the UART collected enough data and generates an "timeout"-interrupt. > Since 8250-dma *thinks* the DMA-transfer is still pending it tries to > cancel it via invoking dmaengine_pause() first. This causes the segfault > because echan->edesc is NULL now that the transfer completed (however > the callback did not run yet). > > With this patch we don't BUG in the scenario described. Applied thanks
On Mon, Sep 29, 2014 at 08:06:45PM +0200, Sebastian Andrzej Siewior wrote: > I added book keeping of whether or not the 8250-dma driver has an RX > transfer pending or not so we don't BUG here if it calls > dmaengine_pause() on a channel which has not a pending transfer. Guess > what, this is not enough. > The following can be triggered with a busy RX channel and hackbench in > background: > - DMA transfer completes. The callback is delayed via > vchan_cookie_complete() into a tasklet so it das not happen asap. > - hackbench keeps the system busy so the tasklet does not run "soon". > - the UART collected enough data and generates an "timeout"-interrupt. > Since 8250-dma *thinks* the DMA-transfer is still pending it tries to > cancel it via invoking dmaengine_pause() first. This causes the segfault > because echan->edesc is NULL now that the transfer completed (however > the callback did not run yet). > > With this patch we don't BUG in the scenario described. Applied, thanks
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index 7b65633f495e..123f578d6dd3 100644 --- a/drivers/dma/edma.c +++ b/drivers/dma/edma.c @@ -288,7 +288,7 @@ static int edma_slave_config(struct edma_chan *echan, static int edma_dma_pause(struct edma_chan *echan) { /* Pause/Resume only allowed with cyclic mode */ - if (!echan->edesc->cyclic) + if (!echan->edesc || !echan->edesc->cyclic) return -EINVAL; edma_pause(echan->ch_num);
I added book keeping of whether or not the 8250-dma driver has an RX transfer pending or not so we don't BUG here if it calls dmaengine_pause() on a channel which has not a pending transfer. Guess what, this is not enough. The following can be triggered with a busy RX channel and hackbench in background: - DMA transfer completes. The callback is delayed via vchan_cookie_complete() into a tasklet so it das not happen asap. - hackbench keeps the system busy so the tasklet does not run "soon". - the UART collected enough data and generates an "timeout"-interrupt. Since 8250-dma *thinks* the DMA-transfer is still pending it tries to cancel it via invoking dmaengine_pause() first. This causes the segfault because echan->edesc is NULL now that the transfer completed (however the callback did not run yet). With this patch we don't BUG in the scenario described. Cc: vinod.koul@intel.com Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> --- drivers/dma/edma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)