December 2024 - Linux-stable-mirror

[PATCH v2 1/1] mtd: spi-nor: core: replace dummy buswidth from addr to data

by Cheng Ming Lin

From: Cheng Ming Lin <chengminglin(a)mxic.com.tw> The default dummy cycle for Macronix SPI NOR flash in Octal Output Read Mode(1-1-8) is 20. Currently, the dummy buswidth is set according to the address bus width. In the 1-1-8 mode, this means the dummy buswidth is 1. When converting dummy cycles to bytes, this results in 20 x 1 / 8 = 2 bytes, causing the host to read data 4 cycles too early. Since the protocol data buswidth is always greater than or equal to the address buswidth. Setting the dummy buswidth to match the data buswidth increases the likelihood that the dummy cycle-to-byte conversion will be divisible, preventing the host from reading data prematurely. Fixes: 0e30f47232ab5 ("mtd: spi-nor: add support for DTR protocol") Cc: stable(a)vger.kernel.org Reviewd-by: Pratyush Yadav <pratyush(a)kernel.org> Signed-off-by: Cheng Ming Lin <chengminglin(a)mxic.com.tw> --- drivers/mtd/spi-nor/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index f9c189ed7353..c7aceaa8a43f 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -89,7 +89,7 @@ void spi_nor_spimem_setup_op(const struct spi_nor *nor, op->addr.buswidth = spi_nor_get_protocol_addr_nbits(proto); if (op->dummy.nbytes) - op->dummy.buswidth = spi_nor_get_protocol_addr_nbits(proto); + op->dummy.buswidth = spi_nor_get_protocol_data_nbits(proto); if (op->data.nbytes) op->data.buswidth = spi_nor_get_protocol_data_nbits(proto); -- 2.25.1

11 months

6
10
0 0

[PATCH v2] hfs/hfsplus: fix slab-out-of-bounds in hfs_bnode_read_key

by Vasiliy Kovalev

Syzbot reported an issue in hfs subsystem: BUG: KASAN: slab-out-of-bounds in memcpy_from_page include/linux/highmem.h:423 [inline] BUG: KASAN: slab-out-of-bounds in hfs_bnode_read fs/hfs/bnode.c:35 [inline] BUG: KASAN: slab-out-of-bounds in hfs_bnode_read_key+0x314/0x450 fs/hfs/bnode.c:70 Write of size 94 at addr ffff8880123cd100 by task syz-executor237/5102 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 memcpy_from_page include/linux/highmem.h:423 [inline] hfs_bnode_read fs/hfs/bnode.c:35 [inline] hfs_bnode_read_key+0x314/0x450 fs/hfs/bnode.c:70 hfs_brec_insert+0x7f3/0xbd0 fs/hfs/brec.c:159 hfs_cat_create+0x41d/0xa50 fs/hfs/catalog.c:118 hfs_mkdir+0x6c/0xe0 fs/hfs/dir.c:232 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdir fs/namei.c:4300 [inline] __se_sys_mkdir fs/namei.c:4298 [inline] __x64_sys_mkdir+0x6c/0x80 fs/namei.c:4298 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fbdd6057a99 Add validation for key length in hfs_bnode_read_key to prevent out-of-bounds memory access. Invalid key lengths, likely caused by corrupted file system images (potentially due to malformed data during image generation), now result in clearing the key buffer, enhancing stability and reliability. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+5f3a973ed3dfb85a6683(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5f3a973ed3dfb85a6683 Cc: stable(a)vger.kernel.org Signed-off-by: Vasiliy Kovalev <kovalev(a)altlinux.org> --- v2: add more information to the commit message regarding the purpose of the patch. --- fs/hfs/bnode.c | 6 ++++++ fs/hfsplus/bnode.c | 6 ++++++ 2 files changed, 12 insertions(+) diff --git a/fs/hfs/bnode.c b/fs/hfs/bnode.c index 6add6ebfef8967..cb823a8a6ba960 100644 --- a/fs/hfs/bnode.c +++ b/fs/hfs/bnode.c @@ -67,6 +67,12 @@ void hfs_bnode_read_key(struct hfs_bnode *node, void *key, int off) else key_len = tree->max_key_len + 1; + if (key_len > sizeof(hfs_btree_key) || key_len < 1) { + memset(key, 0, sizeof(hfs_btree_key)); + pr_err("hfs: Invalid key length: %d\n", key_len); + return; + } + hfs_bnode_read(node, key, off, key_len); } diff --git a/fs/hfsplus/bnode.c b/fs/hfsplus/bnode.c index 87974d5e679156..079ea80534f7de 100644 --- a/fs/hfsplus/bnode.c +++ b/fs/hfsplus/bnode.c @@ -67,6 +67,12 @@ void hfs_bnode_read_key(struct hfs_bnode *node, void *key, int off) else key_len = tree->max_key_len + 2; + if (key_len > sizeof(hfsplus_btree_key) || key_len < 1) { + memset(key, 0, sizeof(hfsplus_btree_key)); + pr_err("hfsplus: Invalid key length: %d\n", key_len); + return; + } + hfs_bnode_read(node, key, off, key_len); } -- 2.33.8

11 months

2
2
0 0

[PATCH 1/2] alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled

by Suren Baghdasaryan

When memory allocation profiling is disabled there is no need to update current->alloc_tag and these manipulations add unnecessary overhead. Fix the overhead by skipping these extra updates. Fixes: b951aaff5035 ("mm: enable page allocation tagging") Signed-off-by: Suren Baghdasaryan <surenb(a)google.com> Cc: stable(a)vger.kernel.org --- include/linux/alloc_tag.h | 11 ++++++++--- lib/alloc_tag.c | 2 ++ 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/include/linux/alloc_tag.h b/include/linux/alloc_tag.h index 0bbbe537c5f9..a946e0203e6d 100644 --- a/include/linux/alloc_tag.h +++ b/include/linux/alloc_tag.h @@ -224,9 +224,14 @@ static inline void alloc_tag_sub(union codetag_ref *ref, size_t bytes) {} #define alloc_hooks_tag(_tag, _do_alloc) \ ({ \ - struct alloc_tag * __maybe_unused _old = alloc_tag_save(_tag); \ - typeof(_do_alloc) _res = _do_alloc; \ - alloc_tag_restore(_tag, _old); \ + typeof(_do_alloc) _res; \ + if (mem_alloc_profiling_enabled()) { \ + struct alloc_tag * __maybe_unused _old; \ + _old = alloc_tag_save(_tag); \ + _res = _do_alloc; \ + alloc_tag_restore(_tag, _old); \ + } else \ + _res = _do_alloc; \ _res; \ }) diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c index 7dcebf118a3e..4c373f444eb1 100644 --- a/lib/alloc_tag.c +++ b/lib/alloc_tag.c @@ -29,6 +29,8 @@ EXPORT_SYMBOL(_shared_alloc_tag); DEFINE_STATIC_KEY_MAYBE(CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT, mem_alloc_profiling_key); +EXPORT_SYMBOL(mem_alloc_profiling_key); + DEFINE_STATIC_KEY_FALSE(mem_profiling_compressed); struct alloc_tag_kernel_section kernel_tags = { NULL, 0 }; base-commit: 431614f1580a03c1a653340c55ea76bd12a9403f -- 2.47.1.613.gc27f4b7a9f-goog

11 months

3
14
0 0

[PATCH v3] usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs

by Krishna Kurapati

