June 2024 - Linux-stable-mirror

[PATCH stable 4.19 up to 6.8] vxlan: Fix regression when dropping packets due to invalid src addresses

by Daniel Borkmann

[ Upstream commit 1cd4bc987abb2823836cbb8f887026011ccddc8a ] Commit f58f45c1e5b9 ("vxlan: drop packets from invalid src-address") has recently been added to vxlan mainly in the context of source address snooping/learning so that when it is enabled, an entry in the FDB is not being created for an invalid address for the corresponding tunnel endpoint. Before commit f58f45c1e5b9 vxlan was similarly behaving as geneve in that it passed through whichever macs were set in the L2 header. It turns out that this change in behavior breaks setups, for example, Cilium with netkit in L3 mode for Pods as well as tunnel mode has been passing before the change in f58f45c1e5b9 for both vxlan and geneve. After mentioned change it is only passing for geneve as in case of vxlan packets are dropped due to vxlan_set_mac() returning false as source and destination macs are zero which for E/W traffic via tunnel is totally fine. Fix it by only opting into the is_valid_ether_addr() check in vxlan_set_mac() when in fact source address snooping/learning is actually enabled in vxlan. This is done by moving the check into vxlan_snoop(). With this change, the Cilium connectivity test suite passes again for both tunnel flavors. Fixes: f58f45c1e5b9 ("vxlan: drop packets from invalid src-address") Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Cc: David Bauer <mail(a)david-bauer.net> Cc: Ido Schimmel <idosch(a)nvidia.com> Cc: Nikolay Aleksandrov <razor(a)blackwall.org> Cc: Martin KaFai Lau <martin.lau(a)kernel.org> Reviewed-by: Ido Schimmel <idosch(a)nvidia.com> Reviewed-by: Nikolay Aleksandrov <razor(a)blackwall.org> Reviewed-by: David Bauer <mail(a)david-bauer.net> Signed-off-by: David S. Miller <davem(a)davemloft.net> [ Backport note: vxlan snooping/learning not supported in 6.8 or older, so commit is simply a revert. ] Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> --- drivers/net/vxlan/vxlan_core.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c index 0a0b4a9717ce..1d0688610189 100644 --- a/drivers/net/vxlan/vxlan_core.c +++ b/drivers/net/vxlan/vxlan_core.c @@ -1615,10 +1615,6 @@ static bool vxlan_set_mac(struct vxlan_dev *vxlan, if (ether_addr_equal(eth_hdr(skb)->h_source, vxlan->dev->dev_addr)) return false; - /* Ignore packets from invalid src-address */ - if (!is_valid_ether_addr(eth_hdr(skb)->h_source)) - return false; - /* Get address from the outer IP header */ if (vxlan_get_sk_family(vs) == AF_INET) { saddr.sin.sin_addr.s_addr = ip_hdr(skb)->saddr; -- 2.34.1

3 months, 2 weeks

2
1
0 0

FAILED: patch "[PATCH] x86/topology/amd: Evaluate SMT in CPUID leaf 0x8000001e only" failed to apply to 6.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.9.y git checkout FETCH_HEAD git cherry-pick -x 34bf6bae3286a58762711cfbce2cf74ecd42e1b5 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024060624-platinum-ladies-9214@gregkh' --subject-prefix 'PATCH 6.9.y' HEAD^.. Possible dependencies: 34bf6bae3286 ("x86/topology/amd: Evaluate SMT in CPUID leaf 0x8000001e only on family 0x17 and greater") 21f546a43a91 ("Merge branch 'x86/urgent' into x86/cpu, to resolve conflict") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 34bf6bae3286a58762711cfbce2cf74ecd42e1b5 Mon Sep 17 00:00:00 2001 From: Thomas Gleixner <tglx(a)linutronix.de> Date: Tue, 28 May 2024 22:21:31 +0200 Subject: [PATCH] x86/topology/amd: Evaluate SMT in CPUID leaf 0x8000001e only on family 0x17 and greater The new AMD/HYGON topology parser evaluates the SMT information in CPUID leaf 0x8000001e unconditionally while the original code restricted it to CPUs with family 0x17 and greater. This breaks family 0x15 CPUs which advertise that leaf and have a non-zero value in the SMT section. The machine boots, but the scheduler complains loudly about the mismatch of the core IDs: WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6482 sched_cpu_starting+0x183/0x250 WARNING: CPU: 0 PID: 1 at kernel/sched/topology.c:2408 build_sched_domains+0x76b/0x12b0 Add the condition back to cure it. [ bp: Make it actually build because grandpa is not concerned with trivial stuff. :-P ] Fixes: f7fb3b2dd92c ("x86/cpu: Provide an AMD/HYGON specific topology parser") Closes: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/56 Reported-by: Tim Teichmann <teichmanntim(a)outlook.de> Reported-by: Christian Heusel <christian(a)heusel.eu> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Tested-by: Tim Teichmann <teichmanntim(a)outlook.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/7skhx6mwe4hxiul64v6azhlxnokheorksqsdbp7qw6g2jduf6… diff --git a/arch/x86/kernel/cpu/topology_amd.c b/arch/x86/kernel/cpu/topology_amd.c index d419deed6a48..7d476fa697ca 100644 --- a/arch/x86/kernel/cpu/topology_amd.c +++ b/arch/x86/kernel/cpu/topology_amd.c @@ -84,9 +84,9 @@ static bool parse_8000_001e(struct topo_scan *tscan, bool has_topoext) /* * If leaf 0xb is available, then the domain shifts are set - * already and nothing to do here. + * already and nothing to do here. Only valid for family >= 0x17. */ - if (!has_topoext) { + if (!has_topoext && tscan->c->x86 >= 0x17) { /* * Leaf 0x80000008 set the CORE domain shift already. * Update the SMT domain, but do not propagate it.

3 months, 2 weeks

3
3
0 0

[PATCH 6.6.y] mm: ratelimit stat flush from workingset shrinker

by Jesper Dangaard Brouer

From: Shakeel Butt <shakeelb(a)google.com> commit d4a5b369ad6d8aae552752ff438dddde653a72ec upstream. One of our workloads (Postgres 14 + sysbench OLTP) regressed on newer upstream kernel and on further investigation, it seems like the cause is the always synchronous rstat flush in the count_shadow_nodes() added by the commit f82e6bf9bb9b ("mm: memcg: use rstat for non-hierarchical stats"). On further inspection it seems like we don't really need accurate stats in this function as it was already approximating the amount of appropriate shadow entries to keep for maintaining the refault information. Since there is already 2 sec periodic rstat flush, we don't need exact stats here. Let's ratelimit the rstat flush in this code path. Link: https://lkml.kernel.org/r/20231228073055.4046430-1-shakeelb@google.com Fixes: f82e6bf9bb9b ("mm: memcg: use rstat for non-hierarchical stats") Signed-off-by: Shakeel Butt <shakeelb(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Yosry Ahmed <yosryahmed(a)google.com> Cc: Yu Zhao <yuzhao(a)google.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: Muchun Song <songmuchun(a)bytedance.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Jesper Dangaard Brouer <hawk(a)kernel.org> --- On production with kernel v6.6 we are observing issues with excessive cgroup rstat flushing due to the extra call to mem_cgroup_flush_stats() in count_shadow_nodes() introduced in commit f82e6bf9bb9b ("mm: memcg: use rstat for non-hierarchical stats") that commit is part of v6.6. We request backport of commit d4a5b369ad6d ("mm: ratelimit stat flush from workingset shrinker") as it have a fixes tag for this commit. IMHO it is worth explaining call path that makes count_shadow_nodes() cause excessive cgroup rstat flushing calls. Function shrink_node() calls mem_cgroup_flush_stats() on its own first, and then invokes shrink_node_memcgs(). Function shrink_node_memcgs() iterates over cgroups via mem_cgroup_iter() for each calling shrink_slab(). The shrink_slab() calls do_shrink_slab() that via shrinker->count_objects() invoke count_shadow_nodes(), and count_shadow_nodes() does a mem_cgroup_flush_stats() call, that seems unnecessary. Backport differs slightly due to v6.6.32 doesn't contain commit 7d7ef0a4686a ("mm: memcg: restore subtree stats flushing") from v6.8. --- mm/workingset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/workingset.c b/mm/workingset.c index 2559a1f2fc1c..9110957bec5b 100644 --- a/mm/workingset.c +++ b/mm/workingset.c @@ -664,7 +664,7 @@ static unsigned long count_shadow_nodes(struct shrinker *shrinker, struct lruvec *lruvec; int i; - mem_cgroup_flush_stats(); + mem_cgroup_flush_stats_ratelimited(); lruvec = mem_cgroup_lruvec(sc->memcg, NODE_DATA(sc->nid)); for (pages = 0, i = 0; i < NR_LRU_LISTS; i++) pages += lruvec_page_state_local(lruvec,

3 months, 2 weeks

3
3
0 0

Are the 'FAILED' notifications always sent?

by Matthieu Baerts

Hi Sasha, Thank you for the recent backports linked to MPTCP. Recently, I noticed that two patches [1] [2] with the same "Fixes" tag -- but without "Cc: stable", sorry for that -- have been backported to different stable versions. That's good, thank you! The first patch made its way to v5.15, while the second one went up to v6.8, but not to older stable versions. I understand it didn't go further because of other conflicts, and I'm ready to help to fix them. I just wanted to know if it is normal I didn't get any 'FAILED' notifications like the ones Greg send [3]: I rely on them to know which patches have been treated by the Stable team, but had conflicts. Will I get these notifications later (no hurry), or should I not rely on them to track fixes that could not be backported? Cheers, Matt [1] https://lore.kernel.org/mptcp/20240514011335.176158-2-martineau@kernel.org/ [2] https://lore.kernel.org/mptcp/20240514011335.176158-3-martineau@kernel.org/ [3] 'FAILED: patch "[PATCH] (...)" failed to apply to x.y-stable tree' -- Sponsored by the NGI0 Core fund.

3 months, 2 weeks

2
2
0 0

[PATCH 6.6.y 0/3] Backport of "mptcp: fix full TCP keep-alive support"

by Matthieu Baerts (NGI0)

It looks like the patch "mptcp: fix full TCP keep-alive support" has been backported up to v6.8 recently (thanks!), but not before due to conflicts. I had to adapt a bit the code not to backport new features, but the modifications were simple, and isolated from the rest. MPTCP sockopt tests have been executed, and no issues have been reported. Matthieu Baerts (NGI0) (1): mptcp: fix full TCP keep-alive support Paolo Abeni (2): mptcp: avoid some duplicate code in socket option handling mptcp: cleanup SOL_TCP handling net/mptcp/protocol.h | 3 ++ net/mptcp/sockopt.c | 123 +++++++++++++++++++++++++++++-------------- 2 files changed, 87 insertions(+), 39 deletions(-) -- 2.43.0

3 months, 2 weeks

2
4
0 0

[PATCH] Revert "drm/amdgpu: init iommu after amdkfd device init"

by Armin Wolf

This reverts commit 56b522f4668167096a50c39446d6263c96219f5f. A user reported that this commit breaks the integrated gpu of his notebook, causing a black screen. He was able to bisect the problematic commit and verified that by reverting it the notebook works again. He also confirmed that kernel 6.8.1 also works on his device, so the upstream commit itself seems to be ok. An amdgpu developer (Alex Deucher) confirmed that this patch should have never been ported to 5.15 in the first place, so revert this commit from the 5.15 stable series. Reported-by: Barry Kauler <bkauler(a)gmail.com> Signed-off-by: Armin Wolf <W_Armin(a)gmx.de> --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 222a1d9ecf16..5f6c32ec674d 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -2487,6 +2487,10 @@ static int amdgpu_device_ip_init(struct amdgpu_device *adev) if (r) goto init_failed; + r = amdgpu_amdkfd_resume_iommu(adev); + if (r) + goto init_failed; + r = amdgpu_device_ip_hw_init_phase1(adev); if (r) goto init_failed; @@ -2525,10 +2529,6 @@ static int amdgpu_device_ip_init(struct amdgpu_device *adev) if (!adev->gmc.xgmi.pending_reset) amdgpu_amdkfd_device_init(adev); - r = amdgpu_amdkfd_resume_iommu(adev); - if (r) - goto init_failed; - amdgpu_fru_get_product_info(adev); init_failed: -- 2.39.2

3 months, 2 weeks

5
6
0 0

Re: Patch "platform/x86: xiaomi-wmi: Fix race condition when reporting key events" has been added to the 6.6-stable tree

by Armin Wolf

Am 26.05.24 um 21:43 schrieb Sasha Levin: > This is a note to let you know that I've just added the patch titled > > platform/x86: xiaomi-wmi: Fix race condition when reporting key events > > to the 6.6-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > platform-x86-xiaomi-wmi-fix-race-condition-when-repo.patch > and it can be found in the queue-6.6 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > Hi, the underlying race condition can only be triggered since commit e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on all CPUs"), which afaik was introduced with kernel 6.8. Because of this, i do not think that we have to backport this commit to kernels before 6.8. Thanks, Armin Wolf > > commit 831f943a69833152081ec7393af598f0c8b415fa > Author: Armin Wolf <W_Armin(a)gmx.de> > Date: Tue Apr 2 16:30:57 2024 +0200 > > platform/x86: xiaomi-wmi: Fix race condition when reporting key events > > [ Upstream commit 290680c2da8061e410bcaec4b21584ed951479af ] > > Multiple WMI events can be received concurrently, so multiple instances > of xiaomi_wmi_notify() can be active at the same time. Since the input > device is shared between those handlers, the key input sequence can be > disturbed. > > Fix this by protecting the key input sequence with a mutex. > > Compile-tested only. > > Fixes: edb73f4f0247 ("platform/x86: wmi: add Xiaomi WMI key driver") > Signed-off-by: Armin Wolf <W_Armin(a)gmx.de> > Link: https://lore.kernel.org/r/20240402143059.8456-2-W_Armin@gmx.de > Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy(a)linux.intel.com> > Reviewed-by: Hans de Goede <hdegoede(a)redhat.com> > Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/platform/x86/xiaomi-wmi.c b/drivers/platform/x86/xiaomi-wmi.c > index 54a2546bb93bf..be80f0bda9484 100644 > --- a/drivers/platform/x86/xiaomi-wmi.c > +++ b/drivers/platform/x86/xiaomi-wmi.c > @@ -2,8 +2,10 @@ > /* WMI driver for Xiaomi Laptops */ > > #include <linux/acpi.h> > +#include <linux/device.h> > #include <linux/input.h> > #include <linux/module.h> > +#include <linux/mutex.h> > #include <linux/wmi.h> > > #include <uapi/linux/input-event-codes.h> > @@ -20,12 +22,21 @@ > > struct xiaomi_wmi { > struct input_dev *input_dev; > + struct mutex key_lock; /* Protects the key event sequence */ > unsigned int key_code; > }; > > +static void xiaomi_mutex_destroy(void *data) > +{ > + struct mutex *lock = data; > + > + mutex_destroy(lock); > +} > + > static int xiaomi_wmi_probe(struct wmi_device *wdev, const void *context) > { > struct xiaomi_wmi *data; > + int ret; > > if (wdev == NULL || context == NULL) > return -EINVAL; > @@ -35,6 +46,11 @@ static int xiaomi_wmi_probe(struct wmi_device *wdev, const void *context) > return -ENOMEM; > dev_set_drvdata(&wdev->dev, data); > > + mutex_init(&data->key_lock); > + ret = devm_add_action_or_reset(&wdev->dev, xiaomi_mutex_destroy, &data->key_lock); > + if (ret < 0) > + return ret; > + > data->input_dev = devm_input_allocate_device(&wdev->dev); > if (data->input_dev == NULL) > return -ENOMEM; > @@ -59,10 +75,12 @@ static void xiaomi_wmi_notify(struct wmi_device *wdev, union acpi_object *dummy) > if (data == NULL) > return; > > + mutex_lock(&data->key_lock); > input_report_key(data->input_dev, data->key_code, 1); > input_sync(data->input_dev); > input_report_key(data->input_dev, data->key_code, 0); > input_sync(data->input_dev); > + mutex_unlock(&data->key_lock); > } > > static const struct wmi_device_id xiaomi_wmi_id_table[] = {

3 months, 2 weeks

2
1
0 0

FAILED: patch "[PATCH] drm/i915/audio: Fix audio time stamp programming for DP" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x c66b8356273c8d22498f88e4223af47a7bf8a23c # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024051325-ipad-sturdily-5677@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: c66b8356273c ("drm/i915/audio: Fix audio time stamp programming for DP") 46e61ee4e01e ("drm/i915/audio: s/dev_priv/i915/") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From c66b8356273c8d22498f88e4223af47a7bf8a23c Mon Sep 17 00:00:00 2001 From: Chaitanya Kumar Borah <chaitanya.kumar.borah(a)intel.com> Date: Tue, 30 Apr 2024 14:48:25 +0530 Subject: [PATCH] drm/i915/audio: Fix audio time stamp programming for DP Intel hardware is capable of programming the Maud/Naud SDPs on its own based on real-time clocks. While doing so, it takes care of any deviations from the theoretical values. Programming the registers explicitly with static values can interfere with this logic. Therefore, let the HW decide the Maud and Naud SDPs on it's own. Cc: stable(a)vger.kernel.org # v5.17 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8097 Co-developed-by: Kai Vehmanen <kai.vehmanen(a)intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen(a)intel.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah(a)intel.com> Reviewed-by: Uma Shankar <uma.shankar(a)intel.com> Signed-off-by: Animesh Manna <animesh.manna(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430091825.733499-1-chait… (cherry picked from commit 8e056b50d92ae7f4d6895d1c97a69a2a953cf97b) Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c b/drivers/gpu/drm/i915/display/intel_audio.c index 07e0c73204f3..ed81e1466c4b 100644 --- a/drivers/gpu/drm/i915/display/intel_audio.c +++ b/drivers/gpu/drm/i915/display/intel_audio.c @@ -76,19 +76,6 @@ struct intel_audio_funcs { struct intel_crtc_state *crtc_state); }; -/* DP N/M table */ -#define LC_810M 810000 -#define LC_540M 540000 -#define LC_270M 270000 -#define LC_162M 162000 - -struct dp_aud_n_m { - int sample_rate; - int clock; - u16 m; - u16 n; -}; - struct hdmi_aud_ncts { int sample_rate; int clock; @@ -96,60 +83,6 @@ struct hdmi_aud_ncts { int cts; }; -/* Values according to DP 1.4 Table 2-104 */ -static const struct dp_aud_n_m dp_aud_n_m[] = { - { 32000, LC_162M, 1024, 10125 }, - { 44100, LC_162M, 784, 5625 }, - { 48000, LC_162M, 512, 3375 }, - { 64000, LC_162M, 2048, 10125 }, - { 88200, LC_162M, 1568, 5625 }, - { 96000, LC_162M, 1024, 3375 }, - { 128000, LC_162M, 4096, 10125 }, - { 176400, LC_162M, 3136, 5625 }, - { 192000, LC_162M, 2048, 3375 }, - { 32000, LC_270M, 1024, 16875 }, - { 44100, LC_270M, 784, 9375 }, - { 48000, LC_270M, 512, 5625 }, - { 64000, LC_270M, 2048, 16875 }, - { 88200, LC_270M, 1568, 9375 }, - { 96000, LC_270M, 1024, 5625 }, - { 128000, LC_270M, 4096, 16875 }, - { 176400, LC_270M, 3136, 9375 }, - { 192000, LC_270M, 2048, 5625 }, - { 32000, LC_540M, 1024, 33750 }, - { 44100, LC_540M, 784, 18750 }, - { 48000, LC_540M, 512, 11250 }, - { 64000, LC_540M, 2048, 33750 }, - { 88200, LC_540M, 1568, 18750 }, - { 96000, LC_540M, 1024, 11250 }, - { 128000, LC_540M, 4096, 33750 }, - { 176400, LC_540M, 3136, 18750 }, - { 192000, LC_540M, 2048, 11250 }, - { 32000, LC_810M, 1024, 50625 }, - { 44100, LC_810M, 784, 28125 }, - { 48000, LC_810M, 512, 16875 }, - { 64000, LC_810M, 2048, 50625 }, - { 88200, LC_810M, 1568, 28125 }, - { 96000, LC_810M, 1024, 16875 }, - { 128000, LC_810M, 4096, 50625 }, - { 176400, LC_810M, 3136, 28125 }, - { 192000, LC_810M, 2048, 16875 }, -}; - -static const struct dp_aud_n_m * -audio_config_dp_get_n_m(const struct intel_crtc_state *crtc_state, int rate) -{ - int i; - - for (i = 0; i < ARRAY_SIZE(dp_aud_n_m); i++) { - if (rate == dp_aud_n_m[i].sample_rate && - crtc_state->port_clock == dp_aud_n_m[i].clock) - return &dp_aud_n_m[i]; - } - - return NULL; -} - static const struct { int clock; u32 config; @@ -387,47 +320,17 @@ hsw_dp_audio_config_update(struct intel_encoder *encoder, const struct intel_crtc_state *crtc_state) { struct drm_i915_private *i915 = to_i915(encoder->base.dev); - struct i915_audio_component *acomp = i915->display.audio.component; enum transcoder cpu_transcoder = crtc_state->cpu_transcoder; - enum port port = encoder->port; - const struct dp_aud_n_m *nm; - int rate; - u32 tmp; - rate = acomp ? acomp->aud_sample_rate[port] : 0; - nm = audio_config_dp_get_n_m(crtc_state, rate); - if (nm) - drm_dbg_kms(&i915->drm, "using Maud %u, Naud %u\n", nm->m, - nm->n); - else - drm_dbg_kms(&i915->drm, "using automatic Maud, Naud\n"); + /* Enable time stamps. Let HW calculate Maud/Naud values */ + intel_de_rmw(i915, HSW_AUD_CFG(cpu_transcoder), + AUD_CONFIG_N_VALUE_INDEX | + AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK | + AUD_CONFIG_UPPER_N_MASK | + AUD_CONFIG_LOWER_N_MASK | + AUD_CONFIG_N_PROG_ENABLE, + AUD_CONFIG_N_VALUE_INDEX); - tmp = intel_de_read(i915, HSW_AUD_CFG(cpu_transcoder)); - tmp &= ~AUD_CONFIG_N_VALUE_INDEX; - tmp &= ~AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK; - tmp &= ~AUD_CONFIG_N_PROG_ENABLE; - tmp |= AUD_CONFIG_N_VALUE_INDEX; - - if (nm) { - tmp &= ~AUD_CONFIG_N_MASK; - tmp |= AUD_CONFIG_N(nm->n); - tmp |= AUD_CONFIG_N_PROG_ENABLE; - } - - intel_de_write(i915, HSW_AUD_CFG(cpu_transcoder), tmp); - - tmp = intel_de_read(i915, HSW_AUD_M_CTS_ENABLE(cpu_transcoder)); - tmp &= ~AUD_CONFIG_M_MASK; - tmp &= ~AUD_M_CTS_M_VALUE_INDEX; - tmp &= ~AUD_M_CTS_M_PROG_ENABLE; - - if (nm) { - tmp |= nm->m; - tmp |= AUD_M_CTS_M_VALUE_INDEX; - tmp |= AUD_M_CTS_M_PROG_ENABLE; - } - - intel_de_write(i915, HSW_AUD_M_CTS_ENABLE(cpu_transcoder), tmp); } static void

3 months, 2 weeks

3
2
0 0

FAILED: patch "[PATCH] nilfs2: fix use-after-free of timer for log writer thread" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x f5d4e04634c9cf68bdf23de08ada0bb92e8befe7 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024052603-deceiving-stood-2b59@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f5d4e04634c9cf68bdf23de08ada0bb92e8befe7 Mon Sep 17 00:00:00 2001 From: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Date: Mon, 20 May 2024 22:26:19 +0900 Subject: [PATCH] nilfs2: fix use-after-free of timer for log writer thread Patch series "nilfs2: fix log writer related issues". This bug fix series covers three nilfs2 log writer-related issues, including a timer use-after-free issue and potential deadlock issue on unmount, and a potential freeze issue in event synchronization found during their analysis. Details are described in each commit log. This patch (of 3): A use-after-free issue has been reported regarding the timer sc_timer on the nilfs_sc_info structure. The problem is that even though it is used to wake up a sleeping log writer thread, sc_timer is not shut down until the nilfs_sc_info structure is about to be freed, and is used regardless of the thread's lifetime. Fix this issue by limiting the use of sc_timer only while the log writer thread is alive. Link: https://lkml.kernel.org/r/20240520132621.4054-1-konishi.ryusuke@gmail.com Link: https://lkml.kernel.org/r/20240520132621.4054-2-konishi.ryusuke@gmail.com Fixes: fdce895ea5dd ("nilfs2: change sc_timer from a pointer to an embedded one in struct nilfs_sc_info") Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Reported-by: "Bai, Shuangpeng" <sjb7183(a)psu.edu> Closes: https://groups.google.com/g/syzkaller/c/MK_LYqtt8ko/m/8rgdWeseAwAJ Tested-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c index 6be7dd423fbd..7cb34e1c9206 100644 --- a/fs/nilfs2/segment.c +++ b/fs/nilfs2/segment.c @@ -2118,8 +2118,10 @@ static void nilfs_segctor_start_timer(struct nilfs_sc_info *sci) { spin_lock(&sci->sc_state_lock); if (!(sci->sc_state & NILFS_SEGCTOR_COMMIT)) { - sci->sc_timer.expires = jiffies + sci->sc_interval; - add_timer(&sci->sc_timer); + if (sci->sc_task) { + sci->sc_timer.expires = jiffies + sci->sc_interval; + add_timer(&sci->sc_timer); + } sci->sc_state |= NILFS_SEGCTOR_COMMIT; } spin_unlock(&sci->sc_state_lock); @@ -2320,10 +2322,21 @@ int nilfs_construct_dsync_segment(struct super_block *sb, struct inode *inode, */ static void nilfs_segctor_accept(struct nilfs_sc_info *sci) { + bool thread_is_alive; + spin_lock(&sci->sc_state_lock); sci->sc_seq_accepted = sci->sc_seq_request; + thread_is_alive = (bool)sci->sc_task; spin_unlock(&sci->sc_state_lock); - del_timer_sync(&sci->sc_timer); + + /* + * This function does not race with the log writer thread's + * termination. Therefore, deleting sc_timer, which should not be + * done after the log writer thread exits, can be done safely outside + * the area protected by sc_state_lock. + */ + if (thread_is_alive) + del_timer_sync(&sci->sc_timer); } /** @@ -2349,7 +2362,7 @@ static void nilfs_segctor_notify(struct nilfs_sc_info *sci, int mode, int err) sci->sc_flush_request &= ~FLUSH_DAT_BIT; /* re-enable timer if checkpoint creation was not done */ - if ((sci->sc_state & NILFS_SEGCTOR_COMMIT) && + if ((sci->sc_state & NILFS_SEGCTOR_COMMIT) && sci->sc_task && time_before(jiffies, sci->sc_timer.expires)) add_timer(&sci->sc_timer); } @@ -2539,6 +2552,7 @@ static int nilfs_segctor_thread(void *arg) int timeout = 0; sci->sc_timer_task = current; + timer_setup(&sci->sc_timer, nilfs_construction_timeout, 0); /* start sync. */ sci->sc_task = current; @@ -2606,6 +2620,7 @@ static int nilfs_segctor_thread(void *arg) end_thread: /* end sync. */ sci->sc_task = NULL; + timer_shutdown_sync(&sci->sc_timer); wake_up(&sci->sc_wait_task); /* for nilfs_segctor_kill_thread() */ spin_unlock(&sci->sc_state_lock); return 0; @@ -2669,7 +2684,6 @@ static struct nilfs_sc_info *nilfs_segctor_new(struct super_block *sb, INIT_LIST_HEAD(&sci->sc_gc_inodes); INIT_LIST_HEAD(&sci->sc_iput_queue); INIT_WORK(&sci->sc_iput_work, nilfs_iput_work_func); - timer_setup(&sci->sc_timer, nilfs_construction_timeout, 0); sci->sc_interval = HZ * NILFS_SC_DEFAULT_TIMEOUT; sci->sc_mjcp_freq = HZ * NILFS_SC_DEFAULT_SR_FREQ; @@ -2748,7 +2762,6 @@ static void nilfs_segctor_destroy(struct nilfs_sc_info *sci) down_write(&nilfs->ns_segctor_sem); - timer_shutdown_sync(&sci->sc_timer); kfree(sci); }

3 months, 2 weeks

3
2
0 0

[PATCH MANUALSEL 4.19 1/2] KVM: x86: Handle SRCU initialization failure during page track init

by Sasha Levin

From: Haimin Zhang <tcs_kernel(a)tencent.com> [ Upstream commit eb7511bf9182292ef1df1082d23039e856d1ddfb ] Check the return of init_srcu_struct(), which can fail due to OOM, when initializing the page track mechanism. Lack of checking leads to a NULL pointer deref found by a modified syzkaller. Reported-by: TCS Robot <tcs_robot(a)tencent.com> Signed-off-by: Haimin Zhang <tcs_kernel(a)tencent.com> Message-Id: <1630636626-12262-1-git-send-email-tcs_kernel(a)tencent.com> [Move the call towards the beginning of kvm_arch_init_vm. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/x86/include/asm/kvm_page_track.h | 2 +- arch/x86/kvm/page_track.c | 4 ++-- arch/x86/kvm/x86.c | 7 ++++++- 3 files changed, 9 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/kvm_page_track.h b/arch/x86/include/asm/kvm_page_track.h index 172f9749dbb2..5986bd4aacd6 100644 --- a/arch/x86/include/asm/kvm_page_track.h +++ b/arch/x86/include/asm/kvm_page_track.h @@ -46,7 +46,7 @@ struct kvm_page_track_notifier_node { struct kvm_page_track_notifier_node *node); }; -void kvm_page_track_init(struct kvm *kvm); +int kvm_page_track_init(struct kvm *kvm); void kvm_page_track_cleanup(struct kvm *kvm); void kvm_page_track_free_memslot(struct kvm_memory_slot *free, diff --git a/arch/x86/kvm/page_track.c b/arch/x86/kvm/page_track.c index 3052a59a3065..1f6b0d9b0c85 100644 --- a/arch/x86/kvm/page_track.c +++ b/arch/x86/kvm/page_track.c @@ -169,13 +169,13 @@ void kvm_page_track_cleanup(struct kvm *kvm) cleanup_srcu_struct(&head->track_srcu); } -void kvm_page_track_init(struct kvm *kvm) +int kvm_page_track_init(struct kvm *kvm) { struct kvm_page_track_notifier_head *head; head = &kvm->arch.track_notifier_head; - init_srcu_struct(&head->track_srcu); INIT_HLIST_HEAD(&head->track_notifier_list); + return init_srcu_struct(&head->track_srcu); } /* diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 417abc9ba1ad..70cb18f89029 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -9039,9 +9039,15 @@ void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) int kvm_arch_init_vm(struct kvm *kvm, unsigned long type) { + int ret; + if (type) return -EINVAL; + ret = kvm_page_track_init(kvm); + if (ret) + return ret; + INIT_HLIST_HEAD(&kvm->arch.mask_notifier_list); INIT_LIST_HEAD(&kvm->arch.active_mmu_pages); INIT_LIST_HEAD(&kvm->arch.zapped_obsolete_pages); @@ -9068,7 +9074,6 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type) INIT_DELAYED_WORK(&kvm->arch.kvmclock_sync_work, kvmclock_sync_fn); kvm_hv_init_vm(kvm); - kvm_page_track_init(kvm); kvm_mmu_init_vm(kvm); if (kvm_x86_ops->vm_init) -- 2.33.0

3 months, 2 weeks

4
4
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2024