Re: [PATCH v15 14/23] selftests/vm/pkeys: Fix assertion in test_pkey_alloc_exhaust()

2020-01-14 Thread Michael Ellerman
Sandipan Das writes: > From: Ram Pai > > Some pkeys which are valid on the hardware are reserved > and not available for application use. These keys cannot > be allocated. > > test_pkey_alloc_exhaust() tries to account for these and > has an assertion which validates if all available pkeys >

Re: [PATCH v15 23/23] selftests: vm: pkeys: Use the correct page size on powerpc

2020-01-14 Thread Michael Ellerman
Sandipan Das writes: > Both 4K and 64K pages are supported on powerpc. Parts of > the selftest code perform alignment computations based on > the PAGE_SIZE macro which is currently hardcoded to 64K > for powerpc. This causes some test failures on kernels > configured with 4K page size. > > This

[PATCH 2/2] string.h: fix incompatibility between FORTIFY_SOURCE and KASAN

2020-01-14 Thread Daniel Axtens
The memcmp KASAN self-test fails on a kernel with both KASAN and FORTIFY_SOURCE. When FORTIFY_SOURCE is on, a number of functions are replaced with fortified versions, which attempt to check the sizes of the operands. However, these functions often directly invoke __builtin_foo() once they have

[PATCH 1/2] kasan: stop tests being eliminated as dead code with FORTIFY_SOURCE

2020-01-14 Thread Daniel Axtens
3 KASAN self-tests fail on a kernel with both KASAN and FORTIFY_SOURCE: memchr, memcmp and strlen. When FORTIFY_SOURCE is on, a number of functions are replaced with fortified versions, which attempt to check the sizes of the operands. However, these functions often directly invoke

[PATCH 0/2] Fix some incompatibilites between KASAN and FORTIFY_SOURCE

2020-01-14 Thread Daniel Axtens
3 KASAN self-tests fail on a kernel with both KASAN and FORTIFY_SOURCE: memchr, memcmp and strlen. I have observed this on x86 and powerpc. When FORTIFY_SOURCE is on, a number of functions are replaced with fortified versions, which attempt to check the sizes of the operands. However, these

[PATCH v5] reboot: support offline CPUs before reboot

2020-01-14 Thread Hsin-Yi Wang
Currently system reboots uses architecture specific codes (smp_send_stop) to offline non reboot CPUs. Most architecture's implementation is looping through all non reboot online CPUs and call ipi function to each of them. Some architecture like arm64, arm, and x86... would set offline masks to cpu

Re: [RFC PATCH v3 08/12] lib: vdso: allow arches to provide vdso data pointer

2020-01-14 Thread Christophe Leroy
Le 15/01/2020 à 00:06, Thomas Gleixner a écrit : Christophe Leroy writes: static __maybe_unused int +#ifdef VDSO_GETS_VD_PTR_FROM_ARCH +__cvdso_clock_gettime_common(const struct vdso_data *vd, clockid_t clock, + struct __kernel_timespec *ts) +{ +#else

Re: [PATCH] Fix display of Maximum Memory

2020-01-14 Thread Christophe Leroy
Le 14/01/2020 à 22:07, Michael Bringmann a écrit : Correct overflow problem in calculation+display of Maximum Memory value to syscfg where 32bits is insufficient. Signed-off-by: Michael Bringmann --- arch/powerpc/platforms/pseries/lparcfg.c | 8 1 file changed, 4 insertions(+),

Re: [PATCH v12 00/22] mm/gup: prereqs to track dma-pinned pages: FOLL_PIN

2020-01-14 Thread Andrew Morton
On Tue, 14 Jan 2020 12:15:08 -0800 John Hubbard wrote: > > > > Hi Andrew and all, > > > > To clarify: I'm hoping that this series can go into 5.6. > > > > Meanwhile, I'm working on tracking down and solving the problem that Leon > > reported, in the "track FOLL_PIN pages" patch, and that

[PATCH] Fix display of Maximum Memory

2020-01-14 Thread Michael Bringmann
Correct overflow problem in calculation+display of Maximum Memory value to syscfg where 32bits is insufficient. Signed-off-by: Michael Bringmann --- arch/powerpc/platforms/pseries/lparcfg.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

Re: [RFC PATCH v3 08/12] lib: vdso: allow arches to provide vdso data pointer

2020-01-14 Thread Thomas Gleixner
Christophe Leroy writes: > > static __maybe_unused int > +#ifdef VDSO_GETS_VD_PTR_FROM_ARCH > +__cvdso_clock_gettime_common(const struct vdso_data *vd, clockid_t clock, > + struct __kernel_timespec *ts) > +{ > +#else > __cvdso_clock_gettime_common(clockid_t clock, struct

Re: [PATCH v12 00/22] mm/gup: prereqs to track dma-pinned pages: FOLL_PIN

2020-01-14 Thread John Hubbard
On 1/9/20 2:07 PM, John Hubbard wrote: > On 1/7/20 2:45 PM, John Hubbard wrote: >> Hi, >> >> The "track FOLL_PIN pages" would have been the very next patch, but it is >> not included here because I'm still debugging a bug report from Leon. >> Let's get all of the prerequisite work (it's been

[PATCH 5/5] powerpc/32: reuse orphaned memblocks in kasan_init_shadow_page_tables()

2020-01-14 Thread Christophe Leroy
If concurrent PMD population has happened, re-use orphaned memblocks. Signed-off-by: Christophe Leroy --- arch/powerpc/mm/kasan/kasan_init_32.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/mm/kasan/kasan_init_32.c

[PATCH 4/5] powerpc/32: Simplify KASAN init

2020-01-14 Thread Christophe Leroy
Since kasan_init_region() is not used anymore for modules, KASAN init is done while slab_is_available() is false. Signed-off-by: Christophe Leroy --- arch/powerpc/mm/kasan/kasan_init_32.c | 26 +- 1 file changed, 5 insertions(+), 21 deletions(-) diff --git

[PATCH 1/5] powerpc/32: add support of KASAN_VMALLOC

2020-01-14 Thread Christophe Leroy
Add support of KASAN_VMALLOC on PPC32. To allow this, the early shadow covering the VMALLOC space need to be removed once high_memory var is set and before freeing memblock. And the VMALLOC area need to be aligned such that boundaries are covered by a full shadow page. Signed-off-by: Christophe

[PATCH 3/5] powerpc/32: force KASAN_VMALLOC for modules

2020-01-14 Thread Christophe Leroy
Unloading/Reloading of modules seems to fail with KASAN_VMALLOC but works properly with it. Force selection of KASAN_VMALLOC when MODULES are selected, and drop module_alloc() which was dedicated to KASAN for modules. Reported-by: Link: https://bugzilla.kernel.org/show_bug.cgi?id=205283

[PATCH 2/5] powerpc/kconfig: move CONFIG_PPC32 into Kconfig.cputype

2020-01-14 Thread Christophe Leroy
Move CONFIG_PPC32 at the same place as CONFIG_PPC64 for consistency. Signed-off-by: Christophe Leroy --- arch/powerpc/Kconfig | 4 arch/powerpc/platforms/Kconfig.cputype | 4 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/Kconfig

Re: [PATCH v3] spi: fsl: simplify error path in of_fsl_spi_probe()

2020-01-14 Thread Mark Brown
On Tue, Jan 14, 2020 at 04:26:18PM +, Joakim Tjernlund wrote: > Don't you need to "undo" ioremap, irq etc. in case of later errors? Better, convert to devm_ signature.asc Description: PGP signature

Re: [PATCH v3] spi: fsl: simplify error path in of_fsl_spi_probe()

2020-01-14 Thread Joakim Tjernlund
On Tue, 2020-01-14 at 16:02 +, Christophe Leroy 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. > > > No need to 'goto err;' for just doing a return. > return

Re: [PATCH RESEND v4] reboot: support offline CPUs before reboot

2020-01-14 Thread Thomas Gleixner
Hsin-Yi Wang writes: > > Signed-off-by: Hsin-Yi Wang > --- > Resend v4: > * Cc more people and mailing lists. Also fix a few nits from v4. Please don't name it resend if you actually changed the patch. Resend wants to be an unmodified patch and the only reasons to do that are: - add more

Re: [PATCH v2 2/2] spi: fsl: simplify error path in of_fsl_spi_probe()

2020-01-14 Thread Mark Brown
On Tue, Dec 10, 2019 at 03:17:16PM +, Christophe Leroy wrote: > No need to 'goto err;' for just doing a return. > return directly from where the error happens. This doesn't apply against current code, please check and resend. signature.asc Description: PGP signature

Applied "spi: fsl: simplify error path in of_fsl_spi_probe()" to the spi tree

2020-01-14 Thread Mark Brown
The patch spi: fsl: simplify error path in of_fsl_spi_probe() has been applied to the spi tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-5.6 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "ASoC: dt-bindings: fsl_asrc: add compatible string for imx8qm & imx8qxp" to the asoc tree

2020-01-14 Thread Mark Brown
The patch ASoC: dt-bindings: fsl_asrc: add compatible string for imx8qm & imx8qxp has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.6 All being well this means that it will be integrated into the linux-next tree (usually sometime

Applied "ASoC: fsl_asrc: Add support for imx8qm & imx8qxp" to the asoc tree

2020-01-14 Thread Mark Brown
The patch ASoC: fsl_asrc: Add support for imx8qm & imx8qxp has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.6 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

[PATCH v3] spi: fsl: simplify error path in of_fsl_spi_probe()

2020-01-14 Thread Christophe Leroy
No need to 'goto err;' for just doing a return. return directly from where the error happens. Signed-off-by: Christophe Leroy --- v3: rebase on today's spi/for-next and using PTR_ERR_OR_ZERO() in one place. --- drivers/spi/spi-fsl-spi.c | 27 --- 1 file changed, 8

[PATCH RESEND v4] reboot: support offline CPUs before reboot

2020-01-14 Thread Hsin-Yi Wang
Currently system reboots uses architecture specific codes (smp_send_stop) to offline non reboot CPUs. Most architecture's implementation is looping through all non reboot online CPUs and call ipi function to each of them. Some architecture like arm64, arm, and x86... would set offline masks to cpu

[Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c

2020-01-14 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206203 --- Comment #2 from Erhard F. (erhar...@mailbox.org) --- Created attachment 286805 --> https://bugzilla.kernel.org/attachment.cgi?id=286805=edit kernel .config (kernel 5.4.11, Talos II) -- You are receiving this mail because: You are watching

[Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c

2020-01-14 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206203 --- Comment #1 from Erhard F. (erhar...@mailbox.org) --- Created attachment 286803 --> https://bugzilla.kernel.org/attachment.cgi?id=286803=edit dmesg (kernel 5.4.11, Talos II) -- You are receiving this mail because: You are watching the

[Bug 206203] New: kmemleak reports various leaks in drivers/of/unittest.c

2020-01-14 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206203 Bug ID: 206203 Summary: kmemleak reports various leaks in drivers/of/unittest.c Product: Platform Specific/Hardware Version: 2.5 Kernel Version: 5.4.11 Hardware:

[PATCH] powerpc/32s: reorder Linux PTE bits to better match Hash PTE bits.

2020-01-14 Thread Christophe Leroy
Reorder Linux PTE bits to (almost) match Hash PTE bits. RW Kernel : PP = 00 RO Kernel : PP = 00 RW User : PP = 01 RO User : PP = 11 So naturally, we should have _PAGE_USER = 0x001 _PAGE_RW = 0x002 Today 0x001 and 0x002 and _PAGE_PRESENT and _PAGE_HASHPTE which both are software only bits.

[PATCH] net/wan/fsl_ucc_hdlc: fix out of bounds write on array utdm_info

2020-01-14 Thread Colin King
From: Colin Ian King Array utdm_info is declared as an array of MAX_HDLC_NUM (4) elements however up to UCC_MAX_NUM (8) elements are potentially being written to it. Currently we have an array out-of-bounds write error on the last 4 elements. Fix this by making utdm_info UCC_MAX_NUM elements in

Re: [PATCH] evh_bytechan: fix out of bounds accesses

2020-01-14 Thread Segher Boessenkool
On Tue, Jan 14, 2020 at 05:53:41AM -0600, Timur Tabi wrote: > On 1/14/20 2:29 AM, Segher Boessenkool wrote: > >You have no working lswx I suppose?:-) > > I don't know if the P4080 supports lswx, but it does, than that would be > an elegant way to fix this bug. No e500 version supports it. Many

Re: [PATCH] evh_bytechan: fix out of bounds accesses

2020-01-14 Thread Timur Tabi
On 1/14/20 2:29 AM, Segher Boessenkool wrote: You have no working lswx I suppose?:-) I don't know if the P4080 supports lswx, but it does, than that would be an elegant way to fix this bug.

Re: [RFC PATCH v3 06/12] lib: vdso: __iter_div_u64_rem() is suboptimal for 32 bit time

2020-01-14 Thread Thomas Gleixner
Christophe Leroy writes: > Using __iter_div_ulong_rem() is suboptimal on 32 bits. > Nanoseconds are only 32 bits, and VDSO data is updated every 10ms > so nsec will never overflow 32 bits. That's theory and perhaps true for bare metal, but there is no guarantee on VIRT that the CPU which has

Re: [PATCH] evh_bytechan: fix out of bounds accesses

2020-01-14 Thread Timur Tabi
On 1/14/20 3:18 AM, Laurentiu Tudor wrote: I can offer myself. I'll send a MAINTAINERS patch if nobody is against it. Yes, please do. I'm always available if you have any questions on the code.

Re: [PATCH] MAINTAINERS: Add myself as maintainer of ehv_bytechan tty driver

2020-01-14 Thread Timur Tabi
On 1/14/20 5:00 AM, Laurentiu Tudor wrote: Michael Ellerman made a call for volunteers from NXP to maintain this driver and I offered myself. Signed-off-by: Laurentiu Tudor Acked-by: Timur Tabi

[PATCH] MAINTAINERS: Add myself as maintainer of ehv_bytechan tty driver

2020-01-14 Thread Laurentiu Tudor
Michael Ellerman made a call for volunteers from NXP to maintain this driver and I offered myself. Signed-off-by: Laurentiu Tudor --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4017e6b760be..62082e5f7101 100644 --- a/MAINTAINERS +++

Re: [PATCH] evh_bytechan: fix out of bounds accesses

2020-01-14 Thread Laurentiu Tudor
On 14.01.2020 03:10, Michael Ellerman wrote: > Laurentiu Tudor writes: >> Hello, >> >> On 13.01.2020 15:48, Timur Tabi wrote: >>> On 1/13/20 6:26 AM, Michael Ellerman wrote: I've never heard of it, and I have no idea how to test it. It's not used by qemu, I guess there is/was a

Re: [PATCH] powerpc/xive: discard ESB load value when interrupt is invalid

2020-01-14 Thread Greg Kurz
On Tue, 14 Jan 2020 08:44:54 +0100 Cédric Le Goater wrote: > On 1/14/20 2:14 AM, Michael Ellerman wrote: > > Cédric Le Goater writes: > >> On 1/13/20 2:01 PM, Cédric Le Goater wrote: > >>> From: Frederic Barrat > >>> > >>> A load on an ESB page returning all 1's means that the underlying > >>>

Re: [PATCH] evh_bytechan: fix out of bounds accesses

2020-01-14 Thread Segher Boessenkool
On Mon, Jan 13, 2020 at 07:10:11PM -0600, Timur Tabi wrote: > Ah, I see now. This is all coming back to me. > > I would prefer that ev_byte_channel_send() is updated to access only > 'count' bytes. If that means adding a memcpy to the > ev_byte_channel_send() itself, then so be it. Trying to

[PATCH] powerpc/ptdump: only enable PPC_CHECK_WX with STRICT_KERNEL_RWX

2020-01-14 Thread Christophe Leroy
ptdump_check_wx() is called from mark_rodata_ro() which only exists when CONFIG_STRICT_KERNEL_RWX is selected. Signed-off-by: Christophe Leroy Fixes: 453d87f6a8ae ("powerpc/mm: Warn if W+X pages found on boot") --- arch/powerpc/Kconfig.debug | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH] powerpc/ptdump: fix W+X verification call in mark_rodata_ro()

2020-01-14 Thread Christophe Leroy
ptdump_check_wx() also have to be called when pages are mapped by blocks. Signed-off-by: Christophe Leroy Fixes: 453d87f6a8ae ("powerpc/mm: Warn if W+X pages found on boot") --- arch/powerpc/mm/pgtable_32.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/mm/pgtable_32.c

[PATCH] powerpc/ptdump: fix W+X verification

2020-01-14 Thread Christophe Leroy
Verification cannot rely on simple bit checking because on some platforms PAGE_RW is 0, checking that a page is not W means checking that PAGE_RO is set instead of checking that PAGE_RW is not set. Use pte helpers instead of checking bits. Signed-off-by: Christophe Leroy Fixes: 453d87f6a8ae

Re: [PATCH] powerpc/xive: discard ESB load value when interrupt is invalid

2020-01-14 Thread Cédric Le Goater
On 1/14/20 2:14 AM, Michael Ellerman wrote: > Cédric Le Goater writes: >> On 1/13/20 2:01 PM, Cédric Le Goater wrote: >>> From: Frederic Barrat >>> >>> A load on an ESB page returning all 1's means that the underlying >>> device has invalidated the access to the PQ state of the interrupt >>>