… >> Thus use another label. … >> --- >> net/sunrpc/auth_gss/gss_krb5_crypto.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) … > As has undoubtedly been pointed out in other forums, calling kfree() > with a NULL argument is perfectly valid. The function call “kfree(NULL)” is not really useful for error/exception handling while it is tolerated at various source code places. > Since this small GFP_KERNEL > allocation almost never fails, it's unlikely this change is going to > make any difference except for readability. I became curious if development interests can grow for the usage of an additional label. https://wiki.sei.cmu.edu/confluence/display/c/MEM12-C.+Consider+using+a+goto+chain+when+leaving+a+function+on+error+when+using+and+releasing+resources > Now if we want to clean up the error flows in here to look more > idiomatic, how about this: … > +++ b/net/sunrpc/auth_gss/gss_krb5_crypto.c … > @@ -970,8 +970,9 @@ u32 krb5_etm_checksum(struct crypto_sync_skcipher *cipher, > > out_free_ahash: > ahash_request_free(req); > -out_free_mem: > +out_free_iv: > kfree(iv); > +out_free_cksumdata: > kfree_sensitive(checksumdata); … I find it nice that you show another possible adjustment of corresponding identifiers. Regards, Markus
