Received: by 10.213.65.68 with SMTP id h4csp218656imn; Tue, 13 Mar 2018 01:51:49 -0700 (PDT) X-Google-Smtp-Source: AG47ELtPj3Jhc08SVbdSFlJm0hglTWch0KxEVP1n0KP63fB7hfYdPPplwjsObsxbjJhTULmqcIpX X-Received: by 10.101.102.79 with SMTP id z15mr8887690pgv.181.1520931109759; Tue, 13 Mar 2018 01:51:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520931109; cv=none; d=google.com; s=arc-20160816; b=fAFQ6Z/ihYtvJWfBUsoC0AS/FJFHI9/3sjTC8eAAVbCgKeU+5X9Ekj0vY055BT25Jn 1LUU4YdeBxC9unPQyuLS5WOqmgX7St4PcXD1qo58eKiYfFhDSaCAfJ38oTZFNI8DECu5 kBd6nng9EhvMf3DDLq+knThzZyh4zrDer69nSiN99kIpSp3qjbNJjcBmboyUGLw43dqM c4l1QIs440UHeYUDKnyKlYMhhiss3SbayOQQTVzf0IZQb0fVxmPnhDWdH3j7fzcmfvOs HCZSGyOKIEMjt+FHQPFQS/NB0n0f5dm6GAZPBWHc7HsZOM5dfUHJaWdEwD3sT6W0i9wt UvIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=yaaQe1QbK0kulScV4s/hADy7VTr4VrZvSfoC5+5W5CM=; b=V/VFTGYtbtut82f/GY8VuwB1QCovB/iftOFmmEJtYJxhQZJ2NdZXdS+e3Bg3CFFrsA XqLwanyR56Va2bwpjmVxHNWCjaZFX6qwlfv6pmv4aVhgQZwsk/zUWyIgQ6whY1TqPi2v IzeWvDqUfvOfP1ZRZ9XVcdeXXDnU3i17vH0hGq7eiGFZ2vyL+I8qOSyuIzl/9zD8i7r5 iqlb4BbpI1fHMktvp/Tvx5TjhsO11tYNT1nYmgVliJpv72jBFY+OUxDPwwFI6rUnh/Xk D3jVVQHEpOHJTtlVr6N2p+xlTqxOJMxQavsBYOLvIUhZ39lF1BqgCq8B9nHskZGSAMdE Ew3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=OPnZaM5i; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l63-v6si7523537plb.7.2018.03.13.01.51.35; Tue, 13 Mar 2018 01:51:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=OPnZaM5i; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752587AbeCMItl (ORCPT + 99 others); Tue, 13 Mar 2018 04:49:41 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:33394 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752003AbeCMIti (ORCPT ); Tue, 13 Mar 2018 04:49:38 -0400 Received: by mail-pf0-f194.google.com with SMTP id q13so5580389pff.0 for ; Tue, 13 Mar 2018 01:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yaaQe1QbK0kulScV4s/hADy7VTr4VrZvSfoC5+5W5CM=; b=OPnZaM5ijwxvrPp15fuYOjnJvmMYBPKwBJACiPEy4QF4cMwWD59uGhX47UoDP8R4cP wnyWpRIAl0ZRrX/ox5dlRTUrLWOkpGEkk8RFa2K17vdDl5UguZZ8g/9kHU5pPfgivkkg 8pB1w2iyyM+Wlroq/7llWhXF/s6/FyDXrpBfuPjZ4UKsqtH+5bqHMdK/iL0hw7S4IYmL SKf9mOEYDi88sc3VZHxdDrUlJkRYdJvfcvc3SHBuedAjb4w63C+6Gm66nOIrofwtkpy8 xkqieqKuq5vs0BzpbOtQZqroXdrg+1+4EtTeVpEKcfXIfhlVbCZ49sSYmRzOi2Qe6Va8 ScKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yaaQe1QbK0kulScV4s/hADy7VTr4VrZvSfoC5+5W5CM=; b=j6r5+j0me6Xa9BfKgRyyq6a0RxmN+4DaTuag/QVPbjnfrOVxmcxrle+5aGqKluGO/F CqM0UIsJhuD8A1ro/CUeDqXJKkYxIZsoR8xG2lj3ETxXiuXRlIhYKGA60AD/BSlaPOm3 92O92gwBxhYb3xJs5lAGZj8aEzie6xr3a9wlgRKmoZGeXuLGX/z//McsqIjRMeDi5MHZ xQX7cyO4fjb3UzvpwAzR7Ae6k9hDiY/AIW4ZtyaO8aG9gP6jlVEL/22CoapRGVvKhptF 8H6e9tY7qSSitYV23qsi2N7/4283V7JXaYklx9LaYtEfTt4dU6pT+0nLoPHftfnDWH2w yrxg== X-Gm-Message-State: AElRT7HLqpl8XrdjLQ/c9fDogqXonjlXXIZm/A5wUKzXfCiKa/x8EVqB 77z65VlqE9LxDV+MWvlm2Nud+KmD4eIqruuQ4zzQC3yXk1k= X-Received: by 10.98.152.86 with SMTP id q83mr10894401pfd.218.1520930977818; Tue, 13 Mar 2018 01:49:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.141.12 with HTTP; Tue, 13 Mar 2018 01:49:17 -0700 (PDT) In-Reply-To: References: <201803122219.vHl3IwRo%fengguang.wu@intel.com> From: Dmitry Vyukov Date: Tue, 13 Mar 2018 11:49:17 +0300 Message-ID: Subject: Re: [tip:locking/core 9/11] include/asm-generic/atomic-instrumented.h:288:24: sparse: cast truncates bits from constant value (100 becomes 0) To: kbuild test robot Cc: kbuild-all@01.org, LKML , tipbuild@zytor.com, Ingo Molnar , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 12, 2018 at 6:17 PM, Dmitry Vyukov wrote: > On Mon, Mar 12, 2018 at 5:52 PM, kbuild test robot > wrote: >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core >> head: ac605bee0bfab40fd5d11964705e907d2d5a32de >> commit: 8bf705d130396e69c04cd8e6e010244ad2ce71f4 [9/11] locking/atomic/x86: Switch atomic.h to use atomic-instrumented.h >> reproduce: >> # apt-get install sparse >> git checkout 8bf705d130396e69c04cd8e6e010244ad2ce71f4 >> make ARCH=x86_64 allmodconfig >> make C=1 CF=-D__CHECK_ENDIAN__ >> >> >> sparse warnings: (new ones prefixed by >>) >> >> kernel/locking/qspinlock.c:418:22: sparse: incorrect type in assignment (different modifiers) @@ expected struct mcs_spinlock *prev @@ got struct struct mcs_spinlock *prev @@ >> kernel/locking/qspinlock.c:418:22: expected struct mcs_spinlock *prev >> kernel/locking/qspinlock.c:418:22: got struct mcs_spinlock [pure] * >> kernel/locking/qspinlock_paravirt.h:519:1: sparse: symbol '__pv_queued_spin_unlock_slowpath' was not declared. Should it be static? >> kernel/locking/qspinlock.c:418:22: sparse: incorrect type in assignment (different modifiers) @@ expected struct mcs_spinlock *prev @@ got struct struct mcs_spinlock *prev @@ >> kernel/locking/qspinlock.c:418:22: expected struct mcs_spinlock *prev >> kernel/locking/qspinlock.c:418:22: got struct mcs_spinlock [pure] * >>>> include/asm-generic/atomic-instrumented.h:288:24: sparse: cast truncates bits from constant value (100 becomes 0) >> >> vim +288 include/asm-generic/atomic-instrumented.h >> >> b06ed71a6 Dmitry Vyukov 2018-01-29 282 >> b06ed71a6 Dmitry Vyukov 2018-01-29 283 static __always_inline unsigned long >> b06ed71a6 Dmitry Vyukov 2018-01-29 284 cmpxchg_size(volatile void *ptr, unsigned long old, unsigned long new, int size) >> b06ed71a6 Dmitry Vyukov 2018-01-29 285 { >> b06ed71a6 Dmitry Vyukov 2018-01-29 286 switch (size) { >> b06ed71a6 Dmitry Vyukov 2018-01-29 287 case 1: >> b06ed71a6 Dmitry Vyukov 2018-01-29 @288 return arch_cmpxchg((u8 *)ptr, (u8)old, (u8)new); >> b06ed71a6 Dmitry Vyukov 2018-01-29 289 case 2: >> b06ed71a6 Dmitry Vyukov 2018-01-29 290 return arch_cmpxchg((u16 *)ptr, (u16)old, (u16)new); >> b06ed71a6 Dmitry Vyukov 2018-01-29 291 case 4: >> b06ed71a6 Dmitry Vyukov 2018-01-29 292 return arch_cmpxchg((u32 *)ptr, (u32)old, (u32)new); >> b06ed71a6 Dmitry Vyukov 2018-01-29 293 case 8: >> b06ed71a6 Dmitry Vyukov 2018-01-29 294 BUILD_BUG_ON(sizeof(unsigned long) != 8); >> b06ed71a6 Dmitry Vyukov 2018-01-29 295 return arch_cmpxchg((u64 *)ptr, (u64)old, (u64)new); >> b06ed71a6 Dmitry Vyukov 2018-01-29 296 } >> b06ed71a6 Dmitry Vyukov 2018-01-29 297 BUILD_BUG(); >> b06ed71a6 Dmitry Vyukov 2018-01-29 298 return 0; >> b06ed71a6 Dmitry Vyukov 2018-01-29 299 } >> b06ed71a6 Dmitry Vyukov 2018-01-29 300 >> >> :::::: The code at line 288 was first introduced by commit >> :::::: b06ed71a624ba088a3e3e3ac7d4185f48c7c1660 locking/atomic, asm-generic: Add asm-generic/atomic-instrumented.h >> >> :::::: TO: Dmitry Vyukov >> :::::: CC: Ingo Molnar > > > I will take a look tomorrow. It seems that this is due to this guy: static __always_inline int trylock_clear_pending(struct qspinlock *lock) { struct __qspinlock *l = (void *)lock; return !READ_ONCE(l->locked) && (cmpxchg_acquire(&l->locked_pending, _Q_PENDING_VAL, _Q_LOCKED_VAL) == _Q_PENDING_VAL); } _Q_PENDING_VAL is 0x100. However, locked_pending is 2 bytes. So it seems that compiler checks all switch cases, this inevitably will lead to such warnings. Any suggestion on how to resolve this? Leave as is? Off the top of my head I can think of the following solution: switch (size) { case 1: return arch_cmpxchg((u8 *)ptr, (u8)(old * (size != 1)), (u8)(new * (size != 1))); case 2: return arch_cmpxchg((u16 *)ptr, (u16)(old * (size != 2)), (u16)(new * (size != 2))); But it's too ugly. FTR, the following was helpful to find invocations with particular size: #define cmpxchg(ptr, old, new) \ ({ \ + BUILD_BUG_ON(sizeof(*(ptr)) == 1); \ ((__typeof__(*(ptr)))cmpxchg_size((ptr), (unsigned long)(old), \ (unsigned long)(new), sizeof(*(ptr)))); \ })