On Sat, Jan 13, 2018 at 05:11:49PM +0100, Kim Gybels wrote:
> Take a hint from commit ea68b0ce9f8ce8da3e360aed3cbd6720159ffbee and use
> read() instead of mmap() for small packed-refs files.
>
> This also fixes the problem[1] where xmmap() returns NULL for zero
> length[2], for which munmap() later fails.
>
> Alternatively, we could simply check for NULL before munmap(), or
> introduce an xmunmap() that could be used together with xmmap().
This looks good to me, and since it's a recent-ish regression, I think
we should take the minimal fix here.
But it does make me wonder whether xmmap() ought to be doing this "small
mmap" optimization for us. Obviously that only works when we do
MAP_PRIVATE and never write to the result. But that's how we always use
it anyway, and we're restricted to that to work with the NO_MMAP wrapper
in compat/mmap.c.
> @@ -489,21 +491,21 @@ static int load_contents(struct snapshot *snapshot)
> die_errno("couldn't stat %s", snapshot->refs->path);
> size = xsize_t(st.st_size);
>
> - switch (mmap_strategy) {
> - case MMAP_NONE:
> + if (!size) {
> + snapshot->buf = NULL;
> + snapshot->eof = NULL;
> + snapshot->mmapped = 0;
> + } else if (size <= SMALL_FILE_SIZE || mmap_strategy == MMAP_NONE) {
> snapshot->buf = xmalloc(size);
> bytes_read = read_in_full(fd, snapshot->buf, size);
> if (bytes_read < 0 || bytes_read != size)
> die_errno("couldn't read %s", snapshot->refs->path);
> snapshot->eof = snapshot->buf + size;
> snapshot->mmapped = 0;
If the "!size" case is just lumped in with "size <= SMALL_FILE_SIZE",
then we'd try to xmalloc(0), which is guaranteed to work (we fallback to
a 1-byte allocation if necessary). Would that make things simpler and
more consistent for the rest of the code to always have snapshot->buf be
a valid pointer (just based on seeing Michael's follow-up patches)?
-Peff
