May 2025 - Linux-stable-mirror

[Patch v2 1/4] Drivers: hv: Allocate interrupt and monitor pages aligned to system page boundary

by longli＠linuxonhyperv.com

From: Long Li <longli(a)microsoft.com> There are use cases that interrupt and monitor pages are mapped to user-mode through UIO, they need to be system page aligned. Some Hyper-V allocation APIs introduced earlier broke those requirements. Fix those APIs by always allocating Hyper-V page at system page boundaries. Cc: stable(a)vger.kernel.org Fixes: ca48739e59df ("Drivers: hv: vmbus: Move Hyper-V page allocator to arch neutral code") Signed-off-by: Long Li <longli(a)microsoft.com> --- drivers/hv/hv_common.c | 35 ++++++++++------------------------- 1 file changed, 10 insertions(+), 25 deletions(-) diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c index a7d7494feaca..297ccd7d4997 100644 --- a/drivers/hv/hv_common.c +++ b/drivers/hv/hv_common.c @@ -106,41 +106,26 @@ void __init hv_common_free(void) } /* - * Functions for allocating and freeing memory with size and - * alignment HV_HYP_PAGE_SIZE. These functions are needed because - * the guest page size may not be the same as the Hyper-V page - * size. We depend upon kmalloc() aligning power-of-two size - * allocations to the allocation size boundary, so that the - * allocated memory appears to Hyper-V as a page of the size - * it expects. + * A Hyper-V page can be used by UIO for mapping to user-space, it should + * always be allocated on system page boundaries. */ - void *hv_alloc_hyperv_page(void) { - BUILD_BUG_ON(PAGE_SIZE < HV_HYP_PAGE_SIZE); - - if (PAGE_SIZE == HV_HYP_PAGE_SIZE) - return (void *)__get_free_page(GFP_KERNEL); - else - return kmalloc(HV_HYP_PAGE_SIZE, GFP_KERNEL); + BUILD_BUG_ON(PAGE_SIZE < HV_HYP_PAGE_SIZE); + return (void *)__get_free_page(GFP_KERNEL); } EXPORT_SYMBOL_GPL(hv_alloc_hyperv_page); void *hv_alloc_hyperv_zeroed_page(void) { - if (PAGE_SIZE == HV_HYP_PAGE_SIZE) - return (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO); - else - return kzalloc(HV_HYP_PAGE_SIZE, GFP_KERNEL); + BUILD_BUG_ON(PAGE_SIZE < HV_HYP_PAGE_SIZE); + return (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO); } EXPORT_SYMBOL_GPL(hv_alloc_hyperv_zeroed_page); void hv_free_hyperv_page(void *addr) { - if (PAGE_SIZE == HV_HYP_PAGE_SIZE) - free_page((unsigned long)addr); - else - kfree(addr); + free_page((unsigned long)addr); } EXPORT_SYMBOL_GPL(hv_free_hyperv_page); @@ -272,7 +257,7 @@ static void hv_kmsg_dump_unregister(void) atomic_notifier_chain_unregister(&panic_notifier_list, &hyperv_panic_report_block); - hv_free_hyperv_page(hv_panic_page); + kfree(hv_panic_page); hv_panic_page = NULL; } @@ -280,7 +265,7 @@ static void hv_kmsg_dump_register(void) { int ret; - hv_panic_page = hv_alloc_hyperv_zeroed_page(); + hv_panic_page = kzalloc(HV_HYP_PAGE_SIZE, GFP_KERNEL); if (!hv_panic_page) { pr_err("Hyper-V: panic message page memory allocation failed\n"); return; @@ -289,7 +274,7 @@ static void hv_kmsg_dump_register(void) ret = kmsg_dump_register(&hv_kmsg_dumper); if (ret) { pr_err("Hyper-V: kmsg dump register error 0x%x\n", ret); - hv_free_hyperv_page(hv_panic_page); + kfree(hv_panic_page); hv_panic_page = NULL; } } -- 2.34.1

7 months, 2 weeks

3
2
0 0

+ zsmalloc-dont-underflow-size-calculation-in-zs_obj_write.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: zsmalloc: don't underflow size calculation in zs_obj_write() has been added to the -mm mm-hotfixes-unstable branch. Its filename is zsmalloc-dont-underflow-size-calculation-in-zs_obj_write.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: Sergey Senozhatsky <senozhatsky(a)chromium.org> Subject: zsmalloc: don't underflow size calculation in zs_obj_write() Date: Sun, 4 May 2025 20:00:22 +0900 Do not mix class->size and object size during offsets/sizes calculation in zs_obj_write(). Size classes can merge into clusters, based on objects-per-zspage and pages-per-zspage characteristics, so some size classes can store objects smaller than class->size. This becomes problematic when object size is much smaller than class->size - we can determine that object spans two physical pages, because we use a larger class->size for this, while the actual object is much smaller and fits one physical page, so there is nothing to write to the second page and memcpy() size calculation underflows. We always know the exact size in bytes of the object that we are about to write (store), so use it instead of class->size. Link: https://lkml.kernel.org/r/20250504110650.2783619-1-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Reported-by: Igor Belousov <igor.b(a)beldev.am> Tested-by: Igor Belousov <igor.b(a)beldev.am> Cc: Minchan Kim <minchan(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/zsmalloc.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/mm/zsmalloc.c~zsmalloc-dont-underflow-size-calculation-in-zs_obj_write +++ a/mm/zsmalloc.c @@ -1243,19 +1243,19 @@ void zs_obj_write(struct zs_pool *pool, class = zspage_class(pool, zspage); off = offset_in_page(class->size * obj_idx); - if (off + class->size <= PAGE_SIZE) { + if (!ZsHugePage(zspage)) + off += ZS_HANDLE_SIZE; + + if (off + mem_len <= PAGE_SIZE) { /* this object is contained entirely within a page */ void *dst = kmap_local_zpdesc(zpdesc); - if (!ZsHugePage(zspage)) - off += ZS_HANDLE_SIZE; memcpy(dst + off, handle_mem, mem_len); kunmap_local(dst); } else { /* this object spans two pages */ size_t sizes[2]; - off += ZS_HANDLE_SIZE; sizes[0] = PAGE_SIZE - off; sizes[1] = mem_len - sizes[0]; _ Patches currently in -mm which might be from senozhatsky(a)chromium.org are zsmalloc-dont-underflow-size-calculation-in-zs_obj_write.patch zsmalloc-prefer-the-the-original-pages-node-for-compressed-data-fix.patch zram-modernize-writeback-interface.patch zram-modernize-writeback-interface-v3.patch zram-modernize-writeback-interface-v4.patch zsmalloc-cleanup-headers-includes.patch documentation-zram-update-idle-pages-tracking-documentation.patch

7 months, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] mm, slab: clean up slab->obj_exts always" failed to apply to 6.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.14.y git checkout FETCH_HEAD git cherry-pick -x be8250786ca94952a19ce87f98ad9906448bc9ef # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025050521-provable-extent-4108@gregkh' --subject-prefix 'PATCH 6.14.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From be8250786ca94952a19ce87f98ad9906448bc9ef Mon Sep 17 00:00:00 2001 From: Zhenhua Huang <quic_zhenhuah(a)quicinc.com> Date: Mon, 21 Apr 2025 15:52:32 +0800 Subject: [PATCH] mm, slab: clean up slab->obj_exts always When memory allocation profiling is disabled at runtime or due to an error, shutdown_mem_profiling() is called: slab->obj_exts which previously allocated remains. It won't be cleared by unaccount_slab() because of mem_alloc_profiling_enabled() not true. It's incorrect, slab->obj_exts should always be cleaned up in unaccount_slab() to avoid following error: [...]BUG: Bad page state in process... .. [...]page dumped because: page still charged to cgroup [andriy.shevchenko(a)linux.intel.com: fold need_slab_obj_ext() into its only user] Fixes: 21c690a349ba ("mm: introduce slabobj_ext to support slab object extensions") Cc: stable(a)vger.kernel.org Signed-off-by: Zhenhua Huang <quic_zhenhuah(a)quicinc.com> Acked-by: David Rientjes <rientjes(a)google.com> Acked-by: Harry Yoo <harry.yoo(a)oracle.com> Tested-by: Harry Yoo <harry.yoo(a)oracle.com> Acked-by: Suren Baghdasaryan <surenb(a)google.com> Link: https://patch.msgid.link/20250421075232.2165527-1-quic_zhenhuah@quicinc.com Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> diff --git a/mm/slub.c b/mm/slub.c index dc9e729e1d26..be8b09e09d30 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2028,8 +2028,7 @@ int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s, return 0; } -/* Should be called only if mem_alloc_profiling_enabled() */ -static noinline void free_slab_obj_exts(struct slab *slab) +static inline void free_slab_obj_exts(struct slab *slab) { struct slabobj_ext *obj_exts; @@ -2049,18 +2048,6 @@ static noinline void free_slab_obj_exts(struct slab *slab) slab->obj_exts = 0; } -static inline bool need_slab_obj_ext(void) -{ - if (mem_alloc_profiling_enabled()) - return true; - - /* - * CONFIG_MEMCG creates vector of obj_cgroup objects conditionally - * inside memcg_slab_post_alloc_hook. No other users for now. - */ - return false; -} - #else /* CONFIG_SLAB_OBJ_EXT */ static inline void init_slab_obj_exts(struct slab *slab) @@ -2077,11 +2064,6 @@ static inline void free_slab_obj_exts(struct slab *slab) { } -static inline bool need_slab_obj_ext(void) -{ - return false; -} - #endif /* CONFIG_SLAB_OBJ_EXT */ #ifdef CONFIG_MEM_ALLOC_PROFILING @@ -2129,7 +2111,7 @@ __alloc_tagging_slab_alloc_hook(struct kmem_cache *s, void *object, gfp_t flags) static inline void alloc_tagging_slab_alloc_hook(struct kmem_cache *s, void *object, gfp_t flags) { - if (need_slab_obj_ext()) + if (mem_alloc_profiling_enabled()) __alloc_tagging_slab_alloc_hook(s, object, flags); } @@ -2601,8 +2583,12 @@ static __always_inline void account_slab(struct slab *slab, int order, static __always_inline void unaccount_slab(struct slab *slab, int order, struct kmem_cache *s) { - if (memcg_kmem_online() || need_slab_obj_ext()) - free_slab_obj_exts(slab); + /* + * The slab object extensions should now be freed regardless of + * whether mem_alloc_profiling_enabled() or not because profiling + * might have been disabled after slab->obj_exts got allocated. + */ + free_slab_obj_exts(slab); mod_node_page_state(slab_pgdat(slab), cache_vmstat_idx(s), -(PAGE_SIZE << order));

7 months, 2 weeks

2
3
0 0

[PATCH AUTOSEL 5.10 001/114] kconfig: merge_config: use an empty file as initfile

by Sasha Levin

From: Daniel Gomez <da.gomez(a)samsung.com> [ Upstream commit a26fe287eed112b4e21e854f173c8918a6a8596d ] The scripts/kconfig/merge_config.sh script requires an existing $INITFILE (or the $1 argument) as a base file for merging Kconfig fragments. However, an empty $INITFILE can serve as an initial starting point, later referenced by the KCONFIG_ALLCONFIG Makefile variable if -m is not used. This variable can point to any configuration file containing preset config symbols (the merged output) as stated in Documentation/kbuild/kconfig.rst. When -m is used $INITFILE will contain just the merge output requiring the user to run make (i.e. KCONFIG_ALLCONFIG=<$INITFILE> make <allnoconfig/alldefconfig> or make olddefconfig). Instead of failing when `$INITFILE` is missing, create an empty file and use it as the starting point for merges. Signed-off-by: Daniel Gomez <da.gomez(a)samsung.com> Signed-off-by: Masahiro Yamada <masahiroy(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- scripts/kconfig/merge_config.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/kconfig/merge_config.sh b/scripts/kconfig/merge_config.sh index d7d5c58b8b6aa..557f37f481fdf 100755 --- a/scripts/kconfig/merge_config.sh +++ b/scripts/kconfig/merge_config.sh @@ -98,8 +98,8 @@ INITFILE=$1 shift; if [ ! -r "$INITFILE" ]; then - echo "The base file '$INITFILE' does not exist. Exit." >&2 - exit 1 + echo "The base file '$INITFILE' does not exist. Creating one..." >&2 + touch "$INITFILE" fi MERGE_LIST=$* -- 2.39.5

7 months, 2 weeks

1
113
0 0

[PATCH v4] x86/sev: Fix making shared pages private during kdump

by Ashish Kalra

From: Ashish Kalra <ashish.kalra(a)amd.com> When the shared pages are being made private during kdump preparation there are additional checks to handle shared GHCB pages. These additional checks include handling the case of GHCB page being contained within a huge page. The check for handling the case of GHCB contained within a huge page incorrectly skips a page just below the GHCB page from being transitioned back to private during kdump preparation. This skipped page causes a 0x404 #VC exception when it is accessed later while dumping guest memory during vmcore generation via kdump. Correct the range to be checked for GHCB contained in a huge page. Also ensure that the skipped huge page containing the GHCB page is transitioned back to private by applying the correct address mask later when changing GHCBs to private at end of kdump preparation. Cc: stable(a)vger.kernel.org Fixes: 3074152e56c9 ("x86/sev: Convert shared memory back to private on kexec") Signed-off-by: Ashish Kalra <ashish.kalra(a)amd.com> --- arch/x86/coco/sev/core.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c index d35fec7b164a..97e5d475b9f5 100644 --- a/arch/x86/coco/sev/core.c +++ b/arch/x86/coco/sev/core.c @@ -1019,7 +1019,8 @@ static void unshare_all_memory(void) data = per_cpu(runtime_data, cpu); ghcb = (unsigned long)&data->ghcb_page; - if (addr <= ghcb && ghcb <= addr + size) { + /* Handle the case of a huge page containing the GHCB page */ + if (addr <= ghcb && ghcb < addr + size) { skipped_addr = true; break; } @@ -1131,9 +1132,8 @@ static void shutdown_all_aps(void) void snp_kexec_finish(void) { struct sev_es_runtime_data *data; + unsigned long size, mask, ghcb; unsigned int level, cpu; - unsigned long size; - struct ghcb *ghcb; pte_t *pte; if (!cc_platform_has(CC_ATTR_GUEST_SEV_SNP)) @@ -1157,11 +1157,14 @@ void snp_kexec_finish(void) for_each_possible_cpu(cpu) { data = per_cpu(runtime_data, cpu); - ghcb = &data->ghcb_page; - pte = lookup_address((unsigned long)ghcb, &level); + ghcb = (unsigned long)&data->ghcb_page; + pte = lookup_address(ghcb, &level); size = page_level_size(level); + mask = page_level_mask(level); + /* Handle the case of a huge page containing the GHCB page */ + ghcb &= mask; set_pte_enc(pte, level, (void *)ghcb); - snp_set_memory_private((unsigned long)ghcb, (size / PAGE_SIZE)); + snp_set_memory_private(ghcb, (size / PAGE_SIZE)); } } -- 2.34.1

7 months, 2 weeks

3
2
0 0

[PATCH v2 1/1] PCI: Fix lock symmetry in pci_slot_unlock()

by Ilpo Järvinen

The commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") made the lock function to call depend on dev->subordinate but left pci_slot_unlock() unmodified creating locking asymmetry compared with pci_slot_lock(). Because of the asymmetric lock handling, the same bridge device is unlocked twice. First pci_bus_unlock() unlocks bus->self and then pci_slot_unlock() will unconditionally unlock the same bridge device. Move pci_dev_unlock() inside an else branch to match the logic in pci_slot_lock(). Fixes: a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> --- v2: - Improve changelog (Lukas) - Added Cc stable drivers/pci/pci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 4d7c9f64ea24..26507aa906d7 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -5542,7 +5542,8 @@ static void pci_slot_unlock(struct pci_slot *slot) continue; if (dev->subordinate) pci_bus_unlock(dev->subordinate); - pci_dev_unlock(dev); + else + pci_dev_unlock(dev); } } base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8 -- 2.39.5

7 months, 2 weeks

3
2
0 0

[PATCH] parisc stable patch for kernel v6.12

by Helge Deller

Hi Greg, below is a backport for upstream patch fd87b7783802 ("net: Fix the devmem sock opts and msgs for parisc"). This upstream patch does not apply cleanly against v6.12, and backporting all intermediate changes are too big, so I created this trivial standalone patch instead. Can you please add the patc below to the stable queue for v6.12? Thanks! Helge --- From: Pranjal Shrivastava <praan(a)google.com> Date: Mon, 24 Mar 2025 07:42:27 +0000 Subject: [PATCH] net: Fix the devmem sock opts and msgs for parisc The devmem socket options and socket control message definitions introduced in the TCP devmem series[1] incorrectly continued the socket definitions for arch/parisc. The UAPI change seems safe as there are currently no drivers that declare support for devmem TCP RX via PP_FLAG_ALLOW_UNREADABLE_NETMEM. Hence, fixing this UAPI should be safe. Fix the devmem socket options and socket control message definitions to reflect the series followed by arch/parisc. [1] https://lore.kernel.org/lkml/20240910171458.219195-10-almasrymina@google.co… Patch modified for kernel 6.12 by Helge Deller. Fixes: 8f0b3cc9a4c10 ("tcp: RX path for devmem TCP") Signed-off-by: Pranjal Shrivastava <praan(a)google.com> Signed-off-by: Helge Deller <deller(a)gmx.de> diff --git b/arch/parisc/include/uapi/asm/socket.h a/arch/parisc/include/uapi/asm/socket.h index 38fc0b188e08..96831c988606 100644 --- b/arch/parisc/include/uapi/asm/socket.h +++ a/arch/parisc/include/uapi/asm/socket.h @@ -132,11 +132,15 @@ #define SO_PASSPIDFD 0x404A #define SO_PEERPIDFD 0x404B -#define SO_DEVMEM_LINEAR 78 +#define SCM_TS_OPT_ID 0x404C + +#define SO_RCVPRIORITY 0x404D + +#define SO_DEVMEM_LINEAR 0x404E #define SCM_DEVMEM_LINEAR SO_DEVMEM_LINEAR -#define SO_DEVMEM_DMABUF 79 +#define SO_DEVMEM_DMABUF 0x404F #define SCM_DEVMEM_DMABUF SO_DEVMEM_DMABUF -#define SO_DEVMEM_DONTNEED 80 +#define SO_DEVMEM_DONTNEED 0x4050 #if !defined(__KERNEL__)

7 months, 2 weeks

1
0
0 0

[PATCH v3 0/2] iio: accel: fxls8962af: Fix temperature readings

by Sean Nyekjaer

Add the correct scale to get temperature in mili degree Celcius. Add sign component to temperature scan element. Signed-off-by: Sean Nyekjaer <sean(a)geanix.com> --- Changes in v3: - Dropping define infavor of inline scale value - Added using constants from units.h - Tweaked commit msg to make it more assertive - Link to v2: https://lore.kernel.org/r/20250502-fxls-v2-0-e1af65f1aa6c@geanix.com Changes in v2: - Correct offset is applied before scaling component - Added sign component to temperature scan element - Link to v1: https://lore.kernel.org/r/20250501-fxls-v1-1-f54061a07099@geanix.com --- Sean Nyekjaer (2): iio: accel: fxls8962af: Fix temperature calculation iio: accel: fxls8962af: Fix temperature scan element sign drivers/iio/accel/fxls8962af-core.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) --- base-commit: 609bc31eca06c7408e6860d8b46311ebe45c1fef change-id: 20250501-fxls-307ef3d6d065 Best regards, -- Sean Nyekjaer <sean(a)geanix.com>

7 months, 2 weeks

2
4
0 0

[PATCH v2] video: screen_info: Relocate framebuffers behind PCI bridges

by Thomas Zimmermann

Apply bridge window offsets to screen_info framebuffers during relocation. Fixes invalid access to I/O memory. Resources behind a PCI bridge can be located at a certain offset in the kernel's I/O range. The framebuffer memory range stored in screen_info refers to the offset as seen during boot (essentialy 0). During boot up, the kernel may assign a different memory offset to the bridge device and thereby relocating the framebuffer address of the PCI graphics device as seen by the kernel. The information in screen_info must be updated as well. The helper pcibios_bus_to_resource() performs the relocation of the screen_info resource. The result now matches the I/O-memory resource of the PCI graphics device. As before, we store away the information necessary to update the information in screen_info. Commit 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated EFI framebuffers") added the code for updating screen_info. It is based on similar functionality that pre-existed in efifb. Efifb uses a pointer to the PCI resource, while the newer code does a memcpy of the region. Hence efifb sees any updates to the PCI resource and avoids the issue. v2: - Fixed tags (Takashi, Ivan) - Updated information on efifb Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Reported-by: "Ivan T. Ivanov" <iivanov(a)suse.de> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1240696 Tested-by: "Ivan T. Ivanov" <iivanov(a)suse.de> Fixes: 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated EFI framebuffers") Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v6.9+ --- drivers/video/screen_info_pci.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/video/screen_info_pci.c b/drivers/video/screen_info_pci.c index 6c5833517141..c46c75dc3fae 100644 --- a/drivers/video/screen_info_pci.c +++ b/drivers/video/screen_info_pci.c @@ -8,7 +8,7 @@ static struct pci_dev *screen_info_lfb_pdev; static size_t screen_info_lfb_bar; static resource_size_t screen_info_lfb_offset; -static struct resource screen_info_lfb_res = DEFINE_RES_MEM(0, 0); +static struct pci_bus_region screen_info_lfb_region; static bool __screen_info_relocation_is_valid(const struct screen_info *si, struct resource *pr) { @@ -31,7 +31,7 @@ void screen_info_apply_fixups(void) if (screen_info_lfb_pdev) { struct resource *pr = &screen_info_lfb_pdev->resource[screen_info_lfb_bar]; - if (pr->start != screen_info_lfb_res.start) { + if (pr->start != screen_info_lfb_region.start) { if (__screen_info_relocation_is_valid(si, pr)) { /* * Only update base if we have an actual @@ -69,10 +69,21 @@ static void screen_info_fixup_lfb(struct pci_dev *pdev) for (i = 0; i < numres; ++i) { struct resource *r = &res[i]; + struct pci_bus_region bus_region = { + .start = r->start, + .end = r->end, + }; const struct resource *pr; if (!(r->flags & IORESOURCE_MEM)) continue; + + /* + * Translate the address to resource if the framebuffer + * is behind a PCI bridge. + */ + pcibios_bus_to_resource(pdev->bus, r, &bus_region); + pr = pci_find_resource(pdev, r); if (!pr) continue; @@ -85,7 +96,7 @@ static void screen_info_fixup_lfb(struct pci_dev *pdev) screen_info_lfb_pdev = pdev; screen_info_lfb_bar = pr - pdev->resource; screen_info_lfb_offset = r->start - pr->start; - memcpy(&screen_info_lfb_res, r, sizeof(screen_info_lfb_res)); + memcpy(&screen_info_lfb_region, &bus_region, sizeof(screen_info_lfb_region)); } } DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY, 16, -- 2.49.0

7 months, 2 weeks

2
3
0 0

[PATCH 2/5] rust: clean Rust 1.87.0's `clippy::ptr_eq` lints

by Miguel Ojeda

Starting with Rust 1.87.0 (expected 2025-05-15) [1], Clippy may expand the `ptr_eq` lint, e.g.: error: use `core::ptr::eq` when comparing raw pointers --> rust/kernel/list.rs:438:12 | 438 | if self.first == item { | ^^^^^^^^^^^^^^^^^^ help: try: `core::ptr::eq(self.first, item)` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_eq = note: `-D clippy::ptr-eq` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::ptr_eq)]` Thus clean the few cases we have. This patch may not be actually needed by the time Rust 1.87.0 releases since a PR to relax the lint has been beta nominated [2] due to reports of being too eager (at least by default) [3]. Cc: stable(a)vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust-clippy/pull/14339 [1] Link: https://github.com/rust-lang/rust-clippy/pull/14526 [2] Link: https://github.com/rust-lang/rust-clippy/issues/14525 [3] Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org> --- rust/kernel/alloc/kvec.rs | 2 +- rust/kernel/list.rs | 12 ++++++------ 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/rust/kernel/alloc/kvec.rs b/rust/kernel/alloc/kvec.rs index ae9d072741ce..cde911551327 100644 --- a/rust/kernel/alloc/kvec.rs +++ b/rust/kernel/alloc/kvec.rs @@ -743,7 +743,7 @@ fn into_raw_parts(self) -> (*mut T, NonNull<T>, usize, usize) { pub fn collect(self, flags: Flags) -> Vec<T, A> { let old_layout = self.layout; let (mut ptr, buf, len, mut cap) = self.into_raw_parts(); - let has_advanced = ptr != buf.as_ptr(); + let has_advanced = !core::ptr::eq(ptr, buf.as_ptr()); if has_advanced { // Copy the contents we have advanced to at the beginning of the buffer. diff --git a/rust/kernel/list.rs b/rust/kernel/list.rs index a335c3b1ff5e..c63cbeee3316 100644 --- a/rust/kernel/list.rs +++ b/rust/kernel/list.rs @@ -435,7 +435,7 @@ unsafe fn remove_internal_inner( // * If `item` was the only item in the list, then `prev == item`, and we just set // `item->next` to null, so this correctly sets `first` to null now that the list is // empty. - if self.first == item { + if core::ptr::eq(self.first, item) { // SAFETY: The `prev` pointer is the value that `item->prev` had when it was in this // list, so it must be valid. There is no race since `prev` is still in the list and we // still have exclusive access to the list. @@ -556,7 +556,7 @@ fn next(&mut self) -> Option<ArcBorrow<'a, T>> { let next = unsafe { (*current).next }; // INVARIANT: If `current` was the last element of the list, then this updates it to null. // Otherwise, we update it to the next element. - self.current = if next != self.stop { + self.current = if !core::ptr::eq(next, self.stop) { next } else { ptr::null_mut() @@ -726,7 +726,7 @@ impl<'a, T: ?Sized + ListItem<ID>, const ID: u64> Cursor<'a, T, ID> { fn prev_ptr(&self) -> *mut ListLinksFields { let mut next = self.next; let first = self.list.first; - if next == first { + if core::ptr::eq(next, first) { // We are before the first element. return core::ptr::null_mut(); } @@ -788,7 +788,7 @@ pub fn move_next(&mut self) -> bool { // access the `next` field. let mut next = unsafe { (*self.next).next }; - if next == self.list.first { + if core::ptr::eq(next, self.list.first) { next = core::ptr::null_mut(); } @@ -802,7 +802,7 @@ pub fn move_next(&mut self) -> bool { /// If the cursor is before the first element, then this call does nothing. This call returns /// `true` if the cursor's position was changed. pub fn move_prev(&mut self) -> bool { - if self.next == self.list.first { + if core::ptr::eq(self.next, self.list.first) { return false; } @@ -822,7 +822,7 @@ fn insert_inner(&mut self, item: ListArc<T, ID>) -> *mut ListLinksFields { // * `ptr` is an element in the list or null. // * if `ptr` is null, then `self.list.first` is null so the list is empty. let item = unsafe { self.list.insert_inner(item, ptr) }; - if self.next == self.list.first { + if core::ptr::eq(self.next, self.list.first) { // INVARIANT: We just inserted `item`, so it's a member of list. self.list.first = item; } -- 2.49.0

7 months, 2 weeks

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2025