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

Re: [PATCH] block: cleanup and fix batch completion adding conditions

by Milan Broz

On 3/11/25 4:00 PM, Jens Axboe wrote: > On 3/11/25 8:59 AM, Milan Broz wrote: >> On 3/11/25 4:03 AM, Shinichiro Kawasaki wrote: >>> >>> I created fix candidate patches to address the blktests nvme/039 failure [1]. >>> This may work for the failures Ondrej and Milan observe too, hopefully. >> >> Hi, >> >> I quickly tried to run the test with todays' mainline git and mentioned two patches: >> https://lkml.kernel.org/linux-block/20250311024144.1762333-2-shinichiro.kaw… >> https://lkml.kernel.org/linux-block/20250311024144.1762333-3-shinichiro.kaw… >> and it looks like our SED Opal tests are fixed, no errors or warnings, thanks! >> >>> Jens, Alan, could you take a look in the patches and see if they make sense? >> >> Please, fix it before the 6.14 final, this could cause serious data corruption, at least >> on systems using SED Opal drives. > > Fix is already queued up. Hi Jens, it seems the bug was "successfully" backported to stable 6.13.4+ and I do not see any fix in the stable queue yet. We were hit by it today, as all locked ranges for Opal devices now returning empty data instead of failing read. Please could you check what need to be backported to 6.13 stable? IMO these patches should be backported: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm… https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm… Thanks, Milan

3 months, 3 weeks

1
0
0 0

[PATCH v2] Revert "mmc: sdhci_am654: Add sdhci_am654_start_signal_voltage_switch"

by Josua Mayer

This reverts commit 941a7abd4666912b84ab209396fdb54b0dae685d. This commit uses presence of device-tree properties vmmc-supply and vqmmc-supply for deciding whether to enable a quirk affecting timing of clock and data. The intention was to address issues observed with eMMC and SD on AM62 platforms. This new quirk is however also enabled for AM64 breaking microSD access on the SolidRun HimmingBoard-T which is supported in-tree since v6.11, causing a regression. During boot microSD initialization now fails with the error below: [ 2.008520] mmc1: SDHCI controller on fa00000.mmc [fa00000.mmc] using ADMA 64-bit [ 2.115348] mmc1: error -110 whilst initialising SD card The heuristics for enabling the quirk are clearly not correct as they break at least one but potentially many existing boards. Revert the change and restore original behaviour until a more appropriate method of selecting the quirk is derived. Fixes: 941a7abd4666 ("mmc: sdhci_am654: Add sdhci_am654_start_signal_voltage_switch") Closes: https://lore.kernel.org/linux-mmc/a70fc9fc-186f-4165-a652-3de50733763a@soli… Cc: stable(a)vger.kernel.org Signed-off-by: Josua Mayer <josua(a)solid-run.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> --- Changes in v2: - Fixed "Fixes:" tag invalid commit description copied from history (Reported-by: Adrian Hunter <adrian.hunter(a)intel.com>) (Reported-by: Greg KH <gregkh(a)linuxfoundation.org>) - Link to v1: https://lore.kernel.org/r/20250127-am654-mmc-regression-v1-1-d831f9a13ae9@s… --- drivers/mmc/host/sdhci_am654.c | 30 ------------------------------ 1 file changed, 30 deletions(-) diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c index b73f673db92bbc042392995e715815e15ace6005..f75c31815ab00d17b5757063521f56ba5643babe 100644 --- a/drivers/mmc/host/sdhci_am654.c +++ b/drivers/mmc/host/sdhci_am654.c @@ -155,7 +155,6 @@ struct sdhci_am654_data { u32 tuning_loop; #define SDHCI_AM654_QUIRK_FORCE_CDTEST BIT(0) -#define SDHCI_AM654_QUIRK_SUPPRESS_V1P8_ENA BIT(1) }; struct window { @@ -357,29 +356,6 @@ static void sdhci_j721e_4bit_set_clock(struct sdhci_host *host, sdhci_set_clock(host, clock); } -static int sdhci_am654_start_signal_voltage_switch(struct mmc_host *mmc, struct mmc_ios *ios) -{ - struct sdhci_host *host = mmc_priv(mmc); - struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); - struct sdhci_am654_data *sdhci_am654 = sdhci_pltfm_priv(pltfm_host); - int ret; - - if ((sdhci_am654->quirks & SDHCI_AM654_QUIRK_SUPPRESS_V1P8_ENA) && - ios->signal_voltage == MMC_SIGNAL_VOLTAGE_180) { - if (!IS_ERR(mmc->supply.vqmmc)) { - ret = mmc_regulator_set_vqmmc(mmc, ios); - if (ret < 0) { - pr_err("%s: Switching to 1.8V signalling voltage failed,\n", - mmc_hostname(mmc)); - return -EIO; - } - } - return 0; - } - - return sdhci_start_signal_voltage_switch(mmc, ios); -} - static u8 sdhci_am654_write_power_on(struct sdhci_host *host, u8 val, int reg) { writeb(val, host->ioaddr + reg); @@ -868,11 +844,6 @@ static int sdhci_am654_get_of_property(struct platform_device *pdev, if (device_property_read_bool(dev, "ti,fails-without-test-cd")) sdhci_am654->quirks |= SDHCI_AM654_QUIRK_FORCE_CDTEST; - /* Suppress v1p8 ena for eMMC and SD with vqmmc supply */ - if (!!of_parse_phandle(dev->of_node, "vmmc-supply", 0) == - !!of_parse_phandle(dev->of_node, "vqmmc-supply", 0)) - sdhci_am654->quirks |= SDHCI_AM654_QUIRK_SUPPRESS_V1P8_ENA; - sdhci_get_of_property(pdev); return 0; @@ -969,7 +940,6 @@ static int sdhci_am654_probe(struct platform_device *pdev) goto err_pltfm_free; } - host->mmc_host_ops.start_signal_voltage_switch = sdhci_am654_start_signal_voltage_switch; host->mmc_host_ops.execute_tuning = sdhci_am654_execute_tuning; pm_runtime_get_noresume(dev); --- base-commit: ffd294d346d185b70e28b1a28abe367bbfe53c04 change-id: 20250127-am654-mmc-regression-ed289f8967c2 Best regards, -- Josua Mayer <josua(a)solid-run.com>

