[PATCH v2 net] net: Fix sk->sk_stamp race in sock_recv_cmsgs().

[PATCH v2 net] net: Fix sk->sk_stamp race in sock_recv_cmsgs().

[Kuniyuki Iwashima]

KCSAN found a data race in sock_recv_cmsgs() [0] where the read access
to sk->sk_stamp needs READ_ONCE().

Also, there is another race like below.  If the torn load of the high
32-bits precedes WRITE_ONCE(sk, skb->tstamp) and later the written
lower 32-bits happens to match with SK_DEFAULT_STAMP, the final result
of sk->sk_stamp could be 0.

  sock_recv_cmsgs()  ioctl(SIOCGSTAMP)      sock_recv_cmsgs()
  |                  |                      |
  |- if (sock_flag(sk, SOCK_TIMESTAMP))     |
  |                  |                      |
  |                  `- sock_set_flag(sk, SOCK_TIMESTAMP)
  |                                         |
  |                                          `- if (sock_flag(sk, SOCK_TIMESTAMP))
  `- if (sk->sk_stamp == SK_DEFAULT_STAMP)      `- sock_write_timestamp(sk, skb->tstamp)
      `- sock_write_timestamp(sk, 0)

Even with READ_ONCE(), we could get the same result if READ_ONCE() precedes
WRITE_ONCE() because the SK_DEFAULT_STAMP check and WRITE_ONCE(sk_stamp, 0)
are not atomic.

Let's avoid the race by cmpxchg() on 64-bits architecture or seqlock on
32-bits machines.

[0]:
BUG: KCSAN: data-race in packet_recvmsg / packet_recvmsg

write (marked) to 0xffff88803c81f258 of 8 bytes by task 19171 on cpu 0:
 sock_write_timestamp include/net/sock.h:2670 [inline]
 sock_recv_cmsgs include/net/sock.h:2722 [inline]
 packet_recvmsg+0xb97/0xd00 net/packet/af_packet.c:3489
 sock_recvmsg_nosec net/socket.c:1019 [inline]
 sock_recvmsg+0x11a/0x130 net/socket.c:1040
 sock_read_iter+0x176/0x220 net/socket.c:1118
 call_read_iter include/linux/fs.h:1845 [inline]
 new_sync_read fs/read_write.c:389 [inline]
 vfs_read+0x5e0/0x630 fs/read_write.c:470
 ksys_read+0x163/0x1a0 fs/read_write.c:613
 __do_sys_read fs/read_write.c:623 [inline]
 __se_sys_read fs/read_write.c:621 [inline]
 __x64_sys_read+0x41/0x50 fs/read_write.c:621
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x72/0xdc

read to 0xffff88803c81f258 of 8 bytes by task 19183 on cpu 1:
 sock_recv_cmsgs include/net/sock.h:2721 [inline]
 packet_recvmsg+0xb64/0xd00 net/packet/af_packet.c:3489
 sock_recvmsg_nosec net/socket.c:1019 [inline]
 sock_recvmsg+0x11a/0x130 net/socket.c:1040
 sock_read_iter+0x176/0x220 net/socket.c:1118
 call_read_iter include/linux/fs.h:1845 [inline]
 new_sync_read fs/read_write.c:389 [inline]
 vfs_read+0x5e0/0x630 fs/read_write.c:470
 ksys_read+0x163/0x1a0 fs/read_write.c:613
 __do_sys_read fs/read_write.c:623 [inline]
 __se_sys_read fs/read_write.c:621 [inline]
 __x64_sys_read+0x41/0x50 fs/read_write.c:621
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x72/0xdc

value changed: 0xffffffffc4653600 -> 0x0000000000000000

Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 19183 Comm: syz-executor.5 Not tainted 6.3.0-rc7-02330-gca6270c12e20 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014

Fixes: 6c7c98bad488 ("sock: avoid dirtying sk_stamp, if possible")
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
---
v2:
  * Add Fixes tag

v1: https://lore.kernel.org/netdev/20230506022325.99106-1-kuniyu@amazon.com/
---
 include/net/sock.h | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/include/net/sock.h b/include/net/sock.h
index 8b7ed7167243..c2a8b799283e 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2671,6 +2671,20 @@ static inline void sock_write_timestamp(struct sock *sk, ktime_t kt)
 #endif
 }
 
+#define SK_DEFAULT_STAMP (-1L * NSEC_PER_SEC)
+
+static inline void sock_zero_timestamp(struct sock *sk)
+{
+#if BITS_PER_LONG==32
+	write_seqlock(&sk->sk_stamp_seq);
+	if (sk->sk_stamp == SK_DEFAULT_STAMP)
+		sk->sk_stamp = 0;
+	write_sequnlock(&sk->sk_stamp_seq);
+#else
+	cmpxchg(&sk->sk_stamp, SK_DEFAULT_STAMP, 0);
+#endif
+}
+
 void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
 			   struct sk_buff *skb);
 void __sock_recv_wifi_status(struct msghdr *msg, struct sock *sk,
@@ -2704,7 +2718,6 @@ sock_recv_timestamp(struct msghdr *msg, struct sock *sk, struct sk_buff *skb)
 void __sock_recv_cmsgs(struct msghdr *msg, struct sock *sk,
 		       struct sk_buff *skb);
 
-#define SK_DEFAULT_STAMP (-1L * NSEC_PER_SEC)
 static inline void sock_recv_cmsgs(struct msghdr *msg, struct sock *sk,
 				   struct sk_buff *skb)
 {
@@ -2718,8 +2731,8 @@ static inline void sock_recv_cmsgs(struct msghdr *msg, struct sock *sk,
 		__sock_recv_cmsgs(msg, sk, skb);
 	else if (unlikely(sock_flag(sk, SOCK_TIMESTAMP)))
 		sock_write_timestamp(sk, skb->tstamp);
-	else if (unlikely(sk->sk_stamp == SK_DEFAULT_STAMP))
-		sock_write_timestamp(sk, 0);
+	else
+		sock_zero_timestamp(sk);
 }
 
 void __sock_tx_timestamp(__u16 tsflags, __u8 *tx_flags);
-- 
2.30.2

Re: [PATCH v2 net] net: Fix sk->sk_stamp race in sock_recv_cmsgs().

[Eric Dumazet]

On Mon, May 8, 2023 at 6:58 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
>
> KCSAN found a data race in sock_recv_cmsgs() [0] where the read access
> to sk->sk_stamp needs READ_ONCE().
>
> Also, there is another race like below.  If the torn load of the high
> 32-bits precedes WRITE_ONCE(sk, skb->tstamp) and later the written
> lower 32-bits happens to match with SK_DEFAULT_STAMP, the final result
> of sk->sk_stamp could be 0.
>
>   sock_recv_cmsgs()  ioctl(SIOCGSTAMP)      sock_recv_cmsgs()
>   |                  |                      |
>   |- if (sock_flag(sk, SOCK_TIMESTAMP))     |
>   |                  |                      |
>   |                  `- sock_set_flag(sk, SOCK_TIMESTAMP)
>   |                                         |
>   |                                          `- if (sock_flag(sk, SOCK_TIMESTAMP))
>   `- if (sk->sk_stamp == SK_DEFAULT_STAMP)      `- sock_write_timestamp(sk, skb->tstamp)
>       `- sock_write_timestamp(sk, 0)
>
> Even with READ_ONCE(), we could get the same result if READ_ONCE() precedes
> WRITE_ONCE() because the SK_DEFAULT_STAMP check and WRITE_ONCE(sk_stamp, 0)
> are not atomic.
>
> Let's avoid the race by cmpxchg() on 64-bits architecture or seqlock on
> 32-bits machines.
>

I disagree. Please use WRITE_ONCE(), even if we know it is racy on 32bit.

sock_read_timestamp() and sock_write_timestamp() already are racy, and
we do not care.

Re: [PATCH v2 net] net: Fix sk->sk_stamp race in sock_recv_cmsgs().

[Kuniyuki Iwashima]

From: Eric Dumazet <edumazet@google.com>
Date: Mon, 8 May 2023 19:08:58 +0200
> On Mon, May 8, 2023 at 6:58 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
> >
> > KCSAN found a data race in sock_recv_cmsgs() [0] where the read access
> > to sk->sk_stamp needs READ_ONCE().
> >
> > Also, there is another race like below.  If the torn load of the high
> > 32-bits precedes WRITE_ONCE(sk, skb->tstamp) and later the written
> > lower 32-bits happens to match with SK_DEFAULT_STAMP, the final result
> > of sk->sk_stamp could be 0.
> >
> >   sock_recv_cmsgs()  ioctl(SIOCGSTAMP)      sock_recv_cmsgs()
> >   |                  |                      |
> >   |- if (sock_flag(sk, SOCK_TIMESTAMP))     |
> >   |                  |                      |
> >   |                  `- sock_set_flag(sk, SOCK_TIMESTAMP)
> >   |                                         |
> >   |                                          `- if (sock_flag(sk, SOCK_TIMESTAMP))
> >   `- if (sk->sk_stamp == SK_DEFAULT_STAMP)      `- sock_write_timestamp(sk, skb->tstamp)
> >       `- sock_write_timestamp(sk, 0)
> >
> > Even with READ_ONCE(), we could get the same result if READ_ONCE() precedes
> > WRITE_ONCE() because the SK_DEFAULT_STAMP check and WRITE_ONCE(sk_stamp, 0)
> > are not atomic.
> >
> > Let's avoid the race by cmpxchg() on 64-bits architecture or seqlock on
> > 32-bits machines.
> >
> 
> I disagree. Please use WRITE_ONCE(), even if we know it is racy on 32bit.
> 
> sock_read_timestamp() and sock_write_timestamp() already are racy, and
> we do not care.

I think it's not racy since commit 3a0ed3e96197 ("sock: Make sock->sk_stamp
thread-safe"), which introduced seqlock in sock_read_timestamp() and
sock_write_timestamp().

Re: [PATCH v2 net] net: Fix sk->sk_stamp race in sock_recv_cmsgs().

[Eric Dumazet]

On Mon, May 8, 2023 at 7:20 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
>
> From: Eric Dumazet <edumazet@google.com>
> Date: Mon, 8 May 2023 19:08:58 +0200
> > On Mon, May 8, 2023 at 6:58 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
> > >
> > > KCSAN found a data race in sock_recv_cmsgs() [0] where the read access
> > > to sk->sk_stamp needs READ_ONCE().
> > >
> > > Also, there is another race like below.  If the torn load of the high
> > > 32-bits precedes WRITE_ONCE(sk, skb->tstamp) and later the written
> > > lower 32-bits happens to match with SK_DEFAULT_STAMP, the final result
> > > of sk->sk_stamp could be 0.
> > >
> > >   sock_recv_cmsgs()  ioctl(SIOCGSTAMP)      sock_recv_cmsgs()
> > >   |                  |                      |
> > >   |- if (sock_flag(sk, SOCK_TIMESTAMP))     |
> > >   |                  |                      |
> > >   |                  `- sock_set_flag(sk, SOCK_TIMESTAMP)
> > >   |                                         |
> > >   |                                          `- if (sock_flag(sk, SOCK_TIMESTAMP))
> > >   `- if (sk->sk_stamp == SK_DEFAULT_STAMP)      `- sock_write_timestamp(sk, skb->tstamp)
> > >       `- sock_write_timestamp(sk, 0)
> > >
> > > Even with READ_ONCE(), we could get the same result if READ_ONCE() precedes
> > > WRITE_ONCE() because the SK_DEFAULT_STAMP check and WRITE_ONCE(sk_stamp, 0)
> > > are not atomic.
> > >
> > > Let's avoid the race by cmpxchg() on 64-bits architecture or seqlock on
> > > 32-bits machines.
> > >
> >
> > I disagree. Please use WRITE_ONCE(), even if we know it is racy on 32bit.
> >
> > sock_read_timestamp() and sock_write_timestamp() already are racy, and
> > we do not care.
>
> I think it's not racy since commit 3a0ed3e96197 ("sock: Make sock->sk_stamp
> thread-safe"), which introduced seqlock in sock_read_timestamp() and
> sock_write_timestamp().

Please note I do not care of 32bit.

It is definitely racy on 64bit.

Please look at

commit f75359f3ac855940c5718af10ba089b8977bf339
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Nov 4 21:38:43 2019 -0800

    net: prevent load/store tearing on sk->sk_stamp


We can not use cmpxchg() only in one place and not the others.

cmpxchg() is expensive, we do not want it here on our fast path.

Thanks.

Re: [PATCH v2 net] net: Fix sk->sk_stamp race in sock_recv_cmsgs().

[Kuniyuki Iwashima]

From: Eric Dumazet <edumazet@google.com>
Date: Mon, 8 May 2023 19:31:12 +0200
> On Mon, May 8, 2023 at 7:20 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
> >
> > From: Eric Dumazet <edumazet@google.com>
> > Date: Mon, 8 May 2023 19:08:58 +0200
> > > On Mon, May 8, 2023 at 6:58 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
> > > >
> > > > KCSAN found a data race in sock_recv_cmsgs() [0] where the read access
> > > > to sk->sk_stamp needs READ_ONCE().
> > > >
> > > > Also, there is another race like below.  If the torn load of the high
> > > > 32-bits precedes WRITE_ONCE(sk, skb->tstamp) and later the written
> > > > lower 32-bits happens to match with SK_DEFAULT_STAMP, the final result
> > > > of sk->sk_stamp could be 0.
> > > >
> > > >   sock_recv_cmsgs()  ioctl(SIOCGSTAMP)      sock_recv_cmsgs()
> > > >   |                  |                      |
> > > >   |- if (sock_flag(sk, SOCK_TIMESTAMP))     |
> > > >   |                  |                      |
> > > >   |                  `- sock_set_flag(sk, SOCK_TIMESTAMP)
> > > >   |                                         |
> > > >   |                                          `- if (sock_flag(sk, SOCK_TIMESTAMP))
> > > >   `- if (sk->sk_stamp == SK_DEFAULT_STAMP)      `- sock_write_timestamp(sk, skb->tstamp)
> > > >       `- sock_write_timestamp(sk, 0)
> > > >
> > > > Even with READ_ONCE(), we could get the same result if READ_ONCE() precedes
> > > > WRITE_ONCE() because the SK_DEFAULT_STAMP check and WRITE_ONCE(sk_stamp, 0)
> > > > are not atomic.
> > > >
> > > > Let's avoid the race by cmpxchg() on 64-bits architecture or seqlock on
> > > > 32-bits machines.
> > > >
> > >
> > > I disagree. Please use WRITE_ONCE(), even if we know it is racy on 32bit.
> > >
> > > sock_read_timestamp() and sock_write_timestamp() already are racy, and
> > > we do not care.
> >
> > I think it's not racy since commit 3a0ed3e96197 ("sock: Make sock->sk_stamp
> > thread-safe"), which introduced seqlock in sock_read_timestamp() and
> > sock_write_timestamp().
> 
> Please note I do not care of 32bit.
> 
> It is definitely racy on 64bit.
> 
> Please look at
> 
> commit f75359f3ac855940c5718af10ba089b8977bf339
> Author: Eric Dumazet <edumazet@google.com>
> Date:   Mon Nov 4 21:38:43 2019 -0800
> 
>     net: prevent load/store tearing on sk->sk_stamp
> 
> 
> We can not use cmpxchg() only in one place and not the others.

Ah, I understand.  I'll post v3 with this diff to silence KCSAN.

---8<---
diff --git a/include/net/sock.h b/include/net/sock.h
index 8b7ed7167243..656ea89f60ff 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2718,7 +2718,7 @@ static inline void sock_recv_cmsgs(struct msghdr *msg, struct sock *sk,
 		__sock_recv_cmsgs(msg, sk, skb);
 	else if (unlikely(sock_flag(sk, SOCK_TIMESTAMP)))
 		sock_write_timestamp(sk, skb->tstamp);
-	else if (unlikely(sk->sk_stamp == SK_DEFAULT_STAMP))
+	else if (unlikely(sock_read_timestamp(sk) == SK_DEFAULT_STAMP))
 		sock_write_timestamp(sk, 0);
 }
 
---8<---

Thank you!


> 
> cmpxchg() is expensive, we do not want it here on our fast path.
>
> Thanks.

Re: [PATCH v2 net] net: Fix sk->sk_stamp race in sock_recv_cmsgs().

[kernel test robot]

Hi Kuniyuki,

kernel test robot noticed the following build warnings:

[auto build test WARNING on net/main]

url:    https://github.com/intel-lab-lkp/linux/commits/Kuniyuki-Iwashima/net-Fix-sk-sk_stamp-race-in-sock_recv_cmsgs/20230509-005901
base:   net/main
patch link:    https://lore.kernel.org/r/20230508165815.45602-1-kuniyu%40amazon.com
patch subject: [PATCH v2 net] net: Fix sk->sk_stamp race in sock_recv_cmsgs().
config: alpha-randconfig-s033-20230507 (https://download.01.org/0day-ci/archive/20230509/202305091558.VRASfSNN-lkp@intel.com/config)
compiler: alpha-linux-gcc (GCC) 12.1.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # apt-get install sparse
        # sparse version: v0.6.4-39-gce1a6720-dirty
        # https://github.com/intel-lab-lkp/linux/commit/7755d082501de4c89033aed3be404114fcba1c44
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Kuniyuki-Iwashima/net-Fix-sk-sk_stamp-race-in-sock_recv_cmsgs/20230509-005901
        git checkout 7755d082501de4c89033aed3be404114fcba1c44
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=alpha olddefconfig
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=alpha SHELL=/bin/bash net/key/

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202305091558.VRASfSNN-lkp@intel.com/

sparse warnings: (new ones prefixed by >>)
   net/key/af_key.c: note: in included file (through arch/alpha/include/asm/cmpxchg.h, arch/alpha/include/asm/atomic.h, include/linux/atomic.h, ...):
>> arch/alpha/include/asm/xchg.h:234:32: sparse: sparse: cast truncates bits from constant value (ffffffffc4653600 becomes 0)
   arch/alpha/include/asm/xchg.h:236:32: sparse: sparse: cast truncates bits from constant value (ffffffffc4653600 becomes 3600)

vim +234 arch/alpha/include/asm/xchg.h

a6209d6d71f2ab Ivan Kokshaysky 2009-03-31  227  
a6209d6d71f2ab Ivan Kokshaysky 2009-03-31  228  static __always_inline unsigned long
a6209d6d71f2ab Ivan Kokshaysky 2009-03-31  229  ____cmpxchg(, volatile void *ptr, unsigned long old, unsigned long new,
a6209d6d71f2ab Ivan Kokshaysky 2009-03-31  230  	      int size)
a6209d6d71f2ab Ivan Kokshaysky 2009-03-31  231  {
a6209d6d71f2ab Ivan Kokshaysky 2009-03-31  232  	switch (size) {
a6209d6d71f2ab Ivan Kokshaysky 2009-03-31  233  		case 1:
a6209d6d71f2ab Ivan Kokshaysky 2009-03-31 @234  			return ____cmpxchg(_u8, ptr, old, new);
a6209d6d71f2ab Ivan Kokshaysky 2009-03-31  235  		case 2:
a6209d6d71f2ab Ivan Kokshaysky 2009-03-31  236  			return ____cmpxchg(_u16, ptr, old, new);
a6209d6d71f2ab Ivan Kokshaysky 2009-03-31  237  		case 4:
a6209d6d71f2ab Ivan Kokshaysky 2009-03-31  238  			return ____cmpxchg(_u32, ptr, old, new);
a6209d6d71f2ab Ivan Kokshaysky 2009-03-31  239  		case 8:
a6209d6d71f2ab Ivan Kokshaysky 2009-03-31  240  			return ____cmpxchg(_u64, ptr, old, new);
a6209d6d71f2ab Ivan Kokshaysky 2009-03-31  241  	}
a6209d6d71f2ab Ivan Kokshaysky 2009-03-31  242  	__cmpxchg_called_with_bad_pointer();
a6209d6d71f2ab Ivan Kokshaysky 2009-03-31  243  	return old;
a6209d6d71f2ab Ivan Kokshaysky 2009-03-31  244  }
a6209d6d71f2ab Ivan Kokshaysky 2009-03-31  245  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests

Re: [PATCH v2 net] net: Fix sk->sk_stamp race in sock_recv_cmsgs().

[kernel test robot]

Hi Kuniyuki,

kernel test robot noticed the following build warnings:

[auto build test WARNING on net/main]

url:    https://github.com/intel-lab-lkp/linux/commits/Kuniyuki-Iwashima/net-Fix-sk-sk_stamp-race-in-sock_recv_cmsgs/20230509-005901
base:   net/main
patch link:    https://lore.kernel.org/r/20230508165815.45602-1-kuniyu%40amazon.com
patch subject: [PATCH v2 net] net: Fix sk->sk_stamp race in sock_recv_cmsgs().
config: arm64-randconfig-s032-20230507 (https://download.01.org/0day-ci/archive/20230509/202305091519.TLuWISjA-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 12.1.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # apt-get install sparse
        # sparse version: v0.6.4-39-gce1a6720-dirty
        # https://github.com/intel-lab-lkp/linux/commit/7755d082501de4c89033aed3be404114fcba1c44
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Kuniyuki-Iwashima/net-Fix-sk-sk_stamp-race-in-sock_recv_cmsgs/20230509-005901
        git checkout 7755d082501de4c89033aed3be404114fcba1c44
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=arm64 olddefconfig
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=arm64 SHELL=/bin/bash drivers/firmware/tegra/ net/mctp/

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202305091519.TLuWISjA-lkp@intel.com/

sparse warnings: (new ones prefixed by >>)
   net/mctp/af_mctp.c: note: in included file (through arch/arm64/include/asm/atomic.h, include/linux/atomic.h, include/asm-generic/bitops/atomic.h, ...):
>> arch/arm64/include/asm/cmpxchg.h:174:1: sparse: sparse: cast truncates bits from constant value (ffffffffc4653600 becomes 0)
   arch/arm64/include/asm/cmpxchg.h:174:1: sparse: sparse: cast truncates bits from constant value (ffffffffc4653600 becomes 3600)

vim +174 arch/arm64/include/asm/cmpxchg.h

10b663aef1c247 Catalin Marinas 2012-03-05  170  
305d454aaa292b Will Deacon     2015-10-08  171  __CMPXCHG_GEN()
305d454aaa292b Will Deacon     2015-10-08  172  __CMPXCHG_GEN(_acq)
305d454aaa292b Will Deacon     2015-10-08  173  __CMPXCHG_GEN(_rel)
305d454aaa292b Will Deacon     2015-10-08 @174  __CMPXCHG_GEN(_mb)
10b663aef1c247 Catalin Marinas 2012-03-05  175  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests