Re: [PATCH 3/4] lock_ref_sha1_basic: simplify error code path

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King wrote:

> For most errors, we jump to a goto label that unlocks the
> ref and returns NULL. However, in none of these error paths
> would we ever have actually locked the ref. By the time we
> actually take the lock, we follow a different path that does
> not ever hit this goto (we rely on verify_lock to unlock if
> it finds an error).
[...]
>  refs.c | 12 ++++--------
>  1 file changed, 4 insertions(+), 8 deletions(-)

Wouldn't this leak lock (in all cases) and lock->ref_name and
lock->orig_ref_name (on safe_create_leading_directories failure)?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]