September 2024 - Linux-stable-mirror

[PATCH] KVM: PPC: Book3S HV: Reset LPCR_MER before running a vCPU to avoid spurious interrupts

by Gautam Menghani

Reset LPCR_MER bit before running a vCPU to ensure that it is not set if there are no pending interrupts. Running a vCPU with LPCR_MER bit set and no pending interrupts results in L2 vCPU getting an infinite flood of spurious interrupts. The 'if check' in kvmhv_run_single_vcpu() sets the LPCR_MER bit if there are pending interrupts. The spurious flood problem can be observed in 2 cases: 1. Crashing the guest while interrupt heavy workload is running a. Start a L2 guest and run an interrupt heavy workload (eg: ipistorm) b. While the workload is running, crash the guest (make sure kdump is configured) c. Any one of the vCPUs of the guest will start getting an infinite flood of spurious interrupts. 2. Running LTP stress tests in multiple guests at the same time a. Start 4 L2 guests. b. Start running LTP stress tests on all 4 guests at same time. c. In some time, any one/more of the vCPUs of any of the guests will start getting an infinite flood of spurious interrupts. The root cause of both the above issues is the same: 1. A NMI is sent to a running vCPU that had LPCR_MER bit set. 2. In the NMI path, all registers are refreshed, i.e, H_GUEST_GET_STATE is called for all the registers. 3. When H_GUEST_GET_STATE is called for lpcr, the vcpu->arch.vcore->lpcr of that vCPU at L1 level gets updated with LPCR_MER set to 1, and this new value is always used whenever that vCPU runs, regardless of whether there was a pending interrupt. 4. Since LPCR_MER is set, the vCPU in L2 always jumps to the external interrupt handler, and this cycle never ends. Fix the spurious flood by making sure LPCR_MER is always reset before running a vCPU. Fixes: ec0f6639fa88 ("KVM: PPC: Book3S HV nestedv2: Ensure LPCR_MER bit is passed to the L0") Cc: stable(a)vger.kernel.org # v6.8+ Signed-off-by: Gautam Menghani <gautam(a)linux.ibm.com> --- arch/powerpc/kvm/book3s_hv.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c index 8f7d7e37bc8c..3cc2f1691001 100644 --- a/arch/powerpc/kvm/book3s_hv.c +++ b/arch/powerpc/kvm/book3s_hv.c @@ -98,6 +98,13 @@ /* Used to indicate that a guest passthrough interrupt needs to be handled */ #define RESUME_PASSTHROUGH (RESUME_GUEST | RESUME_FLAG_ARCH2) +/* Clear LPCR_MER bit - If we run a L2 vCPU with LPCR_MER bit set but no pending external + * interrupts, we end up getting a flood of spurious interrupts in L2 KVM guests. To avoid + * that, reset LPCR_MER and let the 'if check' for pending interrupts in kvmhv_run_single_vcpu() + * set LPCR_MER if there are pending interrupts. + */ +#define kvmppc_reset_lpcr_mer(vcpu) (vcpu->arch.vcore->lpcr &= ~LPCR_MER) + /* Used as a "null" value for timebase values */ #define TB_NIL (~(u64)0) @@ -5091,7 +5098,7 @@ static int kvmppc_vcpu_run_hv(struct kvm_vcpu *vcpu) accumulate_time(vcpu, &vcpu->arch.guest_entry); if (cpu_has_feature(CPU_FTR_ARCH_300)) r = kvmhv_run_single_vcpu(vcpu, ~(u64)0, - vcpu->arch.vcore->lpcr); + kvmppc_reset_lpcr_mer(vcpu)); else r = kvmppc_run_vcpu(vcpu); -- 2.46.0

2 months, 3 weeks

1
0
0 0

[PATCH v1] bpf: Prevent infinite loops with bpf_redirect_peer

by Jordan Rife

It is possible to create cycles using bpf_redirect_peer which lead to an an infinite loop inside __netif_receive_skb_core. The simplest way to illustrate this is by attaching a TC program to the ingress hook on both sides of a veth or netkit device pair which redirects to its own peer, although other cycles are possible. This patch places an upper limit on the number of iterations allowed inside __netif_receive_skb_core to prevent this. Signed-off-by: Jordan Rife <jrife(a)google.com> Fixes: 9aa1206e8f48 ("bpf: Add redirect_peer helper") Cc: stable(a)vger.kernel.org --- net/core/dev.c | 11 +++- net/core/dev.h | 1 + .../selftests/bpf/prog_tests/tc_redirect.c | 51 +++++++++++++++++++ .../selftests/bpf/progs/test_tc_peer.c | 13 +++++ 4 files changed, 75 insertions(+), 1 deletion(-) diff --git a/net/core/dev.c b/net/core/dev.c index cd479f5f22f6..753f8d27f47c 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -5455,6 +5455,7 @@ static int __netif_receive_skb_core(struct sk_buff **pskb, bool pfmemalloc, struct net_device *orig_dev; bool deliver_exact = false; int ret = NET_RX_DROP; + int loops = 0; __be16 type; net_timestamp_check(!READ_ONCE(net_hotdata.tstamp_prequeue), skb); @@ -5521,8 +5522,16 @@ static int __netif_receive_skb_core(struct sk_buff **pskb, bool pfmemalloc, nf_skip_egress(skb, true); skb = sch_handle_ingress(skb, &pt_prev, &ret, orig_dev, &another); - if (another) + if (another) { + loops++; + if (unlikely(loops == RX_LOOP_LIMIT)) { + ret = NET_RX_DROP; + net_crit_ratelimited("bpf: loop limit reached on datapath, buggy bpf program?\n"); + goto out; + } + goto another_round; + } if (!skb) goto out; diff --git a/net/core/dev.h b/net/core/dev.h index 5654325c5b71..28d1cf2f9069 100644 --- a/net/core/dev.h +++ b/net/core/dev.h @@ -150,6 +150,7 @@ struct napi_struct *napi_by_id(unsigned int napi_id); void kick_defer_list_purge(struct softnet_data *sd, unsigned int cpu); #define XMIT_RECURSION_LIMIT 8 +#define RX_LOOP_LIMIT 8 #ifndef CONFIG_PREEMPT_RT static inline bool dev_xmit_recursion(void) diff --git a/tools/testing/selftests/bpf/prog_tests/tc_redirect.c b/tools/testing/selftests/bpf/prog_tests/tc_redirect.c index c85798966aec..db1b36090d6c 100644 --- a/tools/testing/selftests/bpf/prog_tests/tc_redirect.c +++ b/tools/testing/selftests/bpf/prog_tests/tc_redirect.c @@ -1081,6 +1081,55 @@ static void test_tc_redirect_peer(struct netns_setup_result *setup_result) close_netns(nstoken); } +static void test_tc_redirect_peer_loop(struct netns_setup_result *setup_result) +{ + LIBBPF_OPTS(bpf_tc_hook, qdisc_src_fwd); + LIBBPF_OPTS(bpf_tc_hook, qdisc_src); + struct test_tc_peer *skel; + struct nstoken *nstoken; + int err; + + /* Set up an infinite redirect loop using bpf_redirect_peer with ingress + * hooks on either side of a veth/netkit pair redirecting to its own + * peer. This should not lock up the kernel. + */ + nstoken = open_netns(NS_SRC); + if (!ASSERT_OK_PTR(nstoken, "setns src")) + return; + + skel = test_tc_peer__open(); + if (!ASSERT_OK_PTR(skel, "test_tc_peer__open")) + goto done; + + skel->rodata->IFINDEX_SRC = setup_result->ifindex_src; + skel->rodata->IFINDEX_SRC_FWD = setup_result->ifindex_src_fwd; + + err = test_tc_peer__load(skel); + if (!ASSERT_OK(err, "test_tc_peer__load")) + goto done; + + QDISC_CLSACT_CREATE(&qdisc_src, setup_result->ifindex_src); + XGRESS_FILTER_ADD(&qdisc_src, BPF_TC_INGRESS, skel->progs.tc_src_self, 0); + close_netns(nstoken); + + nstoken = open_netns(NS_FWD); + if (!ASSERT_OK_PTR(nstoken, "setns fwd")) + return; + QDISC_CLSACT_CREATE(&qdisc_src_fwd, setup_result->ifindex_src_fwd); + XGRESS_FILTER_ADD(&qdisc_src_fwd, BPF_TC_INGRESS, skel->progs.tc_src_fwd_self, 0); + + if (!ASSERT_OK(set_forwarding(false), "disable forwarding")) + goto done; + + SYS_NOFAIL("ip netns exec " NS_SRC " %s -c 1 -W 1 -q %s > /dev/null", + ping_command(AF_INET), IP4_DST); +fail: +done: + if (skel) + test_tc_peer__destroy(skel); + close_netns(nstoken); +} + static int tun_open(char *name) { struct ifreq ifr; @@ -1280,6 +1329,8 @@ static void *test_tc_redirect_run_tests(void *arg) RUN_TEST(tc_redirect_peer, MODE_VETH); RUN_TEST(tc_redirect_peer, MODE_NETKIT); RUN_TEST(tc_redirect_peer_l3, MODE_VETH); + RUN_TEST(tc_redirect_peer_loop, MODE_VETH); + RUN_TEST(tc_redirect_peer_loop, MODE_NETKIT); RUN_TEST(tc_redirect_peer_l3, MODE_NETKIT); RUN_TEST(tc_redirect_neigh, MODE_VETH); RUN_TEST(tc_redirect_neigh_fib, MODE_VETH); diff --git a/tools/testing/selftests/bpf/progs/test_tc_peer.c b/tools/testing/selftests/bpf/progs/test_tc_peer.c index 365eacb5dc34..9b8a00ccad42 100644 --- a/tools/testing/selftests/bpf/progs/test_tc_peer.c +++ b/tools/testing/selftests/bpf/progs/test_tc_peer.c @@ -10,6 +10,7 @@ #include <bpf/bpf_helpers.h> +volatile const __u32 IFINDEX_SRC_FWD; volatile const __u32 IFINDEX_SRC; volatile const __u32 IFINDEX_DST; @@ -34,6 +35,18 @@ int tc_src(struct __sk_buff *skb) return bpf_redirect_peer(IFINDEX_DST, 0); } +SEC("tc") +int tc_src_self(struct __sk_buff *skb) +{ + return bpf_redirect_peer(IFINDEX_SRC, 0); +} + +SEC("tc") +int tc_src_fwd_self(struct __sk_buff *skb) +{ + return bpf_redirect_peer(IFINDEX_SRC_FWD, 0); +} + SEC("tc") int tc_dst_l3(struct __sk_buff *skb) { -- 2.46.1.824.gd892dcdcdd-goog

2 months, 3 weeks

3
3
0 0

[PATCH] staging: Fix atomicity violation in get_serial_info()

by Qiu-ji Chen

Atomicity violation occurs during consecutive reads of the members of gb_tty. Consider a scenario where, because the consecutive reads of gb_tty members are not protected by a lock, the value of gb_tty may still be changing during the read process. gb_tty->port.close_delay and gb_tty->port.closing_wait are updated together, such as in the set_serial_info() function. If during the read process, gb_tty->port.close_delay and gb_tty->port.closing_wait are still being updated, it is possible that gb_tty->port.close_delay is updated while gb_tty->port.closing_wait is not. In this case, the code first reads gb_tty->port.close_delay and then gb_tty->port.closing_wait. A new gb_tty->port.close_delay and an old gb_tty->port.closing_wait could be read. Such values, whether before or after the update, should not coexist as they represent an intermediate state. This could result in a mismatch of the values read for gb_tty->minor, gb_tty->port.close_delay, and gb_tty->port.closing_wait, which in turn could cause ss->close_delay and ss->closing_wait to be mismatched. To address this issue, we have enclosed all sequential read operations of the gb_tty variable within a lock. This ensures that the value of gb_tty remains unchanged throughout the process, guaranteeing its validity. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. Fixes: b71e571adaa5 ("staging: greybus: uart: fix TIOCSSERIAL jiffies conversions") Cc: stable(a)vger.kernel.org Signed-off-by: Qiu-ji Chen <chenqiuji666(a)gmail.com> --- drivers/staging/greybus/uart.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c index cdf4ebb93b10..8cc18590d97b 100644 --- a/drivers/staging/greybus/uart.c +++ b/drivers/staging/greybus/uart.c @@ -595,12 +595,14 @@ static int get_serial_info(struct tty_struct *tty, { struct gb_tty *gb_tty = tty->driver_data; + mutex_lock(&gb_tty->port.mutex); ss->line = gb_tty->minor; ss->close_delay = jiffies_to_msecs(gb_tty->port.close_delay) / 10; ss->closing_wait = gb_tty->port.closing_wait == ASYNC_CLOSING_WAIT_NONE ? ASYNC_CLOSING_WAIT_NONE : jiffies_to_msecs(gb_tty->port.closing_wait) / 10; + mutex_unlock(&gb_tty->port.mutex); return 0; } -- 2.34.1

2 months, 3 weeks

3
2
0 0

[PATCH 3/8] drm/sched: Always increment correct scheduler score

by Tvrtko Ursulin

From: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> Entities run queue can change during drm_sched_entity_push_job() so make sure to update the score consistently. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> Fixes: d41a39dda140 ("drm/scheduler: improve job distribution with multiple queues") Cc: Nirmoy Das <nirmoy.das(a)amd.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: Luben Tuikov <ltuikov89(a)gmail.com> Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: David Airlie <airlied(a)gmail.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v5.9+ Reviewed-by: Christian König <christian.koenig(a)amd.com> Reviewed-by: Nirmoy Das <nirmoy.das(a)intel.com> --- drivers/gpu/drm/scheduler/sched_entity.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c index 76e422548d40..6645a8524699 100644 --- a/drivers/gpu/drm/scheduler/sched_entity.c +++ b/drivers/gpu/drm/scheduler/sched_entity.c @@ -586,7 +586,6 @@ void drm_sched_entity_push_job(struct drm_sched_job *sched_job) ktime_t submit_ts; trace_drm_sched_job(sched_job, entity); - atomic_inc(entity->rq->sched->score); WRITE_ONCE(entity->last_user, current->group_leader); /* @@ -614,6 +613,7 @@ void drm_sched_entity_push_job(struct drm_sched_job *sched_job) rq = entity->rq; sched = rq->sched; + atomic_inc(sched->score); drm_sched_rq_add_entity(rq, entity); spin_unlock(&entity->rq_lock); -- 2.46.0

2 months, 3 weeks

3
4
0 0

[PATCH 6.1] drm/amd/display: fix NULL checks for adev->dm.dc in amdgpu_dm_fini()

by Denis Arefev

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> [ Upstream commit 2a3cfb9a24a28da9cc13d2c525a76548865e182c ] Since 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULL before the call to dc_enable_dmub_notifications(), check beforehand to ensure there will not be a possible NULL-ptr-deref there. Also, since commit 1e88eb1b2c25 ("drm/amd/display: Drop CONFIG_DRM_AMD_DC_HDCP") there are two separate checks for NULL in 'adev->dm.dc' before dc_deinit_callbacks() and dc_dmub_srv_destroy(). Clean up by combining them all under one 'if'. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: 81927e2808be ("drm/amd/display: Support for DMUB AUX") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 393e32259a77..4850aed54604 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -1876,14 +1876,14 @@ static void amdgpu_dm_fini(struct amdgpu_device *adev) dc_deinit_callbacks(adev->dm.dc); #endif - if (adev->dm.dc) + if (adev->dm.dc) { dc_dmub_srv_destroy(&adev->dm.dc->ctx->dmub_srv); - - if (dc_enable_dmub_notifications(adev->dm.dc)) { - kfree(adev->dm.dmub_notify); - adev->dm.dmub_notify = NULL; - destroy_workqueue(adev->dm.delayed_hpd_wq); - adev->dm.delayed_hpd_wq = NULL; + if (dc_enable_dmub_notifications(adev->dm.dc)) { + kfree(adev->dm.dmub_notify); + adev->dm.dmub_notify = NULL; + destroy_workqueue(adev->dm.delayed_hpd_wq); + adev->dm.delayed_hpd_wq = NULL; + } } if (adev->dm.dmub_bo) -- 2.25.1

2 months, 3 weeks

1
0
0 0

[PATCH] gpio: davinci: fix lazy disable

by Parth Pancholi

From: Emanuele Ghidoli <emanuele.ghidoli(a)toradex.com> On a few platforms such as TI's AM69 device, disable_irq() fails to keep track of the interrupts that happen between disable_irq() and enable_irq() and those interrupts are missed. Use the ->irq_unmask() and ->irq_mask() methods instead of ->irq_enable() and ->irq_disable() to correctly keep track of edges when disable_irq is called. This solves the issue of disable_irq() not working as expected on such platforms. Fixes: 23265442b02b ("ARM: davinci: irq_data conversion.") Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli(a)toradex.com> Signed-off-by: Parth Pancholi <parth.pancholi(a)toradex.com> Cc: stable(a)vger.kernel.org --- drivers/gpio/gpio-davinci.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c index 1d0175d6350b..0ecfa7de5ce2 100644 --- a/drivers/gpio/gpio-davinci.c +++ b/drivers/gpio/gpio-davinci.c @@ -289,7 +289,7 @@ static int davinci_gpio_probe(struct platform_device *pdev) * serve as EDMA event triggers. */ -static void gpio_irq_disable(struct irq_data *d) +static void gpio_irq_mask(struct irq_data *d) { struct davinci_gpio_regs __iomem *g = irq2regs(d); uintptr_t mask = (uintptr_t)irq_data_get_irq_handler_data(d); @@ -298,7 +298,7 @@ static void gpio_irq_disable(struct irq_data *d) writel_relaxed(mask, &g->clr_rising); } -static void gpio_irq_enable(struct irq_data *d) +static void gpio_irq_unmask(struct irq_data *d) { struct davinci_gpio_regs __iomem *g = irq2regs(d); uintptr_t mask = (uintptr_t)irq_data_get_irq_handler_data(d); @@ -324,8 +324,8 @@ static int gpio_irq_type(struct irq_data *d, unsigned trigger) static struct irq_chip gpio_irqchip = { .name = "GPIO", - .irq_enable = gpio_irq_enable, - .irq_disable = gpio_irq_disable, + .irq_unmask = gpio_irq_unmask, + .irq_mask = gpio_irq_mask, .irq_set_type = gpio_irq_type, .flags = IRQCHIP_SET_TYPE_MASKED | IRQCHIP_SKIP_SET_WAKE, }; -- 2.34.1

2 months, 3 weeks

4
4
0 0

[PATCH 0/2] pinctrl: intel: platform: fix error path in device_for_each_child_node()

by Javier Carrasco

This series fixes an error path where the reference of a child node is not decremented upon early return. When at it, a trivial comma/semicolon substitution I found by chance has been added to improve code clarity. Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> --- Javier Carrasco (2): pinctrl: intel: platform: fix error path in device_for_each_child_node() pinctrl: intel: platform: use semicolon instead of comma in ncommunities assignment drivers/pinctrl/intel/pinctrl-intel-platform.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- base-commit: 92fc9636d1471b7f68bfee70c776f7f77e747b97 change-id: 20240926-intel-pinctrl-platform-scoped-68d000ba3c1d Best regards, -- Javier Carrasco <javier.carrasco.cruz(a)gmail.com>

2 months, 3 weeks

3
3
0 0

[PATCH v3 03/10] media: qcom: camss: Fix potential crash if domain attach fails

by Vikram Sharma

Fix a potential crash in camss by ensuring detach is skipped if attach is unsuccessful. Fixes: d89751c61279 ("media: qcom: camss: Add support for named power-domains") CC: stable(a)vger.kernel.org Signed-off-by: Vikram Sharma <quic_vikramsa(a)quicinc.com> --- drivers/media/platform/qcom/camss/camss.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c index d64985ca6e88..b6658df37709 100644 --- a/drivers/media/platform/qcom/camss/camss.c +++ b/drivers/media/platform/qcom/camss/camss.c @@ -2131,8 +2131,7 @@ static int camss_configure_pd(struct camss *camss) camss->genpd = dev_pm_domain_attach_by_name(camss->dev, camss->res->pd_name); if (IS_ERR(camss->genpd)) { - ret = PTR_ERR(camss->genpd); - goto fail_pm; + return PTR_ERR(camss->genpd); } } @@ -2149,7 +2148,7 @@ static int camss_configure_pd(struct camss *camss) ret = -ENODEV; else ret = PTR_ERR(camss->genpd); - goto fail_pm; + return ret; } camss->genpd_link = device_link_add(camss->dev, camss->genpd, DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME | -- 2.25.1

2 months, 3 weeks

1
0
0 0

[PATCH] PM / devfreq: Fix atomicity violation in devfreq_update_interval()

by Qiu-ji Chen

The atomicity violation occurs when the variables cur_delay and new_delay are defined. Imagine a scenario where, while defining cur_delay and new_delay, the values stored in devfreq->profile->polling_ms and the delay variable change. After acquiring the mutex_lock and entering the critical section, due to possible concurrent modifications, cur_delay and new_delay may no longer represent the correct values. Subsequent usage, such as if (cur_delay > new_delay), could cause the program to run incorrectly, resulting in inconsistencies. To address this issue, it is recommended to acquire a lock in advance, ensuring that devfreq->profile->polling_ms and delay are protected by the lock when being read. This will help ensure the consistency of the program. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. Fixes: 7e6fdd4bad03 ("PM / devfreq: Core updates to support devices which can idle") Cc: stable(a)vger.kernel.org Signed-off-by: Qiu-ji Chen <chenqiuji666(a)gmail.com> --- drivers/devfreq/devfreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index 98657d3b9435..9634739fc9cb 100644 --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -616,10 +616,10 @@ EXPORT_SYMBOL(devfreq_monitor_resume); */ void devfreq_update_interval(struct devfreq *devfreq, unsigned int *delay) { + mutex_lock(&devfreq->lock); unsigned int cur_delay = devfreq->profile->polling_ms; unsigned int new_delay = *delay; - mutex_lock(&devfreq->lock); devfreq->profile->polling_ms = new_delay; if (IS_SUPPORTED_FLAG(devfreq->governor->flags, IRQ_DRIVEN)) -- 2.34.1

2 months, 3 weeks

1
1
0 0

[PATCH] Input: adp5588-keys - Added checking of key and key_val variables

by Denis Arefev

If the adp5588_read function returns 0, then there will be an overflow of the kpad->keycode buffer. If the adp5588_read function returns a negative value, then the logic is broken - the wrong value is used as an index of the kpad->keycode array. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: stable(a)vger.kernel.org # v5.10+ Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- drivers/input/keyboard/adp5588-keys.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/input/keyboard/adp5588-keys.c b/drivers/input/keyboard/adp5588-keys.c index 1b0279393df4..d05387f9c11f 100644 --- a/drivers/input/keyboard/adp5588-keys.c +++ b/drivers/input/keyboard/adp5588-keys.c @@ -526,14 +526,17 @@ static void adp5588_report_events(struct adp5588_kpad *kpad, int ev_cnt) int i; for (i = 0; i < ev_cnt; i++) { - int key = adp5588_read(kpad->client, KEY_EVENTA + i); - int key_val = key & KEY_EV_MASK; - int key_press = key & KEY_EV_PRESSED; + int key, key_val, key_press; + key = adp5588_read(kpad->client, KEY_EVENTA + i); + if (key < 0) + continue; + key_val = key & KEY_EV_MASK; + key_press = key & KEY_EV_PRESSED; if (key_val >= GPI_PIN_BASE && key_val <= GPI_PIN_END) { /* gpio line used as IRQ source */ adp5588_gpio_irq_handle(kpad, key_val, key_press); - } else { + } else if (key_val > 0) { int row = (key_val - 1) / ADP5588_COLS_MAX; int col = (key_val - 1) % ADP5588_COLS_MAX; int code = MATRIX_SCAN_CODE(row, col, kpad->row_shift); -- 2.25.1

2 months, 3 weeks

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2024