* [Bug 203571] Allow use of SIMD in interrupts on PowerPC
From: bugzilla-daemon @ 2019-05-13 12:39 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203571-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203571
--- Comment #2 from Shawn Landden (slandden@gmail.com) ---
X86 manages to allow SIMD in interrupts through some very careful code in
arch/x86/kernel/fpu/core.c (starting with irq_fpu_usable())
PowerPC can do the same.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH] vsprintf: Do not break early boot with probing addresses
From: Petr Mladek @ 2019-05-13 12:24 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-arch, linux-s390, Sergey Senozhatsky, Heiko Carstens,
Stephen Rothwell, linuxppc-dev, Rasmus Villemoes, linux-kernel,
Michal Hocko, Sergey Senozhatsky, Martin Schwidefsky,
Andy Shevchenko, Linus Torvalds, Tobin C . Harding
In-Reply-To: <20190510124058.0d44b441@gandalf.local.home>
On Fri 2019-05-10 12:40:58, Steven Rostedt wrote:
> On Fri, 10 May 2019 18:32:58 +0200
> Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:
>
> > On Fri, 10 May 2019 12:24:01 -0400
> > Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > > On Fri, 10 May 2019 10:42:13 +0200
> > > Petr Mladek <pmladek@suse.com> wrote:
> > >
> > > > static const char *check_pointer_msg(const void *ptr)
> > > > {
> > > > - char byte;
> > > > -
> > > > if (!ptr)
> > > > return "(null)";
> > > >
> > > > - if (probe_kernel_address(ptr, byte))
> > > > + if ((unsigned long)ptr < PAGE_SIZE || IS_ERR_VALUE(ptr))
> > > > return "(efault)";
> > > >
> > >
> > >
> > > < PAGE_SIZE ?
> > >
> > > do you mean: < TASK_SIZE ?
> >
> > The check with < TASK_SIZE would break on s390. The 'ptr' is
> > in the kernel address space, *not* in the user address space.
> > Remember s390 has two separate address spaces for kernel/user
> > the check < TASK_SIZE only makes sense with a __user pointer.
> >
>
> So we allow this to read user addresses? Can't that cause a fault?
I did some quick check and did not found anywhere a user pointer
being dereferenced via vsprintf().
In each case, %s did the check (ptr < PAGE_SIZE) even before this
patchset. The other checks are in %p format modifiers that are
used to print various kernel structures.
Finally, it accesses the pointer directly. I am not completely sure
but I think that it would not work that easily with an address
from the user address space.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
From: Christoph Hellwig @ 2019-05-13 12:04 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: linux-arch, Arnd Bergmann, linuxppc-dev,
Linux Kernel Mailing List, Andrew Donnellan, Nick Kossifidis,
Andrew Morton, Linus Torvalds, Christoph Hellwig
In-Reply-To: <CACT4Y+YT52wGuARxe9RqUsMYGNZTwaBowWWUUawyqTBq4G1NDg@mail.gmail.com>
On Mon, May 13, 2019 at 01:50:19PM +0200, Dmitry Vyukov wrote:
> > We did have some bugs in the past (~1-2 y/ago) but AFAIK they are all
> > fixed now. These days I build most of my kernels with a bi-endian 64-bit
> > toolchain, and switching endian without running `make clean` also works.
>
> For the record, yes, it turn out to be a problem in our code (a latent
> bug). We actually used host (x86) gcc to build as-if ppc code that can
> run on the host, so it defined neither LE no BE macros. It just
> happened to work in the past :)
So Nick was right and these checks actually are useful..
^ permalink raw reply
* Re: [PATCH RESEND] powerpc: add simd.h implementation specific to PowerPC
From: Michael Ellerman @ 2019-05-13 11:53 UTC (permalink / raw)
To: Shawn Landden, linuxppc-dev; +Cc: Shawn Landden, Paul Mackerras, linux-kernel
In-Reply-To: <20190513005104.20140-1-shawn@git.icu>
Shawn Landden <shawn@git.icu> writes:
> It is safe to do SIMD in an interrupt on PowerPC.
No it's not sorry :)
> Only disable when there is no SIMD available
> (and this is a static branch).
>
> Tested and works with the WireGuard (Zinc) patch I wrote that needs this.
> Also improves performance of the crypto subsystem that checks this.
>
> Re-sending because this linuxppc-dev didn't seem to accept it.
It did but you were probably moderated as a non-subscriber? In future if
you just wait a while for the moderators to wake up it should come
through. Though having posted once and been approved I think you might
not get moderated at all in future (?).
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203571
> Signed-off-by: Shawn Landden <shawn@git.icu>
> ---
> arch/powerpc/include/asm/simd.h | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
> create mode 100644 arch/powerpc/include/asm/simd.h
>
> diff --git a/arch/powerpc/include/asm/simd.h b/arch/powerpc/include/asm/simd.h
> new file mode 100644
> index 000000000..b3fecb95a
> --- /dev/null
> +++ b/arch/powerpc/include/asm/simd.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +
> +#include <asm/cpu_has_feature.h>
> +
> +/*
> + * may_use_simd - whether it is allowable at this time to issue SIMD
> + * instructions or access the SIMD register file
> + *
> + * As documented in Chapter 6.2.1 Machine Status Save/Restore Registers
> + * of Power ISA (2.07 and 3.0), all registers are saved/restored in an interrupt.
I think the confusion here is that the ISA says:
When various interrupts occur, the state of the machine is saved in the
Machine Status Save/Restore registers (SRR0 and SRR1).
And you've read that to mean all "the state" of the machine, ie.
including GPRs, FPRs etc.
But unfortunately it's not that simple. All the hardware does is write
two 64-bit registers (SRR0 & SRR1) with the information required to be
able to return to the state the CPU was in prior to the interrupt. That
includes (obviously) the PC you were executing at, and what state the
CPU was in (ie. 64/32-bit, MMU on/off, FP on/off etc.). All the saving
of registers etc. is left up to software. It's the RISC way :)
I guess we need to work out why exactly may_use_simd() is returning
false in your kworker.
cheers
^ permalink raw reply
* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
From: Dmitry Vyukov @ 2019-05-13 11:50 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-arch, Arnd Bergmann, linuxppc-dev,
Linux Kernel Mailing List, Andrew Donnellan, Nick Kossifidis,
Andrew Morton, Linus Torvalds, Christoph Hellwig
In-Reply-To: <87woiutwq4.fsf@concordia.ellerman.id.au>
From: Michael Ellerman <mpe@ellerman.id.au>
Date: Mon, May 13, 2019 at 1:33 PM
To: Dmitry Vyukov, Arnd Bergmann
Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds, Andrew Morton,
linux-arch, Linux Kernel Mailing List, linuxppc-dev
> Dmitry Vyukov <dvyukov@google.com> writes:
> > From: Arnd Bergmann <arnd@arndb.de>
> > Date: Sat, May 11, 2019 at 2:51 AM
> > To: Dmitry Vyukov
> > Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds, Andrew Morton,
> > linux-arch, Linux Kernel Mailing List, linuxppc-dev
> >
> >> On Fri, May 10, 2019 at 6:53 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> >> > >
> >> > > I think it's good to have a sanity check in-place for consistency.
> >> >
> >> >
> >> > Hi,
> >> >
> >> > This broke our cross-builds from x86. I am using:
> >> >
> >> > $ powerpc64le-linux-gnu-gcc --version
> >> > powerpc64le-linux-gnu-gcc (Debian 7.2.0-7) 7.2.0
> >> >
> >> > and it says that it's little-endian somehow:
> >> >
> >> > $ powerpc64le-linux-gnu-gcc -dM -E - < /dev/null | grep BYTE_ORDER
> >> > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
> >> >
> >> > Is it broke compiler? Or I always hold it wrong? Is there some
> >> > additional flag I need to add?
> >>
> >> It looks like a bug in the kernel Makefiles to me. powerpc32 is always
> >> big-endian,
> >> powerpc64 used to be big-endian but is now usually little-endian. There are
> >> often three separate toolchains that default to the respective user
> >> space targets
> >> (ppc32be, ppc64be, ppc64le), but generally you should be able to build
> >> any of the
> >> three kernel configurations with any of those compilers, and have the Makefile
> >> pass the correct -m32/-m64/-mbig-endian/-mlittle-endian command line options
> >> depending on the kernel configuration. It seems that this is not happening
> >> here. I have not checked why, but if this is the problem, it should be
> >> easy enough
> >> to figure out.
> >
> >
> > Thanks! This clears a lot.
> > This may be a bug in our magic as we try to build kernel files outside
> > of make with own flags (required to extract parts of kernel
> > interfaces).
> > So don't spend time looking for the Makefile bugs yet.
>
> OK :)
>
> We did have some bugs in the past (~1-2 y/ago) but AFAIK they are all
> fixed now. These days I build most of my kernels with a bi-endian 64-bit
> toolchain, and switching endian without running `make clean` also works.
For the record, yes, it turn out to be a problem in our code (a latent
bug). We actually used host (x86) gcc to build as-if ppc code that can
run on the host, so it defined neither LE no BE macros. It just
happened to work in the past :)
+Andrew
^ permalink raw reply
* Re: [PATCH] crypto: vmx - fix copy-paste error in CTR mode
From: Michael Ellerman @ 2019-05-13 11:39 UTC (permalink / raw)
To: Herbert Xu, Eric Biggers
Cc: leo.barbosa, Nayna, Stephan Mueller, nayna, omosnacek,
marcelo.cerri, pfsmorigo, linux-crypto, leitao, George Wilson,
linuxppc-dev, Daniel Axtens
In-Reply-To: <20190513005901.tsop4lz26vusr6o4@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Mon, May 06, 2019 at 08:53:17AM -0700, Eric Biggers wrote:
>>
>> Any progress on this? Someone just reported this again here:
>> https://bugzilla.kernel.org/show_bug.cgi?id=203515
>
> Guys if I don't get a fix for this soon I'll have to disable CTR
> in vmx.
No objection from me.
I'll try and debug it at some point if no one else does, but I can't
make it my top priority sorry.
cheers
^ permalink raw reply
* Re: [PATCH v3 4/6] dt-bindings: soc/fsl: qe: document new fsl,qe-snums binding
From: Joakim Tjernlund @ 2019-05-13 11:39 UTC (permalink / raw)
To: rasmus.villemoes@prevas.dk, leoyang.li@nxp.com,
qiang.zhao@nxp.com, devicetree@vger.kernel.org
Cc: mark.rutland@arm.com, oss@buserror.net,
linux-kernel@vger.kernel.org, Rasmus.Villemoes@prevas.se,
robh+dt@kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190513111442.25724-5-rasmus.villemoes@prevas.dk>
On Mon, 2019-05-13 at 11:14 +0000, Rasmus Villemoes wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> Reading table 4-30, and its footnotes, of the QUICC Engine Block
> Reference Manual shows that the set of snum _values_ is not
> necessarily just a function of the _number_ of snums, as given in the
> fsl,qe-num-snums property.
>
> As an alternative, to make it easier to add support for other variants
> of the QUICC engine IP, this introduces a new binding fsl,qe-snums,
> which automatically encodes both the number of snums and the actual
> values to use.
>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> ---
> Rob, thanks for the review of v2. However, since I moved the example
> from the commit log to the binding (per Joakim's request), I didn't
Thanks, looks good now.
> add a Reviewed-by tag for this revision.
>
> .../devicetree/bindings/soc/fsl/cpm_qe/qe.txt | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt
> index d7afaff5faff..05ec2a838c54 100644
> --- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt
> +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt
> @@ -18,7 +18,8 @@ Required properties:
> - reg : offset and length of the device registers.
> - bus-frequency : the clock frequency for QUICC Engine.
> - fsl,qe-num-riscs: define how many RISC engines the QE has.
> -- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use for the
> +- fsl,qe-snums: This property has to be specified as '/bits/ 8' value,
> + defining the array of serial number (SNUM) values for the virtual
> threads.
>
> Optional properties:
> @@ -34,6 +35,11 @@ Recommended properties
> - brg-frequency : the internal clock source frequency for baud-rate
> generators in Hz.
>
> +Deprecated properties
> +- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use
> + for the threads. Use fsl,qe-snums instead to not only specify the
> + number of snums, but also their values.
> +
> Example:
> qe@e0100000 {
> #address-cells = <1>;
> @@ -44,6 +50,11 @@ Example:
> reg = <e0100000 480>;
> brg-frequency = <0>;
> bus-frequency = <179A7B00>;
> + fsl,qe-snums = /bits/ 8 <
> + 0x04 0x05 0x0C 0x0D 0x14 0x15 0x1C 0x1D
> + 0x24 0x25 0x2C 0x2D 0x34 0x35 0x88 0x89
> + 0x98 0x99 0xA8 0xA9 0xB8 0xB9 0xC8 0xC9
> + 0xD8 0xD9 0xE8 0xE9>;
> }
>
> * Multi-User RAM (MURAM)
> --
> 2.20.1
>
^ permalink raw reply
* Re: [RFC PATCH] powerpc/64/ftrace: mprofile-kernel patch out mflr
From: Michael Ellerman @ 2019-05-13 11:34 UTC (permalink / raw)
To: Naveen N. Rao, linuxppc-dev, Nicholas Piggin
In-Reply-To: <1557729790.fw18xf9mdt.naveen@linux.ibm.com>
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com> writes:
> Michael Ellerman wrote:
>> Nicholas Piggin <npiggin@gmail.com> writes:
>>> The new mprofile-kernel mcount sequence is
>>>
>>> mflr r0
>>> bl _mcount
>>>
>>> Dynamic ftrace patches the branch instruction with a noop, but leaves
>>> the mflr. mflr is executed by the branch unit that can only execute one
>>> per cycle on POWER9 and shared with branches, so it would be nice to
>>> avoid it where possible.
>>>
>>> This patch is a hacky proof of concept to nop out the mflr. Can we do
>>> this or are there races or other issues with it?
>>
>> There's a race, isn't there?
>>
>> We have a function foo which currently has tracing disabled, so the mflr
>> and bl are nop'ed out.
>>
>> CPU 0 CPU 1
>> ==================================
>> bl foo
>> nop (ie. not mflr)
>> -> interrupt
>> something else enable tracing for foo
>> ... patch mflr and branch
>> <- rfi
>> bl _mcount
>>
>> So we end up in _mcount() but with r0 not populated.
>
> Good catch! Looks like we need to patch the mflr with a "b +8" similar
> to what we do in __ftrace_make_nop().
Would that actually make it any faster though? Nick?
cheers
^ permalink raw reply
* Re: [PATCH, RFC] byteorder: sanity check toolchain vs kernel endianess
From: Michael Ellerman @ 2019-05-13 11:33 UTC (permalink / raw)
To: Dmitry Vyukov, Arnd Bergmann
Cc: linux-arch, linuxppc-dev, Linux Kernel Mailing List,
Nick Kossifidis, Andrew Morton, Linus Torvalds, Christoph Hellwig
In-Reply-To: <CACT4Y+ad5z6z0Dweh5hGwYcUUebPEtqsznmX9enPvYB20J16aA@mail.gmail.com>
Dmitry Vyukov <dvyukov@google.com> writes:
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Sat, May 11, 2019 at 2:51 AM
> To: Dmitry Vyukov
> Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds, Andrew Morton,
> linux-arch, Linux Kernel Mailing List, linuxppc-dev
>
>> On Fri, May 10, 2019 at 6:53 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>> > >
>> > > I think it's good to have a sanity check in-place for consistency.
>> >
>> >
>> > Hi,
>> >
>> > This broke our cross-builds from x86. I am using:
>> >
>> > $ powerpc64le-linux-gnu-gcc --version
>> > powerpc64le-linux-gnu-gcc (Debian 7.2.0-7) 7.2.0
>> >
>> > and it says that it's little-endian somehow:
>> >
>> > $ powerpc64le-linux-gnu-gcc -dM -E - < /dev/null | grep BYTE_ORDER
>> > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
>> >
>> > Is it broke compiler? Or I always hold it wrong? Is there some
>> > additional flag I need to add?
>>
>> It looks like a bug in the kernel Makefiles to me. powerpc32 is always
>> big-endian,
>> powerpc64 used to be big-endian but is now usually little-endian. There are
>> often three separate toolchains that default to the respective user
>> space targets
>> (ppc32be, ppc64be, ppc64le), but generally you should be able to build
>> any of the
>> three kernel configurations with any of those compilers, and have the Makefile
>> pass the correct -m32/-m64/-mbig-endian/-mlittle-endian command line options
>> depending on the kernel configuration. It seems that this is not happening
>> here. I have not checked why, but if this is the problem, it should be
>> easy enough
>> to figure out.
>
>
> Thanks! This clears a lot.
> This may be a bug in our magic as we try to build kernel files outside
> of make with own flags (required to extract parts of kernel
> interfaces).
> So don't spend time looking for the Makefile bugs yet.
OK :)
We did have some bugs in the past (~1-2 y/ago) but AFAIK they are all
fixed now. These days I build most of my kernels with a bi-endian 64-bit
toolchain, and switching endian without running `make clean` also works.
cheers
^ permalink raw reply
* [PATCH] powerpc/boot: fix broken way to pass CONFIG options
From: Masahiro Yamada @ 2019-05-13 11:22 UTC (permalink / raw)
To: linuxppc-dev, Michael Ellerman
Cc: Rob Herring, Rodrigo R. Galvao, linux-kernel, Nicholas Piggin,
Mark Greer, Masahiro Yamada, Oliver O'Halloran, Joel Stanley,
Paul Mackerras
Commit 5e9dcb6188a4 ("powerpc/boot: Expose Kconfig symbols to wrapper")
was wrong, but commit e41b93a6be57 ("powerpc/boot: Fix build failures
with -j 1") was also wrong.
Check-in source files never ever depend on build artifacts.
The correct dependency is:
$(obj)/serial.o: $(obj)/autoconf.h
However, copying autoconf.h to arch/power/boot/ is questionable
in the first place.
arch/powerpc/Makefile adopted multiple ways to pass CONFIG options.
arch/powerpc/boot/decompress.c references CONFIG_KERNEL_GZIP and
CONFIG_KERNEL_XZ, which are passed via the command line.
arch/powerpc/boot/serial.c includes the copied autoconf.h to
reference a couple of CONFIG options.
Do not do this.
We should have already learned that including autoconf.h from each
source file is really fragile.
In fact, it is already broken.
arch/powerpc/boot/ppc_asm.h references CONFIG_PPC_8xx, but
arch/powerpc/boot/utils.S is not given any way to access CONFIG
options. So, CONFIG_PPC_8xx is never defined here.
Just pass $(LINUXINCLUDE) and remove all broken code.
I also removed the -traditional flag to make include/linux/kconfig.h
work. I do not understand why it needs to imitate the behavior of
pre-standard C preprocessors.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
arch/powerpc/boot/.gitignore | 2 --
arch/powerpc/boot/Makefile | 14 +++-----------
arch/powerpc/boot/serial.c | 1 -
3 files changed, 3 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
index 32034a0cc554..6610665fcf5e 100644
--- a/arch/powerpc/boot/.gitignore
+++ b/arch/powerpc/boot/.gitignore
@@ -44,5 +44,3 @@ fdt_sw.c
fdt_wip.c
libfdt.h
libfdt_internal.h
-autoconf.h
-
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 73d1f3562978..b8a82be2af2a 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -20,9 +20,6 @@
all: $(obj)/zImage
-compress-$(CONFIG_KERNEL_GZIP) := CONFIG_KERNEL_GZIP
-compress-$(CONFIG_KERNEL_XZ) := CONFIG_KERNEL_XZ
-
ifdef CROSS32_COMPILE
BOOTCC := $(CROSS32_COMPILE)gcc
BOOTAR := $(CROSS32_COMPILE)ar
@@ -34,7 +31,7 @@ endif
BOOTCFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -O2 -msoft-float -mno-altivec -mno-vsx \
-pipe -fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
- -D$(compress-y)
+ $(LINUXINCLUDE)
ifdef CONFIG_PPC64_BOOT_WRAPPER
BOOTCFLAGS += -m64
@@ -51,7 +48,7 @@ BOOTCFLAGS += -mlittle-endian
BOOTCFLAGS += $(call cc-option,-mabi=elfv2)
endif
-BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
+BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -nostdinc
BOOTARFLAGS := -cr$(KBUILD_ARFLAGS)
@@ -202,14 +199,9 @@ $(obj)/empty.c:
$(obj)/zImage.coff.lds $(obj)/zImage.ps3.lds : $(obj)/%: $(srctree)/$(src)/%.S
$(Q)cp $< $@
-$(srctree)/$(src)/serial.c: $(obj)/autoconf.h
-
-$(obj)/autoconf.h: $(obj)/%: $(objtree)/include/generated/%
- $(Q)cp $< $@
-
clean-files := $(zlib-) $(zlibheader-) $(zliblinuxheader-) \
$(zlib-decomp-) $(libfdt) $(libfdtheader) \
- autoconf.h empty.c zImage.coff.lds zImage.ps3.lds zImage.lds
+ empty.c zImage.coff.lds zImage.ps3.lds zImage.lds
quiet_cmd_bootcc = BOOTCC $@
cmd_bootcc = $(BOOTCC) -Wp,-MD,$(depfile) $(BOOTCFLAGS) -c -o $@ $<
diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
index b0491b8c0199..9457863147f9 100644
--- a/arch/powerpc/boot/serial.c
+++ b/arch/powerpc/boot/serial.c
@@ -18,7 +18,6 @@
#include "stdio.h"
#include "io.h"
#include "ops.h"
-#include "autoconf.h"
static int serial_open(void)
{
--
2.17.1
^ permalink raw reply related
* [PATCH v3 1/6] soc/fsl/qe: qe.c: drop useless static qualifier
From: Rasmus Villemoes @ 2019-05-13 11:14 UTC (permalink / raw)
To: devicetree@vger.kernel.org, Qiang Zhao, Li Yang
Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190513111442.25724-1-rasmus.villemoes@prevas.dk>
The local variable snum_init has no reason to have static storage duration.
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Reviewed-by: Qiang Zhao <qiang.zhao@nxp.com>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
drivers/soc/fsl/qe/qe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 612d9c551be5..855373deb746 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -306,7 +306,7 @@ static void qe_snums_init(void)
0x28, 0x29, 0x38, 0x39, 0x48, 0x49, 0x58, 0x59,
0x68, 0x69, 0x78, 0x79, 0x80, 0x81,
};
- static const u8 *snum_init;
+ const u8 *snum_init;
qe_num_of_snum = qe_get_num_of_snums();
--
2.20.1
^ permalink raw reply related
* [PATCH v3 6/6] soc/fsl/qe: qe.c: fold qe_get_num_of_snums into qe_snums_init
From: Rasmus Villemoes @ 2019-05-13 11:15 UTC (permalink / raw)
To: devicetree@vger.kernel.org, Qiang Zhao, Li Yang
Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190513111442.25724-1-rasmus.villemoes@prevas.dk>
The comment "No QE ever has fewer than 28 SNUMs" is false; e.g. the
MPC8309 has 14. The code path returning -EINVAL is also a recipe for
instant disaster, since the caller (qe_snums_init) uncritically
assigns the return value to the unsigned qe_num_of_snum, and would
thus proceed to attempt to copy 4GB from snum_init_46[] to the snum[]
array.
So fold the handling of the legacy fsl,qe-num-snums into
qe_snums_init, and make sure we do not end up using the snum_init_46
array in cases other than the two where we know it makes sense.
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Reviewed-by: Qiang Zhao <qiang.zhao@nxp.com>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
drivers/soc/fsl/qe/qe.c | 46 ++++++++++++++---------------------------
1 file changed, 16 insertions(+), 30 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 1d27187b251c..852060caff24 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -308,24 +308,33 @@ static void qe_snums_init(void)
int i;
bitmap_zero(snum_state, QE_NUM_OF_SNUM);
+ qe_num_of_snum = 28; /* The default number of snum for threads is 28 */
qe = qe_get_device_node();
if (qe) {
i = of_property_read_variable_u8_array(qe, "fsl,qe-snums",
snums, 1, QE_NUM_OF_SNUM);
- of_node_put(qe);
if (i > 0) {
+ of_node_put(qe);
qe_num_of_snum = i;
return;
}
+ /*
+ * Fall back to legacy binding of using the value of
+ * fsl,qe-num-snums to choose one of the static arrays
+ * above.
+ */
+ of_property_read_u32(qe, "fsl,qe-num-snums", &qe_num_of_snum);
+ of_node_put(qe);
}
- qe_num_of_snum = qe_get_num_of_snums();
-
- if (qe_num_of_snum == 76)
+ if (qe_num_of_snum == 76) {
snum_init = snum_init_76;
- else
+ } else if (qe_num_of_snum == 28 || qe_num_of_snum == 46) {
snum_init = snum_init_46;
-
+ } else {
+ pr_err("QE: unsupported value of fsl,qe-num-snums: %u\n", qe_num_of_snum);
+ return;
+ }
memcpy(snums, snum_init, qe_num_of_snum);
}
@@ -642,30 +651,7 @@ EXPORT_SYMBOL(qe_get_num_of_risc);
unsigned int qe_get_num_of_snums(void)
{
- struct device_node *qe;
- int size;
- unsigned int num_of_snums;
- const u32 *prop;
-
- num_of_snums = 28; /* The default number of snum for threads is 28 */
- qe = qe_get_device_node();
- if (!qe)
- return num_of_snums;
-
- prop = of_get_property(qe, "fsl,qe-num-snums", &size);
- if (prop && size == sizeof(*prop)) {
- num_of_snums = *prop;
- if ((num_of_snums < 28) || (num_of_snums > QE_NUM_OF_SNUM)) {
- /* No QE ever has fewer than 28 SNUMs */
- pr_err("QE: number of snum is invalid\n");
- of_node_put(qe);
- return -EINVAL;
- }
- }
-
- of_node_put(qe);
-
- return num_of_snums;
+ return qe_num_of_snum;
}
EXPORT_SYMBOL(qe_get_num_of_snums);
--
2.20.1
^ permalink raw reply related
* [PATCH v3 5/6] soc/fsl/qe: qe.c: support fsl,qe-snums property
From: Rasmus Villemoes @ 2019-05-13 11:15 UTC (permalink / raw)
To: devicetree@vger.kernel.org, Qiang Zhao, Li Yang
Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190513111442.25724-1-rasmus.villemoes@prevas.dk>
Add driver support for the newly introduced fsl,qe-snums property.
Conveniently, of_property_read_variable_u8_array does exactly what we
need: If the property fsl,qe-snums is found (and has an allowed size),
the array of values get copied to snums, and the return value is the
number of snums - we cannot assign directly to num_of_snums, since we
need to check whether the return value is negative.
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Reviewed-by: Qiang Zhao <qiang.zhao@nxp.com>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
drivers/soc/fsl/qe/qe.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 4b444846d590..1d27187b251c 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -283,7 +283,6 @@ EXPORT_SYMBOL(qe_clock_source);
*/
static void qe_snums_init(void)
{
- int i;
static const u8 snum_init_76[] = {
0x04, 0x05, 0x0C, 0x0D, 0x14, 0x15, 0x1C, 0x1D,
0x24, 0x25, 0x2C, 0x2D, 0x34, 0x35, 0x88, 0x89,
@@ -304,7 +303,21 @@ static void qe_snums_init(void)
0x28, 0x29, 0x38, 0x39, 0x48, 0x49, 0x58, 0x59,
0x68, 0x69, 0x78, 0x79, 0x80, 0x81,
};
+ struct device_node *qe;
const u8 *snum_init;
+ int i;
+
+ bitmap_zero(snum_state, QE_NUM_OF_SNUM);
+ qe = qe_get_device_node();
+ if (qe) {
+ i = of_property_read_variable_u8_array(qe, "fsl,qe-snums",
+ snums, 1, QE_NUM_OF_SNUM);
+ of_node_put(qe);
+ if (i > 0) {
+ qe_num_of_snum = i;
+ return;
+ }
+ }
qe_num_of_snum = qe_get_num_of_snums();
@@ -313,7 +326,6 @@ static void qe_snums_init(void)
else
snum_init = snum_init_46;
- bitmap_zero(snum_state, QE_NUM_OF_SNUM);
memcpy(snums, snum_init, qe_num_of_snum);
}
--
2.20.1
^ permalink raw reply related
* [PATCH v3 4/6] dt-bindings: soc/fsl: qe: document new fsl,qe-snums binding
From: Rasmus Villemoes @ 2019-05-13 11:14 UTC (permalink / raw)
To: devicetree@vger.kernel.org, Qiang Zhao, Li Yang
Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190513111442.25724-1-rasmus.villemoes@prevas.dk>
Reading table 4-30, and its footnotes, of the QUICC Engine Block
Reference Manual shows that the set of snum _values_ is not
necessarily just a function of the _number_ of snums, as given in the
fsl,qe-num-snums property.
As an alternative, to make it easier to add support for other variants
of the QUICC engine IP, this introduces a new binding fsl,qe-snums,
which automatically encodes both the number of snums and the actual
values to use.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
Rob, thanks for the review of v2. However, since I moved the example
from the commit log to the binding (per Joakim's request), I didn't
add a Reviewed-by tag for this revision.
.../devicetree/bindings/soc/fsl/cpm_qe/qe.txt | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt
index d7afaff5faff..05ec2a838c54 100644
--- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt
@@ -18,7 +18,8 @@ Required properties:
- reg : offset and length of the device registers.
- bus-frequency : the clock frequency for QUICC Engine.
- fsl,qe-num-riscs: define how many RISC engines the QE has.
-- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use for the
+- fsl,qe-snums: This property has to be specified as '/bits/ 8' value,
+ defining the array of serial number (SNUM) values for the virtual
threads.
Optional properties:
@@ -34,6 +35,11 @@ Recommended properties
- brg-frequency : the internal clock source frequency for baud-rate
generators in Hz.
+Deprecated properties
+- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use
+ for the threads. Use fsl,qe-snums instead to not only specify the
+ number of snums, but also their values.
+
Example:
qe@e0100000 {
#address-cells = <1>;
@@ -44,6 +50,11 @@ Example:
reg = <e0100000 480>;
brg-frequency = <0>;
bus-frequency = <179A7B00>;
+ fsl,qe-snums = /bits/ 8 <
+ 0x04 0x05 0x0C 0x0D 0x14 0x15 0x1C 0x1D
+ 0x24 0x25 0x2C 0x2D 0x34 0x35 0x88 0x89
+ 0x98 0x99 0xA8 0xA9 0xB8 0xB9 0xC8 0xC9
+ 0xD8 0xD9 0xE8 0xE9>;
}
* Multi-User RAM (MURAM)
--
2.20.1
^ permalink raw reply related
* [PATCH v3 3/6] soc/fsl/qe: qe.c: introduce qe_get_device_node helper
From: Rasmus Villemoes @ 2019-05-13 11:14 UTC (permalink / raw)
To: devicetree@vger.kernel.org, Qiang Zhao, Li Yang
Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190513111442.25724-1-rasmus.villemoes@prevas.dk>
The 'try of_find_compatible_node(NULL, NULL, "fsl,qe"), fall back to
of_find_node_by_type(NULL, "qe")' pattern is repeated five
times. Factor it into a common helper.
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Reviewed-by: Qiang Zhao <qiang.zhao@nxp.com>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
drivers/soc/fsl/qe/qe.c | 71 +++++++++++++++++------------------------
1 file changed, 29 insertions(+), 42 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 4b59109df22b..4b444846d590 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -56,6 +56,20 @@ static unsigned int qe_num_of_snum;
static phys_addr_t qebase = -1;
+static struct device_node *qe_get_device_node(void)
+{
+ struct device_node *qe;
+
+ /*
+ * Newer device trees have an "fsl,qe" compatible property for the QE
+ * node, but we still need to support older device trees.
+ */
+ qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
+ if (qe)
+ return qe;
+ return of_find_node_by_type(NULL, "qe");
+}
+
static phys_addr_t get_qe_base(void)
{
struct device_node *qe;
@@ -65,12 +79,9 @@ static phys_addr_t get_qe_base(void)
if (qebase != -1)
return qebase;
- qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
- if (!qe) {
- qe = of_find_node_by_type(NULL, "qe");
- if (!qe)
- return qebase;
- }
+ qe = qe_get_device_node();
+ if (!qe)
+ return qebase;
ret = of_address_to_resource(qe, 0, &res);
if (!ret)
@@ -164,12 +175,9 @@ unsigned int qe_get_brg_clk(void)
if (brg_clk)
return brg_clk;
- qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
- if (!qe) {
- qe = of_find_node_by_type(NULL, "qe");
- if (!qe)
- return brg_clk;
- }
+ qe = qe_get_device_node();
+ if (!qe)
+ return brg_clk;
prop = of_get_property(qe, "brg-frequency", &size);
if (prop && size == sizeof(*prop))
@@ -558,16 +566,9 @@ struct qe_firmware_info *qe_get_firmware_info(void)
initialized = 1;
- /*
- * Newer device trees have an "fsl,qe" compatible property for the QE
- * node, but we still need to support older device trees.
- */
- qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
- if (!qe) {
- qe = of_find_node_by_type(NULL, "qe");
- if (!qe)
- return NULL;
- }
+ qe = qe_get_device_node();
+ if (!qe)
+ return NULL;
/* Find the 'firmware' child node */
fw = of_get_child_by_name(qe, "firmware");
@@ -613,16 +614,9 @@ unsigned int qe_get_num_of_risc(void)
unsigned int num_of_risc = 0;
const u32 *prop;
- qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
- if (!qe) {
- /* Older devices trees did not have an "fsl,qe"
- * compatible property, so we need to look for
- * the QE node by name.
- */
- qe = of_find_node_by_type(NULL, "qe");
- if (!qe)
- return num_of_risc;
- }
+ qe = qe_get_device_node();
+ if (!qe)
+ return num_of_risc;
prop = of_get_property(qe, "fsl,qe-num-riscs", &size);
if (prop && size == sizeof(*prop))
@@ -642,16 +636,9 @@ unsigned int qe_get_num_of_snums(void)
const u32 *prop;
num_of_snums = 28; /* The default number of snum for threads is 28 */
- qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
- if (!qe) {
- /* Older devices trees did not have an "fsl,qe"
- * compatible property, so we need to look for
- * the QE node by name.
- */
- qe = of_find_node_by_type(NULL, "qe");
- if (!qe)
- return num_of_snums;
- }
+ qe = qe_get_device_node();
+ if (!qe)
+ return num_of_snums;
prop = of_get_property(qe, "fsl,qe-num-snums", &size);
if (prop && size == sizeof(*prop)) {
--
2.20.1
^ permalink raw reply related
* [PATCH v3 2/6] soc/fsl/qe: qe.c: reduce static memory footprint by 1.7K
From: Rasmus Villemoes @ 2019-05-13 11:14 UTC (permalink / raw)
To: devicetree@vger.kernel.org, Qiang Zhao, Li Yang
Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190513111442.25724-1-rasmus.villemoes@prevas.dk>
The current array of struct qe_snum use 256*4 bytes for just keeping
track of the free/used state of each index, and the struct layout
means there's another 768 bytes of padding. If we just unzip that
structure, the array of snum values just use 256 bytes, while the
free/inuse state can be tracked in a 32 byte bitmap.
So this reduces the .data footprint by 1760 bytes. It also serves as
preparation for introducing another DT binding for specifying the snum
values.
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Reviewed-by: Qiang Zhao <qiang.zhao@nxp.com>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
drivers/soc/fsl/qe/qe.c | 42 ++++++++++++-----------------------------
1 file changed, 12 insertions(+), 30 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 855373deb746..4b59109df22b 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -14,6 +14,7 @@
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
+#include <linux/bitmap.h>
#include <linux/errno.h>
#include <linux/sched.h>
#include <linux/kernel.h>
@@ -43,25 +44,14 @@ static DEFINE_SPINLOCK(qe_lock);
DEFINE_SPINLOCK(cmxgcr_lock);
EXPORT_SYMBOL(cmxgcr_lock);
-/* QE snum state */
-enum qe_snum_state {
- QE_SNUM_STATE_USED,
- QE_SNUM_STATE_FREE
-};
-
-/* QE snum */
-struct qe_snum {
- u8 num;
- enum qe_snum_state state;
-};
-
/* We allocate this here because it is used almost exclusively for
* the communication processor devices.
*/
struct qe_immap __iomem *qe_immr;
EXPORT_SYMBOL(qe_immr);
-static struct qe_snum snums[QE_NUM_OF_SNUM]; /* Dynamically allocated SNUMs */
+static u8 snums[QE_NUM_OF_SNUM]; /* Dynamically allocated SNUMs */
+static DECLARE_BITMAP(snum_state, QE_NUM_OF_SNUM);
static unsigned int qe_num_of_snum;
static phys_addr_t qebase = -1;
@@ -315,10 +305,8 @@ static void qe_snums_init(void)
else
snum_init = snum_init_46;
- for (i = 0; i < qe_num_of_snum; i++) {
- snums[i].num = snum_init[i];
- snums[i].state = QE_SNUM_STATE_FREE;
- }
+ bitmap_zero(snum_state, QE_NUM_OF_SNUM);
+ memcpy(snums, snum_init, qe_num_of_snum);
}
int qe_get_snum(void)
@@ -328,12 +316,10 @@ int qe_get_snum(void)
int i;
spin_lock_irqsave(&qe_lock, flags);
- for (i = 0; i < qe_num_of_snum; i++) {
- if (snums[i].state == QE_SNUM_STATE_FREE) {
- snums[i].state = QE_SNUM_STATE_USED;
- snum = snums[i].num;
- break;
- }
+ i = find_first_zero_bit(snum_state, qe_num_of_snum);
+ if (i < qe_num_of_snum) {
+ set_bit(i, snum_state);
+ snum = snums[i];
}
spin_unlock_irqrestore(&qe_lock, flags);
@@ -343,14 +329,10 @@ EXPORT_SYMBOL(qe_get_snum);
void qe_put_snum(u8 snum)
{
- int i;
+ const u8 *p = memchr(snums, snum, qe_num_of_snum);
- for (i = 0; i < qe_num_of_snum; i++) {
- if (snums[i].num == snum) {
- snums[i].state = QE_SNUM_STATE_FREE;
- break;
- }
- }
+ if (p)
+ clear_bit(p - snums, snum_state);
}
EXPORT_SYMBOL(qe_put_snum);
--
2.20.1
^ permalink raw reply related
* [PATCH v3 0/6] soc/fsl/qe: cleanups and new DT binding
From: Rasmus Villemoes @ 2019-05-13 11:14 UTC (permalink / raw)
To: devicetree@vger.kernel.org, Qiang Zhao, Li Yang
Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190501092841.9026-1-rasmus.villemoes@prevas.dk>
This small series consists of some small cleanups and simplifications
of the QUICC engine driver, and introduces a new DT binding that makes
it much easier to support other variants of the QUICC engine IP block
that appears in the wild: There's no reason to expect in general that
the number of valid SNUMs uniquely determines the set of such, so it's
better to simply let the device tree specify the values (and,
implicitly via the array length, also the count).
Which tree should this go through?
v3:
- Move example from commit log into binding document (adapting to
MPC8360 which the existing example pertains to).
- Add more review tags.
- Fix minor style issue.
v2:
- Address comments from Christophe Leroy
- Add his Reviewed-by to 1/6 and 3/6
- Split DT binding update to separate patch as per
Documentation/devicetree/bindings/submitting-patches.txt
Rasmus Villemoes (6):
soc/fsl/qe: qe.c: drop useless static qualifier
soc/fsl/qe: qe.c: reduce static memory footprint by 1.7K
soc/fsl/qe: qe.c: introduce qe_get_device_node helper
dt-bindings: soc/fsl: qe: document new fsl,qe-snums binding
soc/fsl/qe: qe.c: support fsl,qe-snums property
soc/fsl/qe: qe.c: fold qe_get_num_of_snums into qe_snums_init
.../devicetree/bindings/soc/fsl/cpm_qe/qe.txt | 13 +-
drivers/soc/fsl/qe/qe.c | 163 +++++++-----------
2 files changed, 77 insertions(+), 99 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH 1/2] perf ioctl: Add check for the sample_period value
From: Ravi Bangoria @ 2019-05-13 10:07 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ravi Bangoria, maddy, linuxppc-dev, linux-kernel, acme, jolsa
In-Reply-To: <20190513085620.GN2650@hirez.programming.kicks-ass.net>
On 5/13/19 2:26 PM, Peter Zijlstra wrote:
> On Mon, May 13, 2019 at 09:42:13AM +0200, Peter Zijlstra wrote:
>> On Sat, May 11, 2019 at 08:12:16AM +0530, Ravi Bangoria wrote:
>>> Add a check for sample_period value sent from userspace. Negative
>>> value does not make sense. And in powerpc arch code this could cause
>>> a recursive PMI 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;
>>
>> Well, perf_event_attr::sample_period is __u64. Would not be the site
>> using it as signed be the one in error?
>
> You forgot to mention commit: 0819b2e30ccb9, so I guess this just makes
> it consistent and is fine.
>
Yeah, I was about to reply :)
^ permalink raw reply
* [PATCH 2/2] powerpc/lib: only build ldstfp.o when CONFIG_PPC_FPU is set
From: Christophe Leroy @ 2019-05-13 10:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <7496da89e027e563cb8e62dc89548525cf53b57e.1557741292.git.christophe.leroy@c-s.fr>
The entire code in ldstfp.o is enclosed into #ifdef CONFIG_PPC_FPU,
so there is no point in building it when this config is not selected.
Fixes: cd64d1697cf0 ("powerpc: mtmsrd not defined")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/lib/Makefile | 3 ++-
arch/powerpc/lib/ldstfp.S | 4 ----
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 17fce3738d48..eebc782d89a5 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -49,7 +49,8 @@ obj64-$(CONFIG_KPROBES_SANITY_TEST) += test_emulate_step.o \
obj-y += checksum_$(BITS).o checksum_wrappers.o \
string_$(BITS).o
-obj-y += sstep.o ldstfp.o
+obj-y += sstep.o
+obj-$(CONFIG_PPC_FPU) += ldstfp.o
obj64-y += quad.o
obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
diff --git a/arch/powerpc/lib/ldstfp.S b/arch/powerpc/lib/ldstfp.S
index 32e91994b6b2..e388a3127cb6 100644
--- a/arch/powerpc/lib/ldstfp.S
+++ b/arch/powerpc/lib/ldstfp.S
@@ -18,8 +18,6 @@
#include <asm/asm-compat.h>
#include <linux/errno.h>
-#ifdef CONFIG_PPC_FPU
-
#define STKFRM (PPC_MIN_STKFRM + 16)
/* Get the contents of frN into *p; N is in r3 and p is in r4. */
@@ -241,5 +239,3 @@ _GLOBAL(conv_dp_to_sp)
MTMSRD(r6)
isync
blr
-
-#endif /* CONFIG_PPC_FPU */
--
2.13.3
^ permalink raw reply related
* [PATCH 1/2] powerpc/lib: fix redundant inclusion of quad.o
From: Christophe Leroy @ 2019-05-13 10:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
quad.o is only for PPC64, and already included in obj64-y,
so it doesn't have to be in obj-y
Fixes: 31bfdb036f12 ("powerpc: Use instruction emulation infrastructure to handle alignment faults")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/lib/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index c55f9c27bf79..17fce3738d48 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -49,7 +49,7 @@ obj64-$(CONFIG_KPROBES_SANITY_TEST) += test_emulate_step.o \
obj-y += checksum_$(BITS).o checksum_wrappers.o \
string_$(BITS).o
-obj-y += sstep.o ldstfp.o quad.o
+obj-y += sstep.o ldstfp.o
obj64-y += quad.o
obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
--
2.13.3
^ permalink raw reply related
* Re: [PATCH 0/1] Forced-wakeup for stop lite states on Powernv
From: Abhishek @ 2019-05-13 9:49 UTC (permalink / raw)
To: Nicholas Piggin, linux-kernel, linux-pm, linuxppc-dev
Cc: ego, daniel.lezcano, rjw, dja
In-Reply-To: <1557291178.ow4spjzq5t.astroid@bobo.none>
On 05/08/2019 10:29 AM, Nicholas Piggin wrote:
> Abhishek Goel's on April 22, 2019 4:32 pm:
>> Currently, the cpuidle governors determine what idle state a idling CPU
>> should enter into based on heuristics that depend on the idle history on
>> that CPU. Given that no predictive heuristic is perfect, there are cases
>> where the governor predicts a shallow idle state, hoping that the CPU will
>> be busy soon. However, if no new workload is scheduled on that CPU in the
>> near future, the CPU will end up in the shallow state.
>>
>> Motivation
>> ----------
>> In case of POWER, this is problematic, when the predicted state in the
>> aforementioned scenario is a lite stop state, as such lite states will
>> inhibit SMT folding, thereby depriving the other threads in the core from
>> using the core resources.
>>
>> So we do not want to get stucked in such states for longer duration. To
>> address this, the cpuidle-core can queue timer to correspond with the
>> residency value of the next available state. This timer will forcefully
>> wakeup the cpu. Few such iterations will essentially train the governor to
>> select a deeper state for that cpu, as the timer here corresponds to the
>> next available cpuidle state residency. Cpu will be kicked out of the lite
>> state and end up in a non-lite state.
>>
>> Experiment
>> ----------
>> I performed experiments for three scenarios to collect some data.
>>
>> case 1 :
>> Without this patch and without tick retained, i.e. in a upstream kernel,
>> It would spend more than even a second to get out of stop0_lite.
>>
>> case 2 : With tick retained in a upstream kernel -
>>
>> Generally, we have a sched tick at 4ms(CONF_HZ = 250). Ideally I expected
>> it to take 8 sched tick to get out of stop0_lite. Experimentally,
>> observation was
>>
>> =========================================================
>> sample min max 99percentile
>> 20 4ms 12ms 4ms
>> =========================================================
>>
>> It would take atleast one sched tick to get out of stop0_lite.
>>
>> case 2 : With this patch (not stopping tick, but explicitly queuing a
>> timer)
>>
>> ============================================================
>> sample min max 99percentile
>> ============================================================
>> 20 144us 192us 144us
>> ============================================================
>>
>> In this patch, we queue a timer just before entering into a stop0_lite
>> state. The timer fires at (residency of next available state + exit latency
>> of next available state * 2). Let's say if next state(stop0) is available
>> which has residency of 20us, it should get out in as low as (20+2*2)*8
>> [Based on the forumla (residency + 2xlatency)*history length] microseconds
>> = 192us. Ideally we would expect 8 iterations, it was observed to get out
>> in 6-7 iterations. Even if let's say stop2 is next available state(stop0
>> and stop1 both are unavailable), it would take (100+2*10)*8 = 960us to get
>> into stop2.
>>
>> So, We are able to get out of stop0_lite generally in 150us(with this
>> patch) as compared to 4ms(with tick retained). As stated earlier, we do not
>> want to get stuck into stop0_lite as it inhibits SMT folding for other
>> sibling threads, depriving them of core resources. Current patch is using
>> forced-wakeup only for stop0_lite, as it gives performance benefit(primary
>> reason) along with lowering down power consumption. We may extend this
>> model for other states in future.
> I still have to wonder, between our snooze loop and stop0, what does
> stop0_lite buy us.
>
> That said, the problem you're solving here is a generic one that all
> stop states have, I think. Doesn't the same thing apply going from
> stop0 to stop5? You might under estimate the sleep time and lose power
> savings and therefore performance there too. Shouldn't we make it
> generic for all stop states?
>
> Thanks,
> Nick
>
>
When a cpu is in snooze, it takes both space and time of core. When in
stop0_lite,
it free up time but it still takes space. When it is in stop0 or deeper,
it free up both
space and time slice of core.
In stop0_lite, cpu doesn't free up the core resources and thus inhibits
thread
folding. When a cpu goes to stop0, it will free up the core resources
thus increasing
the single thread performance of other sibling thread.
Hence, we do not want to get stuck in stop0_lite for long duration, and
want to quickly
move onto the next state.
If we get stuck in any other state we would possibly be losing on to
power saving,
but will still be able to gain the performance benefits for other
sibling threads.
Thanks,
Abhishek
^ permalink raw reply
* Re: [PATCH] vsprintf: Do not break early boot with probing addresses
From: Andy Shevchenko @ 2019-05-13 9:13 UTC (permalink / raw)
To: David Laight
Cc: Petr Mladek, linux-arch@vger.kernel.org, Sergey Senozhatsky,
Heiko Carstens, linux-s390@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Rasmus Villemoes,
linux-kernel@vger.kernel.org, Steven Rostedt, Michal Hocko,
Sergey Senozhatsky, Stephen Rothwell, Linus Torvalds,
Martin Schwidefsky, Tobin C . Harding
In-Reply-To: <096d6c9c17b3484484d9d9d3f3aa3a7c@AcuMS.aculab.com>
On Mon, May 13, 2019 at 08:52:41AM +0000, David Laight wrote:
> From: christophe leroy
> > Sent: 10 May 2019 18:35
> > Le 10/05/2019 à 18:24, Steven Rostedt a écrit :
> > > On Fri, 10 May 2019 10:42:13 +0200
> > > Petr Mladek <pmladek@suse.com> wrote:
> > >> - if (probe_kernel_address(ptr, byte))
> > >> + if ((unsigned long)ptr < PAGE_SIZE || IS_ERR_VALUE(ptr))
> > >> return "(efault)";
>
> "efault" looks a bit like a spellling mistake for "default".
It's a special, thus it's in parenthesis, though somebody can be
misguided.
> > Usually, < PAGE_SIZE means NULL pointer dereference (via the member of a
> > struct)
>
> Maybe the caller should pass in a short buffer so that you can return
> "(err-%d)"
> or "(null+%#x)" ?
In both cases it should be limited to the size of pointer (8 or 16
characters). Something like "(e:%4d)" would work for error codes.
The "(null)" is good enough by itself and already an established
practice..
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2] powerpc: Fix compile issue with force DAWR
From: Christophe Leroy @ 2019-05-13 9:08 UTC (permalink / raw)
To: Michael Neuling, mpe; +Cc: linuxppc-dev
In-Reply-To: <20190513071703.25243-1-mikey@neuling.org>
Le 13/05/2019 à 09:17, Michael Neuling a écrit :
> 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 puts more of the dawr infrastructure in a new file.
I think you are doing a bit more than that. I think you should explain
that you define a new CONFIG_ option, when it is selected, etc ...
The commit you are referring to is talking about P9. It looks like your
patch covers a lot more, so it should be mentionned her I guess.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
You should add a Fixes: tag, ie:
Fixes: c1fe190c0672 ("powerpc: Add force enable of DAWR on P9 option")
> --
> v2:
> Fixes based on Christophe Leroy's comments:
> - Fix commit message formatting
> - Move more DAWR code into dawr.c
> ---
> arch/powerpc/Kconfig | 5 ++
> arch/powerpc/include/asm/hw_breakpoint.h | 20 ++++---
> arch/powerpc/kernel/Makefile | 1 +
> arch/powerpc/kernel/dawr.c | 75 ++++++++++++++++++++++++
> arch/powerpc/kernel/hw_breakpoint.c | 56 ------------------
> arch/powerpc/kvm/Kconfig | 1 +
> 6 files changed, 94 insertions(+), 64 deletions(-)
> create mode 100644 arch/powerpc/kernel/dawr.c
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 2711aac246..f4b19e48cc 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -242,6 +242,7 @@ config PPC
> select SYSCTL_EXCEPTION_TRACE
> select THREAD_INFO_IN_TASK
> select VIRT_TO_BUS if !PPC64
> + select PPC_DAWR_FORCE_ENABLE if PPC64 || PERF
What's PERF ? Did you mean PERF_EVENTS ?
Then what you mean is:
- Selected all the time for PPC64
- Selected for PPC32 when PERF is also selected.
Is that what you want ? At first I thought it was linked to P9.
And ... did you read below statement ?
> #
> # Please keep this list sorted alphabetically.
> #
> @@ -369,6 +370,10 @@ config PPC_ADV_DEBUG_DAC_RANGE
> depends on PPC_ADV_DEBUG_REGS && 44x
> default y
>
> +config PPC_DAWR_FORCE_ENABLE
> + bool
> + default y
> +
Why defaulting it to y. Then how is it set to n ?
> 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..ffbc8eab41 100644
> --- a/arch/powerpc/include/asm/hw_breakpoint.h
> +++ b/arch/powerpc/include/asm/hw_breakpoint.h
> @@ -47,6 +47,8 @@ struct arch_hw_breakpoint {
> #define HW_BRK_TYPE_PRIV_ALL (HW_BRK_TYPE_USER | HW_BRK_TYPE_KERNEL | \
> HW_BRK_TYPE_HYP)
>
> +extern int set_dawr(struct arch_hw_breakpoint *brk);
> +
> #ifdef CONFIG_HAVE_HW_BREAKPOINT
> #include <linux/kdebug.h>
> #include <asm/reg.h>
> @@ -90,18 +92,20 @@ 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);
> -extern bool dawr_force_enable;
> -static inline bool dawr_enabled(void)
> -{
> - return dawr_force_enable;
> -}
> -
That's a very simple function, why not keep it here (or in another .h)
as 'static inline' ?
> #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) { }
> -static inline bool dawr_enabled(void) { return false; }
> +
> #endif /* CONFIG_HAVE_HW_BREAKPOINT */
> +
> +extern bool dawr_force_enable;
> +
> +#ifdef CONFIG_PPC_DAWR_FORCE_ENABLE
> +extern bool dawr_enabled(void);
Functions should not be 'extern'. I'm sure checkpatch --strict will tell
you.
> +#else
> +#define dawr_enabled() true
true by default ?
Previously it was false by default.
And why a #define ? That's better to keep a static inline.
> +#endif
> +
> #endif /* __KERNEL__ */
> #endif /* _PPC_BOOK3S_64_HW_BREAKPOINT_H */
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index 0ea6c4aa3a..a9c497c34f 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_FORCE_ENABLE) += 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..cf1d02fe1e
> --- /dev/null
> +++ b/arch/powerpc/kernel/dawr.c
> @@ -0,0 +1,75 @@
> +// 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);
> +
> +extern bool dawr_enabled(void)
extern ????
> +{
> + return dawr_force_enable;
> +}
> +EXPORT_SYMBOL_GPL(dawr_enabled);
Since dawr_force_enable is also exported, I see no point in having such
a tiny function as an exported function, was better as a 'static inline'.
> +
> +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))
The above is not real clear.
set_dabr() returns 0, H_SUCCESS is not used there.
> + 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((smp_call_func_t)set_dawr, &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;
The above is not needed, the BSS is zeroised at kernel startup.
> +
> + if (cpu_has_feature(CPU_FTR_DAWR)) {
> + /* Don't setup sysfs file for user control on P8 */
> + dawr_force_enable = true;
Strange comment, word "don't" doesn't really fit with a 'true'
> + return 0;
> + }
> +
> + if (PVR_VER(mfspr(SPRN_PVR)) == PVR_POWER9) {
You could use pvr_version_is(PVR_POWER9) instead of open codiing.
> + /* 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);
Wouldn't it also make sense to move set_dawr() from process.c to here ?
> diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c
> index da307dd93e..95605a9c9a 100644
> --- a/arch/powerpc/kernel/hw_breakpoint.c
> +++ b/arch/powerpc/kernel/hw_breakpoint.c
> @@ -380,59 +380,3 @@ void hw_breakpoint_pmu_read(struct perf_event *bp)
> {
> /* TODO */
> }
> -
> -bool dawr_force_enable;
> -EXPORT_SYMBOL_GPL(dawr_force_enable);
> -
> -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((smp_call_func_t)set_dawr, &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/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
> index bfdde04e49..9c0d315108 100644
> --- a/arch/powerpc/kvm/Kconfig
> +++ b/arch/powerpc/kvm/Kconfig
> @@ -39,6 +39,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
>
Christophe
^ permalink raw reply
* Re: [PATCH 1/2] perf ioctl: Add check for the sample_period value
From: Peter Zijlstra @ 2019-05-13 8:56 UTC (permalink / raw)
To: Ravi Bangoria; +Cc: maddy, linuxppc-dev, linux-kernel, acme, jolsa
In-Reply-To: <20190513074213.GH2623@hirez.programming.kicks-ass.net>
On Mon, May 13, 2019 at 09:42:13AM +0200, Peter Zijlstra wrote:
> On Sat, May 11, 2019 at 08:12:16AM +0530, Ravi Bangoria wrote:
> > Add a check for sample_period value sent from userspace. Negative
> > value does not make sense. And in powerpc arch code this could cause
> > a recursive PMI 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;
>
> Well, perf_event_attr::sample_period is __u64. Would not be the site
> using it as signed be the one in error?
You forgot to mention commit: 0819b2e30ccb9, so I guess this just makes
it consistent and is fine.
^ permalink raw reply
* RE: [PATCH] vsprintf: Do not break early boot with probing addresses
From: David Laight @ 2019-05-13 8:52 UTC (permalink / raw)
To: 'christophe leroy', Steven Rostedt, Petr Mladek
Cc: linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
Sergey Senozhatsky, Heiko Carstens, linuxppc-dev@lists.ozlabs.org,
Rasmus Villemoes, linux-kernel@vger.kernel.org, Michal Hocko,
Sergey Senozhatsky, Stephen Rothwell, Andy Shevchenko,
Linus Torvalds, Martin Schwidefsky, Tobin C . Harding
In-Reply-To: <daf4dfd1-7f4f-8b92-6866-437c3a2be28b@c-s.fr>
From: christophe leroy
> Sent: 10 May 2019 18:35
> Le 10/05/2019 à 18:24, Steven Rostedt a écrit :
> > On Fri, 10 May 2019 10:42:13 +0200
> > Petr Mladek <pmladek@suse.com> wrote:
> >
> >> static const char *check_pointer_msg(const void *ptr)
> >> {
> >> - char byte;
> >> -
> >> if (!ptr)
> >> return "(null)";
> >>
> >> - if (probe_kernel_address(ptr, byte))
> >> + if ((unsigned long)ptr < PAGE_SIZE || IS_ERR_VALUE(ptr))
> >> return "(efault)";
"efault" looks a bit like a spellling mistake for "default".
> > < PAGE_SIZE ?
> >
> > do you mean: < TASK_SIZE ?
>
> I guess not.
>
> Usually, < PAGE_SIZE means NULL pointer dereference (via the member of a
> struct)
Maybe the caller should pass in a short buffer so that you can return
"(err-%d)" or "(null+%#x)" ?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ 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