[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <63ab7b62-853c-4996-a493-465283252d5a@csgroup.eu>
Date: Tue, 5 Mar 2024 22:18:38 +0000
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Sean Anderson <sean.anderson@...ux.dev>, "David S . Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>
CC: Vladimir Oltean <vladimir.oltean@....com>, Roy Pledge
<roy.pledge@....com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "stable@...r.kernel.org"
<stable@...r.kernel.org>, Li Yang <leoyang.li@....com>, Scott Wood
<oss@...error.net>, Claudiu Manoil <claudiu.manoil@....com>, Camelia Groza
<camelia.groza@....com>, Steffen Trumtrar <s.trumtrar@...gutronix.de>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RESEND2 PATCH net v4 2/2] soc: fsl: qbman: Use raw spinlock for
cgr_lock
Le 05/03/2024 à 19:14, Sean Anderson a écrit :
> [Vous ne recevez pas souvent de courriers de sean.anderson@...ux.dev. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi,
>
> On 2/23/24 11:02, Sean Anderson wrote:
>> On 2/23/24 00:38, Christophe Leroy wrote:
>>> Le 22/02/2024 à 18:07, Sean Anderson a écrit :
>>>> [Vous ne recevez pas souvent de courriers de sean.anderson@...ux.dev. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
>>>>
>>>> cgr_lock may be locked with interrupts already disabled by
>>>> smp_call_function_single. As such, we must use a raw spinlock to avoid
>>>> problems on PREEMPT_RT kernels. Although this bug has existed for a
>>>> while, it was not apparent until commit ef2a8d5478b9 ("net: dpaa: Adjust
>>>> queue depth on rate change") which invokes smp_call_function_single via
>>>> qman_update_cgr_safe every time a link goes up or down.
>>>
>>> Why a raw spinlock to avoid problems on PREEMPT_RT, can you elaborate ?
>>
>> smp_call_function always runs its callback in hard IRQ context, even on
>> PREEMPT_RT, where spinlocks can sleep. So we need to use raw spinlocks
>> to ensure we aren't waiting on a sleeping task. See the first bug report
>> for more discussion.
>>
>> In the longer term it would be better to switch to some other
>> abstraction.
>
> Does this make sense to you?
Yes that fine, thanks for the clarification. Maybe you can explain that
in the patch description in case you send a v5.
Christophe
Powered by blists - more mailing lists