Re: ##freemail## Re: [PATCH v2] mm: hwpoison: disable memory error handling on 1GB hugepage

On Tue, Aug 20, 2019 at 03:03:55PM +0800, Wanpeng Li wrote: > Cc Mel Gorman, Kirill, Dave Hansen, > On Tue, 11 Jun 2019 at 07:51, Naoya Horiguchi > wrote: > > > > On Wed, May 29, 2019 at 04:31:01PM -0700, Mike Kravetz wrote: > > > On 5/28/19 2:49 AM, Wanpeng Li wrote: > > > > Cc Paolo, > > > >

Re: [PATCH] platform/powernv: Avoid re-registration of imc debugfs directory

Hi, On 8/21/19 10:16 AM, Oliver O'Halloran wrote: On Wed, Aug 21, 2019 at 2:10 PM Anju T Sudhakar wrote: export_imc_mode_and_cmd() function which creates the debugfs interface for imc-mode and imc-command, is invoked when each nest pmu units is registered. When the first nest pmu unit is

Re: [PATCH] platform/powernv: Avoid re-registration of imc debugfs directory

On Wed, Aug 21, 2019 at 2:10 PM Anju T Sudhakar wrote: > > export_imc_mode_and_cmd() function which creates the debugfs interface for > imc-mode and imc-command, is invoked when each nest pmu units is > registered. > When the first nest pmu unit is registered, export_imc_mode_and_cmd() > creates

Re: [PATCH] powerpc/vdso32: inline __get_datapage()

On Fri, 2019-08-16 at 14:48 +, Christophe Leroy wrote: > __get_datapage() is only a few instructions to retrieve the > address of the page where the kernel stores data to the VDSO. > > By inlining this function into its users, a bl/blr pair and > a mflr/mtlr pair is avoided, plus a few reg

[PATCH] platform/powernv: Avoid re-registration of imc debugfs directory

export_imc_mode_and_cmd() function which creates the debugfs interface for imc-mode and imc-command, is invoked when each nest pmu units is registered. When the first nest pmu unit is registered, export_imc_mode_and_cmd() creates 'imc' directory under `/debug/powerpc`. In the subsequent

Re: [PATCH v5 05/12] powerpc/eeh: EEH for pSeries hot plug

