[PATCH] habanalabs: use %px instead of %p in error print

[PATCH] habanalabs: use %px instead of %p in error print

[Oded Gabbay]

When parsing the address of an internal command buffer, the driver prints
an error if the buffer's address is not in the range of the device's DRAM
or SRAM memory address space.

Use %px to print the real address that the user gave the driver and not a
hashed value, so the user will get a clue regarding the origin of his
error.

Note that if the print occurs, the pointer that is printed is a
user's virtual address and not some kind of physical address.

Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
---
 drivers/misc/habanalabs/goya/goya.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/habanalabs/goya/goya.c b/drivers/misc/habanalabs/goya/goya.c
index c4f3ec1e9d8b..238dd57c541b 100644
--- a/drivers/misc/habanalabs/goya/goya.c
+++ b/drivers/misc/habanalabs/goya/goya.c
@@ -4293,7 +4293,7 @@ static int goya_parse_cb_no_ext_quque(struct hl_device *hdev,
 			return 0;
 
 		dev_err(hdev->dev,
-			"Internal CB address %p + 0x%x is not in SRAM nor in DRAM\n",
+			"Internal CB address %px + 0x%x is not in SRAM nor in DRAM\n",
 			parser->user_cb, parser->user_cb_size);
 
 		return -EFAULT;
-- 
2.18.0

Re: [PATCH] habanalabs: use %px instead of %p in error print

[Kees Cook]

On Sat, Mar 2, 2019 at 1:43 AM Oded Gabbay <oded.gabbay@gmail.com> wrote:
>
> When parsing the address of an internal command buffer, the driver prints
> an error if the buffer's address is not in the range of the device's DRAM
> or SRAM memory address space.
>
> Use %px to print the real address that the user gave the driver and not a
> hashed value, so the user will get a clue regarding the origin of his
> error.
>
> Note that if the print occurs, the pointer that is printed is a
> user's virtual address and not some kind of physical address.

Err, which virtual address space is this? If this is mapped into the
kernel's virtual address space, this should not be %px...

-Kees

>
> Suggested-by: Joe Perches <joe@perches.com>
> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
> ---
>  drivers/misc/habanalabs/goya/goya.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/misc/habanalabs/goya/goya.c b/drivers/misc/habanalabs/goya/goya.c
> index c4f3ec1e9d8b..238dd57c541b 100644
> --- a/drivers/misc/habanalabs/goya/goya.c
> +++ b/drivers/misc/habanalabs/goya/goya.c
> @@ -4293,7 +4293,7 @@ static int goya_parse_cb_no_ext_quque(struct hl_device *hdev,
>                         return 0;
>
>                 dev_err(hdev->dev,
> -                       "Internal CB address %p + 0x%x is not in SRAM nor in DRAM\n",
> +                       "Internal CB address %px + 0x%x is not in SRAM nor in DRAM\n",
>                         parser->user_cb, parser->user_cb_size);
>
>                 return -EFAULT;
> --
> 2.18.0
>


-- 
Kees Cook

Re: [PATCH] habanalabs: use %px instead of %p in error print

[Oded Gabbay]

On Thu, Mar 7, 2019 at 5:46 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Sat, Mar 2, 2019 at 1:43 AM Oded Gabbay <oded.gabbay@gmail.com> wrote:
> >
> > When parsing the address of an internal command buffer, the driver prints
> > an error if the buffer's address is not in the range of the device's DRAM
> > or SRAM memory address space.
> >
> > Use %px to print the real address that the user gave the driver and not a
> > hashed value, so the user will get a clue regarding the origin of his
> > error.
> >
> > Note that if the print occurs, the pointer that is printed is a
> > user's virtual address and not some kind of physical address.
>
> Err, which virtual address space is this? If this is mapped into the
> kernel's virtual address space, this should not be %px...
No, it's not mapped to kernel in any way.
It's supposed to be an address in the device's address space.
As this is an error message, it's either a wrong address in the
device's address space, or it's a user-space virtual address.
Oded


>
> -Kees
>
> >
> > Suggested-by: Joe Perches <joe@perches.com>
> > Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
> > ---
> >  drivers/misc/habanalabs/goya/goya.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/misc/habanalabs/goya/goya.c b/drivers/misc/habanalabs/goya/goya.c
> > index c4f3ec1e9d8b..238dd57c541b 100644
> > --- a/drivers/misc/habanalabs/goya/goya.c
> > +++ b/drivers/misc/habanalabs/goya/goya.c
> > @@ -4293,7 +4293,7 @@ static int goya_parse_cb_no_ext_quque(struct hl_device *hdev,
> >                         return 0;
> >
> >                 dev_err(hdev->dev,
> > -                       "Internal CB address %p + 0x%x is not in SRAM nor in DRAM\n",
> > +                       "Internal CB address %px + 0x%x is not in SRAM nor in DRAM\n",
> >                         parser->user_cb, parser->user_cb_size);
> >
> >                 return -EFAULT;
> > --
> > 2.18.0
> >
>
>
> --
> Kees Cook

Re: [PATCH] habanalabs: use %px instead of %p in error print

[Kees Cook]

On Wed, Mar 6, 2019 at 9:42 PM Oded Gabbay <oded.gabbay@gmail.com> wrote:
>
> On Thu, Mar 7, 2019 at 5:46 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Sat, Mar 2, 2019 at 1:43 AM Oded Gabbay <oded.gabbay@gmail.com> wrote:
> > >
> > > When parsing the address of an internal command buffer, the driver prints
> > > an error if the buffer's address is not in the range of the device's DRAM
> > > or SRAM memory address space.
> > >
> > > Use %px to print the real address that the user gave the driver and not a
> > > hashed value, so the user will get a clue regarding the origin of his
> > > error.
> > >
> > > Note that if the print occurs, the pointer that is printed is a
> > > user's virtual address and not some kind of physical address.
> >
> > Err, which virtual address space is this? If this is mapped into the
> > kernel's virtual address space, this should not be %px...
> No, it's not mapped to kernel in any way.
> It's supposed to be an address in the device's address space.
> As this is an error message, it's either a wrong address in the
> device's address space, or it's a user-space virtual address.

Okay, thanks! :)

-- 
Kees Cook