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

["Daniel P. Smith" <dpsmith@apertussolutions.com>]

On 6/13/23 02:33, Jan Beulich wrote:
> 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@suse.com>
>>>
>>> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.cm>
> 
> Thanks.
> 

My pleasure.

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

I agree with that sentiment, but I would distinguish global state from a 
global variable. I would take the approach of,

static boot is_flask_enabled(void)
{
     /* 0 unchecked, 1 checked but disabled, 2 enabled */
     static int state = 0;

     if ( state == 0 )
	state = check_flask_state(); /* pseudo call for real logic */

     return (state < 2 ? false : true);
}

Then all the libxl_flask_* methods would is_flask_enabled(). This would 
not expose a global variable that could be manipulated by users of the 
library.


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

I understand your point, but if ENOSYS (Not Implemented) is not correct, 
what is the appropriate return value for this module does not support 
this op?

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

I am actually split on whether this should be an sub-op of xsm op or if 
this should be exposed via hyperfs. I did not consider a sysctl, though 
I guess an argument could be constructed for it.

v/r,
dps