Hello Richard, On Wednesday, August 10, 2022 10:23:49 PM EDT Richard Guy Briggs wrote: > > I compiled a new kernel and run old user space on this. The above event > > is > > exactly what I see in my audit logs. Why the fan_info=3F? I really would > > have expected 0. What if the actual rule number was 63? I think this > > will work better to leave everything 0 with old user space. > > Well, if it is to be consistently hex encoded, that corresponds to "?" I suppose this OK. > if it is to be interpreted as a string. Since the fan_type is 0, > fan_info would be invalid, so a value of 0 would be entirely reasonable, > hex encoded to fan_info=00. It could also be hex encoded to the string > "(none)". If you wanted "0" for fan_type=FAN_RESPONSE_INFO_AUDIT_RULE, > that would be fan_info=30 if it were interpreted as a string, or > arguably 3F for an integer of rule (decimal) 63. Ultimately, fan_type > should determine how fan_info's hex encoded value should be interpreted. > > But ultimately, the point of this patch is to hex encode the fan_info > field value. Just one last update, I have been able to test the patches with the user space application and it appears to be working from the PoV of what is sent is what's in the audit logs. I'm not sure how picky old kernels are wrt the size of what's sent. But an unpatched 5.19 kernel seems to accept the larger size response and do the right thing. -Steve
