Re: [RFC][PATCH 0/2] Add support for using reserved memory for ima buffer pass

2020-05-06 Thread Prakhar Srivastava
Hi Mark, This patch set currently only address the Pure DT implementation. EFI and ACPI implementations will be posted in subsequent patchsets. The logs are intended to be carried over the kexec and once read the logs are no longer needed and in prior conversation with James(

Re: [PATCH v2 1/2] cpufreq: qoriq: convert to a platform driver

2020-05-06 Thread Viresh Kumar
On 28-04-20, 16:31, Viresh Kumar wrote: > On 21-04-20, 10:29, Mian Yousaf Kaukab wrote: > > The driver has to be manually loaded if it is built as a module. It > > is neither exporting MODULE_DEVICE_TABLE nor MODULE_ALIAS. Moreover, > > no platform-device is created (and thus no uevent is sent)

Re: [PATCH V2 08/11] arch/kmap: Ensure kmap_prot visibility

2020-05-06 Thread Christoph Hellwig
On Sun, May 03, 2020 at 06:09:09PM -0700, ira.we...@intel.com wrote: > From: Ira Weiny > > We want to support kmap_atomic_prot() on all architectures and it makes > sense to define kmap_atomic() to use the default kmap_prot. > > So we ensure all arch's have a globally available kmap_prot either

[PATCH -next] ALSA: sound/ppc: Use bitwise instead of arithmetic operator for flags

2020-05-06 Thread Samuel Zou
Fix the following coccinelle warnings: sound/ppc/pmac.c:729:57-58: WARNING: sum of probable bitmasks, consider | sound/ppc/pmac.c:229:37-38: WARNING: sum of probable bitmasks, consider | Reported-by: Hulk Robot Signed-off-by: Samuel Zou --- sound/ppc/pmac.c | 4 ++-- 1 file changed, 2

[PATCH -next] soc: fsl_asrc: Make some functions static

2020-05-06 Thread ChenTao
Fix the following warning: sound/soc/fsl/fsl_asrc.c:157:5: warning: symbol 'fsl_asrc_request_pair' was not declared. Should it be static? sound/soc/fsl/fsl_asrc.c:200:6: warning: symbol 'fsl_asrc_release_pair' was not declared. Should it be static? Reported-by: Hulk Robot Signed-off-by: ChenTao

Re: [PATCH v2] powerpc/ima: fix secure boot rules in ima arch policy

2020-05-06 Thread Mimi Zohar
On Fri, 2020-05-01 at 10:16 -0400, Nayna Jain wrote: > To prevent verifying the kernel module appended signature twice > (finit_module), once by the module_sig_check() and again by IMA, powerpc > secure boot rules define an IMA architecture specific policy rule > only if CONFIG_MODULE_SIG_FORCE is

Re: [PATCH v4 1/2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'

2020-05-06 Thread Segher Boessenkool
On Wed, May 06, 2020 at 08:10:57PM +0200, Christophe Leroy wrote: > Le 06/05/2020 à 19:58, Segher Boessenkool a écrit : > >> #define __put_user_asm_goto(x, addr, label, op) \ > >>asm volatile goto( \ > >>- "1: " op "%U1%X1

Re: [PATCH V2 08/11] arch/kmap: Ensure kmap_prot visibility

2020-05-06 Thread Ira Weiny
On Tue, May 05, 2020 at 11:13:26PM -0700, Christoph Hellwig wrote: > On Sun, May 03, 2020 at 06:09:09PM -0700, ira.we...@intel.com wrote: > > From: Ira Weiny > > > > We want to support kmap_atomic_prot() on all architectures and it makes > > sense to define kmap_atomic() to use the default

Re: [PATCH V2 05/11] {x86,powerpc,microblaze}/kmap: Move preempt disable

2020-05-06 Thread Ira Weiny
On Tue, May 05, 2020 at 11:11:13PM -0700, Christoph Hellwig wrote: > On Sun, May 03, 2020 at 06:09:06PM -0700, ira.we...@intel.com wrote: > > From: Ira Weiny > > > > During this kmap() conversion series we must maintain bisect-ability. > > To do this, kmap_atomic_prot() in x86, powerpc, and

Re: [PATCH net 11/16] net: ethernet: marvell: mvneta: fix fixed-link phydev leaks

2020-05-06 Thread Naresh Kamboju
On Tue, 29 Nov 2016 at 00:00, Johan Hovold wrote: > > Make sure to deregister and free any fixed-link PHY registered using > of_phy_register_fixed_link() on probe errors and on driver unbind. > > Fixes: 83895bedeee6 ("net: mvneta: add support for fixed links") > Signed-off-by: Johan Hovold > ---

Re: [PATCH v4 1/2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'

2020-05-06 Thread Christophe Leroy
Le 06/05/2020 à 19:58, Segher Boessenkool a écrit : On Wed, May 06, 2020 at 10:58:55AM +1000, Michael Ellerman wrote: The "m<>" here is breaking GCC 4.6.3, which we allegedly still support. [ You shouldn't use 4.6.3, there has been 4.6.4 since a while. And 4.6 is nine years old now.

Re: [PATCH v4 1/2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'

2020-05-06 Thread Segher Boessenkool
On Wed, May 06, 2020 at 11:36:00AM +1000, Michael Ellerman wrote: > >> As far as I understood that's mandatory on recent gcc to get the > >> pre-update form of the instruction. With older versions "m" was doing > >> the same, but not anymore. > > > > Yes. How much that matters depends on the

Re: [PATCH v4 1/2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'

2020-05-06 Thread Segher Boessenkool
On Wed, May 06, 2020 at 10:58:55AM +1000, Michael Ellerman wrote: > >> The "m<>" here is breaking GCC 4.6.3, which we allegedly still support. > > > > [ You shouldn't use 4.6.3, there has been 4.6.4 since a while. And 4.6 > > is nine years old now. Most projects do not support < 4.8 anymore,

[PATCH v2 45/45] powerpc/32s: Implement dedicated kasan_init_region()

2020-05-06 Thread Christophe Leroy
Implement a kasan_init_region() dedicated to book3s/32 that allocates KASAN regions using BATs. Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/kasan.h | 1 + arch/powerpc/mm/kasan/Makefile| 1 + arch/powerpc/mm/kasan/book3s_32.c | 57 +++

[PATCH v2 44/45] powerpc/32s: Allow mapping with BATs with DEBUG_PAGEALLOC

2020-05-06 Thread Christophe Leroy
DEBUG_PAGEALLOC only manages RW data. Text and RO data can still be mapped with BATs. In order to map with BATs, also enforce data alignment. Set by default to 256M which is a good compromise for keeping enough BATs for also KASAN and IMMR. Signed-off-by: Christophe Leroy ---

[PATCH v2 43/45] powerpc/8xx: Implement dedicated kasan_init_region()

2020-05-06 Thread Christophe Leroy
Implement a kasan_init_region() dedicated to 8xx that allocates KASAN regions using huge pages. Signed-off-by: Christophe Leroy --- arch/powerpc/mm/kasan/8xx.c| 74 ++ arch/powerpc/mm/kasan/Makefile | 1 + 2 files changed, 75 insertions(+) create mode

[PATCH v2 42/45] powerpc/8xx: Allow large TLBs with DEBUG_PAGEALLOC

2020-05-06 Thread Christophe Leroy
DEBUG_PAGEALLOC only manages RW data. Text and RO data can still be mapped with hugepages and pinned TLB. In order to map with hugepages, also enforce a 512kB data alignment minimum. That's a trade-off between size of speed, taking into account that DEBUG_PAGEALLOC is a debug option. Anyway the

[PATCH v2 41/45] powerpc/8xx: Allow STRICT_KERNEL_RwX with pinned TLB

2020-05-06 Thread Christophe Leroy
Pinned TLB are 8M. Now that there is no strict boundary anymore between text and RO data, it is possible to use 8M pinned executable TLB that covers both text and RO data. When PIN_TLB_DATA or PIN_TLB_TEXT is selected, enforce 8M RW data alignment and allow STRICT_KERNEL_RWX. Signed-off-by:

[PATCH v2 40/45] powerpc/8xx: Map linear memory with huge pages

2020-05-06 Thread Christophe Leroy
Map linear memory space with 512k and 8M pages whenever possible. Three mappings are performed: - One for kernel text - One for RO data - One for the rest Separating the mappings is done to be able to update the protection later when using STRICT_KERNEL_RWX. The ITLB miss handler now need to

[PATCH v2 39/45] powerpc/8xx: Map IMMR with a huge page

2020-05-06 Thread Christophe Leroy
Map the IMMR area with a single 512k huge page. Signed-off-by: Christophe Leroy --- arch/powerpc/mm/nohash/8xx.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/mm/nohash/8xx.c b/arch/powerpc/mm/nohash/8xx.c index 570ab2114a73..fb31a0c1c2a4 100644 ---

[PATCH v2 38/45] powerpc/8xx: Add a function to early map kernel via huge pages

2020-05-06 Thread Christophe Leroy
Add a function to early map kernel memory using huge pages. For 512k pages, just use standard page table and map in using 512k pages. For 8M pages, create a hugepd table and populate the two PGD entries with it. This function can only be used to create page tables at startup. Once the regular

[PATCH v2 37/45] powerpc/8xx: Refactor kernel address boundary comparison

2020-05-06 Thread Christophe Leroy
Now that linear and IMMR dedicated TLB handling is gone, kernel boundary address comparison is similar in ITLB miss handler and in DTLB miss handler. Create a macro named compare_to_kernel_boundary. When TASK_SIZE is strictly below 0x8000 and PAGE_OFFSET is above 0x8000, it is enough to

[PATCH v2 36/45] powerpc/mm: Don't be too strict with _etext alignment on PPC32

2020-05-06 Thread Christophe Leroy
Similar to PPC64, accept to map RO data as ROX as a trade off between between security and memory usage. Having RO data executable is not a high risk as RO data can't be modified to forge an exploit. Signed-off-by: Christophe Leroy --- arch/powerpc/Kconfig | 26

[PATCH v2 35/45] powerpc/8xx: Move DTLB perf handling closer.

2020-05-06 Thread Christophe Leroy
Now that space have been freed next to the DTLB miss handler, it's associated DTLB perf handling can be brought back in the same place. Signed-off-by: Christophe Leroy --- arch/powerpc/kernel/head_8xx.S | 23 +++ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git

[PATCH v2 34/45] powerpc/8xx: Remove now unused TLB miss functions

2020-05-06 Thread Christophe Leroy
The code to setup linear and IMMR mapping via huge TLB entries is not called anymore. Remove it. Also remove the handling of removed code exits in the perf driver. Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/nohash/32/mmu-8xx.h | 8 +- arch/powerpc/kernel/head_8xx.S

[PATCH v2 33/45] powerpc/8xx: Drop special handling of Linear and IMMR mappings in I/D TLB handlers

2020-05-06 Thread Christophe Leroy
Up to now, linear and IMMR mappings are managed via huge TLB entries through specific code directly in TLB miss handlers. This implies some patching of the TLB miss handlers at startup, and a lot of dedicated code. Remove all this specific dedicated code. For now we are back to normal handling

[PATCH v2 32/45] powerpc/8xx: Always pin TLBs at startup.

2020-05-06 Thread Christophe Leroy
At startup, map 32 Mbytes of memory through 4 pages of 8M, and PIN them inconditionnaly. They need to be pinned because KASAN is using page tables early and the TLBs might be dynamically replaced otherwise. Remove RSV4I flag after installing mappings unless CONFIG_PIN_TLB_ is selected.

[PATCH v2 31/45] powerpc/8xx: Don't set IMMR map anymore at boot

2020-05-06 Thread Christophe Leroy
Only early debug requires IMMR to be mapped early. No need to set it up and pin it in assembly. Map it through page tables at udbg init when necessary. If CONFIG_PIN_TLB_IMMR is selected, pin it once we don't need the 32 Mb pinned RAM anymore. Signed-off-by: Christophe Leroy --- v2: Disable

[PATCH v2 30/45] powerpc/8xx: Add function to set pinned TLBs

2020-05-06 Thread Christophe Leroy
Pinned TLBs cannot be modified when the MMU is enabled. Create a function to rewrite the pinned TLB entries with MMU off. To set pinned TLB, we have to turn off MMU, disable pinning, do a TLB flush (Either with tlbie and tlbia) then reprogam the TLB entries, enable pinning and turn on MMU. If

[PATCH v2 29/45] powerpc/8xx: Move PPC_PIN_TLB options into 8xx Kconfig

2020-05-06 Thread Christophe Leroy
PPC_PIN_TLB options are dedicated to the 8xx, move them into the 8xx Kconfig. While we are at it, add some text to explain what it does. Signed-off-by: Christophe Leroy --- arch/powerpc/Kconfig | 20 --- arch/powerpc/platforms/8xx/Kconfig | 41

[PATCH v2 28/45] powerpc/8xx: MM_SLICE is not needed anymore

2020-05-06 Thread Christophe Leroy
As the 8xx now manages 512k pages in standard page tables, it doesn't need CONFIG_PPC_MM_SLICES anymore. Don't select it anymore and remove all related code. Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/nohash/32/mmu-8xx.h | 64

[PATCH v2 27/45] powerpc/8xx: Only 8M pages are hugepte pages now

2020-05-06 Thread Christophe Leroy
512k pages are now standard pages, so only 8M pages are hugepte. No more handling of normal page tables through hugepd allocation and freeing, and hugepte helpers can also be simplified. Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/nohash/32/hugetlb-8xx.h | 7 +++

[PATCH v2 26/45] powerpc/8xx: Manage 512k huge pages as standard pages.

2020-05-06 Thread Christophe Leroy
At the time being, 512k huge pages are handled through hugepd page tables. The PMD entry is flagged as a hugepd pointer and it means that only 512k hugepages can be managed in that 4M block. However, the hugepd table has the same size as a normal page table, and 512k entries can therefore be

[PATCH v2 25/45] powerpc/8xx: Prepare handlers for _PAGE_HUGE for 512k pages.

2020-05-06 Thread Christophe Leroy
Prepare ITLB handler to handle _PAGE_HUGE when CONFIG_HUGETLBFS is enabled. This means that the L1 entry has to be kept in r11 until L2 entry is read, in order to insert _PAGE_HUGE into it. Also move pgd_offset helpers before pte_update() as they will be needed there in next patch.

[PATCH v2 24/45] powerpc/8xx: Drop CONFIG_8xx_COPYBACK option

2020-05-06 Thread Christophe Leroy
CONFIG_8xx_COPYBACK was there to help disabling copyback cache mode for debuging hardware. But nobody will design new boards with 8xx now. All 8xx platforms select it, so make it the default and remove the option. Also remove the Mx_RESETVAL values which are pretty useless and hide the real

[PATCH v2 23/45] powerpc/mm: Reduce hugepd size for 8M hugepages on 8xx

2020-05-06 Thread Christophe Leroy
Commit 55c8fc3f4930 ("powerpc/8xx: reintroduce 16K pages with HW assistance") redefined pte_t as a struct of 4 pte_basic_t, because in 16K pages mode there are four identical entries in the page table. But hugepd entries for 8M pages require only one entry of size pte_basic_t. So there is no point

[PATCH v2 22/45] powerpc/mm: Create a dedicated pte_update() for 8xx

2020-05-06 Thread Christophe Leroy
pte_update() is a bit special for the 8xx. At the time being, that's an #ifdef inside the nohash/32 pte_update(). As we are going to make it even more special in the coming patches, create a dedicated version for pte_update() for 8xx. Signed-off-by: Christophe Leroy ---

[PATCH v2 21/45] powerpc/mm: Standardise pte_update() prototype between PPC32 and PPC64

2020-05-06 Thread Christophe Leroy
PPC64 takes 3 additional parameters compared to PPC32: - mm - address - huge These 3 parameters will be needed in order to perform different action depending on the page size on the 8xx. Make pte_update() prototype identical for PPC32 and PPC64. This allows dropping an #ifdef in

[PATCH v2 20/45] powerpc/mm: Standardise __ptep_test_and_clear_young() params between PPC32 and PPC64

2020-05-06 Thread Christophe Leroy
On PPC32, __ptep_test_and_clear_young() takes the mm->context.id In preparation of standardising pte_update() params between PPC32 and PPC64, __ptep_test_and_clear_young() need mm instead of mm->context.id Replace context param by mm. Signed-off-by: Christophe Leroy ---

[PATCH v2 19/45] powerpc/mm: Refactor pte_update() on book3s/32

2020-05-06 Thread Christophe Leroy
When CONFIG_PTE_64BIT is set, pte_update() operates on 'unsigned long long' When CONFIG_PTE_64BIT is not set, pte_update() operates on 'unsigned long' In asm/page.h, we have pte_basic_t which is 'unsigned long long' when CONFIG_PTE_64BIT is set and 'unsigned long' otherwise. Refactor

[PATCH v2 18/45] powerpc/mm: Refactor pte_update() on nohash/32

2020-05-06 Thread Christophe Leroy
When CONFIG_PTE_64BIT is set, pte_update() operates on 'unsigned long long' When CONFIG_PTE_64BIT is not set, pte_update() operates on 'unsigned long' In asm/page.h, we have pte_basic_t which is 'unsigned long long' when CONFIG_PTE_64BIT is set and 'unsigned long' otherwise. Refactor

[PATCH v2 17/45] powerpc/mm: PTE_ATOMIC_UPDATES is only for 40x

2020-05-06 Thread Christophe Leroy
Only 40x still uses PTE_ATOMIC_UPDATES. 40x cannot not select CONFIG_PTE64_BIT. Drop handling of PTE_ATOMIC_UPDATES: - In nohash/64 - In nohash/32 for CONFIG_PTE_64BIT Keep PTE_ATOMIC_UPDATES only for nohash/32 for !CONFIG_PTE_64BIT Signed-off-by: Christophe Leroy ---

[PATCH v2 15/45] powerpc/mm: Allocate static page tables for fixmap

2020-05-06 Thread Christophe Leroy
Allocate static page tables for the fixmap area. This allows setting mappings through page tables before memblock is ready. That's needed to use early_ioremap() early and to use standard page mappings with fixmap. Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/fixmap.h | 4

[PATCH v2 16/45] powerpc/mm: Fix conditions to perform MMU specific management by blocks on PPC32.

2020-05-06 Thread Christophe Leroy
Setting init mem to NX shall depend on sinittext being mapped by block, not on stext being mapped by block. Setting text and rodata to RO shall depend on stext being mapped by block, not on sinittext being mapped by block. Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX")

[PATCH v2 14/45] powerpc/32s: Don't warn when mapping RO data ROX.

2020-05-06 Thread Christophe Leroy
Mapping RO data as ROX is not an issue since that data cannot be modified to introduce an exploit. PPC64 accepts to have RO data mapped ROX, as a trade off between kernel size and strictness of protection. On PPC32, kernel size is even more critical as amount of memory is usually small.

[PATCH v2 13/45] powerpc/ptdump: Handle hugepd at PGD level

2020-05-06 Thread Christophe Leroy
The 8xx is about to map kernel linear space and IMMR using huge pages. In order to display those pages properly, ptdump needs to handle hugepd tables at PGD level. For the time being do it only at PGD level. Further patches may add handling of hugepd tables at lower level for other platforms

[PATCH v2 11/45] powerpc/ptdump: Standardise display of BAT flags

2020-05-06 Thread Christophe Leroy
Display BAT flags the same way as page flags: rwx and wimg Signed-off-by: Christophe Leroy --- arch/powerpc/mm/ptdump/bats.c | 37 ++- 1 file changed, 15 insertions(+), 22 deletions(-) diff --git a/arch/powerpc/mm/ptdump/bats.c b/arch/powerpc/mm/ptdump/bats.c

[PATCH v2 12/45] powerpc/ptdump: Properly handle non standard page size

2020-05-06 Thread Christophe Leroy
In order to properly display information regardless of the page size, it is necessary to take into account real page size. Signed-off-by: Christophe Leroy Fixes: cabe8138b23c ("powerpc: dump as a single line areas mapping a single physical page.") Cc: sta...@vger.kernel.org ---

[PATCH v2 06/45] powerpc/kasan: Declare kasan_init_region() weak

2020-05-06 Thread Christophe Leroy
In order to alloc sub-arches to alloc KASAN regions using optimised methods (Huge pages on 8xx, BATs on BOOK3S, ...), declare kasan_init_region() weak. Also make kasan_init_shadow_page_tables() accessible from outside, so that it can be called from the specific kasan_init_region() functions if

[PATCH v2 10/45] powerpc/ptdump: Display size of BATs

2020-05-06 Thread Christophe Leroy
Display the size of areas mapped with BATs. For that, the size display for pages is refactorised. Signed-off-by: Christophe Leroy --- v2: Add missing include of linux/seq_file.h (Thanks to kbuild test robot) --- arch/powerpc/mm/ptdump/bats.c | 4 arch/powerpc/mm/ptdump/ptdump.c | 23

[PATCH v2 05/45] powerpc/kasan: Refactor update of early shadow mappings

2020-05-06 Thread Christophe Leroy
kasan_remap_early_shadow_ro() and kasan_unmap_early_shadow_vmalloc() are both updating the early shadow mapping: the first one sets the mapping read-only while the other clears the mapping. Refactor and create kasan_update_early_region() Signed-off-by: Christophe Leroy ---

[PATCH v2 09/45] powerpc/ptdump: Add _PAGE_COHERENT flag

2020-05-06 Thread Christophe Leroy
For platforms using shared.c (4xx, Book3e, Book3s/32), also handle the _PAGE_COHERENT flag with corresponds to the M bit of the WIMG flags. Signed-off-by: Christophe Leroy --- arch/powerpc/mm/ptdump/shared.c | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH v2 08/45] powerpc/ptdump: Reorder flags

2020-05-06 Thread Christophe Leroy
Reorder flags in a more logical way: - Page size (huge) first - User - RWX - Present - WIMG - Special - Dirty and Accessed Signed-off-by: Christophe Leroy --- arch/powerpc/mm/ptdump/8xx.c| 30 +++--- arch/powerpc/mm/ptdump/shared.c | 30 +++---

[PATCH v2 07/45] powerpc/ptdump: Limit size of flags text to 1/2 chars on PPC32

2020-05-06 Thread Christophe Leroy
In order to have all flags fit on a 80 chars wide screen, reduce the flags to 1 char (2 where ambiguous). No cache is 'i' User is 'ur' (Supervisor would be sr) Shared (for 8xx) becomes 'sh' (it was 'user' when not shared but that was ambiguous because that's not entirely right) Signed-off-by:

[PATCH v2 03/45] powerpc/kasan: Fix shadow pages allocation failure

2020-05-06 Thread Christophe Leroy
Doing kasan pages allocation in MMU_init is too early, kernel doesn't have access yet to the entire memory space and memblock_alloc() fails when the kernel is a bit big. Do it from kasan_init() instead. Fixes: 2edb16efc899 ("powerpc/32: Add KASAN support") Cc: sta...@vger.kernel.org

[PATCH v2 04/45] powerpc/kasan: Remove unnecessary page table locking

2020-05-06 Thread Christophe Leroy
Commit 45ff3c559585 ("powerpc/kasan: Fix parallel loading of modules.") added spinlocks to manage parallele module loading. Since then commit 47febbeeec44 ("powerpc/32: Force KASAN_VMALLOC for modules") converted the module loading to KASAN_VMALLOC. The spinlocking has then become unneeded and

[PATCH v2 01/45] powerpc/kasan: Fix error detection on memory allocation

2020-05-06 Thread Christophe Leroy
In case (k_start & PAGE_MASK) doesn't equal (kstart), 'va' will never be NULL allthough 'block' is NULL Check the return of memblock_alloc() directly instead of the resulting address in the loop. Fixes: 509cd3f2b473 ("powerpc/32: Simplify KASAN init") Signed-off-by: Christophe Leroy ---

[PATCH v2 00/45] Use hugepages to map kernel mem on 8xx

2020-05-06 Thread Christophe Leroy
The main purpose of this big series is to: - reorganise huge page handling to avoid using mm_slices. - use huge pages to map kernel memory on the 8xx. The 8xx supports 4 page sizes: 4k, 16k, 512k and 8M. It uses 2 Level page tables, PGD having 1024 entries, each entry covering 4M address space.

[PATCH v2 02/45] powerpc/kasan: Fix issues by lowering KASAN_SHADOW_END

2020-05-06 Thread Christophe Leroy
At the time being, KASAN_SHADOW_END is 0x1, which is 0 in 32 bits representation. This leads to a couple of issues: - kasan_remap_early_shadow_ro() does nothing because the comparison k_cur < k_end is always false. - In ptdump, address comparison for markers display fails and the marker's

Re: remove set_fs calls from the coredump code v6

2020-05-06 Thread Eric W. Biederman
Christoph Hellwig writes: > On Tue, May 05, 2020 at 03:28:50PM -0500, Eric W. Biederman wrote: >> We probably can. After introducing a kernel_compat_siginfo that is >> the size that userspace actually would need. >> >> It isn't something I want to mess with until this code gets merged, as I

[PATCH 21/91] perf vendor events power9: Add hv_24x7 socket/chip level metric events

2020-05-06 Thread Arnaldo Carvalho de Melo
From: Kajol Jain The hv_24×7 feature in IBM® POWER9™ processor-based servers provide the facility to continuously collect large numbers of hardware performance metrics efficiently and accurately. This patch adds hv_24x7 metric file for different Socket/chip resources. Result: power9

[PATCH 20/91] perf tools: Enable Hz/hz prinitg for --metric-only option

2020-05-06 Thread Arnaldo Carvalho de Melo
From: Kajol Jain Commit 54b5091606c18 ("perf stat: Implement --metric-only mode") added function 'valid_only_metric()' which drops "Hz" or "hz", if it is part of "ScaleUnit". This patch enable it since hv_24x7 supports couple of frequency events. Signed-off-by: Kajol Jain Acked-by: Jiri Olsa

[PATCH 19/91] perf tests expr: Added test for runtime param in metric expression

2020-05-06 Thread Arnaldo Carvalho de Melo
From: Kajol Jain Added test case for parsing "?" in metric expression. Signed-off-by: Kajol Jain Acked-by: Jiri Olsa Cc: Alexander Shishkin Cc: Andi Kleen Cc: Anju T Sudhakar Cc: Benjamin Herrenschmidt Cc: Greg Kroah-Hartman Cc: Jin Yao Cc: Joe Mario Cc: Kan Liang Cc: Madhavan

[PATCH 18/91] perf metricgroups: Enhance JSON/metric infrastructure to handle "?"

2020-05-06 Thread Arnaldo Carvalho de Melo
From: Kajol Jain Patch enhances current metric infrastructure to handle "?" in the metric expression. The "?" can be use for parameters whose value not known while creating metric events and which can be replace later at runtime to the proper value. It also add flexibility to create multiple

Re: [PATCH v4 1/2] powerpc/eeh: fix pseries_eeh_configure_bridge()

2020-05-06 Thread Nathan Lynch
Sam Bobroff writes: > If a device is hot unplgged during EEH recovery, it's possible for the > RTAS call to ibm,configure-pe in pseries_eeh_configure() to return > parameter error (-3), however negative return values are not checked > for and this leads to an infinite loop. > > Fix this by

[PATCH v8 0/5] powerpc/hv-24x7: Expose chip/sockets info to add json file metric support for the hv_24x7 socket/chip level events

2020-05-06 Thread Kajol Jain
Patchset fixes the inconsistent results we are getting when we run multiple 24x7 events. "hv_24x7" pmu interface events needs system dependent parameter like socket/chip/core. For example, hv_24x7 chip level events needs specific chip-id to which the data is requested should be added as part of

[PATCH v8 5/5] powerpc/hv-24x7: Update post_mobility_fixup() to handle migration

2020-05-06 Thread Kajol Jain
Function 'read_sys_info_pseries()' is added to get system parameter values like number of sockets and chips per socket. and it gets these details via rtas_call with token "PROCESSOR_MODULE_INFO". Incase lpar migrate from one system to another, system parameter details like chips per sockets or

[PATCH v8 4/5] Documentation/ABI: Add ABI documentation for chips and sockets

2020-05-06 Thread Kajol Jain
Add documentation for the following sysfs files: /sys/devices/hv_24x7/interface/chipspersocket, /sys/devices/hv_24x7/interface/sockets, /sys/devices/hv_24x7/interface/coresperchip Signed-off-by: Kajol Jain --- .../sysfs-bus-event_source-devices-hv_24x7| 21 +++ 1 file

[PATCH v8 3/5] powerpc/hv-24x7: Add sysfs files inside hv-24x7 device to show processor details

2020-05-06 Thread Kajol Jain
To expose the system dependent parameter like total number of sockets and numbers of chips per socket, patch adds two sysfs files. "sockets" and "chips" are added to /sys/devices/hv_24x7/interface/ of the "hv_24x7" pmu. Signed-off-by: Kajol Jain --- arch/powerpc/perf/hv-24x7.c | 24

[PATCH v8 2/5] powerpc/hv-24x7: Add rtas call in hv-24x7 driver to get processor details

2020-05-06 Thread Kajol Jain
For hv_24x7 socket/chip level events, specific chip-id to which the data requested should be added as part of pmu events. But number of chips/socket in the system details are not exposed. Patch implements read_sys_info_pseries() to get system parameter values like number of sockets and chips per

[PATCH v8 1/5] powerpc/perf/hv-24x7: Fix inconsistent output values incase multiple hv-24x7 events run

2020-05-06 Thread Kajol Jain
Commit 2b206ee6b0df ("powerpc/perf/hv-24x7: Display change in counter values")' added to print _change_ in the counter value rather then raw value for 24x7 counters. Incase of transactions, the event count is set to 0 at the beginning of the transaction. It also sets the event's prev_count to the

Re: [PATCH v7 2/5] powerpc/hv-24x7: Add rtas call in hv-24x7 driver to get processor details

2020-05-06 Thread kajoljain
On 4/29/20 5:01 PM, Michael Ellerman wrote: > Hi Kajol, > > Some comments inline ... > > Kajol Jain writes: >> For hv_24x7 socket/chip level events, specific chip-id to which >> the data requested should be added as part of pmu events. >> But number of chips/socket in the system details are

Re: [PATCH] tty: hvc: Fix data abort due to race in hvc_open

2020-05-06 Thread Greg KH
On Mon, Apr 27, 2020 at 08:26:01PM -0700, Raghavendra Rao Ananta wrote: > Potentially, hvc_open() can be called in parallel when two tasks calls > open() on /dev/hvcX. In such a scenario, if the hp->ops->notifier_add() > callback in the function fails, where it sets the tty->driver_data to > NULL,

Re: [PATCH 2/2] powerpc/perf: Add support for outputting extended regs in perf intr_regs

2020-05-06 Thread Athira Rajeev
> On 06-May-2020, at 9:56 AM, Madhavan Srinivasan wrote: > > > > On 4/29/20 11:34 AM, Anju T Sudhakar wrote: >> The capability flag PERF_PMU_CAP_EXTENDED_REGS, is used to indicate the >> PMU which support extended registers. The generic code define the mask >> of extended registers as 0 for

Re: [PATCH] powerpc/xive: Enforce load-after-store ordering when StoreEOI is active

2020-05-06 Thread Cédric Le Goater
On 5/6/20 1:34 AM, Alistair Popple wrote: > I am still slowly wrapping my head around XIVE and it's interaction with KVM > but from what I can see this looks good and is needed so we can enable > StoreEOI support in future so: > > Reviewed-by: Alistair Popple > > On Thursday, 20 February 2020

Re: [RFC PATCH 06/10] powerpc/powernv: opal use new opal call entry point if it exists

2020-05-06 Thread Gautham R Shenoy
Hello Nicholas, On Sat, May 02, 2020 at 09:19:10PM +1000, Nicholas Piggin wrote: > OPAL may advertise new endian-specific entry point which has different > calling conventions including using the caller's stack, but otherwise > provides the standard OPAL call API without any changes required to >

[PATCH] powerpc/8xx: Update email address in MAINTAINERS

2020-05-06 Thread Christophe Leroy
Since 01 May 2020, our email adresses have changed to @csgroup.eu Update MAINTAINERS accordingly. Signed-off-by: Christophe Leroy --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 2926327e4976..e8714328cc90 100644 ---

Re: remove set_fs calls from the coredump code v6

2020-05-06 Thread Christoph Hellwig
On Tue, May 05, 2020 at 03:28:50PM -0500, Eric W. Biederman wrote: > We probably can. After introducing a kernel_compat_siginfo that is > the size that userspace actually would need. > > It isn't something I want to mess with until this code gets merged, as I > think the set_fs cleanups are

Re: [PATCH] powerpc/5200: update contact email

2020-05-06 Thread Michael Ellerman
Wolfram Sang writes: >> > My 'pengutronix' address is defunct for years. Merge the entries and use >> > the proper contact address. >> >> Is there any point adding the new address? It's just likely to bit-rot >> one day too. > > At least, this one is a group address, not an individual one, so

Re: [PATCH V2 10/11] arch/kmap: Define kmap_atomic_prot() for all arch's

2020-05-06 Thread Christoph Hellwig
On Sun, May 03, 2020 at 06:09:11PM -0700, ira.we...@intel.com wrote: > From: Ira Weiny > > To support kmap_atomic_prot(), all architectures need to support > protections passed to their kmap_atomic_high() function. Pass > protections into kmap_atomic_high() and change the name to >

Re: [PATCH V2 08/11] arch/kmap: Ensure kmap_prot visibility

2020-05-06 Thread Christoph Hellwig
On Sun, May 03, 2020 at 06:09:09PM -0700, ira.we...@intel.com wrote: > From: Ira Weiny > > We want to support kmap_atomic_prot() on all architectures and it makes > sense to define kmap_atomic() to use the default kmap_prot. > > So we ensure all arch's have a globally available kmap_prot either

[PATCH V2 3/3] mm/hugetlb: Define a generic fallback for arch_clear_hugepage_flags()

2020-05-06 Thread Anshuman Khandual
There are multiple similar definitions for arch_clear_hugepage_flags() on various platforms. Lets just add it's generic fallback definition for platforms that do not override. This help reduce code duplication. Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Tony Luck Cc: Fenghua Yu

[PATCH V2 2/3] mm/hugetlb: Define a generic fallback for is_hugepage_only_range()

2020-05-06 Thread Anshuman Khandual
There are multiple similar definitions for is_hugepage_only_range() on various platforms. Lets just add it's generic fallback definition for platforms that do not override. This help reduce code duplication. Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Tony Luck Cc: Fenghua Yu

[PATCH V2 0/3] mm/hugetlb: Add some new generic fallbacks

2020-05-06 Thread Anshuman Khandual
This series adds the following new generic fallbacks. Before that it drops __HAVE_ARCH_HUGE_PTEP_GET from arm64 platform. 1. is_hugepage_only_range() 2. arch_clear_hugepage_flags() This has been boot tested on arm64 and x86 platforms but built tested on some more platforms including the changed

Re: [PATCH V2 07/11] arch/kunmap_atomic: Consolidate duplicate code

2020-05-06 Thread Christoph Hellwig
On Sun, May 03, 2020 at 06:09:08PM -0700, ira.we...@intel.com wrote: > From: Ira Weiny > > Every single architecture (including !CONFIG_HIGHMEM) calls... > > pagefault_enable(); > preempt_enable(); > > ... before returning from __kunmap_atomic(). Lift this code into the >

Re: [PATCH V2 06/11] arch/kmap_atomic: Consolidate duplicate code

2020-05-06 Thread Christoph Hellwig
Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH V2 05/11] {x86,powerpc,microblaze}/kmap: Move preempt disable

2020-05-06 Thread Christoph Hellwig
On Sun, May 03, 2020 at 06:09:06PM -0700, ira.we...@intel.com wrote: > From: Ira Weiny > > During this kmap() conversion series we must maintain bisect-ability. > To do this, kmap_atomic_prot() in x86, powerpc, and microblaze need to > remain functional. > > Create a temporary inline version of

[PATCH -next] powerpc/kernel/sysfs: Use ARRAY_SIZE instead of calculating the array size

2020-05-06 Thread Samuel Zou
fix coccinelle warning, use ARRAY_SIZE arch/powerpc/kernel/sysfs.c:853:34-35: WARNING: Use ARRAY_SIZE arch/powerpc/kernel/sysfs.c:860:33-34: WARNING: Use ARRAY_SIZE arch/powerpc/kernel/sysfs.c:868:28-29: WARNING: Use ARRAY_SIZE arch/powerpc/kernel/sysfs.c:947:34-35: WARNING: Use ARRAY_SIZE