Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
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
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
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 v6 07/13] ARC: Linux Syscall Interface
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 v6 07/13] ARC: Linux Syscall Interface
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 v3 1/4] iee754: provide gcc builtins based generic sqrt functions
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 v3 1/4] iee754: provide gcc builtins based generic sqrt functions
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
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
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 v2 2/4] iee754: provide gcc builtins based generic fma functions
On 6/2/20 7:13 PM, Vineet Gupta wrote:
> On 6/2/20 5:51 AM, Stefan Liebler via Libc-alpha wrote:
>> #endif /* math-use-builtins.h */
>> Please also update the current architecture specific math-use-builtins.h
>> file: sysdeps/s390/fpu/math-use-builtins.h
>> Otherwise it will break build on s390x.
>
> Done.
>
>>> diff --git a/sysdeps/ieee754/dbl-64/s_fma.c b/sysdeps/ieee754/dbl-64/s_fma.c
>>> index 876df6e78bdc..9dc5b132b9ee 100644
>>> --- a/sysdeps/ieee754/dbl-64/s_fma.c
>>> +++ b/sysdeps/ieee754/dbl-64/s_fma.c
>>> @@ -25,6 +25,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> /* This implementation uses rounding to odd to avoid problems with
>>> double rounding. See a paper by Boldo and Melquiond:
>>> @@ -33,6 +34,10 @@
>>> double
>>> __fma (double x, double y, double z)
>>> {
>>> +#if USE_FMA_BUILTIN
>>> + return __builtin_fma (x, y, z);
>>
>> Architectures which have support for ldbl-128 will use the file
>> sysdeps/ieee754/ldbl-128/s_fma.c instead of
>> sysdeps/ieee754/dbl-64/s_fma.c. Should this file also be adjusted in
>> order to use the builtin if USE_FMA_BUILTIN is set to one?
>
> Right.
>
> I used commit f82996f815 "Use GCC builtins for round functions if desired" as
> starting point for my change. And seems it was not an ideal reference :-) as
> round
> has far fewer instances than fma. Indeed fma is present in ldbl-128 and
> dbl-64 so
> needs updating in both.
>
> But just to be sure s390 is currently not using the newly introduced builtins
> so
> I'll keep them as follows.
>
> #define USE_SQRT_BUILTIN 0
> #define USE_SQRTF_BUILTIN 0
>
> #define USE_FMA_BUILTIN 0
> #define USE_FMAF_BUILTIN 0
> #define USE_FMAL_BUILTIN 0
> #define USE_FMAF128_BUILTIN 0
>
Yes. Those should be disabled for now in order to not break anything. As
soon as you've committed your patches, I'll have a look if I can
activate some of them and remove s390 specific implementations. But I
first have to check with the gcc guys, if the builtins are always
expanded correctly in various gcc versions.
Thanks.
Stefan
> -Vineet
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
