[PATCH] powerpc: ptrace: tm_reclaim_current() in flush_tmregs_to_thread()

[Cyril Bur]

There was an assumption that flush_tmregs_to_thread() would only be
called for a task which is not current. And a warning could be shown
to indicate that current is being ptraced.

In the event of a core dump the current threads state is needed. This
means that flush_tmregs_to_thread() must do its best to flush even for
current.

This patch also moves flush_tmregs_to_thread() into ptrace.c as it is
only called from that file.

Signed-off-by: Cyril Bur 
---
 arch/powerpc/include/asm/switch_to.h |  8 
 arch/powerpc/kernel/process.c| 20 
 arch/powerpc/kernel/ptrace.c | 19 +++
 3 files changed, 19 insertions(+), 28 deletions(-)

diff --git a/arch/powerpc/include/asm/switch_to.h 
b/arch/powerpc/include/asm/switch_to.h
index 0a74ebe..17c8380 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -75,14 +75,6 @@ static inline void disable_kernel_spe(void)
 static inline void __giveup_spe(struct task_struct *t) { }
 #endif
 
-#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
-extern void flush_tmregs_to_thread(struct task_struct *);
-#else
-static inline void flush_tmregs_to_thread(struct task_struct *t)
-{
-}
-#endif
-
 static inline void clear_task_ebb(struct task_struct *t)
 {
 #ifdef CONFIG_PPC_BOOK3S_64
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 58ccf86..9ee2623 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1074,26 +1074,6 @@ static inline void restore_sprs(struct thread_struct 
*old_thread,
 #endif
 }
 
-#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
-void flush_tmregs_to_thread(struct task_struct *tsk)
-{
-   /*
-* Process self tracing is not yet supported through
-* ptrace interface. Ptrace generic code should have
-* prevented this from happening in the first place.
-* Warn once here with the message, if some how it
-* is attempted.
-*/
-   WARN_ONCE(tsk == current,
-   "Not expecting ptrace on self: TM regs may be incorrect\n");
-
-   /*
-* If task is not current, it should have been flushed
-* already to it's thread_struct during __switch_to().
-*/
-}
-#endif
-
 struct task_struct *__switch_to(struct task_struct *prev,
struct task_struct *new)
 {
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 4f3c575..bf91658 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define CREATE_TRACE_POINTS
 #include 
@@ -118,6 +119,24 @@ static const struct pt_regs_offset regoffset_table[] = {
REG_OFFSET_END,
 };
 
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+static void flush_tmregs_to_thread(struct task_struct *tsk)
+{
+   /*
+* If task is not current, it will have been flushed already to
+* it's thread_struct during __switch_to().
+*
+* A reclaim flushes ALL the state.
+*/
+
+   if (tsk == current && MSR_TM_SUSPENDED(mfmsr()))
+   tm_reclaim_current(TM_CAUSE_SIGNAL);
+
+}
+#else
+static inline void flush_tmregs_to_thread(struct task_struct *tsk) { }
+#endif
+
 /**
  * regs_query_register_offset() - query register offset from its name
  * @name:  the name of a register
-- 
2.9.2

Re: [PATCH kernel 14/15] vfio/spapr_tce: Export container API for external users

[Alexey Kardashevskiy]

On 09/08/16 22:16, Alex Williamson wrote:
> On Tue, 9 Aug 2016 15:19:39 +1000
> Alexey Kardashevskiy  wrote:
> 
>> On 09/08/16 02:43, Alex Williamson wrote:
>>> On Wed,  3 Aug 2016 18:40:55 +1000
>>> Alexey Kardashevskiy  wrote:
>>>   
 This exports helpers which are needed to keep a VFIO container in
 memory while there are external users such as KVM.

 Signed-off-by: Alexey Kardashevskiy 
 ---
  drivers/vfio/vfio.c | 30 ++
  drivers/vfio/vfio_iommu_spapr_tce.c | 16 +++-
  include/linux/vfio.h|  6 ++
  3 files changed, 51 insertions(+), 1 deletion(-)

 diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
 index d1d70e0..baf6a9c 100644
 --- a/drivers/vfio/vfio.c
 +++ b/drivers/vfio/vfio.c
 @@ -1729,6 +1729,36 @@ long vfio_external_check_extension(struct 
 vfio_group *group, unsigned long arg)
  EXPORT_SYMBOL_GPL(vfio_external_check_extension);
  
  /**
 + * External user API for containers, exported by symbols to be linked
 + * dynamically.
 + *
 + */
 +struct vfio_container *vfio_container_get_ext(struct file *filep)
 +{
 +  struct vfio_container *container = filep->private_data;
 +
 +  if (filep->f_op != _fops)
 +  return ERR_PTR(-EINVAL);
 +
 +  vfio_container_get(container);
 +
 +  return container;
 +}
 +EXPORT_SYMBOL_GPL(vfio_container_get_ext);
 +
 +void vfio_container_put_ext(struct vfio_container *container)
 +{
 +  vfio_container_put(container);
 +}
 +EXPORT_SYMBOL_GPL(vfio_container_put_ext);
 +
 +void *vfio_container_get_iommu_data_ext(struct vfio_container *container)
 +{
 +  return container->iommu_data;
 +}
 +EXPORT_SYMBOL_GPL(vfio_container_get_iommu_data_ext);
 +
 +/**
   * Sub-module support
   */
  /*
 diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c 
 b/drivers/vfio/vfio_iommu_spapr_tce.c
 index 3594ad3..fceea3d 100644
 --- a/drivers/vfio/vfio_iommu_spapr_tce.c
 +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
 @@ -1331,6 +1331,21 @@ const struct vfio_iommu_driver_ops 
 tce_iommu_driver_ops = {
.detach_group   = tce_iommu_detach_group,
  };
  
 +struct iommu_table *vfio_container_spapr_tce_table_get_ext(void 
 *iommu_data,
 +  u64 offset)
 +{
 +  struct tce_container *container = iommu_data;
 +  struct iommu_table *tbl = NULL;
 +
 +  if (tce_iommu_find_table(container, offset, ) < 0)
 +  return NULL;
 +
 +  iommu_table_get(tbl);
 +
 +  return tbl;
 +}
 +EXPORT_SYMBOL_GPL(vfio_container_spapr_tce_table_get_ext);
 +
  static int __init tce_iommu_init(void)
  {
return vfio_register_iommu_driver(_iommu_driver_ops);
 @@ -1348,4 +1363,3 @@ MODULE_VERSION(DRIVER_VERSION);
  MODULE_LICENSE("GPL v2");
  MODULE_AUTHOR(DRIVER_AUTHOR);
  MODULE_DESCRIPTION(DRIVER_DESC);
 -
 diff --git a/include/linux/vfio.h b/include/linux/vfio.h
 index 0ecae0b..1c2138a 100644
 --- a/include/linux/vfio.h
 +++ b/include/linux/vfio.h
 @@ -91,6 +91,12 @@ extern void vfio_group_put_external_user(struct 
 vfio_group *group);
  extern int vfio_external_user_iommu_id(struct vfio_group *group);
  extern long vfio_external_check_extension(struct vfio_group *group,
  unsigned long arg);
 +extern struct vfio_container *vfio_container_get_ext(struct file *filep);
 +extern void vfio_container_put_ext(struct vfio_container *container);
 +extern void *vfio_container_get_iommu_data_ext(
 +  struct vfio_container *container);
 +extern struct iommu_table *vfio_container_spapr_tce_table_get_ext(
 +  void *iommu_data, u64 offset);
  
  /*
   * Sub-module helpers  
>>>
>>>
>>> I think you need to take a closer look of the lifecycle of a container,
>>> having a reference means the container itself won't go away, but only
>>> having a group set within that container holds the actual IOMMU
>>> references.  container->iommu_data is going to be NULL once the
>>> groups are lost.  Thanks,  
>>
>>
>> Container owns the iommu tables and this is what I care about here, groups
>> attached or not - this is handled separately via IOMMU group list in a
>> specific iommu_table struct, these groups get detached from iommu_table
>> when they are removed from a container.
> 
> The container doesn't own anything, the container is privileged by the
> groups being attached to it.  When groups are closed, they detach from
> the container and once the container group list is empty the iommu
> backend is released and iommu_data is NULL.  A container reference
> doesn't give you what you're looking for.  It implies nothing about the
> iommu backend.

Re: 4.8.0-rc1: Invalid memory access at $SRR0: 0140f86c $SRR1: 00003030

[Christian Kujau]

On Wed, 10 Aug 2016, Michael Ellerman wrote:
> Benjamin Herrenschmidt  writes:
> > On Tue, 2016-08-09 at 02:06 -0700, Christian Kujau wrote:
> >> On Mon, 8 Aug 2016, Christian Kujau wrote:
> >> > 
> >> > while trying to upgrade this PowerBook G4 from 4.7-rc7 to 4.8-rc1,
> >> > it's 
> >> > unable to boot the Yaboot (v1.3.16 from Debian/stable) boot loader:
> >
> > There should already be a fix for that:
> >
> > http://patchwork.ozlabs.org/patch/654560/
> >
> > It should be in Michael's tree if not already in Linus.
> 
> That fix is in rc1, so this must be a different bug.

Does the git bisect help?

https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-August/147278.html

Thanks,
Christian.
-- 
BOFH excuse #8:

static buildup

Re: [PATCH] powerpc/Makefile: Use cflags-y/aflags-y for setting endian options

[Michael Ellerman]

Nicholas Piggin  writes:

> On Tue,  9 Aug 2016 22:43:46 +1000
> Michael Ellerman  wrote:
>> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
>> index ca254546cd05..1934707bf321 100644
>> --- a/arch/powerpc/Makefile
>> +++ b/arch/powerpc/Makefile
>> @@ -66,29 +66,28 @@ endif
>>  UTS_MACHINE := $(OLDARCH)
>>  
>>  ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
>> -override CC += -mlittle-endian
>> -ifneq ($(cc-name),clang)
>> -override CC += -mno-strict-align
>> -endif
>> -override AS += -mlittle-endian
>>  override LD += -EL
>> -override CROSS32CC += -mlittle-endian
>>  override CROSS32AS += -mlittle-endian
>
> Can't we get rid of CROSS32AS? If not, then should it get the
> -mbig-endian override?

It's unused. I have a patch to remove it lying around, let me dig up
that series.

cheers

Re: [PATCH 1/7] ima: on soft reboot, restore the measurement list

[Thiago Jung Bauermann]

Am Mittwoch, 10 August 2016, 13:41:08 schrieb Michael Ellerman:
> Thiago Jung Bauermann  writes:
> > Am Dienstag, 09 August 2016, 09:01:13 schrieb Mimi Zohar:
> >> On Tue, 2016-08-09 at 20:59 +1000, Michael Ellerman wrote:
> >> > Mimi Zohar  writes: 
> >> > > +/* Some details preceding the binary serialized measurement list
> >> > > */
> >> > > +struct ima_kexec_hdr {
> >> > > +  unsigned short version;
> >> > > +  unsigned long buffer_size;
> >> > > +  unsigned long count;
> >> > > +} __packed;
> >> > > +
> >> > 
> >> > Am I understanding it correctly that this structure is passed between
> >> > kernels?
> >> 
> >> Yes, the header prefixes the measurement list, which is being passed on
> >> the same computer to the next kernel.  Could the architecture (eg.
> >> LE/BE) change between soft re-boots?
> > 
> > Yes. I am able to boot a BE kernel from an LE kernel with my patches.
> > Whether we want to support that or not is another question...
> 
> Yes you must support that. BE -> LE and vice versa.

I didn't test BE - LE yet, but will do.

> You should also consider the possibility that the next kernel is not
> Linux.

If the next kernel is an ELF binary and it supports the kexec "calling 
convention", it should work too. What could possibly go wrong? I can try 
FreeBSD (I suppose it's an ELF kernel) and see what happens.

-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: 4.8.0-rc1: Invalid memory access at $SRR0: 0140f86c $SRR1: 00003030

[Michael Ellerman]

Benjamin Herrenschmidt  writes:

> On Tue, 2016-08-09 at 02:06 -0700, Christian Kujau wrote:
>> On Mon, 8 Aug 2016, Christian Kujau wrote:
>> > 
>> > while trying to upgrade this PowerBook G4 from 4.7-rc7 to 4.8-rc1,
>> > it's 
>> > unable to boot the Yaboot (v1.3.16 from Debian/stable) boot loader:
>
> There should already be a fix for that:
>
> http://patchwork.ozlabs.org/patch/654560/
>
> It should be in Michael's tree if not already in Linus.

That fix is in rc1, so this must be a different bug.

cheers

Re: [PATCH v2 2/2] powerpc: update pci_controller.refcount for PCI devices and buses

[Andrew Donnellan]

On 10/08/16 10:44, Mauricio Faria de Oliveira wrote:

This patch employs the refcount in struct pci_controller to track
the references from PCI devices and buses (struct pci_dev/pci_bus).

In order to do that without modifying any PCI scan/probe approach
(e.g., PCI_PROBE_DEVTREE and PCI_PROBE_NORMAL), it leverages some
of the PCI arch-specific callback: pci_(add|release)_device() and
pci_(add|remove)_bus().

(a small change is required for PCI_PROBE_DEVTREE, which makes it
consistent with PCI_PROBE_NORMAL - the pci_dev should inherit the
parent pci_bus's phb pointer - see pci_setup_device() in probe.c)

This also has the advantage that locking for kref_(get|put)() is
satisfied by the 'pci_rescan_remove_lock' mutex, which is normal
practice for usage of the PCI subsystem - thus already in place.
More details added in comment on pcibios_release_device().

Signed-off-by: Mauricio Faria de Oliveira 



 void pcibios_release_device(struct pci_dev *dev)
 {
struct pci_controller *phb = pci_bus_to_host(dev->bus);

+   pr_debug("PCI %s, pci_dev %p, phb %p\n", dev_name(>dev), dev, phb);
+
eeh_remove_device(dev);

if (phb->controller_ops.release_device)
phb->controller_ops.release_device(dev);
+
+   if (unlikely(!phb))
+   pr_warn("%s: PCI device %s has null PHB; refcount bug!",
+   __func__, dev_name(>dev)); /* WARN_ON ahead */


This should probably go before trying to dereference phb->controller_ops 
above?



--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

Re: [PATCH v3] powerpc: Do not make the entire heap executable

[Michael Ellerman]

Denys Vlasenko  writes:

> On 32-bit powerps the ELF PLT sections of binaries (built with --bss-plt,
> or with a toolchain which defaults to it) look like this:
...
>
>  arch/powerpc/include/asm/page.h| 10 +-
>  arch/powerpc/include/asm/page_32.h |  2 --
>  arch/powerpc/include/asm/page_64.h |  4 
>  fs/binfmt_elf.c| 34 ++
>  include/linux/mm.h |  1 +
>  mm/mmap.c  | 20 +++-
>  6 files changed, 43 insertions(+), 28 deletions(-)

What tree is this against?

I can't get it to apply to either Linus' tree or linux-next.

cheers

$ patch --dry-run -p1 < diff.diff
checking file arch/powerpc/include/asm/page.h
checking file arch/powerpc/include/asm/page_32.h
checking file arch/powerpc/include/asm/page_64.h
checking file fs/binfmt_elf.c
Hunk #3 FAILED at 613.
Hunk #4 FAILED at 633.
Hunk #5 succeeded at 681 (offset 2 lines).
Hunk #6 succeeded at 889 (offset 2 lines).
Hunk #7 succeeded at 984 (offset 2 lines).
Hunk #8 succeeded at 1003 (offset 2 lines).
2 out of 8 hunks FAILED
checking file include/linux/mm.h
checking file mm/mmap.c
Hunk #1 FAILED at 2653.
Hunk #2 succeeded at 2668 (offset 2 lines).
Hunk #3 succeeded at 2736 (offset 2 lines).
Hunk #4 succeeded at 2750 (offset 2 lines).
1 out of 4 hunks FAILED

Re: [PATCH] cpufreq: powernv: Fix crash in gpstate_timer_handler

[Michael Ellerman]

Viresh Kumar  writes:

> On 04-08-16, 20:59, Akshay Adiga wrote:
>> 'commit 09ca4c9b5958 ("cpufreq: powernv: Replacing pstate_id with
>> frequency table index")' changes calc_global_pstate() to use
>> cpufreq_table index instead of pstate_id.
>> 
>> But in gpstate_timer_handler() pstate_id was being passed instead
>> of cpufreq_table index, which caused the index_to_pstate() to access
>> out of bound indices, leading to this crash.
>> 
>> Adding sanity check for index and pstate, to ensure only valid pstate
>> and index values are returned.
>> 
>> Call Trace:
>> [c0078d66b130] [c011d224] __free_irq+0x234/0x360
>> (unreliable)
>> [c0078d66b1c0] [c011d44c] free_irq+0x6c/0xa0
>> [c0078d66b1f0] [c006c4f8] opal_event_shutdown+0x88/0xd0
>> [c0078d66b230] [c0067a4c] opal_shutdown+0x1c/0x90
>> [c0078d66b260] [c0063a00] pnv_shutdown+0x20/0x40
>> [c0078d66b280] [c0021538] machine_restart+0x38/0x90
>> [c78d66b310] [c0965ea0] panic+0x284/0x300
>> [c0078d66b3a0] [c001f508] die+0x388/0x450
>> [c0078d66b430] [c0045a50] bad_page_fault+0xd0/0x140
>> [c0078d66b4a0] [c0008964] handle_page_fault+0x2c/0x30
>>interrupt: 300 at gpstate_timer_handler+0x150/0x260
>> LR = gpstate_timer_handler+0x130/0x260
>> [c0078d66b7f0] [c0132b58] call_timer_fn+0x58/0x1c0
>> [c0078d66b880] [c0132e20] expire_timers+0x130/0x1d0
>> [c0078d66b8f0] [c0133068] run_timer_softirq+0x1a8/0x230
>> [c0078d66b980] [c00b535c] __do_softirq+0x18c/0x400
>> [c0078d66ba70] [c00b5828] irq_exit+0xc8/0x100
>> [c0078d66ba90] [c001e214] timer_interrupt+0xa4/0xe0
>> [c0078d66bac0] [c00027d0] decrementer_common+0x150/0x180
>>interrupt: 901 at arch_local_irq_restore+0x74/0x90
>>   0] [c0106b34] call_cpuidle+0x44/0x90
>> [c0078d66be50] [c010708c] cpu_startup_entry+0x38c/0x460
>> [c0078d66bf20] [c003d930] start_secondary+0x330/0x380
>> [c0078d66bf90] [c0008e6c] start_secondary_prolog+0x10/0x14
>> 
>> Fixes: 08d27eb ("cpufreq: powernv: Replacing pstate_id with
>> frequency table index")
>> Reported-by: Madhavan Srinivasan 
>> Signed-off-by: Akshay Adiga 
>> ---
>>  drivers/cpufreq/powernv-cpufreq.c | 21 -
>>  1 file changed, 20 insertions(+), 1 deletion(-)
>
> Acked-by: Viresh Kumar 

Who's merging this?

cheers

RE: [PATCH] i2c: don't print error when adding adapter fails

[Zhang, Sonic]

For i2c-bfin-twi.c

Acked-by: Sonic Zhang 


Sonic
-Original Message-
From: Neil Horman [mailto:nhor...@tuxdriver.com] 
Sent: Tuesday, August 09, 2016 8:55 PM
To: Wolfram Sang
Cc: linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; Jean Delvare; 
Wolfram Sang; Ludovic Desroches; Ray Jui; Scott Branden; Jon Mason; 
bcm-kernel-feedback-l...@broadcom.com; Florian Fainelli; Zhang, Sonic; Brian 
Norris; Gregory Fong; Michal Simek; Sören Brinkmann; Jochen Friedrich; Sekhar 
Nori; Kevin Hilman; Guenter Roeck; Uwe Kleine-König; Kukjin Kim; Krzysztof 
Kozlowski; Seth Heasley; Joachim Eastwood; Carlo Caione; Alessandro Rubini; 
Linus Walleij; Peter Korsgaard; Tony Lindgren; Vladimir Zapolskiy; Sylvain 
Lemieux; Guan Xuetao; Heiko Stuebner; Barry Song; Patrice Chotard; Laxman 
Dewangan; Stephen Warren; Thierry Reding; Alexandre Courbot; Masahiro Yamada; 
Tony Prisk; linux-arm-ker...@lists.infradead.org; 
adi-buildroot-de...@lists.sourceforge.net; linuxppc-dev@lists.ozlabs.org; 
linux-samsung-...@vger.kernel.org; linux-amlo...@lists.infradead.org; 
linux-o...@vger.kernel.org; linux-rockc...@lists.infradead.org; 
ker...@stlinux.com; linux-te...@vger.kernel.org
Subject: Re: [PATCH] i2c: don't print error when adding adapter fails

On Tue, Aug 09, 2016 at 01:36:17PM +0200, Wolfram Sang wrote:
> The core will do this for us now.
> 
> Signed-off-by: Wolfram Sang 
> ---
>  drivers/i2c/busses/i2c-amd756.c | 5 +
>  drivers/i2c/busses/i2c-at91.c   | 2 --
>  drivers/i2c/busses/i2c-axxia.c  | 8 +---
>  drivers/i2c/busses/i2c-bcm-iproc.c  | 8 +---
>  drivers/i2c/busses/i2c-bcm-kona.c   | 4 +---
>  drivers/i2c/busses/i2c-bfin-twi.c   | 4 +---
>  drivers/i2c/busses/i2c-brcmstb.c| 4 +---
>  drivers/i2c/busses/i2c-cadence.c| 4 +---
>  drivers/i2c/busses/i2c-cpm.c| 4 +---
>  drivers/i2c/busses/i2c-cros-ec-tunnel.c | 4 +---
>  drivers/i2c/busses/i2c-davinci.c| 4 +---
>  drivers/i2c/busses/i2c-diolan-u2c.c | 4 +---
>  drivers/i2c/busses/i2c-dln2.c   | 4 +---
>  drivers/i2c/busses/i2c-efm32.c  | 1 -
>  drivers/i2c/busses/i2c-exynos5.c| 4 +---
>  drivers/i2c/busses/i2c-hix5hd2.c| 4 +---
>  drivers/i2c/busses/i2c-i801.c   | 1 -
>  drivers/i2c/busses/i2c-ibm_iic.c| 4 +---
>  drivers/i2c/busses/i2c-img-scb.c| 4 +---
>  drivers/i2c/busses/i2c-imx.c| 4 +---
>  drivers/i2c/busses/i2c-isch.c   | 4 +---
>  drivers/i2c/busses/i2c-ismt.c   | 4 +---
>  drivers/i2c/busses/i2c-jz4780.c | 4 +---
>  drivers/i2c/busses/i2c-lpc2k.c  | 4 +---
>  drivers/i2c/busses/i2c-meson.c  | 1 -
>  drivers/i2c/busses/i2c-mpc.c| 4 +---
>  drivers/i2c/busses/i2c-mt65xx.c | 4 +---
>  drivers/i2c/busses/i2c-mxs.c| 1 -
>  drivers/i2c/busses/i2c-nforce2.c| 1 -
>  drivers/i2c/busses/i2c-nomadik.c| 4 +---
>  drivers/i2c/busses/i2c-ocores.c | 4 +---
>  drivers/i2c/busses/i2c-octeon.c | 4 +---
>  drivers/i2c/busses/i2c-omap.c   | 4 +---
>  drivers/i2c/busses/i2c-piix4.c  | 1 -
>  drivers/i2c/busses/i2c-pmcmsp.c | 4 +---
>  drivers/i2c/busses/i2c-pnx.c| 4 +---
>  drivers/i2c/busses/i2c-puv3.c   | 5 +
>  drivers/i2c/busses/i2c-pxa.c| 4 +---
>  drivers/i2c/busses/i2c-rcar.c   | 4 +---
>  drivers/i2c/busses/i2c-riic.c   | 4 +---
>  drivers/i2c/busses/i2c-rk3x.c   | 4 +---
>  drivers/i2c/busses/i2c-s3c2410.c| 1 -
>  drivers/i2c/busses/i2c-sh7760.c | 4 +---
>  drivers/i2c/busses/i2c-sh_mobile.c  | 1 -
>  drivers/i2c/busses/i2c-sirf.c   | 4 +---
>  drivers/i2c/busses/i2c-st.c | 4 +---
>  drivers/i2c/busses/i2c-stu300.c | 5 +
>  drivers/i2c/busses/i2c-tegra.c  | 4 +---
>  drivers/i2c/busses/i2c-uniphier-f.c | 7 +--
>  drivers/i2c/busses/i2c-uniphier.c   | 7 +--
>  drivers/i2c/busses/i2c-wmt.c| 4 +---
>  drivers/i2c/busses/i2c-xgene-slimpro.c  | 1 -
>  drivers/i2c/busses/i2c-xiic.c   | 1 -
>  drivers/i2c/busses/i2c-xlp9xx.c | 4 +---
>  drivers/i2c/busses/i2c-xlr.c| 4 +---
>  55 files changed, 44 insertions(+), 161 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-amd756.c 
> b/drivers/i2c/busses/i2c-amd756.c index 6c7113d990f882..274908cd1fdeab 
> 100644
> --- a/drivers/i2c/busses/i2c-amd756.c
> +++ b/drivers/i2c/busses/i2c-amd756.c
> @@ -378,11 +378,8 @@ static int amd756_probe(struct pci_dev *pdev, const 
> struct pci_device_id *id)
>amd756_ioport);
>  
>   error = i2c_add_adapter(_smbus);
> - if (error) {
> - dev_err(>dev,
> - "Adapter registration failed, module not inserted\n");
> + if (error)
>   goto out_err;
> - }
>  
>   return 0;
>  
> diff --git a/drivers/i2c/busses/i2c-at91.c 

Re: [PATCH 1/7] ima: on soft reboot, restore the measurement list

[Michael Ellerman]

Thiago Jung Bauermann  writes:

> Am Dienstag, 09 August 2016, 09:01:13 schrieb Mimi Zohar:
>> On Tue, 2016-08-09 at 20:59 +1000, Michael Ellerman wrote:
>> > Mimi Zohar  writes:
>> > > diff --git a/security/integrity/ima/ima.h
>> > > b/security/integrity/ima/ima.h
>> > > index b5728da..84e8d36 100644
>> > > --- a/security/integrity/ima/ima.h
>> > > +++ b/security/integrity/ima/ima.h
>> > > @@ -102,6 +102,13 @@ struct ima_queue_entry {
>> > > 
>> > >  };
>> > >  extern struct list_head ima_measurements;   /* list of all 
> measurements
>> > >  */
>> > > 
>> > > +/* Some details preceding the binary serialized measurement list */
>> > > +struct ima_kexec_hdr {
>> > > +unsigned short version;
>> > > +unsigned long buffer_size;
>> > > +unsigned long count;
>> > > +} __packed;
>> > > +
>> > 
>> > Am I understanding it correctly that this structure is passed between
>> > kernels?
>> Yes, the header prefixes the measurement list, which is being passed on
>> the same computer to the next kernel.  Could the architecture (eg.
>> LE/BE) change between soft re-boots?
>
> Yes. I am able to boot a BE kernel from an LE kernel with my patches. 
> Whether we want to support that or not is another question...

Yes you must support that. BE -> LE and vice versa.

You should also consider the possibility that the next kernel is not
Linux.

cheers

Re: [PATCH v2 1/2] powerpc: add refcount to struct pci_controller

[Andrew Donnellan]

On 10/08/16 10:44, Mauricio Faria de Oliveira wrote:

This commit introduces the 'refcount' field in struct pci_controller,
along with the corresponding functions 'controller_(get|put|free)()'.

The functions 'pcibios_(alloc|free)_controller()' are modified to use
that in a backwards compatible manner. (i.e., kfree(phb) is performed
when pcibios_free_controller() is called.)

So, this patch adds the infrastructure with no functional differences
to current users of pcibios_(alloc|free)_controller().  Notably, only
the pseries platform calls pcibios_free_controller() for some purpose
other than to release the pci_controller in case of errors just after
the call to pcibios_alloc_controller() (i.e., 'goto error' scenarios).


cxl's vPHB API also uses pcibios_free_controller() (which is why we 
export the symbol, as it's called from within the cxl module). When we 
remove/shutdown the underlying cxl device, we remove all the devices 
sitting on the vPHB and then free the vPHB.


I'm currently working on a cxl defect found by an IBM test team where we 
run into this - will review this patch more thoroughly and test it shortly.



Andrew

--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

Re: 4.8.0-rc1: Invalid memory access at $SRR0: 0140f86c $SRR1: 00003030

[Christian Kujau]

On Tue, 9 Aug 2016, Benjamin Herrenschmidt wrote:
> On Tue, 2016-08-09 at 02:06 -0700, Christian Kujau wrote:
> > On Mon, 8 Aug 2016, Christian Kujau wrote:
> > > 
> > > while trying to upgrade this PowerBook G4 from 4.7-rc7 to 4.8-rc1,
> > > it's 
> > > unable to boot the Yaboot (v1.3.16 from Debian/stable) boot loader:
> 
> There should already be a fix for that:
> http://patchwork.ozlabs.org/patch/654560/

2c0f99516f539 ("powerpc/32: Fix early access to cpu_spec relocation") is 
in mainline, but my machine is still unable to boot, same error, different 
address:

 > Invalid memory access at $SRR0: 0121686c $SRR1: 3030 

Happy to test more patches :-)

Christian.

> It should be in Michael's tree if not already in Linus.
> 
> Cheers,
> Ben.
> 
> > > 
> > > copying OF device tree...
> > > Building dt strings...
> > > Building dt stucture...
> > > Device tree strings 0x01e72000 -> 0x01e73615
> > > Device tree struct  0x01e74000 -> 0x01e7e000
> > > Quiescing Open Firmware...
> > > Bootng Linux via __start()...
> > > 
> > > Invalid memory access at $SRR0: 0140f86c  $SRR1: 3030
> > > 
> > > Apple PowerBook6,8 4.9.0f0 BootROM built on 01/10/05 at 10:39:14
> > > [...]
> > > 
> > >  ok
> > > 0:> _
> > > 
> > > 
> > > Going back to 4.7-rc7 (w/o installing Yaboot again) works just
> > > fine. The 
> > > config is mostly the same (used "make oldconfig" from 4.7), but
> > > I've said 
> > > YES to CONFIG_SLAB_FREELIST_RANDOM - could this be causing the
> > > boot 
> > > failure? Full .config and screen shot: http://nerdbynature.de/bits/
> > > 4.8.0-rc1/
> > 
> > A git-bisect led me to:
> > 
> > =
> > commit 9402c684613163888714df0955fa1f17142b08bf
> > Author: Benjamin Herrenschmidt 
> > Date:   Tue Jul 5 15:03:41 2016 +1000
> > 
> > powerpc: Factor do_feature_fixup calls
> > 
> > 32 and 64-bit do a similar set of calls early on, we move it all
> > to
> > a single common function to make the boot code more readable.
> > 
> > Signed-off-by: Benjamin Herrenschmidt 
> > Signed-off-by: Michael Ellerman 
> > =
> > 
> > But I'm unable to revert just this patch:
> > 
> > $ git revert 9402c684613163888714df0955fa1f17142b08bf
> > error: could not revert 9402c68... powerpc: Factor do_feature_fixup
> > calls
> > hint: after resolving the conflicts, mark the corrected paths
> > 
> > The bisect-log:
> > 
> > =
> > $ git bisect log
> > git bisect start '--' 'arch/powerpc'
> > # good: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
> > git bisect good 523d939ef98fd712632d93a5a2b588e477a7565e
> > # bad: [29b4817d4018df78086157ea3a55c1d9424a7cfc] Linux 4.8-rc1
> > git bisect bad 29b4817d4018df78086157ea3a55c1d9424a7cfc
> > # bad: [3808a88985b4f5f5e947c364debce4441a380fb8] powerpc: Move FW
> > feature probing out of pseries probe()
> > git bisect bad 3808a88985b4f5f5e947c364debce4441a380fb8
> > # good: [a203658b5ed37c11e5016d3fbbbab9ce018c1b78] powerpc/opal: Wake
> > up kopald polling thread before waiting for events
> > git bisect good a203658b5ed37c11e5016d3fbbbab9ce018c1b78
> > # good: [0dfffb48cecd8f84c6e649baee9bacd9be925734] powerpc/powernv:
> > abstraction for saving SPRs before entering deep idle states
> > git bisect good 0dfffb48cecd8f84c6e649baee9bacd9be925734
> > # good: [66c570f545e056babdd9510595ce762dcedadd71] powerpc/mm: use
> > _raw variant of page table accessors
> > git bisect good 66c570f545e056babdd9510595ce762dcedadd71
> > # good: [c2ca9f6b4cc4c45eb598b24b8b06beee668052d5] powerpc/powernv:
> > Fix pci-cxl.c build when CONFIG_MODULES=n
> > git bisect good c2ca9f6b4cc4c45eb598b24b8b06beee668052d5
> > # good: [4c91bd6eeabb004f283db8a6854b134e2a2de1bc] powerpc: Merge the
> > RELOCATABLE config entries for ppc32 and ppc64
> > git bisect good 4c91bd6eeabb004f283db8a6854b134e2a2de1bc
> > # bad: [c4bd6cb87c9e28a7d9f4a97db5a06cc538eb5e48] powerpc: Move 64-
> > bit feature fixup earlier
> > git bisect bad c4bd6cb87c9e28a7d9f4a97db5a06cc538eb5e48
> > # bad: [9402c684613163888714df0955fa1f17142b08bf] powerpc: Factor
> > do_feature_fixup calls
> > git bisect bad 9402c684613163888714df0955fa1f17142b08bf
> > # good: [27d1149667352772240655b65372a4294f992ea7] powerpc/32: Remove
> > RELOCATABLE_PPC32
> > git bisect good 27d1149667352772240655b65372a4294f992ea7
> > # first bad commit: [9402c684613163888714df0955fa1f17142b08bf]
> > powerpc: Factor do_feature_fixup calls
> > =
> > 
> > 
> > HTH,
> > Christian.
> 

-- 
BOFH excuse #62:

need to wrap system in aluminum foil to fix problem

Re: [PATCH v2 3/3] powerpc: Convert fsl_rstcr_restart to a reset handler

[Nicholas Piggin]

On Tue, 9 Aug 2016 11:47:37 -0700
Andrey Smirnov  wrote:

> On Sun, Jul 31, 2016 at 9:03 PM, Nicholas Piggin  wrote:
> > On Thu, 28 Jul 2016 16:07:18 -0700
> > Andrey Smirnov  wrote:
> >  
> >> Convert fsl_rstcr_restart into a function to be registered with
> >> register_reset_handler().
> >>
> >> Signed-off-by: Andrey Smirnov 
> >> ---
> >>
> >> Changes since v1:
> >>
> >>   - fsl_rstcr_restart is registered as a reset handler in
> >>   setup_rstcr, replacing per-board arch_initcall approach  
> >
> > Bear in mind I don't know much about the embedded or platform code!
> >
> > The documentation for reset notifiers says that they are expected
> > to be registered from drivers, not arch code. That seems to only be
> > intended to mean that the standard ISA or platform reset would
> > normally be handled directly by the arch, whereas if you have an
> > arch specific driver for a reset hardware that just happens to live
> > under arch/, then fsl_rstcr_restart / mpc85xx_cds_restart would be
> > valid use of reset notifier.  
> 
> Yeah, IMHO there's quite a bit of code in sysdev/ which in ideal world
> would go into drivers/ and I think fsl_rstcr_restart is among it
> (similar example on MIPS is drivers/power/reset/brcmstb-reboot.c).
> 
> >
> > So this change seems reasonable to me. One small question:
> >
> >  
> >> +static int mpc85xx_cds_restart_register(void)
> >> +{
> >> + static struct notifier_block restart_handler;
> >> +
> >> + restart_handler.notifier_call = mpc85xx_cds_restart;
> >> + restart_handler.priority = 192;  
> >
> > Should there be a header with #define's for these priorities?  
> 
> I don't have any strong preference either way, I do however think that
> introducing such #define should go into a separate patch-set, since
> you'd probably want to propagate that change across all of the users
> of the API.

You're probably right. I was thinking because powerpc has not used it
before we could use local defines, but it really does need a global
location.

Thanks,
Nick

Re: [PATCH v2 1/3] powerpc: Factor out common code in setup-common.c

[Nicholas Piggin]

On Tue, 9 Aug 2016 09:30:54 -0700
Andrey Smirnov  wrote:

> On Sun, Jul 31, 2016 at 8:40 PM, Nicholas Piggin  wrote:
> > On Thu, 28 Jul 2016 16:07:16 -0700
> > Andrey Smirnov  wrote:
> >  
> >> Factor out a small bit of common code in machine_restart(),
> >> machine_power_off() and machine_halt().
> >>
> >> Signed-off-by: Andrey Smirnov 
> >> ---
> >>
> >> No changes compared to v1.
> >>
> >>  arch/powerpc/kernel/setup-common.c | 23 ++-
> >>  1 file changed, 14 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/arch/powerpc/kernel/setup-common.c
> >> b/arch/powerpc/kernel/setup-common.c index 714b4ba..5cd3283 100644
> >> --- a/arch/powerpc/kernel/setup-common.c
> >> +++ b/arch/powerpc/kernel/setup-common.c
> >> @@ -130,15 +130,22 @@ void machine_shutdown(void)
> >>   ppc_md.machine_shutdown();
> >>  }
> >>
> >> +static void machine_hang(void)
> >> +{
> >> + pr_emerg("System Halted, OK to turn off power\n");
> >> + local_irq_disable();
> >> + while (1)
> >> + ;
> >> +}  
> >
> > What's the intended semantics of this function? A default power
> > off handler when the platform supplies none?  
> 
> I was mostly trying to avoid code duplication in
> machine_halt/machine_restart/machine_power_off and didn't intend that
> function to be used outside. The semantics is just - to hang the CPU
> when things didn't go as expected and code that was supposed to
> restart/halt/power off the machine failed.
> 
> > Would ppc_power_off()
> > be a good name?  
> 
> Calling it "power_off" seems a bit misleading, the function doesn't
> really try to do anything related to powering off, really.

Okay I don't feel too strongly against it.

Thanks,
Nick

[PATCH v2 2/2] powerpc: update pci_controller.refcount for PCI devices and buses

[Mauricio Faria de Oliveira]

This patch employs the refcount in struct pci_controller to track
the references from PCI devices and buses (struct pci_dev/pci_bus).

In order to do that without modifying any PCI scan/probe approach
(e.g., PCI_PROBE_DEVTREE and PCI_PROBE_NORMAL), it leverages some
of the PCI arch-specific callback: pci_(add|release)_device() and
pci_(add|remove)_bus().

(a small change is required for PCI_PROBE_DEVTREE, which makes it
consistent with PCI_PROBE_NORMAL - the pci_dev should inherit the
parent pci_bus's phb pointer - see pci_setup_device() in probe.c)

This also has the advantage that locking for kref_(get|put)() is
satisfied by the 'pci_rescan_remove_lock' mutex, which is normal
practice for usage of the PCI subsystem - thus already in place.
More details added in comment on pcibios_release_device().

Signed-off-by: Mauricio Faria de Oliveira 
---
 arch/powerpc/include/asm/pci-bridge.h |  4 ++--
 arch/powerpc/kernel/pci-common.c  | 25 +
 arch/powerpc/kernel/pci-hotplug.c | 29 +
 arch/powerpc/kernel/pci_of_scan.c |  1 +
 4 files changed, 57 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/pci-bridge.h 
b/arch/powerpc/include/asm/pci-bridge.h
index 6fde0a9..d10eee3 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -131,8 +131,8 @@ struct pci_controller {
 
/*
 * Reference counting for the structures:
-* - TODO pci_dev
-* - TODO pci_bus
+* - pci_dev
+* - pci_bus
 * - TODO pci_dn
 * - TODO eeh_pe
 * - TODO eeh_dev
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 29b37d3..c55e9c0 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1047,6 +1047,17 @@ static void pcibios_setup_device(struct pci_dev *dev)
 
 int pcibios_add_device(struct pci_dev *dev)
 {
+   struct pci_controller *phb = pci_bus_to_host(dev->bus);
+
+   pr_debug("PCI %s, pci_dev %p, phb %p\n", dev_name(>dev), dev, phb);
+
+   if (!phb)
+   pr_warn("%s: PCI device %s has null PHB; refcount bug!",
+   __func__, dev_name(>dev)); /* WARN_ON ahead */
+
+   /* locking: see comment on pcibios_release_device(). */
+   controller_get(phb);
+
/*
 * We can only call pcibios_setup_device() after bus setup is complete,
 * since some of the platform specific DMA setup code depends on it.
@@ -1062,6 +1073,20 @@ int pcibios_add_device(struct pci_dev *dev)
return 0;
 }
 
+void pcibios_add_bus(struct pci_bus *bus)
+{
+   struct pci_controller *phb = pci_bus_to_host(bus);
+
+   pr_debug("PCI %s, pci_bus %p, phb %p\n", dev_name(>dev), bus, phb);
+
+   if (!phb)
+   pr_warn("%s: PCI bus %s has null PHB; refcount bug!",
+   __func__, dev_name(>dev)); /* WARN_ON ahead */
+
+   /* locking: see comment on pcibios_release_device(). */
+   controller_get(phb);
+}
+
 void pcibios_setup_bus_devices(struct pci_bus *bus)
 {
struct pci_dev *dev;
diff --git a/arch/powerpc/kernel/pci-hotplug.c 
b/arch/powerpc/kernel/pci-hotplug.c
index 2d71269..24d1a2a 100644
--- a/arch/powerpc/kernel/pci-hotplug.c
+++ b/arch/powerpc/kernel/pci-hotplug.c
@@ -55,15 +55,44 @@ EXPORT_SYMBOL_GPL(pci_find_bus_by_node);
  * @dev: PCI device
  *
  * The function is called before releasing the indicated PCI device.
+ *
+ * The locking for kref_get() and kref_put() of the PHB/pci_controller
+ * in pcibios_(add|release)_device() and pcibios_(add|remove)_bus() is
+ * satisfied by the pci_rescan_remove_lock mutex (required for rescan/
+ * remove paths of PCI devices/buses; the scan path doesn't require it,
+ * as there is only addition of devices/buses - no removal at all.)
  */
 void pcibios_release_device(struct pci_dev *dev)
 {
struct pci_controller *phb = pci_bus_to_host(dev->bus);
 
+   pr_debug("PCI %s, pci_dev %p, phb %p\n", dev_name(>dev), dev, phb);
+
eeh_remove_device(dev);
 
if (phb->controller_ops.release_device)
phb->controller_ops.release_device(dev);
+
+   if (unlikely(!phb))
+   pr_warn("%s: PCI device %s has null PHB; refcount bug!",
+   __func__, dev_name(>dev)); /* WARN_ON ahead */
+
+   /* locking: see comment on pcibios_release_device(). */
+   controller_put(phb);
+}
+
+void pcibios_remove_bus(struct pci_bus *bus)
+{
+   struct pci_controller *phb = pci_bus_to_host(bus);
+
+   pr_debug("PCI %s, pci_bus %p, phb %p\n", dev_name(>dev), bus, phb);
+
+   if (unlikely(!phb))
+   pr_warn("%s: PCI bus %s has null PHB; refcount bug!",
+   __func__, dev_name(>dev)); /* WARN_ON ahead */
+
+   /* locking: see comment on pcibios_release_device(). */
+   controller_put(phb);
 }
 
 /**
diff --git 

[PATCH v2 1/2] powerpc: add refcount to struct pci_controller

[Mauricio Faria de Oliveira]

This commit introduces the 'refcount' field in struct pci_controller,
along with the corresponding functions 'controller_(get|put|free)()'.

The functions 'pcibios_(alloc|free)_controller()' are modified to use
that in a backwards compatible manner. (i.e., kfree(phb) is performed
when pcibios_free_controller() is called.)

So, this patch adds the infrastructure with no functional differences
to current users of pcibios_(alloc|free)_controller().  Notably, only
the pseries platform calls pcibios_free_controller() for some purpose
other than to release the pci_controller in case of errors just after
the call to pcibios_alloc_controller() (i.e., 'goto error' scenarios).

Signed-off-by: Mauricio Faria de Oliveira 
---
 arch/powerpc/include/asm/pci-bridge.h | 15 +++
 arch/powerpc/kernel/pci-common.c  | 47 ---
 2 files changed, 59 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/pci-bridge.h 
b/arch/powerpc/include/asm/pci-bridge.h
index b5e88e4..6fde0a9 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct device_node;
 
@@ -128,9 +129,23 @@ struct pci_controller {
struct pci_dn *pci_data;
 #endif /* CONFIG_PPC64 */
 
+   /*
+* Reference counting for the structures:
+* - TODO pci_dev
+* - TODO pci_bus
+* - TODO pci_dn
+* - TODO eeh_pe
+* - TODO eeh_dev
+*/
+   struct kref refcount;
+
void *private_data;
 };
 
+void controller_get(struct pci_controller *phb);
+void controller_put(struct pci_controller *phb);
+void controller_free(struct kref *kref);
+
 /* These are used for config access before all the PCI probing
has been done. */
 extern int early_read_config_byte(struct pci_controller *hose, int bus,
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 08afddf..29b37d3 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -114,6 +114,8 @@ struct pci_controller *pcibios_alloc_controller(struct 
device_node *dev)
phb = zalloc_maybe_bootmem(sizeof(struct pci_controller), GFP_KERNEL);
if (phb == NULL)
return NULL;
+
+   kref_init(>refcount); /* use first reference for hose_list entry */
spin_lock(_spinlock);
phb->global_number = get_phb_number(dev);
list_add_tail(>list_node, _list);
@@ -130,12 +132,53 @@ struct pci_controller *pcibios_alloc_controller(struct 
device_node *dev)
PHB_SET_NODE(phb, nid);
}
 #endif
+
+   pr_debug("PCI domain %d, phb %p, phb->is_dynamic %d\n",
+   phb->global_number, phb, phb->is_dynamic);
+
return phb;
 }
 EXPORT_SYMBOL_GPL(pcibios_alloc_controller);
 
+void controller_get(struct pci_controller *phb)
+{
+   if (unlikely(!phb)) {
+   pr_warn("%s: null PHB; refcount bug!\n", __func__);
+   WARN_ON(1);
+   } else {
+   pr_debug("PCI domain %d, phb %p\n", phb->global_number, phb);
+   kref_get(>refcount);
+   }
+}
+
+void controller_put(struct pci_controller *phb)
+{
+   if (unlikely(!phb)) {
+   pr_warn("%s: null PHB; refcount bug!\n", __func__);
+   WARN_ON(1);
+   } else {
+   pr_debug("PCI domain %d, phb %p\n", phb->global_number, phb);
+   kref_put(>refcount, controller_free);
+   }
+}
+
+void controller_free(struct kref *kref)
+{
+   struct pci_controller *phb = container_of(kref, struct pci_controller,
+   refcount);
+
+   pr_info("%s: PCI domain: %d, phb %p, phb->is_dynamic %d\n",
+   __func__, phb->global_number, phb, phb->is_dynamic);
+
+   if (phb->is_dynamic)
+   kfree(phb);
+}
+
 void pcibios_free_controller(struct pci_controller *phb)
 {
+   pr_debug("PCI domain %d, phb %p, phb->is_dynamic %d\n",
+   phb->global_number, phb, phb->is_dynamic);
+
spin_lock(_spinlock);
 
/* Clear bit of phb_bitmap to allow reuse of this PHB number. */
@@ -143,10 +186,8 @@ void pcibios_free_controller(struct pci_controller *phb)
clear_bit(phb->global_number, phb_bitmap);
 
list_del(>list_node);
+   controller_put(phb);
spin_unlock(_spinlock);
-
-   if (phb->is_dynamic)
-   kfree(phb);
 }
 EXPORT_SYMBOL_GPL(pcibios_free_controller);
 
-- 
1.8.3.1

[PATCH v2 0/2] powerpc: fix oops in pcibios_release_device() after pcibios_free_controller()

[Mauricio Faria de Oliveira]

This patchset addresses the problem/suggestion discussed previously [1],
by adding a kref reference counting to the PHB (struct pci_controller):

> It's possible to hit an oops/crash if pcibios_release_device() accesses the
> phb struct and it had been freed earlier -- by pcibios_free_controller() --
> as the memory it pointed to can be reused.

> If after reuse 'phb->controller_ops.release_device' is non-NULL it will be
> called, but it points to an invalid location (that function pointer is not
> set anywhere in the code, so if it's non-NULL, that's not correct), and so
> it hits an oops and the system crashes.

> That problem can happen with the pSeries platform's DLPAR remove operation
> if references to devices are held until after the pcibios_free_controller()
> function runs, and then released - exercising pcibios_release_device() path.

More problem details/call trace are described in the original submission [1].

With the patch applied (tested on 4.8-rc1), the test-case demonstrates that
the PHB is only released/freed after the last reference to the PCI device(s)
is dropped:

  Enable debugging messages:

  # echo 'file pci-common.c +pf; file pci-hotplug.c +pf' > 
/sys/kernel/debug/dynamic_debug/control
  # echo 8 > /proc/sys/kernel/printk

  Hold references to both PCI devices in the PHB:

  # ls -ld /sys/block/sd* | grep -m1 0021:01:00.0
  <...> /sys/block/sdaa -> ../devices/pci0021:01/0021:01:00.0/<...>
  
  # ls -ld /sys/block/sd* | grep -m1 0021:01:00.1
  <...> /sys/block/sdab -> ../devices/pci0021:01/0021:01:00.1/<...>
  
  # cat > /dev/sdaa & pid1=$!
  # cat > /dev/sdab & pid2=$!
  
  Perform DLPAR remove of the PHB:

  # drmgr -w 5 -d 1 -c phb -s 'PHB 33' -r
  Validating PHB DLPAR capability...yes.
  [  888.776964] pci_hp_remove_devices: PCI: Removing devices on bus 0021:01
  [  888.776983] pci_hp_remove_devices:Removing 0021:01:00.0...
  ...
  [  893.696431] pci_hp_remove_devices:Removing 0021:01:00.1...
  ...
  [  908.352717] pci_bus 0021:01: busn_res: [bus 01-ff] is released
  [  908.352744] pcibios_remove_bus: PCI 0021:01, pci_bus c001e7d59400, phb 
c001e7d57400
  [  908.352753] controller_put: PCI domain 33, phb c001e7d57400
  [  908.352811] pcibios_free_controller: PCI domain 33, phb c001e7d57400, 
phb->is_dynamic 1
  [  908.352820] controller_put: PCI domain 33, phb c001e7d57400
  [  908.352832] rpadlpar_io: slot PHB 33 removed
  
  Notice the PHB was not freed yet (controller_free() was not called)

  Drop the last references to the PCI devices:

  # kill -9 $pid1
  [  991.221998] pcibios_release_device: PCI 0021:01:00.0, pci_dev 
c001ee0b7000, phb c001e7d57400
  [  991.222005] controller_put: PCI domain 33, phb c001e7d57400
  
  # kill -9 $pid2
  [  996.076293] pcibios_release_device: PCI 0021:01:00.1, pci_dev 
c001ee0b3800, phb c001e7d57400
  [  996.076299] controller_put: PCI domain 33, phb c001e7d57400
  [  996.076303] controller_free: PCI domain: 33, phb c001e7d57400, 
phb->is_dynamic 1

  Notice that only now the PHB was freed.

Note: this patchset currently covers references from struct pci_dev/pci_bus,
which _is_ enough to resolve this particular problem; it does not yet cover
references from struct pci_dn/eeh_pe/eeh_dev (but since those are unchanged
by/unrelated to this patchset, they remain working in the very same manner).

I have gone to great lengths in time studying the relevant code for EEH in
order to implement those too, but am not yet sure of all the details (e.g.,
lifetime of eeh_dev, removal of pci_dn, etc) that need to be considered to
kfree() them - will likely ask Gavin & maintainers for RFC after some time.

Links:
  [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-July/145264.html 

Changelog:
  v2: change approach to use krefs (suggestion by benh & mpe).

Mauricio Faria de Oliveira (2):
  powerpc: add refcount to struct pci_controller
  powerpc: update pci_controller.refcount for PCI devices and buses

 arch/powerpc/include/asm/pci-bridge.h | 15 
 arch/powerpc/kernel/pci-common.c  | 72 +--
 arch/powerpc/kernel/pci-hotplug.c | 29 ++
 arch/powerpc/kernel/pci_of_scan.c |  1 +
 4 files changed, 114 insertions(+), 3 deletions(-)

-- 
1.8.3.1

Re: [PATCH 2/5] kbuild: allow archs to select build for link dead code/data elimination

[Andi Kleen]

On Wed, Aug 10, 2016 at 12:29:29AM +0200, Arnd Bergmann wrote:
> On Monday, August 8, 2016 8:16:05 PM CEST Andi Kleen wrote:
> > > I don't understand what led Andi Kleen to also move .text.hot and
> > > .text.unlikely together with .text [2], but this may have
> > > been a related issue.
> > >
> > > [2] https://lkml.org/lkml/2015/7/19/377
> >
> > The goal was just to move .hot and .unlikely all together, so that
> > they are clustered and use the minimum amount of cache. On x86 doesn't
> > matter where they are exactly, as long as each is together.
> > If they are not explicitely listed then the linker interleaves
> > them with the normal text, which defeats the purpose.
> 
> I still don't see it, my reading of your patch is that you did
> the opposite, by changing the description that puts all .text.hot
> in front of .text, and all .text.unlikely after exit.text into
> one that mixes them with .text. What am I missing here?

No it doesn't mix .unlikely with .text, .unlikely is all in one place.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only

[PATCH 6/6] cxlflash: Update documentation

[Matthew R. Ochs]

Update the block library link in the API documentation.

Signed-off-by: Matthew R. Ochs 
---
 Documentation/powerpc/cxlflash.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/powerpc/cxlflash.txt 
b/Documentation/powerpc/cxlflash.txt
index f4c1190..6d9a2ed 100644
--- a/Documentation/powerpc/cxlflash.txt
+++ b/Documentation/powerpc/cxlflash.txt
@@ -121,7 +121,7 @@ Block library API
 below.
 
 The block library can be found on GitHub:
-http://www.github.com/mikehollinger/ibmcapikv
+http://github.com/open-power/capiflash
 
 
 CXL Flash Driver IOCTLs
-- 
2.1.0

[PATCH 5/6] cxlflash: Remove adapter file descriptor cache

[Matthew R. Ochs]

The adapter file descriptor was previously cached within the kernel
for a given context in order to support performing a close on behalf
of an application. This is no longer needed as applications are now
required to perform a close on the adapter file descriptor.

Inspired-by: Al Viro 
Signed-off-by: Matthew R. Ochs 
---
 drivers/scsi/cxlflash/superpipe.c | 26 +-
 drivers/scsi/cxlflash/superpipe.h |  1 -
 2 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/scsi/cxlflash/superpipe.c 
b/drivers/scsi/cxlflash/superpipe.c
index b3bb90d..c91fe6f 100644
--- a/drivers/scsi/cxlflash/superpipe.c
+++ b/drivers/scsi/cxlflash/superpipe.c
@@ -788,20 +788,18 @@ err:
  * @cfg:   Internal structure associated with the host.
  * @ctx:   Previously obtained CXL context reference.
  * @ctxid: Previously obtained process element associated with CXL context.
- * @adap_fd:   Previously obtained adapter fd associated with CXL context.
  * @file:  Previously obtained file associated with CXL context.
  * @perms: User-specified permissions.
  */
 static void init_context(struct ctx_info *ctxi, struct cxlflash_cfg *cfg,
-struct cxl_context *ctx, int ctxid, int adap_fd,
-struct file *file, u32 perms)
+struct cxl_context *ctx, int ctxid, struct file *file,
+u32 perms)
 {
struct afu *afu = cfg->afu;
 
ctxi->rht_perms = perms;
ctxi->ctrl_map = >afu_map->ctrls[ctxid].ctrl;
ctxi->ctxid = ENCODE_CTXID(ctxi, ctxid);
-   ctxi->lfd = adap_fd;
ctxi->pid = current->tgid; /* tgid = pid */
ctxi->ctx = ctx;
ctxi->cfg = cfg;
@@ -1086,8 +1084,7 @@ static int cxlflash_mmap_fault(struct vm_area_struct 
*vma, struct vm_fault *vmf)
goto err;
}
 
-   dev_dbg(dev, "%s: fault(%d) for context %d\n",
-   __func__, ctxi->lfd, ctxid);
+   dev_dbg(dev, "%s: fault for context %d\n", __func__, ctxid);
 
if (likely(!ctxi->err_recovery_active)) {
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
@@ -1162,8 +1159,7 @@ static int cxlflash_cxl_mmap(struct file *file, struct 
vm_area_struct *vma)
goto out;
}
 
-   dev_dbg(dev, "%s: mmap(%d) for context %d\n",
-   __func__, ctxi->lfd, ctxid);
+   dev_dbg(dev, "%s: mmap for context %d\n", __func__, ctxid);
 
rc = cxl_fd_mmap(file, vma);
if (likely(!rc)) {
@@ -1406,7 +1402,7 @@ static int cxlflash_disk_attach(struct scsi_device *sdev,
perms = SISL_RHT_PERM(attach->hdr.flags + 1);
 
/* Context mutex is locked upon return */
-   init_context(ctxi, cfg, ctx, ctxid, fd, file, perms);
+   init_context(ctxi, cfg, ctx, ctxid, file, perms);
 
rc = afu_attach(cfg, ctxi);
if (unlikely(rc)) {
@@ -1488,12 +1484,15 @@ err:
  * recover_context() - recovers a context in error
  * @cfg:   Internal structure associated with the host.
  * @ctxi:  Context to release.
+ * @adap_fd:   Adapter file descriptor associated with new/recovered context.
  *
  * Restablishes the state for a context-in-error.
  *
  * Return: 0 on success, -errno on failure
  */
-static int recover_context(struct cxlflash_cfg *cfg, struct ctx_info *ctxi)
+static int recover_context(struct cxlflash_cfg *cfg,
+  struct ctx_info *ctxi,
+  int *adap_fd)
 {
struct device *dev = >dev->dev;
int rc = 0;
@@ -1546,7 +1545,6 @@ static int recover_context(struct cxlflash_cfg *cfg, 
struct ctx_info *ctxi)
 * visible to user space and can't be undone safely on this thread.
 */
ctxi->ctxid = ENCODE_CTXID(ctxi, ctxid);
-   ctxi->lfd = fd;
ctxi->ctx = ctx;
ctxi->file = file;
 
@@ -1563,6 +1561,7 @@ static int recover_context(struct cxlflash_cfg *cfg, 
struct ctx_info *ctxi)
cfg->ctx_tbl[ctxid] = ctxi;
mutex_unlock(>ctx_tbl_list_mutex);
fd_install(fd, file);
+   *adap_fd = fd;
 out:
dev_dbg(dev, "%s: returning ctxid=%d fd=%d rc=%d\n",
__func__, ctxid, fd, rc);
@@ -1621,6 +1620,7 @@ static int cxlflash_afu_recover(struct scsi_device *sdev,
rctxid = recover->context_id;
long reg;
int lretry = 20; /* up to 2 seconds */
+   int new_adap_fd = -1;
int rc = 0;
 
atomic_inc(>recovery_threads);
@@ -1650,7 +1650,7 @@ retry:
 
if (ctxi->err_recovery_active) {
 retry_recover:
-   rc = recover_context(cfg, ctxi);
+   rc = recover_context(cfg, ctxi, _adap_fd);
if (unlikely(rc)) {
dev_err(dev, "%s: Recovery failed for context %llu 
(rc=%d)\n",
__func__, ctxid, rc);
@@ -1672,7 +1672,7 @@ retry_recover:
 
ctxi->err_recovery_active 

[PATCH 4/6] cxlflash: Transition to application close model

[Matthew R. Ochs]

Caching the adapter file descriptor and performing a close on behalf
of an application is a poor design. This is due to the fact that once
a file descriptor in installed, it is free to be altered without the
knowledge of the cxlflash driver. This can lead to inconsistencies
between the application and kernel. Furthermore, the nature of the
former design is more exploitable and thus should be abandoned.

To support applications performing a close on the adapter file that
is associated with a context, a new flag is introduced to the user
API to indicate to applications that they are responsible for the
close following the cleanup (detach) of a context. The documentation
is also updated to reflect this change in behavior.

Inspired-by: Al Viro 
Signed-off-by: Matthew R. Ochs 
---
 Documentation/powerpc/cxlflash.txt | 42 +++---
 drivers/scsi/cxlflash/superpipe.c  | 71 ++
 drivers/scsi/cxlflash/vlun.c   | 13 ++-
 include/uapi/scsi/cxlflash_ioctl.h | 19 +++---
 4 files changed, 73 insertions(+), 72 deletions(-)

diff --git a/Documentation/powerpc/cxlflash.txt 
b/Documentation/powerpc/cxlflash.txt
index 4202d1b..f4c1190 100644
--- a/Documentation/powerpc/cxlflash.txt
+++ b/Documentation/powerpc/cxlflash.txt
@@ -171,11 +171,30 @@ DK_CXLFLASH_ATTACH
   destroyed, the tokens are to be considered stale and subsequent
   usage will result in errors.
 
+   - A valid adapter file descriptor (fd2 >= 0) is only returned on
+ the initial attach for a context. Subsequent attaches to an
+ existing context (DK_CXLFLASH_ATTACH_REUSE_CONTEXT flag present)
+ do not provide the adapter file descriptor as it was previously
+ made known to the application.
+
 - When a context is no longer needed, the user shall detach from
-  the context via the DK_CXLFLASH_DETACH ioctl.
+  the context via the DK_CXLFLASH_DETACH ioctl. When this ioctl
+ returns with a valid adapter file descriptor and the return flag
+ DK_CXLFLASH_APP_CLOSE_ADAP_FD is present, the application _must_
+ close the adapter file descriptor following a successful detach.
+
+   - When this ioctl returns with a valid fd2 and the return flag
+ DK_CXLFLASH_APP_CLOSE_ADAP_FD is present, the application _must_
+ close fd2 in the following circumstances:
+
+   + Following a successful detach of the last user of the context
+   + Following a successful recovery on the context's original fd2
+   + In the child process of a fork(), following a clone ioctl,
+ on the fd2 associated with the source context
 
-- A close on fd2 will invalidate the tokens. This operation is not
-  required by the user.
+- At any time, a close on fd2 will invalidate the tokens. Applications
+ should exercise caution to only close fd2 when appropriate (outlined
+ in the previous bullet) to avoid premature loss of I/O.
 
 DK_CXLFLASH_USER_DIRECT
 ---
@@ -254,6 +273,10 @@ DK_CXLFLASH_DETACH
 success, all "tokens" which had been provided to the user from the
 DK_CXLFLASH_ATTACH onward are no longer valid.
 
+When the DK_CXLFLASH_APP_CLOSE_ADAP_FD flag was returned on a successful
+attach, the application _must_ close the fd2 associated with the context
+following the detach of the final user of the context.
+
 DK_CXLFLASH_VLUN_CLONE
 --
 This ioctl is responsible for cloning a previously created
@@ -261,7 +284,7 @@ DK_CXLFLASH_VLUN_CLONE
 support maintaining user space access to storage after a process
 forks. Upon success, the child process (which invoked the ioctl)
 will have access to the same LUNs via the same resource handle(s)
-and fd2 as the parent, but under a different context.
+as the parent, but under a different context.
 
 Context sharing across processes is not supported with CXL and
 therefore each fork must be met with establishing a new context
@@ -275,6 +298,12 @@ DK_CXLFLASH_VLUN_CLONE
 translation tables are copied from the parent context to the child's
 and then synced with the AFU.
 
+When the DK_CXLFLASH_APP_CLOSE_ADAP_FD flag was returned on a successful
+attach, the application _must_ close the fd2 associated with the source
+context (still resident/accessible in the parent process) following the
+clone. This is to avoid a stale entry in the file descriptor table of the
+child process.
+
 DK_CXLFLASH_VERIFY
 --
 This ioctl is used to detect various changes such as the capacity of
@@ -309,6 +338,11 @@ DK_CXLFLASH_RECOVER_AFU
 at which time the context/resources they held will be freed as part of
 the release fop.
 
+When the DK_CXLFLASH_APP_CLOSE_ADAP_FD flag was returned on a successful
+attach, the 

[PATCH 3/6] cxlflash: Add kref to context

[Matthew R. Ochs]

Currently, context user references are tracked via the list of LUNs
that have attached to the context. While convenient, this is not
intuitive without a deep study of the code and is inconsistent with
the existing reference tracking patterns within the kernel. This design
choice can lead to future bug injection.

To improve code comprehension and better protect against future bugs, add
explicit reference counting to contexts and migrate the context removal
code to the kref release handler.

Inspired-by: Al Viro 
Signed-off-by: Matthew R. Ochs 
---
 drivers/scsi/cxlflash/superpipe.c | 87 +++
 drivers/scsi/cxlflash/superpipe.h |  1 +
 2 files changed, 53 insertions(+), 35 deletions(-)

diff --git a/drivers/scsi/cxlflash/superpipe.c 
b/drivers/scsi/cxlflash/superpipe.c
index 640c3a2..be7522a 100644
--- a/drivers/scsi/cxlflash/superpipe.c
+++ b/drivers/scsi/cxlflash/superpipe.c
@@ -808,11 +808,56 @@ static void init_context(struct ctx_info *ctxi, struct 
cxlflash_cfg *cfg,
ctxi->file = file;
ctxi->initialized = true;
mutex_init(>mutex);
+   kref_init(>kref);
INIT_LIST_HEAD(>luns);
INIT_LIST_HEAD(>list); /* initialize for list_empty() */
 }
 
 /**
+ * remove_context() - context kref release handler
+ * @kref:  Kernel reference associated with context to be removed.
+ *
+ * When a context no longer has any references it can safely be removed
+ * from global access and destroyed. Note that it is assumed the thread
+ * relinquishing access to the context holds its mutex.
+ */
+static void remove_context(struct kref *kref)
+{
+   struct ctx_info *ctxi = container_of(kref, struct ctx_info, kref);
+   struct cxlflash_cfg *cfg = ctxi->cfg;
+   int lfd;
+   u64 ctxid = DECODE_CTXID(ctxi->ctxid);
+
+   /* Remove context from table/error list */
+   WARN_ON(!mutex_is_locked(>mutex));
+   ctxi->unavail = true;
+   mutex_unlock(>mutex);
+   mutex_lock(>ctx_tbl_list_mutex);
+   mutex_lock(>mutex);
+
+   if (!list_empty(>list))
+   list_del(>list);
+   cfg->ctx_tbl[ctxid] = NULL;
+   mutex_unlock(>ctx_tbl_list_mutex);
+   mutex_unlock(>mutex);
+
+   /* Context now completely uncoupled/unreachable */
+   lfd = ctxi->lfd;
+   destroy_context(cfg, ctxi);
+
+   /*
+* As a last step, clean up external resources when not
+* already on an external cleanup thread, i.e.: close(adap_fd).
+*
+* NOTE: this will free up the context from the CXL services,
+* allowing it to dole out the same context_id on a future
+* (or even currently in-flight) disk_attach operation.
+*/
+   if (lfd != -1)
+   sys_close(lfd);
+}
+
+/**
  * _cxlflash_disk_detach() - detaches a LUN from a context
  * @sdev:  SCSI device associated with LUN.
  * @ctxi:  Context owning resources.
@@ -837,7 +882,6 @@ static int _cxlflash_disk_detach(struct scsi_device *sdev,
 
int i;
int rc = 0;
-   int lfd;
u64 ctxid = DECODE_CTXID(detach->context_id),
rctxid = detach->context_id;
 
@@ -879,40 +923,12 @@ static int _cxlflash_disk_detach(struct scsi_device *sdev,
break;
}
 
-   /* Tear down context following last LUN cleanup */
-   if (list_empty(>luns)) {
-   ctxi->unavail = true;
-   mutex_unlock(>mutex);
-   mutex_lock(>ctx_tbl_list_mutex);
-   mutex_lock(>mutex);
-
-   /* Might not have been in error list so conditionally remove */
-   if (!list_empty(>list))
-   list_del(>list);
-   cfg->ctx_tbl[ctxid] = NULL;
-   mutex_unlock(>ctx_tbl_list_mutex);
-   mutex_unlock(>mutex);
-
-   lfd = ctxi->lfd;
-   destroy_context(cfg, ctxi);
-   ctxi = NULL;
-   put_ctx = false;
-
-   /*
-* As a last step, clean up external resources when not
-* already on an external cleanup thread, i.e.: close(adap_fd).
-*
-* NOTE: this will free up the context from the CXL services,
-* allowing it to dole out the same context_id on a future
-* (or even currently in-flight) disk_attach operation.
-*/
-   if (lfd != -1)
-   sys_close(lfd);
-   }
-
-   /* Release the sdev reference that bound this LUN to the context */
+   /*
+* Release the context reference and the sdev reference that
+* bound this LUN to the context.
+*/
+   put_ctx = !kref_put(>kref, remove_context);
scsi_device_put(sdev);
-
 out:
if (put_ctx)
put_context(ctxi);
@@ -1369,10 +1385,11 @@ static int cxlflash_disk_attach(struct scsi_device 
*sdev,

[PATCH 2/6] cxlflash: Cache owning adapter within context

[Matthew R. Ochs]

The context removal routine requires access to the owning adapter
structure to reset the context within the AFU as part of the tear
down sequence. In order to support kref adoption, the owning adapter
must be accessible from the release handler. As the kref framework
only provides the kref reference as the sole parameter, another means
is needed to derive the owning adapter.

As a remedy, the owning adapter reference is saved off within the
context during initialization.

Signed-off-by: Matthew R. Ochs 
---
 drivers/scsi/cxlflash/superpipe.c | 1 +
 drivers/scsi/cxlflash/superpipe.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/scsi/cxlflash/superpipe.c 
b/drivers/scsi/cxlflash/superpipe.c
index ab5c893..640c3a2 100644
--- a/drivers/scsi/cxlflash/superpipe.c
+++ b/drivers/scsi/cxlflash/superpipe.c
@@ -804,6 +804,7 @@ static void init_context(struct ctx_info *ctxi, struct 
cxlflash_cfg *cfg,
ctxi->lfd = adap_fd;
ctxi->pid = current->tgid; /* tgid = pid */
ctxi->ctx = ctx;
+   ctxi->cfg = cfg;
ctxi->file = file;
ctxi->initialized = true;
mutex_init(>mutex);
diff --git a/drivers/scsi/cxlflash/superpipe.h 
b/drivers/scsi/cxlflash/superpipe.h
index 5f9a091..61404f2 100644
--- a/drivers/scsi/cxlflash/superpipe.h
+++ b/drivers/scsi/cxlflash/superpipe.h
@@ -107,6 +107,7 @@ struct ctx_info {
bool err_recovery_active;
struct mutex mutex; /* Context protection */
struct cxl_context *ctx;
+   struct cxlflash_cfg *cfg;
struct list_head luns;  /* LUNs attached to this context */
const struct vm_operations_struct *cxl_mmap_vmops;
struct file *file;
-- 
2.1.0

[PATCH 1/6] cxlflash: Avoid mutex when destroying context

[Matthew R. Ochs]

Context information structures are protected by a mutex that is held
when accessing/manipulating the context. When the code that manages
these structures was authored, a decision was made to include taking
the mutex as part of the allocation/initialization sequence and also
handle the scenario where the mutex was already held when freeing the
context.

While not a problem outright, this design decision has been deemed as
too flexible and the code should be made more rigid to avoid future bugs.
In addition, further review of the code yields that the existing mutex
manipulations in both of these context management paths are superfluous.

This commit removes the obtaining of the context mutex in the context
initialization routine and assumes the mutex is not held in the context
free path.

Inspired-by: Al Viro 
Signed-off-by: Matthew R. Ochs 
---
 drivers/scsi/cxlflash/superpipe.c | 26 --
 1 file changed, 8 insertions(+), 18 deletions(-)

diff --git a/drivers/scsi/cxlflash/superpipe.c 
b/drivers/scsi/cxlflash/superpipe.c
index ce15070..ab5c893 100644
--- a/drivers/scsi/cxlflash/superpipe.c
+++ b/drivers/scsi/cxlflash/superpipe.c
@@ -709,14 +709,13 @@ int cxlflash_disk_release(struct scsi_device *sdev,
  * @cfg:   Internal structure associated with the host.
  * @ctxi:  Context to release.
  *
- * This routine is safe to be called with a a non-initialized context
- * and is tolerant of being called with the context's mutex held (it
- * will be unlocked if necessary before freeing). Also note that the
- * routine conditionally checks for the existence of the context control
- * map before clearing the RHT registers and context capabilities because
- * it is possible to destroy a context while the context is in the error
- * state (previous mapping was removed [so there is no need to worry about
- * clearing] and context is waiting for a new mapping).
+ * This routine is safe to be called with a a non-initialized context.
+ * Also note that the routine conditionally checks for the existence
+ * of the context control map before clearing the RHT registers and
+ * context capabilities because it is possible to destroy a context
+ * while the context is in the error state (previous mapping was
+ * removed [so there is no need to worry about clearing] and context
+ * is waiting for a new mapping).
  */
 static void destroy_context(struct cxlflash_cfg *cfg,
struct ctx_info *ctxi)
@@ -732,9 +731,6 @@ static void destroy_context(struct cxlflash_cfg *cfg,
writeq_be(0, >ctrl_map->rht_cnt_id);
writeq_be(0, >ctrl_map->ctx_cap);
}
-
-   if (mutex_is_locked(>mutex))
-   mutex_unlock(>mutex);
}
 
/* Free memory associated with context */
@@ -795,9 +791,6 @@ err:
  * @adap_fd:   Previously obtained adapter fd associated with CXL context.
  * @file:  Previously obtained file associated with CXL context.
  * @perms: User-specified permissions.
- *
- * Upon return, the context is marked as initialized and the context's mutex
- * is locked.
  */
 static void init_context(struct ctx_info *ctxi, struct cxlflash_cfg *cfg,
 struct cxl_context *ctx, int ctxid, int adap_fd,
@@ -816,8 +809,6 @@ static void init_context(struct ctx_info *ctxi, struct 
cxlflash_cfg *cfg,
mutex_init(>mutex);
INIT_LIST_HEAD(>luns);
INIT_LIST_HEAD(>list); /* initialize for list_empty() */
-
-   mutex_lock(>mutex);
 }
 
 /**
@@ -1445,7 +1436,6 @@ static int cxlflash_disk_attach(struct scsi_device *sdev,
 * knows about us yet; we can be the only one holding our mutex.
 */
list_add(_access->list, >luns);
-   mutex_unlock(>mutex);
mutex_lock(>ctx_tbl_list_mutex);
mutex_lock(>mutex);
cfg->ctx_tbl[ctxid] = ctxi;
@@ -1494,7 +1484,7 @@ err:
file = NULL;
}
 
-   /* Cleanup our context; safe to call even with mutex locked */
+   /* Cleanup our context */
if (ctxi) {
destroy_context(cfg, ctxi);
ctxi = NULL;
-- 
2.1.0

[PATCH 0/6] cxlflash: Improvements and cleanup

[Matthew R. Ochs]

This patch set contains various code improvements and cleanups that
were inspired by Al Viro upon reviewing the cxlflash driver. The core
improvement is that the driver will no longer cache the adapter file
descriptor associated with a context. This results in a user API change
that is documented alongside the modifications.

The series is based upon 4.8-rc1, intended for 4.9, and is bisectable.

Matthew R. Ochs (6):
  cxlflash: Avoid mutex when destroying context
  cxlflash: Cache owning adapter within context
  cxlflash: Add kref to context
  cxlflash: Transition to application close model
  cxlflash: Remove adapter file descriptor cache
  cxlflash: Update documentation

 Documentation/powerpc/cxlflash.txt |  44 -
 drivers/scsi/cxlflash/superpipe.c  | 181 -
 drivers/scsi/cxlflash/superpipe.h  |   3 +-
 drivers/scsi/cxlflash/vlun.c   |  13 +--
 include/uapi/scsi/cxlflash_ioctl.h |  19 +++-
 5 files changed, 135 insertions(+), 125 deletions(-)

-- 
2.1.0

Re: [PATCH 1/7] ima: on soft reboot, restore the measurement list

[Samuel Mendoza-Jonas]

On Tue, 2016-08-09 at 10:19 -0300, Thiago Jung Bauermann wrote:
> Am Dienstag, 09 August 2016, 09:01:13 schrieb Mimi Zohar:
> > 
> > On Tue, 2016-08-09 at 20:59 +1000, Michael Ellerman wrote:
> > > 
> > > Mimi Zohar  writes:
> > > > 
> > > > diff --git a/security/integrity/ima/ima.h
> > > > b/security/integrity/ima/ima.h
> > > > index b5728da..84e8d36 100644
> > > > --- a/security/integrity/ima/ima.h
> > > > +++ b/security/integrity/ima/ima.h
> > > > @@ -102,6 +102,13 @@ struct ima_queue_entry {
> > > > 
> > > >  };
> > > >  extern struct list_head ima_measurements;  /* list of all 
> measurements
> > 
> > > 
> > > > 
> > > >  */
> > > > 
> > > > +/* Some details preceding the binary serialized measurement list */
> > > > +struct ima_kexec_hdr {
> > > > +   unsigned short version;
> > > > +   unsigned long buffer_size;
> > > > +   unsigned long count;
> > > > +} __packed;
> > > > +
> > > 
> > > Am I understanding it correctly that this structure is passed between
> > > kernels?
> > Yes, the header prefixes the measurement list, which is being passed on
> > the same computer to the next kernel.  Could the architecture (eg.
> > LE/BE) change between soft re-boots?
> 
> Yes. I am able to boot a BE kernel from an LE kernel with my patches. 
> Whether we want to support that or not is another question...

The answer to that question is almost certainly yes - on POWER the most
immediate example would be soft-rebooting from a BE host into an LE
Petitboot kernel, or vice versa.

Re: [PATCH 2/5] kbuild: allow archs to select build for link dead code/data elimination

[Andi Kleen]

On Wed, Aug 10, 2016 at 12:29:29AM +0200, Arnd Bergmann wrote:
> On Monday, August 8, 2016 8:16:05 PM CEST Andi Kleen wrote:
> > > I don't understand what led Andi Kleen to also move .text.hot and
> > > .text.unlikely together with .text [2], but this may have
> > > been a related issue.
> > >
> > > [2] https://lkml.org/lkml/2015/7/19/377
> >
> > The goal was just to move .hot and .unlikely all together, so that
> > they are clustered and use the minimum amount of cache. On x86 doesn't
> > matter where they are exactly, as long as each is together.
> > If they are not explicitely listed then the linker interleaves
> > them with the normal text, which defeats the purpose.
> 
> I still don't see it, my reading of your patch is that you did
> the opposite, by changing the description that puts all .text.hot
> in front of .text, and all .text.unlikely after exit.text into
> one that mixes them with .text. What am I missing here?

.text.hot is actually not used, the critical part is .text.unlikely
which was not listed and was interleaved before the patch.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only

Re: [PATCH v3] powerpc: Do not make the entire heap executable

[Kees Cook]

On Tue, Aug 9, 2016 at 12:08 PM, Denys Vlasenko  wrote:
> On 32-bit powerps the ELF PLT sections of binaries (built with --bss-plt,

Typo: powerps -> powerpc

> or with a toolchain which defaults to it) look like this:
>
>   [17] .sbss NOBITS  0002aff8 01aff8 14 00  WA  0   0 
>  4
>   [18] .plt  NOBITS  0002b00c 01aff8 84 00 WAX  0   0 
>  4
>   [19] .bss  NOBITS  0002b090 01aff8 a4 00  WA  0   0 
>  4
>
> Which results in an ELF load header:
>
>   Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD   0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x1
>
> This is all correct, the load region containing the PLT is marked as
> executable. Note that the PLT starts at 0002b00c but the file mapping ends at
> 0002aff8, so the PLT falls in the 0 fill section described by the load header,
> and after a page boundary.
>
> Unfortunately the generic ELF loader ignores the X bit in the load headers
> when it creates the 0 filled non-file backed mappings. It assumes all of these
> mappings are RW BSS sections, which is not the case for PPC.
>
> gcc/ld has an option (--secure-plt) to not do this, this is said to incur
> a small performance penalty.
>
> Currently, to support 32-bit binaries with PLT in BSS kernel maps *entire
> brk area* with executable rights for all binaries, even --secure-plt ones.
>
> Stop doing that.
>
> Teach the ELF loader to check the X bit in the relevant load header
> and create 0 filled anonymous mappings that are executable
> if the load header requests that.
>
> The patch was originally posted in 2012 by Jason Gunthorpe
> and apparently ignored:
>
> https://lkml.org/lkml/2012/9/30/138
>
> Lightly run-tested.
>
> Signed-off-by: Jason Gunthorpe 
> Signed-off-by: Denys Vlasenko 
> CC: Benjamin Herrenschmidt 
> CC: Paul Mackerras 
> CC: Kees Cook 
> CC: Oleg Nesterov 
> CC: Michael Ellerman 
> CC: Florian Weimer 
> CC: linux...@kvack.org
> CC: linuxppc-dev@lists.ozlabs.org
> CC: linux-ker...@vger.kernel.org
> ---
> Changes since v2:
> * moved capability to map with VM_EXEC into vm_brk_flags()
>
> Changes since v1:
> * wrapped lines to not exceed 79 chars
> * improved comment
> * expanded CC list
>
>  arch/powerpc/include/asm/page.h| 10 +-
>  arch/powerpc/include/asm/page_32.h |  2 --
>  arch/powerpc/include/asm/page_64.h |  4 
>  fs/binfmt_elf.c| 34 ++
>  include/linux/mm.h |  1 +
>  mm/mmap.c  | 20 +++-
>  6 files changed, 43 insertions(+), 28 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index 56398e7..42d7ea1 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -225,15 +225,7 @@ extern long long virt_phys_offset;
>  #endif
>  #endif
>
> -/*
> - * Unfortunately the PLT is in the BSS in the PPC32 ELF ABI,
> - * and needs to be executable.  This means the whole heap ends
> - * up being executable.
> - */
> -#define VM_DATA_DEFAULT_FLAGS32(VM_READ | VM_WRITE | VM_EXEC | \
> -VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
> -
> -#define VM_DATA_DEFAULT_FLAGS64(VM_READ | VM_WRITE | \
> +#define VM_DATA_DEFAULT_FLAGS  (VM_READ | VM_WRITE | \
>  VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
>
>  #ifdef __powerpc64__
> diff --git a/arch/powerpc/include/asm/page_32.h 
> b/arch/powerpc/include/asm/page_32.h
> index 6a8e179..6113fa8 100644
> --- a/arch/powerpc/include/asm/page_32.h
> +++ b/arch/powerpc/include/asm/page_32.h
> @@ -9,8 +9,6 @@
>  #endif
>  #endif
>
> -#define VM_DATA_DEFAULT_FLAGS  VM_DATA_DEFAULT_FLAGS32
> -
>  #ifdef CONFIG_NOT_COHERENT_CACHE
>  #define ARCH_DMA_MINALIGN  L1_CACHE_BYTES
>  #endif
> diff --git a/arch/powerpc/include/asm/page_64.h 
> b/arch/powerpc/include/asm/page_64.h
> index dd5f071..52d8e9c 100644
> --- a/arch/powerpc/include/asm/page_64.h
> +++ b/arch/powerpc/include/asm/page_64.h
> @@ -159,10 +159,6 @@ do {   \
>
>  #endif /* !CONFIG_HUGETLB_PAGE */
>
> -#define VM_DATA_DEFAULT_FLAGS \
> -   (is_32bit_task() ? \
> -VM_DATA_DEFAULT_FLAGS32 : VM_DATA_DEFAULT_FLAGS64)
> -
>  /*
>   * This is the default if a program doesn't have a PT_GNU_STACK
>   * program header entry. The PPC64 ELF ABI has a non executable stack
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index a7a28110..d4a1966 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -91,12 +91,18 @@ static struct linux_binfmt elf_format = {
>
>  #define BAD_ADDR(x) ((unsigned long)(x) >= TASK_SIZE)
>
> -static int set_brk(unsigned long start, unsigned long 

Re: [PATCH 2/5] kbuild: allow archs to select build for link dead code/data elimination

[Arnd Bergmann]

On Monday, August 8, 2016 8:16:05 PM CEST Andi Kleen wrote:
> > I don't understand what led Andi Kleen to also move .text.hot and
> > .text.unlikely together with .text [2], but this may have
> > been a related issue.
> >
> > [2] https://lkml.org/lkml/2015/7/19/377
>
> The goal was just to move .hot and .unlikely all together, so that
> they are clustered and use the minimum amount of cache. On x86 doesn't
> matter where they are exactly, as long as each is together.
> If they are not explicitely listed then the linker interleaves
> them with the normal text, which defeats the purpose.

I still don't see it, my reading of your patch is that you did
the opposite, by changing the description that puts all .text.hot
in front of .text, and all .text.unlikely after exit.text into
one that mixes them with .text. What am I missing here?

Arnd

Re: [PATCH 2/5] kbuild: allow archs to select build for link dead code/data elimination

[Arnd Bergmann]

On Tuesday, August 9, 2016 9:20:16 AM CEST Alan Modra wrote:
> On Mon, Aug 08, 2016 at 05:14:27PM +0200, Arnd Bergmann wrote:
> > I have reverted that patch now, so ARM uses ".fixup" again like every
> > other architecture does, and now "*(.fixup) *(.text .text.*)" works
> > correctly, while ""*(.fixup) *(.text .fixup .text.*)" also fails
> > the same way that I saw before:
> 
> That is really odd.  The linker isn't supposed to treat those script
> snippets differently.  First match for .fixup wins.

Sorry for my mistake. I checked again and cannot reproduce what I
thought I saw earlier. "*(.fixup) *(.text .text.*)" fails
as would be expected.

Arnd

Re: [PATCH] i2c: don't print error when adding adapter fails

[Joachim Eastwood]

On 9 August 2016 at 13:36, Wolfram Sang  wrote:
> Since v4.8-rc1, the I2C core will print detailed information when adding an 
> I2C
> adapter fails. So, drivers can skip this now.
>
> I am still undecided if I apply this as a single patch or break it out. But 
> for
> reviewing, avoiding the patch bomb is probably a good thing.
>
> Should go via subsystem tree, I'd think.
>
> Wolfram Sang (1):
>   i2c: don't print error when adding adapter fails


For
>  drivers/i2c/busses/i2c-lpc2k.c  | 4 +---

Acked-by: Joachim Eastwood 


regards,
Joachim Eastwood

Re: [PATCH] i2c: don't print error when adding adapter fails

[Ray Jui]

Hi Wolfram,

On 8/9/2016 4:36 AM, Wolfram Sang wrote:

The core will do this for us now.

Signed-off-by: Wolfram Sang 


[...]


diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c 
b/drivers/i2c/busses/i2c-bcm-iproc.c
index 19c843828fe2ca..8e3477f9297eda 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -488,13 +488,7 @@ static int bcm_iproc_i2c_probe(struct platform_device 
*pdev)
adap->dev.parent = >dev;
adap->dev.of_node = pdev->dev.of_node;

-   ret = i2c_add_adapter(adap);
-   if (ret) {
-   dev_err(iproc_i2c->device, "failed to add adapter\n");
-   return ret;
-   }
-
-   return 0;
+   return i2c_add_adapter(adap);
 }

 static int bcm_iproc_i2c_remove(struct platform_device *pdev)
diff --git a/drivers/i2c/busses/i2c-bcm-kona.c 
b/drivers/i2c/busses/i2c-bcm-kona.c
index ac9f47679c3a4b..a5c9098507896b 100644
--- a/drivers/i2c/busses/i2c-bcm-kona.c
+++ b/drivers/i2c/busses/i2c-bcm-kona.c
@@ -858,10 +858,8 @@ static int bcm_kona_i2c_probe(struct platform_device *pdev)
adap->dev.of_node = pdev->dev.of_node;

rc = i2c_add_adapter(adap);
-   if (rc) {
-   dev_err(dev->device, "failed to add adapter\n");
+   if (rc)
return rc;
-   }

dev_info(dev->device, "device registered successfully\n");



For both i2c-bcm-iproc.c and i2c-bcm-kona.c:

Acked-by: Ray Jui 

Thanks,

Ray

[PATCH v3] powerpc: Do not make the entire heap executable

[Denys Vlasenko]

On 32-bit powerps the ELF PLT sections of binaries (built with --bss-plt,
or with a toolchain which defaults to it) look like this:

  [17] .sbss NOBITS  0002aff8 01aff8 14 00  WA  0   0  4
  [18] .plt  NOBITS  0002b00c 01aff8 84 00 WAX  0   0  4
  [19] .bss  NOBITS  0002b090 01aff8 a4 00  WA  0   0  4

Which results in an ELF load header:

  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD   0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x1

This is all correct, the load region containing the PLT is marked as
executable. Note that the PLT starts at 0002b00c but the file mapping ends at
0002aff8, so the PLT falls in the 0 fill section described by the load header,
and after a page boundary.

Unfortunately the generic ELF loader ignores the X bit in the load headers
when it creates the 0 filled non-file backed mappings. It assumes all of these
mappings are RW BSS sections, which is not the case for PPC.

gcc/ld has an option (--secure-plt) to not do this, this is said to incur
a small performance penalty.

Currently, to support 32-bit binaries with PLT in BSS kernel maps *entire
brk area* with executable rights for all binaries, even --secure-plt ones.

Stop doing that.

Teach the ELF loader to check the X bit in the relevant load header
and create 0 filled anonymous mappings that are executable
if the load header requests that.

The patch was originally posted in 2012 by Jason Gunthorpe
and apparently ignored:

https://lkml.org/lkml/2012/9/30/138

Lightly run-tested.

Signed-off-by: Jason Gunthorpe 
Signed-off-by: Denys Vlasenko 
CC: Benjamin Herrenschmidt 
CC: Paul Mackerras 
CC: Kees Cook 
CC: Oleg Nesterov 
CC: Michael Ellerman 
CC: Florian Weimer 
CC: linux...@kvack.org
CC: linuxppc-dev@lists.ozlabs.org
CC: linux-ker...@vger.kernel.org
---
Changes since v2:
* moved capability to map with VM_EXEC into vm_brk_flags()

Changes since v1:
* wrapped lines to not exceed 79 chars
* improved comment
* expanded CC list

 arch/powerpc/include/asm/page.h| 10 +-
 arch/powerpc/include/asm/page_32.h |  2 --
 arch/powerpc/include/asm/page_64.h |  4 
 fs/binfmt_elf.c| 34 ++
 include/linux/mm.h |  1 +
 mm/mmap.c  | 20 +++-
 6 files changed, 43 insertions(+), 28 deletions(-)

diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 56398e7..42d7ea1 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -225,15 +225,7 @@ extern long long virt_phys_offset;
 #endif
 #endif
 
-/*
- * Unfortunately the PLT is in the BSS in the PPC32 ELF ABI,
- * and needs to be executable.  This means the whole heap ends
- * up being executable.
- */
-#define VM_DATA_DEFAULT_FLAGS32(VM_READ | VM_WRITE | VM_EXEC | \
-VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
-
-#define VM_DATA_DEFAULT_FLAGS64(VM_READ | VM_WRITE | \
+#define VM_DATA_DEFAULT_FLAGS  (VM_READ | VM_WRITE | \
 VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
 
 #ifdef __powerpc64__
diff --git a/arch/powerpc/include/asm/page_32.h 
b/arch/powerpc/include/asm/page_32.h
index 6a8e179..6113fa8 100644
--- a/arch/powerpc/include/asm/page_32.h
+++ b/arch/powerpc/include/asm/page_32.h
@@ -9,8 +9,6 @@
 #endif
 #endif
 
-#define VM_DATA_DEFAULT_FLAGS  VM_DATA_DEFAULT_FLAGS32
-
 #ifdef CONFIG_NOT_COHERENT_CACHE
 #define ARCH_DMA_MINALIGN  L1_CACHE_BYTES
 #endif
diff --git a/arch/powerpc/include/asm/page_64.h 
b/arch/powerpc/include/asm/page_64.h
index dd5f071..52d8e9c 100644
--- a/arch/powerpc/include/asm/page_64.h
+++ b/arch/powerpc/include/asm/page_64.h
@@ -159,10 +159,6 @@ do {   \
 
 #endif /* !CONFIG_HUGETLB_PAGE */
 
-#define VM_DATA_DEFAULT_FLAGS \
-   (is_32bit_task() ? \
-VM_DATA_DEFAULT_FLAGS32 : VM_DATA_DEFAULT_FLAGS64)
-
 /*
  * This is the default if a program doesn't have a PT_GNU_STACK
  * program header entry. The PPC64 ELF ABI has a non executable stack
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index a7a28110..d4a1966 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -91,12 +91,18 @@ static struct linux_binfmt elf_format = {
 
 #define BAD_ADDR(x) ((unsigned long)(x) >= TASK_SIZE)
 
-static int set_brk(unsigned long start, unsigned long end)
+static int set_brk(unsigned long start, unsigned long end, int prot)
 {
start = ELF_PAGEALIGN(start);
end = ELF_PAGEALIGN(end);
if (end > start) {
-   int error = vm_brk(start, end - start);
+   /*
+* Map the last of the bss segment.
+* If the header is 

Re: [PATCH v2] powerpc: Do not make the entire heap executable

[Denys Vlasenko]

On 08/08/2016 09:07 PM, Kees Cook wrote:

On Mon, Aug 8, 2016 at 7:55 AM, Denys Vlasenko  wrote:

On 32-bit powerps the ELF PLT sections of binaries (built with --bss-plt,
or with a toolchain which defaults to it) look like this:

  [17] .sbss NOBITS  0002aff8 01aff8 14 00  WA  0   0  4
  [18] .plt  NOBITS  0002b00c 01aff8 84 00 WAX  0   0  4
  [19] .bss  NOBITS  0002b090 01aff8 a4 00  WA  0   0  4

Which results in an ELF load header:

  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD   0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x1

This is all correct, the load region containing the PLT is marked as
executable. Note that the PLT starts at 0002b00c but the file mapping ends at
0002aff8, so the PLT falls in the 0 fill section described by the load header,
and after a page boundary.

Unfortunately the generic ELF loader ignores the X bit in the load headers
when it creates the 0 filled non-file backed mappings. It assumes all of these
mappings are RW BSS sections, which is not the case for PPC.

gcc/ld has an option (--secure-plt) to not do this, this is said to incur
a small performance penalty.

Currently, to support 32-bit binaries with PLT in BSS kernel maps *entire
brk area* with executable rights for all binaries, even --secure-plt ones.

Stop doing that.

Teach the ELF loader to check the X bit in the relevant load header
and create 0 filled anonymous mappings that are executable
if the load header requests that.

The patch was originally posted in 2012 by Jason Gunthorpe
and apparently ignored:

https://lkml.org/lkml/2012/9/30/138

Lightly run-tested.

Signed-off-by: Jason Gunthorpe 
Signed-off-by: Denys Vlasenko 
CC: Benjamin Herrenschmidt 
CC: Paul Mackerras 
CC: Kees Cook 
CC: Oleg Nesterov ,
CC: Michael Ellerman 
CC: Florian Weimer 
CC: linux...@kvack.org,
CC: linuxppc-dev@lists.ozlabs.org
CC: linux-ker...@vger.kernel.org
---
Changes since v1:
* wrapped lines to not exceed 79 chars
* improved comment
* expanded CC list

 arch/powerpc/include/asm/page.h| 10 +--
 arch/powerpc/include/asm/page_32.h |  2 --
 arch/powerpc/include/asm/page_64.h |  4 ---
 fs/binfmt_elf.c| 56 ++
 4 files changed, 45 insertions(+), 27 deletions(-)

diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 56398e7..42d7ea1 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -225,15 +225,7 @@ extern long long virt_phys_offset;
 #endif
 #endif

-/*
- * Unfortunately the PLT is in the BSS in the PPC32 ELF ABI,
- * and needs to be executable.  This means the whole heap ends
- * up being executable.
- */
-#define VM_DATA_DEFAULT_FLAGS32(VM_READ | VM_WRITE | VM_EXEC | \
-VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
-
-#define VM_DATA_DEFAULT_FLAGS64(VM_READ | VM_WRITE | \
+#define VM_DATA_DEFAULT_FLAGS  (VM_READ | VM_WRITE | \
 VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)

 #ifdef __powerpc64__
diff --git a/arch/powerpc/include/asm/page_32.h 
b/arch/powerpc/include/asm/page_32.h
index 6a8e179..6113fa8 100644
--- a/arch/powerpc/include/asm/page_32.h
+++ b/arch/powerpc/include/asm/page_32.h
@@ -9,8 +9,6 @@
 #endif
 #endif

-#define VM_DATA_DEFAULT_FLAGS  VM_DATA_DEFAULT_FLAGS32
-
 #ifdef CONFIG_NOT_COHERENT_CACHE
 #define ARCH_DMA_MINALIGN  L1_CACHE_BYTES
 #endif
diff --git a/arch/powerpc/include/asm/page_64.h 
b/arch/powerpc/include/asm/page_64.h
index dd5f071..52d8e9c 100644
--- a/arch/powerpc/include/asm/page_64.h
+++ b/arch/powerpc/include/asm/page_64.h
@@ -159,10 +159,6 @@ do {   \

 #endif /* !CONFIG_HUGETLB_PAGE */

-#define VM_DATA_DEFAULT_FLAGS \
-   (is_32bit_task() ? \
-VM_DATA_DEFAULT_FLAGS32 : VM_DATA_DEFAULT_FLAGS64)
-
 /*
  * This is the default if a program doesn't have a PT_GNU_STACK
  * program header entry. The PPC64 ELF ABI has a non executable stack
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index a7a28110..50006d0 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -91,14 +91,25 @@ static struct linux_binfmt elf_format = {

 #define BAD_ADDR(x) ((unsigned long)(x) >= TASK_SIZE)

-static int set_brk(unsigned long start, unsigned long end)
+static int set_brk(unsigned long start, unsigned long end, int prot)
 {
start = ELF_PAGEALIGN(start);
end = ELF_PAGEALIGN(end);
if (end > start) {
-   int error = vm_brk(start, end - start);
-   if (error)
-   return error;
+   /* Map the non-file portion of the last load header. If the
+  header is 

Re: [PATCH v2 3/3] powerpc: Convert fsl_rstcr_restart to a reset handler

[Andrey Smirnov]

On Sun, Jul 31, 2016 at 9:03 PM, Nicholas Piggin  wrote:
> On Thu, 28 Jul 2016 16:07:18 -0700
> Andrey Smirnov  wrote:
>
>> Convert fsl_rstcr_restart into a function to be registered with
>> register_reset_handler().
>>
>> Signed-off-by: Andrey Smirnov 
>> ---
>>
>> Changes since v1:
>>
>>   - fsl_rstcr_restart is registered as a reset handler in
>>   setup_rstcr, replacing per-board arch_initcall approach
>
> Bear in mind I don't know much about the embedded or platform code!
>
> The documentation for reset notifiers says that they are expected
> to be registered from drivers, not arch code. That seems to only be
> intended to mean that the standard ISA or platform reset would
> normally be handled directly by the arch, whereas if you have an
> arch specific driver for a reset hardware that just happens to live
> under arch/, then fsl_rstcr_restart / mpc85xx_cds_restart would be
> valid use of reset notifier.

Yeah, IMHO there's quite a bit of code in sysdev/ which in ideal world
would go into drivers/ and I think fsl_rstcr_restart is among it
(similar example on MIPS is drivers/power/reset/brcmstb-reboot.c).

>
> So this change seems reasonable to me. One small question:
>
>
>> +static int mpc85xx_cds_restart_register(void)
>> +{
>> + static struct notifier_block restart_handler;
>> +
>> + restart_handler.notifier_call = mpc85xx_cds_restart;
>> + restart_handler.priority = 192;
>
> Should there be a header with #define's for these priorities?

I don't have any strong preference either way, I do however think that
introducing such #define should go into a separate patch-set, since
you'd probably want to propagate that change across all of the users
of the API.

Thanks,
Andrey

Re: [PATCH v2 2/3] powerpc: Call chained reset handlers during reset

[Andrey Smirnov]

On Sun, Jul 31, 2016 at 8:47 PM, Nicholas Piggin  wrote:
> On Thu, 28 Jul 2016 16:07:17 -0700
> Andrey Smirnov  wrote:
>
>> Call out to all restart handlers that were added via
>> register_restart_handler() API when restarting the machine.
>>
>> Signed-off-by: Andrey Smirnov 
>> ---
>>
>> No changes compared to v1
>>
>>  arch/powerpc/kernel/setup-common.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/powerpc/kernel/setup-common.c
>> b/arch/powerpc/kernel/setup-common.c index 5cd3283..205d073 100644
>> --- a/arch/powerpc/kernel/setup-common.c
>> +++ b/arch/powerpc/kernel/setup-common.c
>> @@ -145,6 +145,10 @@ void machine_restart(char *cmd)
>>   ppc_md.restart(cmd);
>>
>>   smp_send_stop();
>> +
>> + do_kernel_restart(cmd);
>> + mdelay(1000);
>> +
>>   machine_hang();
>>  }
>>
>
> Ah, I see why you don't move smp_send_stop(). 3 other architectures
> call do_kernel_restart(). arm and arm64 call it with
> local_irq_disabled().

I am not very familiar with low-level SPM code, so take all below with
a grain of salt.

>From my understanding of the code ARM's implementation of
smp_send_stop() is different from MIPS/PowerPC ones in that it just
raises an IPI with a special "stop" flag set, which can and probably
should be done with IRQs disabled. Both MIPS and PowerPC call
smp_call_fuction() in their smp_send_stop() implementation, which if I
read the documentation correctly should not be called with interrupts
disabled, so it looks like the call to local_irq_disabled() could only
be placed after the call to smp_send_stop() on those platforms.

> arm and mips insert the 1s delay. All call it
> after smp_send_stop(). I don't see the harm in the delay. Should we
> call it with local interrupts disabled?
>

With all above being said I don't see any harm in disabling interrupts.

Thanks,
Andrey

Re: [PATCH 2/2] powerpc/pseries: Dynamically increase RMA size

[Sukadev Bhattiprolu]

Paul Clarke [p...@us.ibm.com] wrote:
> Only nits from me...(see below)

Paul,

I agree with your comments and fixed them. Here is the updated patch.

---

>From f9e9e8460206bc3fa7eaa741b9a2bde22870b9e0 Mon Sep 17 00:00:00 2001
From: root 
Date: Thu, 4 Aug 2016 23:13:37 -0400
Subject: [PATCH 2/2] powerpc/pseries: Dynamically grow RMA size

When booting a very large system with a large initrd we run out of space
for the flattened device tree (FDT). To fix this we must increase the
space allocated for the RMA region.

The RMA size is hard-coded in the 'ibm_architecture_vec[]' and increasing
the size there will apply to all systems, large and small, so we want to
increase the RMA region only when necessary.

When we run out of room for the FDT, set a new OF property, 'ibm,new-rma-size'
to the new RMA size (512MB) and issue a client-architecture-support (CAS)
call to the firmware. This will initiate a system reboot. Upon reboot we
notice the new property and update the RMA size accordingly.

Fix suggested by Michael Ellerman.

Signed-off-by: Sukadev Bhattiprolu 
---

[v3]:   - [Paul Clarke] Fix a few nits.

[v2]:   - Add a comment in code regarding 'fixup_nr_cores_done'
- Fix build break when CONFIG_PPC_PSERIES=n
---
 arch/powerpc/kernel/prom_init.c | 97 -
 1 file changed, 96 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index f612a99..d1aaeda 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -87,6 +87,9 @@
 int of_workarounds;
 #endif
 
+#define IBM_NEW_RMA_SIZE_PROP  "ibm,new-rma-size"
+#define IBM_NEW_RMA_SIZE_STR   "512"
+
 #define OF_WA_CLAIM1   /* do phys/virt claim separately, then map */
 #define OF_WA_LONGTRAIL2   /* work around longtrail bugs */
 
@@ -679,6 +682,7 @@ unsigned char ibm_architecture_vec[] = {
W(0x),  /* virt_base */
W(0x),  /* virt_size */
W(0x),  /* load_base */
+#define IBM_ARCH_VEC_MIN_RMA_OFFSET108
W(256), /* 256MB min RMA */
W(0x),  /* full client load */
0,  /* min RMA percentage of total RAM */
@@ -867,6 +871,14 @@ static void fixup_nr_cores(void)
 {
u32 cores;
unsigned char *ptcores;
+   static bool fixup_nr_cores_done = false;
+
+   /*
+* If this is a second CAS call in the same boot sequence, (see
+* increase_rma_size()), we don't need to do the fixup again.
+*/
+   if (fixup_nr_cores_done)
+   return;
 
/* We need to tell the FW about the number of cores we support.
 *
@@ -898,6 +910,42 @@ static void fixup_nr_cores(void)
ptcores[1] = (cores >> 16) & 0xff;
ptcores[2] = (cores >> 8) & 0xff;
ptcores[3] = cores & 0xff;
+   fixup_nr_cores_done = true;
+   }
+}
+
+static void __init fixup_rma_size(void)
+{
+   int rc;
+   u64 size;
+   unsigned char *min_rmap;
+   phandle optnode;
+   char str[64];
+
+   optnode = call_prom("finddevice", 1, 1, ADDR("/options"));
+   if (!PHANDLE_VALID(optnode))
+   prom_panic("Cannot find /options");
+
+   /*
+* If a prior boot specified a new RMA size, use that size in
+* ibm_architecture_vec[]. See also increase_rma_size().
+*/
+   size = 0ULL;
+   memset(str, 0, sizeof(str));
+   rc = prom_getprop(optnode, IBM_NEW_RMA_SIZE_PROP, , sizeof(str));
+   if (rc <= 0)
+   return;
+
+   size = prom_strtoul(str, NULL);
+   min_rmap = _architecture_vec[IBM_ARCH_VEC_MIN_RMA_OFFSET];
+
+   if (size) {
+   prom_printf("Using RMA size %lu from %s.\n", size,
+   IBM_NEW_RMA_SIZE_PROP);
+   min_rmap[0] = (size >> 24) & 0xff;
+   min_rmap[1] = (size >> 16) & 0xff;
+   min_rmap[2] = (size >> 8) & 0xff;
+   min_rmap[3] = size & 0xff;
}
 }
 
@@ -911,6 +959,8 @@ static void __init prom_send_capabilities(void)
 
fixup_nr_cores();
 
+   fixup_rma_size();
+
/* try calling the ibm,client-architecture-support method */
prom_printf("Calling ibm,client-architecture-support...");
if (call_prom_ret("call-method", 3, 2, ,
@@ -946,6 +996,49 @@ static void __init prom_send_capabilities(void)
}
 #endif /* __BIG_ENDIAN__ */
 }
+
+static void __init increase_rma_size(void)
+{
+   int rc, len;
+   char str[64];
+   phandle optnode;
+
+   optnode = call_prom("finddevice", 1, 1, ADDR("/options"));
+   if (!PHANDLE_VALID(optnode))
+   prom_panic("Cannot find /options");
+
+   /*
+* If 

Re: [PATCH] i2c: don't print error when adding adapter fails

[Vladimir Zapolskiy]

On 09.08.2016 14:36, Wolfram Sang wrote:
> The core will do this for us now.
> 
> Signed-off-by: Wolfram Sang 
> ---

For 

>  drivers/i2c/busses/i2c-pnx.c| 4 +---

[snip]

> diff --git a/drivers/i2c/busses/i2c-pnx.c b/drivers/i2c/busses/i2c-pnx.c
> index 7ea67aa46fb730..fd5f9d2bf6d94e 100644
> --- a/drivers/i2c/busses/i2c-pnx.c
> +++ b/drivers/i2c/busses/i2c-pnx.c
> @@ -714,10 +714,8 @@ static int i2c_pnx_probe(struct platform_device *pdev)
>  
>   /* Register this adapter with the I2C subsystem */
>   ret = i2c_add_numbered_adapter(_data->adapter);
> - if (ret < 0) {
> - dev_err(>dev, "I2C: Failed to add bus\n");
> + if (ret < 0)
>   goto out_clock;
> - }
>  
>   dev_dbg(>dev, "%s: Master at %#8x, irq %d.\n",
>   alg_data->adapter.name, res->start, alg_data->irq);

Acked-by: Vladimir Zapolskiy 

--
With best wishes,
Vladimir

Re: [PATCH v2 1/3] powerpc: Factor out common code in setup-common.c

[Andrey Smirnov]

On Sun, Jul 31, 2016 at 8:40 PM, Nicholas Piggin  wrote:
> On Thu, 28 Jul 2016 16:07:16 -0700
> Andrey Smirnov  wrote:
>
>> Factor out a small bit of common code in machine_restart(),
>> machine_power_off() and machine_halt().
>>
>> Signed-off-by: Andrey Smirnov 
>> ---
>>
>> No changes compared to v1.
>>
>>  arch/powerpc/kernel/setup-common.c | 23 ++-
>>  1 file changed, 14 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/setup-common.c
>> b/arch/powerpc/kernel/setup-common.c index 714b4ba..5cd3283 100644
>> --- a/arch/powerpc/kernel/setup-common.c
>> +++ b/arch/powerpc/kernel/setup-common.c
>> @@ -130,15 +130,22 @@ void machine_shutdown(void)
>>   ppc_md.machine_shutdown();
>>  }
>>
>> +static void machine_hang(void)
>> +{
>> + pr_emerg("System Halted, OK to turn off power\n");
>> + local_irq_disable();
>> + while (1)
>> + ;
>> +}
>
> What's the intended semantics of this function? A default power
> off handler when the platform supplies none?

I was mostly trying to avoid code duplication in
machine_halt/machine_restart/machine_power_off and didn't intend that
function to be used outside. The semantics is just - to hang the CPU
when things didn't go as expected and code that was supposed to
restart/halt/power off the machine failed.

> Would ppc_power_off()
> be a good name?

Calling it "power_off" seems a bit misleading, the function doesn't
really try to do anything related to powering off, really.

Thanks,
Andrey

Re: [PATCH] cxl: Set psl_fir_cntl to production environment value

[Uma Krishnan]

Reviewed-by: Uma Krishnan 

On 8/8/2016 4:57 AM, Frederic Barrat wrote:

Switch the setting of psl_fir_cntl from debug to production
environment recommended value. It mostly affects the PSL behavior when
an error is raised in psl_fir1/2.

Tested with cxlflash.

Signed-off-by: Frederic Barrat 
---
 drivers/misc/cxl/pci.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index d152e2d..4be25c4 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -379,7 +379,7 @@ static int calc_capp_routing(struct pci_dev *dev, u64 
*chipid, u64 *capp_unit_id

 static int init_implementation_adapter_psl_regs(struct cxl *adapter, struct 
pci_dev *dev)
 {
-   u64 psl_dsnctl;
+   u64 psl_dsnctl, psl_fircntl;
u64 chipid;
u64 capp_unit_id;
int rc;
@@ -398,8 +398,11 @@ static int init_implementation_adapter_psl_regs(struct cxl 
*adapter, struct pci_
cxl_p1_write(adapter, CXL_PSL_RESLCKTO, 0x2000200ULL);
/* snoop write mask */
cxl_p1_write(adapter, CXL_PSL_SNWRALLOC, 0xULL);
-   /* set fir_accum */
-   cxl_p1_write(adapter, CXL_PSL_FIR_CNTL, 0x0800ULL);
+   /* set fir_cntl to recommended value for production env */
+   psl_fircntl = (0x2ULL << (63-3)); /* ce_report */
+   psl_fircntl |= (0x1ULL << (63-6)); /* FIR_report */
+   psl_fircntl |= 0x1ULL; /* ce_thresh */
+   cxl_p1_write(adapter, CXL_PSL_FIR_CNTL, psl_fircntl);
/* for debugging with trace arrays */
cxl_p1_write(adapter, CXL_PSL_TRACE, 0xFF7CULL);

Re: [PATCH] i2c: don't print error when adding adapter fails

[Wolfram Sang]

> >@@ -550,15 +550,10 @@ static int uniphier_fi2c_probe(struct platform_device 
> >*pdev)
> > }
> >
> > ret = i2c_add_adapter(>adap);
> >-if (ret) {
> >-dev_err(dev, "failed to add I2C adapter\n");
> >-goto err;
> >-}
> >-
> >-err:
> > if (ret)
> > clk_disable_unprepare(priv->clk);
> >
> >+ err:
> 
> You sure about that one ? It leaves the clock enabled in some of the error 
> paths.

Uh, ehrm, where is the brown paper bag? Thanks, Guenter!

> Note: I dropped all individuals from Cc:; my mailer refused to accept the 
> reply because there
> were too many.

Yes, the disadvantage of not breaking out.



signature.asc
Description: PGP signature

Re: [PATCH] powerpc/Makefile: Use cflags-y/aflags-y for setting endian options

[Nicholas Piggin]

On Tue,  9 Aug 2016 22:43:46 +1000
Michael Ellerman  wrote:

> When we introduced the little endian support, we added the endian flags
> to CC directly using override. I don't know the history of why we did
> that, I suspect no one does.
> 
> Although this mostly works, it has one bug, which is that CROSS32CC
> doesn't get -mbig-endian. That means when the compiler is little endian
> by default and the user is building big endian, vdso32 is incorrectly
> compiled as little endian and the kernel fails to build.
> 
> Instead we can add the endian flags to cflags-y/aflags-y, and then
> append those to KBUILD_CFLAGS/KBUILD_AFLAGS.
> 
> This has the advantage of being 1) less ugly, 2) the documented way of
> adding flags in the arch Makefile and 3) it fixes building vdso32 with a
> LE toolchain.

This seems okay to me.

> 
> Signed-off-by: Michael Ellerman 
> ---
>  arch/powerpc/Makefile | 22 --
>  1 file changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index ca254546cd05..1934707bf321 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -66,29 +66,28 @@ endif
>  UTS_MACHINE := $(OLDARCH)
>  
>  ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
> -override CC  += -mlittle-endian
> -ifneq ($(cc-name),clang)
> -override CC  += -mno-strict-align
> -endif
> -override AS  += -mlittle-endian
>  override LD  += -EL
> -override CROSS32CC += -mlittle-endian
>  override CROSS32AS += -mlittle-endian

Can't we get rid of CROSS32AS? If not, then should it get the
-mbig-endian override?

Thanks,
Nick

Re: [PATCH 1/7] ima: on soft reboot, restore the measurement list

[Mimi Zohar]

On Tue, 2016-08-09 at 09:55 -0400, Mimi Zohar wrote:
> On Tue, 2016-08-09 at 10:19 -0300, Thiago Jung Bauermann wrote:
> > Am Dienstag, 09 August 2016, 09:01:13 schrieb Mimi Zohar:
> > > On Tue, 2016-08-09 at 20:59 +1000, Michael Ellerman wrote:
> > > > Mimi Zohar  writes:
> > > > > diff --git a/security/integrity/ima/ima.h
> > > > > b/security/integrity/ima/ima.h
> > > > > index b5728da..84e8d36 100644
> > > > > --- a/security/integrity/ima/ima.h
> > > > > +++ b/security/integrity/ima/ima.h
> > > > > @@ -102,6 +102,13 @@ struct ima_queue_entry {
> > > > > 
> > > > >  };
> > > > >  extern struct list_head ima_measurements;/* list of all 
> > measurements
> > > > >  */
> > > > > 
> > > > > +/* Some details preceding the binary serialized measurement list */
> > > > > +struct ima_kexec_hdr {
> > > > > + unsigned short version;
> > > > > + unsigned long buffer_size;
> > > > > + unsigned long count;
> > > > > +} __packed;
> > > > > +
> > > > 
> > > > Am I understanding it correctly that this structure is passed between
> > > > kernels?
> > > Yes, the header prefixes the measurement list, which is being passed on
> > > the same computer to the next kernel.  Could the architecture (eg.
> > > LE/BE) change between soft re-boots?
> > 
> > Yes. I am able to boot a BE kernel from an LE kernel with my patches. 
> > Whether we want to support that or not is another question...
> 
> The  dependent.  It looks like the khdr->version check in
> ima_restore_measurement_list() would fail if the architecture changes.
> 
> If/when we update the binary measurement list format to support multiple
> TPM PCRs, we should address the endianness as well.

That should have been "TPM PCR banks".  TPM 2.0 allows for multiple TPM
PCR banks.

Mimi

Re: [PATCH 1/7] ima: on soft reboot, restore the measurement list

[Mimi Zohar]

On Tue, 2016-08-09 at 13:35 +, David Laight wrote:

> Also why '__packed' - guarantees sub-optimal code generation.
> Much better to include explicit padding to align everything.

This patch set does not define a new format, but piggy backs on top of
the existing /ima/binary_runtime_measurements list.  The
prefixed buffer header includes a version, so that if in the future we
need to modify the format, we would be able to.

In terms of the prefixed header, how would you define the fields:
version, buffer size, number of measurements? 

Mimi

Re: [PATCH 1/7] ima: on soft reboot, restore the measurement list

[Mimi Zohar]

On Tue, 2016-08-09 at 10:19 -0300, Thiago Jung Bauermann wrote:
> Am Dienstag, 09 August 2016, 09:01:13 schrieb Mimi Zohar:
> > On Tue, 2016-08-09 at 20:59 +1000, Michael Ellerman wrote:
> > > Mimi Zohar  writes:
> > > > diff --git a/security/integrity/ima/ima.h
> > > > b/security/integrity/ima/ima.h
> > > > index b5728da..84e8d36 100644
> > > > --- a/security/integrity/ima/ima.h
> > > > +++ b/security/integrity/ima/ima.h
> > > > @@ -102,6 +102,13 @@ struct ima_queue_entry {
> > > > 
> > > >  };
> > > >  extern struct list_head ima_measurements;  /* list of all 
> measurements
> > > >  */
> > > > 
> > > > +/* Some details preceding the binary serialized measurement list */
> > > > +struct ima_kexec_hdr {
> > > > +   unsigned short version;
> > > > +   unsigned long buffer_size;
> > > > +   unsigned long count;
> > > > +} __packed;
> > > > +
> > > 
> > > Am I understanding it correctly that this structure is passed between
> > > kernels?
> > Yes, the header prefixes the measurement list, which is being passed on
> > the same computer to the next kernel.  Could the architecture (eg.
> > LE/BE) change between soft re-boots?
> 
> Yes. I am able to boot a BE kernel from an LE kernel with my patches. 
> Whether we want to support that or not is another question...

The version check in
ima_restore_measurement_list() would fail if the architecture changes.

If/when we update the binary measurement list format to support multiple
TPM PCRs, we should address the endianness as well.

Mimi

Re: [PATCH] i2c: don't print error when adding adapter fails

[Wolfram Sang]

On Tue, Aug 09, 2016 at 01:57:40PM +0200, Uwe Kleine-König wrote:
> Hello Wolfram,
> 
> On Tue, Aug 09, 2016 at 01:36:17PM +0200, Wolfram Sang wrote:
> > The core will do this for us now.
> 
> Would be nice to point out the relevant commit that changed the core in
> the commit log.

I agree, but it was a series of commits[1] so I skipped that idea.

[1] http://www.spinics.net/lists/linux-i2c/msg25496.html



signature.asc
Description: PGP signature

Re: [PATCH] i2c: don't print error when adding adapter fails

[Neil Horman]

On Tue, Aug 09, 2016 at 01:36:17PM +0200, Wolfram Sang wrote:
> The core will do this for us now.
> 
> Signed-off-by: Wolfram Sang 
> ---
>  drivers/i2c/busses/i2c-amd756.c | 5 +
>  drivers/i2c/busses/i2c-at91.c   | 2 --
>  drivers/i2c/busses/i2c-axxia.c  | 8 +---
>  drivers/i2c/busses/i2c-bcm-iproc.c  | 8 +---
>  drivers/i2c/busses/i2c-bcm-kona.c   | 4 +---
>  drivers/i2c/busses/i2c-bfin-twi.c   | 4 +---
>  drivers/i2c/busses/i2c-brcmstb.c| 4 +---
>  drivers/i2c/busses/i2c-cadence.c| 4 +---
>  drivers/i2c/busses/i2c-cpm.c| 4 +---
>  drivers/i2c/busses/i2c-cros-ec-tunnel.c | 4 +---
>  drivers/i2c/busses/i2c-davinci.c| 4 +---
>  drivers/i2c/busses/i2c-diolan-u2c.c | 4 +---
>  drivers/i2c/busses/i2c-dln2.c   | 4 +---
>  drivers/i2c/busses/i2c-efm32.c  | 1 -
>  drivers/i2c/busses/i2c-exynos5.c| 4 +---
>  drivers/i2c/busses/i2c-hix5hd2.c| 4 +---
>  drivers/i2c/busses/i2c-i801.c   | 1 -
>  drivers/i2c/busses/i2c-ibm_iic.c| 4 +---
>  drivers/i2c/busses/i2c-img-scb.c| 4 +---
>  drivers/i2c/busses/i2c-imx.c| 4 +---
>  drivers/i2c/busses/i2c-isch.c   | 4 +---
>  drivers/i2c/busses/i2c-ismt.c   | 4 +---
>  drivers/i2c/busses/i2c-jz4780.c | 4 +---
>  drivers/i2c/busses/i2c-lpc2k.c  | 4 +---
>  drivers/i2c/busses/i2c-meson.c  | 1 -
>  drivers/i2c/busses/i2c-mpc.c| 4 +---
>  drivers/i2c/busses/i2c-mt65xx.c | 4 +---
>  drivers/i2c/busses/i2c-mxs.c| 1 -
>  drivers/i2c/busses/i2c-nforce2.c| 1 -
>  drivers/i2c/busses/i2c-nomadik.c| 4 +---
>  drivers/i2c/busses/i2c-ocores.c | 4 +---
>  drivers/i2c/busses/i2c-octeon.c | 4 +---
>  drivers/i2c/busses/i2c-omap.c   | 4 +---
>  drivers/i2c/busses/i2c-piix4.c  | 1 -
>  drivers/i2c/busses/i2c-pmcmsp.c | 4 +---
>  drivers/i2c/busses/i2c-pnx.c| 4 +---
>  drivers/i2c/busses/i2c-puv3.c   | 5 +
>  drivers/i2c/busses/i2c-pxa.c| 4 +---
>  drivers/i2c/busses/i2c-rcar.c   | 4 +---
>  drivers/i2c/busses/i2c-riic.c   | 4 +---
>  drivers/i2c/busses/i2c-rk3x.c   | 4 +---
>  drivers/i2c/busses/i2c-s3c2410.c| 1 -
>  drivers/i2c/busses/i2c-sh7760.c | 4 +---
>  drivers/i2c/busses/i2c-sh_mobile.c  | 1 -
>  drivers/i2c/busses/i2c-sirf.c   | 4 +---
>  drivers/i2c/busses/i2c-st.c | 4 +---
>  drivers/i2c/busses/i2c-stu300.c | 5 +
>  drivers/i2c/busses/i2c-tegra.c  | 4 +---
>  drivers/i2c/busses/i2c-uniphier-f.c | 7 +--
>  drivers/i2c/busses/i2c-uniphier.c   | 7 +--
>  drivers/i2c/busses/i2c-wmt.c| 4 +---
>  drivers/i2c/busses/i2c-xgene-slimpro.c  | 1 -
>  drivers/i2c/busses/i2c-xiic.c   | 1 -
>  drivers/i2c/busses/i2c-xlp9xx.c | 4 +---
>  drivers/i2c/busses/i2c-xlr.c| 4 +---
>  55 files changed, 44 insertions(+), 161 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-amd756.c b/drivers/i2c/busses/i2c-amd756.c
> index 6c7113d990f882..274908cd1fdeab 100644
> --- a/drivers/i2c/busses/i2c-amd756.c
> +++ b/drivers/i2c/busses/i2c-amd756.c
> @@ -378,11 +378,8 @@ static int amd756_probe(struct pci_dev *pdev, const 
> struct pci_device_id *id)
>amd756_ioport);
>  
>   error = i2c_add_adapter(_smbus);
> - if (error) {
> - dev_err(>dev,
> - "Adapter registration failed, module not inserted\n");
> + if (error)
>   goto out_err;
> - }
>  
>   return 0;
>  
> diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
> index f23372669f770f..03a519d29616d7 100644
> --- a/drivers/i2c/busses/i2c-at91.c
> +++ b/drivers/i2c/busses/i2c-at91.c
> @@ -1118,8 +1118,6 @@ static int at91_twi_probe(struct platform_device *pdev)
>  
>   rc = i2c_add_numbered_adapter(>adapter);
>   if (rc) {
> - dev_err(dev->dev, "Adapter %s registration failed\n",
> - dev->adapter.name);
>   clk_disable_unprepare(dev->clk);
>  
>   pm_runtime_disable(dev->dev);
> diff --git a/drivers/i2c/busses/i2c-axxia.c b/drivers/i2c/busses/i2c-axxia.c
> index c335cc7852f94e..d3bcaf4ab095d0 100644
> --- a/drivers/i2c/busses/i2c-axxia.c
> +++ b/drivers/i2c/busses/i2c-axxia.c
> @@ -558,13 +558,7 @@ static int axxia_i2c_probe(struct platform_device *pdev)
>  
>   platform_set_drvdata(pdev, idev);
>  
> - ret = i2c_add_adapter(>adapter);
> - if (ret) {
> - dev_err(>dev, "failed to add adapter\n");
> - return ret;
> - }
> -
> - return 0;
> + return i2c_add_adapter(>adapter);
>  }
>  
>  static int axxia_i2c_remove(struct platform_device *pdev)
> diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c 
> b/drivers/i2c/busses/i2c-bcm-iproc.c
> index 19c843828fe2ca..8e3477f9297eda 100644

RE: [PATCH 1/7] ima: on soft reboot, restore the measurement list

[David Laight]

From: Thiago Jung Bauermann
> Sent: 09 August 2016 14:19
...
> > > > +/* Some details preceding the binary serialized measurement list */
> > > > +struct ima_kexec_hdr {
> > > > +   unsigned short version;
> > > > +   unsigned long buffer_size;
> > > > +   unsigned long count;
> > > > +} __packed;
> > > > +
> > >
> > > Am I understanding it correctly that this structure is passed between
> > > kernels?
> > Yes, the header prefixes the measurement list, which is being passed on
> > the same computer to the next kernel.  Could the architecture (eg.
> > LE/BE) change between soft re-boots?
> 
> Yes. I am able to boot a BE kernel from an LE kernel with my patches.

64bit kernel to/from 32bit one? (if that makes sense on the hardware).

> Whether we want to support that or not is another question...

In which case shouldn't they be annotated with the endianness??

Also why '__packed' - guarantees sub-optimal code generation.
Much better to include explicit padding to align everything.

David

Re: [PATCH] i2c: don't print error when adding adapter fails

[Grygorii Strashko]

On 08/09/2016 02:36 PM, Wolfram Sang wrote:

The core will do this for us now.

Signed-off-by: Wolfram Sang 
---


For:

 drivers/i2c/busses/i2c-davinci.c| 4 +---
 drivers/i2c/busses/i2c-omap.c   | 4 +---


Reviewed-by: Grygorii Strashko 


--
regards,
-grygorii

[PATCH] i2c: don't print error when adding adapter fails

[Wolfram Sang]

Since v4.8-rc1, the I2C core will print detailed information when adding an I2C
adapter fails. So, drivers can skip this now.

I am still undecided if I apply this as a single patch or break it out. But for
reviewing, avoiding the patch bomb is probably a good thing.

Should go via subsystem tree, I'd think.

Wolfram Sang (1):
  i2c: don't print error when adding adapter fails

 drivers/i2c/busses/i2c-amd756.c | 5 +
 drivers/i2c/busses/i2c-at91.c   | 2 --
 drivers/i2c/busses/i2c-axxia.c  | 8 +---
 drivers/i2c/busses/i2c-bcm-iproc.c  | 8 +---
 drivers/i2c/busses/i2c-bcm-kona.c   | 4 +---
 drivers/i2c/busses/i2c-bfin-twi.c   | 4 +---
 drivers/i2c/busses/i2c-brcmstb.c| 4 +---
 drivers/i2c/busses/i2c-cadence.c| 4 +---
 drivers/i2c/busses/i2c-cpm.c| 4 +---
 drivers/i2c/busses/i2c-cros-ec-tunnel.c | 4 +---
 drivers/i2c/busses/i2c-davinci.c| 4 +---
 drivers/i2c/busses/i2c-diolan-u2c.c | 4 +---
 drivers/i2c/busses/i2c-dln2.c   | 4 +---
 drivers/i2c/busses/i2c-efm32.c  | 1 -
 drivers/i2c/busses/i2c-exynos5.c| 4 +---
 drivers/i2c/busses/i2c-hix5hd2.c| 4 +---
 drivers/i2c/busses/i2c-i801.c   | 1 -
 drivers/i2c/busses/i2c-ibm_iic.c| 4 +---
 drivers/i2c/busses/i2c-img-scb.c| 4 +---
 drivers/i2c/busses/i2c-imx.c| 4 +---
 drivers/i2c/busses/i2c-isch.c   | 4 +---
 drivers/i2c/busses/i2c-ismt.c   | 4 +---
 drivers/i2c/busses/i2c-jz4780.c | 4 +---
 drivers/i2c/busses/i2c-lpc2k.c  | 4 +---
 drivers/i2c/busses/i2c-meson.c  | 1 -
 drivers/i2c/busses/i2c-mpc.c| 4 +---
 drivers/i2c/busses/i2c-mt65xx.c | 4 +---
 drivers/i2c/busses/i2c-mxs.c| 1 -
 drivers/i2c/busses/i2c-nforce2.c| 1 -
 drivers/i2c/busses/i2c-nomadik.c| 4 +---
 drivers/i2c/busses/i2c-ocores.c | 4 +---
 drivers/i2c/busses/i2c-octeon.c | 4 +---
 drivers/i2c/busses/i2c-omap.c   | 4 +---
 drivers/i2c/busses/i2c-piix4.c  | 1 -
 drivers/i2c/busses/i2c-pmcmsp.c | 4 +---
 drivers/i2c/busses/i2c-pnx.c| 4 +---
 drivers/i2c/busses/i2c-puv3.c   | 5 +
 drivers/i2c/busses/i2c-pxa.c| 4 +---
 drivers/i2c/busses/i2c-rcar.c   | 4 +---
 drivers/i2c/busses/i2c-riic.c   | 4 +---
 drivers/i2c/busses/i2c-rk3x.c   | 4 +---
 drivers/i2c/busses/i2c-s3c2410.c| 1 -
 drivers/i2c/busses/i2c-sh7760.c | 4 +---
 drivers/i2c/busses/i2c-sh_mobile.c  | 1 -
 drivers/i2c/busses/i2c-sirf.c   | 4 +---
 drivers/i2c/busses/i2c-st.c | 4 +---
 drivers/i2c/busses/i2c-stu300.c | 5 +
 drivers/i2c/busses/i2c-tegra.c  | 4 +---
 drivers/i2c/busses/i2c-uniphier-f.c | 7 +--
 drivers/i2c/busses/i2c-uniphier.c   | 7 +--
 drivers/i2c/busses/i2c-wmt.c| 4 +---
 drivers/i2c/busses/i2c-xgene-slimpro.c  | 1 -
 drivers/i2c/busses/i2c-xiic.c   | 1 -
 drivers/i2c/busses/i2c-xlp9xx.c | 4 +---
 drivers/i2c/busses/i2c-xlr.c| 4 +---
 55 files changed, 44 insertions(+), 161 deletions(-)

-- 
2.8.1

[PATCH] i2c: don't print error when adding adapter fails

[Wolfram Sang]

The core will do this for us now.

Signed-off-by: Wolfram Sang 
---
 drivers/i2c/busses/i2c-amd756.c | 5 +
 drivers/i2c/busses/i2c-at91.c   | 2 --
 drivers/i2c/busses/i2c-axxia.c  | 8 +---
 drivers/i2c/busses/i2c-bcm-iproc.c  | 8 +---
 drivers/i2c/busses/i2c-bcm-kona.c   | 4 +---
 drivers/i2c/busses/i2c-bfin-twi.c   | 4 +---
 drivers/i2c/busses/i2c-brcmstb.c| 4 +---
 drivers/i2c/busses/i2c-cadence.c| 4 +---
 drivers/i2c/busses/i2c-cpm.c| 4 +---
 drivers/i2c/busses/i2c-cros-ec-tunnel.c | 4 +---
 drivers/i2c/busses/i2c-davinci.c| 4 +---
 drivers/i2c/busses/i2c-diolan-u2c.c | 4 +---
 drivers/i2c/busses/i2c-dln2.c   | 4 +---
 drivers/i2c/busses/i2c-efm32.c  | 1 -
 drivers/i2c/busses/i2c-exynos5.c| 4 +---
 drivers/i2c/busses/i2c-hix5hd2.c| 4 +---
 drivers/i2c/busses/i2c-i801.c   | 1 -
 drivers/i2c/busses/i2c-ibm_iic.c| 4 +---
 drivers/i2c/busses/i2c-img-scb.c| 4 +---
 drivers/i2c/busses/i2c-imx.c| 4 +---
 drivers/i2c/busses/i2c-isch.c   | 4 +---
 drivers/i2c/busses/i2c-ismt.c   | 4 +---
 drivers/i2c/busses/i2c-jz4780.c | 4 +---
 drivers/i2c/busses/i2c-lpc2k.c  | 4 +---
 drivers/i2c/busses/i2c-meson.c  | 1 -
 drivers/i2c/busses/i2c-mpc.c| 4 +---
 drivers/i2c/busses/i2c-mt65xx.c | 4 +---
 drivers/i2c/busses/i2c-mxs.c| 1 -
 drivers/i2c/busses/i2c-nforce2.c| 1 -
 drivers/i2c/busses/i2c-nomadik.c| 4 +---
 drivers/i2c/busses/i2c-ocores.c | 4 +---
 drivers/i2c/busses/i2c-octeon.c | 4 +---
 drivers/i2c/busses/i2c-omap.c   | 4 +---
 drivers/i2c/busses/i2c-piix4.c  | 1 -
 drivers/i2c/busses/i2c-pmcmsp.c | 4 +---
 drivers/i2c/busses/i2c-pnx.c| 4 +---
 drivers/i2c/busses/i2c-puv3.c   | 5 +
 drivers/i2c/busses/i2c-pxa.c| 4 +---
 drivers/i2c/busses/i2c-rcar.c   | 4 +---
 drivers/i2c/busses/i2c-riic.c   | 4 +---
 drivers/i2c/busses/i2c-rk3x.c   | 4 +---
 drivers/i2c/busses/i2c-s3c2410.c| 1 -
 drivers/i2c/busses/i2c-sh7760.c | 4 +---
 drivers/i2c/busses/i2c-sh_mobile.c  | 1 -
 drivers/i2c/busses/i2c-sirf.c   | 4 +---
 drivers/i2c/busses/i2c-st.c | 4 +---
 drivers/i2c/busses/i2c-stu300.c | 5 +
 drivers/i2c/busses/i2c-tegra.c  | 4 +---
 drivers/i2c/busses/i2c-uniphier-f.c | 7 +--
 drivers/i2c/busses/i2c-uniphier.c   | 7 +--
 drivers/i2c/busses/i2c-wmt.c| 4 +---
 drivers/i2c/busses/i2c-xgene-slimpro.c  | 1 -
 drivers/i2c/busses/i2c-xiic.c   | 1 -
 drivers/i2c/busses/i2c-xlp9xx.c | 4 +---
 drivers/i2c/busses/i2c-xlr.c| 4 +---
 55 files changed, 44 insertions(+), 161 deletions(-)

diff --git a/drivers/i2c/busses/i2c-amd756.c b/drivers/i2c/busses/i2c-amd756.c
index 6c7113d990f882..274908cd1fdeab 100644
--- a/drivers/i2c/busses/i2c-amd756.c
+++ b/drivers/i2c/busses/i2c-amd756.c
@@ -378,11 +378,8 @@ static int amd756_probe(struct pci_dev *pdev, const struct 
pci_device_id *id)
 amd756_ioport);
 
error = i2c_add_adapter(_smbus);
-   if (error) {
-   dev_err(>dev,
-   "Adapter registration failed, module not inserted\n");
+   if (error)
goto out_err;
-   }
 
return 0;
 
diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index f23372669f770f..03a519d29616d7 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -1118,8 +1118,6 @@ static int at91_twi_probe(struct platform_device *pdev)
 
rc = i2c_add_numbered_adapter(>adapter);
if (rc) {
-   dev_err(dev->dev, "Adapter %s registration failed\n",
-   dev->adapter.name);
clk_disable_unprepare(dev->clk);
 
pm_runtime_disable(dev->dev);
diff --git a/drivers/i2c/busses/i2c-axxia.c b/drivers/i2c/busses/i2c-axxia.c
index c335cc7852f94e..d3bcaf4ab095d0 100644
--- a/drivers/i2c/busses/i2c-axxia.c
+++ b/drivers/i2c/busses/i2c-axxia.c
@@ -558,13 +558,7 @@ static int axxia_i2c_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, idev);
 
-   ret = i2c_add_adapter(>adapter);
-   if (ret) {
-   dev_err(>dev, "failed to add adapter\n");
-   return ret;
-   }
-
-   return 0;
+   return i2c_add_adapter(>adapter);
 }
 
 static int axxia_i2c_remove(struct platform_device *pdev)
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c 
b/drivers/i2c/busses/i2c-bcm-iproc.c
index 19c843828fe2ca..8e3477f9297eda 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -488,13 +488,7 @@ static int bcm_iproc_i2c_probe(struct platform_device 
*pdev)
adap->dev.parent = >dev;
adap->dev.of_node = pdev->dev.of_node;

Re: [PATCH] i2c: don't print error when adding adapter fails

[Guenter Roeck]

On 08/09/2016 04:36 AM, Wolfram Sang wrote:

The core will do this for us now.

Signed-off-by: Wolfram Sang 
---

[ ... ]


diff --git a/drivers/i2c/busses/i2c-uniphier-f.c 
b/drivers/i2c/busses/i2c-uniphier-f.c
index aeead0d27d1007..64318e69089439 100644
--- a/drivers/i2c/busses/i2c-uniphier-f.c
+++ b/drivers/i2c/busses/i2c-uniphier-f.c
@@ -550,15 +550,10 @@ static int uniphier_fi2c_probe(struct platform_device 
*pdev)
}

ret = i2c_add_adapter(>adap);
-   if (ret) {
-   dev_err(dev, "failed to add I2C adapter\n");
-   goto err;
-   }
-
-err:
if (ret)
clk_disable_unprepare(priv->clk);

+ err:


You sure about that one ? It leaves the clock enabled in some of the error 
paths.


return ret;
 }

diff --git a/drivers/i2c/busses/i2c-uniphier.c 
b/drivers/i2c/busses/i2c-uniphier.c
index 475a5eb514e215..94f64cccfdef08 100644
--- a/drivers/i2c/busses/i2c-uniphier.c
+++ b/drivers/i2c/busses/i2c-uniphier.c
@@ -407,15 +407,10 @@ static int uniphier_i2c_probe(struct platform_device 
*pdev)
}

ret = i2c_add_adapter(>adap);
-   if (ret) {
-   dev_err(dev, "failed to add I2C adapter\n");
-   goto err;
-   }
-
-err:
if (ret)
clk_disable_unprepare(priv->clk);

+ err:


Same as above.

Note: I dropped all individuals from Cc:; my mailer refused to accept the reply 
because there
were too many.

Guenter


return ret;
 }

Re: [PATCH 1/7] ima: on soft reboot, restore the measurement list

[Thiago Jung Bauermann]

Am Dienstag, 09 August 2016, 09:01:13 schrieb Mimi Zohar:
> On Tue, 2016-08-09 at 20:59 +1000, Michael Ellerman wrote:
> > Mimi Zohar  writes:
> > > diff --git a/security/integrity/ima/ima.h
> > > b/security/integrity/ima/ima.h
> > > index b5728da..84e8d36 100644
> > > --- a/security/integrity/ima/ima.h
> > > +++ b/security/integrity/ima/ima.h
> > > @@ -102,6 +102,13 @@ struct ima_queue_entry {
> > > 
> > >  };
> > >  extern struct list_head ima_measurements;/* list of all 
measurements
> > >  */
> > > 
> > > +/* Some details preceding the binary serialized measurement list */
> > > +struct ima_kexec_hdr {
> > > + unsigned short version;
> > > + unsigned long buffer_size;
> > > + unsigned long count;
> > > +} __packed;
> > > +
> > 
> > Am I understanding it correctly that this structure is passed between
> > kernels?
> Yes, the header prefixes the measurement list, which is being passed on
> the same computer to the next kernel.  Could the architecture (eg.
> LE/BE) change between soft re-boots?

Yes. I am able to boot a BE kernel from an LE kernel with my patches. 
Whether we want to support that or not is another question...
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: [PATCH 1/7] ima: on soft reboot, restore the measurement list

[Mimi Zohar]

On Tue, 2016-08-09 at 20:59 +1000, Michael Ellerman wrote:
> Mimi Zohar  writes:
> 
> > diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> > index b5728da..84e8d36 100644
> > --- a/security/integrity/ima/ima.h
> > +++ b/security/integrity/ima/ima.h
> > @@ -102,6 +102,13 @@ struct ima_queue_entry {
> >  };
> >  extern struct list_head ima_measurements;  /* list of all measurements */
> >  
> > +/* Some details preceding the binary serialized measurement list */
> > +struct ima_kexec_hdr {
> > +   unsigned short version;
> > +   unsigned long buffer_size;
> > +   unsigned long count;
> > +} __packed;
> > +
> 
> Am I understanding it correctly that this structure is passed between kernels?

Yes, the header prefixes the measurement list, which is being passed on
the same computer to the next kernel.  Could the architecture (eg.
LE/BE) change between soft re-boots?

> If so it's an ABI and should use types with well defined sizes, as if it was
> going out to userspace, shouldn't it?

Ok

Mimi

Re: [PATCH] i2c: don't print error when adding adapter fails

[Thierry Reding]

On Tue, Aug 09, 2016 at 01:36:17PM +0200, Wolfram Sang wrote:
[...]
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index b126dbaa47e370..d9979da11485ae 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -932,10 +932,8 @@ static int tegra_i2c_probe(struct platform_device *pdev)
>   i2c_dev->adapter.dev.of_node = pdev->dev.of_node;
>  
>   ret = i2c_add_numbered_adapter(_dev->adapter);
> - if (ret) {
> - dev_err(>dev, "Failed to add I2C adapter\n");
> + if (ret)
>   goto disable_div_clk;
> - }
>  
>   return 0;
>  

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature

Re: [PATCH] i2c: don't print error when adding adapter fails

[Heiko Stübner]

Am Dienstag, 9. August 2016, 13:36:17 schrieb Wolfram Sang:
> The core will do this for us now.
> 
> Signed-off-by: Wolfram Sang 
> ---

[...]

> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
> index 2bc8b01153d619..3b87afe82f6394 100644
> --- a/drivers/i2c/busses/i2c-rk3x.c
> +++ b/drivers/i2c/busses/i2c-rk3x.c
> @@ -1303,10 +1303,8 @@ static int rk3x_i2c_probe(struct platform_device
> *pdev) rk3x_i2c_adapt_div(i2c, clk_rate);
> 
>   ret = i2c_add_adapter(>adap);
> - if (ret < 0) {
> - dev_err(>dev, "Could not register adapter\n");
> + if (ret < 0)
>   goto err_clk_notifier;
> - }
> 
>   dev_info(>dev, "Initialized RK3xxx I2C bus at %p\n", i2c->regs);

for Rockchip
Acked-by: Heiko Stuebner 

[PATCH] powerpc/Makefile: Use cflags-y/aflags-y for setting endian options

[Michael Ellerman]

When we introduced the little endian support, we added the endian flags
to CC directly using override. I don't know the history of why we did
that, I suspect no one does.

Although this mostly works, it has one bug, which is that CROSS32CC
doesn't get -mbig-endian. That means when the compiler is little endian
by default and the user is building big endian, vdso32 is incorrectly
compiled as little endian and the kernel fails to build.

Instead we can add the endian flags to cflags-y/aflags-y, and then
append those to KBUILD_CFLAGS/KBUILD_AFLAGS.

This has the advantage of being 1) less ugly, 2) the documented way of
adding flags in the arch Makefile and 3) it fixes building vdso32 with a
LE toolchain.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/Makefile | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index ca254546cd05..1934707bf321 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -66,29 +66,28 @@ endif
 UTS_MACHINE := $(OLDARCH)
 
 ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
-override CC+= -mlittle-endian
-ifneq ($(cc-name),clang)
-override CC+= -mno-strict-align
-endif
-override AS+= -mlittle-endian
 override LD+= -EL
-override CROSS32CC += -mlittle-endian
 override CROSS32AS += -mlittle-endian
 LDEMULATION:= lppc
 GNUTARGET  := powerpcle
 MULTIPLEWORD   := -mno-multiple
 KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-save-toc-indirect)
 else
-ifeq ($(call cc-option-yn,-mbig-endian),y)
-override CC+= -mbig-endian
-override AS+= -mbig-endian
-endif
 override LD+= -EB
 LDEMULATION:= ppc
 GNUTARGET  := powerpc
 MULTIPLEWORD   := -mmultiple
 endif
 
+cflags-$(CONFIG_CPU_BIG_ENDIAN)+= $(call 
cc-option,-mbig-endian)
+cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian
+ifneq ($(cc-name),clang)
+  cflags-$(CONFIG_CPU_LITTLE_ENDIAN)   += -mno-strict-align
+endif
+
+aflags-$(CONFIG_CPU_BIG_ENDIAN)+= $(call 
cc-option,-mbig-endian)
+aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian
+
 ifeq ($(HAS_BIARCH),y)
 override AS+= -a$(CONFIG_WORD_SIZE)
 override LD+= -m elf$(CONFIG_WORD_SIZE)$(LDEMULATION)
@@ -232,6 +231,9 @@ cpu-as-$(CONFIG_E200)   += -Wa,-me200
 KBUILD_AFLAGS += $(cpu-as-y)
 KBUILD_CFLAGS += $(cpu-as-y)
 
+KBUILD_AFLAGS += $(aflags-y)
+KBUILD_CFLAGS += $(cflags-y)
+
 head-y := 
arch/powerpc/kernel/head_$(CONFIG_WORD_SIZE).o
 head-$(CONFIG_8xx) := arch/powerpc/kernel/head_8xx.o
 head-$(CONFIG_40x) := arch/powerpc/kernel/head_40x.o
-- 
2.7.4

Re: [PATCH 0/7] ima: carry the measurement list across kexec

[Mimi Zohar]

On Tue, 2016-08-09 at 15:19 +1000, Balbir Singh wrote:
> 
> On 04/08/16 22:24, Mimi Zohar wrote:
> > The TPM PCRs are only reset on a hard reboot.  In order to validate a
> > TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list
> > of the running kernel must be saved and then restored on the subsequent
> > boot.
> > 
> > The existing securityfs binary_runtime_measurements file conveniently
> > provides a serialized format of the IMA measurement list. This patch
> > set serializes the measurement list in this format and restores it.
> > 
> > This patch set pre-req's Thiago Bauermann's "kexec_file: Add buffer
> > hand-over for the next kernel" patch set* for actually carrying the
> > serialized measurement list across the kexec.
> > 
> > Mimi
> > 
> 
> Hi, Mimi
> 
> I am trying to convince myself of the security of the solution. I asked
> Thiago as well, but may be I am be lagging behind in understanding.
> 
> We trust the kernel to hand over PCR values of the old kernel (which
> cannot be validated) to the IMA subsystem in the new kernel for storage.
> I guess the idea is for ima_add_boot_aggregate to do the right thing?
> How do we validate what the old kernel is giving us? Why do we care for
> the old measurement list? Is it still of significance in the new kernel?
> 

Hi Balbir,

To validate the hardware TPM PCR values requires walking the measurement
list simulating the TPM extend operation.  The resulting values should
match the hardware TPM PCRs.

In the case of a soft reboot, the TPM PCRs are not reset to 0, so all
the measurements of the running system, including those from previous
soft reboots, need to be included in the measurement list.   Without
these measurements, the simulated PCR values will not match the hardware
TPM PCR values.  Thus the need for this patch set.

Measurements can not be added/removed/changed in the measurement list
without it being detectable.

Mimi

Re: [PATCH] i2c: don't print error when adding adapter fails

[Uwe Kleine-König]

Hello Wolfram,

On Tue, Aug 09, 2016 at 01:36:17PM +0200, Wolfram Sang wrote:
> The core will do this for us now.

Would be nice to point out the relevant commit that changed the core in
the commit log.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [PATCH kernel 14/15] vfio/spapr_tce: Export container API for external users

[Alex Williamson]

On Tue, 9 Aug 2016 15:19:39 +1000
Alexey Kardashevskiy  wrote:

> On 09/08/16 02:43, Alex Williamson wrote:
> > On Wed,  3 Aug 2016 18:40:55 +1000
> > Alexey Kardashevskiy  wrote:
> >   
> >> This exports helpers which are needed to keep a VFIO container in
> >> memory while there are external users such as KVM.
> >>
> >> Signed-off-by: Alexey Kardashevskiy 
> >> ---
> >>  drivers/vfio/vfio.c | 30 ++
> >>  drivers/vfio/vfio_iommu_spapr_tce.c | 16 +++-
> >>  include/linux/vfio.h|  6 ++
> >>  3 files changed, 51 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> >> index d1d70e0..baf6a9c 100644
> >> --- a/drivers/vfio/vfio.c
> >> +++ b/drivers/vfio/vfio.c
> >> @@ -1729,6 +1729,36 @@ long vfio_external_check_extension(struct 
> >> vfio_group *group, unsigned long arg)
> >>  EXPORT_SYMBOL_GPL(vfio_external_check_extension);
> >>  
> >>  /**
> >> + * External user API for containers, exported by symbols to be linked
> >> + * dynamically.
> >> + *
> >> + */
> >> +struct vfio_container *vfio_container_get_ext(struct file *filep)
> >> +{
> >> +  struct vfio_container *container = filep->private_data;
> >> +
> >> +  if (filep->f_op != _fops)
> >> +  return ERR_PTR(-EINVAL);
> >> +
> >> +  vfio_container_get(container);
> >> +
> >> +  return container;
> >> +}
> >> +EXPORT_SYMBOL_GPL(vfio_container_get_ext);
> >> +
> >> +void vfio_container_put_ext(struct vfio_container *container)
> >> +{
> >> +  vfio_container_put(container);
> >> +}
> >> +EXPORT_SYMBOL_GPL(vfio_container_put_ext);
> >> +
> >> +void *vfio_container_get_iommu_data_ext(struct vfio_container *container)
> >> +{
> >> +  return container->iommu_data;
> >> +}
> >> +EXPORT_SYMBOL_GPL(vfio_container_get_iommu_data_ext);
> >> +
> >> +/**
> >>   * Sub-module support
> >>   */
> >>  /*
> >> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c 
> >> b/drivers/vfio/vfio_iommu_spapr_tce.c
> >> index 3594ad3..fceea3d 100644
> >> --- a/drivers/vfio/vfio_iommu_spapr_tce.c
> >> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
> >> @@ -1331,6 +1331,21 @@ const struct vfio_iommu_driver_ops 
> >> tce_iommu_driver_ops = {
> >>.detach_group   = tce_iommu_detach_group,
> >>  };
> >>  
> >> +struct iommu_table *vfio_container_spapr_tce_table_get_ext(void 
> >> *iommu_data,
> >> +  u64 offset)
> >> +{
> >> +  struct tce_container *container = iommu_data;
> >> +  struct iommu_table *tbl = NULL;
> >> +
> >> +  if (tce_iommu_find_table(container, offset, ) < 0)
> >> +  return NULL;
> >> +
> >> +  iommu_table_get(tbl);
> >> +
> >> +  return tbl;
> >> +}
> >> +EXPORT_SYMBOL_GPL(vfio_container_spapr_tce_table_get_ext);
> >> +
> >>  static int __init tce_iommu_init(void)
> >>  {
> >>return vfio_register_iommu_driver(_iommu_driver_ops);
> >> @@ -1348,4 +1363,3 @@ MODULE_VERSION(DRIVER_VERSION);
> >>  MODULE_LICENSE("GPL v2");
> >>  MODULE_AUTHOR(DRIVER_AUTHOR);
> >>  MODULE_DESCRIPTION(DRIVER_DESC);
> >> -
> >> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> >> index 0ecae0b..1c2138a 100644
> >> --- a/include/linux/vfio.h
> >> +++ b/include/linux/vfio.h
> >> @@ -91,6 +91,12 @@ extern void vfio_group_put_external_user(struct 
> >> vfio_group *group);
> >>  extern int vfio_external_user_iommu_id(struct vfio_group *group);
> >>  extern long vfio_external_check_extension(struct vfio_group *group,
> >>  unsigned long arg);
> >> +extern struct vfio_container *vfio_container_get_ext(struct file *filep);
> >> +extern void vfio_container_put_ext(struct vfio_container *container);
> >> +extern void *vfio_container_get_iommu_data_ext(
> >> +  struct vfio_container *container);
> >> +extern struct iommu_table *vfio_container_spapr_tce_table_get_ext(
> >> +  void *iommu_data, u64 offset);
> >>  
> >>  /*
> >>   * Sub-module helpers  
> > 
> > 
> > I think you need to take a closer look of the lifecycle of a container,
> > having a reference means the container itself won't go away, but only
> > having a group set within that container holds the actual IOMMU
> > references.  container->iommu_data is going to be NULL once the
> > groups are lost.  Thanks,  
> 
> 
> Container owns the iommu tables and this is what I care about here, groups
> attached or not - this is handled separately via IOMMU group list in a
> specific iommu_table struct, these groups get detached from iommu_table
> when they are removed from a container.

The container doesn't own anything, the container is privileged by the
groups being attached to it.  When groups are closed, they detach from
the container and once the container group list is empty the iommu
backend is released and iommu_data is NULL.  A container reference
doesn't give you what you're looking for.  It implies nothing about the
iommu backend.

Re: 4.8.0-rc1: Invalid memory access at $SRR0: 0140f86c $SRR1: 00003030

[Benjamin Herrenschmidt]

On Tue, 2016-08-09 at 02:06 -0700, Christian Kujau wrote:
> On Mon, 8 Aug 2016, Christian Kujau wrote:
> > 
> > while trying to upgrade this PowerBook G4 from 4.7-rc7 to 4.8-rc1,
> > it's 
> > unable to boot the Yaboot (v1.3.16 from Debian/stable) boot loader:

There should already be a fix for that:

http://patchwork.ozlabs.org/patch/654560/

It should be in Michael's tree if not already in Linus.

Cheers,
Ben.

> > 
> > copying OF device tree...
> > Building dt strings...
> > Building dt stucture...
> > Device tree strings 0x01e72000 -> 0x01e73615
> > Device tree struct  0x01e74000 -> 0x01e7e000
> > Quiescing Open Firmware...
> > Bootng Linux via __start()...
> > 
> > Invalid memory access at $SRR0: 0140f86c  $SRR1: 3030
> > 
> > Apple PowerBook6,8 4.9.0f0 BootROM built on 01/10/05 at 10:39:14
> > [...]
> > 
> >  ok
> > 0:> _
> > 
> > 
> > Going back to 4.7-rc7 (w/o installing Yaboot again) works just
> > fine. The 
> > config is mostly the same (used "make oldconfig" from 4.7), but
> > I've said 
> > YES to CONFIG_SLAB_FREELIST_RANDOM - could this be causing the
> > boot 
> > failure? Full .config and screen shot: http://nerdbynature.de/bits/
> > 4.8.0-rc1/
> 
> A git-bisect led me to:
> 
> =
> commit 9402c684613163888714df0955fa1f17142b08bf
> Author: Benjamin Herrenschmidt 
> Date:   Tue Jul 5 15:03:41 2016 +1000
> 
> powerpc: Factor do_feature_fixup calls
> 
> 32 and 64-bit do a similar set of calls early on, we move it all
> to
> a single common function to make the boot code more readable.
> 
> Signed-off-by: Benjamin Herrenschmidt 
> Signed-off-by: Michael Ellerman 
> =
> 
> But I'm unable to revert just this patch:
> 
> $ git revert 9402c684613163888714df0955fa1f17142b08bf
> error: could not revert 9402c68... powerpc: Factor do_feature_fixup
> calls
> hint: after resolving the conflicts, mark the corrected paths
> 
> The bisect-log:
> 
> =
> $ git bisect log
> git bisect start '--' 'arch/powerpc'
> # good: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
> git bisect good 523d939ef98fd712632d93a5a2b588e477a7565e
> # bad: [29b4817d4018df78086157ea3a55c1d9424a7cfc] Linux 4.8-rc1
> git bisect bad 29b4817d4018df78086157ea3a55c1d9424a7cfc
> # bad: [3808a88985b4f5f5e947c364debce4441a380fb8] powerpc: Move FW
> feature probing out of pseries probe()
> git bisect bad 3808a88985b4f5f5e947c364debce4441a380fb8
> # good: [a203658b5ed37c11e5016d3fbbbab9ce018c1b78] powerpc/opal: Wake
> up kopald polling thread before waiting for events
> git bisect good a203658b5ed37c11e5016d3fbbbab9ce018c1b78
> # good: [0dfffb48cecd8f84c6e649baee9bacd9be925734] powerpc/powernv:
> abstraction for saving SPRs before entering deep idle states
> git bisect good 0dfffb48cecd8f84c6e649baee9bacd9be925734
> # good: [66c570f545e056babdd9510595ce762dcedadd71] powerpc/mm: use
> _raw variant of page table accessors
> git bisect good 66c570f545e056babdd9510595ce762dcedadd71
> # good: [c2ca9f6b4cc4c45eb598b24b8b06beee668052d5] powerpc/powernv:
> Fix pci-cxl.c build when CONFIG_MODULES=n
> git bisect good c2ca9f6b4cc4c45eb598b24b8b06beee668052d5
> # good: [4c91bd6eeabb004f283db8a6854b134e2a2de1bc] powerpc: Merge the
> RELOCATABLE config entries for ppc32 and ppc64
> git bisect good 4c91bd6eeabb004f283db8a6854b134e2a2de1bc
> # bad: [c4bd6cb87c9e28a7d9f4a97db5a06cc538eb5e48] powerpc: Move 64-
> bit feature fixup earlier
> git bisect bad c4bd6cb87c9e28a7d9f4a97db5a06cc538eb5e48
> # bad: [9402c684613163888714df0955fa1f17142b08bf] powerpc: Factor
> do_feature_fixup calls
> git bisect bad 9402c684613163888714df0955fa1f17142b08bf
> # good: [27d1149667352772240655b65372a4294f992ea7] powerpc/32: Remove
> RELOCATABLE_PPC32
> git bisect good 27d1149667352772240655b65372a4294f992ea7
> # first bad commit: [9402c684613163888714df0955fa1f17142b08bf]
> powerpc: Factor do_feature_fixup calls
> =
> 
> 
> HTH,
> Christian.

Re: [PATCH] i2c: don't print error when adding adapter fails

[Peter Korsgaard]

> "Wolfram" == Wolfram Sang  writes:

 > The core will do this for us now.
 > Signed-off-by: Wolfram Sang 
 > ---
 >  drivers/i2c/busses/i2c-ocores.c | 4 +---

For i2c-ocores.c:

Acked-by: Peter Korsgaard 

-- 
Bye, Peter Korsgaard

Re: powerpc/eeh: trivial fix to non-conventional PCI address output on EEH log

[Michael Ellerman]

On Fri, 2016-22-07 at 17:05:29 UTC, "Guilherme G. Piccoli" wrote:
> This is a very minor/trivial fix for the output of PCI address on EEH logs.
> The PCI address on "OF node" field currently is using ":" as a separator
> for the function, but the usual separator is ".". This patch changes the
> separator for dot, so the PCI address is printed as usual.
> 
> No functional changes were introduced.
> 
> Signed-off-by: Guilherme G. Piccoli 
> Reviewed-by: Gavin Shan 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/10560b9afc8abf349843dff88c

cheers

Re: powerpc/xics: Properly set Edge/Level type and enable resend

[Michael Ellerman]

On Tue, 2016-02-08 at 02:39:43 UTC, Benjamin Herrenschmidt wrote:
> This sets the type of the interrupt appropriately. We set it as follow:
> 
>  - If not mapped from the device-tree, we use edge. This is the case
> of the virtual interrupts and PCI MSIs for example.
> 
>  - If mapped from the device-tree and #interrupt-cells is 2 (PAPR
> compliant), we use the second cell to set the appropriate type
> 
>  - If mapped from the device-tree and #interrupt-cells is 1 (current
> OPAL on P8 does that), we assume level sensitive since those are
> typically going to be the PSI LSIs which are level sensitive.
> 
> Additionally, we mark the interrupts requested via the opal_interrupts
> property all level. This is a bit fishy but the best we can do until we
> fix OPAL to properly expose them with a complete descriptor. It is also
> correct for the current HW anyway as OPAL interrupts are currently PCI
> error and PSI interrupts which are level.
> 
> Finally now that edge interrupts are properly identified, we can enable
> CONFIG_HARDIRQS_SW_RESEND which will make the core re-send them if
> they occur while masked, which some drivers rely upon.
> 
> This fixes issues with lost interrupts on some Mellanox adapters.
> 
> Signed-off-by: Benjamin Herrenschmidt 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/880a3d6afd068682d6386a0528

cheers

Re: ppc/cell: missing error code in spufs_mkgang()

[Michael Ellerman]

On Thu, 2016-04-08 at 05:37:03 UTC, Dan Carpenter wrote:
> We should return -ENOMEM if alloc_spu_gang() fails.
> 
> Signed-off-by: Dan Carpenter 
> Acked-by: Arnd Bergmann 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/54a94fcf2f00c9deb9491d5ab2

cheers

Re: powerpc: vdso: Add missing include file

[Michael Ellerman]

On Sat, 2016-06-08 at 22:54:12 UTC, Guenter Roeck wrote:
> Some powerpc builds fail with the following buld error.
> 
> In file included from ./arch/powerpc/include/asm/mmu_context.h:11:0,
>  from arch/powerpc/kernel/vdso.c:28:
> arch/powerpc/include/asm/cputhreads.h: In function 'get_tensr':
> arch/powerpc/include/asm/cputhreads.h:101:2: error:
>   implicit declaration of function 'cpu_has_feature'
> 
> Fixes: b92a226e5284 ("powerpc: Move cpu_has_feature() to a separate file")
> Signed-off-by: Guenter Roeck 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/546c4402c57497a6ffdf5373af

cheers

Re: powerpc: Fix unused function warning 'lmb_to_memblock'

[Michael Ellerman]

On Mon, 2016-01-08 at 06:32:51 UTC, Alastair D'Silva wrote:
> From: Alastair D'Silva 
> 
> This patch fixes the following warning:
> arch/powerpc/platforms/pseries/hotplug-memory.c:323:29: error: 
> 'lmb_to_memblock' defined but not used [-Werror=unused-function]
> static struct memory_block *lmb_to_memblock(struct of_drconf_cell *lmb)
>^~~
> 
> The only consumer of this function is 'dlpar_remove_lmb', which is
> enabled with CONFIG_MEMORY_HOTREMOVE, so move it into the same
> ifdef block.

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/9dc512819e4b723856773f5a01

cheers

Re: powernv: Load correct TOC pointer while waking up from winkle.

[Michael Ellerman]

On Fri, 2016-05-08 at 13:43:12 UTC, Mahesh Salgaonkar wrote:
> From: Mahesh Salgaonkar 
> 
> The function pnv_restore_hyp_resource() loads the TOC into r2 from
> the invalid PACA pointer before fixing r13 value. This do not affect
> POWER ISA 3.0 but it does have an impact on POWER ISA 2.07 or less
> leading CPU to get stuck forever.
> 
>   login: [  471.830433] Processor 120 is stuck.
> 
> 
> This can be easily reproducible using following steps:
> - Turn off SMT
>   $ ppc64_cpu --smt=off
> - offline/online any online cpu (Thread 0 of any core which is online)
>   $ echo 0 > /sys/devices/system/cpu/cpu/online
>   $ echo 1 > /sys/devices/system/cpu/cpu/online
> 
> For POWER ISA 2.07 or less, the last bit of HSPRG0 is set indicating
> that thread is waking up from winkle. Hence, the last bit of HSPRG0(r13)
> needs to be clear before accessing it as PACA to avoid loading invalid
> values from invalid PACA pointer.
> 
> Fix this by loading TOC after r13 register is corrected.
> 
> Signed-off-by: Mahesh Salgaonkar 

Applied to powerpc fixes, thanks.

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

cheers

Re: pasemi: Fix coherent_dma_mask for dma engine

[Michael Ellerman]

On Wed, 2016-27-07 at 14:41:29 UTC, Darren Stevens wrote:
> Commit 817820b0226a ("powerpc/iommu: Support "hybrid" iommu/direct DMA
> ops for coherent_mask < dma_mask) adds a check of coherent_dma_mask
> for dma allocations.
> Unfortunately current PASemi code does not set this value for the DMA
> engine, which ends up with the default value of 0x, the result 
> is on a PASemi system with >2Gb ram and iommu enabled the the onboard 
> ethernet stops working due to an inability to allocate memory.
> Add an initialisation to pci_dma_dev_setup_pasemi()
>   
> Signed-off-by: Darren Stevens 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/416f37d0816b9720b8227953e5

cheers

Re: [kernel, 04/15] powerpc/powernv/ioda: Fix TCE invalidate to work in real mode again

[Michael Ellerman]

On Wed, 2016-03-08 at 08:40:45 UTC, Alexey Kardashevskiy wrote:
> "powerpc/powernv/pci: Rework accessing the TCE invalidate register"
> broke TCE invalidation on IODA2/PHB3 for real mode.
> 
> This makes invalidate work again.
> 
> Fixes: fd141d1a99a3
> Signed-off-by: Alexey Kardashevskiy 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/4d9021957b5218310e28767f25

cheers

Re: powerpc/pci: Fix endian bug in fixed PHB numbering

[Michael Ellerman]

On Tue, 2016-09-08 at 06:55:41 UTC, Michael Ellerman wrote:
> The recent commit 63a72284b159 ("powerpc/pci: Assign fixed PHB number
> based on device-tree properties"), added code to read a 64-bit property
> from the device tree, and if not found read a 32-bit property (reg).
> 
> There was a bug in the 32-bit case, on big endian machines, due to the
> use of the 64-bit value to read the 32-bit property. The cast of 
> means we end up writing to the high 32-bit of prop, leaving the low
> 32-bits containing whatever junk was on the stack.
> 
> If that junk value was non-zero, and < MAX_PHBS, we would end up using
> it as the PHB id. This results in users seeing what appear to be random
> PHB ids.
> 
> Fix it by reading into a u32 property and then assigning that to the
> u64 value, letting the CPU do the correct conversions for us.
> 
> Fixes: 63a72284b159 ("powerpc/pci: Assign fixed PHB number based on 
> device-tree properties")
> Signed-off-by: Michael Ellerman 

Applied to powerpc fixes.

https://git.kernel.org/powerpc/c/61e8a0d5a0270b91581f6c7150

cheers

Re: [v2] cxl: Use fixed width predefined types in data structure.

[Michael Ellerman]

On Fri, 2016-05-08 at 12:02:00 UTC, Philippe Bergheaud wrote:
> This patch fixes a regression introduced by commit b810253.
> 
> It substitutes the type __u8 to u8 in the uapi header cxl.h,
> because the latter is not always defined in userland build
> environments, in particular when cross-compiling libcxl on
> x86_64 linux machines (RHEL6.7 and Ubuntu 16.04).
> 
> This patch also changes the size of the field data_size, and
> makes it constant, to support 32-bit userland applications
> running on big-endian ppc64 kernels transparently.
> 
> This breaks the (young) API that has been merged in v4.8.
> 
> Signed-off-by: Philippe Bergheaud 

Applied to powerpc fixes, thanks.

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

cheers

Re: cxl: fix sparse warnings

[Michael Ellerman]

On Fri, 2016-22-07 at 09:01:36 UTC, Andrew Donnellan wrote:
> Make native_irq_wait() static and use NULL rather than 0 to initialise
> phb->cfg_data in cxl_pci_vphb_add() to remove sparse warnings.
> 
> Signed-off-by: Andrew Donnellan 
> Reviewed-by: Matthew R. Ochs 
> Acked-by: Ian Munsie 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/6fd40f192a9dba391b2d84882f

cheers

Re: cxl: fix NULL dereference in cxl_context_init() on PowerVM guests

[Michael Ellerman]

On Thu, 2016-28-07 at 05:39:41 UTC, Andrew Donnellan wrote:
> Commit f67a6722d650 ("cxl: Workaround PE=0 hardware limitation in Mellanox
> CX4") added a "min_pe" field to struct cxl_service_layer_ops, to allow us
> to work around a Mellanox CX-4 hardware limitation.
> 
> When allocating the PE number in cxl_context_init(), we read from
> ctx->afu->adapter->native->sl_ops->min_pe to get the minimum PE number.
> Unsurprisingly, in a PowerVM guest ctx->afu->adapter->native is NULL, and
> guests don't have a cxl_service_layer_ops struct anywhere.
> 
> Move min_pe from struct cxl_service_layer_ops to struct cxl so it's
> accessible in both native and PowerVM environments. For the Mellanox CX-4,
> set the min_pe value in set_sl_ops().
> 
> Fixes: f67a6722d650 ("cxl: Workaround PE=0 hardware limitation in Mellanox 
> CX4")
> Reported-by: Frederic Barrat 
> Signed-off-by: Andrew Donnellan 
> Acked-by: Ian Munsie 
> Reviewed-by: Frederic Barrat 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/164793379ad3b7ef5fc5a28260

cheers

Re: crypto: crc32c-vpmsum - Convert to CPU feature based module autoloading

[Michael Ellerman]

On Thu, 2016-04-08 at 06:38:15 UTC, Anton Blanchard wrote:
> From: Anton Blanchard 
> 
> This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure
> to automatically load the crc32c-vpmsum module if the CPU supports
> it.
> 
> Signed-off-by: Anton Blanchard 

Applied to powerpc fixes, thanks.

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

cheers

Re: [v3, 2/2] powernv: Fix MCE handler to avoid trashing CR0/CR1 registers.

[Michael Ellerman]

On Fri, 2016-05-08 at 12:04:13 UTC, Mahesh Salgaonkar wrote:
> From: Mahesh Salgaonkar 
> 
> The current implementation of MCE early handling modifies CR0/1 registers
> without saving its old values. Fix this by moving early check for
> powersaving mode to machine_check_handle_early().
> 
> The power architecture 2.06 or later allows the possibility of getting
> machine check while in nap/sleep/winkle. The last bit of HSPRG0 is set
> to 1, if thread is woken up from winkle. Hence, clear the last bit of
> HSPRG0 (r13) before MCE handler starts using it as paca pointer.
> 
> Also, the current code always puts the thread into nap state irrespective
> of whatever idle state it woke up from. Fix that by looking at
> paca->thread_idle_state and put the thread back into same state where it
> came from.
> 
> Reported-by: Paul Mackerras 
> Signed-off-by: Mahesh Salgaonkar 
> Reviewed-by: Shreyas B. Prabhu 

Applied to powerpc fixes, thanks.

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

cheers

Re: [v3,1/2] powernv: Move IDLE_STATE_ENTER_SEQ macro to cpuidle.h

[Michael Ellerman]

On Fri, 2016-05-08 at 12:04:04 UTC, Mahesh Salgaonkar wrote:
> From: Mahesh Salgaonkar 
> 
> Move IDLE_STATE_ENTER_SEQ macro to cpuidle.h so that MCE handler changes
> in subsequent patch can use it.
> 
> No functionality change.
> 
> Signed-off-by: Mahesh Salgaonkar 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/98d8821a47f3fd7354d3ab87ad

cheers

Re: [PATCH] powerpc/pci: Only do fixed PHB numbering on powernv

[Guilherme G. Piccoli]

On 08/09/2016 01:44 AM, Michael Ellerman wrote:

"Guilherme G. Piccoli"  writes:

On 08/08/2016 09:32 PM, Michael Ellerman wrote:

"Guilherme G. Piccoli"  writes:


(i) What is the specific issue? Do you have some logs or at least a
"high-level" description of the problem in Xorg? I took a look in its
code and PCI domain is coded as u16, which is correct/expected. So it
seems a subtle bug we should investigate and hopefully fix.


It was reported here:

https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-August/147062.html

It seems xorg just has a hard coded limit of 256 domains.


Thanks for the link Michael. I guess Xorg _had_ this limit in the
"past", since the function that was logged on error - xf86MapLegacyIO()
- was removed by a commit of 2014:

https://lists.x.org/archives/xorg-devel/2014-July/043224.html


Aha, nice work.

In fact it seems to be better than that, the array of domains was
removed in 2011 in:

   
https://cgit.freedesktop.org/xorg/xserver/commit/?id=858fbbb40d7c69540cd1fb5315cebf811c6e7b3f

Which is officially ancient history as far as I'm concerned.


Heheh great, good finding Michael!


(ii) Why is it related to the absence of pseries check?! You said this
was your bad, but as far as I understand, Xorg runs in pSeries too so
the issue should also be there heheh


Well yes I guess it would, if anyone had tested Xorg on pseries :)


We use to test Xorg on pSeries regularly; in fact, I made a quick test
today:

http://imgur.com/a/l1lP8

I forced the domain to be 0x as in the above image, and everything
worked fine.


Awesome.


I think for now I'm going to apply this, and we'll work out something
else later.


OK, I guess your solution is fine and solves the pasemi issue quickly,


No given the above info on xorg I'll drop this, and merge just the
endian fix.


Perfect, thanks!


cheers

Re: [PATCH] cxl: Set psl_fir_cntl to production environment value

[Frederic Barrat]

Le 09/08/2016 à 12:53, Michael Ellerman a écrit :

Frederic Barrat  writes:


Switch the setting of psl_fir_cntl from debug to production
environment recommended value. It mostly affects the PSL behavior when
an error is raised in psl_fir1/2.

Tested with cxlflash.


Is this a fix you want in rc1, or something for 4.9 ?


rc1 would be great. The cxlflash folks are eagerly waiting for it.

  Fred

Re: [PATCH 1/7] ima: on soft reboot, restore the measurement list

[Michael Ellerman]

Mimi Zohar  writes:

> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index b5728da..84e8d36 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -102,6 +102,13 @@ struct ima_queue_entry {
>  };
>  extern struct list_head ima_measurements;/* list of all measurements */
>  
> +/* Some details preceding the binary serialized measurement list */
> +struct ima_kexec_hdr {
> + unsigned short version;
> + unsigned long buffer_size;
> + unsigned long count;
> +} __packed;
> +

Am I understanding it correctly that this structure is passed between kernels?

If so it's an ABI and should use types with well defined sizes, as if it was
going out to userspace, shouldn't it?

cheers

Re: [PATCH] cxl: Set psl_fir_cntl to production environment value

[Michael Ellerman]

Frederic Barrat  writes:

> Switch the setting of psl_fir_cntl from debug to production
> environment recommended value. It mostly affects the PSL behavior when
> an error is raised in psl_fir1/2.
>
> Tested with cxlflash.

Is this a fix you want in rc1, or something for 4.9 ?

cheers

Re: [PATCH] powerpc/64be: must build vdso32 as BE on LE host

[Michael Ellerman]

Nicholas Piggin  writes:

> vdso32 should be built with `gcc -m32 --big-endian` when compiling a big
> endian kernel.

I think I have a better solution. Patch coming RSN.

cheers

Re: [PATCH] powerpc: rebuild vdsos correctly

[Michael Ellerman]

Nicholas Piggin  writes:

> On Tue, 09 Aug 2016 14:49:25 +1000
> Michael Ellerman  wrote:
>
>> Nicholas Piggin  writes:
>> 
>> > diff --git a/arch/powerpc/kernel/vdso32/Makefile 
>> > b/arch/powerpc/kernel/vdso32/Makefile
>> > index cbabd14..ae1f245 100644
>> > --- a/arch/powerpc/kernel/vdso32/Makefile
>> > +++ b/arch/powerpc/kernel/vdso32/Makefile
>> > @@ -39,14 +39,14 @@ $(obj)/%.so: $(obj)/%.so.dbg FORCE
>> >$(call if_changed,objcopy)
>> >  
>> >  # assembly rules for the .S files
>> > -$(obj-vdso32): %.o: %.S
>> > +$(obj-vdso32): %.o: %.S FORCE
>> >$(call if_changed_dep,vdso32as)
>> >  
>> >  # actual build commands
>> >  quiet_cmd_vdso32ld = VDSO32L $@
>> > -  cmd_vdso32ld = $(CROSS32CC) $(c_flags) -Wl,-T $^ -o $@
>> > +  cmd_vdso32ld = $(CROSS32CC) $(c_flags) -o $@ -Wl,-T$(filter 
>> > %.lds,$^) $(filter %.o,$^)
>> >  quiet_cmd_vdso32as = VDSO32A $@
>> > -  cmd_vdso32as = $(CROSS32CC) $(a_flags) -c -o $@ $<
>> > +  cmd_vdso32as = $(CROSS32CC) $(a_flags) -o $@ -c $<  
>> 
>> Are the two changes above required, they aren't obviously related.
>
> The vdso32ld change is required because otherwise "FORCE" gets put on
> the end of the command line. vdso32as... I think is not required. Want
> a new version without it?

Yeah either without it or just explaining why it's needed in the change log.

cheers

[PATCH stable 4.6 4/4] powerpc/tm: Avoid SLB faults in treclaim/trecheckpoint when RI=0

[Michael Ellerman]

From: Michael Neuling 

commit 190ce8693c23eae09ba5f303a83bf2fbeb6478b1 upstream.

Currently we have 2 segments that are bolted for the kernel linear
mapping (ie 0xc000... addresses). This is 0 to 1TB and also the kernel
stacks. Anything accessed outside of these regions may need to be
faulted in. (In practice machines with TM always have 1T segments)

If a machine has < 2TB of memory we never fault on the kernel linear
mapping as these two segments cover all physical memory. If a machine
has > 2TB of memory, there may be structures outside of these two
segments that need to be faulted in. This faulting can occur when
running as a guest as the hypervisor may remove any SLB that's not
bolted.

When we treclaim and trecheckpoint we have a window where we need to
run with the userspace GPRs. This means that we no longer have a valid
stack pointer in r1. For this window we therefore clear MSR RI to
indicate that any exceptions taken at this point won't be able to be
handled. This means that we can't take segment misses in this RI=0
window.

In this RI=0 region, we currently access the thread_struct for the
process being context switched to or from. This thread_struct access
may cause a segment fault since it's not guaranteed to be covered by
the two bolted segment entries described above.

We've seen this with a crash when running as a guest with > 2TB of
memory on PowerVM:

  Unrecoverable exception 4100 at c004f138
  Oops: Unrecoverable exception, sig: 6 [#1]
  SMP NR_CPUS=2048 NUMA pSeries
  CPU: 1280 PID: 7755 Comm: kworker/1280:1 Tainted: G X 
4.4.13-46-default #1
  task: c000189001df4210 ti: c000189001d5c000 task.ti: c000189001d5c000
  NIP: c004f138 LR: 10003a24 CTR: 10001b20
  REGS: c000189001d5f730 TRAP: 4100   Tainted: G X  
(4.4.13-46-default)
  MSR: 80011031   CR: 2448  XER: 
  CFAR: c004ed18 SOFTE: 0
  GPR00: c58d7b60 c000189001d5f9b0 100d7d00 3a738288
  GPR04: 2781 0006  cd1f4d889620
  GPR08: c350 08ab 08ab 100d7af0
  GPR12: 100d7ae8 3ffe787e67a0  0211
  GPR16: 10001b20  0080 3ffe787df110
  GPR20: 0001 100d1e10  3ffe787df050
  GPR24: 0003 0001  3fffe79e2e30
  GPR28: 3fffe79e2e68 003d0f00 3ffe787e67a0 3ffe787de680
  NIP [c004f138] restore_gprs+0xd0/0x16c
  LR [10003a24] 0x10003a24
  Call Trace:
  [c000189001d5f9b0] [c000189001d5f9f0] 0xc000189001d5f9f0 (unreliable)
  [c000189001d5fb90] [c001583c] tm_recheckpoint+0x6c/0xa0
  [c000189001d5fbd0] [c0015c40] __switch_to+0x2c0/0x350
  [c000189001d5fc30] [c07e647c] __schedule+0x32c/0x9c0
  [c000189001d5fcb0] [c07e6b58] schedule+0x48/0xc0
  [c000189001d5fce0] [c00deabc] worker_thread+0x22c/0x5b0
  [c000189001d5fd80] [c00e7000] kthread+0x110/0x130
  [c000189001d5fe30] [c0009538] ret_from_kernel_thread+0x5c/0xa4
  Instruction dump:
  7cb103a6 7cc0e3a6 7ca222a6 78a58402 38c00800 7cc62838 0886 7cc000a6
  38a6 78c60022 7cc62838 0b06  7ccff120 e8270078 e8a70098
  ---[ end trace 602126d0a1dedd54 ]---

This fixes this by copying the required data from the thread_struct to
the stack before we clear MSR RI. Then once we clear RI, we only access
the stack, guaranteeing there's no segment miss.

We also tighten the region over which we set RI=0 on the treclaim()
path. This may have a slight performance impact since we're adding an
mtmsr instruction.

Fixes: 090b9284d725 ("powerpc/tm: Clear MSR RI in non-recoverable TM code")
Signed-off-by: Michael Neuling 
Reviewed-by: Cyril Bur 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/tm.S | 61 ++--
 1 file changed, 44 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/kernel/tm.S b/arch/powerpc/kernel/tm.S
index bf8f34a58670..b7019b559ddb 100644
--- a/arch/powerpc/kernel/tm.S
+++ b/arch/powerpc/kernel/tm.S
@@ -110,17 +110,11 @@ _GLOBAL(tm_reclaim)
std r3, STK_PARAM(R3)(r1)
SAVE_NVGPRS(r1)
 
-   /* We need to setup MSR for VSX register save instructions.  Here we
-* also clear the MSR RI since when we do the treclaim, we won't have a
-* valid kernel pointer for a while.  We clear RI here as it avoids
-* adding another mtmsr closer to the treclaim.  This makes the region
-* maked as non-recoverable wider than it needs to be but it saves on
-* inserting another mtmsrd later.
-*/
+   /* We need to setup MSR for VSX register save instructions. */
mfmsr   r14
mr  r15, r14
ori r15, r15, MSR_FP
-   li  

[PATCH stable 4.6 3/4] powerpc/eeh: Fix wrong argument passed to eeh_rmv_device()

[Michael Ellerman]

From: Gavin Shan 

commit cca0e542e02e48cce541a49c4046ec094ec27c1e upstream.

When calling eeh_rmv_device() in eeh_reset_device() for partial hotplug
case, @rmv_data instead of its address is the proper argument.
Otherwise, the stack frame is corrupted when writing to
@rmv_data (actually its address) in eeh_rmv_device(). It results in
kernel crash as observed.

This fixes the issue by passing @rmv_data, not its address to
eeh_rmv_device() in eeh_reset_device().

Fixes: 67086e32b564 ("powerpc/eeh: powerpc/eeh: Support error recovery for VF 
PE")
Reported-by: Pridhiviraj Paidipeddi 
Signed-off-by: Gavin Shan 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/eeh_driver.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index c42627645b54..4a27a9684442 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -653,7 +653,7 @@ static int eeh_reset_device(struct eeh_pe *pe, struct 
pci_bus *bus,
pci_unlock_rescan_remove();
}
} else if (frozen_bus) {
-   eeh_pe_dev_traverse(pe, eeh_rmv_device, _data);
+   eeh_pe_dev_traverse(pe, eeh_rmv_device, rmv_data);
}
 
/*
-- 
2.7.4

[PATCH stable 4.6 2/4] powerpc/bpf/jit: Disable classic BPF JIT on ppc64le

[Michael Ellerman]

From: "Naveen N. Rao" 

commit 844e3be47693f92a108cb1fb3b0606bf25e9c7a6 upstream.

Backport required due to rename of HAVE_BPF_JIT to HAVE_CBPF_JIT
upstream - mpe.

Classic BPF JIT was never ported completely to work on little endian
powerpc. However, it can be enabled and will crash the system when used.
As such, disable use of BPF JIT on ppc64le.

Fixes: 7c105b63bd98 ("powerpc: Add CONFIG_CPU_LITTLE_ENDIAN kernel config 
option.")
Reported-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Naveen N. Rao 
Acked-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 7cd32c038286..4e1b060b8481 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -126,7 +126,7 @@ config PPC
select IRQ_FORCED_THREADING
select HAVE_RCU_TABLE_FREE if SMP
select HAVE_SYSCALL_TRACEPOINTS
-   select HAVE_BPF_JIT
+   select HAVE_BPF_JIT if CPU_BIG_ENDIAN
select HAVE_ARCH_JUMP_LABEL
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select ARCH_HAS_GCOV_PROFILE_ALL
-- 
2.7.4

[PATCH stable 4.6 1/4] powerpc/eeh: Fix invalid cached PE primary bus

[Michael Ellerman]

From: Gavin Shan 

commit a3aa256b7258b3d19f8b44557cc64525a993b941 upstream.

Backport required due to rename of pcibios_add_pci_devices() to
pci_hp_add_devices() upstream - mpe.

The PE primary bus cannot be got from its child devices when having
full hotplug in error recovery. The PE primary bus is cached, which
is done in commit <05ba75f84864> ("powerpc/eeh: Fix stale cached primary
bus"). In eeh_reset_device(), the flag (EEH_PE_PRI_BUS) is cleared
before the PCI hot remove. eeh_pe_bus_get() then returns NULL as the
PE primary bus in pnv_eeh_reset() and it crashes the kernel eventually.

This fixes the issue by clearing the flag (EEH_PE_PRI_BUS) before the
PCI hot add. With it, the PowerNV EEH reset backend (pnv_eeh_reset())
can get valid PE primary bus through eeh_pe_bus_get().

Fixes: 67086e32b564 ("powerpc/eeh: powerpc/eeh: Support error recovery for VF 
PE")
Reported-by: Pridhiviraj Paidipeddi 
Signed-off-by: Gavin Shan 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/eeh_driver.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index 31e4c7e1a4b4..c42627645b54 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -648,7 +648,6 @@ static int eeh_reset_device(struct eeh_pe *pe, struct 
pci_bus *bus,
if (pe->type & EEH_PE_VF) {
eeh_pe_dev_traverse(pe, eeh_rmv_device, NULL);
} else {
-   eeh_pe_state_clear(pe, EEH_PE_PRI_BUS);
pci_lock_rescan_remove();
pcibios_remove_pci_devices(bus);
pci_unlock_rescan_remove();
@@ -698,10 +697,12 @@ static int eeh_reset_device(struct eeh_pe *pe, struct 
pci_bus *bus,
 */
edev = list_first_entry(>edevs, struct eeh_dev, list);
eeh_pe_traverse(pe, eeh_pe_detach_dev, NULL);
-   if (pe->type & EEH_PE_VF)
+   if (pe->type & EEH_PE_VF) {
eeh_add_virt_device(edev, NULL);
-   else
+   } else {
+   eeh_pe_state_clear(pe, EEH_PE_PRI_BUS);
pcibios_add_pci_devices(bus);
+   }
} else if (frozen_bus && rmv_data->removed) {
pr_info("EEH: Sleep 5s ahead of partial hotplug\n");
ssleep(5);
-- 
2.7.4

[PATCH stable 4.6 0/4] powerpc patches for 4.6 stable

[Michael Ellerman]

This is the set of patches I have so far tagged for 4.6 stable.

Please let me know if any of these *shouldn't* go to stable.

Gavin Shan (2):
  powerpc/eeh: Fix invalid cached PE primary bus
  powerpc/eeh: Fix wrong argument passed to eeh_rmv_device()

Michael Neuling (1):
  powerpc/tm: Avoid SLB faults in treclaim/trecheckpoint when RI=0

Naveen N. Rao (1):
  powerpc/bpf/jit: Disable classic BPF JIT on ppc64le

 arch/powerpc/Kconfig |  2 +-
 arch/powerpc/kernel/eeh_driver.c |  9 +++---
 arch/powerpc/kernel/tm.S | 61 +---
 3 files changed, 50 insertions(+), 22 deletions(-)

-- 
2.7.4

Re: [PATCH v2] crypto: powerpc - CRYPT_CRC32C_VPMSUM should depend on ALTIVEC

[Herbert Xu]

On Tue, Aug 09, 2016 at 08:46:15AM +1000, Michael Ellerman wrote:
> The optimised crc32c implementation depends on VMX (aka. Altivec)
> instructions, so the kernel must be built with Altivec support in order
> for the crc32c code to build.
> 
> Fixes: 6dd7a82cc54e ("crypto: powerpc - Add POWER8 optimised crc32c")
> Acked-by: Anton Blanchard 
> Signed-off-by: Michael Ellerman 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: 4.8.0-rc1: Invalid memory access at $SRR0: 0140f86c $SRR1: 00003030

[Christian Kujau]

On Mon, 8 Aug 2016, Christian Kujau wrote:
> while trying to upgrade this PowerBook G4 from 4.7-rc7 to 4.8-rc1, it's 
> unable to boot the Yaboot (v1.3.16 from Debian/stable) boot loader:
> 
> 
> copying OF device tree...
> Building dt strings...
> Building dt stucture...
> Device tree strings 0x01e72000 -> 0x01e73615
> Device tree struct  0x01e74000 -> 0x01e7e000
> Quiescing Open Firmware...
> Bootng Linux via __start()...
> 
> Invalid memory access at $SRR0: 0140f86c  $SRR1: 3030
> 
> Apple PowerBook6,8 4.9.0f0 BootROM built on 01/10/05 at 10:39:14
> [...]
> 
>  ok
> 0:> _
> 
> 
> Going back to 4.7-rc7 (w/o installing Yaboot again) works just fine. The 
> config is mostly the same (used "make oldconfig" from 4.7), but I've said 
> YES to CONFIG_SLAB_FREELIST_RANDOM - could this be causing the boot 
> failure? Full .config and screen shot: http://nerdbynature.de/bits/4.8.0-rc1/

A git-bisect led me to:

=
commit 9402c684613163888714df0955fa1f17142b08bf
Author: Benjamin Herrenschmidt 
Date:   Tue Jul 5 15:03:41 2016 +1000

powerpc: Factor do_feature_fixup calls

32 and 64-bit do a similar set of calls early on, we move it all to
a single common function to make the boot code more readable.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Michael Ellerman 
=

But I'm unable to revert just this patch:

$ git revert 9402c684613163888714df0955fa1f17142b08bf
error: could not revert 9402c68... powerpc: Factor do_feature_fixup calls
hint: after resolving the conflicts, mark the corrected paths

The bisect-log:

=
$ git bisect log
git bisect start '--' 'arch/powerpc'
# good: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
git bisect good 523d939ef98fd712632d93a5a2b588e477a7565e
# bad: [29b4817d4018df78086157ea3a55c1d9424a7cfc] Linux 4.8-rc1
git bisect bad 29b4817d4018df78086157ea3a55c1d9424a7cfc
# bad: [3808a88985b4f5f5e947c364debce4441a380fb8] powerpc: Move FW feature 
probing out of pseries probe()
git bisect bad 3808a88985b4f5f5e947c364debce4441a380fb8
# good: [a203658b5ed37c11e5016d3fbbbab9ce018c1b78] powerpc/opal: Wake up kopald 
polling thread before waiting for events
git bisect good a203658b5ed37c11e5016d3fbbbab9ce018c1b78
# good: [0dfffb48cecd8f84c6e649baee9bacd9be925734] powerpc/powernv: abstraction 
for saving SPRs before entering deep idle states
git bisect good 0dfffb48cecd8f84c6e649baee9bacd9be925734
# good: [66c570f545e056babdd9510595ce762dcedadd71] powerpc/mm: use _raw variant 
of page table accessors
git bisect good 66c570f545e056babdd9510595ce762dcedadd71
# good: [c2ca9f6b4cc4c45eb598b24b8b06beee668052d5] powerpc/powernv: Fix 
pci-cxl.c build when CONFIG_MODULES=n
git bisect good c2ca9f6b4cc4c45eb598b24b8b06beee668052d5
# good: [4c91bd6eeabb004f283db8a6854b134e2a2de1bc] powerpc: Merge the 
RELOCATABLE config entries for ppc32 and ppc64
git bisect good 4c91bd6eeabb004f283db8a6854b134e2a2de1bc
# bad: [c4bd6cb87c9e28a7d9f4a97db5a06cc538eb5e48] powerpc: Move 64-bit feature 
fixup earlier
git bisect bad c4bd6cb87c9e28a7d9f4a97db5a06cc538eb5e48
# bad: [9402c684613163888714df0955fa1f17142b08bf] powerpc: Factor 
do_feature_fixup calls
git bisect bad 9402c684613163888714df0955fa1f17142b08bf
# good: [27d1149667352772240655b65372a4294f992ea7] powerpc/32: Remove 
RELOCATABLE_PPC32
git bisect good 27d1149667352772240655b65372a4294f992ea7
# first bad commit: [9402c684613163888714df0955fa1f17142b08bf] powerpc: Factor 
do_feature_fixup calls
=


HTH,
Christian.
-- 
BOFH excuse #409:

The vulcan-death-grip ping has been applied.

[PATCH] powerpc/pci: Fix endian bug in fixed PHB numbering

[Michael Ellerman]

The recent commit 63a72284b159 ("powerpc/pci: Assign fixed PHB number
based on device-tree properties"), added code to read a 64-bit property
from the device tree, and if not found read a 32-bit property (reg).

There was a bug in the 32-bit case, on big endian machines, due to the
use of the 64-bit value to read the 32-bit property. The cast of 
means we end up writing to the high 32-bit of prop, leaving the low
32-bits containing whatever junk was on the stack.

If that junk value was non-zero, and < MAX_PHBS, we would end up using
it as the PHB id. This results in users seeing what appear to be random
PHB ids.

Fix it by reading into a u32 property and then assigning that to the
u64 value, letting the CPU do the correct conversions for us.

Fixes: 63a72284b159 ("powerpc/pci: Assign fixed PHB number based on device-tree 
properties")
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/pci-common.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index a5c0153ede37..7fdf324d5b51 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -78,6 +78,7 @@ EXPORT_SYMBOL(get_pci_dma_ops);
 static int get_phb_number(struct device_node *dn)
 {
int ret, phb_id = -1;
+   u32 prop_32;
u64 prop;
 
/*
@@ -86,8 +87,10 @@ static int get_phb_number(struct device_node *dn)
 * reading "ibm,opal-phbid", only present in OPAL environment.
 */
ret = of_property_read_u64(dn, "ibm,opal-phbid", );
-   if (ret)
-   ret = of_property_read_u32_index(dn, "reg", 1, (u32 *));
+   if (ret) {
+   ret = of_property_read_u32_index(dn, "reg", 1, _32);
+   prop = prop_32;
+   }
 
if (!ret)
phb_id = (int)(prop & (MAX_PHBS - 1));
-- 
2.7.4

Re: [PATCH kernel 05/15] powerpc/iommu: Stop using @current in mm_iommu_xxx

[Balbir Singh]

On 09/08/16 16:04, Nicholas Piggin wrote:
> On Tue, 9 Aug 2016 14:43:00 +1000
> Balbir Singh  wrote:
> 
>> On 03/08/16 18:40, Alexey Kardashevskiy wrote:
> 
>>> -long mm_iommu_get(unsigned long ua, unsigned long entries,
>>> +long mm_iommu_get(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;
>>> long i, j, ret = 0, locked_entries = 0;
>>> struct page *page = NULL;
>>>  
>>> -   if (!current || !current->mm)
>>> -   return -ESRCH; /* process exited */  
>>
>> VM_BUG_ON(mm == NULL)?
> 
> 
>>> @@ -128,10 +129,17 @@ static long tce_iommu_register_pages(struct 
>>> tce_container *container,
>>> ((vaddr + size) < vaddr))
>>> return -EINVAL;
>>>  
>>> -   ret = mm_iommu_get(vaddr, entries, );
>>> +   if (!container->mm) {
>>> +   if (!current->mm)
>>> +   return -ESRCH; /* process exited */  
>>
>> You may even want to check for PF_EXITING and ignore those tasks?
> 
> 
> These are related to some of the questions I had about the patch.
> 
> But I think it makes sense just to take this approach as a minimal
> bug fix without changing logic too much or adding BUG_ONs, and then
> if we we can consider how iommu takes references to mm and uses it
> (if anybody finds the time).
> 

Agreed

Balbir

Re: [PATCH kernel 05/15] powerpc/iommu: Stop using @current in mm_iommu_xxx

[Nicholas Piggin]

On Tue, 9 Aug 2016 14:43:00 +1000
Balbir Singh  wrote:

> On 03/08/16 18:40, Alexey Kardashevskiy wrote:

> > -long mm_iommu_get(unsigned long ua, unsigned long entries,
> > +long mm_iommu_get(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;
> > long i, j, ret = 0, locked_entries = 0;
> > struct page *page = NULL;
> >  
> > -   if (!current || !current->mm)
> > -   return -ESRCH; /* process exited */  
> 
> VM_BUG_ON(mm == NULL)?


> > @@ -128,10 +129,17 @@ static long tce_iommu_register_pages(struct 
> > tce_container *container,
> > ((vaddr + size) < vaddr))
> > return -EINVAL;
> >  
> > -   ret = mm_iommu_get(vaddr, entries, );
> > +   if (!container->mm) {
> > +   if (!current->mm)
> > +   return -ESRCH; /* process exited */  
> 
> You may even want to check for PF_EXITING and ignore those tasks?


These are related to some of the questions I had about the patch.

But I think it makes sense just to take this approach as a minimal
bug fix without changing logic too much or adding BUG_ONs, and then
if we we can consider how iommu takes references to mm and uses it
(if anybody finds the time).

Thanks,
Nick