Re: Build regressions/improvements in v4.5-rc1

[Geert Uytterhoeven]

On Mon, Jan 25, 2016 at 9:18 AM, Geert Uytterhoeven
 wrote:
> Below is the list of build error/warning regressions/improvements in
> v4.5-rc1[1] compared to v4.4[2].
>
> Summarized:
>   - build errors: +15/-23

> [1] http://kisskb.ellerman.id.au/kisskb/head/9841/ (all 261 configs)
> [2] http://kisskb.ellerman.id.au/kisskb/head/9774/ (259 out of 261 configs)
>
>
> *** ERRORS ***
>
> 15 error regressions:
>   + /home/kisskb/slave/src/arch/sh/drivers/dma/dma-sh.c: error: 'DMTE6_IRQ' 
> undeclared (first use in this function):  => 58:21

sh-randconfig

>   + /home/kisskb/slave/src/drivers/gpu/drm/vc4/vc4_v3d.c: error: called 
> object '0u' is not a function:  => 157:29, 159:27

cris-allmodconfig
cris-allyesconfig
m32r/m32700ut.smp_defconfig
m68k-allmodconfig
parisc-allmodconfig
sh-randconfig
xtensa-allmodconfig

>   + /home/kisskb/slave/src/sound/core/compress_offload.c: error: case label 
> does not reduce to an integer constant:  => 804:2

ppc64le/allmodconfig+ppc64le

>   + /tmp/ccDC0dZh.s: Error: can't resolve `_start' {*UND* section} - `L0 ' 
> {.text section}:  => 378, 49
>   + /tmp/ccGniXga.s: Error: can't resolve `_start' {*UND* section} - `L0 ' 
> {.text section}:  => 43
>   + /tmp/ccci5ABy.s: Error: can't resolve `_start' {*UND* section} - `L0 ' 
> {.text section}:  => 366, 49
>   + /tmp/cccq2wZf.s: Error: can't resolve `_start' {*UND* section} - `L0 ' 
> {.text section}:  => 43
>   + /tmp/cchnfEGb.s: Error: can't resolve `_start' {*UND* section} - `L0 ' 
> {.text section}:  => 43

(reported before)

mips-allnoconfig
mips-defconfig
ip27_defconfig

>   + error: No rule to make target include/config/auto.conf:  => N/A

arm-randconfig (reported before)

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/perf: Remove PPMU_HAS_SSLOT flag for Power8

[Madhavan Srinivasan]

 Commit: 7a7868326d77 introduced PPMU_HAS_SSLOT flag to
 remove assumption of MMCRA[SLOT] with respect to
 PPMU_ALT_SIPR flag. Commit 7a7868326d77's message also
 specifies that Power8 does not support MMCRA[SLOT].
 But still PPMU_HAS_SSLOT flag managed to get into
 Power8 code. Patch to remove the same from Power8 flags.

Signed-off-by: Madhavan Srinivasan 
---
 arch/powerpc/perf/power8-pmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 7d5e295255b7..9958ba8bf0d2 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -816,7 +816,7 @@ static struct power_pmu power8_pmu = {
.get_constraint = power8_get_constraint,
.get_alternatives   = power8_get_alternatives,
.disable_pmc= power8_disable_pmc,
-   .flags  = PPMU_HAS_SSLOT | PPMU_HAS_SIER | 
PPMU_ARCH_207S,
+   .flags  = PPMU_HAS_SIER | PPMU_ARCH_207S,
.n_generic  = ARRAY_SIZE(power8_generic_events),
.generic_events = power8_generic_events,
.cache_events   = &power8_cache_events,
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 2/2] KVM: PPC: Exit guest upon MCE when FWNMI capability is enabled

[Aravinda Prasad]

On Sunday 24 January 2016 02:54 AM, Paul Mackerras wrote:
> On Sat, Jan 23, 2016 at 06:23:35PM +0530, Aravinda Prasad wrote:
>>
>>
>> On Saturday 23 January 2016 03:58 PM, Paul Mackerras wrote:
>>> On Wed, Jan 13, 2016 at 12:38:09PM +0530, Aravinda Prasad wrote:
 Enhance KVM to cause a guest exit with KVM_EXIT_NMI
 exit reasons upon a machine check exception (MCE) in
 the guest address space if the KVM_CAP_PPC_FWNMI
 capability is enabled (instead of delivering 0x200
 interrupt to guest). This enables QEMU to build error
 log and deliver machine check exception to guest via
 guest registered machine check handler.

 This approach simplifies the delivering of machine
 check exception to guest OS compared to the earlier
 approach of KVM directly invoking 0x200 guest interrupt
 vector. In the earlier approach QEMU was enhanced to
 patch the 0x200 interrupt vector during boot. The
 patched code at 0x200 issued a private hcall to pass
 the control to QEMU to build the error log.

 This design/approach is based on the feedback for the
 QEMU patches to handle machine check exception. Details
 of earlier approach of handling machine check exception
 in QEMU and related discussions can be found at:
>>>
>>> [snip]
>>>
 --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
 +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
 @@ -133,21 +133,18 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
stb r0, HSTATE_HWTHREAD_REQ(r13)
  
/*
 -   * For external and machine check interrupts, we need
 -   * to call the Linux handler to process the interrupt.
 -   * We do that by jumping to absolute address 0x500 for
 -   * external interrupts, or the machine_check_fwnmi label
 -   * for machine checks (since firmware might have patched
 -   * the vector area at 0x200).  The [h]rfid at the end of the
 -   * handler will return to the book3s_hv_interrupts.S code.
 -   * For other interrupts we do the rfid to get back
 -   * to the book3s_hv_interrupts.S code here.
 +   * For external interrupts we need to call the Linux
 +   * handler to process the interrupt. We do that by jumping
 +   * to absolute address 0x500 for external interrupts.
 +   * The [h]rfid at the end of the handler will return to
 +   * the book3s_hv_interrupts.S code. For other interrupts
 +   * we do the rfid to get back to the book3s_hv_interrupts.S
 +   * code here.
 */
ld  r8, 112+PPC_LR_STKOFF(r1)
addir1, r1, 112
ld  r7, HSTATE_HOST_MSR(r13)
  
 -  cmpwi   cr1, r12, BOOK3S_INTERRUPT_MACHINE_CHECK
cmpwi   r12, BOOK3S_INTERRUPT_EXTERNAL
beq 11f
cmpwi   r12, BOOK3S_INTERRUPT_H_DOORBELL
 @@ -162,7 +159,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
mtmsrd  r6, 1   /* Clear RI in MSR */
mtsrr0  r8
mtsrr1  r7
 -  beq cr1, 13f/* machine check */
RFI
  
/* On POWER7, we have external interrupts set to use HSRR0/1 */
 @@ -170,8 +166,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
mtspr   SPRN_HSRR1, r7
ba  0x500
  
 -13:   b   machine_check_fwnmi
 -
>>>
>>> So, what you're disabling here is the host-side handling of the
>>> machine check after completing the guest->host switch.  This has
>>> nothing to do with how the machine check gets communicated to the
>>> guest.
>>>
>>> Now, part of the host-side machine check handling has already
>>> happened, but I thought there was more that was done in host kernel
>>> virtual mode.  If this change really is needed then I would want an
>>> ack from Mahesh that this is correct, and it will need to be explained
>>> in detail in the patch description.
>>
>> If we don't do that we will end up running into
>> panic() in opal_machine_check() if UE belonged to guest.
>>
>> Details in this link:
>> http://marc.info/?l=kvm-ppc&m=144730552720044&w=2
> 
> Well maybe the panic call needs to be changed.  But the way you have
> it, we *never* get to opal_machine_check for any machine check
> interrupt, and I have a hard time believing that is correct.

If I am not wrong, earlier, even without this patch we never get to
opal_machine_check() from this place for the machine check happening
inside the guest (irrespective of whether the machine check is recovered
or not). Because, we jump to fast_interrupt_c_return() from
machine_check_realmode without causing the guest to exit.

With this patch I call mc_cont from machine_check_realmode and want the
guest to exit with NMI exit code. However, we don't want to call
opal_machine_check(), because if we call opal_machine_check() we don't
end up with NMI exit for the guest.

Regards,
Aravinda

> 
> Paul.
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs

Re: [PATCH] powerpc/perf: Remove PPMU_HAS_SSLOT flag for Power8

[Anshuman Khandual]

On 01/25/2016 02:03 PM, Madhavan Srinivasan wrote:
>  Commit: 7a7868326d77 introduced PPMU_HAS_SSLOT flag to
>  remove assumption of MMCRA[SLOT] with respect to
>  PPMU_ALT_SIPR flag. Commit 7a7868326d77's message also
>  specifies that Power8 does not support MMCRA[SLOT].
>  But still PPMU_HAS_SSLOT flag managed to get into
>  Power8 code. Patch to remove the same from Power8 flags.

Please follow the present protocol of referring to a commit
ID like this (: ""). Also this PMU flag was added
originally through the base POWER8 PMU enablement commit
(e05b9b9e5c1: "powerpc/perf: Power8 PMU support") which can
be mentioned in the "Fixes:" part.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [kernel] powerpc: Make vmalloc_to_phys() public

[Paul Mackerras]

On Mon, Jan 25, 2016 at 04:46:03PM +1100, Michael Ellerman wrote:
> On Thu, 2016-21-01 at 07:35:08 UTC, Alexey Kardashevskiy wrote:
> > This makes vmalloc_to_phys() public as there will be another user
> > (in-kernel VFIO acceleration) for it soon.
> > 
> > As a part of future little optimization, this changes the helper to call
> > vmalloc_to_pfn() instead of vmalloc_to_page() as the size of the
> > struct page may not be power-of-two aligned which will make gcc use
> > multiply instructions instead of shifts.
> 
> You should also mention why you need to export it, presumably because whatever
> new user you have in mind can be built as a module.

If I remember correctly, it's the *existing* user in hv-24x7.c that
needs the export.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V2] selfttest/powerpc: Add memory page migration tests

[Anshuman Khandual]

On 11/24/2015 01:42 PM, Denis Kirjanov wrote:
> On 11/24/15, Anshuman Khandual  wrote:
>> This adds two tests for memory page migration. One for normal page
>> migration which works for both 4K or 64K base page size kernel and
>> the other one is for 16MB huge page migration which will work both
>> 4K or 64K base page sized 16MB huge pages as and when we support
>> huge page migration.
>>
>> Signed-off-by: Anshuman Khandual 


>> +
>> +static unsigned long get_npages(unsigned long length, unsigned long size)
>> +{
>> +unsigned int tmp1 = length, tmp2 = size;
> I think we want unsigned long here but this is very minor nit

Its been some time now, remember using some tricks to get the
division right. Now that Aneesh's new PTE changes are merged,
will try the Hugetlb migration again and enable the self tests
for them.

>> +
>> +int test_migration(unsigned long length)
>> +{
>> +unsigned long failed;
>> +void *addr;
>> +int ret;
>> +
>> +addr = mmap(MMAP_ADDR, length, MMAP_PROT, MMAP_FLAGS, -1, 0);
>> +if (addr == MAP_FAILED) {
>> +perror("mmap() failed");
>> +exit(-1);
>> +}
>> +
>> +write_buffer(addr, length);
>> +soft_offline_pages(HPAGE_OFF, addr, length/getpagesize(), &failed);
> You've defined get_npages() so I assume it has to be used or not used at all

>> +npages = get_npages(length, PAGE_SIZE_HUGE);

Its used here.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

86xx

[Alessio Igor Bogani]

Hi All,

Sorry for my very bad English!

I'm looking for who takes care of the 86xx subtree
(arch/powerpc/platform/86xx) but I haven't found any entry into
MAINTEINARS file.

Ciao,
Alessio
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v4 0/3] kallsyms base relative series

[Ard Biesheuvel]

This v4 of my kallsyms base relative implementation is now a 3 piece series,
since it caused some problems due to the way absolute symbols are handled
by the absolute per cpu code. As it turns out, that code was probably wrong
in the sense that it caused non-relocated symbol addresses to be emitted
for values that are in fact relative to the address of the kernel text.

Patch #1 fixes the scripts/kallsyms invocation to only pass the x86_64
specific --absolute-percpu option if CONFIG_SMP is also set.

Patch #2 reworks the absolute percpu code to only emit those percpu symbols
as absolute, and not symbols that have been classified as 'A' (absolute) by
the linker, since that does not mean quite the same thing.

Patch #3 is the original kallsyms base relative patch, with some
modifications:
- folded the s/ULLONG_MAX/-1ULL? change made by Andrew
- ensured that the kallsyms_relative_base value itself is relocated as
  required.
- dropped all of the acks and other tags, as they have become outdated with
  the recent changes to this patch.

Ard Biesheuvel (3):
  x86: kallsyms: disable absolute percpu symbols on !SMP
  kallsyms: don't overload absolute symbol type for percpu symbols
  kallsyms: add support for relative offsets in kallsyms address table

 init/Kconfig|  16 +++
 kernel/kallsyms.c   |  38 ++--
 scripts/kallsyms.c  | 102 +---
 scripts/link-vmlinux.sh |   6 +-
 scripts/namespace.pl|   2 +
 5 files changed, 142 insertions(+), 22 deletions(-)

-- 
2.5.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v4 2/3] kallsyms: don't overload absolute symbol type for percpu symbols

[Ard Biesheuvel]

Commit c6bda7c988a5 ("kallsyms: fix percpu vars on x86-64 with relocation")
overloaded the 'A' (absolute) symbol type to signify that a symbol is not
subject to dynamic relocation. However, the original A type does not imply
that at all, and depending on the version of the toolchain, many A type
symbols are emitted that are in fact relative to the kernel text, i.e., if
the kernel is relocated at runtime, these symbols should be updated as well.

For instance, on sparc32, the following symbols are emitted as absolute
(kindly provided by Guenter Roeck):

  f035a420 A _etext
  f03d9000 A _sdata
  f03de8c4 A jiffies
  f03f8860 A _edata
  f03fc000 A __init_begin
  f041bdc8 A __init_text_end
  f0423000 A __bss_start
  f0423000 A __init_end
  f044457d A __bss_stop
  f044457d A _end

On x86_64, similar behavior can be observed:

  81a0 A __end_rodata_hpage_align
  81b19000 A __vvar_page
  81d3d000 A _end

Even if only a couple of them pass the symbol range check that results in
them to be taken into account for the final kallsyms symbol table, it is
obvious that 'A' does not mean the symbol does not need to be updated at
relocation time, and overloading its meaning to signify that is perhaps not
a good idea.

So instead, add a new percpu_absolute member to struct sym_entry, and when
--absolute-percpu is in effect, use it to record symbols whose addresses
should be emitted as final values rather than values that still require
relocation at runtime. That way, we can drop the check against the 'A' type.

Signed-off-by: Ard Biesheuvel 
---
 scripts/kallsyms.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 8fa81e84e295..d39a1eeb080e 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -34,6 +34,7 @@ struct sym_entry {
unsigned int len;
unsigned int start_pos;
unsigned char *sym;
+   unsigned int percpu_absolute;
 };
 
 struct addr_range {
@@ -171,6 +172,8 @@ static int read_symbol(FILE *in, struct sym_entry *s)
strcpy((char *)s->sym + 1, str);
s->sym[0] = stype;
 
+   s->percpu_absolute = 0;
+
/* Record if we've found __per_cpu_start/end. */
check_symbol_range(sym, s->addr, &percpu_range, 1);
 
@@ -325,7 +328,7 @@ static int expand_symbol(unsigned char *data, int len, char 
*result)
 
 static int symbol_absolute(struct sym_entry *s)
 {
-   return toupper(s->sym[0]) == 'A';
+   return s->percpu_absolute;
 }
 
 static void write_src(void)
@@ -681,8 +684,15 @@ static void make_percpus_absolute(void)
unsigned int i;
 
for (i = 0; i < table_cnt; i++)
-   if (symbol_in_range(&table[i], &percpu_range, 1))
+   if (symbol_in_range(&table[i], &percpu_range, 1)) {
+   /*
+* Keep the 'A' override for percpu symbols to
+* ensure consistent behavior compared to older
+* versions of this tool.
+*/
table[i].sym[0] = 'A';
+   table[i].percpu_absolute = 1;
+   }
 }
 
 int main(int argc, char **argv)
-- 
2.5.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v4 3/3] kallsyms: add support for relative offsets in kallsyms address table

[Ard Biesheuvel]

Similar to how relative extables are implemented, it is possible to emit
the kallsyms table in such a way that it contains offsets relative to some
anchor point in the kernel image rather than absolute addresses.

On 64-bit architectures, it cuts the size of the kallsyms address table in
half, since offsets between kernel symbols can typically be expressed in 32
bits. This saves several hundreds of kilobytes of permanent .rodata on
average. In addition, the kallsyms address table is no longer subject to
dynamic relocation when CONFIG_RELOCATABLE is in effect, so the relocation
work done after decompression now doesn't have to do relocation updates for
all these values. This saves up to 24 bytes (i.e., the size of a ELF64 RELA
relocation table entry) per value, which easily adds up to a couple of
megabytes of uncompressed __init data on ppc64 or arm64. Even if these
relocation entries typically compress well, the combined size reduction of
2.8 MB uncompressed for a ppc64_defconfig build (of which 2.4 MB is __init
data) results in a ~500 KB space saving in the compressed image.

Since it is useful for some architectures (like x86) to retain the ability
to emit absolute values as well, this patch adds support for both, by
emitting absolute addresses as positive 32-bit values, and addresses
relative to the lowest encountered relative symbol as negative values,
which are subtracted from the runtime address of this base symbol to
produce the actual address.

Support for the above is enabled by default for all architectures except
IA-64, whose symbols are too far apart to capture in this manner.

Signed-off-by: Ard Biesheuvel 
---
 init/Kconfig| 16 
 kernel/kallsyms.c   | 38 +++--
 scripts/kallsyms.c  | 88 +---
 scripts/link-vmlinux.sh |  4 +
 scripts/namespace.pl|  2 +
 5 files changed, 129 insertions(+), 19 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index 22320804fbaf..1cc72a068afc 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1420,6 +1420,22 @@ config KALLSYMS_ALL
 
   Say N unless you really need all symbols.
 
+config KALLSYMS_BASE_RELATIVE
+   bool
+   depends on KALLSYMS
+   default !IA64
+   help
+ Instead of emitting them as absolute values in the native word size,
+ emit the symbol references in the kallsyms table as 32-bit entries,
+ each containing either an absolute value in the range [0, S32_MAX] or
+ a relative value in the range [base, base + S32_MAX], where base is
+ the lowest relative symbol address encountered in the image.
+
+ On 64-bit builds, this reduces the size of the address table by 50%,
+ but more importantly, it results in entries whose values are build
+ time constants, and no relocation pass is required at runtime to fix
+ up the entries based on the runtime load address of the kernel.
+
 config PRINTK
default y
bool "Enable support for printk" if EXPERT
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 5c5987f10819..10a8af9d5744 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -38,6 +38,7 @@
  * during the second link stage.
  */
 extern const unsigned long kallsyms_addresses[] __weak;
+extern const int kallsyms_offsets[] __weak;
 extern const u8 kallsyms_names[] __weak;
 
 /*
@@ -47,6 +48,9 @@ extern const u8 kallsyms_names[] __weak;
 extern const unsigned long kallsyms_num_syms
 __attribute__((weak, section(".rodata")));
 
+extern const unsigned long kallsyms_relative_base
+__attribute__((weak, section(".rodata")));
+
 extern const u8 kallsyms_token_table[] __weak;
 extern const u16 kallsyms_token_index[] __weak;
 
@@ -176,6 +180,19 @@ static unsigned int get_symbol_offset(unsigned long pos)
return name - kallsyms_names;
 }
 
+static unsigned long kallsyms_sym_address(int idx)
+{
+   if (!IS_ENABLED(CONFIG_KALLSYMS_BASE_RELATIVE))
+   return kallsyms_addresses[idx];
+
+   /* positive offsets are absolute values */
+   if (kallsyms_offsets[idx] >= 0)
+   return kallsyms_offsets[idx];
+
+   /* negative offsets are relative to kallsyms_relative_base - 1 */
+   return kallsyms_relative_base - 1 - kallsyms_offsets[idx];
+}
+
 /* Lookup the address for this symbol. Returns 0 if not found. */
 unsigned long kallsyms_lookup_name(const char *name)
 {
@@ -187,7 +204,7 @@ unsigned long kallsyms_lookup_name(const char *name)
off = kallsyms_expand_symbol(off, namebuf, ARRAY_SIZE(namebuf));
 
if (strcmp(namebuf, name) == 0)
-   return kallsyms_addresses[i];
+   return kallsyms_sym_address(i);
}
return module_kallsyms_lookup_name(name);
 }
@@ -204,7 +221,7 @@ int kallsyms_on_each_symbol(int (*fn)(void *, const char *, 
struct module *,
 
for (i = 0, off = 0; i < kallsyms_num_syms; i++) {
off = kallsyms_expand_symbol(off, namebuf, ARRAY_SIZE(name

[RFC PATCH] PPC32: Fix build failure caused by missing dirty pte handlers

[Pranith Kumar]

In 4.5-rc1, I am getting a build failure as follows:

mm/memory.c: In function ‘do_swap_page’:
mm/memory.c:2573:9: error: implicit declaration of function ‘pte_mksoft_dirty’
[-Werror=implicit-function-declaration]
   pte = pte_mksoft_dirty(pte);

The soft dirty pte handlers are declared only for PPC64 on PPC_BOOK3S in
arch/powerpc/include/asm/book3s/64/hash.h and missing in the 32-bit arch.

Avoid this error by not setting HAVE_ARCH_SOFT_DIRTY for 32-bit system.

Signed-off-by: Pranith Kumar 
---
 arch/powerpc/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e4824fd..21cb5c5 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -557,7 +557,7 @@ choice
 
 config PPC_4K_PAGES
bool "4k page size"
-   select HAVE_ARCH_SOFT_DIRTY if CHECKPOINT_RESTORE && PPC_BOOK3S
+   select HAVE_ARCH_SOFT_DIRTY if CHECKPOINT_RESTORE && PPC_BOOK3S && PPC64
 
 config PPC_16K_PAGES
bool "16k page size"
@@ -566,7 +566,7 @@ config PPC_16K_PAGES
 config PPC_64K_PAGES
bool "64k page size"
depends on !PPC_FSL_BOOK3E && (44x || PPC_STD_MMU_64 || PPC_BOOK3E_64)
-   select HAVE_ARCH_SOFT_DIRTY if CHECKPOINT_RESTORE && PPC_BOOK3S
+   select HAVE_ARCH_SOFT_DIRTY if CHECKPOINT_RESTORE && PPC_BOOK3S && PPC64
 
 config PPC_256K_PAGES
bool "256k page size"
-- 
2.7.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v4 1/3] x86: kallsyms: disable absolute percpu symbols on !SMP

[Ard Biesheuvel]

scripts/kallsyms.c has a special --absolute-percpu command line
option which deals with the zero based per cpu offsets that are
used when building for SMP on x86_64. This means that the option
should only be passed in that case, so add a check for CONFIG_SMP.
Otherwise, per cpu variables are recorded as absolute quantities,
(which they are not under !CONFIG_SMP) and they are not relocated
under CONFIG_RELOCATABLE=y.

Signed-off-by: Ard Biesheuvel 
---
 scripts/link-vmlinux.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index ba6c34ea5429..b541c21072f2 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -86,7 +86,7 @@ kallsyms()
kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET"
fi
 
-   if [ -n "${CONFIG_X86_64}" ]; then
+   if [ -n "${CONFIG_X86_64}" ] && [ -n "${CONFIG_SMP}" ]; then
kallsymopt="${kallsymopt} --absolute-percpu"
fi
 
-- 
2.5.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

[Will Deacon]

On Fri, Jan 15, 2016 at 11:28:45AM -0800, Paul E. McKenney wrote:
> On Fri, Jan 15, 2016 at 09:54:01AM -0800, Paul E. McKenney wrote:
> > On Fri, Jan 15, 2016 at 10:24:32AM +, Will Deacon wrote:
> > > See my earlier reply [1] (but also, your WRC Linux example looks more
> > > like a variant on WWC and I couldn't really follow it).
> > 
> > I will revisit my WRC Linux example.  And yes, creating litmus tests
> > that use non-fake dependencies is still a bit of an undertaking.  :-/
> > I am sure that it will seem more natural with time and experience...
> 
> Hmmm...  You are quite right, I did do WWC.  I need to change cpu2()'s
> last access from a store to a load to get WRC.  Plus the levels of
> indirection definitely didn't match up, did they?

Nope, it was pretty baffling!

>   struct foo {
>   struct foo *next;
>   };
>   struct foo a;
>   struct foo b;
>   struct foo c = { &a };
>   struct foo d = { &b };
>   struct foo x = { &c };
>   struct foo y = { &d };
>   struct foo *r1, *r2, *r3;
> 
>   void cpu0(void)
>   {
>   WRITE_ONCE(x.next, &y);
>   }
> 
>   void cpu1(void)
>   {
>   r1 = lockless_dereference(x.next);
>   WRITE_ONCE(r1->next, &x);
>   }
> 
>   void cpu2(void)
>   {
>   r2 = lockless_dereference(y.next);
>   r3 = READ_ONCE(r2->next);
>   }
> 
> In this case, it is legal to end the run with:
> 
>   r1 == &y && r2 == &x && r3 == &c
> 
> Please see below for a ppcmem litmus test.
> 
> So, did I get it right this time?  ;-)

The code above looks correct to me (in that it matches WRC+addrs),
but your litmus test:

> PPC WRCnf+addrs
> ""
> {
> 0:r2=x; 0:r3=y;
> 1:r2=x; 1:r3=y;
> 2:r2=x; 2:r3=y;
> c=a; d=b; x=c; y=d;
> }
>  P0   | P1| P2;
>  stw r3,0(r2) | lwz r8,0(r2)  | lwz r8,0(r3)  ;
>   | stw r2,0(r3)  | lwz r9,0(r8)  ;
> exists
> (1:r8=y /\ 2:r8=x /\ 2:r9=c)

Seems to be missing the address dependency on P1.

Will
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

[Will Deacon]

On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote:
> On Fri, Jan 15, 2016 at 10:27:14PM +0100, Peter Zijlstra wrote:
> > On Fri, Jan 15, 2016 at 09:46:12AM -0800, Paul E. McKenney wrote:
> > > On Fri, Jan 15, 2016 at 10:13:48AM +0100, Peter Zijlstra wrote:
> > 
> > > > And the stuff we're confused about is how best to express the difference
> > > > and guarantees of these two forms of transitivity and how exactly they
> > > > interact.
> > > 
> > > Hoping my memory-barrier.txt patch helps here...
> > 
> > Yes, that seems a good start. But yesterday you raised the 'fun' point
> > of two globally ordered sequences connected by a single local link.
> 
> The conclusion that I am slowly coming to is that litmus tests should
> not be thought of as linear chains, but rather as cycles.  If you think
> of it as a cycle, then it doesn't matter where the local link is, just
> how many of them and how they are connected.

Do you have some examples of this? I'm struggling to make it work in my
mind, or are you talking specifically in the context of the kernel
memory model?

> But I will admit that there are some rather strange litmus tests that
> challenge this cycle-centric view, for example, the one shown below.
> It turns out that herd and ppcmem disagree on the outcome.  (The Power
> architects side with ppcmem.)
> 
> > And I think I'm still confused on LWSYNC (in the smp_wmb case) when one
> > of the stores looses a conflict, and if that scenario matters. If it
> > does, we should inspect the same case for other barriers.
> 
> Indeed.  I am still working on how these should be described.  My
> current thought is to be quite conservative on what ordering is
> actually respected, however, the current task is formalizing how
> RCU plays with the rest of the memory model.
> 
>   Thanx, Paul
> 
> 
> 
> PPC Overlapping Group-B sets version 4
> ""
> (* When the Group-B sets from two different barriers involve instructions in
>the same thread, within that thread one set must contain the other.
> 
>   P0  P1  P2
>   Rx=1Wy=1Wz=2
>   dep.lwsync  lwsync
>   Ry=0Wz=1Wx=1
>   Rz=1
> 
>   assert(!(z=2))
> 
>Forbidden by ppcmem, allowed by herd.
> *)
> {
> 0:r1=x; 0:r2=y; 0:r3=z;
> 1:r1=x; 1:r2=y; 1:r3=z; 1:r4=1;
> 2:r1=x; 2:r2=y; 2:r3=z; 2:r4=1; 2:r5=2;
> }
>  P0   | P1| P2;
>  lwz r6,0(r1) | stw r4,0(r2)  | stw r5,0(r3)  ;
>  xor r7,r6,r6 | lwsync| lwsync;
>  lwzx r7,r7,r2| stw r4,0(r3)  | stw r4,0(r1)  ;
>  lwz r8,0(r3) |   |   ;
> 
> exists
> (z=2 /\ 0:r6=1 /\ 0:r7=0 /\ 0:r8=1)

That really hurts. Assuming that the "assert(!(z=2))" is actually there
to constrain the coherence order of z to be {0->1->2}, then I think that
this test is forbidden on arm using dmb instead of lwsync. That said, I
also don't think the Rz=1 in P0 changes anything.

The double negatives don't help here! (it is forbidden to guarantee that
z is not always 2).

Will
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v6 0/9] ftrace with regs + live patching for ppc64 LE (ABI v2)

[Torsten Duwe]

Changes since v5:
  * extra "std r0,LRSAVE(r1)" for gcc-6
This makes the code compiler-agnostic.
  * Follow Petr Mladek's suggestion to avoid
redefinition of HAVE_LIVEPATCH

Changes since v4:
  * change comment style in entry_64.S to C89
(nobody is using assembler syntax comments there).
  * the bool function restore_r2 shouldn't return 2,
that's a little confusing.
  * Test whether the compiler supports -mprofile-kernel
and only then define CC_USING_MPROFILE_KERNEL
  * also make the return value of klp_check_compiler_support
depend on that.

Major changes since v3:
  * the graph tracer works now.
It turned out the stack frame it tried to manipulate does not
exist at that point.
  * changes only needed in order to support -mprofile-kernel are now
in a separate patch, prepended.
  * Kconfig cleanup so this is only selectable on ppc64le.


Torsten Duwe (9):
  ppc64 (le): prepare for -mprofile-kernel
  ppc64le FTRACE_WITH_REGS implementation
  ppc use ftrace_modify_all_code default
  ppc64 ftrace_with_regs configuration variables
  ppc64 ftrace_with_regs: spare early boot and low level
  ppc64 ftrace: disable profiling for some functions
  ppc64 ftrace: disable profiling for some files
  Implement kernel live patching for ppc64le (ABIv2)
  Enable LIVEPATCH to be configured on ppc64le and add livepatch.o if it
is selected.

 arch/powerpc/Kconfig |   7 ++
 arch/powerpc/Makefile|  10 +++
 arch/powerpc/include/asm/ftrace.h|   5 ++
 arch/powerpc/include/asm/livepatch.h |  45 ++
 arch/powerpc/kernel/Makefile |  13 +--
 arch/powerpc/kernel/entry_64.S   | 166 ++-
 arch/powerpc/kernel/ftrace.c |  88 ++-
 arch/powerpc/kernel/livepatch.c  |  38 
 arch/powerpc/kernel/module_64.c  |  39 +++-
 arch/powerpc/kernel/process.c|   2 +-
 arch/powerpc/lib/Makefile|   4 +-
 arch/powerpc/mm/fault.c  |   2 +-
 arch/powerpc/mm/hash_utils_64.c  |  18 ++--
 arch/powerpc/mm/hugetlbpage-hash64.c |   2 +-
 arch/powerpc/mm/hugetlbpage.c|   4 +-
 arch/powerpc/mm/mem.c|   2 +-
 arch/powerpc/mm/pgtable_64.c |   2 +-
 arch/powerpc/mm/slb.c|   6 +-
 arch/powerpc/mm/slice.c  |   8 +-
 kernel/trace/Kconfig |   5 ++
 20 files changed, 412 insertions(+), 54 deletions(-)
 create mode 100644 arch/powerpc/include/asm/livepatch.h
 create mode 100644 arch/powerpc/kernel/livepatch.c

-- 
1.8.5.6

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v6 1/9] ppc64 (le): prepare for -mprofile-kernel

[Torsten Duwe]

The gcc switch -mprofile-kernel, available for ppc64 on gcc > 4.8.5,
allows to call _mcount very early in the function, which low-level
ASM code and code patching functions need to consider.
Especially the link register and the parameter registers are still
alive and not yet saved into a new stack frame.

Signed-off-by: Torsten Duwe 
---
 arch/powerpc/kernel/entry_64.S  | 45 +++--
 arch/powerpc/kernel/ftrace.c| 12 +--
 arch/powerpc/kernel/module_64.c | 14 +
 3 files changed, 67 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index a94f155..e7cd043 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -1206,7 +1206,12 @@ _GLOBAL(enter_prom)
 #ifdef CONFIG_DYNAMIC_FTRACE
 _GLOBAL(mcount)
 _GLOBAL(_mcount)
-   blr
+   std r0,LRSAVE(r1) /* gcc6 does this _after_ this call _only_ */
+   mflrr0
+   mtctr   r0
+   ld  r0,LRSAVE(r1)
+   mtlrr0
+   bctr
 
 _GLOBAL_TOC(ftrace_caller)
/* Taken from output of objdump from lib64/glibc */
@@ -1262,13 +1267,28 @@ _GLOBAL(ftrace_stub)
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 _GLOBAL(ftrace_graph_caller)
+#ifdef CC_USING_MPROFILE_KERNEL
+   /* with -mprofile-kernel, parameter regs are still alive at _mcount */
+   std r10, 104(r1)
+   std r9, 96(r1)
+   std r8, 88(r1)
+   std r7, 80(r1)
+   std r6, 72(r1)
+   std r5, 64(r1)
+   std r4, 56(r1)
+   std r3, 48(r1)
+   mfctr   r4  /* ftrace_caller has moved local addr here */
+   std r4, 40(r1)
+   mflrr3  /* ftrace_caller has restored LR from stack */
+#else
/* load r4 with local address */
ld  r4, 128(r1)
-   subir4, r4, MCOUNT_INSN_SIZE
 
/* Grab the LR out of the caller stack frame */
ld  r11, 112(r1)
ld  r3, 16(r11)
+#endif
+   subir4, r4, MCOUNT_INSN_SIZE
 
bl  prepare_ftrace_return
nop
@@ -1277,6 +1297,26 @@ _GLOBAL(ftrace_graph_caller)
 * prepare_ftrace_return gives us the address we divert to.
 * Change the LR in the callers stack frame to this.
 */
+
+#ifdef CC_USING_MPROFILE_KERNEL
+   mtlrr3
+
+   ld  r0, 40(r1)
+   mtctr   r0
+   ld  r10, 104(r1)
+   ld  r9, 96(r1)
+   ld  r8, 88(r1)
+   ld  r7, 80(r1)
+   ld  r6, 72(r1)
+   ld  r5, 64(r1)
+   ld  r4, 56(r1)
+   ld  r3, 48(r1)
+
+   addir1, r1, 112
+   mflrr0
+   std r0, LRSAVE(r1)
+   bctr
+#else
ld  r11, 112(r1)
std r3, 16(r11)
 
@@ -1284,6 +1324,7 @@ _GLOBAL(ftrace_graph_caller)
mtlrr0
addir1, r1, 112
blr
+#endif
 
 _GLOBAL(return_to_handler)
/* need to save return values */
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 44d4d8e..080c525 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -306,11 +306,19 @@ __ftrace_make_call(struct dyn_ftrace *rec, unsigned long 
addr)
 * The load offset is different depending on the ABI. For simplicity
 * just mask it out when doing the compare.
 */
+#ifndef CC_USING_MPROFILE_KERNEL
if ((op[0] != 0x4808) || ((op[1] & 0x) != 0xe841)) {
-   pr_err("Unexpected call sequence: %x %x\n", op[0], op[1]);
+   pr_err("Unexpected call sequence at %p: %x %x\n",
+   ip, op[0], op[1]);
return -EINVAL;
}
-
+#else
+   /* look for patched "NOP" on ppc64 with -mprofile-kernel */
+   if (op[0] != 0x6000) {
+   pr_err("Unexpected call at %p: %x\n", ip, op[0]);
+   return -EINVAL;
+   }
+#endif
/* If we never set up a trampoline to ftrace_caller, then bail */
if (!rec->arch.mod->arch.tramp) {
pr_err("No ftrace trampoline\n");
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 6838451..30f6be1 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -475,6 +475,20 @@ static unsigned long stub_for_addr(Elf64_Shdr *sechdrs,
 static int restore_r2(u32 *instruction, struct module *me)
 {
if (*instruction != PPC_INST_NOP) {
+#ifdef CC_USING_MPROFILE_KERNEL
+   /* -mprofile_kernel sequence starting with
+* mflr r0 and maybe std r0, LRSAVE(r1)
+*/
+   if ((instruction[-3] == 0x7c0802a6 &&
+   instruction[-2] == 0xf8010010) ||
+   instruction[-2] == 0x7c0802a6) {
+   /* Nothing to be done here, it's an _mcount
+* call location and r2 will have to be
+* restored in the _mcount function.
+ 

[PATCH v6 2/9] ppc64le FTRACE_WITH_REGS implementation

[Torsten Duwe]

Implement FTRACE_WITH_REGS for powerpc64, on ELF ABI v2.
Initial work started by Vojtech Pavlik, used with permission.

  * arch/powerpc/kernel/entry_64.S:
- Implement an effective ftrace_caller that works from
  within the kernel binary as well as from modules.
  * arch/powerpc/kernel/ftrace.c:
- be prepared to deal with ppc64 ELF ABI v2, especially
  calls to _mcount that result from gcc -mprofile-kernel
- a little more error verbosity
  * arch/powerpc/kernel/module_64.c:
- do not save the TOC pointer on the trampoline when the
  destination is ftrace_caller. This trampoline jump happens from
  a function prologue before a new stack frame is set up, so bad
  things may happen otherwise...
- relax is_module_trampoline() to recognise the modified
  trampoline.

Signed-off-by: Torsten Duwe 
---
 arch/powerpc/include/asm/ftrace.h |  5 +++
 arch/powerpc/kernel/entry_64.S| 78 +++
 arch/powerpc/kernel/ftrace.c  | 60 +++---
 arch/powerpc/kernel/module_64.c   | 25 -
 4 files changed, 161 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/include/asm/ftrace.h 
b/arch/powerpc/include/asm/ftrace.h
index ef89b14..50ca758 100644
--- a/arch/powerpc/include/asm/ftrace.h
+++ b/arch/powerpc/include/asm/ftrace.h
@@ -46,6 +46,8 @@
 extern void _mcount(void);
 
 #ifdef CONFIG_DYNAMIC_FTRACE
+# define FTRACE_ADDR ((unsigned long)ftrace_caller)
+# define FTRACE_REGS_ADDR FTRACE_ADDR
 static inline unsigned long ftrace_call_adjust(unsigned long addr)
 {
/* reloction of mcount call site is the same as the address */
@@ -58,6 +60,9 @@ struct dyn_arch_ftrace {
 #endif /*  CONFIG_DYNAMIC_FTRACE */
 #endif /* __ASSEMBLY__ */
 
+#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
+#define ARCH_SUPPORTS_FTRACE_OPS 1
+#endif
 #endif
 
 #if defined(CONFIG_FTRACE_SYSCALLS) && defined(CONFIG_PPC64) && 
!defined(__ASSEMBLY__)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index e7cd043..9e98aa1 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -1213,6 +1213,7 @@ _GLOBAL(_mcount)
mtlrr0
bctr
 
+#ifndef CC_USING_MPROFILE_KERNEL
 _GLOBAL_TOC(ftrace_caller)
/* Taken from output of objdump from lib64/glibc */
mflrr3
@@ -1234,6 +1235,83 @@ _GLOBAL(ftrace_graph_stub)
ld  r0, 128(r1)
mtlrr0
addir1, r1, 112
+#else
+_GLOBAL(ftrace_caller)
+   std r0,LRSAVE(r1)
+#if defined(_CALL_ELF) && _CALL_ELF == 2
+   mflrr0
+   bl  2f
+2: mflrr12
+   mtlrr0
+   mr  r0,r2   /* save callee's TOC */
+   addis   r2,r12,(.TOC.-ftrace_caller-12)@ha
+   addir2,r2,(.TOC.-ftrace_caller-12)@l
+#else
+   mr  r0,r2
+#endif
+   ld  r12,LRSAVE(r1)  /* get caller's address */
+
+   stdur1,-SWITCH_FRAME_SIZE(r1)
+
+   std r12, _LINK(r1)
+   SAVE_8GPRS(0,r1)
+   std r0, 24(r1)  /* save TOC */
+   SAVE_8GPRS(8,r1)
+   SAVE_8GPRS(16,r1)
+   SAVE_8GPRS(24,r1)
+
+   addis   r3,r2,function_trace_op@toc@ha
+   addir3,r3,function_trace_op@toc@l
+   ld  r5,0(r3)
+
+   mflrr3
+   std r3, _NIP(r1)
+   std r3, 16(r1)
+   subir3, r3, MCOUNT_INSN_SIZE
+   mfmsr   r4
+   std r4, _MSR(r1)
+   mfctr   r4
+   std r4, _CTR(r1)
+   mfxer   r4
+   std r4, _XER(r1)
+   mr  r4, r12
+   addir6, r1 ,STACK_FRAME_OVERHEAD
+
+.globl ftrace_call
+ftrace_call:
+   bl  ftrace_stub
+   nop
+
+   ld  r3, _NIP(r1)
+   mtlrr3
+
+   REST_8GPRS(0,r1)
+   REST_8GPRS(8,r1)
+   REST_8GPRS(16,r1)
+   REST_8GPRS(24,r1)
+
+   addi r1, r1, SWITCH_FRAME_SIZE
+
+   ld  r12, LRSAVE(r1)  /* get caller's address */
+   mtlrr12
+   mr  r2,r0   /* restore callee's TOC */
+
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+   stdur1, -112(r1)
+.globl ftrace_graph_call
+ftrace_graph_call:
+   b   ftrace_graph_stub
+_GLOBAL(ftrace_graph_stub)
+   addir1, r1, 112
+#endif
+
+   mflrr0  /* move this LR to CTR */
+   mtctr   r0
+
+   ld  r0,LRSAVE(r1)   /* restore callee's lr at _mcount site */
+   mtlrr0
+   bctr/* jump after _mcount site */
+#endif /* CC_USING_MPROFILE_KERNEL */
 _GLOBAL(ftrace_stub)
blr
 #else
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 080c525..310137f 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -61,8 +61,11 @@ ftrace_modify_code(unsigned long ip, unsigned int old, 
unsigned int new)
return -EFAULT;
 
/* Make sure it is what we expect it to be */
-   if (replaced != old)
+   if (replaced != old) {
+   pr_err("%p: replaced (%#x) != old (%#x)",
+   (

[PATCH v6 3/9] ppc use ftrace_modify_all_code default

[Torsten Duwe]

Convert ppc's arch_ftrace_update_code from its own function copy
to use the generic default functionality (without stop_machine --
our instructions are properly aligned and the replacements atomic ;)

With this we gain error checking and the much-needed function_trace_op
handling.

Signed-off-by: Torsten Duwe 
---
 arch/powerpc/kernel/ftrace.c | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 310137f..e419c7b 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -511,20 +511,12 @@ void ftrace_replace_code(int enable)
}
 }
 
+/* Use the default ftrace_modify_all_code, but without
+ * stop_machine().
+ */
 void arch_ftrace_update_code(int command)
 {
-   if (command & FTRACE_UPDATE_CALLS)
-   ftrace_replace_code(1);
-   else if (command & FTRACE_DISABLE_CALLS)
-   ftrace_replace_code(0);
-
-   if (command & FTRACE_UPDATE_TRACE_FUNC)
-   ftrace_update_ftrace_func(ftrace_trace_function);
-
-   if (command & FTRACE_START_FUNC_RET)
-   ftrace_enable_ftrace_graph_caller();
-   else if (command & FTRACE_STOP_FUNC_RET)
-   ftrace_disable_ftrace_graph_caller();
+   ftrace_modify_all_code(command);
 }
 
 int __init ftrace_dyn_arch_init(void)
-- 
1.8.5.6

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v6 4/9] ppc64 ftrace_with_regs configuration variables

[Torsten Duwe]

  * Makefile:
- globally use -mprofile-kernel in case it's configured
  and available.
  * arch/powerpc/Kconfig / kernel/trace/Kconfig:
- declare that ppc64le HAVE_MPROFILE_KERNEL and
  HAVE_DYNAMIC_FTRACE_WITH_REGS, and use it.

Signed-off-by: Torsten Duwe 
---
 arch/powerpc/Kconfig  |  2 ++
 arch/powerpc/Makefile | 10 ++
 kernel/trace/Kconfig  |  5 +
 3 files changed, 17 insertions(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index db49e0d..89b1a2a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -97,8 +97,10 @@ config PPC
select OF_RESERVED_MEM
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_DYNAMIC_FTRACE
+   select HAVE_DYNAMIC_FTRACE_WITH_REGS if PPC64 && CPU_LITTLE_ENDIAN
select HAVE_FUNCTION_TRACER
select HAVE_FUNCTION_GRAPH_TRACER
+   select HAVE_MPROFILE_KERNEL if PPC64 && CPU_LITTLE_ENDIAN
select SYSCTL_EXCEPTION_TRACE
select ARCH_WANT_OPTIONAL_GPIOLIB
select VIRT_TO_BUS if !PPC64
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 96efd82..2f9b527 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -133,6 +133,16 @@ else
 CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=powerpc64
 endif
 
+ifeq ($(CONFIG_PPC64),y)
+ifdef CONFIG_HAVE_MPROFILE_KERNEL
+CC_USING_MPROFILE_KERNEL := $(call cc-option,-mprofile-kernel)
+ifdef CC_USING_MPROFILE_KERNEL
+CC_FLAGS_FTRACE:= -pg $(CC_USING_MPROFILE_KERNEL)
+KBUILD_CPPFLAGS+= -DCC_USING_MPROFILE_KERNEL
+endif
+endif
+endif
+
 CFLAGS-$(CONFIG_CELL_CPU) += $(call cc-option,-mcpu=cell)
 CFLAGS-$(CONFIG_POWER4_CPU) += $(call cc-option,-mcpu=power4)
 CFLAGS-$(CONFIG_POWER5_CPU) += $(call cc-option,-mcpu=power5)
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index e45db6b..a138f6d 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -52,6 +52,11 @@ config HAVE_FENTRY
help
  Arch supports the gcc options -pg with -mfentry
 
+config HAVE_MPROFILE_KERNEL
+   bool
+   help
+ Arch supports the gcc options -pg with -mprofile-kernel
+
 config HAVE_C_RECORDMCOUNT
bool
help
-- 
1.8.5.6

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v6 7/9] ppc64 ftrace: disable profiling for some files

[Torsten Duwe]

This patch complements the "notrace" attribute for selected functions.
It adds -mprofile-kernel to the cc flags to be stripped from the command
line for code-patching.o and feature-fixups.o, in addition to "-pg"

Signed-off-by: Torsten Duwe 
---
 arch/powerpc/lib/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index a47e142..98e22b2 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -6,8 +6,8 @@ subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
 
 ccflags-$(CONFIG_PPC64):= $(NO_MINIMAL_TOC)
 
-CFLAGS_REMOVE_code-patching.o = -pg
-CFLAGS_REMOVE_feature-fixups.o = -pg
+CFLAGS_REMOVE_code-patching.o = -pg -mprofile-kernel
+CFLAGS_REMOVE_feature-fixups.o = -pg -mprofile-kernel
 
 obj-y += string.o alloc.o crtsavres.o ppc_ksyms.o code-patching.o \
 feature-fixups.o
-- 
1.8.5.6

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v6 8/9] Implement kernel live patching for ppc64le (ABIv2)

[Torsten Duwe]

  * create the appropriate files+functions
arch/powerpc/include/asm/livepatch.h
klp_check_compiler_support,
klp_arch_set_pc
arch/powerpc/kernel/livepatch.c with a stub for
klp_write_module_reloc
This is architecture-independent work in progress.
  * introduce a fixup in arch/powerpc/kernel/entry_64.S
for local calls that are becoming global due to live patching.
And of course do the main KLP thing: return to a maybe different
address, possibly altered by the live patching ftrace op.

Signed-off-by: Torsten Duwe 
---
 arch/powerpc/include/asm/livepatch.h | 45 +++
 arch/powerpc/kernel/entry_64.S   | 51 +---
 arch/powerpc/kernel/livepatch.c  | 38 +++
 3 files changed, 130 insertions(+), 4 deletions(-)
 create mode 100644 arch/powerpc/include/asm/livepatch.h
 create mode 100644 arch/powerpc/kernel/livepatch.c

diff --git a/arch/powerpc/include/asm/livepatch.h 
b/arch/powerpc/include/asm/livepatch.h
new file mode 100644
index 000..44e8a2d
--- /dev/null
+++ b/arch/powerpc/include/asm/livepatch.h
@@ -0,0 +1,45 @@
+/*
+ * livepatch.h - powerpc-specific Kernel Live Patching Core
+ *
+ * Copyright (C) 2015 SUSE
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ */
+#ifndef _ASM_POWERPC64_LIVEPATCH_H
+#define _ASM_POWERPC64_LIVEPATCH_H
+
+#include 
+#include 
+
+#ifdef CONFIG_LIVEPATCH
+static inline int klp_check_compiler_support(void)
+{
+#if !defined(_CALL_ELF) || _CALL_ELF != 2 || !defined(CC_USING_MPROFILE_KERNEL)
+   return 1;
+#endif
+   return 0;
+}
+
+extern int klp_write_module_reloc(struct module *mod, unsigned long type,
+  unsigned long loc, unsigned long value);
+
+static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
+{
+   regs->nip = ip;
+}
+#else
+#error Live patching support is disabled; check CONFIG_LIVEPATCH
+#endif
+
+#endif /* _ASM_POWERPC64_LIVEPATCH_H */
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 9e98aa1..f6e3ee7 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -1267,6 +1267,9 @@ _GLOBAL(ftrace_caller)
mflrr3
std r3, _NIP(r1)
std r3, 16(r1)
+#ifdef CONFIG_LIVEPATCH
+   mr  r14,r3  /* remember old NIP */
+#endif
subir3, r3, MCOUNT_INSN_SIZE
mfmsr   r4
std r4, _MSR(r1)
@@ -1283,7 +1286,10 @@ ftrace_call:
nop
 
ld  r3, _NIP(r1)
-   mtlrr3
+   mtctr   r3  /* prepare to jump there */
+#ifdef CONFIG_LIVEPATCH
+   cmpdr14,r3  /* has NIP been altered? */
+#endif
 
REST_8GPRS(0,r1)
REST_8GPRS(8,r1)
@@ -1296,6 +1302,27 @@ ftrace_call:
mtlrr12
mr  r2,r0   /* restore callee's TOC */
 
+#ifdef CONFIG_LIVEPATCH
+   beq+4f  /* likely(old_NIP == new_NIP) */
+
+   /* For a local call, restore this TOC after calling the patch function.
+* For a global call, it does not matter what we restore here,
+* since the global caller does its own restore right afterwards,
+* anyway. Just insert a KLP_return_helper frame in any case,
+* so a patch function can always count on the changed stack offsets.
+*/
+   stdur1,-32(r1)  /* open new mini stack frame */
+   std r0,24(r1)   /* save TOC now, unconditionally. */
+   bl  5f
+5: mflrr12
+   addir12,r12,(KLP_return_helper+4-.)@l
+   std r12,LRSAVE(r1)
+   mtlrr12
+   mfctr   r12 /* allow for TOC calculation in newfunc */
+   bctr
+4:
+#endif
+
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
stdur1, -112(r1)
 .globl ftrace_graph_call
@@ -1305,15 +1332,31 @@ _GLOBAL(ftrace_graph_stub)
addir1, r1, 112
 #endif
 
-   mflrr0  /* move this LR to CTR */
-   mtctr   r0
-
ld  r0,LRSAVE(r1)   /* restore callee's lr at _mcount site */
mtlrr0
bctr/* jump after _mcount site */
 #endif /* CC_USING_MPROFILE_KERNEL */
 _GLOBAL(ftrace_stub)
blr
+
+#ifdef CONFIG_LIVEPATCH
+/* Helper function for local calls that are becoming global
+   due to live patching.
+   We can't simply patch t

[PATCH v6 9/9] Enable LIVEPATCH to be configured on ppc64le and add livepatch.o if it is selected.

[Torsten Duwe]

Signed-off-by: Torsten Duwe 
---
 arch/powerpc/Kconfig |3 +++
 arch/powerpc/kernel/Makefile |1 +
 2 files changed, 4 insertions(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 89b1a2a..62a3f54 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -162,6 +162,7 @@ config PPC
select EDAC_ATOMIC_SCRUB
select ARCH_HAS_DMA_SET_COHERENT_MASK
select HAVE_ARCH_SECCOMP_FILTER
+   select HAVE_LIVEPATCH if PPC64 && CPU_LITTLE_ENDIAN
 
 config GENERIC_CSUM
def_bool CPU_LITTLE_ENDIAN
@@ -1095,3 +1098,5 @@ config PPC_LIB_RHEAP
bool
 
 source "arch/powerpc/kvm/Kconfig"
+
+source "kernel/livepatch/Kconfig"
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 0f417d5..f9a2925 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -119,6 +119,7 @@ obj-$(CONFIG_DYNAMIC_FTRACE)+= ftrace.o
 obj-$(CONFIG_FUNCTION_GRAPH_TRACER)+= ftrace.o
 obj-$(CONFIG_FTRACE_SYSCALLS)  += ftrace.o
 obj-$(CONFIG_TRACING)  += trace_clock.o
+obj-$(CONFIG_LIVEPATCH)+= livepatch.o
 
 ifneq ($(CONFIG_PPC_INDIRECT_PIO),y)
 obj-y  += iomap.o
-- 
1.8.5.6

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v6 5/9] ppc64 ftrace_with_regs: spare early boot and low level

[Torsten Duwe]

Using -mprofile-kernel on early boot code not only confuses the
checker but is also useless, as the infrastructure is not yet in
place. Proceed like with -pg (remove it from CFLAGS), equally with
time.o and ftrace itself.

  * arch/powerpc/kernel/Makefile:
- remove -mprofile-kernel from low level and boot code objects'
  CFLAGS for FUNCTION_TRACER configurations.

Signed-off-by: Torsten Duwe 
---
 arch/powerpc/kernel/Makefile | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index ba33693..0f417d5 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -16,14 +16,14 @@ endif
 
 ifdef CONFIG_FUNCTION_TRACER
 # Do not trace early boot code
-CFLAGS_REMOVE_cputable.o = -pg -mno-sched-epilog
-CFLAGS_REMOVE_prom_init.o = -pg -mno-sched-epilog
-CFLAGS_REMOVE_btext.o = -pg -mno-sched-epilog
-CFLAGS_REMOVE_prom.o = -pg -mno-sched-epilog
+CFLAGS_REMOVE_cputable.o = -pg -mno-sched-epilog -mprofile-kernel
+CFLAGS_REMOVE_prom_init.o = -pg -mno-sched-epilog -mprofile-kernel
+CFLAGS_REMOVE_btext.o = -pg -mno-sched-epilog -mprofile-kernel
+CFLAGS_REMOVE_prom.o = -pg -mno-sched-epilog -mprofile-kernel
 # do not trace tracer code
-CFLAGS_REMOVE_ftrace.o = -pg -mno-sched-epilog
+CFLAGS_REMOVE_ftrace.o = -pg -mno-sched-epilog -mprofile-kernel
 # timers used by tracing
-CFLAGS_REMOVE_time.o = -pg -mno-sched-epilog
+CFLAGS_REMOVE_time.o = -pg -mno-sched-epilog -mprofile-kernel
 endif
 
 obj-y  := cputable.o ptrace.o syscalls.o \
-- 
1.8.5.6

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v6 6/9] ppc64 ftrace: disable profiling for some functions

[Torsten Duwe]

At least POWER7/8 have MMUs that don't completely autoload;
a normal, recoverable memory fault might pass through these functions.
If a dynamic tracer function causes such a fault, any of these functions
being traced with -mprofile-kernel may cause an endless recursion.

Signed-off-by: Torsten Duwe 
---
 arch/powerpc/kernel/process.c|  2 +-
 arch/powerpc/mm/fault.c  |  2 +-
 arch/powerpc/mm/hash_utils_64.c  | 18 +-
 arch/powerpc/mm/hugetlbpage-hash64.c |  2 +-
 arch/powerpc/mm/hugetlbpage.c|  4 ++--
 arch/powerpc/mm/mem.c|  2 +-
 arch/powerpc/mm/pgtable_64.c |  2 +-
 arch/powerpc/mm/slb.c|  6 +++---
 arch/powerpc/mm/slice.c  |  8 
 9 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 646bf4d..5b3c19d 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -733,7 +733,7 @@ static inline void __switch_to_tm(struct task_struct *prev)
  * don't know which of the checkpointed state and the transactional
  * state to use.
  */
-void restore_tm_state(struct pt_regs *regs)
+notrace void restore_tm_state(struct pt_regs *regs)
 {
unsigned long msr_diff;
 
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index a67c6d7..125be37 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -205,7 +205,7 @@ static int mm_fault_error(struct pt_regs *regs, unsigned 
long addr, int fault)
  * The return value is 0 if the fault was handled, or the signal
  * number if this is a kernel fault that can't be handled here.
  */
-int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
+notrace int __kprobes do_page_fault(struct pt_regs *regs, unsigned long 
address,
unsigned long error_code)
 {
enum ctx_state prev_state = exception_enter();
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 7f9616f..64f5b40 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -849,7 +849,7 @@ void early_init_mmu_secondary(void)
 /*
  * Called by asm hashtable.S for doing lazy icache flush
  */
-unsigned int hash_page_do_lazy_icache(unsigned int pp, pte_t pte, int trap)
+notrace unsigned int hash_page_do_lazy_icache(unsigned int pp, pte_t pte, int 
trap)
 {
struct page *page;
 
@@ -870,7 +870,7 @@ unsigned int hash_page_do_lazy_icache(unsigned int pp, 
pte_t pte, int trap)
 }
 
 #ifdef CONFIG_PPC_MM_SLICES
-static unsigned int get_paca_psize(unsigned long addr)
+static notrace unsigned int get_paca_psize(unsigned long addr)
 {
u64 lpsizes;
unsigned char *hpsizes;
@@ -899,7 +899,7 @@ unsigned int get_paca_psize(unsigned long addr)
  * For now this makes the whole process use 4k pages.
  */
 #ifdef CONFIG_PPC_64K_PAGES
-void demote_segment_4k(struct mm_struct *mm, unsigned long addr)
+notrace void demote_segment_4k(struct mm_struct *mm, unsigned long addr)
 {
if (get_slice_psize(mm, addr) == MMU_PAGE_4K)
return;
@@ -920,7 +920,7 @@ void demote_segment_4k(struct mm_struct *mm, unsigned long 
addr)
  * Result is 0: full permissions, _PAGE_RW: read-only,
  * _PAGE_USER or _PAGE_USER|_PAGE_RW: no access.
  */
-static int subpage_protection(struct mm_struct *mm, unsigned long ea)
+static notrace int subpage_protection(struct mm_struct *mm, unsigned long ea)
 {
struct subpage_prot_table *spt = &mm->context.spt;
u32 spp = 0;
@@ -968,7 +968,7 @@ void hash_failure_debug(unsigned long ea, unsigned long 
access,
trap, vsid, ssize, psize, lpsize, pte);
 }
 
-static void check_paca_psize(unsigned long ea, struct mm_struct *mm,
+static notrace void check_paca_psize(unsigned long ea, struct mm_struct *mm,
 int psize, bool user_region)
 {
if (user_region) {
@@ -990,7 +990,7 @@ static void check_paca_psize(unsigned long ea, struct 
mm_struct *mm,
  * -1 - critical hash insertion error
  * -2 - access not permitted by subpage protection mechanism
  */
-int hash_page_mm(struct mm_struct *mm, unsigned long ea,
+notrace int hash_page_mm(struct mm_struct *mm, unsigned long ea,
 unsigned long access, unsigned long trap,
 unsigned long flags)
 {
@@ -1187,7 +1187,7 @@ bail:
 }
 EXPORT_SYMBOL_GPL(hash_page_mm);
 
-int hash_page(unsigned long ea, unsigned long access, unsigned long trap,
+notrace int hash_page(unsigned long ea, unsigned long access, unsigned long 
trap,
  unsigned long dsisr)
 {
unsigned long flags = 0;
@@ -1289,7 +1289,7 @@ out_exit:
 /* WARNING: This is called from hash_low_64.S, if you change this prototype,
  *  do not forget to update the assembly call site !
  */
-void flush_hash_page(unsigned long vpn, real_pte_t pte, int psize, int ssize,
+notrace void flush_hash_page(unsigned long vpn, real_pte_t pte, int psize, int 
ssi

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

[Will Deacon]

Hi Paul,

On Fri, Jan 15, 2016 at 09:39:12AM -0800, Paul E. McKenney wrote:
> On Fri, Jan 15, 2016 at 09:55:54AM +0100, Peter Zijlstra wrote:
> > On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote:
> > > So smp_mb() provides transitivity, as do pairs of smp_store_release()
> > > and smp_read_acquire(), 
> > 
> > But they provide different grades of transitivity, which is where all
> > the confusion lays.
> > 
> > smp_mb() is strongly/globally transitive, all CPUs will agree on the order.
> > 
> > Whereas the RCpc release+acquire is weakly so, only the two cpus
> > involved in the handover will agree on the order.
> 
> Good point!
> 
> Using grace periods in place of smp_mb() also provides strong/global
> transitivity, but also insanely high latencies.  ;-)
> 
> The patch below updates Documentation/memory-barriers.txt to define
> local vs. global transitivity.  The corresponding ppcmem litmus test
> is included below as well.
> 
> Should we start putting litmus tests for the various examples
> somewhere, perhaps in a litmus-tests directory within each participating
> architecture?  I have a pile of powerpc-related litmus tests on my laptop,
> but they probably aren't doing all that much good there.

I too would like to have the litmus tests in the kernel so that we can
refer to them from memory-barriers.txt. Ideally they wouldn't be targetted
to a particular arch, however.

> PPC local-transitive
> ""
> {
> 0:r1=1; 0:r2=u; 0:r3=v; 0:r4=x; 0:r5=y; 0:r6=z;
> 1:r1=1; 1:r2=u; 1:r3=v; 1:r4=x; 1:r5=y; 1:r6=z;
> 2:r1=1; 2:r2=u; 2:r3=v; 2:r4=x; 2:r5=y; 2:r6=z;
> 3:r1=1; 3:r2=u; 3:r3=v; 3:r4=x; 3:r5=y; 3:r6=z;
> }
>  P0   | P1   | P2   | P3   ;
>  lwz r9,0(r4) | lwz r9,0(r5) | lwz r9,0(r6) | stw r1,0(r3) ;
>  lwsync   | lwsync   | lwsync   | sync ;
>  stw r1,0(r2) | lwz r8,0(r3) | stw r1,0(r7) | lwz r9,0(r2) ;
>  lwsync   | lwz r7,0(r2) |  |  ;
>  stw r1,0(r5) | lwsync   |  |  ;
>   | stw r1,0(r6) |  |  ;
> exists
> (* (0:r9=0 /\ 1:r9=1 /\ 2:r9=1 /\ 1:r8=0 /\ 3:r9=0) *)
> (* (0:r9=1 /\ 1:r9=1 /\ 2:r9=1) *)
> (* (0:r9=0 /\ 1:r9=1 /\ 2:r9=1 /\ 1:r7=0) *)
> (0:r9=0 /\ 1:r9=1 /\ 2:r9=1 /\ 1:r7=0)

i.e. we should rewrite this using READ_ONCE/WRITE_ONCE and smp_mb() etc.

> 
> 
> commit 2cb4e83a1b5c89c8e39b8a64bd89269d05913e41
> Author: Paul E. McKenney 
> Date:   Fri Jan 15 09:30:42 2016 -0800
> 
> documentation: Distinguish between local and global transitivity
> 
> The introduction of smp_load_acquire() and smp_store_release() had
> the side effect of introducing a weaker notion of transitivity:
> The transitivity of full smp_mb() barriers is global, but that
> of smp_store_release()/smp_load_acquire() chains is local.  This
> commit therefore introduces the notion of local transitivity and
> gives an example.
> 
> Reported-by: Peter Zijlstra 
> Reported-by: Will Deacon 
> Signed-off-by: Paul E. McKenney 
> 
> diff --git a/Documentation/memory-barriers.txt 
> b/Documentation/memory-barriers.txt
> index c66ba46d8079..d8109ed99342 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -1318,8 +1318,82 @@ or a level of cache, CPU 2 might have early access to 
> CPU 1's writes.
>  General barriers are therefore required to ensure that all CPUs agree
>  on the combined order of CPU 1's and CPU 2's accesses.
>  
> -To reiterate, if your code requires transitivity, use general barriers
> -throughout.
> +General barriers provide "global transitivity", so that all CPUs will
> +agree on the order of operations.  In contrast, a chain of release-acquire
> +pairs provides only "local transitivity", so that only those CPUs on
> +the chain are guaranteed to agree on the combined order of the accesses.

Thanks for having a go at this. I tried defining something axiomatically,
but got stuck pretty quickly. In my scheme, I used "data-directed
transitivity" instead of "local transitivity", since the latter seems to
be a bit of a misnomer.

> +For example, switching to C code in deference to Herman Hollerith:
> +
> + int u, v, x, y, z;
> +
> + void cpu0(void)
> + {
> + r0 = smp_load_acquire(&x);
> + WRITE_ONCE(u, 1);
> + smp_store_release(&y, 1);
> + }
> +
> + void cpu1(void)
> + {
> + r1 = smp_load_acquire(&y);
> + r4 = READ_ONCE(v);
> + r5 = READ_ONCE(u);
> + smp_store_release(&z, 1);
> + }
> +
> + void cpu2(void)
> + {
> + r2 = smp_load_acquire(&z);
> + smp_store_release(&x, 1);
> + }
> +
> + void cpu3(void)
> + {
> + WRITE_ONCE(v, 1);
> + smp_mb();
> + r3 = READ_ONCE(u);
> + }
> +
> +Because cpu0(), cpu1(), and cpu2() participat

Re: [PATCH v4 0/3] kallsyms base relative series

[Guenter Roeck]

On 01/25/2016 06:19 AM, Ard Biesheuvel wrote:

This v4 of my kallsyms base relative implementation is now a 3 piece series,
since it caused some problems due to the way absolute symbols are handled
by the absolute per cpu code. As it turns out, that code was probably wrong
in the sense that it caused non-relocated symbol addresses to be emitted
for values that are in fact relative to the address of the kernel text.

Patch #1 fixes the scripts/kallsyms invocation to only pass the x86_64
specific --absolute-percpu option if CONFIG_SMP is also set.

Patch #2 reworks the absolute percpu code to only emit those percpu symbols
as absolute, and not symbols that have been classified as 'A' (absolute) by
the linker, since that does not mean quite the same thing.

Patch #3 is the original kallsyms base relative patch, with some
modifications:
- folded the s/ULLONG_MAX/-1ULL? change made by Andrew
- ensured that the kallsyms_relative_base value itself is relocated as
   required.
- dropped all of the acks and other tags, as they have become outdated with
   the recent changes to this patch.



I tested the series on top of mmotm (after reverting the original patches).
Qemu tests for mips, sparc, and x86 (both smp and nosmp) now pass.

Tested-by: Guenter Roeck 


Ard Biesheuvel (3):
   x86: kallsyms: disable absolute percpu symbols on !SMP
   kallsyms: don't overload absolute symbol type for percpu symbols
   kallsyms: add support for relative offsets in kallsyms address table

  init/Kconfig|  16 +++
  kernel/kallsyms.c   |  38 ++--
  scripts/kallsyms.c  | 102 +---
  scripts/link-vmlinux.sh |   6 +-
  scripts/namespace.pl|   2 +
  5 files changed, 142 insertions(+), 22 deletions(-)



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/mm: Allow user space to map rtas_rmo_buf

[Nathan Fontenot]

On 01/22/2016 02:35 AM, Michael Ellerman wrote:
> On Fri, 2016-01-22 at 11:58 +0530, Vasant Hegde wrote:
>> On 01/22/2016 10:59 AM, Michael Ellerman wrote:
>>> On Thu, 2016-01-21 at 21:45 +0530, Vasant Hegde wrote:
>>>
 With commit 90a545e9 (restrict /dev/mem to idle io memory ranges) mapping
 rtas_rmo_buf from user space is failing. Hence we are not able to make
 RTAS syscall.
>>>
>>> Having said that, why the  is librtas mapping /dev/mem in
>>> the first place? Unless there is a very good reason, and probably even if 
>>> there
>>> is, we should fix that to use a sane API.
>>
>> We use rtas system call. We use /dev/mem interface to map the RTAS memory 
>> region
>> (allocated by kernel and information is passed to user space via procfs) so 
>> that
>> we can read/write to RTAS memory.
>>
>> I do not have historical information. May be Nathan has more information on 
>> this.
> 
> Yeah, we need to dig into what it's actually doing and why. I had a quick look
> but it wasn't obvious.

This was done many years ago, going on memory for now...

I will have to dig back into this code further but what I remember is that the
following process is used. At boot time a piece of low memory (buffers passed
to rtas have to be in low memory) is reserved to use for rtas calls. This memory
is made available to userspace, namely the librtas library. The code in librtas
will then reserve pieces of this memory to use for buffers when making rtas
calls that require large buffers. I think the biggest user of this is the rtas
configure-connector call which can require two 1-page buffers.

If I remember correctly this was done to avoid having the kernel do all of the
copying to/from user of the buffers used.


> 
> We should not need 1) a system call, 2) a proc interface, and 3) a mmap of
> /dev/mem.
> 

It seems that we could move to an interface that just uses a syscall and have
the kernel copy the buffers in from userspace into the kernels reserved rtas
buffer space.

> If the syscall's not sufficient and we really need to mmap, we should create a
> device which can then be mmapped in a more standard way.
> 
This would also work if having the kernel copy the buffers is not what we
want to do.

-Nathan

> Having said that, Nathan's been moving more of the hotplug logic into the
> kernel, so I'm also not clear on how much of the existing API we will need in
> the future. So yep hopefully Nathan can chime in.
> 
> cheers
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/mm: Allow user space to map rtas_rmo_buf

[Nathan Fontenot]

On 01/22/2016 04:41 AM, Denis Kirjanov wrote:
> On 1/22/16, Michael Ellerman  wrote:
>> On Fri, 2016-01-22 at 11:58 +0530, Vasant Hegde wrote:
>>> On 01/22/2016 10:59 AM, Michael Ellerman wrote:
 On Thu, 2016-01-21 at 21:45 +0530, Vasant Hegde wrote:

> With commit 90a545e9 (restrict /dev/mem to idle io memory ranges)
> mapping
> rtas_rmo_buf from user space is failing. Hence we are not able to make
> RTAS syscall.

 Having said that, why the  is librtas mapping
 /dev/mem in
 the first place? Unless there is a very good reason, and probably even
 if there
 is, we should fix that to use a sane API.
>>>
>>> We use rtas system call. We use /dev/mem interface to map the RTAS memory
>>> region
>>> (allocated by kernel and information is passed to user space via procfs)
>>> so that
>>> we can read/write to RTAS memory.
>>>
>>> I do not have historical information. May be Nathan has more information
>>> on this.
>>
>> Yeah, we need to dig into what it's actually doing and why. I had a quick
>> look
>> but it wasn't obvious.
>>
>> We should not need 1) a system call, 2) a proc interface, and 3) a mmap of
>> /dev/mem.
>>
>> If the syscall's not sufficient and we really need to mmap, we should create
>> a
>> device which can then be mmapped in a more standard way.
>>
>> Having said that, Nathan's been moving more of the hotplug logic into the
>> kernel, so I'm also not clear on how much of the existing API we will need
>> in
>> the future. So yep hopefully Nathan can chime in.
> 
> Yeah, but if we're going to move to only one interface to work with
> RTAS we can break existing applications.
> 

Yes, but I doubt that anything other than librtas is using this. I don't think
this interface was ever documented anywhere.

-Nathan

>>
>> cheers
>>
>> ___
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] 82xx: FCC: Fixing a bug causing to FCC port lock-up (second try)

[David Miller]

From: Martin Roth 
Date: Sun, 24 Jan 2016 00:56:19 +0200

> This is an additional patch to the one already submitted recently.
> The previous patch was not complete, and the FCC port lock-up scenario
> has been reproduced in lab.
> I had an opportunity to check the current patch in lab and the FCC
> port lock no longer freezes, while the previous patch still locks-up the
> FCC port.
> The current patch fixes a pointer arithmetic bug (second bug in the same
> line), which leads FCC port lock-up during underrun/collision handling.
> Within the tx_startup() function in mac-fcc.c, the address of last BD is
> not calculated correctly. As a result of wrong calculation of the last BD
> address, the next transmitted BD may be set to an area out of the transmit
> BD ring. This actually causes to port lock-up and it is not recoverable.
> 
> Signed-off-by: Martin Roth 

Applied, thank you.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 0/3] kallsyms base relative series

[Kees Cook]

On Mon, Jan 25, 2016 at 6:19 AM, Ard Biesheuvel
 wrote:
> This v4 of my kallsyms base relative implementation is now a 3 piece series,
> since it caused some problems due to the way absolute symbols are handled
> by the absolute per cpu code. As it turns out, that code was probably wrong
> in the sense that it caused non-relocated symbol addresses to be emitted
> for values that are in fact relative to the address of the kernel text.
>
> Patch #1 fixes the scripts/kallsyms invocation to only pass the x86_64
> specific --absolute-percpu option if CONFIG_SMP is also set.
>
> Patch #2 reworks the absolute percpu code to only emit those percpu symbols
> as absolute, and not symbols that have been classified as 'A' (absolute) by
> the linker, since that does not mean quite the same thing.
>
> Patch #3 is the original kallsyms base relative patch, with some
> modifications:
> - folded the s/ULLONG_MAX/-1ULL? change made by Andrew
> - ensured that the kallsyms_relative_base value itself is relocated as
>   required.
> - dropped all of the acks and other tags, as they have become outdated with
>   the recent changes to this patch.
>
> Ard Biesheuvel (3):
>   x86: kallsyms: disable absolute percpu symbols on !SMP
>   kallsyms: don't overload absolute symbol type for percpu symbols
>   kallsyms: add support for relative offsets in kallsyms address table

Still works for me!

Reviewed-by: Kees Cook 
Tested-by: Kees Cook 

-Kees

>
>  init/Kconfig|  16 +++
>  kernel/kallsyms.c   |  38 ++--
>  scripts/kallsyms.c  | 102 +---
>  scripts/link-vmlinux.sh |   6 +-
>  scripts/namespace.pl|   2 +
>  5 files changed, 142 insertions(+), 22 deletions(-)
>
> --
> 2.5.0
>



-- 
Kees Cook
Chrome OS & Brillo Security
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: 86xx

[christophe leroy]

Le 25/01/2016 12:15, Alessio Igor Bogani a écrit :

Hi All,

Sorry for my very bad English!

I'm looking for who takes care of the 86xx subtree
(arch/powerpc/platform/86xx) but I haven't found any entry into
MAINTEINARS file.

Ciao,
Alessio




Looks like Kumar Gala  is the commiter for 
many files in this subdirectory


Christophe

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

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 3/3] tty: hvc_xen: hide xen_console_remove when unused

[Arnd Bergmann]

xencons_disconnect_backend() is only called from xen_console_remove(),
which is conditionally compiled, so we get a harmless warning when
CONFIG_HVC_XEN_FRONTEND is unset:

hvc/hvc_xen.c:350:12: error: 'xen_console_remove' defined but not used 
[-Werror=unused-function]

This moves the function down into the same #ifdef section to silence
the warning.

Signed-off-by: Arnd Bergmann 
---
 drivers/tty/hvc/hvc_xen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index fa816b7193b6..11725422dacb 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -323,6 +323,7 @@ void xen_console_resume(void)
}
 }
 
+#ifdef CONFIG_HVC_XEN_FRONTEND
 static void xencons_disconnect_backend(struct xencons_info *info)
 {
if (info->irq > 0)
@@ -363,7 +364,6 @@ static int xen_console_remove(struct xencons_info *info)
return 0;
 }
 
-#ifdef CONFIG_HVC_XEN_FRONTEND
 static int xencons_remove(struct xenbus_device *dev)
 {
return xen_console_remove(dev_get_drvdata(&dev->dev));
-- 
2.7.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/3] tty: hvc_xen: hide xen_console_remove when unused

[Boris Ostrovsky]

On 01/25/2016 04:54 PM, Arnd Bergmann wrote:

xencons_disconnect_backend() is only called from xen_console_remove(),


and also from xencons_probe()/xencons_resume(). But those two are also 
under the

same ifdef.

-boris


which is conditionally compiled, so we get a harmless warning when
CONFIG_HVC_XEN_FRONTEND is unset:

hvc/hvc_xen.c:350:12: error: 'xen_console_remove' defined but not used 
[-Werror=unused-function]

This moves the function down into the same #ifdef section to silence
the warning.

Signed-off-by: Arnd Bergmann 
---
  drivers/tty/hvc/hvc_xen.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index fa816b7193b6..11725422dacb 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -323,6 +323,7 @@ void xen_console_resume(void)
}
  }
  
+#ifdef CONFIG_HVC_XEN_FRONTEND

  static void xencons_disconnect_backend(struct xencons_info *info)
  {
if (info->irq > 0)
@@ -363,7 +364,6 @@ static int xen_console_remove(struct xencons_info *info)
return 0;
  }
  
-#ifdef CONFIG_HVC_XEN_FRONTEND

  static int xencons_remove(struct xenbus_device *dev)
  {
return xen_console_remove(dev_get_drvdata(&dev->dev));


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] QE: Use GFP_ATOMIC while spin_lock_irqsave is held

[Scott Wood]

On Sun, 2016-01-24 at 12:24 +0530, Saurabh Sengar wrote:
> cpm_muram_alloc_common is called twice and both the times
> spin_lock_irqsave is held.
> Using GFP_KERNEL can sleep in spin_lock_irqsave context and cause
> deadlock
> 
> Signed-off-by: Saurabh Sengar 
> ---
> Let me know if there is any other way to fix it.
> Also, I would say this function should be static as it is not used in any
> other file
>  drivers/soc/fsl/qe/qe_common.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Yes, it should be static.  Do you plan to send a patch for that?

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: cxl: Fix struct pid leak when attaching a process through user API

[Michael Ellerman]

On Tue, 2015-03-11 at 12:13:52 UTC, Frederic Barrat wrote:
> When the cxl driver creates a context, it stores the pid of the
> calling task, and mistakenly increments the reference count of the
> struct pid twice, once through get_task_pid(), once through
> get_pid(). The reference count is only decremented once on detach. As
> a result, a struct pid is leaked and it reduces the number of
> processes that can run simultaneously by one.
> The fix is to simply remove the call to get_pid().
> 
> There is a separate patch for the kernel API, since it goes to
> different kernel versions.
> 
> Signed-off-by: Frederic Barrat 
> Cc:  # 3.18+
> Acked-by: Ian Munsie 
> Reviewed-by: Andrew Donnellan 

This no longer applies, since we merged 7b8ad495d592 ("cxl: Fix DSI misses when
the context owning task exits").

Please resend if it's still applicable.

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] PPC32: Fix build failure caused by missing dirty pte handlers

[Michael Ellerman]

On Mon, 2016-01-25 at 09:22 -0500, Pranith Kumar wrote:

> In 4.5-rc1, I am getting a build failure as follows:
> 
> mm/memory.c: In function ‘do_swap_page’:
> mm/memory.c:2573:9: error: implicit declaration of function ‘pte_mksoft_dirty’
> [-Werror=implicit-function-declaration]
>pte = pte_mksoft_dirty(pte);
> 
> The soft dirty pte handlers are declared only for PPC64 on PPC_BOOK3S in
> arch/powerpc/include/asm/book3s/64/hash.h and missing in the 32-bit arch.
> 
> Avoid this error by not setting HAVE_ARCH_SOFT_DIRTY for 32-bit system.

It's building for me, what config are you using?

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

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] PPC32: Fix build failure caused by missing dirty pte handlers

[Pranith Kumar]

On Mon, Jan 25, 2016 at 10:13 PM, Michael Ellerman  wrote:
> On Mon, 2016-01-25 at 09:22 -0500, Pranith Kumar wrote:
>
>> In 4.5-rc1, I am getting a build failure as follows:
>>
>> mm/memory.c: In function ‘do_swap_page’:
>> mm/memory.c:2573:9: error: implicit declaration of function 
>> ‘pte_mksoft_dirty’
>> [-Werror=implicit-function-declaration]
>>pte = pte_mksoft_dirty(pte);
>>
>> The soft dirty pte handlers are declared only for PPC64 on PPC_BOOK3S in
>> arch/powerpc/include/asm/book3s/64/hash.h and missing in the 32-bit arch.
>>
>> Avoid this error by not setting HAVE_ARCH_SOFT_DIRTY for 32-bit system.
>
> It's building for me, what config are you using?
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/12597204/
>

I am not sure where I messed up, but I am getting the following error now.
Config attached. The same patch fixes this error.

In file included from fs/proc/task_mmu.c:14:0:
include/linux/swapops.h: In function ‘pte_to_swp_entry’:
include/linux/swapops.h:69:6: error: implicit declaration of function
‘pte_swp_soft_dirty’ [-Werror=implicit-function-declaration]
  if (pte_swp_soft_dirty(pte))
  ^
include/linux/swapops.h:70:9: error: implicit declaration of function
‘pte_swp_clear_soft_dirty’ [-Werror=implicit-function-declaration]
   pte = pte_swp_clear_soft_dirty(pte);
 ^
fs/proc/task_mmu.c: In function ‘clear_soft_dirty’:
fs/proc/task_mmu.c:876:11: error: implicit declaration of function
‘pte_clear_soft_dirty’ [-Werror=implicit-function-declaration]
   ptent = pte_clear_soft_dirty(ptent);
   ^
fs/proc/task_mmu.c: In function ‘pte_to_pagemap_entry’:
fs/proc/task_mmu.c:1158:7: error: implicit declaration of function
‘pte_soft_dirty’ [-Werror=implicit-function-declaration]
   if (pte_soft_dirty(pte))
   ^
cc1: some warnings being treated as errors



-- 
Pranith


config-failure
Description: Binary data
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

[Paul E. McKenney]

On Mon, Jan 25, 2016 at 02:41:34PM +, Will Deacon wrote:
> On Fri, Jan 15, 2016 at 11:28:45AM -0800, Paul E. McKenney wrote:
> > On Fri, Jan 15, 2016 at 09:54:01AM -0800, Paul E. McKenney wrote:
> > > On Fri, Jan 15, 2016 at 10:24:32AM +, Will Deacon wrote:
> > > > See my earlier reply [1] (but also, your WRC Linux example looks more
> > > > like a variant on WWC and I couldn't really follow it).
> > > 
> > > I will revisit my WRC Linux example.  And yes, creating litmus tests
> > > that use non-fake dependencies is still a bit of an undertaking.  :-/
> > > I am sure that it will seem more natural with time and experience...
> > 
> > Hmmm...  You are quite right, I did do WWC.  I need to change cpu2()'s
> > last access from a store to a load to get WRC.  Plus the levels of
> > indirection definitely didn't match up, did they?
> 
> Nope, it was pretty baffling!

"It is a service that I provide."  ;-)

> > struct foo {
> > struct foo *next;
> > };
> > struct foo a;
> > struct foo b;
> > struct foo c = { &a };
> > struct foo d = { &b };
> > struct foo x = { &c };
> > struct foo y = { &d };
> > struct foo *r1, *r2, *r3;
> > 
> > void cpu0(void)
> > {
> > WRITE_ONCE(x.next, &y);
> > }
> > 
> > void cpu1(void)
> > {
> > r1 = lockless_dereference(x.next);
> > WRITE_ONCE(r1->next, &x);
> > }
> > 
> > void cpu2(void)
> > {
> > r2 = lockless_dereference(y.next);
> > r3 = READ_ONCE(r2->next);
> > }
> > 
> > In this case, it is legal to end the run with:
> > 
> > r1 == &y && r2 == &x && r3 == &c
> > 
> > Please see below for a ppcmem litmus test.
> > 
> > So, did I get it right this time?  ;-)
> 
> The code above looks correct to me (in that it matches WRC+addrs),
> but your litmus test:
> 
> > PPC WRCnf+addrs
> > ""
> > {
> > 0:r2=x; 0:r3=y;
> > 1:r2=x; 1:r3=y;
> > 2:r2=x; 2:r3=y;
> > c=a; d=b; x=c; y=d;
> > }
> >  P0   | P1| P2;
> >  stw r3,0(r2) | lwz r8,0(r2)  | lwz r8,0(r3)  ;
> >   | stw r2,0(r3)  | lwz r9,0(r8)  ;
> > exists
> > (1:r8=y /\ 2:r8=x /\ 2:r9=c)
> 
> Seems to be missing the address dependency on P1.

You are quite correct!  How about the following?

As before, both herd and ppcmem say that the cycle is allowed, as
expected, given non-transitive ordering.  To prohibit the cycle, P1
needs a suitable memory-barrier instruction.

Thanx, Paul



PPC WRCnf+addrs
""
{
0:r2=x; 0:r3=y;
1:r2=x; 1:r3=y;
2:r2=x; 2:r3=y;
c=a; d=b; x=c; y=d;
}
 P0   | P1| P2;
 stw r3,0(r2) | lwz r8,0(r2)  | lwz r8,0(r3)  ;
  | stw r2,0(r8)  | lwz r9,0(r8)  ;
exists
(1:r8=y /\ 2:r8=x /\ 2:r9=c)

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

[Paul E. McKenney]

On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote:
> On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote:
> > On Fri, Jan 15, 2016 at 10:27:14PM +0100, Peter Zijlstra wrote:
> > > On Fri, Jan 15, 2016 at 09:46:12AM -0800, Paul E. McKenney wrote:
> > > > On Fri, Jan 15, 2016 at 10:13:48AM +0100, Peter Zijlstra wrote:
> > > 
> > > > > And the stuff we're confused about is how best to express the 
> > > > > difference
> > > > > and guarantees of these two forms of transitivity and how exactly they
> > > > > interact.
> > > > 
> > > > Hoping my memory-barrier.txt patch helps here...
> > > 
> > > Yes, that seems a good start. But yesterday you raised the 'fun' point
> > > of two globally ordered sequences connected by a single local link.
> > 
> > The conclusion that I am slowly coming to is that litmus tests should
> > not be thought of as linear chains, but rather as cycles.  If you think
> > of it as a cycle, then it doesn't matter where the local link is, just
> > how many of them and how they are connected.
> 
> Do you have some examples of this? I'm struggling to make it work in my
> mind, or are you talking specifically in the context of the kernel
> memory model?

Now that you mention it, maybe it would be best to keep the transitive
and non-transitive separate for the time being anyway.  Just because it
might be possible to deal with does not necessarily mean that we should
be encouraging it.  ;-)

> > But I will admit that there are some rather strange litmus tests that
> > challenge this cycle-centric view, for example, the one shown below.
> > It turns out that herd and ppcmem disagree on the outcome.  (The Power
> > architects side with ppcmem.)
> > 
> > > And I think I'm still confused on LWSYNC (in the smp_wmb case) when one
> > > of the stores looses a conflict, and if that scenario matters. If it
> > > does, we should inspect the same case for other barriers.
> > 
> > Indeed.  I am still working on how these should be described.  My
> > current thought is to be quite conservative on what ordering is
> > actually respected, however, the current task is formalizing how
> > RCU plays with the rest of the memory model.
> > 
> > Thanx, Paul
> > 
> > 
> > 
> > PPC Overlapping Group-B sets version 4
> > ""
> > (* When the Group-B sets from two different barriers involve instructions in
> >the same thread, within that thread one set must contain the other.
> > 
> > P0  P1  P2
> > Rx=1Wy=1Wz=2
> > dep.lwsync  lwsync
> > Ry=0Wz=1Wx=1
> > Rz=1
> > 
> > assert(!(z=2))
> > 
> >Forbidden by ppcmem, allowed by herd.
> > *)
> > {
> > 0:r1=x; 0:r2=y; 0:r3=z;
> > 1:r1=x; 1:r2=y; 1:r3=z; 1:r4=1;
> > 2:r1=x; 2:r2=y; 2:r3=z; 2:r4=1; 2:r5=2;
> > }
> >  P0 | P1| P2;
> >  lwz r6,0(r1)   | stw r4,0(r2)  | stw r5,0(r3)  ;
> >  xor r7,r6,r6   | lwsync| lwsync;
> >  lwzx r7,r7,r2  | stw r4,0(r3)  | stw r4,0(r1)  ;
> >  lwz r8,0(r3)   |   |   ;
> > 
> > exists
> > (z=2 /\ 0:r6=1 /\ 0:r7=0 /\ 0:r8=1)
> 
> That really hurts. Assuming that the "assert(!(z=2))" is actually there
> to constrain the coherence order of z to be {0->1->2}, then I think that
> this test is forbidden on arm using dmb instead of lwsync. That said, I
> also don't think the Rz=1 in P0 changes anything.

What about the smp_wmb() variant of dmb that orders only stores?

> The double negatives don't help here! (it is forbidden to guarantee that
> z is not always 2).

Yes, this is a weird one, and I don't know of any use of it.

Thanx, Paul

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

[Paul E. McKenney]

On Mon, Jan 25, 2016 at 06:02:34PM +, Will Deacon wrote:
> Hi Paul,
> 
> On Fri, Jan 15, 2016 at 09:39:12AM -0800, Paul E. McKenney wrote:
> > On Fri, Jan 15, 2016 at 09:55:54AM +0100, Peter Zijlstra wrote:
> > > On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote:
> > > > So smp_mb() provides transitivity, as do pairs of smp_store_release()
> > > > and smp_read_acquire(), 
> > > 
> > > But they provide different grades of transitivity, which is where all
> > > the confusion lays.
> > > 
> > > smp_mb() is strongly/globally transitive, all CPUs will agree on the 
> > > order.
> > > 
> > > Whereas the RCpc release+acquire is weakly so, only the two cpus
> > > involved in the handover will agree on the order.
> > 
> > Good point!
> > 
> > Using grace periods in place of smp_mb() also provides strong/global
> > transitivity, but also insanely high latencies.  ;-)
> > 
> > The patch below updates Documentation/memory-barriers.txt to define
> > local vs. global transitivity.  The corresponding ppcmem litmus test
> > is included below as well.
> > 
> > Should we start putting litmus tests for the various examples
> > somewhere, perhaps in a litmus-tests directory within each participating
> > architecture?  I have a pile of powerpc-related litmus tests on my laptop,
> > but they probably aren't doing all that much good there.
> 
> I too would like to have the litmus tests in the kernel so that we can
> refer to them from memory-barriers.txt. Ideally they wouldn't be targetted
> to a particular arch, however.

Agreed.  Working on it...

> > PPC local-transitive
> > ""
> > {
> > 0:r1=1; 0:r2=u; 0:r3=v; 0:r4=x; 0:r5=y; 0:r6=z;
> > 1:r1=1; 1:r2=u; 1:r3=v; 1:r4=x; 1:r5=y; 1:r6=z;
> > 2:r1=1; 2:r2=u; 2:r3=v; 2:r4=x; 2:r5=y; 2:r6=z;
> > 3:r1=1; 3:r2=u; 3:r3=v; 3:r4=x; 3:r5=y; 3:r6=z;
> > }
> >  P0   | P1   | P2   | P3   ;
> >  lwz r9,0(r4) | lwz r9,0(r5) | lwz r9,0(r6) | stw r1,0(r3) ;
> >  lwsync   | lwsync   | lwsync   | sync ;
> >  stw r1,0(r2) | lwz r8,0(r3) | stw r1,0(r7) | lwz r9,0(r2) ;
> >  lwsync   | lwz r7,0(r2) |  |  ;
> >  stw r1,0(r5) | lwsync   |  |  ;
> >   | stw r1,0(r6) |  |  ;
> > exists
> > (* (0:r9=0 /\ 1:r9=1 /\ 2:r9=1 /\ 1:r8=0 /\ 3:r9=0) *)
> > (* (0:r9=1 /\ 1:r9=1 /\ 2:r9=1) *)
> > (* (0:r9=0 /\ 1:r9=1 /\ 2:r9=1 /\ 1:r7=0) *)
> > (0:r9=0 /\ 1:r9=1 /\ 2:r9=1 /\ 1:r7=0)
> 
> i.e. we should rewrite this using READ_ONCE/WRITE_ONCE and smp_mb() etc.

Yep!

> > 
> > 
> > commit 2cb4e83a1b5c89c8e39b8a64bd89269d05913e41
> > Author: Paul E. McKenney 
> > Date:   Fri Jan 15 09:30:42 2016 -0800
> > 
> > documentation: Distinguish between local and global transitivity
> > 
> > The introduction of smp_load_acquire() and smp_store_release() had
> > the side effect of introducing a weaker notion of transitivity:
> > The transitivity of full smp_mb() barriers is global, but that
> > of smp_store_release()/smp_load_acquire() chains is local.  This
> > commit therefore introduces the notion of local transitivity and
> > gives an example.
> > 
> > Reported-by: Peter Zijlstra 
> > Reported-by: Will Deacon 
> > Signed-off-by: Paul E. McKenney 
> > 
> > diff --git a/Documentation/memory-barriers.txt 
> > b/Documentation/memory-barriers.txt
> > index c66ba46d8079..d8109ed99342 100644
> > --- a/Documentation/memory-barriers.txt
> > +++ b/Documentation/memory-barriers.txt
> > @@ -1318,8 +1318,82 @@ or a level of cache, CPU 2 might have early access 
> > to CPU 1's writes.
> >  General barriers are therefore required to ensure that all CPUs agree
> >  on the combined order of CPU 1's and CPU 2's accesses.
> >  
> > -To reiterate, if your code requires transitivity, use general barriers
> > -throughout.
> > +General barriers provide "global transitivity", so that all CPUs will
> > +agree on the order of operations.  In contrast, a chain of release-acquire
> > +pairs provides only "local transitivity", so that only those CPUs on
> > +the chain are guaranteed to agree on the combined order of the accesses.
> 
> Thanks for having a go at this. I tried defining something axiomatically,
> but got stuck pretty quickly. In my scheme, I used "data-directed
> transitivity" instead of "local transitivity", since the latter seems to
> be a bit of a misnomer.

I figured that "local" meant local to the CPUs participating in the
release-acquire chain.  As opposed to smp_mb() chains where the ordering
is "global" as in visible to all CPUs, whether on the chain or not.
Does that help?

> > +For example, switching to C code in deference to Herman Hollerith:
> > +
> > +   int u, v, x, y, z;
> > +
> > +   void cpu0(void)
> > +   {
> > +   r0 = smp_load_acquire(&x);
> > +   WRITE_ONCE(u, 1);
> > +   smp_store_release(&y, 1);
> > +   }
> > +
>