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

[PATCH 6.6.x] btrfs: add cancellation points to trim loops

by David Sterba

From: Luca Stefani <luca.stefani.ge1(a)gmail.com> There are reports that system cannot suspend due to running trim because the task responsible for trimming the device isn't able to finish in time, especially since we have a free extent discarding phase, which can trim a lot of unallocated space. There are no limits on the trim size (unlike the block group part). Since trime isn't a critical call it can be interrupted at any time, in such cases we stop the trim, report the amount of discarded bytes and return an error. Link: https://bugzilla.kernel.org/show_bug.cgi?id=219180 Link: https://bugzilla.suse.com/show_bug.cgi?id=1229737 CC: stable(a)vger.kernel.org # 5.15+ Signed-off-by: Luca Stefani <luca.stefani.ge1(a)gmail.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> --- fs/btrfs/extent-tree.c | 7 ++++++- fs/btrfs/free-space-cache.c | 4 ++-- fs/btrfs/free-space-cache.h | 7 +++++++ 3 files changed, 15 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index b3680e1c7054..599407120513 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -1319,6 +1319,11 @@ static int btrfs_issue_discard(struct block_device *bdev, u64 start, u64 len, start += bytes_to_discard; bytes_left -= bytes_to_discard; *discarded_bytes += bytes_to_discard; + + if (btrfs_trim_interrupted()) { + ret = -ERESTARTSYS; + break; + } } return ret; @@ -6094,7 +6099,7 @@ static int btrfs_trim_free_extents(struct btrfs_device *device, u64 *trimmed) start += len; *trimmed += bytes; - if (fatal_signal_pending(current)) { + if (btrfs_trim_interrupted()) { ret = -ERESTARTSYS; break; } diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c index 3bcf4a30cad7..9a6ec9344c3e 100644 --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -3808,7 +3808,7 @@ static int trim_no_bitmap(struct btrfs_block_group *block_group, if (async && *total_trimmed) break; - if (fatal_signal_pending(current)) { + if (btrfs_trim_interrupted()) { ret = -ERESTARTSYS; break; } @@ -3999,7 +3999,7 @@ static int trim_bitmaps(struct btrfs_block_group *block_group, } block_group->discard_cursor = start; - if (fatal_signal_pending(current)) { + if (btrfs_trim_interrupted()) { if (start != offset) reset_trimming_bitmap(ctl, offset); ret = -ERESTARTSYS; diff --git a/fs/btrfs/free-space-cache.h b/fs/btrfs/free-space-cache.h index 33b4da3271b1..bd80c7b2af96 100644 --- a/fs/btrfs/free-space-cache.h +++ b/fs/btrfs/free-space-cache.h @@ -6,6 +6,8 @@ #ifndef BTRFS_FREE_SPACE_CACHE_H #define BTRFS_FREE_SPACE_CACHE_H +#include <linux/freezer.h> + /* * This is the trim state of an extent or bitmap. * @@ -43,6 +45,11 @@ static inline bool btrfs_free_space_trimming_bitmap( return (info->trim_state == BTRFS_TRIM_STATE_TRIMMING); } +static inline bool btrfs_trim_interrupted(void) +{ + return fatal_signal_pending(current) || freezing(current); +} + /* * Deltas are an effective way to populate global statistics. Give macro names * to make it clear what we're doing. An example is discard_extents in -- 2.45.0

2 months

5
6
0 0

FAILED: patch "[PATCH] iio: adc: ad7923: Fix buffer overflow for tx_buf and" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 3a4187ec454e19903fd15f6e1825a4b84e59a4cd # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024120633-brutishly-whisking-17ca@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 3a4187ec454e19903fd15f6e1825a4b84e59a4cd Mon Sep 17 00:00:00 2001 From: Nuno Sa <nuno.sa(a)analog.com> Date: Tue, 29 Oct 2024 13:46:37 +0000 Subject: [PATCH] iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer The AD7923 was updated to support devices with 8 channels, but the size of tx_buf and ring_xfer was not increased accordingly, leading to a potential buffer overflow in ad7923_update_scan_mode(). Fixes: 851644a60d20 ("iio: adc: ad7923: Add support for the ad7908/ad7918/ad7928") Cc: stable(a)vger.kernel.org Signed-off-by: Nuno Sa <nuno.sa(a)analog.com> Signed-off-by: Zicheng Qu <quzicheng(a)huawei.com> Link: https://patch.msgid.link/20241029134637.2261336-1-quzicheng@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/adc/ad7923.c b/drivers/iio/adc/ad7923.c index 09680015a7ab..acc44cb34f82 100644 --- a/drivers/iio/adc/ad7923.c +++ b/drivers/iio/adc/ad7923.c @@ -48,7 +48,7 @@ struct ad7923_state { struct spi_device *spi; - struct spi_transfer ring_xfer[5]; + struct spi_transfer ring_xfer[9]; struct spi_transfer scan_single_xfer[2]; struct spi_message ring_msg; struct spi_message scan_single_msg; @@ -64,7 +64,7 @@ struct ad7923_state { * Length = 8 channels + 4 extra for 8 byte timestamp */ __be16 rx_buf[12] __aligned(IIO_DMA_MINALIGN); - __be16 tx_buf[4]; + __be16 tx_buf[8]; }; struct ad7923_chip_info {

2 months

1
0
0 0

FAILED: patch "[PATCH] iio: adc: ad7923: Fix buffer overflow for tx_buf and" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 3a4187ec454e19903fd15f6e1825a4b84e59a4cd # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024120632-reprogram-skyrocket-0fdd@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 3a4187ec454e19903fd15f6e1825a4b84e59a4cd Mon Sep 17 00:00:00 2001 From: Nuno Sa <nuno.sa(a)analog.com> Date: Tue, 29 Oct 2024 13:46:37 +0000 Subject: [PATCH] iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer The AD7923 was updated to support devices with 8 channels, but the size of tx_buf and ring_xfer was not increased accordingly, leading to a potential buffer overflow in ad7923_update_scan_mode(). Fixes: 851644a60d20 ("iio: adc: ad7923: Add support for the ad7908/ad7918/ad7928") Cc: stable(a)vger.kernel.org Signed-off-by: Nuno Sa <nuno.sa(a)analog.com> Signed-off-by: Zicheng Qu <quzicheng(a)huawei.com> Link: https://patch.msgid.link/20241029134637.2261336-1-quzicheng@huawei.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/adc/ad7923.c b/drivers/iio/adc/ad7923.c index 09680015a7ab..acc44cb34f82 100644 --- a/drivers/iio/adc/ad7923.c +++ b/drivers/iio/adc/ad7923.c @@ -48,7 +48,7 @@ struct ad7923_state { struct spi_device *spi; - struct spi_transfer ring_xfer[5]; + struct spi_transfer ring_xfer[9]; struct spi_transfer scan_single_xfer[2]; struct spi_message ring_msg; struct spi_message scan_single_msg; @@ -64,7 +64,7 @@ struct ad7923_state { * Length = 8 channels + 4 extra for 8 byte timestamp */ __be16 rx_buf[12] __aligned(IIO_DMA_MINALIGN); - __be16 tx_buf[4]; + __be16 tx_buf[8]; }; struct ad7923_chip_info {

2 months

1
0
0 0

FAILED: patch "[PATCH] leds: flash: mt6360: Fix device_for_each_child_node()" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 73b03b27736e440e3009fe1319cbc82d2cd1290c # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024120654-feminize-upstart-b8c4@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 73b03b27736e440e3009fe1319cbc82d2cd1290c Mon Sep 17 00:00:00 2001 From: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> Date: Fri, 27 Sep 2024 01:20:52 +0200 Subject: [PATCH] leds: flash: mt6360: Fix device_for_each_child_node() refcounting in error paths The device_for_each_child_node() macro requires explicit calls to fwnode_handle_put() upon early exits to avoid memory leaks, and in this case the error paths are handled after jumping to 'out_flash_realease', which misses that required call to to decrement the refcount of the child node. A more elegant and robust solution is using the scoped variant of the loop, which automatically handles such early exits. Fix the child node refcounting in the error paths by using device_for_each_child_node_scoped(). Cc: stable(a)vger.kernel.org Fixes: 679f8652064b ("leds: Add mt6360 driver") Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> Link: https://lore.kernel.org/r/20240927-leds_device_for_each_child_node_scoped-v… Signed-off-by: Lee Jones <lee(a)kernel.org> diff --git a/drivers/leds/flash/leds-mt6360.c b/drivers/leds/flash/leds-mt6360.c index 4c74f1cf01f0..676236c19ec4 100644 --- a/drivers/leds/flash/leds-mt6360.c +++ b/drivers/leds/flash/leds-mt6360.c @@ -784,7 +784,6 @@ static void mt6360_v4l2_flash_release(struct mt6360_priv *priv) static int mt6360_led_probe(struct platform_device *pdev) { struct mt6360_priv *priv; - struct fwnode_handle *child; size_t count; int i = 0, ret; @@ -811,7 +810,7 @@ static int mt6360_led_probe(struct platform_device *pdev) return -ENODEV; } - device_for_each_child_node(&pdev->dev, child) { + device_for_each_child_node_scoped(&pdev->dev, child) { struct mt6360_led *led = priv->leds + i; struct led_init_data init_data = { .fwnode = child, }; u32 reg, led_color;

2 months

1
0
0 0

[tip: x86/urgent] cacheinfo: Allocate memory during CPU hotplug if not done from the primary CPU

by tip-bot2 for Ricardo Neri

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: b3fce429a1e030b50c1c91351d69b8667eef627b Gitweb: https://git.kernel.org/tip/b3fce429a1e030b50c1c91351d69b8667eef627b Author: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> AuthorDate: Wed, 27 Nov 2024 16:22:46 -08:00 Committer: Borislav Petkov (AMD) <bp(a)alien8.de> CommitterDate: Fri, 06 Dec 2024 13:07:47 +01:00 cacheinfo: Allocate memory during CPU hotplug if not done from the primary CPU Commit 5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU") adds functionality that architectures can use to optionally allocate and build cacheinfo early during boot. Commit 6539cffa9495 ("cacheinfo: Add arch specific early level initializer") lets secondary CPUs correct (and reallocate memory) cacheinfo data if needed. If the early build functionality is not used and cacheinfo does not need correction, memory for cacheinfo is never allocated. x86 does not use the early build functionality. Consequently, during the cacheinfo CPU hotplug callback, last_level_cache_is_valid() attempts to dereference a NULL pointer: BUG: kernel NULL pointer dereference, address: 0000000000000100 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not present page PGD 0 P4D 0 Oops: 0000 [#1] PREEPMT SMP NOPTI CPU: 0 PID 19 Comm: cpuhp/0 Not tainted 6.4.0-rc2 #1 RIP: 0010: last_level_cache_is_valid+0x95/0xe0a Allocate memory for cacheinfo during the cacheinfo CPU hotplug callback if not done earlier. Moreover, before determining the validity of the last-level cache info, ensure that it has been allocated. Simply checking for non-zero cache_leaves() is not sufficient, as some architectures (e.g., Intel processors) have non-zero cache_leaves() before allocation. Dereferencing NULL cacheinfo can occur in update_per_cpu_data_slice_size(). This function iterates over all online CPUs. However, a CPU may have come online recently, but its cacheinfo may not have been allocated yet. While here, remove an unnecessary indentation in allocate_cache_info(). [ bp: Massage. ] Fixes: 6539cffa9495 ("cacheinfo: Add arch specific early level initializer") Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Reviewed-by: Radu Rendec <rrendec(a)redhat.com> Reviewed-by: Nikolay Borisov <nik.borisov(a)suse.com> Reviewed-by: Andreas Herrmann <aherrmann(a)suse.de> Reviewed-by: Sudeep Holla <sudeep.holla(a)arm.com> Cc: stable(a)vger.kernel.org # 6.3+ Link: https://lore.kernel.org/r/20241128002247.26726-2-ricardo.neri-calderon@linu… --- drivers/base/cacheinfo.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c index 609935a..cf0d455 100644 --- a/drivers/base/cacheinfo.c +++ b/drivers/base/cacheinfo.c @@ -58,7 +58,7 @@ bool last_level_cache_is_valid(unsigned int cpu) { struct cacheinfo *llc; - if (!cache_leaves(cpu)) + if (!cache_leaves(cpu) || !per_cpu_cacheinfo(cpu)) return false; llc = per_cpu_cacheinfo_idx(cpu, cache_leaves(cpu) - 1); @@ -458,11 +458,9 @@ int __weak populate_cache_leaves(unsigned int cpu) return -ENOENT; } -static inline -int allocate_cache_info(int cpu) +static inline int allocate_cache_info(int cpu) { - per_cpu_cacheinfo(cpu) = kcalloc(cache_leaves(cpu), - sizeof(struct cacheinfo), GFP_ATOMIC); + per_cpu_cacheinfo(cpu) = kcalloc(cache_leaves(cpu), sizeof(struct cacheinfo), GFP_ATOMIC); if (!per_cpu_cacheinfo(cpu)) { cache_leaves(cpu) = 0; return -ENOMEM; @@ -534,7 +532,11 @@ static inline int init_level_allocate_ci(unsigned int cpu) */ ci_cacheinfo(cpu)->early_ci_levels = false; - if (cache_leaves(cpu) <= early_leaves) + /* + * Some architectures (e.g., x86) do not use early initialization. + * Allocate memory now in such case. + */ + if (cache_leaves(cpu) <= early_leaves && per_cpu_cacheinfo(cpu)) return 0; kfree(per_cpu_cacheinfo(cpu));