It is observed sometimes when tethering is used over NCM with Windows 11 as host, at some instances, the gadget_giveback has one byte appended at the end of a proper NTB. When the NTB is parsed, unwrap call looks for any leftover bytes in SKB provided by u_ether and if there are any pending bytes, it treats them as a separate NTB and parses it. But in case the second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that were parsed properly in the first NTB and saved in rx_list are dropped. Adding a few custom traces showed the following: [002] d..1 7828.532866: dwc3_gadget_giveback: ep1out: req 000000003868811a length 1025/16384 zsI ==> 0 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10 [002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames In this case, the giveback is of 1025 bytes and block length is 1024. The rest 1 byte (which is 0x00) won't be parsed resulting in drop of all datagrams in rx_list. Same is case with packets of size 2048: [002] d..1 7828.557948: dwc3_gadget_giveback: ep1out: req 0000000011dfd96e length 2049/16384 zsI ==> 0 [002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800 Lecroy shows one byte coming in extra confirming that the byte is coming in from PC: Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590) - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590) --- Packet 4063861 Data(1024 bytes) Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590) --- Packet 4063863 Data(1 byte) Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722) According to Windows driver, no ZLP is needed if wBlockLength is non-zero, because the non-zero wBlockLength has already told the function side the size of transfer to be expected. However, there are in-market NCM devices that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize. To deal with such devices, it pads an extra 0 at end so the transfer is no longer multiple of wMaxPacketSize. Cc: <stable(a)vger.kernel.org> Fixes: 9f6ce4240a2b ("usb: gadget: f_ncm.c added") Signed-off-by: Krishna Kurapati <quic_kriskura(a)quicinc.com> --- Link to v2: https://lore.kernel.org/all/20240131150332.1326523-1-quic_kriskura@quicinc.… Changes in v2: Added check to see if the padded byte is 0x00. Changes in v3: Removed wMaxPacketSize check from v2. drivers/usb/gadget/function/f_ncm.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/f_ncm.c b/drivers/usb/gadget/function/f_ncm.c index ca5d5f564998..e2a059cfda2c 100644 --- a/drivers/usb/gadget/function/f_ncm.c +++ b/drivers/usb/gadget/function/f_ncm.c @@ -1338,7 +1338,15 @@ static int ncm_unwrap_ntb(struct gether *port, "Parsed NTB with %d frames\n", dgram_counter); to_process -= block_len; - if (to_process != 0) { + + /* + * Windows NCM driver avoids USB ZLPs by adding a 1-byte + * zero pad as needed. + */ + if (to_process == 1 && + (*(unsigned char *)(ntb_ptr + block_len) == 0x00)) { + to_process--; + } else if (to_process > 0) { ntb_ptr = (unsigned char *)(ntb_ptr + block_len); goto parse_ntb; } -- 2.34.1

11 months

3
9
0 0

[PATCH] scsi: st: Regression fix: Don't set pos_unknown just after device recognition

by Kai Mäkisara

Commit 9604eea5bd3a ("scsi: st: Add third party poweron reset handling") in v6.6 added new code to handle the Power On/Reset Unit Attention (POR UA) sense data. This was in addition to the existing method. When this Unit Attention is received, the driver blocks attempts to read, write and some other operations because the reset may have rewinded the tape. Because of the added code, also the initial POR UA resulted in blocking operations, including those that are used to set the driver options after the device is recognized. Also, reading and writing are refused, whereas they succeeded before this commit. This patch adds code to not set pos_unknown to block operations if the POR UA is received from the first test_ready() call after the st device has been created. This restores the behavior before v6.6. Signed-off-by: Kai Mäkisara <Kai.Makisara(a)kolumbus.fi> Fixes: 9604eea5bd3a ("scsi: st: Add third party poweron reset handling") Closes: https://lore.kernel.org/linux-scsi/2201CF73-4795-4D3B-9A79-6EE5215CF58D@kol… CC: stable(a)vger.kernel.org --- drivers/scsi/st.c | 6 ++++++ drivers/scsi/st.h | 1 + 2 files changed, 7 insertions(+) diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c index e8ef27d7ef61..ebbd50ec0cda 100644 --- a/drivers/scsi/st.c +++ b/drivers/scsi/st.c @@ -1030,6 +1030,11 @@ static int test_ready(struct scsi_tape *STp, int do_wait) retval = new_session ? CHKRES_NEW_SESSION : CHKRES_READY; break; } + if (STp->first_tur) { + /* Don't set pos_unknown right after device recognition */ + STp->pos_unknown = 0; + STp->first_tur = 0; + } if (SRpnt != NULL) st_release_request(SRpnt); @@ -4328,6 +4333,7 @@ static int st_probe(struct device *dev) blk_queue_rq_timeout(tpnt->device->request_queue, ST_TIMEOUT); tpnt->long_timeout = ST_LONG_TIMEOUT; tpnt->try_dio = try_direct_io; + tpnt->first_tur = 1; for (i = 0; i < ST_NBR_MODES; i++) { STm = &(tpnt->modes[i]); diff --git a/drivers/scsi/st.h b/drivers/scsi/st.h index 7a68eaba7e81..1aaaf5369a40 100644 --- a/drivers/scsi/st.h +++ b/drivers/scsi/st.h @@ -170,6 +170,7 @@ struct scsi_tape { unsigned char rew_at_close; /* rewind necessary at close */ unsigned char inited; unsigned char cleaning_req; /* cleaning requested? */ + unsigned char first_tur; /* first TEST UNIT READY */ int block_size; int min_block; int max_block; -- 2.43.0

11 months

4
4
0 0

[PATCH] selftests/rseq: Fix rseq for cases without glibc support

by Raghavendra Rao Ananta

Currently the rseq constructor, rseq_init(), assumes that glibc always has the support for rseq symbols (__rseq_size for instance). However, glibc supports rseq from version 2.35 onwards. As a result, for the systems that run glibc less than 2.35, the global rseq_size remains initialized to -1U. When a thread then tries to register for rseq, get_rseq_min_alloc_size() would end up returning -1U, which is incorrect. Hence, initialize rseq_size for the cases where glibc doesn't have the support for rseq symbols. Cc: stable(a)vger.kernel.org Fixes: 73a4f5a704a2 ("selftests/rseq: Fix mm_cid test failure") Signed-off-by: Raghavendra Rao Ananta <rananta(a)google.com> --- tools/testing/selftests/rseq/rseq.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/tools/testing/selftests/rseq/rseq.c b/tools/testing/selftests/rseq/rseq.c index 5b9772cdf265..9eb5356f25fa 100644 --- a/tools/testing/selftests/rseq/rseq.c +++ b/tools/testing/selftests/rseq/rseq.c @@ -142,6 +142,16 @@ unsigned int get_rseq_kernel_feature_size(void) return ORIG_RSEQ_FEATURE_SIZE; } +static void set_default_rseq_size(void) +{ + unsigned int rseq_kernel_feature_size = get_rseq_kernel_feature_size(); + + if (rseq_kernel_feature_size < ORIG_RSEQ_ALLOC_SIZE) + rseq_size = rseq_kernel_feature_size; + else + rseq_size = ORIG_RSEQ_ALLOC_SIZE; +} + int rseq_register_current_thread(void) { int rc; @@ -219,12 +229,7 @@ void rseq_init(void) fallthrough; case ORIG_RSEQ_ALLOC_SIZE: { - unsigned int rseq_kernel_feature_size = get_rseq_kernel_feature_size(); - - if (rseq_kernel_feature_size < ORIG_RSEQ_ALLOC_SIZE) - rseq_size = rseq_kernel_feature_size; - else - rseq_size = ORIG_RSEQ_ALLOC_SIZE; + set_default_rseq_size(); break; } default: @@ -239,8 +244,10 @@ void rseq_init(void) rseq_size = 0; return; } + rseq_offset = (void *)&__rseq_abi - rseq_thread_pointer(); rseq_flags = 0; + set_default_rseq_size(); } static __attribute__((destructor)) base-commit: 40384c840ea1944d7c5a392e8975ed088ecf0b37 -- 2.47.0.338.g60cca15819-goog

11 months

3
4
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>

11 months

3
3
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

11 months

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(-)

11 months

2
1
0 0

[PATCH] wifi: mac80211: fix interger overflow in hwmp_route_info_get()

by Gavrilov Ilia

Since the new_metric and last_hop_metric variables can reach the MAX_METRIC(0xffffffff) value, an integer overflow may occur when multiplying them by 10/9. It can lead to incorrect behavior. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE. Fixes: a8d418d9ac25 ("mac80211: mesh: only switch path when new metric is at least 10% better") Cc: stable(a)vger.kernel.org Signed-off-by: Ilia Gavrilov <Ilia.Gavrilov(a)infotecs.ru> --- net/mac80211/mesh_hwmp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c index 4e9546e998b6..7d367ff1efc2 100644 --- a/net/mac80211/mesh_hwmp.c +++ b/net/mac80211/mesh_hwmp.c @@ -458,7 +458,7 @@ static u32 hwmp_route_info_get(struct ieee80211_sub_if_data *sdata, (mpath->sn == orig_sn && (rcu_access_pointer(mpath->next_hop) != sta ? - mult_frac(new_metric, 10, 9) : + mult_frac((u64)new_metric, 10, 9) : new_metric) >= mpath->metric)) { process = false; fresh_info = false; @@ -533,7 +533,7 @@ static u32 hwmp_route_info_get(struct ieee80211_sub_if_data *sdata, if ((mpath->flags & MESH_PATH_FIXED) || ((mpath->flags & MESH_PATH_ACTIVE) && ((rcu_access_pointer(mpath->next_hop) != sta ? - mult_frac(last_hop_metric, 10, 9) : + mult_frac((u64)last_hop_metric, 10, 9) : last_hop_metric) > mpath->metric))) fresh_info = false; } else { -- 2.39.5

11 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024