August 2023 - Linux-stable-mirror

[PATCH 03/21] drm/amd/display: Add smu write msg id fail retry process

by Hamza Mahfooz

From: Fudong Wang <fudong.wang(a)amd.com> A benchmark stress test (12-40 machines x 48hours) found that DCN315 has cases where DC writes to an indirect register to set the smu clock msg id, but when we go to read the same indirect register the returned msg id doesn't match with what we just set it to. So, to fix this retry the write until the register's value matches with the requested value. Cc: stable(a)vger.kernel.org # 6.1+ Fixes: f94903996140 ("drm/amd/display: Add DCN315 CLK_MGR") Reviewed-by: Charlene Liu <charlene.liu(a)amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz(a)amd.com> Signed-off-by: Fudong Wang <fudong.wang(a)amd.com> --- .../display/dc/clk_mgr/dcn315/dcn315_smu.c | 20 +++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_smu.c b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_smu.c index 3e0da873cf4c..1042cf1a3ab0 100644 --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_smu.c +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_smu.c @@ -32,6 +32,7 @@ #define MAX_INSTANCE 6 #define MAX_SEGMENT 6 +#define SMU_REGISTER_WRITE_RETRY_COUNT 5 struct IP_BASE_INSTANCE { unsigned int segment[MAX_SEGMENT]; @@ -132,6 +133,8 @@ static int dcn315_smu_send_msg_with_param( unsigned int msg_id, unsigned int param) { uint32_t result; + uint32_t i = 0; + uint32_t read_back_data; result = dcn315_smu_wait_for_response(clk_mgr, 10, 200000); @@ -148,10 +151,19 @@ static int dcn315_smu_send_msg_with_param( /* Set the parameter register for the SMU message, unit is Mhz */ REG_WRITE(MP1_SMN_C2PMSG_37, param); - /* Trigger the message transaction by writing the message ID */ - generic_write_indirect_reg(CTX, - REG_NBIO(RSMU_INDEX), REG_NBIO(RSMU_DATA), - mmMP1_C2PMSG_3, msg_id); + for (i = 0; i < SMU_REGISTER_WRITE_RETRY_COUNT; i++) { + /* Trigger the message transaction by writing the message ID */ + generic_write_indirect_reg(CTX, + REG_NBIO(RSMU_INDEX), REG_NBIO(RSMU_DATA), + mmMP1_C2PMSG_3, msg_id); + read_back_data = generic_read_indirect_reg(CTX, + REG_NBIO(RSMU_INDEX), REG_NBIO(RSMU_DATA), + mmMP1_C2PMSG_3); + if (read_back_data == msg_id) + break; + udelay(2); + smu_print("SMU msg id write fail %x times. \n", i + 1); + } result = dcn315_smu_wait_for_response(clk_mgr, 10, 200000); -- 2.41.0

1 year, 9 months

1
0
0 0

[PATCH v2 0/2] ath11k: Don't leak ack_status_frame during tx_complete* processing

by Sven Eckelmann

It was noticed that APs stopped to accept clients after a while. With QCA's ath11k fork, it even printed some additional information: attach ack fail -28 when new clients tried to connect. hostapd was then usually showing a message like "deauthenticated due to inactivity (timer DEAUTH/REMOVE)". While debugging this, it was noticed that this happened when a peer was no longer known by ath11k but an NL80211_CMD_PROBE_CLIENT triggered TX was just "finished" for it. In that case, ath11k was just throwing the skb away and left some information in various data structures in mac80211. And after Felix pointed out ieee80211_free_txskb(), it is also clear that dev_kfree_skb_any() in these functions should also be calls to ieee80211_free_txskb() - but for these, I have nothing to trigger this error case. Still, a patch is provided as part of this patch series. Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- Changes in v2: - Simply switch to ieee80211_free_txskb() as recommended by Felix Fietkau + ieee80211_free_txskb calls ieee80211_report_used_skb + ieee80211_report_used_skb calls ieee80211_report_ack_skb (when ack_frame_id is set and !IEEE80211_TX_INTFL_MLME_CONN_TX) + ieee80211_report_ack_skb will remove skb from ack_status_frames - Add second patch which handles similar situations in the previously patched functions - Link to v1: https://lore.kernel.org/r/20230801-ath11k-ack_status_leak-v1-1-539cb72c55bc… --- Sven Eckelmann (2): ath11k: Don't drop tx_status when peer cannot be found ath11k: Cleanup mac80211 references on failure during tx_complete drivers/net/wireless/ath/ath11k/dp_tx.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- base-commit: 1d7dd5aa35474e553b8671b58579e0749b560779 change-id: 20230801-ath11k-ack_status_leak-70a7a30e5d9f Best regards, -- Sven Eckelmann <sven(a)narfation.org>

1 year, 9 months

2
3
0 0

[PATCH net v2] net: handle ARPHRD_PPP in dev_is_mac_header_xmit()

by Nicolas Dichtel

This kind of interface doesn't have a mac header. This patch fixes bpf_redirect() to a ppp interface. CC: stable(a)vger.kernel.org Fixes: 27b29f63058d ("bpf: add bpf_redirect() helper") Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> Tested-by: Siwar Zitouni <siwar.zitouni(a)6wind.com> --- v1 -> v2: - I forgot the 'Tested-by' tag in the v1 :/ include/linux/if_arp.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/if_arp.h b/include/linux/if_arp.h index 1ed52441972f..8efbe29a6f0c 100644 --- a/include/linux/if_arp.h +++ b/include/linux/if_arp.h @@ -53,6 +53,7 @@ static inline bool dev_is_mac_header_xmit(const struct net_device *dev) case ARPHRD_NONE: case ARPHRD_RAWIP: case ARPHRD_PIMREG: + case ARPHRD_PPP: return false; default: return true; -- 2.39.2

1 year, 9 months

2
7
0 0

[PATCH v1] tcpm: Avoid soft reset when partner does not support get_status

by Badhri Jagan Sridharan

When partner does not support get_status message, tcpm right now responds with soft reset message. This causes PD renegotiation to happen and resets PPS link. Avoid soft resetting the link when partner does not support get_status message to mitigate PPS resets. [ 208.926752] Setting voltage/current limit 9500 mV 2450 mA [ 208.930407] set_auto_vbus_discharge_threshold mode:3 pps_active:y vbus:9500 ret:0 [ 208.930418] state change SNK_TRANSITION_SINK -> SNK_READY [rev3 POWER_NEGOTIATION] [ 208.930455] AMS POWER_NEGOTIATION finished // ALERT message from the Source [ 213.948442] PD RX, header: 0x19a6 [1] [ 213.948451] state change SNK_READY -> GET_STATUS_SEND [rev3 GETTING_SOURCE_SINK_STATUS] [ 213.948457] PD TX, header: 0x492 [ 213.950402] PD TX complete, status: 0 [ 213.950427] pending state change GET_STATUS_SEND -> GET_STATUS_SEND_TIMEOUT @ 60 ms [rev3 GETTING_SOURCE_SINK_STATUS] // NOT_SUPPORTED from the Source [ 213.959954] PD RX, header: 0xbb0 [1] // sink sends SOFT_RESET [ 213.959958] state change GET_STATUS_SEND -> SNK_SOFT_RESET [rev3 GETTING_SOURCE_SINK_STATUS] [ 213.959962] AMS GETTING_SOURCE_SINK_STATUS finished [ 213.959964] AMS SOFT_RESET_AMS start [ 213.959966] state change SNK_SOFT_RESET -> AMS_START [rev3 SOFT_RESET_AMS] [ 213.959969] state change AMS_START -> SOFT_RESET_SEND [rev3 SOFT_RESET_AMS] Cc: stable(a)vger.kernel.org Fixes: 8dea75e11380 ("usb: typec: tcpm: Protocol Error handling") Signed-off-by: Badhri Jagan Sridharan <badhri(a)google.com> --- drivers/usb/typec/tcpm/tcpm.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 5639b9a1e0bf..280ce1bd7b53 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -2753,6 +2753,13 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port, port->sink_cap_done = true; tcpm_set_state(port, ready_state(port), 0); break; + /* + * Some port partners do not support GET_STATUS, avoid soft reset the link to + * prevent redundant power re-negotiation + */ + case GET_STATUS_SEND: + tcpm_set_state(port, ready_state(port), 0); + break; case SRC_READY: case SNK_READY: if (port->vdm_state > VDM_STATE_READY) { base-commit: bbb9e06d2c6435af9c62074ad7048910eeb2e7bc -- 2.42.0.rc1.204.g551eb34607-goog

1 year, 9 months

3
2
0 0

[PATCH v5] riscv: Handle zicsr/zifencei issue between gcc and binutils

by Mingzheng Xing

Binutils-2.38 and GCC-12.1.0 bumped[0][1] the default ISA spec to the newer 20191213 version which moves some instructions from the I extension to the Zicsr and Zifencei extensions. So if one of the binutils and GCC exceeds that version, we should explicitly specifying Zicsr and Zifencei via -march to cope with the new changes. but this only occurs when binutils >= 2.36 and GCC >= 11.1.0. It's a different story when binutils < 2.36. binutils-2.36 supports the Zifencei extension[2] and splits Zifencei and Zicsr from I[3]. GCC-11.1.0 is particular[4] because it add support Zicsr and Zifencei extension for -march. binutils-2.35 does not support the Zifencei extension, and does not need to specify Zicsr and Zifencei when working with GCC >= 12.1.0. To make our lives easier, let's relax the check to binutils >= 2.36 in CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI. For the other two cases, where clang < 17 or GCC < 11.1.0, we will deal with them in CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC. For more information, please refer to: commit 6df2a016c0c8 ("riscv: fix build with binutils 2.38") commit e89c2e815e76 ("riscv: Handle zicsr/zifencei issues between clang and binutils") Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae871… [0] Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76bab51… [1] Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=5a1b31e1e1cee6e9f… [2] Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=729a53530e86972d1… [3] Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b03be74bad08c382da47e048007a7… [4] Link: https://lore.kernel.org/all/20230308220842.1231003-1-conor@kernel.org Link: https://lore.kernel.org/all/20230223220546.52879-1-conor@kernel.org Reviewed-by: Conor Dooley <conor.dooley(a)microchip.com> Acked-by: Guo Ren <guoren(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Mingzheng Xing <xingmingzheng(a)iscas.ac.cn> --- Changelog and test results: v4 -> v5: - Add Reviewed-by and Acked-by to commit message, no other code changes. v3 -> v4: - Update the Kconfig help text and commit message. Link: https://lore.kernel.org/all/20230731150511.38140-1-xingmingzheng@iscas.ac.cn v2 -> v3: - Relax the check to binutils >= 2.36. - Update the Kconfig help text and commit message. Link: https://lore.kernel.org/all/20230731095936.23397-1-xingmingzheng@iscas.ac.cn v1 -> v2: - Update the Kconfig help text and commit message. - Add considerations for low version gcc case. Link: https://lore.kernel.org/all/20230726174524.340952-1-xingmingzheng@iscas.ac.… v1: Link: https://lore.kernel.org/all/20230725170405.251011-1-xingmingzheng@iscas.ac.… Here are my test results: * Compiling the kernel for the master branch with a combination of multiple versions of gcc and binutils. gcc binutils patched no patch 11.4.0 2.35 ok ok 11.4.0 2.36 ok ok 11.4.0 2.38 ok ok 12.2.0 2.35 ok error[1] 12.2.0 2.36 ok error[2] 12.2.0 2.38 ok ok 10.5.0 2.35 ok ok 10.5.0 2.36 ok ok 10.5.0 2.38 ok error[3] 11.1.0 2.35 ok ok 11.1.0 2.36 ok ok 11.1.0 2.38 ok ok 11.2.0 2.35 ok ok 11.2.0 2.36 ok ok 11.2.0 2.38 ok ok [1] Assembler messages: Fatal error: -march=rv32imafd_zicsr_zifencei: Invalid or unknown z ISA extension: 'zifencei' make[2]: *** [arch/riscv/kernel/compat_vdso/Makefile:47: arch/riscv/kernel/compat_vdso/rt_sigreturn.o] Error 1 [2] ./arch/riscv/include/asm/vdso/gettimeofday.h: Assembler messages: ./arch/riscv/include/asm/vdso/gettimeofday.h:79: Error: unrecognized opcode `csrr a5,0xc01' ./arch/riscv/include/asm/vdso/gettimeofday.h:79: Error: unrecognized opcode `csrr a5,0xc01' ./arch/riscv/include/asm/vdso/gettimeofday.h:79: Error: unrecognized opcode `csrr a5,0xc01' ./arch/riscv/include/asm/vdso/gettimeofday.h:79: Error: unrecognized opcode `csrr a5,0xc01' make[2]: *** [scripts/Makefile.build:243: arch/riscv/kernel/vdso/vgettimeofday.o] Error 1 [3] cc1: error: '-march=rv64imac_zicsr_zifencei': unsupported ISA subset 'z' cc1: error: ABI requires '-march=rv64' make[2]: *** [scripts/Makefile.build:243: scripts/mod/empty.o] Error 1 make[2]: *** Waiting for unfinished jobs.... cc1: error: '-march=rv64imac_zicsr_zifencei': unsupported ISA subset 'z' cc1: error: ABI requires '-march=rv64' arch/riscv/Kconfig | 32 +++++++++++++++----------- arch/riscv/kernel/compat_vdso/Makefile | 8 ++++++- 2 files changed, 26 insertions(+), 14 deletions(-) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index f52dd125ac5e..ce3a6667cfdb 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -570,24 +570,30 @@ config TOOLCHAIN_HAS_ZIHINTPAUSE config TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI def_bool y # https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae871… - depends on AS_IS_GNU && AS_VERSION >= 23800 - help - Newer binutils versions default to ISA spec version 20191213 which - moves some instructions from the I extension to the Zicsr and Zifencei - extensions. + # https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76bab51… + depends on AS_IS_GNU && AS_VERSION >= 23600 + help + Binutils-2.38 and GCC-12.1.0 bumped the default ISA spec to the newer + 20191213 version, which moves some instructions from the I extension to + the Zicsr and Zifencei extensions. This requires explicitly specifying + Zicsr and Zifencei when binutils >= 2.38 or GCC >= 12.1.0. Zicsr + and Zifencei are supported in binutils from version 2.36 onwards. + To make life easier, and avoid forcing toolchains that default to a + newer ISA spec to version 2.2, relax the check to binutils >= 2.36. + For clang < 17 or GCC < 11.1.0, for which this is not possible, this is + dealt with in CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC. config TOOLCHAIN_NEEDS_OLD_ISA_SPEC def_bool y depends on TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI # https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694… - depends on CC_IS_CLANG && CLANG_VERSION < 170000 - help - Certain versions of clang do not support zicsr and zifencei via -march - but newer versions of binutils require it for the reasons noted in the - help text of CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI. This - option causes an older ISA spec compatible with these older versions - of clang to be passed to GAS, which has the same result as passing zicsr - and zifencei to -march. + # https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b03be74bad08c382da47e048007a7… + depends on (CC_IS_CLANG && CLANG_VERSION < 170000) || (CC_IS_GCC && GCC_VERSION < 110100) + help + Certain versions of clang and GCC do not support zicsr and zifencei via + -march. This option causes an older ISA spec compatible with these older + versions of clang and GCC to be passed to GAS, which has the same result + as passing zicsr and zifencei to -march. config FPU bool "FPU support" diff --git a/arch/riscv/kernel/compat_vdso/Makefile b/arch/riscv/kernel/compat_vdso/Makefile index 189345773e7e..b86e5e2c3aea 100644 --- a/arch/riscv/kernel/compat_vdso/Makefile +++ b/arch/riscv/kernel/compat_vdso/Makefile @@ -11,7 +11,13 @@ compat_vdso-syms += flush_icache COMPAT_CC := $(CC) COMPAT_LD := $(LD) -COMPAT_CC_FLAGS := -march=rv32g -mabi=ilp32 +# binutils 2.35 does not support the zifencei extension, but in the ISA +# spec 20191213, G stands for IMAFD_ZICSR_ZIFENCEI. +ifdef CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI + COMPAT_CC_FLAGS := -march=rv32g -mabi=ilp32 +else + COMPAT_CC_FLAGS := -march=rv32imafd -mabi=ilp32 +endif COMPAT_LD_FLAGS := -melf32lriscv # Disable attributes, as they're useless and break the build. -- 2.34.1

1 year, 9 months

3
2
0 0

[PATCH v2] usb: typec: tcpm: set initial svdm version based on pd revision

by RD Babiera

When sending Discover Identity messages to a Port Partner that uses Power Delivery v2 and SVDM v1, we currently send PD v2 messages with SVDM v2.0, expecting the port partner to respond with its highest supported SVDM version as stated in Section 6.4.4.2.3 in the Power Delivery v3 specification. However, sending SVDM v2 to some Power Delivery v2 port partners results in a NAK whereas sending SVDM v1 does not. NAK messages can be handled by the initiator (PD v3 section 6.4.4.2.5.1), and one solution could be to resend Discover Identity on a lower SVDM version if possible. But, Section 6.4.4.3 of PD v2 states that "A NAK response Should be taken as an indication not to retry that particular Command." Instead, we can set the SVDM version to the maximum one supported by the negotiated PD revision. When operating in PD v2, this obeys Section 6.4.4.2.3, which states the SVDM field "Shall be set to zero to indicate Version 1.0." In PD v3, the SVDM field "Shall be set to 01b to indicate Version 2.0." Fixes: c34e85fa69b9 ("usb: typec: tcpm: Send DISCOVER_IDENTITY from dedicated work") Cc: stable(a)vger.kernel.org Signed-off-by: RD Babiera <rdbabiera(a)google.com> --- Changes since v1: * Fixed styling errors. --- drivers/usb/typec/tcpm/tcpm.c | 35 +++++++++++++++++++++++++++++++---- 1 file changed, 31 insertions(+), 4 deletions(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 829d75ebab42..5024354a0fe0 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -3928,6 +3928,29 @@ static enum typec_cc_status tcpm_pwr_opmode_to_rp(enum typec_pwr_opmode opmode) } } +static void tcpm_set_initial_svdm_version(struct tcpm_port *port) +{ + switch (port->negotiated_rev) { + case PD_REV30: + break; + /* + * 6.4.4.2.3 Structured VDM Version + * 2.0 states "At this time, there is only one version (1.0) defined. + * This field Shall be set to zero to indicate Version 1.0." + * 3.0 states "This field Shall be set to 01b to indicate Version 2.0." + * To ensure that we follow the Power Delivery revision we are currently + * operating on, downgrade the SVDM version to the highest one supported + * by the Power Delivery revision. + */ + case PD_REV20: + typec_partner_set_svdm_version(port->partner, SVDM_VER_1_0); + break; + default: + typec_partner_set_svdm_version(port->partner, SVDM_VER_1_0); + break; + } +} + static void run_state_machine(struct tcpm_port *port) { int ret; @@ -4165,10 +4188,12 @@ static void run_state_machine(struct tcpm_port *port) * For now, this driver only supports SOP for DISCOVER_IDENTITY, thus using * port->explicit_contract to decide whether to send the command. */ - if (port->explicit_contract) + if (port->explicit_contract) { + tcpm_set_initial_svdm_version(port); mod_send_discover_delayed_work(port, 0); - else + } else { port->send_discover = false; + } /* * 6.3.5 @@ -4455,10 +4480,12 @@ static void run_state_machine(struct tcpm_port *port) * For now, this driver only supports SOP for DISCOVER_IDENTITY, thus using * port->explicit_contract. */ - if (port->explicit_contract) + if (port->explicit_contract) { + tcpm_set_initial_svdm_version(port); mod_send_discover_delayed_work(port, 0); - else + } else { port->send_discover = false; + } power_supply_changed(port->psy); break; base-commit: fdf0eaf11452d72945af31804e2a1048ee1b574c -- 2.41.0.585.gd2178a4bd4-goog

1 year, 9 months

3
5
0 0

Bezpłatna konsultacja

by Grzegorz Frycz

Dzień dobry, czy konsultowali Państwo swoją umowę ubezpieczeniową z niezależnym doradcą? Większość moich Klientów, dotychczas nie była świadoma, jak bardzo przepłacają za polisy. Jako specjalista niepowiązany z żadną organizacja ubezpieczeniową bezpłatnie przeanalizuję Państwa rozwiązania finansowe i zarekomenduję najkorzystniejsze na rynku alternatywy, które pozwolą zmniejszyć dotychczasowe koszty przy jednocześnie zwiększonej ochronie. Byliby Państwo zainteresowani? Pozdrawiam Grzegorz Frycz

1 year, 9 months

1
0
0 0

[git:media_stage/fixes] media: vcodec: Fix potential array out-of-bounds in encoder queue_setup

by Hans Verkuil

This is an automatic generated email to let you know that the following patch were queued: Subject: media: vcodec: Fix potential array out-of-bounds in encoder queue_setup Author: Wei Chen <harperchen1110(a)gmail.com> Date: Thu Aug 10 08:23:33 2023 +0000 variable *nplanes is provided by user via system call argument. The possible value of q_data->fmt->num_planes is 1-3, while the value of *nplanes can be 1-8. The array access by index i can cause array out-of-bounds. Fix this bug by checking *nplanes against the array size. Fixes: 4e855a6efa54 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver") Signed-off-by: Wei Chen <harperchen1110(a)gmail.com> Cc: stable(a)vger.kernel.org Reviewed-by: Chen-Yu Tsai <wenst(a)chromium.org> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c | 2 ++ 1 file changed, 2 insertions(+) --- diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c index 9ff439a50f53..315e97a2450e 100644 --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c @@ -821,6 +821,8 @@ static int vb2ops_venc_queue_setup(struct vb2_queue *vq, return -EINVAL; if (*nplanes) { + if (*nplanes != q_data->fmt->num_planes) + return -EINVAL; for (i = 0; i < *nplanes; i++) if (sizes[i] < q_data->sizeimage[i]) return -EINVAL;

1 year, 9 months

1
0
0 0

[PATCH v2 bpf-next 1/2] bpf: Fix issue in verifying allow_ptr_leaks

by Yafang Shao

After we converted the capabilities of our networking-bpf program from cap_sys_admin to cap_net_admin+cap_bpf, our networking-bpf program failed to start. Because it failed the bpf verifier, and the error log is "R3 pointer comparison prohibited". A simple reproducer as follows, SEC("cls-ingress") int ingress(struct __sk_buff *skb) { struct iphdr *iph = (void *)(long)skb->data + sizeof(struct ethhdr); if ((long)(iph + 1) > (long)skb->data_end) return TC_ACT_STOLEN; return TC_ACT_OK; } Per discussion with Yonghong and Alexei [1], comparison of two packet pointers is not a pointer leak. This patch fixes it. Our local kernel is 6.1.y and we expect this fix to be backported to 6.1.y, so stable is CCed. [1]. https://lore.kernel.org/bpf/CAADnVQ+Nmspr7Si+pxWn8zkE7hX-7s93ugwC+94aXSy4uQ… Suggested-by: Yonghong Song <yonghong.song(a)linux.dev> Suggested-by: Alexei Starovoitov <alexei.starovoitov(a)gmail.com> Signed-off-by: Yafang Shao <laoar.shao(a)gmail.com> Acked-by: Eduard Zingerman <eddyz87(a)gmail.com> Cc: stable(a)vger.kernel.org --- kernel/bpf/verifier.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 4ccca1f..b6b60cd 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -14047,6 +14047,12 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env, return -EINVAL; } + /* check src2 operand */ + err = check_reg_arg(env, insn->dst_reg, SRC_OP); + if (err) + return err; + + dst_reg = &regs[insn->dst_reg]; if (BPF_SRC(insn->code) == BPF_X) { if (insn->imm != 0) { verbose(env, "BPF_JMP/JMP32 uses reserved fields\n"); @@ -14058,12 +14064,13 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env, if (err) return err; - if (is_pointer_value(env, insn->src_reg)) { + src_reg = &regs[insn->src_reg]; + if (!(reg_is_pkt_pointer_any(dst_reg) && reg_is_pkt_pointer_any(src_reg)) && + is_pointer_value(env, insn->src_reg)) { verbose(env, "R%d pointer comparison prohibited\n", insn->src_reg); return -EACCES; } - src_reg = &regs[insn->src_reg]; } else { if (insn->src_reg != BPF_REG_0) { verbose(env, "BPF_JMP/JMP32 uses reserved fields\n"); @@ -14071,12 +14078,6 @@ static int check_cond_jmp_op(struct bpf_verifier_env *env, } } - /* check src2 operand */ - err = check_reg_arg(env, insn->dst_reg, SRC_OP); - if (err) - return err; - - dst_reg = &regs[insn->dst_reg]; is_jmp32 = BPF_CLASS(insn->code) == BPF_JMP32; if (BPF_SRC(insn->code) == BPF_K) { -- 1.8.3.1

1 year, 9 months

1
0
0 0

[PATCH net] batman-adv: Hold rtnl lock during MTU update via netlink

by Sven Eckelmann

The automatic recalculation of the maximum allowed MTU is usually triggered by code sections which are already rtnl lock protected by callers outside of batman-adv. But when the fragmentation setting is changed via batman-adv's own batadv genl family, then the rtnl lock is not yet taken. But dev_set_mtu requires that the caller holds the rtnl lock because it uses netdevice notifiers. And this code will then fail the check for this lock: RTNL: assertion failed at net/core/dev.c (1953) Cc: stable(a)vger.kernel.org Reported-by: syzbot+f8812454d9b3ac00d282(a)syzkaller.appspotmail.com Fixes: c6a953cce8d0 ("batman-adv: Trigger events for auto adjusted MTU") Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- This problem was just identified by syzbot [1]. I hope it is ok to directly send this patch to netdev instead of creating a single-patch PR from the batadv/net branch. If you still prefer a PR then we can also prepare it. [1] https://lore.kernel.org/r/0000000000009bbb4b0603717cde@google.com --- net/batman-adv/netlink.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/batman-adv/netlink.c b/net/batman-adv/netlink.c index ad5714f737be..6efbc9275aec 100644 --- a/net/batman-adv/netlink.c +++ b/net/batman-adv/netlink.c @@ -495,7 +495,10 @@ static int batadv_netlink_set_mesh(struct sk_buff *skb, struct genl_info *info) attr = info->attrs[BATADV_ATTR_FRAGMENTATION_ENABLED]; atomic_set(&bat_priv->fragmentation, !!nla_get_u8(attr)); + + rtnl_lock(); batadv_update_min_mtu(bat_priv->soft_iface); + rtnl_unlock(); } if (info->attrs[BATADV_ATTR_GW_BANDWIDTH_DOWN]) { --- base-commit: 421d467dc2d483175bad4fb76a31b9e5a3d744cf change-id: 20230821-batadv-missing-mtu-rtnl-lock-bc4cee67731d Best regards, -- Sven Eckelmann <sven(a)narfation.org>

1 year, 9 months

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2023