Sam Bobroff writes: > diff --git a/arch/powerpc/kernel/of_platform.c > b/arch/powerpc/kernel/of_platform.c > index 427fc22f72b6..11c807468ab5 100644 > --- a/arch/powerpc/kernel/of_platform.c > +++ b/arch/powerpc/kernel/of_platform.c > @@ -81,7 +81,8 @@ static int of_pci_phb_probe(struct

RE: [PATCH v6 3/3] soc: fsl: add RCPM driver

Hi Pavel, On Wednesday, August 21, 2019 11:16, Ran Wang wrote: > > The NXP's QorIQ Processors based on ARM Core have RCPM module (Run > Control and Power Management), which performs system level tasks associated > with power management such as wakeup source control. > > This driver depends on

[PATCH v6 3/3] soc: fsl: add RCPM driver

The NXP's QorIQ Processors based on ARM Core have RCPM module (Run Control and Power Management), which performs system level tasks associated with power management such as wakeup source control. This driver depends on PM wakeup source framework which help to collect wake information.

[PATCH v6 2/3] Documentation: dt: binding: fsl: Add 'little-endian' and update Chassis define

By default, QorIQ SoC's RCPM register block is Big Endian. But there are some exceptions, such as LS1088A and LS2088A, are Little Endian. So add this optional property to help identify them. Actually LS2021A and other Layerscapes won't totally follow Chassis 2.1, so separate them from powerpc

[PATCH v6 1/3] PM: wakeup: Add routine to help fetch wakeup source object.

Some user might want to go through all registered wakeup sources and doing things accordingly. For example, SoC PM driver might need to do HW programming to prevent powering down specific IP which wakeup source depending on. So add this API to help walk through all registered wakeup source objects

Re: [PATCH] btrfs: fix allocation of bitmap pages.

On Tue, Aug 20, 2019 at 01:06:25PM +0200, Vlastimil Babka wrote: > > The whole point of copy_page is to copy exactly one page and it makes > > sense to assume that is aligned. A sane memcpy would use the same > > underlying primitives as well after checking they fit. So I think the > > prime

Re: [PATCH v4 4/7] kexec_elf: remove PURGATORY_STACK_SIZE

Thiago Jung Bauermann writes: > Sven Schnelle writes: > >> It's not used anywhere so just drop it. >> >> Signed-off-by: Sven Schnelle >> --- >> kernel/kexec_elf.c | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/kernel/kexec_elf.c b/kernel/kexec_elf.c >> index

Re: [PATCH v4 0/7] kexec: add generic support for elf kernel images

Sven Schnelle writes: > Changes to v3: > - add support for 32-bit ELF files > > Changes to v2: > - use git format-patch -C > > Changes to v1: > - split up patch into smaller pieces > - rebase onto powerpc/next > - remove unused variable in kexec_elf_load() > > Changes to RFC version: > -

Re: [PATCH v4 1/7] kexec: add KEXEC_ELF

Hello Sven, Just a few small comments below. Regardless of them: Reviewed-by: Thiago Jung Bauermann Sven Schnelle writes: > Right now powerpc provides an implementation to read elf files > with the kexec_file() syscall. Make that available as a public Nit: the syscall is kexec_file_load()

Re: [PATCH v4 7/7] kexec_elf: support 32 bit ELF files

Sven Schnelle writes: > The powerpc version only supported 64 bit. Add some > code to switch decoding of fields during runtime so > we can kexec a 32 bit kernel from a 64 bit kernel and > vice versa. > > Signed-off-by: Sven Schnelle Reviewed-by: Thiago Jung Bauermann -- Thiago Jung

Re: [PATCH v4 6/7] kexec_elf: remove unused variable in kexec_elf_load()

Sven Schnelle writes: > base was never assigned, so we can remove it. > > Reviewed-by: Christophe Leroy > Signed-off-by: Sven Schnelle > --- > kernel/kexec_elf.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/kernel/kexec_elf.c b/kernel/kexec_elf.c > index

Re: [PATCH v4 5/7] kexec_elf: remove Elf_Rel macro

Sven Schnelle writes: > It wasn't used anywhere, so lets drop it. > > Reviewed-by: Christophe Leroy > Signed-off-by: Sven Schnelle > --- > kernel/kexec_elf.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/kernel/kexec_elf.c b/kernel/kexec_elf.c > index

Re: [PATCH v4 4/7] kexec_elf: remove PURGATORY_STACK_SIZE

Sven Schnelle writes: > It's not used anywhere so just drop it. > > Signed-off-by: Sven Schnelle > --- > kernel/kexec_elf.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/kernel/kexec_elf.c b/kernel/kexec_elf.c > index effe9dc0b055..70d31b8feeae 100644 > --- a/kernel/kexec_elf.c >

Re: [PATCH v4 3/7] kexec_elf: remove parsing of section headers

Sven Schnelle writes: > We're not using them, so we can drop the parsing. > > Signed-off-by: Sven Schnelle Reviewed-by: Thiago Jung Bauermann -- Thiago Jung Bauermann IBM Linux Technology Center

Re: [PATCH v4 2/7] kexec_elf: change order of elf_*_to_cpu() functions

Sven Schnelle writes: > Change the order to have a 64/32/16 order, no functional change. > > Signed-off-by: Sven Schnelle Reviewed-by: Thiago Jung Bauermann -- Thiago Jung Bauermann IBM Linux Technology Center

Re: [PATCH v2 05/12] powerpc/mm: rework io-workaround invocation.

On Wed, 2019-08-21 at 00:28 +0200, Christoph Hellwig wrote: > On Tue, Aug 20, 2019 at 02:07:13PM +, Christophe Leroy wrote: > > ppc_md.ioremap() is only used for I/O workaround on CELL platform, > > so indirect function call can be avoided. > > > > This patch reworks the io-workaround and

[PATCH v2] powerpc: Allow flush_(inval_)dcache_range to work across ranges >4GB

From: Alastair D'Silva The upstream commit: 22e9c88d486a ("powerpc/64: reuse PPC32 static inline flush_dcache_range()") has a similar effect, but since it is a rewrite of the assembler to C, is too invasive for stable. This patch is a minimal fix to address the issue in assembler. This patch

Re: [PATCH v5 4/7] powerpc/mm: Use UV_WRITE_PATE ucall to register a PATE

Michael Ellerman [m...@ellerman.id.au] wrote: > Hi Claudio, > > Claudio Carvalho writes: > > From: Michael Anderson > > > > In ultravisor enabled systems, the ultravisor creates and maintains the > > partition table in secure memory where the hypervisor cannot access, and >

[PATCH v2] powerpc: Don't add -mabi= flags when building with Clang

When building pseries_defconfig, building vdso32 errors out: error: unknown target ABI 'elfv1' This happens because -m32 in clang changes the target to 32-bit, which does not allow the ABI to be changed, as the setABI virtual function is not overridden:

[PATCH] selftests/powerpc: Retry on host facility unavailable

TM test tm-unavailable must take into account aborts due to host aborting a transactin because of a facility unavailable exception, just like it already does for aborts on reschedules (TM_CAUSE_KVM_RESCHED). Reported-by: Desnes A. Nunes do Rosario Tested-by: Desnes A. Nunes do Rosario

Re: [PATCH v2 07/12] powerpc/mm: move ioremap_prot() into ioremap.c

On Tue, Aug 20, 2019 at 02:07:15PM +, Christophe Leroy wrote: > Both ioremap_prot() are idenfical, move them into ioremap.c s/idenfical/identical/

Re: [PATCH v2 05/12] powerpc/mm: rework io-workaround invocation.

On Tue, Aug 20, 2019 at 02:07:13PM +, Christophe Leroy wrote: > ppc_md.ioremap() is only used for I/O workaround on CELL platform, > so indirect function call can be avoided. > > This patch reworks the io-workaround and ioremap() functions to > use the global 'io_workaround_inited' flag for

Re: [PATCH v2 04/12] powerpc/mm: drop function __ioremap()

On Tue, Aug 20, 2019 at 02:07:12PM +, Christophe Leroy wrote: > __ioremap() is not used anymore, drop it. > > Suggested-by: Christoph Hellwig > Signed-off-by: Christophe Leroy Looks good, I've already dropped my version of this from the generic ioremap series: Reviewed-by: Christoph

Re: [PATCH v2 02/12] powerpc/ps3: replace __ioremap() by ioremap_prot()

On Tue, Aug 20, 2019 at 02:07:10PM +, Christophe Leroy wrote: > __ioremap() is similar to ioremap_prot() except that ioremap_prot() > does a few sanity changes in addition. > > The flags used by PS3 are not impacted by those changes so for > PS3 both functions are equivalent. > > At the same

[PATCH 1/2] net/ibmvnic: unlock rtnl_lock in reset so linkwatch_event can run

Commit a5681e20b541 ("net/ibmnvic: Fix deadlock problem in reset") made the change to hold the RTNL lock during a reset to avoid deadlock but linkwatch_event is fired during the reset and needs the RTNL lock. That keeps linkwatch_event process from proceeding until the reset is complete. The

[PATCH 2/2] net/ibmvnic: prevent more than one thread from running in reset

The current code allows more than one thread to run in reset. This can corrupt struct adapter data. Check adapter->resetting before performing a reset, if there is another reset running delay (100 msec) before trying again. Signed-off-by: Juliet Kim --- drivers/net/ethernet/ibm/ibmvnic.c |

[PATCH rebased] powerpc/fadump: when fadump is supported register the fadump sysfs files.

Currently it is not possible to distinguish the case when fadump is supported by firmware and disabled in kernel and completely unsupported using the kernel sysfs interface. User can investigate the devicetree but it is more reasonable to provide sysfs files in case we get some fadumpv2 in the

Re: [PATCH] powerpc: Don't add -mabi= flags when building with Clang

On Tue, Aug 20, 2019 at 07:40:33AM -0500, Segher Boessenkool wrote: > On Mon, Aug 19, 2019 at 08:15:38PM -0700, Nathan Chancellor wrote: > > On Mon, Aug 19, 2019 at 04:19:31AM -0500, Segher Boessenkool wrote: > > > On Sun, Aug 18, 2019 at 12:13:21PM -0700, Nathan Chancellor wrote: > > > > When

Re: [PATCH v2 2/2] powerpc: support KASAN instrumentation of bitops

Le 20/08/2019 à 04:49, Daniel Axtens a écrit : The powerpc-specific bitops are not being picked up by the KASAN test suite. Instrumentation is done via the bitops/instrumented-{atomic,lock}.h headers. They require that arch-specific versions of bitop functions are renamed to arch_*. Do this

Re: [PATCH] powerpc: Allow flush_(inval_)dcache_range to work across ranges >4GB

On Fri, Aug 16, 2019 at 09:14:12AM +0200, Greg Kroah-Hartman wrote: > On Fri, Aug 16, 2019 at 11:42:22AM +1000, Michael Ellerman wrote: > > Greg Kroah-Hartman writes: > > > On Thu, Aug 15, 2019 at 02:55:42PM +1000, Alastair D'Silva wrote: > > >> From: Alastair D'Silva > > >> > > >> Heads Up:

[PATCH] powerpc/fadump: when fadump is supported register the fadump sysfs files.

Currently it is not possible to distinguish the case when fadump is supported by firmware and disabled in kernel and completely unsupported using the kernel sysfs interface. User can investigate the devicetree but it is more reasonable to provide sysfs files in case we get some fadumpv2 in the

[PATCH v2 09/11] dma-direct: turn ARCH_ZONE_DMA_BITS into a variable

Some architectures, notably arm64, are interested in tweaking this depending on their runtime dma addressing limitations. Signed-off-by: Nicolas Saenz Julienne --- Changes in v2: - Rename new variable to zone_dma_bits - Update comment with Christoph's suggestion - Remove old powerpc comment

[PATCH v2 00/11] Raspberry Pi 4 DMA addressing support

Hi all, this series attempts to address some issues we found while bringing up the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow up of these discussions: v1: https://lkml.org/lkml/2019/7/31/922 RFC: https://lkml.org/lkml/2019/7/17/476 The new Raspberry Pi 4 has up to 4GB of

[PATCH v4 3/3] powerpc/64: optimise LOAD_REG_IMMEDIATE_SYM()

Optimise LOAD_REG_IMMEDIATE_SYM() using a temporary register to parallelise operations. It reduces the path from 5 to 3 instructions. Suggested-by: Segher Boessenkool Signed-off-by: Christophe Leroy --- v3: new v4: fixed the registers of lis/ori to match rldimi args (tmp is upper part, reg

[PATCH v4 2/3] powerpc/32: replace LOAD_MSR_KERNEL() by LOAD_REG_IMMEDIATE()

LOAD_MSR_KERNEL() and LOAD_REG_IMMEDIATE() are doing the same thing in the same way. Drop LOAD_MSR_KERNEL() Signed-off-by: Christophe Leroy --- v2: no change v3: no change v4: no change --- arch/powerpc/kernel/entry_32.S | 18 +- arch/powerpc/kernel/head_32.h | 21

[PATCH v4 1/3] powerpc: rewrite LOAD_REG_IMMEDIATE() as an intelligent macro

Today LOAD_REG_IMMEDIATE() is a basic #define which loads all parts on a value into a register, including the parts that are NUL. This means always 2 instructions on PPC32 and always 5 instructions on PPC64. And those instructions cannot run in parallele as they are updating the same register.

[PATCH v2 12/12] powerpc/mm: split out early ioremap path.

ioremap does things differently depending on whether SLAB is available or not at different levels. Try to separate the early path from the beginning. Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/io.h | 3 ++- arch/powerpc/mm/ioremap.c | 17 +++--

[PATCH v2 11/12] powerpc/mm: refactor ioremap vm area setup.

PPC32 and PPC64 are doing the same once SLAB is available. Create a do_ioremap() function that calls get_vm_area and do the mapping. For PPC64, we add the 4K PFN hack sanity check to __ioremap_caller() in order to avoid using __ioremap_at(). Other checks in __ioremap_at() are irrelevant for

[PATCH v2 10/12] powerpc/mm: refactor ioremap_range() and use ioremap_page_range()

book3s64's ioremap_range() is almost same as fallback ioremap_range(), except that it calls radix__ioremap_range() when radix is enabled. radix__ioremap_range() is also very similar to the other ones, expect that it calls ioremap_page_range when slab is available. PPC32 __ioremap_caller() have a

[PATCH v2 09/12] powerpc/mm: Move ioremap functions out of pgtable_32/64.c

Create ioremap_32.c and ioremap_64.c and move respective ioremap functions out of pgtable_32.c and pgtable_64.c In the meantime, fix a few comments and changes a printk() to pr_warn(). Also fix a few oversplitted lines. Signed-off-by: Christophe Leroy --- arch/powerpc/mm/Makefile | 2 +-

[PATCH v2 05/12] powerpc/mm: rework io-workaround invocation.

ppc_md.ioremap() is only used for I/O workaround on CELL platform, so indirect function call can be avoided. This patch reworks the io-workaround and ioremap() functions to use the global 'io_workaround_inited' flag for the activation of io-workaround. When CONFIG_PPC_IO_WORKAROUNDS or

[PATCH v2 08/12] powerpc/mm: make ioremap_bot common to all

Drop multiple definitions of ioremap_bot and make one common to all subarches. Only CONFIG_PPC_BOOK3E_64 had a global static init value for ioremap_bot. Now ioremap_bot is set in early_init_mmu_global(). Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/book3s/32/pgtable.h | 2 --

[PATCH v2 06/12] powerpc/mm: move common 32/64 bits ioremap functions into ioremap.c

ioremap(), ioremap_wc() and ioremap_coherent() are now identical on PPC32 and PPC64 as iowa_is_active() will always return false on PPC32. Move them into a new common location called ioremap.c Signed-off-by: Christophe Leroy --- arch/powerpc/mm/Makefile | 2 +- arch/powerpc/mm/ioremap.c

[PATCH v2 07/12] powerpc/mm: move ioremap_prot() into ioremap.c

Both ioremap_prot() are idenfical, move them into ioremap.c Signed-off-by: Christophe Leroy --- arch/powerpc/mm/ioremap.c| 19 +++ arch/powerpc/mm/pgtable_32.c | 17 - arch/powerpc/mm/pgtable_64.c | 24 3 files changed, 19

[PATCH v2 04/12] powerpc/mm: drop function __ioremap()

__ioremap() is not used anymore, drop it. Suggested-by: Christoph Hellwig Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/io.h | 6 -- arch/powerpc/mm/pgtable_32.c | 11 ++- arch/powerpc/mm/pgtable_64.c | 7 --- 3 files changed, 2 insertions(+), 22 deletions(-)

[PATCH v2 00/12] powerpc/mm: cleanup and refactoring in ioremap

The purpose of this series is to cleanup and refactor ioremap. At the time being, ioremap is duplicated in PPC32 and PPC64. In addition, some additional duplication also appear within PPC64. First part of this series drops as much as unused functions. Then io-workaround is reworked to avoid

[PATCH v2 01/12] powerpc: remove the ppc44x ocm.c file

From: Christoph Hellwig The on chip memory allocator is entirely unused in the kernel tree. Signed-off-by: Christoph Hellwig Acked-by: Christophe Leroy Signed-off-by: Christophe Leroy --- arch/powerpc/configs/ppc40x_defconfig | 1 - arch/powerpc/include/asm/ppc4xx_ocm.h | 31 ---

[PATCH v2 03/12] powerpc/mm: drop ppc_md.iounmap() and __iounmap()

ppc_md.iounmap() is never set, drop it. Once ppc_md.iounmap() is gone, iounmap() remains the only user of __iounmap() and iounmap() does nothing else than calling __iounmap(). So drop iounmap() and make __iounmap() the new iounmap(). Reviewed-by: Christoph Hellwig Signed-off-by: Christophe

[PATCH v2 02/12] powerpc/ps3: replace __ioremap() by ioremap_prot()

__ioremap() is similar to ioremap_prot() except that ioremap_prot() does a few sanity changes in addition. The flags used by PS3 are not impacted by those changes so for PS3 both functions are equivalent. At the same time, drop parts of the comment that have been invalid since commit

Re: [PATCH v4 1/2] powerpc/time: Only set CONFIG_ARCH_HAS_SCALED_CPUTIME on PPC64

Christophe Leroy writes: > Hi Nick, > > > Le 07/06/2018 à 03:43, Nicholas Piggin a écrit : >> On Wed, 6 Jun 2018 14:21:08 + (UTC) >> Christophe Leroy wrote: >> >>> scaled cputime is only meaningfull when the processor has >>> SPURR and/or PURR, which means only on PPC64. >>> > > [...] > >>

Re: [PATCH] powerpc: Don't add -mabi= flags when building with Clang

On Mon, Aug 19, 2019 at 08:15:38PM -0700, Nathan Chancellor wrote: > On Mon, Aug 19, 2019 at 04:19:31AM -0500, Segher Boessenkool wrote: > > On Sun, Aug 18, 2019 at 12:13:21PM -0700, Nathan Chancellor wrote: > > > When building pseries_defconfig, building vdso32 errors out: > > > > > > error:

[bug report] hwmon: (ibmpowernv) Add attributes to enable/disable sensor groups

Hello Shilpasri G Bhat, The patch e0da99123f3c: "hwmon: (ibmpowernv) Add attributes to enable/disable sensor groups" from Jul 24, 2018, leads to the following static checker warning: drivers/hwmon/ibmpowernv.c:353 init_sensor_group_data() warn: missing error code here? 'sgrp()'

[PATCH v5 31/31] powernv/fadump: support holes in kernel boot memory area

With support to copy multiple kernel boot memory regions owing to copy size limitation, also handle holes in the memory area to be preserved. Support as many as 128 kernel boot memory regions. This allows having an adequate FADump capture kernel size for different scenarios. Signed-off-by: Hari

[PATCH v5 30/31] powernv/fadump: update documentation about option to release opalcore

With /sys/firmware/opal/core support available on OPAL based machines and an option to the release memory used by kernel in exporting this core file, update FADump documentation with these details. Signed-off-by: Hari Bathini --- Documentation/powerpc/firmware-assisted-dump.rst | 19

[PATCH v5 29/31] powerpc/fadump: consider f/w load area

OPAL loads kernel & initrd at 512MB offset (256MB size), also exported as ibm,opal/dump/fw-load-area. So, if boot memory size of FADump is less than 768MB, kernel memory to be exported as '/proc/vmcore' would be overwritten by f/w while loading kernel & initrd. To avoid such a scenario, enforce a

[PATCH v5 28/31] powernv/opalcore: provide an option to invalidate /sys/firmware/opal/core file

Writing '1' to /sys/kernel/fadump_release_opalcore would release the memory held by kernel in exporting /sys/firmware/opal/core file. Signed-off-by: Hari Bathini --- arch/powerpc/platforms/powernv/opal-core.c | 38 1 file changed, 38 insertions(+) diff --git

[PATCH v5 25/31] powernv/fadump: add support to preserve crash data on FADUMP disabled kernel

Add a new kernel config option, CONFIG_PRESERVE_FA_DUMP that ensures that crash data, from previously crash'ed kernel, is preserved. This helps in cases where FADump is not enabled but the subsequent memory preserving kernel boot is likely to process this crash data. One typical usecase for this

[PATCH v5 27/31] powernv/opalcore: export /sys/firmware/opal/core for analysing opal crashes

From: Hari Bathini Export /sys/firmware/opal/core file to analyze opal crashes. Since OPAL core can be generated independent of CONFIG_FA_DUMP support in kernel, add this support under a new kernel config option CONFIG_OPAL_CORE. Also, avoid code duplication by moving common code used while

[PATCH v5 26/31] powerpc/fadump: update documentation about CONFIG_PRESERVE_FA_DUMP

Kernel config option CONFIG_PRESERVE_FA_DUMP is introduced to ensure crash data, from previously crash'ed kernel, is preserved. Update documentation with this details. Signed-off-by: Hari Bathini --- Documentation/powerpc/firmware-assisted-dump.rst |9 + 1 file changed, 9

[PATCH v5 24/31] powerpc/fadump: improve how crashed kernel's memory is reserved

The size parameter to fadump_reserve_crash_area() function is not needed as all the memory above boot memory size must be preserved anyway. Update the function by dropping this redundant parameter. Signed-off-by: Hari Bathini --- arch/powerpc/kernel/fadump.c | 53

[PATCH v5 23/31] powerpc/fadump: consider reserved ranges while releasing memory

Commit 0962e8004e97 ("powerpc/prom: Scan reserved-ranges node for memory reservations") enabled support to parse 'reserved-ranges' DT node to reserve kernel memory falling in these ranges for firmware purposes. Along with the preserved area memory, ensure memory in reserved ranges is not

[PATCH v5 22/31] powerpc/fadump: make crash memory ranges array allocation generic

Make allocate_crash_memory_ranges() and free_crash_memory_ranges() functions generic to reuse them for memory management of all types of dynamic memory range arrays. This change helps in memory management of reserved ranges array to be added later. Signed-off-by: Hari Bathini ---

[PATCH v5 21/31] powernv/fadump: process architected register state data provided by firmware

From: Hari Bathini Firmware provides architected register state data at the time of crash. Process this data and build CPU notes to append to ELF core. Signed-off-by: Hari Bathini Signed-off-by: Vasant Hegde --- arch/powerpc/kernel/fadump-common.h |4 +

[PATCH v5 20/31] powerpc/fadump: use smaller offset while finding memory for reservation

Use a smaller offset, instead of size of the memory to be reserved by which to skip memory before making another attempt at reserving memory, after the previous attempt to reserve memory for FADump failed due to memory holes and/or reserved ranges, to reduce the likelihood of memory reservation

[PATCH v5 19/31] powerpc/fadump: Update documentation about OPAL platform support

With FADump support now available on both pseries and OPAL platforms, update FADump documentation with these details. Signed-off-by: Hari Bathini --- Documentation/powerpc/firmware-assisted-dump.rst | 104 +- 1 file changed, 63 insertions(+), 41 deletions(-) diff --git

[PATCH v5 18/31] powernv/fadump: handle invalidation of crashdump and re-registraion

Make OPAL call to indicate that the dump is processed and the metadata area in OPAL can be cleared/released. Also, setup/initialize FADump for re-registration. Signed-off-by: Hari Bathini --- arch/powerpc/kernel/fadump.c |7 ++-

[PATCH v5 17/31] powernv/fadump: Warn before processing partial crashdump

If all kernel boot memory regions are not registered for MPIPL before system crashes, try processing the partial crashdump but warn the user before proceeding. Signed-off-by: Hari Bathini --- arch/powerpc/platforms/powernv/opal-fadump.c | 24 1 file changed, 24

[PATCH v5 16/31] powernv/fadump: process the crashdump by exporting it as /proc/vmcore

Add support in the kernel to process the crash'ed kernel's memory preserved during MPIPL and export it as /proc/vmcore file for the userland scripts to filter and analyze it later. Signed-off-by: Hari Bathini --- arch/powerpc/platforms/powernv/opal-fadump.c | 165 ++ 1

[PATCH v5 15/31] powernv/fadump: support copying multiple kernel boot memory regions

Firmware uses 32-bit field for region size while copying/backing-up memory during MPIPL. So, the maximum copy size for a region would be a page less than 4GB (aligned to pagesize) but FADump capture kernel usually needs more memory than that to be preserved to avoid running into out of memory

[PATCH v5 14/31] powernv/fadump: define register/un-register callback functions

Make OPAL calls to register and un-register with firmware for MPIPL. Signed-off-by: Hari Bathini --- arch/powerpc/platforms/powernv/opal-fadump.c | 79 +- 1 file changed, 77 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/powernv/opal-fadump.c

[PATCH v5 13/31] powernv/fadump: reset metadata address during clean up

During kexec boot, metadata address needs to be reset to avoid running into errors interpreting stale metadata address, in case the kexec'ed kernel crashes before metadata address could be setup again. Signed-off-by: Hari Bathini --- arch/powerpc/kernel/fadump-common.h |1 +

[PATCH v5 12/31] powernv/fadump: register kernel metadata address with opal

OPAL allows registering address with it in the first kernel and retrieving it after MPIPL. Setup kernel metadata and register its address with OPAL to use it for processing the crash dump. Signed-off-by: Hari Bathini --- arch/powerpc/kernel/fadump-common.h |4 +

[PATCH v5 11/31] powernv/fadump: add fadump support on powernv

Add basic callback functions for FADump on PowerNV platform. Signed-off-by: Hari Bathini --- arch/powerpc/Kconfig |5 + arch/powerpc/kernel/fadump-common.h |9 ++ arch/powerpc/kernel/fadump.c |3 +

[PATCH v5 10/31] opal: add MPIPL interface definitions

Signed-off-by: Hari Bathini --- arch/powerpc/include/asm/opal-api.h| 50 +++- arch/powerpc/include/asm/opal.h|6 +++ arch/powerpc/platforms/powernv/opal-call.c |3 ++ 3 files changed, 58 insertions(+), 1 deletion(-) diff --git

[PATCH v5 09/31] powerpc/fadump: use FADump instead of fadump for how it is pronounced

fadump is pronounced f-a-dump. Update documentation accordingly. Also, update how fadump_region contents look like with recent changes. Signed-off-by: Hari Bathini --- Documentation/powerpc/firmware-assisted-dump.rst | 55 -- 1 file changed, 30 insertions(+), 25

[PATCH v5 08/31] pseries/fadump: move out platform specific support from generic code

Move code that supports processing the crash'ed kernel's memory preserved by firmware to platform specific callback functions. Signed-off-by: Hari Bathini --- arch/powerpc/kernel/fadump.c | 343 +- arch/powerpc/platforms/pseries/rtas-fadump.c | 280

[PATCH v5 07/31] powerpc/fadump: release all the memory above boot memory size

Except for reserve dump area which is permanent reserved, all memory above boot memory size is released when the dump is invalidated. Make this a bit more explicit in the code. Signed-off-by: Hari Bathini --- arch/powerpc/kernel/fadump.c | 34 ++ 1 file

[PATCH v5 06/31] pseries/fadump: define register/un-register callback functions

Make RTAS calls to register and un-register for FADump. Also, update how fadump_region contents are diplayed to provide more information. Signed-off-by: Hari Bathini Reviewed-by: Mahesh Salgaonkar --- arch/powerpc/kernel/fadump-common.h |2 arch/powerpc/kernel/fadump.c

[PATCH v5 05/31] pseries/fadump: introduce callbacks for platform specific operations

Introduce callback functions for platform specific operations like register, unregister, invalidate & such. Also, define place-holders for the same on pSeries platform. Signed-off-by: Hari Bathini --- arch/powerpc/kernel/fadump-common.h | 26 + arch/powerpc/kernel/fadump.c

[PATCH v5 04/31] pseries/fadump: move rtas specific definitions to platform code

Currently, FADump is only supported on pSeries but that is going to change soon with FADump support being added on PowerNV platform. So, move rtas specific definitions to platform code to allow FADump to have multiple platforms support. Signed-off-by: Hari Bathini ---

[PATCH v5 03/31] powerpc/fadump: Improve fadump documentation

The figures depicting FADump's (Firmware-Assisted Dump) memory layout are missing some finer details like different memory regions and what they represent. Improve the documentation by updating those details. Signed-off-by: Hari Bathini --- Documentation/powerpc/firmware-assisted-dump.rst |

[PATCH v5 02/31] powerpc/fadump: move internal code to a new file

Make way for refactoring platform specific FADump code by moving code that could be referenced from multiple places to fadump-common.c file. Signed-off-by: Hari Bathini --- arch/powerpc/kernel/Makefile|2 arch/powerpc/kernel/fadump-common.c | 140 ++

[PATCH v5 01/31] powerpc/fadump: move internal macros/definitions to a new header

Though asm/fadump.h is meant to be used by other components dealing with FADump, it also has macros/definitions internal to FADump code. Move them to a new header file used within FADump code. This also makes way for refactoring platform specific FADump code. Signed-off-by: Hari Bathini ---

[PATCH v5 00/31] Add FADump support on PowerNV platform

Firmware-Assisted Dump (FADump) is currently supported only on pSeries platform. This patch series adds support for PowerNV platform too. The first few patches refactor the FADump code to make use of common code across multiple platforms. Then basic FADump support is added for PowerNV platform.

[PATCH RESEND v11 8/8] selftests: add openat2(2) selftests

Test all of the various openat2(2) flags, as well as how file descriptor re-opening works. A small stress-test of a symlink-rename attack is included to show that the protections against ".."-based attacks are sufficient. In addition, the memfd selftest is fixed to no longer depend on the

Re: [PATCH] btrfs: fix allocation of bitmap pages.

On 8/20/19 4:30 AM, Christoph Hellwig wrote: > On Mon, Aug 19, 2019 at 07:46:00PM +0200, David Sterba wrote: >> Another thing that is lost is the slub debugging support for all >> architectures, because get_zeroed_pages lacking the red zones and sanity >> checks. >> >> I find working with raw

[PATCH RESEND v11 0/8] openat2(2)

This patchset is being developed here: Patch changelog: v11: [RESEND: ] * Fix checkpatch.pl errors and warnings where reasonable. * Minor cleanup to pr_warn

[PATCH RESEND v11 7/8] open: openat2(2) syscall

The most obvious syscall to add support for the new LOOKUP_* scoping flags would be openat(2). However, there are a few reasons why this is not the best course of action: * The new LOOKUP_* flags are intended to be security features, and openat(2) will silently ignore all unknown flags. This

[PATCH RESEND v11 3/8] open: O_EMPTYPATH: procfs-less file descriptor re-opening

Userspace has made use of /proc/self/fd very liberally to allow for descriptors to be re-opened. There are a wide variety of uses for this feature, but it has always required constructing a pathname and could not be done without procfs mounted. The obvious solution for this is to extend openat(2)

[PATCH RESEND v11 4/8] namei: O_BENEATH-style path resolution flags

Add the following flags to allow various restrictions on path resolution (these affect the *entire* resolution, rather than just the final path component -- as is the case with LOOKUP_FOLLOW). The primary justification for these flags is to allow for programs to be far more strict about how they

[PATCH RESEND v11 5/8] namei: LOOKUP_IN_ROOT: chroot-like path resolution

The primary motivation for the need for this flag is container runtimes which have to interact with malicious root filesystems in the host namespaces. One of the first requirements for a container runtime to be secure against a malicious rootfs is that they correctly scope symlinks (that is, they

[PATCH RESEND v11 6/8] namei: aggressively check for nd->root escape on ".." resolution

This patch allows for LOOKUP_BENEATH and LOOKUP_IN_ROOT to safely permit ".." resolution (in the case of LOOKUP_BENEATH the resolution will still fail if ".." resolution would resolve a path outside of the root -- while LOOKUP_IN_ROOT will chroot(2)-style scope it). Magic-link jumps are still

[PATCH RESEND v11 1/8] namei: obey trailing magic-link DAC permissions

The ability for userspace to "re-open" file descriptors through /proc/self/fd has been a very useful tool for all sorts of usecases (container runtimes are one common example). However, the current interface for doing this has resulted in some pretty subtle security holes. Userspace can re-open a

[PATCH RESEND v11 2/8] procfs: switch magic-link modes to be more sane

Now that magic-link modes are obeyed for file re-opening purposes, some of the pre-existing magic-link modes need to be adjusted to be more semantically correct. The most blatant example of this is /proc/self/exe, which had a mode of a+rwx even though tautologically the file could never be opened

Re: [PATCH 2/3] of_pmem: Add memory ranges which took a mce to bad range

On Tue, Aug 20, 2019 at 12:30 PM Santosh Sivaraj wrote: > > Subscribe to the MCE notification and add the physical address which > generated a memory error to nvdimm bad range. Uh... I should have looked a bit closer at this on v1. a) of_pmem.c isn't part of the powerpc tree. You should have

  1   2   >