Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 9 Aug 2023 13:10:57 +0900
From:   Sergey Senozhatsky <senozhatsky@chromium.org>
To:     "Leizhen (ThunderTown)" <thunder.leizhen@huaweicloud.com>
Cc:     Steven Rostedt <rostedt@goodmis.org>,
        Petr Mladek <pmladek@suse.com>,
        Sergey Senozhatsky <senozhatsky@chromium.org>,
        John Ogness <john.ogness@linutronix.de>,
        linux-kernel@vger.kernel.org, Zhen Lei <thunder.leizhen@huawei.com>
Subject: Re: [PATCH 2/2] hexdump: add a new dump prefix
 DUMP_PREFIX_ADDRESS_LOW16
Message-ID: <20230809041057.GB681074@google.com>
References: <20230805072116.1260-1-thunder.leizhen@huaweicloud.com>
 <20230805072116.1260-3-thunder.leizhen@huaweicloud.com>
 <20230807211409.750c17a5@gandalf.local.home>
 <73d10b7f-3cba-6897-0ff8-7759ef39a908@huaweicloud.com>
 <319df959-5be9-66c5-680f-4a5ae59019b9@huaweicloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <319df959-5be9-66c5-680f-4a5ae59019b9@huaweicloud.com>
Precedence: bulk

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'.