Re: arc_usr_cmpxchg and preemption

2018-03-14 Thread Vineet Gupta
On 03/14/2018 01:38 PM, Alexey Brodkin wrote: @Vineet, are you OK with proposed implementation? I couldn't agree any more ! -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-

Re: arc_usr_cmpxchg and preemption

2018-03-14 Thread Alexey Brodkin
Hi Peter, Vineet, On Wed, 2018-03-14 at 18:53 +0100, Peter Zijlstra wrote: > On Wed, Mar 14, 2018 at 09:58:19AM -0700, Vineet Gupta wrote: > > > Well it is broken wrt the semantics the syscall is supposed to provide. > > Preemption disabling is what prevents a concurrent thread from coming in and

Re: Do we need to disable preemption in flush_tlb_range()?

2018-03-14 Thread Vineet Gupta
+CC Peter since we have his attention ;-) On 03/01/2018 07:13 AM, Alexey Brodkin wrote: Hi Vineet, Just noticed that in comments for smp_call_function_many() it is said that preemption must be disabled during its execution. And that function gets executed among other ways like that: --

[PATCH] mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs

2018-03-14 Thread Evgeniy Didin
It was found that in IDMAC mode after soft-reset driver switches to PIO mode. That's what happens in case of DTO timeout overflow calculation failure: 1. soft-reset is called 2. driver restarts dma 3. descriptors states are checked, one of descriptor is owned by the IDMAC. 4. driver can't use DMA

Re: Do we need to disable preemption in flush_tlb_range()?

2018-03-14 Thread Alexey Brodkin
Ping! On Thu, 2018-03-01 at 18:13 +0300, Alexey Brodkin wrote: > Hi Vineet, > > Just noticed that in comments for smp_call_function_many() it is said that > preemption must be disabled during its execution. And that function gets > executed > among other ways like that: > ---

Re: arc_usr_cmpxchg and preemption

2018-03-14 Thread Peter Zijlstra
On Wed, Mar 14, 2018 at 06:53:52PM +0100, Peter Zijlstra wrote: > On Wed, Mar 14, 2018 at 09:58:19AM -0700, Vineet Gupta wrote: > > > Well it is broken wrt the semantics the syscall is supposed to provide. > > Preemption disabling is what prevents a concurrent thread from coming in and > > modifyi

Re: arc_usr_cmpxchg and preemption

2018-03-14 Thread Peter Zijlstra
On Wed, Mar 14, 2018 at 09:58:19AM -0700, Vineet Gupta wrote: > Well it is broken wrt the semantics the syscall is supposed to provide. > Preemption disabling is what prevents a concurrent thread from coming in and > modifying the same location (Imagine a variable which is being cmpxchg > concurre

Re: arc_usr_cmpxchg and preemption

2018-03-14 Thread Vineet Gupta
+CC linux-arch, Peter for any preemption insights ! On 03/14/2018 09:36 AM, Alexey Brodkin wrote: Hi Vineet, While debugging a segfault of user-space app on system without atomic ops (I mean LLOCK/SCOND) I understood the root-cause is in implementation of kernel's __NR_arc_usr_cmpxchg syscall w

arc_usr_cmpxchg and preemption

2018-03-14 Thread Alexey Brodkin
Hi Vineet, While debugging a segfault of user-space app on system without atomic ops (I mean LLOCK/SCOND) I understood the root-cause is in implementation of kernel's __NR_arc_usr_cmpxchg syscall which is supposed to emulate mentioned atomic ops for user-space. So here's a problem. 1. User-space

Re: mmc: block: bonnie++ runs with errors on arc/hsdk board

2018-03-14 Thread Evgeniy Didin
Hi Adrian, > > > > Was the performance affected? i.e. the results from bonnie++ > > I have run bonnie++ several times before and after mentioned commit. Here is > output: > --<8---

kisskb: OK linux-next/axs101_defconfig/arcompact Wed Mar 14, 19:04

2018-03-14 Thread noreply
OK linux-next/axs101_defconfig/arcompact Wed Mar 14, 19:04 http://kisskb.ellerman.id.au/kisskb/buildresult/13302379/ Commit: Add linux-next specific files for 20180314 71b7a5164471c2e42e870bdbcca3176d9a9b281c Compiler: arc-buildroot-linux-uclibc-gcc (Buildroot 2015.08.1) 4.8.4 No