[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230809041057.GB681074@google.com>
Date: Wed, 9 Aug 2023 13:10:57 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: "Leizhen (ThunderTown)" <thunder.leizhen@...weicloud.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
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 (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.
> 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'.
Powered by blists - more mailing lists