Re: [PATCH] Fix comparison of services of same preferred type

Hi Johannes,

On 8/1/25 6:02 AM, Johannes Emerich wrote:
> The service_compare_preferred() function is called twice in
> service_compare(), once with a guard to only use it on services with
> differing types, but once without any such guard. In the latter case,
> when comparing two services of the same preferred technology, it always
> returns -1 because it checks service_a first and exits immediately, when
> one would normally expect that comparison to result in a tie (return
> value 0).
> 
> This causes the parent service_compare() function to terminate its
> comparison early instead of applying appropriate tie-breakers like
> online status, Strength or Name. The result is an unstable sort order
> that depends on the initial order of services.
> 
> This patch adds a condition to service_compare_preferred() so that
> the preference logic is only applied to services of different types,
> without relying on calling contexts to make such checks.
> 
> I ran into this issue when reading sources to understand how ConnMan
> would sort two connected Ethernet services, when one is 'online' and one
> is 'ready' and 'ethernet' is in the preferred technologies list. It
> seems that their online state would in fact not matter at all, instead
> the service that happened to appear first in the list would win.
> 
> The issue may have been introduced in
> 31d9ce64a06743cc69b92c47a36e5ace0f9cb030, when
> service_compare_preferred() was extracted from its original context in
> which the comparison was only applied to services of unequal types.
> 
> Signed-off-by: Johannes Emerich <[email protected]>

No Signed-off-by tags used by ConnMan.

I went ahead and applied this with a slight tweak to commit header / description.

Regards,
-Denis