[PATCH 0/4] Fix a race condition when reading loose refs

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

 



This patch series is inspired by the first patch [1] in a series by
Peff and solves the race condition that he discovered plus a second,
similar race.  The general problem is that loose ref files are read in
two steps: lstat() followed by readlink() or open().  If another
process changes the file between our two steps, then the old code gets
confused and can give incorrect results.  The new code detects if an
error reported by readlink()/open() is inconsistent with the results
of the previous lstat(), and if so, tries anew.

The first three commits are just preparatory.  All four commits could
easily be squashed together if it is preferred (especially commits 2
through 4), but I did it this way to separate the
code-churning-but-trivial changes from the functional changes to make
review easier.

[1] http://article.gmane.org/gmane.comp.version-control.git/223525

Michael Haggerty (4):
  resolve_ref_unsafe(): extract function handle_missing_loose_ref()
  resolve_ref_unsafe(): handle the case of an SHA-1 within loop
  resolve_ref_unsafe(): nest reference-reading code in an infinite loop
  resolve_ref_unsafe(): close race condition reading loose refs

 refs.c | 187 ++++++++++++++++++++++++++++++++++++++++-------------------------
 1 file changed, 114 insertions(+), 73 deletions(-)

-- 
1.8.3

--
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]