* [PATCH 5/5] arm64: dts: exynos5433: Add support of bus frequency using VDD_INT on TM2
From: Krzysztof Kozlowski @ 2016-12-06 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480663087-4590-6-git-send-email-cw00.choi@samsung.com>
On Fri, Dec 02, 2016 at 04:18:07PM +0900, Chanwoo Choi wrote:
> This patch adds the bus Device-tree nodes for INT (Internal) block
> to enable the bus frequency scaling.
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 72 +++++++++++++++++++++++++++
> 1 file changed, 72 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index c08589970134..7b37aae336b1 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -170,6 +170,58 @@
> };
> };
>
> +&bus_g2d_400 {
> + devfreq-events = <&ppmu_event0_d0_general>, <&ppmu_event0_d1_general>;
> + vdd-supply = <&buck4_reg>;
> + exynos,saturation-ratio = <10>;
> + status = "okay";
> +};
> +
> +&bus_mscl {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_jpeg {
Except the first entry (which is a parent), are there any objections to
order these nodes alphabetically? This also applies to the previously
patch.
Beside that nit, looks good. I will have to wait anyway to next merge
window, so for the reference:
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_mfc {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_g2d_266 {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_gscl {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_hevc {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_bus0 {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_bus1 {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_bus2 {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> &cmu_aud {
> assigned-clocks = <&cmu_aud CLK_MOUT_AUD_PLL_USER>;
> assigned-clock-parents = <&cmu_top CLK_FOUT_AUD_PLL>;
> @@ -794,6 +846,26 @@
> bus-width = <4>;
> };
>
> +&ppmu_d0_general {
> + status = "okay";
> +
> + events {
> + ppmu_event0_d0_general: ppmu-event0-d0-general {
> + event-name = "ppmu-event0-d0-general";
> + };
> + };
> +};
> +
> +&ppmu_d1_general {
> + status = "okay";
> +
> + events {
> + ppmu_event0_d1_general: ppmu-event0-d1-general {
> + event-name = "ppmu-event0-d1-general";
> + };
> + };
> +};
> +
> &pinctrl_alive {
> pinctrl-names = "default";
> pinctrl-0 = <&initial_alive>;
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v2 2/2] ASoC: atmel: tse850: rely on the ssc to register as a cpu dai by itself
From: Peter Rosin @ 2016-12-06 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481052157-23400-1-git-send-email-peda@axentia.se>
This breaks devicetree compatibility, but in this case that is ok. All
affected units are either on my desk, or running an even older version
of the driver that is not compatible with the upstreamed version anyway
(and when these other units are eventually updated, they will get a
fresh dtb as well, so that is not a significant problem either).
All of that is of course assuming that noone else has managed to build
something that can use this driver, but that seems extremely improbable.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
.../bindings/sound/axentia,tse850-pcm5142.txt | 11 ++++++++---
sound/soc/atmel/tse850-pcm5142.c | 23 +++-------------------
2 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
index 5b9b38f578bb..fdb25b492514 100644
--- a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
+++ b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
@@ -2,8 +2,7 @@ Devicetree bindings for the Axentia TSE-850 audio complex
Required properties:
- compatible: "axentia,tse850-pcm5142"
- - axentia,ssc-controller: The phandle of the atmel SSC controller used as
- cpu dai.
+ - axentia,cpu-dai: The phandle of the cpu dai.
- axentia,audio-codec: The phandle of the PCM5142 codec.
- axentia,add-gpios: gpio specifier that controls the mixer.
- axentia,loop1-gpios: gpio specifier that controls loop relays on channel 1.
@@ -43,6 +42,12 @@ the PCM5142 codec.
Example:
+ &ssc0 {
+ #sound-dai-cells = <0>;
+
+ status = "okay";
+ };
+
&i2c {
codec: pcm5142 at 4c {
compatible = "ti,pcm5142";
@@ -77,7 +82,7 @@ Example:
sound {
compatible = "axentia,tse850-pcm5142";
- axentia,ssc-controller = <&ssc0>;
+ axentia,cpu-dai = <&ssc0>;
axentia,audio-codec = <&codec>;
axentia,add-gpios = <&pioA 8 GPIO_ACTIVE_LOW>;
diff --git a/sound/soc/atmel/tse850-pcm5142.c b/sound/soc/atmel/tse850-pcm5142.c
index ac6a814c8ecf..a72c7d642026 100644
--- a/sound/soc/atmel/tse850-pcm5142.c
+++ b/sound/soc/atmel/tse850-pcm5142.c
@@ -51,11 +51,7 @@
#include <sound/soc.h>
#include <sound/pcm_params.h>
-#include "atmel_ssc_dai.h"
-
struct tse850_priv {
- int ssc_id;
-
struct gpio_desc *add;
struct gpio_desc *loop1;
struct gpio_desc *loop2;
@@ -329,23 +325,20 @@ static int tse850_dt_init(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct device_node *codec_np, *cpu_np;
- struct snd_soc_card *card = &tse850_card;
struct snd_soc_dai_link *dailink = &tse850_dailink;
- struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
if (!np) {
dev_err(&pdev->dev, "only device tree supported\n");
return -EINVAL;
}
- cpu_np = of_parse_phandle(np, "axentia,ssc-controller", 0);
+ cpu_np = of_parse_phandle(np, "axentia,cpu-dai", 0);
if (!cpu_np) {
- dev_err(&pdev->dev, "failed to get dai and pcm info\n");
+ dev_err(&pdev->dev, "failed to get cpu dai\n");
return -EINVAL;
}
dailink->cpu_of_node = cpu_np;
dailink->platform_of_node = cpu_np;
- tse850->ssc_id = of_alias_get_id(cpu_np, "ssc");
of_node_put(cpu_np);
codec_np = of_parse_phandle(np, "axentia,audio-codec", 0);
@@ -415,23 +408,14 @@ static int tse850_probe(struct platform_device *pdev)
return ret;
}
- ret = atmel_ssc_set_audio(tse850->ssc_id);
- if (ret != 0) {
- dev_err(dev,
- "failed to set SSC %d for audio\n", tse850->ssc_id);
- goto err_disable_ana;
- }
-
ret = snd_soc_register_card(card);
if (ret) {
dev_err(dev, "snd_soc_register_card failed\n");
- goto err_put_audio;
+ goto err_disable_ana;
}
return 0;
-err_put_audio:
- atmel_ssc_put_audio(tse850->ssc_id);
err_disable_ana:
regulator_disable(tse850->ana);
return ret;
@@ -443,7 +427,6 @@ static int tse850_remove(struct platform_device *pdev)
struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
snd_soc_unregister_card(card);
- atmel_ssc_put_audio(tse850->ssc_id);
regulator_disable(tse850->ana);
return 0;
--
2.1.4
^ permalink raw reply related
* [PATCH v2 1/2] misc: atmel-ssc: register as sound DAI if #sound-dai-cells is present
From: Peter Rosin @ 2016-12-06 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481052157-23400-1-git-send-email-peda@axentia.se>
The SSC is currently not usable with the ASoC simple-audio-card, as
every SSC audio user has to build a platform driver that may do as
little as calling atmel_ssc_set_audio/atmel_ssc_put_audio (which
allocates the SSC and registers a DAI with the ASoC subsystem).
So, have that happen automatically, if the #sound-dai-cells property
is present in devicetree, which it has to be anyway for simple audio
card to work.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
.../devicetree/bindings/misc/atmel-ssc.txt | 2 +
drivers/misc/atmel-ssc.c | 50 ++++++++++++++++++++++
include/linux/atmel-ssc.h | 1 +
3 files changed, 53 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
index efc98ea1f23d..f8629bb73945 100644
--- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
+++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
@@ -24,6 +24,8 @@ Optional properties:
this parameter to choose where the clock from.
- By default the clock is from TK pin, if the clock from RK pin, this
property is needed.
+ - #sound-dai-cells: Should contain <0>.
+ - This property makes the SSC into an automatically registered DAI.
Examples:
- PDC transfer:
diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index 0516ecda54d3..b2a0340f277e 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -20,6 +20,8 @@
#include <linux/of.h>
+#include "../../sound/soc/atmel/atmel_ssc_dai.h"
+
/* Serialize access to ssc_list and user count */
static DEFINE_SPINLOCK(user_lock);
static LIST_HEAD(ssc_list);
@@ -145,6 +147,49 @@ static inline const struct atmel_ssc_platform_data * __init
platform_get_device_id(pdev)->driver_data;
}
+#ifdef CONFIG_SND_ATMEL_SOC_SSC
+static int ssc_sound_dai_probe(struct ssc_device *ssc)
+{
+ struct device_node *np = ssc->pdev->dev.of_node;
+ int ret;
+ int id;
+
+ ssc->sound_dai = false;
+
+ if (!of_property_read_bool(np, "#sound-dai-cells"))
+ return 0;
+
+ id = of_alias_get_id(np, "ssc");
+ if (id < 0)
+ return id;
+
+ ret = atmel_ssc_set_audio(id);
+ ssc->sound_dai = !ret;
+
+ return ret;
+}
+
+static void ssc_sound_dai_remove(struct ssc_device *ssc)
+{
+ if (!ssc->sound_dai)
+ return;
+
+ atmel_ssc_put_audio(of_alias_get_id(ssc->pdev->dev.of_node, "ssc"));
+}
+#else
+static inline int ssc_sound_dai_probe(struct ssc_device *ssc)
+{
+ if (of_property_read_bool(ssc->pdev->dev.of_node, "#sound-dai-cells"))
+ return -ENOTSUPP;
+
+ return 0;
+}
+
+static inline void ssc_sound_dai_remove(struct ssc_device *ssc)
+{
+}
+#endif
+
static int ssc_probe(struct platform_device *pdev)
{
struct resource *regs;
@@ -204,6 +249,9 @@ static int ssc_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "Atmel SSC device at 0x%p (irq %d)\n",
ssc->regs, ssc->irq);
+ if (ssc_sound_dai_probe(ssc))
+ dev_err(&pdev->dev, "failed to auto-setup ssc for audio\n");
+
return 0;
}
@@ -211,6 +259,8 @@ static int ssc_remove(struct platform_device *pdev)
{
struct ssc_device *ssc = platform_get_drvdata(pdev);
+ ssc_sound_dai_remove(ssc);
+
spin_lock(&user_lock);
list_del(&ssc->list);
spin_unlock(&user_lock);
diff --git a/include/linux/atmel-ssc.h b/include/linux/atmel-ssc.h
index 7c0f6549898b..fdb545101ede 100644
--- a/include/linux/atmel-ssc.h
+++ b/include/linux/atmel-ssc.h
@@ -20,6 +20,7 @@ struct ssc_device {
int user;
int irq;
bool clk_from_rk_pin;
+ bool sound_dai;
};
struct ssc_device * __must_check ssc_request(unsigned int ssc_num);
--
2.1.4
^ permalink raw reply related
* [PATCH v2 0/2] register atmel-ssc as sound DAI w/o platform driver
From: Peter Rosin @ 2016-12-06 19:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
v1 -> v2 changes
- add ack from Rob Herring on patch 1/2.
- add reasons why breaking compatibility is ok for patch 2/2 (requested
by Rob).
- add #sound-dai-cells to the ssc0 node in the devcietree example.
The Atmel SSC is currently not usable as an audio DAI unless someone
registers it with ASoC. This is currently delegated to a platform
driver for every possible audio use, and prevents the SSC from being
used as a cpu DAI with the simple-audio-card driver.
The first patch fixes this.
The second patch simplifies one of these platform drivers, since it
can now rely on the SSC to register itself with ASoC. However, this
may not be a possible simplification for other, older, drivers since
it also requires device tree changes.
Cheers,
Peter
Peter Rosin (2):
misc: atmel-ssc: register as sound DAI if #sound-dai-cells is present
ASoC: atmel: tse850: rely on the ssc to register as a cpu dai by
itself
.../devicetree/bindings/misc/atmel-ssc.txt | 2 +
.../bindings/sound/axentia,tse850-pcm5142.txt | 11 +++--
drivers/misc/atmel-ssc.c | 50 ++++++++++++++++++++++
include/linux/atmel-ssc.h | 1 +
sound/soc/atmel/tse850-pcm5142.c | 23 ++--------
5 files changed, 64 insertions(+), 23 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH 4/5] arm64: dts: exynos5433: Add bus dt node using VDD_INT for Exynos5433
From: Krzysztof Kozlowski @ 2016-12-06 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480663087-4590-5-git-send-email-cw00.choi@samsung.com>
On Fri, Dec 02, 2016 at 04:18:06PM +0900, Chanwoo Choi wrote:
> This patch adds the bus nodes using VDD_INT for Exynos5433 SoC.
> Exynos5433 has the following AMBA AXI buses to translate data
> between DRAM and sub-blocks.
>
> Following list specify the detailed correlation between sub-block and clock:
> - CLK_ACLK_G2D_{400|266} : Bus clock for G2D
> - CLK_ACLK_MSCL_400 : Bus clock for MSCL (Mobile Scaler)
> - CLK_ACLK_GSCL_333 : Bus clock for GSCL (General Scaler)
> - CLK_SCLK_JPEG_MSCL : Bus clock for JPEG
> - CLK_ACLK_MFC_400 : Bus clock for MFC (Multi Format Codec)
> - CLK_ACLK_HEVC_400 : Bus clock for HEVC (High Effective Video Codec)
> - CLK_ACLK_BUS0_400 : NoC(Network On Chip)'s bus clock for PERIC/PERIS/FSYS/MSCL
> - CLK_ACLK_BUS1_400 : NoC's bus clock for MFC/HEVC/G3D
> - CLK_ACLK_BUS2_400 : NoC's bus clock for GSCL/DISP/G2D/CAM0/CAM1/ISP
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 208 +++++++++++++++++++++++++
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 1 +
> 2 files changed, 209 insertions(+)
> create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
> new file mode 100644
> index 000000000000..b1e1d9c622e1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
> @@ -0,0 +1,208 @@
> +/*
> + * Samsung's Exynos5433 SoC Memory interface and AMBA bus device tree source
> + *
> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> + * Chanwoo Choi <cw00.choi@samsung.com>
> + *
> + * Samsung's Exynos5433 SoC Memory interface and AMBA buses are listed
> + * as device tree nodes are listed in this file.
This duplicates the introduction line and does not make sense.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/ {
Shouldn't these be under soc node? It looks like property of SoC itself.
> + /* INT (Internal) block using VDD_INT */
> + bus_g2d_400: bus_g2d_400 {
In node name, the dash '-' is preferred. The name should describe
general class of device so probably this should be just "bus"... but I
don't see a way how to do it reasonable anyway.
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu_top CLK_ACLK_G2D_400>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_g2d_400_opp_table>;
> + status ="disable";
Hm?
> + };
> +
> + bus_mscl: bus_mscl {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu_top CLK_ACLK_MSCL_400>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_g2d_400_opp_table>;
> + status ="disable";
> + };
> +
> + bus_jpeg: bus_jpeg {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu_top CLK_SCLK_JPEG_MSCL>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_g2d_400_opp_table>;
> + status ="disable";
> + };
> +
> + bus_mfc: bus_mfc {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu_top CLK_ACLK_MFC_400>;
> +
> + clock-names = "bus";
> + operating-points-v2 = <&bus_g2d_400_opp_table>;
> + status ="disable";
> + };
> +
> + bus_g2d_266: bus_g2d_266 {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu_top CLK_ACLK_G2D_266>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_g2d_266_opp_table>;
> + status ="disable";
> + };
> +
> + bus_gscl: bus_gscl {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu_top CLK_ACLK_GSCL_333>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_gscl_opp_table>;
> + status ="disable";
> + };
> +
> + bus_hevc: bus_hevc {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu_top CLK_ACLK_HEVC_400>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_hevc_opp_table>;
> + status ="disable";
> + };
> +
> + bus_bus0: bus_bus0 {
bus, bus, bus, bus, jackpot! Let's try to find better name and label for
these. :)
Best regards,
Krzysztof
^ permalink raw reply
* [PATCHv4 08/10] mm/kasan: Switch to using __pa_symbol and lm_alias
From: Mark Rutland @ 2016-12-06 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480445729-27130-9-git-send-email-labbott@redhat.com>
On Tue, Nov 29, 2016 at 10:55:27AM -0800, Laura Abbott wrote:
> @@ -94,7 +94,7 @@ static void __init zero_pud_populate(pgd_t *pgd, unsigned long addr,
>
> pud_populate(&init_mm, pud, kasan_zero_pmd);
We also need to lm_alias()-ify kasan_zero_pmd here, or we'll get a
stream of warnings at boot (example below).
I should have spotted that. :/
With that fixed up, I'm able to boot Juno with both KASAN_INLINE and
DEBUG_VIRTUAL, without issued. With that, my previous Reviewed-by and Tested-by
stand.
Thanks,
Mark.
---->8----
[ 0.000000] virt_to_phys used for non-linear address :ffff20000a367000
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] WARNING: CPU: 0 PID: 0 at arch/arm64/mm/physaddr.c:13 __virt_to_phys+0x48/0x68
[ 0.000000] Modules linked in:
[ 0.000000]
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-rc6-00012-gdcc0162-dirty #13
[ 0.000000] Hardware name: ARM Juno development board (r1) (DT)
[ 0.000000] task: ffff200009ec2200 task.stack: ffff200009eb0000
[ 0.000000] PC is at __virt_to_phys+0x48/0x68
[ 0.000000] LR is at __virt_to_phys+0x48/0x68
[ 0.000000] pc : [<ffff2000080af310>] lr : [<ffff2000080af310>] pstate: 600000c5
[ 0.000000] sp : ffff200009eb3c80
[ 0.000000] x29: ffff200009eb3c80 x28: ffff20000abdd000
[ 0.000000] x27: ffff200009ce1000 x26: ffff047fffffffff
[ 0.000000] x25: ffff200009ce1000 x24: ffff20000a366100
[ 0.000000] x23: ffff048000000000 x22: ffff20000a366000
[ 0.000000] x21: ffff040080000000 x20: ffff040040000000
[ 0.000000] x19: ffff20000a367000 x18: 000000000000005c
[ 0.000000] x17: 00000009ffec20e0 x16: 00000000fefff4b0
[ 0.000000] x15: ffffffffffffffff x14: 302b646d705f6f72
[ 0.000000] x13: 657a5f6e6173616b x12: 2820303030373633
[ 0.000000] x11: ffff20000a376ca0 x10: 0000000000000010
[ 0.000000] x9 : 646461207261656e x8 : 696c2d6e6f6e2072
[ 0.000000] x7 : 6f66206465737520 x6 : ffff20000a3741e5
[ 0.000000] x5 : 1fffe4000146ee0e x4 : 1fffe400013de704
[ 0.000000] x3 : 1fffe400013d6003 x2 : 1fffe400013d6003
[ 0.000000] x1 : 0000000000000000 x0 : 0000000000000056
[ 0.000000]
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] Call trace:
[ 0.000000] Exception stack(0xffff200009eb3a50 to 0xffff200009eb3b80)
[ 0.000000] 3a40: ffff20000a367000 0001000000000000
[ 0.000000] 3a60: ffff200009eb3c80 ffff2000080af310 00000000600000c5 000000000000003d
[ 0.000000] 3a80: ffff200009ce1000 ffff2000081c4720 0000000041b58ab3 ffff200009c6cd98
[ 0.000000] 3aa0: ffff2000080818a0 ffff20000a366000 ffff048000000000 ffff20000a366100
[ 0.000000] 3ac0: ffff200009ce1000 ffff047fffffffff ffff200009ce1000 ffff20000abdd000
[ 0.000000] 3ae0: ffff0400013e3ccf ffff20000a3766c0 0000000000000000 0000000000000000
[ 0.000000] 3b00: ffff200009eb3c80 ffff200009eb3c80 ffff200009eb3c40 00000000ffffffc8
[ 0.000000] 3b20: ffff200009eb3b50 ffff2000082cbd3c ffff200009eb3c80 ffff200009eb3c80
[ 0.000000] 3b40: ffff200009eb3c40 00000000ffffffc8 0000000000000056 0000000000000000
[ 0.000000] 3b60: 1fffe400013d6003 1fffe400013d6003 1fffe400013de704 1fffe4000146ee0e
[ 0.000000] [<ffff2000080af310>] __virt_to_phys+0x48/0x68
[ 0.000000] [<ffff200009d734e8>] zero_pud_populate+0x88/0x138
[ 0.000000] [<ffff200009d736f8>] kasan_populate_zero_shadow+0x160/0x18c
[ 0.000000] [<ffff200009d5a048>] kasan_init+0x1f8/0x408
[ 0.000000] [<ffff200009d54000>] setup_arch+0x314/0x948
[ 0.000000] [<ffff200009d50c64>] start_kernel+0xb4/0x54c
[ 0.000000] [<ffff200009d501e0>] __primary_switched+0x64/0x74
[mark at leverpostej:~/src/linux]% uselinaro 15.08 aarch64-linux-gnu-readelf -s vmlinux | grep ffff20000a367000
108184: ffff20000a367000 4096 OBJECT GLOBAL DEFAULT 25 kasan_zero_pmd
[mark at leverpostej:~/src/linux]% uselinaro 15.08 aarch64-linux-gnu-addr2line -ife vmlinux ffff200009d734e8
set_pud
/home/mark/src/linux/./arch/arm64/include/asm/pgtable.h:435
__pud_populate
/home/mark/src/linux/./arch/arm64/include/asm/pgalloc.h:47
pud_populate
/home/mark/src/linux/./arch/arm64/include/asm/pgalloc.h:52
zero_pud_populate
/home/mark/src/linux/mm/kasan/kasan_init.c:95
^ permalink raw reply
* [RESEND PATCH V6 0/6] Add support for privileged mappings
From: Robin Murphy @ 2016-12-06 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000d01d24e02$e3023700$a906a500$@codeaurora.org>
On 04/12/16 07:48, Sricharan wrote:
> Hi Robin,
>
>> Hi Sricharan,
>>
>> On 02/12/16 14:55, Sricharan R wrote:
>>> This series is a resend of the V5 that Mitch sent sometime back [2]
>>> All the patches are the same and i have just rebased. Not sure why this
>>> finally did not make it last time. The last patch in the previous
>>> series does not apply now [3], so just redid that. Also Copied the tags
>>> that he had from last time as well.
>>
>> Heh, I was assuming this would be down to me to pick up. Vinod did have
>> some complaints last time about the commit message on the PL330 patch -
>> I did get as far as rewriting that and reworking onto my SMMU
>> changes[1], I just hadn't got round to sending it, so it fell onto the
>> "after the next merge window" pile.
>>
>> I'd give some review comments, but they'd essentially be a diff against
>> that branch :)
>>
>
> Sure, i did not knew that you were on this already. I can repost with the diff
> from your branch taken in or wait for you as well. I am fine with either ways
> that you suggest.
>
> I checked the patches against your branch, i see that the changes are,
>
> 1) one patch for implementing it for armv7s descriptor
> 2) Changes on pl330 patch commit logs and
> 3) One patch for doing the revert on arm-smmuv3 as well.
If you want to pick up my short-descriptor and SMMUv3 patches and run
with them you're more than welcome - the rest is just cosmetic stuff
which doesn't really matter, especially as it's picking up acks as-is.
Robin.
> Regards,
> Sricharan
>
>
^ permalink raw reply
* [PATCHv4 05/10] arm64: Use __pa_symbol for kernel symbols
From: Laura Abbott @ 2016-12-06 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206170222.GE24177@leverpostej>
On 12/06/2016 09:02 AM, Mark Rutland wrote:
> Hi,
>
> As a heads-up, it looks like this got mangled somewhere. In the hunk at
> arch/arm64/mm/kasan_init.c:68, 'do' in the context became 'edo'.
> Deleting the 'e' makes it apply.
>
Argh, this must have come in while editing the .patch before e-mailing.
Sorry about that.
> I think this is almost there; other than James's hibernate bug I only
> see one real issue, and everything else is a minor nit.
>
> On Tue, Nov 29, 2016 at 10:55:24AM -0800, Laura Abbott wrote:
>> __pa_symbol is technically the marco that should be used for kernel
>> symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL which
>> will do bounds checking. As part of this, introduce lm_alias, a
>> macro which wraps the __va(__pa(...)) idiom used a few places to
>> get the alias.
>
> I think the addition of the lm_alias() macro under include/mm should be
> a separate preparatory patch. That way it's separate from the
> arm64-specific parts, and more obvious to !arm64 people reviewing the
> other parts.
>
I debated if it was more obvious to show how it was used in context
vs a stand alone patch. I think you're right that for non-arm64 reviewers
the separate patch would be easier to find.
>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>> ---
>> v4: Stop calling __va early, conversion of a few more sites. I decided against
>> wrapping the __p*d_populate calls into new functions since the call sites
>> should be limited.
>> ---
>> arch/arm64/include/asm/kvm_mmu.h | 4 ++--
>> arch/arm64/include/asm/memory.h | 2 ++
>> arch/arm64/include/asm/mmu_context.h | 6 +++---
>> arch/arm64/include/asm/pgtable.h | 2 +-
>> arch/arm64/kernel/acpi_parking_protocol.c | 2 +-
>> arch/arm64/kernel/cpu-reset.h | 2 +-
>> arch/arm64/kernel/cpufeature.c | 2 +-
>> arch/arm64/kernel/hibernate.c | 13 +++++--------
>> arch/arm64/kernel/insn.c | 2 +-
>> arch/arm64/kernel/psci.c | 2 +-
>> arch/arm64/kernel/setup.c | 8 ++++----
>> arch/arm64/kernel/smp_spin_table.c | 2 +-
>> arch/arm64/kernel/vdso.c | 4 ++--
>> arch/arm64/mm/init.c | 11 ++++++-----
>> arch/arm64/mm/kasan_init.c | 21 +++++++++++++-------
>> arch/arm64/mm/mmu.c | 32 +++++++++++++++++++------------
>> drivers/firmware/psci.c | 2 +-
>> include/linux/mm.h | 4 ++++
>> 18 files changed, 70 insertions(+), 51 deletions(-)
>
> It looks like we need to make sure these (directly) include <linux/mm.h>
> for __pa_symbol() and lm_alias(), or there's some fragility, e.g.
>
> [mark at leverpostej:~/src/linux]% uselinaro 15.08 make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j10 -s
> arch/arm64/kernel/psci.c: In function 'cpu_psci_cpu_boot':
> arch/arm64/kernel/psci.c:48:50: error: implicit declaration of function '__pa_symbol' [-Werror=implicit-function-declaration]
> int err = psci_ops.cpu_on(cpu_logical_map(cpu), __pa_symbol(secondary_entry));
> ^
> cc1: some warnings being treated as errors
> make[1]: *** [arch/arm64/kernel/psci.o] Error 1
> make: *** [arch/arm64/kernel] Error 2
> make: *** Waiting for unfinished jobs....
>
Right, I'll double check.
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -205,6 +205,8 @@ static inline void *phys_to_virt(phys_addr_t x)
>> #define __va(x) ((void *)__phys_to_virt((phys_addr_t)(x)))
>> #define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
>> #define virt_to_pfn(x) __phys_to_pfn(__virt_to_phys((unsigned long)(x)))
>> +#define sym_to_pfn(x) __phys_to_pfn(__pa_symbol(x))
>> +#define lm_alias(x) __va(__pa_symbol(x))
>
> As Catalin mentioned, we should be able to drop this copy of lm_alias(),
> given we have the same in the core headers.
>
>> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
>> index a2c2478..79cd86b 100644
>> --- a/arch/arm64/kernel/vdso.c
>> +++ b/arch/arm64/kernel/vdso.c
>> @@ -140,11 +140,11 @@ static int __init vdso_init(void)
>> return -ENOMEM;
>>
>> /* Grab the vDSO data page. */
>> - vdso_pagelist[0] = pfn_to_page(PHYS_PFN(__pa(vdso_data)));
>> + vdso_pagelist[0] = phys_to_page(__pa_symbol(vdso_data));
>>
>> /* Grab the vDSO code pages. */
>> for (i = 0; i < vdso_pages; i++)
>> - vdso_pagelist[i + 1] = pfn_to_page(PHYS_PFN(__pa(&vdso_start)) + i);
>> + vdso_pagelist[i + 1] = pfn_to_page(PHYS_PFN(__pa_symbol(&vdso_start)) + i);
>
> I see you added sym_to_pfn(), which we can use here to keep this short
> and legible. It might also be worth using a temporary pfn_t, e.g.
>
> pfn = sym_to_pfn(&vdso_start);
>
> for (i = 0; i < vdso_pages; i++)
> vdso_pagelist[i + 1] = pfn_to_page(pfn + i);
>
Good idea.
>> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
>> index 8263429..9defbe2 100644
>> --- a/drivers/firmware/psci.c
>> +++ b/drivers/firmware/psci.c
>> @@ -383,7 +383,7 @@ static int psci_suspend_finisher(unsigned long index)
>> u32 *state = __this_cpu_read(psci_power_state);
>>
>> return psci_ops.cpu_suspend(state[index - 1],
>> - virt_to_phys(cpu_resume));
>> + __pa_symbol(cpu_resume));
>> }
>>
>> int psci_cpu_suspend_enter(unsigned long index)
>
> This should probably be its own patch since it's not under arch/arm64/.
>
Fine by me.
> I'm happy for this to go via the arm64 tree with the rest regardless
> (assuming Lorenzo has no objections).
>
> Thanks,
> Mark.
>
Thanks,
Laura
^ permalink raw reply
* [PATCH 3/5] arm64: dts: exynos5433: Add PPMU dt node
From: Krzysztof Kozlowski @ 2016-12-06 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480663087-4590-4-git-send-email-cw00.choi@samsung.com>
On Fri, Dec 02, 2016 at 04:18:05PM +0900, Chanwoo Choi wrote:
> This patch adds PPMU (Platform Performance Monitoring Unit) Device-tree node
> to measure the utilization of each IP in Exynos SoC.
>
> - PPMU_D{0|1}_CPU are used to measure the utilization of MIF (Memory Interface)
> block with VDD_MIF power source.
> - PPMU_D{0|1}_GENERAL are used to measure the utilization of INT(Internal)
> block with VDD_INT power source.
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index 64226d5ae471..8c4ee84d5232 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -599,6 +599,30 @@
> clock-names = "fin_pll", "mct";
> };
>
> + ppmu_d0_cpu: ppmu at 10480000 {
> + compatible = "samsung,exynos-ppmu-v2";
> + reg = <0x10480000 0x2000>;
> + status = "disabled";
Why these are disabled? They have some external dependencies?
Best regards,
Krzysztof
> + };
> +
> + ppmu_d0_general: ppmu at 10490000 {
> + compatible = "samsung,exynos-ppmu-v2";
> + reg = <0x10490000 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_d1_cpu: ppmu at 104b0000 {
> + compatible = "samsung,exynos-ppmu-v2";
> + reg = <0x104b0000 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_d1_general: ppmu at 104c0000 {
> + compatible = "samsung,exynos-ppmu-v2";
> + reg = <0x104c0000 0x2000>;
> + status = "disabled";
> + };
> +
> pinctrl_alive: pinctrl at 10580000 {
> compatible = "samsung,exynos5433-pinctrl";
> reg = <0x10580000 0x1a20>, <0x11090000 0x100>;
> --
> 1.9.1
>
^ permalink raw reply
* [stable:PATCH 3/3] arm64: suspend: Reconfigure PSTATE after resume from idle [v4.8]
From: James Morse @ 2016-12-06 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206190454.19083-1-james.morse@arm.com>
commit d08544127d9fb4505635e3cb6871fd50a42947bd upstream.
The suspend/resume path in kernel/sleep.S, as used by cpu-idle, does not
save/restore PSTATE. As a result of this cpufeatures that were detected
and have bits in PSTATE get lost when we resume from idle.
UAO gets set appropriately on the next context switch. PAN will be
re-enabled next time we return from user-space, but on a preemptible
kernel we may run work accessing user space before this point.
Add code to re-enable theses two features in __cpu_suspend_exit().
We re-use uao_thread_switch() passing current.
Signed-off-by: James Morse <james.morse@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
Cc: <stable@vger.kernel.org> # 4.8.12
---
arch/arm64/include/asm/exec.h | 3 +++
arch/arm64/kernel/process.c | 3 ++-
arch/arm64/kernel/suspend.c | 11 +++++++++++
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/exec.h b/arch/arm64/include/asm/exec.h
index db0563c23482..f7865dd9d868 100644
--- a/arch/arm64/include/asm/exec.h
+++ b/arch/arm64/include/asm/exec.h
@@ -18,6 +18,9 @@
#ifndef __ASM_EXEC_H
#define __ASM_EXEC_H
+#include <linux/sched.h>
+
extern unsigned long arch_align_stack(unsigned long sp);
+void uao_thread_switch(struct task_struct *next);
#endif /* __ASM_EXEC_H */
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 6cd2612236dc..9cc8667212a6 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -49,6 +49,7 @@
#include <asm/alternative.h>
#include <asm/compat.h>
#include <asm/cacheflush.h>
+#include <asm/exec.h>
#include <asm/fpsimd.h>
#include <asm/mmu_context.h>
#include <asm/processor.h>
@@ -303,7 +304,7 @@ static void tls_thread_switch(struct task_struct *next)
}
/* Restore the UAO state depending on next's addr_limit */
-static void uao_thread_switch(struct task_struct *next)
+void uao_thread_switch(struct task_struct *next)
{
if (IS_ENABLED(CONFIG_ARM64_UAO)) {
if (task_thread_info(next)->addr_limit == KERNEL_DS)
diff --git a/arch/arm64/kernel/suspend.c b/arch/arm64/kernel/suspend.c
index b616e365cee3..23ddf5500b09 100644
--- a/arch/arm64/kernel/suspend.c
+++ b/arch/arm64/kernel/suspend.c
@@ -1,8 +1,11 @@
#include <linux/ftrace.h>
#include <linux/percpu.h>
#include <linux/slab.h>
+#include <asm/alternative.h>
#include <asm/cacheflush.h>
+#include <asm/cpufeature.h>
#include <asm/debug-monitors.h>
+#include <asm/exec.h>
#include <asm/pgtable.h>
#include <asm/memory.h>
#include <asm/mmu_context.h>
@@ -48,6 +51,14 @@ void notrace __cpu_suspend_exit(void)
set_my_cpu_offset(per_cpu_offset(smp_processor_id()));
/*
+ * PSTATE was not saved over suspend/resume, re-enable any detected
+ * features that might not have been set correctly.
+ */
+ asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_HAS_PAN,
+ CONFIG_ARM64_PAN));
+ uao_thread_switch(current);
+
+ /*
* Restore HW breakpoint registers to sane values
* before debug exceptions are possibly reenabled
* through local_dbg_restore.
--
2.10.1
^ permalink raw reply related
* [stable:PATCH 2/3] arm64: mm: Set PSTATE.PAN from the cpu_enable_pan() call [v4.8]
From: James Morse @ 2016-12-06 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206190454.19083-1-james.morse@arm.com>
commit 7209c868600bd8926e37c10b9aae83124ccc1dd8 upstream.
Commit 338d4f49d6f7 ("arm64: kernel: Add support for Privileged Access
Never") enabled PAN by enabling the 'SPAN' feature-bit in SCTLR_EL1.
This means the PSTATE.PAN bit won't be set until the next return to the
kernel from userspace. On a preemptible kernel we may schedule work that
accesses userspace on a CPU before it has done this.
Now that cpufeature enable() calls are scheduled via stop_machine(), we
can set PSTATE.PAN from the cpu_enable_pan() call.
Add WARN_ON_ONCE(in_interrupt()) to check the PSTATE value we updated
is not immediately discarded.
Reported-by: Tony Thompson <anthony.thompson@arm.com>
Reported-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
[will: fixed typo in comment]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
Cc: <stable@vger.kernel.org> # 4.8.12
---
arch/arm64/mm/fault.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 2001ebd12666..67506c3c5476 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -29,7 +29,9 @@
#include <linux/sched.h>
#include <linux/highmem.h>
#include <linux/perf_event.h>
+#include <linux/preempt.h>
+#include <asm/bug.h>
#include <asm/cpufeature.h>
#include <asm/exception.h>
#include <asm/debug-monitors.h>
@@ -673,7 +675,14 @@ NOKPROBE_SYMBOL(do_debug_exception);
#ifdef CONFIG_ARM64_PAN
int cpu_enable_pan(void *__unused)
{
+ /*
+ * We modify PSTATE. This won't work from irq context as the PSTATE
+ * is discarded once we return from the exception.
+ */
+ WARN_ON_ONCE(in_interrupt());
+
config_sctlr_el1(SCTLR_EL1_SPAN, 0);
+ asm(SET_PSTATE_PAN(1));
return 0;
}
#endif /* CONFIG_ARM64_PAN */
--
2.10.1
^ permalink raw reply related
* [stable:PATCH 1/3] arm64: cpufeature: Schedule enable() calls instead of calling them via IPI [v4.8]
From: James Morse @ 2016-12-06 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206190454.19083-1-james.morse@arm.com>
commit 2a6dcb2b5f3e21592ca8dfa198dcce7bec09b020 upstream.
The enable() call for a cpufeature/errata is called using on_each_cpu().
This issues a cross-call IPI to get the work done. Implicitly, this
stashes the running PSTATE in SPSR when the CPU receives the IPI, and
restores it when we return. This means an enable() call can never modify
PSTATE.
To allow PAN to do this, change the on_each_cpu() call to use
stop_machine(). This schedules the work on each CPU which allows
us to modify PSTATE.
This involves changing the protype of all the enable() functions.
enable_cpu_capabilities() is called during boot and enables the feature
on all online CPUs. This path now uses stop_machine(). CPU features for
hotplug'd CPUs are enabled by verify_local_cpu_features() which only
acts on the local CPU, and can already modify the running PSTATE as it
is called from secondary_start_kernel().
Reported-by: Tony Thompson <anthony.thompson@arm.com>
Reported-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
[Removed enable() hunks for A53 workaround]
Signed-off-by: James Morse <james.morse@arm.com>
Cc: <stable@vger.kernel.org> # 4.8.12
---
arch/arm64/include/asm/cpufeature.h | 2 +-
arch/arm64/include/asm/processor.h | 6 +++---
arch/arm64/kernel/cpufeature.c | 10 +++++++++-
arch/arm64/kernel/traps.c | 3 ++-
arch/arm64/mm/fault.c | 6 ++++--
5 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 7099f26e3702..b96346b943b7 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -90,7 +90,7 @@ struct arm64_cpu_capabilities {
u16 capability;
int def_scope; /* default scope */
bool (*matches)(const struct arm64_cpu_capabilities *caps, int scope);
- void (*enable)(void *); /* Called on all active CPUs */
+ int (*enable)(void *); /* Called on all active CPUs */
union {
struct { /* To be used for erratum handling only */
u32 midr_model;
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index ace0a96e7d6e..3be0ab013e35 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -190,8 +190,8 @@ static inline void spin_lock_prefetch(const void *ptr)
#endif
-void cpu_enable_pan(void *__unused);
-void cpu_enable_uao(void *__unused);
-void cpu_enable_cache_maint_trap(void *__unused);
+int cpu_enable_pan(void *__unused);
+int cpu_enable_uao(void *__unused);
+int cpu_enable_cache_maint_trap(void *__unused);
#endif /* __ASM_PROCESSOR_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 62272eac1352..94a0330f7ec9 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -19,7 +19,9 @@
#define pr_fmt(fmt) "CPU features: " fmt
#include <linux/bsearch.h>
+#include <linux/cpumask.h>
#include <linux/sort.h>
+#include <linux/stop_machine.h>
#include <linux/types.h>
#include <asm/cpu.h>
#include <asm/cpufeature.h>
@@ -936,7 +938,13 @@ void __init enable_cpu_capabilities(const struct arm64_cpu_capabilities *caps)
{
for (; caps->matches; caps++)
if (caps->enable && cpus_have_cap(caps->capability))
- on_each_cpu(caps->enable, NULL, true);
+ /*
+ * Use stop_machine() as it schedules the work allowing
+ * us to modify PSTATE, instead of on_each_cpu() which
+ * uses an IPI, giving us a PSTATE that disappears when
+ * we return.
+ */
+ stop_machine(caps->enable, NULL, cpu_online_mask);
}
/*
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 771a01a7fbce..9595d3d9c3db 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -428,9 +428,10 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
force_signal_inject(SIGILL, ILL_ILLOPC, regs, 0);
}
-void cpu_enable_cache_maint_trap(void *__unused)
+int cpu_enable_cache_maint_trap(void *__unused)
{
config_sctlr_el1(SCTLR_EL1_UCI, 0);
+ return 0;
}
#define __user_cache_maint(insn, address, res) \
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 05d2bd776c69..2001ebd12666 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -671,9 +671,10 @@ asmlinkage int __exception do_debug_exception(unsigned long addr,
NOKPROBE_SYMBOL(do_debug_exception);
#ifdef CONFIG_ARM64_PAN
-void cpu_enable_pan(void *__unused)
+int cpu_enable_pan(void *__unused)
{
config_sctlr_el1(SCTLR_EL1_SPAN, 0);
+ return 0;
}
#endif /* CONFIG_ARM64_PAN */
@@ -684,8 +685,9 @@ void cpu_enable_pan(void *__unused)
* We need to enable the feature at runtime (instead of adding it to
* PSR_MODE_EL1h) as the feature may not be implemented by the cpu.
*/
-void cpu_enable_uao(void *__unused)
+int cpu_enable_uao(void *__unused)
{
asm(SET_PSTATE_UAO(1));
+ return 0;
}
#endif /* CONFIG_ARM64_UAO */
--
2.10.1
^ permalink raw reply related
* [stable:PATCH 0/3] PAN fixes backport for v4.8.12
From: James Morse @ 2016-12-06 19:04 UTC (permalink / raw)
To: linux-arm-kernel
Hi Greg, linux-stable,
This is the backport of the recent PAN fixes series for v4.8.
Original series:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461806.html
Next time I will remember to work backwards through stable versions.
Sorry for the confusion!
Thanks,
James Morse (3):
arm64: cpufeature: Schedule enable() calls instead of calling them via
IPI [v4.8]
arm64: mm: Set PSTATE.PAN from the cpu_enable_pan() call [v4.8]
arm64: suspend: Reconfigure PSTATE after resume from idle [v4.8]
arch/arm64/include/asm/cpufeature.h | 2 +-
arch/arm64/include/asm/exec.h | 3 +++
arch/arm64/include/asm/processor.h | 6 +++---
arch/arm64/kernel/cpufeature.c | 10 +++++++++-
arch/arm64/kernel/process.c | 3 ++-
arch/arm64/kernel/suspend.c | 11 +++++++++++
arch/arm64/kernel/traps.c | 3 ++-
arch/arm64/mm/fault.c | 15 +++++++++++++--
8 files changed, 44 insertions(+), 9 deletions(-)
--
2.10.1
^ permalink raw reply
* [PATCH] arm64: Add CMDLINE_EXTEND
From: Will Deacon @ 2016-12-06 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52e471aa-9ad8-2a6a-efc4-0746b93ab37a@infradead.org>
On Tue, Dec 06, 2016 at 10:28:19AM -0800, Geoff Levand wrote:
> On 12/06/2016 04:20 AM, Will Deacon wrote:
> > On Mon, Dec 05, 2016 at 09:41:06AM -0800, Geoff Levand wrote:
> >> On 12/05/2016 04:08 AM, Catalin Marinas wrote:
> >>> On Fri, Dec 02, 2016 at 02:17:02PM -0800, Geoff Levand wrote:
> >>>> The device tree code already supports CMDLINE_EXTEND,
> >>>> so add the config option to make it available on arm64.
> >>>
> >>> What's your use-case for this patch? Note that both CMDLINE_FORCE and
> >>> CMDLINE_EXTEND (if we introduce it) are ignored by the EFI stub.
> >>> However, we don't seem to have stated this anywhere.
> >>
> >> I use this in CoreOS, where we need to set "acpi=force" for
> >> arm64. CoreOS uses a proper UEFI + grub.
> >
> > So why can't you just set that in grub if you want to boot with ACPI?
>
> That is how I originally did it, but it was suggested I
> do it in the kernel config. See:
>
> https://github.com/coreos/scripts/pull/610
>
> Is there any reason why we don't want arm64 to have
> CMDLINE_EXTEND?
I'm yet to see a good use-case for it.
Will
^ permalink raw reply
* [RFC PATCH 00/23] arm: defconfigs: use kconfig fragments
From: Olof Johansson @ 2016-12-06 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481027938-31831-1-git-send-email-b.zolnierkie@samsung.com>
On Tue, Dec 6, 2016 at 4:38 AM, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
> Hi,
>
> This RFC patchset starts convertion of ARM defconfigs to use kconfig
> fragments and dynamically generate defconfigs. The goals of this
> work are to:
You don't provide any motivation as to why this is better. As far as I
am concerned it'll just be a mess.
So:
Nack. So much nack. I really don't want to see a proliferation of
config fragments like this.
I had a feeling it was a bad idea to pick up that one line config
fragment before, since it opened the door for this kind of mess. :(
-Olof
^ permalink raw reply
* [PATCHv4 10/10] arm64: Add support for CONFIG_DEBUG_VIRTUAL
From: Mark Rutland @ 2016-12-06 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480445729-27130-11-git-send-email-labbott@redhat.com>
On Tue, Nov 29, 2016 at 10:55:29AM -0800, Laura Abbott wrote:
>
> + WARN(!__is_lm_address(x),
> + "virt_to_phys used for non-linear address :%pK\n", (void *)x);
Nit: s/ :/: /
It might be worth adding %pS too; i.e.
WARN(!__is_lm_address(x),
"virt_to_phys used for non-linear address: %pK (%pS)\n",
(void *)x, (void *)x);
... that way we might get a better idea before we have to resort to
grepping objdump output.
Other than that this looks good to me. This builds cleanly with and
without DEBUG_VIRTUAL enabled, and boots happily with DEBUG_VIRTUAL
disabled.
With both DEBUG_VIRTUAL and KASAN, I'm hitting a sea of warnings from
kasan_init at boot time, but I don't think that's a problem with this
patch as such, so FWIW:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
^ permalink raw reply
* [PATCH v5] ARM: davinci: da8xx: Fix sleeping function called from invalid context
From: David Lechner @ 2016-12-06 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c4e15855-b785-8bc7-5ef2-af4ec24354e6@ti.com>
On 12/06/2016 03:57 AM, Sekhar Nori wrote:
> On Tuesday 06 December 2016 03:21 PM, Alexandre Bailon wrote:
>> On 12/06/2016 10:33 AM, Sekhar Nori wrote:
>>> On Monday 05 December 2016 07:43 PM, Alexandre Bailon wrote:
>>>> Everytime the usb20 phy is enabled, there is a
>>>> "sleeping function called from invalid context" BUG.
>>>>
>>>> clk_enable() from arch/arm/mach-davinci/clock.c uses spin_lock_irqsave()
>>>> before to invoke the callback usb20_phy_clk_enable().
>>>> usb20_phy_clk_enable() uses clk_get() and clk_enable_prepapre()
>>>> which may sleep.
>>>> Move clk_get() to da8xx_register_usb20_phy_clk() and
>>>> replace clk_prepare_enable() by clk_enable().
>>>>
>>>> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
>>>
>>> This will still cause the recursive locking problem reported by David.
>>> Not sure what the point of sending this version was.
>>>
>>> Thanks,
>>> Sekhar
>>>
>
>> What am I supposed to do ?
>
> That needs to be resolved between you and David. Perhaps convert the fix
> sent by David into a proper patch and base this patch on that. Or wait
> for David to send it himself and let him also make the modifications
> needed in this patch.
>
> David ?
>
> Thanks,
> Sekhar
>
Alexandre, I was hoping that you would just squash my patch with your
patch and take Sekhar's suggestion about a separate patch to make the
private __clk_enable() public as davinci_clk_enable() when you re-submit.
You can add "Suggested-By: David Lechner <david@lechnology.com>" to the
commit message if you would like to give me some credit for my ideas.
^ permalink raw reply
* [RFC v3 09/10] iommu/arm-smmu: Implement reserved region get/put callbacks
From: Robin Murphy @ 2016-12-06 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479215363-2898-10-git-send-email-eric.auger@redhat.com>
On 15/11/16 13:09, Eric Auger wrote:
> The get() populates the list with the PCI host bridge windows
> and the MSI IOVA range.
>
> At the moment an arbitray MSI IOVA window is set at 0x8000000
> of size 1MB. This will allow to report those info in iommu-group
> sysfs?
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> ---
>
> RFC v2 -> v3:
> - use existing get/put_resv_regions
>
> RFC v1 -> v2:
> - use defines for MSI IOVA base and length
> ---
> drivers/iommu/arm-smmu.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 8f72814..81f1a83 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -278,6 +278,9 @@ enum arm_smmu_s2cr_privcfg {
>
> #define FSYNR0_WNR (1 << 4)
>
> +#define MSI_IOVA_BASE 0x8000000
> +#define MSI_IOVA_LENGTH 0x100000
> +
> static int force_stage;
> module_param(force_stage, int, S_IRUGO);
> MODULE_PARM_DESC(force_stage,
> @@ -1545,6 +1548,53 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
> return iommu_fwspec_add_ids(dev, &fwid, 1);
> }
>
> +static void arm_smmu_get_resv_regions(struct device *dev,
> + struct list_head *head)
> +{
> + struct iommu_resv_region *region;
> + struct pci_host_bridge *bridge;
> + struct resource_entry *window;
> +
> + /* MSI region */
> + region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
> + IOMMU_RESV_MSI);
> + if (!region)
> + return;
> +
> + list_add_tail(®ion->list, head);
> +
> + if (!dev_is_pci(dev))
> + return;
> +
> + bridge = pci_find_host_bridge(to_pci_dev(dev)->bus);
> +
> + resource_list_for_each_entry(window, &bridge->windows) {
> + phys_addr_t start;
> + size_t length;
> +
> + if (resource_type(window->res) != IORESOURCE_MEM &&
> + resource_type(window->res) != IORESOURCE_IO)
As Joerg commented elsewhere, considering anything other than memory
resources isn't right (I appreciate you've merely copied my own mistake
here). We need some other way to handle root complexes where the CPU
MMIO views of PCI windows appear in PCI memory space - using the I/O
address of I/O resources only works by chance on Juno, and it still
doesn't account for config space. I suggest we just leave that out for
the time being to make life easier (does it even apply to anything other
than Juno?) and figure it out later.
> + continue;
> +
> + start = window->res->start - window->offset;
> + length = window->res->end - window->res->start + 1;
> + region = iommu_alloc_resv_region(start, length,
> + IOMMU_RESV_NOMAP);
> + if (!region)
> + return;
> + list_add_tail(®ion->list, head);
> + }
> +}
Either way, there's nothing SMMU-specific about PCI windows. The fact
that we'd have to copy-paste all of this into the SMMUv3 driver
unchanged suggests it should go somewhere common (although I would be
inclined to leave the insertion of the fake MSI region to driver-private
wrappers). As I said before, the current iova_reserve_pci_windows()
simply wants splitting into appropriate public callbacks for
get_resv_regions and apply_resv_regions.
Robin.
> +static void arm_smmu_put_resv_regions(struct device *dev,
> + struct list_head *head)
> +{
> + struct iommu_resv_region *entry, *next;
> +
> + list_for_each_entry_safe(entry, next, head, list)
> + kfree(entry);
> +}
> +
> static struct iommu_ops arm_smmu_ops = {
> .capable = arm_smmu_capable,
> .domain_alloc = arm_smmu_domain_alloc,
> @@ -1560,6 +1610,8 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
> .domain_get_attr = arm_smmu_domain_get_attr,
> .domain_set_attr = arm_smmu_domain_set_attr,
> .of_xlate = arm_smmu_of_xlate,
> + .get_resv_regions = arm_smmu_get_resv_regions,
> + .put_resv_regions = arm_smmu_put_resv_regions,
> .pgsize_bitmap = -1UL, /* Restricted during device attach */
> };
>
>
^ permalink raw reply
* [Question] New mmap64 syscall?
From: Yury Norov @ 2016-12-06 18:54 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
(Sorry if there is similar discussion, and I missed it. I didn't
find something in LKML in last half a year.)
In aarch64/ilp32 discussion Catalin wondered why we don't pass offset
in mmap() as 64-bit value (in 2 registers if needed). Looking at kernel
code I found that there's no generic interface for it. But almost all
architectures provide their own implementations, like this:
SYSCALL_DEFINE6(mips_mmap, unsigned long, addr, unsigned long, len,
unsigned long, prot, unsigned long, flags, unsigned long,
fd, off_t, offset)
{
unsigned long result;
result = -EINVAL;
if (offset & ~PAGE_MASK)
goto out;
result = sys_mmap_pgoff(addr, len, prot, flags, fd, offset >> PAGE_SHIFT);
out:
return result;
}
On glibc side things are even worse. There's no mmap() implementation
that allows to pass 64-bit offset in 32-bit architecture. mmap64() which
is supposed to do this is simply broken:
void *
__mmap64 (void *addr, size_t len, int prot, int flags, int fd, off64_t
offset)
{
[...]
void *result;
result = (void *) INLINE_SYSCALL (mmap2, 6, addr,
len, prot, flags, fd,
(off_t) (offset >> page_shift));
return result;
}
It explicitly declares offset as 64-bit value, but casts it to 32-bit
before passing to the kernel, which is wrong for me. Even if arch has
64-bit off_t, like aarch64/ilp32, the cast will take place because
offset is passed in a single register, which is 32-bit.
I see 3 solutions for my problem:
1. Reuse aarch64/lp64 mmap code for ilp32 in glibc, but wrap offset with
SYSCALL_LL64() macro - which converts offset to the pair for 32-bit
ports. This is simple but local solution. And most probably it's enough.
2. Add new flag to mmap, like MAP_OFFSET_IN_PAIR. This will also work.
The problem here is that there are too much arches that implement
their custom sys_mmap2(). And, of course, this type of flags is
looking ugly.
3. Introduce new mmap64() syscall like this:
sys_mmap64(void *addr, size_t len, int prot, int flags, int fd, struct off_pair *off);
(The pointer here because otherwise we have 7 args, if simply pass off_hi and
off_lo in registers.)
With new 64-bit interface we can deprecate mmap2(), and generalize all
implementations in kernel.
I think we can discuss it because 64-bit is the default size for off_t
in all new 32-bit architectures. So generic solution may take place.
The last question here is how important to support offsets bigger than
2^44 on 32-bit machines in practice? It may be a case for ARM64 servers,
which are looking like main aarch64/ilp32 users. If no, we can leave
things as is, and just do nothing.
Yury
On Mon, Dec 05, 2016 at 05:12:43PM +0000, Catalin Marinas wrote:
> On Fri, Oct 21, 2016 at 11:33:10PM +0300, Yury Norov wrote:
> > off_t is passed in register pair just like in aarch32.
> > In this patch corresponding aarch32 handlers are shared to
> > ilp32 code.
> [...]
> > +/*
> > + * Note: off_4k (w5) is always in units of 4K. If we can't do the
> > + * requested offset because it is not page-aligned, we return -EINVAL.
> > + */
> > +ENTRY(compat_sys_mmap2_wrapper)
> > +#if PAGE_SHIFT > 12
> > + tst w5, #~PAGE_MASK >> 12
> > + b.ne 1f
> > + lsr w5, w5, #PAGE_SHIFT - 12
> > +#endif
> > + b sys_mmap_pgoff
> > +1: mov x0, #-EINVAL
> > + ret
> > +ENDPROC(compat_sys_mmap2_wrapper)
>
> For compat sys_mmap2, the pgoff argument is in multiples of 4K. This was
> traditionally used for architectures where off_t is 32-bit to allow
> mapping files to 2^44.
>
> Since off_t is 64-bit with AArch64/ILP32, should we just pass the off_t
> as a 64-bit value in two different registers (w5 and w6)?
^ permalink raw reply
* [PATCH] arm64: Add CMDLINE_EXTEND
From: Geoff Levand @ 2016-12-06 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206122040.GH2498@arm.com>
Hi Will,
On 12/06/2016 04:20 AM, Will Deacon wrote:
> On Mon, Dec 05, 2016 at 09:41:06AM -0800, Geoff Levand wrote:
>> On 12/05/2016 04:08 AM, Catalin Marinas wrote:
>>> On Fri, Dec 02, 2016 at 02:17:02PM -0800, Geoff Levand wrote:
>>>> The device tree code already supports CMDLINE_EXTEND,
>>>> so add the config option to make it available on arm64.
>>>
>>> What's your use-case for this patch? Note that both CMDLINE_FORCE and
>>> CMDLINE_EXTEND (if we introduce it) are ignored by the EFI stub.
>>> However, we don't seem to have stated this anywhere.
>>
>> I use this in CoreOS, where we need to set "acpi=force" for
>> arm64. CoreOS uses a proper UEFI + grub.
>
> So why can't you just set that in grub if you want to boot with ACPI?
That is how I originally did it, but it was suggested I
do it in the kernel config. See:
https://github.com/coreos/scripts/pull/610
Is there any reason why we don't want arm64 to have
CMDLINE_EXTEND?
-Geoff
^ permalink raw reply
* next-20161205 build: 3 failures 4 warnings (next-20161205)
From: Marc Zyngier @ 2016-12-06 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206181050.GF30492@tuxbot>
On 06/12/16 18:10, Bjorn Andersson wrote:
> On Mon 05 Dec 07:44 PST 2016, Marc Zyngier wrote:
>
>> On 05/12/16 11:20, Mark Brown wrote:
>>> On Mon, Dec 05, 2016 at 07:56:06AM +0000, Build bot for Mark Brown wrote:
>>>
>>> Today's -next fails to build an arm64 allnodconfig and allmodconfig
>>> with:
>>>
>>>> arm64-allnoconfig
>>>> ../arch/arm64/lib/clear_user.S:33: Error: bad or irreducible absolute expression
>>>> ../arch/arm64/lib/clear_user.S:53: Error: bad or irreducible absolute expression
>>>> ../arch/arm64/lib/clear_user.S:33: Error: attempt to move .org backwards
>>>> ../arch/arm64/lib/clear_user.S:53: Error: attempt to move .org backwards
>>>> ../arch/arm64/lib/copy_from_user.S:67: Error: bad or irreducible absolute expression
>>>> ../arch/arm64/lib/copy_from_user.S:70: Error: bad or irreducible absolute expression
>>>> ../arch/arm64/lib/copy_from_user.S:67: Error: attempt to move .org backwards
>>>> ../arch/arm64/lib/copy_from_user.S:70: Error: attempt to move .org backwards
>>>> ../arch/arm64/lib/copy_in_user.S:68: Error: bad or irreducible absolute expression
>>>> ../arch/arm64/lib/copy_in_user.S:71: Error: bad or irreducible absolute expression
>>>> ../arch/arm64/lib/copy_in_user.S:68: Error: attempt to move .org backwards
>>>> ../arch/arm64/lib/copy_in_user.S:71: Error: attempt to move .org backwards
>>>> ../arch/arm64/lib/copy_to_user.S:66: Error: bad or irreducible absolute expression
>>>> ../arch/arm64/lib/copy_to_user.S:69: Error: bad or irreducible absolute expression
>>>> ../arch/arm64/lib/copy_to_user.S:66: Error: attempt to move .org backwards
>>>> ../arch/arm64/lib/copy_to_user.S:69: Error: attempt to move .org backwards
>>>
>>> This was triggered somehow by bca8f17f57bd7 (arm64: Get rid of
>>> asm/opcodes.h) though I didn't figure out how.
>>
>> Old and broken gas. I have a workaround stashed there:
>>
>> http://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=arm64/standalone.h&id=559f97365362ed9e96f594200020379df46630d8
>>
>> At least binutils 2.24 and 2.25 are affected, while 2.27 is not.
>>
>
> Made me realize that the Ubuntu 15.10 release I'm on is deprecated.
>
> If I read the release notes for Ubuntu correctly the 14.04 LTS release
> is supported until April 2019, with binutils 2.24. So I would be
> surprised if this won't bite quite a bunch of people down the road.
Catalin has taken a slightly different set of fixes which do address
this problem:
https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/commit/?h=for-next/core&id=bbb56c27228d4ad64aca858c5af49d0f2f11c645
https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/commit/?h=for-next/core&id=cd9e1927a525f6ce7c0d99c6e038f0a0b9e85176
The build system will warn you that your binutils are broken, and enable
the workaround (which will only result in slightly painful disassembly
for some instructions).
Some of the most visible distros have also other "features", such as
compilers that do not implement basic capabilities on which the kernel
relies for performance (jump labels, for example)...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCHv4 09/10] mm/usercopy: Switch to using lm_alias
From: Mark Rutland @ 2016-12-06 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480445729-27130-10-git-send-email-labbott@redhat.com>
On Tue, Nov 29, 2016 at 10:55:28AM -0800, Laura Abbott wrote:
>
> The usercopy checking code currently calls __va(__pa(...)) to check for
> aliases on symbols. Switch to using lm_alias instead.
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
I've given this a go on Juno, which boots happily. LKDTM triggers as
expected when copying from the kernel text and its alias.
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
> Found when reviewing the kernel. Tested.
> ---
> mm/usercopy.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/usercopy.c b/mm/usercopy.c
> index 3c8da0a..8345299 100644
> --- a/mm/usercopy.c
> +++ b/mm/usercopy.c
> @@ -108,13 +108,13 @@ static inline const char *check_kernel_text_object(const void *ptr,
> * __pa() is not just the reverse of __va(). This can be detected
> * and checked:
> */
> - textlow_linear = (unsigned long)__va(__pa(textlow));
> + textlow_linear = (unsigned long)lm_alias(textlow);
> /* No different mapping: we're done. */
> if (textlow_linear == textlow)
> return NULL;
>
> /* Check the secondary mapping... */
> - texthigh_linear = (unsigned long)__va(__pa(texthigh));
> + texthigh_linear = (unsigned long)lm_alias(texthigh);
> if (overlaps(ptr, n, textlow_linear, texthigh_linear))
> return "<linear kernel text>";
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCHv4 09/10] mm/usercopy: Switch to using lm_alias
From: Mark Rutland @ 2016-12-06 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jKrBc6R9JYay1L6pd958Vm5-6p=37tiUYgg6uPeZb1HtQ@mail.gmail.com>
On Tue, Nov 29, 2016 at 11:39:44AM -0800, Kees Cook wrote:
> On Tue, Nov 29, 2016 at 10:55 AM, Laura Abbott <labbott@redhat.com> wrote:
> >
> > The usercopy checking code currently calls __va(__pa(...)) to check for
> > aliases on symbols. Switch to using lm_alias instead.
> >
> > Signed-off-by: Laura Abbott <labbott@redhat.com>
>
> Acked-by: Kees Cook <keescook@chromium.org>
>
> I should probably add a corresponding alias test to lkdtm...
>
> -Kees
Something like the below?
It uses lm_alias(), so it depends on Laura's patches. We seem to do the
right thing, anyhow:
root at ribbensteg:/home/nanook# echo USERCOPY_KERNEL_ALIAS > /sys/kernel/debug/provoke-crash/DIRECT
[ 44.493400] usercopy: kernel memory exposure attempt detected from ffff80000031a730 (<linear kernel text>) (4096 bytes)
[ 44.504263] kernel BUG at mm/usercopy.c:75!
Thanks,
Mark.
---->8----
diff --git a/drivers/misc/lkdtm.h b/drivers/misc/lkdtm.h
index fdf954c..96d8d76 100644
--- a/drivers/misc/lkdtm.h
+++ b/drivers/misc/lkdtm.h
@@ -56,5 +56,6 @@
void lkdtm_USERCOPY_STACK_FRAME_FROM(void);
void lkdtm_USERCOPY_STACK_BEYOND(void);
void lkdtm_USERCOPY_KERNEL(void);
+void lkdtm_USERCOPY_KERNEL_ALIAS(void);
#endif
diff --git a/drivers/misc/lkdtm_core.c b/drivers/misc/lkdtm_core.c
index f9154b8..f6bc6d6 100644
--- a/drivers/misc/lkdtm_core.c
+++ b/drivers/misc/lkdtm_core.c
@@ -228,6 +228,7 @@ struct crashtype crashtypes[] = {
CRASHTYPE(USERCOPY_STACK_FRAME_FROM),
CRASHTYPE(USERCOPY_STACK_BEYOND),
CRASHTYPE(USERCOPY_KERNEL),
+ CRASHTYPE(USERCOPY_KERNEL_ALIAS),
};
diff --git a/drivers/misc/lkdtm_usercopy.c b/drivers/misc/lkdtm_usercopy.c
index 1dd6114..955f2dc 100644
--- a/drivers/misc/lkdtm_usercopy.c
+++ b/drivers/misc/lkdtm_usercopy.c
@@ -279,9 +279,16 @@ void lkdtm_USERCOPY_STACK_BEYOND(void)
do_usercopy_stack(true, false);
}
-void lkdtm_USERCOPY_KERNEL(void)
+static void do_usercopy_kernel(bool use_alias)
{
unsigned long user_addr;
+ const void *rodata = test_text;
+ void *text = vm_mmap;
+
+ if (use_alias) {
+ rodata = lm_alias(rodata);
+ text = lm_alias(text);
+ }
user_addr = vm_mmap(NULL, 0, PAGE_SIZE,
PROT_READ | PROT_WRITE | PROT_EXEC,
@@ -292,14 +299,14 @@ void lkdtm_USERCOPY_KERNEL(void)
}
pr_info("attempting good copy_to_user from kernel rodata\n");
- if (copy_to_user((void __user *)user_addr, test_text,
+ if (copy_to_user((void __user *)user_addr, rodata,
unconst + sizeof(test_text))) {
pr_warn("copy_to_user failed unexpectedly?!\n");
goto free_user;
}
pr_info("attempting bad copy_to_user from kernel text\n");
- if (copy_to_user((void __user *)user_addr, vm_mmap,
+ if (copy_to_user((void __user *)user_addr, text,
unconst + PAGE_SIZE)) {
pr_warn("copy_to_user failed, but lacked Oops\n");
goto free_user;
@@ -309,6 +316,16 @@ void lkdtm_USERCOPY_KERNEL(void)
vm_munmap(user_addr, PAGE_SIZE);
}
+void lkdtm_USERCOPY_KERNEL(void)
+{
+ do_usercopy_kernel(false);
+}
+
+void lkdtm_USERCOPY_KERNEL_ALIAS(void)
+{
+ do_usercopy_kernel(true);
+}
+
void __init lkdtm_usercopy_init(void)
{
/* Prepare cache that lacks SLAB_USERCOPY flag. */
^ permalink raw reply related
* [RFC v3 06/10] iommu: iommu_get_group_resv_regions
From: Robin Murphy @ 2016-12-06 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479215363-2898-7-git-send-email-eric.auger@redhat.com>
On 15/11/16 13:09, Eric Auger wrote:
> Introduce iommu_get_group_resv_regions whose role consists in
> enumerating all devices from the group and collecting their
> reserved regions. It checks duplicates.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> ---
>
> - we do not move list elements from device to group list since
> the iommu_put_resv_regions() could not be called.
> - at the moment I did not introduce any iommu_put_group_resv_regions
> since it simply consists in voiding/freeing the list
> ---
> drivers/iommu/iommu.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/iommu.h | 8 ++++++++
> 2 files changed, 61 insertions(+)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index a4530ad..e0fbcc5 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -133,6 +133,59 @@ static ssize_t iommu_group_show_name(struct iommu_group *group, char *buf)
> return sprintf(buf, "%s\n", group->name);
> }
>
> +static bool iommu_resv_region_present(struct iommu_resv_region *region,
> + struct list_head *head)
> +{
> + struct iommu_resv_region *entry;
> +
> + list_for_each_entry(entry, head, list) {
> + if ((region->start == entry->start) &&
> + (region->length == entry->length) &&
> + (region->prot == entry->prot))
> + return true;
> + }
> + return false;
> +}
> +
> +static int
> +iommu_insert_device_resv_regions(struct list_head *dev_resv_regions,
> + struct list_head *group_resv_regions)
> +{
> + struct iommu_resv_region *entry, *region;
> +
> + list_for_each_entry(entry, dev_resv_regions, list) {
> + if (iommu_resv_region_present(entry, group_resv_regions))
> + continue;
In the case of overlapping regions which _aren't_ an exact match, would
it be better to expand the existing one rather than leave the caller to
sort it out? It seems a bit inconsistent to handle only the one case here.
> + region = iommu_alloc_resv_region(entry->start, entry->length,
> + entry->prot);
> + if (!region)
> + return -ENOMEM;
> +
> + list_add_tail(®ion->list, group_resv_regions);
> + }
> + return 0;
> +}
> +
> +int iommu_get_group_resv_regions(struct iommu_group *group,
> + struct list_head *head)
> +{
> + struct iommu_device *device;
> + int ret = 0;
> +
> + list_for_each_entry(device, &group->devices, list) {
Should we not be taking the group mutex around this?
Robin.
> + struct list_head dev_resv_regions;
> +
> + INIT_LIST_HEAD(&dev_resv_regions);
> + iommu_get_resv_regions(device->dev, &dev_resv_regions);
> + ret = iommu_insert_device_resv_regions(&dev_resv_regions, head);
> + iommu_put_resv_regions(device->dev, &dev_resv_regions);
> + if (ret)
> + break;
> + }
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(iommu_get_group_resv_regions);
> +
> static IOMMU_GROUP_ATTR(name, S_IRUGO, iommu_group_show_name, NULL);
>
> static void iommu_group_release(struct kobject *kobj)
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 0aea877..0f7ae2c 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -243,6 +243,8 @@ extern void iommu_set_fault_handler(struct iommu_domain *domain,
> extern int iommu_request_dm_for_dev(struct device *dev);
> extern struct iommu_resv_region *
> iommu_alloc_resv_region(phys_addr_t start, size_t length, unsigned int prot);
> +extern int iommu_get_group_resv_regions(struct iommu_group *group,
> + struct list_head *head);
>
> extern int iommu_attach_group(struct iommu_domain *domain,
> struct iommu_group *group);
> @@ -462,6 +464,12 @@ static inline void iommu_put_resv_regions(struct device *dev,
> return NULL;
> }
>
> +static inline int iommu_get_group_resv_regions(struct iommu_group *group,
> + struct list_head *head)
> +{
> + return -ENODEV;
> +}
> +
> static inline int iommu_request_dm_for_dev(struct device *dev)
> {
> return -ENODEV;
>
^ permalink raw reply
* next-20161205 build: 3 failures 4 warnings (next-20161205)
From: Bjorn Andersson @ 2016-12-06 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7b3daf13-dbab-5acf-cd5f-2414141500b3@arm.com>
On Mon 05 Dec 07:44 PST 2016, Marc Zyngier wrote:
> On 05/12/16 11:20, Mark Brown wrote:
> > On Mon, Dec 05, 2016 at 07:56:06AM +0000, Build bot for Mark Brown wrote:
> >
> > Today's -next fails to build an arm64 allnodconfig and allmodconfig
> > with:
> >
> >> arm64-allnoconfig
> >> ../arch/arm64/lib/clear_user.S:33: Error: bad or irreducible absolute expression
> >> ../arch/arm64/lib/clear_user.S:53: Error: bad or irreducible absolute expression
> >> ../arch/arm64/lib/clear_user.S:33: Error: attempt to move .org backwards
> >> ../arch/arm64/lib/clear_user.S:53: Error: attempt to move .org backwards
> >> ../arch/arm64/lib/copy_from_user.S:67: Error: bad or irreducible absolute expression
> >> ../arch/arm64/lib/copy_from_user.S:70: Error: bad or irreducible absolute expression
> >> ../arch/arm64/lib/copy_from_user.S:67: Error: attempt to move .org backwards
> >> ../arch/arm64/lib/copy_from_user.S:70: Error: attempt to move .org backwards
> >> ../arch/arm64/lib/copy_in_user.S:68: Error: bad or irreducible absolute expression
> >> ../arch/arm64/lib/copy_in_user.S:71: Error: bad or irreducible absolute expression
> >> ../arch/arm64/lib/copy_in_user.S:68: Error: attempt to move .org backwards
> >> ../arch/arm64/lib/copy_in_user.S:71: Error: attempt to move .org backwards
> >> ../arch/arm64/lib/copy_to_user.S:66: Error: bad or irreducible absolute expression
> >> ../arch/arm64/lib/copy_to_user.S:69: Error: bad or irreducible absolute expression
> >> ../arch/arm64/lib/copy_to_user.S:66: Error: attempt to move .org backwards
> >> ../arch/arm64/lib/copy_to_user.S:69: Error: attempt to move .org backwards
> >
> > This was triggered somehow by bca8f17f57bd7 (arm64: Get rid of
> > asm/opcodes.h) though I didn't figure out how.
>
> Old and broken gas. I have a workaround stashed there:
>
> http://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=arm64/standalone.h&id=559f97365362ed9e96f594200020379df46630d8
>
> At least binutils 2.24 and 2.25 are affected, while 2.27 is not.
>
Made me realize that the Ubuntu 15.10 release I'm on is deprecated.
If I read the release notes for Ubuntu correctly the 14.04 LTS release
is supported until April 2019, with binutils 2.24. So I would be
surprised if this won't bite quite a bunch of people down the road.
Regards,
Bjorn
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox