Re: rtc-opal: Fix handling of firmware error codes, prevent busy loops

[Stewart Smith]

Alexandre Belloni  writes:
> On 02/08/2016 at 11:50:16 +1000, Stewart Smith wrote:
>> According to the OPAL docs:
>> https://github.com/open-power/skiboot/blob/skiboot-5.2.5/doc/opal-api/opal-rtc-read-3.txt
>> https://github.com/open-power/skiboot/blob/skiboot-5.2.5/doc/opal-api/opal-rtc-write-4.txt
>> OPAL_HARDWARE may be returned from OPAL_RTC_READ or OPAL_RTC_WRITE and this
>> indicates either a transient or permanent error.
>> 
>> Prior to this patch, Linux was not dealing with OPAL_HARDWARE being a
>> permanent error particularly well, in that you could end up in a busy
>> loop.
>> 
>> This was not too hard to trigger on an AMI BMC based OpenPOWER machine
>> doing a continuous "ipmitool mc reset cold" to the BMC, the result of
>> that being that we'd get stuck in an infinite loop in opal_get_rtc_time.
>> 
>> We now retry a few times before returning the error higher up the stack.
>> 
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Stewart Smith 
>> ---
>>  drivers/rtc/rtc-opal.c | 12 ++--
>>  1 file changed, 10 insertions(+), 2 deletions(-)
>> 
>
> Just a note to let you know that this patch should have gone through my
> tree but it was not sent to linux-rtc or me.
>
> I guess what happened is that Michael cleaned up the Linux PPC patchwork
> queue.

Apologies for not sending there. My (18 month ago self) bad.

-- 
Stewart Smith
OPAL Architect, IBM.

Re: [PATCH v11 3/3] mm, x86: display pkey in smaps only if arch supports pkeys

[Michael Ellerman]

Ram Pai  writes:

> On Fri, Feb 02, 2018 at 12:27:27PM +0800, kbuild test robot wrote:
>> Hi Ram,
>> 
>> Thank you for the patch! Yet something to improve:
>> 
>> [auto build test ERROR on linus/master]
>> [also build test ERROR on v4.15 next-20180201]
>> [if your patch is applied to the wrong git tree, please drop us a note to 
>> help improve the system]
>> 
>> url:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_0day-2Dci_linux_commits_Ram-2DPai_mm-2Dx86-2Dpowerpc-2DEnhancements-2Dto-2DMemory-2DProtection-2DKeys_20180202-2D120004=DwIBAg=jf_iaSHvJObTbx-siA1ZOg=m-UrKChQVkZtnPpjbF6YY99NbT8FBByQ-E-ygV8luxw=Fv3tEHet1bTUrDjOnzEhXvGM_4tGlkYhJHPBnWNWgVA=Z1W6CV2tfPmLYU8lVv1oDRl2cAyQA76KE2P064A2CQY=
>> config: x86_64-randconfig-x005-201804 (attached as .config)
>> compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
>> reproduce:
>> # save the attached .config to linux build tree
>> make ARCH=x86_64 
>> 
>> All error/warnings (new ones prefixed by >>):
>> 
>>In file included from arch/x86/include/asm/mmu_context.h:8:0,
>> from arch/x86/events/core.c:36:
>> >> include/linux/pkeys.h:16:23: error: expected identifier or '(' before 
>> >> numeric constant
>> #define vma_pkey(vma) 0
>>   ^
>> >> arch/x86/include/asm/mmu_context.h:298:19: note: in expansion of macro 
>> >> 'vma_pkey'
>> static inline int vma_pkey(struct vm_area_struct *vma)
>>   ^~~~
>> 
>> vim +16 include/linux/pkeys.h
>> 
>>  7   
>>  8   #ifdef CONFIG_ARCH_HAS_PKEYS
>>  9   #include 
>> 10   #else /* ! CONFIG_ARCH_HAS_PKEYS */
>> 11   #define arch_max_pkey() (1)
>> 12   #define execute_only_pkey(mm) (0)
>> 13   #define arch_override_mprotect_pkey(vma, prot, pkey) (0)
>> 14   #define PKEY_DEDICATED_EXECUTE_ONLY 0
>> 15   #define ARCH_VM_PKEY_FLAGS 0
>>   > 16   #define vma_pkey(vma) 0
>
> Oops. Thanks for catching the issue. The following fix will resolve the error.
>
> diff --git a/arch/x86/include/asm/mmu_context.h
> b/arch/x86/include/asm/mmu_context.h
> index 6d16d15..c1aeb19 100644
> --- a/arch/x86/include/asm/mmu_context.h
> +++ b/arch/x86/include/asm/mmu_context.h
> @@ -238,11 +238,6 @@ static inline int vma_pkey(struct vm_area_struct
>   *vma)
>  
> return (vma->vm_flags & vma_pkey_mask) >> VM_PKEY_SHIFT;
> }
> -#else
> -static inline int vma_pkey(struct vm_area_struct *vma)
> -{
> -   return 0;
> -}
>  #endif

That's not working for me (i386_defconfig):

  In file included from ../include/linux/pkeys.h:6:0,
   from ../arch/x86/kernel/fpu/xstate.c:9:
  ../arch/x86/include/asm/mmu_context.h: In function 
‘arch_vma_access_permitted’:
  ../arch/x86/include/asm/mmu_context.h:276:28: error: implicit declaration of 
function ‘vma_pkey’ [-Werror=implicit-function-declaration]
return __pkru_allows_pkey(vma_pkey(vma), write);
  ^~~~
  In file included from ../include/linux/pkeys.h:6:0,
   from ../fs/proc/task_mmu.c:21:
  ../arch/x86/include/asm/mmu_context.h: In function 
‘arch_vma_access_permitted’:
  ../arch/x86/include/asm/mmu_context.h:276:28: error: implicit declaration of 
function ‘vma_pkey’ [-Werror=implicit-function-declaration]
return __pkru_allows_pkey(vma_pkey(vma), write);
  ^~~~
  In file included from ../include/linux/pkeys.h:6:0,
   from ../mm/mmap.c:46:
  ../arch/x86/include/asm/mmu_context.h: In function 
‘arch_vma_access_permitted’:
  ../arch/x86/include/asm/mmu_context.h:276:28: error: implicit declaration of 
function ‘vma_pkey’ [-Werror=implicit-function-declaration]
return __pkru_allows_pkey(vma_pkey(vma), write);
  ^~~~
  In file included from ../include/linux/pkeys.h:6:0,
   from ../mm/mprotect.c:27:
  ../arch/x86/include/asm/mmu_context.h: In function 
‘arch_vma_access_permitted’:
  ../arch/x86/include/asm/mmu_context.h:276:28: error: implicit declaration of 
function ‘vma_pkey’ [-Werror=implicit-function-declaration]
return __pkru_allows_pkey(vma_pkey(vma), write);
  ^~~~
  In file included from ../include/linux/pkeys.h:6:0,
   from ../arch/x86/kernel/fpu/core.c:15:
  ../arch/x86/include/asm/mmu_context.h: In function 
‘arch_vma_access_permitted’:
  ../arch/x86/include/asm/mmu_context.h:276:28: error: implicit declaration of 
function ‘vma_pkey’ [-Werror=implicit-function-declaration]
return __pkru_allows_pkey(vma_pkey(vma), write);
  ^~~~

cheers

Re: rtc-opal: Fix handling of firmware error codes, prevent busy loops

[Michael Ellerman]

Alexandre Belloni  writes:

> Hi,
>
> On 02/08/2016 at 11:50:16 +1000, Stewart Smith wrote:
>> According to the OPAL docs:
>> https://github.com/open-power/skiboot/blob/skiboot-5.2.5/doc/opal-api/opal-rtc-read-3.txt
>> https://github.com/open-power/skiboot/blob/skiboot-5.2.5/doc/opal-api/opal-rtc-write-4.txt
>> OPAL_HARDWARE may be returned from OPAL_RTC_READ or OPAL_RTC_WRITE and this
>> indicates either a transient or permanent error.
>> 
>> Prior to this patch, Linux was not dealing with OPAL_HARDWARE being a
>> permanent error particularly well, in that you could end up in a busy
>> loop.
>> 
>> This was not too hard to trigger on an AMI BMC based OpenPOWER machine
>> doing a continuous "ipmitool mc reset cold" to the BMC, the result of
>> that being that we'd get stuck in an infinite loop in opal_get_rtc_time.
>> 
>> We now retry a few times before returning the error higher up the stack.
>> 
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Stewart Smith 
>> ---
>>  drivers/rtc/rtc-opal.c | 12 ++--
>>  1 file changed, 10 insertions(+), 2 deletions(-)
>> 
>
> Just a note to let you know that this patch should have gone through my
> tree but it was not sent to linux-rtc or me.

Sorry, I saw it had been languishing for a long time and assumed you'd
missed it.

Happy to revert/rework it if you're not happy with it.

> I guess what happened is that Michael cleaned up the Linux PPC patchwork
> queue.

Yeah I did.

In future I'll ping you if there's something that seems to have fallen
through the cracks.

cheers

Re: Kernel 4.15 lost set_robust_list support on POWER 9

[Nicholas Piggin]

On Tue, 06 Feb 2018 08:47:03 +0530
"Aneesh Kumar K.V"  wrote:

> Nicholas Piggin  writes:
> 
> > On Tue, 06 Feb 2018 08:55:31 +1100
> > Benjamin Herrenschmidt  wrote:
> >  
> >> On Mon, 2018-02-05 at 19:14 -0200, Mauricio Faria de Oliveira wrote:  
> >> > Nick, Michael,
> >> 
> >> +Aneesh.
> >>   
> >> > On 02/05/2018 10:48 AM, Florian Weimer wrote:
> >> > > 7041  set_robust_list(0x7fff93dc3980, 24) = -1 ENOSYS (Function not 
> >> > > implemented)
> >> > 
> >> > The regression was introduced by commit 371b8044 ("powerpc/64s: 
> >> > Initialize ISAv3 MMU registers before setting partition table").
> >> > 
> >> > The problem is Radix MMU specific (does not occur with 'disable_radix'),
> >> > and does not occur with that code reverted (ie do not set PIDR to zero).
> >> > 
> >> > Do you see any reasons why?
> >> > (wondering if at all related to access_ok() in include/asm/uaccess.h)  
> >
> > Does this help?
> >
> > powerpc/64s/radix: allocate guard-PID for kernel contexts at boot
> >
> > 64s/radix uses PID 0 for its kernel mapping at the 0xCxxx (quadrant 3)
> > address. This mapping is also accessible at 0x0xxx when PIDR=0 -- the
> > top 2 bits just selects the addressing mode, which is effectively the
> > same when PIDR=0 -- so address 0 translates to physical address 0 by
> > the kernel's linear map.
> >
> > Commit 371b8044 ("powerpc/64s: Initialize ISAv3 MMU registers before
> > setting partition table"), which zeroes PIDR at boot, caused this
> > situation, and that stops kernel access to NULL from faulting in boot.
> > Before this, we inherited what firmware or kexec gave, which is almost
> > always non-zero.
> >
> > futex_atomic_cmpxchg detection is done in boot, by testing if it
> > returns -EFAULT on a NULL address. This breaks when kernel access to
> > NULL during boot does not fault.
> >
> > This patch allocates a non-zero guard PID for init_mm, and switches
> > kernel context to the guard PID at boot. This disallows access to the
> > kernel mapping from quadrant 0 at boot.
> >
> > The effectiveness of this protection will be diminished a little after
> > boot when kernel threads inherit the last context, but those should
> > have NULL guard areas, and it's possible we will actually prefer to do
> > a non-lazy switch back to the guard PID in a future change. For now,
> > this gives a minimal fix, and gives NULL pointer protection for boot.  
> 
> I also have this as a part of another patch series. Since we already
> support cmpxchg(), i would suggest we avoid the runtime check.
> 
> I needed this w.r.t hash so that we don't detect a NULL access as bad
> slb address because we don't have PACA slb_addr_limit initialized
> correctly that early.
> 
> commit c42b0fb10027af0c44fc9e2f6f9586203c38f99b
> Author: Aneesh Kumar K.V 
> Date:   Wed Jan 24 13:54:22 2018 +0530
> 
> Don't do futext cmp test.
> 
> It access NULL address early in the boot and we want to avoid that to 
> simplify
> the fault handling.
> futex_detect_cmpxchg() does a cmpxchg_futex_value_locked on a NULL user 
> addr
> to runtime detect whether architecture implements atomic cmpxchg for 
> futex.
> 
> diff --git a/arch/powerpc/platforms/Kconfig.cputype 
> b/arch/powerpc/platforms/Kconfig.cputype
> index a429d859f15d..31bc2bd5dfd1 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -75,6 +75,7 @@ config PPC_BOOK3S_64
>   select ARCH_SUPPORTS_NUMA_BALANCING
>   select IRQ_WORK
>   select HAVE_KERNEL_XZ
> + select HAVE_FUTEX_CMPXCHG if FUTEX
>  
>  config PPC_BOOK3E_64
>   bool "Embedded processors"
>  
> 

I think that's okay, but what I'd prefer is to set up the hash context
sufficiently that it will cope with a userspace access (and preferably
fault) before we switch on the MMU at boot.

We can do this patch as well, as a "don't bother testing because we always
support it" cleanup.

Thanks,
Nick

Re: Kernel 4.15 lost set_robust_list support on POWER 9

[Aneesh Kumar K.V]

Nicholas Piggin  writes:

> On Tue, 06 Feb 2018 08:55:31 +1100
> Benjamin Herrenschmidt  wrote:
>
>> On Mon, 2018-02-05 at 19:14 -0200, Mauricio Faria de Oliveira wrote:
>> > Nick, Michael,  
>> 
>> +Aneesh.
>> 
>> > On 02/05/2018 10:48 AM, Florian Weimer wrote:  
>> > > 7041  set_robust_list(0x7fff93dc3980, 24) = -1 ENOSYS (Function not 
>> > > implemented)  
>> > 
>> > The regression was introduced by commit 371b8044 ("powerpc/64s: 
>> > Initialize ISAv3 MMU registers before setting partition table").
>> > 
>> > The problem is Radix MMU specific (does not occur with 'disable_radix'),
>> > and does not occur with that code reverted (ie do not set PIDR to zero).
>> > 
>> > Do you see any reasons why?
>> > (wondering if at all related to access_ok() in include/asm/uaccess.h)
>
> Does this help?
>
> powerpc/64s/radix: allocate guard-PID for kernel contexts at boot
>
> 64s/radix uses PID 0 for its kernel mapping at the 0xCxxx (quadrant 3)
> address. This mapping is also accessible at 0x0xxx when PIDR=0 -- the
> top 2 bits just selects the addressing mode, which is effectively the
> same when PIDR=0 -- so address 0 translates to physical address 0 by
> the kernel's linear map.
>
> Commit 371b8044 ("powerpc/64s: Initialize ISAv3 MMU registers before
> setting partition table"), which zeroes PIDR at boot, caused this
> situation, and that stops kernel access to NULL from faulting in boot.
> Before this, we inherited what firmware or kexec gave, which is almost
> always non-zero.
>
> futex_atomic_cmpxchg detection is done in boot, by testing if it
> returns -EFAULT on a NULL address. This breaks when kernel access to
> NULL during boot does not fault.
>
> This patch allocates a non-zero guard PID for init_mm, and switches
> kernel context to the guard PID at boot. This disallows access to the
> kernel mapping from quadrant 0 at boot.
>
> The effectiveness of this protection will be diminished a little after
> boot when kernel threads inherit the last context, but those should
> have NULL guard areas, and it's possible we will actually prefer to do
> a non-lazy switch back to the guard PID in a future change. For now,
> this gives a minimal fix, and gives NULL pointer protection for boot.

I also have this as a part of another patch series. Since we already
support cmpxchg(), i would suggest we avoid the runtime check.

I needed this w.r.t hash so that we don't detect a NULL access as bad
slb address because we don't have PACA slb_addr_limit initialized
correctly that early.

commit c42b0fb10027af0c44fc9e2f6f9586203c38f99b
Author: Aneesh Kumar K.V 
Date:   Wed Jan 24 13:54:22 2018 +0530

Don't do futext cmp test.

It access NULL address early in the boot and we want to avoid that to 
simplify
the fault handling.
futex_detect_cmpxchg() does a cmpxchg_futex_value_locked on a NULL user addr
to runtime detect whether architecture implements atomic cmpxchg for futex.

diff --git a/arch/powerpc/platforms/Kconfig.cputype 
b/arch/powerpc/platforms/Kconfig.cputype
index a429d859f15d..31bc2bd5dfd1 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -75,6 +75,7 @@ config PPC_BOOK3S_64
select ARCH_SUPPORTS_NUMA_BALANCING
select IRQ_WORK
select HAVE_KERNEL_XZ
+   select HAVE_FUTEX_CMPXCHG if FUTEX
 
 config PPC_BOOK3E_64
bool "Embedded processors"
 

Re: [PATCH, net] ibmvnic: fix empty firmware version and errors cleanup

[David Miller]

From: Desnes Augusto Nunes do Rosario 
Date: Mon,  5 Feb 2018 14:33:55 -0200

> This patch makes sure that the firmware version is never NULL. Moreover,
> it also performs some cleanup on the error messages.
> 
> Fixes: a107311d7fdf ("ibmvnic: fix firmware version when no firmware level
> has been provided by the VIOS server")
> Signed-off-by: Desnes A. Nunes do Rosario 

Applied, thanks.

Re: Kernel 4.15 lost set_robust_list support on POWER 9

[Nicholas Piggin]

On Tue, 06 Feb 2018 08:55:31 +1100
Benjamin Herrenschmidt  wrote:

> On Mon, 2018-02-05 at 19:14 -0200, Mauricio Faria de Oliveira wrote:
> > Nick, Michael,  
> 
> +Aneesh.
> 
> > On 02/05/2018 10:48 AM, Florian Weimer wrote:  
> > > 7041  set_robust_list(0x7fff93dc3980, 24) = -1 ENOSYS (Function not 
> > > implemented)  
> > 
> > The regression was introduced by commit 371b8044 ("powerpc/64s: 
> > Initialize ISAv3 MMU registers before setting partition table").
> > 
> > The problem is Radix MMU specific (does not occur with 'disable_radix'),
> > and does not occur with that code reverted (ie do not set PIDR to zero).
> > 
> > Do you see any reasons why?
> > (wondering if at all related to access_ok() in include/asm/uaccess.h)

Does this help?

powerpc/64s/radix: allocate guard-PID for kernel contexts at boot

64s/radix uses PID 0 for its kernel mapping at the 0xCxxx (quadrant 3)
address. This mapping is also accessible at 0x0xxx when PIDR=0 -- the
top 2 bits just selects the addressing mode, which is effectively the
same when PIDR=0 -- so address 0 translates to physical address 0 by
the kernel's linear map.

Commit 371b8044 ("powerpc/64s: Initialize ISAv3 MMU registers before
setting partition table"), which zeroes PIDR at boot, caused this
situation, and that stops kernel access to NULL from faulting in boot.
Before this, we inherited what firmware or kexec gave, which is almost
always non-zero.

futex_atomic_cmpxchg detection is done in boot, by testing if it
returns -EFAULT on a NULL address. This breaks when kernel access to
NULL during boot does not fault.

This patch allocates a non-zero guard PID for init_mm, and switches
kernel context to the guard PID at boot. This disallows access to the
kernel mapping from quadrant 0 at boot.

The effectiveness of this protection will be diminished a little after
boot when kernel threads inherit the last context, but those should
have NULL guard areas, and it's possible we will actually prefer to do
a non-lazy switch back to the guard PID in a future change. For now,
this gives a minimal fix, and gives NULL pointer protection for boot.
---
 arch/powerpc/mm/pgtable-radix.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/mm/pgtable-radix.c b/arch/powerpc/mm/pgtable-radix.c
index 573a9a2ee455..6389a8527e4a 100644
--- a/arch/powerpc/mm/pgtable-radix.c
+++ b/arch/powerpc/mm/pgtable-radix.c
@@ -20,6 +20,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -333,6 +334,9 @@ static void __init radix_init_pgtable(void)
 "r" (TLBIEL_INVAL_SET_LPID), "r" (0));
asm volatile("eieio; tlbsync; ptesync" : : : "memory");
trace_tlbie(0, 0, TLBIEL_INVAL_SET_LPID, 0, 2, 1, 1);
+
+   init_mm.context.id = mmu_base_pid;
+   mmu_base_pid++;
 }
 
 static void __init radix_init_partition_table(void)
@@ -579,7 +583,7 @@ void __init radix__early_init_mmu(void)
 
radix_init_iamr();
radix_init_pgtable();
-
+   radix__switch_mmu_context(NULL, _mm);
if (cpu_has_feature(CPU_FTR_HVMODE))
tlbiel_all();
 }
@@ -604,6 +608,7 @@ void radix__early_init_mmu_secondary(void)
}
radix_init_iamr();
 
+   radix__switch_mmu_context(NULL, _mm);
if (cpu_has_feature(CPU_FTR_HVMODE))
tlbiel_all();
 }
-- 
2.15.1

Re: Kernel 4.15 lost set_robust_list support on POWER 9

[Benjamin Herrenschmidt]

On Mon, 2018-02-05 at 19:14 -0200, Mauricio Faria de Oliveira wrote:
> Nick, Michael,

+Aneesh.

> On 02/05/2018 10:48 AM, Florian Weimer wrote:
> > 7041  set_robust_list(0x7fff93dc3980, 24) = -1 ENOSYS (Function not 
> > implemented)
> 
> The regression was introduced by commit 371b8044 ("powerpc/64s: 
> Initialize ISAv3 MMU registers before setting partition table").
> 
> The problem is Radix MMU specific (does not occur with 'disable_radix'),
> and does not occur with that code reverted (ie do not set PIDR to zero).
> 
> Do you see any reasons why?
> (wondering if at all related to access_ok() in include/asm/uaccess.h)
> 
> with:
> 
>  # strace -e set_robust_list -f ./test
>  set_robust_list(0x7fffa4b03910, 24) = -1 ENOSYS (Function not 
> implemented)
>  +++ exited with 1 +++
> 
>  # uname -r
>  4.15.0
> 
> without:
> 
>  # strace -e set_robust_list -f ./test
>  set_robust_list(0x7fff889c3910, 24) = 0
>  +++ exited with 0 +++
> 
>  # uname -r
>  4.15.0.nopidr

Re: Kernel 4.15 lost set_robust_list support on POWER 9

[Mauricio Faria de Oliveira]

Nick, Michael,

On 02/05/2018 10:48 AM, Florian Weimer wrote:
7041  set_robust_list(0x7fff93dc3980, 24) = -1 ENOSYS (Function not 
implemented)


The regression was introduced by commit 371b8044 ("powerpc/64s: 
Initialize ISAv3 MMU registers before setting partition table").


The problem is Radix MMU specific (does not occur with 'disable_radix'),
and does not occur with that code reverted (ie do not set PIDR to zero).

Do you see any reasons why?
(wondering if at all related to access_ok() in include/asm/uaccess.h)

with:

# strace -e set_robust_list -f ./test
set_robust_list(0x7fffa4b03910, 24) = -1 ENOSYS (Function not 
implemented)

+++ exited with 1 +++

# uname -r
4.15.0

without:

# strace -e set_robust_list -f ./test
set_robust_list(0x7fff889c3910, 24) = 0
+++ exited with 0 +++

# uname -r
4.15.0.nopidr

Re: [PATCH for 4.16 v7 02/11] powerpc: membarrier: Skip memory barrier in switch_mm()

[Mathieu Desnoyers]

- On Feb 5, 2018, at 3:22 PM, Ingo Molnar mi...@kernel.org wrote:

> * Mathieu Desnoyers  wrote:
> 
>>  
>> +config ARCH_HAS_MEMBARRIER_HOOKS
>> +bool
> 
> Yeah, so I have renamed this to ARCH_HAS_MEMBARRIER_CALLBACKS, and propagated 
> it
> through the rest of the patches. "Callback" is the canonical name, and I also
> cringe every time I see 'hook'.
> 
> Please let me know if there are any big objections against this minor cleanup.

No objection at all,

Thanks!

Mathieu

> 
> Thanks,
> 
>   Ingo

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: [PATCH for 4.16 v7 02/11] powerpc: membarrier: Skip memory barrier in switch_mm()

[Ingo Molnar]

* Mathieu Desnoyers  wrote:

>  
> +config ARCH_HAS_MEMBARRIER_HOOKS
> + bool

Yeah, so I have renamed this to ARCH_HAS_MEMBARRIER_CALLBACKS, and propagated 
it 
through the rest of the patches. "Callback" is the canonical name, and I also 
cringe every time I see 'hook'.

Please let me know if there are any big objections against this minor cleanup.

Thanks,

Ingo

[PATCH, net] ibmvnic: fix empty firmware version and errors cleanup

[Desnes Augusto Nunes do Rosario]

This patch makes sure that the firmware version is never NULL. Moreover,
it also performs some cleanup on the error messages.

Fixes: a107311d7fdf ("ibmvnic: fix firmware version when no firmware level
has been provided by the VIOS server")
Signed-off-by: Desnes A. Nunes do Rosario 
---
 drivers/net/ethernet/ibm/ibmvnic.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index 5caaa9033841..afaf29b201dc 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -3286,7 +3286,7 @@ static void handle_vpd_rsp(union ibmvnic_crq *crq,
   struct ibmvnic_adapter *adapter)
 {
struct device *dev = >vdev->dev;
-   unsigned char *substr = NULL, *ptr = NULL;
+   unsigned char *substr = NULL;
u8 fw_level_len = 0;
 
memset(adapter->fw_version, 0, 32);
@@ -3306,10 +3306,6 @@ static void handle_vpd_rsp(union ibmvnic_crq *crq,
substr = strnstr(adapter->vpd->buff, "RM", adapter->vpd->len);
if (!substr) {
dev_info(dev, "Warning - No FW level has been provided in the 
VPD buffer by the VIOS Server\n");
-   ptr = strncpy((char *)adapter->fw_version, "N/A",
- 3 * sizeof(char));
-   if (!ptr)
-   dev_err(dev, "Failed to inform that firmware version is 
unavailable to the adapter\n");
goto complete;
}
 
@@ -3324,16 +3320,14 @@ static void handle_vpd_rsp(union ibmvnic_crq *crq,
/* copy firmware version string from vpd into adapter */
if ((substr + 3 + fw_level_len) <
(adapter->vpd->buff + adapter->vpd->len)) {
-   ptr = strncpy((char *)adapter->fw_version,
- substr + 3, fw_level_len);
-
-   if (!ptr)
-   dev_err(dev, "Failed to isolate FW level string\n");
+   strncpy((char *)adapter->fw_version, substr + 3, fw_level_len);
} else {
dev_info(dev, "FW substr extrapolated VPD buff\n");
}
 
 complete:
+   if (adapter->fw_version[0] == '\0')
+   strncpy((char *)adapter->fw_version, "N/A", 3 * sizeof(char));
complete(>fw_done);
 }
 
-- 
2.14.3

Re: PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first networking updates for the kernel 4.16

[Christian Zigotzky]

Yes, you can.

Christian

On 05 February 2018 at 3:29PM, Andrew Lunn wrote:

On Mon, Feb 05, 2018 at 10:38:34AM +0100, Christian Zigotzky wrote:

Hello Andrew,

Many thanks for your patch. I compiled the latest git kernel today and the
PA Semi PWRficient Gigabit Ethernet works with your patch.

Great.

Can i add a tested-by:

Thanks
Andrew

Re: [PATCH (skiboot)] dt: add /cpus/ibm, powerpc-cpu-features device tree bindings

[Segher Boessenkool]

On Mon, Feb 05, 2018 at 11:26:15AM +1000, Nicholas Piggin wrote:
> On Sat, 3 Feb 2018 09:36:20 -0600
> > On Sat, Feb 03, 2018 at 02:27:32PM +1000, Nicholas Piggin wrote:
> > > + /*
> > > +  * ISAv3.0B branch instruction and register additions
> > > +  * CA32, OV32, mcrxrx, setb
> > > +  */
> > > + { "branch-v3",  
> > 
> > Those aren't branch instructions, they are integer instructions.  Some
> > of which use the XER, some of which use CR fields.
> 
> Okay, well the register changes are for branch facility registers, I
> guess instructions could move to integer. We have nothing relying on
> exact definition of these things at the moment, so these we can change.

XER is a fixed-point facility register (that's what the "X" means even!)

Thanks,


Segher

Re: PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first networking updates for the kernel 4.16

[Andrew Lunn]

On Mon, Feb 05, 2018 at 10:38:34AM +0100, Christian Zigotzky wrote:
> Hello Andrew,
> 
> Many thanks for your patch. I compiled the latest git kernel today and the
> PA Semi PWRficient Gigabit Ethernet works with your patch.

Great.

Can i add a tested-by:

Thanks
Andrew

[mainline][Memory off/on][83e3c48] kernel Oops with memory hot-unplug on ppc

[Abdul Haleem]

Greetings,

Kernel Oops seen when memory hot-unplug on powerpc mainline kernel.

Machine: Power6 PowerVM ppc64
Kernel: 4.15.0
Config: attached
gcc: 4.8.2
Test: Memory hot-unplug of a memory block
echo offline > /sys/devices/system/memory/memory/state

The faulty instruction address points to the code path:

# gdb -batch vmlinux -ex 'list *(0xc0238330)'
0xc0238330 is in get_pfnblock_flags_mask
(./include/linux/mmzone.h:1157).
1152#endif
1153
1154static inline struct mem_section *__nr_to_section(unsigned long nr)
1155{
1156#ifdef CONFIG_SPARSEMEM_EXTREME
1157if (!mem_section)
1158return NULL;
1159#endif
1160if (!mem_section[SECTION_NR_TO_ROOT(nr)])
1161return NULL;


The code was first introduced with commit( 83e3c48: mm/sparsemem:
Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y)

Trace messages:
---
Offlined Pages 1024
ehea: memory is going online
ehea: LPAR memory changed - re-initializing driver
ehea: re-initializing driver complete
ehea: memory is going online
ehea: LPAR memory changed - re-initializing driver
ehea: re-initializing driver complete
ehea: memory is going offline
ehea: LPAR memory changed - re-initializing driver
ehea: re-initializing driver complete
Offlined Pages 1024
Unable to handle kernel paging request for data at address
0xc0005b706ad88178
Faulting instruction address: 0xc0238330
Oops: Kernel access of bad area, sig: 11 [#1]
BE SMP NR_CPUS=1024 NUMA pSeries
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in: rpadlpar_io(E) rpaphp(E) xt_CHECKSUM(E) bnep(E)
bluetooth(E) ecdh_generic(E) nf_conntrack_netbios_ns(E)
nf_conntrack_broadcast(E) ip6t_REJECT(E) nf_reject_ipv6(E)
nf_conntrack_ipv6(E) nf_defrag_ipv6(E) ipt_REJECT(E) nf_reject_ipv4(E)
nf_conntrack_ipv4(E) nf_defrag_ipv4(E) cfg80211(E) xt_conntrack(E)
rfkill(E) nf_conntrack(E) libcrc32c(E) ebtable_nat(E) ebtable_broute(E)
bridge(E) stp(E) llc(E) ebtable_filter(E) ebtables(E) ip6table_mangle(E)
ip6table_security(E) ip6table_raw(E) ip6table_filter(E) ip6_tables(E)
iptable_mangle(E) iptable_security(E) iptable_raw(E) iptable_filter(E)
ip_tables(E) ses(E) enclosure(E) osst(E) scsi_transport_sas(E) st(E)
nfsd(E) auth_rpcgss(E) ehea(E) uio_pdrv_genirq(E) nfs_acl(E) uio(E)
lockd(E) sunrpc(E) grace(E) ipv6(E) crc_ccitt(E) autofs4(E)
 ext4(E) mbcache(E) jbd2(E) sr_mod(E) cdrom(E) sd_mod(E) dm_mirror(E)
dm_region_hash(E) dm_log(E) dm_mod(E) dax(E)
CPU: 12 PID: 6981 Comm: avocado Tainted: GW   E4.15.0-autotest #1
NIP:  c0238330 LR: c02c5dcc CTR: c0122f80
REGS: c002aef63370 TRAP: 0300   Tainted: GW   E 
(4.15.0-autotest)
MSR:  8200b032   CR: 24242488  XER: 
CFAR: c000883c DAR: c0005b706ad88178 DSISR: 4000 SOFTE: 1 
GPR00: c02c5b70 c002aef635f0 c1101a00 c002b1563800 
GPR04: b6db6db6e3f3e100 0002 0007 0010a000 
GPR08: 5b6db6db71f8 c002b3fd0f80 00b6db6db6e3f3e1 0040 
GPR12: 24242488 ced43c00 01001054b518 00803cdf37a8 
GPR16:  c002b3f3ce20 0001 0001 
GPR20: 0001  00026400 003f 
GPR24: c113caa0 0008  0001 
GPR28: c12a1620 c002b3f3ce20 c002b3f3ca00 c002b156 
NIP [c0238330] .get_pfnblock_flags_mask+0x20/0xd0
LR [c02c5dcc] .unset_migratetype_isolate+0x2bc/0x340
Call Trace:
[c002aef635f0] [c02c5b70] .unset_migratetype_isolate+0x60/0x340 
(unreliable)
[c002aef636a0] [c02c60e0] .start_isolate_page_range+0x290/0x450
[c002aef637a0] [c02c0164] .__offline_pages+0x114/0xaa0
[c002aef638f0] [c058a9b8] .memory_subsys_offline+0x58/0xe0
[c002aef63970] [c0567638] .device_offline+0xe8/0x130
[c002aef63a00] [c058a71c] .store_mem_state+0x15c/0x180
[c002aef63a90] [c0562710] .dev_attr_store+0x30/0x60
[c002aef63b00] [c03789e0] .sysfs_kf_write+0x60/0xa0
[c002aef63b70] [c03777a4] .kernfs_fop_write+0x184/0x260
[c002aef63c10] [c02cce8c] .__vfs_write+0x3c/0x1e0
[c002aef63cf0] [c02cd240] .vfs_write+0xc0/0x230
[c002aef63d90] [c02cd558] .SyS_write+0x58/0x100
[c002aef63e30] [c000b858] system_call+0x58/0x6c
Instruction dump:
4e800020 6000 6000 6000 3d02001a 788ac202 3928fc20 e929 
2fa9 419e006c 78886502 79081f24 <7d29402a> 2fa9 419e000c 794a2428 
---[ end trace 2cf894fd69b0954b ]---

INFO: rcu_sched detected stalls on CPUs/tasks:
(detected by 7, t=2102 jiffies, g=25946, c=25945, q=29)
All QSes seen, last rcu_sched kthread activity 2102 (4295176275-4295174173), 
jiffies_till_next_fqs=1, root ->qsmask 0x0
sh  R  running task0  6189  1 

Re: Kernel 4.15 lost set_robust_list support on POWER 9

[Florian Weimer]

On 02/05/2018 01:48 PM, Florian Weimer wrote:

I get this:

7041  set_robust_list(0x7fff93dc3980, 24) = -1 ENOSYS (Function not 
implemented)


The system call works on 4.14.  Looks like the probing for 
futex_cmpxchg_enabled goes wrong.


Sorry, I have no idea where to start digging.  I don't see anything 
obvious in dmesg.


I'm trying to revert

commit 30d6e0a4190d37740e9447e4e4815f06992dd8c3
Author: Jiri Slaby 
Date:   Thu Aug 24 09:31:05 2017 +0200

     futex: Remove duplicated code and fix undefined behaviour

to see if it makes a difference


Never mind, it must be something else because that commit is in 4.14, 
but set_robust_list is still working there.  (Let's hope that the 
probing doesn't fail randomly …)


Thanks,
Florian

Kernel 4.15 lost set_robust_list support on POWER 9

[Florian Weimer]

I get this:

7041  set_robust_list(0x7fff93dc3980, 24) = -1 ENOSYS (Function not 
implemented)


The system call works on 4.14.  Looks like the probing for 
futex_cmpxchg_enabled goes wrong.


Sorry, I have no idea where to start digging.  I don't see anything 
obvious in dmesg.


I'm trying to revert

commit 30d6e0a4190d37740e9447e4e4815f06992dd8c3
Author: Jiri Slaby 
Date:   Thu Aug 24 09:31:05 2017 +0200

futex: Remove duplicated code and fix undefined behaviour

to see if it makes a difference.

Thanks,
Florian

PA Semi PWRficient Gigabit Ethernet doesn't work anymore since the first networking updates for the kernel 4.16

[Christian Zigotzky]

Hello Andrew,

Many thanks for your patch. I compiled the latest git kernel today and 
the PA Semi PWRficient Gigabit Ethernet works with your patch.


Have a nice week!

Thanks,
Christian


On 04 February 2018 at 6:16PM, Andrew Lunn wrote:
> On Sun, Feb 04, 2018 at 05:47:03PM +0100, Christian Zigotzky wrote:
>> Hello,
>>
>> The PA Semi PWRficient Gigabit Ethernet doesn't work anymore since 
the first

>> networking updates [1] for the kernel 4.16.
>>
>> Error messages:
>>
>> [    0.634241] libphy: pasemi gpio mdio bus: probed
>> [    0.634749] pasemi gpio mdio bus: Cannot register as MDIO bus, 
err -38

>
> -38 is ENOSYS.
>
>> --- a/drivers/net/phy/mdio_bus.c    2018-02-03 17:34:46.973045321 +0100
>> +++ b/drivers/net/phy/mdio_bus.c    2018-02-04 11:03:14.909093360 +0100
>> @@ -47,41 +47,11 @@
>>
>>  #include "mdio-boardinfo.h"
>>
>> -static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
>> -{
>> -    struct gpio_desc *gpiod = NULL;
>> -
>> -    /* Deassert the optional reset signal */
>> -    if (mdiodev->dev.of_node)
>> -        gpiod = fwnode_get_named_gpiod(>dev.of_node->fwnode,
>> -                       "reset-gpios", 0, GPIOD_OUT_LOW,
>> -                       "PHY reset");
>
> So i think you don't have GPIOLIB enabled. Hence you are hitting
>
> 
http://elixir.free-electrons.com/linux/latest/source/include/linux/gpio/consumer.h#L470

>
> static inline
> struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
>                      const char *propname, int index,
>                      enum gpiod_flags dflags,
>                      const char *label)
> {
>     return ERR_PTR(-ENOSYS);
> }
>
> So rather than just deleting all this code, breaking other platforms
> that need this gpio, lets try a real fix. Please try this. If it
> works, i will formally submit it.
>
>    Andrew
>
> >From a4210ba306948497d7360927c1e532eb903c58b2 Mon Sep 17 00:00:00 2001
> From: Andrew Lunn 
> Date: Sun, 4 Feb 2018 11:09:20 -0600
> Subject: [PATCH] net: phy: Handle not having GPIO enabled in the kernel
>
> If CONFIG_GPIOLIB is disabled, fwnode_get_named_gpiod() becomes a stub
> function, which return -ENOSYS. Handle this in the same way as
> -ENOENT, i.e. assume there is no GPIO used to reset the PHYs.
>
> Reported-by: Christian Zigotzky 
> Signed-off-by: Andrew Lunn 
> ---
>  drivers/net/phy/mdio_bus.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 88272b3ac2e2..24b5511222c8 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -56,7 +56,8 @@ static int mdiobus_register_gpiod(struct 
mdio_device *mdiodev)

>          gpiod = fwnode_get_named_gpiod(>dev.of_node->fwnode,
>                         "reset-gpios", 0, GPIOD_OUT_LOW,
>                         "PHY reset");
> -    if (PTR_ERR(gpiod) == -ENOENT)
> +    if (PTR_ERR(gpiod) == -ENOENT ||
> +        PTR_ERR(gpiod) == -ENOSYS)
>          gpiod = NULL;
>      else if (IS_ERR(gpiod))
>          return PTR_ERR(gpiod);