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 09:51:09 +0800 [thread overview]
Message-ID: <efe7e4ad-6ee8-08c3-d43f-d7c54de04045@bytedance.com> (raw)
In-Reply-To: <20231025084255.bc70b9d0e5af9f6f3d2d4735@kernel.org>
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
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 */
>>>
>
>
next prev parent reply other threads:[~2023-10-25 1:51 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 [this message]
2023-10-25 11:06 ` wuqiang.matt
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=efe7e4ad-6ee8-08c3-d43f-d7c54de04045@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox