linux-kernel - Re: [PATCH] clocksource: timer-sp804: Fix read_current_timer() issue when clock source is not registered

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <BYAPR12MB32050A4AE88CB1F589E91505D5D42@BYAPR12MB3205.namprd12.prod.outlook.com>
Date: Sat, 8 Mar 2025 03:15:31 +0000
From: stephen eta zhou <stephen.eta.zhou@...look.com>
To: Daniel Lezcano <daniel.lezcano@...aro.org>, Krzysztof Kozlowski
	<krzk@...nel.org>
CC: "tglx@...utronix.de" <tglx@...utronix.de>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] clocksource: timer-sp804: Fix read_current_timer() issue
 when clock source is not registered

Hi Daniel

> Oh! Thanks for letting me know that, I appreciate

> I'll pay double attention to the patches.

I want to explain to you what Krzysztof said about my patch being generated by AI.

I have always had a worship spirit for Linux. I admit that I was a little biased towards AI in my previous email reply, because I was worried that some of my words would make kernel contributors feel unfriendly, so I asked AI to help me polish my answer, but I was indeed misled by AI during the polishing process. I admit that this was my previous fault.

But what I want to explain about this patch is that I really debugged it step by step using qemu. If necessary, I can provide complete and detailed debugging records.

I can first briefly explain how I found this problem. I was trying to optimize the memblock_add function, and I wanted to know how long it took to run. In the early kernel, I tried to get the tsc timestamp, but I found that all I got were 0, so I started to investigate step by step, and finally located that vexpress-v2p-ca9 used the sp804 driver and did not register the current_timer. I also submitted another patch for this problem, but there is no reply yet. In another patch, I added WARN to read_current_timer to quickly locate the problem, because I did debug for a while at that time. I am not sure if the patch I submitted is the best, but I want to explain that this is indeed the patch I debugged and submitted myself.

If you want to verify this problem, it is also very simple. Just use qemu to run vexpress_defconfig, this conf, and then use vexpress-v2p-ca9.dtb, and then breakpoint to the read_current_timer function in qemu+gdb, and you will find that it will return -ENXIO

For the previous situation, I apologize to the kernel maintainers, but please give me a chance, can you not list me as AI? .....

Thanks
Stephen
________________________________________
From: Daniel Lezcano <daniel.lezcano@...aro.org>
Sent: Friday, March 7, 2025 21:41
To: Krzysztof Kozlowski <krzk@...nel.org>; stephen eta zhou <stephen.eta.zhou@...look.com>
Cc: tglx@...utronix.de <tglx@...utronix.de>; linux-kernel@...r.kernel.org <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] clocksource: timer-sp804: Fix read_current_timer() issue when clock source is not registered

Hi Krzysztof,

On 07/03/2025 12:17, Krzysztof Kozlowski wrote:
> On 07/03/2025 09:10, Daniel Lezcano wrote:
>>
>> Hi Stephen,
>>
>> thanks for the proposed fix
>>
>> On 21/02/2025 04:46, stephen eta zhou wrote:
>>> Hi daniel
>>>
>>> While debugging on the vexpress-v2p-ca9 platform, I discovered that the read_current_timer API wasn't functioning correctly. The issue was that the SP804 driver lacked ARM32 support and did not register read_current_timer. To add ARM32 compatibility, I’ve submitted this patch. Without it, using SP804 as the timer on ARM32 causes issues with boot_init_stack_canary when inserting the canary value into the interrupt stack, and also affects entropy generation and collection, resulting in incorrect rdseed values.
>>
>> It is better to put that information in the changelog and provide a
>> fixed format of the patch description.
> Daniel,
>
> In case you actually consider applying this - some of the patches or
> their descriptions were generated by sort of AI tools, thus approach
> with caution.
>
> It was already pointed out that patches might be a garbage output of AI.
> Also they were not tested, even though what is claimed here "debugging
> on ...".

Oh! Thanks for letting me know that, I appreciate

I'll pay double attention to the patches.

Thanks

   -- Daniel

--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog