* Re: [PATCH v2 0/6] PAXB INTx support with proper model
From: Florian Fainelli @ 2019-09-04 17:16 UTC (permalink / raw)
To: Srinath Mannam, Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring,
Mark Rutland, Andy Shevchenko, Arnd Bergmann
Cc: linux-pci, bcm-kernel-feedback-list, linux-kernel,
linux-arm-kernel, devicetree
In-Reply-To: <1566982488-9673-1-git-send-email-srinath.mannam@broadcom.com>
On 8/28/19 1:54 AM, Srinath Mannam wrote:
> This patch series adds PCIe legacy interrupt (INTx) support to the iProc
> PCIe driver by modeling it with its own IRQ domain. All 4 interrupts INTA,
> INTB, INTC, INTD share the same interrupt line connected to the GIC
> in the system. This is now modeled by using its own IRQ domain.
>
> Also update all relevant devicetree files to adapt to the new model.
>
> This patch set is based on Linux-5.2-rc4.
>
> Changes from v1:
> - Addressed Rob, Lorenzo, Arnd's comments
> - Used child node for interrupt controller.
> - Addressed Andy Shevchenko's comments
> - Replaced while loop with do-while.
Lorenzo, Bjorn, if you are good with the binding and PCI host driver
changes, you can take patches 1-2 through your tree, and I will queue up
the others through the Broadcom ARM SoC pull requests. If not, please
feel free to add a:
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Ray Jui (6):
> dt-bindings: pci: Update iProc PCI binding for INTx support
> PCI: iproc: Add INTx support with better modeling
> arm: dts: Change PCIe INTx mapping for Cygnus
> arm: dts: Change PCIe INTx mapping for NSP
> arm: dts: Change PCIe INTx mapping for HR2
> arm64: dts: Change PCIe INTx mapping for NS2
>
> .../devicetree/bindings/pci/brcm,iproc-pcie.txt | 48 ++++++++--
> arch/arm/boot/dts/bcm-cygnus.dtsi | 30 ++++++-
> arch/arm/boot/dts/bcm-hr2.dtsi | 30 ++++++-
> arch/arm/boot/dts/bcm-nsp.dtsi | 45 ++++++++--
> arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 28 +++++-
> drivers/pci/controller/pcie-iproc.c | 100 ++++++++++++++++++++-
> drivers/pci/controller/pcie-iproc.h | 6 ++
> 7 files changed, 260 insertions(+), 27 deletions(-)
>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next 15/15] thermal: rcar: use devm_platform_ioremap_resource() to simplify code
From: Wolfram Sang @ 2019-09-04 17:25 UTC (permalink / raw)
To: YueHaibing
Cc: mans, mmayer, eric, miquel.raynal, linux-stm32, heiko,
amit.kucheria, f.fainelli, daniel.lezcano, phil, linux-rockchip,
agross, bcm-kernel-feedback-list, linux-arm-msm, rui.zhang,
david.hernandezsanchez, alexandre.torgue, marc.w.gonzalez, rjui,
edubezval, linux-mediatek, linux-rpi-kernel, gregory.0xf0,
matthias.bgg, horms+renesas, talel, linux-arm-kernel, sbranden,
wsa+renesas, gregkh, linux-pm, linux-kernel, wahrenst,
mcoquelin.stm32, jun.nie, computersforpeace, shawnguo
In-Reply-To: <20190904122939.23780-16-yuehaibing@huawei.com>
[-- Attachment #1.1: Type: text/plain, Size: 472 bytes --]
On Wed, Sep 04, 2019 at 08:29:39PM +0800, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
I think for such straightforward (and manifold) conversions, one patch
per subsystem is better than one patch per driver. But this is not my
subsystem, so I'll leave it to the thermal maintainers.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 03/10] arm64: atomics: avoid out-of-line ll/sc atomics
From: Nick Desaulniers @ 2019-09-04 17:28 UTC (permalink / raw)
To: Andrew Murray
Cc: Mark Rutland, Peter Zijlstra, Catalin Marinas, Robin Murphy,
Ard.Biesheuvel, Nathan Chancellor, Will Deacon, Linux ARM
In-Reply-To: <20190903220412.GU9720@e119886-lin.cambridge.arm.com>
On Tue, Sep 3, 2019 at 3:04 PM Andrew Murray <andrew.murray@arm.com> wrote:
>
> On Tue, Sep 03, 2019 at 05:37:55PM +0100, Will Deacon wrote:
> > On Tue, Sep 03, 2019 at 04:31:20PM +0100, Andrew Murray wrote:
> > > On Tue, Sep 03, 2019 at 04:15:44PM +0100, Andrew Murray wrote:
> > > > On Tue, Sep 03, 2019 at 03:45:34PM +0100, Will Deacon wrote:
> > > > > Does it work if the only thing you change is the toolchain, and use GCC
> > > > > instead?
> > > >
> > > > Yup.
> > >
> > > Also this is Clang generation:
> > >
> > > ffff8000100f2700 <__ptrace_link>:
> > > ffff8000100f2700: f9426009 ldr x9, [x0, #1216]
> > > ffff8000100f2704: 91130008 add x8, x0, #0x4c0
> > > ffff8000100f2708: eb09011f cmp x8, x9
> > > ffff8000100f270c: 540002a1 b.ne ffff8000100f2760 <__ptrace_link+0x60> // b.any
> > > ffff8000100f2710: f9425829 ldr x9, [x1, #1200]
> > > ffff8000100f2714: 9112c02a add x10, x1, #0x4b0
> > > ffff8000100f2718: f9000528 str x8, [x9, #8]
> > > ffff8000100f271c: f9026009 str x9, [x0, #1216]
> > > ffff8000100f2720: f902640a str x10, [x0, #1224]
> > > ffff8000100f2724: f9025828 str x8, [x1, #1200]
> > > ffff8000100f2728: f9024001 str x1, [x0, #1152]
> > > ffff8000100f272c: b4000162 cbz x2, ffff8000100f2758 <__ptrace_link+0x58>
> > > ffff8000100f2730: b900985f str wzr, [x2, #152]
> > > ffff8000100f2734: 14000004 b ffff8000100f2744 <__ptrace_link+0x44>
> > > ffff8000100f2738: 14000001 b ffff8000100f273c <__ptrace_link+0x3c>
> > > ffff8000100f273c: 14000006 b ffff8000100f2754 <__ptrace_link+0x54>
> > > ffff8000100f2740: 14000001 b ffff8000100f2744 <__ptrace_link+0x44>
> > > ffff8000100f2744: 52800028 mov w8, #0x1 // #1
> > > ffff8000100f2748: b828005f stadd w8, [x2]
> > > ffff8000100f274c: f9030002 str x2, [x0, #1536]
> > > ffff8000100f2750: d65f03c0 ret
> > > ffff8000100f2754: 140007fd b ffff8000100f4748 <ptrace_check_attach+0xf8>
> > > ...
> > >
> > > This looks like the default path (before we write over it) will take you to
> > > the LSE code (e.g. ffff8000100f2734). I'm pretty sure this is wrong, or at
> > > least not what we expected to see. Also why 4 branches?
> >
> > So I reproduced this with a silly atomic_inc wrapper:
> >
> > void will_atomic_inc(atomic_t *v)
> > {
> > atomic_inc(v);
> > }
> >
> > Compiles to:
> >
> > 0000000000000018 <will_atomic_inc>:
> > 18: 14000004 b 28 <will_atomic_inc+0x10>
> > 1c: 14000001 b 20 <will_atomic_inc+0x8>
> > 20: 14000005 b 34 <will_atomic_inc+0x1c>
> > 24: 14000001 b 28 <will_atomic_inc+0x10>
> > 28: 52800028 mov w8, #0x1 // #1
> > 2c: b828001f stadd w8, [x0]
> > 30: d65f03c0 ret
> > 34: 14000027 b d0 <dump_kernel_offset+0x60>
> > 38: d65f03c0 ret
> >
> > which is going to explode.
>
> I've come up with a simple reproducer for this issue:
>
> static bool branch_jump()
> {
> asm_volatile_goto(
> "1: b %l[l_yes2]"
> : : : : l_yes2);
>
> return false;
> l_yes2:
> return true;
> }
>
> static bool branch_test()
> {
> return (!branch_jump() && !branch_jump());
> }
>
> void andy_test(int *v)
> {
> if (branch_test())
> *v = 0xff;
> }
>
> This leads to the following (it shouldn't do anything):
>
> 0000000000000000 <andy_test>:
> 0: 14000004 b 10 <andy_test+0x10>
> 4: 14000001 b 8 <andy_test+0x8>
> 8: 14000004 b 18 <andy_test+0x18>
> c: 14000001 b 10 <andy_test+0x10>
> 10: 52801fe8 mov w8, #0xff // #255
> 14: b9000008 str w8, [x0]
> 18: d65f03c0 ret
>
> The issue goes away with any of the following hunks:
>
>
> @@ -55,7 +55,7 @@ static bool branch_jump()
>
> static bool branch_test()
> {
> - return (!branch_jump() && !branch_jump());
> + return (!branch_jump());
> }
>
> void andy_test(int *v)
>
>
> or:
>
>
> @@ -53,14 +53,10 @@ static bool branch_jump()
> return true;
> }
>
> -static bool branch_test()
> -{
> - return (!branch_jump() && !branch_jump());
> -}
>
> void andy_test(int *v)
> {
> - if (branch_test())
> + if (!branch_jump() && !branch_jump())
> *v = 0xff;
> }
Indeed, playing with the definition of `__lse_ll_sc_body`, I can get
the kernel to boot again.
So I think your very helpful test cases are illustrating two different problems:
https://godbolt.org/z/dMf7x-
See the disassembly of `andy_test2`. Reference to the correct label
is emitted in the inline asm, but there's some silly unconditional
branches to the next instruction. That's issue #1 and part of the
reason you see superfluous branches. With that fixed, `andy_test2`
would match between GCC and Clang. I think that can be a very late
peephole optimization (and further, we could probably combine labels
that refer to the same location, oh and .Lfunc_endX could just use
`.`, too!). LLVM devs noted that the x86 backend doesn't have this
issue, but this is a curiously recurring pattern I'm noticing in LLVM
where some arch agnostic optimization is only implemented for x86...
I'm reading through our Branch Folding pass which I think should
handle this, but I'll need to fire up a debugger.
Issue #2 is the more critical issue, but may be conflated with issue
#1. Issue #2 is the nonsensical control flow with one level of
inlining. See how in the disassembly of `andy_test`, the first label
referenced from inline assembly is *before* the mov/str when it should
have been *after*. Not sure where we could be going wrong, but it's
straightforward for me to observe the code change as its transformed
through LLVM, and I've debugged and fixed issues related to inlining
asm goto before.
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] SOC: TI soc updates for 5.4
From: santosh.shilimkar @ 2019-09-04 17:35 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Olof Johansson, arm-soc, linux-kernel@vger.kernel.org, Linux ARM,
Kevin Hilman
In-Reply-To: <CAK8P3a3_NWWBFrpNpbPH9+47Segi_EaYx2jx5jvPhYJJqR+a7A@mail.gmail.com>
On 9/4/19 6:13 AM, Arnd Bergmann wrote:
> On Tue, Aug 27, 2019 at 5:12 AM Santosh Shilimkar
> <santosh.shilimkar@oracle.com> wrote:
>
>> ----------------------------------------------------------------
>> soc: TI soc updates for 5.4
>>
>> - Update firmware to support PM domain shared and exclusive support
>> - Update driver and dt binding docs for the same.
>>
>> ----------------------------------------------------------------
>>
>> Lokesh Vutla (3):
>> firmware: ti_sci: Allow for device shared and exclusive requests
>> dt-bindings: ti_sci_pm_domains: Add support for exclusive and shared
>> access
>> soc: ti: ti_sci_pm_domains: Add support for exclusive and shared
>> access
>
> Hi Santosh,
>
> I noticed that your branch is based on top of v5.3-rc2, while my
> arm/drivers branch started out from -rc1.
>
> Do you have any dependencies on -rc2 in your changes? If not,
> could you please resubmit after rebasing? I can also just
> cherry-pick those three commits if that's easier.
>
No dependencies. Can you please cherry pick them this time ?
Will use rc1 for future pull request(s). Thanks !!
Regards,
Santosh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 0/5] arm: exynos: Second round of pulls for v5.4
From: Krzysztof Kozlowski @ 2019-09-04 17:49 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, arm, soc
Cc: linux-samsung-soc, Kukjin Kim, linux-arm-kernel,
Krzysztof Kozlowski, linux-kernel
Hi,
Notes:
1. One patch for soc64 sent directly, not as pull req.
2. Drivers and DTS pulls are on top of previous.
3. mach/soc pull replaces previous pull (I see it was not merged).
No dependencies between pulls.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 1/5] ARM: defconfig: exynos for v5.4
From: Krzysztof Kozlowski @ 2019-09-04 17:49 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, arm, soc
Cc: linux-samsung-soc, Kukjin Kim, linux-arm-kernel,
Krzysztof Kozlowski, linux-kernel
In-Reply-To: <20190904175002.10487-1-krzk@kernel.org>
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-5.4
for you to fetch changes up to 86759eeb32f70193ca7ebd50cc9b70ccb73d3d89:
ARM: multi_v7_defconfig: Make MAX77802 regulator driver built-in (2019-09-02 17:38:20 +0200)
----------------------------------------------------------------
Samsung defconfig changes for v5.4
1. Enable AHCI platform driver on exynos defconfig for Exynos5250-based
Arndale board,
2. Make Max77802 PMIC regulator driver a built-in on multi_v7 defconfig
as it is essential early during boot.
----------------------------------------------------------------
Marek Szyprowski (2):
ARM: exynos_defconfig: Enable AHCI-platform SATA driver
ARM: multi_v7_defconfig: Make MAX77802 regulator driver built-in
arch/arm/configs/exynos_defconfig | 5 ++++-
arch/arm/configs/multi_v7_defconfig | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 2/5] soc: samsung: Second pull for v5.4
From: Krzysztof Kozlowski @ 2019-09-04 17:49 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, arm, soc
Cc: linux-samsung-soc, Kukjin Kim, linux-arm-kernel,
Krzysztof Kozlowski, linux-kernel
In-Reply-To: <20190904175002.10487-1-krzk@kernel.org>
Hi,
On top of previous pull request.
Best regards,
Krzysztof
The following changes since commit 40d8aff614f71ab3cab20785b4f213e3802d4e87:
soc: samsung: chipid: Convert exynos-chipid driver to use the regmap API (2019-08-15 20:25:25 +0200)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-5.4-2
for you to fetch changes up to 28578825ede61834a2c46e7f9a89012c4c7a667f:
soc: samsung: chipid: Select missing dependency for EXYNOS_CHIPID (2019-08-22 20:16:20 +0200)
----------------------------------------------------------------
Samsung soc drivers changes for v5.4, part 2
Fixes and cleanups for recently introduced Exynos chipid driver.
----------------------------------------------------------------
Colin Ian King (1):
soc: samsung: chipid: Fix memory leak in error path
Sylwester Nawrocki (2):
soc: samsung: chipid: Remove the regmap lookup error log
soc: samsung: chipid: Select missing dependency for EXYNOS_CHIPID
drivers/soc/samsung/Kconfig | 1 +
drivers/soc/samsung/exynos-chipid.c | 18 +++++++++++-------
2 files changed, 12 insertions(+), 7 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 3/5] ARM: dts: exynos: Second pull for v5.4
From: Krzysztof Kozlowski @ 2019-09-04 17:50 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, arm, soc
Cc: linux-samsung-soc, Kukjin Kim, linux-arm-kernel,
Krzysztof Kozlowski, linux-kernel
In-Reply-To: <20190904175002.10487-1-krzk@kernel.org>
Hi,
On top of previous pull request.
Best regards,
Krzysztof
The following changes since commit bfb77169306d5d560a8b62eebaf6d69d02e8d152:
ARM: dts: exynos: Add CAM power domain to Exynos5422/5800 (2019-08-12 19:02:59 +0200)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-5.4-2
for you to fetch changes up to 51c88919e52873c83f8be0c8f5d0ffd654f1ef4a:
ARM: dts: exynos: Enable GPU/Mali T604 on Arndale board (2019-09-04 19:25:33 +0200)
----------------------------------------------------------------
Samsung DTS ARM changes for v5.4, part 2
1. Fix Exynos542x Chromebooks boot with multi_v7 defconfig,
2. Add GPU (Mali) support to Exynos5250 boards,
3. Minor cleanup for Exynos3250 ADC.
----------------------------------------------------------------
Guillaume Gardet (4):
ARM: dts: exynos: Fix min/max buck4 for GPU on Arndale board
ARM: dts: exynos: Add GPU/Mali T604 node to Exynos5250
ARM: dts: exynos: Enable GPU/Mali T604 on Chromebook Snow
ARM: dts: exynos: Enable GPU/Mali T604 on Arndale board
Krzysztof Kozlowski (1):
ARM: dts: exynos: Remove not accurate secondary ADC compatible
Marek Szyprowski (1):
ARM: dts: exynos: Mark LDO10 as always-on on Peach Pit/Pi Chromebooks
arch/arm/boot/dts/exynos3250.dtsi | 3 +-
arch/arm/boot/dts/exynos5250-arndale.dts | 9 +++--
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 5 +++
arch/arm/boot/dts/exynos5250.dtsi | 47 +++++++++++++++++++++++++++
arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 +
arch/arm/boot/dts/exynos5800-peach-pi.dts | 1 +
6 files changed, 62 insertions(+), 4 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 4/5] ARM: samsung: mach for v5.4, second (replacing previous)
From: Krzysztof Kozlowski @ 2019-09-04 17:50 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, arm, soc
Cc: linux-samsung-soc, Kukjin Kim, linux-arm-kernel,
Krzysztof Kozlowski, linux-kernel
In-Reply-To: <20190904175002.10487-1-krzk@kernel.org>
Hi,
Replaces previous pull (and it includes it).
Best regards,
Krzysztof
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-5.4-2
for you to fetch changes up to c663d542bfb40eeeb6d393ed155c23a4666d65e1:
MAINTAINERS: Extend patterns for Samsung SoC, Security Subsystem and clock drivers (2019-08-22 21:04:45 +0200)
----------------------------------------------------------------
Samsung mach/soc changes for v5.4
1. Minor fixup in plat and mach code (S3C platforms),
2. Enable exynos-chipid driver to provide SoC related information,
3. Extend the patterns for Samsung maintainer entries to cover all
important files.
----------------------------------------------------------------
Krzysztof Kozlowski (1):
MAINTAINERS: Extend patterns for Samsung SoC, Security Subsystem and clock drivers
Linus Walleij (1):
ARM: samsung: Include GPIO driver header
Masahiro Yamada (1):
ARM: s3c64xx: squash samsung_usb_phy.h into setup-usb-phy.c
Pankaj Dubey (1):
ARM: exynos: Enable exynos-chipid driver
MAINTAINERS | 9 +++++++--
arch/arm/mach-exynos/Kconfig | 1 +
arch/arm/mach-s3c64xx/setup-usb-phy.c | 5 +++++
arch/arm/plat-samsung/include/plat/gpio-core.h | 1 +
arch/arm/plat-samsung/include/plat/usb-phy.h | 2 --
include/linux/usb/samsung_usb_phy.h | 17 -----------------
6 files changed, 14 insertions(+), 21 deletions(-)
delete mode 100644 include/linux/usb/samsung_usb_phy.h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1] firmware: meson_sm: use %*ph to print small buffer
From: Andy Shevchenko @ 2019-09-04 17:48 UTC (permalink / raw)
To: Kevin Hilman, Neil Armstrong, linux-arm-kernel, linux-amlogic
Cc: Andy Shevchenko
Use %*ph format to print small buffer as hex string.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/firmware/meson/meson_sm.c | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/firmware/meson/meson_sm.c b/drivers/firmware/meson/meson_sm.c
index 8d908a8e0d20..8ea27af435da 100644
--- a/drivers/firmware/meson/meson_sm.c
+++ b/drivers/firmware/meson/meson_sm.c
@@ -231,19 +231,7 @@ static ssize_t serial_show(struct device *dev, struct device_attribute *attr,
return ret;
}
- ret = sprintf(buf, "%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x\n",
- id_buf[SM_CHIP_ID_OFFSET + 0],
- id_buf[SM_CHIP_ID_OFFSET + 1],
- id_buf[SM_CHIP_ID_OFFSET + 2],
- id_buf[SM_CHIP_ID_OFFSET + 3],
- id_buf[SM_CHIP_ID_OFFSET + 4],
- id_buf[SM_CHIP_ID_OFFSET + 5],
- id_buf[SM_CHIP_ID_OFFSET + 6],
- id_buf[SM_CHIP_ID_OFFSET + 7],
- id_buf[SM_CHIP_ID_OFFSET + 8],
- id_buf[SM_CHIP_ID_OFFSET + 9],
- id_buf[SM_CHIP_ID_OFFSET + 10],
- id_buf[SM_CHIP_ID_OFFSET + 11]);
+ ret = sprintf(buf, "%12phN\n", &id_buf[SM_CHIP_ID_OFFSET]);
kfree(id_buf);
--
2.23.0.rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/5] arm64: exynos: Enable exynos-chipid driver
From: Krzysztof Kozlowski @ 2019-09-04 17:50 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, arm, soc
Cc: linux-samsung-soc, Bartlomiej Zolnierkiewicz, Pankaj Dubey,
linux-kernel, Krzysztof Kozlowski, Kukjin Kim, Sylwester Nawrocki,
linux-arm-kernel
In-Reply-To: <20190904175002.10487-1-krzk@kernel.org>
From: Pankaj Dubey <pankaj.dubey@samsung.com>
Enable Exynos Chipid driver for accessing SoC related information.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/Kconfig.platforms | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 4778c775de1b..8a098fb4f04c 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -77,6 +77,7 @@ config ARCH_BRCMSTB
config ARCH_EXYNOS
bool "ARMv8 based Samsung Exynos SoC family"
select COMMON_CLK_SAMSUNG
+ select EXYNOS_CHIPID
select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
select EXYNOS_PMU
select HAVE_S3C2410_WATCHDOG if WATCHDOG
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Applied "ASoC: sirf-audio: use devm_platform_ioremap_resource() to simplify code" to the asoc tree
From: Mark Brown @ 2019-09-04 17:53 UTC (permalink / raw)
To: YueHaibing
Cc: kstewart, alsa-devel, linux-kernel, gregkh, tiwai, yuehaibing,
baohua, lgirdwood, Hulk Robot, Mark Brown, linux-arm-kernel,
pakki001, tglx, perex, allison
In-Reply-To: <20190904083412.18700-1-yuehaibing@huawei.com>
The patch
ASoC: sirf-audio: use devm_platform_ioremap_resource() to simplify code
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 2f302d476c960fdf8481399a46b8df92408d06e2 Mon Sep 17 00:00:00 2001
From: YueHaibing <yuehaibing@huawei.com>
Date: Wed, 4 Sep 2019 16:34:12 +0800
Subject: [PATCH] ASoC: sirf-audio: use devm_platform_ioremap_resource() to
simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190904083412.18700-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/codecs/sirf-audio-codec.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/sound/soc/codecs/sirf-audio-codec.c b/sound/soc/codecs/sirf-audio-codec.c
index 9009a7407b7a..a061d78473ac 100644
--- a/sound/soc/codecs/sirf-audio-codec.c
+++ b/sound/soc/codecs/sirf-audio-codec.c
@@ -459,7 +459,6 @@ static int sirf_audio_codec_driver_probe(struct platform_device *pdev)
int ret;
struct sirf_audio_codec *sirf_audio_codec;
void __iomem *base;
- struct resource *mem_res;
sirf_audio_codec = devm_kzalloc(&pdev->dev,
sizeof(struct sirf_audio_codec), GFP_KERNEL);
@@ -468,8 +467,7 @@ static int sirf_audio_codec_driver_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, sirf_audio_codec);
- mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- base = devm_ioremap_resource(&pdev->dev, mem_res);
+ base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
return PTR_ERR(base);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded
From: Heinrich Schuchardt @ 2019-09-04 18:07 UTC (permalink / raw)
To: Marc Zyngier
Cc: Peter Maydell, Daniel P . Berrangé, Suzuki K Pouloze,
Heinrich Schuchardt, Julien Thierry, linux-kernel, James Morse,
Stefan Hajnoczi, kvmarm, linux-arm-kernel
If an application tries to access memory that is not mapped, an error
ENOSYS, "load/store instruction decoding not implemented" may occur.
QEMU will hang with a register dump.
Instead create a data abort that can be handled gracefully by the
application running in the virtual environment.
Now the virtual machine can react to the event in the most appropriate
way - by recovering, by writing an informative log, or by rebooting.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
virt/kvm/arm/mmio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/arm/mmio.c b/virt/kvm/arm/mmio.c
index a8a6a0c883f1..0cbed7d6a0f4 100644
--- a/virt/kvm/arm/mmio.c
+++ b/virt/kvm/arm/mmio.c
@@ -161,8 +161,8 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run *run,
if (ret)
return ret;
} else {
- kvm_err("load/store instruction decoding not implemented\n");
- return -ENOSYS;
+ kvm_inject_dabt(vcpu, kvm_vcpu_get_hfar(vcpu));
+ return 1;
}
rt = vcpu->arch.mmio_decode.rt;
--
2.23.0.rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [GIT PULL] i.MX clock changes for 5.4
From: Stephen Boyd @ 2019-09-04 18:13 UTC (permalink / raw)
To: Shawn Guo
Cc: Stefan Agner, linux-imx, kernel, Fabio Estevam, linux-clk,
linux-arm-kernel
In-Reply-To: <20190825115505.GA20454@X250>
Quoting Shawn Guo (2019-08-25 04:55:06)
> Hi Stephen,
>
> This is the i.MX clock changes I collected for 5.4. Please help pull,
> and keep commit 6ad7cb7122ce ("clk: imx8: Add DSP related clocks")
> stable, as I pulled it into my DT branch as dependency. Thanks!
>
> Shawn
>
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/clk-imx-5.4
>
> for you to fetch changes up to 760e548e7f885d89bf2dfab4838df9379edd19fc:
>
> clk: imx: imx8mn: fix audio pll setting (2019-08-24 21:04:27 +0200)
>
> ----------------------------------------------------------------
Thanks. Pulled into clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] soc: qcom: geni: Provide parameter error checking
From: Bjorn Andersson @ 2019-09-04 18:27 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-arm-msm, agross, linux-kernel, linux-arm-kernel
In-Reply-To: <20190904084554.GF26880@dell>
On Wed 04 Sep 01:45 PDT 2019, Lee Jones wrote:
> On Tue, 03 Sep 2019, Bjorn Andersson wrote:
>
> > On Tue 03 Sep 06:50 PDT 2019, Lee Jones wrote:
> >
> > > When booting with ACPI, the Geni Serial Engine is not set as the I2C/SPI
> > > parent and thus, the wrapper (parent device) is unassigned. This causes
> > > the kernel to crash with a null dereference error.
> > >
> >
> > Now I see what you did in 8bc529b25354; i.e. stubbed all the other calls
> > between the SE and wrapper.
> >
> > Do you think it would be possible to resolve the _DEP link to QGP[01]
> > somehow?
>
> I looked at QGP{0,1}, but did not see it represented in the current
> Device Tree implementation and thus failed to identify it. Do you
> know what it is? Does it have a driver in Linux already?
>
QGP0 is the same hardware block as &qupv3_id_0, but apparently both are
only representing a smaller part - and different ones.
But conceptually both represents the wrapper...
> > For the clocks workarounds this could be resolved by us
> > representing that relationship using device_link and just rely on
> > pm_runtime to propagate the clock state.
>
> That is not allowed when booting ACPI. The Clock/Regulator frameworks
> are not to be used in this use-case, hence why all of the calls to
> these frameworks are "stubbed out". If we wanted to properly
> implement power management, we would have to create a driver/subsystem
> similar to the "Windows-compatible System Power Management Controller"
> (PEP). Without documentation for the PEP, this would be an impossible
> task. A request for the aforementioned documentation has been put in
> to Lenovo/Qualcomm. Hopefully something appears soon.
>
I see, so the PEP states needs to be parsed and associated with each
device and we would use pm_runtime to toggle between the states and
device_links to ensure that _DEP nodes are powered in appropriate order.
That seems reasonable and straight forward and the reliance on
pm_runtime will make the DT case cleaner as well.
> > For the DMA operation, iiuc it's the wrapper that implements the DMA
> > engine involved, but I'm guessing the main reason for mapping buffers on
> > the wrapper is so that it ends up being associated with the iommu
> > context of the wrapper.
>
> Judging by the code alone, the wrapper doesn't sound like it does much
> at all. It seems to only have a single (version) register (at least
> that is the only register that's used). The only registers it
> reads/writes are those of the calling device, whether that be I2C, SPI
> or UART.
>
> Device Tree represents the wrapper's relationship with the I2C (and
> SPI/UART) Serial Engine (SE) devices as parent-child ones, with the
> wrapper being the parent and SE the child. Whether this is a true
> representation of the hardware or just a tactic used for convenience
> is not clear, but the same representation does not exist in ACPI.
>
> In the current Linux implementation, the buffer belongs to the SE
> (obtained by the child (e.g. I2C) SE by fetching the parent's
> (wrapper's) device data using the standard platform helpers) but the
> register-set used to control the DMA transactions belong to the SE
> devices.
>
Yeah, I saw this as well. If all the SEs where the wrappers iommu domain
things should work fine by mapping it on the se->dev, regardless of the
device's being linked together.
The remaining relationship to the wrapper would then be reduced to the
read of the version to check for 1.0 or 1.1 hardware in the SPI driver,
which can be replaced by the assumption that we're on 1.1.
> > Are the SMMU contexts at all represented in the ACPI world and if so do
> > you know how the wrapper vs SEs are bound to contexts? Can we map on
> > se->dev when wrapper is NULL (or perhaps always?)?
>
> Yes, the SMMU devices are represented in ACPI (MMU0) and (MMU1). They
> share the same register addresses as the SMMU devices located in
> arch/arm64/boot/dts/qcom/sdm845.dtsi.
>
Right but this only describes the IOMMU devices, I don't see any
information about how individual client devices relates to the various
IOMMU contexts.
> With this simple parameter checking patch, the SE falls back to using
> FIFO mode to transmit data and continues to work flawlessly. IMHO
> this should be applied in the first instance, as it fixes a real (null
> dereference) bug which currently resides in the Mainline kernel.
>
Per the current driver design the wrapper device is the parent of the
SE, I should have seen that 8bc529b25354 was the beginning of a game of
whac-a-mole circumventing this design. Sorry for not spotting this
earlier.
But if this is the one whack left to get the thing to boot then I think
we should merge it.
> Moving forward we can try to come up with a suitable plan to implement
> DMA in the ACPI use-case - but again, this is feature adding work
> which should be carried out against -next, where as this patch needs
> to go in via the current -rcs ASAP.
>
Sounds good.
Regards,
Bjorn
> > > Fixes: 8bc529b25354 ("soc: qcom: geni: Add support for ACPI")
> > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > ---
> > > Since we are already at -rc7 this patch should be processed ASAP - thank you.
> > >
> > > drivers/soc/qcom/qcom-geni-se.c | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c
> > > index d5cf953b4337..7d622ea1274e 100644
> > > --- a/drivers/soc/qcom/qcom-geni-se.c
> > > +++ b/drivers/soc/qcom/qcom-geni-se.c
> > > @@ -630,6 +630,9 @@ int geni_se_tx_dma_prep(struct geni_se *se, void *buf, size_t len,
> > > struct geni_wrapper *wrapper = se->wrapper;
> > > u32 val;
> > >
> > > + if (!wrapper)
> > > + return -EINVAL;
> > > +
> > > *iova = dma_map_single(wrapper->dev, buf, len, DMA_TO_DEVICE);
> > > if (dma_mapping_error(wrapper->dev, *iova))
> > > return -EIO;
> > > @@ -663,6 +666,9 @@ int geni_se_rx_dma_prep(struct geni_se *se, void *buf, size_t len,
> > > struct geni_wrapper *wrapper = se->wrapper;
> > > u32 val;
> > >
> > > + if (!wrapper)
> > > + return -EINVAL;
> > > +
> > > *iova = dma_map_single(wrapper->dev, buf, len, DMA_FROM_DEVICE);
> > > if (dma_mapping_error(wrapper->dev, *iova))
> > > return -EIO;
>
> --
> Lee Jones [?????????]
> Linaro Services Technical Lead
> Linaro.org ??? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] SOC: TI soc updates for 5.4
From: Arnd Bergmann @ 2019-09-04 18:45 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Olof Johansson, arm-soc, linux-kernel@vger.kernel.org, Linux ARM,
Kevin Hilman
In-Reply-To: <3af4da24-2246-ff94-b83d-2b6ada4fc362@oracle.com>
On Wed, Sep 4, 2019 at 7:35 PM <santosh.shilimkar@oracle.com> wrote:
> On 9/4/19 6:13 AM, Arnd Bergmann wrote:
> > On Tue, Aug 27, 2019 at 5:12 AM Santosh Shilimkar
> >
> > Do you have any dependencies on -rc2 in your changes? If not,
> > could you please resubmit after rebasing? I can also just
> > cherry-pick those three commits if that's easier.
> >
> No dependencies. Can you please cherry pick them this time ?
> Will use rc1 for future pull request(s). Thanks !!
Ok, done.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: arm64/efistub boot error with CONFIG_GCC_PLUGIN_STACKLEAK
From: Ard Biesheuvel @ 2019-09-04 18:51 UTC (permalink / raw)
To: skodde; +Cc: Mark Rutland, linux-efi, linux-arm-kernel
In-Reply-To: <CAJrUJt-_B2DD3+538Ubq6s_3dyW3+EgFDY=RoLHBM8DUzJh_Fw@mail.gmail.com>
On Sat, 31 Aug 2019 at 10:20, skodde <skodde@gmail.com> wrote:
>
> On Thu, Aug 15, 2019 at 8:17 AM skodde <skodde@gmail.com> wrote:
> > On Thu, Aug 15, 2019 at 7:21 AM Ard Biesheuvel
> > <ard.biesheuvel@linaro.org> wrote:
> > > On Thu, 15 Aug 2019 at 14:03, Mark Rutland <mark.rutland@arm.com> wrote:
> > > > On Thu, Aug 15, 2019 at 05:56:27AM -0400, skodde wrote:
> > > > > The kernel boots fine with that option disabled, but strangely
> > > > > presents the same error when disabling only CONFIG_RANDOMIZE_BASE.
> > > >
> > > > That shouldn't be possible, given the IS_ENABLED(CONFIG_RANDOMIZE_BASE)
> > > > guard around the efi_get_random_bytes() call, so something sounds wrong.
> > > >
> > > > Maybe there's a problem with stale objects. If you're not doing so
> > > > already, could you try a clean build with CONFIG_RANDOMIZE_BASE
> > > > deselected?
> > > >
> > > Also, can you try booting with the nokaslr command line option added?
> >
> > You were right, I haven't tried with nokaslr, but it worked fine by
> > rebuilding the kernel after a distclean with CONFIG_RANDOMIZE_BASE
> > disabled and CONFIG_GCC_PLUGIN_STACKLEAK enabled. That's what I was
> > expecting the first time and this is the reason why I mentioned it.
> > I've been recompiling too many times, sorry about that.
> >
> > Anyhow, the main issue is the efi_get_random_bytes() fail with
> > CONFIG_GCC_PLUGIN_STACKLEAK enabled, and that's still valid.
>
> Now the configuration that was working on 5.8 fails on 5.11 (haven't
> tried 5.9 or 5.10):
>
What do these version numbers mean? v5.8 vs v5.11??
> - CONFIG_GCC_PLUGIN_STACKLEAK=n && CONFIG_RANDOMIZE_BASE=y (working on 5.8)
>
> Loading Linux 5.2.11-00015-g0cc3335a89ac ...
> Loading initial ramdisk ...
> EFI stub: Booting Linux Kernel...
> EFI stub: ERROR: efi_get_random_bytes() failed
> EFI stub: ERROR: Failed to relocate kernel
To be honest, this looks like a firmware issue. Its implementation of
EFI_RNG_PROTOCOL is throwing an error.
I guess we could choose to handle this error more gracefully, but the
result above is the expected behavior when EFI_RNG_PROTOCOL throws an
error.
> Error: Image at 00079560000 start failed: Load Error
> Unloading driver at 0x00079560000
>
>
> - CONFIG_GCC_PLUGIN_STACKLEAK=n && CONFIG_RANDOMIZE_BASE=y && nokaslr
>
> Loading Linux 5.2.11-00015-g0cc3335a89ac ...
> Loading initial ramdisk ...
> EFI stub: Booting Linux Kernel...
> EFI stub: KASLR disabled on kernel command line
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
> EFI stub: ERROR: Unable to construct new device tree.
> EFI stub: ERROR: Failed to update FDT and exit boot services
> Error: Image at 00079561000 start failed: Load Error
> Unloading driver at 0x00079561000
>
This looks unrelated. update_fdt() is faling, but we don't know why.
Could you add some debug prints at the various return sites to figure
out why it is failing?
>
> After getting back to the bootloader, loading a known working kernel
> fails (but it works fine after a reboot):
>
> Loading Linux 5.2.8-00016-ga0d5f389a536 ...
>
> Synchronous Exception at 0x00000000B652157C
> PC 0x0000B652157C
> PC 0x0000B65226B4
> PC 0x0000B6522EE0
> PC 0x0000B646BB10
> PC 0x0000B6468580
> PC 0x0000B6524600
> PC 0x0000B6420078
> PC 0x0000B6485CFC
> PC 0x0000B64849B4
> PC 0x0000B648586C
> PC 0x0000B64849B4
> PC 0x0000B6485E68
> PC 0x0000B6485EC0
> PC 0x0000B647C5C8
> PC 0x0000B647C2C8
> PC 0x0000B647C658
> PC 0x0000B647C2C8
> PC 0x0000B64784A8
> PC 0x0000B646F1FC
> PC 0x0000B6485CFC
> PC 0x0000B64849B4
> PC 0x0000B648586C
> PC 0x0000B64849B4
> PC 0x0000B6483C94
> PC 0x0000B64785A4
> PC 0x0000B6478794
> PC 0x0000B647880C
> PC 0x0000B652532C
> PC 0x00003F95B714 (0x00003F952000+0x00009714) [ 1] DxeCore.dll
> PC 0x0000B66CC440 (0x0000B66B9000+0x00013440) [ 2] UiApp.dll
> PC 0x0000B66CCD8C (0x0000B66B9000+0x00013D8C) [ 2] UiApp.dll
> PC 0x0000BF73D880 (0x0000BF729000+0x00014880) [ 3] SetupBrowser.dll
> PC 0x0000BF737BFC (0x0000BF729000+0x0000EBFC) [ 3] SetupBrowser.dll
> PC 0x0000B66C2700 (0x0000B66B9000+0x00009700) [ 4] UiApp.dll
> PC 0x00003F95B714 (0x00003F952000+0x00009714) [ 5] DxeCore.dll
> PC 0x0000BF71AEBC (0x0000BF711000+0x00009EBC) [ 6] BdsDxe.dll
> PC 0x0000BF721C8C (0x0000BF711000+0x00010C8C) [ 6] BdsDxe.dll
> PC 0x00003F95F470 (0x00003F952000+0x0000D470) [ 7] DxeCore.dll
> [ 1] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
> [ 2] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll
> [ 3] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe/DEBUG/SetupBrowser.dll
> [ 4] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll
> [ 5] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
> [ 6] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Universal/BdsDxe/BdsDxe/DEBUG/BdsDxe.dll
> [ 7] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
>
> X0 0xAFAFAFAFAFAFAFAF X1 0x0000000000008000 X2
> 0xFFFFFFFFFFEFFFFF X3 0x0000000000008000
> X4 0x00000000B6530000 X5 0x00000000B652CAE0 X6
> 0x000000007B4FE000 X7 0x00000000B6468258
> X8 0x0000000000001000 X9 0x0000000000000002 X10
> 0xFFFFFFFFFFFFFFFF X11 0x00000000B648A182
> X12 0x00000000B6489FAC X13 0x00000000B648A15C X14
> 0x0000000000000014 X15 0x00000000000000FF
> X16 0x0000000000001510 X17 0x00000000B5A3AA40 X18
> 0x000000000000005C X19 0x0000000000000401
> X20 0x0000000000000001 X21 0x000000002D3C2808 X22
> 0x00000000B652CAB0 X23 0x000000006DB08FA4
> X24 0x0000000000000000 X25 0x000000007A96E000 X26
> 0x000000000000000F X27 0x0000000000000FFF
> X28 0x00000000B646B000 FP 0x000000003F950BD0 LR 0x00000000B65226B4
>
> V0 0x0000000000000000 4049C00000000000 V1 0x0000000000000000
> 3FE0000000000000
> V2 0x0000000000000000 40D1AD0000000000 V3 0xFFBFDFDF6FEFFFDF
> FFFFFFFFFFEFFED5
> V4 0xF7FFF5EF41FBEFFF FFFFBFFFFFFFFFBC V5 0xFFFFFFFFAFB8FFFB
> FFBFFFFFD7FFDDF6
> V6 0x8BFFB1B7FFFB7FFE F7EFFFFFFFFFFFFF V7 0x7BFFFFBF55FFD7D7
> FFFFFFFFDB7FFFFF
> V8 0x0000000000000000 FFFFFFFFFFDDFF9F V9 0x0000000000000000
> FFFEFBF3976793FF
> V10 0x0000000000000000 FFFFFFFFFF7FFFDF V11 0x0000000000000000
> F77FFEFDFFFFF3FF
> V12 0x0000000000000000 FFFFFFFF3D554FFF V13 0x0000000000000000
> FFFFFFFFBDE0EABF
> V14 0x0000000000000000 FFFFFFFFE7EEFFAD V15 0x0000000000000000
> FFDFFFFF7DFEFFFB
> V16 0xEEA8FDDFFFFFDFFF FFFFFFFFB7FE56FF V17 0xBF3B955BDBFFFFFF
> FFF7F9EFFFFFBFFF
> V18 0x7FBFFDEF7FEBFFAF FFFFFFBF8FEFFFDF V19 0xFEBFFF7FFFFDFFFF
> FFFFFFFFF5FF7DF5
> V20 0xFFFFFFFFFFFFFFFF FFFFFFFFC7ED54FF V21 0xF7FFFEEEFFFFFF7F
> DAFEFFDFFFF7FBF5
> V22 0xFBE6FFFFFFFFFFFF FFFFFFFFFFFFFFFF V23 0xFFF5FFFFFF7FFFFF
> FFFFFFFFFFFFFF7F
> V24 0xFFFFFFFF7FFEFFFF FFFFEF7FFFFFFFFF V25 0xEB8EFFF7FFFFF7FE
> FFFFFFFFFD7FFFFD
> V26 0x3FFFFDFFFFFF5FFF FFCF7EFFFFFFFFFF V27 0xAFBFFEF9FFFFFFFF
> DDFBBFFBBDC4BE5F
> V28 0xFFFFFFDFFFF7EFDF 9DCD7CF3FFFFFFCF V29 0xDFFFFFFFFFFFFFFF
> BAF7D6FE7FFFDFFF
> V30 0xDFF7FFFFFFBFFFFD FFFFDFFFFFFFFFFF V31 0xCA4F7F47DAF7DBFB
> FFFFFFFFFFF76E77
>
> SP 0x000000003F950BD0 ELR 0x00000000B652157C SPSR 0x60000209 FPSR
> 0x00000010
> ESR 0x96000004 FAR 0xAFAFAFAFAFAFAFBF
>
> ESR : EC 0x25 IL 0x1 ISS 0x00000004
>
> Data abort: Translation fault, zeroth level
>
> Stack dump:
> 000003F950AD0: 000000003F950C70 000000003F96454C FFFFFFFFFF7FFFDF
> 0000000000000000
> 000003F950AF0: 000000003F950C90 000000003F96454C 000000003F950B60
> 00000000BF6F9EAC
> 000003F950B10: 00000000B91B4398 00000000BE909498 000000003F950B30
> 000000003F95F5D4
> 000003F950B30: 000000003F950B60 000000003F960758 000000003F97407C
> 000000003F95F5D4
> 000003F950B50: 000000003F950B80 D7AB00003F960910 000000003F950B80
> 000000003F9612DC
> 000003F950B70: 000000004201DB9E 000000003F974078 000000003F950BA0
> 000000003F961364
> 000003F950B90: 000000003F974070 0000000000000000 000000003F950BD0
> 000000003F96323C
> 000003F950BB0: 000000003F950BD0 000000003F960B14 000000003F976618
> 000000007B50DFFF
> > 000003F950BD0: 000000003F950C10 00000000B65226B4 00000000B5A3E8A0 00000000B5A3E8A0
> 000003F950BF0: 0000000000000000 00000000000CEC80 0000000000000000
> 0000000000001000
> 000003F950C10: 000000003F950C70 00000000B6522EE0 00000000000CEC80
> 00000000B5A3E8A0
> 000003F950C30: 0000000000000000 0000000000001000 000000007A96E000
> 0000000000000000
> 000003F950C50: 0000000000007FFF 000000000000000F 0000000000001000
> 00000000B646B000
> 000003F950C70: 000000003F950CD0 00000000B646BB10 0000000000000000
> 0000000000000BA1
> 000003F950C90: 0000000000000000 00000000B5A3E8A0 000000007A96E000
> 0000000000000FFF
> 000003F950CB0: 0000000000BA0A00 0000000000000001 0000000000001000
> 000000003F95F5D4
> ASSERT [ArmCpuDxe]
> /home/skodde/macchiatobin/edk/uefi-marvell/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(271):
> ((BOOLEAN)(0==1))
>
>
> - CONFIG_GCC_PLUGIN_STACKLEAK=y && CONFIG_RANDOMIZE_BASE=n
>
> Loading Linux 5.2.11-00015-g0cc3335a89ac ...
> Loading initial ramdisk ...
> EFI stub: Booting Linux Kernel...
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
> [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd081]
> [...]
>
> All good here.
>
> This time I did a distclean before each build.
>
>
> Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: next/master boot: 310 boots: 11 failed, 292 passed with 6 offline, 1 untried/unknown (next-20190904)
From: Mark Brown @ 2019-09-04 19:27 UTC (permalink / raw)
To: khilman, Matthias Brugger, linux-mediatek, linux-arm-kernel
Cc: kernel-build-reports
In-Reply-To: <5d700b15.1c69fb81.2abcd.479b@mx.google.com>
[-- Attachment #1.1: Type: text/plain, Size: 959 bytes --]
On Wed, Sep 04, 2019 at 12:05:57PM -0700, kernelci.org bot wrote:
Since 30th August -next fails to boot with no kernel output on
mt7622-rfb1:
> arm64:
> defconfig:
> gcc-8:
> mt7622-rfb1: 1 failed lab
>
> defconfig+CONFIG_RANDOMIZE_BASE=y:
> gcc-8:
> mt7622-rfb1: 1 failed lab
There's logging from ATF so it looks like we try to boot the kernel:
Starting kernel ...
[ATF][ 36.199793]save kernel info
[ATF][ 36.202824]Kernel_EL2
[ATF][ 36.205580]Kernel is 64Bit
[ATF][ 36.208768]pc=0x40080000, r0=0x5cf48000, r1=0x0
INFO: BL3-1: Preparing for EL3 exit to normal world, Kernel
INFO: BL3-1: Next image address = 0x40080000
INFO: BL3-1: Next image spsr = 0x3c9
[ATF][ 36.227037]el3_exit
but no output. More details including full logs at:
https://kernelci.org/boot/id/5d6fe70059b514164ef1224d/
https://kernelci.org/boot/id/5d6fe6e259b514164ef12243/
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 09/11] coresight: etm4x: docs: Update ABI doc for sysfs features added.
From: Mathieu Poirier @ 2019-09-04 19:47 UTC (permalink / raw)
To: Greg KH
Cc: Jon Corbet, Coresight ML, open list:DOCUMENTATION,
linux-arm-kernel, Suzuki K. Poulose, Mike Leach
In-Reply-To: <20190904161737.GA20662@kroah.com>
On Wed, 4 Sep 2019 at 10:17, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Sep 04, 2019 at 10:05:51AM -0600, Mathieu Poirier wrote:
> > On Tue, 3 Sep 2019 at 23:48, Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Tue, Sep 03, 2019 at 04:51:40PM -0600, Mathieu Poirier wrote:
> > > > On Tue, 3 Sep 2019 at 13:59, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Thu, Aug 29, 2019 at 10:33:19PM +0100, Mike Leach wrote:
> > > > > > Update document to include the new sysfs features added during this
> > > > > > patchset.
> > > > > >
> > > > > > Updated to reflect the new sysfs component nameing schema.
> > > > > >
> > > > > > Signed-off-by: Mike Leach <mike.leach@linaro.org>
> > > > > > ---
> > > > > > .../testing/sysfs-bus-coresight-devices-etm4x | 183 +++++++++++-------
> > > > > > 1 file changed, 115 insertions(+), 68 deletions(-)
> > > > > >
> > > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > > > > > index 36258bc1b473..112c50ae9986 100644
> > > > > > --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > > > > > +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > > > > > @@ -1,4 +1,4 @@
> > > > > > -What: /sys/bus/coresight/devices/<memory_map>.etm/enable_source
> > > > > > +What: /sys/bus/coresight/devices/etm<N>/enable_source
> > > > >
> > > > > You are renaming sysfs directories that have been around since:
> > > > >
> > > > > > Date: April 2015
> > > > >
> > > > > ???
> > > > >
> > > > > Really?
> > > > >
> > > > > That's brave.
> > > >
> > > >
> > > > When I worked on the coresight sysfs ABI a while back I specifically
> > > > added it at the "testing" level as I was well aware that things could
> > > > change in the future. According to the guidelines in the
> > > > documentation userspace can rely on it which was accurate since the
> > > > interface didn't change for 4 years. But the guidelines also mention
> > > > that changes can occur before the interfaces are move to stables, and
> > > > that programs are encouraged to manifest their interest by adding
> > > > their name to the "users" field.
> > > >
> > > > The interface was changed in 5.2 to support coresight from ACPI and
> > > > make things easier to understand for users. It is a lot more
> > > > intuitive to associate an ETM tracer with the CPU it belongs to by
> > > > referring to the CPU number than the memory mapped address. Given the
> > > > "testing" status of the interface and the absence of registered users
> > > > I decided to move forward with the change. If "testing" is too strict
> > > > for that I suggest to add an "experimental" category where it would be
> > > > more acceptable to change things as subsystems mature.
> > >
> > > "testing" is not really "testing" if you have userspace tools/programs
> > > assuming the location and contents of specific files in sysfs.
> > >
> > > You can change things in sysfs by creating new files, but to do
> > > wholesale renaming like you did here can be very dangerous as you might
> > > be breaking things.
> >
> > Yes, something I have definitely considered.
> >
> > > Usually new files are created, not existing ones
> > > moved.
> >
> > In this case it would have meant a new symbolic link for every
> > coresight device, so twice a many entries under
> > $(SYS)/bus/coresight/device/. That would have been a lot of clutter
> > and an increasing source of problems as the number of CPU and sinks
> > increases. To me, and given the permissive definition of "testing"
> > found in the documentation, a clean break was a better option.
>
> Well, "testing" doesn't really matter in the end, if a tool/user relies
> on it, we have to keep it working properly.
>
> > > What tools use these today? What is going to break?
> >
> > Other than local shell scripts I am not aware of any tools using these
> > today. I am certainly open to discuss a better alternative but right
> > now, I just don't see one.
>
> Be aware that you might have to change this back if there is any
> objections.
>
We have an agreement.
Regards,
Mathieu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] soc: qcom: geni: Provide parameter error checking
From: Lee Jones @ 2019-09-04 20:01 UTC (permalink / raw)
To: Bjorn Andersson; +Cc: linux-arm-msm, agross, linux-kernel, linux-arm-kernel
In-Reply-To: <20190904182732.GE574@tuxbook-pro>
On Wed, 04 Sep 2019, Bjorn Andersson wrote:
> On Wed 04 Sep 01:45 PDT 2019, Lee Jones wrote:
>
> > On Tue, 03 Sep 2019, Bjorn Andersson wrote:
> >
> > > On Tue 03 Sep 06:50 PDT 2019, Lee Jones wrote:
> > >
> > > > When booting with ACPI, the Geni Serial Engine is not set as the I2C/SPI
> > > > parent and thus, the wrapper (parent device) is unassigned. This causes
> > > > the kernel to crash with a null dereference error.
> > > >
> > >
> > > Now I see what you did in 8bc529b25354; i.e. stubbed all the other calls
> > > between the SE and wrapper.
> > >
> > > Do you think it would be possible to resolve the _DEP link to QGP[01]
> > > somehow?
> >
> > I looked at QGP{0,1}, but did not see it represented in the current
> > Device Tree implementation and thus failed to identify it. Do you
> > know what it is? Does it have a driver in Linux already?
>
> QGP0 is the same hardware block as &qupv3_id_0, but apparently both are
> only representing a smaller part - and different ones.
>
> But conceptually both represents the wrapper...
... which doesn't actually do anything in the Linux implementation.
It only has one register. :)
> > > For the clocks workarounds this could be resolved by us
> > > representing that relationship using device_link and just rely on
> > > pm_runtime to propagate the clock state.
> >
> > That is not allowed when booting ACPI. The Clock/Regulator frameworks
> > are not to be used in this use-case, hence why all of the calls to
> > these frameworks are "stubbed out". If we wanted to properly
> > implement power management, we would have to create a driver/subsystem
> > similar to the "Windows-compatible System Power Management Controller"
> > (PEP). Without documentation for the PEP, this would be an impossible
> > task. A request for the aforementioned documentation has been put in
> > to Lenovo/Qualcomm. Hopefully something appears soon.
> >
>
> I see, so the PEP states needs to be parsed and associated with each
> device and we would use pm_runtime to toggle between the states and
> device_links to ensure that _DEP nodes are powered in appropriate order.
>
> That seems reasonable and straight forward and the reliance on
> pm_runtime will make the DT case cleaner as well.
Essentially yes. The issue is translating the ACPI tables into
actions to be taken by the Linux Power Management APIs. Again, we've
requested documentation. Now, we wait ...
> > > For the DMA operation, iiuc it's the wrapper that implements the DMA
> > > engine involved, but I'm guessing the main reason for mapping buffers on
> > > the wrapper is so that it ends up being associated with the iommu
> > > context of the wrapper.
> >
> > Judging by the code alone, the wrapper doesn't sound like it does much
> > at all. It seems to only have a single (version) register (at least
> > that is the only register that's used). The only registers it
> > reads/writes are those of the calling device, whether that be I2C, SPI
> > or UART.
> >
> > Device Tree represents the wrapper's relationship with the I2C (and
> > SPI/UART) Serial Engine (SE) devices as parent-child ones, with the
> > wrapper being the parent and SE the child. Whether this is a true
> > representation of the hardware or just a tactic used for convenience
> > is not clear, but the same representation does not exist in ACPI.
> >
> > In the current Linux implementation, the buffer belongs to the SE
> > (obtained by the child (e.g. I2C) SE by fetching the parent's
> > (wrapper's) device data using the standard platform helpers) but the
> > register-set used to control the DMA transactions belong to the SE
> > devices.
> >
>
> Yeah, I saw this as well. If all the SEs where the wrappers iommu domain
> things should work fine by mapping it on the se->dev, regardless of the
> device's being linked together.
This is my assumption too.
> The remaining relationship to the wrapper would then be reduced to the
> read of the version to check for 1.0 or 1.1 hardware in the SPI driver,
> which can be replaced by the assumption that we're on 1.1.
Also correct. You would be left with a huge duplication of code
across each of the SEs however.
> > > Are the SMMU contexts at all represented in the ACPI world and if so do
> > > you know how the wrapper vs SEs are bound to contexts? Can we map on
> > > se->dev when wrapper is NULL (or perhaps always?)?
> >
> > Yes, the SMMU devices are represented in ACPI (MMU0) and (MMU1). They
> > share the same register addresses as the SMMU devices located in
> > arch/arm64/boot/dts/qcom/sdm845.dtsi.
>
> Right but this only describes the IOMMU devices, I don't see any
> information about how individual client devices relates to the various
> IOMMU contexts.
I see some _DEPs which detail the MMU{0,1}, but that's about it.
> > With this simple parameter checking patch, the SE falls back to using
> > FIFO mode to transmit data and continues to work flawlessly. IMHO
> > this should be applied in the first instance, as it fixes a real (null
> > dereference) bug which currently resides in the Mainline kernel.
> >
>
> Per the current driver design the wrapper device is the parent of the
> SE, I should have seen that 8bc529b25354 was the beginning of a game of
> whac-a-mole circumventing this design. Sorry for not spotting this
> earlier.
Right, but that doesn't mean that the current driver design is
correct. ACPI, which is in theory a description of the hardware
doesn't seem to think so. It looks more like we do this in Linux as a
convenience function to link the devices. Instead this 'parent' seems
to be represented as a very small register space at the end of the SE
banks.
> But if this is the one whack left to get the thing to boot then I think
> we should merge it.
Amazing, thank you!
Do you know how we go about getting this merged? We only potentially
have 0.5 weeks (1.5 weeks if there is an -rc8 [doubtful]), so we need
to move fast. Would you be prepared to send it to Linus for -fixes?
I'd do it myself, but this is a little out of my remit.
Nothing heard from Andy for a very long time.
> > Moving forward we can try to come up with a suitable plan to implement
> > DMA in the ACPI use-case - but again, this is feature adding work
> > which should be carried out against -next, where as this patch needs
> > to go in via the current -rcs ASAP.
>
> Sounds good.
Great.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers
From: Gerald Schaefer @ 2019-09-04 20:16 UTC (permalink / raw)
To: Anshuman Khandual
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Tetsuo Handa, Heiko Carstens, Michal Hocko, linux-mm, Dave Hansen,
Paul Mackerras, sparclinux, Thomas Gleixner, linux-s390,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Jason Gunthorpe, linux-arm-kernel, linux-snps-arc,
Kees Cook, Masahiro Yamada, Mark Brown, Dan Williams,
Vlastimil Babka, Sri Krishna chowdary, Ard Biesheuvel,
Greg Kroah-Hartman, linux-mips, Ralf Baechle, linux-kernel,
Paul Burton, Mike Rapoport, Vineet Gupta, Martin Schwidefsky,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <1567497706-8649-2-git-send-email-anshuman.khandual@arm.com>
On Tue, 3 Sep 2019 13:31:46 +0530
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
> This adds a test module which will validate architecture page table helpers
> and accessors regarding compliance with generic MM semantics expectations.
> This will help various architectures in validating changes to the existing
> page table helpers or addition of new ones.
>
> Test page table and memory pages creating it's entries at various level are
> all allocated from system memory with required alignments. If memory pages
> with required size and alignment could not be allocated, then all depending
> individual tests are skipped.
This looks very useful, thanks. Of course, s390 is quite special and does
not work nicely with this patch (yet), mostly because of our dynamic page
table levels/folding. Still need to figure out what can be fixed in the arch
code and what would need to be changed in the test module. See below for some
generic comments/questions.
At least one real bug in the s390 code was already revealed by this, which
is very nice. In pmd/pud_bad(), we also check large pmds/puds for sanity,
instead of reporting them as bad, which is apparently not how it is expected.
[...]
> +/*
> + * Basic operations
> + *
> + * mkold(entry) = An old and not a young entry
> + * mkyoung(entry) = A young and not an old entry
> + * mkdirty(entry) = A dirty and not a clean entry
> + * mkclean(entry) = A clean and not a dirty entry
> + * mkwrite(entry) = A write and not a write protected entry
> + * wrprotect(entry) = A write protected and not a write entry
> + * pxx_bad(entry) = A mapped and non-table entry
> + * pxx_same(entry1, entry2) = Both entries hold the exact same value
> + */
> +#define VADDR_TEST (PGDIR_SIZE + PUD_SIZE + PMD_SIZE + PAGE_SIZE)
Why is P4D_SIZE missing in the VADDR_TEST calculation?
[...]
> +
> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
> +static void pud_clear_tests(pud_t *pudp)
> +{
> + memset(pudp, RANDOM_NZVALUE, sizeof(pud_t));
> + pud_clear(pudp);
> + WARN_ON(!pud_none(READ_ONCE(*pudp)));
> +}
For pgd/p4d/pud_clear(), we only clear if the page table level is present
and not folded. The memset() here overwrites the table type bits, so
pud_clear() will not clear anything on s390 and the pud_none() check will
fail.
Would it be possible to OR a (larger) random value into the table, so that
the lower 12 bits would be preserved?
> +
> +static void pud_populate_tests(struct mm_struct *mm, pud_t *pudp, pmd_t *pmdp)
> +{
> + /*
> + * This entry points to next level page table page.
> + * Hence this must not qualify as pud_bad().
> + */
> + pmd_clear(pmdp);
> + pud_clear(pudp);
> + pud_populate(mm, pudp, pmdp);
> + WARN_ON(pud_bad(READ_ONCE(*pudp)));
> +}
This will populate the pud with a pmd pointer that does not point to the
beginning of the pmd table, but to the second entry (because of how
VADDR_TEST is constructed). This will result in failing pud_bad() check
on s390. Not sure why/how it works on other archs, but would it be possible
to align pmdp down to the beginning of the pmd table (and similar for the
other pxd_populate_tests)?
[...]
> +
> + p4d_free(mm, saved_p4dp);
> + pud_free(mm, saved_pudp);
> + pmd_free(mm, saved_pmdp);
> + pte_free(mm, (pgtable_t) virt_to_page(saved_ptep));
pgtable_t is arch-specific, and on s390 it is not a struct page pointer,
but a pte pointer. So this will go wrong, also on all other archs (if any)
where pgtable_t is not struct page.
Would it be possible to use pte_free_kernel() instead, and just pass
saved_ptep directly?
Regards,
Gerald
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 2/3] Broadcom defconfig-arm64 changes for 5.4
From: Arnd Bergmann @ 2019-09-04 20:19 UTC (permalink / raw)
To: Stefan Wahren
Cc: Stefan Wahren, Florian Fainelli, Kevin Hilman, arm-soc,
bcm-kernel-feedback-list, Linux ARM, Olof Johansson,
Nicolas Saenz Julienne
In-Reply-To: <4fd4b848-669d-00c5-144b-deab7a62a263@gmx.net>
On Wed, Sep 4, 2019 at 7:06 PM Stefan Wahren <wahrenst@gmx.net> wrote:
> Am 04.09.19 um 15:02 schrieb Arnd Bergmann:
> > On Mon, Aug 19, 2019 at 9:06 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
> >>
> >> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
> >>
> >> are available in the Git repository at:
> >>
> >> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-5.4/defconfig-arm64
> >>
> >> for you to fetch changes up to d6cc9ddd23f8b113797152896462b27e2b213ece:
> >>
> >> Merge tag 'tags/bcm2835-defconfig-64-next-2019-08-15' into defconfig-arm64/next (2019-08-15 11:38:29 -0700)
> >>
> >> ----------------------------------------------------------------
> >> This pull request contains Broadcom ARM64-based SoCs defconfig updates
> >> for 5.4, please pull the following:
> >>
> >> - Nicolas enables the Raspberry Pi CPUFREQ driver in the ARM64 defconfig file
> > Pulled into arm/defconfig.
> >
> > The way we work at the moment, there is no real need to split changes
> > to the arm32 and arm64 defconfig files into separate pull requests or even
> > separate patches.
>
> this is new to me. My understanding was to separate all changes between
> arm32 and arm64 changes.
Right, that was the policy for a long time, but it has gradually gotten
more relaxed.
> So this isn't necessary for the DT arm/arm64 changes, too?
I would still like to see large pull requests get split up into logical
chunks, and the 32/64 split tends to be a natural boundary for
many things, but I think there are cases where it makes more
sense to combine. For instance, the raspberry pi changes tend
to go together for 32/64, so a single pull request is best here.
OTOH, if there are many changes for one Broadcom platform, in
addition to a couple of patches each for the other platforms,
a good split might be
a) bcm283{5678}, both 32-bit and 64-bit combined
b) random other 32-bit DT changes
c) random other 64-bit DT changes
As a rule of thumb, the best pull requests are those
that clearly tell what goes on in the branch using a
tag/commit description in a couple of paragraphs without
enumerating unrelated items. (same as a changeset
commit message actually).
The branches we currently have are
arm/fixes
arm/defconfig
arm/drivers
arm/dt
arm/soc
arm/late
Each of them contain 32-bit and 64-bit changes across all platforms.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v12 00/12] namei: openat2(2) path resolution restrictions
From: Aleksa Sarai @ 2019-09-04 20:19 UTC (permalink / raw)
To: Al Viro, Jeff Layton, J. Bruce Fields, Arnd Bergmann,
David Howells, Shuah Khan, Shuah Khan, Ingo Molnar,
Peter Zijlstra, Christian Brauner
Cc: linux-ia64, linux-sh, Alexander Shishkin, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, linux-kselftest, sparclinux,
Jiri Olsa, linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai,
linux-mips, linux-xtensa, Kees Cook, Jann Horn, linuxppc-dev,
Aleksa Sarai, Andy Lutomirski, Namhyung Kim, David Drysdale,
linux-arm-kernel, linux-parisc, linux-m68k, linux-api, Chanho Min,
Oleg Nesterov, Eric Biederman, linux-alpha, linux-fsdevel,
Andrew Morton, Linus Torvalds, containers
This patchset is being developed here:
<https://github.com/cyphar/linux/tree/resolveat/master>
Patch changelog:
v12:
* Remove @how->reserved field from openat2(2), and instead use the
(struct, size) design for syscall extensions.
* Implement copy_struct_{to,from}_user() to unify (struct, size)
syscall extension designs (as well as make them slightly more
efficient by using memchr_inv() as well as using buffers and
avoiding repeated access_ok() checks for trailing byte operations).
* Port sched_setattr(), perf_event_attr(), and clone3() to use the
new helpers.
v11: <https://lore.kernel.org/lkml/20190820033406.29796-1-cyphar@cyphar.com/>
<https://lore.kernel.org/lkml/20190728010207.9781-1-cyphar@cyphar.com/>
v10: <https://lore.kernel.org/lkml/20190719164225.27083-1-cyphar@cyphar.com/>
v09: <https://lore.kernel.org/lkml/20190706145737.5299-1-cyphar@cyphar.com/>
v08: <https://lore.kernel.org/lkml/20190520133305.11925-1-cyphar@cyphar.com/>
v07: <https://lore.kernel.org/lkml/20190507164317.13562-1-cyphar@cyphar.com/>
v06: <https://lore.kernel.org/lkml/20190506165439.9155-1-cyphar@cyphar.com/>
v05: <https://lore.kernel.org/lkml/20190320143717.2523-1-cyphar@cyphar.com/>
v04: <https://lore.kernel.org/lkml/20181112142654.341-1-cyphar@cyphar.com/>
v03: <https://lore.kernel.org/lkml/20181009070230.12884-1-cyphar@cyphar.com/>
v02: <https://lore.kernel.org/lkml/20181009065300.11053-1-cyphar@cyphar.com/>
v01: <https://lore.kernel.org/lkml/20180929103453.12025-1-cyphar@cyphar.com/>
The need for some sort of control over VFS's path resolution (to avoid
malicious paths resulting in inadvertent breakouts) has been a very
long-standing desire of many userspace applications. This patchset is a
revival of Al Viro's old AT_NO_JUMPS[1,2] patchset (which was a variant
of David Drysdale's O_BENEATH patchset[3] which was a spin-off of the
Capsicum project[4]) with a few additions and changes made based on the
previous discussion within [5] as well as others I felt were useful.
In line with the conclusions of the original discussion of AT_NO_JUMPS,
the flag has been split up into separate flags. However, instead of
being an openat(2) flag it is provided through a new syscall openat2(2)
which provides several other improvements to the openat(2) interface (see the
patch description for more details). The following new LOOKUP_* flags are
added:
* LOOKUP_NO_XDEV blocks all mountpoint crossings (upwards, downwards,
or through absolute links). Absolute pathnames alone in openat(2) do
not trigger this.
* LOOKUP_NO_MAGICLINKS blocks resolution through /proc/$pid/fd-style
links. This is done by blocking the usage of nd_jump_link() during
resolution in a filesystem. The term "magic-links" is used to match
with the only reference to these links in Documentation/, but I'm
happy to change the name.
It should be noted that this is different to the scope of
~LOOKUP_FOLLOW in that it applies to all path components. However,
you can do openat2(NO_FOLLOW|NO_MAGICLINKS) on a magic-link and it
will *not* fail (assuming that no parent component was a
magic-link), and you will have an fd for the magic-link.
* LOOKUP_BENEATH disallows escapes to outside the starting dirfd's
tree, using techniques such as ".." or absolute links. Absolute
paths in openat(2) are also disallowed. Conceptually this flag is to
ensure you "stay below" a certain point in the filesystem tree --
but this requires some additional to protect against various races
that would allow escape using "..".
Currently LOOKUP_BENEATH implies LOOKUP_NO_MAGICLINKS, because it
can trivially beam you around the filesystem (breaking the
protection). In future, there might be similar safety checks done as
in LOOKUP_IN_ROOT, but that requires more discussion.
In addition, two new flags are added that expand on the above ideas:
* LOOKUP_NO_SYMLINKS does what it says on the tin. No symlink
resolution is allowed at all, including magic-links. Just as with
LOOKUP_NO_MAGICLINKS this can still be used with NOFOLLOW to open an
fd for the symlink as long as no parent path had a symlink
component.
* LOOKUP_IN_ROOT is an extension of LOOKUP_BENEATH that, rather than
blocking attempts to move past the root, forces all such movements
to be scoped to the starting point. This provides chroot(2)-like
protection but without the cost of a chroot(2) for each filesystem
operation, as well as being safe against race attacks that chroot(2)
is not.
If a race is detected (as with LOOKUP_BENEATH) then an error is
generated, and similar to LOOKUP_BENEATH it is not permitted to cross
magic-links with LOOKUP_IN_ROOT.
The primary need for this is from container runtimes, which
currently need to do symlink scoping in userspace[6] when opening
paths in a potentially malicious container. There is a long list of
CVEs that could have bene mitigated by having RESOLVE_THIS_ROOT
(such as CVE-2017-1002101, CVE-2017-1002102, CVE-2018-15664, and
CVE-2019-5736, just to name a few).
And further, several semantics of file descriptor "re-opening" are now
changed to prevent attacks like CVE-2019-5736 by restricting how
magic-links can be resolved (based on their mode). This required some
other changes to the semantics of the modes of O_PATH file descriptor's
associated /proc/self/fd magic-links. openat2(2) has the ability to
further restrict re-opening of its own O_PATH fds, so that users can
make even better use of this feature.
Finally, O_EMPTYPATH was added so that users can do /proc/self/fd-style
re-opening without depending on procfs. The new restricted semantics for
magic-links are applied here too.
In order to make all of the above more usable, I'm working on
libpathrs[7] which is a C-friendly library for safe path resolution. It
features a userspace-emulated backend if the kernel doesn't support
openat2(2). Hopefully we can get userspace to switch to using it, and
thus get openat2(2) support for free once it's ready.
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: David Howells <dhowells@redhat.com>
Cc: Jann Horn <jannh@google.com>
Cc: Christian Brauner <christian@brauner.io>
Cc: David Drysdale <drysdale@google.com>
Cc: Tycho Andersen <tycho@tycho.ws>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
[1]: https://lwn.net/Articles/721443/
[2]: https://lore.kernel.org/patchwork/patch/784221/
[3]: https://lwn.net/Articles/619151/
[4]: https://lwn.net/Articles/603929/
[5]: https://lwn.net/Articles/723057/
[6]: https://github.com/cyphar/filepath-securejoin
[7]: https://github.com/openSUSE/libpathrs
Aleksa Sarai (12):
lib: introduce copy_struct_{to,from}_user helpers
clone3: switch to copy_struct_from_user()
sched_setattr: switch to copy_struct_{to,from}_user()
perf_event_open: switch to copy_struct_from_user()
namei: obey trailing magic-link DAC permissions
procfs: switch magic-link modes to be more sane
open: O_EMPTYPATH: procfs-less file descriptor re-opening
namei: O_BENEATH-style path resolution flags
namei: LOOKUP_IN_ROOT: chroot-like path resolution
namei: aggressively check for nd->root escape on ".." resolution
open: openat2(2) syscall
selftests: add openat2(2) selftests
Documentation/filesystems/path-lookup.rst | 12 +-
arch/alpha/include/uapi/asm/fcntl.h | 1 +
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 +
arch/ia64/kernel/syscalls/syscall.tbl | 1 +
arch/m68k/kernel/syscalls/syscall.tbl | 1 +
arch/microblaze/kernel/syscalls/syscall.tbl | 1 +
arch/mips/kernel/syscalls/syscall_n32.tbl | 1 +
arch/mips/kernel/syscalls/syscall_n64.tbl | 1 +
arch/mips/kernel/syscalls/syscall_o32.tbl | 1 +
arch/parisc/include/uapi/asm/fcntl.h | 39 +-
arch/parisc/kernel/syscalls/syscall.tbl | 1 +
arch/powerpc/kernel/syscalls/syscall.tbl | 1 +
arch/s390/kernel/syscalls/syscall.tbl | 1 +
arch/sh/kernel/syscalls/syscall.tbl | 1 +
arch/sparc/include/uapi/asm/fcntl.h | 1 +
arch/sparc/kernel/syscalls/syscall.tbl | 1 +
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
arch/xtensa/kernel/syscalls/syscall.tbl | 1 +
fs/fcntl.c | 2 +-
fs/internal.h | 1 +
fs/namei.c | 270 ++++++++++--
fs/open.c | 100 ++++-
fs/proc/base.c | 20 +-
fs/proc/fd.c | 23 +-
fs/proc/namespaces.c | 2 +-
include/linux/fcntl.h | 21 +-
include/linux/fs.h | 8 +-
include/linux/namei.h | 9 +
include/linux/syscalls.h | 14 +-
include/linux/uaccess.h | 5 +
include/uapi/asm-generic/fcntl.h | 4 +
include/uapi/asm-generic/unistd.h | 5 +-
include/uapi/linux/fcntl.h | 42 ++
include/uapi/linux/sched.h | 2 +
kernel/events/core.c | 45 +-
kernel/fork.c | 34 +-
kernel/sched/core.c | 85 +---
lib/Makefile | 2 +-
lib/struct_user.c | 182 ++++++++
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/memfd/memfd_test.c | 7 +-
tools/testing/selftests/openat2/.gitignore | 1 +
tools/testing/selftests/openat2/Makefile | 8 +
tools/testing/selftests/openat2/helpers.c | 167 ++++++++
tools/testing/selftests/openat2/helpers.h | 118 +++++
.../testing/selftests/openat2/linkmode_test.c | 333 +++++++++++++++
.../testing/selftests/openat2/openat2_test.c | 106 +++++
.../selftests/openat2/rename_attack_test.c | 127 ++++++
.../testing/selftests/openat2/resolve_test.c | 402 ++++++++++++++++++
53 files changed, 1971 insertions(+), 248 deletions(-)
create mode 100644 lib/struct_user.c
create mode 100644 tools/testing/selftests/openat2/.gitignore
create mode 100644 tools/testing/selftests/openat2/Makefile
create mode 100644 tools/testing/selftests/openat2/helpers.c
create mode 100644 tools/testing/selftests/openat2/helpers.h
create mode 100644 tools/testing/selftests/openat2/linkmode_test.c
create mode 100644 tools/testing/selftests/openat2/openat2_test.c
create mode 100644 tools/testing/selftests/openat2/rename_attack_test.c
create mode 100644 tools/testing/selftests/openat2/resolve_test.c
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v12 01/12] lib: introduce copy_struct_{to,from}_user helpers
From: Aleksa Sarai @ 2019-09-04 20:19 UTC (permalink / raw)
To: Al Viro, Jeff Layton, J. Bruce Fields, Arnd Bergmann,
David Howells, Shuah Khan, Shuah Khan, Ingo Molnar,
Peter Zijlstra, Christian Brauner
Cc: linux-ia64, linux-sh, Alexander Shishkin, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, linux-kselftest, sparclinux,
Jiri Olsa, linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai,
linux-mips, linux-xtensa, Kees Cook, Jann Horn, linuxppc-dev,
Aleksa Sarai, Andy Lutomirski, Namhyung Kim, David Drysdale,
linux-arm-kernel, linux-parisc, linux-m68k, linux-api, Chanho Min,
Oleg Nesterov, Eric Biederman, linux-alpha, linux-fsdevel,
Andrew Morton, Linus Torvalds, containers
In-Reply-To: <20190904201933.10736-1-cyphar@cyphar.com>
A common pattern for syscall extensions is increasing the size of a
struct passed from userspace, such that the zero-value of the new fields
result in the old kernel behaviour (allowing for a mix of userspace and
kernel vintages to operate on one another in most cases). This is done
in both directions -- hence two helpers -- though it's more common to
have to copy user space structs into kernel space.
Previously there was no common lib/ function that implemented
the necessary extension-checking semantics (and different syscalls
implemented them slightly differently or incompletely[1]). A future
patch replaces all of the common uses of this pattern to use the new
copy_struct_{to,from}_user() helpers.
[1]: For instance {sched_setattr,perf_event_open,clone3}(2) all do do
similar checks to copy_struct_from_user() while rt_sigprocmask(2)
always rejects differently-sized struct arguments.
Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
---
include/linux/uaccess.h | 5 ++
lib/Makefile | 2 +-
lib/struct_user.c | 182 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 188 insertions(+), 1 deletion(-)
create mode 100644 lib/struct_user.c
diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index 34a038563d97..0ad9544a1aee 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -230,6 +230,11 @@ static inline unsigned long __copy_from_user_inatomic_nocache(void *to,
#endif /* ARCH_HAS_NOCACHE_UACCESS */
+extern int copy_struct_to_user(void __user *dst, size_t usize,
+ const void *src, size_t ksize);
+extern int copy_struct_from_user(void *dst, size_t ksize,
+ const void __user *src, size_t usize);
+
/*
* probe_kernel_read(): safely attempt to read from a location
* @dst: pointer to the buffer that shall take the data
diff --git a/lib/Makefile b/lib/Makefile
index 29c02a924973..d86c71feaf0a 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -28,7 +28,7 @@ endif
CFLAGS_string.o := $(call cc-option, -fno-stack-protector)
endif
-lib-y := ctype.o string.o vsprintf.o cmdline.o \
+lib-y := ctype.o string.o struct_user.o vsprintf.o cmdline.o \
rbtree.o radix-tree.o timerqueue.o xarray.o \
idr.o extable.o \
sha1.o chacha.o irq_regs.o argv_split.o \
diff --git a/lib/struct_user.c b/lib/struct_user.c
new file mode 100644
index 000000000000..7301ab1bbe98
--- /dev/null
+++ b/lib/struct_user.c
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2019 SUSE LLC
+ * Copyright (C) 2019 Aleksa Sarai <cyphar@cyphar.com>
+ */
+
+#include <linux/types.h>
+#include <linux/export.h>
+#include <linux/uaccess.h>
+#include <linux/kernel.h>
+#include <linux/string.h>
+
+#define BUFFER_SIZE 64
+
+/*
+ * "memset(p, 0, size)" but for user space buffers. Caller must have already
+ * checked access_ok(p, size).
+ */
+static int __memzero_user(void __user *p, size_t s)
+{
+ const char zeros[BUFFER_SIZE] = {};
+ while (s > 0) {
+ size_t n = min(s, sizeof(zeros));
+
+ if (__copy_to_user(p, zeros, n))
+ return -EFAULT;
+
+ p += n;
+ s -= n;
+ }
+ return 0;
+}
+
+/**
+ * copy_struct_to_user: copy a struct to user space
+ * @dst: Destination address, in user space.
+ * @usize: Size of @dst struct.
+ * @src: Source address, in kernel space.
+ * @ksize: Size of @src struct.
+ *
+ * Copies a struct from kernel space to user space, in a way that guarantees
+ * backwards-compatibility for struct syscall arguments (as long as future
+ * struct extensions are made such that all new fields are *appended* to the
+ * old struct, and zeroed-out new fields have the same meaning as the old
+ * struct).
+ *
+ * @ksize is just sizeof(*dst), and @usize should've been passed by user space.
+ * The recommended usage is something like the following:
+ *
+ * SYSCALL_DEFINE2(foobar, struct foo __user *, uarg, size_t, usize)
+ * {
+ * int err;
+ * struct foo karg = {};
+ *
+ * // do something with karg
+ *
+ * err = copy_struct_to_user(uarg, usize, &karg, sizeof(karg));
+ * if (err)
+ * return err;
+ *
+ * // ...
+ * }
+ *
+ * There are three cases to consider:
+ * * If @usize == @ksize, then it's copied verbatim.
+ * * If @usize < @ksize, then kernel space is "returning" a newer struct to an
+ * older user space. In order to avoid user space getting incomplete
+ * information (new fields might be important), all trailing bytes in @src
+ * (@ksize - @usize) must be zerored, otherwise -EFBIG is returned.
+ * * If @usize > @ksize, then the kernel is "returning" an older struct to a
+ * newer user space. The trailing bytes in @dst (@usize - @ksize) will be
+ * zero-filled.
+ *
+ * Returns (in all cases, some data may have been copied):
+ * * -EFBIG: (@usize < @ksize) and there are non-zero trailing bytes in @src.
+ * * -EFAULT: access to user space failed.
+ */
+int copy_struct_to_user(void __user *dst, size_t usize,
+ const void *src, size_t ksize)
+{
+ size_t size = min(ksize, usize);
+ size_t rest = abs(ksize - usize);
+
+ if (unlikely(usize > PAGE_SIZE))
+ return -EFAULT;
+ if (unlikely(!access_ok(dst, usize)))
+ return -EFAULT;
+
+ /* Deal with trailing bytes. */
+ if (usize < ksize) {
+ if (memchr_inv(src + size, 0, rest))
+ return -EFBIG;
+ } else if (usize > ksize) {
+ if (__memzero_user(dst + size, rest))
+ return -EFAULT;
+ }
+ /* Copy the interoperable parts of the struct. */
+ if (__copy_to_user(dst, src, size))
+ return -EFAULT;
+ return 0;
+}
+EXPORT_SYMBOL(copy_struct_to_user);
+
+/**
+ * copy_struct_from_user: copy a struct from user space
+ * @dst: Destination address, in kernel space. This buffer must be @ksize
+ * bytes long.
+ * @ksize: Size of @dst struct.
+ * @src: Source address, in user space.
+ * @usize: (Alleged) size of @src struct.
+ *
+ * Copies a struct from user space to kernel space, in a way that guarantees
+ * backwards-compatibility for struct syscall arguments (as long as future
+ * struct extensions are made such that all new fields are *appended* to the
+ * old struct, and zeroed-out new fields have the same meaning as the old
+ * struct).
+ *
+ * @ksize is just sizeof(*dst), and @usize should've been passed by user space.
+ * The recommended usage is something like the following:
+ *
+ * SYSCALL_DEFINE2(foobar, const struct foo __user *, uarg, size_t, usize)
+ * {
+ * int err;
+ * struct foo karg = {};
+ *
+ * err = copy_struct_from_user(&karg, sizeof(karg), uarg, size);
+ * if (err)
+ * return err;
+ *
+ * // ...
+ * }
+ *
+ * There are three cases to consider:
+ * * If @usize == @ksize, then it's copied verbatim.
+ * * If @usize < @ksize, then the user space has passed an old struct to a
+ * newer kernel. The rest of the trailing bytes in @dst (@ksize - @usize)
+ * are to be zero-filled.
+ * * If @usize > @ksize, then the user space has passed a new struct to an
+ * older kernel. The trailing bytes unknown to the kernel (@usize - @ksize)
+ * are checked to ensure they are zeroed, otherwise -E2BIG is returned.
+ *
+ * Returns (in all cases, some data may have been copied):
+ * * -E2BIG: (@usize > @ksize) and there are non-zero trailing bytes in @src.
+ * * -E2BIG: @usize is "too big" (at time of writing, >PAGE_SIZE).
+ * * -EFAULT: access to user space failed.
+ */
+int copy_struct_from_user(void *dst, size_t ksize,
+ const void __user *src, size_t usize)
+{
+ size_t size = min(ksize, usize);
+ size_t rest = abs(ksize - usize);
+
+ if (unlikely(usize > PAGE_SIZE))
+ return -EFAULT;
+ if (unlikely(!access_ok(src, usize)))
+ return -EFAULT;
+
+ /* Deal with trailing bytes. */
+ if (usize < ksize)
+ memset(dst + size, 0, rest);
+ else if (usize > ksize) {
+ const void __user *addr = src + size;
+ char buffer[BUFFER_SIZE] = {};
+
+ while (rest > 0) {
+ size_t bufsize = min(rest, sizeof(buffer));
+
+ if (__copy_from_user(buffer, addr, bufsize))
+ return -EFAULT;
+ if (memchr_inv(buffer, 0, bufsize))
+ return -E2BIG;
+
+ addr += bufsize;
+ rest -= bufsize;
+ }
+ }
+ /* Copy the interoperable parts of the struct. */
+ if (__copy_from_user(dst, src, size))
+ return -EFAULT;
+ return 0;
+}
+EXPORT_SYMBOL(copy_struct_from_user);
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v12 02/12] clone3: switch to copy_struct_from_user()
From: Aleksa Sarai @ 2019-09-04 20:19 UTC (permalink / raw)
To: Al Viro, Jeff Layton, J. Bruce Fields, Arnd Bergmann,
David Howells, Shuah Khan, Shuah Khan, Ingo Molnar,
Peter Zijlstra, Christian Brauner
Cc: linux-ia64, linux-sh, Alexander Shishkin, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, linux-kselftest, sparclinux,
Jiri Olsa, linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai,
linux-mips, linux-xtensa, Kees Cook, Jann Horn, linuxppc-dev,
Aleksa Sarai, Andy Lutomirski, Namhyung Kim, David Drysdale,
linux-arm-kernel, linux-parisc, linux-m68k, linux-api, Chanho Min,
Oleg Nesterov, Eric Biederman, linux-alpha, linux-fsdevel,
Andrew Morton, Linus Torvalds, containers
In-Reply-To: <20190904201933.10736-1-cyphar@cyphar.com>
The change is very straightforward, and takes advantage of the (very
minor) efficiency improvements in copy_struct_from_user() -- that the
memchr_inv() check is done on a buffer instead of one-at-at-time with
get_user().
Additionally, explicitly define CLONE_ARGS_SIZE_VER0 to match the other
users of the struct-extension pattern.
Cc: Christian Brauner <christian@brauner.io>
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
---
include/uapi/linux/sched.h | 2 ++
kernel/fork.c | 34 ++++++----------------------------
2 files changed, 8 insertions(+), 28 deletions(-)
diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h
index b3105ac1381a..0945805982b4 100644
--- a/include/uapi/linux/sched.h
+++ b/include/uapi/linux/sched.h
@@ -47,6 +47,8 @@ struct clone_args {
__aligned_u64 tls;
};
+#define CLONE_ARGS_SIZE_VER0 64 /* sizeof first published struct */
+
/*
* Scheduling policies
*/
diff --git a/kernel/fork.c b/kernel/fork.c
index 2852d0e76ea3..70c10d9b429a 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2528,39 +2528,17 @@ SYSCALL_DEFINE5(clone, unsigned long, clone_flags, unsigned long, newsp,
#ifdef __ARCH_WANT_SYS_CLONE3
noinline static int copy_clone_args_from_user(struct kernel_clone_args *kargs,
struct clone_args __user *uargs,
- size_t size)
+ size_t usize)
{
+ int err;
struct clone_args args;
- if (unlikely(size > PAGE_SIZE))
- return -E2BIG;
-
- if (unlikely(size < sizeof(struct clone_args)))
+ if (unlikely(usize < CLONE_ARGS_SIZE_VER0))
return -EINVAL;
- if (unlikely(!access_ok(uargs, size)))
- return -EFAULT;
-
- if (size > sizeof(struct clone_args)) {
- unsigned char __user *addr;
- unsigned char __user *end;
- unsigned char val;
-
- addr = (void __user *)uargs + sizeof(struct clone_args);
- end = (void __user *)uargs + size;
-
- for (; addr < end; addr++) {
- if (get_user(val, addr))
- return -EFAULT;
- if (val)
- return -E2BIG;
- }
-
- size = sizeof(struct clone_args);
- }
-
- if (copy_from_user(&args, uargs, size))
- return -EFAULT;
+ err = copy_struct_from_user(&args, sizeof(args), uargs, usize);
+ if (err)
+ return err;
*kargs = (struct kernel_clone_args){
.flags = args.flags,
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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