Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752779AbdLKMAo (ORCPT ); Mon, 11 Dec 2017 07:00:44 -0500 Received: from resqmta-ch2-02v.sys.comcast.net ([69.252.207.34]:42126 "EHLO resqmta-ch2-02v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751281AbdLKMAm (ORCPT ); Mon, 11 Dec 2017 07:00:42 -0500 Date: Mon, 11 Dec 2017 06:00:40 -0600 (CST) From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Linus Torvalds cc: Geert Uytterhoeven , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , "Tobin C . Harding" , linux-mm , Linux Kernel Mailing List Subject: Re: [PATCH] mm/slab: Do not hash pointers when debugging slab In-Reply-To: Message-ID: References: <1512641861-5113-1-git-send-email-geert+renesas@glider.be> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CMAE-Envelope: MS4wfMBOqClOHP1gTRLeSXphALF2OQKjJtcwzAQeBpWF9f833CxY+9255aKqtYJXUx8s7D5RY5YwDJRNrJJZXF+IxU77hDGQ0o58YIIlyPWntJCb7xlPEIO0 dKiF98GZUDG0d/H1mddn7HOc3cIPOBXPamo4ScKpbA6V8j4vUEa0R4l0L+NQfqbA6pDYL0HYWIMd7leUaNVQB18pagGj1tud8ym9/O130ZwKJSKvwivzDpls yZVwyDsNE9p4LCXgGnY/KJqY1UI1vVYwe8WMazqDCeuO3G/lJ3xsav/K8gRnb4wzxBgaDPJk7tCDoUbvivJj5j8HY5N5ujsuhUHDKjpvv3OyW7nB5fHKP+6e Sij3l5Zkx9Kfj0cMvhudlb4rELbC/Vvv75YxCCuyWVAR2CCYuBeuP9XXObxgVU4CgAiTsn/4gIMJ5wywgU/zgG7Pxl4inA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1343 Lines: 33 On Sun, 10 Dec 2017, Linus Torvalds wrote: > On Thu, Dec 7, 2017 at 2:17 AM, Geert Uytterhoeven > wrote: > > > > if (cachep->flags & SLAB_STORE_USER) { > > - pr_err("Last user: [<%p>](%pSR)\n", > > + pr_err("Last user: [<%px>](%pSR)\n", > > *dbg_userword(cachep, objp), > > *dbg_userword(cachep, objp)); > > Is there actually any point to the %px at all? > > Why not remove it? the _real_ information is printed out by %pSR, and > that's both sufficient and useful in ways %px isn't. This pointer refers to code so we can remove it. > > > - pr_err("Slab corruption (%s): %s start=%p, len=%d\n", > > + pr_err("Slab corruption (%s): %s start=%px, len=%d\n", > > print_tainted(), cachep->name, > > realobj, size); > > and here, is the pointer actually interesting, or should we just give > the offset to the allocation? > > But if the pointer is interesting, then ack. The pointer here is to an slab object which could be important if one wants to find the pointer value in a hexdump of another object (f.e. listhead) or other pointer information that is being inspected in a debugging session.