Re: [PATCH v2 9/9] powerpc/eeh: Add eeh_state_active() helper

2018-03-19 Thread kbuild test robot 
Hi Sam,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on v4.16-rc4]
[also build test ERROR on next-20180319]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Sam-Bobroff/EEH-refactoring-1/20180320-024729
config: powerpc-ppc64_defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

   In file included from include/linux/kernel.h:14:0,
from include/linux/delay.h:22,
from arch/powerpc/kernel/eeh_driver.c:25:
   arch/powerpc/kernel/eeh_driver.c: In function 'eeh_reset_device':
>> arch/powerpc/kernel/eeh_driver.c:692:5: error: 'eeh_aware_driver' undeclared 
>> (first use in this function); did you mean 'eeh_state_active'?
   (eeh_aware_driver ? "partial" : "complete"));
^
   include/linux/printk.h:308:34: note: in definition of macro 'pr_info'
 printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
 ^~~
   arch/powerpc/kernel/eeh_driver.c:692:5: note: each undeclared identifier is 
reported only once for each function it appears in
   (eeh_aware_driver ? "partial" : "complete"));
^
   include/linux/printk.h:308:34: note: in definition of macro 'pr_info'
 printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
 ^~~

vim +692 arch/powerpc/kernel/eeh_driver.c

5cfb20b96 arch/powerpc/kernel/eeh_driver.cGavin Shan
2014-09-30  619  
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 
2005-11-03  620  /**
29f8bf1b7 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan
2012-02-27  621   * eeh_reset_device - Perform actual reset of a pci slot
a10e51924 arch/powerpc/kernel/eeh_driver.cSam Bobroff   
2018-03-19  622   * @driver_eeh_aware: Does the device's driver provide EEH 
support?
9b3c76f08 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan
2012-09-07  623   * @pe: EEH PE
29f8bf1b7 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan
2012-02-27  624   * @bus: PCI bus corresponding to the isolcated slot
a10e51924 arch/powerpc/kernel/eeh_driver.cSam Bobroff   
2018-03-19  625   * @rmv_data: Optional, list to record removed devices
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 
2005-11-03  626   *
29f8bf1b7 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan
2012-02-27  627   * This routine must be called to do reset on the indicated PE.
29f8bf1b7 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan
2012-02-27  628   * During the reset, udev might be invoked because those 
affected
29f8bf1b7 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan
2012-02-27  629   * PCI devices will be removed and then added.
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 
2005-11-03  630   */
67086e32b arch/powerpc/kernel/eeh_driver.cWei Yang  
2016-03-04  631  static int eeh_reset_device(struct eeh_pe *pe, struct pci_bus 
*bus,
a10e51924 arch/powerpc/kernel/eeh_driver.cSam Bobroff   
2018-03-19  632 struct eeh_rmv_data *rmv_data,
a10e51924 arch/powerpc/kernel/eeh_driver.cSam Bobroff   
2018-03-19  633 bool driver_eeh_aware)
77bd74156 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 
2005-11-03  634  {
edfd17ff3 arch/powerpc/kernel/eeh_driver.cArnd Bergmann 
2017-11-04  635 time64_t tstamp;
67086e32b arch/powerpc/kernel/eeh_driver.cWei Yang  
2016-03-04  636 int cnt, rc;
67086e32b arch/powerpc/kernel/eeh_driver.cWei Yang  
2016-03-04  637 struct eeh_dev *edev;
424054566 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 
2006-04-28  638  
424054566 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 
2006-04-28  639 /* pcibios will clear the counter; save the value */
9b3c76f08 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan
2012-09-07  640 cnt = pe->freeze_count;
5a71978e4 arch/powerpc/kernel/eeh_driver.cGavin Shan
2013-06-20  641 tstamp = pe->tstamp;
424054566 arch/powerpc/platforms/pseries/eeh_driver.c Linas Vepstas 
2006-04-28  642  
20ee6a970 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan
2012-09-11  643 /*
20ee6a970 arch/powerpc/platforms/pseries/eeh_driver.c Gavin Shan
2012-09-11  644  * W

Re: [PATCH 1/2] powerpc64/ftrace: Add a field in paca to disable ftrace in unsafe code paths

2018-03-19 Thread Nicholas Piggin 
On Tue, 20 Mar 2018 09:34:43 +1100
Michael Ellerman  wrote:

> Nicholas Piggin  writes:
> 
> > On Mon, 19 Mar 2018 14:43:00 +0530
> > "Naveen N. Rao"  wrote:
> >  
> >> We have some C code that we call into from real mode where we cannot
> >> take any exceptions. Though the C functions themselves are mostly safe,
> >> if these functions are traced, there is a possibility that we may take
> >> an exception. For instance, in certain conditions, the ftrace code uses
> >> WARN(), which uses a 'trap' to do its job.
> >> 
> >> For such scenarios, introduce a new field in paca 'ftrace_disabled',
> >> which is checked on ftrace entry before continuing. This field can then
> >> be set to a non-zero value to disable/pause ftrace, and reset to zero to
> >> resume ftrace.
> >> 
> >> Since KVM is the only user for this currently, we guard the
> >> ftrace/mcount checks within CONFIG_KVM. This can later be removed
> >> if/when there are other users.  
> >
> > Why not test HSTATE_IN_GUEST then? Add ftrace_disabled if non-KVM users
> > come along.  
> 
> We want to use it for the kexec down path, we've already had bugs there.
> 
> So please keep the separate flag and pull it out of #ifdef KVM.

Okay that's fine.

> If we're worried about space usage in the paca we can probably
> consolidate this and some other things into a flags word.

I'm not too concerned about some more u8 flags.

Thanks,
Nick

Re: [PATCH] powerpc/boot: Remove duplicate typedefs from libfdt_env.h

2018-03-19 Thread Oliver 
On Tue, Mar 20, 2018 at 3:02 AM, Mark Greer  wrote:
> On Mon, Mar 19, 2018 at 09:53:09AM +0100, Christophe LEROY wrote:
>>
>>
>> Le 16/03/2018 à 22:54, Mark Greer a écrit :
>> >When building a uImage or zImage using ppc6xx_defconfig and some other
>> >defconfigs, the following error occurs:
>> >
>> >   BOOTCC  arch/powerpc/boot/fdt.o
>> >   In file included from arch/powerpc/boot/fdt.c:51:0:
>> >   ../arch/powerpc/boot/libfdt_env.h:10:13: error: redefinition of typedef 
>> > 'uint32_t'
>> >   ../arch/powerpc/boot/types.h:21:13: note: previous declaration of 
>> > 'uint32_t' was here
>> >   ../arch/powerpc/boot/libfdt_env.h:11:13: error: redefinition of typedef 
>> > 'uint64_t'
>> >   ../arch/powerpc/boot/types.h:22:13: note: previous declaration of 
>> > 'uint64_t' was here
>> >   ../arch/powerpc/boot/Makefile:210: recipe for target 
>> > 'arch/powerpc/boot/fdt.o' failed
>> >   make[2]: *** [arch/powerpc/boot/fdt.o] Error 1
>> >
>> >The problem is that commit 656ad58ef19e (powerpc/boot: Add OPAL console
>> >to epapr wrappers) adds typedefs for uint32_t and uint64_t to type.h but
>> >doesn't remove the pre-existing (and now duplicate) typedefs from
>> >libfdt_env.h.  Fix the error by removing the duplicat typedefs from
>> >libfdt_env.h
>> >
>> >CC: David Gibson 
>> >CC: Oliver O'Halloran 
>> >Signed-off-by: Mark Greer 
>> >---
>> >Having said all of that, commit 656ad58ef19e (powerpc/boot: Add OPAL
>> >console to epapr wrappers) went into mainline back in 2016 so, AFAICT,
>> >this has been broken since then.  That seems unlikely so I must be
>> >missing something...  Any ideas what that is?
>>
>> I just compiled uImage for ppc6xx_defconfig, and I don't get such error.
>> I looked at what gcc -E outputs, u32 is defined twice but it doesn't seems
>> to bother GCC.
>>
>> What version of GCC do you use ?
>> I tried with 5.4.0 and 4.6.3, both seems to work.
>>
>> Christophe
>
> Hi Christophe.
>
> That's interesting.  I would expect an error regardless of version.
>
> I used an old 4.5.1 gcc that I had laying around (from denx, iirc).
> I'll find a newer one and try it.

Yeah that's pretty odd. It might be a bug in your specific version of
GCC since I can't replicate it with this dumb test case:

#include 
typedef unsigned intu32;

typedef u32 uint32_t;
typedef u32 uint32_t;

int main(void) {
uint32_t test = 0;
printf("%u\n", test);
return 0;
}

Does that result in an error?

> Either way, it seems to me that we should remove the duplicate definitions.
> Do you agree?

It wouldn't hurt to remove those definitions from libfdt_env.h. That
file includes types.h directly anyway so there's not much point in
them being there.

Thanks,
Oliver

Re: [RFC PATCH 4/6] mm: provide generic compat_sys_readahead() implementation

2018-03-19 Thread Al Viro 
On Mon, Mar 19, 2018 at 10:29:20AM +0100, Ingo Molnar wrote:
> 
> * Al Viro  wrote:
> 
> > On Sun, Mar 18, 2018 at 06:18:48PM +, Al Viro wrote:
> > 
> > > I'd done some digging in that area, will find the notes and post.
> > 
> > OK, found:
> 
> Very nice writeup - IMHO this should go into Documentation/!

If you want to turn that into something printable - more power to you...
FWIW, I think we need to require per-architecture descriptions of ABI
for all architectures.  Something along the lines of

alpha:
C ABI: 64bit, location sequence is ($16, $17, $18, $19, $20, $21, stack)
No arg padding (as for all 64bit).  Stack pointer in $30, return value
in $0.
Syscall ABI: syscall number in $0, arg slots filled from $16, $17, $18, $19,
$20, $21.  Return value in $0, error is reported as 1 in $19.  Saved
syscall number is used as a flag for __force_successful_syscall_return()
purposes - sticking 0 there inhibits the effect of negative return value.

arm:
C ABI: 32bit, location sequence is (r0, r1, r2, r3, stack).  Arg padding
for 64bit args: to even slot.  Stack pointer in sp, return value in r0
Syscall ABI, EABI variant: syscall number in r7.
Syscall ABI, OABI variant: syscall number encoded into insn.
Syscall ABI (both variants): arg slots filled from r0, r1, r2, r3, r4, r5.
Return value in r0.  It's not quite a biarch (support of e.g. ioctl
handling is absent, etc.; basic syscalls are handled, but that's it).

etc.  Ideally the information about callee-saved registers, syscall restart
logics, etc. should also go there.  I'm sick and tired of digging though
the asm glue of unfamiliar architectures ;-/

Another relevant piece of information (especially for biarch) is how
should sub-word arguments be normalized.  E.g. on amd64 both int and long
are passed in 64bit words and function that expects an int does *not*
care about the upper 32 bits.  If you have long f(int a) {return a;},
it will sign-extend the argument.  On ppc, OTOH, it won't - the caller
is responsible for having the bits 31..63 all equal.

That used to be a source of considerable PITA - e.g. kill(2) used to
require a compat wrapper on ppc.  These days SYSCALL_DEFINE and
COMPAT_SYSCALL_DEFINE glue takes care of normalizations.  However
it doesn't apply for the stuff that does *not* use ...DEFINE and
for use of native syscalls on biarch we need a bit more.  Consider
e.g. 32bit syscall on sparc64 wanting to use the native counterpart.
Arguments that are <= 32bit in both ABIs are fine - normalizations
will take care of them.  Anything that is 64bit in both ABIs means
that we will need compat anyway - the argument needs to be recombined
from two registers into one.  The headache comes from
* signed long
* unsigned long
* pointers
Those are word-sized and we need to normalize.  Solution before
SYSCALL_DEFINE glue: have upper halves forcibly zeroed on entry (which
normalizes unsigned long and pointers) and then sign-extend every
signed int and signed long in per-syscall glue (that zeroing is
guaranteed to denormalize int arguments).  Once SYSCALL_DEFINE started
to do normalization we disposed on the need to do separate wrappers
for int arguments; that still leaves us with signed long ones, but
* they are very rare
* most of the syscalls passing them need compat for more
serious reasons anyway.
There are only two exceptions - bdflush(2) and pciconfig_iobase(2).
The latter doesn't exist on sparc, the former ignores its signed long
argument completely.  So we are left with "zero upper halves of all
argument-bearing registers upon the entry and have per-syscall glue
take care of the rest".

For s390 the situation is nastier - normalization for signed and
unsigned long is the same as usual, but pointers might have junk
in bit 31.  IOW, for anything with pointer in arguments we can't
just use the native syscall.  As the result, s390 doesn't bother
with zeroing upper halves in syscall dispatcher and does private
mini-wrappers for native syscalls with pointer/long/ulong arguments.

That kind of crap really needs to be documented - RTFS becomes
somewhat painful when it involves tens of assemblers *and*
missing ABI documents (try to locate one for something embedded -
great motivation for expanding vocabulary, that) ;-/

FWIW, SYSCALL_DEFINE and its ilk (COMPAT_SYSCALL_DEFINE,
s390 COMPAT_SYSCALL_WRAP, etc.) are all about stepping over the
ABI gap - we've got some values from userland caller and we
need to turn that into a valid C function call that would
satisfy C ABI constraints.  Some amount of normalization might've
been done by syscall dispatcher; this stuff does the rest on
per-function basis.

> One way to implement this would be to put the argument chain types (string) 
> and 
> sizes (int) into a special debug section which isn't included in the final 
> kernel 
> image but which can be checked at link time.

Umm...  Possible, but I actually believe that we can do that without
debug

Re: [PATCH 2/2] powerpc/mm: Trace tlbia instruction

2018-03-19 Thread Balbir Singh 
On Mon, 19 Mar 2018 11:32:40 +0100 (CET)
Christophe Leroy  wrote:

> Add a trace point for tlbia (Translation Lookaside Buffer Invalidate
> All) instruction.
> 
> Signed-off-by: Christophe Leroy 
> ---
>  arch/powerpc/include/asm/trace.h | 15 +++
>  arch/powerpc/mm/mmu_decl.h   |  2 ++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/arch/powerpc/include/asm/trace.h 
> b/arch/powerpc/include/asm/trace.h
> index 33f3b479138b..d1d63b173dd7 100644
> --- a/arch/powerpc/include/asm/trace.h
> +++ b/arch/powerpc/include/asm/trace.h
> @@ -202,6 +202,21 @@ TRACE_EVENT(tlbie,
>   __entry->r)
>  );
>  
> +TRACE_EVENT(tlbia,
> +
> + TP_PROTO(unsigned long lpid),
> + TP_ARGS(lpid),
> + TP_STRUCT__entry(
> + __field(unsigned long, lpid)
> + ),
> +
> + TP_fast_assign(
> + __entry->lpid = lpid;
> + ),
> +
> + TP_printk("lpid=%ld", __entry->lpid)
> +);


Do we want to call this lpid?

Balbir Singh.

Re: [PATCH 1/2] powerpc/mm: Add missing tracepoint for tlbie

2018-03-19 Thread Balbir Singh 
On Mon, 19 Mar 2018 11:32:38 +0100 (CET)
Christophe Leroy  wrote:

> commit 0428491cba927 ("powerpc/mm: Trace tlbie(l) instructions")
> added tracepoints for tlbie calls, but _tlbil_va() was forgotten
> 
> Fixes: 0428491cba927 ("powerpc/mm: Trace tlbie(l) instructions")
> Signed-off-by: Christophe Leroy 
> ---
>  arch/powerpc/mm/mmu_decl.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
> index 57fbc554c785..b9991e0c61a2 100644
> --- a/arch/powerpc/mm/mmu_decl.h
> +++ b/arch/powerpc/mm/mmu_decl.h
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #ifdef CONFIG_PPC_MMU_NOHASH
>  
> @@ -56,6 +57,7 @@ static inline void _tlbil_va(unsigned long address, 
> unsigned int pid,
>unsigned int tsize, unsigned int ind)
>  {
>   asm volatile ("tlbie %0; sync" : : "r" (address) : "memory");
> + trace_tlbie(pid, 0, address, 0, 0, 0, 0);


I did not really cover a whole lot of NOHASH, any idea why its
called tlbil_va and not _tlbie_va?

The first field is really the lpid and should be 0 for non-virtualized
systems. Can I recommend that we rs field for pid and the rb field for
address? so effectively something like

trace_tlbie(0, 0, address, pid, 0, 0, 0);

Balbir

Re: [PATCH 1/2] powerpc64/ftrace: Add a field in paca to disable ftrace in unsafe code paths

2018-03-19 Thread Michael Ellerman 
Nicholas Piggin  writes:

> On Mon, 19 Mar 2018 14:43:00 +0530
> "Naveen N. Rao"  wrote:
>
>> We have some C code that we call into from real mode where we cannot
>> take any exceptions. Though the C functions themselves are mostly safe,
>> if these functions are traced, there is a possibility that we may take
>> an exception. For instance, in certain conditions, the ftrace code uses
>> WARN(), which uses a 'trap' to do its job.
>> 
>> For such scenarios, introduce a new field in paca 'ftrace_disabled',
>> which is checked on ftrace entry before continuing. This field can then
>> be set to a non-zero value to disable/pause ftrace, and reset to zero to
>> resume ftrace.
>> 
>> Since KVM is the only user for this currently, we guard the
>> ftrace/mcount checks within CONFIG_KVM. This can later be removed
>> if/when there are other users.
>
> Why not test HSTATE_IN_GUEST then? Add ftrace_disabled if non-KVM users
> come along.

We want to use it for the kexec down path, we've already had bugs there.

So please keep the separate flag and pull it out of #ifdef KVM.

If we're worried about space usage in the paca we can probably
consolidate this and some other things into a flags word.

cheers

Re: [PATCH 1/1] PCI set flag PCI_SCAN_ALL_PCIE_DEVS for P.A. Semi boards

2018-03-19 Thread Michael Ellerman 
Bjorn Helgaas  writes:

> On Fri, Mar 16, 2018 at 01:55:36PM +0100, Christian Zigotzky wrote:
>> Bjorn Helgaas created a patch for making PCI_SCAN_ALL_PCIE_DEVS work for
>> Root Ports as well as Downstream. Previously PCI_SCAN_ALL_PCIE_DEVS (set by
>> quirks or the "pci=pcie_scan_all"
>> kernel parameter) only affected Switch Downstream Ports, not Root Ports. The
>> problem is, that we have to add always the boot argument "pci=pcie_scan_all"
>> for using Bjorn's improvements. Without the boot argument
>> "pci=pcie_scan_all", the kernel doesn't boot on P.A. Semi boards with SB600
>> chipset (SB600 chipset is connected via PCIe x4 to the P.A. Semi’s
>> PA6T-1682M System-on-a-Chip) because the kernel can't find any drives
>> connected to the SB600 anymore. Olof Johansson has created a patch for
>> executing "pci=pcie_scan_all" automatically on P.A. Semi boards. With his
>> patch, we don't need to add 'pci=pcie_scan_all' to the kernel boot arguments
>> anymore.
>
> The patch looks fine, but I need a signed-off-by line before I can apply
> it.  See 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst

I'm happy to take it, I've been meaning to check if Olof sent a SOB in
his original mail but haven't got to it.

...

Yes, he did, see below.

So I'll merge that, I'll add a Tested-by for you Christian.

Christian please don't remove any of the tags when submitting other
peoples' patches in future.

cheers


>From a3b390277627b0342c8ccfc16e58679e0d8abdde Mon Sep 17 00:00:00 2001
From: Olof Johansson 
Date: Sat, 2 Dec 2017 14:56:36 -0800
Subject: [PATCH] powerpc/pasemi: set PCI_SCAN_ALL_PCI_DEVS

Needed on Amiga X1000 with SB600.

Reported-by: Christian Zigotzky 
Cc: Bjorn Helgaas 
Signed-off-by: Olof Johansson 
---
 arch/powerpc/platforms/pasemi/pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/platforms/pasemi/pci.c 
b/arch/powerpc/platforms/pasemi/pci.c
index 5ff6108..ea54ed2 100644
--- a/arch/powerpc/platforms/pasemi/pci.c
+++ b/arch/powerpc/platforms/pasemi/pci.c
@@ -224,6 +224,8 @@ void __init pas_pci_init(void)
return;
}

+   pci_set_flag(PCI_SCAN_ALL_PCIE_DEVS):
+
for (np = NULL; (np = of_get_next_child(root, np)) != NULL;)
if (np->name && !strcmp(np->name, "pxp") && !pas_add_bridge(np))
of_node_get(np);

Re: [01/10] selftests/powerpc: add process creation benchmark

2018-03-19 Thread Michael Ellerman 
On Tue, 2018-03-06 at 13:24:58 UTC, Nicholas Piggin wrote:
> Signed-off-by: Nicholas Piggin 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/838fd21b1bde8ed16e64289a8c7467

cheers

Re: powerpc: dts: replace 'linux,stdout-path' with 'stdout-path'

2018-03-19 Thread Michael Ellerman 
On Wed, 2018-02-28 at 22:44:06 UTC, Rob Herring wrote:
> 'linux,stdout-path' has been deprecated for some time in favor of
> 'stdout-path'. Now dtc will warn on occurrences of 'linux,stdout-path'.
> Search and replace all the of occurrences with 'stdout-path'.
> 
> Signed-off-by: Rob Herring 
> Cc: Mark Rutland 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: linuxppc-dev@lists.ozlabs.org

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/d79a02b3e03b103d84536fb19ae7a7

cheers

Re: powerpc/time: stop validating rtc_time in .read_time

2018-03-19 Thread Michael Ellerman 
On Wed, 2018-02-21 at 21:46:33 UTC, Alexandre Belloni wrote:
> The RTC core is always calling rtc_valid_tm after the read_time callback.
> It is not necessary to call it just before returning from the callback.
> 
> Signed-off-by: Alexandre Belloni 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/890ae7979758568734881ad0f382c4

cheers

Re: [V6] cxl: Fix timebase synchronization status on P9

2018-03-19 Thread Michael Ellerman 
On Tue, 2018-02-20 at 13:48:56 UTC, Christophe Lombard wrote:
> The PSL Timebase register is updated by the PSL to maintain the
> timebase.
> On P9, the Timebase value is only provided by the CAPP as received
> the last time a timebase request was performed.
> The timebase requests are initiated through the adapter configuration or
> application registers.
> The specific sysfs entry "/sys/class/cxl/cardxx/psl_timebase_synced" is
> now dynamically updated according the content of the PSL Timebase
> register.
> 
> Signed-off-by: Christophe Lombard 
> Reviewed-by: Vaibhav Jain 
> Acked-by: Andrew Donnellan 
> Acked-by: Frederic Barrat 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/c2be663d5307fb9751a562ac664fa7

cheers

Re: [RESEND] powerpc/5200: dts: digsy_mtc.dts: fix rv3029 compatible

2018-03-19 Thread Michael Ellerman 
On Fri, 2018-02-16 at 23:43:23 UTC, Alexandre Belloni wrote:
> The proper compatible for rv3029 is microcrystal,rv3029.
> 
> Acked-by: Anatolij Gustschin 
> Signed-off-by: Alexandre Belloni 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/7004263bd4f4c79da9ca2a1d04d38d

cheers

Re: Fix cleanup when VAS is not configured

2018-03-19 Thread Michael Ellerman 
On Tue, 2018-02-13 at 19:53:27 UTC, Sukadev Bhattiprolu wrote:
> From: Sukadev Bhattiprolu 
> Date: Fri, 9 Feb 2018 11:49:06 -0600
> Subject: [PATCH 1/1] powerpc/vas: Fix cleanup when VAS is not configured
> 
> When VAS is not configured, unregister the platform driver. Also simplify
> cleanup by delaying vas debugfs init until we know VAS is configured.
> 
> Signed-off-by: Sukadev Bhattiprolu 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/45ddea8a73a25461387eb8e87f3e0e

cheers

Re: [4/4] powerpc/vas: Add a couple of trace points

2018-03-19 Thread Michael Ellerman 
On Sat, 2018-02-10 at 03:49:27 UTC, Sukadev Bhattiprolu wrote:
> Add a couple of trace points in the VAS driver
> 
> Signed-off-by: Sukadev Bhattiprolu 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/007bb7d6c77ef2243dabf9c4132afa

cheers

Re: powerpc/npu-dma.c: Fix crash after __mmu_notifier_register failure

2018-03-19 Thread Michael Ellerman 
On Sat, 2018-02-10 at 03:20:06 UTC, Mark Hairgrove wrote:
> pnv_npu2_init_context wasn't checking the return code from
> __mmu_notifier_register. If  __mmu_notifier_register failed, the
> npu_context was still assigned to the mm and the caller wasn't given any
> indication that things went wrong. Later on pnv_npu2_destroy_context would
> be called, which in turn called mmu_notifier_unregister and dropped
> mm->mm_count without having incremented it in the first place. This led to
> various forms of corruption like mm use-after-free and mm double-free.
> 
> __mmu_notifier_register can fail with EINTR if a signal is pending, so
> this case can be frequent.
> 
> This patch calls opal_npu_destroy_context on the failure paths, and makes
> sure not to assign mm->context.npu_context until past the failure points.
> 
> Signed-off-by: Mark Hairgrove 
> Acked-By: Alistair Popple 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/720c84046c26444fe825f8614ddceb

cheers

Re: [v6, 1/2] raid6/altivec: Add vpermxor implementation for raid6 Q syndrome

2018-03-19 Thread Michael Ellerman 
On Fri, 2017-08-04 at 03:42:32 UTC, Matt Brown wrote:
> This patch uses the vpermxor instruction to optimise the raid6 Q syndrome.
> This instruction was made available with POWER8, ISA version 2.07.
> It allows for both vperm and vxor instructions to be done in a single
> instruction. This has been tested for correctness on a ppc64le vm with a
> basic RAID6 setup containing 5 drives.
> 
> The performance benchmarks are from the raid6test in the /lib/raid6/test
> directory. These results are from an IBM Firestone machine with ppc64le
> architecture. The benchmark results show a 35% speed increase over the best
> existing algorithm for powerpc (altivec). The raid6test has also been run
> on a big-endian ppc64 vm to ensure it also works for big-endian
> architectures.
> 
> Performance benchmarks:
>   raid6: altivecx4 gen() 18773 MB/s
>   raid6: altivecx8 gen() 19438 MB/s
> 
>   raid6: vpermxor4 gen() 25112 MB/s
>   raid6: vpermxor8 gen() 26279 MB/s
> 
> Signed-off-by: Matt Brown 
> Reviewed-by: Daniel Axtens 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/2de95953c4e6ad54c9bee5e6a5518d

cheers

Re: powerpc/include/asm: Remove unused 64bit cacheflush function

2018-03-19 Thread Michael Ellerman 
On Thu, 2017-07-20 at 06:25:14 UTC, Matt Brown wrote:
> The flush_dcache_phys_range function is no longer used in the kernel.
> This patch removes and cleans up the function.
> 
> Signed-off-by: Matt Brown 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/1d82fc5c54ef7956f5c01bbcf26b52

cheers

[PATCH 3/3] powerpc: Free up CPU feature bits on 64-bit machines

2018-03-19 Thread Paul Mackerras 
This moves all the CPU feature bits that are only used on 32-bit
machines to the top 20 bits of the CPU feature word and arranges
for them to be defined only in 32-bit builds.  The features that
are common to 32-bit and 64-bit machines are moved to bits 0-11
of the CPU feature word.  This means that for 64-bit platforms,
bits 44-63 can now be used for new features that only exist on
64-bit machines.  (These bit numbers are counting from the right,
i.e. the LSB is bit 0.)

Because CPU_FTR_L3_DISABLE_NAP moved from the low 16 bits to the high
16 bits, we have to adjust some assembly code.  Also, CPU_FTR_EMB_HV
moved from the high 16 bits to the low 16 bits.

Note that CPU_FTR_REAL_LE only applies to 64-bit chips, because only
64-bit chips (POWER6, 7, 8, 9) have a true little-endian mode that is
a CPU execution mode as opposed to being a page attribute.

With this we now have 20 free CPU feature bits on 64-bit machines.

Signed-off-by: Paul Mackerras 
---
 arch/powerpc/include/asm/cputable.h   | 133 --
 arch/powerpc/kernel/cpu_setup_6xx.S   |   2 +-
 arch/powerpc/kernel/cpu_setup_fsl_booke.S |   2 +-
 3 files changed, 73 insertions(+), 64 deletions(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 761b99c..49fd067 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -131,40 +131,48 @@ static inline void cpu_feature_keys_init(void) { }
 
 /* CPU kernel features */
 
-/* Retain the 32b definitions all use bottom half of word */
+/* Definitions for features that we have on both 32-bit and 64-bit chips */
 #define CPU_FTR_COHERENT_ICACHEASM_CONST(0x0001)
-#define CPU_FTR_L2CR   ASM_CONST(0x0002)
-#define CPU_FTR_SPEC7450   ASM_CONST(0x0004)
-#define CPU_FTR_ALTIVECASM_CONST(0x0008)
-#define CPU_FTR_TAUASM_CONST(0x0010)
-#define CPU_FTR_CAN_DOZE   ASM_CONST(0x0020)
-#define CPU_FTR_USE_RTCASM_CONST(0x0040)
-#define CPU_FTR_601ASM_CONST(0x0100)
-#define CPU_FTR_DBELL  ASM_CONST(0x0200)
-#define CPU_FTR_CAN_NAPASM_CONST(0x0400)
-#define CPU_FTR_L3CR   ASM_CONST(0x0800)
-#define CPU_FTR_L3_DISABLE_NAP ASM_CONST(0x1000)
-#define CPU_FTR_NAP_DISABLE_L2_PR  ASM_CONST(0x2000)
-#define CPU_FTR_DUAL_PLL_750FX ASM_CONST(0x4000)
-#define CPU_FTR_NO_DPM ASM_CONST(0x8000)
-#define CPU_FTR_476_DD2ASM_CONST(0x0001)
-#define CPU_FTR_NEED_COHERENT  ASM_CONST(0x0002)
-#define CPU_FTR_NO_BTICASM_CONST(0x0004)
-#define CPU_FTR_DEBUG_LVL_EXC  ASM_CONST(0x0008)
-#define CPU_FTR_NODSISRALIGN   ASM_CONST(0x0010)
-#define CPU_FTR_PPC_LE ASM_CONST(0x0020)
-#define CPU_FTR_REAL_LEASM_CONST(0x0040)
-#define CPU_FTR_FPU_UNAVAILABLEASM_CONST(0x0080)
-#define CPU_FTR_UNIFIED_ID_CACHE   ASM_CONST(0x0100)
-#define CPU_FTR_SPEASM_CONST(0x0200)
-#define CPU_FTR_NEED_PAIRED_STWCX  ASM_CONST(0x0400)
-#define CPU_FTR_LWSYNC ASM_CONST(0x0800)
-#define CPU_FTR_NOEXECUTE  ASM_CONST(0x1000)
-#define CPU_FTR_INDEXED_DCRASM_CONST(0x2000)
-#define CPU_FTR_EMB_HV ASM_CONST(0x4000)
+#define CPU_FTR_ALTIVECASM_CONST(0x0002)
+#define CPU_FTR_DBELL  ASM_CONST(0x0004)
+#define CPU_FTR_CAN_NAPASM_CONST(0x0008)
+#define CPU_FTR_DEBUG_LVL_EXC  ASM_CONST(0x0010)
+#define CPU_FTR_NODSISRALIGN   ASM_CONST(0x0020)
+#define CPU_FTR_FPU_UNAVAILABLEASM_CONST(0x0040)
+#define CPU_FTR_LWSYNC ASM_CONST(0x0080)
+#define CPU_FTR_NOEXECUTE  ASM_CONST(0x0100)
+#define CPU_FTR_EMB_HV ASM_CONST(0x0200)
+
+/* Definitions for features that only exist on 32-bit chips */
+#ifdef CONFIG_PPC32
+#define CPU_FTR_601ASM_CONST(0x1000)
+#define CPU_FTR_L2CR   ASM_CONST(0x2000)
+#define CPU_FTR_SPEC7450   ASM_CONST(0x4000)
+#define CPU_FTR_TAUASM_CONST(0x8000)
+#define CPU_FTR_CAN_DOZE   ASM_CONST(0x0001)
+#define CPU_FTR_USE_RTCASM_CONST(0x0002)
+#define CPU_FTR_L3CR   ASM_CONST(0x0004)
+#define CPU_FTR_L3_DISABLE_NAP ASM_CONST(0x0008)
+#define CPU_FTR_NAP_DISABLE_L2_PR  ASM_CONST(0x0010)
+#define CPU_FTR_DUAL_PLL_750FX ASM_CONST(0x0020)
+#define CPU_FTR_NO_DPM ASM_CONST(0x0040)
+#define CPU_FTR_476_DD2

[PATCH 1/3] powerpc: Use feature bit for RTC presence rather than timebase presence

2018-03-19 Thread Paul Mackerras 
All PowerPC CPUs other than the original PPC601 have a timebase
register rather than the "real-time clock" (RTC) register that the
PPC601 (and the original POWER and POWER2 CPUs) had.  Currently
we have a CPU feature bit to indicate the presence of the timebase,
but it makes more sense to use a bit to indicate the unusual
situation rather than the common situation.  This therefore defines
a CPU_FTR_USE_RTC bit in place of the CPU_FTR_USE_TB bit, and
arranges for it to be set on PPC601 systems.

Signed-off-by: Paul Mackerras 
---
 arch/powerpc/include/asm/cputable.h | 85 +
 arch/powerpc/include/asm/time.h |  2 +-
 arch/powerpc/kernel/dt_cpu_ftrs.c   |  3 +-
 arch/powerpc/kernel/vdso.c  | 12 +++---
 4 files changed, 47 insertions(+), 55 deletions(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index a2c5c95..052db18 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -138,7 +138,7 @@ static inline void cpu_feature_keys_init(void) { }
 #define CPU_FTR_ALTIVECASM_CONST(0x0008)
 #define CPU_FTR_TAUASM_CONST(0x0010)
 #define CPU_FTR_CAN_DOZE   ASM_CONST(0x0020)
-#define CPU_FTR_USE_TB ASM_CONST(0x0040)
+#define CPU_FTR_USE_RTCASM_CONST(0x0040)
 #define CPU_FTR_L2CSR  ASM_CONST(0x0080)
 #define CPU_FTR_601ASM_CONST(0x0100)
 #define CPU_FTR_DBELL  ASM_CONST(0x0200)
@@ -285,21 +285,19 @@ static inline void cpu_feature_keys_init(void) { }
 #endif
 
 #define CPU_FTRS_PPC601(CPU_FTR_COMMON | CPU_FTR_601 | \
-   CPU_FTR_COHERENT_ICACHE | CPU_FTR_UNIFIED_ID_CACHE)
-#define CPU_FTRS_603   (CPU_FTR_COMMON | \
-   CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \
+   CPU_FTR_COHERENT_ICACHE | CPU_FTR_UNIFIED_ID_CACHE | CPU_FTR_USE_RTC)
+#define CPU_FTRS_603   (CPU_FTR_COMMON | CPU_FTR_MAYBE_CAN_DOZE | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_PPC_LE)
-#define CPU_FTRS_604   (CPU_FTR_COMMON | \
-   CPU_FTR_USE_TB | CPU_FTR_PPC_LE)
+#define CPU_FTRS_604   (CPU_FTR_COMMON | CPU_FTR_PPC_LE)
 #define CPU_FTRS_740_NOTAU (CPU_FTR_COMMON | \
-   CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
+   CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_L2CR | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_PPC_LE)
 #define CPU_FTRS_740   (CPU_FTR_COMMON | \
-   CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
+   CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_L2CR | \
CPU_FTR_TAU | CPU_FTR_MAYBE_CAN_NAP | \
CPU_FTR_PPC_LE)
 #define CPU_FTRS_750   (CPU_FTR_COMMON | \
-   CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
+   CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_L2CR | \
CPU_FTR_TAU | CPU_FTR_MAYBE_CAN_NAP | \
CPU_FTR_PPC_LE)
 #define CPU_FTRS_750CL (CPU_FTRS_750)
@@ -308,103 +306,96 @@ static inline void cpu_feature_keys_init(void) { }
 #define CPU_FTRS_750FX (CPU_FTRS_750 | CPU_FTR_DUAL_PLL_750FX)
 #define CPU_FTRS_750GX (CPU_FTRS_750FX)
 #define CPU_FTRS_7400_NOTAU(CPU_FTR_COMMON | \
-   CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
+   CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_L2CR | \
CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_PPC_LE)
 #define CPU_FTRS_7400  (CPU_FTR_COMMON | \
-   CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
+   CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_L2CR | \
CPU_FTR_TAU | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_PPC_LE)
 #define CPU_FTRS_7450_20   (CPU_FTR_COMMON | \
-   CPU_FTR_USE_TB | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
+   CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_L3CR | CPU_FTR_SPEC7450 | \
CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
 #define CPU_FTRS_7450_21   (CPU_FTR_COMMON | \
-   CPU_FTR_USE_TB | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_L3CR | CPU_FTR_SPEC7450 | \
CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_L3_DISABLE_NAP | \
CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE | CPU_FTR_NEED_PAIRED_STWCX)
 #define CPU_FTRS_7450_23   (CPU_FTR_COMMON | \
-   CPU_FTR_USE_TB | CPU_FTR_NEED_PAIRED_STWCX | \
+   CPU_FTR_NEED_PAIRED_STWCX | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_L3CR | CPU_FTR_SPEC7450 | \
CPU_FTR_NAP_DISABLE_L2_PR | CPU_FTR_NEED_COHERENT | CPU_FTR_PPC_LE)
 #define CPU_FTRS_7455_1(CPU_FTR_COMMON | \
-   CPU_FTR_USE_TB | CPU_FTR_NEED_PAIRED_STWCX | \
+   CPU_FTR_NEED_PAIRED_STWCX | \
CPU_FTR_L2CR | CPU_FTR_ALTIVEC_COMP | CPU_FTR_L3CR | \

[PATCH 2/3] powerpc: Book E: Remove unused CPU_FTR_L2CSR bit

2018-03-19 Thread Paul Mackerras 
The CPU_FTR_L2CSR bit is never tested anywhere, so let's reclaim the bit.

Signed-off-by: Paul Mackerras 
---
 arch/powerpc/include/asm/cputable.h | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 052db18..761b99c 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -139,7 +139,6 @@ static inline void cpu_feature_keys_init(void) { }
 #define CPU_FTR_TAUASM_CONST(0x0010)
 #define CPU_FTR_CAN_DOZE   ASM_CONST(0x0020)
 #define CPU_FTR_USE_RTCASM_CONST(0x0040)
-#define CPU_FTR_L2CSR  ASM_CONST(0x0080)
 #define CPU_FTR_601ASM_CONST(0x0100)
 #define CPU_FTR_DBELL  ASM_CONST(0x0200)
 #define CPU_FTR_CAN_NAPASM_CONST(0x0400)
@@ -385,18 +384,18 @@ static inline void cpu_feature_keys_init(void) { }
CPU_FTR_SPE_COMP | CPU_FTR_MAYBE_CAN_NAP | \
CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE)
 #define CPU_FTRS_E500MC(CPU_FTR_NODSISRALIGN | \
-   CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
+   CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
CPU_FTR_DBELL | CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV)
 /*
  * e5500/e6500 erratum A-006958 is a timebase bug that can use the
  * same workaround as CPU_FTR_CELL_TB_BUG.
  */
 #define CPU_FTRS_E5500 (CPU_FTR_NODSISRALIGN | \
-   CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
+   CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \
CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV | CPU_FTR_CELL_TB_BUG)
 #define CPU_FTRS_E6500 (CPU_FTR_NODSISRALIGN | \
-   CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
+   CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \
CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV | CPU_FTR_ALTIVEC_COMP | \
CPU_FTR_CELL_TB_BUG | CPU_FTR_SMT)
-- 
2.7.4

[PATCH 0/3] powerpc: Free up CPU feature bits

2018-03-19 Thread Paul Mackerras 
This patch series is against the powerpc next branch.  It takes
advantage of the fact that there are only a few CPU feature bits that
are meaningful on both 32-bit and 64-bit platforms.  At the moment,
many of the 64 bits of the CPU feature mask on 64-bit platforms are
taken up with bits which are only relevant to 32-bit platforms.  This
series rearranges things so that we can use those bits for new
features that are relevant only to 64-bit platforms.  With this, there
are now 20 bits available for new 64-bit features.

To make things simpler, we use the bottom 12 bits of the CPU feature
word for features that are relevant to both 32-bit and 64-bit
platforms.  The remaining 20 or 52 bits are then available for
features specific to 32-bit or 64-bit platforms.

Paul.

 arch/powerpc/include/asm/cputable.h   | 223 +++---
 arch/powerpc/include/asm/time.h   |   2 +-
 arch/powerpc/kernel/cpu_setup_6xx.S   |   2 +-
 arch/powerpc/kernel/cpu_setup_fsl_booke.S |   2 +-
 arch/powerpc/kernel/dt_cpu_ftrs.c |   3 +-
 arch/powerpc/kernel/vdso.c|  12 +-
 6 files changed, 122 insertions(+), 122 deletions(-)

Re: [PATCHv5 1/3] powerpc, cpu: partially unbind the mapping between cpu logical id and its seq in dt

2018-03-19 Thread kbuild test robot 
Hi Pingfan,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on v4.16-rc4]
[also build test ERROR on next-20180319]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Pingfan-Liu/enable-nr_cpus-for-powerpc/20180318-041117
config: powerpc-tqm8548_defconfig (attached as .config)
compiler: powerpc-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

>> arch/powerpc/kernel/prom.c:79:23: error: 'boot_cpu_count' defined but not 
>> used [-Werror=unused-variable]
static int __initdata boot_cpu_count;
  ^~
   cc1: all warnings being treated as errors

vim +/boot_cpu_count +79 arch/powerpc/kernel/prom.c

9b6b563c Paul Mackerras 2005-10-06  71  
9b6b563c Paul Mackerras 2005-10-06  72  #ifdef CONFIG_PPC64
28897731 Olof Johansson 2006-04-12  73  int __initdata iommu_is_off;
9b6b563c Paul Mackerras 2005-10-06  74  int __initdata iommu_force_on;
cf00a8d1 Paul Mackerras 2005-10-31  75  unsigned long tce_alloc_start, 
tce_alloc_end;
cd3db0c4 Benjamin Herrenschmidt 2010-07-06  76  u64 ppc64_rma_size;
9b6b563c Paul Mackerras 2005-10-06  77  #endif
03bf469a Benjamin Herrenschmidt 2011-05-11  78  static phys_addr_t 
first_memblock_size;
7ac87abb Matt Evans 2011-05-25 @79  static int __initdata 
boot_cpu_count;
9b6b563c Paul Mackerras 2005-10-06  80  

:: The code at line 79 was first introduced by commit
:: 7ac87abb8166b99584149fcfb2efef5773a078e9 powerpc: Fix early boot 
accounting of CPUs

:: TO: Matt Evans <m...@ozlabs.org>
:: CC: Benjamin Herrenschmidt <b...@kernel.crashing.org>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 1/1] PCI set flag PCI_SCAN_ALL_PCIE_DEVS for P.A. Semi boards

2018-03-19 Thread Christian Zigotzky 
Hello Bjorn,

Thanks for your reply. Olof wrote this patch.

@Olof
Could you please sign off this patch?

Thanks,
Christian

On 19. Mar 2018, at 20:13, Bjorn Helgaas  wrote:

The patch looks fine, but I need a signed-off-by line before I can apply
it.  See 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst

---

arch/powerpc/platforms/pasemi/pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/platforms/pasemi/pci.c
b/arch/powerpc/platforms/pasemi/pci.c
index 5ff6108..ea54ed2 100644
--- a/arch/powerpc/platforms/pasemi/pci.c
+++ b/arch/powerpc/platforms/pasemi/pci.c
@@ -224,6 +224,8 @@ void __init pas_pci_init(void)
 return;
 }

+pci_set_flags(PCI_SCAN_ALL_PCIE_DEVS);
+
 for (np = NULL; (np = of_get_next_child(root, np)) != NULL;)
 if (np->name && !strcmp(np->name, "pxp") && !pas_add_bridge(np))
 of_node_get(np);

--

Re: [GIT PULL 00/14] perf/core improvements and fixes

2018-03-19 Thread Ingo Molnar 

* Arnaldo Carvalho de Melo <a...@kernel.org> wrote:

> Hi Ingo,
> 
>   Please consider pulling, this has those 31 patches that were
> blocked due to some problems (author not being the fist S-o-B, build
> broken on ppc), those issues should all be fixed and then we have 14
> patches more, described in the signed tag.
> 
> Regards,
> 
> - Arnaldo
> 
> Test results at the end of this message, as usual.
> 
> The following changes since commit 10f354a36f9a9aa1b8bffe0abc1cd43822a85bcd:
> 
>   perf test: Fix exit code for record+probe_libc_inet_pton.sh (2018-03-16 
> 13:56:31 -0300)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-core-for-mingo-4.17-20180319
> 
> for you to fetch changes up to 1cd618838b9703eabe4a75badf433382b12f6bef:
> 
>   perf tests bp_account: Fix build with clang-6 (2018-03-19 13:51:54 -0300)
> 
> 
> perf/core improvements and fixes:
> 
> - Fixes for problems experienced with new gcc 8 warnings, that treated
>   as errors, broke the build, related to snprintf and casting issues.
>   (Arnaldo Carvalho de Melo, Jiri Olsa, Josh Poinboeuf)
> 
> - Fix build of new breakpoint 'perf test' entry with clang < 6, noticed
>   on fedora 25, 26 and 27 (Arnaldo Carvalho de Melo)
> 
> - Workaround problem with symbol resolution in 'perf annotate', using
>   the symbol name already present in the objdump output (Arnaldo Carvalho de 
> Melo)
> 
> - Document 'perf top --ignore-vmlinux' (Arnaldo Carvalho de Melo)
> 
> - Fix out of bounds access on array fd when cnt is 100 in one of the
>   'perf test' entries, detected using 'cpptest' (Colin Ian King)
> 
> - Add support for the forced leader feature, i.e. 'perf report --group'
>   for a group of events not really grouped when scheduled (without using
>   {} to enclose the list of events in the command line) in pipe mode,
>   e.g.:
> 
>   $ perf record -e cycles,instructions -o - kill | perf report --group -i -
> 
> - Use right type to access array elements in 'perf probe' (Masami Hiramatsu)
> 
> - Update POWER9 vendor events (those described in JSON format) (Sukadev 
> Bhattiprolu)
> 
> - Discard head in overwrite_rb_find_range() (Yisheng Xie)
> 
> - Avoid setting 'quiet' to 'true' unnecessarily (Yisheng Xie)
> 
> Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
> 
> 
> Arnaldo Carvalho de Melo (4):
>   perf annotate: Use asprintf when formatting objdump command line
>   perf top: Document --ignore-vmlinux
>   perf annotate: Use ops->target.name when available for unresolved call 
> targets
>   perf tests bp_account: Fix build with clang-6
> 
> Colin Ian King (1):
>   perf tests: Fix out of bounds access on array fd when cnt is 100
> 
> Jiri Olsa (4):
>   perf record: Synthesize features before events in pipe mode
>   perf report: Support forced leader feature in pipe mode
>   perf tools: Fix snprint warnings for gcc 8
>   perf tools: Fix python extension build for gcc 8
> 
> Josh Poimboeuf (1):
>   objtool, perf: Fix GCC 8 -Wrestrict error
> 
> Masami Hiramatsu (1):
>   perf probe: Use right type to access array elements
> 
> Sukadev Bhattiprolu (1):
>   perf vendor events: Update POWER9 events
> 
> Yisheng Xie (2):
>   perf mmap: Discard head in overwrite_rb_find_range()
>   perf debug: Avoid setting 'quiet' to 'true' unnecessarily
> 
>  tools/lib/str_error_r.c|   2 +-
>  tools/perf/Documentation/perf-top.txt  |   3 +
>  tools/perf/builtin-record.c|  18 +-
>  tools/perf/builtin-report.c|  57 +++--
>  tools/perf/builtin-script.c|  22 +-
>  .../perf/pmu-events/arch/powerpc/power9/cache.json |  25 ---
>  .../pmu-events/arch/powerpc/power9/frontend.json   |  10 -
>  .../pmu-events/arch/powerpc/power9/marked.json |   5 -
>  .../pmu-events/arch/powerpc/power9/memory.json |   5 -
>  .../perf/pmu-events/arch/powerpc/power9/other.json | 241 
> ++---
>  .../pmu-events/arch/powerpc/power9/pipeline.json   |  50 ++---
>  tools/perf/pmu-events/arch/powerpc/power9/pmc.json |   5 -
>  .../arch/powerpc/power9/translation.json   |  10 +-
>  tools/perf/tests/attr.c|   4 +-
>  tools/perf/tests/bp_account.c  |  10 +-
>  tools/perf/tests/mem.c |   2 +-
>  tools/perf/tests/pmu.c |   2 +-
>  tools/perf/ut

