[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xen/spinlock: use correct pointer


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
  • Date: Fri, 26 Apr 2024 10:33:16 -0400
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Vpx/cFxweS61wRRRkOw84SPvY4PtH2Glydv/7cYPezA=; b=XMrbDOpMM9B6F0Ld6t4H5yuJvtjBL32/8nir92BitdCdMeaA29SMBLqE3/ppdirV0gVnN8WxfuVRAR5ajmFS4ViOTXrM9NBhJR2GyqBn/0XiCBzEhxCZYuw07VigKeYHKmbx95BdxYBdzLqQstKY+Ei/fx+o39oYlxAHwwB4gerjrvZdnQkwzfl5X6abWOx9f7mg4zPtS+/LjKnQ1GuyjyIbth2K2UOhV1AxrKniMkVFVELu8oLdwEb+hyPFue8qMhqBkPRc5/AYBRBeiSV45SXsN8AMzsxo8BeofK2S18rX6WrxNDL7AGRkq78VTVdDdfn9nJUyfIxFuF8hWUWOMw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C1ojq8+SFUa25LR9tOz9+pt5GjNx2tYayTUKhJxzAgeDboHPEGZOD3m30TbUwhAjrobudov4bZjRbeO5zC+m+cR/a6+O9WpB1EhKmaYnuC3VBYavu8xMNn5DOgZHYkvx1BbLGAtY5JzukIbkZ41RH6M5fT7v7ZpY8538qGt3TWvnO24LJ+95gz3nzn9t39NEup4z8IDYIgbUs5CGiZG4eAvvF5bCqK27RAnfqpzberugjsziNOUr5uX3oCPA1fyu2h5I8Yg5rWXikP21eW89uADZrh42yge4SM6UF5xcIfqcuOd09uDaEY9Az/myGDxIE8BUvuL39OS7orth2bg3ew==
  • Cc: Juergen Gross <jgross@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 26 Apr 2024 14:33:38 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 4/26/24 02:31, Jan Beulich wrote:
> On 25.04.2024 22:45, Stewart Hildebrand wrote:
>> The ->profile member is at different offsets in struct rspinlock and
>> struct spinlock. When initializing the profiling bits of an rspinlock,
>> an unrelated member in struct rspinlock was being overwritten, leading
>> to mild havoc. Use the correct pointer.
>>
>> Fixes: b053075d1a7b ("xen/spinlock: make struct lock_profile rspinlock_t 
>> aware")
>> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
> 
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Thanks!

> 
>> --- a/xen/common/spinlock.c
>> +++ b/xen/common/spinlock.c
>> @@ -789,7 +789,11 @@ static int __init cf_check lock_prof_init(void)
>>      {
>>          (*q)->next = lock_profile_glb_q.elem_q;
>>          lock_profile_glb_q.elem_q = *q;
>> -        (*q)->ptr.lock->profile = *q;
>> +
>> +        if ( (*q)->is_rlock )
>> +            (*q)->ptr.rlock->profile = *q;
>> +        else
>> +            (*q)->ptr.lock->profile = *q;
>>      }
>>  
>>      _lock_profile_register_struct(LOCKPROF_TYPE_GLOBAL,
> 
> Just to mention it: Strictly speaking spinlock_profile_print_elem()'s
> 
>     printk("%s: addr=%p, lockval=%08x, ", data->name, data->ptr.lock, 
> lockval);
> 
> isn't quite right either (and I would be surprised if Misra didn't have
> to say something about it).
> 
> Jan

I'd be happy to send a patch for that instance, too. Would you like a
Reported-by: tag?

That patch would look something like:

--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -637,22 +637,25 @@ static void cf_check spinlock_profile_print_elem(struct 
lock_profile *data,
 {
     unsigned int cpu;
     unsigned int lockval;
+    void *lockaddr;
 
     if ( data->is_rlock )
     {
         cpu = data->ptr.rlock->debug.cpu;
         lockval = data->ptr.rlock->tickets.head_tail;
+        lockaddr = data->ptr.rlock;
     }
     else
     {
         cpu = data->ptr.lock->debug.cpu;
         lockval = data->ptr.lock->tickets.head_tail;
+        lockaddr = data->ptr.lock;
     }
 
     printk("%s ", lock_profile_ancs[type].name);
     if ( type != LOCKPROF_TYPE_GLOBAL )
         printk("%d ", idx);
-    printk("%s: addr=%p, lockval=%08x, ", data->name, data->ptr.lock, lockval);
+    printk("%s: addr=%p, lockval=%08x, ", data->name, lockaddr, lockval);
     if ( cpu == SPINLOCK_NO_CPU )
         printk("not locked\n");
     else


That case is benign since the pointer is not dereferenced. So the
rationale would primarily be for consistency (and possibly satisfying
Misra).



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.