Re: [PATCH 4/3] ewah: adjust callers of ewah_read_mmap()

2018-06-15 Thread Jeff King
On Fri, Jun 15, 2018 at 02:23:44PM -0400, Derrick Stolee wrote: > If we are considering changing the reachability bitmap, then I'm very > intrigued. I think the number one thing to consider is to use the > multi-pack-index as a reference point (with a stable object order) so the > objects can be

Re: [PATCH 4/3] ewah: adjust callers of ewah_read_mmap()

2018-06-15 Thread Derrick Stolee
On 6/15/2018 1:31 PM, Jeff King wrote: On Fri, Jun 15, 2018 at 09:41:46AM -0700, Junio C Hamano wrote: Derrick Stolee writes: On 6/14/2018 11:44 PM, Jeff King wrote: The return value of ewah_read_mmap() is now an ssize_t, since we could (in theory) process up to 32GB of data. This would

Re: [PATCH 4/3] ewah: adjust callers of ewah_read_mmap()

2018-06-15 Thread Jeff King
On Fri, Jun 15, 2018 at 09:41:46AM -0700, Junio C Hamano wrote: > Derrick Stolee writes: > > > On 6/14/2018 11:44 PM, Jeff King wrote: > >> The return value of ewah_read_mmap() is now an ssize_t, > >> since we could (in theory) process up to 32GB of data. This > >> would never happen in

Re: [PATCH 4/3] ewah: adjust callers of ewah_read_mmap()

2018-06-15 Thread Junio C Hamano
Jeff King writes: > On Thu, Jun 14, 2018 at 11:28:50PM -0400, Jeff King wrote: > >> Yep. We also fail to check if we even have enough bytes to read the >> buffer_size in the first place. >> >> Here are some patches. The first one fixes the problem you found. The >> second one drops some dead

Re: [PATCH 4/3] ewah: adjust callers of ewah_read_mmap()

2018-06-15 Thread Junio C Hamano
Derrick Stolee writes: > On 6/14/2018 11:44 PM, Jeff King wrote: >> The return value of ewah_read_mmap() is now an ssize_t, >> since we could (in theory) process up to 32GB of data. This >> would never happen in practice, but a corrupt or malicious >> .bitmap or index file could convince us to

Re: [PATCH 4/3] ewah: adjust callers of ewah_read_mmap()

2018-06-15 Thread Derrick Stolee
On 6/14/2018 11:44 PM, Jeff King wrote: The return value of ewah_read_mmap() is now an ssize_t, since we could (in theory) process up to 32GB of data. This would never happen in practice, but a corrupt or malicious .bitmap or index file could convince us to do so. Aside: Why a 32GB limit?

[PATCH 4/3] ewah: adjust callers of ewah_read_mmap()

2018-06-14 Thread Jeff King
On Thu, Jun 14, 2018 at 11:28:50PM -0400, Jeff King wrote: > Yep. We also fail to check if we even have enough bytes to read the > buffer_size in the first place. > > Here are some patches. The first one fixes the problem you found. The > second one drops some dead code that has a related