> On Thu, Mar 15, 2018 at 12:03 PM, Alexey Brodkin
> wrote:
> Here's a brief analysis:
> ARM: Looks like they got rid of that stuff in v4.4, see
> commit db695c0509d6 ("ARM: remove user cmpxchg syscall").
>
> M68K: That's even uglier implementation which is really asking for
> a face
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
On Fri, Mar 16, 2018 at 10:54:52AM -0700, Vineet Gupta wrote:
> I'd say just bite the bullet, write the patch and we can refine it there !
Just be glad its not futex.c proper ;-) I'll try and have a look later..
___
linux-snps-arc mailing list
linux-snp
On 03/16/2018 10:33 AM, Alexey Brodkin wrote:
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
On Thu, Mar 15, 2018 at 07:03:32PM +, Alexey Brodkin wrote:
> > I think there's a bunch of architectures that are in the same boat.
> > m68k, arm, mips was mentioned. Sure, the moment an arch has hardware
> > support you don't need the syscall anymore.
>
> Here's a brief analysis:
> ARM: Look
Hi Peter,
On Thu, 2018-03-15 at 12:28 +0100, Peter Zijlstra wrote:
> On Thu, Mar 15, 2018 at 09:12:09AM +, Alexey Brodkin wrote:
> > On Thu, 2018-03-15 at 09:18 +0100, Peter Zijlstra wrote:
> > > Also, it might make sense to stuff this implementation in some lib/ file
> > > somewhere and make
On Thu, Mar 15, 2018 at 09:12:09AM +, Alexey Brodkin wrote:
> On Thu, 2018-03-15 at 09:18 +0100, Peter Zijlstra wrote:
> > Also, it might make sense to stuff this implementation in some lib/ file
> > somewhere and make all platforms that need it use the same code, afaict
> > there really isn't
Hi Peter,
On Thu, 2018-03-15 at 09:18 +0100, Peter Zijlstra wrote:
> On Wed, Mar 14, 2018 at 08:38:53PM +, Alexey Brodkin wrote:
> > > int sys_cmpxchg(u32 __user *user_ptr, u32 old, u32 new)
> > > {
> > > u32 val;
> > > int ret;
> > >
> > > again:
> > > ret = 0;
> > >
> > > preempt_d
On Wed, Mar 14, 2018 at 08:38:53PM +, Alexey Brodkin wrote:
> > int sys_cmpxchg(u32 __user *user_ptr, u32 old, u32 new)
> > {
> > u32 val;
> > int ret;
> >
> > again:
> > ret = 0;
> >
> > preempt_disable();
> > val = get_user(user_ptr);
> > if (val == old)
> >
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-
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
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
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
+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
14 matches
Mail list logo
