- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] RDMA/bnxt_re: Avoid CPU lockups due fifo occupancy check loop
by Zhang Changzhong 18 Nov '24

18 Nov '24

From: Selvin Xavier <selvin.xavier(a)broadcom.com> mainline inclusion from mainline-v6.12-rc4 commit 8be3e5b0c96beeefe9d5486b96575d104d3e7d17 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB2SU7 CVE: CVE-2024-50157 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Driver waits indefinitely for the fifo occupancy to go below a threshold as soon as the pacing interrupt is received. This can cause soft lockup on one of the processors, if the rate of DB is very high. Add a loop count for FPGA and exit the __wait_for_fifo_occupancy_below_th if the loop is taking more time. Pacing will be continuing until the occupancy is below the threshold. This is ensured by the checks in bnxt_re_pacing_timer_exp and further scheduling the work for pacing based on the fifo occupancy. Fixes: 2ad4e6303a6d ("RDMA/bnxt_re: Implement doorbell pacing algorithm") Link: https://patch.msgid.link/r/1728373302-19530-7-git-send-email-selvin.xavier@… Reviewed-by: Kalesh AP <kalesh-anakkur.purayil(a)broadcom.com> Reviewed-by: Chandramohan Akula <chandramohan.akula(a)broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier(a)broadcom.com> Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> Conflicts: drivers/infiniband/hw/bnxt_re/main.c [24943dcdc156 ("RDMA/bnxt_re: Disable doorbell moderation if hardware register read fails") not merged] Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- drivers/infiniband/hw/bnxt_re/main.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/infiniband/hw/bnxt_re/main.c b/drivers/infiniband/hw/bnxt_re/main.c index 0373d0e..8b032a2 100644 --- a/drivers/infiniband/hw/bnxt_re/main.c +++ b/drivers/infiniband/hw/bnxt_re/main.c @@ -484,6 +484,8 @@ static void bnxt_re_set_default_pacing_data(struct bnxt_re_dev *rdev) static void __wait_for_fifo_occupancy_below_th(struct bnxt_re_dev *rdev) { + struct bnxt_qplib_db_pacing_data *pacing_data = rdev->qplib_res.pacing_data; + u32 retry_fifo_check = 1000; u32 read_val, fifo_occup; /* loop shouldn't run infintely as the occupancy usually goes @@ -500,6 +502,14 @@ static void __wait_for_fifo_occupancy_below_th(struct bnxt_re_dev *rdev) if (fifo_occup < rdev->qplib_res.pacing_data->pacing_th) break; + if (!retry_fifo_check--) { + dev_info_once(rdev_to_dev(rdev), + "%s: fifo_occup = 0x%xfifo_max_depth = 0x%x pacing_th = 0x%x\n", + __func__, fifo_occup, pacing_data->fifo_max_depth, + pacing_data->pacing_th); + break; + } + } } -- 2.9.5

2 1

[PATCH OLK-6.6] ima: fix a compilation error with ima_bprm_creds_for_exec()
by Gu Bowen 18 Nov '24

18 Nov '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAZ996 CVE: NA ---------------------------------------------------------------------- The new feature script execution check has added a new security function ima_bprm_creds_for_exe, which causes a compilation error when ima is not enabled, we fix it. Fixes: b89997c5e3ff ("IMA support script execution check") Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- include/linux/ima.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/include/linux/ima.h b/include/linux/ima.h index 76d0f71d7955..eb119cd62f02 100644 --- a/include/linux/ima.h +++ b/include/linux/ima.h @@ -63,6 +63,11 @@ static inline int ima_bprm_check(struct linux_binprm *bprm) return 0; } +static inline int ima_bprm_creds_for_exec(struct linux_binprm *bprm) +{ + return 0; +} + static inline int ima_file_check(struct file *file, int mask) { return 0; -- 2.25.1

2 1

[PATCH OLK-5.10] bpf, arm64: Fix address emission with tag-based KASAN enabled
by Tengda Wu 18 Nov '24

18 Nov '24

From: Peter Collingbourne <pcc(a)google.com> mainline inclusion from mainline-v6.12-rc5 commit a552e2ef5fd1a6c78267cd4ec5a9b49aa11bbb1c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB2YVC CVE: CVE-2024-50203 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When BPF_TRAMP_F_CALL_ORIG is enabled, the address of a bpf_tramp_image struct on the stack is passed during the size calculation pass and an address on the heap is passed during code generation. This may cause a heap buffer overflow if the heap address is tagged because emit_a64_mov_i64() will emit longer code than it did during the size calculation pass. The same problem could occur without tag-based KASAN if one of the 16-bit words of the stack address happened to be all-ones during the size calculation pass. Fix the problem by assuming the worst case (4 instructions) when calculating the size of the bpf_tramp_image address emission. Fixes: 19d3c179a377 ("bpf, arm64: Fix trampoline for BPF_TRAMP_F_CALL_ORIG") Signed-off-by: Peter Collingbourne <pcc(a)google.com> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Acked-by: Xu Kuohai <xukuohai(a)huawei.com> Link: https://linux-review.googlesource.com/id/I1496f2bc24fba7a1d492e16e2b94cf437… Link: https://lore.kernel.org/bpf/20241018221644.3240898-1-pcc@google.com Conflicts: arch/arm64/net/bpf_jit_comp.c [This conflict arises from the fact that the previous patch, 2a5ab77af7f9 ("bpf, arm64: Add bpf trampoline for arm64"), made some minor adjustments for version 5.10 without fully aligning with the community] Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- arch/arm64/net/bpf_jit_comp.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c index adab5f03a306..af5760c0d2e7 100644 --- a/arch/arm64/net/bpf_jit_comp.c +++ b/arch/arm64/net/bpf_jit_comp.c @@ -1647,7 +1647,11 @@ static int prepare_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im, emit(A64_STR64I(A64_R(19), A64_SP, regs_off), ctx); if (flags & BPF_TRAMP_F_CALL_ORIG) { - emit_a64_mov_i64(A64_R(0), (const u64)im, ctx); + /* for the first pass, assume the worst case */ + if (!ctx->image) + ctx->idx += 4; + else + emit_a64_mov_i64(A64_R(0), (const u64)im, ctx); emit_call((const u64)__bpf_tramp_enter, ctx); } @@ -1688,7 +1692,11 @@ static int prepare_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im, if (flags & BPF_TRAMP_F_CALL_ORIG) { im->ip_epilogue = ctx->image + ctx->idx; - emit_a64_mov_i64(A64_R(0), (const u64)im, ctx); + /* for the first pass, assume the worst case */ + if (!ctx->image) + ctx->idx += 4; + else + emit_a64_mov_i64(A64_R(0), (const u64)im, ctx); emit_call((const u64)__bpf_tramp_exit, ctx); } -- 2.34.1

2 1

[PATCH OLK-6.6] bpf, arm64: Fix address emission with tag-based KASAN enabled
by Tengda Wu 18 Nov '24

18 Nov '24

From: Peter Collingbourne <pcc(a)google.com> mainline inclusion from mainline-v6.12-rc5 commit a552e2ef5fd1a6c78267cd4ec5a9b49aa11bbb1c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB2YVC CVE: CVE-2024-50203 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When BPF_TRAMP_F_CALL_ORIG is enabled, the address of a bpf_tramp_image struct on the stack is passed during the size calculation pass and an address on the heap is passed during code generation. This may cause a heap buffer overflow if the heap address is tagged because emit_a64_mov_i64() will emit longer code than it did during the size calculation pass. The same problem could occur without tag-based KASAN if one of the 16-bit words of the stack address happened to be all-ones during the size calculation pass. Fix the problem by assuming the worst case (4 instructions) when calculating the size of the bpf_tramp_image address emission. Fixes: 19d3c179a377 ("bpf, arm64: Fix trampoline for BPF_TRAMP_F_CALL_ORIG") Signed-off-by: Peter Collingbourne <pcc(a)google.com> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Acked-by: Xu Kuohai <xukuohai(a)huawei.com> Link: https://linux-review.googlesource.com/id/I1496f2bc24fba7a1d492e16e2b94cf437… Link: https://lore.kernel.org/bpf/20241018221644.3240898-1-pcc@google.com Conflicts: arch/arm64/net/bpf_jit_comp.c [This conflict is due to us not merging a cache optimization commit 96b0f5addc7a ('arm64, bpf: Use bpf_prog_pack for arm64 bpf trampoline')] Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- arch/arm64/net/bpf_jit_comp.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c index d6f4aebbad69..76ae4a3131ba 100644 --- a/arch/arm64/net/bpf_jit_comp.c +++ b/arch/arm64/net/bpf_jit_comp.c @@ -1949,7 +1949,11 @@ static int prepare_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im, emit(A64_STR64I(A64_R(20), A64_SP, regs_off + 8), ctx); if (flags & BPF_TRAMP_F_CALL_ORIG) { - emit_a64_mov_i64(A64_R(0), (const u64)im, ctx); + /* for the first pass, assume the worst case */ + if (!ctx->image) + ctx->idx += 4; + else + emit_a64_mov_i64(A64_R(0), (const u64)im, ctx); emit_call((const u64)__bpf_tramp_enter, ctx); } @@ -1993,7 +1997,11 @@ static int prepare_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im, if (flags & BPF_TRAMP_F_CALL_ORIG) { im->ip_epilogue = ctx->image + ctx->idx; - emit_a64_mov_i64(A64_R(0), (const u64)im, ctx); + /* for the first pass, assume the worst case */ + if (!ctx->image) + ctx->idx += 4; + else + emit_a64_mov_i64(A64_R(0), (const u64)im, ctx); emit_call((const u64)__bpf_tramp_exit, ctx); } -- 2.34.1

2 1

[PATCH OLK-6.6] sched/numa: Fix the potential null pointer dereference in task_numa_work()
by liukai 18 Nov '24

18 Nov '24

From: Shawn Wang <shawnwang(a)linux.alibaba.com> stable inclusion from stable-v6.6.60 commit ade91f6e9848b370add44d89c976e070ccb492ef category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB37AS CVE: CVE-2024-50223 -------------------------------- Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… [ Upstream commit 9c70b2a33cd2aa6a5a59c5523ef053bd42265209 ] When running stress-ng-vm-segv test, we found a null pointer dereference error in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel... stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process. Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential task_numa_work() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vma_next() in task_numa_work() will return a null pointer even if the vma iterator restarts from 0. Recheck the vma pointer before dereferencing it in task_numa_work(). Fixes: 214dbc428137 ("sched: convert to vma iterator") Signed-off-by: Shawn Wang <shawnwang(a)linux.alibaba.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: stable(a)vger.kernel.org # v6.2+ Link: https://lkml.kernel.org/r/20241025022208.125527-1-shawnwang@linux.alibaba.c… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- kernel/sched/fair.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index d5ae744deb39..f1cd57e70f1f 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -3413,7 +3413,7 @@ static void task_numa_work(struct callback_head *work) vma = vma_next(&vmi); } - do { + for (; vma; vma = vma_next(&vmi)) { if (!vma_migratable(vma) || !vma_policy_mof(vma) || is_vm_hugetlb_page(vma) || (vma->vm_flags & VM_MIXEDMAP)) { continue; @@ -3499,7 +3499,7 @@ static void task_numa_work(struct callback_head *work) cond_resched(); } while (end != vma->vm_end); - } for_each_vma(vmi, vma); + } out: /* -- 2.34.1

2 1

[PATCH OLK-6.6] ima: fix a compilation error with ima_bprm_creds_for_exec()
by Gu Bowen 18 Nov '24

18 Nov '24

The new feature script execution check has added a new security function ima_bprm_creds_for_exe, which causes a compilation error when ima is not enabled, we fix it. Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- include/linux/ima.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/include/linux/ima.h b/include/linux/ima.h index 76d0f71d7955..eb119cd62f02 100644 --- a/include/linux/ima.h +++ b/include/linux/ima.h @@ -63,6 +63,11 @@ static inline int ima_bprm_check(struct linux_binprm *bprm) return 0; } +static inline int ima_bprm_creds_for_exec(struct linux_binprm *bprm) +{ + return 0; +} + static inline int ima_file_check(struct file *file, int mask) { return 0; -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower
by Liu Jian 18 Nov '24

18 Nov '24

From: Felix Fietkau <nbd(a)nbd.name> stable inclusion from stable-v4.19.323 commit b0b862aa3dbcd16b3c4715259a825f48ca540088 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB37A8 CVE: CVE-2024-50237 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------------------------------------- commit 393b6bc174b0dd21bb2a36c13b36e62fc3474a23 upstream. Avoid potentially crashing in the driver because of uninitialized private data Fixes: 5b3dc42b1b0d ("mac80211: add support for driver tx power reporting") Cc: stable(a)vger.kernel.org Signed-off-by: Felix Fietkau <nbd(a)nbd.name> Link: https://patch.msgid.link/20241002095630.22431-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/mac80211/cfg.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c index d384fb85b8df..1f7ae4cbbdee 100644 --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -2451,7 +2451,8 @@ static int ieee80211_get_tx_power(struct wiphy *wiphy, struct ieee80211_local *local = wiphy_priv(wiphy); struct ieee80211_sub_if_data *sdata = IEEE80211_WDEV_TO_SUB_IF(wdev); - if (local->ops->get_txpower) + if (local->ops->get_txpower && + (sdata->flags & IEEE80211_SDATA_IN_DRIVER)) return drv_get_txpower(local, sdata, dbm); if (!local->use_chanctx) -- 2.34.1

2 1

[PATCH OLK-5.10] wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower
by Liu Jian 18 Nov '24

18 Nov '24

From: Felix Fietkau <nbd(a)nbd.name> stable inclusion from stable-v5.10.229 commit c21efba8b5a86537ccdf43f77536bad02f82776c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB37A8 CVE: CVE-2024-50237 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------------------------------------- commit 393b6bc174b0dd21bb2a36c13b36e62fc3474a23 upstream. Avoid potentially crashing in the driver because of uninitialized private data Fixes: 5b3dc42b1b0d ("mac80211: add support for driver tx power reporting") Cc: stable(a)vger.kernel.org Signed-off-by: Felix Fietkau <nbd(a)nbd.name> Link: https://patch.msgid.link/20241002095630.22431-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/mac80211/cfg.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c index c8d2fe8fbc0a..f2629e56d1a5 100644 --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -2720,7 +2720,8 @@ static int ieee80211_get_tx_power(struct wiphy *wiphy, struct ieee80211_local *local = wiphy_priv(wiphy); struct ieee80211_sub_if_data *sdata = IEEE80211_WDEV_TO_SUB_IF(wdev); - if (local->ops->get_txpower) + if (local->ops->get_txpower && + (sdata->flags & IEEE80211_SDATA_IN_DRIVER)) return drv_get_txpower(local, sdata, dbm); if (!local->use_chanctx) -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower
by Liu Jian 18 Nov '24

18 Nov '24

From: Felix Fietkau <nbd(a)nbd.name> stable inclusion from stable-v5.10.229 commit c21efba8b5a86537ccdf43f77536bad02f82776c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB37A8 CVE: CVE-2024-50237 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------------------------------------- commit 393b6bc174b0dd21bb2a36c13b36e62fc3474a23 upstream. Avoid potentially crashing in the driver because of uninitialized private data Fixes: 5b3dc42b1b0d ("mac80211: add support for driver tx power reporting") Cc: stable(a)vger.kernel.org Signed-off-by: Felix Fietkau <nbd(a)nbd.name> Link: https://patch.msgid.link/20241002095630.22431-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/mac80211/cfg.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c index c8d2fe8fbc0a..f2629e56d1a5 100644 --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -2720,7 +2720,8 @@ static int ieee80211_get_tx_power(struct wiphy *wiphy, struct ieee80211_local *local = wiphy_priv(wiphy); struct ieee80211_sub_if_data *sdata = IEEE80211_WDEV_TO_SUB_IF(wdev); - if (local->ops->get_txpower) + if (local->ops->get_txpower && + (sdata->flags & IEEE80211_SDATA_IN_DRIVER)) return drv_get_txpower(local, sdata, dbm); if (!local->use_chanctx) -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] mailbox: bcm2835: Fix timeout during suspend mode
by dinglongwei 18 Nov '24

18 Nov '24

From: Stefan Wahren <wahrenst(a)gmx.net> stable inclusion from stable-v5.10.227 commit 32ee78823dea2d54adaf6e05f86622eba359e091 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRCG CVE: CVE-2024-49963 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit dc09f007caed3b2f6a3b6bd7e13777557ae22bfd ] During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs Link: https://github.com/raspberrypi/firmware/issues/1894 Fixes: 0bae6af6d704 ("mailbox: Enable BCM2835 mailbox support") Signed-off-by: Stefan Wahren <wahrenst(a)gmx.net> Reviewed-by: Florian Fainelli <florian.fainelli(a)broadcom.com> Signed-off-by: Jassi Brar <jassisinghbrar(a)gmail.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- drivers/mailbox/bcm2835-mailbox.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mailbox/bcm2835-mailbox.c b/drivers/mailbox/bcm2835-mailbox.c index 39761d190545..5c33c01a9d26 100644 --- a/drivers/mailbox/bcm2835-mailbox.c +++ b/drivers/mailbox/bcm2835-mailbox.c @@ -146,7 +146,8 @@ static int bcm2835_mbox_probe(struct platform_device *pdev) spin_lock_init(&mbox->lock); ret = devm_request_irq(dev, irq_of_parse_and_map(dev->of_node, 0), - bcm2835_mbox_irq, 0, dev_name(dev), mbox); + bcm2835_mbox_irq, IRQF_NO_SUSPEND, dev_name(dev), + mbox); if (ret) { dev_err(dev, "Failed to register a mailbox IRQ handler: %d\n", ret); -- 2.17.1

2 1