[PATCH] drm/amd/amdgpu: cast mem->num_pages to 64-bits when shifting

StDenis, Tom Tom.StDenis at amd.com
Mon Jun 17 20:05:35 UTC 2019


Ok no worries I'll fix it up and push it later today.

Btw I didn't use an inline cast because the macro kept breaking. I tried variants of parentheses and nothing worked.... Odd...


Thanks,
Tom

On June 17, 2019 3:32:03 PM EDT, "Kuehling, Felix" <Felix.Kuehling at amd.com> wrote:

On 2019-06-17 3:28 p.m., Christian König wrote:
Am 17.06.19 um 21:15 schrieb Kuehling, Felix:
 Looks good to me. One cosmetic comment inline. With that fixed this
 patch is Reviewed-by:  Felix Kuehling <Felix.Kuehling at amd.com>

 On 2019-06-14 12:51 p.m., StDenis, Tom wrote:
 On 32-bit hosts mem->num_pages is 32-bits and can overflow
 when shifted.  Add a cast to avoid this.

 Signed-off-by: Tom St Denis <tom.stdenis at amd.com>
________________________________
    drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 8 +++++---
    1 file changed, 5 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
 b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
 index c963ad86072e..31895d3c33de 100644
 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
 +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
 @@ -279,14 +279,16 @@ static int amdgpu_vram_mgr_new(struct
 ttm_mem_type_manager *man,
        uint64_t vis_usage = 0;
        unsigned i;
        int r;
 +    uint64_t mem_bytes;
Christian likes the "upside-down christmas tree" to help readability of
local variable declarations.

 Ah, yeah. Thanks for the note.

 I actually don't care about that much, but I always get rejects from
 upstream subsystem maintainers if I don't do this.

 It's most likely not even documented somewhere,

Right. The fact that I even noticed it probably means that I have a mild
case of OCD myself. If it was a strict requirement, it should be caught
by checkpatch.pl.

Cheers,
   Felix


 Christian.



          lpfn = place->lpfn;
       if (!lpfn)
           lpfn = man->size;
          /* bail out quickly if there's likely not enough VRAM for
this BO */
-    if (atomic64_add_return(mem->num_pages << PAGE_SHIFT,
&mgr->usage) > adev->gmc.mc_vram_size) {
-        atomic64_sub(mem->num_pages << PAGE_SHIFT, &mgr->usage);
+    mem_bytes = (u64)mem->num_pages << PAGE_SHIFT;
+    if (atomic64_add_return(mem_bytes, &mgr->usage) >
adev->gmc.mc_vram_size) {
+        atomic64_sub(mem_bytes, &mgr->usage);
           mem->mm_node = NULL;
           return 0;
       }
@@ -308,7 +310,7 @@ static int amdgpu_vram_mgr_new(struct
ttm_mem_type_manager *man,
       nodes = kvmalloc_array((uint32_t)num_nodes, sizeof(*nodes),
                      GFP_KERNEL | __GFP_ZERO);
       if (!nodes) {
-        atomic64_sub(mem->num_pages << PAGE_SHIFT, &mgr->usage);
+        atomic64_sub(mem_bytes, &mgr->usage);
           return -ENOMEM;
       }
________________________________
amd-gfx mailing list
amd-gfx at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20190617/55fb5d05/attachment.html>


More information about the amd-gfx mailing list