[LU-18586] add llapi_find_param_alloc() function

• Type: Improvement
• Resolution: Unresolved
• Priority: Minor
• Affects Version/s: Lustre 2.16.0
• Labels: easy
• Severity: 3
• Assignee: WC Triage
• Reporter: Andreas Dilger

Description

The "find_param" structure is usually allocated on the stack in lfs.c functions, and passed into llapi_* functions. In most cases this is OK, but the llapi_* functions are also intended to be used by external tools, so it is possible that new fields are added to the end of struct find_param that are referenced internally, while the static on-stack allocation does not contain these fields.

This could result in out-of-bounds memory access if there is a significant difference between the Lustre version the tool was compiled against and the installed liblustreapi.so dynamic library.

It would be better to have an allocator function like llapi_find_param_alloc() and a matching llapi_find_param_free() that always allocates and initializes struct find_param in a consistent manner with the llapi functions in the running liblustreapi.so. The llapi_find_param_alloc() function should be used in all of the existing code and added to the llapi_* man pages where struct find_param is being used (i.e. llapi_ostlist(), llapi_migrate_mdt(), llapi_find(), llapi_getstripe() AFAICS) so that this provides a good template for new tools that are using these functions.

While the llapi_find_param_free() function is not strictly required to free struct find_param, there may be fields that have sub-allocations or references that should be cleaned up before the structure is freed.

It may also be useful to add a macro alias name llapi_find_param for find_param that makes the structure name more unique. This can be used in the man pages without breaking the API by changing the function argument type. It would possibly allow us to make such a change in the future.

Issue Links

• is related to: LU-17814 "lfs find" to scan with multiple threads