Comment # 20 on bug 1206359 from Jiri Slaby

(In reply to Vlastimil Babka from comment #16)
> At least old=0xffffffffffffffff looks quite wrong, but it should result in
> EINVAL rather than ENOMEM.
> In general 6.1 includes the maple tree, so that would be my first suspect to
> look

I have to go now, so for now, I came to a suspicion that this is memory
corruption. That 0xffffffffffffffff must be written by something else. So could
this mmap() kernel rewrite ended up in something like this in rpm:

1) slots = calloc(); (it's 16320B, so likely via sbrk(), I didn't check)
2) do a lot of mremap() and mmap(), some of them simply returns "slots" address
from 1) again.
3) slot[X].mapped gets rewritten by a mistake due to 2) by a bunch of 0xff.
4) we see slot->mapped as -1 here.

?