From peterz at infradead.org  Thu Sep  1 01:33:24 2016
From: peterz at infradead.org (Peter Zijlstra)
Date: Thu, 1 Sep 2016 10:33:24 +0200
Subject: [PATCH] arc: perf: Enable generic "cache-references" and
 "cache-misses" events
In-Reply-To: <5f65fa04-8d33-e525-115d-4e6991a7668e@synopsys.com>
References: <1472125647-518-1-git-send-email-abrodkin@synopsys.com>
 <6074e252-6e18-bb01-4de1-023bd7e82f03@synopsys.com>
 <5f65fa04-8d33-e525-115d-4e6991a7668e@synopsys.com>
Message-ID: <20160901083324.GM10153@twins.programming.kicks-ass.net>

On Wed, Aug 31, 2016 at 12:05:14PM -0700, Vineet Gupta wrote:
> On 08/26/2016 10:31 AM, Vineet Gupta wrote:
> > On 08/25/2016 04:49 AM, Alexey Brodkin wrote:
> >> ...
> >>  	[PERF_COUNT_ARC_EDTLB] = "edtlb",	/* D-TLB Miss */
> >>  	[PERF_COUNT_ARC_EITLB] = "eitlb",	/* I-TLB Miss */
> >> +
> >> +	[PERF_COUNT_HW_CACHE_REFERENCES] = "imemrdc",	/* Instr: mem read cached */
> >> +	[PERF_COUNT_HW_CACHE_MISSES] = "dclm",		/* D-cache Load Miss */
> > I think this is duplicating a mistake we already have. I vaguely remember when
> > doing some hackbench profiling last year with range based profiling confined to
> > memset routine and saw that L1-dcache-misses was counting zero. This is because it
> > only counts LD misses while memset only does ST.
> >
> > Performance counter stats for '/sbin/hackbench':
> >
> >      0 L1-dcache-misses
> >      0 L1-dcache-load-misses
> >      1846082 L1-dcache-store-misses
> >
> >
> > @PeterZ do you concur that is wrong and we ought to setup 2 counters to do this
> > correctly ?
> 
> Hi Peter / Will,
> 
> Can you provide some guidance here. So I looked at what others do -
> ARMV7_PERFCTR_L1_DCACHE_REFILL counts both load and store misses, while ARC has 2
> separate conditions for load or stores. Is there an existing mechanism to "group"
> / "add" them to give a cumulative PERF_COUNT_HW_CACHE_MISSES 

Nope. So I would not try and use these generic events. In other news, it
seems like there's finally some progress on the JSON patches:

  https://lkml.kernel.org/r/20160831114254.GA9001 at krava

Which would make using non-standard events easier.

> - is that what perf event grouping is ?

Again, nope. Perf event groups are single counter (so no implicit
addition) that are co-scheduled on the PMU.

> Quoting from perf wiki @ https://perf.wiki.kernel.org/index.php/Tutorial
> 
> "It can be interesting to try and pack events in a way that guarantees that event
> A and B are always measured together. Although the perf_events kernel interface
> provides support for event grouping, the current perf tool does *not*."

That seems out-dated, Jiri added grouping support to perf-tool quite a
while back.

You can do it like:

	perf stat -e '{cycles,instructions}'

Which will place the cycles event and the instructions event in a group
and thereby guarantee they're co-scheduled.




From Julia.Lawall at lip6.fr  Thu Sep  1 10:51:29 2016
From: Julia.Lawall at lip6.fr (Julia Lawall)
Date: Thu,  1 Sep 2016 19:51:29 +0200
Subject: [PATCH 0/9] constify uart_ops structures
Message-ID: <1472752298-981-1-git-send-email-Julia.Lawall@lip6.fr>

Constify uart_ops structures.

---

 drivers/tty/serial/altera_jtaguart.c |    2 +-
 drivers/tty/serial/altera_uart.c     |    2 +-
 drivers/tty/serial/arc_uart.c        |    2 +-
 drivers/tty/serial/atmel_serial.c    |    2 +-
 drivers/tty/serial/bcm63xx_uart.c    |    2 +-
 drivers/tty/serial/fsl_lpuart.c      |    4 ++--
 drivers/tty/serial/imx.c             |    2 +-
 drivers/tty/serial/jsm/jsm_tty.c     |    2 +-
 drivers/tty/serial/max3100.c         |    2 +-
 drivers/tty/serial/men_z135_uart.c   |    2 +-
 drivers/tty/serial/mxs-auart.c       |    2 +-
 drivers/tty/serial/pch_uart.c        |    2 +-
 drivers/tty/serial/sh-sci.c          |    2 +-
 drivers/tty/serial/st-asc.c          |    2 +-
 drivers/tty/serial/timbuart.c        |    2 +-
 drivers/tty/serial/uartlite.c        |    2 +-
 drivers/tty/serial/xilinx_uartps.c   |    2 +-
 17 files changed, 18 insertions(+), 18 deletions(-)


From Julia.Lawall at lip6.fr  Thu Sep  1 10:51:38 2016
From: Julia.Lawall at lip6.fr (Julia Lawall)
Date: Thu,  1 Sep 2016 19:51:38 +0200
Subject: [PATCH 9/9] serial/arc: constify uart_ops structures
In-Reply-To: <1472752298-981-1-git-send-email-Julia.Lawall@lip6.fr>
References: <1472752298-981-1-git-send-email-Julia.Lawall@lip6.fr>
Message-ID: <1472752298-981-10-git-send-email-Julia.Lawall@lip6.fr>

Check for uart_ops structures that are only stored in the ops field of a
uart_port structure.  This field is declared const, so uart_ops structures
that have this property can be declared as const also.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct uart_ops i at p = { ... };

@ok@
identifier r.i;
struct uart_port e;
position p;
@@
e.ops = &i at p;

@bad@
position p != {r.p,ok.p};
identifier r.i;
struct uart_ops e;
@@
e at i@p

@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
 struct uart_ops i = { ... };
// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall at lip6.fr>

---
 drivers/tty/serial/arc_uart.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/arc_uart.c b/drivers/tty/serial/arc_uart.c
index 3a1de5c..5ac06fc 100644
--- a/drivers/tty/serial/arc_uart.c
+++ b/drivers/tty/serial/arc_uart.c
@@ -464,7 +464,7 @@ static int arc_serial_poll_getchar(struct uart_port *port)
 }
 #endif
 
-static struct uart_ops arc_serial_pops = {
+static const struct uart_ops arc_serial_pops = {
 	.tx_empty	= arc_serial_tx_empty,
 	.set_mctrl	= arc_serial_set_mctrl,
 	.get_mctrl	= arc_serial_get_mctrl,



From Vineet.Gupta1 at synopsys.com  Thu Sep  1 11:28:29 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Thu, 1 Sep 2016 11:28:29 -0700
Subject: [PATCH] perf tools: Fix static building
In-Reply-To: <20160831072128.GB4740@krava>
References: <1471887222-26270-1-git-send-email-abrodkin@synopsys.com>
 <20160831072128.GB4740@krava>
Message-ID: <8deeb70b-6fe8-32c5-9f6f-65b2d6bd70eb@synopsys.com>

On 08/31/2016 12:21 AM, Jiri Olsa wrote:
> On Mon, Aug 22, 2016 at 08:33:42PM +0300, Alexey Brodkin wrote:
>> With commit e3d09ec8126f ("tools lib traceevent: Export dynamic symbols
>> used by traceevent plugins") we started to add "--dynamic-list" in
>> LDFLAGS. One side-effect of that was inability to build really
>> statically-linked perf.
> 
> IIRC --dynamic-list forces perf to exports some symbols to
> be used by plugins.. don't see this breaking static build
> 
> also it's working properly for me:
> 
> [jolsa at krava perf]$ make LDFLAGS=-static
> ...
> [jolsa at krava perf]$ ldd ./perf
>         not a dynamic executable
> 
> unless I miss what you mean by 'really statically-linked' ;-)

Right - so I tried this as well and indeed I can confirm that it builds for me as
static. Atleast the build system doesn;t need changing as -sattic being propagated
to fianl link cmd.

There seems to be some weirdness with ARC tools: file reports

| ELF 32-bit LSB executable, *unknown arch 0xc3* version 1 (SYSV),
| dynamically linked, interpreter *empty*, for GNU/Linux 3.9.0, not stripped


That is clearly wrong !

And the static binary as expected doesn't seem to run on target - exits with -EACCESS.

-Vineet


From Vineet.Gupta1 at synopsys.com  Thu Sep  1 11:49:45 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Thu, 1 Sep 2016 11:49:45 -0700
Subject: [PATCH 9/9] serial/arc: constify uart_ops structures
In-Reply-To: <1472752298-981-10-git-send-email-Julia.Lawall@lip6.fr>
References: <1472752298-981-1-git-send-email-Julia.Lawall@lip6.fr>
 <1472752298-981-10-git-send-email-Julia.Lawall@lip6.fr>
Message-ID: <a666292c-e4a8-d6b4-6e2a-a44d8b6b9528@synopsys.com>

On 09/01/2016 10:51 AM, Julia Lawall wrote:
> Check for uart_ops structures that are only stored in the ops field of a
> uart_port structure.  This field is declared const, so uart_ops structures
> that have this property can be declared as const also.
> 
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
> 
> // <smpl>
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct uart_ops i at p = { ... };
> 
> @ok@
> identifier r.i;
> struct uart_port e;
> position p;
> @@
> e.ops = &i at p;
> 
> @bad@
> position p != {r.p,ok.p};
> identifier r.i;
> struct uart_ops e;
> @@
> e at i@p
> 
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> static
> +const
>  struct uart_ops i = { ... };
> // </smpl>
> 
> Signed-off-by: Julia Lawall <Julia.Lawall at lip6.fr>

Acked-by: Vineet Gupta <vgupta at synopsys.com>

Thx for making it better Julia !
-Vineet

> 
> ---
>  drivers/tty/serial/arc_uart.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/serial/arc_uart.c b/drivers/tty/serial/arc_uart.c
> index 3a1de5c..5ac06fc 100644
> --- a/drivers/tty/serial/arc_uart.c
> +++ b/drivers/tty/serial/arc_uart.c
> @@ -464,7 +464,7 @@ static int arc_serial_poll_getchar(struct uart_port *port)
>  }
>  #endif
>  
> -static struct uart_ops arc_serial_pops = {
> +static const struct uart_ops arc_serial_pops = {
>  	.tx_empty	= arc_serial_tx_empty,
>  	.set_mctrl	= arc_serial_set_mctrl,
>  	.get_mctrl	= arc_serial_get_mctrl,
> 



From gregkh at linuxfoundation.org  Mon Sep  5 06:02:37 2016
From: gregkh at linuxfoundation.org (Greg KH)
Date: Mon, 5 Sep 2016 15:02:37 +0200
Subject: ARC stable backport request
In-Reply-To: <2ac8d0fc-9c67-e7c7-41f0-68cb34514019@synopsys.com>
References: <2ac8d0fc-9c67-e7c7-41f0-68cb34514019@synopsys.com>
Message-ID: <20160905130237.GB29724@kroah.com>

On Mon, Aug 22, 2016 at 10:36:20AM -0700, Vineet Gupta wrote:
> Hi Stable Team,
> 
> Could you please backport upstream 20d780374c81c ("ARC: build: Better way to
> detect ISA compatible toolchain")
> 
> This is needed to let kernel building with newer gcc 6.x based tools.

Applied to 4.4-stable, thanks.

greg k-h


From Joao.Pinto at synopsys.com  Tue Sep  6 04:05:20 2016
From: Joao.Pinto at synopsys.com (Joao Pinto)
Date: Tue, 6 Sep 2016 12:05:20 +0100
Subject: [PATCH] pci: adding support for PCI_MSI_IRQ_DOMAIN in ARC arch
In-Reply-To: <64d6513b-13f1-953d-410b-a4aeea6908c3@synopsys.com>
References: <fdd37b0b995d178fddb34fdbdb5daf5981822f52.1470757628.git.jpinto@synopsys.com>
 <64d6513b-13f1-953d-410b-a4aeea6908c3@synopsys.com>
Message-ID: <05c5bab3-77bf-9993-8661-49ca9f41a7ca@synopsys.com>

Hi Bjorn,
Did you have the chance to check this patch?

Thanks.

On 8/10/2016 6:55 PM, Vineet Gupta wrote:
> On 08/09/2016 08:51 AM, Joao Pinto wrote:
>> Due to the added dependency on PCI_MSI_IRQ_DOMAIN for all PCIe RC 
>> drivers, we were unable to build a RC solution for an ARC platform.
>>
>> To fix this, this patch adds ARC as a PCI_MSI_IRQ_DOMAIN supportive
>> platform and adds the generation of msi.h in the ARC arch.
>>
>> Signed-off-by: Joao Pinto <jpinto at synopsys.com>
> 
> LGTM - Bjorn I presume you will pick this up ?
> 
> -Vineet
>> ---
>>  arch/arc/include/asm/Kbuild | 1 +
>>  drivers/pci/Kconfig         | 2 +-
>>  2 files changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild
>> index 0b10ef2..c332604 100644
>> --- a/arch/arc/include/asm/Kbuild
>> +++ b/arch/arc/include/asm/Kbuild
>> @@ -25,6 +25,7 @@ generic-y += mcs_spinlock.h
>>  generic-y += mm-arch-hooks.h
>>  generic-y += mman.h
>>  generic-y += msgbuf.h
>> +generic-y += msi.h
>>  generic-y += param.h
>>  generic-y += parport.h
>>  generic-y += pci.h
>> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
>> index 67f9916..6555eb7 100644
>> --- a/drivers/pci/Kconfig
>> +++ b/drivers/pci/Kconfig
>> @@ -25,7 +25,7 @@ config PCI_MSI
>>  	   If you don't know what to do here, say Y.
>>  
>>  config PCI_MSI_IRQ_DOMAIN
>> -	def_bool ARM || ARM64 || X86
>> +	def_bool ARC || ARM || ARM64 || X86
>>  	depends on PCI_MSI
>>  	select GENERIC_MSI_IRQ_DOMAIN
>>  
> 
> 



From helgaas at kernel.org  Tue Sep  6 08:57:39 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Tue, 6 Sep 2016 10:57:39 -0500
Subject: [PATCH] pci: adding support for PCI_MSI_IRQ_DOMAIN in ARC arch
In-Reply-To: <fdd37b0b995d178fddb34fdbdb5daf5981822f52.1470757628.git.jpinto@synopsys.com>
References: <fdd37b0b995d178fddb34fdbdb5daf5981822f52.1470757628.git.jpinto@synopsys.com>
Message-ID: <20160906155739.GD1214@localhost>

On Tue, Aug 09, 2016 at 04:49:37PM +0100, Joao Pinto wrote:
> To fix this, this patch adds ARC as a PCI_MSI_IRQ_DOMAIN supportive
> platform and adds the generation of msi.h in the ARC arch.
> 
> Signed-off-by: Joao Pinto <jpinto at synopsys.com>

I added Vineet's ack and put this on pci/msi for v4.9, thanks!

> ---
>  arch/arc/include/asm/Kbuild | 1 +
>  drivers/pci/Kconfig         | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild
> index 0b10ef2..c332604 100644
> --- a/arch/arc/include/asm/Kbuild
> +++ b/arch/arc/include/asm/Kbuild
> @@ -25,6 +25,7 @@ generic-y += mcs_spinlock.h
>  generic-y += mm-arch-hooks.h
>  generic-y += mman.h
>  generic-y += msgbuf.h
> +generic-y += msi.h
>  generic-y += param.h
>  generic-y += parport.h
>  generic-y += pci.h
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 67f9916..6555eb7 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -25,7 +25,7 @@ config PCI_MSI
>  	   If you don't know what to do here, say Y.
>  
>  config PCI_MSI_IRQ_DOMAIN
> -	def_bool ARM || ARM64 || X86
> +	def_bool ARC || ARM || ARM64 || X86
>  	depends on PCI_MSI
>  	select GENERIC_MSI_IRQ_DOMAIN
>  
> -- 
> 1.8.1.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From Joao.Pinto at synopsys.com  Tue Sep  6 09:14:25 2016
From: Joao.Pinto at synopsys.com (Joao Pinto)
Date: Tue, 6 Sep 2016 17:14:25 +0100
Subject: [PATCH] pci: adding support for PCI_MSI_IRQ_DOMAIN in ARC arch
In-Reply-To: <20160906155739.GD1214@localhost>
References: <fdd37b0b995d178fddb34fdbdb5daf5981822f52.1470757628.git.jpinto@synopsys.com>
 <20160906155739.GD1214@localhost>
Message-ID: <a7b7c384-e559-85e5-cee0-11ff9906bbb1@synopsys.com>

On 9/6/2016 4:57 PM, Bjorn Helgaas wrote:
> On Tue, Aug 09, 2016 at 04:49:37PM +0100, Joao Pinto wrote:
>> To fix this, this patch adds ARC as a PCI_MSI_IRQ_DOMAIN supportive
>> platform and adds the generation of msi.h in the ARC arch.
>>
>> Signed-off-by: Joao Pinto <jpinto at synopsys.com>
> 
> I added Vineet's ack and put this on pci/msi for v4.9, thanks!

Great! Thanks!

> 
>> ---
>>  arch/arc/include/asm/Kbuild | 1 +
>>  drivers/pci/Kconfig         | 2 +-
>>  2 files changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild
>> index 0b10ef2..c332604 100644
>> --- a/arch/arc/include/asm/Kbuild
>> +++ b/arch/arc/include/asm/Kbuild
>> @@ -25,6 +25,7 @@ generic-y += mcs_spinlock.h
>>  generic-y += mm-arch-hooks.h
>>  generic-y += mman.h
>>  generic-y += msgbuf.h
>> +generic-y += msi.h
>>  generic-y += param.h
>>  generic-y += parport.h
>>  generic-y += pci.h
>> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
>> index 67f9916..6555eb7 100644
>> --- a/drivers/pci/Kconfig
>> +++ b/drivers/pci/Kconfig
>> @@ -25,7 +25,7 @@ config PCI_MSI
>>  	   If you don't know what to do here, say Y.
>>  
>>  config PCI_MSI_IRQ_DOMAIN
>> -	def_bool ARM || ARM64 || X86
>> +	def_bool ARC || ARM || ARM64 || X86
>>  	depends on PCI_MSI
>>  	select GENERIC_MSI_IRQ_DOMAIN
>>  
>> -- 
>> 1.8.1.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From Vineet.Gupta1 at synopsys.com  Tue Sep  6 13:21:21 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Tue, 6 Sep 2016 13:21:21 -0700
Subject: WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously
 submitted to be applied to the 4.7-stable tree?
In-Reply-To: <20160906193810.GB22028@kroah.com>
References: <1473080592214136@kroah.com>
 <584a8fcd-6876-de0d-3c5e-8b4dad12c49d@synopsys.com>
 <20160906193810.GB22028@kroah.com>
Message-ID: <7ab12d76-875a-c06f-08e3-ef628edda1b9@synopsys.com>

On 09/06/2016 12:39 PM, gregkh at linuxfoundation.org wrote:
> On Tue, Sep 06, 2016 at 09:50:46AM -0700, Vineet Gupta wrote:
>> On 09/05/2016 06:03 AM, gregkh at linuxfoundation.org wrote:
>>> The patch below was submitted to be applied to the 4.7-stable tree.
>>>
>>> I fail to see how this patch meets the stable kernel rules as found at
>>> Documentation/stable_kernel_rules.txt.
>>>
>>> I could be totally wrong, and if so, please respond to 
>>> <stable at vger.kernel.org> and let me know why this patch should be
>>> applied.  Otherwise, it is now dropped from my patch queues, never to be
>>> seen again.
>> Hi Greg,
>>
>> We are about to switch to new version of GNU tools (gcc 6.x based) which
>> unfortunately has a non compatible ABI change - as described in the patch.
>>
>> Some of our customers are going to stick with older kernels and thus this helps
>> them upgrade to newer tools with their existing baseline kernels.
> That's nice, but it's a new feature.  Stick with old userspace for older
> kernels, and use new kernels for new userspace if you so desire.

I understand your point. This is what we did at the time of upstreaming the kernel
- and was something I was hoping to avoid this time because this is a flag day
change. People get locked into kernel version or tools - when the kernel code
itself didn't really change a bit.

But if this really is against the norms of stable backports, then I suppose we
can't do much ?

Thx,
-Vineet

>
> We do allow some new gcc fixes to be backported, but that's always where
> we have found bugs, or build warnings.  Not "we need to support gcc6 for
> old kernels", as really, if someone wants to update userspace, they
> don't update their kernel?
>
> thanks,
>
> greg k-h
>



From Vineet.Gupta1 at synopsys.com  Tue Sep  6 13:28:45 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Tue, 6 Sep 2016 13:28:45 -0700
Subject: WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously
 submitted to be applied to the 4.7-stable tree?
In-Reply-To: <7ab12d76-875a-c06f-08e3-ef628edda1b9@synopsys.com>
References: <1473080592214136@kroah.com>
 <584a8fcd-6876-de0d-3c5e-8b4dad12c49d@synopsys.com>
 <20160906193810.GB22028@kroah.com>
 <7ab12d76-875a-c06f-08e3-ef628edda1b9@synopsys.com>
Message-ID: <1e3ae422-d8ff-326e-29bd-b58002b5163b@synopsys.com>

On 09/06/2016 01:22 PM, Vineet Gupta wrote:
> > Not "we need to support gcc6 for
> > old kernels", as really, if someone wants to update userspace, they
> > don't update their kernel?

FWIW, I'm not arguing for the backport inclusion - I'm just trying to explain the
context more.

Thing is your regular user/customer don't really care/know about these details. So
there are tools bugs and more often than not the easy answer for tools providers
is "this is a known issue in gcc x.y which has been fixed in gcc x2.y2 so consider
upgrading". So it is for such class of users that having such backports makes life
a little easy.

Thx,
-Vineet


From gregkh at linuxfoundation.org  Tue Sep  6 23:28:52 2016
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Wed, 7 Sep 2016 08:28:52 +0200
Subject: WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously
 submitted to be applied to the 4.7-stable tree?
In-Reply-To: <1e3ae422-d8ff-326e-29bd-b58002b5163b@synopsys.com>
References: <1473080592214136@kroah.com>
 <584a8fcd-6876-de0d-3c5e-8b4dad12c49d@synopsys.com>
 <20160906193810.GB22028@kroah.com>
 <7ab12d76-875a-c06f-08e3-ef628edda1b9@synopsys.com>
 <1e3ae422-d8ff-326e-29bd-b58002b5163b@synopsys.com>
Message-ID: <20160907062852.GA1287@kroah.com>

On Tue, Sep 06, 2016 at 01:28:45PM -0700, Vineet Gupta wrote:
> On 09/06/2016 01:22 PM, Vineet Gupta wrote:
> > > Not "we need to support gcc6 for
> > > old kernels", as really, if someone wants to update userspace, they
> > > don't update their kernel?
> 
> FWIW, I'm not arguing for the backport inclusion - I'm just trying to explain the
> context more.
> 
> Thing is your regular user/customer don't really care/know about these details. So
> there are tools bugs and more often than not the easy answer for tools providers
> is "this is a known issue in gcc x.y which has been fixed in gcc x2.y2 so consider
> upgrading". So it is for such class of users that having such backports makes life
> a little easy.

That's fine, but who would be upgrading their userspace gcc and then
wanting to rebuild their kernel for an old kernel release?  What
prevents them from also updating their kernel?

I understand the context, I'm just trying to say that this really is a
"new feature" you are wanting here from what I can tell.  I'd recommend
just having people upgrade their kernel :)

thanks,

greg k-h


From Vineet.Gupta1 at synopsys.com  Wed Sep  7 09:38:25 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Wed, 7 Sep 2016 09:38:25 -0700
Subject: WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously
 submitted to be applied to the 4.7-stable tree?
In-Reply-To: <20160907062852.GA1287@kroah.com>
References: <1473080592214136@kroah.com>
 <584a8fcd-6876-de0d-3c5e-8b4dad12c49d@synopsys.com>
 <20160906193810.GB22028@kroah.com>
 <7ab12d76-875a-c06f-08e3-ef628edda1b9@synopsys.com>
 <1e3ae422-d8ff-326e-29bd-b58002b5163b@synopsys.com>
 <20160907062852.GA1287@kroah.com>
Message-ID: <df4f96e8-fb05-ec81-6b32-ff6bc54ad853@synopsys.com>

On 09/06/2016 11:28 PM, Greg Kroah-Hartman wrote:
> On Tue, Sep 06, 2016 at 01:28:45PM -0700, Vineet Gupta wrote:
>> On 09/06/2016 01:22 PM, Vineet Gupta wrote:
>>>> Not "we need to support gcc6 for
>>>> old kernels", as really, if someone wants to update userspace, they
>>>> don't update their kernel?
>> FWIW, I'm not arguing for the backport inclusion - I'm just trying to explain the
>> context more.
>>
>> Thing is your regular user/customer don't really care/know about these details. So
>> there are tools bugs and more often than not the easy answer for tools providers
>> is "this is a known issue in gcc x.y which has been fixed in gcc x2.y2 so consider
>> upgrading". So it is for such class of users that having such backports makes life
>> a little easy.
> That's fine, but who would be upgrading their userspace gcc and then
> wanting to rebuild their kernel for an old kernel release? 

IMHO those are totally unrelated things. user-space gcc/tools upgrade can be
forced upon customers by processor vendors (us) saying new tools come with boat
load of fixes etc and more often that not it is indeed the case. OTOH, customers
typically like to lock into a specific kernel baseline for longish duration
because (1) they have out of tree drivers - (2) they have production systems,
where they would be iffy to change to a new kernel because prev one is stable etc.
I know above seem like made up points and it is easy to dismiss them given that
(1)  We don't really work our processes for "enabling" out of tree stuff and (2) a
new gcc is more unstable than a new kernel. But that is the mindset when you talk
to them.

>  What prevents them from also updating their kernel?

Their platform baseline and out of tree drivers. Given my experience with
maintaining arch port, in the past, an arch rebase has been easier than rebasing
the drivers because of the framework improvements, API changes....


> I understand the context, I'm just trying to say that this really is a
> "new feature" you are wanting here from what I can tell.  I'd recommend
> just having people upgrade their kernel :)

That's what I recommend them too, all the time, but forcing this with a tools
upgrade really enforces them and they need to pick a side, before 4.x or after 4.x
which is not nice....

Thx,
-Vineet

>
> thanks,
>
> greg k-h
>



From Vineet.Gupta1 at synopsys.com  Thu Sep  8 09:28:18 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Thu, 8 Sep 2016 09:28:18 -0700
Subject: [PATCH] atomic64: No need for CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
Message-ID: <1473352098-5822-1-git-send-email-vgupta@synopsys.com>

This came to light when implementing native 64-bit atomics for ARCv2.

The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
to check whether atomic64_dec_if_positive() is available.
It seems it was needed when not every arch defined it.
However as of current code the Kconfig option seems needless

- for CONFIG_GENERIC_ATOMIC64 it is auto-enabled in lib/Kconfig and a
  generic definition of API is present lib/atomic64.c
- arches with native 64-bit atomics select it in arch/*/Kconfig and
  define the API in their headers

So I see no point in keeping the Kconfig option

Compile tested for 2 representatives:
 - blackfin (CONFIG_GENERIC_ATOMIC64)
 - x86 (!CONFIG_GENERIC_ATOMIC64)

Also logistics wise it seemed simpler to just do this in 1 patch vs.
splitting per arch - but I can break it up if maintainer feel that
is better to avoid conflicts.

Cc: Richard Henderson <rth at twiddle.net>
Cc: Ivan Kokshaysky <ink at jurassic.park.msu.ru>
Cc: Matt Turner <mattst88 at gmail.com>
Cc: Russell King <linux at armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Ralf Baechle <ralf at linux-mips.org>
Cc: "James E.J. Bottomley" <jejb at parisc-linux.org>
Cc: Helge Deller <deller at gmx.de>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Paul Mackerras <paulus at samba.org>
Cc: Michael Ellerman <mpe at ellerman.id.au>
Cc: Martin Schwidefsky <schwidefsky at de.ibm.com>
Cc: Heiko Carstens <heiko.carstens at de.ibm.com>
Cc: "David S. Miller" <davem at davemloft.net>
Cc: Chris Metcalf <cmetcalf at mellanox.com>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Ingo Molnar <mingo at redhat.com>
Cc: "H. Peter Anvin" <hpa at zytor.com>
Cc: x86 at kernel.org
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Vineet Gupta <vgupta at synopsys.com>
Cc: Zhaoxiu Zeng <zhaoxiu.zeng at gmail.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Matthew Wilcox <willy at linux.intel.com>
Cc: Alexander Potapenko <glider at google.com>
Cc: Andrey Ryabinin <aryabinin at virtuozzo.com>
Cc: Herbert Xu <herbert at gondor.apana.org.au>
Cc: Ming Lin <ming.l at ssi.samsung.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Geert Uytterhoeven <geert at linux-m68k.org>
Cc: Peter Zijlstra <peterz at infradead.org>
Cc: Borislav Petkov <bp at suse.de>
Cc: Andi Kleen <ak at linux.intel.com>
Cc: Boqun Feng <boqun.feng at gmail.com>
Cc: linux-alpha at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-mips at linux-mips.org
Cc: linux-parisc at vger.kernel.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-s390 at vger.kernel.org
Cc: sparclinux at vger.kernel.org
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-arch at vger.kernel.org
Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
---
 arch/alpha/Kconfig   | 1 -
 arch/arm/Kconfig     | 1 -
 arch/arm64/Kconfig   | 1 -
 arch/mips/Kconfig    | 1 -
 arch/parisc/Kconfig  | 1 -
 arch/powerpc/Kconfig | 1 -
 arch/s390/Kconfig    | 1 -
 arch/sparc/Kconfig   | 1 -
 arch/tile/Kconfig    | 1 -
 arch/x86/Kconfig     | 1 -
 lib/Kconfig          | 3 ---
 lib/atomic64_test.c  | 4 ----
 12 files changed, 17 deletions(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 7f312d80b43b..0e49d39ea74a 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -15,7 +15,6 @@ config ALPHA
 	select GENERIC_IRQ_SHOW
 	select ARCH_WANT_IPC_PARSE_VERSION
 	select ARCH_HAVE_NMI_SAFE_CMPXCHG
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select AUDIT_ARCH
 	select GENERIC_CLOCKEVENTS
 	select GENERIC_SMP_IDLE_THREAD
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a9c4e48bb7ec..2a50957c7bfb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1,7 +1,6 @@
 config ARM
 	bool
 	default y
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index bc3f00f586f1..3df2ca7efbcc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -6,7 +6,6 @@ config ARM64
 	select ACPI_MCFG if ACPI
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_GCOV_PROFILE_ALL
 	select ARCH_HAS_KCOV
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 26388562e300..5bbea197c220 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -30,7 +30,6 @@ config MIPS
 	select HAVE_ARCH_TRANSPARENT_HUGEPAGE if CPU_SUPPORTS_HUGEPAGES && 64BIT
 	select RTC_LIB if !MACH_LOONGSON64
 	select GENERIC_ATOMIC64 if !64BIT
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select HAVE_DMA_CONTIGUOUS
 	select HAVE_DMA_API_DEBUG
 	select GENERIC_IRQ_PROBE
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index cd8778103165..9e40b52c0721 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -15,7 +15,6 @@ config PARISC
 	select BUILDTIME_EXTABLE_SORT
 	select HAVE_PERF_EVENTS
 	select GENERIC_ATOMIC64 if !64BIT
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select BROKEN_RODATA
 	select GENERIC_IRQ_PROBE
 	select GENERIC_PCI_IOMAP
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 927d2ab2ce08..18d1b42cf545 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -113,7 +113,6 @@ config PPC
 	select HAVE_DEBUG_KMEMLEAK
 	select ARCH_HAS_SG_CHAIN
 	select GENERIC_ATOMIC64 if PPC32
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select HAVE_PERF_EVENTS
 	select HAVE_PERF_REGS
 	select HAVE_PERF_USER_STACK_DUMP
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index e751fe25d6ab..af52b07efde2 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -67,7 +67,6 @@ config DEBUG_RODATA
 
 config S390
 	def_bool y
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ELF_RANDOMIZE
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 59b09600dd32..bfedbe0cb7b2 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -22,7 +22,6 @@ config SPARC
 	select HAVE_ARCH_TRACEHOOK
 	select HAVE_EXIT_THREAD
 	select SYSCTL_EXCEPTION_TRACE
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select RTC_CLASS
 	select RTC_DRV_M48T59
 	select RTC_SYSTOHC
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 4820a02838ac..12eda5440c93 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -3,7 +3,6 @@
 
 config TILE
 	def_bool y
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAVE_NMI_SAFE_CMPXCHG
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c580d8c33562..0cf609998550 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -23,7 +23,6 @@ config X86
 	select ARCH_CLOCKSOURCE_DATA
 	select ARCH_DISCARD_MEMBLOCK
 	select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ELF_RANDOMIZE
diff --git a/lib/Kconfig b/lib/Kconfig
index d79909dc01ec..0e74df3c5441 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -457,9 +457,6 @@ config NLATTR
 config GENERIC_ATOMIC64
        bool
 
-config ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
-	def_bool y if GENERIC_ATOMIC64
-
 config LRU_CACHE
 	tristate
 
diff --git a/lib/atomic64_test.c b/lib/atomic64_test.c
index dbb369145dda..46042901130f 100644
--- a/lib/atomic64_test.c
+++ b/lib/atomic64_test.c
@@ -213,7 +213,6 @@ static __init void test_atomic64(void)
 	r += one;
 	BUG_ON(v.counter != r);
 
-#ifdef CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	INIT(onestwos);
 	BUG_ON(atomic64_dec_if_positive(&v) != (onestwos - 1));
 	r -= one;
@@ -226,9 +225,6 @@ static __init void test_atomic64(void)
 	INIT(-one);
 	BUG_ON(atomic64_dec_if_positive(&v) != (-one - one));
 	BUG_ON(v.counter != r);
-#else
-#warning Please implement atomic64_dec_if_positive for your architecture and select the above Kconfig symbol
-#endif
 
 	INIT(onestwos);
 	BUG_ON(!atomic64_inc_not_zero(&v));
-- 
2.7.4



From peterz at infradead.org  Thu Sep  8 11:19:05 2016
From: peterz at infradead.org (Peter Zijlstra)
Date: Thu, 8 Sep 2016 20:19:05 +0200
Subject: [PATCH] atomic64: No need for
 CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
In-Reply-To: <1473352098-5822-1-git-send-email-vgupta@synopsys.com>
References: <1473352098-5822-1-git-send-email-vgupta@synopsys.com>
Message-ID: <20160908181905.GY10153@twins.programming.kicks-ass.net>

On Thu, Sep 08, 2016 at 09:28:18AM -0700, Vineet Gupta wrote:
> This came to light when implementing native 64-bit atomics for ARCv2.
> 
> The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> to check whether atomic64_dec_if_positive() is available.
> It seems it was needed when not every arch defined it.
> However as of current code the Kconfig option seems needless
> 
> - for CONFIG_GENERIC_ATOMIC64 it is auto-enabled in lib/Kconfig and a
>   generic definition of API is present lib/atomic64.c
> - arches with native 64-bit atomics select it in arch/*/Kconfig and
>   define the API in their headers
> 
> So I see no point in keeping the Kconfig option
> 
> Compile tested for 2 representatives:
>  - blackfin (CONFIG_GENERIC_ATOMIC64)
>  - x86 (!CONFIG_GENERIC_ATOMIC64)
> 
> Also logistics wise it seemed simpler to just do this in 1 patch vs.
> splitting per arch - but I can break it up if maintainer feel that
> is better to avoid conflicts.

Works for me; you want me to take this, or do you need it for you ARCv2
patches?


From Vineet.Gupta1 at synopsys.com  Thu Sep  8 11:34:29 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Thu, 8 Sep 2016 11:34:29 -0700
Subject: [PATCH] atomic64: No need for
 CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
In-Reply-To: <20160908181905.GY10153@twins.programming.kicks-ass.net>
References: <1473352098-5822-1-git-send-email-vgupta@synopsys.com>
 <20160908181905.GY10153@twins.programming.kicks-ass.net>
Message-ID: <a37b81a2-9634-255e-b20b-51e75913cb40@synopsys.com>

On 09/08/2016 11:19 AM, Peter Zijlstra wrote:
> On Thu, Sep 08, 2016 at 09:28:18AM -0700, Vineet Gupta wrote:
>> This came to light when implementing native 64-bit atomics for ARCv2.
>>
>> The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
>> to check whether atomic64_dec_if_positive() is available.
>> It seems it was needed when not every arch defined it.
>> However as of current code the Kconfig option seems needless
>>
>> - for CONFIG_GENERIC_ATOMIC64 it is auto-enabled in lib/Kconfig and a
>>   generic definition of API is present lib/atomic64.c
>> - arches with native 64-bit atomics select it in arch/*/Kconfig and
>>   define the API in their headers
>>
>> So I see no point in keeping the Kconfig option
>>
>> Compile tested for 2 representatives:
>>  - blackfin (CONFIG_GENERIC_ATOMIC64)
>>  - x86 (!CONFIG_GENERIC_ATOMIC64)
>>
>> Also logistics wise it seemed simpler to just do this in 1 patch vs.
>> splitting per arch - but I can break it up if maintainer feel that
>> is better to avoid conflicts.
> Works for me; you want me to take this, or do you need it for you ARCv2
> patches?

Please do. ARCv2 patch (following shortly) doesn't need it - I selected the
option in orig patch - which I can just take out.

Thx,
-Vineet


From Vineet.Gupta1 at synopsys.com  Thu Sep  8 12:29:27 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Thu, 8 Sep 2016 12:29:27 -0700
Subject: [PATCH] ARCv2: Implement atomic64 based on LLOCKD/SCONDD instructions
Message-ID: <1473362967-23750-1-git-send-email-vgupta@synopsys.com>

ARCv2 ISA provides 64-bit exclusive load/stores so use them to implement
the 64-bit atomics and elide the spinlock based generic 64-bit atomics

boot tested with atomic64 self-test (and GOD bless the person who wrote
them, I realized my inline assmebly is sloppy as hell)

One thing I'm not sure of is the lack of explicit memory clobber in
barrier-less ops e.g. atomic64_add() (BTW same is true for 32-bit
atomic_add() as well). Per commit 398aa66827 ("ARM: 6212/1: atomic ops:
add memory constraints to inline asm ") Will fixed ARM code by adding
appropriate constraint to atomic64_add(). For ARC instead adding memory
clobber to atomic64_set() does the trick (otherwise self-test is broked)
This is on ARC we can't possibly use "m" in atomic64_add() since that make gcc
emit register relative effective addresses which LLOCKD/SCONDD are not
allowed by ISA

Cc: Peter Zijlstra <peterz at infradead.org>
Cc: Will Deacon <will.deacon at arm.com>
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
---
 arch/arc/Kconfig              |   2 +-
 arch/arc/include/asm/atomic.h | 255 +++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 254 insertions(+), 3 deletions(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 0d3e59f56974..073b3582544b 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -13,7 +13,7 @@ config ARC
 	select CLKSRC_OF
 	select CLONE_BACKWARDS
 	select COMMON_CLK
-	select GENERIC_ATOMIC64
+	select GENERIC_ATOMIC64 if !ISA_ARCV2 || !(ARC_HAS_LL64 && ARC_HAS_LLSC)
 	select GENERIC_CLOCKEVENTS
 	select GENERIC_FIND_FIRST_BIT
 	# for now, we don't need GENERIC_IRQ_PROBE, CONFIG_GENERIC_IRQ_CHIP
diff --git a/arch/arc/include/asm/atomic.h b/arch/arc/include/asm/atomic.h
index 4e3c1b6b0806..2b7e84d8fffa 100644
--- a/arch/arc/include/asm/atomic.h
+++ b/arch/arc/include/asm/atomic.h
@@ -20,6 +20,7 @@
 #ifndef CONFIG_ARC_PLAT_EZNPS
 
 #define atomic_read(v)  READ_ONCE((v)->counter)
+#define ATOMIC_INIT(i)	{ (i) }
 
 #ifdef CONFIG_ARC_HAS_LLSC
 
@@ -343,10 +344,260 @@ ATOMIC_OPS(xor, ^=, CTOP_INST_AXOR_DI_R2_R2_R3)
 
 #define atomic_add_negative(i, v)	(atomic_add_return(i, v) < 0)
 
-#define ATOMIC_INIT(i)			{ (i) }
+
+#ifdef CONFIG_GENERIC_ATOMIC64
 
 #include <asm-generic/atomic64.h>
 
-#endif
+#else	/* Kconfig ensures this is only enabled with needed h/w assist */
+
+/*
+ * ARCv2 supports 64-bit exclusive load (LLOCKD) / store (SCONDD)
+ *  - The address HAS to be 64-bit aligned
+ *  - There are 2 semantics involved here:
+ *    = exlusive implies no interim update between load/store to same addr
+ *    = both words are observed/updated together: this is guaranteed even
+ *      for regular 64-bit load (LDD) / store (STD). Thus atomic64_set()
+ *      is NOT required to use LLOCKD+SCONDD, STD suffices
+ */
+
+typedef struct {
+	aligned_u64 counter;
+} atomic64_t;
+
+#define ATOMIC64_INIT(a) { (a) }
+
+static inline long long atomic64_read(const atomic64_t *v)
+{
+	unsigned long long val;
+
+	__asm__ __volatile__(
+	"	ldd   %0, [%1]	\n"
+	: "=r"(val)
+	: "r"(&v->counter));
+
+	return val;
+}
+
+static inline void atomic64_set(atomic64_t *v, long long a)
+{
+	/*
+	 * This could have been a simple assignment in "C" but would need
+	 * explicit volatile. Otherwise gcc optimizers could elide the store
+	 * which borked atomic64 self test
+	 */
+	__asm__ __volatile__(
+	"	std   %0, [%1]	\n"
+	:
+	: "r"(a), "r"(&v->counter)
+	: "memory");
+}
+
+#define ATOMIC64_OP(op, op1, op2)					\
+static inline void atomic64_##op(long long a, atomic64_t *v)		\
+{									\
+	unsigned long long val;						\
+									\
+	__asm__ __volatile__(						\
+	"1:				\n"				\
+	"	llockd  %0, [%1]	\n"				\
+	"	" #op1 " %L0, %L0, %L2	\n"				\
+	"	" #op2 " %H0, %H0, %H2	\n"				\
+	"	scondd   %0, [%1]	\n"				\
+	"	bnz     1b		\n"				\
+	: "=&r"(val)							\
+	: "r"(&v->counter), "ir"(a)					\
+	: "cc");						\
+}									\
+
+#define ATOMIC64_OP_RETURN(op, op1, op2)		        	\
+static inline long long atomic64_##op##_return(long long a, atomic64_t *v)	\
+{									\
+	unsigned long long val;						\
+									\
+	smp_mb();							\
+									\
+	__asm__ __volatile__(						\
+	"1:				\n"				\
+	"	llockd   %0, [%1]	\n"				\
+	"	" #op1 " %L0, %L0, %L2	\n"				\
+	"	" #op2 " %H0, %H0, %H2	\n"				\
+	"	scondd   %0, [%1]	\n"				\
+	"	bnz     1b		\n"				\
+	: [val] "=&r"(val)						\
+	: "r"(&v->counter), "ir"(a)					\
+	: "cc");	/* memory clobber comes from smp_mb() */	\
+									\
+	smp_mb();							\
+									\
+	return val;							\
+}
+
+#define ATOMIC64_FETCH_OP(op, op1, op2)		        		\
+static inline long long atomic64_fetch_##op(long long a, atomic64_t *v)	\
+{									\
+	unsigned long long val, orig;					\
+									\
+	smp_mb();							\
+									\
+	__asm__ __volatile__(						\
+	"1:				\n"				\
+	"	llockd   %0, [%2]	\n"				\
+	"	" #op1 " %L1, %L0, %L3	\n"				\
+	"	" #op2 " %H1, %H0, %H3	\n"				\
+	"	scondd   %1, [%2]	\n"				\
+	"	bnz     1b		\n"				\
+	: "=&r"(orig), "=&r"(val)					\
+	: "r"(&v->counter), "ir"(a)					\
+	: "cc");	/* memory clobber comes from smp_mb() */	\
+									\
+	smp_mb();							\
+									\
+	return orig;							\
+}
+
+#define ATOMIC64_OPS(op, op1, op2)					\
+	ATOMIC64_OP(op, op1, op2)					\
+	ATOMIC64_OP_RETURN(op, op1, op2)				\
+	ATOMIC64_FETCH_OP(op, op1, op2)
+
+#define atomic64_andnot atomic64_andnot
+
+ATOMIC64_OPS(add, add.f, adc)
+ATOMIC64_OPS(sub, sub.f, sbc)
+ATOMIC64_OPS(and, and, and)
+ATOMIC64_OPS(andnot, bic, bic)
+ATOMIC64_OPS(or, or, or)
+ATOMIC64_OPS(xor, xor, xor)
+
+#undef ATOMIC64_OPS
+#undef ATOMIC64_FETCH_OP
+#undef ATOMIC64_OP_RETURN
+#undef ATOMIC64_OP
+
+static inline long long
+atomic64_cmpxchg(atomic64_t *ptr, long long expected, long long new)
+{
+	long long prev;
+
+	smp_mb();
+
+	__asm__ __volatile__(
+	"1:	llockd  %0, [%1]	\n"
+	"	brne    %L0, %L2, 2f	\n"
+	"	brne    %H0, %H2, 2f	\n"
+	"	scondd  %3, [%1]	\n"
+	"	bnz     1b		\n"
+	"2:				\n"
+	: "=&r"(prev)
+	: "r"(ptr), "ir"(expected), "r"(new)
+	: "cc");	/* memory clobber comes from smp_mb() */
+
+	smp_mb();
+
+	return prev;
+}
+
+static inline long long atomic64_xchg(atomic64_t *ptr, long long new)
+{
+	long long prev;
+
+	smp_mb();
+
+	__asm__ __volatile__(
+	"1:	llockd  %0, [%1]	\n"
+	"	scondd  %2, [%1]	\n"
+	"	bnz     1b		\n"
+	"2:				\n"
+	: "=&r"(prev)
+	: "r"(ptr), "r"(new)
+	: "cc");	/* memory clobber comes from smp_mb() */
+
+	smp_mb();
+
+	return prev;
+}
+
+/**
+ * atomic64_dec_if_positive - decrement by 1 if old value positive
+ * @v: pointer of type atomic64_t
+ *
+ * The function returns the old value of *v minus 1, even if
+ * the atomic variable, v, was not decremented.
+ */
+
+static inline long long atomic64_dec_if_positive(atomic64_t *v)
+{
+	long long val;
+
+	smp_mb();
+
+	__asm__ __volatile__(
+	"1:	llockd  %0, [%1]	\n"
+	"	sub.f   %L0, %L0, 1	# w0 - 1, set C on borrow\n"
+	"	sub.c   %H0, %H0, 1	# if C set, w1 - 1\n"
+	"	brlt    %H0, 0, 2f	\n"
+	"	scondd  %0, [%1]	\n"
+	"	bnz     1b		\n"
+	"2:				\n"
+	: "=&r"(val)
+	: "r"(&v->counter)
+	: "cc");	/* memory clobber comes from smp_mb() */
+
+	smp_mb();
+
+	return val;
+}
+
+/**
+ * atomic64_add_unless - add unless the number is a given value
+ * @v: pointer of type atomic64_t
+ * @a: the amount to add to v...
+ * @u: ...unless v is equal to u.
+ *
+ * if (v != u) { v += a; ret = 1} else {ret = 0}
+ * Returns 1 iff @v was not @u (i.e. if add actually happened)
+ */
+static inline int atomic64_add_unless(atomic64_t *v, long long a, long long u)
+{
+	long long val;
+	int op_done;
+
+	smp_mb();
+
+	__asm__ __volatile__(
+	"1:	llockd  %0, [%2]	\n"
+	"	mov	%1, 1		\n"
+	"	brne	%L0, %L4, 2f	# continue to add since v != u \n"
+	"	breq.d	%H0, %H4, 3f	# return since v == u \n"
+	"	mov	%1, 0		\n"
+	"2:				\n"
+	"	add.f   %L0, %L0, %L3	\n"
+	"	adc     %H0, %H0, %H3	\n"
+	"	scondd  %0, [%2]	\n"
+	"	bnz     1b		\n"
+	"3:				\n"
+	: "=&r"(val), "=&r" (op_done)
+	: "r"(&v->counter), "r"(a), "r"(u)
+	: "cc");	/* memory clobber comes from smp_mb() */
+
+	smp_mb();
+
+	return op_done;
+}
+
+#define atomic64_add_negative(a, v)	(atomic64_add_return((a), (v)) < 0)
+#define atomic64_inc(v)			atomic64_add(1LL, (v))
+#define atomic64_inc_return(v)		atomic64_add_return(1LL, (v))
+#define atomic64_inc_and_test(v)	(atomic64_inc_return(v) == 0)
+#define atomic64_sub_and_test(a, v)	(atomic64_sub_return((a), (v)) == 0)
+#define atomic64_dec(v)			atomic64_sub(1LL, (v))
+#define atomic64_dec_return(v)		atomic64_sub_return(1LL, (v))
+#define atomic64_dec_and_test(v)	(atomic64_dec_return((v)) == 0)
+#define atomic64_inc_not_zero(v)	atomic64_add_unless((v), 1LL, 0LL)
+
+#endif	/* !CONFIG_GENERIC_ATOMIC64 */
+
+#endif	/* !__ASSEMBLY__ */
 
 #endif
-- 
2.7.4



From Vineet.Gupta1 at synopsys.com  Thu Sep  8 15:24:10 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Thu, 8 Sep 2016 15:24:10 -0700
Subject: [PATCH] ARCv2: Implement atomic64 based on LLOCKD/SCONDD
 instructions
In-Reply-To: <1473362967-23750-1-git-send-email-vgupta@synopsys.com>
References: <1473362967-23750-1-git-send-email-vgupta@synopsys.com>
Message-ID: <7012c761-a355-d830-22bf-48db96a12452@synopsys.com>

On 09/08/2016 12:29 PM, Vineet Gupta wrote:
> One thing I'm not sure of is the lack of explicit memory clobber in
> barrier-less ops e.g. atomic64_add() (BTW same is true for 32-bit
> atomic_add() as well). Per commit 398aa66827 ("ARM: 6212/1: atomic ops:
> add memory constraints to inline asm ") Will fixed ARM code by adding
> appropriate constraint to atomic64_add(). For ARC instead adding memory
> clobber to atomic64_set() does the trick (otherwise self-test is broked)
> This is on ARC we can't possibly use "m" in atomic64_add() since that make gcc
> emit register relative effective addresses which LLOCKD/SCONDD are not
> allowed by ISA

So interestingly my self-test run fine, but I had this oldish version stashed
somewhere which did something liek below and that clearly generates wrong code.

int my_test_atomic(void)
{
    long v0 = 0x33333333;
    long onestwos = 0x11112222;

    atomic_t v = ATOMIC_INIT(v0);
    long long r = v0;
    int ret = 0;

    atomic_set(&v, v0); r = v0;
    atomic_add(onestwos, &v);
    r += onestwos;
    if (v.counter != r) {      /* <------ */
                ret = 3;   /* error */
    }

    return ret;
}

key here is the check - if we access the atomic directly, I get error. If I use
atomic_read() which forces a reload due to volatile, things are hunky dory. So it
seems to me we don't need memory clobber or equivalent in barrier less atomics
except the set. Seems too fragile ?

-Vineet


From peterz at infradead.org  Fri Sep  9 00:40:44 2016
From: peterz at infradead.org (Peter Zijlstra)
Date: Fri, 9 Sep 2016 09:40:44 +0200
Subject: [PATCH] ARCv2: Implement atomic64 based on LLOCKD/SCONDD
 instructions
In-Reply-To: <7012c761-a355-d830-22bf-48db96a12452@synopsys.com>
References: <1473362967-23750-1-git-send-email-vgupta@synopsys.com>
 <7012c761-a355-d830-22bf-48db96a12452@synopsys.com>
Message-ID: <20160909074044.GC10153@twins.programming.kicks-ass.net>

On Thu, Sep 08, 2016 at 03:24:10PM -0700, Vineet Gupta wrote:
> On 09/08/2016 12:29 PM, Vineet Gupta wrote:
> > One thing I'm not sure of is the lack of explicit memory clobber in
> > barrier-less ops e.g. atomic64_add() (BTW same is true for 32-bit
> > atomic_add() as well). Per commit 398aa66827 ("ARM: 6212/1: atomic ops:
> > add memory constraints to inline asm ") Will fixed ARM code by adding
> > appropriate constraint to atomic64_add(). For ARC instead adding memory
> > clobber to atomic64_set() does the trick (otherwise self-test is broked)
> > This is on ARC we can't possibly use "m" in atomic64_add() since that make gcc
> > emit register relative effective addresses which LLOCKD/SCONDD are not
> > allowed by ISA
> 
> So interestingly my self-test run fine, but I had this oldish version stashed
> somewhere which did something liek below and that clearly generates wrong code.
> 
> int my_test_atomic(void)
> {
>     long v0 = 0x33333333;
>     long onestwos = 0x11112222;
> 
>     atomic_t v = ATOMIC_INIT(v0);
>     long long r = v0;
>     int ret = 0;
> 
>     atomic_set(&v, v0); r = v0;
>     atomic_add(onestwos, &v);
>     r += onestwos;
>     if (v.counter != r) {      /* <------ */
>                 ret = 3;   /* error */
>     }
> 
>     return ret;
> }
> 
> key here is the check - if we access the atomic directly, I get error. If I use
> atomic_read() which forces a reload due to volatile, things are hunky dory. So it
> seems to me we don't need memory clobber or equivalent in barrier less atomics
> except the set. Seems too fragile ?

Accessing atomic_t::counter without the accessors is undefined behaviour
and you pretty much get to keep whatever pieces, although volatile
accesses generally work (except when it doesn't, see blackfin SMP for
example).

atomic_set() should be at least WRITE_ONCE().
atomic_read() should be at least READ_ONCE().

atomic_$op(), atomic_fetch_$op_relaxed() and atomic_$op_return_relaxed()
need not imply any sort of barrier, compiler or otherwise.

atomic_fetch_$op() and atomic_$op_return(), which imply memory ordering,
also very much imply a compiler barrier, since all memory barriers do.



From gregkh at linuxfoundation.org  Fri Sep  9 04:39:11 2016
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 9 Sep 2016 13:39:11 +0200
Subject: WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously
 submitted to be applied to the 4.7-stable tree?
In-Reply-To: <df4f96e8-fb05-ec81-6b32-ff6bc54ad853@synopsys.com>
References: <1473080592214136@kroah.com>
 <584a8fcd-6876-de0d-3c5e-8b4dad12c49d@synopsys.com>
 <20160906193810.GB22028@kroah.com>
 <7ab12d76-875a-c06f-08e3-ef628edda1b9@synopsys.com>
 <1e3ae422-d8ff-326e-29bd-b58002b5163b@synopsys.com>
 <20160907062852.GA1287@kroah.com>
 <df4f96e8-fb05-ec81-6b32-ff6bc54ad853@synopsys.com>
Message-ID: <20160909113911.GD28372@kroah.com>

On Wed, Sep 07, 2016 at 09:38:25AM -0700, Vineet Gupta wrote:
> On 09/06/2016 11:28 PM, Greg Kroah-Hartman wrote:
> > On Tue, Sep 06, 2016 at 01:28:45PM -0700, Vineet Gupta wrote:
> >> On 09/06/2016 01:22 PM, Vineet Gupta wrote:
> >>>> Not "we need to support gcc6 for
> >>>> old kernels", as really, if someone wants to update userspace, they
> >>>> don't update their kernel?
> >> FWIW, I'm not arguing for the backport inclusion - I'm just trying to explain the
> >> context more.
> >>
> >> Thing is your regular user/customer don't really care/know about these details. So
> >> there are tools bugs and more often than not the easy answer for tools providers
> >> is "this is a known issue in gcc x.y which has been fixed in gcc x2.y2 so consider
> >> upgrading". So it is for such class of users that having such backports makes life
> >> a little easy.
> > That's fine, but who would be upgrading their userspace gcc and then
> > wanting to rebuild their kernel for an old kernel release? 
> 
> IMHO those are totally unrelated things. user-space gcc/tools upgrade can be
> forced upon customers by processor vendors (us) saying new tools come with boat
> load of fixes etc and more often that not it is indeed the case. OTOH, customers
> typically like to lock into a specific kernel baseline for longish duration
> because (1) they have out of tree drivers - (2) they have production systems,
> where they would be iffy to change to a new kernel because prev one is stable etc.
> I know above seem like made up points and it is easy to dismiss them given that
> (1)  We don't really work our processes for "enabling" out of tree stuff and (2) a
> new gcc is more unstable than a new kernel. But that is the mindset when you talk
> to them.
> 
> >  What prevents them from also updating their kernel?
> 
> Their platform baseline and out of tree drivers. Given my experience with
> maintaining arch port, in the past, an arch rebase has been easier than rebasing
> the drivers because of the framework improvements, API changes....

If they have huge patches for their kernels, adding yet-another-one for
the gcc change should be just fine, right?  And you know they aren't
updating their base stable kernel release number, so even if this was
added to the stable trees, they wouldn't see it :(

Unless ARC customers are better than others?

thanks,

greg k-h


From Vineet.Gupta1 at synopsys.com  Fri Sep  9 10:08:39 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Fri, 9 Sep 2016 10:08:39 -0700
Subject: WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously
 submitted to be applied to the 4.7-stable tree?
In-Reply-To: <20160909113911.GD28372@kroah.com>
References: <1473080592214136@kroah.com>
 <584a8fcd-6876-de0d-3c5e-8b4dad12c49d@synopsys.com>
 <20160906193810.GB22028@kroah.com>
 <7ab12d76-875a-c06f-08e3-ef628edda1b9@synopsys.com>
 <1e3ae422-d8ff-326e-29bd-b58002b5163b@synopsys.com>
 <20160907062852.GA1287@kroah.com>
 <df4f96e8-fb05-ec81-6b32-ff6bc54ad853@synopsys.com>
 <20160909113911.GD28372@kroah.com>
Message-ID: <3a40ba02-36a6-d92b-0187-148c96488816@synopsys.com>

On 09/09/2016 04:39 AM, Greg Kroah-Hartman wrote:
> On Wed, Sep 07, 2016 at 09:38:25AM -0700, Vineet Gupta wrote:
>> On 09/06/2016 11:28 PM, Greg Kroah-Hartman wrote:
>>> On Tue, Sep 06, 2016 at 01:28:45PM -0700, Vineet Gupta wrote:
>>>> On 09/06/2016 01:22 PM, Vineet Gupta wrote:
>>>>>> Not "we need to support gcc6 for
>>>>>> old kernels", as really, if someone wants to update userspace, they
>>>>>> don't update their kernel?
>>>> FWIW, I'm not arguing for the backport inclusion - I'm just trying to explain the
>>>> context more.
>>>>
>>>> Thing is your regular user/customer don't really care/know about these details. So
>>>> there are tools bugs and more often than not the easy answer for tools providers
>>>> is "this is a known issue in gcc x.y which has been fixed in gcc x2.y2 so consider
>>>> upgrading". So it is for such class of users that having such backports makes life
>>>> a little easy.
>>> That's fine, but who would be upgrading their userspace gcc and then
>>> wanting to rebuild their kernel for an old kernel release? 
>> IMHO those are totally unrelated things. user-space gcc/tools upgrade can be
>> forced upon customers by processor vendors (us) saying new tools come with boat
>> load of fixes etc and more often that not it is indeed the case. OTOH, customers
>> typically like to lock into a specific kernel baseline for longish duration
>> because (1) they have out of tree drivers - (2) they have production systems,
>> where they would be iffy to change to a new kernel because prev one is stable etc.
>> I know above seem like made up points and it is easy to dismiss them given that
>> (1)  We don't really work our processes for "enabling" out of tree stuff and (2) a
>> new gcc is more unstable than a new kernel. But that is the mindset when you talk
>> to them.
>>
>>>  What prevents them from also updating their kernel?
>> Their platform baseline and out of tree drivers. Given my experience with
>> maintaining arch port, in the past, an arch rebase has been easier than rebasing
>> the drivers because of the framework improvements, API changes....
> If they have huge patches for their kernels, adding yet-another-one for
> the gcc change should be just fine, right? 

That is true.

>  And you know they aren't
> updating their base stable kernel release number, so even if this was
> added to the stable trees, they wouldn't see it :(

I'd presume they will follow the stable bumps - otherwise it is pointless to ask
for backport in first place.

-Vineet


From Vineet.Gupta1 at synopsys.com  Fri Sep  9 11:20:51 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Fri, 9 Sep 2016 11:20:51 -0700
Subject: [PATCH v2] ARCv2: Implement atomic64 based on LLOCKD/SCONDD
 instructions
Message-ID: <1473445251-18260-1-git-send-email-vgupta@synopsys.com>

ARCv2 ISA provides 64-bit exclusive load/stores so use them to implement
the 64-bit atomics and elide the spinlock based generic 64-bit atomics

boot tested with atomic64 self-test (and GOD bless the person who wrote
them, I realized my inline assmebly is sloppy as hell)

Cc: Peter Zijlstra <peterz at infradead.org>
Cc: Will Deacon <will.deacon at arm.com>
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
---
changes since v2
 - Removed questions aboutt compiler barrier from changelog
 - added some comments to same effect in atomic64_set()
 - fixes a few spellos in comment/changelog
---
 arch/arc/Kconfig              |   2 +-
 arch/arc/include/asm/atomic.h | 262 +++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 261 insertions(+), 3 deletions(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 0d3e59f56974..073b3582544b 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -13,7 +13,7 @@ config ARC
 	select CLKSRC_OF
 	select CLONE_BACKWARDS
 	select COMMON_CLK
-	select GENERIC_ATOMIC64
+	select GENERIC_ATOMIC64 if !ISA_ARCV2 || !(ARC_HAS_LL64 && ARC_HAS_LLSC)
 	select GENERIC_CLOCKEVENTS
 	select GENERIC_FIND_FIRST_BIT
 	# for now, we don't need GENERIC_IRQ_PROBE, CONFIG_GENERIC_IRQ_CHIP
diff --git a/arch/arc/include/asm/atomic.h b/arch/arc/include/asm/atomic.h
index 4e3c1b6b0806..288ad07b69b5 100644
--- a/arch/arc/include/asm/atomic.h
+++ b/arch/arc/include/asm/atomic.h
@@ -20,6 +20,7 @@
 #ifndef CONFIG_ARC_PLAT_EZNPS
 
 #define atomic_read(v)  READ_ONCE((v)->counter)
+#define ATOMIC_INIT(i)	{ (i) }
 
 #ifdef CONFIG_ARC_HAS_LLSC
 
@@ -343,10 +344,267 @@ ATOMIC_OPS(xor, ^=, CTOP_INST_AXOR_DI_R2_R2_R3)
 
 #define atomic_add_negative(i, v)	(atomic_add_return(i, v) < 0)
 
-#define ATOMIC_INIT(i)			{ (i) }
+
+#ifdef CONFIG_GENERIC_ATOMIC64
 
 #include <asm-generic/atomic64.h>
 
-#endif
+#else	/* Kconfig ensures this is only enabled with needed h/w assist */
+
+/*
+ * ARCv2 supports 64-bit exclusive load (LLOCKD) / store (SCONDD)
+ *  - The address HAS to be 64-bit aligned
+ *  - There are 2 semantics involved here:
+ *    = exclusive implies no interim update between load/store to same addr
+ *    = both words are observed/updated together: this is guaranteed even
+ *      for regular 64-bit load (LDD) / store (STD). Thus atomic64_set()
+ *      is NOT required to use LLOCKD+SCONDD, STD suffices
+ */
+
+typedef struct {
+	aligned_u64 counter;
+} atomic64_t;
+
+#define ATOMIC64_INIT(a) { (a) }
+
+static inline long long atomic64_read(const atomic64_t *v)
+{
+	unsigned long long val;
+
+	__asm__ __volatile__(
+	"	ldd   %0, [%1]	\n"
+	: "=r"(val)
+	: "r"(&v->counter));
+
+	return val;
+}
+
+static inline void atomic64_set(atomic64_t *v, long long a)
+{
+	/*
+	 * This could have been a simple assignment in "C" but would need
+	 * explicit volatile. Otherwise gcc optimizers could elide the store
+	 * which borked atomic64 self-test
+	 * In the inline asm version, memory clobber needed for exact same reson,
+	 * to tell gcc about the store.
+	 *
+	 * This however is not needed for sibling atomic64_add() etc since
+	 * both load/store are explicitly done in inline asm. As long as API
+	 * is called for each access, gcc has no way to optimize away and of the
+	 * load or store
+	 */
+	__asm__ __volatile__(
+	"	std   %0, [%1]	\n"
+	:
+	: "r"(a), "r"(&v->counter)
+	: "memory");
+}
+
+#define ATOMIC64_OP(op, op1, op2)					\
+static inline void atomic64_##op(long long a, atomic64_t *v)		\
+{									\
+	unsigned long long val;						\
+									\
+	__asm__ __volatile__(						\
+	"1:				\n"				\
+	"	llockd  %0, [%1]	\n"				\
+	"	" #op1 " %L0, %L0, %L2	\n"				\
+	"	" #op2 " %H0, %H0, %H2	\n"				\
+	"	scondd   %0, [%1]	\n"				\
+	"	bnz     1b		\n"				\
+	: "=&r"(val)							\
+	: "r"(&v->counter), "ir"(a)					\
+	: "cc");						\
+}									\
+
+#define ATOMIC64_OP_RETURN(op, op1, op2)		        	\
+static inline long long atomic64_##op##_return(long long a, atomic64_t *v)	\
+{									\
+	unsigned long long val;						\
+									\
+	smp_mb();							\
+									\
+	__asm__ __volatile__(						\
+	"1:				\n"				\
+	"	llockd   %0, [%1]	\n"				\
+	"	" #op1 " %L0, %L0, %L2	\n"				\
+	"	" #op2 " %H0, %H0, %H2	\n"				\
+	"	scondd   %0, [%1]	\n"				\
+	"	bnz     1b		\n"				\
+	: [val] "=&r"(val)						\
+	: "r"(&v->counter), "ir"(a)					\
+	: "cc");	/* memory clobber comes from smp_mb() */	\
+									\
+	smp_mb();							\
+									\
+	return val;							\
+}
+
+#define ATOMIC64_FETCH_OP(op, op1, op2)		        		\
+static inline long long atomic64_fetch_##op(long long a, atomic64_t *v)	\
+{									\
+	unsigned long long val, orig;					\
+									\
+	smp_mb();							\
+									\
+	__asm__ __volatile__(						\
+	"1:				\n"				\
+	"	llockd   %0, [%2]	\n"				\
+	"	" #op1 " %L1, %L0, %L3	\n"				\
+	"	" #op2 " %H1, %H0, %H3	\n"				\
+	"	scondd   %1, [%2]	\n"				\
+	"	bnz     1b		\n"				\
+	: "=&r"(orig), "=&r"(val)					\
+	: "r"(&v->counter), "ir"(a)					\
+	: "cc");	/* memory clobber comes from smp_mb() */	\
+									\
+	smp_mb();							\
+									\
+	return orig;							\
+}
+
+#define ATOMIC64_OPS(op, op1, op2)					\
+	ATOMIC64_OP(op, op1, op2)					\
+	ATOMIC64_OP_RETURN(op, op1, op2)				\
+	ATOMIC64_FETCH_OP(op, op1, op2)
+
+#define atomic64_andnot atomic64_andnot
+
+ATOMIC64_OPS(add, add.f, adc)
+ATOMIC64_OPS(sub, sub.f, sbc)
+ATOMIC64_OPS(and, and, and)
+ATOMIC64_OPS(andnot, bic, bic)
+ATOMIC64_OPS(or, or, or)
+ATOMIC64_OPS(xor, xor, xor)
+
+#undef ATOMIC64_OPS
+#undef ATOMIC64_FETCH_OP
+#undef ATOMIC64_OP_RETURN
+#undef ATOMIC64_OP
+
+static inline long long
+atomic64_cmpxchg(atomic64_t *ptr, long long expected, long long new)
+{
+	long long prev;
+
+	smp_mb();
+
+	__asm__ __volatile__(
+	"1:	llockd  %0, [%1]	\n"
+	"	brne    %L0, %L2, 2f	\n"
+	"	brne    %H0, %H2, 2f	\n"
+	"	scondd  %3, [%1]	\n"
+	"	bnz     1b		\n"
+	"2:				\n"
+	: "=&r"(prev)
+	: "r"(ptr), "ir"(expected), "r"(new)
+	: "cc");	/* memory clobber comes from smp_mb() */
+
+	smp_mb();
+
+	return prev;
+}
+
+static inline long long atomic64_xchg(atomic64_t *ptr, long long new)
+{
+	long long prev;
+
+	smp_mb();
+
+	__asm__ __volatile__(
+	"1:	llockd  %0, [%1]	\n"
+	"	scondd  %2, [%1]	\n"
+	"	bnz     1b		\n"
+	"2:				\n"
+	: "=&r"(prev)
+	: "r"(ptr), "r"(new)
+	: "cc");	/* memory clobber comes from smp_mb() */
+
+	smp_mb();
+
+	return prev;
+}
+
+/**
+ * atomic64_dec_if_positive - decrement by 1 if old value positive
+ * @v: pointer of type atomic64_t
+ *
+ * The function returns the old value of *v minus 1, even if
+ * the atomic variable, v, was not decremented.
+ */
+
+static inline long long atomic64_dec_if_positive(atomic64_t *v)
+{
+	long long val;
+
+	smp_mb();
+
+	__asm__ __volatile__(
+	"1:	llockd  %0, [%1]	\n"
+	"	sub.f   %L0, %L0, 1	# w0 - 1, set C on borrow\n"
+	"	sub.c   %H0, %H0, 1	# if C set, w1 - 1\n"
+	"	brlt    %H0, 0, 2f	\n"
+	"	scondd  %0, [%1]	\n"
+	"	bnz     1b		\n"
+	"2:				\n"
+	: "=&r"(val)
+	: "r"(&v->counter)
+	: "cc");	/* memory clobber comes from smp_mb() */
+
+	smp_mb();
+
+	return val;
+}
+
+/**
+ * atomic64_add_unless - add unless the number is a given value
+ * @v: pointer of type atomic64_t
+ * @a: the amount to add to v...
+ * @u: ...unless v is equal to u.
+ *
+ * if (v != u) { v += a; ret = 1} else {ret = 0}
+ * Returns 1 iff @v was not @u (i.e. if add actually happened)
+ */
+static inline int atomic64_add_unless(atomic64_t *v, long long a, long long u)
+{
+	long long val;
+	int op_done;
+
+	smp_mb();
+
+	__asm__ __volatile__(
+	"1:	llockd  %0, [%2]	\n"
+	"	mov	%1, 1		\n"
+	"	brne	%L0, %L4, 2f	# continue to add since v != u \n"
+	"	breq.d	%H0, %H4, 3f	# return since v == u \n"
+	"	mov	%1, 0		\n"
+	"2:				\n"
+	"	add.f   %L0, %L0, %L3	\n"
+	"	adc     %H0, %H0, %H3	\n"
+	"	scondd  %0, [%2]	\n"
+	"	bnz     1b		\n"
+	"3:				\n"
+	: "=&r"(val), "=&r" (op_done)
+	: "r"(&v->counter), "r"(a), "r"(u)
+	: "cc");	/* memory clobber comes from smp_mb() */
+
+	smp_mb();
+
+	return op_done;
+}
+
+#define atomic64_add_negative(a, v)	(atomic64_add_return((a), (v)) < 0)
+#define atomic64_inc(v)			atomic64_add(1LL, (v))
+#define atomic64_inc_return(v)		atomic64_add_return(1LL, (v))
+#define atomic64_inc_and_test(v)	(atomic64_inc_return(v) == 0)
+#define atomic64_sub_and_test(a, v)	(atomic64_sub_return((a), (v)) == 0)
+#define atomic64_dec(v)			atomic64_sub(1LL, (v))
+#define atomic64_dec_return(v)		atomic64_sub_return(1LL, (v))
+#define atomic64_dec_and_test(v)	(atomic64_dec_return((v)) == 0)
+#define atomic64_inc_not_zero(v)	atomic64_add_unless((v), 1LL, 0LL)
+
+#endif	/* !CONFIG_GENERIC_ATOMIC64 */
+
+#endif	/* !__ASSEMBLY__ */
 
 #endif
-- 
2.7.4



From wbx at uclibc-ng.org  Sat Sep 10 05:05:34 2016
From: wbx at uclibc-ng.org (Waldemar Brodkorb)
Date: Sat, 10 Sep 2016 14:05:34 +0200
Subject: [PATCH] ARC: Fix max ULP for cosine test
In-Reply-To: <1471945278-18247-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
References: <1471945278-18247-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
Message-ID: <20160910120534.GD6777@waldemar-brodkorb.de>

Hi Eugeniy,
Eugeniy Paltsev wrote,

> Max ULP for "cos (M_PI_6l * 2.0) == 0.5" in "test-double" sub-test
> is set to "0" for ARC. It causes "test-double" test failure.
> 
> I realized that this sub-test on ARM gets completely same results.
> But it doesn't fails on ARM because max ULP is set to "1" for ARM.
> 
> I am wondering, if it was done for any special reason?
> 
> Otherwise, set max ULP for "cos (M_PI_6l * 2.0) == 0.5" test to
> "1" instead of "0" for ARC.

Thanks applied and pushed. Normally I autogenerate the ULPS files
with tst-float -u .. and then merging with the perl script.

best regards
 Waldemar


From lkp at intel.com  Sat Sep 10 21:31:50 2016
From: lkp at intel.com (kbuild test robot)
Date: Sun, 11 Sep 2016 12:31:50 +0800
Subject: [PATCH] atomic64: No need for
 CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
In-Reply-To: <1473352098-5822-1-git-send-email-vgupta@synopsys.com>
Message-ID: <201609111259.q67d9T4B%fengguang.wu@intel.com>

Hi Vineet,

[auto build test ERROR on arm64/for-next/core]
[cannot apply to linus/master linux/master v4.8-rc5 next-20160909]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:    https://github.com/0day-ci/linux/commits/Vineet-Gupta/atomic64-No-need-for-CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE/20160909-013936
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 4.9.0
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   lib/atomic64_test.c: In function 'test_atomic64':
>> lib/atomic64_test.c:217:2: error: implicit declaration of function 'atomic64_dec_if_positive' [-Werror=implicit-function-declaration]
     BUG_ON(atomic64_dec_if_positive(&v) != (onestwos - 1));
     ^
   cc1: some warnings being treated as errors

vim +/atomic64_dec_if_positive +217 lib/atomic64_test.c

86a89380 Luca Barbieri 2010-02-24  211  	INIT(v0);
9efbcd59 Luca Barbieri 2010-03-01  212  	BUG_ON(!atomic64_add_unless(&v, one, v1));
86a89380 Luca Barbieri 2010-02-24  213  	r += one;
86a89380 Luca Barbieri 2010-02-24  214  	BUG_ON(v.counter != r);
86a89380 Luca Barbieri 2010-02-24  215  
86a89380 Luca Barbieri 2010-02-24  216  	INIT(onestwos);
86a89380 Luca Barbieri 2010-02-24 @217  	BUG_ON(atomic64_dec_if_positive(&v) != (onestwos - 1));
86a89380 Luca Barbieri 2010-02-24  218  	r -= one;
86a89380 Luca Barbieri 2010-02-24  219  	BUG_ON(v.counter != r);
86a89380 Luca Barbieri 2010-02-24  220  

:::::: The code at line 217 was first introduced by commit
:::::: 86a8938078a8bb518c5376de493e348c7490d506 lib: Add self-test for atomic64_t

:::::: TO: Luca Barbieri <luca at luca-barbieri.com>
:::::: CC: H. Peter Anvin <hpa at zytor.com>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 44278 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-snps-arc/attachments/20160911/f694dbce/attachment-0001.obj>

From yuriy.kolerov at synopsys.com  Mon Sep 12 08:55:03 2016
From: yuriy.kolerov at synopsys.com (Yuriy Kolerov)
Date: Mon, 12 Sep 2016 18:55:03 +0300
Subject: [PATCH] ARCv2: intc: Use kflag if STATUS32.IE must be reset
Message-ID: <1473695703-29547-1-git-send-email-yuriy.kolerov@synopsys.com>

In the end of "arc_init_IRQ" STATUS32.IE flag is going to be affected by
"flag" instruction but "flag" never touches IE flag on ARCv2. So "kflag"
instruction must be used instead of "flag".

Signed-off-by: Yuriy Kolerov <yuriy.kolerov at synopsys.com>
---
 arch/arc/kernel/intc-arcv2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arc/kernel/intc-arcv2.c b/arch/arc/kernel/intc-arcv2.c
index 6c24faf..62b59409 100644
--- a/arch/arc/kernel/intc-arcv2.c
+++ b/arch/arc/kernel/intc-arcv2.c
@@ -74,7 +74,7 @@ void arc_init_IRQ(void)
 	tmp = read_aux_reg(0xa);
 	tmp |= STATUS_AD_MASK | (irq_prio << 1);
 	tmp &= ~STATUS_IE_MASK;
-	asm volatile("flag %0	\n"::"r"(tmp));
+	asm volatile("kflag %0	\n"::"r"(tmp));
 }
 
 static void arcv2_irq_mask(struct irq_data *data)
-- 
2.7.4




From Vineet.Gupta1 at synopsys.com  Mon Sep 12 10:47:10 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Mon, 12 Sep 2016 10:47:10 -0700
Subject: [PATCH v2 0/2] Getting rid of CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
Message-ID: <1473702432-8116-1-git-send-email-vgupta@synopsys.com>

Hi Peter / Tony.

So kbuild service reported build failure of ia64 with my prev patch.
I've added an untested atomic64_dec_if_positive() to ia64, shamelessly
copied from s390 with some adjustments 64-bit long etc. Could you please
double check.

It builds fine with ia64 cross compiler.

Thx,
-Vineet

Vineet Gupta (2):
  ia64: implement atomic64_dec_if_positive
  atomic64: No need for CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE

 arch/alpha/Kconfig             |  1 -
 arch/arm/Kconfig               |  1 -
 arch/arm64/Kconfig             |  1 -
 arch/ia64/include/asm/atomic.h | 16 ++++++++++++++++
 arch/mips/Kconfig              |  1 -
 arch/parisc/Kconfig            |  1 -
 arch/powerpc/Kconfig           |  1 -
 arch/s390/Kconfig              |  2 +-
 arch/sparc/Kconfig             |  1 -
 arch/tile/Kconfig              |  2 +-
 arch/x86/Kconfig               |  2 +-
 lib/Kconfig                    |  3 ---
 lib/atomic64_test.c            |  4 ----
 13 files changed, 19 insertions(+), 17 deletions(-)

-- 
2.7.4



From Vineet.Gupta1 at synopsys.com  Mon Sep 12 10:47:11 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Mon, 12 Sep 2016 10:47:11 -0700
Subject: [PATCH v2 1/2] ia64: implement atomic64_dec_if_positive
In-Reply-To: <1473702432-8116-1-git-send-email-vgupta@synopsys.com>
References: <1473702432-8116-1-git-send-email-vgupta@synopsys.com>
Message-ID: <1473702432-8116-2-git-send-email-vgupta@synopsys.com>

This is based on s390 version and needed to get rid of
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE

Cc: Tony Luck <tony.luck at intel.com>
Cc: Fenghua Yu <fenghua.yu at intel.com>
Cc: Ingo Molnar <mingo at kernel.org>
Cc: Peter Zijlstra <peterz at infradead.org>
Cc: linux-ia64 at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
---
 arch/ia64/include/asm/atomic.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/ia64/include/asm/atomic.h b/arch/ia64/include/asm/atomic.h
index f565ad376142..65d4bb2b6685 100644
--- a/arch/ia64/include/asm/atomic.h
+++ b/arch/ia64/include/asm/atomic.h
@@ -269,6 +269,22 @@ static __inline__ long atomic64_add_unless(atomic64_t *v, long a, long u)
 
 #define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
 
+static __inline__ long atomic64_dec_if_positive(atomic64_t *v)
+{
+	long c, old, dec;
+	c = atomic64_read(v);
+	for (;;) {
+		dec = c - 1;
+		if (unlikely(dec < 0))
+			break;
+		old = atomic64_cmpxchg((v), c, dec);
+		if (likely(old == c))
+			break;
+		c = old;
+	}
+	return dec;
+}
+
 /*
  * Atomically add I to V and return TRUE if the resulting value is
  * negative.
-- 
2.7.4



From Vineet.Gupta1 at synopsys.com  Mon Sep 12 10:47:12 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Mon, 12 Sep 2016 10:47:12 -0700
Subject: [PATCH v2 2/2] atomic64: No need for
 CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
In-Reply-To: <1473702432-8116-1-git-send-email-vgupta@synopsys.com>
References: <1473702432-8116-1-git-send-email-vgupta@synopsys.com>
Message-ID: <1473702432-8116-3-git-send-email-vgupta@synopsys.com>

This came to light when implementing native 64-bit atomics for ARCv2.

The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
to check whether atomic64_dec_if_positive() is available.
It seems it was needed when not every arch defined it.
However as of current code the Kconfig option seems needless

- for CONFIG_GENERIC_ATOMIC64 it is auto-enabled in lib/Kconfig and a
  generic definition of API is present lib/atomic64.c
- arches with native 64-bit atomics select it in arch/*/Kconfig and
  define the API in their headers

So I see no point in keeping the Kconfig option

Compile tested for:
 - blackfin (CONFIG_GENERIC_ATOMIC64)
 - x86 (!CONFIG_GENERIC_ATOMIC64)
 - ia64

Cc: Richard Henderson <rth at twiddle.net>
Cc: Ivan Kokshaysky <ink at jurassic.park.msu.ru>
Cc: Matt Turner <mattst88 at gmail.com>
Cc: Russell King <linux at armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Ralf Baechle <ralf at linux-mips.org>
Cc: "James E.J. Bottomley" <jejb at parisc-linux.org>
Cc: Helge Deller <deller at gmx.de>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Paul Mackerras <paulus at samba.org>
Cc: Michael Ellerman <mpe at ellerman.id.au>
Cc: Martin Schwidefsky <schwidefsky at de.ibm.com>
Cc: Heiko Carstens <heiko.carstens at de.ibm.com>
Cc: "David S. Miller" <davem at davemloft.net>
Cc: Chris Metcalf <cmetcalf at mellanox.com>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Ingo Molnar <mingo at redhat.com>
Cc: "H. Peter Anvin" <hpa at zytor.com>
Cc: x86 at kernel.org
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Vineet Gupta <vgupta at synopsys.com>
Cc: Zhaoxiu Zeng <zhaoxiu.zeng at gmail.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Matthew Wilcox <willy at linux.intel.com>
Cc: Alexander Potapenko <glider at google.com>
Cc: Andrey Ryabinin <aryabinin at virtuozzo.com>
Cc: Herbert Xu <herbert at gondor.apana.org.au>
Cc: Ming Lin <ming.l at ssi.samsung.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Geert Uytterhoeven <geert at linux-m68k.org>
Cc: Peter Zijlstra <peterz at infradead.org>
Cc: Borislav Petkov <bp at suse.de>
Cc: Andi Kleen <ak at linux.intel.com>
Cc: Boqun Feng <boqun.feng at gmail.com>
Cc: linux-alpha at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-mips at linux-mips.org
Cc: linux-parisc at vger.kernel.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-s390 at vger.kernel.org
Cc: sparclinux at vger.kernel.org
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-arch at vger.kernel.org
Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
---
 arch/alpha/Kconfig   | 1 -
 arch/arm/Kconfig     | 1 -
 arch/arm64/Kconfig   | 1 -
 arch/mips/Kconfig    | 1 -
 arch/parisc/Kconfig  | 1 -
 arch/powerpc/Kconfig | 1 -
 arch/s390/Kconfig    | 2 +-
 arch/sparc/Kconfig   | 1 -
 arch/tile/Kconfig    | 2 +-
 arch/x86/Kconfig     | 2 +-
 lib/Kconfig          | 3 ---
 lib/atomic64_test.c  | 4 ----
 12 files changed, 3 insertions(+), 17 deletions(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 7f312d80b43b..0e49d39ea74a 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -15,7 +15,6 @@ config ALPHA
 	select GENERIC_IRQ_SHOW
 	select ARCH_WANT_IPC_PARSE_VERSION
 	select ARCH_HAVE_NMI_SAFE_CMPXCHG
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select AUDIT_ARCH
 	select GENERIC_CLOCKEVENTS
 	select GENERIC_SMP_IDLE_THREAD
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a9c4e48bb7ec..2a50957c7bfb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1,7 +1,6 @@
 config ARM
 	bool
 	default y
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index bc3f00f586f1..3df2ca7efbcc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -6,7 +6,6 @@ config ARM64
 	select ACPI_MCFG if ACPI
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_GCOV_PROFILE_ALL
 	select ARCH_HAS_KCOV
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 26388562e300..5bbea197c220 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -30,7 +30,6 @@ config MIPS
 	select HAVE_ARCH_TRANSPARENT_HUGEPAGE if CPU_SUPPORTS_HUGEPAGES && 64BIT
 	select RTC_LIB if !MACH_LOONGSON64
 	select GENERIC_ATOMIC64 if !64BIT
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select HAVE_DMA_CONTIGUOUS
 	select HAVE_DMA_API_DEBUG
 	select GENERIC_IRQ_PROBE
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index af12c2db9bb8..8a96bdcc3807 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -14,7 +14,6 @@ config PARISC
 	select BUILDTIME_EXTABLE_SORT
 	select HAVE_PERF_EVENTS
 	select GENERIC_ATOMIC64 if !64BIT
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select BROKEN_RODATA
 	select GENERIC_IRQ_PROBE
 	select GENERIC_PCI_IOMAP
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 927d2ab2ce08..18d1b42cf545 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -113,7 +113,6 @@ config PPC
 	select HAVE_DEBUG_KMEMLEAK
 	select ARCH_HAS_SG_CHAIN
 	select GENERIC_ATOMIC64 if PPC32
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select HAVE_PERF_EVENTS
 	select HAVE_PERF_REGS
 	select HAVE_PERF_USER_STACK_DUMP
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index c109f073d454..af52b07efde2 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -67,7 +67,7 @@ config DEBUG_RODATA
 
 config S390
 	def_bool y
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
+	select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_GCOV_PROFILE_ALL
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 59b09600dd32..bfedbe0cb7b2 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -22,7 +22,6 @@ config SPARC
 	select HAVE_ARCH_TRACEHOOK
 	select HAVE_EXIT_THREAD
 	select SYSCTL_EXCEPTION_TRACE
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select RTC_CLASS
 	select RTC_DRV_M48T59
 	select RTC_SYSTOHC
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 78da75b670bc..12eda5440c93 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -3,7 +3,7 @@
 
 config TILE
 	def_bool y
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
+	select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAVE_NMI_SAFE_CMPXCHG
 	select ARCH_WANT_FRAME_POINTERS
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2a1f0ce7c59a..0cf609998550 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -23,7 +23,7 @@ config X86
 	select ARCH_CLOCKSOURCE_DATA
 	select ARCH_DISCARD_MEMBLOCK
 	select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
+	select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_FAST_MULTIPLIER
diff --git a/lib/Kconfig b/lib/Kconfig
index d79909dc01ec..0e74df3c5441 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -457,9 +457,6 @@ config NLATTR
 config GENERIC_ATOMIC64
        bool
 
-config ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
-	def_bool y if GENERIC_ATOMIC64
-
 config LRU_CACHE
 	tristate
 
diff --git a/lib/atomic64_test.c b/lib/atomic64_test.c
index dbb369145dda..46042901130f 100644
--- a/lib/atomic64_test.c
+++ b/lib/atomic64_test.c
@@ -213,7 +213,6 @@ static __init void test_atomic64(void)
 	r += one;
 	BUG_ON(v.counter != r);
 
-#ifdef CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	INIT(onestwos);
 	BUG_ON(atomic64_dec_if_positive(&v) != (onestwos - 1));
 	r -= one;
@@ -226,9 +225,6 @@ static __init void test_atomic64(void)
 	INIT(-one);
 	BUG_ON(atomic64_dec_if_positive(&v) != (-one - one));
 	BUG_ON(v.counter != r);
-#else
-#warning Please implement atomic64_dec_if_positive for your architecture and select the above Kconfig symbol
-#endif
 
 	INIT(onestwos);
 	BUG_ON(!atomic64_inc_not_zero(&v));
-- 
2.7.4



From Vineet.Gupta1 at synopsys.com  Mon Sep 12 10:58:01 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Mon, 12 Sep 2016 10:58:01 -0700
Subject: [PATCH v3 0/2] Getting rid of CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
In-Reply-To: <201609111259.q67d9T4B%fengguang.wu@intel.com>
References: <201609111259.q67d9T4B%fengguang.wu@intel.com>
Message-ID: <1473703083-8625-1-git-send-email-vgupta@synopsys.com>

Hi Peter / Tony.

Sorry for the rebase snafu with v2.

So kbuild service reported build failure of ia64 with v1 of the patch.
I've added an untested atomic64_dec_if_positive() to ia64, shamelessly
copied from s390 with some adjustments 64-bit long etc. Could you please
double check.

It builds fine with ia64 cross compiler.

Thx,
-Vineet

*** BLURB HERE ***

Vineet Gupta (2):
  ia64: implement atomic64_dec_if_positive
  atomic64: No need for CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE

 arch/alpha/Kconfig             |  1 -
 arch/arm/Kconfig               |  1 -
 arch/arm64/Kconfig             |  1 -
 arch/ia64/include/asm/atomic.h | 16 ++++++++++++++++
 arch/mips/Kconfig              |  1 -
 arch/parisc/Kconfig            |  1 -
 arch/powerpc/Kconfig           |  1 -
 arch/s390/Kconfig              |  1 -
 arch/sparc/Kconfig             |  1 -
 arch/tile/Kconfig              |  1 -
 arch/x86/Kconfig               |  1 -
 lib/Kconfig                    |  3 ---
 lib/atomic64_test.c            |  4 ----
 13 files changed, 16 insertions(+), 17 deletions(-)

-- 
2.7.4



From Vineet.Gupta1 at synopsys.com  Mon Sep 12 10:58:02 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Mon, 12 Sep 2016 10:58:02 -0700
Subject: [PATCH v3 1/2] ia64: implement atomic64_dec_if_positive
In-Reply-To: <1473703083-8625-1-git-send-email-vgupta@synopsys.com>
References: <201609111259.q67d9T4B%fengguang.wu@intel.com>
 <1473703083-8625-1-git-send-email-vgupta@synopsys.com>
Message-ID: <1473703083-8625-2-git-send-email-vgupta@synopsys.com>

This is based on s390 version and needed to get rid of
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE

Cc: Tony Luck <tony.luck at intel.com>
Cc: Fenghua Yu <fenghua.yu at intel.com>
Cc: Ingo Molnar <mingo at kernel.org>
Cc: Peter Zijlstra <peterz at infradead.org>
Cc: linux-ia64 at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Reported-by: kbuild test robot <fengguang.wu at intel.com>
Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
---
 arch/ia64/include/asm/atomic.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/ia64/include/asm/atomic.h b/arch/ia64/include/asm/atomic.h
index f565ad376142..65d4bb2b6685 100644
--- a/arch/ia64/include/asm/atomic.h
+++ b/arch/ia64/include/asm/atomic.h
@@ -269,6 +269,22 @@ static __inline__ long atomic64_add_unless(atomic64_t *v, long a, long u)
 
 #define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
 
+static __inline__ long atomic64_dec_if_positive(atomic64_t *v)
+{
+	long c, old, dec;
+	c = atomic64_read(v);
+	for (;;) {
+		dec = c - 1;
+		if (unlikely(dec < 0))
+			break;
+		old = atomic64_cmpxchg((v), c, dec);
+		if (likely(old == c))
+			break;
+		c = old;
+	}
+	return dec;
+}
+
 /*
  * Atomically add I to V and return TRUE if the resulting value is
  * negative.
-- 
2.7.4



From Vineet.Gupta1 at synopsys.com  Mon Sep 12 10:58:03 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Mon, 12 Sep 2016 10:58:03 -0700
Subject: [PATCH v3 2/2] atomic64: No need for
 CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
In-Reply-To: <1473703083-8625-1-git-send-email-vgupta@synopsys.com>
References: <201609111259.q67d9T4B%fengguang.wu@intel.com>
 <1473703083-8625-1-git-send-email-vgupta@synopsys.com>
Message-ID: <1473703083-8625-3-git-send-email-vgupta@synopsys.com>

This came to light when implementing native 64-bit atomics for ARCv2.

The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
to check whether atomic64_dec_if_positive() is available.
It seems it was needed when not every arch defined it.
However as of current code the Kconfig option seems needless

- for CONFIG_GENERIC_ATOMIC64 it is auto-enabled in lib/Kconfig and a
  generic definition of API is present lib/atomic64.c
- arches with native 64-bit atomics select it in arch/*/Kconfig and
  define the API in their headers

So I see no point in keeping the Kconfig option

Compile tested for:
 - blackfin (CONFIG_GENERIC_ATOMIC64)
 - x86 (!CONFIG_GENERIC_ATOMIC64)
 - ia64

Cc: Richard Henderson <rth at twiddle.net>
Cc: Ivan Kokshaysky <ink at jurassic.park.msu.ru>
Cc: Matt Turner <mattst88 at gmail.com>
Cc: Russell King <linux at armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Ralf Baechle <ralf at linux-mips.org>
Cc: "James E.J. Bottomley" <jejb at parisc-linux.org>
Cc: Helge Deller <deller at gmx.de>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Paul Mackerras <paulus at samba.org>
Cc: Michael Ellerman <mpe at ellerman.id.au>
Cc: Martin Schwidefsky <schwidefsky at de.ibm.com>
Cc: Heiko Carstens <heiko.carstens at de.ibm.com>
Cc: "David S. Miller" <davem at davemloft.net>
Cc: Chris Metcalf <cmetcalf at mellanox.com>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Ingo Molnar <mingo at redhat.com>
Cc: "H. Peter Anvin" <hpa at zytor.com>
Cc: x86 at kernel.org
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Vineet Gupta <vgupta at synopsys.com>
Cc: Zhaoxiu Zeng <zhaoxiu.zeng at gmail.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Matthew Wilcox <willy at linux.intel.com>
Cc: Alexander Potapenko <glider at google.com>
Cc: Andrey Ryabinin <aryabinin at virtuozzo.com>
Cc: Herbert Xu <herbert at gondor.apana.org.au>
Cc: Ming Lin <ming.l at ssi.samsung.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Geert Uytterhoeven <geert at linux-m68k.org>
Cc: Peter Zijlstra <peterz at infradead.org>
Cc: Borislav Petkov <bp at suse.de>
Cc: Andi Kleen <ak at linux.intel.com>
Cc: Boqun Feng <boqun.feng at gmail.com>
Cc: linux-alpha at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-mips at linux-mips.org
Cc: linux-parisc at vger.kernel.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-s390 at vger.kernel.org
Cc: sparclinux at vger.kernel.org
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-arch at vger.kernel.org
Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
---
 arch/alpha/Kconfig   | 1 -
 arch/arm/Kconfig     | 1 -
 arch/arm64/Kconfig   | 1 -
 arch/mips/Kconfig    | 1 -
 arch/parisc/Kconfig  | 1 -
 arch/powerpc/Kconfig | 1 -
 arch/s390/Kconfig    | 1 -
 arch/sparc/Kconfig   | 1 -
 arch/tile/Kconfig    | 1 -
 arch/x86/Kconfig     | 1 -
 lib/Kconfig          | 3 ---
 lib/atomic64_test.c  | 4 ----
 12 files changed, 17 deletions(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 7f312d80b43b..0e49d39ea74a 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -15,7 +15,6 @@ config ALPHA
 	select GENERIC_IRQ_SHOW
 	select ARCH_WANT_IPC_PARSE_VERSION
 	select ARCH_HAVE_NMI_SAFE_CMPXCHG
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select AUDIT_ARCH
 	select GENERIC_CLOCKEVENTS
 	select GENERIC_SMP_IDLE_THREAD
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a9c4e48bb7ec..2a50957c7bfb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1,7 +1,6 @@
 config ARM
 	bool
 	default y
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index bc3f00f586f1..3df2ca7efbcc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -6,7 +6,6 @@ config ARM64
 	select ACPI_MCFG if ACPI
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_GCOV_PROFILE_ALL
 	select ARCH_HAS_KCOV
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 26388562e300..5bbea197c220 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -30,7 +30,6 @@ config MIPS
 	select HAVE_ARCH_TRANSPARENT_HUGEPAGE if CPU_SUPPORTS_HUGEPAGES && 64BIT
 	select RTC_LIB if !MACH_LOONGSON64
 	select GENERIC_ATOMIC64 if !64BIT
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select HAVE_DMA_CONTIGUOUS
 	select HAVE_DMA_API_DEBUG
 	select GENERIC_IRQ_PROBE
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index af12c2db9bb8..8a96bdcc3807 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -14,7 +14,6 @@ config PARISC
 	select BUILDTIME_EXTABLE_SORT
 	select HAVE_PERF_EVENTS
 	select GENERIC_ATOMIC64 if !64BIT
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select BROKEN_RODATA
 	select GENERIC_IRQ_PROBE
 	select GENERIC_PCI_IOMAP
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 927d2ab2ce08..18d1b42cf545 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -113,7 +113,6 @@ config PPC
 	select HAVE_DEBUG_KMEMLEAK
 	select ARCH_HAS_SG_CHAIN
 	select GENERIC_ATOMIC64 if PPC32
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select HAVE_PERF_EVENTS
 	select HAVE_PERF_REGS
 	select HAVE_PERF_USER_STACK_DUMP
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index c109f073d454..d89d97ac83c4 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -67,7 +67,6 @@ config DEBUG_RODATA
 
 config S390
 	def_bool y
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_GCOV_PROFILE_ALL
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 59b09600dd32..bfedbe0cb7b2 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -22,7 +22,6 @@ config SPARC
 	select HAVE_ARCH_TRACEHOOK
 	select HAVE_EXIT_THREAD
 	select SYSCTL_EXCEPTION_TRACE
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select RTC_CLASS
 	select RTC_DRV_M48T59
 	select RTC_SYSTOHC
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 78da75b670bc..4583c0320059 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -3,7 +3,6 @@
 
 config TILE
 	def_bool y
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAVE_NMI_SAFE_CMPXCHG
 	select ARCH_WANT_FRAME_POINTERS
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2a1f0ce7c59a..018076fcffcf 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -23,7 +23,6 @@ config X86
 	select ARCH_CLOCKSOURCE_DATA
 	select ARCH_DISCARD_MEMBLOCK
 	select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
-	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_FAST_MULTIPLIER
diff --git a/lib/Kconfig b/lib/Kconfig
index d79909dc01ec..0e74df3c5441 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -457,9 +457,6 @@ config NLATTR
 config GENERIC_ATOMIC64
        bool
 
-config ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
-	def_bool y if GENERIC_ATOMIC64
-
 config LRU_CACHE
 	tristate
 
diff --git a/lib/atomic64_test.c b/lib/atomic64_test.c
index dbb369145dda..46042901130f 100644
--- a/lib/atomic64_test.c
+++ b/lib/atomic64_test.c
@@ -213,7 +213,6 @@ static __init void test_atomic64(void)
 	r += one;
 	BUG_ON(v.counter != r);
 
-#ifdef CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	INIT(onestwos);
 	BUG_ON(atomic64_dec_if_positive(&v) != (onestwos - 1));
 	r -= one;
@@ -226,9 +225,6 @@ static __init void test_atomic64(void)
 	INIT(-one);
 	BUG_ON(atomic64_dec_if_positive(&v) != (-one - one));
 	BUG_ON(v.counter != r);
-#else
-#warning Please implement atomic64_dec_if_positive for your architecture and select the above Kconfig symbol
-#endif
 
 	INIT(onestwos);
 	BUG_ON(!atomic64_inc_not_zero(&v));
-- 
2.7.4



From tony.luck at intel.com  Mon Sep 12 11:26:07 2016
From: tony.luck at intel.com (Luck, Tony)
Date: Mon, 12 Sep 2016 18:26:07 +0000
Subject: [PATCH v2 1/2] ia64: implement atomic64_dec_if_positive
In-Reply-To: <1473702432-8116-2-git-send-email-vgupta@synopsys.com>
References: <1473702432-8116-1-git-send-email-vgupta@synopsys.com>
 <1473702432-8116-2-git-send-email-vgupta@synopsys.com>
Message-ID: <3908561D78D1C84285E8C5FCA982C28F3A1C7978@ORSMSX114.amr.corp.intel.com>

+static __inline__ long atomic64_dec_if_positive(atomic64_t *v)
+{
+	long c, old, dec;
+	c = atomic64_read(v);
+	for (;;) {
+		dec = c - 1;
+		if (unlikely(dec < 0))
+			break;
+		old = atomic64_cmpxchg((v), c, dec);
+		if (likely(old == c))
+			break;
+		c = old;
+	}
+	return dec;
+}

I was about to say "add a cpu_relax()" in the bottom of that loop. But none of the other
atomic ops that spin on a cmpxchg do that ... so:

Acked-by: Tony Luck <tony.luck at intel.com>

-Tony


From Vineet.Gupta1 at synopsys.com  Tue Sep 13 15:37:17 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Tue, 13 Sep 2016 15:37:17 -0700
Subject: [PATCH] ARC: module: provide linker script to discard debug sections
Message-ID: <1473806237-16800-1-git-send-email-vgupta@synopsys.com>

The module .ko files seem to  bloated due to lot of needless sections,
most of which come due to -gdwarf-2 toggle (needed in turn to get
.debug_frame which kernel stack unwinder usese).

However there's no reason for the other .debug_* sections, so discard
them using arch specific linker script (linker collates module-common.lds
and arch specific lds)

For a very simply module using DEBUG_FS

before
| There are 35 section headers, starting at offset 0x205a0:
| ls -sh q_proc.ko
| 132K q_proc.ko

after
| There are 25 section headers, starting at offset 0x205a0:
| ls -sh q_proc.ko
| 8K q_proc.ko

Reported-by: Daniel Mentz <danielmentz at google.com>
Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
---
 arch/arc/Makefile          |  5 +++++
 arch/arc/kernel/module.lds | 12 ++++++++++++
 2 files changed, 17 insertions(+)
 create mode 100644 arch/arc/kernel/module.lds

diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index 85814e74677d..fe1b702f5c69 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -97,6 +97,11 @@ LIBGCC	:= $(shell $(CC) $(cflags-y) --print-libgcc-file-name)
 # Modules with short calls might break for calls into builtin-kernel
 KBUILD_CFLAGS_MODULE	+= -mlong-calls -mno-millicode
 
+# toss away debug section, ifdef not allowed in the linker script
+ifndef CONFIG_DEBUG_INFO
+KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/arc/kernel/module.lds
+endif
+
 # Finally dump eveything into kernel build system
 KBUILD_CFLAGS	+= $(cflags-y)
 KBUILD_AFLAGS	+= $(KBUILD_CFLAGS)
diff --git a/arch/arc/kernel/module.lds b/arch/arc/kernel/module.lds
new file mode 100644
index 000000000000..c9839be105fc
--- /dev/null
+++ b/arch/arc/kernel/module.lds
@@ -0,0 +1,12 @@
+SECTIONS
+{
+	/DISCARD/ : { *(.debug_aranges) }
+	/DISCARD/ : { *(.debug_pubnames) }
+	/DISCARD/ : { *(.debug_info) }
+	/DISCARD/ : { *(.debug_abbrev) }
+	/DISCARD/ : { *(.debug_line) }
+	/DISCARD/ : { *(.debug_str) }
+	/DISCARD/ : { *(.debug_loc) }
+	/DISCARD/ : { *(.debug_macinfo) }
+	/DISCARD/ : { *(.debug_ranges) }
+}
-- 
2.7.4



From Alexey.Brodkin at synopsys.com  Wed Sep 14 09:21:12 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Wed, 14 Sep 2016 16:21:12 +0000
Subject: [PATCH] perf tools: Fix static building
In-Reply-To: <8deeb70b-6fe8-32c5-9f6f-65b2d6bd70eb@synopsys.com>
References: <1471887222-26270-1-git-send-email-abrodkin@synopsys.com>
 <20160831072128.GB4740@krava>
 <8deeb70b-6fe8-32c5-9f6f-65b2d6bd70eb@synopsys.com>
Message-ID: <1473869942.3766.32.camel@synopsys.com>

Hi Vineet, Jiri,

On Thu, 2016-09-01 at 11:28 -0700, Vineet Gupta wrote:
> On 08/31/2016 12:21 AM, Jiri Olsa wrote:
> > 
> > On Mon, Aug 22, 2016 at 08:33:42PM +0300, Alexey Brodkin wrote:
> > > 
> > > With commit e3d09ec8126f ("tools lib traceevent: Export dynamic symbols
> > > used by traceevent plugins") we started to add "--dynamic-list" in
> > > LDFLAGS. One side-effect of that was inability to build really
> > > statically-linked perf.
> > 
> > IIRC --dynamic-list forces perf to exports some symbols to
> > be used by plugins.. don't see this breaking static build
> > 
> > also it's working properly for me:
> > 
> > [jolsa at krava perf]$ make LDFLAGS=-static
> > ...
> > [jolsa at krava perf]$ ldd ./perf
> > ????????not a dynamic executable
> > 
> > unless I miss what you mean by 'really statically-linked' ;-)
> 
> Right - so I tried this as well and indeed I can confirm that it builds for me as
> static. Atleast the build system doesn;t need changing as -sattic being propagated
> to fianl link cmd.
> 
> There seems to be some weirdness with ARC tools: file reports
> 
> > 
> > ELF 32-bit LSB executable, *unknown arch 0xc3* version 1 (SYSV),
> > dynamically linked, interpreter *empty*, for GNU/Linux 3.9.0, not stripped
> 
> 
> That is clearly wrong !
> 
> And the static binary as expected doesn't seem to run on target - exits with -EACCESS.

I may confirm what Vineet said already adding just that funny ldd output on target:
-------------------->8-----------------
# ldd /home/perf?
	 =>??(0x00000000)
-------------------->8-----------------

Just for comparison that's ldd output for dynamically built perf:
-------------------->8-----------------
# ldd /usr/bin/perf?
checking sub-depends for '/lib/libpthread.so.0'
checking sub-depends for '/lib/librt.so.0'
checking sub-depends for '/lib/libm.so.0'
checking sub-depends for '/lib/libdl.so.0'
checking sub-depends for '/lib/libc.so.0'
	libpthread.so.0 => /lib/libpthread.so.0 (0x00000000)
	librt.so.0 => /lib/librt.so.0 (0x00000000)
	libm.so.0 => /lib/libm.so.0 (0x00000000)
	libdl.so.0 => /lib/libdl.so.0 (0x00000000)
	libc.so.0 => /lib/libc.so.0 (0x00000000)
	/lib/ld-uClibc.so.1 => /lib/ld-uClibc.so.1 (0x00000000)
-------------------->8-----------------

And most probably the reason for me to think perf built with LDFLAGS=-static
was not static is indeed "file" output:
-------------------->8-----------------
file tools/perf/perf
tools/perf/perf: ELF 32-bit LSB executable, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
3.9.0, not stripped
-------------------->8-----------------

Sorry for the noise.

-Alexey

From Eugeniy.Paltsev at synopsys.com  Wed Sep 14 10:40:38 2016
From: Eugeniy.Paltsev at synopsys.com (Eugeniy Paltsev)
Date: Wed, 14 Sep 2016 20:40:38 +0300
Subject: [PATCH] dmaengine: dmatest: Restore "memcpy" as default mode
Message-ID: <1473874838-13744-1-git-send-email-Eugeniy.Paltsev@synopsys.com>

Commit 0d4cb44da6ca0e8 ("dmaengine: dmatest: Add support for
scatter-gather DMA mode") changes default "dmatest" behavior by
changing default mode from "memcpy" to "scatter-gather".
Now "memcpy" gets back as default mode.

Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev at synopsys.com>
---
 drivers/dma/dmatest.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
index 53e9728..cf76fc6 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -56,10 +56,10 @@ module_param(sg_buffers, uint, S_IRUGO | S_IWUSR);
 MODULE_PARM_DESC(sg_buffers,
 		"Number of scatter gather buffers (default: 1)");
 
-static unsigned int dmatest = 1;
+static unsigned int dmatest;
 module_param(dmatest, uint, S_IRUGO | S_IWUSR);
 MODULE_PARM_DESC(dmatest,
-		"dmatest 0-memcpy 1-slave_sg (default: 1)");
+		"dmatest 0-memcpy 1-slave_sg (default: 0)");
 
 static unsigned int xor_sources = 3;
 module_param(xor_sources, uint, S_IRUGO | S_IWUSR);
-- 
2.5.5



From vgupta at synopsys.com  Wed Sep 14 10:53:48 2016
From: vgupta at synopsys.com (Vineet Gupta)
Date: Wed, 14 Sep 2016 10:53:48 -0700
Subject: [PATCH] arc: perf: Enable generic "cache-references" and
 "cache-misses" events
In-Reply-To: <6074e252-6e18-bb01-4de1-023bd7e82f03@synopsys.com>
References: <1472125647-518-1-git-send-email-abrodkin@synopsys.com>
 <6074e252-6e18-bb01-4de1-023bd7e82f03@synopsys.com>
Message-ID: <e9ee8ab7-815b-f213-d61b-30dcf1cbf61f@synopsys.com>

On 08/26/2016 10:30 AM, Vineet Gupta wrote:
> On 08/25/2016 04:49 AM, Alexey Brodkin wrote:
>> ...
>>  	[PERF_COUNT_ARC_EDTLB] = "edtlb",	/* D-TLB Miss */
>>  	[PERF_COUNT_ARC_EITLB] = "eitlb",	/* I-TLB Miss */
>> +
>> +	[PERF_COUNT_HW_CACHE_REFERENCES] = "imemrdc",	/* Instr: mem read cached */
>> +	[PERF_COUNT_HW_CACHE_MISSES] = "dclm",		/* D-cache Load Miss */
> 
> I think this is duplicating a mistake we already have. I vaguely remember when
> doing some hackbench profiling last year with range based profiling confined to
> memset routine and saw that L1-dcache-misses was counting zero. This is because it
> only counts LD misses while memset only does ST.

So given that this is the best we got, I'm going to merge this anyways.

-Vineet

> 
> Performance counter stats for '/sbin/hackbench':
> 
>      0 L1-dcache-misses
>      0 L1-dcache-load-misses
>      1846082 L1-dcache-store-misses
> 
> 
> @PeterZ do you concur that is wrong and we ought to setup 2 counters to do this
> correctly ?
> 
> -Vineet
> 



From appana.durga.rao at xilinx.com  Wed Sep 14 20:24:38 2016
From: appana.durga.rao at xilinx.com (Appana Durga Kedareswara Rao)
Date: Thu, 15 Sep 2016 03:24:38 +0000
Subject: [PATCH] dmaengine: dmatest: Restore "memcpy" as default mode
In-Reply-To: <1473874838-13744-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
References: <1473874838-13744-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
Message-ID: <C246CAC1457055469EF09E3A7AC4E11A4A5EC400@XAP-PVEXMBX01.xlnx.xilinx.com>



> -----Original Message-----
> From: Eugeniy Paltsev [mailto:Eugeniy.Paltsev at synopsys.com]
> Sent: Wednesday, September 14, 2016 11:11 PM
> To: dmaengine at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org; Appana Durga Kedareswara Rao
> <appanad at xilinx.com>; vinod.koul at intel.com; dan.j.williams at intel.com;
> andriy.shevchenko at linux.intel.com; linux-snps-arc at lists.infradead.org; Eugeniy
> Paltsev <Eugeniy.Paltsev at synopsys.com>
> Subject: [PATCH] dmaengine: dmatest: Restore "memcpy" as default mode
> 
> Commit 0d4cb44da6ca0e8 ("dmaengine: dmatest: Add support for scatter-
> gather DMA mode") changes default "dmatest" behavior by changing default
> mode from "memcpy" to "scatter-gather".
> Now "memcpy" gets back as default mode.
> 
> Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev at synopsys.com>

Reviewed-by: Kedareswara rao Appana <appanad at xilinx.com>


Thanks,
Kedar.

> ---
>  drivers/dma/dmatest.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c index
> 53e9728..cf76fc6 100644
> --- a/drivers/dma/dmatest.c
> +++ b/drivers/dma/dmatest.c
> @@ -56,10 +56,10 @@ module_param(sg_buffers, uint, S_IRUGO | S_IWUSR);
> MODULE_PARM_DESC(sg_buffers,
>  		"Number of scatter gather buffers (default: 1)");
> 
> -static unsigned int dmatest = 1;
> +static unsigned int dmatest;
>  module_param(dmatest, uint, S_IRUGO | S_IWUSR);
> MODULE_PARM_DESC(dmatest,
> -		"dmatest 0-memcpy 1-slave_sg (default: 1)");
> +		"dmatest 0-memcpy 1-slave_sg (default: 0)");
> 
>  static unsigned int xor_sources = 3;
>  module_param(xor_sources, uint, S_IRUGO | S_IWUSR);
> --
> 2.5.5



From Eugeniy.Paltsev at synopsys.com  Thu Sep 15 06:14:13 2016
From: Eugeniy.Paltsev at synopsys.com (Eugeniy Paltsev)
Date: Thu, 15 Sep 2016 16:14:13 +0300
Subject: [PATCH] dmaengine: DW DMAC: split pdata to hardware properties and
 platform quirks
Message-ID: <1473945253-16649-1-git-send-email-Eugeniy.Paltsev@synopsys.com>

This patch is to address a proposal by Andy in this thread:
http://www.spinics.net/lists/dmaengine/msg10754.html
Split platform data to actual hardware properties, and platform quirks.
Now we able to use quirks and hardware properties separately from
different sources (pdata, device tree or autoconfig registers)

Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev at synopsys.com>
---
 drivers/dma/dw/core.c                | 31 +++++++++++++++-----------
 drivers/dma/dw/platform.c            | 42 +++++++++++++++++++++---------------
 include/linux/platform_data/dma-dw.h | 20 +++++++++++------
 3 files changed, 57 insertions(+), 36 deletions(-)

diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index c2c0a61..9352735 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1451,10 +1451,25 @@ int dw_dma_probe(struct dw_dma_chip *chip)
 
 	dw->regs = chip->regs;
 	chip->dw = dw;
+	/* Reassign the platform data pointer */
+	pdata = dw->pdata;
 
 	pm_runtime_get_sync(chip->dev);
 
-	if (!chip->pdata) {
+	if ((!chip->pdata) ||
+	   (chip->pdata && test_bit(QUIRKS_ONLY_USED, &chip->pdata->quirks))) {
+
+		/*
+		 * Fill quirks with the default values in case of pdata absence
+		 */
+		if (!chip->pdata) {
+			set_bit(QUIRKS_IS_PRIVATE, &pdata->quirks);
+			set_bit(QUIRKS_IS_MEMCPY, &pdata->quirks);
+			set_bit(QUIRKS_IS_NOLLP, &pdata->quirks);
+		} else {
+			pdata->quirks = chip->pdata->quirks;
+		}
+
 		dw_params = dma_readl(dw, DW_PARAMS);
 		dev_dbg(chip->dev, "DW_PARAMS: 0x%08x\n", dw_params);
 
@@ -1464,9 +1479,6 @@ int dw_dma_probe(struct dw_dma_chip *chip)
 			goto err_pdata;
 		}
 
-		/* Reassign the platform data pointer */
-		pdata = dw->pdata;
-
 		/* Get hardware configuration parameters */
 		pdata->nr_channels = (dw_params >> DW_PARAMS_NR_CHAN & 7) + 1;
 		pdata->nr_masters = (dw_params >> DW_PARAMS_NR_MASTER & 3) + 1;
@@ -1477,8 +1489,6 @@ int dw_dma_probe(struct dw_dma_chip *chip)
 		pdata->block_size = dma_readl(dw, MAX_BLK_SIZE);
 
 		/* Fill platform data with the default values */
-		pdata->is_private = true;
-		pdata->is_memcpy = true;
 		pdata->chan_allocation_order = CHAN_ALLOCATION_ASCENDING;
 		pdata->chan_priority = CHAN_PRIORITY_ASCENDING;
 	} else if (chip->pdata->nr_channels > DW_DMA_MAX_NR_CHANNELS) {
@@ -1486,9 +1496,6 @@ int dw_dma_probe(struct dw_dma_chip *chip)
 		goto err_pdata;
 	} else {
 		memcpy(dw->pdata, chip->pdata, sizeof(*dw->pdata));
-
-		/* Reassign the platform data pointer */
-		pdata = dw->pdata;
 	}
 
 	dw->chan = devm_kcalloc(chip->dev, pdata->nr_channels, sizeof(*dw->chan),
@@ -1569,7 +1576,7 @@ int dw_dma_probe(struct dw_dma_chip *chip)
 				(dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0;
 		} else {
 			dwc->block_size = pdata->block_size;
-			dwc->nollp = pdata->is_nollp;
+			dwc->nollp = test_bit(QUIRKS_IS_NOLLP, &pdata->quirks);
 		}
 	}
 
@@ -1582,9 +1589,9 @@ int dw_dma_probe(struct dw_dma_chip *chip)
 
 	/* Set capabilities */
 	dma_cap_set(DMA_SLAVE, dw->dma.cap_mask);
-	if (pdata->is_private)
+	if (test_bit(QUIRKS_IS_PRIVATE, &pdata->quirks))
 		dma_cap_set(DMA_PRIVATE, dw->dma.cap_mask);
-	if (pdata->is_memcpy)
+	if (test_bit(QUIRKS_IS_MEMCPY, &pdata->quirks))
 		dma_cap_set(DMA_MEMCPY, dw->dma.cap_mask);
 
 	dw->dma.dev = chip->dev;
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index 5bda0eb..308b977 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -12,6 +12,7 @@
  * published by the Free Software Foundation.
  */
 
+#include <linux/bitops.h>
 #include <linux/module.h>
 #include <linux/device.h>
 #include <linux/clk.h>
@@ -111,41 +112,48 @@ dw_dma_parse_dt(struct platform_device *pdev)
 		return NULL;
 	}
 
-	if (of_property_read_u32(np, "dma-masters", &nr_masters))
-		return NULL;
-	if (nr_masters < 1 || nr_masters > DW_DMA_MAX_NR_MASTERS)
-		return NULL;
-
-	if (of_property_read_u32(np, "dma-channels", &nr_channels))
-		return NULL;
-
 	pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
 	if (!pdata)
 		return NULL;
 
+	set_bit(QUIRKS_ONLY_USED, &pdata->quirks);
+
+	if (of_property_read_bool(np, "is-private"))
+		set_bit(QUIRKS_IS_PRIVATE, &pdata->quirks);
+
+	if (of_property_read_bool(np, "is-memcpy"))
+		set_bit(QUIRKS_IS_MEMCPY, &pdata->quirks);
+
+	if (of_property_read_bool(np, "is-nollp"))
+		set_bit(QUIRKS_IS_NOLLP, &pdata->quirks);
+
+	if (of_property_read_u32(np, "dma-masters", &nr_masters))
+		return pdata;
+	if (nr_masters < 1 || nr_masters > DW_DMA_MAX_NR_MASTERS)
+		return pdata;
+
 	pdata->nr_masters = nr_masters;
-	pdata->nr_channels = nr_channels;
 
-	if (of_property_read_bool(np, "is_private"))
-		pdata->is_private = true;
+	if (of_property_read_u32(np, "dma-channels", &nr_channels))
+		return pdata;
 
-	if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
+	pdata->nr_channels = nr_channels;
+
+	if (!of_property_read_u32(np, "chan-allocation-order", &tmp))
 		pdata->chan_allocation_order = (unsigned char)tmp;
 
-	if (!of_property_read_u32(np, "chan_priority", &tmp))
+	if (!of_property_read_u32(np, "chan-priority", &tmp))
 		pdata->chan_priority = tmp;
 
-	if (!of_property_read_u32(np, "block_size", &tmp))
+	if (!of_property_read_u32(np, "block-size", &tmp))
 		pdata->block_size = tmp;
 
 	if (!of_property_read_u32_array(np, "data-width", arr, nr_masters)) {
 		for (tmp = 0; tmp < nr_masters; tmp++)
 			pdata->data_width[tmp] = arr[tmp];
-	} else if (!of_property_read_u32_array(np, "data_width", arr, nr_masters)) {
-		for (tmp = 0; tmp < nr_masters; tmp++)
-			pdata->data_width[tmp] = BIT(arr[tmp] & 0x07);
 	}
 
+	clear_bit(QUIRKS_ONLY_USED, &pdata->quirks);
 	return pdata;
 }
 #else
diff --git a/include/linux/platform_data/dma-dw.h b/include/linux/platform_data/dma-dw.h
index 5f0e11e..9cd8199 100644
--- a/include/linux/platform_data/dma-dw.h
+++ b/include/linux/platform_data/dma-dw.h
@@ -37,10 +37,7 @@ struct dw_dma_slave {
 /**
  * struct dw_dma_platform_data - Controller configuration parameters
  * @nr_channels: Number of channels supported by hardware (max 8)
- * @is_private: The device channels should be marked as private and not for
- *	by the general purpose DMA channel allocator.
- * @is_memcpy: The device channels do support memory-to-memory transfers.
- * @is_nollp: The device channels does not support multi block transfers.
+ * @quirks: Bit field with platform quirks
  * @chan_allocation_order: Allocate channels starting from 0 or 7
  * @chan_priority: Set channel priority increasing from 0 to 7 or 7 to 0.
  * @block_size: Maximum block size supported by the controller
@@ -50,9 +47,18 @@ struct dw_dma_slave {
  */
 struct dw_dma_platform_data {
 	unsigned int	nr_channels;
-	bool		is_private;
-	bool		is_memcpy;
-	bool		is_nollp;
+/* Only use quirks from platform data structure */
+#define QUIRKS_ONLY_USED	0
+/*
+ * The device channels should be marked as private and not for
+ * by the general purpose DMA channel allocator.
+ */
+#define QUIRKS_IS_PRIVATE	1
+/* The device channels do support memory-to-memory transfers. */
+#define QUIRKS_IS_MEMCPY	2
+/* The device channels do not support multi block transfers. */
+#define QUIRKS_IS_NOLLP		3
+	unsigned long	quirks;
 #define CHAN_ALLOCATION_ASCENDING	0	/* zero to seven */
 #define CHAN_ALLOCATION_DESCENDING	1	/* seven to zero */
 	unsigned char	chan_allocation_order;
-- 
2.5.5



From lkp at intel.com  Thu Sep 15 08:04:48 2016
From: lkp at intel.com (kbuild test robot)
Date: Thu, 15 Sep 2016 23:04:48 +0800
Subject: [PATCH] dmaengine: DW DMAC: split pdata to hardware properties
 and platform quirks
In-Reply-To: <1473945253-16649-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
Message-ID: <201609152333.AbSSpwAg%fengguang.wu@intel.com>

Hi Eugeniy,

[auto build test ERROR on slave-dma/next]
[also build test ERROR on next-20160915]
[cannot apply to linus/master linux/master v4.8-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:    https://github.com/0day-ci/linux/commits/Eugeniy-Paltsev/dmaengine-DW-DMAC-split-pdata-to-hardware-properties-and-platform-quirks/20160915-211634
base:   https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git next
config: i386-defconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
        # save the attached .config to linux build tree
        make ARCH=i386 

All errors (new ones prefixed by >>):

>> drivers/tty/serial/8250/8250_lpss.c:159:2: error: unknown field 'is_private' specified in initializer
     .is_private = true,
     ^
>> drivers/tty/serial/8250/8250_lpss.c:160:2: error: unknown field 'is_nollp' specified in initializer
     .is_nollp = true,
     ^

vim +/is_private +159 drivers/tty/serial/8250/8250_lpss.c

a13e19cf Andy Shevchenko 2016-08-17  153  	return 0;
a13e19cf Andy Shevchenko 2016-08-17  154  }
a13e19cf Andy Shevchenko 2016-08-17  155  
fecdef93 Andy Shevchenko 2016-08-17  156  #ifdef CONFIG_SERIAL_8250_DMA
fecdef93 Andy Shevchenko 2016-08-17  157  static const struct dw_dma_platform_data qrk_serial_dma_pdata = {
fecdef93 Andy Shevchenko 2016-08-17  158  	.nr_channels = 2,
fecdef93 Andy Shevchenko 2016-08-17 @159  	.is_private = true,
fecdef93 Andy Shevchenko 2016-08-17 @160  	.is_nollp = true,
fecdef93 Andy Shevchenko 2016-08-17  161  	.chan_allocation_order = CHAN_ALLOCATION_ASCENDING,
fecdef93 Andy Shevchenko 2016-08-17  162  	.chan_priority = CHAN_PRIORITY_ASCENDING,
fecdef93 Andy Shevchenko 2016-08-17  163  	.block_size = 4095,

:::::: The code at line 159 was first introduced by commit
:::::: fecdef932b0093b4a7e1ae88b1dbd63eb74ecc34 serial: 8250_lpss: enable DMA on Intel Quark UART

:::::: TO: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
:::::: CC: Greg Kroah-Hartman <gregkh at linuxfoundation.org>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 25021 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-snps-arc/attachments/20160915/76c45537/attachment-0001.obj>

From vinod.koul at intel.com  Thu Sep 15 08:48:18 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Thu, 15 Sep 2016 21:18:18 +0530
Subject: [PATCH] dmaengine: dmatest: Restore "memcpy" as default mode
In-Reply-To: <1473874838-13744-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
References: <1473874838-13744-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
Message-ID: <20160915154818.GW13920@localhost>

On Wed, Sep 14, 2016 at 08:40:38PM +0300, Eugeniy Paltsev wrote:
> Commit 0d4cb44da6ca0e8 ("dmaengine: dmatest: Add support for
> scatter-gather DMA mode") changes default "dmatest" behavior by
> changing default mode from "memcpy" to "scatter-gather".
> Now "memcpy" gets back as default mode.

Applied, thanks


-- 
~Vinod


From Alexey.Brodkin at synopsys.com  Fri Sep 16 08:01:59 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Fri, 16 Sep 2016 15:01:59 +0000
Subject: [PATCH RFC v1 00/29] ARC cores
In-Reply-To: <1473373930-31547-1-git-send-email-mrolnik@gmail.com>
References: <1473373930-31547-1-git-send-email-mrolnik@gmail.com>
Message-ID: <1474038116.3042.10.camel@synopsys.com>

Hi Michael,

On Fri, 2016-09-09 at 01:31 +0300, Michael Rolnik wrote:
> This series of patches adds ARC target to QEMU. It indends to support
> ????- ARCtangent-A5 processor
> ????- ARC 600 processor
> ????- ARC 700 processor
> 
> All instructions except ASLS are implemented. Not fully tested yet.
> However I was able to execute correctly recursive fibonacci calculation.
> Reset vector is assumed to be some hardcoded value which worked for my test.
> I am planning to get FreeRTOS for ARC, once I get it, I will able to verify
> and complete interrupt support.

That's both very unexpected and cool!

I tried your patches on top of current QEMU git master and it:
?a) Builds for ARC
?b) Very simple code really works!

I was able to single-step with GDB through program as simple as:
--------------------->8---------------------
.global _start
_start:
	mov	r0, 1
	mov	r1, 2
	mov	r1, r0
--------------------->8---------------------

That's what I saw in GDB:
--------------------->8---------------------
(gdb) disassemble?
Dump of assembler code for function _start:
=> 0x00000100 <+0>:	mov	r0,0x1
???0x00000104 <+4>:	mov	r1,0x2
???0x00000108 <+8>:	mov	r1,r0
End of assembler dump.
(gdb) p $r0
$1 = 0
(gdb) stepi
0x00000104 in _start ()
(gdb) p $r0
$2 = 1
(gdb) stepi
0x00000108 in _start ()
(gdb) p $r1
$3 = 2
(gdb) stepi
0x0000010c in ?? ()
(gdb) p $r1
$4 = 1
--------------------->8---------------------

So again this is very promising even though a lot is essentially missing from
this very first implementation.

Anyways IMHO it would be good to have these patches accepted so people may start
playing with that stuff adding missing things one by one.

Let me know if you need any help from my side.

Regards,
Alexey

From noamca at mellanox.com  Sun Sep 18 22:34:40 2016
From: noamca at mellanox.com (Noam Camus)
Date: Mon, 19 Sep 2016 08:34:40 +0300
Subject: [PATCH] ARC: [plat-eznps] add missing atomic_fetch_xxx operations
Message-ID: <1474263280-26203-1-git-send-email-noamca@mellanox.com>

From: Noam Camus <noamca at mellanox.com>

Build brekeage since last changes to generic atomic operations.
Added couple of missing macros which are now mandatory

Signed-off-by: Noam Camus <noamca at mellanox.com>
---
 arch/arc/include/asm/atomic.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arc/include/asm/atomic.h b/arch/arc/include/asm/atomic.h
index 4e3c1b6..4f732bf 100644
--- a/arch/arc/include/asm/atomic.h
+++ b/arch/arc/include/asm/atomic.h
@@ -284,6 +284,7 @@ static inline int atomic_fetch_##op(int i, atomic_t *v)			\
 ATOMIC_OPS(add, +=, CTOP_INST_AADD_DI_R2_R2_R3)
 #define atomic_sub(i, v) atomic_add(-(i), (v))
 #define atomic_sub_return(i, v) atomic_add_return(-(i), (v))
+#define atomic_fetch_sub(i, v) atomic_fetch_add(-(i), (v))
 
 #undef ATOMIC_OPS
 #define ATOMIC_OPS(op, c_op, asm_op)					\
@@ -292,6 +293,7 @@ ATOMIC_OPS(add, +=, CTOP_INST_AADD_DI_R2_R2_R3)
 
 ATOMIC_OPS(and, &=, CTOP_INST_AAND_DI_R2_R2_R3)
 #define atomic_andnot(mask, v) atomic_and(~(mask), (v))
+#define atomic_fetch_andnot(mask, v) atomic_fetch_and(~(mask), (v))
 ATOMIC_OPS(or, |=, CTOP_INST_AOR_DI_R2_R2_R3)
 ATOMIC_OPS(xor, ^=, CTOP_INST_AXOR_DI_R2_R2_R3)
 
-- 
1.7.1



From Vineet.Gupta1 at synopsys.com  Mon Sep 19 10:08:28 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Mon, 19 Sep 2016 10:08:28 -0700
Subject: [PATCH] ARC: [plat-eznps] add missing atomic_fetch_xxx operations
In-Reply-To: <1474263280-26203-1-git-send-email-noamca@mellanox.com>
References: <1474263280-26203-1-git-send-email-noamca@mellanox.com>
Message-ID: <78b621bf-2bc4-f4c8-1d13-8fd6fa483ac8@synopsys.com>

On 09/18/2016 10:34 PM, Noam Camus wrote:
> From: Noam Camus <noamca at mellanox.com>
>
> Build brekeage since last changes to generic atomic operations.
> Added couple of missing macros which are now mandatory
>
> Signed-off-by: Noam Camus <noamca at mellanox.com>

Added to for-next !

Thx,
-Vineet



> ---
>  arch/arc/include/asm/atomic.h |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arc/include/asm/atomic.h b/arch/arc/include/asm/atomic.h
> index 4e3c1b6..4f732bf 100644
> --- a/arch/arc/include/asm/atomic.h
> +++ b/arch/arc/include/asm/atomic.h
> @@ -284,6 +284,7 @@ static inline int atomic_fetch_##op(int i, atomic_t *v)			\
>  ATOMIC_OPS(add, +=, CTOP_INST_AADD_DI_R2_R2_R3)
>  #define atomic_sub(i, v) atomic_add(-(i), (v))
>  #define atomic_sub_return(i, v) atomic_add_return(-(i), (v))
> +#define atomic_fetch_sub(i, v) atomic_fetch_add(-(i), (v))
>  
>  #undef ATOMIC_OPS
>  #define ATOMIC_OPS(op, c_op, asm_op)					\
> @@ -292,6 +293,7 @@ ATOMIC_OPS(add, +=, CTOP_INST_AADD_DI_R2_R2_R3)
>  
>  ATOMIC_OPS(and, &=, CTOP_INST_AAND_DI_R2_R2_R3)
>  #define atomic_andnot(mask, v) atomic_and(~(mask), (v))
> +#define atomic_fetch_andnot(mask, v) atomic_fetch_and(~(mask), (v))
>  ATOMIC_OPS(or, |=, CTOP_INST_AOR_DI_R2_R2_R3)
>  ATOMIC_OPS(xor, ^=, CTOP_INST_AXOR_DI_R2_R2_R3)
>  



From Vineet.Gupta1 at synopsys.com  Mon Sep 19 14:49:30 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Mon, 19 Sep 2016 14:49:30 -0700
Subject: [PATCH 0/3] ARC unwinder switch to .eh_frame
Message-ID: <1474321773-18166-1-git-send-email-vgupta@synopsys.com>

Hi Daniel,

Give these a shot and let me know if they work fine for you.
I'm working on some more improvements to unwinder which will follow
a bit later.

Thx,
-Vineet

Vineet Gupta (3):
  ARC: module: support R_ARC_32_PCREL relocation
  ARC: dw2 unwind: factor CIE specifics for .eh_frame/.debug_frame
  ARC: dw2 unwind: switch to .eh_frame based unwinding

 arch/arc/Makefile             |  2 ++
 arch/arc/include/asm/elf.h    |  3 +--
 arch/arc/kernel/entry.S       | 12 ------------
 arch/arc/kernel/module.c      | 19 ++++++++-----------
 arch/arc/kernel/unwind.c      | 24 +++++++++++++++++-------
 arch/arc/kernel/vmlinux.lds.S | 15 +++++----------
 6 files changed, 33 insertions(+), 42 deletions(-)

-- 
2.7.4



From Vineet.Gupta1 at synopsys.com  Mon Sep 19 14:49:31 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Mon, 19 Sep 2016 14:49:31 -0700
Subject: [PATCH 1/3] ARC: module: support R_ARC_32_PCREL relocation
In-Reply-To: <1474321773-18166-1-git-send-email-vgupta@synopsys.com>
References: <1474321773-18166-1-git-send-email-vgupta@synopsys.com>
Message-ID: <1474321773-18166-2-git-send-email-vgupta@synopsys.com>

Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
---
 arch/arc/include/asm/elf.h | 3 +--
 arch/arc/kernel/module.c   | 6 ++++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arc/include/asm/elf.h b/arch/arc/include/asm/elf.h
index 51a99e25fe33..7096f97a1434 100644
--- a/arch/arc/include/asm/elf.h
+++ b/arch/arc/include/asm/elf.h
@@ -23,8 +23,7 @@
 /* ARC Relocations (kernel Modules only) */
 #define  R_ARC_32		0x4
 #define  R_ARC_32_ME		0x1B
-#define  R_ARC_S25H_PCREL	0x10
-#define  R_ARC_S25W_PCREL	0x11
+#define  R_ARC_32_PCREL		0x31
 
 /*to set parameters in the core dumps */
 #define ELF_ARCH		EM_ARCOMPACT
diff --git a/arch/arc/kernel/module.c b/arch/arc/kernel/module.c
index 376e04622962..576a238434a1 100644
--- a/arch/arc/kernel/module.c
+++ b/arch/arc/kernel/module.c
@@ -106,10 +106,12 @@ int apply_relocate_add(Elf32_Shdr *sechdrs,
 		 */
 		relo_type = ELF32_R_TYPE(rel_entry[i].r_info);
 
-		if (likely(R_ARC_32_ME == relo_type))
+		if (likely(R_ARC_32_ME == relo_type))	/* ME ( S + A ) */
 			arc_write_me((unsigned short *)location, relocation);
-		else if (R_ARC_32 == relo_type)
+		else if (R_ARC_32 == relo_type)		/* ( S + A ) */
 			*((Elf32_Addr *) location) = relocation;
+		else if (R_ARC_32_PCREL == relo_type)	/* ( S + A ) - PDATA ) */
+			*((Elf32_Addr *) location) = relocation - location;
 		else
 			goto relo_err;
 
-- 
2.7.4



From Vineet.Gupta1 at synopsys.com  Mon Sep 19 14:49:32 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Mon, 19 Sep 2016 14:49:32 -0700
Subject: [PATCH 2/3] ARC: dw2 unwind: factor CIE specifics for
 .eh_frame/.debug_frame
In-Reply-To: <1474321773-18166-1-git-send-email-vgupta@synopsys.com>
References: <1474321773-18166-1-git-send-email-vgupta@synopsys.com>
Message-ID: <1474321773-18166-3-git-send-email-vgupta@synopsys.com>

This paves way for switching to .eh_frame based unwindiing

Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
---
 arch/arc/kernel/unwind.c | 25 ++++++++++++++++++-------
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/arch/arc/kernel/unwind.c b/arch/arc/kernel/unwind.c
index 0587bf121d11..4e5dbe7617a1 100644
--- a/arch/arc/kernel/unwind.c
+++ b/arch/arc/kernel/unwind.c
@@ -111,6 +111,8 @@ UNW_REGISTER_INFO};
 #define DW_EH_PE_indirect 0x80
 #define DW_EH_PE_omit     0xff
 
+#define CIE_ID	0xffffffffUL
+
 typedef unsigned long uleb128_t;
 typedef signed long sleb128_t;
 
@@ -232,6 +234,7 @@ void __init arc_unwind_init(void)
 
 static const u32 bad_cie, not_fde;
 static const u32 *cie_for_fde(const u32 *fde, const struct unwind_table *);
+static const u32 *__cie_for_fde(const u32 *fde);
 static signed fde_pointer_type(const u32 *cie);
 
 struct eh_frame_hdr_table_entry {
@@ -338,10 +341,9 @@ static void init_unwind_hdr(struct unwind_table *table,
 	for (fde = table->address, tableSize = table->size, n = 0;
 	     tableSize;
 	     tableSize -= sizeof(*fde) + *fde, fde += 1 + *fde / sizeof(*fde)) {
-		/* const u32 *cie = fde + 1 - fde[1] / sizeof(*fde); */
-		const u32 *cie = (const u32 *)(fde[1]);
+		const u32 *cie = __cie_for_fde(fde);
 
-		if (fde[1] == 0xffffffff)
+		if (fde[1] == CIE_ID)
 			continue;	/* this is a CIE */
 		ptr = (const u8 *)(fde + 2);
 		header->table[n].start = read_pointer(&ptr,
@@ -504,6 +506,16 @@ static sleb128_t get_sleb128(const u8 **pcur, const u8 *end)
 	return value;
 }
 
+static const u32 *__cie_for_fde(const u32 *fde)
+{
+	const u32 *cie;
+
+	/* cie = fde + 1 - fde[1] / sizeof(*fde); */
+	cie = (u32 *) fde[1];
+
+	return cie;
+}
+
 static const u32 *cie_for_fde(const u32 *fde, const struct unwind_table *table)
 {
 	const u32 *cie;
@@ -511,19 +523,18 @@ static const u32 *cie_for_fde(const u32 *fde, const struct unwind_table *table)
 	if (!*fde || (*fde & (sizeof(*fde) - 1)))
 		return &bad_cie;
 
-	if (fde[1] == 0xffffffff)
+	if (fde[1] == CIE_ID)
 		return &not_fde;	/* this is a CIE */
 
 	if ((fde[1] & (sizeof(*fde) - 1)))
 /* || fde[1] > (unsigned long)(fde + 1) - (unsigned long)table->address) */
 		return NULL;	/* this is not a valid FDE */
 
-	/* cie = fde + 1 - fde[1] / sizeof(*fde); */
-	cie = (u32 *) fde[1];
+	cie = __cie_for_fde(fde);
 
 	if (*cie <= sizeof(*cie) + 4 || *cie >= fde[1] - sizeof(*fde)
 	    || (*cie & (sizeof(*cie) - 1))
-	    || (cie[1] != 0xffffffff))
+	    || (cie[1] != CIE_ID))
 		return NULL;	/* this is not a (valid) CIE */
 	return cie;
 }
-- 
2.7.4



From Vineet.Gupta1 at synopsys.com  Mon Sep 19 14:49:33 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Mon, 19 Sep 2016 14:49:33 -0700
Subject: [PATCH 3/3] ARC: dw2 unwind: switch to .eh_frame based unwinding
In-Reply-To: <1474321773-18166-1-git-send-email-vgupta@synopsys.com>
References: <1474321773-18166-1-git-send-email-vgupta@synopsys.com>
Message-ID: <1474321773-18166-4-git-send-email-vgupta@synopsys.com>

So finally after almost 8 years of dealing with .debug_frame, we are
finally switching to .eh_frame. The reason being stripped kernel
binaries had non-functional unwinder as .debug_frame was gone.
Also, in general .eh_frame seems more common way of doing unwinding.

This also folds a revert of f52e126cc747 ("ARC: unwind: ensure that
.debug_frame is generated (vs. .eh_frame)") to ensure that we start
getting .eh_frame

Reported-by: Daniel Mentz <danielmentz at google.com>
Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
---
 arch/arc/Makefile             |  2 ++
 arch/arc/kernel/entry.S       | 12 ------------
 arch/arc/kernel/module.c      | 13 ++++---------
 arch/arc/kernel/unwind.c      |  5 ++---
 arch/arc/kernel/vmlinux.lds.S | 15 +++++----------
 5 files changed, 13 insertions(+), 34 deletions(-)

diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index 601ed173080b..fc6ff8f09f23 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -66,6 +66,8 @@ endif
 
 endif
 
+cflags-$(CONFIG_ARC_DW2_UNWIND)		+= -fasynchronous-unwind-tables
+
 # By default gcc 4.8 generates dwarf4 which kernel unwinder can't grok
 ifeq ($(atleast_gcc48),y)
 cflags-$(CONFIG_ARC_DW2_UNWIND)		+= -gdwarf-2
diff --git a/arch/arc/kernel/entry.S b/arch/arc/kernel/entry.S
index 2efb0625331d..741712d4d6ff 100644
--- a/arch/arc/kernel/entry.S
+++ b/arch/arc/kernel/entry.S
@@ -61,18 +61,6 @@ ENTRY(ret_from_fork)
 	b    ret_from_exception
 END(ret_from_fork)
 
-#ifdef CONFIG_ARC_DW2_UNWIND
-; Workaround for bug 94179 (STAR ):
-; Despite -fasynchronous-unwind-tables, linker is not making dwarf2 unwinder
-; section (.debug_frame) as loadable. So we force it here.
-; This also fixes STAR 9000487933 where the prev-workaround (objcopy --setflag)
-; would not work after a clean build due to kernel build system dependencies.
-.section .debug_frame, "wa", at progbits
-
-; Reset to .text as this file is included in entry-<isa>.S
-.section .text, "ax", at progbits
-#endif
-
 ;################### Non TLB Exception Handling #############################
 
 ; ---------------------------------------------
diff --git a/arch/arc/kernel/module.c b/arch/arc/kernel/module.c
index 576a238434a1..9a2849756022 100644
--- a/arch/arc/kernel/module.c
+++ b/arch/arc/kernel/module.c
@@ -22,13 +22,9 @@ static inline void arc_write_me(unsigned short *addr, unsigned long value)
 	*(addr + 1) = (value & 0xffff);
 }
 
-/* ARC specific section quirks - before relocation loop in generic loader
- *
- * For dwarf unwinding out of modules, this needs to
- * 1. Ensure the .debug_frame is allocatable (ARC Linker bug: despite
- *    -fasynchronous-unwind-tables it doesn't).
- * 2. Since we are iterating thru sec hdr tbl anyways, make a note of
- *    the exact section index, for later use.
+/*
+ * This gets called before relocation loop in generic loader
+ * Make a note of the section index of unwinding section
  */
 int module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 			      char *secstr, struct module *mod)
@@ -40,8 +36,7 @@ int module_frob_arch_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 	mod->arch.unw_info = NULL;
 
 	for (i = 1; i < hdr->e_shnum; i++) {
-		if (strcmp(secstr+sechdrs[i].sh_name, ".debug_frame") == 0) {
-			sechdrs[i].sh_flags |= SHF_ALLOC;
+		if (strcmp(secstr+sechdrs[i].sh_name, ".eh_frame") == 0) {
 			mod->arch.unw_sec_idx = i;
 			break;
 		}
diff --git a/arch/arc/kernel/unwind.c b/arch/arc/kernel/unwind.c
index 4e5dbe7617a1..61fd1ce63c56 100644
--- a/arch/arc/kernel/unwind.c
+++ b/arch/arc/kernel/unwind.c
@@ -111,7 +111,7 @@ UNW_REGISTER_INFO};
 #define DW_EH_PE_indirect 0x80
 #define DW_EH_PE_omit     0xff
 
-#define CIE_ID	0xffffffffUL
+#define CIE_ID	0
 
 typedef unsigned long uleb128_t;
 typedef signed long sleb128_t;
@@ -510,8 +510,7 @@ static const u32 *__cie_for_fde(const u32 *fde)
 {
 	const u32 *cie;
 
-	/* cie = fde + 1 - fde[1] / sizeof(*fde); */
-	cie = (u32 *) fde[1];
+	cie = fde + 1 - fde[1] / sizeof(*fde);
 
 	return cie;
 }
diff --git a/arch/arc/kernel/vmlinux.lds.S b/arch/arc/kernel/vmlinux.lds.S
index 894e696bddaa..bb6d8c5ff2e9 100644
--- a/arch/arc/kernel/vmlinux.lds.S
+++ b/arch/arc/kernel/vmlinux.lds.S
@@ -84,7 +84,7 @@ SECTIONS
 
 	/*
 	 * .exit.text is discard at runtime, not link time, to deal with
-	 * references from .debug_frame
+	 * references from unwinding sections
 	 * It will be init freed, being inside [__init_start : __init_end]
 	 */
 	.exit.text : { EXIT_TEXT }
@@ -120,18 +120,13 @@ SECTIONS
 
 #ifdef CONFIG_ARC_DW2_UNWIND
 	. = ALIGN(PAGE_SIZE);
-	.debug_frame  : {
+	.eh_frame  : {
 		__start_unwind = .;
-		*(.debug_frame)
+		*(.eh_frame)
 		__end_unwind = .;
 	}
-	/*
-	 * gcc 4.8 generates this for -fasynchonous-unwind-tables,
-	 * while we still use the .debug_frame based unwinder
-	 */
-	/DISCARD/ : {	*(.eh_frame) }
 #else
-	/DISCARD/ : {	*(.debug_frame) }
+	/DISCARD/ : {	*(.eh_frame) }
 #endif
 
 	NOTES
@@ -148,7 +143,7 @@ SECTIONS
 	}
 
 #ifndef CONFIG_DEBUG_INFO
-	/* open-coded because we need .debug_frame seperately for unwinding */
+	/DISCARD/ : { *(.debug_frame) }
 	/DISCARD/ : { *(.debug_aranges) }
 	/DISCARD/ : { *(.debug_pubnames) }
 	/DISCARD/ : { *(.debug_info) }
-- 
2.7.4



From danielmentz at google.com  Mon Sep 19 18:21:48 2016
From: danielmentz at google.com (Daniel Mentz)
Date: Mon, 19 Sep 2016 18:21:48 -0700
Subject: [PATCH 0/3] ARC unwinder switch to .eh_frame
In-Reply-To: <1474321773-18166-1-git-send-email-vgupta@synopsys.com>
References: <1474321773-18166-1-git-send-email-vgupta@synopsys.com>
Message-ID: <CAE2F3rA0FrrNiHe6W6DSqYmpTyTiVD3h-wpGtW7rJ07RJLqqgw@mail.gmail.com>

Hi Vineet,

Thank you for your patches. I applied them, and verified that
unwinding works with code that is compiled into the kernel image as
well as kernel modules.
I confirmed that the .eh_frame section is present and that the
.debug_frame section is absent. I also verified that the file size of
the .ko files are small enough for our embedded platform and that
unnecessary sections like .debug_info, .debug_line, .debug_str etc.
are also absent.
Is there anything else you want me to test?
Thanks
Daniel


On Mon, Sep 19, 2016 at 2:49 PM, Vineet Gupta
<Vineet.Gupta1 at synopsys.com> wrote:
> Hi Daniel,
>
> Give these a shot and let me know if they work fine for you.
> I'm working on some more improvements to unwinder which will follow
> a bit later.
>
> Thx,
> -Vineet
>
> Vineet Gupta (3):
>   ARC: module: support R_ARC_32_PCREL relocation
>   ARC: dw2 unwind: factor CIE specifics for .eh_frame/.debug_frame
>   ARC: dw2 unwind: switch to .eh_frame based unwinding
>
>  arch/arc/Makefile             |  2 ++
>  arch/arc/include/asm/elf.h    |  3 +--
>  arch/arc/kernel/entry.S       | 12 ------------
>  arch/arc/kernel/module.c      | 19 ++++++++-----------
>  arch/arc/kernel/unwind.c      | 24 +++++++++++++++++-------
>  arch/arc/kernel/vmlinux.lds.S | 15 +++++----------
>  6 files changed, 33 insertions(+), 42 deletions(-)
>
> --
> 2.7.4
>


From vgupta at synopsys.com  Mon Sep 19 23:13:42 2016
From: vgupta at synopsys.com (Vineet Gupta)
Date: Mon, 19 Sep 2016 23:13:42 -0700
Subject: [PATCH 0/3] ARC unwinder switch to .eh_frame
In-Reply-To: <CAE2F3rA0FrrNiHe6W6DSqYmpTyTiVD3h-wpGtW7rJ07RJLqqgw@mail.gmail.com>
References: <1474321773-18166-1-git-send-email-vgupta@synopsys.com>
 <CAE2F3rA0FrrNiHe6W6DSqYmpTyTiVD3h-wpGtW7rJ07RJLqqgw@mail.gmail.com>
Message-ID: <2aa8d6d7-b489-e51e-dc18-fceb5300f6d2@synopsys.com>

On 09/19/2016 06:21 PM, Daniel Mentz wrote:
> Hi Vineet,
> 
> Thank you for your patches. I applied them, and verified that
> unwinding works with code that is compiled into the kernel image as
> well as kernel modules.
> I confirmed that the .eh_frame section is present and that the
> .debug_frame section is absent. I also verified that the file size of
> the .ko files are small enough for our embedded platform and that
> unnecessary sections like .debug_info, .debug_line, .debug_str etc.
> are also absent.
> Is there anything else you want me to test?
> Thanks
> Daniel

Nope - that is it. Just wanted to make sure it is "field" tested :-)

Thx,
-Vineet


> On Mon, Sep 19, 2016 at 2:49 PM, Vineet Gupta
> <Vineet.Gupta1 at synopsys.com> wrote:
>> Hi Daniel,
>>
>> Give these a shot and let me know if they work fine for you.
>> I'm working on some more improvements to unwinder which will follow
>> a bit later.
>>
>> Thx,
>> -Vineet
>>
>> Vineet Gupta (3):
>>   ARC: module: support R_ARC_32_PCREL relocation
>>   ARC: dw2 unwind: factor CIE specifics for .eh_frame/.debug_frame
>>   ARC: dw2 unwind: switch to .eh_frame based unwinding
>>
>>  arch/arc/Makefile             |  2 ++
>>  arch/arc/include/asm/elf.h    |  3 +--
>>  arch/arc/kernel/entry.S       | 12 ------------
>>  arch/arc/kernel/module.c      | 19 ++++++++-----------
>>  arch/arc/kernel/unwind.c      | 24 +++++++++++++++++-------
>>  arch/arc/kernel/vmlinux.lds.S | 15 +++++----------
>>  6 files changed, 33 insertions(+), 42 deletions(-)
>>
>> --
>> 2.7.4
>>
> 



From Vineet.Gupta1 at synopsys.com  Tue Sep 20 13:56:20 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Tue, 20 Sep 2016 13:56:20 -0700
Subject: perf event grouping for dummies (was Re: [PATCH] arc: perf: Enable
 generic "cache-references" and "cache-misses" events)
In-Reply-To: <20160901083324.GM10153@twins.programming.kicks-ass.net>
References: <1472125647-518-1-git-send-email-abrodkin@synopsys.com>
 <6074e252-6e18-bb01-4de1-023bd7e82f03@synopsys.com>
 <5f65fa04-8d33-e525-115d-4e6991a7668e@synopsys.com>
 <20160901083324.GM10153@twins.programming.kicks-ass.net>
Message-ID: <2a18ae06-3abd-c3a1-e980-f04c511b08e5@synopsys.com>

On 09/01/2016 01:33 AM, Peter Zijlstra wrote:
>> - is that what perf event grouping is ?
>
> Again, nope. Perf event groups are single counter (so no implicit
> addition) that are co-scheduled on the PMU.

I'm not sure I understand - does this require specific PMU/arch support - as in
multiple conditions feeding to same counter. How does perf user make use of this
info - I tried googling around but can't seem to find anything which explains the
semantics.

I can see that group events to work on ARC (although in our case a counter can
cont one condition at a time only) and the results seem to be similar whther we
group or not.

------------->8------------
[ARCLinux]# perf stat -e {cycles,instructions} hackbench
Running with 10*40 (== 400) tasks.
Time: 37.430

 Performance counter stats for 'hackbench':

        3487777173    cycles
        1351709784    instructions            #    0.39  insn per cycle

      38.957481536 seconds time elapsed

[ARCLinux]# perf stat -e cycles hackbench
Running with 10*40 (== 400) tasks.
Time: 36.735

 Performance counter stats for 'hackbench':

        3426151391    cycles

      38.247235981 seconds time elapsed

[ARCLinux]#
[ARCLinux]# perf stat -e instructions hackbench
Running with 10*40 (== 400) tasks.
Time: 37.537

 Performance counter stats for 'hackbench':

        1355421559    instructions

      39.061784281 seconds time elapsed
------------->8------------

...
> 
> You can do it like:
> 
> 	perf stat -e '{cycles,instructions}'
> 
> Which will place the cycles event and the instructions event in a group
> and thereby guarantee they're co-scheduled.

Again when you say co-scheduled what do you mean - why would anyone use the event
grouping - is it when they only have 1 counter and they want to count 2
conditions/events at the same time - isn't this same as event multiplexing ?

-Vineet


From Vineet.Gupta1 at synopsys.com  Tue Sep 20 14:48:48 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Tue, 20 Sep 2016 14:48:48 -0700
Subject: [PATCH] ARCv2: intc: Use kflag if STATUS32.IE must be reset
In-Reply-To: <1473695703-29547-1-git-send-email-yuriy.kolerov@synopsys.com>
References: <1473695703-29547-1-git-send-email-yuriy.kolerov@synopsys.com>
Message-ID: <d78e66ad-6909-b90e-6061-7ef414e94d4a@synopsys.com>

On 09/12/2016 08:55 AM, Yuriy Kolerov wrote:
> In the end of "arc_init_IRQ" STATUS32.IE flag is going to be affected by
> "flag" instruction but "flag" never touches IE flag on ARCv2. So "kflag"
> instruction must be used instead of "flag".
> 
> Signed-off-by: Yuriy Kolerov <yuriy.kolerov at synopsys.com>

Applied to for-next for 4.9 + stable backport.

Thx,
-Vineet


From noamca at mellanox.com  Wed Sep 21 03:51:48 2016
From: noamca at mellanox.com (Noam Camus)
Date: Wed, 21 Sep 2016 13:51:48 +0300
Subject: [PATCH] ARC: CONFIG_NODES_SHIFT fix default values
Message-ID: <1474455108-13550-1-git-send-email-noamca@mellanox.com>

From: Noam Camus <noamca at mellanox.com>

Seem like values assigned as absolute number and not and
shift value, i.e. should be 0 for one node (2^0) and 1 for
couple of nodes (2^1)

Signed-off-by: Noam Camus <noamca at mellanox.com>
---
 arch/arc/Kconfig |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 6af0b43..f347715 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -383,8 +383,8 @@ endchoice
 
 config NODES_SHIFT
 	int "Maximum NUMA Nodes (as a power of 2)"
-	default "1" if !DISCONTIGMEM
-	default "2" if DISCONTIGMEM
+	default "0" if !DISCONTIGMEM
+	default "1" if DISCONTIGMEM
 	depends on NEED_MULTIPLE_NODES
 	---help---
 	  Accessing memory beyond 1GB (with or w/o PAE) requires 2 memory
-- 
1.7.1



From pc at us.ibm.com  Wed Sep 21 17:43:28 2016
From: pc at us.ibm.com (Paul Clarke)
Date: Wed, 21 Sep 2016 19:43:28 -0500
Subject: perf event grouping for dummies (was Re: [PATCH] arc: perf:
 Enable generic "cache-references" and "cache-misses" events)
In-Reply-To: <2a18ae06-3abd-c3a1-e980-f04c511b08e5@synopsys.com>
References: <1472125647-518-1-git-send-email-abrodkin@synopsys.com>
 <6074e252-6e18-bb01-4de1-023bd7e82f03@synopsys.com>
 <5f65fa04-8d33-e525-115d-4e6991a7668e@synopsys.com>
 <20160901083324.GM10153@twins.programming.kicks-ass.net>
 <2a18ae06-3abd-c3a1-e980-f04c511b08e5@synopsys.com>
Message-ID: <04f6dcd2-35c6-6e28-2dcf-bc5f0bb446dc@us.ibm.com>

On 09/20/2016 03:56 PM, Vineet Gupta wrote:
> On 09/01/2016 01:33 AM, Peter Zijlstra wrote:
>>> - is that what perf event grouping is ?
>>
>> Again, nope. Perf event groups are single counter (so no implicit
>> addition) that are co-scheduled on the PMU.
>
> I'm not sure I understand - does this require specific PMU/arch support - as in
> multiple conditions feeding to same counter.

My read is that is that what Peter meant was that each event in the perf event group is a single counter, so all the events in the group are counted simultaneously.  (No multiplexing.)

>> You can do it like:
>>
>> 	perf stat -e '{cycles,instructions}'
>>
>> Which will place the cycles event and the instructions event in a group
>> and thereby guarantee they're co-scheduled.
>
> Again when you say co-scheduled what do you mean - why would anyone use the event
> grouping - is it when they only have 1 counter and they want to count 2
> conditions/events at the same time - isn't this same as event multiplexing ?

I'd say it's the converse of multiplexing.  Instead of mapping multiple events to a single counter, perf event groups map a set of events each to their own counter, and they are active simultaneously.  I suppose it's possible for the _groups_ to be multiplexed with other events or groups, but the group as a whole will be scheduled together, as a group.

If you have a single counter, I don't believe you can support perf event groups, by definition.

Regards,
Paul Clarke, IBM



From peterz at infradead.org  Thu Sep 22 00:56:03 2016
From: peterz at infradead.org (Peter Zijlstra)
Date: Thu, 22 Sep 2016 09:56:03 +0200
Subject: perf event grouping for dummies (was Re: [PATCH] arc: perf:
 Enable generic "cache-references" and "cache-misses" events)
In-Reply-To: <04f6dcd2-35c6-6e28-2dcf-bc5f0bb446dc@us.ibm.com>
References: <1472125647-518-1-git-send-email-abrodkin@synopsys.com>
 <6074e252-6e18-bb01-4de1-023bd7e82f03@synopsys.com>
 <5f65fa04-8d33-e525-115d-4e6991a7668e@synopsys.com>
 <20160901083324.GM10153@twins.programming.kicks-ass.net>
 <2a18ae06-3abd-c3a1-e980-f04c511b08e5@synopsys.com>
 <04f6dcd2-35c6-6e28-2dcf-bc5f0bb446dc@us.ibm.com>
Message-ID: <20160922075603.GW5008@twins.programming.kicks-ass.net>

On Wed, Sep 21, 2016 at 07:43:28PM -0500, Paul Clarke wrote:
> On 09/20/2016 03:56 PM, Vineet Gupta wrote:
> >On 09/01/2016 01:33 AM, Peter Zijlstra wrote:
> >>>- is that what perf event grouping is ?
> >>
> >>Again, nope. Perf event groups are single counter (so no implicit
> >>addition) that are co-scheduled on the PMU.
> >
> >I'm not sure I understand - does this require specific PMU/arch support - as in
> >multiple conditions feeding to same counter.
> 
> My read is that is that what Peter meant was that each event in the
> perf event group is a single counter, so all the events in the group
> are counted simultaneously.  (No multiplexing.)

Right, sorry for the poor wording.

> >Again when you say co-scheduled what do you mean - why would anyone use the event
> >grouping - is it when they only have 1 counter and they want to count 2
> >conditions/events at the same time - isn't this same as event multiplexing ?
> 
> I'd say it's the converse of multiplexing.  Instead of mapping
> multiple events to a single counter, perf event groups map a set of
> events each to their own counter, and they are active simultaneously.
> I suppose it's possible for the _groups_ to be multiplexed with other
> events or groups, but the group as a whole will be scheduled together,
> as a group.

Correct.

Each events get their own hardware counter. Grouped events are
co-scheduled on the hardware.

You can multiplex groups. But if one event in a group is schedule, they
all must be.




From gregkh at linuxfoundation.org  Thu Sep 22 10:29:59 2016
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Thu, 22 Sep 2016 19:29:59 +0200
Subject: [PATCH 4.4 099/118] ARC: uaccess: get_user to zero out dest in cause
 of fault
In-Reply-To: <20160922172938.643879685@linuxfoundation.org>
References: <20160922172938.643879685@linuxfoundation.org>
Message-ID: <20160922172943.597395919@linuxfoundation.org>

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Vineet Gupta <Vineet.Gupta1 at synopsys.com>

commit 05d9d0b96e53c52a113fd783c0c97c830c8dc7af upstream.

Al reported potential issue with ARC get_user() as it wasn't clearing
out destination pointer in case of fault due to bad address etc.

Verified using following

| {
|  	u32 bogus1 = 0xdeadbeef;
|	u64 bogus2 = 0xdead;
|	int rc1, rc2;
|
|  	pr_info("Orig values %x %llx\n", bogus1, bogus2);
|	rc1 = get_user(bogus1, (u32 __user *)0x40000000);
|	rc2 = get_user(bogus2, (u64 __user *)0x50000000);
|	pr_info("access %d %d, new values %x %llx\n",
|		rc1, rc2, bogus1, bogus2);
| }

| [ARCLinux]# insmod /mnt/kernel-module/qtn.ko
| Orig values deadbeef dead
| access -14 -14, new values 0 0

Reported-by: Al Viro <viro at ZenIV.linux.org.uk>
Cc: Linus Torvalds <torvalds at linux-foundation.org>
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
Signed-off-by: Al Viro <viro at zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>

---
 arch/arc/include/asm/uaccess.h |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

--- a/arch/arc/include/asm/uaccess.h
+++ b/arch/arc/include/asm/uaccess.h
@@ -83,7 +83,10 @@
 	"2:	;nop\n"				\
 	"	.section .fixup, \"ax\"\n"	\
 	"	.align 4\n"			\
-	"3:	mov %0, %3\n"			\
+	"3:	# return -EFAULT\n"		\
+	"	mov %0, %3\n"			\
+	"	# zero out dst ptr\n"		\
+	"	mov %1,  0\n"			\
 	"	j   2b\n"			\
 	"	.previous\n"			\
 	"	.section __ex_table, \"a\"\n"	\
@@ -101,7 +104,11 @@
 	"2:	;nop\n"				\
 	"	.section .fixup, \"ax\"\n"	\
 	"	.align 4\n"			\
-	"3:	mov %0, %3\n"			\
+	"3:	# return -EFAULT\n"		\
+	"	mov %0, %3\n"			\
+	"	# zero out dst ptr\n"		\
+	"	mov %1,  0\n"			\
+	"	mov %R1, 0\n"			\
 	"	j   2b\n"			\
 	"	.previous\n"			\
 	"	.section __ex_table, \"a\"\n"	\




From Vineet.Gupta1 at synopsys.com  Thu Sep 22 10:50:21 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Thu, 22 Sep 2016 10:50:21 -0700
Subject: perf event grouping for dummies (was Re: [PATCH] arc: perf:
 Enable generic "cache-references" and "cache-misses" events)
In-Reply-To: <20160922075603.GW5008@twins.programming.kicks-ass.net>
References: <1472125647-518-1-git-send-email-abrodkin@synopsys.com>
 <6074e252-6e18-bb01-4de1-023bd7e82f03@synopsys.com>
 <5f65fa04-8d33-e525-115d-4e6991a7668e@synopsys.com>
 <20160901083324.GM10153@twins.programming.kicks-ass.net>
 <2a18ae06-3abd-c3a1-e980-f04c511b08e5@synopsys.com>
 <04f6dcd2-35c6-6e28-2dcf-bc5f0bb446dc@us.ibm.com>
 <20160922075603.GW5008@twins.programming.kicks-ass.net>
Message-ID: <b15fc87b-c846-fdb5-ef6a-48fc2d797917@synopsys.com>

On 09/22/2016 12:56 AM, Peter Zijlstra wrote:
> On Wed, Sep 21, 2016 at 07:43:28PM -0500, Paul Clarke wrote:
>> On 09/20/2016 03:56 PM, Vineet Gupta wrote:
>>> On 09/01/2016 01:33 AM, Peter Zijlstra wrote:
>>>>> - is that what perf event grouping is ?
>>>>
>>>> Again, nope. Perf event groups are single counter (so no implicit
>>>> addition) that are co-scheduled on the PMU.
>>>
>>> I'm not sure I understand - does this require specific PMU/arch support - as in
>>> multiple conditions feeding to same counter.
>>
>> My read is that is that what Peter meant was that each event in the
>> perf event group is a single counter, so all the events in the group
>> are counted simultaneously.  (No multiplexing.)
> 
> Right, sorry for the poor wording.
> 
>>> Again when you say co-scheduled what do you mean - why would anyone use the event
>>> grouping - is it when they only have 1 counter and they want to count 2
>>> conditions/events at the same time - isn't this same as event multiplexing ?
>>
>> I'd say it's the converse of multiplexing.  Instead of mapping
>> multiple events to a single counter, perf event groups map a set of
>> events each to their own counter, and they are active simultaneously.
>> I suppose it's possible for the _groups_ to be multiplexed with other
>> events or groups, but the group as a whole will be scheduled together,
>> as a group.
> 
> Correct.
> 
> Each events get their own hardware counter. Grouped events are
> co-scheduled on the hardware.

And if we don't group them, then they _may_ not be co-scheduled (active/counting
at the same time) ? But how can this be possible.
Say we have 2 counters, both the cmds below

     perf -e cycles,instructions hackbench
     perf -e {cycles,instructions} hackbench

would assign 2 counters to the 2 conditions which keep counting until perf asks
them to stop (because the profiled application ended)

I don't understand the "scheduling" of counter - once we set them to count, there
is no real intervention/scheduling form software in terms of disabling/enabling
(assuming no multiplexing etc)

> You can multiplex groups. But if one event in a group is schedule, they
> all must be.



From gregkh at linuxfoundation.org  Thu Sep 22 10:41:36 2016
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Thu, 22 Sep 2016 19:41:36 +0200
Subject: [PATCH 4.7 162/184] ARC: uaccess: get_user to zero out dest in cause
 of fault
In-Reply-To: <20160922174048.653794923@linuxfoundation.org>
References: <20160922174048.653794923@linuxfoundation.org>
Message-ID: <20160922174055.638982632@linuxfoundation.org>

4.7-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Vineet Gupta <Vineet.Gupta1 at synopsys.com>

commit 05d9d0b96e53c52a113fd783c0c97c830c8dc7af upstream.

Al reported potential issue with ARC get_user() as it wasn't clearing
out destination pointer in case of fault due to bad address etc.

Verified using following

| {
|  	u32 bogus1 = 0xdeadbeef;
|	u64 bogus2 = 0xdead;
|	int rc1, rc2;
|
|  	pr_info("Orig values %x %llx\n", bogus1, bogus2);
|	rc1 = get_user(bogus1, (u32 __user *)0x40000000);
|	rc2 = get_user(bogus2, (u64 __user *)0x50000000);
|	pr_info("access %d %d, new values %x %llx\n",
|		rc1, rc2, bogus1, bogus2);
| }

| [ARCLinux]# insmod /mnt/kernel-module/qtn.ko
| Orig values deadbeef dead
| access -14 -14, new values 0 0

Reported-by: Al Viro <viro at ZenIV.linux.org.uk>
Cc: Linus Torvalds <torvalds at linux-foundation.org>
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
Signed-off-by: Al Viro <viro at zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>

---
 arch/arc/include/asm/uaccess.h |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

--- a/arch/arc/include/asm/uaccess.h
+++ b/arch/arc/include/asm/uaccess.h
@@ -83,7 +83,10 @@
 	"2:	;nop\n"				\
 	"	.section .fixup, \"ax\"\n"	\
 	"	.align 4\n"			\
-	"3:	mov %0, %3\n"			\
+	"3:	# return -EFAULT\n"		\
+	"	mov %0, %3\n"			\
+	"	# zero out dst ptr\n"		\
+	"	mov %1,  0\n"			\
 	"	j   2b\n"			\
 	"	.previous\n"			\
 	"	.section __ex_table, \"a\"\n"	\
@@ -101,7 +104,11 @@
 	"2:	;nop\n"				\
 	"	.section .fixup, \"ax\"\n"	\
 	"	.align 4\n"			\
-	"3:	mov %0, %3\n"			\
+	"3:	# return -EFAULT\n"		\
+	"	mov %0, %3\n"			\
+	"	# zero out dst ptr\n"		\
+	"	mov %1,  0\n"			\
+	"	mov %R1, 0\n"			\
 	"	j   2b\n"			\
 	"	.previous\n"			\
 	"	.section __ex_table, \"a\"\n"	\




From pc at us.ibm.com  Thu Sep 22 11:23:04 2016
From: pc at us.ibm.com (Paul Clarke)
Date: Thu, 22 Sep 2016 13:23:04 -0500
Subject: perf event grouping for dummies (was Re: [PATCH] arc: perf:
 Enable generic "cache-references" and "cache-misses" events)
In-Reply-To: <b15fc87b-c846-fdb5-ef6a-48fc2d797917@synopsys.com>
References: <1472125647-518-1-git-send-email-abrodkin@synopsys.com>
 <6074e252-6e18-bb01-4de1-023bd7e82f03@synopsys.com>
 <5f65fa04-8d33-e525-115d-4e6991a7668e@synopsys.com>
 <20160901083324.GM10153@twins.programming.kicks-ass.net>
 <2a18ae06-3abd-c3a1-e980-f04c511b08e5@synopsys.com>
 <04f6dcd2-35c6-6e28-2dcf-bc5f0bb446dc@us.ibm.com>
 <20160922075603.GW5008@twins.programming.kicks-ass.net>
 <b15fc87b-c846-fdb5-ef6a-48fc2d797917@synopsys.com>
Message-ID: <4351119f-b212-5039-9a3d-f568f6893b36@us.ibm.com>

On 09/22/2016 12:50 PM, Vineet Gupta wrote:
> On 09/22/2016 12:56 AM, Peter Zijlstra wrote:
>> On Wed, Sep 21, 2016 at 07:43:28PM -0500, Paul Clarke wrote:
>>> On 09/20/2016 03:56 PM, Vineet Gupta wrote:
>>>> On 09/01/2016 01:33 AM, Peter Zijlstra wrote:
>>>>>> - is that what perf event grouping is ?
>>>>>
>>>>> Again, nope. Perf event groups are single counter (so no implicit
>>>>> addition) that are co-scheduled on the PMU.
>>>>
>>>> I'm not sure I understand - does this require specific PMU/arch support - as in
>>>> multiple conditions feeding to same counter.
>>>
>>> My read is that is that what Peter meant was that each event in the
>>> perf event group is a single counter, so all the events in the group
>>> are counted simultaneously.  (No multiplexing.)
>>
>> Right, sorry for the poor wording.
>>
>>>> Again when you say co-scheduled what do you mean - why would anyone use the event
>>>> grouping - is it when they only have 1 counter and they want to count 2
>>>> conditions/events at the same time - isn't this same as event multiplexing ?
>>>
>>> I'd say it's the converse of multiplexing.  Instead of mapping
>>> multiple events to a single counter, perf event groups map a set of
>>> events each to their own counter, and they are active simultaneously.
>>> I suppose it's possible for the _groups_ to be multiplexed with other
>>> events or groups, but the group as a whole will be scheduled together,
>>> as a group.
>>
>> Correct.
>>
>> Each events get their own hardware counter. Grouped events are
>> co-scheduled on the hardware.
>
> And if we don't group them, then they _may_ not be co-scheduled (active/counting
> at the same time) ? But how can this be possible.
> Say we have 2 counters, both the cmds below
>
>      perf -e cycles,instructions hackbench
>      perf -e {cycles,instructions} hackbench
>
> would assign 2 counters to the 2 conditions which keep counting until perf asks
> them to stop (because the profiled application ended)
>
> I don't understand the "scheduling" of counter - once we set them to count, there
> is no real intervention/scheduling form software in terms of disabling/enabling
> (assuming no multiplexing etc)

If you assume no multiplexing, then this discussion on grouping is moot.

It depends on how many events you specify, how many counters there are, and which counters can count which events.  If you specify a set of events for which every event can be counted simultaneously, they will be scheduled simultaneously and continuously.  If you specify more events than counters, there's multiplexing.  AND, if you specify a set of events, some of which cannot be counted simultaneously due to hardware limitations, they'll be multiplexed.

PC



From acme at redhat.com  Thu Sep 22 12:42:52 2016
From: acme at redhat.com (Arnaldo Carvalho de Melo)
Date: Thu, 22 Sep 2016 16:42:52 -0300
Subject: perf event grouping for dummies (was Re: [PATCH] arc: perf:
 Enable generic "cache-references" and "cache-misses" events)
In-Reply-To: <4351119f-b212-5039-9a3d-f568f6893b36@us.ibm.com>
References: <1472125647-518-1-git-send-email-abrodkin@synopsys.com>
 <6074e252-6e18-bb01-4de1-023bd7e82f03@synopsys.com>
 <5f65fa04-8d33-e525-115d-4e6991a7668e@synopsys.com>
 <20160901083324.GM10153@twins.programming.kicks-ass.net>
 <2a18ae06-3abd-c3a1-e980-f04c511b08e5@synopsys.com>
 <04f6dcd2-35c6-6e28-2dcf-bc5f0bb446dc@us.ibm.com>
 <20160922075603.GW5008@twins.programming.kicks-ass.net>
 <b15fc87b-c846-fdb5-ef6a-48fc2d797917@synopsys.com>
 <4351119f-b212-5039-9a3d-f568f6893b36@us.ibm.com>
Message-ID: <20160922194252.GA2441@redhat.com>

Em Thu, Sep 22, 2016 at 01:23:04PM -0500, Paul Clarke escreveu:
> On 09/22/2016 12:50 PM, Vineet Gupta wrote:
> >On 09/22/2016 12:56 AM, Peter Zijlstra wrote:
> >>On Wed, Sep 21, 2016 at 07:43:28PM -0500, Paul Clarke wrote:
> >>>On 09/20/2016 03:56 PM, Vineet Gupta wrote:
> >>>>On 09/01/2016 01:33 AM, Peter Zijlstra wrote:
> >>>>>>- is that what perf event grouping is ?
> >>>>>
> >>>>>Again, nope. Perf event groups are single counter (so no implicit
> >>>>>addition) that are co-scheduled on the PMU.
> >>>>
> >>>>I'm not sure I understand - does this require specific PMU/arch support - as in
> >>>>multiple conditions feeding to same counter.
> >>>
> >>>My read is that is that what Peter meant was that each event in the
> >>>perf event group is a single counter, so all the events in the group
> >>>are counted simultaneously.  (No multiplexing.)
> >>
> >>Right, sorry for the poor wording.
> >>
> >>>>Again when you say co-scheduled what do you mean - why would anyone use the event
> >>>>grouping - is it when they only have 1 counter and they want to count 2
> >>>>conditions/events at the same time - isn't this same as event multiplexing ?
> >>>
> >>>I'd say it's the converse of multiplexing.  Instead of mapping
> >>>multiple events to a single counter, perf event groups map a set of
> >>>events each to their own counter, and they are active simultaneously.
> >>>I suppose it's possible for the _groups_ to be multiplexed with other
> >>>events or groups, but the group as a whole will be scheduled together,
> >>>as a group.
> >>
> >>Correct.
> >>
> >>Each events get their own hardware counter. Grouped events are
> >>co-scheduled on the hardware.
> >
> >And if we don't group them, then they _may_ not be co-scheduled (active/counting
> >at the same time) ? But how can this be possible.
> >Say we have 2 counters, both the cmds below
> >
> >     perf -e cycles,instructions hackbench
> >     perf -e {cycles,instructions} hackbench
> >
> >would assign 2 counters to the 2 conditions which keep counting until perf asks
> >them to stop (because the profiled application ended)
> >
> >I don't understand the "scheduling" of counter - once we set them to count, there
> >is no real intervention/scheduling form software in terms of disabling/enabling
> >(assuming no multiplexing etc)

So, getting this machine as an example:

[    0.067739] smpboot: CPU0: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz (family: 0x6, model: 0x3a, stepping: 0x9)
[    0.067744] Performance Events: PEBS fmt1+, 16-deep LBR, IvyBridge events, full-width counters, Intel PMU driver.
[    0.067774] ... version:                3
[    0.067776] ... bit width:              48
[    0.067777] ... generic registers:      4
[    0.067778] ... value mask:             0000ffffffffffff
[    0.067779] ... max period:             0000ffffffffffff
[    0.067780] ... fixed-purpose events:   3
[    0.067781] ... event mask:             000000070000000f
[    0.068694] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.

[root at zoo ~]# perf stat -e '{branch-instructions,branch-misses,bus-cycles,cache-misses}' ls a
ls: cannot access 'a': No such file or directory

 Performance counter stats for 'ls a':

           356,090      branch-instructions                                         
            17,170      branch-misses             #    4.82% of all branches        
           232,365      bus-cycles                                                  
            12,107      cache-misses                                                

       0.003624967 seconds time elapsed

[root at zoo ~]# perf stat -e '{branch-instructions,branch-misses,bus-cycles,cache-misses,cpu-cycles}' ls a
ls: cannot access 'a': No such file or directory

 Performance counter stats for 'ls a':

     <not counted>      branch-instructions                                           (0.00%)
     <not counted>      branch-misses                                                 (0.00%)
     <not counted>      bus-cycles                                                    (0.00%)
     <not counted>      cache-misses                                                  (0.00%)
     <not counted>      cpu-cycles                                                    (0.00%)

       0.003659678 seconds time elapsed

[root at zoo ~]#

That was as a group, i.e. those {} enclosing it, if you run it with -vv, among
other things you'll see the "group_fd" parameter to the sys_perf_event_open
syscall:

[root at zoo ~]# perf stat -vv -e '{branch-instructions,branch-misses,bus-cycles,cache-misses,cpu-cycles}' ls a
sys_perf_event_open: pid 28581  cpu -1  group_fd -1  flags 0x8
sys_perf_event_open: pid 28581  cpu -1  group_fd 3  flags 0x8
sys_perf_event_open: pid 28581  cpu -1  group_fd 3  flags 0x8
sys_perf_event_open: pid 28581  cpu -1  group_fd 3  flags 0x8
sys_perf_event_open: pid 28581  cpu -1  group_fd 3  flags 0x8
ls: cannot access 'a': No such file or directory

 Performance counter stats for 'ls a':

     <not counted>      branch-instructions                                           (0.00%)
     <not counted>      branch-misses                                                 (0.00%)
     <not counted>      bus-cycles                                                    (0.00%)
     <not counted>      cache-misses                                                  (0.00%)
     <not counted>      cpu-cycles                                                    (0.00%)

       0.002883209 seconds time elapsed

[root at zoo ~]#

So, the first one passes -1, to create the group, the fd it returns is '3',
that is used as group_fd for the other events in that group.

So the workload runs but nothing is counted, the kernel can't do what was
asked, i.e. schedule all those 5 hardware events _at the same time_, no
multiplexing of counters that can count different hardware events is performed
_for that task_.

If we remove that {}, i.e. say, no need to enable all those counters _at the
same time_, multiplex them _in the same task_ to be able to measure them all
to some degree, it "works":

[root at zoo ~]# perf stat -vv -e 'branch-instructions,branch-misses,bus-cycles,cache-misses,cpu-cycles' ls a
perf_event_attr: (For the first event:)
  config                           0x4
  read_format                      TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING
sys_perf_event_open: pid 28594  cpu -1  group_fd -1  flags 0x8
sys_perf_event_open: pid 28594  cpu -1  group_fd -1  flags 0x8
sys_perf_event_open: pid 28594  cpu -1  group_fd -1  flags 0x8
sys_perf_event_open: pid 28594  cpu -1  group_fd -1  flags 0x8
sys_perf_event_open: pid 28594  cpu -1  group_fd -1  flags 0x8

 Performance counter stats for 'ls a':

           317,892      branch-instructions                                           (53.01%)
            13,400      branch-misses             #    4.22% of all branches        
           201,578      bus-cycles                                                  
            11,326      cache-misses                                                
         2,203,482      cpu-cycles                                                    (78.44%)

       0.003026840 seconds time elapsed

[root at zoo ~]#

See the read_format? Those percentages? the group_fd = -1?

It all depends on these PMU resources:

[    0.067777] ... generic registers:      4
[    0.067780] ... fixed-purpose events:   3

Its this part of 'man perf_event_open':

  The  group_fd  argument  allows  event groups to be created.  An event group
has one event which is the group leader.  The leader is created first, with
group_fd = -1.  The rest of the group members are created with subsequent
perf_event_open() calls with group_fd being set to the file descrip? tor  of
the group leader.  (A single event on its own is created with group_fd = -1 and
is considered to be a group with only 1 member.)  An event group is scheduled
onto the CPU as a unit: it will be put onto the CPU only if all of the events
in the group can be put onto the CPU.  This  means that  the  values  of  the
member  events  can be meaningfully compared?added, divided (to get ratios),
and so on?with each other, since they have counted events for the same set of
executed instructions.

- Arnaldo
 
> If you assume no multiplexing, then this discussion on grouping is moot.
 
> It depends on how many events you specify, how many counters there
> are, and which counters can count which events.  If you specify a set
> of events for which every event can be counted simultaneously, they
> will be scheduled simultaneously and continuously.  If you specify
> more events than counters, there's multiplexing.  AND, if you specify

There is multiplexing if group_fd is set to -1 in all events.

> a set of events, some of which cannot be counted simultaneously due to
> hardware limitations, they'll be multiplexed.

Not if group_fd is set to a group leader.
 
> PC


From Vineet.Gupta1 at synopsys.com  Thu Sep 22 13:39:06 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Thu, 22 Sep 2016 13:39:06 -0700
Subject: [PATCH 0/3] ARC unwinder switch to .eh_frame
In-Reply-To: <2aa8d6d7-b489-e51e-dc18-fceb5300f6d2@synopsys.com>
References: <1474321773-18166-1-git-send-email-vgupta@synopsys.com>
 <CAE2F3rA0FrrNiHe6W6DSqYmpTyTiVD3h-wpGtW7rJ07RJLqqgw@mail.gmail.com>
 <2aa8d6d7-b489-e51e-dc18-fceb5300f6d2@synopsys.com>
Message-ID: <758f899b-0b12-cfe5-225f-8764368a8b6d@synopsys.com>

Hi Daniel,

On 09/19/2016 11:13 PM, Vineet Gupta wrote:
> On 09/19/2016 06:21 PM, Daniel Mentz wrote:
>> > Hi Vineet,
>> > 
>> > Thank you for your patches. I applied them, and verified that
>> > unwinding works with code that is compiled into the kernel image as
>> > well as kernel modules.
>> > I confirmed that the .eh_frame section is present and that the
>> > .debug_frame section is absent. I also verified that the file size of
>> > the .ko files are small enough for our embedded platform and that
>> > unnecessary sections like .debug_info, .debug_line, .debug_str etc.
>> > are also absent.
>> > Is there anything else you want me to test?
>> > Thanks
>> > Daniel
> Nope - that is it. Just wanted to make sure it is "field" tested :-)
> 
> Thx,
> -Vineet

FYI - I've pushed some more changes to unwinding department so that we get
call-traces for memset/memcpy et al.

git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git  #for-next

-Vineet




From Vineet.Gupta1 at synopsys.com  Thu Sep 22 13:59:12 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Thu, 22 Sep 2016 13:59:12 -0700
Subject: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch
 to .eh_frame)
In-Reply-To: <CAE2F3rA0FrrNiHe6W6DSqYmpTyTiVD3h-wpGtW7rJ07RJLqqgw@mail.gmail.com>
References: <1474321773-18166-1-git-send-email-vgupta@synopsys.com>
 <CAE2F3rA0FrrNiHe6W6DSqYmpTyTiVD3h-wpGtW7rJ07RJLqqgw@mail.gmail.com>
Message-ID: <caee47ec-eb68-59ee-50dc-ee02c4d78b7d@synopsys.com>

Hi Daniel,

On 09/19/2016 06:21 PM, Daniel Mentz wrote:
> I confirmed that the .eh_frame section is present and that the
> .debug_frame section is absent. I also verified that the file size of
> the .ko files are small enough for our embedded platform and that
> unnecessary sections like .debug_info, .debug_line, .debug_str etc.
> are also absent.

BTW it seems with my latest set of patches, modules still have .debug_*.
Can you double check if your tree still has the interim patch which added a linker
script for modules to strip out .debug_*

http://lists.infradead.org/pipermail/linux-snps-arc/2016-September/001483.html

I'm not planning to carry it and would prefer addressing the the root cause by
removing the -gdwarf-2 toggle. I've added that and pushed rebased series. Care to
take it for a respin please.

Thx,
-Vineet


From danielmentz at google.com  Thu Sep 22 15:37:35 2016
From: danielmentz at google.com (Daniel Mentz)
Date: Thu, 22 Sep 2016 15:37:35 -0700
Subject: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder
 switch to .eh_frame)
In-Reply-To: <caee47ec-eb68-59ee-50dc-ee02c4d78b7d@synopsys.com>
References: <1474321773-18166-1-git-send-email-vgupta@synopsys.com>
 <CAE2F3rA0FrrNiHe6W6DSqYmpTyTiVD3h-wpGtW7rJ07RJLqqgw@mail.gmail.com>
 <caee47ec-eb68-59ee-50dc-ee02c4d78b7d@synopsys.com>
Message-ID: <CAE2F3rBR872+M=mm7Qa5cccrtmOOp5cyZKSWjc4ytOG717jxKQ@mail.gmail.com>

On Thu, Sep 22, 2016 at 1:59 PM, Vineet Gupta
<Vineet.Gupta1 at synopsys.com> wrote:
> Hi Daniel,
>
> On 09/19/2016 06:21 PM, Daniel Mentz wrote:
>> I confirmed that the .eh_frame section is present and that the
>> .debug_frame section is absent. I also verified that the file size of
>> the .ko files are small enough for our embedded platform and that
>> unnecessary sections like .debug_info, .debug_line, .debug_str etc.
>> are also absent.
>
> BTW it seems with my latest set of patches, modules still have .debug_*.
> Can you double check if your tree still has the interim patch which added a linker
> script for modules to strip out .debug_*
>
> http://lists.infradead.org/pipermail/linux-snps-arc/2016-September/001483.html

Hi Vineet,

Sorry, that was a misunderstanding. Buildroot routinely runs the strip
command on .ko files before installing them on the target. I was only
looking at the .ko files *after* running the strip command. No, the
interim patch was not in my tree.

I confirmed that your commit "ARC: dw2 unwind: don't force dwarf 2" is
indeed necessary to suppress the .debug_* sections when
CONFIG_DEBUG_INFO is off. But again, we're stripping .ko files anyways
before installing.

> I'm not planning to carry it and would prefer addressing the the root cause by
> removing the -gdwarf-2 toggle. I've added that and pushed rebased series. Care to
> take it for a respin please.

I downloaded your latest commit
e47305af57d7eedc10b4720e604d669b10c69e3b and verified that stack
traces are properly displayed for code inside kernel modules as well
as vmlinux. I also called memcpy() on some bad address and got a
proper stack trace that involved memcpy().

I conclude that unwinding works for us.

Thank You
 Daniel


From Alexey.Brodkin at synopsys.com  Fri Sep 23 03:38:37 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Fri, 23 Sep 2016 10:38:37 +0000
Subject: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder
 switch to .eh_frame)
In-Reply-To: <CAE2F3rBR872+M=mm7Qa5cccrtmOOp5cyZKSWjc4ytOG717jxKQ@mail.gmail.com>
References: <1474321773-18166-1-git-send-email-vgupta@synopsys.com>
 <CAE2F3rA0FrrNiHe6W6DSqYmpTyTiVD3h-wpGtW7rJ07RJLqqgw@mail.gmail.com>
 <caee47ec-eb68-59ee-50dc-ee02c4d78b7d@synopsys.com>
 <CAE2F3rBR872+M=mm7Qa5cccrtmOOp5cyZKSWjc4ytOG717jxKQ@mail.gmail.com>
Message-ID: <1474627107.2562.19.camel@synopsys.com>

Hi Daniel,

On Thu, 2016-09-22 at 15:37 -0700, Daniel Mentz wrote:
> On Thu, Sep 22, 2016 at 1:59 PM, Vineet Gupta
> <Vineet.Gupta1 at synopsys.com> wrote:
> > 
> > Hi Daniel,
> > 
> > On 09/19/2016 06:21 PM, Daniel Mentz wrote:
> > > 
> > > I confirmed that the .eh_frame section is present and that the
> > > .debug_frame section is absent. I also verified that the file size of
> > > the .ko files are small enough for our embedded platform and that
> > > unnecessary sections like .debug_info, .debug_line, .debug_str etc.
> > > are also absent.
> > 
> > BTW it seems with my latest set of patches, modules still have .debug_*.
> > Can you double check if your tree still has the interim patch which added a linker
> > script for modules to strip out .debug_*
> > 
> > http://lists.infradead.org/pipermail/linux-snps-arc/2016-September/001483.html
> 
> Hi Vineet,
> 
> Sorry, that was a misunderstanding. Buildroot routinely runs the strip
> command on .ko files before installing them on the target. I was only
> looking at the .ko files *after* running the strip command. No, the
> interim patch was not in my tree.

