All of lore.kernel.org
 help / color / mirror / Atom feed
From: "wuqiang.matt" <wuqiang.matt@bytedance.com>
To: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH] locking/atomic: sh: Use generic_cmpxchg_local for arch_cmpxchg_local()
Date: Wed, 25 Oct 2023 19:06:38 +0800	[thread overview]
Message-ID: <0f48e36b-b8c1-443a-f7c3-b9ddea2c503c@bytedance.com> (raw)
In-Reply-To: <efe7e4ad-6ee8-08c3-d43f-d7c54de04045@bytedance.com>

On 2023/10/25 09:51, wuqiang.matt wrote:
> On 2023/10/25 07:42, Masami Hiramatsu (Google) wrote:
>> On Tue, 24 Oct 2023 16:08:12 +0100
>> Mark Rutland <mark.rutland@arm.com> wrote:
>>
>>> On Tue, Oct 24, 2023 at 11:52:54PM +0900, Masami Hiramatsu (Google) wrote:
>>>> From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
>>>>
>>>> Use generic_cmpxchg_local() for arch_cmpxchg_local() implementation
>>>> in SH architecture because it does not implement arch_cmpxchg_local().
>>>
>>> I do not think this is correct.
>>>
>>> The implementation in <asm-generic/cmpxchg-local.h> is UP-only (and it only
>>> disables interrupts), whereas arch/sh can be built SMP. We should probably add
>>> some guards into <asm-generic/cmpxchg-local.h> for that as we have in
>>> <asm-generic/cmpxchg.h>.
>>
>> Isn't cmpxchg_local for the data which only needs to ensure to do cmpxchg
>> on local CPU?
> 
> asm-generic/cmpxchg.h is only for UP, will throw an error for SMP building:
> 
> #ifdef CONFIG_SMP
> #error "Cannot use generic cmpxchg on SMP"
> #endif

Sorry that I just noticed Masami's patch has asm-generic/cmpxchg-local.h
included, not asm-generic/cmpxchg.h. cmpxchg.h does throw an error for SMP
configs, but cmpxchg-local.h doesn't.

> SH arch seems it does have SMP systems. The arch/sh/include/asm/cmpxchg.h has
> the following codes:
> 
> #if defined(CONFIG_GUSA_RB)
> #include <asm/cmpxchg-grb.h>
> #elif defined(CONFIG_CPU_SH4A)
> #include <asm/cmpxchg-llsc.h>
> #elif defined(CONFIG_CPU_J2) && defined(CONFIG_SMP)
> #include <asm/cmpxchg-cas.h>
> #else
> #include <asm/cmpxchg-irq.h>
> #endif
> 
>> So I think it doesn't care about the other CPUs (IOW, it should not touched by
>> other CPUs), so it only considers UP case. E.g. on x86, arch_cmpxchg_local() is
>> defined as raw "cmpxchg" without lock prefix.
>>
>> #define __cmpxchg_local(ptr, old, new, size)                            \
>>          __raw_cmpxchg((ptr), (old), (new), (size), "")
>>
>>
>> Thank you,
>>
>>
>>>
>>> I think the right thing to do here is to define arch_cmpxchg_local() in terms
>>> of arch_cmpxchg(), i.e. at the bottom of arch/sh's <asm/cmpxchg.h> add:
>>>
>>> #define arch_cmpxchg_local              arch_cmpxchg
> 
> I agree too. Might not be performance optimized but guarantees correctness.
> 
>>> Mark.
>>>
>>>>
>>>> Reported-by: kernel test robot <lkp@intel.com>
>>>> Closes: 
>>>> https://lore.kernel.org/oe-kbuild-all/202310241310.Ir5uukOG-lkp@intel.com/
>>>> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
>>>> ---
>>>>   arch/sh/include/asm/cmpxchg.h |    2 ++
>>>>   1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/arch/sh/include/asm/cmpxchg.h b/arch/sh/include/asm/cmpxchg.h
>>>> index 288f6f38d98f..e920e61fb817 100644
>>>> --- a/arch/sh/include/asm/cmpxchg.h
>>>> +++ b/arch/sh/include/asm/cmpxchg.h
>>>> @@ -71,4 +71,6 @@ static inline unsigned long __cmpxchg(volatile void * 
>>>> ptr, unsigned long old,
>>>>                       (unsigned long)_n_, sizeof(*(ptr))); \
>>>>     })
>>>> +#include <asm-generic/cmpxchg-local.h>
>>>> +
>>>>   #endif /* __ASM_SH_CMPXCHG_H */
>>>>
>>
>>
> 


  reply	other threads:[~2023-10-25 11:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-24 14:52 [PATCH] locking/atomic: sh: Use generic_cmpxchg_local for arch_cmpxchg_local() Masami Hiramatsu (Google)
2023-10-24 15:08 ` Mark Rutland
2023-10-24 23:42   ` Masami Hiramatsu
2023-10-25  1:51     ` wuqiang.matt
2023-10-25 11:06       ` wuqiang.matt [this message]
2023-10-25 10:30     ` Mark Rutland
2023-10-25 10:32       ` John Paul Adrian Glaubitz
2023-10-25 13:16         ` Geert Uytterhoeven
2023-10-25 14:57           ` Masami Hiramatsu
2023-10-24 16:43 ` John Paul Adrian Glaubitz
2023-10-25 11:26 ` [External] " wuqiang.matt
2023-10-25 15:12   ` Masami Hiramatsu

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=0f48e36b-b8c1-443a-f7c3-b9ddea2c503c@bytedance.com \
    --to=wuqiang.matt@bytedance.com \
    --cc=dalias@libc.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mhiramat@kernel.org \
    --cc=peterz@infradead.org \
    --cc=ysato@users.sourceforge.jp \
    /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.