[ 1/1] KVM/MMU: Fix comment in walk_shadow_page_lockless_end()
kvm_commit_zap_page() has been renamed to kvm_mmu_commit_zap_page()
This patch is to fix the commit.
Signed-off-by: Lan Tianyu
---
arch/x86/kvm/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 7ccd29b95746..648b839a349d 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -947,7 +947,7 @@ static void walk_shadow_page_lockless_end(struct kvm_vcpu
*vcpu)
{
/*
* Make sure the write to vcpu->mode is not reordered in front of
-* reads to sptes. If it does, kvm_commit_zap_page() can see us
+* reads to sptes. If it does, kvm_mmu_commit_zap_page() can see us
* OUTSIDE_GUEST_MODE and proceed to free the shadow page table.
*/
smp_store_release(>mode, OUTSIDE_GUEST_MODE);
--
2.14.4
[ 1/1] KVM/MMU: Fix comment in walk_shadow_page_lockless_end()
kvm_commit_zap_page() has been renamed to kvm_mmu_commit_zap_page()
This patch is to fix the commit.
Signed-off-by: Lan Tianyu
---
arch/x86/kvm/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 7ccd29b95746..648b839a349d 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -947,7 +947,7 @@ static void walk_shadow_page_lockless_end(struct kvm_vcpu
*vcpu)
{
/*
* Make sure the write to vcpu->mode is not reordered in front of
-* reads to sptes. If it does, kvm_commit_zap_page() can see us
+* reads to sptes. If it does, kvm_mmu_commit_zap_page() can see us
* OUTSIDE_GUEST_MODE and proceed to free the shadow page table.
*/
smp_store_release(>mode, OUTSIDE_GUEST_MODE);
--
2.14.4
Re: [PATCH AUTOSEL 4.4 01/30] usb: usbtest: use irqsave() in USB's complete callback
On Fri, Sep 07, 2018 at 12:38:56AM +, Sasha Levin wrote: > From: Sebastian Andrzej Siewior > > [ Upstream commit 6f3fde684d0232e66ada3410f016a58e09a87689 ] > > The USB completion callback does not disable interrupts while acquiring > the lock. We want to remove the local_irq_disable() invocation from > __usb_hcd_giveback_urb() and therefore it is required for the callback > handler to disable the interrupts while acquiring the lock. > The callback may be invoked either in IRQ or BH context depending on the > USB host controller. > Use the _irqsave() variant of the locking primitives. > > Cc: Greg Kroah-Hartman > Acked-by: Alan Stern > Signed-off-by: Sebastian Andrzej Siewior > Signed-off-by: Greg Kroah-Hartman > Signed-off-by: Sasha Levin > --- > drivers/usb/misc/usbtest.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) And dropped here.
Re: [PATCH AUTOSEL 4.4 01/30] usb: usbtest: use irqsave() in USB's complete callback
On Fri, Sep 07, 2018 at 12:38:56AM +, Sasha Levin wrote: > From: Sebastian Andrzej Siewior > > [ Upstream commit 6f3fde684d0232e66ada3410f016a58e09a87689 ] > > The USB completion callback does not disable interrupts while acquiring > the lock. We want to remove the local_irq_disable() invocation from > __usb_hcd_giveback_urb() and therefore it is required for the callback > handler to disable the interrupts while acquiring the lock. > The callback may be invoked either in IRQ or BH context depending on the > USB host controller. > Use the _irqsave() variant of the locking primitives. > > Cc: Greg Kroah-Hartman > Acked-by: Alan Stern > Signed-off-by: Sebastian Andrzej Siewior > Signed-off-by: Greg Kroah-Hartman > Signed-off-by: Sasha Levin > --- > drivers/usb/misc/usbtest.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) And dropped here.
Re: [PATCH AUTOSEL 4.9 01/43] usb: usbtest: use irqsave() in USB's complete callback
On Fri, Sep 07, 2018 at 12:38:19AM +, Sasha Levin wrote: > From: Sebastian Andrzej Siewior > > [ Upstream commit 6f3fde684d0232e66ada3410f016a58e09a87689 ] > > The USB completion callback does not disable interrupts while acquiring > the lock. We want to remove the local_irq_disable() invocation from > __usb_hcd_giveback_urb() and therefore it is required for the callback > handler to disable the interrupts while acquiring the lock. > The callback may be invoked either in IRQ or BH context depending on the > USB host controller. > Use the _irqsave() variant of the locking primitives. > > Cc: Greg Kroah-Hartman > Acked-by: Alan Stern > Signed-off-by: Sebastian Andrzej Siewior > Signed-off-by: Greg Kroah-Hartman > Signed-off-by: Sasha Levin > --- > drivers/usb/misc/usbtest.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) And dropped here :)
Re: [PATCH AUTOSEL 4.9 01/43] usb: usbtest: use irqsave() in USB's complete callback
On Fri, Sep 07, 2018 at 12:38:19AM +, Sasha Levin wrote: > From: Sebastian Andrzej Siewior > > [ Upstream commit 6f3fde684d0232e66ada3410f016a58e09a87689 ] > > The USB completion callback does not disable interrupts while acquiring > the lock. We want to remove the local_irq_disable() invocation from > __usb_hcd_giveback_urb() and therefore it is required for the callback > handler to disable the interrupts while acquiring the lock. > The callback may be invoked either in IRQ or BH context depending on the > USB host controller. > Use the _irqsave() variant of the locking primitives. > > Cc: Greg Kroah-Hartman > Acked-by: Alan Stern > Signed-off-by: Sebastian Andrzej Siewior > Signed-off-by: Greg Kroah-Hartman > Signed-off-by: Sasha Levin > --- > drivers/usb/misc/usbtest.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) And dropped here :)
Re: [PATCH AUTOSEL 4.14 02/67] usb: usbtest: use irqsave() in USB's complete callback
On Fri, Sep 07, 2018 at 12:37:22AM +, Sasha Levin wrote: > From: Sebastian Andrzej Siewior > > [ Upstream commit 6f3fde684d0232e66ada3410f016a58e09a87689 ] > > The USB completion callback does not disable interrupts while acquiring > the lock. We want to remove the local_irq_disable() invocation from > __usb_hcd_giveback_urb() and therefore it is required for the callback > handler to disable the interrupts while acquiring the lock. > The callback may be invoked either in IRQ or BH context depending on the > USB host controller. > Use the _irqsave() variant of the locking primitives. > > Cc: Greg Kroah-Hartman > Acked-by: Alan Stern > Signed-off-by: Sebastian Andrzej Siewior > Signed-off-by: Greg Kroah-Hartman > Signed-off-by: Sasha Levin > --- > drivers/usb/misc/usbtest.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) Again, this can be dropped. thanks, greg k-h
Re: [PATCH AUTOSEL 4.14 02/67] usb: usbtest: use irqsave() in USB's complete callback
On Fri, Sep 07, 2018 at 12:37:22AM +, Sasha Levin wrote: > From: Sebastian Andrzej Siewior > > [ Upstream commit 6f3fde684d0232e66ada3410f016a58e09a87689 ] > > The USB completion callback does not disable interrupts while acquiring > the lock. We want to remove the local_irq_disable() invocation from > __usb_hcd_giveback_urb() and therefore it is required for the callback > handler to disable the interrupts while acquiring the lock. > The callback may be invoked either in IRQ or BH context depending on the > USB host controller. > Use the _irqsave() variant of the locking primitives. > > Cc: Greg Kroah-Hartman > Acked-by: Alan Stern > Signed-off-by: Sebastian Andrzej Siewior > Signed-off-by: Greg Kroah-Hartman > Signed-off-by: Sasha Levin > --- > drivers/usb/misc/usbtest.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) Again, this can be dropped. thanks, greg k-h
Re: [PATCH AUTOSEL 4.18 02/88] usb: usbtest: use irqsave() in USB's complete callback
On Fri, Sep 07, 2018 at 12:35:52AM +, Sasha Levin wrote: > From: Sebastian Andrzej Siewior > > [ Upstream commit 6f3fde684d0232e66ada3410f016a58e09a87689 ] > > The USB completion callback does not disable interrupts while acquiring > the lock. We want to remove the local_irq_disable() invocation from > __usb_hcd_giveback_urb() and therefore it is required for the callback > handler to disable the interrupts while acquiring the lock. > The callback may be invoked either in IRQ or BH context depending on the > USB host controller. > Use the _irqsave() variant of the locking primitives. All of the "use irqsave in USB's complete callback" patches are not stable material as they are prep work for changes that have yet to hit Linus's tree. So you can drop this one. thanks, greg k-h
Re: [PATCH AUTOSEL 4.18 02/88] usb: usbtest: use irqsave() in USB's complete callback
On Fri, Sep 07, 2018 at 12:35:52AM +, Sasha Levin wrote: > From: Sebastian Andrzej Siewior > > [ Upstream commit 6f3fde684d0232e66ada3410f016a58e09a87689 ] > > The USB completion callback does not disable interrupts while acquiring > the lock. We want to remove the local_irq_disable() invocation from > __usb_hcd_giveback_urb() and therefore it is required for the callback > handler to disable the interrupts while acquiring the lock. > The callback may be invoked either in IRQ or BH context depending on the > USB host controller. > Use the _irqsave() variant of the locking primitives. All of the "use irqsave in USB's complete callback" patches are not stable material as they are prep work for changes that have yet to hit Linus's tree. So you can drop this one. thanks, greg k-h
Re: [PATCH V3 21/26] dt-bindings: interrupt-controller: C-SKY APB intc
On Thu, Sep 06, 2018 at 03:05:38PM +0200, Arnd Bergmann wrote:
> On Thu, Sep 6, 2018 at 4:13 AM Guo Ren wrote:
> >
> > On Wed, Sep 05, 2018 at 07:43:10PM -0500, Rob Herring wrote:
> > > On Wed, Sep 5, 2018 at 7:10 AM Guo Ren wrote:
> > > >
> > > > Signed-off-by: Guo Ren
> > > > +
> > > > + intc: interrupt-controller {
> > >
> > > Needs a unit-address.
> > Ok, change it to:
> > intc: interrupt-controller@0x0050 {
>
> The unit address has no leading 0x or leading zeroes, so
> interrupt-controller@50
Ok
Guo Ren
Re: [PATCH V3 21/26] dt-bindings: interrupt-controller: C-SKY APB intc
On Thu, Sep 06, 2018 at 03:05:38PM +0200, Arnd Bergmann wrote:
> On Thu, Sep 6, 2018 at 4:13 AM Guo Ren wrote:
> >
> > On Wed, Sep 05, 2018 at 07:43:10PM -0500, Rob Herring wrote:
> > > On Wed, Sep 5, 2018 at 7:10 AM Guo Ren wrote:
> > > >
> > > > Signed-off-by: Guo Ren
> > > > +
> > > > + intc: interrupt-controller {
> > >
> > > Needs a unit-address.
> > Ok, change it to:
> > intc: interrupt-controller@0x0050 {
>
> The unit address has no leading 0x or leading zeroes, so
> interrupt-controller@50
Ok
Guo Ren
[PATCH 6/6] ARM: dts: qcom-msm8974: change invalid flag IRQ NONE to valid value
From: Frank Rowand
Change the third field of the "interrupts" property from
IRQ_TYPE_NONE to the correct value.
I do not have hardware documentation for these devices, so I
followed a mail list suggestion to copy the flag values from the same
type of node in arch/arm64/boot/dts/qcom/msm8916.dtsi
Signed-off-by: Frank Rowand
---
Compile and boot tested on a Qualcomm APQ8074 Dragonboard.
arch/arm/boot/dts/qcom-msm8974.dtsi | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 1e54113d6d9a..9550f0612918 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -586,7 +586,7 @@
blsp1_uart1: serial@f991d000 {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0xf991d000 0x1000>;
- interrupts = ;
+ interrupts = ;
clocks = < GCC_BLSP1_UART1_APPS_CLK>, <
GCC_BLSP1_AHB_CLK>;
clock-names = "core", "iface";
status = "disabled";
@@ -595,7 +595,7 @@
blsp1_uart2: serial@f991e000 {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0xf991e000 0x1000>;
- interrupts = ;
+ interrupts = ;
clocks = < GCC_BLSP1_UART2_APPS_CLK>, <
GCC_BLSP1_AHB_CLK>;
clock-names = "core", "iface";
status = "disabled";
@@ -605,8 +605,8 @@
compatible = "qcom,sdhci-msm-v4";
reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
reg-names = "hc_mem", "core_mem";
- interrupts = ,
-;
+ interrupts = ,
+;
interrupt-names = "hc_irq", "pwr_irq";
clocks = < GCC_SDCC1_APPS_CLK>,
< GCC_SDCC1_AHB_CLK>,
@@ -619,8 +619,8 @@
compatible = "qcom,sdhci-msm-v4";
reg = <0xf9864900 0x11c>, <0xf9864000 0x800>;
reg-names = "hc_mem", "core_mem";
- interrupts = ,
-;
+ interrupts = ,
+;
interrupt-names = "hc_irq", "pwr_irq";
clocks = < GCC_SDCC3_APPS_CLK>,
< GCC_SDCC3_AHB_CLK>,
@@ -633,8 +633,8 @@
compatible = "qcom,sdhci-msm-v4";
reg = <0xf98a4900 0x11c>, <0xf98a4000 0x800>;
reg-names = "hc_mem", "core_mem";
- interrupts = ,
-;
+ interrupts = ,
+;
interrupt-names = "hc_irq", "pwr_irq";
clocks = < GCC_SDCC2_APPS_CLK>,
< GCC_SDCC2_AHB_CLK>,
@@ -701,14 +701,14 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
- interrupts = ;
+ interrupts = ;
};
i2c@f9924000 {
status = "disabled";
compatible = "qcom,i2c-qup-v2.1.1";
reg = <0xf9924000 0x1000>;
- interrupts = ;
+ interrupts = ;
clocks = < GCC_BLSP1_QUP2_I2C_APPS_CLK>, <
GCC_BLSP1_AHB_CLK>;
clock-names = "core", "iface";
#address-cells = <1>;
@@ -719,7 +719,7 @@
status = "disabled";
compatible = "qcom,i2c-qup-v2.1.1";
reg = <0xf9964000 0x1000>;
- interrupts = ;
+ interrupts = ;
clocks = < GCC_BLSP2_QUP2_I2C_APPS_CLK>, <
GCC_BLSP2_AHB_CLK>;
clock-names = "core", "iface";
#address-cells = <1>;
@@ -730,7 +730,7 @@
status = "disabled";
compatible = "qcom,i2c-qup-v2.1.1";
reg = <0xf9967000 0x1000>;
- interrupts = ;
+ interrupts = ;
clocks = < GCC_BLSP2_QUP5_I2C_APPS_CLK>, <
GCC_BLSP2_AHB_CLK>;
clock-names = "core", "iface";
#address-cells = <1>;
@@ -746,7 +746,7 @@
<0xfc4cb000 0x1000>,
<0xfc4ca000 0x1000>;
[PATCH 2/6] ARM: dts: qcom-msm8974: use named constant for interrupt type GIC_SPI
From: Frank Rowand
Cosmetic change of integer value "0" in the first field of the
"interrupts" property to the correct named constant.
Signed-off-by: Frank Rowand
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 56 +++--
1 file changed, 29 insertions(+), 27 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index f4f5e2df4c03..c09cc1232a6f 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -243,7 +243,7 @@
adsp-pil {
compatible = "qcom,msm8974-adsp-pil";
- interrupts-extended = < 0 162 IRQ_TYPE_EDGE_RISING>,
+ interrupts-extended = < GIC_SPI 162 IRQ_TYPE_EDGE_RISING>,
<_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
<_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
<_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
@@ -275,7 +275,7 @@
qcom,smem = <443>, <429>;
interrupt-parent = <>;
- interrupts = <0 158 IRQ_TYPE_EDGE_RISING>;
+ interrupts = ;
qcom,ipc = < 8 10>;
@@ -300,7 +300,7 @@
qcom,smem = <435>, <428>;
interrupt-parent = <>;
- interrupts = <0 27 IRQ_TYPE_EDGE_RISING>;
+ interrupts = ;
qcom,ipc = < 8 14>;
@@ -325,7 +325,7 @@
qcom,smem = <451>, <431>;
interrupt-parent = <>;
- interrupts = <0 143 IRQ_TYPE_EDGE_RISING>;
+ interrupts = ;
qcom,ipc = < 8 18>;
@@ -364,7 +364,7 @@
modem_smsm: modem@1 {
reg = <1>;
- interrupts = <0 26 IRQ_TYPE_EDGE_RISING>;
+ interrupts = ;
interrupt-controller;
#interrupt-cells = <2>;
@@ -372,7 +372,7 @@
adsp_smsm: adsp@2 {
reg = <2>;
- interrupts = <0 157 IRQ_TYPE_EDGE_RISING>;
+ interrupts = ;
interrupt-controller;
#interrupt-cells = <2>;
@@ -380,7 +380,7 @@
wcnss_smsm: wcnss@7 {
reg = <7>;
- interrupts = <0 144 IRQ_TYPE_EDGE_RISING>;
+ interrupts = ;
interrupt-controller;
#interrupt-cells = <2>;
@@ -445,50 +445,50 @@
frame@f9021000 {
frame-number = <0>;
- interrupts = <0 8 0x4>,
-<0 7 0x4>;
+ interrupts = ,
+;
reg = <0xf9021000 0x1000>,
<0xf9022000 0x1000>;
};
frame@f9023000 {
frame-number = <1>;
- interrupts = <0 9 0x4>;
+ interrupts = ;
reg = <0xf9023000 0x1000>;
status = "disabled";
};
frame@f9024000 {
frame-number = <2>;
- interrupts = <0 10 0x4>;
+ interrupts = ;
reg = <0xf9024000 0x1000>;
status = "disabled";
};
frame@f9025000 {
frame-number = <3>;
- interrupts = <0 11 0x4>;
+ interrupts = ;
reg = <0xf9025000 0x1000>;
status = "disabled";
};
frame@f9026000 {
frame-number = <4>;
- interrupts = <0 12 0x4>;
+ interrupts = ;
reg = <0xf9026000 0x1000>;
status = "disabled";
};
frame@f9027000 {
frame-number = <5>;
- interrupts = <0 13 0x4>;
+ interrupts = ;
reg = <0xf9027000 0x1000>;
status = "disabled";
};
frame@f9028000 {
frame-number = <6>;
- interrupts = <0 14 0x4>;
+ interrupts = ;
reg = <0xf9028000 0x1000>;
[PATCH 1/6] ARM: dts: qcom-msm8974: use named constant for interrupt type GIC_PPI
From: Frank Rowand
Cosmetic change of integer value "1" in the first field of the
"interrupts" property to the correct named constant.
Signed-off-by: Frank Rowand
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index d9019a49b292..f4f5e2df4c03 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -67,7 +67,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
- interrupts = <1 9 0xf04>;
+ interrupts = ;
CPU0: cpu@0 {
compatible = "qcom,krait";
@@ -214,7 +214,7 @@
cpu-pmu {
compatible = "qcom,krait-pmu";
- interrupts = <1 7 0xf04>;
+ interrupts = ;
};
clocks {
@@ -233,10 +233,10 @@
timer {
compatible = "arm,armv7-timer";
- interrupts = <1 2 0xf08>,
-<1 3 0xf08>,
-<1 4 0xf08>,
-<1 1 0xf08>;
+ interrupts = ,
+,
+,
+;
clock-frequency = <1920>;
};
--
Frank Rowand
[PATCH 0/6] ARM: dts: qcom-msm8974: change invalid flag IRQ NONE to valid value
From: Frank Rowand
A boot time warning of devicetree interrupts types set to the invalid
value of none was added by 83a86fbb5b56 ("irqchip/gic: Loudly complain
about the use of IRQ_TYPE_NONE"). This patch series fixes the
devicetree source to replace IRQ_TYPE_NONE with the appropriate
value.
Some cosmetic changes are made by several patches. The final patch
in the series replaces the IRQ_TYPE_NONE values with the proper
values.
The cosmetic changes are to change integer values in the third field
of the "interrupts" property to the correct named constant.
Bjorn suggested that I also change integer values in the first field
of the "interrupts" property to the correct named constant.
The series is split into several patches for ease of review. Each
cosmetic patch addresses a single named constant.
Frank Rowand (6):
ARM: dts: qcom-msm8974: use named constant for interrupt type GIC_PPI
ARM: dts: qcom-msm8974: use named constant for interrupt type GIC_SPI
ARM: dts: qcom-msm8974: use named constant for interrupt flag EDGE
RISING
ARM: dts: qcom-msm8974: use named constant for interrupt flag LEVEL
HIGH
ARM: dts: qcom-msm8974: use named constant for interrupt flag NONE
ARM: dts: qcom-msm8974: change invalid flag IRQ NONE to valid value
arch/arm/boot/dts/qcom-msm8974.dtsi | 72 +++--
1 file changed, 37 insertions(+), 35 deletions(-)
--
Frank Rowand
[PATCH 6/6] ARM: dts: qcom-msm8974: change invalid flag IRQ NONE to valid value
From: Frank Rowand
Change the third field of the "interrupts" property from
IRQ_TYPE_NONE to the correct value.
I do not have hardware documentation for these devices, so I
followed a mail list suggestion to copy the flag values from the same
type of node in arch/arm64/boot/dts/qcom/msm8916.dtsi
Signed-off-by: Frank Rowand
---
Compile and boot tested on a Qualcomm APQ8074 Dragonboard.
arch/arm/boot/dts/qcom-msm8974.dtsi | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 1e54113d6d9a..9550f0612918 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -586,7 +586,7 @@
blsp1_uart1: serial@f991d000 {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0xf991d000 0x1000>;
- interrupts = ;
+ interrupts = ;
clocks = < GCC_BLSP1_UART1_APPS_CLK>, <
GCC_BLSP1_AHB_CLK>;
clock-names = "core", "iface";
status = "disabled";
@@ -595,7 +595,7 @@
blsp1_uart2: serial@f991e000 {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0xf991e000 0x1000>;
- interrupts = ;
+ interrupts = ;
clocks = < GCC_BLSP1_UART2_APPS_CLK>, <
GCC_BLSP1_AHB_CLK>;
clock-names = "core", "iface";
status = "disabled";
@@ -605,8 +605,8 @@
compatible = "qcom,sdhci-msm-v4";
reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
reg-names = "hc_mem", "core_mem";
- interrupts = ,
-;
+ interrupts = ,
+;
interrupt-names = "hc_irq", "pwr_irq";
clocks = < GCC_SDCC1_APPS_CLK>,
< GCC_SDCC1_AHB_CLK>,
@@ -619,8 +619,8 @@
compatible = "qcom,sdhci-msm-v4";
reg = <0xf9864900 0x11c>, <0xf9864000 0x800>;
reg-names = "hc_mem", "core_mem";
- interrupts = ,
-;
+ interrupts = ,
+;
interrupt-names = "hc_irq", "pwr_irq";
clocks = < GCC_SDCC3_APPS_CLK>,
< GCC_SDCC3_AHB_CLK>,
@@ -633,8 +633,8 @@
compatible = "qcom,sdhci-msm-v4";
reg = <0xf98a4900 0x11c>, <0xf98a4000 0x800>;
reg-names = "hc_mem", "core_mem";
- interrupts = ,
-;
+ interrupts = ,
+;
interrupt-names = "hc_irq", "pwr_irq";
clocks = < GCC_SDCC2_APPS_CLK>,
< GCC_SDCC2_AHB_CLK>,
@@ -701,14 +701,14 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
- interrupts = ;
+ interrupts = ;
};
i2c@f9924000 {
status = "disabled";
compatible = "qcom,i2c-qup-v2.1.1";
reg = <0xf9924000 0x1000>;
- interrupts = ;
+ interrupts = ;
clocks = < GCC_BLSP1_QUP2_I2C_APPS_CLK>, <
GCC_BLSP1_AHB_CLK>;
clock-names = "core", "iface";
#address-cells = <1>;
@@ -719,7 +719,7 @@
status = "disabled";
compatible = "qcom,i2c-qup-v2.1.1";
reg = <0xf9964000 0x1000>;
- interrupts = ;
+ interrupts = ;
clocks = < GCC_BLSP2_QUP2_I2C_APPS_CLK>, <
GCC_BLSP2_AHB_CLK>;
clock-names = "core", "iface";
#address-cells = <1>;
@@ -730,7 +730,7 @@
status = "disabled";
compatible = "qcom,i2c-qup-v2.1.1";
reg = <0xf9967000 0x1000>;
- interrupts = ;
+ interrupts = ;
clocks = < GCC_BLSP2_QUP5_I2C_APPS_CLK>, <
GCC_BLSP2_AHB_CLK>;
clock-names = "core", "iface";
#address-cells = <1>;
@@ -746,7 +746,7 @@
<0xfc4cb000 0x1000>,
<0xfc4ca000 0x1000>;
[PATCH 2/6] ARM: dts: qcom-msm8974: use named constant for interrupt type GIC_SPI
From: Frank Rowand
Cosmetic change of integer value "0" in the first field of the
"interrupts" property to the correct named constant.
Signed-off-by: Frank Rowand
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 56 +++--
1 file changed, 29 insertions(+), 27 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index f4f5e2df4c03..c09cc1232a6f 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -243,7 +243,7 @@
adsp-pil {
compatible = "qcom,msm8974-adsp-pil";
- interrupts-extended = < 0 162 IRQ_TYPE_EDGE_RISING>,
+ interrupts-extended = < GIC_SPI 162 IRQ_TYPE_EDGE_RISING>,
<_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
<_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
<_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
@@ -275,7 +275,7 @@
qcom,smem = <443>, <429>;
interrupt-parent = <>;
- interrupts = <0 158 IRQ_TYPE_EDGE_RISING>;
+ interrupts = ;
qcom,ipc = < 8 10>;
@@ -300,7 +300,7 @@
qcom,smem = <435>, <428>;
interrupt-parent = <>;
- interrupts = <0 27 IRQ_TYPE_EDGE_RISING>;
+ interrupts = ;
qcom,ipc = < 8 14>;
@@ -325,7 +325,7 @@
qcom,smem = <451>, <431>;
interrupt-parent = <>;
- interrupts = <0 143 IRQ_TYPE_EDGE_RISING>;
+ interrupts = ;
qcom,ipc = < 8 18>;
@@ -364,7 +364,7 @@
modem_smsm: modem@1 {
reg = <1>;
- interrupts = <0 26 IRQ_TYPE_EDGE_RISING>;
+ interrupts = ;
interrupt-controller;
#interrupt-cells = <2>;
@@ -372,7 +372,7 @@
adsp_smsm: adsp@2 {
reg = <2>;
- interrupts = <0 157 IRQ_TYPE_EDGE_RISING>;
+ interrupts = ;
interrupt-controller;
#interrupt-cells = <2>;
@@ -380,7 +380,7 @@
wcnss_smsm: wcnss@7 {
reg = <7>;
- interrupts = <0 144 IRQ_TYPE_EDGE_RISING>;
+ interrupts = ;
interrupt-controller;
#interrupt-cells = <2>;
@@ -445,50 +445,50 @@
frame@f9021000 {
frame-number = <0>;
- interrupts = <0 8 0x4>,
-<0 7 0x4>;
+ interrupts = ,
+;
reg = <0xf9021000 0x1000>,
<0xf9022000 0x1000>;
};
frame@f9023000 {
frame-number = <1>;
- interrupts = <0 9 0x4>;
+ interrupts = ;
reg = <0xf9023000 0x1000>;
status = "disabled";
};
frame@f9024000 {
frame-number = <2>;
- interrupts = <0 10 0x4>;
+ interrupts = ;
reg = <0xf9024000 0x1000>;
status = "disabled";
};
frame@f9025000 {
frame-number = <3>;
- interrupts = <0 11 0x4>;
+ interrupts = ;
reg = <0xf9025000 0x1000>;
status = "disabled";
};
frame@f9026000 {
frame-number = <4>;
- interrupts = <0 12 0x4>;
+ interrupts = ;
reg = <0xf9026000 0x1000>;
status = "disabled";
};
frame@f9027000 {
frame-number = <5>;
- interrupts = <0 13 0x4>;
+ interrupts = ;
reg = <0xf9027000 0x1000>;
status = "disabled";
};
frame@f9028000 {
frame-number = <6>;
- interrupts = <0 14 0x4>;
+ interrupts = ;
reg = <0xf9028000 0x1000>;
[PATCH 1/6] ARM: dts: qcom-msm8974: use named constant for interrupt type GIC_PPI
From: Frank Rowand
Cosmetic change of integer value "1" in the first field of the
"interrupts" property to the correct named constant.
Signed-off-by: Frank Rowand
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index d9019a49b292..f4f5e2df4c03 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -67,7 +67,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
- interrupts = <1 9 0xf04>;
+ interrupts = ;
CPU0: cpu@0 {
compatible = "qcom,krait";
@@ -214,7 +214,7 @@
cpu-pmu {
compatible = "qcom,krait-pmu";
- interrupts = <1 7 0xf04>;
+ interrupts = ;
};
clocks {
@@ -233,10 +233,10 @@
timer {
compatible = "arm,armv7-timer";
- interrupts = <1 2 0xf08>,
-<1 3 0xf08>,
-<1 4 0xf08>,
-<1 1 0xf08>;
+ interrupts = ,
+,
+,
+;
clock-frequency = <1920>;
};
--
Frank Rowand
[PATCH 0/6] ARM: dts: qcom-msm8974: change invalid flag IRQ NONE to valid value
From: Frank Rowand
A boot time warning of devicetree interrupts types set to the invalid
value of none was added by 83a86fbb5b56 ("irqchip/gic: Loudly complain
about the use of IRQ_TYPE_NONE"). This patch series fixes the
devicetree source to replace IRQ_TYPE_NONE with the appropriate
value.
Some cosmetic changes are made by several patches. The final patch
in the series replaces the IRQ_TYPE_NONE values with the proper
values.
The cosmetic changes are to change integer values in the third field
of the "interrupts" property to the correct named constant.
Bjorn suggested that I also change integer values in the first field
of the "interrupts" property to the correct named constant.
The series is split into several patches for ease of review. Each
cosmetic patch addresses a single named constant.
Frank Rowand (6):
ARM: dts: qcom-msm8974: use named constant for interrupt type GIC_PPI
ARM: dts: qcom-msm8974: use named constant for interrupt type GIC_SPI
ARM: dts: qcom-msm8974: use named constant for interrupt flag EDGE
RISING
ARM: dts: qcom-msm8974: use named constant for interrupt flag LEVEL
HIGH
ARM: dts: qcom-msm8974: use named constant for interrupt flag NONE
ARM: dts: qcom-msm8974: change invalid flag IRQ NONE to valid value
arch/arm/boot/dts/qcom-msm8974.dtsi | 72 +++--
1 file changed, 37 insertions(+), 35 deletions(-)
--
Frank Rowand
[PATCH 4/6] ARM: dts: qcom-msm8974: use named constant for interrupt flag LEVEL HIGH
From: Frank Rowand
Cosmetic change of integer value "4" in the third field of the
"interrupts" property to the correct named constant.
Signed-off-by: Frank Rowand
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 6273b6120be0..c7198900b426 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -445,50 +445,50 @@
frame@f9021000 {
frame-number = <0>;
- interrupts = ,
-;
+ interrupts = ,
+;
reg = <0xf9021000 0x1000>,
<0xf9022000 0x1000>;
};
frame@f9023000 {
frame-number = <1>;
- interrupts = ;
+ interrupts = ;
reg = <0xf9023000 0x1000>;
status = "disabled";
};
frame@f9024000 {
frame-number = <2>;
- interrupts = ;
+ interrupts = ;
reg = <0xf9024000 0x1000>;
status = "disabled";
};
frame@f9025000 {
frame-number = <3>;
- interrupts = ;
+ interrupts = ;
reg = <0xf9025000 0x1000>;
status = "disabled";
};
frame@f9026000 {
frame-number = <4>;
- interrupts = ;
+ interrupts = ;
reg = <0xf9026000 0x1000>;
status = "disabled";
};
frame@f9027000 {
frame-number = <5>;
- interrupts = ;
+ interrupts = ;
reg = <0xf9027000 0x1000>;
status = "disabled";
};
frame@f9028000 {
frame-number = <6>;
- interrupts = ;
+ interrupts = ;
reg = <0xf9028000 0x1000>;
status = "disabled";
};
--
Frank Rowand
[PATCH 5/6] ARM: dts: qcom-msm8974: use named constant for interrupt flag NONE
From: Frank Rowand
Cosmetic change of integer value "0" in the third field of the
"interrupts" property to the correct named constant.
Signed-off-by: Frank Rowand
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index c7198900b426..1e54113d6d9a 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -586,7 +586,7 @@
blsp1_uart1: serial@f991d000 {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0xf991d000 0x1000>;
- interrupts = ;
+ interrupts = ;
clocks = < GCC_BLSP1_UART1_APPS_CLK>, <
GCC_BLSP1_AHB_CLK>;
clock-names = "core", "iface";
status = "disabled";
@@ -595,7 +595,7 @@
blsp1_uart2: serial@f991e000 {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0xf991e000 0x1000>;
- interrupts = ;
+ interrupts = ;
clocks = < GCC_BLSP1_UART2_APPS_CLK>, <
GCC_BLSP1_AHB_CLK>;
clock-names = "core", "iface";
status = "disabled";
@@ -605,8 +605,8 @@
compatible = "qcom,sdhci-msm-v4";
reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
reg-names = "hc_mem", "core_mem";
- interrupts = ,
-;
+ interrupts = ,
+;
interrupt-names = "hc_irq", "pwr_irq";
clocks = < GCC_SDCC1_APPS_CLK>,
< GCC_SDCC1_AHB_CLK>,
@@ -633,8 +633,8 @@
compatible = "qcom,sdhci-msm-v4";
reg = <0xf98a4900 0x11c>, <0xf98a4000 0x800>;
reg-names = "hc_mem", "core_mem";
- interrupts = ,
-;
+ interrupts = ,
+;
interrupt-names = "hc_irq", "pwr_irq";
clocks = < GCC_SDCC2_APPS_CLK>,
< GCC_SDCC2_AHB_CLK>,
@@ -701,7 +701,7 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
- interrupts = ;
+ interrupts = ;
};
i2c@f9924000 {
@@ -746,7 +746,7 @@
<0xfc4cb000 0x1000>,
<0xfc4ca000 0x1000>;
interrupt-names = "periph_irq";
- interrupts = ;
+ interrupts = ;
qcom,ee = <0>;
qcom,channel = <0>;
#address-cells = <2>;
--
Frank Rowand
[PATCH 3/6] ARM: dts: qcom-msm8974: use named constant for interrupt flag EDGE RISING
From: Frank Rowand
Cosmetic change of integer value "1" in the third field of the
"interrupts" property to the correct named constant.
Signed-off-by: Frank Rowand
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index c09cc1232a6f..6273b6120be0 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -1056,7 +1056,7 @@
};
rpm {
- interrupts = ;
+ interrupts = ;
qcom,ipc = < 8 0>;
qcom,smd-edge = <15>;
--
Frank Rowand
[PATCH 4/6] ARM: dts: qcom-msm8974: use named constant for interrupt flag LEVEL HIGH
From: Frank Rowand
Cosmetic change of integer value "4" in the third field of the
"interrupts" property to the correct named constant.
Signed-off-by: Frank Rowand
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 6273b6120be0..c7198900b426 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -445,50 +445,50 @@
frame@f9021000 {
frame-number = <0>;
- interrupts = ,
-;
+ interrupts = ,
+;
reg = <0xf9021000 0x1000>,
<0xf9022000 0x1000>;
};
frame@f9023000 {
frame-number = <1>;
- interrupts = ;
+ interrupts = ;
reg = <0xf9023000 0x1000>;
status = "disabled";
};
frame@f9024000 {
frame-number = <2>;
- interrupts = ;
+ interrupts = ;
reg = <0xf9024000 0x1000>;
status = "disabled";
};
frame@f9025000 {
frame-number = <3>;
- interrupts = ;
+ interrupts = ;
reg = <0xf9025000 0x1000>;
status = "disabled";
};
frame@f9026000 {
frame-number = <4>;
- interrupts = ;
+ interrupts = ;
reg = <0xf9026000 0x1000>;
status = "disabled";
};
frame@f9027000 {
frame-number = <5>;
- interrupts = ;
+ interrupts = ;
reg = <0xf9027000 0x1000>;
status = "disabled";
};
frame@f9028000 {
frame-number = <6>;
- interrupts = ;
+ interrupts = ;
reg = <0xf9028000 0x1000>;
status = "disabled";
};
--
Frank Rowand
[PATCH 5/6] ARM: dts: qcom-msm8974: use named constant for interrupt flag NONE
From: Frank Rowand
Cosmetic change of integer value "0" in the third field of the
"interrupts" property to the correct named constant.
Signed-off-by: Frank Rowand
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index c7198900b426..1e54113d6d9a 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -586,7 +586,7 @@
blsp1_uart1: serial@f991d000 {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0xf991d000 0x1000>;
- interrupts = ;
+ interrupts = ;
clocks = < GCC_BLSP1_UART1_APPS_CLK>, <
GCC_BLSP1_AHB_CLK>;
clock-names = "core", "iface";
status = "disabled";
@@ -595,7 +595,7 @@
blsp1_uart2: serial@f991e000 {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0xf991e000 0x1000>;
- interrupts = ;
+ interrupts = ;
clocks = < GCC_BLSP1_UART2_APPS_CLK>, <
GCC_BLSP1_AHB_CLK>;
clock-names = "core", "iface";
status = "disabled";
@@ -605,8 +605,8 @@
compatible = "qcom,sdhci-msm-v4";
reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
reg-names = "hc_mem", "core_mem";
- interrupts = ,
-;
+ interrupts = ,
+;
interrupt-names = "hc_irq", "pwr_irq";
clocks = < GCC_SDCC1_APPS_CLK>,
< GCC_SDCC1_AHB_CLK>,
@@ -633,8 +633,8 @@
compatible = "qcom,sdhci-msm-v4";
reg = <0xf98a4900 0x11c>, <0xf98a4000 0x800>;
reg-names = "hc_mem", "core_mem";
- interrupts = ,
-;
+ interrupts = ,
+;
interrupt-names = "hc_irq", "pwr_irq";
clocks = < GCC_SDCC2_APPS_CLK>,
< GCC_SDCC2_AHB_CLK>,
@@ -701,7 +701,7 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
- interrupts = ;
+ interrupts = ;
};
i2c@f9924000 {
@@ -746,7 +746,7 @@
<0xfc4cb000 0x1000>,
<0xfc4ca000 0x1000>;
interrupt-names = "periph_irq";
- interrupts = ;
+ interrupts = ;
qcom,ee = <0>;
qcom,channel = <0>;
#address-cells = <2>;
--
Frank Rowand
[PATCH 3/6] ARM: dts: qcom-msm8974: use named constant for interrupt flag EDGE RISING
From: Frank Rowand
Cosmetic change of integer value "1" in the third field of the
"interrupts" property to the correct named constant.
Signed-off-by: Frank Rowand
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index c09cc1232a6f..6273b6120be0 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -1056,7 +1056,7 @@
};
rpm {
- interrupts = ;
+ interrupts = ;
qcom,ipc = < 8 0>;
qcom,smd-edge = <15>;
--
Frank Rowand
Re: [PATCH v2 6/8] perf/x86/intel/lbr: guest requesting KVM for lbr stack save/restore
On 09/07/2018 11:27 AM, Andi Kleen wrote: On Thu, Sep 06, 2018 at 07:30:54PM +0800, Wei Wang wrote: This patch adds an interface to enable a guest to request KVM to save and restore the lbr stack on vCPU context switching. KVM couldn't capture the info about whether the guest is actively using the lbr feature via the lbr enable bit in the debugctl MSR, because that control bit is frequently enabled and disabled by the guest, and in some csaes, it is disabled even when the guest is actively using the lbr feature. For example, perf_pmu_sched_task in the guest disables the bit before reading out the lbr stack. In this case, the bit is disabled though the guest is still using the lbr feature. So, a KVM-specific MSR, MSR_KVM_PV_LBR_CTRL, is used by the guest at a proper place to tell KVM if the LBR is actively in use or not. Basically, the lbr user callstack mode needs the lbr stack to be saved/restored on a context switching, so we set the ACTIVE bit of MSR_KVM_PV_LBR_CTRL only when the user callstack mode is used. The KVM hypervisor will add the lbr stack save/restore support on vCPU switching after the ACTIVE bit is set. PV is difficult because it requires changing all the users. It needs changes of the guest driver, but remains transparent to guest user applications (e.g. the perf tool). Btw, we tested it, and it works in guest as good as on the native linux. This was thought of as the hardest part of this work. Let me just clarify it a little bit: The fundamental function we want to achieve is #1 when the vCPU is actively using the LBR feature, save/restore the lbr stack when the vCPU is scheduled out/in; #2 when the vCPU is NOT actively using the LBR feature, DON'T save/restore the lbr stack when the vCPU is scheduled out/in; The key problem we need to solve is: how does the host know if the guest is actively using the lbr feature or not? Maybe a better approach would be a lazy restore of the LBRs: Don't restore the LBRs on context switch, but set the LBR MSRs to intercept. Then on the first access restore the LBRs and allow direct access to the MSRs again. Also when the LBRs haven't been set to direct access the state doesn't need to be saved. This could achieve the above #1, but how would it solve #2 above? That is, after the guest uses the lbr feature for a while, the lbr stack has been passed through, then the guest doesn't use lbr any more, but the vCPU will still save/restore on switching? (Host cannot know that the guest is not using lbr by the debugctl[0], the commit log above has some explanations about this) Best, Wei
Re: [PATCH v2 6/8] perf/x86/intel/lbr: guest requesting KVM for lbr stack save/restore
On 09/07/2018 11:27 AM, Andi Kleen wrote: On Thu, Sep 06, 2018 at 07:30:54PM +0800, Wei Wang wrote: This patch adds an interface to enable a guest to request KVM to save and restore the lbr stack on vCPU context switching. KVM couldn't capture the info about whether the guest is actively using the lbr feature via the lbr enable bit in the debugctl MSR, because that control bit is frequently enabled and disabled by the guest, and in some csaes, it is disabled even when the guest is actively using the lbr feature. For example, perf_pmu_sched_task in the guest disables the bit before reading out the lbr stack. In this case, the bit is disabled though the guest is still using the lbr feature. So, a KVM-specific MSR, MSR_KVM_PV_LBR_CTRL, is used by the guest at a proper place to tell KVM if the LBR is actively in use or not. Basically, the lbr user callstack mode needs the lbr stack to be saved/restored on a context switching, so we set the ACTIVE bit of MSR_KVM_PV_LBR_CTRL only when the user callstack mode is used. The KVM hypervisor will add the lbr stack save/restore support on vCPU switching after the ACTIVE bit is set. PV is difficult because it requires changing all the users. It needs changes of the guest driver, but remains transparent to guest user applications (e.g. the perf tool). Btw, we tested it, and it works in guest as good as on the native linux. This was thought of as the hardest part of this work. Let me just clarify it a little bit: The fundamental function we want to achieve is #1 when the vCPU is actively using the LBR feature, save/restore the lbr stack when the vCPU is scheduled out/in; #2 when the vCPU is NOT actively using the LBR feature, DON'T save/restore the lbr stack when the vCPU is scheduled out/in; The key problem we need to solve is: how does the host know if the guest is actively using the lbr feature or not? Maybe a better approach would be a lazy restore of the LBRs: Don't restore the LBRs on context switch, but set the LBR MSRs to intercept. Then on the first access restore the LBRs and allow direct access to the MSRs again. Also when the LBRs haven't been set to direct access the state doesn't need to be saved. This could achieve the above #1, but how would it solve #2 above? That is, after the guest uses the lbr feature for a while, the lbr stack has been passed through, then the guest doesn't use lbr any more, but the vCPU will still save/restore on switching? (Host cannot know that the guest is not using lbr by the debugctl[0], the commit log above has some explanations about this) Best, Wei
Re: [PATCH V3 17/26] csky: Misc headers
On Thu, Sep 06, 2018 at 04:16:30PM +0200, Arnd Bergmann wrote:
> On Wed, Sep 5, 2018 at 2:08 PM Guo Ren wrote:
>
> > diff --git a/arch/csky/boot/dts/qemu.dts b/arch/csky/boot/dts/qemu.dts
> > new file mode 100644
> > index 000..d36e4cd
> > --- /dev/null
> > +++ b/arch/csky/boot/dts/qemu.dts
> > @@ -0,0 +1,77 @@
> > +/dts-v1/;
> > +/ {
> > + compatible = "csky,qemu";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + interrupt-parent = <>;
>
> Ideally, qemu would supply a dtb file that matches the current configuration,
> as we do for instance on the ARM 'virt' machine. This allows you
> much more flexibility in running all kinds of options, as well as extending
> qemu later with new features.
So, I should remove qemu.dts in next version patch?
> > +
> > + timer0: timer@0xd000 {
> > + compatible = "snps,dw-apb-timer";
> > + reg = <0xd000 0x1000>;
> > + clocks = <_apb>;
> > + clock-names = "timer";
> > + interrupts = <1>;
> > + };
> > +
> > + timer1: timer@0xd014 {
>
> Drop the leading '0x' in the unit-address here (in all devices)
Ok
Re: [PATCH V3 17/26] csky: Misc headers
On Thu, Sep 06, 2018 at 04:16:30PM +0200, Arnd Bergmann wrote:
> On Wed, Sep 5, 2018 at 2:08 PM Guo Ren wrote:
>
> > diff --git a/arch/csky/boot/dts/qemu.dts b/arch/csky/boot/dts/qemu.dts
> > new file mode 100644
> > index 000..d36e4cd
> > --- /dev/null
> > +++ b/arch/csky/boot/dts/qemu.dts
> > @@ -0,0 +1,77 @@
> > +/dts-v1/;
> > +/ {
> > + compatible = "csky,qemu";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + interrupt-parent = <>;
>
> Ideally, qemu would supply a dtb file that matches the current configuration,
> as we do for instance on the ARM 'virt' machine. This allows you
> much more flexibility in running all kinds of options, as well as extending
> qemu later with new features.
So, I should remove qemu.dts in next version patch?
> > +
> > + timer0: timer@0xd000 {
> > + compatible = "snps,dw-apb-timer";
> > + reg = <0xd000 0x1000>;
> > + clocks = <_apb>;
> > + clock-names = "timer";
> > + interrupts = <1>;
> > + };
> > +
> > + timer1: timer@0xd014 {
>
> Drop the leading '0x' in the unit-address here (in all devices)
Ok
Re: [PATCH V3 13/26] csky: Library functions
On Thu, Sep 06, 2018 at 05:50:02PM +0200, Geert Uytterhoeven wrote: > On Thu, Sep 6, 2018 at 4:25 PM Arnd Bergmann wrote: > > On Wed, Sep 5, 2018 at 2:08 PM Guo Ren wrote: > > > --- /dev/null > > > +++ b/arch/csky/abiv1/memset.c > > > @@ -0,0 +1,38 @@ > > > + if ((long)d & 0x3) > > > + while (l--) *d++ = ch; > > while ((uintptr_t)d & 0x3) && l--) > *d++ =ch; > > and remove the else below? Ok > > > + *(((long *)d)+3) = tmp; > > s/long/u32/ Ok Thx Guo Ren
Re: [PATCH V3 13/26] csky: Library functions
On Thu, Sep 06, 2018 at 05:50:02PM +0200, Geert Uytterhoeven wrote: > On Thu, Sep 6, 2018 at 4:25 PM Arnd Bergmann wrote: > > On Wed, Sep 5, 2018 at 2:08 PM Guo Ren wrote: > > > --- /dev/null > > > +++ b/arch/csky/abiv1/memset.c > > > @@ -0,0 +1,38 @@ > > > + if ((long)d & 0x3) > > > + while (l--) *d++ = ch; > > while ((uintptr_t)d & 0x3) && l--) > *d++ =ch; > > and remove the else below? Ok > > > + *(((long *)d)+3) = tmp; > > s/long/u32/ Ok Thx Guo Ren
linux-next: Tree for Sep 7
Hi all, Changes since 20180906: Dropped trees: xarray, ida (temporarily) The vfs tree still had its build failures for which I disabled some sample programs. The net-next tree still had its build failure for which I reverted a commit. The bfp-next tree gained a conflict against the above revert and a build failure so I used the version from next-20180906. The kspp tree gained a conflict against the tip tree. Non-merge commits (relative to Linus' tree): 2218 2668 files changed, 77895 insertions(+), 46956 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 287 trees (counting Linus' and 66 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (ca16eb342ebe Merge tag 'for-linus-20180906' of git://git.kernel.dk/linux-block) Merging fixes/master (72358c0b59b7 linux-next: build warnings from the build of Linus' tree) Merging kbuild-current/fixes (914b087ff9e0 kbuild: make missing $DEPMOD a Warning instead of an Error) Merging arc-current/for-curr (dd45210b6dd4 ARC: don't check for HIGHMEM pages in arch_dma_alloc) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (f52bb98f5ade arm64: mm: always enable CONFIG_HOLES_IN_ZONE) Merging m68k-current/for-linus (0986b16ab49b m68k/mac: Use correct PMU response format) Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global invalidations when removing copro) Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (6da410d97ffa Merge tag 'mlx5e-fixes-2018-09-05' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux) Merging bpf/master (28619527b8a7 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging ipsec/master (782710e333a5 xfrm: reset crypto_done when iterating over multiple input xfrms) Merging netfilter/master (7acfda539c0b netfilter: nf_tables: release chain in flushing set) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (5b394b2ddf03 Linux 4.19-rc1) Merging mac80211/master (6eae4a6c2be3 mac80211: fix pending queue hang due to TX_DROP) Merging rdma-fixes/for-rc (08e74be10305 RDMA/uverbs: Fix error cleanup path of ib_uverbs_add_one()) Merging sound-current/for-linus (f7c50fa636f7 ALSA: hda: Fix several mismatch for register mask and value) Merging sound-asoc-fixes/for-linus (4f3184ed5e20 Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (5b394b2ddf03 Linux 4.19-rc1) Merging regulator-fixes/for-linus (25be6316a30a Merge branch 'regulator-4.19' into regulator-linus) Merging spi-fixes/for-linus (4cd5d1d385f4 Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (3a2ddc1af79c MAINTAINERS: Add entries for PPC64 RPA PCI hotplug drivers) Merging driver-core.current/driver-core-linus (57361846b52b Linux 4.19-rc2) Merging tty.current/tty-linus (57361846b52b Linux 4.19-rc2) Merging usb.current/usb-linus (bfa150f37f80 Merge tag 'fixes-for-v4.19-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus) Merging us
linux-next: Tree for Sep 7
Hi all, Changes since 20180906: Dropped trees: xarray, ida (temporarily) The vfs tree still had its build failures for which I disabled some sample programs. The net-next tree still had its build failure for which I reverted a commit. The bfp-next tree gained a conflict against the above revert and a build failure so I used the version from next-20180906. The kspp tree gained a conflict against the tip tree. Non-merge commits (relative to Linus' tree): 2218 2668 files changed, 77895 insertions(+), 46956 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 287 trees (counting Linus' and 66 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (ca16eb342ebe Merge tag 'for-linus-20180906' of git://git.kernel.dk/linux-block) Merging fixes/master (72358c0b59b7 linux-next: build warnings from the build of Linus' tree) Merging kbuild-current/fixes (914b087ff9e0 kbuild: make missing $DEPMOD a Warning instead of an Error) Merging arc-current/for-curr (dd45210b6dd4 ARC: don't check for HIGHMEM pages in arch_dma_alloc) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (f52bb98f5ade arm64: mm: always enable CONFIG_HOLES_IN_ZONE) Merging m68k-current/for-linus (0986b16ab49b m68k/mac: Use correct PMU response format) Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global invalidations when removing copro) Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (6da410d97ffa Merge tag 'mlx5e-fixes-2018-09-05' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux) Merging bpf/master (28619527b8a7 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging ipsec/master (782710e333a5 xfrm: reset crypto_done when iterating over multiple input xfrms) Merging netfilter/master (7acfda539c0b netfilter: nf_tables: release chain in flushing set) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (5b394b2ddf03 Linux 4.19-rc1) Merging mac80211/master (6eae4a6c2be3 mac80211: fix pending queue hang due to TX_DROP) Merging rdma-fixes/for-rc (08e74be10305 RDMA/uverbs: Fix error cleanup path of ib_uverbs_add_one()) Merging sound-current/for-linus (f7c50fa636f7 ALSA: hda: Fix several mismatch for register mask and value) Merging sound-asoc-fixes/for-linus (4f3184ed5e20 Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (5b394b2ddf03 Linux 4.19-rc1) Merging regulator-fixes/for-linus (25be6316a30a Merge branch 'regulator-4.19' into regulator-linus) Merging spi-fixes/for-linus (4cd5d1d385f4 Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (3a2ddc1af79c MAINTAINERS: Add entries for PPC64 RPA PCI hotplug drivers) Merging driver-core.current/driver-core-linus (57361846b52b Linux 4.19-rc2) Merging tty.current/tty-linus (57361846b52b Linux 4.19-rc2) Merging usb.current/usb-linus (bfa150f37f80 Merge tag 'fixes-for-v4.19-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus) Merging us
Re: [PATCH V3 13/26] csky: Library functions
On Thu, Sep 06, 2018 at 04:24:59PM +0200, Arnd Bergmann wrote:
> On Wed, Sep 5, 2018 at 2:08 PM Guo Ren wrote:
>
> > --- /dev/null
> > +++ b/arch/csky/abiv1/memset.c
> > @@ -0,0 +1,38 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> > +#include
> > +
> > +void *memset(void *dest, int c, size_t l)
> > +{
> > + char *d = dest;
> > + int ch = c;
> > + int tmp;
> > +
> > + if ((long)d & 0x3)
> > + while (l--) *d++ = ch;
> > + else {
> > + ch &= 0xff;
> > + tmp = (ch | ch << 8 | ch << 16 | ch << 24);
> > +
> > + while (l >= 16) {
> > + *(((long *)d)) = tmp;
> > + *(((long *)d)+1) = tmp;
> > + *(((long *)d)+2) = tmp;
> > + *(((long *)d)+3) = tmp;
> > + l -= 16;
> > + d += 16;
> > + }
> > +
> > + while (l > 3) {
> > + *(((long *)d)) = tmp;
> > + d = d + 4;
> > + l -= 4;
> > + }
> > +
> > + while (l) {
> > + *d++ = ch;
> > + l--;
> > + }
> > + }
> > + return dest;
> > +}
>
> I see that we have a trivial memset() implementation in lib/string.c, but
> yours
> seems to be better optimized. Where did you get it from?
We write it for our ck610 to improve the performance, but I think a lot
of other arch done it in asm style.
> Is this a version
> that works particularly well on C-Sky, or is this a generic optimized memset
> that others could use as well?
We only test it on C-SKY, but I think it will also work better on other
arch CPU than current lib/string.c memset implement.
I see that in lib/string.c:
void *memset(void *s, int c, size_t count)
{
char *xs = s;
while (count--)
*xs++ = c;
return s;
}
The most problem is "char *xs;" and it will cause "st.b" in asm.
"st.b" is very slow.
Our key improvement is:
> > + *(((long *)d)) = tmp;
> > + *(((long *)d)+1) = tmp;
> > + *(((long *)d)+2) = tmp;
> > + *(((long *)d)+3) = tmp;
It will cause SOC AXI burst transfer.
> In the latter case, we could add it to
> lib/string.c and let architectures select it in place of the triivial version.
Good idea.
Guo Ren
Re: [PATCH V3 13/26] csky: Library functions
On Thu, Sep 06, 2018 at 04:24:59PM +0200, Arnd Bergmann wrote:
> On Wed, Sep 5, 2018 at 2:08 PM Guo Ren wrote:
>
> > --- /dev/null
> > +++ b/arch/csky/abiv1/memset.c
> > @@ -0,0 +1,38 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> > +#include
> > +
> > +void *memset(void *dest, int c, size_t l)
> > +{
> > + char *d = dest;
> > + int ch = c;
> > + int tmp;
> > +
> > + if ((long)d & 0x3)
> > + while (l--) *d++ = ch;
> > + else {
> > + ch &= 0xff;
> > + tmp = (ch | ch << 8 | ch << 16 | ch << 24);
> > +
> > + while (l >= 16) {
> > + *(((long *)d)) = tmp;
> > + *(((long *)d)+1) = tmp;
> > + *(((long *)d)+2) = tmp;
> > + *(((long *)d)+3) = tmp;
> > + l -= 16;
> > + d += 16;
> > + }
> > +
> > + while (l > 3) {
> > + *(((long *)d)) = tmp;
> > + d = d + 4;
> > + l -= 4;
> > + }
> > +
> > + while (l) {
> > + *d++ = ch;
> > + l--;
> > + }
> > + }
> > + return dest;
> > +}
>
> I see that we have a trivial memset() implementation in lib/string.c, but
> yours
> seems to be better optimized. Where did you get it from?
We write it for our ck610 to improve the performance, but I think a lot
of other arch done it in asm style.
> Is this a version
> that works particularly well on C-Sky, or is this a generic optimized memset
> that others could use as well?
We only test it on C-SKY, but I think it will also work better on other
arch CPU than current lib/string.c memset implement.
I see that in lib/string.c:
void *memset(void *s, int c, size_t count)
{
char *xs = s;
while (count--)
*xs++ = c;
return s;
}
The most problem is "char *xs;" and it will cause "st.b" in asm.
"st.b" is very slow.
Our key improvement is:
> > + *(((long *)d)) = tmp;
> > + *(((long *)d)+1) = tmp;
> > + *(((long *)d)+2) = tmp;
> > + *(((long *)d)+3) = tmp;
It will cause SOC AXI burst transfer.
> In the latter case, we could add it to
> lib/string.c and let architectures select it in place of the triivial version.
Good idea.
Guo Ren
[LKP] [tty] 0b4f83d510: INFO:task_blocked_for_more_than#seconds
FYI, we noticed the following commit (built with gcc-7):
commit: 0b4f83d510f6fef6bb9da25f122c8d733d50516f ("[PATCH 2/4] tty: Hold
tty_ldisc_lock() during tty_reopen()")
url:
https://github.com/0day-ci/linux/commits/Dmitry-Safonov/tty-Hold-write-ldisc-sem-in-tty_reopen/20180829-165618
base: https://git.kernel.org/cgit/linux/kernel/git/gregkh/tty.git tty-testing
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -m 256M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+--+++
| | 58dd163974 | 0b4f83d510 |
+--+++
| boot_successes | 14 | 4 |
| boot_failures| 0 | 6 |
| INFO:task_blocked_for_more_than#seconds | 0 | 6 |
| Kernel_panic-not_syncing:hung_task:blocked_tasks | 0 | 6 |
+--+++
[ 244.816801] INFO: task validate_data:655 blocked for more than 120 seconds.
[ 244.818833] Not tainted 4.18.0-11684-g0b4f83d #1
[ 244.820028] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 244.826965] validate_data D0 655623 0x2002
[ 244.828279] Call Trace:
[ 244.828958] ? __schedule+0x843/0x950
[ 244.830173] ? __ldsem_down_read_nested+0x1c4/0x3b0
[ 244.834903] schedule+0x31/0x70
[ 244.835665] schedule_timeout+0x34/0x760
[ 244.836613] ? ftrace_likely_update+0x35/0x60
[ 244.837683] ? __ldsem_down_read_nested+0x1c4/0x3b0
[ 244.838818] ? ftrace_likely_update+0x35/0x60
[ 244.840127] ? ftrace_likely_update+0x35/0x60
[ 244.845947] ? __ldsem_down_read_nested+0x1c4/0x3b0
[ 244.847882] __ldsem_down_read_nested+0x23a/0x3b0
[ 244.849886] ? tty_ldisc_ref_wait+0x25/0x50
[ 244.853807] tty_ldisc_ref_wait+0x25/0x50
[ 244.854946] tty_compat_ioctl+0x8a/0x120
[ 244.855928] ? this_tty+0x80/0x80
[ 244.856742] __ia32_compat_sys_ioctl+0xc28/0x1ce0
[ 244.857981] do_int80_syscall_32+0x1d2/0x5f0
[ 244.859003] entry_INT80_compat+0x88/0xa0
[ 244.859972] INFO: task dnsmasq:668 blocked for more than 120 seconds.
[ 244.868315] Not tainted 4.18.0-11684-g0b4f83d #1
[ 244.869583] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 244.871744] dnsmasq D0 668 1 0x2002
[ 244.873063] Call Trace:
[ 244.873697] ? __schedule+0x843/0x950
[ 244.874572] ? __ldsem_down_read_nested+0x1c4/0x3b0
[ 244.875725] schedule+0x31/0x70
[ 244.876576] schedule_timeout+0x34/0x760
[ 244.877573] ? ftrace_likely_update+0x35/0x60
[ 244.878660] ? __ldsem_down_read_nested+0x1c4/0x3b0
[ 244.879872] ? ftrace_likely_update+0x35/0x60
[ 244.890522] ? ftrace_likely_update+0x35/0x60
[ 244.891572] ? __ldsem_down_read_nested+0x1c4/0x3b0
[ 244.892746] __ldsem_down_read_nested+0x23a/0x3b0
[ 244.893861] ? tty_ldisc_ref_wait+0x25/0x50
[ 244.894841] tty_ldisc_ref_wait+0x25/0x50
[ 244.895911] tty_compat_ioctl+0x8a/0x120
[ 244.896916] ? this_tty+0x80/0x80
[ 244.897717] __ia32_compat_sys_ioctl+0xc28/0x1ce0
[ 244.898821] do_int80_syscall_32+0x1d2/0x5f0
[ 244.899830] entry_INT80_compat+0x88/0xa0
[ 244.909466] INFO: task dropbear:734 blocked for more than 120 seconds.
[ 244.911173] Not tainted 4.18.0-11684-g0b4f83d #1
[ 244.912394] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 244.914176] dropbearD0 734 1 0x2002
[ 244.915446] Call Trace:
[ 244.916068] ? __schedule+0x843/0x950
[ 244.916945] ? __ldsem_down_read_nested+0x1c4/0x3b0
[ 244.918076] schedule+0x31/0x70
[ 244.918832] schedule_timeout+0x34/0x760
[ 244.919781] ? ftrace_likely_update+0x35/0x60
[ 244.921104] ? __ldsem_down_read_nested+0x1c4/0x3b0
[ 244.922304] ? ftrace_likely_update+0x35/0x60
[ 244.923347] ? ftrace_likely_update+0x35/0x60
[ 244.924369] ? __ldsem_down_read_nested+0x1c4/0x3b0
[ 244.925496] __ldsem_down_read_nested+0x23a/0x3b0
[ 244.926598] ? tty_ldisc_ref_wait+0x25/0x50
[ 244.927578] tty_ldisc_ref_wait+0x25/0x50
[ 244.928526] tty_compat_ioctl+0x8a/0x120
[ 244.929449] ? this_tty+0x80/0x80
[ 244.930240] __ia32_compat_sys_ioctl+0xc28/0x1ce0
[ 244.940083] do_int80_syscall_32+0x1d2/0x5f0
[ 244.941310] entry_INT80_compat+0x88/0xa0
[ 244.944070]
[ 244.944070] Showing all locks held in the system:
[ 244.945558] 1 lock held by khungtaskd/18:
[ 244.946495] #0: (ptrval) (rcu_read_lock){}, at:
debug_show_all_locks+0x16/0x190
[ 244.948503] 2 locks held by askfirst/235:
[ 244.949439] #0: (ptrval) (>ldisc_sem){},
[LKP] [tty] 0b4f83d510: INFO:task_blocked_for_more_than#seconds
FYI, we noticed the following commit (built with gcc-7):
commit: 0b4f83d510f6fef6bb9da25f122c8d733d50516f ("[PATCH 2/4] tty: Hold
tty_ldisc_lock() during tty_reopen()")
url:
https://github.com/0day-ci/linux/commits/Dmitry-Safonov/tty-Hold-write-ldisc-sem-in-tty_reopen/20180829-165618
base: https://git.kernel.org/cgit/linux/kernel/git/gregkh/tty.git tty-testing
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -m 256M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+--+++
| | 58dd163974 | 0b4f83d510 |
+--+++
| boot_successes | 14 | 4 |
| boot_failures| 0 | 6 |
| INFO:task_blocked_for_more_than#seconds | 0 | 6 |
| Kernel_panic-not_syncing:hung_task:blocked_tasks | 0 | 6 |
+--+++
[ 244.816801] INFO: task validate_data:655 blocked for more than 120 seconds.
[ 244.818833] Not tainted 4.18.0-11684-g0b4f83d #1
[ 244.820028] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 244.826965] validate_data D0 655623 0x2002
[ 244.828279] Call Trace:
[ 244.828958] ? __schedule+0x843/0x950
[ 244.830173] ? __ldsem_down_read_nested+0x1c4/0x3b0
[ 244.834903] schedule+0x31/0x70
[ 244.835665] schedule_timeout+0x34/0x760
[ 244.836613] ? ftrace_likely_update+0x35/0x60
[ 244.837683] ? __ldsem_down_read_nested+0x1c4/0x3b0
[ 244.838818] ? ftrace_likely_update+0x35/0x60
[ 244.840127] ? ftrace_likely_update+0x35/0x60
[ 244.845947] ? __ldsem_down_read_nested+0x1c4/0x3b0
[ 244.847882] __ldsem_down_read_nested+0x23a/0x3b0
[ 244.849886] ? tty_ldisc_ref_wait+0x25/0x50
[ 244.853807] tty_ldisc_ref_wait+0x25/0x50
[ 244.854946] tty_compat_ioctl+0x8a/0x120
[ 244.855928] ? this_tty+0x80/0x80
[ 244.856742] __ia32_compat_sys_ioctl+0xc28/0x1ce0
[ 244.857981] do_int80_syscall_32+0x1d2/0x5f0
[ 244.859003] entry_INT80_compat+0x88/0xa0
[ 244.859972] INFO: task dnsmasq:668 blocked for more than 120 seconds.
[ 244.868315] Not tainted 4.18.0-11684-g0b4f83d #1
[ 244.869583] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 244.871744] dnsmasq D0 668 1 0x2002
[ 244.873063] Call Trace:
[ 244.873697] ? __schedule+0x843/0x950
[ 244.874572] ? __ldsem_down_read_nested+0x1c4/0x3b0
[ 244.875725] schedule+0x31/0x70
[ 244.876576] schedule_timeout+0x34/0x760
[ 244.877573] ? ftrace_likely_update+0x35/0x60
[ 244.878660] ? __ldsem_down_read_nested+0x1c4/0x3b0
[ 244.879872] ? ftrace_likely_update+0x35/0x60
[ 244.890522] ? ftrace_likely_update+0x35/0x60
[ 244.891572] ? __ldsem_down_read_nested+0x1c4/0x3b0
[ 244.892746] __ldsem_down_read_nested+0x23a/0x3b0
[ 244.893861] ? tty_ldisc_ref_wait+0x25/0x50
[ 244.894841] tty_ldisc_ref_wait+0x25/0x50
[ 244.895911] tty_compat_ioctl+0x8a/0x120
[ 244.896916] ? this_tty+0x80/0x80
[ 244.897717] __ia32_compat_sys_ioctl+0xc28/0x1ce0
[ 244.898821] do_int80_syscall_32+0x1d2/0x5f0
[ 244.899830] entry_INT80_compat+0x88/0xa0
[ 244.909466] INFO: task dropbear:734 blocked for more than 120 seconds.
[ 244.911173] Not tainted 4.18.0-11684-g0b4f83d #1
[ 244.912394] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 244.914176] dropbearD0 734 1 0x2002
[ 244.915446] Call Trace:
[ 244.916068] ? __schedule+0x843/0x950
[ 244.916945] ? __ldsem_down_read_nested+0x1c4/0x3b0
[ 244.918076] schedule+0x31/0x70
[ 244.918832] schedule_timeout+0x34/0x760
[ 244.919781] ? ftrace_likely_update+0x35/0x60
[ 244.921104] ? __ldsem_down_read_nested+0x1c4/0x3b0
[ 244.922304] ? ftrace_likely_update+0x35/0x60
[ 244.923347] ? ftrace_likely_update+0x35/0x60
[ 244.924369] ? __ldsem_down_read_nested+0x1c4/0x3b0
[ 244.925496] __ldsem_down_read_nested+0x23a/0x3b0
[ 244.926598] ? tty_ldisc_ref_wait+0x25/0x50
[ 244.927578] tty_ldisc_ref_wait+0x25/0x50
[ 244.928526] tty_compat_ioctl+0x8a/0x120
[ 244.929449] ? this_tty+0x80/0x80
[ 244.930240] __ia32_compat_sys_ioctl+0xc28/0x1ce0
[ 244.940083] do_int80_syscall_32+0x1d2/0x5f0
[ 244.941310] entry_INT80_compat+0x88/0xa0
[ 244.944070]
[ 244.944070] Showing all locks held in the system:
[ 244.945558] 1 lock held by khungtaskd/18:
[ 244.946495] #0: (ptrval) (rcu_read_lock){}, at:
debug_show_all_locks+0x16/0x190
[ 244.948503] 2 locks held by askfirst/235:
[ 244.949439] #0: (ptrval) (>ldisc_sem){},
Re: [PATCH] vme: remove unneeded kfree
On Thu, Sep 6, 2018 at 1:51 AM Ding Xiang
wrote:
>
> put_device will call vme_dev_release to free vdev, kfree is
> unnecessary here.
That does seem to be the case. I think "unnecessary" is overly kind,
it does seem to be a double free.
Looks like the issue was introduced back in 2013 by commit
def1820d25fa ("vme: add missing put_device() after device_register()
fails").
It seems you should *either* kfree() the vdev, _or_ do put_device(),
but doing both seems wrong.
I presume the device_register() has never failed, and this being
vme-only I'm guessing there isn't a vibrant testing community.
Greg?
Linus
Re: [PATCH] vme: remove unneeded kfree
On Thu, Sep 6, 2018 at 1:51 AM Ding Xiang
wrote:
>
> put_device will call vme_dev_release to free vdev, kfree is
> unnecessary here.
That does seem to be the case. I think "unnecessary" is overly kind,
it does seem to be a double free.
Looks like the issue was introduced back in 2013 by commit
def1820d25fa ("vme: add missing put_device() after device_register()
fails").
It seems you should *either* kfree() the vdev, _or_ do put_device(),
but doing both seems wrong.
I presume the device_register() has never failed, and this being
vme-only I'm guessing there isn't a vibrant testing community.
Greg?
Linus
Re: [PATCH v4 3/4] drivers: edac: Add EDAC driver support for QCOM SoCs
On 9/7/2018 4:01 AM, vnkgu...@codeaurora.org wrote:
On 2018-09-06 05:38, Sai Prakash Ranjan wrote:
On 9/5/2018 4:52 AM, Venkata Narendra Kumar Gutta wrote:
+static const struct of_device_id qcom_llcc_edac_match_table[] = {
+ { .compatible = "qcom,llcc-edac" },
+ { },
+};
+
Hi Venkata,
Devicetree binding for llcc is updated, but what about this compatible?
Does it need documentation too? I was not sure if I should add
documentation for this or not!
It does not require a separate binding, what I meant was to add this
compatible in the llcc binding itself, maybe as a subnode if it is correct.
Re: [PATCH v4 3/4] drivers: edac: Add EDAC driver support for QCOM SoCs
On 9/7/2018 4:01 AM, vnkgu...@codeaurora.org wrote:
On 2018-09-06 05:38, Sai Prakash Ranjan wrote:
On 9/5/2018 4:52 AM, Venkata Narendra Kumar Gutta wrote:
+static const struct of_device_id qcom_llcc_edac_match_table[] = {
+ { .compatible = "qcom,llcc-edac" },
+ { },
+};
+
Hi Venkata,
Devicetree binding for llcc is updated, but what about this compatible?
Does it need documentation too? I was not sure if I should add
documentation for this or not!
It does not require a separate binding, what I meant was to add this
compatible in the llcc binding itself, maybe as a subnode if it is correct.
[PATCH] 9p locks: add mount option for lock retry interval
From: Dinu-Razvan Chis-Serban
The default P9_LOCK_TIMEOUT can be too long for some users exporting
a local file system to a guest VM (30s), make this configurable at
mount time.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195727
Signed-off-by: Dinu-Razvan Chis-Serban
Signed-off-by: Dominique Martinet
---
This patch also has been in bugzilla for a bit over a year, and looks
fine to me.
I'll get it in linux-next around next week at the same time as the other
bz patch I sent recently after some testing, and will see with Razvan
(not sure how to call you in "short" version?) on how we fix comments
to it but can take are of that if required.
fs/9p/v9fs.c | 21 +
fs/9p/v9fs.h | 1 +
fs/9p/vfs_file.c | 5 -
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/fs/9p/v9fs.c b/fs/9p/v9fs.c
index 89bac3d2f05b..619128b55837 100644
--- a/fs/9p/v9fs.c
+++ b/fs/9p/v9fs.c
@@ -61,6 +61,8 @@ enum {
Opt_cache_loose, Opt_fscache, Opt_mmap,
/* Access options */
Opt_access, Opt_posixacl,
+ /* Lock timeout option */
+ Opt_locktimeout,
/* Error token */
Opt_err
};
@@ -80,6 +82,7 @@ static const match_table_t tokens = {
{Opt_cachetag, "cachetag=%s"},
{Opt_access, "access=%s"},
{Opt_posixacl, "posixacl"},
+ {Opt_locktimeout, "locktimeout=%u"},
{Opt_err, NULL}
};
@@ -187,6 +190,7 @@ static int v9fs_parse_options(struct v9fs_session_info
*v9ses, char *opts)
#ifdef CONFIG_9P_FSCACHE
v9ses->cachetag = NULL;
#endif
+ v9ses->session_lock_timeout = P9_LOCK_TIMEOUT;
if (!opts)
return 0;
@@ -359,6 +363,23 @@ static int v9fs_parse_options(struct v9fs_session_info
*v9ses, char *opts)
#endif
break;
+ case Opt_locktimeout:
+ r = match_int([0], );
+ if (r < 0) {
+ p9_debug(P9_DEBUG_ERROR,
+"integer field, but no integer?\n");
+ ret = r;
+ continue;
+ }
+ if (option < 1) {
+ p9_debug(P9_DEBUG_ERROR,
+"locktimeout must be a greater than
zero integer.\n");
+ ret = -EINVAL;
+ continue;
+ }
+ v9ses->session_lock_timeout = (long)option * HZ;
+ break;
+
default:
continue;
}
diff --git a/fs/9p/v9fs.h b/fs/9p/v9fs.h
index 982e017acadb..129e5243a6bf 100644
--- a/fs/9p/v9fs.h
+++ b/fs/9p/v9fs.h
@@ -116,6 +116,7 @@ struct v9fs_session_info {
struct p9_client *clnt; /* 9p client */
struct list_head slist; /* list of sessions registered with v9fs */
struct rw_semaphore rename_sem;
+ long session_lock_timeout; /* retry interval for blocking locks */
};
/* cache_validity flags */
diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c
index 374bc1c72048..c608b98c0188 100644
--- a/fs/9p/vfs_file.c
+++ b/fs/9p/vfs_file.c
@@ -154,6 +154,7 @@ static int v9fs_file_do_lock(struct file *filp, int cmd,
struct file_lock *fl)
uint8_t status = P9_LOCK_ERROR;
int res = 0;
unsigned char fl_type;
+ struct v9fs_session_info *v9ses;
fid = filp->private_data;
BUG_ON(fid == NULL);
@@ -189,6 +190,8 @@ static int v9fs_file_do_lock(struct file *filp, int cmd,
struct file_lock *fl)
if (IS_SETLKW(cmd))
flock.flags = P9_LOCK_FLAGS_BLOCK;
+ v9ses = v9fs_inode2v9ses(file_inode(filp));
+
/*
* if its a blocked request and we get P9_LOCK_BLOCKED as the status
* for lock request, keep on trying
@@ -202,7 +205,7 @@ static int v9fs_file_do_lock(struct file *filp, int cmd,
struct file_lock *fl)
break;
if (status == P9_LOCK_BLOCKED && !IS_SETLKW(cmd))
break;
- if (schedule_timeout_interruptible(P9_LOCK_TIMEOUT) != 0)
+ if (schedule_timeout_interruptible(v9ses->session_lock_timeout)
!= 0)
break;
}
--
2.17.1
[PATCH] 9p locks: add mount option for lock retry interval
From: Dinu-Razvan Chis-Serban
The default P9_LOCK_TIMEOUT can be too long for some users exporting
a local file system to a guest VM (30s), make this configurable at
mount time.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195727
Signed-off-by: Dinu-Razvan Chis-Serban
Signed-off-by: Dominique Martinet
---
This patch also has been in bugzilla for a bit over a year, and looks
fine to me.
I'll get it in linux-next around next week at the same time as the other
bz patch I sent recently after some testing, and will see with Razvan
(not sure how to call you in "short" version?) on how we fix comments
to it but can take are of that if required.
fs/9p/v9fs.c | 21 +
fs/9p/v9fs.h | 1 +
fs/9p/vfs_file.c | 5 -
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/fs/9p/v9fs.c b/fs/9p/v9fs.c
index 89bac3d2f05b..619128b55837 100644
--- a/fs/9p/v9fs.c
+++ b/fs/9p/v9fs.c
@@ -61,6 +61,8 @@ enum {
Opt_cache_loose, Opt_fscache, Opt_mmap,
/* Access options */
Opt_access, Opt_posixacl,
+ /* Lock timeout option */
+ Opt_locktimeout,
/* Error token */
Opt_err
};
@@ -80,6 +82,7 @@ static const match_table_t tokens = {
{Opt_cachetag, "cachetag=%s"},
{Opt_access, "access=%s"},
{Opt_posixacl, "posixacl"},
+ {Opt_locktimeout, "locktimeout=%u"},
{Opt_err, NULL}
};
@@ -187,6 +190,7 @@ static int v9fs_parse_options(struct v9fs_session_info
*v9ses, char *opts)
#ifdef CONFIG_9P_FSCACHE
v9ses->cachetag = NULL;
#endif
+ v9ses->session_lock_timeout = P9_LOCK_TIMEOUT;
if (!opts)
return 0;
@@ -359,6 +363,23 @@ static int v9fs_parse_options(struct v9fs_session_info
*v9ses, char *opts)
#endif
break;
+ case Opt_locktimeout:
+ r = match_int([0], );
+ if (r < 0) {
+ p9_debug(P9_DEBUG_ERROR,
+"integer field, but no integer?\n");
+ ret = r;
+ continue;
+ }
+ if (option < 1) {
+ p9_debug(P9_DEBUG_ERROR,
+"locktimeout must be a greater than
zero integer.\n");
+ ret = -EINVAL;
+ continue;
+ }
+ v9ses->session_lock_timeout = (long)option * HZ;
+ break;
+
default:
continue;
}
diff --git a/fs/9p/v9fs.h b/fs/9p/v9fs.h
index 982e017acadb..129e5243a6bf 100644
--- a/fs/9p/v9fs.h
+++ b/fs/9p/v9fs.h
@@ -116,6 +116,7 @@ struct v9fs_session_info {
struct p9_client *clnt; /* 9p client */
struct list_head slist; /* list of sessions registered with v9fs */
struct rw_semaphore rename_sem;
+ long session_lock_timeout; /* retry interval for blocking locks */
};
/* cache_validity flags */
diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c
index 374bc1c72048..c608b98c0188 100644
--- a/fs/9p/vfs_file.c
+++ b/fs/9p/vfs_file.c
@@ -154,6 +154,7 @@ static int v9fs_file_do_lock(struct file *filp, int cmd,
struct file_lock *fl)
uint8_t status = P9_LOCK_ERROR;
int res = 0;
unsigned char fl_type;
+ struct v9fs_session_info *v9ses;
fid = filp->private_data;
BUG_ON(fid == NULL);
@@ -189,6 +190,8 @@ static int v9fs_file_do_lock(struct file *filp, int cmd,
struct file_lock *fl)
if (IS_SETLKW(cmd))
flock.flags = P9_LOCK_FLAGS_BLOCK;
+ v9ses = v9fs_inode2v9ses(file_inode(filp));
+
/*
* if its a blocked request and we get P9_LOCK_BLOCKED as the status
* for lock request, keep on trying
@@ -202,7 +205,7 @@ static int v9fs_file_do_lock(struct file *filp, int cmd,
struct file_lock *fl)
break;
if (status == P9_LOCK_BLOCKED && !IS_SETLKW(cmd))
break;
- if (schedule_timeout_interruptible(P9_LOCK_TIMEOUT) != 0)
+ if (schedule_timeout_interruptible(v9ses->session_lock_timeout)
!= 0)
break;
}
--
2.17.1
[PATCH] ARM: qcom_defconfig: Enable MAILBOX
From: Frank Rowand
Problem:
ab460a2e72da ("rpmsg: qcom_smd: Access APCS through mailbox framework"
added a "depends on MAILBOX") to RPMSG_QCOM_SMD, thus RPMSG_QCOM_SMD
becomes unset since MAILBOX was not enabled in qcom_defconfig and is
not otherwise selected for the dragonboard. When the resulting
kernel is booted the mmc device which contains the root file system
is not available.
Fix:
add CONFIG_MAILBOX to qcom_defconfig
Fixes: ab460a2e72da ("rpmsg: qcom_smd: Access APCS through mailbox framework"
added a "depends on MAILBOX")
Signed-off-by: Frank Rowand
---
Bjorn suggested that multi_v7_defconfig might need this same fix
but I don't have a target to test on so I have not included that
change in this patch
Tested on Qualcomm APQ8074 Dragonboard
arch/arm/configs/qcom_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index 6aa7046fb91f..bd6440f23493 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -207,6 +207,7 @@ CONFIG_MSM_MMCC_8974=y
CONFIG_MSM_IOMMU=y
CONFIG_HWSPINLOCK=y
CONFIG_HWSPINLOCK_QCOM=y
+CONFIG_MAILBOX=y
CONFIG_REMOTEPROC=y
CONFIG_QCOM_ADSP_PIL=y
CONFIG_QCOM_Q6V5_PIL=y
--
Frank Rowand
[PATCH] ARM: qcom_defconfig: Enable MAILBOX
From: Frank Rowand
Problem:
ab460a2e72da ("rpmsg: qcom_smd: Access APCS through mailbox framework"
added a "depends on MAILBOX") to RPMSG_QCOM_SMD, thus RPMSG_QCOM_SMD
becomes unset since MAILBOX was not enabled in qcom_defconfig and is
not otherwise selected for the dragonboard. When the resulting
kernel is booted the mmc device which contains the root file system
is not available.
Fix:
add CONFIG_MAILBOX to qcom_defconfig
Fixes: ab460a2e72da ("rpmsg: qcom_smd: Access APCS through mailbox framework"
added a "depends on MAILBOX")
Signed-off-by: Frank Rowand
---
Bjorn suggested that multi_v7_defconfig might need this same fix
but I don't have a target to test on so I have not included that
change in this patch
Tested on Qualcomm APQ8074 Dragonboard
arch/arm/configs/qcom_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index 6aa7046fb91f..bd6440f23493 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -207,6 +207,7 @@ CONFIG_MSM_MMCC_8974=y
CONFIG_MSM_IOMMU=y
CONFIG_HWSPINLOCK=y
CONFIG_HWSPINLOCK_QCOM=y
+CONFIG_MAILBOX=y
CONFIG_REMOTEPROC=y
CONFIG_QCOM_ADSP_PIL=y
CONFIG_QCOM_Q6V5_PIL=y
--
Frank Rowand
Re: [PATCH] mm: hugepage: mark splitted page dirty when needed
On Thu, Sep 06, 2018 at 05:08:42PM +0300, Kirill A. Shutemov wrote: > On Thu, Sep 06, 2018 at 07:39:33PM +0800, Peter Xu wrote: > > On Wed, Sep 05, 2018 at 03:55:22PM +0300, Kirill A. Shutemov wrote: > > > On Wed, Sep 05, 2018 at 03:30:37PM +0800, Peter Xu wrote: > > > > On Tue, Sep 04, 2018 at 10:00:28AM -0400, Zi Yan wrote: > > > > > On 4 Sep 2018, at 4:01, Kirill A. Shutemov wrote: > > > > > > > > > > > On Tue, Sep 04, 2018 at 03:55:10PM +0800, Peter Xu wrote: > > > > > >> When splitting a huge page, we should set all small pages as dirty > > > > > >> if > > > > > >> the original huge page has the dirty bit set before. Otherwise > > > > > >> we'll > > > > > >> lose the original dirty bit. > > > > > > > > > > > > We don't lose it. It got transfered to struct page flag: > > > > > > > > > > > > if (pmd_dirty(old_pmd)) > > > > > > SetPageDirty(page); > > > > > > > > > > > > > > > > Plus, when split_huge_page_to_list() splits a THP, its subroutine > > > > > __split_huge_page() > > > > > propagates the dirty bit in the head page flag to all subpages in > > > > > __split_huge_page_tail(). > > > > > > > > Hi, Kirill, Zi, > > > > > > > > Thanks for your responses! > > > > > > > > Though in my test the huge page seems to be splitted not by > > > > split_huge_page_to_list() but by explicit calls to > > > > change_protection(). The stack looks like this (again, this is a > > > > customized kernel, and I added an explicit dump_stack() there): > > > > > > > > kernel: dump_stack+0x5c/0x7b > > > > kernel: __split_huge_pmd+0x192/0xdc0 > > > > kernel: ? update_load_avg+0x8b/0x550 > > > > kernel: ? update_load_avg+0x8b/0x550 > > > > kernel: ? account_entity_enqueue+0xc5/0xf0 > > > > kernel: ? enqueue_entity+0x112/0x650 > > > > kernel: change_protection+0x3a2/0xab0 > > > > kernel: mwriteprotect_range+0xdd/0x110 > > > > kernel: userfaultfd_ioctl+0x50b/0x1210 > > > > kernel: ? do_futex+0x2cf/0xb20 > > > > kernel: ? tty_write+0x1d2/0x2f0 > > > > kernel: ? do_vfs_ioctl+0x9f/0x610 > > > > kernel: do_vfs_ioctl+0x9f/0x610 > > > > kernel: ? __x64_sys_futex+0x88/0x180 > > > > kernel: ksys_ioctl+0x70/0x80 > > > > kernel: __x64_sys_ioctl+0x16/0x20 > > > > kernel: do_syscall_64+0x55/0x150 > > > > kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > > > > > At the very time the userspace is sending an UFFDIO_WRITEPROTECT ioctl > > > > to kernel space, which is handled by mwriteprotect_range(). In case > > > > you'd like to refer to the kernel, it's basically this one from > > > > Andrea's (with very trivial changes): > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git > > > > userfault > > > > > > > > So... do we have two paths to split the huge pages separately? > > > > > > We have two entiries that can be split: page table enties and underlying > > > compound page. > > > > > > split_huge_pmd() (and variants of it) split the PMD entry into a PTE page > > > table. It doens't touch underlying compound page. The page still can be > > > mapped in other place as huge. > > > > > > split_huge_page() (and ivariants of it) split compound page into a number > > > of 4k (or whatever PAGE_SIZE is). The operation requires splitting all > > > PMD, but not other way around. > > > > > > > > > > > Another (possibly very naive) question is: could any of you hint me > > > > how the page dirty bit is finally applied to the PTEs? These two > > > > dirty flags confused me for a few days already (the SetPageDirty() one > > > > which sets the page dirty flag, and the pte_mkdirty() which sets that > > > > onto the real PTEs). > > > > > > Dirty bit from page table entries transferes to sturct page flug and used > > > for decision making in reclaim path. > > > > Thanks for explaining. It's much clearer for me. > > > > Though for the issue I have encountered, I am still confused on why > > that dirty bit can be ignored for the splitted PTEs. Indeed we have: > > > > if (pmd_dirty(old_pmd)) > > SetPageDirty(page); > > > > However to me this only transfers (as you explained above) the dirty > > bit (AFAIU it's possibly set by the hardware when the page is written) > > to the page struct of the compound page. It did not really apply to > > every small page of the splitted huge page. As you also explained, > > this __split_huge_pmd() only splits the PMD entry but it keeps the > > compound huge page there, then IMHO it should also apply the dirty > > bits from the huge page to all the small page entries, no? > > The bit on compound page represents all small subpages. PageDirty() on any > subpage will return you true if the compound page is dirty. Ah I didn't notice this before (since PageDirty is defined with PF_HEAD), thanks for pointing out. > > > These dirty bits are really important to my scenario since AFAIU the > > change_protection() call is using these dirty bits to decide whether > > it should append the
Re: [PATCH] mm: hugepage: mark splitted page dirty when needed
On Thu, Sep 06, 2018 at 05:08:42PM +0300, Kirill A. Shutemov wrote: > On Thu, Sep 06, 2018 at 07:39:33PM +0800, Peter Xu wrote: > > On Wed, Sep 05, 2018 at 03:55:22PM +0300, Kirill A. Shutemov wrote: > > > On Wed, Sep 05, 2018 at 03:30:37PM +0800, Peter Xu wrote: > > > > On Tue, Sep 04, 2018 at 10:00:28AM -0400, Zi Yan wrote: > > > > > On 4 Sep 2018, at 4:01, Kirill A. Shutemov wrote: > > > > > > > > > > > On Tue, Sep 04, 2018 at 03:55:10PM +0800, Peter Xu wrote: > > > > > >> When splitting a huge page, we should set all small pages as dirty > > > > > >> if > > > > > >> the original huge page has the dirty bit set before. Otherwise > > > > > >> we'll > > > > > >> lose the original dirty bit. > > > > > > > > > > > > We don't lose it. It got transfered to struct page flag: > > > > > > > > > > > > if (pmd_dirty(old_pmd)) > > > > > > SetPageDirty(page); > > > > > > > > > > > > > > > > Plus, when split_huge_page_to_list() splits a THP, its subroutine > > > > > __split_huge_page() > > > > > propagates the dirty bit in the head page flag to all subpages in > > > > > __split_huge_page_tail(). > > > > > > > > Hi, Kirill, Zi, > > > > > > > > Thanks for your responses! > > > > > > > > Though in my test the huge page seems to be splitted not by > > > > split_huge_page_to_list() but by explicit calls to > > > > change_protection(). The stack looks like this (again, this is a > > > > customized kernel, and I added an explicit dump_stack() there): > > > > > > > > kernel: dump_stack+0x5c/0x7b > > > > kernel: __split_huge_pmd+0x192/0xdc0 > > > > kernel: ? update_load_avg+0x8b/0x550 > > > > kernel: ? update_load_avg+0x8b/0x550 > > > > kernel: ? account_entity_enqueue+0xc5/0xf0 > > > > kernel: ? enqueue_entity+0x112/0x650 > > > > kernel: change_protection+0x3a2/0xab0 > > > > kernel: mwriteprotect_range+0xdd/0x110 > > > > kernel: userfaultfd_ioctl+0x50b/0x1210 > > > > kernel: ? do_futex+0x2cf/0xb20 > > > > kernel: ? tty_write+0x1d2/0x2f0 > > > > kernel: ? do_vfs_ioctl+0x9f/0x610 > > > > kernel: do_vfs_ioctl+0x9f/0x610 > > > > kernel: ? __x64_sys_futex+0x88/0x180 > > > > kernel: ksys_ioctl+0x70/0x80 > > > > kernel: __x64_sys_ioctl+0x16/0x20 > > > > kernel: do_syscall_64+0x55/0x150 > > > > kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > > > > > At the very time the userspace is sending an UFFDIO_WRITEPROTECT ioctl > > > > to kernel space, which is handled by mwriteprotect_range(). In case > > > > you'd like to refer to the kernel, it's basically this one from > > > > Andrea's (with very trivial changes): > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git > > > > userfault > > > > > > > > So... do we have two paths to split the huge pages separately? > > > > > > We have two entiries that can be split: page table enties and underlying > > > compound page. > > > > > > split_huge_pmd() (and variants of it) split the PMD entry into a PTE page > > > table. It doens't touch underlying compound page. The page still can be > > > mapped in other place as huge. > > > > > > split_huge_page() (and ivariants of it) split compound page into a number > > > of 4k (or whatever PAGE_SIZE is). The operation requires splitting all > > > PMD, but not other way around. > > > > > > > > > > > Another (possibly very naive) question is: could any of you hint me > > > > how the page dirty bit is finally applied to the PTEs? These two > > > > dirty flags confused me for a few days already (the SetPageDirty() one > > > > which sets the page dirty flag, and the pte_mkdirty() which sets that > > > > onto the real PTEs). > > > > > > Dirty bit from page table entries transferes to sturct page flug and used > > > for decision making in reclaim path. > > > > Thanks for explaining. It's much clearer for me. > > > > Though for the issue I have encountered, I am still confused on why > > that dirty bit can be ignored for the splitted PTEs. Indeed we have: > > > > if (pmd_dirty(old_pmd)) > > SetPageDirty(page); > > > > However to me this only transfers (as you explained above) the dirty > > bit (AFAIU it's possibly set by the hardware when the page is written) > > to the page struct of the compound page. It did not really apply to > > every small page of the splitted huge page. As you also explained, > > this __split_huge_pmd() only splits the PMD entry but it keeps the > > compound huge page there, then IMHO it should also apply the dirty > > bits from the huge page to all the small page entries, no? > > The bit on compound page represents all small subpages. PageDirty() on any > subpage will return you true if the compound page is dirty. Ah I didn't notice this before (since PageDirty is defined with PF_HEAD), thanks for pointing out. > > > These dirty bits are really important to my scenario since AFAIU the > > change_protection() call is using these dirty bits to decide whether > > it should append the
[PATCH] apparmor: Fix network performance issue in aa_label_sk_perm
The netperf benchmark shows a 5.73% reduction in throughput for
small (64 byte) transfers by unconfined tasks.
DEFINE_AUDIT_SK() in aa_label_sk_perm() should not be performed
unconditionally, rather only when the label is confined.
netperf-tcp
56974a6fc^ 56974a6fc
Min 64 563.48 ( 0.00%) 531.17 ( -5.73%)
Min 128 1056.92 ( 0.00%) 999.44 ( -5.44%)
Min 256 1945.95 ( 0.00%) 1867.97 ( -4.01%)
Min 1024 6761.40 ( 0.00%) 6364.23 ( -5.87%)
Min 2048 0.53 ( 0.00%)10606.20 ( -4.54%)
Min 3312 13692.67 ( 0.00%)13158.41 ( -3.90%)
Min 4096 14926.29 ( 0.00%)14457.46 ( -3.14%)
Min 8192 18399.34 ( 0.00%)18091.65 ( -1.67%)
Min 1638421384.13 ( 0.00%)21158.05 ( -1.06%)
Hmean 64 564.96 ( 0.00%) 534.38 ( -5.41%)
Hmean 128 1064.42 ( 0.00%) 1010.12 ( -5.10%)
Hmean 256 1965.85 ( 0.00%) 1879.16 ( -4.41%)
Hmean 1024 6839.77 ( 0.00%) 6478.70 ( -5.28%)
Hmean 2048 11154.80 ( 0.00%)10671.13 ( -4.34%)
Hmean 3312 13838.12 ( 0.00%)13249.01 ( -4.26%)
Hmean 4096 15009.99 ( 0.00%)14561.36 ( -2.99%)
Hmean 8192 18975.57 ( 0.00%)18326.54 ( -3.42%)
Hmean 1638421440.44 ( 0.00%)21324.59 ( -0.54%)
Stddev64 1.24 ( 0.00%)2.85 (-130.64%)
Stddev128 4.51 ( 0.00%)6.53 ( -44.84%)
Stddev256 11.67 ( 0.00%)8.50 ( 27.16%)
Stddev102448.33 ( 0.00%) 75.07 ( -55.34%)
Stddev204854.82 ( 0.00%) 65.16 ( -18.86%)
Stddev3312 153.57 ( 0.00%) 56.29 ( 63.35%)
Stddev4096 100.25 ( 0.00%) 88.50 ( 11.72%)
Stddev8192 358.13 ( 0.00%) 169.99 ( 52.54%)
Stddev16384 43.99 ( 0.00%) 141.82 (-222.39%)
Signed-off-by: Tony Jones
Fixes: 56974a6fcfef ("apparmor: add base infastructure for socket
mediation")
---
security/apparmor/net.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/security/apparmor/net.c b/security/apparmor/net.c
index bb24cfa0a164..d5d72dd1ca1f 100644
--- a/security/apparmor/net.c
+++ b/security/apparmor/net.c
@@ -146,17 +146,20 @@ int aa_af_perm(struct aa_label *label, const char *op,
u32 request, u16 family,
static int aa_label_sk_perm(struct aa_label *label, const char *op, u32
request,
struct sock *sk)
{
- struct aa_profile *profile;
- DEFINE_AUDIT_SK(sa, op, sk);
+ int error = 0;
AA_BUG(!label);
AA_BUG(!sk);
- if (unconfined(label))
- return 0;
+ if (!unconfined(label)) {
+ struct aa_profile *profile;
+ DEFINE_AUDIT_SK(sa, op, sk);
- return fn_for_each_confined(label, profile,
- aa_profile_af_sk_perm(profile, , request, sk));
+ error = fn_for_each_confined(label, profile,
+ aa_profile_af_sk_perm(profile, , request, sk));
+ }
+
+ return error;
}
int aa_sk_perm(const char *op, u32 request, struct sock *sk)
--
2.18.0
[PATCH] apparmor: Fix network performance issue in aa_label_sk_perm
The netperf benchmark shows a 5.73% reduction in throughput for
small (64 byte) transfers by unconfined tasks.
DEFINE_AUDIT_SK() in aa_label_sk_perm() should not be performed
unconditionally, rather only when the label is confined.
netperf-tcp
56974a6fc^ 56974a6fc
Min 64 563.48 ( 0.00%) 531.17 ( -5.73%)
Min 128 1056.92 ( 0.00%) 999.44 ( -5.44%)
Min 256 1945.95 ( 0.00%) 1867.97 ( -4.01%)
Min 1024 6761.40 ( 0.00%) 6364.23 ( -5.87%)
Min 2048 0.53 ( 0.00%)10606.20 ( -4.54%)
Min 3312 13692.67 ( 0.00%)13158.41 ( -3.90%)
Min 4096 14926.29 ( 0.00%)14457.46 ( -3.14%)
Min 8192 18399.34 ( 0.00%)18091.65 ( -1.67%)
Min 1638421384.13 ( 0.00%)21158.05 ( -1.06%)
Hmean 64 564.96 ( 0.00%) 534.38 ( -5.41%)
Hmean 128 1064.42 ( 0.00%) 1010.12 ( -5.10%)
Hmean 256 1965.85 ( 0.00%) 1879.16 ( -4.41%)
Hmean 1024 6839.77 ( 0.00%) 6478.70 ( -5.28%)
Hmean 2048 11154.80 ( 0.00%)10671.13 ( -4.34%)
Hmean 3312 13838.12 ( 0.00%)13249.01 ( -4.26%)
Hmean 4096 15009.99 ( 0.00%)14561.36 ( -2.99%)
Hmean 8192 18975.57 ( 0.00%)18326.54 ( -3.42%)
Hmean 1638421440.44 ( 0.00%)21324.59 ( -0.54%)
Stddev64 1.24 ( 0.00%)2.85 (-130.64%)
Stddev128 4.51 ( 0.00%)6.53 ( -44.84%)
Stddev256 11.67 ( 0.00%)8.50 ( 27.16%)
Stddev102448.33 ( 0.00%) 75.07 ( -55.34%)
Stddev204854.82 ( 0.00%) 65.16 ( -18.86%)
Stddev3312 153.57 ( 0.00%) 56.29 ( 63.35%)
Stddev4096 100.25 ( 0.00%) 88.50 ( 11.72%)
Stddev8192 358.13 ( 0.00%) 169.99 ( 52.54%)
Stddev16384 43.99 ( 0.00%) 141.82 (-222.39%)
Signed-off-by: Tony Jones
Fixes: 56974a6fcfef ("apparmor: add base infastructure for socket
mediation")
---
security/apparmor/net.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/security/apparmor/net.c b/security/apparmor/net.c
index bb24cfa0a164..d5d72dd1ca1f 100644
--- a/security/apparmor/net.c
+++ b/security/apparmor/net.c
@@ -146,17 +146,20 @@ int aa_af_perm(struct aa_label *label, const char *op,
u32 request, u16 family,
static int aa_label_sk_perm(struct aa_label *label, const char *op, u32
request,
struct sock *sk)
{
- struct aa_profile *profile;
- DEFINE_AUDIT_SK(sa, op, sk);
+ int error = 0;
AA_BUG(!label);
AA_BUG(!sk);
- if (unconfined(label))
- return 0;
+ if (!unconfined(label)) {
+ struct aa_profile *profile;
+ DEFINE_AUDIT_SK(sa, op, sk);
- return fn_for_each_confined(label, profile,
- aa_profile_af_sk_perm(profile, , request, sk));
+ error = fn_for_each_confined(label, profile,
+ aa_profile_af_sk_perm(profile, , request, sk));
+ }
+
+ return error;
}
int aa_sk_perm(const char *op, u32 request, struct sock *sk)
--
2.18.0
Re: [PATCH 4.19 regression fix] printk: For early boot messages check loglevel when flushing the buffer
On (09/06/18 16:28), Petr Mladek wrote: > On Thu 2018-09-06 16:29:40, Sergey Senozhatsky wrote: > > On (09/05/18 13:02), Petr Mladek wrote: > > > Note that the first registered console prints all messages > > > even without this flag. > > > > Hmm, OK, interesting point. > > > > I assumed that the first console usually has CON_PRINTBUFFER bit set. > > Or even a CON_PRINTBUFFER | CON_ANYTIME combo. E.g. 8250. It sort of > > makes sense to have CON_PRINTBUFFER for the first console. Any later > > consoles [e.g. fbcon, netcon] don't necessarily have CON_PRINTBUFFER. > > > > And the first console has CON_PRINTBUFFER bit set. Well, just because > > it sounds reasonable. Those were the main assumptions behind my code > > snippet. Was any of those assumptions wrong? > > This assumption makes sense. In fact, I was wrong. I thought that > console_seq/console_idx were not updated until the first console > was registered. But it is not the case. > > It means that the hack with exclusive_console might be usable. Yeah, it is a hack. But not as dirty as it might appear, I think. In some sense it's aligned with what we do for exlusive_consoles - we treat exclusive consoles specially. So specially that even if the system panics while we re-flush logbuf messages to a new exclusive console, we flush_on_panic() only to that exclusive console, ignoring the rest of them. Not sure if it's totally right. There can be a netcon, for instance, available, which will not see panic flush() because of a exclusive console: --- diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index c036f128cdc3..ede29a7ba6db 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -2545,6 +2545,7 @@ void console_flush_on_panic(void) * ensure may_schedule is cleared. */ console_trylock(); + exclusive_console = NULL; console_may_schedule = 0; console_unlock(); } --- Opinions? > But I would prefer to do it a cleaner way. OK. > But it is rather complicated, still hacky, ... Right. > > > > I can agree, definitely. That's one of the options. > > I prefer the revert for now. OK, agreed. IIRC I didn't see any upstream code which would have been fixed by the commit in question. -ss
Re: [PATCH 4.19 regression fix] printk: For early boot messages check loglevel when flushing the buffer
On (09/06/18 16:28), Petr Mladek wrote: > On Thu 2018-09-06 16:29:40, Sergey Senozhatsky wrote: > > On (09/05/18 13:02), Petr Mladek wrote: > > > Note that the first registered console prints all messages > > > even without this flag. > > > > Hmm, OK, interesting point. > > > > I assumed that the first console usually has CON_PRINTBUFFER bit set. > > Or even a CON_PRINTBUFFER | CON_ANYTIME combo. E.g. 8250. It sort of > > makes sense to have CON_PRINTBUFFER for the first console. Any later > > consoles [e.g. fbcon, netcon] don't necessarily have CON_PRINTBUFFER. > > > > And the first console has CON_PRINTBUFFER bit set. Well, just because > > it sounds reasonable. Those were the main assumptions behind my code > > snippet. Was any of those assumptions wrong? > > This assumption makes sense. In fact, I was wrong. I thought that > console_seq/console_idx were not updated until the first console > was registered. But it is not the case. > > It means that the hack with exclusive_console might be usable. Yeah, it is a hack. But not as dirty as it might appear, I think. In some sense it's aligned with what we do for exlusive_consoles - we treat exclusive consoles specially. So specially that even if the system panics while we re-flush logbuf messages to a new exclusive console, we flush_on_panic() only to that exclusive console, ignoring the rest of them. Not sure if it's totally right. There can be a netcon, for instance, available, which will not see panic flush() because of a exclusive console: --- diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index c036f128cdc3..ede29a7ba6db 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -2545,6 +2545,7 @@ void console_flush_on_panic(void) * ensure may_schedule is cleared. */ console_trylock(); + exclusive_console = NULL; console_may_schedule = 0; console_unlock(); } --- Opinions? > But I would prefer to do it a cleaner way. OK. > But it is rather complicated, still hacky, ... Right. > > > > I can agree, definitely. That's one of the options. > > I prefer the revert for now. OK, agreed. IIRC I didn't see any upstream code which would have been fixed by the commit in question. -ss
Re: [PATCH 2/2] pci: dwc: add UniPhier PCIe host controller support
Hi Bjorn, On Thu, 6 Sep 2018 09:09:27 -0500 wrote: > On Thu, Sep 06, 2018 at 10:38:20AM +0900, Kunihiko Hayashi wrote: > > > > +++ b/drivers/pci/controller/dwc/pcie-uniphier.c > > > > @@ -0,0 +1,464 @@ > > > > +// SPDX-License-Identifier: GPL-2.0 > > > > +// > > > > +// PCI-express host controller driver for UniPhier SoCs > > > > +// Copyright 2018 Socionext Inc. > > > > +// Author: Kunihiko Hayashi > > > > > > Use /* ... */ comments except for the SPDX line. > > > > Okay, although I wondered which way to put, I'll replace the header next. > > The easiest thing is to look at similar files already in the tree and > follow their style. The details are here: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst#n540 > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst#n74 Thanks for your advice. Although I've found both styles in some sub-systems, these are helpful for me. I replaced it in posted v2. Thank you, --- Best Regards, Kunihiko Hayashi
Re: [PATCH 2/2] pci: dwc: add UniPhier PCIe host controller support
Hi Bjorn, On Thu, 6 Sep 2018 09:09:27 -0500 wrote: > On Thu, Sep 06, 2018 at 10:38:20AM +0900, Kunihiko Hayashi wrote: > > > > +++ b/drivers/pci/controller/dwc/pcie-uniphier.c > > > > @@ -0,0 +1,464 @@ > > > > +// SPDX-License-Identifier: GPL-2.0 > > > > +// > > > > +// PCI-express host controller driver for UniPhier SoCs > > > > +// Copyright 2018 Socionext Inc. > > > > +// Author: Kunihiko Hayashi > > > > > > Use /* ... */ comments except for the SPDX line. > > > > Okay, although I wondered which way to put, I'll replace the header next. > > The easiest thing is to look at similar files already in the tree and > follow their style. The details are here: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst#n540 > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst#n74 Thanks for your advice. Although I've found both styles in some sub-systems, these are helpful for me. I replaced it in posted v2. Thank you, --- Best Regards, Kunihiko Hayashi
Re: [PATCH v5 5/5] x86/kvm: Avoid dynamic allocation of pvclock data when SEV is active
On 9/6/18 1:50 PM, Brijesh Singh wrote: ... >> >> #define HVC_DECRYPTED_ARRAY_SIZE \ >> PAGE_ALIGN((NR_CPUS - HVC_BOOT_ARRAY_SIZE) * \ >> sizeof(struct pvclock_vsyscall_time_info)) >> > Since the hv_clock_aux array will have NR_CPUS elements hence the following definition is all we need. #ifdef CONFIG_AMD_MEM_ENCRYPT static struct pvclock_vsyscall_time_info hv_clock_aux[NR_CPUS] __decrypted_aux; #endif > Sure works for me. > >>> +static struct pvclock_vsyscall_time_info >>> + hv_clock_dec[HVC_DECRYPTED_ARRAY_SIZE] >>> __decrypted_hvclock; >>> +
Re: [PATCH v5 5/5] x86/kvm: Avoid dynamic allocation of pvclock data when SEV is active
On 9/6/18 1:50 PM, Brijesh Singh wrote: ... >> >> #define HVC_DECRYPTED_ARRAY_SIZE \ >> PAGE_ALIGN((NR_CPUS - HVC_BOOT_ARRAY_SIZE) * \ >> sizeof(struct pvclock_vsyscall_time_info)) >> > Since the hv_clock_aux array will have NR_CPUS elements hence the following definition is all we need. #ifdef CONFIG_AMD_MEM_ENCRYPT static struct pvclock_vsyscall_time_info hv_clock_aux[NR_CPUS] __decrypted_aux; #endif > Sure works for me. > >>> +static struct pvclock_vsyscall_time_info >>> + hv_clock_dec[HVC_DECRYPTED_ARRAY_SIZE] >>> __decrypted_hvclock; >>> +
Re: [LKP] [rcutorture] 894b343aa8: WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_fwd_prog
On Fri, Sep 07, 2018 at 11:01:56AM +0800, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 894b343aa8bec5ee732329f1db09b9f5c2794de5 ("rcutorture: Add call_rcu()
> flooding forward-progress tests")
> https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git
> dev.2018.08.30a
>
> in testcase: trinity
> with following parameters:
>
> runtime: 300s
>
> test-description: Trinity is a linux system call fuzz tester.
> test-url: http://codemonkey.org.uk/projects/trinity/
This one is real, and I have been working on it.
I added forward-progress testing, and am still working out the kinks.
It might be a little bit.
Thanx, Paul
> on test machine: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -smp
> 2 -m 512M
>
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
>
>
> +--+++
> | |
> 93fd89934b | 894b343aa8 |
> +--+++
> | boot_successes | 24
> | 18 |
> | boot_failures| 1
> | 12 |
> | invoked_oom-killer:gfp_mask=0x | 1
> | 2 |
> | Mem-Info | 1
> | 2 |
> | Out_of_memory:Kill_process | 1
> ||
> | Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 0
> | 2 |
> | RIP:rcu_torture_fwd_prog | 0
> | 10 |
> | WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_fwd_prog | 0
> | 9 |
> +--+++
>
>
>
> [ 307.810166] WARNING: CPU: 1 PID: 54 at kernel/rcu/rcutorture.c:1840
> rcu_torture_fwd_prog+0x41f/0x542
> [ 307.832010] Modules linked in:
> [ 307.837737] CPU: 1 PID: 54 Comm: rcu_torture_fwd Tainted: G
> T 4.19.0-rc1-00151-g894b343 #1
> [ 307.856076] RIP: 0010:rcu_torture_fwd_prog+0x41f/0x542
> [ 307.866058] Code: b8 0e 00 eb e2 48 c7 05 c9 25 35 01 f0 fa 78 83 c6 05 92
> 99 67 02 00 e8 29 6c 09 00 84 c0 0f 85 af 00 00 00 49 83 fc 63 7f 02 <0f> 0b
> 48 8b 45 88 4f 8d 44 3d 00 4d 89 e9 48 c7 c6 a0 34 e2 81 48
> [ 307.902163] RSP: 0018:88000c1cbe80 EFLAGS: 00010293
> [ 307.912698] RAX: RBX: 0001 RCX:
> 88001046c080
> [ 307.926369] RDX: 0017 RSI: 811c173d RDI:
> 88001046c080
> [ 307.940082] RBP: 88000c1cbf00 R08: 0020 R09:
> 8800053e4ce0
> [ 307.953984] R10: 8800053e4260 R11: 8800053e4d40 R12:
>
> [ 307.968462] R13: 0003 R14: R15:
> 0083
> [ 307.982466] FS: () GS:88001c40()
> knlGS:
> [ 307.998082] CS: 0010 DS: ES: CR0: 80050033
> [ 308.009554] CR2: 7ffc7538e000 CR3: 02411004 CR4:
> 000206a0
> [ 308.023264] Call Trace:
> [ 308.028512] ? _raw_spin_unlock_irqrestore+0x45/0x4f
> [ 308.038529] ? rcu_torture_stall+0x12d/0x12d
> [ 308.047149] ? kthread+0x114/0x123
> [ 308.054115] ? kthread+0x114/0x123
> [ 308.060625] ? kthread_create_worker_on_cpu+0x5f/0x5f
> [ 308.069703] ? ret_from_fork+0x3a/0x50
> [ 308.076537] irq event stamp: 3048
> [ 308.082507] hardirqs last enabled at (3047): []
> kfree+0x125/0x136
> [ 308.097831] hardirqs last disabled at (3048): []
> trace_hardirqs_off_thunk+0x1a/0x1c
> [ 308.115656] softirqs last enabled at (56): []
> __do_softirq+0x359/0x39b
> [ 308.130979] softirqs last disabled at (49): []
> irq_exit+0x59/0x75
> [ 308.145115] ---[ end trace 3654c8b0e1b99cb1 ]---
>
>
> To reproduce:
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp qemu -k job-script # job-script is attached in this
> email
>
>
>
> Thanks,
> Rong, Chen
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 4.19.0-rc1 Kernel Configuration
> #
>
> #
> # Compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> #
> CONFIG_CC_IS_GCC=y
> CONFIG_GCC_VERSION=70300
> CONFIG_CLANG_VERSION=0
> CONFIG_CONSTRUCTORS=y
> CONFIG_IRQ_WORK=y
> CONFIG_BUILDTIME_EXTABLE_SORT=y
> CONFIG_THREAD_INFO_IN_TASK=y
>
> #
> # General setup
> #
> CONFIG_INIT_ENV_ARG_LIMIT=32
> # CONFIG_COMPILE_TEST is not set
> CONFIG_LOCALVERSION=""
> CONFIG_LOCALVERSION_AUTO=y
> CONFIG_BUILD_SALT=""
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
>
Re: [LKP] [rcutorture] 894b343aa8: WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_fwd_prog
On Fri, Sep 07, 2018 at 11:01:56AM +0800, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 894b343aa8bec5ee732329f1db09b9f5c2794de5 ("rcutorture: Add call_rcu()
> flooding forward-progress tests")
> https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git
> dev.2018.08.30a
>
> in testcase: trinity
> with following parameters:
>
> runtime: 300s
>
> test-description: Trinity is a linux system call fuzz tester.
> test-url: http://codemonkey.org.uk/projects/trinity/
This one is real, and I have been working on it.
I added forward-progress testing, and am still working out the kinks.
It might be a little bit.
Thanx, Paul
> on test machine: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -smp
> 2 -m 512M
>
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
>
>
> +--+++
> | |
> 93fd89934b | 894b343aa8 |
> +--+++
> | boot_successes | 24
> | 18 |
> | boot_failures| 1
> | 12 |
> | invoked_oom-killer:gfp_mask=0x | 1
> | 2 |
> | Mem-Info | 1
> | 2 |
> | Out_of_memory:Kill_process | 1
> ||
> | Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 0
> | 2 |
> | RIP:rcu_torture_fwd_prog | 0
> | 10 |
> | WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_fwd_prog | 0
> | 9 |
> +--+++
>
>
>
> [ 307.810166] WARNING: CPU: 1 PID: 54 at kernel/rcu/rcutorture.c:1840
> rcu_torture_fwd_prog+0x41f/0x542
> [ 307.832010] Modules linked in:
> [ 307.837737] CPU: 1 PID: 54 Comm: rcu_torture_fwd Tainted: G
> T 4.19.0-rc1-00151-g894b343 #1
> [ 307.856076] RIP: 0010:rcu_torture_fwd_prog+0x41f/0x542
> [ 307.866058] Code: b8 0e 00 eb e2 48 c7 05 c9 25 35 01 f0 fa 78 83 c6 05 92
> 99 67 02 00 e8 29 6c 09 00 84 c0 0f 85 af 00 00 00 49 83 fc 63 7f 02 <0f> 0b
> 48 8b 45 88 4f 8d 44 3d 00 4d 89 e9 48 c7 c6 a0 34 e2 81 48
> [ 307.902163] RSP: 0018:88000c1cbe80 EFLAGS: 00010293
> [ 307.912698] RAX: RBX: 0001 RCX:
> 88001046c080
> [ 307.926369] RDX: 0017 RSI: 811c173d RDI:
> 88001046c080
> [ 307.940082] RBP: 88000c1cbf00 R08: 0020 R09:
> 8800053e4ce0
> [ 307.953984] R10: 8800053e4260 R11: 8800053e4d40 R12:
>
> [ 307.968462] R13: 0003 R14: R15:
> 0083
> [ 307.982466] FS: () GS:88001c40()
> knlGS:
> [ 307.998082] CS: 0010 DS: ES: CR0: 80050033
> [ 308.009554] CR2: 7ffc7538e000 CR3: 02411004 CR4:
> 000206a0
> [ 308.023264] Call Trace:
> [ 308.028512] ? _raw_spin_unlock_irqrestore+0x45/0x4f
> [ 308.038529] ? rcu_torture_stall+0x12d/0x12d
> [ 308.047149] ? kthread+0x114/0x123
> [ 308.054115] ? kthread+0x114/0x123
> [ 308.060625] ? kthread_create_worker_on_cpu+0x5f/0x5f
> [ 308.069703] ? ret_from_fork+0x3a/0x50
> [ 308.076537] irq event stamp: 3048
> [ 308.082507] hardirqs last enabled at (3047): []
> kfree+0x125/0x136
> [ 308.097831] hardirqs last disabled at (3048): []
> trace_hardirqs_off_thunk+0x1a/0x1c
> [ 308.115656] softirqs last enabled at (56): []
> __do_softirq+0x359/0x39b
> [ 308.130979] softirqs last disabled at (49): []
> irq_exit+0x59/0x75
> [ 308.145115] ---[ end trace 3654c8b0e1b99cb1 ]---
>
>
> To reproduce:
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp qemu -k job-script # job-script is attached in this
> email
>
>
>
> Thanks,
> Rong, Chen
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 4.19.0-rc1 Kernel Configuration
> #
>
> #
> # Compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> #
> CONFIG_CC_IS_GCC=y
> CONFIG_GCC_VERSION=70300
> CONFIG_CLANG_VERSION=0
> CONFIG_CONSTRUCTORS=y
> CONFIG_IRQ_WORK=y
> CONFIG_BUILDTIME_EXTABLE_SORT=y
> CONFIG_THREAD_INFO_IN_TASK=y
>
> #
> # General setup
> #
> CONFIG_INIT_ENV_ARG_LIMIT=32
> # CONFIG_COMPILE_TEST is not set
> CONFIG_LOCALVERSION=""
> CONFIG_LOCALVERSION_AUTO=y
> CONFIG_BUILD_SALT=""
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
>
Re: linux-next: build warnings from the build of Linus' tree
Hi Peter, On Fri, 7 Sep 2018 08:14:40 +1000 Stephen Rothwell wrote: > > On Thu, 6 Sep 2018 12:49:39 +0200 Peter Oberparleiter > wrote: > > > > I've attached a quick fix that should address both problems. I'd > > appreciate if this patch could get some testing before I post proper fix > > patches. > > I have added that into linux-next today ... I will let you know this > afternoon how it went (it looks sensible, though). It certainly gets rid of the PowerPC linker messages, thanks. -- Cheers, Stephen Rothwell pgpT8rFj9k9KF.pgp Description: OpenPGP digital signature
Re: linux-next: build warnings from the build of Linus' tree
Hi Peter, On Fri, 7 Sep 2018 08:14:40 +1000 Stephen Rothwell wrote: > > On Thu, 6 Sep 2018 12:49:39 +0200 Peter Oberparleiter > wrote: > > > > I've attached a quick fix that should address both problems. I'd > > appreciate if this patch could get some testing before I post proper fix > > patches. > > I have added that into linux-next today ... I will let you know this > afternoon how it went (it looks sensible, though). It certainly gets rid of the PowerPC linker messages, thanks. -- Cheers, Stephen Rothwell pgpT8rFj9k9KF.pgp Description: OpenPGP digital signature
Re: KASAN: null-ptr-deref Write in binder_update_page_range
Thanks, Martijn,
Greg, could you have a look to pick up?
On Mon, Aug 27, 2018 at 03:35:24PM +0200, Martijn Coenen wrote:
> Thanks Minchan!
>
> On Thu, Aug 23, 2018 at 7:29 AM, Minchan Kim wrote:
> > Signed-off-by: Todd Kjos
> > Signed-off-by: Minchan Kim
> Reviewed-by: Martijn Coenen
>
> > ---
> > drivers/android/binder_alloc.c | 43 +++---
> > 1 file changed, 35 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
> > index 3f3b7b253445..64fd96eada31 100644
> > --- a/drivers/android/binder_alloc.c
> > +++ b/drivers/android/binder_alloc.c
> > @@ -332,6 +332,35 @@ static int binder_update_page_range(struct
> > binder_alloc *alloc, int allocate,
> > return vma ? -ENOMEM : -ESRCH;
> > }
> >
> > +
> > +static inline void binder_alloc_set_vma(struct binder_alloc *alloc,
> > + struct vm_area_struct *vma)
> > +{
> > + if (vma)
> > + alloc->vma_vm_mm = vma->vm_mm;
> > + /*
> > +* If we see alloc->vma is not NULL, buffer data structures set up
> > +* completely. Look at smp_rmb side binder_alloc_get_vma.
> > +* We also want to guarantee new alloc->vma_vm_mm is always visible
> > +* if alloc->vma is set.
> > +*/
> > + smp_wmb();
> > + alloc->vma = vma;
> > +}
> > +
> > +static inline struct vm_area_struct *binder_alloc_get_vma(
> > + struct binder_alloc *alloc)
> > +{
> > + struct vm_area_struct *vma = NULL;
> > +
> > + if (alloc->vma) {
> > + /* Look at description in binder_alloc_set_vma */
> > + smp_rmb();
> > + vma = alloc->vma;
> > + }
> > + return vma;
> > +}
> > +
> > static struct binder_buffer *binder_alloc_new_buf_locked(
> > struct binder_alloc *alloc,
> > size_t data_size,
> > @@ -348,7 +377,7 @@ static struct binder_buffer
> > *binder_alloc_new_buf_locked(
> > size_t size, data_offsets_size;
> > int ret;
> >
> > - if (alloc->vma == NULL) {
> > + if (!binder_alloc_get_vma(alloc)) {
> > binder_alloc_debug(BINDER_DEBUG_USER_ERROR,
> >"%d: binder_alloc_buf, no vma\n",
> >alloc->pid);
> > @@ -723,9 +752,7 @@ int binder_alloc_mmap_handler(struct binder_alloc
> > *alloc,
> > buffer->free = 1;
> > binder_insert_free_buffer(alloc, buffer);
> > alloc->free_async_space = alloc->buffer_size / 2;
> > - barrier();
> > - alloc->vma = vma;
> > - alloc->vma_vm_mm = vma->vm_mm;
> > + binder_alloc_set_vma(alloc, vma);
> > mmgrab(alloc->vma_vm_mm);
> >
> > return 0;
> > @@ -754,10 +781,10 @@ void binder_alloc_deferred_release(struct
> > binder_alloc *alloc)
> > int buffers, page_count;
> > struct binder_buffer *buffer;
> >
> > - BUG_ON(alloc->vma);
> > -
> > buffers = 0;
> > mutex_lock(>mutex);
> > + BUG_ON(alloc->vma);
> > +
> > while ((n = rb_first(>allocated_buffers))) {
> > buffer = rb_entry(n, struct binder_buffer, rb_node);
> >
> > @@ -900,7 +927,7 @@ int binder_alloc_get_allocated_count(struct
> > binder_alloc *alloc)
> > */
> > void binder_alloc_vma_close(struct binder_alloc *alloc)
> > {
> > - WRITE_ONCE(alloc->vma, NULL);
> > + binder_alloc_set_vma(alloc, NULL);
> > }
> >
> > /**
> > @@ -935,7 +962,7 @@ enum lru_status binder_alloc_free_page(struct list_head
> > *item,
> >
> > index = page - alloc->pages;
> > page_addr = (uintptr_t)alloc->buffer + index * PAGE_SIZE;
> > - vma = alloc->vma;
> > + vma = binder_alloc_get_vma(alloc);
> > if (vma) {
> > if (!mmget_not_zero(alloc->vma_vm_mm))
> > goto err_mmget;
> > --
> > 2.18.0.1017.ga543ac7ca45-goog
> >
> >
> >
> >
Re: KASAN: null-ptr-deref Write in binder_update_page_range
Thanks, Martijn,
Greg, could you have a look to pick up?
On Mon, Aug 27, 2018 at 03:35:24PM +0200, Martijn Coenen wrote:
> Thanks Minchan!
>
> On Thu, Aug 23, 2018 at 7:29 AM, Minchan Kim wrote:
> > Signed-off-by: Todd Kjos
> > Signed-off-by: Minchan Kim
> Reviewed-by: Martijn Coenen
>
> > ---
> > drivers/android/binder_alloc.c | 43 +++---
> > 1 file changed, 35 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
> > index 3f3b7b253445..64fd96eada31 100644
> > --- a/drivers/android/binder_alloc.c
> > +++ b/drivers/android/binder_alloc.c
> > @@ -332,6 +332,35 @@ static int binder_update_page_range(struct
> > binder_alloc *alloc, int allocate,
> > return vma ? -ENOMEM : -ESRCH;
> > }
> >
> > +
> > +static inline void binder_alloc_set_vma(struct binder_alloc *alloc,
> > + struct vm_area_struct *vma)
> > +{
> > + if (vma)
> > + alloc->vma_vm_mm = vma->vm_mm;
> > + /*
> > +* If we see alloc->vma is not NULL, buffer data structures set up
> > +* completely. Look at smp_rmb side binder_alloc_get_vma.
> > +* We also want to guarantee new alloc->vma_vm_mm is always visible
> > +* if alloc->vma is set.
> > +*/
> > + smp_wmb();
> > + alloc->vma = vma;
> > +}
> > +
> > +static inline struct vm_area_struct *binder_alloc_get_vma(
> > + struct binder_alloc *alloc)
> > +{
> > + struct vm_area_struct *vma = NULL;
> > +
> > + if (alloc->vma) {
> > + /* Look at description in binder_alloc_set_vma */
> > + smp_rmb();
> > + vma = alloc->vma;
> > + }
> > + return vma;
> > +}
> > +
> > static struct binder_buffer *binder_alloc_new_buf_locked(
> > struct binder_alloc *alloc,
> > size_t data_size,
> > @@ -348,7 +377,7 @@ static struct binder_buffer
> > *binder_alloc_new_buf_locked(
> > size_t size, data_offsets_size;
> > int ret;
> >
> > - if (alloc->vma == NULL) {
> > + if (!binder_alloc_get_vma(alloc)) {
> > binder_alloc_debug(BINDER_DEBUG_USER_ERROR,
> >"%d: binder_alloc_buf, no vma\n",
> >alloc->pid);
> > @@ -723,9 +752,7 @@ int binder_alloc_mmap_handler(struct binder_alloc
> > *alloc,
> > buffer->free = 1;
> > binder_insert_free_buffer(alloc, buffer);
> > alloc->free_async_space = alloc->buffer_size / 2;
> > - barrier();
> > - alloc->vma = vma;
> > - alloc->vma_vm_mm = vma->vm_mm;
> > + binder_alloc_set_vma(alloc, vma);
> > mmgrab(alloc->vma_vm_mm);
> >
> > return 0;
> > @@ -754,10 +781,10 @@ void binder_alloc_deferred_release(struct
> > binder_alloc *alloc)
> > int buffers, page_count;
> > struct binder_buffer *buffer;
> >
> > - BUG_ON(alloc->vma);
> > -
> > buffers = 0;
> > mutex_lock(>mutex);
> > + BUG_ON(alloc->vma);
> > +
> > while ((n = rb_first(>allocated_buffers))) {
> > buffer = rb_entry(n, struct binder_buffer, rb_node);
> >
> > @@ -900,7 +927,7 @@ int binder_alloc_get_allocated_count(struct
> > binder_alloc *alloc)
> > */
> > void binder_alloc_vma_close(struct binder_alloc *alloc)
> > {
> > - WRITE_ONCE(alloc->vma, NULL);
> > + binder_alloc_set_vma(alloc, NULL);
> > }
> >
> > /**
> > @@ -935,7 +962,7 @@ enum lru_status binder_alloc_free_page(struct list_head
> > *item,
> >
> > index = page - alloc->pages;
> > page_addr = (uintptr_t)alloc->buffer + index * PAGE_SIZE;
> > - vma = alloc->vma;
> > + vma = binder_alloc_get_vma(alloc);
> > if (vma) {
> > if (!mmget_not_zero(alloc->vma_vm_mm))
> > goto err_mmget;
> > --
> > 2.18.0.1017.ga543ac7ca45-goog
> >
> >
> >
> >
[PATCH v11 1/2] leds: core: Introduce LED pattern trigger
This patch adds one new led trigger that LED device can configure the software or hardware pattern and trigger it. Consumers can write 'pattern' file to enable the software pattern which alters the brightness for the specified duration with one software timer. Moreover consumers can write 'hw_pattern' file to enable the hardware pattern for some LED controllers which can autonomously control brightness over time, according to some preprogrammed hardware patterns. Signed-off-by: Raphael Teysseyre Signed-off-by: Baolin Wang --- Changes from v10: - Change 'int' to 'u32' for delta_t field. Changes from v9: - None. Changes from v8: - None. Changes from v7: - Move the SC27XX hardware patterns description into its own ABI file. Changes from v6: - Improve commit message. - Optimize the description of the hw_pattern file. - Simplify some logics. Changes from v5: - Add one 'hw_pattern' file for hardware patterns. Changes from v4: - Change the repeat file to return the originally written number. - Improve comments. - Fix some build warnings. Changes from v3: - Reset pattern number to 0 if user provides incorrect pattern string. - Support one pattern. Changes from v2: - Remove hardware_pattern boolen. - Chnage the pattern string format. Changes from v1: - Use ATTRIBUTE_GROUPS() to define attributes. - Introduce hardware_pattern flag to determine if software pattern or hardware pattern. - Re-implement pattern_trig_store_pattern() function. - Remove pattern_get() interface. - Improve comments. - Other small optimization. --- .../ABI/testing/sysfs-class-led-trigger-pattern| 38 +++ drivers/leds/trigger/Kconfig |7 + drivers/leds/trigger/Makefile |1 + drivers/leds/trigger/ledtrig-pattern.c | 337 include/linux/leds.h | 16 + 5 files changed, 399 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-pattern create mode 100644 drivers/leds/trigger/ledtrig-pattern.c diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern new file mode 100644 index 000..8cc5099 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern @@ -0,0 +1,38 @@ +What: /sys/class/leds//pattern +Date: September 2018 +KernelVersion: 4.20 +Description: + Specify a software pattern for the LED, that supports altering + the brightness for the specified duration with one software + timer. + + The pattern is given by a series of tuples, of brightness and + duration (ms). The LED is expected to traverse the series and + each brightness value for the specified duration. Duration of + 0 means brightness should immediately change to new value. + + The format of the software pattern values should be: + "brightness_1 duration_1 brightness_2 duration_2 brightness_3 + duration_3 ...". + +What: /sys/class/leds//hw_pattern +Date: September 2018 +KernelVersion: 4.20 +Description: + Specify a hardware pattern for the LED, for LED hardware that + supports autonomously controlling brightness over time, according + to some preprogrammed hardware patterns. + + Since different LED hardware can have different semantics of + hardware patterns, each driver is expected to provide its own + description for the hardware patterns in their ABI documentation + file. + +What: /sys/class/leds//repeat +Date: September 2018 +KernelVersion: 4.20 +Description: + Specify a pattern repeat number. 0 means repeat indefinitely. + + This file will always return the originally written repeat + number. diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig index 4018af7..b76fc3c 100644 --- a/drivers/leds/trigger/Kconfig +++ b/drivers/leds/trigger/Kconfig @@ -129,4 +129,11 @@ config LEDS_TRIGGER_NETDEV This allows LEDs to be controlled by network device activity. If unsure, say Y. +config LEDS_TRIGGER_PATTERN + tristate "LED Pattern Trigger" + help + This allows LEDs to be controlled by a software or hardware pattern + which is a series of tuples, of brightness and duration (ms). + If unsure, say N + endif # LEDS_TRIGGERS diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile index f3cfe19..9bcb64e 100644 --- a/drivers/leds/trigger/Makefile +++ b/drivers/leds/trigger/Makefile @@ -13,3 +13,4 @@ obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT) += ledtrig-transient.o obj-$(CONFIG_LEDS_TRIGGER_CAMERA) += ledtrig-camera.o obj-$(CONFIG_LEDS_TRIGGER_PANIC) += ledtrig-panic.o
[PATCH v11 1/2] leds: core: Introduce LED pattern trigger
This patch adds one new led trigger that LED device can configure the software or hardware pattern and trigger it. Consumers can write 'pattern' file to enable the software pattern which alters the brightness for the specified duration with one software timer. Moreover consumers can write 'hw_pattern' file to enable the hardware pattern for some LED controllers which can autonomously control brightness over time, according to some preprogrammed hardware patterns. Signed-off-by: Raphael Teysseyre Signed-off-by: Baolin Wang --- Changes from v10: - Change 'int' to 'u32' for delta_t field. Changes from v9: - None. Changes from v8: - None. Changes from v7: - Move the SC27XX hardware patterns description into its own ABI file. Changes from v6: - Improve commit message. - Optimize the description of the hw_pattern file. - Simplify some logics. Changes from v5: - Add one 'hw_pattern' file for hardware patterns. Changes from v4: - Change the repeat file to return the originally written number. - Improve comments. - Fix some build warnings. Changes from v3: - Reset pattern number to 0 if user provides incorrect pattern string. - Support one pattern. Changes from v2: - Remove hardware_pattern boolen. - Chnage the pattern string format. Changes from v1: - Use ATTRIBUTE_GROUPS() to define attributes. - Introduce hardware_pattern flag to determine if software pattern or hardware pattern. - Re-implement pattern_trig_store_pattern() function. - Remove pattern_get() interface. - Improve comments. - Other small optimization. --- .../ABI/testing/sysfs-class-led-trigger-pattern| 38 +++ drivers/leds/trigger/Kconfig |7 + drivers/leds/trigger/Makefile |1 + drivers/leds/trigger/ledtrig-pattern.c | 337 include/linux/leds.h | 16 + 5 files changed, 399 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-pattern create mode 100644 drivers/leds/trigger/ledtrig-pattern.c diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern new file mode 100644 index 000..8cc5099 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern @@ -0,0 +1,38 @@ +What: /sys/class/leds//pattern +Date: September 2018 +KernelVersion: 4.20 +Description: + Specify a software pattern for the LED, that supports altering + the brightness for the specified duration with one software + timer. + + The pattern is given by a series of tuples, of brightness and + duration (ms). The LED is expected to traverse the series and + each brightness value for the specified duration. Duration of + 0 means brightness should immediately change to new value. + + The format of the software pattern values should be: + "brightness_1 duration_1 brightness_2 duration_2 brightness_3 + duration_3 ...". + +What: /sys/class/leds//hw_pattern +Date: September 2018 +KernelVersion: 4.20 +Description: + Specify a hardware pattern for the LED, for LED hardware that + supports autonomously controlling brightness over time, according + to some preprogrammed hardware patterns. + + Since different LED hardware can have different semantics of + hardware patterns, each driver is expected to provide its own + description for the hardware patterns in their ABI documentation + file. + +What: /sys/class/leds//repeat +Date: September 2018 +KernelVersion: 4.20 +Description: + Specify a pattern repeat number. 0 means repeat indefinitely. + + This file will always return the originally written repeat + number. diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig index 4018af7..b76fc3c 100644 --- a/drivers/leds/trigger/Kconfig +++ b/drivers/leds/trigger/Kconfig @@ -129,4 +129,11 @@ config LEDS_TRIGGER_NETDEV This allows LEDs to be controlled by network device activity. If unsure, say Y. +config LEDS_TRIGGER_PATTERN + tristate "LED Pattern Trigger" + help + This allows LEDs to be controlled by a software or hardware pattern + which is a series of tuples, of brightness and duration (ms). + If unsure, say N + endif # LEDS_TRIGGERS diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile index f3cfe19..9bcb64e 100644 --- a/drivers/leds/trigger/Makefile +++ b/drivers/leds/trigger/Makefile @@ -13,3 +13,4 @@ obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT) += ledtrig-transient.o obj-$(CONFIG_LEDS_TRIGGER_CAMERA) += ledtrig-camera.o obj-$(CONFIG_LEDS_TRIGGER_PANIC) += ledtrig-panic.o
Re: [PATCH v2 1/8] perf/x86: add a function to get the lbr stack
> +int perf_get_lbr_stack(struct perf_lbr_stack *stack)
> +{
> + stack->lbr_nr = x86_pmu.lbr_nr;
> + stack->lbr_tos = x86_pmu.lbr_tos;
> + stack->lbr_from = x86_pmu.lbr_from;
> + stack->lbr_to = x86_pmu.lbr_to;
> +
> + if (x86_pmu.intel_cap.lbr_format == LBR_FORMAT_INFO)
> + stack->lbr_info = MSR_LBR_INFO_0;
> + else
> + stack->lbr_info = 0;
Seems weird to export the enum value if the enum isn't exported.
How can it be used?
-Andi
[PATCH v11 2/2] leds: sc27xx: Add pattern_set/clear interfaces for LED controller
This patch implements the 'pattern_set'and 'pattern_clear'
interfaces to support SC27XX LED breathing mode.
Signed-off-by: Baolin Wang
Acked-by: Pavel Machek
---
Changes from v10:
- Add duration alignment function suggested by Jacek.
- Add acked tag from Pavel.
Changes from v9:
- Optimize the ABI documentation file.
- Update the brightness value in hardware pattern mode.
Changes from v8:
- Optimize the ABI documentation file.
Changes from v7:
- Add its own ABI documentation file.
Changes from v6:
- None.
Changes from v5:
- None.
Changes from v4:
- None.
Changes from v3:
- None.
Changes from v2:
- None.
Changes from v1:
- Remove pattern_get interface.
---
.../ABI/testing/sysfs-class-led-driver-sc27xx | 22
drivers/leds/leds-sc27xx-bltc.c| 121
2 files changed, 143 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
new file mode 100644
index 000..45b1e60
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
@@ -0,0 +1,22 @@
+What: /sys/class/leds//hw_pattern
+Date: September 2018
+KernelVersion: 4.20
+Description:
+ Specify a hardware pattern for the SC27XX LED. For the SC27XX
+ LED controller, it only supports 4 stages to make a single
+ hardware pattern, which is used to configure the rise time,
+ high time, fall time and low time for the breathing mode.
+
+ For the breathing mode, the SC27XX LED only expects one
brightness
+ for the high stage. To be compatible with the hardware pattern
+ format, we should set brightness as 0 for rise stage, fall
+ stage and low stage.
+
+ Min stage duration: 125 ms
+ Max stage duration: 31875 ms
+
+ Since the stage duration step is 125 ms, the duration should be
+ a multiplier of 125, like 125ms, 250ms, 375ms, 500ms ...
31875ms.
+
+ Thus the format of the hardware pattern values should be:
+ "0 rise_duration brightness high_duration 0 fall_duration 0
low_duration".
diff --git a/drivers/leds/leds-sc27xx-bltc.c b/drivers/leds/leds-sc27xx-bltc.c
index 9d9b7aa..271e028 100644
--- a/drivers/leds/leds-sc27xx-bltc.c
+++ b/drivers/leds/leds-sc27xx-bltc.c
@@ -32,8 +32,18 @@
#define SC27XX_DUTY_MASK GENMASK(15, 0)
#define SC27XX_MOD_MASKGENMASK(7, 0)
+#define SC27XX_CURVE_SHIFT 8
+#define SC27XX_CURVE_L_MASKGENMASK(7, 0)
+#define SC27XX_CURVE_H_MASKGENMASK(15, 8)
+
#define SC27XX_LEDS_OFFSET 0x10
#define SC27XX_LEDS_MAX3
+#define SC27XX_LEDS_PATTERN_CNT4
+/* Stage duration step, in milliseconds */
+#define SC27XX_LEDS_STEP 125
+/* Minimum and maximum duration, in milliseconds */
+#define SC27XX_DELTA_T_MIN SC27XX_LEDS_STEP
+#define SC27XX_DELTA_T_MAX (SC27XX_LEDS_STEP * 255)
struct sc27xx_led {
char name[LED_MAX_NAME_SIZE];
@@ -122,6 +132,113 @@ static int sc27xx_led_set(struct led_classdev *ldev, enum
led_brightness value)
return err;
}
+static void sc27xx_led_clamp_align_delta_t(u32 *delta_t)
+{
+ u32 v, offset, t = *delta_t;
+
+ v = t + SC27XX_LEDS_STEP / 2;
+ v = clamp_t(u32, v, SC27XX_DELTA_T_MIN, SC27XX_DELTA_T_MAX);
+ offset = v - SC27XX_DELTA_T_MIN;
+ offset = SC27XX_LEDS_STEP * (offset / SC27XX_LEDS_STEP);
+
+ *delta_t = SC27XX_DELTA_T_MIN + offset;
+}
+
+static int sc27xx_led_pattern_clear(struct led_classdev *ldev)
+{
+ struct sc27xx_led *leds = to_sc27xx_led(ldev);
+ struct regmap *regmap = leds->priv->regmap;
+ u32 base = sc27xx_led_get_offset(leds);
+ u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
+ u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
+ int err;
+
+ mutex_lock(>priv->lock);
+
+ /* Reset the rise, high, fall and low time to zero. */
+ regmap_write(regmap, base + SC27XX_LEDS_CURVE0, 0);
+ regmap_write(regmap, base + SC27XX_LEDS_CURVE1, 0);
+
+ err = regmap_update_bits(regmap, ctrl_base,
+ (SC27XX_LED_RUN | SC27XX_LED_TYPE) << ctrl_shift, 0);
+
+ ldev->brightness = LED_OFF;
+
+ mutex_unlock(>priv->lock);
+
+ return err;
+}
+
+static int sc27xx_led_pattern_set(struct led_classdev *ldev,
+ struct led_pattern *pattern,
+ int len, u32 repeat)
+{
+ struct sc27xx_led *leds = to_sc27xx_led(ldev);
+ u32 base = sc27xx_led_get_offset(leds);
+ u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
+ u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
+ struct regmap *regmap = leds->priv->regmap;
+ int err;
+
+ /*
+* Must contain 4
Re: [PATCH v2 1/8] perf/x86: add a function to get the lbr stack
> +int perf_get_lbr_stack(struct perf_lbr_stack *stack)
> +{
> + stack->lbr_nr = x86_pmu.lbr_nr;
> + stack->lbr_tos = x86_pmu.lbr_tos;
> + stack->lbr_from = x86_pmu.lbr_from;
> + stack->lbr_to = x86_pmu.lbr_to;
> +
> + if (x86_pmu.intel_cap.lbr_format == LBR_FORMAT_INFO)
> + stack->lbr_info = MSR_LBR_INFO_0;
> + else
> + stack->lbr_info = 0;
Seems weird to export the enum value if the enum isn't exported.
How can it be used?
-Andi
[PATCH v11 2/2] leds: sc27xx: Add pattern_set/clear interfaces for LED controller
This patch implements the 'pattern_set'and 'pattern_clear'
interfaces to support SC27XX LED breathing mode.
Signed-off-by: Baolin Wang
Acked-by: Pavel Machek
---
Changes from v10:
- Add duration alignment function suggested by Jacek.
- Add acked tag from Pavel.
Changes from v9:
- Optimize the ABI documentation file.
- Update the brightness value in hardware pattern mode.
Changes from v8:
- Optimize the ABI documentation file.
Changes from v7:
- Add its own ABI documentation file.
Changes from v6:
- None.
Changes from v5:
- None.
Changes from v4:
- None.
Changes from v3:
- None.
Changes from v2:
- None.
Changes from v1:
- Remove pattern_get interface.
---
.../ABI/testing/sysfs-class-led-driver-sc27xx | 22
drivers/leds/leds-sc27xx-bltc.c| 121
2 files changed, 143 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
new file mode 100644
index 000..45b1e60
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
@@ -0,0 +1,22 @@
+What: /sys/class/leds//hw_pattern
+Date: September 2018
+KernelVersion: 4.20
+Description:
+ Specify a hardware pattern for the SC27XX LED. For the SC27XX
+ LED controller, it only supports 4 stages to make a single
+ hardware pattern, which is used to configure the rise time,
+ high time, fall time and low time for the breathing mode.
+
+ For the breathing mode, the SC27XX LED only expects one
brightness
+ for the high stage. To be compatible with the hardware pattern
+ format, we should set brightness as 0 for rise stage, fall
+ stage and low stage.
+
+ Min stage duration: 125 ms
+ Max stage duration: 31875 ms
+
+ Since the stage duration step is 125 ms, the duration should be
+ a multiplier of 125, like 125ms, 250ms, 375ms, 500ms ...
31875ms.
+
+ Thus the format of the hardware pattern values should be:
+ "0 rise_duration brightness high_duration 0 fall_duration 0
low_duration".
diff --git a/drivers/leds/leds-sc27xx-bltc.c b/drivers/leds/leds-sc27xx-bltc.c
index 9d9b7aa..271e028 100644
--- a/drivers/leds/leds-sc27xx-bltc.c
+++ b/drivers/leds/leds-sc27xx-bltc.c
@@ -32,8 +32,18 @@
#define SC27XX_DUTY_MASK GENMASK(15, 0)
#define SC27XX_MOD_MASKGENMASK(7, 0)
+#define SC27XX_CURVE_SHIFT 8
+#define SC27XX_CURVE_L_MASKGENMASK(7, 0)
+#define SC27XX_CURVE_H_MASKGENMASK(15, 8)
+
#define SC27XX_LEDS_OFFSET 0x10
#define SC27XX_LEDS_MAX3
+#define SC27XX_LEDS_PATTERN_CNT4
+/* Stage duration step, in milliseconds */
+#define SC27XX_LEDS_STEP 125
+/* Minimum and maximum duration, in milliseconds */
+#define SC27XX_DELTA_T_MIN SC27XX_LEDS_STEP
+#define SC27XX_DELTA_T_MAX (SC27XX_LEDS_STEP * 255)
struct sc27xx_led {
char name[LED_MAX_NAME_SIZE];
@@ -122,6 +132,113 @@ static int sc27xx_led_set(struct led_classdev *ldev, enum
led_brightness value)
return err;
}
+static void sc27xx_led_clamp_align_delta_t(u32 *delta_t)
+{
+ u32 v, offset, t = *delta_t;
+
+ v = t + SC27XX_LEDS_STEP / 2;
+ v = clamp_t(u32, v, SC27XX_DELTA_T_MIN, SC27XX_DELTA_T_MAX);
+ offset = v - SC27XX_DELTA_T_MIN;
+ offset = SC27XX_LEDS_STEP * (offset / SC27XX_LEDS_STEP);
+
+ *delta_t = SC27XX_DELTA_T_MIN + offset;
+}
+
+static int sc27xx_led_pattern_clear(struct led_classdev *ldev)
+{
+ struct sc27xx_led *leds = to_sc27xx_led(ldev);
+ struct regmap *regmap = leds->priv->regmap;
+ u32 base = sc27xx_led_get_offset(leds);
+ u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
+ u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
+ int err;
+
+ mutex_lock(>priv->lock);
+
+ /* Reset the rise, high, fall and low time to zero. */
+ regmap_write(regmap, base + SC27XX_LEDS_CURVE0, 0);
+ regmap_write(regmap, base + SC27XX_LEDS_CURVE1, 0);
+
+ err = regmap_update_bits(regmap, ctrl_base,
+ (SC27XX_LED_RUN | SC27XX_LED_TYPE) << ctrl_shift, 0);
+
+ ldev->brightness = LED_OFF;
+
+ mutex_unlock(>priv->lock);
+
+ return err;
+}
+
+static int sc27xx_led_pattern_set(struct led_classdev *ldev,
+ struct led_pattern *pattern,
+ int len, u32 repeat)
+{
+ struct sc27xx_led *leds = to_sc27xx_led(ldev);
+ u32 base = sc27xx_led_get_offset(leds);
+ u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
+ u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
+ struct regmap *regmap = leds->priv->regmap;
+ int err;
+
+ /*
+* Must contain 4
Re: [PATCH v2 6/8] perf/x86/intel/lbr: guest requesting KVM for lbr stack save/restore
On Thu, Sep 06, 2018 at 07:30:54PM +0800, Wei Wang wrote: > This patch adds an interface to enable a guest to request KVM to save > and restore the lbr stack on vCPU context switching. > > KVM couldn't capture the info about whether the guest is actively using > the lbr feature via the lbr enable bit in the debugctl MSR, because that > control bit is frequently enabled and disabled by the guest, and in some > csaes, it is disabled even when the guest is actively using the lbr > feature. For example, perf_pmu_sched_task in the guest disables the bit > before reading out the lbr stack. In this case, the bit is disabled though > the guest is still using the lbr feature. > > So, a KVM-specific MSR, MSR_KVM_PV_LBR_CTRL, is used by the guest at a > proper place to tell KVM if the LBR is actively in use or not. Basically, > the lbr user callstack mode needs the lbr stack to be saved/restored on a > context switching, so we set the ACTIVE bit of MSR_KVM_PV_LBR_CTRL only > when the user callstack mode is used. The KVM hypervisor will add the lbr > stack save/restore support on vCPU switching after the ACTIVE bit is set. PV is difficult because it requires changing all the users. Maybe a better approach would be a lazy restore of the LBRs: Don't restore the LBRs on context switch, but set the LBR MSRs to intercept. Then on the first access restore the LBRs and allow direct access to the MSRs again. Also when the LBRs haven't been set to direct access the state doesn't need to be saved. -Andi
Re: [PATCH v2 6/8] perf/x86/intel/lbr: guest requesting KVM for lbr stack save/restore
On Thu, Sep 06, 2018 at 07:30:54PM +0800, Wei Wang wrote: > This patch adds an interface to enable a guest to request KVM to save > and restore the lbr stack on vCPU context switching. > > KVM couldn't capture the info about whether the guest is actively using > the lbr feature via the lbr enable bit in the debugctl MSR, because that > control bit is frequently enabled and disabled by the guest, and in some > csaes, it is disabled even when the guest is actively using the lbr > feature. For example, perf_pmu_sched_task in the guest disables the bit > before reading out the lbr stack. In this case, the bit is disabled though > the guest is still using the lbr feature. > > So, a KVM-specific MSR, MSR_KVM_PV_LBR_CTRL, is used by the guest at a > proper place to tell KVM if the LBR is actively in use or not. Basically, > the lbr user callstack mode needs the lbr stack to be saved/restored on a > context switching, so we set the ACTIVE bit of MSR_KVM_PV_LBR_CTRL only > when the user callstack mode is used. The KVM hypervisor will add the lbr > stack save/restore support on vCPU switching after the ACTIVE bit is set. PV is difficult because it requires changing all the users. Maybe a better approach would be a lazy restore of the LBRs: Don't restore the LBRs on context switch, but set the LBR MSRs to intercept. Then on the first access restore the LBRs and allow direct access to the MSRs again. Also when the LBRs haven't been set to direct access the state doesn't need to be saved. -Andi
[PATCH] lib: rbtree: Fixed assign coding style issue
Fixed coding style issue.
Signed-off-by: Pablo Pellecchia
---
lib/rbtree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/rbtree.c b/lib/rbtree.c
index d3ff682fd4b8..c47745c39671 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -539,7 +539,7 @@ struct rb_node *rb_next(const struct rb_node *node)
if (node->rb_right) {
node = node->rb_right;
while (node->rb_left)
- node=node->rb_left;
+ node = node->rb_left;
return (struct rb_node *)node;
}
--
2.14.1
[PATCH] lib: rbtree: Fixed assign coding style issue
Fixed coding style issue.
Signed-off-by: Pablo Pellecchia
---
lib/rbtree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/rbtree.c b/lib/rbtree.c
index d3ff682fd4b8..c47745c39671 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -539,7 +539,7 @@ struct rb_node *rb_next(const struct rb_node *node)
if (node->rb_right) {
node = node->rb_right;
while (node->rb_left)
- node=node->rb_left;
+ node = node->rb_left;
return (struct rb_node *)node;
}
--
2.14.1
Re: [PATCH] ASoC: max98373: usleep_range() needs include/delay.h
Hi Grant, On Thu, Sep 06, 2018 at 05:27:28PM -0700, Grant Grundler wrote: > Commit ca917f9fe1a0fab added use of usleep_range() but not > the corresponding "include ". The result is > with Chrome OS won't build because warnings are forced > to be errors: > mnt/host/source/src/third_party/kernel/v4.4/sound/soc/codecs/max98373.c:734:2: > error: implicit declaration of function 'usleep_range' > [-Werror,-Wimplicit-function-declaration] > usleep_range(1, 11000); > ^ > > Including delay.h "fixes" this. > > Signed-off-by: Grant Grundler Reviewed-by: Benson Leung Thanks! -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH] ASoC: max98373: usleep_range() needs include/delay.h
Hi Grant, On Thu, Sep 06, 2018 at 05:27:28PM -0700, Grant Grundler wrote: > Commit ca917f9fe1a0fab added use of usleep_range() but not > the corresponding "include ". The result is > with Chrome OS won't build because warnings are forced > to be errors: > mnt/host/source/src/third_party/kernel/v4.4/sound/soc/codecs/max98373.c:734:2: > error: implicit declaration of function 'usleep_range' > [-Werror,-Wimplicit-function-declaration] > usleep_range(1, 11000); > ^ > > Including delay.h "fixes" this. > > Signed-off-by: Grant Grundler Reviewed-by: Benson Leung Thanks! -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH V3 09/26] csky: VDSO and rt_sigreturn
On Thu, Sep 06, 2018 at 04:02:42PM +0200, Arnd Bergmann wrote:
> On Wed, Sep 5, 2018 at 2:08 PM Guo Ren wrote:
>
> > +
> > + /*
> > +* __NR_rt_sigreturn must be 173
> > +* Because gcc/config/csky/linux-unwind.h use hard code to parse
> > rt_sigframe.
> > +*/
> > + err = setup_vdso_page(vdso->rt_signal_retcode);
> > + if (err) panic("Cannot set signal return code, err: %x.", err);
>
> __NR_rt_sigreturn is 139
Yes, we've changed to use asm-generic define, and I forgot to update the
comment.
Guo Ren
Re: [PATCH V3 09/26] csky: VDSO and rt_sigreturn
On Thu, Sep 06, 2018 at 04:02:42PM +0200, Arnd Bergmann wrote:
> On Wed, Sep 5, 2018 at 2:08 PM Guo Ren wrote:
>
> > +
> > + /*
> > +* __NR_rt_sigreturn must be 173
> > +* Because gcc/config/csky/linux-unwind.h use hard code to parse
> > rt_sigframe.
> > +*/
> > + err = setup_vdso_page(vdso->rt_signal_retcode);
> > + if (err) panic("Cannot set signal return code, err: %x.", err);
>
> __NR_rt_sigreturn is 139
Yes, we've changed to use asm-generic define, and I forgot to update the
comment.
Guo Ren
linux-next: manual merge of the kspp tree with the tip tree
Hi Kees,
Today's linux-next merge of the kspp tree got a conflict in:
drivers/misc/lkdtm/core.c
between commit:
bef459026b16 ("lkdtm: Test copy_to_user() on bad kernel pointer under
KERNEL_DS")
from the tip tree and commit:
f90d1e0c7804 ("lkdtm: Add a test for STACKLEAK")
from the kspp tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/misc/lkdtm/core.c
index 5a755590d3dc,aca26d81e9b8..
--- a/drivers/misc/lkdtm/core.c
+++ b/drivers/misc/lkdtm/core.c
@@@ -183,7 -183,7 +183,8 @@@ static const struct crashtype crashtype
CRASHTYPE(USERCOPY_STACK_FRAME_FROM),
CRASHTYPE(USERCOPY_STACK_BEYOND),
CRASHTYPE(USERCOPY_KERNEL),
+ CRASHTYPE(USERCOPY_KERNEL_DS),
+ CRASHTYPE(STACKLEAK_ERASING),
};
pgpc_R5k95RSd.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the kspp tree with the tip tree
Hi Kees,
Today's linux-next merge of the kspp tree got a conflict in:
drivers/misc/lkdtm/core.c
between commit:
bef459026b16 ("lkdtm: Test copy_to_user() on bad kernel pointer under
KERNEL_DS")
from the tip tree and commit:
f90d1e0c7804 ("lkdtm: Add a test for STACKLEAK")
from the kspp tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/misc/lkdtm/core.c
index 5a755590d3dc,aca26d81e9b8..
--- a/drivers/misc/lkdtm/core.c
+++ b/drivers/misc/lkdtm/core.c
@@@ -183,7 -183,7 +183,8 @@@ static const struct crashtype crashtype
CRASHTYPE(USERCOPY_STACK_FRAME_FROM),
CRASHTYPE(USERCOPY_STACK_BEYOND),
CRASHTYPE(USERCOPY_KERNEL),
+ CRASHTYPE(USERCOPY_KERNEL_DS),
+ CRASHTYPE(STACKLEAK_ERASING),
};
pgpc_R5k95RSd.pgp
Description: OpenPGP digital signature
Re: [PATCH V3 06/26] csky: Cache and TLB routines
On Thu, Sep 06, 2018 at 04:31:16PM +0200, Arnd Bergmann wrote: > On Wed, Sep 5, 2018 at 2:08 PM Guo Ren wrote: > > > diff --git a/arch/csky/include/asm/io.h b/arch/csky/include/asm/io.h > > new file mode 100644 > > index 000..fcb2142 > > --- /dev/null > > +++ b/arch/csky/include/asm/io.h > > @@ -0,0 +1,23 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd. > > +#ifndef __ASM_CSKY_IO_H > > +#define __ASM_CSKY_IO_H > > + > > +#include > > +#include > > +#include > > + > > +extern void __iomem *ioremap(phys_addr_t offset, size_t size); > > + > > +extern void iounmap(void *addr); > > + > > +extern int remap_area_pages(unsigned long address, phys_addr_t phys_addr, > > + size_t size, unsigned long flags); > > + > > +#define ioremap_nocache(phy, sz) ioremap(phy, sz) > > +#define ioremap_wc ioremap_nocache > > +#define ioremap_wt ioremap_nocache > > + > > +#include > > It is very unusual for an architecture to not need special handling in > asm/io.h, > to do the proper barriers etc. > > Can you describe how C-Sky hardware implements MMIO? Our mmio is uncachable and strong-order address, so there is no need barriers for access these io addr. #define ioremap_wc ioremap_nocache #define ioremap_wt ioremap_nocache Current ioremap_wc and ioremap_wt implementation are too simple and we'll improve it in future. > In particular: > > - Is a read from uncached memory always serialized with DMA, and with > other CPUs doing MMIO access to a different address? CPU use ld.w to get data from uncached strong order memory. Other CPUs use the same mmio vaddr to access the uncachable strong order memory paddr. > - How does endianess work? Are there any buses that flip bytes around > when running big-endian, or do you always do that in software? Currently we only support little-endian and soc will follow it. Guo Ren
Re: [PATCH V3 06/26] csky: Cache and TLB routines
On Thu, Sep 06, 2018 at 04:31:16PM +0200, Arnd Bergmann wrote: > On Wed, Sep 5, 2018 at 2:08 PM Guo Ren wrote: > > > diff --git a/arch/csky/include/asm/io.h b/arch/csky/include/asm/io.h > > new file mode 100644 > > index 000..fcb2142 > > --- /dev/null > > +++ b/arch/csky/include/asm/io.h > > @@ -0,0 +1,23 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd. > > +#ifndef __ASM_CSKY_IO_H > > +#define __ASM_CSKY_IO_H > > + > > +#include > > +#include > > +#include > > + > > +extern void __iomem *ioremap(phys_addr_t offset, size_t size); > > + > > +extern void iounmap(void *addr); > > + > > +extern int remap_area_pages(unsigned long address, phys_addr_t phys_addr, > > + size_t size, unsigned long flags); > > + > > +#define ioremap_nocache(phy, sz) ioremap(phy, sz) > > +#define ioremap_wc ioremap_nocache > > +#define ioremap_wt ioremap_nocache > > + > > +#include > > It is very unusual for an architecture to not need special handling in > asm/io.h, > to do the proper barriers etc. > > Can you describe how C-Sky hardware implements MMIO? Our mmio is uncachable and strong-order address, so there is no need barriers for access these io addr. #define ioremap_wc ioremap_nocache #define ioremap_wt ioremap_nocache Current ioremap_wc and ioremap_wt implementation are too simple and we'll improve it in future. > In particular: > > - Is a read from uncached memory always serialized with DMA, and with > other CPUs doing MMIO access to a different address? CPU use ld.w to get data from uncached strong order memory. Other CPUs use the same mmio vaddr to access the uncachable strong order memory paddr. > - How does endianess work? Are there any buses that flip bytes around > when running big-endian, or do you always do that in software? Currently we only support little-endian and soc will follow it. Guo Ren
[LKP] [rcutorture] 894b343aa8: WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_fwd_prog
FYI, we noticed the following commit (built with gcc-7):
commit: 894b343aa8bec5ee732329f1db09b9f5c2794de5 ("rcutorture: Add call_rcu()
flooding forward-progress tests")
https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git
dev.2018.08.30a
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -smp 2
-m 512M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+--+++
| | 93fd89934b
| 894b343aa8 |
+--+++
| boot_successes | 24
| 18 |
| boot_failures| 1
| 12 |
| invoked_oom-killer:gfp_mask=0x | 1
| 2 |
| Mem-Info | 1
| 2 |
| Out_of_memory:Kill_process | 1
||
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 0
| 2 |
| RIP:rcu_torture_fwd_prog | 0
| 10 |
| WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_fwd_prog | 0
| 9 |
+--+++
[ 307.810166] WARNING: CPU: 1 PID: 54 at kernel/rcu/rcutorture.c:1840
rcu_torture_fwd_prog+0x41f/0x542
[ 307.832010] Modules linked in:
[ 307.837737] CPU: 1 PID: 54 Comm: rcu_torture_fwd Tainted: GT
4.19.0-rc1-00151-g894b343 #1
[ 307.856076] RIP: 0010:rcu_torture_fwd_prog+0x41f/0x542
[ 307.866058] Code: b8 0e 00 eb e2 48 c7 05 c9 25 35 01 f0 fa 78 83 c6 05 92
99 67 02 00 e8 29 6c 09 00 84 c0 0f 85 af 00 00 00 49 83 fc 63 7f 02 <0f> 0b 48
8b 45 88 4f 8d 44 3d 00 4d 89 e9 48 c7 c6 a0 34 e2 81 48
[ 307.902163] RSP: 0018:88000c1cbe80 EFLAGS: 00010293
[ 307.912698] RAX: RBX: 0001 RCX: 88001046c080
[ 307.926369] RDX: 0017 RSI: 811c173d RDI: 88001046c080
[ 307.940082] RBP: 88000c1cbf00 R08: 0020 R09: 8800053e4ce0
[ 307.953984] R10: 8800053e4260 R11: 8800053e4d40 R12:
[ 307.968462] R13: 0003 R14: R15: 0083
[ 307.982466] FS: () GS:88001c40()
knlGS:
[ 307.998082] CS: 0010 DS: ES: CR0: 80050033
[ 308.009554] CR2: 7ffc7538e000 CR3: 02411004 CR4: 000206a0
[ 308.023264] Call Trace:
[ 308.028512] ? _raw_spin_unlock_irqrestore+0x45/0x4f
[ 308.038529] ? rcu_torture_stall+0x12d/0x12d
[ 308.047149] ? kthread+0x114/0x123
[ 308.054115] ? kthread+0x114/0x123
[ 308.060625] ? kthread_create_worker_on_cpu+0x5f/0x5f
[ 308.069703] ? ret_from_fork+0x3a/0x50
[ 308.076537] irq event stamp: 3048
[ 308.082507] hardirqs last enabled at (3047): []
kfree+0x125/0x136
[ 308.097831] hardirqs last disabled at (3048): []
trace_hardirqs_off_thunk+0x1a/0x1c
[ 308.115656] softirqs last enabled at (56): []
__do_softirq+0x359/0x39b
[ 308.130979] softirqs last disabled at (49): []
irq_exit+0x59/0x75
[ 308.145115] ---[ end trace 3654c8b0e1b99cb1 ]---
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Rong, Chen
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.19.0-rc1 Kernel Configuration
#
#
# Compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=70300
CONFIG_CLANG_VERSION=0
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
[LKP] [rcutorture] 894b343aa8: WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_fwd_prog
FYI, we noticed the following commit (built with gcc-7):
commit: 894b343aa8bec5ee732329f1db09b9f5c2794de5 ("rcutorture: Add call_rcu()
flooding forward-progress tests")
https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git
dev.2018.08.30a
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -smp 2
-m 512M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+--+++
| | 93fd89934b
| 894b343aa8 |
+--+++
| boot_successes | 24
| 18 |
| boot_failures| 1
| 12 |
| invoked_oom-killer:gfp_mask=0x | 1
| 2 |
| Mem-Info | 1
| 2 |
| Out_of_memory:Kill_process | 1
||
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 0
| 2 |
| RIP:rcu_torture_fwd_prog | 0
| 10 |
| WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_fwd_prog | 0
| 9 |
+--+++
[ 307.810166] WARNING: CPU: 1 PID: 54 at kernel/rcu/rcutorture.c:1840
rcu_torture_fwd_prog+0x41f/0x542
[ 307.832010] Modules linked in:
[ 307.837737] CPU: 1 PID: 54 Comm: rcu_torture_fwd Tainted: GT
4.19.0-rc1-00151-g894b343 #1
[ 307.856076] RIP: 0010:rcu_torture_fwd_prog+0x41f/0x542
[ 307.866058] Code: b8 0e 00 eb e2 48 c7 05 c9 25 35 01 f0 fa 78 83 c6 05 92
99 67 02 00 e8 29 6c 09 00 84 c0 0f 85 af 00 00 00 49 83 fc 63 7f 02 <0f> 0b 48
8b 45 88 4f 8d 44 3d 00 4d 89 e9 48 c7 c6 a0 34 e2 81 48
[ 307.902163] RSP: 0018:88000c1cbe80 EFLAGS: 00010293
[ 307.912698] RAX: RBX: 0001 RCX: 88001046c080
[ 307.926369] RDX: 0017 RSI: 811c173d RDI: 88001046c080
[ 307.940082] RBP: 88000c1cbf00 R08: 0020 R09: 8800053e4ce0
[ 307.953984] R10: 8800053e4260 R11: 8800053e4d40 R12:
[ 307.968462] R13: 0003 R14: R15: 0083
[ 307.982466] FS: () GS:88001c40()
knlGS:
[ 307.998082] CS: 0010 DS: ES: CR0: 80050033
[ 308.009554] CR2: 7ffc7538e000 CR3: 02411004 CR4: 000206a0
[ 308.023264] Call Trace:
[ 308.028512] ? _raw_spin_unlock_irqrestore+0x45/0x4f
[ 308.038529] ? rcu_torture_stall+0x12d/0x12d
[ 308.047149] ? kthread+0x114/0x123
[ 308.054115] ? kthread+0x114/0x123
[ 308.060625] ? kthread_create_worker_on_cpu+0x5f/0x5f
[ 308.069703] ? ret_from_fork+0x3a/0x50
[ 308.076537] irq event stamp: 3048
[ 308.082507] hardirqs last enabled at (3047): []
kfree+0x125/0x136
[ 308.097831] hardirqs last disabled at (3048): []
trace_hardirqs_off_thunk+0x1a/0x1c
[ 308.115656] softirqs last enabled at (56): []
__do_softirq+0x359/0x39b
[ 308.130979] softirqs last disabled at (49): []
irq_exit+0x59/0x75
[ 308.145115] ---[ end trace 3654c8b0e1b99cb1 ]---
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Rong, Chen
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.19.0-rc1 Kernel Configuration
#
#
# Compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=70300
CONFIG_CLANG_VERSION=0
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
Re: [PATCH v10 2/2] leds: sc27xx: Add pattern_set/clear interfaces for LED controller
Hi Pavel, On 7 September 2018 at 05:16, Pavel Machek wrote: > Hi! > >> diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx >> b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx >> new file mode 100644 >> index 000..d8056d5 >> --- /dev/null >> +++ b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx >> @@ -0,0 +1,22 @@ >> +What:/sys/class/leds//hw_pattern >> +Date:September 2018 >> +KernelVersion: 4.20 >> +Description: >> + Specify a hardware pattern for the SC27XX LED. For the SC27XX >> + LED controller, it only supports 4 stages to make a single >> + hardware pattern, which is used to configure the rise time, >> + high time, fall time and low time for the breathing mode. >> + >> + For the breathing mode, the SC27XX LED only expects one >> brightness >> + for the high stage. To be compatible with the hardware pattern >> + format, we should set brightness as 0 for rise stage, fall >> + stage and low stage. >> + >> + Min stage duration: 125 ms >> + Max stage duration: 31875 ms >> + >> + Since the stage duration step is 125 ms, the duration must be >> + a multiplier of 125, like 125ms, 250ms, 375ms, 500ms ... >> 31875ms. >> + >> + Thus the format of the hardware pattern values should be: >> + "0 rise_duration brightness high_duration 0 fall_duration 0 >> low_duration". > > If I'm not mistaken, this is: > > "0 rise_duration brightness high_duration brightness > fall_duration 0 low_duration". > > Right? Hmmm, for SC27XX led, there is no need to set brightness for rise and fall stage. > > With that fixed: > > Acked-by: Pavel Machek Thanks. -- Baolin Wang Best Regards
Re: [PATCH v10 2/2] leds: sc27xx: Add pattern_set/clear interfaces for LED controller
Hi Pavel, On 7 September 2018 at 05:16, Pavel Machek wrote: > Hi! > >> diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx >> b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx >> new file mode 100644 >> index 000..d8056d5 >> --- /dev/null >> +++ b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx >> @@ -0,0 +1,22 @@ >> +What:/sys/class/leds//hw_pattern >> +Date:September 2018 >> +KernelVersion: 4.20 >> +Description: >> + Specify a hardware pattern for the SC27XX LED. For the SC27XX >> + LED controller, it only supports 4 stages to make a single >> + hardware pattern, which is used to configure the rise time, >> + high time, fall time and low time for the breathing mode. >> + >> + For the breathing mode, the SC27XX LED only expects one >> brightness >> + for the high stage. To be compatible with the hardware pattern >> + format, we should set brightness as 0 for rise stage, fall >> + stage and low stage. >> + >> + Min stage duration: 125 ms >> + Max stage duration: 31875 ms >> + >> + Since the stage duration step is 125 ms, the duration must be >> + a multiplier of 125, like 125ms, 250ms, 375ms, 500ms ... >> 31875ms. >> + >> + Thus the format of the hardware pattern values should be: >> + "0 rise_duration brightness high_duration 0 fall_duration 0 >> low_duration". > > If I'm not mistaken, this is: > > "0 rise_duration brightness high_duration brightness > fall_duration 0 low_duration". > > Right? Hmmm, for SC27XX led, there is no need to set brightness for rise and fall stage. > > With that fixed: > > Acked-by: Pavel Machek Thanks. -- Baolin Wang Best Regards
Re: [PATCH v10 2/2] leds: sc27xx: Add pattern_set/clear interfaces for LED controller
Hi Jacek,
On 7 September 2018 at 04:16, Jacek Anaszewski
wrote:
> Hi Baolin,
>
> Thank you for the patch. I really appreciate your effort.
>
> I see one more thing I forgot to mention in the previous
> review. Please take a look at my comment to pattern_set().
>
> On 09/06/2018 04:37 AM, Baolin Wang wrote:
>> This patch implements the 'pattern_set'and 'pattern_clear'
>> interfaces to support SC27XX LED breathing mode.
>>
>> Signed-off-by: Baolin Wang
>> ---
>> Changes from v9:
>> - Optimize the ABI documentation file.
>> - Update the brightness value in hardware pattern mode.
>>
>> Changes from v8:
>> - Optimize the ABI documentation file.
>>
>> Changes from v7:
>> - Add its own ABI documentation file.
>>
>> Changes from v6:
>> - None.
>>
>> Changes from v5:
>> - None.
>>
>> Changes from v4:
>> - None.
>>
>> Changes from v3:
>> - None.
>>
>> Changes from v2:
>> - None.
>>
>> Changes from v1:
>> - Remove pattern_get interface.
>> ---
>> .../ABI/testing/sysfs-class-led-driver-sc27xx | 22 +
>> drivers/leds/leds-sc27xx-bltc.c| 103
>>
>> 2 files changed, 125 insertions(+)
>> create mode 100644 Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
>>
>> diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
>> b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
>> new file mode 100644
>> index 000..d8056d5
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
>> @@ -0,0 +1,22 @@
>> +What:/sys/class/leds//hw_pattern
>> +Date:September 2018
>> +KernelVersion: 4.20
>> +Description:
>> + Specify a hardware pattern for the SC27XX LED. For the SC27XX
>> + LED controller, it only supports 4 stages to make a single
>> + hardware pattern, which is used to configure the rise time,
>> + high time, fall time and low time for the breathing mode.
>> +
>> + For the breathing mode, the SC27XX LED only expects one
>> brightness
>> + for the high stage. To be compatible with the hardware pattern
>> + format, we should set brightness as 0 for rise stage, fall
>> + stage and low stage.
>> +
>> + Min stage duration: 125 ms
>> + Max stage duration: 31875 ms
>> +
>> + Since the stage duration step is 125 ms, the duration must be
>> + a multiplier of 125, like 125ms, 250ms, 375ms, 500ms ...
>> 31875ms.
>> +
>> + Thus the format of the hardware pattern values should be:
>> + "0 rise_duration brightness high_duration 0 fall_duration 0
>> low_duration".
>> diff --git a/drivers/leds/leds-sc27xx-bltc.c
>> b/drivers/leds/leds-sc27xx-bltc.c
>> index 9d9b7aa..558a325 100644
>> --- a/drivers/leds/leds-sc27xx-bltc.c
>> +++ b/drivers/leds/leds-sc27xx-bltc.c
>> @@ -32,8 +32,15 @@
>> #define SC27XX_DUTY_MASK GENMASK(15, 0)
>> #define SC27XX_MOD_MASK GENMASK(7, 0)
>>
>> +#define SC27XX_CURVE_SHIFT 8
>> +#define SC27XX_CURVE_L_MASK GENMASK(7, 0)
>> +#define SC27XX_CURVE_H_MASK GENMASK(15, 8)
>> +
>> #define SC27XX_LEDS_OFFSET 0x10
>> #define SC27XX_LEDS_MAX 3
>> +#define SC27XX_LEDS_PATTERN_CNT 4
>> +/* Stage duration step, in milliseconds */
>> +#define SC27XX_LEDS_STEP 125
>>
>> struct sc27xx_led {
>> char name[LED_MAX_NAME_SIZE];
>> @@ -122,6 +129,98 @@ static int sc27xx_led_set(struct led_classdev *ldev,
>> enum led_brightness value)
>> return err;
>> }
>>
>> +static int sc27xx_led_pattern_clear(struct led_classdev *ldev)
>> +{
>> + struct sc27xx_led *leds = to_sc27xx_led(ldev);
>> + struct regmap *regmap = leds->priv->regmap;
>> + u32 base = sc27xx_led_get_offset(leds);
>> + u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
>> + u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
>> + int err;
>> +
>> + mutex_lock(>priv->lock);
>> +
>> + /* Reset the rise, high, fall and low time to zero. */
>> + regmap_write(regmap, base + SC27XX_LEDS_CURVE0, 0);
>> + regmap_write(regmap, base + SC27XX_LEDS_CURVE1, 0);
>> +
>> + err = regmap_update_bits(regmap, ctrl_base,
>> + (SC27XX_LED_RUN | SC27XX_LED_TYPE) << ctrl_shift, 0);
>> +
>> + ldev->brightness = LED_OFF;
>> +
>> + mutex_unlock(>priv->lock);
>> +
>> + return err;
>> +}
>> +
>> +static int sc27xx_led_pattern_set(struct led_classdev *ldev,
>> + struct led_pattern *pattern,
>> + int len, u32 repeat)
>> +{
>> + struct sc27xx_led *leds = to_sc27xx_led(ldev);
>> + u32 base = sc27xx_led_get_offset(leds);
>> + u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
>> + u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
>> + struct regmap *regmap = leds->priv->regmap;
>> + int err;
>> +
>> + /*
>> + * Must contain 4 tuples to configure the rise time, high
Re: [PATCH v10 2/2] leds: sc27xx: Add pattern_set/clear interfaces for LED controller
Hi Jacek,
On 7 September 2018 at 04:16, Jacek Anaszewski
wrote:
> Hi Baolin,
>
> Thank you for the patch. I really appreciate your effort.
>
> I see one more thing I forgot to mention in the previous
> review. Please take a look at my comment to pattern_set().
>
> On 09/06/2018 04:37 AM, Baolin Wang wrote:
>> This patch implements the 'pattern_set'and 'pattern_clear'
>> interfaces to support SC27XX LED breathing mode.
>>
>> Signed-off-by: Baolin Wang
>> ---
>> Changes from v9:
>> - Optimize the ABI documentation file.
>> - Update the brightness value in hardware pattern mode.
>>
>> Changes from v8:
>> - Optimize the ABI documentation file.
>>
>> Changes from v7:
>> - Add its own ABI documentation file.
>>
>> Changes from v6:
>> - None.
>>
>> Changes from v5:
>> - None.
>>
>> Changes from v4:
>> - None.
>>
>> Changes from v3:
>> - None.
>>
>> Changes from v2:
>> - None.
>>
>> Changes from v1:
>> - Remove pattern_get interface.
>> ---
>> .../ABI/testing/sysfs-class-led-driver-sc27xx | 22 +
>> drivers/leds/leds-sc27xx-bltc.c| 103
>>
>> 2 files changed, 125 insertions(+)
>> create mode 100644 Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
>>
>> diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
>> b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
>> new file mode 100644
>> index 000..d8056d5
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
>> @@ -0,0 +1,22 @@
>> +What:/sys/class/leds//hw_pattern
>> +Date:September 2018
>> +KernelVersion: 4.20
>> +Description:
>> + Specify a hardware pattern for the SC27XX LED. For the SC27XX
>> + LED controller, it only supports 4 stages to make a single
>> + hardware pattern, which is used to configure the rise time,
>> + high time, fall time and low time for the breathing mode.
>> +
>> + For the breathing mode, the SC27XX LED only expects one
>> brightness
>> + for the high stage. To be compatible with the hardware pattern
>> + format, we should set brightness as 0 for rise stage, fall
>> + stage and low stage.
>> +
>> + Min stage duration: 125 ms
>> + Max stage duration: 31875 ms
>> +
>> + Since the stage duration step is 125 ms, the duration must be
>> + a multiplier of 125, like 125ms, 250ms, 375ms, 500ms ...
>> 31875ms.
>> +
>> + Thus the format of the hardware pattern values should be:
>> + "0 rise_duration brightness high_duration 0 fall_duration 0
>> low_duration".
>> diff --git a/drivers/leds/leds-sc27xx-bltc.c
>> b/drivers/leds/leds-sc27xx-bltc.c
>> index 9d9b7aa..558a325 100644
>> --- a/drivers/leds/leds-sc27xx-bltc.c
>> +++ b/drivers/leds/leds-sc27xx-bltc.c
>> @@ -32,8 +32,15 @@
>> #define SC27XX_DUTY_MASK GENMASK(15, 0)
>> #define SC27XX_MOD_MASK GENMASK(7, 0)
>>
>> +#define SC27XX_CURVE_SHIFT 8
>> +#define SC27XX_CURVE_L_MASK GENMASK(7, 0)
>> +#define SC27XX_CURVE_H_MASK GENMASK(15, 8)
>> +
>> #define SC27XX_LEDS_OFFSET 0x10
>> #define SC27XX_LEDS_MAX 3
>> +#define SC27XX_LEDS_PATTERN_CNT 4
>> +/* Stage duration step, in milliseconds */
>> +#define SC27XX_LEDS_STEP 125
>>
>> struct sc27xx_led {
>> char name[LED_MAX_NAME_SIZE];
>> @@ -122,6 +129,98 @@ static int sc27xx_led_set(struct led_classdev *ldev,
>> enum led_brightness value)
>> return err;
>> }
>>
>> +static int sc27xx_led_pattern_clear(struct led_classdev *ldev)
>> +{
>> + struct sc27xx_led *leds = to_sc27xx_led(ldev);
>> + struct regmap *regmap = leds->priv->regmap;
>> + u32 base = sc27xx_led_get_offset(leds);
>> + u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
>> + u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
>> + int err;
>> +
>> + mutex_lock(>priv->lock);
>> +
>> + /* Reset the rise, high, fall and low time to zero. */
>> + regmap_write(regmap, base + SC27XX_LEDS_CURVE0, 0);
>> + regmap_write(regmap, base + SC27XX_LEDS_CURVE1, 0);
>> +
>> + err = regmap_update_bits(regmap, ctrl_base,
>> + (SC27XX_LED_RUN | SC27XX_LED_TYPE) << ctrl_shift, 0);
>> +
>> + ldev->brightness = LED_OFF;
>> +
>> + mutex_unlock(>priv->lock);
>> +
>> + return err;
>> +}
>> +
>> +static int sc27xx_led_pattern_set(struct led_classdev *ldev,
>> + struct led_pattern *pattern,
>> + int len, u32 repeat)
>> +{
>> + struct sc27xx_led *leds = to_sc27xx_led(ldev);
>> + u32 base = sc27xx_led_get_offset(leds);
>> + u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
>> + u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
>> + struct regmap *regmap = leds->priv->regmap;
>> + int err;
>> +
>> + /*
>> + * Must contain 4 tuples to configure the rise time, high
Re: [PATCH v2 2/9] nios2: build .dtb files in dts directory
On Wed, 2018-09-05 at 18:53 -0500, Rob Herring wrote: > Align nios2 with other architectures which build the dtb files in the > same directory as the dts files. This is also in line with most other > build targets which are located in the same directory as the source. > This move will help enable the 'dtbs' target which builds all the > dtbs > regardless of kernel config. > > This transition could break some scripts if they expect dtb files in > the old location. > > Cc: Ley Foon Tan > Cc: nios2-...@lists.rocketboards.org > Signed-off-by: Rob Herring > --- > Please ack so I can take the whole series via the DT tree. > > arch/nios2/Makefile | 4 ++-- > arch/nios2/boot/Makefile | 4 > arch/nios2/boot/dts/Makefile | 1 + > 3 files changed, 3 insertions(+), 6 deletions(-) > create mode 100644 arch/nios2/boot/dts/Makefile > > diff --git a/arch/nios2/Makefile b/arch/nios2/Makefile > index 8673a79dca9c..50eece1c6adb 100644 > --- a/arch/nios2/Makefile > +++ b/arch/nios2/Makefile > @@ -59,10 +59,10 @@ archclean: > $(Q)$(MAKE) $(clean)=$(nios2-boot) > > %.dtb: | scripts > - $(Q)$(MAKE) $(build)=$(nios2-boot) $(nios2-boot)/$@ > + $(Q)$(MAKE) $(build)=$(nios2-boot)/dts $(nios2-boot)/dts/$@ > > dtbs: > - $(Q)$(MAKE) $(build)=$(nios2-boot) $(nios2-boot)/$@ > + $(Q)$(MAKE) $(build)=$(nios2-boot)/dts > > $(BOOT_TARGETS): vmlinux > $(Q)$(MAKE) $(build)=$(nios2-boot) $(nios2-boot)/$@ > diff --git a/arch/nios2/boot/Makefile b/arch/nios2/boot/Makefile > index 2ba23a679732..007586094dde 100644 > --- a/arch/nios2/boot/Makefile > +++ b/arch/nios2/boot/Makefile > @@ -47,10 +47,6 @@ obj-$(CONFIG_NIOS2_DTB_SOURCE_BOOL) += > linked_dtb.o > > targets += $(dtb-y) > > -# Rule to build device tree blobs with make command > -$(obj)/%.dtb: $(src)/dts/%.dts FORCE > - $(call if_changed_dep,dtc) > - > $(obj)/dtbs: $(addprefix $(obj)/, $(dtb-y)) > > install: > diff --git a/arch/nios2/boot/dts/Makefile > b/arch/nios2/boot/dts/Makefile > new file mode 100644 > index ..f66554cd5c45 > --- /dev/null > +++ b/arch/nios2/boot/dts/Makefile > @@ -0,0 +1 @@ > +# SPDX-License-Identifier: GPL-2.0 > -- > 2.17.1 > Hi Rob I have synced your all-dtbs branch from here: https://git.kernel.org/pu b/scm/linux/kernel/git/robh/linux.git/log/?h=all-dtbs It shows error when compile kernel image and also when "make dtbs_install". make dtbs_install make[1]: *** No rule to make target 'arch/nios2/boot/dts/arch/nios2/boot/dts/10m50_devboard.dtb', needed by 'arch/nios2/boot/dts/arch/nios2/boot/dts/10m50_devboard.dtb.S'. Stop. Makefile:1229: recipe for target 'dtbs' failed make: *** [dtbs] Error 2 Regards Ley Foon
Re: [PATCH v2 2/9] nios2: build .dtb files in dts directory
On Wed, 2018-09-05 at 18:53 -0500, Rob Herring wrote: > Align nios2 with other architectures which build the dtb files in the > same directory as the dts files. This is also in line with most other > build targets which are located in the same directory as the source. > This move will help enable the 'dtbs' target which builds all the > dtbs > regardless of kernel config. > > This transition could break some scripts if they expect dtb files in > the old location. > > Cc: Ley Foon Tan > Cc: nios2-...@lists.rocketboards.org > Signed-off-by: Rob Herring > --- > Please ack so I can take the whole series via the DT tree. > > arch/nios2/Makefile | 4 ++-- > arch/nios2/boot/Makefile | 4 > arch/nios2/boot/dts/Makefile | 1 + > 3 files changed, 3 insertions(+), 6 deletions(-) > create mode 100644 arch/nios2/boot/dts/Makefile > > diff --git a/arch/nios2/Makefile b/arch/nios2/Makefile > index 8673a79dca9c..50eece1c6adb 100644 > --- a/arch/nios2/Makefile > +++ b/arch/nios2/Makefile > @@ -59,10 +59,10 @@ archclean: > $(Q)$(MAKE) $(clean)=$(nios2-boot) > > %.dtb: | scripts > - $(Q)$(MAKE) $(build)=$(nios2-boot) $(nios2-boot)/$@ > + $(Q)$(MAKE) $(build)=$(nios2-boot)/dts $(nios2-boot)/dts/$@ > > dtbs: > - $(Q)$(MAKE) $(build)=$(nios2-boot) $(nios2-boot)/$@ > + $(Q)$(MAKE) $(build)=$(nios2-boot)/dts > > $(BOOT_TARGETS): vmlinux > $(Q)$(MAKE) $(build)=$(nios2-boot) $(nios2-boot)/$@ > diff --git a/arch/nios2/boot/Makefile b/arch/nios2/boot/Makefile > index 2ba23a679732..007586094dde 100644 > --- a/arch/nios2/boot/Makefile > +++ b/arch/nios2/boot/Makefile > @@ -47,10 +47,6 @@ obj-$(CONFIG_NIOS2_DTB_SOURCE_BOOL) += > linked_dtb.o > > targets += $(dtb-y) > > -# Rule to build device tree blobs with make command > -$(obj)/%.dtb: $(src)/dts/%.dts FORCE > - $(call if_changed_dep,dtc) > - > $(obj)/dtbs: $(addprefix $(obj)/, $(dtb-y)) > > install: > diff --git a/arch/nios2/boot/dts/Makefile > b/arch/nios2/boot/dts/Makefile > new file mode 100644 > index ..f66554cd5c45 > --- /dev/null > +++ b/arch/nios2/boot/dts/Makefile > @@ -0,0 +1 @@ > +# SPDX-License-Identifier: GPL-2.0 > -- > 2.17.1 > Hi Rob I have synced your all-dtbs branch from here: https://git.kernel.org/pu b/scm/linux/kernel/git/robh/linux.git/log/?h=all-dtbs It shows error when compile kernel image and also when "make dtbs_install". make dtbs_install make[1]: *** No rule to make target 'arch/nios2/boot/dts/arch/nios2/boot/dts/10m50_devboard.dtb', needed by 'arch/nios2/boot/dts/arch/nios2/boot/dts/10m50_devboard.dtb.S'. Stop. Makefile:1229: recipe for target 'dtbs' failed make: *** [dtbs] Error 2 Regards Ley Foon
Re: [LKP] 0a3856392c [ 10.513760] INFO: trying to register non-static key.
On Fri, Sep 07, 2018 at 09:05:39AM +0800, kernel test robot wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> commit 0a3856392cff1542170b5bc37211c9a21fd0c3f6
> Author: Matthew Wilcox
> AuthorDate: Mon Jun 18 17:23:37 2018 -0400
> Commit: Matthew Wilcox
> CommitDate: Tue Aug 21 23:54:20 2018 -0400
>
> test_ida: Move ida_check_leaf
>
> Convert to new API and move to kernel space. Take the opportunity to
> test the situation a little more thoroughly (ie at different offsets).
>
> Signed-off-by: Matthew Wilcox
Thank you test-bot. Can you check if this patch fixes the problem?
diff --git a/lib/test_ida.c b/lib/test_ida.c
index 2d1637d8136b..b06880625961 100644
--- a/lib/test_ida.c
+++ b/lib/test_ida.c
@@ -150,10 +150,10 @@ static void ida_check_conv(struct ida *ida)
IDA_BUG_ON(ida, !ida_is_empty(ida));
}
+static DEFINE_IDA(ida);
+
static int ida_checks(void)
{
- DEFINE_IDA(ida);
-
IDA_BUG_ON(, !ida_is_empty());
ida_check_alloc();
ida_check_destroy();
Re: [LKP] 0a3856392c [ 10.513760] INFO: trying to register non-static key.
On Fri, Sep 07, 2018 at 09:05:39AM +0800, kernel test robot wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> commit 0a3856392cff1542170b5bc37211c9a21fd0c3f6
> Author: Matthew Wilcox
> AuthorDate: Mon Jun 18 17:23:37 2018 -0400
> Commit: Matthew Wilcox
> CommitDate: Tue Aug 21 23:54:20 2018 -0400
>
> test_ida: Move ida_check_leaf
>
> Convert to new API and move to kernel space. Take the opportunity to
> test the situation a little more thoroughly (ie at different offsets).
>
> Signed-off-by: Matthew Wilcox
Thank you test-bot. Can you check if this patch fixes the problem?
diff --git a/lib/test_ida.c b/lib/test_ida.c
index 2d1637d8136b..b06880625961 100644
--- a/lib/test_ida.c
+++ b/lib/test_ida.c
@@ -150,10 +150,10 @@ static void ida_check_conv(struct ida *ida)
IDA_BUG_ON(ida, !ida_is_empty(ida));
}
+static DEFINE_IDA(ida);
+
static int ida_checks(void)
{
- DEFINE_IDA(ida);
-
IDA_BUG_ON(, !ida_is_empty());
ida_check_alloc();
ida_check_destroy();
Re: Plumbers 2018 - Performance and Scalability Microconference
Christopher Lameter writes: > On Thu, 6 Sep 2018, Huang, Ying wrote: > >> > Certainly interested in attending but this overlaps supercomputing 2018 in >> > Dallas Texas... >> >> Sorry to know this. It appears that there are too many conferences in >> November... > > I will try to get to it in the middle of SC18, RDMA track and RISC V > track... Sign me up. Great to know this! Looking forward to meet you in the microconference. Best Regards, Huang, Ying
Re: Plumbers 2018 - Performance and Scalability Microconference
Christopher Lameter writes: > On Thu, 6 Sep 2018, Huang, Ying wrote: > >> > Certainly interested in attending but this overlaps supercomputing 2018 in >> > Dallas Texas... >> >> Sorry to know this. It appears that there are too many conferences in >> November... > > I will try to get to it in the middle of SC18, RDMA track and RISC V > track... Sign me up. Great to know this! Looking forward to meet you in the microconference. Best Regards, Huang, Ying
Re: [PATCH v3 5/5] x86/mm: add WARN_ON_ONCE() for wrong large page mapping
On Tue, 2018-09-04 at 18:52 +0200, Thomas Gleixner wrote:
> On Tue, 4 Sep 2018, Thomas Gleixner wrote:
> > On Tue, 4 Sep 2018, Yang, Bin wrote:
> > > On Tue, 2018-09-04 at 00:27 +0200, Thomas Gleixner wrote:
> > > > On Tue, 21 Aug 2018, Bin Yang wrote:
> > > > > @@ -625,6 +625,7 @@ try_preserve_large_page(pte_t *kpte, unsigned
> > > > > long address,
> > > > >
> > > > > psize = page_level_size(level);
> > > > > pmask = page_level_mask(level);
> > > > > + addr = address & pmask;
> > > > >
> > > > > /*
> > > > >* Calculate the number of pages, which fit into this large
> > > > > @@ -636,6 +637,12 @@ try_preserve_large_page(pte_t *kpte, unsigned
> > > > > long address,
> > > > > cpa->numpages = numpages;
> > > > >
> > > > > /*
> > > > > + * The old pgprot should not have any protection bit. Otherwise,
> > > > > + * the existing mapping is wrong already.
> > > > > + */
> > > > > + WARN_ON_ONCE(needs_static_protections(old_prot, addr, psize,
> > > > > old_pfn));
> > > >
> > > > The check itself is fine, but it just emits a warning and goes on as if
> > > > nothing happened.
> > > >
> > > > We really want to think about a proper way to fix that up without
> > > > overhead
> > > > for the sane case.
> > >
> > > could we change it as below? I think it should be safe to split large
> > > page if current mapping is wrong already.
> > >
> > > if (needs_static_protections(old_prot, addr, psize, old_pfn)) {
> > > WARN_ON_ONCE(1);
> > > goto out_unlock;
> > > }
> >
> > Sure, but what enforces the static protections on the pages which are not
> > in the modified range of the current CPA call? Nothing.
>
> I looked deeper into that. For the PMD split it's rather trivial to do, but
> a PUD split would require a horrible pile of changes as we'd have to remove
> the protections from the new PMD first, go all the way back and rescan the
> new PMDs whether they need to be split up further. But that needs a lot of
> refactoring and I'm not sure if it's worth the trouble right now.
>
> As we haven't cared about that since CPA got introduced, I think we just do
> the consistency check and warn. That's better what we have now and when it
> ever triggers revisit it.
Is below check enough?
if ((pgprot_val(old_prot) & _PAGE_PRESENT) &&
needs_static_protections(old_prot, addr, psize, old_pfn)) {
WARN_ON_ONCE(1);
}
>
> Thanks,
>
> tglx
Re: [PATCH v3 5/5] x86/mm: add WARN_ON_ONCE() for wrong large page mapping
On Tue, 2018-09-04 at 18:52 +0200, Thomas Gleixner wrote:
> On Tue, 4 Sep 2018, Thomas Gleixner wrote:
> > On Tue, 4 Sep 2018, Yang, Bin wrote:
> > > On Tue, 2018-09-04 at 00:27 +0200, Thomas Gleixner wrote:
> > > > On Tue, 21 Aug 2018, Bin Yang wrote:
> > > > > @@ -625,6 +625,7 @@ try_preserve_large_page(pte_t *kpte, unsigned
> > > > > long address,
> > > > >
> > > > > psize = page_level_size(level);
> > > > > pmask = page_level_mask(level);
> > > > > + addr = address & pmask;
> > > > >
> > > > > /*
> > > > >* Calculate the number of pages, which fit into this large
> > > > > @@ -636,6 +637,12 @@ try_preserve_large_page(pte_t *kpte, unsigned
> > > > > long address,
> > > > > cpa->numpages = numpages;
> > > > >
> > > > > /*
> > > > > + * The old pgprot should not have any protection bit. Otherwise,
> > > > > + * the existing mapping is wrong already.
> > > > > + */
> > > > > + WARN_ON_ONCE(needs_static_protections(old_prot, addr, psize,
> > > > > old_pfn));
> > > >
> > > > The check itself is fine, but it just emits a warning and goes on as if
> > > > nothing happened.
> > > >
> > > > We really want to think about a proper way to fix that up without
> > > > overhead
> > > > for the sane case.
> > >
> > > could we change it as below? I think it should be safe to split large
> > > page if current mapping is wrong already.
> > >
> > > if (needs_static_protections(old_prot, addr, psize, old_pfn)) {
> > > WARN_ON_ONCE(1);
> > > goto out_unlock;
> > > }
> >
> > Sure, but what enforces the static protections on the pages which are not
> > in the modified range of the current CPA call? Nothing.
>
> I looked deeper into that. For the PMD split it's rather trivial to do, but
> a PUD split would require a horrible pile of changes as we'd have to remove
> the protections from the new PMD first, go all the way back and rescan the
> new PMDs whether they need to be split up further. But that needs a lot of
> refactoring and I'm not sure if it's worth the trouble right now.
>
> As we haven't cared about that since CPA got introduced, I think we just do
> the consistency check and warn. That's better what we have now and when it
> ever triggers revisit it.
Is below check enough?
if ((pgprot_val(old_prot) & _PAGE_PRESENT) &&
needs_static_protections(old_prot, addr, psize, old_pfn)) {
WARN_ON_ONCE(1);
}
>
> Thanks,
>
> tglx
Re: [PATCH V3 00/26] C-SKY(csky) Linux Kernel Port
Hi, On Wed, Sep 05, 2018 at 08:07:39PM +0800, Guo Ren wrote: > This is the 3th version patchset to add the Linux kernel port for C-SKY(csky). > Thanks to everyone who provided feedback on the previous version. > > This patchset adds architecture support to Linux for C-SKY's 32-bit embedded > CPU cores and the patches are based on linux-4.18.4 > > There are two ABI versions with several CPU cores in this patchset: > ABIv1: ck610 (16-bit instruction, 32-bit data path, VIPT Cache ...) > ABIv2: ck807 ck810 ck860 (16/32-bit variable length instruction, PIPT Cache, >SMP ...) > My key question is about upstream toolchain support. The buildroot clone tells me $ git describe csky/master 2017.11-2111-ge9cc5a5 and $ git log --oneline origin/master..csky/master | wc 11807436 57104 with $ git remote -v cskyhttps://gitlab.com/c-sky/buildroot.git origin git://git.buildroot.net/buildroot So it looks like there are more thasn a thousand patches on top of buildroot. Adding an architecture to buildroot should only take a single patch, or maybe a few, but not more than a thousand. This strongly suggests that a lot of changes are not upstream but only available in the buildroot clone. When are we going to see all those changes in upstream gcc, binutils, and qemu ? I don't really want to dig through more than a thousand patches in a buildroot clone to find out details about the status of upstream toolchain support. Thanks, Guenter
Re: [PATCH V3 00/26] C-SKY(csky) Linux Kernel Port
Hi, On Wed, Sep 05, 2018 at 08:07:39PM +0800, Guo Ren wrote: > This is the 3th version patchset to add the Linux kernel port for C-SKY(csky). > Thanks to everyone who provided feedback on the previous version. > > This patchset adds architecture support to Linux for C-SKY's 32-bit embedded > CPU cores and the patches are based on linux-4.18.4 > > There are two ABI versions with several CPU cores in this patchset: > ABIv1: ck610 (16-bit instruction, 32-bit data path, VIPT Cache ...) > ABIv2: ck807 ck810 ck860 (16/32-bit variable length instruction, PIPT Cache, >SMP ...) > My key question is about upstream toolchain support. The buildroot clone tells me $ git describe csky/master 2017.11-2111-ge9cc5a5 and $ git log --oneline origin/master..csky/master | wc 11807436 57104 with $ git remote -v cskyhttps://gitlab.com/c-sky/buildroot.git origin git://git.buildroot.net/buildroot So it looks like there are more thasn a thousand patches on top of buildroot. Adding an architecture to buildroot should only take a single patch, or maybe a few, but not more than a thousand. This strongly suggests that a lot of changes are not upstream but only available in the buildroot clone. When are we going to see all those changes in upstream gcc, binutils, and qemu ? I don't really want to dig through more than a thousand patches in a buildroot clone to find out details about the status of upstream toolchain support. Thanks, Guenter
Re: [PATCH 4.4 123/124] crypto: padlock-aes - Fix Nano workaround data corruption
On Sat, 2018-08-04 at 11:01 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Herbert Xu
>
> commit 46d8c4b28652d35dc6cfb5adf7f54e102fc04384 upstream.
>
> This was detected by the self-test thanks to Ard's chunking patch.
>
> I finally got around to testing this out on my ancient Via box. It
> turns out that the workaround got the assembly wrong and we end up
> doing count + initial cycles of the loop instead of just count.
>
> This obviously causes corruption, either by overwriting the source
> that is yet to be processed, or writing over the end of the buffer.
>
> On CPUs that don't require the workaround only ECB is affected.
> On Nano CPUs both ECB and CBC are affected.
>
> This patch fixes it by doing the subtraction prior to the assembly.
[...]
> --- a/drivers/crypto/padlock-aes.c
> +++ b/drivers/crypto/padlock-aes.c
> @@ -266,6 +266,8 @@ static inline void padlock_xcrypt_ecb(co
> > return;
> > }
>
> + count -= initial;
> +
> if (initial)
> asm volatile (".byte 0xf3,0x0f,0xa7,0xc8" /* rep
> xcryptecb */
> : "+S"(input), "+D"(output)
> @@ -273,7 +275,7 @@ static inline void padlock_xcrypt_ecb(co
>
> asm volatile (".byte 0xf3,0x0f,0xa7,0xc8" /* rep xcryptecb */
> : "+S"(input), "+D"(output)
> - : "d"(control_word), "b"(key), "c"(count - initial));
> + : "d"(control_word), "b"(key), "c"(count));
> }
>
> static inline u8 *padlock_xcrypt_cbc(const u8 *input, u8 *output, void *key,
[...]
On the face of it, this change shouldn't make any difference. But I
think what's going on is that the compiler stores "initial" in register
ecx and nowhere else, because it has no idea that the first inline
assembly block will update ecx.
This change evidently works around that problem for the specific
compiler and configuration you tested with, but it seems fragile. I
think the assembly constraints should be updated to properly fix this.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
Re: [PATCH 4.4 123/124] crypto: padlock-aes - Fix Nano workaround data corruption
On Sat, 2018-08-04 at 11:01 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Herbert Xu
>
> commit 46d8c4b28652d35dc6cfb5adf7f54e102fc04384 upstream.
>
> This was detected by the self-test thanks to Ard's chunking patch.
>
> I finally got around to testing this out on my ancient Via box. It
> turns out that the workaround got the assembly wrong and we end up
> doing count + initial cycles of the loop instead of just count.
>
> This obviously causes corruption, either by overwriting the source
> that is yet to be processed, or writing over the end of the buffer.
>
> On CPUs that don't require the workaround only ECB is affected.
> On Nano CPUs both ECB and CBC are affected.
>
> This patch fixes it by doing the subtraction prior to the assembly.
[...]
> --- a/drivers/crypto/padlock-aes.c
> +++ b/drivers/crypto/padlock-aes.c
> @@ -266,6 +266,8 @@ static inline void padlock_xcrypt_ecb(co
> > return;
> > }
>
> + count -= initial;
> +
> if (initial)
> asm volatile (".byte 0xf3,0x0f,0xa7,0xc8" /* rep
> xcryptecb */
> : "+S"(input), "+D"(output)
> @@ -273,7 +275,7 @@ static inline void padlock_xcrypt_ecb(co
>
> asm volatile (".byte 0xf3,0x0f,0xa7,0xc8" /* rep xcryptecb */
> : "+S"(input), "+D"(output)
> - : "d"(control_word), "b"(key), "c"(count - initial));
> + : "d"(control_word), "b"(key), "c"(count));
> }
>
> static inline u8 *padlock_xcrypt_cbc(const u8 *input, u8 *output, void *key,
[...]
On the face of it, this change shouldn't make any difference. But I
think what's going on is that the compiler stores "initial" in register
ecx and nowhere else, because it has no idea that the first inline
assembly block will update ecx.
This change evidently works around that problem for the specific
compiler and configuration you tested with, but it seems fragile. I
think the assembly constraints should be updated to properly fix this.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
Re: [PATCH V3 05/26] csky: System Call
On Thu, Sep 06, 2018 at 04:10:49PM +0200, Arnd Bergmann wrote:
> On Wed, Sep 5, 2018 at 2:08 PM Guo Ren wrote:
>
> > +SYSCALL_DEFINE6(mmap2,
> > + unsigned long, addr,
> > + unsigned long, len,
> > + unsigned long, prot,
> > + unsigned long, flags,
> > + unsigned long, fd,
> > + off_t, offset)
> > +{
> > + if (unlikely(offset & (~PAGE_MASK >> 12)))
> > + return -EINVAL;
> > + return sys_mmap_pgoff(addr, len, prot, flags, fd,
> > + offset >> (PAGE_SHIFT - 12));
> > +}
>
> Please call ksys_mmap_pgoff() instead of sys_mmap_pgoff() here.
Ok.
> The prototype in include/asm-generic/syscalls.h uses 'unsigned long'
> for the last argument as well, not off_t.
Ok, unsigned long for last argument.
> > +struct mmap_arg_struct {
> > + unsigned long addr;
> > + unsigned long len;
> > + unsigned long prot;
> > + unsigned long flags;
> > + unsigned long fd;
> > + unsigned long offset;
> > +};
> > +
> > +SYSCALL_DEFINE1(mmap,
> > + struct mmap_arg_struct *, arg)
>
> Something is still wrong here, there should be no way to
> call sys_mmap(), since it's not in the syscall table.
You are right, remove it.
> > + return sys_fadvise64_64(fd, offset, len, advice);
> > +}
>
> And call ksys_fadvise64_64() here.
Ok.
Guo Ren
Re: [PATCH V3 05/26] csky: System Call
On Thu, Sep 06, 2018 at 04:10:49PM +0200, Arnd Bergmann wrote:
> On Wed, Sep 5, 2018 at 2:08 PM Guo Ren wrote:
>
> > +SYSCALL_DEFINE6(mmap2,
> > + unsigned long, addr,
> > + unsigned long, len,
> > + unsigned long, prot,
> > + unsigned long, flags,
> > + unsigned long, fd,
> > + off_t, offset)
> > +{
> > + if (unlikely(offset & (~PAGE_MASK >> 12)))
> > + return -EINVAL;
> > + return sys_mmap_pgoff(addr, len, prot, flags, fd,
> > + offset >> (PAGE_SHIFT - 12));
> > +}
>
> Please call ksys_mmap_pgoff() instead of sys_mmap_pgoff() here.
Ok.
> The prototype in include/asm-generic/syscalls.h uses 'unsigned long'
> for the last argument as well, not off_t.
Ok, unsigned long for last argument.
> > +struct mmap_arg_struct {
> > + unsigned long addr;
> > + unsigned long len;
> > + unsigned long prot;
> > + unsigned long flags;
> > + unsigned long fd;
> > + unsigned long offset;
> > +};
> > +
> > +SYSCALL_DEFINE1(mmap,
> > + struct mmap_arg_struct *, arg)
>
> Something is still wrong here, there should be no way to
> call sys_mmap(), since it's not in the syscall table.
You are right, remove it.
> > + return sys_fadvise64_64(fd, offset, len, advice);
> > +}
>
> And call ksys_fadvise64_64() here.
Ok.
Guo Ren
