- Linux-stable-mirror - lists.linaro.org

[PATCH 1/2] mm/vma: fix gap check for unmapped_area with VM_GROWSDOWN

by Wei Yang

Current unmapped_area() may fail to get the available area. For example, we have a vma range like below: 0123456789abcdef m m A m m Let's assume start_gap is 0x2000 and stack_guard_gap is 0x1000. And now we are looking for free area with size 0x1000 within [0x2000, 0xd000]. The unmapped_area_topdown() could find address at 0x8000, while unmapped_area() fails. In original code before commit 3499a13168da ("mm/mmap: use maple tree for unmapped_area{_topdown}"), the logic is: * find a gap with total length, including alignment * adjust start address with alignment What we do now is: * find a gap with total length, including alignment * adjust start address with alignment * then compare the left range with total length This is not necessary to compare with total length again after start address adjusted. Also, it is not correct to minus 1 here. This may not trigger an issue in real world, since address are usually aligned with page size. Fixes: 58c5d0d6d522 ("mm/mmap: regression fix for unmapped_area{_topdown}") Signed-off-by: Wei Yang <richard.weiyang(a)gmail.com> CC: Liam R. Howlett <Liam.Howlett(a)Oracle.com> CC: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> CC: Vlastimil Babka <vbabka(a)suse.cz> CC: Jann Horn <jannh(a)google.com> CC: Rick Edgecombe <rick.p.edgecombe(a)intel.com> Cc: <stable(a)vger.kernel.org> --- mm/vma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/vma.c b/mm/vma.c index 3f45a245e31b..d82fdbc710b0 100644 --- a/mm/vma.c +++ b/mm/vma.c @@ -2668,7 +2668,7 @@ unsigned long unmapped_area(struct vm_unmapped_area_info *info) gap += (info->align_offset - gap) & info->align_mask; tmp = vma_next(&vmi); if (tmp && (tmp->vm_flags & VM_STARTGAP_FLAGS)) { /* Avoid prev check if possible */ - if (vm_start_gap(tmp) < gap + length - 1) { + if (vm_start_gap(tmp) < gap + info->length) { low_limit = tmp->vm_end; vma_iter_reset(&vmi); goto retry; -- 2.34.1

1 month

2
3
0 0

[PATCH] drivers/hv: select PCI_HYPERV if PCI is enabled

by Hamza Mahfooz

We should select PCI_HYPERV here, otherwise it's possible for devices to not show up as expected, at least not in an orderly manner. Cc: stable(a)vger.kernel.org Cc: Wei Liu <wei.liu(a)kernel.org> Signed-off-by: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> --- drivers/hv/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig index 862c47b191af..6ee75b3f0fa6 100644 --- a/drivers/hv/Kconfig +++ b/drivers/hv/Kconfig @@ -9,6 +9,7 @@ config HYPERV select PARAVIRT select X86_HV_CALLBACK_VECTOR if X86 select OF_EARLY_FLATTREE if OF + select PCI_HYPERV if PCI help Select this option to run Linux as a Hyper-V client operating system. -- 2.47.1

1 month

3
5
0 0

[PATCH] hwmon: (peci/dimmtemp) Do not provide fake thresholds data

by Paul Fertser

When an Icelake or Sapphire Rapids CPU isn't providing the maximum and critical thresholds for particular DIMM the driver should return an error to the userspace instead of giving it stale (best case) or wrong (the structure contains all zeros after kzalloc() call) data. The issue can be reproduced by binding the peci driver while the host is fully booted and idle, this makes PECI interaction unreliable enough. Fixes: 73bc1b885dae ("hwmon: peci: Add dimmtemp driver") Fixes: 621995b6d795 ("hwmon: (peci/dimmtemp) Add Sapphire Rapids support") Cc: stable(a)vger.kernel.org Signed-off-by: Paul Fertser <fercerpav(a)gmail.com> --- drivers/hwmon/peci/dimmtemp.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/hwmon/peci/dimmtemp.c b/drivers/hwmon/peci/dimmtemp.c index d6762259dd69..fbe82d9852e0 100644 --- a/drivers/hwmon/peci/dimmtemp.c +++ b/drivers/hwmon/peci/dimmtemp.c @@ -127,8 +127,6 @@ static int update_thresholds(struct peci_dimmtemp *priv, int dimm_no) return 0; ret = priv->gen_info->read_thresholds(priv, dimm_order, chan_rank, &data); - if (ret == -ENODATA) /* Use default or previous value */ - return 0; if (ret) return ret; @@ -509,11 +507,11 @@ read_thresholds_icx(struct peci_dimmtemp *priv, int dimm_order, int chan_rank, u ret = peci_ep_pci_local_read(priv->peci_dev, 0, 13, 0, 2, 0xd4, &reg_val); if (ret || !(reg_val & BIT(31))) - return -ENODATA; /* Use default or previous value */ + return -ENODATA; ret = peci_ep_pci_local_read(priv->peci_dev, 0, 13, 0, 2, 0xd0, &reg_val); if (ret) - return -ENODATA; /* Use default or previous value */ + return -ENODATA; /* * Device 26, Offset 224e0: IMC 0 channel 0 -> rank 0 @@ -546,11 +544,11 @@ read_thresholds_spr(struct peci_dimmtemp *priv, int dimm_order, int chan_rank, u ret = peci_ep_pci_local_read(priv->peci_dev, 0, 30, 0, 2, 0xd4, &reg_val); if (ret || !(reg_val & BIT(31))) - return -ENODATA; /* Use default or previous value */ + return -ENODATA; ret = peci_ep_pci_local_read(priv->peci_dev, 0, 30, 0, 2, 0xd0, &reg_val); if (ret) - return -ENODATA; /* Use default or previous value */ + return -ENODATA; /* * Device 26, Offset 219a8: IMC 0 channel 0 -> rank 0 -- 2.34.1

1 month

3
7
0 0

[PATCH 02/20] perf/x86/intel: Fix ARCH_PERFMON_NUM_COUNTER_LEAF

by Dapeng Mi

From: Kan Liang <kan.liang(a)linux.intel.com> The EAX of the CPUID Leaf 023H enumerates the mask of valid sub-leaves. To tell the availability of the sub-leaf 1 (enumerate the counter mask), perf should check the bit 1 (0x2) of EAS, rather than bit 0 (0x1). The error is not user-visible on bare metal. Because the sub-leaf 0 and the sub-leaf 1 are always available. However, it may bring issues in a virtualization environment when a VMM only enumerates the sub-leaf 0. Fixes: eb467aaac21e ("perf/x86/intel: Support Architectural PerfMon Extension leaf") Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- arch/x86/events/intel/core.c | 4 ++-- arch/x86/include/asm/perf_event.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index 5e8521a54474..12eb96219740 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -4966,8 +4966,8 @@ static void update_pmu_cap(struct x86_hybrid_pmu *pmu) if (ebx & ARCH_PERFMON_EXT_EQ) pmu->config_mask |= ARCH_PERFMON_EVENTSEL_EQ; - if (sub_bitmaps & ARCH_PERFMON_NUM_COUNTER_LEAF_BIT) { - cpuid_count(ARCH_PERFMON_EXT_LEAF, ARCH_PERFMON_NUM_COUNTER_LEAF, + if (sub_bitmaps & ARCH_PERFMON_NUM_COUNTER_LEAF) { + cpuid_count(ARCH_PERFMON_EXT_LEAF, ARCH_PERFMON_NUM_COUNTER_LEAF_BIT, &eax, &ebx, &ecx, &edx); pmu->cntr_mask64 = eax; pmu->fixed_cntr_mask64 = ebx; diff --git a/arch/x86/include/asm/perf_event.h b/arch/x86/include/asm/perf_event.h index adaeb8ca3a8a..71e2ae021374 100644 --- a/arch/x86/include/asm/perf_event.h +++ b/arch/x86/include/asm/perf_event.h @@ -197,7 +197,7 @@ union cpuid10_edx { #define ARCH_PERFMON_EXT_UMASK2 0x1 #define ARCH_PERFMON_EXT_EQ 0x2 #define ARCH_PERFMON_NUM_COUNTER_LEAF_BIT 0x1 -#define ARCH_PERFMON_NUM_COUNTER_LEAF 0x1 +#define ARCH_PERFMON_NUM_COUNTER_LEAF BIT(ARCH_PERFMON_NUM_COUNTER_LEAF_BIT) /* * Intel Architectural LBR CPUID detection/enumeration details: -- 2.40.1

1 month

3
4
0 0

[PATCH net 0/3] mptcp: fixes addressing syzbot reports

by Matthieu Baerts (NGI0)

Recently, a few issues linked to MPTCP have been reported by syzbot. All the remaining ones are addressed in this series. - Patch 1: Address "KMSAN: uninit-value in mptcp_incoming_options (2)". A fix for v5.11. - Patch 2: Address "WARNING in mptcp_pm_nl_set_flags (2)". A fix for v5.18. - Patch 3: Address "WARNING in __mptcp_clean_una (2)". A fix for v6.4, backported up to v6.1. Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- Matthieu Baerts (NGI0) (1): mptcp: pm: only set fullmesh for subflow endp Paolo Abeni (2): mptcp: consolidate suboption status mptcp: handle fastopen disconnect correctly net/mptcp/options.c | 13 +++++-------- net/mptcp/pm_netlink.c | 3 ++- net/mptcp/protocol.c | 4 +++- net/mptcp/protocol.h | 30 ++++++++++++++++-------------- 4 files changed, 26 insertions(+), 24 deletions(-) --- base-commit: 15a901361ec3fb1c393f91880e1cbf24ec0a88bd change-id: 20250123-net-mptcp-syzbot-issues-ffdbbb9b85d7 Best regards, -- Matthieu Baerts (NGI0) <matttbe(a)kernel.org>

1 month

2
4
0 0

+ kfence-skip-__gfp_thisnode-allocations-on-numa-systems.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: kfence: skip __GFP_THISNODE allocations on NUMA systems has been added to the -mm mm-hotfixes-unstable branch. Its filename is kfence-skip-__gfp_thisnode-allocations-on-numa-systems.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: Marco Elver <elver(a)google.com> Subject: kfence: skip __GFP_THISNODE allocations on NUMA systems Date: Fri, 24 Jan 2025 13:01:38 +0100 On NUMA systems, __GFP_THISNODE indicates that an allocation _must_ be on a particular node, and failure to allocate on the desired node will result in a failed allocation. Skip __GFP_THISNODE allocations if we are running on a NUMA system, since KFENCE can't guarantee which node its pool pages are allocated on. Link: https://lkml.kernel.org/r/20250124120145.410066-1-elver@google.com Fixes: 236e9f153852 ("kfence: skip all GFP_ZONEMASK allocations") Signed-off-by: Marco Elver <elver(a)google.com> Reported-by: Vlastimil Babka <vbabka(a)suse.cz> Acked-by: Vlastimil Babka <vbabka(a)suse.cz> Cc: Christoph Lameter <cl(a)linux.com> Cc: Alexander Potapenko <glider(a)google.com> Cc: Chistoph Lameter <cl(a)linux.com> Cc: Dmitriy Vyukov <dvyukov(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/kfence/core.c | 2 ++ 1 file changed, 2 insertions(+) --- a/mm/kfence/core.c~kfence-skip-__gfp_thisnode-allocations-on-numa-systems +++ a/mm/kfence/core.c @@ -21,6 +21,7 @@ #include <linux/log2.h> #include <linux/memblock.h> #include <linux/moduleparam.h> +#include <linux/nodemask.h> #include <linux/notifier.h> #include <linux/panic_notifier.h> #include <linux/random.h> @@ -1084,6 +1085,7 @@ void *__kfence_alloc(struct kmem_cache * * properties (e.g. reside in DMAable memory). */ if ((flags & GFP_ZONEMASK) || + ((flags & __GFP_THISNODE) && num_online_nodes() > 1) || (s->flags & (SLAB_CACHE_DMA | SLAB_CACHE_DMA32))) { atomic_long_inc(&counters[KFENCE_COUNTER_SKIP_INCOMPAT]); return NULL; _ Patches currently in -mm which might be from elver(a)google.com are kfence-skip-__gfp_thisnode-allocations-on-numa-systems.patch

1 month

1
0
0 0

+ nilfs2-fix-possible-int-overflows-in-nilfs_fiemap.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: nilfs2: fix possible int overflows in nilfs_fiemap() has been added to the -mm mm-hotfixes-unstable branch. Its filename is nilfs2-fix-possible-int-overflows-in-nilfs_fiemap.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: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Subject: nilfs2: fix possible int overflows in nilfs_fiemap() Date: Sat, 25 Jan 2025 07:20:53 +0900 Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result by being prepared to go through potentially maxblocks == INT_MAX blocks, the value in n may experience an overflow caused by left shift of blkbits. While it is extremely unlikely to occur, play it safe and cast right hand expression to wider type to mitigate the issue. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Link: https://lkml.kernel.org/r/20250124222133.5323-1-konishi.ryusuke@gmail.com Fixes: 622daaff0a89 ("nilfs2: fiemap support") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/nilfs2/inode.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/fs/nilfs2/inode.c~nilfs2-fix-possible-int-overflows-in-nilfs_fiemap +++ a/fs/nilfs2/inode.c @@ -1186,7 +1186,7 @@ int nilfs_fiemap(struct inode *inode, st if (size) { if (phys && blkphy << blkbits == phys + size) { /* The current extent goes on */ - size += n << blkbits; + size += (u64)n << blkbits; } else { /* Terminate the current extent */ ret = fiemap_fill_next_extent( @@ -1199,14 +1199,14 @@ int nilfs_fiemap(struct inode *inode, st flags = FIEMAP_EXTENT_MERGED; logical = blkoff << blkbits; phys = blkphy << blkbits; - size = n << blkbits; + size = (u64)n << blkbits; } } else { /* Start a new extent */ flags = FIEMAP_EXTENT_MERGED; logical = blkoff << blkbits; phys = blkphy << blkbits; - size = n << blkbits; + size = (u64)n << blkbits; } blkoff += n; } _ Patches currently in -mm which might be from n.zhandarovich(a)fintech.ru are nilfs2-fix-possible-int-overflows-in-nilfs_fiemap.patch

1 month

1
0
0 0

[PATCH RESEND net] ptp: Ensure info->enable callback is always set

by Thomas Weißschuh

The ioctl and sysfs handlers unconditionally call the ->enable callback. Not all drivers implement that callback, leading to NULL dereferences. Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c. Instead use a dummy callback if no better was specified by the driver. Fixes: d94ba80ebbea ("ptp: Added a brand new class driver for ptp clocks.") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> --- drivers/ptp/ptp_clock.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c index b932425ddc6a3789504164a69d1b8eba47da462c..35a5994bf64f6373c08269d63aaeac3f4ab31ff0 100644 --- a/drivers/ptp/ptp_clock.c +++ b/drivers/ptp/ptp_clock.c @@ -217,6 +217,11 @@ static int ptp_getcycles64(struct ptp_clock_info *info, struct timespec64 *ts) return info->gettime64(info, ts); } +static int ptp_enable(struct ptp_clock_info *ptp, struct ptp_clock_request *request, int on) +{ + return -EOPNOTSUPP; +} + static void ptp_aux_kworker(struct kthread_work *work) { struct ptp_clock *ptp = container_of(work, struct ptp_clock, @@ -294,6 +299,9 @@ struct ptp_clock *ptp_clock_register(struct ptp_clock_info *info, ptp->info->getcrosscycles = ptp->info->getcrosststamp; } + if (!ptp->info->enable) + ptp->info->enable = ptp_enable; + if (ptp->info->do_aux_work) { kthread_init_delayed_work(&ptp->aux_work, ptp_aux_kworker); ptp->kworker = kthread_run_worker(0, "ptp%d", ptp->index); --- base-commit: c4b9570cfb63501638db720f3bee9f6dfd044b82 change-id: 20250122-ptp-enable-831339c62428 Best regards, -- Thomas Weißschuh <linux(a)weissschuh.net>

1 month

4
4
0 0

[PATCH v2] drm/i915: Fix page cleanup on DMA remap failure

by Brian Geffon

When converting to folios the cleanup path of shmem_get_pages() was missed. When a DMA remap fails and the max segment size is greater than PAGE_SIZE it will attempt to retry the remap with a PAGE_SIZEd segment size. The cleanup code isn't properly using the folio apis and as a result isn't handling compound pages correctly. v1 -> v2: (Ville) Fixed locations where we were not clearing mapping unevictable. Cc: stable(a)vger.kernel.org Cc: Ville Syrjala <ville.syrjala(a)linux.intel.com> Cc: Vidya Srinivas <vidya.srinivas(a)intel.com> Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13487 Link: https://lore.kernel.org/lkml/20250116135636.410164-1-bgeffon@google.com/ Fixes: 0b62af28f249 ("i915: convert shmem_sg_free_table() to use a folio_batch") Signed-off-by: Brian Geffon <bgeffon(a)google.com> Suggested-by: Tomasz Figa <tfiga(a)google.com> --- drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 +-- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 23 +++++++++------------- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 7 ++++--- 3 files changed, 14 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h b/drivers/gpu/drm/i915/gem/i915_gem_object.h index 3dc61cbd2e11..0f122a12d4a5 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h @@ -843,8 +843,7 @@ int shmem_sg_alloc_table(struct drm_i915_private *i915, struct sg_table *st, size_t size, struct intel_memory_region *mr, struct address_space *mapping, unsigned int max_segment); -void shmem_sg_free_table(struct sg_table *st, struct address_space *mapping, - bool dirty, bool backup); +void shmem_sg_free_table(struct sg_table *st, bool dirty, bool backup); void __shmem_writeback(size_t size, struct address_space *mapping); #ifdef CONFIG_MMU_NOTIFIER diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c index fe69f2c8527d..b320d9dfd6d3 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c @@ -29,16 +29,13 @@ static void check_release_folio_batch(struct folio_batch *fbatch) cond_resched(); } -void shmem_sg_free_table(struct sg_table *st, struct address_space *mapping, - bool dirty, bool backup) +void shmem_sg_free_table(struct sg_table *st, bool dirty, bool backup) { struct sgt_iter sgt_iter; struct folio_batch fbatch; struct folio *last = NULL; struct page *page; - mapping_clear_unevictable(mapping); - folio_batch_init(&fbatch); for_each_sgt_page(page, sgt_iter, st) { struct folio *folio = page_folio(page); @@ -180,10 +177,10 @@ int shmem_sg_alloc_table(struct drm_i915_private *i915, struct sg_table *st, return 0; err_sg: sg_mark_end(sg); + mapping_clear_unevictable(mapping); if (sg != st->sgl) { - shmem_sg_free_table(st, mapping, false, false); + shmem_sg_free_table(st, false, false); } else { - mapping_clear_unevictable(mapping); sg_free_table(st); } @@ -209,8 +206,6 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj) struct address_space *mapping = obj->base.filp->f_mapping; unsigned int max_segment = i915_sg_segment_size(i915->drm.dev); struct sg_table *st; - struct sgt_iter sgt_iter; - struct page *page; int ret; /* @@ -239,9 +234,8 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj) * for PAGE_SIZE chunks instead may be helpful. */ if (max_segment > PAGE_SIZE) { - for_each_sgt_page(page, sgt_iter, st) - put_page(page); - sg_free_table(st); + /* Leave the mapping unevictable while we retry */ + shmem_sg_free_table(st, false, false); kfree(st); max_segment = PAGE_SIZE; @@ -265,7 +259,8 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj) return 0; err_pages: - shmem_sg_free_table(st, mapping, false, false); + mapping_clear_unevictable(mapping); + shmem_sg_free_table(st, false, false); /* * shmemfs first checks if there is enough memory to allocate the page * and reports ENOSPC should there be insufficient, along with the usual @@ -402,8 +397,8 @@ void i915_gem_object_put_pages_shmem(struct drm_i915_gem_object *obj, struct sg_ if (i915_gem_object_needs_bit17_swizzle(obj)) i915_gem_object_save_bit_17_swizzle(obj, pages); - shmem_sg_free_table(pages, file_inode(obj->base.filp)->i_mapping, - obj->mm.dirty, obj->mm.madv == I915_MADV_WILLNEED); + mapping_clear_unevictable(file_inode(obj->base.filp)->i_mapping); + shmem_sg_free_table(pages, obj->mm.dirty, obj->mm.madv == I915_MADV_WILLNEED); kfree(pages); obj->mm.dirty = false; } diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c index 10d8673641f7..37f51a04b838 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c @@ -232,7 +232,8 @@ static int i915_ttm_tt_shmem_populate(struct ttm_device *bdev, return 0; err_free_st: - shmem_sg_free_table(st, filp->f_mapping, false, false); + mapping_clear_unevictable(filp->f_mapping); + shmem_sg_free_table(st, false, false); return err; } @@ -243,8 +244,8 @@ static void i915_ttm_tt_shmem_unpopulate(struct ttm_tt *ttm) bool backup = ttm->page_flags & TTM_TT_FLAG_SWAPPED; struct sg_table *st = &i915_tt->cached_rsgt.table; - shmem_sg_free_table(st, file_inode(i915_tt->filp)->i_mapping, - backup, backup); + mapping_clear_unevictable(file_inode(i915_tt->filp)->i_mapping); + shmem_sg_free_table(st, backup, backup); } static void i915_ttm_tt_release(struct kref *ref) -- 2.48.0.rc2.279.g1de40edade-goog

1 month

3
5
0 0

[PATCH 1/2] drm/xe/devcoredump: Move exec queue snapshot to Contexts section

by Lucas De Marchi

Having the exec queue snapshot inside a "GuC CT" section was always wrong. Commit c28fd6c358db ("drm/xe/devcoredump: Improve section headings and add tile info") tried to fix that bug, but with that also broke the mesa tool that parses the devcoredump, hence it was reverted in commit 70fb86a85dc9 ("drm/xe: Revert some changes that break a mesa debug tool"). With the mesa tool also fixed, this can propagate as a fix on both kernel and userspace side to avoid unnecessary headache for a debug feature. Cc: John Harrison <John.C.Harrison(a)Intel.com> Cc: Julia Filipchuk <julia.filipchuk(a)intel.com> Cc: José Roberto de Souza <jose.souza(a)intel.com> Cc: stable(a)vger.kernel.org Fixes: 70fb86a85dc9 ("drm/xe: Revert some changes that break a mesa debug tool") Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com> --- drivers/gpu/drm/xe/xe_devcoredump.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c index 81dc7795c0651..a7946a76777e7 100644 --- a/drivers/gpu/drm/xe/xe_devcoredump.c +++ b/drivers/gpu/drm/xe/xe_devcoredump.c @@ -119,11 +119,7 @@ static ssize_t __xe_devcoredump_read(char *buffer, size_t count, drm_puts(&p, "\n**** GuC CT ****\n"); xe_guc_ct_snapshot_print(ss->guc.ct, &p); - /* - * Don't add a new section header here because the mesa debug decoder - * tool expects the context information to be in the 'GuC CT' section. - */ - /* drm_puts(&p, "\n**** Contexts ****\n"); */ + drm_puts(&p, "\n**** Contexts ****\n"); xe_guc_exec_queue_snapshot_print(ss->ge, &p); drm_puts(&p, "\n**** Job ****\n"); -- 2.48.0

1 month

2
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror