2018-12-07 04:30:42

by Shunyong Yang

[permalink] [raw]
Subject: [PATCH 1/2] dmaengine: qcom_hidma: initialize tx flags in hidma_prep_dma_*

In async_tx_test_ack(), it uses flags in struct dma_async_tx_descriptor
to check the ACK status. As hidma reuses the descriptor in a free list
when hidma_prep_dma_*(memcpy/memset) is called, the flag will keep ACKed
if the descriptor has been used before. This will cause a BUG_ON in
async_tx_quiesce().

kernel BUG at crypto/async_tx/async_tx.c:282!
Internal error: Oops - BUG: 0 1 SMP
...
task: ffff8017dd3ec000 task.stack: ffff8017dd3e8000
PC is at async_tx_quiesce+0x54/0x78 [async_tx]
LR is at async_trigger_callback+0x98/0x110 [async_tx]

This patch initializes flags in dma_async_tx_descriptor by the flags
passed from the caller when hidma_prep_dma_*(memcpy/memset) is called.

Cc: Joey Zheng <[email protected]>
Signed-off-by: Shunyong Yang <[email protected]>
---
drivers/dma/qcom/hidma.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index 43d4b00b8138..9d639ed1955a 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -415,6 +415,7 @@ static int hidma_alloc_chan_resources(struct dma_chan *dmach)
if (!mdesc)
return NULL;

+ mdesc->desc.flags = flags;
hidma_ll_set_transfer_params(mdma->lldev, mdesc->tre_ch,
src, dest, len, flags,
HIDMA_TRE_MEMCPY);
@@ -447,6 +448,7 @@ static int hidma_alloc_chan_resources(struct dma_chan *dmach)
if (!mdesc)
return NULL;

+ mdesc->desc.flags = flags;
hidma_ll_set_transfer_params(mdma->lldev, mdesc->tre_ch,
value, dest, len, flags,
HIDMA_TRE_MEMSET);
--
1.8.3.1



2018-12-07 04:32:17

by Shunyong Yang

[permalink] [raw]
Subject: [PATCH 2/2] dmaengine: qcom_hidma: assign channel cookie correctly

When dma_cookie_complete() is called in hidma_process_completed(),
dma_cookie_status() will return DMA_COMPLETE in hidma_tx_status(). Then,
hidma_txn_is_success() will be called to use channel cookie
mchan->last_success to do additional DMA status check. Current code
assigns mchan->last_success after dma_cookie_complete(). This causes
a race condition of dma_cookie_status() returns DMA_COMPLETE before
mchan->last_success is assigned correctly. The race will cause
hidma_tx_status() return DMA_ERROR but the transaction is actually a
success. Moreover, in async_tx case, it will cause a timeout panic
in async_tx_quiesce().

Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for
transaction
...
Call trace:
[<ffff000008089994>] dump_backtrace+0x0/0x1f4
[<ffff000008089bac>] show_stack+0x24/0x2c
[<ffff00000891e198>] dump_stack+0x84/0xa8
[<ffff0000080da544>] panic+0x12c/0x29c
[<ffff0000045d0334>] async_tx_quiesce+0xa4/0xc8 [async_tx]
[<ffff0000045d03c8>] async_trigger_callback+0x70/0x1c0 [async_tx]
[<ffff0000048b7d74>] raid_run_ops+0x86c/0x1540 [raid456]
[<ffff0000048bd084>] handle_stripe+0x5e8/0x1c7c [raid456]
[<ffff0000048be9ec>] handle_active_stripes.isra.45+0x2d4/0x550 [raid456]
[<ffff0000048beff4>] raid5d+0x38c/0x5d0 [raid456]
[<ffff000008736538>] md_thread+0x108/0x168
[<ffff0000080fb1cc>] kthread+0x10c/0x138
[<ffff000008084d34>] ret_from_fork+0x10/0x18

Cc: Joey Zheng <[email protected]>
Signed-off-by: Shunyong Yang <[email protected]>
---
drivers/dma/qcom/hidma.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index 9d639ed1955a..aa88bcceda20 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -138,24 +138,24 @@ static void hidma_process_completed(struct hidma_chan *mchan)
desc = &mdesc->desc;
last_cookie = desc->cookie;

+ llstat = hidma_ll_status(mdma->lldev, mdesc->tre_ch);
+
spin_lock_irqsave(&mchan->lock, irqflags);
+ if (llstat == DMA_COMPLETE) {
+ mchan->last_success = last_cookie;
+ result.result = DMA_TRANS_NOERROR;
+ } else
+ result.result = DMA_TRANS_ABORTED;
+
dma_cookie_complete(desc);
spin_unlock_irqrestore(&mchan->lock, irqflags);

- llstat = hidma_ll_status(mdma->lldev, mdesc->tre_ch);
dmaengine_desc_get_callback(desc, &cb);

dma_run_dependencies(desc);

spin_lock_irqsave(&mchan->lock, irqflags);
list_move(&mdesc->node, &mchan->free);
-
- if (llstat == DMA_COMPLETE) {
- mchan->last_success = last_cookie;
- result.result = DMA_TRANS_NOERROR;
- } else
- result.result = DMA_TRANS_ABORTED;
-
spin_unlock_irqrestore(&mchan->lock, irqflags);

dmaengine_desc_callback_invoke(&cb, &result);
--
1.8.3.1


2018-12-08 20:30:00

by Sinan Kaya

[permalink] [raw]
Subject: Re: [PATCH 2/2] dmaengine: qcom_hidma: assign channel cookie correctly

On 12/6/2018 11:29 PM, Shunyong Yang wrote:
> When dma_cookie_complete() is called in hidma_process_completed(),
> dma_cookie_status() will return DMA_COMPLETE in hidma_tx_status(). Then,
> hidma_txn_is_success() will be called to use channel cookie
> mchan->last_success to do additional DMA status check. Current code
> assigns mchan->last_success after dma_cookie_complete(). This causes
> a race condition of dma_cookie_status() returns DMA_COMPLETE before
> mchan->last_success is assigned correctly. The race will cause
> hidma_tx_status() return DMA_ERROR but the transaction is actually a
> success. Moreover, in async_tx case, it will cause a timeout panic
> in async_tx_quiesce().
>
> Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for
> transaction
> ...
> Call trace:
> [<ffff000008089994>] dump_backtrace+0x0/0x1f4
> [<ffff000008089bac>] show_stack+0x24/0x2c
> [<ffff00000891e198>] dump_stack+0x84/0xa8
> [<ffff0000080da544>] panic+0x12c/0x29c
> [<ffff0000045d0334>] async_tx_quiesce+0xa4/0xc8 [async_tx]
> [<ffff0000045d03c8>] async_trigger_callback+0x70/0x1c0 [async_tx]
> [<ffff0000048b7d74>] raid_run_ops+0x86c/0x1540 [raid456]
> [<ffff0000048bd084>] handle_stripe+0x5e8/0x1c7c [raid456]
> [<ffff0000048be9ec>] handle_active_stripes.isra.45+0x2d4/0x550 [raid456]
> [<ffff0000048beff4>] raid5d+0x38c/0x5d0 [raid456]
> [<ffff000008736538>] md_thread+0x108/0x168
> [<ffff0000080fb1cc>] kthread+0x10c/0x138
> [<ffff000008084d34>] ret_from_fork+0x10/0x18
>
> Cc: Joey Zheng<[email protected]>
> Signed-off-by: Shunyong Yang<[email protected]>


Acked-by: Sinan Kaya <[email protected]>

to both patches 1/2 and 2/2.


2018-12-14 01:06:34

by Shunyong Yang

[permalink] [raw]
Subject: Re: [PATCH 2/2] dmaengine: qcom_hidma: assign channel cookie correctly

Hi, Sinan

On 2018/12/9 4:28, Sinan Kaya wrote:
> On 12/6/2018 11:29 PM, Shunyong Yang wrote:
>> When dma_cookie_complete() is called in hidma_process_completed(),
>> dma_cookie_status() will return DMA_COMPLETE in hidma_tx_status(). Then,
>> hidma_txn_is_success() will be called to use channel cookie
>> mchan->last_success to do additional DMA status check. Current code
>> assigns mchan->last_success after dma_cookie_complete(). This causes
>> a race condition of dma_cookie_status() returns DMA_COMPLETE before
>> mchan->last_success is assigned correctly. The race will cause
>> hidma_tx_status() return DMA_ERROR but the transaction is actually a
>> success. Moreover, in async_tx case, it will cause a timeout panic
>> in async_tx_quiesce().
>>
>> Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for
>> transaction
>> ...
>> Call trace:
>> [<ffff000008089994>] dump_backtrace+0x0/0x1f4
>> [<ffff000008089bac>] show_stack+0x24/0x2c
>> [<ffff00000891e198>] dump_stack+0x84/0xa8
>> [<ffff0000080da544>] panic+0x12c/0x29c
>> [<ffff0000045d0334>] async_tx_quiesce+0xa4/0xc8 [async_tx]
>> [<ffff0000045d03c8>] async_trigger_callback+0x70/0x1c0 [async_tx]
>> [<ffff0000048b7d74>] raid_run_ops+0x86c/0x1540 [raid456]
>> [<ffff0000048bd084>] handle_stripe+0x5e8/0x1c7c [raid456]
>> [<ffff0000048be9ec>] handle_active_stripes.isra.45+0x2d4/0x550 [raid456]
>> [<ffff0000048beff4>] raid5d+0x38c/0x5d0 [raid456]
>> [<ffff000008736538>] md_thread+0x108/0x168
>> [<ffff0000080fb1cc>] kthread+0x10c/0x138
>> [<ffff000008084d34>] ret_from_fork+0x10/0x18
>>
>> Cc: Joey Zheng<[email protected]>
>> Signed-off-by: Shunyong Yang<[email protected]>
>
>
> Acked-by: Sinan Kaya <[email protected]>
>
> to both patches 1/2 and 2/2.
>
>
Thanks for the ACKs.

Shunyong.


2019-01-04 10:21:58

by Shunyong Yang

[permalink] [raw]
Subject: Re: [PATCH 2/2] dmaengine: qcom_hidma: assign channel cookie correctly

Hi, Vinod,

Gentle ping. Would you please help to review these two patches and merge?

On 2018/12/14 9:03, Yang, Shunyong wrote:
> Hi, Sinan
>
> On 2018/12/9 4:28, Sinan Kaya wrote:
>> On 12/6/2018 11:29 PM, Shunyong Yang wrote:
>>> When dma_cookie_complete() is called in hidma_process_completed(),
>>> dma_cookie_status() will return DMA_COMPLETE in hidma_tx_status(). Then,
>>> hidma_txn_is_success() will be called to use channel cookie
>>> mchan->last_success to do additional DMA status check. Current code
>>> assigns mchan->last_success after dma_cookie_complete(). This causes
>>> a race condition of dma_cookie_status() returns DMA_COMPLETE before
>>> mchan->last_success is assigned correctly. The race will cause
>>> hidma_tx_status() return DMA_ERROR but the transaction is actually a
>>> success. Moreover, in async_tx case, it will cause a timeout panic
>>> in async_tx_quiesce().
>>>
>>> Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for
>>> transaction
>>> ...
>>> Call trace:
>>> [<ffff000008089994>] dump_backtrace+0x0/0x1f4
>>> [<ffff000008089bac>] show_stack+0x24/0x2c
>>> [<ffff00000891e198>] dump_stack+0x84/0xa8
>>> [<ffff0000080da544>] panic+0x12c/0x29c
>>> [<ffff0000045d0334>] async_tx_quiesce+0xa4/0xc8 [async_tx]
>>> [<ffff0000045d03c8>] async_trigger_callback+0x70/0x1c0 [async_tx]
>>> [<ffff0000048b7d74>] raid_run_ops+0x86c/0x1540 [raid456]
>>> [<ffff0000048bd084>] handle_stripe+0x5e8/0x1c7c [raid456]
>>> [<ffff0000048be9ec>] handle_active_stripes.isra.45+0x2d4/0x550 [raid456]
>>> [<ffff0000048beff4>] raid5d+0x38c/0x5d0 [raid456]
>>> [<ffff000008736538>] md_thread+0x108/0x168
>>> [<ffff0000080fb1cc>] kthread+0x10c/0x138
>>> [<ffff000008084d34>] ret_from_fork+0x10/0x18
>>>
>>> Cc: Joey Zheng<[email protected]>
>>> Signed-off-by: Shunyong Yang<[email protected]>
>>
>>
>> Acked-by: Sinan Kaya <[email protected]>
>>
>> to both patches 1/2 and 2/2.
>>
>>
> Thanks for the ACKs.
>
> Shunyong.
>
>


2019-01-04 19:01:52

by Vinod Koul

[permalink] [raw]
Subject: Re: [PATCH 2/2] dmaengine: qcom_hidma: assign channel cookie correctly

On 07-12-18, 12:29, Shunyong Yang wrote:
> When dma_cookie_complete() is called in hidma_process_completed(),
> dma_cookie_status() will return DMA_COMPLETE in hidma_tx_status(). Then,
> hidma_txn_is_success() will be called to use channel cookie
> mchan->last_success to do additional DMA status check. Current code
> assigns mchan->last_success after dma_cookie_complete(). This causes
> a race condition of dma_cookie_status() returns DMA_COMPLETE before
> mchan->last_success is assigned correctly. The race will cause
> hidma_tx_status() return DMA_ERROR but the transaction is actually a
> success. Moreover, in async_tx case, it will cause a timeout panic
> in async_tx_quiesce().
>
> Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for
> transaction
> ...
> Call trace:
> [<ffff000008089994>] dump_backtrace+0x0/0x1f4
> [<ffff000008089bac>] show_stack+0x24/0x2c
> [<ffff00000891e198>] dump_stack+0x84/0xa8
> [<ffff0000080da544>] panic+0x12c/0x29c
> [<ffff0000045d0334>] async_tx_quiesce+0xa4/0xc8 [async_tx]
> [<ffff0000045d03c8>] async_trigger_callback+0x70/0x1c0 [async_tx]
> [<ffff0000048b7d74>] raid_run_ops+0x86c/0x1540 [raid456]
> [<ffff0000048bd084>] handle_stripe+0x5e8/0x1c7c [raid456]
> [<ffff0000048be9ec>] handle_active_stripes.isra.45+0x2d4/0x550 [raid456]
> [<ffff0000048beff4>] raid5d+0x38c/0x5d0 [raid456]
> [<ffff000008736538>] md_thread+0x108/0x168
> [<ffff0000080fb1cc>] kthread+0x10c/0x138
> [<ffff000008084d34>] ret_from_fork+0x10/0x18
>
> Cc: Joey Zheng <[email protected]>
> Signed-off-by: Shunyong Yang <[email protected]>
> ---
> drivers/dma/qcom/hidma.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
> index 9d639ed1955a..aa88bcceda20 100644
> --- a/drivers/dma/qcom/hidma.c
> +++ b/drivers/dma/qcom/hidma.c
> @@ -138,24 +138,24 @@ static void hidma_process_completed(struct hidma_chan *mchan)
> desc = &mdesc->desc;
> last_cookie = desc->cookie;
>
> + llstat = hidma_ll_status(mdma->lldev, mdesc->tre_ch);
> +
> spin_lock_irqsave(&mchan->lock, irqflags);
> + if (llstat == DMA_COMPLETE) {
> + mchan->last_success = last_cookie;
> + result.result = DMA_TRANS_NOERROR;
> + } else
> + result.result = DMA_TRANS_ABORTED;

Coding style mandates that else should also have braces, please fix that

--
~Vinod