From: Erwan LE RAY <erwan.leray@foss.st.com>
To: dillon min <dillon.minfei@gmail.com>,
Greg KH <gregkh@linuxfoundation.org>
Cc: <linux-serial@vger.kernel.org>,
Alexandre TORGUE <alexandre.torgue@foss.st.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
<jirislaby@kernel.org>,
<linux-stm32@st-md-mailman.stormreply.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Fabrice Gasnier <fabrice.gasnier@foss.st.com>,
Valentin Caron <valentin.caron@foss.st.com>
Subject: Re: [Linux-stm32] [PATCH] serial: stm32: optimize spin lock usage
Date: Mon, 12 Apr 2021 15:19:27 +0200 [thread overview]
Message-ID: <f3985d70-4f00-7442-de4e-e382b19e3e50@foss.st.com> (raw)
In-Reply-To: <CAL9mu0+hi5eYEder1Mj2yjUN+eicJ9qG8Kr4GTC2mqfY405Jkg@mail.gmail.com>
Hi Dillon,
Thanks for your patch.
Could you please elaborate the use case in your commit message ?
Best Regards, Erwan.
On 4/12/21 10:54 AM, dillon min wrote:
> Hi Greg,
>
> On Mon, Apr 12, 2021 at 4:25 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>>
>> On Mon, Apr 12, 2021 at 02:50:20PM +0800, dillon min wrote:
>>> Hi Greg,
>>>
>>> Thanks for the quick response, please ignore the last private mail.
>>>
>>> On Mon, Apr 12, 2021 at 1:52 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>>>>
>>>> On Mon, Apr 12, 2021 at 12:34:21PM +0800, dillon.minfei@gmail.com wrote:
>>>>> From: dillon min <dillon.minfei@gmail.com>
>>>>>
>>>>> To avoid potential deadlock in spin_lock usage, change to use
>>>>> spin_lock_irqsave(), spin_unlock_irqrestore() in process(thread_fn) context.
>>>>> spin_lock(), spin_unlock() under handler context.
>>>>>
>>>>> remove unused local_irq_save/restore call.
>>>>>
>>>>> Signed-off-by: dillon min <dillon.minfei@gmail.com>
>>>>> ---
>>>>> Was verified on stm32f469-disco board. need more test on stm32mp platform.
>>>>>
>>>>> drivers/tty/serial/stm32-usart.c | 27 +++++++++++++++++----------
>>>>> 1 file changed, 17 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
>>>>> index b3675cf25a69..c4c859b34367 100644
>>>>> --- a/drivers/tty/serial/stm32-usart.c
>>>>> +++ b/drivers/tty/serial/stm32-usart.c
>>>>> @@ -214,7 +214,7 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
>>>>> struct tty_port *tport = &port->state->port;
>>>>> struct stm32_port *stm32_port = to_stm32_port(port);
>>>>> const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
>>>>> - unsigned long c;
>>>>> + unsigned long c, flags;
>>>>> u32 sr;
>>>>> char flag;
>>>>>
>>>>> @@ -276,9 +276,17 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
>>>>> uart_insert_char(port, sr, USART_SR_ORE, c, flag);
>>>>> }
>>>>>
>>>>> - spin_unlock(&port->lock);
>>>>> + if (threaded)
>>>>> + spin_unlock_irqrestore(&port->lock, flags);
>>>>> + else
>>>>> + spin_unlock(&port->lock);
>>>>
>>>> You shouldn't have to check for this, see the other patches on the list
>>>> recently that fixed this up to not be an issue for irq handlers.
>>> Can you help to give more hints, or the commit id of the patch which
>>> fixed this. thanks.
>>>
>>> I'm still confused with this.
>>>
>>> The stm32_usart_threaded_interrupt() is a kthread context, once
>>> port->lock holds by this function, another serial interrupts raised,
>>> such as USART_SR_TXE,stm32_usart_interrupt() can't get the lock,
>>> there will be a deadlock. isn't it?
>>>
>>> So, shouldn't I use spin_lock{_irqsave} according to the caller's context ?
>>
>> Please see 81e2073c175b ("genirq: Disable interrupts for force threaded
>> handlers") for when threaded irq handlers have irqs disabled, isn't that
>> the case you are trying to "protect" from here?
>>
>> Why is the "threaded" flag used at all? The driver should not care.
>>
>> Also see 9baedb7baeda ("serial: imx: drop workaround for forced irq
>> threading") in linux-next for an example of how this was fixed up in a
>> serial driver.
>>
>> does that help?
>>
> Yes, it's really helpful. and 81e2073c175b should be highlighted in a doc.
> In my past knowledge, we should care about hard irq & thread_fn lock conflict.
> This patch has totally avoided patching code in the separate driver side.
> thanks.
>
> I will just keep the changes in stm32_usart_console_write(), remove
> these code in
> thread_fn. update version 2 for you.
>
> thanks.
>
> Dillon,
>> thanks,
>>
>> greg k-h
> _______________________________________________
> Linux-stm32 mailing list
> Linux-stm32@st-md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
>
next prev parent reply other threads:[~2021-04-12 13:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-12 4:34 [PATCH] serial: stm32: optimize spin lock usage dillon.minfei
2021-04-12 5:52 ` Greg KH
2021-04-12 6:50 ` dillon min
2021-04-12 8:25 ` Greg KH
2021-04-12 8:54 ` dillon min
2021-04-12 13:19 ` Erwan LE RAY [this message]
2021-04-12 13:41 ` [Linux-stm32] " dillon min
2021-04-12 7:23 ` kernel test robot
2021-04-12 7:29 ` dillon min
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=f3985d70-4f00-7442-de4e-e382b19e3e50@foss.st.com \
--to=erwan.leray@foss.st.com \
--cc=alexandre.torgue@foss.st.com \
--cc=dillon.minfei@gmail.com \
--cc=fabrice.gasnier@foss.st.com \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=valentin.caron@foss.st.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).