Re: [PATCH] powerpc: drop useless warning in eeh_init()
On Thu, 04 Dec 2014 11:32:45 +1100 Michael Ellerman m...@ellerman.id.au wrote: On Thu, 2014-12-04 at 09:14 +1100, Gavin Shan wrote: On Wed, Dec 03, 2014 at 03:20:46PM +0100, Greg Kurz wrote: On Wed, 26 Nov 2014 09:28:47 +1100 Gavin Shan gws...@linux.vnet.ibm.com wrote: On Tue, Nov 25, 2014 at 05:10:06PM +0100, Greg Kurz wrote: This is what we get in dmesg when booting a pseries guest and the hypervisor doesn't provide EEH support. Ping ? It's already in Michael's git tree. Indeed. It's also marked as Under Review in patchwork, which basically means I've seen it and it's on its way into my tree unless you hear otherwise. http://patchwork.ozlabs.org/patch/414753/ cheers Sorry for the noise, I'll check next time... :\ -- G ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: dts: pq3/85xx: Fix GPIO address
Fix the GPIO address in the device tree to match the documented location.
Signed-off-by: Alessio Igor Bogani alessio.bog...@elettra.eu
---
arch/powerpc/boot/dts/fsl/pq3-gpio-0.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/pq3-gpio-0.dtsi
b/arch/powerpc/boot/dts/fsl/pq3-gpio-0.dtsi
index 72a3ef5..a1b4854 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-gpio-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-gpio-0.dtsi
@@ -1,5 +1,5 @@
/*
- * PQ3 GPIO device tree stub [ controller @ offset 0xf000 ]
+ * PQ3 GPIO device tree stub [ controller @ offset 0xfc00 ]
*
* Copyright 2011 Freescale Semiconductor Inc.
*
@@ -32,10 +32,10 @@
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
-gpio-controller@f000 {
+gpio-controller@fc00 {
#gpio-cells = 2;
compatible = fsl,pq3-gpio;
- reg = 0xf000 0x100;
+ reg = 0xfc00 0x100;
interrupts = 47 0x2 0 0;
gpio-controller;
};
--
2.1.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC PATCH v2 1/1] powerpc/85xx: Add support for Emerson/Artesyn MVME2500.
Add support for the Artesyn MVME2500 Single Board Computer.
The MVME2500 is a 6U form factor VME64 computer with:
- A single Freescale QorIQ P2010 CPU
- 1 GB of DDR3 onboard memory
- Three Gigabit Ethernets
- Five 16550 compatible UARTS
- One USB 2.0 port, one SHDC socket and one SATA connector
- One PCI/PCI eXpress Mezzanine Card (PMC/XMC) Slot
- MultiProcessor Interrupt Controller (MPIC)
- A DS1375T Real Time Clock (RTC) and 512 KB of Non-Volatile Memory
- Two 64 KB EEPROMs
- U-Boot in 16 SPI Flash
This patch is based on linux-3.18-rc7 and has been boot tested.
Signed-off-by: Alessio Igor Bogani alessio.bog...@elettra.eu
---
v1 - v2
Increase an LBC window from only 0x1000 to 0x8000 bytes
Rename:
eeprom-vpd and spd to eeprom
Artesyn to artesyn
Remove:
board_soc label
partition scheme
A whitespace
#cell-index usages
The mvm2500.dtsi file (moving its definitions at the bottom
of the mvme2500.dts)
mvme2500_defconfig and use mpc85xx_defconfig instead
Useless headers in mvme2500.c
SWIOTLB usages
Replace:
printk() with pr_info()
NVRAM with MTD-RAM: Unfortunately the former doesn't cope with
16-bit addressing of the chip used in MVME2500 board but the
latter can due of the bank-witdth device tree definition.
arch/powerpc/boot/dts/mvme2500.dts | 282 +
arch/powerpc/configs/mpc85xx_defconfig | 71 +++--
arch/powerpc/platforms/85xx/Kconfig| 6 +
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/mvme2500.c | 74 +
5 files changed, 387 insertions(+), 47 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mvme2500.dts
create mode 100644 arch/powerpc/platforms/85xx/mvme2500.c
diff --git a/arch/powerpc/boot/dts/mvme2500.dts
b/arch/powerpc/boot/dts/mvme2500.dts
new file mode 100644
index 000..4bd134e
--- /dev/null
+++ b/arch/powerpc/boot/dts/mvme2500.dts
@@ -0,0 +1,282 @@
+/*
+ * Device tree source for the Emerson/Artesyn MVME2500
+ *
+ * Copyright 2014 Elettra-Sincrotrone Trieste S.C.p.A.
+ *
+ * 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.
+ *
+ * Based on: P2020 DS Device Tree Source
+ * Copyright 2009 Freescale Semiconductor Inc.
+ */
+
+/include/ fsl/p2020si-pre.dtsi
+
+/ {
+ model = MVME2500;
+ compatible = artesyn,MVME2500;
+
+ aliases {
+ serial2 = serial2;
+ serial3 = serial3;
+ serial4 = serial4;
+ serial5 = serial5;
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ soc: soc@ffe0 {
+ ranges = 0x0 0 0xffe0 0x10;
+
+ i2c@3000 {
+ hwmon@4c {
+ compatible = adi,adt7461;
+ reg = 0x4c;
+ };
+
+ rtc@68 {
+ compatible = dallas,ds1337;
+ reg = 0x68;
+ interrupts = 8 1 0 0;
+ };
+
+ eeprom@54 {
+ compatible = atmel,24c64;
+ reg = 0x54;
+ };
+
+ eeprom@52 {
+ compatible = atmel,24c512;
+ reg = 0x52;
+ };
+
+ eeprom@53 {
+ compatible = atmel,24c512;
+ reg = 0x53;
+ };
+
+ eeprom@50 {
+ compatible = atmel,24c02;
+ reg = 0x50;
+ };
+
+ };
+
+ spi0: spi@7000 {
+ fsl,espi-num-chipselects = 2;
+
+ flash@0 {
+ compatible = atmel,at25df641;
+ reg = 0;
+ spi-max-frequency = 1000;
+ };
+ flash@1 {
+ compatible = atmel,at25df641;
+ reg = 1;
+ spi-max-frequency = 1000;
+ };
+ };
+
+ usb@22000 {
+ dr_mode = host;
+ phy_type = ulpi;
+ };
+
+ enet0: ethernet@24000 {
+
Re: powerpc/book3s: Fix flush_tlb cpu_spec hook to take a generic argument.
On Tue, 2014-12-02 at 14:31 +0530, Mahesh Jagannath Salgaonkar wrote: On 11/29/2014 04:08 AM, Michael Ellerman wrote: On Tue, 2014-23-09 at 03:53:54 UTC, Mahesh Salgaonkar wrote: From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com The flush_tlb hook in cpu_spec was introduced as a generic function hook to invalidate TLBs. But the current implementation of flush_tlb hook takes IS (invalidation selector) as an argument which is architecture dependent. Hence, It is not right to have a generic routine where caller has to pass non-generic argument. This patch fixes this and makes flush_tlb hook as high level API. The old code used to call flush_tlb hook with IS=0 (single page) resulting partial invalidation of TLBs which is not right. This fix now makes sure that whole TLB is invalidated to be able to successfully recover from TLB and ERAT errors. Which old code? You mean the MCE code I think. That's a bug fix, so it should be a separate patch. Yes. MCE code. Since this patch re-factors the code that takes IS as direct argument, having a separate fix patch does not make any sense and would get overwritten by this patch anyway. That's irrelevant. The fix will go to stable, the refactor will not. Please do the MCE fix as a separate, preceeding patch. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 03/10] mm: Convert p[te|md]_numa users to p[te|md]_protnone_numa
On Thu, Dec 04, 2014 at 08:01:57AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2014-12-03 at 15:52 +, Mel Gorman wrote: It's implied but can I assume it passed? If so, Ben and Paul, can I consider the series to be acked by you other than the minor comment updates? Yes. Assuming it passed :-) Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org Sweet, thanks. -- Mel Gorman SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 03/10] mm: Convert p[te|md]_numa users to p[te|md]_protnone_numa
On Wed, Dec 03, 2014 at 10:50:35PM +0530, Aneesh Kumar K.V wrote: Mel Gorman mgor...@suse.de writes: On Wed, Dec 03, 2014 at 08:53:37PM +0530, Aneesh Kumar K.V wrote: Benjamin Herrenschmidt b...@kernel.crashing.org writes: On Tue, 2014-12-02 at 12:57 +0530, Aneesh Kumar K.V wrote: Now, hash_preload can possibly insert an hpte in hash page table even if the access is not allowed by the pte permissions. But i guess even that is ok. because we will fault again, end-up calling hash_page_mm where we handle that part correctly. I think we need a test case... I ran the subpageprot test that Paul had written. I modified it to ran with selftest. It's implied but can I assume it passed? Yes. -bash-4.2# ./subpage_prot test: subpage_prot tags: git_version:v3.17-rc3-13511-g0cd3756 allocated malloc block of 0x400 bytes at 0x0x3fffb0d1 testing malloc block... OK success: subpage_prot -bash-4.2# Thanks for adding that and double checking. I won't pick up the patch as part of this series because it's not directly related but I would strongly suggest sending the patch separately. -- Mel Gorman SUSE Labs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/10] Replace _PAGE_NUMA with PAGE_NONE protections v4
There are no functional changes here and I kept the mmotm-20141119 baseline as that is what got tested but it rebases cleanly to current mmotm. The series makes architectural changes but splitting this on a per-arch basis would cause bisect-related brain damage. I'm hoping this can go through Andrew without conflict. It's been tested by myself (standard tests), Aneesh (ppc64) and Sasha (trinity) so there is some degree of confidence that it's ok. Changelog since V3 o Minor comment update (benh) o Add ack'ed bys Changelog since V2 o Rename *_protnone_numa to _protnone and extend docs (linus) o Rebase to mmotm-20141119 for pre-merge testing(mel) o Conver WARN_ON to VM_WARN_ON (aneesh) Changelog since V1 o ppc64 paranoia checks and clarifications (aneesh) o Fix trinity regression (hopefully) o Reduce unnecessary TLB flushes(mel) Automatic NUMA balancing depends on being able to protect PTEs to trap a fault and gather reference locality information. Very broadly speaking it would mark PTEs as not present and use another bit to distinguish between NUMA hinting faults and other types of faults. It was universally loved by everybody and caused no problems whatsoever. That last sentence might be a lie. This series is very heavily based on patches from Linus and Aneesh to replace the existing PTE/PMD NUMA helper functions with normal change protections. I did alter and add parts of it but I consider them relatively minor contributions. At their suggestion, acked-bys are in there but I've no problem converting them to Signed-off-by if requested. AFAIK, this has received no testing on ppc64 and I'm depending on Aneesh for that. I tested trinity under kvm-tool and passed and ran a few other basic tests. At the time of writing, only the short-lived tests have completed but testing of V2 indicated that long-term testing had no surprises. In most cases I'm leaving out detail as it's not that interesting. specjbb single JVM: There was negligible performance difference in the benchmark itself for short runs. However, system activity is higher and interrupts are much higher over time -- possibly TLB flushes. Migrations are also higher. Overall, this is more overhead but considering the problems faced with the old approach I think we just have to suck it up and find another way of reducing the overhead. specjbb multi JVM: Negligible performance difference to the actual benchmark but like the single JVM case, the system overhead is noticeably higher. Again, interrupts are a major factor. autonumabench: This was all over the place and about all that can be reasonably concluded is that it's different but not necessarily better or worse. autonumabench 3.18.0-rc53.18.0-rc5 mmotm-20141119 protnone-v3r3 UserNUMA01 32380.24 ( 0.00%)21642.92 ( 33.16%) UserNUMA01_THEADLOCAL22481.02 ( 0.00%)22283.22 ( 0.88%) UserNUMA023137.00 ( 0.00%) 3116.54 ( 0.65%) UserNUMA02_SMT1614.03 ( 0.00%) 1543.53 ( 4.37%) System NUMA01 322.97 ( 0.00%) 1465.89 (-353.88%) System NUMA01_THEADLOCAL 91.87 ( 0.00%) 49.32 ( 46.32%) System NUMA02 37.83 ( 0.00%) 14.61 ( 61.38%) System NUMA02_SMT 7.36 ( 0.00%)7.45 ( -1.22%) Elapsed NUMA01 716.63 ( 0.00%) 599.29 ( 16.37%) Elapsed NUMA01_THEADLOCAL 553.98 ( 0.00%) 539.94 ( 2.53%) Elapsed NUMA02 83.85 ( 0.00%) 83.04 ( 0.97%) Elapsed NUMA02_SMT 86.57 ( 0.00%) 79.15 ( 8.57%) CPU NUMA014563.00 ( 0.00%) 3855.00 ( 15.52%) CPU NUMA01_THEADLOCAL 4074.00 ( 0.00%) 4136.00 ( -1.52%) CPU NUMA023785.00 ( 0.00%) 3770.00 ( 0.40%) CPU NUMA02_SMT1872.00 ( 0.00%) 1959.00 ( -4.65%) System CPU usage of NUMA01 is worse but it's an adverse workload on this machine so I'm reluctant to conclude that it's a problem that matters. On the other workloads that are sensible on this machine, system CPU usage is great. Overall time to complete the benchmark is comparable 3.18.0-rc5 3.18.0-rc5 mmotm-20141119protnone-v3r3 User59612.5048586.44 System460.22 1537.45 Elapsed 1442.20 1304.29 NUMA alloc hit 5075182 5743353 NUMA alloc miss 0 0 NUMA interleave hit 0 0 NUMA alloc local 5075174 5743339 NUMA base PTE updates637061448 443106883 NUMA huge PMD updates 1243434 864747 NUMA page range updates 1273699656 885857347 NUMA
[PATCH 01/10] mm: numa: Do not dereference pmd outside of the lock during NUMA hinting fault
A transhuge NUMA hinting fault may find the page is migrating and should
wait until migration completes. The check is race-prone because the pmd
is deferenced outside of the page lock and while the race is tiny, it'll
be larger if the PMD is cleared while marking PMDs for hinting fault.
This patch closes the race.
Signed-off-by: Mel Gorman mgor...@suse.de
---
include/linux/migrate.h | 4
mm/huge_memory.c| 3 ++-
mm/migrate.c| 6 --
3 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index 01aad3e..a3edcdf 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -77,7 +77,6 @@ static inline int migrate_huge_page_move_mapping(struct
address_space *mapping,
#ifdef CONFIG_NUMA_BALANCING
extern bool pmd_trans_migrating(pmd_t pmd);
-extern void wait_migrate_huge_page(struct anon_vma *anon_vma, pmd_t *pmd);
extern int migrate_misplaced_page(struct page *page,
struct vm_area_struct *vma, int node);
extern bool migrate_ratelimited(int node);
@@ -86,9 +85,6 @@ static inline bool pmd_trans_migrating(pmd_t pmd)
{
return false;
}
-static inline void wait_migrate_huge_page(struct anon_vma *anon_vma, pmd_t
*pmd)
-{
-}
static inline int migrate_misplaced_page(struct page *page,
struct vm_area_struct *vma, int node)
{
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 817a875..a2cd021 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1283,8 +1283,9 @@ int do_huge_pmd_numa_page(struct mm_struct *mm, struct
vm_area_struct *vma,
* check_same as the page may no longer be mapped.
*/
if (unlikely(pmd_trans_migrating(*pmdp))) {
+ page = pmd_page(*pmdp);
spin_unlock(ptl);
- wait_migrate_huge_page(vma-anon_vma, pmdp);
+ wait_on_page_locked(page);
goto out;
}
diff --git a/mm/migrate.c b/mm/migrate.c
index 41945cb..11d86b4 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1698,12 +1698,6 @@ bool pmd_trans_migrating(pmd_t pmd)
return PageLocked(page);
}
-void wait_migrate_huge_page(struct anon_vma *anon_vma, pmd_t *pmd)
-{
- struct page *page = pmd_page(*pmd);
- wait_on_page_locked(page);
-}
-
/*
* Attempt to migrate a misplaced page to the specified destination
* node. Caller is expected to have an elevated reference count on
--
2.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 02/10] mm: Add p[te|md] protnone helpers for use by NUMA balancing
This is a preparatory patch that introduces protnone helpers for automatic
NUMA balancing.
Signed-off-by: Mel Gorman mgor...@suse.de
Acked-by: Linus Torvalds torva...@linux-foundation.org
Acked-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Tested-by: Sasha Levin sasha.le...@oracle.com
---
arch/powerpc/include/asm/pgtable.h | 16
arch/x86/include/asm/pgtable.h | 16
include/asm-generic/pgtable.h | 20
3 files changed, 52 insertions(+)
diff --git a/arch/powerpc/include/asm/pgtable.h
b/arch/powerpc/include/asm/pgtable.h
index a8805fe..7b889a3 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -39,6 +39,22 @@ static inline int pte_none(pte_t pte){
return (pte_val(pte) ~_PTE_NONE_MASK)
static inline pgprot_t pte_pgprot(pte_t pte) { return __pgprot(pte_val(pte)
PAGE_PROT_BITS); }
#ifdef CONFIG_NUMA_BALANCING
+/*
+ * These work without NUMA balancing but the kernel does not care. See the
+ * comment in include/asm-generic/pgtable.h . On powerpc, this will only
+ * work for user pages and always return true for kernel pages.
+ */
+static inline int pte_protnone(pte_t pte)
+{
+ return (pte_val(pte)
+ (_PAGE_PRESENT | _PAGE_USER)) == _PAGE_PRESENT;
+}
+
+static inline int pmd_protnone(pmd_t pmd)
+{
+ return pte_protnone(pmd_pte(pmd));
+}
+
static inline int pte_present(pte_t pte)
{
return pte_val(pte) _PAGE_NUMA_MASK;
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 081d6f4..2e25780 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -502,6 +502,22 @@ static inline int pmd_present(pmd_t pmd)
_PAGE_NUMA);
}
+#ifdef CONFIG_NUMA_BALANCING
+/*
+ * These work without NUMA balancing but the kernel does not care. See the
+ * comment in include/asm-generic/pgtable.h
+ */
+static inline int pte_protnone(pte_t pte)
+{
+ return pte_flags(pte) _PAGE_PROTNONE;
+}
+
+static inline int pmd_protnone(pmd_t pmd)
+{
+ return pmd_flags(pmd) _PAGE_PROTNONE;
+}
+#endif /* CONFIG_NUMA_BALANCING */
+
static inline int pmd_none(pmd_t pmd)
{
/* Only check low word on 32-bit platforms, since it might be
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 177d597..d497d08 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -688,6 +688,26 @@ static inline int pmd_trans_unstable(pmd_t *pmd)
#endif
}
+#ifndef CONFIG_NUMA_BALANCING
+/*
+ * Technically a PTE can be PROTNONE even when not doing NUMA balancing but
+ * the only case the kernel cares is for NUMA balancing and is only ever set
+ * when the VMA is accessible. For PROT_NONE VMAs, the PTEs are not marked
+ * _PAGE_PROTNONE so by by default, implement the helper as always no. It
+ * is the responsibility of the caller to distinguish between PROT_NONE
+ * protections and NUMA hinting fault protections.
+ */
+static inline int pte_protnone(pte_t pte)
+{
+ return 0;
+}
+
+static inline int pmd_protnone(pmd_t pmd)
+{
+ return 0;
+}
+#endif /* CONFIG_NUMA_BALANCING */
+
#ifdef CONFIG_NUMA_BALANCING
/*
* _PAGE_NUMA distinguishes between an unmapped page table entry, an entry that
--
2.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 03/10] mm: Convert p[te|md]_numa users to p[te|md]_protnone_numa
Convert existing users of pte_numa and friends to the new helper. Note
that the kernel is broken after this patch is applied until the other
page table modifiers are also altered. This patch layout is to make
review easier.
Signed-off-by: Mel Gorman mgor...@suse.de
Acked-by: Linus Torvalds torva...@linux-foundation.org
Acked-by: Aneesh Kumar aneesh.ku...@linux.vnet.ibm.com
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Tested-by: Sasha Levin sasha.le...@oracle.com
---
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 2 +-
arch/powerpc/mm/fault.c | 5 -
arch/powerpc/mm/pgtable.c | 11 ---
arch/powerpc/mm/pgtable_64.c| 3 ++-
arch/x86/mm/gup.c | 4 ++--
include/uapi/linux/mempolicy.h | 2 +-
mm/gup.c| 10 +-
mm/huge_memory.c| 16 +++
mm/memory.c | 4 ++--
mm/mprotect.c | 39 ++---
mm/pgtable-generic.c| 2 +-
11 files changed, 40 insertions(+), 58 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
index 084ad54..3e6ad3f 100644
--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
@@ -235,7 +235,7 @@ long kvmppc_do_h_enter(struct kvm *kvm, unsigned long flags,
pte_size = psize;
pte = lookup_linux_pte_and_update(pgdir, hva, writing,
pte_size);
- if (pte_present(pte) !pte_numa(pte)) {
+ if (pte_present(pte) !pte_protnone(pte)) {
if (writing !pte_write(pte))
/* make the actual HPTE be read-only */
ptel = hpte_make_readonly(ptel);
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index eb79907..b434153 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -398,8 +398,6 @@ good_area:
* processors use the same I/D cache coherency mechanism
* as embedded.
*/
- if (error_code DSISR_PROTFAULT)
- goto bad_area;
#endif /* CONFIG_PPC_STD_MMU */
/*
@@ -423,9 +421,6 @@ good_area:
flags |= FAULT_FLAG_WRITE;
/* a read */
} else {
- /* protection fault */
- if (error_code 0x0800)
- goto bad_area;
if (!(vma-vm_flags (VM_READ | VM_EXEC | VM_WRITE)))
goto bad_area;
}
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index c90e602..83dfcb5 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -172,9 +172,14 @@ static pte_t set_access_flags_filter(pte_t pte, struct
vm_area_struct *vma,
void set_pte_at(struct mm_struct *mm, unsigned long addr, pte_t *ptep,
pte_t pte)
{
-#ifdef CONFIG_DEBUG_VM
- WARN_ON(pte_val(*ptep) _PAGE_PRESENT);
-#endif
+ /*
+* When handling numa faults, we already have the pte marked
+* _PAGE_PRESENT, but we can be sure that it is not in hpte.
+* Hence we can use set_pte_at for them.
+*/
+ VM_WARN_ON((pte_val(*ptep) (_PAGE_PRESENT | _PAGE_USER)) ==
+ (_PAGE_PRESENT | _PAGE_USER));
+
/* Note: mm-context.id might not yet have been assigned as
* this context might not have been activated yet when this
* is called.
diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index 87ff0c1..435ebf7 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -718,7 +718,8 @@ void set_pmd_at(struct mm_struct *mm, unsigned long addr,
pmd_t *pmdp, pmd_t pmd)
{
#ifdef CONFIG_DEBUG_VM
- WARN_ON(pmd_val(*pmdp) _PAGE_PRESENT);
+ WARN_ON((pmd_val(*pmdp) (_PAGE_PRESENT | _PAGE_USER)) ==
+ (_PAGE_PRESENT | _PAGE_USER));
assert_spin_locked(mm-page_table_lock);
WARN_ON(!pmd_trans_huge(pmd));
#endif
diff --git a/arch/x86/mm/gup.c b/arch/x86/mm/gup.c
index 207d9aef..f32e12c 100644
--- a/arch/x86/mm/gup.c
+++ b/arch/x86/mm/gup.c
@@ -84,7 +84,7 @@ static noinline int gup_pte_range(pmd_t pmd, unsigned long
addr,
struct page *page;
/* Similar to the PMD case, NUMA hinting must take slow path */
- if (pte_numa(pte)) {
+ if (pte_protnone(pte)) {
pte_unmap(ptep);
return 0;
}
@@ -178,7 +178,7 @@ static int gup_pmd_range(pud_t pud, unsigned long addr,
unsigned long end,
* slowpath for accounting purposes and so that they
* can be serialised against THP migration.
*/
- if (pmd_numa(pmd))
+
[PATCH 04/10] ppc64: Add paranoid warnings for unexpected DSISR_PROTFAULT
ppc64 should not be depending on DSISR_PROTFAULT and it's unexpected
if they are triggered. This patch adds warnings just in case they
are being accidentally depended upon.
Signed-off-by: Mel Gorman mgor...@suse.de
Acked-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Tested-by: Sasha Levin sasha.le...@oracle.com
---
arch/powerpc/mm/copro_fault.c | 8 ++--
arch/powerpc/mm/fault.c | 20 +---
2 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/mm/copro_fault.c b/arch/powerpc/mm/copro_fault.c
index 5a236f0..0450d68 100644
--- a/arch/powerpc/mm/copro_fault.c
+++ b/arch/powerpc/mm/copro_fault.c
@@ -64,10 +64,14 @@ int copro_handle_mm_fault(struct mm_struct *mm, unsigned
long ea,
if (!(vma-vm_flags VM_WRITE))
goto out_unlock;
} else {
- if (dsisr DSISR_PROTFAULT)
- goto out_unlock;
if (!(vma-vm_flags (VM_READ | VM_EXEC)))
goto out_unlock;
+ /*
+* protfault should only happen due to us
+* mapping a region readonly temporarily. PROT_NONE
+* is also covered by the VMA check above.
+*/
+ WARN_ON_ONCE(dsisr DSISR_PROTFAULT);
}
ret = 0;
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index b434153..1bcd378 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -389,17 +389,6 @@ good_area:
#endif /* CONFIG_8xx */
if (is_exec) {
-#ifdef CONFIG_PPC_STD_MMU
- /* Protection fault on exec go straight to failure on
-* Hash based MMUs as they either don't support per-page
-* execute permission, or if they do, it's handled already
-* at the hash level. This test would probably have to
-* be removed if we change the way this works to make hash
-* processors use the same I/D cache coherency mechanism
-* as embedded.
-*/
-#endif /* CONFIG_PPC_STD_MMU */
-
/*
* Allow execution from readable areas if the MMU does not
* provide separate controls over reading and executing.
@@ -414,6 +403,14 @@ good_area:
(cpu_has_feature(CPU_FTR_NOEXECUTE) ||
!(vma-vm_flags (VM_READ | VM_WRITE
goto bad_area;
+#ifdef CONFIG_PPC_STD_MMU
+ /*
+* protfault should only happen due to us
+* mapping a region readonly temporarily. PROT_NONE
+* is also covered by the VMA check above.
+*/
+ WARN_ON_ONCE(error_code DSISR_PROTFAULT);
+#endif /* CONFIG_PPC_STD_MMU */
/* a write */
} else if (is_write) {
if (!(vma-vm_flags VM_WRITE))
@@ -423,6 +420,7 @@ good_area:
} else {
if (!(vma-vm_flags (VM_READ | VM_EXEC | VM_WRITE)))
goto bad_area;
+ WARN_ON_ONCE(error_code DSISR_PROTFAULT);
}
/*
--
2.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 05/10] mm: Convert p[te|md]_mknonnuma and remaining page table manipulations
With PROT_NONE, the traditional page table manipulation functions are
sufficient.
Signed-off-by: Mel Gorman mgor...@suse.de
Acked-by: Linus Torvalds torva...@linux-foundation.org
Acked-by: Aneesh Kumar aneesh.ku...@linux.vnet.ibm.com
Tested-by: Sasha Levin sasha.le...@oracle.com
---
include/linux/huge_mm.h | 3 +--
mm/huge_memory.c| 33 +++--
mm/memory.c | 10 ++
mm/mempolicy.c | 2 +-
mm/migrate.c| 2 +-
mm/mprotect.c | 2 +-
mm/pgtable-generic.c| 2 --
7 files changed, 17 insertions(+), 37 deletions(-)
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index ad9051b..554bbe3 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -31,8 +31,7 @@ extern int move_huge_pmd(struct vm_area_struct *vma,
unsigned long new_addr, unsigned long old_end,
pmd_t *old_pmd, pmd_t *new_pmd);
extern int change_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
- unsigned long addr, pgprot_t newprot,
- int prot_numa);
+ unsigned long addr, pgprot_t newprot);
enum transparent_hugepage_flag {
TRANSPARENT_HUGEPAGE_FLAG,
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index f81fddf..5618e22 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1366,9 +1366,8 @@ int do_huge_pmd_numa_page(struct mm_struct *mm, struct
vm_area_struct *vma,
goto out;
clear_pmdnuma:
BUG_ON(!PageLocked(page));
- pmd = pmd_mknonnuma(pmd);
+ pmd = pmd_modify(pmd, vma-vm_page_prot);
set_pmd_at(mm, haddr, pmdp, pmd);
- VM_BUG_ON(pmd_protnone(*pmdp));
update_mmu_cache_pmd(vma, addr, pmdp);
unlock_page(page);
out_unlock:
@@ -1503,7 +1502,7 @@ out:
* - HPAGE_PMD_NR is protections changed and TLB flush necessary
*/
int change_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
- unsigned long addr, pgprot_t newprot, int prot_numa)
+ unsigned long addr, pgprot_t newprot)
{
struct mm_struct *mm = vma-vm_mm;
spinlock_t *ptl;
@@ -1512,29 +1511,11 @@ int change_huge_pmd(struct vm_area_struct *vma, pmd_t
*pmd,
if (__pmd_trans_huge_lock(pmd, vma, ptl) == 1) {
pmd_t entry;
ret = 1;
- if (!prot_numa) {
- entry = pmdp_get_and_clear_notify(mm, addr, pmd);
- if (pmd_protnone(entry))
- entry = pmd_mknonnuma(entry);
- entry = pmd_modify(entry, newprot);
- ret = HPAGE_PMD_NR;
- set_pmd_at(mm, addr, pmd, entry);
- BUG_ON(pmd_write(entry));
- } else {
- struct page *page = pmd_page(*pmd);
-
- /*
-* Do not trap faults against the zero page. The
-* read-only data is likely to be read-cached on the
-* local CPU cache and it is less useful to know about
-* local vs remote hits on the zero page.
-*/
- if (!is_huge_zero_page(page)
- !pmd_protnone(*pmd)) {
- pmdp_set_numa(mm, addr, pmd);
- ret = HPAGE_PMD_NR;
- }
- }
+ entry = pmdp_get_and_clear_notify(mm, addr, pmd);
+ entry = pmd_modify(entry, newprot);
+ ret = HPAGE_PMD_NR;
+ set_pmd_at(mm, addr, pmd, entry);
+ BUG_ON(pmd_write(entry));
spin_unlock(ptl);
}
diff --git a/mm/memory.c b/mm/memory.c
index eaa46f1..2100e0f 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3114,9 +3114,9 @@ static int do_numa_page(struct mm_struct *mm, struct
vm_area_struct *vma,
* validation through pte_unmap_same(). It's of NUMA type but
* the pfn may be screwed if the read is non atomic.
*
- * ptep_modify_prot_start is not called as this is clearing
- * the _PAGE_NUMA bit and it is not really expected that there
- * would be concurrent hardware modifications to the PTE.
+ * We can safely just do a set_pte_at(), because the old
+ * page table entry is not accessible, so there would be no
+ * concurrent hardware modifications to the PTE.
*/
ptl = pte_lockptr(mm, pmd);
spin_lock(ptl);
@@ -3125,7 +3125,9 @@ static int do_numa_page(struct mm_struct *mm, struct
vm_area_struct *vma,
goto out;
}
- pte = pte_mknonnuma(pte);
+ /* Make it present again */
+ pte = pte_modify(pte, vma-vm_page_prot);
+ pte = pte_mkyoung(pte);
set_pte_at(mm, addr, ptep, pte);
update_mmu_cache(vma, addr, ptep);
diff --git a/mm/mempolicy.c
[PATCH 06/10] mm: Remove remaining references to NUMA hinting bits and helpers
This patch removes the NUMA PTE bits and associated helpers. As a side-effect
it increases the maximum possible swap space on x86-64.
One potential source of problems is races between the marking of PTEs
PROT_NONE, NUMA hinting faults and migration. It must be guaranteed that
a PTE being protected is not faulted in parallel, seen as a pte_none and
corrupting memory. The base case is safe but transhuge has problems in the
past due to an different migration mechanism and a dependance on page lock
to serialise migrations and warrants a closer look.
task_work hinting updateparallel fault
--
change_pmd_range
change_huge_pmd
__pmd_trans_huge_lock
pmdp_get_and_clear
__handle_mm_fault
pmd_none
do_huge_pmd_anonymous_page
read? pmd_lock blocks until
hinting complete, fail !pmd_none test
write?
__do_huge_pmd_anonymous_page acquires pmd_lock, checks pmd_none
pmd_modify
set_pmd_at
task_work hinting updateparallel migration
--
change_pmd_range
change_huge_pmd
__pmd_trans_huge_lock
pmdp_get_and_clear
__handle_mm_fault
do_huge_pmd_numa_page
migrate_misplaced_transhuge_page
pmd_lock waits for updates
to complete, recheck pmd_same
pmd_modify
set_pmd_at
Both of those are safe and the case where a transhuge page is inserted
during a protection update is unchanged. The case where two processes try
migrating at the same time is unchanged by this series so should still be
ok. I could not find a case where we are accidentally depending on the
PTE not being cleared and flushed. If one is missed, it'll manifest as
corruption problems that start triggering shortly after this series is
merged and only happen when NUMA balancing is enabled.
Signed-off-by: Mel Gorman mgor...@suse.de
Tested-by: Sasha Levin sasha.le...@oracle.com
---
arch/powerpc/include/asm/pgtable.h| 54 +---
arch/powerpc/include/asm/pte-common.h | 5 --
arch/powerpc/include/asm/pte-hash64.h | 6 --
arch/x86/include/asm/pgtable.h| 22 +
arch/x86/include/asm/pgtable_64.h | 5 --
arch/x86/include/asm/pgtable_types.h | 41 +
include/asm-generic/pgtable.h | 155 --
include/linux/swapops.h | 2 +-
8 files changed, 7 insertions(+), 283 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable.h
b/arch/powerpc/include/asm/pgtable.h
index 7b889a3..0a85e33 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -54,64 +54,12 @@ static inline int pmd_protnone(pmd_t pmd)
{
return pte_protnone(pmd_pte(pmd));
}
-
-static inline int pte_present(pte_t pte)
-{
- return pte_val(pte) _PAGE_NUMA_MASK;
-}
-
-#define pte_present_nonuma pte_present_nonuma
-static inline int pte_present_nonuma(pte_t pte)
-{
- return pte_val(pte) (_PAGE_PRESENT);
-}
-
-#define ptep_set_numa ptep_set_numa
-static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr,
-pte_t *ptep)
-{
- if ((pte_val(*ptep) _PAGE_PRESENT) == 0)
- VM_BUG_ON(1);
-
- pte_update(mm, addr, ptep, _PAGE_PRESENT, _PAGE_NUMA, 0);
- return;
-}
-
-#define pmdp_set_numa pmdp_set_numa
-static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr,
-pmd_t *pmdp)
-{
- if ((pmd_val(*pmdp) _PAGE_PRESENT) == 0)
- VM_BUG_ON(1);
-
- pmd_hugepage_update(mm, addr, pmdp, _PAGE_PRESENT, _PAGE_NUMA);
- return;
-}
-
-/*
- * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist
- * which was inherited from x86. For the purposes of powerpc pte_basic_t and
- * pmd_t are equivalent
- */
-#define pteval_t pte_basic_t
-#define pmdval_t pmd_t
-static inline pteval_t ptenuma_flags(pte_t pte)
-{
- return pte_val(pte) _PAGE_NUMA_MASK;
-}
-
-static inline pmdval_t pmdnuma_flags(pmd_t pmd)
-{
- return pmd_val(pmd) _PAGE_NUMA_MASK;
-}
-
-# else
+#endif /* CONFIG_NUMA_BALANCING */
static inline int pte_present(pte_t pte)
{
return pte_val(pte) _PAGE_PRESENT;
}
-#endif /* CONFIG_NUMA_BALANCING */
/* Conversion functions: convert a page and protection to a page entry,
* and a page entry and page directory to the page they refer to.
diff --git a/arch/powerpc/include/asm/pte-common.h
b/arch/powerpc/include/asm/pte-common.h
index e040c35..8d1569c
[PATCH 07/10] mm: numa: Do not trap faults on the huge zero page
Faults on the huge zero page are pointless and there is a BUG_ON
to catch them during fault time. This patch reintroduces a check
that avoids marking the zero page PAGE_NONE.
Signed-off-by: Mel Gorman mgor...@suse.de
---
include/linux/huge_mm.h | 3 ++-
mm/huge_memory.c| 13 -
mm/memory.c | 1 -
mm/mprotect.c | 15 ++-
4 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 554bbe3..ad9051b 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -31,7 +31,8 @@ extern int move_huge_pmd(struct vm_area_struct *vma,
unsigned long new_addr, unsigned long old_end,
pmd_t *old_pmd, pmd_t *new_pmd);
extern int change_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
- unsigned long addr, pgprot_t newprot);
+ unsigned long addr, pgprot_t newprot,
+ int prot_numa);
enum transparent_hugepage_flag {
TRANSPARENT_HUGEPAGE_FLAG,
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 5618e22..ad2a3ee 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1502,7 +1502,7 @@ out:
* - HPAGE_PMD_NR is protections changed and TLB flush necessary
*/
int change_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
- unsigned long addr, pgprot_t newprot)
+ unsigned long addr, pgprot_t newprot, int prot_numa)
{
struct mm_struct *mm = vma-vm_mm;
spinlock_t *ptl;
@@ -1510,6 +1510,17 @@ int change_huge_pmd(struct vm_area_struct *vma, pmd_t
*pmd,
if (__pmd_trans_huge_lock(pmd, vma, ptl) == 1) {
pmd_t entry;
+
+ /*
+* Avoid trapping faults against the zero page. The read-only
+* data is likely to be read-cached on the local CPU and
+* local/remote hits to the zero page are not interesting.
+*/
+ if (prot_numa is_huge_zero_pmd(*pmd)) {
+ spin_unlock(ptl);
+ return 0;
+ }
+
ret = 1;
entry = pmdp_get_and_clear_notify(mm, addr, pmd);
entry = pmd_modify(entry, newprot);
diff --git a/mm/memory.c b/mm/memory.c
index 2100e0f..2ec07a9 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3136,7 +3136,6 @@ static int do_numa_page(struct mm_struct *mm, struct
vm_area_struct *vma,
pte_unmap_unlock(ptep, ptl);
return 0;
}
- BUG_ON(is_zero_pfn(page_to_pfn(page)));
/*
* Avoid grouping on DSO/COW pages in specific and RO pages
diff --git a/mm/mprotect.c b/mm/mprotect.c
index dc65c0f..33dfafb 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -75,6 +75,19 @@ static unsigned long change_pte_range(struct vm_area_struct
*vma, pmd_t *pmd,
oldpte = *pte;
if (pte_present(oldpte)) {
pte_t ptent;
+
+ /*
+* Avoid trapping faults against the zero or KSM
+* pages. See similar comment in change_huge_pmd.
+*/
+ if (prot_numa) {
+ struct page *page;
+
+ page = vm_normal_page(vma, addr, oldpte);
+ if (!page || PageKsm(page))
+ continue;
+ }
+
ptent = ptep_modify_prot_start(mm, addr, pte);
ptent = pte_modify(ptent, newprot);
@@ -141,7 +154,7 @@ static inline unsigned long change_pmd_range(struct
vm_area_struct *vma,
split_huge_page_pmd(vma, addr, pmd);
else {
int nr_ptes = change_huge_pmd(vma, pmd, addr,
- newprot);
+ newprot, prot_numa);
if (nr_ptes) {
if (nr_ptes == HPAGE_PMD_NR) {
--
2.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 08/10] x86: mm: Restore original pte_special check
Commit b38af4721f59 (x86,mm: fix pte_special versus pte_numa) adjusted
the pte_special check to take into account that a special pte had SPECIAL
and neither PRESENT nor PROTNONE. Now that NUMA hinting PTEs are no
longer modifying _PAGE_PRESENT it should be safe to restore the original
pte_special behaviour.
Signed-off-by: Mel Gorman mgor...@suse.de
---
arch/x86/include/asm/pgtable.h | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index cf428a7..0dd5be3 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -136,13 +136,7 @@ static inline int pte_exec(pte_t pte)
static inline int pte_special(pte_t pte)
{
- /*
-* See CONFIG_NUMA_BALANCING pte_numa in include/asm-generic/pgtable.h.
-* On x86 we have _PAGE_BIT_NUMA == _PAGE_BIT_GLOBAL+1 ==
-* __PAGE_BIT_SOFTW1 == _PAGE_BIT_SPECIAL.
-*/
- return (pte_flags(pte) _PAGE_SPECIAL)
- (pte_flags(pte) (_PAGE_PRESENT|_PAGE_PROTNONE));
+ return pte_flags(pte) _PAGE_SPECIAL;
}
static inline unsigned long pte_pfn(pte_t pte)
--
2.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 09/10] mm: numa: Add paranoid check around pte_protnone_numa
pte_protnone_numa is only safe to use after VMA checks for PROT_NONE are complete. Treating a real PROT_NONE PTE as a NUMA hinting fault is going to result in strangeness so add a check for it. BUG_ON looks like overkill but if this is hit then it's a serious bug that could result in corruption so do not even try recovering. It would have been more comprehensive to check VMA flags in pte_protnone_numa but it would have made the API ugly just for a debugging check. Signed-off-by: Mel Gorman mgor...@suse.de --- mm/huge_memory.c | 3 +++ mm/memory.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index ad2a3ee..8546654 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1273,6 +1273,9 @@ int do_huge_pmd_numa_page(struct mm_struct *mm, struct vm_area_struct *vma, bool migrated = false; int flags = 0; + /* A PROT_NONE fault should not end up here */ + BUG_ON(!(vma-vm_flags (VM_READ | VM_EXEC | VM_WRITE))); + ptl = pmd_lock(mm, pmdp); if (unlikely(!pmd_same(pmd, *pmdp))) goto out_unlock; diff --git a/mm/memory.c b/mm/memory.c index 2ec07a9..7d97af5 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -3109,6 +3109,9 @@ static int do_numa_page(struct mm_struct *mm, struct vm_area_struct *vma, bool migrated = false; int flags = 0; + /* A PROT_NONE fault should not end up here */ + BUG_ON(!(vma-vm_flags (VM_READ | VM_EXEC | VM_WRITE))); + /* * The pte at this point cannot be used safely without * validation through pte_unmap_same(). It's of NUMA type but -- 2.1.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 10/10] mm: numa: Avoid unnecessary TLB flushes when setting NUMA hinting entries
If a PTE or PMD is already marked NUMA when scanning to mark entries
for NUMA hinting then it is not necessary to update the entry and
incur a TLB flush penalty. Avoid the avoidhead where possible.
Signed-off-by: Mel Gorman mgor...@suse.de
---
mm/huge_memory.c | 14 --
mm/mprotect.c| 4
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 8546654..f2bf521 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1524,12 +1524,14 @@ int change_huge_pmd(struct vm_area_struct *vma, pmd_t
*pmd,
return 0;
}
- ret = 1;
- entry = pmdp_get_and_clear_notify(mm, addr, pmd);
- entry = pmd_modify(entry, newprot);
- ret = HPAGE_PMD_NR;
- set_pmd_at(mm, addr, pmd, entry);
- BUG_ON(pmd_write(entry));
+ if (!prot_numa || !pmd_protnone(*pmd)) {
+ ret = 1;
+ entry = pmdp_get_and_clear_notify(mm, addr, pmd);
+ entry = pmd_modify(entry, newprot);
+ ret = HPAGE_PMD_NR;
+ set_pmd_at(mm, addr, pmd, entry);
+ BUG_ON(pmd_write(entry));
+ }
spin_unlock(ptl);
}
diff --git a/mm/mprotect.c b/mm/mprotect.c
index 33dfafb..109e7aa 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -86,6 +86,10 @@ static unsigned long change_pte_range(struct vm_area_struct
*vma, pmd_t *pmd,
page = vm_normal_page(vma, addr, oldpte);
if (!page || PageKsm(page))
continue;
+
+ /* Avoid TLB flush if possible */
+ if (pte_protnone(oldpte))
+ continue;
}
ptent = ptep_modify_prot_start(mm, addr, pte);
--
2.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 1/4] tools/perf: support parsing parameterized events
On Tue, Dec 02, 2014 at 06:09:35PM -0800, Sukadev Bhattiprolu wrote: From: Cody P Schafer c...@linux.vnet.ibm.com Enable event specification like: pmu/event_name,param1=0x1,param2=0x4/ Assuming that /sys/bus/event_source/devices/pmu/events/event_name Contains something like param2=$foo,bar=1,param1=$baz oops.. sorry to be PITA on this one.. I might have missed something in the previous discussion but I guess I might have finally some opinion on this ;-) here's how I think your patchset works: in /sys/bus/event_source/devices/pmu/events/event_name you can actually have: param2=foo,bar=1,param1=baz notice no '$', thats what you add later in 'perf list' output, right? Moreover it actually does not matter whats in value 'param2=HERE', because it's not used in the config code at all apart from the 'perf list' display processing. So when we discussed the '$' name way, I thought it'd be like: in /sys/bus/event_source/devices/pmu/events/event_name you have: param2=$foo,bar=1,param1=$baz and on command line you'd use: pmu/event_name,foo=0x1,bar=0x4/ to assign directly to the $var, which would justify the $var syntax I think.. anyway we could assign directly to the param term name as you do, but I think we just need to mark the term as parametrized, like: in /sys/bus/event_source/devices/pmu/events/event_name you have: param2=?,bar=1,param1=? and on command line you'd use: pmu/event_name,param2=0x1,param1=0x4/ while the config code would check that the param substitution is done only for terms with '?' in value, like 'param2=?' and not for all PARSE_EVENTS__TERM_TYPE_STR type terms (as of now) thanks, jirka ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
ppc64 and Documentation/mic/mpssd/mpssd.c issues
Hi Caz, I think commit ... commit 8d49751580db804a02caf6a5b7cebe2ff26c0d7e Author: Caz Yokoyama caz.yokoy...@intel.com Date: Thu Sep 5 16:42:39 2013 -0700 Sample Implementation of Intel MIC User Space Daemon. ... actually triggers a build error on my default config ppc64 (I'm using net-next tree): HOSTCC Documentation/mic/mpssd/mpssd.o Documentation/mic/mpssd/mpssd.c:93: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:96: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:113: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:116: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:119: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:146: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:149: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:151: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:152: error: braced-group within expression allowed only inside a function make[3]: *** [Documentation/mic/mpssd/mpssd.o] Error 1 make[2]: *** [Documentation/mic/mpssd] Error 2 make[1]: *** [Documentation/mic] Error 2 make: *** [vmlinux] Error 2 gcc --version gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11) Cheers, Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC 2/2] sound: ppc: keywest: drop using attach adapter
As we now have deferred probing, we can use a custom mechanism and
finally get rid of the legacy interface from the i2c core.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
sound/ppc/keywest.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/sound/ppc/keywest.c b/sound/ppc/keywest.c
index 0d1c27e911b8..a957f32368fa 100644
--- a/sound/ppc/keywest.c
+++ b/sound/ppc/keywest.c
@@ -52,7 +52,7 @@ static int keywest_attach_adapter(struct i2c_adapter *adapter)
return -EINVAL;
if (strncmp(adapter-name, mac-io, 6))
- return 0; /* ignored */
+ return -EINVAL; /* ignored */
memset(info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, keywest, I2C_NAME_SIZE);
@@ -100,7 +100,6 @@ static struct i2c_driver keywest_driver = {
.driver = {
.name = PMac Keywest Audio,
},
- .attach_adapter = keywest_attach_adapter,
.probe = keywest_probe,
.remove = keywest_remove,
.id_table = keywest_i2c_id,
@@ -132,16 +131,32 @@ int snd_pmac_tumbler_post_init(void)
/* exported */
int snd_pmac_keywest_init(struct pmac_keywest *i2c)
{
- int err;
+ struct i2c_adapter *adap;
+ int err, i = 0;
if (keywest_ctx)
return -EBUSY;
+ adap = i2c_get_adapter(0);
+ if (!adap)
+ return -EPROBE_DEFER;
+
keywest_ctx = i2c;
if ((err = i2c_add_driver(keywest_driver))) {
snd_printk(KERN_ERR cannot register keywest i2c driver\n);
+ i2c_put_adapter(adap);
return err;
}
+
+ /* We assume Macs have consecutive I2C bus numbers starting at 0 */
+ while (adap) {
+ err = keywest_attach_adapter(adap);
+ if (!err)
+ break;
+ i2c_put_adapter(adap);
+ adap = i2c_get_adapter(++i);
+ }
+
return 0;
}
--
2.1.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC 1/2] macintosh: therm_windtunnel: drop using attach adapter
As we now have deferred probing, we can use a custom mechanism and
finally get rid of the legacy interface from the i2c core.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/macintosh/therm_windtunnel.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/macintosh/therm_windtunnel.c
b/drivers/macintosh/therm_windtunnel.c
index 3b4a157714b1..9de83cdd0bca 100644
--- a/drivers/macintosh/therm_windtunnel.c
+++ b/drivers/macintosh/therm_windtunnel.c
@@ -431,7 +431,6 @@ static struct i2c_driver g4fan_driver = {
.driver = {
.name = therm_windtunnel,
},
- .attach_adapter = do_attach,
.probe = do_probe,
.remove = do_remove,
.id_table = therm_windtunnel_id,
@@ -444,7 +443,29 @@ static struct i2c_driver g4fan_driver = {
static int therm_of_probe(struct platform_device *dev)
{
- return i2c_add_driver( g4fan_driver );
+ struct i2c_adapter *adap;
+ int ret, i = 0;
+
+ adap = i2c_get_adapter(0);
+ if (!adap)
+ return -EPROBE_DEFER;
+
+ ret = i2c_add_driver(g4fan_driver);
+ if (ret) {
+ i2c_put_adapter(adap);
+ return ret;
+ }
+
+ /* We assume Macs have consecutive I2C bus numbers starting at 0 */
+ while (adap) {
+ do_attach(adap);
+ if (x.running)
+ break;
+ i2c_put_adapter(adap);
+ adap = i2c_get_adapter(++i);
+ }
+
+ return 0;
}
static int
--
2.1.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC 0/2] get rid of remaining users of attach_adapter
The attach_adapter mechanism of the I2C framework is deprecated for years. There are two users left, drivers for old Macintosh computers. I recently got the idea of replacing this mechanism with a custom one with the help of deferred probing. Because I don't have the hardware, I worked on a seperate branch where I modified the windtunnel driver to be runnable on my Renesas Lager board (ARM). I first verified that the attach_adapter method was used, then the driver rightfully failed on detecting the i2c clients. Using my custom mechanism, the same happens: all busses get scanned, then the clients cannot be detected. Since I didn't change the actual detection code, I assume that it should be working on those Macintosh devices as well. The keywest driver is only compile-tested. That being said, I'd be more than happy, if we could find someone willing to test these patches. If they could be applied, we can _finally_ get rid of this legacy mechanism and clean up the i2c core. The branch I used for ARM compilation is here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/attach_adapter_removal_with_arm_compile-experimental Thanks, Wolfram Wolfram Sang (2): macintosh: therm_windtunnel: drop using attach adapter sound: ppc: keywest: drop using attach adapter drivers/macintosh/therm_windtunnel.c | 25 +++-- sound/ppc/keywest.c | 21 ++--- 2 files changed, 41 insertions(+), 5 deletions(-) -- 2.1.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [RFC 2/2] sound: ppc: keywest: drop using attach adapter
At Thu, 4 Dec 2014 17:41:53 +0100,
Wolfram Sang wrote:
As we now have deferred probing, we can use a custom mechanism and
finally get rid of the legacy interface from the i2c core.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
sound/ppc/keywest.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/sound/ppc/keywest.c b/sound/ppc/keywest.c
index 0d1c27e911b8..a957f32368fa 100644
--- a/sound/ppc/keywest.c
+++ b/sound/ppc/keywest.c
@@ -52,7 +52,7 @@ static int keywest_attach_adapter(struct i2c_adapter
*adapter)
return -EINVAL;
if (strncmp(adapter-name, mac-io, 6))
- return 0; /* ignored */
+ return -EINVAL; /* ignored */
memset(info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, keywest, I2C_NAME_SIZE);
@@ -100,7 +100,6 @@ static struct i2c_driver keywest_driver = {
.driver = {
.name = PMac Keywest Audio,
},
- .attach_adapter = keywest_attach_adapter,
.probe = keywest_probe,
.remove = keywest_remove,
.id_table = keywest_i2c_id,
@@ -132,16 +131,32 @@ int snd_pmac_tumbler_post_init(void)
/* exported */
int snd_pmac_keywest_init(struct pmac_keywest *i2c)
{
- int err;
+ struct i2c_adapter *adap;
+ int err, i = 0;
if (keywest_ctx)
return -EBUSY;
+ adap = i2c_get_adapter(0);
+ if (!adap)
+ return -EPROBE_DEFER;
+
keywest_ctx = i2c;
if ((err = i2c_add_driver(keywest_driver))) {
snd_printk(KERN_ERR cannot register keywest i2c driver\n);
+ i2c_put_adapter(adap);
return err;
}
+
+ /* We assume Macs have consecutive I2C bus numbers starting at 0 */
+ while (adap) {
+ err = keywest_attach_adapter(adap);
+ if (!err)
+ break;
+ i2c_put_adapter(adap);
+ adap = i2c_get_adapter(++i);
+ }
+
return 0;
What if adap is NULL in the last while loop? Isn't it supposed to
return an error?
thanks,
Takashi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc64 and Documentation/mic/mpssd/mpssd.c issues
On 12/04/2014 05:57 PM, Sudeep Dutt wrote: On Thu, 2014-12-04 at 08:48 -0800, Yokoyama, Caz wrote: Thank you for the report. Have you tried to compile on x86_64? Which rhel do you use? Rhel6.X? MIC card is expected to work with x86_64 host, not with ppc64. We have never compiled on ppc host while our primary development platform was rhel6.X. Yep, I was using RHEL6 on ppc64 by chance to build an upstream kernel. You might want to fix the Kconfig entry then to limit this to x86_64 only. ;) Thanks, Daniel I am adding Peter Foley since he enabled the mpssd build by default recently with commit adb19fb. Peter, is there a way to enable the mpssd build only for x86_64? Thanks, Sudeep Dutt Line 92 is the first use of htole16 and MIC_VRING_ENTRIES. Is there any change on them? Thank you. -caz, caz.yokoy...@intel.com, yokoy...@member.fsf.org -Original Message- From: Daniel Borkmann [mailto:dbork...@redhat.com] Sent: Thursday, December 04, 2014 5:42 AM To: Yokoyama, Caz Cc: b...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org Subject: ppc64 and Documentation/mic/mpssd/mpssd.c issues Hi Caz, I think commit ... commit 8d49751580db804a02caf6a5b7cebe2ff26c0d7e Author: Caz Yokoyama caz.yokoy...@intel.com Date: Thu Sep 5 16:42:39 2013 -0700 Sample Implementation of Intel MIC User Space Daemon. ... actually triggers a build error on my default config ppc64 (I'm using net-next tree): HOSTCC Documentation/mic/mpssd/mpssd.o Documentation/mic/mpssd/mpssd.c:93: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:96: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:113: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:116: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:119: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:146: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:149: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:151: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:152: error: braced-group within expression allowed only inside a function make[3]: *** [Documentation/mic/mpssd/mpssd.o] Error 1 make[2]: *** [Documentation/mic/mpssd] Error 2 make[1]: *** [Documentation/mic] Error 2 make: *** [vmlinux] Error 2 gcc --version gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11) Cheers, Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [RFC 2/2] sound: ppc: keywest: drop using attach adapter
+
+ /* We assume Macs have consecutive I2C bus numbers starting at 0 */
+ while (adap) {
+ err = keywest_attach_adapter(adap);
+ if (!err)
+ break;
+ i2c_put_adapter(adap);
+ adap = i2c_get_adapter(++i);
+ }
+
return 0;
What if adap is NULL in the last while loop? Isn't it supposed to
return an error?
True, we probably should have something like
return adap ? 0 : -ENODEV;
Thanks!
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 1/1] powerpc/85xx: Add support for Emerson/Artesyn MVME2500.
On Thu, 2014-12-04 at 10:23 +0100, Alessio Igor Bogani wrote: +/include/ fsl/pq3-mpic-message-B.dtsi The MPIC message include should be done in the SoC file -- it's not board-specific. For some reason I don't see this dtsi being included by anything currently. @@ -80,33 +82,21 @@ CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_MTD=y -CONFIG_MTD_OF_PARTS=y CONFIG_MTD_CMDLINE_PARTS=y -CONFIG_MTD_CHAR=y -CONFIG_MTD_BLKDEVS=y CONFIG_MTD_BLOCK=y CONFIG_FTL=y CONFIG_MTD_CFI=y -CONFIG_MTD_GEN_PROBE=y -CONFIG_MTD_MAP_BANK_WIDTH_1=y -CONFIG_MTD_MAP_BANK_WIDTH_2=y -CONFIG_MTD_MAP_BANK_WIDTH_4=y -CONFIG_MTD_CFI_I1=y -CONFIG_MTD_CFI_I2=y Are these removals due to make savedefconfig? Please have a separate patch that just runs make savedefconfig first, so that we can see what actual changes are being made. Otherwise, looks good. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc64 and Documentation/mic/mpssd/mpssd.c issues
On Thu, 2014-12-04 at 16:48 +, Yokoyama, Caz wrote: Thank you for the report. Have you tried to compile on x86_64? Which rhel do you use? Rhel6.X? MIC card is expected to work with x86_64 host, not with ppc64. We have never compiled on ppc host while our primary development platform was rhel6.X. Line 92 is the first use of htole16 and MIC_VRING_ENTRIES. Is there any change on them? Then you should make sure your Kconfig/Makefile stanza only compiles it on x86_64 instead of breaking all other architectures... Ben. Thank you. -caz, caz.yokoy...@intel.com, yokoy...@member.fsf.org -Original Message- From: Daniel Borkmann [mailto:dbork...@redhat.com] Sent: Thursday, December 04, 2014 5:42 AM To: Yokoyama, Caz Cc: b...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org Subject: ppc64 and Documentation/mic/mpssd/mpssd.c issues Hi Caz, I think commit ... commit 8d49751580db804a02caf6a5b7cebe2ff26c0d7e Author: Caz Yokoyama caz.yokoy...@intel.com Date: Thu Sep 5 16:42:39 2013 -0700 Sample Implementation of Intel MIC User Space Daemon. ... actually triggers a build error on my default config ppc64 (I'm using net-next tree): HOSTCC Documentation/mic/mpssd/mpssd.o Documentation/mic/mpssd/mpssd.c:93: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:96: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:113: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:116: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:119: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:146: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:149: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:151: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:152: error: braced-group within expression allowed only inside a function make[3]: *** [Documentation/mic/mpssd/mpssd.o] Error 1 make[2]: *** [Documentation/mic/mpssd] Error 2 make[1]: *** [Documentation/mic] Error 2 make: *** [vmlinux] Error 2 gcc --version gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11) Cheers, Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: ppc64 and Documentation/mic/mpssd/mpssd.c issues
On Thu, 2014-12-04 at 08:48 -0800, Yokoyama, Caz wrote: Thank you for the report. Have you tried to compile on x86_64? Which rhel do you use? Rhel6.X? MIC card is expected to work with x86_64 host, not with ppc64. We have never compiled on ppc host while our primary development platform was rhel6.X. I am adding Peter Foley since he enabled the mpssd build by default recently with commit adb19fb. Peter, is there a way to enable the mpssd build only for x86_64? Thanks, Sudeep Dutt Line 92 is the first use of htole16 and MIC_VRING_ENTRIES. Is there any change on them? Thank you. -caz, caz.yokoy...@intel.com, yokoy...@member.fsf.org -Original Message- From: Daniel Borkmann [mailto:dbork...@redhat.com] Sent: Thursday, December 04, 2014 5:42 AM To: Yokoyama, Caz Cc: b...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org Subject: ppc64 and Documentation/mic/mpssd/mpssd.c issues Hi Caz, I think commit ... commit 8d49751580db804a02caf6a5b7cebe2ff26c0d7e Author: Caz Yokoyama caz.yokoy...@intel.com Date: Thu Sep 5 16:42:39 2013 -0700 Sample Implementation of Intel MIC User Space Daemon. ... actually triggers a build error on my default config ppc64 (I'm using net-next tree): HOSTCC Documentation/mic/mpssd/mpssd.o Documentation/mic/mpssd/mpssd.c:93: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:96: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:113: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:116: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:119: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:146: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:149: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:151: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:152: error: braced-group within expression allowed only inside a function make[3]: *** [Documentation/mic/mpssd/mpssd.o] Error 1 make[2]: *** [Documentation/mic/mpssd] Error 2 make[1]: *** [Documentation/mic] Error 2 make: *** [vmlinux] Error 2 gcc --version gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11) Cheers, Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: ppc64 and Documentation/mic/mpssd/mpssd.c issues
Thank you for the report. Have you tried to compile on x86_64? Which rhel do you use? Rhel6.X? MIC card is expected to work with x86_64 host, not with ppc64. We have never compiled on ppc host while our primary development platform was rhel6.X. Line 92 is the first use of htole16 and MIC_VRING_ENTRIES. Is there any change on them? Thank you. -caz, caz.yokoy...@intel.com, yokoy...@member.fsf.org -Original Message- From: Daniel Borkmann [mailto:dbork...@redhat.com] Sent: Thursday, December 04, 2014 5:42 AM To: Yokoyama, Caz Cc: b...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org Subject: ppc64 and Documentation/mic/mpssd/mpssd.c issues Hi Caz, I think commit ... commit 8d49751580db804a02caf6a5b7cebe2ff26c0d7e Author: Caz Yokoyama caz.yokoy...@intel.com Date: Thu Sep 5 16:42:39 2013 -0700 Sample Implementation of Intel MIC User Space Daemon. ... actually triggers a build error on my default config ppc64 (I'm using net-next tree): HOSTCC Documentation/mic/mpssd/mpssd.o Documentation/mic/mpssd/mpssd.c:93: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:96: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:113: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:116: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:119: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:146: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:149: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:151: error: braced-group within expression allowed only inside a function Documentation/mic/mpssd/mpssd.c:152: error: braced-group within expression allowed only inside a function make[3]: *** [Documentation/mic/mpssd/mpssd.o] Error 1 make[2]: *** [Documentation/mic/mpssd] Error 2 make[1]: *** [Documentation/mic] Error 2 make: *** [vmlinux] Error 2 gcc --version gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11) Cheers, Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc64 and Documentation/mic/mpssd/mpssd.c issues
On Thu, Dec 4, 2014 at 11:57 AM, Sudeep Dutt sudeep.d...@intel.com wrote: On Thu, 2014-12-04 at 08:48 -0800, Yokoyama, Caz wrote: Thank you for the report. Have you tried to compile on x86_64? Which rhel do you use? Rhel6.X? MIC card is expected to work with x86_64 host, not with ppc64. We have never compiled on ppc host while our primary development platform was rhel6.X. I am adding Peter Foley since he enabled the mpssd build by default recently with commit adb19fb. Peter, is there a way to enable the mpssd build only for x86_64? Change hostprogs-y to hostprogs-$(CONFIG_X86_64) in the mpssd Makefile. That will restrict it to x86_64 only. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH linux-next] Documentation: Build mic/mpssd only for x86_64
mic/mpssd along with MIC drivers are currently only usable on x86_64. So build mic/mpssd only for x86_64 to avoid build breaks on big-endian systems. Reported-by: Daniel Borkmann dbork...@redhat.com Reported-by: Dan Streetman ddstr...@gmail.com Suggested-by: Peter Foley pefol...@pefoley.com Signed-off-by: Ashutosh Dixit ashutosh.di...@intel.com --- Documentation/mic/mpssd/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/mic/mpssd/Makefile b/Documentation/mic/mpssd/Makefile index 0f31568..f47fe6b 100644 --- a/Documentation/mic/mpssd/Makefile +++ b/Documentation/mic/mpssd/Makefile @@ -1,5 +1,5 @@ # List of programs to build -hostprogs-y := mpssd +hostprogs-$(CONFIG_X86_64) := mpssd mpssd-objs := mpssd.o sysfs.o -- 2.0.0.rc3.2.g998f840 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/pci: remove pci device on a bus in reverse order
On Thu, Dec 04, 2014 at 03:21:18PM +0800, Wei Yang wrote: On Thu, Dec 04, 2014 at 04:40:35PM +1100, Michael Ellerman wrote: On Thu, 2014-04-12 at 03:24:37 UTC, Wei Yang wrote: As in commit ac205b7b (PCI: make sriov work with hotplug remove) indicates, when removing pci devices on a bus which has VFs, we need to remove them in the reverse order. This patch applies this pattern on the hotplug remove path on powerpc arch. So is this is a bug fix? It hasn't trigger a bug yet. I found this issue during the code reading. When VFs are enabled and try to remove a bus with VFs, it will face a problem. So I port the change in commit ac205b7b here. Where/how have you tested this? I have tested after change on Power8, the EEH hotplug path works fine for PFs now. Will test this when EEH for VFs are ready. Suggest me to keep it untill EEH for VFs are ready? Please keep it and resend it (with typo fixed as I pointed) after SRIOV patchset gets merged. If SRIOV isn't enabled, we don't need the code change. By the way, it's something related to EEH for PFs. When PF and its VFs seat on same PCI bus, we should remove VFs before putting PF offline in the reversed order as you did in your code change. Otherwise, PF is put into offline and its driver disables VFs. We try redoing the removal for VFs in hotplug path, which would cause race condition. If VFs aren't existing, until your SRIOV patchset is merged, we don't have this problem. Please correct me if I understood things wrongly. Thanks, Gavin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] ASoC: fsl_ssi: fix error path in probe
On Tue, Dec 02, 2014 at 02:55:06PM +0900, Jiada Wang wrote: SSI component isn't unregistered if fsl_ssi_debugfs_create() fails in probe phase. applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] ASoC: fsl_ssi: use platform_get_irq instead of irq_of_parse_and_map
On Tue, Dec 02, 2014 at 02:55:07PM +0900, Jiada Wang wrote: Use platform_get_irq as no mapping needs to be done. By using platform_get_irq, driver can avoid to free IRQ manually when SSI driver exits. Fabio sent a version of this before yours so I applied his, I think the code is the same. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] Revert clk: ppc-corenet: Fix Section mismatch warning
On Thu, 2014-12-04 at 14:06 +0800, Kevin Hao wrote: On Wed, Dec 03, 2014 at 10:46:24PM -0600, Scott Wood wrote: Since only this first patch is a critical bugfix, and there's no arch/powerpc content in that patch, I think it should go via Mike's tree if it's to go in for 3.18 (if it's not already too late). Or, to keep things simple given the dependency of the following patches, we could batch them all together for -next and add a # 3.18 stable request. We don't need to explicitly add a #3.18 stable request in this case. As I know, we only need to indicate the first version which is affected by the bug fixed by this commit in the cc tag. This would imply that the applicable stable kernel version rang should be from 3.17 to the previous version of the kernel which finally merge this commit. OK. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/pci: remove pci device on a bus in reverse order
On Fri, Dec 05, 2014 at 09:48:13AM +1100, Gavin Shan wrote: On Thu, Dec 04, 2014 at 03:21:18PM +0800, Wei Yang wrote: On Thu, Dec 04, 2014 at 04:40:35PM +1100, Michael Ellerman wrote: On Thu, 2014-04-12 at 03:24:37 UTC, Wei Yang wrote: As in commit ac205b7b (PCI: make sriov work with hotplug remove) indicates, when removing pci devices on a bus which has VFs, we need to remove them in the reverse order. This patch applies this pattern on the hotplug remove path on powerpc arch. So is this is a bug fix? It hasn't trigger a bug yet. I found this issue during the code reading. When VFs are enabled and try to remove a bus with VFs, it will face a problem. So I port the change in commit ac205b7b here. Where/how have you tested this? I have tested after change on Power8, the EEH hotplug path works fine for PFs now. Will test this when EEH for VFs are ready. Suggest me to keep it untill EEH for VFs are ready? Please keep it and resend it (with typo fixed as I pointed) after SRIOV patchset gets merged. If SRIOV isn't enabled, we don't need the code change. By the way, it's something related to EEH for PFs. When PF and its VFs seat on same PCI bus, we should remove VFs before putting PF offline in the reversed order as you did in your code change. Otherwise, PF is put into offline and its driver disables VFs. We try redoing the removal for VFs in hotplug path, which would cause race condition. If VFs aren't existing, until your SRIOV patchset is merged, we don't have this problem. Please correct me if I understood things wrongly. Current code is fine until VF is introduced. Yes, your understanding is correct. Thanks, Gavin -- Richard Yang Help you, Help me ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/powernv: Expose OPAL firmware symbol map
Newer versions of OPAL will provide this, so let's expose it to user
space so tools like perf can use it to properly decode samples in
firmware space.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powernv/opal.c
index 06d9076..6427959 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -61,6 +61,8 @@ static DEFINE_SPINLOCK(opal_notifier_lock);
static uint64_t last_notified_mask = 0x0ul;
static atomic_t opal_notifier_hold = ATOMIC_INIT(0);
static uint32_t opal_heartbeat;
+static void *opal_symmap;
+static uint64_t opal_symmap_size;
static void opal_reinit_cores(void)
{
@@ -604,10 +606,49 @@ static int opal_sysfs_init(void)
pr_warn(kobject_create_and_add opal failed\n);
return -ENOMEM;
}
-
return 0;
}
+static ssize_t symbol_map_read(struct file *fp, struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf, loff_t off, size_t count)
+{
+ ssize_t chunk;
+
+ if (off = opal_symmap_size)
+ return 0;
+ chunk = min_t(ssize_t, opal_symmap_size - off, count);
+ memcpy(buf, opal_symmap + off, chunk);
+
+ return chunk;
+}
+
+static BIN_ATTR_RO(symbol_map, 0);
+
+static void opal_export_symmap(void)
+{
+ const __be64 *syms;
+ unsigned int size;
+ struct device_node *fw;
+ int rc;
+
+ fw = of_find_node_by_path(/ibm,opal/firmware);
+ if (!fw)
+ return;
+ syms = of_get_property(fw, symbol-map, size);
+ if (!syms || size != 2 * sizeof(__be64))
+ return;
+
+ opal_symmap = __va(be64_to_cpu(syms[0]));
+ opal_symmap_size = be64_to_cpu(syms[1]);
+
+ /* Setup attributes */
+ bin_attr_symbol_map.size = opal_symmap_size;
+ rc = sysfs_create_bin_file(opal_kobj, bin_attr_symbol_map);
+ if (rc)
+ pr_warn(Error %d creating OPAL symbols file\n, rc);
+}
+
static void __init opal_dump_region_init(void)
{
void *addr;
@@ -738,6 +779,8 @@ static int __init opal_init(void)
/* Create opal kobject under /sys/firmware */
rc = opal_sysfs_init();
if (rc == 0) {
+ /* Export symbol map to userspace */
+ opal_export_symmap();
/* Setup dump region interface */
opal_dump_region_init();
/* Setup error log interface */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH linux-next] Documentation: Build mic/mpssd only for x86_64
On Thu, Dec 4, 2014 at 4:27 PM, Ashutosh Dixit ashutosh.di...@intel.com wrote: mic/mpssd along with MIC drivers are currently only usable on x86_64. So build mic/mpssd only for x86_64 to avoid build breaks on big-endian systems. Only building for x86_64 is fine, but in that case what's the point of leaving the htole16() et. al. functions in mpssd.c? Shouldn't they be removed? Reported-by: Daniel Borkmann dbork...@redhat.com Reported-by: Dan Streetman ddstr...@gmail.com Suggested-by: Peter Foley pefol...@pefoley.com Signed-off-by: Ashutosh Dixit ashutosh.di...@intel.com --- Documentation/mic/mpssd/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/mic/mpssd/Makefile b/Documentation/mic/mpssd/Makefile index 0f31568..f47fe6b 100644 --- a/Documentation/mic/mpssd/Makefile +++ b/Documentation/mic/mpssd/Makefile @@ -1,5 +1,5 @@ # List of programs to build -hostprogs-y := mpssd +hostprogs-$(CONFIG_X86_64) := mpssd mpssd-objs := mpssd.o sysfs.o -- 2.0.0.rc3.2.g998f840 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] Revert clk: ppc-corenet: Fix Section mismatch warning
On Wed, 2014-12-03 at 16:53 +0800, Kevin Hao wrote:
This reverts commit da788acb28386aa896224e784954bb73c99ff26c.
That commit tried to fix the section mismatch warning by moving the
ppc_corenet_clk_driver struct to init section. This is definitely wrong
because the kernel would free the memories occupied by this struct
after boot while this driver is still registered in the driver core.
The kernel would panic when accessing this driver struct.
Cc: sta...@vger.kernel.org # 3.17
Signed-off-by: Kevin Hao haoke...@gmail.com
Acked-by: Scott Wood scottw...@freescale.com
Acked-by: Michael Turquette mturque...@linaro.org
---
v3: Cc stable and add ack.
v2: A new patch in v2.
drivers/clk/clk-ppc-corenet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-ppc-corenet.c
index b6e6c85507a5..0a47d6f49cd6 100644
--- a/drivers/clk/clk-ppc-corenet.c
+++ b/drivers/clk/clk-ppc-corenet.c
@@ -291,7 +291,7 @@ static const struct of_device_id ppc_clk_ids[]
__initconst = {
{}
};
-static struct platform_driver ppc_corenet_clk_driver __initdata = {
+static struct platform_driver ppc_corenet_clk_driver = {
.driver = {
.name = ppc_corenet_clock,
.of_match_table = ppc_clk_ids,
This patch is going to conflict with commit a4ae8f3b0f7ac6ab3 clk: drop
owner assignment from platform_drivers in linux-next -- or rather,
you've based this on that patch, but it's not in mpe's next branch, so I
get a merge conflict and there'd be another merge conflict later on to
get back to the newer base.
I really think this should go via the clock tree. That's where the
breakage was introduced in the first place...
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/powernv: Expose OPAL firmware symbol map
Newer versions of OPAL will provide this, so let's expose it to user
space so tools like perf can use it to properly decode samples in
firmware space.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
v2. Use memory_read_from_buffer()
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powernv/opal.c
index 06d9076..98f50e8 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -61,6 +61,8 @@ static DEFINE_SPINLOCK(opal_notifier_lock);
static uint64_t last_notified_mask = 0x0ul;
static atomic_t opal_notifier_hold = ATOMIC_INIT(0);
static uint32_t opal_heartbeat;
+static void *opal_symmap;
+static uint64_t opal_symmap_size;
static void opal_reinit_cores(void)
{
@@ -608,6 +610,40 @@ static int opal_sysfs_init(void)
return 0;
}
+static ssize_t symbol_map_read(struct file *fp, struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf, loff_t off, size_t count)
+{
+ return memory_read_from_buffer(buf, count, off,
+ opal_symmap, opal_symmap_size);
+}
+
+static BIN_ATTR_RO(symbol_map, 0);
+
+static void opal_export_symmap(void)
+{
+ const __be64 *syms;
+ unsigned int size;
+ struct device_node *fw;
+ int rc;
+
+ fw = of_find_node_by_path(/ibm,opal/firmware);
+ if (!fw)
+ return;
+ syms = of_get_property(fw, symbol-map, size);
+ if (!syms || size != 2 * sizeof(__be64))
+ return;
+
+ opal_symmap = __va(be64_to_cpu(syms[0]));
+ opal_symmap_size = be64_to_cpu(syms[1]);
+
+ /* Setup attributes */
+ bin_attr_symbol_map.size = opal_symmap_size;
+ rc = sysfs_create_bin_file(opal_kobj, bin_attr_symbol_map);
+ if (rc)
+ pr_warn(Error %d creating OPAL symbols file\n, rc);
+}
+
static void __init opal_dump_region_init(void)
{
void *addr;
@@ -738,6 +774,8 @@ static int __init opal_init(void)
/* Create opal kobject under /sys/firmware */
rc = opal_sysfs_init();
if (rc == 0) {
+ /* Export symbol map to userspace */
+ opal_export_symmap();
/* Setup dump region interface */
opal_dump_region_init();
/* Setup error log interface */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/book3s: Fix partial invalidation of TLBs in MCE code.
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
The existing MCE code calls flush_tlb hook with IS=0 (single page) resulting
partial invalidation of TLBs which is not right. This patch fixes that
by passing IS=0xc00 to invalidate whole TLB for successful recovery from
TLB and ERAT errors.
Signed-off-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
---
Hi Michael,
This MCE fix patch is for stable.
arch/powerpc/kernel/mce_power.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/mce_power.c b/arch/powerpc/kernel/mce_power.c
index aa9aff3..b6f123a 100644
--- a/arch/powerpc/kernel/mce_power.c
+++ b/arch/powerpc/kernel/mce_power.c
@@ -79,7 +79,7 @@ static long mce_handle_derror(uint64_t dsisr, uint64_t
slb_error_bits)
}
if (dsisr P7_DSISR_MC_TLB_MULTIHIT_MFTLB) {
if (cur_cpu_spec cur_cpu_spec-flush_tlb)
- cur_cpu_spec-flush_tlb(TLBIEL_INVAL_PAGE);
+ cur_cpu_spec-flush_tlb(TLBIEL_INVAL_SET);
/* reset error bits */
dsisr = ~P7_DSISR_MC_TLB_MULTIHIT_MFTLB;
}
@@ -110,7 +110,7 @@ static long mce_handle_common_ierror(uint64_t srr1)
break;
case P7_SRR1_MC_IFETCH_TLB_MULTIHIT:
if (cur_cpu_spec cur_cpu_spec-flush_tlb) {
- cur_cpu_spec-flush_tlb(TLBIEL_INVAL_PAGE);
+ cur_cpu_spec-flush_tlb(TLBIEL_INVAL_SET);
handled = 1;
}
break;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/book3s: Fix flush_tlb cpu_spec hook to take a generic argument.
On 12/04/2014 03:05 PM, Michael Ellerman wrote: On Tue, 2014-12-02 at 14:31 +0530, Mahesh Jagannath Salgaonkar wrote: On 11/29/2014 04:08 AM, Michael Ellerman wrote: On Tue, 2014-23-09 at 03:53:54 UTC, Mahesh Salgaonkar wrote: From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com The flush_tlb hook in cpu_spec was introduced as a generic function hook to invalidate TLBs. But the current implementation of flush_tlb hook takes IS (invalidation selector) as an argument which is architecture dependent. Hence, It is not right to have a generic routine where caller has to pass non-generic argument. This patch fixes this and makes flush_tlb hook as high level API. The old code used to call flush_tlb hook with IS=0 (single page) resulting partial invalidation of TLBs which is not right. This fix now makes sure that whole TLB is invalidated to be able to successfully recover from TLB and ERAT errors. Which old code? You mean the MCE code I think. That's a bug fix, so it should be a separate patch. Yes. MCE code. Since this patch re-factors the code that takes IS as direct argument, having a separate fix patch does not make any sense and would get overwritten by this patch anyway. That's irrelevant. The fix will go to stable, the refactor will not. Please do the MCE fix as a separate, preceeding patch. Done. Sent out a separate fix patch for stable https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-December/123310.html Thanks, -Mahesh. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/book3s: Fix partial invalidation of TLBs in MCE code.
On Fri, 2014-12-05 at 10:01 +0530, Mahesh J Salgaonkar wrote:
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
The existing MCE code calls flush_tlb hook with IS=0 (single page) resulting
partial invalidation of TLBs which is not right. This patch fixes that
by passing IS=0xc00 to invalidate whole TLB for successful recovery from
TLB and ERAT errors.
What does TLBIEL_INVAL_SET means in that context ? Invalidating a set
isn't the same thing as invalidating the TLB ... and that makes no sense
without passing the page address or set # as an argument anyway
I still don't understand your flush_tlb() interface... it's arguments
don't make sense
Ben.
Signed-off-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
---
Hi Michael,
This MCE fix patch is for stable.
arch/powerpc/kernel/mce_power.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/mce_power.c b/arch/powerpc/kernel/mce_power.c
index aa9aff3..b6f123a 100644
--- a/arch/powerpc/kernel/mce_power.c
+++ b/arch/powerpc/kernel/mce_power.c
@@ -79,7 +79,7 @@ static long mce_handle_derror(uint64_t dsisr, uint64_t
slb_error_bits)
}
if (dsisr P7_DSISR_MC_TLB_MULTIHIT_MFTLB) {
if (cur_cpu_spec cur_cpu_spec-flush_tlb)
- cur_cpu_spec-flush_tlb(TLBIEL_INVAL_PAGE);
+ cur_cpu_spec-flush_tlb(TLBIEL_INVAL_SET);
/* reset error bits */
dsisr = ~P7_DSISR_MC_TLB_MULTIHIT_MFTLB;
}
@@ -110,7 +110,7 @@ static long mce_handle_common_ierror(uint64_t srr1)
break;
case P7_SRR1_MC_IFETCH_TLB_MULTIHIT:
if (cur_cpu_spec cur_cpu_spec-flush_tlb) {
- cur_cpu_spec-flush_tlb(TLBIEL_INVAL_PAGE);
+ cur_cpu_spec-flush_tlb(TLBIEL_INVAL_SET);
handled = 1;
}
break;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [2/2] pstore: add pstore support on powernv
On 12/04/2014 11:07 AM, Michael Ellerman wrote: On Wed, 2014-03-12 at 11:03:15 UTC, Hari Bathini wrote: This patch extends pstore, a generic interface to platform dependent persistent storage, support for powernv platform to capture certain useful information, during dying moments. Such support is already in place for pseries platform. This patch while adding pstore support for powernv platform, moves common code for pseries and powernv to arch/powerpc/kernel/nvram_64.c file. Please move the common code first in a separate patch. Unless there's some reason you absolutely can't do that. Sure, Michael. Let me make the changes as suggested and post the updated patch series. Thanks Hari 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
