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

[PATCH v2] ksmbd: vfs: skip lock-range check on equal size to avoid size==0 underflow

by Qianchang Zhao

When size equals the current i_size (including 0), the code used to call check_lock_range(filp, i_size, size - 1, WRITE), which computes `size - 1` and can underflow for size==0. Skip the equal case. Reported-by: Qianchang Zhao <pioooooooooip(a)gmail.com> Reported-by: Zhitong Liu <liuzhitong1993(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Qianchang Zhao <pioooooooooip(a)gmail.com> --- fs/smb/server/vfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/smb/server/vfs.c b/fs/smb/server/vfs.c index 891ed2dc2..d068b78a3 100644 --- a/fs/smb/server/vfs.c +++ b/fs/smb/server/vfs.c @@ -828,7 +828,7 @@ int ksmbd_vfs_truncate(struct ksmbd_work *work, if (size < inode->i_size) { err = check_lock_range(filp, size, inode->i_size - 1, WRITE); - } else { + } else if (size > inode->i_size) { err = check_lock_range(filp, inode->i_size, size - 1, WRITE); } -- 2.34.1

40 minutes

2
1
0 0

[PATCH] powerpc: Use relocated font data pointer for btext_drawchar()

by Finn Thain

From: Christophe Leroy <christophe.leroy(a)csgroup.eu> Since Linux v6.7, booting using BootX on an Old World PowerMac produces an early crash. Stan Johnson writes, "the symptoms are that the screen goes blank and the backlight stays on, and the system freezes (Linux doesn't boot)." Further testing revealed that the failure can be avoided by disabling CONFIG_BOOTX_TEXT. Bisection revealed that the regression was caused by a patch which replaced the static btext font data with const data in a different compilation unit. To fix this, access the font data at its relocated address. Cc: Cedar Maxwell <cedarmaxwell(a)mac.com> Cc: Stan Johnson <userm57(a)yahoo.com> Cc: "Dr. David Alan Gilbert" <linux(a)treblig.org> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Cc: stable(a)vger.kernel.org Link: https://lists.debian.org/debian-powerpc/2025/10/msg00111.html Link: https://lore.kernel.org/linuxppc-dev/d81ddca8-c5ee-d583-d579-02b19ed95301@y… Reported-by: Cedar Maxwell <cedarmaxwell(a)mac.com> Closes: https://lists.debian.org/debian-powerpc/2025/09/msg00031.html Bisected-by: Stan Johnson <userm57(a)yahoo.com> Tested-by: Stan Johnson <userm57(a)yahoo.com> Fixes: 0ebc7feae79a ("powerpc: Use shared font data") Signed-off-by: Finn Thain <fthain(a)linux-m68k.org> --- Christophe, as you're the author of this patch, this submission will probably need your sign-off. --- arch/powerpc/kernel/btext.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/btext.c b/arch/powerpc/kernel/btext.c index 7f63f1cdc6c3..ca00c4824e31 100644 --- a/arch/powerpc/kernel/btext.c +++ b/arch/powerpc/kernel/btext.c @@ -20,6 +20,7 @@ #include <asm/io.h> #include <asm/processor.h> #include <asm/udbg.h> +#include <asm/setup.h> #define NO_SCROLL @@ -463,7 +464,7 @@ static noinline void draw_byte(unsigned char c, long locX, long locY) { unsigned char *base = calc_base(locX << 3, locY << 4); unsigned int font_index = c * 16; - const unsigned char *font = font_sun_8x16.data + font_index; + const unsigned char *font = PTRRELOC(font_sun_8x16.data) + font_index; int rb = dispDeviceRowBytes; rmci_maybe_on(); -- 2.49.1

1 hour, 37 minutes

1
0
0 0

Fwd: Compile Error fs/nfsd/nfs4state.o - clamp() low limit slotsize greater than high limit total_avail/scale_factor

by Chuck Lever

FYI https://bugzilla.kernel.org/show_bug.cgi?id=220745 -------- Forwarded Message -------- Subject: Re: Compile Error fs/nfsd/nfs4state.o - clamp() low limit slotsize greater than high limit total_avail/scale_factor Date: Thu, 06 Nov 2025 07:29:25 -0500 From: Jeff Layton <jlayton(a)kernel.org> To: Mike-SPC via Bugspray Bot <bugbot(a)kernel.org>, cel(a)kernel.org, neilb(a)ownmail.net, trondmy(a)kernel.org, linux-nfs(a)vger.kernel.org, anna(a)kernel.org, neilb(a)brown.name On Thu, 2025-11-06 at 11:30 +0000, Mike-SPC via Bugspray Bot wrote: > Mike-SPC writes via Kernel.org Bugzilla: > > (In reply to Bugspray Bot from comment #5) > > Chuck Lever <cel(a)kernel.org> replies to comment #4: > > > > On 11/5/25 7:25 AM, Mike-SPC via Bugspray Bot wrote: > > > Mike-SPC writes via Kernel.org Bugzilla: > > > > > > > Have you found a 6.1.y kernel for which the build doesn't fail? > > > > > > Yes. Compiling Version 6.1.155 works without problems. > > > Versions >= 6.1.156 aren't. > > > > My analysis yesterday suggests that, because the nfs4state.c code hasn't > > changed, it's probably something elsewhere that introduced this problem. > > As we can't reproduce the issue, can you use "git bisect" between > > v6.1.155 and v6.1.156 to find the culprit commit? > > > > (via https://msgid.link/ab235dbe-7949-4208-a21a-2cdd50347152@kernel.org) > > > Yes, your analysis is right (thanks for it). > After some investigation, the issue appears to be caused by changes introduced in > include/linux/minmax.h. > > I verified this by replacing minmax.h in 6.1.156 with the version from 6.1.155, > and the kernel then compiles successfully. > > The relevant section in the 6.1.156 changelog (https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.156) shows several modifications to minmax.h (notably around __clamp_once() and the use of > BUILD_BUG_ON_MSG(statically_true(ulo > uhi), ...)), which seem to trigger a compile-time assertion when building NFSD. > > Replacing the updated header with the previous one resolves the issue, so this appears > to be a regression introduced by the new clamp() logic. > > Could you please advise who is the right person or mailing list to report this issue to > (minmax.h maintainers, kernel core, or stable tree)? > I'd let all 3 know, and I'd include the author of the patches that you suspect are the problem. They'll probably want to revise the one that's a problem. Cheers, -- Jeff Layton <jlayton(a)kernel.org>

3 hours, 33 minutes

3
8
0 0

[PATCH] powerpc: Fix mprotect on book3s32

by Dave Vasilevsky via B4 Relay

From: Dave Vasilevsky <dave(a)vasilevsky.ca> On 32-bit book3s with hash-MMUs, tlb_flush() was a no-op. This was unnoticed because all uses until recently were for unmaps, and thus handled by __tlb_remove_tlb_entry(). After commit 4a18419f71cd ("mm/mprotect: use mmu_gather") in kernel 5.19, tlb_gather_mmu() started being used for mprotect as well. This caused mprotect to simply not work on these machines: int *ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); *ptr = 1; // force HPTE to be created mprotect(ptr, 4096, PROT_READ); *ptr = 2; // should segfault, but succeeds Fixed by making tlb_flush() actually flush TLB pages. This finally agrees with the behaviour of boot3s64's tlb_flush(). Fixes: 4a18419f71cd ("mm/mprotect: use mmu_gather") Signed-off-by: Dave Vasilevsky <dave(a)vasilevsky.ca> --- arch/powerpc/include/asm/book3s/32/tlbflush.h | 8 ++++++-- arch/powerpc/mm/book3s32/tlb.c | 6 ++++++ 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/include/asm/book3s/32/tlbflush.h b/arch/powerpc/include/asm/book3s/32/tlbflush.h index e43534da5207aa3b0cb3c07b78e29b833c141f3f..b8c587ad2ea954f179246a57d6e86e45e91dcfdc 100644 --- a/arch/powerpc/include/asm/book3s/32/tlbflush.h +++ b/arch/powerpc/include/asm/book3s/32/tlbflush.h @@ -11,6 +11,7 @@ void hash__flush_tlb_mm(struct mm_struct *mm); void hash__flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr); void hash__flush_range(struct mm_struct *mm, unsigned long start, unsigned long end); +void hash__flush_gather(struct mmu_gather *tlb); #ifdef CONFIG_SMP void _tlbie(unsigned long address); @@ -28,9 +29,12 @@ void _tlbia(void); */ static inline void tlb_flush(struct mmu_gather *tlb) { - /* 603 needs to flush the whole TLB here since it doesn't use a hash table. */ - if (!mmu_has_feature(MMU_FTR_HPTE_TABLE)) + if (mmu_has_feature(MMU_FTR_HPTE_TABLE)) { + hash__flush_gather(tlb); + } else { + /* 603 needs to flush the whole TLB here since it doesn't use a hash table. */ _tlbia(); + } } static inline void flush_range(struct mm_struct *mm, unsigned long start, unsigned long end) diff --git a/arch/powerpc/mm/book3s32/tlb.c b/arch/powerpc/mm/book3s32/tlb.c index 9ad6b56bfec96e989b96f027d075ad5812500854..3da95ecfbbb296303082e378425e92a5fbdbfac8 100644 --- a/arch/powerpc/mm/book3s32/tlb.c +++ b/arch/powerpc/mm/book3s32/tlb.c @@ -105,3 +105,9 @@ void hash__flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr) flush_hash_pages(mm->context.id, vmaddr, pmd_val(*pmd), 1); } EXPORT_SYMBOL(hash__flush_tlb_page); + +void hash__flush_gather(struct mmu_gather *tlb) +{ + hash__flush_range(tlb->mm, tlb->start, tlb->end); +} +EXPORT_SYMBOL(hash__flush_gather); --- base-commit: dcb6fa37fd7bc9c3d2b066329b0d27dedf8becaa change-id: 20251027-vasi-mprotect-g3-f8f5278d4140 Best regards, -- Dave Vasilevsky <dave(a)vasilevsky.ca>

3 hours, 48 minutes

4
3
0 0

[PATCH 1/2] HID: logitech-dj: Remove duplicate error logging

by Hans de Goede

logi_dj_recv_query_paired_devices() and logi_dj_recv_switch_to_dj_mode() both have 2 callers which all log an error if the function fails. Move the error logging to inside these 2 functions to remove the duplicated error logging in the callers. While at it also move the logi_dj_recv_send_report() call error handling in logi_dj_recv_switch_to_dj_mode() to directly after the call. That call only fails if the report cannot be found and in that case it does nothing, so the msleep() is not necessary on failures. Fixes: 6f20d3261265 ("HID: logitech-dj: Fix error handling in logi_dj_recv_switch_to_dj_mode()") Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <johannes.goede(a)oss.qualcomm.com> --- drivers/hid/hid-logitech-dj.c | 56 ++++++++++++++--------------------- 1 file changed, 23 insertions(+), 33 deletions(-) diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c index d66f4807311a..58a848ed248d 100644 --- a/drivers/hid/hid-logitech-dj.c +++ b/drivers/hid/hid-logitech-dj.c @@ -889,7 +889,6 @@ static void delayedwork_callback(struct work_struct *work) struct dj_workitem workitem; unsigned long flags; int count; - int retval; dbg_hid("%s\n", __func__); @@ -926,11 +925,7 @@ static void delayedwork_callback(struct work_struct *work) logi_dj_recv_destroy_djhid_device(djrcv_dev, &workitem); break; case WORKITEM_TYPE_UNKNOWN: - retval = logi_dj_recv_query_paired_devices(djrcv_dev); - if (retval) { - hid_err(djrcv_dev->hidpp, "%s: logi_dj_recv_query_paired_devices error: %d\n", - __func__, retval); - } + logi_dj_recv_query_paired_devices(djrcv_dev); break; case WORKITEM_TYPE_EMPTY: dbg_hid("%s: device list is empty\n", __func__); @@ -1323,8 +1318,10 @@ static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev) djrcv_dev->last_query = jiffies; - if (djrcv_dev->type != recvr_type_dj) - return logi_dj_recv_query_hidpp_devices(djrcv_dev); + if (djrcv_dev->type != recvr_type_dj) { + retval = logi_dj_recv_query_hidpp_devices(djrcv_dev); + goto out; + } dj_report = kzalloc(sizeof(struct dj_report), GFP_KERNEL); if (!dj_report) @@ -1334,6 +1331,10 @@ static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev) dj_report->report_type = REPORT_TYPE_CMD_GET_PAIRED_DEVICES; retval = logi_dj_recv_send_report(djrcv_dev, dj_report); kfree(dj_report); +out: + if (retval < 0) + hid_err(djrcv_dev->hidpp, "%s error:%d\n", __func__, retval); + return retval; } @@ -1359,6 +1360,8 @@ static int logi_dj_recv_switch_to_dj_mode(struct dj_receiver_dev *djrcv_dev, (u8)timeout; retval = logi_dj_recv_send_report(djrcv_dev, dj_report); + if (retval) + goto out; /* * Ugly sleep to work around a USB 3.0 bug when the receiver is @@ -1367,11 +1370,6 @@ static int logi_dj_recv_switch_to_dj_mode(struct dj_receiver_dev *djrcv_dev, * 50 msec should gives enough time to the receiver to be ready. */ msleep(50); - - if (retval) { - kfree(dj_report); - return retval; - } } /* @@ -1397,7 +1395,12 @@ static int logi_dj_recv_switch_to_dj_mode(struct dj_receiver_dev *djrcv_dev, HIDPP_REPORT_SHORT_LENGTH, HID_OUTPUT_REPORT, HID_REQ_SET_REPORT); +out: kfree(dj_report); + + if (retval < 0) + hid_err(hdev, "%s error:%d\n", __func__, retval); + return retval; } @@ -1935,11 +1938,8 @@ static int logi_dj_probe(struct hid_device *hdev, if (has_hidpp) { retval = logi_dj_recv_switch_to_dj_mode(djrcv_dev, 0); - if (retval < 0) { - hid_err(hdev, "%s: logi_dj_recv_switch_to_dj_mode returned error:%d\n", - __func__, retval); + if (retval < 0) goto switch_to_dj_mode_fail; - } } /* This is enabling the polling urb on the IN endpoint */ @@ -1957,15 +1957,11 @@ static int logi_dj_probe(struct hid_device *hdev, spin_lock_irqsave(&djrcv_dev->lock, flags); djrcv_dev->ready = true; spin_unlock_irqrestore(&djrcv_dev->lock, flags); - retval = logi_dj_recv_query_paired_devices(djrcv_dev); - if (retval < 0) { - hid_err(hdev, "%s: logi_dj_recv_query_paired_devices error:%d\n", - __func__, retval); - /* - * This can happen with a KVM, let the probe succeed, - * logi_dj_recv_queue_unknown_work will retry later. - */ - } + /* + * This can fail with a KVM. Ignore errors to let the probe + * succeed, logi_dj_recv_queue_unknown_work will retry later. + */ + logi_dj_recv_query_paired_devices(djrcv_dev); } return 0; @@ -1982,18 +1978,12 @@ static int logi_dj_probe(struct hid_device *hdev, #ifdef CONFIG_PM static int logi_dj_reset_resume(struct hid_device *hdev) { - int retval; struct dj_receiver_dev *djrcv_dev = hid_get_drvdata(hdev); if (!djrcv_dev || djrcv_dev->hidpp != hdev) return 0; - retval = logi_dj_recv_switch_to_dj_mode(djrcv_dev, 0); - if (retval < 0) { - hid_err(hdev, "%s: logi_dj_recv_switch_to_dj_mode returned error:%d\n", - __func__, retval); - } - + logi_dj_recv_switch_to_dj_mode(djrcv_dev, 0); return 0; } #endif -- 2.51.1

5 hours, 10 minutes

1
0
0 0

PROBLEM: boot hang on Indy R4400SC (regression)

by Nick Bowler

Hi, After a recent 6.1.y stable kernel update, my Indy (mips64 R4400SC) now just stops booting early, just before when I would normally see the kernel messages about mounting the root filesystem. There are no further messages of any kind, and the boot process does not appear to ever complete. However, the kernel is not fully crashed, as it does respond to sysrq commands from the keyboard (and I do get output on the console from these). I bisected to the following: 794b679a28bb59a4533ae39a7cf945b9d5bbe336 is the first bad commit commit 794b679a28bb59a4533ae39a7cf945b9d5bbe336 Author: Jiaxun Yang <jiaxun.yang(a)flygoat.com> Date: Sat Jun 7 13:43:56 2025 +0100 MIPS: mm: tlb-r4k: Uniquify TLB entries on init commit 35ad7e181541aa5757f9f316768d3e64403ec843 upstream. This reverts cleanly on top of 6.1.158 and the resulting kernel boots normally. I then reproduced this failure on 6.18-rc4. Reverting 35ad7e181541 on top of 6.18-rc4 also results in a normal boot. Let me know if you need any more info! Thanks, Nick

6 hours, 11 minutes

2
3
0 0

Re: Patch "clocksource/drivers/timer-rtl-otto: Work around dying timers" has been added to the 6.17-stab

by Pascal Ernster

Hi Sasha, [2025-11-04 14:17] Sasha Levin: > This is a note to let you know that I've just added the patch titled > > clocksource/drivers/timer-rtl-otto: Work around dying timers > > to the 6.17-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: > clocksource-drivers-timer-rtl-otto-work-around-dying.patch > and it can be found in the queue-6.17 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. > > > > commit fbc0494f847969d81c1f087117dca462c816bedb > Author: Markus Stockhausen <markus.stockhausen(a)gmx.de> > Date: Mon Aug 4 04:03:25 2025 -0400 > > clocksource/drivers/timer-rtl-otto: Work around dying timers > > [ Upstream commit e7a25106335041aeca4fdf50a84804c90142c886 ] > > The OpenWrt distribution has switched from kernel longterm 6.6 to > 6.12. Reports show that devices with the Realtek Otto switch platform > die during operation and are rebooted by the watchdog. Sorting out > other possible reasons the Otto timer is to blame. The platform > currently consists of 4 targets with different hardware revisions. > It is not 100% clear which devices and revisions are affected. > > Analysis shows: > > A more aggressive sched/deadline handling leads to more timer starts > with small intervals. This increases the bug chances. See > https://marc.info/?l=linux-kernel&m=175276556023276&w=2 > > Focusing on the real issue a hardware limitation on some devices was > found. There is a minimal chance that a timer ends without firing an > interrupt if it is reprogrammed within the 5us before its expiration > time. Work around this issue by introducing a bounce() function. It > restarts the timer directly before the normal restart functions as > follows: > > - Stop timer > - Restart timer with a slow frequency. > - Target time will be >5us > - The subsequent normal restart is outside the critical window > > Downstream has already tested and confirmed a patch. See > https://github.com/openwrt/openwrt/pull/19468 > https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/5787… > > Signed-off-by: Markus Stockhausen <markus.stockhausen(a)gmx.de> > Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> > Tested-by: Stephen Howell <howels(a)allthatwemight.be> > Tested-by: Bjørn Mork <bjorn(a)mork.no> > Link: https://lore.kernel.org/r/20250804080328.2609287-2-markus.stockhausen@gmx.de > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/clocksource/timer-rtl-otto.c b/drivers/clocksource/timer-rtl-otto.c > index 8a3068b36e752..8be45a11fb8b6 100644 > --- a/drivers/clocksource/timer-rtl-otto.c > +++ b/drivers/clocksource/timer-rtl-otto.c > @@ -38,6 +38,7 @@ > #define RTTM_BIT_COUNT 28 > #define RTTM_MIN_DELTA 8 > #define RTTM_MAX_DELTA CLOCKSOURCE_MASK(28) > +#define RTTM_MAX_DIVISOR GENMASK(15, 0) > > /* > * Timers are derived from the LXB clock frequency. Usually this is a fixed > @@ -112,6 +113,22 @@ static irqreturn_t rttm_timer_interrupt(int irq, void *dev_id) > return IRQ_HANDLED; > } > > +static void rttm_bounce_timer(void __iomem *base, u32 mode) > +{ > + /* > + * When a running timer has less than ~5us left, a stop/start sequence > + * might fail. While the details are unknown the most evident effect is > + * that the subsequent interrupt will not be fired. > + * > + * As a workaround issue an intermediate restart with a very slow > + * frequency of ~3kHz keeping the target counter (>=8). So the follow > + * up restart will always be issued outside the critical window. > + */ > + > + rttm_disable_timer(base); > + rttm_enable_timer(base, mode, RTTM_MAX_DIVISOR); > +} > + > static void rttm_stop_timer(void __iomem *base) > { > rttm_disable_timer(base); > @@ -129,6 +146,7 @@ static int rttm_next_event(unsigned long delta, struct clock_event_device *clkev > struct timer_of *to = to_timer_of(clkevt); > > RTTM_DEBUG(to->of_base.base); > + rttm_bounce_timer(to->of_base.base, RTTM_CTRL_COUNTER); > rttm_stop_timer(to->of_base.base); > rttm_set_period(to->of_base.base, delta); > rttm_start_timer(to, RTTM_CTRL_COUNTER); > @@ -141,6 +159,7 @@ static int rttm_state_oneshot(struct clock_event_device *clkevt) > struct timer_of *to = to_timer_of(clkevt); > > RTTM_DEBUG(to->of_base.base); > + rttm_bounce_timer(to->of_base.base, RTTM_CTRL_COUNTER); > rttm_stop_timer(to->of_base.base); > rttm_set_period(to->of_base.base, RTTM_TICKS_PER_SEC / HZ); > rttm_start_timer(to, RTTM_CTRL_COUNTER); > @@ -153,6 +172,7 @@ static int rttm_state_periodic(struct clock_event_device *clkevt) > struct timer_of *to = to_timer_of(clkevt); > > RTTM_DEBUG(to->of_base.base); > + rttm_bounce_timer(to->of_base.base, RTTM_CTRL_TIMER); > rttm_stop_timer(to->of_base.base); > rttm_set_period(to->of_base.base, RTTM_TICKS_PER_SEC / HZ); > rttm_start_timer(to, RTTM_CTRL_TIMER); this patch is part of a series of 4 patches, but it seems you have only cherry-picked patches 1 and 3 from that series, although all 4 were merged into Linus' tree: https://lore.kernel.org/all/20250804080328.2609287-1-markus.stockhausen@gmx… https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/driv… I could only find the "linux-stable-commits" mails for queue-6.17, but you selected the same 2 patches for queue-6.12 as well. Is that selection of only 2 of the 4 patches intentional? Regards Pascaö

6 hours, 40 minutes

1
0
0 0

[PATCH] shmem: fix tmpfs reconfiguration (remount) when noswap is set

by Mike Yuan

In systemd we're trying to switch the internal credentials setup logic to new mount API [1], and I noticed fsconfig(FSCONFIG_CMD_RECONFIGURE) consistently fails on tmpfs with noswap option. This can be trivially reproduced with the following: ``` int fs_fd = fsopen("tmpfs", 0); fsconfig(fs_fd, FSCONFIG_SET_FLAG, "noswap", NULL, 0); fsconfig(fs_fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0); fsmount(fs_fd, 0, 0); fsconfig(fs_fd, FSCONFIG_CMD_RECONFIGURE, NULL, NULL, 0); <------ EINVAL ``` After some digging the culprit is shmem_reconfigure() rejecting !(ctx->seen & SHMEM_SEEN_NOSWAP) && sbinfo->noswap, which is bogus as ctx->seen serves as a mask for whether certain options are touched at all. On top of that, noswap option doesn't use fsparam_flag_no, hence it's not really possible to "reenable" swap to begin with. Drop the check and redundant SHMEM_SEEN_NOSWAP flag. [1] https://github.com/systemd/systemd/pull/39637 Fixes: 2c6efe9cf2d7 ("shmem: add support to ignore swap") Signed-off-by: Mike Yuan <me(a)yhndnzj.com> Cc: Luis Chamberlain <mcgrof(a)kernel.org> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Hugh Dickins <hughd(a)google.com> Cc: <stable(a)vger.kernel.org> --- mm/shmem.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/mm/shmem.c b/mm/shmem.c index b9081b817d28..1b976414d6fa 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -131,8 +131,7 @@ struct shmem_options { #define SHMEM_SEEN_INODES 2 #define SHMEM_SEEN_HUGE 4 #define SHMEM_SEEN_INUMS 8 -#define SHMEM_SEEN_NOSWAP 16 -#define SHMEM_SEEN_QUOTA 32 +#define SHMEM_SEEN_QUOTA 16 }; #ifdef CONFIG_TRANSPARENT_HUGEPAGE @@ -4677,7 +4676,6 @@ static int shmem_parse_one(struct fs_context *fc, struct fs_parameter *param) "Turning off swap in unprivileged tmpfs mounts unsupported"); } ctx->noswap = true; - ctx->seen |= SHMEM_SEEN_NOSWAP; break; case Opt_quota: if (fc->user_ns != &init_user_ns) @@ -4827,14 +4825,15 @@ static int shmem_reconfigure(struct fs_context *fc) err = "Current inum too high to switch to 32-bit inums"; goto out; } - if ((ctx->seen & SHMEM_SEEN_NOSWAP) && ctx->noswap && !sbinfo->noswap) { + + /* + * "noswap" doesn't use fsparam_flag_no, i.e. there's no "swap" + * counterpart for (re-)enabling swap. + */ + if (ctx->noswap && !sbinfo->noswap) { err = "Cannot disable swap on remount"; goto out; } - if (!(ctx->seen & SHMEM_SEEN_NOSWAP) && !ctx->noswap && sbinfo->noswap) { - err = "Cannot enable swap on remount if it was disabled on first mount"; - goto out; - } if (ctx->seen & SHMEM_SEEN_QUOTA && !sb_any_quota_loaded(fc->root->d_sb)) { base-commit: 0d7bee10beeb59b1133bf5a4749b17a4ef3bbb01 -- 2.51.1

7 hours, 3 minutes

1
0
0 0

[PATCH] mm/hmm/test: Fix error handling in dmirror_device_init

by Ma Ke

dmirror_device_init() calls device_initialize() which sets the device reference count to 1, but fails to call put_device() when error occurs after dev_set_name() or cdev_device_add() failures. This results in memory leaks of struct device objects. Additionally, dmirror_device_remove() lacks the final put_device() call to properly release the device reference. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 6a760f58c792 ("mm/hmm/test: use char dev with struct device to get device node") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- lib/test_hmm.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/lib/test_hmm.c b/lib/test_hmm.c index 83e3d8208a54..5159fc36eea6 100644 --- a/lib/test_hmm.c +++ b/lib/test_hmm.c @@ -1458,20 +1458,25 @@ static int dmirror_device_init(struct dmirror_device *mdevice, int id) ret = dev_set_name(&mdevice->device, "hmm_dmirror%u", id); if (ret) - return ret; + goto put_device; ret = cdev_device_add(&mdevice->cdevice, &mdevice->device); if (ret) - return ret; + goto put_device; /* Build a list of free ZONE_DEVICE struct pages */ return dmirror_allocate_chunk(mdevice, NULL); + +put_device: + put_device(&mdevice->device); + return ret; } static void dmirror_device_remove(struct dmirror_device *mdevice) { dmirror_device_remove_chunks(mdevice); cdev_device_del(&mdevice->cdevice, &mdevice->device); + put_device(&mdevice->device); } static int __init hmm_dmirror_init(void) -- 2.17.1

11 hours, 42 minutes

2
1
0 0

[PATCH] ksmbd: fix leak of transform buffer on encrypt_resp() failure

by Qianchang Zhao

When encrypt_resp() fails at the send path, we only set STATUS_DATA_ERROR but leave the transform buffer allocated (work->tr_buf in this tree). Repeating this path leaks kernel memory and can lead to OOM (DoS) when encryption is required. Reproduced on: Linux v6.18-rc2 (self-built test kernel) Fix by freeing the transform buffer and forcing plaintext error reply. Reported-by: Qianchang Zhao <pioooooooooip(a)gmail.com> Reported-by: Zhitong Liu <liuzhitong1993(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Qianchang Zhao <pioooooooooip(a)gmail.com> --- fs/smb/server/server.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/smb/server/server.c b/fs/smb/server/server.c index 40420544c..15dd13e76 100644 --- a/fs/smb/server/server.c +++ b/fs/smb/server/server.c @@ -244,8 +244,14 @@ static void __handle_ksmbd_work(struct ksmbd_work *work, if (work->sess && work->sess->enc && work->encrypted && conn->ops->encrypt_resp) { rc = conn->ops->encrypt_resp(work); - if (rc < 0) + if (rc < 0) { conn->ops->set_rsp_status(work, STATUS_DATA_ERROR); + work->encrypted = false; + if (work->tr_buf) { + kvfree(work->tr_buf); + work->tr_buf = NULL; + } + } } if (work->sess) ksmbd_user_session_put(work->sess); -- 2.34.1

11 hours, 46 minutes

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror