From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752228AbdLJVr7 (ORCPT ); Sun, 10 Dec 2017 16:47:59 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:39088 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751137AbdLJVr6 (ORCPT ); Sun, 10 Dec 2017 16:47:58 -0500 Date: Sun, 10 Dec 2017 13:47:53 -0800 From: "Paul E. McKenney" To: Linus Torvalds Cc: Andy Shevchenko , Kees Cook , David Laight , "linux-kernel@vger.kernel.org" , "mingo@kernel.org" , "jiangshanlai@gmail.com" , "dipankar@in.ibm.com" , "akpm@linux-foundation.org" , "mathieu.desnoyers@efficios.com" , "josh@joshtriplett.org" , "tglx@linutronix.de" , "peterz@infradead.org" , "rostedt@goodmis.org" , "dhowells@redhat.com" , "edumazet@google.com" , "fweisbec@gmail.com" , "oleg@redhat.com" Subject: Re: [PATCH tip/core/rcu 02/20] torture: Prepare scripting for shift from %p to %pK Reply-To: paulmck@linux.vnet.ibm.com References: <20171201200819.GA25519@linux.vnet.ibm.com> <1512158945-27269-2-git-send-email-paulmck@linux.vnet.ibm.com> <20171204134203.GR7829@linux.vnet.ibm.com> <20171204161100.GT7829@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17121021-2213-0000-0000-000002486CA7 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008186; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000244; SDB=6.00958348; UDB=6.00484571; IPR=6.00738370; BA=6.00005733; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00018466; XFM=3.00000015; UTC=2017-12-10 21:47:56 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17121021-2214-0000-0000-00005867985C Message-Id: <20171210214753.GM7829@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-10_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712100325 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Dec 10, 2017 at 12:39:11PM -0800, Linus Torvalds wrote: > On Sun, Dec 10, 2017 at 4:52 AM, Andy Shevchenko > wrote: > >> > >>> Perhaps it should have printed a fixed, non-zero value for non-zero > >>> pointers. > >> > >> I must leave this to the people who have a dog in that contest. ;-) > > > > Since there is an ongoing discussion with security people near to %pK > > and alike, I added Kees and Linus to Cc list. > > > > The proposed change can be done easily, though I have no knowledge > > about possible implications. > > I'd rather make %pK act more like %p than have gratuitous differences. > > I also think %pK is kind of pointless in general. It has not been a > big success, and the whole "root or not" is kind of nasty anyway. Root > in a container? Things like that. > > So I think that if people worry about leaking pointers, they should > primarily go for: > > - just use %p and now get the hashed value > > - if the hashed value is pointless, ask yourself whether the pointer > itself is important. Maybe it should be removed? > > - as a last option, if you really think the true pointer value is > important, why is root so special, and maybe you should use %px and > make sure you have proper sensible permissions. > > ..and %pK just isn't really the answer in any of those cases. My main use case is comparing pointer values directly, for example, in the console log against those in event-trace output. So if those are hashed the same way, I wouldn't even notice. I very rarely need to compute offsets, but I thought that the low-order bits were excluded from the hash to make this work straightforwardly in the common case. Of course, computing offsets could be a problem for larger structures, by my reaction to that would be to make the kernel do the offset computation for me as needed. So it looks like I should drop the three patches in my tree that convert %p to %pK. Any objections? Thanx, Paul