Re: [PATCH v4 4/4] fanotify, audit: deliver fan_info as a hex-encoded string

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

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.