Well are you sure buildroot really touches modules in Linux kernel build folder?
Buildroot just runs a simple "make" command in "output/build/linux-x.y".

And only on installation step Buildroot strips binaries in "output/target" folder.
Moreover starting from that commit
https://git.buildroot.net/buildroot/commit/?id=10c4d27aef4dca01572cfc8146cbfd194a1a85e4
even on Linux installation step Buildroot reuses kernel's module stripping infrastructure
but again that happens only on target.

Just in case that's what I see when building MSDOSFS as module.

In build folder:
----------------------------->8-------------------------------
arc-linux-readelf -S build/linux-4.7.3/fs/fat/msdos.ko
There are 38 section headers, starting at offset 0x2a630:

Section Headers:
? [Nr] Name??????????????Type????????????Addr?????Off????Size???ES Flg Lk Inf Al
? [ 0]???????????????????NULL????????????00000000 000000 000000 00??????0???0??0
? [ 1] .note.gnu.build-i NOTE????????????00000000 000034 000024 00???A??0???0??4
? [ 2] .text?????????????PROGBITS????????00000000 000058 0013a8 00??AX??0???0??4
? [ 3] .rela.text????????RELA????????????00000000 01c774 000600 0c???I 35???2??4
? [ 4] .init.text????????PROGBITS????????00000000 001400 000010 00??AX??0???0??4
? [ 5] .rela.init.text???RELA????????????00000000 01cd74 000018 0c???I 35???4??4
? [ 6] .exit.text????????PROGBITS????????00000000 001410 000010 00??AX??0???0??4
? [ 7] .rela.exit.text???RELA????????????00000000 01cd8c 000018 0c???I 35???6??4
? [ 8] .rodata???????????PROGBITS????????00000000 001440 000100 00???A??0???0 64
? [ 9] .rela.rodata??????RELA????????????00000000 01cda4 000078 0c???I 35???8??4
? [10] .modinfo??????????PROGBITS????????00000000 001540 000090 00???A??0???0??4
? [11] .rodata.str1.4????PROGBITS????????00000000 0015d0 000030 01 AMS??0???0??4
? [12] .data?????????????PROGBITS????????00000000 001600 00002c 00??WA??0???0??4
? [13] .rela.data????????RELA????????????00000000 01ce1c 000030 0c???I 35??12??4
? [14] .gnu.linkonce.thi PROGBITS????????00000000 001640 000140 00??WA??0???0 64
? [15] .rela.gnu.linkonc RELA????????????00000000 01ce4c 00000c 0c???I 35??14??4
? [16] .tdata????????????PROGBITS????????00000000 001780 000000 00 WAT??0???0??1
? [17] .tbss?????????????NOBITS??????????00000000 001780 000000 00 WAT??0???0??1
? [18] .bss??????????????NOBITS??????????00000000 001780 000000 00??WA??0???0??1
? [19] .comment??????????PROGBITS????????00000000 001780 000078 01??MS??0???0??1
? [20] .note.GNU-stack???PROGBITS????????00000000 0017f8 000000 00??????0???0??1
? [21] .debug_aranges????PROGBITS????????00000000 0017f8 000048 00??????0???0??1
? [22] .rela.debug_arang RELA????????????00000000 01ce58 00003c 0c???I 35??21??4
? [23] .debug_info???????PROGBITS????????00000000 001840 00eaa9 00??????0???0??1
? [24] .rela.debug_info??RELA????????????00000000 01ce94 00a53c 0c???I 35??23??4
? [25] .debug_abbrev?????PROGBITS????????00000000 0102e9 0008b3 00??????0???0??1
? [26] .debug_line???????PROGBITS????????00000000 010b9c 001d4d 00??????0???0??1
? [27] .rela.debug_line??RELA????????????00000000 0273d0 001818 0c???I 35??26??4
? [28] .debug_frame??????PROGBITS????????00000000 0128ec 0002d8 00??????0???0??4
? [29] .rela.debug_frame RELA????????????00000000 028be8 000168 0c???I 35??28??4
? [30] .debug_str????????PROGBITS????????00000000 012bc4 008485 01??MS??0???0??1
? [31] .debug_loc????????PROGBITS????????00000000 01b049 000b49 00??????0???0??1
? [32] .rela.debug_loc???RELA????????????00000000 028d50 001308 0c???I 35??31??4
? [33] .debug_ranges?????PROGBITS????????00000000 01bb92 0001f8 00??????0???0??1
? [34] .rela.debug_range RELA????????????00000000 02a058 000480 0c???I 35??33??4
? [35] .symtab???????????SYMTAB??????????00000000 01bd8c 0005e0 10?????36??53??4
? [36] .strtab???????????STRTAB??????????00000000 01c36c 000407 00??????0???0??1
? [37] .shstrtab?????????STRTAB??????????00000000 02a4d8 000157 00??????0???0??1
Key to Flags:
? W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
? L (link order), O (extra OS processing required), G (group), T (TLS),
? C (compressed), x (unknown), o (OS specific), E (exclude),
? p (processor specific)
----------------------------->8-------------------------------

On target:
----------------------------->8-------------------------------
arc-linux-readelf -S target/lib/modules/4.7.3/kernel/fs/fat/msdos.ko?
There are 24 section headers, starting at offset 0x28e0:

Section Headers:
? [Nr] Name??????????????Type????????????Addr?????Off????Size???ES Flg Lk Inf Al
? [ 0]???????????????????NULL????????????00000000 000000 000000 00??????0???0??0
? [ 1] .note.gnu.build-i NOTE????????????00000000 000034 000024 00???A??0???0??4
? [ 2] .text?????????????PROGBITS????????00000000 000058 0013a8 00??AX??0???0??4
? [ 3] .rela.text????????RELA????????????00000000 002128 000600 0c???I 21???2??4
? [ 4] .init.text????????PROGBITS????????00000000 001400 000010 00??AX??0???0??4
? [ 5] .rela.init.text???RELA????????????00000000 002728 000018 0c???I 21???4??4
? [ 6] .exit.text????????PROGBITS????????00000000 001410 000010 00??AX??0???0??4
? [ 7] .rela.exit.text???RELA????????????00000000 002740 000018 0c???I 21???6??4
? [ 8] .rodata???????????PROGBITS????????00000000 001440 000100 00???A??0???0 64
? [ 9] .rela.rodata??????RELA????????????00000000 002758 000078 0c???I 21???8??4
? [10] .modinfo??????????PROGBITS????????00000000 001540 000090 00???A??0???0??4
? [11] .rodata.str1.4????PROGBITS????????00000000 0015d0 000030 01 AMS??0???0??4
? [12] .data?????????????PROGBITS????????00000000 001600 00002c 00??WA??0???0??4
? [13] .rela.data????????RELA????????????00000000 0027d0 000030 0c???I 21??12??4
? [14] .gnu.linkonce.thi PROGBITS????????00000000 001640 000140 00??WA??0???0 64
? [15] .rela.gnu.linkonc RELA????????????00000000 002800 00000c 0c???I 21??14??4
? [16] .tdata????????????PROGBITS????????00000000 001780 000000 00 WAT??0???0??1
? [17] .tbss?????????????NOBITS??????????00000000 001780 000000 00 WAT??0???0??1
? [18] .bss??????????????NOBITS??????????00000000 001780 000000 00??WA??0???0??1
? [19] .comment??????????PROGBITS????????00000000 001780 000078 01??MS??0???0??1
? [20] .note.GNU-stack???PROGBITS????????00000000 0017f8 000000 00??????0???0??1
? [21] .symtab???????????SYMTAB??????????00000000 0017f8 000540 10?????22??43??4
? [22] .strtab???????????STRTAB??????????00000000 001d38 0003ed 00??????0???0??1
? [23] .shstrtab?????????STRTAB??????????00000000 00280c 0000d3 00??????0???0??1
Key to Flags:
? W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
? L (link order), O (extra OS processing required), G (group), T (TLS),
? C (compressed), x (unknown), o (OS specific), E (exclude),
? p (processor specific)
----------------------------->8-------------------------------

-Alexey

From danielmentz at google.com  Fri Sep 23 18:04:06 2016
From: danielmentz at google.com (Daniel Mentz)
Date: Fri, 23 Sep 2016 18:04:06 -0700
Subject: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder
 switch to .eh_frame)
In-Reply-To: <1474627107.2562.19.camel@synopsys.com>
References: <1474321773-18166-1-git-send-email-vgupta@synopsys.com>
 <CAE2F3rA0FrrNiHe6W6DSqYmpTyTiVD3h-wpGtW7rJ07RJLqqgw@mail.gmail.com>
 <caee47ec-eb68-59ee-50dc-ee02c4d78b7d@synopsys.com>
 <CAE2F3rBR872+M=mm7Qa5cccrtmOOp5cyZKSWjc4ytOG717jxKQ@mail.gmail.com>
 <1474627107.2562.19.camel@synopsys.com>
Message-ID: <CAE2F3rBjKsEGpbUMhGLthx-Ue=LQCqEPtbB20bG2P=D2nbwYsw@mail.gmail.com>

On Fri, Sep 23, 2016 at 3:38 AM, Alexey Brodkin
<Alexey.Brodkin at synopsys.com> wrote:
> On Thu, 2016-09-22 at 15:37 -0700, Daniel Mentz wrote:
>> Sorry, that was a misunderstanding. Buildroot routinely runs the strip
>> command on .ko files before installing them on the target. I was only
>> looking at the .ko files *after* running the strip command. No, the
>> interim patch was not in my tree.
>
> Well are you sure buildroot really touches modules in Linux kernel build folder?
> Buildroot just runs a simple "make" command in "output/build/linux-x.y".

Sorry, that was phrased badly. Buildroot does not touch the modules in
the Linux kernel build folder. Modules are stripped in the target
directory as you described.

> And only on installation step Buildroot strips binaries in "output/target" folder.
> Moreover starting from that commit
> https://git.buildroot.net/buildroot/commit/?id=10c4d27aef4dca01572cfc8146cbfd194a1a85e4
> even on Linux installation step Buildroot reuses kernel's module stripping infrastructure
> but again that happens only on target.


From Alexey.Brodkin at synopsys.com  Mon Sep 26 05:38:19 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Mon, 26 Sep 2016 12:38:19 +0000
Subject: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder
 switch to .eh_frame)
In-Reply-To: <CAE2F3rBjKsEGpbUMhGLthx-Ue=LQCqEPtbB20bG2P=D2nbwYsw@mail.gmail.com>
References: <1474321773-18166-1-git-send-email-vgupta@synopsys.com>
 <CAE2F3rA0FrrNiHe6W6DSqYmpTyTiVD3h-wpGtW7rJ07RJLqqgw@mail.gmail.com>
 <caee47ec-eb68-59ee-50dc-ee02c4d78b7d@synopsys.com>
 <CAE2F3rBR872+M=mm7Qa5cccrtmOOp5cyZKSWjc4ytOG717jxKQ@mail.gmail.com>
 <1474627107.2562.19.camel@synopsys.com>
 <CAE2F3rBjKsEGpbUMhGLthx-Ue=LQCqEPtbB20bG2P=D2nbwYsw@mail.gmail.com>
Message-ID: <1474893488.4184.14.camel@synopsys.com>

Hi Daniel,

On Fri, 2016-09-23 at 18:04 -0700, Daniel Mentz wrote:
> On Fri, Sep 23, 2016 at 3:38 AM, Alexey Brodkin
> <Alexey.Brodkin at synopsys.com> wrote:
> > 
> > On Thu, 2016-09-22 at 15:37 -0700, Daniel Mentz wrote:
> > > 
> > > Sorry, that was a misunderstanding. Buildroot routinely runs the strip
> > > command on .ko files before installing them on the target. I was only
> > > looking at the .ko files *after* running the strip command. No, the
> > > interim patch was not in my tree.
> > 
> > Well are you sure buildroot really touches modules in Linux kernel build folder?
> > Buildroot just runs a simple "make" command in "output/build/linux-x.y".
> 
> Sorry, that was phrased badly. Buildroot does not touch the modules in
> the Linux kernel build folder. Modules are stripped in the target
> directory as you described.

So every is as expected now for you or there're still thing you don't like?

-Alexey

From danielmentz at google.com  Mon Sep 26 11:51:34 2016
From: danielmentz at google.com (Daniel Mentz)
Date: Mon, 26 Sep 2016 11:51:34 -0700
Subject: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder
 switch to .eh_frame)
