Received: by 10.223.176.5 with SMTP id f5csp3023561wra; Mon, 5 Feb 2018 14:24:13 -0800 (PST) X-Google-Smtp-Source: AH8x227ug9t8m0vrIpzyWfEhuVlXHqM5k62N+ciGU+VFUIGggfHbQmsJRyxO6BR5MULcbsLB2i07 X-Received: by 2002:a17:902:7148:: with SMTP id u8-v6mr277824plm.91.1517869453072; Mon, 05 Feb 2018 14:24:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517869453; cv=none; d=google.com; s=arc-20160816; b=nl/zfwq0YPG0HbD7hIlK178E4OzoZIi7x/3ZNflgNAI3j9ws9d9+6AfFsI2bmbqS1H 6mfv4iu3xgg0QlkNpkpIIq0kO2cit59uiPGDrzPmhCxkMFIj5/uJq7G+/+94edI/Tq7L AtdTjs4z2khf4AfsvcJSLOzX9l/cHGN6g/3quUsrUrbkU0tY78Yn6SXH9TXTtaOXKpvw 6YgVJ5AS4wVDfwSHUqrLkhR1a3fuzPuERtuszFnER81ruBGMNUsmla3f658VQDPYlqJn cqVXsBlCVLYiaGJkmDdCoGCRcRLduN9dUddyse/S4FUgVMx4/6cIZn+DVqyFAb2p1ZPk FjnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:dkim-signature :arc-authentication-results; bh=0OlLhE/xtjqTqd2WlHib7OIKON/U6CnoYOCWoIbDH5s=; b=1HtiuVaMFfT7fUKTQSHn4e1q6qgSHrCFk2ZEcRx2i+n/jWyXWkd69/zoXCsn6Q2oEb GBvq0AjbawB3cECIDsWZ73ZG8fA9+PvXQ3ZAisDRqbZtaHbLyouGzO+pg6FwQtjQ4kda boHWfZdZUIPDhuFOeInXgZr6QXuRdGC9d9WJVZfcmREY3fWZILIpyVnxDgcDhqarVzvf 8j13A9rR0IBkra3j2dPTxNC/VQRmdSyiBctY20vB0AtJf+1p2QZtXuICskeNw4FDuSr8 KaMUkrh/hb8FWt5fSy96SrxK2ASsQSyCBykThzGAXOJL3K6zGOOka6TZKdNpwPpW2T+6 0FGQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@tobin.cc header.s=fm2 header.b=D9QnUX0e; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=CDRKxUfR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s22-v6si533108plk.550.2018.02.05.14.23.59; Mon, 05 Feb 2018 14:24:13 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@tobin.cc header.s=fm2 header.b=D9QnUX0e; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=CDRKxUfR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752125AbeBEWXG (ORCPT + 99 others); Mon, 5 Feb 2018 17:23:06 -0500 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:60655 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752074AbeBEWW6 (ORCPT ); Mon, 5 Feb 2018 17:22:58 -0500 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id BEF56209E9; Mon, 5 Feb 2018 17:22:57 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Mon, 05 Feb 2018 17:22:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tobin.cc; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=0OlLhE/xtjqTqd2WlHib7OIKON/U6CnoYOCWoIbDH5s=; b=D9QnUX0e c6tPGg0Ob3p4QjMboSgZwruwQKY9qN2Alx3q6uk6XSxfA5dFgSeA0lYAV3BdOaVe YNJKoTawEvZDiotbFHcSHltbYYCy5MwF/Klq0ldeOvz7jXolMyrn00EzJFxFOL6W 2OWPziFF4jwnKLoWeVlJRY5WWSFt1EFWvolZAijsMdj5PcCMtqMLjzFS8ab8tufa x5LW1LEEnNb2jAEJtaCUAQ1e3EFVYU65/z7ETKVkKAeqyG2e7fsENfitLGO2xDSB ccLgx4+/JlRLnLeRNhPymKXQXqSsn/JPxnbBVK48d9g4ehva1I1eDpgTajBohGdX pi4f9m0xDbe2UA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=0OlLhE/xtjqTqd2WlHib7OIKON/U6 CnoYOCWoIbDH5s=; b=CDRKxUfRx2MuvLBJCQ694ca5VEArVkWKwSvEh+dvDXdm/ Rcv9oPvA8X22poc/L4X1ZkUnqfBSDy2oiCy+OwSpBYLglgRUwR26MnwkxmaCOOnO UE4+pQX69oVa9vY3JXXeFsj6yAmTcJLnu242whB2nAlQafu1Joh7h2MdQxxi5j7f wnKPoj0QlSf+5cOFjP54oFRFGwjyPG6dWvdHEZsIjgXhgYDqcdkBDXBj4pRucPC+ TiYOmw2ajiEgFc3BirVxktIDXm0Nd+8cYOQrqdJpjw26zvmiXGFdSlMuXA0oL/zK ijaAOVtr0FrAkyqe2e+qcLWXMCDPuIWGfCIa72alQ== X-ME-Sender: Received: from localhost (106-69-204-165.dyn.iinet.net.au [106.69.204.165]) by mail.messagingengine.com (Postfix) with ESMTPA id 16BDD24108; Mon, 5 Feb 2018 17:22:56 -0500 (EST) Date: Tue, 6 Feb 2018 09:22:54 +1100 From: "Tobin C. Harding" To: Adam Borowski Cc: Kees Cook , Petr Mladek , Sergey Senozhatsky , Steven Rostedt , LKML , Andrew Morton , Joe Perches , "Roberts, William C" , Linus Torvalds , David Laight , Randy Dunlap , Geert Uytterhoeven Subject: Re: [PATCH] vsprintf: avoid misleading "(null)" for %px Message-ID: <20180205222254.GS29988@eros> References: <20180204174521.21383-1-kilobyte@angband.pl> <20180205094438.pfd7ffymlvklpxe7@pathway.suse.cz> <20180205201555.GQ29988@eros> <20180205205817.72dy7e7xzjcnwmhs@angband.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180205205817.72dy7e7xzjcnwmhs@angband.pl> X-Mailer: Mutt 1.5.24 (2015-08-30) User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 05, 2018 at 09:58:17PM +0100, Adam Borowski wrote: > On Tue, Feb 06, 2018 at 07:32:32AM +1100, Kees Cook wrote: > > On Tue, Feb 6, 2018 at 7:15 AM, Tobin C. Harding wrote: > > > On Tue, Feb 06, 2018 at 05:57:17AM +1100, Kees Cook wrote: > > >> On Mon, Feb 5, 2018 at 8:44 PM, Petr Mladek wrote: > > >> > On Sun 2018-02-04 18:45:21, Adam Borowski wrote: > > >> >> Like %pK already does, print "00000000" instead. > > >> >> > > >> >> This confused people -- the convention is that "(null)" means you tried to > > >> >> dereference a null pointer as opposed to printing the address. > > > > > > Leaving aside what is converting to %px. If we consider that using %px > > > is meant to convey to us that we _really_ want the address, in hex hence > > > the 'x', then it is not surprising that we will get "00000000"'s for a > > > null pointer, right? Yes it is different to before but since we are > > > changing the specifier does this not imply that there may be some > > > change? > > > > I personally prefer 0000s, but if we're going to change this, we need > > to be aware of the difference. > > It's easy to paint this bikeshed any color you guys want to: there's an "if" > already. My preference is also 0000; NULL would be good, too -- I just > don't want (null) as that has a special meaning in usual userspace > implementations; (null) also fits well most other modes of %p as they show > some object the argument points to. Confusion = wasted debugging time. > > This is consistent with what we had before, with %pK special-cased. > > > > In what is now to be expected fashion for %p the discussion appears to > > > have split into two different things - what to do with %px and what to > > > do with %pK :) > > > > I say leave %pK alone. :) > > As in, printing some random (hashed) value? > > > Let's recap: > > Currently: > not-null null > %pponies object's description (null) > %px address (null) > %pK hash hash > > I'd propose: > not-null null > %pponies object's description (null) > %px address 00000000 > %pK hash 00000000 > > The initial patch in this thread changes printk("%px",0) from (null) to > 00000000; what Tobin complained about is that printk("%pK",0) prints a > random value. Epic fail on my behalf, my first comment was _wrong_ and brought %pK into the discussion - bad Tobin, please crawl back under your rock. The original patch is good IMO and I AFAICT in everyone else's. Tobin