On Tue, Jan 16, 2018 at 12:37:51AM +0100, Kim Gybels wrote: > > This looks good to me, and since it's a recent-ish regression, I think > > we should take the minimal fix here. > > The minimal fix being a simple NULL check before munmap()? Sorry to be unclear. I just meant that your patch is probably fine as-is. I didn't want to hold up a regression fix with a bunch of nit-picking or possible future work, when we could build that on top later. > > 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. > > Maybe I should have left the optimization for small files out of the patch for > the zero length regression. After all, read() vs mmap() performance might > depend on other factors than just size. I'd be OK including it here, since there's prior art in the commit you referenced. Though of course actual numbers are always good when claiming an optimization. :) > > 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)? > > Indeed, all those patches are to avoid using the NULL pointers in ways that are > undefined. We could also copy index_core's way of handling the zero length > case: > ret = index_mem(sha1, "", size, type, path, flags); > > Point to some static memory instead of NULL, then all the pointer arithmetic is defined. Yep, that would work, too. I don't think the overhead of a once-per-process xmalloc(0) is a big deal, though, if it keeps the code simpler (though I admit it is not that complex either way). -Peff
