[PATCH 06/17] ARM: dts: r8a7742: Add SDHI nodes

[Lad Prabhakar]

Add the SDHI devices nodes to the R8A7742 device tree.

Signed-off-by: Lad Prabhakar 
Reviewed-by: Marian-Cristian Rotariu 
---
 arch/arm/boot/dts/r8a7742.dtsi | 60 ++
 1 file changed, 60 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
index f28c32d..0565472 100644
--- a/arch/arm/boot/dts/r8a7742.dtsi
+++ b/arch/arm/boot/dts/r8a7742.dtsi
@@ -717,6 +717,66 @@
status = "disabled";
};
 
+   sdhi0: sd@ee10 {
+   compatible = "renesas,sdhi-r8a7742",
+"renesas,rcar-gen2-sdhi";
+   reg = <0 0xee10 0 0x328>;
+   interrupts = ;
+   clocks = < CPG_MOD 314>;
+   dmas = < 0xcd>, < 0xce>,
+  < 0xcd>, < 0xce>;
+   dma-names = "tx", "rx", "tx", "rx";
+   max-frequency = <19500>;
+   power-domains = < R8A7742_PD_ALWAYS_ON>;
+   resets = < 314>;
+   status = "disabled";
+   };
+
+   sdhi1: sd@ee12 {
+   compatible = "renesas,sdhi-r8a7742",
+"renesas,rcar-gen2-sdhi";
+   reg = <0 0xee12 0 0x328>;
+   interrupts = ;
+   clocks = < CPG_MOD 313>;
+   dmas = < 0xc9>, < 0xca>,
+  < 0xc9>, < 0xca>;
+   dma-names = "tx", "rx", "tx", "rx";
+   max-frequency = <19500>;
+   power-domains = < R8A7742_PD_ALWAYS_ON>;
+   resets = < 313>;
+   status = "disabled";
+   };
+
+   sdhi2: sd@ee14 {
+   compatible = "renesas,sdhi-r8a7742",
+"renesas,rcar-gen2-sdhi";
+   reg = <0 0xee14 0 0x100>;
+   interrupts = ;
+   clocks = < CPG_MOD 312>;
+   dmas = < 0xc1>, < 0xc2>,
+  < 0xc1>, < 0xc2>;
+   dma-names = "tx", "rx", "tx", "rx";
+   max-frequency = <9750>;
+   power-domains = < R8A7742_PD_ALWAYS_ON>;
+   resets = < 312>;
+   status = "disabled";
+   };
+
+   sdhi3: sd@ee16 {
+   compatible = "renesas,sdhi-r8a7742",
+"renesas,rcar-gen2-sdhi";
+   reg = <0 0xee16 0 0x100>;
+   interrupts = ;
+   clocks = < CPG_MOD 311>;
+   dmas = < 0xd3>, < 0xd4>,
+  < 0xd3>, < 0xd4>;
+   dma-names = "tx", "rx", "tx", "rx";
+   max-frequency = <9750>;
+   power-domains = < R8A7742_PD_ALWAYS_ON>;
+   resets = < 311>;
+   status = "disabled";
+   };
+
mmcif1: mmc@ee22 {
compatible = "renesas,mmcif-r8a7742",
 "renesas,sh-mmcif";
-- 
2.7.4

[PATCH 11/17] dt-bindings: net: renesas,ether: Document R8A7742 SoC

[Lad Prabhakar]

Document RZ/G1H (R8A7742) SoC bindings.

Signed-off-by: Lad Prabhakar 
Reviewed-by: Marian-Cristian Rotariu 
---
 Documentation/devicetree/bindings/net/renesas,ether.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/net/renesas,ether.yaml 
b/Documentation/devicetree/bindings/net/renesas,ether.yaml
index c11eeb6..ce307e8 100644
--- a/Documentation/devicetree/bindings/net/renesas,ether.yaml
+++ b/Documentation/devicetree/bindings/net/renesas,ether.yaml
@@ -29,6 +29,7 @@ properties:
   - renesas,rcar-gen1-ether  # a generic R-Car Gen1 device
   - items:
   - enum:
+  - renesas,ether-r8a7742# device is a part of R8A7742 SoC
   - renesas,ether-r8a7743# device is a part of R8A7743 SoC
   - renesas,ether-r8a7745# device is a part of R8A7745 SoC
   - renesas,ether-r8a7790# device is a part of R8A7790 SoC
-- 
2.7.4

[PATCH 09/17] ARM: dts: r8a7742: Add sata nodes

[Lad Prabhakar]

Add the sata devices nodes to the R8A7742 device tree.

Signed-off-by: Lad Prabhakar 
Reviewed-by: Marian-Cristian Rotariu 
---
 arch/arm/boot/dts/r8a7742.dtsi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
index ca1a016..553b92f 100644
--- a/arch/arm/boot/dts/r8a7742.dtsi
+++ b/arch/arm/boot/dts/r8a7742.dtsi
@@ -809,6 +809,28 @@
max-frequency = <9750>;
};
 
+   sata0: sata@ee30 {
+   compatible = "renesas,sata-r8a7742",
+"renesas,rcar-gen2-sata";
+   reg = <0 0xee30 0 0x20>;
+   interrupts = ;
+   clocks = < CPG_MOD 815>;
+   power-domains = < R8A7742_PD_ALWAYS_ON>;
+   resets = < 815>;
+   status = "disabled";
+   };
+
+   sata1: sata@ee50 {
+   compatible = "renesas,sata-r8a7742",
+"renesas,rcar-gen2-sata";
+   reg = <0 0xee50 0 0x20>;
+   interrupts = ;
+   clocks = < CPG_MOD 814>;
+   power-domains = < R8A7742_PD_ALWAYS_ON>;
+   resets = < 814>;
+   status = "disabled";
+   };
+
gic: interrupt-controller@f1001000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
-- 
2.7.4

[PATCH 12/17] ARM: dts: r8a7742: Add Ethernet AVB support

[Lad Prabhakar]

Add Ethernet AVB support for R8A7742 SoC.

Signed-off-by: Lad Prabhakar 
Reviewed-by: Marian-Cristian Rotariu 
---
 arch/arm/boot/dts/r8a7742.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
index 553b92f..925bc8a 100644
--- a/arch/arm/boot/dts/r8a7742.dtsi
+++ b/arch/arm/boot/dts/r8a7742.dtsi
@@ -547,6 +547,19 @@
dma-channels = <15>;
};
 
+   avb: ethernet@e680 {
+   compatible = "renesas,etheravb-r8a7742",
+"renesas,etheravb-rcar-gen2";
+   reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
+   interrupts = ;
+   clocks = < CPG_MOD 812>;
+   power-domains = < R8A7742_PD_ALWAYS_ON>;
+   resets = < 812>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
scifa0: serial@e6c4 {
compatible = "renesas,scifa-r8a7742",
 "renesas,rcar-gen2-scifa", "renesas,scifa";
-- 
2.7.4

[PATCH 16/17] dt-bindings: watchdog: renesas,wdt: Document r8a7742 support

[Lad Prabhakar]

RZ/G1H (R8A7742) watchdog implementation is compatible with R-Car Gen2,
therefore add relevant documentation.

Signed-off-by: Lad Prabhakar 
Reviewed-by: Marian-Cristian Rotariu 
---
 Documentation/devicetree/bindings/watchdog/renesas,wdt.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.txt 
b/Documentation/devicetree/bindings/watchdog/renesas,wdt.txt
index 79b3c62..e42fd30 100644
--- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.txt
@@ -5,6 +5,7 @@ Required properties:
fallback compatible string when compatible with the generic
version.
   Examples with soctypes are:
+- "renesas,r8a7742-wdt" (RZ/G1H)
 - "renesas,r8a7743-wdt" (RZ/G1M)
 - "renesas,r8a7744-wdt" (RZ/G1N)
 - "renesas,r8a7745-wdt" (RZ/G1E)
-- 
2.7.4

Re: [PATCH] kobject: Make sure the parent does not get released before its children

[Greg Kroah-Hartman]

On Thu, May 14, 2020 at 09:54:15AM +0300, Heikki Krogerus wrote:
> On Wed, May 13, 2020 at 04:14:51PM -0700, Randy Dunlap wrote:
> > On 5/13/20 2:30 PM, Brendan Higgins wrote:
> > > On Wed, May 13, 2020 at 8:18 AM Heikki Krogerus
> > >  wrote:
> > >>
> > >> In the function kobject_cleanup(), kobject_del(kobj) is
> > >> called before the kobj->release(). That makes it possible to
> > >> release the parent of the kobject before the kobject itself.
> > >>
> > >> To fix that, adding function __kboject_del() that does
> > >> everything that kobject_del() does except release the parent
> > >> reference. kobject_cleanup() then calls __kobject_del()
> > >> instead of kobject_del(), and separately decrements the
> > >> reference count of the parent kobject after kobj->release()
> > >> has been called.
> > >>
> > >> Reported-by: Naresh Kamboju 
> > >> Reported-by: kernel test robot 
> > >> Fixes: 7589238a8cf3 ("Revert "software node: Simplify 
> > >> software_node_release() function"")
> > >> Cc: Brendan Higgins 
> > >> Cc: Randy Dunlap 
> > >> Suggested-by: "Rafael J. Wysocki" 
> > >> Signed-off-by: Heikki Krogerus 
> > > 
> > > Reviewed-by: Brendan Higgins 
> > > Tested-by: Brendan Higgins 
> > > 
> > 
> > Acked-by: Randy Dunlap 
> > Tested-by: Randy Dunlap 
> 
> Thanks guys. Sorry about the mix-up.

I didn't get the chance to review this today, will do so on Monday,
thanks.

greg k-h

[PATCH 14/17] dt-bindings: power: renesas,apmu: Document r8a7742 support

[Lad Prabhakar]

Document APMU and SMP enable method for RZ/G1H (also known as r8a7742)
SoC.

Signed-off-by: Lad Prabhakar 
Reviewed-by: Marian-Cristian Rotariu 
---
 Documentation/devicetree/bindings/power/renesas,apmu.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/power/renesas,apmu.yaml 
b/Documentation/devicetree/bindings/power/renesas,apmu.yaml
index 078b2cb..60a23b3 100644
--- a/Documentation/devicetree/bindings/power/renesas,apmu.yaml
+++ b/Documentation/devicetree/bindings/power/renesas,apmu.yaml
@@ -18,6 +18,7 @@ properties:
   compatible:
 items:
   - enum:
+  - renesas,r8a7742-apmu  # RZ/G1H
   - renesas,r8a7743-apmu  # RZ/G1M
   - renesas,r8a7744-apmu  # RZ/G1N
   - renesas,r8a7745-apmu  # RZ/G1E
-- 
2.7.4

[PATCH 13/17] ARM: dts: r8a7742: Add Ether support

[Lad Prabhakar]

Define the generic R8A7742 part of the Ether device node.

Signed-off-by: Lad Prabhakar 
Reviewed-by: Marian-Cristian Rotariu 
---
 arch/arm/boot/dts/r8a7742.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
index 925bc8a..1fe65f7 100644
--- a/arch/arm/boot/dts/r8a7742.dtsi
+++ b/arch/arm/boot/dts/r8a7742.dtsi
@@ -844,6 +844,20 @@
status = "disabled";
};
 
+   ether: ethernet@ee70 {
+   compatible = "renesas,ether-r8a7742",
+"renesas,rcar-gen2-ether";
+   reg = <0 0xee70 0 0x400>;
+   interrupts = ;
+   clocks = < CPG_MOD 813>;
+   power-domains = < R8A7742_PD_ALWAYS_ON>;
+   resets = < 813>;
+   phy-mode = "rmii";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
gic: interrupt-controller@f1001000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
-- 
2.7.4

[PATCH 04/17] dt-bindings: mmc: renesas,sdhi: Document r8a7742 support

[Lad Prabhakar]

Document SDHI controller for RZ/G1H (R8A7742) SoC, which is compatible
with R-Car Gen2 SoC family.

Signed-off-by: Lad Prabhakar 
Reviewed-by: Marian-Cristian Rotariu 
---
 Documentation/devicetree/bindings/mmc/renesas,sdhi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.txt 
b/Documentation/devicetree/bindings/mmc/renesas,sdhi.txt
index e6cc478..0ca9a62 100644
--- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.txt
+++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.txt
@@ -7,6 +7,7 @@ Required properties:
"renesas,sdhi-r7s9210" - SDHI IP on R7S9210 SoC
"renesas,sdhi-r8a73a4" - SDHI IP on R8A73A4 SoC
"renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
+   "renesas,sdhi-r8a7742" - SDHI IP on R8A7742 SoC
"renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC
"renesas,sdhi-r8a7744" - SDHI IP on R8A7744 SoC
"renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC
-- 
2.7.4

[PATCH 05/17] mmc: renesas_sdhi_sys_dmac: Add support for r8a7742 SoC

[Lad Prabhakar]

Add support for r8a7742 SoC. Renesas RZ/G1H (R8A7742) SDHI is identical to
the R-Car Gen2 family.

Signed-off-by: Lad Prabhakar 
Reviewed-by: Marian-Cristian Rotariu 
---
 drivers/mmc/host/renesas_sdhi_sys_dmac.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c 
b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
index 13ff023..dbfcbc2 100644
--- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
@@ -75,6 +75,7 @@ static const struct of_device_id 
renesas_sdhi_sys_dmac_of_match[] = {
{ .compatible = "renesas,sdhi-r7s72100", .data = _rz_compatible, },
{ .compatible = "renesas,sdhi-r8a7778", .data = 
_rcar_gen1_compatible, },
{ .compatible = "renesas,sdhi-r8a7779", .data = 
_rcar_gen1_compatible, },
+   { .compatible = "renesas,sdhi-r8a7742", .data = 
_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7743", .data = 
_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7745", .data = 
_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7790", .data = 
_rcar_gen2_compatible, },
-- 
2.7.4

[PATCH 03/17] ARM: dts: r8a7742: Add I2C and IIC support

[Lad Prabhakar]

Add the I2C[0-3] and IIC[0-3] devices nodes to the R8A7742 device tree.

Automatic transmission for PMIC control is not available on IIC3 hence
compatible string "renesas,rcar-gen2-iic" and "renesas,rmobile-iic" is
not added to iic3 node.

Signed-off-by: Lad Prabhakar 
Reviewed-by: Marian-Cristian Rotariu 
---
 arch/arm/boot/dts/r8a7742.dtsi | 122 +
 1 file changed, 122 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
index 305d808..f28c32d 100644
--- a/arch/arm/boot/dts/r8a7742.dtsi
+++ b/arch/arm/boot/dts/r8a7742.dtsi
@@ -359,6 +359,128 @@
ranges = <0 0 0xe630 0x4>;
};
 
+   i2c0: i2c@e6508000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,i2c-r8a7742",
+"renesas,rcar-gen2-i2c";
+   reg = <0 0xe6508000 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 931>;
+   power-domains = < R8A7742_PD_ALWAYS_ON>;
+   resets = < 931>;
+   i2c-scl-internal-delay-ns = <110>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@e6518000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,i2c-r8a7742",
+"renesas,rcar-gen2-i2c";
+   reg = <0 0xe6518000 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 930>;
+   power-domains = < R8A7742_PD_ALWAYS_ON>;
+   resets = < 930>;
+   i2c-scl-internal-delay-ns = <6>;
+   status = "disabled";
+   };
+
+   i2c2: i2c@e653 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,i2c-r8a7742",
+"renesas,rcar-gen2-i2c";
+   reg = <0 0xe653 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 929>;
+   power-domains = < R8A7742_PD_ALWAYS_ON>;
+   resets = < 929>;
+   i2c-scl-internal-delay-ns = <6>;
+   status = "disabled";
+   };
+
+   i2c3: i2c@e654 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,i2c-r8a7742",
+"renesas,rcar-gen2-i2c";
+   reg = <0 0xe654 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 928>;
+   power-domains = < R8A7742_PD_ALWAYS_ON>;
+   resets = < 928>;
+   i2c-scl-internal-delay-ns = <110>;
+   status = "disabled";
+   };
+
+   iic0: i2c@e650 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,iic-r8a7742",
+"renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
+   reg = <0 0xe650 0 0x425>;
+   interrupts = ;
+   clocks = < CPG_MOD 318>;
+   dmas = < 0x61>, < 0x62>,
+  < 0x61>, < 0x62>;
+   dma-names = "tx", "rx", "tx", "rx";
+   power-domains = < R8A7742_PD_ALWAYS_ON>;
+   resets = < 318>;
+   status = "disabled";
+   };
+
+   iic1: i2c@e651 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,iic-r8a7742",
+"renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
+   reg = <0 0xe651 0 0x425>;
+   interrupts = ;
+   clocks = < CPG_MOD 323>;
+   dmas = < 0x65>, < 0x66>,
+  < 0x65>, < 0x66>;
+   dma-names = "tx", "rx", "tx", "rx";
+   power-domains = < R8A7742_PD_ALWAYS_ON>;
+   resets = < 323>;
+   status = "disabled";
+   };
+
+   iic2: i2c@e652 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "renesas,iic-r8a7742",
+"renesas,rcar-gen2-iic",
+   

[PATCH 01/17] dt-bindings: i2c: renesas,i2c: Document r8a7742 support

[Lad Prabhakar]

Document i2c controller for RZ/G1H (R8A7742) SoC, which is compatible
with R-Car Gen2 SoC family.

Signed-off-by: Lad Prabhakar 
Reviewed-by: Marian-Cristian Rotariu 
---
 Documentation/devicetree/bindings/i2c/renesas,i2c.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/renesas,i2c.txt 
b/Documentation/devicetree/bindings/i2c/renesas,i2c.txt
index c359965..a03f9f5 100644
--- a/Documentation/devicetree/bindings/i2c/renesas,i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/renesas,i2c.txt
@@ -2,6 +2,7 @@ I2C for R-Car platforms
 
 Required properties:
 - compatible:
+   "renesas,i2c-r8a7742" if the device is a part of a R8A7742 SoC.
"renesas,i2c-r8a7743" if the device is a part of a R8A7743 SoC.
"renesas,i2c-r8a7744" if the device is a part of a R8A7744 SoC.
"renesas,i2c-r8a7745" if the device is a part of a R8A7745 SoC.
-- 
2.7.4

Re: [patch V5 04/38] x86: Make hardware latency tracing explicit

[Thomas Gleixner]

Steven Rostedt  writes:

> On Tue, 12 May 2020 23:01:03 +0200
> Thomas Gleixner  wrote:
>
>> --- a/arch/x86/kernel/cpu/mce/core.c
>> +++ b/arch/x86/kernel/cpu/mce/core.c
>> @@ -1916,7 +1916,7 @@ static __always_inline void exc_machine_
>>  mce_check_crashing_cpu())
>>  return;
>>  
>> -nmi_enter();
>> +nmi_enter_notrace();
>
> Now a machine check exception could happen and be a cause of latency
> (although there may be more issues if it does). The "nmi_enter trace"
> version does two things. One is for time measurements (if available),
> and the other is just letting the hardware latency know it happen (a
> simple increment).
>
> The only thing that is checked is "smp_processor_id()" (I just
> remembered it doesn't need per cpu, as it only runs on a single CPU at
> a time).
>
> Could the notrace version supply the increment, and leave the
> trace_clock() in the trace version?

Yes, I can split it up that way.

Re: [PATCH 4/4] thermal: core: genetlink support for events/cmd/sampling

[Daniel Lezcano]

On 15/05/2020 16:43, Srinivas Pandruvada wrote:
> On Fri, 2020-05-15 at 16:10 +0200, Daniel Lezcano wrote:
>> Initially the thermal framework had a very simple notification
>> mechanism to send generic netlink messages to the userspace.
>>
>> The notification function was never called from anywhere and the
>> corresponding dead code was removed. It was probably a first attempt
>> to introduce the netlink notification.
>>
>> At LPC2018, the presentation "Linux thermal: User kernel interface",
>> proposed to create the notifications to the userspace via a kfifo.
>>
>> The advantage of the kfifo is the performance. It is usually used
>> from
>> a 1:1 communication channel where a driver captures data and send
>> them
>> as fast as possible to an userspace process.
> Shall I submit my RFC using KFifo on top of this series? Any
> objections?

ATM the notification is not plugged with any thermal core code path. It
is separated on purpose in order to let your RFC to get some comments.

If you want to base your RFC on top of it, I'm perfectly fine with that.

I'll review your RFC now, I wanted to do that before but got busy with
another stuff.

If you want to compare kfifo and netlink, the userspace test programs
are at:

https://git.linaro.org/people/daniel.lezcano/thermal-genl.git/

IMO, using the kfifo for the sampling and the notifications/the commands
via netlink would make more sense.


-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH 02/17] dt-bindings: i2c: renesas,iic: Document r8a7742 support

[Lad Prabhakar]

Document IIC controller for RZ/G1H (R8A7742) SoC, which is compatible
with R-Car Gen2 SoC family.

Signed-off-by: Lad Prabhakar 
Reviewed-by: Marian-Cristian Rotariu 
---
 Documentation/devicetree/bindings/i2c/renesas,iic.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/renesas,iic.txt 
b/Documentation/devicetree/bindings/i2c/renesas,iic.txt
index ffe085c..89facb0 100644
--- a/Documentation/devicetree/bindings/i2c/renesas,iic.txt
+++ b/Documentation/devicetree/bindings/i2c/renesas,iic.txt
@@ -4,6 +4,7 @@ Required properties:
 - compatible  :
- "renesas,iic-r8a73a4" (R-Mobile APE6)
- "renesas,iic-r8a7740" (R-Mobile A1)
+   - "renesas,iic-r8a7742" (RZ/G1H)
- "renesas,iic-r8a7743" (RZ/G1M)
- "renesas,iic-r8a7744" (RZ/G1N)
- "renesas,iic-r8a7745" (RZ/G1E)
-- 
2.7.4

Re: [PATCH] blkcg: Fix memory leak in blkg_conf_prep()

[Markus Elfring]

…
> new_blkg = blkg_alloc(pos, q, GFP_KERNEL);
…

I suggest to omit the source code quotation from the change description.


> if calling blkg_lookup_check() failed, at the IS_ERR block,
> the new_blkg should be free before goto lable fail_unlock
> in blkg_conf_prep() function.

How do you think about a wording variant like the following?

  If a call of the function “blkg_lookup_check” failed,
  release the previously allocated block group before jumping
  to the target “fail_unlock” in the implementation of
  the function “blkg_conf_prep”.


Would you like to add the tag “Fixes” to the commit message?

Regards,
Markus

[PATCH 00/17] RZ/G1H describe I2C, IIC, MMC0, SATA, AVB, RWDT and APMU nodes

[Lad Prabhakar]

Hi All,

This patch series describes i2c, iic, mmc0, sdhi, sata, AVB, apmu and
RWDT on R8A7742 SoC.

Cheers,
Prabhakar

Lad Prabhakar (17):
  dt-bindings: i2c: renesas,i2c: Document r8a7742 support
  dt-bindings: i2c: renesas,iic: Document r8a7742 support
  ARM: dts: r8a7742: Add I2C and IIC support
  dt-bindings: mmc: renesas,sdhi: Document r8a7742 support
  mmc: renesas_sdhi_sys_dmac: Add support for r8a7742 SoC
  ARM: dts: r8a7742: Add SDHI nodes
  ARM: dts: r8a7742: Add MMC0 node
  dt-bindings: ata: renesas,rcar-sata: Add r8a7742 support
  ARM: dts: r8a7742: Add sata nodes
  dt-bindings: net: renesas,ravb: Add support for r8a7742 SoC
  dt-bindings: net: renesas,ether: Document R8A7742 SoC
  ARM: dts: r8a7742: Add Ethernet AVB support
  ARM: dts: r8a7742: Add Ether support
  dt-bindings: power: renesas,apmu: Document r8a7742 support
  ARM: dts: r8a7742: Add APMU nodes
  dt-bindings: watchdog: renesas,wdt: Document r8a7742 support
  ARM: dts: r8a7742: Add RWDT node

 .../devicetree/bindings/ata/renesas,rcar-sata.yaml |   1 +
 .../devicetree/bindings/i2c/renesas,i2c.txt|   1 +
 .../devicetree/bindings/i2c/renesas,iic.txt|   1 +
 .../devicetree/bindings/mmc/renesas,sdhi.txt   |   1 +
 .../devicetree/bindings/net/renesas,ether.yaml |   1 +
 .../devicetree/bindings/net/renesas,ravb.txt   |   1 +
 .../devicetree/bindings/power/renesas,apmu.yaml|   1 +
 .../devicetree/bindings/watchdog/renesas,wdt.txt   |   1 +
 arch/arm/boot/dts/r8a7742.dtsi | 270 +
 drivers/mmc/host/renesas_sdhi_sys_dmac.c   |   1 +
 10 files changed, 279 insertions(+)

-- 
2.7.4

Re: [PATCH v2 17/19] spi: dw: Add DMA support to the DW SPI MMIO driver

[Andy Shevchenko]

On Fri, May 15, 2020 at 01:47:56PM +0300, Serge Semin wrote:
> Since the common code in the spi-dw-dma.c driver is ready to be used
> by the MMIO driver and now provides a method to generically (on any
> DT or ACPI-based platforms) retrieve the Tx/Rx DMA channel handlers,
> we can use it and a set of the common DW SPI DMA callbacks to enable
> DMA at least for generic "snps,dw-apb-ssi" and "snps,dwc-ssi-1.01a"
> devices.

Reviewed-by: Andy Shevchenko 

> 
> Co-developed-by: Georgy Vlasov 
> Signed-off-by: Georgy Vlasov 
> Co-developed-by: Ramil Zaripov 
> Signed-off-by: Ramil Zaripov 
> Signed-off-by: Serge Semin 
> Cc: Alexey Malahov 
> Cc: Thomas Bogendoerfer 
> Cc: Paul Burton 
> Cc: Ralf Baechle 
> Cc: Arnd Bergmann 
> Cc: Allison Randal 
> Cc: Andy Shevchenko 
> Cc: Gareth Williams 
> Cc: Rob Herring 
> Cc: linux-m...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> ---
>  drivers/spi/spi-dw-mmio.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
> index 0894b4c09496..e23d0c53a664 100644
> --- a/drivers/spi/spi-dw-mmio.c
> +++ b/drivers/spi/spi-dw-mmio.c
> @@ -149,6 +149,8 @@ static int dw_spi_dw_apb_init(struct platform_device 
> *pdev,
>   /* Register hook to configure CTRLR0 */
>   dwsmmio->dws.update_cr0 = dw_spi_update_cr0;
>  
> + dw_spi_dma_setup_generic(>dws);
> +
>   return 0;
>  }
>  
> @@ -158,6 +160,8 @@ static int dw_spi_dwc_ssi_init(struct platform_device 
> *pdev,
>   /* Register hook to configure CTRLR0 */
>   dwsmmio->dws.update_cr0 = dw_spi_update_cr0_v1_01a;
>  
> + dw_spi_dma_setup_generic(>dws);
> +
>   return 0;
>  }
>  
> -- 
> 2.25.1
> 

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] coresight: etm4x: Add support to disable trace unit power up

[Sai Prakash Ranjan]

Hi Mathieu,

On 2020-05-15 20:22, Mathieu Poirier wrote:

On Thu, 14 May 2020 at 12:39, Sai Prakash Ranjan
 wrote:


Hi Mathieu,

On 2020-05-14 23:30, Mathieu Poirier wrote:
> Good morning Sai,
>
> On Thu, May 14, 2020 at 04:29:15PM +0530, Sai Prakash Ranjan wrote:
>> From: Tingwei Zhang 
>>
>> On some Qualcomm Technologies Inc. SoCs like SC7180, there
>> exists a hardware errata where the APSS (Application Processor
>> SubSystem)/CPU watchdog counter is stopped when ETM register
>> TRCPDCR.PU=1.
>
> Fun stuff...
>

Yes :)

>> Since the ETMs share the same power domain as
>> that of respective CPU cores, they are powered on when the
>> CPU core is powered on. So we can disable powering up of the
>> trace unit after checking for this errata via new property
>> called "qcom,tupwr-disable".
>>
>> Signed-off-by: Tingwei Zhang 
>> Co-developed-by: Sai Prakash Ranjan 
>> Signed-off-by: Sai Prakash Ranjan 
>
> Co-developed-by: Sai Prakash Ranjan 
> Signed-off-by: Tingwei Zhang 
>

Tingwei is the author, so if I understand correctly, his signed-off-by
should appear first, am I wrong?


It's a gray area and depends on who's code is more prevalent in the
patch.  If Tingwei wrote the most of the code then his name is in the
"from:" section, yours as co-developer and he signs off on it (as I
suggested).  If you did most of the work then it is the opposite.
Adding a Co-developed and a signed-off with the same name doesn't make
sense.



I did check the documentation for submitting patches:
Documentation/process/submitting-patches.rst. And it clearly states
that "Co-developed-by must be followed by Signed-off by the co-author
and the last Signed-off-by: must always be that of the developer
submitting the patch".

Quoting below from the doc:

Co-developed-by:  ...Since
Co-developed-by: denotes authorship, every Co-developed-by: must be 
immediately
followed by a Signed-off-by: of the associated co-author.  Standard 
sign-off
procedure applies, i.e. the ordering of Signed-off-by: tags should 
reflect the
chronological history of the patch insofar as possible, regardless of 
whether
the author is attributed via From: or Co-developed-by:.  Notably, the 
last
Signed-off-by: must always be that of the developer submitting the 
patch.




>> ---
>>  .../devicetree/bindings/arm/coresight.txt |  6 
>>  drivers/hwtracing/coresight/coresight-etm4x.c | 29
>> ---
>
> Please split in two patches.
>

Sure, I will split the dt-binding into separate patch, checkpatch did
warn.


And you still sent me the patch...  I usually run checkpatch before
all the submissions I review and flatly ignore patches that return
errors.  You got lucky...



I did not mean to ignore it or else I wouldn't have run checkpatch 
itself.
I checked other cases like "arm,scatter-gather" where the binding and 
the
driver change was in a single patch, hence I thought it's not a very 
strict rule.


Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH] keys: Move permissions checking decisions into the checking code

[Stephen Smalley]

On Thu, May 14, 2020 at 12:59 PM David Howells  wrote:
>
> How about this then?
>
> David
> ---
> commit fa37b6c7e2f86d16ede1e0e3cb73857152d51825
> Author: David Howells 
> Date:   Thu May 14 17:48:55 2020 +0100
>
> keys: Move permissions checking decisions into the checking code
>
> Overhaul the permissions checking, moving the decisions of which permits 
> to
> request for what operation and what overrides to allow into the 
> permissions
> checking functions in keyrings, SELinux and Smack.
>
> To this end, the KEY_NEED_* constants are turned into an enum and expanded
> in number to cover operation types individually.
>
> Note that some more tweaking is probably needed to separate kernel uses,
> e.g. AFS using rxrpc keys, from direct userspace users.
>
> Some overrides are available and this needs to be handled specially:
>
>  (1) KEY_FLAG_KEEP in key->flags - The key may not be deleted and/or 
> things
>  may not be removed from the keyring.

Why can't they be deleted / removed?  They can't ever be deleted or
removed or for some period of time?

>  (2) KEY_FLAG_ROOT_CAN_CLEAR in key->flags - The keyring can be cleared by
>  CAP_SYS_ADMIN.

Why do some keyrings get this flag and others do not?  Under what
conditions?  Why is CAP_SYS_ADMIN the right capability for this?

>  (3) KEY_FLAG_ROOT_CAN_INVAL in key->flags - The key can be invalidated by
>  CAP_SYS_ADMIN.

Ditto.

>  (4) An appropriate auth token being set in cred->request_key_auth that
>  gives a process transient permission to view and instantiate a key.
>  This is used by the kernel to delegate instantiation to userspace.

Is this ever allowed across different credentials?  When?  Why?  Is
there a check between the different credentials before the auth token
is created?

> Note that this requires some tweaks to the testsuite as some of the error
> codes change.

Which testsuite?  keyring or selinux or both?  What error codes change
(from what to what)?  Does this constitute an ABI change?

I like moving more of the permission checking logic into the security
modules and giving them greater visibility and control.  That said, I
am somewhat concerned by the scale of this change, by the extent to
which you are exposing keyring internals inside the security modules,
and by the extent to which logic is getting duplicated in each
security module.  I'd suggest a more incremental approach, e.g. start
with just the enum patch, then migrate the easy cases, then consider
the more complicated cases.  And possibly we need multiple different
security hooks for the keyring subsystem that are more specialized for
the complicated cases.  If we authorize the delegation up front, we
don't need to check it later.

Re: [PATCH RESEND 3/4] Documentation/litmus-tests: Merge atomic's README into top-level one

[Paul E. McKenney]

On Sat, May 16, 2020 at 12:01:41AM +0900, Akira Yokosawa wrote:
> On Thu, 14 May 2020 15:45:58 -0700, Paul E. McKenney wrote:
> > On Fri, May 15, 2020 at 07:03:33AM +0900, Akira Yokosawa wrote:
> >> On Thu, 14 May 2020 10:16:56 -0700, Paul E. McKenney wrote:
> >>> On Thu, May 14, 2020 at 08:46:18AM +0800, Boqun Feng wrote:
>  On Wed, May 13, 2020 at 06:39:03AM +0900, Akira Yokosawa wrote:
> > From 96fa6680e3b990633ecbb6d11acf03a161b790bd Mon Sep 17 00:00:00 2001
> > From: Akira Yokosawa 
> > Date: Sun, 10 May 2020 15:12:57 +0900
> > Subject: [PATCH RESEND 3/4] Documentation/litmus-tests: Merge atomic's 
> > README into top-level one
> >
> > Where Documentation/litmus-tests/README lists RCU litmus tests,
> > Documentation/litmus-tests/atomic/README lists atomic litmus tests.
> > For symmetry, merge the latter into former, with some context
> > adjustment in the introduction.
> >
> > Signed-off-by: Akira Yokosawa 
> > Acked-by: Andrea Parri 
> > Acked-by: Joel Fernandes (Google) 
> 
>  Acked-by: Boqun Feng 
> 
>  Thanks!
> >>>
> >>> Applied, and thank you all!
> >>>
> >>> I rebased, cancelling the revert with the original, resulting in an
> >>> updated lkmm branch on -rcu.  There was one minor conflict, so could
> >>> one of you please check to make sure that I resolved things appropriately?
> >>
> >> One thing I noticed.
> >>
> >> Commit b2998782ded4 ("Documentation/litmus-tests: Clarify about the RCU
> >> pre-initialization test")'s change log says:
> >>
> >> Since this test returned to tools/memory-model/, make sure that it is
> >> ~~~
> >> at least referenced from Documentation/litmus-tests/'s README.
> >>
> >> Because of the rebase, this needs amendment as well as the title.
> >>
> >> Something like
> >>
> >> Documentation/litumus-tests: Cite a relevant litmus test in 
> >> tools/memory-model
> >>
> >> For ease of finding the RCU related litmus test under
> >> tools/memory-model/, add an entry in README.
> >>
> >> ?
> > 
> > Good catch, and yes, I will update that on the next rebase.
> > 
> > Any other things in need of adjustment?
> 
> Aside from the missing Signed-off-by tags Stephen pointed out, I don't
> see anything.

Yeah, I did mess that up!  ;-)

Thank you for checking!!!

Thanx, Paul

Re: [PATCH v3 3/4] serial: 8250_dw: Simplify the ref clock rate setting procedure

[Andy Shevchenko]

On Fri, May 15, 2020 at 05:50:07PM +0300, Serge Semin wrote:
> On Fri, May 15, 2020 at 05:05:47PM +0300, Andy Shevchenko wrote:
> > On Thu, May 07, 2020 at 02:31:34AM +0300, Serge Semin wrote:
> > > Really instead of twice checking the clk_round_rate() return value
> > > we could do it once, and if it isn't error the clock rate can be changed.
> > > By doing so we decrease a number of ret-value tests and remove a weird
> > > goto-based construction implemented in the dw8250_set_termios() method.
> > 
> > >   rate = clk_round_rate(d->clk, baud * 16);
> > > - if (rate < 0)
> > > - ret = rate;
> > 
> > > - else if (rate == 0)
> > > - ret = -ENOENT;
> > 
> > This case now handled differently.
> > I don't think it's good idea to change semantics.
> > 
> > So, I don't see how this, after leaving the rate==0 case, would be better 
> > than
> > original one.
> 
> Semantic doesn't change. The code does exactly the same as before. If it 
> didn't
> I either would have provided a comment about this or just didn't introduce the
> change in the first place. I guess you just don't see the whole picture of the
> method. Take a look in the code. The ret variable's been used to skip the
> "p->uartclk = rate" assignment. That's it. So the (rate == 0) will still be
> considered as error condition, which causes the clock rate left unchanged.
> Here is the code diff so you wouldn't need to dive deep into the driver
> sources:
> 
> < clk_disable_unprepare(d->clk);
> < rate = clk_round_rate(d->clk, baud * 16);
> < if (rate < 0)
> < ret = rate;
> < else if (rate == 0)
> < ret = -ENOENT;
> < else
> < ret = clk_set_rate(d->clk, rate);
> < clk_prepare_enable(d->clk);
> <
> < if (ret)
> < goto out;
> <
> < p->uartclk = rate;
> <
>  ---
> >   clk_disable_unprepare(d->clk);
> >   rate = clk_round_rate(d->clk, baud * 16);
> >   if (rate > 0) {
> >  ret = clk_set_rate(d->clk, rate);
> >  if (!ret)
> >  p->uartclk = rate;
> >   }
> >   clk_prepare_enable(d->clk);

Thanks.
Indeed, in the above it looks clear.



-- 
With Best Regards,
Andy Shevchenko

Re: linux-next: Tree for May 12 (fs/namespace.c)

[Randy Dunlap]

On 5/12/20 8:12 AM, Randy Dunlap wrote:
> On 5/12/20 5:54 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> News: there will be no linux-next release tomorrow.
>>
>> Changes since 20200511:
>>
>> New trees: notifications, fsinfo
>>
> 
> on i386 or x86_64:
> 
>   CC  fs/namespace.o
> ../fs/namespace.c: In function ‘fsinfo_generic_mount_topology’:
> ../fs/namespace.c:4274:42: error: ‘struct mount’ has no member named 
> ‘mnt_topology_changes’
>   p->mnt_topology_changes = atomic_read(>mnt_topology_changes);
>   ^~
> 
> i.e., CONFIG_MOUNT_NOTIFICATIONS is not set/enabled.
> 
> Full randconfig file is attached.
> 

This build error is still present in linux-next 20200515.


-- 
~Randy
Reported-by: Randy Dunlap 

Re: [PATCH v2 15/19] spi: dw: Add DW SPI DMA/PCI/MMIO dependency on the DW SPI core

[Andy Shevchenko]

On Fri, May 15, 2020 at 01:47:54PM +0300, Serge Semin wrote:
> Seeing all of the DW SPI driver components like DW SPI DMA/PCI/MMIO
> depend on the DW SPI core code it's better to use the if-endif
> conditional kernel config statement to signify that common dependency.

Makes sense!
Reviewed-by: Andy Shevchenko 

> 
> Co-developed-by: Georgy Vlasov 
> Signed-off-by: Georgy Vlasov 
> Co-developed-by: Ramil Zaripov 
> Signed-off-by: Ramil Zaripov 
> Signed-off-by: Serge Semin 
> Cc: Alexey Malahov 
> Cc: Thomas Bogendoerfer 
> Cc: Paul Burton 
> Cc: Ralf Baechle 
> Cc: Arnd Bergmann 
> Cc: Allison Randal 
> Cc: Andy Shevchenko 
> Cc: Gareth Williams 
> Cc: Rob Herring 
> Cc: linux-m...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> ---
>  drivers/spi/Kconfig | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 6a84f3dad35c..3cdf8310d185 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -226,17 +226,20 @@ config SPI_DESIGNWARE
>   help
> general driver for SPI controller core from DesignWare
>  
> +if SPI_DESIGNWARE
> +
>  config SPI_DW_DMA
>   bool "DMA support for DW SPI controller"
> - depends on SPI_DESIGNWARE
>  
>  config SPI_DW_PCI
>   tristate "PCI interface driver for DW SPI core"
> - depends on SPI_DESIGNWARE && PCI
> + depends on PCI
>  
>  config SPI_DW_MMIO
>   tristate "Memory-mapped io interface driver for DW SPI core"
> - depends on SPI_DESIGNWARE
> + depends on HAS_IOMEM
> +
> +endif
>  
>  config SPI_DLN2
> tristate "Diolan DLN-2 USB SPI adapter"
> -- 
> 2.25.1
> 

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 05/19] staging: wfx: fix coherency of hif_scan() prototype

[Jérôme Pouiller]

On Friday 15 May 2020 15:53:59 CEST Greg Kroah-Hartman wrote:
> On Fri, May 15, 2020 at 10:33:11AM +0200, Jerome Pouiller wrote:
> > From: Jérôme Pouiller 
> >
> > The function hif_scan() return the timeout for the completion of the
> > scan request. It is the only function from hif_tx.c that return another
> > thing than just an error code. This behavior is not coherent with the
> > rest of file. Worse, if value returned is positive, the caller can't
> > make say if it is a timeout or the value returned by the hardware.
> >
> > Uniformize API with other HIF functions, only return the error code and
> > pass timeout with parameters.
> >
> > Signed-off-by: Jérôme Pouiller 
> > ---
> >  drivers/staging/wfx/hif_tx.c | 6 --
> >  drivers/staging/wfx/hif_tx.h | 2 +-
> >  drivers/staging/wfx/scan.c   | 6 +++---
> >  3 files changed, 8 insertions(+), 6 deletions(-)
> 
> This patch fails to apply to my branch, so I've stopped here in the
> patch series.

Hello Greg,

Did you applied the patch called "staging: wfx: unlock on error path" from
Dan?

(I wrote that information in the introduction letter, but maybe I would
had include the Dan's patch in my PR?)


-- 
Jérôme Pouiller

[PATCH -tip 03/10] kcsan: Support distinguishing volatile accesses

[Marco Elver]

In the kernel, volatile is used in various concurrent context, whether
in low-level synchronization primitives or for legacy reasons. If
supported by the compiler, we will assume that aligned volatile accesses
up to sizeof(long long) (matching compiletime_assert_rwonce_type()) are
atomic.

Recent versions Clang [1] (GCC tentative [2]) can instrument volatile
accesses differently. Add the option (required) to enable the
instrumentation, and provide the necessary runtime functions. None of
the updated compilers are widely available yet (Clang 11 will be the
first release to support the feature).

[1] 
https://github.com/llvm/llvm-project/commit/5a2c31116f412c3b6888be361137efd705e05814
[2] https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544452.html

This patch allows removing any explicit checks in primitives such as
READ_ONCE() and WRITE_ONCE().

Signed-off-by: Marco Elver 
---
 kernel/kcsan/core.c| 43 ++
 scripts/Makefile.kcsan |  5 -
 2 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c
index a73a66cf79df..15f67949d11e 100644
--- a/kernel/kcsan/core.c
+++ b/kernel/kcsan/core.c
@@ -789,6 +789,49 @@ void __tsan_write_range(void *ptr, size_t size)
 }
 EXPORT_SYMBOL(__tsan_write_range);
 
+/*
+ * Use of explicit volatile is generally disallowed [1], however, volatile is
+ * still used in various concurrent context, whether in low-level
+ * synchronization primitives or for legacy reasons.
+ * [1] https://lwn.net/Articles/233479/
+ *
+ * We only consider volatile accesses atomic if they are aligned and would pass
+ * the size-check of compiletime_assert_rwonce_type().
+ */
+#define DEFINE_TSAN_VOLATILE_READ_WRITE(size)  
\
+   void __tsan_volatile_read##size(void *ptr) \
+   {  \
+   const bool is_atomic = size <= sizeof(long long) &&\
+  IS_ALIGNED((unsigned long)ptr, size);   \
+   if (IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS) && is_atomic)  \
+   return;\
+   check_access(ptr, size, is_atomic ? KCSAN_ACCESS_ATOMIC : 0);  \
+   }  \
+   EXPORT_SYMBOL(__tsan_volatile_read##size); \
+   void __tsan_unaligned_volatile_read##size(void *ptr)   \
+   __alias(__tsan_volatile_read##size);   \
+   EXPORT_SYMBOL(__tsan_unaligned_volatile_read##size);   \
+   void __tsan_volatile_write##size(void *ptr)\
+   {  \
+   const bool is_atomic = size <= sizeof(long long) &&\
+  IS_ALIGNED((unsigned long)ptr, size);   \
+   if (IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS) && is_atomic)  \
+   return;\
+   check_access(ptr, size,\
+KCSAN_ACCESS_WRITE |  \
+(is_atomic ? KCSAN_ACCESS_ATOMIC : 0));   \
+   }  \
+   EXPORT_SYMBOL(__tsan_volatile_write##size);\
+   void __tsan_unaligned_volatile_write##size(void *ptr)  \
+   __alias(__tsan_volatile_write##size);  \
+   EXPORT_SYMBOL(__tsan_unaligned_volatile_write##size)
+
+DEFINE_TSAN_VOLATILE_READ_WRITE(1);
+DEFINE_TSAN_VOLATILE_READ_WRITE(2);
+DEFINE_TSAN_VOLATILE_READ_WRITE(4);
+DEFINE_TSAN_VOLATILE_READ_WRITE(8);
+DEFINE_TSAN_VOLATILE_READ_WRITE(16);
+
 /*
  * The below are not required by KCSAN, but can still be emitted by the
  * compiler.
diff --git a/scripts/Makefile.kcsan b/scripts/Makefile.kcsan
index 20337a7ecf54..c02662b30a7c 100644
--- a/scripts/Makefile.kcsan
+++ b/scripts/Makefile.kcsan
@@ -9,7 +9,10 @@ else
 cc-param = --param -$(1)
 endif
 
+# Most options here should be kept optional, to allow enabling more compilers
+# if the absence of some options still allows us to use KCSAN in most cases.
 CFLAGS_KCSAN := -fsanitize=thread \
-   $(call cc-option,$(call cc-param,tsan-instrument-func-entry-exit=0) 
-fno-optimize-sibling-calls)
+   $(call cc-option,$(call cc-param,tsan-instrument-func-entry-exit=0) 
-fno-optimize-sibling-calls) \
+   $(call cc-param,tsan-distinguish-volatile=1)
 
 endif # CONFIG_KCSAN
-- 
2.26.2.761.g0e0b3e54be-goog

[PATCH -tip 06/10] kcsan: Restrict supported compilers

[Marco Elver]

The first version of Clang that supports -tsan-distinguish-volatile will
be able to support KCSAN. The first Clang release to do so, will be
Clang 11. This is due to satisfying all the following requirements:

1. Never emit calls to __tsan_func_{entry,exit}.

2. __no_kcsan functions should not call anything, not even
   kcsan_{enable,disable}_current(), when using __{READ,WRITE}_ONCE => Requires
   leaving them plain!

3. Support atomic_{read,set}*() with KCSAN, which rely on
   arch_atomic_{read,set}*() using __{READ,WRITE}_ONCE() => Because of
   #2, rely on Clang 11's -tsan-distinguish-volatile support. We will
   double-instrument atomic_{read,set}*(), but that's reasonable given
   it's still lower cost than the data_race() variant due to avoiding 2
   extra calls (kcsan_{en,dis}able_current() calls).

4. __always_inline functions inlined into __no_kcsan functions are never
   instrumented.

5. __always_inline functions inlined into instrumented functions are
   instrumented.

6. __no_kcsan_or_inline functions may be inlined into __no_kcsan functions =>
   Implies leaving 'noinline' off of __no_kcsan_or_inline.

7. Because of #6, __no_kcsan and __no_kcsan_or_inline functions should never be
   spuriously inlined into instrumented functions, causing the accesses of the
   __no_kcsan function to be instrumented.

Older versions of Clang do not satisfy #3. The latest GCC currently doesn't
support at least #1, #3, and #7.

Link: 
https://lkml.kernel.org/r/CANpmjNMTsY_8241bS7=xafqvzhflrvekv_um4aduwe_kh3r...@mail.gmail.com
Signed-off-by: Marco Elver 
---
 lib/Kconfig.kcsan | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/lib/Kconfig.kcsan b/lib/Kconfig.kcsan
index a7276035ca0d..3f3b5bca7a8f 100644
--- a/lib/Kconfig.kcsan
+++ b/lib/Kconfig.kcsan
@@ -3,6 +3,12 @@
 config HAVE_ARCH_KCSAN
bool
 
+config HAVE_KCSAN_COMPILER
+   def_bool CC_IS_CLANG && $(cc-option,-fsanitize=thread -mllvm 
-tsan-distinguish-volatile=1)
+   help
+ For the list of compilers that support KCSAN, please see
+ .
+
 config KCSAN_KCOV_BROKEN
def_bool KCOV && CC_HAS_SANCOV_TRACE_PC
depends on CC_IS_CLANG
@@ -15,7 +21,8 @@ config KCSAN_KCOV_BROKEN
 
 menuconfig KCSAN
bool "KCSAN: dynamic data race detector"
-   depends on HAVE_ARCH_KCSAN && DEBUG_KERNEL && !KASAN
+   depends on HAVE_ARCH_KCSAN && HAVE_KCSAN_COMPILER
+   depends on DEBUG_KERNEL && !KASAN
depends on !KCSAN_KCOV_BROKEN
select STACKTRACE
help
-- 
2.26.2.761.g0e0b3e54be-goog

[PATCH -tip 02/10] kcsan: Avoid inserting __tsan_func_entry/exit if possible

[Marco Elver]

To avoid inserting  __tsan_func_{entry,exit}, add option if supported by
compiler. Currently only Clang can be told to not emit calls to these
functions. It is safe to not emit these, since KCSAN does not rely on
them.

Note that, if we disable __tsan_func_{entry,exit}(), we need to disable
tail-call optimization in sanitized compilation units, as otherwise we
may skip frames in the stack trace; in particular when the tail called
function is one of the KCSAN's runtime functions, and a report is
generated, might we miss the function where the actual access occurred.
Since __tsan_func_{entry,exit}() insertion effectively disabled
tail-call optimization, there should be no observable change. [This was
caught and confirmed with kcsan-test & UNWINDER_ORC.]

Signed-off-by: Marco Elver 
---
 scripts/Makefile.kcsan | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/scripts/Makefile.kcsan b/scripts/Makefile.kcsan
index cafa28ae..20337a7ecf54 100644
--- a/scripts/Makefile.kcsan
+++ b/scripts/Makefile.kcsan
@@ -1,6 +1,15 @@
 # SPDX-License-Identifier: GPL-2.0
 ifdef CONFIG_KCSAN
 
-CFLAGS_KCSAN := -fsanitize=thread
+# GCC and Clang accept backend options differently. Do not wrap in cc-option,
+# because Clang accepts "--param" even if it is unused.
+ifdef CONFIG_CC_IS_CLANG
+cc-param = -mllvm -$(1)
+else
+cc-param = --param -$(1)
+endif
+
+CFLAGS_KCSAN := -fsanitize=thread \
+   $(call cc-option,$(call cc-param,tsan-instrument-func-entry-exit=0) 
-fno-optimize-sibling-calls)
 
 endif # CONFIG_KCSAN
-- 
2.26.2.761.g0e0b3e54be-goog

[PATCH -tip 05/10] kcsan: Remove 'noinline' from __no_kcsan_or_inline

[Marco Elver]

Some compilers incorrectly inline small __no_kcsan functions, which then
results in instrumenting the accesses. For this reason, the 'noinline'
attribute was added to __no_kcsan_or_inline. All known versions of GCC
are affected by this. Supported version of Clang are unaffected, and
never inlines a no_sanitize function.

However, the attribute 'noinline' in __no_kcsan_or_inline causes
unexpected code generation in functions that are __no_kcsan and call a
__no_kcsan_or_inline function.

In certain situations it is expected that the __no_kcsan_or_inline
function is actually inlined by the __no_kcsan function, and *no* calls
are emitted. By removing the 'noinline' attribute we give the compiler
the ability to inline and generate the expected code in __no_kcsan
functions.

Link: 
https://lkml.kernel.org/r/canpmjnnopjk0tprxkb_deinav_ummorf1-2uajlhnlwqq1h...@mail.gmail.com
Signed-off-by: Marco Elver 
---
 include/linux/compiler.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index e24cc3a2bc3e..17c98b215572 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -276,11 +276,9 @@ do {   
\
 #ifdef __SANITIZE_THREAD__
 /*
  * Rely on __SANITIZE_THREAD__ instead of CONFIG_KCSAN, to avoid not inlining 
in
- * compilation units where instrumentation is disabled. The attribute 
'noinline'
- * is required for older compilers, where implicit inlining of very small
- * functions renders __no_sanitize_thread ineffective.
+ * compilation units where instrumentation is disabled.
  */
-# define __no_kcsan_or_inline __no_kcsan noinline notrace __maybe_unused
+# define __no_kcsan_or_inline __no_kcsan notrace __maybe_unused
 # define __no_sanitize_or_inline __no_kcsan_or_inline
 #else
 # define __no_kcsan_or_inline __always_inline
-- 
2.26.2.761.g0e0b3e54be-goog

[PATCH -tip 00/10] Fix KCSAN for new ONCE (require Clang 11)

[Marco Elver]

This patch series is the conclusion to [1], where we determined that due
to various interactions with no_sanitize attributes and the new
{READ,WRITE}_ONCE(), KCSAN will require Clang 11 or later. Other
sanitizers are largely untouched, and only KCSAN now has a hard
dependency on Clang 11. To test, a recent Clang development version will
suffice [2]. While a little inconvenient for now, it is hoped that in
future we may be able to fix GCC and re-enable GCC support.

The patch "kcsan: Restrict supported compilers" contains a detailed list
of requirements that led to this decision.

Most of the patches are related to KCSAN, however, the first patch also
includes an UBSAN related fix and is a dependency for the remaining
ones. The last 2 patches clean up the attributes by moving them to the
right place, and fix KASAN's way of defining __no_kasan_or_inline,
making it consistent with KCSAN.

The series has been tested by running kcsan-test several times and
completed successfully.

[1] 
https://lkml.kernel.org/r/canpmjnogfqhtda9wwpxs2kztqssozbwsumo5bqqw0c0g0zg...@mail.gmail.com
[2] https://github.com/llvm/llvm-project

Arnd Bergmann (1):
  ubsan, kcsan: don't combine sanitizer with kcov on clang

Marco Elver (9):
  kcsan: Avoid inserting __tsan_func_entry/exit if possible
  kcsan: Support distinguishing volatile accesses
  kcsan: Pass option tsan-instrument-read-before-write to Clang
  kcsan: Remove 'noinline' from __no_kcsan_or_inline
  kcsan: Restrict supported compilers
  kcsan: Update Documentation to change supported compilers
  READ_ONCE, WRITE_ONCE: Remove data_race() wrapping
  compiler.h: Move function attributes to compiler_types.h
  compiler_types.h, kasan: Use __SANITIZE_ADDRESS__ instead of
CONFIG_KASAN to decide inlining

 Documentation/dev-tools/kcsan.rst |  9 +--
 include/linux/compiler.h  | 35 ++---
 include/linux/compiler_types.h| 32 +++
 kernel/kcsan/core.c   | 43 +++
 lib/Kconfig.kcsan | 20 +-
 lib/Kconfig.ubsan | 11 
 scripts/Makefile.kcsan| 15 ++-
 7 files changed, 122 insertions(+), 43 deletions(-)

-- 
2.26.2.761.g0e0b3e54be-goog

[PATCH -tip 04/10] kcsan: Pass option tsan-instrument-read-before-write to Clang

[Marco Elver]

Clang (unlike GCC) removes reads before writes with matching addresses
in the same basic block. This is an optimization for TSAN, since writes
will always cause conflict if the preceding read would have.

However, for KCSAN we cannot rely on this option, because we apply
several special rules to writes, in particular when the
KCSAN_ASSUME_PLAIN_WRITES_ATOMIC option is selected. To avoid missing
potential data races, pass the -tsan-instrument-read-before-write option
to Clang if it is available [1].

[1] 
https://github.com/llvm/llvm-project/commit/151ed6aa38a3ec6c01973b35f684586b6e1c0f7e

Signed-off-by: Marco Elver 
---
 scripts/Makefile.kcsan | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/Makefile.kcsan b/scripts/Makefile.kcsan
index c02662b30a7c..ea4a6301633e 100644
--- a/scripts/Makefile.kcsan
+++ b/scripts/Makefile.kcsan
@@ -13,6 +13,7 @@ endif
 # if the absence of some options still allows us to use KCSAN in most cases.
 CFLAGS_KCSAN := -fsanitize=thread \
$(call cc-option,$(call cc-param,tsan-instrument-func-entry-exit=0) 
-fno-optimize-sibling-calls) \
+   $(call cc-option,$(call cc-param,tsan-instrument-read-before-write=1)) \
$(call cc-param,tsan-distinguish-volatile=1)
 
 endif # CONFIG_KCSAN
-- 
2.26.2.761.g0e0b3e54be-goog

[PATCH -tip 08/10] READ_ONCE, WRITE_ONCE: Remove data_race() wrapping

[Marco Elver]

The volatile access no longer needs to be wrapped in data_race(),
because we require compilers that emit instrumentation distinguishing
volatile accesses.

Signed-off-by: Marco Elver 
---
 include/linux/compiler.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 17c98b215572..fce56402c082 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -229,7 +229,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int 
val,
 #define __READ_ONCE_SCALAR(x)  \
 ({ \
typeof(x) *__xp = &(x); \
-   __unqual_scalar_typeof(x) __x = data_race(__READ_ONCE(*__xp));  \
+   __unqual_scalar_typeof(x) __x = __READ_ONCE(*__xp); \
kcsan_check_atomic_read(__xp, sizeof(*__xp));   \
smp_read_barrier_depends(); \
(typeof(x))__x; \
@@ -250,7 +250,7 @@ do {
\
 do {   \
typeof(x) *__xp = &(x); \
kcsan_check_atomic_write(__xp, sizeof(*__xp));  \
-   data_race(({ __WRITE_ONCE(*__xp, val); 0; }));  \
+   __WRITE_ONCE(*__xp, val);   \
 } while (0)
 
 #define WRITE_ONCE(x, val) \
-- 
2.26.2.761.g0e0b3e54be-goog

[PATCH -tip 01/10] ubsan, kcsan: don't combine sanitizer with kcov on clang

[Marco Elver]

From: Arnd Bergmann 

Clang does not allow -fsanitize-coverage=trace-{pc,cmp} together
with -fsanitize=bounds or with ubsan:

clang: error: argument unused during compilation: 
'-fsanitize-coverage=trace-pc' [-Werror,-Wunused-command-line-argument]
clang: error: argument unused during compilation: 
'-fsanitize-coverage=trace-cmp' [-Werror,-Wunused-command-line-argument]

To avoid the warning, check whether clang can handle this correctly
or disallow ubsan and kcsan when kcov is enabled.

Link: https://bugs.llvm.org/show_bug.cgi?id=45831
Link: https://lore.kernel.org/lkml/20200505142341.1096942-1-a...@arndb.de
Acked-by: Marco Elver 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Marco Elver 
---
This patch is already in -rcu tree, but since since the series is based
on -tip, to avoid conflict it is required for the subsequent patches.
---
 lib/Kconfig.kcsan | 11 +++
 lib/Kconfig.ubsan | 11 +++
 2 files changed, 22 insertions(+)

diff --git a/lib/Kconfig.kcsan b/lib/Kconfig.kcsan
index ea28245c6c1d..a7276035ca0d 100644
--- a/lib/Kconfig.kcsan
+++ b/lib/Kconfig.kcsan
@@ -3,9 +3,20 @@
 config HAVE_ARCH_KCSAN
bool
 
+config KCSAN_KCOV_BROKEN
+   def_bool KCOV && CC_HAS_SANCOV_TRACE_PC
+   depends on CC_IS_CLANG
+   depends on !$(cc-option,-Werror=unused-command-line-argument 
-fsanitize=thread -fsanitize-coverage=trace-pc)
+   help
+ Some versions of clang support either KCSAN and KCOV but not the
+ combination of the two.
+ See https://bugs.llvm.org/show_bug.cgi?id=45831 for the status
+ in newer releases.
+
 menuconfig KCSAN
bool "KCSAN: dynamic data race detector"
depends on HAVE_ARCH_KCSAN && DEBUG_KERNEL && !KASAN
+   depends on !KCSAN_KCOV_BROKEN
select STACKTRACE
help
  The Kernel Concurrency Sanitizer (KCSAN) is a dynamic
diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
index 48469c95d78e..3baea77bf37f 100644
--- a/lib/Kconfig.ubsan
+++ b/lib/Kconfig.ubsan
@@ -26,9 +26,20 @@ config UBSAN_TRAP
  the system. For some system builders this is an acceptable
  trade-off.
 
+config UBSAN_KCOV_BROKEN
+   def_bool KCOV && CC_HAS_SANCOV_TRACE_PC
+   depends on CC_IS_CLANG
+   depends on !$(cc-option,-Werror=unused-command-line-argument 
-fsanitize=bounds -fsanitize-coverage=trace-pc)
+   help
+ Some versions of clang support either UBSAN or KCOV but not the
+ combination of the two.
+ See https://bugs.llvm.org/show_bug.cgi?id=45831 for the status
+ in newer releases.
+
 config UBSAN_BOUNDS
bool "Perform array index bounds checking"
default UBSAN
+   depends on !UBSAN_KCOV_BROKEN
help
  This option enables detection of directly indexed out of bounds
  array accesses, where the array size is known at compile time.
-- 
2.26.2.761.g0e0b3e54be-goog

[PATCH -tip 09/10] compiler.h: Move function attributes to compiler_types.h

[Marco Elver]

Cleanup and move the KASAN and KCSAN related function attributes to
compiler_types.h, where the rest of the same kind live.

No functional change intended.

Signed-off-by: Marco Elver 
---
 include/linux/compiler.h   | 29 -
 include/linux/compiler_types.h | 29 +
 2 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index fce56402c082..a7b01e750dd3 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -259,35 +259,6 @@ do {   
\
__WRITE_ONCE_SCALAR(x, val);\
 } while (0)
 
-#ifdef CONFIG_KASAN
-/*
- * We can't declare function 'inline' because __no_sanitize_address conflicts
- * with inlining. Attempt to inline it may cause a build failure.
- * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
- * '__maybe_unused' allows us to avoid defined-but-not-used warnings.
- */
-# define __no_kasan_or_inline __no_sanitize_address notrace __maybe_unused
-# define __no_sanitize_or_inline __no_kasan_or_inline
-#else
-# define __no_kasan_or_inline __always_inline
-#endif
-
-#define __no_kcsan __no_sanitize_thread
-#ifdef __SANITIZE_THREAD__
-/*
- * Rely on __SANITIZE_THREAD__ instead of CONFIG_KCSAN, to avoid not inlining 
in
- * compilation units where instrumentation is disabled.
- */
-# define __no_kcsan_or_inline __no_kcsan notrace __maybe_unused
-# define __no_sanitize_or_inline __no_kcsan_or_inline
-#else
-# define __no_kcsan_or_inline __always_inline
-#endif
-
-#ifndef __no_sanitize_or_inline
-#define __no_sanitize_or_inline __always_inline
-#endif
-
 static __no_sanitize_or_inline
 unsigned long __read_once_word_nocheck(const void *addr)
 {
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 6ed0612bc143..b190a12e7089 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -167,6 +167,35 @@ struct ftrace_likely_data {
  */
 #define noinline_for_stack noinline
 
+#ifdef CONFIG_KASAN
+/*
+ * We can't declare function 'inline' because __no_sanitize_address conflicts
+ * with inlining. Attempt to inline it may cause a build failure.
+ * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
+ * '__maybe_unused' allows us to avoid defined-but-not-used warnings.
+ */
+# define __no_kasan_or_inline __no_sanitize_address notrace __maybe_unused
+# define __no_sanitize_or_inline __no_kasan_or_inline
+#else
+# define __no_kasan_or_inline __always_inline
+#endif
+
+#define __no_kcsan __no_sanitize_thread
+#ifdef __SANITIZE_THREAD__
+/*
+ * Rely on __SANITIZE_THREAD__ instead of CONFIG_KCSAN, to avoid not inlining 
in
+ * compilation units where instrumentation is disabled.
+ */
+# define __no_kcsan_or_inline __no_kcsan notrace __maybe_unused
+# define __no_sanitize_or_inline __no_kcsan_or_inline
+#else
+# define __no_kcsan_or_inline __always_inline
+#endif
+
+#ifndef __no_sanitize_or_inline
+#define __no_sanitize_or_inline __always_inline
+#endif
+
 #endif /* __KERNEL__ */
 
 #endif /* __ASSEMBLY__ */
-- 
2.26.2.761.g0e0b3e54be-goog

[PATCH -tip 07/10] kcsan: Update Documentation to change supported compilers

[Marco Elver]

Signed-off-by: Marco Elver 
---
 Documentation/dev-tools/kcsan.rst | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/Documentation/dev-tools/kcsan.rst 
b/Documentation/dev-tools/kcsan.rst
index f4b5766f12cc..ce4bbd918648 100644
--- a/Documentation/dev-tools/kcsan.rst
+++ b/Documentation/dev-tools/kcsan.rst
@@ -8,8 +8,7 @@ approach to detect races. KCSAN's primary purpose is to detect 
`data races`_.
 Usage
 -
 
-KCSAN is supported in both GCC and Clang. With GCC it requires version 7.3.0 or
-later. With Clang it requires version 7.0.0 or later.
+KCSAN requires Clang version 11 or later.
 
 To enable KCSAN configure the kernel with::
 
@@ -121,12 +120,6 @@ the below options are available:
 static __no_kcsan_or_inline void foo(void) {
 ...
 
-  Note: Older compiler versions (GCC < 9) also do not always honor the
-  ``__no_kcsan`` attribute on regular ``inline`` functions. If false positives
-  with these compilers cannot be tolerated, for small functions where
-  ``__always_inline`` would be appropriate, ``__no_kcsan_or_inline`` should be
-  preferred instead.
-
 * To disable data race detection for a particular compilation unit, add to the
   ``Makefile``::
 
-- 
2.26.2.761.g0e0b3e54be-goog

[PATCH -tip 10/10] compiler_types.h, kasan: Use __SANITIZE_ADDRESS__ instead of CONFIG_KASAN to decide inlining

[Marco Elver]

Like is done for KCSAN, for KASAN we should also use __always_inline in
compilation units that have instrumentation disabled
(KASAN_SANITIZE_foo.o := n). Adds common documentation for KASAN and
KCSAN explaining the attribute.

Signed-off-by: Marco Elver 
---
 include/linux/compiler_types.h | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index b190a12e7089..5faf68eae204 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -167,7 +167,14 @@ struct ftrace_likely_data {
  */
 #define noinline_for_stack noinline
 
-#ifdef CONFIG_KASAN
+/*
+ * Sanitizer helper attributes: Because using __always_inline and
+ * __no_sanitize_* conflict, provide helper attributes that will either expand
+ * to __no_sanitize_* in compilation units where instrumentation is enabled
+ * (__SANITIZE_*__), or __always_inline in compilation units without
+ * instrumentation (__SANITIZE_*__ undefined).
+ */
+#ifdef __SANITIZE_ADDRESS__
 /*
  * We can't declare function 'inline' because __no_sanitize_address conflicts
  * with inlining. Attempt to inline it may cause a build failure.
@@ -182,10 +189,6 @@ struct ftrace_likely_data {
 
 #define __no_kcsan __no_sanitize_thread
 #ifdef __SANITIZE_THREAD__
-/*
- * Rely on __SANITIZE_THREAD__ instead of CONFIG_KCSAN, to avoid not inlining 
in
- * compilation units where instrumentation is disabled.
- */
 # define __no_kcsan_or_inline __no_kcsan notrace __maybe_unused
 # define __no_sanitize_or_inline __no_kcsan_or_inline
 #else
-- 
2.26.2.761.g0e0b3e54be-goog

Re: [PATCH v2 14/19] spi: dw: Remove DW DMA code dependency from DW_DMAC_PCI

[Andy Shevchenko]

On Fri, May 15, 2020 at 01:47:53PM +0300, Serge Semin wrote:
> Since there is a generic method available to initialize the DW SPI DMA
> interface on any DT and ACPI-based platforms, which in general can be
> designed with not only DW DMAC but with any DMA engine on board, we can
> freely remove the CONFIG_DW_DMAC_PCI config from dependency list of
> CONFIG_SPI_DW_DMA. Especially seeing that we don't use anything DW DMAC
> specific in the new driver.

Right, and used data structures are always available at compile time.
Reviewed-by: Andy Shevchenko 

> Co-developed-by: Georgy Vlasov 
> Signed-off-by: Georgy Vlasov 
> Co-developed-by: Ramil Zaripov 
> Signed-off-by: Ramil Zaripov 
> Signed-off-by: Serge Semin 
> Cc: Alexey Malahov 
> Cc: Thomas Bogendoerfer 
> Cc: Paul Burton 
> Cc: Ralf Baechle 
> Cc: Rob Herring 
> Cc: Arnd Bergmann 
> Cc: Allison Randal 
> Cc: Andy Shevchenko 
> Cc: Gareth Williams 
> Cc: linux-m...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> ---
>  drivers/spi/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 03b061975f70..6a84f3dad35c 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -228,7 +228,7 @@ config SPI_DESIGNWARE
>  
>  config SPI_DW_DMA
>   bool "DMA support for DW SPI controller"
> - depends on SPI_DESIGNWARE && DW_DMAC_PCI
> + depends on SPI_DESIGNWARE
>  
>  config SPI_DW_PCI
>   tristate "PCI interface driver for DW SPI core"
> -- 
> 2.25.1
> 

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 0/7] usb: gadget: udc: atmel: add usb device support for SAM9x60 SoC

[Alexandre Belloni]

Hi,

On 15/05/2020 14:16:24+0300, cristian.bir...@microchip.com wrote:
> From: Cristian Birsan 
> 
> This patch set adds usb device support for SAM9x60 SoC.
> The DPRAM memory for the USB High Speed Device Port (UDPHS) hardware
> block was increased and the allocation method is changed. This patch
> series simplifies the endpoint allocation scheme to acomodate this SoC
> and the old ones.
> 
> Changes in v2:
> - drop the patch that adds reference to pmc for sam9x60
> - use dt-bindings: usb prefix
> - enable usb device in device tree
> 
> Claudiu Beznea (1):
>   usb: gadget: udc: atmel: use of_find_matching_node_and_match
> 
> Cristian Birsan (6):
>   dt-bindings: usb: atmel: Update DT bindings documentation for sam9x60
>   usb: gadget: udc: atmel: simplify endpoint allocation
>   usb: gadget: udc: atmel: use 1 bank endpoints for control transfers
>   usb: gadget: udc: atmel: rename errata into caps
>   usb: gadget: udc: atmel: update endpoint allocation for sam9x60
>   ARM: dts: at91: sam9x60ek: enable usb device

This should probably be rebased on top of
https://lore.kernel.org/linux-arm-kernel/20200507155651.1094142-1-gregory.clem...@bootlin.com/
so we avoid having to define the endpoints in the device tree in the
first place.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH RESEND 3/4] Documentation/litmus-tests: Merge atomic's README into top-level one

[Akira Yokosawa]

On Thu, 14 May 2020 15:45:58 -0700, Paul E. McKenney wrote:
> On Fri, May 15, 2020 at 07:03:33AM +0900, Akira Yokosawa wrote:
>> On Thu, 14 May 2020 10:16:56 -0700, Paul E. McKenney wrote:
>>> On Thu, May 14, 2020 at 08:46:18AM +0800, Boqun Feng wrote:
 On Wed, May 13, 2020 at 06:39:03AM +0900, Akira Yokosawa wrote:
> From 96fa6680e3b990633ecbb6d11acf03a161b790bd Mon Sep 17 00:00:00 2001
> From: Akira Yokosawa 
> Date: Sun, 10 May 2020 15:12:57 +0900
> Subject: [PATCH RESEND 3/4] Documentation/litmus-tests: Merge atomic's 
> README into top-level one
>
> Where Documentation/litmus-tests/README lists RCU litmus tests,
> Documentation/litmus-tests/atomic/README lists atomic litmus tests.
> For symmetry, merge the latter into former, with some context
> adjustment in the introduction.
>
> Signed-off-by: Akira Yokosawa 
> Acked-by: Andrea Parri 
> Acked-by: Joel Fernandes (Google) 

 Acked-by: Boqun Feng 

 Thanks!
>>>
>>> Applied, and thank you all!
>>>
>>> I rebased, cancelling the revert with the original, resulting in an
>>> updated lkmm branch on -rcu.  There was one minor conflict, so could
>>> one of you please check to make sure that I resolved things appropriately?
>>
>> One thing I noticed.
>>
>> Commit b2998782ded4 ("Documentation/litmus-tests: Clarify about the RCU
>> pre-initialization test")'s change log says:
>>
>> Since this test returned to tools/memory-model/, make sure that it is
>> ~~~
>> at least referenced from Documentation/litmus-tests/'s README.
>>
>> Because of the rebase, this needs amendment as well as the title.
>>
>> Something like
>>
>> Documentation/litumus-tests: Cite a relevant litmus test in 
>> tools/memory-model
>>
>> For ease of finding the RCU related litmus test under
>> tools/memory-model/, add an entry in README.
>>
>> ?
> 
> Good catch, and yes, I will update that on the next rebase.
> 
> Any other things in need of adjustment?

Aside from the missing Signed-off-by tags Stephen pointed out, I don't
see anything.

Thanks, Akira

> 
>   Thanx, Paul

Re: [PATCH 1/2] rbtree_latch: quit searching when reaching to maximum depth

[Peter Zijlstra]

On Fri, May 15, 2020 at 10:39:25PM +0800, Lai Jiangshan wrote:
> On Fri, May 15, 2020 at 9:04 PM Peter Zijlstra  wrote:
> > On Fri, May 15, 2020 at 12:47:06PM +, Lai Jiangshan wrote:
> > > lib/rbtree.c has ensured that there is not possible to
> > > inadvertently cause (temporary) loops in the tree structure
> > > as seen in program order of the modifier. But loop is still
> > > possible to be seen in searcher due to CPU's reordering.
> > >
> > > for example:
> > > modifier  searcher
> > >
> > > left rotate at parent
> > > parent->rb_right is node
> > >   search to parent
> > >   parent->rb_right is node
> > >+->see node->rb_left changed
> > > WRITE_ONCE(parent->rb_right, tmp);-+ |  node->rb_left is parennt
> > > no smp_wmb(), some arch can| |
> > > reorder these two writes   | |  loop long between
> > > WRITE_ONCE(node->rb_left, parent);-+-+  parent and node
> > >  |
> > >  +--->finally see
> > >   parent->rb_right
> > >
> > > The long loop won't stop until the modifer's CPU flushes
> > > its writes. Too avoid it, we should limit the searching depth.
> >
> > Cute, have you actually observed this? Did you have performance issues?
> 
> I can only test it on x86 by now, which implies smp_wmb() between
> writes. I haven't observed any thing wrong. I'm just imaging
> it on some other ARCHs.

Note that smp_wmb() doesn't imply flushing the store-buffers. Nor does
the TSO memory model of x86 (it's the main feature that distinguishes
TSO from SC).

x86's MFENCE is a completion barrier and does imply so though.

> I accidentally found this part of code when I searched for
> whether there is any attempt again to use rbtree with RCU, and
> whether there are the cases besides speculative page fault.

It got mentioned earlier in the contect of a stream of changes, an
uninterrupted modifier can basically starve a search.

But I don't think that's a problem with the current users.

> > > There are no more than (1< > > And the max_depth of a tree is no more than 2*lg(node_count+1),
> > > which is no mare than 2*BITS_PER_LONG.
> > >
> > > So the serarch should stop when diving down up to
> > > 2*BITS_PER_LONG depth.
> >
> > Arguably you can have a larger key space, but I think due to memory
> > constraints this limit still isn't wrong. But I do feel you need a
> > comment with that.
> 
> Sure, I will add some comments about why "2*BITS_PER_LONG" in code.
> 
> But how it could be larger key space? there are not more than
> (1< space, and (1< (1<

Re: [patch V4 part 4 23/24] x86/entry: Provide IDTENTRY_DF

[Thomas Gleixner]

Andy Lutomirski  writes:
> On Tue, May 5, 2020 at 7:16 AM Thomas Gleixner  wrote:
>>
>> Provide a separate macro for #DF as this needs to emit paranoid only code
>> and has also a special ASM stub in 32bit.
>
> Acked-by: Andy Lutomirski 
>
> but... maybe it would be cleaner just to open-code all of this in the
> next patch?  This is a lot of macro to do nothing at all.

Well, yes and no. The point is that we really want to have all idt
entries marked IDENTRY_ and have the prototypes including the XEN
variants generated.

Thanks,

tglx

Re: [PATCH] memcg: expose root cgroup's memory.stat

[Roman Gushchin]

On Fri, May 15, 2020 at 06:44:44AM -0700, Shakeel Butt wrote:
> On Fri, May 15, 2020 at 6:24 AM Johannes Weiner  wrote:
> >
> > On Fri, May 15, 2020 at 10:29:55AM +0200, Michal Hocko wrote:
> > > On Sat 09-05-20 07:06:38, Shakeel Butt wrote:
> > > > On Fri, May 8, 2020 at 2:44 PM Johannes Weiner  
> > > > wrote:
> > > > >
> > > > > On Fri, May 08, 2020 at 10:06:30AM -0700, Shakeel Butt wrote:
> > > > > > One way to measure the efficiency of memory reclaim is to look at 
> > > > > > the
> > > > > > ratio (pgscan+pfrefill)/pgsteal. However at the moment these stats 
> > > > > > are
> > > > > > not updated consistently at the system level and the ratio of these 
> > > > > > are
> > > > > > not very meaningful. The pgsteal and pgscan are updated for only 
> > > > > > global
> > > > > > reclaim while pgrefill gets updated for global as well as cgroup
> > > > > > reclaim.
> > > > > >
> > > > > > Please note that this difference is only for system level vmstats. 
> > > > > > The
> > > > > > cgroup stats returned by memory.stat are actually consistent. The
> > > > > > cgroup's pgsteal contains number of reclaimed pages for global as 
> > > > > > well
> > > > > > as cgroup reclaim. So, one way to get the system level stats is to 
> > > > > > get
> > > > > > these stats from root's memory.stat, so, expose memory.stat for the 
> > > > > > root
> > > > > > cgroup.
> > > > > >
> > > > > >   from Johannes Weiner:
> > > > > >   There are subtle differences between /proc/vmstat and
> > > > > >   memory.stat, and cgroup-aware code that wants to watch the 
> > > > > > full
> > > > > >   hierarchy currently has to know about these intricacies and
> > > > > >   translate semantics back and forth.
> > >
> > > Can we have those subtle differences documented please?
> > >
> > > > > >
> > > > > >   Generally having the fully recursive memory.stat at the root
> > > > > >   level could help a broader range of usecases.
> > > > >
> > > > > The changelog begs the question why we don't just "fix" the
> > > > > system-level stats. It may be useful to include the conclusions from
> > > > > that discussion, and why there is value in keeping the stats this way.
> > > > >
> > > >
> > > > Right. Andrew, can you please add the following para to the changelog?
> > > >
> > > > Why not fix the stats by including both the global and cgroup reclaim
> > > > activity instead of exposing root cgroup's memory.stat? The reason is
> > > > the benefit of having metrics exposing the activity that happens
> > > > purely due to machine capacity rather than localized activity that
> > > > happens due to the limits throughout the cgroup tree. Additionally
> > > > there are userspace tools like sysstat(sar) which reads these stats to
> > > > inform about the system level reclaim activity. So, we should not
> > > > break such use-cases.
> > > >
> > > > > > Signed-off-by: Shakeel Butt 
> > > > > > Suggested-by: Johannes Weiner 
> > > > >
> > > > > Acked-by: Johannes Weiner 
> > > >
> > > > Thanks a lot.
> > >
> > > I was quite surprised that the patch is so simple TBH. For some reason
> > > I've still had memories that we do not account for root memcg (likely
> > > because mem_cgroup_is_root(memcg) bail out in the try_charge. But stats
> > > are slightly different here.
> >
> > Yep, we skip the page_counter for root, but keep in mind that cgroup1
> > *does* have a root-level memory.stat, so (for the most part) we've
> > been keeping consumer stats for the root level the whole time.
> >
> > > counters because they are not really all the same. E.g.
> > > - mem_cgroup_charge_statistics accounts for each memcg
> >
> > Yep, that's heritage from cgroup1.
> >
> > > - memcg_charge_kernel_stack relies on pages being associated with a
> > >   memcg and that in turn relies on __memcg_kmem_charge_page which bails
> > >   out on root memcg
> >
> > You're right. It should only bypass the page_counter, but still set
> > page->mem_cgroup = root_mem_cgroup, just like user pages.

What about kernel threads? We consider them belonging to the root memory
cgroup. Should their memory consumption being considered in root-level stats?

I'm not sure we really want it, but I guess we need to document how
kernel threads are handled.

> >
> > This counter also doesn't get exported on cgroup1, so it would indeed
> > be a new bug. It needs to be fixed before this patch here.
> >
> > > - memcg_charge_slab (NR_SLAB*) skips over root memcg as well
> >
> > Same thing with these two.
> 
> Yes, we skip page_counter for root but not the stats. I will go over
> all the stats and make sure we are not skipping the stats for root.

Re: [PATCH v2 08/19] spi: dw: Discard dma_width member of the dw_spi structure

[Andy Shevchenko]

On Fri, May 15, 2020 at 05:16:27PM +0300, Serge Semin wrote:
> On Fri, May 15, 2020 at 04:49:56PM +0300, Andy Shevchenko wrote:
> > On Fri, May 15, 2020 at 04:05:59PM +0300, Serge Semin wrote:
> > > On Fri, May 15, 2020 at 04:03:05PM +0300, Andy Shevchenko wrote:
> > > > On Fri, May 15, 2020 at 01:47:47PM +0300, Serge Semin wrote:
> > > > > This member has exactly the same value as n_bytes of the DW SPI 
> > > > > private
> > > > > data object, it's calculated at the same point of the transfer method,
> > > > > n_bytes isn't changed during the whole transfer, and they even serve 
> > > > > for
> > > > > the same purpose - keep number of bytes per transfer word, though the
> > > > > dma_width is used only to calculate the DMA source/destination 
> > > > > addresses
> > > > > width, which n_bytes could be also utilized for. Taking all of these
> > > > > into account let's replace the dma_width member usage with n_bytes one
> > > > > and remove the former.
> > > > 
> > > > I've no strong opinion about this.
> > > > So, after addressing one issue below,
> > > > Reviewed-by: Andy Shevchenko 
> > 
> > ...
> > 
> > > > > -static enum dma_slave_buswidth convert_dma_width(u32 dma_width) {
> > > > > - if (dma_width == 1)
> > > > 
> > > > > +static enum dma_slave_buswidth convert_dma_width(u8 n_bytes) {
> > > > 
> > > > It seems somebody (maybe even me) at some point messed up between enum
> > > > definition and function that returns an enum.
> > > > 
> > > > For what said, { should be on the separate line.
> > > 
> > > See the patch 16/19: "spi: dw: Cleanup generic DW DMA code namings"
> > > in this series.
> > 
> > Since you are touching that line here, it makes sense to do it here rather 
> > than
> > ping-pong to other patch in very same series.
> 
> You didn't open the patch I referred to, did you?

Patches in the series are going on purpose. I look at them in the sequence of
the appearance. But okay, I looked at it and I found what I expected. I think
that you may reorder patch 16 to be one right after renaming module.

> If you did, you would have
> seen that I touched that line there too in the framework of the naming cleanup
> procedure. So please, stop wasting my time with trivial stuff.

Haven't you missed my tag? It means I spent *my* time on *your* stuff. Please,
be respectful to reviewers.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCHv1 15/19] power: supply: sbs-battery: add ability to disable charger broadcasts

[Emil Velikov]

On 2020/05/13, Sebastian Reichel wrote:
> From: Jean-Francois Dagenais 
> 
> In certain designs, it is possible to add a battery on a populated i2c
> bus without an sbs compliant charger. In that case, the battery will
> un-necessarily and sometimes un-desirably master the bus trying to write
> info in the charger.

Nit: s/un-/un/

> 
> It is observed in many occasion that these battery "broadcasts" are even
> corrupting other ongoing master to slave communication. I.e. the
> multi-master support in the battery is inadequate.
> 
> Thankfully, the CHARGER_MODE bit allows designers to disable that SBS
> battery behaviour.
> 
> This needs to be done once when the battery is first seen on the bus.
> 
> Signed-off-by: Jean-Francois Dagenais 
> [rebased code]
> Signed-off-by: Sebastian Reichel 
> ---

> @@ -1017,6 +1043,9 @@ static int sbs_probe(struct i2c_client *client,
>   }
>   chip->i2c_retry_count = chip->i2c_retry_count + 1;
>  
> + chip->charger_broadcasts = !of_property_read_bool(client->dev.of_node,
> + "sbs,disable-charger-broadcasts");
> +
This patch adds the of_property_read, only for it to be replaced in the next
patch. Consider flipping the patch order?

-Emil

Re: [PATCH] ARM: dts: at91: Configure I2C SCL gpio as open drain

[Alexandre Belloni]

On 15/05/2020 17:00:01+0300, Codrin Ciubotariu wrote:
> The SCL gpio pin used by I2C bus for recovery needs to be configured as
> open drain.
> 
> Fixes: 455fec938bbb ("ARM: dts: at91: sama5d2: add i2c gpio pinctrl")
> Fixes: a4bd8da893a3 ("ARM: dts: at91: sama5d3: add i2c gpio pinctrl")
> Fixes: 8fb82f050cf6 ("ARM: dts: at91: sama5d4: add i2c gpio pinctrl")
> Signed-off-by: Codrin Ciubotariu 
> ---
>  arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts   | 6 +++---
>  arch/arm/boot/dts/at91-sama5d2_xplained.dts | 6 +++---
>  arch/arm/boot/dts/sama5d3.dtsi  | 6 +++---
>  arch/arm/boot/dts/sama5d4.dtsi  | 6 +++---
>  4 files changed, 12 insertions(+), 12 deletions(-)
> 

Applied, thanks. There was a small conflict in the sama5d2 board dts,
please check.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v3 2/2] staging: vt6655: vt6656: change order of makefile variable definitions

[Matej Dujava]

On Fri, May 15, 2020 at 03:48:59PM +0200, Greg Kroah-Hartman wrote:

I still fail to understand the need for this patch at all.  It doesn't
clean anything up, nor change anything.  There is no rule that this has
to be in one order or the other, and in fact, I like the order that the
files currently have :)

thanks,

greg k-h


Most of makefiles has pattern that `obj-${}` is before `driver-y` lines.
If this is not something that was intentional, then this patch is not
adding any value indeed.

Few examples that give me that impression:

./gnss/Makefile-# SPDX-License-Identifier: GPL-2.0
./gnss/Makefile-#
./gnss/Makefile-# Makefile for the GNSS subsystem.
./gnss/Makefile-#
./gnss/Makefile-
./gnss/Makefile:obj-$(CONFIG_GNSS)  += gnss.o
./gnss/Makefile-gnss-y := core.o
./gnss/Makefile-
./gnss/Makefile:obj-$(CONFIG_GNSS_SERIAL)   += gnss-serial.o
./gnss/Makefile-gnss-serial-y := serial.o
--snip end--

./.../go7007/Makefile-# SPDX-License-Identifier: GPL-2.0
./.../go7007/Makefile:obj-$(CONFIG_VIDEO_GO7007) += go7007.o
./.../go7007/Makefile:obj-$(CONFIG_VIDEO_GO7007_USB) += go7007-usb.o
./.../go7007/Makefile:obj-$(CONFIG_VIDEO_GO7007_LOADER) += go7007-loader.o
./.../go7007/Makefile:obj-$(CONFIG_VIDEO_GO7007_USB_S2250_BOARD) += s2250.o
./.../go7007/Makefile-
./.../go7007/Makefile-go7007-y := go7007-v4l2.o go7007-driver.o go7007-i2c.
./.../go7007/Makefile-snd-go7007.o
./.../go7007/Makefile-
./.../go7007/Makefile-s2250-y := s2250-board.o
--snip end--

Thanks,
Matej

Re: [PATCH 4/8] libbpf hashmap: Localize static hashmap__* symbols

[Ian Rogers]

On Fri, May 15, 2020 at 7:29 AM Arnaldo Carvalho de Melo
 wrote:
>
> Em Fri, May 15, 2020 at 11:17:07AM +0200, Jiri Olsa escreveu:
> > On Thu, May 14, 2020 at 11:56:20PM -0700, Ian Rogers wrote:
> > > Localize the hashmap__* symbols in libbpf.a. To allow for a version in
> > > libapi.
> > >
> > > Before:
> > > $ nm libbpf.a
> > > ...
> > > 0002088a t hashmap_add_entry
> > > 0001712a t hashmap__append
> > > 00020aa3 T hashmap__capacity
> > > 0002099c T hashmap__clear
> > > 000208b3 t hashmap_del_entry
> > > 00020fc1 T hashmap__delete
> > > 00020f29 T hashmap__find
> > > 00020c6c t hashmap_find_entry
> > > 00020a61 T hashmap__free
> > > 00020b08 t hashmap_grow
> > > 000208dd T hashmap__init
> > > 00020d35 T hashmap__insert
> > > 00020ab5 t hashmap_needs_to_grow
> > > 00020947 T hashmap__new
> > > 0775 t hashmap__set
> > > 000212f8 t hashmap__set
> > > 00020a91 T hashmap__size
> > > ...
> > >
> > > After:
> > > $ nm libbpf.a
> > > ...
> > > 0002088a t hashmap_add_entry
> > > 0001712a t hashmap__append
> > > 00020aa3 t hashmap__capacity
> > > 0002099c t hashmap__clear
> > > 000208b3 t hashmap_del_entry
> > > 00020fc1 t hashmap__delete
> > > 00020f29 t hashmap__find
> > > 00020c6c t hashmap_find_entry
> > > 00020a61 t hashmap__free
> > > 00020b08 t hashmap_grow
> > > 000208dd t hashmap__init
> > > 00020d35 t hashmap__insert
> > > 00020ab5 t hashmap_needs_to_grow
> > > 00020947 t hashmap__new
> > > 0775 t hashmap__set
> > > 000212f8 t hashmap__set
> > > 00020a91 t hashmap__size
> > > ...
> >
> > I think this will break bpf selftests which use hashmap,
> > we need to find some other way to include this
> >
> > either to use it from libbpf directly, or use the api version
> > only if the libbpf is not compiled in perf, we could use
> > following to detect that:
> >
> >   CFLAGS += -DHAVE_LIBBPF_SUPPORT
> >   $(call detected,CONFIG_LIBBPF)
>
> And have it in tools/perf/util/ instead?
>
>
> - Arnaldo

*sigh*

$ make -C tools/testing/selftests/bpf test_hashmap
make: Entering directory
'/usr/local/google/home/irogers/kernel-trees/kernel.org/tip/tools/testing/s
elftests/bpf'
 BINARY   test_hashmap
/usr/bin/ld: /tmp/ccEGGNw5.o: in function `test_hashmap_generic':
/usr/local/google/home/irogers/kernel-trees/kernel.org/tip/tools/testing/selftests/bpf/test_hashmap.
c:61: undefined reference to `hashmap__new'
...

My preference was to make hashmap a sharable API in tools, to benefit
not just perf but say things like libsymbol, libperf, etc. Moving it
into perf and using conditional compilation is kinda gross but having
libbpf tests depend on libapi also isn't ideal I guess. It is tempting
to just cut a hashmap from fresh cloth to avoid this and to share
among tools/. I don't know if the bpf folks have opinions?

I'll do a v2 using conditional compilation to see how bad it looks.

Thanks,
Ian

Re: [PATCH -next] soc: mediatek: Missing platform_device_unregister() on error in mtk_mmsys_probe()

[Matthias Brugger]

On 06/05/2020 19:24, Enric Balletbo i Serra wrote:
> Hi Wei,
> 
> Thank you for your patch.
> 
> On 6/5/20 16:13, Wei Yongjun wrote:
>> Add the missing platform_device_unregister() before return
>> from mtk_mmsys_probe() in the error handling case.
>>
>> Fixes: 667c769246b0 ("soc / drm: mediatek: Fix mediatek-drm device probing")
>> Signed-off-by: Wei Yongjun 
> 
> Reviewed-by: Enric Balletbo i Serra 
> 

applied to v5.7-next/soc

Thanks!

>> ---
>>  drivers/soc/mediatek/mtk-mmsys.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/soc/mediatek/mtk-mmsys.c 
>> b/drivers/soc/mediatek/mtk-mmsys.c
>> index 05e322c9c301..05ce4cb464b0 100644
>> --- a/drivers/soc/mediatek/mtk-mmsys.c
>> +++ b/drivers/soc/mediatek/mtk-mmsys.c
>> @@ -312,8 +312,10 @@ static int mtk_mmsys_probe(struct platform_device *pdev)
>>  
>>  drm = platform_device_register_data(>dev, "mediatek-drm",
>>  PLATFORM_DEVID_AUTO, NULL, 0);
>> -if (IS_ERR(drm))
>> +if (IS_ERR(drm)) {
>> +platform_device_unregister(clks);
>>  return PTR_ERR(drm);
>> +}
>>  
>>  return 0;
>>  }
>>
>>
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>

Re: [PATCH] coresight: etm4x: Add support to disable trace unit power up

[Mathieu Poirier]

On Thu, 14 May 2020 at 12:39, Sai Prakash Ranjan
 wrote:
>
> Hi Mathieu,
>
> On 2020-05-14 23:30, Mathieu Poirier wrote:
> > Good morning Sai,
> >
> > On Thu, May 14, 2020 at 04:29:15PM +0530, Sai Prakash Ranjan wrote:
> >> From: Tingwei Zhang 
> >>
> >> On some Qualcomm Technologies Inc. SoCs like SC7180, there
> >> exists a hardware errata where the APSS (Application Processor
> >> SubSystem)/CPU watchdog counter is stopped when ETM register
> >> TRCPDCR.PU=1.
> >
> > Fun stuff...
> >
>
> Yes :)
>
> >> Since the ETMs share the same power domain as
> >> that of respective CPU cores, they are powered on when the
> >> CPU core is powered on. So we can disable powering up of the
> >> trace unit after checking for this errata via new property
> >> called "qcom,tupwr-disable".
> >>
> >> Signed-off-by: Tingwei Zhang 
> >> Co-developed-by: Sai Prakash Ranjan 
> >> Signed-off-by: Sai Prakash Ranjan 
> >
> > Co-developed-by: Sai Prakash Ranjan 
> > Signed-off-by: Tingwei Zhang 
> >
>
> Tingwei is the author, so if I understand correctly, his signed-off-by
> should appear first, am I wrong?

It's a gray area and depends on who's code is more prevalent in the
patch.  If Tingwei wrote the most of the code then his name is in the
"from:" section, yours as co-developer and he signs off on it (as I
suggested).  If you did most of the work then it is the opposite.
Adding a Co-developed and a signed-off with the same name doesn't make
sense.

>
> >> ---
> >>  .../devicetree/bindings/arm/coresight.txt |  6 
> >>  drivers/hwtracing/coresight/coresight-etm4x.c | 29
> >> ---
> >
> > Please split in two patches.
> >
>
> Sure, I will split the dt-binding into separate patch, checkpatch did
> warn.

And you still sent me the patch...  I usually run checkpatch before
all the submissions I review and flatly ignore patches that return
errors.  You got lucky...

>
> >>  2 files changed, 25 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt
> >> b/Documentation/devicetree/bindings/arm/coresight.txt
> >> index 846f6daae71b..d2030128fe46 100644
> >> --- a/Documentation/devicetree/bindings/arm/coresight.txt
> >> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
> >> @@ -108,6 +108,12 @@ its hardware characteristcs.
> >>  * arm,cp14: must be present if the system accesses ETM/PTM
> >> management
> >>registers via co-processor 14.
> >>
> >> +* qcom,tupwr-disable: boolean. Indicates that trace unit power up
> >> can
> >> +  be disabled on Qualcomm Technologies Inc. systems where ETMs are
> >> in
> >> +  the same power domain as their CPU cores. This property is
> >> required
> >> +  to identify such systems with hardware errata where the CPU
> >> watchdog
> >> +  counter is stopped when TRCPDCR.PU=1.
> >> +
> >
> > I think something like "qcom,skip-power-up" would be clearer.
> >
> > Also, a better choice of words is that TRCPDCR.PU does not have to be
> > set on
> > Qualcomm...
> >
>
> Yes "qcom,skip-power-up" is a lot better, thanks. Also will use
> something as
> you suggested for description.
>
> >>  * Optional property for TMC:
> >>
> >>  * arm,buffer-size: size of contiguous buffer space for TMC ETR
> >> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c
> >> b/drivers/hwtracing/coresight/coresight-etm4x.c
> >> index fb0f5f4f3a91..6886b44f6947 100644
> >> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> >> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> >> @@ -104,6 +104,11 @@ struct etm4_enable_arg {
> >>  int rc;
> >>  };
> >>
> >> +static inline bool etm4_can_disable_tupwr(struct device *dev)
> >> +{
> >> +return fwnode_property_present(dev_fwnode(dev),
> >> "qcom,tupwr-disable");
> >> +}
> >> +
> >
> > Please call fwnode_property_present() at initialisation time to set a
> > new
> > drvdata::skip_power_up variable.  From there just switch on that in
> > etm4_enable/disable_hw().
> >
>
> Will do, thanks.
>
> Thanks,
> Sai
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> member
> of Code Aurora Forum, hosted by The Linux Foundation
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 13/19] spi: dw: Move Non-DMA code to the DW PCIe-SPI driver

[Andy Shevchenko]

On Fri, May 15, 2020 at 01:47:52PM +0300, Serge Semin wrote:
> This is a preparation patch before adding the DW DMA support into the
> DW SPI MMIO driver. We need to unpin the Non-DMA-specific code from the
> intended to be generic DW APB SSI DMA code. This isn't that hard,
> since the most part of the spi-dw-mid.c driver in fact implements a
> generic DMA interface for the DW SPI controller driver. The only Intel
> MID specifics concern getting the max frequency from the MRST Clock
> Control Unit and fetching the DMA controller channels from
> corresponding PCIe DMA controller. Since first one is related with the
> SPI interface configuration we moved it' implementation into the
> DW PCIe-SPI driver module. After that former spi-dw-mid.c file
> can be just renamed to be the DW SPI DMA module optionally compiled in to
> the DW APB SSI core driver.

Cc list here is huge!

I think this patch should go immediately after bunch of fixes.

...

> -obj-$(CONFIG_SPI_DESIGNWARE) += spi-dw.o
> +obj-$(CONFIG_SPI_DESIGNWARE) += spi-dw-core.o
> +spi-dw-core-y:= spi-dw.o
> +spi-dw-core-$(CONFIG_SPI_DW_DMA) += spi-dw-dma.o

We may leave module name the same, right?

obj-$(CONFIG_SPI_DESIGNWARE)+= spi-dw.o
spi-dw-y:= spi-dw-core.o
spi-dw-$(CONFIG_SPI_DW_DMA) += spi-dw-dma.o

>  obj-$(CONFIG_SPI_DW_MMIO)+= spi-dw-mmio.o
> -obj-$(CONFIG_SPI_DW_PCI) += spi-dw-midpci.o
> -spi-dw-midpci-objs   := spi-dw-pci.o spi-dw-mid.o
> +obj-$(CONFIG_SPI_DW_PCI) += spi-dw-pci.o

> -/* Some specific info for SPI0 controller on Intel MID */
> -
> -/* HW info for MRST Clk Control Unit, 32b reg per controller */
> -#define MRST_SPI_CLK_BASE1   /* 100m */
> -#define MRST_CLK_SPI_REG 0xff11d86c
> -#define CLK_SPI_BDIV_OFFSET  0
> -#define CLK_SPI_BDIV_MASK0x0007
> -#define CLK_SPI_CDIV_OFFSET  9
> -#define CLK_SPI_CDIV_MASK0x0e00
> -#define CLK_SPI_DISABLE_OFFSET   8
> -
> -int dw_spi_mid_init_mfld(struct dw_spi *dws)
> -{
> - void __iomem *clk_reg;
> - u32 clk_cdiv;
> -
> - clk_reg = ioremap(MRST_CLK_SPI_REG, 16);
> - if (!clk_reg)
> - return -ENOMEM;
> -
> - /* Get SPI controller operating freq info */
> - clk_cdiv = readl(clk_reg + dws->bus_num * sizeof(u32));
> - clk_cdiv &= CLK_SPI_CDIV_MASK;
> - clk_cdiv >>= CLK_SPI_CDIV_OFFSET;
> - dws->max_freq = MRST_SPI_CLK_BASE / (clk_cdiv + 1);
> -
> - iounmap(clk_reg);
> -
> - /* Register hook to configure CTRLR0 */
> - dws->update_cr0 = dw_spi_update_cr0;
> -
> - dw_spi_mid_setup_dma_mfld(dws);
> - return 0;
> -}
> -
> -int dw_spi_mid_init_generic(struct dw_spi *dws)
> -{
> - /* Register hook to configure CTRLR0 */
> - dws->update_cr0 = dw_spi_update_cr0;
> -
> - dw_spi_mid_setup_dma_generic(dws);
> - return 0;
> -}
> +EXPORT_SYMBOL_GPL(dw_spi_mid_setup_dma_generic);
> diff --git a/drivers/spi/spi-dw-pci.c b/drivers/spi/spi-dw-pci.c
> index dde54a918b5d..c13707b8493e 100644
> --- a/drivers/spi/spi-dw-pci.c
> +++ b/drivers/spi/spi-dw-pci.c
> @@ -15,6 +15,15 @@
>  
>  #define DRIVER_NAME "dw_spi_pci"
>  
> +/* HW info for MRST Clk Control Unit, 32b reg per controller */
> +#define MRST_SPI_CLK_BASE1   /* 100m */
> +#define MRST_CLK_SPI_REG 0xff11d86c
> +#define CLK_SPI_BDIV_OFFSET  0
> +#define CLK_SPI_BDIV_MASK0x0007
> +#define CLK_SPI_CDIV_OFFSET  9
> +#define CLK_SPI_CDIV_MASK0x0e00
> +#define CLK_SPI_DISABLE_OFFSET   8
> +
>  struct spi_pci_desc {
>   int (*setup)(struct dw_spi *);
>   u16 num_cs;
> @@ -22,20 +31,55 @@ struct spi_pci_desc {
>   u32 max_freq;
>  };
>  
> +static int spi_mid_init(struct dw_spi *dws)
> +{
> + void __iomem *clk_reg;
> + u32 clk_cdiv;
> +
> + clk_reg = ioremap(MRST_CLK_SPI_REG, 16);
> + if (!clk_reg)
> + return -ENOMEM;
> +
> + /* Get SPI controller operating freq info */
> + clk_cdiv = readl(clk_reg + dws->bus_num * sizeof(u32));
> + clk_cdiv &= CLK_SPI_CDIV_MASK;
> + clk_cdiv >>= CLK_SPI_CDIV_OFFSET;
> + dws->max_freq = MRST_SPI_CLK_BASE / (clk_cdiv + 1);
> +
> + iounmap(clk_reg);
> +
> + /* Register hook to configure CTRLR0 */
> + dws->update_cr0 = dw_spi_update_cr0;
> +
> + dw_spi_mid_setup_dma_mfld(dws);
> +
> + return 0;
> +}
> +
> +static int spi_generic_init(struct dw_spi *dws)
> +{
> + /* Register hook to configure CTRLR0 */
> + dws->update_cr0 = dw_spi_update_cr0;
> +
> + dw_spi_mid_setup_dma_generic(dws);
> +
> + return 0;
> +}
> +
>  static struct spi_pci_desc spi_pci_mid_desc_1 = {
> - .setup = dw_spi_mid_init_mfld,
> + .setup = spi_mid_init,
>   .num_cs = 5,
>   .bus_num = 0,
>  };
>  
>  static struct spi_pci_desc spi_pci_mid_desc_2 = {
> - .setup = dw_spi_mid_init_mfld,
> + .setup = spi_mid_init,
>   

Re: [PATCH 00/16] ARM: dts: at91: sama5d2: Rework Flexcom definitions

[Alexandre Belloni]

On 14/05/2020 05:03:06+, tudor.amba...@microchip.com wrote:
> From: Tudor Ambarus 
> 
> Rework the sama5d2 SoC flexcom definitions. The Flexcom IPs are
> in the SoC. Move all the flexcom nodes together with their function
> definitions in the SoC dtsi. Boards will just fill the pins and enable
> the desired functions. With this we remove the duplication of the
> flexcom definitions across the sama5d2 boards.
> 
> Round the flexcom support and add the missing flexcom definitions.
> All the flexcom functions are now defined.
> 
> Apart of the aliases and the new flx0 i2c function on sama5d2_xplained,
> the only functional change that this patch set adds, is that it uart5,
> uart6 and uart7 inherit the atmel,fifo-size = <32>; optional property.
> These nodes have both the FIFO size described and the DMA enabled.
> uart5 was tested on sama5d27-wlsom1-ek. On uart6 and uart7 a
> Bluetooth module can be connected. Tested BT uart7 on sama5d2-icp.
> 
> Tudor Ambarus (16):
>   ARM: dts: at91: sama5d2: Fix the label numbering for flexcom functions
>   ARM: dts: at91: sama5d2: Move flx4 definitions in the SoC dtsi
>   ARM: dts: at91: sama5d2: Move flx3 definitions in the SoC dtsi
>   ARM: dts: at91: sama5d2: Move flx2 definitions in the SoC dtsi
>   ARM: dts: at91: sama5d2: Move flx1 definitions in the SoC dtsi
>   ARM: dts: at91: sama5d2: Move flx0 definitions in the SoC dtsi
>   ARM: dts: at91: sama5d2: Specify the FIFO size for the Flexcom UART
>   ARM: dts: at91: sama5d2: Add DMA bindings for the SPI and UART flx4
> functions
>   ARM: dts: at91: sama5d2: Add DMA bindings for the flx3 SPI function
>   ARM: dts: at91: sama5d2: Add DMA bindings for the flx1 I2C function
>   ARM: dts: at91: sama5d2: Add DMA bindings for the SPI and I2C flx0
> functions
>   ARM: dts: at91: sama5d2: Add missing flexcom definitions
>   ARM: dts: at91: sama5d2: Remove i2s and tcb aliases from SoC dtsi
>   ARM: dts: at91: sama5d2_xplained: Add alias for DBGU
>   ARM: dts: at91: sama5d2_xplained: Describe the flx0 I2C function
>   ARM: dts: at91: sama5d2_ptc_ek: Add comments to describe the aliases
> 
Applied, thanks.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v3 3/4] serial: 8250_dw: Simplify the ref clock rate setting procedure

[Serge Semin]

On Fri, May 15, 2020 at 05:05:47PM +0300, Andy Shevchenko wrote:
> On Thu, May 07, 2020 at 02:31:34AM +0300, Serge Semin wrote:
> > Really instead of twice checking the clk_round_rate() return value
> > we could do it once, and if it isn't error the clock rate can be changed.
> > By doing so we decrease a number of ret-value tests and remove a weird
> > goto-based construction implemented in the dw8250_set_termios() method.
> 
> > rate = clk_round_rate(d->clk, baud * 16);
> > -   if (rate < 0)
> > -   ret = rate;
> 
> > -   else if (rate == 0)
> > -   ret = -ENOENT;
> 
> This case now handled differently.
> I don't think it's good idea to change semantics.
> 
> So, I don't see how this, after leaving the rate==0 case, would be better than
> original one.

Semantic doesn't change. The code does exactly the same as before. If it didn't
I either would have provided a comment about this or just didn't introduce the
change in the first place. I guess you just don't see the whole picture of the
method. Take a look in the code. The ret variable's been used to skip the
"p->uartclk = rate" assignment. That's it. So the (rate == 0) will still be
considered as error condition, which causes the clock rate left unchanged.
Here is the code diff so you wouldn't need to dive deep into the driver
sources:

<   clk_disable_unprepare(d->clk);
<   rate = clk_round_rate(d->clk, baud * 16);
<   if (rate < 0)
<   ret = rate;
<   else if (rate == 0)
<   ret = -ENOENT;
<   else
<   ret = clk_set_rate(d->clk, rate);
<   clk_prepare_enable(d->clk);
<
<   if (ret)
<   goto out;
<
<   p->uartclk = rate;
<
   clk_disable_unprepare(d->clk);
>   rate = clk_round_rate(d->clk, baud * 16);
>   if (rate > 0) {
>  ret = clk_set_rate(d->clk, rate);
>  if (!ret)
>  p->uartclk = rate;
>   }
>   clk_prepare_enable(d->clk);

-Sergey

> 
> > -   else
> > +   if (rate > 0) {
> > ret = clk_set_rate(d->clk, rate);
> > +   if (!ret)
> > +   p->uartclk = rate;
> > +   }
> > clk_prepare_enable(d->clk);
> >  
> > -   if (ret)
> > -   goto out;
> > -
> > -   p->uartclk = rate;
> > -
> > -out:
> > p->status &= ~UPSTAT_AUTOCTS;
> > if (termios->c_cflag & CRTSCTS)
> > p->status |= UPSTAT_AUTOCTS;
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

Re: [PATCHv1 03/19] power: supply: core: add manufacture date properties

[Emil Velikov]

Hi Sebastian,

On 2020/05/13, Sebastian Reichel wrote:
> Some smart batteries store their manufacture date, which is
> useful to identify the battery and/or to know about the cell
> quality.
> 
Have you considered exposing this as a single file? Say following the ISO8601
format - -MM-DD.

-Emil

Re: [PATCH 1/4] dt-bindings: i2c: Document I2C controller binding for MT6797 SoC

[Matthias Brugger]

Hi Wolfram,

On 26/02/2020 23:23, Rob Herring wrote:
> On Sat, 22 Feb 2020 21:54:41 +0530, Manivannan Sadhasivam wrote:
>> I2C controller driver for MT6577 SoC is reused for MT6797 SoC. Hence,
>> document that in DT binding.
>>
>> Signed-off-by: Manivannan Sadhasivam 
>> ---
>>  Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt | 1 +
>>  1 file changed, 1 insertion(+)
>>
> 
> Acked-by: Rob Herring 
> 

Do you want to take this thorough your tree or are you OK if I take it thorough
mine?

Regards,
Matthias

Re: [PATCH 4/4] thermal: core: genetlink support for events/cmd/sampling

[Srinivas Pandruvada]

On Fri, 2020-05-15 at 16:10 +0200, Daniel Lezcano wrote:
> Initially the thermal framework had a very simple notification
> mechanism to send generic netlink messages to the userspace.
> 
> The notification function was never called from anywhere and the
> corresponding dead code was removed. It was probably a first attempt
> to introduce the netlink notification.
> 
> At LPC2018, the presentation "Linux thermal: User kernel interface",
> proposed to create the notifications to the userspace via a kfifo.
> 
> The advantage of the kfifo is the performance. It is usually used
> from
> a 1:1 communication channel where a driver captures data and send
> them
> as fast as possible to an userspace process.
Shall I submit my RFC using KFifo on top of this series? Any
objections?

Thanks,
Srinivas

> The inconvenient is the process uses the notification channel
> exclusively, thus no other process is allowed to use the channel to
> get temperature or notifications.
> 
> The purpose of this series is to provide a fully netlink featured
> thermal management.
> 
> This patch is defining a generic netlink API to discover the current
> thermal setup, get events and temperature sampling. As any genetlink
> protocol, it can evolve and the versionning allows to keep the
> backward
> compatibility.
> 
> In order to not flood the user with a single channel data, there are
> two multicast channels, one for the temperature sampling when the
> thermal zone is updated and another one for the events, so the user
> can get the events only without the thermal zone temperature
> sampling. All these events are from the ones presented at the
> LPC2018.
> 
> Also, a list of commands to discover the thermal setup is given and
> can be extended on purpose.
> 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/Makefile  |   2 +-
>  drivers/thermal/thermal_core.h|  13 +
>  drivers/thermal/thermal_netlink.c | 612
> ++
>  include/linux/thermal.h   |  12 -
>  include/uapi/linux/thermal.h  |  80 +++-
>  5 files changed, 699 insertions(+), 20 deletions(-)
>  create mode 100644 drivers/thermal/thermal_netlink.c
> 
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 8c8ed7b79915..80fddb02cb32 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -5,7 +5,7 @@
>  
>  obj-$(CONFIG_THERMAL)+= thermal_sys.o
>  thermal_sys-y+= thermal_core.o
> thermal_sysfs.o \
> - thermal_helpers.o
> + thermal_helpers.o
> thermal_netlink.o
>  
>  # interface to/from other layers providing sensors
>  thermal_sys-$(CONFIG_THERMAL_HWMON)  += thermal_hwmon.o
> diff --git a/drivers/thermal/thermal_core.h
> b/drivers/thermal/thermal_core.h
> index 7e8f45db6bbf..4c98d398c301 100644
> --- a/drivers/thermal/thermal_core.h
> +++ b/drivers/thermal/thermal_core.h
> @@ -52,6 +52,19 @@ int for_each_thermal_governor(int (*cb)(struct
> thermal_governor *, void *),
>  
>  struct thermal_zone_device *thermal_zone_get_by_id(int id);
>  
> +/* Netlink notification function */
> +int thermal_notify_tz_create(int tz_id, const char *name);
> +int thermal_notify_tz_delete(int tz_id);
> +int thermal_notify_tz_enable(int tz_id);
> +int thermal_notify_tz_disable(int tz_id);
> +int thermal_notify_tz_trip_low(int tz_id, int id);
> +int thermal_notify_tz_trip_high(int tz_id, int id);
> +int thermal_notify_tz_trip_delete(int tz_id, int id);
> +int thermal_notify_tz_trip_add(int tz_id, int id, int type,
> +int temp, int hyst);
> +int thermal_notify_tz_trip_change(int tz_id, int id, int type,
> +   int temp, int hyst);
> +
>  struct thermal_attr {
>   struct device_attribute attr;
>   char name[THERMAL_NAME_LENGTH];
> diff --git a/drivers/thermal/thermal_netlink.c
> b/drivers/thermal/thermal_netlink.c
> new file mode 100644
> index ..a2bce846771e
> --- /dev/null
> +++ b/drivers/thermal/thermal_netlink.c
> @@ -0,0 +1,612 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2020 Linaro Limited
> + *
> + * Author: Daniel Lezcano 
> + *
> + * Generic netlink for thermal management framework
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "thermal_core.h"
> +
> +static const struct genl_multicast_group thermal_genl_mcgrps[] = {
> + { .name = THERMAL_GENL_SAMPLING_GROUP_NAME, },
> + { .name = THERMAL_GENL_EVENT_GROUP_NAME,  },
> +};
> +
> +static const struct nla_policy
> thermal_genl_policy[THERMAL_GENL_ATTR_MAX + 1] = {
> + /* Thermal zone */
> + [THERMAL_GENL_ATTR_TZ]  = { .type =
> NLA_NESTED },
> + [THERMAL_GENL_ATTR_TZ_ID]   = { .type = NLA_U32 },
> + [THERMAL_GENL_ATTR_TZ_TEMP] = { .type = NLA_U32
> },
> + [THERMAL_GENL_ATTR_TZ_TRIP] = { .type =
> NLA_NESTED },
> + 

Re: [PATCHv1 01/19] kobject: increase allowed number of uevent variables

[Emil Velikov]

On 2020/05/13, Sebastian Reichel wrote:
> SBS battery driver exposes 32 power supply properties now,
> which will result in uevent failure on (un)plugging the
> battery. Other drivers (e.g. bq27xxx) are also coming close
> to this limit, so increase it.
> 
> Signed-off-by: Sebastian Reichel 
> ---
>  include/linux/kobject.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/kobject.h b/include/linux/kobject.h
> index e2ca0a292e21..75e822569e39 100644
> --- a/include/linux/kobject.h
> +++ b/include/linux/kobject.h
> @@ -29,7 +29,7 @@
>  #include 
>  
>  #define UEVENT_HELPER_PATH_LEN   256
> -#define UEVENT_NUM_ENVP  32  /* number of env 
> pointers */
> +#define UEVENT_NUM_ENVP  64  /* number of env 
> pointers */

To be on the safe side I've checked systemd/udev. It's using ordered hashmap,
so it's perfectly capable of handling the extra entries.

Reviewed-by: Emil Velikov 

-Emil

linux-next boot error: general protection fault in tomoyo_get_local_path

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:bdecf38f Add linux-next specific files for 20200515
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=155a43b210
kernel config:  https://syzkaller.appspot.com/x/.config?x=27a5e30c87a59937
dashboard link: https://syzkaller.appspot.com/bug?extid=c1af344512918c61362c
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+c1af344512918c613...@syzkaller.appspotmail.com

general protection fault, probably for non-canonical address 
0xdc05:  [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0028-0x002f]
CPU: 0 PID: 6698 Comm: sshd Not tainted 5.7.0-rc5-next-20200515-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:tomoyo_get_local_path+0x450/0x800 security/tomoyo/realpath.c:165
Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 b4 03 00 00 48 b8 00 00 00 00 00 
fc ff df 4d 8b 7f 60 49 8d 7f 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 87 03 
00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b
RSP: 0018:c900063d7450 EFLAGS: 00010206
RAX: dc00 RBX: 88809975c000 RCX: 8363deda
RDX: 0005 RSI: 8363dee8 RDI: 0028
RBP: 192000c7ae8b R08: 8880a47644c0 R09: fbfff155a0a2
R10: 8aad050f R11: fbfff155a0a1 R12: 88809df3cfea
R13: 88809df3c000 R14: 1a2a R15: 
FS:  7efe13ce28c0() GS:8880ae60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 55e78cf578f5 CR3: 987ed000 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 tomoyo_realpath_from_path+0x393/0x620 security/tomoyo/realpath.c:282
 tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
 tomoyo_path_number_perm+0x1c2/0x4d0 security/tomoyo/file.c:723
 tomoyo_path_mknod+0x10d/0x190 security/tomoyo/tomoyo.c:246
 security_path_mknod+0x116/0x180 security/security.c:1072
 may_o_create fs/namei.c:2905 [inline]
 lookup_open+0x5ae/0x1320 fs/namei.c:3046
 open_last_lookups fs/namei.c:3155 [inline]
 path_openat+0x93c/0x27f0 fs/namei.c:3343
 do_filp_open+0x192/0x260 fs/namei.c:3373
 do_sys_openat2+0x585/0x7d0 fs/open.c:1179
 do_sys_open+0xc3/0x140 fs/open.c:1195
 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
 entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x7efe11e4b6f0
Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 
00 00 83 3d 19 30 2c 00 00 75 10 b8 02 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 
c3 48 83 ec 08 e8 fe 9d 01 00 48 89 04 24
RSP: 002b:7ffc3d0894d8 EFLAGS: 0246 ORIG_RAX: 0002
RAX: ffda RBX: 55e78f0bc110 RCX: 7efe11e4b6f0
RDX: 01b6 RSI: 0241 RDI: 55e78cf578f5
RBP: 0004 R08: 0004 R09: 0001
R10: 0240 R11: 0246 R12: 55e78cf2851e
R13: 0001 R14:  R15: 
Modules linked in:
---[ end trace 0a58064de06d50f4 ]---
RIP: 0010:tomoyo_get_local_path+0x450/0x800 security/tomoyo/realpath.c:165
Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 b4 03 00 00 48 b8 00 00 00 00 00 
fc ff df 4d 8b 7f 60 49 8d 7f 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 87 03 
00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b
RSP: 0018:c900063d7450 EFLAGS: 00010206
RAX: dc00 RBX: 88809975c000 RCX: 8363deda
RDX: 0005 RSI: 8363dee8 RDI: 0028
RBP: 192000c7ae8b R08: 8880a47644c0 R09: fbfff155a0a2
R10: 8aad050f R11: fbfff155a0a1 R12: 88809df3cfea
R13: 88809df3c000 R14: 1a2a R15: 
FS:  7efe13ce28c0() GS:8880ae60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 55dfe16c15f8 CR3: 987ed000 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Re: [f2fs-dev] [PATCH] f2fs: flush dirty meta pages when flushing them

[Jaegeuk Kim]

On 05/15, Chao Yu wrote:
> On 2020/5/15 10:15, Jaegeuk Kim wrote:
> > Let's guarantee flusing dirty meta pages to avoid infinite loop.
> 
> What's the root cause? Race case or meta page flush failure?

Investigating, but at least, this can avoid the inifinite loop there.

V2:

>From c60ce8e7178004fd6cba96e592247e43b5fd98d8 Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim 
Date: Wed, 13 May 2020 21:12:53 -0700
Subject: [PATCH] f2fs: flush dirty meta pages when flushing them

Let's guarantee flusing dirty meta pages to avoid infinite loop.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/checkpoint.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 620a386d82c1a..3dc3ac6fe1432 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -1266,6 +1266,9 @@ void f2fs_wait_on_all_pages(struct f2fs_sb_info *sbi, int 
type)
if (unlikely(f2fs_cp_error(sbi)))
break;
 
+   if (type == F2FS_DIRTY_META)
+   f2fs_sync_meta_pages(sbi, META, LONG_MAX,
+   FS_CP_META_IO);
io_schedule_timeout(DEFAULT_IO_TIMEOUT);
}
finish_wait(>cp_wait, );
-- 
2.26.2.761.g0e0b3e54be-goog

Re: [PATCH 00/13] Reconcile NUMA balancing decisions with the load balancer v6

[Jirka Hladky]

> Complete shot in the dark but restore adjust_numa_imbalance() and try
> this
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 1a9983da4408..0b31f4468d5b 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2393,7 +2393,7 @@ static void ttwu_queue(struct task_struct *p, int cpu, 
> int wake_flags)
> struct rq_flags rf;
>  #if defined(CONFIG_SMP)
> -   if (sched_feat(TTWU_QUEUE) && !cpus_share_cache(smp_processor_id(), 
> cpu)) {
> +   if (sched_feat(TTWU_QUEUE)) {
> sched_clock_cpu(cpu); /* Sync clocks across CPUs */
> ttwu_queue_remote(p, cpu, wake_flags);
> return;

Hi Mel,

we have performance results for the proposed patch above ^^^.
Unfortunately, it hasn't helped the performance.

Jirka


On Wed, May 13, 2020 at 5:30 PM Mel Gorman  wrote:
>
> On Wed, May 13, 2020 at 04:57:15PM +0200, Jirka Hladky wrote:
> > Hi Mel,
> >
> > we have tried the kernel with adjust_numa_imbalance() crippled to just
> > return the imbalance it's given.
> >
> > It has solved all the performance problems I have reported.
> > Performance is the same as with 5.6 kernel (before the patch was
> > applied).
> >
> > * solved the performance drop upto 20%  with single instance
> > SPECjbb2005 benchmark on 8 NUMA node servers (particularly on AMD EPYC
> > Rome systems) => this performance drop was INCREASING with higher
> > threads counts (10% for 16 threads and 20 % for 32 threads)
> > * solved the performance drop for low load scenarios (SPECjvm2008 and NAS)
> >
> > Any suggestions on how to proceed? One approach is to turn
> > "imbalance_min" into the kernel tunable. Any other ideas?
> >
> > https://github.com/torvalds/linux/blob/4f8a3cc1183c442daee6cc65360e3385021131e4/kernel/sched/fair.c#L8914
> >
>
> Complete shot in the dark but restore adjust_numa_imbalance() and try
> this
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 1a9983da4408..0b31f4468d5b 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2393,7 +2393,7 @@ static void ttwu_queue(struct task_struct *p, int cpu, 
> int wake_flags)
> struct rq_flags rf;
>
>  #if defined(CONFIG_SMP)
> -   if (sched_feat(TTWU_QUEUE) && !cpus_share_cache(smp_processor_id(), 
> cpu)) {
> +   if (sched_feat(TTWU_QUEUE)) {
> sched_clock_cpu(cpu); /* Sync clocks across CPUs */
> ttwu_queue_remote(p, cpu, wake_flags);
> return;
>
> --
> Mel Gorman
> SUSE Labs
>


-- 
-Jirka

[LTP] [ANNOUNCE] The Linux Test Project has been released for MAY 2020

[Cyril Hrubis]

Good news everyone,

the Linux Test Project test suite stable release for *May 2020* has been
released.

Since the last release 327 patches by 26 authors were merged.

NOTABLE CHANGES
===

* New tests
  - fanotify16: FAN_MODIFY_DIR test
  - ioctl_loop01: LO_FLAGS_AUTOCLEAR and LO_FLAGS_PARTSCAN test
  - ioctl_loop02: LO_FLAGS_READ_ONLY and LOOP_CHANGE_FD test
  - ioctl_loop03: LOOP_CHANGE_FD test with WR mode
  - ioctl_loop04: LOOP_SET_CAPACITY ioctl test
  - ioctl_loop05: LOOP_SET_DIRECT_IO ioctl test
  - ioctl_loop06: LOOP_SET_BLOCK_SIZE error test
  - ioctl_loop07: LOOP_SET/GET_STATUS64 sizelimit field test
  - pipe2_02: test for pipe2 O_CLOEXEC flag
  - pipe2_04: test for pipe2 with/without O_NONBLOCK mode
  - timerfd04: time namespace test
  - timens01: time namespace test
  - clock_gettime03: time namespace test
  - clock_nanosleep03: time namespace test
  - sysinfo03: time namespace test
  - clone301, clone301: clone3() syscall tests
  - bind04: Connection tests for stream-oriented sockets (SOCK_STREAM and 
SOCK_SEQPACKET)
  - bind05: Connection tests for datagram-oriented sockets (SOCK_DGRAM)
  - fcntl37: add error test for fcntl with F_SETPIPE_SZ
  - openat201, openat202, openat203: openat2() syscall tests
  - open_tree01, open_tree02: open_tree() syscall tests
  - fspick01, fspick02: fspick() syscall tests
  - move_mount01, move_mount02: move_mount() syscall tests
  - fsmount01, fsmount02: fsmount() syscall tests
  - fsconfig01, fsconfig02: fsconfig() syscall tests
  - fsopen01, fsopen02: fsopen() syscall tests
  - pty04: Test data transmission with SLIP line discipline
  - fallocate06: test for misaligned fallocate()
  - io_pgetevents01, io_pgetevents02: io_pgetevents() syscall tests
  - pidfd_open01, pidfd_open02, pidfd_open03: pidfd_open() syscall tests
  - vmsplice04: vmsplice() test with SPLICE_F_NONBLOCK
  - pipe12: add new test for pipe when write bytes > pipe size

* New regression tests
  - pty04: Added SLCAN ldisc and check for CVE-2020-11494
  - setsockopt05: Test for CVE-2017-1000112
  - ptrace09: Test for CVE-2018-8897
  - snd_seq01: Test for CVE-2018-7566
  - bind06: Test for CVE-2018-18559
  - ptrace08: Test for CVE-2018-1000199
  - ioctl_sg01: Test for CVE-2018-1000204
  - sendmsg03: Test for CVE-2017-17712
  - timerfd_settime02: Test for CVE-2017-10661
  - connect02: Test for CVE 2018-9568
   and also for setsockopt(IP_ADDRFORM) kernel bug
   (82c9ae440857 ipv6: fix restrict IPV6_ADDRFORM operation)
  - fanotify15: Add a test case for inode marks
  (f367a62a7cad fanotify: merge duplicate events on parent and 
child)
  - fanotify09: Check merging of events on directories
 (55bf882c7f13 fanotify: fix merging marks masks with FAN_ONDIR)
  - add_key05: add maxbytes/maxkeys test under unprivileged user
   (a08bf91ce28e "KEYS: allow reaching the keys quotas exactly")
  - pipe13: test for pipe to wake up all readers
(6551d5c56eb0 "pipe: make sure to wake up everybody when the last 
reader/writer closes")
  - quotactl07: test for Q_XQTUOTARM
(3dd4d40b4208 "xfs: Sanity check flags of Q_XQUOTARM call")
  - pty03: test for slip/slcan data race
   (0ace17d568241 "can, slip: Protect tty->disc_data in write_wakeup 
and close with RCU")

* Increased coverage
  - readv01: new test cases added to the test
  - add_key02: add the "big_key" key type

* First half of time64 tests for 64bit timer syscalls has landed in this
  relese, second half is going to be part of the next one1

* Additional 12 tests were converted to the new test library

* Removed tests
  - epoll2: these depended on Portable Coroutine Library and were not even
compiled by default for a long time

* Fixes for gcc-10 that enables -fno-common by default

* LTP now supports ARC CPUs

* Skip oversleep checks in timer tests under VM

+ The usual amount of fixes and cleanups.


NOTABLE CHANGES IN NETWORK TESTS

brought to you by Petr Vorel

* New netlink based route change tests

* Fixes
  - nfs: detect disabled UDP
  - rpc: cleanup unused tests
  - detect libtirpc with pkg-config

* Rewrite to new API
  - bind02, socketcall0[2-4], test_1_to_1_initmsg_connect (SCTP)
  - rpcinfo01.sh, rpc01.sh, sendfile01.sh, xinetd_tests.sh

DOWNLOAD AND LINKS
==

The latest version of the test-suite contains 3000+ tests for the Linux
and can be downloaded at:

https://github.com/linux-test-project/ltp/releases/tag/20200515

The project pages as well as GIT repository are hosted on GitHub:

https://github.com/linux-test-project/ltp
http://linux-test-project.github.io/

If you ever wondered how to write a LTP testcase, don't miss our developer
documentation at:

https://github.com/linux-test-project/ltp/wiki/C-Test-Case-Tutorial
https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines
https://github.com/linux-test-project/

Re: How about just O_EXEC? (was Re: [PATCH v5 3/6] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC)

[Florian Weimer]

* Kees Cook:

> On Fri, May 15, 2020 at 10:43:34AM +0200, Florian Weimer wrote:
>> * Kees Cook:
>> 
>> > Maybe I've missed some earlier discussion that ruled this out, but I
>> > couldn't find it: let's just add O_EXEC and be done with it. It actually
>> > makes the execve() path more like openat2() and is much cleaner after
>> > a little refactoring. Here are the results, though I haven't emailed it
>> > yet since I still want to do some more testing:
>> > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/o_exec/v1
>> 
>> I think POSIX specifies O_EXEC in such a way that it does not confer
>> read permissions.  This seems incompatible with what we are trying to
>> achieve here.
>
> I was trying to retain this behavior, since we already make this
> distinction between execve() and uselib() with the MAY_* flags:
>
> execve():
> struct open_flags open_exec_flags = {
> .open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC,
> .acc_mode = MAY_EXEC,
>
> uselib():
> static const struct open_flags uselib_flags = {
> .open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC,
> .acc_mode = MAY_READ | MAY_EXEC,
>
> I tried to retain this in my proposal, in the O_EXEC does not imply
> MAY_READ:

That doesn't quite parse for me, sorry.

The point is that the script interpreter actually needs to *read* those
files in order to execute them.

Thanks,
Florian

Re: [PATCH 4/4] thermal: core: genetlink support for events/cmd/sampling

[Srinivas Pandruvada]

On Fri, 2020-05-15 at 16:10 +0200, Daniel Lezcano wrote:
> Initially the thermal framework had a very simple notification
> mechanism to send generic netlink messages to the userspace.
> 
> The notification function was never called from anywhere and the
> corresponding dead code was removed. It was probably a first attempt
> to introduce the netlink notification.
> 
> At LPC2018, the presentation "Linux thermal: User kernel interface",
> proposed to create the notifications to the userspace via a kfifo.
> 
> The advantage of the kfifo is the performance. It is usually used
> from
> a 1:1 communication channel where a driver captures data and send
> them
> as fast as possible to an userspace process.
Shall I submit my RFC using KFifo on top of this series? Any
objections?

Thanks,
Srinivas

> The inconvenient is the process uses the notification channel
> exclusively, thus no other process is allowed to use the channel to
> get temperature or notifications.
> 
> The purpose of this series is to provide a fully netlink featured
> thermal management.
> 
> This patch is defining a generic netlink API to discover the current
> thermal setup, get events and temperature sampling. As any genetlink
> protocol, it can evolve and the versionning allows to keep the
> backward
> compatibility.
> 
> In order to not flood the user with a single channel data, there are
> two multicast channels, one for the temperature sampling when the
> thermal zone is updated and another one for the events, so the user
> can get the events only without the thermal zone temperature
> sampling. All these events are from the ones presented at the
> LPC2018.
> 
> Also, a list of commands to discover the thermal setup is given and
> can be extended on purpose.
> 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/Makefile  |   2 +-
>  drivers/thermal/thermal_core.h|  13 +
>  drivers/thermal/thermal_netlink.c | 612
> ++
>  include/linux/thermal.h   |  12 -
>  include/uapi/linux/thermal.h  |  80 +++-
>  5 files changed, 699 insertions(+), 20 deletions(-)
>  create mode 100644 drivers/thermal/thermal_netlink.c
> 
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 8c8ed7b79915..80fddb02cb32 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -5,7 +5,7 @@
>  
>  obj-$(CONFIG_THERMAL)+= thermal_sys.o
>  thermal_sys-y+= thermal_core.o
> thermal_sysfs.o \
> - thermal_helpers.o
> + thermal_helpers.o
> thermal_netlink.o
>  
>  # interface to/from other layers providing sensors
>  thermal_sys-$(CONFIG_THERMAL_HWMON)  += thermal_hwmon.o
> diff --git a/drivers/thermal/thermal_core.h
> b/drivers/thermal/thermal_core.h
> index 7e8f45db6bbf..4c98d398c301 100644
> --- a/drivers/thermal/thermal_core.h
> +++ b/drivers/thermal/thermal_core.h
> @@ -52,6 +52,19 @@ int for_each_thermal_governor(int (*cb)(struct
> thermal_governor *, void *),
>  
>  struct thermal_zone_device *thermal_zone_get_by_id(int id);
>  
> +/* Netlink notification function */
> +int thermal_notify_tz_create(int tz_id, const char *name);
> +int thermal_notify_tz_delete(int tz_id);
> +int thermal_notify_tz_enable(int tz_id);
> +int thermal_notify_tz_disable(int tz_id);
> +int thermal_notify_tz_trip_low(int tz_id, int id);
> +int thermal_notify_tz_trip_high(int tz_id, int id);
> +int thermal_notify_tz_trip_delete(int tz_id, int id);
> +int thermal_notify_tz_trip_add(int tz_id, int id, int type,
> +int temp, int hyst);
> +int thermal_notify_tz_trip_change(int tz_id, int id, int type,
> +   int temp, int hyst);
> +
>  struct thermal_attr {
>   struct device_attribute attr;
>   char name[THERMAL_NAME_LENGTH];
> diff --git a/drivers/thermal/thermal_netlink.c
> b/drivers/thermal/thermal_netlink.c
> new file mode 100644
> index ..a2bce846771e
> --- /dev/null
> +++ b/drivers/thermal/thermal_netlink.c
> @@ -0,0 +1,612 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2020 Linaro Limited
> + *
> + * Author: Daniel Lezcano 
> + *
> + * Generic netlink for thermal management framework
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "thermal_core.h"
> +
> +static const struct genl_multicast_group thermal_genl_mcgrps[] = {
> + { .name = THERMAL_GENL_SAMPLING_GROUP_NAME, },
> + { .name = THERMAL_GENL_EVENT_GROUP_NAME,  },
> +};
> +
> +static const struct nla_policy
> thermal_genl_policy[THERMAL_GENL_ATTR_MAX + 1] = {
> + /* Thermal zone */
> + [THERMAL_GENL_ATTR_TZ]  = { .type =
> NLA_NESTED },
> + [THERMAL_GENL_ATTR_TZ_ID]   = { .type = NLA_U32 },
> + [THERMAL_GENL_ATTR_TZ_TEMP] = { .type = NLA_U32
> },
> + [THERMAL_GENL_ATTR_TZ_TRIP] = { .type =
> NLA_NESTED },
> + 

Re: [PATCH v5 2/2] rpmsg: core: Add support to retrieve name extension

[Arnaud POULIQUEN]

Hi Mathieu


On 5/14/20 10:40 PM, Mathieu Poirier wrote:
> After adding support for rpmsg device name extension, this patch
> provides a function that returns the extension portion of an rpmsg
> device name.  That way users of the name extension functionality don't
> have to write the same boiler plate code to extract the information.
> 
> Suggested-by: Suman Anna ;
> Signed-off-by: Mathieu Poirier 

Probably what is missing now it is an upstreamed client. :)
If a client is mandatory sample/rpmsg/rpmsg_client_sample.c could be 
a good candidate, using extension to construct the "Hello" message...

Acked-by: Arnaud Pouliquen 

Regards,
Arnaud

> ---
>  drivers/rpmsg/rpmsg_core.c | 95 ++
>  include/linux/rpmsg.h  | 13 ++
>  2 files changed, 108 insertions(+)
> 
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index 5e01e8dede6b..9583eb936607 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -439,6 +439,101 @@ static int rpmsg_dev_match(struct device *dev, struct 
> device_driver *drv)
>   return of_driver_match_device(dev, drv);
>  }
>  
> +/**
> + * rpmsg_device_get_name_extension() - get the name extension of a rpmsg 
> device
> + * @rpdev: the rpmsg device to work with
> + * @skip: how many characters in the extension should be skipped over
> + *
> + * With function rpmsg_id_match() allowing for extension of the base driver 
> name
> + * in order to differentiate services, this function returns the extension 
> part
> + * of an rpmsg device name.  As such and with the following rpmsg driver 
> device
> + * id table and rpmsg device names:
> + *
> + * static struct rpmsg_device_id rpmsg_driver_sample_id_table[] = {
> + *  { .name = "rpmsg-client-sample" },
> + *  { },
> + * }
> + *
> + * rpdev1->id.name == "rpmsg-client-sample";
> + * rpdev2->id.name == "rpmsg-client-sample_instance0";
> + *
> + * Calling rpmsg_device_get_name_extension() will yields the following:
> + *
> + * rpmsg_device_get_name_extension(rpdev1, 0) == NULL;
> + * rpmsg_device_get_name_extension(rpdev2, 0) == "_instance0";
> + * rpmsg_device_get_name_extension(rpdev2, 1) == "instance0";
> + *
> + *
> + * Return: The name extension if found, NULL if the name of the RPMSG device
> + *  equals the name of the RPMSG driver and an error if no match is
> + *  found or a validation problem has occurred.
> + */
> +const char *rpmsg_device_get_name_extension(struct rpmsg_device *rpdev,
> + unsigned int skip)
> +{
> + const char *drv_name, *dev_name, *extension;
> + const struct rpmsg_device_id *ids;
> + struct device *dev = >dev;
> + struct rpmsg_driver *rpdrv;
> + bool match = false;
> + unsigned int i;
> +
> + if (!dev->driver)
> + return ERR_PTR(-EINVAL);
> +
> + rpdrv = to_rpmsg_driver(dev->driver);
> +
> + /*
> +  * No point in going further if the device doesn't have name or
> +  * the driver doesn't have a table to work with.
> +  */
> + if (!rpdev->id.name[0] || !rpdrv->id_table)
> + return ERR_PTR(-EINVAL);
> +
> + ids = rpdrv->id_table;
> + dev_name = rpdev->id.name;
> +
> + /*
> +  * See if any name in the driver's table match the beginning
> +  * of the rpmsg device's name.
> +  */
> + for (i = 0; ids[i].name[0]; i++) {
> + drv_name = ids[i].name;
> + if (strncmp(drv_name,
> + dev_name, strlen(drv_name)) == 0) {
> + match = true;
> + break;
> + }
> + }
> +
> + /*
> +  * A match was not found, return an error to differentiate with cases
> +  * where a match was found but the name has no extension (see below).
> +  */
> + if (!match)
> + return ERR_PTR(-ENOENT);
> +
> +  /* No name extension to return if device and driver are the same */
> + if (strlen(dev_name) == strlen(drv_name))
> + return NULL;
> +
> + /*
> +  * Make sure we were not requested to skip past the end
> +  * of the device name.
> +  */
> + if (strlen(drv_name) + skip >= strlen(dev_name))
> + return ERR_PTR(-EINVAL);
> +
> + /*
> +  * Move past the base name published by the driver and
> +  * skip any extra characters if needed.
> +  */
> + extension = dev_name + strlen(drv_name) + skip;
> +
> + return extension;
> +}
> +EXPORT_SYMBOL(rpmsg_device_get_name_extension);
> +
>  static int rpmsg_uevent(struct device *dev, struct kobj_uevent_env *env)
>  {
>   struct rpmsg_device *rpdev = to_rpmsg_device(dev);
> diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
> index 9fe156d1c018..9537b95ad30a 100644
> --- a/include/linux/rpmsg.h
> +++ b/include/linux/rpmsg.h
> @@ -135,6 +135,9 @@ int rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, 
> u32 src, u32 dst,
>  __poll_t rpmsg_poll(struct 

Re: Re:Re: [PATCH v2] drm/arm: fixes pixel clock enabled with wrong format

[Liviu Dudau]

Hi Bernard,

On Fri, May 08, 2020 at 04:47:17PM +0800, Bernard wrote:
> From: "赵军奎" 
> Date: 2020-04-24 19:37:36
> To:  Liviu Dudau 
> Cc:  Brian Starkey ,David Airlie 
> ,Daniel Vetter 
> ,dri-de...@lists.freedesktop.org,linux-kernel@vger.kernel.org,opensource.ker...@vivo.com
> Subject: Re:Re: [PATCH v2] drm/arm: fixes pixel clock enabled with wrong 
> format
> 
> 
> 
> 
> From: Liviu Dudau 
> Date: 2020-04-24 19:09:50
> To:  Bernard Zhao 
> Cc:  Brian Starkey ,David Airlie 
> ,Daniel Vetter 
> ,dri-de...@lists.freedesktop.org,linux-kernel@vger.kernel.org,opensource.ker...@vivo.com
> Subject: Re: [PATCH v2] drm/arm: fixes pixel clock enabled with wrong 
> format>Hi Bernand,
> >
> >On Thu, Apr 23, 2020 at 11:35:51PM -0700, Bernard Zhao wrote:
> >> The pixel clock is still enabled when the format is wrong.
> >> no error branch handle, and also some register is not set
> >> in this case, e.g: HDLCD_REG__SELECT. Maybe we
> >> should disable this clock and throw an warn message when
> >> this happened.
> >> With this change, the code maybe a bit more readable.
> >> 
> >> Signed-off-by: Bernard Zhao 
> >> 
> >> Changes since V1:
> >> *add format error handle, if format is not correct, throw
> >> an warning message and disable this clock.
> >> 
> >> Link for V1:
> >> *https://lore.kernel.org/patchwork/patch/1228501/
> >> ---
> >>  drivers/gpu/drm/arm/hdlcd_crtc.c | 13 +
> >>  1 file changed, 9 insertions(+), 4 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
> >> b/drivers/gpu/drm/arm/hdlcd_crtc.c
> >> index af67fefed38d..f3945dee2b7d 100644
> >> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> >> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> >> @@ -96,7 +96,7 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
> >>}
> >>  
> >>if (WARN_ON(!format))
> >> -  return 0;
> >> +  return -EINVAL;
> >
> >That is the right fix!
> >
> >>  
> >>/* HDLCD uses 'bytes per pixel', zero means 1 byte */
> >>btpp = (format->bits_per_pixel + 7) / 8;
> >> @@ -125,7 +125,7 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
> >>return 0;
> >>  }
> >>  
> >> -static void hdlcd_crtc_mode_set_nofb(struct drm_crtc *crtc)
> >> +static int hdlcd_crtc_mode_set_nofb(struct drm_crtc *crtc)
> >
> >But this is not. We don't need to propagate the error further, just 
> >
> >>  {
> >>struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
> >>struct drm_display_mode *m = >state->adjusted_mode;
> >> @@ -162,9 +162,10 @@ static void hdlcd_crtc_mode_set_nofb(struct drm_crtc 
> >> *crtc)
> >>  
> >>err = hdlcd_set_pxl_fmt(crtc);
> >>if (err)
> >> -  return;
> >
> 
> My previous understanding was that when such an exception occurred, it was 
> caught
> in the atomic_enable interface, and then disable pixel clock. I am not sure 
> is this ok or
> i have to do more register clean operaction.
> 
> >... return here so that we don't call clk_set_rate();
> And for this part, i am a little confused :
> 1 clk_set_rate must be set even if format is wrong?
> 2 The original code logic shows that If format is not correct, we will not 
> set registers 
> HDLCD_REG_PIXEL_FORMAT & HDLCD_REG__SELECT, will this bring in
> any problems?
> 3 if 1 the rate must set & 2 registers above doesn`t matter, then maybe there 
> is no
> need to disable pixel clock.
> Am i misunderstanding

You are right, the pixel format check should not happen inside 
hdlcd_crtc_atomic_enable()
hook, it should be moved into a separate function hdlcd_crtc_atomic_check() and 
that needs
to be hooked into .atomic_check() for hdlcd_crtc_helper_funcs().

If you want to have another go I'll be happy to review and Ack your patch.

Best regards,
Liviu 

> 
> Regards,
> Bernard
> 
> >> +  return err;
> >>  
> >>clk_set_rate(hdlcd->clk, m->crtc_clock * 1000);
> >> +  return 0;
> >>  }
> >>  
> >>  static void hdlcd_crtc_atomic_enable(struct drm_crtc *crtc,
> >> @@ -173,7 +174,11 @@ static void hdlcd_crtc_atomic_enable(struct drm_crtc 
> >> *crtc,
> >>struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
> >>  
> >>clk_prepare_enable(hdlcd->clk);
> >> -  hdlcd_crtc_mode_set_nofb(crtc);
> >> +  if (hdlcd_crtc_mode_set_nofb(crtc)) {
> >> +  DRM_DEBUG_KMS("Invalid format, pixel clock enable failed!\n");
> >> +  clk_disable_unprepare(hdlcd->clk);
> >> +  return;
> >> +  }
> >>hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> >>drm_crtc_vblank_on(crtc);
> >>  }
> >> -- 
> >> 2.26.2
> >> 
> >
> >-- 
> >
> >| I would like to |
> >| fix the world,  |
> >| but they're not |
> >| giving me the   |
> > \ source code!  /
> >  ---
> >¯\_(ツ)_/¯
> 
> 
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

Re: [PATCH v2 12/19] spi: dw: Fix Rx-only DMA transfers

[Andy Shevchenko]

On Fri, May 15, 2020 at 01:47:51PM +0300, Serge Semin wrote:
> Tx-only DMA transfers are working perfectly fine since in this case
> the code just ignores the Rx FIFO overflow interrupts. But it turns
> out the SPI Rx-only transfers are broken since nothing pushing any
> data to the shift registers, so the Rx FIFO is left empty and the
> SPI core subsystems just returns a timeout error. Since DW DMAC
> driver doesn't support something like cyclic write operations of
> a single byte to a device register, the only way to support the
> Rx-only SPI transfers is to fake it by using a dummy Tx-buffer.
> This is what we intend to fix in this commit by setting the
> SPI_CONTROLLER_MUST_TX flag for DMA-capable platform.

I'm fine with this if Mark considers this right thing to do.
So, conditionally
Reviewed-by: Andy Shevchenko 

> 
> Signed-off-by: Serge Semin 
> Cc: Georgy Vlasov 
> Cc: Ramil Zaripov 
> Cc: Alexey Malahov 
> Cc: Thomas Bogendoerfer 
> Cc: Paul Burton 
> Cc: Ralf Baechle 
> Cc: Arnd Bergmann 
> Cc: Allison Randal 
> Cc: Andy Shevchenko 
> Cc: Gareth Williams 
> Cc: Rob Herring 
> Cc: linux-m...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> ---
>  drivers/spi/spi-dw.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
> index 1edb8cdd11ee..31607b40147d 100644
> --- a/drivers/spi/spi-dw.c
> +++ b/drivers/spi/spi-dw.c
> @@ -517,6 +517,7 @@ int dw_spi_add_host(struct device *dev, struct dw_spi 
> *dws)
>   dev_warn(dev, "DMA init failed\n");
>   } else {
>   master->can_dma = dws->dma_ops->can_dma;
> + master->flags |= SPI_CONTROLLER_MUST_TX;
>   }
>   }
>  
> -- 
> 2.25.1
> 

-- 
With Best Regards,
Andy Shevchenko

[PATCH 10/29] c6x: use asm-generic/cacheflush.h

[Christoph Hellwig]

C6x needs almost no cache flushing routines of its own.  Rely on
asm-generic/cacheflush.h for the defaults.

Signed-off-by: Christoph Hellwig 
---
 arch/c6x/include/asm/cacheflush.h | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/arch/c6x/include/asm/cacheflush.h 
b/arch/c6x/include/asm/cacheflush.h
index 4540b40475e6c..10922d528de6d 100644
--- a/arch/c6x/include/asm/cacheflush.h
+++ b/arch/c6x/include/asm/cacheflush.h
@@ -16,21 +16,6 @@
 #include 
 #include 
 
-/*
- * virtually-indexed cache management (our cache is physically indexed)
- */
-#define flush_cache_all()  do {} while (0)
-#define flush_cache_mm(mm) do {} while (0)
-#define flush_cache_dup_mm(mm) do {} while (0)
-#define flush_cache_range(mm, start, end)  do {} while (0)
-#define flush_cache_page(vma, vmaddr, pfn) do {} while (0)
-#define flush_cache_vmap(start, end)   do {} while (0)
-#define flush_cache_vunmap(start, end) do {} while (0)
-#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
-#define flush_dcache_page(page)do {} while (0)
-#define flush_dcache_mmap_lock(mapping)do {} while (0)
-#define flush_dcache_mmap_unlock(mapping)  do {} while (0)
-
 /*
  * physically-indexed cache management
  */
@@ -49,14 +34,12 @@ do {
  \
(unsigned long) page_address(page) + PAGE_SIZE)); \
 } while (0)
 
-
 #define copy_to_user_page(vma, page, vaddr, dst, src, len) \
 do {\
memcpy(dst, src, len);   \
flush_icache_range((unsigned) (dst), (unsigned) (dst) + (len)); \
 } while (0)
 
-#define copy_from_user_page(vma, page, vaddr, dst, src, len) \
-   memcpy(dst, src, len)
+#include 
 
 #endif /* _ASM_C6X_CACHEFLUSH_H */
-- 
2.26.2

[PATCH 09/29] arm64: use asm-generic/cacheflush.h

[Christoph Hellwig]

ARM64 needs almost no cache flushing routines of its own.  Rely on
asm-generic/cacheflush.h for the defaults.

Signed-off-by: Christoph Hellwig 
---
 arch/arm64/include/asm/cacheflush.h | 46 -
 1 file changed, 5 insertions(+), 41 deletions(-)

diff --git a/arch/arm64/include/asm/cacheflush.h 
b/arch/arm64/include/asm/cacheflush.h
index e6cca3d4acf70..03a5a187163ab 100644
--- a/arch/arm64/include/asm/cacheflush.h
+++ b/arch/arm64/include/asm/cacheflush.h
@@ -94,20 +94,7 @@ static inline void flush_icache_range(unsigned long start, 
unsigned long end)
 #endif
kick_all_cpus_sync();
 }
-
-static inline void flush_cache_mm(struct mm_struct *mm)
-{
-}
-
-static inline void flush_cache_page(struct vm_area_struct *vma,
-   unsigned long user_addr, unsigned long pfn)
-{
-}
-
-static inline void flush_cache_range(struct vm_area_struct *vma,
-unsigned long start, unsigned long end)
-{
-}
+#define flush_icache_range flush_icache_range
 
 /*
  * Cache maintenance functions used by the DMA API. No to be used directly.
@@ -123,12 +110,7 @@ extern void __dma_flush_area(const void *, size_t);
  */
 extern void copy_to_user_page(struct vm_area_struct *, struct page *,
unsigned long, void *, const void *, unsigned long);
-#define copy_from_user_page(vma, page, vaddr, dst, src, len) \
-   do {\
-   memcpy(dst, src, len);  \
-   } while (0)
-
-#define flush_cache_dup_mm(mm) flush_cache_mm(mm)
+#define copy_to_user_page copy_to_user_page
 
 /*
  * flush_dcache_page is used when the kernel has written to the page
@@ -154,29 +136,11 @@ static __always_inline void __flush_icache_all(void)
dsb(ish);
 }
 
-#define flush_dcache_mmap_lock(mapping)do { } while (0)
-#define flush_dcache_mmap_unlock(mapping)  do { } while (0)
-
-/*
- * We don't appear to need to do anything here.  In fact, if we did, we'd
- * duplicate cache flushing elsewhere performed by flush_dcache_page().
- */
-#define flush_icache_page(vma,page)do { } while (0)
-
-/*
- * Not required on AArch64 (PIPT or VIPT non-aliasing D-cache).
- */
-static inline void flush_cache_vmap(unsigned long start, unsigned long end)
-{
-}
-
-static inline void flush_cache_vunmap(unsigned long start, unsigned long end)
-{
-}
-
 int set_memory_valid(unsigned long addr, int numpages, int enable);
 
 int set_direct_map_invalid_noflush(struct page *page);
 int set_direct_map_default_noflush(struct page *page);
 
-#endif
+#include 
+
+#endif /* __ASM_CACHEFLUSH_H */
-- 
2.26.2

Re: [PATCH v2 11/19] spi: dw: Initialize paddr in DW SPI MMIO private data

[Andy Shevchenko]

On Fri, May 15, 2020 at 01:47:50PM +0300, Serge Semin wrote:
> This field is used only for the DW SPI DMA code initialization, that's
> why there were no problems with it being uninitialized in Dw SPI MMIO
> driver. Since in a further patch we are going to introduce the DW SPI DMA
> support in the MMIO version of the driver, lets set the field with the
> physical address of the DW SPI controller registers region.

Reviewed-by: Andy Shevchenko 

> 
> Co-developed-by: Georgy Vlasov 
> Signed-off-by: Georgy Vlasov 
> Co-developed-by: Ramil Zaripov 
> Signed-off-by: Ramil Zaripov 
> Signed-off-by: Serge Semin 
> Cc: Alexey Malahov 
> Cc: Thomas Bogendoerfer 
> Cc: Paul Burton 
> Cc: Ralf Baechle 
> Cc: Arnd Bergmann 
> Cc: Allison Randal 
> Cc: Andy Shevchenko 
> Cc: Gareth Williams 
> Cc: Rob Herring 
> Cc: linux-m...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> ---
>  drivers/spi/spi-dw-mmio.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
> index 398f7926cf92..0894b4c09496 100644
> --- a/drivers/spi/spi-dw-mmio.c
> +++ b/drivers/spi/spi-dw-mmio.c
> @@ -184,6 +184,7 @@ static int dw_spi_mmio_probe(struct platform_device *pdev)
>   int (*init_func)(struct platform_device *pdev,
>struct dw_spi_mmio *dwsmmio);
>   struct dw_spi_mmio *dwsmmio;
> + struct resource *mem;
>   struct dw_spi *dws;
>   int ret;
>   int num_cs;
> @@ -196,10 +197,12 @@ static int dw_spi_mmio_probe(struct platform_device 
> *pdev)
>   dws = >dws;
>  
>   /* Get basic io resource and map it */
> - dws->regs = devm_platform_ioremap_resource(pdev, 0);
> + dws->regs = devm_platform_get_and_ioremap_resource(pdev, 0, );
>   if (IS_ERR(dws->regs))
>   return PTR_ERR(dws->regs);
>  
> + dws->paddr = mem->start;
> +
>   dws->irq = platform_get_irq(pdev, 0);
>   if (dws->irq < 0)
>   return dws->irq; /* -ENXIO */
> -- 
> 2.25.1
> 

-- 
With Best Regards,
Andy Shevchenko

[PATCH 15/29] openrisc: use asm-generic/cacheflush.h

[Christoph Hellwig]

OpenRISC needs almost no cache flushing routines of its own.  Rely on
asm-generic/cacheflush.h for the defaults.

Signed-off-by: Christoph Hellwig 
---
 arch/openrisc/include/asm/cacheflush.h | 31 +-
 1 file changed, 6 insertions(+), 25 deletions(-)

diff --git a/arch/openrisc/include/asm/cacheflush.h 
b/arch/openrisc/include/asm/cacheflush.h
index 79d5d7753fe4b..74d1fce4e8839 100644
--- a/arch/openrisc/include/asm/cacheflush.h
+++ b/arch/openrisc/include/asm/cacheflush.h
@@ -62,31 +62,12 @@ static inline void flush_dcache_page(struct page *page)
clear_bit(PG_dc_clean, >flags);
 }
 
-/*
- * Other interfaces are not required since we do not have virtually
- * indexed or tagged caches. So we can use the default here.
- */
-#define flush_cache_all()  do { } while (0)
-#define flush_cache_mm(mm) do { } while (0)
-#define flush_cache_dup_mm(mm) do { } while (0)
-#define flush_cache_range(vma, start, end) do { } while (0)
-#define flush_cache_page(vma, vmaddr, pfn) do { } while (0)
-#define flush_dcache_mmap_lock(mapping)do { } while (0)
-#define flush_dcache_mmap_unlock(mapping)  do { } while (0)
-#define flush_icache_range(start, end) do { } while (0)
-#define flush_icache_page(vma, pg) do { } while (0)
-#define flush_icache_user_range(vma, pg, adr, len) do { } while (0)
-#define flush_cache_vmap(start, end)   do { } while (0)
-#define flush_cache_vunmap(start, end) do { } while (0)
-
-#define copy_to_user_page(vma, page, vaddr, dst, src, len)   \
-   do { \
-   memcpy(dst, src, len);   \
-   if (vma->vm_flags & VM_EXEC) \
-   sync_icache_dcache(page);\
-   } while (0)
+#define flush_icache_user_range(vma, page, addr, len)  \
+do {   \
+   if (vma->vm_flags & VM_EXEC)\
+   sync_icache_dcache(page);   \
+} while (0)
 
-#define copy_from_user_page(vma, page, vaddr, dst, src, len) \
-   memcpy(dst, src, len)
+#include 
 
 #endif /* __ASM_CACHEFLUSH_H */
-- 
2.26.2

Re: [PATCH 1/2] rbtree_latch: quit searching when reaching to maximum depth

[Lai Jiangshan]

On Fri, May 15, 2020 at 9:04 PM Peter Zijlstra  wrote:
>
> On Fri, May 15, 2020 at 12:47:06PM +, Lai Jiangshan wrote:
> > lib/rbtree.c has ensured that there is not possible to
> > inadvertently cause (temporary) loops in the tree structure
> > as seen in program order of the modifier. But loop is still
> > possible to be seen in searcher due to CPU's reordering.
> >
> > for example:
> > modifier  searcher
> >
> > left rotate at parent
> > parent->rb_right is node
> >   search to parent
> >   parent->rb_right is node
> >+->see node->rb_left changed
> > WRITE_ONCE(parent->rb_right, tmp);-+ |  node->rb_left is parennt
> > no smp_wmb(), some arch can| |
> > reorder these two writes   | |  loop long between
> > WRITE_ONCE(node->rb_left, parent);-+-+  parent and node
> >  |
> >  +--->finally see
> >   parent->rb_right
> >
> > The long loop won't stop until the modifer's CPU flushes
> > its writes. Too avoid it, we should limit the searching depth.
>
> Cute, have you actually observed this? Did you have performance issues?

I can only test it on x86 by now, which implies smp_wmb() between
writes. I haven't observed any thing wrong. I'm just imaging
it on some other ARCHs.

I accidentally found this part of code when I searched for
whether there is any attempt again to use rbtree with RCU, and
whether there are the cases besides speculative page fault.

>
> > There are no more than (1< > And the max_depth of a tree is no more than 2*lg(node_count+1),
> > which is no mare than 2*BITS_PER_LONG.
> >
> > So the serarch should stop when diving down up to
> > 2*BITS_PER_LONG depth.
>
> Arguably you can have a larger key space, but I think due to memory
> constraints this limit still isn't wrong. But I do feel you need a
> comment with that.

Sure, I will add some comments about why "2*BITS_PER_LONG" in code.

But how it could be larger key space? there are not more than
(1<

[PATCH 12/29] ia64: use asm-generic/cacheflush.h

[Christoph Hellwig]

IA64 needs almost no cache flushing routines of its own.  Rely on
asm-generic/cacheflush.h for the defaults.

Signed-off-by: Christoph Hellwig 
---
 arch/ia64/include/asm/cacheflush.h | 28 +++-
 1 file changed, 3 insertions(+), 25 deletions(-)

diff --git a/arch/ia64/include/asm/cacheflush.h 
b/arch/ia64/include/asm/cacheflush.h
index 6d3478f8abc89..a8f1c86ac242a 100644
--- a/arch/ia64/include/asm/cacheflush.h
+++ b/arch/ia64/include/asm/cacheflush.h
@@ -12,44 +12,22 @@
 
 #include 
 
-/*
- * Cache flushing routines.  This is the kind of stuff that can be very 
expensive, so try
- * to avoid them whenever possible.
- */
-
-#define flush_cache_all()  do { } while (0)
-#define flush_cache_mm(mm) do { } while (0)
-#define flush_cache_dup_mm(mm) do { } while (0)
-#define flush_cache_range(vma, start, end) do { } while (0)
-#define flush_cache_page(vma, vmaddr, pfn) do { } while (0)
-#define flush_icache_page(vma,page)do { } while (0)
-#define flush_cache_vmap(start, end)   do { } while (0)
-#define flush_cache_vunmap(start, end) do { } while (0)
-
 #define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
 #define flush_dcache_page(page)\
 do {   \
clear_bit(PG_arch_1, &(page)->flags);   \
 } while (0)
 
-#define flush_dcache_mmap_lock(mapping)do { } while (0)
-#define flush_dcache_mmap_unlock(mapping)  do { } while (0)
-
-extern void flush_icache_range (unsigned long start, unsigned long end);
+extern void flush_icache_range(unsigned long start, unsigned long end);
+#define flush_icache_range flush_icache_range
 extern void clflush_cache_range(void *addr, int size);
 
-
 #define flush_icache_user_range(vma, page, user_addr, len) 
\
 do {   
\
unsigned long _addr = (unsigned long) page_address(page) + ((user_addr) 
& ~PAGE_MASK);  \
flush_icache_range(_addr, _addr + (len));   
\
 } while (0)
 
-#define copy_to_user_page(vma, page, vaddr, dst, src, len) \
-do { memcpy(dst, src, len); \
- flush_icache_user_range(vma, page, vaddr, len); \
-} while (0)
-#define copy_from_user_page(vma, page, vaddr, dst, src, len) \
-   memcpy(dst, src, len)
+#include 
 
 #endif /* _ASM_IA64_CACHEFLUSH_H */
-- 
2.26.2

[PATCH 25/29] exec: only build read_code when needed

[Christoph Hellwig]

Only build read_code when binary formats that use it are built into the
kernel.

Signed-off-by: Christoph Hellwig 
---
 fs/exec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/exec.c b/fs/exec.c
index 06b4c550af5d9..a4f766f296f8f 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1027,6 +1027,8 @@ int kernel_read_file_from_fd(int fd, void **buf, loff_t 
*size, loff_t max_size,
 }
 EXPORT_SYMBOL_GPL(kernel_read_file_from_fd);
 
+#if defined(CONFIG_HAVE_AOUT) || defined(CONFIG_BINFMT_FLAT) || \
+defined(CONFIG_BINFMT_ELF_FDPIC)
 ssize_t read_code(struct file *file, unsigned long addr, loff_t pos, size_t 
len)
 {
ssize_t res = vfs_read(file, (void __user *)addr, len, );
@@ -1035,6 +1037,7 @@ ssize_t read_code(struct file *file, unsigned long addr, 
loff_t pos, size_t len)
return res;
 }
 EXPORT_SYMBOL(read_code);
+#endif
 
 /*
  * Maps the mm_struct mm into the current task struct.
-- 
2.26.2

[PATCH 14/29] m68knommu: use asm-generic/cacheflush.h

[Christoph Hellwig]

m68knommu needs almost no cache flushing routines of its own.  Rely on
asm-generic/cacheflush.h for the defaults.

Signed-off-by: Christoph Hellwig 
Acked-by: Greg Ungerer 
---
 arch/m68k/include/asm/cacheflush_no.h | 19 ++-
 1 file changed, 2 insertions(+), 17 deletions(-)

diff --git a/arch/m68k/include/asm/cacheflush_no.h 
b/arch/m68k/include/asm/cacheflush_no.h
index 11e9a9dcbfb24..2731f07e7be8c 100644
--- a/arch/m68k/include/asm/cacheflush_no.h
+++ b/arch/m68k/include/asm/cacheflush_no.h
@@ -9,25 +9,8 @@
 #include 
 
 #define flush_cache_all()  __flush_cache_all()
-#define flush_cache_mm(mm) do { } while (0)
-#define flush_cache_dup_mm(mm) do { } while (0)
-#define flush_cache_range(vma, start, end) do { } while (0)
-#define flush_cache_page(vma, vmaddr)  do { } while (0)
 #define flush_dcache_range(start, len) __flush_dcache_all()
-#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
-#define flush_dcache_page(page)do { } while (0)
-#define flush_dcache_mmap_lock(mapping)do { } while (0)
-#define flush_dcache_mmap_unlock(mapping)  do { } while (0)
 #define flush_icache_range(start, len) __flush_icache_all()
-#define flush_icache_page(vma,pg)  do { } while (0)
-#define flush_icache_user_range(vma,pg,adr,len)do { } while (0)
-#define flush_cache_vmap(start, end)   do { } while (0)
-#define flush_cache_vunmap(start, end) do { } while (0)
-
-#define copy_to_user_page(vma, page, vaddr, dst, src, len) \
-   memcpy(dst, src, len)
-#define copy_from_user_page(vma, page, vaddr, dst, src, len) \
-   memcpy(dst, src, len)
 
 void mcf_cache_push(void);
 
@@ -98,4 +81,6 @@ static inline void cache_clear(unsigned long paddr, int len)
__clear_cache_all();
 }
 
+#include 
+
 #endif /* _M68KNOMMU_CACHEFLUSH_H */
-- 
2.26.2

[PATCH 24/29] m68k: implement flush_icache_user_range

[Christoph Hellwig]

Rename the current flush_icache_range to flush_icache_user_range as
per commit ae92ef8a4424 ("PATCH] flush icache in correct context") there
seems to be an assumption that it operates on user addresses.  Add a
flush_icache_range around it that for now is a no-op.

Signed-off-by: Christoph Hellwig 
Acked-by: Geert Uytterhoeven 
---
 arch/m68k/include/asm/cacheflush_mm.h | 2 ++
 arch/m68k/mm/cache.c  | 7 ++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/m68k/include/asm/cacheflush_mm.h 
b/arch/m68k/include/asm/cacheflush_mm.h
index 95376bf84faa5..1ac55e7b47f01 100644
--- a/arch/m68k/include/asm/cacheflush_mm.h
+++ b/arch/m68k/include/asm/cacheflush_mm.h
@@ -257,6 +257,8 @@ static inline void __flush_page_to_ram(void *vaddr)
 extern void flush_icache_user_page(struct vm_area_struct *vma, struct page 
*page,
unsigned long addr, int len);
 extern void flush_icache_range(unsigned long address, unsigned long endaddr);
+extern void flush_icache_user_range(unsigned long address,
+   unsigned long endaddr);
 
 static inline void copy_to_user_page(struct vm_area_struct *vma,
 struct page *page, unsigned long vaddr,
diff --git a/arch/m68k/mm/cache.c b/arch/m68k/mm/cache.c
index 99057cd5ff7f1..7915be3a09712 100644
--- a/arch/m68k/mm/cache.c
+++ b/arch/m68k/mm/cache.c
@@ -73,7 +73,7 @@ static unsigned long virt_to_phys_slow(unsigned long vaddr)
 
 /* Push n pages at kernel virtual address and clear the icache */
 /* RZ: use cpush %bc instead of cpush %dc, cinv %ic */
-void flush_icache_range(unsigned long address, unsigned long endaddr)
+void flush_icache_user_range(unsigned long address, unsigned long endaddr)
 {
if (CPU_IS_COLDFIRE) {
unsigned long start, end;
@@ -104,6 +104,11 @@ void flush_icache_range(unsigned long address, unsigned 
long endaddr)
  : "di" (FLUSH_I));
}
 }
+
+void flush_icache_range(unsigned long address, unsigned long endaddr)
+{
+   flush_icache_user_range(address, endaddr);
+}
 EXPORT_SYMBOL(flush_icache_range);
 
 void flush_icache_user_page(struct vm_area_struct *vma, struct page *page,
-- 
2.26.2

[PATCH 11/29] hexagon: use asm-generic/cacheflush.h

[Christoph Hellwig]

Hexagon needs almost no cache flushing routines of its own.  Rely on
asm-generic/cacheflush.h for the defaults.

Signed-off-by: Christoph Hellwig 
---
 arch/hexagon/include/asm/cacheflush.h | 19 +--
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/arch/hexagon/include/asm/cacheflush.h 
b/arch/hexagon/include/asm/cacheflush.h
index fb447de45d54c..6eff0730e6efd 100644
--- a/arch/hexagon/include/asm/cacheflush.h
+++ b/arch/hexagon/include/asm/cacheflush.h
@@ -25,29 +25,17 @@
 #define LINESIZE   32
 #define LINEBITS   5
 
-#define flush_cache_all()  do { } while (0)
-#define flush_cache_mm(mm) do { } while (0)
-#define flush_cache_dup_mm(mm) do { } while (0)
-#define flush_cache_range(vma, start, end) do { } while (0)
-#define flush_cache_page(vma, vmaddr, pfn) do { } while (0)
-#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
-#define flush_dcache_page(page)do { } while (0)
-#define flush_dcache_mmap_lock(mapping)do { } while (0)
-#define flush_dcache_mmap_unlock(mapping)  do { } while (0)
-#define flush_icache_page(vma, pg) do { } while (0)
-#define flush_icache_user_range(vma, pg, adr, len) do { } while (0)
-#define flush_cache_vmap(start, end)   do { } while (0)
-#define flush_cache_vunmap(start, end) do { } while (0)
-
 /*
  * Flush Dcache range through current map.
  */
 extern void flush_dcache_range(unsigned long start, unsigned long end);
+#define flush_dcache_range flush_dcache_range
 
 /*
  * Flush Icache range through current map.
  */
 extern void flush_icache_range(unsigned long start, unsigned long end);
+#define flush_icache_range flush_icache_range
 
 /*
  * Memory-management related flushes are there to ensure in non-physically
@@ -78,6 +66,7 @@ static inline void update_mmu_cache(struct vm_area_struct 
*vma,
 
 void copy_to_user_page(struct vm_area_struct *vma, struct page *page,
   unsigned long vaddr, void *dst, void *src, int len);
+#define copy_to_user_page copy_to_user_page
 
 #define copy_from_user_page(vma, page, vaddr, dst, src, len) \
memcpy(dst, src, len)
@@ -85,4 +74,6 @@ void copy_to_user_page(struct vm_area_struct *vma, struct 
page *page,
 extern void hexagon_inv_dcache_range(unsigned long start, unsigned long end);
 extern void hexagon_clean_dcache_range(unsigned long start, unsigned long end);
 
+#include 
+
 #endif
-- 
2.26.2

Re: [PATCH v2 10/19] spi: dw: Use DMA max burst to set the request thresholds

[Andy Shevchenko]

On Fri, May 15, 2020 at 01:47:49PM +0300, Serge Semin wrote:
> Each channel of DMA controller may have a limited length of burst
> transaction (number of IO operations performed at ones in a single
> DMA client request). This parameter can be used to setup the most
> optimal DMA Tx/Rx data level values. In order to avoid the Tx buffer
> overrun we can set the DMA Tx level to be of FIFO depth minus the
> maximum burst transactions length. To prevent the Rx buffer underflow
> the DMA Rx level should be set to the maximum burst transactions length.
> This commit setups the DMA channels and the DW SPI DMA Tx/Rx levels
> in accordance with these rules.

It's good one, but see my comments.


I think this patch should go before previous one.
(and without changes regarding FIFO length)

> +static void mid_spi_maxburst_init(struct dw_spi *dws)
> +{
> + struct dma_slave_caps caps;
> + u32 max_burst, def_burst;
> + int ret;
> +
> + def_burst = dws->fifo_len / 2;
> +
> + ret = dma_get_slave_caps(dws->rxchan, );
> + if (!ret && caps.max_burst)
> + max_burst = caps.max_burst;
> + else
> + max_burst = RX_BURST_LEVEL;
> +

> + dws->rxburst = (def_burst > max_burst) ? max_burst : def_burst;

min() ?

> +
> + ret = dma_get_slave_caps(dws->txchan, );
> + if (!ret && caps.max_burst)
> + max_burst = caps.max_burst;
> + else
> + max_burst = TX_BURST_LEVEL;
> +

> + dws->txburst = (def_burst > max_burst) ? max_burst : def_burst;

Ditto.

> +}
> +
>  static int mid_spi_dma_init_mfld(struct device *dev, struct dw_spi *dws)
>  {
>   struct dw_dma_slave slave = {0};
> @@ -67,6 +92,8 @@ static int mid_spi_dma_init_mfld(struct device *dev, struct 
> dw_spi *dws)
>   dws->master->dma_rx = dws->rxchan;
>   dws->master->dma_tx = dws->txchan;
>  
> + mid_spi_maxburst_init(dws);
> +
>   return 0;
>  
>  free_rxchan:
> @@ -92,6 +119,8 @@ static int mid_spi_dma_init_generic(struct device *dev, 
> struct dw_spi *dws)
>   dws->master->dma_rx = dws->rxchan;
>   dws->master->dma_tx = dws->txchan;
>  
> + mid_spi_maxburst_init(dws);
> +
>   return 0;
>  }
>  
> @@ -195,7 +224,7 @@ static struct dma_async_tx_descriptor 
> *dw_spi_dma_prepare_tx(struct dw_spi *dws,
>   memset(, 0, sizeof(txconf));
>   txconf.direction = DMA_MEM_TO_DEV;
>   txconf.dst_addr = dws->dma_addr;
> - txconf.dst_maxburst = TX_BURST_LEVEL;
> + txconf.dst_maxburst = dws->txburst;
>   txconf.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
>   txconf.dst_addr_width = convert_dma_width(dws->n_bytes);
>   txconf.device_fc = false;
> @@ -268,7 +297,7 @@ static struct dma_async_tx_descriptor 
> *dw_spi_dma_prepare_rx(struct dw_spi *dws,
>   memset(, 0, sizeof(rxconf));
>   rxconf.direction = DMA_DEV_TO_MEM;
>   rxconf.src_addr = dws->dma_addr;
> - rxconf.src_maxburst = RX_BURST_LEVEL;
> + rxconf.src_maxburst = dws->rxburst;
>   rxconf.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
>   rxconf.src_addr_width = convert_dma_width(dws->n_bytes);
>   rxconf.device_fc = false;
> @@ -293,8 +322,8 @@ static int mid_spi_dma_setup(struct dw_spi *dws, struct 
> spi_transfer *xfer)
>  {
>   u16 imr = 0, dma_ctrl = 0;
>  
> - dw_writel(dws, DW_SPI_DMARDLR, RX_BURST_LEVEL - 1);
> - dw_writel(dws, DW_SPI_DMATDLR, dws->fifo_len - TX_BURST_LEVEL);
> + dw_writel(dws, DW_SPI_DMARDLR, dws->rxburst - 1);
> + dw_writel(dws, DW_SPI_DMATDLR, dws->fifo_len - dws->txburst);
>  
>   if (xfer->tx_buf) {
>   dma_ctrl |= SPI_DMA_TDMAE;

...

>   /* DMA info */
>   struct dma_chan *txchan;
> + u32 txburst;
>   struct dma_chan *rxchan;
> + u32 rxburst;

Leave u32 together, it may be optimal on 64-bit architectures where ABIs 
require padding.

-- 
With Best Regards,
Andy Shevchenko

[PATCH 27/29] binfmt_flat: use flush_icache_user_range

[Christoph Hellwig]

load_flat_file works on user addresses.

Signed-off-by: Christoph Hellwig 
Acked-by: Greg Ungerer 
---
 fs/binfmt_flat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index 831a2b25ba79f..6f0aca5379da2 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -854,7 +854,7 @@ static int load_flat_file(struct linux_binprm *bprm,
 #endif /* CONFIG_BINFMT_FLAT_OLD */
}
 
-   flush_icache_range(start_code, end_code);
+   flush_icache_user_range(start_code, end_code);
 
/* zero the BSS,  BRK and stack areas */
if (clear_user((void __user *)(datapos + data_len), bss_len +
-- 
2.26.2

[PATCH 22/29] xtensa: implement flush_icache_user_range

[Christoph Hellwig]

The Xtensa implementation of flush_icache_range seems to be able to
cope with user addresses.  Just define flush_icache_user_range to
flush_icache_range.

Signed-off-by: Christoph Hellwig 
---
 arch/xtensa/include/asm/cacheflush.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/xtensa/include/asm/cacheflush.h 
b/arch/xtensa/include/asm/cacheflush.h
index a0d50be5a8cb1..460e666ad0761 100644
--- a/arch/xtensa/include/asm/cacheflush.h
+++ b/arch/xtensa/include/asm/cacheflush.h
@@ -107,6 +107,8 @@ void flush_cache_page(struct vm_area_struct*,
 #define flush_cache_page  local_flush_cache_page
 #endif
 
+#define flush_icache_user_range flush_icache_range
+
 #define local_flush_cache_all()
\
do {\
__flush_invalidate_dcache_all();\
-- 
2.26.2

[PATCH 19/29] mm: rename flush_icache_user_range to flush_icache_user_page

[Christoph Hellwig]

The function currently known as flush_icache_user_range only operates
on a single page.  Rename it to flush_icache_user_page as we'll need
the name flush_icache_user_range for something else soon.

Signed-off-by: Christoph Hellwig 
Acked-by: Geert Uytterhoeven 
---
 arch/alpha/include/asm/cacheflush.h| 10 +-
 arch/alpha/kernel/smp.c|  2 +-
 arch/ia64/include/asm/cacheflush.h |  2 +-
 arch/m68k/include/asm/cacheflush_mm.h  |  4 ++--
 arch/m68k/mm/cache.c   |  2 +-
 arch/nds32/include/asm/cacheflush.h|  4 ++--
 arch/nds32/mm/cacheflush.c |  2 +-
 arch/openrisc/include/asm/cacheflush.h |  2 +-
 arch/powerpc/include/asm/cacheflush.h  |  4 ++--
 arch/powerpc/mm/mem.c  |  2 +-
 arch/riscv/include/asm/cacheflush.h|  3 ++-
 include/asm-generic/cacheflush.h   |  6 +++---
 kernel/events/uprobes.c|  2 +-
 13 files changed, 23 insertions(+), 22 deletions(-)

diff --git a/arch/alpha/include/asm/cacheflush.h 
b/arch/alpha/include/asm/cacheflush.h
index 636d7ca0d05f6..9945ff483eaf7 100644
--- a/arch/alpha/include/asm/cacheflush.h
+++ b/arch/alpha/include/asm/cacheflush.h
@@ -35,7 +35,7 @@ extern void smp_imb(void);
 
 extern void __load_new_mm_context(struct mm_struct *);
 static inline void
-flush_icache_user_range(struct vm_area_struct *vma, struct page *page,
+flush_icache_user_page(struct vm_area_struct *vma, struct page *page,
unsigned long addr, int len)
 {
if (vma->vm_flags & VM_EXEC) {
@@ -46,16 +46,16 @@ flush_icache_user_range(struct vm_area_struct *vma, struct 
page *page,
mm->context[smp_processor_id()] = 0;
}
 }
-#define flush_icache_user_range flush_icache_user_range
+#define flush_icache_user_page flush_icache_user_page
 #else /* CONFIG_SMP */
-extern void flush_icache_user_range(struct vm_area_struct *vma,
+extern void flush_icache_user_page(struct vm_area_struct *vma,
struct page *page, unsigned long addr, int len);
-#define flush_icache_user_range flush_icache_user_range
+#define flush_icache_user_page flush_icache_user_page
 #endif /* CONFIG_SMP */
 
 /* This is used only in __do_fault and do_swap_page.  */
 #define flush_icache_page(vma, page) \
-   flush_icache_user_range((vma), (page), 0, 0)
+   flush_icache_user_page((vma), (page), 0, 0)
 
 #include 
 
diff --git a/arch/alpha/kernel/smp.c b/arch/alpha/kernel/smp.c
index 5f90df30be20a..52995bf413fea 100644
--- a/arch/alpha/kernel/smp.c
+++ b/arch/alpha/kernel/smp.c
@@ -740,7 +740,7 @@ ipi_flush_icache_page(void *x)
 }
 
 void
-flush_icache_user_range(struct vm_area_struct *vma, struct page *page,
+flush_icache_user_page(struct vm_area_struct *vma, struct page *page,
unsigned long addr, int len)
 {
struct mm_struct *mm = vma->vm_mm;
diff --git a/arch/ia64/include/asm/cacheflush.h 
b/arch/ia64/include/asm/cacheflush.h
index a8f1c86ac242a..708c0fa5d975e 100644
--- a/arch/ia64/include/asm/cacheflush.h
+++ b/arch/ia64/include/asm/cacheflush.h
@@ -22,7 +22,7 @@ extern void flush_icache_range(unsigned long start, unsigned 
long end);
 #define flush_icache_range flush_icache_range
 extern void clflush_cache_range(void *addr, int size);
 
-#define flush_icache_user_range(vma, page, user_addr, len) 
\
+#define flush_icache_user_page(vma, page, user_addr, len)  
\
 do {   
\
unsigned long _addr = (unsigned long) page_address(page) + ((user_addr) 
& ~PAGE_MASK);  \
flush_icache_range(_addr, _addr + (len));   
\
diff --git a/arch/m68k/include/asm/cacheflush_mm.h 
b/arch/m68k/include/asm/cacheflush_mm.h
index 1e2544ecaf88c..95376bf84faa5 100644
--- a/arch/m68k/include/asm/cacheflush_mm.h
+++ b/arch/m68k/include/asm/cacheflush_mm.h
@@ -254,7 +254,7 @@ static inline void __flush_page_to_ram(void *vaddr)
 #define flush_dcache_mmap_unlock(mapping)  do { } while (0)
 #define flush_icache_page(vma, page)   __flush_page_to_ram(page_address(page))
 
-extern void flush_icache_user_range(struct vm_area_struct *vma, struct page 
*page,
+extern void flush_icache_user_page(struct vm_area_struct *vma, struct page 
*page,
unsigned long addr, int len);
 extern void flush_icache_range(unsigned long address, unsigned long endaddr);
 
@@ -264,7 +264,7 @@ static inline void copy_to_user_page(struct vm_area_struct 
*vma,
 {
flush_cache_page(vma, vaddr, page_to_pfn(page));
memcpy(dst, src, len);
-   flush_icache_user_range(vma, page, vaddr, len);
+   flush_icache_user_page(vma, page, vaddr, len);
 }
 static inline void copy_from_user_page(struct vm_area_struct *vma,
   struct page *page, unsigned long vaddr,
diff --git a/arch/m68k/mm/cache.c 

[PATCH 29/29] module: move the set_fs hack for flush_icache_range to m68k

[Christoph Hellwig]

flush_icache_range generally operates on kernel addresses, but for some
reason m68k needed a set_fs override.  Move that into the m68k code
insted of keeping it in the module loader.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Geert Uytterhoeven 
Acked-by: Geert Uytterhoeven 
---
 arch/m68k/mm/cache.c | 4 
 kernel/module.c  | 8 
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/m68k/mm/cache.c b/arch/m68k/mm/cache.c
index 7915be3a09712..5ecb3310e8745 100644
--- a/arch/m68k/mm/cache.c
+++ b/arch/m68k/mm/cache.c
@@ -107,7 +107,11 @@ void flush_icache_user_range(unsigned long address, 
unsigned long endaddr)
 
 void flush_icache_range(unsigned long address, unsigned long endaddr)
 {
+   mm_segment_t old_fs = get_fs();
+
+   set_fs(KERNEL_DS);
flush_icache_user_range(address, endaddr);
+   set_fs(old_fs);
 }
 EXPORT_SYMBOL(flush_icache_range);
 
diff --git a/kernel/module.c b/kernel/module.c
index 646f1e2330d2b..b1673ed49594f 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3312,12 +3312,6 @@ static int check_module_license_and_versions(struct 
module *mod)
 
 static void flush_module_icache(const struct module *mod)
 {
-   mm_segment_t old_fs;
-
-   /* flush the icache in correct context */
-   old_fs = get_fs();
-   set_fs(KERNEL_DS);
-
/*
 * Flush the instruction cache, since we've played with text.
 * Do it before processing of module parameters, so the module
@@ -3329,8 +3323,6 @@ static void flush_module_icache(const struct module *mod)
   + mod->init_layout.size);
flush_icache_range((unsigned long)mod->core_layout.base,
   (unsigned long)mod->core_layout.base + 
mod->core_layout.size);
-
-   set_fs(old_fs);
 }
 
 int __weak module_frob_arch_sections(Elf_Ehdr *hdr,
-- 
2.26.2

[PATCH 26/29] exec: use flush_icache_user_range in read_code

[Christoph Hellwig]

read_code operates on user addresses.

Signed-off-by: Christoph Hellwig 
---
 fs/exec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/exec.c b/fs/exec.c
index a4f766f296f8f..c541867316a63 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1033,7 +1033,7 @@ ssize_t read_code(struct file *file, unsigned long addr, 
loff_t pos, size_t len)
 {
ssize_t res = vfs_read(file, (void __user *)addr, len, );
if (res > 0)
-   flush_icache_range(addr, addr + len);
+   flush_icache_user_range(addr, addr + len);
return res;
 }
 EXPORT_SYMBOL(read_code);
-- 
2.26.2

[PATCH 23/29] arm: rename flush_cache_user_range to flush_icache_user_range

[Christoph Hellwig]

flush_icache_user_range will be the name for a generic primitive.
Move the arm name so that arm already has an implementation.

Signed-off-by: Christoph Hellwig 
---
 arch/arm/include/asm/cacheflush.h | 4 ++--
 arch/arm/kernel/traps.c   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/cacheflush.h 
b/arch/arm/include/asm/cacheflush.h
index c78e14fcfb5df..2e24e765e6d3a 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -258,11 +258,11 @@ extern void flush_cache_page(struct vm_area_struct *vma, 
unsigned long user_addr
 #define flush_cache_dup_mm(mm) flush_cache_mm(mm)
 
 /*
- * flush_cache_user_range is used when we want to ensure that the
+ * flush_icache_user_range is used when we want to ensure that the
  * Harvard caches are synchronised for the user space address range.
  * This is used for the ARM private sys_cacheflush system call.
  */
-#define flush_cache_user_range(s,e)__cpuc_coherent_user_range(s,e)
+#define flush_icache_user_range(s,e)   __cpuc_coherent_user_range(s,e)
 
 /*
  * Perform necessary cache operations to ensure that data previously
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 1e70e7227f0ff..316a7687f8133 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -566,7 +566,7 @@ __do_cache_op(unsigned long start, unsigned long end)
if (fatal_signal_pending(current))
return 0;
 
-   ret = flush_cache_user_range(start, start + chunk);
+   ret = flush_icache_user_range(start, start + chunk);
if (ret)
return ret;
 
-- 
2.26.2

[PATCH 28/29] nommu: use flush_icache_user_range in brk and mmap

[Christoph Hellwig]

These obviously operate on user addresses.

Signed-off-by: Christoph Hellwig 
---
 mm/nommu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/nommu.c b/mm/nommu.c
index 318df4e236c99..aed7acaed2383 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -443,7 +443,7 @@ SYSCALL_DEFINE1(brk, unsigned long, brk)
/*
 * Ok, looks good - let it rip.
 */
-   flush_icache_range(mm->brk, brk);
+   flush_icache_user_range(mm->brk, brk);
return mm->brk = brk;
 }
 
@@ -1287,7 +1287,7 @@ unsigned long do_mmap(struct file *file,
/* we flush the region from the icache only when the first executable
 * mapping of it is made  */
if (vma->vm_flags & VM_EXEC && !region->vm_icache_flushed) {
-   flush_icache_range(region->vm_start, region->vm_end);
+   flush_icache_user_range(region->vm_start, region->vm_end);
region->vm_icache_flushed = true;
}
 
-- 
2.26.2

[PATCH 18/29] arm,sparc,unicore32: remove flush_icache_user_range

[Christoph Hellwig]

flush_icache_user_range is only used by , so
remove it from the architectures that implement it, but don't use
.

Signed-off-by: Christoph Hellwig 
---
 arch/arm/include/asm/cacheflush.h   | 3 ---
 arch/sparc/include/asm/cacheflush_32.h  | 2 --
 arch/sparc/include/asm/cacheflush_64.h  | 1 -
 arch/unicore32/include/asm/cacheflush.h | 3 ---
 4 files changed, 9 deletions(-)

diff --git a/arch/arm/include/asm/cacheflush.h 
b/arch/arm/include/asm/cacheflush.h
index 7114b9aa46b87..c78e14fcfb5df 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -318,9 +318,6 @@ extern void flush_kernel_dcache_page(struct page *);
 #define flush_dcache_mmap_lock(mapping)
xa_lock_irq(>i_pages)
 #define flush_dcache_mmap_unlock(mapping)  xa_unlock_irq(>i_pages)
 
-#define flush_icache_user_range(vma,page,addr,len) \
-   flush_dcache_page(page)
-
 /*
  * We don't appear to need to do anything here.  In fact, if we did, we'd
  * duplicate cache flushing elsewhere performed by flush_dcache_page().
diff --git a/arch/sparc/include/asm/cacheflush_32.h 
b/arch/sparc/include/asm/cacheflush_32.h
index fb66094a2c30c..41c6d734a4741 100644
--- a/arch/sparc/include/asm/cacheflush_32.h
+++ b/arch/sparc/include/asm/cacheflush_32.h
@@ -17,8 +17,6 @@
 #define flush_icache_range(start, end) do { } while (0)
 #define flush_icache_page(vma, pg) do { } while (0)
 
-#define flush_icache_user_range(vma,pg,adr,len)do { } while (0)
-
 #define copy_to_user_page(vma, page, vaddr, dst, src, len) \
do {\
flush_cache_page(vma, vaddr, page_to_pfn(page));\
diff --git a/arch/sparc/include/asm/cacheflush_64.h 
b/arch/sparc/include/asm/cacheflush_64.h
index e7517434d1fa6..b9341836597ec 100644
--- a/arch/sparc/include/asm/cacheflush_64.h
+++ b/arch/sparc/include/asm/cacheflush_64.h
@@ -49,7 +49,6 @@ void __flush_dcache_range(unsigned long start, unsigned long 
end);
 void flush_dcache_page(struct page *page);
 
 #define flush_icache_page(vma, pg) do { } while(0)
-#define flush_icache_user_range(vma,pg,adr,len)do { } while (0)
 
 void flush_ptrace_access(struct vm_area_struct *, struct page *,
 unsigned long uaddr, void *kaddr,
diff --git a/arch/unicore32/include/asm/cacheflush.h 
b/arch/unicore32/include/asm/cacheflush.h
index 9393ca4047e93..ff0be92ebc320 100644
--- a/arch/unicore32/include/asm/cacheflush.h
+++ b/arch/unicore32/include/asm/cacheflush.h
@@ -162,9 +162,6 @@ extern void flush_dcache_page(struct page *);
 #define flush_dcache_mmap_lock(mapping)do { } while (0)
 #define flush_dcache_mmap_unlock(mapping)  do { } while (0)
 
-#define flush_icache_user_range(vma, page, addr, len)  \
-   flush_dcache_page(page)
-
 /*
  * We don't appear to need to do anything here.  In fact, if we did, we'd
  * duplicate cache flushing elsewhere performed by flush_dcache_page().
-- 
2.26.2

[PATCH 05/29] asm-generic: fix the inclusion guards for cacheflush.h

[Christoph Hellwig]

cacheflush.h uses a somewhat to generic include guard name that clashes
with various arch files.  Use a more specific one.

Signed-off-by: Christoph Hellwig 
---
 include/asm-generic/cacheflush.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/asm-generic/cacheflush.h b/include/asm-generic/cacheflush.h
index cac7404b2bdd2..906277492ec59 100644
--- a/include/asm-generic/cacheflush.h
+++ b/include/asm-generic/cacheflush.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __ASM_CACHEFLUSH_H
-#define __ASM_CACHEFLUSH_H
+#ifndef _ASM_GENERIC_CACHEFLUSH_H
+#define _ASM_GENERIC_CACHEFLUSH_H
 
 /* Keep includes the same across arches.  */
 #include 
@@ -109,4 +109,4 @@ static inline void flush_cache_vunmap(unsigned long start, 
unsigned long end)
memcpy(dst, src, len)
 #endif
 
-#endif /* __ASM_CACHEFLUSH_H */
+#endif /* _ASM_GENERIC_CACHEFLUSH_H */
-- 
2.26.2

Re: [PATCH 2/2] perf test: Improve pmu event metric testing

[John Garry]

On 15/05/2020 12:48, Jiri Olsa wrote:

On Fri, May 15, 2020 at 10:09:10AM +0100, John Garry wrote:

On 15/05/2020 00:02, Ian Rogers wrote:

On Thu, May 14, 2020 at 2:00 AM John Garry  wrote:


On 13/05/2020 17:10, Ian Rogers wrote:

Out of interest, if we could move the validation of metrics to jevents,
how much functionality would we still have here?

If we add checking to jevents then the MetricExpr would be known to be
valid, however, the events (aka ids) within the expression could be
invalid.


So I think that has some value. I mean, just to detect syntax errors,
like those remedied in "perf metrics: fix parse errors in power8 metrics".


I'm not sure we could realistically check the events at
jevents (build) time as there is no guarantee that the machine we run
on is the same as the one we compile on.


But we could at least check that there are event aliases for that CPU,
right? (by examining the JSONs for that cpu). If the event alias does
not actually match on the target CPU, then that can't be helped.


Agreed, I think there will be some cases where something more can be
done. Jiri has proposed fake pmus as well:
https://www.spinics.net/lists/linux-perf-users/msg11760.html
I don't know how much sense it makes trying to get this in jevents, as
long as 'perf test' is run.


At a glance, that does not look like something we would want in jevents. But
rather the metric expr parsing error detection and alias checking.

About jirka's patch:

--- a/tools/perf/tests/pmu-events.c
+++ b/tools/perf/tests/pmu-events.c
@@ -485,6 +485,102 @@ static int test_parsing(void)
return ret == 0 ? TEST_OK : TEST_SKIP;
  }

+
+static struct test_metric metrics[] = {
+   { .metric = "imx8_ddr0@read\\-cycles@ * 4 * 4", },
+   { .metric = 
"imx8_ddr0@axid\\-read\\,axi_mask\\=0x\\,axi_id\\=0x@
* 4", },
+   { .metric = "(cstate_pkg@c2\\-residency@ / msr@tsc@) * 100", },
+   { .metric = "(imx8_ddr0@read\\-cycles@ + imx8_ddr0@write\\-cycles@)", },
+};

Maybe we could add these to pmu-events/arch/test/test_cpu/metric.json, and
get at them that way.


that test sets the 'fake pmu' stuff.. could we do that in your test?


I'm not sure about a test comparable to the alias match testing, but at 
least it should be possible to verify that jevents generates as-expected 
metric events (as done in __test_pmu_event_table() for regular events).


Cheers,
John

[PATCH 07/29] asm-generic: improve the flush_dcache_page stub

[Christoph Hellwig]

There is a magic ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE cpp symbol that
guards non-stub availability of flush_dcache_pagge.  Use that to
check if flush_dcache_pagg is implemented.

Signed-off-by: Christoph Hellwig 
---
 include/asm-generic/cacheflush.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/asm-generic/cacheflush.h b/include/asm-generic/cacheflush.h
index bf9bb83e9fc8d..4d4ef6516 100644
--- a/include/asm-generic/cacheflush.h
+++ b/include/asm-generic/cacheflush.h
@@ -2,8 +2,6 @@
 #ifndef _ASM_GENERIC_CACHEFLUSH_H
 #define _ASM_GENERIC_CACHEFLUSH_H
 
-#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
-
 /*
  * The cache doesn't need to be flushed when TLB entries change when
  * the cache is mapped to physical memory, not virtual memory
@@ -42,12 +40,14 @@ static inline void flush_cache_page(struct vm_area_struct 
*vma,
 }
 #endif
 
-#ifndef flush_dcache_page
+#ifndef ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE
 static inline void flush_dcache_page(struct page *page)
 {
 }
+#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
 #endif
 
+
 #ifndef flush_dcache_mmap_lock
 static inline void flush_dcache_mmap_lock(struct address_space *mapping)
 {
-- 
2.26.2

[PATCH 21/29] sh: implement flush_icache_user_range

[Christoph Hellwig]

The SuperH implementation of flush_icache_range seems to be able to
cope with user addresses.  Just define flush_icache_user_range to
flush_icache_range.

Signed-off-by: Christoph Hellwig 
---
 arch/sh/include/asm/cacheflush.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/sh/include/asm/cacheflush.h b/arch/sh/include/asm/cacheflush.h
index b932e42ef0284..fe7400079b97b 100644
--- a/arch/sh/include/asm/cacheflush.h
+++ b/arch/sh/include/asm/cacheflush.h
@@ -46,6 +46,7 @@ extern void flush_cache_range(struct vm_area_struct *vma,
 #define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
 extern void flush_dcache_page(struct page *page);
 extern void flush_icache_range(unsigned long start, unsigned long end);
+#define flush_icache_user_range flush_icache_range
 extern void flush_icache_page(struct vm_area_struct *vma,
 struct page *page);
 extern void flush_cache_sigtramp(unsigned long address);
-- 
2.26.2

[PATCH 16/29] powerpc: use asm-generic/cacheflush.h

[Christoph Hellwig]

Power needs almost no cache flushing routines of its own.  Rely on
asm-generic/cacheflush.h for the defaults.

Also remove the pointless __KERNEL__ ifdef while we're at it.

Signed-off-by: Christoph Hellwig 
---
 arch/powerpc/include/asm/cacheflush.h | 42 +++
 1 file changed, 10 insertions(+), 32 deletions(-)

diff --git a/arch/powerpc/include/asm/cacheflush.h 
b/arch/powerpc/include/asm/cacheflush.h
index e92191b390f31..e682c8e10e903 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -4,23 +4,9 @@
 #ifndef _ASM_POWERPC_CACHEFLUSH_H
 #define _ASM_POWERPC_CACHEFLUSH_H
 
-#ifdef __KERNEL__
-
 #include 
 #include 
 
-/*
- * No cache flushing is required when address mappings are changed,
- * because the caches on PowerPCs are physically addressed.
- */
-#define flush_cache_all()  do { } while (0)
-#define flush_cache_mm(mm) do { } while (0)
-#define flush_cache_dup_mm(mm) do { } while (0)
-#define flush_cache_range(vma, start, end) do { } while (0)
-#define flush_cache_page(vma, vmaddr, pfn) do { } while (0)
-#define flush_icache_page(vma, page)   do { } while (0)
-#define flush_cache_vunmap(start, end) do { } while (0)
-
 #ifdef CONFIG_PPC_BOOK3S_64
 /*
  * Book3s has no ptesync after setting a pte, so without this ptesync it's
@@ -33,20 +19,20 @@ static inline void flush_cache_vmap(unsigned long start, 
unsigned long end)
 {
asm volatile("ptesync" ::: "memory");
 }
-#else
-static inline void flush_cache_vmap(unsigned long start, unsigned long end) { }
-#endif
+#define flush_cache_vmap flush_cache_vmap
+#endif /* CONFIG_PPC_BOOK3S_64 */
 
 #define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
 extern void flush_dcache_page(struct page *page);
-#define flush_dcache_mmap_lock(mapping)do { } while (0)
-#define flush_dcache_mmap_unlock(mapping)  do { } while (0)
 
 void flush_icache_range(unsigned long start, unsigned long stop);
-extern void flush_icache_user_range(struct vm_area_struct *vma,
-   struct page *page, unsigned long addr,
-   int len);
-extern void flush_dcache_icache_page(struct page *page);
+#define flush_icache_range flush_icache_range
+
+void flush_icache_user_range(struct vm_area_struct *vma, struct page *page,
+   unsigned long addr, int len);
+#define flush_icache_user_range flush_icache_user_range
+
+void flush_dcache_icache_page(struct page *page);
 void __flush_dcache_icache(void *page);
 
 /**
@@ -111,14 +97,6 @@ static inline void invalidate_dcache_range(unsigned long 
start,
mb();   /* sync */
 }
 
-#define copy_to_user_page(vma, page, vaddr, dst, src, len) \
-   do { \
-   memcpy(dst, src, len); \
-   flush_icache_user_range(vma, page, vaddr, len); \
-   } while (0)
-#define copy_from_user_page(vma, page, vaddr, dst, src, len) \
-   memcpy(dst, src, len)
-
-#endif /* __KERNEL__ */
+#include 
 
 #endif /* _ASM_POWERPC_CACHEFLUSH_H */
-- 
2.26.2

[PATCH 20/29] asm-generic: add a flush_icache_user_range stub

[Christoph Hellwig]

Define flush_icache_user_range to flush_icache_range unless the
architecture provides its own implementation.

Signed-off-by: Christoph Hellwig 
---
 include/asm-generic/cacheflush.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/asm-generic/cacheflush.h b/include/asm-generic/cacheflush.h
index 2c9686fefb715..907fa5d164944 100644
--- a/include/asm-generic/cacheflush.h
+++ b/include/asm-generic/cacheflush.h
@@ -66,6 +66,10 @@ static inline void flush_icache_range(unsigned long start, 
unsigned long end)
 }
 #endif
 
+#ifndef flush_icache_user_range
+#define flush_icache_user_range flush_icache_range
+#endif
+
 #ifndef flush_icache_page
 static inline void flush_icache_page(struct vm_area_struct *vma,
 struct page *page)
-- 
2.26.2

[PATCH 17/29] riscv: use asm-generic/cacheflush.h

[Christoph Hellwig]

RISC-V needs almost no cache flushing routines of its own.  Rely on
asm-generic/cacheflush.h for the defaults.

Also remove the pointless __KERNEL__ ifdef while we're at it.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Palmer Dabbelt 
Acked-by: Palmer Dabbelt 
---
 arch/riscv/include/asm/cacheflush.h | 62 ++---
 1 file changed, 3 insertions(+), 59 deletions(-)

diff --git a/arch/riscv/include/asm/cacheflush.h 
b/arch/riscv/include/asm/cacheflush.h
index c8677c75f82cb..a167b4fbdf007 100644
--- a/arch/riscv/include/asm/cacheflush.h
+++ b/arch/riscv/include/asm/cacheflush.h
@@ -8,65 +8,6 @@
 
 #include 
 
-#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
-
-/*
- * The cache doesn't need to be flushed when TLB entries change when
- * the cache is mapped to physical memory, not virtual memory
- */
-static inline void flush_cache_all(void)
-{
-}
-
-static inline void flush_cache_mm(struct mm_struct *mm)
-{
-}
-
-static inline void flush_cache_dup_mm(struct mm_struct *mm)
-{
-}
-
-static inline void flush_cache_range(struct vm_area_struct *vma,
-unsigned long start,
-unsigned long end)
-{
-}
-
-static inline void flush_cache_page(struct vm_area_struct *vma,
-   unsigned long vmaddr,
-   unsigned long pfn)
-{
-}
-
-static inline void flush_dcache_mmap_lock(struct address_space *mapping)
-{
-}
-
-static inline void flush_dcache_mmap_unlock(struct address_space *mapping)
-{
-}
-
-static inline void flush_icache_page(struct vm_area_struct *vma,
-struct page *page)
-{
-}
-
-static inline void flush_cache_vmap(unsigned long start, unsigned long end)
-{
-}
-
-static inline void flush_cache_vunmap(unsigned long start, unsigned long end)
-{
-}
-
-#define copy_to_user_page(vma, page, vaddr, dst, src, len) \
-   do { \
-   memcpy(dst, src, len); \
-   flush_icache_user_range(vma, page, vaddr, len); \
-   } while (0)
-#define copy_from_user_page(vma, page, vaddr, dst, src, len) \
-   memcpy(dst, src, len)
-
 static inline void local_flush_icache_all(void)
 {
asm volatile ("fence.i" ::: "memory");
@@ -79,6 +20,7 @@ static inline void flush_dcache_page(struct page *page)
if (test_bit(PG_dcache_clean, >flags))
clear_bit(PG_dcache_clean, >flags);
 }
+#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
 
 /*
  * RISC-V doesn't have an instruction to flush parts of the instruction cache,
@@ -105,4 +47,6 @@ void flush_icache_mm(struct mm_struct *mm, bool local);
 #define SYS_RISCV_FLUSH_ICACHE_LOCAL 1UL
 #define SYS_RISCV_FLUSH_ICACHE_ALL   (SYS_RISCV_FLUSH_ICACHE_LOCAL)
 
+#include 
+
 #endif /* _ASM_RISCV_CACHEFLUSH_H */
-- 
2.26.2

[PATCH 08/29] alpha: use asm-generic/cacheflush.h

[Christoph Hellwig]

Alpha needs almost no cache flushing routines of its own.  Rely on
asm-generic/cacheflush.h for the defaults.

Signed-off-by: Christoph Hellwig 
---
 arch/alpha/include/asm/cacheflush.h | 28 ++--
 1 file changed, 6 insertions(+), 22 deletions(-)

diff --git a/arch/alpha/include/asm/cacheflush.h 
b/arch/alpha/include/asm/cacheflush.h
index 89128489cb598..636d7ca0d05f6 100644
--- a/arch/alpha/include/asm/cacheflush.h
+++ b/arch/alpha/include/asm/cacheflush.h
@@ -4,19 +4,6 @@
 
 #include 
 
-/* Caches aren't brain-dead on the Alpha. */
-#define flush_cache_all()  do { } while (0)
-#define flush_cache_mm(mm) do { } while (0)
-#define flush_cache_dup_mm(mm) do { } while (0)
-#define flush_cache_range(vma, start, end) do { } while (0)
-#define flush_cache_page(vma, vmaddr, pfn) do { } while (0)
-#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
-#define flush_dcache_page(page)do { } while (0)
-#define flush_dcache_mmap_lock(mapping)do { } while (0)
-#define flush_dcache_mmap_unlock(mapping)  do { } while (0)
-#define flush_cache_vmap(start, end)   do { } while (0)
-#define flush_cache_vunmap(start, end) do { } while (0)
-
 /* Note that the following two definitions are _highly_ dependent
on the contexts in which they are used in the kernel.  I personally
think it is criminal how loosely defined these macros are.  */
@@ -59,20 +46,17 @@ flush_icache_user_range(struct vm_area_struct *vma, struct 
page *page,
mm->context[smp_processor_id()] = 0;
}
 }
-#else
+#define flush_icache_user_range flush_icache_user_range
+#else /* CONFIG_SMP */
 extern void flush_icache_user_range(struct vm_area_struct *vma,
struct page *page, unsigned long addr, int len);
-#endif
+#define flush_icache_user_range flush_icache_user_range
+#endif /* CONFIG_SMP */
 
 /* This is used only in __do_fault and do_swap_page.  */
 #define flush_icache_page(vma, page) \
-  flush_icache_user_range((vma), (page), 0, 0)
+   flush_icache_user_range((vma), (page), 0, 0)
 
-#define copy_to_user_page(vma, page, vaddr, dst, src, len) \
-do { memcpy(dst, src, len); \
- flush_icache_user_range(vma, page, vaddr, len); \
-} while (0)
-#define copy_from_user_page(vma, page, vaddr, dst, src, len) \
-   memcpy(dst, src, len)
+#include 
 
 #endif /* _ALPHA_CACHEFLUSH_H */
-- 
2.26.2

[PATCH 13/29] microblaze: use asm-generic/cacheflush.h

[Christoph Hellwig]

Microblaze needs almost no cache flushing routines of its own.  Rely on
asm-generic/cacheflush.h for the defaults.

Signed-off-by: Christoph Hellwig 
---
 arch/microblaze/include/asm/cacheflush.h | 29 ++--
 1 file changed, 2 insertions(+), 27 deletions(-)

diff --git a/arch/microblaze/include/asm/cacheflush.h 
b/arch/microblaze/include/asm/cacheflush.h
index 11f56c85056bb..39f8fb6768d8b 100644
--- a/arch/microblaze/include/asm/cacheflush.h
+++ b/arch/microblaze/include/asm/cacheflush.h
@@ -57,9 +57,6 @@ void microblaze_cache_init(void);
 #define invalidate_icache()mbc->iin();
 #define invalidate_icache_range(start, end)mbc->iinr(start, end);
 
-#define flush_icache_user_range(vma, pg, adr, len) flush_icache();
-#define flush_icache_page(vma, pg) do { } while (0)
-
 #define enable_dcache()mbc->de();
 #define disable_dcache()   mbc->dd();
 /* FIXME for LL-temac driver */
@@ -77,27 +74,9 @@ do { \
flush_dcache_range((unsigned) (addr), (unsigned) (addr) + PAGE_SIZE); \
 } while (0);
 
-#define flush_dcache_mmap_lock(mapping)do { } while (0)
-#define flush_dcache_mmap_unlock(mapping)  do { } while (0)
-
-#define flush_cache_dup_mm(mm) do { } while (0)
-#define flush_cache_vmap(start, end)   do { } while (0)
-#define flush_cache_vunmap(start, end) do { } while (0)
-#define flush_cache_mm(mm) do { } while (0)
-
 #define flush_cache_page(vma, vmaddr, pfn) \
flush_dcache_range(pfn << PAGE_SHIFT, (pfn << PAGE_SHIFT) + PAGE_SIZE);
 
-/* MS: kgdb code use this macro, wrong len with FLASH */
-#if 0
-#define flush_cache_range(vma, start, len) {   \
-   flush_icache_range((unsigned) (start), (unsigned) (start) + (len)); \
-   flush_dcache_range((unsigned) (start), (unsigned) (start) + (len)); \
-}
-#endif
-
-#define flush_cache_range(vma, start, len) do { } while (0)
-
 static inline void copy_to_user_page(struct vm_area_struct *vma,
 struct page *page, unsigned long vaddr,
 void *dst, void *src, int len)
@@ -109,12 +88,8 @@ static inline void copy_to_user_page(struct vm_area_struct 
*vma,
flush_dcache_range(addr, addr + PAGE_SIZE);
}
 }
+#define copy_to_user_page copy_to_user_page
 
-static inline void copy_from_user_page(struct vm_area_struct *vma,
-  struct page *page, unsigned long vaddr,
-  void *dst, void *src, int len)
-{
-   memcpy(dst, src, len);
-}
+#include 
 
 #endif /* _ASM_MICROBLAZE_CACHEFLUSH_H */
-- 
2.26.2

Re: How about just O_EXEC? (was Re: [PATCH v5 3/6] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC)

[Kees Cook]

On Fri, May 15, 2020 at 10:43:34AM +0200, Florian Weimer wrote:
> * Kees Cook:
> 
> > Maybe I've missed some earlier discussion that ruled this out, but I
> > couldn't find it: let's just add O_EXEC and be done with it. It actually
> > makes the execve() path more like openat2() and is much cleaner after
> > a little refactoring. Here are the results, though I haven't emailed it
> > yet since I still want to do some more testing:
> > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/o_exec/v1
> 
> I think POSIX specifies O_EXEC in such a way that it does not confer
> read permissions.  This seems incompatible with what we are trying to
> achieve here.

I was trying to retain this behavior, since we already make this
distinction between execve() and uselib() with the MAY_* flags:

execve():
struct open_flags open_exec_flags = {
.open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC,
.acc_mode = MAY_EXEC,

uselib():
static const struct open_flags uselib_flags = {
.open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC,
.acc_mode = MAY_READ | MAY_EXEC,

I tried to retain this in my proposal, in the O_EXEC does not imply
MAY_READ:

+   /* Should execution permissions be checked on open? */
+   if (flags & O_EXEC) {
+   flags |= __FMODE_EXEC;
+   acc_mode |= MAY_EXEC;
+   }

-- 
Kees Cook

[PATCH 06/29] asm-generic: don't include in cacheflush.h

[Christoph Hellwig]

This seems to lead to some crazy include loops when using
asm-generic/cacheflush.h on more architectures, so leave it
to the arch header for now.

Signed-off-by: Christoph Hellwig 
---
 arch/um/include/asm/tlb.h | 2 ++
 arch/x86/include/asm/cacheflush.h | 2 ++
 drivers/nvdimm/pmem.c | 3 ++-
 include/asm-generic/cacheflush.h  | 3 ---
 4 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/um/include/asm/tlb.h b/arch/um/include/asm/tlb.h
index 70ee603839006..ff9c62828962c 100644
--- a/arch/um/include/asm/tlb.h
+++ b/arch/um/include/asm/tlb.h
@@ -2,6 +2,8 @@
 #ifndef __UM_TLB_H
 #define __UM_TLB_H
 
+#include 
+
 #include 
 #include 
 #include 
diff --git a/arch/x86/include/asm/cacheflush.h 
b/arch/x86/include/asm/cacheflush.h
index 63feaf2a5f93d..b192d917a6d0b 100644
--- a/arch/x86/include/asm/cacheflush.h
+++ b/arch/x86/include/asm/cacheflush.h
@@ -2,6 +2,8 @@
 #ifndef _ASM_X86_CACHEFLUSH_H
 #define _ASM_X86_CACHEFLUSH_H
 
+#include 
+
 /* Caches aren't brain-dead on the intel. */
 #include 
 #include 
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 2df6994acf836..55282a6217407 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -7,7 +7,6 @@
  * Copyright (c) 2015, Boaz Harrosh .
  */
 
-#include 
 #include 
 #include 
 #include 
@@ -25,6 +24,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "pmem.h"
 #include "pfn.h"
 #include "nd.h"
diff --git a/include/asm-generic/cacheflush.h b/include/asm-generic/cacheflush.h
index 906277492ec59..bf9bb83e9fc8d 100644
--- a/include/asm-generic/cacheflush.h
+++ b/include/asm-generic/cacheflush.h
@@ -2,9 +2,6 @@
 #ifndef _ASM_GENERIC_CACHEFLUSH_H
 #define _ASM_GENERIC_CACHEFLUSH_H
 
-/* Keep includes the same across arches.  */
-#include 
-
 #define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
 
 /*
-- 
2.26.2

[PATCH 02/29] nds32: unexport flush_icache_page

[Christoph Hellwig]

flush_icache_page is only used by mm/memory.c.

Signed-off-by: Christoph Hellwig 
---
 arch/nds32/mm/cacheflush.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/nds32/mm/cacheflush.c b/arch/nds32/mm/cacheflush.c
index 254703653b6f5..8f168b33065fa 100644
--- a/arch/nds32/mm/cacheflush.c
+++ b/arch/nds32/mm/cacheflush.c
@@ -35,7 +35,6 @@ void flush_icache_page(struct vm_area_struct *vma, struct 
page *page)
kunmap_atomic((void *)kaddr);
local_irq_restore(flags);
 }
-EXPORT_SYMBOL(flush_icache_page);
 
 void flush_icache_user_range(struct vm_area_struct *vma, struct page *page,
 unsigned long addr, int len)
-- 
2.26.2

sort out the flush_icache_range mess v2

[Christoph Hellwig]

Hi all,

flush_icache_range is mostly used for kernel address, except for the following
cases:

 - the nommu brk and mmap implementations,
 - the read_code helper that is only used for binfmt_flat, binfmt_elf_fdpic,
   and binfmt_aout including the broken ia32 compat version
 - binfmt_flat itself,

none of which really are used by a typical MMU enabled kernel, as a.out can
only be build for alpha and m68k to start with.

But strangely enough commit ae92ef8a4424 ("PATCH] flush icache in correct
context") added a "set_fs(KERNEL_DS)" around the flush_icache_range call
in the module loader, because apparently m68k assumed user pointers.

This series first cleans up the cacheflush implementations, largely by
switching as much as possible to the asm-generic version after a few
preparations, then moves the misnamed current flush_icache_user_range to
a new name, to finally introduce a real flush_icache_user_range to be used
for the above use cases to flush the instruction cache for a userspace
address range.  The last patch then drops the set_fs in the module code
and moves it into the m68k implementation.

A git tree is available here:

git://git.infradead.org/users/hch/misc.git flush_icache_range.2

Gitweb:


http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/flush_icache_range.2

Changes since v1:
 - fix pmem.c compilation on some s390 configs
 - drop two patches picked up by the arch maintainers

[PATCH 01/29] arm: fix the flush_icache_range arguments in set_fiq_handler

[Christoph Hellwig]

The arguments passed look bogus, try to fix them to something that seems
to make sense.

Signed-off-by: Christoph Hellwig 
---
 arch/arm/kernel/fiq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/fiq.c b/arch/arm/kernel/fiq.c
index cd1234c103fcd..98ca3e3fa8471 100644
--- a/arch/arm/kernel/fiq.c
+++ b/arch/arm/kernel/fiq.c
@@ -98,8 +98,8 @@ void set_fiq_handler(void *start, unsigned int length)
 
memcpy(base + offset, start, length);
if (!cache_is_vipt_nonaliasing())
-   flush_icache_range((unsigned long)base + offset, offset +
-  length);
+   flush_icache_range((unsigned long)base + offset,
+  (unsigned long)base + offset + length);
flush_icache_range(0x + offset, 0x + offset + length);
 }
 
-- 
2.26.2

[PATCH 03/29] powerpc: unexport flush_icache_user_range

[Christoph Hellwig]

flush_icache_user_range is only used by copy_to_user_page, which is
only used by core VM code.

Signed-off-by: Christoph Hellwig 
---
 arch/powerpc/mm/mem.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 041ed7cfd341a..f0d1bf0a8e14f 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -587,7 +587,6 @@ void flush_icache_user_range(struct vm_area_struct *vma, 
struct page *page,
flush_icache_range(maddr, maddr + len);
kunmap(page);
 }
-EXPORT_SYMBOL(flush_icache_user_range);
 
 /*
  * System memory should not be in /proc/iomem but various tools expect it
-- 
2.26.2

[PATCH 04/29] unicore32: remove flush_cache_user_range

[Christoph Hellwig]

flush_cache_user_range is an ARMism not used by any generic or unicore32
specific code.

Signed-off-by: Christoph Hellwig 
---
 arch/unicore32/include/asm/cacheflush.h | 8 
 1 file changed, 8 deletions(-)

diff --git a/arch/unicore32/include/asm/cacheflush.h 
b/arch/unicore32/include/asm/cacheflush.h
index dc8c0b41538f8..9393ca4047e93 100644
--- a/arch/unicore32/include/asm/cacheflush.h
+++ b/arch/unicore32/include/asm/cacheflush.h
@@ -132,14 +132,6 @@ extern void flush_cache_page(struct vm_area_struct *vma,
 
 #define flush_cache_dup_mm(mm) flush_cache_mm(mm)
 
-/*
- * flush_cache_user_range is used when we want to ensure that the
- * Harvard caches are synchronised for the user space address range.
- * This is used for the UniCore private sys_cacheflush system call.
- */
-#define flush_cache_user_range(vma, start, end) \
-   __cpuc_coherent_user_range((start) & PAGE_MASK, PAGE_ALIGN(end))
-
 /*
  * Perform necessary cache operations to ensure that data previously
  * stored within this range of addresses can be executed by the CPU.
-- 
2.26.2