From: Al Viro > Sent: 19 December 2017 21:49 > > I suspect that an "offset and size within the kernel object" value > > might make sense. But what does the _pointer_ tell you? > > Well, for example seeing a 0xfffffffffffffff4 where a pointer to object > must have been is a pretty strong hint to start looking for a way for > that ERR_PTR(-ENOMEM) having ended up there... Something like > 0x6e69622f7273752f is almost certainly a misplaced "/usr/bin", i.e. a > pathname overwriting whatever it ends up in, etc. And yes, I have run > into both of those in real life. > > Debugging the situation when crap value has ended up in place of a > pointer is certainly a case where you do want to see what exactly has > ended up in there... I've certainly seen a lot of ascii in pointers (usually because the previous item has overrun). Although I suspect they'd appear in the fault frame - which hopefully carries real addresses. A compromise would be to hash the 'page' part of the address. On 64bit systems this is probably about 32 bits. It would still show whether pointers are user, kernel, vmalloc (etc) but without giving away the actual value. The page offset (12 bits) would show the alignment (etc). Including a per-boot random number would make it harder to generate 'rainbow tables' to reverse the hash. David -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href
