linux-kernel - Re: [PATCH] drm/xen-front: fix pointer casts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 23 May 2018 14:27:43 +0300
From:   Oleksandr Andrushchenko <andr2000@...il.com>
To:     Juergen Gross <jgross@...e.com>, xen-devel@...ts.xenproject.org,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        daniel.vetter@...el.com, boris.ostrovsky@...cle.com
Cc:     Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>
Subject: Re: [PATCH] drm/xen-front: fix pointer casts

On 05/23/2018 02:06 PM, Juergen Gross wrote:
> On 23/05/18 12:00, Oleksandr Andrushchenko wrote:
>> On 05/23/2018 12:19 PM, Juergen Gross wrote:
>>> On 21/05/18 09:39, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>
>>>>
>>>> Building for a 32-bit target results in warnings from casting
>>>> between a 32-bit pointer and a 64-bit integer. Fix the warnings
>>>> by casting those pointers to uintptr_t first.
>>>>
>>>> Signed-off-by: Oleksandr Andrushchenko
>>>> <oleksandr_andrushchenko@...m.com>
>>>> ---
>>>>    drivers/gpu/drm/xen/xen_drm_front.h       | 4 ++--
>>>>    drivers/gpu/drm/xen/xen_drm_front_shbuf.c | 2 +-
>>>>    2 files changed, 3 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/xen/xen_drm_front.h
>>>> b/drivers/gpu/drm/xen/xen_drm_front.h
>>>> index 2c2479b571ae..8e15dbebc4ba 100644
>>>> --- a/drivers/gpu/drm/xen/xen_drm_front.h
>>>> +++ b/drivers/gpu/drm/xen/xen_drm_front.h
>>>> @@ -126,12 +126,12 @@ struct xen_drm_front_drm_info {
>>>>      static inline u64 xen_drm_front_fb_to_cookie(struct
>>>> drm_framebuffer *fb)
>>>>    {
>>>> -    return (u64)fb;
>>>> +    return (u64)(uintptr_t)fb;
>>> Do you really still need the cast to u64?
>> Indeed, I can remove (u64) now, thank you
>>>>    }
>>>>      static inline u64 xen_drm_front_dbuf_to_cookie(struct
>>>> drm_gem_object *gem_obj)
>>>>    {
>>>> -    return (u64)gem_obj;
>>>> +    return (u64)(uintptr_t)gem_obj;
>>>>    }
>>>>      int xen_drm_front_mode_set(struct xen_drm_front_drm_pipeline
>>>> *pipeline,
>>>> diff --git a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
>>>> b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
>>>> index 8099cb343ae3..47fc93847765 100644
>>>> --- a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
>>>> +++ b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
>>>> @@ -122,7 +122,7 @@ static void guest_calc_num_grefs(struct
>>>> xen_drm_front_shbuf *buf)
>>>>    }
>>>>      #define xen_page_to_vaddr(page) \
>>>> -        ((phys_addr_t)pfn_to_kaddr(page_to_xen_pfn(page)))
>>>> +        ((phys_addr_t)(uintptr_t)pfn_to_kaddr(page_to_xen_pfn(page)))
>>> phys_addr_t for a virtual address?
>> This is because the resulting value is then passed to gnttab_set_map_op/
>> gnttab_set_unmap_op which expects host address to be passed as
>> phys_addr_t addr :(
> Okay, but this means the compiler should do the necessary cast when
> you drop the cast to phys_addr_t in xen_page_to_vaddr(), as the cast
> to uintptr_t is already producing an unsigned integer value which can
> easily be promoted to more bits, right?
Right, so I can safely use:
  #define xen_page_to_vaddr(page) \
- ((phys_addr_t)(uintptr_t)pfn_to_kaddr(page_to_xen_pfn(page)))
+               ((uintptr_t)pfn_to_kaddr(page_to_xen_pfn(page)))

>
> Juergen
Thank you for your time and comments,
Oleksandr