June 2024 - Linux-stable-mirror

[PATCH] bus: mhi: ep: Do not allocate memory for MHI objects from DMA zone

by Manivannan Sadhasivam

MHI endpoint stack accidentally started allocating memory for objects from DMA zone since commit 62210a26cd4f ("bus: mhi: ep: Use slab allocator where applicable"). But there is no real need to allocate memory from this naturally limited DMA zone. This also causes the MHI endpoint stack to run out of memory while doing high bandwidth transfers. So let's switch over to normal memory. Cc: stable(a)vger.kernel.org # 6.8 Fixes: 62210a26cd4f ("bus: mhi: ep: Use slab allocator where applicable") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> --- drivers/bus/mhi/ep/main.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/bus/mhi/ep/main.c b/drivers/bus/mhi/ep/main.c index f8f674adf1d4..4acfac73ca9a 100644 --- a/drivers/bus/mhi/ep/main.c +++ b/drivers/bus/mhi/ep/main.c @@ -90,7 +90,7 @@ static int mhi_ep_send_completion_event(struct mhi_ep_cntrl *mhi_cntrl, struct m struct mhi_ring_element *event; int ret; - event = kmem_cache_zalloc(mhi_cntrl->ev_ring_el_cache, GFP_KERNEL | GFP_DMA); + event = kmem_cache_zalloc(mhi_cntrl->ev_ring_el_cache, GFP_KERNEL); if (!event) return -ENOMEM; @@ -109,7 +109,7 @@ int mhi_ep_send_state_change_event(struct mhi_ep_cntrl *mhi_cntrl, enum mhi_stat struct mhi_ring_element *event; int ret; - event = kmem_cache_zalloc(mhi_cntrl->ev_ring_el_cache, GFP_KERNEL | GFP_DMA); + event = kmem_cache_zalloc(mhi_cntrl->ev_ring_el_cache, GFP_KERNEL); if (!event) return -ENOMEM; @@ -127,7 +127,7 @@ int mhi_ep_send_ee_event(struct mhi_ep_cntrl *mhi_cntrl, enum mhi_ee_type exec_e struct mhi_ring_element *event; int ret; - event = kmem_cache_zalloc(mhi_cntrl->ev_ring_el_cache, GFP_KERNEL | GFP_DMA); + event = kmem_cache_zalloc(mhi_cntrl->ev_ring_el_cache, GFP_KERNEL); if (!event) return -ENOMEM; @@ -146,7 +146,7 @@ static int mhi_ep_send_cmd_comp_event(struct mhi_ep_cntrl *mhi_cntrl, enum mhi_e struct mhi_ring_element *event; int ret; - event = kmem_cache_zalloc(mhi_cntrl->ev_ring_el_cache, GFP_KERNEL | GFP_DMA); + event = kmem_cache_zalloc(mhi_cntrl->ev_ring_el_cache, GFP_KERNEL); if (!event) return -ENOMEM; @@ -438,7 +438,7 @@ static int mhi_ep_read_channel(struct mhi_ep_cntrl *mhi_cntrl, read_offset = mhi_chan->tre_size - mhi_chan->tre_bytes_left; write_offset = len - buf_left; - buf_addr = kmem_cache_zalloc(mhi_cntrl->tre_buf_cache, GFP_KERNEL | GFP_DMA); + buf_addr = kmem_cache_zalloc(mhi_cntrl->tre_buf_cache, GFP_KERNEL); if (!buf_addr) return -ENOMEM; @@ -1481,14 +1481,14 @@ int mhi_ep_register_controller(struct mhi_ep_cntrl *mhi_cntrl, mhi_cntrl->ev_ring_el_cache = kmem_cache_create("mhi_ep_event_ring_el", sizeof(struct mhi_ring_element), 0, - SLAB_CACHE_DMA, NULL); + 0, NULL); if (!mhi_cntrl->ev_ring_el_cache) { ret = -ENOMEM; goto err_free_cmd; } mhi_cntrl->tre_buf_cache = kmem_cache_create("mhi_ep_tre_buf", MHI_EP_DEFAULT_MTU, 0, - SLAB_CACHE_DMA, NULL); + 0, NULL); if (!mhi_cntrl->tre_buf_cache) { ret = -ENOMEM; goto err_destroy_ev_ring_el_cache; -- 2.25.1

12 months

2
1
0 0

[PATCH] drm/amd/display: prevent register access while in IPS

by Hamza Mahfooz

We can't read/write to DCN registers while in IPS. Since, that can cause the system to hang. So, before proceeding with the access in that scenario, force the system out of IPS. Cc: stable(a)vger.kernel.org # 6.6+ Signed-off-by: Hamza Mahfooz <hamza.mahfooz(a)amd.com> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 ++++++++++ 1 file changed, 10 insertions(+) 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 059f78c8cd04..c8bc4098ed18 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -11796,6 +11796,12 @@ void amdgpu_dm_trigger_timing_sync(struct drm_device *dev) mutex_unlock(&adev->dm.dc_lock); } +static inline void amdgpu_dm_exit_ips_for_hw_access(struct dc *dc) +{ + if (dc->ctx->dmub_srv && !dc->ctx->dmub_srv->idle_exit_counter) + dc_exit_ips_for_hw_access(dc); +} + void dm_write_reg_func(const struct dc_context *ctx, uint32_t address, u32 value, const char *func_name) { @@ -11806,6 +11812,8 @@ void dm_write_reg_func(const struct dc_context *ctx, uint32_t address, return; } #endif + + amdgpu_dm_exit_ips_for_hw_access(ctx->dc); cgs_write_register(ctx->cgs_device, address, value); trace_amdgpu_dc_wreg(&ctx->perf_trace->write_count, address, value); } @@ -11829,6 +11837,8 @@ uint32_t dm_read_reg_func(const struct dc_context *ctx, uint32_t address, return 0; } + amdgpu_dm_exit_ips_for_hw_access(ctx->dc); + value = cgs_read_register(ctx->cgs_device, address); trace_amdgpu_dc_rreg(&ctx->perf_trace->read_count, address, value); -- 2.45.0

12 months

2
1
0 0

[PATCH v4] af_packet: Handle outgoing VLAN packets without hardware offloading

by Chengen Du

The issue initially stems from libpcap. The ethertype will be overwritten as the VLAN TPID if the network interface lacks hardware VLAN offloading. In the outbound packet path, if hardware VLAN offloading is unavailable, the VLAN tag is inserted into the payload but then cleared from the sk_buff struct. Consequently, this can lead to a false negative when checking for the presence of a VLAN tag, causing the packet sniffing outcome to lack VLAN tag information (i.e., TCI-TPID). As a result, the packet capturing tool may be unable to parse packets as expected. The TCI-TPID is missing because the prb_fill_vlan_info() function does not modify the tp_vlan_tci/tp_vlan_tpid values, as the information is in the payload and not in the sk_buff struct. The skb_vlan_tag_present() function only checks vlan_all in the sk_buff struct. In cooked mode, the L2 header is stripped, preventing the packet capturing tool from determining the correct TCI-TPID value. Additionally, the protocol in SLL is incorrect, which means the packet capturing tool cannot parse the L3 header correctly. Link: https://github.com/the-tcpdump-group/libpcap/issues/1105 Link: https://lore.kernel.org/netdev/20240520070348.26725-1-chengen.du@canonical.… Fixes: 393e52e33c6c ("packet: deliver VLAN TCI to userspace") Cc: stable(a)vger.kernel.org Signed-off-by: Chengen Du <chengen.du(a)canonical.com> --- net/packet/af_packet.c | 85 ++++++++++++++++++++++++++++++++++++------ 1 file changed, 74 insertions(+), 11 deletions(-) diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index ea3ebc160e25..21d34a12c11c 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -538,6 +538,62 @@ static void *packet_current_frame(struct packet_sock *po, return packet_lookup_frame(po, rb, rb->head, status); } +static int vlan_get_info(struct sk_buff *skb, u16 *tci, u16 *tpid) +{ + if (skb_vlan_tag_present(skb)) { + *tci = skb_vlan_tag_get(skb); + *tpid = ntohs(skb->vlan_proto); + } else if (unlikely(eth_type_vlan(skb->protocol))) { + unsigned int vlan_depth = skb->mac_len; + struct vlan_hdr vhdr, *vh; + u8 *skb_head = skb->data; + int skb_len = skb->len; + + if (vlan_depth) { + if (WARN_ON(vlan_depth < VLAN_HLEN)) + return 0; + vlan_depth -= VLAN_HLEN; + } else { + vlan_depth = ETH_HLEN; + } + + skb_push(skb, skb->data - skb_mac_header(skb)); + vh = skb_header_pointer(skb, vlan_depth, sizeof(vhdr), &vhdr); + if (skb_head != skb->data) { + skb->data = skb_head; + skb->len = skb_len; + } + if (unlikely(!vh)) + return 0; + + *tci = ntohs(vh->h_vlan_TCI); + *tpid = ntohs(skb->protocol); + } else { + return 0; + } + + return 1; +} + +static __be16 sll_get_protocol(struct sk_buff *skb) +{ + __be16 proto = skb->protocol; + + if (unlikely(eth_type_vlan(proto))) { + u8 *skb_head = skb->data; + int skb_len = skb->len; + + skb_push(skb, skb->data - skb_mac_header(skb)); + proto = __vlan_get_protocol(skb, proto, NULL); + if (skb_head != skb->data) { + skb->data = skb_head; + skb->len = skb_len; + } + } + + return proto; +} + static void prb_del_retire_blk_timer(struct tpacket_kbdq_core *pkc) { del_timer_sync(&pkc->retire_blk_timer); @@ -1007,9 +1063,11 @@ static void prb_clear_rxhash(struct tpacket_kbdq_core *pkc, static void prb_fill_vlan_info(struct tpacket_kbdq_core *pkc, struct tpacket3_hdr *ppd) { - if (skb_vlan_tag_present(pkc->skb)) { - ppd->hv1.tp_vlan_tci = skb_vlan_tag_get(pkc->skb); - ppd->hv1.tp_vlan_tpid = ntohs(pkc->skb->vlan_proto); + u16 tci, tpid; + + if (vlan_get_info(pkc->skb, &tci, &tpid)) { + ppd->hv1.tp_vlan_tci = tci; + ppd->hv1.tp_vlan_tpid = tpid; ppd->tp_status = TP_STATUS_VLAN_VALID | TP_STATUS_VLAN_TPID_VALID; } else { ppd->hv1.tp_vlan_tci = 0; @@ -2418,15 +2476,17 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev, hdrlen = sizeof(*h.h1); break; case TPACKET_V2: + u16 tci, tpid; + h.h2->tp_len = skb->len; h.h2->tp_snaplen = snaplen; h.h2->tp_mac = macoff; h.h2->tp_net = netoff; h.h2->tp_sec = ts.tv_sec; h.h2->tp_nsec = ts.tv_nsec; - if (skb_vlan_tag_present(skb)) { - h.h2->tp_vlan_tci = skb_vlan_tag_get(skb); - h.h2->tp_vlan_tpid = ntohs(skb->vlan_proto); + if (vlan_get_info(skb, &tci, &tpid)) { + h.h2->tp_vlan_tci = tci; + h.h2->tp_vlan_tpid = tpid; status |= TP_STATUS_VLAN_VALID | TP_STATUS_VLAN_TPID_VALID; } else { h.h2->tp_vlan_tci = 0; @@ -2457,7 +2517,8 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev, sll->sll_halen = dev_parse_header(skb, sll->sll_addr); sll->sll_family = AF_PACKET; sll->sll_hatype = dev->type; - sll->sll_protocol = skb->protocol; + sll->sll_protocol = (sk->sk_type == SOCK_DGRAM) ? + sll_get_protocol(skb) : skb->protocol; sll->sll_pkttype = skb->pkt_type; if (unlikely(packet_sock_flag(po, PACKET_SOCK_ORIGDEV))) sll->sll_ifindex = orig_dev->ifindex; @@ -3482,7 +3543,8 @@ static int packet_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, /* Original length was stored in sockaddr_ll fields */ origlen = PACKET_SKB_CB(skb)->sa.origlen; sll->sll_family = AF_PACKET; - sll->sll_protocol = skb->protocol; + sll->sll_protocol = (sock->type == SOCK_DGRAM) ? + sll_get_protocol(skb) : skb->protocol; } sock_recv_cmsgs(msg, sk, skb); @@ -3521,6 +3583,7 @@ static int packet_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, if (packet_sock_flag(pkt_sk(sk), PACKET_SOCK_AUXDATA)) { struct tpacket_auxdata aux; + u16 tci, tpid; aux.tp_status = TP_STATUS_USER; if (skb->ip_summed == CHECKSUM_PARTIAL) @@ -3535,9 +3598,9 @@ static int packet_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, aux.tp_snaplen = skb->len; aux.tp_mac = 0; aux.tp_net = skb_network_offset(skb); - if (skb_vlan_tag_present(skb)) { - aux.tp_vlan_tci = skb_vlan_tag_get(skb); - aux.tp_vlan_tpid = ntohs(skb->vlan_proto); + if (vlan_get_info(skb, &tci, &tpid)) { + aux.tp_vlan_tci = tci; + aux.tp_vlan_tpid = tpid; aux.tp_status |= TP_STATUS_VLAN_VALID | TP_STATUS_VLAN_TPID_VALID; } else { aux.tp_vlan_tci = 0; -- 2.43.0

12 months

2
1
0 0

[tip: irq/urgent] irqchip/gic-v3-its: Fix potential race condition in its_vlpi_prop_update()

by tip-bot2 for Hagar Hemdan

The following commit has been merged into the irq/urgent branch of tip: Commit-ID: b97e8a2f7130a4b30d1502003095833d16c028b3 Gitweb: https://git.kernel.org/tip/b97e8a2f7130a4b30d1502003095833d16c028b3 Author: Hagar Hemdan <hagarhem(a)amazon.com> AuthorDate: Fri, 31 May 2024 16:21:44 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Mon, 03 Jun 2024 18:20:00 +02:00 irqchip/gic-v3-its: Fix potential race condition in its_vlpi_prop_update() its_vlpi_prop_update() calls lpi_write_config() which obtains the mapping information for a VLPI without lock held. So it could race with its_vlpi_unmap(). Since all calls from its_irq_set_vcpu_affinity() require the same lock to be held, hoist the locking there instead of sprinkling the locking all over the place. This bug was discovered using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. [ tglx: Use guard() instead of goto ] Fixes: 015ec0386ab6 ("irqchip/gic-v3-its: Add VLPI configuration handling") Suggested-by: Marc Zyngier <maz(a)kernel.org> Signed-off-by: Hagar Hemdan <hagarhem(a)amazon.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Reviewed-by: Marc Zyngier <maz(a)kernel.org> Link: https://lore.kernel.org/r/20240531162144.28650-1-hagarhem@amazon.com --- drivers/irqchip/irq-gic-v3-its.c | 44 ++++++++----------------------- 1 file changed, 12 insertions(+), 32 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 40ebf17..3c755d5 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1846,28 +1846,22 @@ static int its_vlpi_map(struct irq_data *d, struct its_cmd_info *info) { struct its_device *its_dev = irq_data_get_irq_chip_data(d); u32 event = its_get_event_id(d); - int ret = 0; if (!info->map) return -EINVAL; - raw_spin_lock(&its_dev->event_map.vlpi_lock); - if (!its_dev->event_map.vm) { struct its_vlpi_map *maps; maps = kcalloc(its_dev->event_map.nr_lpis, sizeof(*maps), GFP_ATOMIC); - if (!maps) { - ret = -ENOMEM; - goto out; - } + if (!maps) + return -ENOMEM; its_dev->event_map.vm = info->map->vm; its_dev->event_map.vlpi_maps = maps; } else if (its_dev->event_map.vm != info->map->vm) { - ret = -EINVAL; - goto out; + return -EINVAL; } /* Get our private copy of the mapping information */ @@ -1899,46 +1893,32 @@ static int its_vlpi_map(struct irq_data *d, struct its_cmd_info *info) its_dev->event_map.nr_vlpis++; } -out: - raw_spin_unlock(&its_dev->event_map.vlpi_lock); - return ret; + return 0; } static int its_vlpi_get(struct irq_data *d, struct its_cmd_info *info) { struct its_device *its_dev = irq_data_get_irq_chip_data(d); struct its_vlpi_map *map; - int ret = 0; - - raw_spin_lock(&its_dev->event_map.vlpi_lock); map = get_vlpi_map(d); - if (!its_dev->event_map.vm || !map) { - ret = -EINVAL; - goto out; - } + if (!its_dev->event_map.vm || !map) + return -EINVAL; /* Copy our mapping information to the incoming request */ *info->map = *map; -out: - raw_spin_unlock(&its_dev->event_map.vlpi_lock); - return ret; + return 0; } static int its_vlpi_unmap(struct irq_data *d) { struct its_device *its_dev = irq_data_get_irq_chip_data(d); u32 event = its_get_event_id(d); - int ret = 0; - - raw_spin_lock(&its_dev->event_map.vlpi_lock); - if (!its_dev->event_map.vm || !irqd_is_forwarded_to_vcpu(d)) { - ret = -EINVAL; - goto out; - } + if (!its_dev->event_map.vm || !irqd_is_forwarded_to_vcpu(d)) + return -EINVAL; /* Drop the virtual mapping */ its_send_discard(its_dev, event); @@ -1962,9 +1942,7 @@ static int its_vlpi_unmap(struct irq_data *d) kfree(its_dev->event_map.vlpi_maps); } -out: - raw_spin_unlock(&its_dev->event_map.vlpi_lock); - return ret; + return 0; } static int its_vlpi_prop_update(struct irq_data *d, struct its_cmd_info *info) @@ -1992,6 +1970,8 @@ static int its_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu_info) if (!is_v4(its_dev->its)) return -EINVAL; + guard(raw_spinlock_irq)(&its_dev->event_map.vlpi_lock); + /* Unmap request? */ if (!info) return its_vlpi_unmap(d);

12 months

1
0
0 0

[tip: irq/urgent] irqchip/gic-v3-its: Fix potential race condition in its_vlpi_prop_update()

by tip-bot2 for Hagar Hemdan

The following commit has been merged into the irq/urgent branch of tip: Commit-ID: 8dd4302d37bb2fe842acb3be688d393254b4f126 Gitweb: https://git.kernel.org/tip/8dd4302d37bb2fe842acb3be688d393254b4f126 Author: Hagar Hemdan <hagarhem(a)amazon.com> AuthorDate: Fri, 31 May 2024 16:21:44 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Mon, 03 Jun 2024 14:19:42 +02:00 irqchip/gic-v3-its: Fix potential race condition in its_vlpi_prop_update() its_vlpi_prop_update() calls lpi_write_config() which obtains the mapping information for a VLPI without lock held. So it could race with its_vlpi_unmap(). Since all calls from its_irq_set_vcpu_affinity() require the same lock to be held, hoist the locking there instead of sprinkling the locking all over the place. This bug was discovered using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. [ tglx: Use guard() instead of goto ] Fixes: 015ec0386ab6 ("irqchip/gic-v3-its: Add VLPI configuration handling") Suggested-by: Marc Zyngier <maz(a)kernel.org> Signed-off-by: Hagar Hemdan <hagarhem(a)amazon.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Reviewed-by: Marc Zyngier <maz(a)kernel.org> Link: https://lore.kernel.org/r/20240531162144.28650-1-hagarhem@amazon.com --- drivers/irqchip/irq-gic-v3-its.c | 44 ++++++++----------------------- 1 file changed, 12 insertions(+), 32 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 40ebf17..c696ac9 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1846,28 +1846,22 @@ static int its_vlpi_map(struct irq_data *d, struct its_cmd_info *info) { struct its_device *its_dev = irq_data_get_irq_chip_data(d); u32 event = its_get_event_id(d); - int ret = 0; if (!info->map) return -EINVAL; - raw_spin_lock(&its_dev->event_map.vlpi_lock); - if (!its_dev->event_map.vm) { struct its_vlpi_map *maps; maps = kcalloc(its_dev->event_map.nr_lpis, sizeof(*maps), GFP_ATOMIC); - if (!maps) { - ret = -ENOMEM; - goto out; - } + if (!maps) + return -ENOMEM; its_dev->event_map.vm = info->map->vm; its_dev->event_map.vlpi_maps = maps; } else if (its_dev->event_map.vm != info->map->vm) { - ret = -EINVAL; - goto out; + return -EINVAL; } /* Get our private copy of the mapping information */ @@ -1899,46 +1893,32 @@ static int its_vlpi_map(struct irq_data *d, struct its_cmd_info *info) its_dev->event_map.nr_vlpis++; } -out: - raw_spin_unlock(&its_dev->event_map.vlpi_lock); - return ret; + return 0; } static int its_vlpi_get(struct irq_data *d, struct its_cmd_info *info) { struct its_device *its_dev = irq_data_get_irq_chip_data(d); struct its_vlpi_map *map; - int ret = 0; - - raw_spin_lock(&its_dev->event_map.vlpi_lock); map = get_vlpi_map(d); - if (!its_dev->event_map.vm || !map) { - ret = -EINVAL; - goto out; - } + if (!its_dev->event_map.vm || !map) + return -EINVAL; /* Copy our mapping information to the incoming request */ *info->map = *map; -out: - raw_spin_unlock(&its_dev->event_map.vlpi_lock); - return ret; + return 0; } static int its_vlpi_unmap(struct irq_data *d) { struct its_device *its_dev = irq_data_get_irq_chip_data(d); u32 event = its_get_event_id(d); - int ret = 0; - - raw_spin_lock(&its_dev->event_map.vlpi_lock); - if (!its_dev->event_map.vm || !irqd_is_forwarded_to_vcpu(d)) { - ret = -EINVAL; - goto out; - } + if (!its_dev->event_map.vm || !irqd_is_forwarded_to_vcpu(d)) + return -EINVAL; /* Drop the virtual mapping */ its_send_discard(its_dev, event); @@ -1962,9 +1942,7 @@ static int its_vlpi_unmap(struct irq_data *d) kfree(its_dev->event_map.vlpi_maps); } -out: - raw_spin_unlock(&its_dev->event_map.vlpi_lock); - return ret; + return 0; } static int its_vlpi_prop_update(struct irq_data *d, struct its_cmd_info *info) @@ -1992,6 +1970,8 @@ static int its_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu_info) if (!is_v4(its_dev->its)) return -EINVAL; + guard(raw_spinlock_irq, &its_dev->event_map.vlpi_lock); + /* Unmap request? */ if (!info) return its_vlpi_unmap(d);

12 months

4
3
0 0

Re: Patch "nilfs2: make superblock data array index computation sparse friendly" has been added to the 6.1-stable tree

by Ryusuke Konishi

Hi Sasha, A week ago, I notified the stable mailing list that this patch is not a bug fix that should be backported, and Greg removed it from the backport queue to the stable trees. [1] https://lkml.kernel.org/r/CAKFNMo=kyzbvfLrTv8JhuY=e7-fkjtpL3DvcQ1r+RUPPeC4S… On Tue, May 28, 2024 at 3:28 AM Greg KH <greg(a)kroah.com> wrote: > > This commit fixes the sparse warning output by build "make C=1" with > > the sparse check, but does not fix any operational bugs. > > > > Therefore, if fixing a harmless sparse warning does not meet the > > requirements for backporting to stable trees (I assume it does), > > please drop it as it is a false positive pickup. Sorry if the > > "Fixes:" tag is confusing. > > > > The same goes for the same patch queued to other stable-trees. > > Now dropped, thanks! > > greg k-h So I think this is just a case where the "Fixes" tag was mechanically detected and mistakenly picked up again. Could you please confirm? Regards, Ryusuke Konishi On Mon, Jun 3, 2024 at 9:11 PM Sasha Levin wrote: > > This is a note to let you know that I've just added the patch titled > > nilfs2: make superblock data array index computation sparse friendly > > to the 6.1-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: > nilfs2-make-superblock-data-array-index-computation-.patch > and it can be found in the queue-6.1 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. > > > > commit 358bc3e8f5a5e2c51fc07aadb70e25fa206e764b > Author: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> > Date: Tue Apr 30 17:00:19 2024 +0900 > > nilfs2: make superblock data array index computation sparse friendly > > [ Upstream commit 91d743a9c8299de1fc1b47428d8bb4c85face00f ] > > Upon running sparse, "warning: dubious: x & !y" is output at an array > index calculation within nilfs_load_super_block(). > > The calculation is not wrong, but to eliminate the sparse warning, replace > it with an equivalent calculation. > > Also, add a comment to make it easier to understand what the unintuitive > array index calculation is doing and whether it's correct. > > Link: https://lkml.kernel.org/r/20240430080019.4242-3-konishi.ryusuke@gmail.com > Fixes: e339ad31f599 ("nilfs2: introduce secondary super block") > Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> > Cc: Bart Van Assche <bvanassche(a)acm.org> > Cc: Jens Axboe <axboe(a)kernel.dk> > Cc: kernel test robot <lkp(a)intel.com> > Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/fs/nilfs2/the_nilfs.c b/fs/nilfs2/the_nilfs.c > index 71400496ed365..3e3c1d32da180 100644 > --- a/fs/nilfs2/the_nilfs.c > +++ b/fs/nilfs2/the_nilfs.c > @@ -592,7 +592,7 @@ static int nilfs_load_super_block(struct the_nilfs *nilfs, > struct nilfs_super_block **sbp = nilfs->ns_sbp; > struct buffer_head **sbh = nilfs->ns_sbh; > u64 sb2off, devsize = bdev_nr_bytes(nilfs->ns_bdev); > - int valid[2], swp = 0; > + int valid[2], swp = 0, older; > > if (devsize < NILFS_SEG_MIN_BLOCKS * NILFS_MIN_BLOCK_SIZE + 4096) { > nilfs_err(sb, "device size too small"); > @@ -648,9 +648,25 @@ static int nilfs_load_super_block(struct the_nilfs *nilfs, > if (swp) > nilfs_swap_super_block(nilfs); > > + /* > + * Calculate the array index of the older superblock data. > + * If one has been dropped, set index 0 pointing to the remaining one, > + * otherwise set index 1 pointing to the old one (including if both > + * are the same). > + * > + * Divided case valid[0] valid[1] swp -> older > + * ------------------------------------------------------------- > + * Both SBs are invalid 0 0 N/A (Error) > + * SB1 is invalid 0 1 1 0 > + * SB2 is invalid 1 0 0 0 > + * SB2 is newer 1 1 1 0 > + * SB2 is older or the same 1 1 0 1 > + */ > + older = valid[1] ^ swp; > + > nilfs->ns_sbwcount = 0; > nilfs->ns_sbwtime = le64_to_cpu(sbp[0]->s_wtime); > - nilfs->ns_prot_seq = le64_to_cpu(sbp[valid[1] & !swp]->s_last_seq); > + nilfs->ns_prot_seq = le64_to_cpu(sbp[older]->s_last_seq); > *sbpp = sbp[0]; > return 0; > }

