Re: [PATCH] rpmsg: virtio_rpmsg_bus: replace "%p" with "%pK"

[Bjorn Andersson]

On Tue 27 Aug 15:17 PDT 2019, Suman Anna wrote:

> On 8/27/19 5:15 PM, Suman Anna wrote:
> > On 8/27/19 5:07 PM, Bjorn Andersson wrote:
> >> On Tue 27 Aug 13:25 PDT 2019, Suman Anna wrote:
> >>
> >>> Hi Bjorn,
> >>>
> >>> On 8/27/19 12:10 AM, Bjorn Andersson wrote:
> >>>> On Fri 09 Aug 13:25 PDT 2019, Suman Anna wrote:
> >>>>
> >>>>> Hi Bjorn,
> >>>>>
> >>>>
> >>>> Hi Suman
> >>>>
> >>>>> On 10/23/18 8:19 PM, Suman Anna wrote:
> >>>>>> The virtio_rpmsg_bus driver uses the "%p" format-specifier for
> >>>>>> printing the vring buffer address. This prints only a hashed
> >>>>>> pointer even for previliged users. Use "%pK" instead so that
> >>>>>> the address can be printed during debug using kptr_restrict
> >>>>>> sysctl.
> >>>>>
> >>>>> Seems to have been lost among the patches, can you pick up this trivial
> >>>>> patch for 5.4? Should apply cleanly on the latest HEAD as well.
> >>>>>
> >>>>
> >>>> I share Andrew's question regarding what benefit you have from knowing
> >>>> this value. Should we not just remove the va from the print? Or do you
> >>>> actually have a use case for it?.
> >>>
> >>> I mainly use it during debug when comparing against kernel_page_tables
> >>> and vmallocinfo. The pools that we use are not always guaranteed to be
> >>> from linear memory, and behavior changes when using with CMA or DMA pools.
> >>>
> >>
> >> Thanks Suman. It seems to me that there's room for improvement to aid
> >> this kind of debugging. But your usecase seems reasonable, so I'm
> >> merging the patch.
> > 
> > Thanks Bjorn.
> 
> Btw, looks like you applied the patch against rproc-next instead of
> rpmsg-next.
> 

Thanks for noticing so quick; I moved the change to the correct
branch.

Regards,
Bjorn

> regards
> Suman
> 
> > 
> >>
> >>> Note that usage of %pK does not leak the addresses automatically, but
> >>> atleast enables me to get the values when needed. The changes also bring
> >>> the usage in rpmsg core in sync with the remoteproc core.
> >>>
> >>
> >> Sounds like shouldn't have merged them in remoteproc then ;P
> > 
> > Slightly different reasoning looking at the commit, it was probably when
> > %p was leaking the addresses.
> > 
> > regards
> > Suman
> > 
> >>
> >> Thanks,
> >> Bjorn
> >>
> >>> regards
> >>> Suman
> >>>
> >>>>
> >>>> Regards,
> >>>> Bjorn
> >>>>
> >>>>> regards
> >>>>> Suman
> >>>>>
> >>>>>>
> >>>>>> Signed-off-by: Suman Anna <s-anna@xxxxxx>
> >>>>>> ---
> >>>>>>  drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
> >>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
> >>>>>> index f29dee731026..1345f373a1a0 100644
> >>>>>> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> >>>>>> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> >>>>>> @@ -950,7 +950,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
> >>>>>>  		goto vqs_del;
> >>>>>>  	}
> >>>>>>  
> >>>>>> -	dev_dbg(&vdev->dev, "buffers: va %p, dma %pad\n",
> >>>>>> +	dev_dbg(&vdev->dev, "buffers: va %pK, dma %pad\n",
> >>>>>>  		bufs_va, &vrp->bufs_dma);
> >>>>>>  
> >>>>>>  	/* half of the buffers is dedicated for RX */
> >>>>>>
> >>>>>
> >>>
> > 
>