]> git.ipfire.org Git - thirdparty/git.git/commit - fsmonitor.c
fsmonitor: don't fill bitmap with entries to be removed
authorWilliam Baker <William.Baker@microsoft.com>
Fri, 11 Oct 2019 20:11:23 +0000 (13:11 -0700)
committerJunio C Hamano <gitster@pobox.com>
Sat, 12 Oct 2019 01:16:11 +0000 (10:16 +0900)
commit3444ec2eb2be58c285d2bf04f39e6e9ea5eda9a2
tree66e71b60020526c9f93d9e3050aae0a290394733
parent5fa0f5238b0cd46cfe7f6fa76c3f526ea98148d9
fsmonitor: don't fill bitmap with entries to be removed

While doing some testing with fsmonitor enabled I found
that git commands would segfault after staging and
unstaging an untracked file.  Looking at the crash it
appeared that fsmonitor_ewah_callback was attempting to
adjust bits beyond the bounds of the index cache.

Digging into how this could happen it became clear that
the fsmonitor extension must have been written with
more bits than there were entries in the index.  The
root cause ended up being that fill_fsmonitor_bitmap was
populating fsmonitor_dirty with bits for all entries in
the index, even those that had been marked for removal.

To solve this problem fill_fsmonitor_bitmap has been
updated to skip entries with the the CE_REMOVE flag set.
With this change the bits written for the fsmonitor
extension will be consistent with the index entries
written by do_write_index.  Additionally, BUG checks
have been added to detect if the number of bits in
fsmonitor_dirty should ever exceed the number of
entries in the index again.

Another option that was considered was moving the call
to fill_fsmonitor_bitmap closer to where the index is
written (and where the fsmonitor extension itself is
written).  However, that did not work as the
fsmonitor_dirty bitmap must be filled before the index
is split during writing.

Signed-off-by: William Baker <William.Baker@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fsmonitor.c
t/t7519-status-fsmonitor.sh
t/t7519/fsmonitor-env [new file with mode: 0755]