Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: "Ghimiray, Himal Prasad" <himal.prasad.ghimiray@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
	Matthew Auld <matthew.auld@intel.com>,
	Matthew Brost <matthew.brost@intel.com>
Subject: Re: [PATCH] drm/xe/xe_migrate: Fix potential overflows expression
Date: Fri, 22 Mar 2024 15:37:22 -0400	[thread overview]
Message-ID: <Zf3d8niX22_zfvZy@intel.com> (raw)
In-Reply-To: <2bb36b66-8931-4adc-9f94-5e37958a5f25@intel.com>

On Fri, Mar 22, 2024 at 03:00:17PM +0530, Ghimiray, Himal Prasad wrote:
>    On 21-03-2024 02:27, Rodrigo Vivi wrote:                                     
>                                                                                 
>    On Wed, Mar 20, 2024 at 03:48:35PM +0530, Himal Prasad Ghimiray wrote:       
>                                                                                 
>    >Cast to proper datatypes to avoid overflows.                                
>                                                                                 
>    I'm afraid that the cast wont prevent the overflow, but mask it.             
>    probably safer to move the multiplication to some of the helpers             
>    in linux/math64.h ?!                                                         
>                                                                                 
>    Hi Rodrigo,                                                                  
>    Thank you for your response. The modifications are inspired by the inline    
>    u64 mul_u32_u32(u32 a, u32 b)                                                
>    function defined in linux/math64.h. Initially, I considered using the same   
>    approach.                                                                    
>    However, I discovered an architecture-specific implementation for            
>    mul_u32_u32.                                                                 
>    To prevent ambiguity, I opted for casting, which I observed is a standard    
>    practice throughout Linux code.                                              

afaik the cast just tells compilers and static analyzer tools that we know
what we are doing and we know that that math on the right won't exceed
the cast size. But it doesn't prevent overflow. You need to take care
and be sure that you are not overflowing the bits you have available. Always.

I doubled checked all the cases below and I'm sure we don't have any
overflow issue there. So you need to at least adjust the commit message.


Btw, (map_ofs / XE_PAGE_SIZE - NUM_KERNEL_PDE) probably deserves a separate
patch to make it to use some of the variants of DIV_ROUND macros...


>    BR                                                                           
>    Himal                                                                        
>                                                                                 
>                                                                                 
>                                                                                 
>    >Cc: Matthew Auld [1]<matthew.auld@intel.com>                                
>    >Cc: Matthew Brost [2]<matthew.brost@intel.com>                              
>    >Cc: Rodrigo Vivi [3]<rodrigo.vivi@intel.com>                                
>    >Signed-off-by: Himal Prasad Ghimiray [4]<himal.prasad.ghimiray@intel.com>   
>    >---                                                                         
>    >These errors were highlighted by Coverity. I'm uncertain whether they       
>    >require attention or if it would be more appropriate to label them as       
>    >false positives within the tool.                                            
>                                                                                 
>    >I've submitted this patch in case addressing the issues is necessary.       
>    >However, if reviewers determine that these issues should be marked as       
>    >false positives or ignored within the tool, that option is also             
>    >available                                                                   
>                                                                                 
>    > drivers/gpu/drm/xe/xe_migrate.c | 8 ++++----                               
>    > 1 file changed, 4 insertions(+), 4 deletions(-)                            
>                                                                                 
>    >diff --git a/drivers/gpu/drm/xe/xe_migrate.c b/drivers/gpu/drm/xe/xe_migrate.c
>    >index ee1bb938c493..2ba4fb9511f6 100644                                     
>    >--- a/drivers/gpu/drm/xe/xe_migrate.c                                       
>    >+++ b/drivers/gpu/drm/xe/xe_migrate.c                                       
>    >@@ -227,7 +227,7 @@ static int xe_migrate_prepare_vm(struct xe_tile *tile, struct xe_migrate *m,
>    >                if (vm->flags & XE_VM_FLAG_64K && level == 1)               
>    >                        flags = XE_PDE_64K;                                 
>    >                                                                            
>    >-               entry = vm->pt_ops->pde_encode_bo(bo, map_ofs + (level - 1) *
>    >+               entry = vm->pt_ops->pde_encode_bo(bo, map_ofs + (u64)(level - 1) *
>    >                                                  XE_PAGE_SIZE, pat_index); 
>    >                xe_map_wr(xe, &bo->vmap, map_ofs + XE_PAGE_SIZE * level, u64,
>    >                          entry | flags);                                   
>    >@@ -235,7 +235,7 @@ static int xe_migrate_prepare_vm(struct xe_tile *tile, struct xe_migrate *m,
>    >                                                                            
>    >        /* Write PDE's that point to our BO. */                             
>    >        for (i = 0; i < num_entries - num_level; i++) {                     
>    >-               entry = vm->pt_ops->pde_encode_bo(bo, i * XE_PAGE_SIZE,     
>    >+               entry = vm->pt_ops->pde_encode_bo(bo, (u64)i * XE_PAGE_SIZE,
>    >                                                  pat_index);               
>    >                                                                            
>    >                xe_map_wr(xe, &bo->vmap, map_ofs + XE_PAGE_SIZE +           
>    >@@ -291,7 +291,7 @@ static int xe_migrate_prepare_vm(struct xe_tile *tile, struct xe_migrate *m,
>    > #define VM_SA_UPDATE_UNIT_SIZE         (XE_PAGE_SIZE / NUM_VMUSA_UNIT_PER_PAGE)
>    > #define NUM_VMUSA_WRITES_PER_UNIT      (VM_SA_UPDATE_UNIT_SIZE / sizeof(u64))
>    >        drm_suballoc_manager_init(&m->vm_update_sa,                         
>    >-                                 (map_ofs / XE_PAGE_SIZE - NUM_KERNEL_PDE) *
>    >+                                 (size_t)(map_ofs / XE_PAGE_SIZE - NUM_KERNEL_PDE) *
>    >                                  NUM_VMUSA_UNIT_PER_PAGE, 0);              
>    >                                                                            
>    >        m->pt_bo = bo;                                                      
>    >@@ -490,7 +490,7 @@ static void emit_pte(struct xe_migrate *m,              
>    >        struct xe_vm *vm = m->q->vm;                                        
>    >        u16 pat_index;                                                      
>    >        u32 ptes;                                                           
>    >-       u64 ofs = at_pt * XE_PAGE_SIZE;                                     
>    >+       u64 ofs = (u64)at_pt * XE_PAGE_SIZE;                                
>    >        u64 cur_ofs;                                                        
>    >                                                                            
>    >        /* Indirect access needs compression enabled uncached PAT index */  
>    >--                                                                          
>    >2.25.1                                                                      
> 
> References
> 
>    Visible links
>    1. mailto:matthew.auld@intel.com
>    2. mailto:matthew.brost@intel.com
>    3. mailto:rodrigo.vivi@intel.com
>    4. mailto:himal.prasad.ghimiray@intel.com

  reply	other threads:[~2024-03-22 19:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-20 10:18 [PATCH] drm/xe/xe_migrate: Fix potential overflows expression Himal Prasad Ghimiray
2024-03-20 10:12 ` ✓ CI.Patch_applied: success for " Patchwork
2024-03-20 10:13 ` ✓ CI.checkpatch: " Patchwork
2024-03-20 10:14 ` ✓ CI.KUnit: " Patchwork
2024-03-20 10:24 ` ✓ CI.Build: " Patchwork
2024-03-20 10:27 ` ✓ CI.Hooks: " Patchwork
2024-03-20 10:28 ` ✓ CI.checksparse: " Patchwork
2024-03-20 10:54 ` ✓ CI.BAT: " Patchwork
2024-03-20 20:57 ` [PATCH] " Rodrigo Vivi
2024-03-22  9:30   ` Ghimiray, Himal Prasad
2024-03-22 19:37     ` Rodrigo Vivi [this message]
2024-03-25  4:15       ` Ghimiray, Himal Prasad
2024-03-28 13:45 ` ✓ CI.Patch_applied: success for drm/xe/xe_migrate: Fix potential overflows expression (rev2) Patchwork
2024-03-28 13:46 ` ✓ CI.checkpatch: " Patchwork
2024-03-28 13:47 ` ✓ CI.KUnit: " Patchwork
2024-03-28 13:59 ` ✓ CI.Build: " Patchwork
2024-03-28 14:02 ` ✓ CI.Hooks: " Patchwork
2024-03-28 14:05 ` ✓ CI.checksparse: " Patchwork
2024-03-28 14:41 ` ✓ CI.BAT: " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zf3d8niX22_zfvZy@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=himal.prasad.ghimiray@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=matthew.brost@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox