Re: [PATCH] soc: samsung: exynos-pmu: Fix for CONFIG_DEBUG_PREEMPT

[Krzysztof Kozlowski <krzk@kernel.org>]

On 09/09/2025 19:03, Will Deacon wrote:
> On Tue, Sep 09, 2025 at 05:43:16PM +0200, Krzysztof Kozlowski wrote:
>> On 09/09/2025 12:15, Will Deacon wrote:
>>> Krzysztof,
>>>
>>> On Sat, Sep 06, 2025 at 09:07:02AM +0200, Krzysztof Kozlowski wrote:
>>>> On 05/09/2025 19:43, Mostafa Saleh wrote:
>>>>>>>
>>>>>>> As this value is only read once, it doesn't require to be stable, so
>>>>>>
>>>>>> Why it does not need to be stable? Onlining wrong CPU number is not
>>>>>> desired...
>>>>>>
>>>>>>> just use "raw_smp_processor_id" instead.
>>>>>>
>>>>>> You might be just hiding some other real issue, because above stacktrace
>>>>>> is from gs101_cpuhp_pmu_online() which IRQs disabled and preemption
>>>>>> disabled. Provide analysis of the warning, instead of just making it
>>>>>> disappear.
>>>>>
>>>>> Not sure I understand, how is preemption disabled? that wouldn't fire
>>>>> in that case.
>>>>
>>>> Because there is explicit preempt_disable().
>>>
>>> Where do you see that?
>>
>> I did look at the code.
>>
>> All the calls I saw (including calltrace from commit msg) were under raw
>> spinlock and raw spinlock does:
>>
>> preempt_disable();
> 
> The backtrace doesn't contain a raw spinlock. As Peter subsequently

How backtrace could contain spinlock? Backtrace points you the calls and
clearly in these calls in the source code there is raw spinlock.

> pointed out, the reported issue has been fixed in linux-next and there's

Not in Linux next, but in maintainer tree. Who is going to apply the
patch? Maintainer. On what tree? Maintainer's tree.

> a raw spinlock there but since the report is from vanilla -rc4, it
> doesn't have that fix.

So that's the argument - instead of trying maintainer's tree or
linux-next, or even trying to put some effort and investigate why
maintainer claims that "gs101_cpuhp_pmu_online() which IRQs disabled and
preemption disabled." you just respond "there is no fix in rc release".

I gave the technical objection based on reading code.

Contributor instead of checking this or doing basic work - developing on
tree which has fixes, just bounced back. And you complain that I "could
try a bit harder to fill". Keep such comments to yourself.


Best regards,
Krzysztof