12 months

1
0
0 0

Re: Patch "nfc: nci: Fix kcov check in nci_rx_work()" has been added to the 6.1-stable tree

by Tetsuo Handa

Not for 6.1 and earlier kernels. -------- Forwarded Message -------- Date: Sat, 11 May 2024 09:05:18 -0400 Subject: Re: Patch "nfc: nci: Fix kcov check in nci_rx_work()" has been added to the 6.1-stable tree Message-ID: <Zj9tDunQd3BDcG2a@sashalap> On Sat, May 11, 2024 at 07:53:00AM +0900, Tetsuo Handa wrote: >On 2024/05/11 6:39, Sasha Levin wrote: >> This is a note to let you know that I've just added the patch titled >> >> nfc: nci: Fix kcov check in nci_rx_work() >> >> to the 6.1-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: >> nfc-nci-fix-kcov-check-in-nci_rx_work.patch >> and it can be found in the queue-6.1 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. >> > >I think we should not add this patch to 6.1 and earlier kernels, for >only 6.2 and later kernels call kcov_remote_stop() from nci_rx_work(). Dropped, thanks! -- Thanks, Sasha On 2024/06/03 21:13, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > nfc: nci: Fix kcov check in nci_rx_work() > > to the 6.1-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: > nfc-nci-fix-kcov-check-in-nci_rx_work.patch > and it can be found in the queue-6.1 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. >

12 months

1
0
0 0

Re: Patch "ALSA: timer: Set lower bound of start tick time" has been added to the 6.8-stable tree

by Takashi Iwai

On Thu, 30 May 2024 21:02:36 +0200, Sasha Levin wrote: > > This is a note to let you know that I've just added the patch titled > > ALSA: timer: Set lower bound of start tick time > > to the 6.8-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: > alsa-timer-set-lower-bound-of-start-tick-time.patch > and it can be found in the queue-6.8 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. Please drop this one for 6.8 and older (you posted for 6.6 too). As already explained in another mail, this commit needs a prerequisite use of guard(). An alternative patch has been already submitted. Take it instead: https://lore.kernel.org/all/20240527062431.18709-1-tiwai@suse.de/ thanks, Takashi > > > > commit d717dbdb94145bee1e9cf9eca387d973564203c4 > Author: Takashi Iwai <tiwai(a)suse.de> > Date: Tue May 14 20:27:36 2024 +0200 > > ALSA: timer: Set lower bound of start tick time > > [ Upstream commit 4a63bd179fa8d3fcc44a0d9d71d941ddd62f0c4e ] > > Currently ALSA timer doesn't have the lower limit of the start tick > time, and it allows a very small size, e.g. 1 tick with 1ns resolution > for hrtimer. Such a situation may lead to an unexpected RCU stall, > where the callback repeatedly queuing the expire update, as reported > by fuzzer. > > This patch introduces a sanity check of the timer start tick time, so > that the system returns an error when a too small start size is set. > As of this patch, the lower limit is hard-coded to 100us, which is > small enough but can still work somehow. > > Reported-by: syzbot+43120c2af6ca2938cc38(a)syzkaller.appspotmail.com > Closes: https://lore.kernel.org/r/000000000000fa00a1061740ab6d@google.com > Cc: <stable(a)vger.kernel.org> > Link: https://lore.kernel.org/r/20240514182745.4015-1-tiwai@suse.de > Signed-off-by: Takashi Iwai <tiwai(a)suse.de> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/sound/core/timer.c b/sound/core/timer.c > index e6e551d4a29e0..42c4c2b029526 100644 > --- a/sound/core/timer.c > +++ b/sound/core/timer.c > @@ -553,6 +553,14 @@ static int snd_timer_start1(struct snd_timer_instance *timeri, > goto unlock; > } > > + /* check the actual time for the start tick; > + * bail out as error if it's way too low (< 100us) > + */ > + if (start) { > + if ((u64)snd_timer_hw_resolution(timer) * ticks < 100000) > + return -EINVAL; > + } > + > if (start) > timeri->ticks = timeri->cticks = ticks; > else if (!timeri->cticks)

12 months

2
1
0 0

[PATCH bpf v1 2/2] bpf: Harden __bpf_kfunc tag against linker kfunc removal

by Tony Ambardar

BPF kfuncs are often not directly referenced and may be inadvertently removed by optimization steps during kernel builds, thus the __bpf_kfunc tag mitigates against this removal by including the __used macro. However, this macro alone does not prevent removal during linking, and may still yield build warnings (e.g. on mips64el): LD vmlinux BTFIDS vmlinux WARN: resolve_btfids: unresolved symbol bpf_verify_pkcs7_signature WARN: resolve_btfids: unresolved symbol bpf_lookup_user_key WARN: resolve_btfids: unresolved symbol bpf_lookup_system_key WARN: resolve_btfids: unresolved symbol bpf_key_put WARN: resolve_btfids: unresolved symbol bpf_iter_task_next WARN: resolve_btfids: unresolved symbol bpf_iter_css_task_new WARN: resolve_btfids: unresolved symbol bpf_get_file_xattr WARN: resolve_btfids: unresolved symbol bpf_ct_insert_entry WARN: resolve_btfids: unresolved symbol bpf_cgroup_release WARN: resolve_btfids: unresolved symbol bpf_cgroup_from_id WARN: resolve_btfids: unresolved symbol bpf_cgroup_acquire WARN: resolve_btfids: unresolved symbol bpf_arena_free_pages NM System.map SORTTAB vmlinux OBJCOPY vmlinux.32 Update the __bpf_kfunc tag to better guard against linker optimization by including the new __retain compiler macro, which fixes the warnings above. Verify the __retain macro with readelf by checking object flags for 'R': $ readelf -Wa kernel/trace/bpf_trace.o Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al ... [178] .text.bpf_key_put PROGBITS 00000000 6420 0050 00 AXR 0 0 8 ... Key to Flags: ... R (retain), D (mbind), p (processor specific) Link: https://lore.kernel.org/bpf/ZlmGoT9KiYLZd91S@krava/T/ Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/r/202401211357.OCX9yllM-lkp@intel.com/ Fixes: 57e7c169cd6a ("bpf: Add __bpf_kfunc tag for marking kernel functions as kfuncs") Cc: stable(a)vger.kernel.org # v6.6+ Signed-off-by: Tony Ambardar <Tony.Ambardar(a)gmail.com> --- include/linux/btf.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/btf.h b/include/linux/btf.h index f9e56fd12a9f..7c3e40c3295e 100644 --- a/include/linux/btf.h +++ b/include/linux/btf.h @@ -82,7 +82,7 @@ * as to avoid issues such as the compiler inlining or eliding either a static * kfunc, or a global kfunc in an LTO build. */ -#define __bpf_kfunc __used noinline +#define __bpf_kfunc __used __retain noinline #define __bpf_kfunc_start_defs() \ __diag_push(); \ -- 2.34.1

12 months

1
0
0 0

Re: Patch "KVM: arm64: nv: Add sanitising to VNCR-backed sysregs" has been added to the 6.8-stable tree

by Marc Zyngier

On Mon, 03 Jun 2024 12:52:54 +0100, Sasha Levin <sashal(a)kernel.org> wrote: > > This is a note to let you know that I've just added the patch titled > > KVM: arm64: nv: Add sanitising to VNCR-backed sysregs > > to the 6.8-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: > kvm-arm64-nv-add-sanitising-to-vncr-backed-sysregs.patch > and it can be found in the queue-6.8 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. > > > > commit fbb2bcdc458dd7db3860f85a06e98cc25904d20d > Author: Marc Zyngier <maz(a)kernel.org> > Date: Wed Feb 14 13:18:04 2024 +0000 > > KVM: arm64: nv: Add sanitising to VNCR-backed sysregs > > [ Upstream commit 888f0880702293096619b300150cd7e59fcd9743 ] > > VNCR-backed "registers" are actually only memory. Which means that > there is zero control over what the guest can write, and that it > is the hypervisor's job to actually sanitise the content of the > backing store. Yeah, this is fun. > > In order to preserve some form of sanity, add a repainting mechanism > that makes use of a per-VM set of RES0/RES1 masks, one pair per VNCR > register. These masks get applied on access to the backing store via > __vcpu_sys_reg(), ensuring that the state that is consumed by KVM is > correct. > > So far, nothing populates these masks, but stay tuned. > > Signed-off-by: Marc Zyngier <maz(a)kernel.org> > Reviewed-by: Joey Gouly <joey.gouly(a)arm.com> > Link: https://lore.kernel.org/r/20240214131827.2856277-4-maz@kernel.org > Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> > Stable-dep-of: ce5d2448eb8f ("KVM: arm64: Destroy mpidr_data for 'late' vCPU creation") > Signed-off-by: Sasha Levin <sashal(a)kernel.org> Please drop this. It serves no purpose on 6.8 aside from wasting memory. If backporting ce5d2448eb8f is hard due to some conflicts, we'll tackle it ourselves. Thanks, M. -- Without deviation from the norm, progress is not possible.

12 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2024