* [PATCH 05/15] kbuild: add CONFIG_HEADERS_INSTALL and loosen the dependency of samples
From: Masahiro Yamada @ 2019-06-04 10:13 UTC (permalink / raw)
To: linux-kbuild
Cc: Heiko Carstens, David Howells, Masahiro Yamada, Paul Mackerras,
Vincent Chen, Sam Ravnborg, linux-s390, Arnd Bergmann,
Helge Deller, Christian Borntraeger, linux-snps-arc,
Vasily Gorbik, Jani Nikula, Greentime Hu, James E.J. Bottomley,
Michal Marek, linux-parisc, Vineet Gupta, Randy Dunlap,
linux-kernel, linuxppc-dev
In-Reply-To: <20190604101409.2078-1-yamada.masahiro@socionext.com>
Commit 5318321d367c ("samples: disable CONFIG_SAMPLES for UML") used
a big hammer to fix the build errors under the samples/ directory,
while only some samples actually include uapi headers from usr/include.
Introduce CONFIG_HEADERS_INSTALL since 'depends on HEADERS_INSTALL' is
clearer than 'depends on !UML'. If this option is enabled, uapi headers
are installed before starting directory descending.
I added 'depends on HEADERS_INSTALL' to per-sample CONFIG options.
This allows UML to compile some samples.
$ make ARCH=um allmodconfig samples/
[ snip ]
CC [M] samples/configfs/configfs_sample.o
CC [M] samples/kfifo/bytestream-example.o
CC [M] samples/kfifo/dma-example.o
CC [M] samples/kfifo/inttype-example.o
CC [M] samples/kfifo/record-example.o
CC [M] samples/kobject/kobject-example.o
CC [M] samples/kobject/kset-example.o
CC [M] samples/trace_events/trace-events-sample.o
CC [M] samples/trace_printk/trace-printk.o
AR samples/vfio-mdev/built-in.a
AR samples/built-in.a
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Makefile | 8 ++++----
arch/arc/configs/tb10x_defconfig | 1 +
arch/nds32/configs/defconfig | 1 +
arch/parisc/configs/a500_defconfig | 1 +
arch/parisc/configs/b180_defconfig | 1 +
arch/parisc/configs/c3000_defconfig | 1 +
arch/parisc/configs/default_defconfig | 1 +
arch/powerpc/configs/ppc6xx_defconfig | 1 +
arch/s390/configs/debug_defconfig | 1 +
lib/Kconfig.debug | 19 ++++++++++++++-----
samples/Kconfig | 14 +++++++++++---
samples/Makefile | 4 ++--
12 files changed, 39 insertions(+), 14 deletions(-)
diff --git a/Makefile b/Makefile
index 8348939765d3..ce5a9551860d 100644
--- a/Makefile
+++ b/Makefile
@@ -1053,9 +1053,6 @@ vmlinux: scripts/link-vmlinux.sh autoksyms_recursive $(vmlinux-deps) FORCE
targets := vmlinux
-# Some samples need headers_install.
-samples: headers_install
-
# The actual objects are generated when descending,
# make sure no implicit rule kicks in
$(sort $(vmlinux-deps)): $(vmlinux-dirs) ;
@@ -1199,6 +1196,10 @@ headers_check: headers_install
$(Q)$(MAKE) $(hdr-inst)=include/uapi dst=include HDRCHECK=1
$(Q)$(MAKE) $(hdr-inst)=arch/$(SRCARCH)/include/uapi dst=include HDRCHECK=1
+ifdef CONFIG_HEADERS_INSTALL
+prepare: headers_install
+endif
+
ifdef CONFIG_HEADERS_CHECK
all: headers_check
endif
@@ -1745,7 +1746,6 @@ build-dir = $(patsubst %/,%,$(dir $(build-target)))
PHONY += /
/: ./
-samples/: headers_install
%/: prepare FORCE
$(Q)$(MAKE) KBUILD_MODULES=1 $(build)=$(build-dir)
diff --git a/arch/arc/configs/tb10x_defconfig b/arch/arc/configs/tb10x_defconfig
index 5b5119d2b5d5..dc739bd093e3 100644
--- a/arch/arc/configs/tb10x_defconfig
+++ b/arch/arc/configs/tb10x_defconfig
@@ -94,6 +94,7 @@ CONFIG_CONFIGFS_FS=y
CONFIG_DEBUG_INFO=y
CONFIG_STRIP_ASM_SYMS=y
CONFIG_DEBUG_FS=y
+CONFIG_HEADERS_INSTALL=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_MAGIC_SYSRQ=y
diff --git a/arch/nds32/configs/defconfig b/arch/nds32/configs/defconfig
index 65ce9259081b..40313a635075 100644
--- a/arch/nds32/configs/defconfig
+++ b/arch/nds32/configs/defconfig
@@ -92,6 +92,7 @@ CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_DWARF4=y
CONFIG_GDB_SCRIPTS=y
CONFIG_READABLE_ASM=y
+CONFIG_HEADERS_INSTALL=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_MAGIC_SYSRQ=y
diff --git a/arch/parisc/configs/a500_defconfig b/arch/parisc/configs/a500_defconfig
index 5acb93dcaabf..390c0bc09179 100644
--- a/arch/parisc/configs/a500_defconfig
+++ b/arch/parisc/configs/a500_defconfig
@@ -167,6 +167,7 @@ CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_UTF8=m
CONFIG_DEBUG_FS=y
+CONFIG_HEADERS_INSTALL=y
CONFIG_HEADERS_CHECK=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_BUGVERBOSE is not set
diff --git a/arch/parisc/configs/b180_defconfig b/arch/parisc/configs/b180_defconfig
index 83ffd161aec5..bdf1fe2b217f 100644
--- a/arch/parisc/configs/b180_defconfig
+++ b/arch/parisc/configs/b180_defconfig
@@ -91,6 +91,7 @@ CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_UTF8=m
+CONFIG_HEADERS_INSTALL=y
CONFIG_HEADERS_CHECK=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
diff --git a/arch/parisc/configs/c3000_defconfig b/arch/parisc/configs/c3000_defconfig
index 8d41a73bd71b..ed4d49575b38 100644
--- a/arch/parisc/configs/c3000_defconfig
+++ b/arch/parisc/configs/c3000_defconfig
@@ -140,6 +140,7 @@ CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_UTF8=m
CONFIG_DEBUG_FS=y
+CONFIG_HEADERS_INSTALL=y
CONFIG_HEADERS_CHECK=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_MUTEXES=y
diff --git a/arch/parisc/configs/default_defconfig b/arch/parisc/configs/default_defconfig
index 52c9050a7c5c..fcfd9eaadf9b 100644
--- a/arch/parisc/configs/default_defconfig
+++ b/arch/parisc/configs/default_defconfig
@@ -184,6 +184,7 @@ CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=y
CONFIG_DEBUG_FS=y
+CONFIG_HEADERS_INSTALL=y
CONFIG_HEADERS_CHECK=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
diff --git a/arch/powerpc/configs/ppc6xx_defconfig b/arch/powerpc/configs/ppc6xx_defconfig
index 7c6baf6df139..463aa3e53084 100644
--- a/arch/powerpc/configs/ppc6xx_defconfig
+++ b/arch/powerpc/configs/ppc6xx_defconfig
@@ -1124,6 +1124,7 @@ CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_DEBUG_INFO=y
CONFIG_UNUSED_SYMBOLS=y
+CONFIG_HEADERS_INSTALL=y
CONFIG_HEADERS_CHECK=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
diff --git a/arch/s390/configs/debug_defconfig b/arch/s390/configs/debug_defconfig
index b0920b35f87b..994e03fad424 100644
--- a/arch/s390/configs/debug_defconfig
+++ b/arch/s390/configs/debug_defconfig
@@ -586,6 +586,7 @@ CONFIG_GDB_SCRIPTS=y
CONFIG_FRAME_WARN=1024
CONFIG_READABLE_ASM=y
CONFIG_UNUSED_SYMBOLS=y
+CONFIG_HEADERS_INSTALL=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_MAGIC_SYSRQ=y
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 7cdcb962358c..6a6ea4219d1e 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -305,14 +305,23 @@ config DEBUG_FS
If unsure, say N.
+config HEADERS_INSTALL
+ bool "Install uapi headers to usr/include"
+ depends on !UML
+ help
+ This option will install uapi headers (headers exported to user-space)
+ into the usr/include directory for use during the kernel build.
+ This is unneeded for building the kernel itself, but needed for some
+ user-space program samples. It is also needed by some features such
+ as uapi header sanity checks.
+
config HEADERS_CHECK
bool "Run sanity checks on uapi headers when building 'all'"
- depends on !UML
+ depends on HEADERS_INSTALL
help
- This option will extract the user-visible kernel headers when
- building the 'all' target, and will run basic sanity checks on them to
- ensure that exported files do not attempt to include files which
- were not exported, etc.
+ This option will run basic sanity checks on uapi headers when
+ building the 'all' target, for example, ensure that they do not
+ attempt to include files which were not exported, etc.
If you're making modifications to header files which are
relevant for userspace, say 'Y', and check the headers
diff --git a/samples/Kconfig b/samples/Kconfig
index d63cc8a3e0df..71b5e833dd9e 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
menuconfig SAMPLES
bool "Sample kernel code"
- depends on !UML
help
You can build and test sample kernel code here.
@@ -95,16 +94,24 @@ config SAMPLE_CONFIGFS
config SAMPLE_CONNECTOR
tristate "Build connector sample -- loadable modules only"
- depends on CONNECTOR && m
+ depends on CONNECTOR && HEADERS_INSTALL && m
help
When enabled, this builds both a sample kernel module for
the connector interface and a user space tool to communicate
with it.
See also Documentation/connector/connector.txt
+config SAMPLE_HIDRAW
+ bool "hidraw sample"
+ depends on HEADERS_INSTALL
+
+config SAMPLE_PIDFD
+ bool "pidfd sample"
+ depends on HEADERS_INSTALL
+
config SAMPLE_SECCOMP
bool "Build seccomp sample code"
- depends on SECCOMP_FILTER
+ depends on SECCOMP_FILTER && HEADERS_INSTALL
help
Build samples of seccomp filters using various methods of
BPF filter construction.
@@ -156,6 +163,7 @@ config SAMPLE_ANDROID_BINDERFS
config SAMPLE_VFS
bool "Build example programs that use new VFS system calls"
+ depends on HEADERS_INSTALL
help
Build example userspace programs that use new VFS system calls such
as mount API and statx(). Note that this is restricted to the x86
diff --git a/samples/Makefile b/samples/Makefile
index debf8925f06f..7d6e4ca28d69 100644
--- a/samples/Makefile
+++ b/samples/Makefile
@@ -4,14 +4,14 @@
obj-$(CONFIG_SAMPLE_ANDROID_BINDERFS) += binderfs/
obj-$(CONFIG_SAMPLE_CONFIGFS) += configfs/
obj-$(CONFIG_SAMPLE_CONNECTOR) += connector/
-subdir-y += hidraw
+subdir-$(CONFIG_SAMPLE_HIDRAW) += hidraw
obj-$(CONFIG_SAMPLE_HW_BREAKPOINT) += hw_breakpoint/
obj-$(CONFIG_SAMPLE_KDB) += kdb/
obj-$(CONFIG_SAMPLE_KFIFO) += kfifo/
obj-$(CONFIG_SAMPLE_KOBJECT) += kobject/
obj-$(CONFIG_SAMPLE_KPROBES) += kprobes/
obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch/
-subdir-y += pidfd
+subdir-$(CONFIG_SAMPLE_PIDFD) += pidfd
obj-$(CONFIG_SAMPLE_QMI_CLIENT) += qmi/
obj-$(CONFIG_SAMPLE_RPMSG_CLIENT) += rpmsg/
subdir-$(CONFIG_SAMPLE_SECCOMP) += seccomp
--
2.17.1
^ permalink raw reply related
* [PATCH 00/15] kbuild: refactor headers_install and support compile-test of UAPI headers
From: Masahiro Yamada @ 2019-06-04 10:13 UTC (permalink / raw)
To: linux-kbuild
Cc: Song Liu, linux-doc, Palmer Dabbelt, Heiko Carstens,
Alexei Starovoitov, David Howells, Masahiro Yamada,
Paul Mackerras, linux-riscv, Vincent Chen, Sam Ravnborg,
linux-s390, Vasily Gorbik, Daniel Borkmann, Jonathan Corbet,
Helge Deller, Christian Borntraeger, Yonghong Song,
linux-snps-arc, Albert Ou, Arnd Bergmann, Jani Nikula,
Greentime Hu, James E.J. Bottomley, Michal Marek, linux-parisc,
Vineet Gupta, Randy Dunlap, linux-kernel, netdev, bpf,
linuxppc-dev, Martin KaFai Lau
Multiple people have suggested to compile-test UAPI headers.
Currently, Kbuild provides simple sanity checks by headers_check
but they are not enough to catch bugs.
The most recent patch I know is David Howells' work:
https://patchwork.kernel.org/patch/10590203/
I agree that we need better tests for UAPI headers,
but I want to integrate it in a clean way.
The idea that has been in my mind is to compile each header
to make sure the selfcontainedness.
Recently, Jani Nikula proposed a new syntax 'header-test-y'.
https://patchwork.kernel.org/patch/10947005/
So, I implemented UAPI compile-testing on top of that.
When adding a new feature, cleaning the code first is a
good practice.
[1] Remove headers_install_all
This target installs UAPI headers of all architectures
in a single tree.
It does not make sense to compile test of headers from
multiple arches at the same time. Hence, removed.
[2] Split header installation into 'make headers' and 'make headers_install'
To compile-test UAPI headers, we need a work-directory somewhere
to save objects and .*.cmd files.
usr/include/ will be the work-directory.
Since we cannot pollute the final destination of headers_install,
I split the header installation into two stages.
'make headers' will build up
the ready-to-install headers in usr/include,
which will be also used as a work-directory for the compile-test.
'make headers_install' will copy headers
from usr/include to $(INSTALL_HDR_PATH)/include.
[3] Support compile-test of UAPI headers
This is implemented in usr/include/Makefile
Jani Nikula (1):
kbuild: add support for ensuring headers are self-contained
Masahiro Yamada (14):
kbuild: remove headers_{install,check}_all
kbuild: remove stale dependency between Documentation/ and
headers_install
kbuild: make gdb_script depend on prepare0 instead of prepare
kbuild: fix Kconfig prompt of CONFIG_HEADERS_CHECK
kbuild: add CONFIG_HEADERS_INSTALL and loosen the dependency of
samples
kbuild: remove build_unifdef target in scripts/Makefile
kbuild: build all prerequisite of headers_install simultaneously
kbuild: add 'headers' target to build up ready-to-install uapi headers
kbuild: re-implement Makefile.headersinst without directory descending
kbuild: move hdr-inst shorthand to top Makefile
kbuild: simplify scripts/headers_install.sh
kbuild: deb-pkg: do not run headers_check
fixup: kbuild: add support for ensuring headers are self-contained
kbuild: compile test UAPI headers to ensure they are self-contained
Documentation/kbuild/headers_install.txt | 7 --
Documentation/kbuild/makefiles.txt | 13 ++-
Makefile | 56 +++++-----
arch/arc/configs/tb10x_defconfig | 1 +
arch/nds32/configs/defconfig | 1 +
arch/parisc/configs/a500_defconfig | 1 +
arch/parisc/configs/b180_defconfig | 1 +
arch/parisc/configs/c3000_defconfig | 1 +
arch/parisc/configs/default_defconfig | 1 +
arch/powerpc/configs/ppc6xx_defconfig | 1 +
arch/s390/configs/debug_defconfig | 1 +
include/uapi/{linux => }/Kbuild | 6 +-
init/Kconfig | 20 ++++
lib/Kconfig.debug | 25 +++--
samples/Kconfig | 14 ++-
samples/Makefile | 4 +-
scripts/Kbuild.include | 6 --
scripts/Makefile | 5 -
scripts/Makefile.build | 9 ++
scripts/Makefile.headersinst | 132 ++++++++++-------------
scripts/Makefile.lib | 3 +
scripts/cc-system-headers.sh | 8 ++
scripts/headers.sh | 29 -----
scripts/headers_install.sh | 48 ++++-----
scripts/package/builddeb | 2 +-
usr/.gitignore | 1 -
usr/Makefile | 2 +
usr/include/.gitignore | 3 +
usr/include/Makefile | 132 +++++++++++++++++++++++
29 files changed, 329 insertions(+), 204 deletions(-)
rename include/uapi/{linux => }/Kbuild (77%)
create mode 100755 scripts/cc-system-headers.sh
delete mode 100755 scripts/headers.sh
create mode 100644 usr/include/.gitignore
create mode 100644 usr/include/Makefile
--
2.17.1
^ permalink raw reply
* Re: [POWERPC][next-20190603] Boot failure : Kernel BUG at mm/vmalloc.c:470
From: Stephen Rothwell @ 2019-06-04 10:29 UTC (permalink / raw)
To: Sachin Sant
Cc: linux-mm, linux-next, linuxppc-dev, linux-kernel,
Uladzislau Rezki (Sony)
In-Reply-To: <9F9C0085-F8A4-4B66-802B-382119E34DF5@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 552 bytes --]
Hi Sachin,
On Tue, 4 Jun 2019 14:45:43 +0530 Sachin Sant <sachinp@linux.vnet.ibm.com> wrote:
>
> While booting linux-next [next-20190603] on a POWER9 LPAR following
> BUG is encountered and the boot fails.
>
> If I revert the following 2 patches I no longer see this BUG message
>
> 07031d37b2f9 ( mm/vmalloc.c: switch to WARN_ON() and move it under unlink_va() )
> 728e0fbf263e ( mm/vmalloc.c: get rid of one single unlink_va() when merge )
This latter patch has been fixed in today's linux-next ...
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 22/22] docs: fix broken documentation links
From: Mauro Carvalho Chehab @ 2019-06-04 9:46 UTC (permalink / raw)
To: Christophe Leroy
Cc: Andrew Lunn, Thomas Preston, Wolfram Sang, Catalin Marinas,
Linus Walleij, Will Deacon, Russell King, Paul Mackerras,
Alessia Mantegazza, Jakub Wilk, AKASHI Takahiro, Kevin Hilman,
James Morris, linux-acpi, Andy Gross, xen-devel, Jason Wang,
Alexander Popov, Qian Cai, Al Viro, Andy Lutomirski,
Thomas Gleixner, Kairui Song, Quentin Perret, Greg Kroah-Hartman,
Rafael J. Wysocki, linux-kernel, Paul Burton, Jiri Kosina,
Casey Schaufler, Andrew Morton, Lu Baolu, Mark Rutland, Feng Tang,
Linux Doc Mailing List, Dave Hansen, Mimi Zohar, Kamalesh Babulal,
Masahiro Yamada, Yannik Sembritzki, Harry Wei, linux-i2c,
Shuah Khan, Stephen Rothwell, Paul E. McKenney, Alexandre Ghiti,
YueHaibing, Robert Moore, Bartosz Golaszewski, Len Brown,
David Brown, Joerg Roedel, linux-arm-msm, Mauro Carvalho Chehab,
linux-gpio, Claudiu Manoil, Florian Fainelli, Jacek Anaszewski,
Bjorn Helgaas, linux-amlogic, Boris Ostrovsky, Mika Westerberg,
linux-arm-kernel, Tony Luck, Sean Christopherson, Rob Herring,
James Morse, Robin Murphy, Samuel Mendoza-Jonas, linux-pci,
Bhupesh Sharma, Josh Poimboeuf, platform-driver-x86, Ding Xiang,
linux-kselftest, Alex Shi, Lorenzo Pieralisi, Baoquan He,
Jonathan Corbet, Raphael Gault, Joel Stanley, Federico Vaga,
Darren Hart, Erik Schmauss, Serge E. Hallyn, Palmer Dabbelt,
Kees Cook, Bartlomiej Zolnierkiewicz, Jonathan Neuschäfer,
SeongJae Park, Mark Brown, Borislav Petkov, Sunil Muthuswamy,
virtualization, devel, Ard Biesheuvel, Liam Girdwood,
Sakari Ailus, Olof Johansson, Logan Gunthorpe, David S. Miller,
Kirill A. Shutemov, Sven Van Asbroeck, Michal Hocko, kvm,
Michael S. Tsirkin, Peter Zijlstra, Thorsten Leemhuis,
David Howells, linux-mm, H. Peter Anvin, devel, Manfred Spraul,
Luis Chamberlain, x86, Pavel Tatashin, Mike Rapoport, Ingo Molnar,
Dave Young, devicetree, Arnaldo Carvalho de Melo, Jerome Glisse,
Stefano Stabellini, Jonathan Cameron, Dmitry Vyukov, linux-edac,
Juergen Gross, Denis Efremov, netdev, Nicolas Ferre, Changbin Du,
linux-security-module, linuxppc-dev, Andy Shevchenko
In-Reply-To: <64e136de-1a7b-3436-9675-44ea9fa7b64a@c-s.fr>
Em Mon, 3 Jun 2019 09:34:15 +0200
Christophe Leroy <christophe.leroy@c-s.fr> escreveu:
> Le 30/05/2019 à 01:23, Mauro Carvalho Chehab a écrit :
> > Mostly due to x86 and acpi conversion, several documentation
> > links are still pointing to the old file. Fix them.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > ---
> > Documentation/acpi/dsd/leds.txt | 2 +-
> > Documentation/admin-guide/kernel-parameters.rst | 6 +++---
> > Documentation/admin-guide/kernel-parameters.txt | 16 ++++++++--------
> > Documentation/admin-guide/ras.rst | 2 +-
> > .../devicetree/bindings/net/fsl-enetc.txt | 7 +++----
> > .../bindings/pci/amlogic,meson-pcie.txt | 2 +-
> > .../bindings/regulator/qcom,rpmh-regulator.txt | 2 +-
> > Documentation/devicetree/booting-without-of.txt | 2 +-
> > Documentation/driver-api/gpio/board.rst | 2 +-
> > Documentation/driver-api/gpio/consumer.rst | 2 +-
> > .../firmware-guide/acpi/enumeration.rst | 2 +-
> > .../firmware-guide/acpi/method-tracing.rst | 2 +-
> > Documentation/i2c/instantiating-devices | 2 +-
> > Documentation/sysctl/kernel.txt | 4 ++--
> > .../translations/it_IT/process/howto.rst | 2 +-
> > .../it_IT/process/stable-kernel-rules.rst | 4 ++--
> > .../translations/zh_CN/process/4.Coding.rst | 2 +-
> > Documentation/x86/x86_64/5level-paging.rst | 2 +-
> > Documentation/x86/x86_64/boot-options.rst | 4 ++--
> > .../x86/x86_64/fake-numa-for-cpusets.rst | 2 +-
> > MAINTAINERS | 6 +++---
> > arch/arm/Kconfig | 2 +-
> > arch/arm64/kernel/kexec_image.c | 2 +-
> > arch/powerpc/Kconfig | 2 +-
> > arch/x86/Kconfig | 16 ++++++++--------
> > arch/x86/Kconfig.debug | 2 +-
> > arch/x86/boot/header.S | 2 +-
> > arch/x86/entry/entry_64.S | 2 +-
> > arch/x86/include/asm/bootparam_utils.h | 2 +-
> > arch/x86/include/asm/page_64_types.h | 2 +-
> > arch/x86/include/asm/pgtable_64_types.h | 2 +-
> > arch/x86/kernel/cpu/microcode/amd.c | 2 +-
> > arch/x86/kernel/kexec-bzimage64.c | 2 +-
> > arch/x86/kernel/pci-dma.c | 2 +-
> > arch/x86/mm/tlb.c | 2 +-
> > arch/x86/platform/pvh/enlighten.c | 2 +-
> > drivers/acpi/Kconfig | 10 +++++-----
> > drivers/net/ethernet/faraday/ftgmac100.c | 2 +-
> > .../fieldbus/Documentation/fieldbus_dev.txt | 4 ++--
> > drivers/vhost/vhost.c | 2 +-
> > include/acpi/acpi_drivers.h | 2 +-
> > include/linux/fs_context.h | 2 +-
> > include/linux/lsm_hooks.h | 2 +-
> > mm/Kconfig | 2 +-
> > security/Kconfig | 2 +-
> > tools/include/linux/err.h | 2 +-
> > tools/objtool/Documentation/stack-validation.txt | 4 ++--
> > tools/testing/selftests/x86/protection_keys.c | 2 +-
> > 48 files changed, 77 insertions(+), 78 deletions(-)
>
> [...]
>
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 8c1c636308c8..e868d2bd48b8 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -898,7 +898,7 @@ config PPC_MEM_KEYS
> > page-based protections, but without requiring modification of the
> > page tables when an application changes protection domains.
> >
> > - For details, see Documentation/vm/protection-keys.rst
> > + For details, see Documentation/x86/protection-keys.rst
>
> It looks strange to reference an x86 file, for powerpc arch.
Indeed. Yet, seeking for the API documented there:
$ git grep -l pkey_mprotect
Documentation/x86/protection-keys.rst
arch/alpha/kernel/syscalls/syscall.tbl
arch/arm/tools/syscall.tbl
arch/arm64/include/asm/unistd32.h
arch/ia64/kernel/syscalls/syscall.tbl
arch/m68k/kernel/syscalls/syscall.tbl
arch/microblaze/kernel/syscalls/syscall.tbl
arch/mips/kernel/syscalls/syscall_n32.tbl
arch/mips/kernel/syscalls/syscall_n64.tbl
arch/mips/kernel/syscalls/syscall_o32.tbl
arch/parisc/kernel/syscalls/syscall.tbl
arch/powerpc/kernel/syscalls/syscall.tbl
arch/s390/kernel/syscalls/syscall.tbl
arch/sh/kernel/syscalls/syscall.tbl
arch/sparc/kernel/syscalls/syscall.tbl
arch/x86/entry/syscalls/syscall_32.tbl
arch/x86/entry/syscalls/syscall_64.tbl
arch/xtensa/kernel/syscalls/syscall.tbl
include/linux/syscalls.h
include/uapi/asm-generic/unistd.h
kernel/sys_ni.c
mm/mprotect.c
tools/include/uapi/asm-generic/unistd.h
tools/perf/arch/powerpc/entry/syscalls/syscall.tbl
tools/perf/arch/x86/entry/syscalls/syscall_64.tbl
tools/perf/builtin-trace.c
tools/testing/selftests/x86/protection_keys.c
Despite being used on several archs, the only documentation for it
is inside the x86 directory, as it seems that this is not
arch-specific.
Perhaps the file should, instead, be moved to another book.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH 22/22] docs: fix broken documentation links
From: Mauro Carvalho Chehab @ 2019-06-04 9:58 UTC (permalink / raw)
To: Christophe Leroy
Cc: Andrew Lunn, Thomas Preston, Wolfram Sang, Catalin Marinas,
Linus Walleij, Will Deacon, Russell King, Paul Mackerras,
Alessia Mantegazza, Jakub Wilk, AKASHI Takahiro, Kevin Hilman,
James Morris, linux-acpi, Andy Gross, xen-devel, Jason Wang,
Alexander Popov, Qian Cai, Al Viro, Andy Lutomirski,
Thomas Gleixner, Kairui Song, Quentin Perret, Greg Kroah-Hartman,
Rafael J. Wysocki, linux-kernel, Paul Burton, Jiri Kosina,
Casey Schaufler, Andrew Morton, Lu Baolu, Mark Rutland, Feng Tang,
Linux Doc Mailing List, Dave Hansen, Mimi Zohar, Kamalesh Babulal,
Masahiro Yamada, Yannik Sembritzki, Harry Wei, linux-i2c,
Shuah Khan, Stephen Rothwell, Paul E. McKenney, Alexandre Ghiti,
YueHaibing, Robert Moore, Bartosz Golaszewski, Len Brown,
David Brown, Joerg Roedel, linux-arm-msm, linux-gpio,
Claudiu Manoil, Florian Fainelli, Jacek Anaszewski, Bjorn Helgaas,
linux-amlogic, Boris Ostrovsky, Mika Westerberg, linux-arm-kernel,
Tony Luck, Sean Christopherson, Rob Herring, James Morse,
Robin Murphy, Samuel Mendoza-Jonas, linux-pci, Bhupesh Sharma,
Josh Poimboeuf, platform-driver-x86, Ding Xiang, linux-kselftest,
Alex Shi, Lorenzo Pieralisi, Baoquan He, Jonathan Corbet,
Raphael Gault, Joel Stanley, Federico Vaga, Darren Hart,
Erik Schmauss, Serge E. Hallyn, Palmer Dabbelt, Kees Cook,
Bartlomiej Zolnierkiewicz, Jonathan Neuschäfer,
SeongJae Park, Mark Brown, Borislav Petkov, Sunil Muthuswamy,
virtualization, devel, Ard Biesheuvel, Liam Girdwood,
Sakari Ailus, Olof Johansson, Logan Gunthorpe, David S. Miller,
Kirill A. Shutemov, Sven Van Asbroeck, Michal Hocko, kvm,
Michael S. Tsirkin, Peter Zijlstra, Thorsten Leemhuis,
David Howells, linux-mm, H. Peter Anvin, devel, Manfred Spraul,
Luis Chamberlain, x86, Pavel Tatashin, Mike Rapoport, Ingo Molnar,
Dave Young, devicetree, Arnaldo Carvalho de Melo, Jerome Glisse,
Stefano Stabellini, Jonathan Cameron, Dmitry Vyukov, linux-edac,
Juergen Gross, Denis Efremov, netdev, Nicolas Ferre, Changbin Du,
linux-security-module, linuxppc-dev, Andy Shevchenko
In-Reply-To: <20190604064614.67cde821@coco.lan>
Em Tue, 4 Jun 2019 06:46:14 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> escreveu:
> Em Mon, 3 Jun 2019 09:34:15 +0200
> Christophe Leroy <christophe.leroy@c-s.fr> escreveu:
>
> > [...]
> >
> > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > > index 8c1c636308c8..e868d2bd48b8 100644
> > > --- a/arch/powerpc/Kconfig
> > > +++ b/arch/powerpc/Kconfig
> > > @@ -898,7 +898,7 @@ config PPC_MEM_KEYS
> > > page-based protections, but without requiring modification of the
> > > page tables when an application changes protection domains.
> > >
> > > - For details, see Documentation/vm/protection-keys.rst
> > > + For details, see Documentation/x86/protection-keys.rst
> >
> > It looks strange to reference an x86 file, for powerpc arch.
>
> Indeed. Yet, seeking for the API documented there:
>
> $ git grep -l pkey_mprotect
> Documentation/x86/protection-keys.rst
> arch/alpha/kernel/syscalls/syscall.tbl
> arch/arm/tools/syscall.tbl
> arch/arm64/include/asm/unistd32.h
> arch/ia64/kernel/syscalls/syscall.tbl
> arch/m68k/kernel/syscalls/syscall.tbl
> arch/microblaze/kernel/syscalls/syscall.tbl
> arch/mips/kernel/syscalls/syscall_n32.tbl
> arch/mips/kernel/syscalls/syscall_n64.tbl
> arch/mips/kernel/syscalls/syscall_o32.tbl
> arch/parisc/kernel/syscalls/syscall.tbl
> arch/powerpc/kernel/syscalls/syscall.tbl
> arch/s390/kernel/syscalls/syscall.tbl
> arch/sh/kernel/syscalls/syscall.tbl
> arch/sparc/kernel/syscalls/syscall.tbl
> arch/x86/entry/syscalls/syscall_32.tbl
> arch/x86/entry/syscalls/syscall_64.tbl
> arch/xtensa/kernel/syscalls/syscall.tbl
> include/linux/syscalls.h
> include/uapi/asm-generic/unistd.h
> kernel/sys_ni.c
> mm/mprotect.c
> tools/include/uapi/asm-generic/unistd.h
> tools/perf/arch/powerpc/entry/syscalls/syscall.tbl
> tools/perf/arch/x86/entry/syscalls/syscall_64.tbl
> tools/perf/builtin-trace.c
> tools/testing/selftests/x86/protection_keys.c
>
> Despite being used on several archs, the only documentation for it
> is inside the x86 directory, as it seems that this is not
> arch-specific.
>
> Perhaps the file should, instead, be moved to another book.
I guess the best is to have this inside the core-api book.
Patch enclosed.
Regards,
Mauro
[PATCH] docs: move protection-keys.rst to the core-api book
This document is used by multiple architectures:
$ echo $(git grep -l pkey_mprotect arch|cut -d'/' -f 2|sort|uniq)
alpha arm arm64 ia64 m68k microblaze mips parisc powerpc s390 sh sparc x86 xtensa
So, let's move it to the core book and adjust the links to it
accordingly.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
index ee1bb8983a88..2466a4c51031 100644
--- a/Documentation/core-api/index.rst
+++ b/Documentation/core-api/index.rst
@@ -34,6 +34,7 @@ Core utilities
timekeeping
boot-time-mm
memory-hotplug
+ protection-keys
Interfaces for kernel debugging
diff --git a/Documentation/x86/protection-keys.rst b/Documentation/core-api/protection-keys.rst
similarity index 100%
rename from Documentation/x86/protection-keys.rst
rename to Documentation/core-api/protection-keys.rst
diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst
index ae36fc5fc649..f2de1b2d3ac7 100644
--- a/Documentation/x86/index.rst
+++ b/Documentation/x86/index.rst
@@ -19,7 +19,6 @@ x86-specific Documentation
tlb
mtrr
pat
- protection-keys
intel_mpx
amd-memory-encryption
pti
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8c1c636308c8..3b795a0cab62 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -898,7 +898,7 @@ config PPC_MEM_KEYS
page-based protections, but without requiring modification of the
page tables when an application changes protection domains.
- For details, see Documentation/vm/protection-keys.rst
+ For details, see Documentation/core-api/protection-keys.rst
If unsure, say y.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2bbbd4d1ba31..d87d53fcd261 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1911,7 +1911,7 @@ config X86_INTEL_MEMORY_PROTECTION_KEYS
page-based protections, but without requiring modification of the
page tables when an application changes protection domains.
- For details, see Documentation/x86/protection-keys.txt
+ For details, see Documentation/core-api/protection-keys.rst
If unsure, say y.
diff --git a/tools/testing/selftests/x86/protection_keys.c b/tools/testing/selftests/x86/protection_keys.c
index 5d546dcdbc80..480995bceefa 100644
--- a/tools/testing/selftests/x86/protection_keys.c
+++ b/tools/testing/selftests/x86/protection_keys.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Tests x86 Memory Protection Keys (see Documentation/x86/protection-keys.txt)
+ * Tests x86 Memory Protection Keys (see Documentation/core-api/protection-keys.rst)
*
* There are examples in here of:
* * how to set protection keys on memory
^ permalink raw reply related
* [PATCH] ocxl: do not use C++ style comments in uapi header
From: Masahiro Yamada @ 2019-06-04 11:16 UTC (permalink / raw)
To: Frederic Barrat, Andrew Donnellan, linuxppc-dev
Cc: Arnd Bergmann, Greg KH, Randy Dunlap, linux-kernel,
Masahiro Yamada, Joe Perches, Thomas Gleixner
Linux kernel tolerates C++ style comments these days. Actually, the
SPDX License tags for .c files start with //.
On the other hand, uapi headers are written in more strict C, where
the C++ comment style is forbidden.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
include/uapi/misc/ocxl.h | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
index 97937cfa3baa..6d29a60a896a 100644
--- a/include/uapi/misc/ocxl.h
+++ b/include/uapi/misc/ocxl.h
@@ -33,23 +33,23 @@ struct ocxl_ioctl_attach {
};
struct ocxl_ioctl_metadata {
- __u16 version; // struct version, always backwards compatible
+ __u16 version; /* struct version, always backwards compatible */
- // Version 0 fields
+ /* Version 0 fields */
__u8 afu_version_major;
__u8 afu_version_minor;
- __u32 pasid; // PASID assigned to the current context
+ __u32 pasid; /* PASID assigned to the current context */
- __u64 pp_mmio_size; // Per PASID MMIO size
+ __u64 pp_mmio_size; /* Per PASID MMIO size */
__u64 global_mmio_size;
- // End version 0 fields
+ /* End version 0 fields */
- __u64 reserved[13]; // Total of 16*u64
+ __u64 reserved[13]; /* Total of 16*u64 */
};
struct ocxl_ioctl_p9_wait {
- __u16 thread_id; // The thread ID required to wake this thread
+ __u16 thread_id; /* The thread ID required to wake this thread */
__u16 reserved1;
__u32 reserved2;
__u64 reserved3[3];
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 01/16] uaccess: add untagged_addr definition for other arches
From: Andrey Konovalov @ 2019-06-04 11:46 UTC (permalink / raw)
To: Christoph Hellwig
Cc: the arch/x86 maintainers, Rich Felker, Catalin Marinas,
Yoshinori Sato, linux-sh, James Hogan, PowerPC, Paul Burton,
Nicholas Piggin, linux-mips, Linux Memory Management List,
Khalid Aziz, Paul Mackerras, sparclinux, Linus Torvalds,
David S. Miller, LKML
In-Reply-To: <20190604072706.GF15680@lst.de>
On Tue, Jun 4, 2019 at 9:27 AM Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, Jun 03, 2019 at 09:16:08AM -0600, Khalid Aziz wrote:
> > Could you reword above sentence? We are already starting off with
> > untagged_addr() not being no-op for arm64 and sparc64. It will expand
> > further potentially. So something more along the lines of "Define it as
> > noop for architectures that do not support memory tagging". The first
> > paragraph in the log can also be rewritten to be not specific to arm64.
>
> Well, as of this patch this actually is a no-op for everyone.
>
> Linus, what do you think of applying this patch (maybe with a slightly
> fixed up commit log) to 5.2-rc so that we remove a cross dependency
> between the series?
(I have adjusted the patch description and have just sent it out
separately from the series).
^ permalink raw reply
* Re: [PATCH] ocxl: do not use C++ style comments in uapi header
From: Frederic Barrat @ 2019-06-04 11:51 UTC (permalink / raw)
To: Masahiro Yamada, Andrew Donnellan, linuxppc-dev
Cc: Arnd Bergmann, Greg KH, Randy Dunlap, linux-kernel, Joe Perches,
Thomas Gleixner
In-Reply-To: <20190604111632.22479-1-yamada.masahiro@socionext.com>
Le 04/06/2019 à 13:16, Masahiro Yamada a écrit :
> Linux kernel tolerates C++ style comments these days. Actually, the
> SPDX License tags for .c files start with //.
>
> On the other hand, uapi headers are written in more strict C, where
> the C++ comment style is forbidden.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
Thanks!
Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
>
> include/uapi/misc/ocxl.h | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
> index 97937cfa3baa..6d29a60a896a 100644
> --- a/include/uapi/misc/ocxl.h
> +++ b/include/uapi/misc/ocxl.h
> @@ -33,23 +33,23 @@ struct ocxl_ioctl_attach {
> };
>
> struct ocxl_ioctl_metadata {
> - __u16 version; // struct version, always backwards compatible
> + __u16 version; /* struct version, always backwards compatible */
>
> - // Version 0 fields
> + /* Version 0 fields */
> __u8 afu_version_major;
> __u8 afu_version_minor;
> - __u32 pasid; // PASID assigned to the current context
> + __u32 pasid; /* PASID assigned to the current context */
>
> - __u64 pp_mmio_size; // Per PASID MMIO size
> + __u64 pp_mmio_size; /* Per PASID MMIO size */
> __u64 global_mmio_size;
>
> - // End version 0 fields
> + /* End version 0 fields */
>
> - __u64 reserved[13]; // Total of 16*u64
> + __u64 reserved[13]; /* Total of 16*u64 */
> };
>
> struct ocxl_ioctl_p9_wait {
> - __u16 thread_id; // The thread ID required to wake this thread
> + __u16 thread_id; /* The thread ID required to wake this thread */
> __u16 reserved1;
> __u32 reserved2;
> __u64 reserved3[3];
>
^ permalink raw reply
* Re: [PATCH] ocxl: do not use C++ style comments in uapi header
From: Masahiro Yamada @ 2019-06-04 12:12 UTC (permalink / raw)
To: Frederic Barrat
Cc: Andrew Donnellan, Arnd Bergmann, Greg KH, Randy Dunlap,
Linux Kernel Mailing List, Joe Perches, Thomas Gleixner,
linuxppc-dev
In-Reply-To: <90aa6d91-7592-17b0-17fd-e33676bd0a46@linux.ibm.com>
On Tue, Jun 4, 2019 at 8:54 PM Frederic Barrat <fbarrat@linux.ibm.com> wrote:
>
>
>
> Le 04/06/2019 à 13:16, Masahiro Yamada a écrit :
> > Linux kernel tolerates C++ style comments these days. Actually, the
> > SPDX License tags for .c files start with //.
> >
> > On the other hand, uapi headers are written in more strict C, where
> > the C++ comment style is forbidden.
> >
> > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > ---
>
> Thanks!
> Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
>
Please hold on this patch until
we get consensus about the C++ comment style.
Discussion just started here:
https://lore.kernel.org/patchwork/patch/1083801/
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [RFC PATCH] powerpc/book3e: KASAN Full support for 64bit
From: Christophe Leroy @ 2019-06-04 12:43 UTC (permalink / raw)
To: Daniel Axtens, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <87woi2xm8l.fsf@dja-thinkpad.axtens.net>
On 06/03/2019 11:50 PM, Daniel Axtens wrote:
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>
>> Hi,
>>
>> Ok, can you share your .config ?
>
> Sure! This one is with kasan off as the last build I did was testing to
> see if the code reorgisation was the cause of the issues. (it was not)
>
>
>
>
> This was the kasan-enabled config that failed to boot:
>
>
Same issue with your .config under QEMU:
A go with gdb shows:
Breakpoint 3, 0xc000000000027b6c in exc_0x700_common ()
=> 0xc000000000027b6c <exc_0x700_common+0>: f8 01 00 70 std r0,112(r1)
(gdb) bt
#0 0xc000000000027b6c in exc_0x700_common ()
#1 0xc00000000136f80c in .udbg_init_memcons ()
Without CONFIG_PPC_EARLY_DEBUG, it boots fine for me. Can you check on
your side ?
Deactivating KASAN for arch/powerpc/kernel/udbg.o and
arch/powerpc/sysdev/udbg_memcons.o is not enough, we hit a call to
strstr() in register_early_udbg_console(), and once we get rid of it (in
the same way as in prom_init.c) the next issue is register_console() and
I don't know what to do about that one.
Christophe
>
>
> Regards,
> Daniel
>
>>
>> Christophe
>>
>> Le 31/05/2019 à 03:29, Daniel Axtens a écrit :
>>> Hi Christophe,
>>>
>>> I tried this on the t4240rdb and it fails to boot if KASAN is
>>> enabled. It does boot with the patch applied but KASAN disabled, so that
>>> narrows it down a little bit.
>>>
>>> I need to focus on 3s first so I'll just drop 3e from my patch set for
>>> now.
>>>
>>> Regards,
>>> Daniel
>>>
>>>> The KASAN shadow area is mapped into vmemmap space:
>>>> 0x8000 0400 0000 0000 to 0x8000 0600 0000 0000.
>>>> For this vmemmap has to be disabled.
>>>>
>>>> Cc: Daniel Axtens <dja@axtens.net>
>>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>>> ---
>>>> arch/powerpc/Kconfig | 1 +
>>>> arch/powerpc/Kconfig.debug | 3 +-
>>>> arch/powerpc/include/asm/kasan.h | 11 +++
>>>> arch/powerpc/kernel/Makefile | 2 +
>>>> arch/powerpc/kernel/head_64.S | 3 +
>>>> arch/powerpc/kernel/setup_64.c | 20 +++---
>>>> arch/powerpc/mm/kasan/Makefile | 1 +
>>>> arch/powerpc/mm/kasan/kasan_init_64.c | 129 ++++++++++++++++++++++++++++++++++
>>>> 8 files changed, 159 insertions(+), 11 deletions(-)
>>>> create mode 100644 arch/powerpc/mm/kasan/kasan_init_64.c
>>>>
>>>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>>>> index 1a2fb50126b2..e0b7c45e4dc7 100644
>>>> --- a/arch/powerpc/Kconfig
>>>> +++ b/arch/powerpc/Kconfig
>>>> @@ -174,6 +174,7 @@ config PPC
>>>> select HAVE_ARCH_AUDITSYSCALL
>>>> select HAVE_ARCH_JUMP_LABEL
>>>> select HAVE_ARCH_KASAN if PPC32
>>>> + select HAVE_ARCH_KASAN if PPC_BOOK3E_64 && !SPARSEMEM_VMEMMAP
>>>> select HAVE_ARCH_KGDB
>>>> select HAVE_ARCH_MMAP_RND_BITS
>>>> select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
>>>> diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
>>>> index 61febbbdd02b..b4140dd6b4e4 100644
>>>> --- a/arch/powerpc/Kconfig.debug
>>>> +++ b/arch/powerpc/Kconfig.debug
>>>> @@ -370,4 +370,5 @@ config PPC_FAST_ENDIAN_SWITCH
>>>> config KASAN_SHADOW_OFFSET
>>>> hex
>>>> depends on KASAN
>>>> - default 0xe0000000
>>>> + default 0xe0000000 if PPC32
>>>> + default 0x6800040000000000 if PPC64
>>>> diff --git a/arch/powerpc/include/asm/kasan.h b/arch/powerpc/include/asm/kasan.h
>>>> index 296e51c2f066..756b3d58f921 100644
>>>> --- a/arch/powerpc/include/asm/kasan.h
>>>> +++ b/arch/powerpc/include/asm/kasan.h
>>>> @@ -23,10 +23,21 @@
>>>>
>>>> #define KASAN_SHADOW_OFFSET ASM_CONST(CONFIG_KASAN_SHADOW_OFFSET)
>>>>
>>>> +#ifdef CONFIG_PPC32
>>>> #define KASAN_SHADOW_END 0UL
>>>>
>>>> #define KASAN_SHADOW_SIZE (KASAN_SHADOW_END - KASAN_SHADOW_START)
>>>>
>>>> +#else
>>>> +
>>>> +#include <asm/pgtable.h>
>>>> +
>>>> +#define KASAN_SHADOW_SIZE (KERN_VIRT_SIZE >> KASAN_SHADOW_SCALE_SHIFT)
>>>> +
>>>> +#define KASAN_SHADOW_END (KASAN_SHADOW_START + KASAN_SHADOW_SIZE)
>>>> +
>>>> +#endif /* CONFIG_PPC32 */
>>>> +
>>>> #ifdef CONFIG_KASAN
>>>> void kasan_early_init(void);
>>>> void kasan_mmu_init(void);
>>>> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
>>>> index 0ea6c4aa3a20..7f232c06f11d 100644
>>>> --- a/arch/powerpc/kernel/Makefile
>>>> +++ b/arch/powerpc/kernel/Makefile
>>>> @@ -35,6 +35,8 @@ KASAN_SANITIZE_early_32.o := n
>>>> KASAN_SANITIZE_cputable.o := n
>>>> KASAN_SANITIZE_prom_init.o := n
>>>> KASAN_SANITIZE_btext.o := n
>>>> +KASAN_SANITIZE_paca.o := n
>>>> +KASAN_SANITIZE_setup_64.o := n
>>>>
>>>> ifdef CONFIG_KASAN
>>>> CFLAGS_early_32.o += -DDISABLE_BRANCH_PROFILING
>>>> diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
>>>> index 3fad8d499767..80fbd8024fb2 100644
>>>> --- a/arch/powerpc/kernel/head_64.S
>>>> +++ b/arch/powerpc/kernel/head_64.S
>>>> @@ -966,6 +966,9 @@ start_here_multiplatform:
>>>> * and SLB setup before we turn on relocation.
>>>> */
>>>>
>>>> +#ifdef CONFIG_KASAN
>>>> + bl kasan_early_init
>>>> +#endif
>>>> /* Restore parameters passed from prom_init/kexec */
>>>> mr r3,r31
>>>> bl early_setup /* also sets r13 and SPRG_PACA */
>>>> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
>>>> index ba404dd9ce1d..d2bf860dd966 100644
>>>> --- a/arch/powerpc/kernel/setup_64.c
>>>> +++ b/arch/powerpc/kernel/setup_64.c
>>>> @@ -311,6 +311,16 @@ void __init early_setup(unsigned long dt_ptr)
>>>> DBG(" -> early_setup(), dt_ptr: 0x%lx\n", dt_ptr);
>>>>
>>>> /*
>>>> + * Configure exception handlers. This include setting up trampolines
>>>> + * if needed, setting exception endian mode, etc...
>>>> + */
>>>> + configure_exceptions();
>>>> +
>>>> + /* Apply all the dynamic patching */
>>>> + apply_feature_fixups();
>>>> + setup_feature_keys();
>>>> +
>>>> + /*
>>>> * Do early initialization using the flattened device
>>>> * tree, such as retrieving the physical memory map or
>>>> * calculating/retrieving the hash table size.
>>>> @@ -325,16 +335,6 @@ void __init early_setup(unsigned long dt_ptr)
>>>> setup_paca(paca_ptrs[boot_cpuid]);
>>>> fixup_boot_paca();
>>>>
>>>> - /*
>>>> - * Configure exception handlers. This include setting up trampolines
>>>> - * if needed, setting exception endian mode, etc...
>>>> - */
>>>> - configure_exceptions();
>>>> -
>>>> - /* Apply all the dynamic patching */
>>>> - apply_feature_fixups();
>>>> - setup_feature_keys();
>>>> -
>>>> /* Initialize the hash table or TLB handling */
>>>> early_init_mmu();
>>>>
>>>> diff --git a/arch/powerpc/mm/kasan/Makefile b/arch/powerpc/mm/kasan/Makefile
>>>> index 6577897673dd..0bfbe3892808 100644
>>>> --- a/arch/powerpc/mm/kasan/Makefile
>>>> +++ b/arch/powerpc/mm/kasan/Makefile
>>>> @@ -3,3 +3,4 @@
>>>> KASAN_SANITIZE := n
>>>>
>>>> obj-$(CONFIG_PPC32) += kasan_init_32.o
>>>> +obj-$(CONFIG_PPC64) += kasan_init_64.o
>>>> diff --git a/arch/powerpc/mm/kasan/kasan_init_64.c b/arch/powerpc/mm/kasan/kasan_init_64.c
>>>> new file mode 100644
>>>> index 000000000000..7fd71b8e883b
>>>> --- /dev/null
>>>> +++ b/arch/powerpc/mm/kasan/kasan_init_64.c
>>>> @@ -0,0 +1,129 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +
>>>> +#define DISABLE_BRANCH_PROFILING
>>>> +
>>>> +#include <linux/kasan.h>
>>>> +#include <linux/printk.h>
>>>> +#include <linux/memblock.h>
>>>> +#include <linux/sched/task.h>
>>>> +#include <asm/pgalloc.h>
>>>> +
>>>> +static void __init kasan_populate_pte(pte_t *ptep, pgprot_t prot)
>>>> +{
>>>> + unsigned long va = (unsigned long)kasan_early_shadow_page;
>>>> + phys_addr_t pa = __pa(kasan_early_shadow_page);
>>>> + int i;
>>>> +
>>>> + for (i = 0; i < PTRS_PER_PTE; i++, ptep++)
>>>> + __set_pte_at(&init_mm, va, ptep, pfn_pte(PHYS_PFN(pa), prot), 0);
>>>> +}
>>>> +
>>>> +static void __init kasan_populate_pmd(pmd_t *pmdp)
>>>> +{
>>>> + int i;
>>>> +
>>>> + for (i = 0; i < PTRS_PER_PMD; i++)
>>>> + pmd_populate_kernel(&init_mm, pmdp + i, kasan_early_shadow_pte);
>>>> +}
>>>> +
>>>> +static void __init kasan_populate_pud(pud_t *pudp)
>>>> +{
>>>> + int i;
>>>> +
>>>> + for (i = 0; i < PTRS_PER_PUD; i++)
>>>> + pud_populate(&init_mm, pudp + i, kasan_early_shadow_pmd);
>>>> +}
>>>> +
>>>> +static void __init *kasan_alloc_pgtable(unsigned long size)
>>>> +{
>>>> + void *ptr = memblock_alloc_try_nid(size, size, MEMBLOCK_LOW_LIMIT,
>>>> + __pa(MAX_DMA_ADDRESS), NUMA_NO_NODE);
>>>> +
>>>> + if (!ptr)
>>>> + panic("%s: Failed to allocate %lu bytes align=0x%lx max_addr=%lx\n",
>>>> + __func__, size, size, __pa(MAX_DMA_ADDRESS));
>>>> +
>>>> + return ptr;
>>>> +}
>>>> +
>>>> +static int __init kasan_map_page(unsigned long va, unsigned long pa, pgprot_t prot)
>>>> +{
>>>> + pgd_t *pgdp = pgd_offset_k(va);
>>>> + pud_t *pudp;
>>>> + pmd_t *pmdp;
>>>> + pte_t *ptep;
>>>> +
>>>> + if (pgd_none(*pgdp) || (void *)pgd_page_vaddr(*pgdp) == kasan_early_shadow_pud) {
>>>> + pudp = kasan_alloc_pgtable(PUD_TABLE_SIZE);
>>>> + kasan_populate_pud(pudp);
>>>> + pgd_populate(&init_mm, pgdp, pudp);
>>>> + }
>>>> + pudp = pud_offset(pgdp, va);
>>>> + if (pud_none(*pudp) || (void *)pud_page_vaddr(*pudp) == kasan_early_shadow_pmd) {
>>>> + pmdp = kasan_alloc_pgtable(PMD_TABLE_SIZE);
>>>> + kasan_populate_pmd(pmdp);
>>>> + pud_populate(&init_mm, pudp, pmdp);
>>>> + }
>>>> + pmdp = pmd_offset(pudp, va);
>>>> + if (!pmd_present(*pmdp) || (void *)pmd_page_vaddr(*pmdp) == kasan_early_shadow_pte) {
>>>> + ptep = kasan_alloc_pgtable(PTE_TABLE_SIZE);
>>>> + kasan_populate_pte(ptep, PAGE_KERNEL);
>>>> + pmd_populate_kernel(&init_mm, pmdp, ptep);
>>>> + }
>>>> + ptep = pte_offset_kernel(pmdp, va);
>>>> +
>>>> + __set_pte_at(&init_mm, va, ptep, pfn_pte(pa >> PAGE_SHIFT, prot), 0);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static void __init kasan_init_region(struct memblock_region *reg)
>>>> +{
>>>> + void *start = __va(reg->base);
>>>> + void *end = __va(reg->base + reg->size);
>>>> + unsigned long k_start, k_end, k_cur;
>>>> +
>>>> + if (start >= end)
>>>> + return;
>>>> +
>>>> + k_start = (unsigned long)kasan_mem_to_shadow(start);
>>>> + k_end = (unsigned long)kasan_mem_to_shadow(end);
>>>> +
>>>> + for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE) {
>>>> + void *va = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
>>>> +
>>>> + kasan_map_page(k_cur, __pa(va), PAGE_KERNEL);
>>>> + }
>>>> + flush_tlb_kernel_range(k_start, k_end);
>>>> +}
>>>> +
>>>> +void __init kasan_init(void)
>>>> +{
>>>> + struct memblock_region *reg;
>>>> +
>>>> + for_each_memblock(memory, reg)
>>>> + kasan_init_region(reg);
>>>> +
>>>> + /* It's too early to use clear_page() ! */
>>>> + memset(kasan_early_shadow_page, 0, sizeof(kasan_early_shadow_page));
>>>> +
>>>> + /* Enable error messages */
>>>> + init_task.kasan_depth = 0;
>>>> + pr_info("KASAN init done\n");
>>>> +}
>>>> +
>>>> +/* The early shadow maps everything to a single page of zeroes */
>>>> +asmlinkage void __init kasan_early_init(void)
>>>> +{
>>>> + unsigned long addr = KASAN_SHADOW_START;
>>>> + unsigned long end = KASAN_SHADOW_END;
>>>> + pgd_t *pgdp = pgd_offset_k(addr);
>>>> +
>>>> + kasan_populate_pte(kasan_early_shadow_pte, PAGE_KERNEL);
>>>> + kasan_populate_pmd(kasan_early_shadow_pmd);
>>>> + kasan_populate_pud(kasan_early_shadow_pud);
>>>> +
>>>> + do {
>>>> + pgd_populate(&init_mm, pgdp, kasan_early_shadow_pud);
>>>> + } while (pgdp++, addr = pgd_addr_end(addr, end), addr != end);
>>>> +}
>>>> --
>>>> 2.13.3
^ permalink raw reply
* Re: [PATCH v5 1/3] powerpc: Fix vDSO clock_getres()
From: Sasha Levin @ 2019-06-04 12:50 UTC (permalink / raw)
To: Sasha Levin, Vincenzo Frascino, linux-arch, linuxppc-dev
Cc: stable, Paul Mackerras, vincenzo.frascino
In-Reply-To: <20190528120446.48911-2-vincenzo.frascino@arm.com>
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: a7f290dad32e [PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel.
The bot has tested the following trees: v5.1.6, v5.0.20, v4.19.47, v4.14.123, v4.9.180, v4.4.180.
v5.1.6: Build OK!
v5.0.20: Build OK!
v4.19.47: Build OK!
v4.14.123: Failed to apply! Possible dependencies:
5c929885f1bb ("powerpc/vdso64: Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE")
b5b4453e7912 ("powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across Y2038")
v4.9.180: Failed to apply! Possible dependencies:
454656155110 ("powerpc/asm: Use OFFSET macro in asm-offsets.c")
5c929885f1bb ("powerpc/vdso64: Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE")
5d451a87e5eb ("powerpc/64: Retrieve number of L1 cache sets from device-tree")
7c5b06cadf27 ("KVM: PPC: Book3S HV: Adapt TLB invalidations to work on POWER9")
83677f551e0a ("KVM: PPC: Book3S HV: Adjust host/guest context switch for POWER9")
902e06eb86cd ("powerpc/32: Change the stack protector canary value per task")
b5b4453e7912 ("powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across Y2038")
bd067f83b084 ("powerpc/64: Fix naming of cache block vs. cache line")
e2827fe5c156 ("powerpc/64: Clean up ppc64_caches using a struct per cache")
e9cf1e085647 ("KVM: PPC: Book3S HV: Add new POWER9 guest-accessible SPRs")
f4c51f841d2a ("KVM: PPC: Book3S HV: Modify guest entry/exit paths to handle radix guests")
v4.4.180: Failed to apply! Possible dependencies:
153086644fd1 ("powerpc/ftrace: Add support for -mprofile-kernel ftrace ABI")
3eb5d5888dc6 ("powerpc: Add ppc_strict_facility_enable boot option")
454656155110 ("powerpc/asm: Use OFFSET macro in asm-offsets.c")
579e633e764e ("powerpc: create flush_all_to_thread()")
5c929885f1bb ("powerpc/vdso64: Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE")
70fe3d980f5f ("powerpc: Restore FPU/VEC/VSX if previously used")
85baa095497f ("powerpc/livepatch: Add live patching support on ppc64le")
902e06eb86cd ("powerpc/32: Change the stack protector canary value per task")
b5b4453e7912 ("powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across Y2038")
bf76f73c5f65 ("powerpc: enable UBSAN support")
c208505900b2 ("powerpc: create giveup_all()")
d1e1cf2e38de ("powerpc: clean up asm/switch_to.h")
dc4fbba11e46 ("powerpc: Create disable_kernel_{fp,altivec,vsx,spe}()")
f17c4e01e906 ("powerpc/module: Mark module stubs with a magic value")
How should we proceed with this patch?
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v4 3/3] kselftest: Extend vDSO selftest to clock_getres
From: Christophe Leroy @ 2019-06-04 13:16 UTC (permalink / raw)
To: Vincenzo Frascino, Michael Ellerman, linux-arch, linuxppc-dev,
linux-s390, linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Paul Mackerras, Martin Schwidefsky,
Thomas Gleixner, Shuah Khan
In-Reply-To: <afb7395f-43e9-c304-2db2-349e6727b687@arm.com>
Hi Vincenzo
Le 28/05/2019 à 13:57, Vincenzo Frascino a écrit :
> Hi Michael,
>
> thank you for your reply.
>
> On 28/05/2019 07:19, Michael Ellerman wrote:
>> Vincenzo Frascino <vincenzo.frascino@arm.com> writes:
>>
>>> The current version of the multiarch vDSO selftest verifies only
>>> gettimeofday.
>>>
>>> Extend the vDSO selftest to clock_getres, to verify that the
>>> syscall and the vDSO library function return the same information.
>>>
>>> The extension has been used to verify the hrtimer_resoltion fix.
>>
>> This is passing for me even without patch 1 applied, shouldn't it fail
>> without the fix? What am I missing?
>>
>
> This is correct, because during the refactoring process I missed an "n" :)
>
> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_sec·!=·y.tv_sec))
>
> Should be:
>
> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_nsec·!=·y.tv_nsec))
>
> My mistake, I am going to fix the test and re-post v5 of this set.
>
> Without my patch if you pass "highres=off" to the kernel (as a command line
> parameter) it leads to a broken implementation of clock_getres since the value
> of CLOCK_REALTIME_RES does not change at runtime.
>
> Expected result (with highres=off):
>
> # uname -r
> 5.2.0-rc2
> # ./vdso_clock_getres
> clock_id: CLOCK_REALTIME [FAIL]
> clock_id: CLOCK_BOOTTIME [PASS]
> clock_id: CLOCK_TAI [PASS]
> clock_id: CLOCK_REALTIME_COARSE [PASS]
> clock_id: CLOCK_MONOTONIC [FAIL]
> clock_id: CLOCK_MONOTONIC_RAW [PASS]
> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>
> The reason of this behavior is that the only clocks supported by getres on
> powerpc are CLOCK_REALTIME and CLOCK_MONOTONIC, the rest on the clocks use
> always syscalls.
vdso64 is supposed to implement CLOCK_{REALTIME/MONOTONIC}_COARSE, so I
guess it should fail for them too ?
Or is your test done on vdso32 ?
Christophe
>
>> # uname -r
>> 5.2.0-rc2-gcc-8.2.0
>>
>> # ./vdso_clock_getres
>> clock_id: CLOCK_REALTIME [PASS]
>> clock_id: CLOCK_BOOTTIME [PASS]
>> clock_id: CLOCK_TAI [PASS]
>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>> clock_id: CLOCK_MONOTONIC [PASS]
>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>
>> cheers
>>
>>> Cc: Shuah Khan <shuah@kernel.org>
>>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
>>> ---
>>>
>>> Note: This patch is independent from the others in this series, hence it
>>> can be merged singularly by the kselftest maintainers.
>>>
>>> tools/testing/selftests/vDSO/Makefile | 2 +
>>> .../selftests/vDSO/vdso_clock_getres.c | 124 ++++++++++++++++++
>>> 2 files changed, 126 insertions(+)
>>> create mode 100644 tools/testing/selftests/vDSO/vdso_clock_getres.c
>
^ permalink raw reply
* Re: [PATCH v4 3/3] kselftest: Extend vDSO selftest to clock_getres
From: Vincenzo Frascino @ 2019-06-04 13:32 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman, linux-arch, linuxppc-dev,
linux-s390, linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Paul Mackerras, Martin Schwidefsky,
Thomas Gleixner, Shuah Khan
In-Reply-To: <5c99721a-ce6b-10a0-99f2-6c37c1da4542@c-s.fr>
Hi Christophe,
On 04/06/2019 14:16, Christophe Leroy wrote:
> Hi Vincenzo
>
> Le 28/05/2019 à 13:57, Vincenzo Frascino a écrit :
>> Hi Michael,
>>
>> thank you for your reply.
>>
>> On 28/05/2019 07:19, Michael Ellerman wrote:
>>> Vincenzo Frascino <vincenzo.frascino@arm.com> writes:
>>>
>>>> The current version of the multiarch vDSO selftest verifies only
>>>> gettimeofday.
>>>>
>>>> Extend the vDSO selftest to clock_getres, to verify that the
>>>> syscall and the vDSO library function return the same information.
>>>>
>>>> The extension has been used to verify the hrtimer_resoltion fix.
>>>
>>> This is passing for me even without patch 1 applied, shouldn't it fail
>>> without the fix? What am I missing?
>>>
>>
>> This is correct, because during the refactoring process I missed an "n" :)
>>
>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_sec·!=·y.tv_sec))
>>
>> Should be:
>>
>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_nsec·!=·y.tv_nsec))
>>
>> My mistake, I am going to fix the test and re-post v5 of this set.
>>
>> Without my patch if you pass "highres=off" to the kernel (as a command line
>> parameter) it leads to a broken implementation of clock_getres since the value
>> of CLOCK_REALTIME_RES does not change at runtime.
>>
>> Expected result (with highres=off):
>>
>> # uname -r
>> 5.2.0-rc2
>> # ./vdso_clock_getres
>> clock_id: CLOCK_REALTIME [FAIL]
>> clock_id: CLOCK_BOOTTIME [PASS]
>> clock_id: CLOCK_TAI [PASS]
>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>> clock_id: CLOCK_MONOTONIC [FAIL]
>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>
>> The reason of this behavior is that the only clocks supported by getres on
>> powerpc are CLOCK_REALTIME and CLOCK_MONOTONIC, the rest on the clocks use
>> always syscalls.
>
> vdso64 is supposed to implement CLOCK_{REALTIME/MONOTONIC}_COARSE, so I
> guess it should fail for them too ?
>
> Or is your test done on vdso32 ?
>
Based on what I can see in kernel/vdso64 in 5.2-rc3:
/*
* Exact prototype of clock_getres()
*
* int __kernel_clock_getres(clockid_t clock_id, struct timespec *res);
*
*/
V_FUNCTION_BEGIN(__kernel_clock_getres)
.cfi_startproc
/* Check for supported clock IDs */
cmpwi cr0,r3,CLOCK_REALTIME
cmpwi cr1,r3,CLOCK_MONOTONIC
cror cr0*4+eq,cr0*4+eq,cr1*4+eq
bne cr0,99f
li r3,0
cmpldi cr0,r4,0
crclr cr0*4+so
beqlr
lis r5,CLOCK_REALTIME_RES@h
ori r5,r5,CLOCK_REALTIME_RES@l
std r3,TSPC64_TV_SEC(r4)
std r5,TSPC64_TV_NSEC(r4)
blr
/*
* syscall fallback
*/
99:
li r0,__NR_clock_getres
sc
blr
.cfi_endproc
V_FUNCTION_END(__kernel_clock_getres)
it does not seem so for what concerns vdso64. I did run again the test both on
ppc and ppc64 qemu instances and the result is the same to what I reported in
this thread.
Am I missing something?
> Christophe
>
>>
>>> # uname -r
>>> 5.2.0-rc2-gcc-8.2.0
>>>
>>> # ./vdso_clock_getres
>>> clock_id: CLOCK_REALTIME [PASS]
>>> clock_id: CLOCK_BOOTTIME [PASS]
>>> clock_id: CLOCK_TAI [PASS]
>>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>>> clock_id: CLOCK_MONOTONIC [PASS]
>>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>>
>>> cheers
>>>
>>>> Cc: Shuah Khan <shuah@kernel.org>
>>>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
>>>> ---
>>>>
>>>> Note: This patch is independent from the others in this series, hence it
>>>> can be merged singularly by the kselftest maintainers.
>>>>
>>>> tools/testing/selftests/vDSO/Makefile | 2 +
>>>> .../selftests/vDSO/vdso_clock_getres.c | 124 ++++++++++++++++++
>>>> 2 files changed, 126 insertions(+)
>>>> create mode 100644 tools/testing/selftests/vDSO/vdso_clock_getres.c
>>
--
Regards,
Vincenzo
^ permalink raw reply
* Re: [PATCH v4 3/3] kselftest: Extend vDSO selftest to clock_getres
From: Christophe Leroy @ 2019-06-04 13:39 UTC (permalink / raw)
To: Vincenzo Frascino, Michael Ellerman, linux-arch, linuxppc-dev,
linux-s390, linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Paul Mackerras, Martin Schwidefsky,
Thomas Gleixner, Shuah Khan
In-Reply-To: <b710d906-edac-f8a7-792b-e6822399187c@arm.com>
Le 04/06/2019 à 15:32, Vincenzo Frascino a écrit :
> Hi Christophe,
>
> On 04/06/2019 14:16, Christophe Leroy wrote:
>> Hi Vincenzo
>>
>> Le 28/05/2019 à 13:57, Vincenzo Frascino a écrit :
>>> Hi Michael,
>>>
>>> thank you for your reply.
>>>
>>> On 28/05/2019 07:19, Michael Ellerman wrote:
>>>> Vincenzo Frascino <vincenzo.frascino@arm.com> writes:
>>>>
>>>>> The current version of the multiarch vDSO selftest verifies only
>>>>> gettimeofday.
>>>>>
>>>>> Extend the vDSO selftest to clock_getres, to verify that the
>>>>> syscall and the vDSO library function return the same information.
>>>>>
>>>>> The extension has been used to verify the hrtimer_resoltion fix.
>>>>
>>>> This is passing for me even without patch 1 applied, shouldn't it fail
>>>> without the fix? What am I missing?
>>>>
>>>
>>> This is correct, because during the refactoring process I missed an "n" :)
>>>
>>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_sec·!=·y.tv_sec))
>>>
>>> Should be:
>>>
>>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_nsec·!=·y.tv_nsec))
>>>
>>> My mistake, I am going to fix the test and re-post v5 of this set.
>>>
>>> Without my patch if you pass "highres=off" to the kernel (as a command line
>>> parameter) it leads to a broken implementation of clock_getres since the value
>>> of CLOCK_REALTIME_RES does not change at runtime.
>>>
>>> Expected result (with highres=off):
>>>
>>> # uname -r
>>> 5.2.0-rc2
>>> # ./vdso_clock_getres
>>> clock_id: CLOCK_REALTIME [FAIL]
>>> clock_id: CLOCK_BOOTTIME [PASS]
>>> clock_id: CLOCK_TAI [PASS]
>>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>>> clock_id: CLOCK_MONOTONIC [FAIL]
>>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>>
>>> The reason of this behavior is that the only clocks supported by getres on
>>> powerpc are CLOCK_REALTIME and CLOCK_MONOTONIC, the rest on the clocks use
>>> always syscalls.
>>
>> vdso64 is supposed to implement CLOCK_{REALTIME/MONOTONIC}_COARSE, so I
>> guess it should fail for them too ?
>>
>> Or is your test done on vdso32 ?
>>
>
> Based on what I can see in kernel/vdso64 in 5.2-rc3:
>
> /*
> * Exact prototype of clock_getres()
> *
> * int __kernel_clock_getres(clockid_t clock_id, struct timespec *res);
> *
> */
> V_FUNCTION_BEGIN(__kernel_clock_getres)
> .cfi_startproc
> /* Check for supported clock IDs */
> cmpwi cr0,r3,CLOCK_REALTIME
> cmpwi cr1,r3,CLOCK_MONOTONIC
> cror cr0*4+eq,cr0*4+eq,cr1*4+eq
> bne cr0,99f
>
> li r3,0
> cmpldi cr0,r4,0
> crclr cr0*4+so
> beqlr
> lis r5,CLOCK_REALTIME_RES@h
> ori r5,r5,CLOCK_REALTIME_RES@l
> std r3,TSPC64_TV_SEC(r4)
> std r5,TSPC64_TV_NSEC(r4)
> blr
>
> /*
> * syscall fallback
> */
> 99:
> li r0,__NR_clock_getres
> sc
> blr
> .cfi_endproc
> V_FUNCTION_END(__kernel_clock_getres)
>
> it does not seem so for what concerns vdso64. I did run again the test both on
> ppc and ppc64 qemu instances and the result is the same to what I reported in
> this thread.
>
> Am I missing something?
I was thinking about
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5c929885f1bb
but apparently clock_getres() was left aside. Should we do something
about it ?
Christophe
>
>> Christophe
>>
>>>
>>>> # uname -r
>>>> 5.2.0-rc2-gcc-8.2.0
>>>>
>>>> # ./vdso_clock_getres
>>>> clock_id: CLOCK_REALTIME [PASS]
>>>> clock_id: CLOCK_BOOTTIME [PASS]
>>>> clock_id: CLOCK_TAI [PASS]
>>>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>>>> clock_id: CLOCK_MONOTONIC [PASS]
>>>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>>>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>>>
>>>> cheers
>>>>
>>>>> Cc: Shuah Khan <shuah@kernel.org>
>>>>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
>>>>> ---
>>>>>
>>>>> Note: This patch is independent from the others in this series, hence it
>>>>> can be merged singularly by the kselftest maintainers.
>>>>>
>>>>> tools/testing/selftests/vDSO/Makefile | 2 +
>>>>> .../selftests/vDSO/vdso_clock_getres.c | 124 ++++++++++++++++++
>>>>> 2 files changed, 126 insertions(+)
>>>>> create mode 100644 tools/testing/selftests/vDSO/vdso_clock_getres.c
>>>
>
^ permalink raw reply
* Re: [POWERPC][next-20190603] Boot failure : Kernel BUG at mm/vmalloc.c:470
From: Sachin Sant @ 2019-06-04 13:39 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-mm, linux-next, linuxppc-dev, linux-kernel,
Uladzislau Rezki (Sony)
In-Reply-To: <20190604202918.17a1e466@canb.auug.org.au>
> On 04-Jun-2019, at 3:59 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Sachin,
>
> On Tue, 4 Jun 2019 14:45:43 +0530 Sachin Sant <sachinp@linux.vnet.ibm.com> wrote:
>>
>> While booting linux-next [next-20190603] on a POWER9 LPAR following
>> BUG is encountered and the boot fails.
>>
>> If I revert the following 2 patches I no longer see this BUG message
>>
>> 07031d37b2f9 ( mm/vmalloc.c: switch to WARN_ON() and move it under unlink_va() )
>> 728e0fbf263e ( mm/vmalloc.c: get rid of one single unlink_va() when merge )
>
> This latter patch has been fixed in today's linux-next …
Thanks Stephen.
With today’s next (20190604) I no longer see this issue.
Thanks
-Sachin
^ permalink raw reply
* Re: [PATCH v4 3/3] kselftest: Extend vDSO selftest to clock_getres
From: Vincenzo Frascino @ 2019-06-04 13:43 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman, linux-arch, linuxppc-dev,
linux-s390, linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Paul Mackerras, Martin Schwidefsky,
Thomas Gleixner, Shuah Khan
In-Reply-To: <dd8bf915-f438-74f0-494e-427d10fc0505@c-s.fr>
On 04/06/2019 14:39, Christophe Leroy wrote:
>
>
> Le 04/06/2019 à 15:32, Vincenzo Frascino a écrit :
>> Hi Christophe,
>>
>> On 04/06/2019 14:16, Christophe Leroy wrote:
>>> Hi Vincenzo
>>>
>>> Le 28/05/2019 à 13:57, Vincenzo Frascino a écrit :
>>>> Hi Michael,
>>>>
>>>> thank you for your reply.
>>>>
>>>> On 28/05/2019 07:19, Michael Ellerman wrote:
>>>>> Vincenzo Frascino <vincenzo.frascino@arm.com> writes:
>>>>>
>>>>>> The current version of the multiarch vDSO selftest verifies only
>>>>>> gettimeofday.
>>>>>>
>>>>>> Extend the vDSO selftest to clock_getres, to verify that the
>>>>>> syscall and the vDSO library function return the same information.
>>>>>>
>>>>>> The extension has been used to verify the hrtimer_resoltion fix.
>>>>>
>>>>> This is passing for me even without patch 1 applied, shouldn't it fail
>>>>> without the fix? What am I missing?
>>>>>
>>>>
>>>> This is correct, because during the refactoring process I missed an "n" :)
>>>>
>>>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_sec·!=·y.tv_sec))
>>>>
>>>> Should be:
>>>>
>>>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_nsec·!=·y.tv_nsec))
>>>>
>>>> My mistake, I am going to fix the test and re-post v5 of this set.
>>>>
>>>> Without my patch if you pass "highres=off" to the kernel (as a command line
>>>> parameter) it leads to a broken implementation of clock_getres since the value
>>>> of CLOCK_REALTIME_RES does not change at runtime.
>>>>
>>>> Expected result (with highres=off):
>>>>
>>>> # uname -r
>>>> 5.2.0-rc2
>>>> # ./vdso_clock_getres
>>>> clock_id: CLOCK_REALTIME [FAIL]
>>>> clock_id: CLOCK_BOOTTIME [PASS]
>>>> clock_id: CLOCK_TAI [PASS]
>>>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>>>> clock_id: CLOCK_MONOTONIC [FAIL]
>>>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>>>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>>>
>>>> The reason of this behavior is that the only clocks supported by getres on
>>>> powerpc are CLOCK_REALTIME and CLOCK_MONOTONIC, the rest on the clocks use
>>>> always syscalls.
>>>
>>> vdso64 is supposed to implement CLOCK_{REALTIME/MONOTONIC}_COARSE, so I
>>> guess it should fail for them too ?
>>>
>>> Or is your test done on vdso32 ?
>>>
>>
>> Based on what I can see in kernel/vdso64 in 5.2-rc3:
>>
>> /*
>> * Exact prototype of clock_getres()
>> *
>> * int __kernel_clock_getres(clockid_t clock_id, struct timespec *res);
>> *
>> */
>> V_FUNCTION_BEGIN(__kernel_clock_getres)
>> .cfi_startproc
>> /* Check for supported clock IDs */
>> cmpwi cr0,r3,CLOCK_REALTIME
>> cmpwi cr1,r3,CLOCK_MONOTONIC
>> cror cr0*4+eq,cr0*4+eq,cr1*4+eq
>> bne cr0,99f
>>
>> li r3,0
>> cmpldi cr0,r4,0
>> crclr cr0*4+so
>> beqlr
>> lis r5,CLOCK_REALTIME_RES@h
>> ori r5,r5,CLOCK_REALTIME_RES@l
>> std r3,TSPC64_TV_SEC(r4)
>> std r5,TSPC64_TV_NSEC(r4)
>> blr
>>
>> /*
>> * syscall fallback
>> */
>> 99:
>> li r0,__NR_clock_getres
>> sc
>> blr
>> .cfi_endproc
>> V_FUNCTION_END(__kernel_clock_getres)
>>
>> it does not seem so for what concerns vdso64. I did run again the test both on
>> ppc and ppc64 qemu instances and the result is the same to what I reported in
>> this thread.
>>
>> Am I missing something?
>
> I was thinking about
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5c929885f1bb
> but apparently clock_getres() was left aside. Should we do something
> about it ?
>
Sure, but I would like this series to be merged first (since the topic is
different). I am happy, after that, to push a separate one on top that addresses
the problem.
Please let me know if it works for you and Michael.
> Christophe
>
>>
>>> Christophe
>>>
>>>>
>>>>> # uname -r
>>>>> 5.2.0-rc2-gcc-8.2.0
>>>>>
>>>>> # ./vdso_clock_getres
>>>>> clock_id: CLOCK_REALTIME [PASS]
>>>>> clock_id: CLOCK_BOOTTIME [PASS]
>>>>> clock_id: CLOCK_TAI [PASS]
>>>>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>>>>> clock_id: CLOCK_MONOTONIC [PASS]
>>>>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>>>>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>>>>
>>>>> cheers
>>>>>
>>>>>> Cc: Shuah Khan <shuah@kernel.org>
>>>>>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
>>>>>> ---
>>>>>>
>>>>>> Note: This patch is independent from the others in this series, hence it
>>>>>> can be merged singularly by the kselftest maintainers.
>>>>>>
>>>>>> tools/testing/selftests/vDSO/Makefile | 2 +
>>>>>> .../selftests/vDSO/vdso_clock_getres.c | 124 ++++++++++++++++++
>>>>>> 2 files changed, 126 insertions(+)
>>>>>> create mode 100644 tools/testing/selftests/vDSO/vdso_clock_getres.c
>>>>
>>
--
Regards,
Vincenzo
^ permalink raw reply
* Re: [PATCH v4 3/3] kselftest: Extend vDSO selftest to clock_getres
From: Christophe Leroy @ 2019-06-04 13:52 UTC (permalink / raw)
To: Vincenzo Frascino, Michael Ellerman, linux-arch, linuxppc-dev,
linux-s390, linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Paul Mackerras, Martin Schwidefsky,
Thomas Gleixner, Shuah Khan
In-Reply-To: <eacdc960-c344-9f9f-7f1b-ad770cb4a725@arm.com>
Le 04/06/2019 à 15:43, Vincenzo Frascino a écrit :
> On 04/06/2019 14:39, Christophe Leroy wrote:
>>
>>
>> Le 04/06/2019 à 15:32, Vincenzo Frascino a écrit :
>>> Hi Christophe,
>>>
>>> On 04/06/2019 14:16, Christophe Leroy wrote:
>>>> Hi Vincenzo
>>>>
>>>> Le 28/05/2019 à 13:57, Vincenzo Frascino a écrit :
>>>>> Hi Michael,
>>>>>
>>>>> thank you for your reply.
>>>>>
>>>>> On 28/05/2019 07:19, Michael Ellerman wrote:
>>>>>> Vincenzo Frascino <vincenzo.frascino@arm.com> writes:
>>>>>>
>>>>>>> The current version of the multiarch vDSO selftest verifies only
>>>>>>> gettimeofday.
>>>>>>>
>>>>>>> Extend the vDSO selftest to clock_getres, to verify that the
>>>>>>> syscall and the vDSO library function return the same information.
>>>>>>>
>>>>>>> The extension has been used to verify the hrtimer_resoltion fix.
>>>>>>
>>>>>> This is passing for me even without patch 1 applied, shouldn't it fail
>>>>>> without the fix? What am I missing?
>>>>>>
>>>>>
>>>>> This is correct, because during the refactoring process I missed an "n" :)
>>>>>
>>>>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_sec·!=·y.tv_sec))
>>>>>
>>>>> Should be:
>>>>>
>>>>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_nsec·!=·y.tv_nsec))
>>>>>
>>>>> My mistake, I am going to fix the test and re-post v5 of this set.
>>>>>
>>>>> Without my patch if you pass "highres=off" to the kernel (as a command line
>>>>> parameter) it leads to a broken implementation of clock_getres since the value
>>>>> of CLOCK_REALTIME_RES does not change at runtime.
>>>>>
>>>>> Expected result (with highres=off):
>>>>>
>>>>> # uname -r
>>>>> 5.2.0-rc2
>>>>> # ./vdso_clock_getres
>>>>> clock_id: CLOCK_REALTIME [FAIL]
>>>>> clock_id: CLOCK_BOOTTIME [PASS]
>>>>> clock_id: CLOCK_TAI [PASS]
>>>>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>>>>> clock_id: CLOCK_MONOTONIC [FAIL]
>>>>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>>>>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>>>>
>>>>> The reason of this behavior is that the only clocks supported by getres on
>>>>> powerpc are CLOCK_REALTIME and CLOCK_MONOTONIC, the rest on the clocks use
>>>>> always syscalls.
>>>>
>>>> vdso64 is supposed to implement CLOCK_{REALTIME/MONOTONIC}_COARSE, so I
>>>> guess it should fail for them too ?
>>>>
>>>> Or is your test done on vdso32 ?
>>>>
>>>
>>> Based on what I can see in kernel/vdso64 in 5.2-rc3:
>>>
>>> /*
>>> * Exact prototype of clock_getres()
>>> *
>>> * int __kernel_clock_getres(clockid_t clock_id, struct timespec *res);
>>> *
>>> */
>>> V_FUNCTION_BEGIN(__kernel_clock_getres)
>>> .cfi_startproc
>>> /* Check for supported clock IDs */
>>> cmpwi cr0,r3,CLOCK_REALTIME
>>> cmpwi cr1,r3,CLOCK_MONOTONIC
>>> cror cr0*4+eq,cr0*4+eq,cr1*4+eq
>>> bne cr0,99f
>>>
>>> li r3,0
>>> cmpldi cr0,r4,0
>>> crclr cr0*4+so
>>> beqlr
>>> lis r5,CLOCK_REALTIME_RES@h
>>> ori r5,r5,CLOCK_REALTIME_RES@l
>>> std r3,TSPC64_TV_SEC(r4)
>>> std r5,TSPC64_TV_NSEC(r4)
>>> blr
>>>
>>> /*
>>> * syscall fallback
>>> */
>>> 99:
>>> li r0,__NR_clock_getres
>>> sc
>>> blr
>>> .cfi_endproc
>>> V_FUNCTION_END(__kernel_clock_getres)
>>>
>>> it does not seem so for what concerns vdso64. I did run again the test both on
>>> ppc and ppc64 qemu instances and the result is the same to what I reported in
>>> this thread.
>>>
>>> Am I missing something?
>>
>> I was thinking about
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5c929885f1bb
>> but apparently clock_getres() was left aside. Should we do something
>> about it ?
>>
>
> Sure, but I would like this series to be merged first (since the topic is
> different). I am happy, after that, to push a separate one on top that addresses
> the problem.
>
> Please let me know if it works for you and Michael.
No problem for myself.
By the way, next time (or next spin ?) I recommend you to handle your
patches independently and not as a series since they are all
independant. It would have avoided confusion and the need for you to
resend all 3 patches everytime you did a change in one of them.
Christophe
>
>> Christophe
>>
>>>
>>>> Christophe
>>>>
>>>>>
>>>>>> # uname -r
>>>>>> 5.2.0-rc2-gcc-8.2.0
>>>>>>
>>>>>> # ./vdso_clock_getres
>>>>>> clock_id: CLOCK_REALTIME [PASS]
>>>>>> clock_id: CLOCK_BOOTTIME [PASS]
>>>>>> clock_id: CLOCK_TAI [PASS]
>>>>>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>>>>>> clock_id: CLOCK_MONOTONIC [PASS]
>>>>>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>>>>>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>>>>>
>>>>>> cheers
>>>>>>
>>>>>>> Cc: Shuah Khan <shuah@kernel.org>
>>>>>>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
>>>>>>> ---
>>>>>>>
>>>>>>> Note: This patch is independent from the others in this series, hence it
>>>>>>> can be merged singularly by the kselftest maintainers.
>>>>>>>
>>>>>>> tools/testing/selftests/vDSO/Makefile | 2 +
>>>>>>> .../selftests/vDSO/vdso_clock_getres.c | 124 ++++++++++++++++++
>>>>>>> 2 files changed, 126 insertions(+)
>>>>>>> create mode 100644 tools/testing/selftests/vDSO/vdso_clock_getres.c
>>>>>
>>>
>
^ permalink raw reply
* [PATCH v2 06/22] docs: mark orphan documents as such
From: Mauro Carvalho Chehab @ 2019-06-04 14:17 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Maxime Ripard, dri-devel, platform-driver-x86, Paul Mackerras,
Mauro Carvalho Chehab, linux-stm32, Alexandre Torgue,
Jonathan Corbet, David Airlie, Andrew Donnellan, linux-pm,
Maarten Lankhorst, Matan Ziv-Av, Mauro Carvalho Chehab,
Daniel Vetter, Sean Paul, linux-arm-kernel, linux-kernel,
Maxime Coquelin, Frederic Barrat, linuxppc-dev, Georgi Djakov
In-Reply-To: <cover.1559656538.git.mchehab+samsung@kernel.org>
Sphinx doesn't like orphan documents:
Documentation/accelerators/ocxl.rst: WARNING: document isn't included in any toctree
Documentation/arm/stm32/overview.rst: WARNING: document isn't included in any toctree
Documentation/arm/stm32/stm32f429-overview.rst: WARNING: document isn't included in any toctree
Documentation/arm/stm32/stm32f746-overview.rst: WARNING: document isn't included in any toctree
Documentation/arm/stm32/stm32f769-overview.rst: WARNING: document isn't included in any toctree
Documentation/arm/stm32/stm32h743-overview.rst: WARNING: document isn't included in any toctree
Documentation/arm/stm32/stm32mp157-overview.rst: WARNING: document isn't included in any toctree
Documentation/gpu/msm-crash-dump.rst: WARNING: document isn't included in any toctree
Documentation/interconnect/interconnect.rst: WARNING: document isn't included in any toctree
Documentation/laptops/lg-laptop.rst: WARNING: document isn't included in any toctree
Documentation/powerpc/isa-versions.rst: WARNING: document isn't included in any toctree
Documentation/virtual/kvm/amd-memory-encryption.rst: WARNING: document isn't included in any toctree
Documentation/virtual/kvm/vcpu-requests.rst: WARNING: document isn't included in any toctree
So, while they aren't on any toctree, add :orphan: to them, in order
to silent this warning.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/accelerators/ocxl.rst | 2 ++
Documentation/arm/stm32/overview.rst | 2 ++
Documentation/arm/stm32/stm32f429-overview.rst | 2 ++
Documentation/arm/stm32/stm32f746-overview.rst | 2 ++
Documentation/arm/stm32/stm32f769-overview.rst | 2 ++
Documentation/arm/stm32/stm32h743-overview.rst | 2 ++
Documentation/arm/stm32/stm32mp157-overview.rst | 2 ++
Documentation/gpu/msm-crash-dump.rst | 2 ++
Documentation/interconnect/interconnect.rst | 2 ++
Documentation/laptops/lg-laptop.rst | 2 ++
Documentation/powerpc/isa-versions.rst | 2 ++
11 files changed, 22 insertions(+)
diff --git a/Documentation/accelerators/ocxl.rst b/Documentation/accelerators/ocxl.rst
index 14cefc020e2d..b1cea19a90f5 100644
--- a/Documentation/accelerators/ocxl.rst
+++ b/Documentation/accelerators/ocxl.rst
@@ -1,3 +1,5 @@
+:orphan:
+
========================================================
OpenCAPI (Open Coherent Accelerator Processor Interface)
========================================================
diff --git a/Documentation/arm/stm32/overview.rst b/Documentation/arm/stm32/overview.rst
index 85cfc8410798..f7e734153860 100644
--- a/Documentation/arm/stm32/overview.rst
+++ b/Documentation/arm/stm32/overview.rst
@@ -1,3 +1,5 @@
+:orphan:
+
========================
STM32 ARM Linux Overview
========================
diff --git a/Documentation/arm/stm32/stm32f429-overview.rst b/Documentation/arm/stm32/stm32f429-overview.rst
index 18feda97f483..65bbb1c3b423 100644
--- a/Documentation/arm/stm32/stm32f429-overview.rst
+++ b/Documentation/arm/stm32/stm32f429-overview.rst
@@ -1,3 +1,5 @@
+:orphan:
+
STM32F429 Overview
==================
diff --git a/Documentation/arm/stm32/stm32f746-overview.rst b/Documentation/arm/stm32/stm32f746-overview.rst
index b5f4b6ce7656..42d593085015 100644
--- a/Documentation/arm/stm32/stm32f746-overview.rst
+++ b/Documentation/arm/stm32/stm32f746-overview.rst
@@ -1,3 +1,5 @@
+:orphan:
+
STM32F746 Overview
==================
diff --git a/Documentation/arm/stm32/stm32f769-overview.rst b/Documentation/arm/stm32/stm32f769-overview.rst
index 228656ced2fe..f6adac862b17 100644
--- a/Documentation/arm/stm32/stm32f769-overview.rst
+++ b/Documentation/arm/stm32/stm32f769-overview.rst
@@ -1,3 +1,5 @@
+:orphan:
+
STM32F769 Overview
==================
diff --git a/Documentation/arm/stm32/stm32h743-overview.rst b/Documentation/arm/stm32/stm32h743-overview.rst
index 3458dc00095d..c525835e7473 100644
--- a/Documentation/arm/stm32/stm32h743-overview.rst
+++ b/Documentation/arm/stm32/stm32h743-overview.rst
@@ -1,3 +1,5 @@
+:orphan:
+
STM32H743 Overview
==================
diff --git a/Documentation/arm/stm32/stm32mp157-overview.rst b/Documentation/arm/stm32/stm32mp157-overview.rst
index 62e176d47ca7..2c52cd020601 100644
--- a/Documentation/arm/stm32/stm32mp157-overview.rst
+++ b/Documentation/arm/stm32/stm32mp157-overview.rst
@@ -1,3 +1,5 @@
+:orphan:
+
STM32MP157 Overview
===================
diff --git a/Documentation/gpu/msm-crash-dump.rst b/Documentation/gpu/msm-crash-dump.rst
index 757cd257e0d8..240ef200f76c 100644
--- a/Documentation/gpu/msm-crash-dump.rst
+++ b/Documentation/gpu/msm-crash-dump.rst
@@ -1,3 +1,5 @@
+:orphan:
+
=====================
MSM Crash Dump Format
=====================
diff --git a/Documentation/interconnect/interconnect.rst b/Documentation/interconnect/interconnect.rst
index c3e004893796..56e331dab70e 100644
--- a/Documentation/interconnect/interconnect.rst
+++ b/Documentation/interconnect/interconnect.rst
@@ -1,5 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
+:orphan:
+
=====================================
GENERIC SYSTEM INTERCONNECT SUBSYSTEM
=====================================
diff --git a/Documentation/laptops/lg-laptop.rst b/Documentation/laptops/lg-laptop.rst
index aa503ee9b3bc..f2c2ffe31101 100644
--- a/Documentation/laptops/lg-laptop.rst
+++ b/Documentation/laptops/lg-laptop.rst
@@ -1,5 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0+
+:orphan:
+
LG Gram laptop extra features
=============================
diff --git a/Documentation/powerpc/isa-versions.rst b/Documentation/powerpc/isa-versions.rst
index 812e20cc898c..66c24140ebf1 100644
--- a/Documentation/powerpc/isa-versions.rst
+++ b/Documentation/powerpc/isa-versions.rst
@@ -1,3 +1,5 @@
+:orphan:
+
CPU to ISA Version Mapping
==========================
--
2.21.0
^ permalink raw reply related
* [PATCH v2 18/22] docs: move protection-keys.rst to the core-api book
From: Mauro Carvalho Chehab @ 2019-06-04 14:17 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Michal Hocko, Dave Hansen, Paul Mackerras, linux-kselftest,
H. Peter Anvin, Mauro Carvalho Chehab, Shuah Khan,
Jonathan Corbet, x86, Matthew Wilcox, Ingo Molnar,
Kent Overstreet, Arnd Bergmann, Jonathan Neuschäfer,
Mauro Carvalho Chehab, Mike Rapoport, Borislav Petkov,
Thomas Gleixner, Randy Dunlap, linux-kernel, Changbin Du,
Andrew Morton, linuxppc-dev
In-Reply-To: <cover.1559656538.git.mchehab+samsung@kernel.org>
This document is used by multiple architectures:
$ echo $(git grep -l pkey_mprotect arch|cut -d'/' -f 2|sort|uniq)
alpha arm arm64 ia64 m68k microblaze mips parisc powerpc s390 sh sparc x86 xtensa
So, let's move it to the core book and adjust the links to it
accordingly.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/core-api/index.rst | 1 +
Documentation/{x86 => core-api}/protection-keys.rst | 0
Documentation/x86/index.rst | 1 -
arch/powerpc/Kconfig | 2 +-
arch/x86/Kconfig | 2 +-
tools/testing/selftests/x86/protection_keys.c | 2 +-
6 files changed, 4 insertions(+), 4 deletions(-)
rename Documentation/{x86 => core-api}/protection-keys.rst (100%)
diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
index ee1bb8983a88..2466a4c51031 100644
--- a/Documentation/core-api/index.rst
+++ b/Documentation/core-api/index.rst
@@ -34,6 +34,7 @@ Core utilities
timekeeping
boot-time-mm
memory-hotplug
+ protection-keys
Interfaces for kernel debugging
diff --git a/Documentation/x86/protection-keys.rst b/Documentation/core-api/protection-keys.rst
similarity index 100%
rename from Documentation/x86/protection-keys.rst
rename to Documentation/core-api/protection-keys.rst
diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst
index ae36fc5fc649..f2de1b2d3ac7 100644
--- a/Documentation/x86/index.rst
+++ b/Documentation/x86/index.rst
@@ -19,7 +19,6 @@ x86-specific Documentation
tlb
mtrr
pat
- protection-keys
intel_mpx
amd-memory-encryption
pti
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 1120ff8ac715..e437aa3e78b4 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -898,7 +898,7 @@ config PPC_MEM_KEYS
page-based protections, but without requiring modification of the
page tables when an application changes protection domains.
- For details, see Documentation/vm/protection-keys.rst
+ For details, see Documentation/core-api/protection-keys.rst
If unsure, say y.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 23de3b9da480..61244bdb886f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1911,7 +1911,7 @@ config X86_INTEL_MEMORY_PROTECTION_KEYS
page-based protections, but without requiring modification of the
page tables when an application changes protection domains.
- For details, see Documentation/x86/protection-keys.txt
+ For details, see Documentation/core-api/protection-keys.rst
If unsure, say y.
diff --git a/tools/testing/selftests/x86/protection_keys.c b/tools/testing/selftests/x86/protection_keys.c
index 5d546dcdbc80..480995bceefa 100644
--- a/tools/testing/selftests/x86/protection_keys.c
+++ b/tools/testing/selftests/x86/protection_keys.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Tests x86 Memory Protection Keys (see Documentation/x86/protection-keys.txt)
+ * Tests x86 Memory Protection Keys (see Documentation/core-api/protection-keys.rst)
*
* There are examples in here of:
* * how to set protection keys on memory
--
2.21.0
^ permalink raw reply related
* Re: [POWERPC][next-20190603] Boot failure : Kernel BUG at mm/vmalloc.c:470
From: Stephen Rothwell @ 2019-06-04 14:20 UTC (permalink / raw)
To: Sachin Sant
Cc: linux-mm, linux-next, linuxppc-dev, linux-kernel,
Uladzislau Rezki (Sony)
In-Reply-To: <88ADCAAE-4F1A-49FE-A454-BBAB12A88C70@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 232 bytes --]
Hi Sachin,
On Tue, 4 Jun 2019 19:09:26 +0530 Sachin Sant <sachinp@linux.vnet.ibm.com> wrote:
>
> With today’s next (20190604) I no longer see this issue.
Excellent, thanks for verifying.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 3/3] kselftest: Extend vDSO selftest to clock_getres
From: Vincenzo Frascino @ 2019-06-04 14:21 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman, linux-arch, linuxppc-dev,
linux-s390, linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Paul Mackerras, Martin Schwidefsky,
Thomas Gleixner, Shuah Khan
In-Reply-To: <2389b7f2-288b-215e-994a-3b24be08e125@c-s.fr>
On 04/06/2019 14:52, Christophe Leroy wrote:
>
>
> Le 04/06/2019 à 15:43, Vincenzo Frascino a écrit :
>> On 04/06/2019 14:39, Christophe Leroy wrote:
>>>
>>>
>>> Le 04/06/2019 à 15:32, Vincenzo Frascino a écrit :
>>>> Hi Christophe,
>>>>
>>>> On 04/06/2019 14:16, Christophe Leroy wrote:
>>>>> Hi Vincenzo
>>>>>
>>>>> Le 28/05/2019 à 13:57, Vincenzo Frascino a écrit :
>>>>>> Hi Michael,
>>>>>>
>>>>>> thank you for your reply.
>>>>>>
>>>>>> On 28/05/2019 07:19, Michael Ellerman wrote:
>>>>>>> Vincenzo Frascino <vincenzo.frascino@arm.com> writes:
>>>>>>>
>>>>>>>> The current version of the multiarch vDSO selftest verifies only
>>>>>>>> gettimeofday.
>>>>>>>>
>>>>>>>> Extend the vDSO selftest to clock_getres, to verify that the
>>>>>>>> syscall and the vDSO library function return the same information.
>>>>>>>>
>>>>>>>> The extension has been used to verify the hrtimer_resoltion fix.
>>>>>>>
>>>>>>> This is passing for me even without patch 1 applied, shouldn't it fail
>>>>>>> without the fix? What am I missing?
>>>>>>>
>>>>>>
>>>>>> This is correct, because during the refactoring process I missed an "n" :)
>>>>>>
>>>>>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_sec·!=·y.tv_sec))
>>>>>>
>>>>>> Should be:
>>>>>>
>>>>>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_nsec·!=·y.tv_nsec))
>>>>>>
>>>>>> My mistake, I am going to fix the test and re-post v5 of this set.
>>>>>>
>>>>>> Without my patch if you pass "highres=off" to the kernel (as a command line
>>>>>> parameter) it leads to a broken implementation of clock_getres since the value
>>>>>> of CLOCK_REALTIME_RES does not change at runtime.
>>>>>>
>>>>>> Expected result (with highres=off):
>>>>>>
>>>>>> # uname -r
>>>>>> 5.2.0-rc2
>>>>>> # ./vdso_clock_getres
>>>>>> clock_id: CLOCK_REALTIME [FAIL]
>>>>>> clock_id: CLOCK_BOOTTIME [PASS]
>>>>>> clock_id: CLOCK_TAI [PASS]
>>>>>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>>>>>> clock_id: CLOCK_MONOTONIC [FAIL]
>>>>>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>>>>>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>>>>>
>>>>>> The reason of this behavior is that the only clocks supported by getres on
>>>>>> powerpc are CLOCK_REALTIME and CLOCK_MONOTONIC, the rest on the clocks use
>>>>>> always syscalls.
>>>>>
>>>>> vdso64 is supposed to implement CLOCK_{REALTIME/MONOTONIC}_COARSE, so I
>>>>> guess it should fail for them too ?
>>>>>
>>>>> Or is your test done on vdso32 ?
>>>>>
>>>>
>>>> Based on what I can see in kernel/vdso64 in 5.2-rc3:
>>>>
>>>> /*
>>>> * Exact prototype of clock_getres()
>>>> *
>>>> * int __kernel_clock_getres(clockid_t clock_id, struct timespec *res);
>>>> *
>>>> */
>>>> V_FUNCTION_BEGIN(__kernel_clock_getres)
>>>> .cfi_startproc
>>>> /* Check for supported clock IDs */
>>>> cmpwi cr0,r3,CLOCK_REALTIME
>>>> cmpwi cr1,r3,CLOCK_MONOTONIC
>>>> cror cr0*4+eq,cr0*4+eq,cr1*4+eq
>>>> bne cr0,99f
>>>>
>>>> li r3,0
>>>> cmpldi cr0,r4,0
>>>> crclr cr0*4+so
>>>> beqlr
>>>> lis r5,CLOCK_REALTIME_RES@h
>>>> ori r5,r5,CLOCK_REALTIME_RES@l
>>>> std r3,TSPC64_TV_SEC(r4)
>>>> std r5,TSPC64_TV_NSEC(r4)
>>>> blr
>>>>
>>>> /*
>>>> * syscall fallback
>>>> */
>>>> 99:
>>>> li r0,__NR_clock_getres
>>>> sc
>>>> blr
>>>> .cfi_endproc
>>>> V_FUNCTION_END(__kernel_clock_getres)
>>>>
>>>> it does not seem so for what concerns vdso64. I did run again the test both on
>>>> ppc and ppc64 qemu instances and the result is the same to what I reported in
>>>> this thread.
>>>>
>>>> Am I missing something?
>>>
>>> I was thinking about
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5c929885f1bb
>>> but apparently clock_getres() was left aside. Should we do something
>>> about it ?
>>>
>>
>> Sure, but I would like this series to be merged first (since the topic is
>> different). I am happy, after that, to push a separate one on top that addresses
>> the problem.
>>
>> Please let me know if it works for you and Michael.
>
> No problem for myself.
>
> By the way, next time (or next spin ?) I recommend you to handle your
> patches independently and not as a series since they are all
> independant. It would have avoided confusion and the need for you to
> resend all 3 patches everytime you did a change in one of them.
>
Thanks for the advise, I will do next time.
> Christophe
>
>>
>>> Christophe
>>>
>>>>
>>>>> Christophe
>>>>>
>>>>>>
>>>>>>> # uname -r
>>>>>>> 5.2.0-rc2-gcc-8.2.0
>>>>>>>
>>>>>>> # ./vdso_clock_getres
>>>>>>> clock_id: CLOCK_REALTIME [PASS]
>>>>>>> clock_id: CLOCK_BOOTTIME [PASS]
>>>>>>> clock_id: CLOCK_TAI [PASS]
>>>>>>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>>>>>>> clock_id: CLOCK_MONOTONIC [PASS]
>>>>>>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>>>>>>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>>>>>>
>>>>>>> cheers
>>>>>>>
>>>>>>>> Cc: Shuah Khan <shuah@kernel.org>
>>>>>>>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> Note: This patch is independent from the others in this series, hence it
>>>>>>>> can be merged singularly by the kselftest maintainers.
>>>>>>>>
>>>>>>>> tools/testing/selftests/vDSO/Makefile | 2 +
>>>>>>>> .../selftests/vDSO/vdso_clock_getres.c | 124 ++++++++++++++++++
>>>>>>>> 2 files changed, 126 insertions(+)
>>>>>>>> create mode 100644 tools/testing/selftests/vDSO/vdso_clock_getres.c
>>>>>>
>>>>
>>
--
Regards,
Vincenzo
^ permalink raw reply
* Re: [PATCH v3 14/16] powerpc/32: implement fast entry for syscalls on BOOKE
From: Christophe Leroy @ 2019-06-04 16:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel, Nicholas Piggin
In-Reply-To: <20190523061427.GA19655@blackberry>
Paul,
Le 23/05/2019 à 08:14, Paul Mackerras a écrit :
> On Tue, Apr 30, 2019 at 12:39:03PM +0000, Christophe Leroy wrote:
>> This patch implements a fast entry for syscalls.
>>
>> Syscalls don't have to preserve non volatile registers except LR.
>>
>> This patch then implement a fast entry for syscalls, where
>> volatile registers get clobbered.
>>
>> As this entry is dedicated to syscall it always sets MSR_EE
>> and warns in case MSR_EE was previously off
>>
>> It also assumes that the call is always from user, system calls are
>> unexpected from kernel.
>
> This is now upstream as commit 1a4b739bbb4f. On the e500mc test
> config that I use, I'm getting this build failure:
>
> arch/powerpc/kernel/head_fsl_booke.o: In function `SystemCall':
> arch/powerpc/kernel/head_fsl_booke.S:416: undefined reference to `kvmppc_handler_BOOKE_INTERRUPT_SYSCALL_SPRN_SRR1'
> Makefile:1052: recipe for target 'vmlinux' failed
Does my patch (https://patchwork.ozlabs.org/patch/1103909/) fixes the
issue for you ?
Thanks
Christophe
>
>> +.macro SYSCALL_ENTRY trapno intno
>> + mfspr r10, SPRN_SPRG_THREAD
>> +#ifdef CONFIG_KVM_BOOKE_HV
>> +BEGIN_FTR_SECTION
>> + mtspr SPRN_SPRG_WSCRATCH0, r10
>> + stw r11, THREAD_NORMSAVE(0)(r10)
>> + stw r13, THREAD_NORMSAVE(2)(r10)
>> + mfcr r13 /* save CR in r13 for now */
>> + mfspr r11, SPRN_SRR1
>> + mtocrf 0x80, r11 /* check MSR[GS] without clobbering reg */
>> + bf 3, 1975f
>> + b kvmppc_handler_BOOKE_INTERRUPT_\intno\()_SPRN_SRR1
>
> It seems to me that the "_SPRN_SRR1" on the end of this line
> isn't meant to be there... However, it still fails to link with that
> removed.
>
> Paul.
>
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/pseries: Simplify cpu readd to use drc_index
From: Nathan Lynch @ 2019-06-04 17:21 UTC (permalink / raw)
To: Tyrel Datwyler; +Cc: mingming.cao, linuxppc-dev
In-Reply-To: <69336ea3-7937-17cc-8082-d4ad782d7e8c@linux.vnet.ibm.com>
Tyrel Datwyler <tyreld@linux.vnet.ibm.com> writes:
> On 05/20/2019 08:01 AM, Nathan Lynch wrote:
>> Kernel implementation details aside, how do you change the cpu-node
>> relationship at runtime without breaking NUMA-aware applications? Is
>> this not a fundamental issue to address before adding code like this?
>>
>
> If that is the concern then hotplug in general already breaks
> them. Take for example the removal of a faulty processor and then
> adding a new processor back. It is quite possible that the new
> processor is in a different NUMA node. Keep in mind that in this
> scenario the new processor and threads gets the same logical cpu ids
> as the faulty processor we just removed.
Yes, the problem is re-use of a logical CPU id with a node id that
differs from the one it was initially assigned, and there are several
ways to get into that situation on this platform. We probably need to be
more careful in how we allocate a spot in the CPU maps for a newly-added
processor. I believe the algorithm is simple first-fit right now, and it
doesn't take into account prior NUMA relationships.
> Now we have to ask the question who is right and who is wrong. In this
> case the kernel data structures reflect the correct NUMA
> topology. However, did the NUMA aware application or libnuma make an
> assumption that specific sets of logical cpu ids are always in the
> same NUMA node?
Yes, and that assumption is widespread because people tend to develop on
an architecture where this kind of stuff doesn't happen (at least not
yet).
And I don't really agree that the current behavior reflects what is
actually going on. When Linux running in a PowerVM LPAR receives a
notification to change the NUMA properties of a processor at runtime,
it's because the platform has changed the physical characteristics of
the partition. I.e. you're now using a different physical processor,
with different relationships to the other resources in the system. Even
if it didn't destabilize the kernel (by changing the result of
cpu_to_node() when various subsystems assume it will be static),
continuing to use the logical CPU ids on the new processor obscures what
has actually happened. And we have developers that have told us that
this behavior - changing the logical cpu<->node relationship at runtime
- is something their existing NUMA-aware applications cannot handle.
^ permalink raw reply
* Re: [PATCH v3 04/11] arm64/mm: Add temporary arch_remove_memory() implementation
From: Robin Murphy @ 2019-06-04 17:36 UTC (permalink / raw)
To: David Hildenbrand, 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
In-Reply-To: <5059f68d-45d2-784e-0770-ee67060773c7@redhat.com>
On 04/06/2019 07:56, David Hildenbrand wrote:
> 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).
FWIW the other pieces of ZONE_DEVICE are now due to land in parallel,
but as long as we don't throw the ARCH_ENABLE_MEMORY_HOTREMOVE switch
then there should still be no issue. Besides, given that we should
consistently ignore the altmap everywhere at the moment, it may even
work out regardless.
One thing stands out about the failure path thing, though - if
__add_pages() did fail, can it still be guaranteed to have initialised
the memmap such that page_zone() won't return nonsense? Last time I
looked that was still a problem when removing memory which had been
successfully added, but never onlined (although I do know that
particular case was already being discussed at the time, and I've not
been paying the greatest attention since).
Robin.
^ permalink raw reply
* Re: [PATCH v3 04/11] arm64/mm: Add temporary arch_remove_memory() implementation
From: David Hildenbrand @ 2019-06-04 17:51 UTC (permalink / raw)
To: Robin Murphy, 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
In-Reply-To: <7a5b8c8d-f1bb-9c7e-9809-405af374fecd@arm.com>
On 04.06.19 19:36, Robin Murphy wrote:
> On 04/06/2019 07:56, David Hildenbrand wrote:
>> 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).
>
> FWIW the other pieces of ZONE_DEVICE are now due to land in parallel,
> but as long as we don't throw the ARCH_ENABLE_MEMORY_HOTREMOVE switch
> then there should still be no issue. Besides, given that we should
> consistently ignore the altmap everywhere at the moment, it may even
> work out regardless.
Thanks for the info.
>
> One thing stands out about the failure path thing, though - if
> __add_pages() did fail, can it still be guaranteed to have initialised
> the memmap such that page_zone() won't return nonsense? Last time I
if __add_pages() fails, then arch_add_memory() fails and
arch_remove_memory() will not be called in the context of this series.
Only if it succeeded.
> looked that was still a problem when removing memory which had been
> successfully added, but never onlined (although I do know that
> particular case was already being discussed at the time, and I've not
> been paying the greatest attention since).
Yes, that part is next on my list. It works but is ugly. The memory
removal process should not care about zones at all.
Slowly moving into the right direction :)
>
> Robin.
>
--
Thanks,
David / dhildenb
^ 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