Re: [PATCH 2/2] x86, powerpc: remove -funit-at-a-time compiler option entirely
x86 maintainers, Ping. On Mon, Nov 12, 2018 at 8:23 PM Michael Ellerman wrote: > > Masahiro Yamada writes: > > > GCC 4.6 manual says: > > > > -funit-at-a-time > > This option is left for compatibility reasons. -funit-at-a-time has > > no effect, while -fno-unit-at-a-time implies -fno-toplevel-reorder > > and -fno-section-anchors. > > Enabled by default. > > > > Signed-off-by: Masahiro Yamada > > --- > > > > arch/powerpc/Makefile | 4 > > arch/x86/Makefile | 4 > > arch/x86/Makefile.um | 5 - > > 3 files changed, 13 deletions(-) > > > > diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile > > index 8a2ce14..854199c 100644 > > --- a/arch/powerpc/Makefile > > +++ b/arch/powerpc/Makefile > > @@ -228,10 +228,6 @@ KBUILD_CFLAGS += $(call cc-option,-mno-vsx) > > KBUILD_CFLAGS += $(call cc-option,-mno-spe) > > KBUILD_CFLAGS += $(call cc-option,-mspe=no) > > > > -# Enable unit-at-a-time mode when possible. It shrinks the > > -# kernel considerably. > > -KBUILD_CFLAGS += $(call cc-option,-funit-at-a-time) > > - > > Thanks for cleaning it up. > > Acked-by: Michael Ellerman > > cheers -- Best Regards Masahiro Yamada
Re: [PATCH 1/2] um: remove -fno-unit-at-a-time workaround for pre-4.0 GCC
x86 maintainers,
Ping.
On Tue, Nov 13, 2018 at 6:48 PM Richard Weinberger wrote:
>
> Am Montag, 12. November 2018, 03:35:19 CET schrieb Masahiro Yamada:
> > Commit cafa0010cd51 ("Raise the minimum required gcc version to 4.6")
> > bumped the minimum GCC version to 4.6 for all architectures.
> >
> > '$(call cc-option,-fno-unit-at-a-time)' is now dead code since
> > '$(cc-version) -lt 0400' is always false.
> >
> > Signed-off-by: Masahiro Yamada
> > ---
> >
> > arch/x86/Makefile.um | 8 ++--
> > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/x86/Makefile.um b/arch/x86/Makefile.um
> > index 91085a0..577976b 100644
> > --- a/arch/x86/Makefile.um
> > +++ b/arch/x86/Makefile.um
> > @@ -26,12 +26,8 @@ cflags-y += $(call
> > cc-option,-mpreferred-stack-boundary=2)
> > # an unresolved reference.
> > cflags-y += -ffreestanding
> >
> > -# Disable unit-at-a-time mode on pre-gcc-4.0 compilers, it makes gcc use
> > -# a lot more stack due to the lack of sharing of stacklots. Also, gcc
> > -# 4.3.0 needs -funit-at-a-time for extern inline functions.
> > -KBUILD_CFLAGS += $(shell if [ $(cc-version) -lt 0400 ] ; then \
> > - echo $(call cc-option,-fno-unit-at-a-time); \
> > - else echo $(call cc-option,-funit-at-a-time); fi ;)
> > +# gcc 4.3.0 needs -funit-at-a-time for extern inline functions.
> > +KBUILD_CFLAGS += $(call cc-option,-funit-at-a-time)
>
> Acked-by: Richard Weinberger
>
> Thanks,
> //richard
>
>
>
--
Best Regards
Masahiro Yamada
Re: [PATCH v2 01/34] kbuild: Add support for DT binding schema checks
Hi Rob, On Tue, Dec 4, 2018 at 6:32 AM Rob Herring wrote: > > This adds the build infrastructure for checking DT binding schema > documents and validating dts files using the binding schema. > > Check DT binding schema documents: > make dt_binding_check > > Build dts files and check using DT binding schema: > make dtbs_check > > Optionally, DT_SCHEMA_FILES can passed in with a schema file(s) to use > for validation. This makes it easier to find and fix errors generated by > a specific schema. > > Currently, the validation targets are separate from a normal build to > avoid a hard dependency on the external DT schema project and because > there are lots of warnings generated. > > Cc: Jonathan Corbet > Cc: Mark Rutland > Cc: Masahiro Yamada > Cc: Michal Marek > Cc: linux-...@vger.kernel.org > Cc: devicet...@vger.kernel.org > Cc: linux-kbu...@vger.kernel.org > Signed-off-by: Rob Herring > --- > .gitignore | 1 + > Documentation/Makefile | 2 +- > Documentation/devicetree/bindings/.gitignore | 1 + > Documentation/devicetree/bindings/Makefile | 33 > Makefile | 11 +-- > scripts/Makefile.lib | 24 -- > 6 files changed, 67 insertions(+), 5 deletions(-) > create mode 100644 Documentation/devicetree/bindings/.gitignore > create mode 100644 Documentation/devicetree/bindings/Makefile > > diff --git a/.gitignore b/.gitignore > index 97ba6b79834c..a20ac26aa2f5 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -15,6 +15,7 @@ > *.bin > *.bz2 > *.c.[012]*.* > +*.dt.yaml > *.dtb > *.dtb.S > *.dwo > diff --git a/Documentation/Makefile b/Documentation/Makefile > index 2ca77ad0f238..9786957c6a35 100644 > --- a/Documentation/Makefile > +++ b/Documentation/Makefile > @@ -2,7 +2,7 @@ > # Makefile for Sphinx documentation > # > > -subdir-y := > +subdir-y := devicetree/bindings/ > > # You can set these variables from the command line. > SPHINXBUILD = sphinx-build > diff --git a/Documentation/devicetree/bindings/.gitignore > b/Documentation/devicetree/bindings/.gitignore > new file mode 100644 > index ..d9194c02dd08 > --- /dev/null > +++ b/Documentation/devicetree/bindings/.gitignore > @@ -0,0 +1 @@ > +*.example.dts > diff --git a/Documentation/devicetree/bindings/Makefile > b/Documentation/devicetree/bindings/Makefile > new file mode 100644 > index ..ee0110dd8131 > --- /dev/null > +++ b/Documentation/devicetree/bindings/Makefile > @@ -0,0 +1,33 @@ > +# SPDX-License-Identifier: GPL-2.0 > +DT_DOC_CHECKER ?= dt-doc-validate > +DT_EXTRACT_EX ?= dt-extract-example > +DT_MK_SCHEMA ?= dt-mk-schema > +DT_MK_SCHEMA_FLAGS := $(if $(DT_SCHEMA_FILES), -u) > + > +quiet_cmd_chk_binding = CHKDT $< > + cmd_chk_binding = (set -e; \ > + $(DT_DOC_CHECKER) $< ; \ > + mkdir -p $(dir $@) ; \ > + $(DT_EXTRACT_EX) $< > $@ ) > + > +$(obj)/%.example.dts: $(src)/%.yaml FORCE > + $(call if_changed,chk_binding) > + > +DT_TMP_SCHEMA := .schema.yaml.tmp > +extra-y += $(DT_TMP_SCHEMA) > + > +quiet_cmd_mk_schema = SCHEMA $@ > + cmd_mk_schema = mkdir -p $(obj); \ > + rm -f $@; \ > + $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@ $< I think '$<' is wrong. '$<' is replaced with the first prerequisite. You can easily check what is happening here. $ cat Documentation/devicetree/bindings/..schema.yaml.tmp.cmd cmd_Documentation/devicetree/bindings/.schema.yaml.tmp := mkdir -p Documentation/devicetree/bindings; rm -f Documentation/devicetree/bindings/.schema.yaml.tmp; dt-mk-schema -o Documentation/devicetree/bindings/.schema.yaml.tmp Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml So, the dt-validater will check only binding from ti,davinci.yaml, which is almost useless. If I understand it correctly, .schema.yaml.tmp should contain all binding yaml. I fixed it up like follows: diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile index ee0110d..267458f 100644 --- a/Documentation/devicetree/bindings/Makefile +++ b/Documentation/devicetree/bindings/Makefile @@ -19,7 +19,7 @@ extra-y += $(DT_TMP_SCHEMA) quiet_cmd_mk_schema = SCHEMA $@ cmd_mk_schema = mkdir -p $(obj); \ rm -f $@; \ - $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@ $< + $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@ $(filter-out FORCE, $^) DT_DOCS = $(shell cd $(srctree)/$(src) && find * -name '*.yaml') DT_SCHEMA_FILES ?= $(addprefix $(src)/,$(DT_DOCS)) Then, I see another error. SCHEMA Documentation/devicetree/bindings/.schema.yaml.tmp Traceback (most recent call last): File "/home/masahiro/ref/yaml-bindings/tools/dt-mk-schema", line 32, in schemas = dtschema.process_schemas(args.schemas, core_schema=(not args.useronly))
Re: [PATCH] pseries/hotplug: Add more delay in pseries_cpu_die while waiting for rtas-stop
Gautham R Shenoy writes: > On Fri, Dec 07, 2018 at 04:13:11PM +0530, Gautham R Shenoy wrote: >> Sure. I will test the patch and report back. > > I added the following debug patch on top of your patch, and after an > hour's run, the system crashed. Appending the log at the end. Thank you very much for testing! Your debug patch was very helpful as well. > I suppose we still need to increase the number of tries since we wait > only for 2.5ms looping before giving up. Do you think it would have helped? In the debug output you posted I would have expected the following message to show up if the loop finished too early, and it didn't: "Querying DEAD? cpu %i (%i) shows %i\n" So I don't think increasing the loop length would have made a difference. In fact, the call to smp_query_cpu_stopped() always succeeded on the first iteration. I think there is something else going on which we don't fully understand yet. From your other email: > I agree that the Kernel has to respect RTAS's restriction. The PAPR > v2.8.1, Requirement R1-7.2.3-8 under section 7.2.3 says the following: > > "The stop-self service needs to be serialized with calls to the > stop-self, start-cpu, and set-power-level services. The OS must > be able to call RTAS services on other processors while the > processor is stopped or being stopped" > > Thus the onus is on the OS to ensure that there are no concurrent rtas > calls with "stop-self" token. As you say perhaps there's another call to stop-self, start-cpu or set-power-level being made concurrently. I don't currently see how more than one stop-self or start-cpu call could be in flight at the same time given that there are a number of locks being grabbed during CPU hotplug and unplug. OTOH the CPU that actually calls stop-self doesn't seem to grab any locks itself so it's a possibility. As for set-power-level, it's only used in the case of PCI hotplug from what I can see, and that isn't part of the picture in this case, right? We could address this problem directly by adding another lock separate from rtas.lock to serialize just these calls. The challenge is with stop-self, because the CPU calling it will never return to release the lock. Is it possible to grab a lock (or down a semaphore) in the CPU calling stop-self and then release the lock (or up the semaphore) in the CPU running pseries_cpu_die()? > > There's also a race between the CPU driving the unplug and the CPU > > being unplugged which I think is not easy for the CPU being > > unplugged to win, which makes the busy loop in pseries_cpu_die() a > > bit fragile. I describe the race in the patch description. > > > > My solution to make the race less tight is to make the CPU driving > > the unplug to only start the busy loop only after the CPU being > > unplugged is in the CPU_STATE_OFFLINE state. At that point, we know > > that it either is about to call RTAS or it already has. > > Ah, yes this is good optimization. Though, I think we ought to > unconditionally wait until the target CPU has woken up from CEDE and > changed its state to CPU_STATE_OFFLINE. After if PROD failed, then we > would have caught it in dlpar_offline_cpu() itself. I recently saw a QEMU-implemented hcall (H_LOGICAL_CI_LOAD) return success when it had been given an invalid memory address to load from, so my confidence in the error reporting of hcalls is a bit shaken. :-) In that case the CPU would wait forever for the CPU state to change. If you believe 100 ms is too short a timeout, we could make it 500 ms or even 1s. What do you think? > cpu 112 (hwid 112) Ready to die... > [DEBUG] Waited for CPU 112 to enter rtas: tries=0, time=65 > cpu 113 (hwid 113) Ready to die... > [DEBUG] Waited for CPU 113 to enter rtas: tries=0, time=1139 > cpu 114 (hwid 114) Ready to die... > [DEBUG] Waited for CPU 114 to enter rtas: tries=0, time=1036 > cpu 115 (hwid 115) Ready to die... > [DEBUG] Waited for CPU 115 to enter rtas: tries=0, time=133 > cpu 116 (hwid 116) Ready to die... > [DEBUG] Waited for CPU 116 to enter rtas: tries=0, time=1231 > cpu 117 (hwid 117) Ready to die... > [DEBUG] Waited for CPU 117 to enter rtas: tries=0, time=1231 > cpu 118 (hwid 118) Ready to die... > [DEBUG] Waited for CPU 118 to enter rtas: tries=0, time=1231 > cpu 119 (hwid 119) Ready to die... > [DEBUG] Waited for CPU 119 to enter rtas: tries=0, time=1131 > cpu 104 (hwid 104) Ready to die... > [DEBUG] Waited for CPU 104 to enter rtas: tries=0, time=40 Interesting, so 1.2 ms can pass before the dying CPU actually gets close to making the stop-self call. And even in those cases the retry loop is succeeding on the first try! So this shows that changing the code to wait for the CPU_STATE_OFFLINE state is worth it. > *** RTAS CALL BUFFER CORRUPTION *** > 393: rtas32_call_buff_ptr= > 0060 0060 0060 0060 [...`...`...`...`] > 0060 0060 0060 0060 [...`...`...`...`] > 0060 0060 0060 0060 [...`...`...`
Re: [PATCH v2 18/34] dt-bindings: arm: Convert FSL board/soc bindings to json-schema
On Thu, Dec 06, 2018 at 05:33:13PM -0600, Rob Herring wrote: > On Wed, Dec 5, 2018 at 8:32 PM Shawn Guo wrote: > > > > On Mon, Dec 03, 2018 at 03:32:07PM -0600, Rob Herring wrote: > > > Convert Freescale SoC bindings to DT schema format using json-schema. > > > > > > Cc: Shawn Guo > > > Cc: Mark Rutland > > > Cc: devicet...@vger.kernel.org > > > Signed-off-by: Rob Herring > > > --- > > > .../devicetree/bindings/arm/armadeus.txt | 6 - > > > Documentation/devicetree/bindings/arm/bhf.txt | 6 - > > > .../bindings/arm/compulab-boards.txt | 25 -- > > > Documentation/devicetree/bindings/arm/fsl.txt | 229 -- > > > .../devicetree/bindings/arm/fsl.yaml | 214 > > > > Rob, > > > > I do have any changes on bindings/arm/fsl.txt queued for 4.21 on my > > tree, so please send it via your tree. > > What about: > > c386f362957b dt-bindings: Add compatible string for LS1028A-QDS > 3671cd57de06 dt-bindings: ls1012a: Add FRWY-LS1012A device tree binding Ah, sorry, I only checked on imx/dt branch and forgot imx/dt64. I will drop the changes on fsl.txt and update fsl.yaml after it hits mainline. Shawn
Re: [PATCH V3 updated] arch/powerpc/mm/hugetlb: NestMMU workaround for hugetlb mprotect RW upgrade
Hi Aneesh,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.20-rc5 next-20181207]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Aneesh-Kumar-K-V/arch-powerpc-mm-hugetlb-NestMMU-workaround-for-hugetlb-mprotect-RW-upgrade/20181207-025514
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
arch/powerpc/mm/hugetlbpage-radix.c: In function
'radix__huge_ptep_modify_prot_commit':
>> arch/powerpc/mm/hugetlbpage-radix.c:104:6: error: implicit declaration of
>> function 'is_pte_rw_upgrade' [-Werror=implicit-function-declaration]
if (is_pte_rw_upgrade(pte_val(old_pte), pte_val(pte)) &&
^
cc1: some warnings being treated as errors
vim +/is_pte_rw_upgrade +104 arch/powerpc/mm/hugetlbpage-radix.c
93
94 void radix__huge_ptep_modify_prot_commit(struct vm_area_struct *vma,
95 unsigned long addr, pte_t
*ptep,
96 pte_t old_pte, pte_t pte)
97 {
98 struct mm_struct *mm = vma->vm_mm;
99
100 /*
101 * To avoid NMMU hang while relaxing access we need to flush
the tlb before
102 * we set the new value.
103 */
> 104 if (is_pte_rw_upgrade(pte_val(old_pte), pte_val(pte)) &&
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH V4 0/3] * mm/kvm/vfio/ppc64: Migrate compound pages out of CMA region
On Wed, 21 Nov 2018 14:52:56 +0530 "Aneesh Kumar K.V" wrote: > Subject: [PATCH V4 0/3] * mm/kvm/vfio/ppc64: Migrate compound pages out of > CMA region Asterisk in title is strange? > ppc64 use CMA area for the allocation of guest page table (hash page table). > We won't > be able to start guest if we fail to allocate hash page table. We have > observed > hash table allocation failure because we failed to migrate pages out of CMA > region > because they were pinned. This happen when we are using VFIO. VFIO on ppc64 > pins > the entire guest RAM. If the guest RAM pages get allocated out of CMA region, > we > won't be able to migrate those pages. The pages are also pinned for the > lifetime of the > guest. > > Currently we support migration of non-compound pages. With THP and with the > addition of > hugetlb migration we can end up allocating compound pages from CMA region. > This > patch series add support for migrating compound pages. The first path adds > the helper > get_user_pages_cma_migrate() which pin the page making sure we migrate them > out of > CMA region before incrementing the reference count. Very little review activity. Perhaps Andrey and/or Michal can find the time.. > mm/migrate.c| 108 can we make this code disappear when CONFIG_CMA=n?
Re: [PATCH] crypto/testmgr: fix skcipher test with CONFIG_VMAP_STACK
On Fri, 7 Dec 2018 at 18:33, Christophe Leroy wrote:
>
> [2.364486] WARNING: CPU: 0 PID: 60 at ./arch/powerpc/include/asm/io.h:837
> dma_nommu_map_page+0x44/0xd4
> [2.373579] CPU: 0 PID: 60 Comm: cryptomgr_test Tainted: GW
> 4.20.0-rc5-00560-g6bfb52e23a00-dirty #531
> [2.384740] NIP: c000c540 LR: c000c584 CTR:
> [2.389743] REGS: c95abab0 TRAP: 0700 Tainted: GW
> (4.20.0-rc5-00560-g6bfb52e23a00-dirty)
> [2.400042] MSR: 00029032 CR: 24042204 XER:
> [2.406669]
> [2.406669] GPR00: c02f2244 c95abb60 c6262990 c95abd80 256a 0001
> 0001 0001
> [2.406669] GPR08: 2000 0010 0010 24042202
> 0100 c95abd88
> [2.406669] GPR16: c05569d4 0001 0010 c95abc88 c0615664
> 0004
> [2.406669] GPR24: 0010 c95abc88 c95abc88 c61ae210 c7ff6d40
> c61ae210 3d68
> [2.441559] NIP [c000c540] dma_nommu_map_page+0x44/0xd4
> [2.446720] LR [c000c584] dma_nommu_map_page+0x88/0xd4
> [2.451762] Call Trace:
> [2.454195] [c95abb60] [82000808] 0x82000808 (unreliable)
> [2.459572] [c95abb80] [c02f2244] talitos_edesc_alloc+0xbc/0x3c8
> [2.465493] [c95abbb0] [c02f2600] ablkcipher_edesc_alloc+0x4c/0x5c
> [2.471606] [c95abbd0] [c02f4ed0] ablkcipher_encrypt+0x20/0x64
> [2.477389] [c95abbe0] [c02023b0] __test_skcipher+0x4bc/0xa08
> [2.483049] [c95abe00] [c0204b60] test_skcipher+0x2c/0xcc
> [2.488385] [c95abe20] [c0204c48] alg_test_skcipher+0x48/0xbc
> [2.494064] [c95abe40] [c0205cec] alg_test+0x164/0x2e8
> [2.499142] [c95abf00] [c0200dec] cryptomgr_test+0x48/0x50
> [2.504558] [c95abf10] [c0039ff4] kthread+0xe4/0x110
> [2.509471] [c95abf40] [c000e1d0] ret_from_kernel_thread+0x14/0x1c
> [2.515532] Instruction dump:
> [2.518468] 7c7e1b78 7c9d2378 7cbf2b78 41820054 3d20c076 8089c200 3d20c076
> 7c84e850
> [2.526127] 8129c204 7c842e70 7f844840 419c0008 <0fe0> 2f9e
> 54847022 7c84fa14
> [2.533960] ---[ end trace bf78d94af73fe3b8 ]---
> [2.539123] talitos ff02.crypto: master data transfer error
> [2.544775] talitos ff02.crypto: TEA error: ISR 0x2000_0040
> [2.551625] alg: skcipher: encryption failed on test 1 for
> ecb-aes-talitos: ret=22
>
> IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack
> cannot be DMA mapped anymore.
>
> This patch allocates it with kmalloc()
>
This looks like a driver bug to me. Other accelerators in
drivers/crypto all take a copy of the IV before mapping it for DMA, so
it would be better if talitos did the same.
> Fixes: da7f033ddc9f ("crypto: cryptomgr - Add test infrastructure")
> Signed-off-by: Christophe Leroy
> ---
> crypto/testmgr.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/crypto/testmgr.c b/crypto/testmgr.c
> index b1f79c6bf409..eea498f9030d 100644
> --- a/crypto/testmgr.c
> +++ b/crypto/testmgr.c
> @@ -1112,12 +1112,16 @@ static int __test_skcipher(struct crypto_skcipher
> *tfm, int enc,
> struct crypto_wait wait;
> const char *input, *result;
> void *data;
> - char iv[MAX_IVLEN];
> + char *iv;
> char *xbuf[XBUFSIZE];
> char *xoutbuf[XBUFSIZE];
> int ret = -ENOMEM;
> unsigned int ivsize = crypto_skcipher_ivsize(tfm);
>
> + iv = kmalloc(MAX_IVLEN, GFP_KERNEL | GFP_DMA);
> + if (!iv)
> + goto out_noiv;
> +
> if (testmgr_alloc_buf(xbuf))
> goto out_nobuf;
>
> @@ -1339,6 +1343,8 @@ static int __test_skcipher(struct crypto_skcipher *tfm,
> int enc,
> out_nooutbuf:
> testmgr_free_buf(xbuf);
> out_nobuf:
> + kfree(iv);
> +out_noiv:
> return ret;
> }
>
> --
> 2.13.3
>
error: no previous prototype for ‘pt_regs_check’
Michael, I have been wondering for a while now, but I failed to make sense of this function: pt_regs_check (commit 002af9391bfbe). What is this function meant for ? Background, it breaks my W=1 build with: ../arch/powerpc/kernel/ptrace.c:3339:13: error: no previous prototype for ‘pt_regs_check’ [-Werror=missing-prototypes] I failed to find a usage of it within the linux source tree... (git grep pt_regs_check returns nothing). Thanks,
[PATCH v6] powerpc/ptrace: replace ptrace_report_syscall() with a tracehook call
From: Elvira Khabirova
Arch code should use tracehook_*() helpers, as documented
in include/linux/tracehook.h,
ptrace_report_syscall() is not expected to be used outside that file.
Co-authored-by: Dmitry V. Levin
Fixes: 5521eb4bca2d ("powerpc/ptrace: Add support for PTRACE_SYSEMU")
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Oleg Nesterov
Cc: Breno Leitao
Cc: Andy Lutomirski
Cc: Eugene Syromyatnikov
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Elvira Khabirova
Signed-off-by: Dmitry V. Levin
---
Please make either v5 or v6 edition of this fix, or any similar fix,
into v4.20.
v6: reverted to a fixed version of v4, compile- and run-tested with strace
v5: reverted to a simple approach, compile- and run-tested
v4: rewritten to call tracehook_report_syscall_entry() once, compile-tested
v3: add a descriptive comment
v2: explicitly ignore tracehook_report_syscall_entry() return code
arch/powerpc/kernel/ptrace.c | 54 +++-
1 file changed, 35 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index afb819f4ca68..fcfdc1229f08 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -3263,27 +3263,43 @@ static inline int do_seccomp(struct pt_regs *regs) {
return 0; }
*/
long do_syscall_trace_enter(struct pt_regs *regs)
{
+ struct thread_info *ti;
+ u32 cached_flags;
+
user_exit();
- if (test_thread_flag(TIF_SYSCALL_EMU)) {
- ptrace_report_syscall(regs);
- /*
-* Returning -1 will skip the syscall execution. We want to
-* avoid clobbering any register also, thus, not 'gotoing'
-* skip label.
-*/
- return -1;
- }
+ ti = current_thread_info();
+ cached_flags = READ_ONCE(ti->flags) &
+ (_TIF_SYSCALL_EMU | _TIF_SYSCALL_TRACE |
+ _TIF_SYSCALL_TRACEPOINT);
- /*
-* The tracer may decide to abort the syscall, if so tracehook
-* will return !0. Note that the tracer may also just change
-* regs->gpr[0] to an invalid syscall number, that is handled
-* below on the exit path.
-*/
- if (test_thread_flag(TIF_SYSCALL_TRACE) &&
- tracehook_report_syscall_entry(regs))
- goto skip;
+ if (cached_flags & (_TIF_SYSCALL_EMU | _TIF_SYSCALL_TRACE)) {
+ int rc = tracehook_report_syscall_entry(regs);
+
+ if (unlikely(cached_flags & _TIF_SYSCALL_EMU)) {
+ /*
+* A nonzero return code from
+* tracehook_report_syscall_entry() tells us
+* to prevent the syscall execution, but
+* we are not going to execute it anyway.
+*
+* Returning -1 will skip the syscall execution.
+* We want to avoid clobbering any register also,
+* thus, not 'gotoing' skip label.
+*/
+ return -1;
+ }
+
+ if (rc) {
+ /*
+* The tracer decided to abort the syscall.
+* Note that the tracer may also just change
+* regs->gpr[0] to an invalid syscall number,
+* that is handled below on the exit path.
+*/
+ goto skip;
+ }
+ }
/* Run seccomp after ptrace; allow it to set gpr[3]. */
if (do_seccomp(regs))
@@ -3293,7 +3309,7 @@ long do_syscall_trace_enter(struct pt_regs *regs)
if (regs->gpr[0] >= NR_syscalls)
goto skip;
- if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
+ if (unlikely(cached_flags & _TIF_SYSCALL_TRACEPOINT))
trace_sys_enter(regs, regs->gpr[0]);
#ifdef CONFIG_PPC64
--
ldv
Re: [PATCH RFC 4/7] riscv/vdso: don't clear PG_reserved
On Wed, 05 Dec 2018 04:28:48 PST (-0800), da...@redhat.com wrote: The VDSO is part of the kernel image and therefore the struct pages are marked as reserved during boot. As we install a special mapping, the actual struct pages will never be exposed to MM via the page tables. We can therefore leave the pages marked as reserved. Cc: Palmer Dabbelt Cc: Albert Ou Cc: Tobias Klauser Cc: Andrew Morton Cc: Michal Hocko Cc: Matthew Wilcox Signed-off-by: David Hildenbrand --- arch/riscv/kernel/vdso.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/riscv/kernel/vdso.c b/arch/riscv/kernel/vdso.c index 582cb153eb24..0cd044122234 100644 --- a/arch/riscv/kernel/vdso.c +++ b/arch/riscv/kernel/vdso.c @@ -54,7 +54,6 @@ static int __init vdso_init(void) struct page *pg; pg = virt_to_page(vdso_start + (i << PAGE_SHIFT)); - ClearPageReserved(pg); vdso_pagelist[i] = pg; } vdso_pagelist[i] = virt_to_page(vdso_data); I'm going to assume this will go in through another tree along with the rest of the set assuming everyone else is happy with it. Acked-by: Palmer Dabbelt Thanks!
Re: [PATCH v4] powerpc/ptrace: replace ptrace_report_syscall() with a tracehook call
On Fri, Dec 07, 2018 at 05:34:10PM +0100, Oleg Nesterov wrote: > On 12/07, Dmitry V. Levin wrote: > > On Fri, Dec 07, 2018 at 10:12:49PM +1100, Michael Ellerman wrote: > > > > > > Sorry, this patch does not work, please ignore it. > > > > > > Hmm OK. Why exactly? > > > > Unfortunately, I have no idea why it doesn't work. > > All I can say is it breaks strace because the kernel no longer sends > > syscall entry stops. > > May be because TIF_SYSCALL_EMU/etc is a bit number, not a mask? IOW, rather > than > > whatever & TIF_XXX > > you should do > > whatever & _TIF_XXX > > intstead? Thanks Oleg, this was exactly the reason why it didn't work. That kind of things happens when you let userspace people hack you kernel. :) -- ldv signature.asc Description: PGP signature
Re: [REPOST PATCH v6 0/4] kgdb: Fix kgdb_roundup_cpus()
Hi, On Fri, Dec 7, 2018 at 9:42 AM Catalin Marinas wrote: > > On Tue, Dec 04, 2018 at 07:38:24PM -0800, Douglas Anderson wrote: > > Douglas Anderson (4): > > kgdb: Remove irq flags from roundup > > kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function() > > kgdb: Don't round up a CPU that failed rounding up before > > kdb: Don't back trace on a cpu that didn't round up > > FWIW, trying these on arm64 (ThunderX2) with CONFIG_KGDB_TESTS_ON_BOOT=y > on top of 4.20-rc5 doesn't boot. It looks like they leave interrupts > disabled when they shouldn't and it trips over the BUG at > mm/vmalloc.c:1380 (called via do_fork -> copy_process). > > Now, I don't think these patches make things worse on arm64 since prior > to them the kgdb boot tests on arm64 were stuck in a loop (RUN > singlestep). Thanks for the report! ...actually, I'd never tried CONFIG_KGDB_TESTS before. ...so I tried them now: A) chromeos-4.19 tree on qcom-sdm845 without this series: booted up OK B) chromeos-4.19 tree on qcom-sdm845 with this series: booted up OK C) v4.20-rc5-90-g30002dd008ed on rockchip-rk3399 (kevin) with this series: booted up OK Example output from B) above: localhost ~ # dmesg | grep kgdbts [2.139814] KGDB: Registered I/O driver kgdbts [2.144582] kgdbts:RUN plant and detach test [2.165333] kgdbts:RUN sw breakpoint test [2.172990] kgdbts:RUN bad memory access test [2.178640] kgdbts:RUN singlestep test 1000 iterations [2.187765] kgdbts:RUN singlestep [0/1000] [2.559596] kgdbts:RUN singlestep [100/1000] [2.931419] kgdbts:RUN singlestep [200/1000] [3.303474] kgdbts:RUN singlestep [300/1000] [3.675121] kgdbts:RUN singlestep [400/1000] [4.046867] kgdbts:RUN singlestep [500/1000] [4.418920] kgdbts:RUN singlestep [600/1000] [4.790824] kgdbts:RUN singlestep [700/1000] [5.162479] kgdbts:RUN singlestep [800/1000] [5.534103] kgdbts:RUN singlestep [900/1000] [5.902299] kgdbts:RUN do_fork for 100 breakpoints [8.463900] KGDB: Unregistered I/O driver kgdbts, debugger disabled ...so I guess I'm a little confused. Either I have a different config than you do or something is special about your machine? NOTE: In general I've never considered "single step" as reliable in kgdb. I mostly use kgdb as "after the fact" crash debugging to analyze local variables / memory / other tasks. If it worked that'd actually be kinda great, but at least when I started using kgdb years ago I learned that it didn't work and stopped trying... -Doug
Re: use generic DMA mapping code in powerpc V4
Next step: 13c1fdec5682b6e13257277fa16aa31f342d167d (powerpc/dma: move pci_dma_dev_setup_swiotlb to fsl_pci.c) git checkout 13c1fdec5682b6e13257277fa16aa31f342d167d Result: The PASEMI onboard ethernet works and the X5000 boots. — Christian Sent from my iPhone > On 7. Dec 2018, at 14:45, Christian Zigotzky wrote: > >> On 06 December 2018 at 11:55AM, Christian Zigotzky wrote: >>> On 05 December 2018 at 3:05PM, Christoph Hellwig wrote: >>> >>> Thanks. Can you try a few stepping points in the tree? >>> >>> First just with commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 >>> (the first one) applied? >>> >>> Second with all commits up to 5da11e49df21f21dac25a2491aa788307bdacb6b >>> >>> And if that still works with commits up to >>> c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a >>> >> Hi Christoph, >> >> I undid the commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 with the >> following command: >> >> git checkout 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 >> >> Result: PASEMI onboard ethernet works again and the P5020 board boots. >> >> I will test the other commits in the next days. >> >> @All >> It is really important, that you also test Christoph's work on your PASEMI >> and NXP boards. Could you please help us with solving the issues? >> >> 'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a' >> >> Thanks, >> Christian >> >> > Today I tested the commit 5da11e49df21f21dac25a2491aa788307bdacb6b. > > git checkout 5da11e49df21f21dac25a2491aa788307bdacb6b > > The PASEMI onboard ethernet works and the P5020 board boots. > > -- Christian >
[PATCH] powerpc: implement CONFIG_DEBUG_VIRTUAL
This patch implements CONFIG_DEBUG_VIRTUAL to warn about
incorrect use of virt_to_phys() and page_to_phys()
Below is the result of test_debug_virtual:
[1.438746] WARNING: CPU: 0 PID: 1 at ./arch/powerpc/include/asm/io.h:808
test_debug_virtual_init+0x3c/0xd4
[1.448156] CPU: 0 PID: 1 Comm: swapper Not tainted
4.20.0-rc5-00560-g6bfb52e23a00-dirty #532
[1.457259] NIP: c066c550 LR: c0650ccc CTR: c066c514
[1.462257] REGS: c900bdb0 TRAP: 0700 Not tainted
(4.20.0-rc5-00560-g6bfb52e23a00-dirty)
[1.471184] MSR: 00029032 CR: 48000422 XER: 2000
[1.477811]
[1.477811] GPR00: c0650ccc c900be60 c60d 006000c0 c900
9032 c7fa0020
[1.477811] GPR08: 2400 0001 0900 c07b5d04
c00037d8
[1.477811] GPR16: c076 c074
0092 c0685bb0
[1.477811] GPR24: c065042c c068a734 c0685b8c 0006 c076
c075c3c0
[1.512711] NIP [c066c550] test_debug_virtual_init+0x3c/0xd4
[1.518315] LR [c0650ccc] do_one_initcall+0x8c/0x1cc
[1.523163] Call Trace:
[1.525595] [c900be60] [c0567340] 0xc0567340 (unreliable)
[1.530954] [c900be90] [c0650ccc] do_one_initcall+0x8c/0x1cc
[1.536551] [c900bef0] [c0651000] kernel_init_freeable+0x1f4/0x2cc
[1.542658] [c900bf30] [c00037ec] kernel_init+0x14/0x110
[1.547913] [c900bf40] [c000e1d0] ret_from_kernel_thread+0x14/0x1c
[1.553971] Instruction dump:
[1.556909] 3ca50100 bfa10024 54a5000e 3fa0c076 7c0802a6 3d454000 813dc204
554893be
[1.564566] 7d294010 7d294910 90010034 39290001 <0f09> 7c3e0b78 955e0008
3fe0c062
[1.572425] ---[ end trace 6f6984225b280ad6 ]---
[1.577467] PA: 0x0900 for VA: 0xc900
[1.581799] PA: 0x061e8f50 for VA: 0xc61e8f50
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/io.h | 12 +++-
arch/powerpc/mm/pgtable_32.c | 2 +-
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index fd634a293d7f..1a3ed380f7d0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -128,6 +128,7 @@ config PPC
#
# Please keep this list sorted alphabetically.
#
+ select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_DMA_SET_COHERENT_MASK
select ARCH_HAS_ELF_RANDOMIZE
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index e746becd9d6f..75fb9f110eb6 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -29,6 +29,7 @@ extern struct pci_dev *isa_bridge_pcidev;
#include
#include
+#include
#include
#include
#include
@@ -804,6 +805,8 @@ extern void __iounmap_at(void *ea, unsigned long size);
*/
static inline unsigned long virt_to_phys(volatile void * address)
{
+ WARN_ON(IS_ENABLED(CONFIG_DEBUG_VIRTUAL) && !virt_addr_valid(address));
+
return __pa((unsigned long)address);
}
@@ -827,7 +830,14 @@ static inline void * phys_to_virt(unsigned long address)
/*
* Change "struct page" to physical address.
*/
-#define page_to_phys(page) ((phys_addr_t)page_to_pfn(page) << PAGE_SHIFT)
+static inline phys_addr_t page_to_phys(struct page *page)
+{
+ unsigned long pfn = page_to_pfn(page);
+
+ WARN_ON(IS_ENABLED(CONFIG_DEBUG_VIRTUAL) && !pfn_valid(pfn));
+
+ return PFN_PHYS(pfn);
+}
/*
* 32 bits still uses virt_to_bus() for it's implementation of DMA
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index deb49a6e9cad..9c4e6ed19a93 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -143,7 +143,7 @@ __ioremap_caller(phys_addr_t addr, unsigned long size,
pgprot_t prot, void *call
* Don't allow anybody to remap normal RAM that we're using.
* mem_init() sets high_memory so only do the check after that.
*/
- if (slab_is_available() && (p < virt_to_phys(high_memory)) &&
+ if (slab_is_available() && virt_addr_valid(p) &&
page_is_ram(__phys_to_pfn(p))) {
printk("__ioremap(): phys addr 0x%llx is RAM lr %ps\n",
(unsigned long long)p, __builtin_return_address(0));
--
2.13.3
Re: [REPOST PATCH v6 0/4] kgdb: Fix kgdb_roundup_cpus()
On Tue, Dec 04, 2018 at 07:38:24PM -0800, Douglas Anderson wrote: > Douglas Anderson (4): > kgdb: Remove irq flags from roundup > kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function() > kgdb: Don't round up a CPU that failed rounding up before > kdb: Don't back trace on a cpu that didn't round up FWIW, trying these on arm64 (ThunderX2) with CONFIG_KGDB_TESTS_ON_BOOT=y on top of 4.20-rc5 doesn't boot. It looks like they leave interrupts disabled when they shouldn't and it trips over the BUG at mm/vmalloc.c:1380 (called via do_fork -> copy_process). Now, I don't think these patches make things worse on arm64 since prior to them the kgdb boot tests on arm64 were stuck in a loop (RUN singlestep). -- Catalin
[PATCH] crypto/testmgr: fix skcipher test with CONFIG_VMAP_STACK
[2.364486] WARNING: CPU: 0 PID: 60 at ./arch/powerpc/include/asm/io.h:837
dma_nommu_map_page+0x44/0xd4
[2.373579] CPU: 0 PID: 60 Comm: cryptomgr_test Tainted: GW
4.20.0-rc5-00560-g6bfb52e23a00-dirty #531
[2.384740] NIP: c000c540 LR: c000c584 CTR:
[2.389743] REGS: c95abab0 TRAP: 0700 Tainted: GW
(4.20.0-rc5-00560-g6bfb52e23a00-dirty)
[2.400042] MSR: 00029032 CR: 24042204 XER:
[2.406669]
[2.406669] GPR00: c02f2244 c95abb60 c6262990 c95abd80 256a 0001
0001 0001
[2.406669] GPR08: 2000 0010 0010 24042202
0100 c95abd88
[2.406669] GPR16: c05569d4 0001 0010 c95abc88 c0615664
0004
[2.406669] GPR24: 0010 c95abc88 c95abc88 c61ae210 c7ff6d40
c61ae210 3d68
[2.441559] NIP [c000c540] dma_nommu_map_page+0x44/0xd4
[2.446720] LR [c000c584] dma_nommu_map_page+0x88/0xd4
[2.451762] Call Trace:
[2.454195] [c95abb60] [82000808] 0x82000808 (unreliable)
[2.459572] [c95abb80] [c02f2244] talitos_edesc_alloc+0xbc/0x3c8
[2.465493] [c95abbb0] [c02f2600] ablkcipher_edesc_alloc+0x4c/0x5c
[2.471606] [c95abbd0] [c02f4ed0] ablkcipher_encrypt+0x20/0x64
[2.477389] [c95abbe0] [c02023b0] __test_skcipher+0x4bc/0xa08
[2.483049] [c95abe00] [c0204b60] test_skcipher+0x2c/0xcc
[2.488385] [c95abe20] [c0204c48] alg_test_skcipher+0x48/0xbc
[2.494064] [c95abe40] [c0205cec] alg_test+0x164/0x2e8
[2.499142] [c95abf00] [c0200dec] cryptomgr_test+0x48/0x50
[2.504558] [c95abf10] [c0039ff4] kthread+0xe4/0x110
[2.509471] [c95abf40] [c000e1d0] ret_from_kernel_thread+0x14/0x1c
[2.515532] Instruction dump:
[2.518468] 7c7e1b78 7c9d2378 7cbf2b78 41820054 3d20c076 8089c200 3d20c076
7c84e850
[2.526127] 8129c204 7c842e70 7f844840 419c0008 <0fe0> 2f9e 54847022
7c84fa14
[2.533960] ---[ end trace bf78d94af73fe3b8 ]---
[2.539123] talitos ff02.crypto: master data transfer error
[2.544775] talitos ff02.crypto: TEA error: ISR 0x2000_0040
[2.551625] alg: skcipher: encryption failed on test 1 for ecb-aes-talitos:
ret=22
IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack
cannot be DMA mapped anymore.
This patch allocates it with kmalloc()
Fixes: da7f033ddc9f ("crypto: cryptomgr - Add test infrastructure")
Signed-off-by: Christophe Leroy
---
crypto/testmgr.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index b1f79c6bf409..eea498f9030d 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1112,12 +1112,16 @@ static int __test_skcipher(struct crypto_skcipher *tfm,
int enc,
struct crypto_wait wait;
const char *input, *result;
void *data;
- char iv[MAX_IVLEN];
+ char *iv;
char *xbuf[XBUFSIZE];
char *xoutbuf[XBUFSIZE];
int ret = -ENOMEM;
unsigned int ivsize = crypto_skcipher_ivsize(tfm);
+ iv = kmalloc(MAX_IVLEN, GFP_KERNEL | GFP_DMA);
+ if (!iv)
+ goto out_noiv;
+
if (testmgr_alloc_buf(xbuf))
goto out_nobuf;
@@ -1339,6 +1343,8 @@ static int __test_skcipher(struct crypto_skcipher *tfm,
int enc,
out_nooutbuf:
testmgr_free_buf(xbuf);
out_nobuf:
+ kfree(iv);
+out_noiv:
return ret;
}
--
2.13.3
Re: [PATCH v3 00/12] perf/core: Generalise event exclusion checking
On Thu, Dec 06, 2018 at 04:47:17PM +, Andrew Murray wrote: > Many PMU drivers do not have the capability to exclude counting events > that occur in specific contexts such as idle, kernel, guest, etc. These > drivers indicate this by returning an error in their event_init upon > testing the events attribute flags. > > However this approach requires that each time a new event modifier is > added to perf, all the perf drivers need to be modified to indicate that > they don't support the attribute. This results in additional boiler-plate > code common to many drivers that needs to be maintained. Furthermore the > drivers are not consistent with regards to the error value they return > when reporting unsupported attributes. > > This patchset allow PMU drivers to advertise their inability to exclude > based on context via a new capability: PERF_PMU_CAP_NO_EXCLUDE. This > allows the perf core to reject requests for exclusion events where there > is no support in the PMU. > > This is a functional change, in particular: > > - Some drivers will now additionally (but correctly) report unsupported >exclusion flags. It's typical for existing userspace tools such as >perf to handle such errors by retrying the system call without the >unsupported flags. > > - Drivers that do not support any exclusion that previously reported >-EPERM or -EOPNOTSUPP will now report -EINVAL - this is consistent >with the majority and results in userspace perf retrying without >exclusion. > > All drivers touched by this patchset have been compile tested. For the bits under arch/arm/ and drivers/perf: Acked-by: Will Deacon Note that I've queued the TX2 uncore PMU for 4.21 [1], which could also benefit from your new flag. Will [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=for-next/perf&id=69c32972d59388c041268e8206e8eb1acff29b9a
Re: [PATCH v4] powerpc/ptrace: replace ptrace_report_syscall() with a tracehook call
On 12/07, Dmitry V. Levin wrote: > > On Fri, Dec 07, 2018 at 10:12:49PM +1100, Michael Ellerman wrote: > > > > Sorry, this patch does not work, please ignore it. > > > > Hmm OK. Why exactly? > > Unfortunately, I have no idea why it doesn't work. > All I can say is it breaks strace because the kernel no longer sends > syscall entry stops. May be because TIF_SYSCALL_EMU/etc is a bit number, not a mask? IOW, rather than whatever & TIF_XXX you should do whatever & _TIF_XXX intstead? Oleg.
[PATCH v5] powerpc/ptrace: replace ptrace_report_syscall() with a tracehook call
From: Elvira Khabirova
Arch code should use tracehook_*() helpers, as documented
in include/linux/tracehook.h,
ptrace_report_syscall() is not expected to be used outside that file.
The patch does not look very nice, but at least it is correct
and opens the way for PTRACE_GET_SYSCALL_INFO API.
Co-authored-by: Dmitry V. Levin
Fixes: 5521eb4bca2d ("powerpc/ptrace: Add support for PTRACE_SYSEMU")
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Oleg Nesterov
Cc: Breno Leitao
Cc: Andy Lutomirski
Cc: Eugene Syromyatnikov
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Elvira Khabirova
Signed-off-by: Dmitry V. Levin
---
v5: reverted to a simple approach, compile- and run-tested
v4: rewritten to call tracehook_report_syscall_entry() once, compile-tested
v3: add a descriptive comment
v2: explicitly ignore tracehook_report_syscall_entry() return code
arch/powerpc/kernel/ptrace.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index afb819f4ca68..714c3480c52d 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -3266,12 +3266,17 @@ long do_syscall_trace_enter(struct pt_regs *regs)
user_exit();
if (test_thread_flag(TIF_SYSCALL_EMU)) {
- ptrace_report_syscall(regs);
/*
+* A nonzero return code from tracehook_report_syscall_entry()
+* tells us to prevent the syscall execution, but we are not
+* going to execute it anyway.
+*
* Returning -1 will skip the syscall execution. We want to
* avoid clobbering any register also, thus, not 'gotoing'
* skip label.
*/
+ if (tracehook_report_syscall_entry(regs))
+ ;
return -1;
}
--
ldv
Re: [PATCH v4] powerpc/ptrace: replace ptrace_report_syscall() with a tracehook call
On Fri, Dec 07, 2018 at 10:12:49PM +1100, Michael Ellerman wrote:
> "Dmitry V. Levin" writes:
> > On Mon, Dec 03, 2018 at 06:18:23AM +0300, Dmitry V. Levin wrote:
> >> From: Elvira Khabirova
> >>
> >> Arch code should use tracehook_*() helpers, as documented
> >> in include/linux/tracehook.h,
> >> ptrace_report_syscall() is not expected to be used outside that file.
> >>
> >> Co-authored-by: Dmitry V. Levin
> >> Fixes: 5521eb4bca2d ("powerpc/ptrace: Add support for PTRACE_SYSEMU")
> >> Signed-off-by: Elvira Khabirova
> >> Signed-off-by: Dmitry V. Levin
> >> ---
> >> v4: rewritten to call tracehook_report_syscall_entry() once, compile-tested
> >> v3: add a descriptive comment
> >> v2: explicitly ignore tracehook_report_syscall_entry() return code
> >>
> >> arch/powerpc/kernel/ptrace.c | 54 +++-
> >> 1 file changed, 35 insertions(+), 19 deletions(-)
> >
> > Sorry, this patch does not work, please ignore it.
>
> Hmm OK. Why exactly?
Unfortunately, I have no idea why it doesn't work.
All I can say is it breaks strace because the kernel no longer sends
syscall entry stops.
> I wrote more or less the same patch, although I used a temporary bool.
>
> > However, the bug blocks PTRACE_GET_SYSCALL_INFO, so please fix it.
>
> Sorry, didn't realise it was blocking you.
We are changing ptrace_report_syscall signature to implement
PTRACE_GET_SYSCALL_INFO, and this is the only place in the kernel besides
tracehook_report_syscall_*() that invokes ptrace_report_syscall() directly.
> > I'm going to use
> > if (tracehook_report_syscall_entry(regs))
> > return -1;
> > return -1;
> > in the series until you have a better fix.
>
> Yeah that's fine by me. I could send that to Linus for 4.20 if you want
> me to, otherwise I'm fine for you to carry it in your series.
Yes, please. I'll send a v5 shortly.
--
ldv
signature.asc
Description: PGP signature
Re: [PATCH] bpf: fix overflow of bpf_jit_limit when PAGE_SIZE >= 64K
Quoting Michael Ellerman (2018-12-07 06:31:13)
> Michael Roth writes:
>
> > Commit ede95a63b5 introduced a bpf_jit_limit tuneable to limit BPF
> > JIT allocations. At compile time it defaults to PAGE_SIZE * 4,
> > and is adjusted again at init time if MODULES_VADDR is defined.
> >
> > For ppc64 kernels, MODULES_VADDR isn't defined, so we're stuck with
>
> But maybe it should be, I don't know why we don't define it.
>
> > the compile-time default at boot-time, which is 0x9c40 when
> > using 64K page size. This overflows the signed 32-bit bpf_jit_limit
> > value:
> >
> > root@ubuntu:/tmp# cat /proc/sys/net/core/bpf_jit_limit
> > -1673527296
> >
> > and can cause various unexpected failures throughout the network
> > stack. In one case `strace dhclient eth0` reported:
> >
> > setsockopt(5, SOL_SOCKET, SO_ATTACH_FILTER, {len=11, filter=0x105dd27f8},
> > 16) = -1 ENOTSUPP (Unknown error 524)
> >
> > and similar failures can be seen with tools like tcpdump. This doesn't
> > always reproduce however, and I'm not sure why. The more consistent
> > failure I've seen is an Ubuntu 18.04 KVM guest booted on a POWER9 host
> > would time out on systemd/netplan configuring a virtio-net NIC with no
> > noticeable errors in the logs.
> >
> > Fix this by limiting the compile-time default for bpf_jit_limit to
> > INT_MAX.
>
> INT_MAX is a lot more than (4k * 4), so I guess I'm not clear on
> whether we should be using PAGE_SIZE here at all. I guess each BPF
> program uses at least one page is the thinking?
That seems to be the case, at least, the max number of minimum-sized
allocations would be less on ppc64 since the allocations are always at
least PAGE_SIZE in size. The init-time default also limits to INT_MAX,
so it seemed consistent to do that here too.
>
> Thanks for tracking this down. For some reason none of my ~10 test boxes
> have hit this, perhaps I don't have new enough userspace?
I'm not too sure, I would've thought things like the dhclient case in
the commit log would fail every time, but sometimes I need to reboot the
guest before I start seeing the behavior. Maybe there's something special
about when JIT allocations are actually done that can affect
reproducibility?
In my case at least the virtio-net networking timeout was consistent
enough for a bisect, but maybe it depends on the specific network
configuration (single NIC, basic DHCP through netplan/systemd in my case).
>
> You don't mention why you needed to add BPF_MIN(), I assume because the
> kernel version of min() has gotten too complicated to work here?
I wasn't sure if it was safe here or not, so I tried looking at other
users and came across:
mm/vmalloc.c:777:#define VMAP_MIN(x, y) ((x) < (y) ? (x) : (y)) /*
can't use min() */
I'm not sure what the reasoning was (or whether it still applies), but I
figured it was safer to do the same here. Maybe Nick still recalls?
>
> Daniel I assume you'll merge this via your tree?
>
> cheers
>
> > Fixes: ede95a63b5e8 ("bpf: add bpf_jit_limit knob to restrict unpriv
> > allocations")
> > Cc: linuxppc-...@ozlabs.org
> > Cc: Daniel Borkmann
> > Cc: Sandipan Das
> > Cc: Alexei Starovoitov
> > Signed-off-by: Michael Roth
> > ---
> > kernel/bpf/core.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> > index b1a3545d0ec8..55de4746cdfd 100644
> > --- a/kernel/bpf/core.c
> > +++ b/kernel/bpf/core.c
> > @@ -365,7 +365,8 @@ void bpf_prog_kallsyms_del_all(struct bpf_prog *fp)
> > }
> >
> > #ifdef CONFIG_BPF_JIT
> > -# define BPF_JIT_LIMIT_DEFAULT (PAGE_SIZE * 4)
> > +# define BPF_MIN(x, y) ((x) < (y) ? (x) : (y))
> > +# define BPF_JIT_LIMIT_DEFAULT BPF_MIN((PAGE_SIZE * 4), INT_MAX)
> >
> > /* All BPF JIT sysctl knobs here. */
> > int bpf_jit_enable __read_mostly = IS_BUILTIN(CONFIG_BPF_JIT_ALWAYS_ON);
> > --
> > 2.17.1
>
Re: [PATCH 01/34] powerpc: use mm zones more sensibly
I will work at the weekend to figure out where the problematic commit is. — Christian Sent from my iPhone > On 7. Dec 2018, at 15:09, Christoph Hellwig wrote: > >> On Fri, Dec 07, 2018 at 11:18:18PM +1100, Michael Ellerman wrote: >> Christoph Hellwig writes: >> >>> Ben / Michael, >>> >>> can we get this one queued up for 4.21 to prepare for the DMA work later >>> on? >> >> I was hoping the PASEMI / NXP regressions could be solved before >> merging. >> >> My p5020ds is booting fine with this series, so I'm not sure why it's >> causing problems on Christian's machine. >> >> The last time I turned on my PASEMI board it tripped some breakers, so I >> need to investigate that before I can help test that. >> >> I'll see how things look on Monday and either merge the commits you >> identified or the whole series depending on if there's any more info >> from Christian. > > Christian just confirmed everything up to at least > "powerpc/dma: stop overriding dma_get_required_mask" works for his > setups.
Re: [PATCH 01/34] powerpc: use mm zones more sensibly
On Fri, Dec 07, 2018 at 11:18:18PM +1100, Michael Ellerman wrote: > Christoph Hellwig writes: > > > Ben / Michael, > > > > can we get this one queued up for 4.21 to prepare for the DMA work later > > on? > > I was hoping the PASEMI / NXP regressions could be solved before > merging. > > My p5020ds is booting fine with this series, so I'm not sure why it's > causing problems on Christian's machine. > > The last time I turned on my PASEMI board it tripped some breakers, so I > need to investigate that before I can help test that. > > I'll see how things look on Monday and either merge the commits you > identified or the whole series depending on if there's any more info > from Christian. Christian just confirmed everything up to at least "powerpc/dma: stop overriding dma_get_required_mask" works for his setups.
Re: [PATCH 3/4] powerpc/tm: Unset MSR[TS] if not recheckpointing
On Mon, 26 Nov 2018 18:12:00 -0200 Breno Leitao wrote: > There is a TM Bad Thing bug that can be caused when you return from a > signal context in a suspended transaction but with ucontext MSR[TS] unset. > > This forces regs->msr[TS] to be set at syscall entrance (since the CPU > state is transactional). It also calls treclaim() to flush the transaction > state, which is done based on the live (mfmsr) MSR state. > > Since user context MSR[TS] is not set, then restore_tm_sigcontexts() is not > called, thus, not executing recheckpoint, keeping the CPU state as not > transactional. When calling rfid, SRR1 will have MSR[TS] set, but the CPU > state is non transactional, causing the TM Bad Thing with the following > stack: > Works for me on Linux 4.4 and 4.12 Tested-by: Michal Suchánek Thanks
Re: [PATCH 4/4] selftests/powerpc: Add checks for transactional sigreturn
On Mon, 26 Nov 2018 18:12:01 -0200
Breno Leitao wrote:
Hello
> +
> +int main(int argc, char **argv)
> +{
> + test_harness(tm_signal_sigreturn_nt, "tm_signal_sigreturn_nt");
Should be something like
return test_harness(tm_signal_sigreturn_nt, "tm_signal_sigreturn_nt");
> +}
> +
Thanks
Michal
Re: use generic DMA mapping code in powerpc V4
On 06 December 2018 at 11:55AM, Christian Zigotzky wrote: On 05 December 2018 at 3:05PM, Christoph Hellwig wrote: Thanks. Can you try a few stepping points in the tree? First just with commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 (the first one) applied? Second with all commits up to 5da11e49df21f21dac25a2491aa788307bdacb6b And if that still works with commits up to c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a Hi Christoph, I undid the commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 with the following command: git checkout 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 Result: PASEMI onboard ethernet works again and the P5020 board boots. I will test the other commits in the next days. @All It is really important, that you also test Christoph's work on your PASEMI and NXP boards. Could you please help us with solving the issues? 'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a' Thanks, Christian Today I tested the commit 5da11e49df21f21dac25a2491aa788307bdacb6b. git checkout 5da11e49df21f21dac25a2491aa788307bdacb6b The PASEMI onboard ethernet works and the P5020 board boots. -- Christian
[PATCH] gpio: max7301: fix driver for use with CONFIG_VMAP_STACK
spi_read() and spi_write() require DMA-safe memory. When
CONFIG_VMAP_STACK is selected, those functions cannot be used
with buffers on stack.
This patch replaces calls to spi_read() and spi_write() by
spi_write_then_read() which doesn't require DMA-safe buffers.
Fixes: 0c36ec314735 ("gpio: gpio driver for max7301 SPI GPIO expander")
Cc:
Signed-off-by: Christophe Leroy
---
drivers/gpio/gpio-max7301.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpio/gpio-max7301.c b/drivers/gpio/gpio-max7301.c
index 68c7942d0a3c..6f7d12ba2f74 100644
--- a/drivers/gpio/gpio-max7301.c
+++ b/drivers/gpio/gpio-max7301.c
@@ -25,7 +25,7 @@ static int max7301_spi_write(struct device *dev, unsigned int
reg,
struct spi_device *spi = to_spi_device(dev);
u16 word = ((reg & 0x7F) << 8) | (val & 0xFF);
- return spi_write(spi, (const u8 *)&word, sizeof(word));
+ return spi_write_then_read(spi, &word, sizeof(word), NULL, 0);
}
/* A read from the MAX7301 means two transfers; here, one message each */
@@ -37,14 +37,8 @@ static int max7301_spi_read(struct device *dev, unsigned int
reg)
struct spi_device *spi = to_spi_device(dev);
word = 0x8000 | (reg << 8);
- ret = spi_write(spi, (const u8 *)&word, sizeof(word));
- if (ret)
- return ret;
- /*
-* This relies on the fact, that a transfer with NULL tx_buf shifts out
-* zero bytes (=NOOP for MAX7301)
-*/
- ret = spi_read(spi, (u8 *)&word, sizeof(word));
+ ret = spi_write_then_read(spi, &word, sizeof(word), &word,
+ sizeof(word));
if (ret)
return ret;
return word & 0xff;
--
2.13.3
Re: [1/7] drivers/cpufreq: change CONFIG_6xx to CONFIG_PPC_BOOK3S_32
On Sat, 2018-11-17 at 10:24:54 UTC, Christophe Leroy wrote: > Today, powerpc has three CONFIG labels which means exactly the same: > - CONFIG_6xx > - CONFIG_PPC_BOOK3S_32 > - CONFIG_PPC_STD_MMU_32 > > By consistency with PPC64, CONFIG_PPC_BOOK3S_32 is the preferred one. > Using a label with includes _PPC_ also makes it clearer that it is > linked to powerpc. > > In preparation of the removal of CONFIG_6xx, this patch replaces it > by CONFIG_PPC_BOOK3S_32 > > Signed-off-by: Christophe Leroy > Acked-by: Viresh Kumar Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/f99e33f12490d03e34e1b9cb1b3e3a cheers
Re: misc: cxl: Use device_type helpers to access the node type
On Fri, 2018-11-16 at 22:11:02 UTC, Rob Herring wrote: > Remove directly accessing device_node.type pointer and use the accessors > instead. This will eventually allow removing the type pointer. > > Cc: Frederic Barrat > Cc: Andrew Donnellan > Cc: Arnd Bergmann > Cc: Greg Kroah-Hartman > Cc: linuxppc-dev@lists.ozlabs.org > Signed-off-by: Rob Herring > Acked-by: Andrew Donnellan Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/d2db097905d6ec439b7e863dc9a7e7 cheers
Re: macintosh: Use device_type helpers to access the node type
On Fri, 2018-11-16 at 22:11:01 UTC, Rob Herring wrote: > Remove directly accessing device_node.type pointer and use the accessors > instead. This will eventually allow removing the type pointer. > > Cc: Benjamin Herrenschmidt > Cc: linuxppc-dev@lists.ozlabs.org > Signed-off-by: Rob Herring Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/bf82d3758d4a075d17f4930c9872b0 cheers
Re: powerpc: Use device_type helpers to access the node type
On Fri, 2018-11-16 at 22:11:00 UTC, Rob Herring wrote: > Remove directly accessing device_node.type pointer and use the accessors > instead. This will eventually allow removing the type pointer. > > Replace the open coded iterating over child nodes with > for_each_child_of_node() while we're here. > > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: Arnd Bergmann > Cc: linuxppc-dev@lists.ozlabs.org > Signed-off-by: Rob Herring Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/e5480bdcc4429e4c172d450ee1db19 cheers
Re: powerpc: Rework btext_find_display to use of_stdout and device_type helpers
On Fri, 2018-11-16 at 22:10:59 UTC, Rob Herring wrote: > Remove directly accessing device_node.type pointer and use the accessors > instead. This will eventually allow removing the type pointer. > > In the process, the of_stdout pointer can be used instead of finding the > stdout node again. > > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: linuxppc-dev@lists.ozlabs.org > Signed-off-by: Rob Herring Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/5b8d6be7b8dd286bd654e37d637ded cheers
Re: macintosh: windfarm: Another convert to using %pOFn instead of device_node.name
On Fri, 2018-11-16 at 22:05:39 UTC, Rob Herring wrote: > In preparation to remove the node name pointer from struct device_node, > convert printf users to use the %pOFn format specifier. > > Convert the open coded iterating thru child nodes to > for_each_child_of_node() while we're here. > > Cc: Benjamin Herrenschmidt > Cc: linuxppc-dev@lists.ozlabs.org > Signed-off-by: Rob Herring Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/15b680c474afd54dac05530d8fed41 cheers
Re: powerpc/mm: dump segment registers on book3s/32
On Fri, 2018-11-16 at 17:06:43 UTC, Christophe Leroy wrote: > This patch creates a debugfs file to see content of > segment registers > > ~# cat /sys/kernel/debug/segment_registers > ---[ User Segments ]--- > 0x-0x0fff Kern key 1 User key 1 VSID 0xade2b0 > 0x1000-0x1fff Kern key 1 User key 1 VSID 0xade3c1 > 0x2000-0x2fff Kern key 1 User key 1 VSID 0xade4d2 > 0x3000-0x3fff Kern key 1 User key 1 VSID 0xade5e3 > 0x4000-0x4fff Kern key 1 User key 1 VSID 0xade6f4 > 0x5000-0x5fff Kern key 1 User key 1 VSID 0xade805 > 0x6000-0x6fff Kern key 1 User key 1 VSID 0xade916 > 0x7000-0x7fff Kern key 1 User key 1 VSID 0xadea27 > 0x8000-0x8fff Kern key 1 User key 1 VSID 0xadeb38 > 0x9000-0x9fff Kern key 1 User key 1 VSID 0xadec49 > 0xa000-0xafff Kern key 1 User key 1 VSID 0xaded5a > 0xb000-0xbfff Kern key 1 User key 1 VSID 0xadee6b > > ---[ Kernel Segments ]--- > 0xc000-0xcfff Kern key 0 User key 1 VSID 0x000ccc > 0xd000-0xdfff Kern key 0 User key 1 VSID 0x000ddd > 0xe000-0xefff Kern key 0 User key 1 VSID 0x000eee > 0xf000-0x Kern key 0 User key 1 VSID 0x000fff > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/0261a508c9fcb33e60f09cac42032f cheers
Re: powerpc/xmon: Fix invocation inside lock region
On Thu, 2018-11-08 at 17:12:42 UTC, Breno Leitao wrote: > Currently xmon needs to get devtree_lock (through rtas_token()) during its > invocation (at crash time). If there is a crash while devtree_lock is being > held, then xmon tries to get the lock but spins forever and never get into > the interactive debugger, as in the following case: > > int *ptr = NULL; > raw_spin_lock_irqsave(&devtree_lock, flags); > *ptr = 0xdeadbeef; > > This patch avoids calling rtas_token(), thus trying to get the same lock, > at crash time. This new mechanism proposes getting the token at > initialization time (xmon_init()) and just consuming it at crash time. > > This would allow xmon to be possible invoked independent of devtree_lock > being held or not. > > Signed-off-by: Breno Leitao > Reviewed-by: Thiago Jung Bauermann Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/8d4a862276a9c30a269d368d324fb5 cheers
Re: powerpc/mm: remove unused function prototype
On Thu, 2018-11-01 at 21:54:01 UTC, Breno Leitao wrote:
> Commit f384796c40dc ("powerpc/mm: Add support for handling > 512TB address
> in SLB miss") removed function slb_miss_bad_addr(struct pt_regs *regs), but
> kept its declaration in the prototype file. This patch simply removes the
> function definition.
>
> Signed-off-by: Breno Leitao
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/f91203e71c64202b4b20fd0c2d5e94
cheers
Re: powerpc/tools/checkpatch: Ignore DT_SPLIT_BINDING_PATCH
On Tue, 2018-12-04 at 05:11:54 UTC, Russell Currey wrote: > >From what I've seen, every time this warning comes up it's bogus, > so let's ignore it. > > Signed-off-by: Russell Currey > Reviewed-by: Andrew Donnellan Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/afa202b6bd307f6a2e682c59e392f8 cheers
Re: [v3] powerpc/math-emu: Update macros from GCC
On Mon, 2018-12-03 at 23:07:46 UTC, Joel Stanley wrote: > The add_ss, sub_ddmmss, umul_ppmm and udiv_qrnnd macros originate > from GCC's longlong.h which in turn was copied from GMP's longlong.h a > few decades ago. > > This was found when compiling with clang: > >arch/powerpc/math-emu/fnmsub.c:46:2: error: invalid use of a cast in a >inline asm context requiring an l-value: remove the cast or build with >-fheinous-gnu-extensions >FP_ADD_D(R, T, B); >^ >... > >./arch/powerpc/include/asm/sfp-machine.h:283:27: note: expanded from >macro 'sub_ddmmss' > : "=r" ((USItype)(sh)), \ > ~~^~~ > > Segher points out: this was fixed in GCC over 16 years ago > ( https://gcc.gnu.org/r56600 ), and in GMP (where it comes from) > presumably before that. > > Update the add_ss, sub_ddmmss, umul_ppmm and udiv_qrnnd macros to > the latest GCC version in order to git rid of the invalid casts. These > were taken as-is from GCC's longlong in order to make future syncs > obvious. Other parts of sfp-machine.h were left as-is as the file > contains more features than present in longlong.h. > > Link: https://github.com/ClangBuiltLinux/linux/issues/260 > Signed-off-by: Joel Stanley > Reviewed-by: Nick Desaulniers > Reviewed-by: Segher Boessenkool Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/b682c8692442711684befe413cf93c cheers
Re: [v4] powerpc/mm: dump block address translation on book3s/32
On Mon, 2018-12-03 at 17:40:25 UTC, Christophe Leroy wrote: > This patch adds a debugfs file to dump block address translation: > > ~# cat /sys/kernel/debug/powerpc/block_address_translation > ---[ Instruction Block Address Translations ]--- > 0: - > 1: - > 2: 0xc000-0xcfff 0x Kernel EXEC coherent > 3: 0xd000-0xdfff 0x1000 Kernel EXEC coherent > 4: - > 5: - > 6: - > 7: - > > ---[ Data Block Address Translations ]--- > 0: - > 1: - > 2: 0xc000-0xcfff 0x Kernel RW coherent > 3: 0xd000-0xdfff 0x1000 Kernel RW coherent > 4: - > 5: - > 6: - > 7: - > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/7c91efce1608325634494b25ff6491 cheers
Re: [v9,01/20] powerpc/book3s32: Remove CONFIG_BOOKE dependent code
On Thu, 2018-11-29 at 14:06:47 UTC, Christophe Leroy wrote: > BOOK3S/32 cannot be BOOKE, so remove useless code > > Signed-off-by: Christophe Leroy Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/a43ccc4bc499cb592e2cb3b4ada8d3 cheers
Re: powerpc: annotate implicit fall throughs
On Wed, 2018-11-28 at 22:28:30 UTC, Stephen Rothwell wrote: > There is a plan to build the kernel with -Wimplicit-fallthrough and these > places in the code produced warnings, but because we build arch/powerpc > with -Werror, they became errors. Fix them up. > > This patch produces no change in behaviour, but should be reviewed in > case these are actually bugs not intentional fallthoughs. > > Cc: Kees Cook > Cc: Gustavo A. R. Silva > Cc: Nicholas Piggin > Cc: Balbir Singh > Signed-off-by: Stephen Rothwell Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/8ad940217cce2b6ccc8d8cc7156e9a cheers
Re: powerpc/pseries/cpuidle: Fix preempt warning
On Fri, 2018-11-23 at 16:30:11 UTC, Breno Leitao wrote: > When booting a pseries kernel with PREEMPT enabled, it dumps the following > warning: > >BUG: using smp_processor_id() in preemptible [] code: swapper/0/1 >caller is pseries_processor_idle_init+0x5c/0x22c >CPU: 13 PID: 1 Comm: swapper/0 Not tainted > 4.20.0-rc3-00090-g12201a0128bc-dirty #828 >Call Trace: >[c00429437ab0] [c09c8878] dump_stack+0xec/0x164 (unreliable) >[c00429437b00] [c05f2f24] check_preemption_disabled+0x154/0x160 >[c00429437b90] [c0cab8e8] > pseries_processor_idle_init+0x5c/0x22c >[c00429437c10] [c0010ed4] do_one_initcall+0x64/0x300 >[c00429437ce0] [c0c54500] kernel_init_freeable+0x3f0/0x500 >[c00429437db0] [c00112dc] kernel_init+0x2c/0x160 >[c00429437e20] [c000c1d0] ret_from_kernel_thread+0x5c/0x6c > > This happens because the code calls get_lppaca() which calls get_paca() and > it checks if preemption is disabled through check_preemption_disabled(). > > Preemption should be disabled because the per CPU variable may make no > sense if there is a preemption (and a CPU switch) after it reads the per > CPU data and when it is used. > > At this device driver specifically, it is not a problem, because this code > just need to have access to one lppaca struct, and it does not matter if it > is the current per CPU lppaca struct or not (i.e. when there is a > preemption and a CPU migration). > > That said, the most appropriated fix seems to be related to avoiding the > debug_smp_processor_id() call at get_paca(), instead of calling > preempt_disable() before get_paca(). > > Signed-off-by: Breno Leitao Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/2b038cbc5fcf12a7ee1cc9bfd5da1e cheers
Re: [PATCH] bpf: fix overflow of bpf_jit_limit when PAGE_SIZE >= 64K
Michael Roth writes:
> Commit ede95a63b5 introduced a bpf_jit_limit tuneable to limit BPF
> JIT allocations. At compile time it defaults to PAGE_SIZE * 4,
> and is adjusted again at init time if MODULES_VADDR is defined.
>
> For ppc64 kernels, MODULES_VADDR isn't defined, so we're stuck with
But maybe it should be, I don't know why we don't define it.
> the compile-time default at boot-time, which is 0x9c40 when
> using 64K page size. This overflows the signed 32-bit bpf_jit_limit
> value:
>
> root@ubuntu:/tmp# cat /proc/sys/net/core/bpf_jit_limit
> -1673527296
>
> and can cause various unexpected failures throughout the network
> stack. In one case `strace dhclient eth0` reported:
>
> setsockopt(5, SOL_SOCKET, SO_ATTACH_FILTER, {len=11, filter=0x105dd27f8},
> 16) = -1 ENOTSUPP (Unknown error 524)
>
> and similar failures can be seen with tools like tcpdump. This doesn't
> always reproduce however, and I'm not sure why. The more consistent
> failure I've seen is an Ubuntu 18.04 KVM guest booted on a POWER9 host
> would time out on systemd/netplan configuring a virtio-net NIC with no
> noticeable errors in the logs.
>
> Fix this by limiting the compile-time default for bpf_jit_limit to
> INT_MAX.
INT_MAX is a lot more than (4k * 4), so I guess I'm not clear on
whether we should be using PAGE_SIZE here at all. I guess each BPF
program uses at least one page is the thinking?
Thanks for tracking this down. For some reason none of my ~10 test boxes
have hit this, perhaps I don't have new enough userspace?
You don't mention why you needed to add BPF_MIN(), I assume because the
kernel version of min() has gotten too complicated to work here?
Daniel I assume you'll merge this via your tree?
cheers
> Fixes: ede95a63b5e8 ("bpf: add bpf_jit_limit knob to restrict unpriv
> allocations")
> Cc: linuxppc-...@ozlabs.org
> Cc: Daniel Borkmann
> Cc: Sandipan Das
> Cc: Alexei Starovoitov
> Signed-off-by: Michael Roth
> ---
> kernel/bpf/core.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index b1a3545d0ec8..55de4746cdfd 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -365,7 +365,8 @@ void bpf_prog_kallsyms_del_all(struct bpf_prog *fp)
> }
>
> #ifdef CONFIG_BPF_JIT
> -# define BPF_JIT_LIMIT_DEFAULT (PAGE_SIZE * 4)
> +# define BPF_MIN(x, y) ((x) < (y) ? (x) : (y))
> +# define BPF_JIT_LIMIT_DEFAULT BPF_MIN((PAGE_SIZE * 4), INT_MAX)
>
> /* All BPF JIT sysctl knobs here. */
> int bpf_jit_enable __read_mostly = IS_BUILTIN(CONFIG_BPF_JIT_ALWAYS_ON);
> --
> 2.17.1
Re: [PATCH 01/34] powerpc: use mm zones more sensibly
Christoph Hellwig writes:
> Ben / Michael,
>
> can we get this one queued up for 4.21 to prepare for the DMA work later
> on?
I was hoping the PASEMI / NXP regressions could be solved before
merging.
My p5020ds is booting fine with this series, so I'm not sure why it's
causing problems on Christian's machine.
The last time I turned on my PASEMI board it tripped some breakers, so I
need to investigate that before I can help test that.
I'll see how things look on Monday and either merge the commits you
identified or the whole series depending on if there's any more info
from Christian.
cheers
> On Wed, Nov 14, 2018 at 09:22:41AM +0100, Christoph Hellwig wrote:
>> Powerpc has somewhat odd usage where ZONE_DMA is used for all memory on
>> common 64-bit configfs, and ZONE_DMA32 is used for 31-bit schemes.
>>
>> Move to a scheme closer to what other architectures use (and I dare to
>> say the intent of the system):
>>
>> - ZONE_DMA: optionally for memory < 31-bit (64-bit embedded only)
>> - ZONE_NORMAL: everything addressable by the kernel
>> - ZONE_HIGHMEM: memory > 32-bit for 32-bit kernels
>>
>> Also provide information on how ZONE_DMA is used by defining
>> ARCH_ZONE_DMA_BITS.
>>
>> Contains various fixes from Benjamin Herrenschmidt.
>>
>> Signed-off-by: Christoph Hellwig
>> ---
>> arch/powerpc/Kconfig | 8 +---
>> arch/powerpc/include/asm/page.h | 2 +
>> arch/powerpc/include/asm/pgtable.h| 1 -
>> arch/powerpc/kernel/dma-swiotlb.c | 6 +--
>> arch/powerpc/kernel/dma.c | 7 +--
>> arch/powerpc/mm/mem.c | 47 +++
>> arch/powerpc/platforms/85xx/corenet_generic.c | 10
>> arch/powerpc/platforms/85xx/qemu_e500.c | 9
>> include/linux/mmzone.h| 2 +-
>> 9 files changed, 25 insertions(+), 67 deletions(-)
>>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index 8be31261aec8..c3613bc1 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -374,9 +374,9 @@ config PPC_ADV_DEBUG_DAC_RANGE
>> depends on PPC_ADV_DEBUG_REGS && 44x
>> default y
>>
>> -config ZONE_DMA32
>> +config ZONE_DMA
>> bool
>> -default y if PPC64
>> +default y if PPC_BOOK3E_64
>>
>> config PGTABLE_LEVELS
>> int
>> @@ -869,10 +869,6 @@ config ISA
>>have an IBM RS/6000 or pSeries machine, say Y. If you have an
>>embedded board, consult your board documentation.
>>
>> -config ZONE_DMA
>> -bool
>> -default y
>> -
>> config GENERIC_ISA_DMA
>> bool
>> depends on ISA_DMA_API
>> diff --git a/arch/powerpc/include/asm/page.h
>> b/arch/powerpc/include/asm/page.h
>> index f6a1265face2..fc8c9ac0c6be 100644
>> --- a/arch/powerpc/include/asm/page.h
>> +++ b/arch/powerpc/include/asm/page.h
>> @@ -354,4 +354,6 @@ typedef struct page *pgtable_t;
>> #endif /* __ASSEMBLY__ */
>> #include
>>
>> +#define ARCH_ZONE_DMA_BITS 31
>> +
>> #endif /* _ASM_POWERPC_PAGE_H */
>> diff --git a/arch/powerpc/include/asm/pgtable.h
>> b/arch/powerpc/include/asm/pgtable.h
>> index 9679b7519a35..8af32ce93c7f 100644
>> --- a/arch/powerpc/include/asm/pgtable.h
>> +++ b/arch/powerpc/include/asm/pgtable.h
>> @@ -66,7 +66,6 @@ extern unsigned long empty_zero_page[];
>>
>> extern pgd_t swapper_pg_dir[];
>>
>> -void limit_zone_pfn(enum zone_type zone, unsigned long max_pfn);
>> int dma_pfn_limit_to_zone(u64 pfn_limit);
>> extern void paging_init(void);
>>
>> diff --git a/arch/powerpc/kernel/dma-swiotlb.c
>> b/arch/powerpc/kernel/dma-swiotlb.c
>> index 5fc335f4d9cd..678811abccfc 100644
>> --- a/arch/powerpc/kernel/dma-swiotlb.c
>> +++ b/arch/powerpc/kernel/dma-swiotlb.c
>> @@ -108,12 +108,8 @@ int __init swiotlb_setup_bus_notifier(void)
>>
>> void __init swiotlb_detect_4g(void)
>> {
>> -if ((memblock_end_of_DRAM() - 1) > 0x) {
>> +if ((memblock_end_of_DRAM() - 1) > 0x)
>> ppc_swiotlb_enable = 1;
>> -#ifdef CONFIG_ZONE_DMA32
>> -limit_zone_pfn(ZONE_DMA32, (1ULL << 32) >> PAGE_SHIFT);
>> -#endif
>> -}
>> }
>>
>> static int __init check_swiotlb_enabled(void)
>> diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
>> index dbfc7056d7df..6551685a4ed0 100644
>> --- a/arch/powerpc/kernel/dma.c
>> +++ b/arch/powerpc/kernel/dma.c
>> @@ -50,7 +50,7 @@ static int dma_nommu_dma_supported(struct device *dev, u64
>> mask)
>> return 1;
>>
>> #ifdef CONFIG_FSL_SOC
>> -/* Freescale gets another chance via ZONE_DMA/ZONE_DMA32, however
>> +/* Freescale gets another chance via ZONE_DMA, however
>> * that will have to be refined if/when they support iommus
>> */
>> return 1;
>> @@ -94,13 +94,10 @@ void *__dma_nommu_alloc_coherent(struct device *dev,
>> size_t size,
>> }
>>
>> switch (zone) {
>> +#ifdef CONFIG_ZONE_DMA
>> case ZONE_DMA:
>> flag |= GFP_DMA;
>>
Re: [PATCH] pseries/hotplug: Add more delay in pseries_cpu_die while waiting for rtas-stop
On Fri, Dec 07, 2018 at 04:13:11PM +0530, Gautham R Shenoy wrote:
> Hi Thiago,
>
>
> Sure. I will test the patch and report back.
I added the following debug patch on top of your patch, and after an
hour's run, the system crashed. Appending the log at the end.
I suppose we still need to increase the number of tries since we wait
only for 2.5ms looping before giving up.
x8-
>From 9e9e1e459cdc63540a73575af359a7bc0d43e455 Mon Sep 17 00:00:00 2001
From: "Gautham R. Shenoy"
Date: Fri, 7 Dec 2018 16:47:25 +0530
Subject: [PATCH] Add debug on top of Thiago's patch
Signed-off-by: Gautham R. Shenoy
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c
b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index fad3ceb..2545aab 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -214,6 +214,9 @@ static void pseries_cpu_die(unsigned int cpu)
msleep(1);
}
} else if (get_preferred_offline_state(cpu) == CPU_STATE_OFFLINE) {
+ u64 tb_before = mftb();
+ u64 tb_after;
+
/*
* If the current state is not offline yet, it means that the
* dying CPU (which is in pseries_mach_cpu_die) didn't have a
@@ -230,6 +233,11 @@ static void pseries_cpu_die(unsigned int cpu)
break;
udelay(100);
}
+
+ tb_after = mftb();
+
+ printk("[DEBUG] Waited for CPU %d to enter rtas: tries=%d,
time=%llu\n", cpu, tries,
+ div_u64(tb_after - tb_before, tb_ticks_per_usec));
}
if (cpu_status != 0) {
--
1.9.4
x8-
cpu 112 (hwid 112) Ready to die...
[DEBUG] Waited for CPU 112 to enter rtas: tries=0, time=65
cpu 113 (hwid 113) Ready to die...
[DEBUG] Waited for CPU 113 to enter rtas: tries=0, time=1139
cpu 114 (hwid 114) Ready to die...
[DEBUG] Waited for CPU 114 to enter rtas: tries=0, time=1036
cpu 115 (hwid 115) Ready to die...
[DEBUG] Waited for CPU 115 to enter rtas: tries=0, time=133
cpu 116 (hwid 116) Ready to die...
[DEBUG] Waited for CPU 116 to enter rtas: tries=0, time=1231
cpu 117 (hwid 117) Ready to die...
[DEBUG] Waited for CPU 117 to enter rtas: tries=0, time=1231
cpu 118 (hwid 118) Ready to die...
[DEBUG] Waited for CPU 118 to enter rtas: tries=0, time=1231
cpu 119 (hwid 119) Ready to die...
[DEBUG] Waited for CPU 119 to enter rtas: tries=0, time=1131
cpu 104 (hwid 104) Ready to die...
[DEBUG] Waited for CPU 104 to enter rtas: tries=0, time=40
*** RTAS CALL BUFFER CORRUPTION ***
393: rtas32_call_buff_ptr=
0060 0060 0060 0060 [...`...`...`...`]
0060 0060 0060 0060 [...`...`...`...`]
0060 0060 0060 0060 [...`...`...`...`]
0060 0800 E07F ACA7 00C0 [...`]
2500 [%...]
306E 7572 [0nur]
4800 0008 [H...0nur]
394: rtas64_map_buff_ptr=
5046 5743 4F44 4500 [PFWCODE.]
6000 0069 [`..i]
[]
0005 0001 []
1A00 []
8018 6398 0300 00C0 [..c.]
[..c.]
cpu 105 (hwid 105) Ready to die...
Bad kernel stack pointer 1fafb6c0 at 0
Oops: Bad kernel stack pointer, sig: 6 [#1]
LE SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 105 PID: 0 Comm: swapper/105 Not tainted 4.20.0-rc5-thiago+ #45
NIP: LR: CTR: 007829c8
REGS: c0001e63bd30 TRAP: 0700 Not tainted (4.20.0-rc5-thiago+)
MSR: 80081000 CR: 2804 XER: 0010
CFAR: 1ec153f0 IRQMASK: 80009033
GPR00: 1fafb6c0 1ec236a0 0040
GPR04: 00c0 0080 00046c4fb4842557 00cd
GPR08: 0001f400 1ed035dc
GPR12: c0001eb5e480 c003a1b53f90 1eea3e20
GPR16: c006fd845100 c004c8b0 c13d5300
GPR20: c006fd845300 0008 c19d2cf8 c13d6888
GPR24: 0069 c13d688c 0002 c13d688c
GPR28: c19cecf0 0348
NIP [] (null)
LR [] (null)
Call Trace:
Instruction dump:
XX
Re: [PATCH v2 30/34] dt-bindings: arm: Convert Tegra board/soc bindings to json-schema
On Thu, Dec 06, 2018 at 04:38:44PM -0600, Rob Herring wrote: > On Tue, Dec 4, 2018 at 2:50 AM Thierry Reding > wrote: > > > > On Mon, Dec 03, 2018 at 03:32:19PM -0600, Rob Herring wrote: > > > Convert Tegra SoC bindings to DT schema format using json-schema. > > > > > > Cc: Mark Rutland > > > Cc: Thierry Reding > > > Cc: Jonathan Hunter > > > Cc: devicet...@vger.kernel.org > > > Cc: linux-te...@vger.kernel.org > > > Signed-off-by: Rob Herring > > > --- > > > .../devicetree/bindings/arm/tegra.txt | 65 --- > > > .../devicetree/bindings/arm/tegra.yaml| 101 ++ > > > 2 files changed, 101 insertions(+), 65 deletions(-) > > > delete mode 100644 Documentation/devicetree/bindings/arm/tegra.txt > > > create mode 100644 Documentation/devicetree/bindings/arm/tegra.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/arm/tegra.txt > > > b/Documentation/devicetree/bindings/arm/tegra.txt > > > deleted file mode 100644 > > > index c59b15f64346.. > > > --- a/Documentation/devicetree/bindings/arm/tegra.txt > > > +++ /dev/null > > > @@ -1,65 +0,0 @@ > > > -NVIDIA Tegra device tree bindings > > > > > > - > > > -SoCs > > > > > > - > > > -Each device tree must specify which Tegra SoC it uses, using one of the > > > -following compatible values: > > > - > > > - nvidia,tegra20 > > > - nvidia,tegra30 > > > - nvidia,tegra114 > > > - nvidia,tegra124 > > > - nvidia,tegra132 > > > - nvidia,tegra210 > > > - nvidia,tegra186 > > > - nvidia,tegra194 > > > - > > > -Boards > > > > > > - > > > -Each device tree must specify which one or more of the following > > > -board-specific compatible values: > > > - > > > - ad,medcom-wide > > > - ad,plutux > > > - ad,tamonten > > > - ad,tec > > > - compal,paz00 > > > - compulab,trimslice > > > - nvidia,beaver > > > - nvidia,cardhu > > > - nvidia,cardhu-a02 > > > - nvidia,cardhu-a04 > > > - nvidia,dalmore > > > - nvidia,harmony > > > - nvidia,jetson-tk1 > > > - nvidia,norrin > > > - nvidia,p2371- > > > - nvidia,p2371-2180 > > > - nvidia,p2571 > > > - nvidia,p2771- > > > - nvidia,p2972- > > > - nvidia,roth > > > - nvidia,seaboard > > > - nvidia,tn7 > > > - nvidia,ventana > > > - toradex,apalis_t30 > > > - toradex,apalis_t30-eval > > > - toradex,apalis_t30-v1.1 > > > - toradex,apalis_t30-v1.1-eval > > > - toradex,apalis-tk1 > > > - toradex,apalis-tk1-eval > > > - toradex,apalis-tk1-v1.2 > > > - toradex,apalis-tk1-v1.2-eval > > > - toradex,colibri_t20 > > > - toradex,colibri_t20-eval-v3 > > > - toradex,colibri_t20-iris > > > - toradex,colibri_t30 > > > - toradex,colibri_t30-eval-v3 > > > - > > > -Trusted Foundations > > > > > > -Tegra supports the Trusted Foundation secure monitor. See the > > > -"tlm,trusted-foundations" binding's documentation for more details. > > > diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml > > > b/Documentation/devicetree/bindings/arm/tegra.yaml > > > new file mode 100644 > > > index ..66493892ffc1 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/arm/tegra.yaml > > > @@ -0,0 +1,101 @@ > > > +# SPDX-License-Identifier: GPL-2.0 > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/arm/tegra.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > Could you explain what these are? They give 404, so I assume they are > > more like placeholders and not actually used? > > Please read the documentation in patch 2. They are used, but aren't live URLs. Okay, thanks for pointing that out. I wasn't Cc'ed on that patch, so it took a while to hunt it down. > > > + > > > +title: NVIDIA Tegra device tree bindings > > > + > > > +maintainers: > > > + - Marcel Ziswiler > > > + - Peter De Schrijver > > > > Not sure how you got that list, but probably from git history. I think > > it makes sense to replace Marcel and Peter with Jon and myself. > > Will do. > > > Other than that, looks fine to me. Some of the enumerations below look > > somewhat hard to parse, but I suspect that it will become second nature > > in no time. > > We can add descriptions and/or comments if that helps. I didn't add > them if not already there. My comment was regarding the schema syntax with the oneOf, - items, etc. That's all new to me and difficult to read, but I'm sure I'll get used to it. Thierry signature.asc Description: PGP signature
Re: [PATCH] KVM: PPC: Book3S PR: Set hflag to indicate that POWER9 supports 1T segments
On Fri, Dec 07, 2018 at 10:08:20PM +1100, Michael Ellerman wrote: > Suraj Jitindar Singh writes: > > > When booting a kvm-pr guest on a POWER9 machine the following message is > > observed: > > "qemu-system-ppc64: KVM does not support 1TiB segments which guest expects" > > > > This is because the guest is expecting to be able to use 1T segments > > however we don't indicate support for it. This is because we don't set > > the BOOK3S_HFLAG_MULTI_PGSIZE flag in the hflags in kvmppc_set_pvr_pr() > > on POWER9. > > > > POWER9 does indeed have support for 1T segments, so add a case for > > POWER9 to the switch statement to ensure it is set. > > If this just checked mmu_has_feature(MMU_FTR_1T_SEGMENT) it would have > been right in this case, and we'd also never have to update it in > future. > > Any reason not to? PR KVM can emulate a different processor from the host. Checking mmu_has_feature() will tell you about the host, not the CPU being emulated. Paul.
Re: [PATCH v2 2/2] kgdb/treewide: constify struct kgdb_arch arch_kgdb_ops
Christophe Leroy writes:
> checkpatch.pl reports the following:
>
> WARNING: struct kgdb_arch should normally be const
> #28: FILE: arch/mips/kernel/kgdb.c:397:
> +struct kgdb_arch arch_kgdb_ops = {
>
> This report makes sense, as all other ops struct, this
> one should also be const. This patch does the change.
...
> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> index 59c578f865aa..bdb588b1d8fb 100644
> --- a/arch/powerpc/kernel/kgdb.c
> +++ b/arch/powerpc/kernel/kgdb.c
> @@ -477,7 +477,7 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
> /*
> * Global data
> */
> -struct kgdb_arch arch_kgdb_ops;
> +const struct kgdb_arch arch_kgdb_ops;
>
> static int kgdb_not_implemented(struct pt_regs *regs)
> {
Acked-by: Michael Ellerman (powerpc)
cheers
Re: [PATCH v4] powerpc/ptrace: replace ptrace_report_syscall() with a tracehook call
"Dmitry V. Levin" writes:
> On Mon, Dec 03, 2018 at 06:18:23AM +0300, Dmitry V. Levin wrote:
>> From: Elvira Khabirova
>>
>> Arch code should use tracehook_*() helpers, as documented
>> in include/linux/tracehook.h,
>> ptrace_report_syscall() is not expected to be used outside that file.
>>
>> Co-authored-by: Dmitry V. Levin
>> Fixes: 5521eb4bca2d ("powerpc/ptrace: Add support for PTRACE_SYSEMU")
>> Signed-off-by: Elvira Khabirova
>> Signed-off-by: Dmitry V. Levin
>> ---
>> v4: rewritten to call tracehook_report_syscall_entry() once, compile-tested
>> v3: add a descriptive comment
>> v2: explicitly ignore tracehook_report_syscall_entry() return code
>>
>> arch/powerpc/kernel/ptrace.c | 54 +++-
>> 1 file changed, 35 insertions(+), 19 deletions(-)
>
> Sorry, this patch does not work, please ignore it.
Hmm OK. Why exactly?
I wrote more or less the same patch, although I used a temporary bool.
> However, the bug blocks PTRACE_GET_SYSCALL_INFO, so please fix it.
Sorry, didn't realise it was blocking you.
> I'm going to use
> if (tracehook_report_syscall_entry(regs))
> return -1;
> return -1;
> in the series until you have a better fix.
Yeah that's fine by me. I could send that to Linus for 4.20 if you want
me to, otherwise I'm fine for you to carry it in your series.
cheers
Re: [PATCH] KVM: PPC: Book3S PR: Set hflag to indicate that POWER9 supports 1T segments
Suraj Jitindar Singh writes: > When booting a kvm-pr guest on a POWER9 machine the following message is > observed: > "qemu-system-ppc64: KVM does not support 1TiB segments which guest expects" > > This is because the guest is expecting to be able to use 1T segments > however we don't indicate support for it. This is because we don't set > the BOOK3S_HFLAG_MULTI_PGSIZE flag in the hflags in kvmppc_set_pvr_pr() > on POWER9. > > POWER9 does indeed have support for 1T segments, so add a case for > POWER9 to the switch statement to ensure it is set. If this just checked mmu_has_feature(MMU_FTR_1T_SEGMENT) it would have been right in this case, and we'd also never have to update it in future. Any reason not to? cheers > diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c > index 4efd65d9e828..82840160c606 100644 > --- a/arch/powerpc/kvm/book3s_pr.c > +++ b/arch/powerpc/kvm/book3s_pr.c > @@ -587,6 +587,7 @@ void kvmppc_set_pvr_pr(struct kvm_vcpu *vcpu, u32 pvr) > case PVR_POWER8: > case PVR_POWER8E: > case PVR_POWER8NVL: > + case PVR_POWER9: > vcpu->arch.hflags |= BOOK3S_HFLAG_MULTI_PGSIZE | > BOOK3S_HFLAG_NEW_TLBIE; > break; > -- > 2.13.6
Re: [PATCH] pseries/hotplug: Add more delay in pseries_cpu_die while waiting for rtas-stop
Hi Thiago, On Thu, Dec 06, 2018 at 03:28:17PM -0200, Thiago Jung Bauermann wrote: [..snip..] > > > I posted a similar patch last year, but I wasn't able to arrive at a > root cause analysis like you did: > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-February/153734.html Ah! Nice. So this is a known problem. > > One thing I realized after I posted the patch was that in my case, the > CPU was crashing inside RTAS. From the NIP and LR in the trace above it > looks like it's crashing in RTAS in your case as well. > > Michael Ellerman had two comments on my patch: > > 1. Regardless of the underlying bug, the kernel shouldn't crash so we > need a patch making it more resilient to this failure. > > 2. The wait loop should use udelay() so that the loop will actually take > a set amount of wall time, rather than just cycles. > > Regarding 1. if the problem is that the kernel is causing RTAS to crash > because it calls it in a way that's unsupported, then I don't see how we > can make the kernel more resilient. We have to make the kernel respect > RTAS' restrictions (or alternatively, poke RTAS devs to make RTAS fail > gracefuly in these conditions). I agree that the Kernel has to respect RTAS's restriction. The PAPR v2.8.1, Requirement R1-7.2.3-8 under section 7.2.3 says the following: "The stop-self service needs to be serialized with calls to the stop-self, start-cpu, and set-power-level services. The OS must be able to call RTAS services on other processors while the processor is stopped or being stopped" Thus the onus is on the OS to ensure that there are no concurrent rtas calls with "stop-self" token. > > Regarding 2. I implemented a new version of my patch (posted below) but > I was never able to test it because I couldn't access a system where the > problem was reproducible anymore. > > There's also a race between the CPU driving the unplug and the CPU being > unplugged which I think is not easy for the CPU being unplugged to win, > which makes the busy loop in pseries_cpu_die() a bit fragile. I describe > the race in the patch description. > > My solution to make the race less tight is to make the CPU driving the > unplug to only start the busy loop only after the CPU being unplugged is > in the CPU_STATE_OFFLINE state. At that point, we know that it either is > about to call RTAS or it already has. Ah, yes this is good optimization. Though, I think we ought to unconditionally wait until the target CPU has woken up from CEDE and changed its state to CPU_STATE_OFFLINE. After if PROD failed, then we would have caught it in dlpar_offline_cpu() itself. > > Do you think this makes sense? If you do, would you mind testing my > patch? You can change the timeouts and delays if you want. To be honest > they're just guesses on my part... Sure. I will test the patch and report back. -- Thanks and Regards gautham.
Re: [PATCH v4 0/5] powerpc: system call table generation support
Hi Satheesh, On Fri, 7 Dec 2018 at 12:57, Satheesh Rajendran wrote: > > On Fri, Dec 07, 2018 at 11:41:35AM +0530, Firoz Khan wrote: > Hi Firoz, > > This version(v4) booted fine in IBM Power8 box. Sounds good. Thanks for the support. Thanks Arnd for sharing the solution for "split compat syscall table out from native table" If someone can review this patch series and queue it for 4.21 would be great. Thanks Firoz > Compiled with 'ppc64le_defconfig' aginst > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=merge&id=a26b21082959cee3075b3edb7ef23071c7e0b09a > > Reference failure v3 version: > https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-November/182110.html > > Regards, > -Satheesh.
[PATCH] soc: fsl: guts: us devm_kstrdup_const() for RO data
devm_kstrdup() may return NULL if internal allocation failed, but
as machine is from the device tree, and thus RO, devm_kstrdup_const()
can be used here, which will only copy the reference.
Signed-off-by: Nicholas Mc Guire
Fixes: a6fc3b698130 ("soc: fsl: add GUTS driver for QorIQ platforms")
---
Problem located by experimental coccinelle script
Patch was compile tested with: multi_v7_defconfig (implies FSL_GUTS=y)
Patch is against 4.20-rc5 (localversion-next is next-20181207)
drivers/soc/fsl/guts.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index 302e0c8..15071ec 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -157,7 +157,8 @@ static int fsl_guts_probe(struct platform_device *pdev)
of_property_read_string_index(root, "compatible", 0, &machine);
of_node_put(root);
if (machine)
- soc_dev_attr.machine = devm_kstrdup(dev, machine, GFP_KERNEL);
+ soc_dev_attr.machine = devm_kstrdup_const(dev, machine,
+ GFP_KERNEL);
svr = fsl_guts_get_svr();
soc_die = fsl_soc_die_match(svr, fsl_soc_die);
--
2.1.4
