On Thu, 03 Oct 2019, Matthew Wilcox wrote:
On Thu, Oct 03, 2019 at 01:18:47PM -0700, Davidlohr Bueso wrote:
It has been discussed[1,2] that almost all users of interval trees would better
be served if the intervals were actually not [a,b], but instead [a, b). This
So how does a user represent a range from ULONG_MAX to ULONG_MAX now?
I would assume that any such lookups would be stab queries (anon/vma interval
tree). So both anon and files. And yeah, I blissfully ignored any overflow scenarios.
This should at least be documented.
I think the problem is that large parts of the kernel just don't consider
integer overflow. Because we write in C, it's natural to write:
for (i = start; i < end; i++)
and just assume that we never need to hit ULONG_MAX or UINT_MAX.
Similarly, I did not adjust queries such as 0 to ULONG_MAX, which are actually
real, then again any intersecting ranges will most likely not even be close to
end.
If we're storing addresses, that's generally true -- most architectures
don't allow addresses in the -PAGE_SIZE to ULONG_MAX range (or they'd
have trouble with PTR_ERR). If you're looking at file sizes, that's
not true on 32-bit machines, and we've definitely seen filesystem bugs
with files nudging up on 16TB (on 32 bit with 4k page size). Or block
driver bugs with similarly sized block devices.
So, yeah, easier to use. But damning corner cases.
I agree.
Thanks,
Davidlohr
