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] [day] [month] [year] [list]
Message-ID: <8a0662b7-2801-47a2-9c91-4eb0e7ef307b@linaro.org>
Date: Fri, 25 Jul 2025 15:15:37 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
 linux-tip-commits@...r.kernel.org, Donghoon Yu <hoony.yu@...sung.com>,
 Youngmin Nam <youngmin.nam@...sung.com>, John Stultz <jstultz@...gle.com>,
 Will McVicker <willmcvicker@...gle.com>, x86@...nel.org,
 Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 Arnd Bergmann <arnd@...nel.org>
Subject: Re: [tip: timers/clocksource] clocksource/drivers/exynos_mct: Don't
 register as a sched_clock on arm64

On 25/07/2025 12:34, Ingo Molnar wrote:
> 
> * Daniel Lezcano <daniel.lezcano@...aro.org> wrote:

[ ... ]

>>> 3)
>>>
>>> There's also a stray Tested-by tag by one of the SOB entries:
>>>
>>>> Signed-off-by: Youngmin Nam <youngmin.nam@...sung.com>
>>>> Reviewed-by: Youngmin Nam <youngmin.nam@...sung.com>
>>>> Tested-by: Youngmin Nam <youngmin.nam@...sung.com>
>>>
>>> When someone passes along a patch, it's implicit that they not only
>>> have reviewed the patch, but have also tested it to a certain extent
>>
>> In this specific case where the original commit is from AOSP, this chain
>> seems to make sense. Souns like:
>>
>> "I was in the original commit delivery path"
>> "I reviewed this patch carried to Linux"
>> "I tested it on Linux"
> 
> Yeah, so then this should be documented by adding a comment to the tag
> itself:
> 
>      Signed-off-by: Donghoon Yu <hoony.yu@...sung.com>
>      Signed-off-by: Youngmin Nam <youngmin.nam@...sung.com>
>      Signed-off-by: Will McVicker <willmcvicker@...gle.com>
>      Signed-off-by: Daniel Lezcano <daniel.lezcano@...aro.org>
>      Tested-by: Youngmin Nam <youngmin.nam@...sung.com>   # AOSP -> Linux port
>      Reviewed-by: Youngmin Nam <youngmin.nam@...sung.com> # AOSP -> Linux port
> 
> Otherwise it's just confusing as to why there's duplicate SOB and
> Reviewed-by entries.

Yes, I agree it is more clear.

> But as long as the porting was basically just a cherry-pick, these
> extra tags are probably superfluous. If there was a conflict resolved
> by one of the maintainers along the SOB chain, that should be marked
> explicitly, which I see was already done in some cases:
> 
>      [ dlezcano : Fixed conflict with 20250614175556.922159-2-linux@...ck-us.net ]

Ok, noted for the next time.

>>> 4)
>>>
>>> Why is the 'Link' tag just in the middle of the SOB chain, instead at the end of it?
>>
>> I don't know. Link must be at the end  It is stated somewhere in the
>> documentation?
>>
>> I use git b4 -s <msg-id> and the tool adds the Link then my sign off.
> 
> Yeah, so using tools and not looking at the end result will often just
> create a random tag order that looks messy.
> 
> On preferred tag ordering, see:
> 
>    Documentation/process/maintainer-tip.rst
> 
>    Ordering of commit tags
>    ^^^^^^^^^^^^^^^^^^^^^^^
>    ...
> 
> 'Link' is at the end of the list of tags.
> 
> There's some logic to the -tip tag ordering (more important tags go
> before less important tags), but it's mostly just an arbitrary order
> that we try to stick to within -tip.

Thanks for the pointer !

>>> Presumably this is the proper SOB chain:
>>>
>>>> Author:        Donghoon Yu <hoony.yu@...sung.com>
>>>
>>>> Signed-off-by: Donghoon Yu <hoony.yu@...sung.com>
>>>> Signed-off-by: Youngmin Nam <youngmin.nam@...sung.com>
>>>> Signed-off-by: Will McVicker <willmcvicker@...gle.com>
>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano@...aro.org>
>>>> Acked-by: John Stultz <jstultz@...gle.com>
>>>> Link: https://lore.kernel.org/r/20250620181719.1399856-3-willmcvicker@google.com
>>>
>>> Correct?
>>
>>
> 
> So I got no answer for this question, but I suppose my assumption is
> correct - so I've rebased the tip:timers/clocksource commits to fix the
> misattribution and a number of other problems, and also fixed various
> typos, spelling mistakes and inconsistencies in the changelogs while at
> it. Let me know if I got something wrong.

If the rebase is possible, I suggest to take the opportunity to remove 
the following patches:

commit 5d86e479193b - clocksource/drivers/exynos_mct: Add module support
commit 7e477e9c4eb4 - clocksource/drivers/exynos_mct: Fix section 
mismatch from the module conversion

Because of:

[1] 
https://lore.kernel.org/all/20250725090349.87730-2-krzysztof.kozlowski@linaro.org/

[2] 
https://lore.kernel.org/all/bccb77b9-7cdc-4965-aa05-05836466f81f@app.fastmail.com/


> I've attached a delta-patch of the changelog changes below - note that
> I skipped the commit IDs to make the diff easier to read.

I have one question regarding the 'handler', when there is a message like:

[ handler: I did some changes ]

...

Signed-off-by: John Doe <handler@...nel.org>

Does the 'handler' have to match the email name ?

For example below, there is:

[ dlezcano : Fixed conflict with 
20250614175556.922159-2-linux@...ck-us.net ]

Signed-off-by: Daniel Lezcano <daniel.lezcano@...aro.org>


Is this form ok, or should it be:

[ daniel.lezcano: Fixed conflict with 
20250614175556.922159-2-linux@...ck-us.net ]

?

> ===================>
> ---	2025-07-25 12:15:26.024284067 +0200
> +++	2025-07-25 12:15:18.761435799 +0200
> @@ -10,6 +10,7 @@ Date:   Tue Jul 15 14:18:33 2025 +0200
>       the module loading.
>       
>       Fix this by adding the __init_or_module annotation for the functions:
> +

If my understanding of the documentation is correct, it seems to me the 
delta is ok. Until now, I was relying on the tool to put the different 
tags in the correct order, I thought it was in the arrival order.

Thanks for fixing this. Is there an existing script checking the tags 
order is correct regarding the tip criteria ?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