* [PATCH 6.9 001/157] drm/amdkfd: handle duplicate BOs in reserve_bo_and_cond_vms
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 002/157] drm/i915/hwmon: Get rid of devm Greg Kroah-Hartman
` (165 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Lang Yu, Felix Kuehling,
Alex Deucher
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lang Yu <Lang.Yu@amd.com>
commit 2a705f3e49d20b59cd9e5cc3061b2d92ebe1e5f0 upstream.
Observed on gfx8 ASIC where KFD_IOC_ALLOC_MEM_FLAGS_AQL_QUEUE_MEM is used.
Two attachments use the same VM, root PD would be locked twice.
[ 57.910418] Call Trace:
[ 57.793726] ? reserve_bo_and_cond_vms+0x111/0x1c0 [amdgpu]
[ 57.793820] amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu+0x6c/0x1c0 [amdgpu]
[ 57.793923] ? idr_get_next_ul+0xbe/0x100
[ 57.793933] kfd_process_device_free_bos+0x7e/0xf0 [amdgpu]
[ 57.794041] kfd_process_wq_release+0x2ae/0x3c0 [amdgpu]
[ 57.794141] ? process_scheduled_works+0x29c/0x580
[ 57.794147] process_scheduled_works+0x303/0x580
[ 57.794157] ? __pfx_worker_thread+0x10/0x10
[ 57.794160] worker_thread+0x1a2/0x370
[ 57.794165] ? __pfx_worker_thread+0x10/0x10
[ 57.794167] kthread+0x11b/0x150
[ 57.794172] ? __pfx_kthread+0x10/0x10
[ 57.794177] ret_from_fork+0x3d/0x60
[ 57.794181] ? __pfx_kthread+0x10/0x10
[ 57.794184] ret_from_fork_asm+0x1b/0x30
Signed-off-by: Lang Yu <Lang.Yu@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1188,7 +1188,8 @@ static int reserve_bo_and_cond_vms(struc
int ret;
ctx->sync = &mem->sync;
- drm_exec_init(&ctx->exec, DRM_EXEC_INTERRUPTIBLE_WAIT, 0);
+ drm_exec_init(&ctx->exec, DRM_EXEC_INTERRUPTIBLE_WAIT |
+ DRM_EXEC_IGNORE_DUPLICATES, 0);
drm_exec_until_all_locked(&ctx->exec) {
ctx->n_vms = 0;
list_for_each_entry(entry, &mem->attachments, list) {
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 002/157] drm/i915/hwmon: Get rid of devm
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 001/157] drm/amdkfd: handle duplicate BOs in reserve_bo_and_cond_vms Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 003/157] afs: Dont cross .backup mountpoint from backup volume Greg Kroah-Hartman
` (164 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Rodrigo Vivi, Ashutosh Dixit,
Andi Shyti
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ashutosh Dixit <ashutosh.dixit@intel.com>
commit 5bc9de065b8bb9b8dd8799ecb4592d0403b54281 upstream.
When both hwmon and hwmon drvdata (on which hwmon depends) are device
managed resources, the expectation, on device unbind, is that hwmon will be
released before drvdata. However, in i915 there are two separate code
paths, which both release either drvdata or hwmon and either can be
released before the other. These code paths (for device unbind) are as
follows (see also the bug referenced below):
Call Trace:
release_nodes+0x11/0x70
devres_release_group+0xb2/0x110
component_unbind_all+0x8d/0xa0
component_del+0xa5/0x140
intel_pxp_tee_component_fini+0x29/0x40 [i915]
intel_pxp_fini+0x33/0x80 [i915]
i915_driver_remove+0x4c/0x120 [i915]
i915_pci_remove+0x19/0x30 [i915]
pci_device_remove+0x32/0xa0
device_release_driver_internal+0x19c/0x200
unbind_store+0x9c/0xb0
and
Call Trace:
release_nodes+0x11/0x70
devres_release_all+0x8a/0xc0
device_unbind_cleanup+0x9/0x70
device_release_driver_internal+0x1c1/0x200
unbind_store+0x9c/0xb0
This means that in i915, if use devm, we cannot gurantee that hwmon will
always be released before drvdata. Which means that we have a uaf if hwmon
sysfs is accessed when drvdata has been released but hwmon hasn't.
The only way out of this seems to be do get rid of devm_ and release/free
everything explicitly during device unbind.
v2: Change commit message and other minor code changes
v3: Cleanup from i915_hwmon_register on error (Armin Wolf)
v4: Eliminate potential static analyzer warning (Rodrigo)
Eliminate fetch_and_zero (Jani)
v5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10366
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240417145646.793223-1-ashutosh.dixit@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/i915_hwmon.c | 46 ++++++++++++++++++++++++++------------
1 file changed, 32 insertions(+), 14 deletions(-)
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -793,7 +793,7 @@ void i915_hwmon_register(struct drm_i915
if (!IS_DGFX(i915))
return;
- hwmon = devm_kzalloc(dev, sizeof(*hwmon), GFP_KERNEL);
+ hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
if (!hwmon)
return;
@@ -819,14 +819,12 @@ void i915_hwmon_register(struct drm_i915
hwm_get_preregistration_info(i915);
/* hwmon_dev points to device hwmon<i> */
- hwmon_dev = devm_hwmon_device_register_with_info(dev, ddat->name,
- ddat,
- &hwm_chip_info,
- hwm_groups);
- if (IS_ERR(hwmon_dev)) {
- i915->hwmon = NULL;
- return;
- }
+ hwmon_dev = hwmon_device_register_with_info(dev, ddat->name,
+ ddat,
+ &hwm_chip_info,
+ hwm_groups);
+ if (IS_ERR(hwmon_dev))
+ goto err;
ddat->hwmon_dev = hwmon_dev;
@@ -839,16 +837,36 @@ void i915_hwmon_register(struct drm_i915
if (!hwm_gt_is_visible(ddat_gt, hwmon_energy, hwmon_energy_input, 0))
continue;
- hwmon_dev = devm_hwmon_device_register_with_info(dev, ddat_gt->name,
- ddat_gt,
- &hwm_gt_chip_info,
- NULL);
+ hwmon_dev = hwmon_device_register_with_info(dev, ddat_gt->name,
+ ddat_gt,
+ &hwm_gt_chip_info,
+ NULL);
if (!IS_ERR(hwmon_dev))
ddat_gt->hwmon_dev = hwmon_dev;
}
+ return;
+err:
+ i915_hwmon_unregister(i915);
}
void i915_hwmon_unregister(struct drm_i915_private *i915)
{
- fetch_and_zero(&i915->hwmon);
+ struct i915_hwmon *hwmon = i915->hwmon;
+ struct intel_gt *gt;
+ int i;
+
+ if (!hwmon)
+ return;
+
+ for_each_gt(gt, i915, i)
+ if (hwmon->ddat_gt[i].hwmon_dev)
+ hwmon_device_unregister(hwmon->ddat_gt[i].hwmon_dev);
+
+ if (hwmon->ddat.hwmon_dev)
+ hwmon_device_unregister(hwmon->ddat.hwmon_dev);
+
+ mutex_destroy(&hwmon->hwmon_lock);
+
+ kfree(i915->hwmon);
+ i915->hwmon = NULL;
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 003/157] afs: Dont cross .backup mountpoint from backup volume
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 001/157] drm/amdkfd: handle duplicate BOs in reserve_bo_and_cond_vms Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 002/157] drm/i915/hwmon: Get rid of devm Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 004/157] erofs: avoid allocating DEFLATE streams before mounting Greg Kroah-Hartman
` (163 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Jan Henrik Sylvester, Markus Suvanto,
Marc Dionne, David Howells, Jeffrey Altman, linux-afs,
Christian Brauner
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Dionne <marc.dionne@auristor.com>
commit 29be9100aca2915fab54b5693309bc42956542e5 upstream.
Don't cross a mountpoint that explicitly specifies a backup volume
(target is <vol>.backup) when starting from a backup volume.
It it not uncommon to mount a volume's backup directly in the volume
itself. This can cause tools that are not paying attention to get
into a loop mounting the volume onto itself as they attempt to
traverse the tree, leading to a variety of problems.
This doesn't prevent the general case of loops in a sequence of
mountpoints, but addresses a common special case in the same way
as other afs clients.
Reported-by: Jan Henrik Sylvester <jan.henrik.sylvester@uni-hamburg.de>
Link: http://lists.infradead.org/pipermail/linux-afs/2024-May/008454.html
Reported-by: Markus Suvanto <markus.suvanto@gmail.com>
Link: http://lists.infradead.org/pipermail/linux-afs/2024-February/008074.html
Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://lore.kernel.org/r/768760.1716567475@warthog.procyon.org.uk
Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
cc: linux-afs@lists.infradead.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/afs/mntpt.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/fs/afs/mntpt.c
+++ b/fs/afs/mntpt.c
@@ -140,6 +140,11 @@ static int afs_mntpt_set_params(struct f
put_page(page);
if (ret < 0)
return ret;
+
+ /* Don't cross a backup volume mountpoint from a backup volume */
+ if (src_as->volume && src_as->volume->type == AFSVL_BACKVOL &&
+ ctx->type == AFSVL_BACKVOL)
+ return -ENODEV;
}
return 0;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 004/157] erofs: avoid allocating DEFLATE streams before mounting
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 003/157] afs: Dont cross .backup mountpoint from backup volume Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 005/157] x86/topology/amd: Evaluate SMT in CPUID leaf 0x8000001e only on family 0x17 and greater Greg Kroah-Hartman
` (162 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Sandeep Dhavale, Gao Xiang
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gao Xiang <hsiangkao@linux.alibaba.com>
commit 80eb4f62056d6ae709bdd0636ab96ce660f494b2 upstream.
Currently, each DEFLATE stream takes one 32 KiB permanent internal
window buffer even if there is no running instance which uses DEFLATE
algorithm.
It's unexpected and wasteful on embedded devices with limited resources
and servers with hundreds of CPU cores if DEFLATE is enabled but unused.
Fixes: ffa09b3bd024 ("erofs: DEFLATE compression support")
Cc: <stable@vger.kernel.org> # 6.6+
Reviewed-by: Sandeep Dhavale <dhavale@google.com>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240520090106.2898681-1-hsiangkao@linux.alibaba.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/erofs/decompressor_deflate.c | 57 +++++++++++++++++++++-------------------
1 file changed, 30 insertions(+), 27 deletions(-)
--- a/fs/erofs/decompressor_deflate.c
+++ b/fs/erofs/decompressor_deflate.c
@@ -46,39 +46,15 @@ int __init z_erofs_deflate_init(void)
/* by default, use # of possible CPUs instead */
if (!z_erofs_deflate_nstrms)
z_erofs_deflate_nstrms = num_possible_cpus();
-
- for (; z_erofs_deflate_avail_strms < z_erofs_deflate_nstrms;
- ++z_erofs_deflate_avail_strms) {
- struct z_erofs_deflate *strm;
-
- strm = kzalloc(sizeof(*strm), GFP_KERNEL);
- if (!strm)
- goto out_failed;
-
- /* XXX: in-kernel zlib cannot shrink windowbits currently */
- strm->z.workspace = vmalloc(zlib_inflate_workspacesize());
- if (!strm->z.workspace) {
- kfree(strm);
- goto out_failed;
- }
-
- spin_lock(&z_erofs_deflate_lock);
- strm->next = z_erofs_deflate_head;
- z_erofs_deflate_head = strm;
- spin_unlock(&z_erofs_deflate_lock);
- }
return 0;
-
-out_failed:
- erofs_err(NULL, "failed to allocate zlib workspace");
- z_erofs_deflate_exit();
- return -ENOMEM;
}
int z_erofs_load_deflate_config(struct super_block *sb,
struct erofs_super_block *dsb, void *data, int size)
{
struct z_erofs_deflate_cfgs *dfl = data;
+ static DEFINE_MUTEX(deflate_resize_mutex);
+ static bool inited;
if (!dfl || size < sizeof(struct z_erofs_deflate_cfgs)) {
erofs_err(sb, "invalid deflate cfgs, size=%u", size);
@@ -89,9 +65,36 @@ int z_erofs_load_deflate_config(struct s
erofs_err(sb, "unsupported windowbits %u", dfl->windowbits);
return -EOPNOTSUPP;
}
-
+ mutex_lock(&deflate_resize_mutex);
+ if (!inited) {
+ for (; z_erofs_deflate_avail_strms < z_erofs_deflate_nstrms;
+ ++z_erofs_deflate_avail_strms) {
+ struct z_erofs_deflate *strm;
+
+ strm = kzalloc(sizeof(*strm), GFP_KERNEL);
+ if (!strm)
+ goto failed;
+ /* XXX: in-kernel zlib cannot customize windowbits */
+ strm->z.workspace = vmalloc(zlib_inflate_workspacesize());
+ if (!strm->z.workspace) {
+ kfree(strm);
+ goto failed;
+ }
+
+ spin_lock(&z_erofs_deflate_lock);
+ strm->next = z_erofs_deflate_head;
+ z_erofs_deflate_head = strm;
+ spin_unlock(&z_erofs_deflate_lock);
+ }
+ inited = true;
+ }
+ mutex_unlock(&deflate_resize_mutex);
erofs_info(sb, "EXPERIMENTAL DEFLATE feature in use. Use at your own risk!");
return 0;
+failed:
+ mutex_unlock(&deflate_resize_mutex);
+ z_erofs_deflate_exit();
+ return -ENOMEM;
}
int z_erofs_deflate_decompress(struct z_erofs_decompress_req *rq,
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 005/157] x86/topology/amd: Evaluate SMT in CPUID leaf 0x8000001e only on family 0x17 and greater
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 004/157] erofs: avoid allocating DEFLATE streams before mounting Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 006/157] vxlan: Fix regression when dropping packets due to invalid src addresses Greg Kroah-Hartman
` (161 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Tim Teichmann, Christian Heusel,
Thomas Gleixner, Borislav Petkov (AMD)
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <tglx@linutronix.de>
commit 34bf6bae3286a58762711cfbce2cf74ecd42e1b5 upstream.
The new AMD/HYGON topology parser evaluates the SMT information in CPUID leaf
0x8000001e unconditionally while the original code restricted it to CPUs with
family 0x17 and greater.
This breaks family 0x15 CPUs which advertise that leaf and have a non-zero
value in the SMT section. The machine boots, but the scheduler complains loudly
about the mismatch of the core IDs:
WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6482 sched_cpu_starting+0x183/0x250
WARNING: CPU: 0 PID: 1 at kernel/sched/topology.c:2408 build_sched_domains+0x76b/0x12b0
Add the condition back to cure it.
[ bp: Make it actually build because grandpa is not concerned with
trivial stuff. :-P ]
Fixes: f7fb3b2dd92c ("x86/cpu: Provide an AMD/HYGON specific topology parser")
Closes: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/56
Reported-by: Tim Teichmann <teichmanntim@outlook.de>
Reported-by: Christian Heusel <christian@heusel.eu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: Tim Teichmann <teichmanntim@outlook.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/7skhx6mwe4hxiul64v6azhlxnokheorksqsdbp7qw6g2jduf6c@7b5pvomauugk
Signed-off-by: Christian Heusel <christian@heusel.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/cpu/topology_amd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/x86/kernel/cpu/topology_amd.c
+++ b/arch/x86/kernel/cpu/topology_amd.c
@@ -84,9 +84,9 @@ static bool parse_8000_001e(struct topo_
/*
* If leaf 0xb is available, then the domain shifts are set
- * already and nothing to do here.
+ * already and nothing to do here. Only valid for family >= 0x17.
*/
- if (!has_0xb) {
+ if (!has_0xb && tscan->c->x86 >= 0x17) {
/*
* Leaf 0x80000008 set the CORE domain shift already.
* Update the SMT domain, but do not propagate it.
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 006/157] vxlan: Fix regression when dropping packets due to invalid src addresses
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 005/157] x86/topology/amd: Evaluate SMT in CPUID leaf 0x8000001e only on family 0x17 and greater Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 007/157] f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode() Greg Kroah-Hartman
` (160 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Daniel Borkmann, David Bauer,
Ido Schimmel, Nikolay Aleksandrov, Martin KaFai Lau,
David S. Miller
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Borkmann <daniel@iogearbox.net>
commit 1cd4bc987abb2823836cbb8f887026011ccddc8a upstream.
Commit f58f45c1e5b9 ("vxlan: drop packets from invalid src-address")
has recently been added to vxlan mainly in the context of source
address snooping/learning so that when it is enabled, an entry in the
FDB is not being created for an invalid address for the corresponding
tunnel endpoint.
Before commit f58f45c1e5b9 vxlan was similarly behaving as geneve in
that it passed through whichever macs were set in the L2 header. It
turns out that this change in behavior breaks setups, for example,
Cilium with netkit in L3 mode for Pods as well as tunnel mode has been
passing before the change in f58f45c1e5b9 for both vxlan and geneve.
After mentioned change it is only passing for geneve as in case of
vxlan packets are dropped due to vxlan_set_mac() returning false as
source and destination macs are zero which for E/W traffic via tunnel
is totally fine.
Fix it by only opting into the is_valid_ether_addr() check in
vxlan_set_mac() when in fact source address snooping/learning is
actually enabled in vxlan. This is done by moving the check into
vxlan_snoop(). With this change, the Cilium connectivity test suite
passes again for both tunnel flavors.
Fixes: f58f45c1e5b9 ("vxlan: drop packets from invalid src-address")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: David Bauer <mail@david-bauer.net>
Cc: Ido Schimmel <idosch@nvidia.com>
Cc: Nikolay Aleksandrov <razor@blackwall.org>
Cc: Martin KaFai Lau <martin.lau@kernel.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: David Bauer <mail@david-bauer.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/vxlan/vxlan_core.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/net/vxlan/vxlan_core.c
+++ b/drivers/net/vxlan/vxlan_core.c
@@ -1446,6 +1446,10 @@ static bool vxlan_snoop(struct net_devic
struct vxlan_fdb *f;
u32 ifindex = 0;
+ /* Ignore packets from invalid src-address */
+ if (!is_valid_ether_addr(src_mac))
+ return true;
+
#if IS_ENABLED(CONFIG_IPV6)
if (src_ip->sa.sa_family == AF_INET6 &&
(ipv6_addr_type(&src_ip->sin6.sin6_addr) & IPV6_ADDR_LINKLOCAL))
@@ -1615,10 +1619,6 @@ static bool vxlan_set_mac(struct vxlan_d
if (ether_addr_equal(eth_hdr(skb)->h_source, vxlan->dev->dev_addr))
return false;
- /* Ignore packets from invalid src-address */
- if (!is_valid_ether_addr(eth_hdr(skb)->h_source))
- return false;
-
/* Get address from the outer IP header */
if (vxlan_get_sk_family(vs) == AF_INET) {
saddr.sin.sin_addr.s_addr = ip_hdr(skb)->saddr;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 007/157] f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 006/157] vxlan: Fix regression when dropping packets due to invalid src addresses Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 008/157] media: lgdt3306a: Add a check against null-pointer-def Greg Kroah-Hartman
` (159 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Chao Yu, Jaegeuk Kim,
syzbot+3694e283cf5c40df6d14
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chao Yu <chao@kernel.org>
commit 20faaf30e55522bba2b56d9c46689233205d7717 upstream.
syzbot reports a kernel bug as below:
F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4
==================================================================
BUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]
BUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline]
BUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600
Read of size 1 at addr ffff88807a58c76c by task syz-executor280/5076
CPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488
kasan_report+0x143/0x180 mm/kasan/report.c:601
f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]
current_nat_addr fs/f2fs/node.h:213 [inline]
f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600
f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline]
f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925
ioctl_fiemap fs/ioctl.c:220 [inline]
do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838
__do_sys_ioctl fs/ioctl.c:902 [inline]
__se_sys_ioctl+0x81/0x170 fs/ioctl.c:890
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The root cause is we missed to do sanity check on i_xattr_nid during
f2fs_iget(), so that in fiemap() path, current_nat_addr() will access
nat_bitmap w/ offset from invalid i_xattr_nid, result in triggering
kasan bug report, fix it.
Reported-and-tested-by: syzbot+3694e283cf5c40df6d14@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-f2fs-devel/00000000000094036c0616e72a1d@google.com
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/f2fs/inode.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -361,6 +361,12 @@ static bool sanity_check_inode(struct in
return false;
}
+ if (fi->i_xattr_nid && f2fs_check_nid_range(sbi, fi->i_xattr_nid)) {
+ f2fs_warn(sbi, "%s: inode (ino=%lx) has corrupted i_xattr_nid: %u, run fsck to fix.",
+ __func__, inode->i_ino, fi->i_xattr_nid);
+ return false;
+ }
+
return true;
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 008/157] media: lgdt3306a: Add a check against null-pointer-def
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 007/157] f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode() Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 009/157] drm/amdgpu: add error handle to avoid out-of-bounds Greg Kroah-Hartman
` (158 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Zheyu Ma, Mauro Carvalho Chehab
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zheyu Ma <zheyuma97@gmail.com>
commit c1115ddbda9c930fba0fdd062e7a8873ebaf898d upstream.
The driver should check whether the client provides the platform_data.
The following log reveals it:
[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[ 29.612820] Call Trace:
[ 29.613030] <TASK>
[ 29.613201] dump_stack_lvl+0x56/0x6f
[ 29.613496] ? kmemdup+0x30/0x40
[ 29.613754] print_report.cold+0x494/0x6b7
[ 29.614082] ? kmemdup+0x30/0x40
[ 29.614340] kasan_report+0x8a/0x190
[ 29.614628] ? kmemdup+0x30/0x40
[ 29.614888] kasan_check_range+0x14d/0x1d0
[ 29.615213] memcpy+0x20/0x60
[ 29.615454] kmemdup+0x30/0x40
[ 29.615700] lgdt3306a_probe+0x52/0x310
[ 29.616339] i2c_device_probe+0x951/0xa90
Link: https://lore.kernel.org/linux-media/20220405095018.3993578-1-zheyuma97@gmail.com
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/dvb-frontends/lgdt3306a.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/media/dvb-frontends/lgdt3306a.c
+++ b/drivers/media/dvb-frontends/lgdt3306a.c
@@ -2176,6 +2176,11 @@ static int lgdt3306a_probe(struct i2c_cl
struct dvb_frontend *fe;
int ret;
+ if (!client->dev.platform_data) {
+ dev_err(&client->dev, "platform data is mandatory\n");
+ return -EINVAL;
+ }
+
config = kmemdup(client->dev.platform_data,
sizeof(struct lgdt3306a_config), GFP_KERNEL);
if (config == NULL) {
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 009/157] drm/amdgpu: add error handle to avoid out-of-bounds
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 008/157] media: lgdt3306a: Add a check against null-pointer-def Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 010/157] drm/xe/bb: assert width in xe_bb_create_job() Greg Kroah-Hartman
` (157 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Bob Zhou, Christian König,
Le Ma, Alex Deucher
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bob Zhou <bob.zhou@amd.com>
commit 8b2faf1a4f3b6c748c0da36cda865a226534d520 upstream.
if the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should
be stop to avoid out-of-bounds read, so directly return -EINVAL.
Signed-off-by: Bob Zhou <bob.zhou@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Le Ma <le.ma@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -2021,6 +2021,9 @@ static int sdma_v4_0_process_trap_irq(st
DRM_DEBUG("IH: SDMA trap\n");
instance = sdma_v4_0_irq_id_to_seq(entry->client_id);
+ if (instance < 0)
+ return instance;
+
switch (entry->ring_id) {
case 0:
amdgpu_fence_process(&adev->sdma.instance[instance].ring);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 010/157] drm/xe/bb: assert width in xe_bb_create_job()
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 009/157] drm/amdgpu: add error handle to avoid out-of-bounds Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 011/157] bcache: fix variable length array abuse in btree_iter Greg Kroah-Hartman
` (156 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Matthew Auld, Nirmoy Das
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Auld <matthew.auld@intel.com>
commit 1008368e1c7e36bdec01b3cce1e76606dc3ad46f upstream.
The queue width will determine the number of batch buffer emitted into
the ring. In the case of xe_bb_create_job() we pass exactly one batch
address, therefore add an assert for the width to make sure we don't go
out of bounds. While here also convert to the helper to determine if the
queue is migration based.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240320112730.219854-3-matthew.auld@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/xe/xe_bb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/xe/xe_bb.c
+++ b/drivers/gpu/drm/xe/xe_bb.c
@@ -96,7 +96,8 @@ struct xe_sched_job *xe_bb_create_job(st
{
u64 addr = xe_sa_bo_gpu_addr(bb->bo);
- xe_gt_assert(q->gt, !(q->vm && q->vm->flags & XE_VM_FLAG_MIGRATION));
+ xe_gt_assert(q->gt, !xe_sched_job_is_migration(q));
+ xe_gt_assert(q->gt, q->width == 1);
return __xe_bb_create_job(q, bb, &addr);
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 011/157] bcache: fix variable length array abuse in btree_iter
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 010/157] drm/xe/bb: assert width in xe_bb_create_job() Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 012/157] crypto: starfive - Do not free stack buffer Greg Kroah-Hartman
` (155 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Matthew Mirvish, Coly Li, Jens Axboe
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Mirvish <matthew@mm12.xyz>
commit 3a861560ccb35f2a4f0a4b8207fa7c2a35fc7f31 upstream.
btree_iter is used in two ways: either allocated on the stack with a
fixed size MAX_BSETS, or from a mempool with a dynamic size based on the
specific cache set. Previously, the struct had a fixed-length array of
size MAX_BSETS which was indexed out-of-bounds for the dynamically-sized
iterators, which causes UBSAN to complain.
This patch uses the same approach as in bcachefs's sort_iter and splits
the iterator into a btree_iter with a flexible array member and a
btree_iter_stack which embeds a btree_iter as well as a fixed-length
data array.
Cc: stable@vger.kernel.org
Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039368
Signed-off-by: Matthew Mirvish <matthew@mm12.xyz>
Signed-off-by: Coly Li <colyli@suse.de>
Link: https://lore.kernel.org/r/20240509011117.2697-3-colyli@suse.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/bcache/bset.c | 44 +++++++++++++++++++++---------------------
drivers/md/bcache/bset.h | 30 ++++++++++++++++++----------
drivers/md/bcache/btree.c | 40 ++++++++++++++++++++------------------
drivers/md/bcache/super.c | 5 ++--
drivers/md/bcache/sysfs.c | 2 -
drivers/md/bcache/writeback.c | 10 ++++-----
6 files changed, 71 insertions(+), 60 deletions(-)
--- a/drivers/md/bcache/bset.c
+++ b/drivers/md/bcache/bset.c
@@ -54,7 +54,7 @@ void bch_dump_bucket(struct btree_keys *
int __bch_count_data(struct btree_keys *b)
{
unsigned int ret = 0;
- struct btree_iter iter;
+ struct btree_iter_stack iter;
struct bkey *k;
if (b->ops->is_extents)
@@ -67,7 +67,7 @@ void __bch_check_keys(struct btree_keys
{
va_list args;
struct bkey *k, *p = NULL;
- struct btree_iter iter;
+ struct btree_iter_stack iter;
const char *err;
for_each_key(b, k, &iter) {
@@ -879,7 +879,7 @@ unsigned int bch_btree_insert_key(struct
unsigned int status = BTREE_INSERT_STATUS_NO_INSERT;
struct bset *i = bset_tree_last(b)->data;
struct bkey *m, *prev = NULL;
- struct btree_iter iter;
+ struct btree_iter_stack iter;
struct bkey preceding_key_on_stack = ZERO_KEY;
struct bkey *preceding_key_p = &preceding_key_on_stack;
@@ -895,9 +895,9 @@ unsigned int bch_btree_insert_key(struct
else
preceding_key(k, &preceding_key_p);
- m = bch_btree_iter_init(b, &iter, preceding_key_p);
+ m = bch_btree_iter_stack_init(b, &iter, preceding_key_p);
- if (b->ops->insert_fixup(b, k, &iter, replace_key))
+ if (b->ops->insert_fixup(b, k, &iter.iter, replace_key))
return status;
status = BTREE_INSERT_STATUS_INSERT;
@@ -1100,33 +1100,33 @@ void bch_btree_iter_push(struct btree_it
btree_iter_cmp));
}
-static struct bkey *__bch_btree_iter_init(struct btree_keys *b,
- struct btree_iter *iter,
- struct bkey *search,
- struct bset_tree *start)
+static struct bkey *__bch_btree_iter_stack_init(struct btree_keys *b,
+ struct btree_iter_stack *iter,
+ struct bkey *search,
+ struct bset_tree *start)
{
struct bkey *ret = NULL;
- iter->size = ARRAY_SIZE(iter->data);
- iter->used = 0;
+ iter->iter.size = ARRAY_SIZE(iter->stack_data);
+ iter->iter.used = 0;
#ifdef CONFIG_BCACHE_DEBUG
- iter->b = b;
+ iter->iter.b = b;
#endif
for (; start <= bset_tree_last(b); start++) {
ret = bch_bset_search(b, start, search);
- bch_btree_iter_push(iter, ret, bset_bkey_last(start->data));
+ bch_btree_iter_push(&iter->iter, ret, bset_bkey_last(start->data));
}
return ret;
}
-struct bkey *bch_btree_iter_init(struct btree_keys *b,
- struct btree_iter *iter,
+struct bkey *bch_btree_iter_stack_init(struct btree_keys *b,
+ struct btree_iter_stack *iter,
struct bkey *search)
{
- return __bch_btree_iter_init(b, iter, search, b->set);
+ return __bch_btree_iter_stack_init(b, iter, search, b->set);
}
static inline struct bkey *__bch_btree_iter_next(struct btree_iter *iter,
@@ -1293,10 +1293,10 @@ void bch_btree_sort_partial(struct btree
struct bset_sort_state *state)
{
size_t order = b->page_order, keys = 0;
- struct btree_iter iter;
+ struct btree_iter_stack iter;
int oldsize = bch_count_data(b);
- __bch_btree_iter_init(b, &iter, NULL, &b->set[start]);
+ __bch_btree_iter_stack_init(b, &iter, NULL, &b->set[start]);
if (start) {
unsigned int i;
@@ -1307,7 +1307,7 @@ void bch_btree_sort_partial(struct btree
order = get_order(__set_bytes(b->set->data, keys));
}
- __btree_sort(b, &iter, start, order, false, state);
+ __btree_sort(b, &iter.iter, start, order, false, state);
EBUG_ON(oldsize >= 0 && bch_count_data(b) != oldsize);
}
@@ -1323,11 +1323,11 @@ void bch_btree_sort_into(struct btree_ke
struct bset_sort_state *state)
{
uint64_t start_time = local_clock();
- struct btree_iter iter;
+ struct btree_iter_stack iter;
- bch_btree_iter_init(b, &iter, NULL);
+ bch_btree_iter_stack_init(b, &iter, NULL);
- btree_mergesort(b, new->set->data, &iter, false, true);
+ btree_mergesort(b, new->set->data, &iter.iter, false, true);
bch_time_stats_update(&state->time, start_time);
--- a/drivers/md/bcache/bset.h
+++ b/drivers/md/bcache/bset.h
@@ -321,7 +321,14 @@ struct btree_iter {
#endif
struct btree_iter_set {
struct bkey *k, *end;
- } data[MAX_BSETS];
+ } data[];
+};
+
+/* Fixed-size btree_iter that can be allocated on the stack */
+
+struct btree_iter_stack {
+ struct btree_iter iter;
+ struct btree_iter_set stack_data[MAX_BSETS];
};
typedef bool (*ptr_filter_fn)(struct btree_keys *b, const struct bkey *k);
@@ -333,9 +340,9 @@ struct bkey *bch_btree_iter_next_filter(
void bch_btree_iter_push(struct btree_iter *iter, struct bkey *k,
struct bkey *end);
-struct bkey *bch_btree_iter_init(struct btree_keys *b,
- struct btree_iter *iter,
- struct bkey *search);
+struct bkey *bch_btree_iter_stack_init(struct btree_keys *b,
+ struct btree_iter_stack *iter,
+ struct bkey *search);
struct bkey *__bch_bset_search(struct btree_keys *b, struct bset_tree *t,
const struct bkey *search);
@@ -350,13 +357,14 @@ static inline struct bkey *bch_bset_sear
return search ? __bch_bset_search(b, t, search) : t->data->start;
}
-#define for_each_key_filter(b, k, iter, filter) \
- for (bch_btree_iter_init((b), (iter), NULL); \
- ((k) = bch_btree_iter_next_filter((iter), (b), filter));)
-
-#define for_each_key(b, k, iter) \
- for (bch_btree_iter_init((b), (iter), NULL); \
- ((k) = bch_btree_iter_next(iter));)
+#define for_each_key_filter(b, k, stack_iter, filter) \
+ for (bch_btree_iter_stack_init((b), (stack_iter), NULL); \
+ ((k) = bch_btree_iter_next_filter(&((stack_iter)->iter), (b), \
+ filter));)
+
+#define for_each_key(b, k, stack_iter) \
+ for (bch_btree_iter_stack_init((b), (stack_iter), NULL); \
+ ((k) = bch_btree_iter_next(&((stack_iter)->iter)));)
/* Sorting */
--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@ -1309,7 +1309,7 @@ static bool btree_gc_mark_node(struct bt
uint8_t stale = 0;
unsigned int keys = 0, good_keys = 0;
struct bkey *k;
- struct btree_iter iter;
+ struct btree_iter_stack iter;
struct bset_tree *t;
gc->nodes++;
@@ -1570,7 +1570,7 @@ static int btree_gc_rewrite_node(struct
static unsigned int btree_gc_count_keys(struct btree *b)
{
struct bkey *k;
- struct btree_iter iter;
+ struct btree_iter_stack iter;
unsigned int ret = 0;
for_each_key_filter(&b->keys, k, &iter, bch_ptr_bad)
@@ -1611,17 +1611,18 @@ static int btree_gc_recurse(struct btree
int ret = 0;
bool should_rewrite;
struct bkey *k;
- struct btree_iter iter;
+ struct btree_iter_stack iter;
struct gc_merge_info r[GC_MERGE_NODES];
struct gc_merge_info *i, *last = r + ARRAY_SIZE(r) - 1;
- bch_btree_iter_init(&b->keys, &iter, &b->c->gc_done);
+ bch_btree_iter_stack_init(&b->keys, &iter, &b->c->gc_done);
for (i = r; i < r + ARRAY_SIZE(r); i++)
i->b = ERR_PTR(-EINTR);
while (1) {
- k = bch_btree_iter_next_filter(&iter, &b->keys, bch_ptr_bad);
+ k = bch_btree_iter_next_filter(&iter.iter, &b->keys,
+ bch_ptr_bad);
if (k) {
r->b = bch_btree_node_get(b->c, op, k, b->level - 1,
true, b);
@@ -1911,7 +1912,7 @@ static int bch_btree_check_recurse(struc
{
int ret = 0;
struct bkey *k, *p = NULL;
- struct btree_iter iter;
+ struct btree_iter_stack iter;
for_each_key_filter(&b->keys, k, &iter, bch_ptr_invalid)
bch_initial_mark_key(b->c, b->level, k);
@@ -1919,10 +1920,10 @@ static int bch_btree_check_recurse(struc
bch_initial_mark_key(b->c, b->level + 1, &b->key);
if (b->level) {
- bch_btree_iter_init(&b->keys, &iter, NULL);
+ bch_btree_iter_stack_init(&b->keys, &iter, NULL);
do {
- k = bch_btree_iter_next_filter(&iter, &b->keys,
+ k = bch_btree_iter_next_filter(&iter.iter, &b->keys,
bch_ptr_bad);
if (k) {
btree_node_prefetch(b, k);
@@ -1950,7 +1951,7 @@ static int bch_btree_check_thread(void *
struct btree_check_info *info = arg;
struct btree_check_state *check_state = info->state;
struct cache_set *c = check_state->c;
- struct btree_iter iter;
+ struct btree_iter_stack iter;
struct bkey *k, *p;
int cur_idx, prev_idx, skip_nr;
@@ -1959,8 +1960,8 @@ static int bch_btree_check_thread(void *
ret = 0;
/* root node keys are checked before thread created */
- bch_btree_iter_init(&c->root->keys, &iter, NULL);
- k = bch_btree_iter_next_filter(&iter, &c->root->keys, bch_ptr_bad);
+ bch_btree_iter_stack_init(&c->root->keys, &iter, NULL);
+ k = bch_btree_iter_next_filter(&iter.iter, &c->root->keys, bch_ptr_bad);
BUG_ON(!k);
p = k;
@@ -1978,7 +1979,7 @@ static int bch_btree_check_thread(void *
skip_nr = cur_idx - prev_idx;
while (skip_nr) {
- k = bch_btree_iter_next_filter(&iter,
+ k = bch_btree_iter_next_filter(&iter.iter,
&c->root->keys,
bch_ptr_bad);
if (k)
@@ -2051,7 +2052,7 @@ int bch_btree_check(struct cache_set *c)
int ret = 0;
int i;
struct bkey *k = NULL;
- struct btree_iter iter;
+ struct btree_iter_stack iter;
struct btree_check_state check_state;
/* check and mark root node keys */
@@ -2547,11 +2548,11 @@ static int bch_btree_map_nodes_recurse(s
if (b->level) {
struct bkey *k;
- struct btree_iter iter;
+ struct btree_iter_stack iter;
- bch_btree_iter_init(&b->keys, &iter, from);
+ bch_btree_iter_stack_init(&b->keys, &iter, from);
- while ((k = bch_btree_iter_next_filter(&iter, &b->keys,
+ while ((k = bch_btree_iter_next_filter(&iter.iter, &b->keys,
bch_ptr_bad))) {
ret = bcache_btree(map_nodes_recurse, k, b,
op, from, fn, flags);
@@ -2580,11 +2581,12 @@ int bch_btree_map_keys_recurse(struct bt
{
int ret = MAP_CONTINUE;
struct bkey *k;
- struct btree_iter iter;
+ struct btree_iter_stack iter;
- bch_btree_iter_init(&b->keys, &iter, from);
+ bch_btree_iter_stack_init(&b->keys, &iter, from);
- while ((k = bch_btree_iter_next_filter(&iter, &b->keys, bch_ptr_bad))) {
+ while ((k = bch_btree_iter_next_filter(&iter.iter, &b->keys,
+ bch_ptr_bad))) {
ret = !b->level
? fn(op, b, k)
: bcache_btree(map_keys_recurse, k,
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -1914,8 +1914,9 @@ struct cache_set *bch_cache_set_alloc(st
INIT_LIST_HEAD(&c->btree_cache_freed);
INIT_LIST_HEAD(&c->data_buckets);
- iter_size = ((meta_bucket_pages(sb) * PAGE_SECTORS) / sb->block_size + 1) *
- sizeof(struct btree_iter_set);
+ iter_size = sizeof(struct btree_iter) +
+ ((meta_bucket_pages(sb) * PAGE_SECTORS) / sb->block_size) *
+ sizeof(struct btree_iter_set);
c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL);
if (!c->devices)
--- a/drivers/md/bcache/sysfs.c
+++ b/drivers/md/bcache/sysfs.c
@@ -660,7 +660,7 @@ static unsigned int bch_root_usage(struc
unsigned int bytes = 0;
struct bkey *k;
struct btree *b;
- struct btree_iter iter;
+ struct btree_iter_stack iter;
goto lock_root;
--- a/drivers/md/bcache/writeback.c
+++ b/drivers/md/bcache/writeback.c
@@ -908,15 +908,15 @@ static int bch_dirty_init_thread(void *a
struct dirty_init_thrd_info *info = arg;
struct bch_dirty_init_state *state = info->state;
struct cache_set *c = state->c;
- struct btree_iter iter;
+ struct btree_iter_stack iter;
struct bkey *k, *p;
int cur_idx, prev_idx, skip_nr;
k = p = NULL;
prev_idx = 0;
- bch_btree_iter_init(&c->root->keys, &iter, NULL);
- k = bch_btree_iter_next_filter(&iter, &c->root->keys, bch_ptr_bad);
+ bch_btree_iter_stack_init(&c->root->keys, &iter, NULL);
+ k = bch_btree_iter_next_filter(&iter.iter, &c->root->keys, bch_ptr_bad);
BUG_ON(!k);
p = k;
@@ -930,7 +930,7 @@ static int bch_dirty_init_thread(void *a
skip_nr = cur_idx - prev_idx;
while (skip_nr) {
- k = bch_btree_iter_next_filter(&iter,
+ k = bch_btree_iter_next_filter(&iter.iter,
&c->root->keys,
bch_ptr_bad);
if (k)
@@ -979,7 +979,7 @@ void bch_sectors_dirty_init(struct bcach
int i;
struct btree *b = NULL;
struct bkey *k = NULL;
- struct btree_iter iter;
+ struct btree_iter_stack iter;
struct sectors_dirty_init op;
struct cache_set *c = d->c;
struct bch_dirty_init_state state;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 012/157] crypto: starfive - Do not free stack buffer
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (10 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 011/157] bcache: fix variable length array abuse in btree_iter Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 013/157] btrfs: qgroup: fix initialization of auto inherit array Greg Kroah-Hartman
` (154 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Jia Jie Ho, Herbert Xu
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jia Jie Ho <jiajie.ho@starfivetech.com>
commit d7f01649f4eaf1878472d3d3f480ae1e50d98f6c upstream.
RSA text data uses variable length buffer allocated in software stack.
Calling kfree on it causes undefined behaviour in subsequent operations.
Cc: <stable@vger.kernel.org> #6.7+
Signed-off-by: Jia Jie Ho <jiajie.ho@starfivetech.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/crypto/starfive/jh7110-rsa.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/crypto/starfive/jh7110-rsa.c
+++ b/drivers/crypto/starfive/jh7110-rsa.c
@@ -273,7 +273,6 @@ static int starfive_rsa_enc_core(struct
err_rsa_crypt:
writel(STARFIVE_RSA_RESET, cryp->base + STARFIVE_PKA_CACR_OFFSET);
- kfree(rctx->rsa_data);
return ret;
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 013/157] btrfs: qgroup: fix initialization of auto inherit array
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (11 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 012/157] crypto: starfive - Do not free stack buffer Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 014/157] wifi: rtw89: correct aSIFSTime for 6GHz band Greg Kroah-Hartman
` (153 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Qu Wenruo, Dan Carpenter,
David Sterba
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <dan.carpenter@linaro.org>
commit 0e39c9e524479b85c1b83134df0cfc6e3cb5353a upstream.
The "i++" was accidentally left out so it just sets qgids[0] over and
over.
This can lead to unexpected problems, as the groups[1:] would be all 0,
leading to later find_qgroup_rb() unable to find a qgroup and cause
snapshot creation failure.
Fixes: 5343cd9364ea ("btrfs: qgroup: simple quota auto hierarchy for nested subvolumes")
CC: stable@vger.kernel.org # 6.7+
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/qgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -3129,7 +3129,7 @@ static int qgroup_auto_inherit(struct bt
qgids = res->qgroups;
list_for_each_entry(qg_list, &inode_qg->groups, next_group)
- qgids[i] = qg_list->group->qgroupid;
+ qgids[i++] = qg_list->group->qgroupid;
*inherit = res;
return 0;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 014/157] wifi: rtw89: correct aSIFSTime for 6GHz band
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (12 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 013/157] btrfs: qgroup: fix initialization of auto inherit array Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 015/157] ata: pata_legacy: make legacy_exit() work again Greg Kroah-Hartman
` (152 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Ping-Ke Shih
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ping-Ke Shih <pkshih@realtek.com>
commit f506e3ee547669cd96842e03c8a772aa7df721fa upstream.
aSIFSTime is 10us for 2GHz band and 16us for 5GHz and 6GHz bands.
Originally, it doesn't consider 6GHz band and use wrong value, so correct
it accordingly.
Cc: stable@vger.kernel.org
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240430020515.8399-1-pkshih@realtek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/realtek/rtw89/mac80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/realtek/rtw89/mac80211.c
+++ b/drivers/net/wireless/realtek/rtw89/mac80211.c
@@ -318,7 +318,7 @@ static u8 rtw89_aifsn_to_aifs(struct rtw
u8 sifs;
slot_time = vif->bss_conf.use_short_slot ? 9 : 20;
- sifs = chan->band_type == RTW89_BAND_5G ? 16 : 10;
+ sifs = chan->band_type == RTW89_BAND_2G ? 10 : 16;
return aifsn * slot_time + sifs;
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 015/157] ata: pata_legacy: make legacy_exit() work again
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (13 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 014/157] wifi: rtw89: correct aSIFSTime for 6GHz band Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 016/157] fsverity: use register_sysctl_init() to avoid kmemleak warning Greg Kroah-Hartman
` (151 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Sergey Shtylyov, Niklas Cassel,
Damien Le Moal
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergey Shtylyov <s.shtylyov@omp.ru>
commit d4a89339f17c87c4990070e9116462d16e75894f upstream.
Commit defc9cd826e4 ("pata_legacy: resychronize with upstream changes and
resubmit") missed to update legacy_exit(), so that it now fails to do any
cleanup -- the loop body there can never be entered. Fix that and finally
remove now useless nr_legacy_host variable...
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
Fixes: defc9cd826e4 ("pata_legacy: resychronize with upstream changes and resubmit")
Cc: stable@vger.kernel.org
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/ata/pata_legacy.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -173,8 +173,6 @@ static int legacy_port[NR_HOST] = { 0x1f
static struct legacy_probe probe_list[NR_HOST];
static struct legacy_data legacy_data[NR_HOST];
static struct ata_host *legacy_host[NR_HOST];
-static int nr_legacy_host;
-
/**
* legacy_probe_add - Add interface to probe list
@@ -1276,9 +1274,11 @@ static __exit void legacy_exit(void)
{
int i;
- for (i = 0; i < nr_legacy_host; i++) {
+ for (i = 0; i < NR_HOST; i++) {
struct legacy_data *ld = &legacy_data[i];
- ata_host_detach(legacy_host[i]);
+
+ if (legacy_host[i])
+ ata_host_detach(legacy_host[i]);
platform_device_unregister(ld->platform_dev);
}
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 016/157] fsverity: use register_sysctl_init() to avoid kmemleak warning
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (14 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 015/157] ata: pata_legacy: make legacy_exit() work again Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 017/157] proc: Move fdinfo PTRACE_MODE_READ check into the inode .permission operation Greg Kroah-Hartman
` (150 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Yi Zhang, Joel Granados,
Eric Biggers
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <ebiggers@google.com>
commit ee5814dddefbaa181cb247a75676dd5103775db1 upstream.
Since the fsverity sysctl registration runs as a builtin initcall, there
is no corresponding sysctl deregistration and the resulting struct
ctl_table_header is not used. This can cause a kmemleak warning just
after the system boots up. (A pointer to the ctl_table_header is stored
in the fsverity_sysctl_header static variable, which kmemleak should
detect; however, the compiler can optimize out that variable.) Avoid
the kmemleak warning by using register_sysctl_init() which is intended
for use by builtin initcalls and uses kmemleak_not_leak().
Reported-by: Yi Zhang <yi.zhang@redhat.com>
Closes: https://lore.kernel.org/r/CAHj4cs8DTSvR698UE040rs_pX1k-WVe7aR6N2OoXXuhXJPDC-w@mail.gmail.com
Cc: stable@vger.kernel.org
Reviewed-by: Joel Granados <j.granados@samsung.com>
Link: https://lore.kernel.org/r/20240501025331.594183-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/verity/init.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
--- a/fs/verity/init.c
+++ b/fs/verity/init.c
@@ -10,8 +10,6 @@
#include <linux/ratelimit.h>
#ifdef CONFIG_SYSCTL
-static struct ctl_table_header *fsverity_sysctl_header;
-
static struct ctl_table fsverity_sysctl_table[] = {
#ifdef CONFIG_FS_VERITY_BUILTIN_SIGNATURES
{
@@ -28,10 +26,7 @@ static struct ctl_table fsverity_sysctl_
static void __init fsverity_init_sysctl(void)
{
- fsverity_sysctl_header = register_sysctl("fs/verity",
- fsverity_sysctl_table);
- if (!fsverity_sysctl_header)
- panic("fsverity sysctl registration failed");
+ register_sysctl_init("fs/verity", fsverity_sysctl_table);
}
#else /* CONFIG_SYSCTL */
static inline void fsverity_init_sysctl(void)
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 017/157] proc: Move fdinfo PTRACE_MODE_READ check into the inode .permission operation
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (15 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 016/157] fsverity: use register_sysctl_init() to avoid kmemleak warning Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 018/157] platform/chrome: cros_ec: Handle events during suspend after resume completion Greg Kroah-Hartman
` (149 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Kevin Parsons (Microsoft),
Christian Brauner, Christian König, Jann Horn, Kalesh Singh,
Hardik Garg, Allen Pais, Tyler Hicks (Microsoft)
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tyler Hicks (Microsoft) <code@tyhicks.com>
commit 0a960ba49869ebe8ff859d000351504dd6b93b68 upstream.
The following commits loosened the permissions of /proc/<PID>/fdinfo/
directory, as well as the files within it, from 0500 to 0555 while also
introducing a PTRACE_MODE_READ check between the current task and
<PID>'s task:
- commit 7bc3fa0172a4 ("procfs: allow reading fdinfo with PTRACE_MODE_READ")
- commit 1927e498aee1 ("procfs: prevent unprivileged processes accessing fdinfo dir")
Before those changes, inode based system calls like inotify_add_watch(2)
would fail when the current task didn't have sufficient read permissions:
[...]
lstat("/proc/1/task/1/fdinfo", {st_mode=S_IFDIR|0500, st_size=0, ...}) = 0
inotify_add_watch(64, "/proc/1/task/1/fdinfo",
IN_MODIFY|IN_ATTRIB|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|
IN_ONLYDIR|IN_DONT_FOLLOW|IN_EXCL_UNLINK) = -1 EACCES (Permission denied)
[...]
This matches the documented behavior in the inotify_add_watch(2) man
page:
ERRORS
EACCES Read access to the given file is not permitted.
After those changes, inotify_add_watch(2) started succeeding despite the
current task not having PTRACE_MODE_READ privileges on the target task:
[...]
lstat("/proc/1/task/1/fdinfo", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
inotify_add_watch(64, "/proc/1/task/1/fdinfo",
IN_MODIFY|IN_ATTRIB|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|
IN_ONLYDIR|IN_DONT_FOLLOW|IN_EXCL_UNLINK) = 1757
openat(AT_FDCWD, "/proc/1/task/1/fdinfo",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 EACCES (Permission denied)
[...]
This change in behavior broke .NET prior to v7. See the github link
below for the v7 commit that inadvertently/quietly (?) fixed .NET after
the kernel changes mentioned above.
Return to the old behavior by moving the PTRACE_MODE_READ check out of
the file .open operation and into the inode .permission operation:
[...]
lstat("/proc/1/task/1/fdinfo", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
inotify_add_watch(64, "/proc/1/task/1/fdinfo",
IN_MODIFY|IN_ATTRIB|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|
IN_ONLYDIR|IN_DONT_FOLLOW|IN_EXCL_UNLINK) = -1 EACCES (Permission denied)
[...]
Reported-by: Kevin Parsons (Microsoft) <parsonskev@gmail.com>
Link: https://github.com/dotnet/runtime/commit/89e5469ac591b82d38510fe7de98346cce74ad4f
Link: https://stackoverflow.com/questions/75379065/start-self-contained-net6-build-exe-as-service-on-raspbian-system-unauthorizeda
Fixes: 7bc3fa0172a4 ("procfs: allow reading fdinfo with PTRACE_MODE_READ")
Cc: stable@vger.kernel.org
Cc: Christian Brauner <brauner@kernel.org>
Cc: Christian König <christian.koenig@amd.com>
Cc: Jann Horn <jannh@google.com>
Cc: Kalesh Singh <kaleshsingh@google.com>
Cc: Hardik Garg <hargar@linux.microsoft.com>
Cc: Allen Pais <apais@linux.microsoft.com>
Signed-off-by: Tyler Hicks (Microsoft) <code@tyhicks.com>
Link: https://lore.kernel.org/r/20240501005646.745089-1-code@tyhicks.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/proc/fd.c | 42 ++++++++++++++++++++----------------------
1 file changed, 20 insertions(+), 22 deletions(-)
--- a/fs/proc/fd.c
+++ b/fs/proc/fd.c
@@ -74,7 +74,18 @@ out:
return 0;
}
-static int proc_fdinfo_access_allowed(struct inode *inode)
+static int seq_fdinfo_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, seq_show, inode);
+}
+
+/**
+ * Shared /proc/pid/fdinfo and /proc/pid/fdinfo/fd permission helper to ensure
+ * that the current task has PTRACE_MODE_READ in addition to the normal
+ * POSIX-like checks.
+ */
+static int proc_fdinfo_permission(struct mnt_idmap *idmap, struct inode *inode,
+ int mask)
{
bool allowed = false;
struct task_struct *task = get_proc_task(inode);
@@ -88,18 +99,13 @@ static int proc_fdinfo_access_allowed(st
if (!allowed)
return -EACCES;
- return 0;
+ return generic_permission(idmap, inode, mask);
}
-static int seq_fdinfo_open(struct inode *inode, struct file *file)
-{
- int ret = proc_fdinfo_access_allowed(inode);
-
- if (ret)
- return ret;
-
- return single_open(file, seq_show, inode);
-}
+static const struct inode_operations proc_fdinfo_file_inode_operations = {
+ .permission = proc_fdinfo_permission,
+ .setattr = proc_setattr,
+};
static const struct file_operations proc_fdinfo_file_operations = {
.open = seq_fdinfo_open,
@@ -388,6 +394,8 @@ static struct dentry *proc_fdinfo_instan
ei = PROC_I(inode);
ei->fd = data->fd;
+ inode->i_op = &proc_fdinfo_file_inode_operations;
+
inode->i_fop = &proc_fdinfo_file_operations;
tid_fd_update_inode(task, inode, 0);
@@ -407,23 +415,13 @@ static int proc_readfdinfo(struct file *
proc_fdinfo_instantiate);
}
-static int proc_open_fdinfo(struct inode *inode, struct file *file)
-{
- int ret = proc_fdinfo_access_allowed(inode);
-
- if (ret)
- return ret;
-
- return 0;
-}
-
const struct inode_operations proc_fdinfo_inode_operations = {
.lookup = proc_lookupfdinfo,
+ .permission = proc_fdinfo_permission,
.setattr = proc_setattr,
};
const struct file_operations proc_fdinfo_operations = {
- .open = proc_open_fdinfo,
.read = generic_read_dir,
.iterate_shared = proc_readfdinfo,
.llseek = generic_file_llseek,
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 018/157] platform/chrome: cros_ec: Handle events during suspend after resume completion
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (16 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 017/157] proc: Move fdinfo PTRACE_MODE_READ check into the inode .permission operation Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 019/157] thermal/drivers/qcom/lmh: Check for SCM availability at probe Greg Kroah-Hartman
` (148 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Lalith Rajendran, chrome-platform,
Karthikeyan Ramasubramanian, Tzung-Bi Shih
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Karthikeyan Ramasubramanian <kramasub@chromium.org>
commit 2fbe479c0024e1c6b992184a799055e19932aa48 upstream.
Commit 47ea0ddb1f56 ("platform/chrome: cros_ec_lpc: Separate host
command and irq disable") re-ordered the resume sequence. Before that
change, cros_ec resume sequence is:
1) Enable IRQ
2) Send resume event
3) Handle events during suspend
After commit 47ea0ddb1f56 ("platform/chrome: cros_ec_lpc: Separate host
command and irq disable"), cros_ec resume sequence is:
1) Enable IRQ
2) Handle events during suspend
3) Send resume event.
This re-ordering leads to delayed handling of any events queued between
items 2) and 3) with the updated sequence. Also in certain platforms, EC
skips triggering interrupt for certain events eg. mkbp events until the
resume event is received. Such events are stuck in the host event queue
indefinitely. This change puts back the original order to avoid any
delay in handling the pending events.
Fixes: 47ea0ddb1f56 ("platform/chrome: cros_ec_lpc: Separate host command and irq disable")
Cc: <stable@vger.kernel.org>
Cc: Lalith Rajendran <lalithkraj@chromium.org>
Cc: <chrome-platform@lists.linux.dev>
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@chromium.org>
Link: https://lore.kernel.org/r/20240429121343.v2.1.If2e0cef959f1f6df9f4d1ab53a97c54aa54208af@changeid
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/platform/chrome/cros_ec.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/drivers/platform/chrome/cros_ec.c
+++ b/drivers/platform/chrome/cros_ec.c
@@ -432,6 +432,12 @@ static void cros_ec_send_resume_event(st
void cros_ec_resume_complete(struct cros_ec_device *ec_dev)
{
cros_ec_send_resume_event(ec_dev);
+
+ /*
+ * Let the mfd devices know about events that occur during
+ * suspend. This way the clients know what to do with them.
+ */
+ cros_ec_report_events_during_suspend(ec_dev);
}
EXPORT_SYMBOL(cros_ec_resume_complete);
@@ -442,12 +448,6 @@ static void cros_ec_enable_irq(struct cr
if (ec_dev->wake_enabled)
disable_irq_wake(ec_dev->irq);
-
- /*
- * Let the mfd devices know about events that occur during
- * suspend. This way the clients know what to do with them.
- */
- cros_ec_report_events_during_suspend(ec_dev);
}
/**
@@ -475,8 +475,8 @@ EXPORT_SYMBOL(cros_ec_resume_early);
*/
int cros_ec_resume(struct cros_ec_device *ec_dev)
{
- cros_ec_enable_irq(ec_dev);
- cros_ec_send_resume_event(ec_dev);
+ cros_ec_resume_early(ec_dev);
+ cros_ec_resume_complete(ec_dev);
return 0;
}
EXPORT_SYMBOL(cros_ec_resume);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 019/157] thermal/drivers/qcom/lmh: Check for SCM availability at probe
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (17 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 018/157] platform/chrome: cros_ec: Handle events during suspend after resume completion Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 020/157] soc: qcom: rpmh-rsc: Enhance check for VRM in-flight request Greg Kroah-Hartman
` (147 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Dmitry Baryshkov, Bjorn Andersson,
Konrad Dybcio, Daniel Lezcano
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konrad Dybcio <konrad.dybcio@linaro.org>
commit d9d3490c48df572edefc0b64655259eefdcbb9be upstream.
Up until now, the necessary scm availability check has not been
performed, leading to possible null pointer dereferences (which did
happen for me on RB1).
Fix that.
Fixes: 53bca371cdf7 ("thermal/drivers/qcom: Add support for LMh driver")
Cc: <stable@vger.kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20240308-topic-rb1_lmh-v2-2-bac3914b0fe3@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/thermal/qcom/lmh.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/thermal/qcom/lmh.c
+++ b/drivers/thermal/qcom/lmh.c
@@ -95,6 +95,9 @@ static int lmh_probe(struct platform_dev
unsigned int enable_alg;
u32 node_id;
+ if (!qcom_scm_is_available())
+ return -EPROBE_DEFER;
+
lmh_data = devm_kzalloc(dev, sizeof(*lmh_data), GFP_KERNEL);
if (!lmh_data)
return -ENOMEM;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 020/157] soc: qcom: rpmh-rsc: Enhance check for VRM in-flight request
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (18 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 019/157] thermal/drivers/qcom/lmh: Check for SCM availability at probe Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 021/157] ACPI: resource: Do IRQ override on TongFang GXxHRXx and GMxHGxx Greg Kroah-Hartman
` (146 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Konrad Dybcio, Maulik Shah,
Bjorn Andersson, Elliot Berman
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maulik Shah <quic_mkshah@quicinc.com>
commit f592cc5794747b81e53b53dd6e80219ee25f0611 upstream.
Each RPMh VRM accelerator resource has 3 or 4 contiguous 4-byte aligned
addresses associated with it. These control voltage, enable state, mode,
and in legacy targets, voltage headroom. The current in-flight request
checking logic looks for exact address matches. Requests for different
addresses of the same RPMh resource as thus not detected as in-flight.
Add new cmd-db API cmd_db_match_resource_addr() to enhance the in-flight
request check for VRM requests by ignoring the address offset.
This ensures that only one request is allowed to be in-flight for a given
VRM resource. This is needed to avoid scenarios where request commands are
carried out by RPMh hardware out-of-order leading to LDO regulator
over-current protection triggering.
Fixes: 658628e7ef78 ("drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs")
Cc: stable@vger.kernel.org
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Tested-by: Elliot Berman <quic_eberman@quicinc.com> # sm8650-qrd
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
Link: https://lore.kernel.org/r/20240215-rpmh-rsc-fixes-v4-1-9cbddfcba05b@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/soc/qcom/cmd-db.c | 32 +++++++++++++++++++++++++++++++-
drivers/soc/qcom/rpmh-rsc.c | 3 ++-
include/soc/qcom/cmd-db.h | 10 +++++++++-
3 files changed, 42 insertions(+), 3 deletions(-)
--- a/drivers/soc/qcom/cmd-db.c
+++ b/drivers/soc/qcom/cmd-db.c
@@ -1,6 +1,10 @@
/* SPDX-License-Identifier: GPL-2.0 */
-/* Copyright (c) 2016-2018, 2020, The Linux Foundation. All rights reserved. */
+/*
+ * Copyright (c) 2016-2018, 2020, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+#include <linux/bitfield.h>
#include <linux/debugfs.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -17,6 +21,8 @@
#define MAX_SLV_ID 8
#define SLAVE_ID_MASK 0x7
#define SLAVE_ID_SHIFT 16
+#define SLAVE_ID(addr) FIELD_GET(GENMASK(19, 16), addr)
+#define VRM_ADDR(addr) FIELD_GET(GENMASK(19, 4), addr)
/**
* struct entry_header: header for each entry in cmddb
@@ -221,6 +227,30 @@ const void *cmd_db_read_aux_data(const c
EXPORT_SYMBOL_GPL(cmd_db_read_aux_data);
/**
+ * cmd_db_match_resource_addr() - Compare if both Resource addresses are same
+ *
+ * @addr1: Resource address to compare
+ * @addr2: Resource address to compare
+ *
+ * Return: true if two addresses refer to the same resource, false otherwise
+ */
+bool cmd_db_match_resource_addr(u32 addr1, u32 addr2)
+{
+ /*
+ * Each RPMh VRM accelerator resource has 3 or 4 contiguous 4-byte
+ * aligned addresses associated with it. Ignore the offset to check
+ * for VRM requests.
+ */
+ if (addr1 == addr2)
+ return true;
+ else if (SLAVE_ID(addr1) == CMD_DB_HW_VRM && VRM_ADDR(addr1) == VRM_ADDR(addr2))
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL_GPL(cmd_db_match_resource_addr);
+
+/**
* cmd_db_read_slave_id - Get the slave ID for a given resource address
*
* @id: Resource id to query the DB for version
--- a/drivers/soc/qcom/rpmh-rsc.c
+++ b/drivers/soc/qcom/rpmh-rsc.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2023-2024, Qualcomm Innovation Center, Inc. All rights reserved.
*/
#define pr_fmt(fmt) "%s " fmt, KBUILD_MODNAME
@@ -557,7 +558,7 @@ static int check_for_req_inflight(struct
for_each_set_bit(j, &curr_enabled, MAX_CMDS_PER_TCS) {
addr = read_tcs_cmd(drv, drv->regs[RSC_DRV_CMD_ADDR], i, j);
for (k = 0; k < msg->num_cmds; k++) {
- if (addr == msg->cmds[k].addr)
+ if (cmd_db_match_resource_addr(msg->cmds[k].addr, addr))
return -EBUSY;
}
}
--- a/include/soc/qcom/cmd-db.h
+++ b/include/soc/qcom/cmd-db.h
@@ -1,5 +1,8 @@
/* SPDX-License-Identifier: GPL-2.0 */
-/* Copyright (c) 2016-2018, The Linux Foundation. All rights reserved. */
+/*
+ * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
#ifndef __QCOM_COMMAND_DB_H__
#define __QCOM_COMMAND_DB_H__
@@ -21,6 +24,8 @@ u32 cmd_db_read_addr(const char *resourc
const void *cmd_db_read_aux_data(const char *resource_id, size_t *len);
+bool cmd_db_match_resource_addr(u32 addr1, u32 addr2);
+
enum cmd_db_hw_type cmd_db_read_slave_id(const char *resource_id);
int cmd_db_ready(void);
@@ -31,6 +36,9 @@ static inline u32 cmd_db_read_addr(const
static inline const void *cmd_db_read_aux_data(const char *resource_id, size_t *len)
{ return ERR_PTR(-ENODEV); }
+static inline bool cmd_db_match_resource_addr(u32 addr1, u32 addr2)
+{ return false; }
+
static inline enum cmd_db_hw_type cmd_db_read_slave_id(const char *resource_id)
{ return -ENODEV; }
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 021/157] ACPI: resource: Do IRQ override on TongFang GXxHRXx and GMxHGxx
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (19 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 020/157] soc: qcom: rpmh-rsc: Enhance check for VRM in-flight request Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 022/157] arm64: tegra: Correct Tegra132 I2C alias Greg Kroah-Hartman
` (145 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Christoffer Sandberg, Werner Sembach,
Rafael J. Wysocki
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoffer Sandberg <cs@tuxedo.de>
commit c81bf14f9db68311c2e75428eea070d97d603975 upstream.
Listed devices need the override for the keyboard to work.
Signed-off-by: Christoffer Sandberg <cs@tuxedo.de>
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/acpi/resource.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -630,6 +630,18 @@ static const struct dmi_system_id irq1_e
DMI_MATCH(DMI_BOARD_NAME, "X565"),
},
},
+ {
+ /* TongFang GXxHRXx/TUXEDO InfinityBook Pro Gen9 AMD */
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "GXxHRXx"),
+ },
+ },
+ {
+ /* TongFang GMxHGxx/TUXEDO Stellaris Slim Gen1 AMD */
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "GMxHGxx"),
+ },
+ },
{ }
};
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 022/157] arm64: tegra: Correct Tegra132 I2C alias
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (20 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 021/157] ACPI: resource: Do IRQ override on TongFang GXxHRXx and GMxHGxx Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 023/157] arm64: dts: qcom: qcs404: fix bluetooth device address Greg Kroah-Hartman
` (144 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Krzysztof Kozlowski, Jon Hunter,
Thierry Reding
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <krzk@kernel.org>
commit 2633c58e1354d7de2c8e7be8bdb6f68a0a01bad7 upstream.
There is no such device as "as3722@40", because its name is "pmic". Use
phandles for aliases to fix relying on full node path. This corrects
aliases for RTC devices and also fixes dtc W=1 warning:
tegra132-norrin.dts:12.3-36: Warning (alias_paths): /aliases:rtc0: aliases property is not a valid node (/i2c@7000d000/as3722@40)
Fixes: 0f279ebdf3ce ("arm64: tegra: Add NVIDIA Tegra132 Norrin support")
Cc: stable@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/boot/dts/nvidia/tegra132-norrin.dts | 4 ++--
arch/arm64/boot/dts/nvidia/tegra132.dtsi | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--- a/arch/arm64/boot/dts/nvidia/tegra132-norrin.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra132-norrin.dts
@@ -9,8 +9,8 @@
compatible = "nvidia,norrin", "nvidia,tegra132", "nvidia,tegra124";
aliases {
- rtc0 = "/i2c@7000d000/as3722@40";
- rtc1 = "/rtc@7000e000";
+ rtc0 = &as3722;
+ rtc1 = &tegra_rtc;
serial0 = &uarta;
};
--- a/arch/arm64/boot/dts/nvidia/tegra132.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra132.dtsi
@@ -572,7 +572,7 @@
status = "disabled";
};
- rtc@7000e000 {
+ tegra_rtc: rtc@7000e000 {
compatible = "nvidia,tegra124-rtc", "nvidia,tegra20-rtc";
reg = <0x0 0x7000e000 0x0 0x100>;
interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 023/157] arm64: dts: qcom: qcs404: fix bluetooth device address
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (21 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 022/157] arm64: tegra: Correct Tegra132 I2C alias Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 024/157] md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING Greg Kroah-Hartman
` (143 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Johan Hovold, Bryan ODonoghue,
Bjorn Andersson
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan+linaro@kernel.org>
commit f5f390a77f18eaeb2c93211a1b7c5e66b5acd423 upstream.
The 'local-bd-address' property is used to pass a unique Bluetooth
device address from the boot firmware to the kernel and should otherwise
be left unset so that the OS can prevent the controller from being used
until a valid address has been provided through some other means (e.g.
using btmgmt).
Fixes: 60f77ae7d1c1 ("arm64: dts: qcom: qcs404-evb: Enable uart3 and add Bluetooth")
Cc: stable@vger.kernel.org # 5.10
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20240501075201.4732-1-johan+linaro@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
@@ -62,7 +62,7 @@
vddrf-supply = <&vreg_l1_1p3>;
vddch0-supply = <&vdd_ch0_3p3>;
- local-bd-address = [ 02 00 00 00 5a ad ];
+ local-bd-address = [ 00 00 00 00 00 00 ];
max-speed = <3200000>;
};
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 024/157] md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (22 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 023/157] arm64: dts: qcom: qcs404: fix bluetooth device address Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 025/157] wifi: rtw89: pci: correct TX resource checking for PCI DMA channel of firmware command Greg Kroah-Hartman
` (142 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Yu Kuai, Song Liu, Dan Moulding,
Junxiao Bi
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yu Kuai <yukuai3@huawei.com>
commit 151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa upstream.
Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with
small possibility, the root cause is exactly the same as commit
bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")
However, Dan reported another hang after that, and junxiao investigated
the problem and found out that this is caused by plugged bio can't issue
from raid5d().
Current implementation in raid5d() has a weird dependence:
1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
MD_SB_CHANGE_PENDING;
2) raid5d() handles IO in a deadloop, until all IO are issued;
3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;
This behaviour is introduce before v2.6, and for consequence, if other
context hold 'reconfig_mutex', and md_check_recovery() can't update
super_block, then raid5d() will waste one cpu 100% by the deadloop, until
'reconfig_mutex' is released.
Refer to the implementation from raid1 and raid10, fix this problem by
skipping issue IO if MD_SB_CHANGE_PENDING is still set after
md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex'
is released. Meanwhile, the hang problem will be fixed as well.
Fixes: 5e2cf333b7bd ("md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d")
Cc: stable@vger.kernel.org # v5.19+
Reported-and-tested-by: Dan Moulding <dan@danm.net>
Closes: https://lore.kernel.org/all/20240123005700.9302-1-dan@danm.net/
Investigated-by: Junxiao Bi <junxiao.bi@oracle.com>
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Link: https://lore.kernel.org/r/20240322081005.1112401-1-yukuai1@huaweicloud.com
Signed-off-by: Song Liu <song@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/raid5.c | 15 +++------------
1 file changed, 3 insertions(+), 12 deletions(-)
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -36,7 +36,6 @@
*/
#include <linux/blkdev.h>
-#include <linux/delay.h>
#include <linux/kthread.h>
#include <linux/raid/pq.h>
#include <linux/async_tx.h>
@@ -6734,6 +6733,9 @@ static void raid5d(struct md_thread *thr
int batch_size, released;
unsigned int offset;
+ if (test_bit(MD_SB_CHANGE_PENDING, &mddev->sb_flags))
+ break;
+
released = release_stripe_list(conf, conf->temp_inactive_list);
if (released)
clear_bit(R5_DID_ALLOC, &conf->cache_state);
@@ -6770,18 +6772,7 @@ static void raid5d(struct md_thread *thr
spin_unlock_irq(&conf->device_lock);
md_check_recovery(mddev);
spin_lock_irq(&conf->device_lock);
-
- /*
- * Waiting on MD_SB_CHANGE_PENDING below may deadlock
- * seeing md_check_recovery() is needed to clear
- * the flag when using mdmon.
- */
- continue;
}
-
- wait_event_lock_irq(mddev->sb_wait,
- !test_bit(MD_SB_CHANGE_PENDING, &mddev->sb_flags),
- conf->device_lock);
}
pr_debug("%d stripes handled\n", handled);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 025/157] wifi: rtw89: pci: correct TX resource checking for PCI DMA channel of firmware command
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (23 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 024/157] md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 026/157] wifi: rtl8xxxu: Fix the TX power of RTL8192CU, RTL8723AU Greg Kroah-Hartman
` (141 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Ping-Ke Shih
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ping-Ke Shih <pkshih@realtek.com>
commit c6330b129786e267b14129335a08fa7c331c308d upstream.
The DMA channel of firmware command doesn't use TX WD (WiFi descriptor), so
don't need to consider number of TX WD as factor of TX resource. Otherwise,
during pause state (a transient state to switch to/from low power mode)
firmware commands could be dropped and driver throws warnings suddenly:
rtw89_8852ce 0000:04:00.0: no tx fwcmd resource
rtw89_8852ce 0000:04:00.0: failed to send h2c
The case we met is that driver sends RSSI strength of firmware command at
RX path that could be running concurrently with switching low power mode.
The missing of this firmware command doesn't affect user experiences,
because the RSSI strength will be updated again after a while.
The DMA descriptors of normal packets has three layers like:
+-------+
| TX BD | (*n elements)
+-------+
|
| +-------+
+-> | TX WD | (*m elements)
+-------+
|
| +--------+
+-> | SKB |
+--------+
And, firmware command queue (TXCH 12) is a special queue that has only
two layers:
+-------+
| TX BD | (*n elements)
+-------+
|
| +------------------+
+-> | firmware command |
+------------------+
Fixes: 4a29213cd775 ("wifi: rtw89: pci: correct TX resource checking in low power mode")
Cc: stable@vger.kernel.org
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240410011316.9906-1-pkshih@realtek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/realtek/rtw89/pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/realtek/rtw89/pci.c
+++ b/drivers/net/wireless/realtek/rtw89/pci.c
@@ -1089,7 +1089,8 @@ u32 __rtw89_pci_check_and_reclaim_tx_res
spin_lock_bh(&rtwpci->trx_lock);
cnt = rtw89_pci_get_avail_txbd_num(tx_ring);
- cnt = min(cnt, wd_ring->curr_num);
+ if (txch != RTW89_TXCH_CH12)
+ cnt = min(cnt, wd_ring->curr_num);
spin_unlock_bh(&rtwpci->trx_lock);
return cnt;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 026/157] wifi: rtl8xxxu: Fix the TX power of RTL8192CU, RTL8723AU
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (24 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 025/157] wifi: rtw89: pci: correct TX resource checking for PCI DMA channel of firmware command Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 027/157] wifi: rtl8xxxu: enable MFP support with security flag of RX descriptor Greg Kroah-Hartman
` (140 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Bitterblue Smith, Ping-Ke Shih
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
commit 08b5d052d17a89bb8706b2888277d0b682dc1610 upstream.
Don't subtract 1 from the power index. This was added in commit
2fc0b8e5a17d ("rtl8xxxu: Add TX power base values for gen1 parts")
for unknown reasons. The vendor drivers don't do this.
Also correct the calculations of values written to
REG_OFDM0_X{C,D}_TX_IQ_IMBALANCE. According to the vendor driver,
these are used for TX power training.
With these changes rtl8xxxu sets the TX power of RTL8192CU the same
as the vendor driver.
None of this appears to have any effect on my RTL8192CU device.
Cc: stable@vger.kernel.org
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/6ae5945b-644e-45e4-a78f-4c7d9c987910@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 25 +++++++-----------
1 file changed, 10 insertions(+), 15 deletions(-)
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -1505,13 +1505,13 @@ rtl8xxxu_gen1_set_tx_power(struct rtl8xx
u8 cck[RTL8723A_MAX_RF_PATHS], ofdm[RTL8723A_MAX_RF_PATHS];
u8 ofdmbase[RTL8723A_MAX_RF_PATHS], mcsbase[RTL8723A_MAX_RF_PATHS];
u32 val32, ofdm_a, ofdm_b, mcs_a, mcs_b;
- u8 val8;
+ u8 val8, base;
int group, i;
group = rtl8xxxu_gen1_channel_to_group(channel);
- cck[0] = priv->cck_tx_power_index_A[group] - 1;
- cck[1] = priv->cck_tx_power_index_B[group] - 1;
+ cck[0] = priv->cck_tx_power_index_A[group];
+ cck[1] = priv->cck_tx_power_index_B[group];
if (priv->hi_pa) {
if (cck[0] > 0x20)
@@ -1522,10 +1522,6 @@ rtl8xxxu_gen1_set_tx_power(struct rtl8xx
ofdm[0] = priv->ht40_1s_tx_power_index_A[group];
ofdm[1] = priv->ht40_1s_tx_power_index_B[group];
- if (ofdm[0])
- ofdm[0] -= 1;
- if (ofdm[1])
- ofdm[1] -= 1;
ofdmbase[0] = ofdm[0] + priv->ofdm_tx_power_index_diff[group].a;
ofdmbase[1] = ofdm[1] + priv->ofdm_tx_power_index_diff[group].b;
@@ -1614,20 +1610,19 @@ rtl8xxxu_gen1_set_tx_power(struct rtl8xx
rtl8xxxu_write32(priv, REG_TX_AGC_A_MCS15_MCS12,
mcs_a + power_base->reg_0e1c);
+ val8 = u32_get_bits(mcs_a + power_base->reg_0e1c, 0xff000000);
for (i = 0; i < 3; i++) {
- if (i != 2)
- val8 = (mcsbase[0] > 8) ? (mcsbase[0] - 8) : 0;
- else
- val8 = (mcsbase[0] > 6) ? (mcsbase[0] - 6) : 0;
+ base = i != 2 ? 8 : 6;
+ val8 = max_t(int, val8 - base, 0);
rtl8xxxu_write8(priv, REG_OFDM0_XC_TX_IQ_IMBALANCE + i, val8);
}
+
rtl8xxxu_write32(priv, REG_TX_AGC_B_MCS15_MCS12,
mcs_b + power_base->reg_0868);
+ val8 = u32_get_bits(mcs_b + power_base->reg_0868, 0xff000000);
for (i = 0; i < 3; i++) {
- if (i != 2)
- val8 = (mcsbase[1] > 8) ? (mcsbase[1] - 8) : 0;
- else
- val8 = (mcsbase[1] > 6) ? (mcsbase[1] - 6) : 0;
+ base = i != 2 ? 8 : 6;
+ val8 = max_t(int, val8 - base, 0);
rtl8xxxu_write8(priv, REG_OFDM0_XD_TX_IQ_IMBALANCE + i, val8);
}
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 027/157] wifi: rtl8xxxu: enable MFP support with security flag of RX descriptor
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (25 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 026/157] wifi: rtl8xxxu: Fix the TX power of RTL8192CU, RTL8723AU Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 028/157] wifi: rtlwifi: rtl8192de: Fix 5 GHz TX power Greg Kroah-Hartman
` (139 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Martin Kaistra, Ping-Ke Shih
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Kaistra <martin.kaistra@linutronix.de>
commit cbfbb4ddbc8503478e0a138f9a31f61686cc5f11 upstream.
In order to connect to networks which require 802.11w, add the
MFP_CAPABLE flag and let mac80211 do the actual crypto in software.
When a robust management frame is received, rx_dec->swdec is not set,
even though the HW did not decrypt it. Extend the check and don't set
RX_FLAG_DECRYPTED for these frames in order to use SW decryption.
Use the security flag in the RX descriptor for this purpose, like it is
done in the rtw88 driver.
Cc: stable@vger.kernel.org
Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240418071813.1883174-3-martin.kaistra@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 9 +++++++++
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 7 +++++--
2 files changed, 14 insertions(+), 2 deletions(-)
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -122,6 +122,15 @@ enum rtl8xxxu_rx_type {
RX_TYPE_ERROR = -1
};
+enum rtl8xxxu_rx_desc_enc {
+ RX_DESC_ENC_NONE = 0,
+ RX_DESC_ENC_WEP40 = 1,
+ RX_DESC_ENC_TKIP_WO_MIC = 2,
+ RX_DESC_ENC_TKIP_MIC = 3,
+ RX_DESC_ENC_AES = 4,
+ RX_DESC_ENC_WEP104 = 5,
+};
+
struct rtl8xxxu_rxdesc16 {
#ifdef __LITTLE_ENDIAN
u32 pktlen:14;
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -6468,7 +6468,8 @@ int rtl8xxxu_parse_rxdesc16(struct rtl8x
rx_status->mactime = rx_desc->tsfl;
rx_status->flag |= RX_FLAG_MACTIME_START;
- if (!rx_desc->swdec)
+ if (!rx_desc->swdec &&
+ rx_desc->security != RX_DESC_ENC_NONE)
rx_status->flag |= RX_FLAG_DECRYPTED;
if (rx_desc->crc32)
rx_status->flag |= RX_FLAG_FAILED_FCS_CRC;
@@ -6573,7 +6574,8 @@ int rtl8xxxu_parse_rxdesc24(struct rtl8x
rx_status->mactime = rx_desc->tsfl;
rx_status->flag |= RX_FLAG_MACTIME_START;
- if (!rx_desc->swdec)
+ if (!rx_desc->swdec &&
+ rx_desc->security != RX_DESC_ENC_NONE)
rx_status->flag |= RX_FLAG_DECRYPTED;
if (rx_desc->crc32)
rx_status->flag |= RX_FLAG_FAILED_FCS_CRC;
@@ -7993,6 +7995,7 @@ static int rtl8xxxu_probe(struct usb_int
ieee80211_hw_set(hw, HAS_RATE_CONTROL);
ieee80211_hw_set(hw, SUPPORT_FAST_XMIT);
ieee80211_hw_set(hw, AMPDU_AGGREGATION);
+ ieee80211_hw_set(hw, MFP_CAPABLE);
wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_CQM_RSSI_LIST);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 028/157] wifi: rtlwifi: rtl8192de: Fix 5 GHz TX power
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (26 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 027/157] wifi: rtl8xxxu: enable MFP support with security flag of RX descriptor Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 029/157] wifi: rtlwifi: rtl8192de: Fix low speed with WPA3-SAE Greg Kroah-Hartman
` (138 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Bitterblue Smith, Ping-Ke Shih
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
commit de4d4be4fa64ed7b4aa1c613061015bd8fa98b24 upstream.
Different channels have different TX power settings. rtl8192de is using
the TX power setting from the wrong channel in the 5 GHz band because
_rtl92c_phy_get_rightchnlplace expects an array which includes all the
channel numbers, but it's using an array which includes only the 5 GHz
channel numbers.
Use the array channel_all (defined in rtl8192de/phy.c) instead of
the incorrect channel5g (defined in core.c).
Tested only with rtl8192du, which will use the same TX power code.
Cc: stable@vger.kernel.org
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/c7653517-cf88-4f57-b79a-8edb0a8b32f0@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c
@@ -892,8 +892,8 @@ static u8 _rtl92c_phy_get_rightchnlplace
u8 place = chnl;
if (chnl > 14) {
- for (place = 14; place < ARRAY_SIZE(channel5g); place++) {
- if (channel5g[place] == chnl) {
+ for (place = 14; place < ARRAY_SIZE(channel_all); place++) {
+ if (channel_all[place] == chnl) {
place++;
break;
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 029/157] wifi: rtlwifi: rtl8192de: Fix low speed with WPA3-SAE
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (27 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 028/157] wifi: rtlwifi: rtl8192de: Fix 5 GHz TX power Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 030/157] wifi: rtlwifi: rtl8192de: Fix endianness issue in RX path Greg Kroah-Hartman
` (137 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Bitterblue Smith, Ping-Ke Shih
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
commit a7c0f48410f546772ac94a0f7b7291a15c4fc173 upstream.
Some (all?) management frames are incorrectly reported to mac80211 as
decrypted when actually the hardware did not decrypt them. This results
in speeds 3-5 times lower than expected, 20-30 Mbps instead of 100
Mbps.
Fix this by checking the encryption type field of the RX descriptor.
rtw88 does the same thing.
This fix was tested only with rtl8192du, which will use the same code.
Cc: stable@vger.kernel.org
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/4d600435-f0ea-46b0-bdb4-e60f173da8dd@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c | 5 ++---
drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.h | 14 ++++++++++++++
2 files changed, 16 insertions(+), 3 deletions(-)
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c
@@ -413,7 +413,8 @@ bool rtl92de_rx_query_desc(struct ieee80
stats->icv = (u16)get_rx_desc_icv(pdesc);
stats->crc = (u16)get_rx_desc_crc32(pdesc);
stats->hwerror = (stats->crc | stats->icv);
- stats->decrypted = !get_rx_desc_swdec(pdesc);
+ stats->decrypted = !get_rx_desc_swdec(pdesc) &&
+ get_rx_desc_enc_type(pdesc) != RX_DESC_ENC_NONE;
stats->rate = (u8)get_rx_desc_rxmcs(pdesc);
stats->shortpreamble = (u16)get_rx_desc_splcp(pdesc);
stats->isampdu = (bool)(get_rx_desc_paggr(pdesc) == 1);
@@ -426,8 +427,6 @@ bool rtl92de_rx_query_desc(struct ieee80
rx_status->band = hw->conf.chandef.chan->band;
if (get_rx_desc_crc32(pdesc))
rx_status->flag |= RX_FLAG_FAILED_FCS_CRC;
- if (!get_rx_desc_swdec(pdesc))
- rx_status->flag |= RX_FLAG_DECRYPTED;
if (get_rx_desc_bw(pdesc))
rx_status->bw = RATE_INFO_BW_40;
if (get_rx_desc_rxht(pdesc))
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.h
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.h
@@ -14,6 +14,15 @@
#define USB_HWDESC_HEADER_LEN 32
#define CRCLENGTH 4
+enum rtl92d_rx_desc_enc {
+ RX_DESC_ENC_NONE = 0,
+ RX_DESC_ENC_WEP40 = 1,
+ RX_DESC_ENC_TKIP_WO_MIC = 2,
+ RX_DESC_ENC_TKIP_MIC = 3,
+ RX_DESC_ENC_AES = 4,
+ RX_DESC_ENC_WEP104 = 5,
+};
+
/* macros to read/write various fields in RX or TX descriptors */
static inline void set_tx_desc_pkt_size(__le32 *__pdesc, u32 __val)
@@ -246,6 +255,11 @@ static inline u32 get_rx_desc_drv_info_s
return le32_get_bits(*__pdesc, GENMASK(19, 16));
}
+static inline u32 get_rx_desc_enc_type(__le32 *__pdesc)
+{
+ return le32_get_bits(*__pdesc, GENMASK(22, 20));
+}
+
static inline u32 get_rx_desc_shift(__le32 *__pdesc)
{
return le32_get_bits(*__pdesc, GENMASK(25, 24));
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 030/157] wifi: rtlwifi: rtl8192de: Fix endianness issue in RX path
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (28 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 029/157] wifi: rtlwifi: rtl8192de: Fix low speed with WPA3-SAE Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 031/157] arm64: dts: qcom: sc8280xp: add missing PCIe minimum OPP Greg Kroah-Hartman
` (136 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Bitterblue Smith, Ping-Ke Shih
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
commit 2f228d364da95ab58f63a3fedc00d5b2b7db16ab upstream.
Structs rx_desc_92d and rx_fwinfo_92d will not work for big endian
systems.
Delete rx_desc_92d because it's big and barely used, and instead use
the get_rx_desc_rxmcs and get_rx_desc_rxht functions, which work on big
endian systems too.
Fix rx_fwinfo_92d by duplicating four of its members in the correct
order.
Tested only with RTL8192DU, which will use the same code.
Tested only on a little endian system.
Cc: stable@vger.kernel.org
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/698463da-5ef1-40c7-b744-fa51ad847caf@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c | 16 ++--
drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.h | 65 ++-----------------
2 files changed, 15 insertions(+), 66 deletions(-)
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c
@@ -35,7 +35,7 @@ static long _rtl92de_translate_todbm(str
static void _rtl92de_query_rxphystatus(struct ieee80211_hw *hw,
struct rtl_stats *pstats,
- struct rx_desc_92d *pdesc,
+ __le32 *pdesc,
struct rx_fwinfo_92d *p_drvinfo,
bool packet_match_bssid,
bool packet_toself,
@@ -50,8 +50,10 @@ static void _rtl92de_query_rxphystatus(s
u8 i, max_spatial_stream;
u32 rssi, total_rssi = 0;
bool is_cck_rate;
+ u8 rxmcs;
- is_cck_rate = RX_HAL_IS_CCK_RATE(pdesc->rxmcs);
+ rxmcs = get_rx_desc_rxmcs(pdesc);
+ is_cck_rate = rxmcs <= DESC_RATE11M;
pstats->packet_matchbssid = packet_match_bssid;
pstats->packet_toself = packet_toself;
pstats->packet_beacon = packet_beacon;
@@ -157,8 +159,8 @@ static void _rtl92de_query_rxphystatus(s
pstats->rx_pwdb_all = pwdb_all;
pstats->rxpower = rx_pwr_all;
pstats->recvsignalpower = rx_pwr_all;
- if (pdesc->rxht && pdesc->rxmcs >= DESC_RATEMCS8 &&
- pdesc->rxmcs <= DESC_RATEMCS15)
+ if (get_rx_desc_rxht(pdesc) && rxmcs >= DESC_RATEMCS8 &&
+ rxmcs <= DESC_RATEMCS15)
max_spatial_stream = 2;
else
max_spatial_stream = 1;
@@ -364,7 +366,7 @@ static void _rtl92de_process_phyinfo(str
static void _rtl92de_translate_rx_signal_stuff(struct ieee80211_hw *hw,
struct sk_buff *skb,
struct rtl_stats *pstats,
- struct rx_desc_92d *pdesc,
+ __le32 *pdesc,
struct rx_fwinfo_92d *p_drvinfo)
{
struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
@@ -440,9 +442,7 @@ bool rtl92de_rx_query_desc(struct ieee80
if (phystatus) {
p_drvinfo = (struct rx_fwinfo_92d *)(skb->data +
stats->rx_bufshift);
- _rtl92de_translate_rx_signal_stuff(hw,
- skb, stats,
- (struct rx_desc_92d *)pdesc,
+ _rtl92de_translate_rx_signal_stuff(hw, skb, stats, pdesc,
p_drvinfo);
}
/*rx_status->qual = stats->signal; */
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.h
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.h
@@ -394,10 +394,17 @@ struct rx_fwinfo_92d {
u8 csi_target[2];
u8 sigevm;
u8 max_ex_pwr;
+#ifdef __LITTLE_ENDIAN
u8 ex_intf_flag:1;
u8 sgi_en:1;
u8 rxsc:2;
u8 reserve:4;
+#else
+ u8 reserve:4;
+ u8 rxsc:2;
+ u8 sgi_en:1;
+ u8 ex_intf_flag:1;
+#endif
} __packed;
struct tx_desc_92d {
@@ -502,64 +509,6 @@ struct tx_desc_92d {
u32 reserve_pass_pcie_mm_limit[4];
} __packed;
-struct rx_desc_92d {
- u32 length:14;
- u32 crc32:1;
- u32 icverror:1;
- u32 drv_infosize:4;
- u32 security:3;
- u32 qos:1;
- u32 shift:2;
- u32 phystatus:1;
- u32 swdec:1;
- u32 lastseg:1;
- u32 firstseg:1;
- u32 eor:1;
- u32 own:1;
-
- u32 macid:5;
- u32 tid:4;
- u32 hwrsvd:5;
- u32 paggr:1;
- u32 faggr:1;
- u32 a1_fit:4;
- u32 a2_fit:4;
- u32 pam:1;
- u32 pwr:1;
- u32 moredata:1;
- u32 morefrag:1;
- u32 type:2;
- u32 mc:1;
- u32 bc:1;
-
- u32 seq:12;
- u32 frag:4;
- u32 nextpktlen:14;
- u32 nextind:1;
- u32 rsvd:1;
-
- u32 rxmcs:6;
- u32 rxht:1;
- u32 amsdu:1;
- u32 splcp:1;
- u32 bandwidth:1;
- u32 htc:1;
- u32 tcpchk_rpt:1;
- u32 ipcchk_rpt:1;
- u32 tcpchk_valid:1;
- u32 hwpcerr:1;
- u32 hwpcind:1;
- u32 iv0:16;
-
- u32 iv1;
-
- u32 tsfl;
-
- u32 bufferaddress;
- u32 bufferaddress64;
-
-} __packed;
-
void rtl92de_tx_fill_desc(struct ieee80211_hw *hw,
struct ieee80211_hdr *hdr, u8 *pdesc,
u8 *pbd_desc_tx, struct ieee80211_tx_info *info,
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 031/157] arm64: dts: qcom: sc8280xp: add missing PCIe minimum OPP
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (29 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 030/157] wifi: rtlwifi: rtl8192de: Fix endianness issue in RX path Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 032/157] arm64: dts: hi3798cv200: fix the size of GICR Greg Kroah-Hartman
` (135 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Konrad Dybcio, Manivannan Sadhasivam,
Johan Hovold, Bjorn Andersson
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan+linaro@kernel.org>
commit 2b621971554a94094cf489314dc1c2b65401965c upstream.
Add the missing PCIe CX performance level votes to avoid relying on
other drivers (e.g. USB or UFS) to maintain the nominal performance
level required for Gen3 speeds.
Fixes: 813e83157001 ("arm64: dts: qcom: sc8280xp/sa8540p: add PCIe2-4 nodes")
Cc: stable@vger.kernel.org # 6.2
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20240306095651.4551-5-johan+linaro@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 5 +++++
1 file changed, 5 insertions(+)
--- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
@@ -1799,6 +1799,7 @@
assigned-clock-rates = <100000000>;
power-domains = <&gcc PCIE_4_GDSC>;
+ required-opps = <&rpmhpd_opp_nom>;
resets = <&gcc GCC_PCIE_4_PHY_BCR>;
reset-names = "phy";
@@ -1898,6 +1899,7 @@
assigned-clock-rates = <100000000>;
power-domains = <&gcc PCIE_3B_GDSC>;
+ required-opps = <&rpmhpd_opp_nom>;
resets = <&gcc GCC_PCIE_3B_PHY_BCR>;
reset-names = "phy";
@@ -1998,6 +2000,7 @@
assigned-clock-rates = <100000000>;
power-domains = <&gcc PCIE_3A_GDSC>;
+ required-opps = <&rpmhpd_opp_nom>;
resets = <&gcc GCC_PCIE_3A_PHY_BCR>;
reset-names = "phy";
@@ -2099,6 +2102,7 @@
assigned-clock-rates = <100000000>;
power-domains = <&gcc PCIE_2B_GDSC>;
+ required-opps = <&rpmhpd_opp_nom>;
resets = <&gcc GCC_PCIE_2B_PHY_BCR>;
reset-names = "phy";
@@ -2199,6 +2203,7 @@
assigned-clock-rates = <100000000>;
power-domains = <&gcc PCIE_2A_GDSC>;
+ required-opps = <&rpmhpd_opp_nom>;
resets = <&gcc GCC_PCIE_2A_PHY_BCR>;
reset-names = "phy";
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 032/157] arm64: dts: hi3798cv200: fix the size of GICR
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (30 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 031/157] arm64: dts: qcom: sc8280xp: add missing PCIe minimum OPP Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 033/157] arm64: dts: ti: verdin-am62: Set memory size to 2gb Greg Kroah-Hartman
` (134 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Yang Xiwen, Krzysztof Kozlowski
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Xiwen <forbidden405@outlook.com>
commit 428a575dc9038846ad259466d5ba109858c0a023 upstream.
During boot, Linux kernel complains:
[ 0.000000] GIC: GICv2 detected, but range too small and irqchip.gicv2_force_probe not set
This SoC is using a regular GIC-400 and the GICR space size should be
8KB rather than 256B.
With this patch:
[ 0.000000] GIC: Using split EOI/Deactivate mode
So this should be the correct fix.
Fixes: 2f20182ed670 ("arm64: dts: hisilicon: add dts files for hi3798cv200-poplar board")
Signed-off-by: Yang Xiwen <forbidden405@outlook.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240219-cache-v3-1-a33c57534ae9@outlook.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
@@ -58,7 +58,7 @@
gic: interrupt-controller@f1001000 {
compatible = "arm,gic-400";
reg = <0x0 0xf1001000 0x0 0x1000>, /* GICD */
- <0x0 0xf1002000 0x0 0x100>; /* GICC */
+ <0x0 0xf1002000 0x0 0x2000>; /* GICC */
#address-cells = <0>;
#interrupt-cells = <3>;
interrupt-controller;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 033/157] arm64: dts: ti: verdin-am62: Set memory size to 2gb
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (31 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 032/157] arm64: dts: hi3798cv200: fix the size of GICR Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 034/157] media: mgb4: Fix double debugfs remove Greg Kroah-Hartman
` (133 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Max Krummenacher, Francesco Dolcini,
Nishanth Menon
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Max Krummenacher <max.krummenacher@toradex.com>
commit f70a88829723c1b462ea0fec15fa75809a0d670b upstream.
The maximum DDR RAM size stuffed on the Verdin AM62 is 2GB,
correct the memory node accordingly.
Fixes: 316b80246b16 ("arm64: dts: ti: add verdin am62")
Cc: <stable@vger.kernel.org>
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20240320142937.2028707-1-max.oss.09@gmail.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
@@ -76,7 +76,7 @@
memory@80000000 {
device_type = "memory";
- reg = <0x00000000 0x80000000 0x00000000 0x40000000>; /* 1G RAM */
+ reg = <0x00000000 0x80000000 0x00000000 0x80000000>; /* 2G RAM */
};
opp-table {
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 034/157] media: mgb4: Fix double debugfs remove
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (32 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 033/157] arm64: dts: ti: verdin-am62: Set memory size to 2gb Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 035/157] media: mc: Fix graph walk in media_pipeline_start Greg Kroah-Hartman
` (132 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Martin Tůma, Hans Verkuil
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Tůma <martin.tuma@digiteqautomotive.com>
commit 825fc49497957310e421454fe3fb8b8d8d8e2dd2 upstream.
Fixes an error where debugfs_remove_recursive() is called first on a parent
directory and then again on a child which causes a kernel panic.
Signed-off-by: Martin Tůma <martin.tuma@digiteqautomotive.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Fixes: 0ab13674a9bd ("media: pci: mgb4: Added Digiteq Automotive MGB4 driver")
Cc: <stable@vger.kernel.org>
[hverkuil: added Fixes/Cc tags]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/pci/mgb4/mgb4_core.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/media/pci/mgb4/mgb4_core.c
+++ b/drivers/media/pci/mgb4/mgb4_core.c
@@ -642,9 +642,6 @@ static void mgb4_remove(struct pci_dev *
struct mgb4_dev *mgbdev = pci_get_drvdata(pdev);
int i;
-#ifdef CONFIG_DEBUG_FS
- debugfs_remove_recursive(mgbdev->debugfs);
-#endif
#if IS_REACHABLE(CONFIG_HWMON)
hwmon_device_unregister(mgbdev->hwmon_dev);
#endif
@@ -659,6 +656,10 @@ static void mgb4_remove(struct pci_dev *
if (mgbdev->vin[i])
mgb4_vin_free(mgbdev->vin[i]);
+#ifdef CONFIG_DEBUG_FS
+ debugfs_remove_recursive(mgbdev->debugfs);
+#endif
+
device_remove_groups(&mgbdev->pdev->dev, mgb4_pci_groups);
free_spi(mgbdev);
free_i2c(mgbdev);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 035/157] media: mc: Fix graph walk in media_pipeline_start
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (33 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 034/157] media: mgb4: Fix double debugfs remove Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 036/157] media: mc: mark the media devnode as registered from the, start Greg Kroah-Hartman
` (131 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Tomi Valkeinen, Sakari Ailus,
Hans Verkuil
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
commit 8a9d420149c477e7c97fbd6453704e4612bdd3fa upstream.
The graph walk tries to follow all links, even if they are not between
pads. This causes a crash with, e.g. a MEDIA_LNK_FL_ANCILLARY_LINK link.
Fix this by allowing the walk to proceed only for MEDIA_LNK_FL_DATA_LINK
links.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Cc: stable@vger.kernel.org # for 6.1 and later
Fixes: ae219872834a ("media: mc: entity: Rewrite media_pipeline_start()")
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/mc/mc-entity.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/media/mc/mc-entity.c
+++ b/drivers/media/mc/mc-entity.c
@@ -619,6 +619,12 @@ static int media_pipeline_explore_next_l
link = list_entry(entry->links, typeof(*link), list);
last_link = media_pipeline_walk_pop(walk);
+ if ((link->flags & MEDIA_LNK_FL_LINK_TYPE) != MEDIA_LNK_FL_DATA_LINK) {
+ dev_dbg(walk->mdev->dev,
+ "media pipeline: skipping link (not data-link)\n");
+ return 0;
+ }
+
dev_dbg(walk->mdev->dev,
"media pipeline: exploring link '%s':%u -> '%s':%u\n",
link->source->entity->name, link->source->index,
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 036/157] media: mc: mark the media devnode as registered from the, start
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (34 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 035/157] media: mc: Fix graph walk in media_pipeline_start Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 037/157] media: mxl5xx: Move xpt structures off stack Greg Kroah-Hartman
` (130 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Hans Verkuil, Sakari Ailus,
Laurent Pinchart
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
commit 4bc60736154bc9e0e39d3b88918f5d3762ebe5e0 upstream.
First the media device node was created, and if successful it was
marked as 'registered'. This leaves a small race condition where
an application can open the device node and get an error back
because the 'registered' flag was not yet set.
Change the order: first set the 'registered' flag, then actually
register the media device node. If that fails, then clear the flag.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Fixes: cf4b9211b568 ("[media] media: Media device node support")
Cc: stable@vger.kernel.org
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/mc/mc-devnode.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/media/mc/mc-devnode.c
+++ b/drivers/media/mc/mc-devnode.c
@@ -245,15 +245,14 @@ int __must_check media_devnode_register(
kobject_set_name(&devnode->cdev.kobj, "media%d", devnode->minor);
/* Part 3: Add the media and char device */
+ set_bit(MEDIA_FLAG_REGISTERED, &devnode->flags);
ret = cdev_device_add(&devnode->cdev, &devnode->dev);
if (ret < 0) {
+ clear_bit(MEDIA_FLAG_REGISTERED, &devnode->flags);
pr_err("%s: cdev_device_add failed\n", __func__);
goto cdev_add_error;
}
- /* Part 4: Activate this minor. The char device can now be used. */
- set_bit(MEDIA_FLAG_REGISTERED, &devnode->flags);
-
return 0;
cdev_add_error:
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 037/157] media: mxl5xx: Move xpt structures off stack
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (35 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 036/157] media: mc: mark the media devnode as registered from the, start Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 038/157] media: v4l2-core: hold videodev_lock until dev reg, finishes Greg Kroah-Hartman
` (129 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Nathan Chancellor, Miguel Ojeda,
Mauro Carvalho Chehab
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Chancellor <nathan@kernel.org>
commit 526f4527545b2d4ce0733733929fac7b6da09ac6 upstream.
When building for LoongArch with clang 18.0.0, the stack usage of
probe() is larger than the allowed 2048 bytes:
drivers/media/dvb-frontends/mxl5xx.c:1698:12: warning: stack frame size (2368) exceeds limit (2048) in 'probe' [-Wframe-larger-than]
1698 | static int probe(struct mxl *state, struct mxl5xx_cfg *cfg)
| ^
1 warning generated.
This is the result of the linked LLVM commit, which changes how the
arrays of structures in config_ts() get handled with
CONFIG_INIT_STACK_ZERO and CONFIG_INIT_STACK_PATTERN, which causes the
above warning in combination with inlining, as config_ts() gets inlined
into probe().
This warning can be easily fixed by moving the array of structures off
of the stackvia 'static const', which is a better location for these
variables anyways because they are static data that is only ever read
from, never modified, so allocating the stack space is wasteful.
This drops the stack usage from 2368 bytes to 256 bytes with the same
compiler and configuration.
Link: https://lore.kernel.org/linux-media/20240111-dvb-mxl5xx-move-structs-off-stack-v1-1-ca4230e67c11@kernel.org
Cc: stable@vger.kernel.org
Closes: https://github.com/ClangBuiltLinux/linux/issues/1977
Link: https://github.com/llvm/llvm-project/commit/afe8b93ffdfef5d8879e1894b9d7dda40dee2b8d
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Tested-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/dvb-frontends/mxl5xx.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
--- a/drivers/media/dvb-frontends/mxl5xx.c
+++ b/drivers/media/dvb-frontends/mxl5xx.c
@@ -1381,57 +1381,57 @@ static int config_ts(struct mxl *state,
u32 nco_count_min = 0;
u32 clk_type = 0;
- struct MXL_REG_FIELD_T xpt_sync_polarity[MXL_HYDRA_DEMOD_MAX] = {
+ static const struct MXL_REG_FIELD_T xpt_sync_polarity[MXL_HYDRA_DEMOD_MAX] = {
{0x90700010, 8, 1}, {0x90700010, 9, 1},
{0x90700010, 10, 1}, {0x90700010, 11, 1},
{0x90700010, 12, 1}, {0x90700010, 13, 1},
{0x90700010, 14, 1}, {0x90700010, 15, 1} };
- struct MXL_REG_FIELD_T xpt_clock_polarity[MXL_HYDRA_DEMOD_MAX] = {
+ static const struct MXL_REG_FIELD_T xpt_clock_polarity[MXL_HYDRA_DEMOD_MAX] = {
{0x90700010, 16, 1}, {0x90700010, 17, 1},
{0x90700010, 18, 1}, {0x90700010, 19, 1},
{0x90700010, 20, 1}, {0x90700010, 21, 1},
{0x90700010, 22, 1}, {0x90700010, 23, 1} };
- struct MXL_REG_FIELD_T xpt_valid_polarity[MXL_HYDRA_DEMOD_MAX] = {
+ static const struct MXL_REG_FIELD_T xpt_valid_polarity[MXL_HYDRA_DEMOD_MAX] = {
{0x90700014, 0, 1}, {0x90700014, 1, 1},
{0x90700014, 2, 1}, {0x90700014, 3, 1},
{0x90700014, 4, 1}, {0x90700014, 5, 1},
{0x90700014, 6, 1}, {0x90700014, 7, 1} };
- struct MXL_REG_FIELD_T xpt_ts_clock_phase[MXL_HYDRA_DEMOD_MAX] = {
+ static const struct MXL_REG_FIELD_T xpt_ts_clock_phase[MXL_HYDRA_DEMOD_MAX] = {
{0x90700018, 0, 3}, {0x90700018, 4, 3},
{0x90700018, 8, 3}, {0x90700018, 12, 3},
{0x90700018, 16, 3}, {0x90700018, 20, 3},
{0x90700018, 24, 3}, {0x90700018, 28, 3} };
- struct MXL_REG_FIELD_T xpt_lsb_first[MXL_HYDRA_DEMOD_MAX] = {
+ static const struct MXL_REG_FIELD_T xpt_lsb_first[MXL_HYDRA_DEMOD_MAX] = {
{0x9070000C, 16, 1}, {0x9070000C, 17, 1},
{0x9070000C, 18, 1}, {0x9070000C, 19, 1},
{0x9070000C, 20, 1}, {0x9070000C, 21, 1},
{0x9070000C, 22, 1}, {0x9070000C, 23, 1} };
- struct MXL_REG_FIELD_T xpt_sync_byte[MXL_HYDRA_DEMOD_MAX] = {
+ static const struct MXL_REG_FIELD_T xpt_sync_byte[MXL_HYDRA_DEMOD_MAX] = {
{0x90700010, 0, 1}, {0x90700010, 1, 1},
{0x90700010, 2, 1}, {0x90700010, 3, 1},
{0x90700010, 4, 1}, {0x90700010, 5, 1},
{0x90700010, 6, 1}, {0x90700010, 7, 1} };
- struct MXL_REG_FIELD_T xpt_enable_output[MXL_HYDRA_DEMOD_MAX] = {
+ static const struct MXL_REG_FIELD_T xpt_enable_output[MXL_HYDRA_DEMOD_MAX] = {
{0x9070000C, 0, 1}, {0x9070000C, 1, 1},
{0x9070000C, 2, 1}, {0x9070000C, 3, 1},
{0x9070000C, 4, 1}, {0x9070000C, 5, 1},
{0x9070000C, 6, 1}, {0x9070000C, 7, 1} };
- struct MXL_REG_FIELD_T xpt_err_replace_sync[MXL_HYDRA_DEMOD_MAX] = {
+ static const struct MXL_REG_FIELD_T xpt_err_replace_sync[MXL_HYDRA_DEMOD_MAX] = {
{0x9070000C, 24, 1}, {0x9070000C, 25, 1},
{0x9070000C, 26, 1}, {0x9070000C, 27, 1},
{0x9070000C, 28, 1}, {0x9070000C, 29, 1},
{0x9070000C, 30, 1}, {0x9070000C, 31, 1} };
- struct MXL_REG_FIELD_T xpt_err_replace_valid[MXL_HYDRA_DEMOD_MAX] = {
+ static const struct MXL_REG_FIELD_T xpt_err_replace_valid[MXL_HYDRA_DEMOD_MAX] = {
{0x90700014, 8, 1}, {0x90700014, 9, 1},
{0x90700014, 10, 1}, {0x90700014, 11, 1},
{0x90700014, 12, 1}, {0x90700014, 13, 1},
{0x90700014, 14, 1}, {0x90700014, 15, 1} };
- struct MXL_REG_FIELD_T xpt_continuous_clock[MXL_HYDRA_DEMOD_MAX] = {
+ static const struct MXL_REG_FIELD_T xpt_continuous_clock[MXL_HYDRA_DEMOD_MAX] = {
{0x907001D4, 0, 1}, {0x907001D4, 1, 1},
{0x907001D4, 2, 1}, {0x907001D4, 3, 1},
{0x907001D4, 4, 1}, {0x907001D4, 5, 1},
{0x907001D4, 6, 1}, {0x907001D4, 7, 1} };
- struct MXL_REG_FIELD_T xpt_nco_clock_rate[MXL_HYDRA_DEMOD_MAX] = {
+ static const struct MXL_REG_FIELD_T xpt_nco_clock_rate[MXL_HYDRA_DEMOD_MAX] = {
{0x90700044, 16, 80}, {0x90700044, 16, 81},
{0x90700044, 16, 82}, {0x90700044, 16, 83},
{0x90700044, 16, 84}, {0x90700044, 16, 85},
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 038/157] media: v4l2-core: hold videodev_lock until dev reg, finishes
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (36 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 037/157] media: mxl5xx: Move xpt structures off stack Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 039/157] media: ov2740: Fix LINK_FREQ and PIXEL_RATE control value reporting Greg Kroah-Hartman
` (128 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Hans Verkuil, Sakari Ailus
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
commit 1ed4477f2ea4743e7c5e1f9f3722152d14e6eeb1 upstream.
After the new V4L2 device node was registered, some additional
initialization was done before the device node was marked as
'registered'. During the time between creating the device node
and marking it as 'registered' it was possible to open the
device node, which would return -ENODEV since the 'registered'
flag was not yet set.
Hold the videodev_lock mutex from just before the device node
is registered until the 'registered' flag is set. Since v4l2_open
will take the same lock, it will wait until this registration
process is finished. This resolves this race condition.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: <stable@vger.kernel.org> # for vi4.18 and up
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/v4l2-core/v4l2-dev.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -1036,8 +1036,10 @@ int __video_register_device(struct video
vdev->dev.devt = MKDEV(VIDEO_MAJOR, vdev->minor);
vdev->dev.parent = vdev->dev_parent;
dev_set_name(&vdev->dev, "%s%d", name_base, vdev->num);
+ mutex_lock(&videodev_lock);
ret = device_register(&vdev->dev);
if (ret < 0) {
+ mutex_unlock(&videodev_lock);
pr_err("%s: device_register failed\n", __func__);
goto cleanup;
}
@@ -1057,6 +1059,7 @@ int __video_register_device(struct video
/* Part 6: Activate this minor. The char device can now be used. */
set_bit(V4L2_FL_REGISTERED, &vdev->flags);
+ mutex_unlock(&videodev_lock);
return 0;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 039/157] media: ov2740: Fix LINK_FREQ and PIXEL_RATE control value reporting
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (37 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 038/157] media: v4l2-core: hold videodev_lock until dev reg, finishes Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 040/157] media: v4l: async: Properly re-initialise notifier entry in unregister Greg Kroah-Hartman
` (127 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Sakari Ailus, Hans de Goede,
Bingbu Cao, Hans Verkuil
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sakari Ailus <sakari.ailus@linux.intel.com>
commit f7aa5995910cb5e7a5419c6705f465c55973b714 upstream.
The driver dug the supported link frequency up from the V4L2 fwnode
endpoint and used it internally, but failed to report this in the
LINK_FREQ and PIXEL_RATE controls. Fix this.
Fixes: 0677a2d9b735 ("media: ov2740: Add support for 180 MHz link frequency")
Cc: stable@vger.kernel.org # for v6.8 and later
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/i2c/ov2740.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/drivers/media/i2c/ov2740.c
+++ b/drivers/media/i2c/ov2740.c
@@ -768,14 +768,15 @@ static int ov2740_init_controls(struct o
cur_mode = ov2740->cur_mode;
size = ARRAY_SIZE(link_freq_menu_items);
- ov2740->link_freq = v4l2_ctrl_new_int_menu(ctrl_hdlr, &ov2740_ctrl_ops,
- V4L2_CID_LINK_FREQ,
- size - 1, 0,
- link_freq_menu_items);
+ ov2740->link_freq =
+ v4l2_ctrl_new_int_menu(ctrl_hdlr, &ov2740_ctrl_ops,
+ V4L2_CID_LINK_FREQ, size - 1,
+ ov2740->supported_modes->link_freq_index,
+ link_freq_menu_items);
if (ov2740->link_freq)
ov2740->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
- pixel_rate = to_pixel_rate(OV2740_LINK_FREQ_360MHZ_INDEX);
+ pixel_rate = to_pixel_rate(ov2740->supported_modes->link_freq_index);
ov2740->pixel_rate = v4l2_ctrl_new_std(ctrl_hdlr, &ov2740_ctrl_ops,
V4L2_CID_PIXEL_RATE, 0,
pixel_rate, 1, pixel_rate);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 040/157] media: v4l: async: Properly re-initialise notifier entry in unregister
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (38 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 039/157] media: ov2740: Fix LINK_FREQ and PIXEL_RATE control value reporting Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 041/157] media: v4l: async: Dont set notifiers V4L2 device if registering fails Greg Kroah-Hartman
` (126 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Sakari Ailus, Hans Verkuil
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sakari Ailus <sakari.ailus@linux.intel.com>
commit 9537a8425a7a0222999d5839a0b394b1e8834b4a upstream.
The notifier_entry of a notifier is not re-initialised after unregistering
the notifier. This leads to dangling pointers being left there so use
list_del_init() to return the notifier_entry an empty list.
Fixes: b8ec754ae4c5 ("media: v4l: async: Set v4l2_device and subdev in async notifier init")
Cc: <stable@vger.kernel.org> # for 6.6 and later
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/v4l2-core/v4l2-async.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -639,7 +639,7 @@ __v4l2_async_nf_unregister(struct v4l2_a
v4l2_async_nf_unbind_all_subdevs(notifier);
- list_del(¬ifier->notifier_entry);
+ list_del_init(¬ifier->notifier_entry);
}
void v4l2_async_nf_unregister(struct v4l2_async_notifier *notifier)
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 041/157] media: v4l: async: Dont set notifiers V4L2 device if registering fails
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (39 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 040/157] media: v4l: async: Properly re-initialise notifier entry in unregister Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 042/157] media: v4l: async: Fix notifier list entry init Greg Kroah-Hartman
` (125 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Sakari Ailus, Hans Verkuil
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sakari Ailus <sakari.ailus@linux.intel.com>
commit 46bc0234ad38063ce550ecf135c1a52458f0a804 upstream.
The V4L2 device used to be set when the notifier was registered but this
has been moved to the notifier initialisation. Don't touch the V4L2 device
if registration fails.
Fixes: b8ec754ae4c5 ("media: v4l: async: Set v4l2_device and subdev in async notifier init")
Cc: <stable@vger.kernel.org> # for 6.6 and later
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/v4l2-core/v4l2-async.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -618,16 +618,10 @@ err_unlock:
int v4l2_async_nf_register(struct v4l2_async_notifier *notifier)
{
- int ret;
-
if (WARN_ON(!notifier->v4l2_dev == !notifier->sd))
return -EINVAL;
- ret = __v4l2_async_nf_register(notifier);
- if (ret)
- notifier->v4l2_dev = NULL;
-
- return ret;
+ return __v4l2_async_nf_register(notifier);
}
EXPORT_SYMBOL(v4l2_async_nf_register);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 042/157] media: v4l: async: Fix notifier list entry init
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (40 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 041/157] media: v4l: async: Dont set notifiers V4L2 device if registering fails Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 043/157] mmc: davinci: Dont strip remove function when driver is builtin Greg Kroah-Hartman
` (124 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Alexander Stein, Sakari Ailus,
Hans Verkuil
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Stein <alexander.stein@ew.tq-group.com>
commit 6d8acd02c4c6a8f917eefac1de2e035521ca119d upstream.
struct v4l2_async_notifier has several list_head members, but only
waiting_list and done_list are initialized. notifier_entry was kept
'zeroed' leading to an uninitialized list_head.
This results in a NULL-pointer dereference if csi2_async_register() fails,
e.g. node for remote endpoint is disabled, and returns -ENOTCONN.
The following calls to v4l2_async_nf_unregister() results in a NULL
pointer dereference.
Add the missing list head initializer.
Fixes: b8ec754ae4c5 ("media: v4l: async: Set v4l2_device and subdev in async notifier init")
Cc: <stable@vger.kernel.org> # for 6.6 and later
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/v4l2-core/v4l2-async.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -563,6 +563,7 @@ void v4l2_async_nf_init(struct v4l2_asyn
{
INIT_LIST_HEAD(¬ifier->waiting_list);
INIT_LIST_HEAD(¬ifier->done_list);
+ INIT_LIST_HEAD(¬ifier->notifier_entry);
notifier->v4l2_dev = v4l2_dev;
}
EXPORT_SYMBOL(v4l2_async_nf_init);
@@ -572,6 +573,7 @@ void v4l2_async_subdev_nf_init(struct v4
{
INIT_LIST_HEAD(¬ifier->waiting_list);
INIT_LIST_HEAD(¬ifier->done_list);
+ INIT_LIST_HEAD(¬ifier->notifier_entry);
notifier->sd = sd;
}
EXPORT_SYMBOL_GPL(v4l2_async_subdev_nf_init);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 043/157] mmc: davinci: Dont strip remove function when driver is builtin
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (41 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 042/157] media: v4l: async: Fix notifier list entry init Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 044/157] mmc: core: Add mmc_gpiod_set_cd_config() function Greg Kroah-Hartman
` (123 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Uwe Kleine-König, Ulf Hansson
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
commit 55c421b364482b61c4c45313a535e61ed5ae4ea3 upstream.
Using __exit for the remove function results in the remove callback being
discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g.
using sysfs or hotplug), the driver is just removed without the cleanup
being performed. This results in resource leaks. Fix it by compiling in the
remove callback unconditionally.
This also fixes a W=1 modpost warning:
WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in
reference: davinci_mmcsd_driver+0x10 (section: .data) ->
davinci_mmcsd_remove (section: .exit.text)
Fixes: b4cff4549b7a ("DaVinci: MMC: MMC/SD controller driver for DaVinci family")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240324114017.231936-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/davinci_mmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -1337,7 +1337,7 @@ ioremap_fail:
return ret;
}
-static void __exit davinci_mmcsd_remove(struct platform_device *pdev)
+static void davinci_mmcsd_remove(struct platform_device *pdev)
{
struct mmc_davinci_host *host = platform_get_drvdata(pdev);
@@ -1392,7 +1392,7 @@ static struct platform_driver davinci_mm
.of_match_table = davinci_mmc_dt_ids,
},
.probe = davinci_mmcsd_probe,
- .remove_new = __exit_p(davinci_mmcsd_remove),
+ .remove_new = davinci_mmcsd_remove,
.id_table = davinci_mmc_devtype,
};
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 044/157] mmc: core: Add mmc_gpiod_set_cd_config() function
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (42 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 043/157] mmc: davinci: Dont strip remove function when driver is builtin Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 045/157] mmc: sdhci: Add support for "Tuning Error" interrupts Greg Kroah-Hartman
` (122 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Andy Shevchenko, Hans de Goede,
Adrian Hunter, Ulf Hansson
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit 63a7cd660246aa36af263b85c33ecc6601bf04be upstream.
Some mmc host drivers may need to fixup a card-detection GPIO's config
to e.g. enable the GPIO controllers builtin pull-up resistor on devices
where the firmware description of the GPIO is broken (e.g. GpioInt with
PullNone instead of PullUp in ACPI DSDT).
Since this is the exception rather then the rule adding a config
parameter to mmc_gpiod_request_cd() seems undesirable, so instead
add a new mmc_gpiod_set_cd_config() function. This is simply a wrapper
to call gpiod_set_config() on the card-detect GPIO acquired through
mmc_gpiod_request_cd().
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240410191639.526324-2-hdegoede@redhat.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/core/slot-gpio.c | 20 ++++++++++++++++++++
include/linux/mmc/slot-gpio.h | 1 +
2 files changed, 21 insertions(+)
--- a/drivers/mmc/core/slot-gpio.c
+++ b/drivers/mmc/core/slot-gpio.c
@@ -221,6 +221,26 @@ int mmc_gpiod_request_cd(struct mmc_host
}
EXPORT_SYMBOL(mmc_gpiod_request_cd);
+/**
+ * mmc_gpiod_set_cd_config - set config for card-detection GPIO
+ * @host: mmc host
+ * @config: Generic pinconf config (from pinconf_to_config_packed())
+ *
+ * This can be used by mmc host drivers to fixup a card-detection GPIO's config
+ * (e.g. set PIN_CONFIG_BIAS_PULL_UP) after acquiring the GPIO descriptor
+ * through mmc_gpiod_request_cd().
+ *
+ * Returns:
+ * 0 on success, or a negative errno value on error.
+ */
+int mmc_gpiod_set_cd_config(struct mmc_host *host, unsigned long config)
+{
+ struct mmc_gpio *ctx = host->slot.handler_priv;
+
+ return gpiod_set_config(ctx->cd_gpio, config);
+}
+EXPORT_SYMBOL(mmc_gpiod_set_cd_config);
+
bool mmc_can_gpio_cd(struct mmc_host *host)
{
struct mmc_gpio *ctx = host->slot.handler_priv;
--- a/include/linux/mmc/slot-gpio.h
+++ b/include/linux/mmc/slot-gpio.h
@@ -21,6 +21,7 @@ int mmc_gpiod_request_cd(struct mmc_host
unsigned int debounce);
int mmc_gpiod_request_ro(struct mmc_host *host, const char *con_id,
unsigned int idx, unsigned int debounce);
+int mmc_gpiod_set_cd_config(struct mmc_host *host, unsigned long config);
void mmc_gpio_set_cd_isr(struct mmc_host *host,
irqreturn_t (*isr)(int irq, void *dev_id));
int mmc_gpio_set_cd_wake(struct mmc_host *host, bool on);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 045/157] mmc: sdhci: Add support for "Tuning Error" interrupts
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (43 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 044/157] mmc: core: Add mmc_gpiod_set_cd_config() function Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 046/157] mmc: sdhci-acpi: Sort DMI quirks alphabetically Greg Kroah-Hartman
` (121 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Hans de Goede, Adrian Hunter,
Ulf Hansson
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <adrian.hunter@intel.com>
commit b3855668d98cf9c6aec2db999dd27d872f8ba878 upstream.
Most Bay Trail devices do not enable UHS modes for the external sdcard slot
the Lenovo Yoga Tablet 2 830 / 1050 and Lenovo Yoga Tablet 2 Pro 1380 (8",
10" and 13") models however do enable this.
Using a UHS cards in these tablets results in errors like this one:
[ 225.272001] mmc2: Unexpected interrupt 0x04000000.
[ 225.272024] mmc2: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 225.272034] mmc2: sdhci: Sys addr: 0x0712c400 | Version: 0x0000b502
[ 225.272044] mmc2: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000007
[ 225.272054] mmc2: sdhci: Argument: 0x00000000 | Trn mode: 0x00000023
[ 225.272064] mmc2: sdhci: Present: 0x01e20002 | Host ctl: 0x00000016
[ 225.272073] mmc2: sdhci: Power: 0x0000000f | Blk gap: 0x00000000
[ 225.272082] mmc2: sdhci: Wake-up: 0x00000000 | Clock: 0x00000107
[ 225.272092] mmc2: sdhci: Timeout: 0x0000000e | Int stat: 0x00000001
[ 225.272101] mmc2: sdhci: Int enab: 0x03ff000b | Sig enab: 0x03ff000b
[ 225.272110] mmc2: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000001
[ 225.272119] mmc2: sdhci: Caps: 0x076864b2 | Caps_1: 0x00000004
[ 225.272129] mmc2: sdhci: Cmd: 0x00000c1b | Max curr: 0x00000000
[ 225.272138] mmc2: sdhci: Resp[0]: 0x00000c00 | Resp[1]: 0x00000000
[ 225.272147] mmc2: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000900
[ 225.272155] mmc2: sdhci: Host ctl2: 0x0000000c
[ 225.272164] mmc2: sdhci: ADMA Err: 0x00000003 | ADMA Ptr: 0x0712c200
[ 225.272172] mmc2: sdhci: ============================================
which results in IO errors leading to issues accessing the sdcard.
0x04000000 is a so-called "Tuning Error" which sofar the SDHCI driver
does not support / enable. Modify the IRQ handler to process these.
This fixes UHS microsd cards not working with these tablets.
Link: https://lore.kernel.org/r/199bb4aa-c6b5-453e-be37-58bbf468800c@intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240410191639.526324-3-hdegoede@redhat.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/sdhci.c | 10 ++++++++--
drivers/mmc/host/sdhci.h | 3 ++-
2 files changed, 10 insertions(+), 3 deletions(-)
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3439,12 +3439,18 @@ static void sdhci_data_irq(struct sdhci_
host->data->error = -EILSEQ;
if (!mmc_op_tuning(SDHCI_GET_CMD(sdhci_readw(host, SDHCI_COMMAND))))
sdhci_err_stats_inc(host, DAT_CRC);
- } else if ((intmask & SDHCI_INT_DATA_CRC) &&
+ } else if ((intmask & (SDHCI_INT_DATA_CRC | SDHCI_INT_TUNING_ERROR)) &&
SDHCI_GET_CMD(sdhci_readw(host, SDHCI_COMMAND))
!= MMC_BUS_TEST_R) {
host->data->error = -EILSEQ;
if (!mmc_op_tuning(SDHCI_GET_CMD(sdhci_readw(host, SDHCI_COMMAND))))
sdhci_err_stats_inc(host, DAT_CRC);
+ if (intmask & SDHCI_INT_TUNING_ERROR) {
+ u16 ctrl2 = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+
+ ctrl2 &= ~SDHCI_CTRL_TUNED_CLK;
+ sdhci_writew(host, ctrl2, SDHCI_HOST_CONTROL2);
+ }
} else if (intmask & SDHCI_INT_ADMA_ERROR) {
pr_err("%s: ADMA error: 0x%08x\n", mmc_hostname(host->mmc),
intmask);
@@ -3979,7 +3985,7 @@ bool sdhci_cqe_irq(struct sdhci_host *ho
} else
*cmd_error = 0;
- if (intmask & (SDHCI_INT_DATA_END_BIT | SDHCI_INT_DATA_CRC)) {
+ if (intmask & (SDHCI_INT_DATA_END_BIT | SDHCI_INT_DATA_CRC | SDHCI_INT_TUNING_ERROR)) {
*data_error = -EILSEQ;
if (!mmc_op_tuning(SDHCI_GET_CMD(sdhci_readw(host, SDHCI_COMMAND))))
sdhci_err_stats_inc(host, DAT_CRC);
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -158,6 +158,7 @@
#define SDHCI_INT_BUS_POWER 0x00800000
#define SDHCI_INT_AUTO_CMD_ERR 0x01000000
#define SDHCI_INT_ADMA_ERROR 0x02000000
+#define SDHCI_INT_TUNING_ERROR 0x04000000
#define SDHCI_INT_NORMAL_MASK 0x00007FFF
#define SDHCI_INT_ERROR_MASK 0xFFFF8000
@@ -169,7 +170,7 @@
SDHCI_INT_DATA_AVAIL | SDHCI_INT_SPACE_AVAIL | \
SDHCI_INT_DATA_TIMEOUT | SDHCI_INT_DATA_CRC | \
SDHCI_INT_DATA_END_BIT | SDHCI_INT_ADMA_ERROR | \
- SDHCI_INT_BLK_GAP)
+ SDHCI_INT_BLK_GAP | SDHCI_INT_TUNING_ERROR)
#define SDHCI_INT_ALL_MASK ((unsigned int)-1)
#define SDHCI_CQE_INT_ERR_MASK ( \
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 046/157] mmc: sdhci-acpi: Sort DMI quirks alphabetically
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (44 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 045/157] mmc: sdhci: Add support for "Tuning Error" interrupts Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 047/157] mmc: sdhci-acpi: Fix Lenovo Yoga Tablet 2 Pro 1380 sdcard slot not working Greg Kroah-Hartman
` (120 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Andy Shevchenko, Hans de Goede,
Adrian Hunter, Ulf Hansson
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit a92a73b1d9249d155412d8ac237142fa716803ea upstream.
Sort the DMI quirks alphabetically.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240410191639.526324-4-hdegoede@redhat.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/sdhci-acpi.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
--- a/drivers/mmc/host/sdhci-acpi.c
+++ b/drivers/mmc/host/sdhci-acpi.c
@@ -719,9 +719,22 @@ static const struct acpi_device_id sdhci
};
MODULE_DEVICE_TABLE(acpi, sdhci_acpi_ids);
+/* Please keep this list sorted alphabetically */
static const struct dmi_system_id sdhci_acpi_quirks[] = {
{
/*
+ * The Acer Aspire Switch 10 (SW5-012) microSD slot always
+ * reports the card being write-protected even though microSD
+ * cards do not have a write-protect switch at all.
+ */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire SW5-012"),
+ },
+ .driver_data = (void *)DMI_QUIRK_SD_NO_WRITE_PROTECT,
+ },
+ {
+ /*
* The Lenovo Miix 320-10ICR has a bug in the _PS0 method of
* the SHC1 ACPI device, this bug causes it to reprogram the
* wrong LDO (DLDO3) to 1.8V if 1.8V modes are used and the
@@ -736,18 +749,6 @@ static const struct dmi_system_id sdhci_
},
{
/*
- * The Acer Aspire Switch 10 (SW5-012) microSD slot always
- * reports the card being write-protected even though microSD
- * cards do not have a write-protect switch at all.
- */
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
- DMI_MATCH(DMI_PRODUCT_NAME, "Aspire SW5-012"),
- },
- .driver_data = (void *)DMI_QUIRK_SD_NO_WRITE_PROTECT,
- },
- {
- /*
* The Toshiba WT8-B's microSD slot always reports the card being
* write-protected.
*/
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 047/157] mmc: sdhci-acpi: Fix Lenovo Yoga Tablet 2 Pro 1380 sdcard slot not working
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (45 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 046/157] mmc: sdhci-acpi: Sort DMI quirks alphabetically Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 048/157] mmc: sdhci-acpi: Disable write protect detection on Toshiba WT10-A Greg Kroah-Hartman
` (119 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Andy Shevchenko, Hans de Goede,
Adrian Hunter, Ulf Hansson
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit f3521d7cbaefff19cc656325787ed797e5f6a955 upstream.
The Lenovo Yoga Tablet 2 Pro 1380 sdcard slot has an active high cd pin
and a broken wp pin which always reports the card being write-protected.
Add a DMI quirk to address both issues.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240410191639.526324-5-hdegoede@redhat.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/sdhci-acpi.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
--- a/drivers/mmc/host/sdhci-acpi.c
+++ b/drivers/mmc/host/sdhci-acpi.c
@@ -80,6 +80,7 @@ struct sdhci_acpi_host {
enum {
DMI_QUIRK_RESET_SD_SIGNAL_VOLT_ON_SUSP = BIT(0),
DMI_QUIRK_SD_NO_WRITE_PROTECT = BIT(1),
+ DMI_QUIRK_SD_CD_ACTIVE_HIGH = BIT(2),
};
static inline void *sdhci_acpi_priv(struct sdhci_acpi_host *c)
@@ -749,6 +750,26 @@ static const struct dmi_system_id sdhci_
},
{
/*
+ * Lenovo Yoga Tablet 2 Pro 1380F/L (13" Android version) this
+ * has broken WP reporting and an inverted CD signal.
+ * Note this has more or less the same BIOS as the Lenovo Yoga
+ * Tablet 2 830F/L or 1050F/L (8" and 10" Android), but unlike
+ * the 830 / 1050 models which share the same mainboard this
+ * model has a different mainboard and the inverted CD and
+ * broken WP are unique to this board.
+ */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Intel Corp."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "VALLEYVIEW C0 PLATFORM"),
+ DMI_MATCH(DMI_BOARD_NAME, "BYT-T FFD8"),
+ /* Full match so as to NOT match the 830/1050 BIOS */
+ DMI_MATCH(DMI_BIOS_VERSION, "BLADE_21.X64.0005.R00.1504101516"),
+ },
+ .driver_data = (void *)(DMI_QUIRK_SD_NO_WRITE_PROTECT |
+ DMI_QUIRK_SD_CD_ACTIVE_HIGH),
+ },
+ {
+ /*
* The Toshiba WT8-B's microSD slot always reports the card being
* write-protected.
*/
@@ -867,6 +888,9 @@ static int sdhci_acpi_probe(struct platf
if (sdhci_acpi_flag(c, SDHCI_ACPI_SD_CD)) {
bool v = sdhci_acpi_flag(c, SDHCI_ACPI_SD_CD_OVERRIDE_LEVEL);
+ if (quirks & DMI_QUIRK_SD_CD_ACTIVE_HIGH)
+ host->mmc->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
+
err = mmc_gpiod_request_cd(host->mmc, NULL, 0, v, 0);
if (err) {
if (err == -EPROBE_DEFER)
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 048/157] mmc: sdhci-acpi: Disable write protect detection on Toshiba WT10-A
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (46 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 047/157] mmc: sdhci-acpi: Fix Lenovo Yoga Tablet 2 Pro 1380 sdcard slot not working Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 049/157] mmc: sdhci-acpi: Add quirk to enable pull-up on the card-detect GPIO on Asus T100TA Greg Kroah-Hartman
` (118 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Andy Shevchenko, Hans de Goede,
Adrian Hunter, Ulf Hansson
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit ef3eab75e17191e5665f52e64e85bc29d5705a7b upstream.
On the Toshiba WT10-A the microSD slot always reports the card being
write-protected, just like on the Toshiba WT8-B.
Add a DMI quirk to work around this.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240410191639.526324-6-hdegoede@redhat.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/sdhci-acpi.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/drivers/mmc/host/sdhci-acpi.c
+++ b/drivers/mmc/host/sdhci-acpi.c
@@ -779,6 +779,17 @@ static const struct dmi_system_id sdhci_
},
.driver_data = (void *)DMI_QUIRK_SD_NO_WRITE_PROTECT,
},
+ {
+ /*
+ * The Toshiba WT10-A's microSD slot always reports the card being
+ * write-protected.
+ */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TOSHIBA WT10-A"),
+ },
+ .driver_data = (void *)DMI_QUIRK_SD_NO_WRITE_PROTECT,
+ },
{} /* Terminating entry */
};
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 049/157] mmc: sdhci-acpi: Add quirk to enable pull-up on the card-detect GPIO on Asus T100TA
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (47 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 048/157] mmc: sdhci-acpi: Disable write protect detection on Toshiba WT10-A Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 050/157] drm/fbdev-generic: Do not set physical framebuffer address Greg Kroah-Hartman
` (117 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Andy Shevchenko, Hans de Goede,
Adrian Hunter, Ulf Hansson
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit 431946c0f640c93421439a6c928efb3152c035a4 upstream.
The card-detect GPIO for the microSD slot on Asus T100TA / T100TAM models
stopped working under Linux after commit 6fd03f024828 ("gpiolib: acpi:
support bias pull disable").
The GPIO in question is connected to a mechanical switch in the slot
which shorts the pin to GND when a card is inserted.
The GPIO pin correctly gets configured with a 20K pull-up by the BIOS,
but there is a bug in the DSDT where the GpioInt for the card-detect is
configured with a PullNone setting:
GpioInt (Edge, ActiveBoth, SharedAndWake, PullNone, 0x2710,
"\\_SB.GPO0", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0026
}
Linux now actually honors the PullNone setting and disables the 20K pull-up
configured by the BIOS.
Add a new DMI_QUIRK_SD_CD_ENABLE_PULL_UP quirk which when set calls
mmc_gpiod_set_cd_config() to re-enable the pull-up and set this for
the Asus T100TA models to fix this.
Fixes: 6fd03f024828 ("gpiolib: acpi: support bias pull disable")
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240410191639.526324-7-hdegoede@redhat.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/sdhci-acpi.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
--- a/drivers/mmc/host/sdhci-acpi.c
+++ b/drivers/mmc/host/sdhci-acpi.c
@@ -10,6 +10,7 @@
#include <linux/export.h>
#include <linux/module.h>
#include <linux/device.h>
+#include <linux/pinctrl/pinconf-generic.h>
#include <linux/platform_device.h>
#include <linux/ioport.h>
#include <linux/io.h>
@@ -81,6 +82,7 @@ enum {
DMI_QUIRK_RESET_SD_SIGNAL_VOLT_ON_SUSP = BIT(0),
DMI_QUIRK_SD_NO_WRITE_PROTECT = BIT(1),
DMI_QUIRK_SD_CD_ACTIVE_HIGH = BIT(2),
+ DMI_QUIRK_SD_CD_ENABLE_PULL_UP = BIT(3),
};
static inline void *sdhci_acpi_priv(struct sdhci_acpi_host *c)
@@ -735,6 +737,14 @@ static const struct dmi_system_id sdhci_
.driver_data = (void *)DMI_QUIRK_SD_NO_WRITE_PROTECT,
},
{
+ /* Asus T100TA, needs pull-up for cd but DSDT GpioInt has NoPull set */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "T100TA"),
+ },
+ .driver_data = (void *)DMI_QUIRK_SD_CD_ENABLE_PULL_UP,
+ },
+ {
/*
* The Lenovo Miix 320-10ICR has a bug in the _PS0 method of
* the SHC1 ACPI device, this bug causes it to reprogram the
@@ -908,6 +918,9 @@ static int sdhci_acpi_probe(struct platf
goto err_free;
dev_warn(dev, "failed to setup card detect gpio\n");
c->use_runtime_pm = false;
+ } else if (quirks & DMI_QUIRK_SD_CD_ENABLE_PULL_UP) {
+ mmc_gpiod_set_cd_config(host->mmc,
+ PIN_CONF_PACKED(PIN_CONFIG_BIAS_PULL_UP, 20000));
}
if (quirks & DMI_QUIRK_RESET_SD_SIGNAL_VOLT_ON_SUSP)
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 050/157] drm/fbdev-generic: Do not set physical framebuffer address
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (48 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 049/157] mmc: sdhci-acpi: Add quirk to enable pull-up on the card-detect GPIO on Asus T100TA Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 051/157] fbdev: savage: Handle err return when savagefb_check_var failed Greg Kroah-Hartman
` (116 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Thomas Zimmermann,
Javier Martinez Canillas, Zack Rusin, Maarten Lankhorst,
Maxime Ripard, Zack Rusin, Sui Jingfeng
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Zimmermann <tzimmermann@suse.de>
commit 87cb4a612a89690b123e68f6602d9f6581b03597 upstream.
Framebuffer memory is allocated via vzalloc() from non-contiguous
physical pages. The physical framebuffer start address is therefore
meaningless. Do not set it.
The value is not used within the kernel and only exported to userspace
on dedicated ARM configs. No functional change is expected.
v2:
- refer to vzalloc() in commit message (Javier)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: a5b44c4adb16 ("drm/fbdev-generic: Always use shadow buffering")
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Zack Rusin <zackr@vmware.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: <stable@vger.kernel.org> # v6.4+
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Zack Rusin <zack.rusin@broadcom.com>
Reviewed-by: Sui Jingfeng <sui.jingfeng@linux.dev>
Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240419083331.7761-2-tzimmermann@suse.de
(cherry picked from commit 73ef0aecba78aa9ebd309b10b6cd17d94e632892)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_fbdev_generic.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -113,7 +113,6 @@ static int drm_fbdev_generic_helper_fb_p
/* screen */
info->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
info->screen_buffer = screen_buffer;
- info->fix.smem_start = page_to_phys(vmalloc_to_page(info->screen_buffer));
info->fix.smem_len = screen_size;
/* deferred I/O */
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 051/157] fbdev: savage: Handle err return when savagefb_check_var failed
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (49 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 050/157] drm/fbdev-generic: Do not set physical framebuffer address Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 052/157] firmware: qcom_scm: disable clocks if qcom_scm_bw_enable() fails Greg Kroah-Hartman
` (115 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Cai Xinchen, Helge Deller
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cai Xinchen <caixinchen1@huawei.com>
commit 6ad959b6703e2c4c5d7af03b4cfd5ff608036339 upstream.
The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero")
checks the value of pixclock to avoid divide-by-zero error. However
the function savagefb_probe doesn't handle the error return of
savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.
Fixes: 04e5eac8f3ab ("fbdev: savage: Error out if pixclock equals zero")
Signed-off-by: Cai Xinchen <caixinchen1@huawei.com>
Cc: stable@vger.kernel.org
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/video/fbdev/savage/savagefb_driver.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/video/fbdev/savage/savagefb_driver.c
+++ b/drivers/video/fbdev/savage/savagefb_driver.c
@@ -2276,7 +2276,10 @@ static int savagefb_probe(struct pci_dev
if (info->var.xres_virtual > 0x1000)
info->var.xres_virtual = 0x1000;
#endif
- savagefb_check_var(&info->var, info);
+ err = savagefb_check_var(&info->var, info);
+ if (err)
+ goto failed;
+
savagefb_set_fix(info);
/*
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 052/157] firmware: qcom_scm: disable clocks if qcom_scm_bw_enable() fails
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (50 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 051/157] fbdev: savage: Handle err return when savagefb_check_var failed Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 053/157] drm/amdgpu/atomfirmware: add intergrated info v2.3 table Greg Kroah-Hartman
` (114 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Gabor Juhos, Mukesh Ojha,
Bjorn Andersson
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gabor Juhos <j4g8y7@gmail.com>
commit 0c50b7fcf2773b4853e83fc15aba1a196ba95966 upstream.
There are several functions which are calling qcom_scm_bw_enable()
then returns immediately if the call fails and leaves the clocks
enabled.
Change the code of these functions to disable clocks when the
qcom_scm_bw_enable() call fails. This also fixes a possible dma
buffer leak in the qcom_scm_pas_init_image() function.
Compile tested only due to lack of hardware with interconnect
support.
Cc: stable@vger.kernel.org
Fixes: 65b7ebda5028 ("firmware: qcom_scm: Add bw voting support to the SCM interface")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com>
Link: https://lore.kernel.org/r/20240304-qcom-scm-disable-clk-v1-1-b36e51577ca1@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firmware/qcom/qcom_scm.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -569,13 +569,14 @@ int qcom_scm_pas_init_image(u32 peripher
ret = qcom_scm_bw_enable();
if (ret)
- return ret;
+ goto disable_clk;
desc.args[1] = mdata_phys;
ret = qcom_scm_call(__scm->dev, &desc, &res);
-
qcom_scm_bw_disable();
+
+disable_clk:
qcom_scm_clk_disable();
out:
@@ -637,10 +638,12 @@ int qcom_scm_pas_mem_setup(u32 periphera
ret = qcom_scm_bw_enable();
if (ret)
- return ret;
+ goto disable_clk;
ret = qcom_scm_call(__scm->dev, &desc, &res);
qcom_scm_bw_disable();
+
+disable_clk:
qcom_scm_clk_disable();
return ret ? : res.result[0];
@@ -672,10 +675,12 @@ int qcom_scm_pas_auth_and_reset(u32 peri
ret = qcom_scm_bw_enable();
if (ret)
- return ret;
+ goto disable_clk;
ret = qcom_scm_call(__scm->dev, &desc, &res);
qcom_scm_bw_disable();
+
+disable_clk:
qcom_scm_clk_disable();
return ret ? : res.result[0];
@@ -706,11 +711,12 @@ int qcom_scm_pas_shutdown(u32 peripheral
ret = qcom_scm_bw_enable();
if (ret)
- return ret;
+ goto disable_clk;
ret = qcom_scm_call(__scm->dev, &desc, &res);
-
qcom_scm_bw_disable();
+
+disable_clk:
qcom_scm_clk_disable();
return ret ? : res.result[0];
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 053/157] drm/amdgpu/atomfirmware: add intergrated info v2.3 table
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (51 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 052/157] firmware: qcom_scm: disable clocks if qcom_scm_bw_enable() fails Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:32 ` [PATCH 6.9 054/157] 9p: add missing locking around taking dentry fid list Greg Kroah-Hartman
` (113 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Li Ma, Yifan Zhang, Alex Deucher
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Li Ma <li.ma@amd.com>
commit e64e8f7c178e5228e0b2dbb504b9dc75953a319f upstream.
[Why]
The vram width value is 0.
Because the integratedsysteminfo table in VBIOS has updated to 2.3.
[How]
Driver needs a new intergrated info v2.3 table too.
Then the vram width value will be correct.
Signed-off-by: Li Ma <li.ma@amd.com>
Reviewed-by: Yifan Zhang <yifan1.zhang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 15 ++++++++
drivers/gpu/drm/amd/include/atomfirmware.h | 43 +++++++++++++++++++++++
2 files changed, 58 insertions(+)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
@@ -211,6 +211,7 @@ union igp_info {
struct atom_integrated_system_info_v1_11 v11;
struct atom_integrated_system_info_v1_12 v12;
struct atom_integrated_system_info_v2_1 v21;
+ struct atom_integrated_system_info_v2_3 v23;
};
union umc_info {
@@ -353,6 +354,20 @@ amdgpu_atomfirmware_get_vram_info(struct
if (mem_type == LpDdr5MemType)
mem_channel_width = 32;
else
+ mem_channel_width = 64;
+ if (vram_width)
+ *vram_width = mem_channel_number * mem_channel_width;
+ if (vram_type)
+ *vram_type = convert_atom_mem_type_to_vram_type(adev, mem_type);
+ break;
+ case 3:
+ mem_channel_number = igp_info->v23.umachannelnumber;
+ if (!mem_channel_number)
+ mem_channel_number = 1;
+ mem_type = igp_info->v23.memorytype;
+ if (mem_type == LpDdr5MemType)
+ mem_channel_width = 32;
+ else
mem_channel_width = 64;
if (vram_width)
*vram_width = mem_channel_number * mem_channel_width;
--- a/drivers/gpu/drm/amd/include/atomfirmware.h
+++ b/drivers/gpu/drm/amd/include/atomfirmware.h
@@ -1657,6 +1657,49 @@ struct atom_integrated_system_info_v2_2
uint32_t reserved4[189];
};
+struct uma_carveout_option {
+ char optionName[29]; //max length of string is 28chars + '\0'. Current design is for "minimum", "Medium", "High". This makes entire struct size 64bits
+ uint8_t memoryCarvedGb; //memory carved out with setting
+ uint8_t memoryRemainingGb; //memory remaining on system
+ union {
+ struct _flags {
+ uint8_t Auto : 1;
+ uint8_t Custom : 1;
+ uint8_t Reserved : 6;
+ } flags;
+ uint8_t all8;
+ } uma_carveout_option_flags;
+};
+
+struct atom_integrated_system_info_v2_3 {
+ struct atom_common_table_header table_header;
+ uint32_t vbios_misc; // enum of atom_system_vbiosmisc_def
+ uint32_t gpucapinfo; // enum of atom_system_gpucapinf_def
+ uint32_t system_config;
+ uint32_t cpucapinfo;
+ uint16_t gpuclk_ss_percentage; // unit of 0.001%, 1000 mean 1%
+ uint16_t gpuclk_ss_type;
+ uint16_t dpphy_override; // bit vector, enum of atom_sysinfo_dpphy_override_def
+ uint8_t memorytype; // enum of atom_dmi_t17_mem_type_def, APU memory type indication.
+ uint8_t umachannelnumber; // number of memory channels
+ uint8_t htc_hyst_limit;
+ uint8_t htc_tmp_limit;
+ uint8_t reserved1; // dp_ss_control
+ uint8_t gpu_package_id;
+ struct edp_info_table edp1_info;
+ struct edp_info_table edp2_info;
+ uint32_t reserved2[8];
+ struct atom_external_display_connection_info extdispconninfo;
+ uint8_t UMACarveoutVersion;
+ uint8_t UMACarveoutIndexMax;
+ uint8_t UMACarveoutTypeDefault;
+ uint8_t UMACarveoutIndexDefault;
+ uint8_t UMACarveoutType; //Auto or Custom
+ uint8_t UMACarveoutIndex;
+ struct uma_carveout_option UMASizeControlOption[20];
+ uint8_t reserved3[110];
+};
+
// system_config
enum atom_system_vbiosmisc_def{
INTEGRATED_SYSTEM_INFO__GET_EDID_CALLBACK_FUNC_SUPPORT = 0x01,
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 054/157] 9p: add missing locking around taking dentry fid list
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (52 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 053/157] drm/amdgpu/atomfirmware: add intergrated info v2.3 table Greg Kroah-Hartman
@ 2024-06-13 11:32 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 055/157] drm/amd: Fix shutdown (again) on some SMU v13.0.4/11 platforms Greg Kroah-Hartman
` (112 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:32 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Christian Schoenebeck,
Dominique Martinet
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dominique Martinet <asmadeus@codewreck.org>
commit c898afdc15645efb555acb6d85b484eb40a45409 upstream.
Fix a use-after-free on dentry's d_fsdata fid list when a thread
looks up a fid through dentry while another thread unlinks it:
UAF thread:
refcount_t: addition on 0; use-after-free.
p9_fid_get linux/./include/net/9p/client.h:262
v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129
v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181
v9fs_fid_lookup+0xbf/0xc20 linux/fs/9p/fid.c:314
v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400
vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248
Freed by:
p9_fid_destroy (inlined)
p9_client_clunk+0xb0/0xe0 linux/net/9p/client.c:1456
p9_fid_put linux/./include/net/9p/client.h:278
v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55
v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518
vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335
The problem is that d_fsdata was not accessed under d_lock, because
d_release() normally is only called once the dentry is otherwise no
longer accessible but since we also call it explicitly in v9fs_remove
that lock is required:
move the hlist out of the dentry under lock then unref its fids once
they are no longer accessible.
Fixes: 154372e67d40 ("fs/9p: fix create-unlink-getattr idiom")
Cc: stable@vger.kernel.org
Reported-by: Meysam Firouzi
Reported-by: Amirmohammad Eftekhar
Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
Message-ID: <20240521122947.1080227-1-asmadeus@codewreck.org>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/9p/vfs_dentry.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/fs/9p/vfs_dentry.c
+++ b/fs/9p/vfs_dentry.c
@@ -48,12 +48,17 @@ static int v9fs_cached_dentry_delete(con
static void v9fs_dentry_release(struct dentry *dentry)
{
struct hlist_node *p, *n;
+ struct hlist_head head;
p9_debug(P9_DEBUG_VFS, " dentry: %pd (%p)\n",
dentry, dentry);
- hlist_for_each_safe(p, n, (struct hlist_head *)&dentry->d_fsdata)
+
+ spin_lock(&dentry->d_lock);
+ hlist_move_list((struct hlist_head *)&dentry->d_fsdata, &head);
+ spin_unlock(&dentry->d_lock);
+
+ hlist_for_each_safe(p, n, &head)
p9_fid_put(hlist_entry(p, struct p9_fid, dlist));
- dentry->d_fsdata = NULL;
}
static int v9fs_lookup_revalidate(struct dentry *dentry, unsigned int flags)
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 055/157] drm/amd: Fix shutdown (again) on some SMU v13.0.4/11 platforms
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (53 preceding siblings ...)
2024-06-13 11:32 ` [PATCH 6.9 054/157] 9p: add missing locking around taking dentry fid list Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 056/157] Revert "drm/amdkfd: fix gfx_target_version for certain 11.0.3 devices" Greg Kroah-Hartman
` (111 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Tim Huang, Mario Limonciello,
Alex Deucher, lectrode
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mario Limonciello <mario.limonciello@amd.com>
commit 267cace556e8a53d703119f7435ab556209e5b6a upstream.
commit cd94d1b182d2 ("dm/amd/pm: Fix problems with reboot/shutdown for
some SMU 13.0.4/13.0.11 users") attempted to fix shutdown issues
that were reported since commit 31729e8c21ec ("drm/amd/pm: fixes a
random hang in S4 for SMU v13.0.4/11") but caused issues for some
people.
Adjust the workaround flow to properly only apply in the S4 case:
-> For shutdown go through SMU_MSG_PrepareMp1ForUnload
-> For S4 go through SMU_MSG_GfxDeviceDriverReset and
SMU_MSG_PrepareMp1ForUnload
Reported-and-tested-by: lectrode <electrodexsnet@gmail.com>
Closes: https://github.com/void-linux/void-packages/issues/50417
Cc: stable@vger.kernel.org
Fixes: cd94d1b182d2 ("dm/amd/pm: Fix problems with reboot/shutdown for some SMU 13.0.4/13.0.11 users")
Reviewed-by: Tim Huang <Tim.Huang@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c | 20 ++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c
@@ -226,15 +226,17 @@ static int smu_v13_0_4_system_features_c
struct amdgpu_device *adev = smu->adev;
int ret = 0;
- if (!en && adev->in_s4) {
- /* Adds a GFX reset as workaround just before sending the
- * MP1_UNLOAD message to prevent GC/RLC/PMFW from entering
- * an invalid state.
- */
- ret = smu_cmn_send_smc_msg_with_param(smu, SMU_MSG_GfxDeviceDriverReset,
- SMU_RESET_MODE_2, NULL);
- if (ret)
- return ret;
+ if (!en && !adev->in_s0ix) {
+ if (adev->in_s4) {
+ /* Adds a GFX reset as workaround just before sending the
+ * MP1_UNLOAD message to prevent GC/RLC/PMFW from entering
+ * an invalid state.
+ */
+ ret = smu_cmn_send_smc_msg_with_param(smu, SMU_MSG_GfxDeviceDriverReset,
+ SMU_RESET_MODE_2, NULL);
+ if (ret)
+ return ret;
+ }
ret = smu_cmn_send_smc_msg(smu, SMU_MSG_PrepareMp1ForUnload, NULL);
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 056/157] Revert "drm/amdkfd: fix gfx_target_version for certain 11.0.3 devices"
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (54 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 055/157] drm/amd: Fix shutdown (again) on some SMU v13.0.4/11 platforms Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 057/157] KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked Greg Kroah-Hartman
` (110 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Feifei Xu, Alex Deucher, Feifei Xu
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
commit dd2b75fd9a79bf418e088656822af06fc253dbe3 upstream.
This reverts commit 28ebbb4981cb1fad12e0b1227dbecc88810b1ee8.
Revert this commit as apparently the LLVM code to take advantage of
this never landed.
Reviewed-by: Feifei Xu <Feifei.Xu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Feifei Xu <feifei.xu@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -408,15 +408,8 @@ struct kfd_dev *kgd2kfd_probe(struct amd
f2g = &gfx_v11_kfd2kgd;
break;
case IP_VERSION(11, 0, 3):
- if ((adev->pdev->device == 0x7460 &&
- adev->pdev->revision == 0x00) ||
- (adev->pdev->device == 0x7461 &&
- adev->pdev->revision == 0x00))
- /* Note: Compiler version is 11.0.5 while HW version is 11.0.3 */
- gfx_target_version = 110005;
- else
- /* Note: Compiler version is 11.0.1 while HW version is 11.0.3 */
- gfx_target_version = 110001;
+ /* Note: Compiler version is 11.0.1 while HW version is 11.0.3 */
+ gfx_target_version = 110001;
f2g = &gfx_v11_kfd2kgd;
break;
case IP_VERSION(11, 5, 0):
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 057/157] KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (55 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 056/157] Revert "drm/amdkfd: fix gfx_target_version for certain 11.0.3 devices" Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 058/157] KVM: arm64: Fix AArch32 register narrowing on userspace write Greg Kroah-Hartman
` (109 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Santosh Shukla, Maxim Levitsky,
Sean Christopherson, Paolo Bonzini
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Christopherson <seanjc@google.com>
commit b4bd556467477420ee3a91fbcba73c579669edc6 upstream.
When requesting an NMI window, WARN on vNMI support being enabled if and
only if NMIs are actually masked, i.e. if the vCPU is already handling an
NMI. KVM's ABI for NMIs that arrive simultanesouly (from KVM's point of
view) is to inject one NMI and pend the other. When using vNMI, KVM pends
the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the
rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected).
However, if KVM can't immediately inject an NMI, e.g. because the vCPU is
in an STI shadow or is running with GIF=0, then KVM will request an NMI
window and trigger the WARN (but still function correctly).
Whether or not the GIF=0 case makes sense is debatable, as the intent of
KVM's behavior is to provide functionality that is as close to real
hardware as possible. E.g. if two NMIs are sent in quick succession, the
probability of both NMIs arriving in an STI shadow is infinitesimally low
on real hardware, but significantly larger in a virtual environment, e.g.
if the vCPU is preempted in the STI shadow. For GIF=0, the argument isn't
as clear cut, because the window where two NMIs can collide is much larger
in bare metal (though still small).
That said, KVM should not have divergent behavior for the GIF=0 case based
on whether or not vNMI support is enabled. And KVM has allowed
simultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400
("KVM: Fix simultaneous NMIs"). I.e. KVM's GIF=0 handling shouldn't be
modified without a *really* good reason to do so, and if KVM's behavior
were to be modified, it should be done irrespective of vNMI support.
Fixes: fa4c027a7956 ("KVM: x86: Add support for SVM's Virtual NMI")
Cc: stable@vger.kernel.org
Cc: Santosh Shukla <Santosh.Shukla@amd.com>
Cc: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20240522021435.1684366-1-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/svm/svm.c | 27 +++++++++++++++++++--------
1 file changed, 19 insertions(+), 8 deletions(-)
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -3843,16 +3843,27 @@ static void svm_enable_nmi_window(struct
struct vcpu_svm *svm = to_svm(vcpu);
/*
- * KVM should never request an NMI window when vNMI is enabled, as KVM
- * allows at most one to-be-injected NMI and one pending NMI, i.e. if
- * two NMIs arrive simultaneously, KVM will inject one and set
- * V_NMI_PENDING for the other. WARN, but continue with the standard
- * single-step approach to try and salvage the pending NMI.
+ * If NMIs are outright masked, i.e. the vCPU is already handling an
+ * NMI, and KVM has not yet intercepted an IRET, then there is nothing
+ * more to do at this time as KVM has already enabled IRET intercepts.
+ * If KVM has already intercepted IRET, then single-step over the IRET,
+ * as NMIs aren't architecturally unmasked until the IRET completes.
+ *
+ * If vNMI is enabled, KVM should never request an NMI window if NMIs
+ * are masked, as KVM allows at most one to-be-injected NMI and one
+ * pending NMI. If two NMIs arrive simultaneously, KVM will inject one
+ * NMI and set V_NMI_PENDING for the other, but if and only if NMIs are
+ * unmasked. KVM _will_ request an NMI window in some situations, e.g.
+ * if the vCPU is in an STI shadow or if GIF=0, KVM can't immediately
+ * inject the NMI. In those situations, KVM needs to single-step over
+ * the STI shadow or intercept STGI.
*/
- WARN_ON_ONCE(is_vnmi_enabled(svm));
+ if (svm_get_nmi_mask(vcpu)) {
+ WARN_ON_ONCE(is_vnmi_enabled(svm));
- if (svm_get_nmi_mask(vcpu) && !svm->awaiting_iret_completion)
- return; /* IRET will cause a vm exit */
+ if (!svm->awaiting_iret_completion)
+ return; /* IRET will cause a vm exit */
+ }
/*
* SEV-ES guests are responsible for signaling when a vCPU is ready to
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 058/157] KVM: arm64: Fix AArch32 register narrowing on userspace write
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (56 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 057/157] KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 059/157] KVM: arm64: Allow AArch32 PSTATE.M to be restored as System mode Greg Kroah-Hartman
` (108 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Nina Schoetterl-Glausch,
Oliver Upton, Marc Zyngier
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Zyngier <maz@kernel.org>
commit 947051e361d551e0590777080ffc4926190f62f2 upstream.
When userspace writes to one of the core registers, we make
sure to narrow the corresponding GPRs if PSTATE indicates
an AArch32 context.
The code tries to check whether the context is EL0 or EL1 so
that it narrows the correct registers. But it does so by checking
the full PSTATE instead of PSTATE.M.
As a consequence, and if we are restoring an AArch32 EL0 context
in a 64bit guest, and that PSTATE has *any* bit set outside of
PSTATE.M, we narrow *all* registers instead of only the first 15,
destroying the 64bit state.
Obviously, this is not something the guest is likely to enjoy.
Correctly masking PSTATE to only evaluate PSTATE.M fixes it.
Fixes: 90c1f934ed71 ("KVM: arm64: Get rid of the AArch32 register mapping code")
Reported-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
Cc: stable@vger.kernel.org
Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
Acked-by: Oliver Upton <oliver.upton@linux.dev>
Link: https://lore.kernel.org/r/20240524141956.1450304-2-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/kvm/guest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -276,7 +276,7 @@ static int set_core_reg(struct kvm_vcpu
if (*vcpu_cpsr(vcpu) & PSR_MODE32_BIT) {
int i, nr_reg;
- switch (*vcpu_cpsr(vcpu)) {
+ switch (*vcpu_cpsr(vcpu) & PSR_AA32_MODE_MASK) {
/*
* Either we are dealing with user mode, and only the
* first 15 registers (+ PC) must be narrowed to 32bit.
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 059/157] KVM: arm64: Allow AArch32 PSTATE.M to be restored as System mode
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (57 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 058/157] KVM: arm64: Fix AArch32 register narrowing on userspace write Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 060/157] KVM: arm64: AArch32: Fix spurious trapping of conditional instructions Greg Kroah-Hartman
` (107 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Oliver Upton, Marc Zyngier
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Zyngier <maz@kernel.org>
commit dfe6d190f38fc5df5ff2614b463a5195a399c885 upstream.
It appears that we don't allow a vcpu to be restored in AArch32
System mode, as we *never* included it in the list of valid modes.
Just add it to the list of allowed modes.
Fixes: 0d854a60b1d7 ("arm64: KVM: enable initialization of a 32bit vcpu")
Cc: stable@vger.kernel.org
Acked-by: Oliver Upton <oliver.upton@linux.dev>
Link: https://lore.kernel.org/r/20240524141956.1450304-3-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/kvm/guest.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -251,6 +251,7 @@ static int set_core_reg(struct kvm_vcpu
case PSR_AA32_MODE_SVC:
case PSR_AA32_MODE_ABT:
case PSR_AA32_MODE_UND:
+ case PSR_AA32_MODE_SYS:
if (!vcpu_el1_is_32bit(vcpu))
return -EINVAL;
break;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 060/157] KVM: arm64: AArch32: Fix spurious trapping of conditional instructions
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (58 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 059/157] KVM: arm64: Allow AArch32 PSTATE.M to be restored as System mode Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 061/157] LoongArch: Add all CPUs enabled by fdt to NUMA node 0 Greg Kroah-Hartman
` (106 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Oliver Upton, Marc Zyngier
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Zyngier <maz@kernel.org>
commit c92e8b9eacebb4060634ebd9395bba1b29aadc68 upstream.
We recently upgraded the view of ESR_EL2 to 64bit, in keeping with
the requirements of the architecture.
However, the AArch32 emulation code was left unaudited, and the
(already dodgy) code that triages whether a trap is spurious or not
(because the condition code failed) broke in a subtle way:
If ESR_EL2.ISS2 is ever non-zero (unlikely, but hey, this is the ARM
architecture we're talking about), the hack that tests the top bits
of ESR_EL2.EC will break in an interesting way.
Instead, use kvm_vcpu_trap_get_class() to obtain the EC, and list
all the possible ECs that can fail a condition code check.
While we're at it, add SMC32 to the list, as it is explicitly listed
as being allowed to trap despite failing a condition code check (as
described in the HCR_EL2.TSC documentation).
Fixes: 0b12620fddb8 ("KVM: arm64: Treat ESR_EL2 as a 64-bit register")
Cc: stable@vger.kernel.org
Acked-by: Oliver Upton <oliver.upton@linux.dev>
Link: https://lore.kernel.org/r/20240524141956.1450304-4-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/kvm/hyp/aarch32.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
--- a/arch/arm64/kvm/hyp/aarch32.c
+++ b/arch/arm64/kvm/hyp/aarch32.c
@@ -50,9 +50,23 @@ bool kvm_condition_valid32(const struct
u32 cpsr_cond;
int cond;
- /* Top two bits non-zero? Unconditional. */
- if (kvm_vcpu_get_esr(vcpu) >> 30)
+ /*
+ * These are the exception classes that could fire with a
+ * conditional instruction.
+ */
+ switch (kvm_vcpu_trap_get_class(vcpu)) {
+ case ESR_ELx_EC_CP15_32:
+ case ESR_ELx_EC_CP15_64:
+ case ESR_ELx_EC_CP14_MR:
+ case ESR_ELx_EC_CP14_LS:
+ case ESR_ELx_EC_FP_ASIMD:
+ case ESR_ELx_EC_CP10_ID:
+ case ESR_ELx_EC_CP14_64:
+ case ESR_ELx_EC_SVC32:
+ break;
+ default:
return true;
+ }
/* Is condition field valid? */
cond = kvm_vcpu_get_condition(vcpu);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 061/157] LoongArch: Add all CPUs enabled by fdt to NUMA node 0
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (59 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 060/157] KVM: arm64: AArch32: Fix spurious trapping of conditional instructions Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 062/157] LoongArch: Fix built-in DTB detection Greg Kroah-Hartman
` (105 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Jiaxun Yang, Huacai Chen
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiaxun Yang <jiaxun.yang@flygoat.com>
commit 3de9c42d02a79a5e09bbee7a4421ddc00cfd5c6d upstream.
NUMA enabled kernel on FDT based machine fails to boot because CPUs
are all in NUMA_NO_NODE and mm subsystem won't accept that.
Fix by adding them to default NUMA node at FDT parsing phase and move
numa_add_cpu(0) to a later point.
Cc: stable@vger.kernel.org
Fixes: 88d4d957edc7 ("LoongArch: Add FDT booting support from efi system table")
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/loongarch/include/asm/numa.h | 1 +
arch/loongarch/kernel/smp.c | 5 ++++-
2 files changed, 5 insertions(+), 1 deletion(-)
--- a/arch/loongarch/include/asm/numa.h
+++ b/arch/loongarch/include/asm/numa.h
@@ -56,6 +56,7 @@ extern int early_cpu_to_node(int cpu);
static inline void early_numa_add_cpu(int cpuid, s16 node) { }
static inline void numa_add_cpu(unsigned int cpu) { }
static inline void numa_remove_cpu(unsigned int cpu) { }
+static inline void set_cpuid_to_node(int cpuid, s16 node) { }
static inline int early_cpu_to_node(int cpu)
{
--- a/arch/loongarch/kernel/smp.c
+++ b/arch/loongarch/kernel/smp.c
@@ -262,7 +262,6 @@ static void __init fdt_smp_setup(void)
if (cpuid == loongson_sysconf.boot_cpu_id) {
cpu = 0;
- numa_add_cpu(cpu);
} else {
cpu = cpumask_next_zero(-1, cpu_present_mask);
}
@@ -272,6 +271,9 @@ static void __init fdt_smp_setup(void)
set_cpu_present(cpu, true);
__cpu_number_map[cpuid] = cpu;
__cpu_logical_map[cpu] = cpuid;
+
+ early_numa_add_cpu(cpu, 0);
+ set_cpuid_to_node(cpuid, 0);
}
loongson_sysconf.nr_cpus = num_processors;
@@ -456,6 +458,7 @@ void smp_prepare_boot_cpu(void)
set_cpu_possible(0, true);
set_cpu_online(0, true);
set_my_cpu_offset(per_cpu_offset(0));
+ numa_add_cpu(0);
rr_node = first_node(node_online_map);
for_each_possible_cpu(cpu) {
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 062/157] LoongArch: Fix built-in DTB detection
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (60 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 061/157] LoongArch: Add all CPUs enabled by fdt to NUMA node 0 Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 063/157] LoongArch: Override higher address bits in JUMP_VIRT_ADDR Greg Kroah-Hartman
` (104 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Jiaxun Yang, Huacai Chen
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiaxun Yang <jiaxun.yang@flygoat.com>
commit b56f67a6c748bb009f313f91651c8020d2338d63 upstream.
fdt_check_header(__dtb_start) will always success because kernel
provides a dummy dtb, and by coincidence __dtb_start clashed with
entry of this dummy dtb. The consequence is fdt passed from firmware
will never be taken.
Fix by trying to utilise __dtb_start only when CONFIG_BUILTIN_DTB is
enabled.
Cc: stable@vger.kernel.org
Fixes: 7b937cc243e5 ("of: Create of_root if no dtb provided by firmware")
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/loongarch/kernel/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/loongarch/kernel/setup.c b/arch/loongarch/kernel/setup.c
index 89ad756aeeed..3d048f1be143 100644
--- a/arch/loongarch/kernel/setup.c
+++ b/arch/loongarch/kernel/setup.c
@@ -282,7 +282,7 @@ static void __init fdt_setup(void)
return;
/* Prefer to use built-in dtb, checking its legality first. */
- if (!fdt_check_header(__dtb_start))
+ if (IS_ENABLED(CONFIG_BUILTIN_DTB) && !fdt_check_header(__dtb_start))
fdt_pointer = __dtb_start;
else
fdt_pointer = efi_fdt_pointer(); /* Fallback to firmware dtb */
--
2.45.2
^ permalink raw reply related [flat|nested] 168+ messages in thread* [PATCH 6.9 063/157] LoongArch: Override higher address bits in JUMP_VIRT_ADDR
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (61 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 062/157] LoongArch: Fix built-in DTB detection Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 064/157] LoongArch: Fix entry point in kernel image header Greg Kroah-Hartman
` (103 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Jiaxun Yang, Huacai Chen
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiaxun Yang <jiaxun.yang@flygoat.com>
commit 1098efd299ffe9c8af818425338c7f6c4f930a98 upstream.
In JUMP_VIRT_ADDR we are performing an or calculation on address value
directly from pcaddi.
This will only work if we are currently running from direct 1:1 mapping
addresses or firmware's DMW is configured exactly same as kernel. Still,
we should not rely on such assumption.
Fix by overriding higher bits in address comes from pcaddi, so we can
get rid of or operator.
Cc: stable@vger.kernel.org
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/loongarch/include/asm/stackframe.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/loongarch/include/asm/stackframe.h
+++ b/arch/loongarch/include/asm/stackframe.h
@@ -42,7 +42,7 @@
.macro JUMP_VIRT_ADDR temp1 temp2
li.d \temp1, CACHE_BASE
pcaddi \temp2, 0
- or \temp1, \temp1, \temp2
+ bstrins.d \temp1, \temp2, (DMW_PABITS - 1), 0
jirl zero, \temp1, 0xc
.endm
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 064/157] LoongArch: Fix entry point in kernel image header
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (62 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 063/157] LoongArch: Override higher address bits in JUMP_VIRT_ADDR Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 065/157] clk: bcm: dvp: Assign ->num before accessing ->hws Greg Kroah-Hartman
` (102 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Jiaxun Yang, Huacai Chen
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiaxun Yang <jiaxun.yang@flygoat.com>
commit beb2800074c15362cf9f6c7301120910046d6556 upstream.
Currently kernel entry in head.S is in DMW address range, firmware is
instructed to jump to this address after loading the kernel image.
However kernel should not make any assumption on firmware's DMW
setting, thus the entry point should be a physical address falls into
direct translation region.
Fix by converting entry address to physical and amend entry calculation
logic in libstub accordingly.
BTW, use ABSOLUTE() to calculate variables to make Clang/LLVM happy.
Cc: stable@vger.kernel.org
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/loongarch/kernel/head.S | 2 +-
arch/loongarch/kernel/vmlinux.lds.S | 10 ++++++----
drivers/firmware/efi/libstub/loongarch.c | 2 +-
3 files changed, 8 insertions(+), 6 deletions(-)
--- a/arch/loongarch/kernel/head.S
+++ b/arch/loongarch/kernel/head.S
@@ -22,7 +22,7 @@
_head:
.word MZ_MAGIC /* "MZ", MS-DOS header */
.org 0x8
- .dword kernel_entry /* Kernel entry point */
+ .dword _kernel_entry /* Kernel entry point (physical address) */
.dword _kernel_asize /* Kernel image effective size */
.quad PHYS_LINK_KADDR /* Kernel image load offset from start of RAM */
.org 0x38 /* 0x20 ~ 0x37 reserved */
--- a/arch/loongarch/kernel/vmlinux.lds.S
+++ b/arch/loongarch/kernel/vmlinux.lds.S
@@ -6,6 +6,7 @@
#define PAGE_SIZE _PAGE_SIZE
#define RO_EXCEPTION_TABLE_ALIGN 4
+#define PHYSADDR_MASK 0xffffffffffff /* 48-bit */
/*
* Put .bss..swapper_pg_dir as the first thing in .bss. This will
@@ -142,10 +143,11 @@ SECTIONS
#ifdef CONFIG_EFI_STUB
/* header symbols */
- _kernel_asize = _end - _text;
- _kernel_fsize = _edata - _text;
- _kernel_vsize = _end - __initdata_begin;
- _kernel_rsize = _edata - __initdata_begin;
+ _kernel_entry = ABSOLUTE(kernel_entry & PHYSADDR_MASK);
+ _kernel_asize = ABSOLUTE(_end - _text);
+ _kernel_fsize = ABSOLUTE(_edata - _text);
+ _kernel_vsize = ABSOLUTE(_end - __initdata_begin);
+ _kernel_rsize = ABSOLUTE(_edata - __initdata_begin);
#endif
.gptab.sdata : {
--- a/drivers/firmware/efi/libstub/loongarch.c
+++ b/drivers/firmware/efi/libstub/loongarch.c
@@ -41,7 +41,7 @@ static efi_status_t exit_boot_func(struc
unsigned long __weak kernel_entry_address(unsigned long kernel_addr,
efi_loaded_image_t *image)
{
- return *(unsigned long *)(kernel_addr + 8) - VMLINUX_LOAD_ADDRESS + kernel_addr;
+ return *(unsigned long *)(kernel_addr + 8) - PHYSADDR(VMLINUX_LOAD_ADDRESS) + kernel_addr;
}
efi_status_t efi_boot_kernel(void *handle, efi_loaded_image_t *image,
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 065/157] clk: bcm: dvp: Assign ->num before accessing ->hws
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (63 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 064/157] LoongArch: Fix entry point in kernel image header Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 066/157] clk: bcm: rpi: " Greg Kroah-Hartman
` (101 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Nathan Chancellor, Kees Cook,
Florian Fainelli, Stephen Boyd
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Chancellor <nathan@kernel.org>
commit 9368cdf90f52a68120d039887ccff74ff33b4444 upstream.
Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with
__counted_by") annotated the hws member of 'struct clk_hw_onecell_data'
with __counted_by, which informs the bounds sanitizer about the number
of elements in hws, so that it can warn when hws is accessed out of
bounds. As noted in that change, the __counted_by member must be
initialized with the number of elements before the first array access
happens, otherwise there will be a warning from each access prior to the
initialization because the number of elements is zero. This occurs in
clk_dvp_probe() due to ->num being assigned after ->hws has been
accessed:
UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-bcm2711-dvp.c:59:2
index 0 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]')
Move the ->num initialization to before the first access of ->hws, which
clears up the warning.
Cc: stable@vger.kernel.org
Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20240425-cbl-bcm-assign-counted-by-val-before-access-v1-1-e2db3b82d5ef@kernel.org
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/clk/bcm/clk-bcm2711-dvp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/clk/bcm/clk-bcm2711-dvp.c
+++ b/drivers/clk/bcm/clk-bcm2711-dvp.c
@@ -56,6 +56,8 @@ static int clk_dvp_probe(struct platform
if (ret)
return ret;
+ data->num = NR_CLOCKS;
+
data->hws[0] = clk_hw_register_gate_parent_data(&pdev->dev,
"hdmi0-108MHz",
&clk_dvp_parent, 0,
@@ -76,7 +78,6 @@ static int clk_dvp_probe(struct platform
goto unregister_clk0;
}
- data->num = NR_CLOCKS;
ret = of_clk_add_hw_provider(pdev->dev.of_node, of_clk_hw_onecell_get,
data);
if (ret)
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 066/157] clk: bcm: rpi: Assign ->num before accessing ->hws
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (64 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 065/157] clk: bcm: dvp: Assign ->num before accessing ->hws Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 067/157] clk: qcom: clk-alpha-pll: fix rate setting for Stromer PLLs Greg Kroah-Hartman
` (100 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Nathan Chancellor, Kees Cook,
Florian Fainelli, Stephen Boyd
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Chancellor <nathan@kernel.org>
commit 6dc445c1905096b2ed4db1a84570375b4e00cc0f upstream.
Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with
__counted_by") annotated the hws member of 'struct clk_hw_onecell_data'
with __counted_by, which informs the bounds sanitizer about the number
of elements in hws, so that it can warn when hws is accessed out of
bounds. As noted in that change, the __counted_by member must be
initialized with the number of elements before the first array access
happens, otherwise there will be a warning from each access prior to the
initialization because the number of elements is zero. This occurs in
raspberrypi_discover_clocks() due to ->num being assigned after ->hws
has been accessed:
UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-raspberrypi.c:374:4
index 3 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]')
Move the ->num initialization to before the first access of ->hws, which
clears up the warning.
Cc: stable@vger.kernel.org
Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20240425-cbl-bcm-assign-counted-by-val-before-access-v1-2-e2db3b82d5ef@kernel.org
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/clk/bcm/clk-raspberrypi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -371,8 +371,8 @@ static int raspberrypi_discover_clocks(s
if (IS_ERR(hw))
return PTR_ERR(hw);
- data->hws[clks->id] = hw;
data->num = clks->id + 1;
+ data->hws[clks->id] = hw;
}
clks++;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 067/157] clk: qcom: clk-alpha-pll: fix rate setting for Stromer PLLs
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (65 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 066/157] clk: bcm: rpi: " Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 068/157] clk: qcom: apss-ipq-pll: use stromer ops for IPQ5018 to fix boot failure Greg Kroah-Hartman
` (99 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Dmitry Baryshkov, Gabor Juhos,
Bjorn Andersson
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gabor Juhos <j4g8y7@gmail.com>
commit 3c5b3e17b8fd1f1add5a9477306c355fab126977 upstream.
The clk_alpha_pll_stromer_set_rate() function writes inproper
values into the ALPHA_VAL{,_U} registers which results in wrong
clock rates when the alpha value is used.
The broken behaviour can be seen on IPQ5018 for example, when
dynamic scaling sets the CPU frequency to 800000 KHz. In this
case the CPU cores are running only at 792031 KHz:
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
800000
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
792031
This happens because the function ignores the fact that the alpha
value calculated by the alpha_pll_round_rate() function is only
32 bits wide which must be extended to 40 bits if it is used on
a hardware which supports 40 bits wide values.
Extend the clk_alpha_pll_stromer_set_rate() function to convert
the alpha value to 40 bits before wrinting that into the registers
in order to ensure that the hardware really uses the requested rate.
After the change the CPU frequency is correct:
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
800000
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
800000
Cc: stable@vger.kernel.org
Fixes: e47a4f55f240 ("clk: qcom: clk-alpha-pll: Add support for Stromer PLLs")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Link: https://lore.kernel.org/r/20240328-alpha-pll-fix-stromer-set-rate-v3-1-1b79714c78bc@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/clk/qcom/clk-alpha-pll.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -2489,6 +2489,8 @@ static int clk_alpha_pll_stromer_set_rat
rate = alpha_pll_round_rate(rate, prate, &l, &a, ALPHA_REG_BITWIDTH);
regmap_write(pll->clkr.regmap, PLL_L_VAL(pll), l);
+
+ a <<= ALPHA_REG_BITWIDTH - ALPHA_BITWIDTH;
regmap_write(pll->clkr.regmap, PLL_ALPHA_VAL(pll), a);
regmap_write(pll->clkr.regmap, PLL_ALPHA_VAL_U(pll),
a >> ALPHA_BITWIDTH);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 068/157] clk: qcom: apss-ipq-pll: use stromer ops for IPQ5018 to fix boot failure
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (66 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 067/157] clk: qcom: clk-alpha-pll: fix rate setting for Stromer PLLs Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 069/157] crypto: ecdsa - Fix module auto-load on add-key Greg Kroah-Hartman
` (98 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Gabor Juhos, Kathiravan Thirumoorthy,
Bjorn Andersson
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gabor Juhos <j4g8y7@gmail.com>
commit 5fce38e2a1a97900989d9fedebcf5a4dacdaee30 upstream.
Booting v6.8 results in a hang on various IPQ5018 based boards.
Investigating the problem showed that the hang happens when the
clk_alpha_pll_stromer_plus_set_rate() function tries to write
into the PLL_MODE register of the APSS PLL.
Checking the downstream code revealed that it uses [1] stromer
specific operations for IPQ5018, whereas in the current code
the stromer plus specific operations are used.
The ops in the 'ipq_pll_stromer_plus' clock definition can't be
changed since that is needed for IPQ5332, so add a new alpha pll
clock declaration which uses the correct stromer ops and use this
new clock for IPQ5018 to avoid the boot failure.
Also, change pll_type in 'ipq5018_pll_data' to
CLK_ALPHA_PLL_TYPE_STROMER to better reflect that it is a Stromer
PLL and change the apss_ipq_pll_probe() function accordingly.
1. https://git.codelinaro.org/clo/qsdk/oss/kernel/linux-ipq-5.4/-/blob/NHSS.QSDK.12.4/drivers/clk/qcom/apss-ipq5018.c#L67
Cc: stable@vger.kernel.org
Fixes: 50492f929486 ("clk: qcom: apss-ipq-pll: add support for IPQ5018")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Tested-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
Reviewed-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
Link: https://lore.kernel.org/r/20240315-apss-ipq-pll-ipq5018-hang-v2-1-6fe30ada2009@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/clk/qcom/apss-ipq-pll.c | 30 +++++++++++++++++++++++++++---
1 file changed, 27 insertions(+), 3 deletions(-)
--- a/drivers/clk/qcom/apss-ipq-pll.c
+++ b/drivers/clk/qcom/apss-ipq-pll.c
@@ -55,6 +55,29 @@ static struct clk_alpha_pll ipq_pll_huay
},
};
+static struct clk_alpha_pll ipq_pll_stromer = {
+ .offset = 0x0,
+ /*
+ * Reuse CLK_ALPHA_PLL_TYPE_STROMER_PLUS register offsets.
+ * Although this is a bit confusing, but the offset values
+ * are correct nevertheless.
+ */
+ .regs = ipq_pll_offsets[CLK_ALPHA_PLL_TYPE_STROMER_PLUS],
+ .flags = SUPPORTS_DYNAMIC_UPDATE,
+ .clkr = {
+ .enable_reg = 0x0,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data) {
+ .name = "a53pll",
+ .parent_data = &(const struct clk_parent_data) {
+ .fw_name = "xo",
+ },
+ .num_parents = 1,
+ .ops = &clk_alpha_pll_stromer_ops,
+ },
+ },
+};
+
static struct clk_alpha_pll ipq_pll_stromer_plus = {
.offset = 0x0,
.regs = ipq_pll_offsets[CLK_ALPHA_PLL_TYPE_STROMER_PLUS],
@@ -145,8 +168,8 @@ struct apss_pll_data {
};
static const struct apss_pll_data ipq5018_pll_data = {
- .pll_type = CLK_ALPHA_PLL_TYPE_STROMER_PLUS,
- .pll = &ipq_pll_stromer_plus,
+ .pll_type = CLK_ALPHA_PLL_TYPE_STROMER,
+ .pll = &ipq_pll_stromer,
.pll_config = &ipq5018_pll_config,
};
@@ -204,7 +227,8 @@ static int apss_ipq_pll_probe(struct pla
if (data->pll_type == CLK_ALPHA_PLL_TYPE_HUAYRA)
clk_alpha_pll_configure(data->pll, regmap, data->pll_config);
- else if (data->pll_type == CLK_ALPHA_PLL_TYPE_STROMER_PLUS)
+ else if (data->pll_type == CLK_ALPHA_PLL_TYPE_STROMER ||
+ data->pll_type == CLK_ALPHA_PLL_TYPE_STROMER_PLUS)
clk_stromer_pll_configure(data->pll, regmap, data->pll_config);
ret = devm_clk_register_regmap(dev, &data->pll->clkr);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 069/157] crypto: ecdsa - Fix module auto-load on add-key
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (67 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 068/157] clk: qcom: apss-ipq-pll: use stromer ops for IPQ5018 to fix boot failure Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 070/157] crypto: ecrdsa - Fix module auto-load on add_key Greg Kroah-Hartman
` (97 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Stefan Berger, Vitaly Chikunov,
Herbert Xu
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Berger <stefanb@linux.ibm.com>
commit 48e4fd6d54f54d0ceab5a952d73e47a9454a6ccb upstream.
Add module alias with the algorithm cra_name similar to what we have for
RSA-related and other algorithms.
The kernel attempts to modprobe asymmetric algorithms using the names
"crypto-$cra_name" and "crypto-$cra_name-all." However, since these
aliases are currently missing, the modules are not loaded. For instance,
when using the `add_key` function, the hash algorithm is typically
loaded automatically, but the asymmetric algorithm is not.
Steps to test:
1. Create certificate
openssl req -x509 -sha256 -newkey ec \
-pkeyopt "ec_paramgen_curve:secp384r1" -keyout key.pem -days 365 \
-subj '/CN=test' -nodes -outform der -out nist-p384.der
2. Optionally, trace module requests with: trace-cmd stream -e module &
3. Trigger add_key call for the cert:
# keyctl padd asymmetric "" @u < nist-p384.der
641069229
# lsmod | head -2
Module Size Used by
ecdsa_generic 16384 0
Fixes: c12d448ba939 ("crypto: ecdsa - Register NIST P384 and extend test suite")
Cc: stable@vger.kernel.org
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Vitaly Chikunov <vt@altlinux.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
crypto/ecdsa.c | 3 +++
1 file changed, 3 insertions(+)
--- a/crypto/ecdsa.c
+++ b/crypto/ecdsa.c
@@ -373,4 +373,7 @@ module_exit(ecdsa_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Stefan Berger <stefanb@linux.ibm.com>");
MODULE_DESCRIPTION("ECDSA generic algorithm");
+MODULE_ALIAS_CRYPTO("ecdsa-nist-p192");
+MODULE_ALIAS_CRYPTO("ecdsa-nist-p256");
+MODULE_ALIAS_CRYPTO("ecdsa-nist-p384");
MODULE_ALIAS_CRYPTO("ecdsa-generic");
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 070/157] crypto: ecrdsa - Fix module auto-load on add_key
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (68 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 069/157] crypto: ecdsa - Fix module auto-load on add-key Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 071/157] crypto: qat - Fix ADF_DEV_RESET_SYNC memory leak Greg Kroah-Hartman
` (96 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Vitaly Chikunov, Stefan Berger,
Herbert Xu, Paul Wolneykien
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vitaly Chikunov <vt@altlinux.org>
commit eb5739a1efbc9ff216271aeea0ebe1c92e5383e5 upstream.
Add module alias with the algorithm cra_name similar to what we have for
RSA-related and other algorithms.
The kernel attempts to modprobe asymmetric algorithms using the names
"crypto-$cra_name" and "crypto-$cra_name-all." However, since these
aliases are currently missing, the modules are not loaded. For instance,
when using the `add_key` function, the hash algorithm is typically
loaded automatically, but the asymmetric algorithm is not.
Steps to test:
1. Cert is generated usings ima-evm-utils test suite with
`gen-keys.sh`, example cert is provided below:
$ base64 -d >test-gost2012_512-A.cer <<EOF
MIIB/DCCAWagAwIBAgIUK8+whWevr3FFkSdU9GLDAM7ure8wDAYIKoUDBwEBAwMFADARMQ8wDQYD
VQQDDAZDQSBLZXkwIBcNMjIwMjAxMjIwOTQxWhgPMjA4MjEyMDUyMjA5NDFaMBExDzANBgNVBAMM
BkNBIEtleTCBoDAXBggqhQMHAQEBAjALBgkqhQMHAQIBAgEDgYQABIGALXNrTJGgeErBUOov3Cfo
IrHF9fcj8UjzwGeKCkbCcINzVUbdPmCopeJRHDJEvQBX1CQUPtlwDv6ANjTTRoq5nCk9L5PPFP1H
z73JIXHT0eRBDVoWy0cWDRz1mmQlCnN2HThMtEloaQI81nTlKZOcEYDtDpi5WODmjEeRNQJMdqCj
UDBOMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFCwfOITMbE9VisW1i2TYeu1tAo5QMB8GA1UdIwQY
MBaAFCwfOITMbE9VisW1i2TYeu1tAo5QMAwGCCqFAwcBAQMDBQADgYEAmBfJCMTdC0/NSjz4BBiQ
qDIEjomO7FEHYlkX5NGulcF8FaJW2jeyyXXtbpnub1IQ8af1KFIpwoS2e93LaaofxpWlpQLlju6m
KYLOcO4xK3Whwa2hBAz9YbpUSFjvxnkS2/jpH2MsOSXuUEeCruG/RkHHB3ACef9umG6HCNQuAPY=
EOF
2. Optionally, trace module requests with: trace-cmd stream -e module &
3. Trigger add_key call for the cert:
# keyctl padd asymmetric "" @u <test-gost2012_512-A.cer
939910969
# lsmod | head -3
Module Size Used by
ecrdsa_generic 16384 0
streebog_generic 28672 0
Repored-by: Paul Wolneykien <manowar@altlinux.org>
Cc: stable@vger.kernel.org
Signed-off-by: Vitaly Chikunov <vt@altlinux.org>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
crypto/ecrdsa.c | 1 +
1 file changed, 1 insertion(+)
--- a/crypto/ecrdsa.c
+++ b/crypto/ecrdsa.c
@@ -294,4 +294,5 @@ module_exit(ecrdsa_mod_fini);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Vitaly Chikunov <vt@altlinux.org>");
MODULE_DESCRIPTION("EC-RDSA generic algorithm");
+MODULE_ALIAS_CRYPTO("ecrdsa");
MODULE_ALIAS_CRYPTO("ecrdsa-generic");
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 071/157] crypto: qat - Fix ADF_DEV_RESET_SYNC memory leak
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (69 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 070/157] crypto: ecrdsa - Fix module auto-load on add_key Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 072/157] kbuild: Remove support for Clangs ThinLTO caching Greg Kroah-Hartman
` (95 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Herbert Xu, Giovanni Cabiddu
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Herbert Xu <herbert@gondor.apana.org.au>
commit d3b17c6d9dddc2db3670bc9be628b122416a3d26 upstream.
Using completion_done to determine whether the caller has gone
away only works after a complete call. Furthermore it's still
possible that the caller has not yet called wait_for_completion,
resulting in another potential UAF.
Fix this by making the caller use cancel_work_sync and then freeing
the memory safely.
Fixes: 7d42e097607c ("crypto: qat - resolve race condition during AER recovery")
Cc: <stable@vger.kernel.org> #6.8+
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/crypto/intel/qat/qat_common/adf_aer.c | 19 +++++--------------
1 file changed, 5 insertions(+), 14 deletions(-)
--- a/drivers/crypto/intel/qat/qat_common/adf_aer.c
+++ b/drivers/crypto/intel/qat/qat_common/adf_aer.c
@@ -130,8 +130,7 @@ static void adf_device_reset_worker(stru
if (adf_dev_restart(accel_dev)) {
/* The device hanged and we can't restart it so stop here */
dev_err(&GET_DEV(accel_dev), "Restart device failed\n");
- if (reset_data->mode == ADF_DEV_RESET_ASYNC ||
- completion_done(&reset_data->compl))
+ if (reset_data->mode == ADF_DEV_RESET_ASYNC)
kfree(reset_data);
WARN(1, "QAT: device restart failed. Device is unusable\n");
return;
@@ -147,16 +146,8 @@ static void adf_device_reset_worker(stru
adf_dev_restarted_notify(accel_dev);
clear_bit(ADF_STATUS_RESTARTING, &accel_dev->status);
- /*
- * The dev is back alive. Notify the caller if in sync mode
- *
- * If device restart will take a more time than expected,
- * the schedule_reset() function can timeout and exit. This can be
- * detected by calling the completion_done() function. In this case
- * the reset_data structure needs to be freed here.
- */
- if (reset_data->mode == ADF_DEV_RESET_ASYNC ||
- completion_done(&reset_data->compl))
+ /* The dev is back alive. Notify the caller if in sync mode */
+ if (reset_data->mode == ADF_DEV_RESET_ASYNC)
kfree(reset_data);
else
complete(&reset_data->compl);
@@ -191,10 +182,10 @@ static int adf_dev_aer_schedule_reset(st
if (!timeout) {
dev_err(&GET_DEV(accel_dev),
"Reset device timeout expired\n");
+ cancel_work_sync(&reset_data->reset_work);
ret = -EFAULT;
- } else {
- kfree(reset_data);
}
+ kfree(reset_data);
return ret;
}
return 0;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 072/157] kbuild: Remove support for Clangs ThinLTO caching
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (70 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 071/157] crypto: qat - Fix ADF_DEV_RESET_SYNC memory leak Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 073/157] mm: fix race between __split_huge_pmd_locked() and GUP-fast Greg Kroah-Hartman
` (94 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Yifan Hong, Masami Hiramatsu,
Nathan Chancellor, Masahiro Yamada
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Chancellor <nathan@kernel.org>
commit aba091547ef6159d52471f42a3ef531b7b660ed8 upstream.
There is an issue in clang's ThinLTO caching (enabled for the kernel via
'--thinlto-cache-dir') with .incbin, which the kernel occasionally uses
to include data within the kernel, such as the .config file for
/proc/config.gz. For example, when changing the .config and rebuilding
vmlinux, the copy of .config in vmlinux does not match the copy of
.config in the build folder:
$ echo 'CONFIG_LTO_NONE=n
CONFIG_LTO_CLANG_THIN=y
CONFIG_IKCONFIG=y
CONFIG_HEADERS_INSTALL=y' >kernel/configs/repro.config
$ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 clean defconfig repro.config vmlinux
...
$ grep CONFIG_HEADERS_INSTALL .config
CONFIG_HEADERS_INSTALL=y
$ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL
CONFIG_HEADERS_INSTALL=y
$ scripts/config -d HEADERS_INSTALL
$ make -kj"$(nproc)" ARCH=x86_64 LLVM=1 vmlinux
...
UPD kernel/config_data
GZIP kernel/config_data.gz
CC kernel/configs.o
...
LD vmlinux
...
$ grep CONFIG_HEADERS_INSTALL .config
# CONFIG_HEADERS_INSTALL is not set
$ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL
CONFIG_HEADERS_INSTALL=y
Without '--thinlto-cache-dir' or when using full LTO, this issue does
not occur.
Benchmarking incremental builds on a few different machines with and
without the cache shows a 20% increase in incremental build time without
the cache when measured by touching init/main.c and running 'make all'.
ARCH=arm64 defconfig + CONFIG_LTO_CLANG_THIN=y on an arm64 host:
Benchmark 1: With ThinLTO cache
Time (mean ± σ): 56.347 s ± 0.163 s [User: 83.768 s, System: 24.661 s]
Range (min … max): 56.109 s … 56.594 s 10 runs
Benchmark 2: Without ThinLTO cache
Time (mean ± σ): 67.740 s ± 0.479 s [User: 718.458 s, System: 31.797 s]
Range (min … max): 67.059 s … 68.556 s 10 runs
Summary
With ThinLTO cache ran
1.20 ± 0.01 times faster than Without ThinLTO cache
ARCH=x86_64 defconfig + CONFIG_LTO_CLANG_THIN=y on an x86_64 host:
Benchmark 1: With ThinLTO cache
Time (mean ± σ): 85.772 s ± 0.252 s [User: 91.505 s, System: 8.408 s]
Range (min … max): 85.447 s … 86.244 s 10 runs
Benchmark 2: Without ThinLTO cache
Time (mean ± σ): 103.833 s ± 0.288 s [User: 232.058 s, System: 8.569 s]
Range (min … max): 103.286 s … 104.124 s 10 runs
Summary
With ThinLTO cache ran
1.21 ± 0.00 times faster than Without ThinLTO cache
While it is unfortunate to take this performance improvement off the
table, correctness is more important. If/when this is fixed in LLVM, it
can potentially be brought back in a conditional manner. Alternatively,
a developer can just disable LTO if doing incremental compiles quickly
is important, as a full compile cycle can still take over a minute even
with the cache and it is unlikely that LTO will result in functional
differences for a kernel change.
Cc: stable@vger.kernel.org
Fixes: dc5723b02e52 ("kbuild: add support for Clang LTO")
Reported-by: Yifan Hong <elsk@google.com>
Closes: https://github.com/ClangBuiltLinux/linux/issues/2021
Reported-by: Masami Hiramatsu <mhiramat@kernel.org>
Closes: https://lore.kernel.org/r/20220327115526.cc4b0ff55fc53c97683c3e4d@kernel.org/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Makefile | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/Makefile
+++ b/Makefile
@@ -942,7 +942,6 @@ endif
ifdef CONFIG_LTO_CLANG
ifdef CONFIG_LTO_CLANG_THIN
CC_FLAGS_LTO := -flto=thin -fsplit-lto-unit
-KBUILD_LDFLAGS += --thinlto-cache-dir=$(extmod_prefix).thinlto-cache
else
CC_FLAGS_LTO := -flto
endif
@@ -1477,7 +1476,7 @@ endif # CONFIG_MODULES
# Directories & files removed with 'make clean'
CLEAN_FILES += vmlinux.symvers modules-only.symvers \
modules.builtin modules.builtin.modinfo modules.nsdeps \
- compile_commands.json .thinlto-cache rust/test \
+ compile_commands.json rust/test \
rust-project.json .vmlinux.objs .vmlinux.export.c
# Directories & files removed with 'make mrproper'
@@ -1783,7 +1782,7 @@ PHONY += compile_commands.json
clean-dirs := $(KBUILD_EXTMOD)
clean: rm-files := $(KBUILD_EXTMOD)/Module.symvers $(KBUILD_EXTMOD)/modules.nsdeps \
- $(KBUILD_EXTMOD)/compile_commands.json $(KBUILD_EXTMOD)/.thinlto-cache
+ $(KBUILD_EXTMOD)/compile_commands.json
PHONY += prepare
# now expand this into a simple variable to reduce the cost of shell evaluations
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 073/157] mm: fix race between __split_huge_pmd_locked() and GUP-fast
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (71 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 072/157] kbuild: Remove support for Clangs ThinLTO caching Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 074/157] io_uring/napi: fix timeout calculation Greg Kroah-Hartman
` (93 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Ryan Roberts, Zi Yan,
Anshuman Khandual, David Hildenbrand, Andreas Larsson,
Andy Lutomirski, Aneesh Kumar K.V, Borislav Petkov (AMD),
Catalin Marinas, Christian Borntraeger, Christophe Leroy,
Dave Hansen, David S. Miller, Ingo Molnar, Jonathan Corbet,
Mark Rutland, Naveen N. Rao, Nicholas Piggin, Peter Zijlstra,
Sven Schnelle, Thomas Gleixner, Will Deacon, Andrew Morton
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ryan Roberts <ryan.roberts@arm.com>
commit 3a5a8d343e1cf96eb9971b17cbd4b832ab19b8e7 upstream.
__split_huge_pmd_locked() can be called for a present THP, devmap or
(non-present) migration entry. It calls pmdp_invalidate() unconditionally
on the pmdp and only determines if it is present or not based on the
returned old pmd. This is a problem for the migration entry case because
pmd_mkinvalid(), called by pmdp_invalidate() must only be called for a
present pmd.
On arm64 at least, pmd_mkinvalid() will mark the pmd such that any future
call to pmd_present() will return true. And therefore any lockless
pgtable walker could see the migration entry pmd in this state and start
interpretting the fields as if it were present, leading to BadThings (TM).
GUP-fast appears to be one such lockless pgtable walker.
x86 does not suffer the above problem, but instead pmd_mkinvalid() will
corrupt the offset field of the swap entry within the swap pte. See link
below for discussion of that problem.
Fix all of this by only calling pmdp_invalidate() for a present pmd. And
for good measure let's add a warning to all implementations of
pmdp_invalidate[_ad](). I've manually reviewed all other
pmdp_invalidate[_ad]() call sites and believe all others to be conformant.
This is a theoretical bug found during code review. I don't have any test
case to trigger it in practice.
Link: https://lkml.kernel.org/r/20240501143310.1381675-1-ryan.roberts@arm.com
Link: https://lore.kernel.org/all/0dd7827a-6334-439a-8fd0-43c98e6af22b@arm.com/
Fixes: 84c3fc4e9c56 ("mm: thp: check pmd migration entry in common path")
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Reviewed-by: Zi Yan <ziy@nvidia.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: David Hildenbrand <david@redhat.com>
Cc: Andreas Larsson <andreas@gaisler.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Naveen N. Rao <naveen.n.rao@linux.ibm.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sven Schnelle <svens@linux.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/mm/arch_pgtable_helpers.rst | 6 ++-
arch/powerpc/mm/book3s64/pgtable.c | 1
arch/s390/include/asm/pgtable.h | 4 +-
arch/sparc/mm/tlb.c | 1
arch/x86/mm/pgtable.c | 2 +
mm/huge_memory.c | 49 +++++++++++++++---------------
mm/pgtable-generic.c | 2 +
7 files changed, 39 insertions(+), 26 deletions(-)
--- a/Documentation/mm/arch_pgtable_helpers.rst
+++ b/Documentation/mm/arch_pgtable_helpers.rst
@@ -140,7 +140,8 @@ PMD Page Table Helpers
+---------------------------+--------------------------------------------------+
| pmd_swp_clear_soft_dirty | Clears a soft dirty swapped PMD |
+---------------------------+--------------------------------------------------+
-| pmd_mkinvalid | Invalidates a mapped PMD [1] |
+| pmd_mkinvalid | Invalidates a present PMD; do not call for |
+| | non-present PMD [1] |
+---------------------------+--------------------------------------------------+
| pmd_set_huge | Creates a PMD huge mapping |
+---------------------------+--------------------------------------------------+
@@ -196,7 +197,8 @@ PUD Page Table Helpers
+---------------------------+--------------------------------------------------+
| pud_mkdevmap | Creates a ZONE_DEVICE mapped PUD |
+---------------------------+--------------------------------------------------+
-| pud_mkinvalid | Invalidates a mapped PUD [1] |
+| pud_mkinvalid | Invalidates a present PUD; do not call for |
+| | non-present PUD [1] |
+---------------------------+--------------------------------------------------+
| pud_set_huge | Creates a PUD huge mapping |
+---------------------------+--------------------------------------------------+
--- a/arch/powerpc/mm/book3s64/pgtable.c
+++ b/arch/powerpc/mm/book3s64/pgtable.c
@@ -170,6 +170,7 @@ pmd_t pmdp_invalidate(struct vm_area_str
{
unsigned long old_pmd;
+ VM_WARN_ON_ONCE(!pmd_present(*pmdp));
old_pmd = pmd_hugepage_update(vma->vm_mm, address, pmdp, _PAGE_PRESENT, _PAGE_INVALID);
flush_pmd_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
return __pmd(old_pmd);
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -1778,8 +1778,10 @@ static inline pmd_t pmdp_huge_clear_flus
static inline pmd_t pmdp_invalidate(struct vm_area_struct *vma,
unsigned long addr, pmd_t *pmdp)
{
- pmd_t pmd = __pmd(pmd_val(*pmdp) | _SEGMENT_ENTRY_INVALID);
+ pmd_t pmd;
+ VM_WARN_ON_ONCE(!pmd_present(*pmdp));
+ pmd = __pmd(pmd_val(*pmdp) | _SEGMENT_ENTRY_INVALID);
return pmdp_xchg_direct(vma->vm_mm, addr, pmdp, pmd);
}
--- a/arch/sparc/mm/tlb.c
+++ b/arch/sparc/mm/tlb.c
@@ -249,6 +249,7 @@ pmd_t pmdp_invalidate(struct vm_area_str
{
pmd_t old, entry;
+ VM_WARN_ON_ONCE(!pmd_present(*pmdp));
entry = __pmd(pmd_val(*pmdp) & ~_PAGE_VALID);
old = pmdp_establish(vma, address, pmdp, entry);
flush_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -631,6 +631,8 @@ int pmdp_clear_flush_young(struct vm_are
pmd_t pmdp_invalidate_ad(struct vm_area_struct *vma, unsigned long address,
pmd_t *pmdp)
{
+ VM_WARN_ON_ONCE(!pmd_present(*pmdp));
+
/*
* No flush is necessary. Once an invalid PTE is established, the PTE's
* access and dirty bits cannot be updated.
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2493,32 +2493,11 @@ static void __split_huge_pmd_locked(stru
return __split_huge_zero_page_pmd(vma, haddr, pmd);
}
- /*
- * Up to this point the pmd is present and huge and userland has the
- * whole access to the hugepage during the split (which happens in
- * place). If we overwrite the pmd with the not-huge version pointing
- * to the pte here (which of course we could if all CPUs were bug
- * free), userland could trigger a small page size TLB miss on the
- * small sized TLB while the hugepage TLB entry is still established in
- * the huge TLB. Some CPU doesn't like that.
- * See http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf, Erratum
- * 383 on page 105. Intel should be safe but is also warns that it's
- * only safe if the permission and cache attributes of the two entries
- * loaded in the two TLB is identical (which should be the case here).
- * But it is generally safer to never allow small and huge TLB entries
- * for the same virtual address to be loaded simultaneously. So instead
- * of doing "pmd_populate(); flush_pmd_tlb_range();" we first mark the
- * current pmd notpresent (atomically because here the pmd_trans_huge
- * must remain set at all times on the pmd until the split is complete
- * for this pmd), then we flush the SMP TLB and finally we write the
- * non-huge version of the pmd entry with pmd_populate.
- */
- old_pmd = pmdp_invalidate(vma, haddr, pmd);
-
- pmd_migration = is_pmd_migration_entry(old_pmd);
+ pmd_migration = is_pmd_migration_entry(*pmd);
if (unlikely(pmd_migration)) {
swp_entry_t entry;
+ old_pmd = *pmd;
entry = pmd_to_swp_entry(old_pmd);
page = pfn_swap_entry_to_page(entry);
write = is_writable_migration_entry(entry);
@@ -2529,6 +2508,30 @@ static void __split_huge_pmd_locked(stru
soft_dirty = pmd_swp_soft_dirty(old_pmd);
uffd_wp = pmd_swp_uffd_wp(old_pmd);
} else {
+ /*
+ * Up to this point the pmd is present and huge and userland has
+ * the whole access to the hugepage during the split (which
+ * happens in place). If we overwrite the pmd with the not-huge
+ * version pointing to the pte here (which of course we could if
+ * all CPUs were bug free), userland could trigger a small page
+ * size TLB miss on the small sized TLB while the hugepage TLB
+ * entry is still established in the huge TLB. Some CPU doesn't
+ * like that. See
+ * http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf, Erratum
+ * 383 on page 105. Intel should be safe but is also warns that
+ * it's only safe if the permission and cache attributes of the
+ * two entries loaded in the two TLB is identical (which should
+ * be the case here). But it is generally safer to never allow
+ * small and huge TLB entries for the same virtual address to be
+ * loaded simultaneously. So instead of doing "pmd_populate();
+ * flush_pmd_tlb_range();" we first mark the current pmd
+ * notpresent (atomically because here the pmd_trans_huge must
+ * remain set at all times on the pmd until the split is
+ * complete for this pmd), then we flush the SMP TLB and finally
+ * we write the non-huge version of the pmd entry with
+ * pmd_populate.
+ */
+ old_pmd = pmdp_invalidate(vma, haddr, pmd);
page = pmd_page(old_pmd);
folio = page_folio(page);
if (pmd_dirty(old_pmd)) {
--- a/mm/pgtable-generic.c
+++ b/mm/pgtable-generic.c
@@ -198,6 +198,7 @@ pgtable_t pgtable_trans_huge_withdraw(st
pmd_t pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
pmd_t *pmdp)
{
+ VM_WARN_ON_ONCE(!pmd_present(*pmdp));
pmd_t old = pmdp_establish(vma, address, pmdp, pmd_mkinvalid(*pmdp));
flush_pmd_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
return old;
@@ -208,6 +209,7 @@ pmd_t pmdp_invalidate(struct vm_area_str
pmd_t pmdp_invalidate_ad(struct vm_area_struct *vma, unsigned long address,
pmd_t *pmdp)
{
+ VM_WARN_ON_ONCE(!pmd_present(*pmdp));
return pmdp_invalidate(vma, address, pmdp);
}
#endif
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 074/157] io_uring/napi: fix timeout calculation
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (72 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 073/157] mm: fix race between __split_huge_pmd_locked() and GUP-fast Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 075/157] io_uring: check for non-NULL file pointer in io_file_can_poll() Greg Kroah-Hartman
` (92 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Lewis Baker, Jens Axboe
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jens Axboe <axboe@kernel.dk>
commit 415ce0ea55c5a3afea501a773e002be9ed7149f5 upstream.
Not quite sure what __io_napi_adjust_timeout() was attemping to do, it's
adjusting both the NAPI timeout and the general overall timeout, and
calculating a value that is never used. The overall timeout is a super
set of the NAPI timeout, and doesn't need adjusting. The only thing we
really need to care about is that the NAPI timeout doesn't exceed the
overall timeout. If a user asked for a timeout of eg 5 usec and NAPI
timeout is 10 usec, then we should not spin for 10 usec.
While in there, sanitize the time checking a bit. If we have a negative
value in the passed in timeout, discard it. Round up the value as well,
so we don't end up with a NAPI timeout for the majority of the wait,
with only a tiny sleep value at the end.
Hence the only case we need to care about is if the NAPI timeout is
larger than the overall timeout. If it is, cap the NAPI timeout at what
the overall timeout is.
Cc: stable@vger.kernel.org
Fixes: 8d0c12a80cde ("io-uring: add napi busy poll support")
Reported-by: Lewis Baker <lewissbaker@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
io_uring/napi.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/io_uring/napi.c b/io_uring/napi.c
index 883a1a665907..8c18ede595c4 100644
--- a/io_uring/napi.c
+++ b/io_uring/napi.c
@@ -261,12 +261,14 @@ int io_unregister_napi(struct io_ring_ctx *ctx, void __user *arg)
}
/*
- * __io_napi_adjust_timeout() - Add napi id to the busy poll list
+ * __io_napi_adjust_timeout() - adjust busy loop timeout
* @ctx: pointer to io-uring context structure
* @iowq: pointer to io wait queue
* @ts: pointer to timespec or NULL
*
* Adjust the busy loop timeout according to timespec and busy poll timeout.
+ * If the specified NAPI timeout is bigger than the wait timeout, then adjust
+ * the NAPI timeout accordingly.
*/
void __io_napi_adjust_timeout(struct io_ring_ctx *ctx, struct io_wait_queue *iowq,
struct timespec64 *ts)
@@ -274,16 +276,16 @@ void __io_napi_adjust_timeout(struct io_ring_ctx *ctx, struct io_wait_queue *iow
unsigned int poll_to = READ_ONCE(ctx->napi_busy_poll_to);
if (ts) {
- struct timespec64 poll_to_ts = ns_to_timespec64(1000 * (s64)poll_to);
+ struct timespec64 poll_to_ts;
- if (timespec64_compare(ts, &poll_to_ts) > 0) {
- *ts = timespec64_sub(*ts, poll_to_ts);
- } else {
- u64 to = timespec64_to_ns(ts);
-
- do_div(to, 1000);
- ts->tv_sec = 0;
- ts->tv_nsec = 0;
+ poll_to_ts = ns_to_timespec64(1000 * (s64)poll_to);
+ if (timespec64_compare(ts, &poll_to_ts) < 0) {
+ s64 poll_to_ns = timespec64_to_ns(ts);
+ if (poll_to_ns > 0) {
+ u64 val = poll_to_ns + 999;
+ do_div(val, (s64) 1000);
+ poll_to = val;
+ }
}
}
--
2.45.2
^ permalink raw reply related [flat|nested] 168+ messages in thread* [PATCH 6.9 075/157] io_uring: check for non-NULL file pointer in io_file_can_poll()
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (73 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 074/157] io_uring/napi: fix timeout calculation Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 076/157] filemap: add helper mapping_max_folio_size() Greg Kroah-Hartman
` (91 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Jens Axboe
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jens Axboe <axboe@kernel.dk>
commit 5fc16fa5f13b3c06fdb959ef262050bd810416a2 upstream.
In earlier kernels, it was possible to trigger a NULL pointer
dereference off the forced async preparation path, if no file had
been assigned. The trace leading to that looks as follows:
BUG: kernel NULL pointer dereference, address: 00000000000000b0
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 67 PID: 1633 Comm: buf-ring-invali Not tainted 6.8.0-rc3+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 2/2/2022
RIP: 0010:io_buffer_select+0xc3/0x210
Code: 00 00 48 39 d1 0f 82 ae 00 00 00 48 81 4b 48 00 00 01 00 48 89 73 70 0f b7 50 0c 66 89 53 42 85 ed 0f 85 d2 00 00 00 48 8b 13 <48> 8b 92 b0 00 00 00 48 83 7a 40 00 0f 84 21 01 00 00 4c 8b 20 5b
RSP: 0018:ffffb7bec38c7d88 EFLAGS: 00010246
RAX: ffff97af2be61000 RBX: ffff97af234f1700 RCX: 0000000000000040
RDX: 0000000000000000 RSI: ffff97aecfb04820 RDI: ffff97af234f1700
RBP: 0000000000000000 R08: 0000000000200030 R09: 0000000000000020
R10: ffffb7bec38c7dc8 R11: 000000000000c000 R12: ffffb7bec38c7db8
R13: ffff97aecfb05800 R14: ffff97aecfb05800 R15: ffff97af2be5e000
FS: 00007f852f74b740(0000) GS:ffff97b1eeec0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000b0 CR3: 000000016deab005 CR4: 0000000000370ef0
Call Trace:
<TASK>
? __die+0x1f/0x60
? page_fault_oops+0x14d/0x420
? do_user_addr_fault+0x61/0x6a0
? exc_page_fault+0x6c/0x150
? asm_exc_page_fault+0x22/0x30
? io_buffer_select+0xc3/0x210
__io_import_iovec+0xb5/0x120
io_readv_prep_async+0x36/0x70
io_queue_sqe_fallback+0x20/0x260
io_submit_sqes+0x314/0x630
__do_sys_io_uring_enter+0x339/0xbc0
? __do_sys_io_uring_register+0x11b/0xc50
? vm_mmap_pgoff+0xce/0x160
do_syscall_64+0x5f/0x180
entry_SYSCALL_64_after_hwframe+0x46/0x4e
RIP: 0033:0x55e0a110a67e
Code: ba cc 00 00 00 45 31 c0 44 0f b6 92 d0 00 00 00 31 d2 41 b9 08 00 00 00 41 83 e2 01 41 c1 e2 04 41 09 c2 b8 aa 01 00 00 0f 05 <c3> 90 89 30 eb a9 0f 1f 40 00 48 8b 42 20 8b 00 a8 06 75 af 85 f6
because the request is marked forced ASYNC and has a bad file fd, and
hence takes the forced async prep path.
Current kernels with the request async prep cleaned up can no longer hit
this issue, but for ease of backporting, let's add this safety check in
here too as it really doesn't hurt. For both cases, this will inevitably
end with a CQE posted with -EBADF.
Cc: stable@vger.kernel.org
Fixes: a76c0b31eef5 ("io_uring: commit non-pollable provided mapped buffers upfront")
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
io_uring/io_uring.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/io_uring/io_uring.h
+++ b/io_uring/io_uring.h
@@ -442,7 +442,7 @@ static inline bool io_file_can_poll(stru
{
if (req->flags & REQ_F_CAN_POLL)
return true;
- if (file_can_poll(req->file)) {
+ if (req->file && file_can_poll(req->file)) {
req->flags |= REQ_F_CAN_POLL;
return true;
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 076/157] filemap: add helper mapping_max_folio_size()
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (74 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 075/157] io_uring: check for non-NULL file pointer in io_file_can_poll() Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 077/157] iomap: fault in smaller chunks for non-large folio mappings Greg Kroah-Hartman
` (90 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Darrick J. Wong, Xu Yang,
Ritesh Harjani (IBM), Christoph Hellwig, Matthew Wilcox (Oracle),
Christian Brauner
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xu Yang <xu.yang_2@nxp.com>
commit 79c137454815ba5554caa8eeb4ad5c94e96e45ce upstream.
Add mapping_max_folio_size() to get the maximum folio size for this
pagecache mapping.
Fixes: 5d8edfb900d5 ("iomap: Copy larger chunks from userspace")
Cc: stable@vger.kernel.org
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Link: https://lore.kernel.org/r/20240521114939.2541461-1-xu.yang_2@nxp.com
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/pagemap.h | 34 +++++++++++++++++++++-------------
1 file changed, 21 insertions(+), 13 deletions(-)
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -344,6 +344,19 @@ static inline void mapping_set_gfp_mask(
m->gfp_mask = mask;
}
+/*
+ * There are some parts of the kernel which assume that PMD entries
+ * are exactly HPAGE_PMD_ORDER. Those should be fixed, but until then,
+ * limit the maximum allocation order to PMD size. I'm not aware of any
+ * assumptions about maximum order if THP are disabled, but 8 seems like
+ * a good order (that's 1MB if you're using 4kB pages)
+ */
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+#define MAX_PAGECACHE_ORDER HPAGE_PMD_ORDER
+#else
+#define MAX_PAGECACHE_ORDER 8
+#endif
+
/**
* mapping_set_large_folios() - Indicate the file supports large folios.
* @mapping: The file.
@@ -370,6 +383,14 @@ static inline bool mapping_large_folio_s
test_bit(AS_LARGE_FOLIO_SUPPORT, &mapping->flags);
}
+/* Return the maximum folio size for this pagecache mapping, in bytes. */
+static inline size_t mapping_max_folio_size(struct address_space *mapping)
+{
+ if (mapping_large_folio_support(mapping))
+ return PAGE_SIZE << MAX_PAGECACHE_ORDER;
+ return PAGE_SIZE;
+}
+
static inline int filemap_nr_thps(struct address_space *mapping)
{
#ifdef CONFIG_READ_ONLY_THP_FOR_FS
@@ -528,19 +549,6 @@ static inline void *detach_page_private(
return folio_detach_private(page_folio(page));
}
-/*
- * There are some parts of the kernel which assume that PMD entries
- * are exactly HPAGE_PMD_ORDER. Those should be fixed, but until then,
- * limit the maximum allocation order to PMD size. I'm not aware of any
- * assumptions about maximum order if THP are disabled, but 8 seems like
- * a good order (that's 1MB if you're using 4kB pages)
- */
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
-#define MAX_PAGECACHE_ORDER HPAGE_PMD_ORDER
-#else
-#define MAX_PAGECACHE_ORDER 8
-#endif
-
#ifdef CONFIG_NUMA
struct folio *filemap_alloc_folio(gfp_t gfp, unsigned int order);
#else
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 077/157] iomap: fault in smaller chunks for non-large folio mappings
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (75 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 076/157] filemap: add helper mapping_max_folio_size() Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 078/157] ACPI: APEI: EINJ: Fix einj_dev release leak Greg Kroah-Hartman
` (89 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Darrick J. Wong, Xu Yang,
Christoph Hellwig, Matthew Wilcox (Oracle), Christian Brauner
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xu Yang <xu.yang_2@nxp.com>
commit 4e527d5841e24623181edc7fd6f6598ffa810e10 upstream.
Since commit (5d8edfb900d5 "iomap: Copy larger chunks from userspace"),
iomap will try to copy in larger chunks than PAGE_SIZE. However, if the
mapping doesn't support large folio, only one page of maximum 4KB will
be created and 4KB data will be writen to pagecache each time. Then,
next 4KB will be handled in next iteration. This will cause potential
write performance problem.
If chunk is 2MB, total 512 pages need to be handled finally. During this
period, fault_in_iov_iter_readable() is called to check iov_iter readable
validity. Since only 4KB will be handled each time, below address space
will be checked over and over again:
start end
-
buf, buf+2MB
buf+4KB, buf+2MB
buf+8KB, buf+2MB
...
buf+2044KB buf+2MB
Obviously the checking size is wrong since only 4KB will be handled each
time. So this will get a correct chunk to let iomap work well in non-large
folio case.
With this change, the write speed will be stable. Tested on ARM64 device.
Before:
- dd if=/dev/zero of=/dev/sda bs=400K count=10485 (334 MB/s)
- dd if=/dev/zero of=/dev/sda bs=800K count=5242 (278 MB/s)
- dd if=/dev/zero of=/dev/sda bs=1600K count=2621 (204 MB/s)
- dd if=/dev/zero of=/dev/sda bs=2200K count=1906 (170 MB/s)
- dd if=/dev/zero of=/dev/sda bs=3000K count=1398 (150 MB/s)
- dd if=/dev/zero of=/dev/sda bs=4500K count=932 (139 MB/s)
After:
- dd if=/dev/zero of=/dev/sda bs=400K count=10485 (339 MB/s)
- dd if=/dev/zero of=/dev/sda bs=800K count=5242 (330 MB/s)
- dd if=/dev/zero of=/dev/sda bs=1600K count=2621 (332 MB/s)
- dd if=/dev/zero of=/dev/sda bs=2200K count=1906 (333 MB/s)
- dd if=/dev/zero of=/dev/sda bs=3000K count=1398 (333 MB/s)
- dd if=/dev/zero of=/dev/sda bs=4500K count=932 (333 MB/s)
Fixes: 5d8edfb900d5 ("iomap: Copy larger chunks from userspace")
Cc: stable@vger.kernel.org
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Link: https://lore.kernel.org/r/20240521114939.2541461-2-xu.yang_2@nxp.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/iomap/buffered-io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -909,11 +909,11 @@ static size_t iomap_write_end(struct iom
static loff_t iomap_write_iter(struct iomap_iter *iter, struct iov_iter *i)
{
loff_t length = iomap_length(iter);
- size_t chunk = PAGE_SIZE << MAX_PAGECACHE_ORDER;
loff_t pos = iter->pos;
ssize_t written = 0;
long status = 0;
struct address_space *mapping = iter->inode->i_mapping;
+ size_t chunk = mapping_max_folio_size(mapping);
unsigned int bdp_flags = (iter->flags & IOMAP_NOWAIT) ? BDP_ASYNC : 0;
do {
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 078/157] ACPI: APEI: EINJ: Fix einj_dev release leak
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (76 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 077/157] iomap: fault in smaller chunks for non-large folio mappings Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 079/157] i2c: acpi: Unbind mux adapters before delete Greg Kroah-Hartman
` (88 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Dan Williams, Ben Cheatham,
Rafael J. Wysocki
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <dan.j.williams@intel.com>
commit 7ff6c798eca05e4a9dcb80163cb454d7787a4bc3 upstream.
The platform driver conversion of EINJ mistakenly used
platform_device_del() to unwind platform_device_register_full() at
module exit. This leads to a small leak of one 'struct platform_device'
instance per module load/unload cycle. Switch to
platform_device_unregister() which performs both device_del() and final
put_device().
Fixes: 5621fafaac00 ("EINJ: Migrate to a platform driver")
Cc: 6.9+ <stable@vger.kernel.org> # 6.9+
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Ben Cheatham <Benjamin.Cheatham@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/acpi/apei/einj-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/acpi/apei/einj-core.c
+++ b/drivers/acpi/apei/einj-core.c
@@ -903,7 +903,7 @@ static void __exit einj_exit(void)
if (einj_initialized)
platform_driver_unregister(&einj_driver);
- platform_device_del(einj_dev);
+ platform_device_unregister(einj_dev);
}
module_init(einj_init);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 079/157] i2c: acpi: Unbind mux adapters before delete
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (77 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 078/157] ACPI: APEI: EINJ: Fix einj_dev release leak Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 080/157] HID: i2c-hid: elan: fix reset suspend current leakage Greg Kroah-Hartman
` (87 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Hamish Martin, Mika Westerberg,
Andi Shyti, Wolfram Sang
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
commit 3f858bbf04dbac934ac279aaee05d49eb9910051 upstream.
There is an issue with ACPI overlay table removal specifically related
to I2C multiplexers.
Consider an ACPI SSDT Overlay that defines a PCA9548 I2C mux on an
existing I2C bus. When this table is loaded we see the creation of a
device for the overall PCA9548 chip and 8 further devices - one
i2c_adapter each for the mux channels. These are all bound to their
ACPI equivalents via an eventual invocation of acpi_bind_one().
When we unload the SSDT overlay we run into the problem. The ACPI
devices are deleted as normal via acpi_device_del_work_fn() and the
acpi_device_del_list.
However, the following warning and stack trace is output as the
deletion does not go smoothly:
------------[ cut here ]------------
kernfs: can not remove 'physical_node', no directory
WARNING: CPU: 1 PID: 11 at fs/kernfs/dir.c:1674 kernfs_remove_by_name_ns+0xb9/0xc0
Modules linked in:
CPU: 1 PID: 11 Comm: kworker/u128:0 Not tainted 6.8.0-rc6+ #1
Hardware name: congatec AG conga-B7E3/conga-B7E3, BIOS 5.13 05/16/2023
Workqueue: kacpi_hotplug acpi_device_del_work_fn
RIP: 0010:kernfs_remove_by_name_ns+0xb9/0xc0
Code: e4 00 48 89 ef e8 07 71 db ff 5b b8 fe ff ff ff 5d 41 5c 41 5d e9 a7 55 e4 00 0f 0b eb a6 48 c7 c7 f0 38 0d 9d e8 97 0a d5 ff <0f> 0b eb dc 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 0018:ffff9f864008fb28 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff8ef90a8d4940 RCX: 0000000000000000
RDX: ffff8f000e267d10 RSI: ffff8f000e25c780 RDI: ffff8f000e25c780
RBP: ffff8ef9186f9870 R08: 0000000000013ffb R09: 00000000ffffbfff
R10: 00000000ffffbfff R11: ffff8f000e0a0000 R12: ffff9f864008fb50
R13: ffff8ef90c93dd60 R14: ffff8ef9010d0958 R15: ffff8ef9186f98c8
FS: 0000000000000000(0000) GS:ffff8f000e240000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f48f5253a08 CR3: 00000003cb82e000 CR4: 00000000003506f0
Call Trace:
<TASK>
? kernfs_remove_by_name_ns+0xb9/0xc0
? __warn+0x7c/0x130
? kernfs_remove_by_name_ns+0xb9/0xc0
? report_bug+0x171/0x1a0
? handle_bug+0x3c/0x70
? exc_invalid_op+0x17/0x70
? asm_exc_invalid_op+0x1a/0x20
? kernfs_remove_by_name_ns+0xb9/0xc0
? kernfs_remove_by_name_ns+0xb9/0xc0
acpi_unbind_one+0x108/0x180
device_del+0x18b/0x490
? srso_return_thunk+0x5/0x5f
? srso_return_thunk+0x5/0x5f
device_unregister+0xd/0x30
i2c_del_adapter.part.0+0x1bf/0x250
i2c_mux_del_adapters+0xa1/0xe0
i2c_device_remove+0x1e/0x80
device_release_driver_internal+0x19a/0x200
bus_remove_device+0xbf/0x100
device_del+0x157/0x490
? __pfx_device_match_fwnode+0x10/0x10
? srso_return_thunk+0x5/0x5f
device_unregister+0xd/0x30
i2c_acpi_notify+0x10f/0x140
notifier_call_chain+0x58/0xd0
blocking_notifier_call_chain+0x3a/0x60
acpi_device_del_work_fn+0x85/0x1d0
process_one_work+0x134/0x2f0
worker_thread+0x2f0/0x410
? __pfx_worker_thread+0x10/0x10
kthread+0xe3/0x110
? __pfx_kthread+0x10/0x10
ret_from_fork+0x2f/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
</TASK>
---[ end trace 0000000000000000 ]---
...
repeated 7 more times, 1 for each channel of the mux
...
The issue is that the binding of the ACPI devices to their peer I2C
adapters is not correctly cleaned up. Digging deeper into the issue we
see that the deletion order is such that the ACPI devices matching the
mux channel i2c adapters are deleted first during the SSDT overlay
removal. For each of the channels we see a call to i2c_acpi_notify()
with ACPI_RECONFIG_DEVICE_REMOVE but, because these devices are not
actually i2c_clients, nothing is done for them.
Later on, after each of the mux channels has been dealt with, we come
to delete the i2c_client representing the PCA9548 device. This is the
call stack we see above, whereby the kernel cleans up the i2c_client
including destruction of the mux and its channel adapters. At this
point we do attempt to unbind from the ACPI peers but those peers no
longer exist and so we hit the kernfs errors.
The fix is to augment i2c_acpi_notify() to handle i2c_adapters. But,
given that the life cycle of the adapters is linked to the i2c_client,
instead of deleting the i2c_adapters during the i2c_acpi_notify(), we
just trigger unbinding of the ACPI device from the adapter device, and
allow the clean up of the adapter to continue in the way it always has.
Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Fixes: 525e6fabeae2 ("i2c / ACPI: add support for ACPI reconfigure notifications")
Cc: <stable@vger.kernel.org> # v4.8+
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/i2c/i2c-core-acpi.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -445,6 +445,11 @@ static struct i2c_client *i2c_acpi_find_
return i2c_find_device_by_fwnode(acpi_fwnode_handle(adev));
}
+static struct i2c_adapter *i2c_acpi_find_adapter_by_adev(struct acpi_device *adev)
+{
+ return i2c_find_adapter_by_fwnode(acpi_fwnode_handle(adev));
+}
+
static int i2c_acpi_notify(struct notifier_block *nb, unsigned long value,
void *arg)
{
@@ -471,11 +476,17 @@ static int i2c_acpi_notify(struct notifi
break;
client = i2c_acpi_find_client_by_adev(adev);
- if (!client)
- break;
+ if (client) {
+ i2c_unregister_device(client);
+ put_device(&client->dev);
+ }
+
+ adapter = i2c_acpi_find_adapter_by_adev(adev);
+ if (adapter) {
+ acpi_unbind_one(&adapter->dev);
+ put_device(&adapter->dev);
+ }
- i2c_unregister_device(client);
- put_device(&client->dev);
break;
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 080/157] HID: i2c-hid: elan: fix reset suspend current leakage
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (78 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 079/157] i2c: acpi: Unbind mux adapters before delete Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 081/157] scsi: core: Handle devices which return an unusually large VPD page count Greg Kroah-Hartman
` (86 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Douglas Anderson, Steev Klimaszewski,
Johan Hovold, Benjamin Tissoires
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan+linaro@kernel.org>
commit 0eafc58f2194dbd01d4be40f99a697681171995b upstream.
The Elan eKTH5015M touch controller found on the Lenovo ThinkPad X13s
shares the VCC33 supply with other peripherals that may remain powered
during suspend (e.g. when enabled as wakeup sources).
The reset line is also wired so that it can be left deasserted when the
supply is off.
This is important as it avoids holding the controller in reset for
extended periods of time when it remains powered, which can lead to
increased power consumption, and also avoids leaking current through the
X13s reset circuitry during suspend (and after driver unbind).
Use the new 'no-reset-on-power-off' devicetree property to determine
when reset needs to be asserted on power down.
Notably this also avoids wasting power on machine variants without a
touchscreen for which the driver would otherwise exit probe with reset
asserted.
Fixes: bd3cba00dcc6 ("HID: i2c-hid: elan: Add support for Elan eKTH6915 i2c-hid touchscreens")
Cc: <stable@vger.kernel.org> # 6.0
Cc: Douglas Anderson <dianders@chromium.org>
Tested-by: Steev Klimaszewski <steev@kali.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20240507144821.12275-5-johan+linaro@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/i2c-hid/i2c-hid-of-elan.c | 59 +++++++++++++++++++++++++++-------
1 file changed, 47 insertions(+), 12 deletions(-)
--- a/drivers/hid/i2c-hid/i2c-hid-of-elan.c
+++ b/drivers/hid/i2c-hid/i2c-hid-of-elan.c
@@ -31,6 +31,7 @@ struct i2c_hid_of_elan {
struct regulator *vcc33;
struct regulator *vccio;
struct gpio_desc *reset_gpio;
+ bool no_reset_on_power_off;
const struct elan_i2c_hid_chip_data *chip_data;
};
@@ -40,17 +41,17 @@ static int elan_i2c_hid_power_up(struct
container_of(ops, struct i2c_hid_of_elan, ops);
int ret;
+ gpiod_set_value_cansleep(ihid_elan->reset_gpio, 1);
+
if (ihid_elan->vcc33) {
ret = regulator_enable(ihid_elan->vcc33);
if (ret)
- return ret;
+ goto err_deassert_reset;
}
ret = regulator_enable(ihid_elan->vccio);
- if (ret) {
- regulator_disable(ihid_elan->vcc33);
- return ret;
- }
+ if (ret)
+ goto err_disable_vcc33;
if (ihid_elan->chip_data->post_power_delay_ms)
msleep(ihid_elan->chip_data->post_power_delay_ms);
@@ -60,6 +61,15 @@ static int elan_i2c_hid_power_up(struct
msleep(ihid_elan->chip_data->post_gpio_reset_on_delay_ms);
return 0;
+
+err_disable_vcc33:
+ if (ihid_elan->vcc33)
+ regulator_disable(ihid_elan->vcc33);
+err_deassert_reset:
+ if (ihid_elan->no_reset_on_power_off)
+ gpiod_set_value_cansleep(ihid_elan->reset_gpio, 0);
+
+ return ret;
}
static void elan_i2c_hid_power_down(struct i2chid_ops *ops)
@@ -67,7 +77,14 @@ static void elan_i2c_hid_power_down(stru
struct i2c_hid_of_elan *ihid_elan =
container_of(ops, struct i2c_hid_of_elan, ops);
- gpiod_set_value_cansleep(ihid_elan->reset_gpio, 1);
+ /*
+ * Do not assert reset when the hardware allows for it to remain
+ * deasserted regardless of the state of the (shared) power supply to
+ * avoid wasting power when the supply is left on.
+ */
+ if (!ihid_elan->no_reset_on_power_off)
+ gpiod_set_value_cansleep(ihid_elan->reset_gpio, 1);
+
if (ihid_elan->chip_data->post_gpio_reset_off_delay_ms)
msleep(ihid_elan->chip_data->post_gpio_reset_off_delay_ms);
@@ -79,6 +96,7 @@ static void elan_i2c_hid_power_down(stru
static int i2c_hid_of_elan_probe(struct i2c_client *client)
{
struct i2c_hid_of_elan *ihid_elan;
+ int ret;
ihid_elan = devm_kzalloc(&client->dev, sizeof(*ihid_elan), GFP_KERNEL);
if (!ihid_elan)
@@ -93,21 +111,38 @@ static int i2c_hid_of_elan_probe(struct
if (IS_ERR(ihid_elan->reset_gpio))
return PTR_ERR(ihid_elan->reset_gpio);
+ ihid_elan->no_reset_on_power_off = of_property_read_bool(client->dev.of_node,
+ "no-reset-on-power-off");
+
ihid_elan->vccio = devm_regulator_get(&client->dev, "vccio");
- if (IS_ERR(ihid_elan->vccio))
- return PTR_ERR(ihid_elan->vccio);
+ if (IS_ERR(ihid_elan->vccio)) {
+ ret = PTR_ERR(ihid_elan->vccio);
+ goto err_deassert_reset;
+ }
ihid_elan->chip_data = device_get_match_data(&client->dev);
if (ihid_elan->chip_data->main_supply_name) {
ihid_elan->vcc33 = devm_regulator_get(&client->dev,
ihid_elan->chip_data->main_supply_name);
- if (IS_ERR(ihid_elan->vcc33))
- return PTR_ERR(ihid_elan->vcc33);
+ if (IS_ERR(ihid_elan->vcc33)) {
+ ret = PTR_ERR(ihid_elan->vcc33);
+ goto err_deassert_reset;
+ }
}
- return i2c_hid_core_probe(client, &ihid_elan->ops,
- ihid_elan->chip_data->hid_descriptor_address, 0);
+ ret = i2c_hid_core_probe(client, &ihid_elan->ops,
+ ihid_elan->chip_data->hid_descriptor_address, 0);
+ if (ret)
+ goto err_deassert_reset;
+
+ return 0;
+
+err_deassert_reset:
+ if (ihid_elan->no_reset_on_power_off)
+ gpiod_set_value_cansleep(ihid_elan->reset_gpio, 0);
+
+ return ret;
}
static const struct elan_i2c_hid_chip_data elan_ekth6915_chip_data = {
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 081/157] scsi: core: Handle devices which return an unusually large VPD page count
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (79 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 080/157] HID: i2c-hid: elan: fix reset suspend current leakage Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 082/157] net/ipv6: Fix route deleting failure when metric equals 0 Greg Kroah-Hartman
` (85 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Peter Schneider, Bart Van Assche,
Martin K. Petersen
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin K. Petersen <martin.petersen@oracle.com>
commit d09c05aa35909adb7d29f92f0cd79fdcd1338ef0 upstream.
Peter Schneider reported that a system would no longer boot after
updating to 6.8.4. Peter bisected the issue and identified commit
b5fc07a5fb56 ("scsi: core: Consult supported VPD page list prior to
fetching page") as being the culprit.
Turns out the enclosure device in Peter's system reports a byteswapped
page length for VPD page 0. It reports "02 00" as page length instead
of "00 02". This causes us to attempt to access 516 bytes (page length
+ header) of information despite only 2 pages being present.
Limit the page search scope to the size of our VPD buffer to guard
against devices returning a larger page count than requested.
Link: https://lore.kernel.org/r/20240521023040.2703884-1-martin.petersen@oracle.com
Fixes: b5fc07a5fb56 ("scsi: core: Consult supported VPD page list prior to fetching page")
Cc: stable@vger.kernel.org
Reported-by: Peter Schneider <pschneider1968@googlemail.com>
Closes: https://lore.kernel.org/all/eec6ebbf-061b-4a7b-96dc-ea748aa4d035@googlemail.com/
Tested-by: Peter Schneider <pschneider1968@googlemail.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/scsi.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -350,6 +350,13 @@ static int scsi_get_vpd_size(struct scsi
if (result < SCSI_VPD_HEADER_SIZE)
return 0;
+ if (result > sizeof(vpd)) {
+ dev_warn_once(&sdev->sdev_gendev,
+ "%s: long VPD page 0 length: %d bytes\n",
+ __func__, result);
+ result = sizeof(vpd);
+ }
+
result -= SCSI_VPD_HEADER_SIZE;
if (!memchr(&vpd[SCSI_VPD_HEADER_SIZE], page, result))
return 0;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 082/157] net/ipv6: Fix route deleting failure when metric equals 0
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (80 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 081/157] scsi: core: Handle devices which return an unusually large VPD page count Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 083/157] net/9p: fix uninit-value in p9_client_rpc() Greg Kroah-Hartman
` (84 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Fan Yu, xu xin, David Ahern,
Jakub Kicinski
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: xu xin <xu.xin16@zte.com.cn>
commit bb487272380d120295e955ad8acfcbb281b57642 upstream.
Problem
=========
After commit 67f695134703 ("ipv6: Move setting default metric for routes"),
we noticed that the logic of assigning the default value of fc_metirc
changed in the ioctl process. That is, when users use ioctl(fd, SIOCADDRT,
rt) with a non-zero metric to add a route, then they may fail to delete a
route with passing in a metric value of 0 to the kernel by ioctl(fd,
SIOCDELRT, rt). But iproute can succeed in deleting it.
As a reference, when using iproute tools by netlink to delete routes with
a metric parameter equals 0, like the command as follows:
ip -6 route del fe80::/64 via fe81::5054:ff:fe11:3451 dev eth0 metric 0
the user can still succeed in deleting the route entry with the smallest
metric.
Root Reason
===========
After commit 67f695134703 ("ipv6: Move setting default metric for routes"),
When ioctl() pass in SIOCDELRT with a zero metric, rtmsg_to_fib6_config()
will set a defalut value (1024) to cfg->fc_metric in kernel, and in
ip6_route_del() and the line 4074 at net/ipv3/route.c, it will check by
if (cfg->fc_metric && cfg->fc_metric != rt->fib6_metric)
continue;
and the condition is true and skip the later procedure (deleting route)
because cfg->fc_metric != rt->fib6_metric. But before that commit,
cfg->fc_metric is still zero there, so the condition is false and it
will do the following procedure (deleting).
Solution
========
In order to keep a consistent behaviour across netlink() and ioctl(), we
should allow to delete a route with a metric value of 0. So we only do
the default setting of fc_metric in route adding.
CC: stable@vger.kernel.org # 5.4+
Fixes: 67f695134703 ("ipv6: Move setting default metric for routes")
Co-developed-by: Fan Yu <fan.yu9@zte.com.cn>
Signed-off-by: Fan Yu <fan.yu9@zte.com.cn>
Signed-off-by: xu xin <xu.xin16@zte.com.cn>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20240514201102055dD2Ba45qKbLlUMxu_DTHP@zte.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/route.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -4446,7 +4446,7 @@ static void rtmsg_to_fib6_config(struct
.fc_table = l3mdev_fib_table_by_index(net, rtmsg->rtmsg_ifindex) ?
: RT6_TABLE_MAIN,
.fc_ifindex = rtmsg->rtmsg_ifindex,
- .fc_metric = rtmsg->rtmsg_metric ? : IP6_RT_PRIO_USER,
+ .fc_metric = rtmsg->rtmsg_metric,
.fc_expires = rtmsg->rtmsg_info,
.fc_dst_len = rtmsg->rtmsg_dst_len,
.fc_src_len = rtmsg->rtmsg_src_len,
@@ -4476,6 +4476,9 @@ int ipv6_route_ioctl(struct net *net, un
rtnl_lock();
switch (cmd) {
case SIOCADDRT:
+ /* Only do the default setting of fc_metric in route adding */
+ if (cfg.fc_metric == 0)
+ cfg.fc_metric = IP6_RT_PRIO_USER;
err = ip6_route_add(&cfg, GFP_KERNEL, NULL);
break;
case SIOCDELRT:
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 083/157] net/9p: fix uninit-value in p9_client_rpc()
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (81 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 082/157] net/ipv6: Fix route deleting failure when metric equals 0 Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 084/157] net/tcp: Dont consider TCP_CLOSE in TCP_AO_ESTABLISHED Greg Kroah-Hartman
` (83 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Nikita Zhandarovich,
Christian Schoenebeck, Dominique Martinet,
syzbot+ff14db38f56329ef68df
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
commit 25460d6f39024cc3b8241b14c7ccf0d6f11a736a upstream.
Syzbot with the help of KMSAN reported the following error:
BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]
BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
trace_9p_client_res include/trace/events/9p.h:146 [inline]
p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
legacy_get_tree+0x114/0x290 fs/fs_context.c:662
vfs_get_tree+0xa7/0x570 fs/super.c:1797
do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
path_mount+0x742/0x1f20 fs/namespace.c:3679
do_mount fs/namespace.c:3692 [inline]
__do_sys_mount fs/namespace.c:3898 [inline]
__se_sys_mount+0x725/0x810 fs/namespace.c:3875
__x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
do_syscall_64+0xd5/0x1f0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was created at:
__alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598
__alloc_pages_node include/linux/gfp.h:238 [inline]
alloc_pages_node include/linux/gfp.h:261 [inline]
alloc_slab_page mm/slub.c:2175 [inline]
allocate_slab mm/slub.c:2338 [inline]
new_slab+0x2de/0x1400 mm/slub.c:2391
___slab_alloc+0x1184/0x33d0 mm/slub.c:3525
__slab_alloc mm/slub.c:3610 [inline]
__slab_alloc_node mm/slub.c:3663 [inline]
slab_alloc_node mm/slub.c:3835 [inline]
kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852
p9_tag_alloc net/9p/client.c:278 [inline]
p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641
p9_client_rpc+0x27e/0x1340 net/9p/client.c:688
p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
legacy_get_tree+0x114/0x290 fs/fs_context.c:662
vfs_get_tree+0xa7/0x570 fs/super.c:1797
do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
path_mount+0x742/0x1f20 fs/namespace.c:3679
do_mount fs/namespace.c:3692 [inline]
__do_sys_mount fs/namespace.c:3898 [inline]
__se_sys_mount+0x725/0x810 fs/namespace.c:3875
__x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
do_syscall_64+0xd5/0x1f0
entry_SYSCALL_64_after_hwframe+0x6d/0x75
If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag
will not be properly initialized. However, trace_9p_client_res()
ends up trying to print it out anyway before p9_client_rpc()
finishes.
Fix this issue by assigning default values to p9_fcall fields
such as 'tag' and (just in case KMSAN unearths something new) 'id'
during the tag allocation stage.
Reported-and-tested-by: syzbot+ff14db38f56329ef68df@syzkaller.appspotmail.com
Fixes: 348b59012e5c ("net/9p: Convert net/9p protocol dumps to tracepoints")
Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
Cc: stable@vger.kernel.org
Message-ID: <20240408141039.30428-1-n.zhandarovich@fintech.ru>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/9p/client.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -235,6 +235,8 @@ static int p9_fcall_init(struct p9_clien
if (!fc->sdata)
return -ENOMEM;
fc->capacity = alloc_msize;
+ fc->id = 0;
+ fc->tag = P9_NOTAG;
return 0;
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 084/157] net/tcp: Dont consider TCP_CLOSE in TCP_AO_ESTABLISHED
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (82 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 083/157] net/9p: fix uninit-value in p9_client_rpc() Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 085/157] selftests: net: lib: support errexit with busywait Greg Kroah-Hartman
` (82 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Dmitry Safonov, Jakub Kicinski
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Safonov <0x7f454c46@gmail.com>
commit 33700a0c9b562700c28d31360a5f04508f459a45 upstream.
TCP_CLOSE may or may not have current/rnext keys and should not be
considered "established". The fast-path for TCP_CLOSE is
SKB_DROP_REASON_TCP_CLOSE. This is what tcp_rcv_state_process() does
anyways. Add an early drop path to not spend any time verifying
segment signatures for sockets in TCP_CLOSE state.
Cc: stable@vger.kernel.org # v6.7
Fixes: 0a3a809089eb ("net/tcp: Verify inbound TCP-AO signed segments")
Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com>
Link: https://lore.kernel.org/r/20240529-tcp_ao-sk_state-v1-1-d69b5d323c52@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/net/tcp_ao.h | 7 ++++---
net/ipv4/tcp_ao.c | 13 +++++++++----
2 files changed, 13 insertions(+), 7 deletions(-)
--- a/include/net/tcp_ao.h
+++ b/include/net/tcp_ao.h
@@ -86,7 +86,8 @@ static inline int tcp_ao_sizeof_key(cons
struct tcp_ao_info {
/* List of tcp_ao_key's */
struct hlist_head head;
- /* current_key and rnext_key aren't maintained on listen sockets.
+ /* current_key and rnext_key are maintained on sockets
+ * in TCP_AO_ESTABLISHED states.
* Their purpose is to cache keys on established connections,
* saving needless lookups. Never dereference any of them from
* listen sockets.
@@ -201,9 +202,9 @@ struct tcp6_ao_context {
};
struct tcp_sigpool;
+/* Established states are fast-path and there always is current_key/rnext_key */
#define TCP_AO_ESTABLISHED (TCPF_ESTABLISHED | TCPF_FIN_WAIT1 | TCPF_FIN_WAIT2 | \
- TCPF_CLOSE | TCPF_CLOSE_WAIT | \
- TCPF_LAST_ACK | TCPF_CLOSING)
+ TCPF_CLOSE_WAIT | TCPF_LAST_ACK | TCPF_CLOSING)
int tcp_ao_transmit_skb(struct sock *sk, struct sk_buff *skb,
struct tcp_ao_key *key, struct tcphdr *th,
--- a/net/ipv4/tcp_ao.c
+++ b/net/ipv4/tcp_ao.c
@@ -933,6 +933,7 @@ tcp_inbound_ao_hash(struct sock *sk, con
struct tcp_ao_key *key;
__be32 sisn, disn;
u8 *traffic_key;
+ int state;
u32 sne = 0;
info = rcu_dereference(tcp_sk(sk)->ao_info);
@@ -948,8 +949,9 @@ tcp_inbound_ao_hash(struct sock *sk, con
disn = 0;
}
+ state = READ_ONCE(sk->sk_state);
/* Fast-path */
- if (likely((1 << sk->sk_state) & TCP_AO_ESTABLISHED)) {
+ if (likely((1 << state) & TCP_AO_ESTABLISHED)) {
enum skb_drop_reason err;
struct tcp_ao_key *current_key;
@@ -988,6 +990,9 @@ tcp_inbound_ao_hash(struct sock *sk, con
return SKB_NOT_DROPPED_YET;
}
+ if (unlikely(state == TCP_CLOSE))
+ return SKB_DROP_REASON_TCP_CLOSE;
+
/* Lookup key based on peer address and keyid.
* current_key and rnext_key must not be used on tcp listen
* sockets as otherwise:
@@ -1001,7 +1006,7 @@ tcp_inbound_ao_hash(struct sock *sk, con
if (th->syn && !th->ack)
goto verify_hash;
- if ((1 << sk->sk_state) & (TCPF_LISTEN | TCPF_NEW_SYN_RECV)) {
+ if ((1 << state) & (TCPF_LISTEN | TCPF_NEW_SYN_RECV)) {
/* Make the initial syn the likely case here */
if (unlikely(req)) {
sne = tcp_ao_compute_sne(0, tcp_rsk(req)->rcv_isn,
@@ -1018,14 +1023,14 @@ tcp_inbound_ao_hash(struct sock *sk, con
/* no way to figure out initial sisn/disn - drop */
return SKB_DROP_REASON_TCP_FLAGS;
}
- } else if ((1 << sk->sk_state) & (TCPF_SYN_SENT | TCPF_SYN_RECV)) {
+ } else if ((1 << state) & (TCPF_SYN_SENT | TCPF_SYN_RECV)) {
disn = info->lisn;
if (th->syn || th->rst)
sisn = th->seq;
else
sisn = info->risn;
} else {
- WARN_ONCE(1, "TCP-AO: Unexpected sk_state %d", sk->sk_state);
+ WARN_ONCE(1, "TCP-AO: Unexpected sk_state %d", state);
return SKB_DROP_REASON_TCP_AOFAILURE;
}
verify_hash:
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 085/157] selftests: net: lib: support errexit with busywait
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (83 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 084/157] net/tcp: Dont consider TCP_CLOSE in TCP_AO_ESTABLISHED Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 086/157] selftests: net: lib: avoid error removing empty netns name Greg Kroah-Hartman
` (81 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Geliang Tang, Matthieu Baerts (NGI0),
Hangbin Liu, Jakub Kicinski
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthieu Baerts (NGI0) <matttbe@kernel.org>
commit 41b02ea4c0adfcc6761fbfed42c3ce6b6412d881 upstream.
If errexit is enabled ('set -e'), loopy_wait -- or busywait and others
using it -- will stop after the first failure.
Note that if the returned status of loopy_wait is checked, and even if
errexit is enabled, Bash will not stop at the first error.
Fixes: 25ae948b4478 ("selftests/net: add lib.sh")
Cc: stable@vger.kernel.org
Acked-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
Link: https://lore.kernel.org/r/20240605-upstream-net-20240605-selftests-net-lib-fixes-v1-1-b3afadd368c9@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/testing/selftests/net/lib.sh | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/tools/testing/selftests/net/lib.sh
+++ b/tools/testing/selftests/net/lib.sh
@@ -63,9 +63,7 @@ loopy_wait()
while true
do
local out
- out=$("$@")
- local ret=$?
- if ((!ret)); then
+ if out=$("$@"); then
echo -n "$out"
return 0
fi
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 086/157] selftests: net: lib: avoid error removing empty netns name
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (84 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 085/157] selftests: net: lib: support errexit with busywait Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 087/157] mm/ksm: fix ksm_pages_scanned accounting Greg Kroah-Hartman
` (80 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Geliang Tang, Matthieu Baerts (NGI0),
Petr Machata, Hangbin Liu, Jakub Kicinski
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthieu Baerts (NGI0) <matttbe@kernel.org>
commit 79322174bcc780b99795cb89d237b26006a8b94b upstream.
If there is an error to create the first netns with 'setup_ns()',
'cleanup_ns()' will be called with an empty string as first parameter.
The consequences is that 'cleanup_ns()' will try to delete an invalid
netns, and wait 20 seconds if the netns list is empty.
Instead of just checking if the name is not empty, convert the string
separated by spaces to an array. Manipulating the array is cleaner, and
calling 'cleanup_ns()' with an empty array will be a no-op.
Fixes: 25ae948b4478 ("selftests/net: add lib.sh")
Cc: stable@vger.kernel.org
Acked-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
Link: https://lore.kernel.org/r/20240605-upstream-net-20240605-selftests-net-lib-fixes-v1-2-b3afadd368c9@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/testing/selftests/net/lib.sh | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
--- a/tools/testing/selftests/net/lib.sh
+++ b/tools/testing/selftests/net/lib.sh
@@ -10,7 +10,7 @@ BUSYWAIT_TIMEOUT=$((WAIT_TIMEOUT * 1000)
# Kselftest framework requirement - SKIP code is 4.
ksft_skip=4
# namespace list created by setup_ns
-NS_LIST=""
+NS_LIST=()
##############################################################################
# Helpers
@@ -133,6 +133,7 @@ cleanup_ns()
fi
for ns in "$@"; do
+ [ -z "${ns}" ] && continue
ip netns delete "${ns}" &> /dev/null
if ! busywait $BUSYWAIT_TIMEOUT ip netns list \| grep -vq "^$ns$" &> /dev/null; then
echo "Warn: Failed to remove namespace $ns"
@@ -146,7 +147,7 @@ cleanup_ns()
cleanup_all_ns()
{
- cleanup_ns $NS_LIST
+ cleanup_ns "${NS_LIST[@]}"
}
# setup netns with given names as prefix. e.g
@@ -155,7 +156,7 @@ setup_ns()
{
local ns=""
local ns_name=""
- local ns_list=""
+ local ns_list=()
local ns_exist=
for ns_name in "$@"; do
# Some test may setup/remove same netns multi times
@@ -171,13 +172,13 @@ setup_ns()
if ! ip netns add "$ns"; then
echo "Failed to create namespace $ns_name"
- cleanup_ns "$ns_list"
+ cleanup_ns "${ns_list[@]}"
return $ksft_skip
fi
ip -n "$ns" link set lo up
- ! $ns_exist && ns_list="$ns_list $ns"
+ ! $ns_exist && ns_list+=("$ns")
done
- NS_LIST="$NS_LIST $ns_list"
+ NS_LIST+=("${ns_list[@]}")
}
tc_rule_stats_get()
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 087/157] mm/ksm: fix ksm_pages_scanned accounting
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (85 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 086/157] selftests: net: lib: avoid error removing empty netns name Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 088/157] mm/ksm: fix ksm_zero_pages accounting Greg Kroah-Hartman
` (79 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Chengming Zhou, David Hildenbrand,
xu xin, Andrea Arcangeli, Hugh Dickins, Ran Xiaokai,
Stefan Roesch, Yang Yang, Andrew Morton
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chengming Zhou <chengming.zhou@linux.dev>
commit 730cdc2c72c6905a2eda2fccbbf67dcef1206590 upstream.
Patch series "mm/ksm: fix some accounting problems", v3.
We encountered some abnormal ksm_pages_scanned and ksm_zero_pages during
some random tests.
1. ksm_pages_scanned unchanged even ksmd scanning has progress.
2. ksm_zero_pages maybe -1 in some rare cases.
This patch (of 2):
During testing, I found ksm_pages_scanned is unchanged although the
scan_get_next_rmap_item() did return valid rmap_item that is not NULL.
The reason is the scan_get_next_rmap_item() will return NULL after a full
scan, so ksm_do_scan() just return without accounting of the
ksm_pages_scanned.
Fix it by just putting ksm_pages_scanned accounting in that loop, and it
will be accounted more timely if that loop would last for a long time.
Link: https://lkml.kernel.org/r/20240528-b4-ksm-counters-v3-0-34bb358fdc13@linux.dev
Link: https://lkml.kernel.org/r/20240528-b4-ksm-counters-v3-1-34bb358fdc13@linux.dev
Fixes: b348b5fe2b5f ("mm/ksm: add pages scanned metric")
Signed-off-by: Chengming Zhou <chengming.zhou@linux.dev>
Acked-by: David Hildenbrand <david@redhat.com>
Reviewed-by: xu xin <xu.xin16@zte.com.cn>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Ran Xiaokai <ran.xiaokai@zte.com.cn>
Cc: Stefan Roesch <shr@devkernel.io>
Cc: Yang Yang <yang.yang29@zte.com.cn>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/ksm.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -2747,18 +2747,16 @@ static void ksm_do_scan(unsigned int sca
{
struct ksm_rmap_item *rmap_item;
struct page *page;
- unsigned int npages = scan_npages;
- while (npages-- && likely(!freezing(current))) {
+ while (scan_npages-- && likely(!freezing(current))) {
cond_resched();
rmap_item = scan_get_next_rmap_item(&page);
if (!rmap_item)
return;
cmp_and_merge_page(page, rmap_item);
put_page(page);
+ ksm_pages_scanned++;
}
-
- ksm_pages_scanned += scan_npages - npages;
}
static int ksmd_should_run(void)
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 088/157] mm/ksm: fix ksm_zero_pages accounting
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (86 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 087/157] mm/ksm: fix ksm_pages_scanned accounting Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 089/157] kmsan: do not wipe out origin when doing partial unpoisoning Greg Kroah-Hartman
` (78 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Chengming Zhou, David Hildenbrand,
Andrea Arcangeli, Hugh Dickins, Ran Xiaokai, Stefan Roesch,
xu xin, Yang Yang, Andrew Morton
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chengming Zhou <chengming.zhou@linux.dev>
commit c2dc78b86e0821ecf9a9d0c35dba2618279a5bb6 upstream.
We normally ksm_zero_pages++ in ksmd when page is merged with zero page,
but ksm_zero_pages-- is done from page tables side, where there is no any
accessing protection of ksm_zero_pages.
So we can read very exceptional value of ksm_zero_pages in rare cases,
such as -1, which is very confusing to users.
Fix it by changing to use atomic_long_t, and the same case with the
mm->ksm_zero_pages.
Link: https://lkml.kernel.org/r/20240528-b4-ksm-counters-v3-2-34bb358fdc13@linux.dev
Fixes: e2942062e01d ("ksm: count all zero pages placed by KSM")
Fixes: 6080d19f0704 ("ksm: add ksm zero pages for each process")
Signed-off-by: Chengming Zhou <chengming.zhou@linux.dev>
Acked-by: David Hildenbrand <david@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Ran Xiaokai <ran.xiaokai@zte.com.cn>
Cc: Stefan Roesch <shr@devkernel.io>
Cc: xu xin <xu.xin16@zte.com.cn>
Cc: Yang Yang <yang.yang29@zte.com.cn>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/proc/base.c | 2 +-
include/linux/ksm.h | 17 ++++++++++++++---
include/linux/mm_types.h | 2 +-
mm/ksm.c | 11 +++++------
4 files changed, 21 insertions(+), 11 deletions(-)
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -3214,7 +3214,7 @@ static int proc_pid_ksm_stat(struct seq_
mm = get_task_mm(task);
if (mm) {
seq_printf(m, "ksm_rmap_items %lu\n", mm->ksm_rmap_items);
- seq_printf(m, "ksm_zero_pages %lu\n", mm->ksm_zero_pages);
+ seq_printf(m, "ksm_zero_pages %ld\n", mm_ksm_zero_pages(mm));
seq_printf(m, "ksm_merging_pages %lu\n", mm->ksm_merging_pages);
seq_printf(m, "ksm_process_profit %ld\n", ksm_process_profit(mm));
mmput(mm);
--- a/include/linux/ksm.h
+++ b/include/linux/ksm.h
@@ -33,16 +33,27 @@ void __ksm_exit(struct mm_struct *mm);
*/
#define is_ksm_zero_pte(pte) (is_zero_pfn(pte_pfn(pte)) && pte_dirty(pte))
-extern unsigned long ksm_zero_pages;
+extern atomic_long_t ksm_zero_pages;
+
+static inline void ksm_map_zero_page(struct mm_struct *mm)
+{
+ atomic_long_inc(&ksm_zero_pages);
+ atomic_long_inc(&mm->ksm_zero_pages);
+}
static inline void ksm_might_unmap_zero_page(struct mm_struct *mm, pte_t pte)
{
if (is_ksm_zero_pte(pte)) {
- ksm_zero_pages--;
- mm->ksm_zero_pages--;
+ atomic_long_dec(&ksm_zero_pages);
+ atomic_long_dec(&mm->ksm_zero_pages);
}
}
+static inline long mm_ksm_zero_pages(struct mm_struct *mm)
+{
+ return atomic_long_read(&mm->ksm_zero_pages);
+}
+
static inline int ksm_fork(struct mm_struct *mm, struct mm_struct *oldmm)
{
int ret;
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -988,7 +988,7 @@ struct mm_struct {
* Represent how many empty pages are merged with kernel zero
* pages when enabling KSM use_zero_pages.
*/
- unsigned long ksm_zero_pages;
+ atomic_long_t ksm_zero_pages;
#endif /* CONFIG_KSM */
#ifdef CONFIG_LRU_GEN_WALKS_MMU
struct {
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -296,7 +296,7 @@ static bool ksm_use_zero_pages __read_mo
static bool ksm_smart_scan = true;
/* The number of zero pages which is placed by KSM */
-unsigned long ksm_zero_pages;
+atomic_long_t ksm_zero_pages = ATOMIC_LONG_INIT(0);
/* The number of pages that have been skipped due to "smart scanning" */
static unsigned long ksm_pages_skipped;
@@ -1428,8 +1428,7 @@ static int replace_page(struct vm_area_s
* the dirty bit in zero page's PTE is set.
*/
newpte = pte_mkdirty(pte_mkspecial(pfn_pte(page_to_pfn(kpage), vma->vm_page_prot)));
- ksm_zero_pages++;
- mm->ksm_zero_pages++;
+ ksm_map_zero_page(mm);
/*
* We're replacing an anonymous page with a zero page, which is
* not anonymous. We need to do proper accounting otherwise we
@@ -3368,7 +3367,7 @@ static void wait_while_offlining(void)
#ifdef CONFIG_PROC_FS
long ksm_process_profit(struct mm_struct *mm)
{
- return (long)(mm->ksm_merging_pages + mm->ksm_zero_pages) * PAGE_SIZE -
+ return (long)(mm->ksm_merging_pages + mm_ksm_zero_pages(mm)) * PAGE_SIZE -
mm->ksm_rmap_items * sizeof(struct ksm_rmap_item);
}
#endif /* CONFIG_PROC_FS */
@@ -3657,7 +3656,7 @@ KSM_ATTR_RO(pages_skipped);
static ssize_t ksm_zero_pages_show(struct kobject *kobj,
struct kobj_attribute *attr, char *buf)
{
- return sysfs_emit(buf, "%ld\n", ksm_zero_pages);
+ return sysfs_emit(buf, "%ld\n", atomic_long_read(&ksm_zero_pages));
}
KSM_ATTR_RO(ksm_zero_pages);
@@ -3666,7 +3665,7 @@ static ssize_t general_profit_show(struc
{
long general_profit;
- general_profit = (ksm_pages_sharing + ksm_zero_pages) * PAGE_SIZE -
+ general_profit = (ksm_pages_sharing + atomic_long_read(&ksm_zero_pages)) * PAGE_SIZE -
ksm_rmap_items * sizeof(struct ksm_rmap_item);
return sysfs_emit(buf, "%ld\n", general_profit);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 089/157] kmsan: do not wipe out origin when doing partial unpoisoning
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (87 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 088/157] mm/ksm: fix ksm_zero_pages accounting Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 090/157] tpm_tis: Do *not* flush uninitialized work Greg Kroah-Hartman
` (77 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Alexander Potapenko,
Brian Johannesmeyer, Marco Elver, Dmitry Vyukov, Kees Cook,
Andrew Morton
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Potapenko <glider@google.com>
commit 2ef3cec44c60ae171b287db7fc2aa341586d65ba upstream.
As noticed by Brian, KMSAN should not be zeroing the origin when
unpoisoning parts of a four-byte uninitialized value, e.g.:
char a[4];
kmsan_unpoison_memory(a, 1);
This led to false negatives, as certain poisoned values could receive zero
origins, preventing those values from being reported.
To fix the problem, check that kmsan_internal_set_shadow_origin() writes
zero origins only to slots which have zero shadow.
Link: https://lkml.kernel.org/r/20240528104807.738758-1-glider@google.com
Fixes: f80be4571b19 ("kmsan: add KMSAN runtime core")
Signed-off-by: Alexander Potapenko <glider@google.com>
Reported-by: Brian Johannesmeyer <bjohannesmeyer@gmail.com>
Link: https://lore.kernel.org/lkml/20240524232804.1984355-1-bjohannesmeyer@gmail.com/T/
Reviewed-by: Marco Elver <elver@google.com>
Tested-by: Brian Johannesmeyer <bjohannesmeyer@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/kmsan/core.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
--- a/mm/kmsan/core.c
+++ b/mm/kmsan/core.c
@@ -196,8 +196,7 @@ void kmsan_internal_set_shadow_origin(vo
u32 origin, bool checked)
{
u64 address = (u64)addr;
- void *shadow_start;
- u32 *origin_start;
+ u32 *shadow_start, *origin_start;
size_t pad = 0;
KMSAN_WARN_ON(!kmsan_metadata_is_contiguous(addr, size));
@@ -225,8 +224,16 @@ void kmsan_internal_set_shadow_origin(vo
origin_start =
(u32 *)kmsan_get_metadata((void *)address, KMSAN_META_ORIGIN);
- for (int i = 0; i < size / KMSAN_ORIGIN_SIZE; i++)
- origin_start[i] = origin;
+ /*
+ * If the new origin is non-zero, assume that the shadow byte is also non-zero,
+ * and unconditionally overwrite the old origin slot.
+ * If the new origin is zero, overwrite the old origin slot iff the
+ * corresponding shadow slot is zero.
+ */
+ for (int i = 0; i < size / KMSAN_ORIGIN_SIZE; i++) {
+ if (origin || !shadow_start[i])
+ origin_start[i] = origin;
+ }
}
struct page *kmsan_vmalloc_to_page_or_null(void *vaddr)
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 090/157] tpm_tis: Do *not* flush uninitialized work
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (88 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 089/157] kmsan: do not wipe out origin when doing partial unpoisoning Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 091/157] cpufreq: amd-pstate: Fix the inconsistency in max frequency units Greg Kroah-Hartman
` (76 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Jan Beulich, Jarkko Sakkinen
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Beulich <jbeulich@suse.com>
commit 0ea00e249ca992adee54dc71a526ee70ef109e40 upstream.
tpm_tis_core_init() may fail before tpm_tis_probe_irq_single() is
called, in which case tpm_tis_remove() unconditionally calling
flush_work() is triggering a warning for .func still being NULL.
Cc: stable@vger.kernel.org # v6.5+
Fixes: 481c2d14627d ("tpm,tpm_tis: Disable interrupts after 1000 unhandled IRQs")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/char/tpm/tpm_tis_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -1020,7 +1020,8 @@ void tpm_tis_remove(struct tpm_chip *chi
interrupt = 0;
tpm_tis_write32(priv, reg, ~TPM_GLOBAL_INT_ENABLE & interrupt);
- flush_work(&priv->free_irq_work);
+ if (priv->free_irq_work.func)
+ flush_work(&priv->free_irq_work);
tpm_tis_clkrun_enable(chip, false);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 091/157] cpufreq: amd-pstate: Fix the inconsistency in max frequency units
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (89 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 090/157] tpm_tis: Do *not* flush uninitialized work Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 092/157] intel_th: pci: Add Meteor Lake-S CPU support Greg Kroah-Hartman
` (75 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Dhananjay Ugwekar, Mario Limonciello,
Gautham R. Shenoy, Peter Jung, Rafael J. Wysocki
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com>
commit e4731baaf29438508197d3a8a6d4f5a8c51663f8 upstream.
The nominal frequency in cpudata is maintained in MHz whereas all other
frequencies are in KHz. This means we have to convert nominal frequency
value to KHz before we do any interaction with other frequency values.
In amd_pstate_set_boost(), this conversion from MHz to KHz is missed,
fix that.
Tested on a AMD Zen4 EPYC server
Before:
$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq | uniq
2151
$ cat /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_min_freq | uniq
400000
$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq | uniq
2151
409422
After:
$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq | uniq
2151000
$ cat /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_min_freq | uniq
400000
$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq | uniq
2151000
1799527
Fixes: ec437d71db77 ("cpufreq: amd-pstate: Introduce a new AMD P-State driver to support future processors")
Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com>
Acked-by: Mario Limonciello <mario.limonciello@amd.com>
Acked-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
Tested-by: Peter Jung <ptr1337@cachyos.org>
Cc: 5.17+ <stable@vger.kernel.org> # 5.17+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/cpufreq/amd-pstate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/cpufreq/amd-pstate.c
+++ b/drivers/cpufreq/amd-pstate.c
@@ -705,7 +705,7 @@ static int amd_pstate_set_boost(struct c
if (state)
policy->cpuinfo.max_freq = cpudata->max_freq;
else
- policy->cpuinfo.max_freq = cpudata->nominal_freq;
+ policy->cpuinfo.max_freq = cpudata->nominal_freq * 1000;
policy->max = policy->cpuinfo.max_freq;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 092/157] intel_th: pci: Add Meteor Lake-S CPU support
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (90 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 091/157] cpufreq: amd-pstate: Fix the inconsistency in max frequency units Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 093/157] rtla/timerlat: Fix histogram report when a cpu count is 0 Greg Kroah-Hartman
` (74 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Alexander Shishkin, Andy Shevchenko,
stable
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
commit a4f813c3ec9d1c32bc402becd1f011b3904dd699 upstream.
Add support for the Trace Hub in Meteor Lake-S CPU.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20240429130119.1518073-15-alexander.shishkin@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hwtracing/intel_th/pci.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/hwtracing/intel_th/pci.c
+++ b/drivers/hwtracing/intel_th/pci.c
@@ -290,6 +290,11 @@ static const struct pci_device_id intel_
.driver_data = (kernel_ulong_t)&intel_th_2x,
},
{
+ /* Meteor Lake-S CPU */
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xae24),
+ .driver_data = (kernel_ulong_t)&intel_th_2x,
+ },
+ {
/* Raptor Lake-S */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x7a26),
.driver_data = (kernel_ulong_t)&intel_th_2x,
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 093/157] rtla/timerlat: Fix histogram report when a cpu count is 0
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (91 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 092/157] intel_th: pci: Add Meteor Lake-S CPU support Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 094/157] sparc64: Fix number of online CPUs Greg Kroah-Hartman
` (73 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Daniel Bristot de Oliveria,
John Kacur
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Kacur <jkacur@redhat.com>
commit 01b05fc0e5f3aec443a9a8ffa0022cbca2fd3608 upstream.
On short runs it is possible to get no samples on a cpu, like this:
# rtla timerlat hist -u -T50
Index IRQ-001 Thr-001 Usr-001 IRQ-002 Thr-002 Usr-002
2 1 0 0 0 0 0
33 0 1 0 0 0 0
36 0 0 1 0 0 0
49 0 0 0 1 0 0
52 0 0 0 0 1 0
over: 0 0 0 0 0 0
count: 1 1 1 1 1 0
min: 2 33 36 49 52 18446744073709551615
avg: 2 33 36 49 52 -
max: 2 33 36 49 52 0
rtla timerlat hit stop tracing
IRQ handler delay: (exit from idle) 48.21 us (91.09 %)
IRQ latency: 49.11 us
Timerlat IRQ duration: 2.17 us (4.09 %)
Blocking thread: 1.01 us (1.90 %)
swapper/2:0 1.01 us
------------------------------------------------------------------------
Thread latency: 52.93 us (100%)
Max timerlat IRQ latency from idle: 49.11 us in cpu 2
Note, the value 18446744073709551615 is the same as ~0.
Fix this by reporting no results for the min, avg and max if the count
is 0.
Link: https://lkml.kernel.org/r/20240510190318.44295-1-jkacur@redhat.com
Cc: stable@vger.kernel.org
Fixes: 1eeb6328e8b3 ("rtla/timerlat: Add timerlat hist mode")
Suggested-by: Daniel Bristot de Oliveria <bristot@kernel.org>
Signed-off-by: John Kacur <jkacur@redhat.com>
Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/tracing/rtla/src/timerlat_hist.c | 68 ++++++++++++++++++++++-----------
1 file changed, 46 insertions(+), 22 deletions(-)
--- a/tools/tracing/rtla/src/timerlat_hist.c
+++ b/tools/tracing/rtla/src/timerlat_hist.c
@@ -324,17 +324,29 @@ timerlat_print_summary(struct timerlat_h
if (!data->hist[cpu].irq_count && !data->hist[cpu].thread_count)
continue;
- if (!params->no_irq)
- trace_seq_printf(trace->seq, "%9llu ",
- data->hist[cpu].min_irq);
-
- if (!params->no_thread)
- trace_seq_printf(trace->seq, "%9llu ",
- data->hist[cpu].min_thread);
-
- if (params->user_hist)
- trace_seq_printf(trace->seq, "%9llu ",
- data->hist[cpu].min_user);
+ if (!params->no_irq) {
+ if (data->hist[cpu].irq_count)
+ trace_seq_printf(trace->seq, "%9llu ",
+ data->hist[cpu].min_irq);
+ else
+ trace_seq_printf(trace->seq, " - ");
+ }
+
+ if (!params->no_thread) {
+ if (data->hist[cpu].thread_count)
+ trace_seq_printf(trace->seq, "%9llu ",
+ data->hist[cpu].min_thread);
+ else
+ trace_seq_printf(trace->seq, " - ");
+ }
+
+ if (params->user_hist) {
+ if (data->hist[cpu].user_count)
+ trace_seq_printf(trace->seq, "%9llu ",
+ data->hist[cpu].min_user);
+ else
+ trace_seq_printf(trace->seq, " - ");
+ }
}
trace_seq_printf(trace->seq, "\n");
@@ -384,17 +396,29 @@ timerlat_print_summary(struct timerlat_h
if (!data->hist[cpu].irq_count && !data->hist[cpu].thread_count)
continue;
- if (!params->no_irq)
- trace_seq_printf(trace->seq, "%9llu ",
- data->hist[cpu].max_irq);
-
- if (!params->no_thread)
- trace_seq_printf(trace->seq, "%9llu ",
- data->hist[cpu].max_thread);
-
- if (params->user_hist)
- trace_seq_printf(trace->seq, "%9llu ",
- data->hist[cpu].max_user);
+ if (!params->no_irq) {
+ if (data->hist[cpu].irq_count)
+ trace_seq_printf(trace->seq, "%9llu ",
+ data->hist[cpu].max_irq);
+ else
+ trace_seq_printf(trace->seq, " - ");
+ }
+
+ if (!params->no_thread) {
+ if (data->hist[cpu].thread_count)
+ trace_seq_printf(trace->seq, "%9llu ",
+ data->hist[cpu].max_thread);
+ else
+ trace_seq_printf(trace->seq, " - ");
+ }
+
+ if (params->user_hist) {
+ if (data->hist[cpu].user_count)
+ trace_seq_printf(trace->seq, "%9llu ",
+ data->hist[cpu].max_user);
+ else
+ trace_seq_printf(trace->seq, " - ");
+ }
}
trace_seq_printf(trace->seq, "\n");
trace_seq_do_printf(trace->seq);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 094/157] sparc64: Fix number of online CPUs
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (92 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 093/157] rtla/timerlat: Fix histogram report when a cpu count is 0 Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 095/157] mm/hugetlb: do not call vma_add_reservation upon ENOMEM Greg Kroah-Hartman
` (72 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Sam Ravnborg, Nick Bowler,
Andreas Larsson, David S. Miller, Atish Patra, Bob Picco,
Vijay Kumar, Arnd Bergmann
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sam Ravnborg <sam@ravnborg.org>
commit 98937707fea8375e8acea0aaa0b68a956dd52719 upstream.
Nick Bowler reported:
When using newer kernels on my Ultra 60 with dual 450MHz UltraSPARC-II
CPUs, I noticed that only CPU 0 comes up, while older kernels (including
4.7) are working fine with both CPUs.
I bisected the failure to this commit:
9b2f753ec23710aa32c0d837d2499db92fe9115b is the first bad commit
commit 9b2f753ec23710aa32c0d837d2499db92fe9115b
Author: Atish Patra <atish.patra@oracle.com>
Date: Thu Sep 15 14:54:40 2016 -0600
sparc64: Fix cpu_possible_mask if nr_cpus is set
This is a small change that reverts very easily on top of 5.18: there is
just one trivial conflict. Once reverted, both CPUs work again.
Maybe this is related to the fact that the CPUs on this system are
numbered CPU0 and CPU2 (there is no CPU1)?
The current code that adjust cpu_possible based on nr_cpu_ids do not
take into account that CPU's may not come one after each other.
Move the chech to the function that setup the cpu_possible mask
so there is no need to adjust it later.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Fixes: 9b2f753ec237 ("sparc64: Fix cpu_possible_mask if nr_cpus is set")
Reported-by: Nick Bowler <nbowler@draconx.ca>
Tested-by: Nick Bowler <nbowler@draconx.ca>
Link: https://lore.kernel.org/sparclinux/20201009161924.c8f031c079dd852941307870@gmx.de/
Link: https://lore.kernel.org/all/CADyTPEwt=ZNams+1bpMB1F9w_vUdPsGCt92DBQxxq_VtaLoTdw@mail.gmail.com/
Cc: stable@vger.kernel.org # v4.8+
Cc: Andreas Larsson <andreas@gaisler.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Atish Patra <atish.patra@oracle.com>
Cc: Bob Picco <bob.picco@oracle.com>
Cc: Vijay Kumar <vijay.ac.kumar@oracle.com>
Cc: David S. Miller <davem@davemloft.net>
Reviewed-by: Andreas Larsson <andreas@gaisler.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20240330-sparc64-warnings-v1-9-37201023ee2f@ravnborg.org
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/sparc/include/asm/smp_64.h | 2 --
arch/sparc/kernel/prom_64.c | 4 +++-
arch/sparc/kernel/setup_64.c | 1 -
arch/sparc/kernel/smp_64.c | 14 --------------
4 files changed, 3 insertions(+), 18 deletions(-)
--- a/arch/sparc/include/asm/smp_64.h
+++ b/arch/sparc/include/asm/smp_64.h
@@ -47,7 +47,6 @@ void arch_send_call_function_ipi_mask(co
int hard_smp_processor_id(void);
#define raw_smp_processor_id() (current_thread_info()->cpu)
-void smp_fill_in_cpu_possible_map(void);
void smp_fill_in_sib_core_maps(void);
void __noreturn cpu_play_dead(void);
@@ -77,7 +76,6 @@ void __cpu_die(unsigned int cpu);
#define smp_fill_in_sib_core_maps() do { } while (0)
#define smp_fetch_global_regs() do { } while (0)
#define smp_fetch_global_pmu() do { } while (0)
-#define smp_fill_in_cpu_possible_map() do { } while (0)
#define smp_init_cpu_poke() do { } while (0)
#define scheduler_poke() do { } while (0)
--- a/arch/sparc/kernel/prom_64.c
+++ b/arch/sparc/kernel/prom_64.c
@@ -483,7 +483,9 @@ static void *record_one_cpu(struct devic
ncpus_probed++;
#ifdef CONFIG_SMP
set_cpu_present(cpuid, true);
- set_cpu_possible(cpuid, true);
+
+ if (num_possible_cpus() < nr_cpu_ids)
+ set_cpu_possible(cpuid, true);
#endif
return NULL;
}
--- a/arch/sparc/kernel/setup_64.c
+++ b/arch/sparc/kernel/setup_64.c
@@ -671,7 +671,6 @@ void __init setup_arch(char **cmdline_p)
paging_init();
init_sparc64_elf_hwcap();
- smp_fill_in_cpu_possible_map();
/*
* Once the OF device tree and MDESC have been setup and nr_cpus has
* been parsed, we know the list of possible cpus. Therefore we can
--- a/arch/sparc/kernel/smp_64.c
+++ b/arch/sparc/kernel/smp_64.c
@@ -1216,20 +1216,6 @@ void __init smp_setup_processor_id(void)
xcall_deliver_impl = hypervisor_xcall_deliver;
}
-void __init smp_fill_in_cpu_possible_map(void)
-{
- int possible_cpus = num_possible_cpus();
- int i;
-
- if (possible_cpus > nr_cpu_ids)
- possible_cpus = nr_cpu_ids;
-
- for (i = 0; i < possible_cpus; i++)
- set_cpu_possible(i, true);
- for (; i < NR_CPUS; i++)
- set_cpu_possible(i, false);
-}
-
void smp_fill_in_sib_core_maps(void)
{
unsigned int i;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 095/157] mm/hugetlb: do not call vma_add_reservation upon ENOMEM
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (93 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 094/157] sparc64: Fix number of online CPUs Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 096/157] mm/cma: drop incorrect alignment check in cma_init_reserved_mem Greg Kroah-Hartman
` (71 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Oscar Salvador, Breno Leitao,
Muchun Song, Andrew Morton, syzbot+d3fe2dc5ffe9380b714b
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oscar Salvador <osalvador@suse.de>
commit 8daf9c702ee7f825f0de8600abff764acfedea13 upstream.
sysbot reported a splat [1] on __unmap_hugepage_range(). This is because
vma_needs_reservation() can return -ENOMEM if
allocate_file_region_entries() fails to allocate the file_region struct
for the reservation.
Check for that and do not call vma_add_reservation() if that is the case,
otherwise region_abort() and region_del() will see that we do not have any
file_regions.
If we detect that vma_needs_reservation() returned -ENOMEM, we clear the
hugetlb_restore_reserve flag as if this reservation was still consumed, so
free_huge_folio() will not increment the resv count.
[1] https://lore.kernel.org/linux-mm/0000000000004096100617c58d54@google.com/T/#ma5983bc1ab18a54910da83416b3f89f3c7ee43aa
Link: https://lkml.kernel.org/r/20240528205323.20439-1-osalvador@suse.de
Fixes: df7a6d1f6405 ("mm/hugetlb: restore the reservation if needed")
Signed-off-by: Oscar Salvador <osalvador@suse.de>
Reported-and-tested-by: syzbot+d3fe2dc5ffe9380b714b@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-mm/0000000000004096100617c58d54@google.com/
Cc: Breno Leitao <leitao@debian.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/hugetlb.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -5774,8 +5774,20 @@ void __unmap_hugepage_range(struct mmu_g
* do_exit() will not see it, and will keep the reservation
* forever.
*/
- if (adjust_reservation && vma_needs_reservation(h, vma, address))
- vma_add_reservation(h, vma, address);
+ if (adjust_reservation) {
+ int rc = vma_needs_reservation(h, vma, address);
+
+ if (rc < 0)
+ /* Pressumably allocate_file_region_entries failed
+ * to allocate a file_region struct. Clear
+ * hugetlb_restore_reserve so that global reserve
+ * count will not be incremented by free_huge_folio.
+ * Act as if we consumed the reservation.
+ */
+ folio_clear_hugetlb_restore_reserve(page_folio(page));
+ else if (rc)
+ vma_add_reservation(h, vma, address);
+ }
tlb_remove_page_size(tlb, page, huge_page_size(h));
/*
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 096/157] mm/cma: drop incorrect alignment check in cma_init_reserved_mem
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (94 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 095/157] mm/hugetlb: do not call vma_add_reservation upon ENOMEM Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 097/157] mm/hugetlb: pass correct order_per_bit to cma_declare_contiguous_nid Greg Kroah-Hartman
` (70 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Frank van der Linden,
David Hildenbrand, Marek Szyprowski, Muchun Song, Roman Gushchin,
Andrew Morton
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Frank van der Linden <fvdl@google.com>
commit b174f139bdc8aaaf72f5b67ad1bd512c4868a87e upstream.
cma_init_reserved_mem uses IS_ALIGNED to check if the size represented by
one bit in the cma allocation bitmask is aligned with
CMA_MIN_ALIGNMENT_BYTES (pageblock size).
However, this is too strict, as this will fail if order_per_bit >
pageblock_order, which is a valid configuration.
We could check IS_ALIGNED both ways, but since both numbers are powers of
two, no check is needed at all.
Link: https://lkml.kernel.org/r/20240404162515.527802-1-fvdl@google.com
Fixes: de9e14eebf33 ("drivers: dma-contiguous: add initialization from device tree")
Signed-off-by: Frank van der Linden <fvdl@google.com>
Acked-by: David Hildenbrand <david@redhat.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/cma.c | 4 ----
1 file changed, 4 deletions(-)
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -182,10 +182,6 @@ int __init cma_init_reserved_mem(phys_ad
if (!size || !memblock_is_region_reserved(base, size))
return -EINVAL;
- /* alignment should be aligned with order_per_bit */
- if (!IS_ALIGNED(CMA_MIN_ALIGNMENT_PAGES, 1 << order_per_bit))
- return -EINVAL;
-
/* ensure minimal alignment required by mm core */
if (!IS_ALIGNED(base | size, CMA_MIN_ALIGNMENT_BYTES))
return -EINVAL;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 097/157] mm/hugetlb: pass correct order_per_bit to cma_declare_contiguous_nid
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (95 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 096/157] mm/cma: drop incorrect alignment check in cma_init_reserved_mem Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 098/157] mm: /proc/pid/smaps_rollup: avoid skipping vma after getting mmap_lock again Greg Kroah-Hartman
` (69 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Frank van der Linden, Roman Gushchin,
David Hildenbrand, Marek Szyprowski, Muchun Song, Andrew Morton
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Frank van der Linden <fvdl@google.com>
commit 55d134a7b499c77e7cfd0ee41046f3c376e791e5 upstream.
The hugetlb_cma code passes 0 in the order_per_bit argument to
cma_declare_contiguous_nid (the alignment, computed using the page order,
is correctly passed in).
This causes a bit in the cma allocation bitmap to always represent a 4k
page, making the bitmaps potentially very large, and slower.
It would create bitmaps that would be pretty big. E.g. for a 4k page
size on x86, hugetlb_cma=64G would mean a bitmap size of (64G / 4k) / 8
== 2M. With HUGETLB_PAGE_ORDER as order_per_bit, as intended, this
would be (64G / 2M) / 8 == 4k. So, that's quite a difference.
Also, this restricted the hugetlb_cma area to ((PAGE_SIZE <<
MAX_PAGE_ORDER) * 8) * PAGE_SIZE (e.g. 128G on x86) , since
bitmap_alloc uses normal page allocation, and is thus restricted by
MAX_PAGE_ORDER. Specifying anything about that would fail the CMA
initialization.
So, correctly pass in the order instead.
Link: https://lkml.kernel.org/r/20240404162515.527802-2-fvdl@google.com
Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages using cma")
Signed-off-by: Frank van der Linden <fvdl@google.com>
Acked-by: Roman Gushchin <roman.gushchin@linux.dev>
Acked-by: David Hildenbrand <david@redhat.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/hugetlb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -7879,9 +7879,9 @@ void __init hugetlb_cma_reserve(int orde
* huge page demotion.
*/
res = cma_declare_contiguous_nid(0, size, 0,
- PAGE_SIZE << HUGETLB_PAGE_ORDER,
- 0, false, name,
- &hugetlb_cma[nid], nid);
+ PAGE_SIZE << HUGETLB_PAGE_ORDER,
+ HUGETLB_PAGE_ORDER, false, name,
+ &hugetlb_cma[nid], nid);
if (res) {
pr_warn("hugetlb_cma: reservation failed: err %d, node %d",
res, nid);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 098/157] mm: /proc/pid/smaps_rollup: avoid skipping vma after getting mmap_lock again
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (96 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 097/157] mm/hugetlb: pass correct order_per_bit to cma_declare_contiguous_nid Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 099/157] mm/memory-failure: fix handling of dissolved but not taken off from buddy pages Greg Kroah-Hartman
` (68 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Yuanyuan Zhong, Mohamed Khalfella,
David Hildenbrand, Matthew Wilcox (Oracle), Andrew Morton
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yuanyuan Zhong <yzhong@purestorage.com>
commit 6d065f507d82307d6161ac75c025111fb8b08a46 upstream.
After switching smaps_rollup to use VMA iterator, searching for next entry
is part of the condition expression of the do-while loop. So the current
VMA needs to be addressed before the continue statement.
Otherwise, with some VMAs skipped, userspace observed memory
consumption from /proc/pid/smaps_rollup will be smaller than the sum of
the corresponding fields from /proc/pid/smaps.
Link: https://lkml.kernel.org/r/20240523183531.2535436-1-yzhong@purestorage.com
Fixes: c4c84f06285e ("fs/proc/task_mmu: stop using linked list and highest_vm_end")
Signed-off-by: Yuanyuan Zhong <yzhong@purestorage.com>
Reviewed-by: Mohamed Khalfella <mkhalfella@purestorage.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/proc/task_mmu.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -965,12 +965,17 @@ static int show_smaps_rollup(struct seq_
break;
/* Case 1 and 2 above */
- if (vma->vm_start >= last_vma_end)
+ if (vma->vm_start >= last_vma_end) {
+ smap_gather_stats(vma, &mss, 0);
+ last_vma_end = vma->vm_end;
continue;
+ }
/* Case 4 above */
- if (vma->vm_end > last_vma_end)
+ if (vma->vm_end > last_vma_end) {
smap_gather_stats(vma, &mss, last_vma_end);
+ last_vma_end = vma->vm_end;
+ }
}
} for_each_vma(vmi, vma);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 099/157] mm/memory-failure: fix handling of dissolved but not taken off from buddy pages
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (97 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 098/157] mm: /proc/pid/smaps_rollup: avoid skipping vma after getting mmap_lock again Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 100/157] mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL Greg Kroah-Hartman
` (67 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Miaohe Lin, Naoya Horiguchi,
Andrew Morton
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miaohe Lin <linmiaohe@huawei.com>
commit 8cf360b9d6a840700e06864236a01a883b34bbad upstream.
When I did memory failure tests recently, below panic occurs:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8cee00
flags: 0x6fffe0000000000(node=1|zone=2|lastcpupid=0x7fff)
raw: 06fffe0000000000 dead000000000100 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000000009 00000000ffffffff 0000000000000000
page dumped because: VM_BUG_ON_PAGE(!PageBuddy(page))
------------[ cut here ]------------
kernel BUG at include/linux/page-flags.h:1009!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:__del_page_from_free_list+0x151/0x180
RSP: 0018:ffffa49c90437998 EFLAGS: 00000046
RAX: 0000000000000035 RBX: 0000000000000009 RCX: ffff8dd8dfd1c9c8
RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff8dd8dfd1c9c0
RBP: ffffd901233b8000 R08: ffffffffab5511f8 R09: 0000000000008c69
R10: 0000000000003c15 R11: ffffffffab5511f8 R12: ffff8dd8fffc0c80
R13: 0000000000000001 R14: ffff8dd8fffc0c80 R15: 0000000000000009
FS: 00007ff916304740(0000) GS:ffff8dd8dfd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055eae50124c8 CR3: 00000008479e0000 CR4: 00000000000006f0
Call Trace:
<TASK>
__rmqueue_pcplist+0x23b/0x520
get_page_from_freelist+0x26b/0xe40
__alloc_pages_noprof+0x113/0x1120
__folio_alloc_noprof+0x11/0xb0
alloc_buddy_hugetlb_folio.isra.0+0x5a/0x130
__alloc_fresh_hugetlb_folio+0xe7/0x140
alloc_pool_huge_folio+0x68/0x100
set_max_huge_pages+0x13d/0x340
hugetlb_sysctl_handler_common+0xe8/0x110
proc_sys_call_handler+0x194/0x280
vfs_write+0x387/0x550
ksys_write+0x64/0xe0
do_syscall_64+0xc2/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ff916114887
RSP: 002b:00007ffec8a2fd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000055eae500e350 RCX: 00007ff916114887
RDX: 0000000000000004 RSI: 000055eae500e390 RDI: 0000000000000003
RBP: 000055eae50104c0 R08: 0000000000000000 R09: 000055eae50104c0
R10: 0000000000000077 R11: 0000000000000246 R12: 0000000000000004
R13: 0000000000000004 R14: 00007ff916216b80 R15: 00007ff916216a00
</TASK>
Modules linked in: mce_inject hwpoison_inject
---[ end trace 0000000000000000 ]---
And before the panic, there had an warning about bad page state:
BUG: Bad page state in process page-types pfn:8cee00
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8cee00
flags: 0x6fffe0000000000(node=1|zone=2|lastcpupid=0x7fff)
page_type: 0xffffff7f(buddy)
raw: 06fffe0000000000 ffffd901241c0008 ffffd901240f8008 0000000000000000
raw: 0000000000000000 0000000000000009 00000000ffffff7f 0000000000000000
page dumped because: nonzero mapcount
Modules linked in: mce_inject hwpoison_inject
CPU: 8 PID: 154211 Comm: page-types Not tainted 6.9.0-rc4-00499-g5544ec3178e2-dirty #22
Call Trace:
<TASK>
dump_stack_lvl+0x83/0xa0
bad_page+0x63/0xf0
free_unref_page+0x36e/0x5c0
unpoison_memory+0x50b/0x630
simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110
debugfs_attr_write+0x42/0x60
full_proxy_write+0x5b/0x80
vfs_write+0xcd/0x550
ksys_write+0x64/0xe0
do_syscall_64+0xc2/0x1d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f189a514887
RSP: 002b:00007ffdcd899718 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f189a514887
RDX: 0000000000000009 RSI: 00007ffdcd899730 RDI: 0000000000000003
RBP: 00007ffdcd8997a0 R08: 0000000000000000 R09: 00007ffdcd8994b2
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffdcda199a8
R13: 0000000000404af1 R14: 000000000040ad78 R15: 00007f189a7a5040
</TASK>
The root cause should be the below race:
memory_failure
try_memory_failure_hugetlb
me_huge_page
__page_handle_poison
dissolve_free_hugetlb_folio
drain_all_pages -- Buddy page can be isolated e.g. for compaction.
take_page_off_buddy -- Failed as page is not in the buddy list.
-- Page can be putback into buddy after compaction.
page_ref_inc -- Leads to buddy page with refcnt = 1.
Then unpoison_memory() can unpoison the page and send the buddy page back
into buddy list again leading to the above bad page state warning. And
bad_page() will call page_mapcount_reset() to remove PageBuddy from buddy
page leading to later VM_BUG_ON_PAGE(!PageBuddy(page)) when trying to
allocate this page.
Fix this issue by only treating __page_handle_poison() as successful when
it returns 1.
Link: https://lkml.kernel.org/r/20240523071217.1696196-1-linmiaohe@huawei.com
Fixes: ceaf8fbea79a ("mm, hwpoison: skip raw hwpoison page in freeing 1GB hugepage")
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/memory-failure.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1218,7 +1218,7 @@ static int me_huge_page(struct page_stat
* subpages.
*/
folio_put(folio);
- if (__page_handle_poison(p) >= 0) {
+ if (__page_handle_poison(p) > 0) {
page_ref_inc(p);
res = MF_RECOVERED;
} else {
@@ -2097,7 +2097,7 @@ retry:
*/
if (res == 0) {
folio_unlock(folio);
- if (__page_handle_poison(p) >= 0) {
+ if (__page_handle_poison(p) > 0) {
page_ref_inc(p);
res = MF_RECOVERED;
} else {
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 100/157] mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (98 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 099/157] mm/memory-failure: fix handling of dissolved but not taken off from buddy pages Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 101/157] selftests/mm: compaction_test: fix incorrect write of zero to nr_hugepages Greg Kroah-Hartman
` (66 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Hailong.Liu, Michal Hocko,
Barry Song, Oven, Barry Song, Uladzislau Rezki (Sony), Chao Yu,
Christoph Hellwig, Gao Xiang, Lorenzo Stoakes, Andrew Morton
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hailong.Liu <hailong.liu@oppo.com>
commit 8e0545c83d672750632f46e3f9ad95c48c91a0fc upstream.
commit a421ef303008 ("mm: allow !GFP_KERNEL allocations for kvmalloc")
includes support for __GFP_NOFAIL, but it presents a conflict with commit
dd544141b9eb ("vmalloc: back off when the current task is OOM-killed"). A
possible scenario is as follows:
process-a
__vmalloc_node_range(GFP_KERNEL | __GFP_NOFAIL)
__vmalloc_area_node()
vm_area_alloc_pages()
--> oom-killer send SIGKILL to process-a
if (fatal_signal_pending(current)) break;
--> return NULL;
To fix this, do not check fatal_signal_pending() in vm_area_alloc_pages()
if __GFP_NOFAIL set.
This issue occurred during OPLUS KASAN TEST. Below is part of the log
-> oom-killer sends signal to process
[65731.222840] [ T1308] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/apps/uid_10198,task=gs.intelligence,pid=32454,uid=10198
[65731.259685] [T32454] Call trace:
[65731.259698] [T32454] dump_backtrace+0xf4/0x118
[65731.259734] [T32454] show_stack+0x18/0x24
[65731.259756] [T32454] dump_stack_lvl+0x60/0x7c
[65731.259781] [T32454] dump_stack+0x18/0x38
[65731.259800] [T32454] mrdump_common_die+0x250/0x39c [mrdump]
[65731.259936] [T32454] ipanic_die+0x20/0x34 [mrdump]
[65731.260019] [T32454] atomic_notifier_call_chain+0xb4/0xfc
[65731.260047] [T32454] notify_die+0x114/0x198
[65731.260073] [T32454] die+0xf4/0x5b4
[65731.260098] [T32454] die_kernel_fault+0x80/0x98
[65731.260124] [T32454] __do_kernel_fault+0x160/0x2a8
[65731.260146] [T32454] do_bad_area+0x68/0x148
[65731.260174] [T32454] do_mem_abort+0x151c/0x1b34
[65731.260204] [T32454] el1_abort+0x3c/0x5c
[65731.260227] [T32454] el1h_64_sync_handler+0x54/0x90
[65731.260248] [T32454] el1h_64_sync+0x68/0x6c
[65731.260269] [T32454] z_erofs_decompress_queue+0x7f0/0x2258
--> be->decompressed_pages = kvcalloc(be->nr_pages, sizeof(struct page *), GFP_KERNEL | __GFP_NOFAIL);
kernel panic by NULL pointer dereference.
erofs assume kvmalloc with __GFP_NOFAIL never return NULL.
[65731.260293] [T32454] z_erofs_runqueue+0xf30/0x104c
[65731.260314] [T32454] z_erofs_readahead+0x4f0/0x968
[65731.260339] [T32454] read_pages+0x170/0xadc
[65731.260364] [T32454] page_cache_ra_unbounded+0x874/0xf30
[65731.260388] [T32454] page_cache_ra_order+0x24c/0x714
[65731.260411] [T32454] filemap_fault+0xbf0/0x1a74
[65731.260437] [T32454] __do_fault+0xd0/0x33c
[65731.260462] [T32454] handle_mm_fault+0xf74/0x3fe0
[65731.260486] [T32454] do_mem_abort+0x54c/0x1b34
[65731.260509] [T32454] el0_da+0x44/0x94
[65731.260531] [T32454] el0t_64_sync_handler+0x98/0xb4
[65731.260553] [T32454] el0t_64_sync+0x198/0x19c
Link: https://lkml.kernel.org/r/20240510100131.1865-1-hailong.liu@oppo.com
Fixes: 9376130c390a ("mm/vmalloc: add support for __GFP_NOFAIL")
Signed-off-by: Hailong.Liu <hailong.liu@oppo.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Suggested-by: Barry Song <21cnbao@gmail.com>
Reported-by: Oven <liyangouwen1@oppo.com>
Reviewed-by: Barry Song <baohua@kernel.org>
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Cc: Chao Yu <chao@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Gao Xiang <xiang@kernel.org>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/vmalloc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -3492,7 +3492,7 @@ vm_area_alloc_pages(gfp_t gfp, int nid,
{
unsigned int nr_allocated = 0;
gfp_t alloc_gfp = gfp;
- bool nofail = false;
+ bool nofail = gfp & __GFP_NOFAIL;
struct page *page;
int i;
@@ -3549,12 +3549,11 @@ vm_area_alloc_pages(gfp_t gfp, int nid,
* and compaction etc.
*/
alloc_gfp &= ~__GFP_NOFAIL;
- nofail = true;
}
/* High-order pages or fallback path if "bulk" fails. */
while (nr_allocated < nr_pages) {
- if (fatal_signal_pending(current))
+ if (!nofail && fatal_signal_pending(current))
break;
if (nid == NUMA_NO_NODE)
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 101/157] selftests/mm: compaction_test: fix incorrect write of zero to nr_hugepages
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (99 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 100/157] mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 102/157] selftests/mm: fix build warnings on ppc64 Greg Kroah-Hartman
` (65 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Dev Jain, Anshuman Khandual,
Shuah Khan, Sri Jayaramappa, Andrew Morton
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dev Jain <dev.jain@arm.com>
commit 9ad665ef55eaad1ead1406a58a34f615a7c18b5e upstream.
Currently, the test tries to set nr_hugepages to zero, but that is not
actually done because the file offset is not reset after read(). Fix that
using lseek().
Link: https://lkml.kernel.org/r/20240521074358.675031-3-dev.jain@arm.com
Fixes: bd67d5c15cc1 ("Test compaction of mlocked memory")
Signed-off-by: Dev Jain <dev.jain@arm.com>
Cc: <stable@vger.kernel.org>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Sri Jayaramappa <sjayaram@akamai.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/testing/selftests/mm/compaction_test.c | 2 ++
1 file changed, 2 insertions(+)
--- a/tools/testing/selftests/mm/compaction_test.c
+++ b/tools/testing/selftests/mm/compaction_test.c
@@ -107,6 +107,8 @@ int check_compaction(unsigned long mem_f
goto close_fd;
}
+ lseek(fd, 0, SEEK_SET);
+
/* Start with the initial condition of 0 huge pages*/
if (write(fd, "0", sizeof(char)) != sizeof(char)) {
ksft_print_msg("Failed to write 0 to /proc/sys/vm/nr_hugepages: %s\n",
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 102/157] selftests/mm: fix build warnings on ppc64
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (100 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 101/157] selftests/mm: compaction_test: fix incorrect write of zero to nr_hugepages Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 103/157] selftests/mm: compaction_test: fix bogus test success on Aarch64 Greg Kroah-Hartman
` (64 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Michael Ellerman, Shuah Khan,
Andrew Morton
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Ellerman <mpe@ellerman.id.au>
commit 1901472fa880e5706f90926cd85a268d2d16bf84 upstream.
Fix warnings like:
In file included from uffd-unit-tests.c:8:
uffd-unit-tests.c: In function `uffd_poison_handle_fault':
uffd-common.h:45:33: warning: format `%llu' expects argument of type
`long long unsigned int', but argument 3 has type `__u64' {aka `long
unsigned int'} [-Wformat=]
By switching to unsigned long long for u64 for ppc64 builds.
Link: https://lkml.kernel.org/r/20240521030219.57439-1-mpe@ellerman.id.au
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/testing/selftests/mm/gup_test.c | 1 +
tools/testing/selftests/mm/uffd-common.h | 1 +
2 files changed, 2 insertions(+)
--- a/tools/testing/selftests/mm/gup_test.c
+++ b/tools/testing/selftests/mm/gup_test.c
@@ -1,3 +1,4 @@
+#define __SANE_USERSPACE_TYPES__ // Use ll64
#include <fcntl.h>
#include <errno.h>
#include <stdio.h>
--- a/tools/testing/selftests/mm/uffd-common.h
+++ b/tools/testing/selftests/mm/uffd-common.h
@@ -8,6 +8,7 @@
#define __UFFD_COMMON_H__
#define _GNU_SOURCE
+#define __SANE_USERSPACE_TYPES__ // Use ll64
#include <stdio.h>
#include <errno.h>
#include <unistd.h>
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 103/157] selftests/mm: compaction_test: fix bogus test success on Aarch64
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (101 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 102/157] selftests/mm: fix build warnings on ppc64 Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 104/157] watchdog: rti_wdt: Set min_hw_heartbeat_ms to accommodate a safety margin Greg Kroah-Hartman
` (63 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Dev Jain, Anshuman Khandual,
Shuah Khan, Sri Jayaramappa, Andrew Morton
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dev Jain <dev.jain@arm.com>
commit d4202e66a4b1fe6968f17f9f09bbc30d08f028a1 upstream.
Patch series "Fixes for compaction_test", v2.
The compaction_test memory selftest introduces fragmentation in memory
and then tries to allocate as many hugepages as possible. This series
addresses some problems.
On Aarch64, if nr_hugepages == 0, then the test trivially succeeds since
compaction_index becomes 0, which is less than 3, due to no division by
zero exception being raised. We fix that by checking for division by
zero.
Secondly, correctly set the number of hugepages to zero before trying
to set a large number of them.
Now, consider a situation in which, at the start of the test, a non-zero
number of hugepages have been already set (while running the entire
selftests/mm suite, or manually by the admin). The test operates on 80%
of memory to avoid OOM-killer invocation, and because some memory is
already blocked by hugepages, it would increase the chance of OOM-killing.
Also, since mem_free used in check_compaction() is the value before we
set nr_hugepages to zero, the chance that the compaction_index will
be small is very high if the preset nr_hugepages was high, leading to a
bogus test success.
This patch (of 3):
Currently, if at runtime we are not able to allocate a huge page, the test
will trivially pass on Aarch64 due to no exception being raised on
division by zero while computing compaction_index. Fix that by checking
for nr_hugepages == 0. Anyways, in general, avoid a division by zero by
exiting the program beforehand. While at it, fix a typo, and handle the
case where the number of hugepages may overflow an integer.
Link: https://lkml.kernel.org/r/20240521074358.675031-1-dev.jain@arm.com
Link: https://lkml.kernel.org/r/20240521074358.675031-2-dev.jain@arm.com
Fixes: bd67d5c15cc1 ("Test compaction of mlocked memory")
Signed-off-by: Dev Jain <dev.jain@arm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Sri Jayaramappa <sjayaram@akamai.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/testing/selftests/mm/compaction_test.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
--- a/tools/testing/selftests/mm/compaction_test.c
+++ b/tools/testing/selftests/mm/compaction_test.c
@@ -82,12 +82,13 @@ int prereq(void)
return -1;
}
-int check_compaction(unsigned long mem_free, unsigned int hugepage_size)
+int check_compaction(unsigned long mem_free, unsigned long hugepage_size)
{
+ unsigned long nr_hugepages_ul;
int fd, ret = -1;
int compaction_index = 0;
- char initial_nr_hugepages[10] = {0};
- char nr_hugepages[10] = {0};
+ char initial_nr_hugepages[20] = {0};
+ char nr_hugepages[20] = {0};
/* We want to test with 80% of available memory. Else, OOM killer comes
in to play */
@@ -136,7 +137,12 @@ int check_compaction(unsigned long mem_f
/* We should have been able to request at least 1/3 rd of the memory in
huge pages */
- compaction_index = mem_free/(atoi(nr_hugepages) * hugepage_size);
+ nr_hugepages_ul = strtoul(nr_hugepages, NULL, 10);
+ if (!nr_hugepages_ul) {
+ ksft_print_msg("ERROR: No memory is available as huge pages\n");
+ goto close_fd;
+ }
+ compaction_index = mem_free/(nr_hugepages_ul * hugepage_size);
lseek(fd, 0, SEEK_SET);
@@ -147,11 +153,11 @@ int check_compaction(unsigned long mem_f
goto close_fd;
}
- ksft_print_msg("Number of huge pages allocated = %d\n",
- atoi(nr_hugepages));
+ ksft_print_msg("Number of huge pages allocated = %lu\n",
+ nr_hugepages_ul);
if (compaction_index > 3) {
- ksft_print_msg("ERROR: Less that 1/%d of memory is available\n"
+ ksft_print_msg("ERROR: Less than 1/%d of memory is available\n"
"as huge pages\n", compaction_index);
goto close_fd;
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 104/157] watchdog: rti_wdt: Set min_hw_heartbeat_ms to accommodate a safety margin
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (102 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 103/157] selftests/mm: compaction_test: fix bogus test success on Aarch64 Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 105/157] bonding: fix oops during rmmod Greg Kroah-Hartman
` (62 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Judith Mendez, Guenter Roeck,
Wim Van Sebroeck
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Judith Mendez <jm@ti.com>
commit cae58516534e110f4a8558d48aa4435e15519121 upstream.
On AM62x, the watchdog is pet before the valid window is open. Fix
min_hw_heartbeat and accommodate a 2% + static offset safety margin.
The static offset accounts for max hardware error.
Remove the hack in the driver which shifts the open window boundary,
since it is no longer necessary due to the fix mentioned above.
cc: stable@vger.kernel.org
Fixes: 5527483f8f7c ("watchdog: rti-wdt: attach to running watchdog during probe")
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20240417205700.3947408-1-jm@ti.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/watchdog/rti_wdt.c | 34 +++++++++++++++-------------------
1 file changed, 15 insertions(+), 19 deletions(-)
--- a/drivers/watchdog/rti_wdt.c
+++ b/drivers/watchdog/rti_wdt.c
@@ -59,6 +59,8 @@
#define PON_REASON_EOF_NUM 0xCCCCBBBB
#define RESERVED_MEM_MIN_SIZE 12
+#define MAX_HW_ERROR 250
+
static int heartbeat = DEFAULT_HEARTBEAT;
/*
@@ -97,7 +99,7 @@ static int rti_wdt_start(struct watchdog
* to be 50% or less than that; we obviouly want to configure the open
* window as large as possible so we select the 50% option.
*/
- wdd->min_hw_heartbeat_ms = 500 * wdd->timeout;
+ wdd->min_hw_heartbeat_ms = 520 * wdd->timeout + MAX_HW_ERROR;
/* Generate NMI when wdt expires */
writel_relaxed(RTIWWDRX_NMI, wdt->base + RTIWWDRXCTRL);
@@ -131,31 +133,33 @@ static int rti_wdt_setup_hw_hb(struct wa
* be petted during the open window; not too early or not too late.
* The HW configuration options only allow for the open window size
* to be 50% or less than that.
+ * To avoid any glitches, we accommodate 2% + max hardware error
+ * safety margin.
*/
switch (wsize) {
case RTIWWDSIZE_50P:
- /* 50% open window => 50% min heartbeat */
- wdd->min_hw_heartbeat_ms = 500 * heartbeat;
+ /* 50% open window => 52% min heartbeat */
+ wdd->min_hw_heartbeat_ms = 520 * heartbeat + MAX_HW_ERROR;
break;
case RTIWWDSIZE_25P:
- /* 25% open window => 75% min heartbeat */
- wdd->min_hw_heartbeat_ms = 750 * heartbeat;
+ /* 25% open window => 77% min heartbeat */
+ wdd->min_hw_heartbeat_ms = 770 * heartbeat + MAX_HW_ERROR;
break;
case RTIWWDSIZE_12P5:
- /* 12.5% open window => 87.5% min heartbeat */
- wdd->min_hw_heartbeat_ms = 875 * heartbeat;
+ /* 12.5% open window => 89.5% min heartbeat */
+ wdd->min_hw_heartbeat_ms = 895 * heartbeat + MAX_HW_ERROR;
break;
case RTIWWDSIZE_6P25:
- /* 6.5% open window => 93.5% min heartbeat */
- wdd->min_hw_heartbeat_ms = 935 * heartbeat;
+ /* 6.5% open window => 95.5% min heartbeat */
+ wdd->min_hw_heartbeat_ms = 955 * heartbeat + MAX_HW_ERROR;
break;
case RTIWWDSIZE_3P125:
- /* 3.125% open window => 96.9% min heartbeat */
- wdd->min_hw_heartbeat_ms = 969 * heartbeat;
+ /* 3.125% open window => 98.9% min heartbeat */
+ wdd->min_hw_heartbeat_ms = 989 * heartbeat + MAX_HW_ERROR;
break;
default:
@@ -233,14 +237,6 @@ static int rti_wdt_probe(struct platform
return -EINVAL;
}
- /*
- * If watchdog is running at 32k clock, it is not accurate.
- * Adjust frequency down in this case so that we don't pet
- * the watchdog too often.
- */
- if (wdt->freq < 32768)
- wdt->freq = wdt->freq * 9 / 10;
-
pm_runtime_enable(dev);
ret = pm_runtime_resume_and_get(dev);
if (ret < 0) {
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 105/157] bonding: fix oops during rmmod
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (103 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 104/157] watchdog: rti_wdt: Set min_hw_heartbeat_ms to accommodate a safety margin Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 106/157] irqchip/riscv-intc: Prevent memory leak when riscv_intc_init_common() fails Greg Kroah-Hartman
` (61 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Tony Battersby, Simon Horman,
Jay Vosburgh, Jakub Kicinski
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tony Battersby <tonyb@cybernetics.com>
commit a45835a0bb6ef7d5ddbc0714dd760de979cb6ece upstream.
"rmmod bonding" causes an oops ever since commit cc317ea3d927 ("bonding:
remove redundant NULL check in debugfs function"). Here are the relevant
functions being called:
bonding_exit()
bond_destroy_debugfs()
debugfs_remove_recursive(bonding_debug_root);
bonding_debug_root = NULL; <--------- SET TO NULL HERE
bond_netlink_fini()
rtnl_link_unregister()
__rtnl_link_unregister()
unregister_netdevice_many_notify()
bond_uninit()
bond_debug_unregister()
(commit removed check for bonding_debug_root == NULL)
debugfs_remove()
simple_recursive_removal()
down_write() -> OOPS
However, reverting the bad commit does not solve the problem completely
because the original code contains a race that could cause the same
oops, although it was much less likely to be triggered unintentionally:
CPU1
rmmod bonding
bonding_exit()
bond_destroy_debugfs()
debugfs_remove_recursive(bonding_debug_root);
CPU2
echo -bond0 > /sys/class/net/bonding_masters
bond_uninit()
bond_debug_unregister()
if (!bonding_debug_root)
CPU1
bonding_debug_root = NULL;
So do NOT revert the bad commit (since the removed checks were racy
anyway), and instead change the order of actions taken during module
removal. The same oops can also happen if there is an error during
module init, so apply the same fix there.
Fixes: cc317ea3d927 ("bonding: remove redundant NULL check in debugfs function")
Cc: stable@vger.kernel.org
Signed-off-by: Tony Battersby <tonyb@cybernetics.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Link: https://lore.kernel.org/r/641f914f-3216-4eeb-87dd-91b78aa97773@cybernetics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/bonding/bond_main.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -6477,16 +6477,16 @@ static int __init bonding_init(void)
if (res)
goto out;
+ bond_create_debugfs();
+
res = register_pernet_subsys(&bond_net_ops);
if (res)
- goto out;
+ goto err_net_ops;
res = bond_netlink_init();
if (res)
goto err_link;
- bond_create_debugfs();
-
for (i = 0; i < max_bonds; i++) {
res = bond_create(&init_net, NULL);
if (res)
@@ -6501,10 +6501,11 @@ static int __init bonding_init(void)
out:
return res;
err:
- bond_destroy_debugfs();
bond_netlink_fini();
err_link:
unregister_pernet_subsys(&bond_net_ops);
+err_net_ops:
+ bond_destroy_debugfs();
goto out;
}
@@ -6513,11 +6514,11 @@ static void __exit bonding_exit(void)
{
unregister_netdevice_notifier(&bond_netdev_notifier);
- bond_destroy_debugfs();
-
bond_netlink_fini();
unregister_pernet_subsys(&bond_net_ops);
+ bond_destroy_debugfs();
+
#ifdef CONFIG_NET_POLL_CONTROLLER
/* Make sure we don't have an imbalance on our netpoll blocking */
WARN_ON(atomic_read(&netpoll_block_tx));
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 106/157] irqchip/riscv-intc: Prevent memory leak when riscv_intc_init_common() fails
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (104 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 105/157] bonding: fix oops during rmmod Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 107/157] wifi: ath10k: fix QCOM_RPROC_COMMON dependency Greg Kroah-Hartman
` (60 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Sunil V L, Thomas Gleixner,
Anup Patel
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sunil V L <sunilvl@ventanamicro.com>
commit 0110c4b110477bb1f19b0d02361846be7ab08300 upstream.
When riscv_intc_init_common() fails, the firmware node allocated is not
freed. Add the missing free().
Fixes: 7023b9d83f03 ("irqchip/riscv-intc: Add ACPI support")
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Anup Patel <anup@brainfault.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240527081113.616189-1-sunilvl@ventanamicro.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/irqchip/irq-riscv-intc.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/irqchip/irq-riscv-intc.c
+++ b/drivers/irqchip/irq-riscv-intc.c
@@ -253,8 +253,9 @@ IRQCHIP_DECLARE(andes, "andestech,cpu-in
static int __init riscv_intc_acpi_init(union acpi_subtable_headers *header,
const unsigned long end)
{
- struct fwnode_handle *fn;
struct acpi_madt_rintc *rintc;
+ struct fwnode_handle *fn;
+ int rc;
rintc = (struct acpi_madt_rintc *)header;
@@ -273,7 +274,11 @@ static int __init riscv_intc_acpi_init(u
return -ENOMEM;
}
- return riscv_intc_init_common(fn, &riscv_intc_chip);
+ rc = riscv_intc_init_common(fn, &riscv_intc_chip);
+ if (rc)
+ irq_domain_free_fwnode(fn);
+
+ return rc;
}
IRQCHIP_ACPI_DECLARE(riscv_intc, ACPI_MADT_TYPE_RINTC, NULL,
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 107/157] wifi: ath10k: fix QCOM_RPROC_COMMON dependency
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (105 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 106/157] irqchip/riscv-intc: Prevent memory leak when riscv_intc_init_common() fails Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 108/157] kdb: Fix buffer overflow during tab-complete Greg Kroah-Hartman
` (59 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Dmitry Baryshkov, Kalle Valo
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
commit 21ae74e1bf18331ae5e279bd96304b3630828009 upstream.
If ath10k_snoc is built-in, while Qualcomm remoteprocs are built as
modules, compilation fails with:
/usr/bin/aarch64-linux-gnu-ld: drivers/net/wireless/ath/ath10k/snoc.o: in function `ath10k_modem_init':
drivers/net/wireless/ath/ath10k/snoc.c:1534: undefined reference to `qcom_register_ssr_notifier'
/usr/bin/aarch64-linux-gnu-ld: drivers/net/wireless/ath/ath10k/snoc.o: in function `ath10k_modem_deinit':
drivers/net/wireless/ath/ath10k/snoc.c:1551: undefined reference to `qcom_unregister_ssr_notifier'
Add corresponding dependency to ATH10K_SNOC Kconfig entry so that it's
built as module if QCOM_RPROC_COMMON is built as module too.
Fixes: 747ff7d3d742 ("ath10k: Don't always treat modem stop events as crashes")
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20240511-ath10k-snoc-dep-v1-1-9666e3af5c27@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
@@ -45,6 +45,7 @@ config ATH10K_SNOC
depends on ATH10K
depends on ARCH_QCOM || COMPILE_TEST
depends on QCOM_SMEM
+ depends on QCOM_RPROC_COMMON || QCOM_RPROC_COMMON=n
select QCOM_SCM
select QCOM_QMI_HELPERS
help
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 108/157] kdb: Fix buffer overflow during tab-complete
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (106 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 107/157] wifi: ath10k: fix QCOM_RPROC_COMMON dependency Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 109/157] kdb: Use format-strings rather than \0 injection in kdb_read() Greg Kroah-Hartman
` (58 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Justin Stitt, Douglas Anderson,
Daniel Thompson
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Thompson <daniel.thompson@linaro.org>
commit e9730744bf3af04cda23799029342aa3cddbc454 upstream.
Currently, when the user attempts symbol completion with the Tab key, kdb
will use strncpy() to insert the completed symbol into the command buffer.
Unfortunately it passes the size of the source buffer rather than the
destination to strncpy() with predictably horrible results. Most obviously
if the command buffer is already full but cp, the cursor position, is in
the middle of the buffer, then we will write past the end of the supplied
buffer.
Fix this by replacing the dubious strncpy() calls with memmove()/memcpy()
calls plus explicit boundary checks to make sure we have enough space
before we start moving characters around.
Reported-by: Justin Stitt <justinstitt@google.com>
Closes: https://lore.kernel.org/all/CAFhGd8qESuuifuHsNjFPR-Va3P80bxrw+LqvC8deA8GziUJLpw@mail.gmail.com/
Cc: stable@vger.kernel.org
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Justin Stitt <justinstitt@google.com>
Tested-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-1-f236dbe9828d@linaro.org
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/debug/kdb/kdb_io.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -367,14 +367,19 @@ poll_again:
kdb_printf(kdb_prompt_str);
kdb_printf("%s", buffer);
} else if (tab != 2 && count > 0) {
- len_tmp = strlen(p_tmp);
- strncpy(p_tmp+len_tmp, cp, lastchar-cp+1);
- len_tmp = strlen(p_tmp);
- strncpy(cp, p_tmp+len, len_tmp-len + 1);
- len = len_tmp - len;
- kdb_printf("%s", cp);
- cp += len;
- lastchar += len;
+ /* How many new characters do we want from tmpbuffer? */
+ len_tmp = strlen(p_tmp) - len;
+ if (lastchar + len_tmp >= bufend)
+ len_tmp = bufend - lastchar;
+
+ if (len_tmp) {
+ /* + 1 ensures the '\0' is memmove'd */
+ memmove(cp+len_tmp, cp, (lastchar-cp) + 1);
+ memcpy(cp, p_tmp+len, len_tmp);
+ kdb_printf("%s", cp);
+ cp += len_tmp;
+ lastchar += len_tmp;
+ }
}
kdb_nextline = 1; /* reset output line number */
break;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 109/157] kdb: Use format-strings rather than \0 injection in kdb_read()
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (107 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 108/157] kdb: Fix buffer overflow during tab-complete Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 110/157] kdb: Fix console handling when editing and tab-completing commands Greg Kroah-Hartman
` (57 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Justin Stitt, Douglas Anderson,
Daniel Thompson
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Thompson <daniel.thompson@linaro.org>
commit 09b35989421dfd5573f0b4683c7700a7483c71f9 upstream.
Currently when kdb_read() needs to reposition the cursor it uses copy and
paste code that works by injecting an '\0' at the cursor position before
delivering a carriage-return and reprinting the line (which stops at the
'\0').
Tidy up the code by hoisting the copy and paste code into an appropriately
named function. Additionally let's replace the '\0' injection with a
proper field width parameter so that the string will be abridged during
formatting instead.
Cc: stable@vger.kernel.org # Not a bug fix but it is needed for later bug fixes
Tested-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-2-f236dbe9828d@linaro.org
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/debug/kdb/kdb_io.c | 55 ++++++++++++++++++++++++++++------------------
1 file changed, 34 insertions(+), 21 deletions(-)
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -184,6 +184,33 @@ char kdb_getchar(void)
unreachable();
}
+/**
+ * kdb_position_cursor() - Place cursor in the correct horizontal position
+ * @prompt: Nil-terminated string containing the prompt string
+ * @buffer: Nil-terminated string containing the entire command line
+ * @cp: Cursor position, pointer the character in buffer where the cursor
+ * should be positioned.
+ *
+ * The cursor is positioned by sending a carriage-return and then printing
+ * the content of the line until we reach the correct cursor position.
+ *
+ * There is some additional fine detail here.
+ *
+ * Firstly, even though kdb_printf() will correctly format zero-width fields
+ * we want the second call to kdb_printf() to be conditional. That keeps things
+ * a little cleaner when LOGGING=1.
+ *
+ * Secondly, we can't combine everything into one call to kdb_printf() since
+ * that renders into a fixed length buffer and the combined print could result
+ * in unwanted truncation.
+ */
+static void kdb_position_cursor(char *prompt, char *buffer, char *cp)
+{
+ kdb_printf("\r%s", kdb_prompt_str);
+ if (cp > buffer)
+ kdb_printf("%.*s", (int)(cp - buffer), buffer);
+}
+
/*
* kdb_read
*
@@ -212,7 +239,6 @@ static char *kdb_read(char *buffer, size
* and null byte */
char *lastchar;
char *p_tmp;
- char tmp;
static char tmpbuffer[CMD_BUFLEN];
int len = strlen(buffer);
int len_tmp;
@@ -249,12 +275,8 @@ poll_again:
}
*(--lastchar) = '\0';
--cp;
- kdb_printf("\b%s \r", cp);
- tmp = *cp;
- *cp = '\0';
- kdb_printf(kdb_prompt_str);
- kdb_printf("%s", buffer);
- *cp = tmp;
+ kdb_printf("\b%s ", cp);
+ kdb_position_cursor(kdb_prompt_str, buffer, cp);
}
break;
case 10: /* linefeed */
@@ -272,19 +294,14 @@ poll_again:
memcpy(tmpbuffer, cp+1, lastchar - cp - 1);
memcpy(cp, tmpbuffer, lastchar - cp - 1);
*(--lastchar) = '\0';
- kdb_printf("%s \r", cp);
- tmp = *cp;
- *cp = '\0';
- kdb_printf(kdb_prompt_str);
- kdb_printf("%s", buffer);
- *cp = tmp;
+ kdb_printf("%s ", cp);
+ kdb_position_cursor(kdb_prompt_str, buffer, cp);
}
break;
case 1: /* Home */
if (cp > buffer) {
- kdb_printf("\r");
- kdb_printf(kdb_prompt_str);
cp = buffer;
+ kdb_position_cursor(kdb_prompt_str, buffer, cp);
}
break;
case 5: /* End */
@@ -390,13 +407,9 @@ poll_again:
memcpy(cp+1, tmpbuffer, lastchar - cp);
*++lastchar = '\0';
*cp = key;
- kdb_printf("%s\r", cp);
+ kdb_printf("%s", cp);
++cp;
- tmp = *cp;
- *cp = '\0';
- kdb_printf(kdb_prompt_str);
- kdb_printf("%s", buffer);
- *cp = tmp;
+ kdb_position_cursor(kdb_prompt_str, buffer, cp);
} else {
*++lastchar = '\0';
*cp++ = key;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 110/157] kdb: Fix console handling when editing and tab-completing commands
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (108 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 109/157] kdb: Use format-strings rather than \0 injection in kdb_read() Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 111/157] kdb: Merge identical case statements in kdb_read() Greg Kroah-Hartman
` (56 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Douglas Anderson, Justin Stitt,
Daniel Thompson
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Thompson <daniel.thompson@linaro.org>
commit db2f9c7dc29114f531df4a425d0867d01e1f1e28 upstream.
Currently, if the cursor position is not at the end of the command buffer
and the user uses the Tab-complete functions, then the console does not
leave the cursor in the correct position.
For example consider the following buffer with the cursor positioned
at the ^:
md kdb_pro 10
^
Pressing tab should result in:
md kdb_prompt_str 10
^
However this does not happen. Instead the cursor is placed at the end
(after then 10) and further cursor movement redraws incorrectly. The
same problem exists when we double-Tab but in a different part of the
code.
Fix this by sending a carriage return and then redisplaying the text to
the left of the cursor.
Cc: stable@vger.kernel.org
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-3-f236dbe9828d@linaro.org
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/debug/kdb/kdb_io.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -383,6 +383,8 @@ poll_again:
kdb_printf("\n");
kdb_printf(kdb_prompt_str);
kdb_printf("%s", buffer);
+ if (cp != lastchar)
+ kdb_position_cursor(kdb_prompt_str, buffer, cp);
} else if (tab != 2 && count > 0) {
/* How many new characters do we want from tmpbuffer? */
len_tmp = strlen(p_tmp) - len;
@@ -396,6 +398,9 @@ poll_again:
kdb_printf("%s", cp);
cp += len_tmp;
lastchar += len_tmp;
+ if (cp != lastchar)
+ kdb_position_cursor(kdb_prompt_str,
+ buffer, cp);
}
}
kdb_nextline = 1; /* reset output line number */
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 111/157] kdb: Merge identical case statements in kdb_read()
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (109 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 110/157] kdb: Fix console handling when editing and tab-completing commands Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 112/157] kdb: Use format-specifiers rather than memset() for padding " Greg Kroah-Hartman
` (55 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Douglas Anderson, Justin Stitt,
Daniel Thompson
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Thompson <daniel.thompson@linaro.org>
commit 6244917f377bf64719551b58592a02a0336a7439 upstream.
The code that handles case 14 (down) and case 16 (up) has been copy and
pasted despite being byte-for-byte identical. Combine them.
Cc: stable@vger.kernel.org # Not a bug fix but it is needed for later bug fixes
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-4-f236dbe9828d@linaro.org
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/debug/kdb/kdb_io.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -317,6 +317,7 @@ poll_again:
}
break;
case 14: /* Down */
+ case 16: /* Up */
memset(tmpbuffer, ' ',
strlen(kdb_prompt_str) + (lastchar-buffer));
*(tmpbuffer+strlen(kdb_prompt_str) +
@@ -331,15 +332,6 @@ poll_again:
++cp;
}
break;
- case 16: /* Up */
- memset(tmpbuffer, ' ',
- strlen(kdb_prompt_str) + (lastchar-buffer));
- *(tmpbuffer+strlen(kdb_prompt_str) +
- (lastchar-buffer)) = '\0';
- kdb_printf("\r%s\r", tmpbuffer);
- *lastchar = (char)key;
- *(lastchar+1) = '\0';
- return lastchar;
case 9: /* Tab */
if (tab < 2)
++tab;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 112/157] kdb: Use format-specifiers rather than memset() for padding in kdb_read()
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (110 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 111/157] kdb: Merge identical case statements in kdb_read() Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 113/157] Revert "xsk: Support redirect to any socket bound to the same umem" Greg Kroah-Hartman
` (54 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Douglas Anderson, Justin Stitt,
Daniel Thompson
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Thompson <daniel.thompson@linaro.org>
commit c9b51ddb66b1d96e4d364c088da0f1dfb004c574 upstream.
Currently when the current line should be removed from the display
kdb_read() uses memset() to fill a temporary buffer with spaces.
The problem is not that this could be trivially implemented using a
format string rather than open coding it. The real problem is that
it is possible, on systems with a long kdb_prompt_str, to write past
the end of the tmpbuffer.
Happily, as mentioned above, this can be trivially implemented using a
format string. Make it so!
Cc: stable@vger.kernel.org
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-5-f236dbe9828d@linaro.org
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/debug/kdb/kdb_io.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -318,11 +318,9 @@ poll_again:
break;
case 14: /* Down */
case 16: /* Up */
- memset(tmpbuffer, ' ',
- strlen(kdb_prompt_str) + (lastchar-buffer));
- *(tmpbuffer+strlen(kdb_prompt_str) +
- (lastchar-buffer)) = '\0';
- kdb_printf("\r%s\r", tmpbuffer);
+ kdb_printf("\r%*c\r",
+ (int)(strlen(kdb_prompt_str) + (lastchar - buffer)),
+ ' ');
*lastchar = (char)key;
*(lastchar+1) = '\0';
return lastchar;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 113/157] Revert "xsk: Support redirect to any socket bound to the same umem"
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (111 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 112/157] kdb: Use format-specifiers rather than memset() for padding " Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:33 ` [PATCH 6.9 114/157] Revert "xsk: Document ability to " Greg Kroah-Hartman
` (53 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Yuval El-Hanany, Magnus Karlsson,
Daniel Borkmann
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Magnus Karlsson <magnus.karlsson@intel.com>
commit 7fcf26b315bbb728036da0862de6b335da83dff2 upstream.
This reverts commit 2863d665ea41282379f108e4da6c8a2366ba66db.
This patch introduced a potential kernel crash when multiple napi instances
redirect to the same AF_XDP socket. By removing the queue_index check, it is
possible for multiple napi instances to access the Rx ring at the same time,
which will result in a corrupted ring state which can lead to a crash when
flushing the rings in __xsk_flush(). This can happen when the linked list of
sockets to flush gets corrupted by concurrent accesses. A quick and small fix
is not possible, so let us revert this for now.
Reported-by: Yuval El-Hanany <YuvalE@radware.com>
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/xdp-newbies/8100DBDC-0B7C-49DB-9995-6027F6E63147@radware.com
Link: https://lore.kernel.org/bpf/20240604122927.29080-2-magnus.karlsson@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/xdp/xsk.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index 727aa20be4bd..7d1c0986f9bb 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -313,13 +313,10 @@ static bool xsk_is_bound(struct xdp_sock *xs)
static int xsk_rcv_check(struct xdp_sock *xs, struct xdp_buff *xdp, u32 len)
{
- struct net_device *dev = xdp->rxq->dev;
- u32 qid = xdp->rxq->queue_index;
-
if (!xsk_is_bound(xs))
return -ENXIO;
- if (!dev->_rx[qid].pool || xs->umem != dev->_rx[qid].pool->umem)
+ if (xs->dev != xdp->rxq->dev || xs->queue_id != xdp->rxq->queue_index)
return -EINVAL;
if (len > xsk_pool_get_rx_frame_size(xs->pool) && !xs->sg) {
--
2.45.2
^ permalink raw reply related [flat|nested] 168+ messages in thread* [PATCH 6.9 114/157] Revert "xsk: Document ability to redirect to any socket bound to the same umem"
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (112 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 113/157] Revert "xsk: Support redirect to any socket bound to the same umem" Greg Kroah-Hartman
@ 2024-06-13 11:33 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 115/157] Revert "perf record: Reduce memory for recording PERF_RECORD_LOST_SAMPLES event" Greg Kroah-Hartman
` (52 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:33 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Yuval El-Hanany, Magnus Karlsson,
Daniel Borkmann
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Magnus Karlsson <magnus.karlsson@intel.com>
commit 03e38d315f3c5258270ad50f2ae784b6372e87c3 upstream.
This reverts commit 968595a93669b6b4f6d1fcf80cf2d97956b6868f.
Reported-by: Yuval El-Hanany <YuvalE@radware.com>
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/xdp-newbies/8100DBDC-0B7C-49DB-9995-6027F6E63147@radware.com
Link: https://lore.kernel.org/bpf/20240604122927.29080-3-magnus.karlsson@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/networking/af_xdp.rst | 31 ++++++++++++-----------------
1 file changed, 13 insertions(+), 18 deletions(-)
diff --git a/Documentation/networking/af_xdp.rst b/Documentation/networking/af_xdp.rst
index 72da7057e4cf..dceeb0d763aa 100644
--- a/Documentation/networking/af_xdp.rst
+++ b/Documentation/networking/af_xdp.rst
@@ -329,24 +329,23 @@ XDP_SHARED_UMEM option and provide the initial socket's fd in the
sxdp_shared_umem_fd field as you registered the UMEM on that
socket. These two sockets will now share one and the same UMEM.
-In this case, it is possible to use the NIC's packet steering
-capabilities to steer the packets to the right queue. This is not
-possible in the previous example as there is only one queue shared
-among sockets, so the NIC cannot do this steering as it can only steer
-between queues.
+There is no need to supply an XDP program like the one in the previous
+case where sockets were bound to the same queue id and
+device. Instead, use the NIC's packet steering capabilities to steer
+the packets to the right queue. In the previous example, there is only
+one queue shared among sockets, so the NIC cannot do this steering. It
+can only steer between queues.
-In libxdp (or libbpf prior to version 1.0), you need to use the
-xsk_socket__create_shared() API as it takes a reference to a FILL ring
-and a COMPLETION ring that will be created for you and bound to the
-shared UMEM. You can use this function for all the sockets you create,
-or you can use it for the second and following ones and use
-xsk_socket__create() for the first one. Both methods yield the same
-result.
+In libbpf, you need to use the xsk_socket__create_shared() API as it
+takes a reference to a FILL ring and a COMPLETION ring that will be
+created for you and bound to the shared UMEM. You can use this
+function for all the sockets you create, or you can use it for the
+second and following ones and use xsk_socket__create() for the first
+one. Both methods yield the same result.
Note that a UMEM can be shared between sockets on the same queue id
and device, as well as between queues on the same device and between
-devices at the same time. It is also possible to redirect to any
-socket as long as it is bound to the same umem with XDP_SHARED_UMEM.
+devices at the same time.
XDP_USE_NEED_WAKEUP bind flag
-----------------------------
@@ -823,10 +822,6 @@ A: The short answer is no, that is not supported at the moment. The
switch, or other distribution mechanism, in your NIC to direct
traffic to the correct queue id and socket.
- Note that if you are using the XDP_SHARED_UMEM option, it is
- possible to switch traffic between any socket bound to the same
- umem.
-
Q: My packets are sometimes corrupted. What is wrong?
A: Care has to be taken not to feed the same buffer in the UMEM into
--
2.45.2
^ permalink raw reply related [flat|nested] 168+ messages in thread* [PATCH 6.9 115/157] Revert "perf record: Reduce memory for recording PERF_RECORD_LOST_SAMPLES event"
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (113 preceding siblings ...)
2024-06-13 11:33 ` [PATCH 6.9 114/157] Revert "xsk: Document ability to " Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 116/157] e1000e: move force SMBUS near the end of enable_ulp function Greg Kroah-Hartman
` (51 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Milian Wolff, Adrian Hunter,
Ian Rogers, Jiri Olsa, Kan Liang, Namhyung Kim,
Arnaldo Carvalho de Melo, stable
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnaldo Carvalho de Melo <acme@redhat.com>
commit 5b3cde198878b2f3269d5e7efbc0d514899b1fd8 upstream.
This reverts commit 7d1405c71df21f6c394b8a885aa8a133f749fa22.
This causes segfaults in some cases, as reported by Milian:
```
sudo /usr/bin/perf record -z --call-graph dwarf -e cycles -e
raw_syscalls:sys_enter ls
...
[ perf record: Woken up 3 times to write data ]
malloc(): invalid next size (unsorted)
Aborted
```
Backtrace with GDB + debuginfod:
```
malloc(): invalid next size (unsorted)
Thread 1 "perf" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6,
no_tid=no_tid@entry=0) at pthread_kill.c:44
Downloading source file /usr/src/debug/glibc/glibc/nptl/pthread_kill.c
44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO
(ret) : 0;
(gdb) bt
#0 __pthread_kill_implementation (threadid=<optimized out>,
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007ffff6ea8eb3 in __pthread_kill_internal (threadid=<optimized out>,
signo=6) at pthread_kill.c:78
#2 0x00007ffff6e50a30 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/
raise.c:26
#3 0x00007ffff6e384c3 in __GI_abort () at abort.c:79
#4 0x00007ffff6e39354 in __libc_message_impl (fmt=fmt@entry=0x7ffff6fc22ea
"%s\n") at ../sysdeps/posix/libc_fatal.c:132
#5 0x00007ffff6eb3085 in malloc_printerr (str=str@entry=0x7ffff6fc5850
"malloc(): invalid next size (unsorted)") at malloc.c:5772
#6 0x00007ffff6eb657c in _int_malloc (av=av@entry=0x7ffff6ff6ac0
<main_arena>, bytes=bytes@entry=368) at malloc.c:4081
#7 0x00007ffff6eb877e in __libc_calloc (n=<optimized out>,
elem_size=<optimized out>) at malloc.c:3754
#8 0x000055555569bdb6 in perf_session.do_write_header ()
#9 0x00005555555a373a in __cmd_record.constprop.0 ()
#10 0x00005555555a6846 in cmd_record ()
#11 0x000055555564db7f in run_builtin ()
#12 0x000055555558ed77 in main ()
```
Valgrind memcheck:
```
==45136== Invalid write of size 8
==45136== at 0x2B38A5: perf_event__synthesize_id_sample (in /usr/bin/perf)
==45136== by 0x157069: __cmd_record.constprop.0 (in /usr/bin/perf)
==45136== by 0x15A845: cmd_record (in /usr/bin/perf)
==45136== by 0x201B7E: run_builtin (in /usr/bin/perf)
==45136== by 0x142D76: main (in /usr/bin/perf)
==45136== Address 0x6a866a8 is 0 bytes after a block of size 40 alloc'd
==45136== at 0x4849BF3: calloc (vg_replace_malloc.c:1675)
==45136== by 0x3574AB: zalloc (in /usr/bin/perf)
==45136== by 0x1570E0: __cmd_record.constprop.0 (in /usr/bin/perf)
==45136== by 0x15A845: cmd_record (in /usr/bin/perf)
==45136== by 0x201B7E: run_builtin (in /usr/bin/perf)
==45136== by 0x142D76: main (in /usr/bin/perf)
==45136==
==45136== Syscall param write(buf) points to unaddressable byte(s)
==45136== at 0x575953D: __libc_write (write.c:26)
==45136== by 0x575953D: write (write.c:24)
==45136== by 0x35761F: ion (in /usr/bin/perf)
==45136== by 0x357778: writen (in /usr/bin/perf)
==45136== by 0x1548F7: record__write (in /usr/bin/perf)
==45136== by 0x15708A: __cmd_record.constprop.0 (in /usr/bin/perf)
==45136== by 0x15A845: cmd_record (in /usr/bin/perf)
==45136== by 0x201B7E: run_builtin (in /usr/bin/perf)
==45136== by 0x142D76: main (in /usr/bin/perf)
==45136== Address 0x6a866a8 is 0 bytes after a block of size 40 alloc'd
==45136== at 0x4849BF3: calloc (vg_replace_malloc.c:1675)
==45136== by 0x3574AB: zalloc (in /usr/bin/perf)
==45136== by 0x1570E0: __cmd_record.constprop.0 (in /usr/bin/perf)
==45136== by 0x15A845: cmd_record (in /usr/bin/perf)
==45136== by 0x201B7E: run_builtin (in /usr/bin/perf)
==45136== by 0x142D76: main (in /usr/bin/perf)
==45136==
-----
Closes: https://lore.kernel.org/linux-perf-users/23879991.0LEYPuXRzz@milian-workstation/
Reported-by: Milian Wolff <milian.wolff@kdab.com>
Tested-by: Milian Wolff <milian.wolff@kdab.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: stable@kernel.org # 6.8+
Link: https://lore.kernel.org/lkml/Zl9ksOlHJHnKM70p@x1
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/perf/builtin-record.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1956,8 +1956,7 @@ static void record__read_lost_samples(st
if (count.lost) {
if (!lost) {
- lost = zalloc(sizeof(*lost) +
- session->machines.host.id_hdr_size);
+ lost = zalloc(PERF_SAMPLE_MAX_SIZE);
if (!lost) {
pr_debug("Memory allocation failed\n");
return;
@@ -1973,8 +1972,7 @@ static void record__read_lost_samples(st
lost_count = perf_bpf_filter__lost_count(evsel);
if (lost_count) {
if (!lost) {
- lost = zalloc(sizeof(*lost) +
- session->machines.host.id_hdr_size);
+ lost = zalloc(PERF_SAMPLE_MAX_SIZE);
if (!lost) {
pr_debug("Memory allocation failed\n");
return;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 116/157] e1000e: move force SMBUS near the end of enable_ulp function
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (114 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 115/157] Revert "perf record: Reduce memory for recording PERF_RECORD_LOST_SAMPLES event" Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 117/157] sparc: move struct termio to asm/termios.h Greg Kroah-Hartman
` (50 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Hui Wang, Vitaly Lifshits,
Naama Meir, Simon Horman, Paul Menzel, Tony Nguyen, Zhang Rui,
Jacob Keller, Jakub Kicinski
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hui Wang <hui.wang@canonical.com>
commit bfd546a552e140b0a4c8a21527c39d6d21addb28 upstream.
The commit 861e8086029e ("e1000e: move force SMBUS from enable ulp
function to avoid PHY loss issue") introduces a regression on
PCH_MTP_I219_LM18 (PCIID: 0x8086550A). Without the referred commit, the
ethernet works well after suspend and resume, but after applying the
commit, the ethernet couldn't work anymore after the resume and the
dmesg shows that the NIC link changes to 10Mbps (1000Mbps originally):
[ 43.305084] e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Up 10 Mbps Full Duplex, Flow Control: Rx/Tx
Without the commit, the force SMBUS code will not be executed if
"return 0" or "goto out" is executed in the enable_ulp(), and in my
case, the "goto out" is executed since FWSM_FW_VALID is set. But after
applying the commit, the force SMBUS code will be ran unconditionally.
Here move the force SMBUS code back to enable_ulp() and put it
immediately ahead of hw->phy.ops.release(hw), this could allow the
longest settling time as possible for interface in this function and
doesn't change the original code logic.
The issue was found on a Lenovo laptop with the ethernet hw as below:
00:1f.6 Ethernet controller [0200]: Intel Corporation Device [8086:550a]
(rev 20).
And this patch is verified (cable plug and unplug, system suspend
and resume) on Lenovo laptops with ethernet hw: [8086:550a],
[8086:550b], [8086:15bb], [8086:15be], [8086:1a1f], [8086:1a1c] and
[8086:0dc7].
Fixes: 861e8086029e ("e1000e: move force SMBUS from enable ulp function to avoid PHY loss issue")
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: Vitaly Lifshits <vitaly.lifshits@intel.com>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Tested-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://lore.kernel.org/r/20240528-net-2024-05-28-intel-net-fixes-v1-1-dc8593d2bbc6@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 22 ++++++++++++++++++++++
drivers/net/ethernet/intel/e1000e/netdev.c | 18 ------------------
2 files changed, 22 insertions(+), 18 deletions(-)
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -1225,6 +1225,28 @@ s32 e1000_enable_ulp_lpt_lp(struct e1000
}
release:
+ /* Switching PHY interface always returns MDI error
+ * so disable retry mechanism to avoid wasting time
+ */
+ e1000e_disable_phy_retry(hw);
+
+ /* Force SMBus mode in PHY */
+ ret_val = e1000_read_phy_reg_hv_locked(hw, CV_SMB_CTRL, &phy_reg);
+ if (ret_val) {
+ e1000e_enable_phy_retry(hw);
+ hw->phy.ops.release(hw);
+ goto out;
+ }
+ phy_reg |= CV_SMB_CTRL_FORCE_SMBUS;
+ e1000_write_phy_reg_hv_locked(hw, CV_SMB_CTRL, phy_reg);
+
+ e1000e_enable_phy_retry(hw);
+
+ /* Force SMBus mode in MAC */
+ mac_reg = er32(CTRL_EXT);
+ mac_reg |= E1000_CTRL_EXT_FORCE_SMBUS;
+ ew32(CTRL_EXT, mac_reg);
+
hw->phy.ops.release(hw);
out:
if (ret_val)
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6623,7 +6623,6 @@ static int __e1000_shutdown(struct pci_d
struct e1000_hw *hw = &adapter->hw;
u32 ctrl, ctrl_ext, rctl, status, wufc;
int retval = 0;
- u16 smb_ctrl;
/* Runtime suspend should only enable wakeup for link changes */
if (runtime)
@@ -6697,23 +6696,6 @@ static int __e1000_shutdown(struct pci_d
if (retval)
return retval;
}
-
- /* Force SMBUS to allow WOL */
- /* Switching PHY interface always returns MDI error
- * so disable retry mechanism to avoid wasting time
- */
- e1000e_disable_phy_retry(hw);
-
- e1e_rphy(hw, CV_SMB_CTRL, &smb_ctrl);
- smb_ctrl |= CV_SMB_CTRL_FORCE_SMBUS;
- e1e_wphy(hw, CV_SMB_CTRL, smb_ctrl);
-
- e1000e_enable_phy_retry(hw);
-
- /* Force SMBus mode in MAC */
- ctrl_ext = er32(CTRL_EXT);
- ctrl_ext |= E1000_CTRL_EXT_FORCE_SMBUS;
- ew32(CTRL_EXT, ctrl_ext);
}
/* Ensure that the appropriate bits are set in LPI_CTRL
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 117/157] sparc: move struct termio to asm/termios.h
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (115 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 116/157] e1000e: move force SMBUS near the end of enable_ulp function Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 118/157] ext4: Fixes len calculation in mpage_journal_page_buffers Greg Kroah-Hartman
` (49 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Mike Gilbert, Andreas Larsson
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Gilbert <floppym@gentoo.org>
commit c32d18e7942d7589b62e301eb426b32623366565 upstream.
Every other arch declares struct termio in asm/termios.h, so make sparc
match them.
Resolves a build failure in the PPP software package, which includes
both bits/ioctl-types.h via sys/ioctl.h (glibc) and asm/termbits.h.
Closes: https://bugs.gentoo.org/918992
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
Cc: stable@vger.kernel.org
Reviewed-by: Andreas Larsson <andreas@gaisler.com>
Tested-by: Andreas Larsson <andreas@gaisler.com>
Link: https://lore.kernel.org/r/20240306171149.3843481-1-floppym@gentoo.org
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/sparc/include/uapi/asm/termbits.h | 10 ----------
arch/sparc/include/uapi/asm/termios.h | 9 +++++++++
2 files changed, 9 insertions(+), 10 deletions(-)
--- a/arch/sparc/include/uapi/asm/termbits.h
+++ b/arch/sparc/include/uapi/asm/termbits.h
@@ -10,16 +10,6 @@ typedef unsigned int tcflag_t;
typedef unsigned long tcflag_t;
#endif
-#define NCC 8
-struct termio {
- unsigned short c_iflag; /* input mode flags */
- unsigned short c_oflag; /* output mode flags */
- unsigned short c_cflag; /* control mode flags */
- unsigned short c_lflag; /* local mode flags */
- unsigned char c_line; /* line discipline */
- unsigned char c_cc[NCC]; /* control characters */
-};
-
#define NCCS 17
struct termios {
tcflag_t c_iflag; /* input mode flags */
--- a/arch/sparc/include/uapi/asm/termios.h
+++ b/arch/sparc/include/uapi/asm/termios.h
@@ -40,5 +40,14 @@ struct winsize {
unsigned short ws_ypixel;
};
+#define NCC 8
+struct termio {
+ unsigned short c_iflag; /* input mode flags */
+ unsigned short c_oflag; /* output mode flags */
+ unsigned short c_cflag; /* control mode flags */
+ unsigned short c_lflag; /* local mode flags */
+ unsigned char c_line; /* line discipline */
+ unsigned char c_cc[NCC]; /* control characters */
+};
#endif /* _UAPI_SPARC_TERMIOS_H */
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 118/157] ext4: Fixes len calculation in mpage_journal_page_buffers
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (116 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 117/157] sparc: move struct termio to asm/termios.h Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 119/157] ext4: set type of ac_groups_linear_remaining to __u32 to avoid overflow Greg Kroah-Hartman
` (48 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Ritesh Harjani (IBM), Jan Kara,
Theodore Tso, stable
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
commit c2a09f3d782de952f09a3962d03b939e7fa7ffa4 upstream.
Truncate operation can race with writeback, in which inode->i_size can get
truncated and therefore size - folio_pos() can be negative. This fixes the
len calculation. However this path doesn't get easily triggered even
with data journaling.
Cc: stable@kernel.org # v6.5
Fixes: 80be8c5cc925 ("Fixes: ext4: Make mpage_journal_page_buffers use folio")
Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/cff4953b5c9306aba71e944ab176a5d396b9a1b7.1709182250.git.ritesh.list@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -2334,7 +2334,7 @@ static int mpage_journal_page_buffers(ha
if (folio_pos(folio) + len > size &&
!ext4_verity_in_progress(inode))
- len = size - folio_pos(folio);
+ len = size & (len - 1);
return ext4_journal_folio_buffers(handle, folio, len);
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 119/157] ext4: set type of ac_groups_linear_remaining to __u32 to avoid overflow
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (117 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 118/157] ext4: Fixes len calculation in mpage_journal_page_buffers Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 120/157] ext4: fix mb_cache_entrys e_refcnt leak in ext4_xattr_block_cache_find() Greg Kroah-Hartman
` (47 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Baokun Li, Zhang Yi,
Jan Kara, Theodore Tso
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Baokun Li <libaokun1@huawei.com>
commit 9a9f3a9842927e4af7ca10c19c94dad83bebd713 upstream.
Now ac_groups_linear_remaining is of type __u16 and s_mb_max_linear_groups
is of type unsigned int, so an overflow occurs when setting a value above
65535 through the mb_max_linear_groups sysfs interface. Therefore, the
type of ac_groups_linear_remaining is set to __u32 to avoid overflow.
Fixes: 196e402adf2e ("ext4: improve cr 0 / cr 1 group scanning")
CC: stable@kernel.org
Signed-off-by: Baokun Li <libaokun1@huawei.com>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20240319113325.3110393-8-libaokun1@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/mballoc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/ext4/mballoc.h
+++ b/fs/ext4/mballoc.h
@@ -193,8 +193,8 @@ struct ext4_allocation_context {
ext4_grpblk_t ac_orig_goal_len;
__u32 ac_flags; /* allocation hints */
+ __u32 ac_groups_linear_remaining;
__u16 ac_groups_scanned;
- __u16 ac_groups_linear_remaining;
__u16 ac_found;
__u16 ac_cX_found[EXT4_MB_NUM_CRS];
__u16 ac_tail;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 120/157] ext4: fix mb_cache_entrys e_refcnt leak in ext4_xattr_block_cache_find()
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (118 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 119/157] ext4: set type of ac_groups_linear_remaining to __u32 to avoid overflow Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 121/157] riscv: dts: starfive: Remove PMIC interrupt info for Visionfive 2 board Greg Kroah-Hartman
` (46 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, syzbot+dd43bd0f7474512edc47, stable,
Baokun Li, Jan Kara, Theodore Tso
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Baokun Li <libaokun1@huawei.com>
commit 0c0b4a49d3e7f49690a6827a41faeffad5df7e21 upstream.
Syzbot reports a warning as follows:
============================================
WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290
Modules linked in:
CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7
RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419
Call Trace:
<TASK>
ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375
generic_shutdown_super+0x136/0x2d0 fs/super.c:641
kill_block_super+0x44/0x90 fs/super.c:1675
ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327
[...]
============================================
This is because when finding an entry in ext4_xattr_block_cache_find(), if
ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown
in the __entry_find(), won't be put away, and eventually trigger the above
issue in mb_cache_destroy() due to reference count leakage.
So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.
Reported-by: syzbot+dd43bd0f7474512edc47@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=dd43bd0f7474512edc47
Fixes: fb265c9cb49e ("ext4: add ext4_sb_bread() to disambiguate ENOMEM cases")
Cc: stable@kernel.org
Signed-off-by: Baokun Li <libaokun1@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20240504075526.2254349-2-libaokun@huaweicloud.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/xattr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -3113,8 +3113,10 @@ ext4_xattr_block_cache_find(struct inode
bh = ext4_sb_bread(inode->i_sb, ce->e_value, REQ_PRIO);
if (IS_ERR(bh)) {
- if (PTR_ERR(bh) == -ENOMEM)
+ if (PTR_ERR(bh) == -ENOMEM) {
+ mb_cache_entry_put(ea_block_cache, ce);
return NULL;
+ }
bh = NULL;
EXT4_ERROR_INODE(inode, "block %lu read error",
(unsigned long)ce->e_value);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 121/157] riscv: dts: starfive: Remove PMIC interrupt info for Visionfive 2 board
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (119 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 120/157] ext4: fix mb_cache_entrys e_refcnt leak in ext4_xattr_block_cache_find() Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 122/157] ARM: dts: samsung: smdkv310: fix keypad no-autorepeat Greg Kroah-Hartman
` (45 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Bo Gan, Shengyu Qu, Conor Dooley
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shengyu Qu <wiagn233@outlook.com>
commit 0f74c64f0a9f6e1e7cf17bea3d4350fa6581e0d7 upstream.
Interrupt line number of the AXP15060 PMIC is not a necessary part of
its device tree. Originally the binding required one, so the dts patch
added an invalid interrupt that the driver ignored (0) as the interrupt
line of the PMIC is not actually connected on this platform. This went
unnoticed during review as it would have been a valid interrupt for a
GPIO controller, but it is not for the PLIC. The PLIC, on this platform
at least, silently ignores the enablement of interrupt 0. Bo Gan is
running a modified version of OpenSBI that faults if writes are done to
reserved fields, so their kernel runs into problems.
Delete the invalid interrupt from the device tree.
Cc: stable@vger.kernel.org
Reported-by: Bo Gan <ganboing@gmail.com>
Link: https://lore.kernel.org/all/c8b6e960-2459-130f-e4e4-7c9c2ebaa6d3@gmail.com/
Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
Fixes: 2378341504de ("riscv: dts: starfive: Enable axp15060 pmic for cpufreq")
[conor: rewrite the commit message to add more detail]
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi | 1 -
1 file changed, 1 deletion(-)
--- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
@@ -238,7 +238,6 @@
axp15060: pmic@36 {
compatible = "x-powers,axp15060";
reg = <0x36>;
- interrupts = <0>;
interrupt-controller;
#interrupt-cells = <1>;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 122/157] ARM: dts: samsung: smdkv310: fix keypad no-autorepeat
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (120 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 121/157] riscv: dts: starfive: Remove PMIC interrupt info for Visionfive 2 board Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 123/157] ARM: dts: samsung: smdk4412: " Greg Kroah-Hartman
` (44 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Krzysztof Kozlowski
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
commit 87d8e522d6f5a004f0aa06c0def302df65aff296 upstream.
Although the Samsung SoC keypad binding defined
linux,keypad-no-autorepeat property, Linux driver never implemented it
and always used linux,input-no-autorepeat. Correct the DTS to use
property actually implemented.
This also fixes dtbs_check errors like:
exynos4210-smdkv310.dtb: keypad@100a0000: 'linux,keypad-no-autorepeat' does not match any of the regexes: '^key-[0-9a-z]+$', 'pinctrl-[0-9]+'
Cc: <stable@vger.kernel.org>
Fixes: 0561ceabd0f1 ("ARM: dts: Add intial dts file for EXYNOS4210 SoC, SMDKV310 and ORIGEN")
Link: https://lore.kernel.org/r/20240312183105.715735-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/samsung/exynos4210-smdkv310.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/samsung/exynos4210-smdkv310.dts
+++ b/arch/arm/boot/dts/samsung/exynos4210-smdkv310.dts
@@ -88,7 +88,7 @@
&keypad {
samsung,keypad-num-rows = <2>;
samsung,keypad-num-columns = <8>;
- linux,keypad-no-autorepeat;
+ linux,input-no-autorepeat;
wakeup-source;
pinctrl-names = "default";
pinctrl-0 = <&keypad_rows &keypad_cols>;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 123/157] ARM: dts: samsung: smdk4412: fix keypad no-autorepeat
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (121 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 122/157] ARM: dts: samsung: smdkv310: fix keypad no-autorepeat Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 124/157] ARM: dts: samsung: exynos4412-origen: " Greg Kroah-Hartman
` (43 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Krzysztof Kozlowski
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
commit 4ac4c1d794e7ff454d191bbdab7585ed8dbf3758 upstream.
Although the Samsung SoC keypad binding defined
linux,keypad-no-autorepeat property, Linux driver never implemented it
and always used linux,input-no-autorepeat. Correct the DTS to use
property actually implemented.
This also fixes dtbs_check errors like:
exynos4412-smdk4412.dtb: keypad@100a0000: 'key-A', 'key-B', 'key-C', 'key-D', 'key-E', 'linux,keypad-no-autorepeat' do not match any of the regexes: '^key-[0-9a-z]+$', 'pinctrl-[0-9]+'
Cc: <stable@vger.kernel.org>
Fixes: c9b92dd70107 ("ARM: dts: Add keypad entries to SMDK4412")
Link: https://lore.kernel.org/r/20240312183105.715735-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/samsung/exynos4412-smdk4412.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/samsung/exynos4412-smdk4412.dts
+++ b/arch/arm/boot/dts/samsung/exynos4412-smdk4412.dts
@@ -69,7 +69,7 @@
&keypad {
samsung,keypad-num-rows = <3>;
samsung,keypad-num-columns = <8>;
- linux,keypad-no-autorepeat;
+ linux,input-no-autorepeat;
wakeup-source;
pinctrl-0 = <&keypad_rows &keypad_cols>;
pinctrl-names = "default";
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 124/157] ARM: dts: samsung: exynos4412-origen: fix keypad no-autorepeat
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (122 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 123/157] ARM: dts: samsung: smdk4412: " Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 125/157] parisc: Define HAVE_ARCH_HUGETLB_UNMAPPED_AREA Greg Kroah-Hartman
` (42 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Krzysztof Kozlowski
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
commit 88208d3cd79821117fd3fb80d9bcab618467d37b upstream.
Although the Samsung SoC keypad binding defined
linux,keypad-no-autorepeat property, Linux driver never implemented it
and always used linux,input-no-autorepeat. Correct the DTS to use
property actually implemented.
This also fixes dtbs_check errors like:
exynos4412-origen.dtb: keypad@100a0000: 'linux,keypad-no-autorepeat' does not match any of the regexes: '^key-[0-9a-z]+$', 'pinctrl-[0-9]+'
Cc: <stable@vger.kernel.org>
Fixes: bd08f6277e44 ("ARM: dts: Add keypad entries to Exynos4412 based Origen")
Link: https://lore.kernel.org/r/20240312183105.715735-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/samsung/exynos4412-origen.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/samsung/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/samsung/exynos4412-origen.dts
@@ -453,7 +453,7 @@
&keypad {
samsung,keypad-num-rows = <3>;
samsung,keypad-num-columns = <2>;
- linux,keypad-no-autorepeat;
+ linux,input-no-autorepeat;
wakeup-source;
pinctrl-0 = <&keypad_rows &keypad_cols>;
pinctrl-names = "default";
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 125/157] parisc: Define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (123 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 124/157] ARM: dts: samsung: exynos4412-origen: " Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 126/157] parisc: Define sigset_t in parisc uapi header Greg Kroah-Hartman
` (41 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Helge Deller, John David Anglin
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <deller@gmx.de>
commit d4a599910193b85f76c100e30d8551c8794f8c2a upstream.
Define the HAVE_ARCH_HUGETLB_UNMAPPED_AREA macro like other platforms do in
their page.h files to avoid this compile warning:
arch/parisc/mm/hugetlbpage.c:25:1: warning: no previous prototype for 'hugetlb_get_unmapped_area' [-Wmissing-prototypes]
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org # 6.0+
Reported-by: John David Anglin <dave.anglin@bell.net>
Tested-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/parisc/include/asm/page.h | 1 +
1 file changed, 1 insertion(+)
--- a/arch/parisc/include/asm/page.h
+++ b/arch/parisc/include/asm/page.h
@@ -8,6 +8,7 @@
#define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT)
#define PAGE_MASK (~(PAGE_SIZE-1))
+#define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
#ifndef __ASSEMBLY__
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 126/157] parisc: Define sigset_t in parisc uapi header
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (124 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 125/157] parisc: Define HAVE_ARCH_HUGETLB_UNMAPPED_AREA Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 127/157] s390/ap: Fix crash in AP internal function modify_bitmap() Greg Kroah-Hartman
` (40 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Helge Deller
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <deller@kernel.org>
commit 487fa28fa8b60417642ac58e8beda6e2509d18f9 upstream.
The util-linux debian package fails to build on parisc, because
sigset_t isn't defined in asm/signal.h when included from userspace.
Move the sigset_t type from internal header to the uapi header to fix the
build.
Link: https://buildd.debian.org/status/fetch.php?pkg=util-linux&arch=hppa&ver=2.40-7&stamp=1714163443&raw=0
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org # v6.0+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/parisc/include/asm/signal.h | 12 ------------
arch/parisc/include/uapi/asm/signal.h | 10 ++++++++++
2 files changed, 10 insertions(+), 12 deletions(-)
--- a/arch/parisc/include/asm/signal.h
+++ b/arch/parisc/include/asm/signal.h
@@ -4,23 +4,11 @@
#include <uapi/asm/signal.h>
-#define _NSIG 64
-/* bits-per-word, where word apparently means 'long' not 'int' */
-#define _NSIG_BPW BITS_PER_LONG
-#define _NSIG_WORDS (_NSIG / _NSIG_BPW)
-
# ifndef __ASSEMBLY__
/* Most things should be clean enough to redefine this at will, if care
is taken to make libc match. */
-typedef unsigned long old_sigset_t; /* at least 32 bits */
-
-typedef struct {
- /* next_signal() assumes this is a long - no choice */
- unsigned long sig[_NSIG_WORDS];
-} sigset_t;
-
#include <asm/sigcontext.h>
#endif /* !__ASSEMBLY */
--- a/arch/parisc/include/uapi/asm/signal.h
+++ b/arch/parisc/include/uapi/asm/signal.h
@@ -57,10 +57,20 @@
#include <asm-generic/signal-defs.h>
+#define _NSIG 64
+#define _NSIG_BPW (sizeof(unsigned long) * 8)
+#define _NSIG_WORDS (_NSIG / _NSIG_BPW)
+
# ifndef __ASSEMBLY__
# include <linux/types.h>
+typedef unsigned long old_sigset_t; /* at least 32 bits */
+
+typedef struct {
+ unsigned long sig[_NSIG_WORDS];
+} sigset_t;
+
/* Avoid too many header ordering problems. */
struct siginfo;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 127/157] s390/ap: Fix crash in AP internal function modify_bitmap()
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (125 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 126/157] parisc: Define sigset_t in parisc uapi header Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 128/157] s390/cpacf: Split and rework cpacf query functions Greg Kroah-Hartman
` (39 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Marc Hartmayer, Harald Freudenberger,
Holger Dengler, Heiko Carstens
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Harald Freudenberger <freude@linux.ibm.com>
commit d4f9d5a99a3fd1b1c691b7a1a6f8f3f25f4116c9 upstream.
A system crash like this
Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403
Fault in home space mode while using kernel ASCE.
AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d
Oops: 0038 ilc:3 [#1] PREEMPT SMP
Modules linked in: mlx5_ib ...
CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8
Hardware name: IBM 3931 A01 704 (LPAR)
Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3
000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0
000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff
000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8
Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a
0000014b75e7b600: 18b2 lr %r11,%r2
#0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616
>0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13)
0000014b75e7b60c: a7680001 lhi %r6,1
0000014b75e7b610: 187b lr %r7,%r11
0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654
0000014b75e7b616: 18e9 lr %r14,%r9
Call Trace:
[<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8
([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8)
[<0000014b75e7b758>] apmask_store+0x68/0x140
[<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8
[<0000014b75598524>] vfs_write+0x1b4/0x448
[<0000014b7559894c>] ksys_write+0x74/0x100
[<0000014b7618a440>] __do_syscall+0x268/0x328
[<0000014b761a3558>] system_call+0x70/0x98
INFO: lockdep is turned off.
Last Breaking-Event-Address:
[<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8
Kernel panic - not syncing: Fatal exception: panic_on_oops
occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value
(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.
The fix is simple: use unsigned long values for the internal variables. The
correct checks are already in place in the function but a simple int for
the internal variables was used with the possibility to overflow.
Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Tested-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/s390/crypto/ap_bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/s390/crypto/ap_bus.c
+++ b/drivers/s390/crypto/ap_bus.c
@@ -1129,7 +1129,7 @@ static int hex2bitmap(const char *str, u
*/
static int modify_bitmap(const char *str, unsigned long *bitmap, int bits)
{
- int a, i, z;
+ unsigned long a, i, z;
char *np, sign;
/* bits needs to be a multiple of 8 */
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 128/157] s390/cpacf: Split and rework cpacf query functions
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (126 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 127/157] s390/ap: Fix crash in AP internal function modify_bitmap() Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 129/157] s390/cpacf: Make use of invalid opcode produce a link error Greg Kroah-Hartman
` (38 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Nina Schoetterl-Glausch,
Heiko Carstens, Juergen Christ, Holger Dengler,
Harald Freudenberger
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Harald Freudenberger <freude@linux.ibm.com>
commit 830999bd7e72f4128b9dfa37090d9fa8120ce323 upstream.
Rework the cpacf query functions to use the correct RRE
or RRF instruction formats and set register fields within
instructions correctly.
Fixes: 1afd43e0fbba ("s390/crypto: allow to query all known cpacf functions")
Reported-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
Suggested-by: Heiko Carstens <hca@linux.ibm.com>
Suggested-by: Juergen Christ <jchrist@linux.ibm.com>
Suggested-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
Reviewed-by: Juergen Christ <jchrist@linux.ibm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/s390/include/asm/cpacf.h | 101 +++++++++++++++++++++++++++++++++---------
1 file changed, 81 insertions(+), 20 deletions(-)
--- a/arch/s390/include/asm/cpacf.h
+++ b/arch/s390/include/asm/cpacf.h
@@ -166,28 +166,79 @@
typedef struct { unsigned char bytes[16]; } cpacf_mask_t;
-/**
- * cpacf_query() - check if a specific CPACF function is available
- * @opcode: the opcode of the crypto instruction
- * @func: the function code to test for
- *
- * Executes the query function for the given crypto instruction @opcode
- * and checks if @func is available
- *
- * Returns 1 if @func is available for @opcode, 0 otherwise
- */
-static __always_inline void __cpacf_query(unsigned int opcode, cpacf_mask_t *mask)
+static __always_inline void __cpacf_query_rre(u32 opc, u8 r1, u8 r2,
+ cpacf_mask_t *mask)
+{
+ asm volatile(
+ " la %%r1,%[mask]\n"
+ " xgr %%r0,%%r0\n"
+ " .insn rre,%[opc] << 16,%[r1],%[r2]\n"
+ : [mask] "=R" (*mask)
+ : [opc] "i" (opc),
+ [r1] "i" (r1), [r2] "i" (r2)
+ : "cc", "r0", "r1");
+}
+
+static __always_inline void __cpacf_query_rrf(u32 opc,
+ u8 r1, u8 r2, u8 r3, u8 m4,
+ cpacf_mask_t *mask)
{
asm volatile(
- " lghi 0,0\n" /* query function */
- " lgr 1,%[mask]\n"
- " spm 0\n" /* pckmo doesn't change the cc */
- /* Parameter regs are ignored, but must be nonzero and unique */
- "0: .insn rrf,%[opc] << 16,2,4,6,0\n"
- " brc 1,0b\n" /* handle partial completion */
- : "=m" (*mask)
- : [mask] "d" ((unsigned long)mask), [opc] "i" (opcode)
- : "cc", "0", "1");
+ " la %%r1,%[mask]\n"
+ " xgr %%r0,%%r0\n"
+ " .insn rrf,%[opc] << 16,%[r1],%[r2],%[r3],%[m4]\n"
+ : [mask] "=R" (*mask)
+ : [opc] "i" (opc), [r1] "i" (r1), [r2] "i" (r2),
+ [r3] "i" (r3), [m4] "i" (m4)
+ : "cc", "r0", "r1");
+}
+
+static __always_inline void __cpacf_query(unsigned int opcode,
+ cpacf_mask_t *mask)
+{
+ switch (opcode) {
+ case CPACF_KDSA:
+ __cpacf_query_rre(CPACF_KDSA, 0, 2, mask);
+ break;
+ case CPACF_KIMD:
+ __cpacf_query_rre(CPACF_KIMD, 0, 2, mask);
+ break;
+ case CPACF_KLMD:
+ __cpacf_query_rre(CPACF_KLMD, 0, 2, mask);
+ break;
+ case CPACF_KM:
+ __cpacf_query_rre(CPACF_KM, 2, 4, mask);
+ break;
+ case CPACF_KMA:
+ __cpacf_query_rrf(CPACF_KMA, 2, 4, 6, 0, mask);
+ break;
+ case CPACF_KMAC:
+ __cpacf_query_rre(CPACF_KMAC, 0, 2, mask);
+ break;
+ case CPACF_KMC:
+ __cpacf_query_rre(CPACF_KMC, 2, 4, mask);
+ break;
+ case CPACF_KMCTR:
+ __cpacf_query_rrf(CPACF_KMCTR, 2, 4, 6, 0, mask);
+ break;
+ case CPACF_KMF:
+ __cpacf_query_rre(CPACF_KMF, 2, 4, mask);
+ break;
+ case CPACF_KMO:
+ __cpacf_query_rre(CPACF_KMO, 2, 4, mask);
+ break;
+ case CPACF_PCC:
+ __cpacf_query_rre(CPACF_PCC, 0, 0, mask);
+ break;
+ case CPACF_PCKMO:
+ __cpacf_query_rre(CPACF_PCKMO, 0, 0, mask);
+ break;
+ case CPACF_PRNO:
+ __cpacf_query_rre(CPACF_PRNO, 2, 4, mask);
+ break;
+ default:
+ BUG();
+ }
}
static __always_inline int __cpacf_check_opcode(unsigned int opcode)
@@ -215,6 +266,16 @@ static __always_inline int __cpacf_check
}
}
+/**
+ * cpacf_query() - check if a specific CPACF function is available
+ * @opcode: the opcode of the crypto instruction
+ * @func: the function code to test for
+ *
+ * Executes the query function for the given crypto instruction @opcode
+ * and checks if @func is available
+ *
+ * Returns 1 if @func is available for @opcode, 0 otherwise
+ */
static __always_inline int cpacf_query(unsigned int opcode, cpacf_mask_t *mask)
{
if (__cpacf_check_opcode(opcode)) {
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 129/157] s390/cpacf: Make use of invalid opcode produce a link error
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (127 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 128/157] s390/cpacf: Split and rework cpacf query functions Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 130/157] i3c: master: svc: fix invalidate IBI type and miss call client IBI handler Greg Kroah-Hartman
` (37 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Heiko Carstens, Harald Freudenberger,
Holger Dengler, Juergen Christ
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Harald Freudenberger <freude@linux.ibm.com>
commit 32e8bd6423fc127d2b37bdcf804fd76af3bbec79 upstream.
Instead of calling BUG() at runtime introduce and use a prototype for a
non-existing function to produce a link error during compile when a not
supported opcode is used with the __cpacf_query() or __cpacf_check_opcode()
inline functions.
Suggested-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
Reviewed-by: Juergen Christ <jchrist@linux.ibm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/s390/include/asm/cpacf.h | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/arch/s390/include/asm/cpacf.h
+++ b/arch/s390/include/asm/cpacf.h
@@ -166,6 +166,13 @@
typedef struct { unsigned char bytes[16]; } cpacf_mask_t;
+/*
+ * Prototype for a not existing function to produce a link
+ * error if __cpacf_query() or __cpacf_check_opcode() is used
+ * with an invalid compile time const opcode.
+ */
+void __cpacf_bad_opcode(void);
+
static __always_inline void __cpacf_query_rre(u32 opc, u8 r1, u8 r2,
cpacf_mask_t *mask)
{
@@ -237,7 +244,7 @@ static __always_inline void __cpacf_quer
__cpacf_query_rre(CPACF_PRNO, 2, 4, mask);
break;
default:
- BUG();
+ __cpacf_bad_opcode();
}
}
@@ -262,7 +269,8 @@ static __always_inline int __cpacf_check
case CPACF_KMA:
return test_facility(146); /* check for MSA8 */
default:
- BUG();
+ __cpacf_bad_opcode();
+ return 0;
}
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 130/157] i3c: master: svc: fix invalidate IBI type and miss call client IBI handler
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (128 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 129/157] s390/cpacf: Make use of invalid opcode produce a link error Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 131/157] genirq/irqdesc: Prevent use-after-free in irq_find_at_or_after() Greg Kroah-Hartman
` (36 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Frank Li, Miquel Raynal,
Alexandre Belloni
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Frank Li <Frank.Li@nxp.com>
commit 38baed9b8600008e5d7bc8cb9ceccc1af3dd54b7 upstream.
In an In-Band Interrupt (IBI) handle, the code logic is as follows:
1: writel(SVC_I3C_MCTRL_REQUEST_AUTO_IBI | SVC_I3C_MCTRL_IBIRESP_AUTO,
master->regs + SVC_I3C_MCTRL);
2: ret = readl_relaxed_poll_timeout(master->regs + SVC_I3C_MSTATUS, val,
SVC_I3C_MSTATUS_IBIWON(val), 0, 1000);
...
3: ibitype = SVC_I3C_MSTATUS_IBITYPE(status);
ibiaddr = SVC_I3C_MSTATUS_IBIADDR(status);
SVC_I3C_MSTATUS_IBIWON may be set before step 1. Thus, step 2 will return
immediately, and the I3C controller has not sent out the 9th SCL yet.
Consequently, ibitype and ibiaddr are 0, resulting in an unknown IBI type
occurrence and missing call I3C client driver's IBI handler.
A typical case is that SVC_I3C_MSTATUS_IBIWON is set when an IBI occurs
during the controller send start frame in svc_i3c_master_xfer().
Clear SVC_I3C_MSTATUS_IBIWON before issue SVC_I3C_MCTRL_REQUEST_AUTO_IBI
to fix this issue.
Cc: stable@vger.kernel.org
Fixes: 5e5e3c92e748 ("i3c: master: svc: fix wrong data return when IBI happen during start frame")
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20240506164009.21375-3-Frank.Li@nxp.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/i3c/master/svc-i3c-master.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/drivers/i3c/master/svc-i3c-master.c
+++ b/drivers/i3c/master/svc-i3c-master.c
@@ -415,6 +415,19 @@ static void svc_i3c_master_ibi_work(stru
int ret;
mutex_lock(&master->lock);
+ /*
+ * IBIWON may be set before SVC_I3C_MCTRL_REQUEST_AUTO_IBI, causing
+ * readl_relaxed_poll_timeout() to return immediately. Consequently,
+ * ibitype will be 0 since it was last updated only after the 8th SCL
+ * cycle, leading to missed client IBI handlers.
+ *
+ * A typical scenario is when IBIWON occurs and bus arbitration is lost
+ * at svc_i3c_master_priv_xfers().
+ *
+ * Clear SVC_I3C_MINT_IBIWON before sending SVC_I3C_MCTRL_REQUEST_AUTO_IBI.
+ */
+ writel(SVC_I3C_MINT_IBIWON, master->regs + SVC_I3C_MSTATUS);
+
/* Acknowledge the incoming interrupt with the AUTOIBI mechanism */
writel(SVC_I3C_MCTRL_REQUEST_AUTO_IBI |
SVC_I3C_MCTRL_IBIRESP_AUTO,
@@ -429,9 +442,6 @@ static void svc_i3c_master_ibi_work(stru
goto reenable_ibis;
}
- /* Clear the interrupt status */
- writel(SVC_I3C_MINT_IBIWON, master->regs + SVC_I3C_MSTATUS);
-
status = readl(master->regs + SVC_I3C_MSTATUS);
ibitype = SVC_I3C_MSTATUS_IBITYPE(status);
ibiaddr = SVC_I3C_MSTATUS_IBIADDR(status);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 131/157] genirq/irqdesc: Prevent use-after-free in irq_find_at_or_after()
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (129 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 130/157] i3c: master: svc: fix invalidate IBI type and miss call client IBI handler Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 132/157] hwmon: (ltc2992) Fix memory leak in ltc2992_parse_dt() Greg Kroah-Hartman
` (35 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, dicken.ding, Thomas Gleixner
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: dicken.ding <dicken.ding@mediatek.com>
commit b84a8aba806261d2f759ccedf4a2a6a80a5e55ba upstream.
irq_find_at_or_after() dereferences the interrupt descriptor which is
returned by mt_find() while neither holding sparse_irq_lock nor RCU read
lock, which means the descriptor can be freed between mt_find() and the
dereference:
CPU0 CPU1
desc = mt_find()
delayed_free_desc(desc)
irq_desc_get_irq(desc)
The use-after-free is reported by KASAN:
Call trace:
irq_get_next_irq+0x58/0x84
show_stat+0x638/0x824
seq_read_iter+0x158/0x4ec
proc_reg_read_iter+0x94/0x12c
vfs_read+0x1e0/0x2c8
Freed by task 4471:
slab_free_freelist_hook+0x174/0x1e0
__kmem_cache_free+0xa4/0x1dc
kfree+0x64/0x128
irq_kobj_release+0x28/0x3c
kobject_put+0xcc/0x1e0
delayed_free_desc+0x14/0x2c
rcu_do_batch+0x214/0x720
Guard the access with a RCU read lock section.
Fixes: 721255b9826b ("genirq: Use a maple tree for interrupt descriptor management")
Signed-off-by: dicken.ding <dicken.ding@mediatek.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240524091739.31611-1-dicken.ding@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/irq/irqdesc.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -160,7 +160,10 @@ static int irq_find_free_area(unsigned i
static unsigned int irq_find_at_or_after(unsigned int offset)
{
unsigned long index = offset;
- struct irq_desc *desc = mt_find(&sparse_irqs, &index, nr_irqs);
+ struct irq_desc *desc;
+
+ guard(rcu)();
+ desc = mt_find(&sparse_irqs, &index, nr_irqs);
return desc ? irq_desc_get_irq(desc) : nr_irqs;
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 132/157] hwmon: (ltc2992) Fix memory leak in ltc2992_parse_dt()
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (130 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 131/157] genirq/irqdesc: Prevent use-after-free in irq_find_at_or_after() Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 133/157] riscv: enable HAVE_ARCH_HUGE_VMAP for XIP kernel Greg Kroah-Hartman
` (34 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Javier Carrasco, Guenter Roeck
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
commit a94ff8e50c20bde6d50864849a98b106e45d30c6 upstream.
A new error path was added to the fwnode_for_each_available_node() loop
in ltc2992_parse_dt(), which leads to an early return that requires a
call to fwnode_handle_put() to avoid a memory leak in that case.
Add the missing fwnode_handle_put() in the error path from a zero value
shunt resistor.
Cc: stable@vger.kernel.org
Fixes: 10b029020487 ("hwmon: (ltc2992) Avoid division by zero")
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20240523-fwnode_for_each_available_child_node_scoped-v2-1-701f3a03f2fb@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hwmon/ltc2992.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/hwmon/ltc2992.c
+++ b/drivers/hwmon/ltc2992.c
@@ -876,9 +876,11 @@ static int ltc2992_parse_dt(struct ltc29
ret = fwnode_property_read_u32(child, "shunt-resistor-micro-ohms", &val);
if (!ret) {
- if (!val)
+ if (!val) {
+ fwnode_handle_put(child);
return dev_err_probe(&st->client->dev, -EINVAL,
"shunt resistor value cannot be zero\n");
+ }
st->r_sense_uohm[addr] = val;
}
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 133/157] riscv: enable HAVE_ARCH_HUGE_VMAP for XIP kernel
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (131 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 132/157] hwmon: (ltc2992) Fix memory leak in ltc2992_parse_dt() Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 134/157] ASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension Greg Kroah-Hartman
` (33 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Nam Cao, Alexandre Ghiti,
Palmer Dabbelt
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nam Cao <namcao@linutronix.de>
commit 7bed51617401dab2be930b13ed5aacf581f7c8ef upstream.
HAVE_ARCH_HUGE_VMAP also works on XIP kernel, so remove its dependency on
!XIP_KERNEL.
This also fixes a boot problem for XIP kernel introduced by the commit in
"Fixes:". This commit used huge page mapping for vmemmap, but huge page
vmap was not enabled for XIP kernel.
Fixes: ff172d4818ad ("riscv: Use hugepage mappings for vmemmap")
Signed-off-by: Nam Cao <namcao@linutronix.de>
Cc: <stable@vger.kernel.org>
Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Link: https://lore.kernel.org/r/20240526110104.470429-1-namcao@linutronix.de
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/riscv/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -103,7 +103,7 @@ config RISCV
select HAS_IOPORT if MMU
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP
- select HAVE_ARCH_HUGE_VMAP if MMU && 64BIT && !XIP_KERNEL
+ select HAVE_ARCH_HUGE_VMAP if MMU && 64BIT
select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
select HAVE_ARCH_JUMP_LABEL_RELATIVE if !XIP_KERNEL
select HAVE_ARCH_KASAN if MMU && 64BIT
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 134/157] ASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (132 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 133/157] riscv: enable HAVE_ARCH_HUGE_VMAP for XIP kernel Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 135/157] ALSA: ump: Dont clear bank selection after sending a program change Greg Kroah-Hartman
` (32 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Peter Ujfalusi, Pierre-Louis Bossart,
Seppo Ingalsuo, Ranjani Sridharan, Mark Brown
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
commit ffa077b2f6ad124ec3d23fbddc5e4b0ff2647af8 upstream.
If a process module does not have base config extension then the same
format applies to all of it's inputs and the process->base_config_ext is
NULL, causing NULL dereference when specifically crafted topology and
sequences used.
Fixes: 648fea128476 ("ASoC: SOF: ipc4-topology: set copier output format for process module")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://msgid.link/r/20240529121201.14687-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/sof/ipc4-topology.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/sound/soc/sof/ipc4-topology.c
+++ b/sound/soc/sof/ipc4-topology.c
@@ -217,6 +217,14 @@ sof_ipc4_get_input_pin_audio_fmt(struct
}
process = swidget->private;
+
+ /*
+ * For process modules without base config extension, base module config
+ * format is used for all input pins
+ */
+ if (process->init_config != SOF_IPC4_MODULE_INIT_CONFIG_TYPE_BASE_CFG_WITH_EXT)
+ return &process->base_config.audio_fmt;
+
base_cfg_ext = process->base_config_ext;
/*
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 135/157] ALSA: ump: Dont clear bank selection after sending a program change
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (133 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 134/157] ASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 136/157] ALSA: ump: Dont accept an invalid UMP protocol number Greg Kroah-Hartman
` (31 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Takashi Iwai
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit fe85f6e607d75b856e7229924c71f55e005f8284 upstream.
The current code clears the bank selection MSB/LSB after sending a
program change, but this can be wrong, as many apps may not send the
full bank selection with both MSB and LSB but sending only one.
Better to keep the previous bank set.
Fixes: 0b5288f5fe63 ("ALSA: ump: Add legacy raw MIDI support")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20240529083823.5778-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/ump_convert.c | 1 -
1 file changed, 1 deletion(-)
--- a/sound/core/ump_convert.c
+++ b/sound/core/ump_convert.c
@@ -404,7 +404,6 @@ static int cvt_legacy_cmd_to_ump(struct
midi2->pg.bank_msb = cc->cc_bank_msb;
midi2->pg.bank_lsb = cc->cc_bank_lsb;
cc->bank_set = 0;
- cc->cc_bank_msb = cc->cc_bank_lsb = 0;
}
break;
case UMP_MSG_STATUS_CHANNEL_PRESSURE:
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 136/157] ALSA: ump: Dont accept an invalid UMP protocol number
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (134 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 135/157] ALSA: ump: Dont clear bank selection after sending a program change Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 137/157] EDAC/amd64: Convert PCIBIOS_* return codes to errnos Greg Kroah-Hartman
` (30 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Takashi Iwai
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit ac0d71ee534e67c7e53439e8e9cb45ed40731660 upstream.
When a UMP Stream Configuration message is received, the driver tries
to switch the protocol, but there was no sanity check of the protocol,
hence it can pass an invalid value. Add the check and bail out if a
wrong value is passed.
Fixes: a79807683781 ("ALSA: ump: Add helper to change MIDI protocol")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20240529164723.18309-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/ump.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/sound/core/ump.c
+++ b/sound/core/ump.c
@@ -685,10 +685,17 @@ static void seq_notify_protocol(struct s
*/
int snd_ump_switch_protocol(struct snd_ump_endpoint *ump, unsigned int protocol)
{
+ unsigned int type;
+
protocol &= ump->info.protocol_caps;
if (protocol == ump->info.protocol)
return 0;
+ type = protocol & SNDRV_UMP_EP_INFO_PROTO_MIDI_MASK;
+ if (type != SNDRV_UMP_EP_INFO_PROTO_MIDI1 &&
+ type != SNDRV_UMP_EP_INFO_PROTO_MIDI2)
+ return 0;
+
ump->info.protocol = protocol;
ump_dbg(ump, "New protocol = %x (caps = %x)\n",
protocol, ump->info.protocol_caps);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 137/157] EDAC/amd64: Convert PCIBIOS_* return codes to errnos
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (135 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 136/157] ALSA: ump: Dont accept an invalid UMP protocol number Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 138/157] EDAC/igen6: " Greg Kroah-Hartman
` (29 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Ilpo Järvinen,
Borislav Petkov (AMD)
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
commit 3ec8ebd8a5b782d56347ae884de880af26f93996 upstream.
gpu_get_node_map() uses pci_read_config_dword() that returns PCIBIOS_*
codes. The return code is then returned all the way into the module
init function amd64_edac_init() that returns it as is. The module init
functions, however, should return normal errnos.
Convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal
errno before returning it from gpu_get_node_map().
For consistency, convert also the other similar cases which return
PCIBIOS_* codes even if they do not have any bugs at the moment.
Fixes: 4251566ebc1c ("EDAC/amd64: Cache and use GPU node map")
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240527132236.13875-1-ilpo.jarvinen@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/edac/amd64_edac.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -81,7 +81,7 @@ int __amd64_read_pci_cfg_dword(struct pc
amd64_warn("%s: error reading F%dx%03x.\n",
func, PCI_FUNC(pdev->devfn), offset);
- return err;
+ return pcibios_err_to_errno(err);
}
int __amd64_write_pci_cfg_dword(struct pci_dev *pdev, int offset,
@@ -94,7 +94,7 @@ int __amd64_write_pci_cfg_dword(struct p
amd64_warn("%s: error writing to F%dx%03x.\n",
func, PCI_FUNC(pdev->devfn), offset);
- return err;
+ return pcibios_err_to_errno(err);
}
/*
@@ -1025,8 +1025,10 @@ static int gpu_get_node_map(struct amd64
}
ret = pci_read_config_dword(pdev, REG_LOCAL_NODE_TYPE_MAP, &tmp);
- if (ret)
+ if (ret) {
+ ret = pcibios_err_to_errno(ret);
goto out;
+ }
gpu_node_map.node_count = FIELD_GET(LNTM_NODE_COUNT, tmp);
gpu_node_map.base_node_id = FIELD_GET(LNTM_BASE_NODE_ID, tmp);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 138/157] EDAC/igen6: Convert PCIBIOS_* return codes to errnos
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (136 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 137/157] EDAC/amd64: Convert PCIBIOS_* return codes to errnos Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 139/157] cifs: fix creating sockets when using sfu mount options Greg Kroah-Hartman
` (28 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Ilpo Järvinen,
Borislav Petkov (AMD), Qiuxu Zhuo
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
commit f8367a74aebf88dc8b58a0db6a6c90b4cb8fc9d3 upstream.
errcmd_enable_error_reporting() uses pci_{read,write}_config_word()
that return PCIBIOS_* codes. The return code is then returned all the
way into the probe function igen6_probe() that returns it as is. The
probe functions, however, should return normal errnos.
Convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal
errno before returning it from errcmd_enable_error_reporting().
Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC")
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240527132236.13875-2-ilpo.jarvinen@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/edac/igen6_edac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/edac/igen6_edac.c
+++ b/drivers/edac/igen6_edac.c
@@ -800,7 +800,7 @@ static int errcmd_enable_error_reporting
rc = pci_read_config_word(imc->pdev, ERRCMD_OFFSET, &errcmd);
if (rc)
- return rc;
+ return pcibios_err_to_errno(rc);
if (enable)
errcmd |= ERRCMD_CE | ERRSTS_UE;
@@ -809,7 +809,7 @@ static int errcmd_enable_error_reporting
rc = pci_write_config_word(imc->pdev, ERRCMD_OFFSET, errcmd);
if (rc)
- return rc;
+ return pcibios_err_to_errno(rc);
return 0;
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 139/157] cifs: fix creating sockets when using sfu mount options
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (137 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 138/157] EDAC/igen6: " Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 140/157] nfs: fix undefined behavior in nfs_block_bits() Greg Kroah-Hartman
` (27 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Steve French
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steve French <stfrench@microsoft.com>
commit 518549c120e671c4906f77d1802b97e9b23f673a upstream.
When running fstest generic/423 with sfu mount option, it
was being skipped due to inability to create sockets:
generic/423 [not run] cifs does not support mknod/mkfifo
which can also be easily reproduced with their af_unix tool:
./src/af_unix /mnt1/socket-two bind: Operation not permitted
Fix sfu mount option to allow creating and reporting sockets.
Cc: stable@vger.kernel.org
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/smb/client/cifspdu.h | 2 +-
fs/smb/client/inode.c | 4 ++++
fs/smb/client/smb2ops.c | 3 +++
3 files changed, 8 insertions(+), 1 deletion(-)
--- a/fs/smb/client/cifspdu.h
+++ b/fs/smb/client/cifspdu.h
@@ -2574,7 +2574,7 @@ typedef struct {
struct win_dev {
- unsigned char type[8]; /* IntxCHR or IntxBLK or LnxFIFO*/
+ unsigned char type[8]; /* IntxCHR or IntxBLK or LnxFIFO or LnxSOCK */
__le64 major;
__le64 minor;
} __attribute__((packed));
--- a/fs/smb/client/inode.c
+++ b/fs/smb/client/inode.c
@@ -591,6 +591,10 @@ cifs_sfu_type(struct cifs_fattr *fattr,
mnr = le64_to_cpu(*(__le64 *)(pbuf+16));
fattr->cf_rdev = MKDEV(mjr, mnr);
}
+ } else if (memcmp("LnxSOCK", pbuf, 8) == 0) {
+ cifs_dbg(FYI, "Socket\n");
+ fattr->cf_mode |= S_IFSOCK;
+ fattr->cf_dtype = DT_SOCK;
} else if (memcmp("IntxLNK", pbuf, 7) == 0) {
cifs_dbg(FYI, "Symlink\n");
fattr->cf_mode |= S_IFLNK;
--- a/fs/smb/client/smb2ops.c
+++ b/fs/smb/client/smb2ops.c
@@ -4996,6 +4996,9 @@ static int __cifs_sfu_make_node(unsigned
pdev.major = cpu_to_le64(MAJOR(dev));
pdev.minor = cpu_to_le64(MINOR(dev));
break;
+ case S_IFSOCK:
+ strscpy(pdev.type, "LnxSOCK");
+ break;
case S_IFIFO:
strscpy(pdev.type, "LnxFIFO");
break;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 140/157] nfs: fix undefined behavior in nfs_block_bits()
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (138 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 139/157] cifs: fix creating sockets when using sfu mount options Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 141/157] NFS: Fix READ_PLUS when server doesnt support OP_READ_PLUS Greg Kroah-Hartman
` (26 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Sergey Shtylyov, Benjamin Coddington,
Trond Myklebust
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergey Shtylyov <s.shtylyov@omp.ru>
commit 3c0a2e0b0ae661457c8505fecc7be5501aa7a715 upstream.
Shifting *signed int* typed constant 1 left by 31 bits causes undefined
behavior. Specify the correct *unsigned long* type by using 1UL instead.
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
Cc: stable@vger.kernel.org
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nfs/internal.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -710,9 +710,9 @@ unsigned long nfs_block_bits(unsigned lo
if ((bsize & (bsize - 1)) || nrbitsp) {
unsigned char nrbits;
- for (nrbits = 31; nrbits && !(bsize & (1 << nrbits)); nrbits--)
+ for (nrbits = 31; nrbits && !(bsize & (1UL << nrbits)); nrbits--)
;
- bsize = 1 << nrbits;
+ bsize = 1UL << nrbits;
if (nrbitsp)
*nrbitsp = nrbits;
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 141/157] NFS: Fix READ_PLUS when server doesnt support OP_READ_PLUS
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (139 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 140/157] nfs: fix undefined behavior in nfs_block_bits() Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 142/157] eventfs: Fix a possible null pointer dereference in eventfs_find_events() Greg Kroah-Hartman
` (25 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Olga Kornievskaia, Anna Schumaker,
Benjamin Coddington, Trond Myklebust
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anna Schumaker <Anna.Schumaker@Netapp.com>
commit f06d1b10cb016d5aaecdb1804fefca025387bd10 upstream.
Olga showed me a case where the client was sending multiple READ_PLUS
calls to the server in parallel, and the server replied
NFS4ERR_OPNOTSUPP to each. The client would fall back to READ for the
first reply, but fail to retry the other calls.
I fix this by removing the test for NFS_CAP_READ_PLUS in
nfs4_read_plus_not_supported(). This allows us to reschedule any
READ_PLUS call that has a NFS4ERR_OPNOTSUPP return value, even after the
capability has been cleared.
Reported-by: Olga Kornievskaia <kolga@netapp.com>
Fixes: c567552612ec ("NFS: Add READ_PLUS data segment support")
Cc: stable@vger.kernel.org # v5.10+
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nfs/nfs4proc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -5456,7 +5456,7 @@ static bool nfs4_read_plus_not_supported
struct rpc_message *msg = &task->tk_msg;
if (msg->rpc_proc == &nfs4_procedures[NFSPROC4_CLNT_READ_PLUS] &&
- server->caps & NFS_CAP_READ_PLUS && task->tk_status == -ENOTSUPP) {
+ task->tk_status == -ENOTSUPP) {
server->caps &= ~NFS_CAP_READ_PLUS;
msg->rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_READ];
rpc_restart_call_prepare(task);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 142/157] eventfs: Fix a possible null pointer dereference in eventfs_find_events()
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (140 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 141/157] NFS: Fix READ_PLUS when server doesnt support OP_READ_PLUS Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 143/157] eventfs: Keep the directories from having the same inode number as files Greg Kroah-Hartman
` (24 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Hao Ge, Steven Rostedt (Google)
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hao Ge <gehao@kylinos.cn>
commit d4e9a968738bf66d3bb852dd5588d4c7afd6d7f4 upstream.
In function eventfs_find_events,there is a potential null pointer
that may be caused by calling update_events_attr which will perform
some operations on the members of the ei struct when ei is NULL.
Hence,When ei->is_freed is set,return NULL directly.
Link: https://lore.kernel.org/linux-trace-kernel/20240513053338.63017-1-hao.ge@linux.dev
Cc: stable@vger.kernel.org
Fixes: 8186fff7ab64 ("tracefs/eventfs: Use root and instance inodes as default ownership")
Signed-off-by: Hao Ge <gehao@kylinos.cn>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/tracefs/event_inode.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/fs/tracefs/event_inode.c
+++ b/fs/tracefs/event_inode.c
@@ -345,10 +345,9 @@ static struct eventfs_inode *eventfs_fin
* If the ei is being freed, the ownership of the children
* doesn't matter.
*/
- if (ei->is_freed) {
- ei = NULL;
- break;
- }
+ if (ei->is_freed)
+ return NULL;
+
// Walk upwards until you find the events inode
} while (!ei->is_events);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 143/157] eventfs: Keep the directories from having the same inode number as files
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (141 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 142/157] eventfs: Fix a possible null pointer dereference in eventfs_find_events() Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 144/157] tracefs: Clear EVENT_INODE flag in tracefs_drop_inode() Greg Kroah-Hartman
` (23 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Masahiro Yamada,
Steven Rostedt (Google)
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt (Google) <rostedt@goodmis.org>
commit 8898e7f288c47d450a3cf1511c791a03550c0789 upstream.
The directories require unique inode numbers but all the eventfs files
have the same inode number. Prevent the directories from having the same
inode numbers as the files as that can confuse some tooling.
Link: https://lore.kernel.org/linux-trace-kernel/20240523051539.428826685@goodmis.org
Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Fixes: 834bf76add3e6 ("eventfs: Save directory inodes in the eventfs_inode structure")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/tracefs/event_inode.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/fs/tracefs/event_inode.c
+++ b/fs/tracefs/event_inode.c
@@ -50,8 +50,12 @@ static struct eventfs_root_inode *get_ro
/* Just try to make something consistent and unique */
static int eventfs_dir_ino(struct eventfs_inode *ei)
{
- if (!ei->ino)
+ if (!ei->ino) {
ei->ino = get_next_ino();
+ /* Must not have the file inode number */
+ if (ei->ino == EVENTFS_FILE_INODE_INO)
+ ei->ino = get_next_ino();
+ }
return ei->ino;
}
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 144/157] tracefs: Clear EVENT_INODE flag in tracefs_drop_inode()
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (142 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 143/157] eventfs: Keep the directories from having the same inode number as files Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 145/157] btrfs: qgroup: update rescan message levels and error codes Greg Kroah-Hartman
` (22 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Masahiro Yamada,
Steven Rostedt (Google)
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt (Google) <rostedt@goodmis.org>
commit 0bcfd9aa4dafa03b88d68bf66b694df2a3e76cf3 upstream.
When the inode is being dropped from the dentry, the TRACEFS_EVENT_INODE
flag needs to be cleared to prevent a remount from calling
eventfs_remount() on the tracefs_inode private data. There's a race
between the inode is dropped (and the dentry freed) to where the inode is
actually freed. If a remount happens between the two, the eventfs_inode
could be accessed after it is freed (only the dentry keeps a ref count on
it).
Currently the TRACEFS_EVENT_INODE flag is cleared from the dentry iput()
function. But this is incorrect, as it is possible that the inode has
another reference to it. The flag should only be cleared when the inode is
really being dropped and has no more references. That happens in the
drop_inode callback of the inode, as that gets called when the last
reference of the inode is released.
Remove the tracefs_d_iput() function and move its logic to the more
appropriate tracefs_drop_inode() callback function.
Link: https://lore.kernel.org/linux-trace-kernel/20240523051539.908205106@goodmis.org
Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Fixes: baa23a8d4360d ("tracefs: Reset permissions on remount if permissions are options")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/tracefs/inode.c | 33 +++++++++++++++++----------------
1 file changed, 17 insertions(+), 16 deletions(-)
--- a/fs/tracefs/inode.c
+++ b/fs/tracefs/inode.c
@@ -439,10 +439,26 @@ static int tracefs_show_options(struct s
return 0;
}
+static int tracefs_drop_inode(struct inode *inode)
+{
+ struct tracefs_inode *ti = get_tracefs(inode);
+
+ /*
+ * This inode is being freed and cannot be used for
+ * eventfs. Clear the flag so that it doesn't call into
+ * eventfs during the remount flag updates. The eventfs_inode
+ * gets freed after an RCU cycle, so the content will still
+ * be safe if the iteration is going on now.
+ */
+ ti->flags &= ~TRACEFS_EVENT_INODE;
+
+ return 1;
+}
+
static const struct super_operations tracefs_super_operations = {
.alloc_inode = tracefs_alloc_inode,
.free_inode = tracefs_free_inode,
- .drop_inode = generic_delete_inode,
+ .drop_inode = tracefs_drop_inode,
.statfs = simple_statfs,
.remount_fs = tracefs_remount,
.show_options = tracefs_show_options,
@@ -469,22 +485,7 @@ static int tracefs_d_revalidate(struct d
return !(ei && ei->is_freed);
}
-static void tracefs_d_iput(struct dentry *dentry, struct inode *inode)
-{
- struct tracefs_inode *ti = get_tracefs(inode);
-
- /*
- * This inode is being freed and cannot be used for
- * eventfs. Clear the flag so that it doesn't call into
- * eventfs during the remount flag updates. The eventfs_inode
- * gets freed after an RCU cycle, so the content will still
- * be safe if the iteration is going on now.
- */
- ti->flags &= ~TRACEFS_EVENT_INODE;
-}
-
static const struct dentry_operations tracefs_dentry_operations = {
- .d_iput = tracefs_d_iput,
.d_revalidate = tracefs_d_revalidate,
.d_release = tracefs_d_release,
};
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 145/157] btrfs: qgroup: update rescan message levels and error codes
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (143 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 144/157] tracefs: Clear EVENT_INODE flag in tracefs_drop_inode() Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 146/157] btrfs: qgroup: fix qgroup id collision across mounts Greg Kroah-Hartman
` (21 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Boris Burkov, David Sterba
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Sterba <dsterba@suse.com>
commit 1fa7603d569b9e738e9581937ba8725cd7d39b48 upstream.
On filesystems without enabled quotas there's still a warning message in
the logs when rescan is called. In that case it's not a problem that
should be reported, rescan can be called unconditionally. Change the
error code to ENOTCONN which is used for 'quotas not enabled' elsewhere.
Remove message (also a warning) when rescan is called during an ongoing
rescan, this brings no useful information and the error code is
sufficient.
Change message levels to debug for now, they can be removed eventually.
CC: stable@vger.kernel.org # 6.6+
Reviewed-by: Boris Burkov <boris@bur.io>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/qgroup.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -3826,14 +3826,14 @@ qgroup_rescan_init(struct btrfs_fs_info
/* we're resuming qgroup rescan at mount time */
if (!(fs_info->qgroup_flags &
BTRFS_QGROUP_STATUS_FLAG_RESCAN)) {
- btrfs_warn(fs_info,
+ btrfs_debug(fs_info,
"qgroup rescan init failed, qgroup rescan is not queued");
ret = -EINVAL;
} else if (!(fs_info->qgroup_flags &
BTRFS_QGROUP_STATUS_FLAG_ON)) {
- btrfs_warn(fs_info,
+ btrfs_debug(fs_info,
"qgroup rescan init failed, qgroup is not enabled");
- ret = -EINVAL;
+ ret = -ENOTCONN;
}
if (ret)
@@ -3844,14 +3844,12 @@ qgroup_rescan_init(struct btrfs_fs_info
if (init_flags) {
if (fs_info->qgroup_flags & BTRFS_QGROUP_STATUS_FLAG_RESCAN) {
- btrfs_warn(fs_info,
- "qgroup rescan is already in progress");
ret = -EINPROGRESS;
} else if (!(fs_info->qgroup_flags &
BTRFS_QGROUP_STATUS_FLAG_ON)) {
- btrfs_warn(fs_info,
+ btrfs_debug(fs_info,
"qgroup rescan init failed, qgroup is not enabled");
- ret = -EINVAL;
+ ret = -ENOTCONN;
} else if (btrfs_qgroup_mode(fs_info) == BTRFS_QGROUP_MODE_DISABLED) {
/* Quota disable is in progress */
ret = -EBUSY;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 146/157] btrfs: qgroup: fix qgroup id collision across mounts
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (144 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 145/157] btrfs: qgroup: update rescan message levels and error codes Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 147/157] btrfs: protect folio::private when attaching extent buffer folios Greg Kroah-Hartman
` (20 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Qu Wenruo, Boris Burkov,
David Sterba
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Burkov <boris@bur.io>
commit 2b8aa78cf1279ec5e418baa26bfed5df682568d8 upstream.
If we delete subvolumes whose ID is the largest in the filesystem, then
unmount and mount again, then btrfs_init_root_free_objectid on the
tree_root will select a subvolid smaller than that one and thus allow
reusing it.
If we are also using qgroups (and particularly squotas) it is possible
to delete the subvol without deleting the qgroup. In that case, we will
be able to create a new subvol whose id already has a level 0 qgroup.
This will result in re-using that qgroup which would then lead to
incorrect accounting.
Fixes: 6ed05643ddb1 ("btrfs: create qgroup earlier in snapshot creation")
CC: stable@vger.kernel.org # 6.7+
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Boris Burkov <boris@bur.io>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/qgroup.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -468,6 +468,7 @@ int btrfs_read_qgroup_config(struct btrf
}
if (!qgroup) {
struct btrfs_qgroup *prealloc;
+ struct btrfs_root *tree_root = fs_info->tree_root;
prealloc = kzalloc(sizeof(*prealloc), GFP_KERNEL);
if (!prealloc) {
@@ -475,6 +476,25 @@ int btrfs_read_qgroup_config(struct btrf
goto out;
}
qgroup = add_qgroup_rb(fs_info, prealloc, found_key.offset);
+ /*
+ * If a qgroup exists for a subvolume ID, it is possible
+ * that subvolume has been deleted, in which case
+ * re-using that ID would lead to incorrect accounting.
+ *
+ * Ensure that we skip any such subvol ids.
+ *
+ * We don't need to lock because this is only called
+ * during mount before we start doing things like creating
+ * subvolumes.
+ */
+ if (is_fstree(qgroup->qgroupid) &&
+ qgroup->qgroupid > tree_root->free_objectid)
+ /*
+ * Don't need to check against BTRFS_LAST_FREE_OBJECTID,
+ * as it will get checked on the next call to
+ * btrfs_get_free_objectid.
+ */
+ tree_root->free_objectid = qgroup->qgroupid + 1;
}
ret = btrfs_sysfs_add_one_qgroup(fs_info, qgroup);
if (ret < 0)
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 147/157] btrfs: protect folio::private when attaching extent buffer folios
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (145 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 146/157] btrfs: qgroup: fix qgroup id collision across mounts Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 148/157] btrfs: fix crash on racing fsync and size-extending write into prealloc Greg Kroah-Hartman
` (19 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Linus Torvalds, Mikhail Gavrilov,
Toralf Förster, syzbot+f80b066392366b4af85e, Chris Mason,
Filipe Manana, Josef Bacik, Qu Wenruo, David Sterba
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qu Wenruo <wqu@suse.com>
commit f3a5367c679d31473d3fbb391675055b4792c309 upstream.
[BUG]
Since v6.8 there are rare kernel crashes reported by various people,
the common factor is bad page status error messages like this:
BUG: Bad page state in process kswapd0 pfn:d6e840
page: refcount:0 mapcount:0 mapping:000000007512f4f2 index:0x2796c2c7c
pfn:0xd6e840
aops:btree_aops ino:1
flags: 0x17ffffe0000008(uptodate|node=0|zone=2|lastcpupid=0x3fffff)
page_type: 0xffffffff()
raw: 0017ffffe0000008 dead000000000100 dead000000000122 ffff88826d0be4c0
raw: 00000002796c2c7c 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: non-NULL mapping
[CAUSE]
Commit 09e6cef19c9f ("btrfs: refactor alloc_extent_buffer() to
allocate-then-attach method") changes the sequence when allocating a new
extent buffer.
Previously we always called grab_extent_buffer() under
mapping->i_private_lock, to ensure the safety on modification on
folio::private (which is a pointer to extent buffer for regular
sectorsize).
This can lead to the following race:
Thread A is trying to allocate an extent buffer at bytenr X, with 4
4K pages, meanwhile thread B is trying to release the page at X + 4K
(the second page of the extent buffer at X).
Thread A | Thread B
-----------------------------------+-------------------------------------
| btree_release_folio()
| | This is for the page at X + 4K,
| | Not page X.
| |
alloc_extent_buffer() | |- release_extent_buffer()
|- filemap_add_folio() for the | | |- atomic_dec_and_test(eb->refs)
| page at bytenr X (the first | | |
| page). | | |
| Which returned -EEXIST. | | |
| | | |
|- filemap_lock_folio() | | |
| Returned the first page locked. | | |
| | | |
|- grab_extent_buffer() | | |
| |- atomic_inc_not_zero() | | |
| | Returned false | | |
| |- folio_detach_private() | | |- folio_detach_private() for X
| |- folio_test_private() | | |- folio_test_private()
| Returned true | | | Returned true
|- folio_put() | |- folio_put()
Now there are two puts on the same folio at folio X, leading to refcount
underflow of the folio X, and eventually causing the BUG_ON() on the
page->mapping.
The condition is not that easy to hit:
- The release must be triggered for the middle page of an eb
If the release is on the same first page of an eb, page lock would kick
in and prevent the race.
- folio_detach_private() has a very small race window
It's only between folio_test_private() and folio_clear_private().
That's exactly when mapping->i_private_lock is used to prevent such race,
and commit 09e6cef19c9f ("btrfs: refactor alloc_extent_buffer() to
allocate-then-attach method") screwed that up.
At that time, I thought the page lock would kick in as
filemap_release_folio() also requires the page to be locked, but forgot
the filemap_release_folio() only locks one page, not all pages of an
extent buffer.
[FIX]
Move all the code requiring i_private_lock into
attach_eb_folio_to_filemap(), so that everything is done with proper
lock protection.
Furthermore to prevent future problems, add an extra
lockdep_assert_locked() to ensure we're holding the proper lock.
To reproducer that is able to hit the race (takes a few minutes with
instrumented code inserting delays to alloc_extent_buffer()):
#!/bin/sh
drop_caches () {
while(true); do
echo 3 > /proc/sys/vm/drop_caches
echo 1 > /proc/sys/vm/compact_memory
done
}
run_tar () {
while(true); do
for x in `seq 1 80` ; do
tar cf /dev/zero /mnt > /dev/null &
done
wait
done
}
mkfs.btrfs -f -d single -m single /dev/vda
mount -o noatime /dev/vda /mnt
# create 200,000 files, 1K each
./simoop -n 200000 -E -f 1k /mnt
drop_caches &
(run_tar)
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/linux-btrfs/CAHk-=wgt362nGfScVOOii8cgKn2LVVHeOvOA7OBwg1OwbuJQcw@mail.gmail.com/
Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Link: https://lore.kernel.org/lkml/CABXGCsPktcHQOvKTbPaTwegMExije=Gpgci5NW=hqORo-s7diA@mail.gmail.com/
Reported-by: Toralf Förster <toralf.foerster@gmx.de>
Link: https://lore.kernel.org/linux-btrfs/e8b3311c-9a75-4903-907f-fc0f7a3fe423@gmx.de/
Reported-by: syzbot+f80b066392366b4af85e@syzkaller.appspotmail.com
Fixes: 09e6cef19c9f ("btrfs: refactor alloc_extent_buffer() to allocate-then-attach method")
CC: stable@vger.kernel.org # 6.8+
CC: Chris Mason <clm@fb.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/extent_io.c | 60 ++++++++++++++++++++++++++-------------------------
1 file changed, 31 insertions(+), 29 deletions(-)
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3662,6 +3662,8 @@ static struct extent_buffer *grab_extent
struct folio *folio = page_folio(page);
struct extent_buffer *exists;
+ lockdep_assert_held(&page->mapping->i_private_lock);
+
/*
* For subpage case, we completely rely on radix tree to ensure we
* don't try to insert two ebs for the same bytenr. So here we always
@@ -3729,13 +3731,14 @@ static int check_eb_alignment(struct btr
* The caller needs to free the existing folios and retry using the same order.
*/
static int attach_eb_folio_to_filemap(struct extent_buffer *eb, int i,
+ struct btrfs_subpage *prealloc,
struct extent_buffer **found_eb_ret)
{
struct btrfs_fs_info *fs_info = eb->fs_info;
struct address_space *mapping = fs_info->btree_inode->i_mapping;
const unsigned long index = eb->start >> PAGE_SHIFT;
- struct folio *existing_folio;
+ struct folio *existing_folio = NULL;
int ret;
ASSERT(found_eb_ret);
@@ -3747,12 +3750,14 @@ retry:
ret = filemap_add_folio(mapping, eb->folios[i], index + i,
GFP_NOFS | __GFP_NOFAIL);
if (!ret)
- return 0;
+ goto finish;
existing_folio = filemap_lock_folio(mapping, index + i);
/* The page cache only exists for a very short time, just retry. */
- if (IS_ERR(existing_folio))
+ if (IS_ERR(existing_folio)) {
+ existing_folio = NULL;
goto retry;
+ }
/* For now, we should only have single-page folios for btree inode. */
ASSERT(folio_nr_pages(existing_folio) == 1);
@@ -3763,14 +3768,13 @@ retry:
return -EAGAIN;
}
- if (fs_info->nodesize < PAGE_SIZE) {
- /*
- * We're going to reuse the existing page, can drop our page
- * and subpage structure now.
- */
+finish:
+ spin_lock(&mapping->i_private_lock);
+ if (existing_folio && fs_info->nodesize < PAGE_SIZE) {
+ /* We're going to reuse the existing page, can drop our folio now. */
__free_page(folio_page(eb->folios[i], 0));
eb->folios[i] = existing_folio;
- } else {
+ } else if (existing_folio) {
struct extent_buffer *existing_eb;
existing_eb = grab_extent_buffer(fs_info,
@@ -3778,6 +3782,7 @@ retry:
if (existing_eb) {
/* The extent buffer still exists, we can use it directly. */
*found_eb_ret = existing_eb;
+ spin_unlock(&mapping->i_private_lock);
folio_unlock(existing_folio);
folio_put(existing_folio);
return 1;
@@ -3786,6 +3791,22 @@ retry:
__free_page(folio_page(eb->folios[i], 0));
eb->folios[i] = existing_folio;
}
+ eb->folio_size = folio_size(eb->folios[i]);
+ eb->folio_shift = folio_shift(eb->folios[i]);
+ /* Should not fail, as we have preallocated the memory. */
+ ret = attach_extent_buffer_folio(eb, eb->folios[i], prealloc);
+ ASSERT(!ret);
+ /*
+ * To inform we have an extra eb under allocation, so that
+ * detach_extent_buffer_page() won't release the folio private when the
+ * eb hasn't been inserted into radix tree yet.
+ *
+ * The ref will be decreased when the eb releases the page, in
+ * detach_extent_buffer_page(). Thus needs no special handling in the
+ * error path.
+ */
+ btrfs_folio_inc_eb_refs(fs_info, eb->folios[i]);
+ spin_unlock(&mapping->i_private_lock);
return 0;
}
@@ -3797,7 +3818,6 @@ struct extent_buffer *alloc_extent_buffe
int attached = 0;
struct extent_buffer *eb;
struct extent_buffer *existing_eb = NULL;
- struct address_space *mapping = fs_info->btree_inode->i_mapping;
struct btrfs_subpage *prealloc = NULL;
u64 lockdep_owner = owner_root;
bool page_contig = true;
@@ -3863,7 +3883,7 @@ reallocate:
for (int i = 0; i < num_folios; i++) {
struct folio *folio;
- ret = attach_eb_folio_to_filemap(eb, i, &existing_eb);
+ ret = attach_eb_folio_to_filemap(eb, i, prealloc, &existing_eb);
if (ret > 0) {
ASSERT(existing_eb);
goto out;
@@ -3900,24 +3920,6 @@ reallocate:
* and free the allocated page.
*/
folio = eb->folios[i];
- eb->folio_size = folio_size(folio);
- eb->folio_shift = folio_shift(folio);
- spin_lock(&mapping->i_private_lock);
- /* Should not fail, as we have preallocated the memory */
- ret = attach_extent_buffer_folio(eb, folio, prealloc);
- ASSERT(!ret);
- /*
- * To inform we have extra eb under allocation, so that
- * detach_extent_buffer_page() won't release the folio private
- * when the eb hasn't yet been inserted into radix tree.
- *
- * The ref will be decreased when the eb released the page, in
- * detach_extent_buffer_page().
- * Thus needs no special handling in error path.
- */
- btrfs_folio_inc_eb_refs(fs_info, folio);
- spin_unlock(&mapping->i_private_lock);
-
WARN_ON(btrfs_folio_test_dirty(fs_info, folio, eb->start, eb->len));
/*
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 148/157] btrfs: fix crash on racing fsync and size-extending write into prealloc
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (146 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 147/157] btrfs: protect folio::private when attaching extent buffer folios Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 149/157] btrfs: fix leak of qgroup extent records after transaction abort Greg Kroah-Hartman
` (18 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Filipe Manana, Omar Sandoval,
David Sterba
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Omar Sandoval <osandov@fb.com>
commit 9d274c19a71b3a276949933859610721a453946b upstream.
We have been seeing crashes on duplicate keys in
btrfs_set_item_key_safe():
BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)
------------[ cut here ]------------
kernel BUG at fs/btrfs/ctree.c:2620!
invalid opcode: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]
With the following stack trace:
#0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)
#1 btrfs_drop_extents (fs/btrfs/file.c:411:4)
#2 log_one_extent (fs/btrfs/tree-log.c:4732:9)
#3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)
#4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)
#5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)
#6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)
#7 btrfs_sync_file (fs/btrfs/file.c:1933:8)
#8 vfs_fsync_range (fs/sync.c:188:9)
#9 vfs_fsync (fs/sync.c:202:9)
#10 do_fsync (fs/sync.c:212:9)
#11 __do_sys_fdatasync (fs/sync.c:225:9)
#12 __se_sys_fdatasync (fs/sync.c:223:1)
#13 __x64_sys_fdatasync (fs/sync.c:223:1)
#14 do_syscall_x64 (arch/x86/entry/common.c:52:14)
#15 do_syscall_64 (arch/x86/entry/common.c:83:7)
#16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)
So we're logging a changed extent from fsync, which is splitting an
extent in the log tree. But this split part already exists in the tree,
triggering the BUG().
This is the state of the log tree at the time of the crash, dumped with
drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)
to get more details than btrfs_print_leaf() gives us:
>>> print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"])
leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610
leaf 33439744 flags 0x100000000000000
fs uuid e5bd3946-400c-4223-8923-190ef1f18677
chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da
item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160
generation 7 transid 9 size 8192 nbytes 8473563889606862198
block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0
sequence 204 flags 0x10(PREALLOC)
atime 1716417703.220000000 (2024-05-22 15:41:43)
ctime 1716417704.983333333 (2024-05-22 15:41:44)
mtime 1716417704.983333333 (2024-05-22 15:41:44)
otime 17592186044416.000000000 (559444-03-08 01:40:16)
item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13
index 195 namelen 3 name: 193
item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37
location key (0 UNKNOWN.0 0) type XATTR
transid 7 data_len 1 name_len 6
name: user.a
data a
item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 303144960 nr 12288
extent data offset 0 nr 4096 ram 12288
extent compression 0 (none)
item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53
generation 9 type 2 (prealloc)
prealloc data disk byte 303144960 nr 12288
prealloc data offset 4096 nr 8192
item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53
generation 9 type 2 (prealloc)
prealloc data disk byte 303144960 nr 12288
prealloc data offset 8192 nr 4096
...
So the real problem happened earlier: notice that items 4 (4k-12k) and 5
(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and
item 5 starts at i_size.
Here is the state of the filesystem tree at the time of the crash:
>>> root = prog.crashed_thread().stack_trace()[2]["inode"].root
>>> ret, nodes, slots = btrfs_search_slot(root, BtrfsKey(450, 0, 0))
>>> print_extent_buffer(nodes[0])
leaf 30425088 level 0 items 184 generation 9 owner 5
leaf 30425088 flags 0x100000000000000
fs uuid e5bd3946-400c-4223-8923-190ef1f18677
chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da
...
item 179 key (450 INODE_ITEM 0) itemoff 4907 itemsize 160
generation 7 transid 7 size 4096 nbytes 12288
block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0
sequence 6 flags 0x10(PREALLOC)
atime 1716417703.220000000 (2024-05-22 15:41:43)
ctime 1716417703.220000000 (2024-05-22 15:41:43)
mtime 1716417703.220000000 (2024-05-22 15:41:43)
otime 1716417703.220000000 (2024-05-22 15:41:43)
item 180 key (450 INODE_REF 256) itemoff 4894 itemsize 13
index 195 namelen 3 name: 193
item 181 key (450 XATTR_ITEM 1640047104) itemoff 4857 itemsize 37
location key (0 UNKNOWN.0 0) type XATTR
transid 7 data_len 1 name_len 6
name: user.a
data a
item 182 key (450 EXTENT_DATA 0) itemoff 4804 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 303144960 nr 12288
extent data offset 0 nr 8192 ram 12288
extent compression 0 (none)
item 183 key (450 EXTENT_DATA 8192) itemoff 4751 itemsize 53
generation 9 type 2 (prealloc)
prealloc data disk byte 303144960 nr 12288
prealloc data offset 8192 nr 4096
Item 5 in the log tree corresponds to item 183 in the filesystem tree,
but nothing matches item 4. Furthermore, item 183 is the last item in
the leaf.
btrfs_log_prealloc_extents() is responsible for logging prealloc extents
beyond i_size. It first truncates any previously logged prealloc extents
that start beyond i_size. Then, it walks the filesystem tree and copies
the prealloc extent items to the log tree.
If it hits the end of a leaf, then it calls btrfs_next_leaf(), which
unlocks the tree and does another search. However, while the filesystem
tree is unlocked, an ordered extent completion may modify the tree. In
particular, it may insert an extent item that overlaps with an extent
item that was already copied to the log tree.
This may manifest in several ways depending on the exact scenario,
including an EEXIST error that is silently translated to a full sync,
overlapping items in the log tree, or this crash. This particular crash
is triggered by the following sequence of events:
- Initially, the file has i_size=4k, a regular extent from 0-4k, and a
prealloc extent beyond i_size from 4k-12k. The prealloc extent item is
the last item in its B-tree leaf.
- The file is fsync'd, which copies its inode item and both extent items
to the log tree.
- An xattr is set on the file, which sets the
BTRFS_INODE_COPY_EVERYTHING flag.
- The range 4k-8k in the file is written using direct I/O. i_size is
extended to 8k, but the ordered extent is still in flight.
- The file is fsync'd. Since BTRFS_INODE_COPY_EVERYTHING is set, this
calls copy_inode_items_to_log(), which calls
btrfs_log_prealloc_extents().
- btrfs_log_prealloc_extents() finds the 4k-12k prealloc extent in the
filesystem tree. Since it starts before i_size, it skips it. Since it
is the last item in its B-tree leaf, it calls btrfs_next_leaf().
- btrfs_next_leaf() unlocks the path.
- The ordered extent completion runs, which converts the 4k-8k part of
the prealloc extent to written and inserts the remaining prealloc part
from 8k-12k.
- btrfs_next_leaf() does a search and finds the new prealloc extent
8k-12k.
- btrfs_log_prealloc_extents() copies the 8k-12k prealloc extent into
the log tree. Note that it overlaps with the 4k-12k prealloc extent
that was copied to the log tree by the first fsync.
- fsync calls btrfs_log_changed_extents(), which tries to log the 4k-8k
extent that was written.
- This tries to drop the range 4k-8k in the log tree, which requires
adjusting the start of the 4k-12k prealloc extent in the log tree to
8k.
- btrfs_set_item_key_safe() sees that there is already an extent
starting at 8k in the log tree and calls BUG().
Fix this by detecting when we're about to insert an overlapping file
extent item in the log tree and truncating the part that would overlap.
CC: stable@vger.kernel.org # 6.1+
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/tree-log.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -4856,18 +4856,23 @@ static int btrfs_log_prealloc_extents(st
path->slots[0]++;
continue;
}
- if (!dropped_extents) {
- /*
- * Avoid logging extent items logged in past fsync calls
- * and leading to duplicate keys in the log tree.
- */
+ /*
+ * Avoid overlapping items in the log tree. The first time we
+ * get here, get rid of everything from a past fsync. After
+ * that, if the current extent starts before the end of the last
+ * extent we copied, truncate the last one. This can happen if
+ * an ordered extent completion modifies the subvolume tree
+ * while btrfs_next_leaf() has the tree unlocked.
+ */
+ if (!dropped_extents || key.offset < truncate_offset) {
ret = truncate_inode_items(trans, root->log_root, inode,
- truncate_offset,
+ min(key.offset, truncate_offset),
BTRFS_EXTENT_DATA_KEY);
if (ret)
goto out;
dropped_extents = true;
}
+ truncate_offset = btrfs_file_extent_end(path);
if (ins_nr == 0)
start_slot = slot;
ins_nr++;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 149/157] btrfs: fix leak of qgroup extent records after transaction abort
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (147 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 148/157] btrfs: fix crash on racing fsync and size-extending write into prealloc Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 150/157] btrfs: re-introduce norecovery mount option Greg Kroah-Hartman
` (17 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, syzbot+0fecc032fa134afd49df,
Josef Bacik, Qu Wenruo, Filipe Manana, David Sterba
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <fdmanana@suse.com>
commit fb33eb2ef0d88e75564983ef057b44c5b7e4fded upstream.
Qgroup extent records are created when delayed ref heads are created and
then released after accounting extents at btrfs_qgroup_account_extents(),
called during the transaction commit path.
If a transaction is aborted we free the qgroup records by calling
btrfs_qgroup_destroy_extent_records() at btrfs_destroy_delayed_refs(),
unless we don't have delayed references. We are incorrectly assuming
that no delayed references means we don't have qgroup extents records.
We can currently have no delayed references because we ran them all
during a transaction commit and the transaction was aborted after that
due to some error in the commit path.
So fix this by ensuring we btrfs_qgroup_destroy_extent_records() at
btrfs_destroy_delayed_refs() even if we don't have any delayed references.
Reported-by: syzbot+0fecc032fa134afd49df@syzkaller.appspotmail.com
Link: https://lore.kernel.org/linux-btrfs/0000000000004e7f980619f91835@google.com/
Fixes: 81f7eb00ff5b ("btrfs: destroy qgroup extent records on transaction abort")
CC: stable@vger.kernel.org # 6.1+
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/disk-io.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -4544,18 +4544,10 @@ static void btrfs_destroy_delayed_refs(s
struct btrfs_fs_info *fs_info)
{
struct rb_node *node;
- struct btrfs_delayed_ref_root *delayed_refs;
+ struct btrfs_delayed_ref_root *delayed_refs = &trans->delayed_refs;
struct btrfs_delayed_ref_node *ref;
- delayed_refs = &trans->delayed_refs;
-
spin_lock(&delayed_refs->lock);
- if (atomic_read(&delayed_refs->num_entries) == 0) {
- spin_unlock(&delayed_refs->lock);
- btrfs_debug(fs_info, "delayed_refs has NO entry");
- return;
- }
-
while ((node = rb_first_cached(&delayed_refs->href_root)) != NULL) {
struct btrfs_delayed_ref_head *head;
struct rb_node *n;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 150/157] btrfs: re-introduce norecovery mount option
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (148 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 149/157] btrfs: fix leak of qgroup extent records after transaction abort Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 151/157] ALSA: seq: Fix incorrect UMP type for system messages Greg Kroah-Hartman
` (16 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Lennart Poettering, Jiri Slaby,
Johannes Thumshirn, Qu Wenruo, David Sterba
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qu Wenruo <wqu@suse.com>
commit 440861b1a03c72cc7be4a307e178dcaa6894479b upstream.
Although 'norecovery' mount option was marked as deprecated for a long
time and a warning message was printed during the deprecation window,
it's still actively utilized by several projects that need a safer way
to mount a btrfs without any writes.
Furthermore this 'norecovery' mount option is supported by other major
filesystems, which makes it less clear what's our motivation to remove
it.
Re-introduce the 'norecovery' mount option, and output a message to recommend
'rescue=nologreplay' option.
Link: https://lore.kernel.org/linux-btrfs/ZkxZT0J-z0GYvfy8@gardel-login/#t
Link: https://github.com/systemd/systemd/pull/32892
Link: https://bugzilla.suse.com/show_bug.cgi?id=1222429
Reported-by: Lennart Poettering <lennart@poettering.net>
Reported-by: Jiri Slaby <jslaby@suse.com>
Fixes: a1912f712188 ("btrfs: remove code for inode_cache and recovery mount options")
CC: stable@vger.kernel.org # 6.8+
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/super.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -119,6 +119,7 @@ enum {
Opt_thread_pool,
Opt_treelog,
Opt_user_subvol_rm_allowed,
+ Opt_norecovery,
/* Rescue options */
Opt_rescue,
@@ -245,6 +246,8 @@ static const struct fs_parameter_spec bt
__fsparam(NULL, "nologreplay", Opt_nologreplay, fs_param_deprecated, NULL),
/* Deprecated, with alias rescue=usebackuproot */
__fsparam(NULL, "usebackuproot", Opt_usebackuproot, fs_param_deprecated, NULL),
+ /* For compatibility only, alias for "rescue=nologreplay". */
+ fsparam_flag("norecovery", Opt_norecovery),
/* Debugging options. */
fsparam_flag_no("enospc_debug", Opt_enospc_debug),
@@ -438,6 +441,11 @@ static int btrfs_parse_param(struct fs_c
"'nologreplay' is deprecated, use 'rescue=nologreplay' instead");
btrfs_set_opt(ctx->mount_opt, NOLOGREPLAY);
break;
+ case Opt_norecovery:
+ btrfs_info(NULL,
+"'norecovery' is for compatibility only, recommended to use 'rescue=nologreplay'");
+ btrfs_set_opt(ctx->mount_opt, NOLOGREPLAY);
+ break;
case Opt_flushoncommit:
if (result.negated)
btrfs_clear_opt(ctx->mount_opt, FLUSHONCOMMIT);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 151/157] ALSA: seq: Fix incorrect UMP type for system messages
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (149 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 150/157] btrfs: re-introduce norecovery mount option Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 152/157] bpf: fix multi-uprobe PID filtering logic Greg Kroah-Hartman
` (15 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Takashi Iwai
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit edb32776196afa393c074d6a2733e3a69e66b299 upstream.
When converting a legacy system message to a UMP packet, it forgot to
modify the UMP type field but keeping the default type (either type 2
or 4). Correct to the right type for system messages.
Fixes: e9e02819a98a ("ALSA: seq: Automatic conversion of UMP events")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20240529083800.5742-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/seq/seq_ump_convert.c | 2 ++
1 file changed, 2 insertions(+)
--- a/sound/core/seq/seq_ump_convert.c
+++ b/sound/core/seq/seq_ump_convert.c
@@ -740,6 +740,7 @@ static int system_1p_ev_to_ump_midi1(con
union snd_ump_midi1_msg *data,
unsigned char status)
{
+ data->system.type = UMP_MSG_TYPE_SYSTEM; // override
data->system.status = status;
data->system.parm1 = event->data.control.value & 0x7f;
return 1;
@@ -751,6 +752,7 @@ static int system_2p_ev_to_ump_midi1(con
union snd_ump_midi1_msg *data,
unsigned char status)
{
+ data->system.type = UMP_MSG_TYPE_SYSTEM; // override
data->system.status = status;
data->system.parm1 = event->data.control.value & 0x7f;
data->system.parm2 = (event->data.control.value >> 7) & 0x7f;
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 152/157] bpf: fix multi-uprobe PID filtering logic
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (150 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 151/157] ALSA: seq: Fix incorrect UMP type for system messages Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 153/157] powerpc/64/bpf: fix tail calls for PCREL addressing Greg Kroah-Hartman
` (14 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Jiri Olsa, Andrii Nakryiko,
Alexei Starovoitov
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrii Nakryiko <andrii@kernel.org>
commit 46ba0e49b64232adac35a2bc892f1710c5b0fb7f upstream.
Current implementation of PID filtering logic for multi-uprobes in
uprobe_prog_run() is filtering down to exact *thread*, while the intent
for PID filtering it to filter by *process* instead. The check in
uprobe_prog_run() also differs from the analogous one in
uprobe_multi_link_filter() for some reason. The latter is correct,
checking task->mm, not the task itself.
Fix the check in uprobe_prog_run() to perform the same task->mm check.
While doing this, we also update get_pid_task() use to use PIDTYPE_TGID
type of lookup, given the intent is to get a representative task of an
entire process. This doesn't change behavior, but seems more logical. It
would hold task group leader task now, not any random thread task.
Last but not least, given multi-uprobe support is half-broken due to
this PID filtering logic (depending on whether PID filtering is
important or not), we need to make it easy for user space consumers
(including libbpf) to easily detect whether PID filtering logic was
already fixed.
We do it here by adding an early check on passed pid parameter. If it's
negative (and so has no chance of being a valid PID), we return -EINVAL.
Previous behavior would eventually return -ESRCH ("No process found"),
given there can't be any process with negative PID. This subtle change
won't make any practical change in behavior, but will allow applications
to detect PID filtering fixes easily. Libbpf fixes take advantage of
this in the next patch.
Cc: stable@vger.kernel.org
Acked-by: Jiri Olsa <jolsa@kernel.org>
Fixes: b733eeade420 ("bpf: Add pid filter support for uprobe_multi link")
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/r/20240521163401.3005045-2-andrii@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/trace/bpf_trace.c | 8 ++++----
tools/testing/selftests/bpf/prog_tests/uprobe_multi_test.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -3260,7 +3260,7 @@ static int uprobe_prog_run(struct bpf_up
struct bpf_run_ctx *old_run_ctx;
int err = 0;
- if (link->task && current != link->task)
+ if (link->task && current->mm != link->task->mm)
return 0;
if (sleepable)
@@ -3361,8 +3361,9 @@ int bpf_uprobe_multi_link_attach(const u
upath = u64_to_user_ptr(attr->link_create.uprobe_multi.path);
uoffsets = u64_to_user_ptr(attr->link_create.uprobe_multi.offsets);
cnt = attr->link_create.uprobe_multi.cnt;
+ pid = attr->link_create.uprobe_multi.pid;
- if (!upath || !uoffsets || !cnt)
+ if (!upath || !uoffsets || !cnt || pid < 0)
return -EINVAL;
if (cnt > MAX_UPROBE_MULTI_CNT)
return -E2BIG;
@@ -3386,10 +3387,9 @@ int bpf_uprobe_multi_link_attach(const u
goto error_path_put;
}
- pid = attr->link_create.uprobe_multi.pid;
if (pid) {
rcu_read_lock();
- task = get_pid_task(find_vpid(pid), PIDTYPE_PID);
+ task = get_pid_task(find_vpid(pid), PIDTYPE_TGID);
rcu_read_unlock();
if (!task) {
err = -ESRCH;
--- a/tools/testing/selftests/bpf/prog_tests/uprobe_multi_test.c
+++ b/tools/testing/selftests/bpf/prog_tests/uprobe_multi_test.c
@@ -397,7 +397,7 @@ static void test_attach_api_fails(void)
link_fd = bpf_link_create(prog_fd, 0, BPF_TRACE_UPROBE_MULTI, &opts);
if (!ASSERT_ERR(link_fd, "link_fd"))
goto cleanup;
- ASSERT_EQ(link_fd, -ESRCH, "pid_is_wrong");
+ ASSERT_EQ(link_fd, -EINVAL, "pid_is_wrong");
cleanup:
if (link_fd >= 0)
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 153/157] powerpc/64/bpf: fix tail calls for PCREL addressing
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (151 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 152/157] bpf: fix multi-uprobe PID filtering logic Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 154/157] powerpc/bpf: enforce full ordering for ATOMIC operations with BPF_FETCH Greg Kroah-Hartman
` (13 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Hari Bathini, Michael Ellerman
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hari Bathini <hbathini@linux.ibm.com>
commit 2ecfe59cd7de1f202e9af2516a61fbbf93d0bd4d upstream.
With PCREL addressing, there is no kernel TOC. So, it is not setup in
prologue when PCREL addressing is used. But the number of instructions
to skip on a tail call was not adjusted accordingly. That resulted in
not so obvious failures while using tailcalls. 'tailcalls' selftest
crashed the system with the below call trace:
bpf_test_run+0xe8/0x3cc (unreliable)
bpf_prog_test_run_skb+0x348/0x778
__sys_bpf+0xb04/0x2b00
sys_bpf+0x28/0x38
system_call_exception+0x168/0x340
system_call_vectored_common+0x15c/0x2ec
Also, as bpf programs are always module addresses and a bpf helper in
general is a core kernel text address, using PC relative addressing
often fails with "out of range of pcrel address" error. Switch to
using kernel base for relative addressing to handle this better.
Fixes: 7e3a68be42e1 ("powerpc/64: vmlinux support building with PCREL addresing")
Cc: stable@vger.kernel.org # v6.4+
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240502173205.142794-1-hbathini@linux.ibm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/net/bpf_jit_comp64.c | 30 ++++++++++++++++--------------
1 file changed, 16 insertions(+), 14 deletions(-)
--- a/arch/powerpc/net/bpf_jit_comp64.c
+++ b/arch/powerpc/net/bpf_jit_comp64.c
@@ -202,7 +202,8 @@ void bpf_jit_build_epilogue(u32 *image,
EMIT(PPC_RAW_BLR());
}
-static int bpf_jit_emit_func_call_hlp(u32 *image, struct codegen_context *ctx, u64 func)
+static int
+bpf_jit_emit_func_call_hlp(u32 *image, u32 *fimage, struct codegen_context *ctx, u64 func)
{
unsigned long func_addr = func ? ppc_function_entry((void *)func) : 0;
long reladdr;
@@ -211,19 +212,20 @@ static int bpf_jit_emit_func_call_hlp(u3
return -EINVAL;
if (IS_ENABLED(CONFIG_PPC_KERNEL_PCREL)) {
- reladdr = func_addr - CTX_NIA(ctx);
+ reladdr = func_addr - local_paca->kernelbase;
if (reladdr >= (long)SZ_8G || reladdr < -(long)SZ_8G) {
- pr_err("eBPF: address of %ps out of range of pcrel address.\n",
- (void *)func);
+ pr_err("eBPF: address of %ps out of range of 34-bit relative address.\n",
+ (void *)func);
return -ERANGE;
}
- /* pla r12,addr */
- EMIT(PPC_PREFIX_MLS | __PPC_PRFX_R(1) | IMM_H18(reladdr));
- EMIT(PPC_INST_PADDI | ___PPC_RT(_R12) | IMM_L(reladdr));
- EMIT(PPC_RAW_MTCTR(_R12));
- EMIT(PPC_RAW_BCTR());
-
+ EMIT(PPC_RAW_LD(_R12, _R13, offsetof(struct paca_struct, kernelbase)));
+ /* Align for subsequent prefix instruction */
+ if (!IS_ALIGNED((unsigned long)fimage + CTX_NIA(ctx), 8))
+ EMIT(PPC_RAW_NOP());
+ /* paddi r12,r12,addr */
+ EMIT(PPC_PREFIX_MLS | __PPC_PRFX_R(0) | IMM_H18(reladdr));
+ EMIT(PPC_INST_PADDI | ___PPC_RT(_R12) | ___PPC_RA(_R12) | IMM_L(reladdr));
} else {
reladdr = func_addr - kernel_toc_addr();
if (reladdr > 0x7FFFFFFF || reladdr < -(0x80000000L)) {
@@ -233,9 +235,9 @@ static int bpf_jit_emit_func_call_hlp(u3
EMIT(PPC_RAW_ADDIS(_R12, _R2, PPC_HA(reladdr)));
EMIT(PPC_RAW_ADDI(_R12, _R12, PPC_LO(reladdr)));
- EMIT(PPC_RAW_MTCTR(_R12));
- EMIT(PPC_RAW_BCTRL());
}
+ EMIT(PPC_RAW_MTCTR(_R12));
+ EMIT(PPC_RAW_BCTRL());
return 0;
}
@@ -285,7 +287,7 @@ static int bpf_jit_emit_tail_call(u32 *i
int b2p_index = bpf_to_ppc(BPF_REG_3);
int bpf_tailcall_prologue_size = 8;
- if (IS_ENABLED(CONFIG_PPC64_ELF_ABI_V2))
+ if (!IS_ENABLED(CONFIG_PPC_KERNEL_PCREL) && IS_ENABLED(CONFIG_PPC64_ELF_ABI_V2))
bpf_tailcall_prologue_size += 4; /* skip past the toc load */
/*
@@ -993,7 +995,7 @@ emit_clear:
return ret;
if (func_addr_fixed)
- ret = bpf_jit_emit_func_call_hlp(image, ctx, func_addr);
+ ret = bpf_jit_emit_func_call_hlp(image, fimage, ctx, func_addr);
else
ret = bpf_jit_emit_func_call_rel(image, fimage, ctx, func_addr);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 154/157] powerpc/bpf: enforce full ordering for ATOMIC operations with BPF_FETCH
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (152 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 153/157] powerpc/64/bpf: fix tail calls for PCREL addressing Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 155/157] nilfs2: fix potential kernel bug due to lack of writeback flag waiting Greg Kroah-Hartman
` (12 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Puranjay Mohan, Christophe Leroy,
Naveen N Rao, Paul E. McKenney, Michael Ellerman
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Puranjay Mohan <puranjay@kernel.org>
commit b1e7cee96127468c2483cf10c2899c9b5cf79bf8 upstream.
The Linux Kernel Memory Model [1][2] requires RMW operations that have a
return value to be fully ordered.
BPF atomic operations with BPF_FETCH (including BPF_XCHG and
BPF_CMPXCHG) return a value back so they need to be JITed to fully
ordered operations. POWERPC currently emits relaxed operations for
these.
We can show this by running the following litmus-test:
PPC SB+atomic_add+fetch
{
0:r0=x; (* dst reg assuming offset is 0 *)
0:r1=2; (* src reg *)
0:r2=1;
0:r4=y; (* P0 writes to this, P1 reads this *)
0:r5=z; (* P1 writes to this, P0 reads this *)
0:r6=0;
1:r2=1;
1:r4=y;
1:r5=z;
}
P0 | P1 ;
stw r2, 0(r4) | stw r2,0(r5) ;
| ;
loop:lwarx r3, r6, r0 | ;
mr r8, r3 | ;
add r3, r3, r1 | sync ;
stwcx. r3, r6, r0 | ;
bne loop | ;
mr r1, r8 | ;
| ;
lwa r7, 0(r5) | lwa r7,0(r4) ;
~exists(0:r7=0 /\ 1:r7=0)
Witnesses
Positive: 9 Negative: 3
Condition ~exists (0:r7=0 /\ 1:r7=0)
Observation SB+atomic_add+fetch Sometimes 3 9
This test shows that the older store in P0 is reordered with a newer
load to a different address. Although there is a RMW operation with
fetch between them. Adding a sync before and after RMW fixes the issue:
Witnesses
Positive: 9 Negative: 0
Condition ~exists (0:r7=0 /\ 1:r7=0)
Observation SB+atomic_add+fetch Never 0 9
[1] https://www.kernel.org/doc/Documentation/memory-barriers.txt
[2] https://www.kernel.org/doc/Documentation/atomic_t.txt
Fixes: aea7ef8a82c0 ("powerpc/bpf/32: add support for BPF_ATOMIC bitwise operations")
Fixes: 2d9206b22743 ("powerpc/bpf/32: Add instructions for atomic_[cmp]xchg")
Fixes: dbe6e2456fb0 ("powerpc/bpf/64: add support for atomic fetch operations")
Fixes: 1e82dfaa7819 ("powerpc/bpf/64: Add instructions for atomic_[cmp]xchg")
Cc: stable@vger.kernel.org # v6.0+
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: Naveen N Rao <naveen@kernel.org>
Acked-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240513100248.110535-1-puranjay@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/net/bpf_jit_comp32.c | 12 ++++++++++++
arch/powerpc/net/bpf_jit_comp64.c | 12 ++++++++++++
2 files changed, 24 insertions(+)
--- a/arch/powerpc/net/bpf_jit_comp32.c
+++ b/arch/powerpc/net/bpf_jit_comp32.c
@@ -900,6 +900,15 @@ int bpf_jit_build_body(struct bpf_prog *
/* Get offset into TMP_REG */
EMIT(PPC_RAW_LI(tmp_reg, off));
+ /*
+ * Enforce full ordering for operations with BPF_FETCH by emitting a 'sync'
+ * before and after the operation.
+ *
+ * This is a requirement in the Linux Kernel Memory Model.
+ * See __cmpxchg_u32() in asm/cmpxchg.h as an example.
+ */
+ if ((imm & BPF_FETCH) && IS_ENABLED(CONFIG_SMP))
+ EMIT(PPC_RAW_SYNC());
tmp_idx = ctx->idx * 4;
/* load value from memory into r0 */
EMIT(PPC_RAW_LWARX(_R0, tmp_reg, dst_reg, 0));
@@ -953,6 +962,9 @@ int bpf_jit_build_body(struct bpf_prog *
/* For the BPF_FETCH variant, get old data into src_reg */
if (imm & BPF_FETCH) {
+ /* Emit 'sync' to enforce full ordering */
+ if (IS_ENABLED(CONFIG_SMP))
+ EMIT(PPC_RAW_SYNC());
EMIT(PPC_RAW_MR(ret_reg, ax_reg));
if (!fp->aux->verifier_zext)
EMIT(PPC_RAW_LI(ret_reg - 1, 0)); /* higher 32-bit */
--- a/arch/powerpc/net/bpf_jit_comp64.c
+++ b/arch/powerpc/net/bpf_jit_comp64.c
@@ -805,6 +805,15 @@ emit_clear:
/* Get offset into TMP_REG_1 */
EMIT(PPC_RAW_LI(tmp1_reg, off));
+ /*
+ * Enforce full ordering for operations with BPF_FETCH by emitting a 'sync'
+ * before and after the operation.
+ *
+ * This is a requirement in the Linux Kernel Memory Model.
+ * See __cmpxchg_u64() in asm/cmpxchg.h as an example.
+ */
+ if ((imm & BPF_FETCH) && IS_ENABLED(CONFIG_SMP))
+ EMIT(PPC_RAW_SYNC());
tmp_idx = ctx->idx * 4;
/* load value from memory into TMP_REG_2 */
if (size == BPF_DW)
@@ -867,6 +876,9 @@ emit_clear:
PPC_BCC_SHORT(COND_NE, tmp_idx);
if (imm & BPF_FETCH) {
+ /* Emit 'sync' to enforce full ordering */
+ if (IS_ENABLED(CONFIG_SMP))
+ EMIT(PPC_RAW_SYNC());
EMIT(PPC_RAW_MR(ret_reg, _R0));
/*
* Skip unnecessary zero-extension for 32-bit cmpxchg.
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 155/157] nilfs2: fix potential kernel bug due to lack of writeback flag waiting
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (153 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 154/157] powerpc/bpf: enforce full ordering for ATOMIC operations with BPF_FETCH Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 156/157] nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors Greg Kroah-Hartman
` (11 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Ryusuke Konishi, Andrew Morton
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ryusuke Konishi <konishi.ryusuke@gmail.com>
commit a4ca369ca221bb7e06c725792ac107f0e48e82e7 upstream.
Destructive writes to a block device on which nilfs2 is mounted can cause
a kernel bug in the folio/page writeback start routine or writeback end
routine (__folio_start_writeback in the log below):
kernel BUG at mm/page-writeback.c:3070!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
...
RIP: 0010:__folio_start_writeback+0xbaa/0x10e0
Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff
e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f>
0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00
...
Call Trace:
<TASK>
nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2]
nilfs_segctor_construct+0x181/0x6b0 [nilfs2]
nilfs_segctor_thread+0x548/0x11c0 [nilfs2]
kthread+0x2f0/0x390
ret_from_fork+0x4b/0x80
ret_from_fork_asm+0x1a/0x30
</TASK>
This is because when the log writer starts a writeback for segment summary
blocks or a super root block that use the backing device's page cache, it
does not wait for the ongoing folio/page writeback, resulting in an
inconsistent writeback state.
Fix this issue by waiting for ongoing writebacks when putting
folios/pages on the backing device into writeback state.
Link: https://lkml.kernel.org/r/20240530141556.4411-1-konishi.ryusuke@gmail.com
Fixes: 9ff05123e3bf ("nilfs2: segment constructor")
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nilfs2/segment.c | 3 +++
1 file changed, 3 insertions(+)
--- a/fs/nilfs2/segment.c
+++ b/fs/nilfs2/segment.c
@@ -1652,6 +1652,7 @@ static void nilfs_segctor_prepare_write(
if (bh->b_folio != bd_folio) {
if (bd_folio) {
folio_lock(bd_folio);
+ folio_wait_writeback(bd_folio);
folio_clear_dirty_for_io(bd_folio);
folio_start_writeback(bd_folio);
folio_unlock(bd_folio);
@@ -1665,6 +1666,7 @@ static void nilfs_segctor_prepare_write(
if (bh == segbuf->sb_super_root) {
if (bh->b_folio != bd_folio) {
folio_lock(bd_folio);
+ folio_wait_writeback(bd_folio);
folio_clear_dirty_for_io(bd_folio);
folio_start_writeback(bd_folio);
folio_unlock(bd_folio);
@@ -1681,6 +1683,7 @@ static void nilfs_segctor_prepare_write(
}
if (bd_folio) {
folio_lock(bd_folio);
+ folio_wait_writeback(bd_folio);
folio_clear_dirty_for_io(bd_folio);
folio_start_writeback(bd_folio);
folio_unlock(bd_folio);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 156/157] nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (154 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 155/157] nilfs2: fix potential kernel bug due to lack of writeback flag waiting Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 11:34 ` [PATCH 6.9 157/157] smb: client: fix deadlock in smb2_find_smb_tcon() Greg Kroah-Hartman
` (10 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Ryusuke Konishi,
syzbot+c8166c541d3971bf6c87, Andrew Morton
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ryusuke Konishi <konishi.ryusuke@gmail.com>
commit 7373a51e7998b508af7136530f3a997b286ce81c upstream.
The error handling in nilfs_empty_dir() when a directory folio/page read
fails is incorrect, as in the old ext2 implementation, and if the
folio/page cannot be read or nilfs_check_folio() fails, it will falsely
determine the directory as empty and corrupt the file system.
In addition, since nilfs_empty_dir() does not immediately return on a
failed folio/page read, but continues to loop, this can cause a long loop
with I/O if i_size of the directory's inode is also corrupted, causing the
log writer thread to wait and hang, as reported by syzbot.
Fix these issues by making nilfs_empty_dir() immediately return a false
value (0) if it fails to get a directory folio/page.
Link: https://lkml.kernel.org/r/20240604134255.7165-1-konishi.ryusuke@gmail.com
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Reported-by: syzbot+c8166c541d3971bf6c87@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c8166c541d3971bf6c87
Fixes: 2ba466d74ed7 ("nilfs2: directory entry operations")
Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nilfs2/dir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/nilfs2/dir.c
+++ b/fs/nilfs2/dir.c
@@ -608,7 +608,7 @@ int nilfs_empty_dir(struct inode *inode)
kaddr = nilfs_get_folio(inode, i, &folio);
if (IS_ERR(kaddr))
- continue;
+ return 0;
de = (struct nilfs_dir_entry *)kaddr;
kaddr += nilfs_last_byte(inode, i) - NILFS_DIR_REC_LEN(1);
^ permalink raw reply [flat|nested] 168+ messages in thread* [PATCH 6.9 157/157] smb: client: fix deadlock in smb2_find_smb_tcon()
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (155 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 156/157] nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors Greg Kroah-Hartman
@ 2024-06-13 11:34 ` Greg Kroah-Hartman
2024-06-13 16:51 ` [PATCH 6.9 000/157] 6.9.5-rc1 review SeongJae Park
` (9 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Greg Kroah-Hartman @ 2024-06-13 11:34 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Enzo Matsumiya, Shyam Prasad N,
Paulo Alcantara (Red Hat), Steve French
6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Enzo Matsumiya <ematsumiya@suse.de>
commit 02c418774f76a0a36a6195c9dbf8971eb4130a15 upstream.
Unlock cifs_tcp_ses_lock before calling cifs_put_smb_ses() to avoid such
deadlock.
Cc: stable@vger.kernel.org
Signed-off-by: Enzo Matsumiya <ematsumiya@suse.de>
Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/smb/client/smb2transport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/smb/client/smb2transport.c
+++ b/fs/smb/client/smb2transport.c
@@ -216,8 +216,8 @@ smb2_find_smb_tcon(struct TCP_Server_Inf
}
tcon = smb2_find_smb_sess_tcon_unlocked(ses, tid);
if (!tcon) {
- cifs_put_smb_ses(ses);
spin_unlock(&cifs_tcp_ses_lock);
+ cifs_put_smb_ses(ses);
return NULL;
}
spin_unlock(&cifs_tcp_ses_lock);
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [PATCH 6.9 000/157] 6.9.5-rc1 review
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (156 preceding siblings ...)
2024-06-13 11:34 ` [PATCH 6.9 157/157] smb: client: fix deadlock in smb2_find_smb_tcon() Greg Kroah-Hartman
@ 2024-06-13 16:51 ` SeongJae Park
2024-06-14 1:44 ` Bagas Sanjaya
` (8 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: SeongJae Park @ 2024-06-13 16:51 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: SeongJae Park, stable, patches, linux-kernel, torvalds, akpm,
linux, shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml, broonie, damon
Hello,
On Thu, 13 Jun 2024 13:32:05 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> This is the start of the stable review cycle for the 6.9.5 release.
> There are 157 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 15 Jun 2024 11:31:50 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.9.5-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.y
> and the diffstat can be found below.
This rc kernel passes DAMON functionality test[1] on my test machine.
Attaching the test results summary below. Please note that I retrieved the
kernel from linux-stable-rc tree[2].
Tested-by: SeongJae Park <sj@kernel.org>
[1] https://github.com/awslabs/damon-tests/tree/next/corr
[2] 35fcf9de8f9d ("Linux 6.9.5-rc1")
Thanks,
SJ
[...]
---
ok 6 selftests: damon: debugfs_duplicate_context_creation.sh
ok 7 selftests: damon: debugfs_rm_non_contexts.sh
ok 8 selftests: damon: debugfs_target_ids_read_before_terminate_race.sh
ok 9 selftests: damon: debugfs_target_ids_pid_leak.sh
ok 10 selftests: damon: sysfs.sh
ok 11 selftests: damon: sysfs_update_removed_scheme_dir.sh
ok 12 selftests: damon: sysfs_update_schemes_tried_regions_hang.py
ok 13 selftests: damon: sysfs_update_schemes_tried_regions_wss_estimation.py
ok 14 selftests: damon: damos_quota.py
ok 15 selftests: damon: damos_apply_interval.py
ok 16 selftests: damon: reclaim.sh
ok 17 selftests: damon: lru_sort.sh
ok 1 selftests: damon-tests: kunit.sh
ok 2 selftests: damon-tests: huge_count_read_write.sh
ok 3 selftests: damon-tests: buffer_overflow.sh
ok 4 selftests: damon-tests: rm_contexts.sh
ok 5 selftests: damon-tests: record_null_deref.sh
ok 6 selftests: damon-tests: dbgfs_target_ids_read_before_terminate_race.sh
ok 7 selftests: damon-tests: dbgfs_target_ids_pid_leak.sh
ok 8 selftests: damon-tests: damo_tests.sh
ok 9 selftests: damon-tests: masim-record.sh
ok 10 selftests: damon-tests: build_i386.sh
ok 11 selftests: damon-tests: build_arm64.sh
ok 12 selftests: damon-tests: build_m68k.sh
ok 13 selftests: damon-tests: build_i386_idle_flag.sh
ok 14 selftests: damon-tests: build_i386_highpte.sh
ok 15 selftests: damon-tests: build_nomemcg.sh
[33m
[92mPASS [39m
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [PATCH 6.9 000/157] 6.9.5-rc1 review
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (157 preceding siblings ...)
2024-06-13 16:51 ` [PATCH 6.9 000/157] 6.9.5-rc1 review SeongJae Park
@ 2024-06-14 1:44 ` Bagas Sanjaya
2024-06-14 6:14 ` Naresh Kamboju
` (7 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Bagas Sanjaya @ 2024-06-14 1:44 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor, allen.lkml, broonie
[-- Attachment #1: Type: text/plain, Size: 557 bytes --]
On Thu, Jun 13, 2024 at 01:32:05PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.9.5 release.
> There are 157 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
Successfully compiled and installed the kernel on my computer (Acer
Aspire E15, Intel Core i3 Haswell). No noticeable regressions.
Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [PATCH 6.9 000/157] 6.9.5-rc1 review
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (158 preceding siblings ...)
2024-06-14 1:44 ` Bagas Sanjaya
@ 2024-06-14 6:14 ` Naresh Kamboju
2024-06-14 9:38 ` Pavel Machek
` (6 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Naresh Kamboju @ 2024-06-14 6:14 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml, broonie
On Thu, 13 Jun 2024 at 17:18, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 6.9.5 release.
> There are 157 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 15 Jun 2024 11:31:50 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.9.5-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
## Build
* kernel: 6.9.5-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-6.9.y
* git commit: 3fc8ec8cbfb63bed37f4702410201c973a690450
* git describe: v6.9.2-957-g3fc8ec8cbfb6
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.9.y/build/v6.9.2-957-g3fc8ec8cbfb6
## Test Regressions (compared to v6.9.2-797-g4aee3af1daf2)
## Metric Regressions (compared to v6.9.2-797-g4aee3af1daf2)
## Test Fixes (compared to v6.9.2-797-g4aee3af1daf2)
## Metric Fixes (compared to v6.9.2-797-g4aee3af1daf2)
## Test result summary
total: 163101, pass: 141914, fail: 2059, skip: 19128, xfail: 0
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 129 total, 129 passed, 0 failed
* arm64: 38 total, 38 passed, 0 failed
* i386: 29 total, 29 passed, 0 failed
* mips: 24 total, 24 passed, 0 failed
* parisc: 3 total, 3 passed, 0 failed
* powerpc: 34 total, 34 passed, 0 failed
* riscv: 17 total, 17 passed, 0 failed
* s390: 12 total, 12 passed, 0 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 33 total, 33 passed, 0 failed
## Test suites summary
* boot
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mm
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-user_events
* kselftest-vDSO
* kselftest-watchdog
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-smoke
* ltp-smoketest
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [PATCH 6.9 000/157] 6.9.5-rc1 review
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (159 preceding siblings ...)
2024-06-14 6:14 ` Naresh Kamboju
@ 2024-06-14 9:38 ` Pavel Machek
2024-06-14 11:44 ` Ron Economos
` (5 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Pavel Machek @ 2024-06-14 9:38 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml, broonie
[-- Attachment #1: Type: text/plain, Size: 948 bytes --]
Hi!
> This is the start of the stable review cycle for the 6.9.5 release.
> There are 157 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.9.y
6.6, 5.15, 5.4 pass our testing, too:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.6.y
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.15.y
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.4.y
Tested-by: Pavel Machek (CIP) <pavel@denx.de>
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [PATCH 6.9 000/157] 6.9.5-rc1 review
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (160 preceding siblings ...)
2024-06-14 9:38 ` Pavel Machek
@ 2024-06-14 11:44 ` Ron Economos
2024-06-14 14:13 ` Mark Brown
` (4 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Ron Economos @ 2024-06-14 11:44 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor, allen.lkml, broonie
On 6/13/24 4:32 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.9.5 release.
> There are 157 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 15 Jun 2024 11:31:50 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.9.5-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Tested-by: Ron Economos <re@w6rz.net>
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [PATCH 6.9 000/157] 6.9.5-rc1 review
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (161 preceding siblings ...)
2024-06-14 11:44 ` Ron Economos
@ 2024-06-14 14:13 ` Mark Brown
2024-06-14 17:04 ` Jon Hunter
` (3 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Mark Brown @ 2024-06-14 14:13 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml
[-- Attachment #1: Type: text/plain, Size: 344 bytes --]
On Thu, Jun 13, 2024 at 01:32:05PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.9.5 release.
> There are 157 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
Tested-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [PATCH 6.9 000/157] 6.9.5-rc1 review
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (162 preceding siblings ...)
2024-06-14 14:13 ` Mark Brown
@ 2024-06-14 17:04 ` Jon Hunter
2024-06-15 1:59 ` Peter Schneider
` (2 subsequent siblings)
166 siblings, 0 replies; 168+ messages in thread
From: Jon Hunter @ 2024-06-14 17:04 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml, broonie,
linux-tegra, stable
On Thu, 13 Jun 2024 13:32:05 +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.9.5 release.
> There are 157 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 15 Jun 2024 11:31:50 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.9.5-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v6.9:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
116 tests: 116 pass, 0 fail
Linux version: 6.9.5-rc1-g3fc8ec8cbfb6
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [PATCH 6.9 000/157] 6.9.5-rc1 review
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (163 preceding siblings ...)
2024-06-14 17:04 ` Jon Hunter
@ 2024-06-15 1:59 ` Peter Schneider
2024-06-15 2:09 ` Shuah Khan
2024-06-16 13:51 ` Florian Fainelli
166 siblings, 0 replies; 168+ messages in thread
From: Peter Schneider @ 2024-06-15 1:59 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor, allen.lkml, broonie
Am 13.06.2024 um 13:32 schrieb Greg Kroah-Hartman:
> This is the start of the stable review cycle for the 6.9.5 release.
> There are 157 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
Builds, boots and works fine w/o regressions on 2-socket Ivy Bridge Xeon E5-2697 v2.
Everything looking good. Except from simply firing up 12 VMs, I have not done any serious
load testing this time though.
Tested-by: Peter Schneider <pschneider1968@googlemail.com>
Beste Grüße,
Peter Schneider
--
Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you. -- David McCullough Jr.
OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244
Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc
https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@googlemail.com
https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@gmail.com
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [PATCH 6.9 000/157] 6.9.5-rc1 review
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (164 preceding siblings ...)
2024-06-15 1:59 ` Peter Schneider
@ 2024-06-15 2:09 ` Shuah Khan
2024-06-16 13:51 ` Florian Fainelli
166 siblings, 0 replies; 168+ messages in thread
From: Shuah Khan @ 2024-06-15 2:09 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor, allen.lkml, broonie, Shuah Khan
On 6/13/24 05:32, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.9.5 release.
> There are 157 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 15 Jun 2024 11:31:50 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.9.5-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 168+ messages in thread* Re: [PATCH 6.9 000/157] 6.9.5-rc1 review
2024-06-13 11:32 [PATCH 6.9 000/157] 6.9.5-rc1 review Greg Kroah-Hartman
` (165 preceding siblings ...)
2024-06-15 2:09 ` Shuah Khan
@ 2024-06-16 13:51 ` Florian Fainelli
166 siblings, 0 replies; 168+ messages in thread
From: Florian Fainelli @ 2024-06-16 13:51 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, sudipm.mukherjee, srw, rwarsow,
conor, allen.lkml, broonie
On 6/13/2024 12:32 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.9.5 release.
> There are 157 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 15 Jun 2024 11:31:50 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.9.5-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
On ARCH_BRCMST using 32-bit and 64-bit ARM kernels, build tested on
BMIPS_GENERIC:
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
--
Florian
^ permalink raw reply [flat|nested] 168+ messages in thread