Details
-
Bug
-
Resolution: Unresolved
-
Minor
-
Lustre 2.17.0
-
None
-
3
-
9223372036854775807
Description
Ever since https://review.whamcloud.com/c/fs/lustre-release/+/55019 patch, the qmt_uuid2idx() function is now defined as returning an enum and the stype variable it's typically assigned to is also the same enum.
The problem is all the code that left that then checks the stype for being less than zero as some sort of an error indication that could never hit anymore even though the function does have a comment that it returns -EINVAL for wrong uuid and it does indeed attempt a negative return:
* \retval -EINVAL wrong uuid */ enum qmt_stype qmt_uuid2idx(struct obd_uuid *uuid, int *idx) { char *uuid_str, *name, *dash; int rc = -EINVAL; uuid_str = (char *)uuid->uuid; if (strnlen(uuid_str, UUID_MAX) >= UUID_MAX) { CERROR("quota: UUID '%.*s' missing trailing NUL: rc = %d\n", UUID_MAX, uuid_str, rc); return rc; }
Obviously this is not a great idea and we need to do something about it.
There are 6 spots tha check for stype < 0 today:
qmt_dqacq, qmt_intent_policy, qmt_lvbo_update, qmt_lvbo_fill, qmt_slv_add, qmt_pool_new_conn
Attachments
Issue Links
- is related to
-
LU-17356 qmt_sarr_get_idx()) ASSERTION( arr_idx < qpi->qpi_sarr.osts.op_count && arr_idx >= 0 ) failed: idx invalid 0 op_count 0
-
- Resolved
-