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

[PATCH] bcache: call bio_endio() to replace directly calling bio->bi_end_io()

by colyli＠fnnas.com

From: Coly Li <colyli(a)fnnas.com> When a bcache device is not attached to a cache device, current code calls the request's bi_end_io() callback directly. The correct method is to call bio_endio(bio) instead of bio->bi_end_io(bio). This patch fixes the incorrect calling. Fixes: bc082a55d25c ("bcache: fix inaccurate io state for detached bcache devices") Fixes: 40f567bbb3b0 ("md: bcache: check the return value of kzalloc() in detached_dev_do_request()") Reported-by: Shida Zhang <zhangshida(a)kylinos.cn> Closes: https://lore.kernel.org/linux-block/20251121081748.1443507-1-zhangshida@kyl… Cc: Christoph Hellwig <hch(a)infradead.org> Cc: Jia-Ju Bai <baijiaju1990(a)gmail.com> Cc: stable(a)vger.kernel.org #4.17+ Signed-off-by: Coly Li <colyli(a)fnnas.com> --- drivers/md/bcache/request.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c index af345dc6fde1..7b815064db54 100644 --- a/drivers/md/bcache/request.c +++ b/drivers/md/bcache/request.c @@ -1104,7 +1104,7 @@ static void detached_dev_end_io(struct bio *bio) } kfree(ddip); - bio->bi_end_io(bio); + bio_endio(bio); } static void detached_dev_do_request(struct bcache_device *d, struct bio *bio, @@ -1121,7 +1121,7 @@ static void detached_dev_do_request(struct bcache_device *d, struct bio *bio, ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO); if (!ddip) { bio->bi_status = BLK_STS_RESOURCE; - bio->bi_end_io(bio); + bio_endio(bio); return; } @@ -1136,7 +1136,7 @@ static void detached_dev_do_request(struct bcache_device *d, struct bio *bio, if ((bio_op(bio) == REQ_OP_DISCARD) && !bdev_max_discard_sectors(dc->bdev)) - bio->bi_end_io(bio); + bio_endio(bio); else submit_bio_noacct(bio); } -- 2.47.3

2 days, 16 hours

1
0
0 0

[PATCH] counter: interrupt-cnt: Drop IRQF_NO_THREAD flag

by A. Sverdlin

From: Alexander Sverdlin <alexander.sverdlin(a)siemens.com> An IRQ handler can either be IRQF_NO_THREAD or acquire spinlock_t, as CONFIG_PROVE_RAW_LOCK_NESTING warns: ============================= [ BUG: Invalid wait context ] 6.18.0-rc1+git... #1 ----------------------------- some-user-space-process/1251 is trying to lock: (&counter->events_list_lock){....}-{3:3}, at: counter_push_event [counter] other info that might help us debug this: context-{2:2} no locks held by some-user-space-process/.... stack backtrace: CPU: 0 UID: 0 PID: 1251 Comm: some-user-space-process 6.18.0-rc1+git... #1 PREEMPT Call trace: show_stack (C) dump_stack_lvl dump_stack __lock_acquire lock_acquire _raw_spin_lock_irqsave counter_push_event [counter] interrupt_cnt_isr [interrupt_cnt] __handle_irq_event_percpu handle_irq_event handle_simple_irq handle_irq_desc generic_handle_domain_irq gpio_irq_handler handle_irq_desc generic_handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler el0_interrupt __el0_irq_handler_common el0t_64_irq_handler el0t_64_irq ... and Sebastian correctly points out. Remove IRQF_NO_THREAD as an alternative to switching to raw_spinlock_t, because the latter would limit all potential nested locks to raw_spinlock_t only. Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20251117151314.xwLAZrWY@linutronix.de/ Fixes: a55ebd47f21f ("counter: add IRQ or GPIO based counter") Signed-off-by: Alexander Sverdlin <alexander.sverdlin(a)siemens.com> --- drivers/counter/interrupt-cnt.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/counter/interrupt-cnt.c b/drivers/counter/interrupt-cnt.c index 6c0c1d2d7027d..e6100b5fb082e 100644 --- a/drivers/counter/interrupt-cnt.c +++ b/drivers/counter/interrupt-cnt.c @@ -229,8 +229,7 @@ static int interrupt_cnt_probe(struct platform_device *pdev) irq_set_status_flags(priv->irq, IRQ_NOAUTOEN); ret = devm_request_irq(dev, priv->irq, interrupt_cnt_isr, - IRQF_TRIGGER_RISING | IRQF_NO_THREAD, - dev_name(dev), counter); + IRQF_TRIGGER_RISING, dev_name(dev), counter); if (ret) return ret; -- 2.51.1

