1. We need a write lock in mhi_gen_tre otherwise there is race of the WP
used for ringing channel DB between mhi_queue and M0 transition.
2. We can not invoke local_bh_enable() when irqs are disabled, so move
read_lock_irqsave() under the mhi_gen_tre() since we add write_lock_bh() in
mhi_gen_tre().
v1 -> v2:
Added write_unlock_bh(&mhi_chan->lock) in mhi_gen_tre() before return
because of error process.
Bhaumik Bhatt (1):
bus: mhi: host: Add spinlock to protect WP access when queueing TREs
Hemant Kumar (1):
bus: mhi: host: Take irqsave lock after TRE is generated
drivers/bus/mhi/host/main.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
--
2.7.4
From: Hemant Kumar <[email protected]>
Take irqsave lock after TRE is generated to avoid deadlock due to core
getting interrupts enabled as local_bh_enable must not be called with
irqs disabled based on upstream patch.
Signed-off-by: Hemant Kumar <[email protected]>
Signed-off-by: Lazarus Motha <[email protected]>
Signed-off-by: Qiang Yu <[email protected]>
---
drivers/bus/mhi/host/main.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index 13c4b89..8accdfd 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -1124,17 +1124,15 @@ static int mhi_queue(struct mhi_device *mhi_dev, struct mhi_buf_info *buf_info,
if (unlikely(MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state)))
return -EIO;
- read_lock_irqsave(&mhi_cntrl->pm_lock, flags);
-
ret = mhi_is_ring_full(mhi_cntrl, tre_ring);
- if (unlikely(ret)) {
- ret = -EAGAIN;
- goto exit_unlock;
- }
+ if (unlikely(ret))
+ return -EAGAIN;
ret = mhi_gen_tre(mhi_cntrl, mhi_chan, buf_info, mflags);
if (unlikely(ret))
- goto exit_unlock;
+ return ret;
+
+ read_lock_irqsave(&mhi_cntrl->pm_lock, flags);
/* Packet is queued, take a usage ref to exit M3 if necessary
* for host->device buffer, balanced put is done on buffer completion
@@ -1154,7 +1152,6 @@ static int mhi_queue(struct mhi_device *mhi_dev, struct mhi_buf_info *buf_info,
if (dir == DMA_FROM_DEVICE)
mhi_cntrl->runtime_put(mhi_cntrl);
-exit_unlock:
read_unlock_irqrestore(&mhi_cntrl->pm_lock, flags);
return ret;
--
2.7.4
On 9/13/2023 2:47 AM, Qiang Yu wrote:
> From: Hemant Kumar <[email protected]>
>
> Take irqsave lock after TRE is generated to avoid deadlock due to core
> getting interrupts enabled as local_bh_enable must not be called with
> irqs disabled based on upstream patch.
Where is local_bh_enable() being called? What patch? What is upstream
of the codebase you submitted this to? Why is it safe to call
mhi_gen_tre() without the lock?
On 9/22/2023 10:50 PM, Jeffrey Hugo wrote:
> On 9/13/2023 2:47 AM, Qiang Yu wrote:
>> From: Hemant Kumar <[email protected]>
>>
>> Take irqsave lock after TRE is generated to avoid deadlock due to core
>> getting interrupts enabled as local_bh_enable must not be called with
>> irqs disabled based on upstream patch.
>
> Where is local_bh_enable() being called? What patch? What is
> upstream of the codebase you submitted this to? Why is it safe to
> call mhi_gen_tre() without the lock?
This patch is to fix the issue included by "[PATCH v2 1/2] bus: mhi:
host: Add spinlock to protect WP access when queueing TREs". In that
patch, we add write_lock_bh/write_unlock_bh in mhi_gen_tre().
However, before mhi_gen_tre() is invoked, mhi_cntrl->pm_lock is getted,
line 1125, and it is a spin lock. So it becomes we want to get and
release bh lock after spin lock. __local_bh_enable_ip is called as part
of write_unlock_bh
and local_bh_enable. When CONFIG_TRACE_IRQFLAGS is enabled, irq will be
enabled once __local_bh_enable_ip is called. The commit message is not
clear and confusing, will change it in [patch v3].
On 9/24/2023 10:08 PM, Qiang Yu wrote:
>
> On 9/22/2023 10:50 PM, Jeffrey Hugo wrote:
>> On 9/13/2023 2:47 AM, Qiang Yu wrote:
>>> From: Hemant Kumar <[email protected]>
>>>
>>> Take irqsave lock after TRE is generated to avoid deadlock due to core
>>> getting interrupts enabled as local_bh_enable must not be called with
>>> irqs disabled based on upstream patch.
>>
>> Where is local_bh_enable() being called? What patch? What is
>> upstream of the codebase you submitted this to? Why is it safe to
>> call mhi_gen_tre() without the lock?
>
> This patch is to fix the issue included by "[PATCH v2 1/2] bus: mhi:
> host: Add spinlock to protect WP access when queueing TREs". In that
> patch, we add write_lock_bh/write_unlock_bh in mhi_gen_tre().
>
> However, before mhi_gen_tre() is invoked, mhi_cntrl->pm_lock is getted,
> line 1125, and it is a spin lock. So it becomes we want to get and
> release bh lock after spin lock. __local_bh_enable_ip is called as part
> of write_unlock_bh
>
> and local_bh_enable. When CONFIG_TRACE_IRQFLAGS is enabled, irq will be
> enabled once __local_bh_enable_ip is called. The commit message is not
> clear and confusing, will change it in [patch v3].
>
In addition to clarifying the commit message, I recommend looking at
adding this to the other patch. It seems very odd to review a series
where one patch introduces a known issue, and a following patch corrects
that issue. It would be better to not introduce the issue in the first
place.
On 9/29/2023 11:25 PM, Jeffrey Hugo wrote:
> On 9/24/2023 10:08 PM, Qiang Yu wrote:
>>
>> On 9/22/2023 10:50 PM, Jeffrey Hugo wrote:
>>> On 9/13/2023 2:47 AM, Qiang Yu wrote:
>>>> From: Hemant Kumar <[email protected]>
>>>>
>>>> Take irqsave lock after TRE is generated to avoid deadlock due to core
>>>> getting interrupts enabled as local_bh_enable must not be called with
>>>> irqs disabled based on upstream patch.
>>>
>>> Where is local_bh_enable() being called? What patch? What is
>>> upstream of the codebase you submitted this to? Why is it safe to
>>> call mhi_gen_tre() without the lock?
>>
>> This patch is to fix the issue included by "[PATCH v2 1/2] bus: mhi:
>> host: Add spinlock to protect WP access when queueing TREs". In that
>> patch, we add write_lock_bh/write_unlock_bh in mhi_gen_tre().
>>
>> However, before mhi_gen_tre() is invoked, mhi_cntrl->pm_lock is
>> getted, line 1125, and it is a spin lock. So it becomes we want to
>> get and release bh lock after spin lock. __local_bh_enable_ip is
>> called as part of write_unlock_bh
>>
>> and local_bh_enable. When CONFIG_TRACE_IRQFLAGS is enabled, irq will
>> be enabled once __local_bh_enable_ip is called. The commit message is
>> not clear and confusing, will change it in [patch v3].
>>
>
> In addition to clarifying the commit message, I recommend looking at
> adding this to the other patch. It seems very odd to review a series
> where one patch introduces a known issue, and a following patch
> corrects that issue. It would be better to not introduce the issue in
> the first place.
OK, will squash two patches into one patch after we achieve an agreement.