Re: [PATCH 1/1] PCI set flag PCI_SCAN_ALL_PCIE_DEVS for P.A. Semi boards

2018-03-19 Thread Bjorn Helgaas 
On Fri, Mar 16, 2018 at 01:55:36PM +0100, Christian Zigotzky wrote:
> Bjorn Helgaas created a patch for making PCI_SCAN_ALL_PCIE_DEVS work for
> Root Ports as well as Downstream. Previously PCI_SCAN_ALL_PCIE_DEVS (set by
> quirks or the "pci=pcie_scan_all"
> kernel parameter) only affected Switch Downstream Ports, not Root Ports. The
> problem is, that we have to add always the boot argument "pci=pcie_scan_all"
> for using Bjorn's improvements. Without the boot argument
> "pci=pcie_scan_all", the kernel doesn't boot on P.A. Semi boards with SB600
> chipset (SB600 chipset is connected via PCIe x4 to the P.A. Semi’s
> PA6T-1682M System-on-a-Chip) because the kernel can't find any drives
> connected to the SB600 anymore. Olof Johansson has created a patch for
> executing "pci=pcie_scan_all" automatically on P.A. Semi boards. With his
> patch, we don't need to add 'pci=pcie_scan_all' to the kernel boot arguments
> anymore.

The patch looks fine, but I need a signed-off-by line before I can apply
it.  See 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst

> ---
> 
> arch/powerpc/platforms/pasemi/pci.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/powerpc/platforms/pasemi/pci.c
> b/arch/powerpc/platforms/pasemi/pci.c
> index 5ff6108..ea54ed2 100644
> --- a/arch/powerpc/platforms/pasemi/pci.c
> +++ b/arch/powerpc/platforms/pasemi/pci.c
> @@ -224,6 +224,8 @@ void __init pas_pci_init(void)
>      return;
>  }
> 
> +    pci_set_flags(PCI_SCAN_ALL_PCIE_DEVS);
> +
>  for (np = NULL; (np = of_get_next_child(root, np)) != NULL;)
>      if (np->name && !strcmp(np->name, "pxp") && !pas_add_bridge(np))
>          of_node_get(np);
> 
> --
> 
>

[PATCH 05/14] perf vendor events: Update POWER9 events

2018-03-19 Thread Arnaldo Carvalho de Melo 
From: Sukadev Bhattiprolu 

Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Sukadev Bhattiprolu 
Link: https://lkml.kernel.org/r/20180313224647.ga22...@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../perf/pmu-events/arch/powerpc/power9/cache.json |  25 ---
 .../pmu-events/arch/powerpc/power9/frontend.json   |  10 -
 .../pmu-events/arch/powerpc/power9/marked.json |   5 -
 .../pmu-events/arch/powerpc/power9/memory.json |   5 -
 .../perf/pmu-events/arch/powerpc/power9/other.json | 241 ++---
 .../pmu-events/arch/powerpc/power9/pipeline.json   |  50 ++---
 tools/perf/pmu-events/arch/powerpc/power9/pmc.json |   5 -
 .../arch/powerpc/power9/translation.json   |  10 +-
 8 files changed, 178 insertions(+), 173 deletions(-)

diff --git a/tools/perf/pmu-events/arch/powerpc/power9/cache.json 
b/tools/perf/pmu-events/arch/powerpc/power9/cache.json
index 7945c5196c43..851072105054 100644
--- a/tools/perf/pmu-events/arch/powerpc/power9/cache.json
+++ b/tools/perf/pmu-events/arch/powerpc/power9/cache.json
@@ -19,11 +19,6 @@
 "EventName": "PM_CMPLU_STALL_FXU",
 "BriefDescription": "Finish stall due to a scalar fixed point or CR 
instruction in the execution pipeline. These instructions get routed to the 
ALU, ALU2, and DIV pipes"
   },
-  {,
-"EventCode": "0x1D15C",
-"EventName": "PM_MRK_DTLB_MISS_1G",
-"BriefDescription": "Marked Data TLB reload (after a miss) page size 2M. 
Implies radix translation was used"
-  },
   {,
 "EventCode": "0x4D12A",
 "EventName": "PM_MRK_DATA_FROM_RL4_CYC",
@@ -79,21 +74,6 @@
 "EventName": "PM_THRESH_EXC_4096",
 "BriefDescription": "Threshold counter exceed a count of 4096"
   },
-  {,
-"EventCode": "0x3D156",
-"EventName": "PM_MRK_DTLB_MISS_64K",
-"BriefDescription": "Marked Data TLB Miss page size 64K"
-  },
-  {,
-"EventCode": "0x4C15E",
-"EventName": "PM_MRK_DTLB_MISS_16M",
-"BriefDescription": "Marked Data TLB Miss page size 16M"
-  },
-  {,
-"EventCode": "0x2D15E",
-"EventName": "PM_MRK_DTLB_MISS_16G",
-"BriefDescription": "Marked Data TLB Miss page size 16G"
-  },
   {,
 "EventCode": "0x3F14A",
 "EventName": "PM_MRK_DPTEG_FROM_RMEM",
@@ -123,10 +103,5 @@
 "EventCode": "0x1002A",
 "EventName": "PM_CMPLU_STALL_LARX",
 "BriefDescription": "Finish stall because the NTF instruction was a larx 
waiting to be satisfied"
-  },
-  {,
-"EventCode": "0x1C058",
-"EventName": "PM_DTLB_MISS_16G",
-"BriefDescription": "Data TLB Miss page size 16G"
   }
 ]
\ No newline at end of file
diff --git a/tools/perf/pmu-events/arch/powerpc/power9/frontend.json 
b/tools/perf/pmu-events/arch/powerpc/power9/frontend.json
index bd8361b5fd6a..f9fa84b16fb5 100644
--- a/tools/perf/pmu-events/arch/powerpc/power9/frontend.json
+++ b/tools/perf/pmu-events/arch/powerpc/power9/frontend.json
@@ -154,11 +154,6 @@
 "EventName": "PM_MRK_DATA_FROM_RL2L3_SHR_CYC",
 "BriefDescription": "Duration in cycles to reload with Shared (S) data 
from another chip's L2 or L3 on the same Node or Group (Remote), as this chip 
due to a marked load"
   },
-  {,
-"EventCode": "0x3C056",
-"EventName": "PM_DTLB_MISS_64K",
-"BriefDescription": "Data TLB Miss page size 64K"
-  },
   {,
 "EventCode": "0x30060",
 "EventName": "PM_TM_TRANS_RUN_INST",
@@ -344,11 +339,6 @@
 "EventName": "PM_MRK_LARX_FIN",
 "BriefDescription": "Larx finished"
   },
-  {,
-"EventCode": "0x4C056",
-"EventName": "PM_DTLB_MISS_16M",
-"BriefDescription": "Data TLB Miss page size 16M"
-  },
   {,
 "EventCode": "0x1003A",
 "EventName": "PM_CMPLU_STALL_LSU_FIN",
diff --git a/tools/perf/pmu-events/arch/powerpc/power9/marked.json 
b/tools/perf/pmu-events/arch/powerpc/power9/marked.json
index 22f9f32060a8..b1954c38bab1 100644
--- a/tools/perf/pmu-events/arch/powerpc/power9/marked.json
+++ b/tools/perf/pmu-events/arch/powerpc/power9/marked.json
@@ -529,11 +529,6 @@
 "EventName": "PM_L1_ICACHE_RELOADED_ALL",
 "BriefDescription": "Counts all Icache reloads includes demand, prefetch, 
prefetch turned into demand and demand turned into prefetch"
   },
-  {,
-"EventCode": "0x4003C",
-"EventName": "PM_DISP_HELD_SYNC_HOLD",
-"BriefDescription": "Cycles in which dispatch is held because of a 
synchronizing instruction in the pipeline"
-  },
   {,
 "EventCode": "0x3003C",
 "EventName": "PM_CMPLU_STALL_NESTED_TEND",
diff --git a/tools/perf/pmu-events/arch/powerpc/power9/memory.json 
b/tools/perf/pmu-events/arch/powerpc/power9/memory.json
index 9960d1c0dd44..2e2ebc700c74 100644
--- a/tools/perf/pmu-events/arch/powerpc/power9/memory.json
+++ b/tools/perf/pmu-events/arch/powerpc/power9/memory.json
@@ -44,11 +44,6 @@
 "EventName": "PM_LD_CMPL",
 "BriefDescription": "count of Loads completed"
   },
