Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 3/5] arm: decompressor: define a new zImage tag
From: Russell King - ARM Linux admin @ 2020-06-01 14:55 UTC (permalink / raw)
  To: Łukasz Stelmach
  Cc: Kees Cook, Bartlomiej Zolnierkiewicz, Masahiro Yamada,
	Nick Desaulniers, linux-kernel, AKASHI Takahiro, Ben Dooks,
	Thomas Gleixner, Enrico Weigelt, Ingo Molnar, linux-arm-kernel,
	Marek Szyprowski
In-Reply-To: <20200601142754.26139-4-l.stelmach@samsung.com>

On Mon, Jun 01, 2020 at 04:27:52PM +0200, Łukasz Stelmach wrote:
> Add DCSZ tag which holds dynamic memory (stack, bss, malloc pool)
> requirements of the decompressor code.

Why do we need to know the stack and BSS size, when the userspace
kexec tool doesn't need to know this to perform the same function.

> 
> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
> ---
>  arch/arm/boot/compressed/vmlinux.lds.S |  9 ++++++++-
>  arch/arm/include/asm/image.h           | 13 +++++++++++++
>  2 files changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/compressed/vmlinux.lds.S b/arch/arm/boot/compressed/vmlinux.lds.S
> index 308e9cd6a897..dcfdb3209c90 100644
> --- a/arch/arm/boot/compressed/vmlinux.lds.S
> +++ b/arch/arm/boot/compressed/vmlinux.lds.S
> @@ -39,6 +39,11 @@ SECTIONS
>      LONG(ARM_ZIMAGE_MAGIC3)
>      LONG(ZIMAGE_MAGIC(__piggy_size_addr - _start))
>      LONG(ZIMAGE_MAGIC(_kernel_bss_size))
> +    LONG(ZIMAGE_MAGIC(5))
> +    LONG(ARM_ZIMAGE_MAGIC4)
> +    LONG(ZIMAGE_MAGIC(_end - __bss_start))
> +    LONG(ZIMAGE_MAGIC(_stack_end - _stack_start))
> +    LONG(ZIMAGE_MAGIC(_malloc_size))
>      LONG(0)
>      _table_end = .;
>    }
> @@ -108,10 +113,12 @@ SECTIONS
>    . = BSS_START;
>    __bss_start = .;
>    .bss			: { *(.bss) }
> +  . = ALIGN(8);		/* the stack must be 64-bit aligned and adjoin bss */
>    _end = .;
>  
> -  . = ALIGN(8);		/* the stack must be 64-bit aligned */
> +  _stack_start = .;
>    .stack		: { *(.stack) }
> +  _stack_end = .;
>  
>    PROVIDE(__pecoff_data_size = ALIGN(512) - ADDR(.data));
>    PROVIDE(__pecoff_end = ALIGN(512));
> diff --git a/arch/arm/include/asm/image.h b/arch/arm/include/asm/image.h
> index d5c18a0f6a34..624438740f23 100644
> --- a/arch/arm/include/asm/image.h
> +++ b/arch/arm/include/asm/image.h
> @@ -15,6 +15,7 @@
>  #define ARM_ZIMAGE_MAGIC1 ZIMAGE_MAGIC(0x016f2818)
>  #define ARM_ZIMAGE_MAGIC2 (0x45454545)
>  #define ARM_ZIMAGE_MAGIC3 ZIMAGE_MAGIC(0x5a534c4b)
> +#define ARM_ZIMAGE_MAGIC4 ZIMAGE_MAGIC(0x5a534344)
>  
>  #ifndef __ASSEMBLY__
>  
> @@ -43,6 +44,18 @@ struct arm_zimage_tag {
>  	} u;
>  };
>  
> +struct arm_zimage_tag_dc {
> +	struct tag_header hdr;
> +	union {
> +#define ZIMAGE_TAG_DECOMP_SIZE ARM_ZIMAGE_MAGIC4
> +		struct zimage_decomp_size {
> +			__le32 bss_size;
> +			__le32 stack_size;
> +			__le32 malloc_size;
> +		} decomp_size;
> +	} u;
> +};
> +
>  #endif /* __ASSEMBLY__ */
>  
>  #endif /* __ASM_IMAGE_H */
> -- 
> 2.26.2
> 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up

_______________________________________________
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 4/5] arm: Add kexec_image_info
From: Russell King - ARM Linux admin @ 2020-06-01 14:56 UTC (permalink / raw)
  To: Łukasz Stelmach
  Cc: Kees Cook, Bartlomiej Zolnierkiewicz, Masahiro Yamada,
	Nick Desaulniers, linux-kernel, AKASHI Takahiro, Ben Dooks,
	Thomas Gleixner, Enrico Weigelt, Ingo Molnar, linux-arm-kernel,
	Marek Szyprowski
In-Reply-To: <20200601142754.26139-5-l.stelmach@samsung.com>

On Mon, Jun 01, 2020 at 04:27:53PM +0200, Łukasz Stelmach wrote:
> Add kexec_image_info to print detailed information about a kexec image.

Isn't this already visible through kexec debugging?  Why do we need
to duplicate the same output in the kernel?  Do we think that the
kexec interfaces are that fragile that they don't work?

> 
> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
> ---
>  arch/arm/kernel/machine_kexec.c | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> index 76300f3813e8..c10a2dfd53d1 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -31,6 +31,32 @@ extern unsigned long kexec_boot_atags;
>  
>  static atomic_t waiting_for_crash_ipi;
>  
> +/**
> + * kexec_image_info - For debugging output.
> + */
> +#define kexec_image_info(_i) _kexec_image_info(__func__, __LINE__, _i)
> +static void _kexec_image_info(const char *func, int line,
> +	const struct kimage *kimage)
> +{
> +	unsigned long i;
> +
> +	pr_debug("%s:%d:\n", func, line);
> +	pr_debug("  kexec kimage info:\n");
> +	pr_debug("    type:        %d\n", kimage->type);
> +	pr_debug("    start:       %lx\n", kimage->start);
> +	pr_debug("    head:        %lx\n", kimage->head);
> +	pr_debug("    nr_segments: %lu\n", kimage->nr_segments);
> +
> +	for (i = 0; i < kimage->nr_segments; i++) {
> +		pr_debug("      segment[%lu]: %08lx - %08lx, 0x%x bytes, %lu pages\n",
> +			i,
> +			kimage->segment[i].mem,
> +			kimage->segment[i].mem + kimage->segment[i].memsz,
> +			kimage->segment[i].memsz,
> +			kimage->segment[i].memsz /  PAGE_SIZE);
> +	}
> +}
> +
>  /*
>   * Provide a dummy crash_notes definition while crash dump arrives to arm.
>   * This prevents breakage of crash_notes attribute in kernel/ksysfs.c.
> @@ -42,6 +68,8 @@ int machine_kexec_prepare(struct kimage *image)
>  	__be32 header;
>  	int i, err;
>  
> +	kexec_image_info(image);
> +
>  	image->arch.kernel_r2 = image->start - KEXEC_ARM_ZIMAGE_OFFSET
>  				     + KEXEC_ARM_ATAGS_OFFSET;
>  
> -- 
> 2.26.2
> 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up

_______________________________________________
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/5] arm: decompressor: set malloc pool size for the decompressor
From: Lukasz Stelmach @ 2020-06-01 14:56 UTC (permalink / raw)
  To: Russell King - ARM Linux admin
  Cc: Kees Cook, Bartlomiej Zolnierkiewicz, Masahiro Yamada,
	Nick Desaulniers, linux-kernel, AKASHI Takahiro, Ben Dooks,
	Thomas Gleixner, Enrico Weigelt, Ingo Molnar, linux-arm-kernel,
	Marek Szyprowski
In-Reply-To: <20200601144607.GI1551@shell.armlinux.org.uk>


[-- Attachment #1.1: Type: text/plain, Size: 2194 bytes --]

It was <2020-06-01 pon 15:46>, when Russell King - ARM Linux admin wrote:
> On Mon, Jun 01, 2020 at 04:27:50PM +0200, Łukasz Stelmach wrote:
>> Move the definition of malloc pool size of the decompressor to
>> a single place. This value will be exposed later for kexec_file loader.
>> 
>> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
>> ---
>>  arch/arm/boot/compressed/Makefile | 2 ++
>>  arch/arm/boot/compressed/head.S   | 6 ++++--
>>  2 files changed, 6 insertions(+), 2 deletions(-)
>> 
>> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
>> index 9c11e7490292..b3594cd1588c 100644
>> --- a/arch/arm/boot/compressed/Makefile
>> +++ b/arch/arm/boot/compressed/Makefile
>> @@ -125,6 +125,8 @@ KBSS_SZ = $(shell echo $$(($$($(NM) $(obj)/../../../../vmlinux | \
>>  		sed -n -e 's/^\([^ ]*\) [AB] __bss_start$$/-0x\1/p' \
>>  		       -e 's/^\([^ ]*\) [AB] __bss_stop$$/+0x\1/p') )) )
>>  LDFLAGS_vmlinux = --defsym _kernel_bss_size=$(KBSS_SZ)
>> +# malloc pool size
>> +LDFLAGS_vmlinux += --defsym _malloc_size=0x10000
>>  # Supply ZRELADDR to the decompressor via a linker symbol.
>>  ifneq ($(CONFIG_AUTO_ZRELADDR),y)
>>  LDFLAGS_vmlinux += --defsym zreladdr=$(ZRELADDR)
>> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
>> index e8e1c866e413..dcc1afa60fb9 100644
>> --- a/arch/arm/boot/compressed/head.S
>> +++ b/arch/arm/boot/compressed/head.S
>> @@ -309,7 +309,8 @@ restart:	adr	r0, LC0
>>  #ifndef CONFIG_ZBOOT_ROM
>>  		/* malloc space is above the relocated stack (64k max) */
>>  		add	sp, sp, r0
>> -		add	r10, sp, #0x10000
>> +		ldr	r10, =_malloc_size
>> +		add	r10, r10, sp
>
> This says "locate _malloc_size in a literal pool somewhere, and load it
> using a PC-relative offset".  Are you sure that the literal pool is
> sensibly located?
>
> Would it be better to use a definition for this?

I've followed ZRELADDR way. I think both values should be handled the
same way (it makes it easier to comprehend IMHO). Is there any reason
not to?  Should I change ZRELADDR for v2 too?

-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 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: [RFC PATCH v3 2/2] arm64: tlb: Use the TLBI RANGE feature in arm64
From: Zhenyu Ye @ 2020-06-01 14:57 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: linux-arch, suzuki.poulose, maz, linux-kernel, xiexiangyou,
	steven.price, zhangshaokun, linux-mm, arm, prime.zeng, guohanjun,
	olof, kuhn.chenqun, will, linux-arm-kernel
In-Reply-To: <20200520170759.GE18302@gaia>

Hi Catalin,

I have sent the v4 of this series [1] and combine the two function with
a single loop.  See codes for details.

[1] https://lore.kernel.org/linux-arm-kernel/20200601144713.2222-1-yezhenyu2@huawei.com/

On 2020/5/21 1:08, Catalin Marinas wrote:
>> This optimization is only effective when the range is a multiple of 256KB
>> (when the page size is 4KB), and I'm worried about the performance
>> of ilog2().  I traced the __flush_tlb_range() last year and found that in
>> most cases the range is less than 256K (see details in [1]).
> 
> THP or hugetlbfs would exercise bigger strides but I guess it depends on
> the use-case. ilog2() should be reduced to a few instructions on arm64
> AFAICT (haven't tried but it should use the CLZ instruction).
> 

Not bigger than 256K, but the range must be a integer multiple of 256KB,
so I still start from scale 0.

Thanks,
Zhenyu


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v2 1/2] dt-bindings: arm: fsl: Add MYiR Tech boards
From: Parthiban Nallathambi @ 2020-06-01 14:58 UTC (permalink / raw)
  To: m.felsch, shawnguo, robh+dt, s.hauer
  Cc: devicetree, Parthiban Nallathambi, linux-kernel, linux-imx,
	kernel, festevam, linux-arm-kernel

Add entries for MYiR Tech imx6ULL eval boards.

Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index cd3fbe7e3948..592d73187da4 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -264,6 +264,8 @@ properties:
               - armadeus,imx6ull-opos6uldev # OPOS6UL (i.MX6ULL) SoM on OPOS6ULDev board
               - fsl,imx6ull-14x14-evk     # i.MX6 UltraLiteLite 14x14 EVK Board
               - kontron,imx6ull-n6411-som # Kontron N6411 SOM
+              - myir,imx6ull-mys-6ulx # MYiR Tech iMX6ULL Evaluation Board
+              - myir,imx6ull-mys-6ulx-nand # MYiR Tech iMX6ULL Evaluation Board with NAND
               - toradex,colibri-imx6ull-eval            # Colibri iMX6ULL Module on Colibri Evaluation Board
               - toradex,colibri-imx6ull-wifi-eval       # Colibri iMX6ULL Wi-Fi / Bluetooth Module on Colibri Evaluation Board
           - const: fsl,imx6ull
-- 
2.26.2


_______________________________________________
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 v2 2/2] ARM: dts: imx6ull: add MYiR MYS-6ULX SBC
From: Parthiban Nallathambi @ 2020-06-01 14:58 UTC (permalink / raw)
  To: m.felsch, shawnguo, robh+dt, s.hauer
  Cc: devicetree, Parthiban Nallathambi, linux-kernel, linux-imx,
	kernel, festevam, linux-arm-kernel
In-Reply-To: <20200601145857.5658-1-parthiban@linumiz.com>

Add support for the MYiR imx6ULL based single board computer
equipped with on board 256MB NAND & RAM. The board also
provides expansion header for expansion board, but this
commit adds only support for SBC.

Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>
---

Notes:
    Changelog v2:
    - moved regulator under root node
    - status property removed

 arch/arm/boot/dts/Makefile                    |   1 +
 .../boot/dts/imx6ull-myir-mys-6ulx-nand.dts   |  19 ++
 arch/arm/boot/dts/imx6ull-myir-mys-6ulx.dtsi  | 238 ++++++++++++++++++
 3 files changed, 258 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6ull-myir-mys-6ulx-nand.dts
 create mode 100644 arch/arm/boot/dts/imx6ull-myir-mys-6ulx.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e8dd99201397..eab86051d782 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -612,6 +612,7 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
 	imx6ull-14x14-evk.dtb \
 	imx6ull-colibri-eval-v3.dtb \
 	imx6ull-colibri-wifi-eval-v3.dtb \
+	imx6ull-myir-mys-6ulx-nand.dtb \
 	imx6ull-opos6uldev.dtb \
 	imx6ull-phytec-segin-ff-rdk-nand.dtb \
 	imx6ull-phytec-segin-ff-rdk-emmc.dtb \
diff --git a/arch/arm/boot/dts/imx6ull-myir-mys-6ulx-nand.dts b/arch/arm/boot/dts/imx6ull-myir-mys-6ulx-nand.dts
new file mode 100644
index 000000000000..43e072671ca4
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull-myir-mys-6ulx-nand.dts
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Linumiz
+ * Author: Parthiban Nallathambi <parthiban@linumiz.com>
+ */
+
+/dts-v1/;
+#include "imx6ull.dtsi"
+#include "imx6ull-myir-mys-6ulx.dtsi"
+
+/ {
+	model = "MYiR i.MX6ULL MYS-6ULX Single Board Computer with NAND";
+	compatible = "myir,imx6ull-mys-6ulx-nand", "myir,imx6ull-mys-6ulx",
+		     "fsl,imx6ull";
+};
+
+&gpmi {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6ull-myir-mys-6ulx.dtsi b/arch/arm/boot/dts/imx6ull-myir-mys-6ulx.dtsi
new file mode 100644
index 000000000000..03365a1ca8e6
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull-myir-mys-6ulx.dtsi
@@ -0,0 +1,238 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Linumiz
+ * Author: Parthiban Nallathambi <parthiban@linumiz.com>
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pwm/pwm.h>
+
+/ {
+	model = "MYiR MYS-6ULX Single Board Computer";
+	compatible = "myir,imx6ull-mys-6ulx", "fsl,imx6ull";
+
+	chosen {
+		stdout-path = &uart1;
+	};
+
+	reg_vdd_5v: regulator-vdd-5v {
+		compatible = "regulator-fixed";
+		regulator-name = "VDD_5V";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	reg_vdd_3v3: regulator-vdd-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "VDD_3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		vin-supply = <&reg_vdd_5v>;
+	};
+};
+
+&fec1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet1>;
+	phy-mode = "rmii";
+	phy-handle = <&ethphy0>;
+	phy-supply = <&reg_vdd_3v3>;
+	status = "okay";
+
+	mdio: mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ethphy0: ethernet-phy@0 {
+			reg = <0>;
+			interrupt-parent = <&gpio5>;
+			interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+			clocks = <&clks IMX6UL_CLK_ENET_REF>;
+			clock-names = "rmii-ref";
+		};
+	};
+};
+
+&gpmi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_gpmi_nand>;
+	nand-on-flash-bbt;
+	status = "disabled";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1>;
+	status = "okay";
+};
+
+&usbotg1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usb_otg1_id>;
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&usbotg2 {
+	dr_mode = "host";
+	disable-over-current;
+	status = "okay";
+};
+
+&usdhc1 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+	pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+	cd-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
+	no-1-8-v;
+	keep-power-in-suspend;
+	wakeup-source;
+	vmmc-supply = <&reg_vdd_3v3>;
+	status = "okay";
+};
+
+&usdhc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc2>;
+	pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
+	pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
+	bus-width = <8>;
+	non-removable;
+	keep-power-in-suspend;
+	vmmc-supply = <&reg_vdd_3v3>;
+};
+
+&iomuxc {
+	pinctrl_enet1: enet1grp {
+		fsl,pins = <
+			MX6UL_PAD_GPIO1_IO06__ENET1_MDIO	0x1b0b0
+			MX6UL_PAD_GPIO1_IO07__ENET1_MDC		0x1b0b0
+			MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN	0x1b0b0
+			MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER	0x1b0b0
+			MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00	0x1b0b0
+			MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01	0x1b0b0
+			MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN	0x1b0b0
+			MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00	0x1b0b0
+			MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01	0x1b0b0
+			MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1	0x4001b031
+			MX6UL_PAD_SNVS_TAMPER5__GPIO5_IO05	0x1b0b0
+		>;
+	};
+
+	pinctrl_gpmi_nand: gpminandgrp {
+		fsl,pins = <
+			MX6UL_PAD_NAND_CLE__RAWNAND_CLE		0x0b0b1
+			MX6UL_PAD_NAND_ALE__RAWNAND_ALE		0x0b0b1
+			MX6UL_PAD_NAND_WP_B__RAWNAND_WP_B	0x0b0b1
+			MX6UL_PAD_NAND_READY_B__RAWNAND_READY_B	0x0b000
+			MX6UL_PAD_NAND_CE0_B__RAWNAND_CE0_B	0x0b0b1
+			MX6UL_PAD_NAND_RE_B__RAWNAND_RE_B	0x0b0b1
+			MX6UL_PAD_NAND_WE_B__RAWNAND_WE_B	0x0b0b1
+			MX6UL_PAD_NAND_DATA00__RAWNAND_DATA00	0x0b0b1
+			MX6UL_PAD_NAND_DATA01__RAWNAND_DATA01	0x0b0b1
+			MX6UL_PAD_NAND_DATA02__RAWNAND_DATA02	0x0b0b1
+			MX6UL_PAD_NAND_DATA03__RAWNAND_DATA03	0x0b0b1
+			MX6UL_PAD_NAND_DATA04__RAWNAND_DATA04	0x0b0b1
+			MX6UL_PAD_NAND_DATA05__RAWNAND_DATA05	0x0b0b1
+			MX6UL_PAD_NAND_DATA06__RAWNAND_DATA06	0x0b0b1
+			MX6UL_PAD_NAND_DATA07__RAWNAND_DATA07	0x0b0b1
+		>;
+	};
+
+	pinctrl_uart1: uart1grp {
+		fsl,pins = <
+			MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX	0x1b0b1
+			MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX	0x1b0b1
+		>;
+	};
+
+	pinctrl_usb_otg1_id: usbotg1idgrp {
+		fsl,pins = <
+			MX6UL_PAD_GPIO1_IO00__ANATOP_OTG1_ID	0x17059
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			MX6UL_PAD_SD1_CMD__USDHC1_CMD		0x17059
+			MX6UL_PAD_SD1_CLK__USDHC1_CLK		0x10059
+			MX6UL_PAD_SD1_DATA0__USDHC1_DATA0	0x17059
+			MX6UL_PAD_SD1_DATA1__USDHC1_DATA1	0x17059
+			MX6UL_PAD_SD1_DATA2__USDHC1_DATA2	0x17059
+			MX6UL_PAD_SD1_DATA3__USDHC1_DATA3	0x17059
+			MX6UL_PAD_UART1_RTS_B__GPIO1_IO19	0x17059
+		>;
+	};
+
+	pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
+		fsl,pins = <
+			MX6UL_PAD_SD1_CMD__USDHC1_CMD		0x170b9
+			MX6UL_PAD_SD1_CLK__USDHC1_CLK		0x100b9
+			MX6UL_PAD_SD1_DATA0__USDHC1_DATA0	0x170b9
+			MX6UL_PAD_SD1_DATA1__USDHC1_DATA1	0x170b9
+			MX6UL_PAD_SD1_DATA2__USDHC1_DATA2	0x170b9
+			MX6UL_PAD_SD1_DATA3__USDHC1_DATA3	0x170b9
+		>;
+	};
+
+	pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+		fsl,pins = <
+			MX6UL_PAD_SD1_CMD__USDHC1_CMD		0x170f9
+			MX6UL_PAD_SD1_CLK__USDHC1_CLK		0x100f9
+			MX6UL_PAD_SD1_DATA0__USDHC1_DATA0	0x170f9
+			MX6UL_PAD_SD1_DATA1__USDHC1_DATA1	0x170f9
+			MX6UL_PAD_SD1_DATA2__USDHC1_DATA2	0x170f9
+			MX6UL_PAD_SD1_DATA3__USDHC1_DATA3	0x170f9
+		>;
+	};
+
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			MX6UL_PAD_NAND_RE_B__USDHC2_CLK		0x10069
+			MX6UL_PAD_NAND_WE_B__USDHC2_CMD		0x17059
+			MX6UL_PAD_NAND_DATA00__USDHC2_DATA0	0x17059
+			MX6UL_PAD_NAND_DATA01__USDHC2_DATA1	0x17059
+			MX6UL_PAD_NAND_DATA02__USDHC2_DATA2	0x17059
+			MX6UL_PAD_NAND_DATA03__USDHC2_DATA3	0x17059
+			MX6UL_PAD_NAND_DATA04__USDHC2_DATA4	0x17059
+			MX6UL_PAD_NAND_DATA05__USDHC2_DATA5	0x17059
+			MX6UL_PAD_NAND_DATA06__USDHC2_DATA6	0x17059
+			MX6UL_PAD_NAND_DATA07__USDHC2_DATA7	0x17059
+		>;
+	};
+
+	pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+		fsl,pins = <
+			MX6UL_PAD_NAND_RE_B__USDHC2_CLK		0x100b9
+			MX6UL_PAD_NAND_WE_B__USDHC2_CMD		0x170b9
+			MX6UL_PAD_NAND_DATA00__USDHC2_DATA0	0x170b9
+			MX6UL_PAD_NAND_DATA01__USDHC2_DATA1	0x170b9
+			MX6UL_PAD_NAND_DATA02__USDHC2_DATA2	0x170b9
+			MX6UL_PAD_NAND_DATA03__USDHC2_DATA3	0x170b9
+			MX6UL_PAD_NAND_DATA04__USDHC2_DATA4	0x170b9
+			MX6UL_PAD_NAND_DATA05__USDHC2_DATA5	0x170b9
+			MX6UL_PAD_NAND_DATA06__USDHC2_DATA6	0x170b9
+			MX6UL_PAD_NAND_DATA07__USDHC2_DATA7	0x170b9
+		>;
+	};
+
+	pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+		fsl,pins = <
+			MX6UL_PAD_NAND_RE_B__USDHC2_CLK		0x100f9
+			MX6UL_PAD_NAND_WE_B__USDHC2_CMD		0x170f9
+			MX6UL_PAD_NAND_DATA00__USDHC2_DATA0	0x170f9
+			MX6UL_PAD_NAND_DATA01__USDHC2_DATA1	0x170f9
+			MX6UL_PAD_NAND_DATA02__USDHC2_DATA2	0x170f9
+			MX6UL_PAD_NAND_DATA03__USDHC2_DATA3	0x170f9
+			MX6UL_PAD_NAND_DATA04__USDHC2_DATA4	0x170f9
+			MX6UL_PAD_NAND_DATA05__USDHC2_DATA5	0x170f9
+			MX6UL_PAD_NAND_DATA06__USDHC2_DATA6	0x170f9
+			MX6UL_PAD_NAND_DATA07__USDHC2_DATA7	0x170f9
+		>;
+	};
+};
-- 
2.26.2


_______________________________________________
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: [PATCH v4 11/26] arm64: mte: Add PROT_MTE support to mmap() and mprotect()
From: Dave Martin @ 2020-06-01 15:04 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: linux-arch, nd, Szabolcs Nagy, Andrey Konovalov, Kevin Brodsky,
	Peter Collingbourne, linux-mm, Evgenii Stepanov,
	Vincenzo Frascino, Will Deacon, Linux ARM
In-Reply-To: <20200601144544.GC23419@gaia>

On Mon, Jun 01, 2020 at 03:45:45PM +0100, Catalin Marinas wrote:
> On Mon, Jun 01, 2020 at 09:55:38AM +0100, Dave P Martin wrote:
> > On Thu, May 28, 2020 at 05:34:13PM +0100, Catalin Marinas wrote:
> > > On Thu, May 28, 2020 at 12:05:09PM +0100, Szabolcs Nagy wrote:
> > > > The 05/28/2020 10:14, Catalin Marinas wrote:
> > > > > On Wed, May 27, 2020 at 11:57:39AM -0700, Peter Collingbourne wrote:
> > > > > > Should the userspace stack always be mapped as if with PROT_MTE if the
> > > > > > hardware supports it? Such a change would be invisible to non-MTE
> > > > > > aware userspace since it would already need to opt in to tag checking
> > > > > > via prctl. This would let userspace avoid a complex stack
> > > > > > initialization sequence when running with stack tagging enabled on the
> > > > > > main thread.
> > > > > 
> > > > > I don't think the stack initialisation is that difficult. On program
> > > > > startup (can be the dynamic loader). Something like (untested):
> > > > > 
> > > > > 	register unsigned long stack asm ("sp");
> > > > > 	unsigned long page_sz = sysconf(_SC_PAGESIZE);
> > > > > 
> > > > > 	mprotect((void *)(stack & ~(page_sz - 1)), page_sz,
> > > > > 		 PROT_READ | PROT_WRITE | PROT_MTE | PROT_GROWSDOWN);
> > > > > 
> > > > > (the essential part it PROT_GROWSDOWN so that you don't have to specify
> > > > > a stack lower limit)
> > > > 
> > > > does this work even if the currently mapped stack is more than page_sz?
> > > > determining the mapped main stack area is i think non-trivial to do in
> > > > userspace (requires parsing /proc/self/maps or similar).
> > > 
> > > Because of PROT_GROWSDOWN, the kernel adjusts the start of the range
> > > down automatically. It is potentially problematic if the top of the
> > > stack is more than a page away and you want the whole stack coloured. I
> > > haven't run a test but my reading of the kernel code is that the stack
> > > vma would be split in this scenario, so the range beyond sp+page_sz
> > > won't have PROT_MTE set.
> > > 
> > > My assumption is that if you do this during program start, the stack is
> > > smaller than a page. Alternatively, could we use argv or envp to
> > > determine the top of the user stack (the bottom is taken care of by the
> > > kernel)?
> > 
> > I don't think you can easily know when the stack ends, but perhaps it
> > doesn't matter.
> > 
> > From memory, the initial stack looks like:
> > 
> > 	argv/env strings
> > 	AT_NULL
> > 	auxv
> > 	NULL
> > 	env
> > 	NULL
> > 	argv
> > 	argc	<--- sp
> > 
> > If we don't care about tagging the strings correctly, we could step to
> > the end of auxv and tag down from there.
> > 
> > If we do care about tagging the strings, there's probably no good way
> > to find the end of the string area, other than looking up sp in
> > /proc/self/maps.  I'm not sure we should trust all past and future
> > kernels to spit out the strings in a predictable order.
> 
> I don't think we care about tagging whatever the kernel places on the
> stack since the argv/envp pointers are untagged. An mprotect(PROT_MTE)
> may or may not cover the environment but it shouldn't matter as the
> kernel clears the tags on the corresponding pages anyway.

We have no match-all tag, right?  So we do rely on the tags being
cleared for the initial stack contents so that using untagged pointers
to access it works.

> AFAIK stack tagging works by colouring a stack frame on function entry
> and clearing the tags on return. We would only hit a problem if the
> function issuing mprotect(sp, PROT_MTE) on and its callers already
> assumed a PROT_MTE stack. Without PROT_MTE, an STG would be
> write-ignore, so subsequently turning it on would lead to a mismatch
> between the pointer and the allocation tags.
> 
> So PROT_MTE turning on should happen very early in the user process
> startup code before any code with stack tagging enabled. Whether you
> reach the top of the stack with such mprotect() doesn't really matter
> since up to that point there should not be any use of stack tagging. If
> that's not possible, for example the glibc code setting up the stack was
> compiled to stack tagging itself, the kernel would have to enable it
> when the user process starts. However, I'd only do this based on some
> ELF note.

Sounds fair.

This early on, the process shouldn't be exposed to arbitrary, untrusted
data.  So it's probably not a problem that tagging isn't turned on right
from the start.

Cheers
---Dave

_______________________________________________
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 v8 2/3] perf auxtrace: Add four itrace options
From: Arnaldo Carvalho de Melo @ 2020-06-01 15:06 UTC (permalink / raw)
  To: Adrian Hunter
  Cc: Mark Rutland, Ian Rogers, Andi Kleen, Al Grant, Mathieu Poirier,
	Alexander Shishkin, Will Deacon, Tan Xiaojun, linux-kernel,
	Peter Zijlstra, Jin Yao, Ingo Molnar, James Clark, Leo Yan,
	Namhyung Kim, Thomas Gleixner, Jiri Olsa, linux-arm-kernel,
	Mike Leach
In-Reply-To: <aaacf3f6-daab-098e-d1fb-1509e1cf9c84@intel.com>

Em Mon, Jun 01, 2020 at 10:24:00AM +0300, Adrian Hunter escreveu:
> On 30/05/20 3:24 pm, Leo Yan wrote:
> > From: Tan Xiaojun <tanxiaojun@huawei.com>
> > 
> > This patch is to add four options to synthesize events which are
> > described as below:
> > 
> >  'f': synthesize first level cache events
> >  'm': synthesize last level cache events
> >  't': synthesize TLB events
> >  'a': synthesize remote access events
> > 
> > This four options will be used by ARM SPE as their first consumer.
> > 
> > Signed-off-by: Tan Xiaojun <tanxiaojun@huawei.com>
> > Signed-off-by: James Clark <james.clark@arm.com>
> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
> > Tested-by: James Clark <james.clark@arm.com>
> 
> Acked-by: Adrian Hunter <adrian.hunter@intel.com>

Thanks a lot!

- Arnaldo

_______________________________________________
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 5/5] arm: kexec_file: load zImage or uImage, initrd and dtb
From: Russell King - ARM Linux admin @ 2020-06-01 15:07 UTC (permalink / raw)
  To: Łukasz Stelmach
  Cc: Kees Cook, Bartlomiej Zolnierkiewicz, Masahiro Yamada,
	Nick Desaulniers, linux-kernel, AKASHI Takahiro, Ben Dooks,
	Thomas Gleixner, Enrico Weigelt, Ingo Molnar, linux-arm-kernel,
	Marek Szyprowski
In-Reply-To: <20200601142754.26139-6-l.stelmach@samsung.com>

On Mon, Jun 01, 2020 at 04:27:54PM +0200, Łukasz Stelmach wrote:
> This is kexec_file_load implementation for ARM. It loads zImage and
> initrd from file descripters and resuses DTB.
> 
> Most code is derived from arm64 kexec_file_load implementation
> and from kexec-tools.

Please make the uImage loader able to be configured out of the
kernel; it's a legacy image format now, and some of us just don't
use it anymore.  That way, those who wish to have it can, and
those who wish not to can have a smaller kernel.

> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
> ---
>  arch/arm/Kconfig                     |  15 ++
>  arch/arm/include/asm/image.h         |  26 ++++
>  arch/arm/include/asm/kexec.h         |  14 ++
>  arch/arm/kernel/Makefile             |   5 +-
>  arch/arm/kernel/kexec_uimage.c       |  80 ++++++++++
>  arch/arm/kernel/kexec_zimage.c       | 199 +++++++++++++++++++++++++
>  arch/arm/kernel/machine_kexec.c      |  11 +-
>  arch/arm/kernel/machine_kexec_file.c | 209 +++++++++++++++++++++++++++
>  8 files changed, 554 insertions(+), 5 deletions(-)
>  create mode 100644 arch/arm/kernel/kexec_uimage.c
>  create mode 100644 arch/arm/kernel/kexec_zimage.c
>  create mode 100644 arch/arm/kernel/machine_kexec_file.c
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index c77c93c485a0..6adb849cb304 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1917,6 +1917,21 @@ config KEXEC
>  	  is properly shutdown, so do not be surprised if this code does not
>  	  initially work for you.
>  
> +config KEXEC_FILE
> +	bool "Kexec file based system call (EXPERIMENTAL)"
> +	depends on (!SMP || PM_SLEEP_SMP)
> +	depends on USE_OF
> +	select KEXEC_CORE
> +	select CRC32
> +	help
> +	  This is new version of kexec system call. This system call is
> +	  file based and takes file descriptors as system call argument
> +	  for kernel and initramfs as opposed to list of segments as
> +	  accepted by previous system call.
> +
> +	  The kernel to be loaded MUST support Flattened Device Tree
> +	  (selected with CONFIG_USE_OF).
> +
>  config ATAGS_PROC
>  	bool "Export atags in procfs"
>  	depends on ATAGS && KEXEC
> diff --git a/arch/arm/include/asm/image.h b/arch/arm/include/asm/image.h
> index 624438740f23..95f23837b04f 100644
> --- a/arch/arm/include/asm/image.h
> +++ b/arch/arm/include/asm/image.h
> @@ -8,8 +8,13 @@
>  			 (((x) >>  8) & 0x0000ff00) |  \
>  			 (((x) <<  8) & 0x00ff0000) |  \
>  			 (((x) << 24) & 0xff000000))
> +#define UIMAGE_MAGIC(x) (x)
>  #else
>  #define ZIMAGE_MAGIC(x) (x)
> +#define UIMAGE_MAGIC(x) ((((x) >> 24) & 0x000000ff) | \
> +			 (((x) >>  8) & 0x0000ff00) |  \
> +			 (((x) <<  8) & 0x00ff0000) |  \
> +			 (((x) << 24) & 0xff000000))
>  #endif
>  
>  #define ARM_ZIMAGE_MAGIC1 ZIMAGE_MAGIC(0x016f2818)
> @@ -17,6 +22,12 @@
>  #define ARM_ZIMAGE_MAGIC3 ZIMAGE_MAGIC(0x5a534c4b)
>  #define ARM_ZIMAGE_MAGIC4 ZIMAGE_MAGIC(0x5a534344)
>  
> +#define ARM_UIMAGE_MAGIC UIMAGE_MAGIC(0x27051956)
> +#define ARM_UIMAGE_NAME_LEN		32
> +#define ARM_UIMAGE_TYPE_KERNEL		2
> +#define ARM_UIMAGE_TYPE_KERNEL_NOLOAD	14
> +#define ARM_UIMAGE_ARCH_ARM		2
> +
>  #ifndef __ASSEMBLY__
>  
>  #include <linux/types.h>
> @@ -33,6 +44,21 @@ struct arm_zimage_header {
>  	__le32 extension_tag_offset;
>  };
>  
> +struct arm_uimage_header {
> +	__be32 magic;
> +	__be32 hdr_crc;
> +	__be32 time;
> +	__be32 size;
> +	__be32 load;
> +	__be32 entry;
> +	__be32 crc;
> +	__u8   os;
> +	__u8   arch;
> +	__u8   type;
> +	__u8   comp;
> +	__u8   name[ARM_UIMAGE_NAME_LEN];
> +};
> +
>  struct arm_zimage_tag {
>  	struct tag_header hdr;
>  	union {
> diff --git a/arch/arm/include/asm/kexec.h b/arch/arm/include/asm/kexec.h
> index 22751b5b5735..fda35afa7195 100644
> --- a/arch/arm/include/asm/kexec.h
> +++ b/arch/arm/include/asm/kexec.h
> @@ -83,6 +83,20 @@ static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
>  }
>  #define boot_pfn_to_page boot_pfn_to_page
>  
> +#ifdef CONFIG_KEXEC_FILE
> +
> +extern const struct kexec_file_ops kexec_zimage_ops;
> +extern const struct kexec_file_ops kexec_uimage_ops;
> +
> +struct kimage;
> +
> +extern int load_other_segments(struct kimage *image,
> +		unsigned long kernel_load_addr, unsigned long kernel_size,
> +		char *initrd, unsigned long initrd_len,
> +		unsigned long initrd_offset, char *cmdline);
> +
> +#endif /* CONFIG_KEXEC_FILE */
> +
>  #endif /* __ASSEMBLY__ */
>  
>  #endif /* CONFIG_KEXEC */
> diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
> index 89e5d864e923..466c683bb551 100644
> --- a/arch/arm/kernel/Makefile
> +++ b/arch/arm/kernel/Makefile
> @@ -3,6 +3,7 @@
>  # Makefile for the linux kernel.
>  #
>  
> +CFLAGS_kexec_zimage.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
>  CPPFLAGS_vmlinux.lds := -DTEXT_OFFSET=$(TEXT_OFFSET)
>  AFLAGS_head.o        := -DTEXT_OFFSET=$(TEXT_OFFSET)
>  
> @@ -56,7 +57,9 @@ obj-$(CONFIG_FUNCTION_TRACER)	+= entry-ftrace.o
>  obj-$(CONFIG_DYNAMIC_FTRACE)	+= ftrace.o insn.o patch.o
>  obj-$(CONFIG_FUNCTION_GRAPH_TRACER)	+= ftrace.o insn.o patch.o
>  obj-$(CONFIG_JUMP_LABEL)	+= jump_label.o insn.o patch.o
> -obj-$(CONFIG_KEXEC)		+= machine_kexec.o relocate_kernel.o
> +obj-$(CONFIG_KEXEC_CORE)	+= machine_kexec.o relocate_kernel.o
> +obj-$(CONFIG_KEXEC_FILE)	+= machine_kexec_file.o kexec_zimage.o	\
> +				   kexec_uimage.o
>  # Main staffs in KPROBES are in arch/arm/probes/ .
>  obj-$(CONFIG_KPROBES)		+= patch.o insn.o
>  obj-$(CONFIG_OABI_COMPAT)	+= sys_oabi-compat.o
> diff --git a/arch/arm/kernel/kexec_uimage.c b/arch/arm/kernel/kexec_uimage.c
> new file mode 100644
> index 000000000000..47033574e24e
> --- /dev/null
> +++ b/arch/arm/kernel/kexec_uimage.c
> @@ -0,0 +1,80 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Kexec uImage loader
> + *
> + * Copyright (C) 2020 Samsung Electronics
> + * Author: Łukasz Stelmach <l.stelmach@samsung.com>
> + */
> +
> +#define pr_fmt(fmt)	"kexec_file(uImage): " fmt
> +
> +#include <asm/image.h>
> +#include <linux/crc32.h>
> +#include <linux/err.h>
> +#include <linux/kexec.h>
> +
> +#define crc32_ones(crc, buf, len) \
> +	(crc32(crc ^ 0xffffffff, buf, len) ^ 0xffffffff)
> +
> +static int uimage_probe(const char *uimage_buf, unsigned long uimage_len)
> +{
> +	const struct arm_uimage_header *h =
> +		(struct arm_uimage_header *) uimage_buf;
> +	struct arm_uimage_header uhdr;
> +	unsigned long zoff = sizeof(struct arm_uimage_header);
> +	uint32_t crc;
> +
> +	if (h->magic != ARM_UIMAGE_MAGIC)
> +		return -EINVAL;
> +
> +	if (h->type != ARM_UIMAGE_TYPE_KERNEL &&
> +	    h->type != ARM_UIMAGE_TYPE_KERNEL_NOLOAD){
> +		pr_debug("Invalid image type: %d\n", h->type);
> +		return -EINVAL;
> +	}
> +
> +	if (h->arch != ARM_UIMAGE_ARCH_ARM) {
> +		pr_debug("Invalidy image arch: %d\n", h->arch);
> +		return -EINVAL;
> +	}
> +
> +	memcpy((char *)&uhdr, h, sizeof(uhdr));
> +	crc = be32_to_cpu(uhdr.hdr_crc);
> +	uhdr.hdr_crc = 0;
> +
> +	if (crc32_ones(0, (char *)&uhdr, sizeof(uhdr)) != crc) {
> +		pr_debug("Corrupt header, CRC do not match\n");
> +		return -EINVAL;
> +	}
> +
> +	crc = be32_to_cpu(uhdr.crc);
> +	if (crc32_ones(0, uimage_buf + zoff, uimage_len - zoff) != crc) {
> +		pr_debug("Corrupt zImage, CRC do not match\n");
> +		return -EINVAL;
> +	}
> +
> +	return kexec_zimage_ops.probe(uimage_buf + zoff,
> +				      uimage_len - zoff);
> +}
> +
> +static void *uimage_load(struct kimage *image,
> +				char *uimage, unsigned long uimage_len,
> +				char *initrd, unsigned long initrd_len,
> +				char *cmdline, unsigned long cmdline_len)
> +{
> +	const struct arm_uimage_header *h =
> +		(struct arm_uimage_header *) uimage;
> +	unsigned long zimage_offset = sizeof(struct arm_uimage_header);
> +
> +	pr_debug("Loading uImage");
> +	return kexec_zimage_ops.load(image,
> +				     uimage + zimage_offset,
> +				     uimage_len - zimage_offset,
> +				     initrd, initrd_len,
> +				     cmdline, cmdline_len);
> +}
> +
> +const struct kexec_file_ops kexec_uimage_ops = {
> +	.probe = uimage_probe,
> +	.load = uimage_load,
> +};
> diff --git a/arch/arm/kernel/kexec_zimage.c b/arch/arm/kernel/kexec_zimage.c
> new file mode 100644
> index 000000000000..d09795fc9072
> --- /dev/null
> +++ b/arch/arm/kernel/kexec_zimage.c
> @@ -0,0 +1,199 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Kexec zImage loader
> + *
> + * Copyright (C) 2020 Samsung Electronics
> + * Author: Łukasz Stelmach <l.stelmach@samsung.com>

Please credit me as part author of this - you have taken some of my
code from the userspace kexec tool (such as the contents of
find_extension_tag()) and copied it in here, so this is not all your
own work.

> + */
> +
> +#define pr_fmt(fmt)	"kexec_file(zImage): " fmt
> +
> +#include <asm/image.h>
> +#include <asm/unaligned.h>
> +#include <linux/err.h>
> +#include <linux/kexec.h>
> +#include <linux/memblock.h>
> +
> +#define byte_size(t)    ((t)->hdr.size << 2)
> +
> +static const void *find_extension_tag(const char *buf,
> +						       unsigned long len,
> +						       uint32_t tag_id)
> +{
> +	const struct arm_zimage_header *h = (const struct arm_zimage_header *)buf;
> +	const struct arm_zimage_tag *tag;
> +	uint32_t offset, size;
> +	uint32_t max = len - sizeof(struct tag_header);
> +
> +	if (len < sizeof(*h) ||
> +	    h->magic != ARM_ZIMAGE_MAGIC1 ||
> +	    h->magic2 != ARM_ZIMAGE_MAGIC2)
> +		return NULL;
> +
> +	for (offset = h->extension_tag_offset;
> +	     (tag = (void *)(buf + offset)) != NULL &&
> +		     offset < max &&
> +		     (size = le32_to_cpu(byte_size(tag))) != 0 &&
> +		     offset + size < len;
> +	     offset += size) {
> +		pr_debug("  offset 0x%08x tag 0x%08x size %u\n",
> +			  offset, le32_to_cpu(tag->hdr.tag), size);
> +		if (tag->hdr.tag == tag_id)
> +			return tag;
> +	}
> +
> +	return NULL;
> +}
> +
> +static int zimage_probe(const char *kernel_buf, unsigned long kernel_len)
> +{
> +	const struct arm_zimage_header *h =
> +		(struct arm_zimage_header *)(kernel_buf);
> +
> +	if (!h || (kernel_len < sizeof(*h)))
> +		return -EINVAL;
> +
> +	if ((h->magic != ARM_ZIMAGE_MAGIC1) ||
> +	    (h->magic2 != ARM_ZIMAGE_MAGIC2))
> +		return -EINVAL;
> +
> +	return 0;
> +}
> +
> +
> +#if defined(DEBUG)
> +#define debug_offsets() ({			\
> +	pr_debug("Image offsets:\n");		\
> +	pr_debug("  kernel 0x%08lx 0x%08lx\n", kernel_offset, kernel_len); \
> +	pr_debug("  zimage 0x%08lx 0x%08lx\n", zimage_offset, zimage_len); \
> +	pr_debug("  initrd 0x%08lx 0x%08lx\n", initrd_offset, initrd_len); \
> +})
> +#else
> +#define debug_offsets()
> +#endif
> +
> +static void *zimage_load(struct kimage *image,
> +				char *zimage, unsigned long zimage_len,
> +				char *initrd, unsigned long initrd_len,
> +				char *cmdline, unsigned long cmdline_len)
> +{
> +	struct arm_zimage_header *h;
> +	struct kexec_buf kbuf;
> +	struct kexec_segment *zimage_segment;
> +	const struct arm_zimage_tag *klsz_tag;
> +	const struct arm_zimage_tag_dc *dcsz_tag;
> +	int ret = -EINVAL;
> +
> +	unsigned long zimage_mem = 0x20000; /* malloc 64kB + stack 4 kB + some bss */
> +	unsigned long kernel_len = zimage_len * 4; /* 4:1 compression */

This has been proven wrong.

> +	unsigned long kernel_offset = memblock_start_of_DRAM() +
> +		ALIGN(TEXT_OFFSET, PAGE_SIZE);

TEXT_OFFSET is actually a property of the loaded kernel, not of the
currently running kernel.  I have a patch to add that into the zImage
tag.

> +	unsigned long zimage_offset = kernel_offset +
> +		ALIGN(kernel_len, PAGE_SIZE);
> +	unsigned long initrd_offset = zimage_offset +
> +		ALIGN(zimage_len + zimage_mem, PAGE_SIZE);

Since kernel_len is wrong, these will be wrong... please only fall
back to this if you don't find the extension tag - in other words,
declare the variables here, but don't initialise them, set them
lower down in the file if we fail to find the extension tag.

> +
> +	if (image->type == KEXEC_TYPE_CRASH) {
> +		kernel_offset += crashk_res.start;
> +		zimage_offset += crashk_res.start;
> +		initrd_offset += crashk_res.start;
> +	}
> +	debug_offsets();
> +
> +	h = (struct arm_zimage_header *)zimage;
> +
> +	klsz_tag = find_extension_tag(zimage, zimage_len, ZIMAGE_TAG_KRNL_SIZE);
> +	if (klsz_tag) {
> +		uint32_t *p = (void *)zimage +
> +			le32_to_cpu(klsz_tag->u.krnl_size.size_ptr);
> +		uint32_t edata_size = le32_to_cpu(get_unaligned(p));
> +		uint32_t bss_size = le32_to_cpu(klsz_tag->u.krnl_size.bss_size);
> +
> +		kernel_len = edata_size + bss_size;
> +
> +		pr_debug("Decompressed kernel sizes:\n");
> +		pr_debug(" text+data 0x%08lx bss 0x%08lx total 0x%08lx\n",
> +			 (unsigned long)edata_size,
> +			 (unsigned long)bss_size,
> +			 (unsigned long)kernel_len);
> +
> +		zimage_offset = kernel_offset + ALIGN(edata_size, PAGE_SIZE);
> +		initrd_offset = zimage_offset +
> +			max(ALIGN(zimage_len + 0x20000, PAGE_SIZE),
> +			    ALIGN((unsigned long)bss_size, PAGE_SIZE));
> +		debug_offsets();

This looks incorrect to me.  Please see the kexec tool - what its doing
in its corresponding section that you copied some of this code from is
carefully thought out and can't be simplified.  Ergo, I think this is
wrong.

> +	}
> +
> +	dcsz_tag = find_extension_tag(zimage, zimage_len,
> +				      ZIMAGE_TAG_DECOMP_SIZE);
> +	if (dcsz_tag) {
> +		uint32_t bss_size = le32_to_cpu(dcsz_tag->u.decomp_size.bss_size);
> +		uint32_t stack_size = le32_to_cpu(dcsz_tag->u.decomp_size.stack_size);
> +		uint32_t malloc_size = le32_to_cpu(dcsz_tag->u.decomp_size.malloc_size);
> +
> +		zimage_mem = bss_size + stack_size + malloc_size;
> +
> +		pr_debug("Decompressor memory requirements:\n");
> +		pr_debug(" bss 0x%08lx stack 0x%08lx malloc 0x%08lx total 0x%08lx\n",
> +			 (unsigned long)bss_size,
> +			 (unsigned long)stack_size,
> +			 (unsigned long)malloc_size,
> +			 zimage_mem);
> +
> +		initrd_offset = max(ALIGN(zimage_offset + zimage_len +
> +					  bss_size + stack_size +
> +					  malloc_size, PAGE_SIZE),
> +				    ALIGN(kernel_offset + kernel_len, PAGE_SIZE));
> +		debug_offsets();
> +	}
> +
> +	/*
> +	 * zImage MUST be loaded into the first 128 MiB of physical
> +	 * memory for proper memory detection. Should the uncompressed
> +	 * kernel be larger than 128 MiB, zImage relocation becomes
> +	 * unavoidable and it is best to rely on the relocation code.
> +	 */
> +	if (((zimage_offset - kernel_offset) + PAGE_SIZE + 0x8000) >= SZ_128M) {
> +		pr_debug("The kernel is too big (%ld MiB) to avoid "
> +			 "zImage relocation. Loading zimage at 0x%08lx\n",
> +			 ((zimage_offset - kernel_offset) >> 20),
> +			 kernel_offset);
> +		zimage_offset = kernel_offset;
> +	}
> +
> +	kbuf.image = image;
> +	kbuf.top_down = false;
> +
> +	kbuf.buf_min = zimage_offset;
> +	kbuf.buf_max = ULONG_MAX;
> +	kbuf.buffer = zimage;
> +	kbuf.bufsz = zimage_len;
> +	kbuf.buf_align = PAGE_SIZE;
> +
> +	kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
> +	kbuf.memsz = zimage_len;
> +
> +	ret = kexec_add_buffer(&kbuf);
> +	if (ret)
> +		return ERR_PTR(ret);
> +
> +	pr_debug("Loaded zImage at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> +		 kbuf.mem, kbuf.bufsz, kbuf.memsz);
> +
> +	initrd_offset += kbuf.mem - zimage_offset;
> +	debug_offsets();
> +
> +	zimage_segment = &image->segment[image->nr_segments - 1];
> +	image->start = zimage_segment->mem;
> +
> +	ret = load_other_segments(image,
> +				  zimage_segment->mem, zimage_segment->memsz,
> +				  initrd, initrd_len, initrd_offset,
> +				  cmdline);
> +	return ERR_PTR(ret);
> +}
> +
> +const struct kexec_file_ops kexec_zimage_ops = {
> +	.probe = zimage_probe,
> +	.load = zimage_load,
> +};
> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> index c10a2dfd53d1..2e4780efabb4 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -93,10 +93,13 @@ int machine_kexec_prepare(struct kimage *image)
>  					       current_segment->memsz))
>  			return -EINVAL;
>  
> -		err = get_user(header, (__be32*)current_segment->buf);
> -		if (err)
> -			return err;
> -
> +		if (image->file_mode) {
> +			header = *(__be32 *)current_segment->buf;
> +		} else {
> +			err = get_user(header, (__be32 *)current_segment->buf);
> +			if (err)
> +				return err;
> +		}
>  		if (header == cpu_to_be32(OF_DT_HEADER))
>  			image->arch.kernel_r2 = current_segment->mem;
>  	}
> diff --git a/arch/arm/kernel/machine_kexec_file.c b/arch/arm/kernel/machine_kexec_file.c
> new file mode 100644
> index 000000000000..ead680f1e795
> --- /dev/null
> +++ b/arch/arm/kernel/machine_kexec_file.c
> @@ -0,0 +1,209 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * kexec_file for arm
> + *
> + * Copyright (C) 2018 Linaro Limited
> + * Copyright (C) 2020 Samsung Electronics
> + * Authors:
> + *     AKASHI Takahiro <takahiro.akashi@linaro.org>
> + *     Łukasz Stelmach <l.stelmach@samsung.com>
> + *
> + */
> +
> +#define pr_fmt(fmt) "kexec_file: " fmt
> +
> +#include <linux/kexec.h>
> +#include <linux/libfdt.h>
> +#include <linux/of_fdt.h>
> +#include <linux/random.h>
> +
> +/* relevant device tree properties */
> +#define FDT_PROP_INITRD_START	"linux,initrd-start"
> +#define FDT_PROP_INITRD_END	"linux,initrd-end"
> +#define FDT_PROP_BOOTARGS	"bootargs"
> +#define FDT_PROP_RNG_SEED	"rng-seed"
> +
> +static int setup_dtb(struct kimage *image,
> +		     unsigned long initrd_load_addr, unsigned long initrd_len,
> +		     char *cmdline, void *dtb)
> +{
> +	int off, ret;
> +
> +	ret = fdt_path_offset(dtb, "/chosen");
> +	if (ret < 0)
> +		goto out;
> +
> +	off = ret;
> +
> +	/* add bootargs */
> +	if (cmdline) {
> +		ret = fdt_setprop_string(dtb, off, FDT_PROP_BOOTARGS, cmdline);
> +		if (ret)
> +			goto out;
> +	} else {
> +		ret = fdt_delprop(dtb, off, FDT_PROP_BOOTARGS);
> +		if (ret && (ret != -FDT_ERR_NOTFOUND))
> +			goto out;
> +	}
> +
> +	/* add initrd-* */
> +	if (initrd_load_addr) {
> +		ret = fdt_setprop_u64(dtb, off, FDT_PROP_INITRD_START,
> +				      initrd_load_addr);
> +		if (ret)
> +			goto out;
> +
> +		ret = fdt_setprop_u64(dtb, off, FDT_PROP_INITRD_END,
> +				      initrd_load_addr + initrd_len);
> +		if (ret)
> +			goto out;
> +	} else {
> +		ret = fdt_delprop(dtb, off, FDT_PROP_INITRD_START);
> +		if (ret && (ret != -FDT_ERR_NOTFOUND))
> +			goto out;
> +
> +		ret = fdt_delprop(dtb, off, FDT_PROP_INITRD_END);
> +		if (ret && (ret != -FDT_ERR_NOTFOUND))
> +			goto out;
> +	}
> +
> +	/* add rng-seed */
> +	if (rng_is_initialized()) {
> +		char seed[128];
> +		get_random_bytes(seed, sizeof(seed));
> +
> +		ret = fdt_setprop(dtb, off, FDT_PROP_RNG_SEED,
> +				  seed, sizeof(seed));
> +		if (ret)
> +			goto out;
> +	} else {
> +		pr_notice("RNG is not initialised: omitting \"%s\" property\n",
> +				FDT_PROP_RNG_SEED);
> +		ret = 0;
> +	}
> +
> +out:
> +	if (ret)
> +		return (ret == -FDT_ERR_NOSPACE) ? -ENOMEM : -EINVAL;
> +
> +	return 0;
> +}
> +/*
> + * More space needed so that we can add initrd, bootargs and kaslr-seed.
> + */
> +#define DTB_EXTRA_SPACE 0x1000
> +
> +static int create_dtb(struct kimage *image,
> +		      unsigned long initrd_load_addr, unsigned long initrd_len,
> +		      char *cmdline, void **dtb)
> +{
> +	void *buf;
> +	size_t buf_size;
> +	size_t cmdline_len;
> +	int ret;
> +
> +	cmdline_len = cmdline ? strlen(cmdline) : 0;
> +	buf_size = fdt_totalsize(initial_boot_params)
> +			+ cmdline_len + DTB_EXTRA_SPACE;
> +
> +	for (;;) {
> +		buf = vmalloc(buf_size);
> +		if (!buf)
> +			return -ENOMEM;
> +
> +		/* duplicate a device tree blob */
> +		ret = fdt_open_into(initial_boot_params, buf, buf_size);
> +		if (ret)
> +			return -EINVAL;
> +
> +		ret = setup_dtb(image, initrd_load_addr, initrd_len,
> +				cmdline, buf);
> +		if (ret) {
> +			vfree(buf);
> +			if (ret == -ENOMEM) {
> +				/* unlikely, but just in case */
> +				buf_size += DTB_EXTRA_SPACE;
> +				continue;
> +			} else {
> +				return ret;
> +			}
> +		}
> +
> +		/* trim it */
> +		fdt_pack(buf);
> +		*dtb = buf;
> +
> +		return 0;
> +	}
> +}
> +
> +int load_other_segments(struct kimage *image,
> +			unsigned long zimage_load_addr,
> +			unsigned long zimage_len,
> +			char *initrd,
> +			unsigned long initrd_len,
> +			unsigned long initrd_offset,
> +			char *cmdline)
> +{
> +	struct kexec_buf kbuf;
> +	void *dtb = NULL;
> +	unsigned long initrd_load_addr = 0;
> +	unsigned long dtb_len;
> +	int ret = 0;
> +
> +	kbuf.image = image;
> +	/* not allocate anything below the kernel */
> +	kbuf.buf_min = initrd_offset;
> +	if (initrd) {
> +		kbuf.buffer = initrd;
> +		kbuf.bufsz = initrd_len;
> +		kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
> +		kbuf.memsz = initrd_len;
> +		kbuf.buf_align = PAGE_SIZE;
> +		kbuf.buf_max = ULONG_MAX;
> +		kbuf.top_down = false;
> +
> +		ret = kexec_add_buffer(&kbuf);
> +		if (ret)
> +			goto out_err;
> +
> +		pr_debug("Loaded initrd at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> +				kbuf.mem, kbuf.bufsz, kbuf.memsz);
> +
> +		initrd_load_addr = kbuf.mem;
> +		kbuf.buf_min = initrd_load_addr + kbuf.memsz;
> +	}
> +
> +	/* load dtb */
> +	ret = create_dtb(image, initrd_load_addr, initrd_len, cmdline, &dtb);
> +	if (ret) {
> +		pr_err("Preparing for new dtb failed\n");
> +		goto out_err;
> +	}
> +
> +	dtb_len = fdt_totalsize(dtb);
> +	kbuf.buffer = dtb;
> +	kbuf.bufsz = dtb_len;
> +	kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
> +	kbuf.memsz = dtb_len;
> +	kbuf.buf_align = PAGE_SIZE;
> +	kbuf.buf_max = ULONG_MAX;
> +	kbuf.top_down = false;
> +
> +	ret = kexec_add_buffer(&kbuf);
> +	if (ret)
> +		goto out_err;
> +
> +	pr_debug("Loaded dtb at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> +		 kbuf.mem, kbuf.bufsz, kbuf.memsz);
> +	return 0;
> +out_err:
> +	vfree(dtb);
> +	return ret;
> +}
> +
> +const struct kexec_file_ops * const kexec_file_loaders[] = {
> +	&kexec_uimage_ops,
> +	&kexec_zimage_ops,
> +	NULL
> +};
> -- 
> 2.26.2
> 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up

_______________________________________________
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/5] arm: decompressor: set malloc pool size for the decompressor
From: Russell King - ARM Linux admin @ 2020-06-01 15:10 UTC (permalink / raw)
  To: Lukasz Stelmach
  Cc: Kees Cook, Bartlomiej Zolnierkiewicz, Masahiro Yamada,
	Nick Desaulniers, linux-kernel, AKASHI Takahiro, Ben Dooks,
	Thomas Gleixner, Enrico Weigelt, Ingo Molnar, linux-arm-kernel,
	Marek Szyprowski
In-Reply-To: <dleftj367eu95j.fsf%l.stelmach@samsung.com>

On Mon, Jun 01, 2020 at 04:56:40PM +0200, Lukasz Stelmach wrote:
> It was <2020-06-01 pon 15:46>, when Russell King - ARM Linux admin wrote:
> > On Mon, Jun 01, 2020 at 04:27:50PM +0200, Łukasz Stelmach wrote:
> >> Move the definition of malloc pool size of the decompressor to
> >> a single place. This value will be exposed later for kexec_file loader.
> >> 
> >> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
> >> ---
> >>  arch/arm/boot/compressed/Makefile | 2 ++
> >>  arch/arm/boot/compressed/head.S   | 6 ++++--
> >>  2 files changed, 6 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> >> index 9c11e7490292..b3594cd1588c 100644
> >> --- a/arch/arm/boot/compressed/Makefile
> >> +++ b/arch/arm/boot/compressed/Makefile
> >> @@ -125,6 +125,8 @@ KBSS_SZ = $(shell echo $$(($$($(NM) $(obj)/../../../../vmlinux | \
> >>  		sed -n -e 's/^\([^ ]*\) [AB] __bss_start$$/-0x\1/p' \
> >>  		       -e 's/^\([^ ]*\) [AB] __bss_stop$$/+0x\1/p') )) )
> >>  LDFLAGS_vmlinux = --defsym _kernel_bss_size=$(KBSS_SZ)
> >> +# malloc pool size
> >> +LDFLAGS_vmlinux += --defsym _malloc_size=0x10000
> >>  # Supply ZRELADDR to the decompressor via a linker symbol.
> >>  ifneq ($(CONFIG_AUTO_ZRELADDR),y)
> >>  LDFLAGS_vmlinux += --defsym zreladdr=$(ZRELADDR)
> >> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> >> index e8e1c866e413..dcc1afa60fb9 100644
> >> --- a/arch/arm/boot/compressed/head.S
> >> +++ b/arch/arm/boot/compressed/head.S
> >> @@ -309,7 +309,8 @@ restart:	adr	r0, LC0
> >>  #ifndef CONFIG_ZBOOT_ROM
> >>  		/* malloc space is above the relocated stack (64k max) */
> >>  		add	sp, sp, r0
> >> -		add	r10, sp, #0x10000
> >> +		ldr	r10, =_malloc_size
> >> +		add	r10, r10, sp
> >
> > This says "locate _malloc_size in a literal pool somewhere, and load it
> > using a PC-relative offset".  Are you sure that the literal pool is
> > sensibly located?
> >
> > Would it be better to use a definition for this?
> 
> I've followed ZRELADDR way. I think both values should be handled the
> same way (it makes it easier to comprehend IMHO). Is there any reason
> not to?  Should I change ZRELADDR for v2 too?

There's a good reason.  ZRELADDR can be a constant that does not fit
into the ARMs immediate constants (8 bits of significant data plus
a multiple of a 2-bit shift), whereas the size of the malloc space
is guaranteed to fit.  So, ZRELADDR has to use a literal load.
This doesn't.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up

_______________________________________________
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 5/5] arm: kexec_file: load zImage or uImage, initrd and dtb
From: Russell King - ARM Linux admin @ 2020-06-01 15:14 UTC (permalink / raw)
  To: Łukasz Stelmach
  Cc: Kees Cook, Bartlomiej Zolnierkiewicz, Masahiro Yamada,
	Nick Desaulniers, linux-kernel, AKASHI Takahiro, Ben Dooks,
	Thomas Gleixner, Enrico Weigelt, Ingo Molnar, linux-arm-kernel,
	Marek Szyprowski
In-Reply-To: <20200601150745.GL1551@shell.armlinux.org.uk>

On Mon, Jun 01, 2020 at 04:07:45PM +0100, Russell King - ARM Linux admin wrote:
> On Mon, Jun 01, 2020 at 04:27:54PM +0200, Łukasz Stelmach wrote:
> > diff --git a/arch/arm/kernel/kexec_zimage.c b/arch/arm/kernel/kexec_zimage.c
> > new file mode 100644
> > index 000000000000..d09795fc9072
> > --- /dev/null
> > +++ b/arch/arm/kernel/kexec_zimage.c
> > @@ -0,0 +1,199 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Kexec zImage loader
> > + *
> > + * Copyright (C) 2020 Samsung Electronics
> > + * Author: Łukasz Stelmach <l.stelmach@samsung.com>
> 
> Please credit me as part author of this - you have taken some of my
> code from the userspace kexec tool (such as the contents of
> find_extension_tag()) and copied it in here, so this is not all your
> own work.

It would also be a very good idea to indicate _where_ you copied some
of this code from.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up

_______________________________________________
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 1/2] media: dt-bindings: media: xilinx: Add Xilinx UHD-SDI Receiver Subsystem
From: Vishal Sagar @ 2020-06-01 15:14 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Dinesh Kumar,
	Hyun Kwon, Sandip Kothari, linux-kernel@vger.kernel.org,
	robh+dt@kernel.org, Michal Simek, Joe Perches,
	hans.verkuil@cisco.com, mchehab@kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <20200506130225.GD5946@pendragon.ideasonboard.com>

Hi Laurent,

Thanks for the review.

> -----Original Message-----
> From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Sent: Wednesday, May 6, 2020 6:32 PM
> To: Vishal Sagar <vsagar@xilinx.com>
> Cc: Hyun Kwon <hyunk@xilinx.com>; mchehab@kernel.org;
> robh+dt@kernel.org; mark.rutland@arm.com; Michal Simek
> <michals@xilinx.com>; linux-media@vger.kernel.org;
> devicetree@vger.kernel.org; hans.verkuil@cisco.com; linux-arm-
> kernel@lists.infradead.org; linux-kernel@vger.kernel.org; Dinesh Kumar
> <dineshk@xilinx.com>; Sandip Kothari <sandipk@xilinx.com>; Joe Perches
> <joe@perches.com>
> Subject: Re: [PATCH v2 1/2] media: dt-bindings: media: xilinx: Add Xilinx UHD-
> SDI Receiver Subsystem
> 
> Hi Vishal,
> 
> Thank you for the patch.
> 
> On Wed, Apr 29, 2020 at 07:47:03PM +0530, Vishal Sagar wrote:
> > Add bindings documentation for Xilinx UHD-SDI Receiver Subsystem.
> >
> > The Xilinx UHD-SDI Receiver Subsystem consists of SMPTE UHD-SDI (RX) IP
> > core, an SDI RX to Video Bridge IP core to convert SDI video to native
> > video and a Video In to AXI4-Stream IP core to convert native video to
> > AXI4-Stream.
> >
> > Signed-off-by: Vishal Sagar <vishal.sagar@xilinx.com>
> > ---
> > v2
> > - Removed references to xlnx,video*
> > - Fixed as per Sakari Ailus and Rob Herring's comments
> > - Converted to yaml format
> >
> >  .../bindings/media/xilinx/xlnx,sdirxss.yaml   | 132 ++++++++++++++++++
> >  1 file changed, 132 insertions(+)
> >  create mode 100644
> Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml
> >
> > diff --git
> a/Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml
> b/Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml
> > new file mode 100644
> > index 000000000000..9133ad19df55
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml
> > @@ -0,0 +1,132 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/xilinx/xlnx,sdirxss.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +
> > +title: Xilinx SMPTE UHD-SDI Receiver Subsystem
> > +
> > +maintainers:
> > +  - Vishal Sagar <vishal.sagar@xilinx.com>
> > +
> > +description: |
> > +  The SMPTE UHD-SDI Receiver (RX) Subsystem allows you to quickly create
> systems
> > +  based on SMPTE SDI protocols. It receives unaligned native SDI streams
> from
> > +  the SDI GT PHY and outputs an AXI4-Stream video stream, native video, or
> > +  native SDI using Xilinx transceivers as the physical layer.
> > +
> > +  The subsystem consists of
> > +  1 - SMPTE UHD-SDI Rx
> > +  2 - SDI Rx to Native Video Bridge
> > +  3 - Video In to AXI4-Stream Bridge
> > +
> > +  The subsystem can capture SDI streams in upto 12G mode 8 data streams
> and output
> 
> s/upto/up to/
> 

I will fix this in next version. 

> > +  a dual pixel per clock RGB/YUV444,422/420 10/12 bits per component
> AXI4-Stream.
> > +
> > +properties:
> > +  compatible:
> > +    items:
> > +      - enum:
> > +        - xlnx,v-smpte-uhdsdi-rx-ss-2.0
> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +  interrupts:
> > +    maxItems: 1
> > +
> > +  clocks:
> > +    description: List of clock specifiers
> > +    items:
> > +      - description: AXI4-Lite clock
> > +      - description: SMPTE UHD-SDI Rx core clock
> > +      - description: Video clock
> > +
> > +  clock-names:
> > +    items:
> > +      - const: s_axi_aclk
> > +      - const: sdi_rx_clk
> > +      - const: video_out_clk
> > +
> > +  xlnx,bpp:
> > +    description: Bits per pixel supported. Can be 10 or 12 bits per pixel only.
> > +    allOf:
> > +      - $ref: "/schemas/types.yaml#/definitions/uint32"
> > +      - enum: [10, 12]
> 
> I don't see this as a design parameter in the documentation (pg290,
> v2.0). What does it correspond to ? All the BPC mentions in the
> documentation always state that 10-bit is the only supported value.
> 

The new version of IP being released will have 10 and 12 bit support. It is already in the Xilinx linux-xlnx repo.
I will rename this to "xlnx,bpc" instead of "xlnx,bpp" to refer to bits per component.

> > +
> > +  xlnx,line-rate:
> > +    description: |
> > +      The maximum mode supported by the design. Possible values are as
> below
> > +      12G_SDI_8DS - 12G mode with 8 data streams
> > +      6G_SDI      -  6G mode
> > +      3G_SDI      -  3G mode
> > +    enum:
> > +      - 12G_SDI_8DS
> > +      - 6G_SDI
> > +      - 3G_SDI
> 
> How about making this an integer property, with #define in
> include/dt-bindings/media/xilinx-sdi.h ? As far as I understand, the SDI
> TX subsystem has the same parameter, so the #define could be shared
> between the two.
> 

Yes that is ok with me. I will add this in the next version.

> > +
> > +  xlnx,include-edh:
> > +    type: boolean
> > +    description: |
> > +      This is present when the Error Detection and Handling processor is
> > +      enabled in design.
> > +
> > +  ports:
> > +    type: object
> > +    description: |
> > +      Generally the SDI port is connected to a device like SDI Broadcast
> camera
> > +      which is independently controlled. Hence port@0 is a source port which
> can be
> > +      connected to downstream IP which can work with AXI4 Stream data.
> 
> We should still have an input port. It can be connected to a DT node for
> a physical SDI connector, or any other component in the platform (I
> expect the former to be the common case). There are DT bindings for
> connectors in Documentation/devicetree/bindings/display/connector/, we
> should add one for SDI.
> 

Yes the input port is a physical SDI connector connected to an equipment like broadcast camera.
But the camera/equipment can't be controlled by the V4L2 pipeline and SDI protocol is unidirectional.

If we add another dt node, then I think another dummy v4l subdev driver will need to implemented and loaded
to complete the pipe as Xilinx Video driver will need it.

Could you please share the reason to have this input port in the SDI Rx driver?

> > +    properties:
> > +      port@0:
> > +        type: object
> > +        description: Source port
> > +        properties:
> > +          reg:
> > +            const: 0
> > +          endpoint:
> > +            type: object
> > +            properties:
> > +              remote-endpoint: true
> > +            required:
> > +              - remote-endpoint
> > +            additionalProperties: false
> > +        additionalProperties: false
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - interrupts
> > +  - clocks
> > +  - clock-names
> > +  - xlnx,line-rate
> > +  - xlnx,bpp
> > +  - ports
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    uhdsdirxss: v-smpte-uhdsdi-rxss@80000000 {
> > +      compatible = "xlnx,v-smpte-uhdsdi-rx-ss-2.0";
> > +      interrupt-parent = <&gic>;
> > +      interrupts = <0 89 4>;
> > +      reg = <0x0 0x80000000 0x0 0x10000>;
> > +      xlnx,include-edh;
> > +      xlnx,line-rate = "12G_SDI_8DS";
> > +      clocks = <&clk_1>, <&si570_1>, <&clk_2>;
> > +      clock-names = "s_axi_aclk", "sdi_rx_clk", "video_out_clk";
> > +      xlnx,bpp = <10>;
> > +
> > +      ports {
> > +        #address-cells = <1>;
> > +        #size-cells = <0>;
> > +        port@0 {
> > +          reg = <0>;
> > +          sdirx_out: endpoint {
> > +            remote-endpoint = <&vcap_sdirx_in>;
> > +          };
> > +        };
> > +      };
> > +    };
> 
> --
> Regards,
> 
> Laurent Pinchart

Regards
Vishal Sagar 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v3 0/1] ARM: Add Rockchip rk3288w support
From: Mylène Josserand @ 2020-06-01 15:14 UTC (permalink / raw)
  To: mturquette, sboyd, heiko
  Cc: mylene.josserand, kever.yang, linux-kernel, linux-rockchip, geert,
	kernel, linux-clk, linux-arm-kernel

Hello everyone,

Context
-------

Here is my V3 of my patches that add the support for the Rockchip
RK3288w which is a revision of the RK3288. It is mostly the same SOC
except for, at least, one clock tree which is different.
This difference is only known by looking at the BSP kernel [1].

Currently, the mainline kernel will not hang on rk3288w but it is
probably by "chance" because we got an issue on a lower kernel version.

According to Rockchip's U-Boot [2], the rk3288w can be detected using
the HDMI revision number (= 0x1A) in this version of the SOC.

Changelog
---------

In this V3, the revision's detection is not done in the kernel anymore.
This patch will handle the rk3288w clock tree according to a new
compatible "rockchip,rk3288w-cru" that must be provided by bootloaders.

Changes since v2:
   - Remove all codes about revision detection, let's handle that by
   Bootloaders

Best regards,
Mylène Josserand

[1] https://github.com/rockchip-linux/kernel/blob/develop-4.4/drivers/clk/rockchip/clk-rk3288.c#L960..L964
[2] https://github.com/rockchip-linux/u-boot/blob/next-dev/arch/arm/mach-rockchip/rk3288/rk3288.c#L378..L388

Mylène Josserand (1):
  clk: rockchip: rk3288: Handle clock tree for rk3288w

 drivers/clk/rockchip/clk-rk3288.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

-- 
2.26.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v3 1/1] clk: rockchip: rk3288: Handle clock tree for rk3288w
From: Mylène Josserand @ 2020-06-01 15:14 UTC (permalink / raw)
  To: mturquette, sboyd, heiko
  Cc: mylene.josserand, kever.yang, linux-kernel, linux-rockchip, geert,
	kernel, linux-clk, linux-arm-kernel
In-Reply-To: <20200601151442.156184-1-mylene.josserand@collabora.com>

The revision rk3288w has a different clock tree about "hclk_vio"
clock, according to the BSP kernel code.

This patch handles this difference by detecting which device-tree
we are using. If it is a "rockchip,rk3288-cru", let's register
the clock tree as it was before. If the compatible is
"rockchip,rk3288w-cru", we will apply the difference according to this
version of this SoC.

Noticed that this new device-tree compatible must be handled by
bootloader.

Signed-off-by: Mylène Josserand <mylene.josserand@collabora.com>
---
 drivers/clk/rockchip/clk-rk3288.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3288.c b/drivers/clk/rockchip/clk-rk3288.c
index cc2a177bbdbf..5018d2f1e54c 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -425,8 +425,6 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = {
 	COMPOSITE(0, "aclk_vio0", mux_pll_src_cpll_gpll_usb480m_p, CLK_IGNORE_UNUSED,
 			RK3288_CLKSEL_CON(31), 6, 2, MFLAGS, 0, 5, DFLAGS,
 			RK3288_CLKGATE_CON(3), 0, GFLAGS),
-	DIV(0, "hclk_vio", "aclk_vio0", 0,
-			RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
 	COMPOSITE(0, "aclk_vio1", mux_pll_src_cpll_gpll_usb480m_p, CLK_IGNORE_UNUSED,
 			RK3288_CLKSEL_CON(31), 14, 2, MFLAGS, 8, 5, DFLAGS,
 			RK3288_CLKGATE_CON(3), 2, GFLAGS),
@@ -819,6 +817,16 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = {
 	INVERTER(0, "pclk_isp", "pclk_isp_in", RK3288_CLKSEL_CON(29), 3, IFLAGS),
 };
 
+static struct rockchip_clk_branch rk3288w_hclkvio_branch[] __initdata = {
+	DIV(0, "hclk_vio", "aclk_vio1", 0,
+	    RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
+};
+
+static struct rockchip_clk_branch rk3288_hclkvio_branch[] __initdata = {
+	DIV(0, "hclk_vio", "aclk_vio0", 0,
+	    RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
+};
+
 static const char *const rk3288_critical_clocks[] __initconst = {
 	"aclk_cpu",
 	"aclk_peri",
@@ -936,6 +944,14 @@ static void __init rk3288_clk_init(struct device_node *np)
 				   RK3288_GRF_SOC_STATUS1);
 	rockchip_clk_register_branches(ctx, rk3288_clk_branches,
 				  ARRAY_SIZE(rk3288_clk_branches));
+
+	if (of_device_is_compatible(np, "rockchip,rk3288w-cru"))
+		rockchip_clk_register_branches(ctx, rk3288w_hclkvio_branch,
+					       ARRAY_SIZE(rk3288w_hclkvio_branch));
+	else
+		rockchip_clk_register_branches(ctx, rk3288_hclkvio_branch,
+					       ARRAY_SIZE(rk3288_hclkvio_branch));
+
 	rockchip_clk_protect_critical(rk3288_critical_clocks,
 				      ARRAY_SIZE(rk3288_critical_clocks));
 
-- 
2.26.2


_______________________________________________
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: [PATCH v4 18/26] arm64: mte: Add PTRACE_{PEEK,POKE}MTETAGS support
From: Luis Machado @ 2020-06-01 15:17 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: linux-arch, Omair Javaid, Szabolcs Nagy, Andrey Konovalov,
	Kevin Brodsky, Peter Collingbourne, linux-mm, Alan Hayward,
	Vincenzo Frascino, Will Deacon, Dave P Martin, linux-arm-kernel
In-Reply-To: <20200601120724.GB23419@gaia>

On 6/1/20 9:07 AM, Catalin Marinas wrote:
> On Fri, May 29, 2020 at 06:25:14PM -0300, Luis Machado wrote:
>> I have a question about siginfo MTE information. I suppose SEGV_MTESERR will
>> be the most useful setting for debugging, right? Does si_addr contain the
>> tagged pointer with the logical tag, a zero-tagged memory address or a
>> tagged pointer with the allocation tag?
> 
> The si_addr is zero-tagged currently. We were planning to expose the tag
> in FAR_EL1 as a separate siginfo field. See these discussions:
> > 
https://lore.kernel.org/linux-arm-kernel/20200513180914.50892-1-pcc@google.com/
> https://lore.kernel.org/linux-arm-kernel/20200521022943.195898-1-pcc@google.com/
> 
> In theory, we could add the tag to si_addr for SEGV_MTESERR, it
> shouldn't break the existing ABI (well, it depends on how you look at
> it).
> 

Having additional fields in siginfo that hold useful information is 
probably best for debuggers. See my comment below about Intel MPX.

>>  From the debugger user's perspective, one would want to see both the logical
>> tag and the allocation tag. And it would be handy to have both available in
>> siginfo. Does that make sense?
> 
> The debugger can access the allocation tag via PTRACE_PEEKMTETAGS. I
> don't think the kernel should provide this in siginfo. Also, the signal
> handler can do an LDG and read the allocation tag directly, no need for
> it to be in siginfo.
> 

While the debugger can request this information from the kernel, the 
debugger has already received a SIGSEGV signal and will have to fetch 
siginfo for si_code. Having to do another PTRACE_PEEKMTETAGS call just 
to fetch the allocation tag doesn't sound great. Remember this can 
travel through TCP to gdbserver so it can call ptrace from the remote's 
end. It would be best to avoid the round trip.

Also, there seems to be past precedent to include more information in 
siginfo. For example, Intel MPX includes upper/lower bounds violation 
data in there.

Regarding using LDG, are you suggesting force-running this particular 
instruction in the traced process? If so, that isn't the way GDB (in 
particular, not sure about LLDB) does things.

>> Also, when would we see SEGV_MTEAERR, for example? That would provide no
>> additional information about a particular memory address, which is not that
>> useful for the debugger.
> 
> Yeah, we can't really do much here since the hardware doesn't provide us
> such information. The async mode is only useful as a general test to see
> if your program has MTE faults but for actual debugging you'd have to
> switch to synchronous. For glibc at least, I think the mode can be
> driven by an environment variable.
> 

I suspect SEGV_MTESERR would be a reasonable default then, for whoever 
is responsible for setting the default settings.

I'm assuming it is not the debugger, as it doesn't know how to toggle 
prctl settings.

_______________________________________________
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 v3] arm64: dts: ti: k3-am654-main: Update otap-del-sel values
From: Faiz Abbas @ 2020-06-01 15:37 UTC (permalink / raw)
  To: linux-kernel, devicetree, linux-arm-kernel; +Cc: t-kristo, nm, robh+dt
In-Reply-To: <20200519082027.5726-1-faiz_abbas@ti.com>

Hi,

On 19/05/20 1:50 pm, Faiz Abbas wrote:
> According to the latest AM65x Data Manual[1], a different output tap
> delay value is optimum for a given speed mode. Update these values.
> 
> [1] http://www.ti.com/lit/gpn/am6526
> 
> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> ---
> 
> v3: Updated values to the latest data manual revision
> 
> v2: Updated to the latest mainline kernel
> 

Can this patch be picked up?

Thanks,
Faiz

_______________________________________________
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/2] dt-bindings: power: Convert imx gpc to json-schema
From: Rob Herring @ 2020-06-01 15:43 UTC (permalink / raw)
  To: Anson Huang
  Cc: devicetree, ulf.hansson, p.zabel, sboyd, shawnguo, s.hauer,
	linux-kernel, krzk, andrew.smirnov, robh+dt, Linux-imx, kernel,
	festevam, linux-arm-kernel
In-Reply-To: <1590998803-29191-1-git-send-email-Anson.Huang@nxp.com>

On Mon, 01 Jun 2020 16:06:42 +0800, Anson Huang wrote:
> Convert the i.MX GPC binding to DT schema format using json-schema
> 
> >From latest reference manual, there is actually ONLY 1 interrupt for
> GPC, so the additional GPC interrupt is removed.
> 
> Consumer's example is also removed since it is NOT that useful.
> 
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
>  .../devicetree/bindings/power/fsl,imx-gpc.txt      |  91 ---------------
>  .../devicetree/bindings/power/fsl,imx-gpc.yaml     | 124 +++++++++++++++++++++
>  2 files changed, 124 insertions(+), 91 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
>  create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml
> 

Applied, 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: [PATCH 2/2] dt-bindings: power: Convert imx gpcv2 to json-schema
From: Rob Herring @ 2020-06-01 15:43 UTC (permalink / raw)
  To: Anson Huang
  Cc: devicetree, ulf.hansson, kernel, andrew.smirnov, shawnguo,
	s.hauer, linux-kernel, krzk, sboyd, robh+dt, Linux-imx, p.zabel,
	festevam, linux-arm-kernel
In-Reply-To: <1590998803-29191-2-git-send-email-Anson.Huang@nxp.com>

On Mon, 01 Jun 2020 16:06:43 +0800, Anson Huang wrote:
> Convert the i.MX GPCv2 binding to DT schema format using json-schema
> 
> Example is updated based on latest DT file and consumer's example is
> removed since it is NOT that useful.
> 
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
>  .../devicetree/bindings/power/fsl,imx-gpcv2.txt    |  77 ---------------
>  .../devicetree/bindings/power/fsl,imx-gpcv2.yaml   | 108 +++++++++++++++++++++
>  2 files changed, 108 insertions(+), 77 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
>  create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
> 

Applied, 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: [PATCH] pinctrl-single: fix pcs_parse_pinconf() return val
From: Tony Lindgren @ 2020-06-01 16:18 UTC (permalink / raw)
  To: Drew Fustini
  Cc: Linus Walleij, linux-kernel, Robert Nelson, linux-gpio,
	Jason Kridner, Haojian Zhuang, linux-omap, linux-arm-kernel
In-Reply-To: <20200531204147.GA664833@x1>

* Drew Fustini <drew@beagleboard.org> [200531 20:42]:
> This patch causes pcs_parse_pinconf() to return an error when no
> pinctrl_map is added.  The current behavior is to return 0 when
> !PCS_HAS_PINCONF or !nconfs.  Thus pcs_parse_one_pinctrl_entry()
> incorrectly assumes that a map was added and sets num_maps = 2.

Looks OK to me, would be good to wait for Haojian to test this one.

Regards,

Tony

_______________________________________________
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 3/5] arm: decompressor: define a new zImage tag
From: Lukasz Stelmach @ 2020-06-01 16:19 UTC (permalink / raw)
  To: Russell King - ARM Linux admin
  Cc: Kees Cook, Bartlomiej Zolnierkiewicz, Masahiro Yamada,
	Nick Desaulniers, linux-kernel, AKASHI Takahiro, Ben Dooks,
	Thomas Gleixner, Enrico Weigelt, Ingo Molnar, linux-arm-kernel,
	Marek Szyprowski
In-Reply-To: <20200601145502.GJ1551@shell.armlinux.org.uk>


[-- Attachment #1.1: Type: text/plain, Size: 3954 bytes --]

It was <2020-06-01 pon 15:55>, when Russell King - ARM Linux admin wrote:
> On Mon, Jun 01, 2020 at 04:27:52PM +0200, Łukasz Stelmach wrote:
>> Add DCSZ tag which holds dynamic memory (stack, bss, malloc pool)
>> requirements of the decompressor code.
>
> Why do we need to know the stack and BSS size, when the userspace
> kexec tool doesn't need to know this to perform the same function.


kexec-tools load zImage as low in DRAM as possible and rely on two
assumptions:

    + the zImage will copy itself to make enough room for the kernel,
    + sizeof(zImage+mem) < sizeof(kernel+mem), which is true because
      of compression.

       DRAM start
       + 0x8000

zImage    |-----------|-----|-------|
            text+data   bss   stack 

                 text+data           bss   
kernel    |---------------------|-------------------|


initrd                                              |-initrd-|-dtb-|


My code on the other hand tries to load the zImage high enough to make
room for the kernel without copying the zImage.


            text+data           bss   
kernel    |-----------|-------------------|

zImage                |-----------|-----|-------|
                        text+data   bss   stack 

initrd                                          |-initrd-|-dtb-|


In such case the second assumption would be

    sizeof(zImage+mem) < sizeof(kernel bss)

and I can't tell for sure it would always be true. That is why we need
detailed information about decompressor memory requirements.


>> 
>> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
>> ---
>>  arch/arm/boot/compressed/vmlinux.lds.S |  9 ++++++++-
>>  arch/arm/include/asm/image.h           | 13 +++++++++++++
>>  2 files changed, 21 insertions(+), 1 deletion(-)
>> 
>> diff --git a/arch/arm/boot/compressed/vmlinux.lds.S b/arch/arm/boot/compressed/vmlinux.lds.S
>> index 308e9cd6a897..dcfdb3209c90 100644
>> --- a/arch/arm/boot/compressed/vmlinux.lds.S
>> +++ b/arch/arm/boot/compressed/vmlinux.lds.S
>> @@ -39,6 +39,11 @@ SECTIONS
>>      LONG(ARM_ZIMAGE_MAGIC3)
>>      LONG(ZIMAGE_MAGIC(__piggy_size_addr - _start))
>>      LONG(ZIMAGE_MAGIC(_kernel_bss_size))
>> +    LONG(ZIMAGE_MAGIC(5))
>> +    LONG(ARM_ZIMAGE_MAGIC4)
>> +    LONG(ZIMAGE_MAGIC(_end - __bss_start))
>> +    LONG(ZIMAGE_MAGIC(_stack_end - _stack_start))
>> +    LONG(ZIMAGE_MAGIC(_malloc_size))
>>      LONG(0)
>>      _table_end = .;
>>    }
>> @@ -108,10 +113,12 @@ SECTIONS
>>    . = BSS_START;
>>    __bss_start = .;
>>    .bss			: { *(.bss) }
>> +  . = ALIGN(8);		/* the stack must be 64-bit aligned and adjoin bss */
>>    _end = .;
>>  
>> -  . = ALIGN(8);		/* the stack must be 64-bit aligned */
>> +  _stack_start = .;
>>    .stack		: { *(.stack) }
>> +  _stack_end = .;
>>  
>>    PROVIDE(__pecoff_data_size = ALIGN(512) - ADDR(.data));
>>    PROVIDE(__pecoff_end = ALIGN(512));
>> diff --git a/arch/arm/include/asm/image.h b/arch/arm/include/asm/image.h
>> index d5c18a0f6a34..624438740f23 100644
>> --- a/arch/arm/include/asm/image.h
>> +++ b/arch/arm/include/asm/image.h
>> @@ -15,6 +15,7 @@
>>  #define ARM_ZIMAGE_MAGIC1 ZIMAGE_MAGIC(0x016f2818)
>>  #define ARM_ZIMAGE_MAGIC2 (0x45454545)
>>  #define ARM_ZIMAGE_MAGIC3 ZIMAGE_MAGIC(0x5a534c4b)
>> +#define ARM_ZIMAGE_MAGIC4 ZIMAGE_MAGIC(0x5a534344)
>>  
>>  #ifndef __ASSEMBLY__
>>  
>> @@ -43,6 +44,18 @@ struct arm_zimage_tag {
>>  	} u;
>>  };
>>  
>> +struct arm_zimage_tag_dc {
>> +	struct tag_header hdr;
>> +	union {
>> +#define ZIMAGE_TAG_DECOMP_SIZE ARM_ZIMAGE_MAGIC4
>> +		struct zimage_decomp_size {
>> +			__le32 bss_size;
>> +			__le32 stack_size;
>> +			__le32 malloc_size;
>> +		} decomp_size;
>> +	} u;
>> +};
>> +
>>  #endif /* __ASSEMBLY__ */
>>  
>>  #endif /* __ASM_IMAGE_H */
>> -- 
>> 2.26.2
>> 
>> 

-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 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 4/5] arm: Add kexec_image_info
From: Lukasz Stelmach @ 2020-06-01 16:30 UTC (permalink / raw)
  To: Russell King - ARM Linux admin
  Cc: Kees Cook, Bartlomiej Zolnierkiewicz, Masahiro Yamada,
	Nick Desaulniers, linux-kernel, AKASHI Takahiro, Ben Dooks,
	Thomas Gleixner, Enrico Weigelt, Ingo Molnar, linux-arm-kernel,
	Marek Szyprowski
In-Reply-To: <20200601145614.GK1551@shell.armlinux.org.uk>


[-- Attachment #1.1: Type: text/plain, Size: 2784 bytes --]

It was <2020-06-01 pon 15:56>, when Russell King - ARM Linux admin wrote:
> On Mon, Jun 01, 2020 at 04:27:53PM +0200, Łukasz Stelmach wrote:
>> Add kexec_image_info to print detailed information about a kexec image.
>
> Isn't this already visible through kexec debugging?  Why do we need
> to duplicate the same output in the kernel?  Do we think that the
> kexec interfaces are that fragile that they don't work?

Because:

    + kexec_image_info is required if we want to show information for an
      image loaded via kexec_file_load (with kexec-tools or any other
      tool e.g. u-root),
    + this is where both interfaces meet and it is easy to compare
      their results,
    + I consider showing results as close to the end of a code path as
      possible more reliable.

>> 
>> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
>> ---
>>  arch/arm/kernel/machine_kexec.c | 28 ++++++++++++++++++++++++++++
>>  1 file changed, 28 insertions(+)
>> 
>> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
>> index 76300f3813e8..c10a2dfd53d1 100644
>> --- a/arch/arm/kernel/machine_kexec.c
>> +++ b/arch/arm/kernel/machine_kexec.c
>> @@ -31,6 +31,32 @@ extern unsigned long kexec_boot_atags;
>>  
>>  static atomic_t waiting_for_crash_ipi;
>>  
>> +/**
>> + * kexec_image_info - For debugging output.
>> + */
>> +#define kexec_image_info(_i) _kexec_image_info(__func__, __LINE__, _i)
>> +static void _kexec_image_info(const char *func, int line,
>> +	const struct kimage *kimage)
>> +{
>> +	unsigned long i;
>> +
>> +	pr_debug("%s:%d:\n", func, line);
>> +	pr_debug("  kexec kimage info:\n");
>> +	pr_debug("    type:        %d\n", kimage->type);
>> +	pr_debug("    start:       %lx\n", kimage->start);
>> +	pr_debug("    head:        %lx\n", kimage->head);
>> +	pr_debug("    nr_segments: %lu\n", kimage->nr_segments);
>> +
>> +	for (i = 0; i < kimage->nr_segments; i++) {
>> +		pr_debug("      segment[%lu]: %08lx - %08lx, 0x%x bytes, %lu pages\n",
>> +			i,
>> +			kimage->segment[i].mem,
>> +			kimage->segment[i].mem + kimage->segment[i].memsz,
>> +			kimage->segment[i].memsz,
>> +			kimage->segment[i].memsz /  PAGE_SIZE);
>> +	}
>> +}
>> +
>>  /*
>>   * Provide a dummy crash_notes definition while crash dump arrives to arm.
>>   * This prevents breakage of crash_notes attribute in kernel/ksysfs.c.
>> @@ -42,6 +68,8 @@ int machine_kexec_prepare(struct kimage *image)
>>  	__be32 header;
>>  	int i, err;
>>  
>> +	kexec_image_info(image);
>> +
>>  	image->arch.kernel_r2 = image->start - KEXEC_ARM_ZIMAGE_OFFSET
>>  				     + KEXEC_ARM_ATAGS_OFFSET;
>>  
>> -- 
>> 2.26.2
>> 
>> 

-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 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 v4 18/26] arm64: mte: Add PTRACE_{PEEK,POKE}MTETAGS support
From: Catalin Marinas @ 2020-06-01 16:33 UTC (permalink / raw)
  To: Luis Machado
  Cc: linux-arch, Omair Javaid, Szabolcs Nagy, Andrey Konovalov,
	Kevin Brodsky, Peter Collingbourne, linux-mm, Alan Hayward,
	Vincenzo Frascino, Will Deacon, Dave P Martin, linux-arm-kernel
In-Reply-To: <48197e4c-0b77-5e35-c735-922aede425c5@linaro.org>

On Mon, Jun 01, 2020 at 12:17:27PM -0300, Luis Machado wrote:
> On 6/1/20 9:07 AM, Catalin Marinas wrote:
> > On Fri, May 29, 2020 at 06:25:14PM -0300, Luis Machado wrote:
> > > I have a question about siginfo MTE information. I suppose SEGV_MTESERR will
> > > be the most useful setting for debugging, right? Does si_addr contain the
> > > tagged pointer with the logical tag, a zero-tagged memory address or a
> > > tagged pointer with the allocation tag?
> > 
> > The si_addr is zero-tagged currently. We were planning to expose the tag
> > in FAR_EL1 as a separate siginfo field. See these discussions:
> >
> > https://lore.kernel.org/linux-arm-kernel/20200513180914.50892-1-pcc@google.com/
> > https://lore.kernel.org/linux-arm-kernel/20200521022943.195898-1-pcc@google.com/
> > 
> > In theory, we could add the tag to si_addr for SEGV_MTESERR, it
> > shouldn't break the existing ABI (well, it depends on how you look at
> > it).
> 
> Having additional fields in siginfo that hold useful information is probably
> best for debuggers. See my comment below about Intel MPX.
> 
> > >  From the debugger user's perspective, one would want to see both the logical
> > > tag and the allocation tag. And it would be handy to have both available in
> > > siginfo. Does that make sense?
> > 
> > The debugger can access the allocation tag via PTRACE_PEEKMTETAGS. I
> > don't think the kernel should provide this in siginfo. Also, the signal
> > handler can do an LDG and read the allocation tag directly, no need for
> > it to be in siginfo.
> 
> While the debugger can request this information from the kernel, the
> debugger has already received a SIGSEGV signal and will have to fetch
> siginfo for si_code. Having to do another PTRACE_PEEKMTETAGS call just to
> fetch the allocation tag doesn't sound great. Remember this can travel
> through TCP to gdbserver so it can call ptrace from the remote's end. It
> would be best to avoid the round trip.

But given that this is supposed to be a rare event, does another round
trip to read some memory matter much?

> Also, there seems to be past precedent to include more information in
> siginfo. For example, Intel MPX includes upper/lower bounds violation data
> in there.

There is a possible race here with getting the allocation tag. For
example, another thread of the same process unmaps the memory and
reading the tag from the user memory is no longer possible. If we are to
add such information, we can't guarantee it's always possible (it may
differ from the MPX case).

In general, I don't like providing information that's already accessible
by other means (unless there's a performance issue but I don't think
that's the case here).

> Regarding using LDG, are you suggesting force-running this particular
> instruction in the traced process? If so, that isn't the way GDB (in
> particular, not sure about LLDB) does things.

No. What I meant is that if the signal handler itself needs the
information, it can execute an LDG. For gdb, the equivalent currently is
PTRACE_PEEKMTETAGS.

> > > Also, when would we see SEGV_MTEAERR, for example? That would provide no
> > > additional information about a particular memory address, which is not that
> > > useful for the debugger.
> > 
> > Yeah, we can't really do much here since the hardware doesn't provide us
> > such information. The async mode is only useful as a general test to see
> > if your program has MTE faults but for actual debugging you'd have to
> > switch to synchronous. For glibc at least, I think the mode can be
> > driven by an environment variable.
> 
> I suspect SEGV_MTESERR would be a reasonable default then, for whoever is
> responsible for setting the default settings.
> 
> I'm assuming it is not the debugger, as it doesn't know how to toggle prctl
> settings.

The debugger could set the environment before starting the debugged
process. But yes, that would be the C library.

-- 
Catalin

_______________________________________________
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 0/5 v2] KASan for ARM
From: Florian Fainelli @ 2020-06-01 16:36 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Abbott Liu, Andrey Ryabinin, Russell King, Linux ARM,
	Ard Biesheuvel
In-Reply-To: <CACRpkdZ5Dd92QYtKU8X+HHBFXXWm5m16htZ7vxeMTanxTQ=L1A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]



On 6/1/2020 1:55 AM, Linus Walleij wrote:
> On Mon, Jun 1, 2020 at 6:00 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
> 
>> Since this patch series has had many people trying to push it forward,
>> how about we try to get it merged as-is (minus bugs, see below) with the
>> caveat that TTRB0-less CPUs are not going to be supported for now and
>> later on, this gets lifted if we find a champion who can get that working?
> 
> Oh I fixed most issues in the v9 patch set, we ironed out the actual problem
> with ARMv4 and ARMv5 with some help from Ard, Catalin and then Russell
> suggested how to also improve the way we get taskinfo from sp in the
> assembly.
> 
>> I tested this on an ARMv8 system (Brahma-B53 CPU) and an ARMv7-A system
>> (Brahma-B15 CPU) with and without ARM_LPAE enabled and neither were able
>> to boot unless KASAN was turned off (outline instrumentation), I don't
>> even get to the point where earlyprintk is giving me anything which is
>> odd. Have not looked at the differences between this version and the one
>> I had sent before and have not hooked a debugger to find out where we
>> are hung.
>>
>> If you have a Raspberry Pi 4 you could use it as a test system for ARM_LPAE.
> 
> Did you try to use the v9 patch set on top of v5.7:
> https://lore.kernel.org/linux-arm-kernel/20200515114028.135674-1-linus.walleij@linaro.org/
> 
> I need to rebase this on v5.8-rc1 once it is out but it is working on all my
> targets now, there is also this git branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan

This branch got me a bit further, but still failed to fully initialize
(see attached kasan.log), on another platform with a slightly different
memory map, I ended up getting a different error (kasan2.log).
-- 
Florian

[-- Attachment #2: kasan.log --]
[-- Type: text/plain, Size: 6769 bytes --]

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.7.0-rc1-g17b3e5f7b19c (fainelli@fainelli-desktop) (gcc version 6.3.0 (crosstool-NG ), GNU ld (crosstool-NG )
2.26.20160125) #10 SMP Mon Jun 1 09:26:43 PDT 2020
[    0.000000] CPU: ARMv7 Processor [420f00f3] revision 3 (ARMv7), cr=30c5387d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] OF: fdt: Machine model: BCM97445VMS
[    0.000000] printk: bootconsole [earlycon0] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] cma: Reserved 16 MiB at 0x00000000bec00000
[    0.000000] kasan: populating shadow for b7000000, bd000000
[    0.000000] 8<--- cut here ---
[    0.000000] Unable to handle kernel paging request at virtual address bcbffe00
[    0.000000] pgd = (ptrval)
[    0.000000] [bcbffe00] *pgd=80000000006003, *pmd=00000000
[    0.000000] Internal error: Oops: 206 [#1] SMP ARM
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-rc1-g17b3e5f7b19c #10
[    0.000000] Hardware name: Broadcom STB (Flattened Device Tree)
[    0.000000] PC is at check_memory_region+0xb0/0x1bc
[    0.000000] LR is at 0x40
[    0.000000] pc : [<c044b060>]    lr : [<00000040>]    psr: 000000d3
[    0.000000] sp : c2803c58  ip : bcbffe00  fp : c2803c84
[    0.000000] r10: c16b5000  r9 : 00000000  r8 : bcc00000
[    0.000000] r7 : 00000000  r6 : 00000200  r5 : bcbfffff  r4 : edffffff
[    0.000000] r3 : c181cf10  r2 : 00000001  r1 : 00001000  r0 : edfff000
[    0.000000] Flags: nzcv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment user
[    0.000000] Control: 30c5387d  Table: 018731e0  DAC: fffffffd
[    0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval))
[    0.000000] Stack: (0xc2803c58 to 0xc2804000)
[    0.000000] 3c40:                                                       c181cf10 00001000
[    0.000000] 3c60: edfff000 00000000 00000000 00000001 00000000 c16b5000 c2803ca4 c2803c88
[    0.000000] 3c80: c0448ca8 c044afbc 00001000 00000000 edfff000 00000000 c2803ce4 c2803ca8
[    0.000000] 3ca0: c181cf10 c0448c8c 3fffffff 00000000 00000001 00000000 ffffffff 00000000
[    0.000000] 3cc0: 00000001 00000000 ffffffff ffffffff b71f6000 00000018 c2803d1c c2803ce8
[    0.000000] 3ce0: c180d578 c181ce68 3fffffff 00000000 00000001 00000000 ffffffff c180d7c0
[    0.000000] 3d00: ee1f6fb0 00000000 fffff000 00000000 c2803d4c c2803d20 c180d768 c180d508
[    0.000000] 3d20: 2e00071f c180d924 b71f6000 c2899de0 bd000000 00000000 c18730d8 00000018
[    0.000000] 3d40: c2803d6c c2803d50 c180d94c c180d724 c289a040 c2b51460 30000000 00000000
[    0.000000] 3d60: c2803dc4 c2803d70 c180db60 c180d8cc 02800000 00000000 c2b284c0 00000000
[    0.000000] 3d80: 0000001c ffff1000 0002ffff 00001000 30000000 00000000 30000000 c2f8c740
[    0.000000] 3da0: c0008000 c1870a44 c2899de0 e12fff1e c2803f40 c185e7a8 c2803ee4 c2803dc8
[    0.000000] 3dc0: c1805b48 c180d99c 0000006c 30c5387d 00000000 00000000 c1200740 c2803edc
[    0.000000] 3de0: c0226508 30c5387d 00000024 c2803df8 185007c0 c2803ea0 c1200740 c2803edc
[    0.000000] 3e00: 41b58ab3 c1641aa4 c1805368 c02b2060 c02b2c50 c02b3508 00000000 b75007cc
[    0.000000] 3e20: c2800000 30c0387d c2800000 c2806d40 c2803ed4 c2803e40 c02b2c50 c02b3508
[    0.000000] 3e40: c2803eb4 00000000 c2803e74 c2803e58 c2803e74 c2803e60 c0297cc0 c044ab08
[    0.000000] 3e60: 41b58ab3 c1643fe0 c02b2bbc c2803e78 c031c8ec c044ab08 00000000 c285fad8
[    0.000000] 3e80: c2803edc c0449634 c2803eb4 c2803e98 c0449634 c044a3c8 c2b4bf80 c2b4d680
[    0.000000] 3ea0: 00000000 c2800000 c2803ec4 c2803eb8 c044ab68 00000000 c2803ee4 b75007e4
[    0.000000] 3ec0: c2803fc0 30c0387d c2800000 c2806d40 420f00f3 30c5387d c2803ff4 c2803ee8
[    0.000000] 3ee0: c1800d3c c1805374 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f20: 41b58ab3 c1640b9c c1800c64 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f40: c1870a44 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c180d618
[    0.000000] 3f80: 00001000 00002b24 02b24403 00c00000 c2803fe4 c2803fa0 c180d684 c02281a8
[    0.000000] 3fa0: 02b24403 00c00000 00000000 00000000 c280a284 c2899de0 00000000 c1800334
[    0.000000] 3fc0: 00000000 00000000 ffffffff c1800334 00000000 30c0387d ffffffff 07723000
[    0.000000] 3fe0: 420f00f3 30c5387d 00000000 c2803ff8 00000000 c1800c70 00000000 00000000
[    0.000000] Backtrace:
[    0.000000] [<c044afb0>] (check_memory_region) from [<c0448ca8>] (memset+0x28/0x44)
[    0.000000]  r10:c16b5000 r9:00000000 r8:00000001 r7:00000000 r6:00000000 r5:edfff000
[    0.000000]  r4:00001000 r3:c181cf10
[    0.000000] [<c0448c80>] (memset) from [<c181cf10>] (memblock_alloc_try_nid+0xb4/0xc4)
[    0.000000]  r7:00000000 r6:edfff000 r5:00000000 r4:00001000
[    0.000000] [<c181ce5c>] (memblock_alloc_try_nid) from [<c180d578>] (kasan_alloc_block.constprop.7+0x7c/0x84)
[    0.000000]  r9:00000018 r8:b71f6000 r7:ffffffff r6:ffffffff r5:00000000 r4:00000001
[    0.000000] [<c180d4fc>] (kasan_alloc_block.constprop.7) from [<c180d768>] (kasan_pte_populate+0x50/0xb4)
[    0.000000]  r7:00000000 r6:fffff000 r5:00000000 r4:ee1f6fb0
[    0.000000] [<c180d718>] (kasan_pte_populate) from [<c180d94c>] (create_mapping.constprop.1+0x8c/0xa4)
[    0.000000]  r9:00000018 r8:c18730d8 r7:00000000 r6:bd000000 r5:c2899de0 r4:b71f6000
[    0.000000] [<c180d8c0>] (create_mapping.constprop.1) from [<c180db60>] (kasan_init+0x1d0/0x2f0)
[    0.000000]  r7:00000000 r6:30000000 r5:c2b51460 r4:c289a040
[    0.000000] [<c180d990>] (kasan_init) from [<c1805b48>] (setup_arch+0x7e0/0xfb0)
[    0.000000]  r10:c185e7a8 r9:c2803f40 r8:e12fff1e r7:c2899de0 r6:c1870a44 r5:c0008000
[    0.000000]  r4:c2f8c740
[    0.000000] [<c1805368>] (setup_arch) from [<c1800d3c>] (start_kernel+0xd8/0x5d8)
[    0.000000]  r10:30c5387d r9:420f00f3 r8:c2806d40 r7:c2800000 r6:30c0387d r5:c2803fc0
[    0.000000]  r4:b75007e4
[    0.000000] [<c1800c64>] (start_kernel) from [<00000000>] (0x0)
[    0.000000]  r10:30c5387d r9:420f00f3 r8:07723000 r7:ffffffff r6:30c0387d r5:00000000
[    0.000000]  r4:c1800334
[    0.000000] Code: e286e007 a1a0e006 e1b0e1ce 0a00002d (e1cc60d0)
[    0.000000] random: get_random_bytes called from print_oops_end_marker+0x48/0x58 with crng_init=0
[    0.000000] ---[ end trace 0000000000000000 ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

[-- Attachment #3: kasan2.log --]
[-- Type: text/plain, Size: 5162 bytes --]

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.7.0-rc1-g17b3e5f7b19c (fainelli@fainelli-desktop) (gcc version 6.3.0 (crosstool-NG ), GNU ld (crosstool-NG )
2.26.20160125) #10 SMP Mon Jun 1 09:26:43 PDT 2020
[    0.000000] CPU: ARMv7 Processor [420f1000] revision 0 (ARMv7), cr=30c5383d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: BCX972160DV
[    0.000000] printk: bootconsole [earlycon0] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] cma: Reserved 16 MiB at 0x00000000fcc00000
[    0.000000] kasan: populating shadow for b7000000, bd000000
[    0.000000] kasan: populating shadow for af000000, bd000000
[    0.000000] kasan: populating shadow for b6e00000, b7000000
[    0.000000] kasan: Kernel address sanitizer initialized
[    0.000000] ==================================================================
[    0.000000] BUG: KASAN: stack-out-of-bounds in unflatten_dt_nodes+0x5f8/0x75c
[    0.000000] Write of size 6 at addr df783afc by task swapper/0
[    0.000000]
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-rc1-g17b3e5f7b19c #10
[    0.000000] Hardware name: Broadcom STB (Flattened Device Tree)
[    0.000000] Backtrace:
[    0.000000] [<c0210d68>] (dump_backtrace) from [<c0211130>] (show_stack+0x20/0x24)
[    0.000000]  r7:c2977560 r6:00000000 r5:400000d3 r4:c2977560
[    0.000000] [<c0211110>] (show_stack) from [<c086ec70>] (dump_stack+0xc0/0xf0)
[    0.000000] [<c086ebb0>] (dump_stack) from [<c0449efc>] (print_address_description.constprop.2+0x78/0x4d4)
[    0.000000]  r10:c2803d40 r9:df7839b8 r8:00000001 r7:c0d58280 r6:edce2c78 r5:c2800000
[    0.000000]  r4:df783afc r3:edce2c80
[    0.000000] [<c0449e84>] (print_address_description.constprop.2) from [<c044a5fc>] (__kasan_report+0x124/0x158)
[    0.000000]  r8:00000001 r7:c0d58280 r6:00000000 r5:c2800000 r4:df783afc
[    0.000000] [<c044a4d8>] (__kasan_report) from [<c0449650>] (kasan_report+0x3c/0x44)
[    0.000000]  r8:baef0761 r7:c0d58280 r6:00000001 r5:00000006 r4:df783afc
[    0.000000] [<c0449614>] (kasan_report) from [<c044b0cc>] (check_memory_region+0x11c/0x1bc)
[    0.000000]  r7:df783afc r6:baef075f r5:baef0760 r4:df783b01
[    0.000000] [<c044afb0>] (check_memory_region) from [<c0448d80>] (memcpy+0x4c/0x70)
[    0.000000]  r10:c2803d40 r9:df7839b8 r8:c761e000 r7:df783afc r6:c7622030 r5:c0d58280
[    0.000000]  r4:00000006 r3:c0d58280
[    0.000000] [<c0448d34>] (memcpy) from [<c0d58280>] (unflatten_dt_nodes+0x5f8/0x75c)
[    0.000000]  r7:df783ab0 r6:df783ad0 r5:00000006 r4:c7622030
[    0.000000] [<c0d57c88>] (unflatten_dt_nodes) from [<c0d5851c>] (__unflatten_device_tree+0x118/0x398)
[    0.000000]  r10:00000000 r9:c2f81cc0 r8:df786ffc r7:df77976c r6:c761e000 r5:0000d890
[    0.000000]  r4:c2b1af70
[    0.000000] [<c0d58404>] (__unflatten_device_tree) from [<c1836a0c>] (unflatten_device_tree+0x44/0x54)
[    0.000000]  r10:c185e7a8 r9:00000000 r8:42800000 r7:c2b51490 r6:efffcd00 r5:00000000
[    0.000000]  r4:c1834efc
[    0.000000] [<c18369c8>] (unflatten_device_tree) from [<c1805fa8>] (setup_arch+0xc40/0xfb0)
[    0.000000]  r4:c185e7d0
[    0.000000] [<c1805368>] (setup_arch) from [<c1800d3c>] (start_kernel+0xd8/0x5d8)
[    0.000000]  r10:30c5387d r9:420f1000 r8:c2806d40 r7:c2800000 r6:30c0387d r5:c2803fc0
[    0.000000]  r4:b75007e4
[    0.000000] [<c1800c64>] (start_kernel) from [<00000000>] (0x0)
[    0.000000]  r10:30c5387d r9:420f1000 r8:4761e000 r7:ffffffff r6:30c0387d r5:00000000
[    0.000000]  r4:c1800334
[    0.000000]
[    0.000000] The buggy address belongs to the page:
[    0.000000] page:edce2c78 refcount:1 mapcount:0 mapping:(ptrval) index:0x0
[    0.000000] flags: 0x0()
[    0.000000] raw: 00000000 00000000 edce2c80 edce2c80 00000000 00000000 00000000 00000000
[    0.000000] raw: ffffffff 00000001
[    0.000000] page dumped because: kasan: bad access detected
[    0.000000]
[    0.000000] Memory state around the buggy address:
[    0.000000]  df783980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]  df783a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000] >df783a80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
[    0.000000]                                                         ^
[    0.000000]  df783b00: 04 f4 f4 f4 f2 f2 f2 f2 04 f4 f4 f4 f2 f2 f2 f2
[    0.000000]  df783b80: 04 f4 f4 f4 f2 f2 f2 f2 04 f4 f4 f4 f2 f2 f2 f2
[    0.000000] ==================================================================
[    0.000000] Disabling lock debugging due to kernel taint
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: Trusted OS migration not required
[    0.000000] psci: SMC Calling Convention v1.1
[    0.000000] percpu: Embedded 20 pages/cpu s49292 r8192 d24436 u81920
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 1038463
[    0.000000] Kernel command line: earlyprintk


[-- Attachment #4: 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 0/5 v2] KASan for ARM
From: Ard Biesheuvel @ 2020-06-01 16:40 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Abbott Liu, Linus Walleij, Russell King, Linux ARM,
	Andrey Ryabinin
In-Reply-To: <25cdd13f-1f95-1ca5-c28b-917538643590@gmail.com>

On Mon, 1 Jun 2020 at 18:37, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>
>
> On 6/1/2020 1:55 AM, Linus Walleij wrote:
> > On Mon, Jun 1, 2020 at 6:00 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >
> >> Since this patch series has had many people trying to push it forward,
> >> how about we try to get it merged as-is (minus bugs, see below) with the
> >> caveat that TTRB0-less CPUs are not going to be supported for now and
> >> later on, this gets lifted if we find a champion who can get that working?
> >
> > Oh I fixed most issues in the v9 patch set, we ironed out the actual problem
> > with ARMv4 and ARMv5 with some help from Ard, Catalin and then Russell
> > suggested how to also improve the way we get taskinfo from sp in the
> > assembly.
> >
> >> I tested this on an ARMv8 system (Brahma-B53 CPU) and an ARMv7-A system
> >> (Brahma-B15 CPU) with and without ARM_LPAE enabled and neither were able
> >> to boot unless KASAN was turned off (outline instrumentation), I don't
> >> even get to the point where earlyprintk is giving me anything which is
> >> odd. Have not looked at the differences between this version and the one
> >> I had sent before and have not hooked a debugger to find out where we
> >> are hung.
> >>
> >> If you have a Raspberry Pi 4 you could use it as a test system for ARM_LPAE.
> >
> > Did you try to use the v9 patch set on top of v5.7:
> > https://lore.kernel.org/linux-arm-kernel/20200515114028.135674-1-linus.walleij@linaro.org/
> >
> > I need to rebase this on v5.8-rc1 once it is out but it is working on all my
> > targets now, there is also this git branch:
> > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
>
> This branch got me a bit further, but still failed to fully initialize
> (see attached kasan.log), on another platform with a slightly different
> memory map, I ended up getting a different error (kasan2.log).

How can you be sure kasan2.log did not detect an actual bug?

_______________________________________________
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 5/5] arm: kexec_file: load zImage or uImage, initrd and dtb
From: Lukasz Stelmach @ 2020-06-01 16:46 UTC (permalink / raw)
  To: Russell King - ARM Linux admin
  Cc: Kees Cook, Bartlomiej Zolnierkiewicz, Masahiro Yamada,
	Nick Desaulniers, linux-kernel, AKASHI Takahiro, Ben Dooks,
	Thomas Gleixner, Enrico Weigelt, Ingo Molnar, linux-arm-kernel,
	Marek Szyprowski
In-Reply-To: <20200601151431.GN1551@shell.armlinux.org.uk>


[-- Attachment #1.1: Type: text/plain, Size: 1089 bytes --]

It was <2020-06-01 pon 16:14>, when Russell King - ARM Linux admin wrote:
> On Mon, Jun 01, 2020 at 04:07:45PM +0100, Russell King - ARM Linux admin wrote:
>> On Mon, Jun 01, 2020 at 04:27:54PM +0200, Łukasz Stelmach wrote:
>> > diff --git a/arch/arm/kernel/kexec_zimage.c b/arch/arm/kernel/kexec_zimage.c
>> > new file mode 100644
>> > index 000000000000..d09795fc9072
>> > --- /dev/null
>> > +++ b/arch/arm/kernel/kexec_zimage.c
>> > @@ -0,0 +1,199 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +/*
>> > + * Kexec zImage loader
>> > + *
>> > + * Copyright (C) 2020 Samsung Electronics
>> > + * Author: Łukasz Stelmach <l.stelmach@samsung.com>
>> 
>> Please credit me as part author of this - you have taken some of my
>> code from the userspace kexec tool (such as the contents of
>> find_extension_tag()) and copied it in here, so this is not all your
>> own work.
>
> It would also be a very good idea to indicate _where_ you copied some
> of this code from.

Sure thing. Done.

-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 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


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox