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

[PATCH v2] i2c: ls2x: Fix frequency division register access

by Binbin Zhou

According to the chip manual, the I2C register access type of Loongson-2K2000/LS7A is "B", so we can only access registers in byte form (readb/writeb). Although Loongson-2K0500/Loongson-2K1000 do not have similar constraints, register accesses in byte form also behave correctly. Also, in hardware, the frequency division registers are defined as two separate registers (high 8-bit and low 8-bit), so we just access them directly as bytes. Cc: stable(a)vger.kernel.org Fixes: 015e61f0bffd ("i2c: ls2x: Add driver for Loongson-2K/LS7A I2C controller") Co-developed-by: Hongliang Wang <wanghongliang(a)loongson.cn> Signed-off-by: Hongliang Wang <wanghongliang(a)loongson.cn> Signed-off-by: Binbin Zhou <zhoubinbin(a)loongson.cn> --- V2: - Add a comment to prevent from changing that back to 16-bit write. Link to V1: https://lore.kernel.org/all/20250218111133.3058590-1-zhoubinbin@loongson.cn/ drivers/i2c/busses/i2c-ls2x.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/busses/i2c-ls2x.c b/drivers/i2c/busses/i2c-ls2x.c index 8821cac3897b..61377693a4d6 100644 --- a/drivers/i2c/busses/i2c-ls2x.c +++ b/drivers/i2c/busses/i2c-ls2x.c @@ -10,6 +10,7 @@ * Rewritten for mainline by Binbin Zhou <zhoubinbin(a)loongson.cn> */ +#include <linux/bitfield.h> #include <linux/bits.h> #include <linux/completion.h> #include <linux/device.h> @@ -26,7 +27,8 @@ #include <linux/units.h> /* I2C Registers */ -#define I2C_LS2X_PRER 0x0 /* Freq Division Register(16 bits) */ +#define I2C_LS2X_PRER_LO 0x0 /* Freq Division Low Byte Register */ +#define I2C_LS2X_PRER_HI 0x1 /* Freq Division High Byte Register */ #define I2C_LS2X_CTR 0x2 /* Control Register */ #define I2C_LS2X_TXR 0x3 /* Transport Data Register */ #define I2C_LS2X_RXR 0x3 /* Receive Data Register */ @@ -93,6 +95,7 @@ static irqreturn_t ls2x_i2c_isr(int this_irq, void *dev_id) */ static void ls2x_i2c_adjust_bus_speed(struct ls2x_i2c_priv *priv) { + u16 val; struct i2c_timings *t = &priv->i2c_t; struct device *dev = priv->adapter.dev.parent; u32 acpi_speed = i2c_acpi_find_bus_speed(dev); @@ -104,9 +107,14 @@ static void ls2x_i2c_adjust_bus_speed(struct ls2x_i2c_priv *priv) else t->bus_freq_hz = LS2X_I2C_FREQ_STD; - /* Calculate and set i2c frequency. */ - writew(LS2X_I2C_PCLK_FREQ / (5 * t->bus_freq_hz) - 1, - priv->base + I2C_LS2X_PRER); + /* + * According to the chip manual, we can only access the registers as bytes, + * otherwise the high bits will be truncated. + * So set the I2C frequency with a sequential writeb instead of writew. + */ + val = LS2X_I2C_PCLK_FREQ / (5 * t->bus_freq_hz) - 1; + writeb(FIELD_GET(GENMASK(7, 0), val), priv->base + I2C_LS2X_PRER_LO); + writeb(FIELD_GET(GENMASK(15, 8), val), priv->base + I2C_LS2X_PRER_HI); } static void ls2x_i2c_init(struct ls2x_i2c_priv *priv) base-commit: 7e45b505e699f4c80aa8bf79b4ea2a5f5a66bb51 -- 2.47.1

3 days, 19 hours

2
1
0 0

[PATCH 0/2] HID: intel-ish-hid: Fix use-after-free issues in driver removal process

by Zhang Lixu

These patches address use-after-free issues in the `intel_ishtp_hid` driver during the removal process. Zhang Lixu (2): HID: intel-ish-hid: Fix use-after-free issue in hid_ishtp_cl_remove() HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove() drivers/hid/intel-ish-hid/ishtp-hid-client.c | 2 +- drivers/hid/intel-ish-hid/ishtp-hid.c | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) base-commit: 0ae0fa3bf0b44c8611d114a9f69985bf451010c3 -- 2.43.0

3 days, 19 hours

2
3
0 0

[PATCH v8] arm64: mm: Populate vmemmap at the page level if not section aligned

by Zhenhua Huang

On the arm64 platform with 4K base page config, SECTION_SIZE_BITS is set to 27, making one section 128M. The related page struct which vmemmap points to is 2M then. Commit c1cc1552616d ("arm64: MMU initialisation") optimizes the vmemmap to populate at the PMD section level which was suitable initially since hot plug granule is always one section(128M). However, commit ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug") introduced a 2M(SUBSECTION_SIZE) hot plug granule, which disrupted the existing arm64 assumptions. The first problem is that if start or end is not aligned to a section boundary, such as when a subsection is hot added, populating the entire section is wasteful. The next problem is if we hotplug something that spans part of 128 MiB section (subsections, let's call it memblock1), and then hotplug something that spans another part of a 128 MiB section(subsections, let's call it memblock2), and subsequently unplug memblock1, vmemmap_free() will clear the entire PMD entry which also supports memblock2 even though memblock2 is still active. Assuming hotplug/unplug sizes are guaranteed to be symmetric. Do the fix similar to x86-64: populate to pages levels if start/end is not aligned with section boundary. Cc: <stable(a)vger.kernel.org> # v5.4+ Fixes: ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug") Signed-off-by: Zhenhua Huang <quic_zhenhuah(a)quicinc.com> --- Hi Catalin and David, Following our latest discussion, I've updated the patch for your review. I also removed Catalin's review tag since I've made significant modifications. arch/arm64/mm/mmu.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index b4df5bc5b1b8..de05ccf47f21 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -1177,8 +1177,11 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, struct vmem_altmap *altmap) { WARN_ON((start < VMEMMAP_START) || (end > VMEMMAP_END)); + /* [start, end] should be within one section */ + WARN_ON(end - start > PAGES_PER_SECTION * sizeof(struct page)); - if (!IS_ENABLED(CONFIG_ARM64_4K_PAGES)) + if (!IS_ENABLED(CONFIG_ARM64_4K_PAGES) || + (end - start < PAGES_PER_SECTION * sizeof(struct page))) return vmemmap_populate_basepages(start, end, node, altmap); else return vmemmap_populate_hugepages(start, end, node, altmap); -- 2.25.1

3 days, 20 hours

1
0
0 0

[PATCH V4] mm/hugetlb: wait for hugetlb folios to be freed

by yangge1116＠126.com

From: Ge Yang <yangge1116(a)126.com> Since the introduction of commit c77c0a8ac4c52 ("mm/hugetlb: defer freeing of huge pages if in non-task context"), which supports deferring the freeing of hugetlb pages, the allocation of contiguous memory through cma_alloc() may fail probabilistically. In the CMA allocation process, if it is found that the CMA area is occupied by in-use hugetlb folios, these in-use hugetlb folios need to be migrated to another location. When there are no available hugetlb folios in the free hugetlb pool during the migration of in-use hugetlb folios, new folios are allocated from the buddy system. A temporary state is set on the newly allocated folio. Upon completion of the hugetlb folio migration, the temporary state is transferred from the new folios to the old folios. Normally, when the old folios with the temporary state are freed, it is directly released back to the buddy system. However, due to the deferred freeing of hugetlb pages, the PageBuddy() check fails, ultimately leading to the failure of cma_alloc(). Here is a simplified call trace illustrating the process: cma_alloc() ->__alloc_contig_migrate_range() // Migrate in-use hugetlb folios ->unmap_and_move_huge_page() ->folio_putback_hugetlb() // Free old folios ->test_pages_isolated() ->__test_page_isolated_in_pageblock() ->PageBuddy(page) // Check if the page is in buddy To resolve this issue, we have implemented a function named wait_for_freed_hugetlb_folios(). This function ensures that the hugetlb folios are properly released back to the buddy system after their migration is completed. By invoking wait_for_freed_hugetlb_folios() before calling PageBuddy(), we ensure that PageBuddy() will succeed. Fixes: c77c0a8ac4c52 ("mm/hugetlb: defer freeing of huge pages if in non-task context") Signed-off-by: Ge Yang <yangge1116(a)126.com> Cc: <stable(a)vger.kernel.org> --- V4: - add a check to determine if hpage_freelist is empty suggested by David V3: - adjust code and message suggested by Muchun and David V2: - flush all folios at once suggested by David include/linux/hugetlb.h | 5 +++++ mm/hugetlb.c | 8 ++++++++ mm/page_isolation.c | 10 ++++++++++ 3 files changed, 23 insertions(+) diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 6c6546b..0c54b3a 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -697,6 +697,7 @@ bool hugetlb_bootmem_page_zones_valid(int nid, struct huge_bootmem_page *m); int isolate_or_dissolve_huge_page(struct page *page, struct list_head *list); int replace_free_hugepage_folios(unsigned long start_pfn, unsigned long end_pfn); +void wait_for_freed_hugetlb_folios(void); struct folio *alloc_hugetlb_folio(struct vm_area_struct *vma, unsigned long addr, bool cow_from_owner); struct folio *alloc_hugetlb_folio_nodemask(struct hstate *h, int preferred_nid, @@ -1092,6 +1093,10 @@ static inline int replace_free_hugepage_folios(unsigned long start_pfn, return 0; } +static inline void wait_for_freed_hugetlb_folios(void) +{ +} + static inline struct folio *alloc_hugetlb_folio(struct vm_area_struct *vma, unsigned long addr, bool cow_from_owner) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 30bc34d..8801dbc 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -2955,6 +2955,14 @@ int replace_free_hugepage_folios(unsigned long start_pfn, unsigned long end_pfn) return ret; } +void wait_for_freed_hugetlb_folios(void) +{ + if (llist_empty(&hpage_freelist)) + return; + + flush_work(&free_hpage_work); +} + typedef enum { /* * For either 0/1: we checked the per-vma resv map, and one resv diff --git a/mm/page_isolation.c b/mm/page_isolation.c index 8ed53ee0..b2fc526 100644 --- a/mm/page_isolation.c +++ b/mm/page_isolation.c @@ -615,6 +615,16 @@ int test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn, int ret; /* + * Due to the deferred freeing of hugetlb folios, the hugepage folios may + * not immediately release to the buddy system. This can cause PageBuddy() + * to fail in __test_page_isolated_in_pageblock(). To ensure that the + * hugetlb folios are properly released back to the buddy system, we + * invoke the wait_for_freed_hugetlb_folios() function to wait for the + * release to complete. + */ + wait_for_freed_hugetlb_folios(); + + /* * Note: pageblock_nr_pages != MAX_PAGE_ORDER. Then, chunks of free * pages are not aligned to pageblock_nr_pages. * Then we just check migratetype first. -- 2.7.4

3 days, 20 hours

3
2
0 0

[PATCH AUTOSEL 6.6 01/17] HID: intel-ish-hid: fix the length of MNG_SYNC_FW_CLOCK in doorbell

by Sasha Levin

From: Zhang Lixu <lixu.zhang(a)intel.com> [ Upstream commit 4b54ae69197b9f416baa0fceadff7e89075f8454 ] The timestamps in the Firmware log and HID sensor samples are incorrect. They show 1970-01-01 because the current IPC driver only uses the first 8 bytes of bootup time when synchronizing time with the firmware. The firmware converts the bootup time to UTC time, which results in the display of 1970-01-01. In write_ipc_from_queue(), when sending the MNG_SYNC_FW_CLOCK message, the clock is updated according to the definition of ipc_time_update_msg. However, in _ish_sync_fw_clock(), the message length is specified as the size of uint64_t when building the doorbell. As a result, the firmware only receives the first 8 bytes of struct ipc_time_update_msg. This patch corrects the length in the doorbell to ensure the entire ipc_time_update_msg is sent, fixing the timestamp issue. Signed-off-by: Zhang Lixu <lixu.zhang(a)intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/hid/intel-ish-hid/ipc/ipc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c b/drivers/hid/intel-ish-hid/ipc/ipc.c index dd5fc60874ba1..b1a41c90c5741 100644 --- a/drivers/hid/intel-ish-hid/ipc/ipc.c +++ b/drivers/hid/intel-ish-hid/ipc/ipc.c @@ -577,14 +577,14 @@ static void fw_reset_work_fn(struct work_struct *unused) static void _ish_sync_fw_clock(struct ishtp_device *dev) { static unsigned long prev_sync; - uint64_t usec; + struct ipc_time_update_msg time = {}; if (prev_sync && time_before(jiffies, prev_sync + 20 * HZ)) return; prev_sync = jiffies; - usec = ktime_to_us(ktime_get_boottime()); - ipc_send_mng_msg(dev, MNG_SYNC_FW_CLOCK, &usec, sizeof(uint64_t)); + /* The fields of time would be updated while sending message */ + ipc_send_mng_msg(dev, MNG_SYNC_FW_CLOCK, &time, sizeof(time)); } /** -- 2.39.5

3 days, 21 hours

2
17
0 0

[PATCH] scsi: esas2r: Add check for alloc_ordered_workqueue()

by Haoxiang Li

Add check for the return value of alloc_ordered_workqueue() in esas2r_init_adapter() to catch potential exception. Fixes: 4cb1b41a5ee4 ("scsi: esas2r: Simplify an alloc_ordered_workqueue() invocation") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024(a)163.com> --- drivers/scsi/esas2r/esas2r_init.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/scsi/esas2r/esas2r_init.c b/drivers/scsi/esas2r/esas2r_init.c index 0cea5f3d1a08..48bb8aaf9df4 100644 --- a/drivers/scsi/esas2r/esas2r_init.c +++ b/drivers/scsi/esas2r/esas2r_init.c @@ -314,6 +314,11 @@ int esas2r_init_adapter(struct Scsi_Host *host, struct pci_dev *pcid, a->fw_event_q = alloc_ordered_workqueue("esas2r/%d", WQ_MEM_RECLAIM, a->index); + if (!a->fw_event_q) { + esas2r_log(ESAS2R_LOG_CRIT, "failed to create work queue\n"); + esas2r_kill_adapter(index); + return 0; + } init_waitqueue_head(&a->buffered_ioctl_waiter); init_waitqueue_head(&a->nvram_waiter); init_waitqueue_head(&a->fm_api_waiter); -- 2.25.1

3 days, 21 hours

1
0
0 0

[PATCH] Revert "ext4: apply umask if ACL support is disabled"

by Max Kellermann

This reverts commit 484fd6c1de13b336806a967908a927cc0356e312. The commit caused a regression because now the umask was applied to symlinks and the fix is unnecessary because the umask/O_TMPFILE bug has been fixed somewhere else already. Fixes: https://lore.kernel.org/lkml/28DSITL9912E1.2LSZUVTGTO52Q@mforney.org/ Signed-off-by: Max Kellermann <max.kellermann(a)ionos.com> --- fs/ext4/acl.h | 5 ----- 1 file changed, 5 deletions(-) diff --git a/fs/ext4/acl.h b/fs/ext4/acl.h index ef4c19e5f570..0c5a79c3b5d4 100644 --- a/fs/ext4/acl.h +++ b/fs/ext4/acl.h @@ -68,11 +68,6 @@ extern int ext4_init_acl(handle_t *, struct inode *, struct inode *); static inline int ext4_init_acl(handle_t *handle, struct inode *inode, struct inode *dir) { - /* usually, the umask is applied by posix_acl_create(), but if - ext4 ACL support is disabled at compile time, we need to do - it here, because posix_acl_create() will never be called */ - inode->i_mode &= ~current_umask(); - return 0; } #endif /* CONFIG_EXT4_FS_POSIX_ACL */ -- 2.39.2

3 days, 21 hours

6
6
0 0

Re: [PATCH] jfs: fix slab-out-of-bounds read in ea_get()

by Qasim Ijaz

On Thu, Feb 13, 2025 at 11:07:07AM +0100, Greg KH wrote: > On Thu, Feb 13, 2025 at 12:20:25AM +0000, Qasim Ijaz wrote: > > During the "size_check" label in ea_get(), the code checks if the extended > > attribute list (xattr) size matches ea_size. If not, it logs > > "ea_get: invalid extended attribute" and calls print_hex_dump(). > > > > Here, EALIST_SIZE(ea_buf->xattr) returns 4110417968, which exceeds > > INT_MAX (2,147,483,647). Then ea_size is clamped: > > > > int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr)); > > > > Although clamp_t aims to bound ea_size between 0 and 4110417968, the upper > > limit is treated as an int, causing an overflow above 2^31 - 1. This leads > > "size" to wrap around and become negative (-184549328). > > > > The "size" is then passed to print_hex_dump() (called "len" in > > print_hex_dump()), it is passed as type size_t (an unsigned > > type), this is then stored inside a variable called > > "int remaining", which is then assigned to "int linelen" which > > is then passed to hex_dump_to_buffer(). In print_hex_dump() > > the for loop, iterates through 0 to len-1, where len is > > 18446744073525002176, calling hex_dump_to_buffer() > > on each iteration: > > > > for (i = 0; i < len; i += rowsize) { > > linelen = min(remaining, rowsize); > > remaining -= rowsize; > > > > hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize, > > linebuf, sizeof(linebuf), ascii); > > > > ... > > } > > > > The expected stopping condition (i < len) is effectively broken > > since len is corrupted and very large. This eventually leads to > > the "ptr+i" being passed to hex_dump_to_buffer() to get closer > > to the end of the actual bounds of "ptr", eventually an out of > > bounds access is done in hex_dump_to_buffer() in the following > > for loop: > > > > for (j = 0; j < len; j++) { > > if (linebuflen < lx + 2) > > goto overflow2; > > ch = ptr[j]; > > ... > > } > > > > To fix this we should validate "EALIST_SIZE(ea_buf->xattr)" > > before it is utilised. > > > > Reported-by: syzbot <syzbot+4e6e7e4279d046613bc5(a)syzkaller.appspotmail.com> > > Tested-by: syzbot <syzbot+4e6e7e4279d046613bc5(a)syzkaller.appspotmail.com> > > Closes: https://syzkaller.appspot.com/bug?extid=4e6e7e4279d046613bc5 > > Fixes: d9f9d96136cb ("jfs: xattr: check invalid xattr size more strictly") > > Signed-off-by: Qasim Ijaz <qasdev00(a)gmail.com> > > --- > > fs/jfs/xattr.c | 15 ++++++++++----- > > 1 file changed, 10 insertions(+), 5 deletions(-) > > > > diff --git a/fs/jfs/xattr.c b/fs/jfs/xattr.c > > index 24afbae87225..7575c51cce9b 100644 > > --- a/fs/jfs/xattr.c > > +++ b/fs/jfs/xattr.c > > @@ -559,11 +555,16 @@ static int ea_get(struct inode *inode, struct ea_buffer *ea_buf, int min_size) > > > > size_check: > > if (EALIST_SIZE(ea_buf->xattr) != ea_size) { > > - int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr)); > > - > > - printk(KERN_ERR "ea_get: invalid extended attribute\n"); > > - print_hex_dump(KERN_ERR, "", DUMP_PREFIX_ADDRESS, 16, 1, > > - ea_buf->xattr, size, 1); > > + if (unlikely(EALIST_SIZE(ea_buf->xattr) > INT_MAX)) { > > + printk(KERN_ERR "ea_get: extended attribute size too large: %u > INT_MAX\n", > > + EALIST_SIZE(ea_buf->xattr)); > > + } else { > > + int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr)); > > + > > + printk(KERN_ERR "ea_get: invalid extended attribute\n"); > > + print_hex_dump(KERN_ERR, "", DUMP_PREFIX_ADDRESS, 16, 1, > > + ea_buf->xattr, size, 1); > > + } > > ea_release(inode, ea_buf); > > rc = -EIO; > > goto clean_up; > > -- > > 2.39.5 > > > > Hi, > > This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him > a patch that has triggered this response. He used to manually respond > to these common problems, but in order to save his sanity (he kept > writing the same thing over and over, yet to different people), I was > created. Hopefully you will not take offence and will fix the problem > in your patch and resubmit it so that it can be accepted into the Linux > kernel tree. > > You are receiving this message because of the following common error(s) > as indicated below: > > - You have marked a patch with a "Fixes:" tag for a commit that is in an > older released kernel, yet you do not have a cc: stable line in the > signed-off-by area at all, which means that the patch will not be > applied to any older kernel releases. To properly fix this, please > follow the documented rules in the > Documentation/process/stable-kernel-rules.rst file for how to resolve > this. > > If you wish to discuss this problem further, or you have questions about > how to resolve this issue, please feel free to respond to this email and > Greg will reply once he has dug out from the pending patches received > from other developers. > Hi Greg, Just following up on this patch. I’ve sent v2 with the added CC stable tag. Here’s the link: https://lore.kernel.org/all/20250213210553.28613-1-qasdev00@gmail.com/ Let me know if any further changes are needed. Thanks, Qasim > thanks, > > greg k-h's patch email bot

3 days, 23 hours

2
1
0 0

[PATCH v2 Linux-6.12.y Linux-6.13.y 1/1] selftests/mm: build with -O2

by Yifei Liu

From: Kevin Brodsky <kevin.brodsky(a)arm.com> [ Upstream commit 46036188ea1f5266df23a6149dea0df1c77cd1c7 ] The mm kselftests are currently built with no optimisation (-O0). It's unclear why, and besides being obviously suboptimal, this also prevents the pkeys tests from working as intended. Let's build all the tests with -O2. [kevin.brodsky(a)arm.com: silence unused-result warnings] Link: https://lkml.kernel.org/r/20250107170110.2819685-1-kevin.brodsky@arm.com Link: https://lkml.kernel.org/r/20241209095019.1732120-6-kevin.brodsky@arm.com Signed-off-by: Kevin Brodsky <kevin.brodsky(a)arm.com> Cc: Aruna Ramakrishna <aruna.ramakrishna(a)oracle.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Joey Gouly <joey.gouly(a)arm.com> Cc: Keith Lucas <keith.lucas(a)oracle.com> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Shuah Khan <shuah(a)kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> (cherry picked from commit 46036188ea1f5266df23a6149dea0df1c77cd1c7) [Yifei: This commit also fix the failure of pkey_sighandler_tests_64, which is also in linux-6.12.y and linux-6.13.y, thus backport this commit] Signed-off-by: Yifei Liu <yifei.l.liu(a)oracle.com> --- tools/testing/selftests/mm/Makefile | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/mm/Makefile b/tools/testing/selftests/mm/Makefile index 02e1204971b0..c0138cb19705 100644 --- a/tools/testing/selftests/mm/Makefile +++ b/tools/testing/selftests/mm/Makefile @@ -33,9 +33,16 @@ endif # LDLIBS. MAKEFLAGS += --no-builtin-rules -CFLAGS = -Wall -I $(top_srcdir) $(EXTRA_CFLAGS) $(KHDR_INCLUDES) $(TOOLS_INCLUDES) +CFLAGS = -Wall -O2 -I $(top_srcdir) $(EXTRA_CFLAGS) $(KHDR_INCLUDES) $(TOOLS_INCLUDES) LDLIBS = -lrt -lpthread -lm +# Some distributions (such as Ubuntu) configure GCC so that _FORTIFY_SOURCE is +# automatically enabled at -O1 or above. This triggers various unused-result +# warnings where functions such as read() or write() are called and their +# return value is not checked. Disable _FORTIFY_SOURCE to silence those +# warnings. +CFLAGS += -U_FORTIFY_SOURCE + TEST_GEN_FILES = cow TEST_GEN_FILES += compaction_test TEST_GEN_FILES += gup_longterm -- 2.46.0

3 days, 23 hours

4
7
0 0

[PATCH] drm/xe: Fix exporting xe buffers multiple times

by Jacek Lawrynowicz

From: Tomasz Rusinowicz <tomasz.rusinowicz(a)intel.com> The `struct ttm_resource->placement` contains TTM_PL_FLAG_* flags, but it was incorrectly tested for XE_PL_* flags. This caused xe_dma_buf_pin() to always fail when invoked for the second time. Fix this by checking the `mem_type` field instead. Fixes: 7764222d54b7 ("drm/xe: Disallow pinning dma-bufs in VRAM") Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Lucas De Marchi <lucas.demarchi(a)intel.com> Cc: "Thomas Hellström" <thomas.hellstrom(a)linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko(a)intel.com> Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: Matthew Auld <matthew.auld(a)intel.com> Cc: Nirmoy Das <nirmoy.das(a)intel.com> Cc: Jani Nikula <jani.nikula(a)intel.com> Cc: intel-xe(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v6.8+ Signed-off-by: Tomasz Rusinowicz <tomasz.rusinowicz(a)intel.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz(a)linux.intel.com> --- drivers/gpu/drm/xe/xe_bo.h | 2 -- drivers/gpu/drm/xe/xe_dma_buf.c | 2 +- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_bo.h b/drivers/gpu/drm/xe/xe_bo.h index d9386ab031404..43bf6f140d40d 100644 --- a/drivers/gpu/drm/xe/xe_bo.h +++ b/drivers/gpu/drm/xe/xe_bo.h @@ -341,7 +341,6 @@ static inline unsigned int xe_sg_segment_size(struct device *dev) return round_down(max / 2, PAGE_SIZE); } -#if IS_ENABLED(CONFIG_DRM_XE_KUNIT_TEST) /** * xe_bo_is_mem_type - Whether the bo currently resides in the given * TTM memory type @@ -356,4 +355,3 @@ static inline bool xe_bo_is_mem_type(struct xe_bo *bo, u32 mem_type) return bo->ttm.resource->mem_type == mem_type; } #endif -#endif diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c b/drivers/gpu/drm/xe/xe_dma_buf.c index c5b95470fa324..f67803e15a0e6 100644 --- a/drivers/gpu/drm/xe/xe_dma_buf.c +++ b/drivers/gpu/drm/xe/xe_dma_buf.c @@ -58,7 +58,7 @@ static int xe_dma_buf_pin(struct dma_buf_attachment *attach) * 1) Avoid pinning in a placement not accessible to some importers. * 2) Pinning in VRAM requires PIN accounting which is a to-do. */ - if (xe_bo_is_pinned(bo) && bo->ttm.resource->placement != XE_PL_TT) { + if (xe_bo_is_pinned(bo) && !xe_bo_is_mem_type(bo, XE_PL_TT)) { drm_dbg(&xe->drm, "Can't migrate pinned bo for dma-buf pin.\n"); return -EINVAL; } -- 2.45.1

4 days, 1 hour

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror