grep: fix race conditions on userdiff calls
authorMatheus Tavares <matheus.bernardino@usp.br>
Thu, 16 Jan 2020 02:39:49 +0000 (23:39 -0300)
committerJunio C Hamano <gitster@pobox.com>
Fri, 17 Jan 2020 21:52:14 +0000 (13:52 -0800)
commitc3a5bb31c1567edd1671b54726d4acbb10563a2c
tree24732665ef6a84d45481b374c5e3f34f45ce135b
parentd0654dc308b0ba76dd8ed7bbb33c8d8f7aacd783
grep: fix race conditions on userdiff calls

git-grep uses an internal grep_read_mutex to protect object reading
operations. Similarly, there's a grep_attr_mutex to protect calls to the
gitattributes machinery. However, two of the three functions protected
by the last mutex may also perform object reading, as seen below:

- userdiff_get_textconv() > notes_cache_init() >
  notes_cache_match_validity() > lookup_commit_reference_gently() >
  parse_object() > repo_has_object_file() >
  repo_has_object_file_with_flags() > oid_object_info_extended()

- userdiff_find_by_path() > git_check_attr() > collect_some_attrs() >
  prepare_attr_stack() > read_attr() > read_attr_from_index() >
  read_blob_data_from_index() > read_object_file()

As these calls are not protected by grep_read_mutex, there might be race
conditions with other threads performing object reading (e.g. threads
calling fill_textconv() at grep.c:fill_textconv_grep()). To prevent
that, let's make sure to acquire the lock before both of these calls.

Note: this patch might slow down the threaded grep in worktree, for the
sake of thread-safeness. However, in the following patches, we should
regain performance by replacing grep_read_mutex for an internal object
reading lock and allowing parallel inflation during object reading.

Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
grep.c