Re: [PATCH v1 1/5] libperf cpumap: Correct reference count for perf_cpu_map__merge()

[Leo Yan <leo.yan@arm.com>]

Hi Adrian,

On 10/10/24 18:41, Adrian Hunter wrote:>
> On 25/09/24 22:53, Leo Yan wrote:
>> The perf_cpu_map__merge() function has two arguments, 'orig' and 'other',
>> and it returns results for three different cases:
>>
>>    Case 1: 'other' is a subset of 'orig'.
>>    Case 2: 'orig' is a subset of 'other'.
>>    Case 3: 'orig' and 'other' are not subsets of each other.
>>
>> The result combinations are:
>>
>>    +--------+-------------+-----------+-----------+
>>    | Cases  | Result      | orig      | other     |
>>    +--------+-------------+-----------+-----------+
>>    | Case1  | orig        | No change | No change |
>>    +--------+-------------+-----------+-----------+
>>    | Case2  | other       | No change | refcnt++  |
>>    +--------+-------------+-----------+-----------+
>>    | Case3  | New CPU map | refcnt--  | No change |
>>    +--------+-------------+-----------+-----------+
>>
>> Both Case 1 and Case 3 have a risk of releasing maps unexpectedly. This
>> is because the reference counter operations are not consistent crossing
>> different cases and leads to difficulty for callers handling them.
>>
>> For Case 1, because 'other' is a subset of 'orig', 'orig' is returned as
>> the merging result, but its refcnt is not incremented. This can lead to
>> the map being released repeatedly:
>>
>>    struct perf_cpu_map *a = perf_cpu_map__new("1,2");
>>    struct perf_cpu_map *b = perf_cpu_map__new("2");
>>
>>    /* 'm' and 'a' point to the same CPU map */
>>    struct perf_cpu_map *m = perf_cpu_map__merge(a, b);
>>
>>    ...
>>
>>    perf_cpu_map__put(m); -> Release the map
>>    perf_cpu_map__put(b);
>>    perf_cpu_map__put(a); -> Release the same merged again
>>
>> For Case 3, it is possible that the CPU map pointed to by 'orig' can be
>> released twice: within the function and outside of it.
>>
>>    struct perf_cpu_map *a = perf_cpu_map__new("1,2");
>>    struct perf_cpu_map *b = perf_cpu_map__new("3");
>>
>>    struct perf_cpu_map *m = perf_cpu_map__merge(a, b);
>>                               `> 'm' is new allocated map. But 'a' has
>>                                been released in the function.
>>    ...
>>
>>    perf_cpu_map__put(m);
>>    perf_cpu_map__put(b);
>>    perf_cpu_map__put(a); -> Release the 'a' map again
>>
>> This commit increases the reference counter if a passed map is returned.
>> For the case of a newly allocated map, it does not change the reference
>> counter for passed maps.
> 
> The 2 non-test uses of perf_cpu_map__merge both do:
> 
>          a = perf_cpu_map__merge(a, b);
> 
> so another way to make the API less misleading would be
> to introduce:
> 
>          err = perf_cpu_map__merge_in(&a, b);
> 
> where:
> 
> int perf_cpu_map__merge_in(struct perf_cpu_map **orig, struct perf_cpu_map *other)
> {
>          struct perf_cpu_map *result = perf_cpu_map__merge(*orig, other);
> 
>          if (!result)
>                  return -ENOMEM;
> 
>          *orig = result;
>          return 0;
> }
> 
> without any changes to perf_cpu_map__merge().

Just wandering why we cannot do the same thing for the perf_cpu_map__merge() 
function?

   int perf_cpu_map__merge_in(struct perf_cpu_map **orig,
                              struct perf_cpu_map *other)

This can allow us to avoid any confusion in the first place. And we don't need 
to maintain two functions for the same thing.

Thanks,
Leo