1. 23 Feb, 2022 1 commit
  2. 05 Jan, 2022 1 commit
  3. 08 Jul, 2021 1 commit
  4. 07 Jul, 2021 1 commit
  5. 20 Jan, 2021 1 commit
    • mwindow: Fix a bug in the LRU window finding code · 2f382ab7
      This change now updates the `lru_window` variable to match the current
      file's MRU window. This makes it such that it doesn't always choose the
      file that happened to come last in the list of window files, and instead
      should now correctly choose the file with the least-recently-used one.
      lhchavez committed
  6. 06 Dec, 2020 1 commit
  7. 29 Nov, 2020 1 commit
    • Make the pack and mwindow implementations data-race-free · 322c15ee
      This change fixes a packfile heap corruption that can happen when
      interacting with multiple packfiles concurrently across multiple
      threads. This is exacerbated by setting a lower mwindow open file limit.
      
      This change:
      
      * Renames most of the internal methods in pack.c to clearly indicate
        that they expect to be called with a certain lock held, making
        reasoning about the state of locks a bit easier.
      * Splits the `git_pack_file` lock in two: the one in `git_pack_file`
        only protects the `index_map`. The protection to `git_mwindow_file` is
        now in that struct.
      * Explicitly checks for freshness of the `git_pack_file` in
        `git_packfile_unpack_header`: this allows the mwindow implementation
        to close files whenever there is enough cache pressure, and
        `git_packfile_unpack_header` will reopen the packfile if needed.
      * After a call to `p_munmap()`, the `data` and `len` fields are poisoned
        with `NULL` to make use-after-frees more evident and crash rather than
        being open to the possibility of heap corruption.
      * Adds a test case to prevent this from regressing in the future.
      
      Fixes: #5591
      lhchavez committed
  8. 27 Nov, 2020 1 commit
  9. 11 Oct, 2020 2 commits
  10. 05 Aug, 2020 2 commits
  11. 12 Jul, 2020 1 commit
  12. 26 Jun, 2020 1 commit
    • Review feedback · eab2b044
      * Change the default of the file limit to 0 (unlimited).
      * Changed the heuristic to close files to be the file that contains the
        least-recently-used window such that the window is the
        most-recently-used in the file, and the file does not have in-use
        windows.
      * Parameterized the filelimit test to check for a limit of 1 and 100
        open windows.
      lhchavez committed
  13. 21 Jun, 2020 1 commit
    • mwindow: set limit on number of open files · 9679df57
      There are some cases in which repositories accrue a large number of
      packfiles. The existing mwindow limit applies only to the total size of
      mmap'd files, not on their number. This leads to a situation in which
      having lots of small packfiles could exhaust the allowed number of open
      files, particularly on macOS, where the default ulimit is very low
      (256).
      
      This change adds a new configuration parameter
      (GIT_OPT_SET_MWINDOW_FILE_LIMIT) that sets the maximum number of open
      packfiles, with a default of 128. This is low enough so that even macOS
      users should not hit it during normal use.
      
      Based on PR #5386, originally written by @josharian.
      
      Fixes: #2758
      lhchavez committed
  14. 25 Nov, 2019 1 commit
  15. 20 Jul, 2019 1 commit
  16. 15 Feb, 2019 4 commits
    • maps: provide return value when deleting entries · 84a089da
      Currently, the delete functions of maps do not provide a return value. Like
      this, it is impossible to tell whether the entry has really been deleted or not.
      Change the implementation to provide either a return value of zero if the entry
      has been successfully deleted or `GIT_ENOTFOUND` if the key could not be found.
      
      Convert callers to the `delete_at` functions to instead use this higher-level
      interface.
      Patrick Steinhardt committed
    • strmap: introduce high-level setter for key/value pairs · 03555830
      Currently, one would use the function `git_strmap_insert` to insert key/value
      pairs into a map. This function has historically been a macro, which is why its
      syntax is kind of weird: instead of returning an error code directly, it instead
      has to be passed a pointer to where the return value shall be stored. This does
      not match libgit2's common idiom of directly returning error codes.
      
      Introduce a new function `git_strmap_set`, which takes as parameters the map,
      key and value and directly returns an error code. Convert all callers of
      `git_strmap_insert` to make use of it.
      Patrick Steinhardt committed
    • strmap: introduce `git_strmap_get` and use it throughout the tree · ef507bc7
      The current way of looking up an entry from a map is tightly coupled with the
      map implementation, as one first has to look up the index of the key and then
      retrieve the associated value by using the index. As a caller, you usually do
      not care about any indices at all, though, so this is more complicated than
      really necessary. Furthermore, it invites for errors to happen if the correct
      error checking sequence is not being followed.
      
      Introduce a new high-level function `git_strmap_get` that takes a map and a key
      and returns a pointer to the associated value if such a key exists. Otherwise,
      a `NULL` pointer is returned. Adjust all callers that can trivially be
      converted.
      Patrick Steinhardt committed
    • maps: use uniform lifecycle management functions · 351eeff3
      Currently, the lifecycle functions for maps (allocation, deallocation, resize)
      are not named in a uniform way and do not have a uniform function signature.
      Rename the functions to fix that, and stick to libgit2's naming scheme of saying
      `git_foo_new`. This results in the following new interface for allocation:
      
      - `int git_<t>map_new(git_<t>map **out)` to allocate a new map, returning an
        error code if we ran out of memory
      
      - `void git_<t>map_free(git_<t>map *map)` to free a map
      
      - `void git_<t>map_clear(git<t>map *map)` to remove all entries from a map
      
      This commit also fixes all existing callers.
      Patrick Steinhardt committed
  17. 22 Jan, 2019 1 commit
  18. 28 Nov, 2018 1 commit
  19. 03 Jul, 2017 1 commit
    • Make sure to always include "common.h" first · 0c7f49dd
      Next to including several files, our "common.h" header also declares
      various macros which are then used throughout the project. As such, we
      have to make sure to always include this file first in all
      implementation files. Otherwise, we might encounter problems or even
      silent behavioural differences due to macros or defines not being
      defined as they should be. So in fact, our header and implementation
      files should make sure to always include "common.h" first.
      
      This commit does so by establishing a common include pattern. Header
      files inside of "src" will now always include "common.h" as its first
      other file, separated by a newline from all the other includes to make
      it stand out as special. There are two cases for the implementation
      files. If they do have a matching header file, they will always include
      this one first, leading to "common.h" being transitively included as
      first file. If they do not have a matching header file, they instead
      include "common.h" as first file themselves.
      
      This fixes the outlined problems and will become our standard practice
      for header and source files inside of the "src/" from now on.
      Patrick Steinhardt committed
  20. 17 Feb, 2017 2 commits
  21. 29 Dec, 2016 1 commit
  22. 04 Aug, 2016 1 commit
  23. 09 Mar, 2016 1 commit
  24. 15 Feb, 2015 1 commit
  25. 27 Oct, 2014 1 commit
  26. 25 Jun, 2014 2 commits
  27. 23 Jun, 2014 1 commit
    • Share packs across repository instances · b3b66c57
      Opening the same repository multiple times will currently open the same
      file multiple times, as well as map the same region of the file multiple
      times. This is not necessary, as the packfile data is immutable.
      
      Instead of opening and closing packfiles directly, introduce an
      indirection and allocate packfiles globally. This does mean locking on
      each packfile open, but we already use this lock for the global mwindow
      list so it doesn't introduce a new contention point.
      Carlos Martín Nieto committed
  28. 22 Apr, 2013 1 commit
    • Further threading fixes · 53607868
      This builds on the earlier thread safety work to make it so that
      setting the odb, index, refdb, or config for a repository is done
      in a threadsafe manner with minimized locking time.  This is done
      by adding a lock to the repository object and using it to guard
      the assignment of the above listed pointers.  The lock is only
      held to assign the pointer value.
      
      This also contains some minor fixes to the other work with pack
      files to reduce the time that locks are being held to and fix an
      apparently memory leak.
      Russell Belfer committed
  29. 17 Mar, 2013 1 commit
  30. 23 Jan, 2013 1 commit
  31. 08 Jan, 2013 1 commit
  32. 06 Jan, 2013 1 commit
    • git_mwindow_file_deregister() shouldn't return errors · f9b55bcb
      As a function that appears to only be called on error paths, I don't
      think it makes sense for it to return an error, or clobber the global
      giterr. Note that no existing callsites actually check the return
      code.
      
      In my own application, there are errors where the real error ends
      up being hidden, as git_mwindow_file_deregister() clobbers the
      global giterr. I'm not sure this error is even relevant?
      Scott J. Goldman committed
  33. 09 Dec, 2012 1 commit