[PATCH kernel v3] powerpc/xive: Drop deregistered irqs

There is a race between releasing an irq on one cpu and fetching it from XIVE on another cpu as there does not seem to be any locking between these, probably because xive_irq_chip::irq_shutdown() is supposed to remove the irq from all queues in the system which it does not do. As a result, when

Re: [PATCH kernel v3] powerpc/xive: Drop deregistered irqs

On Wed, 2019-07-17 at 15:00 +1000, Alexey Kardashevskiy wrote: > There is a race between releasing an irq on one cpu and fetching it > from XIVE on another cpu as there does not seem to be any locking between > these, probably because xive_irq_chip::irq_shutdown() is supposed to > remove the irq

Re: [PATCH v7] cpufreq/pasemi: fix an use-after-free in pas_cpufreq_cpu_init()

On 17-07-19, 11:55, Wen Yang wrote: > The cpu variable is still being used in the of_get_property() call > after the of_node_put() call, which may result in use-after-free. > > Fixes: a9acc26b75f6 ("cpufreq/pasemi: fix possible object reference leak") > Signed-off-by: Wen Yang > Cc: "Rafael J.

[PATCH v7] cpufreq/pasemi: fix an use-after-free in pas_cpufreq_cpu_init()

The cpu variable is still being used in the of_get_property() call after the of_node_put() call, which may result in use-after-free. Fixes: a9acc26b75f6 ("cpufreq/pasemi: fix possible object reference leak") Signed-off-by: Wen Yang Cc: "Rafael J. Wysocki" Cc: Viresh Kumar Cc: Michael Ellerman

Re: [PATCH v2 2/4] Add fchmodat4(), a new syscall

On Tue, Jul 16, 2019 at 10:40:46PM -0400, Rich Felker wrote: > On Tue, Jul 16, 2019 at 06:27:17PM -0700, Palmer Dabbelt wrote: > > man 3p says that fchmodat() takes a flags argument, but the Linux > > syscall does not. There doesn't appear to be a good userspace > > workaround for this issue but

Re: [PATCH v2 2/4] Add fchmodat4(), a new syscall

On Tue, Jul 16, 2019 at 06:27:17PM -0700, Palmer Dabbelt wrote: > man 3p says that fchmodat() takes a flags argument, but the Linux > syscall does not. There doesn't appear to be a good userspace > workaround for this issue but the implementation in the kernel is pretty > straight-forward. The

Re: [PATCH v2 2/4] Add fchmodat4(), a new syscall

On Tue, 16 Jul 2019 18:48:02 PDT (-0700), v...@zeniv.linux.org.uk wrote: On Tue, Jul 16, 2019 at 06:27:17PM -0700, Palmer Dabbelt wrote: -int do_fchmodat(int dfd, const char __user *filename, umode_t mode) +int do_fchmodat4(int dfd, const char __user *filename, umode_t mode, int flags) {

Re: [PATCH v2 2/4] Add fchmodat4(), a new syscall

On Tue, Jul 16, 2019 at 06:27:17PM -0700, Palmer Dabbelt wrote: > -int do_fchmodat(int dfd, const char __user *filename, umode_t mode) > +int do_fchmodat4(int dfd, const char __user *filename, umode_t mode, int > flags) > { > struct path path; > int error; > - unsigned int

[PATCH v2 4/4] tools: Add fchmodat4

I'm not sure why it's necessary to add this explicitly to tools/ as well as arch/, but there were a few instances of fspick in here so I blindly added fchmodat4 in the same fashion. Signed-off-by: Palmer Dabbelt --- tools/include/uapi/asm-generic/unistd.h | 4 +++-

[PATCH v2 3/4] arch: Register fchmodat4, usually as syscall 434

This registers the new fchmodat4 syscall in most places as nuber 434, with alpha being the exception where it's 544. I found all these sites by grepping for fspick, which I assume has found me everything. Signed-off-by: Palmer Dabbelt --- arch/alpha/kernel/syscalls/syscall.tbl | 1 +

Add a new fchmodat4() syscall, v2

This patch set adds fchmodat4(), a new syscall. The actual implementation is super simple: essentially it's just the same as fchmodat(), but LOOKUP_FOLLOW is conditionally set based on the flags. I've attempted to make this match "man 2 fchmodat" as closely as possible, which says EINVAL is

[PATCH v2 1/4] Non-functional cleanup of a "__user * filename"

The next patch defines a very similar interface, which I copied from this definition. Since I'm touching it anyway I don't see any reason not to just go fix this one up. Signed-off-by: Palmer Dabbelt --- include/linux/syscalls.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2 2/4] Add fchmodat4(), a new syscall

man 3p says that fchmodat() takes a flags argument, but the Linux syscall does not. There doesn't appear to be a good userspace workaround for this issue but the implementation in the kernel is pretty straight-forward. The specific use case where the missing flags came up was WRT a fuse

Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3

On 16.07.19 20:55, Christian Brauner wrote: On Tue, Jul 16, 2019 at 08:53:10PM +0200, Sven Schnelle wrote: Hi, [Adding Helge to CC list] On Tue, Jul 16, 2019 at 03:06:33PM +0200, Christian Brauner wrote: On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote: I think Vasily

[PATCH] powerpc/64: mark __boot_from_prom and start_here_common as __ref

Functions `__boot_from_prom` and `start_here_common` are "init code" in the sense that they are only executed at boot time, nevertheless they should not be tagged as __init since this will carry them to a different section located at the very end of kernel text. If the TOC is not set up, the

Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3

On Tue, Jul 16, 2019 at 08:53:10PM +0200, Sven Schnelle wrote: > Hi, > > [Adding Helge to CC list] > > On Tue, Jul 16, 2019 at 03:06:33PM +0200, Christian Brauner wrote: > > On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote: > > > I think Vasily already has a clone3 patch for

Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3

Hi, [Adding Helge to CC list] On Tue, Jul 16, 2019 at 03:06:33PM +0200, Christian Brauner wrote: > On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote: > > I think Vasily already has a clone3 patch for s390x with 435. > > A quick follow-up on this. Helge and Michael have

Re: [PATCH v3] tpm: tpm_ibm_vtpm: Fix unallocated banks

On Fri, 12 Jul 2019 00:13:57 +0300 Jarkko Sakkinen wrote: > On Thu, Jul 11, 2019 at 11:28:24PM +0300, Jarkko Sakkinen wrote: > > On Thu, Jul 11, 2019 at 12:13:35PM -0400, Nayna Jain wrote: > > > The nr_allocated_banks and allocated banks are initialized as part of > > > tpm_chip_register.

Non deterministic kernel crashes after minimal devicetree changes.

Dear everyone, we are currently developing a kernel upgrade for an older hardware. The system shall be upgraded from kernel 2.6.24 to the current stable vanilla kernel (4.19). With our new kernel we are facing strange and non deterministic kernel crashes which occur more or less randomly when

Re: [PATCH 02/12] Documentation/arm: repointer docs to Documentation/arch/arm

On Fri, 12 Jul 2019 at 04:20, Alex Shi wrote: > > Since we move 'arm/arm64' docs to Documentation/arch/{arm,arm64} dir, > redirect the doc pointer to them. > > Signed-off-by: Alex Shi > Cc: Jonathan Corbet > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski > Cc: linux-...@vger.kernel.org > Cc:

Re: [PATCH 1/2] arch: mark syscall number 435 reserved for clone3

On Mon, Jul 15, 2019 at 03:56:04PM +0200, Christian Borntraeger wrote: > I think Vasily already has a clone3 patch for s390x with 435. A quick follow-up on this. Helge and Michael have asked whether there are any tests for clone3. Yes, there will be and I try to have them ready by the end of the

Re: [PATCH] powerpc: remove meaningless KBUILD_ARFLAGS addition

Segher Boessenkool writes: > On Mon, Jul 15, 2019 at 05:05:34PM +1000, Michael Ellerman wrote: >> Segher Boessenkool writes: >> > Yes, that is why I used the environment variable, all binutils work >> > with that. There was no --target option in GNU ar before 2.22. >> >> Yeah, we're not very

[PATCH 01/14] docs: powerpc: convert docs to ReST and rename to *.rst

Convert docs to ReST and add them to the arch-specific book. The conversion here was trivial, as almost every file there was already using an elegant format close to ReST standard. The changes were mostly to mark literal blocks and add a few missing section title identifiers. One note with

[PATCH 00/14] pending doc patches for 5.3-rc

Those are the pending documentation patches after my pull request for this branch: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git tags/docs/v5.3-1 Patches 1 to 13 were already submitted, but got rebased. Patch 14 is a new fixup one. Patches 1 and 2 weren't submitted

Re: [PATCH kernel v2] powerpc/xive: Drop deregistered irqs

Cédric Le Goater writes: > On 16/07/2019 11:10, Alexey Kardashevskiy wrote: >> On 16/07/2019 18:59, Cédric Le Goater wrote: >>> On 15/07/2019 09:11, Alexey Kardashevskiy wrote: There is a race between releasing an irq on one cpu and fetching it from XIVE on another cpu as there does not

[PATCH v4 25/25] 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.txt | 19

[PATCH v4 24/25] powernv/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 v4 23/25] 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 v4 22/25] powernv/fadump: Warn before processing partial crashdump

If not all kernel boot memory regions are 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 | 21 + 1 file changed, 21

[PATCH v4 21/25] 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 v4 20/25] 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.txt |9 + 1 file changed, 9

[PATCH v4 19/25] 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 v4 18/25] 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 v4 17/25] 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, also ensure memory in reserved ranges is not

[PATCH v4 07/25] 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-common.h |6 arch/powerpc/kernel/fadump.c | 340 +-

[PATCH v4 16/25] powerpc/fadump: consider reserved ranges while reserving memory

Commit 0962e8004e97 ("powerpc/prom: Scan reserved-ranges node for memory reservations") enabled support to parse reserved-ranges DT node and reserve kernel memory falling in these ranges for F/W purposes. Ensure memory in these ranges is not overlapped with memory reserved for FADump. Also, use a

[PATCH v4 15/25] 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.txt | 104 +- 1 file changed, 63 insertions(+), 41 deletions(-) diff --git

[PATCH v4 14/25] 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 | 190 ++ 1

[PATCH v4 13/25] powernv/fadump: support copying multiple kernel 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 v4 12/25] 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 | 71 +- 1 file changed, 69 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/powernv/opal-fadump.c

[PATCH v4 11/25] 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 v4 10/25] 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 | 10 +++ arch/powerpc/kernel/fadump.c |3 +

[PATCH v4 09/25] 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 v4 08/25] 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.txt | 71 -- 1 file changed, 39 insertions(+), 32

[PATCH v4 06/25] 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 --- arch/powerpc/kernel/fadump-common.h |2 arch/powerpc/kernel/fadump.c | 164

[PATCH v4 05/25] 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 | 33 ++ arch/powerpc/kernel/fadump.c

[PATCH v4 04/25] 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 v4 03/25] 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.txt |

[PATCH v4 02/25] 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 | 144

[PATCH v4 01/25] 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 v4 00/25] 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.

Re: [PATCH v3 10/11] mm/memory_hotplug: Make unregister_memory_block_under_nodes() never fail

On 16.07.19 10:46, Oscar Salvador wrote: > On Mon, Jul 15, 2019 at 01:10:33PM +0200, David Hildenbrand wrote: >> On 01.07.19 12:27, Michal Hocko wrote: >>> On Mon 01-07-19 11:36:44, Oscar Salvador wrote: On Mon, Jul 01, 2019 at 10:51:44AM +0200, Michal Hocko wrote: > Yeah, we do not allow

Re: [PATCH v3 10/11] mm/memory_hotplug: Make unregister_memory_block_under_nodes() never fail

On 16.07.19 10:46, Oscar Salvador wrote: > On Mon, Jul 15, 2019 at 01:10:33PM +0200, David Hildenbrand wrote: >> On 01.07.19 12:27, Michal Hocko wrote: >>> On Mon 01-07-19 11:36:44, Oscar Salvador wrote: On Mon, Jul 01, 2019 at 10:51:44AM +0200, Michal Hocko wrote: > Yeah, we do not allow

Re: [PATCH 00/10] cpufreq: Migrate users of policy notifiers to QoS requests

On Tue, Jul 16, 2019 at 12:14 PM Viresh Kumar wrote: > > On 16-07-19, 12:06, Rafael J. Wysocki wrote: > > On Tue, Jul 16, 2019 at 11:49 AM Viresh Kumar > > wrote: > > > > > > Hello, > > > > > > Now that cpufreq core supports taking QoS requests for min/max cpu > > > frequencies, lets migrate

Re: [PATCH 00/10] cpufreq: Migrate users of policy notifiers to QoS requests

On 16-07-19, 12:06, Rafael J. Wysocki wrote: > On Tue, Jul 16, 2019 at 11:49 AM Viresh Kumar wrote: > > > > Hello, > > > > Now that cpufreq core supports taking QoS requests for min/max cpu > > frequencies, lets migrate rest of the users to using them instead of the > > policy notifiers. > >

Re: [PATCH 00/10] cpufreq: Migrate users of policy notifiers to QoS requests

On Tue, Jul 16, 2019 at 11:49 AM Viresh Kumar wrote: > > Hello, > > Now that cpufreq core supports taking QoS requests for min/max cpu > frequencies, lets migrate rest of the users to using them instead of the > policy notifiers. Technically, this still is linux-next only. :-) > The

[PATCH 06/10] powerpc: macintosh: Switch to QoS requests instead of cpufreq notifier

The cpufreq core now takes the min/max frequency constraints via QoS requests and the CPUFREQ_ADJUST notifier shall get removed later on. Switch over to using the QoS request for maximum frequency constraint for windfarm_cpufreq_clamp driver. Signed-off-by: Viresh Kumar ---

[PATCH 00/10] cpufreq: Migrate users of policy notifiers to QoS requests

Hello, Now that cpufreq core supports taking QoS requests for min/max cpu frequencies, lets migrate rest of the users to using them instead of the policy notifiers. The CPUFREQ_NOTIFY and CPUFREQ_ADJUST events of the policy notifiers are removed as a result, but we have to add

Re: [PATCH kernel v2] powerpc/xive: Drop deregistered irqs

On 15/07/2019 09:11, Alexey Kardashevskiy wrote: > There is a race between releasing an irq on one cpu and fetching it > from XIVE on another cpu as there does not seem to be any locking between > these, probably because xive_irq_chip::irq_shutdown() is supposed to > remove the irq from all queues

Re: [PATCH kernel v2] powerpc/xive: Drop deregistered irqs

On 16/07/2019 11:10, Alexey Kardashevskiy wrote: > > > On 16/07/2019 18:59, Cédric Le Goater wrote: >> On 15/07/2019 09:11, Alexey Kardashevskiy wrote: >>> There is a race between releasing an irq on one cpu and fetching it >>> from XIVE on another cpu as there does not seem to be any locking

Re: [PATCH kernel v2] powerpc/xive: Drop deregistered irqs

On 16/07/2019 18:59, Cédric Le Goater wrote: On 15/07/2019 09:11, Alexey Kardashevskiy wrote: There is a race between releasing an irq on one cpu and fetching it from XIVE on another cpu as there does not seem to be any locking between these, probably because xive_irq_chip::irq_shutdown() is

[PATCH v2] powerpc/nvdimm: Pick the nearby online node if the device node is not online

This is similar to what ACPI does. Nvdimm layer doesn't bring the SCM device numa node online. Hence we need to make sure we always use an online node as ndr_desc.numa_node. Otherwise this result in kernel crashes. The target node is used by dax/kmem and that will bring up the numa node online

Re: [PATCH v6] cpufreq/pasemi: fix an use-after-free inpas_cpufreq_cpu_init()

On 16-07-19, 16:26, wen.yan...@zte.com.cn wrote: > Okay thank you. > Now this patch > (https://lore.kernel.org/lkml/ee8cf5fb4b4a01fdf9199037ff6d835b935cfd13.1562902877.git.viresh.ku...@linaro.org/) > > seems to have not been merged into the linux-next. > > In order to avoid code conflicts, we

[Bug 203647] Locking API testsuite fails "mixed read-lock/lock-write ABBA" rlock on kernels >=4.14.x

https://bugzilla.kernel.org/show_bug.cgi?id=203647 Anatoly Pugachev (mator...@gmail.com) changed: What|Removed |Added CC|

Re: [PATCH v3 10/11] mm/memory_hotplug: Make unregister_memory_block_under_nodes() never fail

On Mon, Jul 15, 2019 at 01:10:33PM +0200, David Hildenbrand wrote: > On 01.07.19 12:27, Michal Hocko wrote: > > On Mon 01-07-19 11:36:44, Oscar Salvador wrote: > >> On Mon, Jul 01, 2019 at 10:51:44AM +0200, Michal Hocko wrote: > >>> Yeah, we do not allow to offline multi zone (node) ranges so the

Re: [PATCH v6] cpufreq/pasemi: fix an use-after-free inpas_cpufreq_cpu_init()

> > The cpu variable is still being used in the of_get_property() call > > after the of_node_put() call, which may result in use-after-free. > > > > Fixes: a9acc26b75f6 ("cpufreq/pasemi: fix possible object reference leak") > > Signed-off-by: Wen Yang > > Cc: "Rafael J. Wysocki" > > Cc: Viresh

Re: [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags

On 2019-07-14, Al Viro wrote: > On Sat, Jul 13, 2019 at 03:41:53AM +0100, Al Viro wrote: > > On Fri, Jul 12, 2019 at 04:00:26PM +0100, Al Viro wrote: > > > On Fri, Jul 12, 2019 at 02:25:53PM +0100, Al Viro wrote: > > > > > > > if (flags & LOOKUP_BENEATH) { > > > >

Re: [PATCH] powerpc: remove meaningless KBUILD_ARFLAGS addition

On Tue, Jul 16, 2019 at 3:16 AM Segher Boessenkool wrote: > > On Mon, Jul 15, 2019 at 09:03:46PM +0900, Masahiro Yamada wrote: > > On Mon, Jul 15, 2019 at 4:30 PM Segher Boessenkool > > wrote: > > > > > > On Mon, Jul 15, 2019 at 05:05:34PM +1000, Michael Ellerman wrote: > > > > Segher

Re: [EXTERNAL] Re: [PATCH v2 3/6] powerpc/eeh: Improve debug messages around device addition

On Tue, 2019-07-16 at 16:48 +1000, Sam Bobroff wrote: > On Thu, Jun 20, 2019 at 01:45:24PM +1000, Oliver O'Halloran wrote: > > On Thu, Jun 20, 2019 at 12:40 PM Alexey Kardashevskiy > > wrote: > > > On 19/06/2019 14:27, Sam Bobroff wrote: > > > > On Tue, Jun 11, 2019 at 03:47:58PM +1000, Alexey

Re: [EXTERNAL] Re: [PATCH v2 3/6] powerpc/eeh: Improve debug messages around device addition

On Thu, Jun 20, 2019 at 01:45:24PM +1000, Oliver O'Halloran wrote: > On Thu, Jun 20, 2019 at 12:40 PM Alexey Kardashevskiy wrote: > > > > On 19/06/2019 14:27, Sam Bobroff wrote: > > > On Tue, Jun 11, 2019 at 03:47:58PM +1000, Alexey Kardashevskiy wrote: > > >> > > >> On 07/05/2019 14:30, Sam

[PATCH v2] powerpc/mm/radix: Fix PTE/PMD fragment count for early page table mappings

We could potentially hit the following BUG_ON when memory hotplugged before reboot is unplugged after reboot: kernel BUG at arch/powerpc/mm/pgtable-frag.c:113! remove_pagetable+0x594/0x6a0 (unreliable) remove_pagetable+0x94/0x6a0 vmemmap_free+0x394/0x410