From: Al Viro <viro@zeniv.linux.org.uk>
To: kernel test robot <lkp@intel.com>
Cc: oe-kbuild-all@lists.linux.dev, linux-fsdevel@vger.kernel.org
Subject: Re: [viro-vfs:misc.cmpxchg 4/8] arch/sparc/include/asm/cmpxchg_32.h:51:61: sparse: sparse: cast truncates bits from constant value (eb9f becomes 9f)
Date: Tue, 2 Apr 2024 21:24:13 +0100 [thread overview]
Message-ID: <20240402202413.GH538574@ZenIV> (raw)
In-Reply-To: <202404030332.d8MKrNbM-lkp@intel.com>
On Wed, Apr 03, 2024 at 03:40:22AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git misc.cmpxchg
> head: 9e2f22ef1ae21b949a3903727d7e7cd5eb48810f
> commit: 1b2857f7277164d8bed4e831e3c3696572a51f0b [4/8] sparc32: add __cmpxchg_u{8,16}() and teach __cmpxchg() to handle those sizes
> config: sparc-randconfig-r132-20240403 (https://download.01.org/0day-ci/archive/20240403/202404030332.d8MKrNbM-lkp@intel.com/config)
> compiler: sparc-linux-gcc (GCC) 13.2.0
> reproduce: (https://download.01.org/0day-ci/archive/20240403/202404030332.d8MKrNbM-lkp@intel.com/reproduce)
> sparse warnings: (new ones prefixed by >>)
> kernel/bpf/helpers.c:2157:18: sparse: sparse: symbol 'bpf_task_release_dtor' was not declared. Should it be static?
> kernel/bpf/helpers.c:2187:18: sparse: sparse: symbol 'bpf_cgroup_release_dtor' was not declared. Should it be static?
> kernel/bpf/helpers.c: note: in included file (through arch/sparc/include/asm/cmpxchg.h, arch/sparc/include/asm/atomic_32.h, arch/sparc/include/asm/atomic.h, ...):
> >> arch/sparc/include/asm/cmpxchg_32.h:51:61: sparse: sparse: cast truncates bits from constant value (eb9f becomes 9f)
> kernel/bpf/helpers.c: note: in included file (through include/linux/timer.h, include/linux/workqueue.h, include/linux/bpf.h):
> include/linux/list.h:83:21: sparse: sparse: self-comparison always evaluates to true
> include/linux/list.h:83:21: sparse: sparse: self-comparison always evaluates to true
> kernel/bpf/helpers.c: note: in included file (through arch/sparc/include/asm/cmpxchg.h, arch/sparc/include/asm/atomic_32.h, arch/sparc/include/asm/atomic.h, ...):
> >> arch/sparc/include/asm/cmpxchg_32.h:51:61: sparse: sparse: cast truncates bits from constant value (eb9f becomes 9f)
> kernel/bpf/helpers.c:2495:18: sparse: sparse: context imbalance in 'bpf_rcu_read_lock' - wrong count at exit
> kernel/bpf/helpers.c:2500:18: sparse: sparse: context imbalance in 'bpf_rcu_read_unlock' - unexpected unlock
>
> vim +51 arch/sparc/include/asm/cmpxchg_32.h
>
> 44
> 45 /* don't worry...optimizer will get rid of most of this */
> 46 static inline unsigned long
> 47 __cmpxchg(volatile void *ptr, unsigned long old, unsigned long new_, int size)
> 48 {
> 49 switch (size) {
> 50 case 1:
> > 51 return __cmpxchg_u8((u8 *)ptr, (u8)old, (u8)new_);
> 52 case 2:
> 53 return __cmpxchg_u16((u16 *)ptr, (u16)old, (u16)new_);
> 54 case 4:
> 55 return __cmpxchg_u32((u32 *)ptr, (u32)old, (u32)new_);
> 56 default:
> 57 __cmpxchg_called_with_bad_pointer();
> 58 break;
> 59 }
> 60 return old;
> 61 }
... and calls are cmpxchg(&node->owner, NULL, BPF_PTR_POISON). IOW, that's
a false positive - size will be 4, not 1.
IMO it's a sparse bug; one way to work around that would've been
return
size == 1 ? __cmpxchg_u8(ptr, old, new_) :
size == 2 ? __cmpxchg_u16(ptr, old, new_) :
size == 4 ? __cmpxchg_u32(ptr, old, new_) :
(__cmpxchg_called_with_bad_pointer(), old);
instead of that switch - elimination of dead subexpressions *does* suppress
such warnings. Elimination of dead branches doesn't...
prev parent reply other threads:[~2024-04-02 20:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-02 19:40 [viro-vfs:misc.cmpxchg 4/8] arch/sparc/include/asm/cmpxchg_32.h:51:61: sparse: sparse: cast truncates bits from constant value (eb9f becomes 9f) kernel test robot
2024-04-02 20:24 ` Al Viro [this message]
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=20240402202413.GH538574@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=oe-kbuild-all@lists.linux.dev \
/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