2 months

1
0
0 0

[tip: x86/urgent] x86/cacheinfo: Delete global num_cache_leaves

by tip-bot2 for Ricardo Neri

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 9677be09e5e4fbe48aeccb06ae3063c5eba331c3 Gitweb: https://git.kernel.org/tip/9677be09e5e4fbe48aeccb06ae3063c5eba331c3 Author: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> AuthorDate: Wed, 27 Nov 2024 16:22:47 -08:00 Committer: Borislav Petkov (AMD) <bp(a)alien8.de> CommitterDate: Fri, 06 Dec 2024 13:13:36 +01:00 x86/cacheinfo: Delete global num_cache_leaves Linux remembers cpu_cachinfo::num_leaves per CPU, but x86 initializes all CPUs from the same global "num_cache_leaves". This is erroneous on systems such as Meteor Lake, where each CPU has a distinct num_leaves value. Delete the global "num_cache_leaves" and initialize num_leaves on each CPU. init_cache_level() no longer needs to set num_leaves. Also, it never had to set num_levels as it is unnecessary in x86. Keep checking for zero cache leaves. Such condition indicates a bug. [ bp: Cleanup. ] Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Cc: stable(a)vger.kernel.org # 6.3+ Link: https://lore.kernel.org/r/20241128002247.26726-3-ricardo.neri-calderon@linu… --- arch/x86/kernel/cpu/cacheinfo.c | 43 +++++++++++++++----------------- 1 file changed, 21 insertions(+), 22 deletions(-) diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c index 392d09c..e6fa03e 100644 --- a/arch/x86/kernel/cpu/cacheinfo.c +++ b/arch/x86/kernel/cpu/cacheinfo.c @@ -178,8 +178,6 @@ struct _cpuid4_info_regs { struct amd_northbridge *nb; }; -static unsigned short num_cache_leaves; - /* AMD doesn't have CPUID4. Emulate it here to report the same information to the user. This makes some assumptions about the machine: L2 not shared, no SMT etc. that is currently true on AMD CPUs. @@ -717,20 +715,23 @@ void cacheinfo_hygon_init_llc_id(struct cpuinfo_x86 *c) void init_amd_cacheinfo(struct cpuinfo_x86 *c) { + struct cpu_cacheinfo *ci = get_cpu_cacheinfo(c->cpu_index); if (boot_cpu_has(X86_FEATURE_TOPOEXT)) { - num_cache_leaves = find_num_cache_leaves(c); + ci->num_leaves = find_num_cache_leaves(c); } else if (c->extended_cpuid_level >= 0x80000006) { if (cpuid_edx(0x80000006) & 0xf000) - num_cache_leaves = 4; + ci->num_leaves = 4; else - num_cache_leaves = 3; + ci->num_leaves = 3; } } void init_hygon_cacheinfo(struct cpuinfo_x86 *c) { - num_cache_leaves = find_num_cache_leaves(c); + struct cpu_cacheinfo *ci = get_cpu_cacheinfo(c->cpu_index); + + ci->num_leaves = find_num_cache_leaves(c); } void init_intel_cacheinfo(struct cpuinfo_x86 *c) @@ -740,21 +741,21 @@ void init_intel_cacheinfo(struct cpuinfo_x86 *c) unsigned int new_l1d = 0, new_l1i = 0; /* Cache sizes from cpuid(4) */ unsigned int new_l2 = 0, new_l3 = 0, i; /* Cache sizes from cpuid(4) */ unsigned int l2_id = 0, l3_id = 0, num_threads_sharing, index_msb; + struct cpu_cacheinfo *ci = get_cpu_cacheinfo(c->cpu_index); if (c->cpuid_level > 3) { - static int is_initialized; - - if (is_initialized == 0) { - /* Init num_cache_leaves from boot CPU */ - num_cache_leaves = find_num_cache_leaves(c); - is_initialized++; - } + /* + * There should be at least one leaf. A non-zero value means + * that the number of leaves has been initialized. + */ + if (!ci->num_leaves) + ci->num_leaves = find_num_cache_leaves(c); /* * Whenever possible use cpuid(4), deterministic cache * parameters cpuid leaf to find the cache details */ - for (i = 0; i < num_cache_leaves; i++) { + for (i = 0; i < ci->num_leaves; i++) { struct _cpuid4_info_regs this_leaf = {}; int retval; @@ -790,14 +791,14 @@ void init_intel_cacheinfo(struct cpuinfo_x86 *c) * Don't use cpuid2 if cpuid4 is supported. For P4, we use cpuid2 for * trace cache */ - if ((num_cache_leaves == 0 || c->x86 == 15) && c->cpuid_level > 1) { + if ((!ci->num_leaves || c->x86 == 15) && c->cpuid_level > 1) { /* supports eax=2 call */ int j, n; unsigned int regs[4]; unsigned char *dp = (unsigned char *)regs; int only_trace = 0; - if (num_cache_leaves != 0 && c->x86 == 15) + if (ci->num_leaves && c->x86 == 15) only_trace = 1; /* Number of times to iterate */ @@ -991,14 +992,12 @@ static void ci_leaf_init(struct cacheinfo *this_leaf, int init_cache_level(unsigned int cpu) { - struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu); + struct cpu_cacheinfo *ci = get_cpu_cacheinfo(cpu); - if (!num_cache_leaves) + /* There should be at least one leaf. */ + if (!ci->num_leaves) return -ENOENT; - if (!this_cpu_ci) - return -EINVAL; - this_cpu_ci->num_levels = 3; - this_cpu_ci->num_leaves = num_cache_leaves; + return 0; }

2 months

1
0
0 0

FAILED: patch "[PATCH] PCI: endpoint: Clear secondary (not primary) EPC in" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 688d2eb4c6fcfdcdaed0592f9df9196573ff5ce2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024120649-cranium-uncle-f7f1@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 688d2eb4c6fcfdcdaed0592f9df9196573ff5ce2 Mon Sep 17 00:00:00 2001 From: Zijun Hu <quic_zijuhu(a)quicinc.com> Date: Thu, 7 Nov 2024 08:53:09 +0800 Subject: [PATCH] PCI: endpoint: Clear secondary (not primary) EPC in pci_epc_remove_epf() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In addition to a primary endpoint controller, an endpoint function may be associated with a secondary endpoint controller, epf->sec_epc, to provide NTB (non-transparent bridge) functionality. Previously, pci_epc_remove_epf() incorrectly cleared epf->epc instead of epf->sec_epc when removing from the secondary endpoint controller. Extend the epc->list_lock coverage and clear either epf->epc or epf->sec_epc as indicated. Link: https://lore.kernel.org/r/20241107-epc_rfc-v2-2-da5b6a99a66f@quicinc.com Fixes: 63840ff53223 ("PCI: endpoint: Add support to associate secondary EPC with EPF") Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> [mani: reworded subject and description] Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski(a)kernel.org> Cc: stable(a)vger.kernel.org diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c index 21af2dbacc33..bed7c7d1fe3c 100644 --- a/drivers/pci/endpoint/pci-epc-core.c +++ b/drivers/pci/endpoint/pci-epc-core.c @@ -746,18 +746,18 @@ void pci_epc_remove_epf(struct pci_epc *epc, struct pci_epf *epf, if (IS_ERR_OR_NULL(epc) || !epf) return; + mutex_lock(&epc->list_lock); if (type == PRIMARY_INTERFACE) { func_no = epf->func_no; list = &epf->list; + epf->epc = NULL; } else { func_no = epf->sec_epc_func_no; list = &epf->sec_epc_list; + epf->sec_epc = NULL; } - - mutex_lock(&epc->list_lock); clear_bit(func_no, &epc->function_num_map); list_del(list); - epf->epc = NULL; mutex_unlock(&epc->list_lock); } EXPORT_SYMBOL_GPL(pci_epc_remove_epf);

2 months

1
0
0 0

FAILED: patch "[PATCH] PCI: endpoint: Clear secondary (not primary) EPC in" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 688d2eb4c6fcfdcdaed0592f9df9196573ff5ce2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024120648-rigging-lying-eda9@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 688d2eb4c6fcfdcdaed0592f9df9196573ff5ce2 Mon Sep 17 00:00:00 2001 From: Zijun Hu <quic_zijuhu(a)quicinc.com> Date: Thu, 7 Nov 2024 08:53:09 +0800 Subject: [PATCH] PCI: endpoint: Clear secondary (not primary) EPC in pci_epc_remove_epf() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In addition to a primary endpoint controller, an endpoint function may be associated with a secondary endpoint controller, epf->sec_epc, to provide NTB (non-transparent bridge) functionality. Previously, pci_epc_remove_epf() incorrectly cleared epf->epc instead of epf->sec_epc when removing from the secondary endpoint controller. Extend the epc->list_lock coverage and clear either epf->epc or epf->sec_epc as indicated. Link: https://lore.kernel.org/r/20241107-epc_rfc-v2-2-da5b6a99a66f@quicinc.com Fixes: 63840ff53223 ("PCI: endpoint: Add support to associate secondary EPC with EPF") Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> [mani: reworded subject and description] Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski(a)kernel.org> Cc: stable(a)vger.kernel.org diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c index 21af2dbacc33..bed7c7d1fe3c 100644 --- a/drivers/pci/endpoint/pci-epc-core.c +++ b/drivers/pci/endpoint/pci-epc-core.c @@ -746,18 +746,18 @@ void pci_epc_remove_epf(struct pci_epc *epc, struct pci_epf *epf, if (IS_ERR_OR_NULL(epc) || !epf) return; + mutex_lock(&epc->list_lock); if (type == PRIMARY_INTERFACE) { func_no = epf->func_no; list = &epf->list; + epf->epc = NULL; } else { func_no = epf->sec_epc_func_no; list = &epf->sec_epc_list; + epf->sec_epc = NULL; } - - mutex_lock(&epc->list_lock); clear_bit(func_no, &epc->function_num_map); list_del(list); - epf->epc = NULL; mutex_unlock(&epc->list_lock); } EXPORT_SYMBOL_GPL(pci_epc_remove_epf);

2 months

1
0
0 0

FAILED: patch "[PATCH] PCI: keystone: Set mode as Root Complex for" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 5a938ed9481b0c06cb97aec45e722a80568256fd # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024120615-backlands-caboose-2224@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5a938ed9481b0c06cb97aec45e722a80568256fd Mon Sep 17 00:00:00 2001 From: Kishon Vijay Abraham I <kishon(a)ti.com> Date: Fri, 24 May 2024 16:27:13 +0530 Subject: [PATCH] PCI: keystone: Set mode as Root Complex for "ti,keystone-pcie" compatible MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit commit 23284ad677a9 ("PCI: keystone: Add support for PCIe EP in AM654x Platforms") introduced configuring "enum dw_pcie_device_mode" as part of device data ("struct ks_pcie_of_data"). However it failed to set the mode for "ti,keystone-pcie" compatible. Since the mode defaults to "DW_PCIE_UNKNOWN_TYPE", the following error message is displayed for the v3.65a controller: "INVALID device type 0" Despite the driver probing successfully, the controller may not be functional in the Root Complex mode of operation. So, set the mode as Root Complex for "ti,keystone-pcie" compatible to fix this. Fixes: 23284ad677a9 ("PCI: keystone: Add support for PCIe EP in AM654x Platforms") Link: https://lore.kernel.org/r/20240524105714.191642-2-s-vadapalli@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com> Signed-off-by: Siddharth Vadapalli <s-vadapalli(a)ti.com> [kwilczynski: commit log, added tag for stable releases] Signed-off-by: Krzysztof Wilczyński <kwilczynski(a)kernel.org> Cc: stable(a)vger.kernel.org diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c index 2219b1a866fa..b99bc4071fe9 100644 --- a/drivers/pci/controller/dwc/pci-keystone.c +++ b/drivers/pci/controller/dwc/pci-keystone.c @@ -1093,6 +1093,7 @@ static int ks_pcie_am654_set_mode(struct device *dev, static const struct ks_pcie_of_data ks_pcie_rc_of_data = { .host_ops = &ks_pcie_host_ops, + .mode = DW_PCIE_RC_TYPE, .version = DW_PCIE_VER_365A, };

2 months

1
0
0 0

FAILED: patch "[PATCH] PCI: keystone: Set mode as Root Complex for" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 5a938ed9481b0c06cb97aec45e722a80568256fd # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024120616-pucker-unlisted-7c65@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5a938ed9481b0c06cb97aec45e722a80568256fd Mon Sep 17 00:00:00 2001 From: Kishon Vijay Abraham I <kishon(a)ti.com> Date: Fri, 24 May 2024 16:27:13 +0530 Subject: [PATCH] PCI: keystone: Set mode as Root Complex for "ti,keystone-pcie" compatible MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit commit 23284ad677a9 ("PCI: keystone: Add support for PCIe EP in AM654x Platforms") introduced configuring "enum dw_pcie_device_mode" as part of device data ("struct ks_pcie_of_data"). However it failed to set the mode for "ti,keystone-pcie" compatible. Since the mode defaults to "DW_PCIE_UNKNOWN_TYPE", the following error message is displayed for the v3.65a controller: "INVALID device type 0" Despite the driver probing successfully, the controller may not be functional in the Root Complex mode of operation. So, set the mode as Root Complex for "ti,keystone-pcie" compatible to fix this. Fixes: 23284ad677a9 ("PCI: keystone: Add support for PCIe EP in AM654x Platforms") Link: https://lore.kernel.org/r/20240524105714.191642-2-s-vadapalli@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com> Signed-off-by: Siddharth Vadapalli <s-vadapalli(a)ti.com> [kwilczynski: commit log, added tag for stable releases] Signed-off-by: Krzysztof Wilczyński <kwilczynski(a)kernel.org> Cc: stable(a)vger.kernel.org diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c index 2219b1a866fa..b99bc4071fe9 100644 --- a/drivers/pci/controller/dwc/pci-keystone.c +++ b/drivers/pci/controller/dwc/pci-keystone.c @@ -1093,6 +1093,7 @@ static int ks_pcie_am654_set_mode(struct device *dev, static const struct ks_pcie_of_data ks_pcie_rc_of_data = { .host_ops = &ks_pcie_host_ops, + .mode = DW_PCIE_RC_TYPE, .version = DW_PCIE_VER_365A, };

2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror