January 2025 - Linux-stable-mirror

[PATCH 6.1.y] RDMA/rxe: Fix the qp flush warnings in req

by lanbincn＠qq.com

From: Zhu Yanjun <yanjun.zhu(a)linux.dev> commit ea4c990fa9e19ffef0648e40c566b94ba5ab31be upstream. When the qp is in error state, the status of WQEs in the queue should be set to error. Or else the following will appear. [ 920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxe_comp.c:756 rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.617744] Modules linked in: rnbd_client(O) rtrs_client(O) rtrs_core(O) rdma_ucm rdma_cm iw_cm ib_cm crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel ib_uverbs ib_core loop brd null_blk ipv6 [ 920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G O 6.1.113-storage+ #65 [ 920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 920.619396] RIP: 0010:rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff <0f> 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24 [ 920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246 [ 920.620817] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000008 [ 920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac [ 920.621548] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffac406450 [ 920.621884] R10: ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800 [ 920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: 0000000000000000 [ 920.622609] FS: 0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000 [ 920.622979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 920.623245] CR2: 00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0 [ 920.623680] Call Trace: [ 920.623815] <TASK> [ 920.623933] ? __warn+0x79/0xc0 [ 920.624116] ? rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.624356] ? report_bug+0xfb/0x150 [ 920.624594] ? handle_bug+0x3c/0x60 [ 920.624796] ? exc_invalid_op+0x14/0x70 [ 920.624976] ? asm_exc_invalid_op+0x16/0x20 [ 920.625203] ? rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.625474] ? rxe_completer+0x329/0xcc0 [rdma_rxe] [ 920.625749] rxe_do_task+0x80/0x110 [rdma_rxe] [ 920.626037] rxe_requester+0x625/0xde0 [rdma_rxe] [ 920.626310] ? rxe_cq_post+0xe2/0x180 [rdma_rxe] [ 920.626583] ? do_complete+0x18d/0x220 [rdma_rxe] [ 920.626812] ? rxe_completer+0x1a3/0xcc0 [rdma_rxe] [ 920.627050] rxe_do_task+0x80/0x110 [rdma_rxe] [ 920.627285] tasklet_action_common.constprop.0+0xa4/0x120 [ 920.627522] handle_softirqs+0xc2/0x250 [ 920.627728] ? sort_range+0x20/0x20 [ 920.627942] run_ksoftirqd+0x1f/0x30 [ 920.628158] smpboot_thread_fn+0xc7/0x1b0 [ 920.628334] kthread+0xd6/0x100 [ 920.628504] ? kthread_complete_and_exit+0x20/0x20 [ 920.628709] ret_from_fork+0x1f/0x30 [ 920.628892] </TASK> Fixes: ae720bdb703b ("RDMA/rxe: Generate error completion for error requester QP state") Signed-off-by: Zhu Yanjun <yanjun.zhu(a)linux.dev> Link: https://patch.msgid.link/20241025152036.121417-1-yanjun.zhu@linux.dev Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Bin Lan <lanbincn(a)qq.com> --- drivers/infiniband/sw/rxe/rxe_req.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/sw/rxe/rxe_req.c b/drivers/infiniband/sw/rxe/rxe_req.c index 35768fdbd5b7..1ef5819e75ff 100644 --- a/drivers/infiniband/sw/rxe/rxe_req.c +++ b/drivers/infiniband/sw/rxe/rxe_req.c @@ -643,13 +643,15 @@ int rxe_requester(void *arg) if (unlikely(qp->req.state == QP_STATE_ERROR)) { wqe = req_next_wqe(qp); - if (wqe) + if (wqe) { /* * Generate an error completion for error qp state */ + wqe->status = IB_WC_WR_FLUSH_ERR; goto err; - else + } else { goto exit; + } } if (unlikely(qp->req.state == QP_STATE_RESET)) { -- 2.43.0

4 weeks, 1 day

2
1
0 0

UBSAN array-index-out-of-bounds: cfg80211_scan_6ghz

by John Rowley

Hi, I'm experiencing UBSAN array-index-out-of-bounds errors while using my Framework 13" AMD laptop with its Mediatek MT7922 wifi adapter (mt7921e). It seems to happen only once on boot, and occurs with both kernel versions 6.12.7 and 6.13-rc4, both compiled from vanilla upstream kernel sources on Fedora 41 using the kernel.org LLVM toolchain (19.1.6). I can try some other kernel series if necessary, and also a bisect if I find a working version, but that may take me a while. I wasn't sure if I should mark this as a regression, as I'm not sure which/if there is a working kernel version at this point. Thanks. ---- [ 17.754417] UBSAN: array-index-out-of-bounds in /data/linux/net/wireless/scan.c:766:2 [ 17.754423] index 0 is out of range for type 'struct ieee80211_channel *[] __counted_by(n_channels)' (aka 'struct ieee80211_channel *[]') [ 17.754427] CPU: 13 UID: 0 PID: 620 Comm: kworker/u64:10 Tainted: G T 6.13.0-rc4 #9 [ 17.754433] Tainted: [T]=RANDSTRUCT [ 17.754435] Hardware name: Framework Laptop 13 (AMD Ryzen 7040Series)/FRANMDCP07, BIOS 03.05 03/29/2024 [ 17.754438] Workqueue: events_unbound cfg80211_wiphy_work [ 17.754446] Call Trace: [ 17.754449] <TASK> [ 17.754452] dump_stack_lvl+0x82/0xc0 [ 17.754459] __ubsan_handle_out_of_bounds+0xe7/0x110 [ 17.754464] ? srso_alias_return_thunk+0x5/0xfbef5 [ 17.754470] ? __kmalloc_noprof+0x1a7/0x280 [ 17.754477] cfg80211_scan_6ghz+0x3bb/0xfd0 [ 17.754482] ? srso_alias_return_thunk+0x5/0xfbef5 [ 17.754486] ? try_to_wake_up+0x368/0x4c0 [ 17.754491] ? try_to_wake_up+0x1a9/0x4c0 [ 17.754496] ___cfg80211_scan_done+0xa9/0x1e0 [ 17.754500] cfg80211_wiphy_work+0xb7/0xe0 [ 17.754504] process_scheduled_works+0x205/0x3a0 [ 17.754509] worker_thread+0x24a/0x300 [ 17.754514] ? __cfi_worker_thread+0x10/0x10 [ 17.754519] kthread+0x158/0x180 [ 17.754524] ? __cfi_kthread+0x10/0x10 [ 17.754528] ret_from_fork+0x40/0x50 [ 17.754534] ? __cfi_kthread+0x10/0x10 [ 17.754538] ret_from_fork_asm+0x11/0x30 [ 17.754544] </TASK>

4 weeks, 1 day

3
3
0 0

Re: [PATCH v3] USB: serial: quatech2: Fix null-ptr-deref in qt2_process_read_urb()

by Qasim Ijaz

On Tue, Jan 14, 2025 at 10:47:33AM +0100, Johan Hovold wrote: > On Mon, Jan 13, 2025 at 06:00:34PM +0000, Qasim Ijaz wrote: > > This patch addresses a null-ptr-deref in qt2_process_read_urb() due to > > an incorrect bounds check in the following: > > > > if (newport > serial->num_ports) { > > dev_err(&port->dev, > > "%s - port change to invalid port: %i\n", > > __func__, newport); > > break; > > } > > > > The condition doesn't account for the valid range of the serial->port > > buffer, which is from 0 to serial->num_ports - 1. When newport is equal > > to serial->num_ports, the assignment of "port" in the > > following code is out-of-bounds and NULL: > > > > serial_priv->current_port = newport; > > port = serial->port[serial_priv->current_port]; > > > > The fix checks if newport is greater than or equal to serial->num_ports > > indicating it is out-of-bounds. > > > > Reported-by: syzbot <syzbot+506479ebf12fe435d01a(a)syzkaller.appspotmail.com> > > Closes: https://syzkaller.appspot.com/bug?extid=506479ebf12fe435d01a > > Fixes: f7a33e608d9a ("USB: serial: add quatech2 usb to serial driver") > > Cc: <stable(a)vger.kernel.org> # 3.5 > > Signed-off-by: Qasim Ijaz <qasdev00(a)gmail.com> > > --- > > Thanks for the update. I've applied the patch now after adding Greg's > Reviewed-by tag (for v2). > > For your future contributions, try to remember to include any > Reviewed-by or Tested-by tags when updating the patch unless the changes > are non-trivial. > > There should typically also be a short change log here under the --- > line to indicate what changes from previous versions. > > It is also encouraged to write the commit message in imperative mood > (add, change, fix) and to avoid the phrase "this patch". There are some > more details in > > Documentation/process/submitting-patches.rst > > Something to keep in mind for the future, but this patch already looks > really good. > > Johan Hi Johan, Thanks for reviewing and applying the patch. I appreciate the guidance on patch style and process, and I'll incorporate your suggestions in future submissions. Best regards, Qasim

4 weeks, 1 day

1
0
0 0

[GIT PULL 4/5] xfs: realtime reverse-mapping support

by Darrick J. Wong

Hi Carlos, Please pull this branch with changes for xfs. As usual, I did a test-merge with the main upstream branch as of a few minutes ago, and didn't see any conflicts. Please let me know if you encounter any problems. --D The following changes since commit 05290bd5c6236b8ad659157edb36bd2d38f46d3e: xfs: allow inode-based btrees to reserve space in the data device (2024-12-23 13:06:03 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git tags/realtime-rmap_2024-12-23 for you to fetch changes up to c2358439af374cad47f771797875d0beb8256738: xfs: enable realtime rmap btree (2024-12-23 13:06:09 -0800) ---------------------------------------------------------------- xfs: realtime reverse-mapping support [v6.2 04/14] This is the latest revision of a patchset that adds to XFS kernel support for reverse mapping for the realtime device. This time around I've fixed some of the bitrot that I've noticed over the past few months, and most notably have converted rtrmapbt to use the metadata inode directory feature instead of burning more space in the superblock. At the beginning of the set are patches to implement storing B+tree leaves in an inode root, since the realtime rmapbt is rooted in an inode, unlike the regular rmapbt which is rooted in an AG block. Prior to this, the only btree that could be rooted in the inode fork was the block mapping btree; if all the extent records fit in the inode, format would be switched from 'btree' to 'extents'. The next few patches enhance the reverse mapping routines to handle the parts that are specific to rtgroups -- adding the new btree type, adding a new log intent item type, and wiring up the metadata directory tree entries. Finally, implement GETFSMAP with the rtrmapbt and scrub functionality for the rtrmapbt and rtbitmap and online fsck functionality. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: "Darrick J. Wong" <djwong(a)kernel.org> ---------------------------------------------------------------- Darrick J. Wong (37): xfs: add some rtgroup inode helpers xfs: prepare rmap btree cursor tracepoints for realtime xfs: simplify the xfs_rmap_{alloc,free}_extent calling conventions xfs: introduce realtime rmap btree ondisk definitions xfs: realtime rmap btree transaction reservations xfs: add realtime rmap btree operations xfs: prepare rmap functions to deal with rtrmapbt xfs: add a realtime flag to the rmap update log redo items xfs: support recovering rmap intent items targetting realtime extents xfs: pretty print metadata file types in error messages xfs: support file data forks containing metadata btrees xfs: add realtime reverse map inode to metadata directory xfs: add metadata reservations for realtime rmap btrees xfs: wire up a new metafile type for the realtime rmap xfs: wire up rmap map and unmap to the realtime rmapbt xfs: create routine to allocate and initialize a realtime rmap btree inode xfs: wire up getfsmap to the realtime reverse mapping btree xfs: check that the rtrmapbt maxlevels doesn't increase when growing fs xfs: report realtime rmap btree corruption errors to the health system xfs: allow queued realtime intents to drain before scrubbing xfs: scrub the realtime rmapbt xfs: cross-reference realtime bitmap to realtime rmapbt scrubber xfs: cross-reference the realtime rmapbt xfs: scan rt rmap when we're doing an intense rmap check of bmbt mappings xfs: scrub the metadir path of rt rmap btree files xfs: walk the rt reverse mapping tree when rebuilding rmap xfs: online repair of realtime file bmaps xfs: repair inodes that have realtime extents xfs: repair rmap btree inodes xfs: online repair of realtime bitmaps for a realtime group xfs: support repairing metadata btrees rooted in metadir inodes xfs: online repair of the realtime rmap btree xfs: create a shadow rmap btree during realtime rmap repair xfs: hook live realtime rmap operations during a repair operation xfs: don't shut down the filesystem for media failures beyond end of log xfs: react to fsdax failure notifications on the rt device xfs: enable realtime rmap btree fs/xfs/Makefile | 3 + fs/xfs/libxfs/xfs_btree.c | 73 +++ fs/xfs/libxfs/xfs_btree.h | 8 +- fs/xfs/libxfs/xfs_btree_mem.c | 1 + fs/xfs/libxfs/xfs_btree_staging.c | 1 + fs/xfs/libxfs/xfs_defer.h | 1 + fs/xfs/libxfs/xfs_exchmaps.c | 4 +- fs/xfs/libxfs/xfs_format.h | 28 +- fs/xfs/libxfs/xfs_fs.h | 7 +- fs/xfs/libxfs/xfs_health.h | 4 +- fs/xfs/libxfs/xfs_inode_buf.c | 32 +- fs/xfs/libxfs/xfs_inode_fork.c | 25 + fs/xfs/libxfs/xfs_log_format.h | 6 +- fs/xfs/libxfs/xfs_log_recover.h | 2 + fs/xfs/libxfs/xfs_metafile.c | 18 + fs/xfs/libxfs/xfs_metafile.h | 2 + fs/xfs/libxfs/xfs_ondisk.h | 2 + fs/xfs/libxfs/xfs_refcount.c | 6 +- fs/xfs/libxfs/xfs_rmap.c | 171 +++++-- fs/xfs/libxfs/xfs_rmap.h | 12 +- fs/xfs/libxfs/xfs_rtbitmap.c | 2 +- fs/xfs/libxfs/xfs_rtbitmap.h | 9 + fs/xfs/libxfs/xfs_rtgroup.c | 53 +- fs/xfs/libxfs/xfs_rtgroup.h | 49 +- fs/xfs/libxfs/xfs_rtrmap_btree.c | 1011 +++++++++++++++++++++++++++++++++++++ fs/xfs/libxfs/xfs_rtrmap_btree.h | 210 ++++++++ fs/xfs/libxfs/xfs_sb.c | 6 + fs/xfs/libxfs/xfs_shared.h | 14 + fs/xfs/libxfs/xfs_trans_resv.c | 12 +- fs/xfs/libxfs/xfs_trans_space.h | 13 + fs/xfs/scrub/alloc_repair.c | 5 +- fs/xfs/scrub/bmap.c | 108 +++- fs/xfs/scrub/bmap_repair.c | 129 ++++- fs/xfs/scrub/common.c | 160 +++++- fs/xfs/scrub/common.h | 23 +- fs/xfs/scrub/health.c | 1 + fs/xfs/scrub/inode.c | 10 +- fs/xfs/scrub/inode_repair.c | 136 ++++- fs/xfs/scrub/metapath.c | 3 + fs/xfs/scrub/newbt.c | 42 ++ fs/xfs/scrub/newbt.h | 1 + fs/xfs/scrub/reap.c | 41 ++ fs/xfs/scrub/reap.h | 2 + fs/xfs/scrub/repair.c | 191 +++++++ fs/xfs/scrub/repair.h | 17 + fs/xfs/scrub/rgsuper.c | 6 +- fs/xfs/scrub/rmap_repair.c | 84 ++- fs/xfs/scrub/rtbitmap.c | 75 ++- fs/xfs/scrub/rtbitmap.h | 55 ++ fs/xfs/scrub/rtbitmap_repair.c | 429 +++++++++++++++- fs/xfs/scrub/rtrmap.c | 271 ++++++++++ fs/xfs/scrub/rtrmap_repair.c | 903 +++++++++++++++++++++++++++++++++ fs/xfs/scrub/rtsummary.c | 17 +- fs/xfs/scrub/rtsummary_repair.c | 3 +- fs/xfs/scrub/scrub.c | 11 +- fs/xfs/scrub/scrub.h | 14 + fs/xfs/scrub/stats.c | 1 + fs/xfs/scrub/tempexch.h | 2 +- fs/xfs/scrub/tempfile.c | 20 +- fs/xfs/scrub/trace.c | 1 + fs/xfs/scrub/trace.h | 228 ++++++++- fs/xfs/xfs_buf.c | 1 + fs/xfs/xfs_buf_item_recover.c | 4 + fs/xfs/xfs_drain.c | 20 +- fs/xfs/xfs_drain.h | 7 +- fs/xfs/xfs_fsmap.c | 174 ++++++- fs/xfs/xfs_fsops.c | 11 + fs/xfs/xfs_health.c | 1 + fs/xfs/xfs_inode.c | 19 +- fs/xfs/xfs_inode_item.c | 2 + fs/xfs/xfs_inode_item_recover.c | 44 +- fs/xfs/xfs_log_recover.c | 2 + fs/xfs/xfs_mount.c | 5 +- fs/xfs/xfs_mount.h | 9 + fs/xfs/xfs_notify_failure.c | 230 +++++---- fs/xfs/xfs_notify_failure.h | 11 + fs/xfs/xfs_qm.c | 8 +- fs/xfs/xfs_rmap_item.c | 216 +++++++- fs/xfs/xfs_rtalloc.c | 82 ++- fs/xfs/xfs_rtalloc.h | 10 + fs/xfs/xfs_stats.c | 4 +- fs/xfs/xfs_stats.h | 2 + fs/xfs/xfs_super.c | 6 - fs/xfs/xfs_super.h | 1 - fs/xfs/xfs_trace.h | 104 ++-- 85 files changed, 5381 insertions(+), 366 deletions(-) create mode 100644 fs/xfs/libxfs/xfs_rtrmap_btree.c create mode 100644 fs/xfs/libxfs/xfs_rtrmap_btree.h create mode 100644 fs/xfs/scrub/rtrmap.c create mode 100644 fs/xfs/scrub/rtrmap_repair.c create mode 100644 fs/xfs/xfs_notify_failure.h

4 weeks, 1 day

2
1
0 0

[GIT PULL 1/5] xfs: bug fixes for 6.13

by Darrick J. Wong

Hi Carlos, Please pull this branch with changes for xfs. As usual, I did a test-merge with the main upstream branch as of a few minutes ago, and didn't see any conflicts. Please let me know if you encounter any problems. --D The following changes since commit 4bbf9020becbfd8fc2c3da790855b7042fad455b: Linux 6.13-rc4 (2024-12-22 13:22:21 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git tags/xfs-6.13-fixes_2024-12-23 for you to fetch changes up to 1aacd3fac248902ea1f7607f2d12b93929a4833b: xfs: release the dquot buf outside of qli_lock (2024-12-23 13:06:01 -0800) ---------------------------------------------------------------- xfs: bug fixes for 6.13 [01/14] Bug fixes for 6.13. This has been running on the djcloud for months with no problems. Enjoy! Signed-off-by: "Darrick J. Wong" <djwong(a)kernel.org> ---------------------------------------------------------------- Darrick J. Wong (2): xfs: don't over-report free space or inodes in statvfs xfs: release the dquot buf outside of qli_lock fs/xfs/xfs_dquot.c | 12 ++++++++---- fs/xfs/xfs_qm_bhv.c | 27 +++++++++++++++++---------- 2 files changed, 25 insertions(+), 14 deletions(-)

4 weeks, 1 day

2
1
0 0

[PATCH v3] USB: serial: quatech2: Fix null-ptr-deref in qt2_process_read_urb()

by Qasim Ijaz

This patch addresses a null-ptr-deref in qt2_process_read_urb() due to an incorrect bounds check in the following: if (newport > serial->num_ports) { dev_err(&port->dev, "%s - port change to invalid port: %i\n", __func__, newport); break; } The condition doesn't account for the valid range of the serial->port buffer, which is from 0 to serial->num_ports - 1. When newport is equal to serial->num_ports, the assignment of "port" in the following code is out-of-bounds and NULL: serial_priv->current_port = newport; port = serial->port[serial_priv->current_port]; The fix checks if newport is greater than or equal to serial->num_ports indicating it is out-of-bounds. Reported-by: syzbot <syzbot+506479ebf12fe435d01a(a)syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=506479ebf12fe435d01a Fixes: f7a33e608d9a ("USB: serial: add quatech2 usb to serial driver") Cc: <stable(a)vger.kernel.org> # 3.5 Signed-off-by: Qasim Ijaz <qasdev00(a)gmail.com> --- drivers/usb/serial/quatech2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/serial/quatech2.c b/drivers/usb/serial/quatech2.c index a317bdbd00ad..72fe83a6c978 100644 --- a/drivers/usb/serial/quatech2.c +++ b/drivers/usb/serial/quatech2.c @@ -503,7 +503,7 @@ static void qt2_process_read_urb(struct urb *urb) newport = *(ch + 3); - if (newport > serial->num_ports) { + if (newport >= serial->num_ports) { dev_err(&port->dev, "%s - port change to invalid port: %i\n", __func__, newport); -- 2.39.5

4 weeks, 1 day

2
1
0 0

[PATCH 5.15 0/3] ZRAM not releasing backing device backport

by Dominique Martinet

This is a resend of the patchset discussed here[1] for the 5.15 tree. [1] https://lore.kernel.org/r/2025011052-backpedal-coat-2fec@gregkh I've picked the "do not keep dangling zcomp pointer" patch from the linux-rc tree at the time, so kept Sasha's SOB and added mine on top -- please let me know if it wasn't appropriate. I've also prepared the 5.10 patches, but I hadn't realized there were so many stable deps (8 patchs total!); I'm honestly not sure the problem is worth the churn but since it's done and tested I'll send the patches if there is no problem with this 5.15 version. Thanks! Dominique Martinet (1): zram: check comp is non-NULL before calling comp_destroy Kairui Song (1): zram: fix uninitialized ZRAM not releasing backing device Sergey Senozhatsky (1): drivers/block/zram/zram_drv.c: do not keep dangling zcomp pointer after zram reset drivers/block/zram/zram_drv.c | 23 +++++++++-------------- 1 file changed, 9 insertions(+), 14 deletions(-) -- 2.39.5

4 weeks, 1 day

4
9
0 0

[merged mm-stable] mm-hugetlb-fix-avoid_reserve-to-allow-taking-folio-from-subpool.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/hugetlb: fix avoid_reserve to allow taking folio from subpool has been removed from the -mm tree. Its filename was mm-hugetlb-fix-avoid_reserve-to-allow-taking-folio-from-subpool.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Peter Xu <peterx(a)redhat.com> Subject: mm/hugetlb: fix avoid_reserve to allow taking folio from subpool Date: Tue, 7 Jan 2025 15:39:56 -0500 Patch series "mm/hugetlb: Refactor hugetlb allocation resv accounting", v2. This is a follow up on Ackerley's series here as replacement: https://lore.kernel.org/r/cover.1728684491.git.ackerleytng@google.com The goal of this series is to cleanup hugetlb resv accounting, especially during folio allocation, to decouple a few things: - Hugetlb folios v.s. Hugetlbfs: IOW, the hope is in the future hugetlb folios can be allocated completely without hugetlbfs. - Decouple VMA v.s. hugetlb folio allocations: allocating a hugetlb folio should not always require a hugetlbfs VMA. For example, either it got allocated from the inode level (see hugetlbfs_fallocate() where it used a pesudo VMA for allocation), or it can be allocated by other kernel subsystems. It paves way for other users to allocate hugetlb folios out of either system reservations, or subpools (instead of hugetlbfs, as a file system). For longer term, this prepares hugetlb as a separate concept versus hugetlbfs, so that hugetlb folios can be allocated by not only hugetlbfs and other things. Tests I've done: - I had a reproducer in patch 1 for the bug I found, this will start to work after patch 1 or the whole set applied. - Hugetlb regression tests (on x86_64 2MBs), includes: - All vmtests on hugetlbfs - libhugetlbfs test suite (which may fail some tests, but no new failures will be introduced by this series, so all such failures happen before this series so shouldn't be relevant). This patch (of 7): Since commit 04f2cbe35699 ("hugetlb: guarantee that COW faults for a process that called mmap(MAP_PRIVATE) on hugetlbfs will succeed"), avoid_reserve was introduced for a special case of CoW on hugetlb private mappings, and only if the owner VMA is trying to allocate yet another hugetlb folio that is not reserved within the private vma reserved map. Later on, in commit d85f69b0b533 ("mm/hugetlb: alloc_huge_page handle areas hole punched by fallocate"), alloc_huge_page() enforced to not consume any global reservation as long as avoid_reserve=true. This operation doesn't look correct, because even if it will enforce the allocation to not use global reservation at all, it will still try to take one reservation from the spool (if the subpool existed). Then since the spool reserved pages take from global reservation, it'll also take one reservation globally. Logically it can cause global reservation to go wrong. I wrote a reproducer below, trigger this special path, and every run of such program will cause global reservation count to increment by one, until it hits the number of free pages: #define _GNU_SOURCE /* See feature_test_macros(7) */ #include <stdio.h> #include <fcntl.h> #include <errno.h> #include <unistd.h> #include <stdlib.h> #include <sys/mman.h> #define MSIZE (2UL << 20) int main(int argc, char *argv[]) { const char *path; int *buf; int fd, ret; pid_t child; if (argc < 2) { printf("usage: %s <hugetlb_file>\n", argv[0]); return -1; } path = argv[1]; fd = open(path, O_RDWR | O_CREAT, 0666); if (fd < 0) { perror("open failed"); return -1; } ret = fallocate(fd, 0, 0, MSIZE); if (ret != 0) { perror("fallocate"); return -1; } buf = mmap(NULL, MSIZE, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0); if (buf == MAP_FAILED) { perror("mmap() failed"); return -1; } /* Allocate a page */ *buf = 1; child = fork(); if (child == 0) { /* child doesn't need to do anything */ exit(0); } /* Trigger CoW from owner */ *buf = 2; munmap(buf, MSIZE); close(fd); unlink(path); return 0; } It can only reproduce with a sub-mount when there're reserved pages on the spool, like: # sysctl vm.nr_hugepages=128 # mkdir ./hugetlb-pool # mount -t hugetlbfs -o min_size=8M,pagesize=2M none ./hugetlb-pool Then run the reproducer on the mountpoint: # ./reproducer ./hugetlb-pool/test Fix it by taking the reservation from spool if available. In general, avoid_reserve is IMHO more about "avoid vma resv map", not spool's. I copied stable, however I have no intention for backporting if it's not a clean cherry-pick, because private hugetlb mapping, and then fork() on top is too rare to hit. Link: https://lkml.kernel.org/r/20250107204002.2683356-1-peterx@redhat.com Link: https://lkml.kernel.org/r/20250107204002.2683356-2-peterx@redhat.com Fixes: d85f69b0b533 ("mm/hugetlb: alloc_huge_page handle areas hole punched by fallocate") Signed-off-by: Peter Xu <peterx(a)redhat.com> Reviewed-by: Ackerley Tng <ackerleytng(a)google.com> Tested-by: Ackerley Tng <ackerleytng(a)google.com> Reviewed-by: Oscar Salvador <osalvador(a)suse.de> Cc: Breno Leitao <leitao(a)debian.org> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Naoya Horiguchi <nao.horiguchi(a)gmail.com> Cc: Rik van Riel <riel(a)surriel.com> Cc: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 22 +++------------------- 1 file changed, 3 insertions(+), 19 deletions(-) --- a/mm/hugetlb.c~mm-hugetlb-fix-avoid_reserve-to-allow-taking-folio-from-subpool +++ a/mm/hugetlb.c @@ -1398,8 +1398,7 @@ static unsigned long available_huge_page static struct folio *dequeue_hugetlb_folio_vma(struct hstate *h, struct vm_area_struct *vma, - unsigned long address, int avoid_reserve, - long chg) + unsigned long address, long chg) { struct folio *folio = NULL; struct mempolicy *mpol; @@ -1415,10 +1414,6 @@ static struct folio *dequeue_hugetlb_fol if (!vma_has_reserves(vma, chg) && !available_huge_pages(h)) goto err; - /* If reserves cannot be used, ensure enough pages are in the pool */ - if (avoid_reserve && !available_huge_pages(h)) - goto err; - gfp_mask = htlb_alloc_mask(h); nid = huge_node(vma, address, gfp_mask, &mpol, &nodemask); @@ -1434,7 +1429,7 @@ static struct folio *dequeue_hugetlb_fol folio = dequeue_hugetlb_folio_nodemask(h, gfp_mask, nid, nodemask); - if (folio && !avoid_reserve && vma_has_reserves(vma, chg)) { + if (folio && vma_has_reserves(vma, chg)) { folio_set_hugetlb_restore_reserve(folio); h->resv_huge_pages--; } @@ -3051,17 +3046,6 @@ struct folio *alloc_hugetlb_folio(struct gbl_chg = hugepage_subpool_get_pages(spool, 1); if (gbl_chg < 0) goto out_end_reservation; - - /* - * Even though there was no reservation in the region/reserve - * map, there could be reservations associated with the - * subpool that can be used. This would be indicated if the - * return value of hugepage_subpool_get_pages() is zero. - * However, if avoid_reserve is specified we still avoid even - * the subpool reservations. - */ - if (avoid_reserve) - gbl_chg = 1; } /* If this allocation is not consuming a reservation, charge it now. @@ -3084,7 +3068,7 @@ struct folio *alloc_hugetlb_folio(struct * from the global free pool (global change). gbl_chg == 0 indicates * a reservation exists for the allocation. */ - folio = dequeue_hugetlb_folio_vma(h, vma, addr, avoid_reserve, gbl_chg); + folio = dequeue_hugetlb_folio_vma(h, vma, addr, gbl_chg); if (!folio) { spin_unlock_irq(&hugetlb_lock); folio = alloc_buddy_hugetlb_folio_with_mpol(h, vma, addr); _ Patches currently in -mm which might be from peterx(a)redhat.com are

4 weeks, 1 day

1
0
0 0

[merged mm-stable] maple_tree-simplify-split-calculation.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: maple_tree: simplify split calculation has been removed from the -mm tree. Its filename was maple_tree-simplify-split-calculation.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Wei Yang <richard.weiyang(a)gmail.com> Subject: maple_tree: simplify split calculation Date: Wed, 13 Nov 2024 03:16:14 +0000 Patch series "simplify split calculation", v3. This patch (of 3): The current calculation for splitting nodes tries to enforce a minimum span on the leaf nodes. This code is complex and never worked correctly to begin with, due to the min value being passed as 0 for all leaves. The calculation should just split the data as equally as possible between the new nodes. Note that b_end will be one more than the data, so the left side is still favoured in the calculation. The current code may also lead to a deficient node by not leaving enough data for the right side of the split. This issue is also addressed with the split calculation change. [Liam.Howlett(a)Oracle.com: rephrase the change log] Link: https://lkml.kernel.org/r/20241113031616.10530-1-richard.weiyang@gmail.com Link: https://lkml.kernel.org/r/20241113031616.10530-2-richard.weiyang@gmail.com Fixes: 54a611b60590 ("Maple Tree: add new data structure") Signed-off-by: Wei Yang <richard.weiyang(a)gmail.com> Reviewed-by: Liam R. Howlett <Liam.Howlett(a)Oracle.com> Cc: Sidhartha Kumar <sidhartha.kumar(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/maple_tree.c | 23 ++++++----------------- 1 file changed, 6 insertions(+), 17 deletions(-) --- a/lib/maple_tree.c~maple_tree-simplify-split-calculation +++ a/lib/maple_tree.c @@ -1863,11 +1863,11 @@ static inline int mab_no_null_split(stru * Return: The first split location. The middle split is set in @mid_split. */ static inline int mab_calc_split(struct ma_state *mas, - struct maple_big_node *bn, unsigned char *mid_split, unsigned long min) + struct maple_big_node *bn, unsigned char *mid_split) { unsigned char b_end = bn->b_end; int split = b_end / 2; /* Assume equal split. */ - unsigned char slot_min, slot_count = mt_slots[bn->type]; + unsigned char slot_count = mt_slots[bn->type]; /* * To support gap tracking, all NULL entries are kept together and a node cannot @@ -1900,18 +1900,7 @@ static inline int mab_calc_split(struct split = b_end / 3; *mid_split = split * 2; } else { - slot_min = mt_min_slots[bn->type]; - *mid_split = 0; - /* - * Avoid having a range less than the slot count unless it - * causes one node to be deficient. - * NOTE: mt_min_slots is 1 based, b_end and split are zero. - */ - while ((split < slot_count - 1) && - ((bn->pivot[split] - min) < slot_count - 1) && - (b_end - split > slot_min)) - split++; } /* Avoid ending a node on a NULL entry */ @@ -2377,7 +2366,7 @@ static inline struct maple_enode static inline unsigned char mas_mab_to_node(struct ma_state *mas, struct maple_big_node *b_node, struct maple_enode **left, struct maple_enode **right, struct maple_enode **middle, - unsigned char *mid_split, unsigned long min) + unsigned char *mid_split) { unsigned char split = 0; unsigned char slot_count = mt_slots[b_node->type]; @@ -2390,7 +2379,7 @@ static inline unsigned char mas_mab_to_n if (b_node->b_end < slot_count) { split = b_node->b_end; } else { - split = mab_calc_split(mas, b_node, mid_split, min); + split = mab_calc_split(mas, b_node, mid_split); *right = mas_new_ma_node(mas, b_node); } @@ -2877,7 +2866,7 @@ static void mas_spanning_rebalance(struc mast->bn->b_end--; mast->bn->type = mte_node_type(mast->orig_l->node); split = mas_mab_to_node(mas, mast->bn, &left, &right, &middle, - &mid_split, mast->orig_l->min); + &mid_split); mast_set_split_parents(mast, left, middle, right, split, mid_split); mast_cp_to_nodes(mast, left, middle, right, split, mid_split); @@ -3365,7 +3354,7 @@ static void mas_split(struct ma_state *m if (mas_push_data(mas, height, &mast, false)) break; - split = mab_calc_split(mas, b_node, &mid_split, prev_l_mas.min); + split = mab_calc_split(mas, b_node, &mid_split); mast_split_data(&mast, mas, split); /* * Usually correct, mab_mas_cp in the above call overwrites _ Patches currently in -mm which might be from richard.weiyang(a)gmail.com are

4 weeks, 1 day

1
0
0 0

Re: Patch "drm/xe/oa: Separate batch submission from waiting for completion" has been added to the 6.12-stable tree

by Dixit, Ashutosh

On Mon, 13 Jan 2025 06:03:53 -0800, Sasha Levin wrote: > Hello Sasha, > This is a note to let you know that I've just added the patch titled > > drm/xe/oa: Separate batch submission from waiting for completion > > to the 6.12-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: > drm-xe-oa-separate-batch-submission-from-waiting-for.patch > and it can be found in the queue-6.12 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. I am writing about 3 emails I received (including this one) about 3 commits being added to stable. These are the 3 commits I am referring to (all commit SHA's refer to Linus' tree and first commit is at the bottom, everywhere in this email): 2fb4350a283af drm/xe/oa: Add input fence dependencies c8507a25cebd1 drm/xe/oa/uapi: Define and parse OA sync properties dddcb19ad4d4b drm/xe/oa: Separate batch submission from waiting for completion So none of these commits had any "Fixes:" tag or "Cc: stable" so not sure why they are being added to stable. Also, they are part of a 7 commit series so not sure why only 3 of the 7 commits are being added to stable? In addition, for this commit which is also added to stable: f0ed39830e606 xe/oa: Fix query mode of operation for OAR/OAC We modified this commit for stable because it will otherwise with the previous 3 commits mentioned above, which we were assuming would not be in stable. Now, if we want all these commits in stable (I actually prefer it), we should just pick them straight from Linus' tree. This would be all these commits: f0ed39830e606 xe/oa: Fix query mode of operation for OAR/OAC c0403e4ceecae drm/xe/oa: Fix "Missing outer runtime PM protection" warning 85d3f9e84e062 drm/xe/oa: Allow only certain property changes from config 9920c8b88c5cf drm/xe/oa: Add syncs support to OA config ioctl cc4e6994d5a23 drm/xe/oa: Move functions up so they can be reused for config ioctl 343dd246fd9b5 drm/xe/oa: Signal output fences 2fb4350a283af drm/xe/oa: Add input fence dependencies c8507a25cebd1 drm/xe/oa/uapi: Define and parse OA sync properties dddcb19ad4d4b drm/xe/oa: Separate batch submission from waiting for completion So: we should either drop the 3 patches at the top, or just pick all 9 patches above. Doing the latter will probably be the simplest and I don't expect any conflicts, or if there are, I can help to resolve those. The above list can be generated by running the following in Linus' tree: git log --oneline -- drivers/gpu/drm/xe/xe_oa.c Thanks. -- Ashutosh > > > > commit 9aeced687e728b9de067a502a0780f8029e61763 > Author: Ashutosh Dixit <ashutosh.dixit(a)intel.com> > Date: Tue Oct 22 13:03:46 2024 -0700 > > drm/xe/oa: Separate batch submission from waiting for completion > > [ Upstream commit dddcb19ad4d4bbe943a72a1fb3266c6e8aa8d541 ] > > When we introduce xe_syncs, we don't wait for internal OA programming > batches to complete. That is, xe_syncs are signaled asynchronously. In > anticipation for this, separate out batch submission from waiting for > completion of those batches. > > v2: Change return type of xe_oa_submit_bb to "struct dma_fence *" (Matt B) > v3: Retain init "int err = 0;" in xe_oa_submit_bb (Jose) > > Reviewed-by: Jonathan Cavitt <jonathan.cavitt(a)intel.com> > Signed-off-by: Ashutosh Dixit <ashutosh.dixit(a)intel.com> > Link: https://patchwork.freedesktop.org/patch/msgid/20241022200352.1192560-2-ashu… > Stable-dep-of: f0ed39830e60 ("xe/oa: Fix query mode of operation for OAR/OAC") > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/gpu/drm/xe/xe_oa.c b/drivers/gpu/drm/xe/xe_oa.c > index 78823f53d290..4962c9eb9a81 100644 > --- a/drivers/gpu/drm/xe/xe_oa.c > +++ b/drivers/gpu/drm/xe/xe_oa.c > @@ -567,11 +567,10 @@ static __poll_t xe_oa_poll(struct file *file, poll_table *wait) > return ret; > } > > -static int xe_oa_submit_bb(struct xe_oa_stream *stream, struct xe_bb *bb) > +static struct dma_fence *xe_oa_submit_bb(struct xe_oa_stream *stream, struct xe_bb *bb) > { > struct xe_sched_job *job; > struct dma_fence *fence; > - long timeout; > int err = 0; > > /* Kernel configuration is issued on stream->k_exec_q, not stream->exec_q */ > @@ -585,14 +584,9 @@ static int xe_oa_submit_bb(struct xe_oa_stream *stream, struct xe_bb *bb) > fence = dma_fence_get(&job->drm.s_fence->finished); > xe_sched_job_push(job); > > - timeout = dma_fence_wait_timeout(fence, false, HZ); > - dma_fence_put(fence); > - if (timeout < 0) > - err = timeout; > - else if (!timeout) > - err = -ETIME; > + return fence; > exit: > - return err; > + return ERR_PTR(err); > } > > static void write_cs_mi_lri(struct xe_bb *bb, const struct xe_oa_reg *reg_data, u32 n_regs) > @@ -656,6 +650,7 @@ static void xe_oa_store_flex(struct xe_oa_stream *stream, struct xe_lrc *lrc, > static int xe_oa_modify_ctx_image(struct xe_oa_stream *stream, struct xe_lrc *lrc, > const struct flex *flex, u32 count) > { > + struct dma_fence *fence; > struct xe_bb *bb; > int err; > > @@ -667,7 +662,16 @@ static int xe_oa_modify_ctx_image(struct xe_oa_stream *stream, struct xe_lrc *lr > > xe_oa_store_flex(stream, lrc, bb, flex, count); > > - err = xe_oa_submit_bb(stream, bb); > + fence = xe_oa_submit_bb(stream, bb); > + if (IS_ERR(fence)) { > + err = PTR_ERR(fence); > + goto free_bb; > + } > + xe_bb_free(bb, fence); > + dma_fence_put(fence); > + > + return 0; > +free_bb: > xe_bb_free(bb, NULL); > exit: > return err; > @@ -675,6 +679,7 @@ static int xe_oa_modify_ctx_image(struct xe_oa_stream *stream, struct xe_lrc *lr > > static int xe_oa_load_with_lri(struct xe_oa_stream *stream, struct xe_oa_reg *reg_lri) > { > + struct dma_fence *fence; > struct xe_bb *bb; > int err; > > @@ -686,7 +691,16 @@ static int xe_oa_load_with_lri(struct xe_oa_stream *stream, struct xe_oa_reg *re > > write_cs_mi_lri(bb, reg_lri, 1); > > - err = xe_oa_submit_bb(stream, bb); > + fence = xe_oa_submit_bb(stream, bb); > + if (IS_ERR(fence)) { > + err = PTR_ERR(fence); > + goto free_bb; > + } > + xe_bb_free(bb, fence); > + dma_fence_put(fence); > + > + return 0; > +free_bb: > xe_bb_free(bb, NULL); > exit: > return err; > @@ -914,15 +928,32 @@ static int xe_oa_emit_oa_config(struct xe_oa_stream *stream, struct xe_oa_config > { > #define NOA_PROGRAM_ADDITIONAL_DELAY_US 500 > struct xe_oa_config_bo *oa_bo; > - int err, us = NOA_PROGRAM_ADDITIONAL_DELAY_US; > + int err = 0, us = NOA_PROGRAM_ADDITIONAL_DELAY_US; > + struct dma_fence *fence; > + long timeout; > > + /* Emit OA configuration batch */ > oa_bo = xe_oa_alloc_config_buffer(stream, config); > if (IS_ERR(oa_bo)) { > err = PTR_ERR(oa_bo); > goto exit; > } > > - err = xe_oa_submit_bb(stream, oa_bo->bb); > + fence = xe_oa_submit_bb(stream, oa_bo->bb); > + if (IS_ERR(fence)) { > + err = PTR_ERR(fence); > + goto exit; > + } > + > + /* Wait till all previous batches have executed */ > + timeout = dma_fence_wait_timeout(fence, false, 5 * HZ); > + dma_fence_put(fence); > + if (timeout < 0) > + err = timeout; > + else if (!timeout) > + err = -ETIME; > + if (err) > + drm_dbg(&stream->oa->xe->drm, "dma_fence_wait_timeout err %d\n", err); > > /* Additional empirical delay needed for NOA programming after registers are written */ > usleep_range(us, 2 * us);

4 weeks, 1 day

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2025