May 2025 - Linux-stable-mirror

+ mm-khugepaged-fix-race-with-folio-split-free-using-temporary-reference.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/khugepaged: fix race with folio split/free using temporary reference has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-khugepaged-fix-race-with-folio-split-free-using-temporary-reference.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Shivank Garg <shivankg(a)amd.com> Subject: mm/khugepaged: fix race with folio split/free using temporary reference Date: Mon, 26 May 2025 18:28:18 +0000 hpage_collapse_scan_file() calls is_refcount_suitable(), which in turn calls folio_mapcount(). folio_mapcount() checks folio_test_large() before proceeding to folio_large_mapcount(), but there is a race window where the folio may get split/freed between these checks, triggering: VM_WARN_ON_FOLIO(!folio_test_large(folio), folio) Take a temporary reference to the folio in hpage_collapse_scan_file(). This stabilizes the folio during refcount check and prevents incorrect large folio detection due to concurrent split/free. Use helper folio_expected_ref_count() + 1 to compare with folio_ref_count() instead of using is_refcount_suitable(). Link: https://lkml.kernel.org/r/20250526182818.37978-1-shivankg@amd.com Fixes: 05c5323b2a34 ("mm: track mapcount of large folios in single value") Signed-off-by: Shivank Garg <shivankg(a)amd.com> Reported-by: syzbot+2b99589e33edbe9475ca(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6828470d.a70a0220.38f255.000c.GAE@google.com Suggested-by: David Hildenbrand <david(a)redhat.com> Acked-by: David Hildenbrand <david(a)redhat.com> Acked-by: Dev Jain <dev.jain(a)arm.com> Reviewed-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: Bharata B Rao <bharata(a)amd.com> Cc: Fengwei Yin <fengwei.yin(a)intel.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Mariano Pache <npache(a)redhat.com> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Zi Yan <ziy(a)nvidia.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/khugepaged.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) --- a/mm/khugepaged.c~mm-khugepaged-fix-race-with-folio-split-free-using-temporary-reference +++ a/mm/khugepaged.c @@ -2295,6 +2295,17 @@ static int hpage_collapse_scan_file(stru continue; } + if (!folio_try_get(folio)) { + xas_reset(&xas); + continue; + } + + if (unlikely(folio != xas_reload(&xas))) { + folio_put(folio); + xas_reset(&xas); + continue; + } + if (folio_order(folio) == HPAGE_PMD_ORDER && folio->index == start) { /* Maybe PMD-mapped */ @@ -2305,23 +2316,27 @@ static int hpage_collapse_scan_file(stru * it's safe to skip LRU and refcount checks before * returning. */ + folio_put(folio); break; } node = folio_nid(folio); if (hpage_collapse_scan_abort(node, cc)) { result = SCAN_SCAN_ABORT; + folio_put(folio); break; } cc->node_load[node]++; if (!folio_test_lru(folio)) { result = SCAN_PAGE_LRU; + folio_put(folio); break; } - if (!is_refcount_suitable(folio)) { + if (folio_expected_ref_count(folio) + 1 != folio_ref_count(folio)) { result = SCAN_PAGE_COUNT; + folio_put(folio); break; } @@ -2333,6 +2348,7 @@ static int hpage_collapse_scan_file(stru */ present += folio_nr_pages(folio); + folio_put(folio); if (need_resched()) { xas_pause(&xas); _ Patches currently in -mm which might be from shivankg(a)amd.com are mm-khugepaged-fix-race-with-folio-split-free-using-temporary-reference.patch mm-khugepaged-clean-up-refcount-check-using-folio_expected_ref_count.patch

6 days, 22 hours

1
0
0 0

[PATCH] block: Fix a deadlock related freezing zoned storage devices

by Bart Van Assche

blk_mq_freeze_queue() never terminates if one or more bios are on the plug list and if the block device driver defines a .submit_bio() method. This is the case for device mapper drivers. The deadlock happens because blk_mq_freeze_queue() waits for q_usage_counter to drop to zero, because a queue reference is held by bios on the plug list and because the __bio_queue_enter() call in __submit_bio() waits for the queue to be unfrozen. This patch fixes the following deadlock: Workqueue: dm-51_zwplugs blk_zone_wplug_bio_work Call trace: __schedule+0xb08/0x1160 schedule+0x48/0xc8 __bio_queue_enter+0xcc/0x1d0 __submit_bio+0x100/0x1b0 submit_bio_noacct_nocheck+0x230/0x49c blk_zone_wplug_bio_work+0x168/0x250 process_one_work+0x26c/0x65c worker_thread+0x33c/0x498 kthread+0x110/0x134 ret_from_fork+0x10/0x20 Call trace: __switch_to+0x230/0x410 __schedule+0xb08/0x1160 schedule+0x48/0xc8 blk_mq_freeze_queue_wait+0x78/0xb8 blk_mq_freeze_queue+0x90/0xa4 queue_attr_store+0x7c/0xf0 sysfs_kf_write+0x98/0xc8 kernfs_fop_write_iter+0x12c/0x1d4 vfs_write+0x340/0x3ac ksys_write+0x78/0xe8 Cc: Christoph Hellwig <hch(a)lst.de> Cc: Damien Le Moal <dlemoal(a)kernel.org> Cc: Yu Kuai <yukuai1(a)huaweicloud.com> Cc: Ming Lei <ming.lei(a)redhat.com> Cc: stable(a)vger.kernel.org Fixes: dd291d77cc90 ("block: Introduce zone write plugging") Signed-off-by: Bart Van Assche <bvanassche(a)acm.org> --- Changes compared to v1: fixed a race condition. Call bio_zone_write_plugging() only before submitting the bio and not after it has been submitted. block/blk-core.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/block/blk-core.c b/block/blk-core.c index b862c66018f2..713fb3865260 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -621,6 +621,13 @@ static inline blk_status_t blk_check_zone_append(struct request_queue *q, return BLK_STS_OK; } +/* + * Do not call bio_queue_enter() if the BIO_ZONE_WRITE_PLUGGING flag has been + * set because this causes blk_mq_freeze_queue() to deadlock if + * blk_zone_wplug_bio_work() submits a bio. Calling bio_queue_enter() for bios + * on the plug list is not necessary since a q_usage_counter reference is held + * while a bio is on the plug list. + */ static void __submit_bio(struct bio *bio) { /* If plug is not used, add new plug here to cache nsecs time. */ @@ -633,8 +640,12 @@ static void __submit_bio(struct bio *bio) if (!bdev_test_flag(bio->bi_bdev, BD_HAS_SUBMIT_BIO)) { blk_mq_submit_bio(bio); - } else if (likely(bio_queue_enter(bio) == 0)) { + } else { struct gendisk *disk = bio->bi_bdev->bd_disk; + bool zwp = bio_zone_write_plugging(bio); + + if (unlikely(!zwp && bio_queue_enter(bio) != 0)) + goto finish_plug; if ((bio->bi_opf & REQ_POLLED) && !(disk->queue->limits.features & BLK_FEAT_POLL)) { @@ -643,9 +654,12 @@ static void __submit_bio(struct bio *bio) } else { disk->fops->submit_bio(bio); } - blk_queue_exit(disk->queue); + + if (!zwp) + blk_queue_exit(disk->queue); } +finish_plug: blk_finish_plug(&plug); }

6 days, 23 hours

5
15
0 0

[PATCH 1/2] drm/buddy: Add public helper to dirty blocks

by Natalie Vock

Cleared blocks that are handed out to users after allocation cannot be presumed to remain cleared. Thus, allocators using drm_buddy need to dirty all blocks on the allocation success path. Provide a helper for them to use. Fixes: 96950929eb232 ("drm/buddy: Implement tracking clear page feature") Cc: stable(a)vger.kernel.org Signed-off-by: Natalie Vock <natalie.vock(a)gmx.de> --- include/drm/drm_buddy.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/include/drm/drm_buddy.h b/include/drm/drm_buddy.h index 9689a7c5dd36..48628ff1c24f 100644 --- a/include/drm/drm_buddy.h +++ b/include/drm/drm_buddy.h @@ -142,6 +142,12 @@ drm_buddy_block_size(struct drm_buddy *mm, return mm->chunk_size << drm_buddy_block_order(block); } +static inline void +drm_buddy_block_set_dirty(struct drm_buddy_block *block) +{ + block->header &= ~DRM_BUDDY_HEADER_CLEAR; +} + int drm_buddy_init(struct drm_buddy *mm, u64 size, u64 chunk_size); void drm_buddy_fini(struct drm_buddy *mm); -- 2.49.0

1 week

1
0
0 0

[PATCH v2] drm/xe/sched: stop re-submitting signalled jobs

by Matthew Auld

Customer is reporting a really subtle issue where we get random DMAR faults, hangs and other nasties for kernel migration jobs when stressing stuff like s2idle/s3/s4. The explosions seems to happen somewhere after resuming the system with splats looking something like: PM: suspend exit rfkill: input handler disabled xe 0000:00:02.0: [drm] GT0: Engine reset: engine_class=bcs, logical_mask: 0x2, guc_id=0 xe 0000:00:02.0: [drm] GT0: Timedout job: seqno=24496, lrc_seqno=24496, guc_id=0, flags=0x13 in no process [-1] xe 0000:00:02.0: [drm] GT0: Kernel-submitted job timed out The likely cause appears to be a race between suspend cancelling the worker that processes the free_job()'s, such that we still have pending jobs to be freed after the cancel. Following from this, on resume the pending_list will now contain at least one already complete job, but it looks like we call drm_sched_resubmit_jobs(), which will then call run_job() on everything still on the pending_list. But if the job was already complete, then all the resources tied to the job, like the bb itself, any memory that is being accessed, the iommu mappings etc. might be long gone since those are usually tied to the fence signalling. This scenario can be seen in ftrace when running a slightly modified xe_pm (kernel was only modified to inject artificial latency into free_job to make the race easier to hit): xe_sched_job_run: dev=0000:00:02.0, fence=0xffff888276cc8540, seqno=0, lrc_seqno=0, gt=0, guc_id=0, batch_addr=0x000000146910 ... xe_exec_queue_stop: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=0, guc_state=0x0, flags=0x13 xe_exec_queue_stop: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=1, guc_state=0x0, flags=0x4 xe_exec_queue_stop: dev=0000:00:02.0, 4:0x1, gt=1, width=1, guc_id=0, guc_state=0x0, flags=0x3 xe_exec_queue_stop: dev=0000:00:02.0, 1:0x1, gt=1, width=1, guc_id=1, guc_state=0x0, flags=0x3 xe_exec_queue_stop: dev=0000:00:02.0, 4:0x1, gt=1, width=1, guc_id=2, guc_state=0x0, flags=0x3 xe_exec_queue_resubmit: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=0, guc_state=0x0, flags=0x13 xe_sched_job_run: dev=0000:00:02.0, fence=0xffff888276cc8540, seqno=0, lrc_seqno=0, gt=0, guc_id=0, batch_addr=0x000000146910 ... ..... xe_exec_queue_memory_cat_error: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=0, guc_state=0x3, flags=0x13 So the job_run() is clearly triggered twice for the same job, even though the first must have already signalled to completion during suspend. We can also see a CAT error after the re-submit. To prevent this try to call xe_sched_stop() to forcefully remove anything on the pending_list that has already signalled, before we re-submit. v2: - Make sure to re-arm the fence callbacks with sched_start(). Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4856 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: William Tseng <william.tseng(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.8+ --- drivers/gpu/drm/xe/xe_gpu_scheduler.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/xe/xe_gpu_scheduler.h b/drivers/gpu/drm/xe/xe_gpu_scheduler.h index c250ea773491..0c8fe0461df9 100644 --- a/drivers/gpu/drm/xe/xe_gpu_scheduler.h +++ b/drivers/gpu/drm/xe/xe_gpu_scheduler.h @@ -51,7 +51,9 @@ static inline void xe_sched_tdr_queue_imm(struct xe_gpu_scheduler *sched) static inline void xe_sched_resubmit_jobs(struct xe_gpu_scheduler *sched) { + drm_sched_stop(&sched->base, NULL); /* remove completed jobs */ drm_sched_resubmit_jobs(&sched->base); + drm_sched_start(&sched->base, 0); /* re-add fence callback for pending jobs */ } static inline bool -- 2.49.0

1 week

2
1
0 0

[PATCH 0/3] ASoC: codecs: wcd93xx: Few regulator supplies fixes

by Krzysztof Kozlowski

Fix cleanup paths in wcd9335 and wcd937x codec drivers. Best regards, Krzysztof --- Krzysztof Kozlowski (3): ASoC: codecs: wcd9335: Fix missing free of regulator supplies ASoC: codecs: wcd937x: Drop unused buck_supply ASoC: codecs: wcd9375: Fix double free of regulator supplies sound/soc/codecs/wcd9335.c | 25 +++++++------------------ sound/soc/codecs/wcd937x.c | 7 +------ 2 files changed, 8 insertions(+), 24 deletions(-) --- base-commit: 393d0c54cae31317deaa9043320c5fd9454deabc change-id: 20250526-b4-b4-asoc-wcd9395-vdd-px-fixes-0ce64398f9cc Best regards, -- Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>

1 week

2
4
0 0

Re: Patch "libbpf: Pass BPF token from find_prog_btf_id to BPF_BTF_GET_FD_BY_ID" has been added to the 6

by Pascal Ernster

[2025-05-22 23:08] Sasha Levin: > This is a note to let you know that I've just added the patch titled > > libbpf: Pass BPF token from find_prog_btf_id to BPF_BTF_GET_FD_BY_ID > > to the 6.14-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: > libbpf-pass-bpf-token-from-find_prog_btf_id-to-bpf_b.patch > and it can be found in the queue-6.14 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 7a8beec7026564efe57ebf9c4c568ed0071f2e39 > Author: Mykyta Yatsenko <yatsenko(a)meta.com> > Date: Mon Mar 17 17:40:38 2025 +0000 > > libbpf: Pass BPF token from find_prog_btf_id to BPF_BTF_GET_FD_BY_ID > > [ Upstream commit 974ef9f0d23edc1a802691c585b84514b414a96d ] > > Pass BPF token from bpf_program__set_attach_target to > BPF_BTF_GET_FD_BY_ID bpf command. > When freplace program attaches to target program, it needs to look up > for BTF of the target, this may require BPF token, if, for example, > running from user namespace. > > Signed-off-by: Mykyta Yatsenko <yatsenko(a)meta.com> > Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> > Acked-by: Yonghong Song <yonghong.song(a)linux.dev> > Link: https://lore.kernel.org/bpf/20250317174039.161275-4-mykyta.yatsenko5@gmail.… > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c > index 359f73ead6137..a9c3e33d0f8a9 100644 > --- a/tools/lib/bpf/bpf.c > +++ b/tools/lib/bpf/bpf.c > @@ -1097,7 +1097,7 @@ int bpf_map_get_fd_by_id(__u32 id) > int bpf_btf_get_fd_by_id_opts(__u32 id, > const struct bpf_get_fd_by_id_opts *opts) > { > - const size_t attr_sz = offsetofend(union bpf_attr, open_flags); > + const size_t attr_sz = offsetofend(union bpf_attr, fd_by_id_token_fd); > union bpf_attr attr; > int fd; > > @@ -1107,6 +1107,7 @@ int bpf_btf_get_fd_by_id_opts(__u32 id, > memset(&attr, 0, attr_sz); > attr.btf_id = id; > attr.open_flags = OPTS_GET(opts, open_flags, 0); > + attr.fd_by_id_token_fd = OPTS_GET(opts, token_fd, 0); > > fd = sys_bpf_fd(BPF_BTF_GET_FD_BY_ID, &attr, attr_sz); > return libbpf_err_errno(fd); > diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h > index 435da95d20589..777627d33d257 100644 > --- a/tools/lib/bpf/bpf.h > +++ b/tools/lib/bpf/bpf.h > @@ -487,9 +487,10 @@ LIBBPF_API int bpf_link_get_next_id(__u32 start_id, __u32 *next_id); > struct bpf_get_fd_by_id_opts { > size_t sz; /* size of this struct for forward/backward compatibility */ > __u32 open_flags; /* permissions requested for the operation on fd */ > + __u32 token_fd; > size_t :0; > }; > -#define bpf_get_fd_by_id_opts__last_field open_flags > +#define bpf_get_fd_by_id_opts__last_field token_fd > > LIBBPF_API int bpf_prog_get_fd_by_id(__u32 id); > LIBBPF_API int bpf_prog_get_fd_by_id_opts(__u32 id, > diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c > index 560b519f820e2..03cc7c46c16b5 100644 > --- a/tools/lib/bpf/btf.c > +++ b/tools/lib/bpf/btf.c > @@ -1619,12 +1619,18 @@ struct btf *btf_get_from_fd(int btf_fd, struct btf *base_btf) > return btf; > } > > -struct btf *btf__load_from_kernel_by_id_split(__u32 id, struct btf *base_btf) > +struct btf *btf_load_from_kernel(__u32 id, struct btf *base_btf, int token_fd) > { > struct btf *btf; > int btf_fd; > + LIBBPF_OPTS(bpf_get_fd_by_id_opts, opts); > + > + if (token_fd) { > + opts.open_flags |= BPF_F_TOKEN_FD; > + opts.token_fd = token_fd; > + } > > - btf_fd = bpf_btf_get_fd_by_id(id); > + btf_fd = bpf_btf_get_fd_by_id_opts(id, &opts); > if (btf_fd < 0) > return libbpf_err_ptr(-errno); > > @@ -1634,6 +1640,11 @@ struct btf *btf__load_from_kernel_by_id_split(__u32 id, struct btf *base_btf) > return libbpf_ptr(btf); > } > > +struct btf *btf__load_from_kernel_by_id_split(__u32 id, struct btf *base_btf) > +{ > + return btf_load_from_kernel(id, base_btf, 0); > +} > + > struct btf *btf__load_from_kernel_by_id(__u32 id) > { > return btf__load_from_kernel_by_id_split(id, NULL); > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > index 194809da51725..6b436ec872b0f 100644 > --- a/tools/lib/bpf/libbpf.c > +++ b/tools/lib/bpf/libbpf.c > @@ -9959,7 +9959,7 @@ int libbpf_find_vmlinux_btf_id(const char *name, > return libbpf_err(err); > } > > -static int libbpf_find_prog_btf_id(const char *name, __u32 attach_prog_fd) > +static int libbpf_find_prog_btf_id(const char *name, __u32 attach_prog_fd, int token_fd) > { > struct bpf_prog_info info; > __u32 info_len = sizeof(info); > @@ -9979,7 +9979,7 @@ static int libbpf_find_prog_btf_id(const char *name, __u32 attach_prog_fd) > pr_warn("The target program doesn't have BTF\n"); > goto out; > } > - btf = btf__load_from_kernel_by_id(info.btf_id); > + btf = btf_load_from_kernel(info.btf_id, NULL, token_fd); > err = libbpf_get_error(btf); > if (err) { > pr_warn("Failed to get BTF %d of the program: %s\n", info.btf_id, errstr(err)); > @@ -10062,7 +10062,7 @@ static int libbpf_find_attach_btf_id(struct bpf_program *prog, const char *attac > pr_warn("prog '%s': attach program FD is not set\n", prog->name); > return -EINVAL; > } > - err = libbpf_find_prog_btf_id(attach_name, attach_prog_fd); > + err = libbpf_find_prog_btf_id(attach_name, attach_prog_fd, prog->obj->token_fd); > if (err < 0) { > pr_warn("prog '%s': failed to find BPF program (FD %d) BTF ID for '%s': %s\n", > prog->name, attach_prog_fd, attach_name, errstr(err)); > @@ -12858,7 +12858,7 @@ struct bpf_link *bpf_program__attach_freplace(const struct bpf_program *prog, > if (target_fd) { > LIBBPF_OPTS(bpf_link_create_opts, target_opts); > > - btf_id = libbpf_find_prog_btf_id(attach_func_name, target_fd); > + btf_id = libbpf_find_prog_btf_id(attach_func_name, target_fd, prog->obj->token_fd); > if (btf_id < 0) > return libbpf_err_ptr(btf_id); > > @@ -13679,7 +13679,7 @@ int bpf_program__set_attach_target(struct bpf_program *prog, > > if (attach_prog_fd) { > btf_id = libbpf_find_prog_btf_id(attach_func_name, > - attach_prog_fd); > + attach_prog_fd, prog->obj->token_fd); > if (btf_id < 0) > return libbpf_err(btf_id); > } else { > diff --git a/tools/lib/bpf/libbpf_internal.h b/tools/lib/bpf/libbpf_internal.h > index de498e2dd6b0b..76669c73dcd16 100644 > --- a/tools/lib/bpf/libbpf_internal.h > +++ b/tools/lib/bpf/libbpf_internal.h > @@ -409,6 +409,7 @@ int libbpf__load_raw_btf(const char *raw_types, size_t types_len, > int btf_load_into_kernel(struct btf *btf, > char *log_buf, size_t log_sz, __u32 log_level, > int token_fd); > +struct btf *btf_load_from_kernel(__u32 id, struct btf *base_btf, int token_fd); > > struct btf *btf_get_from_fd(int btf_fd, struct btf *base_btf); > void btf_get_kernel_prefix_kind(enum bpf_attach_type attach_type, Hi, this patch breaks the build for Kernel 6.14.8 with all the other patches from https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tre… applied on top. A backported version of the same patch is also in queue-6.12, but I haven't tested if that one also breaks the build for Kernel 6.12.30. Regards Pascal

1 week

2
4
0 0

[PATCH v1 RESEND stable tags] nvmem: layouts: u-boot-env: remove crc32 endianness conversion

by Michael C. Pratt

On 11 Oct 2022, it was reported that the crc32 verification of the u-boot environment failed only on big-endian systems for the u-boot-env nvmem layout driver with the following error. Invalid calculated CRC32: 0x88cd6f09 (expected: 0x096fcd88) This problem has been present since the driver was introduced, and before it was made into a layout driver. The suggested fix at the time was to use further endianness conversion macros in order to have both the stored and calculated crc32 values to compare always represented in the system's endianness. This was not accepted due to sparse warnings and some disagreement on how to handle the situation. Later on in a newer revision of the patch, it was proposed to use cpu_to_le32() for both values to compare instead of le32_to_cpu() and store the values as __le32 type to remove compilation errors. The necessity of this is based on the assumption that the use of crc32() requires endianness conversion because the algorithm uses little-endian, however, this does not prove to be the case and the issue is unrelated. Upon inspecting the current kernel code, there already is an existing use of le32_to_cpu() in this driver, which suggests there already is special handling for big-endian systems, however, it is big-endian systems that have the problem. This, being the only functional difference between architectures in the driver combined with the fact that the suggested fix was to use the exact same endianness conversion for the values brings up the possibility that it was not necessary to begin with, as the same endianness conversion for two values expected to be the same is expected to be equivalent to no conversion at all. After inspecting the u-boot environment of devices of both endianness and trying to remove the existing endianness conversion, the problem is resolved in an equivalent way as the other suggested fixes. Ultimately, it seems that u-boot is agnostic to endianness at least for the purpose of environment variables. In other words, u-boot reads and writes the stored crc32 value with the same endianness that the crc32 value is calculated with in whichever endianness a certain architecture runs on. Therefore, the u-boot-env driver does not need to convert endianness. Remove the usage of endianness macros in the u-boot-env driver, and change the type of local variables to maintain the same return type. If there is a special situation in the case of endianness, it would be a corner case and should be handled by a unique "compatible". Even though it is not necessary to use endianness conversion macros here, it may be useful to use them in the future for consistent error printing. Fixes: d5542923f200 ("nvmem: add driver handling U-Boot environment variables") Reported-by: INAGAKI Hiroshi <musashino.open(a)gmail.com> Link: https://lore.kernel.org/all/20221011024928.1807-1-musashino.open@gmail.com Cc: <stable(a)vger.kernel.org> # 6.12.x Cc: <stable(a)vger.kernel.org> # 6.6.x: f4cf4e5: Revert "nvmem: add new config option" Cc: <stable(a)vger.kernel.org> # 6.6.x: 7f38b70: of: device: Export of_device_make_bus_id() Cc: <stable(a)vger.kernel.org> # 6.6.x: 4a1a402: nvmem: Move of_nvmem_layout_get_container() in another header Cc: <stable(a)vger.kernel.org> # 6.6.x: fc29fd8: nvmem: core: Rework layouts to become regular devices Cc: <stable(a)vger.kernel.org> # 6.6.x: 0331c61: nvmem: core: Expose cells through sysfs Cc: <stable(a)vger.kernel.org> # 6.6.x: 401df0d: nvmem: layouts: refactor .add_cells() callback arguments Cc: <stable(a)vger.kernel.org> # 6.6.x: 6d0ca4a: nvmem: layouts: store owner from modules with nvmem_layout_driver_register() Cc: <stable(a)vger.kernel.org> # 6.6.x: 5f15811: nvmem: layouts: add U-Boot env layout Cc: <stable(a)vger.kernel.org> # 6.6.x Signed-off-by: Michael C. Pratt <mcpratt(a)pm.me> --- drivers/nvmem/layouts/u-boot-env.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/nvmem/layouts/u-boot-env.c b/drivers/nvmem/layouts/u-boot-env.c index 731e6f4f12b2..21f6dcf905dd 100644 --- a/drivers/nvmem/layouts/u-boot-env.c +++ b/drivers/nvmem/layouts/u-boot-env.c @@ -92,7 +92,7 @@ int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem, size_t crc32_data_offset; size_t crc32_data_len; size_t crc32_offset; - __le32 *crc32_addr; + uint32_t *crc32_addr; size_t data_offset; size_t data_len; size_t dev_size; @@ -143,8 +143,8 @@ int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem, goto err_kfree; } - crc32_addr = (__le32 *)(buf + crc32_offset); - crc32 = le32_to_cpu(*crc32_addr); + crc32_addr = (uint32_t *)(buf + crc32_offset); + crc32 = *crc32_addr; crc32_data_len = dev_size - crc32_data_offset; data_len = dev_size - data_offset; base-commit: 38fec10eb60d687e30c8c6b5420d86e8149f7557 -- 2.30.2

1 week

1
0
0 0

[PATCH v2 net 0/1] e1000e: fix heap overflow in e1000_set_eeprom()

by Mikael Wessel

v2: patch the correct write helper and add bounds-checking; v1 mistakenly guarded e1000_get_eeprom() (read path). --- Mikael Wessel (1): e1000e: fix heap overflow in e1000_set_eeprom() drivers/net/ethernet/intel/e1000e/ethtool.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.48.1

1 week

4
5
0 0

Backports of d0afcfeb9e3810ec89d1ffde1a0e36621bb75dca for 6.6 and older

by Nathan Chancellor

Hi Greg and Sasha, Please find attached backports of commit d0afcfeb9e38 ("kbuild: Disable -Wdefault-const-init-unsafe") for 6.6 and older, which is needed for tip of tree versions of LLVM. Please let me know if there are any questions. Cheers, Nathan

1 week

2
1
0 0

Series for -Wunterminated-string-initialization in 6.14 and 6.12

by Nathan Chancellor

Hi Greg and Sasha, Please find attatched backports for 6.14 and 6.12 (which have -Wextra enabled by default) to turn off a new warning from -Wextra in GCC 15 and Clang 21, -Wunterminated-string-initialization, which is fatal when CONFIG_WERROR is enabled. Please let me know if there are any issues or questions. Cheers, Nathan

1 week

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2025