Received: by 10.223.176.5 with SMTP id f5csp2919205wra; Mon, 5 Feb 2018 12:16:51 -0800 (PST) X-Google-Smtp-Source: AH8x226x92JcnvjinSxxXkKP3pM1JChz4c7lfPVkqLRl3DTC7Bu+JfSUxDO9S3PDCPXYQMAw2imx X-Received: by 10.101.68.138 with SMTP id l10mr6405pgq.119.1517861811779; Mon, 05 Feb 2018 12:16:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517861811; cv=none; d=google.com; s=arc-20160816; b=t5ClLMdKOgUsveDm1I2YcCv+o82DXRB6HRdTFZHkBfcfCQ+FRW0tFEQ6Bn6uAaFPPa LDyIHeOjcMhtuV5SqUDg+7wXodk4//ZLTjNyqPmItrkkjh5cNF3JuiTXQPNdV3V8uLdE 7Klm7iuIuSqAcUSJvdSWz5qc9b/TQQtozj/7/y+z0vgi38c+9CyD02UpLp2V7oCiTazx 7NETfijIrWfDuAN05fE+X4ZktTSd9mD1Z0yKgFO5a0r1hrsaVAlGV7IJU6jddMPoA13s BIAQvGwsfaYpkKNW3BnntqFcT7n4kCG+eT1CuvYa3iyF/Yt3iiU6apUFmAQQi01F+Ut8 q4rw== 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=YPrbunP4+cKQwKA4+ES2BsiD1Y9kiRnyxzu0KAS5uxo=; b=QoZ+q/oXWmrZMhRhJ8lhLy+smkBU2q9NoMVBoPxle90xNG4dU2BQ+ukxyhCYQKL1Sp 0bvQOHt0cAxPqwXqO3YRNfY1fQezNb1TVDDNpFryb8Qepthq2lwqTTaAwiYHPEg7Cw/V TK9Rv1L1N8/ALxcGkjqHoS653DmXE1/I434b5yU5E+2spLxRa0vVpdTGQAMhqReowsaf Pk1vtyGwtn7MwwVJRid2c3CumCpAWL4xvME1If2tPxHWq4Y/HcBpzZJokHGhdo8fIcAl A5JKfFI/vLawyZGumD9R/audqiBEknshMASaK5cagLhNRI2RegSifi3OetlXCIrLi76N L7bQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@tobin.cc header.s=fm2 header.b=LFC0bkXg; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=JLYKjqdi; 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 o3-v6si5470904pls.450.2018.02.05.12.16.37; Mon, 05 Feb 2018 12:16:51 -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=LFC0bkXg; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=JLYKjqdi; 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 S1751724AbeBEUQF (ORCPT + 99 others); Mon, 5 Feb 2018 15:16:05 -0500 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:52663 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751015AbeBEUQA (ORCPT ); Mon, 5 Feb 2018 15:16:00 -0500 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 8A96E20A5B; Mon, 5 Feb 2018 15:15:59 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Mon, 05 Feb 2018 15:15:59 -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=YPrbunP4+cKQwKA4+ES2BsiD1Y9kiRnyxzu0KAS5uxo=; b=LFC0bkXg qSiBIjFHnftyzcJ7rFrF26OWwoDipY82lXU20leKvksrLxp41c9QKhhUWDLAVV/R kaJKh7s57qqTt3NQ+41beC4M9TjBvERVhO7esnl/KDa+ndHp1DHe7/mGFiUKrP73 LHuqcCMc90HKikg+ugiyOBH5ZJdOOF8NiF/XC05Bu+8W39a5HRM4HwTleFhPQTCg NcZ3gWBY4VTuiCeYxuFYtr4IC2Ta0CvIOv9YccQIcHSMlqI8DHKXAScp0k/8DrA8 NZvABz2Gw1MkKqCA7Wnm+HF68BJvz+J5AfnY9GXQDTHRVmGVoZMho54GTk5/ToA9 L3k7pdzMPcIcTw== 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=YPrbunP4+cKQwKA4+ES2BsiD1Y9ki Rnyxzu0KAS5uxo=; b=JLYKjqdiFsC5uLzFPnwXJCO4a+koz+vxoZGZi8xZPVRZz vTseJZpoEh3r6QgY9fkt9JHrTiT0rEroBrEPCVsizXuZl3mk1dYkZHIyGP9KmeLT /VZi7Ed6NmszgvLpCp3oKM9pUJevOGiwm+Mh226IXClEcp+Xbw6nXpnzBHRYix2b 0lqSVgH4Im6XItI3KXtIWVsHJCkNHLfnAuLYsk3Xda1ofiLwS0URUdODmlDvtGov ppww0BVnpypzQ5mgFtKogoB4DYZVGYsk7MI1SXWovXIyxEgPECit2j6GSePbg8Lv NNEEoiTaWrgzWzw3HwQOQ1E6G70JEQT5ai+ucebdQ== 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 BE0D624108; Mon, 5 Feb 2018 15:15:58 -0500 (EST) Date: Tue, 6 Feb 2018 07:15:55 +1100 From: "Tobin C. Harding" To: Kees Cook Cc: Petr Mladek , Adam Borowski , 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: <20180205201555.GQ29988@eros> References: <20180204174521.21383-1-kilobyte@angband.pl> <20180205094438.pfd7ffymlvklpxe7@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Tue, Feb 06, 2018 at 05:57:17AM +1100, Kees Cook wrote: > On Mon, Feb 5, 2018 at 8:44 PM, Petr Mladek wrote: > > Hi, > > > > I add people who actively commented on adding %px modifier, > > see the thread starting at > > https://lkml.kernel.org/r/1511921105-3647-5-git-send-email-me@tobin.cc > > > > Just for reference. It seems to be related to the commit 9f36e2c448007b54 > > ("printk: use %pK for /proc/kallsyms and /proc/modules"). > > > > > > 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. > > > > By other words, this avoids regressions when people convert > > %x to %px. Do I get it right, please? > > Nothing should be converting from %x to %px, it's %p to %px. %p print > "(null)" for 0x0, so it would be surprising for a conversion from %p > to %px to change that. (Though generally speaking "(null)" is never > useful...) 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? 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 :) thanks, Tobin.