On Tuesday, June 16, 2020 11:43:31 AM EDT Lakshmi Ramasubramanian wrote: > On 6/16/20 8:29 AM, Steve Grubb wrote: > >>>>> The idea is a good idea, but you're assuming that "result" is always > >>>>> errno. That was probably true originally, but isn't now. For > >>>>> example, ima_appraise_measurement() calls xattr_verify(), which > >>>>> compares the security.ima hash with the calculated file hash. On > >>>>> failure, it returns the result of memcmp(). Each and every code path > >>>>> will need to be checked. > >>>> > >>>> Good catch Mimi. > >>>> > >>>> Instead of "errno" should we just use "result" and log the value given > >>>> in the result parameter? > >>> > >>> That would likely collide with another field of the same name which is > >>> the > >>> operation's results. If it really is errno, the name is fine. It's > >>> generic > >>> enough that it can be reused on other events if that mattered. > >> > >> Steve, what is the historical reason why we have both "res" and > >> "result" for indicating a boolean success/fail? I'm just curious how > >> we ended up this way, and who may still be using "result". > > > > I think its pam and some other user space things did this. But because of > > mixed machines in datacenters supporting multiple versions of OS, we have > > to leave result alone. It has to be 0,1 or success/fail. We cannot use > > it for errno. > > As Mimi had pointed out, since the value passed in result parameter is > not always an error code, "errno" is not an appropriate name. > > Can we add a new field, say, "op_result" to report the result of the > specified operation? Sure. But since it is errno sometimes, how would we know when to translate it? -Steve