3 months, 3 weeks

4
7
0 0

[PATCH] ext4: fix OOB read when checking dotdot dir

by Jakub Acs

Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed). ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block. If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access. Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero). Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read. This issue was found by syzkaller tool. Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: ac27a0ec112a0 ("[PATCH] ext4: initial copy of files from ext3") Signed-off-by: Jakub Acs <acsjakub(a)amazon.com> Cc: "Theodore Ts'o" <tytso(a)mit.edu> Cc: Andreas Dilger <adilger.kernel(a)dilger.ca> Cc: linux-ext4(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: Mahmoud Adam <mngyadam(a)amazon.com> Cc: stable(a)vger.kernel.org Cc: security(a)kernel.org --- If not fixed, this potentially leaks information from kernel data structures allocated after the data block. I based the check on the assumption that every ext4 directory has '.' followed by at least one entry ('..') in the first data block. (the code in ext4_empty_dir seems to operate on this assumption) ..and it is also supported by claim in https://www.kernel.org/doc/html/latest/filesystems/ext4/directory.html: "By ext2 custom, the '.' and '..' entries must appear at the beginning of this first block" Please confirm that this is correct and there are no valid ext4 directories that have '.' as the last directory entry. If this assumption is wrong, I would fix the caller rather than the callee. Testing: I booted the kernel in AL2023 EC2 Instance and ran ext4 tests from git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git: <setup with loop devices> ./check ext4/* [..] ext4/002 [not run] This test requires a valid $SCRATCH_LOGDEV ext4/004 [not run] dump utility required, skipped this test ext4/006 [not run] Couldn't find e2fuzz ext4/029 [not run] This test requires a valid $SCRATCH_LOGDEV ext4/030 [not run] mount /dev/loop1 with dax failed ext4/031 [not run] mount /dev/loop1 with dax failed ext4/047 [not run] mount /dev/loop1 with dax=always failed ext4/055 [not run] fsgqa user not defined. ext4/057 [not run] UUID ioctls are not supported by kernel. Not run: ext4/002 ext4/004 ext4/006 ext4/029 ext4/030 ext4/031 ext4/047 ext4/055 ext4/057 Passed all 69 tests (please let me know if any of the skipped tests need to be run) Thanks, Jakub --- fs/ext4/dir.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/ext4/dir.c b/fs/ext4/dir.c index 02d47a64e8d1..d157a6c0eff6 100644 --- a/fs/ext4/dir.c +++ b/fs/ext4/dir.c @@ -104,6 +104,9 @@ int __ext4_check_dir_entry(const char *function, unsigned int line, else if (unlikely(le32_to_cpu(de->inode) > le32_to_cpu(EXT4_SB(dir->i_sb)->s_es->s_inodes_count))) error_msg = "inode out of bounds"; + else if (unlikely(de->name_len > 0 && strcmp(".", de->name) == 0 && + next_offset == size)) + error_msg = "'.' directory cannot be the last in data block"; else return 0; -- 2.47.1

3 months, 3 weeks

3
3
0 0

[PATCH net 1/3] mptcp: Fix data stream corruption in the address announcement

by Matthieu Baerts (NGI0)

From: Arthur Mongodin <amongodin(a)randorisec.fr> Because of the size restriction in the TCP options space, the MPTCP ADD_ADDR option is exclusive and cannot be sent with other MPTCP ones. For this reason, in the linked mptcp_out_options structure, group of fields linked to different options are part of the same union. There is a case where the mptcp_pm_add_addr_signal() function can modify opts->addr, but not ended up sending an ADD_ADDR. Later on, back in mptcp_established_options, other options will be sent, but with unexpected data written in other fields due to the union, e.g. in opts->ext_copy. This could lead to a data stream corruption in the next packet. Using an intermediate variable, prevents from corrupting previously established DSS option. The assignment of the ADD_ADDR option parameters is now done once we are sure this ADD_ADDR option can be set in the packet, e.g. after having dropped other suboptions. Fixes: 1bff1e43a30e ("mptcp: optimize out option generation") Cc: stable(a)vger.kernel.org Suggested-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Arthur Mongodin <amongodin(a)randorisec.fr> Reviewed-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> [ Matt: the commit message has been updated: long lines splits and some clarifications. ] Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- net/mptcp/options.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/mptcp/options.c b/net/mptcp/options.c index fd2de185bc939f8730e87a63ac02a015e610e99c..23949ae2a3a8db19d05c5c8373f45c885c3523ad 100644 --- a/net/mptcp/options.c +++ b/net/mptcp/options.c @@ -651,6 +651,7 @@ static bool mptcp_established_options_add_addr(struct sock *sk, struct sk_buff * struct mptcp_sock *msk = mptcp_sk(subflow->conn); bool drop_other_suboptions = false; unsigned int opt_size = *size; + struct mptcp_addr_info addr; bool echo; int len; @@ -659,7 +660,7 @@ static bool mptcp_established_options_add_addr(struct sock *sk, struct sk_buff * */ if (!mptcp_pm_should_add_signal(msk) || (opts->suboptions & (OPTION_MPTCP_MPJ_ACK | OPTION_MPTCP_MPC_ACK)) || - !mptcp_pm_add_addr_signal(msk, skb, opt_size, remaining, &opts->addr, + !mptcp_pm_add_addr_signal(msk, skb, opt_size, remaining, &addr, &echo, &drop_other_suboptions)) return false; @@ -672,7 +673,7 @@ static bool mptcp_established_options_add_addr(struct sock *sk, struct sk_buff * else if (opts->suboptions & OPTION_MPTCP_DSS) return false; - len = mptcp_add_addr_len(opts->addr.family, echo, !!opts->addr.port); + len = mptcp_add_addr_len(addr.family, echo, !!addr.port); if (remaining < len) return false; @@ -689,6 +690,7 @@ static bool mptcp_established_options_add_addr(struct sock *sk, struct sk_buff * opts->ahmac = 0; *size -= opt_size; } + opts->addr = addr; opts->suboptions |= OPTION_MPTCP_ADD_ADDR; if (!echo) { MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_ADDADDRTX); -- 2.48.1

3 months, 3 weeks

2
2
0 0

[PATCH net 3/3] mptcp: sockopt: fix getting freebind & transparent

by Matthieu Baerts (NGI0)

When adding a socket option support in MPTCP, both the get and set parts are supposed to be implemented. IP(V6)_FREEBIND and IP(V6)_TRANSPARENT support for the setsockopt part has been added a while ago, but it looks like the get part got forgotten. It should have been present as a way to verify a setting has been set as expected, and not to act differently from TCP or any other socket types. Everything was in place to expose it, just the last step was missing. Only new code is added to cover these specific getsockopt(), that seems safe. Fixes: c9406a23c116 ("mptcp: sockopt: add SOL_IP freebind & transparent options") Cc: stable(a)vger.kernel.org Reviewed-by: Mat Martineau <martineau(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- net/mptcp/sockopt.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c index 4b99eb796855e4578d14df90f9d1cc3f1cd5b8c7..3caa0a9d3b3885ce6399570f2d98a2e8f103638d 100644 --- a/net/mptcp/sockopt.c +++ b/net/mptcp/sockopt.c @@ -1419,6 +1419,12 @@ static int mptcp_getsockopt_v4(struct mptcp_sock *msk, int optname, switch (optname) { case IP_TOS: return mptcp_put_int_option(msk, optval, optlen, READ_ONCE(inet_sk(sk)->tos)); + case IP_FREEBIND: + return mptcp_put_int_option(msk, optval, optlen, + inet_test_bit(FREEBIND, sk)); + case IP_TRANSPARENT: + return mptcp_put_int_option(msk, optval, optlen, + inet_test_bit(TRANSPARENT, sk)); case IP_BIND_ADDRESS_NO_PORT: return mptcp_put_int_option(msk, optval, optlen, inet_test_bit(BIND_ADDRESS_NO_PORT, sk)); @@ -1439,6 +1445,12 @@ static int mptcp_getsockopt_v6(struct mptcp_sock *msk, int optname, case IPV6_V6ONLY: return mptcp_put_int_option(msk, optval, optlen, sk->sk_ipv6only); + case IPV6_TRANSPARENT: + return mptcp_put_int_option(msk, optval, optlen, + inet_test_bit(TRANSPARENT, sk)); + case IPV6_FREEBIND: + return mptcp_put_int_option(msk, optval, optlen, + inet_test_bit(FREEBIND, sk)); } return -EOPNOTSUPP; -- 2.48.1

3 months, 3 weeks

2
1
0 0

[PATCH 01/15] proc: fix UAF in proc_get_inode()

by Ayaan Mirza Baig

From: Ye Bin <yebin10(a)huawei.com> Fix race between rmmod and /proc/XXX's inode instantiation. The bug is that pde->proc_ops don't belong to /proc, it belongs to a module, therefore dereferencing it after /proc entry has been registered is a bug unless use_pde/unuse_pde() pair has been used. use_pde/unuse_pde can be avoided (2 atomic ops!) because pde->proc_ops never changes so information necessary for inode instantiation can be saved _before_ proc_register() in PDE itself and used later, avoiding pde->proc_ops->... dereference. rmmod lookup sys_delete_module proc_lookup_de pde_get(de); proc_get_inode(dir->i_sb, de); mod->exit() proc_remove remove_proc_subtree proc_entry_rundown(de); free_module(mod); if (S_ISREG(inode->i_mode)) if (de->proc_ops->proc_read_iter) --> As module is already freed, will trigger UAF BUG: unable to handle page fault for address: fffffbfff80a702b PGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: G Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:proc_get_inode+0x302/0x6e0 RSP: 0018:ffff88811c837998 EFLAGS: 00010a06 RAX: dffffc0000000000 RBX: ffffffffc0538140 RCX: 0000000000000007 RDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158 RBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20 R10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0 R13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001 FS: 00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> proc_lookup_de+0x11f/0x2e0 __lookup_slow+0x188/0x350 walk_component+0x2ab/0x4f0 path_lookupat+0x120/0x660 filename_lookup+0x1ce/0x560 vfs_statx+0xac/0x150 __do_sys_newstat+0x96/0x110 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e [adobriyan(a)gmail.com: don't do 2 atomic ops on the common path] Link: https://lkml.kernel.org/r/3d25ded0-1739-447e-812b-e34da7990dcf@p183 Fixes: 778f3dd5a13c ("Fix procfs compat_ioctl regression") Signed-off-by: Ye Bin <yebin10(a)huawei.com> Signed-off-by: Alexey Dobriyan <adobriyan(a)gmail.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: David S. Miller <davem(a)davemloft.net> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Ayaan Mirza Baig <ayaanmirzabaig85(a)gmail.com> --- fs/proc/generic.c | 10 +++++++++- fs/proc/inode.c | 6 +++--- fs/proc/internal.h | 14 ++++++++++++++ include/linux/proc_fs.h | 7 +++++-- 4 files changed, 31 insertions(+), 6 deletions(-) diff --git a/fs/proc/generic.c b/fs/proc/generic.c index 8ec90826a49e..a3e22803cddf 100644 --- a/fs/proc/generic.c +++ b/fs/proc/generic.c @@ -559,10 +559,16 @@ struct proc_dir_entry *proc_create_reg(const char *name, umode_t mode, return p; } -static inline void pde_set_flags(struct proc_dir_entry *pde) +static void pde_set_flags(struct proc_dir_entry *pde) { if (pde->proc_ops->proc_flags & PROC_ENTRY_PERMANENT) pde->flags |= PROC_ENTRY_PERMANENT; + if (pde->proc_ops->proc_read_iter) + pde->flags |= PROC_ENTRY_proc_read_iter; +#ifdef CONFIG_COMPAT + if (pde->proc_ops->proc_compat_ioctl) + pde->flags |= PROC_ENTRY_proc_compat_ioctl; +#endif } struct proc_dir_entry *proc_create_data(const char *name, umode_t mode, @@ -626,6 +632,7 @@ struct proc_dir_entry *proc_create_seq_private(const char *name, umode_t mode, p->proc_ops = &proc_seq_ops; p->seq_ops = ops; p->state_size = state_size; + pde_set_flags(p); return proc_register(parent, p); } EXPORT_SYMBOL(proc_create_seq_private); @@ -656,6 +663,7 @@ struct proc_dir_entry *proc_create_single_data(const char *name, umode_t mode, return NULL; p->proc_ops = &proc_single_ops; p->single_show = show; + pde_set_flags(p); return proc_register(parent, p); } EXPORT_SYMBOL(proc_create_single_data); diff --git a/fs/proc/inode.c b/fs/proc/inode.c index 626ad7bd94f2..a3eb3b740f76 100644 --- a/fs/proc/inode.c +++ b/fs/proc/inode.c @@ -656,13 +656,13 @@ struct inode *proc_get_inode(struct super_block *sb, struct proc_dir_entry *de) if (S_ISREG(inode->i_mode)) { inode->i_op = de->proc_iops; - if (de->proc_ops->proc_read_iter) + if (pde_has_proc_read_iter(de)) inode->i_fop = &proc_iter_file_ops; else inode->i_fop = &proc_reg_file_ops; #ifdef CONFIG_COMPAT - if (de->proc_ops->proc_compat_ioctl) { - if (de->proc_ops->proc_read_iter) + if (pde_has_proc_compat_ioctl(de)) { + if (pde_has_proc_read_iter(de)) inode->i_fop = &proc_iter_file_ops_compat; else inode->i_fop = &proc_reg_file_ops_compat; diff --git a/fs/proc/internal.h b/fs/proc/internal.h index 1695509370b8..77a517f91821 100644 --- a/fs/proc/internal.h +++ b/fs/proc/internal.h @@ -85,6 +85,20 @@ static inline void pde_make_permanent(struct proc_dir_entry *pde) pde->flags |= PROC_ENTRY_PERMANENT; } +static inline bool pde_has_proc_read_iter(const struct proc_dir_entry *pde) +{ + return pde->flags & PROC_ENTRY_proc_read_iter; +} + +static inline bool pde_has_proc_compat_ioctl(const struct proc_dir_entry *pde) +{ +#ifdef CONFIG_COMPAT + return pde->flags & PROC_ENTRY_proc_compat_ioctl; +#else + return false; +#endif +} + extern struct kmem_cache *proc_dir_entry_cache; void pde_free(struct proc_dir_entry *pde); diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h index 0b2a89854440..ea62201c74c4 100644 --- a/include/linux/proc_fs.h +++ b/include/linux/proc_fs.h @@ -20,10 +20,13 @@ enum { * If in doubt, ignore this flag. */ #ifdef MODULE - PROC_ENTRY_PERMANENT = 0U, + PROC_ENTRY_PERMANENT = 0U, #else - PROC_ENTRY_PERMANENT = 1U << 0, + PROC_ENTRY_PERMANENT = 1U << 0, #endif + + PROC_ENTRY_proc_read_iter = 1U << 1, + PROC_ENTRY_proc_compat_ioctl = 1U << 2, }; struct proc_ops { -- 2.48.1

3 months, 3 weeks

1
0
0 0

[PATCH RESEND] fs/netfs/read_collect: add to next->prev_donated

by Max Kellermann

If multiple subrequests donate data to the same "next" request (depending on the subrequest completion order), each of them would overwrite the `prev_donated` field, causing data corruption and a BUG() crash ("Can't donate prior to front"). Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") Closes: https://lore.kernel.org/netfs/CAKPOu+_4mUwYgQtRTbXCmi+-k3PGvLysnPadkmHOyB7G… Cc: stable(a)vger.kernel.org Signed-off-by: Max Kellermann <max.kellermann(a)ionos.com> Signed-off-by: David Howells <dhowells(a)redhat.com> --- fs/netfs/read_collect.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/netfs/read_collect.c b/fs/netfs/read_collect.c index 8878b46589ff..cafadfe8e858 100644 --- a/fs/netfs/read_collect.c +++ b/fs/netfs/read_collect.c @@ -284,7 +284,7 @@ static bool netfs_consume_read_data(struct netfs_io_subrequest *subreq, bool was netfs_trace_donate_to_deferred_next); } else { next = list_next_entry(subreq, rreq_link); - WRITE_ONCE(next->prev_donated, excess); + WRITE_ONCE(next->prev_donated, next->prev_donated + excess); trace_netfs_donate(rreq, subreq, next, excess, netfs_trace_donate_to_next); } -- 2.47.2

3 months, 3 weeks

4
3
0 0

6.6.84-rc1 build regression on ia64 (and possibly other architectures)

by Frank Scheiner

Dear Greg, I see that the review for 6.6.84-rc1 hasn't started yet, but as it was already available on [1], our CI has already tried to built it for ia64 in the morning. Unfortunately that failed - I assume due to the following **missing** upstream commit: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm… [1]: https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.… Build failure (see [2]): ``` [...] CC drivers/video/fbdev/core/fbcon.o drivers/video/fbdev/core/fbcon.c: In function 'fb_console_setup': drivers/video/fbdev/core/fbcon.c:478:33: error: 'fb_center_logo' undeclared (first use in this function); did you mean 'fb_prepare_logo'? 478 | fb_center_logo = true; | ^~~~~~~~~~~~~~ | fb_prepare_logo drivers/video/fbdev/core/fbcon.c:478:33: note: each undeclared identifier is reported only once for each function it appears in drivers/video/fbdev/core/fbcon.c:485:33: error: 'fb_logo_count' undeclared (first use in this function); did you mean 'file_count'? 485 | fb_logo_count = simple_strtol(options, &options, 0); | ^~~~~~~~~~~~~ | file_count make[8]: *** [scripts/Makefile.build:243: drivers/video/fbdev/core/fbcon.o] Error 1 [...] ``` [2]: https://github.com/linux-ia64/linux-stable-rc/actions/runs/13914712427/job/… [3] (fa671e4f1556e2c18e5443f777a75ae041290068 upstream) includes definitions for these variables, but they are guarded by CONFIG_LOGO. But in `drivers/video/fbdev/core/fbcon.c` those variables are used unguarded with 6.6.84-rc1. The above upstream commit (8887086) fixes that IIUC. Not build-tested yet, though. [3]: https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.… Cheers, Frank

3 months, 3 weeks

2
1
0 0

RE: Transform your business

by kristina williams

Hi again, I would appreciate your feedback on the proposal I sent earlier. Looking forward to your response. Best regards, Kristina ________________________________ From: Kristina Williams Sent: 17 March 2025 12:29 To: linux-stable-mirror(a)lists.linaro.org<mailto:linux-stable-mirror@lists.linaro.org> Subject: Transform your business Hi there, Would you like an updated contact list of Real Estate CRM Software users and customers? We can also provide contact lists for users and customers of the following companies: * AppFolio * RealPage * Buildium * CoreLogic * Yardi Voyager * Kissflow CRM * Pipedrive * HubSpot CRM Service and more... Please specify the target technology users and geographical areas of interest, so we can provide relevant information accordingly. Kind regards, Kristina Williams Lead Specialist To unsubscribe from future emails, simply reply with Stop.

3 months, 3 weeks

1
0
0 0

Re: Patch "nvme-fc: do not ignore connectivity loss during connecting" has been added to the 6.13-stable tree

by Daniel Wagner

Hi Sasha, On Sat, Mar 15, 2025 at 09:34:40AM -0400, Sasha Levin wrote: > 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. This fix is unfortunately buggy (schedule in atomic context). There is a fixup patch which would be necessary alongside this patch: f13409bb3f91 ("nvme-fc: rely on state transitions to handle connectivity loss") Thanks, Daniel > commit e0cdcd023334a757ae78a43d2fa8909dcc72ec56 > Author: Daniel Wagner <wagi(a)kernel.org> > Date: Thu Jan 9 14:30:49 2025 +0100 > > nvme-fc: do not ignore connectivity loss during connecting

3 months, 3 weeks

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror