Re: [PATCH v3 1/4] iee754: provide gcc builtins based generic sqrt functions

2020-06-03 Thread Andreas Schwab 
s/iee754/ieee754/

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v3 1/4] iee754: provide gcc builtins based generic sqrt functions

2020-06-03 Thread Vineet Gupta 
On 6/3/20 1:46 AM, Andreas Schwab wrote:
> s/iee754/ieee754/

Fixed. Thx
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v3 1/4] iee754: provide gcc builtins based generic sqrt functions

2020-06-03 Thread Adhemerval Zanella 



On 03/06/2020 14:06, Vineet Gupta via Libc-alpha wrote:
> On 6/3/20 1:46 AM, Andreas Schwab wrote:
>> s/iee754/ieee754/
> 
> Fixed. Thx
> 

I think this patchset is ok, there is no need to send a v4. Do you 
need someone to push it upstream for you?

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v3 1/4] iee754: provide gcc builtins based generic sqrt functions

2020-06-03 Thread Vineet Gupta 
On 6/3/20 10:09 AM, Adhemerval Zanella via Libc-alpha wrote:
> I think this patchset is ok, there is no need to send a v4. Do you 
> need someone to push it upstream for you?

I do have write access to repo, I'll push it shortly.

Thx,
-Vineet
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v6 07/13] ARC: Linux Syscall Interface

2020-06-03 Thread Vineet Gupta 
On 5/29/20 9:49 AM, Adhemerval Zanella via Libc-alpha wrote:
>> +; - child starts here -
>> +
>> +; Setup TP register (only recent kernels v4.19+ do that)
>> +and.f   0, r12, CLONE_SETTLS
>> +mov.nz  r25, r9
> Do you still need to set it since the minimum supported kernel
> for ARC is 5.1 ?

Right.

> It should be safe for internal glibc usage, since for both pthread
> and posix_spawn it blocks all signals including SIGCANCEL and SIGXID.
> However this is still small race window if this is called directly 
> with pthread cancellation or g*uid in multithread.

I'm not sure what you mean above. Do you mean not doing this in glibc and even 
if
kernel support didn't exist should be safe internally ?

fwiw as mentioned above kernel sets up TP for clone (SETTLS). I detested doing
that for a long time, give ABI implications but ended up doing it anyways due to
an actual race hit when running uClibc tst-kill6 [1]

[1] http://lists.infradead.org/pipermail/linux-snps-arc/2018-October/004480.html
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v6 11/13] ARC: Build Infrastructure

2020-06-03 Thread Adhemerval Zanella 



On 22/04/2020 22:41, Vineet Gupta via Libc-alpha wrote:
> Signed-off-by: Vineet Gupta 

Some comments below.

> ---
>  config.h.in|   3 +
>  sysdeps/arc/Implies|   3 +
>  sysdeps/arc/Makefile   |  21 +++
>  sysdeps/arc/Versions   |   8 +
>  sysdeps/arc/configure  | 182 +
>  sysdeps/arc/configure.ac   |  26 +++
>  sysdeps/arc/nptl/Makefile  |  22 +++
>  sysdeps/arc/preconfigure   |  14 ++
>  sysdeps/unix/sysv/linux/arc/Implies|   3 +
>  sysdeps/unix/sysv/linux/arc/Makefile   |  29 
>  sysdeps/unix/sysv/linux/arc/Versions   |  16 ++
>  sysdeps/unix/sysv/linux/arc/configure  |   4 +
>  sysdeps/unix/sysv/linux/arc/configure.ac   |   4 +
>  sysdeps/unix/sysv/linux/arc/ldconfig.h |  27 +++
>  sysdeps/unix/sysv/linux/arc/shlib-versions |   7 +
>  15 files changed, 369 insertions(+)
>  create mode 100644 sysdeps/arc/Implies
>  create mode 100644 sysdeps/arc/Makefile
>  create mode 100644 sysdeps/arc/Versions
>  create mode 100644 sysdeps/arc/configure
>  create mode 100644 sysdeps/arc/configure.ac
>  create mode 100644 sysdeps/arc/nptl/Makefile
>  create mode 100644 sysdeps/arc/preconfigure
>  create mode 100644 sysdeps/unix/sysv/linux/arc/Implies
>  create mode 100644 sysdeps/unix/sysv/linux/arc/Makefile
>  create mode 100644 sysdeps/unix/sysv/linux/arc/Versions
>  create mode 100644 sysdeps/unix/sysv/linux/arc/configure
>  create mode 100644 sysdeps/unix/sysv/linux/arc/configure.ac
>  create mode 100644 sysdeps/unix/sysv/linux/arc/ldconfig.h
>  create mode 100644 sysdeps/unix/sysv/linux/arc/shlib-versions
> 
> diff --git a/config.h.in b/config.h.in
> index dea43df438f6..08962dfed075 100644
> --- a/config.h.in
> +++ b/config.h.in
> @@ -109,6 +109,9 @@
>  /* AArch64 big endian ABI */
>  #undef HAVE_AARCH64_BE
>  
> +/* ARC big endian ABI */
> +#undef HAVE_ARC_BE
> +

Why do you need this define exactly? It is not used anywhere in the code
and for C code if is more straightforwar to use endian.h.

>  /* C-SKY ABI version.  */
>  #undef CSKYABI
>  
> diff --git a/sysdeps/arc/Implies b/sysdeps/arc/Implies
> new file mode 100644
> index ..780c4e246769
> --- /dev/null
> +++ b/sysdeps/arc/Implies
> @@ -0,0 +1,3 @@
> +wordsize-32
> +ieee754/flt-32
> +ieee754/dbl-64

Ok.

> diff --git a/sysdeps/arc/Makefile b/sysdeps/arc/Makefile
> new file mode 100644
> index ..56ac503bfe43
> --- /dev/null
> +++ b/sysdeps/arc/Makefile
> @@ -0,0 +1,21 @@
> +# ARC Makefile
> +# Copyright (C) 1993-2020 Free Software Foundation, Inc.
> +# This file is part of the GNU C Library.
> +
> +# The GNU C Library is free software; you can redistribute it and/or
> +# modify it under the terms of the GNU Lesser General Public
> +# License as published by the Free Software Foundation; either
> +# version 2.1 of the License, or (at your option) any later version.
> +
> +# The GNU C Library is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +# Lesser General Public License for more details.
> +
> +# You should have received a copy of the GNU Lesser General Public
> +# License along with the GNU C Library.  If not, see
> +# .
> +
> +# We don't support long doubles as a distinct type.  We don't need to set
> +# this variable; it's here mostly for documentational purposes.
> +long-double-fcts = no

Ok.

> diff --git a/sysdeps/arc/Versions b/sysdeps/arc/Versions
> new file mode 100644
> index ..6ac7b8e49505
> --- /dev/null
> +++ b/sysdeps/arc/Versions
> @@ -0,0 +1,8 @@
> +libc {
> +  GLIBC_2.32 {
> +__mcount;
> +  }

Hum, does ARC require a different symbol name than the one provided
by gmon/Versions?

> +  GLIBC_PRIVATE {
> +__syscall_error;
> +  }
> +}
> diff --git a/sysdeps/arc/configure b/sysdeps/arc/configure
> new file mode 100644
> index ..5820017d6505
> --- /dev/null
> +++ b/sysdeps/arc/configure
> @@ -0,0 +1,182 @@
> +# This file is generated from configure.ac by Autoconf.  DO NOT EDIT!
> + # Local configure fragment for sysdeps/arc.
> +
> +$as_echo "#define PI_STATIC_AND_HIDDEN 1" >>confdefs.h
> +
> +libc_cv_have_sdata_section=no
> +
> +# For ARC, historically ; was used for comments and not newline
> +# Later # also got added to comment list, but ; couldn't be switched to
> +# canonical newline as there's lots of code out there which will break
> +libc_cv_asm_line_sep='`'
> +cat >>confdefs.h <<_ACEOF
> +#define ASM_LINE_SEP $libc_cv_asm_line_sep
> +_ACEOF
> +
> +
> +# For big endian ABI, generate a symbol for selecting right dynamic linker
> +
> +
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for grep that handles long 
> lines and -e" >&5
> +$as_echo_n "checking for grep that handles long lines and -e... "

Re: [PATCH v6 07/13] ARC: Linux Syscall Interface

2020-06-03 Thread Adhemerval Zanella 



On 03/06/2020 16:46, Vineet Gupta wrote:
> On 5/29/20 9:49 AM, Adhemerval Zanella via Libc-alpha wrote:
>>> +   ; - child starts here -
>>> +
>>> +   ; Setup TP register (only recent kernels v4.19+ do that)
>>> +   and.f   0, r12, CLONE_SETTLS
>>> +   mov.nz  r25, r9
>> Do you still need to set it since the minimum supported kernel
>> for ARC is 5.1 ?
> 
> Right.
> 
>> It should be safe for internal glibc usage, since for both pthread
>> and posix_spawn it blocks all signals including SIGCANCEL and SIGXID.
>> However this is still small race window if this is called directly 
>> with pthread cancellation or g*uid in multithread.
> 
> I'm not sure what you mean above. Do you mean not doing this in glibc and 
> even if
> kernel support didn't exist should be safe internally ?

At least for internal clone usage with CLONE_VM within glibc we explicit
disable all signals (posix_spawn and pthread_create).

> 
> fwiw as mentioned above kernel sets up TP for clone (SETTLS). I detested doing
> that for a long time, give ABI implications but ended up doing it anyways due 
> to
> an actual race hit when running uClibc tst-kill6 [1]

We explicit disable all signals during the create_thread call in pthread_create
(b3cae39dcbfa2432b3f3aa28854d8ac57f0de1b8), so it should not happen on glibc
anymore.  However it is still an issue if application calls clone itself.

> 
> [1] 
> http://lists.infradead.org/pipermail/linux-snps-arc/2018-October/004480.html
> 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v6 07/13] ARC: Linux Syscall Interface

2020-06-03 Thread Vineet Gupta 
On 6/3/20 1:04 PM, Adhemerval Zanella via Libc-alpha wrote:
> 
> 
> On 03/06/2020 16:46, Vineet Gupta wrote:
>> On 5/29/20 9:49 AM, Adhemerval Zanella via Libc-alpha wrote:
 +  ; - child starts here -
 +
 +  ; Setup TP register (only recent kernels v4.19+ do that)
 +  and.f   0, r12, CLONE_SETTLS
 +  mov.nz  r25, r9
>>> Do you still need to set it since the minimum supported kernel
>>> for ARC is 5.1 ?
>>
>> Right.
>>
>>> It should be safe for internal glibc usage, since for both pthread
>>> and posix_spawn it blocks all signals including SIGCANCEL and SIGXID.
>>> However this is still small race window if this is called directly 
>>> with pthread cancellation or g*uid in multithread.
>>
>> I'm not sure what you mean above. Do you mean not doing this in glibc and 
>> even if
>> kernel support didn't exist should be safe internally ?
> 
> At least for internal clone usage with CLONE_VM within glibc we explicit
> disable all signals (posix_spawn and pthread_create).
> 
>>
>> fwiw as mentioned above kernel sets up TP for clone (SETTLS). I detested 
>> doing
>> that for a long time, give ABI implications but ended up doing it anyways 
>> due to
>> an actual race hit when running uClibc tst-kill6 [1]
> 
> We explicit disable all signals during the create_thread call in 
> pthread_create
> (b3cae39dcbfa2432b3f3aa28854d8ac57f0de1b8), so it should not happen on glibc
> anymore.  However it is still an issue if application calls clone itself.

The scenario there was pthread_create() and parent getting scheduled before 
child
and immediately doing pthread_kill() causing child signal handler to be invoked
and signal handler doing pthread_self() which was broken as TP was not setup.

With commit above, parent pthread_kill() will block and will only run when child
is scheduled and unblocks the signals !
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

2020-06-03 Thread Andrew Morton 
On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny  wrote:

> > > 
> > > Actually it occurs to me that the patch consolidating kmap_prot is odd for
> > > sparc 32 bit...
> > > 
> > > Its a long shot but could you try reverting this patch?
> > > 
> > > 4ea7d2419e3f kmap: consolidate kmap_prot definitions
> > > 
> > 
> > That is not easy to revert, unfortunately, due to several follow-up patches.
> 
> I have gotten your sparc tests to run and they all pass...
> 
> 08:10:34 > ../linux-build-test/rootfs/sparc/run-qemu-sparc.sh 
> Build reference: v5.7-rc4-17-g852b6f2edc0f
> 
> Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed
> Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed
> Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed
> Building sparc32:SS-4:nosmp:initrd ... running . passed
> Building sparc32:SS-5:nosmp:scsi:hd ... running . passed
> Building sparc32:SS-10:nosmp:scsi:cd ... running . passed
> Building sparc32:SS-20:nosmp:scsi:hd ... running . passed
> Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed
> Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running . passed
> Building sparc32:SS-4:smp:scsi:hd ... running . passed
> Building sparc32:SS-5:smp:scsi:cd ... running . passed
> Building sparc32:SS-10:smp:scsi:hd ... running . passed
> Building sparc32:SS-20:smp:scsi:hd ... running . passed
> Building sparc32:SS-600MP:smp:scsi:hd ... running . passed
> Building sparc32:Voyager:smp:noapc:scsi:hd ... running . passed
> 
> Is there another test I need to run?

This all petered out, but as I understand it, this patchset still might
have issues on various architectures.

Can folks please provide an update on the testing status?

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

2020-06-03 Thread Ira Weiny 
On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote:
> On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny  wrote:
> 
> > > > 
> > > > Actually it occurs to me that the patch consolidating kmap_prot is odd 
> > > > for
> > > > sparc 32 bit...
> > > > 
> > > > Its a long shot but could you try reverting this patch?
> > > > 
> > > > 4ea7d2419e3f kmap: consolidate kmap_prot definitions
> > > > 
> > > 
> > > That is not easy to revert, unfortunately, due to several follow-up 
> > > patches.
> > 
> > I have gotten your sparc tests to run and they all pass...
> > 
> > 08:10:34 > ../linux-build-test/rootfs/sparc/run-qemu-sparc.sh 
> > Build reference: v5.7-rc4-17-g852b6f2edc0f
> > 
> > Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed
> > Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed
> > Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed
> > Building sparc32:SS-4:nosmp:initrd ... running . passed
> > Building sparc32:SS-5:nosmp:scsi:hd ... running . passed
> > Building sparc32:SS-10:nosmp:scsi:cd ... running . passed
> > Building sparc32:SS-20:nosmp:scsi:hd ... running . passed
> > Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed
> > Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running . passed
> > Building sparc32:SS-4:smp:scsi:hd ... running . passed
> > Building sparc32:SS-5:smp:scsi:cd ... running . passed
> > Building sparc32:SS-10:smp:scsi:hd ... running . passed
> > Building sparc32:SS-20:smp:scsi:hd ... running . passed
> > Building sparc32:SS-600MP:smp:scsi:hd ... running . passed
> > Building sparc32:Voyager:smp:noapc:scsi:hd ... running . passed
> > 
> > Is there another test I need to run?
> 
> This all petered out, but as I understand it, this patchset still might
> have issues on various architectures.
> 
> Can folks please provide an update on the testing status?

I believe the tests were failing for Guenter due to another patch set...[1]

My tests with just this series are working.

>From my understanding the other failures were unrelated.[2]


I've checked the patch above on top of the mmots which already has
Ira's patches and it booted fine. I've used sparc32_defconfig to build
the kernel and qemu-system-sparc with default machine and CPU.


Mike, am I wrong?  Do you think the kmap() patches are still causing issues?

Ira

[1] 
https://lore.kernel.org/lkml/2807e5fd2f6fda4886f6618eac48510e92eab...@crsmsx101.amr.corp.intel.com/
[2] https://lore.kernel.org/lkml/20200520195110.gh1118...@kernel.org/


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

2020-06-03 Thread Guenter Roeck 
On 6/3/20 2:14 PM, Ira Weiny wrote:
> On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote:
>> On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny  wrote:
>>
>>>>>
>>>>> Actually it occurs to me that the patch consolidating kmap_prot is odd for
>>>>> sparc 32 bit...
>>>>>
>>>>> Its a long shot but could you try reverting this patch?
>>>>>
>>>>> 4ea7d2419e3f kmap: consolidate kmap_prot definitions
>>>>>
>>>>
>>>> That is not easy to revert, unfortunately, due to several follow-up 
>>>> patches.
>>>
>>> I have gotten your sparc tests to run and they all pass...
>>>
>>> 08:10:34 > ../linux-build-test/rootfs/sparc/run-qemu-sparc.sh 
>>> Build reference: v5.7-rc4-17-g852b6f2edc0f
>>>
>>> Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed
>>> Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed
>>> Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed
>>> Building sparc32:SS-4:nosmp:initrd ... running . passed
>>> Building sparc32:SS-5:nosmp:scsi:hd ... running . passed
>>> Building sparc32:SS-10:nosmp:scsi:cd ... running . passed
>>> Building sparc32:SS-20:nosmp:scsi:hd ... running . passed
>>> Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed
>>> Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running . passed
>>> Building sparc32:SS-4:smp:scsi:hd ... running . passed
>>> Building sparc32:SS-5:smp:scsi:cd ... running . passed
>>> Building sparc32:SS-10:smp:scsi:hd ... running . passed
>>> Building sparc32:SS-20:smp:scsi:hd ... running . passed
>>> Building sparc32:SS-600MP:smp:scsi:hd ... running . passed
>>> Building sparc32:Voyager:smp:noapc:scsi:hd ... running . passed
>>>
>>> Is there another test I need to run?
>>
>> This all petered out, but as I understand it, this patchset still might
>> have issues on various architectures.
>>
>> Can folks please provide an update on the testing status?
> 
> I believe the tests were failing for Guenter due to another patch set...[1]
> 
> My tests with just this series are working.
> 
>>From my understanding the other failures were unrelated.[2]
> 
>   
>   I've checked the patch above on top of the mmots which already has
>   Ira's patches and it booted fine. I've used sparc32_defconfig to build
>   the kernel and qemu-system-sparc with default machine and CPU.
>   
> 
> Mike, am I wrong?  Do you think the kmap() patches are still causing issues?
> 

For my part, all I can say is that -next is in pretty bad shape right now.
The summary of my tests says:

Build results:
total: 151 pass: 130 fail: 21
Qemu test results:
total: 430 pass: 375 fail: 55

sparc32 smp images in next-20200603 still crash for me with a spinlock
recursion. s390 images hang early in boot. Several others (alpha, arm64,
various ppc) don't even compile. I can run some more bisects over time,
but this is becoming a full-time job :-(.

Guenter

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

2020-06-03 Thread Mike Rapoport 
On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
> On 6/3/20 2:14 PM, Ira Weiny wrote:
> > On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote:
> >> On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny  wrote:
> >>
> >>>>>
> >>>>> Actually it occurs to me that the patch consolidating kmap_prot is odd 
> >>>>> for
> >>>>> sparc 32 bit...
> >>>>>
> >>>>> Its a long shot but could you try reverting this patch?
> >>>>>
> >>>>> 4ea7d2419e3f kmap: consolidate kmap_prot definitions
> >>>>>
> >>>>
> >>>> That is not easy to revert, unfortunately, due to several follow-up 
> >>>> patches.
> >>>
> >>> I have gotten your sparc tests to run and they all pass...
> >>>
> >>> 08:10:34 > ../linux-build-test/rootfs/sparc/run-qemu-sparc.sh 
> >>> Build reference: v5.7-rc4-17-g852b6f2edc0f
> >>>
> >>> Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed
> >>> Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed
> >>> Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed
> >>> Building sparc32:SS-4:nosmp:initrd ... running . passed
> >>> Building sparc32:SS-5:nosmp:scsi:hd ... running . passed
> >>> Building sparc32:SS-10:nosmp:scsi:cd ... running . passed
> >>> Building sparc32:SS-20:nosmp:scsi:hd ... running . passed
> >>> Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed
> >>> Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running . passed
> >>> Building sparc32:SS-4:smp:scsi:hd ... running . passed
> >>> Building sparc32:SS-5:smp:scsi:cd ... running . passed
> >>> Building sparc32:SS-10:smp:scsi:hd ... running . passed
> >>> Building sparc32:SS-20:smp:scsi:hd ... running . passed
> >>> Building sparc32:SS-600MP:smp:scsi:hd ... running . passed
> >>> Building sparc32:Voyager:smp:noapc:scsi:hd ... running . passed
> >>>
> >>> Is there another test I need to run?
> >>
> >> This all petered out, but as I understand it, this patchset still might
> >> have issues on various architectures.
> >>
> >> Can folks please provide an update on the testing status?
> > 
> > I believe the tests were failing for Guenter due to another patch set...[1]
> > 
> > My tests with just this series are working.
> > 
> >>From my understanding the other failures were unrelated.[2]
> > 
> > 
> > I've checked the patch above on top of the mmots which already has
> > Ira's patches and it booted fine. I've used sparc32_defconfig to build
> > the kernel and qemu-system-sparc with default machine and CPU.
> > 
> > 
> > Mike, am I wrong?  Do you think the kmap() patches are still causing issues?

sparc32 UP and microblaze work for me with next-20200603, but I didn't
test other architectures. 
 
> For my part, all I can say is that -next is in pretty bad shape right now.
> The summary of my tests says:
> 
> Build results:
>   total: 151 pass: 130 fail: 21
> Qemu test results:
>   total: 430 pass: 375 fail: 55
> 
> sparc32 smp images in next-20200603 still crash for me with a spinlock
> recursion.

I think this is because Will's fixes [1] are not yet in -next.

> s390 images hang early in boot. Several others (alpha, arm64,
> various ppc) don't even compile. I can run some more bisects over time,
> but this is becoming a full-time job :-(.
> 
> Guenter

[1] https://lore.kernel.org/lkml/20200526173302.377-1-w...@kernel.org
-- 
Sincerely yours,
Mike.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

2020-06-03 Thread Ira Weiny 
On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
> On 6/3/20 2:14 PM, Ira Weiny wrote:
> > On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote:
> >> On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny  wrote:
> >>

...

> >>
> >> This all petered out, but as I understand it, this patchset still might
> >> have issues on various architectures.
> >>
> >> Can folks please provide an update on the testing status?
> > 
> > I believe the tests were failing for Guenter due to another patch set...[1]
> > 
> > My tests with just this series are working.
> > 
> >>From my understanding the other failures were unrelated.[2]
> > 
> > 
> > I've checked the patch above on top of the mmots which already has
> > Ira's patches and it booted fine. I've used sparc32_defconfig to build
> > the kernel and qemu-system-sparc with default machine and CPU.
> > 
> > 
> > Mike, am I wrong?  Do you think the kmap() patches are still causing issues?
> > 
> 
> For my part, all I can say is that -next is in pretty bad shape right now.
> The summary of my tests says:
> 
> Build results:
>   total: 151 pass: 130 fail: 21
> Qemu test results:
>   total: 430 pass: 375 fail: 55
> 
> sparc32 smp images in next-20200603 still crash for me with a spinlock
> recursion. s390 images hang early in boot. Several others (alpha, arm64,
> various ppc) don't even compile. I can run some more bisects over time,
> but this is becoming a full-time job :-(.
> 

I'm not sure what the process here is.  I just applied my series[1] on
Linus' Master branch[2] and ran sparc32 and s290 from your tests.

sparc32: (passes)

21:43:49 > /home/iweiny/dev/linux-build-test/rootfs/sparc/run-qemu-sparc.sh 
Build reference: v5.7-7188-g67a7a97e8a0f

Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed
Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed
Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed
Building sparc32:SS-4:nosmp:initrd ... running . passed
Building sparc32:SS-5:nosmp:scsi:hd ... running . passed
Building sparc32:SS-10:nosmp:scsi:cd ... running . passed
Building sparc32:SS-20:nosmp:scsi:hd ... running . passed
Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed
Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running ..  passed
Building sparc32:SS-4:smp:scsi:hd ... running . passed
Building sparc32:SS-5:smp:scsi:cd ... running . passed
Building sparc32:SS-10:smp:scsi:hd ... running . passed
Building sparc32:SS-20:smp:scsi:hd ... running . passed
Building sparc32:SS-600MP:smp:scsi:hd ... running . passed
Building sparc32:Voyager:smp:noapc:scsi:hd ... running . passed


s390: (does not compile)

:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
In file included from ./arch/sparc/include/asm/bug.h:6:0,
 from ./include/linux/bug.h:5,
 from ./include/linux/mmdebug.h:5,
 from ./include/linux/mm.h:9,
 from mm/huge_memory.c:8:
mm/huge_memory.c: In function 'hugepage_init':
./include/linux/compiler.h:403:38: error: call to '__compiletime_assert_127' 
declared with attribute error: BUILD_BUG_ON failed: ((13 + (13-3))-13) >= 9
  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
  ^
./include/linux/compiler.h:384:4: note: in definition of macro 
'__compiletime_assert'
prefix ## suffix();\
^~
./include/linux/compiler.h:403:2: note: in expansion of macro 
'_compiletime_assert'
  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
  ^~~
./include/linux/build_bug.h:39:37: note: in expansion of macro 
'compiletime_assert'
 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
 ^~
./include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
  ^~~~
./include/linux/bug.h:24:4: note: in expansion of macro 'BUILD_BUG_ON'
BUILD_BUG_ON(cond); \
^~~~
mm/huge_memory.c:403:2: note: in expansion of macro 'MAYBE_BUILD_BUG_ON'
  MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER >= MAX_ORDER);
  ^~
make[1]: *** [scripts/Makefile.build:267: mm/huge_memory.o] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:1735: mm] Error 2
make: *** Waiting for unfinished jobs



The s390 error is the same on Linus' master and linux-next.  So wha

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

2020-06-03 Thread Mike Rapoport 
On Wed, Jun 03, 2020 at 11:22:26PM -0700, Ira Weiny wrote:
> On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
> 
> With linux-next on sparc I too see the spinlock issue; something like:
> 
> ...
> Starting syslogd: BUG: spinlock recursion on CPU#0, S01syslogd/139
>  lock: 0xf53ef350, .magic: dead4ead, .owner: S01syslogd/139, .owner_cpu: 0
> CPU: 0 PID: 139 Comm: S01syslogd Not tainted 5.7.0-next-20200603 #1
> [f0067d00 : 
> do_raw_spin_lock+0xa8/0xd8 ] 
> [f00d598c : 
> copy_page_range+0x328/0x804 ] 
> [f0025c34 : 
> dup_mm+0x334/0x434 ] 
> [f0027198 : 
> copy_process+0x1248/0x12d4 ] 
> [f00273b8 : 
> _do_fork+0x54/0x30c ] 
> [f00276e4 : 
> do_fork+0x5c/0x6c ] 
> [f000de44 : 
> sparc_do_fork+0x18/0x38 ] 
> [f000b7f4 : 
> do_syscall+0x34/0x40 ] 
> [5010cd4c : 
> 0x5010cd4c ] 
> 
> 
> I'm going to bisect between there and HEAD.

The sparc issue should be fixed by 

https://lore.kernel.org/lkml/20200526173302.377-1-w...@kernel.org
 
> Ira

-- 
Sincerely yours,
Mike.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

2020-06-03 Thread Ira Weiny 
On Thu, Jun 04, 2020 at 09:18:05AM +0300, Mike Rapoport wrote:
> On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
> > On 6/3/20 2:14 PM, Ira Weiny wrote:
> > > On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote:
> > >> On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny  wrote:
> > >>
> > >>>>>
> > >>>>> Actually it occurs to me that the patch consolidating kmap_prot is 
> > >>>>> odd for
> > >>>>> sparc 32 bit...
> > >>>>>
> > >>>>> Its a long shot but could you try reverting this patch?
> > >>>>>
> > >>>>> 4ea7d2419e3f kmap: consolidate kmap_prot definitions
> > >>>>>
> > >>>>
> > >>>> That is not easy to revert, unfortunately, due to several follow-up 
> > >>>> patches.
> > >>>
> > >>> I have gotten your sparc tests to run and they all pass...
> > >>>
> > >>> 08:10:34 > ../linux-build-test/rootfs/sparc/run-qemu-sparc.sh 
> > >>> Build reference: v5.7-rc4-17-g852b6f2edc0f
> > >>>
> > >>> Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed
> > >>> Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed
> > >>> Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed
> > >>> Building sparc32:SS-4:nosmp:initrd ... running . passed
> > >>> Building sparc32:SS-5:nosmp:scsi:hd ... running . passed
> > >>> Building sparc32:SS-10:nosmp:scsi:cd ... running . passed
> > >>> Building sparc32:SS-20:nosmp:scsi:hd ... running . passed
> > >>> Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed
> > >>> Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running . 
> > >>> passed
> > >>> Building sparc32:SS-4:smp:scsi:hd ... running . passed
> > >>> Building sparc32:SS-5:smp:scsi:cd ... running . passed
> > >>> Building sparc32:SS-10:smp:scsi:hd ... running . passed
> > >>> Building sparc32:SS-20:smp:scsi:hd ... running . passed
> > >>> Building sparc32:SS-600MP:smp:scsi:hd ... running . passed
> > >>> Building sparc32:Voyager:smp:noapc:scsi:hd ... running . passed
> > >>>
> > >>> Is there another test I need to run?
> > >>
> > >> This all petered out, but as I understand it, this patchset still might
> > >> have issues on various architectures.
> > >>
> > >> Can folks please provide an update on the testing status?
> > > 
> > > I believe the tests were failing for Guenter due to another patch 
> > > set...[1]
> > > 
> > > My tests with just this series are working.
> > > 
> > >>From my understanding the other failures were unrelated.[2]
> > > 
> > >   
> > >   I've checked the patch above on top of the mmots which already has
> > >   Ira's patches and it booted fine. I've used sparc32_defconfig to build
> > >   the kernel and qemu-system-sparc with default machine and CPU.
> > >   
> > > 
> > > Mike, am I wrong?  Do you think the kmap() patches are still causing 
> > > issues?
> 
> sparc32 UP and microblaze work for me with next-20200603, but I didn't
> test other architectures. 
>  
> > For my part, all I can say is that -next is in pretty bad shape right now.
> > The summary of my tests says:
> > 
> > Build results:
> > total: 151 pass: 130 fail: 21
> > Qemu test results:
> > total: 430 pass: 375 fail: 55
> > 
> > sparc32 smp images in next-20200603 still crash for me with a spinlock
> > recursion.
> 
> I think this is because Will's fixes [1] are not yet in -next.
> 
> > s390 images hang early in boot. Several others (alpha, arm64,
> > various ppc) don't even compile. I can run some more bisects over time,
> > but this is becoming a full-time job :-(.
> > 
> > Guenter
> 
> [1] https://lore.kernel.org/lkml/20200526173302.377-1-w...@kernel.org

I abandoned the bisect and tested with this fix.[1]  It passes.  Guenter, on
the original thread we had microblaze and ppc working with my fix.

https://lore.kernel.org/lkml/20200519194215.ga71...@roeck-us.net/

Sounds like the current failures above are from something much newer in the
tree.

Ira

[1]
23:26:24 >

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

2020-06-03 Thread Ira Weiny 
On Thu, Jun 04, 2020 at 09:37:45AM +0300, Mike Rapoport wrote:
> On Wed, Jun 03, 2020 at 11:22:26PM -0700, Ira Weiny wrote:
> > On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
> > 
> > With linux-next on sparc I too see the spinlock issue; something like:
> > 
> > ...
> > Starting syslogd: BUG: spinlock recursion on CPU#0, S01syslogd/139
> >  lock: 0xf53ef350, .magic: dead4ead, .owner: S01syslogd/139, .owner_cpu: 0
> > CPU: 0 PID: 139 Comm: S01syslogd Not tainted 5.7.0-next-20200603 #1
> > [f0067d00 : 
> > do_raw_spin_lock+0xa8/0xd8 ] 
> > [f00d598c : 
> > copy_page_range+0x328/0x804 ] 
> > [f0025c34 : 
> > dup_mm+0x334/0x434 ] 
> > [f0027198 : 
> > copy_process+0x1248/0x12d4 ] 
> > [f00273b8 : 
> > _do_fork+0x54/0x30c ] 
> > [f00276e4 : 
> > do_fork+0x5c/0x6c ] 
> > [f000de44 : 
> > sparc_do_fork+0x18/0x38 ] 
> > [f000b7f4 : 
> > do_syscall+0x34/0x40 ] 
> > [5010cd4c : 
> > 0x5010cd4c ] 
> > 
> > 
> > I'm going to bisect between there and HEAD.
> 
> The sparc issue should be fixed by 
> 
> https://lore.kernel.org/lkml/20200526173302.377-1-w...@kernel.org

Saw your other email.  And yes they are!

Thanks!
Ira

>  
> > Ira
> 
> -- 
> Sincerely yours,
> Mike.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc