Re: [PATCH] sparse-index: pass string length to index_file_exists()
- From
- Jeff Hostetler <git@jeffhostetler.com>
- Date
- Feb 2, 2024, 19:19 UTC
- Message-ID
- <2bae709a-18da-6ab8-2b76-032ddc045641@jeffhostetler.com>
- In-Reply-To
- <xmqqo7cysp01.fsf@gitster.g>
On 2/2/24 1:24 PM, Junio C Hamano wrote:
Show 35 quoted lines
> "Jeff Hostetler via GitGitGadget" <gitgitgadget@gmail.com> writes: > >> From: Jeff Hostetler <jeffhostetler@github.com> >> >> The call to index_file_exists() in the loop in expand_to_path() passes >> the wrong string length. Let's fix that. >> >> The loop in expand_to_path() searches the name-hash for each >> sub-directory prefix in the provided pathname. That is, by searching >> for "dir1/" then "dir1/dir2/" then "dir1/dir2/dir3/" and so on until >> it finds a cache-entry representing a sparse directory. >> >> The code creates "strbuf path_mutable" to contain the working pathname >> and modifies the buffer in-place by temporarily replacing the character >> following each successive "/" with NUL for the duration of the call to >> index_file_exists(). >> >> It does not update the strbuf.len during this substitution. > > Meaning we memihash() the full pathname munged with '/' -> NUL through > to the end of the original, when we should memihash() the truncated > leading pathname. This is bad, and the ... > >> >> Pass the patched length of the prefix path instead. > > ... fix looks quite straight-forward. > >> Signed-off-by: Jeff Hostetler <jeffhostetler@github.com> >> --- > > The problem description and the fix makes sense, but did you > actually see an end-user visible breakage due to this bug? I am > wondering how you found it, and if it is reasonable to have a test > demonstrate the breakage.
I'm working on a bug where the fsmonitor client doesn't invalidate the CE flags when there is a case discrepancy between the expected and observed case on a case-insensitive file system. (Fix due shortly.)
And I was single-stepping in the debugger inside of `index_file_exists()` while tracking that down and noticed that the length argument was bogus. Something like { name="dir1/", len=10 }
I don't remember if this bug caused visible problems or not. It felt like it caused a few extra rounds of mutually-recursive calls between `index_file_exists()` and `expand_to_path()`, but I can't say that for certain (and I was focused on a different problem at the time).
I do have some test code in `t/helper/lazy-init-name-hash.c` that I suppose we could extend to beat on it, but I'm not sure it is worth it in this case.
Jeff
Show 38 quoted lines
>
>> sparse-index.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/sparse-index.c b/sparse-index.c
>> index 1fdb07a9e69..093708f6220 100644
>> --- a/sparse-index.c
>> +++ b/sparse-index.c
>> @@ -579,8 +579,9 @@ void expand_to_path(struct index_state *istate,
>> replace++;
>> temp = *replace;
>> *replace = '\0';
>> + substr_len = replace - path_mutable.buf;
>> if (index_file_exists(istate, path_mutable.buf,
>> - path_mutable.len, icase)) {
>> + substr_len, icase)) {
>
> There is a break out of this loop when the condition for this "if"
> statement holds, but the value of substr_len does not affect what
> happens after this index_file_exists() call (correctly) computes its
> result. The fix looks good.
>
> Thanks.
>
>> /*
>> * We found a parent directory in the name-hash
>> * hashtable, because only sparse directory entries
>> @@ -593,7 +594,6 @@ void expand_to_path(struct index_state *istate,
>> }
>>
>> *replace = temp;
>> - substr_len = replace - path_mutable.buf;
>> }
>>
>> cleanup:
>>
>> base-commit: 43c8a30d150ecede9709c1f2527c8fba92c65f40
>