On 6/12/23 15:44, Daniel P. Smith wrote:
On 6/12/23 07:46, Jan Beulich wrote:
The variable needs to be properly set only on the error paths.
Coverity ID: 1532311
Fixes: ab4440112bec ("xl / libxl: push parsing of SSID and CPU pool ID
down to libxl")
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Daniel P. Smith <dpsm...@apertussolutions.cm>
---
If XSM is disabled, is it really useful to issue the 2nd and 3rd calls
if the 1st yielded ENOSYS?
Would you be okay with the calls staying if instead on the first
invocation of any libxl_flask_* method, flask status was checked and
stored in a variable that would then be checked by any subsequent calls
and immediately returned if flask was not enabled?
v/r,
dps
Looking closer I realized there is a slight flaw in the logic here. The
first call is accomplished via an xsm_op call and then assumes that
FLASK is the only XSM that has implemented the xsm hook, xsm_op, and
that the result will be an ENOSYS. If someone decides to implement an
xsm_op hook for any of the existing XSM modules or introduces a new XSM
module that has an xsm_op hook, the return likely would not be ENOSYS. I
have often debated if there should be a way to query which XSM module
was loaded for instances just like this. The question is what mechanism
would be best to do so.
v/r,
dps