-  {,
-"EventCode": "0x2D156",
-"EventName": "PM_MRK_DTLB_MISS_4K",
-

[GIT PULL 00/14] perf/core improvements and fixes

2018-03-19 Thread Arnaldo Carvalho de Melo 
Hi Ingo,

Please consider pulling, this has those 31 patches that were
blocked due to some problems (author not being the fist S-o-B, build
broken on ppc), those issues should all be fixed and then we have 14
patches more, described in the signed tag.

Regards,

- Arnaldo

Test results at the end of this message, as usual.

The following changes since commit 10f354a36f9a9aa1b8bffe0abc1cd43822a85bcd:

  perf test: Fix exit code for record+probe_libc_inet_pton.sh (2018-03-16 
13:56:31 -0300)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
tags/perf-core-for-mingo-4.17-20180319

for you to fetch changes up to 1cd618838b9703eabe4a75badf433382b12f6bef:

  perf tests bp_account: Fix build with clang-6 (2018-03-19 13:51:54 -0300)


perf/core improvements and fixes:

- Fixes for problems experienced with new gcc 8 warnings, that treated
  as errors, broke the build, related to snprintf and casting issues.
  (Arnaldo Carvalho de Melo, Jiri Olsa, Josh Poinboeuf)

- Fix build of new breakpoint 'perf test' entry with clang < 6, noticed
  on fedora 25, 26 and 27 (Arnaldo Carvalho de Melo)

- Workaround problem with symbol resolution in 'perf annotate', using
  the symbol name already present in the objdump output (Arnaldo Carvalho de 
Melo)

- Document 'perf top --ignore-vmlinux' (Arnaldo Carvalho de Melo)

- Fix out of bounds access on array fd when cnt is 100 in one of the
  'perf test' entries, detected using 'cpptest' (Colin Ian King)

- Add support for the forced leader feature, i.e. 'perf report --group'
  for a group of events not really grouped when scheduled (without using
  {} to enclose the list of events in the command line) in pipe mode,
  e.g.:

  $ perf record -e cycles,instructions -o - kill | perf report --group -i -

- Use right type to access array elements in 'perf probe' (Masami Hiramatsu)

- Update POWER9 vendor events (those described in JSON format) (Sukadev 
Bhattiprolu)

- Discard head in overwrite_rb_find_range() (Yisheng Xie)

- Avoid setting 'quiet' to 'true' unnecessarily (Yisheng Xie)

Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>


Arnaldo Carvalho de Melo (4):
  perf annotate: Use asprintf when formatting objdump command line
  perf top: Document --ignore-vmlinux
  perf annotate: Use ops->target.name when available for unresolved call 
targets
  perf tests bp_account: Fix build with clang-6

Colin Ian King (1):
  perf tests: Fix out of bounds access on array fd when cnt is 100

Jiri Olsa (4):
  perf record: Synthesize features before events in pipe mode
  perf report: Support forced leader feature in pipe mode
  perf tools: Fix snprint warnings for gcc 8
  perf tools: Fix python extension build for gcc 8

Josh Poimboeuf (1):
  objtool, perf: Fix GCC 8 -Wrestrict error

Masami Hiramatsu (1):
  perf probe: Use right type to access array elements

Sukadev Bhattiprolu (1):
  perf vendor events: Update POWER9 events

Yisheng Xie (2):
  perf mmap: Discard head in overwrite_rb_find_range()
  perf debug: Avoid setting 'quiet' to 'true' unnecessarily

 tools/lib/str_error_r.c|   2 +-
 tools/perf/Documentation/perf-top.txt  |   3 +
 tools/perf/builtin-record.c|  18 +-
 tools/perf/builtin-report.c|  57 +++--
 tools/perf/builtin-script.c|  22 +-
 .../perf/pmu-events/arch/powerpc/power9/cache.json |  25 ---
 .../pmu-events/arch/powerpc/power9/frontend.json   |  10 -
 .../pmu-events/arch/powerpc/power9/marked.json |   5 -
 .../pmu-events/arch/powerpc/power9/memory.json |   5 -
 .../perf/pmu-events/arch/powerpc/power9/other.json | 241 ++---
 .../pmu-events/arch/powerpc/power9/pipeline.json   |  50 ++---
 tools/perf/pmu-events/arch/powerpc/power9/pmc.json |   5 -
 .../arch/powerpc/power9/translation.json   |  10 +-
 tools/perf/tests/attr.c|   4 +-
 tools/perf/tests/bp_account.c  |  10 +-
 tools/perf/tests/mem.c |   2 +-
 tools/perf/tests/pmu.c |   2 +-
 tools/perf/util/annotate.c |  20 +-
 tools/perf/util/cgroup.c   |   2 +-
 tools/perf/util/debug.c|   1 -
 tools/perf/util/header.c   |  11 +-
 tools/perf/util/mmap.c |  15 +-
 tools/perf/util/parse-events.c |   4 +-
 tools/perf/util/pmu.c  |   2 +-
 tools/perf/util/probe-finder.c |  13 +-
 tools/perf/util/setup.py   |   2 +
 26 files changed, 298 insertions(+), 243 deletions(-)

Test results:

The first ones are container (d

Re: [PATCH 1/2] powerpc64/ftrace: Add a field in paca to disable ftrace in unsafe code paths

2018-03-19 Thread Naveen N. Rao 

Steven Rostedt wrote:

On Mon, 19 Mar 2018 14:43:00 +0530
"Naveen N. Rao"  wrote:


diff --git a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S 
b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
index 3f3e81852422..fdf702b4df25 100644
--- a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
+++ b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
@@ -60,6 +60,19 @@ _GLOBAL(ftrace_caller)
mfxer   r10
mfcrr11
 
+#ifdef CONFIG_KVM

+   lbz r3, PACA_FTRACE_DISABLED(r13)
+   cmpdi   r3, 0
+   beq 1f
+   mflrr3
+   mtctr   r3
+   REST_GPR(3, r1)
+   addir1, r1, SWITCH_FRAME_SIZE
+   mtlrr0
+   bctr
+1:
+#endif


I wonder if we should try to move the return out of the fast path (for
cache reasons), as most of the time the above compare will be true. That
is:

#ifdef CONFIG_KVM
lbz r3, PACA_FTRACE_DISABLED(r13)
cmpdi   r3, 0
bne no_trace
#endif

/* rest of ftrace_caller code */

/* after ftrace_caller... */
bctr/* jump after _mcount site */

#ifdef  CONFIG_KVM
no_trace:
mflrr3
mtctr   r3
REST_GPR(3, r1)
addir1, r1, SWITCH_FRAME_SIZE
mtlrr0
bctr
#endif


Thanks, I'll incorporate those changes in my next version.

- Naveen

Re: [PATCH 1/2] powerpc64/ftrace: Add a field in paca to disable ftrace in unsafe code paths

2018-03-19 Thread Naveen N. Rao 

Nicholas Piggin wrote:

On Mon, 19 Mar 2018 14:43:00 +0530
"Naveen N. Rao"  wrote:


We have some C code that we call into from real mode where we cannot
take any exceptions. Though the C functions themselves are mostly safe,
if these functions are traced, there is a possibility that we may take
an exception. For instance, in certain conditions, the ftrace code uses
WARN(), which uses a 'trap' to do its job.

For such scenarios, introduce a new field in paca 'ftrace_disabled',
which is checked on ftrace entry before continuing. This field can then
be set to a non-zero value to disable/pause ftrace, and reset to zero to
resume ftrace.

Since KVM is the only user for this currently, we guard the
ftrace/mcount checks within CONFIG_KVM. This can later be removed
if/when there are other users.


Why not test HSTATE_IN_GUEST then? Add ftrace_disabled if non-KVM users
come along.


That's indeed simpler -- thanks for the suggestion!

- Naveen

Re: [PATCH] powerpc/boot: Remove duplicate typedefs from libfdt_env.h

2018-03-19 Thread christophe leroy 



Le 19/03/2018 à 17:02, Mark Greer a écrit :

On Mon, Mar 19, 2018 at 09:53:09AM +0100, Christophe LEROY wrote:



Le 16/03/2018 à 22:54, Mark Greer a écrit :

When building a uImage or zImage using ppc6xx_defconfig and some other
defconfigs, the following error occurs:

   BOOTCC  arch/powerpc/boot/fdt.o
   In file included from arch/powerpc/boot/fdt.c:51:0:
   ../arch/powerpc/boot/libfdt_env.h:10:13: error: redefinition of typedef 
'uint32_t'
   ../arch/powerpc/boot/types.h:21:13: note: previous declaration of 'uint32_t' 
was here
   ../arch/powerpc/boot/libfdt_env.h:11:13: error: redefinition of typedef 
'uint64_t'
   ../arch/powerpc/boot/types.h:22:13: note: previous declaration of 'uint64_t' 
was here
   ../arch/powerpc/boot/Makefile:210: recipe for target 
'arch/powerpc/boot/fdt.o' failed
   make[2]: *** [arch/powerpc/boot/fdt.o] Error 1

The problem is that commit 656ad58ef19e (powerpc/boot: Add OPAL console
to epapr wrappers) adds typedefs for uint32_t and uint64_t to type.h but
doesn't remove the pre-existing (and now duplicate) typedefs from
libfdt_env.h.  Fix the error by removing the duplicat typedefs from
libfdt_env.h

CC: David Gibson 
CC: Oliver O'Halloran 
Signed-off-by: Mark Greer 
---
Having said all of that, commit 656ad58ef19e (powerpc/boot: Add OPAL
console to epapr wrappers) went into mainline back in 2016 so, AFAICT,
this has been broken since then.  That seems unlikely so I must be
missing something...  Any ideas what that is?


I just compiled uImage for ppc6xx_defconfig, and I don't get such error.
I looked at what gcc -E outputs, u32 is defined twice but it doesn't seems
to bother GCC.

What version of GCC do you use ?
I tried with 5.4.0 and 4.6.3, both seems to work.

Christophe


Hi Christophe.

That's interesting.  I would expect an error regardless of version.

I used an old 4.5.1 gcc that I had laying around (from denx, iirc).
I'll find a newer one and try it.

Either way, it seems to me that we should remove the duplicate definitions.
Do you agree?


Yes I agree. I was however intrigued by your statement that compilation 
should have been broken since 2016.


Christophe



Thanks,

Mark
--



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

[PATCH AUTOSEL for 3.18 101/102] signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP

2018-03-19 Thread Sasha Levin 
From: "Eric W. Biederman" 

[ Upstream commit cf4674c46c66e45f238f8f7e81af2a444b970c0a ]

Setting si_code to 0 results in a userspace seeing an si_code of 0.
This is the same si_code as SI_USER.  Posix and common sense requires
that SI_USER not be a signal specific si_code.  As such this use of 0
for the si_code is a pretty horribly broken ABI.

Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
value of __SI_KILL and now sees a value of SIL_KILL with the result
that uid and pid fields are copied and which might copying the si_addr
field by accident but certainly not by design.  Making this a very
flakey implementation.

Utilizing FPE_FIXME and TRAP_FIXME, siginfo_layout() will now return
SIL_FAULT and the appropriate fields will be reliably copied.

Possible ABI fixes includee:
- Send the signal without siginfo
- Don't generate a signal
- Possibly assign and use an appropriate si_code
- Don't handle cases which can't happen
Cc: Paul Mackerras 
Cc: Kumar Gala 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc:  linuxppc-dev@lists.ozlabs.org
Ref: 9bad068c24d7 ("[PATCH] ppc32: support for e500 and 85xx")
Ref: 0ed70f6105ef ("PPC32: Provide proper siginfo information on various 
exceptions.")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/include/uapi/asm/siginfo.h | 15 +++
 arch/powerpc/kernel/traps.c | 10 +-
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/uapi/asm/siginfo.h 
b/arch/powerpc/include/uapi/asm/siginfo.h
index ccce3ef5cd86..9c437eaf7c21 100644
--- a/arch/powerpc/include/uapi/asm/siginfo.h
+++ b/arch/powerpc/include/uapi/asm/siginfo.h
@@ -17,4 +17,19 @@
 #undef NSIGTRAP
 #define NSIGTRAP   4
 
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME  0   /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+/*
+ * SIGTRAP si_codes
+ */
+#ifdef __KERNEL__
+#define TRAP_FIXME 0   /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+
 #endif /* _ASM_POWERPC_SIGINFO_H */
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 0dc43f9932cf..6cc0280a8ae0 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -769,7 +769,7 @@ void unknown_exception(struct pt_regs *regs)
printk("Bad trap at PC: %lx, SR: %lx, vector=%lx\n",
   regs->nip, regs->msr, regs->trap);
 
-   _exception(SIGTRAP, regs, 0, 0);
+   _exception(SIGTRAP, regs, TRAP_FIXME, 0);
 
exception_exit(prev_state);
 }
@@ -791,7 +791,7 @@ void instruction_breakpoint_exception(struct pt_regs *regs)
 
 void RunModeException(struct pt_regs *regs)
 {
-   _exception(SIGTRAP, regs, 0, 0);
+   _exception(SIGTRAP, regs, TRAP_FIXME, 0);
 }
 
 void __kprobes single_step_exception(struct pt_regs *regs)
@@ -826,7 +826,7 @@ static void emulate_single_step(struct pt_regs *regs)
 
 static inline int __parse_fpscr(unsigned long fpscr)
 {
-   int ret = 0;
+   int ret = FPE_FIXME;
 
/* Invalid operation */
if ((fpscr & FPSCR_VE) && (fpscr & FPSCR_VX))
@@ -1742,7 +1742,7 @@ void SPEFloatingPointException(struct pt_regs *regs)
extern int do_spe_mathemu(struct pt_regs *regs);
unsigned long spefscr;
int fpexc_mode;
-   int code = 0;
+   int code = FPE_FIXME;
int err;
 
flush_spe_to_thread(current);
@@ -1811,7 +1811,7 @@ void SPEFloatingPointRoundException(struct pt_regs *regs)
printk(KERN_ERR "unrecognized spe instruction "
   "in %s at %lx\n", current->comm, regs->nip);
} else {
-   _exception(SIGFPE, regs, 0, regs->nip);
+   _exception(SIGFPE, regs, FPE_FIXME, regs->nip);
return;
}
 }
-- 
2.14.1

[PATCH AUTOSEL for 4.4 166/167] signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP

2018-03-19 Thread Sasha Levin 
From: "Eric W. Biederman" 

[ Upstream commit cf4674c46c66e45f238f8f7e81af2a444b970c0a ]

Setting si_code to 0 results in a userspace seeing an si_code of 0.
This is the same si_code as SI_USER.  Posix and common sense requires
that SI_USER not be a signal specific si_code.  As such this use of 0
for the si_code is a pretty horribly broken ABI.

Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
value of __SI_KILL and now sees a value of SIL_KILL with the result
that uid and pid fields are copied and which might copying the si_addr
field by accident but certainly not by design.  Making this a very
flakey implementation.

Utilizing FPE_FIXME and TRAP_FIXME, siginfo_layout() will now return
SIL_FAULT and the appropriate fields will be reliably copied.

Possible ABI fixes includee:
- Send the signal without siginfo
- Don't generate a signal
- Possibly assign and use an appropriate si_code
- Don't handle cases which can't happen
Cc: Paul Mackerras 
Cc: Kumar Gala 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc:  linuxppc-dev@lists.ozlabs.org
Ref: 9bad068c24d7 ("[PATCH] ppc32: support for e500 and 85xx")
Ref: 0ed70f6105ef ("PPC32: Provide proper siginfo information on various 
exceptions.")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/include/uapi/asm/siginfo.h | 15 +++
 arch/powerpc/kernel/traps.c | 10 +-
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/uapi/asm/siginfo.h 
b/arch/powerpc/include/uapi/asm/siginfo.h
index ccce3ef5cd86..9c437eaf7c21 100644
--- a/arch/powerpc/include/uapi/asm/siginfo.h
+++ b/arch/powerpc/include/uapi/asm/siginfo.h
@@ -17,4 +17,19 @@
 #undef NSIGTRAP
 #define NSIGTRAP   4
 
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME  0   /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+/*
+ * SIGTRAP si_codes
+ */
+#ifdef __KERNEL__
+#define TRAP_FIXME 0   /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+
 #endif /* _ASM_POWERPC_SIGINFO_H */
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index e4dcb0a43e3f..9ac9dfa6f796 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -771,7 +771,7 @@ void unknown_exception(struct pt_regs *regs)
printk("Bad trap at PC: %lx, SR: %lx, vector=%lx\n",
   regs->nip, regs->msr, regs->trap);
 
-   _exception(SIGTRAP, regs, 0, 0);
+   _exception(SIGTRAP, regs, TRAP_FIXME, 0);
 
exception_exit(prev_state);
 }
@@ -793,7 +793,7 @@ void instruction_breakpoint_exception(struct pt_regs *regs)
 
 void RunModeException(struct pt_regs *regs)
 {
-   _exception(SIGTRAP, regs, 0, 0);
+   _exception(SIGTRAP, regs, TRAP_FIXME, 0);
 }
 
 void __kprobes single_step_exception(struct pt_regs *regs)
@@ -828,7 +828,7 @@ static void emulate_single_step(struct pt_regs *regs)
 
 static inline int __parse_fpscr(unsigned long fpscr)
 {
-   int ret = 0;
+   int ret = FPE_FIXME;
 
/* Invalid operation */
if ((fpscr & FPSCR_VE) && (fpscr & FPSCR_VX))
@@ -1764,7 +1764,7 @@ void SPEFloatingPointException(struct pt_regs *regs)
extern int do_spe_mathemu(struct pt_regs *regs);
unsigned long spefscr;
int fpexc_mode;
-   int code = 0;
+   int code = FPE_FIXME;
int err;
 
flush_spe_to_thread(current);
@@ -1833,7 +1833,7 @@ void SPEFloatingPointRoundException(struct pt_regs *regs)
printk(KERN_ERR "unrecognized spe instruction "
   "in %s at %lx\n", current->comm, regs->nip);
} else {
-   _exception(SIGFPE, regs, 0, regs->nip);
+   _exception(SIGFPE, regs, FPE_FIXME, regs->nip);
return;
}
 }
-- 
2.14.1

[PATCH AUTOSEL for 4.9 279/281] signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP

2018-03-19 Thread Sasha Levin 
From: "Eric W. Biederman" 

[ Upstream commit cf4674c46c66e45f238f8f7e81af2a444b970c0a ]

Setting si_code to 0 results in a userspace seeing an si_code of 0.
This is the same si_code as SI_USER.  Posix and common sense requires
that SI_USER not be a signal specific si_code.  As such this use of 0
for the si_code is a pretty horribly broken ABI.

Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
value of __SI_KILL and now sees a value of SIL_KILL with the result
that uid and pid fields are copied and which might copying the si_addr
field by accident but certainly not by design.  Making this a very
flakey implementation.

Utilizing FPE_FIXME and TRAP_FIXME, siginfo_layout() will now return
SIL_FAULT and the appropriate fields will be reliably copied.

Possible ABI fixes includee:
- Send the signal without siginfo
- Don't generate a signal
- Possibly assign and use an appropriate si_code
- Don't handle cases which can't happen
Cc: Paul Mackerras 
Cc: Kumar Gala 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc:  linuxppc-dev@lists.ozlabs.org
Ref: 9bad068c24d7 ("[PATCH] ppc32: support for e500 and 85xx")
Ref: 0ed70f6105ef ("PPC32: Provide proper siginfo information on various 
exceptions.")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/include/uapi/asm/siginfo.h | 15 +++
 arch/powerpc/kernel/traps.c | 10 +-
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/uapi/asm/siginfo.h 
b/arch/powerpc/include/uapi/asm/siginfo.h
index ccce3ef5cd86..9c437eaf7c21 100644
--- a/arch/powerpc/include/uapi/asm/siginfo.h
+++ b/arch/powerpc/include/uapi/asm/siginfo.h
@@ -17,4 +17,19 @@
 #undef NSIGTRAP
 #define NSIGTRAP   4
 
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME  0   /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+/*
+ * SIGTRAP si_codes
+ */
+#ifdef __KERNEL__
+#define TRAP_FIXME 0   /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+
 #endif /* _ASM_POWERPC_SIGINFO_H */
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 43021f8e47a6..7e5b0bbbe4c8 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -793,7 +793,7 @@ void unknown_exception(struct pt_regs *regs)
printk("Bad trap at PC: %lx, SR: %lx, vector=%lx\n",
   regs->nip, regs->msr, regs->trap);
 
-   _exception(SIGTRAP, regs, 0, 0);
+   _exception(SIGTRAP, regs, TRAP_FIXME, 0);
 
exception_exit(prev_state);
 }
@@ -815,7 +815,7 @@ void instruction_breakpoint_exception(struct pt_regs *regs)
 
 void RunModeException(struct pt_regs *regs)
 {
-   _exception(SIGTRAP, regs, 0, 0);
+   _exception(SIGTRAP, regs, TRAP_FIXME, 0);
 }
 
 void single_step_exception(struct pt_regs *regs)
@@ -851,7 +851,7 @@ static void emulate_single_step(struct pt_regs *regs)
 
 static inline int __parse_fpscr(unsigned long fpscr)
 {
-   int ret = 0;
+   int ret = FPE_FIXME;
 
/* Invalid operation */
if ((fpscr & FPSCR_VE) && (fpscr & FPSCR_VX))
@@ -1855,7 +1855,7 @@ void SPEFloatingPointException(struct pt_regs *regs)
extern int do_spe_mathemu(struct pt_regs *regs);
unsigned long spefscr;
int fpexc_mode;
-   int code = 0;
+   int code = FPE_FIXME;
int err;
 
flush_spe_to_thread(current);
@@ -1924,7 +1924,7 @@ void SPEFloatingPointRoundException(struct pt_regs *regs)
printk(KERN_ERR "unrecognized spe instruction "
   "in %s at %lx\n", current->comm, regs->nip);
} else {
-   _exception(SIGFPE, regs, 0, regs->nip);
+   _exception(SIGFPE, regs, FPE_FIXME, regs->nip);
return;
}
 }
-- 
2.14.1

Re: [PATCH] powerpc/boot: Remove duplicate typedefs from libfdt_env.h

2018-03-19 Thread Mark Greer 
On Mon, Mar 19, 2018 at 09:53:09AM +0100, Christophe LEROY wrote:
> 
> 
> Le 16/03/2018 à 22:54, Mark Greer a écrit :
> >When building a uImage or zImage using ppc6xx_defconfig and some other
> >defconfigs, the following error occurs:
> >
> >   BOOTCC  arch/powerpc/boot/fdt.o
> >   In file included from arch/powerpc/boot/fdt.c:51:0:
> >   ../arch/powerpc/boot/libfdt_env.h:10:13: error: redefinition of typedef 
> > 'uint32_t'
> >   ../arch/powerpc/boot/types.h:21:13: note: previous declaration of 
> > 'uint32_t' was here
> >   ../arch/powerpc/boot/libfdt_env.h:11:13: error: redefinition of typedef 
> > 'uint64_t'
> >   ../arch/powerpc/boot/types.h:22:13: note: previous declaration of 
> > 'uint64_t' was here
> >   ../arch/powerpc/boot/Makefile:210: recipe for target 
> > 'arch/powerpc/boot/fdt.o' failed
> >   make[2]: *** [arch/powerpc/boot/fdt.o] Error 1
> >
> >The problem is that commit 656ad58ef19e (powerpc/boot: Add OPAL console
> >to epapr wrappers) adds typedefs for uint32_t and uint64_t to type.h but
> >doesn't remove the pre-existing (and now duplicate) typedefs from
> >libfdt_env.h.  Fix the error by removing the duplicat typedefs from
> >libfdt_env.h
> >
> >CC: David Gibson 
> >CC: Oliver O'Halloran 
> >Signed-off-by: Mark Greer 
> >---
> >Having said all of that, commit 656ad58ef19e (powerpc/boot: Add OPAL
> >console to epapr wrappers) went into mainline back in 2016 so, AFAICT,
> >this has been broken since then.  That seems unlikely so I must be
> >missing something...  Any ideas what that is?
> 
> I just compiled uImage for ppc6xx_defconfig, and I don't get such error.
> I looked at what gcc -E outputs, u32 is defined twice but it doesn't seems
> to bother GCC.
> 
> What version of GCC do you use ?
> I tried with 5.4.0 and 4.6.3, both seems to work.
> 
> Christophe

