Re: [PATCH] cgroup/rdma: fix strncmp prefix match in parse_resource()

崔涛
2026-04-17T06:43:57Z

在 2026/4/15 21:37, Michal Koutný 写道:
> Hello.
>
> On Tue, Apr 14, 2026 at 10:09:36AM +0800, cuitao <cuitao@kylinos.cn> wrote:
>> }
>> - if (strncmp(value, RDMACG_MAX_STR, len) == 0) {
>> + if (strcmp(value, RDMACG_MAX_STR) == 0) {
>
> Have you tested this? (When 'max' isn't the last assignment.)
Yes, I have tested this. Thank you for raising a valid concern about the parsing context. However, after investigation and testing, I believe strcmp is still the correct approach. Let me explain with test results from three kernel versions:

Test 1: Original code（mainline) — strncmp(value, RDMACG_MAX_STR, strlen(value))

echo "... hca_handle=ma hca_object=20" → accepted (BUG: "ma" matches "max")
echo "... hca_handle=maxaa hca_object=20" → rejected
echo "... hca_handle=max hca_object=20" → rejected

Test 2: strcmp(value, RDMACG_MAX_STR) — this commit

echo "... hca_handle=ma hca_object=20" → rejected
echo "... hca_handle=maxaa hca_object=20" → rejected
echo "... hca_handle=max hca_object=20" → rejected

Test 3: strncmp(value, RDMACG_MAX_STR, strlen(RDMACG_MAX_STR)) — your suggestion

echo "... hca_handle=ma hca_object=20" → rejected
echo "... hca_handle=maxaa hca_object=20" → accepted (BUG: "maxaa" matches "max")
echo "... hca_handle=max hca_object=20" → rejected

The suggested strncmp approach actually introduces a new bug: it would accept "maxaa" as "max" because it only compares the first strlen("max") = 3 characters.
>
> That value/c string is taken out of the whole line (see
> rdmacg_parse_limits), so it wouldn't be necessarily equal to
> RDMACG_MAX_STR. So bounded compare is still somewhat needed:
>
> if (strncmp(value, RDMACG_MAX_STR, strlen(RDMACG_MAX_STR)) == 0) {
>
Regarding the concern that value might not be exactly "max" when it's not the last assignment — the "max + extra spaces" test above demonstrates that rdmacg_parse_limits() uses strsep(&options, " ") to split the input by spaces, so by the time parse_resource() receives the value, it is already a clean NUL-terminated token. The extra spaces create empty sub-tokens that fail earlier in validation, regardless of which comparison method is used. So the value passed to the max-check is always either exactly "max", a number, or an invalid string — never "max" with trailing content from a subsequent assignment.

Therefore, an exact string match with strcmp is both correct and sufficient.

[ 383.716179] rdmacg: set_max: raw input='rocep1s0f0 hca_handle=max hca_object=20'
[ 383.716184] rdmacg: set_max: dev_name='rocep1s0f0', options='hca_handle=max hca_object=20'
[ 383.716185] rdmacg: parse_limits: token='hca_handle=max'
[ 383.716188] rdmacg: parse_resource: 'hca_handle'=max (ok)
[ 383.716189] rdmacg: parse_limits: token=''
[ 383.716189] rdmacg: parse_resource: missing name or value (input='')
[ 383.716198] rdmacg: parse_limits: failed on token '' (err=-22)
[ 383.716199] rdmacg: parse_limits: failed (err=-22)
[ 383.716200] rdmacg: set_max: parse_limits failed (err=-22)
[ 499.213562] rdmacg: set_max: raw input='rocep1s0f0 hca_handle=max hca_object=20'
[ 499.213566] rdmacg: set_max: dev_name='rocep1s0f0', options='hca_handle=max hca_object=20'
[ 499.213568] rdmacg: parse_limits: token='hca_handle=max'
[ 499.213570] rdmacg: parse_resource: 'hca_handle'=max (ok)
[ 499.213571] rdmacg: parse_limits: token='hca_object=20'
[ 499.213572] rdmacg: parse_resource: 'hca_object'=20 (ok)
[ 499.213574] rdmacg: parse_limits: all tokens parsed (ok)
[ 499.213575] rdmacg: set_max: device 'rocep1s0f0' limits updated (ok)

> Thanks,
> Michal
Thanks,
cuitao