All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harry Yoo <harry.yoo@oracle.com>
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>, linux-mm@kvack.org
Subject: Re: [bug report] percpu: Wire up cmpxchg128
Date: Tue, 8 Apr 2025 20:57:32 +0900	[thread overview]
Message-ID: <Z_UPLNgijpNw9xRW@harry> (raw)
In-Reply-To: <f20564a5-ca69-412d-94b7-9184fcbcda95@stanley.mountain>

On Tue, Apr 08, 2025 at 02:03:11PM +0300, Dan Carpenter wrote:
> Hello Peter Zijlstra,
> 
> This code is old, and so it must work.  I can't explain why the warning
> is only showing up now.  I was just curious what's going on.
> 
> Commit 6d12c8d308e6 ("percpu: Wire up cmpxchg128") from May 31, 2023
> (linux-next), leads to the following Smatch static checker warning:
> 
> 	mm/slub.c:3609 __update_cpu_freelist_fast()
> 	warn: sizeof(void)
> 
> mm/slub.c
>     3599 
>     3600 #ifndef CONFIG_SLUB_TINY
>     3601 static inline bool
>     3602 __update_cpu_freelist_fast(struct kmem_cache *s,
>     3603                            void *freelist_old, void *freelist_new,
>     3604                            unsigned long tid)
>     3605 {
>     3606         freelist_aba_t old = { .freelist = freelist_old, .counter = tid };
>     3607         freelist_aba_t new = { .freelist = freelist_new, .counter = next_tid(tid) };
>     3608 
> --> 3609         return this_cpu_try_cmpxchg_freelist(s->cpu_slab->freelist_tid.full,
>     3610                                              &old.full, new.full);
>     3611 }
> 
> The problem is:
> 
> arch/arm64/include/asm/percpu.h
>    239  #define this_cpu_cmpxchg128(pcp, o, n)                                  \
>    240  ({                                                                      \
>    241          typedef typeof(pcp) pcp_op_T__;                                 \
>    242          u128 old__, new__, ret__;                                       \
>    243          pcp_op_T__ *ptr__;                                              \
>    244          old__ = o;                                                      \
>    245          new__ = n;                                                      \
>    246          preempt_disable_notrace();                                      \
>    247          ptr__ = raw_cpu_ptr(&(pcp));                                    \
>    248          ret__ = cmpxchg128_local((void *)ptr__, old__, new__);          \
>                                          ^^^^^^^^^^^^^^
> We're passing a void pointer.
> 
>    249          preempt_enable_notrace();                                       \
>    250          ret__;                                                          \
>    251  })
> 
> include/linux/atomic/atomic-instrumented.h
>   5034  #define try_cmpxchg128_local(ptr, oldp, ...) \
>   5035  ({ \
>   5036          typeof(ptr) __ai_ptr = (ptr); \
>   5037          typeof(oldp) __ai_oldp = (oldp); \
>   5038          instrument_atomic_read_write(__ai_ptr, sizeof(*__ai_ptr)); \
>                                                        ^^^^^^^^^^^^^^^^^
> Here we're doing a sizeof() of a void pointer which is 1.  I think maybe
> this is just for KASAN so it's not a big deal in terms of affecting
> runtime?

As far as I can tell,

instrument_* helpers are used to let KASAN/KCSAN/KMSAN check if there are
bugs (e.g., KASAN checks shadow memory and determine if this read or write
is a memory access violation).

When enabled, usually the compiler automatically inserts those checks into
the kernel binary. But those helpers are used where the compiler can't.

I argue that not being able to precisely catch memory errors for
cmpxchg128 users (SLUB and few drivers) has not been a critical
problem.

But it'd be better to fix it :)

> 
>   5039          instrument_read_write(__ai_oldp, sizeof(*__ai_oldp)); \
>   5040          raw_try_cmpxchg128_local(__ai_ptr, __ai_oldp, __VA_ARGS__); \
>   5041  })
> 
> 
> regards,
> dan carpenter
> 

-- 
Cheers,
Harry (formerly known as Hyeonggon)


      reply	other threads:[~2025-04-08 11:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-08 11:03 [bug report] percpu: Wire up cmpxchg128 Dan Carpenter
2025-04-08 11:57 ` Harry Yoo [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=Z_UPLNgijpNw9xRW@harry \
    --to=harry.yoo@oracle.com \
    --cc=dan.carpenter@linaro.org \
    --cc=linux-mm@kvack.org \
    --cc=peterz@infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.