Messages in this thread | | | Subject | Re: [PATCH 2/2] hexdump: add a new dump prefix DUMP_PREFIX_ADDRESS_LOW16 | From | "Leizhen (ThunderTown)" <> | Date | Wed, 9 Aug 2023 15:05:07 +0800 |
| |
On 2023/8/9 12:10, Sergey Senozhatsky wrote: > On (23/08/08 15:52), Leizhen (ThunderTown) wrote: >>>> I find the "before" much easier to read than the "after". >> >> I added the boot option no_hash_pointers, so "before" can print the >> address. Otherwise, just print the 32-bit hash value, as shown below: > > >> [ 14.872153] dump memory at sp=ffff800080903aa0: > > This line is not guaranteed to be printed. If you get > "** N printk messages dropped **" instead then the > ADDRESS_LOW16 math doesn't work.
Anyone is vulnerable in the face of nature. Even DUMP_PREFIX_ADDRESS, without the preface, no one know what's dumped. In any case, DUMP_PREFIX_ADDRESS_LOW16 has its own unique value in this ecosystem. The only regret is that it has a slightly longer name than others. Maybe it could be DUMP_PREFIX_ADDRLOW or something.
By the way, would you consider changing %p to %px in case DUMP_PREFIX_ADDRESS?
> >> Actually, I added DUMP_PREFIX_ADDRESS_LOW16 because of another scene: >> slab kmalloc-512 start ffff3b3c0094e800 pointer offset 168 size 512 >> e888: 00400000 00000000 000f7704 00000000 >> e898: 000f7704 00000000 12345678 00000000 >> e8a8: 00000000 00000000 00000000 00000000 >> e8b8: 9abcdef0 00000000 00507dd0 00000000 >> >> Here, the start address ffff3b3c0094e800 of slab object is printed by %px, >> the address of the error data is at p=ffff3b3c0094e8a8 = ffff3b3c0094e800 + offset 168. >> To locate the problem, dump up to 64 bytes centered on 'p'. > . >
-- Regards, Zhen Lei
| |