[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d4f746ac-5a94-3d0f-a654-0001e1537717@huaweicloud.com>
Date: Fri, 11 Aug 2023 15:31:09 +0800
From: "Leizhen (ThunderTown)" <thunder.leizhen@...weicloud.com>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Petr Mladek <pmladek@...e.com>,
John Ogness <john.ogness@...utronix.de>,
linux-kernel@...r.kernel.org, Zhen Lei <thunder.leizhen@...wei.com>
Subject: Re: [PATCH 2/2] hexdump: add a new dump prefix
DUMP_PREFIX_ADDRESS_LOW16
On 2023/8/9 15:05, Leizhen (ThunderTown) wrote:
>
>
> 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.
I have a new idea. Replace DUMP_PREFIX_ADDRESS_LOW16 with DUMP_PREFIX_CUSTOM.
Let the user to specify the format string.
For example:
pr_info("dump memory at sp=%px:\n", sp);
print_hex_dump(KERN_INFO, "%s%16hx: %s\n", DUMP_PREFIX_CUSTOM, 16, 1, sp, 16, false);
print_hex_dump(KERN_INFO, "%s%16x: %s\n", DUMP_PREFIX_CUSTOM, 16, 1, sp, 16, false);
print_hex_dump(KERN_INFO, "%s%px: %s\n", DUMP_PREFIX_CUSTOM, 16, 1, sp, 16, false);
dump memory at sp=ffff80008091baa0:
baa0: c0 ba 91 80 00 80 ff ff d4 38 16 ce fc a7 ff ff
8091baa0: c0 ba 91 80 00 80 ff ff d4 38 16 ce fc a7 ff ff
ffff80008091baa0: c0 ba 91 80 00 80 ff ff d4 38 16 ce fc a7 ff ff
>
> 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
Powered by blists - more mailing lists