2 days, 17 hours

5
6
0 0

[PATCH] fs: ocfs2: fix kernel BUG in ocfs2_find_victim_chain

by Prithvi Tambewagh

syzbot reported a kernel BUG in ocfs2_find_victim_chain() because the `cl_next_free_rec` field of the allocation chain list is 0, triggring the BUG_ON(!cl->cl_next_free_rec) condition and panicking the kernel. To fix this, `cl_next_free_rec` is checked inside the caller of ocfs2_find_victim_chain() i.e. ocfs2_claim_suballoc_bits() and if it is equal to 0, ocfs2_error() is called, to log the corruption and force the filesystem into read-only mode, to prevent further damage. Reported-by: syzbot+96d38c6e1655c1420a72(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=96d38c6e1655c1420a72 Tested-by: syzbot+96d38c6e1655c1420a72(a)syzkaller.appspotmail.com Cc: stable(a)vger.kernel.org Signed-off-by: Prithvi Tambewagh <activprithvi(a)gmail.com> --- fs/ocfs2/suballoc.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/ocfs2/suballoc.c b/fs/ocfs2/suballoc.c index 6ac4dcd54588..84bb2d11c2aa 100644 --- a/fs/ocfs2/suballoc.c +++ b/fs/ocfs2/suballoc.c @@ -1993,6 +1993,13 @@ static int ocfs2_claim_suballoc_bits(struct ocfs2_alloc_context *ac, cl = (struct ocfs2_chain_list *) &fe->id2.i_chain; + if (le16_to_cpu(cl->cl_next_free_rec) == 0) { + status = ocfs2_error(ac->ac_inode->i_sb, + "Chain allocator dinode %llu has 0 chains\n", + (unsigned long long)le64_to_cpu(fe->i_blkno)); + goto bail; + } + victim = ocfs2_find_victim_chain(cl); ac->ac_chain = victim; base-commit: 939f15e640f193616691d3bcde0089760e75b0d3 -- 2.34.1

2 days, 21 hours

1
0
0 0

[PATCH] fs: ocfs2: fix kernel BUG in ocfs2_find_victim_chain

by Prithvi Tambewagh

syzbot reported a kernel BUG in ocfs2_find_victim_chain() because the `cl_next_free_rec` field of the allocation chain list is 0, triggring the BUG_ON(!cl->cl_next_free_rec) condition and panicking the kernel. To fix this, `cl_next_free_rec` is checked inside the caller of ocfs2_find_victim_chain() i.e. ocfs2_claim_suballoc_bits() and if it is equal to 0, ocfs2_error() is called, to log the corruption and force the filesystem into read-only mode, to prevent further damage. Reported-by: syzbot+96d38c6e1655c1420a72(a)syzkaller.appspotmail.com Tested-by: syzbot+96d38c6e1655c1420a72(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=96d38c6e1655c1420a72 Cc: stable(a)vger.kernel.org Signed-off-by: Prithvi Tambewagh <activprithvi(a)gmail.com> --- fs/ocfs2/suballoc.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/ocfs2/suballoc.c b/fs/ocfs2/suballoc.c index 6ac4dcd54588..c7eb6efc00b4 100644 --- a/fs/ocfs2/suballoc.c +++ b/fs/ocfs2/suballoc.c @@ -1993,6 +1993,13 @@ static int ocfs2_claim_suballoc_bits(struct ocfs2_alloc_context *ac, cl = (struct ocfs2_chain_list *) &fe->id2.i_chain; + if( le16_to_cpu(cl->cl_next_free_rec) == 0) { + status = ocfs2_error(ac->ac_inode->i_sb, + "Chain allocator dinode %llu has 0 chains\n", + (unsigned long long)le64_to_cpu(fe->i_blkno)); + goto bail; + } + victim = ocfs2_find_victim_chain(cl); ac->ac_chain = victim; base-commit: 939f15e640f193616691d3bcde0089760e75b0d3 -- 2.34.1

2 days, 21 hours

1
0
0 0

👉 DUOONE OLED SPAN/FOLD Launch — Black Friday & Cyber Monday Rewards on Kickstarter🎉

by InnLead Innovative

👉 DUOONE OLED SPAN/FOLD Launch — Black Friday & Cyber Monday Rewards on Kickstarter🎉 Multiplayer Gaming, Dual Fun & Work | OLED | Duel & Tabletop Games | 1ms Respones Time ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ We need your feedback! Having trouble seeing this email? View it online ( https://eeenew.com/index.php/component/acym/archive/93-duoone-oled-span-fol… ) ‍DUOONE OLED SPAN/FOLD Multiplayer Gaming, Dual Fun & Work! Live on Kickstarter ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) Hi there, Experience dual OLED touchscreens built for multiplayer gaming and next-level productivity. With 4-input connectivity and multi-display modes, it works seamlessly with PC, Mac, NS, Android, DeX, Xbox, PS, and handheld consoles. Double the screens. Double the power. Double the fun. 👉Back us on Kickstarter and unlock exclusive launch rewards! ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) 👉 Back DUOONE OLED on Kickstarter ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) For work. For play. For everyone. Multiplayer gaming + productivity in one device Board Game - Revolutionize Traditional Gaming on a Stunning OLED Screen! Infinity Game Table-Limitless Gaming with Endless Content and Digital Magic! ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) VS Opponent Gaming Table - Challenge Friends Head-to-Head on Dual Displays! ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) At just 2.3 lbs. Ultra-portable design to bring your gaming, work, and fun wherever you go Book Mode-Book lover, Literary enthusiast, Bibliophile Graphic design, Photo editing, and Professional content creation ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) Experience epic multiplayer gaming, seamless multitasking, and stunning OLED brilliance. ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) 👉Don’t miss out — Claim your Black Friday & Cyber Monday rewards on Kickstarter!🎉 ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) We’re truly grateful to have you with us. Let’s build something remarkable together — see you on Kickstarter for the next big step. Best, InnLead Innovative Unsubscribe ( https://eeenew.com/index.php/component/acym/frontusers/unsubscribe/93-duoon… )

2 days, 22 hours

1
0
0 0

Re: Patch "mptcp: Fix proto fallback detection with BPF" has been added to the 6.1-stable tree

by Matthieu Baerts

Hi Greg, Sasha, Jiayuan, On 27/11/2025 14:41, gregkh(a)linuxfoundation.org wrote: > > This is a note to let you know that I've just added the patch titled > > mptcp: Fix proto fallback detection with BPF > > to the 6.1-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: > mptcp-fix-proto-fallback-detection-with-bpf.patch > and it can be found in the queue-6.1 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. @Sasha: thank you for having resolved the conflicts for this patch (and many others related to MPTCP recently). Sadly, it is causing troubles. @Greg/Sasha: is it possible to remove it from 6.1, 5.15 and 5.10 queues please? (The related patch in 6.6 and above is OK) @Jiayuan: did you not specify you initially saw this issue on a v6.1 kernel? By chance, do you already have a fix for that version? Cheers, Matt -- Sponsored by the NGI0 Core fund.

3 days, 4 hours

3
2
0 0

[PATCH] RDMA/cm: Fix leaking the multicast GID table reference

by Jason Gunthorpe

If the CM ID is destroyed while the CM event for multicast creating is still queued the cancel_work_sync() will prevent the work from running which also prevents destroying the ah_attr. This leaks a refcount and triggers a WARN: GID entry ref leak for dev syz1 index 2 ref=573 WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline] WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886 Destroy the ah_attr after canceling the work, it is safe to call this twice. Cc: stable(a)vger.kernel.org Fixes: fe454dc31e84 ("RDMA/ucma: Fix use-after-free bug in ucma_create_uevent") Reported-by: syzbot+b0da83a6c0e2e2bddbd4(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68232e7b.050a0220.f2294.09f6.GAE@google.com Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> --- drivers/infiniband/core/cma.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c index 95e89f5c147c2c..4f5fd47086ab90 100644 --- a/drivers/infiniband/core/cma.c +++ b/drivers/infiniband/core/cma.c @@ -2031,6 +2031,8 @@ static void destroy_mc(struct rdma_id_private *id_priv, dev_put(ndev); cancel_work_sync(&mc->iboe_join.work); + if (event->event == RDMA_CM_EVENT_MULTICAST_JOIN) + rdma_destroy_ah_attr(&event->param.ud.ah_attr); } kfree(mc); } base-commit: 3fbaef0942719187f3396bfd0c780d55d35e0980 -- 2.43.0

3 days, 6 hours

1
1
0 0

[PATCH] kasan: hw_tags: fix a false positive case of vrealloc in alloced size

by Yeoreum Yun

When a memory region is allocated with vmalloc() and later expanded with vrealloc() — while still within the originally allocated size — KASAN may report a false positive because it does not update the tags for the newly expanded portion of the memory. A typical example of this pattern occurs in the BPF verifier, and the following is a related false positive report: [ 2206.486476] ================================================================== [ 2206.486509] BUG: KASAN: invalid-access in __memcpy+0xc/0x30 [ 2206.486607] Write at addr f5ff800083765270 by task test_progs/205 [ 2206.486664] Pointer tag: [f5], memory tag: [fe] [ 2206.486703] [ 2206.486745] CPU: 4 UID: 0 PID: 205 Comm: test_progs Tainted: G OE 6.18.0-rc7+ #145 PREEMPT(full) [ 2206.486861] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 2206.486897] Hardware name: , BIOS [ 2206.486932] Call trace: [ 2206.486961] show_stack+0x24/0x40 (C) [ 2206.487071] __dump_stack+0x28/0x48 [ 2206.487182] dump_stack_lvl+0x7c/0xb0 [ 2206.487293] print_address_description+0x80/0x270 [ 2206.487403] print_report+0x94/0x100 [ 2206.487505] kasan_report+0xd8/0x150 [ 2206.487606] __do_kernel_fault+0x64/0x268 [ 2206.487717] do_bad_area+0x38/0x110 [ 2206.487820] do_tag_check_fault+0x38/0x60 [ 2206.487936] do_mem_abort+0x48/0xc8 [ 2206.488042] el1_abort+0x40/0x70 [ 2206.488127] el1h_64_sync_handler+0x50/0x118 [ 2206.488217] el1h_64_sync+0xa4/0xa8 [ 2206.488303] __memcpy+0xc/0x30 (P) [ 2206.488412] do_misc_fixups+0x4f8/0x1950 [ 2206.488528] bpf_check+0x31c/0x840 [ 2206.488638] bpf_prog_load+0x58c/0x658 [ 2206.488737] __sys_bpf+0x364/0x488 [ 2206.488833] __arm64_sys_bpf+0x30/0x58 [ 2206.488920] invoke_syscall+0x68/0xe8 [ 2206.489033] el0_svc_common+0xb0/0xf8 [ 2206.489143] do_el0_svc+0x28/0x48 [ 2206.489249] el0_svc+0x40/0xe8 [ 2206.489337] el0t_64_sync_handler+0x84/0x140 [ 2206.489427] el0t_64_sync+0x1bc/0x1c0 Here, 0xf5ff800083765000 is vmalloc()ed address for env->insn_aux_data with the size of 0x268. While this region is expanded size by 0x478 and initialise increased region to apply patched instructions, a false positive is triggered at the address 0xf5ff800083765270 because __kasan_unpoison_vmalloc() with KASAN_VMALLOC_PROT_NORMAL flag only doesn't update the tag on increaed region. To address this, introduces KASAN_VMALLOC_EXPAND flag which is used to expand vmalloc()ed memory in range of real allocated size to update tag for increased region. Fixes: 23689e91fb22 ("kasan, vmalloc: add vmalloc tagging for HW_TAGS”) Cc: <stable(a)vger.kernel.org> Signed-off-by: Yeoreum Yun <yeoreum.yun(a)arm.com> --- include/linux/kasan.h | 1 + mm/kasan/hw_tags.c | 11 +++++++++-- mm/vmalloc.c | 1 + 3 files changed, 11 insertions(+), 2 deletions(-) diff --git a/include/linux/kasan.h b/include/linux/kasan.h index d12e1a5f5a9a..0608c5d4e6cf 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -28,6 +28,7 @@ typedef unsigned int __bitwise kasan_vmalloc_flags_t; #define KASAN_VMALLOC_INIT ((__force kasan_vmalloc_flags_t)0x01u) #define KASAN_VMALLOC_VM_ALLOC ((__force kasan_vmalloc_flags_t)0x02u) #define KASAN_VMALLOC_PROT_NORMAL ((__force kasan_vmalloc_flags_t)0x04u) +#define KASAN_VMALLOC_EXPAND ((__force kasan_vmalloc_flags_t)0x08u) #define KASAN_VMALLOC_PAGE_RANGE 0x1 /* Apply exsiting page range */ #define KASAN_VMALLOC_TLB_FLUSH 0x2 /* TLB flush */ diff --git a/mm/kasan/hw_tags.c b/mm/kasan/hw_tags.c index 1c373cc4b3fa..d768c7360093 100644 --- a/mm/kasan/hw_tags.c +++ b/mm/kasan/hw_tags.c @@ -347,7 +347,7 @@ void *__kasan_unpoison_vmalloc(const void *start, unsigned long size, * * For non-VM_ALLOC allocations, page_alloc memory is tagged as usual. */ - if (!(flags & KASAN_VMALLOC_VM_ALLOC)) { + if (!(flags & (KASAN_VMALLOC_VM_ALLOC | KASAN_VMALLOC_EXPAND))) { WARN_ON(flags & KASAN_VMALLOC_INIT); return (void *)start; } @@ -361,7 +361,14 @@ void *__kasan_unpoison_vmalloc(const void *start, unsigned long size, return (void *)start; } - tag = kasan_random_tag(); + if (flags & KASAN_VMALLOC_EXPAND) { + size = round_up(size + ((unsigned long)start & KASAN_GRANULE_MASK), + KASAN_GRANULE_SIZE); + start = PTR_ALIGN_DOWN(start, KASAN_GRANULE_SIZE); + tag = get_tag(start); + } else + tag = kasan_random_tag(); + start = set_tag(start, tag); /* Unpoison and initialize memory up to size. */ diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 798b2ed21e46..6bfbf26fea3b 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -4176,6 +4176,7 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align */ if (size <= alloced_size) { kasan_unpoison_vmalloc(p + old_size, size - old_size, + KASAN_VMALLOC_EXPAND | KASAN_VMALLOC_PROT_NORMAL); /* * No need to zero memory here, as unused memory will have -- LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

3 days, 7 hours

2
3
0 0

[PATCH] mpi3mr: Prevent duplicate SAS/SATA device entries in channel 1

by Suganath Prabu S

This fix avoids scanning of SAS/SATA devices in channel 1 when SAS transport is enabled as the SAS/SATA devices are exposed through channel 0 when SAS transport is enabled. Signed-off-by: Ranjan Kumar <ranjan.kumar(a)broadcom.com> Signed-off-by: Suganath Prabu S <suganath-prabu.subramani(a)broadcom.com> --- drivers/scsi/mpi3mr/mpi3mr.h | 4 ++-- drivers/scsi/mpi3mr/mpi3mr_os.c | 4 +++- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/mpi3mr/mpi3mr.h b/drivers/scsi/mpi3mr/mpi3mr.h index 6742684..31d68c1 100644 --- a/drivers/scsi/mpi3mr/mpi3mr.h +++ b/drivers/scsi/mpi3mr/mpi3mr.h @@ -56,8 +56,8 @@ extern struct list_head mrioc_list; extern int prot_mask; extern atomic64_t event_counter; -#define MPI3MR_DRIVER_VERSION "8.15.0.5.50" -#define MPI3MR_DRIVER_RELDATE "12-August-2025" +#define MPI3MR_DRIVER_VERSION "8.15.0.5.51" +#define MPI3MR_DRIVER_RELDATE "18-November-2025" #define MPI3MR_DRIVER_NAME "mpi3mr" #define MPI3MR_DRIVER_LICENSE "GPL" diff --git a/drivers/scsi/mpi3mr/mpi3mr_os.c b/drivers/scsi/mpi3mr/mpi3mr_os.c index b88633e..bca3671 100644 --- a/drivers/scsi/mpi3mr/mpi3mr_os.c +++ b/drivers/scsi/mpi3mr/mpi3mr_os.c @@ -1184,6 +1184,8 @@ static void mpi3mr_update_tgtdev(struct mpi3mr_ioc *mrioc, if (is_added == true) tgtdev->io_throttle_enabled = (flags & MPI3_DEVICE0_FLAGS_IO_THROTTLING_REQUIRED) ? 1 : 0; + if(!mrioc->sas_transport_enabled) + tgtdev->non_stl = 1; switch (flags & MPI3_DEVICE0_FLAGS_MAX_WRITE_SAME_MASK) { case MPI3_DEVICE0_FLAGS_MAX_WRITE_SAME_256_LB: @@ -4844,7 +4846,7 @@ static int mpi3mr_target_alloc(struct scsi_target *starget) spin_lock_irqsave(&mrioc->tgtdev_lock, flags); if (starget->channel == mrioc->scsi_device_channel) { tgt_dev = __mpi3mr_get_tgtdev_by_perst_id(mrioc, starget->id); - if (tgt_dev && !tgt_dev->is_hidden) { + if (tgt_dev && !tgt_dev->is_hidden && tgt_dev->non_stl) { scsi_tgt_priv_data->starget = starget; scsi_tgt_priv_data->dev_handle = tgt_dev->dev_handle; scsi_tgt_priv_data->perst_id = tgt_dev->perst_id; -- 2.47.3

3 days, 11 hours

3
2
0 0

+ idr-fix-idr_alloc-returning-an-id-out-of-range.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: idr: fix idr_alloc() returning an ID out of range has been added to the -mm mm-hotfixes-unstable branch. Its filename is idr-fix-idr_alloc-returning-an-id-out-of-range.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: "Matthew Wilcox (Oracle)" <willy(a)infradead.org> Subject: idr: fix idr_alloc() returning an ID out of range Date: Fri, 28 Nov 2025 16:18:32 +0000 If you use an IDR with a non-zero base, and specify a range that lies entirely below the base, 'max - base' becomes very large and idr_get_free() can return an ID that lies outside of the requested range. Link: https://lkml.kernel.org/r/20251128161853.3200058-1-willy@infradead.org Fixes: 6ce711f27500 ("idr: Make 1-based IDRs more efficient") Signed-off-by: Matthew Wilcox (Oracle) <willy(a)infradead.org> Reported-by: Jan Sokolowski <jan.sokolowski(a)intel.com> Reported-by: Koen Koning <koen.koning(a)intel.com> Reported-by: Peter Senna Tschudin <peter.senna(a)linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6449 Reviewed-by: Christian K��nig <christian.koenig(a)amd.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/idr.c | 2 ++ tools/testing/radix-tree/idr-test.c | 21 +++++++++++++++++++++ 2 files changed, 23 insertions(+) --- a/lib/idr.c~idr-fix-idr_alloc-returning-an-id-out-of-range +++ a/lib/idr.c @@ -40,6 +40,8 @@ int idr_alloc_u32(struct idr *idr, void if (WARN_ON_ONCE(!(idr->idr_rt.xa_flags & ROOT_IS_IDR))) idr->idr_rt.xa_flags |= IDR_RT_MARKER; + if (max < base) + return -ENOSPC; id = (id < base) ? 0 : id - base; radix_tree_iter_init(&iter, id); --- a/tools/testing/radix-tree/idr-test.c~idr-fix-idr_alloc-returning-an-id-out-of-range +++ a/tools/testing/radix-tree/idr-test.c @@ -57,6 +57,26 @@ void idr_alloc_test(void) idr_destroy(&idr); } +void idr_alloc2_test(void) +{ + int id; + struct idr idr = IDR_INIT_BASE(idr, 1); + + id = idr_alloc(&idr, idr_alloc2_test, 0, 1, GFP_KERNEL); + assert(id == -ENOSPC); + + id = idr_alloc(&idr, idr_alloc2_test, 1, 2, GFP_KERNEL); + assert(id == 1); + + id = idr_alloc(&idr, idr_alloc2_test, 0, 1, GFP_KERNEL); + assert(id == -ENOSPC); + + id = idr_alloc(&idr, idr_alloc2_test, 0, 2, GFP_KERNEL); + assert(id == -ENOSPC); + + idr_destroy(&idr); +} + void idr_replace_test(void) { DEFINE_IDR(idr); @@ -409,6 +429,7 @@ void idr_checks(void) idr_replace_test(); idr_alloc_test(); + idr_alloc2_test(); idr_null_test(); idr_nowait_test(); idr_get_next_test(0); _ Patches currently in -mm which might be from willy(a)infradead.org are idr-fix-idr_alloc-returning-an-id-out-of-range.patch mm-fix-vma_start_write_killable-signal-handling.patch

3 days, 13 hours

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror