August 2024 - Linux-stable-mirror

[PATCH] rtc: at91sam9: fix OF node leak in probe() error path

by Krzysztof Kozlowski

Driver is leaking an OF node reference obtained from of_parse_phandle_with_fixed_args(). Fixes: 43e112bb3dea ("rtc: at91sam9: make use of syscon/regmap to access GPBR registers") Cc: <stable(a)vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- drivers/rtc/rtc-at91sam9.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/rtc/rtc-at91sam9.c b/drivers/rtc/rtc-at91sam9.c index f93bee96e362..993c0878fb66 100644 --- a/drivers/rtc/rtc-at91sam9.c +++ b/drivers/rtc/rtc-at91sam9.c @@ -368,6 +368,7 @@ static int at91_rtc_probe(struct platform_device *pdev) return ret; rtc->gpbr = syscon_node_to_regmap(args.np); + of_node_put(args.np); rtc->gpbr_offset = args.args[0]; if (IS_ERR(rtc->gpbr)) { dev_err(&pdev->dev, "failed to retrieve gpbr regmap, aborting.\n"); -- 2.43.0

3 weeks, 2 days

4
5
0 0

[PATCH] usb: dwc3: Runtime get and put usb power_supply handle

by Kyle Tso

It is possible that the usb power_supply is registered after the probe of dwc3. In this case, trying to get the usb power_supply during the probe will fail and there is no chance to try again. Also the usb power_supply might be unregistered at anytime so that the handle of it in dwc3 would become invalid. To fix this, get the handle right before calling to power_supply functions and put it afterward. Fixes: 6f0764b5adea ("usb: dwc3: add a power supply for current control") Cc: stable(a)vger.kernel.org Signed-off-by: Kyle Tso <kyletso(a)google.com> --- drivers/usb/dwc3/core.c | 25 +++++-------------------- drivers/usb/dwc3/core.h | 4 ++-- drivers/usb/dwc3/gadget.c | 19 ++++++++++++++----- 3 files changed, 21 insertions(+), 27 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 734de2a8bd21..ab563edd9b4c 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -1631,8 +1631,6 @@ static void dwc3_get_properties(struct dwc3 *dwc) u8 tx_thr_num_pkt_prd = 0; u8 tx_max_burst_prd = 0; u8 tx_fifo_resize_max_num; - const char *usb_psy_name; - int ret; /* default to highest possible threshold */ lpm_nyet_threshold = 0xf; @@ -1667,12 +1665,7 @@ static void dwc3_get_properties(struct dwc3 *dwc) dwc->sys_wakeup = device_may_wakeup(dwc->sysdev); - ret = device_property_read_string(dev, "usb-psy-name", &usb_psy_name); - if (ret >= 0) { - dwc->usb_psy = power_supply_get_by_name(usb_psy_name); - if (!dwc->usb_psy) - dev_err(dev, "couldn't get usb power supply\n"); - } + device_property_read_string(dev, "usb-psy-name", &dwc->usb_psy_name); dwc->has_lpm_erratum = device_property_read_bool(dev, "snps,has-lpm-erratum"); @@ -2133,18 +2126,16 @@ static int dwc3_probe(struct platform_device *pdev) dwc3_get_software_properties(dwc); dwc->reset = devm_reset_control_array_get_optional_shared(dev); - if (IS_ERR(dwc->reset)) { - ret = PTR_ERR(dwc->reset); - goto err_put_psy; - } + if (IS_ERR(dwc->reset)) + return PTR_ERR(dwc->reset); ret = dwc3_get_clocks(dwc); if (ret) - goto err_put_psy; + return ret; ret = reset_control_deassert(dwc->reset); if (ret) - goto err_put_psy; + return ret; ret = dwc3_clk_enable(dwc); if (ret) @@ -2245,9 +2236,6 @@ static int dwc3_probe(struct platform_device *pdev) dwc3_clk_disable(dwc); err_assert_reset: reset_control_assert(dwc->reset); -err_put_psy: - if (dwc->usb_psy) - power_supply_put(dwc->usb_psy); return ret; } @@ -2276,9 +2264,6 @@ static void dwc3_remove(struct platform_device *pdev) pm_runtime_set_suspended(&pdev->dev); dwc3_free_event_buffers(dwc); - - if (dwc->usb_psy) - power_supply_put(dwc->usb_psy); } #ifdef CONFIG_PM diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index 1e561fd8b86e..ecfe2cc224f7 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -1045,7 +1045,7 @@ struct dwc3_scratchpad_array { * @role_sw: usb_role_switch handle * @role_switch_default_mode: default operation mode of controller while * usb role is USB_ROLE_NONE. - * @usb_psy: pointer to power supply interface. + * @usb_psy_name: name of the usb power supply interface. * @usb2_phy: pointer to USB2 PHY * @usb3_phy: pointer to USB3 PHY * @usb2_generic_phy: pointer to array of USB2 PHYs @@ -1223,7 +1223,7 @@ struct dwc3 { struct usb_role_switch *role_sw; enum usb_dr_mode role_switch_default_mode; - struct power_supply *usb_psy; + const char *usb_psy_name; u32 fladj; u32 ref_clk_per; diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 89fc690fdf34..c89b5b5a64cf 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -3049,20 +3049,29 @@ static void dwc3_gadget_set_ssp_rate(struct usb_gadget *g, static int dwc3_gadget_vbus_draw(struct usb_gadget *g, unsigned int mA) { - struct dwc3 *dwc = gadget_to_dwc(g); + struct dwc3 *dwc = gadget_to_dwc(g); + struct power_supply *usb_psy; union power_supply_propval val = {0}; int ret; if (dwc->usb2_phy) return usb_phy_set_power(dwc->usb2_phy, mA); - if (!dwc->usb_psy) + if (!dwc->usb_psy_name) return -EOPNOTSUPP; - val.intval = 1000 * mA; - ret = power_supply_set_property(dwc->usb_psy, POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT, &val); + usb_psy = power_supply_get_by_name(dwc->usb_psy_name); + if (usb_psy) { + val.intval = 1000 * mA; + ret = power_supply_set_property(usb_psy, POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT, + &val); + power_supply_put(usb_psy); + return ret; + } - return ret; + dev_err(dwc->dev, "couldn't get usb power supply\n"); + + return -EOPNOTSUPP; } /** -- 2.45.2.993.g49e7a77208-goog

3 weeks, 2 days

3
2
0 0

[PATCH] Revert "f2fs: stop allocating pinned sections if EAGAIN happens"

by Wu Bo

This reverts commit 2e42b7f817acd6e8d78226445eb6fe44fe79c12a. If the GC victim section has a pinned block when fallocate() trigger FG_GC, the section is not able to be recycled. And this will return -EAGAIN cause fallocate() failed, even though there are much spare space as user see. As the GC policy prone to chose the same victim, fallocate() may not successed at a long period. This scenario has been found during Android OTA. Link: https://lore.kernel.org/linux-f2fs-devel/20231030094024.263707-1-bo.wu@vivo… CC: stable(a)vger.kernel.org Signed-off-by: Wu Bo <bo.wu(a)vivo.com> --- fs/f2fs/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index b58ab1157b7e..19915faccee9 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -1725,7 +1725,7 @@ static int f2fs_expand_inode_data(struct inode *inode, loff_t offset, f2fs_down_write(&sbi->gc_lock); stat_inc_gc_call_count(sbi, FOREGROUND); err = f2fs_gc(sbi, &gc_control); - if (err && err != -ENODATA) + if (err && err != -ENODATA && err != -EAGAIN) goto out_err; } -- 2.25.1

3 weeks, 3 days

4
7
0 0

FAILED: patch "[PATCH] memcg: protect concurrent access to mem_cgroup_idr" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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-5.10.y git checkout FETCH_HEAD git cherry-pick -x 9972605a238339b85bd16b084eed5f18414d22db # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024081218-demote-shakily-f31c@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 9972605a2383 ("memcg: protect concurrent access to mem_cgroup_idr") 6f0df8e16eb5 ("memcontrol: ensure memcg acquired by id is properly set up") e4dde56cd208 ("mm: multi-gen LRU: per-node lru_gen_folio lists") 7348cc91821b ("mm: multi-gen LRU: remove aging fairness safeguard") a579086c99ed ("mm: multi-gen LRU: remove eviction fairness safeguard") adb8213014b2 ("mm: memcg: fix stale protection of reclaim target memcg") 57e9cc50f4dd ("mm: vmscan: split khugepaged stats from direct reclaim stats") e4fea72b1438 ("mglru: mm/vmscan.c: fix imprecise comments") d396def5d86d ("memcg: rearrange code") 410f8e82689e ("memcg: extract memcg_vmstats from struct mem_cgroup") d6c3af7d8a2b ("mm: multi-gen LRU: debugfs interface") 1332a809d95a ("mm: multi-gen LRU: thrashing prevention") 354ed5974429 ("mm: multi-gen LRU: kill switch") f76c83378851 ("mm: multi-gen LRU: optimize multiple memcgs") bd74fdaea146 ("mm: multi-gen LRU: support page table walks") 018ee47f1489 ("mm: multi-gen LRU: exploit locality in rmap") ac35a4902374 ("mm: multi-gen LRU: minimal implementation") ec1c86b25f4b ("mm: multi-gen LRU: groundwork") f1e1a7be4718 ("mm/vmscan.c: refactor shrink_node()") d3629af59f41 ("mm/vmscan: make the annotations of refaults code at the right place") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 9972605a238339b85bd16b084eed5f18414d22db Mon Sep 17 00:00:00 2001 From: Shakeel Butt <shakeel.butt(a)linux.dev> Date: Fri, 2 Aug 2024 16:58:22 -0700 Subject: [PATCH] memcg: protect concurrent access to mem_cgroup_idr Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected through cgroup_mutex from concurrent modifications. However idr_remove() for mem_cgroup_idr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that. We have been seeing list_lru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of list_lru code including list_lru_add(), list_lru_del() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the super_block's list_lru didn't have list_lru_one for the memcg of that object. The initial suspicions were either the object is not allocated through kmem_cache_alloc_lru() or somehow memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but returned success. No evidence were found for these cases. Looking more deeply, we started seeing situations where valid memcg's id is not present in mem_cgroup_idr and in some cases multiple valid memcgs have same id and mem_cgroup_idr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idr_remove() calls or race between idr_alloc()/idr_replace() and idr_remove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup list_lrus on the system for all of them. Later access from other memcgs to the list_lru cause crashes due to missing list_lru_one. Link: https://lkml.kernel.org/r/20240802235822.1830976-1-shakeel.butt@linux.dev Fixes: 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") Signed-off-by: Shakeel Butt <shakeel.butt(a)linux.dev> Acked-by: Muchun Song <muchun.song(a)linux.dev> Reviewed-by: Roman Gushchin <roman.gushchin(a)linux.dev> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 960371788687..f29157288b7d 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -3386,11 +3386,28 @@ static void memcg_wb_domain_size_changed(struct mem_cgroup *memcg) #define MEM_CGROUP_ID_MAX ((1UL << MEM_CGROUP_ID_SHIFT) - 1) static DEFINE_IDR(mem_cgroup_idr); +static DEFINE_SPINLOCK(memcg_idr_lock); + +static int mem_cgroup_alloc_id(void) +{ + int ret; + + idr_preload(GFP_KERNEL); + spin_lock(&memcg_idr_lock); + ret = idr_alloc(&mem_cgroup_idr, NULL, 1, MEM_CGROUP_ID_MAX + 1, + GFP_NOWAIT); + spin_unlock(&memcg_idr_lock); + idr_preload_end(); + return ret; +} static void mem_cgroup_id_remove(struct mem_cgroup *memcg) { if (memcg->id.id > 0) { + spin_lock(&memcg_idr_lock); idr_remove(&mem_cgroup_idr, memcg->id.id); + spin_unlock(&memcg_idr_lock); + memcg->id.id = 0; } } @@ -3524,8 +3541,7 @@ static struct mem_cgroup *mem_cgroup_alloc(struct mem_cgroup *parent) if (!memcg) return ERR_PTR(error); - memcg->id.id = idr_alloc(&mem_cgroup_idr, NULL, - 1, MEM_CGROUP_ID_MAX + 1, GFP_KERNEL); + memcg->id.id = mem_cgroup_alloc_id(); if (memcg->id.id < 0) { error = memcg->id.id; goto fail; @@ -3667,7 +3683,9 @@ static int mem_cgroup_css_online(struct cgroup_subsys_state *css) * publish it here at the end of onlining. This matches the * regular ID destruction during offlining. */ + spin_lock(&memcg_idr_lock); idr_replace(&mem_cgroup_idr, memcg, memcg->id.id); + spin_unlock(&memcg_idr_lock); return 0; offline_kmem:

3 weeks, 3 days

4
8
0 0

[PATCH net v2] net: drop bad gso csum_start and offset in virtio_net_hdr

by Willem de Bruijn

From: Willem de Bruijn <willemb(a)google.com> Tighten csum_start and csum_offset checks in virtio_net_hdr_to_skb for GSO packets. The function already checks that a checksum requested with VIRTIO_NET_HDR_F_NEEDS_CSUM is in skb linear. But for GSO packets this might not hold for segs after segmentation. Syzkaller demonstrated to reach this warning in skb_checksum_help offset = skb_checksum_start_offset(skb); ret = -EINVAL; if (WARN_ON_ONCE(offset >= skb_headlen(skb))) By injecting a TSO packet: WARNING: CPU: 1 PID: 3539 at net/core/dev.c:3284 skb_checksum_help+0x3d0/0x5b0 ip_do_fragment+0x209/0x1b20 net/ipv4/ip_output.c:774 ip_finish_output_gso net/ipv4/ip_output.c:279 [inline] __ip_finish_output+0x2bd/0x4b0 net/ipv4/ip_output.c:301 iptunnel_xmit+0x50c/0x930 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x2296/0x2c70 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x759/0xa60 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4850 [inline] netdev_start_xmit include/linux/netdevice.h:4864 [inline] xmit_one net/core/dev.c:3595 [inline] dev_hard_start_xmit+0x261/0x8c0 net/core/dev.c:3611 __dev_queue_xmit+0x1b97/0x3c90 net/core/dev.c:4261 packet_snd net/packet/af_packet.c:3073 [inline] The geometry of the bad input packet at tcp_gso_segment: [ 52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0 [ 52.003050][ T8403] mac=(168,24) mac_len=24 net=(192,52) trans=244 [ 52.003050][ T8403] shinfo(txflags=0 nr_frags=1 gso(size=1552 type=3 segs=0)) [ 52.003050][ T8403] csum(0x60000c7 start=199 offset=1536 ip_summed=3 complete_sw=0 valid=0 level=0) Mitigate with stricter input validation. csum_offset: for GSO packets, deduce the correct value from gso_type. This is already done for USO. Extend it to TSO. Let UFO be: udp[46]_ufo_fragment ignores these fields and always computes the checksum in software. csum_start: finding the real offset requires parsing to the transport header. Do not add a parser, use existing segmentation parsing. Thanks to SKB_GSO_DODGY, that also catches bad packets that are hw offloaded. Again test both TSO and USO. Do not test UFO for the above reason, and do not test UDP tunnel offload. GSO packet are almost always CHECKSUM_PARTIAL. USO packets may be CHECKSUM_NONE since commit 10154dbded6d6 ("udp: Allow GSO transmit from devices with no checksum offload"), but then still these fields are initialized correctly in udp4_hwcsum/udp6_hwcsum_outgoing. So no need to test for ip_summed == CHECKSUM_PARTIAL first. This revises an existing fix mentioned in the Fixes tag, which broke small packets with GSO offload, as detected by kselftests. Link: https://syzkaller.appspot.com/bug?extid=e1db31216c789f552871 Link: https://lore.kernel.org/netdev/20240723223109.2196886-1-kuba@kernel.org Fixes: e269d79c7d35 ("net: missing check virtio") Cc: stable(a)vger.kernel.org Signed-off-by: Willem de Bruijn <willemb(a)google.com> --- v1->v2 - skb_transport_header instead of skb->transport_header (edumazet@) - typo: migitate -> mitigate --- include/linux/virtio_net.h | 16 +++++----------- net/ipv4/tcp_offload.c | 3 +++ net/ipv4/udp_offload.c | 4 ++++ 3 files changed, 12 insertions(+), 11 deletions(-) diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h index d1d7825318c32..6c395a2600e8d 100644 --- a/include/linux/virtio_net.h +++ b/include/linux/virtio_net.h @@ -56,7 +56,6 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb, unsigned int thlen = 0; unsigned int p_off = 0; unsigned int ip_proto; - u64 ret, remainder, gso_size; if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) { switch (hdr->gso_type & ~VIRTIO_NET_HDR_GSO_ECN) { @@ -99,16 +98,6 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb, u32 off = __virtio16_to_cpu(little_endian, hdr->csum_offset); u32 needed = start + max_t(u32, thlen, off + sizeof(__sum16)); - if (hdr->gso_size) { - gso_size = __virtio16_to_cpu(little_endian, hdr->gso_size); - ret = div64_u64_rem(skb->len, gso_size, &remainder); - if (!(ret && (hdr->gso_size > needed) && - ((remainder > needed) || (remainder == 0)))) { - return -EINVAL; - } - skb_shinfo(skb)->tx_flags |= SKBFL_SHARED_FRAG; - } - if (!pskb_may_pull(skb, needed)) return -EINVAL; @@ -182,6 +171,11 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb, if (gso_type != SKB_GSO_UDP_L4) return -EINVAL; break; + case SKB_GSO_TCPV4: + case SKB_GSO_TCPV6: + if (skb->csum_offset != offsetof(struct tcphdr, check)) + return -EINVAL; + break; } /* Kernel has a special handling for GSO_BY_FRAGS. */ diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c index 4b791e74529e1..e4ad3311e1489 100644 --- a/net/ipv4/tcp_offload.c +++ b/net/ipv4/tcp_offload.c @@ -140,6 +140,9 @@ struct sk_buff *tcp_gso_segment(struct sk_buff *skb, if (thlen < sizeof(*th)) goto out; + if (unlikely(skb_checksum_start(skb) != skb_transport_header(skb))) + goto out; + if (!pskb_may_pull(skb, thlen)) goto out; diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c index aa2e0a28ca613..bc8a9da750fed 100644 --- a/net/ipv4/udp_offload.c +++ b/net/ipv4/udp_offload.c @@ -278,6 +278,10 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb, if (gso_skb->len <= sizeof(*uh) + mss) return ERR_PTR(-EINVAL); + if (unlikely(skb_checksum_start(gso_skb) != + skb_transport_header(gso_skb))) + return ERR_PTR(-EINVAL); + if (skb_gso_ok(gso_skb, features | NETIF_F_GSO_ROBUST)) { /* Packet is from an untrusted source, reset gso_segs. */ skb_shinfo(gso_skb)->gso_segs = DIV_ROUND_UP(gso_skb->len - sizeof(*uh), -- 2.46.0.rc1.232.g9752f9e123-goog

3 weeks, 3 days

9
18
0 0

[PATCH] wifi: mwifiex: Ensure all STA and AP use the same channel

by Sascha Hauer

The mwifiex chips support simultaneous Accesspoint and station mode, but this only works when all are using the same channel. The downstream driver uses ECSA which makes the Accesspoint automatically switch to the channel the station is going to use. Until this is implemented in the mwifiex driver at least catch this situation and bail out with an error. Userspace doesn't have a meaningful way to figure out what went wrong, so print an error message to give the user a clue. Without this patch the driver would timeout on the HostCmd_CMD_802_11_ASSOCIATE command when creating a station with a channel different from the one that an existing accesspoint uses. Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de> Cc: stable(a)vger.kernel.org --- drivers/net/wireless/marvell/mwifiex/cfg80211.c | 52 ++++++++++++++++++++++++ drivers/net/wireless/marvell/mwifiex/main.h | 1 + drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 3 ++ 3 files changed, 56 insertions(+) diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c index 5697a02e6b8d3..0d3bf624cd3de 100644 --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c @@ -2054,6 +2054,55 @@ static int mwifiex_cfg80211_stop_ap(struct wiphy *wiphy, struct net_device *dev, return 0; } +bool mwifiex_channel_conflict(struct mwifiex_private *priv, struct ieee80211_channel *ch) +{ + struct mwifiex_adapter *adapter = priv->adapter; + struct mwifiex_current_bss_params *bss_params; + u8 band; + int freq, i; + + for (i = 0; i < adapter->priv_num; i++) { + struct mwifiex_private *p = adapter->priv[i]; + struct ieee80211_channel *used = NULL; + + if (p == priv) + continue; + + switch (GET_BSS_ROLE(p)) { + case MWIFIEX_BSS_ROLE_UAP: + if (!netif_carrier_ok(p->netdev)) + break; + + if (!cfg80211_chandef_valid(&p->bss_chandef)) + break; + + used = p->bss_chandef.chan; + + break; + case MWIFIEX_BSS_ROLE_STA: + if (!p->media_connected) + break; + + bss_params = &p->curr_bss_params; + band = mwifiex_band_to_radio_type(bss_params->band); + freq = ieee80211_channel_to_frequency(bss_params->bss_descriptor.channel, + band); + + used = ieee80211_get_channel(priv->wdev.wiphy, freq); + + break; + } + + if (used && !ieee80211_channel_equal(used, ch)) { + mwifiex_dbg(priv->adapter, MSG, + "all AP and STA must operate on same channel\n"); + return false; + } + } + + return true; +} + /* cfg80211 operation handler for start_ap. * Function sets beacon period, DTIM period, SSID and security into * AP config structure. @@ -2069,6 +2118,9 @@ static int mwifiex_cfg80211_start_ap(struct wiphy *wiphy, if (GET_BSS_ROLE(priv) != MWIFIEX_BSS_ROLE_UAP) return -1; + if (!mwifiex_channel_conflict(priv, params->chandef.chan)) + return -EBUSY; + bss_cfg = kzalloc(sizeof(struct mwifiex_uap_bss_param), GFP_KERNEL); if (!bss_cfg) return -ENOMEM; diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h index 529863edd7a25..b68dbf884156b 100644 --- a/drivers/net/wireless/marvell/mwifiex/main.h +++ b/drivers/net/wireless/marvell/mwifiex/main.h @@ -1697,6 +1697,7 @@ int mwifiex_set_mac_address(struct mwifiex_private *priv, struct net_device *dev, bool external, u8 *new_mac); void mwifiex_devdump_tmo_func(unsigned long function_context); +bool mwifiex_channel_conflict(struct mwifiex_private *priv, struct ieee80211_channel *ch); #ifdef CONFIG_DEBUG_FS void mwifiex_debugfs_init(void); diff --git a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c index d3cba6895f8ce..9794816d8a0c6 100644 --- a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c +++ b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c @@ -291,6 +291,9 @@ int mwifiex_bss_start(struct mwifiex_private *priv, struct cfg80211_bss *bss, if (!bss_desc) return -1; + if (!mwifiex_channel_conflict(priv, bss->channel)) + return -EBUSY; + if (mwifiex_band_to_radio_type(bss_desc->bss_band) == HostCmd_SCAN_RADIO_TYPE_BG) { config_bands = BAND_B | BAND_G | BAND_GN; --- base-commit: 67a72043aa2e6f60f7bbe7bfa598ba168f16d04f change-id: 20240830-mwifiex-check-channel-f411a156bbe0 Best regards, -- Sascha Hauer <s.hauer(a)pengutronix.de>

3 weeks, 4 days

5
5
0 0

[PATCH 00/12] mwifiex: two fixes and cleanup

by Sascha Hauer

These are a few patches broken out from [1]. Kalle requested to limit the number of patches per series to approximately 12 and Francesco to move the fixes to the front of the series, so here we go. First two patches are fixes. First one is for host mlme support which currently is in wireless-next, so no stable tag needed, second one has a stable tag. The remaining patches except the last one I have chosen to upstream first. I'll continue with the other patches after having this series in shape and merged. The last one is a new patch not included in [1]. Sascha [1] https://lore.kernel.org/all/20240820-mwifiex-cleanup-v1-0-320d8de4a4b7@peng… Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de> --- Sascha Hauer (12): wifi: mwifiex: add missing locking wifi: mwifiex: fix MAC address handling wifi: mwifiex: deduplicate code in mwifiex_cmd_tx_rate_cfg() wifi: mwifiex: use adapter as context pointer for mwifiex_hs_activated_event() wifi: mwifiex: drop unnecessary initialization wifi: mwifiex: make region_code_mapping_t const wifi: mwifiex: pass adapter to mwifiex_dnld_cmd_to_fw() wifi: mwifiex: simplify mwifiex_setup_ht_caps() wifi: mwifiex: fix indention wifi: mwifiex: make locally used function static wifi: mwifiex: move common settings out of switch/case wifi: mwifiex: drop asynchronous init waiting code drivers/net/wireless/marvell/mwifiex/cfg80211.c | 38 ++++------ drivers/net/wireless/marvell/mwifiex/cfp.c | 4 +- drivers/net/wireless/marvell/mwifiex/cmdevt.c | 76 +++++++------------- drivers/net/wireless/marvell/mwifiex/init.c | 19 ++--- drivers/net/wireless/marvell/mwifiex/main.c | 94 +++++++++---------------- drivers/net/wireless/marvell/mwifiex/main.h | 16 ++--- drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 49 ++++--------- drivers/net/wireless/marvell/mwifiex/txrx.c | 3 +- drivers/net/wireless/marvell/mwifiex/util.c | 22 +----- drivers/net/wireless/marvell/mwifiex/wmm.c | 12 ++-- 10 files changed, 105 insertions(+), 228 deletions(-) --- base-commit: 67a72043aa2e6f60f7bbe7bfa598ba168f16d04f change-id: 20240826-mwifiex-cleanup-1-b5035c7faff6 Best regards, -- Sascha Hauer <s.hauer(a)pengutronix.de>

3 weeks, 4 days

2
4
0 0

[PATCH] soundwire: stream: fix programming slave ports for non-continous port maps

by Krzysztof Kozlowski

Two bitmasks in 'struct sdw_slave_prop' - 'source_ports' and 'sink_ports' - define which ports to program in sdw_program_slave_port_params(). The masks are used to get the appropriate data port properties ('struct sdw_get_slave_dpn_prop') from an array. Bitmasks can be non-continuous or can start from index different than 0, thus when looking for matching port property for given port, we must iterate over mask bits, not from 0 up to number of ports. This fixes allocation and programming slave ports, when a source or sink masks start from further index. Fixes: f8101c74aa54 ("soundwire: Add Master and Slave port programming") Cc: <stable(a)vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- drivers/soundwire/stream.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c index 7aa4900dcf31..f275143d7b18 100644 --- a/drivers/soundwire/stream.c +++ b/drivers/soundwire/stream.c @@ -1291,18 +1291,18 @@ struct sdw_dpn_prop *sdw_get_slave_dpn_prop(struct sdw_slave *slave, unsigned int port_num) { struct sdw_dpn_prop *dpn_prop; - u8 num_ports; + unsigned long mask; int i; if (direction == SDW_DATA_DIR_TX) { - num_ports = hweight32(slave->prop.source_ports); + mask = slave->prop.source_ports; dpn_prop = slave->prop.src_dpn_prop; } else { - num_ports = hweight32(slave->prop.sink_ports); + mask = slave->prop.sink_ports; dpn_prop = slave->prop.sink_dpn_prop; } - for (i = 0; i < num_ports; i++) { + for_each_set_bit(i, &mask, 32) { if (dpn_prop[i].num == port_num) return &dpn_prop[i]; } -- 2.43.0

3 weeks, 4 days

6
15
0 0

FAILED: patch "[PATCH] memcg: protect concurrent access to mem_cgroup_idr" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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-5.15.y git checkout FETCH_HEAD git cherry-pick -x 9972605a238339b85bd16b084eed5f18414d22db # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024081211-owl-snowdrop-d2aa@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 9972605a2383 ("memcg: protect concurrent access to mem_cgroup_idr") 6f0df8e16eb5 ("memcontrol: ensure memcg acquired by id is properly set up") e4dde56cd208 ("mm: multi-gen LRU: per-node lru_gen_folio lists") 7348cc91821b ("mm: multi-gen LRU: remove aging fairness safeguard") a579086c99ed ("mm: multi-gen LRU: remove eviction fairness safeguard") adb8213014b2 ("mm: memcg: fix stale protection of reclaim target memcg") 57e9cc50f4dd ("mm: vmscan: split khugepaged stats from direct reclaim stats") e4fea72b1438 ("mglru: mm/vmscan.c: fix imprecise comments") d396def5d86d ("memcg: rearrange code") 410f8e82689e ("memcg: extract memcg_vmstats from struct mem_cgroup") d6c3af7d8a2b ("mm: multi-gen LRU: debugfs interface") 1332a809d95a ("mm: multi-gen LRU: thrashing prevention") 354ed5974429 ("mm: multi-gen LRU: kill switch") f76c83378851 ("mm: multi-gen LRU: optimize multiple memcgs") bd74fdaea146 ("mm: multi-gen LRU: support page table walks") 018ee47f1489 ("mm: multi-gen LRU: exploit locality in rmap") ac35a4902374 ("mm: multi-gen LRU: minimal implementation") ec1c86b25f4b ("mm: multi-gen LRU: groundwork") f1e1a7be4718 ("mm/vmscan.c: refactor shrink_node()") d3629af59f41 ("mm/vmscan: make the annotations of refaults code at the right place") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 9972605a238339b85bd16b084eed5f18414d22db Mon Sep 17 00:00:00 2001 From: Shakeel Butt <shakeel.butt(a)linux.dev> Date: Fri, 2 Aug 2024 16:58:22 -0700 Subject: [PATCH] memcg: protect concurrent access to mem_cgroup_idr Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected through cgroup_mutex from concurrent modifications. However idr_remove() for mem_cgroup_idr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that. We have been seeing list_lru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of list_lru code including list_lru_add(), list_lru_del() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the super_block's list_lru didn't have list_lru_one for the memcg of that object. The initial suspicions were either the object is not allocated through kmem_cache_alloc_lru() or somehow memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but returned success. No evidence were found for these cases. Looking more deeply, we started seeing situations where valid memcg's id is not present in mem_cgroup_idr and in some cases multiple valid memcgs have same id and mem_cgroup_idr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idr_remove() calls or race between idr_alloc()/idr_replace() and idr_remove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup list_lrus on the system for all of them. Later access from other memcgs to the list_lru cause crashes due to missing list_lru_one. Link: https://lkml.kernel.org/r/20240802235822.1830976-1-shakeel.butt@linux.dev Fixes: 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") Signed-off-by: Shakeel Butt <shakeel.butt(a)linux.dev> Acked-by: Muchun Song <muchun.song(a)linux.dev> Reviewed-by: Roman Gushchin <roman.gushchin(a)linux.dev> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 960371788687..f29157288b7d 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -3386,11 +3386,28 @@ static void memcg_wb_domain_size_changed(struct mem_cgroup *memcg) #define MEM_CGROUP_ID_MAX ((1UL << MEM_CGROUP_ID_SHIFT) - 1) static DEFINE_IDR(mem_cgroup_idr); +static DEFINE_SPINLOCK(memcg_idr_lock); + +static int mem_cgroup_alloc_id(void) +{ + int ret; + + idr_preload(GFP_KERNEL); + spin_lock(&memcg_idr_lock); + ret = idr_alloc(&mem_cgroup_idr, NULL, 1, MEM_CGROUP_ID_MAX + 1, + GFP_NOWAIT); + spin_unlock(&memcg_idr_lock); + idr_preload_end(); + return ret; +} static void mem_cgroup_id_remove(struct mem_cgroup *memcg) { if (memcg->id.id > 0) { + spin_lock(&memcg_idr_lock); idr_remove(&mem_cgroup_idr, memcg->id.id); + spin_unlock(&memcg_idr_lock); + memcg->id.id = 0; } } @@ -3524,8 +3541,7 @@ static struct mem_cgroup *mem_cgroup_alloc(struct mem_cgroup *parent) if (!memcg) return ERR_PTR(error); - memcg->id.id = idr_alloc(&mem_cgroup_idr, NULL, - 1, MEM_CGROUP_ID_MAX + 1, GFP_KERNEL); + memcg->id.id = mem_cgroup_alloc_id(); if (memcg->id.id < 0) { error = memcg->id.id; goto fail; @@ -3667,7 +3683,9 @@ static int mem_cgroup_css_online(struct cgroup_subsys_state *css) * publish it here at the end of onlining. This matches the * regular ID destruction during offlining. */ + spin_lock(&memcg_idr_lock); idr_replace(&mem_cgroup_idr, memcg, memcg->id.id); + spin_unlock(&memcg_idr_lock); return 0; offline_kmem:

3 weeks, 4 days

2
1
0 0

FAILED: patch "[PATCH] memcg: protect concurrent access to mem_cgroup_idr" 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 9972605a238339b85bd16b084eed5f18414d22db # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024081259-plow-freezing-a93e@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 9972605a2383 ("memcg: protect concurrent access to mem_cgroup_idr") 6f0df8e16eb5 ("memcontrol: ensure memcg acquired by id is properly set up") e4dde56cd208 ("mm: multi-gen LRU: per-node lru_gen_folio lists") 7348cc91821b ("mm: multi-gen LRU: remove aging fairness safeguard") a579086c99ed ("mm: multi-gen LRU: remove eviction fairness safeguard") adb8213014b2 ("mm: memcg: fix stale protection of reclaim target memcg") 57e9cc50f4dd ("mm: vmscan: split khugepaged stats from direct reclaim stats") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 9972605a238339b85bd16b084eed5f18414d22db Mon Sep 17 00:00:00 2001 From: Shakeel Butt <shakeel.butt(a)linux.dev> Date: Fri, 2 Aug 2024 16:58:22 -0700 Subject: [PATCH] memcg: protect concurrent access to mem_cgroup_idr Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected through cgroup_mutex from concurrent modifications. However idr_remove() for mem_cgroup_idr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that. We have been seeing list_lru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of list_lru code including list_lru_add(), list_lru_del() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the super_block's list_lru didn't have list_lru_one for the memcg of that object. The initial suspicions were either the object is not allocated through kmem_cache_alloc_lru() or somehow memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but returned success. No evidence were found for these cases. Looking more deeply, we started seeing situations where valid memcg's id is not present in mem_cgroup_idr and in some cases multiple valid memcgs have same id and mem_cgroup_idr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idr_remove() calls or race between idr_alloc()/idr_replace() and idr_remove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup list_lrus on the system for all of them. Later access from other memcgs to the list_lru cause crashes due to missing list_lru_one. Link: https://lkml.kernel.org/r/20240802235822.1830976-1-shakeel.butt@linux.dev Fixes: 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") Signed-off-by: Shakeel Butt <shakeel.butt(a)linux.dev> Acked-by: Muchun Song <muchun.song(a)linux.dev> Reviewed-by: Roman Gushchin <roman.gushchin(a)linux.dev> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 960371788687..f29157288b7d 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -3386,11 +3386,28 @@ static void memcg_wb_domain_size_changed(struct mem_cgroup *memcg) #define MEM_CGROUP_ID_MAX ((1UL << MEM_CGROUP_ID_SHIFT) - 1) static DEFINE_IDR(mem_cgroup_idr); +static DEFINE_SPINLOCK(memcg_idr_lock); + +static int mem_cgroup_alloc_id(void) +{ + int ret; + + idr_preload(GFP_KERNEL); + spin_lock(&memcg_idr_lock); + ret = idr_alloc(&mem_cgroup_idr, NULL, 1, MEM_CGROUP_ID_MAX + 1, + GFP_NOWAIT); + spin_unlock(&memcg_idr_lock); + idr_preload_end(); + return ret; +} static void mem_cgroup_id_remove(struct mem_cgroup *memcg) { if (memcg->id.id > 0) { + spin_lock(&memcg_idr_lock); idr_remove(&mem_cgroup_idr, memcg->id.id); + spin_unlock(&memcg_idr_lock); + memcg->id.id = 0; } } @@ -3524,8 +3541,7 @@ static struct mem_cgroup *mem_cgroup_alloc(struct mem_cgroup *parent) if (!memcg) return ERR_PTR(error); - memcg->id.id = idr_alloc(&mem_cgroup_idr, NULL, - 1, MEM_CGROUP_ID_MAX + 1, GFP_KERNEL); + memcg->id.id = mem_cgroup_alloc_id(); if (memcg->id.id < 0) { error = memcg->id.id; goto fail; @@ -3667,7 +3683,9 @@ static int mem_cgroup_css_online(struct cgroup_subsys_state *css) * publish it here at the end of onlining. This matches the * regular ID destruction during offlining. */ + spin_lock(&memcg_idr_lock); idr_replace(&mem_cgroup_idr, memcg, memcg->id.id); + spin_unlock(&memcg_idr_lock); return 0; offline_kmem:

3 weeks, 4 days

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2024