Re: [PATCH v4 1/2] dt-bindings: pinctrl: qcom: Add SM8350 pinctrl bindings
Hi Bjorn, On 07-01-21, 11:17, Bjorn Andersson wrote: > On Tue 05 Jan 23:49 CST 2021, Vinod Koul wrote: > > +#PIN CONFIGURATION NODES > > +patternProperties: > > + '-pinmux$': > > I believe that what Rob was asking for was the matter of describing the > mux and config subnodes under this one. But I don't know really how to > express this, because the following are all valid: I looked at the pinmux-node.yaml which describes subnodes with function and groups, this is a generic description and should be in pinmux-node.yaml not in every device description.. said that I am not sure why else should we add here :) > > default_state: default-state { > pins = "gpio1"; > bias-disable; > }; > > default_state: default-state { > rx { > pins = "gpio1"; > function = "gpio"; > bias-disable; > }; > }; > > default_state: default-state { > pinmux { > pins = "gpio1"; > function = "gpio"; > }; > > pinconf { > pins = "gpio1"; > bias-disable; > }; > }; > > I.e. the properties described here applies either to this node directly, > or any subnodes (1 level) down. > > > Also we've been using different "patternProperties" for this node since > the introduction of the binding 7 years ago. But to be "-state$" seems > to best represent what the node actually describes. > > Regards, > Bjorn > > > +type: object > > +description: > > + Pinctrl node's client devices use subnodes for desired pin > > configuration. > > + Client device subnodes use below standard properties. > > +$ref: "/schemas/pinctrl/pincfg-node.yaml" > > + > > +properties: > > + pins: > > +description: > > + List of gpio pins affected by the properties specified in this > > subnode. > > +items: > > + oneOf: > > +- pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|20[0-3])$" > > +- enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, > > sdc2_data ] > > +minItems: 1 > > +maxItems: 36 > > + > > + function: > > +description: > > + Specify the alternative function to be configured for the > > specified > > + pins. Functions are only valid for gpio pins. > > +enum: [ atest_char, atest_usb, audio_ref, cam_mclk, cci_async, > > +cci_i2c, cci_timer, cmu_rng, coex_uart1, coex_uart2, > > cri_trng, > > +cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, > > ddr_pxi1, > > +ddr_pxi2, ddr_pxi3, dp_hot, dp_lcd, gcc_gp1, gcc_gp2, > > gcc_gp3, > > +gpio, ibi_i3c, jitter_bist, lpass_slimbus, mdp_vsync, > > mdp_vsync0, > > +mdp_vsync1, mdp_vsync2, mdp_vsync3, mi2s0_data0, > > mi2s0_data1, > > +mi2s0_sck, mi2s0_ws, mi2s1_data0, mi2s1_data1, mi2s1_sck, > > +mi2s1_ws, mi2s2_data0, mi2s2_data1, mi2s2_sck, mi2s2_ws, > > +mss_grfc0, mss_grfc1, mss_grfc10, mss_grfc11, mss_grfc12, > > +mss_grfc2, mss_grfc3, mss_grfc4, mss_grfc5, mss_grfc6, > > +mss_grfc7, mss_grfc8, mss_grfc9, nav_gpio, pa_indicator, > > +pcie0_clkreqn, pcie1_clkreqn, phase_flag, pll_bist, > > pll_clk, > > +pri_mi2s, prng_rosc, qdss_cti, qdss_gpio, qlink0_enable, > > +qlink0_request, qlink0_wmss, qlink1_enable, qlink1_request, > > +qlink1_wmss, qlink2_enable, qlink2_request, qlink2_wmss, > > qspi0, > > +qspi1, qspi2, qspi3, qspi_clk, qspi_cs, qup0, qup1, qup10, > > +qup11, qup12, qup13, qup14, qup15, qup16, qup17, qup18, > > qup19, > > +qup2, qup3, qup4, qup5, qup6, qup7, qup8, qup9, qup_l4, > > qup_l5, > > +qup_l6, sd_write, sdc40, sdc41, sdc42, sdc43, sdc4_clk, > > +sdc4_cmd, sec_mi2s, tb_trig, tgu_ch0, tgu_ch1, tgu_ch2, > > +tgu_ch3, tsense_pwm1, tsense_pwm2, uim0_clk, uim0_data, > > +uim0_present, uim0_reset, uim1_clk, uim1_data, > > uim1_present, > > +uim1_reset, usb2phy_ac, usb_phy, vfr_0, vfr_1, > > vsense_trigger ] > > + > > + > > + drive-strength: > > +enum: [2, 4, 6, 8, 10, 12, 14, 16] > > +default: 2 > > +description: > > + Selects the drive strength for the specified pins, in mA. > > + > > + bias-pull-down: true > > + > > + bias-pull-up: true > > + > > + bias-disable: true > > + > > + output-high: true > > + > > + output-low: true > > + > > +required: > > + - pins > > + - function > > + > > +additionalProperties: false > > + > > +required: > > + - compatible > > + - reg > > + - interrupts > > + - interrupt-controller > > + - '#interrupt-cells' > > + - gpio-controller > > + - '#gpio-cells' > > + - gpio-ranges > > + > > +additionalProperties: false > > + > > +examples: > > + -
Re: [PATCH v2 1/1] tty: serial: owl: Add support for kernel debugger
On 07. 01. 21, 19:16, Cristian Ciocaltea wrote: Hi Greg, Thank you for the review! On Thu, Jan 07, 2021 at 04:20:55PM +0100, Greg Kroah-Hartman wrote: On Tue, Jan 05, 2021 at 07:02:02PM +0200, Cristian Ciocaltea wrote: Implement 'poll_put_char' and 'poll_get_char' callbacks in struct 'owl_uart_ops' that enables OWL UART to be used for kernel debugging over serial line. Signed-off-by: Cristian Ciocaltea [...] + +static void owl_uart_poll_put_char(struct uart_port *port, unsigned char ch) +{ + while (owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_TFFU) + cpu_relax(); Unbounded loops? What could possibly go wrong? :( Please don't do that in the kernel, put a max bound on this. I didn't realize the issue since I had encountered this pattern in many other serial drivers, as well: altera_uart, arc_uart, atmel_serial, etc. And are you _SURE_ that cpu_relax() is what you want to call here? I'm thinking of replacing the loop with 'readl_poll_timeout_atomic()', if that would be a better approach. It might be better, yes. Either way, if you add a bound to the loop, you definitely need a more precise timing, so ndelay/udelay instead of cpu_relax. thanks, -- js
[PATCH V7 01/13] dt-bindings: soc: Add dvfsrc driver bindings
Document the binding for enabling dvfsrc on MediaTek SoC. Signed-off-by: Henry Chen --- .../devicetree/bindings/soc/mediatek/dvfsrc.yaml | 67 ++ 1 file changed, 67 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/mediatek/dvfsrc.yaml diff --git a/Documentation/devicetree/bindings/soc/mediatek/dvfsrc.yaml b/Documentation/devicetree/bindings/soc/mediatek/dvfsrc.yaml new file mode 100644 index 000..0b746a8 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/mediatek/dvfsrc.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/mediatek/dvfsrc.yaml#"; +$schema: "http://devicetree.org/meta-schemas/core.yaml#"; + +title: MediaTek dynamic voltage and frequency scaling resource collector (DVFSRC) + +description: | + The Dynamic Voltage and Frequency Scaling Resource Collector (DVFSRC) is a + HW module which is used to collect all the requests from both software and + hardware and turn into the decision of minimum operating voltage and minimum + DRAM frequency to fulfill those requests. + +maintainers: + - henryc.chen + +properties: + reg: +description: DVFSRC common register address and length. + + compatible: +enum: + - mediatek,mt6873-dvfsrc + - mediatek,mt8183-dvfsrc + - mediatek,mt8192-dvfsrc + + '#interconnect-cells': +const: 1 + +patternProperties: + dvfsrc-vcore: +type: object +description: + The DVFSRC regulator is modelled as a subdevice of the DVFSRC. + Because DVFSRC can request power directly via register read/write, likes + vcore which is a core power of mt8183. As such, the DVFSRC regulator + requires that DVFSRC nodes be present. +$ref: /schemas/regulator/regulator.yaml# + +required: + - compatible + - reg + - "#interconnect-cells" + +additionalProperties: false + +examples: + - | +#include + +soc { +#address-cells = <2>; +#size-cells = <2>; + +dvfsrc@10012000 { +compatible = "mediatek,mt8183-dvfsrc"; +reg = <0 0x10012000 0 0x1000>; +#interconnect-cells = <1>; +dvfsrc_vcore: dvfsrc-vcore { +regulator-name = "dvfsrc-vcore"; +regulator-min-microvolt = <725000>; +regulator-max-microvolt = <80>; +regulator-always-on; +}; +}; +}; -- 1.9.1
[PATCH V7 09/13] interconnect: mediatek: Add interconnect provider driver
Introduce Mediatek MT6873/MT8183/MT8192 specific provider driver using the interconnect framework. ICC provider ICC Nodes - |CPU | |--- |VPU | - | |- | |DRAM |--|DRAM | | | |--|scheduler|- |GPU | |--- |DISP| | |--|(EMI)| | | |--| | - | - | |- |MMSYS|--|--- |VDEC| -- | /|\| |change DRAM freq |--- |VENC| -- | | DVFSR | | | | | -- |--- |IMG | | | |--- |CAM | Signed-off-by: Henry Chen --- drivers/interconnect/Kconfig| 1 + drivers/interconnect/Makefile | 1 + drivers/interconnect/mediatek/Kconfig | 13 ++ drivers/interconnect/mediatek/Makefile | 3 + drivers/interconnect/mediatek/mtk-emi.c | 331 5 files changed, 349 insertions(+) create mode 100644 drivers/interconnect/mediatek/Kconfig create mode 100644 drivers/interconnect/mediatek/Makefile create mode 100644 drivers/interconnect/mediatek/mtk-emi.c diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig index d637a89..da91f84 100644 --- a/drivers/interconnect/Kconfig +++ b/drivers/interconnect/Kconfig @@ -12,6 +12,7 @@ menuconfig INTERCONNECT if INTERCONNECT source "drivers/interconnect/imx/Kconfig" +source "drivers/interconnect/mediatek/Kconfig" source "drivers/interconnect/qcom/Kconfig" source "drivers/interconnect/samsung/Kconfig" diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile index 97d393f..d697500 100644 --- a/drivers/interconnect/Makefile +++ b/drivers/interconnect/Makefile @@ -5,5 +5,6 @@ icc-core-objs := core.o bulk.o obj-$(CONFIG_INTERCONNECT) += icc-core.o obj-$(CONFIG_INTERCONNECT_IMX) += imx/ +obj-$(CONFIG_INTERCONNECT_MTK) += mediatek/ obj-$(CONFIG_INTERCONNECT_QCOM)+= qcom/ obj-$(CONFIG_INTERCONNECT_SAMSUNG) += samsung/ diff --git a/drivers/interconnect/mediatek/Kconfig b/drivers/interconnect/mediatek/Kconfig new file mode 100644 index 000..ec98d6a --- /dev/null +++ b/drivers/interconnect/mediatek/Kconfig @@ -0,0 +1,13 @@ +config INTERCONNECT_MTK + bool "Mediatek Network-on-Chip interconnect drivers" + depends on ARCH_MEDIATEK || COMPILE_TEST + help + Support for Mediatek's Network-on-Chip interconnect hardware. + +config INTERCONNECT_MTK_EMI + tristate "Mediatek EMI interconnect driver" + depends on INTERCONNECT_MTK + depends on (MTK_DVFSRC && OF) || COMPILE_TEST + help + This is a driver for the Mediatek Network-on-Chip on DVFSRC-based + platforms. diff --git a/drivers/interconnect/mediatek/Makefile b/drivers/interconnect/mediatek/Makefile new file mode 100644 index 000..353842b --- /dev/null +++ b/drivers/interconnect/mediatek/Makefile @@ -0,0 +1,3 @@ +# SPDX-License-Identifier: GPL-2.0 + +obj-$(CONFIG_INTERCONNECT_MTK_EMI) += mtk-emi.o \ No newline at end of file diff --git a/drivers/interconnect/mediatek/mtk-emi.c b/drivers/interconnect/mediatek/mtk-emi.c new file mode 100644 index 000..8d650be --- /dev/null +++ b/drivers/interconnect/mediatek/mtk-emi.c @@ -0,0 +1,331 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2021, The Linux Foundation. All rights reserved. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +enum mtk_icc_name { + SLAVE_DDR_EMI, + MASTER_MCUSYS, + MASTER_GPUSYS, + MASTER_MMSYS, + MASTER_MM_VPU, + MASTER_MM_DISP, + MASTER_MM_VDEC, + MASTER_MM_VENC, + MASTER_MM_CAM, + MASTER_MM_IMG, + MASTER_MM_MDP, + MASTER_VPUSYS, + MASTER_VPU_PORT_0, + MASTER_VPU_PORT_1, + MASTER_MDLASYS, + MASTER_MDLA_PORT_0, + MASTER_UFS, + MASTER_PCIE, + MASTER_USB, + MASTER_WIFI, + MASTER_BT, + MASTER_NETSYS, + MASTER_DBGIF, + + SLAVE_HRT_DDR_EMI, + MASTER_HRT_MMSYS, + MASTER_HRT_MM_DISP, + MASTER_HRT_MM_VDEC, + MASTER_HRT_MM_VENC, + MASTER_HRT_MM_CAM, + MASTER_HRT_MM_IMG, + MASTER_HRT_MM_MDP, + MASTER_HRT_DBGIF, +}; + +#define MT8183_MAX_LINKS 1 + +/** + * struct mtk_icc_node - Mediatek specific interconnect nodes + * @name: the node name used in debugfs + * @ep : the type of this endpoint + * @id: a unique
[PATCH V7 07/13] dt-bindings: interconnect: add MT8183 interconnect dt-bindings
Add interconnect provider dt-bindings for MT8183. Signed-off-by: Henry Chen Reviewed-by: Rob Herring --- include/dt-bindings/interconnect/mtk,mt8183-emi.h | 21 + 1 file changed, 21 insertions(+) create mode 100644 include/dt-bindings/interconnect/mtk,mt8183-emi.h diff --git a/include/dt-bindings/interconnect/mtk,mt8183-emi.h b/include/dt-bindings/interconnect/mtk,mt8183-emi.h new file mode 100644 index 000..dfd143f --- /dev/null +++ b/include/dt-bindings/interconnect/mtk,mt8183-emi.h @@ -0,0 +1,21 @@ +/* SPDX-License-Identifier: GPL-2.0 + * + * Copyright (c) 2021 MediaTek Inc. + */ + +#ifndef __DT_BINDINGS_INTERCONNECT_MTK_MT8183_EMI_H +#define __DT_BINDINGS_INTERCONNECT_MTK_MT8183_EMI_H + +#define MT8183_SLAVE_DDR_EMI 0 +#define MT8183_MASTER_MCUSYS 1 +#define MT8183_MASTER_GPU 2 +#define MT8183_MASTER_MMSYS3 +#define MT8183_MASTER_MM_VPU 4 +#define MT8183_MASTER_MM_DISP 5 +#define MT8183_MASTER_MM_VDEC 6 +#define MT8183_MASTER_MM_VENC 7 +#define MT8183_MASTER_MM_CAM 8 +#define MT8183_MASTER_MM_IMG 9 +#define MT8183_MASTER_MM_MDP 10 + +#endif -- 1.9.1
[PATCH V7 05/13] arm64: dts: mt8183: add dvfsrc related nodes
Enable dvfsrc on mt8183 platform. Signed-off-by: Henry Chen --- arch/arm64/boot/dts/mediatek/mt8183.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi index 5b782a4..062afe8 100644 --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi @@ -497,6 +497,11 @@ #clock-cells = <1>; }; + ddr_emi: dvfsrc@10012000 { + compatible = "mediatek,mt8183-dvfsrc"; + reg = <0 0x10012000 0 0x1000>; + }; + pwrap: pwrap@1000d000 { compatible = "mediatek,mt8183-pwrap"; reg = <0 0x1000d000 0 0x1000>; -- 1.9.1
[PATCH V7 08/13] dt-bindings: interconnect: add MT6873 interconnect dt-bindings
Add interconnect provider dt-bindings for MT6873. Signed-off-by: Henry Chen --- include/dt-bindings/interconnect/mtk,mt6873-emi.h | 41 +++ 1 file changed, 41 insertions(+) create mode 100644 include/dt-bindings/interconnect/mtk,mt6873-emi.h diff --git a/include/dt-bindings/interconnect/mtk,mt6873-emi.h b/include/dt-bindings/interconnect/mtk,mt6873-emi.h new file mode 100644 index 000..0b20011 --- /dev/null +++ b/include/dt-bindings/interconnect/mtk,mt6873-emi.h @@ -0,0 +1,41 @@ +/* SPDX-License-Identifier: GPL-2.0 + * + * Copyright (c) 2021 MediaTek Inc. + */ + +#ifndef __DT_BINDINGS_INTERCONNECT_MTK_MT6873_EMI_H +#define __DT_BINDINGS_INTERCONNECT_MTK_MT6873_EMI_H + +#define MT6873_SLAVE_DDR_EMI 0 +#define MT6873_MASTER_MCUSYS 1 +#define MT6873_MASTER_GPUSYS 2 +#define MT6873_MASTER_MMSYS3 +#define MT6873_MASTER_MM_VPU 4 +#define MT6873_MASTER_MM_DISP 5 +#define MT6873_MASTER_MM_VDEC 6 +#define MT6873_MASTER_MM_VENC 7 +#define MT6873_MASTER_MM_CAM 8 +#define MT6873_MASTER_MM_IMG 9 +#define MT6873_MASTER_MM_MDP 10 +#define MT6873_MASTER_VPUSYS 11 +#define MT6873_MASTER_VPU_012 +#define MT6873_MASTER_VPU_113 +#define MT6873_MASTER_MDLASYS 14 +#define MT6873_MASTER_MDLA_0 15 +#define MT6873_MASTER_UFS 16 +#define MT6873_MASTER_PCIE 17 +#define MT6873_MASTER_USB 18 +#define MT6873_MASTER_DBGIF19 +#define MT6873_SLAVE_HRT_DDR_EMI 20 +#define MT6873_MASTER_HRT_MMSYS21 +#define MT6873_MASTER_HRT_MM_DISP 22 +#define MT6873_MASTER_HRT_MM_VDEC 23 +#define MT6873_MASTER_HRT_MM_VENC 24 +#define MT6873_MASTER_HRT_MM_CAM 25 +#define MT6873_MASTER_HRT_MM_IMG 26 +#define MT6873_MASTER_HRT_MM_MDP 27 +#define MT6873_MASTER_HRT_DBGIF28 +#define MT6873_MASTER_WIFI 29 +#define MT6873_MASTER_BT 30 +#define MT6873_MASTER_NETSYS 31 +#endif -- 1.9.1
[PATCH V7 04/13] soc: mediatek: add support for mt6873
add support for mt6873 Signed-off-by: Henry Chen --- drivers/soc/mediatek/mtk-dvfsrc.c | 114 ++ 1 file changed, 114 insertions(+) diff --git a/drivers/soc/mediatek/mtk-dvfsrc.c b/drivers/soc/mediatek/mtk-dvfsrc.c index c0c6d91..a422680 100644 --- a/drivers/soc/mediatek/mtk-dvfsrc.c +++ b/drivers/soc/mediatek/mtk-dvfsrc.c @@ -102,6 +102,16 @@ enum dvfsrc_regs { [DVFSRC_SW_BW] =0x160, }; +static const int mt6873_regs[] = { + [DVFSRC_SW_REQ] = 0xC, + [DVFSRC_LEVEL] =0xD44, + [DVFSRC_SW_PEAK_BW] = 0x278, + [DVFSRC_SW_BW] =0x26C, + [DVFSRC_SW_HRT_BW] =0x290, + [DVFSRC_TARGET_LEVEL] = 0xD48, + [DVFSRC_VCORE_REQUEST] =0x6C, +}; + static const struct dvfsrc_opp *get_current_opp(struct mtk_dvfsrc *dvfsrc) { int level; @@ -127,6 +137,78 @@ static int dvfsrc_wait_for_vcore_level(struct mtk_dvfsrc *dvfsrc, u32 level) POLL_TIMEOUT); } +static int mt6873_get_target_level(struct mtk_dvfsrc *dvfsrc) +{ + return dvfsrc_read(dvfsrc, DVFSRC_TARGET_LEVEL); +} + +static int mt6873_get_current_level(struct mtk_dvfsrc *dvfsrc) +{ + u32 curr_level; + + /* HW level 0 is begin from 0x1, and max opp is 0x1*/ + curr_level = ffs(dvfsrc_read(dvfsrc, DVFSRC_LEVEL)); + if (curr_level > dvfsrc->curr_opps->num_opp) + curr_level = 0; + else + curr_level = dvfsrc->curr_opps->num_opp - curr_level; + + return curr_level; +} + +static int mt6873_wait_for_opp_level(struct mtk_dvfsrc *dvfsrc, u32 level) +{ + const struct dvfsrc_opp *target, *curr; + + target = &dvfsrc->curr_opps->opps[level]; + return readx_poll_timeout_atomic(get_current_opp, dvfsrc, curr, + curr->dram_opp >= target->dram_opp, + STARTUP_TIME, POLL_TIMEOUT); +} + +static u32 mt6873_get_vcore_level(struct mtk_dvfsrc *dvfsrc) +{ + return (dvfsrc_read(dvfsrc, DVFSRC_SW_REQ) >> 4) & 0x7; +} + +static u32 mt6873_get_vcp_level(struct mtk_dvfsrc *dvfsrc) +{ + return (dvfsrc_read(dvfsrc, DVFSRC_VCORE_REQUEST) >> 12) & 0x7; +} + +static void mt6873_set_dram_bw(struct mtk_dvfsrc *dvfsrc, u64 bw) +{ + bw = div_u64(kbps_to_mbps(bw), 100); + bw = min_t(u64, bw, 0xFF); + dvfsrc_write(dvfsrc, DVFSRC_SW_BW, bw); +} + +static void mt6873_set_dram_peak_bw(struct mtk_dvfsrc *dvfsrc, u64 bw) +{ + bw = div_u64(kbps_to_mbps(bw), 100); + bw = min_t(u64, bw, 0xFF); + dvfsrc_write(dvfsrc, DVFSRC_SW_PEAK_BW, bw); +} + +static void mt6873_set_dram_hrtbw(struct mtk_dvfsrc *dvfsrc, u64 bw) +{ + bw = div_u64((kbps_to_mbps(bw) + 29), 30); + bw = min_t(u64, bw, 0x3FF); + dvfsrc_write(dvfsrc, DVFSRC_SW_HRT_BW, bw); +} + +static void mt6873_set_vcore_level(struct mtk_dvfsrc *dvfsrc, u32 level) +{ + spin_lock(&dvfsrc->req_lock); + dvfsrc_rmw(dvfsrc, DVFSRC_SW_REQ, level, 0x7, 4); + spin_unlock(&dvfsrc->req_lock); +} + +static void mt6873_set_vscp_level(struct mtk_dvfsrc *dvfsrc, u32 level) +{ + dvfsrc_rmw(dvfsrc, DVFSRC_VCORE_REQUEST, level, 0x7, 12); +} + static int mt8183_wait_for_opp_level(struct mtk_dvfsrc *dvfsrc, u32 level) { const struct dvfsrc_opp *target, *curr; @@ -377,6 +459,35 @@ static int mtk_dvfsrc_probe(struct platform_device *pdev) .wait_for_vcore_level = dvfsrc_wait_for_vcore_level, }; +static const struct dvfsrc_opp dvfsrc_opp_mt6873_lp4[] = { + {0, 0}, {1, 0}, {2, 0}, {3, 0}, + {0, 1}, {1, 1}, {2, 1}, {3, 1}, + {0, 2}, {1, 2}, {2, 2}, {3, 2}, + {1, 3}, {2, 3}, {3, 3}, {1, 4}, + {2, 4}, {3, 4}, {2, 5}, {3, 5}, + {3, 6}, +}; + +static const struct dvfsrc_opp_desc dvfsrc_opp_mt6873_desc[] = { + DVFSRC_OPP_DESC(dvfsrc_opp_mt6873_lp4), +}; + +static const struct dvfsrc_soc_data mt6873_data = { + .opps_desc = dvfsrc_opp_mt6873_desc, + .regs = mt6873_regs, + .get_target_level = mt6873_get_target_level, + .get_current_level = mt6873_get_current_level, + .get_vcore_level = mt6873_get_vcore_level, + .get_vcp_level = mt6873_get_vcp_level, + .set_dram_bw = mt6873_set_dram_bw, + .set_dram_peak_bw = mt6873_set_dram_peak_bw, + .set_dram_hrtbw = mt6873_set_dram_hrtbw, + .set_vcore_level = mt6873_set_vcore_level, + .set_vscp_level = mt6873_set_vscp_level, + .wait_for_opp_level = mt6873_wait_for_opp_level, + .wait_for_vcore_level = dvfsrc_wait_for_vcore_level, +}; + static int mtk_dvfsrc_remove(struct platform_device *pdev) { struct mtk_dvfsrc *dvfsrc = platform_get_drvdata(pdev); @@ -392,6 +503,9 @@ static int mtk_dvfsrc_remove(struct platform_device *pdev) .compatible = "mediatek,mt8183-dvfsrc", .data = &mt8183_data, }, { + .compatible = "mediatek,mt6873-dvfsrc", +
[PATCH V7 02/13] soc: mediatek: add header for mediatek SIP interface
Add a header to collect SIPs and add one SIP call to initialize power management hardware for the SIP interface defined to access the SPM handling vcore voltage and ddr rate changes on mt8183 (and most likely later socs). Signed-off-by: Henry Chen Signed-off-by: Arvin Wang --- include/linux/soc/mediatek/mtk_sip_svc.h | 4 1 file changed, 4 insertions(+) diff --git a/include/linux/soc/mediatek/mtk_sip_svc.h b/include/linux/soc/mediatek/mtk_sip_svc.h index 082398e..079bbcb 100644 --- a/include/linux/soc/mediatek/mtk_sip_svc.h +++ b/include/linux/soc/mediatek/mtk_sip_svc.h @@ -22,4 +22,8 @@ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, MTK_SIP_SMC_CONVENTION, \ ARM_SMCCC_OWNER_SIP, fn_id) +/* VCOREFS */ +#define MTK_SIP_VCOREFS_CONTROL \ + MTK_SIP_SMC_CMD(0x506) + #endif -- 1.9.1
[PATCH V7 12/13] arm64: dts: mt8183: add dvfsrc regulator nodes
Add dvfsrc regulator nodes which is for MT8183-based platforms Signed-off-by: Henry Chen --- arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi index e862078..9fefc5e 100644 --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi @@ -502,6 +502,12 @@ compatible = "mediatek,mt8183-dvfsrc"; reg = <0 0x10012000 0 0x1000>; #interconnect-cells = <1>; + dvfsrc_vcore: dvfsrc-vcore { + regulator-name = "dvfsrc-vcore"; + regulator-min-microvolt = <725000>; + regulator-max-microvolt = <80>; + regulator-always-on; + }; }; pwrap: pwrap@1000d000 { -- 1.9.1
[PATCH V7 03/13] soc: mediatek: add driver for dvfsrc support
Add dvfsrc driver for MT6873/MT8183/MT8192 Signed-off-by: Henry Chen --- drivers/soc/mediatek/Kconfig| 12 + drivers/soc/mediatek/Makefile | 1 + drivers/soc/mediatek/mtk-dvfsrc.c | 421 include/linux/soc/mediatek/mtk_dvfsrc.h | 35 +++ 4 files changed, 469 insertions(+) create mode 100644 drivers/soc/mediatek/mtk-dvfsrc.c create mode 100644 include/linux/soc/mediatek/mtk_dvfsrc.h diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig index fdd8bc0..693a0ff 100644 --- a/drivers/soc/mediatek/Kconfig +++ b/drivers/soc/mediatek/Kconfig @@ -26,6 +26,18 @@ config MTK_DEVAPC The violation information is logged for further analysis or countermeasures. +config MTK_DVFSRC + tristate "MediaTek DVFSRC Support" + depends on ARCH_MEDIATEK + depends on MTK_SCPSYS + help + Say yes here to add support for the MediaTek DVFSRC (dynamic voltage + and frequency scaling resource collector) found + on different MediaTek SoCs. The DVFSRC is a proprietary + hardware which is used to collect all the requests from + system and turn into the decision of minimum Vcore voltage + and minimum DRAM frequency to fulfill those requests. + config MTK_INFRACFG bool "MediaTek INFRACFG Support" select REGMAP diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile index b6908db..4ead103 100644 --- a/drivers/soc/mediatek/Makefile +++ b/drivers/soc/mediatek/Makefile @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o obj-$(CONFIG_MTK_DEVAPC) += mtk-devapc.o +obj-$(CONFIG_MTK_DVFSRC) += mtk-dvfsrc.o obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o diff --git a/drivers/soc/mediatek/mtk-dvfsrc.c b/drivers/soc/mediatek/mtk-dvfsrc.c new file mode 100644 index 000..c0c6d91 --- /dev/null +++ b/drivers/soc/mediatek/mtk-dvfsrc.c @@ -0,0 +1,421 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2021 MediaTek Inc. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DVFSRC_IDLE 0x00 +#define DVFSRC_GET_TARGET_LEVEL(x) (((x) >> 0) & 0x) +#define DVFSRC_GET_CURRENT_LEVEL(x) (((x) >> 16) & 0x) +#define kbps_to_mbps(x) ((x) / 1000) + +#define POLL_TIMEOUT1000 +#define STARTUP_TIME1 + +#define MTK_SIP_DVFSRC_INIT0x00 + +#define DVFSRC_OPP_DESC(_opp_table)\ +{ \ + .opps = _opp_table, \ + .num_opp = ARRAY_SIZE(_opp_table), \ +} + +struct dvfsrc_opp { + u32 vcore_opp; + u32 dram_opp; +}; + +struct dvfsrc_opp_desc { + const struct dvfsrc_opp *opps; + u32 num_opp; +}; + +struct mtk_dvfsrc; +struct dvfsrc_soc_data { + const int *regs; + const struct dvfsrc_opp_desc *opps_desc; + int (*get_target_level)(struct mtk_dvfsrc *dvfsrc); + int (*get_current_level)(struct mtk_dvfsrc *dvfsrc); + u32 (*get_vcore_level)(struct mtk_dvfsrc *dvfsrc); + u32 (*get_vcp_level)(struct mtk_dvfsrc *dvfsrc); + void (*set_dram_bw)(struct mtk_dvfsrc *dvfsrc, u64 bw); + void (*set_dram_peak_bw)(struct mtk_dvfsrc *dvfsrc, u64 bw); + void (*set_dram_hrtbw)(struct mtk_dvfsrc *dvfsrc, u64 bw); + void (*set_opp_level)(struct mtk_dvfsrc *dvfsrc, u32 level); + void (*set_vcore_level)(struct mtk_dvfsrc *dvfsrc, u32 level); + void (*set_vscp_level)(struct mtk_dvfsrc *dvfsrc, u32 level); + int (*wait_for_opp_level)(struct mtk_dvfsrc *dvfsrc, u32 level); + int (*wait_for_vcore_level)(struct mtk_dvfsrc *dvfsrc, u32 level); +}; + +struct mtk_dvfsrc { + struct device *dev; + struct platform_device *icc; + struct platform_device *regulator; + const struct dvfsrc_soc_data *dvd; + int dram_type; + const struct dvfsrc_opp_desc *curr_opps; + void __iomem *regs; + spinlock_t req_lock; + struct mutex pstate_lock; + struct notifier_block scpsys_notifier; +}; + +static u32 dvfsrc_read(struct mtk_dvfsrc *dvfs, u32 offset) +{ + return readl(dvfs->regs + dvfs->dvd->regs[offset]); +} + +static void dvfsrc_write(struct mtk_dvfsrc *dvfs, u32 offset, u32 val) +{ + writel(val, dvfs->regs + dvfs->dvd->regs[offset]); +} + +#define dvfsrc_rmw(dvfs, offset, val, mask, shift) \ + dvfsrc_write(dvfs, offset, \ + (dvfsrc_read(dvfs, offset) & ~(mask << shift)) | (val << shift)) + +enum dvfsrc_regs { + DVFSRC_SW_REQ, + DVFSRC_SW_REQ2, + DVFSRC_LEVEL, + DVFSRC_TARGET_LEVEL, + DVFSRC_SW_BW, + DVFSRC_SW_PEAK_BW, + DVFSRC_SW_HRT_BW, + DVFSRC_VCORE_REQUEST, +}; + +static const int mt8183_regs[] = { + [DVFSRC_SW_REQ] = 0x4, + [DVFSRC_SW_REQ2] = 0x8, + [DVFSRC_LE
[PATCH V7 11/13] arm64: dts: mt8192: add dvfsrc related nodes
Add DDR EMI provider dictating dram interconnect bus performance found on MT8183-based platforms Signed-off-by: Henry Chen --- arch/arm64/boot/dts/mediatek/mt8192.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi index dbefc0d..81d7d05 100644 --- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi @@ -6,6 +6,7 @@ /dts-v1/; #include +#include #include #include #include @@ -468,6 +469,7 @@ compatible = "mediatek,mt8192-dvfsrc", "mediatek,mt6873-dvfsrc"; reg = <0 0x10012000 0 0x1000>; + #interconnect-cells = <1>; }; systimer: timer@10017000 { -- 1.9.1
[PATCH V7 13/13] arm64: dts: mt8192: add dvfsrc regulator nodes
Add dvfsrc regulator nodes which is for MT8192-based platforms Signed-off-by: Henry Chen --- arch/arm64/boot/dts/mediatek/mt8192.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi index 81d7d05..1cf91a4 100644 --- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi @@ -470,6 +470,12 @@ "mediatek,mt6873-dvfsrc"; reg = <0 0x10012000 0 0x1000>; #interconnect-cells = <1>; + dvfsrc_vcore: dvfsrc-vcore { + regulator-name = "dvfsrc-vcore"; + regulator-min-microvolt = <575000>; + regulator-max-microvolt = <725000>; + regulator-always-on; + }; }; systimer: timer@10017000 { -- 1.9.1
[PATCH V7 10/13] arm64: dts: mt8183: add dvfsrc related nodes
Add DDR EMI provider dictating dram interconnect bus performance found on MT8192-based platforms Signed-off-by: Henry Chen --- arch/arm64/boot/dts/mediatek/mt8183.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi index 062afe8..e862078 100644 --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi @@ -7,6 +7,7 @@ #include #include +#include #include #include #include @@ -500,6 +501,7 @@ ddr_emi: dvfsrc@10012000 { compatible = "mediatek,mt8183-dvfsrc"; reg = <0 0x10012000 0 0x1000>; + #interconnect-cells = <1>; }; pwrap: pwrap@1000d000 { -- 1.9.1
[PATCH V7 00/13] Add driver for dvfsrc, support for active state of scpsys
This series is based on v5.11-rc1. The patchsets add support for MediaTek hardware module named DVFSRC (dynamic voltage and frequency scaling resource collector). The DVFSRC is a HW module which is used to collect all the requests from both software and hardware and turn into the decision of minimum operating voltage and minimum DRAM frequency to fulfill those requests. So, This series is to implement the dvfsrc driver to collect all the requests of operating voltage or DRAM bandwidth from other device drivers likes GPU/Camera through 3 frameworks basically: 1. interconnect framework: to aggregate the bandwidth requirements from different clients [1] https://patchwork.kernel.org/cover/10766329/ There has a hw module "DRAM scheduler", which used to control the throughput. The DVFSRC will collect forecast data of dram bandwidth from SW consumers(camera/gpu...), and according the forecast to change the DRAM frequency 2. Regualtor framework: to handle the operating voltage requirement from user or cosumer which not belong any power domain Changes in V7: * Fixed the dt_binding_check error of dvfsrc.yaml. (Rob) * Fixed the checkpatch complains of "Signed-off-by: email name mismatch". (Georgi) * Fixed coding style of interconnect driver. (Georgi) * Upate comment of the years to 2021. (Georgi) Changes in V6: * Remove the performace state support, because the request from consumer can be replaced by using interconnect and regulator framework. * Update the DT patches and convert them to DT schema. (Georgi) * Modify the comment format and coding style. (Mark) Changes in V5: * Support more platform mt6873/mt8192 * Drop the compatible and interconnect provider node and make the parent node an interconnect provider. (Rob/Georgi) * Make modification of interconnect driver from coding suggestion. (Georgi) * Move interconnect diagram into the commit text of patch. (Georgi) * Register the interconnect provider as a platform sub-device. (Georgi) Changes in V4: * Add acked TAG on dt-bindings patches. (Rob) * Declaration of emi_icc_aggregate since the prototype of aggregate function has changed meanwhile. (Georgi) * Used emi_icc_remove instead of icc_provider_del on probe. (Georgi) * Add dvfsrc regulator driver into series. * Bug fixed of mt8183_get_current_level. * Add mutex protection for pstate operation on dvfsrc_set_performance. Changes in V3: * Remove RFC from the subject prefix of the series * Combine dt-binding patch and move interconnect dt-binding document into dvfsrc. (Rob) * Remove unused header, add unit descirption to the bandwidth, rename compatible name on interconnect driver. (Georgi) * Fixed some coding style: check flow, naming, used readx_poll_timeout on dvfsrc driver. (Ryan) * Rename interconnect driver mt8183.c to mtk-emi.c * Rename interconnect header mtk,mt8183.h to mtk,emi.h * mtk-scpsys.c: Add opp table check first to avoid OF runtime parse failed Changes in RFC V2: * Remove the DT property dram_type. (Rob) * Used generic dts property 'opp-level' to get the performace state. (Stephen) * Remove unecessary dependency config on Kconfig. (Stephen) * Remove unused header file, fixed some coding style issue, typo, error handling on dvfsrc driver. (Nicolas/Stephen) * Remove irq handler on dvfsrc driver. (Stephen) * Remove init table on dvfsrc driver, combine hw init on trustzone. * Add interconnect support of mt8183 to aggregate the emi bandwidth. (Georgi) V6: https://patchwork.kernel.org/project/linux-mediatek/list/?series=406077 V5: https://patchwork.kernel.org/project/linux-mediatek/list/?series=348065 V4: https://lore.kernel.org/patchwork/cover/1209284/ V3: https://patchwork.kernel.org/cover/8867/ RFC V2: https://lore.kernel.org/patchwork/patch/1068113/ RFC V1: https://lore.kernel.org/patchwork/cover/1028535/
[PATCH V7 06/13] arm64: dts: mt8192: add dvfsrc related nodes
Enable dvfsrc on mt8192 platform. Signed-off-by: Henry Chen --- arch/arm64/boot/dts/mediatek/mt8192.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi index 8252143..dbefc0d 100644 --- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi @@ -464,6 +464,12 @@ #clock-cells = <1>; }; + ddr_emi: dvfsrc@10012000 { + compatible = "mediatek,mt8192-dvfsrc", +"mediatek,mt6873-dvfsrc"; + reg = <0 0x10012000 0 0x1000>; + }; + systimer: timer@10017000 { compatible = "mediatek,mt8192-timer", "mediatek,mt6765-timer"; -- 1.9.1
[PATCH] perf test: Fix shadow stat test for non-bash shells
It was using some bash-specific features and failed to parse when running with a different shell like below: root@kbl-ppc:~/kbl-ws/perf-dev/lck-9077/acme.tmp/tools/perf# ./perf test 83 -vv 83: perf stat metrics (shadow stat) test: --- start --- test child forked, pid 3922 ./tests/shell/stat+shadow_stat.sh: 19: ./tests/shell/stat+shadow_stat.sh: [[: not found ./tests/shell/stat+shadow_stat.sh: 24: ./tests/shell/stat+shadow_stat.sh: [[: not found ./tests/shell/stat+shadow_stat.sh: 30: ./tests/shell/stat+shadow_stat.sh: [[: not found (standard_in) 2: syntax error ./tests/shell/stat+shadow_stat.sh: 36: ./tests/shell/stat+shadow_stat.sh: [[: not found ./tests/shell/stat+shadow_stat.sh: 19: ./tests/shell/stat+shadow_stat.sh: [[: not found ./tests/shell/stat+shadow_stat.sh: 24: ./tests/shell/stat+shadow_stat.sh: [[: not found ./tests/shell/stat+shadow_stat.sh: 30: ./tests/shell/stat+shadow_stat.sh: [[: not found (standard_in) 2: syntax error ./tests/shell/stat+shadow_stat.sh: 36: ./tests/shell/stat+shadow_stat.sh: [[: not found ./tests/shell/stat+shadow_stat.sh: 45: ./tests/shell/stat+shadow_stat.sh: declare: not found test child finished with -1 end perf stat metrics (shadow stat) test: FAILED! Reported-by: Jin Yao Signed-off-by: Namhyung Kim --- tools/perf/tests/shell/stat+shadow_stat.sh | 24 -- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/tools/perf/tests/shell/stat+shadow_stat.sh b/tools/perf/tests/shell/stat+shadow_stat.sh index 249dfe48cf6a..e2c7ac4ed91d 100755 --- a/tools/perf/tests/shell/stat+shadow_stat.sh +++ b/tools/perf/tests/shell/stat+shadow_stat.sh @@ -16,24 +16,24 @@ test_global_aggr() while read num evt hash ipc rest do # skip not counted events - if [[ $num == "&1 | \ grep ^CPU | \ while read cpu num evt hash ipc rest do # skip not counted events - if [[ $num == "> $results continue fi # skip if no cycles - local cyc=${results[$cpu]} - if [[ -z $cyc ]]; then + local cyc=$(grep $cpu $results | cut -d' ' -f2) + if [ -z "$cyc" ]; then continue fi # use printf for rounding and a leading zero local res=`printf "%.2f" $(echo "scale=6; $num / $cyc" | bc -q)` - if [[ $ipc != $res ]]; then + if [ "$ipc" != "$res" ]; then echo "IPC is different for $cpu: $res != $ipc ($num / $cyc)" + rm -f $results exit 1 fi done + rm -f $results } test_global_aggr -- 2.30.0.284.gd98b1dd5eaa7-goog
LTS: proc: fix lookup in /proc/net subdirectories after setns(2)
Hi Greg, Can you cherry-pick these to 4.19.y & 5.4.y: commit e06689bf57017ac022ccf0f2a5071f760821ce0f Author: Alexey Dobriyan Date: Wed Dec 4 16:49:59 2019 -0800 proc: change ->nlink under proc_subdir_lock commit c6c75deda81344c3a95d1d1f606d5cee109e5d54 Author: Alexey Dobriyan Date: Tue Dec 15 20:42:39 2020 -0800 proc: fix lookup in /proc/net subdirectories after setns(2) -Tommi
Re: [RESEND PATCH 2/2] misc: add support for retimers interfaces on Intel MAX 10 BMC
On Fri, Jan 08, 2021 at 10:05:26AM +0800, Xu Yilun wrote: > On Thu, Jan 07, 2021 at 10:26:12AM +0100, Greg KH wrote: > > On Thu, Jan 07, 2021 at 02:07:08PM +0800, Xu Yilun wrote: > > > This driver supports the ethernet retimers (C827) for the Intel PAC > > > (Programmable Acceleration Card) N3000, which is a FPGA based Smart NIC. > > > > > > C827 is an Intel(R) Ethernet serdes transceiver chip that supports > > > up to 100G transfer. On Intel PAC N3000 there are 2 C827 chips > > > managed by the Intel MAX 10 BMC firmware. They are configured in 4 ports > > > 10G/25G retimer mode. Host could query their link states and firmware > > > version information via retimer interfaces (Shared registers) on Intel > > > MAX 10 BMC. The driver creates sysfs interfaces for users to query these > > > information. > > > > Networking people, please look at this sysfs file: > > > > > +What: > > > /sys/bus/platform/devices/n3000bmc-retimer.*.auto/link_statusX > > > +Date:Jan 2021 > > > +KernelVersion: 5.12 > > > +Contact: Xu Yilun > > > +Description: Read only. Returns the status of each line side link. > > > "1" for > > > + link up, "0" for link down. > > > + Format: "%u". > > > > as I need your approval to add it because it is not the "normal" way for > > link status to be exported to userspace. > > > > One code issue: > > > > > +#define to_link_attr(dev_attr) \ > > > + container_of(dev_attr, struct link_attr, attr) > > > + > > > +static ssize_t > > > +link_status_show(struct device *dev, struct device_attribute *attr, char > > > *buf) > > > +{ > > > + struct m10bmc_retimer *retimer = dev_get_drvdata(dev); > > > + struct link_attr *lattr = to_link_attr(attr); > > > + unsigned int val; > > > + int ret; > > > + > > > + ret = m10bmc_sys_read(retimer->m10bmc, M10BMC_PKVL_LSTATUS, &val); > > > + if (ret) > > > + return ret; > > > + > > > + return sysfs_emit(buf, "%u\n", > > > + !!(val & BIT((retimer->id << 2) + lattr->index))); > > > +} > > > + > > > +#define link_status_attr(_index) \ > > > + static struct link_attr link_attr_status##_index = \ > > > + { .attr = __ATTR(link_status##_index, 0444, \ > > > + link_status_show, NULL), \ > > > + .index = (_index) } > > > > Why is this a "raw" attribute and not a device attribute? > > It is actually a device_attribute. The device_attribute is embedded in > link_attr, like: > > struct link_attr { > struct device_attribute attr; > u32 index; > }; > > An index for the link is appended along with the device_attribute, so we > could identify which link is being queried on link_status_show(). There > are 4 links and this is to avoid duplicated code like > link_status_1_show(), link_status_2_show() ... Duplicated code is better to read than complex code :) > > Please just use a normal DEVICE_ATTR_RO() macro to make it simpler and > > DEVICE_ATTR_RO() is to define a standalone device_attribute variable, but > here we are initializing a field in struct link_attr. Then use the correct initialization macro that is given to you for that, do not roll your own. greg k-h
Re: [PATCH v2] driver core: Fix device link device name collision
On Fri, Jan 08, 2021 at 02:10:51AM +0100, Michael Walle wrote: > Am 8. Januar 2021 02:00:32 MEZ schrieb Saravana Kannan : > >On Thu, Jan 7, 2021 at 4:43 PM Saravana Kannan > >wrote: > >Nevermind, I see it now. Also, in the future, if you can dump the logs > >in some kind of pastebin site, that'd be nice. Avoid the emails > >becoming unwieldy and also avoids the log lines from wrapping. > > I thought about a pastebin. But then decided against it because they might be > deleted in the future. So if anyone looking at the mail archives he might > only get dead links. So.. > > dunno how this is handled on the LKML, tbh. Full logs are good, you did it right, Saravana can deal with long emails :)
drivers/gpu/drm/i915/i915_sw_fence.c:111:20: error: unused function 'debug_fence_free'
Hi Nick, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f5e6c330254ae691f6d7befe61c786eb5056007e commit: 9f4069b055d1508c833115df7493b6e0001e5c9b drm/i915: re-disable -Wframe-address date: 9 months ago config: x86_64-randconfig-r014-20210108 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 5c951623bc8965fa1e89660f2f5f4a2944e4981a) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f4069b055d1508c833115df7493b6e0001e5c9b git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 9f4069b055d1508c833115df7493b6e0001e5c9b # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> drivers/gpu/drm/i915/i915_sw_fence.c:111:20: error: unused function >> 'debug_fence_free' [-Werror,-Wunused-function] static inline void debug_fence_free(struct i915_sw_fence *fence) ^ 1 error generated. vim +/debug_fence_free +111 drivers/gpu/drm/i915/i915_sw_fence.c fc1584059d6c438 Chris Wilson 2016-11-25 110 fc1584059d6c438 Chris Wilson 2016-11-25 @111 static inline void debug_fence_free(struct i915_sw_fence *fence) fc1584059d6c438 Chris Wilson 2016-11-25 112 { fc1584059d6c438 Chris Wilson 2016-11-25 113 } fc1584059d6c438 Chris Wilson 2016-11-25 114 :: The code at line 111 was first introduced by commit :: fc1584059d6c438b1febafa1c207ae1d3c6643e8 drm/i915: Integrate i915_sw_fence with debugobjects :: TO: Chris Wilson :: CC: Chris Wilson --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
On Fri, Dec 25, 2020 at 8:44 AM Metztli Information Technology wrote: > > On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin > wrote: > > > > On 12/23/2020 05:01 PM, Metztli Information Technology wrote: > > > Niltze [ÃâôÃâ¬Ã°Ã²à ÃâòÃÆùÃâõ : Hello], Ed- > > > > > > I built Linux kernel 5.10.1-1 within the 'Debian way' -- as usual -- to > > > generate a kernel component for my Debian-Installer (d-i). > > > The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-unstable. > > > > > > Once I built the proper reiser4progs-2.0.4.tar.gz and generated one set > > > of components for d-i I built the d-i image. > > > > > > Fact is, the installer throws an error in *both* bare metal and > > > VirtualBox 6.1.16: > > > ... > > > Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-base' selected > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --components=main > > > --debian-installer --resolve-deps > > > --keyring=/usr/share/keyrings/archive.gpg buster /target > > > http://deb.debian.org/debian/ > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596: > > > /target/test-exec: Invalid argument > > > Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not supported for file > > > /test-exec (pid: 10077 comm: debootstrap) > > > Dec 22 20:19:56 debootstrap: E: NOEXEC > > > Dec 22 20:19:56 debootstrap: EF: Cannot install into target '/target' > > > mounted with noexec or nodev > > > Dec 22 20:20:12 base-installer: error: exiting on error > > > base-installer/debootstrap-failed > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring 'bootstrap-base' > > > failed with error code 1 > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item 'bootstrap-base' > > > failed. > > > Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the package > > > description for brltty-udeb > > > > > > > [...] > > > > > > > > Apparently, d-i [Debian-installer] complains about being unable to set > > > the test file executable and causes the error when 1 is returned. > > > Notwithstanding, I manually verified that I am able to touch a file and > > > set it +x executable. > > > > > > Furthermore, tricking the function return value to 0 I am able to make > > > d-i continue with the latest SFRN5 installation (see [*trick*] below); > > > yet, subsequently halts again with > > > an apparently related error --can not proceed any further. > > > > > > Digging deeper with dmesg, we can see that apparently it is the kernel > > > which cannot 'read' properly. Please find a partial dmesg log with > > > relevant output > > > from an attempt on my physical development machine. > > > ... > > > [  508.614488] Loading Reiser4 (Software Framework Release: 5.1.3). See > > > reiser4.wiki.kernel.org for a description of Reiser4. > > > [  508.661951] SGI XFS with ACLs, security attributes, realtime, quota, > > > no debug enabled > > > [  509.326270] device-mapper: uevent: version 1.0.3 > > > [  509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) > > > initialised: dm-de...@redhat.com > > > [  509.902828]  sda: sda1 sda2 sda3 sda4 sda5 sda6 > > > [  509.915300]  sdb: sdb1 sdb2 sdb3 > > > [  511.973360]  sdb: sdb1 sdb2 sdb3 > > > [  627.525371] Adding 9765884k swap on /dev/sda3.  Priority:-2 > > > extents:1 across:9765884k FS > > > [  636.240812] reiser4[mount(9430)]: reiser4_register_subvol > > > (fs/reiser4/init_volume.c:222)[edward-1932]: > > > [  636.240812] NOTICE: brick /dev/sda6 has been registered > > > [  636.243003] reiser4 (sda6): found disk format 5.1.3. > > > [  643.759971] reiser4 (/dev/sda6): using Hybrid Transaction Model. > > > [  643.759980] reiser4: brick /dev/sda6 activated > > > [  643.788537] EXT4-fs (sda1): mounting ext2 file system using the ext4 > > > subsystem > > > [  643.813474] EXT4-fs (sda1): mounted filesystem without journal. Opts: > > > (null) > > > [  643.813488] ext2 filesystem being mounted at /target/boot supports > > > timestamps until 2038 (0x7fff) > > > [  648.168730] kernel read not supported for file /test-exec (pid: 9876 > > > comm: debootstrap) [*trick*] > > > [  898.761385] reiser4: brick /dev/sda6 deactivated > > > [  991.001332] reiser4 (sda6): found disk format 5.1.3. > > > [  999.093471] reiser4 (/dev/sda6): using Hybrid Transaction Model. > > > [  999.093480] reiser4: brick /dev/sda6 activated > > > [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using the ext4 > > > subsystem > > > [ 1009.362722] EXT4-fs (sda1): mounted filesystem without journal. Opts: > > > (null) > > > [ 1009.362737] ext2 filesystem being mounted at /target/boot supports > > > timestamps until 2038 (0x7fff) > > > [ 6373.748413] kernel read not supported for file /test-exec (pid: 10094 > > > comm: debootstrap) > > > [ 6413.169920] kernel read not supported for file /usr/bin/true (pid: > > > 15960 comm: chroot) > > > > > > Hello. > > > > This is because of VFS changes in Linux-5.10.X. > > Specifical
[PATCH for can-next] MAINTAINERS: adjust entry to tcan4x5x file split
Commit 7813887ea972 ("can: tcan4x5x: rename tcan4x5x.c -> tcan4x5x-core.c") and commit 67def4ef8bb9 ("can: tcan4x5x: move regmap code into seperate file") split the file tcan4x5x.c into two files, but missed to adjust the TI TCAN4X5X DEVICE DRIVER section in MAINTAINERS. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains: warning: no file matchesF:drivers/net/can/m_can/tcan4x5x.c Adjust the file entry in MAINTAINERS to the tcan4x5x file splitting. Signed-off-by: Lukas Bulwahn --- applies cleanly on next-20210107, not for current master Marc, please pick this for your -next tree on top of the tcan4x5x cleanup. MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8170b40d6236..0d75f07fc951 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17887,7 +17887,7 @@ M: Dan Murphy L: linux-...@vger.kernel.org S: Maintained F: Documentation/devicetree/bindings/net/can/tcan4x5x.txt -F: drivers/net/can/m_can/tcan4x5x.c +F: drivers/net/can/m_can/tcan4x5x* TI TRF7970A NFC DRIVER M: Mark Greer -- 2.17.1
Re: [PATCH 4.14 00/29] 4.14.214-rc1 review
On Thu, 7 Jan 2021 at 20:00, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.214 release. > There are 29 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat, 09 Jan 2021 14:30:35 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.214-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 4.14.214-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: 78e4e5e07ab0059bd4c96c117fb2a8e24bda7127 git describe: v4.14.213-30-g78e4e5e07ab0 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14.213-30-g78e4e5e07ab0 No regressions (compared to build v4.14.213) No fixes (compared to build v4.14.213) Ran 40940 total tests in the following environments and test suites. Environments -- - arm - arm64 - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - juno-r2-compat - juno-r2-kasan - mips - qemu-arm64-kasan - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - sparc - x15 - arm - x86_64 - x86-kasan Test Suites --- * build * linux-log-parser * igt-gpu-tools * install-android-platform-tools-r2600 * kvm-unit-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-mm-tests * ltp-sched-tests * ltp-syscalls-tests * ltp-tracing-tests * perf * fwts * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-fs-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * network-basic-tests * v4l2-compliance * ltp-containers-tests * ltp-open-posix-tests * rcutorture -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH] neighbour: Disregard DEAD dst in neigh_update
On Thu, Jan 07, 2021 at 09:36:37PM -0500, Your Real Name wrote: > On Tue, Jan 05, 2021 at 04:05:21PM -0800, David Miller wrote: > > > > > > From: Tong Zhu > > Date: Wed, 30 Dec 2020 17:54:23 -0500 > > > > > In 4.x kernel a dst in DST_OBSOLETE_DEAD state is associated > > > with loopback net_device and leads to loopback neighbour. It > > > leads to an ethernet header with all zero addresses. > > > > > > A very troubling case is working with mac80211 and ath9k. > > > A packet with all zero source MAC address to mac80211 will > > > eventually fail ieee80211_find_sta_by_ifaddr in ath9k (xmit.c). > > > As result, ath9k flushes tx queue (ath_tx_complete_aggr) without > > > updating baw (block ack window), damages baw logic and disables > > > transmission. > > > > > > Signed-off-by: Tong Zhu > > > > Please repost with an appropriate Fixes: tag. > > > > Thanks. > > I had a second thought on this. This fix should go mainline too. This is a > case we are sending out queued packets when arp reply from the neighbour > comes in. With 5.x kernel, a dst in DST_OBSOLETE_DEAD state leads to dropping > of this packet. It is not as bad as with 4.x kernel that may end up with an > all-zero mac address packet out to ethernet or choking up ath9k when using > block ack. Dropping the packet is still wrong. I’ll repost as a fix to > mainline and target backport to 4.x LTS releases. That's how kernel development works, please read https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how stable kernels are allowed to accept patches. good luck! greg k-h
[PATCH v2 2/2] Hyper-V: pci: x64: Moving the MSI entry definition to arch specific location
The Hyper-V MSI entry is architecture specific. Currently, it is defined in an arch neutral location. This patch moves it to an arch specific location. Signed-off-by: Sunil Muthuswamy --- arch/x86/include/asm/hyperv-tlfs.h | 7 +++ include/asm-generic/hyperv-tlfs.h | 8 2 files changed, 7 insertions(+), 8 deletions(-) diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv-tlfs.h index 6bf42aed387e..a15c17c7f019 100644 --- a/arch/x86/include/asm/hyperv-tlfs.h +++ b/arch/x86/include/asm/hyperv-tlfs.h @@ -523,6 +523,13 @@ struct hv_partition_assist_pg { u32 tlb_lock_count; }; +union hv_msi_entry { + u64 as_uint64; + struct { + u32 address; + u32 data; + } __packed; +}; #include diff --git a/include/asm-generic/hyperv-tlfs.h b/include/asm-generic/hyperv-tlfs.h index e73a11850055..6265f4494970 100644 --- a/include/asm-generic/hyperv-tlfs.h +++ b/include/asm-generic/hyperv-tlfs.h @@ -408,14 +408,6 @@ struct hv_tlb_flush_ex { } __packed; /* HvRetargetDeviceInterrupt hypercall */ -union hv_msi_entry { - u64 as_uint64; - struct { - u32 address; - u32 data; - } __packed; -}; - struct hv_interrupt_entry { u32 source; /* 1 for MSI(-X) */ u32 reserved1; -- 2.17.1
[PATCH v5 2/2] scsi: ufs-qcom: Fix ufs RST_n specs violation
As per specs, e.g, JESD220E chapter 7.2, while powering off/on the ufs device, RST_n signal should be between VSS(Ground) and VCCQ/VCCQ2. Signed-off-by: Ziqi Chen --- drivers/scsi/ufs/ufs-qcom.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c index 2206b1e..d8b896c 100644 --- a/drivers/scsi/ufs/ufs-qcom.c +++ b/drivers/scsi/ufs/ufs-qcom.c @@ -582,6 +582,10 @@ static int ufs_qcom_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op) ufs_qcom_disable_lane_clks(host); phy_power_off(phy); + /* reset the connected UFS device during power down */ + if (host->device_reset) + gpiod_set_value_cansleep(host->device_reset, 1); + } else if (!ufs_qcom_is_link_active(hba)) { ufs_qcom_disable_lane_clks(host); } -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v2 1/2] Hyper-V: pci: x64: Generalize irq/msi set-up and handling
Currently, operations related to irq/msi in Hyper-V vPCI are x86-specific code. In order to support virtual PCI on Hyper-V for other architectures, introduce generic interfaces to replace the x86-specific ones. There are no functional changes in this patch. Co-developed-by: Boqun Feng (Microsoft) Signed-off-by: Boqun Feng (Microsoft) Signed-off-by: Sunil Muthuswamy --- In V2: - Addressed feedback on SoB tab. - Added a second patch to move the MSI entry definition. --- arch/x86/include/asm/mshyperv.h | 24 + drivers/pci/controller/pci-hyperv.c | 33 + 2 files changed, 44 insertions(+), 13 deletions(-) diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h index ffc289992d1b..05b32ef57e34 100644 --- a/arch/x86/include/asm/mshyperv.h +++ b/arch/x86/include/asm/mshyperv.h @@ -245,6 +245,30 @@ bool hv_vcpu_is_preempted(int vcpu); static inline void hv_apic_init(void) {} #endif +#define hv_msi_handler handle_edge_irq +#define hv_msi_handler_name"edge" +#define hv_msi_prepare pci_msi_prepare + +/* Returns the Hyper-V PCI parent MSI vector domain. */ +static inline struct irq_domain *hv_msi_parent_vector_domain(void) +{ + return x86_vector_domain; +} + +/* Returns the interrupt vector mapped to the given IRQ. */ +static inline unsigned int hv_msi_get_int_vector(struct irq_data *data) +{ + struct irq_cfg *cfg = irqd_cfg(data); + + return cfg->vector; +} + +/* Get the IRQ delivery mode. */ +static inline u8 hv_msi_irq_delivery_mode(void) +{ + return APIC_DELIVERY_MODE_FIXED; +} + static inline void hv_set_msi_entry_from_desc(union hv_msi_entry *msi_entry, struct msi_desc *msi_desc) { diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c index 6db8d96a78eb..9ca740d275d7 100644 --- a/drivers/pci/controller/pci-hyperv.c +++ b/drivers/pci/controller/pci-hyperv.c @@ -43,12 +43,11 @@ #include #include #include -#include -#include #include #include #include #include +#include #include /* @@ -1194,7 +1193,6 @@ static void hv_irq_mask(struct irq_data *data) static void hv_irq_unmask(struct irq_data *data) { struct msi_desc *msi_desc = irq_data_get_msi_desc(data); - struct irq_cfg *cfg = irqd_cfg(data); struct hv_retarget_device_interrupt *params; struct hv_pcibus_device *hbus; struct cpumask *dest; @@ -1223,7 +1221,7 @@ static void hv_irq_unmask(struct irq_data *data) (hbus->hdev->dev_instance.b[7] << 8) | (hbus->hdev->dev_instance.b[6] & 0xf8) | PCI_FUNC(pdev->devfn); - params->int_target.vector = cfg->vector; + params->int_target.vector = hv_msi_get_int_vector(data); /* * Honoring apic->delivery_mode set to APIC_DELIVERY_MODE_FIXED by @@ -1324,7 +1322,7 @@ static u32 hv_compose_msi_req_v1( int_pkt->wslot.slot = slot; int_pkt->int_desc.vector = vector; int_pkt->int_desc.vector_count = 1; - int_pkt->int_desc.delivery_mode = APIC_DELIVERY_MODE_FIXED; + int_pkt->int_desc.delivery_mode = hv_msi_irq_delivery_mode(); /* * Create MSI w/ dummy vCPU set, overwritten by subsequent retarget in @@ -1345,7 +1343,7 @@ static u32 hv_compose_msi_req_v2( int_pkt->wslot.slot = slot; int_pkt->int_desc.vector = vector; int_pkt->int_desc.vector_count = 1; - int_pkt->int_desc.delivery_mode = APIC_DELIVERY_MODE_FIXED; + int_pkt->int_desc.delivery_mode = hv_msi_irq_delivery_mode(); /* * Create MSI w/ dummy vCPU set targeting just one vCPU, overwritten @@ -1372,7 +1370,6 @@ static u32 hv_compose_msi_req_v2( */ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg) { - struct irq_cfg *cfg = irqd_cfg(data); struct hv_pcibus_device *hbus; struct vmbus_channel *channel; struct hv_pci_dev *hpdev; @@ -1422,7 +1419,7 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg) size = hv_compose_msi_req_v1(&ctxt.int_pkts.v1, dest, hpdev->desc.win_slot.slot, - cfg->vector); + hv_msi_get_int_vector(data)); break; case PCI_PROTOCOL_VERSION_1_2: @@ -1430,7 +1427,7 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg) size = hv_compose_msi_req_v2(&ctxt.int_pkts.v2, dest, hpdev->desc.win_slot.slot, - cfg->vector); + hv_msi_get_int_vector(data)); break; default: @@ -1541,12 +1538,13 @@ static
[PATCH v5 1/2] scsi: ufs: Fix ufs clk specs violation
As per specs, e.g, JESD220E chapter 7.2, while powering off/on the ufs device, REF_CLK signal should be between VSS(Ground) and VCCQ/VCCQ2. Signed-off-by: Ziqi Chen --- drivers/scsi/ufs/ufshcd.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index e221add..3f807f7 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -8686,8 +8686,6 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op) if (ret) goto set_dev_active; - ufshcd_vreg_set_lpm(hba); - disable_clks: /* * Call vendor specific suspend callback. As these callbacks may access @@ -8711,6 +8709,8 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op) hba->clk_gating.state); } + ufshcd_vreg_set_lpm(hba); + /* Put the host controller in low power mode if possible */ ufshcd_hba_vreg_set_lpm(hba); goto out; @@ -8778,18 +8778,18 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op) old_link_state = hba->uic_link_state; ufshcd_hba_vreg_set_hpm(hba); + ret = ufshcd_vreg_set_hpm(hba); + if (ret) + goto out; + /* Make sure clocks are enabled before accessing controller */ ret = ufshcd_setup_clocks(hba, true); if (ret) - goto out; + goto disable_vreg; /* enable the host irq as host controller would be active soon */ ufshcd_enable_irq(hba); - ret = ufshcd_vreg_set_hpm(hba); - if (ret) - goto disable_irq_and_vops_clks; - /* * Call vendor specific resume callback. As these callbacks may access * vendor specific host controller register space call them when the @@ -8797,7 +8797,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op) */ ret = ufshcd_vops_resume(hba, pm_op); if (ret) - goto disable_vreg; + goto disable_irq_and_vops_clks; /* For DeepSleep, the only supported option is to have the link off */ WARN_ON(ufshcd_is_ufs_dev_deepsleep(hba) && !ufshcd_is_link_off(hba)); @@ -8864,8 +8864,6 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op) ufshcd_link_state_transition(hba, old_link_state, 0); vendor_suspend: ufshcd_vops_suspend(hba, pm_op); -disable_vreg: - ufshcd_vreg_set_lpm(hba); disable_irq_and_vops_clks: ufshcd_disable_irq(hba); if (hba->clk_scaling.is_allowed) @@ -8876,6 +8874,8 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op) trace_ufshcd_clk_gating(dev_name(hba->dev), hba->clk_gating.state); } +disable_vreg: + ufshcd_vreg_set_lpm(hba); out: hba->pm_op_in_progress = 0; if (ret) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v2] ACPI: scan: Fix a Hyper-V Linux VM panic caused by buffer overflow
Linux VM on Hyper-V crashes with the latest mainline: [4.069624] detected buffer overflow in strcpy [4.077733] kernel BUG at lib/string.c:1149! .. [4.085819] RIP: 0010:fortify_panic+0xf/0x11 ... [4.085819] Call Trace: [4.085819] acpi_device_add.cold.15+0xf2/0xfb [4.085819] acpi_add_single_object+0x2a6/0x690 [4.085819] acpi_bus_check_add+0xc6/0x280 [4.085819] acpi_ns_walk_namespace+0xda/0x1aa [4.085819] acpi_walk_namespace+0x9a/0xc2 [4.085819] acpi_bus_scan+0x78/0x90 [4.085819] acpi_scan_init+0xfa/0x248 [4.085819] acpi_init+0x2c1/0x321 [4.085819] do_one_initcall+0x44/0x1d0 [4.085819] kernel_init_freeable+0x1ab/0x1f4 This is because of the recent buffer overflow detection in the commit 6a39e62abbaf ("lib: string.h: detect intra-object overflow in fortified string functions") Here acpi_device_bus_id->bus_id can only hold 14 characters, while the the acpi_device_hid(device) returns a 22-char string "HYPER_V_GEN_COUNTER_V1". Per ACPI Spec v6.2, Section 6.1.5 _HID (Hardware ID), if the ID is a string, it must be of the form AAA or , i.e. 7 chars or 8 chars. The field bus_id in struct acpi_device_bus_id was originally defined as char bus_id[9], and later was enlarged to char bus_id[15] in 2007 in the commit bb0958544f3c ("ACPI: use more understandable bus_id for ACPI devices") Fix the issue by changing the field bus_id to const char *, and use kstrdup_const() to initialize it. Signed-off-by: Dexuan Cui --- Changes in v2: strlcpy -> kstrdup_const. Thanks Rafael J. Wysocki! Change commit log accordingly. drivers/acpi/internal.h | 2 +- drivers/acpi/scan.c | 14 +- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h index cb229e24c563..e6a5d997241c 100644 --- a/drivers/acpi/internal.h +++ b/drivers/acpi/internal.h @@ -97,7 +97,7 @@ void acpi_scan_table_handler(u32 event, void *table, void *context); extern struct list_head acpi_bus_id_list; struct acpi_device_bus_id { - char bus_id[15]; + const char *bus_id; unsigned int instance_no; struct list_head node; }; diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index a1b226eb2ce2..8d49d192d1c1 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -486,6 +486,7 @@ static void acpi_device_del(struct acpi_device *device) acpi_device_bus_id->instance_no--; else { list_del(&acpi_device_bus_id->node); + kfree_const(acpi_device_bus_id->bus_id); kfree(acpi_device_bus_id); } break; @@ -674,7 +675,14 @@ int acpi_device_add(struct acpi_device *device, } if (!found) { acpi_device_bus_id = new_bus_id; - strcpy(acpi_device_bus_id->bus_id, acpi_device_hid(device)); + acpi_device_bus_id->bus_id = + kstrdup_const(acpi_device_hid(device), GFP_KERNEL); + if (!acpi_device_bus_id->bus_id) { + pr_err(PREFIX "Memory allocation error for bus id\n"); + result = -ENOMEM; + goto err_free_new_bus_id; + } + acpi_device_bus_id->instance_no = 0; list_add_tail(&acpi_device_bus_id->node, &acpi_bus_id_list); } @@ -709,6 +717,10 @@ int acpi_device_add(struct acpi_device *device, if (device->parent) list_del(&device->node); list_del(&device->wakeup_list); + + err_free_new_bus_id: + if (!found) + kfree(new_bus_id); mutex_unlock(&acpi_device_lock); err_detach: -- 2.19.1
Re: [PATCH 4/4] Input: omap4-keypad - simplify probe with devm
* Sebastian Reichel [210106 13:44]: > On Wed, Jan 06, 2021 at 02:58:22PM +0200, Tony Lindgren wrote: > > - struct resource *res; > > > > dev_pm_clear_wake_irq(&pdev->dev); > > - > > - free_irq(keypad_data->irq, keypad_data); > > - > > pm_runtime_dont_use_autosuspend(&pdev->dev); > > pm_runtime_disable(&pdev->dev); > > - > > input_unregister_device(keypad_data->input); > > not needed: > > * devm_input_allocate_device - allocate managed input device > * @dev: device owning the input device being created > * > * Returns prepared struct input_dev or %NULL. > * > * Managed input devices do not need to be explicitly unregistered or > * freed as it will be done automatically when owner device unbinds from > * its driver (or binding fails). [...] OK thanks will drop and fix up the reported autobuild warnings and repost. Looks like also the OMAP4_KEYPAD_AUTOIDLE_MS value of 50 is too long, I recently changed it from 30 but now have seen few stuck last pressed keys. Regards, Tony
[PATCH RESEND v3] venus: venc: set inband mode property to FW.
set HFI_PROPERTY_CONFIG_VENC_SYNC_FRAME_SEQUENCE_HEADER to FW to support inband sequence header mode. Signed-off-by: Dikshita Agarwal Changes since v2: - fixed Null pointer dereference (Stanimir, Fritz) - added set property call at correct place. --- drivers/media/platform/qcom/venus/venc.c | 14 ++ drivers/media/platform/qcom/venus/venc_ctrls.c | 17 - 2 files changed, 30 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/qcom/venus/venc.c b/drivers/media/platform/qcom/venus/venc.c index 3a2e449..ae21a7c 100644 --- a/drivers/media/platform/qcom/venus/venc.c +++ b/drivers/media/platform/qcom/venus/venc.c @@ -536,6 +536,7 @@ static int venc_set_properties(struct venus_inst *inst) struct hfi_idr_period idrp; struct hfi_quantization quant; struct hfi_quantization_range quant_range; + struct hfi_enable en; u32 ptype, rate_control, bitrate; u32 profile, level; int ret; @@ -655,6 +656,19 @@ static int venc_set_properties(struct venus_inst *inst) if (ret) return ret; + if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_H264 || + inst->fmt_cap->pixfmt == V4L2_PIX_FMT_HEVC) { + ptype = HFI_PROPERTY_CONFIG_VENC_SYNC_FRAME_SEQUENCE_HEADER; + if (ctr->header_mode == V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE) + en.enable = 0; + else + en.enable = 1; + + ret = hfi_session_set_property(inst, ptype, &en); + if (ret) + return ret; + } + if (!ctr->bitrate_peak) bitrate *= 2; else diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c b/drivers/media/platform/qcom/venus/venc_ctrls.c index cf860e6..3ce02ad 100644 --- a/drivers/media/platform/qcom/venus/venc_ctrls.c +++ b/drivers/media/platform/qcom/venus/venc_ctrls.c @@ -158,6 +158,20 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl) break; case V4L2_CID_MPEG_VIDEO_HEADER_MODE: ctr->header_mode = ctrl->val; + mutex_lock(&inst->lock); + if (inst->streamon_out && inst->streamon_cap) { + if (ctrl->val == V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE) + en.enable = 0; + else + en.enable = 1; + ptype = HFI_PROPERTY_CONFIG_VENC_SYNC_FRAME_SEQUENCE_HEADER; + ret = hfi_session_set_property(inst, ptype, &en); + if (ret) { + mutex_unlock(&inst->lock); + return ret; + } + } + mutex_unlock(&inst->lock); break; case V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB: break; @@ -289,7 +303,8 @@ int venc_ctrl_init(struct venus_inst *inst) v4l2_ctrl_new_std_menu(&inst->ctrl_handler, &venc_ctrl_ops, V4L2_CID_MPEG_VIDEO_HEADER_MODE, V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME, - 1 << V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME, + ~((1 << V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE) | + (1 << V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME)), V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE); v4l2_ctrl_new_std_menu(&inst->ctrl_handler, &venc_ctrl_ops, -- 2.7.4
Re: [PATCH 1/3] thermal: ti-soc-thermal: Fix stuck sensor with continuous mode for 4430
* H. Nikolaus Schaller [201230 13:29]: > > Am 30.12.2020 um 13:55 schrieb Adam Ford : > > On Wed, Dec 30, 2020 at 2:43 AM Tony Lindgren wrote: > >> > >> At least for 4430, trying to use the single conversion mode eventually > >> hangs the thermal sensor. This can be quite easily seen with errors: > >> > >> thermal thermal_zone0: failed to read out thermal zone (-5) ... > > I don't have an OMAP4, but if you want, I can test a DM3730. > > Indeed I remember a similar discussion from the DM3730 [1]. temp values were > always those from the last measurement. E.g. the first one was done > during (cold) boot and the first request after 10 minutes did show a > quite cold system... The next one did show a hot system independent > of what had been between (suspend or high activity). > > It seems as if it was even reproducible with a very old kernel on a > BeagleBoard. > So it is quite fundamental. > > We tried to fix it but did not come to a solution [2]. So we opened an issue > in our tracker [3] and decided to stay with continuous conversion although > this > raises idle mode processor load. Hmm so maybe eocz high always times out in single mode since it also triggers at least on dra7? Yes it would be great if you guys can the $subject patch a try at least on your omap36xx and omap5 boards and see if you see eocz time out warnings in dmesg. Regards, Tony
Re: [PATCH 1/3] thermal: ti-soc-thermal: Fix stuck sensor with continuous mode for 4430
* Péter Ujfalusi [201231 12:55]: > On 12/30/20 10:43 AM, Tony Lindgren wrote: > > @@ -58,7 +58,8 @@ omap4430_adc_to_temp[OMAP4430_ADC_END_VALUE - > > OMAP4430_ADC_START_VALUE + 1] = { > > const struct ti_bandgap_data omap4430_data = { > > .features = TI_BANDGAP_FEATURE_MODE_CONFIG | > > TI_BANDGAP_FEATURE_CLK_CTRL | > > - TI_BANDGAP_FEATURE_POWER_SWITCH, > > + TI_BANDGAP_FEATURE_POWER_SWITCH | > > + TI_BANDGAP_FEATURE_CONT_MODE_ONLY, > > Can we add a comment with the observations? Sure, and I also noticed that the timeout triggers also on dra7 too. I need to recheck what all are affected.. At least we now see warnings on the SoCs affected. > > @@ -605,8 +606,10 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, > > int id) > > u32 counter = 1000; > > struct temp_sensor_registers *tsr; > > > > - /* Select single conversion mode */ > > - if (TI_BANDGAP_HAS(bgp, MODE_CONFIG)) > > + /* Select continuous or single conversion mode */ > > + if (TI_BANDGAP_HAS(bgp, CONT_MODE_ONLY)) > > + RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 1); > > + else if (TI_BANDGAP_HAS(bgp, MODE_CONFIG)) > > RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 0); > > Would not be better to: > if (TI_BANDGAP_HAS(bgp, MODE_CONFIG)) { > if (TI_BANDGAP_HAS(bgp, CONT_MODE_ONLY)) > RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 1); > else > RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 0); > } > > One can only switch to cont/single mode if the mode config is possible. Yup makes sense thanks for spotting that. Regards, Tony
RE: dmaengine : xilinx_dma two issues
> -Original Message- > From: Radhey Shyam Pandey > Sent: Monday, January 4, 2021 10:50 AM > To: Paul Thomas ; Dan Williams > ; Vinod Koul ; Michal Simek > ; Matthew Murrian ; > Romain Perier ; Krzysztof Kozlowski > ; Marc Ferland ; Sebastian von Ohr > ; dmaeng...@vger.kernel.org; Linux ARM arm-ker...@lists.infradead.org>; linux-kernel ker...@vger.kernel.org>; Shravya Kumbham ; git > > Subject: RE: dmaengine : xilinx_dma two issues > > > -Original Message- > > From: Paul Thomas > > Sent: Monday, December 28, 2020 10:14 AM > > To: Dan Williams ; Vinod Koul > > ; Michal Simek ; Radhey Shyam > > Pandey ; Matthew Murrian > > ; Romain Perier > ; > > Krzysztof Kozlowski ; Marc Ferland > > ; Sebastian von Ohr ; > > dmaeng...@vger.kernel.org; Linux ARM > arm-ker...@lists.infradead.org>; linux-kernel > ker...@vger.kernel.org> > > Subject: dmaengine : xilinx_dma two issues > > > > Hello, > > > > I'm trying to get the 5.10 kernel up and running for our system, and > > I'm running into a couple of issues with xilinx_dma. > + (Xilinx mailing list) > > Thanks for bringing the issues to our notice. Replies inline. > > > > > First, commit 14ccf0aab46e 'dmaengine: xilinx_dma: In dma channel > > probe fix node order dependency' breaks our usage. Before this commit a > call to: > > dma_request_chan(&indio_dev->dev, "axi_dma_0"); returns fine, but > > after that commit it returns -19. The reason for this seems to be that > > the only channel that is setup is channel 1 (chan->id is 1 in > xilinx_dma_chan_probe()). > > However in > > of_dma_xilinx_xlate() chan_id is gets set to 0 (int chan_id = > > dma_spec- > > >args[0];), which causes the: > > !xdev->chan[chan_id] > > test to fail in of_dma_xilinx_xlate() > > What is the channel number passed in > dmaclient DT? Any update on this issue? > > dmas = <& axi_dma_0 1> > dma-names = "axi_dma_0" > > > > > Our device-tree entry looks like this: > > axi_dma_0: dma@80002000 { > > status = "okay"; > > #dma-cells = <1>; > > compatible = "xlnx,axi-dma-1.00.a"; > > interrupt-parent = <&gic>; > > interrupts = <0 89 4>; > > reg = <0x0 0x80002000 0x0 0x1000>; > > xlnx,addrwidth = <0x20>; > > clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk LPD_LSBUS>, > > <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk LPD_LSBUS>; > > clock-names = "s_axi_lite_aclk", "m_axi_sg_aclk", > > "m_axi_mm2s_aclk", "m_axi_s2mm_aclk"; > > dma-channel@80002030 { > > compatible = "xlnx,axi-dma-s2mm-channel"; > > dma-channels = <0x1>; > > interrupts = <0 89 4>; > > xlnx,datawidth = <0x20>; > > xlnx,device-id = <0x0>; > > }; > > }; > > > > This is on a 5.10.1 kernel on arm64 zynqmp hardware. > > > > The second issue goes a little further back to commit e81274cd6b526 > > 'dmaengine: add support to dynamic register/unregister of channels'. > > After this commit even just removing the module 'rmmod xilinx_dma', > > without ever using it, results in a kernel oops like this: > > [ 37.214568] xilinx-vdma 80002000.dma: ch 0: SG disabled > > [ 37.219807] xilinx-vdma 80002000.dma: WARN: Device release is not > > defined so it is not safe to unbind this driver while in use > > [ 37.231299] xilinx-vdma 80002000.dma: Xilinx AXI DMA Engine Driver > > Probed!! > > [ 42.100660] Unable to handle kernel paging request at virtual > > address dead0108 > > [ 42.108598] Mem abort info: > > [ 42.111393] ESR = 0x9644 > > [ 42.114443] EC = 0x25: DABT (current EL), IL = 32 bits > > [ 42.119744] SET = 0, FnV = 0 > > [ 42.122794] EA = 0, S1PTW = 0 > > [ 42.125918] Data abort info: > > [ 42.128789] ISV = 0, ISS = 0x0044 > > [ 42.132617] CM = 0, WnR = 1 > > [ 42.135577] [dead0108] address between user and kernel > > address ranges > > [ 42.142705] Internal error: Oops: 9644 [#1] SMP > > [ 42.147566] Modules linked in: xilinx_dma(-) clk_xlnx_clock_wizard > > uio_pdrv_genirq > > [ 42.155139] CPU: 1 PID: 2075 Comm: rmmod Not tainted > > 5.10.1-00026-g3a2e6dd7a05-dirty #192 > > [ 42.163302] Hardware name: Enclustra XU5 SOM (DT) > > [ 42.167992] pstate: 4005 (nZcv daif -PAN -UAO -TCO BTYPE=--) > > [ 42.173996] pc : xilinx_dma_chan_remove+0x74/0xa0 [xilinx_dma] > > [ 42.179815] lr : xilinx_dma_chan_remove+0x70/0xa0 [xilinx_dma] > > [ 42.185636] sp : ffc01112bca0 > > [ 42.188935] x29: ffc01112bca0 x28: ff80402ea640 > > [ 42.194238] x27: x26: > > [ 42.199542] x25: x24: > > [ 42.204845] x23: x22: > > [ 42.210149] x21: ffc0088a2028 x20: ff8040c08410 > > [ 42.215452] x19: ff80423fa480 x18: > > [ 42.220756] x17: x16: > > [ 42.226059] x15: ffc010ce88c8 x14: 0040 > > [ 42.231363] x13: ff00 x1
RE: [PATCH] ACPI: scan: Fix a Hyper-V Linux VM panic caused by buffer overflow
> From: Rafael J. Wysocki > Sent: Thursday, January 7, 2021 5:48 AM > > > > Linux VM on Hyper-V crashes with the latest mainline: > > > > ... > The root cause is a VM issue AFAICS, though. Yes. > It doesn't look like the right fix to me, though. > > The problem appears to be that the string coming from _HID is too long > (which is a spec violation). Yes. We have requested Hyper-V team to fix the buggy BIOS/firmware, but we have to cope with the existing buggy Hyper-V hosts, at least before the Hyper-V fix is deployed to the hosts, and some old versions of the hosts may not get updated. :-( > The patch truncates it to match the > length of the target buffer, but that is not particularly useful. > > It would be better to use something like kstrdup_const() to initialize > acpi_device_bus_id->bus_id IMV. Makes sense. I'll submit v2 shortly. Thanks, -- Dexuan
[PATCH v3] venus: venc: set inband mode property to FW.
set HFI_PROPERTY_CONFIG_VENC_SYNC_FRAME_SEQUENCE_HEADER to FW to support inband sequence header mode. Signed-off-by: Dikshita Agarwal Changes since v2: - fixed Null pointer dereference (Stanimir, Fritz) - added set property call at correct place. --- drivers/media/platform/qcom/venus/venc.c | 14 ++ drivers/media/platform/qcom/venus/venc_ctrls.c | 17 - 2 files changed, 30 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/qcom/venus/venc.c b/drivers/media/platform/qcom/venus/venc.c index 3a2e449..bd6597c 100644 --- a/drivers/media/platform/qcom/venus/venc.c +++ b/drivers/media/platform/qcom/venus/venc.c @@ -536,6 +536,7 @@ static int venc_set_properties(struct venus_inst *inst) struct hfi_idr_period idrp; struct hfi_quantization quant; struct hfi_quantization_range quant_range; + struct hfi_enable en; u32 ptype, rate_control, bitrate; u32 profile, level; int ret; @@ -655,6 +656,19 @@ static int venc_set_properties(struct venus_inst *inst) if (ret) return ret; + if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_H264 || + inst->fmt_cap->pixfmt == V4L2_PIX_FMT_HEVC) { + ptype = HFI_PROPERTY_CONFIG_VENC_SYNC_FRAME_SEQUENCE_HEADER; + if (ctr->header_mode == V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE) + en.enable = 0; + else + en.enable = 1; + + ret = hfi_session_set_property(inst, ptype, &en); + if (ret) + return ret; + } + if (!ctr->bitrate_peak) bitrate *= 2; else diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c b/drivers/media/platform/qcom/venus/venc_ctrls.c index cf860e6..3ce02ad 100644 --- a/drivers/media/platform/qcom/venus/venc_ctrls.c +++ b/drivers/media/platform/qcom/venus/venc_ctrls.c @@ -158,6 +158,20 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl) break; case V4L2_CID_MPEG_VIDEO_HEADER_MODE: ctr->header_mode = ctrl->val; + mutex_lock(&inst->lock); + if (inst->streamon_out && inst->streamon_cap) { + if (ctrl->val == V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE) + en.enable = 0; + else + en.enable = 1; + ptype = HFI_PROPERTY_CONFIG_VENC_SYNC_FRAME_SEQUENCE_HEADER; + ret = hfi_session_set_property(inst, ptype, &en); + if (ret) { + mutex_unlock(&inst->lock); + return ret; + } + } + mutex_unlock(&inst->lock); break; case V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB: break; @@ -289,7 +303,8 @@ int venc_ctrl_init(struct venus_inst *inst) v4l2_ctrl_new_std_menu(&inst->ctrl_handler, &venc_ctrl_ops, V4L2_CID_MPEG_VIDEO_HEADER_MODE, V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME, - 1 << V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME, + ~((1 << V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE) | + (1 << V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME)), V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE); v4l2_ctrl_new_std_menu(&inst->ctrl_handler, &venc_ctrl_ops, -- 2.7.4
Re: [PATCH 1/1] arm64: make section size configurable for memory hotplug
On 1/7/21 6:00 PM, David Hildenbrand wrote: > On 06.01.21 07:11, Anshuman Khandual wrote: >> Hi Sudershan, >> >> This patch (and the cover letter) does not copy LAKML even though the >> entire change here is arm64 specific. Please do copy all applicable >> mailing lists for a given patch. >> >> On 1/6/21 6:58 AM, Sudarshan Rajagopalan wrote: >>> Currently on arm64, memory section size is hard-coded to 1GB. >>> Make this configurable if memory-hotplug is enabled, to support >>> more finer granularity for hotplug-able memory. >> >> Section size has always been decided by the platform. It cannot be a >> configurable option because the user would not know the constraints >> for memory representation on the platform and besides it also cannot >> be trusted. >> >>> >>> Signed-off-by: Sudarshan Rajagopalan >>> --- >>> arch/arm64/Kconfig | 11 +++ >>> arch/arm64/include/asm/sparsemem.h | 4 >>> 2 files changed, 15 insertions(+) >>> >>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >>> index 6d232837cbee..34124eee65da 100644 >>> --- a/arch/arm64/Kconfig >>> +++ b/arch/arm64/Kconfig >>> @@ -294,6 +294,17 @@ config ARCH_ENABLE_MEMORY_HOTREMOVE >>> config SMP >>> def_bool y >>> >>> +config HOTPLUG_SIZE_BITS >>> + int "Memory hotplug block size(29 => 512MB 30 => 1GB)" > > "Memory hotplug block size" and "HOTPLUG_SIZE_BITS" is confusing. It's > the section size. Please use that terminology. > > (if at all, it would have to be "minimum memory hot(un)plug > granularity", but even that is somewhat misleading) > > "SECTION_SIZE_BITS" > > But I agree that letting the user configure it is sub-optimal. > >>> + depends on SPARSEMEM >>> + depends on MEMORY_HOTPLUG >>> + range 28 30 >> >> 28 would not work for 64K pages. > > @Anshuman, what's your feeling about changing this to 128 MB for 4k/16k > base pages (as we have on x86-64 right now) and 512 MB for 64k as > default for now? To summarize, the section size bits for each base page size config should always a. Avoid (MAX_ORDER - 1 + PAGE_SHIFT) > SECTION_SIZE_BITS b. Provide minimum possible section size for a given base page config to have increased agility during memory hotplug operations and reduced vmemmap wastage for sections with holes. c. Allow 4K base page configs to have PMD based vmemmap mappings Because CONFIG_FORCE_MAX_ZONEORDER is always defined on arm64 platform, the following would always avoid the condition (a) SECTION_SIZE_BITS (CONFIG_FORCE_MAX_ZONEORDER - 1 + PAGE_SHIFT) - 22 (11 - 1 + 12) for 4K pages - 24 (11 - 1 + 14) for 16K pages without THP - 25 (12 - 1 + 14) for 16K pages with THP - 26 (11 - 1 + 16) for 64K pages without THP - 29 (14 - 1 + 16) for 64K pages with THP Apart from overriding 4K base page size config to have 27 as section size bits, should not all other values be okay here ? But then wondering what benefit 128MB (27 bits) section size for 16K config would have ? OR the objective here is to match 16K page size config with default x86-64. > > (If we worry about the number of section bits in page->flags, we could > glue it to vmemmap support where that does not matter) Could you please elaborate ? Could smaller section size bits numbers like 22 or 24 create problems in page->flags without changing other parameters like NR_CPUS or NODES_SHIFT ? A quick test with 64K base page without THP i.e 26 bits in section size, fails to boot. As you have suggested, probably constant defaults (128MB for 4K/16K, 512MB for 64K) might be better than depending on the CONFIG_FORCE_MAX_ZONEORDER, at least for now.
Re: [PATCH v1 1/3] cpufreq: intel_pstate: Always read hwp_cap_cached with READ_ONCE()
On Thu, Jan 07, 2021 at 07:42:15PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Because intel_pstate_get_hwp_max() which updates hwp_cap_cached > may run in parallel with the readers of it, annotate all of the > read accesses to it with READ_ONCE(). > > Signed-off-by: Rafael J. Wysocki Tested-by: Chen Yu thanks, Chenyu
Re: [PATCH v1 2/3] cpufreq: intel_pstate: Change intel_pstate_get_hwp_max() argument
On Thu, Jan 07, 2021 at 07:43:30PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > All of the callers of intel_pstate_get_hwp_max() access the struct > cpudata object that corresponds to the given CPU already and the > function itself needs to access that object (in order to update > hwp_cap_cached), so modify the code to pass a struct cpudata pointer > to it instead of the CPU number. > > Signed-off-by: Rafael J. Wysocki Tested-by: Chen Yu thanks, Chenyu
Re: drivers/block/rnbd/rnbd-clt.c:387:2: error: implicit declaration of function 'sg_free_table_chained'
On Fri, Jan 8, 2021 at 7:46 AM kernel test robot wrote: > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: f5e6c330254ae691f6d7befe61c786eb5056007e > commit: 5a1328d0c3a757cdd8c65f4dfe0a02502a5810bc block/rnbd-clt: Dynamically > allocate sglist for rnbd_iu > date: 3 weeks ago > config: parisc-randconfig-r011-20210108 (attached as .config) > compiler: hppa-linux-gcc (GCC) 9.3.0 > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5a1328d0c3a757cdd8c65f4dfe0a02502a5810bc > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout 5a1328d0c3a757cdd8c65f4dfe0a02502a5810bc > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > ARCH=parisc > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > >drivers/block/rnbd/rnbd-clt.c: In function 'rnbd_softirq_done_fn': > >> drivers/block/rnbd/rnbd-clt.c:387:2: error: implicit declaration of > >> function 'sg_free_table_chained' [-Werror=implicit-function-declaration] > 387 | sg_free_table_chained(&iu->sgt, RNBD_INLINE_SG_CNT); > | ^ >drivers/block/rnbd/rnbd-clt.c: In function 'rnbd_queue_rq': > >> drivers/block/rnbd/rnbd-clt.c:1142:8: error: implicit declaration of > >> function 'sg_alloc_table_chained'; did you mean 'sg_alloc_table'? > >> [-Werror=implicit-function-declaration] > 1142 | err = sg_alloc_table_chained(&iu->sgt, > |^~ > |sg_alloc_table >cc1: some warnings being treated as errors > > > vim +/sg_free_table_chained +387 drivers/block/rnbd/rnbd-clt.c Thanks for reporting, I've found the problem, we need to select SG_POOL in Kconfig for RNBD client, will send out a fix soon today. Regards! Jack
Re: [PATCH v1 3/3] cpufreq: intel_pstate: Rename two functions
On Thu, Jan 07, 2021 at 07:44:18PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Rename intel_cpufreq_adjust_hwp() and intel_cpufreq_adjust_perf_ctl() > to intel_cpufreq_hwp_update() and intel_cpufreq_perf_ctl_update(), > respectively, to avoid possible confusion with the ->adjist_perf() > callback function, intel_cpufreq_adjust_perf(). > > Signed-off-by: Rafael J. Wysocki > --- Tested-by: Chen Yu
[RESEND v5 1/4] KVM: VMX: Convert vcpu_vmx.exit_reason to a union
From: Sean Christopherson Convert vcpu_vmx.exit_reason from a u32 to a union (of size u32). The full VM_EXIT_REASON field is comprised of a 16-bit basic exit reason in bits 15:0, and single-bit modifiers in bits 31:16. Historically, KVM has only had to worry about handling the "failed VM-Entry" modifier, which could only be set in very specific flows and required dedicated handling. I.e. manually stripping the FAILED_VMENTRY bit was a somewhat viable approach. But even with only a single bit to worry about, KVM has had several bugs related to comparing a basic exit reason against the full exit reason store in vcpu_vmx. Upcoming Intel features, e.g. SGX, will add new modifier bits that can be set on more or less any VM-Exit, as opposed to the significantly more restricted FAILED_VMENTRY, i.e. correctly handling everything in one-off flows isn't scalable. Tracking exit reason in a union forces code to explicitly choose between consuming the full exit reason and the basic exit, and is a convenient way to document and access the modifiers. No functional change intended. Cc: Xiaoyao Li Signed-off-by: Sean Christopherson Signed-off-by: Chenyi Qiang --- arch/x86/kvm/vmx/nested.c | 42 +++- arch/x86/kvm/vmx/vmx.c| 68 --- arch/x86/kvm/vmx/vmx.h| 25 +- 3 files changed, 86 insertions(+), 49 deletions(-) diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index e2f26564a12d..57fe60c2cf34 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -3311,7 +3311,11 @@ enum nvmx_vmentry_status nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12 = get_vmcs12(vcpu); enum vm_entry_failure_code entry_failure_code; bool evaluate_pending_interrupts; - u32 exit_reason, failed_index; + union vmx_exit_reason exit_reason = { + .basic = EXIT_REASON_INVALID_STATE, + .failed_vmentry = 1, + }; + u32 failed_index; if (kvm_check_request(KVM_REQ_TLB_FLUSH_CURRENT, vcpu)) kvm_vcpu_flush_tlb_current(vcpu); @@ -3363,7 +3367,7 @@ enum nvmx_vmentry_status nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu, if (nested_vmx_check_guest_state(vcpu, vmcs12, &entry_failure_code)) { - exit_reason = EXIT_REASON_INVALID_STATE; + exit_reason.basic = EXIT_REASON_INVALID_STATE; vmcs12->exit_qualification = entry_failure_code; goto vmentry_fail_vmexit; } @@ -3374,7 +3378,7 @@ enum nvmx_vmentry_status nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu, vcpu->arch.tsc_offset += vmcs12->tsc_offset; if (prepare_vmcs02(vcpu, vmcs12, &entry_failure_code)) { - exit_reason = EXIT_REASON_INVALID_STATE; + exit_reason.basic = EXIT_REASON_INVALID_STATE; vmcs12->exit_qualification = entry_failure_code; goto vmentry_fail_vmexit_guest_mode; } @@ -3384,7 +3388,7 @@ enum nvmx_vmentry_status nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu, vmcs12->vm_entry_msr_load_addr, vmcs12->vm_entry_msr_load_count); if (failed_index) { - exit_reason = EXIT_REASON_MSR_LOAD_FAIL; + exit_reason.basic = EXIT_REASON_MSR_LOAD_FAIL; vmcs12->exit_qualification = failed_index; goto vmentry_fail_vmexit_guest_mode; } @@ -3452,7 +3456,7 @@ enum nvmx_vmentry_status nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu, return NVMX_VMENTRY_VMEXIT; load_vmcs12_host_state(vcpu, vmcs12); - vmcs12->vm_exit_reason = exit_reason | VMX_EXIT_REASONS_FAILED_VMENTRY; + vmcs12->vm_exit_reason = exit_reason.full; if (enable_shadow_vmcs || vmx->nested.hv_evmcs) vmx->nested.need_vmcs12_to_shadow_sync = true; return NVMX_VMENTRY_VMEXIT; @@ -5538,7 +5542,12 @@ static int handle_vmfunc(struct kvm_vcpu *vcpu) return kvm_skip_emulated_instruction(vcpu); fail: - nested_vmx_vmexit(vcpu, vmx->exit_reason, + /* +* This is effectively a reflected VM-Exit, as opposed to a synthesized +* nested VM-Exit. Pass the original exit reason, i.e. don't hardcode +* EXIT_REASON_VMFUNC as the exit reason. +*/ + nested_vmx_vmexit(vcpu, vmx->exit_reason.full, vmx_get_intr_info(vcpu), vmx_get_exit_qual(vcpu)); return 1; @@ -5606,7 +5615,8 @@ static bool nested_vmx_exit_handled_io(struct kvm_vcpu *vcpu, * MSR bitmap. This may be the case even when L0 doesn't use MSR bitmaps. */ static bool nested_vmx_
[RESEND v5 4/4] KVM: X86: Add the Document for KVM_CAP_X86_BUS_LOCK_EXIT
Introduce a new capability named KVM_CAP_X86_BUS_LOCK_EXIT, which is used to handle bus locks detected in guest. It allows the userspace to do custom throttling policies to mitigate the 'noisy neighbour' problem. Signed-off-by: Chenyi Qiang --- Documentation/virt/kvm/api.rst | 45 +++--- 1 file changed, 42 insertions(+), 3 deletions(-) diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 70254eaa5229..68bdefca5372 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -4887,9 +4887,11 @@ local APIC is not used. __u16 flags; More architecture-specific flags detailing state of the VCPU that may -affect the device's behavior. The only currently defined flag is -KVM_RUN_X86_SMM, which is valid on x86 machines and is set if the -VCPU is in system management mode. +affect the device's behavior. Current defined flags: + /* x86, set if the VCPU is in system management mode */ + #define KVM_RUN_X86_SMM (1 << 0) + /* x86, set if bus lock detected in VM */ + #define KVM_RUN_BUS_LOCK(1 << 1) :: @@ -6032,6 +6034,43 @@ KVM_EXIT_X86_RDMSR and KVM_EXIT_X86_WRMSR exit notifications which user space can then handle to implement model specific MSR handling and/or user notifications to inform a user that an MSR was not handled. +7.22 KVM_CAP_X86_BUS_LOCK_EXIT +--- + +:Architectures: x86 +:Target: VM +:Parameters: args[0] defines the policy used when bus locks detected in guest +:Returns: 0 on success, -EINVAL when args[0] contains invalid bits + +Valid bits in args[0] are:: + + #define KVM_BUS_LOCK_DETECTION_OFF (1 << 0) + #define KVM_BUS_LOCK_DETECTION_EXIT (1 << 1) + +Enabling this capability on a VM provides userspace with a way to select +a policy to handle the bus locks detected in guest. Userspace can obtain +the supported modes from the result of KVM_CHECK_EXTENSION and define it +through the KVM_ENABLE_CAP. + +KVM_BUS_LOCK_DETECTION_OFF and KVM_BUS_LOCK_DETECTION_EXIT are supported +currently and mutually exclusive with each other. More bits can be added in +the future. + +With KVM_BUS_LOCK_DETECTION_OFF set, bus locks in guest will not cause vm exits +so that no additional actions are needed. This is the default mode. + +With KVM_BUS_LOCK_DETECTION_EXIT set, vm exits happen when bus lock detected +in VM. KVM just exits to userspace when handling them. Userspace can enforce +its own throttling or other policy based mitigations. + +This capability is aimed to address the thread that VM can exploit bus locks to +degree the performance of the whole system. Once the userspace enable this +capability and select the KVM_BUS_LOCK_DETECTION_EXIT mode, KVM will set the +KVM_RUN_BUS_LOCK flag in vcpu-run->flags field and exit to userspace. Concerning +the bus lock vm exit can be preempted by a higher priority VM exit, the exit +notifications to userspace can be KVM_EXIT_BUS_LOCK or other reasons. +KVM_RUN_BUS_LOCK flag is used to distinguish between them. + 8. Other capabilities. == -- 2.17.1
[RESEND v5 2/4] KVM: X86: Reset the vcpu->run->flags at the beginning of vcpu_run
Reset the vcpu->run->flags at the beginning of kvm_arch_vcpu_ioctl_run. It can avoid every thunk of code that needs to set the flag clear it, which increases the odds of missing a case and ending up with a flag in an undefined state. Signed-off-by: Chenyi Qiang --- arch/x86/kvm/x86.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 3f7c1fc7a3ce..ded2149497ba 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -8189,12 +8189,14 @@ static void post_kvm_run_save(struct kvm_vcpu *vcpu) kvm_run->if_flag = !vcpu->arch.guest_state_protected && (kvm_get_rflags(vcpu) & X86_EFLAGS_IF) != 0; - kvm_run->flags = is_smm(vcpu) ? KVM_RUN_X86_SMM : 0; kvm_run->cr8 = kvm_get_cr8(vcpu); kvm_run->apic_base = kvm_get_apic_base(vcpu); kvm_run->ready_for_interrupt_injection = pic_in_kernel(vcpu->kvm) || kvm_vcpu_ready_for_interrupt_injection(vcpu); + + if (is_smm(vcpu)) + kvm_run->flags |= KVM_RUN_X86_SMM; } static void update_cr8_intercept(struct kvm_vcpu *vcpu) @@ -9305,6 +9307,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu) vcpu_load(vcpu); kvm_sigset_activate(vcpu); + kvm_run->flags = 0; kvm_load_guest_fpu(vcpu); if (unlikely(vcpu->arch.mp_state == KVM_MP_STATE_UNINITIALIZED)) { -- 2.17.1
[RESEND v5 3/4] KVM: VMX: Enable bus lock VM exit
Virtual Machine can exploit bus locks to degrade the performance of system. Bus lock can be caused by split locked access to writeback(WB) memory or by using locks on uncacheable(UC) memory. The bus lock is typically >1000 cycles slower than an atomic operation within a cache line. It also disrupts performance on other cores (which must wait for the bus lock to be released before their memory operations can complete). To address the threat, bus lock VM exit is introduced to notify the VMM when a bus lock was acquired, allowing it to enforce throttling or other policy based mitigations. A VMM can enable VM exit due to bus locks by setting a new "Bus Lock Detection" VM-execution control(bit 30 of Secondary Processor-based VM execution controls). If delivery of this VM exit was preempted by a higher priority VM exit (e.g. EPT misconfiguration, EPT violation, APIC access VM exit, APIC write VM exit, exception bitmap exiting), bit 26 of exit reason in vmcs field is set to 1. In current implementation, the KVM exposes this capability through KVM_CAP_X86_BUS_LOCK_EXIT. The user can get the supported mode bitmap (i.e. off and exit) and enable it explicitly (disabled by default). If bus locks in guest are detected by KVM, exit to user space even when current exit reason is handled by KVM internally. Set a new field KVM_RUN_BUS_LOCK in vcpu->run->flags to inform the user space that there is a bus lock detected in guest. Document for Bus Lock VM exit is now available at the latest "Intel Architecture Instruction Set Extensions Programming Reference". Document Link: https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html Co-developed-by: Xiaoyao Li Signed-off-by: Xiaoyao Li Signed-off-by: Chenyi Qiang --- arch/x86/include/asm/kvm_host.h| 7 ++ arch/x86/include/asm/vmx.h | 1 + arch/x86/include/asm/vmxfeatures.h | 1 + arch/x86/include/uapi/asm/kvm.h| 1 + arch/x86/include/uapi/asm/vmx.h| 4 +++- arch/x86/kvm/vmx/capabilities.h| 6 + arch/x86/kvm/vmx/vmx.c | 37 -- arch/x86/kvm/vmx/vmx.h | 2 +- arch/x86/kvm/x86.c | 23 +++ include/uapi/linux/kvm.h | 5 10 files changed, 83 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 3ab7b46087b7..17d882dfee4f 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -52,6 +52,9 @@ #define KVM_DIRTY_LOG_MANUAL_CAPS (KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE | \ KVM_DIRTY_LOG_INITIALLY_SET) +#define KVM_BUS_LOCK_DETECTION_VALID_MODE (KVM_BUS_LOCK_DETECTION_OFF | \ +KVM_BUS_LOCK_DETECTION_EXIT) + /* x86-specific vcpu->requests bit members */ #define KVM_REQ_MIGRATE_TIMER KVM_ARCH_REQ(0) #define KVM_REQ_REPORT_TPR_ACCESS KVM_ARCH_REQ(1) @@ -998,6 +1001,8 @@ struct kvm_arch { struct msr_bitmap_range ranges[16]; } msr_filter; + bool bus_lock_detection_enabled; + struct kvm_pmu_event_filter *pmu_event_filter; struct task_struct *nx_lpage_recovery_thread; @@ -1407,6 +1412,8 @@ extern u8 kvm_tsc_scaling_ratio_frac_bits; extern u64 kvm_max_tsc_scaling_ratio; /* 1ull << kvm_tsc_scaling_ratio_frac_bits */ extern u64 kvm_default_tsc_scaling_ratio; +/* bus lock detection supported? */ +extern bool kvm_has_bus_lock_exit; extern u64 kvm_mce_cap_supported; diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h index 38ca445a8429..358707f60d99 100644 --- a/arch/x86/include/asm/vmx.h +++ b/arch/x86/include/asm/vmx.h @@ -73,6 +73,7 @@ #define SECONDARY_EXEC_PT_USE_GPA VMCS_CONTROL_BIT(PT_USE_GPA) #define SECONDARY_EXEC_TSC_SCALING VMCS_CONTROL_BIT(TSC_SCALING) #define SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE VMCS_CONTROL_BIT(USR_WAIT_PAUSE) +#define SECONDARY_EXEC_BUS_LOCK_DETECTION VMCS_CONTROL_BIT(BUS_LOCK_DETECTION) #define PIN_BASED_EXT_INTR_MASK VMCS_CONTROL_BIT(INTR_EXITING) #define PIN_BASED_NMI_EXITING VMCS_CONTROL_BIT(NMI_EXITING) diff --git a/arch/x86/include/asm/vmxfeatures.h b/arch/x86/include/asm/vmxfeatures.h index 9915990fd8cf..e80523346274 100644 --- a/arch/x86/include/asm/vmxfeatures.h +++ b/arch/x86/include/asm/vmxfeatures.h @@ -83,5 +83,6 @@ #define VMX_FEATURE_TSC_SCALING( 2*32+ 25) /* Scale hardware TSC when read in guest */ #define VMX_FEATURE_USR_WAIT_PAUSE ( 2*32+ 26) /* Enable TPAUSE, UMONITOR, UMWAIT in guest */ #define VMX_FEATURE_ENCLV_EXITING ( 2*32+ 28) /* "" VM-Exit on ENCLV (leaf dependent) */ +#define VMX_FEATURE_BUS_LOCK_DETECTION ( 2*32+ 30) /* VM-Exit when bus lock caused */ #endif /* _ASM_X86_VMXFEATURES_H */ diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch
[RESEND v5 0/4] Add bus lock VM exit support
Hi all, Resend a rebased version. Hope to receive your comments. --- This patch series add the support for bus lock VM exit in KVM. It is a sub-feature of bus lock detection. When it is enabled by the VMM, the processor generates a "Bus Lock" VM exit following execution of an instruction if the processor detects that one or more bus locks were caused the instruction was being executed (due to either direct access by the instruction or stuffed accesses like through A/D updates). Bus lock VM exit will introduce a new modifier bit (bit 26) in exit_reason field in VMCS which indicates bus lock VM exit is preempted by a higher priority VM exit. The first patch is to apply Sean's refactor for vcpu_vmx.exit_reason as a preparation patch for bus lock VM exit support. The second patch is the refactor for vcpu->run->flags. Bus lock VM exit will introduce a new field in the flags to inform the userspace that there's a bus lock detected in guest. It's also a preparation patch. The third patch is the concrete enabling working for bus lock VM exit. Add the support to set the capability to enable bus lock VM exit. The current implementation is just exiting to userspace when handling the bus lock detected in guest. The detail of throttling policy in user space is still to be discussed. We may enforce ratelimit on bus lock in guest, inject some sleep time, or... We hope to get more ideas on this. Document for Bus Lock Detection is now available at the latest "Intel Architecture Instruction Set Extensions Programming Reference". Document Link: https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html --- Changelogs v5->v5: - rebase on top of v5.11-rc1 - no difference compared with the last version - v5:https://lore.kernel.org/lkml/20201106090315.18606-1-chenyi.qi...@intel.com/ v4->v5: - rebase on top on v5.10-rc2 - add preparation patch that reset the vcpu->run->flags at the beginning of the vcpu_run.(Suggested by Sean) - set the KVM_RUN_BUS_LOCK for all bus lock exit to avoid checking both exit_reason and run->flags - add the document to introduce the new kvm capability (KVM_CAP_X86_BUS_LOCK_EXIT) - v4:https://lore.kernel.org/lkml/20201012033542.4696-1-chenyi.qi...@intel.com/ v3->v4: - rebase on top of v5.9 - some code cleanup. - v3:https://lore.kernel.org/lkml/20200910083751.26686-1-chenyi.qi...@intel.com/ v2->v3: - use a bitmap to get/set the capability of bus lock detection. we support exit and off mode currently. - put the handle of exiting to userspace in vmx.c, thus no need to define a shadow to track vmx->exit_reason.bus_lock_detected. - remove the vcpu->stats.bus_locks since every bus lock exits to userspace. - v2:https://lore.kernel.org/lkml/20200817033604.5836-1-chenyi.qi...@intel.com/ v1->v2: - resolve Vitaly's comment to introduce the KVM_EXIT_BUS_LOCK and a capability to enable it. - add the support to exit to user space when handling bus locks. - extend the vcpu->run->flags to indicate bus lock detected for other exit reasons when exiting to user space. - v1:https://lore.kernel.org/lkml/20200628085341.5107-1-chenyi.qi...@intel.com/ --- Chenyi Qiang (3): KVM: X86: Reset the vcpu->run->flags at the beginning of vcpu_run KVM: VMX: Enable bus lock VM exit KVM: X86: Add the Document for KVM_CAP_X86_BUS_LOCK_EXIT Sean Christopherson (1): KVM: VMX: Convert vcpu_vmx.exit_reason to a union Documentation/virt/kvm/api.rst | 45 - arch/x86/include/asm/kvm_host.h| 7 ++ arch/x86/include/asm/vmx.h | 1 + arch/x86/include/asm/vmxfeatures.h | 1 + arch/x86/include/uapi/asm/kvm.h| 1 + arch/x86/include/uapi/asm/vmx.h| 4 +- arch/x86/kvm/vmx/capabilities.h| 6 ++ arch/x86/kvm/vmx/nested.c | 42 +++- arch/x86/kvm/vmx/vmx.c | 105 +++-- arch/x86/kvm/vmx/vmx.h | 25 ++- arch/x86/kvm/x86.c | 28 +++- include/uapi/linux/kvm.h | 5 ++ 12 files changed, 214 insertions(+), 56 deletions(-) -- 2.17.1
Re: [PATCH] fs: process fput task_work with TWA_SIGNAL
On Fri, Jan 08, 2021 at 07:21:52AM +0100, Sedat Dilek wrote: > On Fri, Jan 8, 2021 at 6:30 AM Al Viro wrote: > > > > On Tue, Jan 05, 2021 at 11:29:11AM -0700, Jens Axboe wrote: > > > Song reported a boot regression in a kvm image with 5.11-rc, and bisected > > > it down to the below patch. Debugging this issue, turns out that the boot > > > stalled when a task is waiting on a pipe being released. As we no longer > > > run task_work from get_signal() unless it's queued with TWA_SIGNAL, the > > > task goes idle without running the task_work. This prevents ->release() > > > from being called on the pipe, which another boot task is waiting on. > > > > > > Use TWA_SIGNAL for the file fput work to ensure it's run before the task > > > goes idle. > > > > > > Fixes: 98b89b649fce ("signal: kill JOBCTL_TASK_WORK") > > > Reported-by: Song Liu > > > Signed-off-by: Jens Axboe > > > > > > --- > > > > > > The other alternative here is obviously to re-instate the: > > > > > > if (unlikely(current->task_works)) > > > task_work_run(); > > > > > > in get_signal() that we had before this change. Might be safer in case > > > there are other cases that need to ensure the work is run in a timely > > > fashion, though I do think it's cleaner to long term to correctly mark > > > task_work with the needed notification type. Comments welcome... > > > > Interesting... I think I've missed the discussion of that thing; could > > you forward the relevant thread my way or give an archive link to it? > > See [1]. > > - Sedat - > > [1] https://marc.info/?t=16098715661&r=1&w=2 Wait, that's this very thread, starting with the posting I'd been replying to. Really confused now... Was that a private bug report and an equally private discussion? That's what I wanted to see... Anyway, I'm more than half-asleep right now; will get back to that in the morning.
[RESEND v5 0/4] Add bus lock VM exit support
Hi all, Resend a rebased version. Hope to receive your comments. --- This patch series add the support for bus lock VM exit in KVM. It is a sub-feature of bus lock detection. When it is enabled by the VMM, the processor generates a "Bus Lock" VM exit following execution of an instruction if the processor detects that one or more bus locks were caused the instruction was being executed (due to either direct access by the instruction or stuffed accesses like through A/D updates). Bus lock VM exit will introduce a new modifier bit (bit 26) in exit_reason field in VMCS which indicates bus lock VM exit is preempted by a higher priority VM exit. The first patch is to apply Sean's refactor for vcpu_vmx.exit_reason as a preparation patch for bus lock VM exit support. The second patch is the refactor for vcpu->run->flags. Bus lock VM exit will introduce a new field in the flags to inform the userspace that there's a bus lock detected in guest. It's also a preparation patch. The third patch is the concrete enabling working for bus lock VM exit. Add the support to set the capability to enable bus lock VM exit. The current implementation is just exiting to userspace when handling the bus lock detected in guest. The detail of throttling policy in user space is still to be discussed. We may enforce ratelimit on bus lock in guest, inject some sleep time, or... We hope to get more ideas on this. Document for Bus Lock Detection is now available at the latest "Intel Architecture Instruction Set Extensions Programming Reference". Document Link: https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html --- Changelogs v5->v5: - rebase on top of v5.11-rc1 - no difference compared with the last version - v5:https://lore.kernel.org/lkml/20201106090315.18606-1-chenyi.qi...@intel.com/ v4->v5: - rebase on top on v5.10-rc2 - add preparation patch that reset the vcpu->run->flags at the beginning of the vcpu_run.(Suggested by Sean) - set the KVM_RUN_BUS_LOCK for all bus lock exit to avoid checking both exit_reason and run->flags - add the document to introduce the new kvm capability (KVM_CAP_X86_BUS_LOCK_EXIT) - v4:https://lore.kernel.org/lkml/20201012033542.4696-1-chenyi.qi...@intel.com/ v3->v4: - rebase on top of v5.9 - some code cleanup. - v3:https://lore.kernel.org/lkml/20200910083751.26686-1-chenyi.qi...@intel.com/ v2->v3: - use a bitmap to get/set the capability of bus lock detection. we support exit and off mode currently. - put the handle of exiting to userspace in vmx.c, thus no need to define a shadow to track vmx->exit_reason.bus_lock_detected. - remove the vcpu->stats.bus_locks since every bus lock exits to userspace. - v2:https://lore.kernel.org/lkml/20200817033604.5836-1-chenyi.qi...@intel.com/ v1->v2: - resolve Vitaly's comment to introduce the KVM_EXIT_BUS_LOCK and a capability to enable it. - add the support to exit to user space when handling bus locks. - extend the vcpu->run->flags to indicate bus lock detected for other exit reasons when exiting to user space. - v1:https://lore.kernel.org/lkml/20200628085341.5107-1-chenyi.qi...@intel.com/ --- Chenyi Qiang (3): KVM: X86: Reset the vcpu->run->flags at the beginning of vcpu_run KVM: VMX: Enable bus lock VM exit KVM: X86: Add the Document for KVM_CAP_X86_BUS_LOCK_EXIT Sean Christopherson (1): KVM: VMX: Convert vcpu_vmx.exit_reason to a union Documentation/virt/kvm/api.rst | 45 - arch/x86/include/asm/kvm_host.h| 7 ++ arch/x86/include/asm/vmx.h | 1 + arch/x86/include/asm/vmxfeatures.h | 1 + arch/x86/include/uapi/asm/kvm.h| 1 + arch/x86/include/uapi/asm/vmx.h| 4 +- arch/x86/kvm/vmx/capabilities.h| 6 ++ arch/x86/kvm/vmx/nested.c | 42 +++- arch/x86/kvm/vmx/vmx.c | 105 +++-- arch/x86/kvm/vmx/vmx.h | 25 ++- arch/x86/kvm/x86.c | 28 +++- include/uapi/linux/kvm.h | 5 ++ 12 files changed, 214 insertions(+), 56 deletions(-) -- 2.17.1
Re: [PATCH] fs: process fput task_work with TWA_SIGNAL
On Fri, Jan 08, 2021 at 07:21:52AM +0100, Sedat Dilek wrote: > On Fri, Jan 8, 2021 at 6:30 AM Al Viro wrote: > > > > On Tue, Jan 05, 2021 at 11:29:11AM -0700, Jens Axboe wrote: > > > Song reported a boot regression in a kvm image with 5.11-rc, and bisected > > > it down to the below patch. Debugging this issue, turns out that the boot > > > stalled when a task is waiting on a pipe being released. As we no longer > > > run task_work from get_signal() unless it's queued with TWA_SIGNAL, the > > > task goes idle without running the task_work. This prevents ->release() > > > from being called on the pipe, which another boot task is waiting on. > > > > > > Use TWA_SIGNAL for the file fput work to ensure it's run before the task > > > goes idle. > > > > > > Fixes: 98b89b649fce ("signal: kill JOBCTL_TASK_WORK") > > > Reported-by: Song Liu > > > Signed-off-by: Jens Axboe > > > > > > --- > > > > > > The other alternative here is obviously to re-instate the: > > > > > > if (unlikely(current->task_works)) > > > task_work_run(); > > > > > > in get_signal() that we had before this change. Might be safer in case > > > there are other cases that need to ensure the work is run in a timely > > > fashion, though I do think it's cleaner to long term to correctly mark > > > task_work with the needed notification type. Comments welcome... > > > > Interesting... I think I've missed the discussion of that thing; could > > you forward the relevant thread my way or give an archive link to it? > > See [1]. > > - Sedat - > > [1] https://marc.info/?t=16098715661&r=1&w=2 Thanks; will check tomorrow.
drivers/block/rnbd/rnbd-clt.c:387:2: error: implicit declaration of function 'sg_free_table_chained'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f5e6c330254ae691f6d7befe61c786eb5056007e commit: 5a1328d0c3a757cdd8c65f4dfe0a02502a5810bc block/rnbd-clt: Dynamically allocate sglist for rnbd_iu date: 3 weeks ago config: parisc-randconfig-r011-20210108 (attached as .config) compiler: hppa-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5a1328d0c3a757cdd8c65f4dfe0a02502a5810bc git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 5a1328d0c3a757cdd8c65f4dfe0a02502a5810bc # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=parisc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): drivers/block/rnbd/rnbd-clt.c: In function 'rnbd_softirq_done_fn': >> drivers/block/rnbd/rnbd-clt.c:387:2: error: implicit declaration of function >> 'sg_free_table_chained' [-Werror=implicit-function-declaration] 387 | sg_free_table_chained(&iu->sgt, RNBD_INLINE_SG_CNT); | ^ drivers/block/rnbd/rnbd-clt.c: In function 'rnbd_queue_rq': >> drivers/block/rnbd/rnbd-clt.c:1142:8: error: implicit declaration of >> function 'sg_alloc_table_chained'; did you mean 'sg_alloc_table'? >> [-Werror=implicit-function-declaration] 1142 | err = sg_alloc_table_chained(&iu->sgt, |^~ |sg_alloc_table cc1: some warnings being treated as errors vim +/sg_free_table_chained +387 drivers/block/rnbd/rnbd-clt.c 379 380 static void rnbd_softirq_done_fn(struct request *rq) 381 { 382 struct rnbd_clt_dev *dev= rq->rq_disk->private_data; 383 struct rnbd_clt_session *sess = dev->sess; 384 struct rnbd_iu *iu; 385 386 iu = blk_mq_rq_to_pdu(rq); > 387 sg_free_table_chained(&iu->sgt, RNBD_INLINE_SG_CNT); 388 rnbd_put_permit(sess, iu->permit); 389 blk_mq_end_request(rq, errno_to_blk_status(iu->errno)); 390 } 391 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH] fs: process fput task_work with TWA_SIGNAL
On Fri, Jan 08, 2021 at 05:26:51AM +, Al Viro wrote: > On Tue, Jan 05, 2021 at 11:29:11AM -0700, Jens Axboe wrote: > > Song reported a boot regression in a kvm image with 5.11-rc, and bisected > > it down to the below patch. Debugging this issue, turns out that the boot > > stalled when a task is waiting on a pipe being released. As we no longer > > run task_work from get_signal() unless it's queued with TWA_SIGNAL, the > > task goes idle without running the task_work. This prevents ->release() > > from being called on the pipe, which another boot task is waiting on. > > > > Use TWA_SIGNAL for the file fput work to ensure it's run before the task > > goes idle. > > > > Fixes: 98b89b649fce ("signal: kill JOBCTL_TASK_WORK") > > Reported-by: Song Liu > > Signed-off-by: Jens Axboe > > > > --- > > > > The other alternative here is obviously to re-instate the: > > > > if (unlikely(current->task_works)) > > task_work_run(); > > > > in get_signal() that we had before this change. Might be safer in case > > there are other cases that need to ensure the work is run in a timely > > fashion, though I do think it's cleaner to long term to correctly mark > > task_work with the needed notification type. Comments welcome... > > Interesting... I think I've missed the discussion of that thing; could > you forward the relevant thread my way or give an archive link to it? Actually, why do we need TWA_RESUME at all? OK, a while ago you've added a way for task_work_add() to do wake_up_signal(). Fine, so if the sucker had been asleep in get_signal(), it gets woken up and the work gets run fast. Irrelevant for those who did task_work_add() for themselves. With that commit, though, you've suddenly changed the default behaviour - now if you do that task_work_add() for current *and* get asleep in get_signal(), task_work_add() gets delayed - potentially for a very long time. Now the default (TWA_RESUME) has changed semantics; matter of fact, TWA_SIGNAL seems to be a lot closer than what we used to have. I'm too sleepy right now to check if there are valid usecases for your new TWA_RESUME behaviour, but I very much doubt that old callers (before the TWA_RESUME/TWA_SIGNAL split) want that. In particular, for mntput_no_expire() we definitely do *not* want that, same as with fput(). Same, AFAICS, for YAMA report_access(). And for binder_deferred_fd_close(). And task_tick_numa() looks that way as well... Anyway, bedtime for me; right now it looks like at least for task == current we always want TWA_SIGNAL. I'll look into that more tomorrow when I get up, but so far it smells like switching everything to TWA_SIGNAL would be the right thing to do, if not going back to bool notify for task_work_add()...
[RESEND PATCH 2/2] KVM: X86: Expose bus lock debug exception to guest
Bus lock debug exception is an ability to notify the kernel by an #DB trap after the instruction acquires a bus lock and is executed when CPL>0. This allows the kernel to enforce user application throttling or mitigations. Existence of bus lock debug exception is enumerated via CPUID.(EAX=7,ECX=0).ECX[24]. Software can enable these exceptions by setting bit 2 of the MSR_IA32_DEBUGCTL. Expose the CPUID to guest and emulate the MSR handling when guest enables it. Since SVM already has specific handlers of MSR_IA32_DEBUGMSR in the svm_get/set_msr, move x86 commmon part to VMX and add the bus lock debug exception support. Co-developed-by: Xiaoyao Li Signed-off-by: Xiaoyao Li Signed-off-by: Chenyi Qiang --- arch/x86/kvm/cpuid.c | 3 ++- arch/x86/kvm/vmx/vmx.c | 23 +-- arch/x86/kvm/x86.c | 16 ++-- arch/x86/kvm/x86.h | 2 ++ 4 files changed, 27 insertions(+), 17 deletions(-) diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 13036cf0b912..ea7c593794d2 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -402,7 +402,8 @@ void kvm_set_cpu_caps(void) F(AVX512VBMI) | F(LA57) | F(PKU) | 0 /*OSPKE*/ | F(RDPID) | F(AVX512_VPOPCNTDQ) | F(UMIP) | F(AVX512_VBMI2) | F(GFNI) | F(VAES) | F(VPCLMULQDQ) | F(AVX512_VNNI) | F(AVX512_BITALG) | - F(CLDEMOTE) | F(MOVDIRI) | F(MOVDIR64B) | 0 /*WAITPKG*/ + F(CLDEMOTE) | F(MOVDIRI) | F(MOVDIR64B) | 0 /*WAITPKG*/ | + F(BUS_LOCK_DETECT) ); /* Set LA57 based on hardware capability. */ if (cpuid_ecx(7) & F(LA57)) diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 13c9bcc4d9d9..39f28f90bbb4 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -147,6 +147,9 @@ module_param(allow_smaller_maxphyaddr, bool, S_IRUGO); RTIT_STATUS_ERROR | RTIT_STATUS_STOPPED | \ RTIT_STATUS_BYTECNT)) +#define MSR_VMX_SUPPORTED_DEBUGCTL (DEBUGCTLMSR_LBR | \ + DEBUGCTLMSR_BTF | DEBUGCTLMSR_BUS_LOCK_DETECT) + /* * List of MSRs that can be directly passed to the guest. * In addition to these x2apic and PT MSRs are handled specially. @@ -1924,6 +1927,9 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) !guest_cpuid_has(vcpu, X86_FEATURE_RDTSCP)) return 1; goto find_uret_msr; + case MSR_IA32_DEBUGCTLMSR: + msr_info->data = vmcs_read64(GUEST_IA32_DEBUGCTL); + break; default: find_uret_msr: msr = vmx_find_uret_msr(vmx, msr_info->index); @@ -2002,9 +2008,22 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) VM_EXIT_SAVE_DEBUG_CONTROLS) get_vmcs12(vcpu)->guest_ia32_debugctl = data; - ret = kvm_set_msr_common(vcpu, msr_info); - break; + if (data & ~MSR_VMX_SUPPORTED_DEBUGCTL) + return 1; + if (!msr_info->host_initiated && + (data & DEBUGCTLMSR_BUS_LOCK_DETECT) && + !guest_cpuid_has(vcpu, X86_FEATURE_BUS_LOCK_DETECT)) + return 1; + + if (data & (DEBUGCTLMSR_BTF|DEBUGCTLMSR_LBR)) { + if (report_ignored_msrs) + vcpu_unimpl(vcpu, "%s: BTF|LBR in IA32_DEBUGCTLMSR 0x%llx, nop\n", + __func__, data); + data &= ~(DEBUGCTLMSR_BTF|DEBUGCTLMSR_LBR); + } + vmcs_write64(GUEST_IA32_DEBUGCTL, data); + return 0; case MSR_IA32_BNDCFGS: if (!kvm_mpx_supported() || (!msr_info->host_initiated && diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 06de2b9e57f3..d4a601482794 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -116,8 +116,9 @@ EXPORT_SYMBOL_GPL(kvm_x86_ops); static bool __read_mostly ignore_msrs = 0; module_param(ignore_msrs, bool, S_IRUGO | S_IWUSR); -static bool __read_mostly report_ignored_msrs = true; +bool __read_mostly report_ignored_msrs = true; module_param(report_ignored_msrs, bool, S_IRUGO | S_IWUSR); +EXPORT_SYMBOL_GPL(report_ignored_msrs); unsigned int min_timer_period_us = 200; module_param(min_timer_period_us, uint, S_IRUGO | S_IWUSR); @@ -3067,18 +3068,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info) return 1; } break; - case MSR_IA32_DEBUGCTLMSR: - if (!data) { - /* We support the non-activated case already */ - break; - } else if (data & ~(DEBUGCTLMSR_LBR | DEBUGCTLMSR_BTF)) { - /* Values other than LBR and BTF are vendor-specific, - thus res
[RESEND PATCH 1/2] KVM: X86: Add support for the emulation of DR6_BUS_LOCK bit
To avoid breaking the CPUs without bus lock detection, activate the DR6_BUS_LOCK bit (bit 11) conditionally in DR6_FIXED_1 bits. The set/clear of DR6_BUS_LOCK is similar to the DR6_RTM in DR6 register. The processor clears DR6_BUS_LOCK when bus lock debug exception is generated. (For all other #DB the processor sets this bit to 1.) Software #DB handler should set this bit before returning to the interrupted task. For VM exit caused by debug exception, bit 11 of the exit qualification is set to indicate that a bus lock debug exception condition was detected. The VMM should emulate the exception by clearing bit 11 of the guest DR6. Co-developed-by: Xiaoyao Li Signed-off-by: Xiaoyao Li Signed-off-by: Chenyi Qiang --- arch/x86/include/asm/kvm_host.h | 5 +++-- arch/x86/kvm/emulate.c | 2 +- arch/x86/kvm/svm/svm.c | 6 +++--- arch/x86/kvm/vmx/nested.c | 2 +- arch/x86/kvm/vmx/vmx.c | 6 -- arch/x86/kvm/x86.c | 28 +--- 6 files changed, 29 insertions(+), 20 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 3ab7b46087b7..826fd1e87352 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -196,13 +196,14 @@ enum x86_intercept_stage; #define KVM_NR_DB_REGS 4 +#define DR6_BUS_LOCK (1 << 11) #define DR6_BD (1 << 13) #define DR6_BS (1 << 14) #define DR6_BT (1 << 15) #define DR6_RTM(1 << 16) -#define DR6_FIXED_10xfffe0ff0 +#define DR6_FIXED_10xfffe07f0 #define DR6_INIT 0x0ff0 -#define DR6_VOLATILE 0x0001e00f +#define DR6_VOLATILE 0x0001e80f #define DR7_BP_EN_MASK 0x00ff #define DR7_GE (1 << 9) diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c index 56cae1ff9e3f..882598da20f0 100644 --- a/arch/x86/kvm/emulate.c +++ b/arch/x86/kvm/emulate.c @@ -4327,7 +4327,7 @@ static int check_dr_read(struct x86_emulate_ctxt *ctxt) ctxt->ops->get_dr(ctxt, 6, &dr6); dr6 &= ~DR_TRAP_BITS; - dr6 |= DR6_BD | DR6_RTM; + dr6 |= DR6_BD | DR6_RTM | DR6_BUS_LOCK; ctxt->ops->set_dr(ctxt, 6, dr6); return emulate_db(ctxt); } diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index cce0143a6f80..3d8a0e30314f 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -1860,7 +1860,7 @@ static void svm_sync_dirty_debug_regs(struct kvm_vcpu *vcpu) get_debugreg(vcpu->arch.db[2], 2); get_debugreg(vcpu->arch.db[3], 3); /* -* We cannot reset svm->vmcb->save.dr6 to DR6_FIXED_1|DR6_RTM here, +* We cannot reset svm->vmcb->save.dr6 to DR6_FIXED_1|DR6_RTM|DR6_BUS_LOCK here, * because db_interception might need it. We can do it before vmentry. */ vcpu->arch.dr6 = svm->vmcb->save.dr6; @@ -1911,7 +1911,7 @@ static int db_interception(struct vcpu_svm *svm) if (!(svm->vcpu.guest_debug & (KVM_GUESTDBG_SINGLESTEP | KVM_GUESTDBG_USE_HW_BP)) && !svm->nmi_singlestep) { - u32 payload = (svm->vmcb->save.dr6 ^ DR6_RTM) & ~DR6_FIXED_1; + u32 payload = (svm->vmcb->save.dr6 ^ (DR6_RTM|DR6_BUS_LOCK)) & ~DR6_FIXED_1; kvm_queue_exception_p(&svm->vcpu, DB_VECTOR, payload); return 1; } @@ -3778,7 +3778,7 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu) if (unlikely(svm->vcpu.arch.switch_db_regs & KVM_DEBUGREG_WONT_EXIT)) svm_set_dr6(svm, vcpu->arch.dr6); else - svm_set_dr6(svm, DR6_FIXED_1 | DR6_RTM); + svm_set_dr6(svm, DR6_FIXED_1 | DR6_RTM | DR6_BUS_LOCK); clgi(); kvm_load_guest_xsave_state(vcpu); diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index e2f26564a12d..c5d71a9b3729 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -412,7 +412,7 @@ static int nested_vmx_check_exception(struct kvm_vcpu *vcpu, unsigned long *exit if (!has_payload) { payload = vcpu->arch.dr6; payload &= ~(DR6_FIXED_1 | DR6_BT); - payload ^= DR6_RTM; + payload ^= DR6_RTM | DR6_BUS_LOCK; } *exit_qual = payload; } else diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 75c9c6a0a3a4..13c9bcc4d9d9 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -4824,7 +4824,8 @@ static int handle_exception_nmi(struct kvm_vcpu *vcpu) kvm_queue_exception_p(vcpu, DB_VECTOR, dr6); return 1; } - kvm_run->debug.arch.dr6 = dr6 | DR6_FIXED_1 | DR6_RTM; + kvm_run->debug.arch.dr6 = dr6 | DR6_FIXED_1 | DR6_RTM
[RESEND PATCH 0/2] Add KVM support for bus lock debug exception
Hi all, Any comment on this rebased version? I'd appreciate it if anyone has time to review this short series. --- A bus lock is acquired either through split locked access to writeback (WB) memory or by using locks to uncacheable (UC) memory. This is typically > 1000 cycles slower than atomic opertaion within a cache line. It also disrupts performance on other cores. Bus lock debug exception is a sub-feature of bus lock detection. It is an ability to notify the kernel by an #DB trap after the instruction acquires a bus lock when CPL>0. This allows the kernel to enforce user application throttling or mitigatioins. Expose the bus lock debug exception to guest by the enumeration of CPUID.(EAX=7,ECX=0).ECX[24]. Software in guest can enable these exceptions by setting the DEBUGCTLMSR_BUS_LOCK_DETECT(bit 2) of MSR_IA32_DEBUTCTL. The bus lock #DB exception can also be intercepted by the VMM and identified through the bit 11 of the exit qualification at VM exit. The bit 11 (DR6_BUS_LOCK) of DR6 register is introduced to indicate a bus lock #DB exception. DR6_BUS_LOCK has formerly always been 1 and delivery of a bus lock #DB clears it. The VMM should emulate the exceptions by clearing the bit 11 of the guest DR6. The kernel support patches for bus lock debug exception is available at https://lore.kernel.org/lkml/20201124205245.4164633-1-fenghua...@intel.com/ Document for Bus Lock Detection is now available at the latest "Intel Architecture Instruction Set Extensions Programming Reference". Document Link: https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html --- Changelogs RFC->v1: - rebase on top of v5.11-rc1, no difference compared with the last version - v1:https://lore.kernel.org/lkml/20201119092957.16940-1-chenyi.qi...@intel.com/ Chenyi Qiang (2): KVM: X86: Add support for the emulation of DR6_BUS_LOCK bit KVM: X86: Expose bus lock debug exception to guest arch/x86/include/asm/kvm_host.h | 5 ++-- arch/x86/kvm/cpuid.c| 3 ++- arch/x86/kvm/emulate.c | 2 +- arch/x86/kvm/svm/svm.c | 6 ++--- arch/x86/kvm/vmx/nested.c | 2 +- arch/x86/kvm/vmx/vmx.c | 29 +++--- arch/x86/kvm/x86.c | 44 ++--- arch/x86/kvm/x86.h | 2 ++ 8 files changed, 56 insertions(+), 37 deletions(-) -- 2.17.1
Re: [PATCH 2/2] watchdog: BD70528: conditionally allow BD70528 module
On Thu, Jan 7, 2021 at 5:12 PM Guenter Roeck wrote: > > On Thu, Jan 07, 2021 at 08:37:25AM +0200, Matti Vaittinen wrote: > > The BD70528 watchdog module provides start/stop interface for RTC > > driver because the BD70528 watchdog must be stopped when RTC time > > is set. (WDG uses RTC counter and setting RTC may accidentally trigger > > WDG if WDG is enabled). The BD71828 use same RTC driver as BD70528 but > > don't share same WDG logic. When BD70528 is not configured a stub call > > to "stop WDG" is implemented and in case when BD71828 is used, this > > stub function should be called. Prevent configuring in the BD70528 > > watchdog when BD71828 is configured to avoid access to real WDG > > functions when WDG does not exist in HW. > > > > Signed-off-by: Matti Vaittinen > > As mentioned in my response to the other patch, I think this is the > wrong solution. I agree. Please forget this :) Thanks for the review! Best Regards Matti -- ~~ -Matti Vaittinen When you feel blue, no one sees your tears... When your down, no one understands your struggle... When you feel happy, no one notices your smile... But fart just once... ~~
Re: [PATCH v5] usb: xhci-mtk: fix unreleased bandwidth data
On Tue, 2020-12-29 at 14:24 +0800, Ikjoon Jang wrote: > xhci-mtk has hooks on add_endpoint() and drop_endpoint() from xhci > to handle its own sw bandwidth managements and stores bandwidth data > into internal table every time add_endpoint() is called, > so when bandwidth allocation fails at one endpoint, all earlier > allocation from the same interface could still remain at the table. If failed to add an endpoint, will cause failure of its interface config, then the other endpoints in the same interface will be dropped later? you mean some endpoints in an interface may fail but without affecting its function? > > This patch adds two more hooks from check_bandwidth() and > reset_bandwidth(), and make mtk-xhci to releases all failed endpoints > from reset_bandwidth(). > > Fixes: 08e469de87a2 ("usb: xhci-mtk: supports bandwidth scheduling with > multi-TT") > Signed-off-by: Ikjoon Jang
Re: [PATCH] fs: process fput task_work with TWA_SIGNAL
On Fri, Jan 8, 2021 at 6:30 AM Al Viro wrote: > > On Tue, Jan 05, 2021 at 11:29:11AM -0700, Jens Axboe wrote: > > Song reported a boot regression in a kvm image with 5.11-rc, and bisected > > it down to the below patch. Debugging this issue, turns out that the boot > > stalled when a task is waiting on a pipe being released. As we no longer > > run task_work from get_signal() unless it's queued with TWA_SIGNAL, the > > task goes idle without running the task_work. This prevents ->release() > > from being called on the pipe, which another boot task is waiting on. > > > > Use TWA_SIGNAL for the file fput work to ensure it's run before the task > > goes idle. > > > > Fixes: 98b89b649fce ("signal: kill JOBCTL_TASK_WORK") > > Reported-by: Song Liu > > Signed-off-by: Jens Axboe > > > > --- > > > > The other alternative here is obviously to re-instate the: > > > > if (unlikely(current->task_works)) > > task_work_run(); > > > > in get_signal() that we had before this change. Might be safer in case > > there are other cases that need to ensure the work is run in a timely > > fashion, though I do think it's cleaner to long term to correctly mark > > task_work with the needed notification type. Comments welcome... > > Interesting... I think I've missed the discussion of that thing; could > you forward the relevant thread my way or give an archive link to it? See [1]. - Sedat - [1] https://marc.info/?t=16098715661&r=1&w=2
Re: [PATCH] fs: process fput task_work with TWA_SIGNAL
On Fri, Jan 8, 2021 at 4:56 AM Jens Axboe wrote: > > On 1/7/21 3:17 PM, Doug Anderson wrote: > > Hi, > > > > On Tue, Jan 5, 2021 at 10:30 AM Jens Axboe wrote: > >> > >> Song reported a boot regression in a kvm image with 5.11-rc, and bisected > >> it down to the below patch. Debugging this issue, turns out that the boot > >> stalled when a task is waiting on a pipe being released. As we no longer > >> run task_work from get_signal() unless it's queued with TWA_SIGNAL, the > >> task goes idle without running the task_work. This prevents ->release() > >> from being called on the pipe, which another boot task is waiting on. > >> > >> Use TWA_SIGNAL for the file fput work to ensure it's run before the task > >> goes idle. > >> > >> Fixes: 98b89b649fce ("signal: kill JOBCTL_TASK_WORK") > >> Reported-by: Song Liu > >> Signed-off-by: Jens Axboe > > > > I just spend a bit of time bisecting and landed on commit 98b89b649fce > > ("signal: kill JOBCTL_TASK_WORK") causing my failure to bootup > > mainline. Your patch fixes my problem. I haven't done any analysis > > of the code--just testing, thus: > > > > Tested-by: Douglas Anderson > > Thanks, adding your Tested-by. > I have this in my patch-series since it appeared in [1]. Feel free to add my: Tested-by: Sedat Dilek # LLVM/Clang version 11.0.1 - Sedat - [1] https://git.kernel.dk/cgit/linux-block/log/?h=task_work - Sedat -
RE: [PATCH] hwmon: (amd_energy) fix allocation of hwmon_channel_info config
[AMD Official Use Only - Approved for External Use] Hi Guenter, >> No, because you are not in the approval path (you did not send the patch to >> me). Reviewed-by: or Acked-by: would be more appropriate. Got it, my mistake, please use Acked-by: Naveen Krishna Chatradhi Regards, Naveenk -Original Message- From: Guenter Roeck On Behalf Of Guenter Roeck Sent: Friday, January 8, 2021 11:47 AM To: Chatradhi, Naveen Krishna ; David Arcari ; linux-hw...@vger.kernel.org Cc: Jean Delvare ; linux-kernel@vger.kernel.org; sta...@vger.kernel.org Subject: Re: [PATCH] hwmon: (amd_energy) fix allocation of hwmon_channel_info config [CAUTION: External Email] On 1/7/21 9:49 PM, Chatradhi, Naveen Krishna wrote: > [AMD Official Use Only - Approved for External Use] > > Hi David, > > Thank you for noticing and submitting a fix. You may use > Signed-off-by: Naveen Krishna Chatradhi > No, because you are not in the approval path (you did not send the patch to me). Reviewed-by: or Acked-by: would be more appropriate. Genter > Regards, > Naveenk > > -Original Message- > From: David Arcari > Sent: Thursday, January 7, 2021 8:17 PM > To: linux-hw...@vger.kernel.org > Cc: David Arcari ; Chatradhi, Naveen Krishna > ; Jean Delvare ; > Guenter Roeck ; linux-kernel@vger.kernel.org; > sta...@vger.kernel.org > Subject: [PATCH] hwmon: (amd_energy) fix allocation of > hwmon_channel_info config > > [CAUTION: External Email] > > hwmon, specifically hwmon_num_channel_attrs, expects the config array in the > hwmon_channel_info structure to be terminated by a zero entry. amd_energy > does not honor this convention. As result, a KASAN warning is possible. Fix > this by adding an additional entry and setting it to zero. > > Fixes: 8abee9566b7e ("hwmon: Add amd_energy driver to report energy > counters") > > Signed-off-by: David Arcari > Cc: Naveen Krishna Chatradhi [naveenk:] > Signed-off-by: Naveen Krishna Chatradhi > Cc: Jean Delvare > Cc: Guenter Roeck > Cc: linux-kernel@vger.kernel.org > Cc: sta...@vger.kernel.org > --- > drivers/hwmon/amd_energy.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/hwmon/amd_energy.c b/drivers/hwmon/amd_energy.c > index 9b306448b7a0..822c2e74b98d 100644 > --- a/drivers/hwmon/amd_energy.c > +++ b/drivers/hwmon/amd_energy.c > @@ -222,7 +222,7 @@ static int amd_create_sensor(struct device *dev, > */ > cpus = num_present_cpus() / num_siblings; > > - s_config = devm_kcalloc(dev, cpus + sockets, > + s_config = devm_kcalloc(dev, cpus + sockets + 1, > sizeof(u32), GFP_KERNEL); > if (!s_config) > return -ENOMEM; > @@ -254,6 +254,7 @@ static int amd_create_sensor(struct device *dev, > scnprintf(label_l[i], 10, "Esocket%u", (i - cpus)); > } > > + s_config[i] = 0; > return 0; > } > > -- > 2.18.1 >
Re: [PATCH] hwmon: (amd_energy) fix allocation of hwmon_channel_info config
On 1/7/21 9:49 PM, Chatradhi, Naveen Krishna wrote: > [AMD Official Use Only - Approved for External Use] > > Hi David, > > Thank you for noticing and submitting a fix. You may use > Signed-off-by: Naveen Krishna Chatradhi > No, because you are not in the approval path (you did not send the patch to me). Reviewed-by: or Acked-by: would be more appropriate. Genter > Regards, > Naveenk > > -Original Message- > From: David Arcari > Sent: Thursday, January 7, 2021 8:17 PM > To: linux-hw...@vger.kernel.org > Cc: David Arcari ; Chatradhi, Naveen Krishna > ; Jean Delvare ; Guenter > Roeck ; linux-kernel@vger.kernel.org; > sta...@vger.kernel.org > Subject: [PATCH] hwmon: (amd_energy) fix allocation of hwmon_channel_info > config > > [CAUTION: External Email] > > hwmon, specifically hwmon_num_channel_attrs, expects the config array in the > hwmon_channel_info structure to be terminated by a zero entry. amd_energy > does not honor this convention. As result, a KASAN warning is possible. Fix > this by adding an additional entry and setting it to zero. > > Fixes: 8abee9566b7e ("hwmon: Add amd_energy driver to report energy counters") > > Signed-off-by: David Arcari > Cc: Naveen Krishna Chatradhi > [naveenk:] Signed-off-by: Naveen Krishna Chatradhi > Cc: Jean Delvare > Cc: Guenter Roeck > Cc: linux-kernel@vger.kernel.org > Cc: sta...@vger.kernel.org > --- > drivers/hwmon/amd_energy.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/hwmon/amd_energy.c b/drivers/hwmon/amd_energy.c index > 9b306448b7a0..822c2e74b98d 100644 > --- a/drivers/hwmon/amd_energy.c > +++ b/drivers/hwmon/amd_energy.c > @@ -222,7 +222,7 @@ static int amd_create_sensor(struct device *dev, > */ > cpus = num_present_cpus() / num_siblings; > > - s_config = devm_kcalloc(dev, cpus + sockets, > + s_config = devm_kcalloc(dev, cpus + sockets + 1, > sizeof(u32), GFP_KERNEL); > if (!s_config) > return -ENOMEM; > @@ -254,6 +254,7 @@ static int amd_create_sensor(struct device *dev, > scnprintf(label_l[i], 10, "Esocket%u", (i - cpus)); > } > > + s_config[i] = 0; > return 0; > } > > -- > 2.18.1 >
Re: [PATCH v5] usb: xhci-mtk: fix unreleased bandwidth data
On Thu, 2021-01-07 at 13:09 +0200, Mathias Nyman wrote: > On 29.12.2020 8.24, Ikjoon Jang wrote: > > xhci-mtk has hooks on add_endpoint() and drop_endpoint() from xhci > > to handle its own sw bandwidth managements and stores bandwidth data > > into internal table every time add_endpoint() is called, > > so when bandwidth allocation fails at one endpoint, all earlier > > allocation from the same interface could still remain at the table. > > > > This patch adds two more hooks from check_bandwidth() and > > reset_bandwidth(), and make mtk-xhci to releases all failed endpoints > > from reset_bandwidth(). > > > > Fixes: 08e469de87a2 ("usb: xhci-mtk: supports bandwidth scheduling with > > multi-TT") > > Signed-off-by: Ikjoon Jang > > > > ... > > > > > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > > index d4a8d0efbbc4..e1fcd3cf723f 100644 > > --- a/drivers/usb/host/xhci.c > > +++ b/drivers/usb/host/xhci.c > > @@ -2882,6 +2882,12 @@ static int xhci_check_bandwidth(struct usb_hcd *hcd, > > struct usb_device *udev) > > xhci_dbg(xhci, "%s called for udev %p\n", __func__, udev); > > virt_dev = xhci->devs[udev->slot_id]; > > > > + if (xhci->quirks & XHCI_MTK_HOST) { > > + ret = xhci_mtk_check_bandwidth(hcd, udev); > > + if (ret < 0) > > + return ret; > > + } > > + > > Just noticed that XHCI_MTK_HOST quirk is only set in xhci-mtk.c. > xhci-mtk.c calls xhci_init_driver(..., xhci_mtk_overrides) with a .reset > override function. > > why not add override functions for .check_bandwidth and .reset_bandwidth to > xhci_mtk_overrides instead? > > Another patch to add similar overrides for .add_endpoint and .drop_endpoint > should probably be > done so that we can get rid of the xhci_mtk_add/drop_ep_quirk() calls in > xhci.c as well You mean, we can export xhci_add/drop_endpoint()? > > Thanks > -Mathias >
Re: [PATCH 1/2] watchdog: bd70528: don't crash if WDG is confiured with BD71828
On Thu, 2021-01-07 at 20:15 +0200, Matti Vaittinen wrote: > Thanks a lot for taking a careful look at this Guenter! > > On Thu, 2021-01-07 at 07:12 -0800, Guenter Roeck wrote: > > On Thu, Jan 07, 2021 at 08:37:03AM +0200, Matti Vaittinen wrote: > > > If config for BD70528 watchdog is enabled when BD71828 or BD71815 > > > are used the RTC module will issue call to BD70528 watchdog with > > > NULL data. Ignore this call and don't crash. > > > > > > Signed-off-by: Matti Vaittinen > > > > > > > I really think this should be handled in the calling code. > > Also, I am curious how this is supposed to work. > > > > The code is called with > > > > ret = bd70528_wdt_set(r->parent, new_state & > > BD70528_WDT_STATE_BIT, > > old_state); > > My brainfart. > The bd70528_wdt_set is not called as it is protected in RTC by > has_rtc_timers flag. > > I inserted this check in wrong function. The bd70528_wdt_lock() > is where we may hit the problem as it is not protected. Actually, after a fresh look - it seems the bd70528_wdt_lock() is also just fine. The RTC is not grabbing the lock on other PMICs but the BD70528. I'm not really sure what I have been thinking of. @_@ I should've been more careful. Thanks for spotting this in the review! Best Regards Matti
Re: [PATCHv4 0/4] perf tools: Allow to enable/disable events via control pipe
Hi Jiri, On Thu, Jan 7, 2021 at 9:12 PM Jiri Olsa wrote: > > On Sun, Dec 27, 2020 at 12:20:34AM +0100, Jiri Olsa wrote: > > hi, > > adding support to enable/disable specific events via control > > file via following commands: > > > > # echo 'enable sched:sched_process_fork' > control > > # echo 'disabled sched:sched_process_fork' > control > > > > v4 changes: > > - some of the patches got merged > > - rebased to latest perf/core > > - fixed changelogs > > - added 'ping' command > > any reviews? Acked-by: Namhyung Kim Thanks, Namhyung
Re: [PATCH v4] ovl: fix dentry leak in ovl_get_redirect
ping On 20/12/22 上午11:06, Liangyan wrote: We need to lock d_parent->d_lock before dget_dlock, or this may have d_lockref updated parallelly like calltrace below which will cause dentry->d_lockref leak and risk a crash. CPU 0CPU 1 ovl_set_redirect lookup_fast ovl_get_redirect __d_lookup dget_dlock //no lock protection herespin_lock(&dentry->d_lock) dentry->d_lockref.count++dentry->d_lockref.count++ [ 49.799059] PGD 80061fed7067 P4D 80061fed7067 PUD 61fec5067 PMD 0 [ 49.799689] Oops: 0002 [#1] SMP PTI [ 49.800019] CPU: 2 PID: 2332 Comm: node Not tainted 4.19.24-7.20.al7.x86_64 #1 [ 49.800678] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8a46cfe 04/01/2014 [ 49.801380] RIP: 0010:_raw_spin_lock+0xc/0x20 [ 49.803470] RSP: 0018:ac6fc5417e98 EFLAGS: 00010246 [ 49.803949] RAX: RBX: 93b8da3446c0 RCX: 000a [ 49.804600] RDX: 0001 RSI: 000a RDI: 0088 [ 49.805252] RBP: R08: R09: 993cf040 [ 49.805898] R10: 93b92292e580 R11: d27f188a4b80 R12: [ 49.806548] R13: ff9c R14: fffe R15: 93b8da3446c0 [ 49.807200] FS: 7ffbedffb700() GS:93b92788() knlGS: [ 49.807935] CS: 0010 DS: ES: CR0: 80050033 [ 49.808461] CR2: 0088 CR3: 0005e3f74006 CR4: 003606a0 [ 49.809113] DR0: DR1: DR2: [ 49.809758] DR3: DR6: fffe0ff0 DR7: 0400 [ 49.810410] Call Trace: [ 49.810653] d_delete+0x2c/0xb0 [ 49.810951] vfs_rmdir+0xfd/0x120 [ 49.811264] do_rmdir+0x14f/0x1a0 [ 49.811573] do_syscall_64+0x5b/0x190 [ 49.811917] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 49.812385] RIP: 0033:0x7ffbf505ffd7 [ 49.814404] RSP: 002b:7ffbedffada8 EFLAGS: 0297 ORIG_RAX: 0054 [ 49.815098] RAX: ffda RBX: 7ffbedffb640 RCX: 7ffbf505ffd7 [ 49.815744] RDX: 04449700 RSI: RDI: 06c8cd50 [ 49.816394] RBP: 7ffbedffaea0 R08: R09: 00017d0b [ 49.817038] R10: R11: 0297 R12: 0012 [ 49.817687] R13: 072823d8 R14: 7ffbedffb700 R15: 072823d8 [ 49.818338] Modules linked in: pvpanic cirrusfb button qemu_fw_cfg atkbd libps2 i8042 [ 49.819052] CR2: 0088 [ 49.819368] ---[ end trace 4e652b8aa299aa2d ]--- [ 49.819796] RIP: 0010:_raw_spin_lock+0xc/0x20 [ 49.821880] RSP: 0018:ac6fc5417e98 EFLAGS: 00010246 [ 49.822363] RAX: RBX: 93b8da3446c0 RCX: 000a [ 49.823008] RDX: 0001 RSI: 000a RDI: 0088 [ 49.823658] RBP: R08: R09: 993cf040 [ 49.825404] R10: 93b92292e580 R11: d27f188a4b80 R12: [ 49.827147] R13: ff9c R14: fffe R15: 93b8da3446c0 [ 49.828890] FS: 7ffbedffb700() GS:93b92788() knlGS: [ 49.830725] CS: 0010 DS: ES: CR0: 80050033 [ 49.832359] CR2: 0088 CR3: 0005e3f74006 CR4: 003606a0 [ 49.834085] DR0: DR1: DR2: [ 49.835792] DR3: DR6: fffe0ff0 DR7: 0400 Cc: Fixes: a6c606551141 ("ovl: redirect on rename-dir") Signed-off-by: Liangyan Reviewed-by: Joseph Qi Suggested-by: Al Viro --- fs/overlayfs/dir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c index 28a075b5f5b2..d1efa3a5a503 100644 --- a/fs/overlayfs/dir.c +++ b/fs/overlayfs/dir.c @@ -992,8 +992,8 @@ static char *ovl_get_redirect(struct dentry *dentry, bool abs_redirect) buflen -= thislen; memcpy(&buf[buflen], name, thislen); - tmp = dget_dlock(d->d_parent); spin_unlock(&d->d_lock); + tmp = dget_parent(d); dput(d); d = tmp;
Re: [PATCH] arm64: dts: qcom: sdm845: Reserve LPASS clocks in gcc
On 21-12-20, 16:11, Bjorn Andersson wrote: > The GCC_LPASS_Q6_AXI_CLK and GCC_LPASS_SWAY_CLK clocks may not be > touched on a typical UEFI based SDM845 device, but when the kernel is > built with CONFIG_SDM_LPASSCC_845 this happens, unless they are marked > as protected-clocks in the DT. > > This was done for the MTP and the Pocophone, but not for DB845c and the > Lenovo Yoga C630 - causing these to fail to boot if the LPASS clock > controller is enabled (which it typically isn't). Reviewed-by: Vinod Koul Tested-by: Vinod Koul #on db845c -- ~Vinod
[PATCH v5] power: suspend: Move dpm_watchdog to suspend.c and enhance it
Since dpm_watchdog just cover two functions __device_suspend() and device_resume(), we proposed to move it to core power suspend.c to extend its coverage and monitor more devices suspend hand issues. We propose to use new name suspend watchdog and new timeout handler to cover more sleep hang issues. The new timeout handler will dump disk sleep task call trace at first round timeout and trigger kernel panic at second round timeout. The default timer for each round is defined in CONFIG_PM_SUSPEND_WATCHDOG_TIMEOUT. Signed-off-by: Joseph Jang --- Changes since v4: - Change #define PM_SUSPEND_WATCHDOG to CONFIG_PM_SUSPEND_WATCHDOG in suspend_watchdog.c to make sure we compile all suspend watchdog functions. - Add suspend watchdog functions declared in suspend_watchdog.h to prevent compile errors. Changes since v3: - Change the naming from sleep timer to suspend watchdog. - Remove console_is_suspended() from console.h and printk.c - Add static declaration for suspend_watchdog struct since we use it in suspend.c only. - Move suspend watchdog real logic to suspend_watchdog.c. - Put the function prototypes in suspend_watchdog.h - Use inline functions for function prototypes definition. Changes since v2: - Add kernel/power/suspend_timer.h in MAINTAINERS - Share some corner cases that dpm_watchdog cannot cover. Case#A: dpm_watchdog cannot cover suspend hang in suspend_enter(). File: kernel/power/suspend.c int suspend_devices_and_enter(suspend_state_t state) { ... suspend_test_start(); error = dpm_suspend_start(PMSG_SUSPEND); <== dpm_watchdog will be enabled/disabled in this fucntion ... if (error) { pr_err("Some devices failed to suspend, or early wake event detected\n"); goto Recover_platform; } suspend_test_finish("suspend devices"); if (suspend_test(TEST_DEVICES)) goto Recover_platform; do { error = suspend_enter(state, &wakeup); <== but we encounter hang inside function suspend_enter() ... } while (!error && !wakeup && platform_suspend_again(state)); Case#B: dpm_watchdog cannot cover resume hang in dpm_resume_early() because it enable/disable in device_resume(). Call trace: __switch_to+0x174/0x194 __schedule+0xa60/0x1464 __cancel_work_timer+0x120/0x234 chg_pm_resume+0x2c/0xd8 dpm_run_callback+0x27c/0x624 device_resume_early+0x1e4/0x1f8 dpm_resume_early+0x350/0x8f4 suspend_devices_and_enter+0xffc/0x168c pm_suspend+0xb54/0xdac File: drivers/base/power/main.c. static int device_resume(struct device *dev, pm_message_t state, bool async) if (!dpm_wait_for_superior(dev, async)) goto Complete; dpm_watchdog_set(&wd, dev); device_lock(dev); /* ... Unlock: device_unlock(dev); dpm_watchdog_clear(&wd); Case#C: dpm_watchdog cannot cover suspend hang in ksys_sync(). Call trace: __switch_to+0x1b0/0x1cc __schedule+0xac8/0x1314 io_schedule+0x94/0xc8 wait_on_page_bit+0x1f8/0x3a4 __filemap_fdatawait_range+0x134/0x150 sync_inodes_sb+0x368/0x584 sync_inodes_one_sb+0x18/0x24 iterate_supers+0x12c/0x2b8 ksys_sync+0x48/0x12c enter_state+0x294/0x7bc pm_suspend+0x164/0x2a8 - Explain some enhancement by following. Q1: Why not use the existing one? struct dpm_watchdog { struct device *dev; struct task_struct *tsk; struct timer_list timer; }; A1: In kernel/power/suspend.c, we don't have "struct device " because suspend.c is for core PM instead of device PM. So we propose to use sleep_timer struct. struct sleep_timer { struct task_struct*tsk; struct timer_list timer; }; Q2: Why not use stack memory for timer struct? static void dpm_watchdog_set(struct dpm_watchdog *wd, struct device *dev) { ... timer_setup_on_stack(timer, dpm_watchdog_handler, 0); <== dpm_watchdog use stack memory for timer struct. /* use same timeout value for both suspend and resume */ timer->expires = jiffies + HZ * CONFIG_DPM_WATCHDOG_TIMEOUT; add_timer(timer); } A2: dpm_watchdog use stack memory has limitation. It cannot support starting watchdog at end of function like s2idle_enter(). We cannot use stack memory for this case because the timer struct will be free when go back to caller. File: kernel/power/suspend.c static void s2idle_enter(void) { trace_suspend_resume(TPS("machine_suspend"), PM_SUSPEND_TO_IDLE, true); + stop_sleep_timer(&st); + raw_spin_lock_irq(&s2idle_lock); if (pm_wakeup_pending()) goto out; ... s2idle_state = S2IDLE_STATE_NONE; raw_spin_unlock_irq(&s2idle_lock); + start_sleep_timer(&st); + trace_suspend_resume(TPS("machine_suspend"), PM_SUSPEND_TO_IDLE, false);
Re: [PATCH 3/3] tools/lib/fs: Cache cgroupfs mount point
On Wed, Jan 6, 2021 at 10:33 AM Namhyung Kim wrote: > > Hi Arnaldo, > > On Tue, Dec 29, 2020 at 8:51 PM Arnaldo Carvalho de Melo > wrote: > > > > Em Wed, Dec 16, 2020 at 06:05:56PM +0900, Namhyung Kim escreveu: > > > Currently it parses the /proc file everytime it opens a file in the > > > cgroupfs. Save the last result to avoid it (assuming it won't be > > > changed between the accesses). > > > > Which is the most likely case, but can't we use something like inotify > > to detect that and bail out or warn the user? > > Hmm.. looks doable. Will check. So I've played with inotify a little bit, and it seems it needs to monitor changes on the file or the directory. I didn't get any notification from the /proc/mounts file even if I did some mount/umount. Instead, I could get IN_UNMOUNT when the cgroup filesystem was unmounted. But for the monitoring, we need to do one of a) select-like syscall to wait for the events, b) signal-driven IO notification or c) read the inotify file with non-block mode everytime. In a library code, I don't think we can do a) or b) since it can affect user program behaviors. Then we should go with c) but I think it's opposite to the purpose of this patch. :) As you said, I think mostly we don't care as the accesses will happen in a short period of time. But if you really care, maybe for the upcoming perf daemon changes, I think we can add an API to invalidate the cache or internal time-based invalidation logic (like remove it after 10 sec.). Thoughts? Thanks, Namhyung
RE: [PATCH] hwmon: (amd_energy) fix allocation of hwmon_channel_info config
[AMD Official Use Only - Approved for External Use] Hi David, Thank you for noticing and submitting a fix. You may use Signed-off-by: Naveen Krishna Chatradhi Regards, Naveenk -Original Message- From: David Arcari Sent: Thursday, January 7, 2021 8:17 PM To: linux-hw...@vger.kernel.org Cc: David Arcari ; Chatradhi, Naveen Krishna ; Jean Delvare ; Guenter Roeck ; linux-kernel@vger.kernel.org; sta...@vger.kernel.org Subject: [PATCH] hwmon: (amd_energy) fix allocation of hwmon_channel_info config [CAUTION: External Email] hwmon, specifically hwmon_num_channel_attrs, expects the config array in the hwmon_channel_info structure to be terminated by a zero entry. amd_energy does not honor this convention. As result, a KASAN warning is possible. Fix this by adding an additional entry and setting it to zero. Fixes: 8abee9566b7e ("hwmon: Add amd_energy driver to report energy counters") Signed-off-by: David Arcari Cc: Naveen Krishna Chatradhi [naveenk:] Signed-off-by: Naveen Krishna Chatradhi Cc: Jean Delvare Cc: Guenter Roeck Cc: linux-kernel@vger.kernel.org Cc: sta...@vger.kernel.org --- drivers/hwmon/amd_energy.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/hwmon/amd_energy.c b/drivers/hwmon/amd_energy.c index 9b306448b7a0..822c2e74b98d 100644 --- a/drivers/hwmon/amd_energy.c +++ b/drivers/hwmon/amd_energy.c @@ -222,7 +222,7 @@ static int amd_create_sensor(struct device *dev, */ cpus = num_present_cpus() / num_siblings; - s_config = devm_kcalloc(dev, cpus + sockets, + s_config = devm_kcalloc(dev, cpus + sockets + 1, sizeof(u32), GFP_KERNEL); if (!s_config) return -ENOMEM; @@ -254,6 +254,7 @@ static int amd_create_sensor(struct device *dev, scnprintf(label_l[i], 10, "Esocket%u", (i - cpus)); } + s_config[i] = 0; return 0; } -- 2.18.1
Re: [PATCH] iommu/io-pgtable-arm: Allow non-coherent masters to use system cache
On 2021-01-07 22:27, isa...@codeaurora.org wrote: On 2021-01-06 03:56, Will Deacon wrote: On Thu, Dec 24, 2020 at 12:10:07PM +0530, Sai Prakash Ranjan wrote: commit ecd7274fb4cd ("iommu: Remove unused IOMMU_SYS_CACHE_ONLY flag") removed unused IOMMU_SYS_CACHE_ONLY prot flag and along with it went the memory type setting required for the non-coherent masters to use system cache. Now that system cache support for GPU is added, we will need to mark the memory as normal sys-cached for GPU to use system cache. Without this, the system cache lines are not allocated for GPU. We use the IO_PGTABLE_QUIRK_ARM_OUTER_WBWA quirk instead of a page protection flag as the flag cannot be exposed via DMA api because of no in-tree users. Signed-off-by: Sai Prakash Ranjan --- drivers/iommu/io-pgtable-arm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c index 7c9ea9d7874a..3fb7de8304a2 100644 --- a/drivers/iommu/io-pgtable-arm.c +++ b/drivers/iommu/io-pgtable-arm.c @@ -415,6 +415,9 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data, else if (prot & IOMMU_CACHE) pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE << ARM_LPAE_PTE_ATTRINDX_SHIFT); + else if (data->iop.cfg.quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA) + pte |= (ARM_LPAE_MAIR_ATTR_IDX_INC_OCACHE + << ARM_LPAE_PTE_ATTRINDX_SHIFT); } While this approach of enabling system cache globally for both page tables and other buffers works for the GPU usecase, this isn't ideal for other clients that use system cache. For example, video clients only want to cache a subset of their buffers in the system cache, due to the sizing constraint imposed by how much of the system cache they can use. So, it would be ideal to have a way of expressing the desire to use the system cache on a per-buffer basis. Additionally, our video clients use the DMA layer, and since the requirement is for caching in the system cache to be a per buffer attribute, it seems like we would have to have a DMA attribute to express this on a per-buffer basis. I did bring this up initially [1], also where is this video client in upstream? AFAIK, only system cache user in upstream is GPU. We cannot add any DMA attribute unless there is any user upstream as per [2], so when the support for such a client is added, wouldn't ((data->iop.cfg.quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA) || PROT_FLAG) work? [1] https://lore.kernel.org/dri-devel/ecfda7ca80f6d7b4ff3d89b8758f4...@codeaurora.org/ [2] https://lore.kernel.org/linux-iommu/20191026053026.ga14...@lst.de/T/ Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] staging: mt7621-dts: remove obsolete switch node
On Fri, Jan 8, 2021 at 3:52 AM DENG Qingfang wrote: > > This was for OpenWrt's swconfig driver, which never made it upstream, > and was also superseded by MT7530 DSA driver. > > Signed-off-by: DENG Qingfang > --- > drivers/staging/mt7621-dts/mt7621.dtsi | 7 --- > 1 file changed, 7 deletions(-) Reviewed-by: Sergio Paracuellos
Re: [PATCH v6 1/5] dt-bindings: vendor-prefixes: Add an entry for Kverneland Group
On Thu, Jan 07, 2021 at 07:23:23PM -0700, Rob Herring wrote: > On Thu, 07 Jan 2021 11:08:27 +0100, Oleksij Rempel wrote: > > Add "kvg" entry for Kverneland Group: https://ien.kvernelandgroup.com/ > > > > Signed-off-by: Oleksij Rempel > > --- > > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > > 1 file changed, 2 insertions(+) > > > > > Please add Acked-by/Reviewed-by tags when posting new versions. However, > there's no need to repost patches *only* to add the tags. The upstream > maintainer will do that for acks received on the version they apply. > > If a tag was not added on purpose, please state why and what changed. Sorry, nothing is changed. Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH v14 2/4] fs: add LSM-supporting anon-inode interface
From: Daniel Colascione This change adds a new function, anon_inode_getfd_secure, that creates anonymous-node file with individual non-S_PRIVATE inode to which security modules can apply policy. Existing callers continue using the original singleton-inode kind of anonymous-inode file. We can transition anonymous inode users to the new kind of anonymous inode in individual patches for the sake of bisection and review. The new function accepts an optional context_inode parameter that callers can use to provide additional contextual information to security modules. For example, in case of userfaultfd, the created inode is a 'logical child' of the context_inode (userfaultfd inode of the parent process) in the sense that it provides the security context required during creation of the child process' userfaultfd inode. Signed-off-by: Daniel Colascione [LG: Delete obsolete comments to alloc_anon_inode()] [LG: Add context_inode description in comments to anon_inode_getfd_secure()] [LG: Remove definition of anon_inode_getfile_secure() as there are no callers] [LG: Make __anon_inode_getfile() static] [LG: Use correct error cast in __anon_inode_getfile()] [LG: Fix error handling in __anon_inode_getfile()] Signed-off-by: Lokesh Gidra Reviewed-by: Eric Biggers --- fs/anon_inodes.c| 150 ++-- fs/libfs.c | 5 -- include/linux/anon_inodes.h | 5 ++ 3 files changed, 115 insertions(+), 45 deletions(-) diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c index 89714308c25b..023337d65a03 100644 --- a/fs/anon_inodes.c +++ b/fs/anon_inodes.c @@ -55,61 +55,79 @@ static struct file_system_type anon_inode_fs_type = { .kill_sb= kill_anon_super, }; -/** - * anon_inode_getfile - creates a new file instance by hooking it up to an - * anonymous inode, and a dentry that describe the "class" - * of the file - * - * @name:[in]name of the "class" of the new file - * @fops:[in]file operations for the new file - * @priv:[in]private data for the new file (will be file's private_data) - * @flags: [in]flags - * - * Creates a new file by hooking it on a single inode. This is useful for files - * that do not need to have a full-fledged inode in order to operate correctly. - * All the files created with anon_inode_getfile() will share a single inode, - * hence saving memory and avoiding code duplication for the file/inode/dentry - * setup. Returns the newly created file* or an error pointer. - */ -struct file *anon_inode_getfile(const char *name, - const struct file_operations *fops, - void *priv, int flags) +static struct inode *anon_inode_make_secure_inode( + const char *name, + const struct inode *context_inode) { - struct file *file; + struct inode *inode; + const struct qstr qname = QSTR_INIT(name, strlen(name)); + int error; + + inode = alloc_anon_inode(anon_inode_mnt->mnt_sb); + if (IS_ERR(inode)) + return inode; + inode->i_flags &= ~S_PRIVATE; + error = security_inode_init_security_anon(inode, &qname, context_inode); + if (error) { + iput(inode); + return ERR_PTR(error); + } + return inode; +} - if (IS_ERR(anon_inode_inode)) - return ERR_PTR(-ENODEV); +static struct file *__anon_inode_getfile(const char *name, +const struct file_operations *fops, +void *priv, int flags, +const struct inode *context_inode, +bool secure) +{ + struct inode *inode; + struct file *file; if (fops->owner && !try_module_get(fops->owner)) return ERR_PTR(-ENOENT); - /* -* We know the anon_inode inode count is always greater than zero, -* so ihold() is safe. -*/ - ihold(anon_inode_inode); - file = alloc_file_pseudo(anon_inode_inode, anon_inode_mnt, name, + if (secure) { + inode = anon_inode_make_secure_inode(name, context_inode); + if (IS_ERR(inode)) { + file = ERR_CAST(inode); + goto err; + } + } else { + inode = anon_inode_inode; + if (IS_ERR(inode)) { + file = ERR_PTR(-ENODEV); + goto err; + } + /* +* We know the anon_inode inode count is always +* greater than zero, so ihold() is safe. +*/ + ihold(inode); + } + + file = alloc_file_pseudo(inode, anon_inode_mnt, name, flags & (O_ACCMODE | O_NONBLOCK), fops); if (IS_ERR(file)) - goto err; +
[PATCH v14 4/4] userfaultfd: use secure anon inodes for userfaultfd
From: Daniel Colascione This change gives userfaultfd file descriptors a real security context, allowing policy to act on them. Signed-off-by: Daniel Colascione [LG: Remove owner inode from userfaultfd_ctx] [LG: Use anon_inode_getfd_secure() instead of anon_inode_getfile_secure() in userfaultfd syscall] [LG: Use inode of file in userfaultfd_read() in resolve_userfault_fork()] Signed-off-by: Lokesh Gidra Reviewed-by: Eric Biggers --- fs/userfaultfd.c | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index 894cc28142e7..0be8cdd4425a 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -979,14 +979,14 @@ static __poll_t userfaultfd_poll(struct file *file, poll_table *wait) static const struct file_operations userfaultfd_fops; -static int resolve_userfault_fork(struct userfaultfd_ctx *ctx, - struct userfaultfd_ctx *new, +static int resolve_userfault_fork(struct userfaultfd_ctx *new, + struct inode *inode, struct uffd_msg *msg) { int fd; - fd = anon_inode_getfd("[userfaultfd]", &userfaultfd_fops, new, - O_RDWR | (new->flags & UFFD_SHARED_FCNTL_FLAGS)); + fd = anon_inode_getfd_secure("[userfaultfd]", &userfaultfd_fops, new, + O_RDWR | (new->flags & UFFD_SHARED_FCNTL_FLAGS), inode); if (fd < 0) return fd; @@ -996,7 +996,7 @@ static int resolve_userfault_fork(struct userfaultfd_ctx *ctx, } static ssize_t userfaultfd_ctx_read(struct userfaultfd_ctx *ctx, int no_wait, - struct uffd_msg *msg) + struct uffd_msg *msg, struct inode *inode) { ssize_t ret; DECLARE_WAITQUEUE(wait, current); @@ -1107,7 +1107,7 @@ static ssize_t userfaultfd_ctx_read(struct userfaultfd_ctx *ctx, int no_wait, spin_unlock_irq(&ctx->fd_wqh.lock); if (!ret && msg->event == UFFD_EVENT_FORK) { - ret = resolve_userfault_fork(ctx, fork_nctx, msg); + ret = resolve_userfault_fork(fork_nctx, inode, msg); spin_lock_irq(&ctx->event_wqh.lock); if (!list_empty(&fork_event)) { /* @@ -1167,6 +1167,7 @@ static ssize_t userfaultfd_read(struct file *file, char __user *buf, ssize_t _ret, ret = 0; struct uffd_msg msg; int no_wait = file->f_flags & O_NONBLOCK; + struct inode *inode = file_inode(file); if (ctx->state == UFFD_STATE_WAIT_API) return -EINVAL; @@ -1174,7 +1175,7 @@ static ssize_t userfaultfd_read(struct file *file, char __user *buf, for (;;) { if (count < sizeof(msg)) return ret ? ret : -EINVAL; - _ret = userfaultfd_ctx_read(ctx, no_wait, &msg); + _ret = userfaultfd_ctx_read(ctx, no_wait, &msg, inode); if (_ret < 0) return ret ? ret : _ret; if (copy_to_user((__u64 __user *) buf, &msg, sizeof(msg))) @@ -1999,8 +2000,8 @@ SYSCALL_DEFINE1(userfaultfd, int, flags) /* prevent the mm struct to be freed */ mmgrab(ctx->mm); - fd = anon_inode_getfd("[userfaultfd]", &userfaultfd_fops, ctx, - O_RDWR | (flags & UFFD_SHARED_FCNTL_FLAGS)); + fd = anon_inode_getfd_secure("[userfaultfd]", &userfaultfd_fops, ctx, + O_RDWR | (flags & UFFD_SHARED_FCNTL_FLAGS), NULL); if (fd < 0) { mmdrop(ctx->mm); kmem_cache_free(userfaultfd_ctx_cachep, ctx); -- 2.30.0.284.gd98b1dd5eaa7-goog
[PATCH v14 3/4] selinux: teach SELinux about anonymous inodes
From: Daniel Colascione This change uses the anon_inodes and LSM infrastructure introduced in the previous patches to give SELinux the ability to control anonymous-inode files that are created using the new anon_inode_getfd_secure() function. A SELinux policy author detects and controls these anonymous inodes by adding a name-based type_transition rule that assigns a new security type to anonymous-inode files created in some domain. The name used for the name-based transition is the name associated with the anonymous inode for file listings --- e.g., "[userfaultfd]" or "[perf_event]". Example: type uffd_t; type_transition sysadm_t sysadm_t : anon_inode uffd_t "[userfaultfd]"; allow sysadm_t uffd_t:anon_inode { create }; (The next patch in this series is necessary for making userfaultfd support this new interface. The example above is just for exposition.) Signed-off-by: Daniel Colascione Signed-off-by: Lokesh Gidra --- security/selinux/hooks.c| 59 + security/selinux/include/classmap.h | 2 + 2 files changed, 61 insertions(+) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 644b17ec9e63..8b4e155b2930 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -2934,6 +2933,63 @@ static int selinux_inode_init_security(struct inode *inode, struct inode *dir, return 0; } +static int selinux_inode_init_security_anon(struct inode *inode, + const struct qstr *name, + const struct inode *context_inode) +{ + const struct task_security_struct *tsec = selinux_cred(current_cred()); + struct common_audit_data ad; + struct inode_security_struct *isec; + int rc; + + if (unlikely(!selinux_initialized(&selinux_state))) + return 0; + + isec = selinux_inode(inode); + + /* +* We only get here once per ephemeral inode. The inode has +* been initialized via inode_alloc_security but is otherwise +* untouched. +*/ + isec->initialized = LABEL_INITIALIZED; + isec->sclass = SECCLASS_ANON_INODE; + + if (context_inode) { + struct inode_security_struct *context_isec = + selinux_inode(context_inode); + if (context_isec->initialized != LABEL_INITIALIZED) + return -EACCES; + if (context_isec->sclass != SECCLASS_ANON_INODE) { + pr_err("SELinux: initializing anonymous inode with non-anonymous inode"); + return -EACCES; + } + + isec->sid = context_isec->sid; + } else { + rc = security_transition_sid( + &selinux_state, tsec->sid, tsec->sid, + isec->sclass, name, &isec->sid); + if (rc) + return rc; + } + + /* +* Now that we've initialized security, check whether we're +* allowed to actually create this type of anonymous inode. +*/ + + ad.type = LSM_AUDIT_DATA_INODE; + ad.u.inode = inode; + + return avc_has_perm(&selinux_state, + tsec->sid, + isec->sid, + isec->sclass, + ANON_INODE__CREATE, + &ad); +} + static int selinux_inode_create(struct inode *dir, struct dentry *dentry, umode_t mode) { return may_create(dir, dentry, SECCLASS_FILE); @@ -7000,6 +7057,7 @@ static struct security_hook_list selinux_hooks[] __lsm_ro_after_init = { LSM_HOOK_INIT(inode_free_security, selinux_inode_free_security), LSM_HOOK_INIT(inode_init_security, selinux_inode_init_security), + LSM_HOOK_INIT(inode_init_security_anon, selinux_inode_init_security_anon), LSM_HOOK_INIT(inode_create, selinux_inode_create), LSM_HOOK_INIT(inode_link, selinux_inode_link), LSM_HOOK_INIT(inode_unlink, selinux_inode_unlink), diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h index 40cebde62856..ba2e01a6955c 100644 --- a/security/selinux/include/classmap.h +++ b/security/selinux/include/classmap.h @@ -249,6 +249,8 @@ struct security_class_mapping secclass_map[] = { {"open", "cpu", "kernel", "tracepoint", "read", "write"} }, { "lockdown", { "integrity", "confidentiality", NULL } }, + { "anon_inode", + { COMMON_FILE_PERMS, NULL } }, { NULL } }; -- 2.30.0.284.gd98b1dd5eaa7-goog
[PATCH v14 0/4] SELinux support for anonymous inodes and UFFD
Userfaultfd in unprivileged contexts could be potentially very useful. We'd like to harden userfaultfd to make such unprivileged use less risky. This patch series allows SELinux to manage userfaultfd file descriptors and in the future, other kinds of anonymous-inode-based file descriptor. SELinux policy authors can apply policy types to anonymous inodes by providing name-based transition rules keyed off the anonymous inode internal name ( "[userfaultfd]" in the case of userfaultfd(2) file descriptors) and applying policy to the new SIDs thus produced. With SELinux managed userfaultfd, an admin can control creation and movement of the file descriptors. In particular, handling of a userfaultfd descriptor by a different process is essentially a ptrace access into the process, without any of the corresponding security_ptrace_access_check() checks. For privacy, the admin may want to deny such accesses, which is possible with SELinux support. Inside the kernel, a new anon_inode interface, anon_inode_getfd_secure, allows callers to opt into this SELinux management. In this new "secure" mode, anon_inodes create new ephemeral inodes for anonymous file objects instead of reusing the normal anon_inodes singleton dummy inode. A new LSM hook gives security modules an opportunity to configure and veto these ephemeral inodes. This patch series is one of two fork of [1] and is an alternative to [2]. The primary difference between the two patch series is that this partch series creates a unique inode for each "secure" anonymous inode, while the other patch series ([2]) continues using the singleton dummy anonymous inode and adds a way to attach SELinux security information directly to file objects. I prefer the approach in this patch series because 1) it's a smaller patch than [2], and 2) it produces a more regular security architecture: in this patch series, secure anonymous inodes aren't S_PRIVATE and they maintain the SELinux property that the label for a file is in its inode. We do need an additional inode per anonymous file, but per-struct-file inode creation doesn't seem to be a problem for pipes and sockets. The previous version of this feature ([1]) created a new SELinux security class for userfaultfd file descriptors. This version adopts the generic transition-based approach of [2]. This patch series also differs from [2] in that it doesn't affect all anonymous inodes right away --- instead requiring anon_inodes callers to opt in --- but this difference isn't one of basic approach. The important question to resolve is whether we should be creating new inodes or enhancing per-file data. Changes from the first version of the patch: - Removed some error checks - Defined a new anon_inode SELinux class to resolve the ambiguity in [3] - Inherit sclass as well as descriptor from context inode Changes from the second version of the patch: - Fixed example policy in the commit message to reflect the use of the new anon_inode class. Changes from the third version of the patch: - Dropped the fops parameter to the LSM hook - Documented hook parameters - Fixed incorrect class used for SELinux transition - Removed stray UFFD changed early in the series - Removed a redundant ERR_PTR(PTR_ERR()) Changes from the fourth version of the patch: - Removed an unused parameter from an internal function - Fixed function documentation Changes from the fifth version of the patch: - Fixed function documentation in fs/anon_inodes.c and include/linux/lsm_hooks.h - Used anon_inode_getfd_secure() in userfaultfd() syscall and removed owner from userfaultfd_ctx. Changes from the sixth version of the patch: - Removed definition of anon_inode_getfile_secure() as there are no callers. - Simplified function description of anon_inode_getfd_secure(). - Elaborated more on the purpose of 'context_inode' in commit message. Changes from the seventh version of the patch: - Fixed error handling in _anon_inode_getfile(). - Fixed minor comment and indentation related issues. Changes from the eighth version of the patch: - Replaced selinux_state.initialized with selinux_state.initialized Changes from the ninth version of the patch: - Fixed function names in fs/anon_inodes.c - Fixed comment of anon_inode_getfd_secure() - Fixed name of the patch wherein userfaultfd code uses anon_inode_getfd_secure() Changes from the tenth version of the patch: - Split first patch into VFS and LSM specific patches - Fixed comments in fs/anon_inodes.c - Fixed comment of alloc_anon_inode() Changes from the eleventh version of the patch: - Removed comment of alloc_anon_inode() for consistency with the code - Fixed explanation of LSM hook in the commit message Changes from the twelfth version of the patch: - Replaced FILE__CREATE with ANON_INODE__CREATE while initializing anon-inode's SELinux security struct. - Check context_inode's SELinux label and return -EACCES if it
[PATCH v14 1/4] security: add inode_init_security_anon() LSM hook
This change adds a new LSM hook, inode_init_security_anon(), that will be used while creating secure anonymous inodes. The hook allows/denies its creation and assigns a security context to the inode. The new hook accepts an optional context_inode parameter that callers can use to provide additional contextual information to security modules for granting/denying permission to create an anon-inode of the same type. This context_inode's security_context can also be used to initialize the newly created anon-inode's security_context. Signed-off-by: Lokesh Gidra Reviewed-by: Eric Biggers --- include/linux/lsm_hook_defs.h | 2 ++ include/linux/lsm_hooks.h | 9 + include/linux/security.h | 10 ++ security/security.c | 8 4 files changed, 29 insertions(+) diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h index 7aaa753b8608..dfd261dcbcb0 100644 --- a/include/linux/lsm_hook_defs.h +++ b/include/linux/lsm_hook_defs.h @@ -113,6 +113,8 @@ LSM_HOOK(void, LSM_RET_VOID, inode_free_security, struct inode *inode) LSM_HOOK(int, 0, inode_init_security, struct inode *inode, struct inode *dir, const struct qstr *qstr, const char **name, void **value, size_t *len) +LSM_HOOK(int, 0, inode_init_security_anon, struct inode *inode, +const struct qstr *name, const struct inode *context_inode) LSM_HOOK(int, 0, inode_create, struct inode *dir, struct dentry *dentry, umode_t mode) LSM_HOOK(int, 0, inode_link, struct dentry *old_dentry, struct inode *dir, diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h index a19adef1f088..bdfc8a76a4f7 100644 --- a/include/linux/lsm_hooks.h +++ b/include/linux/lsm_hooks.h @@ -233,6 +233,15 @@ * Returns 0 if @name and @value have been successfully set, * -EOPNOTSUPP if no security attribute is needed, or * -ENOMEM on memory allocation failure. + * @inode_init_security_anon: + * Set up the incore security field for the new anonymous inode + * and return whether the inode creation is permitted by the security + * module or not. + * @inode contains the inode structure + * @name name of the anonymous inode class + * @context_inode optional related inode + * Returns 0 on success, -EACCES if the security module denies the + * creation of this inode, or another -errno upon other errors. * @inode_create: * Check permission to create a regular file. * @dir contains inode structure of the parent of the new file. diff --git a/include/linux/security.h b/include/linux/security.h index c35ea0ffccd9..b0d14f04b16d 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -324,6 +324,9 @@ void security_inode_free(struct inode *inode); int security_inode_init_security(struct inode *inode, struct inode *dir, const struct qstr *qstr, initxattrs initxattrs, void *fs_data); +int security_inode_init_security_anon(struct inode *inode, + const struct qstr *name, + const struct inode *context_inode); int security_old_inode_init_security(struct inode *inode, struct inode *dir, const struct qstr *qstr, const char **name, void **value, size_t *len); @@ -738,6 +741,13 @@ static inline int security_inode_init_security(struct inode *inode, return 0; } +static inline int security_inode_init_security_anon(struct inode *inode, + const struct qstr *name, + const struct inode *context_inode) +{ + return 0; +} + static inline int security_old_inode_init_security(struct inode *inode, struct inode *dir, const struct qstr *qstr, diff --git a/security/security.c b/security/security.c index 7b09cfbae94f..401663b5b70e 100644 --- a/security/security.c +++ b/security/security.c @@ -1059,6 +1059,14 @@ int security_inode_init_security(struct inode *inode, struct inode *dir, } EXPORT_SYMBOL(security_inode_init_security); +int security_inode_init_security_anon(struct inode *inode, + const struct qstr *name, + const struct inode *context_inode) +{ + return call_int_hook(inode_init_security_anon, 0, inode, name, +context_inode); +} + int security_old_inode_init_security(struct inode *inode, struct inode *dir, const struct qstr *qstr, const char **name, void **value, size_t *len) -- 2.30.0.284.gd98b1dd5eaa7-goog
Re: [PATCH v7 net-next 2/2] net: dsa: qca: ar9331: export stats64
On Thu, Jan 07, 2021 at 03:36:45PM +0100, Andrew Lunn wrote: > > +static void ar9331_get_stats64(struct dsa_switch *ds, int port, > > + struct rtnl_link_stats64 *s) > > +{ > > + struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv; > > + struct ar9331_sw_port *p = &priv->port[port]; > > + > > + spin_lock(&p->stats_lock); > > + memcpy(s, &p->stats, sizeof(*s)); > > + spin_unlock(&p->stats_lock); > > +} > > This should probably wait until Vladimir's changes for stat64 are > merged, so this call can sleep. You can then return up to date > statistics. Ack, no problem. Beside, i forgot to collect all the Reviewed-by tags. Will resend all needed changes after Vladimirs patches are accepted. May be the "net: dsa: add optional stats64 support" can already be taken? Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH] fs: process fput task_work with TWA_SIGNAL
On Tue, Jan 05, 2021 at 11:29:11AM -0700, Jens Axboe wrote: > Song reported a boot regression in a kvm image with 5.11-rc, and bisected > it down to the below patch. Debugging this issue, turns out that the boot > stalled when a task is waiting on a pipe being released. As we no longer > run task_work from get_signal() unless it's queued with TWA_SIGNAL, the > task goes idle without running the task_work. This prevents ->release() > from being called on the pipe, which another boot task is waiting on. > > Use TWA_SIGNAL for the file fput work to ensure it's run before the task > goes idle. > > Fixes: 98b89b649fce ("signal: kill JOBCTL_TASK_WORK") > Reported-by: Song Liu > Signed-off-by: Jens Axboe > > --- > > The other alternative here is obviously to re-instate the: > > if (unlikely(current->task_works)) > task_work_run(); > > in get_signal() that we had before this change. Might be safer in case > there are other cases that need to ensure the work is run in a timely > fashion, though I do think it's cleaner to long term to correctly mark > task_work with the needed notification type. Comments welcome... Interesting... I think I've missed the discussion of that thing; could you forward the relevant thread my way or give an archive link to it?
Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)
On 1/7/21 7:48 PM, Sergey Senozhatsky wrote: On (21/01/07 09:58), Vineet Gupta wrote: On 1/7/21 9:04 AM, Petr Mladek wrote: On Thu 2021-01-07 08:43:16, Vineet Gupta wrote: Hi John, On 1/7/21 1:02 AM, John Ogness wrote: Hi Vineet, On 2021-01-06, Vineet Gupta wrote: This breaks ARC booting (no output on console). Could you provide the kernel boot arguments that you use? This series is partly about addressing users that have used boot arguments that are technically incorrect (even if had worked). Seeing the boot arguments of users that are not experiencing problems may help to reveal some of the unusual console usages until now. Kernel command line: earlycon=uart8250,mmio32,0xf0005000,115200n8 console=ttyS0,115200n8 debug print-fatal-signals=1 This is strange, the problematic patch should use ttynull only as a fallback. It should not be used when a particular console is defined on the command line. What happens in my case is console_on_rootfs() doesn't find /dev/console and switching to ttynull. /dev is not present because devtmpfs doesn't automount for initramfs. I wonder if we'll move the nulltty fallback logic into printk code [1] will it fix the problem? [1] https://lore.kernel.org/lkml/X6x%2FAxD1qanC6evJ@jagdpanzerIV.localdomain/ Your reasoning in the post above makes total sense. I tired the patch: adding register_ttynull_console() call in console_device(), removing from console_on_rootfs() band that works too. | Warning: unable to open an initial console. Fallback to ttynull. | Warning: Failed to add ttynull console. No stdin, stdout, and stderr for the init process! | Freeing unused kernel memory: 3096K | This architecture does not have kernel memory protection. | Run /init as init process | with arguments: |/init | with environment: |HOME=/ |TERM=linux | Starting System logger (syslogd) | Bringing up loopback device | Starting inetd | Mounting Posix Mqueue filesys | CONFIG_INITRAMFS_SOURCE="~/arc/RAMFS/archs/ramfs_2011-GNU-2020-03-glibc-2.32-tiny" | ** | Welcome to ARCLinux | ** | [ARCLinux]#
[GIT PULL] Networking for 5.11-rc3
Hi! Slightly lighter PR to get back into the Thu cadence. The HighMem fixes not here yet, but I didn't think they were urgent so no point delaying. The following changes since commit f6e7a024bfe5e11d91ccff46bb576e3fb5a516ea: Merge tag 'arc-5.11-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc (2021-01-05 12:46:27 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git tags/net-5.11-rc3-2 for you to fetch changes up to 220efcf9caf755bdf92892afd37484cb6859e0d2: Merge tag 'mlx5-fixes-2021-01-07' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux (2021-01-07 19:13:30 -0800) Networking fixes for 5.11-rc3 (part 2), including fixes from bpf and can trees. Current release - always broken: - can: mcp251xfd: fix Tx/Rx ring buffer driver race conditions - dsa: hellcreek: fix led_classdev build errors Previous releases - regressions: - ipv6: fib: flush exceptions when purging route to avoid netdev reference leak - ip_tunnels: fix pmtu check in nopmtudisc mode - ip: always refragment ip defragmented packets to avoid MTU issues when forwarding through tunnels, correct "packet too big" message is prohibitively tricky to generate - s390/qeth: fix locking for discipline setup / removal and during recovery to prevent both deadlocks and races - mlx5: Use port_num 1 instead of 0 when delete a RoCE address Previous releases - always broken: - cdc_ncm: correct overhead calculation in delayed_ndp_size to prevent out of bound accesses with Huawei 909s-120 LTE module - stmmac: dwmac-sun8i: fix suspend/resume: - PHY being left powered off - MAC syscon configuration being reset - reference to the reset controller being improperly dropped - qrtr: fix null-ptr-deref in qrtr_ns_remove - can: tcan4x5x: fix bittiming const, use common bittiming from m_can driver - mlx5e: CT: Use per flow counter when CT flow accounting is enabled - mlx5e: Fix SWP offsets when vlan inserted by driver Misc: - bpf: Fix a task_iter bug caused by a bpf -> net merge conflict resolution And the usual many fixes to various error paths. Signed-off-by: Jakub Kicinski Alaa Hleihel (1): net/mlx5: E-Switch, fix changing vf VLANID Alan Maguire (1): bpftool: Fix compilation failure for net.o with older glibc Aleksander Jan Bajkowski (1): net: dsa: lantiq_gswip: Exclude RMII from modes that report 1 GbE Arnd Bergmann (7): qed: select CONFIG_CRC32 phy: dp83640: select CONFIG_CRC32 can: kvaser_pciefd: select CONFIG_CRC32 wil6210: select CONFIG_CRC32 cfg80211: select CONFIG_CRC32 misdn: dsp: select CONFIG_BITREVERSE wan: ds26522: select CONFIG_BITREVERSE Aya Levin (2): net/mlx5e: Add missing capability check for uplink follow net/mlx5e: ethtool, Fix restriction of autoneg with 56G Ayush Sawal (7): chtls: Fix hardware tid leak chtls: Remove invalid set_tcb call chtls: Fix panic when route to peer not configured chtls: Avoid unnecessary freeing of oreq pointer chtls: Replace skb_dequeue with skb_peek chtls: Added a check to avoid NULL pointer dereference chtls: Fix chtls resources release sequence Christophe JAILLET (1): net/sonic: Fix some resource leaks in error handling paths Colin Ian King (1): octeontx2-af: fix memory leak of lmac and lmac->name David S. Miller (2): Merge branch 'stmmac-fixes' Merge branch 'hns3-fixes' Dinghao Liu (2): net/mlx5e: Fix two double free cases net/mlx5e: Fix memleak in mlx5e_create_l2_table_groups Florian Westphal (3): selftests: netfilter: add selftest for ipip pmtu discovery with enabled connection tracking net: fix pmtu check in nopmtudisc mode net: ip: always refragment ip defragmented packets Ido Schimmel (3): nexthop: Fix off-by-one error in error path nexthop: Unlink nexthop group entry in error path selftests: fib_nexthops: Fix wrong mausezahn invocation Jakub Kicinski (11): net: suggest L2 discards be counted towards rx_dropped net: vlan: avoid leaks on register_vlan_dev() failures docs: net: fix documentation on .ndo_get_stats net: bareudp: add missing error handling for bareudp_link_config() Merge tag 'linux-can-fixes-for-5.11-20210107' of git://git.kernel.org/.../mkl/linux-can Merge branch 'net-fix-netfilter-defrag-ip-tunnel-pmtu-blackhole' Merge https://git.kernel.org/.../bpf/bpf Merge branch 'bug-fixes-for-chtls-driver' Merge branch 'nexthop-various-fixes' Merge branch 's390-qeth-fixes-2021-01-07&
linux-next: Tree for Jan 8
Hi all, Changes since 20210107: The net-next tree gained conflict against the net tree. The drm tree gained a build failure so I used the version from next-20210107. The amdgpu tree gained conflict against Linus' tree and a build failure so I used the version from next-20210107. The drm-misc tree gained a build failure from merging the drm tree, so I have used the version from next-20210107. Non-merge commits (relative to Linus' tree): 1770 1804 files changed, 62353 insertions(+), 28668 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 htmldocs. 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 330 trees (counting Linus' and 85 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 (f5e6c330254a Merge tag 'spi-fix-v5.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi) Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2) Merging kbuild-current/fixes (9bba03d4473d kconfig: remove 'kvmconfig' and 'xenconfig' shorthands) Merging arc-current/for-curr (bb12433bf56e ARC: unbork 5.11 bootup: fix snafu in _TIF_NOTIFY_SIGNAL handling) Merging arm-current/fixes (e64ab473ddda ARM: 9034/1: __div64_32(): straighten up inline asm constraints) Merging arm64-fixes/for-next/fixes (462a1b17f8ef arm64: Move PSTATE.TCO setting to separate functions) Merging arm-soc-fixes/arm/fixes (7887cc89d585 ARM: dts: ux500/golden: Set display max brightness) Merging drivers-memory-fixes/fixes (5c8fe583cce5 Linux 5.11-rc1) Merging m68k-current/for-linus (2ae92e8b9b7e MAINTAINERS: Update m68k Mac entry) Merging powerpc-fixes/fixes (3ce47d95b734 powerpc: Handle .text.{hot,unlikely}.* in linker script) Merging s390-fixes/fixes (129975e75b9a s390/Kconfig: sort config S390 select list once again) Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro) Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption not used on new files) Merging net/master (f3562f5e00bb docs: octeontx2: tune rst markup) Merging bpf/master (6f02b540d759 bpftool: Fix compilation failure for net.o with older glibc) Merging ipsec/master (da64ae2d35d3 xfrm: Fix wraparound in xfrm_policy_addr_delta()) Merging netfilter/master (a8f33c038f4e Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging ipvs/master (b4e70d8dd9ea netfilter: nftables: add set expression flags) Merging wireless-drivers/master (bfe55584713b MAINTAINERS: switch to different email address) Merging mac80211/master (3503ee6c0bec selftests: fix the return value for UDP GRO test) Merging rdma-fixes/for-rc (e71ba9452f0b Linux 5.11-rc2) Merging sound-current/for-linus (7b6227550723 Merge tag 'asoc-fix-v5.11-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging sound-asoc-fixes/for-linus (abe845f315b9 Merge remote-tracking branch 'asoc/for-5.11' into asoc-linus) Merging regmap-fixes/for-linus (72962ebcdd45 Merge remote-tracking branch 'regmap/for-5.11' into regmap-linus) Merging regulator-fixes/for-linus (cd66a1589b7c Merge remote-tracking branch 'regulator/for-5.11' into regulator-linus) Merging spi-fixes/for-linus (02b3446f68d5 Merge remote-tracking branch 'spi/for-5.11' into spi-linus) Merging pci-current/for
Re: [PATCH 1/2] cros_ec_commands: Add EC_CODEC_I2S_RX_RESET
Mark Brown 於 2021年1月7日 週四 下午9:55寫道: > > On Thu, Jan 07, 2021 at 04:59:41PM +0800, Yu-Hsuan Hsu wrote: > > Add the new command EC_CODEC_I2S_RX_RESET in ec_codec_i2s_rx_subcmd, > > which is used for resetting the EC codec. > > I think the request was to sync over all the commands that are supported > in the EC rather than just split this one addition into a separate > patch. Got it. However, after running make_linux_ec_commands_h.sh to create the new cros_ec_commands.h, I found there are lots of difference (1092 insertions(+), 66 deletions(-)). In addition, there are also some redefined variables(most are in ./include/linux/usb/pd.h) causing the compile error. It seems not easy to sync cros_ec_commands.h. I'm afraid of breaking something. Does anyone have any suggestion? Thanks.
Re: [PATCH] crypto: omap-sham - Fix link error without crypto-engine
On Sun, Jan 03, 2021 at 03:03:04PM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > The driver was converted to use the crypto engine helper > but is missing the corresponding Kconfig statement to ensure > it is available: > > arm-linux-gnueabi-ld: drivers/crypto/omap-sham.o: in function > `omap_sham_probe': > omap-sham.c:(.text+0x374): undefined reference to `crypto_engine_alloc_init' > arm-linux-gnueabi-ld: omap-sham.c:(.text+0x384): undefined reference to > `crypto_engine_start' > arm-linux-gnueabi-ld: omap-sham.c:(.text+0x510): undefined reference to > `crypto_engine_exit' > arm-linux-gnueabi-ld: drivers/crypto/omap-sham.o: in function > `omap_sham_finish_req': > omap-sham.c:(.text+0x98c): undefined reference to > `crypto_finalize_hash_request' > arm-linux-gnueabi-ld: omap-sham.c:(.text+0x9a0): undefined reference to > `crypto_transfer_hash_request_to_engine' > arm-linux-gnueabi-ld: drivers/crypto/omap-sham.o: in function > `omap_sham_update': > omap-sham.c:(.text+0xf24): undefined reference to > `crypto_transfer_hash_request_to_engine' > arm-linux-gnueabi-ld: drivers/crypto/omap-sham.o: in function > `omap_sham_final': > omap-sham.c:(.text+0x1020): undefined reference to > `crypto_transfer_hash_request_to_engine' > > Fixes: 133c3d434d91 ("crypto: omap-sham - convert to use crypto engine") > Signed-off-by: Arnd Bergmann > --- > drivers/crypto/Kconfig | 1 + > 1 file changed, 1 insertion(+) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH v4] power: suspend: Move dpm_watchdog to suspend.c and enhance it
Since dpm_watchdog just cover two functions __device_suspend() and device_resume(), we proposed to move it to core power suspend.c to extend its coverage and monitor more devices suspend hand issues. We propose to use new name suspend watchdog and new timeout handler to cover more sleep hang issues. The new timeout handler will dump disk sleep task call trace at first round timeout and trigger kernel panic at second round timeout. The default timer for each round is defined in CONFIG_PM_SUSPEND_WATCHDOG_TIMEOUT. Signed-off-by: Joseph Jang --- Changes since v3: - Change the naming from sleep timer to suspend watchdog. - Remove console_is_suspended() from console.h and printk.c - Add static declaration for suspend_watchdog struct since we use it in suspend.c only. - Move suspend watchdog real logic to suspend_watchdog.c. - Put the function prototypes in suspend_watchdog.h - Use inline functions for function prototypes definition. Changes since v2: - Add kernel/power/suspend_timer.h in MAINTAINERS - Share some corner cases that dpm_watchdog cannot cover. Case#A: dpm_watchdog cannot cover suspend hang in suspend_enter(). File: kernel/power/suspend.c int suspend_devices_and_enter(suspend_state_t state) { ... suspend_test_start(); error = dpm_suspend_start(PMSG_SUSPEND); <== dpm_watchdog will be enabled/disabled in this fucntion ... if (error) { pr_err("Some devices failed to suspend, or early wake event detected\n"); goto Recover_platform; } suspend_test_finish("suspend devices"); if (suspend_test(TEST_DEVICES)) goto Recover_platform; do { error = suspend_enter(state, &wakeup); <== but we encounter hang inside function suspend_enter() ... } while (!error && !wakeup && platform_suspend_again(state)); Case#B: dpm_watchdog cannot cover resume hang in dpm_resume_early() because it enable/disable in device_resume(). Call trace: __switch_to+0x174/0x194 __schedule+0xa60/0x1464 __cancel_work_timer+0x120/0x234 chg_pm_resume+0x2c/0xd8 dpm_run_callback+0x27c/0x624 device_resume_early+0x1e4/0x1f8 dpm_resume_early+0x350/0x8f4 suspend_devices_and_enter+0xffc/0x168c pm_suspend+0xb54/0xdac File: drivers/base/power/main.c. static int device_resume(struct device *dev, pm_message_t state, bool async) if (!dpm_wait_for_superior(dev, async)) goto Complete; dpm_watchdog_set(&wd, dev); device_lock(dev); /* ... Unlock: device_unlock(dev); dpm_watchdog_clear(&wd); Case#C: dpm_watchdog cannot cover suspend hang in ksys_sync(). Call trace: __switch_to+0x1b0/0x1cc __schedule+0xac8/0x1314 io_schedule+0x94/0xc8 wait_on_page_bit+0x1f8/0x3a4 __filemap_fdatawait_range+0x134/0x150 sync_inodes_sb+0x368/0x584 sync_inodes_one_sb+0x18/0x24 iterate_supers+0x12c/0x2b8 ksys_sync+0x48/0x12c enter_state+0x294/0x7bc pm_suspend+0x164/0x2a8 - Explain some enhancement by following. Q1: Why not use the existing one? struct dpm_watchdog { struct device *dev; struct task_struct *tsk; struct timer_list timer; }; A1: In kernel/power/suspend.c, we don't have "struct device " because suspend.c is for core PM instead of device PM. So we propose to use sleep_timer struct. struct sleep_timer { struct task_struct*tsk; struct timer_list timer; }; Q2: Why not use stack memory for timer struct? static void dpm_watchdog_set(struct dpm_watchdog *wd, struct device *dev) { ... timer_setup_on_stack(timer, dpm_watchdog_handler, 0); <== dpm_watchdog use stack memory for timer struct. /* use same timeout value for both suspend and resume */ timer->expires = jiffies + HZ * CONFIG_DPM_WATCHDOG_TIMEOUT; add_timer(timer); } A2: dpm_watchdog use stack memory has limitation. It cannot support starting watchdog at end of function like s2idle_enter(). We cannot use stack memory for this case because the timer struct will be free when go back to caller. File: kernel/power/suspend.c static void s2idle_enter(void) { trace_suspend_resume(TPS("machine_suspend"), PM_SUSPEND_TO_IDLE, true); + stop_sleep_timer(&st); + raw_spin_lock_irq(&s2idle_lock); if (pm_wakeup_pending()) goto out; ... s2idle_state = S2IDLE_STATE_NONE; raw_spin_unlock_irq(&s2idle_lock); + start_sleep_timer(&st); + trace_suspend_resume(TPS("machine_suspend"), PM_SUSPEND_TO_IDLE, false); } So we propose to declare a global sleep timer struct in suspend.c like following. File: kernel/power/suspend.c static DEFINE_RAW_SPINLOCK(s2idle_lock); +DECLARE_SLEEP_TIMER(st); + /** * pm_suspend_default_s2idle - Check if susp
Re: [PATCH v2] crypto: Fix divide error in do_xor_speed()
On Tue, Jan 05, 2021 at 01:24:18PM -0800, Doug Anderson wrote: > > ...so while I think your fix will avoid the crash and could land as a > stopgap, it's a sign that we need to run more repetitions on your > particular setup to get accurate timings. Your patch will probably > cause it to just randomly pick one of the implementations. We can always do a follow-up patch. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: Fix divide error in do_xor_speed()
On Thu, Dec 31, 2020 at 12:33:18AM +0300, Kirill Tkhai wrote: > crypto: Fix divide error in do_xor_speed() > > From: Kirill Tkhai > > Latest (but not only latest) linux-next panics with divide > error on my QEMU setup. > > The patch at the bottom of this message fixes the problem. > > xor: measuring software checksum speed > divide error: [#1] PREEMPT SMP KASAN > PREEMPT SMP KASAN > CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.10.0-next-20201223+ #2177 > RIP: 0010:do_xor_speed+0xbb/0xf3 > Code: 41 ff cc 75 b5 bf 01 00 00 00 e8 3d 23 8b fe 65 8b 05 f6 49 83 7d 85 c0 > 75 05 e8 > 84 70 81 fe b8 00 00 50 c3 31 d2 48 8d 7b 10 f5 41 89 c4 e8 58 07 a2 fe > 44 89 63 10 48 8d 7b 08 > e8 cb 07 a2 > RSP: :888100137dc8 EFLAGS: 00010246 > RAX: c350 RBX: 823f0160 RCX: > RDX: RSI: 0808 RDI: 823f0170 > RBP: R08: 8109c50f R09: 824bb6f7 > R10: fbfff04976de R11: 0001 R12: > R13: 888101997000 R14: 888101994000 R15: 823f0178 > FS: () GS:8881f778() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: CR3: 0220e000 CR4: 06a0 > Call Trace: > calibrate_xor_blocks+0x13c/0x1c4 > ? do_xor_speed+0xf3/0xf3 > do_one_initcall+0xc1/0x1b7 > ? start_kernel+0x373/0x373 > ? unpoison_range+0x3a/0x60 > kernel_init_freeable+0x1dd/0x238 > ? rest_init+0xc6/0xc6 > kernel_init+0x8/0x10a > ret_from_fork+0x1f/0x30 > ---[ end trace 5bd3c1d0b2da ]--- > > Fixes: c055e3eae0f1 ("crypto: xor - use ktime for template benchmarking") > Signed-off-by: Kirill Tkhai > Acked-by: Ard Biesheuvel > --- > > v2: New Year resend :) Added fixes tag. > crypto/xor.c |2 ++ > 1 file changed, 2 insertions(+) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] of: property: Add device link support for interrupts
On Thu, Jan 7, 2021 at 7:36 PM Rob Herring wrote: > > On Thu, Jan 7, 2021 at 4:13 PM Saravana Kannan wrote: > > > > On Thu, Jan 7, 2021 at 11:33 AM Rob Herring wrote: > > > > > > On Thu, Jan 7, 2021 at 12:09 PM Saravana Kannan > > > wrote: > > > > > > > > On Thu, Jan 7, 2021 at 10:39 AM Rob Herring wrote: > > > > > > > > > > On Wed, Jan 6, 2021 at 11:53 AM Saravana Kannan > > > > > wrote: > > > > > > > > > > > > On Sat, Jan 2, 2021 at 3:37 AM Marc Zyngier wrote: > > > > > > > > > > > > > > On Thu, 31 Dec 2020 21:12:40 +, > > > > > > > Rob Herring wrote: > > > > > > > > > > > > > > > > On Mon, Dec 21, 2020 at 09:30:45AM +, Marc Zyngier wrote: > > > > > > > > > On 2020-12-18 21:07, Saravana Kannan wrote: > > > > > > > > > > Add support for creating device links out of interrupts > > > > > > > > > > property. > > > > > > > > > > > > > > > > > > > > Cc: Marc Zyngier > > > > > > > > > > Cc: Kevin Hilman > > > > > > > > > > Signed-off-by: Saravana Kannan > > > > > > > > > > --- > > > > > > > > > > Rob/Greg, > > > > > > > > > > > > > > > > > > > > This might need to go into driver-core to avoid conflict > > > > > > > > > > due to fw_devlink refactor series that merged there. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Saravana > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > drivers/of/property.c | 17 + > > > > > > > > > > 1 file changed, 17 insertions(+) > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/of/property.c b/drivers/of/property.c > > > > > > > > > > index 5f9eed79a8aa..e56a5eae0a0b 100644 > > > > > > > > > > --- a/drivers/of/property.c > > > > > > > > > > +++ b/drivers/of/property.c > > > > > > > > > > @@ -1271,6 +1271,22 @@ static struct device_node > > > > > > > > > > *parse_iommu_maps(struct device_node *np, > > > > > > > > > > return of_parse_phandle(np, prop_name, (index * 4) + 1); > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > +static struct device_node *parse_interrupts(struct > > > > > > > > > > device_node *np, > > > > > > > > > > + const char > > > > > > > > > > *prop_name, int index) > > > > > > > > > > +{ > > > > > > > > > > + struct device_node *sup; > > > > > > > > > > + > > > > > > > > > > + if (strcmp(prop_name, "interrupts") || index) > > > > > > > > > > + return NULL; > > > > > > > > > > + > > > > > > > > > > + of_node_get(np); > > > > > > > > > > + while (np && !(sup = of_parse_phandle(np, > > > > > > > > > > "interrupt-parent", 0))) > > > > > > > > > > + np = of_get_next_parent(np); > > > > > > > > > > + of_node_put(np); > > > > > > > > > > + > > > > > > > > > > + return sup; > > > > > > > > > > +} > > > > > > > > > > + > > > > > > > > > > static const struct supplier_bindings > > > > > > > > > > of_supplier_bindings[] = { > > > > > > > > > > { .parse_prop = parse_clocks, }, > > > > > > > > > > { .parse_prop = parse_interconnects, }, > > > > > > > > > > @@ -1296,6 +1312,7 @@ static const struct supplier_bindings > > > > > > > > > > of_supplier_bindings[] = { > > > > > > > > > > { .parse_prop = parse_pinctrl6, }, > > > > > > > > > > { .parse_prop = parse_pinctrl7, }, > > > > > > > > > > { .parse_prop = parse_pinctrl8, }, > > > > > > > > > > + { .parse_prop = parse_interrupts, }, > > > > > > > > > > { .parse_prop = parse_regulators, }, > > > > > > > > > > { .parse_prop = parse_gpio, }, > > > > > > > > > > { .parse_prop = parse_gpios, }, > > > > > > > > > > > > > > > > > > You don't really describe what this is for so I'm only > > > > > > > > > guessing > > > > > > > > > from the context. If you want to follow the interrupt > > > > > > > > > hierarchy, > > > > > > > > > "interrupt-parent" isn't enough. You also need to track > > > > > > > > > things like interrupt-map, or anything that carries a phandle > > > > > > > > > to an interrupt controller. > > > > > > > > > > > > > > > > We don't need to follow the hierarchy, we just need the > > > > > > > > immediate > > > > > > > > dependencies. > > > > > > > > > > > > > > Indeed. I also wonder why this isn't just a irq_find_parent() > > > > > > > call, TBH. > > > > > > > > > > > > Thanks Rob for explaining it. > > > > > > > > > > > > Marc, I wasn't sure if Rob would be okay with including of_irq.h > > > > > > here. > > > > > > Also, I'm trying to keep of/property.c independent of the framework > > > > > > code for now. The long term goal is to see if I can move out most of > > > > > > this into the frameworks. But I want to do that after I sort of some > > > > > > of the larger problems (like getting fw_devlink=on to work on all > > > > > > devices first). Let me know if you have a strong preference for > > > > > > right > > > > > > now, if not, I'd rather keep property.c independent for now. > > > > > > > > > > > > I wasn't aware of interrupt-map until a few weeks ago and didn't > > > > > > know > > > > > > it carried phandles. I can add support for that to
Re: [PATCH] mpt3sas: fix spelling mistake in Kconfig: "compatiblity" -> "compatibility"
On Thu, 17 Dec 2020 17:20:19 +, Colin King wrote: > There is a spelling mistake in the Kconfig help text. Fix it. Applied to 5.11/scsi-fixes, thanks! [1/1] mpt3sas: fix spelling mistake in Kconfig: "compatiblity" -> "compatibility" https://git.kernel.org/mkp/scsi/c/39718fe7adb1 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH V2] docs: ABI: sysfs-driver-ufs: Add DeepSleep power mode
On Mon, 4 Jan 2021 17:50:26 +0200, Adrian Hunter wrote: > Update sysfs documentation for addition of DeepSleep power mode. Applied to 5.11/scsi-fixes, thanks! [1/1] docs: ABI: sysfs-driver-ufs: Add DeepSleep power mode https://git.kernel.org/mkp/scsi/c/0b2894cd0fdf -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v2 0/2] scsi: ufs: Fix power drain and hci quirk for WriteBooster
On Tue, 22 Dec 2020 15:29:03 +0800, Stanley Chu wrote: > This series fixes two WriteBooster issues, > 1. Fix a corner case that device flush capability is not disabled during > system suspend > 2. Fix the checking of UFSHCI quirk UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL > > Stanley Chu (2): > scsi: ufs: Fix possible power drain during system suspend > scsi: ufs: Relax the condition of > UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL > > [...] Applied to 5.11/scsi-fixes, thanks! [1/2] scsi: ufs: Fix possible power drain during system suspend https://git.kernel.org/mkp/scsi/c/1d53864c3617 [2/2] scsi: ufs: Relax the condition of UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL https://git.kernel.org/mkp/scsi/c/21acf4601cc6 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] ibmvfc: fix missing cast of ibmvfc_event pointer to u64 handle
On Wed, 6 Jan 2021 14:37:21 -0600, Tyrel Datwyler wrote: > Commit 2aa0102c6688 ("scsi: ibmvfc: Use correlation token to tag > commands") sets the vfcFrame correlation token to the pointer handle of > the associated ibmvfc_event. However, that commit failed to cast the > pointer to an appropriate type which in this case is a u64. As such > sparse warnings are generated for both correlation token assignments. > > ibmvfc.c:2375:36: sparse: incorrect type in argument 1 (different base types) > ibmvfc.c:2375:36: sparse: expected unsigned long long [usertype] val > ibmvfc.c:2375:36: sparse: got struct ibmvfc_event *[assigned] evt > > [...] Applied to 5.11/scsi-fixes, thanks! [1/1] ibmvfc: fix missing cast of ibmvfc_event pointer to u64 handle https://git.kernel.org/mkp/scsi/c/901d01c8e50c -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v5 0/2] Two UFS fixes
On Thu, 7 Jan 2021 10:53:14 -0800, Jaegeuk Kim wrote: > Change log from v4: > - remove RESERVE tag for tm command > - remove waiting IOs and let full reset handle it > - avoid verbose error log which causes cpu lock up Applied to 5.11/scsi-fixes, thanks! [1/2] scsi: ufs: fix livelock of ufshcd_clear_ua_wluns https://git.kernel.org/mkp/scsi/c/4ee7ee530bc2 [2/2] scsi: ufs: fix tm request correctly when non-fatal error happens https://git.kernel.org/mkp/scsi/c/eeb1b55b6e25 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: ufs: ufshcd-pltfrm depends on HAS_IOMEM
On Tue, 5 Jan 2021 20:08:22 -0800, Randy Dunlap wrote: > Building ufshcd-pltfrm.c on arch/s390/ has a linker error since > S390 does not support IOMEM, so add a dependency on HAS_IOMEM. > > s390-linux-ld: drivers/scsi/ufs/ufshcd-pltfrm.o: in function > `ufshcd_pltfrm_init': > ufshcd-pltfrm.c:(.text+0x38e): undefined reference to > `devm_platform_ioremap_resource' > > where that devm_ function is inside an #ifdef CONFIG_HAS_IOMEM/#endif block. Applied to 5.11/scsi-fixes, thanks! [1/1] scsi: ufs: ufshcd-pltfrm depends on HAS_IOMEM https://git.kernel.org/mkp/scsi/c/5e6ddadf7637 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: megaraid_sas: Fix MEGASAS_IOC_FIRMWARE regression
On Tue, 5 Jan 2021 00:41:04 +0100, Arnd Bergmann wrote: > Phil Oester reported that a fix for a possible buffer overrun that I > sent caused a regression that manifests in this output: > > Event Message: A PCI parity error was detected on a component at bus 0 > device 5 function 0. > Severity: Critical > Message ID: PCI1308 > > [...] Applied to 5.11/scsi-fixes, thanks! [1/1] scsi: megaraid_sas: Fix MEGASAS_IOC_FIRMWARE regression https://git.kernel.org/mkp/scsi/c/b112036535ed -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: ufs: Correct the lun used in eh_device_reset_handler() callback
On Mon, 28 Dec 2020 04:04:36 -0800, Can Guo wrote: > Users can initiate resets to specific SCSI device/target/host through > IOCTL. When this happens, the SCSI cmd passed to eh_device/target/host > _reset_handler() callbacks is initialized with a request whose tag is -1. > So, in this case, it is not right for eh_device_reset_handler() callback > to count on the lun get from hba->lrb[-1]. Fix it by getting lun from the > SCSI device associated with the SCSI cmd. Applied to 5.11/scsi-fixes, thanks! [1/1] scsi: ufs: Correct the lun used in eh_device_reset_handler() callback https://git.kernel.org/mkp/scsi/c/35fc4cd34426 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v2] scsi: sd: remove obsolete variable in sd_remove()
On Mon, 14 Dec 2020 10:54:24 +0100, Lukas Bulwahn wrote: > Commit 140ea3bbf39a ("sd: use __register_blkdev to avoid a modprobe for an > unregistered dev_t") removed blk_register_region(devt, ...) in sd_remove() > and since then, devt is unused in sd_remove(). > > Hence, make W=1 warns: > > drivers/scsi/sd.c:3516:8: > warning: variable 'devt' set but not used [-Wunused-but-set-variable] > > [...] Applied to 5.11/scsi-fixes, thanks! [1/1] scsi: sd: remove obsolete variable in sd_remove() https://git.kernel.org/mkp/scsi/c/be2553358cd4 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] [v2] scsi: scsi_debug: Fix memleak in scsi_debug_init
On Sat, 26 Dec 2020 14:15:03 +0800, Dinghao Liu wrote: > When sdeb_zbc_model does not match BLK_ZONED_NONE, > BLK_ZONED_HA or BLK_ZONED_HM, we should free sdebug_q_arr > to prevent memleak. Also there is no need to execute > sdebug_erase_store() on failure of sdeb_zbc_model_str(). Applied to 5.11/scsi-fixes, thanks! [1/1] scsi: scsi_debug: Fix memleak in scsi_debug_init https://git.kernel.org/mkp/scsi/c/3b01d7ea4dae -- Martin K. Petersen Oracle Linux Engineering
[PATCH v2] tracing/kprobes: Do the notrace functions check without kprobes on ftrace
Enable the notrace function check on the architecture which doesn't support kprobes on ftrace but support dynamic ftrace. This notrace function check is not only for the kprobes on ftrace but also sw-breakpoint based kprobes. Thus there is no reason to limit this check for the arch which supports kprobes on ftrace. This also changes the dependency of Kconfig. Because kprobe event uses the function tracer's address list for identifying notrace function, if the CONFIG_DYNAMIC_FTRACE=n, it can not check whether the target function is notrace or not. Signed-off-by: Masami Hiramatsu Acked-by: Naveen N. Rao --- Changes in v2: - Depends on CONFIG_DYNAMIC_FTRACE instead of CONFIG_FUNCTION_TRACER --- kernel/trace/Kconfig|2 +- kernel/trace/trace_kprobe.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig index fe60f9d7a0e6..18da5e8e28fb 100644 --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -540,7 +540,7 @@ config KPROBE_EVENTS config KPROBE_EVENTS_ON_NOTRACE bool "Do NOT protect notrace function from kprobe events" depends on KPROBE_EVENTS - depends on KPROBES_ON_FTRACE + depends on DYNAMIC_FTRACE default n help This is only for the developers who want to debug ftrace itself diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c index b29f92c51b1a..5fff39541b8a 100644 --- a/kernel/trace/trace_kprobe.c +++ b/kernel/trace/trace_kprobe.c @@ -434,7 +434,7 @@ static int disable_trace_kprobe(struct trace_event_call *call, return 0; } -#if defined(CONFIG_KPROBES_ON_FTRACE) && \ +#if defined(CONFIG_DYNAMIC_FTRACE) && \ !defined(CONFIG_KPROBE_EVENTS_ON_NOTRACE) static bool __within_notrace_func(unsigned long addr) {
Re: [PATCH] tracing/kprobes: Do the notrace functions check without kprobes on ftrace
On Thu, 7 Jan 2021 09:13:30 -0500 Steven Rostedt wrote: > On Wed, 6 Jan 2021 12:20:40 +0900 > Masami Hiramatsu wrote: > > > Enable the notrace function check on the architecture which doesn't > > support kprobes on ftrace. This notrace function check is not only > > for the kprobes on ftrace but also sw-breakpoint based kprobes. > > Thus there is no reason to limit this check for the arch which > > supports kprobes on ftrace. > > > > This also changes the dependency of Kconfig. Because kprobe event > > uses the function tracer's address list for identifying notrace > > function, if the CONFIG_FUNCTION_TRACER=n, it can not check whether > > the target function is notrace or not. > > > > Signed-off-by: Masami Hiramatsu > > Acked-by: Naveen N. Rao > > --- > > Fails to build with: > > kernel/trace/trace_kprobe.c: In function ‘__within_notrace_func’: > kernel/trace/trace_kprobe.c:453:10: error: implicit declaration of function > ‘ftrace_location_range’; did you mean ‘ftrace_location’? > [-Werror=implicit-function-declaration] > 453 | return !ftrace_location_range(addr, addr + size - 1); > | ^ > | ftrace_location > Oops, it depends on CONFIG_DYNAMIC_FTRACE=y instead of CONFIG_FUNCTION_TRACER. Thank you, -- Masami Hiramatsu