Re: [PATCH 2/5] libxl: drop dead assignments to "ret" from libxl__domain_config_setdefault()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.06.2023 22:21, Daniel P. Smith wrote:
> 
> 
> 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 <jbeulich@xxxxxxxx>
>>
>> Reviewed-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxx>

Thanks.

>>> ---
>>> 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?

I'm wary of global variables in shared libraries.

> 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.

Well, this is what results from abusing ENOSYS. The default case of a
switch() in a handler shouldn't return that value. Only if the entire
hypercall is outright unimplemented, returning ENOSYS is appropriate.
In fact I wonder whether dummy.h's xsm_do_xsm_op() is validly doing so,
when that function also serves as the fallback for XSM modules
choosing to not implement any of the op-s (like SILO does).

Since in the specific case here it looks like the intention really is
to carry out Flask-specific operations, a means to check for Flask
specifically might indeed be appropriate. If not a new sub-op of
xsm_op, a new sysctl might be another option.

Jan