Re: [PATCH tip/core/rcu 02/20] torture: Prepare scripting for shift from %p to %pK

[Paul E. McKenney]

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
> <paulmck@xxxxxxxxxxxxxxxxxx> 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