In-Reply-To: <1474893488.4184.14.camel@synopsys.com>
References: <1474321773-18166-1-git-send-email-vgupta@synopsys.com>
 <CAE2F3rA0FrrNiHe6W6DSqYmpTyTiVD3h-wpGtW7rJ07RJLqqgw@mail.gmail.com>
 <caee47ec-eb68-59ee-50dc-ee02c4d78b7d@synopsys.com>
 <CAE2F3rBR872+M=mm7Qa5cccrtmOOp5cyZKSWjc4ytOG717jxKQ@mail.gmail.com>
 <1474627107.2562.19.camel@synopsys.com>
 <CAE2F3rBjKsEGpbUMhGLthx-Ue=LQCqEPtbB20bG2P=D2nbwYsw@mail.gmail.com>
 <1474893488.4184.14.camel@synopsys.com>
Message-ID: <CAE2F3rDw9fUut1QgTbxcEDhKXP7QjgdvBvJ4fgdD9MQ4mx4YLA@mail.gmail.com>

On Mon, Sep 26, 2016 at 5:38 AM, Alexey Brodkin
<Alexey.Brodkin at synopsys.com> wrote:
> On Fri, 2016-09-23 at 18:04 -0700, Daniel Mentz wrote:
>> On Fri, Sep 23, 2016 at 3:38 AM, Alexey Brodkin
>> <Alexey.Brodkin at synopsys.com> wrote:
>> >
>> > On Thu, 2016-09-22 at 15:37 -0700, Daniel Mentz wrote:
>> > >
>> > > Sorry, that was a misunderstanding. Buildroot routinely runs the strip
>> > > command on .ko files before installing them on the target. I was only
>> > > looking at the .ko files *after* running the strip command. No, the
>> > > interim patch was not in my tree.
>> >
>> > Well are you sure buildroot really touches modules in Linux kernel build folder?
>> > Buildroot just runs a simple "make" command in "output/build/linux-x.y".
>>
>> Sorry, that was phrased badly. Buildroot does not touch the modules in
>> the Linux kernel build folder. Modules are stripped in the target
>> directory as you described.
>
> So every is as expected now for you or there're still thing you don't like?

Yes, everything works as expected now. Thank you for Synposys' support
with this issue.


From Vineet.Gupta1 at synopsys.com  Mon Sep 26 14:23:04 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Mon, 26 Sep 2016 14:23:04 -0700
Subject: [PATCH] ARC: CONFIG_NODES_SHIFT fix default values
In-Reply-To: <1474455108-13550-1-git-send-email-noamca@mellanox.com>
References: <1474455108-13550-1-git-send-email-noamca@mellanox.com>
Message-ID: <fac3834b-8690-b67e-e003-ad0dd3724aa4@synopsys.com>

On 09/21/2016 03:51 AM, Noam Camus wrote:
> From: Noam Camus <noamca at mellanox.com>
> 
> Seem like values assigned as absolute number and not and
> shift value, i.e. should be 0 for one node (2^0) and 1 for
> couple of nodes (2^1)
> 
> Signed-off-by: Noam Camus <noamca at mellanox.com>

Good catch ! Added to for-next.

Thx,
-Vineet


From Vineet.Gupta1 at synopsys.com  Tue Sep 27 07:53:56 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Tue, 27 Sep 2016 07:53:56 -0700
Subject: [PATCH] perf: remove orphan DEBUG_PERF_USE_VMALLOC
Message-ID: <1474988036-22260-1-git-send-email-vgupta@synopsys.com>

This doesn't seem to be used anywhere

Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Kees Cook <keescook at chromium.org>
Cc: Johannes Weiner <hannes at cmpxchg.org>
Cc: Tejun Heo <tj at kernel.org>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Petr Mladek <pmladek at suse.com>
Cc: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Cc: Thomas Garnier <thgarnie at google.com>
Cc: Nicolas Pitre <nicolas.pitre at linaro.org>
Cc: Peter Zijlstra <peterz at infradead.org>
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
---
 init/Kconfig | 13 -------------
 1 file changed, 13 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index cac3f096050d..934a61f6e2cc 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1707,19 +1707,6 @@ config PERF_EVENTS
 
 	  Say Y if unsure.
 
-config DEBUG_PERF_USE_VMALLOC
-	default n
-	bool "Debug: use vmalloc to back perf mmap() buffers"
-	depends on PERF_EVENTS && DEBUG_KERNEL && !PPC
-	select PERF_USE_VMALLOC
-	help
-	 Use vmalloc memory to back perf mmap() buffers.
-
-	 Mostly useful for debugging the vmalloc code on platforms
-	 that don't require it.
-
-	 Say N if unsure.
-
 endmenu
 
 config VM_EVENT_COUNTERS
-- 
2.7.4



From kim.phillips at arm.com  Tue Sep 27 09:37:27 2016
From: kim.phillips at arm.com (Kim Phillips)
Date: Tue, 27 Sep 2016 11:37:27 -0500
Subject: [PATCH] perf: remove orphan DEBUG_PERF_USE_VMALLOC
In-Reply-To: <1474988036-22260-1-git-send-email-vgupta@synopsys.com>
References: <1474988036-22260-1-git-send-email-vgupta@synopsys.com>
Message-ID: <20160927113727.55dc9dcf23880a63105da670@arm.com>

On Tue, 27 Sep 2016 07:53:56 -0700
Vineet Gupta <Vineet.Gupta1 at synopsys.com> wrote:

> This doesn't seem to be used anywhere

I thought so too, until I got this response for an equivalent patch:

https://lkml.org/lkml/2016/8/31/53

Kim


From Vineet.Gupta1 at synopsys.com  Tue Sep 27 09:51:35 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Tue, 27 Sep 2016 09:51:35 -0700
Subject: [PATCH] perf: remove orphan DEBUG_PERF_USE_VMALLOC
In-Reply-To: <20160927113727.55dc9dcf23880a63105da670@arm.com>
References: <1474988036-22260-1-git-send-email-vgupta@synopsys.com>
 <20160927113727.55dc9dcf23880a63105da670@arm.com>
Message-ID: <d82fe247-2b8c-896d-e6ce-fb82e78f360e@synopsys.com>

On 09/27/2016 09:37 AM, Kim Phillips wrote:
> On Tue, 27 Sep 2016 07:53:56 -0700
> Vineet Gupta <Vineet.Gupta1 at synopsys.com> wrote:
> 
>> > This doesn't seem to be used anywhere
> I thought so too, until I got this response for an equivalent patch:
> 
> https://lkml.org/lkml/2016/8/31/53

So this is some sort of "developer shortcut" to quickly enable 2 options with one
option. Purpose seems dubious to me ! It would still be possible to enable vmalloc
backed mmap on x86 by simply enabling that option from Kconfig.

-Vineet


From Vineet.Gupta1 at synopsys.com  Tue Sep 27 17:22:13 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Tue, 27 Sep 2016 17:22:13 -0700
Subject: NMI for ARC
In-Reply-To: <20151117131538.GZ3816@twins.programming.kicks-ass.net>
References: <1445286926.3913.13.camel@synopsys.com>
 <C2D7FE5348E1B147BCA15975FBA23075F44D210D@IN01WEMBXA.internal.synopsys.com>
 <20151117110749.GT3816@twins.programming.kicks-ass.net>
 <564B0E18.3040207@synopsys.com>
 <20151117122401.GY3816@twins.programming.kicks-ass.net>
 <20151117122540.GL11639@twins.programming.kicks-ass.net>
 <564B2341.4030409@synopsys.com>
 <20151117131538.GZ3816@twins.programming.kicks-ass.net>
Message-ID: <3b23d64c-2579-b72e-645a-e7ece3c1a3c6@synopsys.com>

Hi Peter,

On 11/17/2015 05:15 AM, Peter Zijlstra wrote:
> On Tue, Nov 17, 2015 at 06:23:21PM +0530, Vineet Gupta wrote:
>> On Tuesday 17 November 2015 05:55 PM, Peter Zijlstra wrote:
>>
>>> This is assuming you now have these NMIs we talked about earlier. If all
>>> you have are regular IRQs this is not possible, for we should be calling
>>> ->read() with IRQs disabled.
>>>
>>
>> No we don't yet. The first stab at it fell flat on floor.
>>
>> The NMI support from hardware is that is it provides different priorities, higher
>> one obviously able to interrupt lower one. However instructions like CLRI (disable
>> interrupts) will still lock out all interrupts.
>>
>> Thus local_irq_save()/restore() and local_irq_enable()/disable() now need to be
>> contextual.
>>
>>   - When running in prio 0 mode, they only need to enable 0
>>   - In prio 1, they need to enable both 0 and 1
>>
>> For irq_save()/restore() this is achievable by doing an additional STATUS32 read
>> at the time of save and passing that value to restore - so there's an additional
>> overhead - but ignoring that for now.
>>
>> Bummer is irq_disable()/enable() case: there's need to pass old prio state from
>> enable to disabled, so we need some sort of global state tracking - which in case
>> of SMP needs to be per cpu.... either keep something hot in a reg or pay the cost
>> of additional mem/cache line miss.
>>
>> I've not investigated how other arches do that. PPC seems to be using some sort of
>> soft irq state anyways.
> 
> Yeah, Sparc64 might be a better example, it more closely matches your
> hardware. See
> arch/sparc/include/asm/irqflags_64.h:arch_local_irq_save().

So I finally got around to doing this and as expected has turned out to be quite
some fun. I have a couple of questions and would really appreciate your inputs there.

1. Is it OK in general to short-circuit preemption off irq checks for NMI style
interrupts. The issue is we can get nested interrupts (timer followed by perf)
and one of them can cause resched_curr() to a user task - but we can't return to
user mode from inner interrupt. So it becomes easy if we don't even bother
checking for TIF_NEED_RESCHED in perf intr path. This also has slight advantage
that perf intr returns quickly. Implementation wise this requires a hack to bump
preemption count in the low level nmi handler - and revert that in nmi return path.

2. The low level return code, resume_user_mode_begin and/or resume_kernel_mode
require interrupt safety, does that need to be NMI safe as well. We ofcourse want
the very late register restore parts to be non-interruptible, but is this required
before we call prrempt_schedule_irq() off of asm code.

Thx,
-Vineet


From peterz at infradead.org  Tue Sep 27 23:56:02 2016
From: peterz at infradead.org (Peter Zijlstra)
Date: Wed, 28 Sep 2016 08:56:02 +0200
Subject: [PATCH] perf: remove orphan DEBUG_PERF_USE_VMALLOC
In-Reply-To: <d82fe247-2b8c-896d-e6ce-fb82e78f360e@synopsys.com>
References: <1474988036-22260-1-git-send-email-vgupta@synopsys.com>
 <20160927113727.55dc9dcf23880a63105da670@arm.com>
 <d82fe247-2b8c-896d-e6ce-fb82e78f360e@synopsys.com>
Message-ID: <20160928065602.GS2794@worktop>

On Tue, Sep 27, 2016 at 09:51:35AM -0700, Vineet Gupta wrote:
> On 09/27/2016 09:37 AM, Kim Phillips wrote:
> > On Tue, 27 Sep 2016 07:53:56 -0700
> > Vineet Gupta <Vineet.Gupta1 at synopsys.com> wrote:
> > 
> >> > This doesn't seem to be used anywhere
> > I thought so too, until I got this response for an equivalent patch:
> > 
> > https://lkml.org/lkml/2016/8/31/53
> 
> So this is some sort of "developer shortcut" to quickly enable 2 options with one
> option. Purpose seems dubious to me ! It would still be possible to enable vmalloc
> backed mmap on x86 by simply enabling that option from Kconfig.

PERF_USE_VMALLOC is not a user selectable option. Also
DEBUG_PERF_USE_VMALLOC clearly indicates its a _DEBUG_ option. Heck,
even the help text says what its for.


From peterz at infradead.org  Wed Sep 28 00:16:42 2016
From: peterz at infradead.org (Peter Zijlstra)
Date: Wed, 28 Sep 2016 09:16:42 +0200
Subject: NMI for ARC
In-Reply-To: <3b23d64c-2579-b72e-645a-e7ece3c1a3c6@synopsys.com>
References: <1445286926.3913.13.camel@synopsys.com>
 <C2D7FE5348E1B147BCA15975FBA23075F44D210D@IN01WEMBXA.internal.synopsys.com>
 <20151117110749.GT3816@twins.programming.kicks-ass.net>
 <564B0E18.3040207@synopsys.com>
 <20151117122401.GY3816@twins.programming.kicks-ass.net>
 <20151117122540.GL11639@twins.programming.kicks-ass.net>
 <564B2341.4030409@synopsys.com>
 <20151117131538.GZ3816@twins.programming.kicks-ass.net>
 <3b23d64c-2579-b72e-645a-e7ece3c1a3c6@synopsys.com>
Message-ID: <20160928071642.GU2794@worktop>

On Tue, Sep 27, 2016 at 05:22:13PM -0700, Vineet Gupta wrote:

> > Yeah, Sparc64 might be a better example, it more closely matches your
> > hardware. See
> > arch/sparc/include/asm/irqflags_64.h:arch_local_irq_save().
> 
> So I finally got around to doing this and as expected has turned out to be quite
> some fun. I have a couple of questions and would really appreciate your inputs there.
> 
> 1. Is it OK in general to short-circuit preemption off irq checks for NMI style
> interrupts. 

Yes. If the NMI returns to kernel space you must not attempt preemption
for reasons you found :-), if the NMI returns to userspace you should do
the normal return to user bits, I think.

> 2. The low level return code, resume_user_mode_begin and/or resume_kernel_mode
> require interrupt safety, does that need to be NMI safe as well. We ofcourse want
> the very late register restore parts to be non-interruptible, but is this required
> before we call prrempt_schedule_irq() off of asm code.

Urgh, I'm never quite sure on the details here, I've Cc'ed Andy who
might actually know this off the top of his head. I'll try and dig
through x86 to see what it does.


From Vineet.Gupta1 at synopsys.com  Wed Sep 28 10:58:06 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Wed, 28 Sep 2016 10:58:06 -0700
Subject: NMI for ARC
In-Reply-To: <20160928071642.GU2794@worktop>
References: <1445286926.3913.13.camel@synopsys.com>
 <C2D7FE5348E1B147BCA15975FBA23075F44D210D@IN01WEMBXA.internal.synopsys.com>
 <20151117110749.GT3816@twins.programming.kicks-ass.net>
 <564B0E18.3040207@synopsys.com>
 <20151117122401.GY3816@twins.programming.kicks-ass.net>
 <20151117122540.GL11639@twins.programming.kicks-ass.net>
 <564B2341.4030409@synopsys.com>
 <20151117131538.GZ3816@twins.programming.kicks-ass.net>
 <3b23d64c-2579-b72e-645a-e7ece3c1a3c6@synopsys.com>
 <20160928071642.GU2794@worktop>
Message-ID: <3b5cbc7c-ed5c-af95-8dc9-25fd92277e98@synopsys.com>

On 09/28/2016 12:16 AM, Peter Zijlstra wrote:
>> 1. Is it OK in general to short-circuit preemption off irq checks for NMI style
>> > interrupts. 
> Yes. If the NMI returns to kernel space you must not attempt preemption
> for reasons you found :-), if the NMI returns to userspace you should do
> the normal return to user bits, I think.

Just to add, eliding preemption check in return path might not be sufficient as we
could still have timer intr leading to scheduler_tick() - whcih is what i found as
well ;-) So scheduler nevertheless needs to be told to not reschedule in this code
path.

So eliding preempt-off-irq just becomes an optimization for NMI code paths IMHO.

Now I was a stupid fool, fudging preemption counts in low level code, to achieve
this, whereas we have nice generic nmi_{enter,exit}() and in_nmi() helpers which
can be used.

Thx,
-Vineet


From luto at amacapital.net  Wed Sep 28 12:25:11 2016
From: luto at amacapital.net (Andy Lutomirski)
Date: Wed, 28 Sep 2016 12:25:11 -0700
Subject: NMI for ARC
In-Reply-To: <20160928071642.GU2794@worktop>
References: <1445286926.3913.13.camel@synopsys.com>
 <C2D7FE5348E1B147BCA15975FBA23075F44D210D@IN01WEMBXA.internal.synopsys.com>
 <20151117110749.GT3816@twins.programming.kicks-ass.net>
 <564B0E18.3040207@synopsys.com>
 <20151117122401.GY3816@twins.programming.kicks-ass.net>
 <20151117122540.GL11639@twins.programming.kicks-ass.net>
 <564B2341.4030409@synopsys.com>
 <20151117131538.GZ3816@twins.programming.kicks-ass.net>
 <3b23d64c-2579-b72e-645a-e7ece3c1a3c6@synopsys.com>
 <20160928071642.GU2794@worktop>
Message-ID: <CALCETrXJCGMW7DcAVw5mkfiOce4u+3OM3_QLkE117ewU_Hzpsg@mail.gmail.com>

On Wed, Sep 28, 2016 at 12:16 AM, Peter Zijlstra <peterz at infradead.org> wrote:
> On Tue, Sep 27, 2016 at 05:22:13PM -0700, Vineet Gupta wrote:
>
>> > Yeah, Sparc64 might be a better example, it more closely matches your
>> > hardware. See
>> > arch/sparc/include/asm/irqflags_64.h:arch_local_irq_save().
>>
>> So I finally got around to doing this and as expected has turned out to be quite
>> some fun. I have a couple of questions and would really appreciate your inputs there.
>>
>> 1. Is it OK in general to short-circuit preemption off irq checks for NMI style
>> interrupts.
>
> Yes. If the NMI returns to kernel space you must not attempt preemption
> for reasons you found :-),

Last time I looked at this, I decided that there was no reason that
NMIs would ever need to handle preemption.  Even if the NMI hit
interruptible kernel code, anything that would cause preemption to be
needed would either send an IPI (and thus cause preemption) right
after the NMI fiinished.  NMI handlers themselves have no business
setting TIF_NEED_RESCHED or similar.

> if the NMI returns to userspace you should do
> the normal return to user bits, I think.

x86 does this for simplicity.  There was a really nasty corner case
that I could only figure out how to solve by special casing NMIs from
user space.  I'm not sure that it's actually necessary from a
non-arch-specific POV to handle all the usual return-to-userspace work
on NMI.  But maybe perf NMIs can send signals?

x86's MCEs *do* need the full return-to-userspace handling for memory
failure to work right.  MCE is kind of like NMI...

>
>> 2. The low level return code, resume_user_mode_begin and/or resume_kernel_mode
>> require interrupt safety, does that need to be NMI safe as well. We ofcourse want
>> the very late register restore parts to be non-interruptible, but is this required
>> before we call prrempt_schedule_irq() off of asm code.
>
> Urgh, I'm never quite sure on the details here, I've Cc'ed Andy who
> might actually know this off the top of his head. I'll try and dig
> through x86 to see what it does.

On x86, it's quite simple.  IRQs are *always* off during the final
register restore, and we don't re-check for preemption there.  x86
handles preemption after turning off IRQs, and IRQs are guaranteed to
stay off until we actually return to userspace.

The code is almost entirely in C in arch/x86/entry/common.c.  There
isn't anything particularly x86-speficic in there.


From peterz at infradead.org  Wed Sep 28 13:37:48 2016
From: peterz at infradead.org (Peter Zijlstra)
Date: Wed, 28 Sep 2016 22:37:48 +0200
Subject: NMI for ARC
In-Reply-To: <CALCETrXJCGMW7DcAVw5mkfiOce4u+3OM3_QLkE117ewU_Hzpsg@mail.gmail.com>
References: <C2D7FE5348E1B147BCA15975FBA23075F44D210D@IN01WEMBXA.internal.synopsys.com>
 <20151117110749.GT3816@twins.programming.kicks-ass.net>
 <564B0E18.3040207@synopsys.com>
 <20151117122401.GY3816@twins.programming.kicks-ass.net>
 <20151117122540.GL11639@twins.programming.kicks-ass.net>
 <564B2341.4030409@synopsys.com>
 <20151117131538.GZ3816@twins.programming.kicks-ass.net>
 <3b23d64c-2579-b72e-645a-e7ece3c1a3c6@synopsys.com>
 <20160928071642.GU2794@worktop>
 <CALCETrXJCGMW7DcAVw5mkfiOce4u+3OM3_QLkE117ewU_Hzpsg@mail.gmail.com>
Message-ID: <20160928203748.GU5012@twins.programming.kicks-ass.net>

On Wed, Sep 28, 2016 at 12:25:11PM -0700, Andy Lutomirski wrote:
> > Yes. If the NMI returns to kernel space you must not attempt preemption
> > for reasons you found :-),
> 
> Last time I looked at this, I decided that there was no reason that
> NMIs would ever need to handle preemption.  Even if the NMI hit
> interruptible kernel code, anything that would cause preemption to be
> needed would either send an IPI (and thus cause preemption) right
> after the NMI fiinished.  NMI handlers themselves have no business
> setting TIF_NEED_RESCHED or similar.

Good point, they don't and therefore you need not bother.

> > if the NMI returns to userspace you should do
> > the normal return to user bits, I think.
> 
> x86 does this for simplicity.  There was a really nasty corner case
> that I could only figure out how to solve by special casing NMIs from
> user space.  I'm not sure that it's actually necessary from a
> non-arch-specific POV to handle all the usual return-to-userspace work
> on NMI.  But maybe perf NMIs can send signals?

No it cannot. It uses irq_work (which sends a self-IPI) when it wants to
do signals.

> >> 2. The low level return code, resume_user_mode_begin and/or resume_kernel_mode
> >> require interrupt safety, does that need to be NMI safe as well. We ofcourse want
> >> the very late register restore parts to be non-interruptible, but is this required
> >> before we call prrempt_schedule_irq() off of asm code.
> >
> > Urgh, I'm never quite sure on the details here, I've Cc'ed Andy who
> > might actually know this off the top of his head. I'll try and dig
> > through x86 to see what it does.
> 
> On x86, it's quite simple.  IRQs are *always* off during the final
> register restore, and we don't re-check for preemption there.  x86
> handles preemption after turning off IRQs, and IRQs are guaranteed to
> stay off until we actually return to userspace.
> 
> The code is almost entirely in C in arch/x86/entry/common.c.  There
> isn't anything particularly x86-speficic in there.

Right, so what I think Vineet is asking is if we need to disable NMIs as
well, we cannot on x86 disable NMIs so no.



From luto at amacapital.net  Wed Sep 28 15:26:10 2016
From: luto at amacapital.net (Andy Lutomirski)
Date: Wed, 28 Sep 2016 15:26:10 -0700
Subject: NMI for ARC
In-Reply-To: <20160928203748.GU5012@twins.programming.kicks-ass.net>
References: <C2D7FE5348E1B147BCA15975FBA23075F44D210D@IN01WEMBXA.internal.synopsys.com>
 <20151117110749.GT3816@twins.programming.kicks-ass.net>
 <564B0E18.3040207@synopsys.com>
 <20151117122401.GY3816@twins.programming.kicks-ass.net>
 <20151117122540.GL11639@twins.programming.kicks-ass.net>
 <564B2341.4030409@synopsys.com>
 <20151117131538.GZ3816@twins.programming.kicks-ass.net>
 <3b23d64c-2579-b72e-645a-e7ece3c1a3c6@synopsys.com>
 <20160928071642.GU2794@worktop>
 <CALCETrXJCGMW7DcAVw5mkfiOce4u+3OM3_QLkE117ewU_Hzpsg@mail.gmail.com>
 <20160928203748.GU5012@twins.programming.kicks-ass.net>
Message-ID: <CALCETrVz48j=fmWtXN9wtSbAP6LNcb-=Uf6biq-9EmMQ=zM8zA@mail.gmail.com>

On Sep 28, 2016 1:37 PM, "Peter Zijlstra" <peterz at infradead.org> wrote:
>
> On Wed, Sep 28, 2016 at 12:25:11PM -0700, Andy Lutomirski wrote:
> > > Yes. If the NMI returns to kernel space you must not attempt preemption
> > > for reasons you found :-),
> >
> > Last time I looked at this, I decided that there was no reason that
> > NMIs would ever need to handle preemption.  Even if the NMI hit
> > interruptible kernel code, anything that would cause preemption to be
> > needed would either send an IPI (and thus cause preemption) right
> > after the NMI fiinished.  NMI handlers themselves have no business
> > setting TIF_NEED_RESCHED or similar.
>
> Good point, they don't and therefore you need not bother.
>
> > > if the NMI returns to userspace you should do
> > > the normal return to user bits, I think.
> >
> > x86 does this for simplicity.  There was a really nasty corner case
> > that I could only figure out how to solve by special casing NMIs from
> > user space.  I'm not sure that it's actually necessary from a
> > non-arch-specific POV to handle all the usual return-to-userspace work
> > on NMI.  But maybe perf NMIs can send signals?
>
> No it cannot. It uses irq_work (which sends a self-IPI) when it wants to
> do signals.
>
> > >> 2. The low level return code, resume_user_mode_begin and/or resume_kernel_mode
> > >> require interrupt safety, does that need to be NMI safe as well. We ofcourse want
> > >> the very late register restore parts to be non-interruptible, but is this required
> > >> before we call prrempt_schedule_irq() off of asm code.
> > >
> > > Urgh, I'm never quite sure on the details here, I've Cc'ed Andy who
> > > might actually know this off the top of his head. I'll try and dig
> > > through x86 to see what it does.
> >
> > On x86, it's quite simple.  IRQs are *always* off during the final
> > register restore, and we don't re-check for preemption there.  x86
> > handles preemption after turning off IRQs, and IRQs are guaranteed to
> > stay off until we actually return to userspace.
> >
> > The code is almost entirely in C in arch/x86/entry/common.c.  There
> > isn't anything particularly x86-speficic in there.
>
> Right, so what I think Vineet is asking is if we need to disable NMIs as
> well, we cannot on x86 disable NMIs so no.
>

The same argument works here, too: an NMI won't set TIF_NEED_RESCHED
without sending an IPI, so we can't miss a wakeup.


From Vineet.Gupta1 at synopsys.com  Wed Sep 28 15:44:17 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Wed, 28 Sep 2016 15:44:17 -0700
Subject: NMI for ARC
In-Reply-To: <CALCETrVz48j=fmWtXN9wtSbAP6LNcb-=Uf6biq-9EmMQ=zM8zA@mail.gmail.com>
References: <C2D7FE5348E1B147BCA15975FBA23075F44D210D@IN01WEMBXA.internal.synopsys.com>
 <20151117110749.GT3816@twins.programming.kicks-ass.net>
 <564B0E18.3040207@synopsys.com>
 <20151117122401.GY3816@twins.programming.kicks-ass.net>
 <20151117122540.GL11639@twins.programming.kicks-ass.net>
 <564B2341.4030409@synopsys.com>
 <20151117131538.GZ3816@twins.programming.kicks-ass.net>
 <3b23d64c-2579-b72e-645a-e7ece3c1a3c6@synopsys.com>
 <20160928071642.GU2794@worktop>
 <CALCETrXJCGMW7DcAVw5mkfiOce4u+3OM3_QLkE117ewU_Hzpsg@mail.gmail.com>
 <20160928203748.GU5012@twins.programming.kicks-ass.net>
 <CALCETrVz48j=fmWtXN9wtSbAP6LNcb-=Uf6biq-9EmMQ=zM8zA@mail.gmail.com>
Message-ID: <671e1614-8847-8a5f-676d-b312e4abd097@synopsys.com>

On 09/28/2016 03:26 PM, Andy Lutomirski wrote:
>>>>> 2. The low level return code, resume_user_mode_begin and/or resume_kernel_mode
>>>>> > > >> require interrupt safety, does that need to be NMI safe as well. We ofcourse want
>>>>> > > >> the very late register restore parts to be non-interruptible, but is this required
>>>>> > > >> before we call prrempt_schedule_irq() off of asm code.
>>>> > > >
>>>> > > > Urgh, I'm never quite sure on the details here, I've Cc'ed Andy who
>>>> > > > might actually know this off the top of his head. I'll try and dig
>>>> > > > through x86 to see what it does.
>>> > >
>>> > > On x86, it's quite simple.  IRQs are *always* off during the final
>>> > > register restore, and we don't re-check for preemption there.  x86
>>> > > handles preemption after turning off IRQs, and IRQs are guaranteed to
>>> > > stay off until we actually return to userspace.
>>> > >
>>> > > The code is almost entirely in C in arch/x86/entry/common.c.  There
>>> > > isn't anything particularly x86-speficic in there.
>> >
>> > Right, so what I think Vineet is asking is if we need to disable NMIs as
>> > well, we cannot on x86 disable NMIs so no.
>> >
> The same argument works here, too: an NMI won't set TIF_NEED_RESCHED
> without sending an IPI, so we can't miss a wakeup.

The case I saw was different: timer intr (normal prio) comes in - scheduler_tick()
sets TIF_NEED_RESCHED and before this intr return, it gets interrupted by perf
intr (higher prio) and we decide not to follow through on preemption because a
nested intr can't return to userspace anyways.




From luto at amacapital.net  Wed Sep 28 15:47:55 2016
From: luto at amacapital.net (Andy Lutomirski)
Date: Wed, 28 Sep 2016 15:47:55 -0700
Subject: NMI for ARC
In-Reply-To: <671e1614-8847-8a5f-676d-b312e4abd097@synopsys.com>
References: <C2D7FE5348E1B147BCA15975FBA23075F44D210D@IN01WEMBXA.internal.synopsys.com>
 <20151117110749.GT3816@twins.programming.kicks-ass.net>
 <564B0E18.3040207@synopsys.com>
 <20151117122401.GY3816@twins.programming.kicks-ass.net>
 <20151117122540.GL11639@twins.programming.kicks-ass.net>
 <564B2341.4030409@synopsys.com>
 <20151117131538.GZ3816@twins.programming.kicks-ass.net>
 <3b23d64c-2579-b72e-645a-e7ece3c1a3c6@synopsys.com>
 <20160928071642.GU2794@worktop>
 <CALCETrXJCGMW7DcAVw5mkfiOce4u+3OM3_QLkE117ewU_Hzpsg@mail.gmail.com>
 <20160928203748.GU5012@twins.programming.kicks-ass.net>
 <CALCETrVz48j=fmWtXN9wtSbAP6LNcb-=Uf6biq-9EmMQ=zM8zA@mail.gmail.com>
 <671e1614-8847-8a5f-676d-b312e4abd097@synopsys.com>
Message-ID: <CALCETrV1ZacNJy0TvPzV2Qucgt3oVp6Z+z_CJ9vjhOhMFQCP+Q@mail.gmail.com>

On Wed, Sep 28, 2016 at 3:44 PM, Vineet Gupta
<Vineet.Gupta1 at synopsys.com> wrote:
> On 09/28/2016 03:26 PM, Andy Lutomirski wrote:
>>>>>> 2. The low level return code, resume_user_mode_begin and/or resume_kernel_mode
>>>>>> > > >> require interrupt safety, does that need to be NMI safe as well. We ofcourse want
>>>>>> > > >> the very late register restore parts to be non-interruptible, but is this required
>>>>>> > > >> before we call prrempt_schedule_irq() off of asm code.
>>>>> > > >
>>>>> > > > Urgh, I'm never quite sure on the details here, I've Cc'ed Andy who
>>>>> > > > might actually know this off the top of his head. I'll try and dig
>>>>> > > > through x86 to see what it does.
>>>> > >
>>>> > > On x86, it's quite simple.  IRQs are *always* off during the final
>>>> > > register restore, and we don't re-check for preemption there.  x86
>>>> > > handles preemption after turning off IRQs, and IRQs are guaranteed to
>>>> > > stay off until we actually return to userspace.
>>>> > >
>>>> > > The code is almost entirely in C in arch/x86/entry/common.c.  There
>>>> > > isn't anything particularly x86-speficic in there.
>>> >
>>> > Right, so what I think Vineet is asking is if we need to disable NMIs as
>>> > well, we cannot on x86 disable NMIs so no.
>>> >
>> The same argument works here, too: an NMI won't set TIF_NEED_RESCHED
>> without sending an IPI, so we can't miss a wakeup.
>
> The case I saw was different: timer intr (normal prio) comes in - scheduler_tick()
> sets TIF_NEED_RESCHED and before this intr return, it gets interrupted by perf
> intr (higher prio) and we decide not to follow through on preemption because a
> nested intr can't return to userspace anyways.
>
>

This shouldn't cause a problem.  When the timer interrupt returns, it
should be able to handle preemption.


From vgupta at synopsys.com  Wed Sep 28 18:20:29 2016
From: vgupta at synopsys.com (Vineet Gupta)
Date: Wed, 28 Sep 2016 18:20:29 -0700
Subject: NMI for ARC
In-Reply-To: <CALCETrVz48j=fmWtXN9wtSbAP6LNcb-=Uf6biq-9EmMQ=zM8zA@mail.gmail.com>
References: <C2D7FE5348E1B147BCA15975FBA23075F44D210D@IN01WEMBXA.internal.synopsys.com>
 <20151117110749.GT3816@twins.programming.kicks-ass.net>
 <564B0E18.3040207@synopsys.com>
 <20151117122401.GY3816@twins.programming.kicks-ass.net>
 <20151117122540.GL11639@twins.programming.kicks-ass.net>
 <564B2341.4030409@synopsys.com>
 <20151117131538.GZ3816@twins.programming.kicks-ass.net>
 <3b23d64c-2579-b72e-645a-e7ece3c1a3c6@synopsys.com>
 <20160928071642.GU2794@worktop>
 <CALCETrXJCGMW7DcAVw5mkfiOce4u+3OM3_QLkE117ewU_Hzpsg@mail.gmail.com>
 <20160928203748.GU5012@twins.programming.kicks-ass.net>
 <CALCETrVz48j=fmWtXN9wtSbAP6LNcb-=Uf6biq-9EmMQ=zM8zA@mail.gmail.com>
Message-ID: <75783d4b-98bf-5d60-a844-20d4eec88ac9@synopsys.com>

On 09/28/2016 03:26 PM, Andy Lutomirski wrote:
>> Right, so what I think Vineet is asking is if we need to disable NMIs as
>> > well, we cannot on x86 disable NMIs so no.
>> >
> The same argument works here, too: an NMI won't set TIF_NEED_RESCHED
> without sending an IPI, so we can't miss a wakeup.

But what exact wakeup miss are we taking about here. If intr were NOT disabled,
how could this happen. Just trying to understand the need for "irqs-disabled" in
resume_{user,kernel}_*

The intr disabled before reg file restore makes complete sense though.



From peterz at infradead.org  Wed Sep 28 23:43:41 2016
From: peterz at infradead.org (Peter Zijlstra)
Date: Thu, 29 Sep 2016 08:43:41 +0200
Subject: NMI for ARC
In-Reply-To: <75783d4b-98bf-5d60-a844-20d4eec88ac9@synopsys.com>
References: <20151117122401.GY3816@twins.programming.kicks-ass.net>
 <20151117122540.GL11639@twins.programming.kicks-ass.net>
 <564B2341.4030409@synopsys.com>
 <20151117131538.GZ3816@twins.programming.kicks-ass.net>
 <3b23d64c-2579-b72e-645a-e7ece3c1a3c6@synopsys.com>
 <20160928071642.GU2794@worktop>
 <CALCETrXJCGMW7DcAVw5mkfiOce4u+3OM3_QLkE117ewU_Hzpsg@mail.gmail.com>
 <20160928203748.GU5012@twins.programming.kicks-ass.net>
 <CALCETrVz48j=fmWtXN9wtSbAP6LNcb-=Uf6biq-9EmMQ=zM8zA@mail.gmail.com>
 <75783d4b-98bf-5d60-a844-20d4eec88ac9@synopsys.com>
Message-ID: <20160929064341.GH3318@worktop.controleur.wifipass.org>

On Wed, Sep 28, 2016 at 06:20:29PM -0700, Vineet Gupta wrote:
> On 09/28/2016 03:26 PM, Andy Lutomirski wrote:
> >> Right, so what I think Vineet is asking is if we need to disable NMIs as
> >> > well, we cannot on x86 disable NMIs so no.
> >> >
> > The same argument works here, too: an NMI won't set TIF_NEED_RESCHED
> > without sending an IPI, so we can't miss a wakeup.
> 
> But what exact wakeup miss are we taking about here. If intr were NOT disabled,
> how could this happen. Just trying to understand the need for "irqs-disabled" in
> resume_{user,kernel}_*
> 
> The intr disabled before reg file restore makes complete sense though.


	user	irq	nmi

	|
	|
	`-----> .
		|
		|
		|
		`----->	.
			|
			|
		. <-----'
	. <-----'
	|
	|

So what Andy is saying is that NMI context never sets TIF_NEED_RESCHED,
this means that return from NMI never needs to check for preemption
etc..

Now your return from IRQ obviously should, the normal way. If the IRQ
return gets interrupted by the NMI nothing special should occur. The
return from NMI should simply resume the return from IRQ.

So I'm a little confused by your timer interrupt example, it _should_ do
the preemption, the nested interrupt (NMI) will return to the regular
interrupt which should resume its normal return preemption or not.




From jslaby at suse.cz  Thu Sep 29 02:06:35 2016
From: jslaby at suse.cz (Jiri Slaby)
Date: Thu, 29 Sep 2016 11:06:35 +0200
Subject: [patch added to 3.12-stable] ARC: uaccess: get_user to zero out dest
 in cause of fault
In-Reply-To: <20160929090654.27405-1-jslaby@suse.cz>
References: <20160929090654.27405-1-jslaby@suse.cz>
Message-ID: <20160929090654.27405-24-jslaby@suse.cz>

From: Vineet Gupta <Vineet.Gupta1 at synopsys.com>

This patch has been added to the 3.12 stable tree. If you have any
objections, please let us know.

===============

commit 05d9d0b96e53c52a113fd783c0c97c830c8dc7af upstream.

Al reported potential issue with ARC get_user() as it wasn't clearing
out destination pointer in case of fault due to bad address etc.

Verified using following

| {
|  	u32 bogus1 = 0xdeadbeef;
|	u64 bogus2 = 0xdead;
|	int rc1, rc2;
|
|  	pr_info("Orig values %x %llx\n", bogus1, bogus2);
|	rc1 = get_user(bogus1, (u32 __user *)0x40000000);
|	rc2 = get_user(bogus2, (u64 __user *)0x50000000);
|	pr_info("access %d %d, new values %x %llx\n",
|		rc1, rc2, bogus1, bogus2);
| }

| [ARCLinux]# insmod /mnt/kernel-module/qtn.ko
| Orig values deadbeef dead
| access -14 -14, new values 0 0

Reported-by: Al Viro <viro at ZenIV.linux.org.uk>
Cc: Linus Torvalds <torvalds at linux-foundation.org>
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
Signed-off-by: Al Viro <viro at zeniv.linux.org.uk>
Signed-off-by: Jiri Slaby <jslaby at suse.cz>
---
 arch/arc/include/asm/uaccess.h | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arc/include/asm/uaccess.h b/arch/arc/include/asm/uaccess.h
index 30c9baffa96f..08770c750696 100644
--- a/arch/arc/include/asm/uaccess.h
+++ b/arch/arc/include/asm/uaccess.h
@@ -83,7 +83,10 @@
 	"2:	;nop\n"				\
 	"	.section .fixup, \"ax\"\n"	\
 	"	.align 4\n"			\
-	"3:	mov %0, %3\n"			\
+	"3:	# return -EFAULT\n"		\
+	"	mov %0, %3\n"			\
+	"	# zero out dst ptr\n"		\
+	"	mov %1,  0\n"			\
 	"	j   2b\n"			\
 	"	.previous\n"			\
 	"	.section __ex_table, \"a\"\n"	\
@@ -101,7 +104,11 @@
 	"2:	;nop\n"				\
 	"	.section .fixup, \"ax\"\n"	\
 	"	.align 4\n"			\
-	"3:	mov %0, %3\n"			\
+	"3:	# return -EFAULT\n"		\
+	"	mov %0, %3\n"			\
+	"	# zero out dst ptr\n"		\
+	"	mov %1,  0\n"			\
+	"	mov %R1, 0\n"			\
 	"	j   2b\n"			\
 	"	.previous\n"			\
 	"	.section __ex_table, \"a\"\n"	\
-- 
2.10.0



From jslaby at suse.cz  Thu Sep 29 03:25:36 2016
From: jslaby at suse.cz (Jiri Slaby)
Date: Thu, 29 Sep 2016 12:25:36 +0200
Subject: [PATCH 3.12 100/119] ARC: uaccess: get_user to zero out dest in cause
 of fault
In-Reply-To: <a528a0fa6d67ebe60bfc762c72b316d28ed21dea.1475144721.git.jslaby@suse.cz>
References: <a528a0fa6d67ebe60bfc762c72b316d28ed21dea.1475144721.git.jslaby@suse.cz>
Message-ID: <27f32d12e690e61a9b356f84e54f496a2cb64f6e.1475144721.git.jslaby@suse.cz>

From: Vineet Gupta <Vineet.Gupta1 at synopsys.com>

3.12-stable review patch.  If anyone has any objections, please let me know.

===============

commit 05d9d0b96e53c52a113fd783c0c97c830c8dc7af upstream.

Al reported potential issue with ARC get_user() as it wasn't clearing
out destination pointer in case of fault due to bad address etc.

Verified using following

| {
|  	u32 bogus1 = 0xdeadbeef;
|	u64 bogus2 = 0xdead;
|	int rc1, rc2;
|
|  	pr_info("Orig values %x %llx\n", bogus1, bogus2);
|	rc1 = get_user(bogus1, (u32 __user *)0x40000000);
|	rc2 = get_user(bogus2, (u64 __user *)0x50000000);
|	pr_info("access %d %d, new values %x %llx\n",
|		rc1, rc2, bogus1, bogus2);
| }

| [ARCLinux]# insmod /mnt/kernel-module/qtn.ko
| Orig values deadbeef dead
| access -14 -14, new values 0 0

Reported-by: Al Viro <viro at ZenIV.linux.org.uk>
Cc: Linus Torvalds <torvalds at linux-foundation.org>
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
Signed-off-by: Al Viro <viro at zeniv.linux.org.uk>
Signed-off-by: Jiri Slaby <jslaby at suse.cz>
---
 arch/arc/include/asm/uaccess.h | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arc/include/asm/uaccess.h b/arch/arc/include/asm/uaccess.h
index 30c9baffa96f..08770c750696 100644
--- a/arch/arc/include/asm/uaccess.h
+++ b/arch/arc/include/asm/uaccess.h
@@ -83,7 +83,10 @@
 	"2:	;nop\n"				\
 	"	.section .fixup, \"ax\"\n"	\
 	"	.align 4\n"			\
-	"3:	mov %0, %3\n"			\
+	"3:	# return -EFAULT\n"		\
+	"	mov %0, %3\n"			\
+	"	# zero out dst ptr\n"		\
+	"	mov %1,  0\n"			\
 	"	j   2b\n"			\
 	"	.previous\n"			\
 	"	.section __ex_table, \"a\"\n"	\
@@ -101,7 +104,11 @@
 	"2:	;nop\n"				\
 	"	.section .fixup, \"ax\"\n"	\
 	"	.align 4\n"			\
-	"3:	mov %0, %3\n"			\
+	"3:	# return -EFAULT\n"		\
+	"	mov %0, %3\n"			\
+	"	# zero out dst ptr\n"		\
+	"	mov %1,  0\n"			\
+	"	mov %R1, 0\n"			\
 	"	j   2b\n"			\
 	"	.previous\n"			\
 	"	.section __ex_table, \"a\"\n"	\
-- 
2.10.0



From Vineet.Gupta1 at synopsys.com  Thu Sep 29 09:47:08 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Thu, 29 Sep 2016 09:47:08 -0700
Subject: NMI for ARC
In-Reply-To: <20160929064341.GH3318@worktop.controleur.wifipass.org>
References: <20151117122401.GY3816@twins.programming.kicks-ass.net>
 <20151117122540.GL11639@twins.programming.kicks-ass.net>
 <564B2341.4030409@synopsys.com>
 <20151117131538.GZ3816@twins.programming.kicks-ass.net>
 <3b23d64c-2579-b72e-645a-e7ece3c1a3c6@synopsys.com>
 <20160928071642.GU2794@worktop>
 <CALCETrXJCGMW7DcAVw5mkfiOce4u+3OM3_QLkE117ewU_Hzpsg@mail.gmail.com>
 <20160928203748.GU5012@twins.programming.kicks-ass.net>
 <CALCETrVz48j=fmWtXN9wtSbAP6LNcb-=Uf6biq-9EmMQ=zM8zA@mail.gmail.com>
 <75783d4b-98bf-5d60-a844-20d4eec88ac9@synopsys.com>
 <20160929064341.GH3318@worktop.controleur.wifipass.org>
Message-ID: <a7fb2709-decd-7aa9-57c4-b996c7755c33@synopsys.com>

On 09/28/2016 11:43 PM, Peter Zijlstra wrote:
> On Wed, Sep 28, 2016 at 06:20:29PM -0700, Vineet Gupta wrote:
>> On 09/28/2016 03:26 PM, Andy Lutomirski wrote:

> 
> 
> 	user	irq	nmi
> 
> 	|
> 	|
> 	`-----> .
> 		|
> 		|
> 		|
> 		`----->	.
> 			|
> 			|
> 		. <-----'
> 	. <-----'
> 	|
> 	|
> 
> So what Andy is saying is that NMI context never sets TIF_NEED_RESCHED,

Can we we be absolutely sure about that. A perf intr, vmalloc based mmap can go
thru various hoops and. Is it not possible that it hits a reschedule, setting
TIF_NEED_RESCHED

> this means that return from NMI never needs to check for preemption
> etc..

I don't think this implies from prev one. In my example, timer interrupt triggers
a TIF_NEED_RESCHED and irq_exit -> __do_softirq() it hits the perf intr

> Now your return from IRQ obviously should, the normal way. If the IRQ
> return gets interrupted by the NMI nothing special should occur. The
> return from NMI should simply resume the return from IRQ.
> 
> So I'm a little confused by your timer interrupt example, it _should_ do
> the preemption, the nested interrupt (NMI) will return to the regular
> interrupt which should resume its normal return preemption or not.

So lets first see how a single priority intr works on ARC (maybe on other arches
as well).

1. task t1 enters kernel syscall (Trap Exception on ARC), handler drops down to
pure kernel model and proceeds into syscall handler.
2. while in handler, some intr is taken, which causes a reschedule to task t2.
3. t2's control flow returns (say it was in syscall when originally
scheduled-out). It needs to return to user mode but cpu needs to return from
active interrupt. So we return to user mode, "riding" the intr return path. Means
intr in step #2 returns to a different PC and execution mode (user vs. kernel etc).

Now the same scheme doesn't work out of the box when u have intr and nmi. We have
to actively ensure that nmi doesn't lead to a __schedule() sans user code. And
this is done by bumping preempt_count(NMI_OFFSET) in entry of nmi handler.


From luto at amacapital.net  Thu Sep 29 10:30:02 2016
From: luto at amacapital.net (Andy Lutomirski)
Date: Thu, 29 Sep 2016 10:30:02 -0700
Subject: NMI for ARC
In-Reply-To: <75783d4b-98bf-5d60-a844-20d4eec88ac9@synopsys.com>
References: <C2D7FE5348E1B147BCA15975FBA23075F44D210D@IN01WEMBXA.internal.synopsys.com>
 <20151117110749.GT3816@twins.programming.kicks-ass.net>
 <564B0E18.3040207@synopsys.com>
 <20151117122401.GY3816@twins.programming.kicks-ass.net>
 <20151117122540.GL11639@twins.programming.kicks-ass.net>
 <564B2341.4030409@synopsys.com>
 <20151117131538.GZ3816@twins.programming.kicks-ass.net>
 <3b23d64c-2579-b72e-645a-e7ece3c1a3c6@synopsys.com>
 <20160928071642.GU2794@worktop>
 <CALCETrXJCGMW7DcAVw5mkfiOce4u+3OM3_QLkE117ewU_Hzpsg@mail.gmail.com>
 <20160928203748.GU5012@twins.programming.kicks-ass.net>
 <CALCETrVz48j=fmWtXN9wtSbAP6LNcb-=Uf6biq-9EmMQ=zM8zA@mail.gmail.com>
 <75783d4b-98bf-5d60-a844-20d4eec88ac9@synopsys.com>
Message-ID: <CALCETrV5mWJx5fhfkjdgk+FpqjvPhDvxyn0xbWDDkAMmW-9n+A@mail.gmail.com>

On Sep 28, 2016 6:20 PM, "Vineet Gupta" <vgupta at synopsys.com> wrote:
>
> On 09/28/2016 03:26 PM, Andy Lutomirski wrote:
> >> Right, so what I think Vineet is asking is if we need to disable NMIs as
> >> > well, we cannot on x86 disable NMIs so no.
> >> >
> > The same argument works here, too: an NMI won't set TIF_NEED_RESCHED
> > without sending an IPI, so we can't miss a wakeup.
>
> But what exact wakeup miss are we taking about here. If intr were NOT disabled,
> how could this happen. Just trying to understand the need for "irqs-disabled" in
> resume_{user,kernel}_*
>
> The intr disabled before reg file restore makes complete sense though.

An interrupt after the TIF_NEED_RESCHED check could set
TIF_NEED_RESCHED (because it woke a waiting task), and the resume code
wouldn't notice.  No IPI would be sent because TIF_NEED_RESCHED on the
current task is supposed to be acted on in a timely manner without
one.

More severe problems could happen.  A signal could be queued or, on
x86, a return-to-usermode notifier could be set by KVM on a
preemptible kernel.  The latter, if missed, will bring down the whole
machine.


From luto at amacapital.net  Thu Sep 29 11:54:03 2016
From: luto at amacapital.net (Andy Lutomirski)
Date: Thu, 29 Sep 2016 11:54:03 -0700
Subject: NMI for ARC
In-Reply-To: <a7fb2709-decd-7aa9-57c4-b996c7755c33@synopsys.com>
References: <20151117122401.GY3816@twins.programming.kicks-ass.net>
 <20151117122540.GL11639@twins.programming.kicks-ass.net>
 <564B2341.4030409@synopsys.com>
 <20151117131538.GZ3816@twins.programming.kicks-ass.net>
 <3b23d64c-2579-b72e-645a-e7ece3c1a3c6@synopsys.com>
 <20160928071642.GU2794@worktop>
 <CALCETrXJCGMW7DcAVw5mkfiOce4u+3OM3_QLkE117ewU_Hzpsg@mail.gmail.com>
 <20160928203748.GU5012@twins.programming.kicks-ass.net>
 <CALCETrVz48j=fmWtXN9wtSbAP6LNcb-=Uf6biq-9EmMQ=zM8zA@mail.gmail.com>
 <75783d4b-98bf-5d60-a844-20d4eec88ac9@synopsys.com>
 <20160929064341.GH3318@worktop.controleur.wifipass.org>
 <a7fb2709-decd-7aa9-57c4-b996c7755c33@synopsys.com>
Message-ID: <CALCETrWZ47facpNA0Juf4e9cJN9BsN7YO+8RdSeU2q=uaUgYFw@mail.gmail.com>

On Thu, Sep 29, 2016 at 9:47 AM, Vineet Gupta
<Vineet.Gupta1 at synopsys.com> wrote:
> On 09/28/2016 11:43 PM, Peter Zijlstra wrote:
>> On Wed, Sep 28, 2016 at 06:20:29PM -0700, Vineet Gupta wrote:
>>> On 09/28/2016 03:26 PM, Andy Lutomirski wrote:
>
>>
>>
>>       user    irq     nmi
>>
>>       |
>>       |
>>       `-----> .
>>               |
>>               |
>>               |
>>               `-----> .
>>                       |
>>                       |
>>               . <-----'
>>       . <-----'
>>       |
>>       |
>>
>> So what Andy is saying is that NMI context never sets TIF_NEED_RESCHED,
>
> Can we we be absolutely sure about that. A perf intr, vmalloc based mmap can go
> thru various hoops and. Is it not possible that it hits a reschedule, setting
> TIF_NEED_RESCHED
>
>> this means that return from NMI never needs to check for preemption
>> etc..
>
> I don't think this implies from prev one. In my example, timer interrupt triggers
> a TIF_NEED_RESCHED and irq_exit -> __do_softirq() it hits the perf intr
>
>> Now your return from IRQ obviously should, the normal way. If the IRQ
>> return gets interrupted by the NMI nothing special should occur. The
>> return from NMI should simply resume the return from IRQ.
>>
>> So I'm a little confused by your timer interrupt example, it _should_ do
>> the preemption, the nested interrupt (NMI) will return to the regular
>> interrupt which should resume its normal return preemption or not.
>
> So lets first see how a single priority intr works on ARC (maybe on other arches
> as well).
>
> 1. task t1 enters kernel syscall (Trap Exception on ARC), handler drops down to
> pure kernel model and proceeds into syscall handler.
> 2. while in handler, some intr is taken, which causes a reschedule to task t2.
> 3. t2's control flow returns (say it was in syscall when originally
> scheduled-out). It needs to return to user mode but cpu needs to return from
> active interrupt. So we return to user mode, "riding" the intr return path. Means
> intr in step #2 returns to a different PC and execution mode (user vs. kernel etc).
>

For the benefit of people who don't know what an "active interrupt" is
(x86 has no such concept in hardware), can you elaborate a bit?  On
x86, for all practical purposes [1], an interrupt kicks the CPU into
kernel mode, and the kernel is free to return however it likes.  It
can do a standard interrupt return right back to the interrupted
context, but it can also switch stacks and do whatever some other
thread was doing.

> Now the same scheme doesn't work out of the box when u have intr and nmi. We have
> to actively ensure that nmi doesn't lead to a __schedule() sans user code. And
> this is done by bumping preempt_count(NMI_OFFSET) in entry of nmi handler.

The perf NMI code won't schedule.  In general, you just need to ensure
that is_nmi() is true.  Any kernel code that touches normal locks,
schedules, gets page faults without extreme caution, etc. needs to be
aware that nmis are special.


[1] There's an exception on 64-bit AMD CPUs because AMD blew it.
Also, x86 NMI return is itself severely overcomplicated because we don't
have good control over NMI nesting.


From Vineet.Gupta1 at synopsys.com  Thu Sep 29 12:48:03 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Thu, 29 Sep 2016 12:48:03 -0700
Subject: NMI for ARC
In-Reply-To: <CALCETrWZ47facpNA0Juf4e9cJN9BsN7YO+8RdSeU2q=uaUgYFw@mail.gmail.com>
References: <20151117122401.GY3816@twins.programming.kicks-ass.net>
 <20151117122540.GL11639@twins.programming.kicks-ass.net>
 <564B2341.4030409@synopsys.com>
 <20151117131538.GZ3816@twins.programming.kicks-ass.net>
 <3b23d64c-2579-b72e-645a-e7ece3c1a3c6@synopsys.com>
 <20160928071642.GU2794@worktop>
 <CALCETrXJCGMW7DcAVw5mkfiOce4u+3OM3_QLkE117ewU_Hzpsg@mail.gmail.com>
 <20160928203748.GU5012@twins.programming.kicks-ass.net>
 <CALCETrVz48j=fmWtXN9wtSbAP6LNcb-=Uf6biq-9EmMQ=zM8zA@mail.gmail.com>
 <75783d4b-98bf-5d60-a844-20d4eec88ac9@synopsys.com>
 <20160929064341.GH3318@worktop.controleur.wifipass.org>
 <a7fb2709-decd-7aa9-57c4-b996c7755c33@synopsys.com>
 <CALCETrWZ47facpNA0Juf4e9cJN9BsN7YO+8RdSeU2q=uaUgYFw@mail.gmail.com>
Message-ID: <245c485e-6350-bd7f-97f2-4e35be2c8e2a@synopsys.com>

On 09/29/2016 11:54 AM, Andy Lutomirski wrote:
>> So lets first see how a single priority intr works on ARC (maybe on other arches
>> > as well).
>> >
>> > 1. task t1 enters kernel syscall (Trap Exception on ARC), handler drops down to
>> > pure kernel model and proceeds into syscall handler.
>> > 2. while in handler, some intr is taken, which causes a reschedule to task t2.
>> > 3. t2's control flow returns (say it was in syscall when originally
>> > scheduled-out). It needs to return to user mode but cpu needs to return from
>> > active interrupt. So we return to user mode, "riding" the intr return path. Means
>> > intr in step #2 returns to a different PC and execution mode (user vs. kernel etc).
>> >
> For the benefit of people who don't know what an "active interrupt" is
> (x86 has no such concept in hardware), can you elaborate a bit? 

A bit set in AUX_IRQ_ACTIVE register which says cpu is servicing an interrupt (of
prio X - see bottom for more details). ARC has RTIE instruction to return from
intr/exception/pure-kernel-mode. In HS38 cores, h/w saves the regfile on taken
interrupts (and not exceptions). Thus RTIE needs to know about return from intr or
exception (pure kernel mode is same as exceptions). In that sense there is a
distinction between intr mode and pure kernel mode.

> On
> x86, for all practical purposes [1], an interrupt kicks the CPU into
> kernel mode, and the kernel is free to return however it likes.  It
> can do a standard interrupt return right back to the interrupted
> context, but it can also switch stacks and do whatever some other
> thread was doing.

That is the true for ARC as well. A taken interrupt can return form orig taken
intr context or it can return in the context of a sched-in task which itself had
entered kernel via a syscall. The auto-saved regfile for interrupts is compatible
with hand saved regs for traps/exceptions so it doesn't really matter.

So when I started with initial nmi support, I was lacking equivalent of
nmi_enter() in the perf intr handler. That in turn led to this nested intr + sched
of user task situation. With that fixed (originally by just fudging the soft
preempt count in nmi entry/exit), I was able to solve this.
So even if TIF_NEED_RESCHED was already set (by outer intr say), nmi returned path
won't resched because of in_nmi() being true.

My original question to Peter was, whether it is OK to elide TIF_NEED_RESCHED
checks for nmi handlers, as an optimization, so that perf intr returns faster.

>> > Now the same scheme doesn't work out of the box when u have intr and nmi. We have
>> > to actively ensure that nmi doesn't lead to a __schedule() sans user code. And
>> > this is done by bumping preempt_count(NMI_OFFSET) in entry of nmi handler.
> The perf NMI code won't schedule.  In general, you just need to ensure
> that is_nmi() is true.  Any kernel code that touches normal locks,
> schedules, gets page faults without extreme caution, etc. needs to be
> aware that nmis are special.

Exactly this bit is what I was missing in the first place.


> [1] There's an exception on 64-bit AMD CPUs because AMD blew it.
> Also, x86 NMI return is itself severely overcomplicated because we don't
> have good control over NMI nesting.

For ARC (HS38 cores), there are 16 interrupt priorities (0-high, 15-lowest) and
each active interrupt has a bit in AUX_IRQ_ACTIVE. If a prio X is active, another
prio X can't be taken (you can only take higher prio). In that sense nmi (aka prio
0) can't nest for us.

-Vineet


From peterz at infradead.org  Fri Sep 30 03:49:41 2016
From: peterz at infradead.org (Peter Zijlstra)
Date: Fri, 30 Sep 2016 12:49:41 +0200
Subject: NMI for ARC
In-Reply-To: <245c485e-6350-bd7f-97f2-4e35be2c8e2a@synopsys.com>
References: <3b23d64c-2579-b72e-645a-e7ece3c1a3c6@synopsys.com>
 <20160928071642.GU2794@worktop>
 <CALCETrXJCGMW7DcAVw5mkfiOce4u+3OM3_QLkE117ewU_Hzpsg@mail.gmail.com>
 <20160928203748.GU5012@twins.programming.kicks-ass.net>
 <CALCETrVz48j=fmWtXN9wtSbAP6LNcb-=Uf6biq-9EmMQ=zM8zA@mail.gmail.com>
 <75783d4b-98bf-5d60-a844-20d4eec88ac9@synopsys.com>
 <20160929064341.GH3318@worktop.controleur.wifipass.org>
 <a7fb2709-decd-7aa9-57c4-b996c7755c33@synopsys.com>
 <CALCETrWZ47facpNA0Juf4e9cJN9BsN7YO+8RdSeU2q=uaUgYFw@mail.gmail.com>
 <245c485e-6350-bd7f-97f2-4e35be2c8e2a@synopsys.com>
Message-ID: <20160930104941.GI5016@twins.programming.kicks-ass.net>

On Thu, Sep 29, 2016 at 12:48:03PM -0700, Vineet Gupta wrote:
> > [1] There's an exception on 64-bit AMD CPUs because AMD blew it.
> > Also, x86 NMI return is itself severely overcomplicated because we don't
> > have good control over NMI nesting.
> 
> For ARC (HS38 cores), there are 16 interrupt priorities (0-high, 15-lowest) and
> each active interrupt has a bit in AUX_IRQ_ACTIVE. If a prio X is active, another
> prio X can't be taken (you can only take higher prio). In that sense nmi (aka prio
> 0) can't nest for us.

Forget you ever read this; the reason for the nested NMIs on x86 is
horrid, but here goes:

The problem is that IRET, the only instruction capable of returning from
_any_ trap/fault/interrupt context automagically unmasks NMIs. And we
'want' to take debug-traps and page-faults from NMI context.

We use debug-traps to synchronize against self-modifying code without
halting the entire machine.

We 'need' page-faults for vmalloc backed memory, the vmalloc page tables
are not globally propagated and we need (minor) faults to populate the
page-tables on demand. And we need page-faults to do user-space access
from NMI context (for the fixup_exception stuff).

Returning from either trap or fault is done through IRET, which then
unmasks NMIs, allowing another NMI to come in while we're still
servicing one.

We have quite the horror cabinet for dealing with this ;-)


From Vineet.Gupta1 at synopsys.com  Fri Sep 30 14:11:26 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Fri, 30 Sep 2016 14:11:26 -0700
Subject: [PATCH] ARCv2: fix local_save_flags
Message-ID: <1475269886-10832-1-git-send-email-vgupta@synopsys.com>

Commit d9676fa152c83b ("ARCv2: Enable LOCKDEP"), changed
local_save_flags() to not return raw STATUS32 but encoded in the form
such that it could be fed directly to CLRI/SETI instructions.
However the STATUS32.E[] was not captured correctly as it corresponds to
bits [4:1] in the register and not [3:0]

Fixes: d9676fa152c83b ("ARCv2: Enable LOCKDEP")
Cc: Evgeny Voevodin <evgeny.voevodin at intel.com>
Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
---
 arch/arc/include/asm/irqflags-arcv2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arc/include/asm/irqflags-arcv2.h b/arch/arc/include/asm/irqflags-arcv2.h
index d1ec7f6b31e0..e880dfa3fcd3 100644
--- a/arch/arc/include/asm/irqflags-arcv2.h
+++ b/arch/arc/include/asm/irqflags-arcv2.h
@@ -112,7 +112,7 @@ static inline long arch_local_save_flags(void)
 	 */
 	temp = (1 << 5) |
 		((!!(temp & STATUS_IE_MASK)) << CLRI_STATUS_IE_BIT) |
-		(temp & CLRI_STATUS_E_MASK);
+		((temp >> 1) & CLRI_STATUS_E_MASK);
 	return temp;
 }
 
-- 
2.7.4



From Vineet.Gupta1 at synopsys.com  Fri Sep 30 14:18:35 2016
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Fri, 30 Sep 2016 14:18:35 -0700
Subject: [PATCH] ARCv2: intc: Use kflag if STATUS32.IE must be reset
In-Reply-To: <1473695703-29547-1-git-send-email-yuriy.kolerov@synopsys.com>
References: <1473695703-29547-1-git-send-email-yuriy.kolerov@synopsys.com>
Message-ID: <b95120e6-010b-0822-e915-2f1abf964a56@synopsys.com>

On 09/12/2016 08:55 AM, Yuriy Kolerov wrote:
> In the end of "arc_init_IRQ" STATUS32.IE flag is going to be affected by
> "flag" instruction but "flag" never touches IE flag on ARCv2. So "kflag"
> instruction must be used instead of "flag".
> 
> Signed-off-by: Yuriy Kolerov <yuriy.kolerov at synopsys.com>
> ---
>  arch/arc/kernel/intc-arcv2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arc/kernel/intc-arcv2.c b/arch/arc/kernel/intc-arcv2.c
> index 6c24faf..62b59409 100644
> --- a/arch/arc/kernel/intc-arcv2.c
> +++ b/arch/arc/kernel/intc-arcv2.c
> @@ -74,7 +74,7 @@ void arc_init_IRQ(void)
>  	tmp = read_aux_reg(0xa);
>  	tmp |= STATUS_AD_MASK | (irq_prio << 1);
>  	tmp &= ~STATUS_IE_MASK;
> -	asm volatile("flag %0	\n"::"r"(tmp));
> +	asm volatile("kflag %0	\n"::"r"(tmp));

Revisiting this in light of ongoing 2 priority interrupt support for HS38 cores.

It seems there is no need to fiddle with interrupt bits here at all.

init/main.c now has well known checkpoints where it explicitly disables the
interrupts in early boot code and enables them when time is right. So when we land
in arc_init_IRQ() interrupts have already been disabled.

So I'm dropping this patch and instead adding another one which removes the intr
bits touching part !

OK ?

-Vineet



From noreply at ellerman.id.au  Fri Sep 30 22:57:56 2016
From: noreply at ellerman.id.au (noreply at ellerman.id.au)
Date: Sat, 01 Oct 2016 05:57:56 -0000
Subject: kisskb: OK linus/axs101_defconfig/arcompact Sat Oct 01, 15:56
Message-ID: <20161001055756.1.84691@8e2d6d7be827>

OK linus/axs101_defconfig/arcompact Sat Oct 01, 15:56

http://kisskb.ellerman.id.au/kisskb/buildresult/12818575/

Commit:   Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
          2161a2a644a6d33a29d68395518d103ed805758f
Compiler: arc-buildroot-linux-uclibc-gcc (Buildroot 2015.08.1) 4.8.4

No errors found in log

Possible warnings (17)
----------------------

net/core/ethtool.c:300:1: warning: control reaches end of non-void function [-Wreturn-type]
block/cfq-iosched.c:3819:1: warning: control reaches end of non-void function [-Wreturn-type]
include/linux/kernel.h:742:17: warning: comparison of distinct pointer types lacks a cast [enabled by default]
net/ipv4/tcp_input.c:4286:49: warning: array subscript is above array bounds [-Warray-bounds]
kernel/sched/core.c:3277:1: warning: control reaches end of non-void function [-Wreturn-type]
fs/ext4/ext4_jbd2.h:428:1: warning: control reaches end of non-void function [-Wreturn-type]
fs/ext4/ext4_jbd2.h:428:1: warning: control reaches end of non-void function [-Wreturn-type]
fs/ext4/ext4_jbd2.h:428:1: warning: control reaches end of non-void function [-Wreturn-type]
fs/ext4/ext4_jbd2.h:428:1: warning: control reaches end of non-void function [-Wreturn-type]
fs/ext4/ext4_jbd2.h:428:1: warning: control reaches end of non-void function [-Wreturn-type]
fs/ext4/ext4_jbd2.h:428:1: warning: control reaches end of non-void function [-Wreturn-type]
fs/ext4/ext4_jbd2.h:428:1: warning: control reaches end of non-void function [-Wreturn-type]
fs/ext4/ext4_jbd2.h:428:1: warning: control reaches end of non-void function [-Wreturn-type]
include/linux/sunrpc/svc_xprt.h:176:1: warning: control reaches end of non-void function [-Wreturn-type]
fs/ext4/ext4_jbd2.h:428:1: warning: control reaches end of non-void function [-Wreturn-type]
drivers/scsi/sd.c:1154:1: warning: control reaches end of non-void function [-Wreturn-type]
arch/arc/include/asm/elf.h:58:29: warning: integer overflow in expression [-Woverflow]



