On Sun, Dec 10, 2017 at 02:52:49PM +0200, Andy Shevchenko wrote: > On Mon, Dec 4, 2017 at 6:11 PM, Paul E. McKenney > <paul...@linux.vnet.ibm.com> wrote: > > On Mon, Dec 04, 2017 at 02:13:38PM +0000, David Laight wrote: > >> From: Paul E. McKenney > >> > Sent: 04 December 2017 13:42 > >> > On Mon, Dec 04, 2017 at 12:32:30PM +0000, David Laight wrote: > >> > > From: Paul E. McKenney > >> > > > Sent: 01 December 2017 20:09 > >> > > > > >> > > > Because %p prints "(null)" and %pK prints "0000000000000000" or (on > >> > > > 32-bit systems) "00000000", this commit adjusts torture-test > >> > > > scripting > >> > > > accordingly. > >> > > > >> > > Surely NULL v not-NULL is one bit of info that the message needs to > >> > > contain? > >> > > >> > Indeed. So the script needs to check for the strings "00000000", > >> > "0000000000000000", and "(null) in the console output". The "(null)" > >> > is what "%p" prints for a NULL pointer, and the other two strings are > >> > what "%pK" prints for a NULL pointer. > >> > > >> > Or am I missing your point? > >> > >> I was thinking that even %pK should print "(null)". > > > > That was my expectation, as in the need for this patch came as a > > surprise to me. > > > >> 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.
One question I have is whether the patches to convert RCU to %pK are even desirable at this point: https://lwn.net/Articles/737451/ If something like the patches in that article get to mainline, then shouldn't I just drop RCU's %pK patches? Thanx, Paul
