Re: [PATCH] powerpc/32: Move the old 6xx -mcpu logic before the TARGET_CPU logic

2018-12-04 Thread Mathieu Malaterre
On Tue, Dec 4, 2018 at 10:28 PM Christophe LEROY
 wrote:
>
>
>
> Le 04/12/2018 à 21:53, Mathieu Malaterre a écrit :
> > The code:
> >
> >ifdef CONFIG_6xx
> >KBUILD_CFLAGS  += -mcpu=powerpc
> >endif
> >
> > was added in 2006 in commit f48b8296b315 ("[PATCH] powerpc32: Set cpu
> > explicitly in kernel compiles"). This change was acceptable since the
> > TARGET_CPU logic was 64-bit only.
> >
> > Since commit 0e00a8c9fd92 ("powerpc: Allow CPU selection
> > also on PPC32") this logic is no longer acceptable after the TARGET_CPU
> > specific. It currently appends -mcpu=powerpc at the end of the command
> > line, after any TARGET_CPU specific:
> >
> >gcc -Wp,-MD,init/.do_mounts.o.d ...
> >  -mcpu=powerpc -mbig-endian -m32 ...
> >  -mcpu=e300c2 ...
> >  -mcpu=powerpc ...
> >  ../init/do_mounts.c
> >
> > Cc: Christophe Leroy 
> > Fixes: 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32")
> > Suggested-by: Michael Ellerman 
> > Link: 
> > https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg142315.html
> > Signed-off-by: Mathieu Malaterre 
> > ---
> >   arch/powerpc/Makefile | 8 
> >   1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> > index 8a2ce14d68d0..544b30667ea5 100644
> > --- a/arch/powerpc/Makefile
> > +++ b/arch/powerpc/Makefile
> > @@ -30,6 +30,10 @@ endif
> >   endif
> >   endif
> >
> > +ifdef CONFIG_6xx
> > +KBUILD_CFLAGS+= -mcpu=powerpc
> > +endif
> > +
>
> Could you make the patch on top of my serie (ie after the change of
> CONFIG_6xx to CONFIG_BOOK3S_32 ?

Sure. That will defeat the point of the Fixes: line, but I guess who
cares anyway ? Will re-submit asap.

> The serie is in origin/next-test
>
> Thanks,
> Christophe
>
> >   ifeq ($(CROSS_COMPILE),)
> >   KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
> >   else
> > @@ -241,10 +245,6 @@ KBUILD_CFLAGS+= $(call 
> > cc-option,-fno-dwarf2-cfi-asm)
> >   # often slow when they are implemented at all
> >   KBUILD_CFLAGS   += $(call cc-option,-mno-string)
> >
> > -ifdef CONFIG_6xx
> > -KBUILD_CFLAGS+= -mcpu=powerpc
> > -endif
> > -
> >   cpu-as-$(CONFIG_4xx)+= -Wa,-m405
> >   cpu-as-$(CONFIG_ALTIVEC)+= $(call as-option,-Wa$(comma)-maltivec)
> >   cpu-as-$(CONFIG_E200)   += -Wa,-me200
> >


Re: [PATCH kernel v4 04/19] powerpc/powernv: Move npu struct from pnv_phb to pci_controller

2018-12-04 Thread Alexey Kardashevskiy



On 05/12/2018 16:47, Alexey Kardashevskiy wrote:
> 
> 
> On 05/12/2018 16:14, David Gibson wrote:
>> On Fri, Nov 23, 2018 at 04:52:49PM +1100, Alexey Kardashevskiy wrote:
>>> The powernv PCI code stores NPU data in the pnv_phb struct. The latter
>>> is referenced by pci_controller::private_data. We are going to have NPU2
>>> support in the pseries platform as well but it does not store any
>>> private_data in in the pci_controller struct; and even if it did,
>>> it would be a different data structure.
>>>
>>> This makes npu a pointer and stores it one level higher in
>>> the pci_controller struct.
>>>
>>> Signed-off-by: Alexey Kardashevskiy 
>>> ---
>>> Changes:
>>> v4:
>>> * changed subj from "powerpc/powernv: Detach npu struct from pnv_phb"
>>> * got rid of global list of npus - store them now in pci_controller
>>> * got rid of npdev_to_npu() helper
>>> ---
>>>  arch/powerpc/include/asm/pci-bridge.h|  1 +
>>>  arch/powerpc/platforms/powernv/pci.h | 16 -
>>>  arch/powerpc/platforms/powernv/npu-dma.c | 81 ++--
>>>  3 files changed, 64 insertions(+), 34 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/pci-bridge.h 
>>> b/arch/powerpc/include/asm/pci-bridge.h
>>> index 94d4490..aee4fcc 100644
>>> --- a/arch/powerpc/include/asm/pci-bridge.h
>>> +++ b/arch/powerpc/include/asm/pci-bridge.h
>>> @@ -129,6 +129,7 @@ struct pci_controller {
>>>  #endif /* CONFIG_PPC64 */
>>>  
>>> void *private_data;
>>> +   struct npu *npu;
>>>  };
>>>  
>>>  /* These are used for config access before all the PCI probing
>>> diff --git a/arch/powerpc/platforms/powernv/pci.h 
>>> b/arch/powerpc/platforms/powernv/pci.h
>>> index 2131373..f2d50974 100644
>>> --- a/arch/powerpc/platforms/powernv/pci.h
>>> +++ b/arch/powerpc/platforms/powernv/pci.h
>>> @@ -8,9 +8,6 @@
>>>  
>>>  struct pci_dn;
>>>  
>>> -/* Maximum possible number of ATSD MMIO registers per NPU */
>>> -#define NV_NMMU_ATSD_REGS 8
>>> -
>>>  enum pnv_phb_type {
>>> PNV_PHB_IODA1   = 0,
>>> PNV_PHB_IODA2   = 1,
>>> @@ -176,19 +173,6 @@ struct pnv_phb {
>>> unsigned intdiag_data_size;
>>> u8  *diag_data;
>>>  
>>> -   /* Nvlink2 data */
>>> -   struct npu {
>>> -   int index;
>>> -   __be64 *mmio_atsd_regs[NV_NMMU_ATSD_REGS];
>>> -   unsigned int mmio_atsd_count;
>>> -
>>> -   /* Bitmask for MMIO register usage */
>>> -   unsigned long mmio_atsd_usage;
>>> -
>>> -   /* Do we need to explicitly flush the nest mmu? */
>>> -   bool nmmu_flush;
>>> -   } npu;
>>> -
>>> int p2p_target_count;
>>>  };
>>>  
>>> diff --git a/arch/powerpc/platforms/powernv/npu-dma.c 
>>> b/arch/powerpc/platforms/powernv/npu-dma.c
>>> index 91d488f..7dd5c0e5 100644
>>> --- a/arch/powerpc/platforms/powernv/npu-dma.c
>>> +++ b/arch/powerpc/platforms/powernv/npu-dma.c
>>> @@ -327,6 +327,25 @@ struct pnv_ioda_pe *pnv_pci_npu_setup_iommu(struct 
>>> pnv_ioda_pe *npe)
>>> return gpe;
>>>  }
>>>  
>>> +/*
>>> + * NPU2 ATS
>>> + */
>>> +/* Maximum possible number of ATSD MMIO registers per NPU */
>>> +#define NV_NMMU_ATSD_REGS 8
>>> +
>>> +/* An NPU descriptor, valid for POWER9 only */
>>> +struct npu {
>>> +   int index;
>>> +   __be64 *mmio_atsd_regs[NV_NMMU_ATSD_REGS];
>>> +   unsigned int mmio_atsd_count;
>>> +
>>> +   /* Bitmask for MMIO register usage */
>>> +   unsigned long mmio_atsd_usage;
>>> +
>>> +   /* Do we need to explicitly flush the nest mmu? */
>>> +   bool nmmu_flush;
>>> +};
>>> +
>>>  /* Maximum number of nvlinks per npu */
>>>  #define NV_MAX_LINKS 6
>>>  
>>> @@ -478,7 +497,6 @@ static void acquire_atsd_reg(struct npu_context 
>>> *npu_context,
>>> int i, j;
>>> struct npu *npu;
>>> struct pci_dev *npdev;
>>> -   struct pnv_phb *nphb;
>>>  
>>> for (i = 0; i <= max_npu2_index; i++) {
>>> mmio_atsd_reg[i].reg = -1;
>>> @@ -493,8 +511,10 @@ static void acquire_atsd_reg(struct npu_context 
>>> *npu_context,
>>> if (!npdev)
>>> continue;
>>>  
>>> -   nphb = pci_bus_to_host(npdev->bus)->private_data;
>>> -   npu = >npu;
>>> +   npu = pci_bus_to_host(npdev->bus)->npu;
>>> +   if (!npu)
>>> +   continue;
>>
>> This patch changes a bunch of places that used to unconditionally
>> locate an NPU now have a failure path.
>>
>> Given that this used to always have an NPU, doesn't that mean that if
>> the NPU is not present something has already gone wrong, and we should
>> WARN_ON() or something?
> 
> 
> 
> That means this is a leftover since I dropped that npdev_to_npu helper
> which could help but there was no real value in it. I'll remove the
> check here in the next respin.


Well, technically kmalloc() can fail in pnv_npu2_init() (but not later)
so can (in theory) end up with an NPU PHB and npu==NULL but it is sooo
unlikely...



> 
> I'll probably add 

Re: [PATCH] serial: 8250: Default SERIAL_OF_PLATFORM to SERIAL_8250

2018-12-04 Thread Michael Ellerman
Hi Florian,

Florian Fainelli  writes:
> +PPC folks
>
> On 11/23/18 10:20 AM, Guenter Roeck wrote:
>> On Mon, Nov 19, 2018 at 12:50:50PM -0800, Guenter Roeck wrote:
>>> On Mon, Nov 19, 2018 at 10:44:30AM -0800, Florian Fainelli wrote:
 On 11/15/18 5:16 PM, Guenter Roeck wrote:
> On Thu, Nov 15, 2018 at 11:48:20AM -0800, Florian Fainelli wrote:
>>
>> OK, would you mind testing this below? It seems to me that 8250_of.c is
>> incompatible with arch/powerpc/kernel/legacy_serial.c and that is what
>> is causing the issue here.
>>
>> diff --git a/drivers/tty/serial/8250/Kconfig
>> b/drivers/tty/serial/8250/Kconfig
>> index d7737dca0e48..21cb14cbd34a 100644
>> --- a/drivers/tty/serial/8250/Kconfig
>> +++ b/drivers/tty/serial/8250/Kconfig
>> @@ -483,7 +483,7 @@ config SERIAL_8250_PXA
>>
>>  config SERIAL_OF_PLATFORM
>> tristate "Devicetree based probing for 8250 ports"
>> -   depends on SERIAL_8250 && OF
>> +   depends on SERIAL_8250 && OF && !(PPC && PPC_UDBG_16550)
>> default SERIAL_8250
>> help
>>   This option is used for all 8250 compatible serial ports that
>
> 44x/virtex5_defconfig has both PPC_UDBG_16550 and SERIAL_OF_PLATFORM 
> enabled
> and fails to boot (or display anything on the console) with this patch 
> applied.

 Thanks for trying, can you either share or provide a link to the mpc85xx
 and ml507 qemu command lines that you use? I spent a good chunk of my
 time trying to get a kernel to boot but has failed so far.

>>>
>> 
>> Any update ? I still see the boot failures in next-20181123.
>
> Yes, took most of last week's off sorry for the delay. I have finally
> been able to boot a kernel using your instructions, thanks. The problem
> is the following call chain:
>
> of_platform_serial_probe()
>  -> serial8250_register_8250_port()
> -> up->port.uartclk == 0, return -EINVAL
>   -> irq_dispose_mapping()
>
> and then we basically unwind what we just did with
> of_platform_serial_probe() including disabling the UART's IRQ, comment
> out the irq_dispose_mapping() and you will have a functional console
> again. 8250_of.c is clearly not a full replacement for legacy_serial.c
> (that was a first attempt), so we need to keep that code around. Making
> the depends even more conditional also does not sound too appealing,
> because while we have identified mpc85xx as being problematic, who knows
> about other platforms. So the best I have that does not involve a revert
> is this below.
>
> Ben, Michael, would that sound reasonable to you? It seems to me that
> there is a million ways to shoot the legacy_serial 8250 registration in
> the foot in any cases, and having CONFIG_SERIAL_OF_PLATFORM just made it
> painfully obvious.

We generally try to avoid changing the device tree from inside Linux,
it's meant to describe the hardware as we're given it, not the state of
Linux drivers etc. Perhaps this is an exceptional case but it still
seems fishy.

I also worry that marking the device node disabled might break something
else, but that's maybe me being paranoid.

I guess I don't really understand how things are supposed to work
though. We have the 8250 driver and also the OF platform driver, the
former has already setup the device and then the OF driver just comes
along and takes over?

eg. in the boot log from the mpc8544ds you see:

  serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42, base_baud = 115200) is a 
16550A
  printk: console [ttyS0] enabled
  printk: console [ttyS0] enabled
  printk: bootconsole [udbg0] disabled
  printk: bootconsole [udbg0] disabled
  of_serial: probe of e0004500.serial failed with error -22

ie. the 8250 core has already setup the device, so there should really
be nothing to do?

If the 8250 code could detect that it already has this port registered
then maybe things would work.

The patch below works for me with mpc8544ds. Whether it's worth changing
the 8250 code this much to accomodate legacy_serial I'm not sure.

cheers


diff --git a/drivers/tty/serial/8250/8250_core.c 
b/drivers/tty/serial/8250/8250_core.c
index 94f3e1c64490..c7d7858fdb3d 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -905,7 +905,7 @@ static struct platform_device *serial8250_isa_devs;
  */
 static DEFINE_MUTEX(serial_mutex);
 
-static struct uart_8250_port *serial8250_find_match_or_unused(struct uart_port 
*port)
+static struct uart_8250_port *serial8250_find_existing(struct uart_port *port)
 {
int i;
 
@@ -921,10 +921,17 @@ static struct uart_8250_port 
*serial8250_find_match_or_unused(struct uart_port *
if (i < nr_uarts && serial8250_ports[i].port.type == PORT_UNKNOWN &&
serial8250_ports[i].port.iobase == 0)
return _ports[i];
+
+   return NULL;
+}
+
+static struct uart_8250_port *serial8250_find_unused(struct uart_port *port)
+{
+  

Re: [PATCH kernel v4 04/19] powerpc/powernv: Move npu struct from pnv_phb to pci_controller

2018-12-04 Thread Alexey Kardashevskiy



On 05/12/2018 16:14, David Gibson wrote:
> On Fri, Nov 23, 2018 at 04:52:49PM +1100, Alexey Kardashevskiy wrote:
>> The powernv PCI code stores NPU data in the pnv_phb struct. The latter
>> is referenced by pci_controller::private_data. We are going to have NPU2
>> support in the pseries platform as well but it does not store any
>> private_data in in the pci_controller struct; and even if it did,
>> it would be a different data structure.
>>
>> This makes npu a pointer and stores it one level higher in
>> the pci_controller struct.
>>
>> Signed-off-by: Alexey Kardashevskiy 
>> ---
>> Changes:
>> v4:
>> * changed subj from "powerpc/powernv: Detach npu struct from pnv_phb"
>> * got rid of global list of npus - store them now in pci_controller
>> * got rid of npdev_to_npu() helper
>> ---
>>  arch/powerpc/include/asm/pci-bridge.h|  1 +
>>  arch/powerpc/platforms/powernv/pci.h | 16 -
>>  arch/powerpc/platforms/powernv/npu-dma.c | 81 ++--
>>  3 files changed, 64 insertions(+), 34 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/pci-bridge.h 
>> b/arch/powerpc/include/asm/pci-bridge.h
>> index 94d4490..aee4fcc 100644
>> --- a/arch/powerpc/include/asm/pci-bridge.h
>> +++ b/arch/powerpc/include/asm/pci-bridge.h
>> @@ -129,6 +129,7 @@ struct pci_controller {
>>  #endif  /* CONFIG_PPC64 */
>>  
>>  void *private_data;
>> +struct npu *npu;
>>  };
>>  
>>  /* These are used for config access before all the PCI probing
>> diff --git a/arch/powerpc/platforms/powernv/pci.h 
>> b/arch/powerpc/platforms/powernv/pci.h
>> index 2131373..f2d50974 100644
>> --- a/arch/powerpc/platforms/powernv/pci.h
>> +++ b/arch/powerpc/platforms/powernv/pci.h
>> @@ -8,9 +8,6 @@
>>  
>>  struct pci_dn;
>>  
>> -/* Maximum possible number of ATSD MMIO registers per NPU */
>> -#define NV_NMMU_ATSD_REGS 8
>> -
>>  enum pnv_phb_type {
>>  PNV_PHB_IODA1   = 0,
>>  PNV_PHB_IODA2   = 1,
>> @@ -176,19 +173,6 @@ struct pnv_phb {
>>  unsigned intdiag_data_size;
>>  u8  *diag_data;
>>  
>> -/* Nvlink2 data */
>> -struct npu {
>> -int index;
>> -__be64 *mmio_atsd_regs[NV_NMMU_ATSD_REGS];
>> -unsigned int mmio_atsd_count;
>> -
>> -/* Bitmask for MMIO register usage */
>> -unsigned long mmio_atsd_usage;
>> -
>> -/* Do we need to explicitly flush the nest mmu? */
>> -bool nmmu_flush;
>> -} npu;
>> -
>>  int p2p_target_count;
>>  };
>>  
>> diff --git a/arch/powerpc/platforms/powernv/npu-dma.c 
>> b/arch/powerpc/platforms/powernv/npu-dma.c
>> index 91d488f..7dd5c0e5 100644
>> --- a/arch/powerpc/platforms/powernv/npu-dma.c
>> +++ b/arch/powerpc/platforms/powernv/npu-dma.c
>> @@ -327,6 +327,25 @@ struct pnv_ioda_pe *pnv_pci_npu_setup_iommu(struct 
>> pnv_ioda_pe *npe)
>>  return gpe;
>>  }
>>  
>> +/*
>> + * NPU2 ATS
>> + */
>> +/* Maximum possible number of ATSD MMIO registers per NPU */
>> +#define NV_NMMU_ATSD_REGS 8
>> +
>> +/* An NPU descriptor, valid for POWER9 only */
>> +struct npu {
>> +int index;
>> +__be64 *mmio_atsd_regs[NV_NMMU_ATSD_REGS];
>> +unsigned int mmio_atsd_count;
>> +
>> +/* Bitmask for MMIO register usage */
>> +unsigned long mmio_atsd_usage;
>> +
>> +/* Do we need to explicitly flush the nest mmu? */
>> +bool nmmu_flush;
>> +};
>> +
>>  /* Maximum number of nvlinks per npu */
>>  #define NV_MAX_LINKS 6
>>  
>> @@ -478,7 +497,6 @@ static void acquire_atsd_reg(struct npu_context 
>> *npu_context,
>>  int i, j;
>>  struct npu *npu;
>>  struct pci_dev *npdev;
>> -struct pnv_phb *nphb;
>>  
>>  for (i = 0; i <= max_npu2_index; i++) {
>>  mmio_atsd_reg[i].reg = -1;
>> @@ -493,8 +511,10 @@ static void acquire_atsd_reg(struct npu_context 
>> *npu_context,
>>  if (!npdev)
>>  continue;
>>  
>> -nphb = pci_bus_to_host(npdev->bus)->private_data;
>> -npu = >npu;
>> +npu = pci_bus_to_host(npdev->bus)->npu;
>> +if (!npu)
>> +continue;
> 
> This patch changes a bunch of places that used to unconditionally
> locate an NPU now have a failure path.
> 
> Given that this used to always have an NPU, doesn't that mean that if
> the NPU is not present something has already gone wrong, and we should
> WARN_ON() or something?



That means this is a leftover since I dropped that npdev_to_npu helper
which could help but there was no real value in it. I'll remove the
check here in the next respin.

I'll probably add checks for npu!=NULL where we used to have
firmware_has_feature(FW_FEATURE_OPAL) in 05/19.



-- 
Alexey


Re: [PATCH kernel v4 04/19] powerpc/powernv: Move npu struct from pnv_phb to pci_controller

2018-12-04 Thread David Gibson
On Fri, Nov 23, 2018 at 04:52:49PM +1100, Alexey Kardashevskiy wrote:
> The powernv PCI code stores NPU data in the pnv_phb struct. The latter
> is referenced by pci_controller::private_data. We are going to have NPU2
> support in the pseries platform as well but it does not store any
> private_data in in the pci_controller struct; and even if it did,
> it would be a different data structure.
> 
> This makes npu a pointer and stores it one level higher in
> the pci_controller struct.
> 
> Signed-off-by: Alexey Kardashevskiy 
> ---
> Changes:
> v4:
> * changed subj from "powerpc/powernv: Detach npu struct from pnv_phb"
> * got rid of global list of npus - store them now in pci_controller
> * got rid of npdev_to_npu() helper
> ---
>  arch/powerpc/include/asm/pci-bridge.h|  1 +
>  arch/powerpc/platforms/powernv/pci.h | 16 -
>  arch/powerpc/platforms/powernv/npu-dma.c | 81 ++--
>  3 files changed, 64 insertions(+), 34 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/pci-bridge.h 
> b/arch/powerpc/include/asm/pci-bridge.h
> index 94d4490..aee4fcc 100644
> --- a/arch/powerpc/include/asm/pci-bridge.h
> +++ b/arch/powerpc/include/asm/pci-bridge.h
> @@ -129,6 +129,7 @@ struct pci_controller {
>  #endif   /* CONFIG_PPC64 */
>  
>   void *private_data;
> + struct npu *npu;
>  };
>  
>  /* These are used for config access before all the PCI probing
> diff --git a/arch/powerpc/platforms/powernv/pci.h 
> b/arch/powerpc/platforms/powernv/pci.h
> index 2131373..f2d50974 100644
> --- a/arch/powerpc/platforms/powernv/pci.h
> +++ b/arch/powerpc/platforms/powernv/pci.h
> @@ -8,9 +8,6 @@
>  
>  struct pci_dn;
>  
> -/* Maximum possible number of ATSD MMIO registers per NPU */
> -#define NV_NMMU_ATSD_REGS 8
> -
>  enum pnv_phb_type {
>   PNV_PHB_IODA1   = 0,
>   PNV_PHB_IODA2   = 1,
> @@ -176,19 +173,6 @@ struct pnv_phb {
>   unsigned intdiag_data_size;
>   u8  *diag_data;
>  
> - /* Nvlink2 data */
> - struct npu {
> - int index;
> - __be64 *mmio_atsd_regs[NV_NMMU_ATSD_REGS];
> - unsigned int mmio_atsd_count;
> -
> - /* Bitmask for MMIO register usage */
> - unsigned long mmio_atsd_usage;
> -
> - /* Do we need to explicitly flush the nest mmu? */
> - bool nmmu_flush;
> - } npu;
> -
>   int p2p_target_count;
>  };
>  
> diff --git a/arch/powerpc/platforms/powernv/npu-dma.c 
> b/arch/powerpc/platforms/powernv/npu-dma.c
> index 91d488f..7dd5c0e5 100644
> --- a/arch/powerpc/platforms/powernv/npu-dma.c
> +++ b/arch/powerpc/platforms/powernv/npu-dma.c
> @@ -327,6 +327,25 @@ struct pnv_ioda_pe *pnv_pci_npu_setup_iommu(struct 
> pnv_ioda_pe *npe)
>   return gpe;
>  }
>  
> +/*
> + * NPU2 ATS
> + */
> +/* Maximum possible number of ATSD MMIO registers per NPU */
> +#define NV_NMMU_ATSD_REGS 8
> +
> +/* An NPU descriptor, valid for POWER9 only */
> +struct npu {
> + int index;
> + __be64 *mmio_atsd_regs[NV_NMMU_ATSD_REGS];
> + unsigned int mmio_atsd_count;
> +
> + /* Bitmask for MMIO register usage */
> + unsigned long mmio_atsd_usage;
> +
> + /* Do we need to explicitly flush the nest mmu? */
> + bool nmmu_flush;
> +};
> +
>  /* Maximum number of nvlinks per npu */
>  #define NV_MAX_LINKS 6
>  
> @@ -478,7 +497,6 @@ static void acquire_atsd_reg(struct npu_context 
> *npu_context,
>   int i, j;
>   struct npu *npu;
>   struct pci_dev *npdev;
> - struct pnv_phb *nphb;
>  
>   for (i = 0; i <= max_npu2_index; i++) {
>   mmio_atsd_reg[i].reg = -1;
> @@ -493,8 +511,10 @@ static void acquire_atsd_reg(struct npu_context 
> *npu_context,
>   if (!npdev)
>   continue;
>  
> - nphb = pci_bus_to_host(npdev->bus)->private_data;
> - npu = >npu;
> + npu = pci_bus_to_host(npdev->bus)->npu;
> + if (!npu)
> + continue;

This patch changes a bunch of places that used to unconditionally
locate an NPU now have a failure path.

Given that this used to always have an NPU, doesn't that mean that if
the NPU is not present something has already gone wrong, and we should
WARN_ON() or something?

>   mmio_atsd_reg[i].npu = npu;
>   mmio_atsd_reg[i].reg = get_mmio_atsd_reg(npu);
>   while (mmio_atsd_reg[i].reg < 0) {
> @@ -662,6 +682,7 @@ struct npu_context *pnv_npu2_init_context(struct pci_dev 
> *gpdev,
>   struct pnv_phb *nphb;
>   struct npu *npu;
>   struct npu_context *npu_context;
> + struct pci_controller *hose;
>  
>   /*
>* At present we don't support GPUs connected to multiple NPUs and I'm
> @@ -689,8 +710,11 @@ struct npu_context *pnv_npu2_init_context(struct pci_dev 
> *gpdev,
>   return ERR_PTR(-EINVAL);
>   }
>  
> -   

Re: [PATCH V3 2/5] mm: update ptep_modify_prot_commit to take old pte value as arg

2018-12-04 Thread Christophe LEROY




Le 05/12/2018 à 05:06, Aneesh Kumar K.V a écrit :

On 12/5/18 9:32 AM, Christophe LEROY wrote:



Le 05/12/2018 à 04:09, Aneesh Kumar K.V a écrit :
Architectures like ppc64 requires to do a conditional tlb flush based 
on the old

and new value of pte. Enable that by passing old pte value as the arg.

Signed-off-by: Aneesh Kumar K.V 
---
  arch/s390/include/asm/pgtable.h | 3 ++-
  arch/s390/mm/pgtable.c  | 2 +-
  arch/x86/include/asm/paravirt.h | 2 +-
  fs/proc/task_mmu.c  | 8 +---
  include/asm-generic/pgtable.h   | 2 +-
  mm/memory.c | 8 
  mm/mprotect.c   | 6 +++---
  7 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/arch/s390/include/asm/pgtable.h 
b/arch/s390/include/asm/pgtable.h

index 5d730199e37b..76dc344edb8c 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -1070,7 +1070,8 @@ static inline pte_t ptep_get_and_clear(struct 
mm_struct *mm,

  #define __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION
  pte_t ptep_modify_prot_start(struct vm_area_struct *, unsigned 
long, pte_t *);
-void ptep_modify_prot_commit(struct vm_area_struct *, unsigned long, 
pte_t *, pte_t);

+void ptep_modify_prot_commit(struct vm_area_struct *, unsigned long,
+ pte_t *, pte_t, pte_t);
  #define __HAVE_ARCH_PTEP_CLEAR_FLUSH
  static inline pte_t ptep_clear_flush(struct vm_area_struct *vma,
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index 29c0a21cd34a..b283b92722cc 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -322,7 +322,7 @@ pte_t ptep_modify_prot_start(struct 
vm_area_struct *vma, unsigned long addr,

  EXPORT_SYMBOL(ptep_modify_prot_start);
  void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned 
long addr,

- pte_t *ptep, pte_t pte)
+ pte_t *ptep, pte_t old_pte, pte_t pte)
  {
  pgste_t pgste;
  struct mm_struct *mm = vma->vm_mm;
diff --git a/arch/x86/include/asm/paravirt.h 
b/arch/x86/include/asm/paravirt.h

index 1154f154025d..0d75a4f60500 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -429,7 +429,7 @@ static inline pte_t ptep_modify_prot_start(struct 
vm_area_struct *vma, unsigned

  }
  static inline void ptep_modify_prot_commit(struct vm_area_struct 
*vma, unsigned long addr,

-   pte_t *ptep, pte_t pte)
+   pte_t *ptep, pte_t old_pte, pte_t pte)
  {
  struct mm_struct *mm = vma->vm_mm;
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 9952d7185170..8d62891d38a8 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -940,10 +940,12 @@ static inline void clear_soft_dirty(struct 
vm_area_struct *vma,

  pte_t ptent = *pte;
  if (pte_present(ptent)) {
-    ptent = ptep_modify_prot_start(vma, addr, pte);
-    ptent = pte_wrprotect(ptent);
+    pte_t old_pte;
+
+    old_pte = ptep_modify_prot_start(vma, addr, pte);
+    ptent = pte_wrprotect(old_pte);


This change doesn't seem to fit with the commit description. Why write 
protecting in addition to clearing dirty ?





The hunk above use a new variable old_pte. There is no functional change 
in that hunk.




Oops, sorry, I misread the patch, don't know why.

Christophe


Re: [PATCH] arch/powerpc: Use dma_zalloc_coherent

2018-12-04 Thread Sabyasachi Gupta
On Mon, Nov 5, 2018 at 7:52 AM Sabyasachi Gupta
 wrote:
>
> Replaced dma_alloc_coherent + memset with dma_zalloc_coherent
>
> Signed-off-by: Sabyasachi Gupta 

Any comment on this patch?

> ---
>  arch/powerpc/sysdev/fsl_rmu.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/fsl_rmu.c b/arch/powerpc/sysdev/fsl_rmu.c
> index 88b35a3d..8b0ebf3 100644
> --- a/arch/powerpc/sysdev/fsl_rmu.c
> +++ b/arch/powerpc/sysdev/fsl_rmu.c
> @@ -756,15 +756,13 @@ fsl_open_outb_mbox(struct rio_mport *mport, void 
> *dev_id, int mbox, int entries)
> }
>
> /* Initialize outbound message descriptor ring */
> -   rmu->msg_tx_ring.virt = dma_alloc_coherent(priv->dev,
> +   rmu->msg_tx_ring.virt = dma_zalloc_coherent(priv->dev,
> rmu->msg_tx_ring.size * RIO_MSG_DESC_SIZE,
> >msg_tx_ring.phys, GFP_KERNEL);
> if (!rmu->msg_tx_ring.virt) {
> rc = -ENOMEM;
> goto out_dma;
> }
> -   memset(rmu->msg_tx_ring.virt, 0,
> -   rmu->msg_tx_ring.size * RIO_MSG_DESC_SIZE);
> rmu->msg_tx_ring.tx_slot = 0;
>
> /* Point dequeue/enqueue pointers at first entry in ring */
> --
> 2.7.4
>


[PATCH 2/2] kgdb/treewide: constify struct kgdb_arch arch_kgdb_ops

2018-12-04 Thread Christophe Leroy
checkpatch.pl reports the following:

  WARNING: struct kgdb_arch should normally be const
  #28: FILE: arch/mips/kernel/kgdb.c:397:
  +struct kgdb_arch arch_kgdb_ops = {

This report makes sense, as all other ops struct, this
one should also be const. This patch does the change.

Signed-off-by: Christophe Leroy 
---
 arch/arc/kernel/kgdb.c| 2 +-
 arch/arm/kernel/kgdb.c| 2 +-
 arch/arm64/kernel/kgdb.c  | 2 +-
 arch/h8300/kernel/kgdb.c  | 2 +-
 arch/hexagon/kernel/kgdb.c| 2 +-
 arch/microblaze/kernel/kgdb.c | 2 +-
 arch/mips/kernel/kgdb.c   | 2 +-
 arch/nios2/kernel/kgdb.c  | 2 +-
 arch/powerpc/kernel/kgdb.c| 2 +-
 arch/sh/kernel/kgdb.c | 2 +-
 arch/sparc/kernel/kgdb_32.c   | 2 +-
 arch/sparc/kernel/kgdb_64.c   | 2 +-
 arch/x86/kernel/kgdb.c| 2 +-
 include/linux/kgdb.h  | 2 +-
 14 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/arc/kernel/kgdb.c b/arch/arc/kernel/kgdb.c
index 9a3c34af2ae8..bfd04b442e36 100644
--- a/arch/arc/kernel/kgdb.c
+++ b/arch/arc/kernel/kgdb.c
@@ -204,7 +204,7 @@ void kgdb_roundup_cpus(unsigned long flags)
local_irq_disable();
 }
 
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
/* breakpoint instruction: TRAP_S 0x3 */
 #ifdef CONFIG_CPU_BIG_ENDIAN
.gdb_bpt_instr  = {0x78, 0x7e},
diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
index caa0dbe3dc61..21a6d5958955 100644
--- a/arch/arm/kernel/kgdb.c
+++ b/arch/arm/kernel/kgdb.c
@@ -274,7 +274,7 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
  * and we handle the normal undef case within the do_undefinstr
  * handler.
  */
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
 #ifndef __ARMEB__
.gdb_bpt_instr  = {0xfe, 0xde, 0xff, 0xe7}
 #else /* ! __ARMEB__ */
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index a20de58061a8..fe1d1f935b90 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -357,7 +357,7 @@ void kgdb_arch_exit(void)
unregister_die_notifier(_notifier);
 }
 
-struct kgdb_arch arch_kgdb_ops;
+const struct kgdb_arch arch_kgdb_ops;
 
 int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
 {
diff --git a/arch/h8300/kernel/kgdb.c b/arch/h8300/kernel/kgdb.c
index 1a1d30cb0609..602e478afbd5 100644
--- a/arch/h8300/kernel/kgdb.c
+++ b/arch/h8300/kernel/kgdb.c
@@ -129,7 +129,7 @@ void kgdb_arch_exit(void)
/* Nothing to do */
 }
 
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
/* Breakpoint instruction: trapa #2 */
.gdb_bpt_instr = { 0x57, 0x20 },
 };
diff --git a/arch/hexagon/kernel/kgdb.c b/arch/hexagon/kernel/kgdb.c
index 16c24b22d0b2..f1924d483e78 100644
--- a/arch/hexagon/kernel/kgdb.c
+++ b/arch/hexagon/kernel/kgdb.c
@@ -83,7 +83,7 @@ struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] = {
{ "syscall_nr", GDB_SIZEOF_REG, offsetof(struct pt_regs, syscall_nr)},
 };
 
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
/* trap0(#0xDB) 0x0cdb0054 */
.gdb_bpt_instr = {0x54, 0x00, 0xdb, 0x0c},
 };
diff --git a/arch/microblaze/kernel/kgdb.c b/arch/microblaze/kernel/kgdb.c
index 6366f69d118e..130cd0f064ce 100644
--- a/arch/microblaze/kernel/kgdb.c
+++ b/arch/microblaze/kernel/kgdb.c
@@ -143,7 +143,7 @@ void kgdb_arch_exit(void)
 /*
  * Global data
  */
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
 #ifdef __MICROBLAZEEL__
.gdb_bpt_instr = {0x18, 0x00, 0x0c, 0xba}, /* brki r16, 0x18 */
 #else
diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
index 31eff1bec577..edfdc2ec2d16 100644
--- a/arch/mips/kernel/kgdb.c
+++ b/arch/mips/kernel/kgdb.c
@@ -394,7 +394,7 @@ int kgdb_arch_handle_exception(int vector, int signo, int 
err_code,
return -1;
 }
 
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
 #ifdef CONFIG_CPU_BIG_ENDIAN
.gdb_bpt_instr = { spec_op << 2, 0x00, 0x00, break_op },
 #else
diff --git a/arch/nios2/kernel/kgdb.c b/arch/nios2/kernel/kgdb.c
index 117859122d1c..37b25f844a2d 100644
--- a/arch/nios2/kernel/kgdb.c
+++ b/arch/nios2/kernel/kgdb.c
@@ -165,7 +165,7 @@ void kgdb_arch_exit(void)
/* Nothing to do */
 }
 
-struct kgdb_arch arch_kgdb_ops = {
+const struct kgdb_arch arch_kgdb_ops = {
/* Breakpoint instruction: trap 30 */
.gdb_bpt_instr = { 0xba, 0x6f, 0x3b, 0x00 },
 };
diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
index 59c578f865aa..bdb588b1d8fb 100644
--- a/arch/powerpc/kernel/kgdb.c
+++ b/arch/powerpc/kernel/kgdb.c
@@ -477,7 +477,7 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
 /*
  * Global data
  */
-struct kgdb_arch arch_kgdb_ops;
+const struct kgdb_arch arch_kgdb_ops;
 
 static int kgdb_not_implemented(struct pt_regs *regs)
 {
diff --git a/arch/sh/kernel/kgdb.c b/arch/sh/kernel/kgdb.c
index 4f04c6638a4d..a24c48446e98 

[PATCH 1/2] mips/kgdb: prepare arch_kgdb_ops for constness

2018-12-04 Thread Christophe Leroy
MIPS is the only architecture modifying arch_kgdb_ops during init.
This patch makes the init static, so that it can be changed to
const in following patch, as recommended by checkpatch.pl

Suggested-by: Paul Burton 
Signed-off-by: Christophe Leroy 
---
 arch/mips/kernel/kgdb.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
index eb6c0d582626..31eff1bec577 100644
--- a/arch/mips/kernel/kgdb.c
+++ b/arch/mips/kernel/kgdb.c
@@ -394,18 +394,16 @@ int kgdb_arch_handle_exception(int vector, int signo, int 
err_code,
return -1;
 }
 
-struct kgdb_arch arch_kgdb_ops;
+struct kgdb_arch arch_kgdb_ops = {
+#ifdef CONFIG_CPU_BIG_ENDIAN
+   .gdb_bpt_instr = { spec_op << 2, 0x00, 0x00, break_op },
+#else
+   .gdb_bpt_instr = { break_op, 0x00, 0x00, spec_op << 2 },
+#endif
+};
 
 int kgdb_arch_init(void)
 {
-   union mips_instruction insn = {
-   .r_format = {
-   .opcode = spec_op,
-   .func   = break_op,
-   }
-   };
-   memcpy(arch_kgdb_ops.gdb_bpt_instr, insn.byte, BREAK_INSTR_SIZE);
-
register_die_notifier(_notifier);
 
return 0;
-- 
2.13.3



Re: [PATCH kernel v4 01/19] powerpc/ioda/npu: Call skiboot's hot reset hook when disabling NPU2

2018-12-04 Thread David Gibson
On Fri, Nov 23, 2018 at 04:52:46PM +1100, Alexey Kardashevskiy wrote:
> The skiboot firmware has a hot reset handler which fences the NVIDIA V100
> GPU RAM on Witherspoons and makes accesses no-op instead of throwing HMIs:
> https://github.com/open-power/skiboot/commit/fca2b2b839a67
> 
> Now we are going to pass V100 via VFIO which most certainly involves
> KVM guests which are often terminated without getting a chance to offline
> GPU RAM so we end up with a running machine with misconfigured memory.
> Accessing this memory produces hardware management interrupts (HMI)
> which bring the host down.
> 
> To suppress HMIs, this wires up this hot reset hook to vfio_pci_disable()
> via pci_disable_device() which switches NPU2 to a safe mode and prevents
> HMIs.
> 
> Signed-off-by: Alexey Kardashevskiy 
> Acked-by: Alistair Popple 

Reviewed-by: David Gibson 

> ---
> Changes:
> v2:
> * updated the commit log
> ---
>  arch/powerpc/platforms/powernv/pci-ioda.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 9ee7a30..29c6837 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -3676,6 +3676,15 @@ static void pnv_pci_release_device(struct pci_dev 
> *pdev)
>   pnv_ioda_release_pe(pe);
>  }
>  
> +static void pnv_npu_disable_device(struct pci_dev *pdev)
> +{
> + struct eeh_dev *edev = pci_dev_to_eeh_dev(pdev);
> + struct eeh_pe *eehpe = edev ? edev->pe : NULL;
> +
> + if (eehpe && eeh_ops && eeh_ops->reset)
> + eeh_ops->reset(eehpe, EEH_RESET_HOT);
> +}
> +
>  static void pnv_pci_ioda_shutdown(struct pci_controller *hose)
>  {
>   struct pnv_phb *phb = hose->private_data;
> @@ -3720,6 +3729,7 @@ static const struct pci_controller_ops 
> pnv_npu_ioda_controller_ops = {
>   .reset_secondary_bus= pnv_pci_reset_secondary_bus,
>   .dma_set_mask   = pnv_npu_dma_set_mask,
>   .shutdown   = pnv_pci_ioda_shutdown,
> + .disable_device = pnv_npu_disable_device,
>  };
>  
>  static const struct pci_controller_ops pnv_npu_ocapi_ioda_controller_ops = {

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [PATCH kernel v4 03/19] powerpc/vfio/iommu/kvm: Do not pin device memory

2018-12-04 Thread David Gibson
On Fri, Nov 23, 2018 at 04:52:48PM +1100, Alexey Kardashevskiy wrote:
> This new memory does not have page structs as it is not plugged to
> the host so gup() will fail anyway.
> 
> This adds 2 helpers:
> - mm_iommu_newdev() to preregister the "memory device" memory so
> the rest of API can still be used;
> - mm_iommu_is_devmem() to know if the physical address is one of thise
> new regions which we must avoid unpinning of.
> 
> This adds @mm to tce_page_is_contained() and iommu_tce_xchg() to test
> if the memory is device memory to avoid pfn_to_page().
> 
> This adds a check for device memory in mm_iommu_ua_mark_dirty_rm() which
> does delayed pages dirtying.
> 
> Signed-off-by: Alexey Kardashevskiy 

Reviewed-by: David Gibson 

> ---
> Changes:
> v4:
> * added device memory check in the real mode path
> ---
>  arch/powerpc/include/asm/iommu.h   |  5 +-
>  arch/powerpc/include/asm/mmu_context.h |  5 ++
>  arch/powerpc/kernel/iommu.c|  9 ++-
>  arch/powerpc/kvm/book3s_64_vio.c   | 18 +++---
>  arch/powerpc/mm/mmu_context_iommu.c| 86 +++---
>  drivers/vfio/vfio_iommu_spapr_tce.c| 28 ++---
>  6 files changed, 119 insertions(+), 32 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/iommu.h 
> b/arch/powerpc/include/asm/iommu.h
> index 35db0cb..a8aeac0 100644
> --- a/arch/powerpc/include/asm/iommu.h
> +++ b/arch/powerpc/include/asm/iommu.h
> @@ -218,8 +218,9 @@ extern void iommu_register_group(struct iommu_table_group 
> *table_group,
>  extern int iommu_add_device(struct device *dev);
>  extern void iommu_del_device(struct device *dev);
>  extern int __init tce_iommu_bus_notifier_init(void);
> -extern long iommu_tce_xchg(struct iommu_table *tbl, unsigned long entry,
> - unsigned long *hpa, enum dma_data_direction *direction);
> +extern long iommu_tce_xchg(struct mm_struct *mm, struct iommu_table *tbl,
> + unsigned long entry, unsigned long *hpa,
> + enum dma_data_direction *direction);
>  #else
>  static inline void iommu_register_group(struct iommu_table_group 
> *table_group,
>   int pci_domain_number,
> diff --git a/arch/powerpc/include/asm/mmu_context.h 
> b/arch/powerpc/include/asm/mmu_context.h
> index 2d6b00d..f0f9f3d 100644
> --- a/arch/powerpc/include/asm/mmu_context.h
> +++ b/arch/powerpc/include/asm/mmu_context.h
> @@ -24,6 +24,9 @@ extern bool mm_iommu_preregistered(struct mm_struct *mm);
>  extern long mm_iommu_new(struct mm_struct *mm,
>   unsigned long ua, unsigned long entries,
>   struct mm_iommu_table_group_mem_t **pmem);
> +extern long mm_iommu_newdev(struct mm_struct *mm, unsigned long ua,
> + unsigned long entries, unsigned long dev_hpa,
> + struct mm_iommu_table_group_mem_t **pmem);
>  extern long mm_iommu_put(struct mm_struct *mm,
>   struct mm_iommu_table_group_mem_t *mem);
>  extern void mm_iommu_init(struct mm_struct *mm);
> @@ -39,6 +42,8 @@ extern long mm_iommu_ua_to_hpa(struct 
> mm_iommu_table_group_mem_t *mem,
>  extern long mm_iommu_ua_to_hpa_rm(struct mm_iommu_table_group_mem_t *mem,
>   unsigned long ua, unsigned int pageshift, unsigned long *hpa);
>  extern void mm_iommu_ua_mark_dirty_rm(struct mm_struct *mm, unsigned long 
> ua);
> +extern bool mm_iommu_is_devmem(struct mm_struct *mm, unsigned long hpa,
> + unsigned int pageshift);
>  extern long mm_iommu_mapped_inc(struct mm_iommu_table_group_mem_t *mem);
>  extern void mm_iommu_mapped_dec(struct mm_iommu_table_group_mem_t *mem);
>  #endif
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index f0dc680..8ccfdd9 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -47,6 +47,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define DBG(...)
>  
> @@ -993,15 +994,17 @@ int iommu_tce_check_gpa(unsigned long page_shift, 
> unsigned long gpa)
>  }
>  EXPORT_SYMBOL_GPL(iommu_tce_check_gpa);
>  
> -long iommu_tce_xchg(struct iommu_table *tbl, unsigned long entry,
> - unsigned long *hpa, enum dma_data_direction *direction)
> +long iommu_tce_xchg(struct mm_struct *mm, struct iommu_table *tbl,
> + unsigned long entry, unsigned long *hpa,
> + enum dma_data_direction *direction)
>  {
>   long ret;
>  
>   ret = tbl->it_ops->exchange(tbl, entry, hpa, direction);
>  
>   if (!ret && ((*direction == DMA_FROM_DEVICE) ||
> - (*direction == DMA_BIDIRECTIONAL)))
> + (*direction == DMA_BIDIRECTIONAL)) &&
> + !mm_iommu_is_devmem(mm, *hpa, tbl->it_page_shift))
>   SetPageDirty(pfn_to_page(*hpa >> PAGE_SHIFT));
>  
>   /* if (unlikely(ret))
> diff --git a/arch/powerpc/kvm/book3s_64_vio.c 
> b/arch/powerpc/kvm/book3s_64_vio.c
> index 62a8d03..532ab797 100644
> --- a/arch/powerpc/kvm/book3s_64_vio.c
> +++ b/arch/powerpc/kvm/book3s_64_vio.c
> @@ 

Re: [PATCH kernel v4 02/19] powerpc/mm/iommu/vfio_spapr_tce: Change mm_iommu_get to reference a region

2018-12-04 Thread David Gibson
On Fri, Nov 23, 2018 at 04:52:47PM +1100, Alexey Kardashevskiy wrote:
> Normally mm_iommu_get() is supposed to add a reference and
> mm_iommu_put() to remove it. However historically mm_iommu_find() does
> the referencing and mm_iommu_get() is doing allocation and referencing.
> 
> We are going to add another helper to preregister device memory so
> instead of having mm_iommu_new() which pre-registers the normal memory
> and references the region, we need separate helpers for pre-registering
> and referencing.
> 
> This renames:
> - mm_iommu_get to mm_iommu_new;
> - mm_iommu_find to mm_iommu_get.
> 
> To make the mm_iommu_get name reflect what it is supposed to do, this
> changes mm_iommu_get() to reference the region so from now on for every
> mm_iommu_get() we need a matching mm_iommu_put().
> 
> This removes the check for exact match as the check for overlap is
> enough now.
> 
> Signed-off-by: Alexey Kardashevskiy 

Reviewed-by: David Gibson 

> ---
> Changes:
> v4:
> * squashed "powerpc/mm/iommu: Make mm_iommu_new() fail on existing regions" 
> into this
> 
> v2:
> * merged 2 patches into one
> ---
>  arch/powerpc/include/asm/mmu_context.h |  4 +--
>  arch/powerpc/mm/mmu_context_iommu.c| 19 +++--
>  drivers/vfio/vfio_iommu_spapr_tce.c| 37 +-
>  3 files changed, 35 insertions(+), 25 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/mmu_context.h 
> b/arch/powerpc/include/asm/mmu_context.h
> index 0381394..2d6b00d 100644
> --- a/arch/powerpc/include/asm/mmu_context.h
> +++ b/arch/powerpc/include/asm/mmu_context.h
> @@ -21,7 +21,7 @@ struct mm_iommu_table_group_mem_t;
>  
>  extern int isolate_lru_page(struct page *page);  /* from internal.h */
>  extern bool mm_iommu_preregistered(struct mm_struct *mm);
> -extern long mm_iommu_get(struct mm_struct *mm,
> +extern long mm_iommu_new(struct mm_struct *mm,
>   unsigned long ua, unsigned long entries,
>   struct mm_iommu_table_group_mem_t **pmem);
>  extern long mm_iommu_put(struct mm_struct *mm,
> @@ -32,7 +32,7 @@ extern struct mm_iommu_table_group_mem_t 
> *mm_iommu_lookup(struct mm_struct *mm,
>   unsigned long ua, unsigned long size);
>  extern struct mm_iommu_table_group_mem_t *mm_iommu_lookup_rm(
>   struct mm_struct *mm, unsigned long ua, unsigned long size);
> -extern struct mm_iommu_table_group_mem_t *mm_iommu_find(struct mm_struct *mm,
> +extern struct mm_iommu_table_group_mem_t *mm_iommu_get(struct mm_struct *mm,
>   unsigned long ua, unsigned long entries);
>  extern long mm_iommu_ua_to_hpa(struct mm_iommu_table_group_mem_t *mem,
>   unsigned long ua, unsigned int pageshift, unsigned long *hpa);
> diff --git a/arch/powerpc/mm/mmu_context_iommu.c 
> b/arch/powerpc/mm/mmu_context_iommu.c
> index 1d5161f..580d89e 100644
> --- a/arch/powerpc/mm/mmu_context_iommu.c
> +++ b/arch/powerpc/mm/mmu_context_iommu.c
> @@ -89,7 +89,7 @@ bool mm_iommu_preregistered(struct mm_struct *mm)
>  }
>  EXPORT_SYMBOL_GPL(mm_iommu_preregistered);
>  
> -long mm_iommu_get(struct mm_struct *mm, unsigned long ua, unsigned long 
> entries,
> +long mm_iommu_new(struct mm_struct *mm, unsigned long ua, unsigned long 
> entries,
>   struct mm_iommu_table_group_mem_t **pmem)
>  {
>   struct mm_iommu_table_group_mem_t *mem;
> @@ -102,12 +102,6 @@ long mm_iommu_get(struct mm_struct *mm, unsigned long 
> ua, unsigned long entries,
>  
>   list_for_each_entry_rcu(mem, >context.iommu_group_mem_list,
>   next) {
> - if ((mem->ua == ua) && (mem->entries == entries)) {
> - ++mem->used;
> - *pmem = mem;
> - goto unlock_exit;
> - }
> -
>   /* Overlap? */
>   if ((mem->ua < (ua + (entries << PAGE_SHIFT))) &&
>   (ua < (mem->ua +
> @@ -202,7 +196,7 @@ long mm_iommu_get(struct mm_struct *mm, unsigned long ua, 
> unsigned long entries,
>  
>   return ret;
>  }
> -EXPORT_SYMBOL_GPL(mm_iommu_get);
> +EXPORT_SYMBOL_GPL(mm_iommu_new);
>  
>  static void mm_iommu_unpin(struct mm_iommu_table_group_mem_t *mem)
>  {
> @@ -318,21 +312,26 @@ struct mm_iommu_table_group_mem_t 
> *mm_iommu_lookup_rm(struct mm_struct *mm,
>   return ret;
>  }
>  
> -struct mm_iommu_table_group_mem_t *mm_iommu_find(struct mm_struct *mm,
> +struct mm_iommu_table_group_mem_t *mm_iommu_get(struct mm_struct *mm,
>   unsigned long ua, unsigned long entries)
>  {
>   struct mm_iommu_table_group_mem_t *mem, *ret = NULL;
>  
> + mutex_lock(_list_mutex);
> +
>   list_for_each_entry_rcu(mem, >context.iommu_group_mem_list, next) {
>   if ((mem->ua == ua) && (mem->entries == entries)) {
>   ret = mem;
> + ++mem->used;
>   break;
>   }
>   }
>  
> + mutex_unlock(_list_mutex);
> +
>   return ret;
>  }
> 

Re: [PATCH v2 13/34] dt-bindings: arm: amlogic: Move 'amlogic,meson-gx-ao-secure' binding to its own file

2018-12-04 Thread Rob Herring
On Tue, Dec 4, 2018 at 7:01 PM Kevin Hilman  wrote:
>
> Rob Herring  writes:
>
> > It is best practice to have 1 binding per file, so board level bindings
> > should be separate for various misc SoC bindings.
> >
> > Cc: Mark Rutland 
> > Cc: Carlo Caione 
> > Cc: Kevin Hilman 
> > Cc: devicet...@vger.kernel.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-amlo...@lists.infradead.org
> > Signed-off-by: Rob Herring 
> > ---
> >  .../devicetree/bindings/arm/amlogic.txt   | 29 ---
> >  .../amlogic/amlogic,meson-gx-ao-secure.txt| 28 ++
> >  2 files changed, 28 insertions(+), 29 deletions(-)
> >  create mode 100644 
> > Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
>
> Acked-by: Kevin Hilman 
>
> But this isn't really related to the schema series is it?  If you
> prefer, I can just queue this one separately via my tree.

Yes, you can take it.

Rob


[PATCH V3 updated] arch/powerpc/mm/hugetlb: NestMMU workaround for hugetlb mprotect RW upgrade

2018-12-04 Thread Aneesh Kumar K.V
NestMMU requires us to mark the pte invalid and flush the tlb when we do a
RW upgrade of pte. We fixed a variant of this in the fault path in commit
Fixes: bd5050e38aec ("powerpc/mm/radix: Change pte relax sequence to handle 
nest MMU hang")

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/book3s/64/hugetlb.h | 12 +
 arch/powerpc/mm/hugetlbpage-hash64.c | 27 
 arch/powerpc/mm/hugetlbpage-radix.c  | 17 
 3 files changed, 56 insertions(+)

diff --git a/arch/powerpc/include/asm/book3s/64/hugetlb.h 
b/arch/powerpc/include/asm/book3s/64/hugetlb.h
index 5b0177733994..66c1e4f88d65 100644
--- a/arch/powerpc/include/asm/book3s/64/hugetlb.h
+++ b/arch/powerpc/include/asm/book3s/64/hugetlb.h
@@ -13,6 +13,10 @@ radix__hugetlb_get_unmapped_area(struct file *file, unsigned 
long addr,
unsigned long len, unsigned long pgoff,
unsigned long flags);
 
+extern void radix__huge_ptep_modify_prot_commit(struct vm_area_struct *vma,
+   unsigned long addr, pte_t *ptep,
+   pte_t old_pte, pte_t pte);
+
 static inline int hstate_get_psize(struct hstate *hstate)
 {
unsigned long shift;
@@ -42,4 +46,12 @@ static inline bool gigantic_page_supported(void)
 /* hugepd entry valid bit */
 #define HUGEPD_VAL_BITS(0x8000UL)
 
+#define huge_ptep_modify_prot_start huge_ptep_modify_prot_start
+extern pte_t huge_ptep_modify_prot_start(struct vm_area_struct *vma,
+unsigned long addr, pte_t *ptep);
+
+#define huge_ptep_modify_prot_commit huge_ptep_modify_prot_commit
+extern void huge_ptep_modify_prot_commit(struct vm_area_struct *vma,
+unsigned long addr, pte_t *ptep,
+pte_t old_pte, pte_t new_pte);
 #endif
diff --git a/arch/powerpc/mm/hugetlbpage-hash64.c 
b/arch/powerpc/mm/hugetlbpage-hash64.c
index 2e6a8f9345d3..48fe74bfeab1 100644
--- a/arch/powerpc/mm/hugetlbpage-hash64.c
+++ b/arch/powerpc/mm/hugetlbpage-hash64.c
@@ -121,3 +121,30 @@ int __hash_page_huge(unsigned long ea, unsigned long 
access, unsigned long vsid,
*ptep = __pte(new_pte & ~H_PAGE_BUSY);
return 0;
 }
+
+pte_t huge_ptep_modify_prot_start(struct vm_area_struct *vma,
+ unsigned long addr, pte_t *ptep)
+{
+   unsigned long pte_val;
+   /*
+* Clear the _PAGE_PRESENT so that no hardware parallel update is
+* possible. Also keep the pte_present true so that we don't take
+* wrong fault.
+*/
+   pte_val = pte_update(vma->vm_mm, addr, ptep,
+_PAGE_PRESENT, _PAGE_INVALID, 1);
+
+   return __pte(pte_val);
+}
+EXPORT_SYMBOL(huge_ptep_modify_prot_start);
+
+void huge_ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long 
addr,
+ pte_t *ptep, pte_t old_pte, pte_t pte)
+{
+
+   if (radix_enabled())
+   return radix__huge_ptep_modify_prot_commit(vma, addr, ptep,
+  old_pte, pte);
+   set_huge_pte_at(vma->vm_mm, addr, ptep, pte);
+}
+EXPORT_SYMBOL(huge_ptep_modify_prot_commit);
diff --git a/arch/powerpc/mm/hugetlbpage-radix.c 
b/arch/powerpc/mm/hugetlbpage-radix.c
index 2486bee0f93e..11d9ea28a816 100644
--- a/arch/powerpc/mm/hugetlbpage-radix.c
+++ b/arch/powerpc/mm/hugetlbpage-radix.c
@@ -90,3 +90,20 @@ radix__hugetlb_get_unmapped_area(struct file *file, unsigned 
long addr,
 
return vm_unmapped_area();
 }
+
+void radix__huge_ptep_modify_prot_commit(struct vm_area_struct *vma,
+unsigned long addr, pte_t *ptep,
+pte_t old_pte, pte_t pte)
+{
+   struct mm_struct *mm = vma->vm_mm;
+
+   /*
+* To avoid NMMU hang while relaxing access we need to flush the tlb 
before
+* we set the new value.
+*/
+   if (is_pte_rw_upgrade(pte_val(old_pte), pte_val(pte)) &&
+   (atomic_read(>context.copros) > 0))
+   radix__flush_hugetlb_page(vma, addr);
+
+   set_huge_pte_at(vma->vm_mm, addr, ptep, pte);
+}
-- 
2.19.2



Re: [PATCH V3 5/5] arch/powerpc/mm/hugetlb: NestMMU workaround for hugetlb mprotect RW upgrade

2018-12-04 Thread Aneesh Kumar K.V
Christophe LEROY  writes:
> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
>> index 8cf035e68378..39d33a3d0dc6 100644
>> --- a/arch/powerpc/mm/hugetlbpage.c
>> +++ b/arch/powerpc/mm/hugetlbpage.c
>> @@ -912,3 +912,32 @@ int gup_hugepte(pte_t *ptep, unsigned long sz, unsigned 
>> long addr,
>>   
>>  return 1;
>>   }
>> +
>> +#ifdef CONFIG_PPC_BOOK3S_64
>
> Could this go in hugetlbpage-hash64.c instead to avoid the #ifdef sequence ?
>

yes. I will send updated patch as reply

-aneesh



Re: [PATCH V3 2/5] mm: update ptep_modify_prot_commit to take old pte value as arg

2018-12-04 Thread Aneesh Kumar K.V

On 12/5/18 9:32 AM, Christophe LEROY wrote:



Le 05/12/2018 à 04:09, Aneesh Kumar K.V a écrit :
Architectures like ppc64 requires to do a conditional tlb flush based 
on the old

and new value of pte. Enable that by passing old pte value as the arg.

Signed-off-by: Aneesh Kumar K.V 
---
  arch/s390/include/asm/pgtable.h | 3 ++-
  arch/s390/mm/pgtable.c  | 2 +-
  arch/x86/include/asm/paravirt.h | 2 +-
  fs/proc/task_mmu.c  | 8 +---
  include/asm-generic/pgtable.h   | 2 +-
  mm/memory.c | 8 
  mm/mprotect.c   | 6 +++---
  7 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/arch/s390/include/asm/pgtable.h 
b/arch/s390/include/asm/pgtable.h

index 5d730199e37b..76dc344edb8c 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -1070,7 +1070,8 @@ static inline pte_t ptep_get_and_clear(struct 
mm_struct *mm,

  #define __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION
  pte_t ptep_modify_prot_start(struct vm_area_struct *, unsigned long, 
pte_t *);
-void ptep_modify_prot_commit(struct vm_area_struct *, unsigned long, 
pte_t *, pte_t);

+void ptep_modify_prot_commit(struct vm_area_struct *, unsigned long,
+ pte_t *, pte_t, pte_t);
  #define __HAVE_ARCH_PTEP_CLEAR_FLUSH
  static inline pte_t ptep_clear_flush(struct vm_area_struct *vma,
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index 29c0a21cd34a..b283b92722cc 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -322,7 +322,7 @@ pte_t ptep_modify_prot_start(struct vm_area_struct 
*vma, unsigned long addr,

  EXPORT_SYMBOL(ptep_modify_prot_start);
  void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned 
long addr,

- pte_t *ptep, pte_t pte)
+ pte_t *ptep, pte_t old_pte, pte_t pte)
  {
  pgste_t pgste;
  struct mm_struct *mm = vma->vm_mm;
diff --git a/arch/x86/include/asm/paravirt.h 
b/arch/x86/include/asm/paravirt.h

index 1154f154025d..0d75a4f60500 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -429,7 +429,7 @@ static inline pte_t ptep_modify_prot_start(struct 
vm_area_struct *vma, unsigned

  }
  static inline void ptep_modify_prot_commit(struct vm_area_struct 
*vma, unsigned long addr,

-   pte_t *ptep, pte_t pte)
+   pte_t *ptep, pte_t old_pte, pte_t pte)
  {
  struct mm_struct *mm = vma->vm_mm;
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 9952d7185170..8d62891d38a8 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -940,10 +940,12 @@ static inline void clear_soft_dirty(struct 
vm_area_struct *vma,

  pte_t ptent = *pte;
  if (pte_present(ptent)) {
-    ptent = ptep_modify_prot_start(vma, addr, pte);
-    ptent = pte_wrprotect(ptent);
+    pte_t old_pte;
+
+    old_pte = ptep_modify_prot_start(vma, addr, pte);
+    ptent = pte_wrprotect(old_pte);


This change doesn't seem to fit with the commit description. Why write 
protecting in addition to clearing dirty ?





The hunk above use a new variable old_pte. There is no functional change 
in that hunk.


-aneesh



Re: [PATCH V3 2/5] mm: update ptep_modify_prot_commit to take old pte value as arg

2018-12-04 Thread Christophe LEROY




Le 05/12/2018 à 04:09, Aneesh Kumar K.V a écrit :

Architectures like ppc64 requires to do a conditional tlb flush based on the old
and new value of pte. Enable that by passing old pte value as the arg.

Signed-off-by: Aneesh Kumar K.V 
---
  arch/s390/include/asm/pgtable.h | 3 ++-
  arch/s390/mm/pgtable.c  | 2 +-
  arch/x86/include/asm/paravirt.h | 2 +-
  fs/proc/task_mmu.c  | 8 +---
  include/asm-generic/pgtable.h   | 2 +-
  mm/memory.c | 8 
  mm/mprotect.c   | 6 +++---
  7 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index 5d730199e37b..76dc344edb8c 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -1070,7 +1070,8 @@ static inline pte_t ptep_get_and_clear(struct mm_struct 
*mm,
  
  #define __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION

  pte_t ptep_modify_prot_start(struct vm_area_struct *, unsigned long, pte_t *);
-void ptep_modify_prot_commit(struct vm_area_struct *, unsigned long, pte_t *, 
pte_t);
+void ptep_modify_prot_commit(struct vm_area_struct *, unsigned long,
+pte_t *, pte_t, pte_t);
  
  #define __HAVE_ARCH_PTEP_CLEAR_FLUSH

  static inline pte_t ptep_clear_flush(struct vm_area_struct *vma,
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index 29c0a21cd34a..b283b92722cc 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -322,7 +322,7 @@ pte_t ptep_modify_prot_start(struct vm_area_struct *vma, 
unsigned long addr,
  EXPORT_SYMBOL(ptep_modify_prot_start);
  
  void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr,

-pte_t *ptep, pte_t pte)
+pte_t *ptep, pte_t old_pte, pte_t pte)
  {
pgste_t pgste;
struct mm_struct *mm = vma->vm_mm;
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 1154f154025d..0d75a4f60500 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -429,7 +429,7 @@ static inline pte_t ptep_modify_prot_start(struct 
vm_area_struct *vma, unsigned
  }
  
  static inline void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr,

-  pte_t *ptep, pte_t pte)
+  pte_t *ptep, pte_t old_pte, pte_t 
pte)
  {
struct mm_struct *mm = vma->vm_mm;
  
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c

index 9952d7185170..8d62891d38a8 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -940,10 +940,12 @@ static inline void clear_soft_dirty(struct vm_area_struct 
*vma,
pte_t ptent = *pte;
  
  	if (pte_present(ptent)) {

-   ptent = ptep_modify_prot_start(vma, addr, pte);
-   ptent = pte_wrprotect(ptent);
+   pte_t old_pte;
+
+   old_pte = ptep_modify_prot_start(vma, addr, pte);
+   ptent = pte_wrprotect(old_pte);


This change doesn't seem to fit with the commit description. Why write 
protecting in addition to clearing dirty ?


Christophe


ptent = pte_clear_soft_dirty(ptent);
-   ptep_modify_prot_commit(vma, addr, pte, ptent);
+   ptep_modify_prot_commit(vma, addr, pte, old_pte, ptent);
} else if (is_swap_pte(ptent)) {
ptent = pte_swp_clear_soft_dirty(ptent);
set_pte_at(vma->vm_mm, addr, pte, ptent);
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index c9897dcc46c4..37039e918f17 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -619,7 +619,7 @@ static inline pte_t ptep_modify_prot_start(struct 
vm_area_struct *vma,
   */
  static inline void ptep_modify_prot_commit(struct vm_area_struct *vma,
   unsigned long addr,
-  pte_t *ptep, pte_t pte)
+  pte_t *ptep, pte_t old_pte, pte_t 
pte)
  {
__ptep_modify_prot_commit(vma->vm_mm, addr, ptep, pte);
  }
diff --git a/mm/memory.c b/mm/memory.c
index d36b0eaa7862..4f3ddaedc764 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3568,7 +3568,7 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
int last_cpupid;
int target_nid;
bool migrated = false;
-   pte_t pte;
+   pte_t pte, old_pte;
bool was_writable = pte_savedwrite(vmf->orig_pte);
int flags = 0;
  
@@ -3588,12 +3588,12 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)

 * Make it present again, Depending on how arch implementes non
 * accessible ptes, some can allow access by kernel mode.
 */
-   pte = ptep_modify_prot_start(vma, vmf->address, vmf->pte);
-   pte = pte_modify(pte, vma->vm_page_prot);
+   old_pte = ptep_modify_prot_start(vma, vmf->address, vmf->pte);
+  

Re: [PATCH V3 5/5] arch/powerpc/mm/hugetlb: NestMMU workaround for hugetlb mprotect RW upgrade

2018-12-04 Thread Christophe LEROY




Le 05/12/2018 à 04:09, Aneesh Kumar K.V a écrit :

NestMMU requires us to mark the pte invalid and flush the tlb when we do a
RW upgrade of pte. We fixed a variant of this in the fault path in commit
Fixes: bd5050e38aec ("powerpc/mm/radix: Change pte relax sequence to handle nest MMU 
hang")

Signed-off-by: Aneesh Kumar K.V 
---
  arch/powerpc/include/asm/book3s/64/hugetlb.h | 12 
  arch/powerpc/mm/hugetlbpage-radix.c  | 17 
  arch/powerpc/mm/hugetlbpage.c| 29 
  3 files changed, 58 insertions(+)

diff --git a/arch/powerpc/include/asm/book3s/64/hugetlb.h 
b/arch/powerpc/include/asm/book3s/64/hugetlb.h
index 5b0177733994..66c1e4f88d65 100644
--- a/arch/powerpc/include/asm/book3s/64/hugetlb.h
+++ b/arch/powerpc/include/asm/book3s/64/hugetlb.h
@@ -13,6 +13,10 @@ radix__hugetlb_get_unmapped_area(struct file *file, unsigned 
long addr,
unsigned long len, unsigned long pgoff,
unsigned long flags);
  
+extern void radix__huge_ptep_modify_prot_commit(struct vm_area_struct *vma,

+   unsigned long addr, pte_t *ptep,
+   pte_t old_pte, pte_t pte);
+
  static inline int hstate_get_psize(struct hstate *hstate)
  {
unsigned long shift;
@@ -42,4 +46,12 @@ static inline bool gigantic_page_supported(void)
  /* hugepd entry valid bit */
  #define HUGEPD_VAL_BITS   (0x8000UL)
  
+#define huge_ptep_modify_prot_start huge_ptep_modify_prot_start

+extern pte_t huge_ptep_modify_prot_start(struct vm_area_struct *vma,
+unsigned long addr, pte_t *ptep);
+
+#define huge_ptep_modify_prot_commit huge_ptep_modify_prot_commit
+extern void huge_ptep_modify_prot_commit(struct vm_area_struct *vma,
+unsigned long addr, pte_t *ptep,
+pte_t old_pte, pte_t new_pte);
  #endif
diff --git a/arch/powerpc/mm/hugetlbpage-radix.c 
b/arch/powerpc/mm/hugetlbpage-radix.c
index 2486bee0f93e..11d9ea28a816 100644
--- a/arch/powerpc/mm/hugetlbpage-radix.c
+++ b/arch/powerpc/mm/hugetlbpage-radix.c
@@ -90,3 +90,20 @@ radix__hugetlb_get_unmapped_area(struct file *file, unsigned 
long addr,
  
  	return vm_unmapped_area();

  }
+
+void radix__huge_ptep_modify_prot_commit(struct vm_area_struct *vma,
+unsigned long addr, pte_t *ptep,
+pte_t old_pte, pte_t pte)
+{
+   struct mm_struct *mm = vma->vm_mm;
+
+   /*
+* To avoid NMMU hang while relaxing access we need to flush the tlb 
before
+* we set the new value.
+*/
+   if (is_pte_rw_upgrade(pte_val(old_pte), pte_val(pte)) &&
+   (atomic_read(>context.copros) > 0))
+   radix__flush_hugetlb_page(vma, addr);
+
+   set_huge_pte_at(vma->vm_mm, addr, ptep, pte);
+}
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 8cf035e68378..39d33a3d0dc6 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -912,3 +912,32 @@ int gup_hugepte(pte_t *ptep, unsigned long sz, unsigned 
long addr,
  
  	return 1;

  }
+
+#ifdef CONFIG_PPC_BOOK3S_64


Could this go in hugetlbpage-hash64.c instead to avoid the #ifdef sequence ?

Christophe


+pte_t huge_ptep_modify_prot_start(struct vm_area_struct *vma,
+ unsigned long addr, pte_t *ptep)
+{
+   unsigned long pte_val;
+   /*
+* Clear the _PAGE_PRESENT so that no hardware parallel update is
+* possible. Also keep the pte_present true so that we don't take
+* wrong fault.
+*/
+   pte_val = pte_update(vma->vm_mm, addr, ptep,
+_PAGE_PRESENT, _PAGE_INVALID, 1);
+
+   return __pte(pte_val);
+}
+EXPORT_SYMBOL(huge_ptep_modify_prot_start);
+
+void huge_ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long 
addr,
+ pte_t *ptep, pte_t old_pte, pte_t pte)
+{
+
+   if (radix_enabled())
+   return radix__huge_ptep_modify_prot_commit(vma, addr, ptep,
+  old_pte, pte);
+   set_huge_pte_at(vma->vm_mm, addr, ptep, pte);
+}
+EXPORT_SYMBOL(huge_ptep_modify_prot_commit);
+#endif



Re: [PATCH v6 2/4] kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()

2018-12-04 Thread Doug Anderson
Hi,

On Mon, Dec 3, 2018 at 7:57 AM Daniel Thompson
 wrote:
>
> On Tue, Nov 27, 2018 at 09:38:37AM -0800, Douglas Anderson wrote:
> > When I had lockdep turned on and dropped into kgdb I got a nice splat
> > on my system.  Specifically it hit:
> >   DEBUG_LOCKS_WARN_ON(current->hardirq_context)
> >
> > Specifically it looked like this:
> >   sysrq: SysRq : DEBUG
> >   [ cut here ]
> >   DEBUG_LOCKS_WARN_ON(current->hardirq_context)
> >   WARNING: CPU: 0 PID: 0 at .../kernel/locking/lockdep.c:2875 
> > lockdep_hardirqs_on+0xf0/0x160
> >   CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.0 #27
> >   pstate: 604003c9 (nZCv DAIF +PAN -UAO)
> >   pc : lockdep_hardirqs_on+0xf0/0x160
> >   ...
> >   Call trace:
> >lockdep_hardirqs_on+0xf0/0x160
> >trace_hardirqs_on+0x188/0x1ac
> >kgdb_roundup_cpus+0x14/0x3c
> >kgdb_cpu_enter+0x53c/0x5cc
> >kgdb_handle_exception+0x180/0x1d4
> >kgdb_compiled_brk_fn+0x30/0x3c
> >brk_handler+0x134/0x178
> >do_debug_exception+0xfc/0x178
> >el1_dbg+0x18/0x78
> >kgdb_breakpoint+0x34/0x58
> >sysrq_handle_dbg+0x54/0x5c
> >__handle_sysrq+0x114/0x21c
> >handle_sysrq+0x30/0x3c
> >qcom_geni_serial_isr+0x2dc/0x30c
> >   ...
> >   ...
> >   irq event stamp: ...45
> >   hardirqs last  enabled at (...44): [...] __do_softirq+0xd8/0x4e4
> >   hardirqs last disabled at (...45): [...] el1_irq+0x74/0x130
> >   softirqs last  enabled at (...42): [...] _local_bh_enable+0x2c/0x34
> >   softirqs last disabled at (...43): [...] irq_exit+0xa8/0x100
> >   ---[ end trace adf21f830c46e638 ]---
> >
> > Looking closely at it, it seems like a really bad idea to be calling
> > local_irq_enable() in kgdb_roundup_cpus().  If nothing else that seems
> > like it could violate spinlock semantics and cause a deadlock.
> >
> > Instead, let's use a private csd alongside
> > smp_call_function_single_async() to round up the other CPUs.  Using
> > smp_call_function_single_async() doesn't require interrupts to be
> > enabled so we can remove the offending bit of code.
> >
> > In order to avoid duplicating this across all the architectures that
> > use the default kgdb_roundup_cpus(), we'll add a "weak" implementation
> > to debug_core.c.
> >
> > Looking at all the people who previously had copies of this code,
> > there were a few variants.  I've attempted to keep the variants
> > working like they used to.  Specifically:
> > * For arch/arc we passed NULL to kgdb_nmicallback() instead of
> >   get_irq_regs().
> > * For arch/mips there was a bit of extra code around
> >   kgdb_nmicallback()
> >
> > NOTE: In this patch we will still get into trouble if we try to round
> > up a CPU that failed to round up before.  We'll try to round it up
> > again and potentially hang when we try to grab the csd lock.  That's
> > not new behavior but we'll still try to do better in a future patch.
> >
> > Suggested-by: Daniel Thompson 
> > Signed-off-by: Douglas Anderson 
> > ---
> >
> > Changes in v6:
> > - Moved smp_call_function_single_async() error check to patch 3.
> >
> > Changes in v5:
> > - Add a comment about get_irq_regs().
> > - get_cpu() => raw_smp_processor_id() in kgdb_roundup_cpus().
> > - for_each_cpu() => for_each_online_cpu()
> > - Error check smp_call_function_single_async()
> >
> > Changes in v4: None
> > Changes in v3:
> > - No separate init call.
> > - Don't round up the CPU that is doing the rounding up.
> > - Add "#ifdef CONFIG_SMP" to match the rest of the file.
> > - Updated desc saying we don't solve the "failed to roundup" case.
> > - Document the ignored parameter.
> >
> > Changes in v2:
> > - Removing irq flags separated from fixing lockdep splat.
> > - Don't use smp_call_function (Daniel).
> >
> >  arch/arc/kernel/kgdb.c | 10 ++
> >  arch/arm/kernel/kgdb.c | 12 ---
> >  arch/arm64/kernel/kgdb.c   | 12 ---
> >  arch/hexagon/kernel/kgdb.c | 27 -
> >  arch/mips/kernel/kgdb.c|  9 +
> >  arch/powerpc/kernel/kgdb.c |  4 ++--
> >  arch/sh/kernel/kgdb.c  | 12 ---
>
> Please could you re-send with the arch maintainers for these platforms
> included in the Cc: of the patch description rather than just in the
> e-mail header.
>
> I'd like to make sure arch maintainers have a chance to opt out if they
> want to (it's a weak symbol so an arch could chose not to use it).
>
> Otherwise I shall start testing shortly!

OK, I did a repost of v6 with the Cc's and also the Acks I've received
so far.  There are no code changes in the repost.  Please let me know
if you have additional comments and thanks for your help.

-Doug


[REPOST PATCH v6 2/4] kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()

2018-12-04 Thread Douglas Anderson
When I had lockdep turned on and dropped into kgdb I got a nice splat
on my system.  Specifically it hit:
  DEBUG_LOCKS_WARN_ON(current->hardirq_context)

Specifically it looked like this:
  sysrq: SysRq : DEBUG
  [ cut here ]
  DEBUG_LOCKS_WARN_ON(current->hardirq_context)
  WARNING: CPU: 0 PID: 0 at .../kernel/locking/lockdep.c:2875 
lockdep_hardirqs_on+0xf0/0x160
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.0 #27
  pstate: 604003c9 (nZCv DAIF +PAN -UAO)
  pc : lockdep_hardirqs_on+0xf0/0x160
  ...
  Call trace:
   lockdep_hardirqs_on+0xf0/0x160
   trace_hardirqs_on+0x188/0x1ac
   kgdb_roundup_cpus+0x14/0x3c
   kgdb_cpu_enter+0x53c/0x5cc
   kgdb_handle_exception+0x180/0x1d4
   kgdb_compiled_brk_fn+0x30/0x3c
   brk_handler+0x134/0x178
   do_debug_exception+0xfc/0x178
   el1_dbg+0x18/0x78
   kgdb_breakpoint+0x34/0x58
   sysrq_handle_dbg+0x54/0x5c
   __handle_sysrq+0x114/0x21c
   handle_sysrq+0x30/0x3c
   qcom_geni_serial_isr+0x2dc/0x30c
  ...
  ...
  irq event stamp: ...45
  hardirqs last  enabled at (...44): [...] __do_softirq+0xd8/0x4e4
  hardirqs last disabled at (...45): [...] el1_irq+0x74/0x130
  softirqs last  enabled at (...42): [...] _local_bh_enable+0x2c/0x34
  softirqs last disabled at (...43): [...] irq_exit+0xa8/0x100
  ---[ end trace adf21f830c46e638 ]---

Looking closely at it, it seems like a really bad idea to be calling
local_irq_enable() in kgdb_roundup_cpus().  If nothing else that seems
like it could violate spinlock semantics and cause a deadlock.

Instead, let's use a private csd alongside
smp_call_function_single_async() to round up the other CPUs.  Using
smp_call_function_single_async() doesn't require interrupts to be
enabled so we can remove the offending bit of code.

In order to avoid duplicating this across all the architectures that
use the default kgdb_roundup_cpus(), we'll add a "weak" implementation
to debug_core.c.

Looking at all the people who previously had copies of this code,
there were a few variants.  I've attempted to keep the variants
working like they used to.  Specifically:
* For arch/arc we passed NULL to kgdb_nmicallback() instead of
  get_irq_regs().
* For arch/mips there was a bit of extra code around
  kgdb_nmicallback()

NOTE: In this patch we will still get into trouble if we try to round
up a CPU that failed to round up before.  We'll try to round it up
again and potentially hang when we try to grab the csd lock.  That's
not new behavior but we'll still try to do better in a future patch.

Suggested-by: Daniel Thompson 
Signed-off-by: Douglas Anderson 
Cc: Vineet Gupta 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Richard Kuo 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: "David S. Miller" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Acked-by: Will Deacon 
---

Changes in v6:
- Moved smp_call_function_single_async() error check to patch 3.

Changes in v5:
- Add a comment about get_irq_regs().
- get_cpu() => raw_smp_processor_id() in kgdb_roundup_cpus().
- for_each_cpu() => for_each_online_cpu()
- Error check smp_call_function_single_async()

Changes in v4: None
Changes in v3:
- No separate init call.
- Don't round up the CPU that is doing the rounding up.
- Add "#ifdef CONFIG_SMP" to match the rest of the file.
- Updated desc saying we don't solve the "failed to roundup" case.
- Document the ignored parameter.

Changes in v2:
- Removing irq flags separated from fixing lockdep splat.
- Don't use smp_call_function (Daniel).

 arch/arc/kernel/kgdb.c | 10 ++
 arch/arm/kernel/kgdb.c | 12 ---
 arch/arm64/kernel/kgdb.c   | 12 ---
 arch/hexagon/kernel/kgdb.c | 27 -
 arch/mips/kernel/kgdb.c|  9 +
 arch/powerpc/kernel/kgdb.c |  4 ++--
 arch/sh/kernel/kgdb.c  | 12 ---
 include/linux/kgdb.h   | 15 --
 kernel/debug/debug_core.c  | 41 ++
 9 files changed, 59 insertions(+), 83 deletions(-)

diff --git a/arch/arc/kernel/kgdb.c b/arch/arc/kernel/kgdb.c
index 0932851028e0..68d9fe4b5aa7 100644
--- a/arch/arc/kernel/kgdb.c
+++ b/arch/arc/kernel/kgdb.c
@@ -192,18 +192,12 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long 
ip)
instruction_pointer(regs) = ip;
 }
 
-static void kgdb_call_nmi_hook(void *ignored)
+void kgdb_call_nmi_hook(void *ignored)
 {
+   /* Default implementation passes get_irq_regs() but we don't */
kgdb_nmicallback(raw_smp_processor_id(), NULL);
 }
 
-void kgdb_roundup_cpus(void)
-{
-   local_irq_enable();
-   smp_call_function(kgdb_call_nmi_hook, NULL, 0);
-   local_irq_disable();
-}
-
 struct kgdb_arch arch_kgdb_ops = {
/* breakpoint instruction: TRAP_S 0x3 */
 #ifdef CONFIG_CPU_BIG_ENDIAN
diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
index f21077b077be..d9a69e941463 

[REPOST PATCH v6 1/4] kgdb: Remove irq flags from roundup

2018-12-04 Thread Douglas Anderson
The function kgdb_roundup_cpus() was passed a parameter that was
documented as:

> the flags that will be used when restoring the interrupts. There is
> local_irq_save() call before kgdb_roundup_cpus().

Nobody used those flags.  Anyone who wanted to temporarily turn on
interrupts just did local_irq_enable() and local_irq_disable() without
looking at them.  So we can definitely remove the flags.

Signed-off-by: Douglas Anderson 
Cc: Vineet Gupta 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Richard Kuo 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: "David S. Miller" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Acked-by: Will Deacon 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Removing irq flags separated from fixing lockdep splat.

 arch/arc/kernel/kgdb.c | 2 +-
 arch/arm/kernel/kgdb.c | 2 +-
 arch/arm64/kernel/kgdb.c   | 2 +-
 arch/hexagon/kernel/kgdb.c | 9 ++---
 arch/mips/kernel/kgdb.c| 2 +-
 arch/powerpc/kernel/kgdb.c | 2 +-
 arch/sh/kernel/kgdb.c  | 2 +-
 arch/sparc/kernel/smp_64.c | 2 +-
 arch/x86/kernel/kgdb.c | 9 ++---
 include/linux/kgdb.h   | 9 ++---
 kernel/debug/debug_core.c  | 2 +-
 11 files changed, 14 insertions(+), 29 deletions(-)

diff --git a/arch/arc/kernel/kgdb.c b/arch/arc/kernel/kgdb.c
index 9a3c34af2ae8..0932851028e0 100644
--- a/arch/arc/kernel/kgdb.c
+++ b/arch/arc/kernel/kgdb.c
@@ -197,7 +197,7 @@ static void kgdb_call_nmi_hook(void *ignored)
kgdb_nmicallback(raw_smp_processor_id(), NULL);
 }
 
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
 {
local_irq_enable();
smp_call_function(kgdb_call_nmi_hook, NULL, 0);
diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
index caa0dbe3dc61..f21077b077be 100644
--- a/arch/arm/kernel/kgdb.c
+++ b/arch/arm/kernel/kgdb.c
@@ -175,7 +175,7 @@ static void kgdb_call_nmi_hook(void *ignored)
kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
 }
 
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
 {
local_irq_enable();
smp_call_function(kgdb_call_nmi_hook, NULL, 0);
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index a20de58061a8..12c339ff6e75 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -289,7 +289,7 @@ static void kgdb_call_nmi_hook(void *ignored)
kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
 }
 
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
 {
local_irq_enable();
smp_call_function(kgdb_call_nmi_hook, NULL, 0);
diff --git a/arch/hexagon/kernel/kgdb.c b/arch/hexagon/kernel/kgdb.c
index 16c24b22d0b2..012e0e230ac2 100644
--- a/arch/hexagon/kernel/kgdb.c
+++ b/arch/hexagon/kernel/kgdb.c
@@ -119,17 +119,12 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long 
pc)
 
 /**
  * kgdb_roundup_cpus - Get other CPUs into a holding pattern
- * @flags: Current IRQ state
  *
  * On SMP systems, we need to get the attention of the other CPUs
  * and get them be in a known state.  This should do what is needed
  * to get the other CPUs to call kgdb_wait(). Note that on some arches,
  * the NMI approach is not used for rounding up all the CPUs. For example,
- * in case of MIPS, smp_call_function() is used to roundup CPUs. In
- * this case, we have to make sure that interrupts are enabled before
- * calling smp_call_function(). The argument to this function is
- * the flags that will be used when restoring the interrupts. There is
- * local_irq_save() call before kgdb_roundup_cpus().
+ * in case of MIPS, smp_call_function() is used to roundup CPUs.
  *
  * On non-SMP systems, this is not called.
  */
@@ -139,7 +134,7 @@ static void hexagon_kgdb_nmi_hook(void *ignored)
kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
 }
 
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
 {
local_irq_enable();
smp_call_function(hexagon_kgdb_nmi_hook, NULL, 0);
diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
index eb6c0d582626..2b05effc17b4 100644
--- a/arch/mips/kernel/kgdb.c
+++ b/arch/mips/kernel/kgdb.c
@@ -219,7 +219,7 @@ static void kgdb_call_nmi_hook(void *ignored)
set_fs(old_fs);
 }
 
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
 {
local_irq_enable();
smp_call_function(kgdb_call_nmi_hook, NULL, 0);
diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
index 59c578f865aa..b0e804844be0 100644
--- a/arch/powerpc/kernel/kgdb.c
+++ b/arch/powerpc/kernel/kgdb.c
@@ -124,7 +124,7 @@ static int kgdb_call_nmi_hook(struct pt_regs *regs)
 }
 
 #ifdef CONFIG_SMP
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
 {

[REPOST PATCH v6 0/4] kgdb: Fix kgdb_roundup_cpus()

2018-12-04 Thread Douglas Anderson
This series was originally part of the series ("serial: Finish kgdb on
qcom_geni; fix many lockdep splats w/ kgdb") but it made sense to
split it up.

It's believed that dropping into kgdb should be more robust once these
patches are applied.

Repost of v6 adds CC's and also tags already received.

Changes in v6:
- Moved smp_call_function_single_async() error check to patch 3.

Changes in v5:
- Add a comment about get_irq_regs().
- get_cpu() => raw_smp_processor_id() in kgdb_roundup_cpus().
- for_each_cpu() => for_each_online_cpu()
- Error check smp_call_function_single_async()

Changes in v4:
- Removed smp_mb() calls.
- Also clear out .debuggerinfo.
- Also clear out .debuggerinfo and .task for the master.
- Remove clearing out in kdb_stub for offline CPUs; it's now redundant.

Changes in v3:
- No separate init call.
- Don't round up the CPU that is doing the rounding up.
- Add "#ifdef CONFIG_SMP" to match the rest of the file.
- Updated desc saying we don't solve the "failed to roundup" case.
- Document the ignored parameter.
- Don't round up a CPU that failed rounding up before new for v3.
- Don't back trace on a cpu that didn't round up new for v3.

Changes in v2:
- Removing irq flags separated from fixing lockdep splat.
- Don't use smp_call_function (Daniel).

Douglas Anderson (4):
  kgdb: Remove irq flags from roundup
  kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()
  kgdb: Don't round up a CPU that failed rounding up before
  kdb: Don't back trace on a cpu that didn't round up

 arch/arc/kernel/kgdb.c  | 10 +
 arch/arm/kernel/kgdb.c  | 12 --
 arch/arm64/kernel/kgdb.c| 12 --
 arch/hexagon/kernel/kgdb.c  | 32 
 arch/mips/kernel/kgdb.c |  9 +
 arch/powerpc/kernel/kgdb.c  |  6 +--
 arch/sh/kernel/kgdb.c   | 12 --
 arch/sparc/kernel/smp_64.c  |  2 +-
 arch/x86/kernel/kgdb.c  |  9 +
 include/linux/kgdb.h| 22 +++
 kernel/debug/debug_core.c   | 65 -
 kernel/debug/debug_core.h   |  1 +
 kernel/debug/kdb/kdb_bt.c   | 11 +-
 kernel/debug/kdb/kdb_debugger.c |  7 
 14 files changed, 98 insertions(+), 112 deletions(-)

-- 
2.20.0.rc1.387.gf8505762e3-goog



Re: [PATCH] powerpc/mm: dump block address translation on book3s/32

2018-12-04 Thread Michael Ellerman
Christophe LEROY  writes:

> Le 16/11/2018 à 11:20, Michael Ellerman a écrit :
>> Christophe LEROY  writes:
>> 
>>> Le 15/11/2018 à 12:46, Michael Ellerman a écrit :
 Christophe Leroy  writes:

> This patch adds a debugfs file to dump block address translation:
>
> ~# cat /sys/kernel/debug/block_address_translation

 My instinct is it should be in /sys/kernel/debug/powerpc. But I guess
 the other page table dump files are not.
>>>
>>> Lol.
>>>
>>> Looks like we have the same instinct ...
>>>
>>> But you rejected my patch https://patchwork.ozlabs.org/patch/750426/ :)
>> 
>> Haha. My argument was that the kernel page table dump is not powerpc
>> specific, but this file *is* powerpc specific. Though I guess it's in
>> the same are as the page table / hash table dump, so it may as well live
>> next to them.
>
> I see you took the first version in next-test. It doesn't handle the 
> case of 64bits phys addresses. v3 does.
>
> I just sent v4 which does to v3 the changes you did (__init and powerpc/ 
> subdir)

Thanks.

cheers


Re: [PATCH] powerpc/ipic: Fix a bounds check in ipic_set_priority()

2018-12-04 Thread Michael Ellerman
Hi Dan,

Thanks for the patch.

Dan Carpenter  writes:
> The ipic_info[] array only has 95 elements so I have made the bounds
> check smaller to prevent a read overflow.  It was Smatch that found
> this issue:
>
> arch/powerpc/sysdev/ipic.c:784 ipic_set_priority()
> error: buffer overflow 'ipic_info' 95 <= 127
>
> Signed-off-by: Dan Carpenter 
> ---
> I wasn't able to find any callers of this code.  Maybe we removed the
> last one in commit b9f0f1bb2bca ("[POWERPC] Adapt ipic driver to new
> host_ops interface, add set_irq_type to set IRQ sense").  So perhaps we
> should just remove it.  I'm not really comfortable doing that myself,
> because I don't know the code well enough and can't build test
> it properly.

Hah wow, last usage removed in 2006!

I don't see any mention of it since then, so I'll remove it. If it
breaks something we can put it back.

Can smatch help us find things like this that are defined non-static but
never used?

cheers


[PATCH V3 5/5] arch/powerpc/mm/hugetlb: NestMMU workaround for hugetlb mprotect RW upgrade

2018-12-04 Thread Aneesh Kumar K.V
NestMMU requires us to mark the pte invalid and flush the tlb when we do a
RW upgrade of pte. We fixed a variant of this in the fault path in commit
Fixes: bd5050e38aec ("powerpc/mm/radix: Change pte relax sequence to handle 
nest MMU hang")

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/book3s/64/hugetlb.h | 12 
 arch/powerpc/mm/hugetlbpage-radix.c  | 17 
 arch/powerpc/mm/hugetlbpage.c| 29 
 3 files changed, 58 insertions(+)

diff --git a/arch/powerpc/include/asm/book3s/64/hugetlb.h 
b/arch/powerpc/include/asm/book3s/64/hugetlb.h
index 5b0177733994..66c1e4f88d65 100644
--- a/arch/powerpc/include/asm/book3s/64/hugetlb.h
+++ b/arch/powerpc/include/asm/book3s/64/hugetlb.h
@@ -13,6 +13,10 @@ radix__hugetlb_get_unmapped_area(struct file *file, unsigned 
long addr,
unsigned long len, unsigned long pgoff,
unsigned long flags);
 
+extern void radix__huge_ptep_modify_prot_commit(struct vm_area_struct *vma,
+   unsigned long addr, pte_t *ptep,
+   pte_t old_pte, pte_t pte);
+
 static inline int hstate_get_psize(struct hstate *hstate)
 {
unsigned long shift;
@@ -42,4 +46,12 @@ static inline bool gigantic_page_supported(void)
 /* hugepd entry valid bit */
 #define HUGEPD_VAL_BITS(0x8000UL)
 
+#define huge_ptep_modify_prot_start huge_ptep_modify_prot_start
+extern pte_t huge_ptep_modify_prot_start(struct vm_area_struct *vma,
+unsigned long addr, pte_t *ptep);
+
+#define huge_ptep_modify_prot_commit huge_ptep_modify_prot_commit
+extern void huge_ptep_modify_prot_commit(struct vm_area_struct *vma,
+unsigned long addr, pte_t *ptep,
+pte_t old_pte, pte_t new_pte);
 #endif
diff --git a/arch/powerpc/mm/hugetlbpage-radix.c 
b/arch/powerpc/mm/hugetlbpage-radix.c
index 2486bee0f93e..11d9ea28a816 100644
--- a/arch/powerpc/mm/hugetlbpage-radix.c
+++ b/arch/powerpc/mm/hugetlbpage-radix.c
@@ -90,3 +90,20 @@ radix__hugetlb_get_unmapped_area(struct file *file, unsigned 
long addr,
 
return vm_unmapped_area();
 }
+
+void radix__huge_ptep_modify_prot_commit(struct vm_area_struct *vma,
+unsigned long addr, pte_t *ptep,
+pte_t old_pte, pte_t pte)
+{
+   struct mm_struct *mm = vma->vm_mm;
+
+   /*
+* To avoid NMMU hang while relaxing access we need to flush the tlb 
before
+* we set the new value.
+*/
+   if (is_pte_rw_upgrade(pte_val(old_pte), pte_val(pte)) &&
+   (atomic_read(>context.copros) > 0))
+   radix__flush_hugetlb_page(vma, addr);
+
+   set_huge_pte_at(vma->vm_mm, addr, ptep, pte);
+}
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 8cf035e68378..39d33a3d0dc6 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -912,3 +912,32 @@ int gup_hugepte(pte_t *ptep, unsigned long sz, unsigned 
long addr,
 
return 1;
 }
+
+#ifdef CONFIG_PPC_BOOK3S_64
+pte_t huge_ptep_modify_prot_start(struct vm_area_struct *vma,
+ unsigned long addr, pte_t *ptep)
+{
+   unsigned long pte_val;
+   /*
+* Clear the _PAGE_PRESENT so that no hardware parallel update is
+* possible. Also keep the pte_present true so that we don't take
+* wrong fault.
+*/
+   pte_val = pte_update(vma->vm_mm, addr, ptep,
+_PAGE_PRESENT, _PAGE_INVALID, 1);
+
+   return __pte(pte_val);
+}
+EXPORT_SYMBOL(huge_ptep_modify_prot_start);
+
+void huge_ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long 
addr,
+ pte_t *ptep, pte_t old_pte, pte_t pte)
+{
+
+   if (radix_enabled())
+   return radix__huge_ptep_modify_prot_commit(vma, addr, ptep,
+  old_pte, pte);
+   set_huge_pte_at(vma->vm_mm, addr, ptep, pte);
+}
+EXPORT_SYMBOL(huge_ptep_modify_prot_commit);
+#endif
-- 
2.19.2



[PATCH V3 4/5] mm/hugetlb: Add prot_modify_start/commit sequence for hugetlb update

2018-12-04 Thread Aneesh Kumar K.V
Architectures like ppc64 requires to do a conditional tlb flush based on the old
and new value of pte. Follow the regular pte change protection sequence for
hugetlb too. This allow the architectures to override the update sequence.

Signed-off-by: Aneesh Kumar K.V 
---
 include/linux/hugetlb.h | 20 
 mm/hugetlb.c|  8 +---
 2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 087fd5f48c91..39e78b80375c 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -543,6 +543,26 @@ static inline void set_huge_swap_pte_at(struct mm_struct 
*mm, unsigned long addr
set_huge_pte_at(mm, addr, ptep, pte);
 }
 #endif
+
+#ifndef huge_ptep_modify_prot_start
+#define huge_ptep_modify_prot_start huge_ptep_modify_prot_start
+static inline pte_t huge_ptep_modify_prot_start(struct vm_area_struct *vma,
+   unsigned long addr, pte_t *ptep)
+{
+   return huge_ptep_get_and_clear(vma->vm_mm, addr, ptep);
+}
+#endif
+
+#ifndef huge_ptep_modify_prot_commit
+#define huge_ptep_modify_prot_commit huge_ptep_modify_prot_commit
+static inline void huge_ptep_modify_prot_commit(struct vm_area_struct *vma,
+   unsigned long addr, pte_t *ptep,
+   pte_t old_pte, pte_t pte)
+{
+   set_huge_pte_at(vma->vm_mm, addr, ptep, pte);
+}
+#endif
+
 #else  /* CONFIG_HUGETLB_PAGE */
 struct hstate {};
 #define alloc_huge_page(v, a, r) NULL
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 705a3e9cc910..353bff385595 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4388,10 +4388,12 @@ unsigned long hugetlb_change_protection(struct 
vm_area_struct *vma,
continue;
}
if (!huge_pte_none(pte)) {
-   pte = huge_ptep_get_and_clear(mm, address, ptep);
-   pte = pte_mkhuge(huge_pte_modify(pte, newprot));
+   pte_t old_pte;
+
+   old_pte = huge_ptep_modify_prot_start(vma, address, 
ptep);
+   pte = pte_mkhuge(huge_pte_modify(old_pte, newprot));
pte = arch_make_huge_pte(pte, vma, NULL, 0);
-   set_huge_pte_at(mm, address, ptep, pte);
+   huge_ptep_modify_prot_commit(vma, address, ptep, 
old_pte, pte);
pages++;
}
spin_unlock(ptl);
-- 
2.19.2



[PATCH V3 3/5] arch/powerpc/mm: Nest MMU workaround for mprotect RW upgrade.

2018-12-04 Thread Aneesh Kumar K.V
NestMMU requires us to mark the pte invalid and flush the tlb when we do a
RW upgrade of pte. We fixed a variant of this in the fault path in commit
Fixes: bd5050e38aec ("powerpc/mm/radix: Change pte relax sequence to handle 
nest MMU hang")

Do the same for mprotect upgrades.

Hugetlb is handled in the next patch.

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/book3s/64/pgtable.h | 18 +
 arch/powerpc/include/asm/book3s/64/radix.h   |  4 +++
 arch/powerpc/mm/pgtable-book3s64.c   | 27 
 arch/powerpc/mm/pgtable-radix.c  | 18 +
 4 files changed, 67 insertions(+)

diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h 
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 2e6ada28da64..92eaea164700 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -1314,6 +1314,24 @@ static inline int pud_pfn(pud_t pud)
BUILD_BUG();
return 0;
 }
+#define __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION
+pte_t ptep_modify_prot_start(struct vm_area_struct *, unsigned long, pte_t *);
+void ptep_modify_prot_commit(struct vm_area_struct *, unsigned long,
+pte_t *, pte_t, pte_t);
+
+/*
+ * Returns true for a R -> RW upgrade of pte
+ */
+static inline bool is_pte_rw_upgrade(unsigned long old_val, unsigned long 
new_val)
+{
+   if (!(old_val & _PAGE_READ))
+   return false;
+
+   if ((!(old_val & _PAGE_WRITE)) && (new_val & _PAGE_WRITE))
+   return true;
+
+   return false;
+}
 
 #endif /* __ASSEMBLY__ */
 #endif /* _ASM_POWERPC_BOOK3S_64_PGTABLE_H_ */
diff --git a/arch/powerpc/include/asm/book3s/64/radix.h 
b/arch/powerpc/include/asm/book3s/64/radix.h
index 7d1a3d1543fc..5ab134eeed20 100644
--- a/arch/powerpc/include/asm/book3s/64/radix.h
+++ b/arch/powerpc/include/asm/book3s/64/radix.h
@@ -127,6 +127,10 @@ extern void radix__ptep_set_access_flags(struct 
vm_area_struct *vma, pte_t *ptep
 pte_t entry, unsigned long address,
 int psize);
 
+extern void radix__ptep_modify_prot_commit(struct vm_area_struct *vma,
+  unsigned long addr, pte_t *ptep,
+  pte_t old_pte, pte_t pte);
+
 static inline unsigned long __radix_pte_update(pte_t *ptep, unsigned long clr,
   unsigned long set)
 {
diff --git a/arch/powerpc/mm/pgtable-book3s64.c 
b/arch/powerpc/mm/pgtable-book3s64.c
index 9f93c9f985c5..3d126353b11e 100644
--- a/arch/powerpc/mm/pgtable-book3s64.c
+++ b/arch/powerpc/mm/pgtable-book3s64.c
@@ -482,3 +482,30 @@ void arch_report_meminfo(struct seq_file *m)
   atomic_long_read(_pages_count[MMU_PAGE_1G]) << 20);
 }
 #endif /* CONFIG_PROC_FS */
+
+pte_t ptep_modify_prot_start(struct vm_area_struct *vma, unsigned long addr,
+pte_t *ptep)
+{
+   unsigned long pte_val;
+
+   /*
+* Clear the _PAGE_PRESENT so that no hardware parallel update is
+* possible. Also keep the pte_present true so that we don't take
+* wrong fault.
+*/
+   pte_val = pte_update(vma->vm_mm, addr, ptep, _PAGE_PRESENT, 
_PAGE_INVALID, 0);
+
+   return __pte(pte_val);
+
+}
+EXPORT_SYMBOL(ptep_modify_prot_start);
+
+void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr,
+pte_t *ptep, pte_t old_pte, pte_t pte)
+{
+   if (radix_enabled())
+   return radix__ptep_modify_prot_commit(vma, addr,
+ ptep, old_pte, pte);
+   set_pte_at(vma->vm_mm, addr, ptep, pte);
+}
+EXPORT_SYMBOL(ptep_modify_prot_commit);
diff --git a/arch/powerpc/mm/pgtable-radix.c b/arch/powerpc/mm/pgtable-radix.c
index 931156069a81..dced3cd241c2 100644
--- a/arch/powerpc/mm/pgtable-radix.c
+++ b/arch/powerpc/mm/pgtable-radix.c
@@ -1063,3 +1063,21 @@ void radix__ptep_set_access_flags(struct vm_area_struct 
*vma, pte_t *ptep,
}
/* See ptesync comment in radix__set_pte_at */
 }
+
+void radix__ptep_modify_prot_commit(struct vm_area_struct *vma,
+   unsigned long addr, pte_t *ptep,
+   pte_t old_pte, pte_t pte)
+{
+   struct mm_struct *mm = vma->vm_mm;
+
+   /*
+* To avoid NMMU hang while relaxing access we need to flush the tlb 
before
+* we set the new value. We need to do this only for radix, because hash
+* translation does flush when updating the linux pte.
+*/
+   if (is_pte_rw_upgrade(pte_val(old_pte), pte_val(pte)) &&
+   (atomic_read(>context.copros) > 0))
+   radix__flush_tlb_page(vma, addr);
+
+   set_pte_at(mm, addr, ptep, pte);
+}
-- 
2.19.2



[PATCH V3 2/5] mm: update ptep_modify_prot_commit to take old pte value as arg

2018-12-04 Thread Aneesh Kumar K.V
Architectures like ppc64 requires to do a conditional tlb flush based on the old
and new value of pte. Enable that by passing old pte value as the arg.

Signed-off-by: Aneesh Kumar K.V 
---
 arch/s390/include/asm/pgtable.h | 3 ++-
 arch/s390/mm/pgtable.c  | 2 +-
 arch/x86/include/asm/paravirt.h | 2 +-
 fs/proc/task_mmu.c  | 8 +---
 include/asm-generic/pgtable.h   | 2 +-
 mm/memory.c | 8 
 mm/mprotect.c   | 6 +++---
 7 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index 5d730199e37b..76dc344edb8c 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -1070,7 +1070,8 @@ static inline pte_t ptep_get_and_clear(struct mm_struct 
*mm,
 
 #define __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION
 pte_t ptep_modify_prot_start(struct vm_area_struct *, unsigned long, pte_t *);
-void ptep_modify_prot_commit(struct vm_area_struct *, unsigned long, pte_t *, 
pte_t);
+void ptep_modify_prot_commit(struct vm_area_struct *, unsigned long,
+pte_t *, pte_t, pte_t);
 
 #define __HAVE_ARCH_PTEP_CLEAR_FLUSH
 static inline pte_t ptep_clear_flush(struct vm_area_struct *vma,
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index 29c0a21cd34a..b283b92722cc 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -322,7 +322,7 @@ pte_t ptep_modify_prot_start(struct vm_area_struct *vma, 
unsigned long addr,
 EXPORT_SYMBOL(ptep_modify_prot_start);
 
 void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr,
-pte_t *ptep, pte_t pte)
+pte_t *ptep, pte_t old_pte, pte_t pte)
 {
pgste_t pgste;
struct mm_struct *mm = vma->vm_mm;
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 1154f154025d..0d75a4f60500 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -429,7 +429,7 @@ static inline pte_t ptep_modify_prot_start(struct 
vm_area_struct *vma, unsigned
 }
 
 static inline void ptep_modify_prot_commit(struct vm_area_struct *vma, 
unsigned long addr,
-  pte_t *ptep, pte_t pte)
+  pte_t *ptep, pte_t old_pte, pte_t 
pte)
 {
struct mm_struct *mm = vma->vm_mm;
 
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 9952d7185170..8d62891d38a8 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -940,10 +940,12 @@ static inline void clear_soft_dirty(struct vm_area_struct 
*vma,
pte_t ptent = *pte;
 
if (pte_present(ptent)) {
-   ptent = ptep_modify_prot_start(vma, addr, pte);
-   ptent = pte_wrprotect(ptent);
+   pte_t old_pte;
+
+   old_pte = ptep_modify_prot_start(vma, addr, pte);
+   ptent = pte_wrprotect(old_pte);
ptent = pte_clear_soft_dirty(ptent);
-   ptep_modify_prot_commit(vma, addr, pte, ptent);
+   ptep_modify_prot_commit(vma, addr, pte, old_pte, ptent);
} else if (is_swap_pte(ptent)) {
ptent = pte_swp_clear_soft_dirty(ptent);
set_pte_at(vma->vm_mm, addr, pte, ptent);
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index c9897dcc46c4..37039e918f17 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -619,7 +619,7 @@ static inline pte_t ptep_modify_prot_start(struct 
vm_area_struct *vma,
  */
 static inline void ptep_modify_prot_commit(struct vm_area_struct *vma,
   unsigned long addr,
-  pte_t *ptep, pte_t pte)
+  pte_t *ptep, pte_t old_pte, pte_t 
pte)
 {
__ptep_modify_prot_commit(vma->vm_mm, addr, ptep, pte);
 }
diff --git a/mm/memory.c b/mm/memory.c
index d36b0eaa7862..4f3ddaedc764 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3568,7 +3568,7 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
int last_cpupid;
int target_nid;
bool migrated = false;
-   pte_t pte;
+   pte_t pte, old_pte;
bool was_writable = pte_savedwrite(vmf->orig_pte);
int flags = 0;
 
@@ -3588,12 +3588,12 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
 * Make it present again, Depending on how arch implementes non
 * accessible ptes, some can allow access by kernel mode.
 */
-   pte = ptep_modify_prot_start(vma, vmf->address, vmf->pte);
-   pte = pte_modify(pte, vma->vm_page_prot);
+   old_pte = ptep_modify_prot_start(vma, vmf->address, vmf->pte);
+   pte = pte_modify(old_pte, vma->vm_page_prot);
pte = pte_mkyoung(pte);
if (was_writable)
pte = pte_mkwrite(pte);
-   ptep_modify_prot_commit(vma, vmf->address, vmf->pte, pte);

[PATCH V3 1/5] mm: Update ptep_modify_prot_start/commit to take vm_area_struct as arg

2018-12-04 Thread Aneesh Kumar K.V
Some architecture may want to call flush_tlb_range from these helpers.

Signed-off-by: Aneesh Kumar K.V 
---
 arch/s390/include/asm/pgtable.h | 4 ++--
 arch/s390/mm/pgtable.c  | 6 --
 arch/x86/include/asm/paravirt.h | 7 +--
 fs/proc/task_mmu.c  | 4 ++--
 include/asm-generic/pgtable.h   | 8 
 mm/memory.c | 4 ++--
 mm/mprotect.c   | 4 ++--
 7 files changed, 21 insertions(+), 16 deletions(-)

diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index 063732414dfb..5d730199e37b 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -1069,8 +1069,8 @@ static inline pte_t ptep_get_and_clear(struct mm_struct 
*mm,
 }
 
 #define __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION
-pte_t ptep_modify_prot_start(struct mm_struct *, unsigned long, pte_t *);
-void ptep_modify_prot_commit(struct mm_struct *, unsigned long, pte_t *, 
pte_t);
+pte_t ptep_modify_prot_start(struct vm_area_struct *, unsigned long, pte_t *);
+void ptep_modify_prot_commit(struct vm_area_struct *, unsigned long, pte_t *, 
pte_t);
 
 #define __HAVE_ARCH_PTEP_CLEAR_FLUSH
 static inline pte_t ptep_clear_flush(struct vm_area_struct *vma,
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index f2cc7da473e4..29c0a21cd34a 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -301,12 +301,13 @@ pte_t ptep_xchg_lazy(struct mm_struct *mm, unsigned long 
addr,
 }
 EXPORT_SYMBOL(ptep_xchg_lazy);
 
-pte_t ptep_modify_prot_start(struct mm_struct *mm, unsigned long addr,
+pte_t ptep_modify_prot_start(struct vm_area_struct *vma, unsigned long addr,
 pte_t *ptep)
 {
pgste_t pgste;
pte_t old;
int nodat;
+   struct mm_struct *mm = vma->vm_mm;
 
preempt_disable();
pgste = ptep_xchg_start(mm, addr, ptep);
@@ -320,10 +321,11 @@ pte_t ptep_modify_prot_start(struct mm_struct *mm, 
unsigned long addr,
 }
 EXPORT_SYMBOL(ptep_modify_prot_start);
 
-void ptep_modify_prot_commit(struct mm_struct *mm, unsigned long addr,
+void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr,
 pte_t *ptep, pte_t pte)
 {
pgste_t pgste;
+   struct mm_struct *mm = vma->vm_mm;
 
if (!MACHINE_HAS_NX)
pte_val(pte) &= ~_PAGE_NOEXEC;
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 4bf42f9e4eea..1154f154025d 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -417,19 +417,22 @@ static inline pgdval_t pgd_val(pgd_t pgd)
 }
 
 #define  __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION
-static inline pte_t ptep_modify_prot_start(struct mm_struct *mm, unsigned long 
addr,
+static inline pte_t ptep_modify_prot_start(struct vm_area_struct *vma, 
unsigned long addr,
   pte_t *ptep)
 {
pteval_t ret;
+   struct mm_struct *mm = vma->vm_mm;
 
ret = PVOP_CALL3(pteval_t, mmu.ptep_modify_prot_start, mm, addr, ptep);
 
return (pte_t) { .pte = ret };
 }
 
-static inline void ptep_modify_prot_commit(struct mm_struct *mm, unsigned long 
addr,
+static inline void ptep_modify_prot_commit(struct vm_area_struct *vma, 
unsigned long addr,
   pte_t *ptep, pte_t pte)
 {
+   struct mm_struct *mm = vma->vm_mm;
+
if (sizeof(pteval_t) > sizeof(long))
/* 5 arg words */
pv_ops.mmu.ptep_modify_prot_commit(mm, addr, ptep, pte);
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 47c3764c469b..9952d7185170 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -940,10 +940,10 @@ static inline void clear_soft_dirty(struct vm_area_struct 
*vma,
pte_t ptent = *pte;
 
if (pte_present(ptent)) {
-   ptent = ptep_modify_prot_start(vma->vm_mm, addr, pte);
+   ptent = ptep_modify_prot_start(vma, addr, pte);
ptent = pte_wrprotect(ptent);
ptent = pte_clear_soft_dirty(ptent);
-   ptep_modify_prot_commit(vma->vm_mm, addr, pte, ptent);
+   ptep_modify_prot_commit(vma, addr, pte, ptent);
} else if (is_swap_pte(ptent)) {
ptent = pte_swp_clear_soft_dirty(ptent);
set_pte_at(vma->vm_mm, addr, pte, ptent);
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 359fb935ded6..c9897dcc46c4 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -606,22 +606,22 @@ static inline void __ptep_modify_prot_commit(struct 
mm_struct *mm,
  * queue the update to be done at some later time.  The update must be
  * actually committed before the pte lock is released, however.
  */
-static inline pte_t ptep_modify_prot_start(struct mm_struct *mm,
+static inline pte_t ptep_modify_prot_start(struct vm_area_struct *vma,
   

[PATCH V3 0/5] NestMMU pte upgrade workaround for mprotect

2018-12-04 Thread Aneesh Kumar K.V


We can upgrade pte access (R -> RW transition) via mprotect. We need
to make sure we follow the recommended pte update sequence as outlined in
commit bd5050e38aec ("powerpc/mm/radix: Change pte relax sequence to handle 
nest MMU hang")
for such updates. This patch series do that.

Changes from V2:
* Update commit message for patch 4
* use radix tlb flush routines directly.

Changes from V1:
* Restrict ths only for R->RW upgrade. We don't need to do this for Autonuma
* Restrict this only for radix translation mode.


Aneesh Kumar K.V (5):
  mm: Update ptep_modify_prot_start/commit to take vm_area_struct as arg
  mm: update ptep_modify_prot_commit to take old pte value as arg
  arch/powerpc/mm: Nest MMU workaround for mprotect RW upgrade.
  mm/hugetlb: Add prot_modify_start/commit sequence for hugetlb update
  arch/powerpc/mm/hugetlb: NestMMU workaround for hugetlb mprotect RW
upgrade

 arch/powerpc/include/asm/book3s/64/hugetlb.h | 12 
 arch/powerpc/include/asm/book3s/64/pgtable.h | 18 
 arch/powerpc/include/asm/book3s/64/radix.h   |  4 +++
 arch/powerpc/mm/hugetlbpage-radix.c  | 17 
 arch/powerpc/mm/hugetlbpage.c| 29 
 arch/powerpc/mm/pgtable-book3s64.c   | 27 ++
 arch/powerpc/mm/pgtable-radix.c  | 18 
 arch/s390/include/asm/pgtable.h  |  5 ++--
 arch/s390/mm/pgtable.c   |  8 --
 arch/x86/include/asm/paravirt.h  |  9 --
 fs/proc/task_mmu.c   |  8 --
 include/asm-generic/pgtable.h| 10 +++
 include/linux/hugetlb.h  | 20 ++
 mm/hugetlb.c |  8 --
 mm/memory.c  |  8 +++---
 mm/mprotect.c|  6 ++--
 16 files changed, 181 insertions(+), 26 deletions(-)

-- 
2.19.2



Re: [PATCH v2 13/34] dt-bindings: arm: amlogic: Move 'amlogic, meson-gx-ao-secure' binding to its own file

2018-12-04 Thread Kevin Hilman
Rob Herring  writes:

> It is best practice to have 1 binding per file, so board level bindings
> should be separate for various misc SoC bindings.
>
> Cc: Mark Rutland 
> Cc: Carlo Caione 
> Cc: Kevin Hilman 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-amlo...@lists.infradead.org
> Signed-off-by: Rob Herring 
> ---
>  .../devicetree/bindings/arm/amlogic.txt   | 29 ---
>  .../amlogic/amlogic,meson-gx-ao-secure.txt| 28 ++
>  2 files changed, 28 insertions(+), 29 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt

Acked-by: Kevin Hilman 

But this isn't really related to the schema series is it?  If you
prefer, I can just queue this one separately via my tree.

Kevin


Re: [PATCH v8 00/14] Appended signatures support for IMA appraisal

2018-12-04 Thread Thiago Jung Bauermann


Hello James,

Thanks for you interest in these patches.

James Morris  writes:

> On Fri, 16 Nov 2018, Thiago Jung Bauermann wrote:
>
>> On the OpenPOWER platform, secure boot and trusted boot are being
>> implemented using IMA for taking measurements and verifying signatures.
>> Since the kernel image on Power servers is an ELF binary, kernels are
>> signed using the scripts/sign-file tool and thus use the same signature
>> format as signed kernel modules.
>>
>> This patch series adds support in IMA for verifying those signatures.
>
> Are you saying you use IMA to verify kernels during boot?  From a Linux
> bootloader?

Yes to both. OpenPOWER machines have embedded in their firmware a Linux
kernel and initramfs to use as bootloader, using Petitboot. kexec is
used to load the OS and boot it.

>> It adds flexibility to OpenPOWER secure boot, because it allows it to boot
>> kernels with the signature appended to them as well as kernels where the
>> signature is stored in the IMA extended attribute.
>
> Just to clarify, with these patches, IMA will be able to verify the
> native form of signed kernel modules?

That wasn't my use case to develop the patches, but I just tested and it
works.

I just had to make a slight modification: there's a whitelist of IMA
hooks that are allowed to use the module signature format (in the
ima_hook_supports_modsig function), and I had to add MODULE_CHECK to it.
The next version of the patches will have this change.

The only difference is that IMA looks for a valid key in the IMA
keyring, while the CONFIG_MODULE_SIG code looks for the module signing
key in the builtin and secondary trusted keyrings.

> i.e. without xattrs at all, and
> this will work with existing signed modules?

No xattrs at all, and yes.

--
Thiago Jung Bauermann
IBM Linux Technology Center



[tip:core/rcu] powerpc: Convert hugepd_free() to use call_rcu()

2018-12-04 Thread tip-bot for Paul E. McKenney
Commit-ID:  04229110adfba984950fc0209632640a76eb1de4
Gitweb: https://git.kernel.org/tip/04229110adfba984950fc0209632640a76eb1de4
Author: Paul E. McKenney 
AuthorDate: Mon, 5 Nov 2018 16:53:13 -0800
Committer:  Paul E. McKenney 
CommitDate: Thu, 8 Nov 2018 21:43:20 -0800

powerpc: Convert hugepd_free() to use call_rcu()

Now that call_rcu()'s callback is not invoked until after all
preempt-disable regions of code have completed (in addition to explicitly
marked RCU read-side critical sections), call_rcu() can be used in place
of call_rcu_sched().  This commit therefore makes that change.

Signed-off-by: Paul E. McKenney 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: 
---
 arch/powerpc/mm/hugetlbpage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 8cf035e68378..4c01e9a01a74 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -289,7 +289,7 @@ static void hugepd_free(struct mmu_gather *tlb, void 
*hugepte)
 
(*batchp)->ptes[(*batchp)->index++] = hugepte;
if ((*batchp)->index == HUGEPD_FREELIST_SIZE) {
-   call_rcu_sched(&(*batchp)->rcu, hugepd_free_rcu_callback);
+   call_rcu(&(*batchp)->rcu, hugepd_free_rcu_callback);
*batchp = NULL;
}
put_cpu_var(hugepd_freelist_cur);


Re: [PATCH v2 15/34] dt-bindings: arm: Convert Atmel board/soc bindings to json-schema

2018-12-04 Thread Rob Herring
On Tue, Dec 4, 2018 at 2:12 AM  wrote:
>
> On 03/12/2018 at 22:32, Rob Herring wrote:
> > Convert Atmel SoC bindings to DT schema format using json-schema.
> >
> > Cc: Mark Rutland 
> > Cc: Nicolas Ferre 
>
> I'm listed here...
>
> > Cc: Alexandre Belloni 
>
> Proper email address here...
>
>
> > Cc: devicet...@vger.kernel.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Signed-off-by: Rob Herring 
> > ---
> >   .../devicetree/bindings/arm/atmel-at91.txt|  72 --
> >   .../devicetree/bindings/arm/atmel-at91.yaml   | 133 ++
> >   2 files changed, 133 insertions(+), 72 deletions(-)
> >   delete mode 100644 Documentation/devicetree/bindings/arm/atmel-at91.txt
> >   create mode 100644 Documentation/devicetree/bindings/arm/atmel-at91.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt 
> > b/Documentation/devicetree/bindings/arm/atmel-at91.txt
> > deleted file mode 100644
> > index 4bf1b4da7659..
> > --- a/Documentation/devicetree/bindings/arm/atmel-at91.txt
> > +++ /dev/null
> > @@ -1,72 +0,0 @@
> > -Atmel AT91 device tree bindings.
> > -
>
> [..]
>
> > diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml 
> > b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
> > new file mode 100644
> > index ..19431f58b906
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
> > @@ -0,0 +1,133 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/arm/atmel-at91.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Atmel AT91 device tree bindings.
> > +
> > +maintainers:
> > +  - Alexandre Belloni 
> > +  - Ludovic Desroches 
>
> ... and sorry but it's not correct just above ^^^
> - wrong Ludovic's email address
> - wrong Alexander's email address
> - and I'm not part of the game anymore...

Humm, I think get_maintainers.pl says you are as that's where the Cc
list came from. But it could be stale if that changed recently.

>
> So actually our MAINTAINER's entry is up-to-date: please use it.

Sorry, it was generated from git history. Many of cases with
get_maintainers.pl was not correct and ended with me being listed.
Probably should have made the git history a fallback.

Rob


Re: [PATCH v8 00/14] Appended signatures support for IMA appraisal

2018-12-04 Thread James Morris
On Fri, 16 Nov 2018, Thiago Jung Bauermann wrote:

> On the OpenPOWER platform, secure boot and trusted boot are being
> implemented using IMA for taking measurements and verifying signatures.
> Since the kernel image on Power servers is an ELF binary, kernels are
> signed using the scripts/sign-file tool and thus use the same signature
> format as signed kernel modules.
> 
> This patch series adds support in IMA for verifying those signatures.

Are you saying you use IMA to verify kernels during boot?  From a Linux 
bootloader?

> It adds flexibility to OpenPOWER secure boot, because it allows it to boot
> kernels with the signature appended to them as well as kernels where the
> signature is stored in the IMA extended attribute.

Just to clarify, with these patches, IMA will be able to verify the 
native form of signed kernel modules?  i.e. without xattrs at all, and 
this will work with existing signed modules?



-- 
James Morris




Re: [PATCH V2] mm: Replace all open encodings for NUMA_NO_NODE

2018-12-04 Thread Lubomir Rintel
On Mon, 2018-11-26 at 17:56 +0530, Anshuman Khandual wrote:
> At present there are multiple places where invalid node number is encoded
> as -1. Even though implicitly understood it is always better to have macros
> in there. Replace these open encodings for an invalid node number with the
> global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like
> 'invalid node' from various places redirecting them to a common definition.
> 
> Signed-off-by: Anshuman Khandual 
> ---
> Changes in V2:
> 
> - Added inclusion of 'numa.h' header at various places per Andrew
> - Updated 'dev_to_node' to use NUMA_NO_NODE instead per Vinod
> 
> Changes in V1: (https://lkml.org/lkml/2018/11/23/485)
> 
> - Dropped OCFS2 changes per Joseph
> - Dropped media/video drivers changes per Hans
> 
> RFC - https://patchwork.kernel.org/patch/10678035/
> 
> Build tested this with multiple cross compiler options like alpha, sparc,
> arm64, x86, powerpc, powerpc64le etc with their default config which might
> not have compiled tested all driver related changes. I will appreciate
> folks giving this a test in their respective build environment.
> 
> All these places for replacement were found by running the following grep
> patterns on the entire kernel code. Please let me know if this might have
> missed some instances. This might also have replaced some false positives.
> I will appreciate suggestions, inputs and review.
> 
> 1. git grep "nid == -1"
> 2. git grep "node == -1"
> 3. git grep "nid = -1"
> 4. git grep "node = -1"
> 
>  arch/alpha/include/asm/topology.h |  3 ++-
>  arch/ia64/kernel/numa.c   |  2 +-
>  arch/ia64/mm/discontig.c  |  6 +++---
>  arch/ia64/sn/kernel/io_common.c   |  3 ++-
>  arch/powerpc/include/asm/pci-bridge.h |  3 ++-
>  arch/powerpc/kernel/paca.c|  3 ++-
>  arch/powerpc/kernel/pci-common.c  |  3 ++-
>  arch/powerpc/mm/numa.c| 14 +++---
>  arch/powerpc/platforms/powernv/memtrace.c |  5 +++--
>  arch/sparc/kernel/auxio_32.c  |  3 ++-
>  arch/sparc/kernel/pci_fire.c  |  3 ++-
>  arch/sparc/kernel/pci_schizo.c|  3 ++-
>  arch/sparc/kernel/pcic.c  |  7 ---
>  arch/sparc/kernel/psycho_common.c |  3 ++-
>  arch/sparc/kernel/sbus.c  |  3 ++-
>  arch/sparc/mm/init_64.c   |  6 +++---
>  arch/sparc/prom/init_32.c |  3 ++-
>  arch/sparc/prom/init_64.c |  5 +++--
>  arch/sparc/prom/tree_32.c | 13 +++--
>  arch/sparc/prom/tree_64.c | 19 ++-
>  arch/x86/include/asm/pci.h|  3 ++-
>  arch/x86/kernel/apic/x2apic_uv_x.c|  7 ---
>  arch/x86/kernel/smpboot.c |  3 ++-
>  arch/x86/platform/olpc/olpc_dt.c  | 17 +
>  drivers/block/mtip32xx/mtip32xx.c |  5 +++--
>  drivers/dma/dmaengine.c   |  4 +++-
>  drivers/infiniband/hw/hfi1/affinity.c |  3 ++-
>  drivers/infiniband/hw/hfi1/init.c |  3 ++-
>  drivers/iommu/dmar.c  |  5 +++--
>  drivers/iommu/intel-iommu.c   |  3 ++-
>  drivers/misc/sgi-xp/xpc_uv.c  |  3 ++-
>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |  5 +++--
>  include/linux/device.h|  2 +-
>  init/init_task.c  |  3 ++-
>  kernel/kthread.c  |  3 ++-
>  kernel/sched/fair.c   | 15 ---
>  lib/cpumask.c |  3 ++-
>  mm/huge_memory.c  | 13 +++--
>  mm/hugetlb.c  |  3 ++-
>  mm/ksm.c  |  2 +-
>  mm/memory.c   |  7 ---
>  mm/memory_hotplug.c   | 12 ++--
>  mm/mempolicy.c|  2 +-
>  mm/page_alloc.c   |  4 ++--
>  mm/page_ext.c |  2 +-
>  net/core/pktgen.c |  3 ++-
>  net/qrtr/qrtr.c   |  3 ++-
>  tools/perf/bench/numa.c   |  6 +++---
>  48 files changed, 146 insertions(+), 108 deletions(-)

Thanks for the patch. It seems to me that you've got a fairly large
amount of it wrong though -- perhaps relying just on "git grep" alone
is not the best idea.

The diffstat is not all that big, it is entirely plausible to just
review each hunk manually: just do a "git show -U20" to get some
context.

You get a NAK from me for the OLPC DT part, but I think at least the
sparc/prom part also deals with device tree nodes and not NUMA nodes.

More inline.

Lubo

> 
> diff --git 

Re: [PATCH v3 4/4] powerpc: generate uapi header and system call table files

2018-12-04 Thread Arnd Bergmann
On Tue, Dec 4, 2018 at 10:17 PM Arnd Bergmann  wrote:
>
> > diff --git a/arch/powerpc/kernel/systbl.S b/arch/powerpc/kernel/systbl.S
> > index 9ff1913..d756348 100644
> > --- a/arch/powerpc/kernel/systbl.S
> > +++ b/arch/powerpc/kernel/systbl.S
>
> >  #ifdef CONFIG_PPC64
> > @@ -47,5 +25,17 @@
> >  .globl sys_call_table
> >  sys_call_table:
> >
> > +#if defined CONFIG_PPC64 && defined(CONFIG_COMPAT)
> > +#define __SYSCALL(nr, entry, nargs) .8byte entry
> >  #define compat_sys_sigsuspend  sys_sigsuspend
> > -#include 
> > +#include 
> > +#undef __SYSCALL
> > +#elif defined CONFIG_PPC64 && !defined(CONFIG_COMPAT)
> > +#define __SYSCALL(nr, entry, nargs) .8byte entry
> > +#include 
> > +#undef __SYSCALL
>
> This part looks wrong: where the old sys_call_table contained
> both the native and compat calls side by side, the new table
> contains only the compat versions (note that CONFIG_COMPAT is
> always set on PPC64). I think you copy-pasted this incorrectly from
> one of the other architectures that uses a different layout for the
> compat calls.
>
> The way I think this could work best is if you add a preparation
> patch that splits out the 64-bit table into two separate ones
> (and make sure that works). After that, you can add your
> existing patch, rebased to use the two generated tables
> instead of the old-style tables. I'll follow up with an untested
> patch for illustration.

One more thing I noticed while writing up that patch: you also need
to use the DOTSYM() macro in __SYSCALL() to generate the correct
symbol name for the old ELF ABI (when PPC64_ELF_ABI_v2 is
not set).

   Arnd


[PATCH] powerpc: split compat syscall table out from native table

2018-12-04 Thread Arnd Bergmann
PowerPC uses a syscall table with native and compat calls interleaved,
which is a slightly simpler way to define two matching tables.

As we move to having the tables generated, that advantage is no longer
important, but the interleaved table gets in the way of using the
same scripts as on the other architectures.

Split out a new compat_sys_call_table symbol that contains all the
compat calls, and leave the main table for the native calls, to more
closely match the method we use everywhere else.

Signed-off-by: Arnd Bergmann 
---
This is completely untested, it's just for illustration and to
get comments about whether this is a good idea.

Firoz, can you try to get this working?
---
 arch/powerpc/include/asm/syscall.h |  3 +--
 arch/powerpc/kernel/entry_64.S |  7 --
 arch/powerpc/kernel/systbl.S   | 37 --
 arch/powerpc/kernel/vdso.c |  7 --
 4 files changed, 41 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/include/asm/syscall.h 
b/arch/powerpc/include/asm/syscall.h
index ab9f3f0a8637..1a0e7a8b1c81 100644
--- a/arch/powerpc/include/asm/syscall.h
+++ b/arch/powerpc/include/asm/syscall.h
@@ -18,9 +18,8 @@
 #include 
 
 /* ftrace syscalls requires exporting the sys_call_table */
-#ifdef CONFIG_FTRACE_SYSCALLS
 extern const unsigned long sys_call_table[];
-#endif /* CONFIG_FTRACE_SYSCALLS */
+extern const unsigned long compat_sys_call_table[];
 
 static inline int syscall_get_nr(struct task_struct *task, struct pt_regs 
*regs)
 {
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 7b1693adff2a..5574d92646f1 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -54,6 +54,9 @@
 SYS_CALL_TABLE:
.tc sys_call_table[TC],sys_call_table
 
+COMPAT_SYS_CALL_TABLE:
+   .tc compat_sys_call_table[TC],compat_sys_call_table
+
 /* This value is used to mark exception frames on the stack. */
 exception_marker:
.tc ID_EXC_MARKER[TC],STACK_FRAME_REGS_MARKER
@@ -173,7 +176,7 @@ system_call:/* label this so stack 
traces look sane */
ld  r11,SYS_CALL_TABLE@toc(2)
andis.  r10,r10,_TIF_32BIT@h
beq 15f
-   addir11,r11,8   /* use 32-bit syscall entries */
+   ld  r11,COMPAT_SYS_CALL_TABLE@toc(2)
clrldi  r3,r3,32
clrldi  r4,r4,32
clrldi  r5,r5,32
@@ -181,7 +184,7 @@ system_call:/* label this so stack 
traces look sane */
clrldi  r7,r7,32
clrldi  r8,r8,32
 15:
-   slwir0,r0,4
+   slwir0,r0,3
 
barrier_nospec_asm
/*
diff --git a/arch/powerpc/kernel/systbl.S b/arch/powerpc/kernel/systbl.S
index 919a32746ede..883b8e36964c 100644
--- a/arch/powerpc/kernel/systbl.S
+++ b/arch/powerpc/kernel/systbl.S
@@ -17,13 +17,13 @@
 #include 
 
 #ifdef CONFIG_PPC64
-#define SYSCALL(func)  .8byte  DOTSYM(sys_##func),DOTSYM(sys_##func)
-#define COMPAT_SYS(func)   .8byte  
DOTSYM(sys_##func),DOTSYM(compat_sys_##func)
-#define PPC_SYS(func)  .8byte  DOTSYM(ppc_##func),DOTSYM(ppc_##func)
-#define OLDSYS(func)   .8byte  
DOTSYM(sys_ni_syscall),DOTSYM(sys_ni_syscall)
-#define SYS32ONLY(func).8byte  
DOTSYM(sys_ni_syscall),DOTSYM(compat_sys_##func)
-#define PPC64ONLY(func).8byte  
DOTSYM(ppc_##func),DOTSYM(sys_ni_syscall)
-#define SYSX(f, f3264, f32).8byte  DOTSYM(f),DOTSYM(f3264)
+#define SYSCALL(func)  .8byte  DOTSYM(sys_##func)
+#define COMPAT_SYS(func)   .8byte  DOTSYM(sys_##func)
+#define PPC_SYS(func)  .8byte  DOTSYM(ppc_##func)
+#define OLDSYS(func)   .8byte  DOTSYM(sys_ni_syscall)
+#define SYS32ONLY(func).8byte  DOTSYM(sys_ni_syscall)
+#define PPC64ONLY(func).8byte  DOTSYM(ppc_##func)
+#define SYSX(f, f3264, f32).8byte  DOTSYM(f)
 #else
 #define SYSCALL(func)  .long   sys_##func
 #define COMPAT_SYS(func)   .long   sys_##func
@@ -48,3 +48,26 @@
 sys_call_table:
 
 #include 
+
+#undef SYSCALL
+#undef COMPAT_SYS
+#undef PPC_SYS
+#undef OLDSYS
+#undef SYS32ONLY
+#undef PPC64ONLY
+#undef SYSX
+
+#ifdef CONFIG_COMPAT
+#define SYSCALL(func)  .8byte  DOTSYM(sys_##func)
+#define COMPAT_SYS(func)   .8byte  DOTSYM(compat_sys_##func)
+#define PPC_SYS(func)  .8byte  DOTSYM(ppc_##func)
+#define OLDSYS(func)   .8byte  DOTSYM(sys_ni_syscall)
+#define SYS32ONLY(func).8byte  DOTSYM(compat_sys_##func)
+#define PPC64ONLY(func).8byte  DOTSYM(sys_ni_syscall)
+#define SYSX(f, f3264, f32).8byte  DOTSYM(f3264)
+
+.globl compat_sys_call_table
+compat_sys_call_table:
+
+#include 
+#endif
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 65b3bdb99f0b..7725a9714736 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -671,15 +671,18 @@ static void __init vdso_setup_syscall_map(void)
 {
unsigned int i;

Re: [PATCH] powerpc/32: Move the old 6xx -mcpu logic before the TARGET_CPU logic

2018-12-04 Thread Christophe LEROY




Le 04/12/2018 à 21:53, Mathieu Malaterre a écrit :

The code:

   ifdef CONFIG_6xx
   KBUILD_CFLAGS  += -mcpu=powerpc
   endif

was added in 2006 in commit f48b8296b315 ("[PATCH] powerpc32: Set cpu
explicitly in kernel compiles"). This change was acceptable since the
TARGET_CPU logic was 64-bit only.

Since commit 0e00a8c9fd92 ("powerpc: Allow CPU selection
also on PPC32") this logic is no longer acceptable after the TARGET_CPU
specific. It currently appends -mcpu=powerpc at the end of the command
line, after any TARGET_CPU specific:

   gcc -Wp,-MD,init/.do_mounts.o.d ...
 -mcpu=powerpc -mbig-endian -m32 ...
 -mcpu=e300c2 ...
 -mcpu=powerpc ...
 ../init/do_mounts.c

Cc: Christophe Leroy 
Fixes: 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32")
Suggested-by: Michael Ellerman 
Link: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg142315.html
Signed-off-by: Mathieu Malaterre 
---
  arch/powerpc/Makefile | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 8a2ce14d68d0..544b30667ea5 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -30,6 +30,10 @@ endif
  endif
  endif
  
+ifdef CONFIG_6xx

+KBUILD_CFLAGS  += -mcpu=powerpc
+endif
+


Could you make the patch on top of my serie (ie after the change of 
CONFIG_6xx to CONFIG_BOOK3S_32 ?


The serie is in origin/next-test

Thanks,
Christophe


  ifeq ($(CROSS_COMPILE),)
  KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
  else
@@ -241,10 +245,6 @@ KBUILD_CFLAGS  += $(call cc-option,-fno-dwarf2-cfi-asm)
  # often slow when they are implemented at all
  KBUILD_CFLAGS += $(call cc-option,-mno-string)
  
-ifdef CONFIG_6xx

-KBUILD_CFLAGS  += -mcpu=powerpc
-endif
-
  cpu-as-$(CONFIG_4xx)  += -Wa,-m405
  cpu-as-$(CONFIG_ALTIVEC)  += $(call as-option,-Wa$(comma)-maltivec)
  cpu-as-$(CONFIG_E200) += -Wa,-me200



Re: [PATCH v3 4/4] powerpc: generate uapi header and system call table files

2018-12-04 Thread Arnd Bergmann
> diff --git a/arch/powerpc/kernel/systbl.S b/arch/powerpc/kernel/systbl.S
> index 9ff1913..d756348 100644
> --- a/arch/powerpc/kernel/systbl.S
> +++ b/arch/powerpc/kernel/systbl.S

>  #ifdef CONFIG_PPC64
> @@ -47,5 +25,17 @@
>  .globl sys_call_table
>  sys_call_table:
>
> +#if defined CONFIG_PPC64 && defined(CONFIG_COMPAT)
> +#define __SYSCALL(nr, entry, nargs) .8byte entry
>  #define compat_sys_sigsuspend  sys_sigsuspend
> -#include 
> +#include 
> +#undef __SYSCALL
> +#elif defined CONFIG_PPC64 && !defined(CONFIG_COMPAT)
> +#define __SYSCALL(nr, entry, nargs) .8byte entry
> +#include 
> +#undef __SYSCALL

This part looks wrong: where the old sys_call_table contained
both the native and compat calls side by side, the new table
contains only the compat versions (note that CONFIG_COMPAT is
always set on PPC64). I think you copy-pasted this incorrectly from
one of the other architectures that uses a different layout for the
compat calls.

The way I think this could work best is if you add a preparation
patch that splits out the 64-bit table into two separate ones
(and make sure that works). After that, you can add your
existing patch, rebased to use the two generated tables
instead of the old-style tables. I'll follow up with an untested
patch for illustration.

   Arnd


[PATCH] powerpc/32: Move the old 6xx -mcpu logic before the TARGET_CPU logic

2018-12-04 Thread Mathieu Malaterre
The code:

  ifdef CONFIG_6xx
  KBUILD_CFLAGS  += -mcpu=powerpc
  endif

was added in 2006 in commit f48b8296b315 ("[PATCH] powerpc32: Set cpu
explicitly in kernel compiles"). This change was acceptable since the
TARGET_CPU logic was 64-bit only.

Since commit 0e00a8c9fd92 ("powerpc: Allow CPU selection
also on PPC32") this logic is no longer acceptable after the TARGET_CPU
specific. It currently appends -mcpu=powerpc at the end of the command
line, after any TARGET_CPU specific:

  gcc -Wp,-MD,init/.do_mounts.o.d ...
-mcpu=powerpc -mbig-endian -m32 ...
-mcpu=e300c2 ...
-mcpu=powerpc ...
../init/do_mounts.c

Cc: Christophe Leroy 
Fixes: 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32")
Suggested-by: Michael Ellerman 
Link: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg142315.html
Signed-off-by: Mathieu Malaterre 
---
 arch/powerpc/Makefile | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 8a2ce14d68d0..544b30667ea5 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -30,6 +30,10 @@ endif
 endif
 endif
 
+ifdef CONFIG_6xx
+KBUILD_CFLAGS  += -mcpu=powerpc
+endif
+
 ifeq ($(CROSS_COMPILE),)
 KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
 else
@@ -241,10 +245,6 @@ KBUILD_CFLAGS  += $(call cc-option,-fno-dwarf2-cfi-asm)
 # often slow when they are implemented at all
 KBUILD_CFLAGS  += $(call cc-option,-mno-string)
 
-ifdef CONFIG_6xx
-KBUILD_CFLAGS  += -mcpu=powerpc
-endif
-
 cpu-as-$(CONFIG_4xx)   += -Wa,-m405
 cpu-as-$(CONFIG_ALTIVEC)   += $(call as-option,-Wa$(comma)-maltivec)
 cpu-as-$(CONFIG_E200)  += -Wa,-me200
-- 
2.19.2



Re: [PATCH v2 26/34] dt-bindings: arm: Convert Renesas board/soc bindings to json-schema

2018-12-04 Thread Simon Horman
On Mon, Dec 03, 2018 at 03:32:15PM -0600, Rob Herring wrote:
> Convert Renesas SoC bindings to DT schema format using json-schema.
> 
> Cc: Simon Horman 
> Cc: Magnus Damm 
> Cc: Mark Rutland 
> Cc: linux-renesas-...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  .../devicetree/bindings/arm/shmobile.txt  | 151 
>  .../devicetree/bindings/arm/shmobile.yaml | 218 ++
>  2 files changed, 218 insertions(+), 151 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml

Hi Rob,

what is this based on? I get a conflict when applying the .txt change
and if I knew the base for this patch it would be rather easy to work
out what has changed.

Also, should we do an s/shmobile.txt/shmobile.yaml/ in MAINTAINERS?


Re: [PATCH v2 25/34] dt-bindings: arm: renesas: Move 'renesas,prr' binding to its own doc

2018-12-04 Thread Simon Horman
On Mon, Dec 03, 2018 at 03:32:14PM -0600, Rob Herring wrote:
> In preparation to convert board-level bindings to json-schema, move
> various misc SoC bindings out to their own file.
> 
> Cc: Mark Rutland 
> Cc: Simon Horman 
> Cc: Magnus Damm 
> Cc: devicet...@vger.kernel.org
> Cc: linux-renesas-...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  .../devicetree/bindings/arm/renesas,prr.txt   | 20 +++
>  .../devicetree/bindings/arm/shmobile.txt  | 18 -
>  2 files changed, 20 insertions(+), 18 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/renesas,prr.txt

Applied for v4.21, but should we add renesas,prr.txt to MAINTAINERS
as a follow-up?


[PATCH] powerpc: remove remaining bits from CONFIG_APUS

2018-12-04 Thread Christophe Leroy
commit f21f49ea639a ("[POWERPC] Remove the dregs of APUS support from
arch/powerpc") removed CONFIG_APUS, but forgot to remove the logic
which adapts tophys() and tovirt() for it.

This patch removes the last stale pieces.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/ppc_asm.h | 19 ++-
 arch/powerpc/kernel/vmlinux.lds.S  |  6 --
 2 files changed, 2 insertions(+), 23 deletions(-)

diff --git a/arch/powerpc/include/asm/ppc_asm.h 
b/arch/powerpc/include/asm/ppc_asm.h
index b5d023680801..378432995eb7 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -480,26 +480,11 @@ END_FTR_SECTION_IFCLR(CPU_FTR_601)
ori rd,rd,((KERNELBASE>>48)&0x);\
rotldi  rd,rd,48
 #else
-/*
- * On APUS (Amiga PowerPC cpu upgrade board), we don't know the
- * physical base address of RAM at compile time.
- */
 #define toreal(rd) tophys(rd,rd)
 #define fromreal(rd)   tovirt(rd,rd)
 
-#define tophys(rd,rs)  \
-0: addis   rd,rs,-PAGE_OFFSET@h;   \
-   .section ".vtop_fixup","aw";\
-   .align  1;  \
-   .long   0b; \
-   .previous
-
-#define tovirt(rd,rs)  \
-0: addis   rd,rs,PAGE_OFFSET@h;\
-   .section ".ptov_fixup","aw";\
-   .align  1;  \
-   .long   0b; \
-   .previous
+#define tophys(rd, rs) addis   rd, rs, -PAGE_OFFSET@h
+#define tovirt(rd, rs) addis   rd, rs, PAGE_OFFSET@h
 #endif
 
 #ifdef CONFIG_PPC_BOOK3S_64
diff --git a/arch/powerpc/kernel/vmlinux.lds.S 
b/arch/powerpc/kernel/vmlinux.lds.S
index d210dcfe915a..c133732e529a 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -203,12 +203,6 @@ SECTIONS
 
.init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {
INIT_DATA
-   __vtop_table_begin = .;
-   KEEP(*(.vtop_fixup));
-   __vtop_table_end = .;
-   __ptov_table_begin = .;
-   KEEP(*(.ptov_fixup));
-   __ptov_table_end = .;
}
 
.init.setup : AT(ADDR(.init.setup) - LOAD_OFFSET) {
-- 
2.13.3



Re: [PATCH] selftests/powerpc: New TM signal self test

2018-12-04 Thread Breno Leitao
Hi Mikey,

On 11/29/18 12:11 AM, Michael Neuling wrote:
> On Wed, 2018-11-28 at 11:23 -0200, Breno Leitao wrote:
>> A new self test that forces MSR[TS] to be set without calling any TM
>> instruction. This test also tries to cause a page fault at a signal
>> handler, exactly between MSR[TS] set and tm_recheckpoint(), forcing
>> thread->texasr to be rewritten with TEXASR[FS] = 0, which will cause a BUG
>> when tm_recheckpoint() is called.
>>
>> This test is not deterministic since it is hard to guarantee that the page
>> access will cause a page fault. Tests have shown that the bug could be
>> exposed with few interactions in a buggy kernel. This test is configured to
>> loop 5000x, having a good chance to hit the kernel issue in just one run.
>> This self test takes less than two seconds to run.
> 
> You could try using sigaltstack() to put the ucontext somewhere else. Then you
> could play tricks with that memory to try to force a fault.
> madvise()+MADV_DONTNEED or fadvise()+POSIX_FADV_DONTNEED might do the trick.

Yes, it sounded interesting and I implemented the test using madvice(). Thanks
for the suggestion!

The current approach didn't seem to improve the amount of page faults at it
seems that MADV_DONTNEED makes no difference when using a Lazy page loading.
This is the test I did, where 'original' is my current patch and 'madvice` is
the patch below:

  Performance counter stats for './original':

 0  major-faults

   125,100  minor-faults


   2.575479619 seconds time elapsed


  Performance counter stats for './madvice':

 0  major-faults

   125,099  minor-faults 



Other than that, I didn't see any improvements in the reproduction rate also, 
although
it is a bit challenging to measure, since it crashes the machine and I can't 
run a
full statistical model.

This is the current patch I compared to the original one

---

commit 082a9fe29412943adfa2d6a363f44bac8e81d0ce
Author: Breno Leitao 
Date:   Tue Nov 13 18:02:57 2018 -0500

selftests/powerpc: New TM signal self test

A new self test that forces MSR[TS] to be set without calling any TM
instruction. This test also tries to cause a page fault at a signal
handler, exactly between MSR[TS] set and tm_recheckpoint(), forcing
thread->texasr to be rewritten with TEXASR[FS] = 0, which will cause a BUG
when tm_recheckpoint() is called.

This test is not deterministic, since it is hard to guarantee that the page
access will cause a page fault. In order to force more page faults at
signal context, the signal handler and the ucontext are being mapped into a
MADV_DONTNEED memory chunks.

Tests have shown that the bug could be exposed with few interactions in a
buggy kernel. This test is configured to loop 5000x, having a good chance
to hit the kernel issue in just one run.  This self test takes less than
two seconds to run.

This test uses set/getcontext because the kernel will recheckpoint
zeroed structures, causing the test to segfault, which is undesired because
the test needs to rerun, so, there is a signal handler for SIGSEGV which
will restart the test.

Signed-off-by: Breno Leitao 

diff --git a/tools/testing/selftests/powerpc/tm/.gitignore 
b/tools/testing/selftests/powerpc/tm/.gitignore
index c3ee8393dae8..89679822ebc9 100644
--- a/tools/testing/selftests/powerpc/tm/.gitignore
+++ b/tools/testing/selftests/powerpc/tm/.gitignore
@@ -11,6 +11,7 @@ tm-signal-context-chk-fpu
 tm-signal-context-chk-gpr
 tm-signal-context-chk-vmx
 tm-signal-context-chk-vsx
+tm-signal-force-msr
 tm-vmx-unavail
 tm-unavailable
 tm-trap
diff --git a/tools/testing/selftests/powerpc/tm/Makefile 
b/tools/testing/selftests/powerpc/tm/Makefile
index 9fc2cf6fbc92..58a2ebd13958 100644
--- a/tools/testing/selftests/powerpc/tm/Makefile
+++ b/tools/testing/selftests/powerpc/tm/Makefile
@@ -4,7 +4,7 @@ SIGNAL_CONTEXT_CHK_TESTS := tm-signal-context-chk-gpr 
tm-signal-context-chk-fpu
 
 TEST_GEN_PROGS := tm-resched-dscr tm-syscall tm-signal-msr-resv 
tm-signal-stack \
tm-vmxcopy tm-fork tm-tar tm-tmspr tm-vmx-unavail tm-unavailable 
tm-trap \
-   $(SIGNAL_CONTEXT_CHK_TESTS) tm-sigreturn
+   $(SIGNAL_CONTEXT_CHK_TESTS) tm-sigreturn tm-signal-force-msr
 
 top_srcdir = ../../../../..
 include ../../lib.mk
@@ -20,6 +20,7 @@ $(OUTPUT)/tm-vmx-unavail: CFLAGS += -pthread -m64
 $(OUTPUT)/tm-resched-dscr: ../pmu/lib.c
 $(OUTPUT)/tm-unavailable: CFLAGS += -O0 -pthread -m64 -Wno-error=uninitialized 
-mvsx
 $(OUTPUT)/tm-trap: CFLAGS += -O0 -pthread -m64
+$(OUTPUT)/tm-signal-force-msr: CFLAGS += -pthread
 
 SIGNAL_CONTEXT_CHK_TESTS := $(patsubst 
%,$(OUTPUT)/%,$(SIGNAL_CONTEXT_CHK_TESTS))
 $(SIGNAL_CONTEXT_CHK_TESTS): tm-signal.S
diff --git 

Re: [PATCH v2 2/3] powerpc: Discard dynsym section for !PPC32

2018-12-04 Thread Segher Boessenkool
On Tue, Dec 04, 2018 at 11:24:28AM +1030, Joel Stanley wrote:
> Alan Modra  explains:
> 
>  > Likely you could discard .interp > and .dynstr too, and .dynsym when
>  > !CONFIG_PPC32.
> 
> Discarding of interp and dynstr happened in a previous patch. The dynsym
> cleanup was a bit less straightforward, so it gets it's own patch.

> diff --git a/arch/powerpc/kernel/vmlinux.lds.S 
> b/arch/powerpc/kernel/vmlinux.lds.S
> index 6570209b0671..2c93a420f456 100644
> --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -266,14 +266,13 @@ SECTIONS
>   }
>  #ifdef CONFIG_RELOCATABLE
>   . = ALIGN(8);
> +#ifdef CONFIG_PPC32
>   .dynsym : AT(ADDR(.dynsym) - LOAD_OFFSET)
>   {
> -#ifdef CONFIG_PPC32
>   __dynamic_symtab = .;
> -#endif
>   *(.dynsym)
>   }
> - .dynstr : AT(ADDR(.dynstr) - LOAD_OFFSET) { *(.dynstr) }

So this last line belongs in the previous patch then, right?


Segher


Re: [PATCH v2 1/6] powerpc: prefer memblock APIs returning virtual address

2018-12-04 Thread Mike Rapoport
On Tue, Dec 04, 2018 at 08:59:41PM +1100, Michael Ellerman wrote:
> Hi Mike,
> 
> Thanks for trying to clean these up.
> 
> I think a few could be improved though ...
> 
> Mike Rapoport  writes:
> > diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
> > index 913bfca..fa884ad 100644
> > --- a/arch/powerpc/kernel/paca.c
> > +++ b/arch/powerpc/kernel/paca.c
> > @@ -42,17 +42,15 @@ static void *__init alloc_paca_data(unsigned long size, 
> > unsigned long align,
> > nid = early_cpu_to_node(cpu);
> > }
> >  
> > -   pa = memblock_alloc_base_nid(size, align, limit, nid, MEMBLOCK_NONE);
> > -   if (!pa) {
> > -   pa = memblock_alloc_base(size, align, limit);
> > -   if (!pa)
> > -   panic("cannot allocate paca data");
> > -   }
> > +   ptr = memblock_alloc_try_nid_raw(size, align, MEMBLOCK_LOW_LIMIT,
> > +limit, nid);
> > +   if (!ptr)
> > +   panic("cannot allocate paca data");
>   
> The old code doesn't zero, but two of the three callers of
> alloc_paca_data() *do* zero the whole allocation, so I'd be happy if we
> did it in here instead.

I looked at the callers and couldn't tell if zeroing memory in
init_lppaca() would be ok.
I'll remove the _raw here.
 
> That would mean we could use memblock_alloc_try_nid() avoiding the need
> to panic() manually.

Actual, my plan was to remove panic() from all memblock_alloc* and make all
callers to check the returned value.
I believe it's cleaner and also allows more meaningful panic messages. Not
mentioning the reduction of memblock code.
 
> > diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> > index 236c115..d11ee7f 100644
> > --- a/arch/powerpc/kernel/setup_64.c
> > +++ b/arch/powerpc/kernel/setup_64.c
> > @@ -634,19 +634,17 @@ __init u64 ppc64_bolted_size(void)
> >  
> >  static void *__init alloc_stack(unsigned long limit, int cpu)
> >  {
> > -   unsigned long pa;
> > +   void *ptr;
> >  
> > BUILD_BUG_ON(STACK_INT_FRAME_SIZE % 16);
> >  
> > -   pa = memblock_alloc_base_nid(THREAD_SIZE, THREAD_SIZE, limit,
> > -   early_cpu_to_node(cpu), MEMBLOCK_NONE);
> > -   if (!pa) {
> > -   pa = memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit);
> > -   if (!pa)
> > -   panic("cannot allocate stacks");
> > -   }
> > +   ptr = memblock_alloc_try_nid_raw(THREAD_SIZE, THREAD_SIZE,
> > +MEMBLOCK_LOW_LIMIT, limit,
> > +early_cpu_to_node(cpu));
> > +   if (!ptr)
> > +   panic("cannot allocate stacks");
>  
> Similarly here, several of the callers zero the stack, and I'd rather
> all of them did.
> 
> So again we could use memblock_alloc_try_nid() here and remove the
> memset()s from emergency_stack_init().

Ok
 
> > diff --git a/arch/powerpc/mm/pgtable-radix.c 
> > b/arch/powerpc/mm/pgtable-radix.c
> > index 9311560..415a1eb0 100644
> > --- a/arch/powerpc/mm/pgtable-radix.c
> > +++ b/arch/powerpc/mm/pgtable-radix.c
> > @@ -51,24 +51,18 @@ static int native_register_process_table(unsigned long 
> > base, unsigned long pg_sz
> >  static __ref void *early_alloc_pgtable(unsigned long size, int nid,
> > unsigned long region_start, unsigned long region_end)
> >  {
> > -   unsigned long pa = 0;
> > +   phys_addr_t min_addr = MEMBLOCK_LOW_LIMIT;
> > +   phys_addr_t max_addr = MEMBLOCK_ALLOC_ANYWHERE;
> > void *pt;
> >  
> > -   if (region_start || region_end) /* has region hint */
> > -   pa = memblock_alloc_range(size, size, region_start, region_end,
> > -   MEMBLOCK_NONE);
> > -   else if (nid != -1) /* has node hint */
> > -   pa = memblock_alloc_base_nid(size, size,
> > -   MEMBLOCK_ALLOC_ANYWHERE,
> > -   nid, MEMBLOCK_NONE);
> > +   if (region_start)
> > +   min_addr = region_start;
> > +   if (region_end)
> > +   max_addr = region_end;
> >  
> > -   if (!pa)
> > -   pa = memblock_alloc_base(size, size, MEMBLOCK_ALLOC_ANYWHERE);
> > -
> > -   BUG_ON(!pa);
> > -
> > -   pt = __va(pa);
> > -   memset(pt, 0, size);
> > +   pt = memblock_alloc_try_nid_nopanic(size, size, min_addr, max_addr,
> > +   nid);
> > +   BUG_ON(!pt);
> 
> I don't think there's any reason to BUG_ON() here rather than letting
> memblock() call panic() for us. So this could also be 
> memblock_alloc_try_nid().

I'd prefer to panic here.
 
> > diff --git a/arch/powerpc/platforms/pasemi/iommu.c 
> > b/arch/powerpc/platforms/pasemi/iommu.c
> > index f297152..f62930f 100644
> > --- a/arch/powerpc/platforms/pasemi/iommu.c
> > +++ b/arch/powerpc/platforms/pasemi/iommu.c
> > @@ -208,7 +208,9 @@ static int __init iob_init(struct device_node *dn)
> > pr_debug(" -> %s\n", __func__);
> >  
> > /* For 2G space, 8x64 

Re: [PATCH v2 26/34] dt-bindings: arm: Convert Renesas board/soc bindings to json-schema

2018-12-04 Thread Rob Herring
On Tue, Dec 4, 2018 at 8:57 AM Geert Uytterhoeven  wrote:
>
> Hi Simon,
>
> On Tue, Dec 4, 2018 at 3:48 PM Simon Horman  wrote:
> > On Mon, Dec 03, 2018 at 03:32:15PM -0600, Rob Herring wrote:
> > > Convert Renesas SoC bindings to DT schema format using json-schema.
> > >
> > > Cc: Simon Horman 
> > > Cc: Magnus Damm 
> > > Cc: Mark Rutland 
> > > Cc: linux-renesas-...@vger.kernel.org
> > > Cc: devicet...@vger.kernel.org
> > > Signed-off-by: Rob Herring 
> > > ---
> > >  .../devicetree/bindings/arm/shmobile.txt  | 151 
> > >  .../devicetree/bindings/arm/shmobile.yaml | 218 ++
> > >  2 files changed, 218 insertions(+), 151 deletions(-)
> > >  delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt
> > >  create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml
> >
> > Hi Rob,
> >
> > what is this based on? I get a conflict when applying the .txt change
> > and if I knew the base for this patch it would be rather easy to work
> > out what has changed.

4.20-rc2

> >
> > Also, should we do an s/shmobile.txt/shmobile.yaml/ in MAINTAINERS?

Yes. Though it was pointed out that get_maintainers.pl can pull emails
out of this file. We'd need to get that to work by default though.

> Probably even s/shmobile.yaml/renesas.yaml/, while at it?

Sure, if that's what you all want.

Rob


Re: [PATCH v2 24/34] dt-bindings: arm: Convert Rockchip board/soc bindings to json-schema

2018-12-04 Thread Rob Herring
On Tue, Dec 4, 2018 at 8:16 AM Heiko Stuebner  wrote:
>
> Am Montag, 3. Dezember 2018, 22:32:13 CET schrieb Rob Herring:
> > Convert Rockchip SoC bindings to DT schema format using json-schema.
> >
> > Cc: Mark Rutland 
> > Cc: Heiko Stuebner 
> > Cc: devicet...@vger.kernel.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-rockc...@lists.infradead.org
> > Signed-off-by: Rob Herring 
>
> > diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml 
> > b/Documentation/devicetree/bindings/arm/rockchip.yaml
> > new file mode 100644
> > index ..3d30ec9adcd3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
> > @@ -0,0 +1,251 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/arm/rockchip.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Rockchip platforms device tree bindings
> > +
> > +maintainers:
> > +  - Beniamino Galvani 
>
> # scripts/get_maintainer.pl -f 
> Documentation/devicetree/bindings/arm/rockchip.txt
>
> doesn't list Beniamino at all and he hasn't been active on Rockchip stuff
> for a number of years, so I'm not really sure where this mention as
> maintainer comes from.

git history. get_maintainers.pl had too many cases where I ended up as
the maintainer.

I'll drop him.

> > +  - Heiko Stuebner 
> > +
> > +properties:
> > +  $nodename:
> > +const: '/'
> > +  compatible:
> > +oneOf:
> > +  - items:
> > +  - enum:
> > +  - amarula,vyasa-rk3288
> > +  - asus,rk3288-tinker
> > +  - asus,rk3288-tinker-s
> > +  - radxa,rock2-square
> > +  - chipspark,popmetal-rk3288
> > +  - netxeon,r89
> > +  - firefly,firefly-rk3288
> > +  - firefly,firefly-rk3288-beta
> > +  - firefly,firefly-rk3288-reload
> > +  - mqmaker,miqi
> > +  - rockchip,rk3288-fennec
> > +  - const: rockchip,rk3288
>
> [...]
>
> > +  - items:
> > +  - enum:
> > +  - firefly,firefly-rk3399
> > +  - firefly,roc-rk3399-pc
> > +  - pine64,rockpro64
> > +  - rockchip,rk3399-evb
> > +  - rockchip,rk3399-sapphire
> > +  - rockchip,rk3399-sapphire-excavator
> > +  - tsd,rk3399-q7-haikou
> > +  - vamrs,ficus
> > +  - vamrs,rock960 # 96boards RK3399 Rock960 (ROCK960 Consumer 
> > Edition)
> > +  - const: rockchip,rk3399
>
>
> as said before, loosing the description of the boards that get thrown
> into one listing really decreases the usability a lot.

Sorry, I thought I addressed these previous comments.

> Best example is maybe the rk3399 rock960, where the consumer-edition
> board is actually named "ficus" and the description actually brings the
> connection to the product-name.
>
> So here it may increase the machine-readability but definitly descreases
> the human readability of the file itself.
>
> I guess just using the format that all the Google-boards got for all boards
> would just be easiest, so for example the rock960 also would just become:
>
>   - description: 96boards RK3399 Ficus (ROCK960 Enterprise Edition)
> items:
>   - const: vamrs,ficus
>   - const: rockchip,rk3399
>
>   - description: 96boards RK3399 Ficus (ROCK960 Consumer Edition)
> items:
>   - const: vamrs,rock960
>   - const: rockchip,rk3399

Sure, you can do this if you like. I prefer the other way as it is a
one line change to add a board. The SoC maintainers can pick whatever
they like. You could split into a file per SoC too if you wanted.

> Looking at other socs, this is likely similar there. Like on Mediatek
> all the MT67xx eval boards loose the mapping to the
> socs marketing name "Helio Foobar" when the description is gone,
> which could've been helpful for people reading the binding.

Generally when we had just 'hello,foobar' with 'Hello Foobar' I
dropped the comment as I didn't think it added much.

Rob


Re: [PATCH v2 26/34] dt-bindings: arm: Convert Renesas board/soc bindings to json-schema

2018-12-04 Thread Geert Uytterhoeven
Hi Simon,

On Tue, Dec 4, 2018 at 3:48 PM Simon Horman  wrote:
> On Mon, Dec 03, 2018 at 03:32:15PM -0600, Rob Herring wrote:
> > Convert Renesas SoC bindings to DT schema format using json-schema.
> >
> > Cc: Simon Horman 
> > Cc: Magnus Damm 
> > Cc: Mark Rutland 
> > Cc: linux-renesas-...@vger.kernel.org
> > Cc: devicet...@vger.kernel.org
> > Signed-off-by: Rob Herring 
> > ---
> >  .../devicetree/bindings/arm/shmobile.txt  | 151 
> >  .../devicetree/bindings/arm/shmobile.yaml | 218 ++
> >  2 files changed, 218 insertions(+), 151 deletions(-)
> >  delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt
> >  create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml
>
> Hi Rob,
>
> what is this based on? I get a conflict when applying the .txt change
> and if I knew the base for this patch it would be rather easy to work
> out what has changed.
>
> Also, should we do an s/shmobile.txt/shmobile.yaml/ in MAINTAINERS?

Probably even s/shmobile.yaml/renesas.yaml/, while at it?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v2 25/34] dt-bindings: arm: renesas: Move 'renesas,prr' binding to its own doc

2018-12-04 Thread Geert Uytterhoeven
On Mon, Dec 3, 2018 at 10:35 PM Rob Herring  wrote:
> In preparation to convert board-level bindings to json-schema, move
> various misc SoC bindings out to their own file.
>
> Cc: Mark Rutland 
> Cc: Simon Horman 
> Cc: Magnus Damm 
> Cc: devicet...@vger.kernel.org
> Cc: linux-renesas-...@vger.kernel.org
> Signed-off-by: Rob Herring 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v2 14/34] dt-bindings: arm: Convert Amlogic board/soc bindings to json-schema

2018-12-04 Thread Rob Herring
On Tue, Dec 4, 2018 at 2:39 AM Neil Armstrong  wrote:
>
> Hi Rob,
>
> You forgot linux-amlogic in CC...
>
> On 03/12/2018 22:32, Rob Herring wrote:
> > Convert Amlogic SoC bindings to DT schema format using json-schema.
> >
> > Cc: Carlo Caione 
> > Cc: Kevin Hilman 
> > Cc: Mark Rutland 
> > Cc: devicet...@vger.kernel.org
> > Signed-off-by: Rob Herring 
> > ---

[...]

> > +  - items:
> > +  - enum:
> > +  - amlogic,s400
> > +  - const: amlogic,a113d
> > +  - const: amlogic,meson-axg
> > +  - items:
> > +  - enum:
> > +  - amlogic,u200
> > +  - const: amlogic,g12a
>
> but all this feels wrong for me.
>
> First of all, this yaml description is not human friendly and not intuitive 
> at all,
> and secondly with this conversion we loose all the comments about the SoC 
> family relationship
> with the compatible strings !
>
> I really understand the point to have automated verification, but really it's 
> a pain to read
> (I can't imagine newcomers... the actual DT bindings are already hard to 
> read...) and
> I feel it will be a real pain to write !

What do you suggest that would be easier? Is it the YAML itself or the
json-schema vocabulary? For the former, we could use {} and [] to make
things more json style. But I imagine it is the latter.

There is some learning curve for json-schema and is certainly a
concern I have, but there would be a learning curve for anything. Our
choices are use some existing schema language or invent one. All the
previous efforts (there's been about 5 since 2013) have been inventing
one, and they've not gone far. There will be far few resources
available to train people with if we do something custom.

> Can't we mix an "humam text" with a "yaml" part on a same document ? we are 
> in 2018 (nearly 2019),
> and it should be easy to extract a yaml description from a text document 
> without pain and
> keep all the human description, no ?

Yes. Please go look at the annotated example in patch 2.

> What will be the case for all the bindings with ASCII art to describe the 
> architecture of the
> HW ? will you simply drop it to replace it with cold yaml description ?

No, you can have literal blocks and/or comments with however much
description you like. In fact, there's some notion to write the
descriptions in sphinx and extract them to generate documentation, but
that's a ways off. That's just the extent of what is possible.

Rob


Re: [PATCH v2 24/34] dt-bindings: arm: Convert Rockchip board/soc bindings to json-schema

2018-12-04 Thread Heiko Stuebner
Am Montag, 3. Dezember 2018, 22:32:13 CET schrieb Rob Herring:
> Convert Rockchip SoC bindings to DT schema format using json-schema.
> 
> Cc: Mark Rutland 
> Cc: Heiko Stuebner 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-rockc...@lists.infradead.org
> Signed-off-by: Rob Herring 

> diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml 
> b/Documentation/devicetree/bindings/arm/rockchip.yaml
> new file mode 100644
> index ..3d30ec9adcd3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
> @@ -0,0 +1,251 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/rockchip.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip platforms device tree bindings
> +
> +maintainers:
> +  - Beniamino Galvani 

# scripts/get_maintainer.pl -f 
Documentation/devicetree/bindings/arm/rockchip.txt

doesn't list Beniamino at all and he hasn't been active on Rockchip stuff
for a number of years, so I'm not really sure where this mention as
maintainer comes from.


> +  - Heiko Stuebner 
> +
> +properties:
> +  $nodename:
> +const: '/'
> +  compatible:
> +oneOf:
> +  - items:
> +  - enum:
> +  - amarula,vyasa-rk3288
> +  - asus,rk3288-tinker
> +  - asus,rk3288-tinker-s
> +  - radxa,rock2-square
> +  - chipspark,popmetal-rk3288
> +  - netxeon,r89
> +  - firefly,firefly-rk3288
> +  - firefly,firefly-rk3288-beta
> +  - firefly,firefly-rk3288-reload
> +  - mqmaker,miqi
> +  - rockchip,rk3288-fennec
> +  - const: rockchip,rk3288

[...]

> +  - items:
> +  - enum:
> +  - firefly,firefly-rk3399
> +  - firefly,roc-rk3399-pc
> +  - pine64,rockpro64
> +  - rockchip,rk3399-evb
> +  - rockchip,rk3399-sapphire
> +  - rockchip,rk3399-sapphire-excavator
> +  - tsd,rk3399-q7-haikou
> +  - vamrs,ficus
> +  - vamrs,rock960 # 96boards RK3399 Rock960 (ROCK960 Consumer 
> Edition)
> +  - const: rockchip,rk3399


as said before, loosing the description of the boards that get thrown 
into one listing really decreases the usability a lot.

Best example is maybe the rk3399 rock960, where the consumer-edition
board is actually named "ficus" and the description actually brings the
connection to the product-name.

So here it may increase the machine-readability but definitly descreases
the human readability of the file itself.

I guess just using the format that all the Google-boards got for all boards
would just be easiest, so for example the rock960 also would just become:

  - description: 96boards RK3399 Ficus (ROCK960 Enterprise Edition)
items:
  - const: vamrs,ficus
  - const: rockchip,rk3399

  - description: 96boards RK3399 Ficus (ROCK960 Consumer Edition)
items:
  - const: vamrs,rock960
  - const: rockchip,rk3399


Looking at other socs, this is likely similar there. Like on Mediatek
all the MT67xx eval boards loose the mapping to the
socs marketing name "Helio Foobar" when the description is gone,
which could've been helpful for people reading the binding.


Heiko


> +  - description: Google Bob (Asus Chromebook Flip C101PA)
> +items:
> +  - const: google,bob-rev13
> +  - const: google,bob-rev12
> +  - const: google,bob-rev11
> +  - const: google,bob-rev10
> +  - const: google,bob-rev9
> +  - const: google,bob-rev8
> +  - const: google,bob-rev7
> +  - const: google,bob-rev6
> +  - const: google,bob-rev5
> +  - const: google,bob-rev4
> +  - const: google,bob
> +  - const: google,gru
> +  - const: rockchip,rk3399






Re: use generic DMA mapping code in powerpc V4

2018-12-04 Thread Christoph Hellwig
On Tue, Dec 04, 2018 at 10:53:39AM +0100, Christian Zigotzky wrote:
> I don't know why this kernel doesn't recognize the hard disks connected to 
> my physical P5020 board and why the onboard ethernet on my PASEMI board 
> doesn't work. (dma_direct_map_page: overflow)

Do you know if this actually works for the baseline before my patches?
E.g. with commit 721c01ba8b46ddb5355bd6e6b3bbfdabfdf01e97 ?


Re: [PATCH v2 21/34] dt-bindings: arm: Convert Oxford Semi board/soc bindings to json-schema

2018-12-04 Thread Rob Herring
On Tue, Dec 4, 2018 at 2:43 AM Neil Armstrong  wrote:
>
> On 03/12/2018 22:32, Rob Herring wrote:
> > Convert Oxford Semi SoC bindings to DT schema format using json-schema.
> >
> > Cc: Mark Rutland 
> > Cc: Neil Armstrong 
> > Cc: devicet...@vger.kernel.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-ox...@groups.io
> > Signed-off-by: Rob Herring 
> > ---
> >  .../devicetree/bindings/arm/oxnas.txt | 14 ---
> >  .../devicetree/bindings/arm/oxnas.yaml| 25 +++
> >  2 files changed, 25 insertions(+), 14 deletions(-)
> >  delete mode 100644 Documentation/devicetree/bindings/arm/oxnas.txt
> >  create mode 100644 Documentation/devicetree/bindings/arm/oxnas.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/arm/oxnas.txt 
> > b/Documentation/devicetree/bindings/arm/oxnas.txt
> > deleted file mode 100644
> > index ac64e60f99f1..
> > --- a/Documentation/devicetree/bindings/arm/oxnas.txt
> > +++ /dev/null
> > @@ -1,14 +0,0 @@
> > -Oxford Semiconductor OXNAS SoCs Family device tree bindings
> > 
> > -
> > -Boards with the OX810SE SoC shall have the following properties:
> > -  Required root node property:
> > -compatible: "oxsemi,ox810se"
> > -
> > -Boards with the OX820 SoC shall have the following properties:
> > -  Required root node property:
> > -compatible: "oxsemi,ox820"
> > -
> > -Board compatible values:
> > -  - "wd,mbwe" (OX810SE)
> > -  - "cloudengines,pogoplugv3" (OX820)
> > diff --git a/Documentation/devicetree/bindings/arm/oxnas.yaml 
> > b/Documentation/devicetree/bindings/arm/oxnas.yaml
> > new file mode 100644
> > index ..6ae51ef513be
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/oxnas.yaml
> > @@ -0,0 +1,25 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/arm/oxnas.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Oxford Semiconductor OXNAS SoCs Family device tree bindings
> > +
> > +maintainers:
> > +  - Neil Armstrong 
> > +
> > +properties:
> > +  $nodename:
> > +const: '/'
> > +  compatible:
> > +oneOf:
> > +  - items:
> > +- enum:
> > +- wd,mbwe
> > +- const: oxsemi,ox810se
> > +
> > +  - items:
> > +- enum:
> > +- cloudengines,pogoplugv3
> > +- const: oxsemi,ox820
> >
>
> We also loose all the "human friendly" description of board/SoC relationship 
> here,
> and I think it's a shame.

You can have whatever comments or description properties you like, so
how would you like it to look?

Rob


Re: [PATCH V2 4/5] mm/hugetlb: Add prot_modify_start/commit sequence for hugetlb update

2018-12-04 Thread Aneesh Kumar K.V
"Aneesh Kumar K.V"  writes:

> On 11/29/18 3:40 AM, Andrew Morton wrote:
>> On Wed, 28 Nov 2018 20:04:37 +0530 "Aneesh Kumar K.V" 
>>  wrote:
>> 
>>> Signed-off-by: Aneesh Kumar K.V 
>> 
>> Some explanation of the motivation would be useful.
>
> I will update the commit message.
>

Is this good?

mm/hugetlb: Add prot_modify_start/commit sequence for hugetlb update

Architectures like ppc64 requires to do a conditional tlb flush based on 
the old
and new value of pte. Follow the regular pte change protection sequence for
hugetlb too. This allow the architectures to override the update sequence.

-aneesh



Re: [PATCH] powerpc/pkeys: copy pkey-tracking-information at fork()

2018-12-04 Thread Florian Weimer
* Ram Pai:

> +void arch_dup_pkeys(struct mm_struct *oldmm, struct mm_struct *mm)
> +{
> + /* Duplicate the oldmm pkey state in mm: */
> + mm_pkey_allocation_map(mm) = mm_pkey_allocation_map(oldmm);
> + mm->context.execute_only_pkey = oldmm->context.execute_only_pkey;
> +}

Looks reasonable to me.

Thanks,
Florian (who is not a kernel developer though)


Re: [PATCH v2 11/34] dt-bindings: arm: Convert Alpine board/soc bindings to json-schema

2018-12-04 Thread Antoine Tenart
Hi Rob,

On Mon, Dec 03, 2018 at 03:32:00PM -0600, Rob Herring wrote:
> diff --git a/Documentation/devicetree/bindings/arm/al,alpine.yaml 
> b/Documentation/devicetree/bindings/arm/al,alpine.yaml
> new file mode 100644
> index ..82e2fafdfece
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/al,alpine.yaml
> @@ -0,0 +1,21 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/al,alpine.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Annapurna Labs Alpine Platform Device Tree Bindings
> +
> +maintainers:
> +  - Tsahee Zidenberg 

Could you add '- Antoine Tenart ' here?

Thanks!
Antoine

> +description: test
> +
> +properties:
> +  compatible:
> +items:
> +  - const: al,alpine
> +  model:
> +items:
> +  - const: "Annapurna Labs Alpine Dev Board"
> +
> +...
> -- 
> 2.19.1
> 

-- 
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: ppc440gp "ebony" board manual/specs

2018-12-04 Thread Benjamin Herrenschmidt
On Tue, 2018-12-04 at 12:19 +0100, Mathieu Malaterre wrote:
> On Tue, Dec 4, 2018 at 12:09 PM Benjamin Herrenschmidt
>  wrote:
> > Hi folks !
> > 
> > Does anybody still has the manual or schematics (or both!) of the old
> > "ebony" ppc440gp eval board around by any chance ?
> 
> A google search for:
> 
> IBM/AMCC "PPC440GP" Evaluation Board datasheet
> 
> leads to:
> 
> https://4donline.ihs.com/images/VipMasterIC/IC/AMCC/AMCCS00334/AMCCS00334-1.pdf?hkey=EF798316E3902B6ED9A73243A3159BB0

Which is the processor data sheet, not the board :)

Cheers,
Ben.




Re: ppc440gp "ebony" board manual/specs

2018-12-04 Thread Mathieu Malaterre
On Tue, Dec 4, 2018 at 12:09 PM Benjamin Herrenschmidt
 wrote:
>
> Hi folks !
>
> Does anybody still has the manual or schematics (or both!) of the old
> "ebony" ppc440gp eval board around by any chance ?

A google search for:

IBM/AMCC "PPC440GP" Evaluation Board datasheet

leads to:

https://4donline.ihs.com/images/VipMasterIC/IC/AMCC/AMCCS00334/AMCCS00334-1.pdf?hkey=EF798316E3902B6ED9A73243A3159BB0


ppc440gp "ebony" board manual/specs

2018-12-04 Thread Benjamin Herrenschmidt
Hi folks !

Does anybody still has the manual or schematics (or both!) of the old
"ebony" ppc440gp eval board around by any chance ?

Cheers
Ben.




[PATCH 4.19 103/139] powerpc/function_graph: Simplify with function_graph_enter()

2018-12-04 Thread Greg Kroah-Hartman
4.19-stable review patch.  If anyone has any objections, please let me know.

--

From: Steven Rostedt (VMware) 

commit fe60522ec60082a1dd735691b82c64f65d4ad15e upstream.

The function_graph_enter() function does the work of calling the function
graph hook function and the management of the shadow stack, simplifying the
work done in the architecture dependent prepare_ftrace_return().

Have powerpc use the new code, and remove the shadow stack management as well as
having to set up the trace structure.

This is needed to prepare for a fix of a design bug on how the curr_ret_stack
is used.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: sta...@kernel.org
Fixes: 03274a3ffb449 ("tracing/fgraph: Adjust fgraph depth before calling trace 
return callback")
Reviewed-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt (VMware) 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/powerpc/kernel/trace/ftrace.c |   15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

--- a/arch/powerpc/kernel/trace/ftrace.c
+++ b/arch/powerpc/kernel/trace/ftrace.c
@@ -697,7 +697,6 @@ int ftrace_disable_ftrace_graph_caller(v
  */
 unsigned long prepare_ftrace_return(unsigned long parent, unsigned long ip)
 {
-   struct ftrace_graph_ent trace;
unsigned long return_hooker;
 
if (unlikely(ftrace_graph_is_dead()))
@@ -708,18 +707,8 @@ unsigned long prepare_ftrace_return(unsi
 
return_hooker = ppc_function_entry(return_to_handler);
 
-   trace.func = ip;
-   trace.depth = current->curr_ret_stack + 1;
-
-   /* Only trace if the calling function expects to */
-   if (!ftrace_graph_entry())
-   goto out;
-
-   if (ftrace_push_return_trace(parent, ip, , 0,
-NULL) == -EBUSY)
-   goto out;
-
-   parent = return_hooker;
+   if (!function_graph_enter(parent, ip, 0, NULL))
+   parent = return_hooker;
 out:
return parent;
 }




Re: [PATCH v2 1/6] powerpc: prefer memblock APIs returning virtual address

2018-12-04 Thread Michael Ellerman
Hi Mike,

Thanks for trying to clean these up.

I think a few could be improved though ...

Mike Rapoport  writes:
> diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
> index 913bfca..fa884ad 100644
> --- a/arch/powerpc/kernel/paca.c
> +++ b/arch/powerpc/kernel/paca.c
> @@ -42,17 +42,15 @@ static void *__init alloc_paca_data(unsigned long size, 
> unsigned long align,
>   nid = early_cpu_to_node(cpu);
>   }
>  
> - pa = memblock_alloc_base_nid(size, align, limit, nid, MEMBLOCK_NONE);
> - if (!pa) {
> - pa = memblock_alloc_base(size, align, limit);
> - if (!pa)
> - panic("cannot allocate paca data");
> - }
> + ptr = memblock_alloc_try_nid_raw(size, align, MEMBLOCK_LOW_LIMIT,
> +  limit, nid);
> + if (!ptr)
> + panic("cannot allocate paca data");
  
The old code doesn't zero, but two of the three callers of
alloc_paca_data() *do* zero the whole allocation, so I'd be happy if we
did it in here instead.

That would mean we could use memblock_alloc_try_nid() avoiding the need
to panic() manually.

> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index 236c115..d11ee7f 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -634,19 +634,17 @@ __init u64 ppc64_bolted_size(void)
>  
>  static void *__init alloc_stack(unsigned long limit, int cpu)
>  {
> - unsigned long pa;
> + void *ptr;
>  
>   BUILD_BUG_ON(STACK_INT_FRAME_SIZE % 16);
>  
> - pa = memblock_alloc_base_nid(THREAD_SIZE, THREAD_SIZE, limit,
> - early_cpu_to_node(cpu), MEMBLOCK_NONE);
> - if (!pa) {
> - pa = memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit);
> - if (!pa)
> - panic("cannot allocate stacks");
> - }
> + ptr = memblock_alloc_try_nid_raw(THREAD_SIZE, THREAD_SIZE,
> +  MEMBLOCK_LOW_LIMIT, limit,
> +  early_cpu_to_node(cpu));
> + if (!ptr)
> + panic("cannot allocate stacks");
 
Similarly here, several of the callers zero the stack, and I'd rather
all of them did.

So again we could use memblock_alloc_try_nid() here and remove the
memset()s from emergency_stack_init().

> diff --git a/arch/powerpc/mm/pgtable-radix.c b/arch/powerpc/mm/pgtable-radix.c
> index 9311560..415a1eb0 100644
> --- a/arch/powerpc/mm/pgtable-radix.c
> +++ b/arch/powerpc/mm/pgtable-radix.c
> @@ -51,24 +51,18 @@ static int native_register_process_table(unsigned long 
> base, unsigned long pg_sz
>  static __ref void *early_alloc_pgtable(unsigned long size, int nid,
>   unsigned long region_start, unsigned long region_end)
>  {
> - unsigned long pa = 0;
> + phys_addr_t min_addr = MEMBLOCK_LOW_LIMIT;
> + phys_addr_t max_addr = MEMBLOCK_ALLOC_ANYWHERE;
>   void *pt;
>  
> - if (region_start || region_end) /* has region hint */
> - pa = memblock_alloc_range(size, size, region_start, region_end,
> - MEMBLOCK_NONE);
> - else if (nid != -1) /* has node hint */
> - pa = memblock_alloc_base_nid(size, size,
> - MEMBLOCK_ALLOC_ANYWHERE,
> - nid, MEMBLOCK_NONE);
> + if (region_start)
> + min_addr = region_start;
> + if (region_end)
> + max_addr = region_end;
>  
> - if (!pa)
> - pa = memblock_alloc_base(size, size, MEMBLOCK_ALLOC_ANYWHERE);
> -
> - BUG_ON(!pa);
> -
> - pt = __va(pa);
> - memset(pt, 0, size);
> + pt = memblock_alloc_try_nid_nopanic(size, size, min_addr, max_addr,
> + nid);
> + BUG_ON(!pt);

I don't think there's any reason to BUG_ON() here rather than letting
memblock() call panic() for us. So this could also be memblock_alloc_try_nid().

> diff --git a/arch/powerpc/platforms/pasemi/iommu.c 
> b/arch/powerpc/platforms/pasemi/iommu.c
> index f297152..f62930f 100644
> --- a/arch/powerpc/platforms/pasemi/iommu.c
> +++ b/arch/powerpc/platforms/pasemi/iommu.c
> @@ -208,7 +208,9 @@ static int __init iob_init(struct device_node *dn)
>   pr_debug(" -> %s\n", __func__);
>  
>   /* For 2G space, 8x64 pages (2^21 bytes) is max total l2 size */
> - iob_l2_base = (u32 *)__va(memblock_alloc_base(1UL<<21, 1UL<<21, 
> 0x8000));
> + iob_l2_base = memblock_alloc_try_nid_raw(1UL << 21, 1UL << 21,
> + MEMBLOCK_LOW_LIMIT, 0x8000,
> + NUMA_NO_NODE);

This isn't equivalent is it?

memblock_alloc_base() panics on failure but memblock_alloc_try_nid_raw()
doesn't?

Same comment for the other locations that do that conversion.

cheers


Re: use generic DMA mapping code in powerpc V4

2018-12-04 Thread Christian Zigotzky

On 04 December 2018 at 08:31AM, Christian Zigotzky wrote:

Hi All,

Could you please test Christoph's kernel on your PASEMI and NXP 
boards? Download:


'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a'

Thanks,
Christian


I successfully tested this kernel on a virtual e5500 QEMU machine today.

Command: ./qemu-system-ppc64 -M ppce500 -cpu e5500 -m 2048 -kernel 
uImage-dma -drive 
format=raw,file=MATE_PowerPC_Remix_2017_0.9.img,index=0,if=virtio -nic 
user,model=e1000 -append "rw root=/dev/vda" -device virtio-vga -device 
virtio-mouse-pci -device virtio-keyboard-pci -usb -soundhw es1370 -smp 4


QEMU version 3.1.0.

I don't know why this kernel doesn't recognize the hard disks connected 
to my physical P5020 board and why the onboard ethernet on my PASEMI 
board doesn't work. (dma_direct_map_page: overflow)


-- Christian



Re: [PATCH RFCv2 3/4] mm/memory_hotplug: Introduce and use more memory types

2018-12-04 Thread David Hildenbrand
On 04.12.18 10:44, Michal Suchánek wrote:
> On Fri, 30 Nov 2018 18:59:21 +0100
> David Hildenbrand  wrote:
> 
>> Let's introduce new types for different kinds of memory blocks and use
>> them in existing code. As I don't see an easy way to split this up,
>> do it in one hunk for now.
>>
>> acpi:
>>  Use DIMM or DIMM_UNREMOVABLE depending on hotremove support in the kernel.
>>  Properly change the type when trying to add memory that was already
>>  detected and used during boot (so this memory will correctly end up as
>>  "acpi" in user space).
>>
>> pseries:
>>  Use DIMM or DIMM_UNREMOVABLE depending on hotremove support in the kernel.
>>  As far as I see, handling like in the acpi case for existing blocks is
>>  not required.
>>
>> probed memory from user space:
>>  Use DIMM_UNREMOVABLE as there is no interface to get rid of this code
>>  again.
>>
>> hv_balloon,xen/balloon:
>>  Use BALLOON. As simple as that :)
>>
>> s390x/sclp:
>>  Use a dedicated type S390X_STANDBY as this type of memory and it's
>>  semantics are very s390x specific.
>>
>> powernv/memtrace:
>>  Only allow to use BOOT memory for memtrace. I consider this code in
>>  general dangerous, but we have to keep it working ... most probably just
>>  a debug feature.
> 
> I don't think it should be arbitrarily restricted like that.
> 

Well code that "randomly" offlines/onlines/removes/adds memory blocks
that it does not own (hint: nobody else in the kernel does that), should
be restricted to types we can guarantee to work.

> Thanks
> 
> Michal
> 


-- 

Thanks,

David / dhildenb


Re: [PATCH RFCv2 3/4] mm/memory_hotplug: Introduce and use more memory types

2018-12-04 Thread Michal Suchánek
On Fri, 30 Nov 2018 18:59:21 +0100
David Hildenbrand  wrote:

> Let's introduce new types for different kinds of memory blocks and use
> them in existing code. As I don't see an easy way to split this up,
> do it in one hunk for now.
> 
> acpi:
>  Use DIMM or DIMM_UNREMOVABLE depending on hotremove support in the kernel.
>  Properly change the type when trying to add memory that was already
>  detected and used during boot (so this memory will correctly end up as
>  "acpi" in user space).
> 
> pseries:
>  Use DIMM or DIMM_UNREMOVABLE depending on hotremove support in the kernel.
>  As far as I see, handling like in the acpi case for existing blocks is
>  not required.
> 
> probed memory from user space:
>  Use DIMM_UNREMOVABLE as there is no interface to get rid of this code
>  again.
> 
> hv_balloon,xen/balloon:
>  Use BALLOON. As simple as that :)
> 
> s390x/sclp:
>  Use a dedicated type S390X_STANDBY as this type of memory and it's
>  semantics are very s390x specific.
> 
> powernv/memtrace:
>  Only allow to use BOOT memory for memtrace. I consider this code in
>  general dangerous, but we have to keep it working ... most probably just
>  a debug feature.

I don't think it should be arbitrarily restricted like that.

Thanks

Michal


Re: [PATCH] powerpc/mm: dump block address translation on book3s/32

2018-12-04 Thread Michael Ellerman
Christophe LEROY  writes:

> Le 16/11/2018 à 11:20, Michael Ellerman a écrit :
>> Christophe LEROY  writes:
>> 
>>> Le 15/11/2018 à 12:46, Michael Ellerman a écrit :
 Christophe Leroy  writes:

> This patch adds a debugfs file to dump block address translation:
>
> ~# cat /sys/kernel/debug/block_address_translation

 My instinct is it should be in /sys/kernel/debug/powerpc. But I guess
 the other page table dump files are not.
>>>
>>> Lol.
>>>
>>> Looks like we have the same instinct ...
>>>
>>> But you rejected my patch https://patchwork.ozlabs.org/patch/750426/ :)
>> 
>> Haha. My argument was that the kernel page table dump is not powerpc
>> specific, but this file *is* powerpc specific. Though I guess it's in
>> the same are as the page table / hash table dump, so it may as well live
>> next to them.
>
> I see you took the first version in next-test. It doesn't handle the 
> case of 64bits phys addresses. v3 does.
>
> I just sent v4 which does to v3 the changes you did (__init and powerpc/ 
> subdir)

Thanks, have picked up v4.

cheers


Re: [PATCH v2 30/34] dt-bindings: arm: Convert Tegra board/soc bindings to json-schema

2018-12-04 Thread Thierry Reding
On Mon, Dec 03, 2018 at 03:32:19PM -0600, Rob Herring wrote:
> Convert Tegra SoC bindings to DT schema format using json-schema.
> 
> Cc: Mark Rutland 
> Cc: Thierry Reding 
> Cc: Jonathan Hunter 
> Cc: devicet...@vger.kernel.org
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  .../devicetree/bindings/arm/tegra.txt |  65 ---
>  .../devicetree/bindings/arm/tegra.yaml| 101 ++
>  2 files changed, 101 insertions(+), 65 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/arm/tegra.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/tegra.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/tegra.txt 
> b/Documentation/devicetree/bindings/arm/tegra.txt
> deleted file mode 100644
> index c59b15f64346..
> --- a/Documentation/devicetree/bindings/arm/tegra.txt
> +++ /dev/null
> @@ -1,65 +0,0 @@
> -NVIDIA Tegra device tree bindings
> 
> -
> -SoCs
> 
> -
> -Each device tree must specify which Tegra SoC it uses, using one of the
> -following compatible values:
> -
> -  nvidia,tegra20
> -  nvidia,tegra30
> -  nvidia,tegra114
> -  nvidia,tegra124
> -  nvidia,tegra132
> -  nvidia,tegra210
> -  nvidia,tegra186
> -  nvidia,tegra194
> -
> -Boards
> 
> -
> -Each device tree must specify which one or more of the following
> -board-specific compatible values:
> -
> -  ad,medcom-wide
> -  ad,plutux
> -  ad,tamonten
> -  ad,tec
> -  compal,paz00
> -  compulab,trimslice
> -  nvidia,beaver
> -  nvidia,cardhu
> -  nvidia,cardhu-a02
> -  nvidia,cardhu-a04
> -  nvidia,dalmore
> -  nvidia,harmony
> -  nvidia,jetson-tk1
> -  nvidia,norrin
> -  nvidia,p2371-
> -  nvidia,p2371-2180
> -  nvidia,p2571
> -  nvidia,p2771-
> -  nvidia,p2972-
> -  nvidia,roth
> -  nvidia,seaboard
> -  nvidia,tn7
> -  nvidia,ventana
> -  toradex,apalis_t30
> -  toradex,apalis_t30-eval
> -  toradex,apalis_t30-v1.1
> -  toradex,apalis_t30-v1.1-eval
> -  toradex,apalis-tk1
> -  toradex,apalis-tk1-eval
> -  toradex,apalis-tk1-v1.2
> -  toradex,apalis-tk1-v1.2-eval
> -  toradex,colibri_t20
> -  toradex,colibri_t20-eval-v3
> -  toradex,colibri_t20-iris
> -  toradex,colibri_t30
> -  toradex,colibri_t30-eval-v3
> -
> -Trusted Foundations
> 
> -Tegra supports the Trusted Foundation secure monitor. See the
> -"tlm,trusted-foundations" binding's documentation for more details.
> diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml 
> b/Documentation/devicetree/bindings/arm/tegra.yaml
> new file mode 100644
> index ..66493892ffc1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/tegra.yaml
> @@ -0,0 +1,101 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/tegra.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#

Could you explain what these are? They give 404, so I assume they are
more like placeholders and not actually used?

> +
> +title: NVIDIA Tegra device tree bindings
> +
> +maintainers:
> +  - Marcel Ziswiler 
> +  - Peter De Schrijver 

Not sure how you got that list, but probably from git history. I think
it makes sense to replace Marcel and Peter with Jon and myself.

Other than that, looks fine to me. Some of the enumerations below look
somewhat hard to parse, but I suspect that it will become second nature
in no time.

Acked-by: Thierry Reding 

> +
> +properties:
> +  compatible:
> +oneOf:
> +  - items:
> +  - enum:
> +  - compal,paz00
> +  - compulab,trimslice
> +  - nvidia,harmony
> +  - nvidia,seaboard
> +  - nvidia,ventana
> +  - const: nvidia,tegra20
> +  - items:
> +  - enum:
> +  - ad,medcom-wide
> +  - ad,plutux
> +  - ad,tec
> +  - const: ad,tamonten
> +  - const: nvidia,tegra20
> +  - items:
> +  - enum:
> +  - toradex,colibri_t20-eval-v3
> +  - toradex,colibri_t20-iris
> +  - const: toradex,colibri_t20
> +  - const: nvidia,tegra20
> +  - items:
> +  - enum:
> +  - nvidia,beaver
> +  - const: nvidia,tegra30
> +  - items:
> +  - enum:
> +  - nvidia,cardhu-a02
> +  - nvidia,cardhu-a04
> +  - const: nvidia,cardhu
> +  - const: nvidia,tegra30
> +  - items:
> +  - const: toradex,apalis_t30-eval
> +  - const: toradex,apalis_t30
> +  - const: nvidia,tegra30
> +  - items:
> +  - const: toradex,apalis_t30-eval-v1.1
> +  - const: toradex,apalis_t30-eval
> +  - const: toradex,apalis_t30-v1.1
> +  - const: toradex,apalis_t30
> +  - const: nvidia,tegra30
> +  - items:
> +  - enum:
> +  - 

Re: [PATCH v2 21/34] dt-bindings: arm: Convert Oxford Semi board/soc bindings to json-schema

2018-12-04 Thread Neil Armstrong
On 03/12/2018 22:32, Rob Herring wrote:
> Convert Oxford Semi SoC bindings to DT schema format using json-schema.
> 
> Cc: Mark Rutland 
> Cc: Neil Armstrong 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-ox...@groups.io
> Signed-off-by: Rob Herring 
> ---
>  .../devicetree/bindings/arm/oxnas.txt | 14 ---
>  .../devicetree/bindings/arm/oxnas.yaml| 25 +++
>  2 files changed, 25 insertions(+), 14 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/arm/oxnas.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/oxnas.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/oxnas.txt 
> b/Documentation/devicetree/bindings/arm/oxnas.txt
> deleted file mode 100644
> index ac64e60f99f1..
> --- a/Documentation/devicetree/bindings/arm/oxnas.txt
> +++ /dev/null
> @@ -1,14 +0,0 @@
> -Oxford Semiconductor OXNAS SoCs Family device tree bindings
> 
> -
> -Boards with the OX810SE SoC shall have the following properties:
> -  Required root node property:
> -compatible: "oxsemi,ox810se"
> -
> -Boards with the OX820 SoC shall have the following properties:
> -  Required root node property:
> -compatible: "oxsemi,ox820"
> -
> -Board compatible values:
> -  - "wd,mbwe" (OX810SE)
> -  - "cloudengines,pogoplugv3" (OX820)
> diff --git a/Documentation/devicetree/bindings/arm/oxnas.yaml 
> b/Documentation/devicetree/bindings/arm/oxnas.yaml
> new file mode 100644
> index ..6ae51ef513be
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/oxnas.yaml
> @@ -0,0 +1,25 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/oxnas.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Oxford Semiconductor OXNAS SoCs Family device tree bindings
> +
> +maintainers:
> +  - Neil Armstrong 
> +
> +properties:
> +  $nodename:
> +const: '/'
> +  compatible:
> +oneOf:
> +  - items:
> +- enum:
> +- wd,mbwe
> +- const: oxsemi,ox810se
> +
> +  - items:
> +- enum:
> +- cloudengines,pogoplugv3
> +- const: oxsemi,ox820
> 

We also loose all the "human friendly" description of board/SoC relationship 
here,
and I think it's a shame.

Neil


Re: [PATCH 1/2] mm: add probe_user_read() and probe_user_address()

2018-12-04 Thread Michael Ellerman
Christophe Leroy  writes:

> In the powerpc, there are several places implementing safe
^
code ?

> access to user data. This is sometimes implemented using
> probe_kernel_address() with additional access_ok() verification,
> sometimes with get_user() enclosed in a pagefault_disable()/enable()
> pair, etc... :
> show_user_instructions()
> bad_stack_expansion()
> p9_hmi_special_emu()
> fsl_pci_mcheck_exception()
> read_user_stack_64()
> read_user_stack_32() on PPC64
> read_user_stack_32() on PPC32
> power_pmu_bhrb_to()
>
> In the same spirit as probe_kernel_read() and probe_kernel_address(),
> this patch adds probe_user_read() and probe_user_address().
>
> probe_user_read() does the same as probe_kernel_read() but
> first checks that it is really a user address.
>
> probe_user_address() is a shortcut to probe_user_read()

...

> +#define probe_user_address(addr, retval) \
> + probe_user_read(&(retval), addr, sizeof(retval))

I realise you added probe_user_address() to mirror probe_kernel_address(),
but I'd rather we just used probe_user_read() directly.

The only advantage of probe_kernel_address() is that you don't have to
mention retval twice.

But the downsides are that it's not obvious that you're writing to
retval (because the macro takes the address for you), and retval is
evaluated twice (the latter is usually not a problem but it can be).

eg, call sites like this are confusing:

static int read_user_stack_64(unsigned long __user *ptr, unsigned long *ret)
{
...

if (!probe_user_address(ptr, *ret))
return 0;

It's confusing because ret is a pointer, but then we dereference it
before passing it to probe_user_address(), so it looks like we're just
passing a value, but we're not.

Compare to:

if (!probe_user_read(ret, ptr, sizeof(*ret)))
return 0;

Which is entirely analogous to a call to memcpy() and involves no magic.

I know there's lots of precedent here with get_user() etc. but that
doesn't mean we have to follow that precedent blindly :)

I guess perhaps we can add probe_user_address() but just not use it in
the powerpc code, if other folks want it to exist.

cheers


Re: [PATCH v2 14/34] dt-bindings: arm: Convert Amlogic board/soc bindings to json-schema

2018-12-04 Thread Neil Armstrong
Hi Rob,

You forgot linux-amlogic in CC...

On 03/12/2018 22:32, Rob Herring wrote:
> Convert Amlogic SoC bindings to DT schema format using json-schema.
> 
> Cc: Carlo Caione 
> Cc: Kevin Hilman 
> Cc: Mark Rutland 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  .../devicetree/bindings/arm/amlogic.txt   | 109 --
>  .../devicetree/bindings/arm/amlogic.yaml  | 109 ++
>  2 files changed, 109 insertions(+), 109 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/arm/amlogic.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/amlogic.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt 
> b/Documentation/devicetree/bindings/arm/amlogic.txt
> deleted file mode 100644
> index f5c8d50a3506..
> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
> +++ /dev/null
> @@ -1,109 +0,0 @@
> -Amlogic MesonX device tree bindings
> 
> -
> -Work in progress statement:
> -
> -Device tree files and bindings applying to Amlogic SoCs and boards are
> -considered "unstable". Any Amlogic device tree binding may change at
> -any time. Be sure to use a device tree binary and a kernel image
> -generated from the same source tree.
> -
> -Please refer to Documentation/devicetree/bindings/ABI.txt for a definition 
> of a
> -stable binding/ABI.
> -
> 
> -
> -Boards with the Amlogic Meson6 SoC shall have the following properties:
> -  Required root node property:
> -compatible: "amlogic,meson6"
> -
> -Boards with the Amlogic Meson8 SoC shall have the following properties:
> -  Required root node property:
> -compatible: "amlogic,meson8";
> -
> -Boards with the Amlogic Meson8b SoC shall have the following properties:
> -  Required root node property:
> -compatible: "amlogic,meson8b";
> -
> -Boards with the Amlogic Meson8m2 SoC shall have the following properties:
> -  Required root node property:
> -compatible: "amlogic,meson8m2";
> -
> -Boards with the Amlogic Meson GXBaby SoC shall have the following properties:
> -  Required root node property:
> -compatible: "amlogic,meson-gxbb";
> -
> -Boards with the Amlogic Meson GXL S905X SoC shall have the following 
> properties:
> -  Required root node property:
> -compatible: "amlogic,s905x", "amlogic,meson-gxl";
> -
> -Boards with the Amlogic Meson GXL S905D SoC shall have the following 
> properties:
> -  Required root node property:
> -compatible: "amlogic,s905d", "amlogic,meson-gxl";
> -
> -Boards with the Amlogic Meson GXL S805X SoC shall have the following 
> properties:
> -  Required root node property:
> -compatible: "amlogic,s805x", "amlogic,meson-gxl";
> -
> -Boards with the Amlogic Meson GXL S905W SoC shall have the following 
> properties:
> -  Required root node property:
> -compatible: "amlogic,s905w", "amlogic,meson-gxl";
> -
> -Boards with the Amlogic Meson GXM S912 SoC shall have the following 
> properties:
> -  Required root node property:
> -compatible: "amlogic,s912", "amlogic,meson-gxm";
> -
> -Boards with the Amlogic Meson AXG A113D SoC shall have the following 
> properties:
> -  Required root node property:
> -compatible: "amlogic,a113d", "amlogic,meson-axg";
> -
> -Boards with the Amlogic Meson G12A S905D2 SoC shall have the following 
> properties:
> -  Required root node property:
> -compatible: "amlogic,g12a";
> -
> -Board compatible values (alphabetically, grouped by SoC):
> -
> -  - "geniatech,atv1200" (Meson6)
> -
> -  - "minix,neo-x8" (Meson8)
> -
> -  - "endless,ec100" (Meson8b)
> -  - "hardkernel,odroid-c1" (Meson8b)
> -  - "tronfy,mxq" (Meson8b)
> -
> -  - "tronsmart,mxiii-plus" (Meson8m2)
> -
> -  - "amlogic,p200" (Meson gxbb)
> -  - "amlogic,p201" (Meson gxbb)
> -  - "friendlyarm,nanopi-k2" (Meson gxbb)
> -  - "hardkernel,odroid-c2" (Meson gxbb)
> -  - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
> -  - "tronsmart,vega-s95-pro", "tronsmart,vega-s95" (Meson gxbb)
> -  - "tronsmart,vega-s95-meta", "tronsmart,vega-s95" (Meson gxbb)
> -  - "tronsmart,vega-s95-telos", "tronsmart,vega-s95" (Meson gxbb)
> -  - "wetek,hub" (Meson gxbb)
> -  - "wetek,play2" (Meson gxbb)
> -
> -  - "amlogic,p212" (Meson gxl s905x)
> -  - "hwacom,amazetv" (Meson gxl s905x)
> -  - "khadas,vim" (Meson gxl s905x)
> -  - "libretech,cc" (Meson gxl s905x)
> -
> -  - "amlogic,p230" (Meson gxl s905d)
> -  - "amlogic,p231" (Meson gxl s905d)
> -
> -  - "amlogic,p241" (Meson gxl s805x)
> -
> -  - "amlogic,p281" (Meson gxl s905w)
> -  - "oranth,tx3-mini" (Meson gxl s905w)
> -
> -  - "amlogic,q200" (Meson gxm s912)
> -  - "amlogic,q201" (Meson gxm s912)
> -  - "khadas,vim2" (Meson gxm s912)
> -  - "kingnovel,r-box-pro" (Meson gxm S912)
> -  - "nexbox,a1" (Meson gxm s912)
> -  - "tronsmart,vega-s96" (Meson gxm s912)
> -
> -  - "amlogic,s400" (Meson axg a113d)
> -
> -  - "amlogic,u200" (Meson g12a s905d2)
> diff --git 

Re: [PATCH v2 29/34] dt-bindings: arm: Convert ST STi board/soc bindings to json-schema

2018-12-04 Thread Patrice CHOTARD
Hi Rob

On 12/3/18 10:32 PM, Rob Herring wrote:
> Convert ST STi SoC bindings to DT schema format using json-schema.
> 
> Cc: Patrice Chotard 
> Cc: Mark Rutland 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  Documentation/devicetree/bindings/arm/sti.txt | 23 ---
>  .../devicetree/bindings/arm/sti.yaml  | 23 +++
>  2 files changed, 23 insertions(+), 23 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/arm/sti.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/sti.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/sti.txt 
> b/Documentation/devicetree/bindings/arm/sti.txt
> deleted file mode 100644
> index 8d27f6b084c7..
> --- a/Documentation/devicetree/bindings/arm/sti.txt
> +++ /dev/null
> @@ -1,23 +0,0 @@
> -ST STi Platforms Device Tree Bindings
> 
> -
> -Boards with the ST STiH415 SoC shall have the following properties:
> -Required root node property:
> -compatible = "st,stih415";
> -
> -Boards with the ST STiH416 SoC shall have the following properties:
> -Required root node property:
> -compatible = "st,stih416";
> -
> -Boards with the ST STiH407 SoC shall have the following properties:
> -Required root node property:
> -compatible = "st,stih407";
> -
> -Boards with the ST STiH410 SoC shall have the following properties:
> -Required root node property:
> -compatible = "st,stih410";
> -
> -Boards with the ST STiH418 SoC shall have the following properties:
> -Required root node property:
> -compatible = "st,stih418";
> -
> diff --git a/Documentation/devicetree/bindings/arm/sti.yaml 
> b/Documentation/devicetree/bindings/arm/sti.yaml
> new file mode 100644
> index ..47f9b8eebaa0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/sti.yaml
> @@ -0,0 +1,23 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/sti.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ST STi Platforms Device Tree Bindings
> +
> +maintainers:
> +  - Patrice Chotard 
> +
> +properties:
> +  $nodename:
> +const: '/'
> +  compatible:
> +items:
> +  - enum:
> +  - st,stih415
> +  - st,stih416
> +  - st,stih407
> +  - st,stih410
> +  - st,stih418
> +...
> 

Acked-by: Patrice Chotard 

Thanks

Re: [PATCH v2 13/34] dt-bindings: arm: amlogic: Move 'amlogic, meson-gx-ao-secure' binding to its own file

2018-12-04 Thread Neil Armstrong
On 03/12/2018 22:32, Rob Herring wrote:
> It is best practice to have 1 binding per file, so board level bindings
> should be separate for various misc SoC bindings.
> 
> Cc: Mark Rutland 
> Cc: Carlo Caione 
> Cc: Kevin Hilman 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-amlo...@lists.infradead.org
> Signed-off-by: Rob Herring 
> ---
>  .../devicetree/bindings/arm/amlogic.txt   | 29 ---
>  .../amlogic/amlogic,meson-gx-ao-secure.txt| 28 ++
>  2 files changed, 28 insertions(+), 29 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt 
> b/Documentation/devicetree/bindings/arm/amlogic.txt
> index 4498292b833d..f5c8d50a3506 100644
> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
> @@ -107,32 +107,3 @@ Board compatible values (alphabetically, grouped by SoC):
>- "amlogic,s400" (Meson axg a113d)
>  
>- "amlogic,u200" (Meson g12a s905d2)
> -
> -Amlogic Meson Firmware registers Interface
> ---
> -
> -The Meson SoCs have a register bank with status and data shared with the
> -secure firmware.
> -
> -Required properties:
> - - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-ao-secure", 
> "syscon"
> -
> -Properties should indentify components of this register interface :
> -
> -Meson GX SoC Information
> -
> -A firmware register encodes the SoC type, package and revision information on
> -the Meson GX SoCs.
> -If present, the following property should be added :
> -
> -Optional properties:
> -  - amlogic,has-chip-id: If present, the interface gives the current SoC 
> version.
> -
> -Example
> 
> -
> -ao-secure@140 {
> - compatible = "amlogic,meson-gx-ao-secure", "syscon";
> - reg = <0x0 0x140 0x0 0x140>;
> - amlogic,has-chip-id;
> -};
> diff --git 
> a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
>  
> b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
> new file mode 100644
> index ..c67d9f48fb91
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
> @@ -0,0 +1,28 @@
> +Amlogic Meson Firmware registers Interface
> +--
> +
> +The Meson SoCs have a register bank with status and data shared with the
> +secure firmware.
> +
> +Required properties:
> + - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-ao-secure", 
> "syscon"
> +
> +Properties should indentify components of this register interface :
> +
> +Meson GX SoC Information
> +
> +A firmware register encodes the SoC type, package and revision information on
> +the Meson GX SoCs.
> +If present, the following property should be added :
> +
> +Optional properties:
> +  - amlogic,has-chip-id: If present, the interface gives the current SoC 
> version.
> +
> +Example
> +---
> +
> +ao-secure@140 {
> + compatible = "amlogic,meson-gx-ao-secure", "syscon";
> + reg = <0x0 0x140 0x0 0x140>;
> + amlogic,has-chip-id;
> +};
> 

Acked-by: Neil Armstrong 


Re: [PATCH v2 15/34] dt-bindings: arm: Convert Atmel board/soc bindings to json-schema

2018-12-04 Thread Nicolas.Ferre
On 03/12/2018 at 22:32, Rob Herring wrote:
> Convert Atmel SoC bindings to DT schema format using json-schema.
> 
> Cc: Mark Rutland 
> Cc: Nicolas Ferre 

I'm listed here...

> Cc: Alexandre Belloni 

Proper email address here...


> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Rob Herring 
> ---
>   .../devicetree/bindings/arm/atmel-at91.txt|  72 --
>   .../devicetree/bindings/arm/atmel-at91.yaml   | 133 ++
>   2 files changed, 133 insertions(+), 72 deletions(-)
>   delete mode 100644 Documentation/devicetree/bindings/arm/atmel-at91.txt
>   create mode 100644 Documentation/devicetree/bindings/arm/atmel-at91.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt 
> b/Documentation/devicetree/bindings/arm/atmel-at91.txt
> deleted file mode 100644
> index 4bf1b4da7659..
> --- a/Documentation/devicetree/bindings/arm/atmel-at91.txt
> +++ /dev/null
> @@ -1,72 +0,0 @@
> -Atmel AT91 device tree bindings.
> -

[..]

> diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml 
> b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
> new file mode 100644
> index ..19431f58b906
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
> @@ -0,0 +1,133 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/atmel-at91.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Atmel AT91 device tree bindings.
> +
> +maintainers:
> +  - Alexandre Belloni 
> +  - Ludovic Desroches 

... and sorry but it's not correct just above ^^^
- wrong Ludovic's email address
- wrong Alexander's email address
- and I'm not part of the game anymore...

So actually our MAINTAINER's entry is up-to-date: please use it.


> +description: |
> +  Boards with a SoC of the Atmel AT91 or SMART family shall have the 
> following
> +
> +properties:
> +  $nodename:
> +const: '/'
> +  compatible:
> +oneOf:
> +  - items:
> +  - const: atmel,at91rm9200
> +  - items:
> +  - enum:
> +  - olimex,sam9-l9260
> +  - enum:
> +  - atmel,at91sam9260
> +  - atmel,at91sam9261
> +  - atmel,at91sam9263
> +  - atmel,at91sam9g20
> +  - atmel,at91sam9g45
> +  - atmel,at91sam9n12
> +  - atmel,at91sam9rl
> +  - atmel,at91sam9xe
> +  - const: atmel,at91sam9
> +
> +  - items:
> +  - enum:
> +  - atmel,at91sam9g15
> +  - atmel,at91sam9g25
> +  - atmel,at91sam9g35
> +  - atmel,at91sam9x25
> +  - atmel,at91sam9x35
> +  - const: atmel,at91sam9x5
> +  - const: atmel,at91sam9
> +
> +  - items:
> +  - const: atmel,sama5d27
> +  - const: atmel,sama5d2
> +  - const: atmel,sama5
> +
> +  - description: Nattis v2 board with Natte v2 power board
> +items:
> +  - const: axentia,nattis-2
> +  - const: axentia,natte-2
> +  - const: axentia,linea
> +  - const: atmel,sama5d31
> +  - const: atmel,sama5d3
> +  - const: atmel,sama5
> +
> +  - description: TSE-850 v3 board
> +items:
> +  - const: axentia,tse850v3
> +  - const: axentia,linea
> +  - const: atmel,sama5d31
> +  - const: atmel,sama5d3
> +  - const: atmel,sama5
> +
> +  - items:
> +  - const: axentia,linea
> +  - const: atmel,sama5d31
> +  - const: atmel,sama5d3
> +  - const: atmel,sama5
> +
> +  - items:
> +  - enum:
> +  - atmel,sama5d31
> +  - atmel,sama5d33
> +  - atmel,sama5d34
> +  - atmel,sama5d35
> +  - atmel,sama5d36
> +  - const: atmel,sama5d3
> +  - const: atmel,sama5
> +
> +  - items:
> +  - enum:
> +  - atmel,sama5d41
> +  - atmel,sama5d42
> +  - atmel,sama5d43
> +  - atmel,sama5d44
> +  - const: atmel,sama5d4
> +  - const: atmel,sama5
> +
> +  - items:
> +  - enum:
> +  - atmel,sams70j19
> +  - atmel,sams70j20
> +  - atmel,sams70j21
> +  - atmel,sams70n19
> +  - atmel,sams70n20
> +  - atmel,sams70n21
> +  - atmel,sams70q19
> +  - atmel,sams70q20
> +  - atmel,sams70q21
> +  - const: atmel,sams70
> +  - const: atmel,samv7
> +
> +  - items:
> +  - enum:
> +  - atmel,samv70j19
> +  - atmel,samv70j20
> +  - atmel,samv70n19
> +  - atmel,samv70n20
> +  - atmel,samv70q19
> +  - atmel,samv70q20
> +  - const: atmel,samv70
> +  - const: atmel,samv7
> +
> +  - items:
> +