From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jorge <griffin@gmx.es>, git@vger.kernel.org
Subject: Re: Bug: .gitconfig folder
Date: Thu, 28 May 2015 03:51:42 -0400 [thread overview]
Message-ID: <20150528075142.GB3688@peff.net> (raw)
In-Reply-To: <xmqq1ti1k5nv.fsf@gitster.dls.corp.google.com>
On Wed, May 27, 2015 at 03:38:12PM -0700, Junio C Hamano wrote:
> The patch was meant to be a tongue-in-cheek tangent that is a vast
> improvement for cases where we absolutely need to use mmap but does
> not help the OP at all ;-) I do not think there is any need for the
> config reader to read the existing file via mmap interface; just
> open it, strbuf_read() the whole thing (and complain when it cannot)
> and we should be ok.
>
> Or do we write back through the mmaped region or something?
No, I think we must never do that in our code because our compat mmap
implementation uses pread(). So all maps must be MAP_PRIVATE (and our
compat mmap barfs if it is not).
I started to go the strbuf_read() route, but it just felt so dirty to
change the way the code works only to try to get a better error message.
So here's my attempt at making it better while still using mmap. The end
result is:
$ mkdir foo
$ git config --file=foo some.key value
error: unable to mmap 'foo': Is a directory
Having looked through the code, I think the _ideal_ way to implement it
would actually be with read() and seek(). We read through the config
once (with the normal parser, which wraps stdio) and mark the offsets of
chunks we want to copy to the output. Then we mmap the original (under
lock, at least, so it shouldn't be racy) and output the existing chunks
and any new content in the appropriate order.
So ideally writing each chunk would just be seek() and copy_fd(). But
our offsets aren't quite perfect. In some cases we read backwards in our
mmap to find the right cutoff point. I'm sure this is fixable given
sufficient refactoring, but the config-writing code is such a tangled
mess that I don't want to spend the time or risk the regressions.
[1/4]: read-cache.c: drop PROT_WRITE from mmap of index
[2/4]: config.c: fix mmap leak when writing config
[3/4]: config.c: avoid xmmap error messages
[4/4]: config.c: rewrite ENODEV into EISDIR when mmap fails
-Peff
next prev parent reply other threads:[~2015-05-28 7:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-27 13:29 Bug: .gitconfig folder Jorge
2015-05-27 20:30 ` Junio C Hamano
2015-05-27 22:18 ` Jeff King
2015-05-27 22:24 ` Stefan Beller
2015-05-28 6:13 ` Jeff King
2015-05-27 22:38 ` Junio C Hamano
2015-05-28 7:51 ` Jeff King [this message]
2015-05-28 7:54 ` [PATCH 1/4] read-cache.c: drop PROT_WRITE from mmap of index Jeff King
2015-05-28 7:54 ` [PATCH 2/4] config.c: fix mmap leak when writing config Jeff King
2015-06-30 14:34 ` [PATCH] config.c: fix writing config files on Windows network shares Karsten Blees
2015-06-30 14:46 ` Torsten Bögershausen
2015-06-30 16:01 ` Jeff King
2015-06-30 14:52 ` Johannes Schindelin
2015-06-30 16:00 ` Jeff King
2015-05-28 7:56 ` [PATCH 3/4] config.c: avoid xmmap error messages Jeff King
2015-05-28 8:03 ` [PATCH 4/4] config.c: rewrite ENODEV into EISDIR when mmap fails Jeff King
2015-05-28 17:11 ` Junio C Hamano
2015-05-28 20:44 ` Jeff King
2015-05-28 21:11 ` Junio C Hamano
2015-05-28 17:06 ` Bug: .gitconfig folder 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=20150528075142.GB3688@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=griffin@gmx.es \
/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).