diff mbox series

[v4,01/14] dmaengine: tegra-apb: Fix use-after-free

Message ID 20200112173006.29863-2-digetx@gmail.com (mailing list archive)
State Changes Requested
Headers show
Series NVIDIA Tegra APB DMA driver fixes and improvements | expand

Commit Message

Dmitry Osipenko Jan. 12, 2020, 5:29 p.m. UTC
I was doing some experiments with I2C and noticed that Tegra APB DMA
driver crashes sometime after I2C DMA transfer termination. The crash
happens because tegra_dma_terminate_all() bails out immediately if pending
list is empty, thus it doesn't release the half-completed descriptors
which are getting re-used before ISR tasklet kicks-in.

 tegra-i2c 7000c400.i2c: DMA transfer timeout
 elants_i2c 0-0010: elants_i2c_irq: failed to read data: -110
 ------------[ cut here ]------------
 WARNING: CPU: 0 PID: 142 at lib/list_debug.c:45 __list_del_entry_valid+0x45/0xac
 list_del corruption, ddbaac44->next is LIST_POISON1 (00000100)
 Modules linked in:
 CPU: 0 PID: 142 Comm: kworker/0:2 Not tainted 5.5.0-rc2-next-20191220-00175-gc3605715758d-dirty #538
 Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
 Workqueue: events_freezable_power_ thermal_zone_device_check
 [<c010e5c5>] (unwind_backtrace) from [<c010a1c5>] (show_stack+0x11/0x14)
 [<c010a1c5>] (show_stack) from [<c0973925>] (dump_stack+0x85/0x94)
 [<c0973925>] (dump_stack) from [<c011f529>] (__warn+0xc1/0xc4)
 [<c011f529>] (__warn) from [<c011f7e9>] (warn_slowpath_fmt+0x61/0x78)
 [<c011f7e9>] (warn_slowpath_fmt) from [<c042497d>] (__list_del_entry_valid+0x45/0xac)
 [<c042497d>] (__list_del_entry_valid) from [<c047a87f>] (tegra_dma_tasklet+0x5b/0x154)
 [<c047a87f>] (tegra_dma_tasklet) from [<c0124799>] (tasklet_action_common.constprop.0+0x41/0x7c)
 [<c0124799>] (tasklet_action_common.constprop.0) from [<c01022ab>] (__do_softirq+0xd3/0x2a8)
 [<c01022ab>] (__do_softirq) from [<c0124683>] (irq_exit+0x7b/0x98)
 [<c0124683>] (irq_exit) from [<c0168c19>] (__handle_domain_irq+0x45/0x80)
 [<c0168c19>] (__handle_domain_irq) from [<c043e429>] (gic_handle_irq+0x45/0x7c)
 [<c043e429>] (gic_handle_irq) from [<c0101aa5>] (__irq_svc+0x65/0x94)
 Exception stack(0xde2ebb90 to 0xde2ebbd8)

Cc: <stable@vger.kernel.org>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
---
 drivers/dma/tegra20-apb-dma.c | 4 ----
 1 file changed, 4 deletions(-)

Comments

Jon Hunter Jan. 14, 2020, 3:09 p.m. UTC | #1
On 12/01/2020 17:29, Dmitry Osipenko wrote:
> I was doing some experiments with I2C and noticed that Tegra APB DMA
> driver crashes sometime after I2C DMA transfer termination. The crash
> happens because tegra_dma_terminate_all() bails out immediately if pending
> list is empty, thus it doesn't release the half-completed descriptors
> which are getting re-used before ISR tasklet kicks-in.

Can you elaborate a bit more on how these are getting re-used? What is
the sequence of events which results in the panic? I believe that this
was also reported in the past [0] and so I don't doubt there is an issue
here, but would like to completely understand this.

Thanks!
Jon

[0] https://lore.kernel.org/patchwork/patch/675349/
Dmitry Osipenko Jan. 14, 2020, 8:33 p.m. UTC | #2
14.01.2020 18:09, Jon Hunter пишет:
> 
> On 12/01/2020 17:29, Dmitry Osipenko wrote:
>> I was doing some experiments with I2C and noticed that Tegra APB DMA
>> driver crashes sometime after I2C DMA transfer termination. The crash
>> happens because tegra_dma_terminate_all() bails out immediately if pending
>> list is empty, thus it doesn't release the half-completed descriptors
>> which are getting re-used before ISR tasklet kicks-in.
> 
> Can you elaborate a bit more on how these are getting re-used? What is
> the sequence of events which results in the panic? I believe that this
> was also reported in the past [0] and so I don't doubt there is an issue
> here, but would like to completely understand this.
> 
> Thanks!
> Jon
> 
> [0] https://lore.kernel.org/patchwork/patch/675349/
> 

In my case it happens in the touchscreen driver during of the
touchscreen's interrupt handling (in a threaded IRQ handler) + CPU is
under load and there is other interrupts activity. So what happens here
is that the TS driver issues one I2C transfer, which fails with
(apparently bogus) timeout (because DMA descriptor is completed and
removed from the pending list, but tasklet not executed yet), and then
TS immediately issues another I2C transfer that re-uses the
yet-incompleted descriptor. That's my understanding.
Jon Hunter Jan. 15, 2020, 9 a.m. UTC | #3
On 14/01/2020 20:33, Dmitry Osipenko wrote:
> 14.01.2020 18:09, Jon Hunter пишет:
>>
>> On 12/01/2020 17:29, Dmitry Osipenko wrote:
>>> I was doing some experiments with I2C and noticed that Tegra APB DMA
>>> driver crashes sometime after I2C DMA transfer termination. The crash
>>> happens because tegra_dma_terminate_all() bails out immediately if pending
>>> list is empty, thus it doesn't release the half-completed descriptors
>>> which are getting re-used before ISR tasklet kicks-in.
>>
>> Can you elaborate a bit more on how these are getting re-used? What is
>> the sequence of events which results in the panic? I believe that this
>> was also reported in the past [0] and so I don't doubt there is an issue
>> here, but would like to completely understand this.
>>
>> Thanks!
>> Jon
>>
>> [0] https://lore.kernel.org/patchwork/patch/675349/
>>
> 
> In my case it happens in the touchscreen driver during of the
> touchscreen's interrupt handling (in a threaded IRQ handler) + CPU is
> under load and there is other interrupts activity. So what happens here
> is that the TS driver issues one I2C transfer, which fails with
> (apparently bogus) timeout (because DMA descriptor is completed and
> removed from the pending list, but tasklet not executed yet), and then
> TS immediately issues another I2C transfer that re-uses the
> yet-incompleted descriptor. That's my understanding.

OK, but what is the exact sequence that it allowing it to re-use the
incompleted descriptor?

Thanks
Jon
Dmitry Osipenko Jan. 16, 2020, 8:10 p.m. UTC | #4
15.01.2020 12:00, Jon Hunter пишет:
> 
> On 14/01/2020 20:33, Dmitry Osipenko wrote:
>> 14.01.2020 18:09, Jon Hunter пишет:
>>>
>>> On 12/01/2020 17:29, Dmitry Osipenko wrote:
>>>> I was doing some experiments with I2C and noticed that Tegra APB DMA
>>>> driver crashes sometime after I2C DMA transfer termination. The crash
>>>> happens because tegra_dma_terminate_all() bails out immediately if pending
>>>> list is empty, thus it doesn't release the half-completed descriptors
>>>> which are getting re-used before ISR tasklet kicks-in.
>>>
>>> Can you elaborate a bit more on how these are getting re-used? What is
>>> the sequence of events which results in the panic? I believe that this
>>> was also reported in the past [0] and so I don't doubt there is an issue
>>> here, but would like to completely understand this.
>>>
>>> Thanks!
>>> Jon
>>>
>>> [0] https://lore.kernel.org/patchwork/patch/675349/
>>>
>>
>> In my case it happens in the touchscreen driver during of the
>> touchscreen's interrupt handling (in a threaded IRQ handler) + CPU is
>> under load and there is other interrupts activity. So what happens here
>> is that the TS driver issues one I2C transfer, which fails with
>> (apparently bogus) timeout (because DMA descriptor is completed and
>> removed from the pending list, but tasklet not executed yet), and then
>> TS immediately issues another I2C transfer that re-uses the
>> yet-incompleted descriptor. That's my understanding.
> 
> OK, but what is the exact sequence that it allowing it to re-use the
> incompleted descriptor?

   TDMA driver                      DMA Client

1.
                                    dmaengine_prep()

2.
   tegra_dma_desc_get()
   dma_desc = kzalloc()
   ...
   tegra_dma_prep_slave_sg()
   INIT_LIST_HEAD(&dma_desc->tx_list);
   INIT_LIST_HEAD(&dma_desc->cb_node);
   list_add_tail(sgreq->node,
                 dma_desc->tx_list)

3.
                                    dma_async_issue_pending()

4.
   tegra_dma_tx_submit()
   list_splice_tail_init(dma_desc->tx_list,
                         tdc->pending_sg_req)

5.
   tegra_dma_isr()
   ...
   handle_once_dma_done()
   ...
   sgreq = list_first_entry(tdc->pending_sg_req)
   list_del(sgreq->node);
   ...
   list_add_tail(dma_desc->cb_node,
                 tdc->cb_desc);
   list_add_tail(dma_desc->node,
                 tdc->free_dma_desc);
   ...
   tasklet_schedule(&tdc->tasklet);
   ...

6.
                                    timeout
                                    dmaengine_terminate_async()

7.
   tegra_dma_terminate_all()
   if (list_empty(tdc->pending_sg_req))
       return 0;

8.
                                    dmaengine_prep()

9.
   tegra_dma_desc_get()
   list_for_each_entry(dma_desc,
                       tdc->free_dma_desc) {
       list_del(dma_desc->node);
       return dma_desc;
   }
   ...
   tegra_dma_prep_slave_sg()
   INIT_LIST_HEAD(&dma_desc->tx_list);
   INIT_LIST_HEAD(&dma_desc->cb_node);

   *** tdc->cb_desc list is wrecked now! ***

   list_add_tail(sgreq->node,
                 dma_desc->tx_list)
   ...

10.
   same actions as in #4 #5 ...

11.
   tegra_dma_tasklet()
   dma_desc = list_first_entry(tdc->cb_desc)
   list_del(dma_desc->cb_node);

   eventual woopsie
Jon Hunter Jan. 28, 2020, 2:02 p.m. UTC | #5
On 16/01/2020 20:10, Dmitry Osipenko wrote:
> 15.01.2020 12:00, Jon Hunter пишет:
>>
>> On 14/01/2020 20:33, Dmitry Osipenko wrote:
>>> 14.01.2020 18:09, Jon Hunter пишет:
>>>>
>>>> On 12/01/2020 17:29, Dmitry Osipenko wrote:
>>>>> I was doing some experiments with I2C and noticed that Tegra APB DMA
>>>>> driver crashes sometime after I2C DMA transfer termination. The crash
>>>>> happens because tegra_dma_terminate_all() bails out immediately if pending
>>>>> list is empty, thus it doesn't release the half-completed descriptors
>>>>> which are getting re-used before ISR tasklet kicks-in.
>>>>
>>>> Can you elaborate a bit more on how these are getting re-used? What is
>>>> the sequence of events which results in the panic? I believe that this
>>>> was also reported in the past [0] and so I don't doubt there is an issue
>>>> here, but would like to completely understand this.
>>>>
>>>> Thanks!
>>>> Jon
>>>>
>>>> [0] https://lore.kernel.org/patchwork/patch/675349/
>>>>
>>>
>>> In my case it happens in the touchscreen driver during of the
>>> touchscreen's interrupt handling (in a threaded IRQ handler) + CPU is
>>> under load and there is other interrupts activity. So what happens here
>>> is that the TS driver issues one I2C transfer, which fails with
>>> (apparently bogus) timeout (because DMA descriptor is completed and
>>> removed from the pending list, but tasklet not executed yet), and then
>>> TS immediately issues another I2C transfer that re-uses the
>>> yet-incompleted descriptor. That's my understanding.
>>
>> OK, but what is the exact sequence that it allowing it to re-use the
>> incompleted descriptor?
> 
>    TDMA driver                      DMA Client
> 
> 1.
>                                     dmaengine_prep()
> 
> 2.
>    tegra_dma_desc_get()
>    dma_desc = kzalloc()
>    ...
>    tegra_dma_prep_slave_sg()
>    INIT_LIST_HEAD(&dma_desc->tx_list);
>    INIT_LIST_HEAD(&dma_desc->cb_node);
>    list_add_tail(sgreq->node,
>                  dma_desc->tx_list)
> 
> 3.
>                                     dma_async_issue_pending()
> 
> 4.
>    tegra_dma_tx_submit()
>    list_splice_tail_init(dma_desc->tx_list,
>                          tdc->pending_sg_req)
> 
> 5.
>    tegra_dma_isr()
>    ...
>    handle_once_dma_done()
>    ...
>    sgreq = list_first_entry(tdc->pending_sg_req)
>    list_del(sgreq->node);
>    ...
>    list_add_tail(dma_desc->cb_node,
>                  tdc->cb_desc);
>    list_add_tail(dma_desc->node,
>                  tdc->free_dma_desc);

Isn't this the problem here, that we have placed this on the free list
before we are actually done?

It seems to me that there could still be a potential race condition
between the ISR and the tasklet running.

Jon
Dmitry Osipenko Jan. 28, 2020, 2:51 p.m. UTC | #6
28.01.2020 17:02, Jon Hunter пишет:
> 
> On 16/01/2020 20:10, Dmitry Osipenko wrote:
>> 15.01.2020 12:00, Jon Hunter пишет:
>>>
>>> On 14/01/2020 20:33, Dmitry Osipenko wrote:
>>>> 14.01.2020 18:09, Jon Hunter пишет:
>>>>>
>>>>> On 12/01/2020 17:29, Dmitry Osipenko wrote:
>>>>>> I was doing some experiments with I2C and noticed that Tegra APB DMA
>>>>>> driver crashes sometime after I2C DMA transfer termination. The crash
>>>>>> happens because tegra_dma_terminate_all() bails out immediately if pending
>>>>>> list is empty, thus it doesn't release the half-completed descriptors
>>>>>> which are getting re-used before ISR tasklet kicks-in.
>>>>>
>>>>> Can you elaborate a bit more on how these are getting re-used? What is
>>>>> the sequence of events which results in the panic? I believe that this
>>>>> was also reported in the past [0] and so I don't doubt there is an issue
>>>>> here, but would like to completely understand this.
>>>>>
>>>>> Thanks!
>>>>> Jon
>>>>>
>>>>> [0] https://lore.kernel.org/patchwork/patch/675349/
>>>>>
>>>>
>>>> In my case it happens in the touchscreen driver during of the
>>>> touchscreen's interrupt handling (in a threaded IRQ handler) + CPU is
>>>> under load and there is other interrupts activity. So what happens here
>>>> is that the TS driver issues one I2C transfer, which fails with
>>>> (apparently bogus) timeout (because DMA descriptor is completed and
>>>> removed from the pending list, but tasklet not executed yet), and then
>>>> TS immediately issues another I2C transfer that re-uses the
>>>> yet-incompleted descriptor. That's my understanding.
>>>
>>> OK, but what is the exact sequence that it allowing it to re-use the
>>> incompleted descriptor?
>>
>>    TDMA driver                      DMA Client
>>
>> 1.
>>                                     dmaengine_prep()
>>
>> 2.
>>    tegra_dma_desc_get()
>>    dma_desc = kzalloc()
>>    ...
>>    tegra_dma_prep_slave_sg()
>>    INIT_LIST_HEAD(&dma_desc->tx_list);
>>    INIT_LIST_HEAD(&dma_desc->cb_node);
>>    list_add_tail(sgreq->node,
>>                  dma_desc->tx_list)
>>
>> 3.
>>                                     dma_async_issue_pending()
>>
>> 4.
>>    tegra_dma_tx_submit()
>>    list_splice_tail_init(dma_desc->tx_list,
>>                          tdc->pending_sg_req)
>>
>> 5.
>>    tegra_dma_isr()
>>    ...
>>    handle_once_dma_done()
>>    ...
>>    sgreq = list_first_entry(tdc->pending_sg_req)
>>    list_del(sgreq->node);
>>    ...
>>    list_add_tail(dma_desc->cb_node,
>>                  tdc->cb_desc);
>>    list_add_tail(dma_desc->node,
>>                  tdc->free_dma_desc);
> 
> Isn't this the problem here, that we have placed this on the free list
> before we are actually done?
> 
> It seems to me that there could still be a potential race condition
> between the ISR and the tasklet running.

Yes, this should be addressed by the patch #3 "dmaengine: tegra-apb:
Prevent race conditions of tasklet vs free list".
Dmitry Osipenko Jan. 29, 2020, 12:12 a.m. UTC | #7
28.01.2020 17:51, Dmitry Osipenko пишет:
> 28.01.2020 17:02, Jon Hunter пишет:
>>
>> On 16/01/2020 20:10, Dmitry Osipenko wrote:
>>> 15.01.2020 12:00, Jon Hunter пишет:
>>>>
>>>> On 14/01/2020 20:33, Dmitry Osipenko wrote:
>>>>> 14.01.2020 18:09, Jon Hunter пишет:
>>>>>>
>>>>>> On 12/01/2020 17:29, Dmitry Osipenko wrote:
>>>>>>> I was doing some experiments with I2C and noticed that Tegra APB DMA
>>>>>>> driver crashes sometime after I2C DMA transfer termination. The crash
>>>>>>> happens because tegra_dma_terminate_all() bails out immediately if pending
>>>>>>> list is empty, thus it doesn't release the half-completed descriptors
>>>>>>> which are getting re-used before ISR tasklet kicks-in.
>>>>>>
>>>>>> Can you elaborate a bit more on how these are getting re-used? What is
>>>>>> the sequence of events which results in the panic? I believe that this
>>>>>> was also reported in the past [0] and so I don't doubt there is an issue
>>>>>> here, but would like to completely understand this.
>>>>>>
>>>>>> Thanks!
>>>>>> Jon
>>>>>>
>>>>>> [0] https://lore.kernel.org/patchwork/patch/675349/
>>>>>>
>>>>>
>>>>> In my case it happens in the touchscreen driver during of the
>>>>> touchscreen's interrupt handling (in a threaded IRQ handler) + CPU is
>>>>> under load and there is other interrupts activity. So what happens here
>>>>> is that the TS driver issues one I2C transfer, which fails with
>>>>> (apparently bogus) timeout (because DMA descriptor is completed and
>>>>> removed from the pending list, but tasklet not executed yet), and then
>>>>> TS immediately issues another I2C transfer that re-uses the
>>>>> yet-incompleted descriptor. That's my understanding.
>>>>
>>>> OK, but what is the exact sequence that it allowing it to re-use the
>>>> incompleted descriptor?
>>>
>>>    TDMA driver                      DMA Client
>>>
>>> 1.
>>>                                     dmaengine_prep()
>>>
>>> 2.
>>>    tegra_dma_desc_get()
>>>    dma_desc = kzalloc()
>>>    ...
>>>    tegra_dma_prep_slave_sg()
>>>    INIT_LIST_HEAD(&dma_desc->tx_list);
>>>    INIT_LIST_HEAD(&dma_desc->cb_node);
>>>    list_add_tail(sgreq->node,
>>>                  dma_desc->tx_list)
>>>
>>> 3.
>>>                                     dma_async_issue_pending()
>>>
>>> 4.
>>>    tegra_dma_tx_submit()
>>>    list_splice_tail_init(dma_desc->tx_list,
>>>                          tdc->pending_sg_req)
>>>
>>> 5.
>>>    tegra_dma_isr()
>>>    ...
>>>    handle_once_dma_done()
>>>    ...
>>>    sgreq = list_first_entry(tdc->pending_sg_req)
>>>    list_del(sgreq->node);
>>>    ...
>>>    list_add_tail(dma_desc->cb_node,
>>>                  tdc->cb_desc);
>>>    list_add_tail(dma_desc->node,
>>>                  tdc->free_dma_desc);
>>
>> Isn't this the problem here, that we have placed this on the free list
>> before we are actually done?
>>
>> It seems to me that there could still be a potential race condition
>> between the ISR and the tasklet running.
> 
> Yes, this should be addressed by the patch #3 "dmaengine: tegra-apb:
> Prevent race conditions of tasklet vs free list".

correction (to avoid confusion): it's actually patch #5, my bad
Jon Hunter Jan. 29, 2020, 10:42 a.m. UTC | #8
On 29/01/2020 00:12, Dmitry Osipenko wrote:
> 28.01.2020 17:51, Dmitry Osipenko пишет:
>> 28.01.2020 17:02, Jon Hunter пишет:
>>>
>>> On 16/01/2020 20:10, Dmitry Osipenko wrote:
>>>> 15.01.2020 12:00, Jon Hunter пишет:
>>>>>
>>>>> On 14/01/2020 20:33, Dmitry Osipenko wrote:
>>>>>> 14.01.2020 18:09, Jon Hunter пишет:
>>>>>>>
>>>>>>> On 12/01/2020 17:29, Dmitry Osipenko wrote:
>>>>>>>> I was doing some experiments with I2C and noticed that Tegra APB DMA
>>>>>>>> driver crashes sometime after I2C DMA transfer termination. The crash
>>>>>>>> happens because tegra_dma_terminate_all() bails out immediately if pending
>>>>>>>> list is empty, thus it doesn't release the half-completed descriptors
>>>>>>>> which are getting re-used before ISR tasklet kicks-in.
>>>>>>>
>>>>>>> Can you elaborate a bit more on how these are getting re-used? What is
>>>>>>> the sequence of events which results in the panic? I believe that this
>>>>>>> was also reported in the past [0] and so I don't doubt there is an issue
>>>>>>> here, but would like to completely understand this.
>>>>>>>
>>>>>>> Thanks!
>>>>>>> Jon
>>>>>>>
>>>>>>> [0] https://lore.kernel.org/patchwork/patch/675349/
>>>>>>>
>>>>>>
>>>>>> In my case it happens in the touchscreen driver during of the
>>>>>> touchscreen's interrupt handling (in a threaded IRQ handler) + CPU is
>>>>>> under load and there is other interrupts activity. So what happens here
>>>>>> is that the TS driver issues one I2C transfer, which fails with
>>>>>> (apparently bogus) timeout (because DMA descriptor is completed and
>>>>>> removed from the pending list, but tasklet not executed yet), and then
>>>>>> TS immediately issues another I2C transfer that re-uses the
>>>>>> yet-incompleted descriptor. That's my understanding.
>>>>>
>>>>> OK, but what is the exact sequence that it allowing it to re-use the
>>>>> incompleted descriptor?
>>>>
>>>>    TDMA driver                      DMA Client
>>>>
>>>> 1.
>>>>                                     dmaengine_prep()
>>>>
>>>> 2.
>>>>    tegra_dma_desc_get()
>>>>    dma_desc = kzalloc()
>>>>    ...
>>>>    tegra_dma_prep_slave_sg()
>>>>    INIT_LIST_HEAD(&dma_desc->tx_list);
>>>>    INIT_LIST_HEAD(&dma_desc->cb_node);
>>>>    list_add_tail(sgreq->node,
>>>>                  dma_desc->tx_list)
>>>>
>>>> 3.
>>>>                                     dma_async_issue_pending()
>>>>
>>>> 4.
>>>>    tegra_dma_tx_submit()
>>>>    list_splice_tail_init(dma_desc->tx_list,
>>>>                          tdc->pending_sg_req)
>>>>
>>>> 5.
>>>>    tegra_dma_isr()
>>>>    ...
>>>>    handle_once_dma_done()
>>>>    ...
>>>>    sgreq = list_first_entry(tdc->pending_sg_req)
>>>>    list_del(sgreq->node);
>>>>    ...
>>>>    list_add_tail(dma_desc->cb_node,
>>>>                  tdc->cb_desc);
>>>>    list_add_tail(dma_desc->node,
>>>>                  tdc->free_dma_desc);
>>>
>>> Isn't this the problem here, that we have placed this on the free list
>>> before we are actually done?
>>>
>>> It seems to me that there could still be a potential race condition
>>> between the ISR and the tasklet running.
>>
>> Yes, this should be addressed by the patch #3 "dmaengine: tegra-apb:
>> Prevent race conditions of tasklet vs free list".
> 
> correction (to avoid confusion): it's actually patch #5, my bad

Ah OK great! Could be worth making that patch #1 or #2 in the series as
theses are somewhat related.

Cheers
Jon
diff mbox series

Patch

diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index 3a45079d11ec..319f31d27014 100644
--- a/drivers/dma/tegra20-apb-dma.c
+++ b/drivers/dma/tegra20-apb-dma.c
@@ -756,10 +756,6 @@  static int tegra_dma_terminate_all(struct dma_chan *dc)
 	bool was_busy;
 
 	spin_lock_irqsave(&tdc->lock, flags);
-	if (list_empty(&tdc->pending_sg_req)) {
-		spin_unlock_irqrestore(&tdc->lock, flags);
-		return 0;
-	}
 
 	if (!tdc->busy)
 		goto skip_dma_stop;