* Re: [PATCH v3] scsi: ibmvscsi: Don't use rc uninitialized in ibmvscsi_do_work
From: Tyrel Datwyler @ 2019-06-03 23:58 UTC (permalink / raw)
To: Nathan Chancellor, Tyrel Datwyler, James E.J. Bottomley,
Martin K. Petersen
Cc: clang-built-linux, linuxppc-dev, linux-kernel, linux-scsi
In-Reply-To: <20190603234405.29600-1-natechancellor@gmail.com>
On 06/03/2019 04:44 PM, Nathan Chancellor wrote:
> clang warns:
>
> drivers/scsi/ibmvscsi/ibmvscsi.c:2126:7: warning: variable 'rc' is used
> uninitialized whenever switch case is taken [-Wsometimes-uninitialized]
> case IBMVSCSI_HOST_ACTION_NONE:
> ^~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/scsi/ibmvscsi/ibmvscsi.c:2151:6: note: uninitialized use occurs
> here
> if (rc) {
> ^~
>
> Initialize rc in the IBMVSCSI_HOST_ACTION_UNBLOCK case statement then
> shuffle IBMVSCSI_HOST_ACTION_NONE down to the default case statement and
> make it return early so that rc is never used uninitialized in this
> function.
>
> Fixes: 035a3c4046b5 ("scsi: ibmvscsi: redo driver work thread to use enum action states")
> Link: https://github.com/ClangBuiltLinux/linux/issues/502
> Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
> Suggested-by: Tyrel Datwyler <tyreld@linux.ibm.com>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Tyrel Datwyler <tyreld@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH v2] PCI: rpaphp: Avoid a sometimes-uninitialized warning
From: Tyrel Datwyler @ 2019-06-04 0:03 UTC (permalink / raw)
To: Nathan Chancellor, Tyrel Datwyler, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman
Cc: linux-pci, Nick Desaulniers, linux-kernel, clang-built-linux,
Bjorn Helgaas, linuxppc-dev
In-Reply-To: <20190603221157.58502-1-natechancellor@gmail.com>
On 06/03/2019 03:11 PM, Nathan Chancellor wrote:
> When building with -Wsometimes-uninitialized, clang warns:
>
> drivers/pci/hotplug/rpaphp_core.c:243:14: warning: variable 'fndit' is
> used uninitialized whenever 'for' loop exits because its condition is
> false [-Wsometimes-uninitialized]
> for (j = 0; j < entries; j++) {
> ^~~~~~~~~~~
> drivers/pci/hotplug/rpaphp_core.c:256:6: note: uninitialized use occurs
> here
> if (fndit)
> ^~~~~
> drivers/pci/hotplug/rpaphp_core.c:243:14: note: remove the condition if
> it is always true
> for (j = 0; j < entries; j++) {
> ^~~~~~~~~~~
> drivers/pci/hotplug/rpaphp_core.c:233:14: note: initialize the variable
> 'fndit' to silence this warning
> int j, fndit;
> ^
> = 0
>
> fndit is only used to gate a sprintf call, which can be moved into the
> loop to simplify the code and eliminate the local variable, which will
> fix this warning.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/504
> Fixes: 2fcf3ae508c2 ("hotplug/drc-info: Add code to search ibm,drc-info property")
> Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Tyrel Datwyler <tyreld@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH kernel] prom_init: Fetch flatten device tree from the system firmware
From: Benjamin Herrenschmidt @ 2019-06-04 0:18 UTC (permalink / raw)
To: Segher Boessenkool, Alexey Kardashevskiy
Cc: linuxppc-dev, Suraj Jitindar Singh, David Gibson
In-Reply-To: <20190603234247.GQ31586@gate.crashing.org>
On Mon, 2019-06-03 at 18:42 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jun 03, 2019 at 12:56:26PM +1000, Alexey Kardashevskiy wrote:
> > On 03/06/2019 09:23, Segher Boessenkool wrote:
> > > > So I go for the simple one and agree with Alexey's idea.
> > >
> > > When dealing with a whole device tree you have to know about the
> > > various
> > > dynamically generated nodes and props, and handle each
> > > appropriately.
> >
> > The code I am changing fetches the device tree and build an fdt.
> > What is
> > that special knowledge in this context you are talking about?
>
> Things like /options are dynamically generated.
They are generated before we do the call to extract the fdt, what's the
problem there ?
> I thought you would just be able to reuse some FDT parsing code to
> implement my suggested new interface. Maybe that was too optimistic.
No, the idea is to have SLOF re-flatten it's live tree and hand us a
blob. At least that's my understanding.
Ben.
^ permalink raw reply
* Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
From: Thiago Jung Bauermann @ 2019-06-04 1:13 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Mike Anderson, Michael Roth, Jean-Philippe Brucker, Jason Wang,
Alexey Kardashevskiy, Ram Pai, linux-kernel, virtualization,
iommu, linuxppc-dev, Christoph Hellwig, David Gibson
In-Reply-To: <20190520090939-mutt-send-email-mst@kernel.org>
Michael S. Tsirkin <mst@redhat.com> writes:
> On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote:
>> I rephrased it in terms of address translation. What do you think of
>> this version? The flag name is slightly different too:
>>
>>
>> VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature has the same
>> meaning as VIRTIO_F_ACCESS_PLATFORM both when set and when not set,
>> with the exception that address translation is guaranteed to be
>> unnecessary when accessing memory addresses supplied to the device
>> by the driver. Which is to say, the device will always use physical
>> addresses matching addresses used by the driver (typically meaning
>> physical addresses used by the CPU) and not translated further. This
>> flag should be set by the guest if offered, but to allow for
>> backward-compatibility device implementations allow for it to be
>> left unset by the guest. It is an error to set both this flag and
>> VIRTIO_F_ACCESS_PLATFORM.
>
>
> OK so VIRTIO_F_ACCESS_PLATFORM is designed to allow unpriveledged
> drivers. This is why devices fail when it's not negotiated.
Just to clarify, what do you mean by unprivileged drivers? Is it drivers
implemented in guest userspace such as with VFIO? Or unprivileged in
some other sense such as needing to use bounce buffers for some reason?
> This confuses me.
> If driver is unpriveledged then what happens with this flag?
> It can supply any address it wants. Will that corrupt kernel
> memory?
Not needing address translation doesn't necessarily mean that there's no
IOMMU. On powerpc we don't use VIRTIO_F_ACCESS_PLATFORM but there's
always an IOMMU present. And we also support VFIO drivers. The VFIO API
for pseries (sPAPR section in Documentation/vfio.txt) has extra ioctls
to program the IOMMU.
For our use case, we don't need address translation because we set up an
identity mapping in the IOMMU so that the device can use guest physical
addresses.
If the guest kernel is concerned that an unprivileged driver could
jeopardize its integrity it should not negotiate this feature flag.
Perhaps there should be a note about this in the flag definition? This
concern is platform-dependant though. I don't believe it's an issue in
pseries.
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
From: Michael S. Tsirkin @ 2019-06-04 1:42 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: Mike Anderson, Michael Roth, Jean-Philippe Brucker, Jason Wang,
Alexey Kardashevskiy, Ram Pai, linux-kernel, virtualization,
iommu, linuxppc-dev, Christoph Hellwig, David Gibson
In-Reply-To: <877ea26tk8.fsf@morokweng.localdomain>
On Mon, Jun 03, 2019 at 10:13:59PM -0300, Thiago Jung Bauermann wrote:
>
>
> Michael S. Tsirkin <mst@redhat.com> writes:
>
> > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote:
> >> I rephrased it in terms of address translation. What do you think of
> >> this version? The flag name is slightly different too:
> >>
> >>
> >> VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature has the same
> >> meaning as VIRTIO_F_ACCESS_PLATFORM both when set and when not set,
> >> with the exception that address translation is guaranteed to be
> >> unnecessary when accessing memory addresses supplied to the device
> >> by the driver. Which is to say, the device will always use physical
> >> addresses matching addresses used by the driver (typically meaning
> >> physical addresses used by the CPU) and not translated further. This
> >> flag should be set by the guest if offered, but to allow for
> >> backward-compatibility device implementations allow for it to be
> >> left unset by the guest. It is an error to set both this flag and
> >> VIRTIO_F_ACCESS_PLATFORM.
> >
> >
> > OK so VIRTIO_F_ACCESS_PLATFORM is designed to allow unpriveledged
> > drivers. This is why devices fail when it's not negotiated.
>
> Just to clarify, what do you mean by unprivileged drivers? Is it drivers
> implemented in guest userspace such as with VFIO? Or unprivileged in
> some other sense such as needing to use bounce buffers for some reason?
I had drivers in guest userspace in mind.
> > This confuses me.
> > If driver is unpriveledged then what happens with this flag?
> > It can supply any address it wants. Will that corrupt kernel
> > memory?
>
> Not needing address translation doesn't necessarily mean that there's no
> IOMMU. On powerpc we don't use VIRTIO_F_ACCESS_PLATFORM but there's
> always an IOMMU present. And we also support VFIO drivers. The VFIO API
> for pseries (sPAPR section in Documentation/vfio.txt) has extra ioctls
> to program the IOMMU.
>
> For our use case, we don't need address translation because we set up an
> identity mapping in the IOMMU so that the device can use guest physical
> addresses.
And can it access any guest physical address?
> If the guest kernel is concerned that an unprivileged driver could
> jeopardize its integrity it should not negotiate this feature flag.
Unfortunately flag negotiation is done through config space
and so can be overwritten by the driver.
> Perhaps there should be a note about this in the flag definition? This
> concern is platform-dependant though. I don't believe it's an issue in
> pseries.
Again ACCESS_PLATFORM has a pretty open definition. It does actually
say it's all up to the platform.
Specifically how will VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION be
implemented portably? virtio has no portable way to know
whether DMA API bypasses translation.
> --
> Thiago Jung Bauermann
> IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v2 1/5] powerpc/powernv: Move SCOM access code into powernv platform
From: Andrew Donnellan @ 2019-06-04 2:01 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20190509051119.7694-1-ajd@linux.ibm.com>
On 9/5/19 3:11 pm, Andrew Donnellan wrote:
> The powernv platform is the only one that directly accesses SCOMs. Move the
> support code to platforms/powernv, and get rid of the PPC_SCOM Kconfig
> option, as SCOM support is always selected when compiling for powernv.
>
> This also means that the Kconfig item for CONFIG_SCOM_DEBUGFS will actually
> show up in menuconfig, as previously it was the only labelled option in
> sysdev/Kconfig and wasn't actually in a menu.
As I've just realised, this isn't actually correct - the option does
indeed show up... in the root menu, where I've just been trained to
ignore it, and where you won't get a menu location if you try to search
for it using / in menuconfig.
I think moving it to the platform menu is obviously a better location.
mpe would you be able to fix up the commit message in merge?
Andrew
>
> Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
> ---
> v1->v2:
> - move scom.h as well (mpe)
> - add all the other patches in this series
> ---
> arch/powerpc/platforms/powernv/Kconfig | 5 ++++-
> arch/powerpc/platforms/powernv/Makefile | 2 +-
> arch/powerpc/platforms/powernv/opal-xscom.c | 3 ++-
> arch/powerpc/{sysdev => platforms/powernv}/scom.c | 3 ++-
> .../{include/asm => platforms/powernv}/scom.h | 13 +++----------
> arch/powerpc/sysdev/Kconfig | 7 -------
> arch/powerpc/sysdev/Makefile | 2 --
> 7 files changed, 12 insertions(+), 23 deletions(-)
> rename arch/powerpc/{sysdev => platforms/powernv}/scom.c (99%)
> rename arch/powerpc/{include/asm => platforms/powernv}/scom.h (95%)
>
> diff --git a/arch/powerpc/platforms/powernv/Kconfig b/arch/powerpc/platforms/powernv/Kconfig
> index 850eee860cf2..938803eab0ad 100644
> --- a/arch/powerpc/platforms/powernv/Kconfig
> +++ b/arch/powerpc/platforms/powernv/Kconfig
> @@ -12,7 +12,6 @@ config PPC_POWERNV
> select EPAPR_BOOT
> select PPC_INDIRECT_PIO
> select PPC_UDBG_16550
> - select PPC_SCOM
> select ARCH_RANDOM
> select CPU_FREQ
> select PPC_DOORBELL
> @@ -47,3 +46,7 @@ config PPC_VAS
> VAS adapters are found in POWER9 based systems.
>
> If unsure, say N.
> +
> +config SCOM_DEBUGFS
> + bool "Expose SCOM controllers via debugfs"
> + depends on DEBUG_FS
> diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile
> index da2e99efbd04..4b1644150135 100644
> --- a/arch/powerpc/platforms/powernv/Makefile
> +++ b/arch/powerpc/platforms/powernv/Makefile
> @@ -4,12 +4,12 @@ obj-y += idle.o opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
> obj-y += rng.o opal-elog.o opal-dump.o opal-sysparam.o opal-sensor.o
> obj-y += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o
> obj-y += opal-kmsg.o opal-powercap.o opal-psr.o opal-sensor-groups.o
> +obj-y += opal-xscom.o scom.o
>
> obj-$(CONFIG_SMP) += smp.o subcore.o subcore-asm.o
> obj-$(CONFIG_PCI) += pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o
> obj-$(CONFIG_CXL_BASE) += pci-cxl.o
> obj-$(CONFIG_EEH) += eeh-powernv.o
> -obj-$(CONFIG_PPC_SCOM) += opal-xscom.o
> obj-$(CONFIG_MEMORY_FAILURE) += opal-memory-errors.o
> obj-$(CONFIG_OPAL_PRD) += opal-prd.o
> obj-$(CONFIG_PERF_EVENTS) += opal-imc.o
> diff --git a/arch/powerpc/platforms/powernv/opal-xscom.c b/arch/powerpc/platforms/powernv/opal-xscom.c
> index 22d5e1110dbb..66337d92cb63 100644
> --- a/arch/powerpc/platforms/powernv/opal-xscom.c
> +++ b/arch/powerpc/platforms/powernv/opal-xscom.c
> @@ -18,7 +18,8 @@
> #include <asm/machdep.h>
> #include <asm/firmware.h>
> #include <asm/opal.h>
> -#include <asm/scom.h>
> +
> +#include "scom.h"
>
> /*
> * We could probably fit that inside the scom_map_t
> diff --git a/arch/powerpc/sysdev/scom.c b/arch/powerpc/platforms/powernv/scom.c
> similarity index 99%
> rename from arch/powerpc/sysdev/scom.c
> rename to arch/powerpc/platforms/powernv/scom.c
> index a707b24a7ddb..50c019d2ef45 100644
> --- a/arch/powerpc/sysdev/scom.c
> +++ b/arch/powerpc/platforms/powernv/scom.c
> @@ -23,9 +23,10 @@
> #include <linux/export.h>
> #include <asm/debugfs.h>
> #include <asm/prom.h>
> -#include <asm/scom.h>
> #include <linux/uaccess.h>
>
> +#include "scom.h"
> +
> const struct scom_controller *scom_controller;
> EXPORT_SYMBOL_GPL(scom_controller);
>
> diff --git a/arch/powerpc/include/asm/scom.h b/arch/powerpc/platforms/powernv/scom.h
> similarity index 95%
> rename from arch/powerpc/include/asm/scom.h
> rename to arch/powerpc/platforms/powernv/scom.h
> index f5cde45b1161..b14fe0edf95b 100644
> --- a/arch/powerpc/include/asm/scom.h
> +++ b/arch/powerpc/platforms/powernv/scom.h
> @@ -18,12 +18,8 @@
> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> */
>
> -#ifndef _ASM_POWERPC_SCOM_H
> -#define _ASM_POWERPC_SCOM_H
> -
> -#ifdef __KERNEL__
> -#ifndef __ASSEMBLY__
> -#ifdef CONFIG_PPC_SCOM
> +#ifndef _SCOM_H
> +#define _SCOM_H
>
> /*
> * The SCOM bus is a sideband bus used for accessing various internal
> @@ -161,7 +157,4 @@ static inline int scom_write(scom_map_t map, u64 reg, u64 value)
> }
>
>
> -#endif /* CONFIG_PPC_SCOM */
> -#endif /* __ASSEMBLY__ */
> -#endif /* __KERNEL__ */
> -#endif /* _ASM_POWERPC_SCOM_H */
> +#endif /* _SCOM_H */
> diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
> index e0dbec780fe9..7808d279ff1d 100644
> --- a/arch/powerpc/sysdev/Kconfig
> +++ b/arch/powerpc/sysdev/Kconfig
> @@ -28,13 +28,6 @@ config PPC_MSI_BITMAP
> source "arch/powerpc/sysdev/xics/Kconfig"
> source "arch/powerpc/sysdev/xive/Kconfig"
>
> -config PPC_SCOM
> - bool
> -
> -config SCOM_DEBUGFS
> - bool "Expose SCOM controllers via debugfs"
> - depends on PPC_SCOM && DEBUG_FS
> -
> config GE_FPGA
> bool
>
> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
> index aaf23283ba0c..35d52d1d2fc0 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -51,8 +51,6 @@ ifdef CONFIG_SUSPEND
> obj-$(CONFIG_PPC_BOOK3S_32) += 6xx-suspend.o
> endif
>
> -obj-$(CONFIG_PPC_SCOM) += scom.o
> -
> obj-$(CONFIG_PPC_EARLY_DEBUG_MEMCONS) += udbg_memcons.o
>
> obj-$(CONFIG_PPC_XICS) += xics/
>
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH kernel] prom_init: Fetch flatten device tree from the system firmware
From: David Gibson @ 2019-06-04 0:32 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Alexey Kardashevskiy, linuxppc-dev, Suraj Jitindar Singh
In-Reply-To: <20190603234932.GR31586@gate.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]
On Mon, Jun 03, 2019 at 06:49:32PM -0500, Segher Boessenkool wrote:
> On Tue, Jun 04, 2019 at 07:18:42AM +1000, Benjamin Herrenschmidt wrote:
> > Yes we could make property fetching faster but mostly by creating a new
> > bulk interface which is quite a bit of work, a new API, and will in
> > practice not be used for anything other than creating the FDT. In that
> > case, nothing will beat in performance having OF create the FDT itself
> > based on its current tree.
>
> And that will change the whole boot protocol, the interaction between OF
> and its client, which is a much bigger change, not conceptually trivial
> at all. Copying all properties at once is, which is why I suggested it.
Much as I wasn't terribly convinced by the original idea, I agree with
Ben and Alexey here. Your approach has slightly more complexity for
slightly less benefit. If it's worth doing yours it's better to do
theirs.
> It would take away the opposition to your patch.
Only from you, AFAICT...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/2] powerpc: Fix compile issue with force DAWR
From: Michael Neuling @ 2019-06-04 3:00 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Mathieu Malaterre, linuxppc-dev
In-Reply-To: <20190529062842.GA4787@infradead.org>
I agree with all the below and will address in v5.
Mikey
On Tue, 2019-05-28 at 23:28 -0700, Christoph Hellwig wrote:
> > +config PPC_DAWR
> > + bool
> > + default n
>
> "default n" is the default default. No need to write this line.
>
> > +++ b/arch/powerpc/kernel/dawr.c
> > @@ -0,0 +1,100 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +//
> > +// DAWR infrastructure
> > +//
> > +// Copyright 2019, Michael Neuling, IBM Corporation.
>
> Normal top of file header should be /* */, //-style comments are only
> for the actual SPDX heder line.
>
> > + /* Send error to user if they hypervisor won't allow us to write DAWR */
> > + if ((!dawr_force_enable) &&
> > + (firmware_has_feature(FW_FEATURE_LPAR)) &&
> > + (set_dawr(&null_brk) != H_SUCCESS))
>
> None of the three inner brace sets here are required, and the code
> becomes much easier to read without them.
>
> > + return -1;
>
> What about returning a proper error code?
>
> > +static int __init dawr_force_setup(void)
> > +{
> > + dawr_force_enable = false;
>
> This variable already is initialized to alse by default, so this line
> is not required.
>
> > + if (PVR_VER(mfspr(SPRN_PVR)) == PVR_POWER9) {
> > + /* Turn DAWR off by default, but allow admin to turn it on */
> > + dawr_force_enable = false;
>
> .. and neither is this one.
>
^ permalink raw reply
* Re: [RFC PATCH v2] powerpc/xmon: restrict when kernel is locked down
From: Christopher M Riedl @ 2019-06-04 3:05 UTC (permalink / raw)
To: Andrew Donnellan, linuxppc-dev, kernel-hardening; +Cc: mjg59, dja
In-Reply-To: <81549d40-e477-6552-9a12-7200933279af@linux.ibm.com>
> On June 3, 2019 at 1:36 AM Andrew Donnellan <ajd@linux.ibm.com> wrote:
>
>
> On 24/5/19 10:38 pm, Christopher M. Riedl wrote:
> > Xmon should be either fully or partially disabled depending on the
> > kernel lockdown state.
> >
> > Put xmon into read-only mode for lockdown=integrity and completely
> > disable xmon when lockdown=confidentiality. Xmon checks the lockdown
> > state and takes appropriate action:
> >
> > (1) during xmon_setup to prevent early xmon'ing
> >
> > (2) when triggered via sysrq
> >
> > (3) when toggled via debugfs
> >
> > (4) when triggered via a previously enabled breakpoint
> >
> > The following lockdown state transitions are handled:
> >
> > (1) lockdown=none -> lockdown=integrity
> > clear all breakpoints, set xmon read-only mode
> >
> > (2) lockdown=none -> lockdown=confidentiality
> > clear all breakpoints, prevent re-entry into xmon
> >
> > (3) lockdown=integrity -> lockdown=confidentiality
> > prevent re-entry into xmon
> >
> > Suggested-by: Andrew Donnellan <ajd@linux.ibm.com>
> > Signed-off-by: Christopher M. Riedl <cmr@informatik.wtf>
> > ---
> >
> > Applies on top of this series:
> > https://patchwork.kernel.org/cover/10884631/
> >
> > I've done some limited testing of the scenarios mentioned in the commit
> > message on a single CPU QEMU config.
> >
> > v1->v2:
> > Fix subject line
> > Submit to linuxppc-dev and kernel-hardening
> >
> > arch/powerpc/xmon/xmon.c | 56 +++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 55 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> > index 3e7be19aa208..8c4a5a0c28f0 100644
> > --- a/arch/powerpc/xmon/xmon.c
> > +++ b/arch/powerpc/xmon/xmon.c
> > @@ -191,6 +191,9 @@ static void dump_tlb_44x(void);
> > static void dump_tlb_book3e(void);
> > #endif
> >
> > +static void clear_all_bpt(void);
> > +static void xmon_init(int);
> > +
> > #ifdef CONFIG_PPC64
> > #define REG "%.16lx"
> > #else
> > @@ -291,6 +294,39 @@ Commands:\n\
> > zh halt\n"
> > ;
> >
> > +#ifdef CONFIG_LOCK_DOWN_KERNEL
> > +static bool xmon_check_lockdown(void)
> > +{
> > + static bool lockdown = false;
> > +
> > + if (!lockdown) {
> > + lockdown = kernel_is_locked_down("Using xmon",
> > + LOCKDOWN_CONFIDENTIALITY);
> > + if (lockdown) {
> > + printf("xmon: Disabled by strict kernel lockdown\n");
> > + xmon_on = 0;
> > + xmon_init(0);
> > + }
> > + }
> > +
> > + if (!xmon_is_ro) {
> > + xmon_is_ro = kernel_is_locked_down("Using xmon write-access",
> > + LOCKDOWN_INTEGRITY);
> > + if (xmon_is_ro) {
> > + printf("xmon: Read-only due to kernel lockdown\n");
> > + clear_all_bpt();
>
> Remind me again why we need to clear breakpoints in integrity mode?
>
>
> Andrew
>
I interpreted "integrity" mode as meaning that any changes made by xmon should
be reversed. This also covers the case when a user creates some breakpoint(s)
in xmon, exits xmon, and then elevates the lockdown state. Upon hitting the
first breakpoint and (re-)entering xmon, xmon will clear all breakpoints.
Xmon can only take action in response to dynamic lockdown level changes when
xmon is invoked in some manner - if there is a better way I am all ears :)
>
> > + }
> > + }
> > +
> > + return lockdown;
> > +}
> > +#else
> > +inline static bool xmon_check_lockdown(void)
> > +{
> > + return false;
> > +}
> > +#endif /* CONFIG_LOCK_DOWN_KERNEL */
> > +
> > static struct pt_regs *xmon_regs;
> >
> > static inline void sync(void)
> > @@ -708,6 +744,9 @@ static int xmon_bpt(struct pt_regs *regs)
> > struct bpt *bp;
> > unsigned long offset;
> >
> > + if (xmon_check_lockdown())
> > + return 0;
> > +
> > if ((regs->msr & (MSR_IR|MSR_PR|MSR_64BIT)) != (MSR_IR|MSR_64BIT))
> > return 0;
> >
> > @@ -739,6 +778,9 @@ static int xmon_sstep(struct pt_regs *regs)
> >
> > static int xmon_break_match(struct pt_regs *regs)
> > {
> > + if (xmon_check_lockdown())
> > + return 0;
> > +
> > if ((regs->msr & (MSR_IR|MSR_PR|MSR_64BIT)) != (MSR_IR|MSR_64BIT))
> > return 0;
> > if (dabr.enabled == 0)
> > @@ -749,6 +791,9 @@ static int xmon_break_match(struct pt_regs *regs)
> >
> > static int xmon_iabr_match(struct pt_regs *regs)
> > {
> > + if (xmon_check_lockdown())
> > + return 0;
> > +
> > if ((regs->msr & (MSR_IR|MSR_PR|MSR_64BIT)) != (MSR_IR|MSR_64BIT))
> > return 0;
> > if (iabr == NULL)
> > @@ -3742,6 +3787,9 @@ static void xmon_init(int enable)
> > #ifdef CONFIG_MAGIC_SYSRQ
> > static void sysrq_handle_xmon(int key)
> > {
> > + if (xmon_check_lockdown())
> > + return;
> > +
> > /* ensure xmon is enabled */
> > xmon_init(1);
> > debugger(get_irq_regs());
> > @@ -3763,7 +3811,6 @@ static int __init setup_xmon_sysrq(void)
> > device_initcall(setup_xmon_sysrq);
> > #endif /* CONFIG_MAGIC_SYSRQ */
> >
> > -#ifdef CONFIG_DEBUG_FS
> > static void clear_all_bpt(void)
> > {
> > int i;
> > @@ -3785,8 +3832,12 @@ static void clear_all_bpt(void)
> > printf("xmon: All breakpoints cleared\n");
> > }
> >
> > +#ifdef CONFIG_DEBUG_FS
> > static int xmon_dbgfs_set(void *data, u64 val)
> > {
> > + if (xmon_check_lockdown())
> > + return 0;
> > +
> > xmon_on = !!val;
> > xmon_init(xmon_on);
> >
> > @@ -3845,6 +3896,9 @@ early_param("xmon", early_parse_xmon);
> >
> > void __init xmon_setup(void)
> > {
> > + if (xmon_check_lockdown())
> > + return;
> > +
> > if (xmon_on)
> > xmon_init(1);
> > if (xmon_early)
> >
>
> --
> Andrew Donnellan OzLabs, ADL Canberra
> ajd@linux.ibm.com IBM Australia Limited
>
^ permalink raw reply
* [PATCH v5 2/2] powerpc: Fix compile issue with force DAWR
From: Michael Neuling @ 2019-06-04 3:00 UTC (permalink / raw)
To: mpe; +Cc: Mathieu Malaterre, mikey, linuxppc-dev, hch
In-Reply-To: <20190604030037.9424-1-mikey@neuling.org>
If you compile with KVM but without CONFIG_HAVE_HW_BREAKPOINT you fail
at linking with:
arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x708): undefined reference to `dawr_force_enable'
This was caused by commit c1fe190c0672 ("powerpc: Add force enable of
DAWR on P9 option").
This moves a bunch of code around to fix this. It moves a lot of the
DAWR code in a new file and creates a new CONFIG_PPC_DAWR to enable
compiling it.
Fixes: c1fe190c0672 ("powerpc: Add force enable of DAWR on P9 option")
Signed-off-by: Michael Neuling <mikey@neuling.org>
--
v5:
- Changes based on comments by hch
- Change // to /* comments
- Change return code from -1 to -ENODEV
- Remove unneeded default n in new Kconfig option
- Remove setting to default value
- Remove unnecessary braces
v4:
- Fix merge conflict with patch from Mathieu Malaterre:
powerpc: silence a -Wcast-function-type warning in dawr_write_file_bool
- Fixed checkpatch issues noticed by Christophe Leroy.
v3:
Fixes based on Christophe Leroy's comments:
- Fix Kconfig options to better reflect reality
- Reorder alphabetically
- Inline vs #define
- Fixed default return for dawr_enabled() when CONFIG_PPC_DAWR=N
V2:
Fixes based on Christophe Leroy's comments:
- Fix commit message formatting
- Move more DAWR code into dawr.c
---
arch/powerpc/Kconfig | 4 +
arch/powerpc/include/asm/hw_breakpoint.h | 21 +++--
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/kernel/dawr.c | 98 ++++++++++++++++++++++++
arch/powerpc/kernel/hw_breakpoint.c | 61 ---------------
arch/powerpc/kernel/process.c | 28 -------
arch/powerpc/kvm/Kconfig | 1 +
7 files changed, 118 insertions(+), 96 deletions(-)
create mode 100644 arch/powerpc/kernel/dawr.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8c1c636308..9d61b36df4 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -234,6 +234,7 @@ config PPC
select OLD_SIGSUSPEND
select PCI_DOMAINS if PCI
select PCI_SYSCALL if PCI
+ select PPC_DAWR if PPC64
select RTC_LIB
select SPARSE_IRQ
select SYSCTL_EXCEPTION_TRACE
@@ -370,6 +371,9 @@ config PPC_ADV_DEBUG_DAC_RANGE
depends on PPC_ADV_DEBUG_REGS && 44x
default y
+config PPC_DAWR
+ bool
+
config ZONE_DMA
bool
default y if PPC_BOOK3E_64
diff --git a/arch/powerpc/include/asm/hw_breakpoint.h b/arch/powerpc/include/asm/hw_breakpoint.h
index 0fe8c1e46b..41abdae6d0 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -90,18 +90,25 @@ static inline void hw_breakpoint_disable(void)
extern void thread_change_pc(struct task_struct *tsk, struct pt_regs *regs);
int hw_breakpoint_handler(struct die_args *args);
-extern int set_dawr(struct arch_hw_breakpoint *brk);
+#else /* CONFIG_HAVE_HW_BREAKPOINT */
+static inline void hw_breakpoint_disable(void) { }
+static inline void thread_change_pc(struct task_struct *tsk,
+ struct pt_regs *regs) { }
+
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+
+
+#ifdef CONFIG_PPC_DAWR
extern bool dawr_force_enable;
static inline bool dawr_enabled(void)
{
return dawr_force_enable;
}
-
-#else /* CONFIG_HAVE_HW_BREAKPOINT */
-static inline void hw_breakpoint_disable(void) { }
-static inline void thread_change_pc(struct task_struct *tsk,
- struct pt_regs *regs) { }
+int set_dawr(struct arch_hw_breakpoint *brk);
+#else
static inline bool dawr_enabled(void) { return false; }
-#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+static inline int set_dawr(struct arch_hw_breakpoint *brk) { return -1; }
+#endif
+
#endif /* __KERNEL__ */
#endif /* _PPC_BOOK3S_64_HW_BREAKPOINT_H */
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 0ea6c4aa3a..56dfa7a2a6 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_PPC64) += setup_64.o sys_ppc32.o \
obj-$(CONFIG_VDSO32) += vdso32/
obj-$(CONFIG_PPC_WATCHDOG) += watchdog.o
obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
+obj-$(CONFIG_PPC_DAWR) += dawr.o
obj-$(CONFIG_PPC_BOOK3S_64) += cpu_setup_ppc970.o cpu_setup_pa6t.o
obj-$(CONFIG_PPC_BOOK3S_64) += cpu_setup_power.o
obj-$(CONFIG_PPC_BOOK3S_64) += mce.o mce_power.o
diff --git a/arch/powerpc/kernel/dawr.c b/arch/powerpc/kernel/dawr.c
new file mode 100644
index 0000000000..ae3bd6abac
--- /dev/null
+++ b/arch/powerpc/kernel/dawr.c
@@ -0,0 +1,98 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DAWR infrastructure
+ *
+ * Copyright 2019, Michael Neuling, IBM Corporation.
+ */
+
+#include <linux/types.h>
+#include <linux/export.h>
+#include <linux/fs.h>
+#include <linux/debugfs.h>
+#include <asm/debugfs.h>
+#include <asm/machdep.h>
+#include <asm/hvcall.h>
+
+bool dawr_force_enable;
+EXPORT_SYMBOL_GPL(dawr_force_enable);
+
+int set_dawr(struct arch_hw_breakpoint *brk)
+{
+ unsigned long dawr, dawrx, mrd;
+
+ dawr = brk->address;
+
+ dawrx = (brk->type & (HW_BRK_TYPE_READ | HW_BRK_TYPE_WRITE))
+ << (63 - 58);
+ dawrx |= ((brk->type & (HW_BRK_TYPE_TRANSLATE)) >> 2) << (63 - 59);
+ dawrx |= (brk->type & (HW_BRK_TYPE_PRIV_ALL)) >> 3;
+ /* dawr length is stored in field MDR bits 48:53. Matches range in
+ * doublewords (64 bits) baised by -1 eg. 0b000000=1DW and
+ * 0b111111=64DW.
+ * brk->len is in bytes.
+ * This aligns up to double word size, shifts and does the bias.
+ */
+ mrd = ((brk->len + 7) >> 3) - 1;
+ dawrx |= (mrd & 0x3f) << (63 - 53);
+
+ if (ppc_md.set_dawr)
+ return ppc_md.set_dawr(dawr, dawrx);
+ mtspr(SPRN_DAWR, dawr);
+ mtspr(SPRN_DAWRX, dawrx);
+ return 0;
+}
+
+static void set_dawr_cb(void *info)
+{
+ set_dawr(info);
+}
+
+static ssize_t dawr_write_file_bool(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct arch_hw_breakpoint null_brk = {0, 0, 0};
+ size_t rc;
+
+ /* Send error to user if they hypervisor won't allow us to write DAWR */
+ if (!dawr_force_enable &&
+ firmware_has_feature(FW_FEATURE_LPAR) &&
+ set_dawr(&null_brk) != H_SUCCESS)
+ return -ENODEV;
+
+ rc = debugfs_write_file_bool(file, user_buf, count, ppos);
+ if (rc)
+ return rc;
+
+ /* If we are clearing, make sure all CPUs have the DAWR cleared */
+ if (!dawr_force_enable)
+ smp_call_function(set_dawr_cb, &null_brk, 0);
+
+ return rc;
+}
+
+static const struct file_operations dawr_enable_fops = {
+ .read = debugfs_read_file_bool,
+ .write = dawr_write_file_bool,
+ .open = simple_open,
+ .llseek = default_llseek,
+};
+
+static int __init dawr_force_setup(void)
+{
+ if (cpu_has_feature(CPU_FTR_DAWR)) {
+ /* Don't setup sysfs file for user control on P8 */
+ dawr_force_enable = true;
+ return 0;
+ }
+
+ if (PVR_VER(mfspr(SPRN_PVR)) == PVR_POWER9) {
+ /* Turn DAWR off by default, but allow admin to turn it on */
+ debugfs_create_file_unsafe("dawr_enable_dangerous", 0600,
+ powerpc_debugfs_root,
+ &dawr_force_enable,
+ &dawr_enable_fops);
+ }
+ return 0;
+}
+arch_initcall(dawr_force_setup);
diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c
index ca3a2358b7..95605a9c9a 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -380,64 +380,3 @@ void hw_breakpoint_pmu_read(struct perf_event *bp)
{
/* TODO */
}
-
-bool dawr_force_enable;
-EXPORT_SYMBOL_GPL(dawr_force_enable);
-
-static void set_dawr_cb(void *info)
-{
- set_dawr(info);
-}
-
-static ssize_t dawr_write_file_bool(struct file *file,
- const char __user *user_buf,
- size_t count, loff_t *ppos)
-{
- struct arch_hw_breakpoint null_brk = {0, 0, 0};
- size_t rc;
-
- /* Send error to user if they hypervisor won't allow us to write DAWR */
- if ((!dawr_force_enable) &&
- (firmware_has_feature(FW_FEATURE_LPAR)) &&
- (set_dawr(&null_brk) != H_SUCCESS))
- return -1;
-
- rc = debugfs_write_file_bool(file, user_buf, count, ppos);
- if (rc)
- return rc;
-
- /* If we are clearing, make sure all CPUs have the DAWR cleared */
- if (!dawr_force_enable)
- smp_call_function(set_dawr_cb, &null_brk, 0);
-
- return rc;
-}
-
-static const struct file_operations dawr_enable_fops = {
- .read = debugfs_read_file_bool,
- .write = dawr_write_file_bool,
- .open = simple_open,
- .llseek = default_llseek,
-};
-
-static int __init dawr_force_setup(void)
-{
- dawr_force_enable = false;
-
- if (cpu_has_feature(CPU_FTR_DAWR)) {
- /* Don't setup sysfs file for user control on P8 */
- dawr_force_enable = true;
- return 0;
- }
-
- if (PVR_VER(mfspr(SPRN_PVR)) == PVR_POWER9) {
- /* Turn DAWR off by default, but allow admin to turn it on */
- dawr_force_enable = false;
- debugfs_create_file_unsafe("dawr_enable_dangerous", 0600,
- powerpc_debugfs_root,
- &dawr_force_enable,
- &dawr_enable_fops);
- }
- return 0;
-}
-arch_initcall(dawr_force_setup);
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 87da401299..03a2da35ce 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -797,34 +797,6 @@ static inline int set_dabr(struct arch_hw_breakpoint *brk)
return __set_dabr(dabr, dabrx);
}
-int set_dawr(struct arch_hw_breakpoint *brk)
-{
- unsigned long dawr, dawrx, mrd;
-
- dawr = brk->address;
-
- dawrx = (brk->type & (HW_BRK_TYPE_READ | HW_BRK_TYPE_WRITE)) \
- << (63 - 58); //* read/write bits */
- dawrx |= ((brk->type & (HW_BRK_TYPE_TRANSLATE)) >> 2) \
- << (63 - 59); //* translate */
- dawrx |= (brk->type & (HW_BRK_TYPE_PRIV_ALL)) \
- >> 3; //* PRIM bits */
- /* dawr length is stored in field MDR bits 48:53. Matches range in
- doublewords (64 bits) baised by -1 eg. 0b000000=1DW and
- 0b111111=64DW.
- brk->len is in bytes.
- This aligns up to double word size, shifts and does the bias.
- */
- mrd = ((brk->len + 7) >> 3) - 1;
- dawrx |= (mrd & 0x3f) << (63 - 53);
-
- if (ppc_md.set_dawr)
- return ppc_md.set_dawr(dawr, dawrx);
- mtspr(SPRN_DAWR, dawr);
- mtspr(SPRN_DAWRX, dawrx);
- return 0;
-}
-
void __set_breakpoint(struct arch_hw_breakpoint *brk)
{
memcpy(this_cpu_ptr(¤t_brk), brk, sizeof(*brk));
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index f53997a8ca..b8e13d5a4a 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -38,6 +38,7 @@ config KVM_BOOK3S_32_HANDLER
config KVM_BOOK3S_64_HANDLER
bool
select KVM_BOOK3S_HANDLER
+ select PPC_DAWR_FORCE_ENABLE
config KVM_BOOK3S_PR_POSSIBLE
bool
--
2.21.0
^ permalink raw reply related
* [PATCH v5 1/2] powerpc: silence a -Wcast-function-type warning in dawr_write_file_bool
From: Michael Neuling @ 2019-06-04 3:00 UTC (permalink / raw)
To: mpe; +Cc: Mathieu Malaterre, mikey, linuxppc-dev, hch
From: Mathieu Malaterre <malat@debian.org>
In commit c1fe190c0672 ("powerpc: Add force enable of DAWR on P9
option") the following piece of code was added:
smp_call_function((smp_call_func_t)set_dawr, &null_brk, 0);
Since GCC 8 this triggers the following warning about incompatible
function types:
arch/powerpc/kernel/hw_breakpoint.c:408:21: error: cast between incompatible function types from 'int (*)(struct arch_hw_breakpoint *)' to 'void (*)(void *)' [-Werror=cast-function-type]
Since the warning is there for a reason, and should not be hidden behind
a cast, provide an intermediate callback function to avoid the warning.
Fixes: c1fe190c0672 ("powerpc: Add force enable of DAWR on P9 option")
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/hw_breakpoint.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c
index da307dd93e..ca3a2358b7 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -384,6 +384,11 @@ void hw_breakpoint_pmu_read(struct perf_event *bp)
bool dawr_force_enable;
EXPORT_SYMBOL_GPL(dawr_force_enable);
+static void set_dawr_cb(void *info)
+{
+ set_dawr(info);
+}
+
static ssize_t dawr_write_file_bool(struct file *file,
const char __user *user_buf,
size_t count, loff_t *ppos)
@@ -403,7 +408,7 @@ static ssize_t dawr_write_file_bool(struct file *file,
/* If we are clearing, make sure all CPUs have the DAWR cleared */
if (!dawr_force_enable)
- smp_call_function((smp_call_func_t)set_dawr, &null_brk, 0);
+ smp_call_function(set_dawr_cb, &null_brk, 0);
return rc;
}
--
2.21.0
^ permalink raw reply related
* crash after NX error
From: Stewart Smith @ 2019-06-04 3:23 UTC (permalink / raw)
To: linuxppc-dev, haren
On my two socket POWER9 system (powernv) with 842 zwap set up, I
recently got a crash with the Ubuntu kernel (I haven't tried with
upstream, and this is the first time the system has died like this, so
I'm not sure how repeatable it is).
[ 2.891463] zswap: loaded using pool 842-nx/zbud
...
[15626.124646] nx_compress_powernv: ERROR: CSB still not valid after 5000000 us, giving up : 00 00 00 00 00000000
[16868.932913] Unable to handle kernel paging request for data at address 0x6655f67da816cdb8
[16868.933726] Faulting instruction address: 0xc000000000391600
cpu 0x68: Vector: 380 (Data Access Out of Range) at [c000001c9d98b9a0]
pc: c000000000391600: kmem_cache_alloc+0x2e0/0x340
lr: c0000000003915ec: kmem_cache_alloc+0x2cc/0x340
sp: c000001c9d98bc20
msr: 900000000280b033
dar: 6655f67da816cdb8
current = 0xc000001ad43cb400
paca = 0xc00000000fac7800 softe: 0 irq_happened: 0x01
pid = 8319, comm = make
Linux version 4.15.0-50-generic (buildd@bos02-ppc64el-006) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #54-Ubuntu SMP Mon May 6 18:55:18 UTC 2019 (Ubuntu 4.15.0-50.54-generic 4.15.18)
68:mon> t
[c000001c9d98bc20] c0000000003914d4 kmem_cache_alloc+0x1b4/0x340 (unreliable)
[c000001c9d98bc80] c0000000003b1e14 __khugepaged_enter+0x54/0x220
[c000001c9d98bcc0] c00000000010f0ec copy_process.isra.5.part.6+0xebc/0x1a10
[c000001c9d98bda0] c00000000010fe4c _do_fork+0xec/0x510
[c000001c9d98be30] c00000000000b584 ppc_clone+0x8/0xc
--- Exception: c00 (System Call) at 00007afe9daf87f4
SP (7fffca606880) is in userspace
So, it looks like there could be a problem in the error path, plausibly
fixed by this patch:
commit 656ecc16e8fc2ab44b3d70e3fcc197a7020d0ca5
Author: Haren Myneni <haren@linux.vnet.ibm.com>
Date: Wed Jun 13 00:32:40 2018 -0700
crypto/nx: Initialize 842 high and normal RxFIFO control registers
NX increments readOffset by FIFO size in receive FIFO control register
when CRB is read. But the index in RxFIFO has to match with the
corresponding entry in FIFO maintained by VAS in kernel. Otherwise NX
may be processing incorrect CRBs and can cause CRB timeout.
VAS FIFO offset is 0 when the receive window is opened during
initialization. When the module is reloaded or in kexec boot, readOffset
in FIFO control register may not match with VAS entry. This patch adds
nx_coproc_init OPAL call to reset readOffset and queued entries in FIFO
control register for both high and normal FIFOs.
Signed-off-by: Haren Myneni <haren@us.ibm.com>
[mpe: Fixup uninitialized variable warning]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
$ git describe --contains 656ecc16e8fc2ab44b3d70e3fcc197a7020d0ca5
v4.19-rc1~24^2~50
Which was never backported to any stable release, so probably needs to
be for v4.14 through v4.18. Notably, Ubuntu is on v4.15 and it doesn't
seem to have picked up the patch. I'm opening an Ubuntu bug for this.
Haren, is this something you can drive through the stable process
(assuming my above crash looks like this failure)?
--
Stewart Smith
OPAL Architect, IBM.
^ permalink raw reply
* Re: [RFC PATCH v2] powerpc/xmon: restrict when kernel is locked down
From: Andrew Donnellan @ 2019-06-04 3:28 UTC (permalink / raw)
To: Christopher M Riedl, linuxppc-dev, kernel-hardening; +Cc: mjg59, dja
In-Reply-To: <1146575236.484635.1559617524880@privateemail.com>
On 4/6/19 1:05 pm, Christopher M Riedl wrote:>>> + if (!xmon_is_ro) {
>>> + xmon_is_ro = kernel_is_locked_down("Using xmon write-access",
>>> + LOCKDOWN_INTEGRITY);
>>> + if (xmon_is_ro) {
>>> + printf("xmon: Read-only due to kernel lockdown\n");
>>> + clear_all_bpt();
>>
>> Remind me again why we need to clear breakpoints in integrity mode?
>>
>>
>> Andrew
>>
>
> I interpreted "integrity" mode as meaning that any changes made by xmon should
> be reversed. This also covers the case when a user creates some breakpoint(s)
> in xmon, exits xmon, and then elevates the lockdown state. Upon hitting the
> first breakpoint and (re-)entering xmon, xmon will clear all breakpoints.
>
> Xmon can only take action in response to dynamic lockdown level changes when
> xmon is invoked in some manner - if there is a better way I am all ears :)
>
Integrity mode merely means we are aiming to prevent modifications to
kernel memory. IMHO leaving existing breakpoints in place is fine as
long as when we hit the breakpoint xmon is in read-only mode.
(dja/mpe might have opinions on this)
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* [PATCH v2] perf ioctl: Add check for the sample_period value
From: Ravi Bangoria @ 2019-06-04 4:29 UTC (permalink / raw)
To: mpe, peterz; +Cc: Ravi Bangoria, maddy, jolsa, linux-kernel, acme, linuxppc-dev
In-Reply-To: <87h89eq55e.fsf@concordia.ellerman.id.au>
perf_event_open() limits the sample_period to 63 bits. See
commit 0819b2e30ccb ("perf: Limit perf_event_attr::sample_period
to 63 bits"). Make ioctl() consistent with it.
Also on powerpc, negative sample_period could cause a recursive
PMIs leading to a hang (reported when running perf-fuzzer).
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
---
kernel/events/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index abbd4b3b96c2..e44c90378940 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5005,6 +5005,9 @@ static int perf_event_period(struct perf_event *event, u64 __user *arg)
if (perf_event_check_period(event, value))
return -EINVAL;
+ if (!event->attr.freq && (value & (1ULL << 63)))
+ return -EINVAL;
+
event_function_call(event, __perf_event_period, &value);
return 0;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH kernel] prom_init: Fetch flatten device tree from the system firmware
From: Alexey Kardashevskiy @ 2019-06-04 5:00 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Suraj Jitindar Singh, David Gibson
In-Reply-To: <20190603234247.GQ31586@gate.crashing.org>
On 04/06/2019 09:42, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jun 03, 2019 at 12:56:26PM +1000, Alexey Kardashevskiy wrote:
>> On 03/06/2019 09:23, Segher Boessenkool wrote:
>>>> So I go for the simple one and agree with Alexey's idea.
>>>
>>> When dealing with a whole device tree you have to know about the various
>>> dynamically generated nodes and props, and handle each appropriately.
>>
>> The code I am changing fetches the device tree and build an fdt. What is
>> that special knowledge in this context you are talking about?
>
> Things like /options are dynamically generated.
Generated by the guest kernel, after walking the tree and before making
the fdt blob? I cannot see it, what do I miss? Otherwise it is all in
slof and the same result is fetched one way or another.
> I thought you would just be able to reuse some FDT parsing code to
> implement my suggested new interface. Maybe that was too optimistic.
--
Alexey
^ permalink raw reply
* [PATCH] powerpc/configs: Disable latencytop
From: Anton Blanchard @ 2019-06-04 5:42 UTC (permalink / raw)
To: paulus, mpe, npiggin, aneesh.kumar; +Cc: linuxppc-dev
latencytop adds almost 4kB to each and every task struct and as such
it doesn't deserve to be in our defconfigs.
Signed-off-by: Anton Blanchard <anton@ozlabs.org>
---
arch/powerpc/configs/g5_defconfig | 1 -
arch/powerpc/configs/gamecube_defconfig | 1 -
arch/powerpc/configs/maple_defconfig | 1 -
arch/powerpc/configs/pmac32_defconfig | 1 -
arch/powerpc/configs/powernv_defconfig | 1 -
arch/powerpc/configs/ppc64_defconfig | 1 -
arch/powerpc/configs/ppc64e_defconfig | 1 -
arch/powerpc/configs/ppc6xx_defconfig | 1 -
arch/powerpc/configs/pseries_defconfig | 1 -
arch/powerpc/configs/wii_defconfig | 1 -
10 files changed, 10 deletions(-)
diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig
index ceb3c770786f..8e9389d6c8ef 100644
--- a/arch/powerpc/configs/g5_defconfig
+++ b/arch/powerpc/configs/g5_defconfig
@@ -244,7 +244,6 @@ CONFIG_CRC_T10DIF=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_MUTEXES=y
-CONFIG_LATENCYTOP=y
CONFIG_BOOTX_TEXT=y
CONFIG_CRYPTO_TEST=m
CONFIG_CRYPTO_PCBC=m
diff --git a/arch/powerpc/configs/gamecube_defconfig b/arch/powerpc/configs/gamecube_defconfig
index 805b0f87653c..bfffdc4f1b73 100644
--- a/arch/powerpc/configs/gamecube_defconfig
+++ b/arch/powerpc/configs/gamecube_defconfig
@@ -91,7 +91,6 @@ CONFIG_CRC_CCITT=y
CONFIG_PRINTK_TIME=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
-CONFIG_LATENCYTOP=y
CONFIG_SCHED_TRACER=y
CONFIG_DMA_API_DEBUG=y
CONFIG_PPC_EARLY_DEBUG=y
diff --git a/arch/powerpc/configs/maple_defconfig b/arch/powerpc/configs/maple_defconfig
index c5f2005005d3..1c436fafb397 100644
--- a/arch/powerpc/configs/maple_defconfig
+++ b/arch/powerpc/configs/maple_defconfig
@@ -104,7 +104,6 @@ CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_STACK_USAGE=y
CONFIG_DEBUG_STACKOVERFLOW=y
-CONFIG_LATENCYTOP=y
CONFIG_XMON=y
CONFIG_XMON_DEFAULT=y
CONFIG_BOOTX_TEXT=y
diff --git a/arch/powerpc/configs/pmac32_defconfig b/arch/powerpc/configs/pmac32_defconfig
index 50b610b48914..8d632ceaea48 100644
--- a/arch/powerpc/configs/pmac32_defconfig
+++ b/arch/powerpc/configs/pmac32_defconfig
@@ -293,7 +293,6 @@ CONFIG_CRC_T10DIF=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DETECT_HUNG_TASK=y
-CONFIG_LATENCYTOP=y
CONFIG_XMON=y
CONFIG_XMON_DEFAULT=y
CONFIG_BOOTX_TEXT=y
diff --git a/arch/powerpc/configs/powernv_defconfig b/arch/powerpc/configs/powernv_defconfig
index ef2ef98d3f28..1cf8ce18b4ca 100644
--- a/arch/powerpc/configs/powernv_defconfig
+++ b/arch/powerpc/configs/powernv_defconfig
@@ -317,7 +317,6 @@ CONFIG_DEBUG_STACK_USAGE=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_SOFTLOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
-CONFIG_LATENCYTOP=y
CONFIG_FUNCTION_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_FTRACE_SYSCALLS=y
diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
index 91fdb619b484..96d695ffe074 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -367,7 +367,6 @@ CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_SOFTLOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
CONFIG_DEBUG_MUTEXES=y
-CONFIG_LATENCYTOP=y
CONFIG_FUNCTION_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
diff --git a/arch/powerpc/configs/ppc64e_defconfig b/arch/powerpc/configs/ppc64e_defconfig
index 41d85cb3c9a2..7e52d4658867 100644
--- a/arch/powerpc/configs/ppc64e_defconfig
+++ b/arch/powerpc/configs/ppc64e_defconfig
@@ -223,7 +223,6 @@ CONFIG_DEBUG_STACK_USAGE=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEBUG_MUTEXES=y
-CONFIG_LATENCYTOP=y
CONFIG_IRQSOFF_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
diff --git a/arch/powerpc/configs/ppc6xx_defconfig b/arch/powerpc/configs/ppc6xx_defconfig
index 7c6baf6df139..7bcdb4d1411c 100644
--- a/arch/powerpc/configs/ppc6xx_defconfig
+++ b/arch/powerpc/configs/ppc6xx_defconfig
@@ -1148,7 +1148,6 @@ CONFIG_FAIL_MAKE_REQUEST=y
CONFIG_FAIL_IO_TIMEOUT=y
CONFIG_FAULT_INJECTION_DEBUG_FS=y
CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y
-CONFIG_LATENCYTOP=y
CONFIG_SCHED_TRACER=y
CONFIG_STACK_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig
index 62e12f61a3b2..c8f5f281e367 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -290,7 +290,6 @@ CONFIG_DEBUG_STACK_USAGE=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_SOFTLOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
-CONFIG_LATENCYTOP=y
CONFIG_FUNCTION_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
diff --git a/arch/powerpc/configs/wii_defconfig b/arch/powerpc/configs/wii_defconfig
index f5c366b02828..d60c04a4708a 100644
--- a/arch/powerpc/configs/wii_defconfig
+++ b/arch/powerpc/configs/wii_defconfig
@@ -123,7 +123,6 @@ CONFIG_PRINTK_TIME=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
-CONFIG_LATENCYTOP=y
CONFIG_SCHED_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_DMA_API_DEBUG=y
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] PCI: rpaphp: Avoid a sometimes-uninitialized warning
From: Christophe Leroy @ 2019-06-04 6:24 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Tyrel Datwyler, linux-pci, linux-kernel, clang-built-linux,
Paul Mackerras, Bjorn Helgaas, linuxppc-dev
In-Reply-To: <20190603174323.48251-1-natechancellor@gmail.com>
Quoting Nathan Chancellor <natechancellor@gmail.com>:
> When building with -Wsometimes-uninitialized, clang warns:
>
> drivers/pci/hotplug/rpaphp_core.c:243:14: warning: variable 'fndit' is
> used uninitialized whenever 'for' loop exits because its condition is
> false [-Wsometimes-uninitialized]
> for (j = 0; j < entries; j++) {
> ^~~~~~~~~~~
> drivers/pci/hotplug/rpaphp_core.c:256:6: note: uninitialized use occurs
> here
> if (fndit)
> ^~~~~
> drivers/pci/hotplug/rpaphp_core.c:243:14: note: remove the condition if
> it is always true
> for (j = 0; j < entries; j++) {
> ^~~~~~~~~~~
> drivers/pci/hotplug/rpaphp_core.c:233:14: note: initialize the variable
> 'fndit' to silence this warning
> int j, fndit;
> ^
> = 0
>
> Looking at the loop in a vacuum as clang would, fndit could be
> uninitialized if entries was ever zero or the if statement was
> always true within the loop. Regardless of whether or not this
> warning is a problem in practice, "found" variables should always
> be initialized to false so that there is no possibility of
> undefined behavior.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/504
> Fixes: 2fcf3ae508c2 ("hotplug/drc-info: Add code to search
> ibm,drc-info property")
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> drivers/pci/hotplug/rpaphp_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/hotplug/rpaphp_core.c
> b/drivers/pci/hotplug/rpaphp_core.c
> index bcd5d357ca23..07b56bf2886f 100644
> --- a/drivers/pci/hotplug/rpaphp_core.c
> +++ b/drivers/pci/hotplug/rpaphp_core.c
> @@ -230,7 +230,7 @@ static int rpaphp_check_drc_props_v2(struct
> device_node *dn, char *drc_name,
> struct of_drc_info drc;
> const __be32 *value;
> char cell_drc_name[MAX_DRC_NAME_LEN];
> - int j, fndit;
> + int j, fndit = 0;
Not sure fndit is needed at all. Looking into the full function code,
fndit only serves as doing a single action. That action could be done
in the loop directly, see below
And while you are at it, I guess you should also handle the
initialisation of cell_drc_name.
In the current code, it looks like content of cell_drc_name is
undefined when doing the strcmp when fndit is not 1.
>
> info = of_find_property(dn->parent, "ibm,drc-info", NULL);
> if (info == NULL)
> --
> 2.22.0.rc2
diff --git a/drivers/pci/hotplug/rpaphp_core.c
b/drivers/pci/hotplug/rpaphp_core.c
index bcd5d357ca23..87113419a44f 100644
--- a/drivers/pci/hotplug/rpaphp_core.c
+++ b/drivers/pci/hotplug/rpaphp_core.c
@@ -230,7 +230,7 @@ static int rpaphp_check_drc_props_v2(struct
device_node *dn, char *drc_name,
struct of_drc_info drc;
const __be32 *value;
char cell_drc_name[MAX_DRC_NAME_LEN];
- int j, fndit;
+ int j;
info = of_find_property(dn->parent, "ibm,drc-info", NULL);
if (info == NULL)
@@ -248,14 +248,10 @@ static int rpaphp_check_drc_props_v2(struct
device_node *dn, char *drc_name,
if (my_index > drc.last_drc_index)
continue;
- fndit = 1;
+ /* Found it */
+ sprintf(cell_drc_name, "%s%d", drc.drc_name_prefix, my_index);
break;
}
- /* Found it */
-
- if (fndit)
- sprintf(cell_drc_name, "%s%d", drc.drc_name_prefix,
- my_index);
if (((drc_name == NULL) ||
(drc_name && !strcmp(drc_name, cell_drc_name))) &&
Christophe
^ permalink raw reply related
* [RFC V2] mm: Generalize notify_page_fault()
From: Anshuman Khandual @ 2019-06-04 6:34 UTC (permalink / raw)
To: linux-kernel, linux-mm
Cc: Mark Rutland, Michal Hocko, linux-ia64, linux-sh, Peter Zijlstra,
Catalin Marinas, Dave Hansen, Will Deacon, Paul Mackerras,
sparclinux, Stephen Rothwell, linux-s390, Yoshinori Sato, x86,
Russell King, Matthew Wilcox, Ingo Molnar, Fenghua Yu,
Anshuman Khandual, Andrey Konovalov, Andy Lutomirski,
Thomas Gleixner, linux-arm-kernel, Tony Luck, Heiko Carstens,
Martin Schwidefsky, Andrew Morton, linuxppc-dev, David S. Miller
Similar notify_page_fault() definitions are being used by architectures
duplicating much of the same code. This attempts to unify them into a
single implementation, generalize it and then move it to a common place.
kprobes_built_in() can detect CONFIG_KPROBES, hence notify_page_fault()
need not be wrapped again within CONFIG_KPROBES. Trap number argument can
now contain upto an 'unsigned int' accommodating all possible platforms.
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-ia64@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s390@vger.kernel.org
Cc: linux-sh@vger.kernel.org
Cc: sparclinux@vger.kernel.org
Cc: x86@kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
Testing:
- Build and boot tested on arm64 and x86
- Build tested on some other archs (arm, sparc64, alpha, powerpc etc)
Changes in RFC V2:
- Changed generic notify_page_fault() per Mathew Wilcox
- Changed x86 to use new generic notify_page_fault()
- s/must not/need not/ in commit message per Matthew Wilcox
Changes in RFC V1: (https://patchwork.kernel.org/patch/10968273/)
arch/arm/mm/fault.c | 22 ----------------------
arch/arm64/mm/fault.c | 22 ----------------------
arch/ia64/mm/fault.c | 22 ----------------------
arch/powerpc/mm/fault.c | 23 ++---------------------
arch/s390/mm/fault.c | 16 +---------------
arch/sh/mm/fault.c | 14 --------------
arch/sparc/mm/fault_64.c | 16 +---------------
arch/x86/mm/fault.c | 21 ++-------------------
include/linux/mm.h | 1 +
mm/memory.c | 16 ++++++++++++++++
10 files changed, 23 insertions(+), 150 deletions(-)
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 58f69fa..1bc3b18 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -30,28 +30,6 @@
#ifdef CONFIG_MMU
-#ifdef CONFIG_KPROBES
-static inline int notify_page_fault(struct pt_regs *regs, unsigned int fsr)
-{
- int ret = 0;
-
- if (!user_mode(regs)) {
- /* kprobe_running() needs smp_processor_id() */
- preempt_disable();
- if (kprobe_running() && kprobe_fault_handler(regs, fsr))
- ret = 1;
- preempt_enable();
- }
-
- return ret;
-}
-#else
-static inline int notify_page_fault(struct pt_regs *regs, unsigned int fsr)
-{
- return 0;
-}
-#endif
-
/*
* This is useful to dump out the page tables associated with
* 'addr' in mm 'mm'.
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index a30818e..152f1f1 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -70,28 +70,6 @@ static inline const struct fault_info *esr_to_debug_fault_info(unsigned int esr)
return debug_fault_info + DBG_ESR_EVT(esr);
}
-#ifdef CONFIG_KPROBES
-static inline int notify_page_fault(struct pt_regs *regs, unsigned int esr)
-{
- int ret = 0;
-
- /* kprobe_running() needs smp_processor_id() */
- if (!user_mode(regs)) {
- preempt_disable();
- if (kprobe_running() && kprobe_fault_handler(regs, esr))
- ret = 1;
- preempt_enable();
- }
-
- return ret;
-}
-#else
-static inline int notify_page_fault(struct pt_regs *regs, unsigned int esr)
-{
- return 0;
-}
-#endif
-
static void data_abort_decode(unsigned int esr)
{
pr_alert("Data abort info:\n");
diff --git a/arch/ia64/mm/fault.c b/arch/ia64/mm/fault.c
index 5baeb02..64283d2 100644
--- a/arch/ia64/mm/fault.c
+++ b/arch/ia64/mm/fault.c
@@ -21,28 +21,6 @@
extern int die(char *, struct pt_regs *, long);
-#ifdef CONFIG_KPROBES
-static inline int notify_page_fault(struct pt_regs *regs, int trap)
-{
- int ret = 0;
-
- if (!user_mode(regs)) {
- /* kprobe_running() needs smp_processor_id() */
- preempt_disable();
- if (kprobe_running() && kprobe_fault_handler(regs, trap))
- ret = 1;
- preempt_enable();
- }
-
- return ret;
-}
-#else
-static inline int notify_page_fault(struct pt_regs *regs, int trap)
-{
- return 0;
-}
-#endif
-
/*
* Return TRUE if ADDRESS points at a page in the kernel's mapped segment
* (inside region 5, on ia64) and that page is present.
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index b5d3578..5a0d71f 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -46,26 +46,6 @@
#include <asm/debug.h>
#include <asm/kup.h>
-static inline bool notify_page_fault(struct pt_regs *regs)
-{
- bool ret = false;
-
-#ifdef CONFIG_KPROBES
- /* kprobe_running() needs smp_processor_id() */
- if (!user_mode(regs)) {
- preempt_disable();
- if (kprobe_running() && kprobe_fault_handler(regs, 11))
- ret = true;
- preempt_enable();
- }
-#endif /* CONFIG_KPROBES */
-
- if (unlikely(debugger_fault_handler(regs)))
- ret = true;
-
- return ret;
-}
-
/*
* Check whether the instruction inst is a store using
* an update addressing form which will update r1.
@@ -466,8 +446,9 @@ static int __do_page_fault(struct pt_regs *regs, unsigned long address,
int is_write = page_fault_is_write(error_code);
vm_fault_t fault, major = 0;
bool must_retry = false;
+ int kprobe_fault = notify_page_fault(regs, 11);
- if (notify_page_fault(regs))
+ if (unlikely(debugger_fault_handler(regs) || kprobe_fault))
return 0;
if (unlikely(page_fault_is_bad(error_code))) {
diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
index c220399..d317263 100644
--- a/arch/s390/mm/fault.c
+++ b/arch/s390/mm/fault.c
@@ -67,20 +67,6 @@ static int __init fault_init(void)
}
early_initcall(fault_init);
-static inline int notify_page_fault(struct pt_regs *regs)
-{
- int ret = 0;
-
- /* kprobe_running() needs smp_processor_id() */
- if (kprobes_built_in() && !user_mode(regs)) {
- preempt_disable();
- if (kprobe_running() && kprobe_fault_handler(regs, 14))
- ret = 1;
- preempt_enable();
- }
- return ret;
-}
-
/*
* Find out which address space caused the exception.
* Access register mode is impossible, ignore space == 3.
@@ -409,7 +395,7 @@ static inline vm_fault_t do_exception(struct pt_regs *regs, int access)
*/
clear_pt_regs_flag(regs, PIF_PER_TRAP);
- if (notify_page_fault(regs))
+ if (notify_page_fault(regs, 14))
return 0;
mm = tsk->mm;
diff --git a/arch/sh/mm/fault.c b/arch/sh/mm/fault.c
index 6defd2c6..94bdfcb 100644
--- a/arch/sh/mm/fault.c
+++ b/arch/sh/mm/fault.c
@@ -24,20 +24,6 @@
#include <asm/tlbflush.h>
#include <asm/traps.h>
-static inline int notify_page_fault(struct pt_regs *regs, int trap)
-{
- int ret = 0;
-
- if (kprobes_built_in() && !user_mode(regs)) {
- preempt_disable();
- if (kprobe_running() && kprobe_fault_handler(regs, trap))
- ret = 1;
- preempt_enable();
- }
-
- return ret;
-}
-
static void
force_sig_info_fault(int si_signo, int si_code, unsigned long address,
struct task_struct *tsk)
diff --git a/arch/sparc/mm/fault_64.c b/arch/sparc/mm/fault_64.c
index 8f8a604..e5557a1 100644
--- a/arch/sparc/mm/fault_64.c
+++ b/arch/sparc/mm/fault_64.c
@@ -38,20 +38,6 @@
int show_unhandled_signals = 1;
-static inline __kprobes int notify_page_fault(struct pt_regs *regs)
-{
- int ret = 0;
-
- /* kprobe_running() needs smp_processor_id() */
- if (kprobes_built_in() && !user_mode(regs)) {
- preempt_disable();
- if (kprobe_running() && kprobe_fault_handler(regs, 0))
- ret = 1;
- preempt_enable();
- }
- return ret;
-}
-
static void __kprobes unhandled_fault(unsigned long address,
struct task_struct *tsk,
struct pt_regs *regs)
@@ -285,7 +271,7 @@ asmlinkage void __kprobes do_sparc64_fault(struct pt_regs *regs)
fault_code = get_thread_fault_code();
- if (notify_page_fault(regs))
+ if (notify_page_fault(regs, 0))
goto exit_exception;
si_code = SEGV_MAPERR;
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 46df4c6..1790859 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -46,23 +46,6 @@ kmmio_fault(struct pt_regs *regs, unsigned long addr)
return 0;
}
-static nokprobe_inline int kprobes_fault(struct pt_regs *regs)
-{
- if (!kprobes_built_in())
- return 0;
- if (user_mode(regs))
- return 0;
- /*
- * To be potentially processing a kprobe fault and to be allowed to call
- * kprobe_running(), we have to be non-preemptible.
- */
- if (preemptible())
- return 0;
- if (!kprobe_running())
- return 0;
- return kprobe_fault_handler(regs, X86_TRAP_PF);
-}
-
/*
* Prefetch quirks:
*
@@ -1280,7 +1263,7 @@ do_kern_addr_fault(struct pt_regs *regs, unsigned long hw_error_code,
return;
/* kprobes don't want to hook the spurious faults: */
- if (kprobes_fault(regs))
+ if (notify_page_fault(regs, X86_TRAP_PF))
return;
/*
@@ -1311,7 +1294,7 @@ void do_user_addr_fault(struct pt_regs *regs,
mm = tsk->mm;
/* kprobes don't want to hook the spurious faults: */
- if (unlikely(kprobes_fault(regs)))
+ if (unlikely(notify_page_fault(regs, X86_TRAP_PF)))
return;
/*
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0e8834a..c5a8dcf 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1778,6 +1778,7 @@ static inline int pte_devmap(pte_t pte)
}
#endif
+int notify_page_fault(struct pt_regs *regs, unsigned int trap);
int vma_wants_writenotify(struct vm_area_struct *vma, pgprot_t vm_page_prot);
extern pte_t *__get_locked_pte(struct mm_struct *mm, unsigned long addr,
diff --git a/mm/memory.c b/mm/memory.c
index ddf20bd..b6bae8f 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -52,6 +52,7 @@
#include <linux/pagemap.h>
#include <linux/memremap.h>
#include <linux/ksm.h>
+#include <linux/kprobes.h>
#include <linux/rmap.h>
#include <linux/export.h>
#include <linux/delayacct.h>
@@ -141,6 +142,21 @@ static int __init init_zero_pfn(void)
core_initcall(init_zero_pfn);
+int __kprobes notify_page_fault(struct pt_regs *regs, unsigned int trap)
+{
+ int ret = 0;
+
+ /*
+ * To be potentially processing a kprobe fault and to be allowed
+ * to call kprobe_running(), we have to be non-preemptible.
+ */
+ if (kprobes_built_in() && !preemptible() && !user_mode(regs)) {
+ if (kprobe_running() && kprobe_fault_handler(regs, trap))
+ ret = 1;
+ }
+ return ret;
+}
+
#if defined(SPLIT_RSS_COUNTING)
void sync_mm_rss(struct mm_struct *mm)
--
2.7.4
^ permalink raw reply related
* Re: [RFC V2] mm: Generalize notify_page_fault()
From: Peter Zijlstra @ 2019-06-04 6:54 UTC (permalink / raw)
To: Anshuman Khandual
Cc: Mark Rutland, Michal Hocko, linux-ia64, linux-sh, Catalin Marinas,
Dave Hansen, Will Deacon, linux-mm, Paul Mackerras, sparclinux,
linux-s390, Yoshinori Sato, x86, Russell King, Matthew Wilcox,
Ingo Molnar, Fenghua Yu, Stephen Rothwell, Andrey Konovalov,
Andy Lutomirski, Thomas Gleixner, linux-arm-kernel, Tony Luck,
Heiko Carstens, linux-kernel, Martin Schwidefsky, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <1559630046-12940-1-git-send-email-anshuman.khandual@arm.com>
On Tue, Jun 04, 2019 at 12:04:06PM +0530, Anshuman Khandual wrote:
> diff --git a/mm/memory.c b/mm/memory.c
> index ddf20bd..b6bae8f 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -52,6 +52,7 @@
> #include <linux/pagemap.h>
> #include <linux/memremap.h>
> #include <linux/ksm.h>
> +#include <linux/kprobes.h>
> #include <linux/rmap.h>
> #include <linux/export.h>
> #include <linux/delayacct.h>
> @@ -141,6 +142,21 @@ static int __init init_zero_pfn(void)
> core_initcall(init_zero_pfn);
>
>
> +int __kprobes notify_page_fault(struct pt_regs *regs, unsigned int trap)
> +{
> + int ret = 0;
> +
> + /*
> + * To be potentially processing a kprobe fault and to be allowed
> + * to call kprobe_running(), we have to be non-preemptible.
> + */
> + if (kprobes_built_in() && !preemptible() && !user_mode(regs)) {
> + if (kprobe_running() && kprobe_fault_handler(regs, trap))
> + ret = 1;
> + }
> + return ret;
> +}
That thing should be called kprobe_page_fault() or something,
notify_page_fault() is a horribly crap name for this function.
^ permalink raw reply
* Re: [PATCH v3 04/11] arm64/mm: Add temporary arch_remove_memory() implementation
From: David Hildenbrand @ 2019-06-04 6:56 UTC (permalink / raw)
To: Wei Yang
Cc: Mark Rutland, linux-s390, linux-ia64, Yu Zhao, Anshuman Khandual,
linux-sh, Catalin Marinas, Ard Biesheuvel, Will Deacon,
linux-kernel, Mike Rapoport, Jun Yao, linux-mm, Chintan Pandya,
Igor Mammedov, akpm, linuxppc-dev, Dan Williams, linux-arm-kernel,
Robin Murphy
In-Reply-To: <20190603214139.mercn5hol2yyfl2s@master>
On 03.06.19 23:41, Wei Yang wrote:
> On Mon, May 27, 2019 at 01:11:45PM +0200, David Hildenbrand wrote:
>> A proper arch_remove_memory() implementation is on its way, which also
>> cleanly removes page tables in arch_add_memory() in case something goes
>> wrong.
>
> Would this be better to understand?
>
> removes page tables created in arch_add_memory
That's not what this sentence expresses. Have a look at
arch_add_memory(), in case __add_pages() fails, the page tables are not
removed. This will also be fixed by Anshuman in the same shot.
>
>>
>> As we want to use arch_remove_memory() in case something goes wrong
>> during memory hotplug after arch_add_memory() finished, let's add
>> a temporary hack that is sufficient enough until we get a proper
>> implementation that cleans up page table entries.
>>
>> We will remove CONFIG_MEMORY_HOTREMOVE around this code in follow up
>> patches.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Cc: Chintan Pandya <cpandya@codeaurora.org>
>> Cc: Mike Rapoport <rppt@linux.ibm.com>
>> Cc: Jun Yao <yaojun8558363@gmail.com>
>> Cc: Yu Zhao <yuzhao@google.com>
>> Cc: Robin Murphy <robin.murphy@arm.com>
>> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
>> Signed-off-by: David Hildenbrand <david@redhat.com>
>> ---
>> arch/arm64/mm/mmu.c | 19 +++++++++++++++++++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index a1bfc4413982..e569a543c384 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -1084,4 +1084,23 @@ int arch_add_memory(int nid, u64 start, u64 size,
>> return __add_pages(nid, start >> PAGE_SHIFT, size >> PAGE_SHIFT,
>> restrictions);
>> }
>> +#ifdef CONFIG_MEMORY_HOTREMOVE
>> +void arch_remove_memory(int nid, u64 start, u64 size,
>> + struct vmem_altmap *altmap)
>> +{
>> + unsigned long start_pfn = start >> PAGE_SHIFT;
>> + unsigned long nr_pages = size >> PAGE_SHIFT;
>> + struct zone *zone;
>> +
>> + /*
>> + * FIXME: Cleanup page tables (also in arch_add_memory() in case
>> + * adding fails). Until then, this function should only be used
>> + * during memory hotplug (adding memory), not for memory
>> + * unplug. ARCH_ENABLE_MEMORY_HOTREMOVE must not be
>> + * unlocked yet.
>> + */
>> + zone = page_zone(pfn_to_page(start_pfn));
>
> Compared with arch_remove_memory in x86. If altmap is not NULL, zone will be
> retrieved from page related to altmap. Not sure why this is not the same?
This is a minimal implementation, sufficient for this use case here. A
full implementation is in the works. For now, this function will not be
used with an altmap (ZONE_DEVICE is not esupported for arm64 yet).
Thanks!
>
>> + __remove_pages(zone, start_pfn, nr_pages, altmap);
>> +}
>> +#endif
>> #endif
>> --
>> 2.20.1
>
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v3 05/11] drivers/base/memory: Pass a block_id to init_memory_block()
From: David Hildenbrand @ 2019-06-04 6:56 UTC (permalink / raw)
To: Wei Yang
Cc: linux-s390, linux-ia64, linux-sh, Greg Kroah-Hartman,
Rafael J. Wysocki, linux-kernel, linux-mm, Igor Mammedov, akpm,
linuxppc-dev, Dan Williams, linux-arm-kernel
In-Reply-To: <20190603214932.3xsvxwiiutcve4tz@master>
On 03.06.19 23:49, Wei Yang wrote:
> On Mon, May 27, 2019 at 01:11:46PM +0200, David Hildenbrand wrote:
>> We'll rework hotplug_memory_register() shortly, so it no longer consumes
>> pass a section.
>>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
>> Signed-off-by: David Hildenbrand <david@redhat.com>
>> ---
>> drivers/base/memory.c | 15 +++++++--------
>> 1 file changed, 7 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
>> index f180427e48f4..f914fa6fe350 100644
>> --- a/drivers/base/memory.c
>> +++ b/drivers/base/memory.c
>> @@ -651,21 +651,18 @@ int register_memory(struct memory_block *memory)
>> return ret;
>> }
>>
>> -static int init_memory_block(struct memory_block **memory,
>> - struct mem_section *section, unsigned long state)
>> +static int init_memory_block(struct memory_block **memory, int block_id,
>> + unsigned long state)
>> {
>> struct memory_block *mem;
>> unsigned long start_pfn;
>> - int scn_nr;
>> int ret = 0;
>>
>> mem = kzalloc(sizeof(*mem), GFP_KERNEL);
>> if (!mem)
>> return -ENOMEM;
>>
>> - scn_nr = __section_nr(section);
>> - mem->start_section_nr =
>> - base_memory_block_id(scn_nr) * sections_per_block;
>> + mem->start_section_nr = block_id * sections_per_block;
>> mem->end_section_nr = mem->start_section_nr + sections_per_block - 1;
>> mem->state = state;
>> start_pfn = section_nr_to_pfn(mem->start_section_nr);
>> @@ -694,7 +691,8 @@ static int add_memory_block(int base_section_nr)
>>
>> if (section_count == 0)
>> return 0;
>> - ret = init_memory_block(&mem, __nr_to_section(section_nr), MEM_ONLINE);
>> + ret = init_memory_block(&mem, base_memory_block_id(base_section_nr),
>> + MEM_ONLINE);
>
> If my understanding is correct, section_nr could be removed too.
Yes you are, this has already been addressed in linux-next.
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v3 06/11] mm/memory_hotplug: Allow arch_remove_pages() without CONFIG_MEMORY_HOTREMOVE
From: David Hildenbrand @ 2019-06-04 6:59 UTC (permalink / raw)
To: Wei Yang
Cc: Oscar Salvador, Rich Felker, linux-ia64, Anshuman Khandual,
linux-sh, Peter Zijlstra, Dave Hansen, Heiko Carstens, Arun KS,
Chris Wilson, linux-mm, Michal Hocko, Paul Mackerras,
H. Peter Anvin, Thomas Gleixner, Qian Cai, linux-s390,
Yoshinori Sato, Rafael J. Wysocki, Mike Rapoport, Ingo Molnar,
Fenghua Yu, Pavel Tatashin, Vasily Gorbik, Rob Herring,
mike.travis@hpe.com, Nicholas Piggin, Alex Deucher, Mark Brown,
Borislav Petkov, Andy Lutomirski, Dan Williams, linux-arm-kernel,
Tony Luck, Baoquan He, Masahiro Yamada, Mathieu Malaterre,
Greg Kroah-Hartman, Andrew Banman, linux-kernel, Logan Gunthorpe,
Wei Yang, Martin Schwidefsky, Igor Mammedov, akpm, linuxppc-dev,
David S. Miller, Kirill A. Shutemov
In-Reply-To: <20190603221540.bvhuvltlwuirm5sl@master>
On 04.06.19 00:15, Wei Yang wrote:
> Allow arch_remove_pages() or arch_remove_memory()?
Looks like I merged __remove_pages() and arch_remove_memory().
@Andrew, can you fix this up to
"mm/memory_hotplug: Allow arch_remove_memory() without
CONFIG_MEMORY_HOTREMOVE"
? Thanks!
>
> And want to confirm the kernel build on affected arch succeed?
I compile-tested on s390x and x86. As the patches are in linux-next for
some time, I think the other builds are also fine.
Thanks!
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: remove asm-generic/ptrace.h v2
From: Christoph Hellwig @ 2019-06-04 7:02 UTC (permalink / raw)
To: Oleg Nesterov, Arnd Bergmann
Cc: linux-arch, linux-sh, x86, linux-mips, linux-kernel, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20190520060018.25569-1-hch@lst.de>
Is anyone going to pick this series up?
On Mon, May 20, 2019 at 08:00:13AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> asm-generic/ptrace.h is a little weird in that it doesn't actually
> implement any functionality, but it provided multiple layers of macros
> that just implement trivial inline functions. We implement those
> directly in the few architectures and be off with a much simpler
> design.
>
> Changes since v1:
> - add a missing empty line between functions
---end quoted text---
^ permalink raw reply
* RE: [PATCH v4 1/3] PM: wakeup: Add routine to help fetch wakeup source object.
From: Ran Wang @ 2019-06-04 7:06 UTC (permalink / raw)
To: Ran Wang, Leo Li, Rob Herring, Mark Rutland, Pavel Machek,
Rafael J . Wysocki, Greg Kroah-Hartman, Len Brown
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org
In-Reply-To: <20190520095238.29210-1-ran.wang_1@nxp.com>
Hi Sirs,
Could anyone please comment this patch set or tell me if I have missed
maintainer in mail list? I'd like to let review process move forward.
Thank you.
Regards,
Ran
On Monday, May 20, 2019 17:53 Ran Wang wrote:
>
> 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. And is user's responsibility to identify if this wakeup source he is
> interested in.
>
> Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> ---
> Change in v4:
> - None.
>
> Change in v3:
> - Adjust indentation of *attached_dev;.
>
> Change in v2:
> - None.
>
> drivers/base/power/wakeup.c | 18 ++++++++++++++++++
> include/linux/pm_wakeup.h | 3 +++
> 2 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c index
> 5b2b6a0..6904485 100644
> --- a/drivers/base/power/wakeup.c
> +++ b/drivers/base/power/wakeup.c
> @@ -14,6 +14,7 @@
> #include <linux/suspend.h>
> #include <linux/seq_file.h>
> #include <linux/debugfs.h>
> +#include <linux/of_device.h>
> #include <linux/pm_wakeirq.h>
> #include <trace/events/power.h>
>
> @@ -226,6 +227,22 @@ void wakeup_source_unregister(struct wakeup_source
> *ws)
> }
> }
> EXPORT_SYMBOL_GPL(wakeup_source_unregister);
> +/**
> + * wakeup_source_get_next - Get next wakeup source from the list
> + * @ws: Previous wakeup source object, null means caller want first one.
> + */
> +struct wakeup_source *wakeup_source_get_next(struct wakeup_source *ws)
> +{
> + struct list_head *ws_head = &wakeup_sources;
> +
> + if (ws)
> + return list_next_or_null_rcu(ws_head, &ws->entry,
> + struct wakeup_source, entry);
> + else
> + return list_entry_rcu(ws_head->next,
> + struct wakeup_source, entry);
> +}
> +EXPORT_SYMBOL_GPL(wakeup_source_get_next);
>
> /**
> * device_wakeup_attach - Attach a wakeup source object to a device object.
> @@ -242,6 +259,7 @@ static int device_wakeup_attach(struct device *dev,
> struct wakeup_source *ws)
> return -EEXIST;
> }
> dev->power.wakeup = ws;
> + ws->attached_dev = dev;
> if (dev->power.wakeirq)
> device_wakeup_attach_irq(dev, dev->power.wakeirq);
> spin_unlock_irq(&dev->power.lock);
> diff --git a/include/linux/pm_wakeup.h b/include/linux/pm_wakeup.h index
> 0ff134d..913b2fb 100644
> --- a/include/linux/pm_wakeup.h
> +++ b/include/linux/pm_wakeup.h
> @@ -50,6 +50,7 @@
> * @wakeup_count: Number of times the wakeup source might abort suspend.
> * @active: Status of the wakeup source.
> * @has_timeout: The wakeup source has been activated with a timeout.
> + * @attached_dev: The device it attached to
> */
> struct wakeup_source {
> const char *name;
> @@ -70,6 +71,7 @@ struct wakeup_source {
> unsigned long wakeup_count;
> bool active:1;
> bool autosleep_enabled:1;
> + struct device *attached_dev;
> };
>
> #ifdef CONFIG_PM_SLEEP
> @@ -101,6 +103,7 @@ static inline void device_set_wakeup_path(struct device
> *dev) extern void wakeup_source_remove(struct wakeup_source *ws); extern
> struct wakeup_source *wakeup_source_register(const char *name); extern
> void wakeup_source_unregister(struct wakeup_source *ws);
> +extern struct wakeup_source *wakeup_source_get_next(struct
> +wakeup_source *ws);
> extern int device_wakeup_enable(struct device *dev); extern int
> device_wakeup_disable(struct device *dev); extern void
> device_set_wakeup_capable(struct device *dev, bool capable);
> --
> 1.7.1
^ permalink raw reply
* Re: [PATCH 03/16] mm: simplify gup_fast_permitted
From: Christoph Hellwig @ 2019-06-04 7:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rich Felker, Yoshinori Sato, Linux-sh list, James Hogan,
the arch/x86 maintainers, Khalid Aziz, Nicholas Piggin,
David S. Miller, Linux-MM, Paul Burton, Paul Mackerras,
Andrey Konovalov, sparclinux, linux-mips, linuxppc-dev,
Christoph Hellwig, Linux List Kernel Mailing
In-Reply-To: <CAHk-=wjU3ycY2FvhKmYmOTi95L0qSi9Hj+yrzWTAWepW-zdBOA@mail.gmail.com>
On Mon, Jun 03, 2019 at 10:02:10AM -0700, Linus Torvalds wrote:
> On Mon, Jun 3, 2019 at 9:08 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > The new code has no test at all for "nr_pages == 0", afaik.
>
> Note that it really is important to check for that, because right now we do
True. The 0 check got lost. I'll make sure we do the right thing for
the next version.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox