@@ -1809,7 +1809,9 @@ static int grep_source_1(struct grep_opt *opt, struct grep_source *gs, int colle
* is not thread-safe.
*/
grep_attr_lock();
+ grep_read_lock();
textconv = userdiff_get_textconv(opt->repo, gs->driver);
+ grep_read_unlock();
grep_attr_unlock();
}
@@ -2177,8 +2179,11 @@ void grep_source_load_driver(struct grep_source *gs,
return;
grep_attr_lock();
- if (gs->path)
+ if (gs->path) {
+ grep_read_lock();
gs->driver = userdiff_find_by_path(istate, gs->path);
+ grep_read_unlock();
+ }
if (!gs->driver)
gs->driver = userdiff_find_by_name("default");
grep_attr_unlock();
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 bellow: - 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> --- grep.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)