Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

[Arnd Bergmann]

On Sat, Dec 12, 2020 at 9:01 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Sat, Dec 12 2020 at 13:26, Marco Elver wrote:
> > On Thu, Mar 07, 2019 at 10:14AM +0100, Arnd Bergmann wrote:
> >> -static void __init futex_detect_cmpxchg(void)
> >> +static noinline void futex_detect_cmpxchg(void)
> >>  {
> >>  #ifndef CONFIG_HAVE_FUTEX_CMPXCHG
> >>      u32 curval;
> >
> > What ever happened to this patch?
>
> It obviously fell through the cracks.
>
> > I'm seeing this again with the attached config + next-20201211 (for
> > testing https://bugs.llvm.org/show_bug.cgi?id=48492). Had to apply this
> > patch to build the kernel.
>
> What really bothers me is to remove the __init from a function which is
> clearly only used during init. And looking deeper it's simply a hack.
>
> This function is only needed when an architecture has to runtime
> discover whether the CPU supports it or not. ARM has unconditional
> support for this, so the obvious thing to do is the below.
>

Ah perfect, that is clearly the right solution here.

> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -86,6 +86,7 @@ config ARM
>         select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
>         select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG
>         select HAVE_FUNCTION_TRACER if !XIP_KERNEL
> +       select HAVE_FUTEX_CMPXCHG if FUTEX
>         select HAVE_GCC_PLUGINS
>         select HAVE_HW_BREAKPOINT if PERF_EVENTS && (CPU_V6 || CPU_V6K || CPU_V7)
>         select HAVE_IDE if PCI || ISA || PCMCIA

I had a look at what other architectures always implement
futex_atomic_cmpxchg_inatomic() or can use the asm-generic non-SMP version,
and I found that it's pretty much all of them, the odd ones being just sparc32
and csky, which use asm-generic/futex.h but do have an SMP option,
as well as xtensa

I would guess that for csky, this is a mistake, as the architecture is fairly
new and should be able to implement it. Not sure about sparc32.

       Arnd

Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

[Guo Ren]

Hi Arnd,

On Mon, Dec 14, 2020 at 9:15 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Sat, Dec 12, 2020 at 9:01 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > On Sat, Dec 12 2020 at 13:26, Marco Elver wrote:
> > > On Thu, Mar 07, 2019 at 10:14AM +0100, Arnd Bergmann wrote:
> > >> -static void __init futex_detect_cmpxchg(void)
> > >> +static noinline void futex_detect_cmpxchg(void)
> > >>  {
> > >>  #ifndef CONFIG_HAVE_FUTEX_CMPXCHG
> > >>      u32 curval;
> > >
> > > What ever happened to this patch?
> >
> > It obviously fell through the cracks.
> >
> > > I'm seeing this again with the attached config + next-20201211 (for
> > > testing https://bugs.llvm.org/show_bug.cgi?id=48492). Had to apply this
> > > patch to build the kernel.
> >
> > What really bothers me is to remove the __init from a function which is
> > clearly only used during init. And looking deeper it's simply a hack.
> >
> > This function is only needed when an architecture has to runtime
> > discover whether the CPU supports it or not. ARM has unconditional
> > support for this, so the obvious thing to do is the below.
> >
>
> Ah perfect, that is clearly the right solution here.
>
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -86,6 +86,7 @@ config ARM
> >         select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
> >         select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG
> >         select HAVE_FUNCTION_TRACER if !XIP_KERNEL
> > +       select HAVE_FUTEX_CMPXCHG if FUTEX
> >         select HAVE_GCC_PLUGINS
> >         select HAVE_HW_BREAKPOINT if PERF_EVENTS && (CPU_V6 || CPU_V6K || CPU_V7)
> >         select HAVE_IDE if PCI || ISA || PCMCIA
>
> I had a look at what other architectures always implement
> futex_atomic_cmpxchg_inatomic() or can use the asm-generic non-SMP version,
> and I found that it's pretty much all of them, the odd ones being just sparc32
> and csky, which use asm-generic/futex.h but do have an SMP option,
> as well as xtensa
>
> I would guess that for csky, this is a mistake, as the architecture is fairly
> new and should be able to implement it. Not sure about sparc32.

The c610, c807, c810 don't support SMP, so futex_cmpxchg_enabled = 1
with asm-generic's implementation.
For c860, there is no HAVE_FUTEX_CMPXCHG and cmpxchg_inatomic/inuser
implementation, so futex_cmpxchg_enabled = 0.

Thx for point it out, we'll implement cmpxchg_inatomic/inuser for C860
and still use asm-generic for non-smp CPUs:

diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
index a2189c0..e968c58 100644
--- a/arch/csky/Kconfig
+++ b/arch/csky/Kconfig
@@ -49,6 +49,7 @@ config CSKY
        select HAVE_FUNCTION_TRACER
        select HAVE_FUNCTION_GRAPH_TRACER
        select HAVE_FUNCTION_ERROR_INJECTION
+       select HAVE_FUTEX_CMPXCHG if FUTEX && SMP
        select HAVE_FTRACE_MCOUNT_RECORD
        select HAVE_KERNEL_GZIP
        select HAVE_KERNEL_LZO
diff --git a/arch/csky/include/asm/futex.h b/arch/csky/include/asm/futex.h
new file mode 100644
index 00000000..29275e8
--- /dev/null
+++ b/arch/csky/include/asm/futex.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __ASM_CSKY_FUTEX_H
+#define __ASM_CSKY_FUTEX_H
+
+#ifndef CONFIG_SMP
+#include <asm-generic/futex.h>
+#else
+#include <linux/futex.h>
+#include <linux/uaccess.h>
+#include <linux/errno.h>
+
+static inline int
+arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
+{
+       int oldval = 0, ret = 0;
+
+       if (!access_ok(uaddr, sizeof(u32)))
+               return -EFAULT;
+
+       <...>
+
+       return ret;
+}
+
+static inline int
+futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
+                             u32 oldval, u32 newval)
+{
+       int ret = 0;
+       u32 val;
+       uintptr_t tmp;
+
+       if (!access_ok(uaddr, sizeof(u32)))
+               return -EFAULT;
+
+       <...>
+
+       return ret;
+}
+#endif
+#endif /* __ASM_CSKY_FUTEX_H */
-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/

Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

[Arnd Bergmann]

On Tue, Dec 15, 2020 at 7:09 AM Guo Ren <guoren@kernel.org> wrote:
> On Mon, Dec 14, 2020 at 9:15 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > I had a look at what other architectures always implement
> > futex_atomic_cmpxchg_inatomic() or can use the asm-generic non-SMP version,
> > and I found that it's pretty much all of them, the odd ones being just sparc32
> > and csky, which use asm-generic/futex.h but do have an SMP option,
> > as well as xtensa
> >
> > I would guess that for csky, this is a mistake, as the architecture is fairly
> > new and should be able to implement it. Not sure about sparc32.
>
> The c610, c807, c810 don't support SMP, so futex_cmpxchg_enabled = 1
> with asm-generic's implementation.
> For c860, there is no HAVE_FUTEX_CMPXCHG and cmpxchg_inatomic/inuser
> implementation, so futex_cmpxchg_enabled = 0.
>
> Thx for point it out, we'll implement cmpxchg_inatomic/inuser for C860
> and still use asm-generic for non-smp CPUs.

Sounds good to me.

With that, I would suggest we actually remove the -ENOSYS fallback
for arch_futex_atomic_op_inuser() and futex_atomic_cmpxchg_inatomic()
in asm-generic/futex.h as well as the HAVE_FUTEX_CMPXCHG Kconfig
symbol, plus these additional fixups:

- for xtensa and mips configurations without ll/sc, fall back to the
  asm-generic version. These are all uniprocessor, while the
  corresponding SMP machines have a working
  arch_futex_atomic_op_inuser().

- Disable SMP support for sun4m/sun4d. From the historic git
  tree, it's unclear how well this ever worked, and very few machines
  of this class ever existed

- Mark SMP for LEON as temporarily broken. As I see in the LEON
  patch set, they have changes to enable compare-and-swap-atomic
  instructions unconditionally, as all SMP Leons have those and
  seem to require this support already for other things.

         Arnd

Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

[Sam Ravnborg]

Hi Arnd,

On Tue, Dec 15, 2020 at 12:26:10PM +0100, Arnd Bergmann wrote:
> On Tue, Dec 15, 2020 at 7:09 AM Guo Ren <guoren@kernel.org> wrote:
> > On Mon, Dec 14, 2020 at 9:15 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > I had a look at what other architectures always implement
> > > futex_atomic_cmpxchg_inatomic() or can use the asm-generic non-SMP version,
> > > and I found that it's pretty much all of them, the odd ones being just sparc32
> > > and csky, which use asm-generic/futex.h but do have an SMP option,
> > > as well as xtensa
> > >
> > > I would guess that for csky, this is a mistake, as the architecture is fairly
> > > new and should be able to implement it. Not sure about sparc32.
> >
> > The c610, c807, c810 don't support SMP, so futex_cmpxchg_enabled = 1
> > with asm-generic's implementation.
> > For c860, there is no HAVE_FUTEX_CMPXCHG and cmpxchg_inatomic/inuser
> > implementation, so futex_cmpxchg_enabled = 0.
> >
> > Thx for point it out, we'll implement cmpxchg_inatomic/inuser for C860
> > and still use asm-generic for non-smp CPUs.
> 
> Sounds good to me.
> 
> With that, I would suggest we actually remove the -ENOSYS fallback
> for arch_futex_atomic_op_inuser() and futex_atomic_cmpxchg_inatomic()
> in asm-generic/futex.h as well as the HAVE_FUTEX_CMPXCHG Kconfig
> symbol, plus these additional fixups:
> 
> - for xtensa and mips configurations without ll/sc, fall back to the
>   asm-generic version. These are all uniprocessor, while the
>   corresponding SMP machines have a working
>   arch_futex_atomic_op_inuser().
> 
> - Disable SMP support for sun4m/sun4d. From the historic git
>   tree, it's unclear how well this ever worked, and very few machines
>   of this class ever existed
Yeah, I have collection of sparc32 machines that I played around with
once. Including one sun4d that I brought from a friendly Linux fellow in
the UK. But somehow I lost interest as this is all very nice machines
but not useful for anything real work.

I think we would be better served dropping support for sun4m and sun4d
from the kernel.

Last I suggested deleting sun4m/sun4d the argument to keep sun4m was that
QEMU supports sun4m - which is a good argument for sun4m. I dunno what
would be needed to migrate QEMU to LEON, see below.

> 
> - Mark SMP for LEON as temporarily broken. As I see in the LEON
>   patch set, they have changes to enable compare-and-swap-atomic
>   instructions unconditionally, as all SMP Leons have those and
>   seem to require this support already for other things.
LEON on the other hand could have some nice future. They are right now
stuck on an older kernel and someone that was motivated should be able
to get LEON4 running on latest upstream.
We had it working in the past - but is was around the time I lost my
sparc interest and no-one jumped in to move it much more forward.

So in other words - no complains for the plan you outline.

	Sam

Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

[Arnd Bergmann]

On Tue, Dec 15, 2020 at 8:38 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> On Tue, Dec 15, 2020 at 12:26:10PM +0100, Arnd Bergmann wrote:
> >
> > - Disable SMP support for sun4m/sun4d. From the historic git
> >   tree, it's unclear how well this ever worked, and very few machines
> >   of this class ever existed
> Yeah, I have collection of sparc32 machines that I played around with
> once. Including one sun4d that I brought from a friendly Linux fellow in
> the UK. But somehow I lost interest as this is all very nice machines
> but not useful for anything real work.
>
> I think we would be better served dropping support for sun4m and sun4d
> from the kernel.

This seems appropriate as well to me.

> Last I suggested deleting sun4m/sun4d the argument to keep sun4m was that
> QEMU supports sun4m - which is a good argument for sun4m. I dunno what
> would be needed to migrate QEMU to LEON, see below.

"qemu-system-sparc -M help" shows a "leon3_generic" platform, apparently
added in 2013. Do you think that would be sufficient?

> > - Mark SMP for LEON as temporarily broken. As I see in the LEON
> >   patch set, they have changes to enable compare-and-swap-atomic
> >   instructions unconditionally, as all SMP Leons have those and
> >   seem to require this support already for other things.
> LEON on the other hand could have some nice future. They are right now
> stuck on an older kernel and someone that was motivated should be able
> to get LEON4 running on latest upstream.
> We had it working in the past - but is was around the time I lost my
> sparc interest and no-one jumped in to move it much more forward.

My best guess from the public information I could find on LEON is that
it keeps shifting away from Linux on LEON to other OSs, and to
and to Linux on NOEL-V.

So even though the CPU itself will likely have a long life ahead of it
with LEON5 only a year old, it's unclear how many more updates
we'll see to the kernel from the current 4.9 based release.

> So in other words - no complains for the plan you outline.

Thanks. I'd probably queue up a patch in my asm-generic tree for
v5.12 to disable SMP on all SPARC32, add the helpers for C-Sky
once Guo Ren has tested a patch, and clean up the futex code based
on this. I guess we want the one-line fix for Arm that Thomas suggested
for v5.10 and backports anyway, The sun4m/sun4d removal should
clearly be discussed separately and go through the sparc tree, to see
if anyone has objections, or if we want to remove other obsolete
platforms (sun3?) along with it.

      Arnd

RE: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

[David Laight]

From: Sam Ravnborg
> Sent: 15 December 2020 19:38
> 
> Hi Arnd,
> 
> On Tue, Dec 15, 2020 at 12:26:10PM +0100, Arnd Bergmann wrote:
> > On Tue, Dec 15, 2020 at 7:09 AM Guo Ren <guoren@kernel.org> wrote:
...
> > - Disable SMP support for sun4m/sun4d. From the historic git
> >   tree, it's unclear how well this ever worked, and very few machines
> >   of this class ever existed
> Yeah, I have collection of sparc32 machines that I played around with
> once. Including one sun4d that I brought from a friendly Linux fellow in
> the UK. But somehow I lost interest as this is all very nice machines
> but not useful for anything real work.

ICL made a few SMP sparc32 systems.
I think the first ones used the original Cypress cpu running at 25MHz.
(I'm fairly sure these were SMP-capable, the later 40MHz definitely were.)
These were full sized VMEbus beasts.
Somewhere I've got a 32MByte memory board - over a square foot of board.
The memory is all 64k by 1 with all the pins on one edge and the chips vertical.
Really looks as though it should glow red and be used for cooking toast.
Even with 4 of those you're not going to run anything modern!

There were also some later mbus+sbus systems with dual sbus!
Designed by Fujitsu.

None of these ever ran solaris.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

[Peter Zijlstra]

On Tue, Dec 15, 2020 at 12:26:10PM +0100, Arnd Bergmann wrote:
> On Tue, Dec 15, 2020 at 7:09 AM Guo Ren <guoren@kernel.org> wrote:
> > On Mon, Dec 14, 2020 at 9:15 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > I had a look at what other architectures always implement
> > > futex_atomic_cmpxchg_inatomic() or can use the asm-generic non-SMP version,
> > > and I found that it's pretty much all of them, the odd ones being just sparc32
> > > and csky, which use asm-generic/futex.h but do have an SMP option,
> > > as well as xtensa
> > >
> > > I would guess that for csky, this is a mistake, as the architecture is fairly
> > > new and should be able to implement it. Not sure about sparc32.
> >
> > The c610, c807, c810 don't support SMP, so futex_cmpxchg_enabled = 1
> > with asm-generic's implementation.
> > For c860, there is no HAVE_FUTEX_CMPXCHG and cmpxchg_inatomic/inuser
> > implementation, so futex_cmpxchg_enabled = 0.
> >
> > Thx for point it out, we'll implement cmpxchg_inatomic/inuser for C860
> > and still use asm-generic for non-smp CPUs.
> 
> Sounds good to me.
> 
> With that, I would suggest we actually remove the -ENOSYS fallback
> for arch_futex_atomic_op_inuser() and futex_atomic_cmpxchg_inatomic()
> in asm-generic/futex.h as well as the HAVE_FUTEX_CMPXCHG Kconfig
> symbol, plus these additional fixups:
> 
> - for xtensa and mips configurations without ll/sc, fall back to the
>   asm-generic version. These are all uniprocessor, while the
>   corresponding SMP machines have a working
>   arch_futex_atomic_op_inuser().
> 
> - Disable SMP support for sun4m/sun4d. From the historic git
>   tree, it's unclear how well this ever worked, and very few machines
>   of this class ever existed

Hooray!! what about PA-RISC ? Can we burn that too?

Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

[Andreas Larsson]

On 2020-12-16 00:24, Arnd Bergmann wrote:
> On Tue, Dec 15, 2020 at 8:38 PM Sam Ravnborg <sam@ravnborg.org> wrote:
>> On Tue, Dec 15, 2020 at 12:26:10PM +0100, Arnd Bergmann wrote:
>>>
>>> - Disable SMP support for sun4m/sun4d. From the historic git
>>>    tree, it's unclear how well this ever worked, and very few machines
>>>    of this class ever existed
>> Yeah, I have collection of sparc32 machines that I played around with
>> once. Including one sun4d that I brought from a friendly Linux fellow in
>> the UK. But somehow I lost interest as this is all very nice machines
>> but not useful for anything real work.
>>
>> I think we would be better served dropping support for sun4m and sun4d
>> from the kernel.
> 
> This seems appropriate as well to me.
> 
>> Last I suggested deleting sun4m/sun4d the argument to keep sun4m was that
>> QEMU supports sun4m - which is a good argument for sun4m. I dunno what
>> would be needed to migrate QEMU to LEON, see below.
> 
> "qemu-system-sparc -M help" shows a "leon3_generic" platform, apparently
> added in 2013. Do you think that would be sufficient?

We have only use QEMU for LEON3 on limited and simpler system
setups. For example the Zephyr SPARC arch + LEON3 BSP port we recently
submitted to the Linux Foundation Zephyr project run their test-suite
successfully on QEMU+LEON3. We will have to look into the QEMU for LEON
and Linux situation.

We mainly use TSIM that is our own high fidelity simulator.


>>> - Mark SMP for LEON as temporarily broken. As I see in the LEON
>>>    patch set, they have changes to enable compare-and-swap-atomic
>>>    instructions unconditionally, as all SMP Leons have those and
>>>    seem to require this support already for other things.
Regarding unconditional compare-and-swap-atomic instructions (CASA) for
LEON. I tried to get those into mainline under the LEON configuration
option but did not get OK for that at that time, with the feedback to do
it dynamically instead. I haven't come around to try to get an updated
patch doing probing instead into mainline yet. If the thought now is to
drop support for SMP for sparc32, maybe we can have the CASA
unconditionally on SMP configured kernels instead. Still we'd like to
have CASA usage even for non-SMP kernels for LEON systems that supports
it.


>> LEON on the other hand could have some nice future. They are right now
>> stuck on an older kernel and someone that was motivated should be able
>> to get LEON4 running on latest upstream.
>> We had it working in the past - but is was around the time I lost my
>> sparc interest and no-one jumped in to move it much more forward.

I would not say that we are stuck on an old kernel. It is rather that
for our official releases we stay on long term support kernels. We still
aim for kernels based on master to work on LEON. Right now we do have a
bit of backlog of things to get into upstream.


> My best guess from the public information I could find on LEON is that
> it keeps shifting away from Linux on LEON to other OSs, and to
> and to Linux on NOEL-V.

On the contrary. Our LEON users shows an increased interest in running
Linux, now that LEON-based systems gains in number of processors,
processor performance and memory. We are adding NOEL as a new processor
line. With NOEL we have a 64-bit architecture. We are not shifting from
LEON to NOEL. LEON is not going away.

>
> So even though the CPU itself will likely have a long life ahead of it
> with LEON5 only a year old, it's unclear how many more updates
> we'll see to the kernel from the current 4.9 based release.

Our latest release was indeed based on 4.9, but we have no plans to stay
there forever. We just tend to select long term support kernels for our
official releases. The next step will be to go to 5.4 if not 5.10.

We recently released a new Linux 4.9 toolchain where we stepped up to
GLIBC 2.31 and GCC 10.2. So we do not consider us stuck at old versions
of any of the involved software.

In addition, non-LTS users are running other mainline kernel versions
as well.


Best regards,

Andreas Larsson
Software Engineer
Cobham Gaisler

Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

[Arnd Bergmann]

On Thu, Dec 17, 2020 at 4:32 PM Andreas Larsson <andreas@gaisler.com> wrote:
> On 2020-12-16 00:24, Arnd Bergmann wrote:
> > On Tue, Dec 15, 2020 at 8:38 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> >> On Tue, Dec 15, 2020 at 12:26:10PM +0100, Arnd Bergmann wrote:
> >>>
> >>> - Disable SMP support for sun4m/sun4d. From the historic git
> >>>    tree, it's unclear how well this ever worked, and very few machines
> >>>    of this class ever existed
> >> Yeah, I have collection of sparc32 machines that I played around with
> >> once. Including one sun4d that I brought from a friendly Linux fellow in
> >> the UK. But somehow I lost interest as this is all very nice machines
> >> but not useful for anything real work.
> >>
> >> I think we would be better served dropping support for sun4m and sun4d
> >> from the kernel.
> >
> > This seems appropriate as well to me.
> >
> >> Last I suggested deleting sun4m/sun4d the argument to keep sun4m was that
> >> QEMU supports sun4m - which is a good argument for sun4m. I dunno what
> >> would be needed to migrate QEMU to LEON, see below.
> >
> > "qemu-system-sparc -M help" shows a "leon3_generic" platform, apparently
> > added in 2013. Do you think that would be sufficient?
>
> We have only use QEMU for LEON3 on limited and simpler system
> setups. For example the Zephyr SPARC arch + LEON3 BSP port we recently
> submitted to the Linux Foundation Zephyr project run their test-suite
> successfully on QEMU+LEON3. We will have to look into the QEMU for LEON
> and Linux situation.
>
> We mainly use TSIM that is our own high fidelity simulator.

I don't think there is a need to have many features supported in qemu,
as long as you have enough RAM, block and network devices (which
are trivial if you have PCI or USB).

> >>> - Mark SMP for LEON as temporarily broken. As I see in the LEON
> >>>    patch set, they have changes to enable compare-and-swap-atomic
> >>>    instructions unconditionally, as all SMP Leons have those and
> >>>    seem to require this support already for other things.
>
> Regarding unconditional compare-and-swap-atomic instructions (CASA) for
> LEON. I tried to get those into mainline under the LEON configuration
> option but did not get OK for that at that time, with the feedback to do
> it dynamically instead. I haven't come around to try to get an updated
> patch doing probing instead into mainline yet. If the thought now is to
> drop support for SMP for sparc32, maybe we can have the CASA
> unconditionally on SMP configured kernels instead. Still we'd like to
> have CASA usage even for non-SMP kernels for LEON systems that
> supports it.

It does make sense to require that a single kernel can work on all
possible hardware. So if we remove sun4m/sun4d support, all that
is left is LEON, and you likely wouldn't need to worry about other
CPUs any more.

However, there is still the question whether a single kernel needs
to work on LEON both with and without CASA. Do you still care
about Linux users on LEON cores that do not support CASA, or is
widespread enough that you just make it unconditional for both
SMP and non-SMP?

> >> LEON on the other hand could have some nice future. They are right now
> >> stuck on an older kernel and someone that was motivated should be able
> >> to get LEON4 running on latest upstream.
> >> We had it working in the past - but is was around the time I lost my
> >> sparc interest and no-one jumped in to move it much more forward.
>
> I would not say that we are stuck on an old kernel. It is rather that
> for our official releases we stay on long term support kernels. We still
> aim for kernels based on master to work on LEON. Right now we do have a
> bit of backlog of things to get into upstream.

Ok, good to hear. There were a couple of old bugs that got found
on mainline that made me wonder whether mainline sparc32 was
used on any hardware at all these days.

I looked at your v4.9 patches and didn't see anything too scary
there, in particular once sparc32 becomes leon-only, you no longer
have to worry about making it work across different CPUs.

> > My best guess from the public information I could find on LEON is that
> > it keeps shifting away from Linux on LEON to other OSs, and to
> > and to Linux on NOEL-V.
>
> On the contrary. Our LEON users shows an increased interest in running
> Linux, now that LEON-based systems gains in number of processors,
> processor performance and memory. We are adding NOEL as a new processor
> line. With NOEL we have a 64-bit architecture. We are not shifting from
> LEON to NOEL. LEON is not going away.

Ok.

> > So even though the CPU itself will likely have a long life ahead of it
> > with LEON5 only a year old, it's unclear how many more updates
> > we'll see to the kernel from the current 4.9 based release.
>
> Our latest release was indeed based on 4.9, but we have no plans to stay
> there forever. We just tend to select long term support kernels for our
> official releases. The next step will be to go to 5.4 if not 5.10.

I hope that you can make it to 5.10 then, as this contains the work
I did for 64-bit time_t, which is required if you have users that want to
run systems after 2038.

> We recently released a new Linux 4.9 toolchain where we stepped up to
> GLIBC 2.31 and GCC 10.2. So we do not consider us stuck at old versions
> of any of the involved software.
>
> In addition, non-LTS users are running other mainline kernel versions
> as well.

FWIW, glibc-2.31 does not have support for 64-bit time_t yet, but I
know there was interest in adding sparc support to the musl libc, which
does support 64-bit time_t.

        Arnd

Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

[Sam Ravnborg]

Hi Arnd,

> > I think we would be better served dropping support for sun4m and sun4d
> > from the kernel.
> 
> This seems appropriate as well to me.

I did a quick hack:
20 files changed, 40 insertions(+), 3051 deletions(-)

All the leon stuff is kept and there is room for more cleaning up.
The kernel can build a sparc32_defconfig with the Gaisler toochain.
This was a one hour quick hack that I cannot commit - it needs to be
split up to allow some resemble of review.

And it touched only arch/sparc/ - no sparc32 specific drivers were
dropped.

If we decide to chase this and we can drop sun4m/sun4d then maintaining
leon will be simpler as a nice side effect.

	Sam

Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

[Andreas Larsson]

On 2020-12-17 17:43, Arnd Bergmann wrote:
> It does make sense to require that a single kernel can work on all
> possible hardware. So if we remove sun4m/sun4d support, all that
> is left is LEON, and you likely wouldn't need to worry about other
> CPUs any more.
> 
> However, there is still the question whether a single kernel needs
> to work on LEON both with and without CASA. Do you still care
> about Linux users on LEON cores that do not support CASA, or is
> widespread enough that you just make it unconditional for both
> SMP and non-SMP?

We are fine with unconditional CASA for both SMP and non-SMP for LEON.


> I hope that you can make it to 5.10 then, as this contains the work
> I did for 64-bit time_t, which is required if you have users that want to
> run systems after 2038.

That is a good point! Thank you!


> FWIW, glibc-2.31 does not have support for 64-bit time_t yet, but I
> know there was interest in adding sparc support to the musl libc, which
> does support 64-bit time_t.

Yes, we will have to follow the developments regarding 64-bit time_t
in GLIBC as well.

-- 
Andreas

Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

[Guo Ren]

Hi Arnd,

On Tue, Dec 15, 2020 at 7:26 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Tue, Dec 15, 2020 at 7:09 AM Guo Ren <guoren@kernel.org> wrote:
> > On Mon, Dec 14, 2020 at 9:15 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > I had a look at what other architectures always implement
> > > futex_atomic_cmpxchg_inatomic() or can use the asm-generic non-SMP version,
> > > and I found that it's pretty much all of them, the odd ones being just sparc32
> > > and csky, which use asm-generic/futex.h but do have an SMP option,
> > > as well as xtensa
> > >
> > > I would guess that for csky, this is a mistake, as the architecture is fairly
> > > new and should be able to implement it. Not sure about sparc32.
> >
> > The c610, c807, c810 don't support SMP, so futex_cmpxchg_enabled = 1
> > with asm-generic's implementation.
> > For c860, there is no HAVE_FUTEX_CMPXCHG and cmpxchg_inatomic/inuser
> > implementation, so futex_cmpxchg_enabled = 0.
> >
> > Thx for point it out, we'll implement cmpxchg_inatomic/inuser for C860
> > and still use asm-generic for non-smp CPUs.
>
> Sounds good to me.
Done: https://lore.kernel.org/linux-csky/1608478763-60148-3-git-send-email-guoren@kernel.org/T/#u

-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/

Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

[Arnd Bergmann]

On Sun, Dec 20, 2020 at 4:46 PM Guo Ren <guoren@kernel.org> wrote:
> On Tue, Dec 15, 2020 at 7:26 PM Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > On Tue, Dec 15, 2020 at 7:09 AM Guo Ren <guoren@kernel.org> wrote:
> > > On Mon, Dec 14, 2020 at 9:15 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > > I had a look at what other architectures always implement
> > > > futex_atomic_cmpxchg_inatomic() or can use the asm-generic non-SMP version,
> > > > and I found that it's pretty much all of them, the odd ones being just sparc32
> > > > and csky, which use asm-generic/futex.h but do have an SMP option,
> > > > as well as xtensa
> > > >
> > > > I would guess that for csky, this is a mistake, as the architecture is fairly
> > > > new and should be able to implement it. Not sure about sparc32.
> > >
> > > The c610, c807, c810 don't support SMP, so futex_cmpxchg_enabled = 1
> > > with asm-generic's implementation.
> > > For c860, there is no HAVE_FUTEX_CMPXCHG and cmpxchg_inatomic/inuser
> > > implementation, so futex_cmpxchg_enabled = 0.
> > >
> > > Thx for point it out, we'll implement cmpxchg_inatomic/inuser for C860
> > > and still use asm-generic for non-smp CPUs.
> >
> > Sounds good to me.
> Done: https://lore.kernel.org/linux-csky/1608478763-60148-3-git-send-email-guoren@kernel.org/T/#u

Thanks!

Can you clarify if there are any dependencies on the other patches in
that series?

I'd like to take the futex patch through the asm-generic tree along with the
patches for the other architectures.

       Arnd

Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

[Guo Ren]

Hi Arnd,

On Mon, Dec 21, 2020 at 1:49 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Sun, Dec 20, 2020 at 4:46 PM Guo Ren <guoren@kernel.org> wrote:
> > On Tue, Dec 15, 2020 at 7:26 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > >
> > > On Tue, Dec 15, 2020 at 7:09 AM Guo Ren <guoren@kernel.org> wrote:
> > > > On Mon, Dec 14, 2020 at 9:15 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > > > I had a look at what other architectures always implement
> > > > > futex_atomic_cmpxchg_inatomic() or can use the asm-generic non-SMP version,
> > > > > and I found that it's pretty much all of them, the odd ones being just sparc32
> > > > > and csky, which use asm-generic/futex.h but do have an SMP option,
> > > > > as well as xtensa
> > > > >
> > > > > I would guess that for csky, this is a mistake, as the architecture is fairly
> > > > > new and should be able to implement it. Not sure about sparc32.
> > > >
> > > > The c610, c807, c810 don't support SMP, so futex_cmpxchg_enabled = 1
> > > > with asm-generic's implementation.
> > > > For c860, there is no HAVE_FUTEX_CMPXCHG and cmpxchg_inatomic/inuser
> > > > implementation, so futex_cmpxchg_enabled = 0.
> > > >
> > > > Thx for point it out, we'll implement cmpxchg_inatomic/inuser for C860
> > > > and still use asm-generic for non-smp CPUs.
> > >
> > > Sounds good to me.
> > Done: https://lore.kernel.org/linux-csky/1608478763-60148-3-git-send-email-guoren@kernel.org/T/#u
>
> Thanks!
>
> Can you clarify if there are any dependencies on the other patches in
> that series?
No dependency.

>
> I'd like to take the futex patch through the asm-generic tree along with the
> patches for the other architectures.
You take the futex patch and I'll remove it from my tree.

-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/