mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-perf-users@vger.kernel.org"
	<linux-perf-users@vger.kernel.org>,
	Russell King <rmk+kernel@arm.linux.org.uk>,
	arcml <linux-snps-arc@lists.infradead.org>,
	"acme@redhat.com" <acme@redhat.com>
Subject: Re: [RFC] perf: fix building for ARCv1
Date: Tue, 18 Oct 2016 11:58:26 -0700	[thread overview]
Message-ID: <9e22e4b1-7e36-1a74-3620-a4790a5d1bfd@synopsys.com> (raw)
In-Reply-To: <20151019093549.GK3816@twins.programming.kicks-ass.net>

On 10/19/2015 02:35 AM, Peter Zijlstra wrote:
> On Mon, Oct 19, 2015 at 09:28:43AM +0000, Vineet Gupta wrote:
>> On Monday 19 October 2015 11:20 AM, Andi Kleen wrote:
>>> Vineet Gupta <Vineet.Gupta1@synopsys.com> writes:
>>>> But this user space - so IMHO UP/SMP doesn't matter and we can't simulate them in
>>>> C just by itself.
>>> It matters when you access the perf ring buffer which is updated by kernel.
>> That's part of the problem. The issue is with atomic_* APIs proliferation in perf
>> user space code which assumes native atomix r-m-w support which is not always
>> true. So I think we still need a feature detection mechanism and if absent leave
>> the ball in arch court by calling arch_atomic_* which can use creative or half
>> working measures so perf will work to some extent atleast and not bomb outright.
>>
>> Also can u please elaborate a bit on "simulate them in C" - u mean just simple
>> unprotected LD, OP, ST or do u fancy usage of futex etc?
> Doesn't ARMv5 have a cmpxchg syscall to deal with this? It does an
> IRQ-disabled load-op-store sequence.

So I got around to addressing this - now that someone actually is trying to use
NPTL (which uses llock/scond) on ARC700 lacking those instructions. However given
that we are going this route, FWIW ARM kernel got rid of this syscall with
db695c0509d6ec ("ARM: remove user cmpxchg syscall") citing some security hole.
Even of we were to disregard, the code at the time had some open code MM trickery,
which I'd rather not replicate. My use case is simple - I only need to support UP
config - and a simple {get,put}_user would suffice - given that that can
potentially take a TLB refill Miss or worse still a full page fault. I'm going to
cook that patch to add that syscall, but wanted to get some thoughts ahead of that.

-Vineet

  parent reply	other threads:[~2016-10-18 18:58 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1445088959-3058-1-git-send-email-abrodkin@synopsys.com>
2015-10-17 14:19 ` Vineet Gupta
2015-10-18 11:15   ` Alexey Brodkin
2015-10-18 23:14     ` Andi Kleen
2015-10-19  4:58       ` Vineet Gupta
2015-10-19  5:49         ` Andi Kleen
2015-10-19  9:28           ` Vineet Gupta
2015-10-19  9:35             ` Peter Zijlstra
2015-10-19  9:46               ` Vineet Gupta
2015-10-19  9:51                 ` Peter Zijlstra
2015-10-19 10:04                   ` Vineet Gupta
2015-10-20  8:00                   ` Vineet Gupta
2015-10-20 10:11                     ` Peter Zijlstra
2015-10-20 10:45                       ` Vineet Gupta
2015-10-29 15:58                         ` Alexey Brodkin
2015-10-30  6:19                           ` Vineet Gupta
2016-02-03 16:20                             ` Alexey Brodkin
     [not found]                             ` <1454516455.2811.4.camel__10775.5710989752$1454516490$gmane$org@synopsys.com>
2016-02-04  4:13                               ` Vineet Gupta
2016-02-05 11:18                                 ` Noam Camus
     [not found]                                   ` <20160205161027.GG28242@kernel.org>
2016-02-10  3:09                                     ` Vineet Gupta
2016-10-18 18:58               ` Vineet Gupta [this message]
2016-10-24 16:17                 ` [PATCH-v2] ARC: syscall for userspace cmpxchg assist Vineet Gupta
2016-11-04 20:16                   ` Vineet Gupta
2016-11-07 18:50                     ` [PATCH] ARC: tweak semantics of " Vineet Gupta
2015-10-30  6:21 ` [RFC] perf: fix building for ARCv1 Vineet Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9e22e4b1-7e36-1a74-3620-a4790a5d1bfd@synopsys.com \
    --to=vineet.gupta1@synopsys.com \
    --cc=Alexey.Brodkin@synopsys.com \
    --cc=acme@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=peterz@infradead.org \
    --cc=rmk+kernel@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®