Hi Christophe.

That's interesting.  I would expect an error regardless of version.

I used an old 4.5.1 gcc that I had laying around (from denx, iirc).
I'll find a newer one and try it.

Either way, it seems to me that we should remove the duplicate definitions.
Do you agree?

Thanks,

Mark
--

[PATCH AUTOSEL for 4.14 93/97] signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP

2018-03-19 Thread Sasha Levin 
From: "Eric W. Biederman" 

[ Upstream commit cf4674c46c66e45f238f8f7e81af2a444b970c0a ]

Setting si_code to 0 results in a userspace seeing an si_code of 0.
This is the same si_code as SI_USER.  Posix and common sense requires
that SI_USER not be a signal specific si_code.  As such this use of 0
for the si_code is a pretty horribly broken ABI.

Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
value of __SI_KILL and now sees a value of SIL_KILL with the result
that uid and pid fields are copied and which might copying the si_addr
field by accident but certainly not by design.  Making this a very
flakey implementation.

Utilizing FPE_FIXME and TRAP_FIXME, siginfo_layout() will now return
SIL_FAULT and the appropriate fields will be reliably copied.

Possible ABI fixes includee:
- Send the signal without siginfo
- Don't generate a signal
- Possibly assign and use an appropriate si_code
- Don't handle cases which can't happen
Cc: Paul Mackerras 
Cc: Kumar Gala 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc:  linuxppc-dev@lists.ozlabs.org
Ref: 9bad068c24d7 ("[PATCH] ppc32: support for e500 and 85xx")
Ref: 0ed70f6105ef ("PPC32: Provide proper siginfo information on various 
exceptions.")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/include/uapi/asm/siginfo.h | 15 +++
 arch/powerpc/kernel/traps.c | 10 +-
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/uapi/asm/siginfo.h 
b/arch/powerpc/include/uapi/asm/siginfo.h
index 1a691141e49f..444ca6c9989a 100644
--- a/arch/powerpc/include/uapi/asm/siginfo.h
+++ b/arch/powerpc/include/uapi/asm/siginfo.h
@@ -18,4 +18,19 @@
 #undef NSIGTRAP
 #define NSIGTRAP   4
 
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME  0   /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+/*
+ * SIGTRAP si_codes
+ */
+#ifdef __KERNEL__
+#define TRAP_FIXME 0   /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+
 #endif /* _ASM_POWERPC_SIGINFO_H */
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 13c9dcdcba69..f6f6d4bf147c 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -720,7 +720,7 @@ void unknown_exception(struct pt_regs *regs)
printk("Bad trap at PC: %lx, SR: %lx, vector=%lx\n",
   regs->nip, regs->msr, regs->trap);
 
-   _exception(SIGTRAP, regs, 0, 0);
+   _exception(SIGTRAP, regs, TRAP_FIXME, 0);
 
exception_exit(prev_state);
 }
@@ -742,7 +742,7 @@ void instruction_breakpoint_exception(struct pt_regs *regs)
 
 void RunModeException(struct pt_regs *regs)
 {
-   _exception(SIGTRAP, regs, 0, 0);
+   _exception(SIGTRAP, regs, TRAP_FIXME, 0);
 }
 
 void single_step_exception(struct pt_regs *regs)
@@ -781,7 +781,7 @@ static void emulate_single_step(struct pt_regs *regs)
 
 static inline int __parse_fpscr(unsigned long fpscr)
 {
-   int ret = 0;
+   int ret = FPE_FIXME;
 
/* Invalid operation */
if ((fpscr & FPSCR_VE) && (fpscr & FPSCR_VX))
@@ -1769,7 +1769,7 @@ void SPEFloatingPointException(struct pt_regs *regs)
extern int do_spe_mathemu(struct pt_regs *regs);
unsigned long spefscr;
int fpexc_mode;
-   int code = 0;
+   int code = FPE_FIXME;
int err;
 
flush_spe_to_thread(current);
@@ -1838,7 +1838,7 @@ void SPEFloatingPointRoundException(struct pt_regs *regs)
printk(KERN_ERR "unrecognized spe instruction "
   "in %s at %lx\n", current->comm, regs->nip);
} else {
-   _exception(SIGFPE, regs, 0, regs->nip);
+   _exception(SIGFPE, regs, FPE_FIXME, regs->nip);
return;
}
 }
-- 
2.14.1

[PATCH AUTOSEL for 4.15 120/124] signal/powerpc: Document conflicts with SI_USER and SIGFPE and SIGTRAP

2018-03-19 Thread Sasha Levin 
From: "Eric W. Biederman" 

[ Upstream commit cf4674c46c66e45f238f8f7e81af2a444b970c0a ]

Setting si_code to 0 results in a userspace seeing an si_code of 0.
This is the same si_code as SI_USER.  Posix and common sense requires
that SI_USER not be a signal specific si_code.  As such this use of 0
for the si_code is a pretty horribly broken ABI.

Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
value of __SI_KILL and now sees a value of SIL_KILL with the result
that uid and pid fields are copied and which might copying the si_addr
field by accident but certainly not by design.  Making this a very
flakey implementation.

Utilizing FPE_FIXME and TRAP_FIXME, siginfo_layout() will now return
SIL_FAULT and the appropriate fields will be reliably copied.

Possible ABI fixes includee:
- Send the signal without siginfo
- Don't generate a signal
- Possibly assign and use an appropriate si_code
- Don't handle cases which can't happen
Cc: Paul Mackerras 
Cc: Kumar Gala 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc:  linuxppc-dev@lists.ozlabs.org
Ref: 9bad068c24d7 ("[PATCH] ppc32: support for e500 and 85xx")
Ref: 0ed70f6105ef ("PPC32: Provide proper siginfo information on various 
exceptions.")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/include/uapi/asm/siginfo.h | 15 +++
 arch/powerpc/kernel/traps.c | 10 +-
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/uapi/asm/siginfo.h 
b/arch/powerpc/include/uapi/asm/siginfo.h
index 1a691141e49f..444ca6c9989a 100644
--- a/arch/powerpc/include/uapi/asm/siginfo.h
+++ b/arch/powerpc/include/uapi/asm/siginfo.h
@@ -18,4 +18,19 @@
 #undef NSIGTRAP
 #define NSIGTRAP   4
 
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME  0   /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+/*
+ * SIGTRAP si_codes
+ */
+#ifdef __KERNEL__
+#define TRAP_FIXME 0   /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+
 #endif /* _ASM_POWERPC_SIGINFO_H */
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index f3eb61be0d30..f2e6e1838952 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -917,7 +917,7 @@ void unknown_exception(struct pt_regs *regs)
printk("Bad trap at PC: %lx, SR: %lx, vector=%lx\n",
   regs->nip, regs->msr, regs->trap);
 
-   _exception(SIGTRAP, regs, 0, 0);
+   _exception(SIGTRAP, regs, TRAP_FIXME, 0);
 
exception_exit(prev_state);
 }
@@ -939,7 +939,7 @@ void instruction_breakpoint_exception(struct pt_regs *regs)
 
 void RunModeException(struct pt_regs *regs)
 {
-   _exception(SIGTRAP, regs, 0, 0);
+   _exception(SIGTRAP, regs, TRAP_FIXME, 0);
 }
 
 void single_step_exception(struct pt_regs *regs)
@@ -978,7 +978,7 @@ static void emulate_single_step(struct pt_regs *regs)
 
 static inline int __parse_fpscr(unsigned long fpscr)
 {
-   int ret = 0;
+   int ret = FPE_FIXME;
 
/* Invalid operation */
if ((fpscr & FPSCR_VE) && (fpscr & FPSCR_VX))
@@ -1929,7 +1929,7 @@ void SPEFloatingPointException(struct pt_regs *regs)
extern int do_spe_mathemu(struct pt_regs *regs);
unsigned long spefscr;
int fpexc_mode;
-   int code = 0;
+   int code = FPE_FIXME;
int err;
 
flush_spe_to_thread(current);
@@ -1998,7 +1998,7 @@ void SPEFloatingPointRoundException(struct pt_regs *regs)
printk(KERN_ERR "unrecognized spe instruction "
   "in %s at %lx\n", current->comm, regs->nip);
} else {
-   _exception(SIGFPE, regs, 0, regs->nip);
+   _exception(SIGFPE, regs, FPE_FIXME, regs->nip);
return;
}
 }
-- 
2.14.1

Re: [PATCH v12 00/11] Application Data Integrity feature introduced by SPARC M7

2018-03-19 Thread Khalid Aziz 

On 03/18/2018 09:08 AM, David Miller wrote:

In uapi/asm/auxvec.h you conditionalize the ADI aux vectors on
CONFIG_SPARC64.

That's not correct, you should never control user facing definitions
based upon kernel configuration.

Also, both 32-bit and 64-bit applications running on ADI capable
machines want to compile against and use this informaiton.

So please remove these CPP checks.



Hi Dave,

That makes sense. I will send a patch to remove these.

Thanks,
Khalid

Re: [PATCH 1/2] powerpc64/ftrace: Add a field in paca to disable ftrace in unsafe code paths

2018-03-19 Thread Steven Rostedt 
On Mon, 19 Mar 2018 14:43:00 +0530
"Naveen N. Rao"  wrote:

> diff --git a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S 
> b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
> index 3f3e81852422..fdf702b4df25 100644
> --- a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
> +++ b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
> @@ -60,6 +60,19 @@ _GLOBAL(ftrace_caller)
>   mfxer   r10
>   mfcrr11
>  
> +#ifdef CONFIG_KVM
> + lbz r3, PACA_FTRACE_DISABLED(r13)
> + cmpdi   r3, 0
> + beq 1f
> + mflrr3
> + mtctr   r3
> + REST_GPR(3, r1)
> + addir1, r1, SWITCH_FRAME_SIZE
> + mtlrr0
> + bctr
> +1:
> +#endif

I wonder if we should try to move the return out of the fast path (for
cache reasons), as most of the time the above compare will be true. That
is:

#ifdef CONFIG_KVM
lbz r3, PACA_FTRACE_DISABLED(r13)
cmpdi   r3, 0
bne no_trace
#endif

/* rest of ftrace_caller code */

/* after ftrace_caller... */
bctr/* jump after _mcount site */

#ifdef  CONFIG_KVM
no_trace:
mflrr3
mtctr   r3
REST_GPR(3, r1)
addir1, r1, SWITCH_FRAME_SIZE
mtlrr0
bctr
#endif


-- Steve

> +
>   /* Get the _mcount() call site out of LR */
>   mflrr7
>   /* Save it as pt_regs->nip */

[PATCH 1/2] powerpc/32be: use stmw/lmw for non volatile registers save/restore

2018-03-19 Thread Christophe Leroy 
arch/powerpc/Makefile activates -mmultiple on BE PPC32 configs
in order to use multiple word instructions in functions entry/exit

The patch does the same for the asm parts, for consistency

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/ppc_asm.h |  5 +
 arch/powerpc/kernel/misc.S | 10 ++
 2 files changed, 15 insertions(+)

diff --git a/arch/powerpc/include/asm/ppc_asm.h 
b/arch/powerpc/include/asm/ppc_asm.h
index ae94b3626b6c..3c39f7fa9540 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -80,11 +80,16 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_SPLPAR)
 #else
 #define SAVE_GPR(n, base)  stw n,GPR0+4*(n)(base)
 #define REST_GPR(n, base)  lwz n,GPR0+4*(n)(base)
+#ifdef CONFIG_CPU_BIG_ENDIAN
+#define SAVE_NVGPRS(base)  stmw13, GPR0+4*13(base)
+#define REST_NVGPRS(base)  lmw 13, GPR0+4*13(base)
+#else
 #define SAVE_NVGPRS(base)  SAVE_GPR(13, base); SAVE_8GPRS(14, base); \
SAVE_10GPRS(22, base)
 #define REST_NVGPRS(base)  REST_GPR(13, base); REST_8GPRS(14, base); \
REST_10GPRS(22, base)
 #endif
+#endif
 
 #define SAVE_2GPRS(n, base)SAVE_GPR(n, base); SAVE_GPR(n+1, base)
 #define SAVE_4GPRS(n, base)SAVE_2GPRS(n, base); SAVE_2GPRS(n+2, base)
diff --git a/arch/powerpc/kernel/misc.S b/arch/powerpc/kernel/misc.S
index 384357cb8bc0..739977a6be80 100644
--- a/arch/powerpc/kernel/misc.S
+++ b/arch/powerpc/kernel/misc.S
@@ -60,6 +60,10 @@ _GLOBAL(setjmp)
PPC_STL r0,0(r3)
PPC_STL r1,SZL(r3)
PPC_STL r2,2*SZL(r3)
+#if defined(CONFIG_PPC32) && defined(CONFIG_CPU_BIG_ENDIAN)
+   mfcrr12
+   stmwr12, 3*SZL(r3)
+#else
mfcrr0
PPC_STL r0,3*SZL(r3)
PPC_STL r13,4*SZL(r3)
@@ -81,6 +85,7 @@ _GLOBAL(setjmp)
PPC_STL r29,20*SZL(r3)
PPC_STL r30,21*SZL(r3)
PPC_STL r31,22*SZL(r3)
+#endif
li  r3,0
blr
 
@@ -88,6 +93,10 @@ _GLOBAL(longjmp)
PPC_LCMPI r4,0
bne 1f
li  r4,1
+#if defined(CONFIG_PPC32) && defined(CONFIG_CPU_BIG_ENDIAN)
+1: lmw r12, 3*SZL(r3)
+   mtcrf   0x38, r12
+#else
 1: PPC_LL  r13,4*SZL(r3)
PPC_LL  r14,5*SZL(r3)
PPC_LL  r15,6*SZL(r3)
@@ -109,6 +118,7 @@ _GLOBAL(longjmp)
PPC_LL  r31,22*SZL(r3)
PPC_LL  r0,3*SZL(r3)
mtcrf   0x38,r0
+#endif
PPC_LL  r0,0(r3)
PPC_LL  r1,SZL(r3)
PPC_LL  r2,2*SZL(r3)
-- 
2.13.3

[PATCH 2/2] powerpc: avoid an unnecessary test and branch in longjmp()

2018-03-19 Thread Christophe Leroy 
Doing the test at exit of the function avoids an unnecessary
test and branch in longjmp()

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/kernel/misc.S | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/misc.S b/arch/powerpc/kernel/misc.S
index 739977a6be80..9b9207f60d28 100644
--- a/arch/powerpc/kernel/misc.S
+++ b/arch/powerpc/kernel/misc.S
@@ -90,14 +90,11 @@ _GLOBAL(setjmp)
blr
 
 _GLOBAL(longjmp)
-   PPC_LCMPI r4,0
-   bne 1f
-   li  r4,1
 #if defined(CONFIG_PPC32) && defined(CONFIG_CPU_BIG_ENDIAN)
-1: lmw r12, 3*SZL(r3)
+   lmw r12, 3*SZL(r3)
mtcrf   0x38, r12
 #else
-1: PPC_LL  r13,4*SZL(r3)
+   PPC_LL  r13,4*SZL(r3)
PPC_LL  r14,5*SZL(r3)
PPC_LL  r15,6*SZL(r3)
PPC_LL  r16,7*SZL(r3)
@@ -123,7 +120,9 @@ _GLOBAL(longjmp)
PPC_LL  r1,SZL(r3)
PPC_LL  r2,2*SZL(r3)
mtlrr0
-   mr  r3,r4
+   mr. r3, r4
+   bnelr
+   li  r3, 1
blr
 
 _GLOBAL(current_stack_pointer)
-- 
2.13.3

Linux 4.16: Reported regressions as of , 2018-03-19 (Was: Re: Linux 4.16-rc6)

2018-03-19 Thread Thorsten Leemhuis 
On 19.03.2018 02:14, Linus Torvalds wrote:
> This has been a nice quiet week, so rc6 is pretty tiny. Everything
> looks like we're on a usual schedule - I'll make an rc7, but hopefully
> that will be it.

Hi! Find below my fifth regression report for Linux 4.16. It lists 7
regressions I'm currently aware of. 2 were fixed since last weeks
report; 1 is new; 2 are going to be removed (see below for details).

Are you aware of any other regressions that got introduced this
development cycle? Then please let me know by mail (a simple bounce or
forward to the sender of this email address is enough!). And please tell
me if there is anything in the report that shouldn't be there.

Ciao, Thorsten

== Current regressions ==

Dell R640 does not boot due to SCSI/SATA failure
- Status: WIP; some other changes developed for 4.17 solve this
regression, but there is a discussion for a proper fix
- Cause:  https://git.kernel.org/torvalds/c/84676c1f21e8
- Reported: 2018-02-22
https://marc.info/?l=linux-kernel=151931128006031
- Last known developer activity: 2018-03-14
https://marc.info/?l=linux-block=152102086831636=2
- Other relevant links:
https://marc.info/?l=linux-block=152051511802229=2
https://marc.info/?l=linux-kernel=152026091325037

hci_bcm: Streamline runtime PM code change for 4.16 kernel breaks
bluetooth on ASUS T100TA
- Status: Hans is working on it, lot's of activity in bugzilla
- Cause:  https://git.kernel.org/torvalds/c/43fff7683468
- Reported: 2018-03-01
https://bugzilla.kernel.org/show_bug.cgi?id=198953

Error updating SMART data during runtime and could not connect to lv
["Possible Regression"]
- Status: Two issues discussed here; not much progress yet on the
regression (latency issues in the MU03 version of the firmware,
triggered by polling SMART data, which causes lvmetad to timeout in some
cases)
- Reported: 2018-03-11
https://marc.info/?l=linux-kernel=152075643627082
https://bugzilla.kernel.org/show_bug.cgi?id=199077
- Last known developer activity: 2018-03-19
https://marc.info/?l=linux-kernel=152145306610330
- Other relevant links:
https://www.mail-archive.com/linux-block@vger.kernel.org/msg18338.html
https://marc.info/?l=linux-scsi=152095303312164=2

15% longer running times on lvm2 test suite
- Status: Seems the real problem is in the way the test scripts interact
with the kernel
- Cause:  https://git.kernel.org/torvalds/c/44c02a2c3dc5
- Reported: 2018-03-11
https://marc.info/?l=linux-kernel=152077333230274
- Last known developer activity: 2018-03-13
https://marc.info/?l=linux-kernel=152097761921525

sdhci-acpi not recognizing eMMC
- Status: Told reporter to contact developers an ML by mail
- Cause:  https://git.kernel.org/torvalds/c/1b7ba57ecc86
- Reported: 2018-03-13
https://bugzilla.kernel.org/show_bug.cgi?id=199105


== Waiting for clarification from reporter ==

Interrupt storm after suspend causes one busy kworker
- Status: Still waiting for data from reporter
- Reported: 2018-02-25
https://bugzilla.kernel.org/show_bug.cgi?id=198929

AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5
- Status: New, but data missing; unclear if this really is a regression
in 4.16, but looks a lot like one
- Reported: 2018-03-13
https://bugzilla.kernel.org/show_bug.cgi?id=199101


== Going to get removed from the report ==

aim7.jobs-per-min -18.0% regression
- Status: not an issue; looks like something weird happen when compiling
the kernel which lead to bogus results
- Cause:  https://git.kernel.org/torvalds/c/c0cef30e4ff0
- Reported: 2018-02-25
https://marc.info/?l=linux-kernel=151957120702272=2
- Last known developer activity:
https://marc.info/?l=linux-kernel=152113601602820

[mm, mlock, vmscan]  9c4e6b1a70:  stress-ng.hdd.ops_per_sec -7.9% regression
- Status: looks stalled, seems nobody cares; side note: lkp-robot warned
about something else triggered by the same commit:
https://lkml.kernel.org/r/20180302093940.GE25699@yexl-desktop is related
- Cause:  https://git.kernel.org/torvalds/c/9c4e6b1a7027
- Reported: 2018-02-25
https://marc.info/?l=linux-kernel=151956997301994
- Note: performance regression found by lkp-robot


== Fixed since last report ==

Regression from efi: call get_event_log before ExitBootServices
- Status: Fixed by https://git.kernel.org/torvalds/c/79832f0b5f71
- Cause:  https://git.kernel.org/torvalds/c/33b6d03469b2
- Reported: 2018-03-06
https://marc.info/?l=linux-kernel=152035206220237=2

[amdgpu CARRIZO] disabled backlight after S3 resume
- Status: Fixed by https://git.kernel.org/torvalds/c/b5e324131697
- Cause:  https://git.kernel.org/torvalds/c/4ec6ecf48c64
- Reported: 2018-03-07
https://bugzilla.kernel.org/show_bug.cgi?id=199047

Re: [PATCH 3/5] powerpc/mm/32: Use page_is_ram to check for RAM

