From: Junio C Hamano <gitster@pobox.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: [PATCH] index: be careful when handling long names
Date: Sun, 13 Jan 2008 14:36:34 -0800 [thread overview]
Message-ID: <7vhchhpd3h.fsf_-_@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <7vsl11plbe.fsf@gitster.siamese.dyndns.org> (Junio C. Hamano's message of "Sun, 13 Jan 2008 11:39:01 -0800")
We currently use lower 12-bit (masked with CE_NAMEMASK) in the
ce_flags field to store the length of the name in cache_entry,
without checking the length parameter given to
create_ce_flags(). This can make us store incorrect length.
Currently we are mostly protected by the fact that many
codepaths first copy the path in a variable of size PATH_MAX,
which typically is 4096 that happens to match the limit, but
that feels like a bug waiting to happen. Besides, that would
not allow us to shorten the width of CE_NAMEMASK to use the bits
for new flags.
This redefines the meaning of the name length stored in the
cache_entry. A name that does not fit is represented by storing
CE_NAMEMASK in the field, and the actual length needs to be
computed by actually counting the bytes in the name[] field.
This way, only the unusually long paths need to suffer.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
> About the CE_NAMEMASK limitation (and currently we do not check
> it, so I think we would be screwed when a pathname that is
> longer than (CE_NAMEMASK+1) and still fits under PATH_MAX is
> given), I think we do not have to limit the maximum pathname
> length. Instead we can teach create_ce_flags() and ce_namelen()
> that a name longer than 2k (or 4k) has the NAMEMASK bits that
> are all 1 and ce->name[] must be counted if so (with an obvious
> optimization to start counting at byte position 2k or 4k in
> ce_namelen()).
This should fix it. Passes tests including the new test that
the existing code fails.
cache.h | 17 +++++++++++++++--
t/t0000-basic.sh | 18 ++++++++++++++++++
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index 39331c2..ad53acc 100644
--- a/cache.h
+++ b/cache.h
@@ -114,8 +114,21 @@ struct cache_entry {
#define CE_VALID (0x8000)
#define CE_STAGESHIFT 12
-#define create_ce_flags(len, stage) htons((len) | ((stage) << CE_STAGESHIFT))
-#define ce_namelen(ce) (CE_NAMEMASK & ntohs((ce)->ce_flags))
+static inline unsigned create_ce_flags(size_t len, unsigned stage)
+{
+ if (len >= CE_NAMEMASK)
+ len = CE_NAMEMASK;
+ return htons(len | (stage << CE_STAGESHIFT));
+}
+
+static inline size_t ce_namelen(const struct cache_entry *ce)
+{
+ size_t len = ntohs((ce)->ce_flags) & CE_NAMEMASK;
+ if (len < CE_NAMEMASK) /* likely */
+ return len;
+ return strlen(ce->name + CE_NAMEMASK) + CE_NAMEMASK;
+}
+
#define ce_size(ce) cache_entry_size(ce_namelen(ce))
#define ce_stage(ce) ((CE_STAGEMASK & ntohs((ce)->ce_flags)) >> CE_STAGESHIFT)
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index 4e49d59..40551a3 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -297,4 +297,22 @@ test_expect_success 'absolute path works as expected' '
test "$sym" = "$(test-absolute-path $dir2/syml)"
'
+test_expect_success 'very long name in the index handled sanely' '
+
+ a=a && # 1
+ a=$a$a$a$a$a$a$a$a$a$a$a$a$a$a$a$a && # 16
+ a=$a$a$a$a$a$a$a$a$a$a$a$a$a$a$a$a && # 256
+ a=$a$a$a$a$a$a$a$a$a$a$a$a$a$a$a$a && # 4096
+ a=${a}q
+
+ >path4 &&
+ git update-index --add path4 &&
+ (
+ git ls-files -s path4 |
+ sed -e "s/ .*/ /" |
+ tr -d "\012"
+ echo "$a"
+ ) | git update-index --index-info
+'
+
test_done
next prev parent reply other threads:[~2008-01-13 22:37 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-12 22:46 performance problem: "git commit filename" Linus Torvalds
2008-01-13 1:46 ` Linus Torvalds
2008-01-13 4:04 ` Linus Torvalds
2008-01-13 5:38 ` Daniel Barkalow
2008-01-13 8:14 ` Junio C Hamano
2008-01-13 16:57 ` Linus Torvalds
2008-01-13 19:31 ` Daniel Barkalow
2008-01-13 8:12 ` Junio C Hamano
2008-01-13 10:33 ` Junio C Hamano
2008-01-13 10:54 ` [PATCH] builtin-commit.c: do not lstat(2) partially committed paths twice Junio C Hamano
2008-01-13 11:09 ` performance problem: "git commit filename" Junio C Hamano
2008-01-13 17:24 ` Linus Torvalds
2008-01-13 19:39 ` Junio C Hamano
2008-01-13 22:36 ` Junio C Hamano [this message]
2008-01-13 22:53 ` [PATCH] index: be careful when handling long names Alex Riesen
2008-01-13 23:08 ` Junio C Hamano
2008-01-13 23:33 ` Alex Riesen
2008-01-14 21:03 ` Junio C Hamano
2008-01-14 1:00 ` performance problem: "git commit filename" Junio C Hamano
2008-01-14 17:07 ` Linus Torvalds
2008-01-14 18:38 ` Junio C Hamano
2008-01-14 19:39 ` Linus Torvalds
2008-01-14 20:08 ` Junio C Hamano
2008-01-14 21:00 ` Linus Torvalds
2008-01-15 0:18 ` Linus Torvalds
2008-01-15 1:13 ` Junio C Hamano
2008-01-13 10:38 ` [PATCH] builtin-commit.c: remove useless check added by faulty cut and paste Junio C Hamano
2008-01-14 21:23 ` しらいしななこ
2008-01-14 21:54 ` Junio C Hamano
2008-01-14 23:46 ` performance problem: "git commit filename" Kristian Høgsberg
2008-01-14 23:15 ` Kristian Høgsberg
2008-01-14 23:48 ` Junio C Hamano
2008-01-14 23:53 ` Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2008-01-19 3:25 Updated in-memory index cleanup Linus Torvalds
2008-01-19 7:42 ` [PATCH] index: be careful when handling long names Junio C Hamano
2008-07-20 0:51 Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vhchhpd3h.fsf_-_@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).