| # In attr_file_free, the locks are acquired in the opposite order in which they |
| # are normally acquired. This is probably something worth fixing to have a |
| # consistent lock hierarchy that is easy to understand. |
| deadlock:attr_cache_lock |
| |
| # git_mwindow_file_register has the possibility of evicting some files from the |
| # global cache. In order to avoid races and closing files that are currently |
| # being accessed, before evicting any file it will attempt to acquire that |
| # file's lock. Finally, git_mwindow_file_register is typically called with a |
| # file lock held, because the caller will use the fd in the mwf immediately |
| # after registering it. This causes ThreadSanitizer to observe different orders |
| # of acquisition of the mutex (which implies a possibility of a deadlock), |
| # _but_ since the files are added to the cache after other files have been |
| # evicted, there cannot be a case where mwf A is trying to be registered while |
| # evicting mwf B concurrently and viceversa: at most one of them can be present |
| # in the cache. |
| deadlock:git_mwindow_file_register |
| |
| # When invoking the time/timezone functions from git_signature_now(), they |
| # access libc methods that need to be instrumented to correctly analyze the |
| # data races. |
| called_from_lib:libc.so.6 |
| |
| # TODO(#5592): Investigate and fix this. It can be triggered by the `thread` |
| # test suite. |
| race:git_filter_list__load_ext |
