June 2024 - Linux-stable-mirror

[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

10 months, 4 weeks

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

10 months, 4 weeks

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);

10 months, 4 weeks

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);

10 months, 4 weeks

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; > }

10 months, 4 weeks

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. >

10 months, 4 weeks

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)

10 months, 4 weeks

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

10 months, 4 weeks

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.

10 months, 4 weeks

1
0
0 0

[tip: irq/urgent] irqchip/sifive-plic: Chain to parent IRQ after handlers are ready

by tip-bot2 for Samuel Holland

The following commit has been merged into the irq/urgent branch of tip: Commit-ID: e306a894bd511804ba9db7c00ca9cc05b55df1f2 Gitweb: https://git.kernel.org/tip/e306a894bd511804ba9db7c00ca9cc05b55df1f2 Author: Samuel Holland <samuel.holland(a)sifive.com> AuthorDate: Wed, 29 May 2024 14:54:56 -07:00 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Mon, 03 Jun 2024 13:53:12 +02:00 irqchip/sifive-plic: Chain to parent IRQ after handlers are ready Now that the PLIC uses a platform driver, the driver is probed later in the boot process, where interrupts from peripherals might already be pending. As a result, plic_handle_irq() may be called as early as the call to irq_set_chained_handler() completes. But this call happens before the per-context handler is completely set up, so there is a window where plic_handle_irq() can see incomplete per-context state and crash. Avoid this by delaying the call to irq_set_chained_handler() until all handlers from all PLICs are initialized. Fixes: 8ec99b033147 ("irqchip/sifive-plic: Convert PLIC driver into a platform driver") Reported-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Signed-off-by: Samuel Holland <samuel.holland(a)sifive.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Tested-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Reviewed-by: Anup Patel <anup(a)brainfault.org> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20240529215458.937817-1-samuel.holland@sifive.com Closes: https://lore.kernel.org/r/CAMuHMdVYFFR7K5SbHBLY-JHhb7YpgGMS_hnRWm8H0KD-wBo+… --- drivers/irqchip/irq-sifive-plic.c | 34 +++++++++++++++--------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c index 8fb183c..9e22f7e 100644 --- a/drivers/irqchip/irq-sifive-plic.c +++ b/drivers/irqchip/irq-sifive-plic.c @@ -85,7 +85,7 @@ struct plic_handler { struct plic_priv *priv; }; static int plic_parent_irq __ro_after_init; -static bool plic_cpuhp_setup_done __ro_after_init; +static bool plic_global_setup_done __ro_after_init; static DEFINE_PER_CPU(struct plic_handler, plic_handlers); static int plic_irq_set_type(struct irq_data *d, unsigned int type); @@ -487,10 +487,8 @@ static int plic_probe(struct platform_device *pdev) unsigned long plic_quirks = 0; struct plic_handler *handler; u32 nr_irqs, parent_hwirq; - struct irq_domain *domain; struct plic_priv *priv; irq_hw_number_t hwirq; - bool cpuhp_setup; if (is_of_node(dev->fwnode)) { const struct of_device_id *id; @@ -549,14 +547,6 @@ static int plic_probe(struct platform_device *pdev) continue; } - /* Find parent domain and register chained handler */ - domain = irq_find_matching_fwnode(riscv_get_intc_hwnode(), DOMAIN_BUS_ANY); - if (!plic_parent_irq && domain) { - plic_parent_irq = irq_create_mapping(domain, RV_IRQ_EXT); - if (plic_parent_irq) - irq_set_chained_handler(plic_parent_irq, plic_handle_irq); - } - /* * When running in M-mode we need to ignore the S-mode handler. * Here we assume it always comes later, but that might be a @@ -597,25 +587,35 @@ done: goto fail_cleanup_contexts; /* - * We can have multiple PLIC instances so setup cpuhp state + * We can have multiple PLIC instances so setup global state * and register syscore operations only once after context * handlers of all online CPUs are initialized. */ - if (!plic_cpuhp_setup_done) { - cpuhp_setup = true; + if (!plic_global_setup_done) { + struct irq_domain *domain; + bool global_setup = true; + for_each_online_cpu(cpu) { handler = per_cpu_ptr(&plic_handlers, cpu); if (!handler->present) { - cpuhp_setup = false; + global_setup = false; break; } } - if (cpuhp_setup) { + + if (global_setup) { + /* Find parent domain and register chained handler */ + domain = irq_find_matching_fwnode(riscv_get_intc_hwnode(), DOMAIN_BUS_ANY); + if (domain) + plic_parent_irq = irq_create_mapping(domain, RV_IRQ_EXT); + if (plic_parent_irq) + irq_set_chained_handler(plic_parent_irq, plic_handle_irq); + cpuhp_setup_state(CPUHP_AP_IRQ_SIFIVE_PLIC_STARTING, "irqchip/sifive/plic:starting", plic_starting_cpu, plic_dying_cpu); register_syscore_ops(&plic_irq_syscore_ops); - plic_cpuhp_setup_done = true; + plic_global_setup_done = true; } }

10 months, 4 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2024