2018-03-19 Thread Michael Ellerman 
Michael Ellerman  writes:
> Jonathan Neuschäfer  writes:
>
>> Signed-off-by: Jonathan Neuschäfer 
>> ---
>>  arch/powerpc/mm/pgtable_32.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
>> index d35d9ad3c1cd..d54e1a9c1c99 100644
>> --- a/arch/powerpc/mm/pgtable_32.c
>> +++ b/arch/powerpc/mm/pgtable_32.c
>> @@ -145,9 +145,8 @@ __ioremap_caller(phys_addr_t addr, unsigned long size, 
>> unsigned long flags,
>>  #ifndef CONFIG_CRASH_DUMP
>>  /*
>>   * Don't allow anybody to remap normal RAM that we're using.
>> - * mem_init() sets high_memory so only do the check after that.
>>   */
>> -if (slab_is_available() && (p < virt_to_phys(high_memory)) &&
>> +if (page_is_ram(__phys_to_pfn(p)) &&
>>  !(__allow_ioremap_reserved && memblock_is_region_reserved(p, 
>> size))) {
>>  printk("__ioremap(): phys addr 0x%llx is RAM lr %ps\n",
>> (unsigned long long)p, __builtin_return_address(0));
>
>
> This is killing my p5020ds (Freescale e5500) unfortunately:

Duh, I should actually read the patch :)

This is a 32-bit system with 4G of RAM, so not all of RAM is mapped,
some of it is highem which is why removing the test against high_memory
above breaks it.

So I need the high_memory test on this system.

I'm not clear why it was a problem for you on the Wii, do you even build
the Wii kernel with HIGHMEM enabled?

cheers

Re: [PATCH 1/2] powerpc64/ftrace: Add a field in paca to disable ftrace in unsafe code paths

2018-03-19 Thread Nicholas Piggin 
On Mon, 19 Mar 2018 14:43:00 +0530
"Naveen N. Rao"  wrote:

> We have some C code that we call into from real mode where we cannot
> take any exceptions. Though the C functions themselves are mostly safe,
> if these functions are traced, there is a possibility that we may take
> an exception. For instance, in certain conditions, the ftrace code uses
> WARN(), which uses a 'trap' to do its job.
> 
> For such scenarios, introduce a new field in paca 'ftrace_disabled',
> which is checked on ftrace entry before continuing. This field can then
> be set to a non-zero value to disable/pause ftrace, and reset to zero to
> resume ftrace.
> 
> Since KVM is the only user for this currently, we guard the
> ftrace/mcount checks within CONFIG_KVM. This can later be removed
> if/when there are other users.

Why not test HSTATE_IN_GUEST then? Add ftrace_disabled if non-KVM users
come along.

Thanks,
Nick

[PATCH 2/2] powerpc/mm: Trace tlbia instruction

2018-03-19 Thread Christophe Leroy 
Add a trace point for tlbia (Translation Lookaside Buffer Invalidate
All) instruction.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/trace.h | 15 +++
 arch/powerpc/mm/mmu_decl.h   |  2 ++
 2 files changed, 17 insertions(+)

diff --git a/arch/powerpc/include/asm/trace.h b/arch/powerpc/include/asm/trace.h
index 33f3b479138b..d1d63b173dd7 100644
--- a/arch/powerpc/include/asm/trace.h
+++ b/arch/powerpc/include/asm/trace.h
@@ -202,6 +202,21 @@ TRACE_EVENT(tlbie,
__entry->r)
 );
 
+TRACE_EVENT(tlbia,
+
+   TP_PROTO(unsigned long lpid),
+   TP_ARGS(lpid),
+   TP_STRUCT__entry(
+   __field(unsigned long, lpid)
+   ),
+
+   TP_fast_assign(
+   __entry->lpid = lpid;
+   ),
+
+   TP_printk("lpid=%ld", __entry->lpid)
+);
+
 #endif /* _TRACE_POWERPC_H */
 
 #undef TRACE_INCLUDE_PATH
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index b9991e0c61a2..d4ae7b5d45fe 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -32,10 +32,12 @@
 static inline void _tlbil_all(void)
 {
asm volatile ("sync; tlbia; isync" : : : "memory");
+   trace_tlbia(MMU_NO_CONTEXT);
 }
 static inline void _tlbil_pid(unsigned int pid)
 {
asm volatile ("sync; tlbia; isync" : : : "memory");
+   trace_tlbia(pid);
 }
 #define _tlbil_pid_noind(pid)  _tlbil_pid(pid)
 
-- 
2.13.3

[PATCH 1/2] powerpc/mm: Add missing tracepoint for tlbie

2018-03-19 Thread Christophe Leroy 
commit 0428491cba927 ("powerpc/mm: Trace tlbie(l) instructions")
added tracepoints for tlbie calls, but _tlbil_va() was forgotten

Fixes: 0428491cba927 ("powerpc/mm: Trace tlbie(l) instructions")
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/mm/mmu_decl.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index 57fbc554c785..b9991e0c61a2 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_PPC_MMU_NOHASH
 
@@ -56,6 +57,7 @@ static inline void _tlbil_va(unsigned long address, unsigned 
int pid,
 unsigned int tsize, unsigned int ind)
 {
asm volatile ("tlbie %0; sync" : : "r" (address) : "memory");
+   trace_tlbie(pid, 0, address, 0, 0, 0, 0);
 }
 #elif defined(CONFIG_PPC_BOOK3E)
 extern void _tlbil_va(unsigned long address, unsigned int pid,
-- 
2.13.3

Re: [RFC PATCH 4/6] mm: provide generic compat_sys_readahead() implementation

2018-03-19 Thread Ingo Molnar 

* Al Viro  wrote:

> On Sun, Mar 18, 2018 at 06:18:48PM +, Al Viro wrote:
> 
> > I'd done some digging in that area, will find the notes and post.
> 
> OK, found:

Very nice writeup - IMHO this should go into Documentation/!

> OTOH, consider arm.  There we have
>   * r0, r1, r2, r3, [sp,#8], [sp,#12], [sp,#16]... is the sequence
> of objects used to pass arguments
>   * 32bit and less - pick the next available slot
>   * 64bit - skip a slot if we'd already taken an odd number, then use
> the next two slots for lower and upper 32 bits of the argument.
> 
> So our classes take
> simple n-argument:0 to 6 slots
> WD4 slots
> DWW   4 slots
> WDW   5 slots
> WWDD  6 slots
> WDWW  5 slots
> WWWD  6 slots
> WWDWW 6 slots
> WDDW  7 slots (!)  Also , , !@#!@#!@#!# and other nice
> and well-deserved comments from arch maintainers, some of them even printable:
> /* It would be nice if people remember that not all the world's an i386
>when they introduce new system calls */
> SYSCALL_DEFINE4(sync_file_range2, int, fd, unsigned int, flags,
>  loff_t, offset, loff_t, nbytes)

Such idiosyncratic platform quirks that have an impact on generic code should 
be 
as self-maintaining as possible: i.e. there should be a build time warning even 
on 
x86 if someone introduces a new, suboptimally packed system call.

Otherwise we'll have such incidents again and again as new system calls get 
added.

> [snip the preprocessor horrors - the sketches I've got there are downright 
> obscene]

I still think we should consider creating a generic facility and a tool: which 
would immediately and automatically add new system calls to *every* 
architecture - 
or which would initially at least check these syscall ABI constraints.

I.e. this would start with a new generic kernel facility that warns about 
suboptimal new system call argument layouts on every architecture, not just on 
the 
affected ones.

That's a significant undertaking but should be possible to do.

Once such a facility is in place all the existing old mess is still a PITA, but 
should be manageable eventually - as no new mess is added to it.

IMHO that's the only thing that could break the somewhat deadly current dynamic 
of 
system call mappings mess. Complaining about people not knowing about quirks 
won't 
help.

One way to implement this would be to put the argument chain types (string) and 
sizes (int) into a special debug section which isn't included in the final 
kernel 
image but which can be checked at link time.

For example this attempt at creating a new system call:

  SYSCALL_DEFINE3(moron, int, fd, loff_t, offset, size_t, count)

... would translate into something like:

.name = "moron", .pattern = "WWW", .type = "int",.size = 4,
.name = NULL,  .type = "loff_t", .size = 8,
.name = NULL,  .type = "size_t", .size = 4,
.name = NULL,  .type = NULL, .size = 0, /* 
end of parameter list */

i.e. "WDW". The build-time constraint checker could then warn about:

  # error: System call "moron" uses invalid 'WWW' argument mapping for a 'WDW' 
sequence
  #please avoid long-long arguments or use 'SYSCALL_DEFINE3_WDW()' 
instead

Each architecture can provide its own syscall parameter checking logic. Both 
'stack boundary' and parameter packing rules would be straightforward to 
express 
if we had such a data structure.

Also note that this tool could also check for optimum packing, i.e. if the new 
system call is defined as:

  SYSCALL_DEFINE3_WDW(moron, int, fd, loff_t, offset, size_t, count)

... would translate to something like:

.name = "moron", .pattern = "WDW", .type = "int",.size = 4,
.name = NULL,  .type = "loff_t", .size = 8,
.name = NULL,  .type = "size_t", .size = 4,
.name = NULL,  .type = NULL, .size = 0, /* 
end of parameter list */

where the tool would print out this error:

  # error: System call "moron" uses suboptimal 'WDW' argument mapping instead 
of 'WWD'

there would be a whitelist of existing system calls that are already using an 
suboptimal argument order - but the warnings/errors would trigger for all new 
system calls.

But adding non-straight-mapped system calls would be the exception in any case.

Such tooling could also do other things, such as limit the C types used for 
system 
call defines to a well-chosen set of ABI-safe types, such as:

  3  key_t
  3  uint32_t
  4  aio_context_t
  4  mqd_t
  4  timer_t
 10  clockid_t
 10  gid_t
 10  loff_t
 10  long
 10  old_gid_t
 10  old_uid_t
 10  umode_t
 11  uid_t
 31  pid_t
 34  size_t
 69  unsigned int

[PATCH 2/2] powerpc64/ftrace: Disable ftrace during kvm guest entry/exit

2018-03-19 Thread Naveen N. Rao 
During guest entry/exit, we switch over to/from the guest MMU context.
While doing so, we set our state to KVM_GUEST_MODE_HOST_HV to note down
the fact that we cannot take any exceptions in the hypervisor code.

Since ftrace may be enabled and since it can result in us taking a trap,
disable ftrace by setting paca->ftrace_disabled. Once we exit the guest
and restore host MMU context, we re-enable ftrace.

Signed-off-by: Naveen N. Rao 
---
 arch/powerpc/kvm/book3s_hv_rmhandlers.S | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index f31f357b8c5a..9292087adb68 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -600,6 +600,10 @@ kvmppc_hv_entry:
/* Save R1 in the PACA */
std r1, HSTATE_HOST_R1(r13)
 
+   /* Disable ftrace since we can't take a trap any more */
+   li  r6, 1
+   stb r6, PACA_FTRACE_DISABLED(r13)
+
li  r6, KVM_GUEST_MODE_HOST_HV
stb r6, HSTATE_IN_GUEST(r13)
 
@@ -2048,6 +2052,8 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_RADIX)
/* Unset guest mode */
li  r0, KVM_GUEST_MODE_NONE
stb r0, HSTATE_IN_GUEST(r13)
+   li  r0, 0
+   stb r0, PACA_FTRACE_DISABLED(r13)
 
ld  r0, SFS+PPC_LR_STKOFF(r1)
addir1, r1, SFS
@@ -3379,6 +3385,8 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_RADIX)
ld  r8, KVM_HOST_LPCR(r10)
mtspr   SPRN_LPCR, r8
isync
+   li  r0, 0
+   stb r0, PACA_FTRACE_DISABLED(r13)
li  r0, KVM_GUEST_MODE_NONE
stb r0, HSTATE_IN_GUEST(r13)
 
-- 
2.16.2

[PATCH 1/2] powerpc64/ftrace: Add a field in paca to disable ftrace in unsafe code paths

2018-03-19 Thread Naveen N. Rao 
We have some C code that we call into from real mode where we cannot
take any exceptions. Though the C functions themselves are mostly safe,
if these functions are traced, there is a possibility that we may take
an exception. For instance, in certain conditions, the ftrace code uses
WARN(), which uses a 'trap' to do its job.

For such scenarios, introduce a new field in paca 'ftrace_disabled',
which is checked on ftrace entry before continuing. This field can then
be set to a non-zero value to disable/pause ftrace, and reset to zero to
resume ftrace.

Since KVM is the only user for this currently, we guard the
ftrace/mcount checks within CONFIG_KVM. This can later be removed
if/when there are other users.

Signed-off-by: Naveen N. Rao 
---
 arch/powerpc/include/asm/paca.h|  1 +
 arch/powerpc/kernel/asm-offsets.c  |  1 +
 arch/powerpc/kernel/trace/ftrace_64_mprofile.S | 13 +
 arch/powerpc/kernel/trace/ftrace_64_pg.S   |  6 ++
 4 files changed, 21 insertions(+)

diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index d2bf71dddbef..4f47adc2a408 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -211,6 +211,7 @@ struct paca_struct {
u16 in_mce;
u8 hmi_event_available; /* HMI event is available */
u8 hmi_p9_special_emu;  /* HMI P9 special emulation */
+   u8 ftrace_disabled;
 #endif
 
/* Stuff for accurate time accounting */
diff --git a/arch/powerpc/kernel/asm-offsets.c 
b/arch/powerpc/kernel/asm-offsets.c
index ea5eb91b836e..8e4fc96ff6bc 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -240,6 +240,7 @@ int main(void)
OFFSET(PACA_RFI_FLUSH_FALLBACK_AREA, paca_struct, 
rfi_flush_fallback_area);
OFFSET(PACA_EXRFI, paca_struct, exrfi);
OFFSET(PACA_L1D_FLUSH_SIZE, paca_struct, l1d_flush_size);
+   OFFSET(PACA_FTRACE_DISABLED, paca_struct, ftrace_disabled);
 
 #endif
OFFSET(PACAHWCPUID, paca_struct, hw_cpu_id);
diff --git a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S 
b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
index 3f3e81852422..fdf702b4df25 100644
--- a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
+++ b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
@@ -60,6 +60,19 @@ _GLOBAL(ftrace_caller)
mfxer   r10
mfcrr11
 
+#ifdef CONFIG_KVM
+   lbz r3, PACA_FTRACE_DISABLED(r13)
+   cmpdi   r3, 0
+   beq 1f
+   mflrr3
+   mtctr   r3
+   REST_GPR(3, r1)
+   addir1, r1, SWITCH_FRAME_SIZE
+   mtlrr0
+   bctr
+1:
+#endif
+
/* Get the _mcount() call site out of LR */
mflrr7
/* Save it as pt_regs->nip */
diff --git a/arch/powerpc/kernel/trace/ftrace_64_pg.S 
b/arch/powerpc/kernel/trace/ftrace_64_pg.S
index f095358da96e..5b2a99129322 100644
--- a/arch/powerpc/kernel/trace/ftrace_64_pg.S
+++ b/arch/powerpc/kernel/trace/ftrace_64_pg.S
@@ -16,6 +16,12 @@
 
 #ifdef CONFIG_DYNAMIC_FTRACE
 _GLOBAL_TOC(ftrace_caller)
+#ifdef CONFIG_KVM
+   lbz r3, PACA_FTRACE_DISABLED(r13)
+   cmpdi   r3, 0
+   bnelr
+#endif
+
/* Taken from output of objdump from lib64/glibc */
mflrr3
ld  r11, 0(r1)
-- 
2.16.2

[PATCH 0/2] Disable ftrace during kvm guest entry/exit

2018-03-19 Thread Naveen N. Rao 
This is a follow on from the RFC posted at:
https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg130047.html

This series implements a new field in paca called 'ftrace_disabled' to 
be set whenever we want to skip function tracing. This is currently only 
used by KVM guest entry/exit and as such, it is guarded in CONFIG_KVM as 
suggested by Steven Rostedt. This has had some minimal testing, and I 
will continue to test it this week and report back if I see any issues.

- Naveen


Naveen N. Rao (2):
  powerpc64/ftrace: Add a field in paca to disable ftrace in unsafe code
paths
  powerpc64/ftrace: Disable ftrace during kvm guest entry/exit

 arch/powerpc/include/asm/paca.h|  1 +
 arch/powerpc/kernel/asm-offsets.c  |  1 +
 arch/powerpc/kernel/trace/ftrace_64_mprofile.S | 13 +
 arch/powerpc/kernel/trace/ftrace_64_pg.S   |  6 ++
 arch/powerpc/kvm/book3s_hv_rmhandlers.S|  8 
 5 files changed, 29 insertions(+)

-- 
2.16.2

Re: [PATCH] powerpc/boot: Remove duplicate typedefs from libfdt_env.h

2018-03-19 Thread Christophe LEROY 



Le 16/03/2018 à 22:54, Mark Greer a écrit :

When building a uImage or zImage using ppc6xx_defconfig and some other
defconfigs, the following error occurs:

   BOOTCC  arch/powerpc/boot/fdt.o
   In file included from arch/powerpc/boot/fdt.c:51:0:
   ../arch/powerpc/boot/libfdt_env.h:10:13: error: redefinition of typedef 
'uint32_t'
   ../arch/powerpc/boot/types.h:21:13: note: previous declaration of 'uint32_t' 
was here
   ../arch/powerpc/boot/libfdt_env.h:11:13: error: redefinition of typedef 
'uint64_t'
   ../arch/powerpc/boot/types.h:22:13: note: previous declaration of 'uint64_t' 
was here
   ../arch/powerpc/boot/Makefile:210: recipe for target 
'arch/powerpc/boot/fdt.o' failed
   make[2]: *** [arch/powerpc/boot/fdt.o] Error 1

The problem is that commit 656ad58ef19e (powerpc/boot: Add OPAL console
to epapr wrappers) adds typedefs for uint32_t and uint64_t to type.h but
doesn't remove the pre-existing (and now duplicate) typedefs from
libfdt_env.h.  Fix the error by removing the duplicat typedefs from
libfdt_env.h

CC: David Gibson 
CC: Oliver O'Halloran 
Signed-off-by: Mark Greer 
---
Having said all of that, commit 656ad58ef19e (powerpc/boot: Add OPAL
console to epapr wrappers) went into mainline back in 2016 so, AFAICT,
this has been broken since then.  That seems unlikely so I must be
missing something...  Any ideas what that is?


I just compiled uImage for ppc6xx_defconfig, and I don't get such error.
I looked at what gcc -E outputs, u32 is defined twice but it doesn't 
seems to bother GCC.


What version of GCC do you use ?
I tried with 5.4.0 and 4.6.3, both seems to work.

Christophe



I built all of the defconfigs that I had toolchains handy for (really
just old-fashioned ppc32, non-booke) so I didn't test everything.
Compile tested only as I no longer have any relevant hardware.

Based on git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux fixes
currently at e4b79900222b (powerpc/64s: Fix NULL AT_BASE_PLATFORM when
using DT CPU features).

  arch/powerpc/boot/libfdt_env.h | 2 --
  1 file changed, 2 deletions(-)

diff --git a/arch/powerpc/boot/libfdt_env.h b/arch/powerpc/boot/libfdt_env.h
index f52c31b1f48f..2a0c8b1bf147 100644
--- a/arch/powerpc/boot/libfdt_env.h
+++ b/arch/powerpc/boot/libfdt_env.h
@@ -7,8 +7,6 @@
  
  #include "of.h"
  
-typedef u32 uint32_t;

-typedef u64 uint64_t;
  typedef unsigned long uintptr_t;
  
  typedef __be16 fdt16_t;

Re: [RFC PATCH 2/6] fs: provide a generic compat_sys_truncate64() implementation

2018-03-19 Thread Kevin Easton 
On Sun, Mar 18, 2018 at 05:10:52PM +0100, Dominik Brodowski wrote:
> The compat_sys_truncate64() implementations in mips, powerpc, s390, sparc
> and x86 only differed based on whether the u64 parameter needed padding
> and on its endianness.
> 

...
  
> +#ifdef __ARCH_WANT_COMPAT_SYS_TRUNCATE64
> +#if defined(__ARCH_WANT_COMPAT_SYS_WITH_PADDING) && \
> + defined(__ARCH_WANT_LE_COMPAT_SYS)
> +COMPAT_SYSCALL_DEFINE4(truncate64, const char __user *, filename, u32 
> padding,
> +unsigned int, offset_low, unsigned int, offset_high)
> +#elif defined(__ARCH_WANT_COMPAT_SYS_WITH_PADDING) && \
> + !defined(__ARCH_WANT_LE_COMPAT_SYS)
> +COMPAT_SYSCALL_DEFINE4(truncate64, const char __user *, filename, u32 
> padding,
> +unsigned int, offset_high, unsigned int, offset_low)

Notwithstanding the other comments, shouldn't there be a comma between
'u32' and 'padding' in those?

- Kevin

Re: [PATCH 3/5] powerpc/mm/32: Use page_is_ram to check for RAM

2018-03-19 Thread Michael Ellerman 
Jonathan Neuschäfer  writes:

> Signed-off-by: Jonathan Neuschäfer 
> ---
>  arch/powerpc/mm/pgtable_32.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> index d35d9ad3c1cd..d54e1a9c1c99 100644
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -145,9 +145,8 @@ __ioremap_caller(phys_addr_t addr, unsigned long size, 
> unsigned long flags,
>  #ifndef CONFIG_CRASH_DUMP
>   /*
>* Don't allow anybody to remap normal RAM that we're using.
> -  * mem_init() sets high_memory so only do the check after that.
>*/
> - if (slab_is_available() && (p < virt_to_phys(high_memory)) &&
> + if (page_is_ram(__phys_to_pfn(p)) &&
>   !(__allow_ioremap_reserved && memblock_is_region_reserved(p, 
> size))) {
>   printk("__ioremap(): phys addr 0x%llx is RAM lr %ps\n",
>  (unsigned long long)p, __builtin_return_address(0));


This is killing my p5020ds (Freescale e5500) unfortunately:

  smp: Bringing up secondary CPUs ...
  __ioremap(): phys addr 0x7fef5000 is RAM lr smp_85xx_kick_cpu
  Unable to handle kernel paging request for data at address 0x
  Faulting instruction address: 0xc0029080
  Oops: Kernel access of bad area, sig: 11 [#1]
  BE SMP NR_CPUS=24 CoreNet Generic
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.16.0-rc4-gcc-4.6.3-00076-g85319478bdb4 #86
  NIP:  c0029080 LR: c0029020 CTR: 0001
  REGS: e804bd40 TRAP: 0300   Not tainted  
(4.16.0-rc4-gcc-4.6.3-00076-g85319478bdb4)
  MSR:  00021002   CR: 24ad4e22  XER: 
  DEAR:  ESR:  
  GPR00: c0029020 e804bdf0 e805  00021002 004d  
c0aaaeed 
  GPR08:    2d57d000 22adbe84  c0002630 
 
  GPR16:        
c0a8b4a4 
  GPR24: 0001   00029002  0001 0001 
0001 
  NIP [c0029080] smp_85xx_kick_cpu+0x100/0x2c0
  LR [c0029020] smp_85xx_kick_cpu+0xa0/0x2c0
  Call Trace:
  [e804bdf0] [c0029020] smp_85xx_kick_cpu+0xa0/0x2c0 (unreliable)
  [e804be30] [c0011194] __cpu_up+0xb4/0x1c0
  [e804be60] [c002f16c] bringup_cpu+0x2c/0xf0
  [e804be80] [c002ec9c] cpuhp_invoke_callback+0x12c/0x310
  [e804beb0] [c002fdd8] cpu_up+0x108/0x230
  [e804bee0] [c09f7438] smp_init+0x84/0x104
  [e804bf00] [c09e9acc] kernel_init_freeable+0xc4/0x228
  [e804bf30] [c0002644] kernel_init+0x14/0x110
  [e804bf40] [c000f3b0] ret_from_kernel_thread+0x5c/0x64
  Instruction dump:
  57990032 3b1c0057 7f19c050 7f3acb78 5718d1be 2e18 41920024 7f29cb78 
  7f0903a6 6000 6000 6000 <7c0048ac> 39290040 4200fff8 7c0004ac 
  random: get_random_bytes called from init_oops_id+0x5c/0x70 with crng_init=0
  ---[ end trace c3807aa91cf16cd8 ]---


The obvious fix of changing the test in smp_85xx_start_cpu() didn't
work, I get a different oops:

  Unable to handle kernel paging request for data at address 0x3fef5140
  Faulting instruction address: 0xc00290a0
  Oops: Kernel access of bad area, sig: 11 [#1]
  BE SMP NR_CPUS=24 CoreNet Generic
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.16.0-rc4-gcc-4.6.3-00076-g85319478bdb4-dirty #90
  NIP:  c00290a0 LR: c0029040 CTR: 0001
  REGS: e804bd50 TRAP: 0300   Not tainted  
(4.16.0-rc4-gcc-4.6.3-00076-g85319478bdb4-dirty)
  MSR:  00021002   CR: 24a24e22  XER: 
  DEAR: 3fef5140 ESR:  
  GPR00: c0029040 e804be00 e805 0023 00021002 004e  
c0aaaed3 
  GPR08:  3fef5140  2d57d000 22a2be84  c0002630 
 
  GPR16:        
c0a8b4a4 
  GPR24: 0004 0001 3fef5140 3fef5140 00029002 3fef5140 0001 
0001 
  NIP [c00290a0] smp_85xx_kick_cpu+0x120/0x2e0
  LR [c0029040] smp_85xx_kick_cpu+0xc0/0x2e0
  Call Trace:
  [e804be00] [c0029040] smp_85xx_kick_cpu+0xc0/0x2e0 (unreliable)
  [e804be30] [c0011194] __cpu_up+0xb4/0x1c0
  [e804be60] [c002f18c] bringup_cpu+0x2c/0xf0
  [e804be80] [c002ecbc] cpuhp_invoke_callback+0x12c/0x310
  [e804beb0] [c002fdf8] cpu_up+0x108/0x230
  [e804bee0] [c09f7438] smp_init+0x84/0x104
  [e804bf00] [c09e9acc] kernel_init_freeable+0xc4/0x228
  [e804bf30] [c0002644] kernel_init+0x14/0x110
  [e804bf40] [c000f3b0] ret_from_kernel_thread+0x5c/0x64
  Instruction dump:
  7c0903a6 4e800421 57ba0032 3b3d0057 7f3ac850 7f5bd378 5739d1be 2e19 
  4192001c 7f49d378 7f2903a6 6000 <7c0048ac> 39290040 4200fff8 7c0004ac 
  random: get_random_bytes called from init_oops_id+0x5c/0x70 with crng_init=0
  ---[ end trace 950df40ee04f2d5e ]---


So that will require a bit more debugging.

cheers