From: gubbaven@codeaurora.org
To: Stephen Boyd <swboyd@chromium.org>
Cc: johan.hedberg@gmail.com, marcel@holtmann.org, mka@chromium.org,
linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
robh@kernel.org, hemantg@codeaurora.org,
linux-arm-msm@vger.kernel.org, bgodavar@codeaurora.org,
tientzu@chromium.org, seanpaul@chromium.org,
rjliao@codeaurora.org, yshavit@google.com
Subject: Re: [PATCH v3] Bluetooth: hci_qca: Bug fixes while collecting controller memory dump
Date: Fri, 14 Feb 2020 17:18:20 +0530 [thread overview]
Message-ID: <d37ca6d9414720b2355d552fa8b68629@codeaurora.org> (raw)
In-Reply-To: <158164697600.184098.7937205486686028830@swboyd.mtv.corp.google.com>
Hi Stephen,
On 2020-02-14 07:52, Stephen Boyd wrote:
> Quoting Venkata Lakshmi Narayana Gubba (2020-02-13 07:56:04)
>> This patch will fix the below issues
>> 1.Fixed race conditions while accessing memory dump state flags.
>
> What sort of race condition?
[Venkat]:
To avoid race condition between qca_hw_error() and
qca_controller_memdump() while accessing memory buffer, mutex is added.
In timeout scenario, qca_hw_error() frees memory dump buffers and
qca_controller_memdump() might still access same memory buffers.
We can avoid this situation by using mutex.
>
>> 2.Updated with actual context of timer in hci_memdump_timeout()
>
> What does this mean?
[Venkat]:
I will update commit text and post in next patch set.
>
>> 3.Updated injecting hardware error event if the dumps failed to
>> receive.
>> 4.Once timeout is triggered, stopping the memory dump collections.
>>
>> Possible scenarios while collecting memory dump:
>>
>> Scenario 1:
>>
>> Memdump event from firmware
>> Some number of memdump events with seq #
>> Hw error event
>> Reset
>>
>> Scenario 2:
>>
>> Memdump event from firmware
>> Some number of memdump events with seq #
>> Timeout schedules hw_error_event if hw error event is not received
>> already
>> hw_error_event clears the memdump activity
>> reset
>>
>> Scenario 3:
>>
>> hw_error_event sends memdump command to firmware and waits for
>> completion
>> Some number of memdump events with seq #
>> hw error event
>> reset
>>
>> Fixes: d841502c79e3 ("Bluetooth: hci_qca: Collect controller memory
>> dump during SSR")
>> Reported-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
>> Signed-off-by: Venkata Lakshmi Narayana Gubba
>> <gubbaven@codeaurora.org>
>> ---
> [...]
>> @@ -1449,6 +1465,23 @@ static void qca_hw_error(struct hci_dev *hdev,
>> u8 code)
>> bt_dev_info(hdev, "waiting for dump to complete");
>> qca_wait_for_dump_collection(hdev);
>> }
>> +
>> + if (qca->memdump_state != QCA_MEMDUMP_COLLECTED) {
>> + bt_dev_err(hu->hdev, "clearing allocated memory due to
>> memdump timeout");
>> + mutex_lock(&qca->hci_memdump_lock);
>
> Why is a mutex needed? Are crashes happening in parallel? It would be
> nice if the commit text mentioned why the mutex is added so that the
> reader doesn't have to figure it out.
>
[Venkat]:Explained in above answer.
>> + if (qca_memdump)
>> + memdump_buf = qca_memdump->memdump_buf_head;
Regards,
Lakshmi Narayana.
prev parent reply other threads:[~2020-02-14 11:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-13 15:56 [PATCH v3] Bluetooth: hci_qca: Bug fixes while collecting controller memory dump Venkata Lakshmi Narayana Gubba
2020-02-13 17:18 ` Abhishek Pandit-Subedi
2020-02-14 2:22 ` Stephen Boyd
2020-02-14 11:48 ` gubbaven [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d37ca6d9414720b2355d552fa8b68629@codeaurora.org \
--to=gubbaven@codeaurora.org \
--cc=bgodavar@codeaurora.org \
--cc=hemantg@codeaurora.org \
--cc=johan.hedberg@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=mka@chromium.org \
--cc=rjliao@codeaurora.org \
--cc=robh@kernel.org \
--cc=seanpaul@chromium.org \
--cc=swboyd@chromium.org \
--cc=tientzu@chromium.org \
--cc=yshavit@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).