6.6.46-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 148/189 tracing: Fix overflow in get_free_elt()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tze-nan Wu <[email protected]>
commit bcf86c01ca4676316557dd482c8416ece8c2e143 upstream.
"tracing_map->next_elt" in get_free_elt() is at risk of overflowing.
Once it overflows, new elements can still be inserted into the tracing_map even though the maximum number of elements (max_elts) has been reached. Continuing to insert elements after the overflow could result in the tracing_map containing "tracing_map->max_size" elements, leaving no empty entries.
If any attempt is made to insert an element into a full tracing_map using __tracing_map_insert(), it will cause an infinite loop with preemption disabled, leading to a CPU hang problem.
Fix this by preventing any further increments to "tracing_map->next_elt" once it reaches "tracing_map->max_elt".
--- kernel/trace/tracing_map.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
kernel/trace/tracing_map.c +3 -3
@@ -454,7 +454,7 @@ static struct tracing_map_elt *get_free_struct tracing_map_elt *elt =NULL ;int idx; - idx =atomic_inc_return (&map->next_elt); + idx =atomic_fetch_add_unless (&map->next_elt,1 , map->max_elts);if (idx < map->max_elts) { elt = *(TRACING_MAP_ELT (map->elts, idx));if (map->ops && map->ops->elt_init)
@@ -699,7 +699,7 @@ void tracing_map_clear(struct tracing_ma {unsigned int i; -atomic_set (&map->next_elt,-1 ); +atomic_set (&map->next_elt,0 );atomic64_set (&map->hits,0 );atomic64_set (&map->drops,0 );
@@ -783,7 +783,7 @@ struct tracing_map *tracing_map_create(u map->map_bits = map_bits; map->max_elts = (1 << map_bits); -atomic_set (&map->next_elt,-1 ); +atomic_set (&map->next_elt,0 ); map->map_size = (1 << (map_bits +1 )); map->ops = ops;
Greg Kroah-Hartman
maintainerPATCH 149/189 padata: Fix possible divide-by-0 panic in padata_mt_helper()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Waiman Long <[email protected]>
commit 6d45e1c948a8b7ed6ceddb14319af69424db730c upstream.
We are hit with a not easily reproducible divide-by-0 panic in padata.c at bootup time.
[ 10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI
[ 10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1
[ 10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021
[ 10.017908] Workqueue: events_unbound padata_mt_helper
[ 10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0
:
[ 10.017963] Call Trace:
[ 10.017968] <TASK>
[ 10.018004] ? padata_mt_helper+0x39/0xb0
[ 10.018084] process_one_work+0x174/0x330
[ 10.018093] worker_thread+0x266/0x3a0
[ 10.018111] kthread+0xcf/0x100
[ 10.018124] ret_from_fork+0x31/0x50
[ 10.018138] ret_from_fork_asm+0x1a/0x30
[ 10.018147] </TASK>Looking at the padata_mt_helper() function, the only way a divide-by-0 panic can happen is when ps->chunk_size is 0. The way that chunk_size is initialized in padata_do_multithreaded(), chunk_size can be 0 when the min_chunk in the passed-in padata_mt_job structure is 0.
Fix this divide-by-0 panic by making sure that chunk_size will be at least 1 no matter what the input parameters are.
--- kernel/padata.c | 7 +++++++ 1 file changed, 7 insertions(+)
kernel/padata.c +7 -0
@@ -516,6 +516,13 @@ void __init padata_do_multithreaded(stru ps.chunk_size =max (ps.chunk_size, job->min_chunk); ps.chunk_size =roundup (ps.chunk_size, job->align); +/* +* chunk_size can be 0 if the caller sets min_chunk to 0. So force it +* to at least 1 to prevent divide-by-0 panic in padata_mt_helper().` +*/ +if (!ps.chunk_size) + ps.chunk_size =1U ; +list_for_each_entry (pw, &works, pw_list)queue_work (system_unbound_wq, &pw->pw_work);
Greg Kroah-Hartman
maintainerPATCH 150/189 smb3: fix setting SecurityFlags when encryption is required
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steve French <[email protected]>
commit 1b5487aefb1ce7a6b1f15a33297d1231306b4122 upstream.
Setting encryption as required in security flags was broken. For example (to require all mounts to be encrypted by setting):
"echo 0x400c5 > /proc/fs/cifs/SecurityFlags"
Would return "Invalid argument" and log "Unsupported security flags" This patch fixes that (e.g. allowing overriding the default for SecurityFlags 0x00c5, including 0x40000 to require seal, ie SMB3.1.1 encryption) so now that works and forces encryption on subsequent mounts.
--- Documentation/admin-guide/cifs/usage.rst | 2 +- fs/smb/client/cifs_debug.c | 2 +- fs/smb/client/cifsglob.h | 8 ++++---- fs/smb/client/smb2pdu.c | 3 +++ 4 files changed, 9 insertions(+), 6 deletions(-)
Documentation/admin-guide/cifs/usage.rst +1 -1
@@ -741,7 +741,7 @@ SecurityFlags Flags which control secur may use NTLMSSP 0x00080 must use NTLMSSP 0x80080 seal (packet encryption) 0x00040 - must seal (not implemented yet) 0x40040 + must seal 0x40040 cifsFYI If set to non-zero value, additional debug information will be logged to the system error log. This field
fs/smb/client/cifs_debug.c +1 -1
@@ -1072,7 +1072,7 @@ static int cifs_security_flags_proc_openstatic void cifs_security_flags_handle_must_flags (unsigned int *flags) { -unsigned int signflags = *flags &CIFSSEC_MUST_SIGN ; +unsigned int signflags = *flags & (CIFSSEC_MUST_SIGN |CIFSSEC_MUST_SEAL );if ((*flags &CIFSSEC_MUST_KRB5 ) ==CIFSSEC_MUST_KRB5 ) *flags =CIFSSEC_MUST_KRB5 ;
fs/smb/client/cifsglob.h +4 -4
@@ -1922,7 +1922,7 @@ static inline bool is_replayable_error(i#define CIFSSEC_MAY_SIGN 0x00001#define CIFSSEC_MAY_NTLMV2 0x00004#define CIFSSEC_MAY_KRB5 0x00008 -#define CIFSSEC_MAY_SEAL 0x00040/* not supported yet */ +#define CIFSSEC_MAY_SEAL 0x00040#define CIFSSEC_MAY_NTLMSSP 0x00080/* raw ntlmssp with ntlmv2 */ #define CIFSSEC_MUST_SIGN 0x01001
@@ -1932,11 +1932,11 @@ require use of the stronger protocol */#define CIFSSEC_MUST_NTLMV2 0x04004#define CIFSSEC_MUST_KRB5 0x08008#ifdef CONFIG_CIFS_UPCALL -#define CIFSSEC_MASK 0x8F08F/* flags supported if no weak allowed */ +#define CIFSSEC_MASK 0xCF0CF/* flags supported if no weak allowed */ #else -#define CIFSSEC_MASK 0x87087/* flags supported if no weak allowed */ +#define CIFSSEC_MASK 0xC70C7/* flags supported if no weak allowed */ #endif /* UPCALL */ -#define CIFSSEC_MUST_SEAL 0x40040/* not supported yet */ +#define CIFSSEC_MUST_SEAL 0x40040#define CIFSSEC_MUST_NTLMSSP 0x80080/* raw ntlmssp with ntlmv2 */ #define CIFSSEC_DEF (CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLMV2 | CIFSSEC_MAY_NTLMSSP | CIFSSEC_MAY_SEAL)
fs/smb/client/smb2pdu.c +3 -0
@@ -80,6 +80,9 @@ int smb3_encryption_required(const strucif (tcon->seal && (tcon->ses->server->capabilities &SMB2_GLOBAL_CAP_ENCRYPTION ))return 1 ; +if (((global_secflags &CIFSSEC_MUST_SEAL ) ==CIFSSEC_MUST_SEAL ) && + (tcon->ses->server->capabilities &SMB2_GLOBAL_CAP_ENCRYPTION )) +return 1 ;return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 151/189 eventfs: Dont return NULL in eventfs_create_dir()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Krause <[email protected]>
commit 12c20c65d0460cf34f9a665d8f0c0d77d45a3829 upstream.
Commit 77a06c33a22d ("eventfs: Test for ei->is_freed when accessing ei->dentry") added another check, testing if the parent was freed after we released the mutex. If so, the function returns NULL. However, all callers expect it to either return a valid pointer or an error pointer, at least since commit 5264a2f4bb3b ("tracing: Fix a NULL vs IS_ERR() bug in event_subsystem_dir()"). Returning NULL will therefore fail the error condition check in the caller.
Fix this by substituting the NULL return value with a fitting error pointer.
--- fs/tracefs/event_inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/tracefs/event_inode.c +1 -1
@@ -806,7 +806,7 @@ struct eventfs_inode *eventfs_create_dir/* Was the parent freed? */ if (list_empty (&ei->list)) {cleanup_ei (ei); - ei =NULL ; + ei =ERR_PTR (-EBUSY ); }return ei; }
Greg Kroah-Hartman
maintainerPATCH 152/189 eventfs: Use SRCU for freeing eventfs_inodes
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Krause <[email protected]>
commit 8e556432477e97ad6179c61b61a32bf5f1af2355 upstream.
To mirror the SRCU lock held in eventfs_iterate() when iterating over eventfs inodes, use call_srcu() to free them too.
This was accidentally(?) degraded to RCU in commit 43aa6f97c2d0 ("eventfs: Get rid of dentry pointers without refcounts").
--- fs/tracefs/event_inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/tracefs/event_inode.c +1 -1
@@ -113,7 +113,7 @@ static void release_ei(struct kref *ref) entry->release (entry->name, ei->data); } -call_rcu (&ei->rcu, free_ei_rcu); +call_srcu (&eventfs_srcu, &ei->rcu, free_ei_rcu); }static inline void put_ei (struct eventfs_inode *ei)
Greg Kroah-Hartman
maintainerPATCH 153/189 selftests: mm: add s390 to ARCH check
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nico Pache <[email protected]>
commit 30b651c8bc788c068a978dc760e9d5f824f7019e upstream.
commit 0518dbe97fe6 ("selftests/mm: fix cross compilation with LLVM") changed the env variable for the architecture from MACHINE to ARCH.
This is preventing 3 required TEST_GEN_FILES from being included when cross compiling s390x and errors when trying to run the test suite. This is due to the ARCH variable already being set and the arch folder name being s390.
Add "s390" to the filtered list to cover this case and have the 3 files included in the build.
--- tools/testing/selftests/mm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/testing/selftests/mm/Makefile +1 -1
@@ -101,7 +101,7 @@ endif endif -ifneq (,$(filter $(ARCH),arm64 ia64 mips64 parisc64 powerpc riscv64 s390x sparc64 x86_64)) +ifneq (,$(filter $(ARCH),arm64 ia64 mips64 parisc64 powerpc riscv64 s390x sparc64 x86_64 s390)) TEST_GEN_FILES += va_high_addr_switch TEST_GEN_FILES += virtual_address_range TEST_GEN_FILES += write_to_hugetlbfs
Greg Kroah-Hartman
maintainerPATCH 154/189 btrfs: avoid using fixed char array size for tree names
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qu Wenruo <[email protected]>
commit 12653ec36112ab55fa06c01db7c4432653d30a8d upstream.
[BUG]
There is a bug report that using the latest trunk GCC 15, btrfs would cause unterminated-string-initialization warning:
linux-6.6/fs/btrfs/print-tree.c:29:49: error: initializer-string for array of ‘char’ is too long [-Werror=unterminated-string-initialization]
29 | { BTRFS_BLOCK_GROUP_TREE_OBJECTID, "BLOCK_GROUP_TREE" },
|
^~~~~~~~~~~~~~~~~~[CAUSE]
To print tree names we have an array of root_name_map structure, which uses "char name[16];" to store the name string of a tree.
But the following trees have names exactly at 16 chars length:
- "BLOCK_GROUP_TREE"
- "RAID_STRIPE_TREE"
This means we will have no space for the terminating '\0', and can lead to unexpected access when printing the name.
[FIX]
Instead of "char name[16];" use "const char *" instead.
Since the name strings are all read-only data, and are all NULL terminated by default, there is not much need to bother the length at all.
--- fs/btrfs/print-tree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/btrfs/print-tree.c +1 -1
@@ -12,7 +12,7 @@struct root_name_map {u64 id; -char name[16 ]; +const char *name; };static const struct root_name_map root_map[] = {
Greg Kroah-Hartman
maintainerPATCH 155/189 x86/paravirt: Fix incorrect virt spinlock setting on bare metal
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen Yu <[email protected]>
commit e639222a51196c69c70b49b67098ce2f9919ed08 upstream.
The kernel can change spinlock behavior when running as a guest. But this guest-friendly behavior causes performance problems on bare metal.
The kernel uses a static key to switch between the two modes.
In theory, the static key is enabled by default (run in guest mode) and should be disabled for bare metal (and in some guests that want native behavior or paravirt spinlock).
A performance drop is reported when running encode/decode workload and BenchSEE cache sub-workload.
Bisect points to commit ce0a1b608bfc ("x86/paravirt: Silence unused native_pv_lock_init() function warning"). When CONFIG_PARAVIRT_SPINLOCKS is disabled the virt_spin_lock_key is incorrectly set to true on bare metal. The qspinlock degenerates to test-and-set spinlock, which decreases the performance on bare metal.
Set the default value of virt_spin_lock_key to false. If booting in a VM, enable this key. Later during the VM initialization, if other high-efficient spinlock is preferred (e.g. paravirt-spinlock), or the user wants the native qspinlock (via nopvspin boot commandline), the virt_spin_lock_key is disabled accordingly.
This results in the following decision matrix:
X86_FEATURE_HYPERVISOR Y Y Y N CONFIG_PARAVIRT_SPINLOCKS Y Y N Y/N PV spinlock Y N N Y/N
virt_spin_lock_key N Y/N Y N
--- arch/x86/include/asm/qspinlock.h | 12 +++++++----- arch/x86/kernel/paravirt.c | 7 +++---- 2 files changed, 10 insertions(+), 9 deletions(-)
arch/x86/include/asm/qspinlock.h +7 -5
@@ -66,13 +66,15 @@ static inline bool vcpu_is_preempted(lon#ifdef CONFIG_PARAVIRT /* -* virt_spin_lock_key - enables (by default) the virt_spin_lock() hijack. +* virt_spin_lock_key - disables by default the virt_spin_lock() hijack. * -* Native (and PV wanting native due to vCPU pinning) should disable this key. -* It is done in this backwards fashion to only have a single direction change, -* which removes ordering between native_pv_spin_init() and HV setup. +* Native (and PV wanting native due to vCPU pinning) should keep this key +* disabled. Native does not touch the key. +* +* When in a guest then native_pv_lock_init() enables the key first and +* KVM/XEN might conditionally disable it later in the boot process again. */ -DECLARE_STATIC_KEY_TRUE (virt_spin_lock_key); +DECLARE_STATIC_KEY_FALSE (virt_spin_lock_key);/* * Shortcut for the queued_spin_lock_slowpath() function that allows
arch/x86/kernel/paravirt.c +3 -4
@@ -71,13 +71,12 @@ DEFINE_PARAVIRT_ASM(pv_native_irq_enable DEFINE_PARAVIRT_ASM(pv_native_read_cr2, "mov %cr2, %rax", .noinstr.text);#endif -DEFINE_STATIC_KEY_TRUE (virt_spin_lock_key); +DEFINE_STATIC_KEY_FALSE (virt_spin_lock_key);void __init native_pv_lock_init (void ) { -if (IS_ENABLED (CONFIG_PARAVIRT_SPINLOCKS ) && - !boot_cpu_has (X86_FEATURE_HYPERVISOR )) -static_branch_disable (&virt_spin_lock_key); +if (boot_cpu_has (X86_FEATURE_HYPERVISOR )) +static_branch_enable (&virt_spin_lock_key); }static void native_tlb_remove_table (struct mmu_gather *tlb,void *table)
Greg Kroah-Hartman
maintainerPATCH 156/189 x86/mtrr: Check if fixed MTRRs exist before saving them
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andi Kleen <[email protected]>
commit 919f18f961c03d6694aa726c514184f2311a4614 upstream.
MTRRs have an obsolete fixed variant for fine grained caching control of the 640K-1MB region that uses separate MSRs. This fixed variant has a separate capability bit in the MTRR capability MSR.
So far all x86 CPUs which support MTRR have this separate bit set, so it went unnoticed that mtrr_save_state() does not check the capability bit before accessing the fixed MTRR MSRs.
Though on a CPU that does not support the fixed MTRR capability this results in a #GP. The #GP itself is harmless because the RDMSR fault is handled gracefully, but results in a WARN_ON().
Add the missing capability check to prevent this.
--- arch/x86/kernel/cpu/mtrr/mtrr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/cpu/mtrr/mtrr.c +1 -1
@@ -609,7 +609,7 @@ void mtrr_save_state(void) {int first_cpu; -if (!mtrr_enabled ()) +if (!mtrr_enabled () || !mtrr_state.have_fixed)return ; first_cpu =cpumask_first (cpu_online_mask);
Greg Kroah-Hartman
maintainerPATCH 157/189 sched/smt: Introduce sched_smt_present_inc/dec() helper
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Yingliang <[email protected]>
commit 31b164e2e4af84d08d2498083676e7eeaa102493 upstream.
Introduce sched_smt_present_inc/dec() helper, so it can be called in normal or error path simply. No functional changed.
--- kernel/sched/core.c | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-)
kernel/sched/core.c +19 -7
@@ -9646,6 +9646,22 @@ static int cpuset_cpu_inactive(unsignedreturn 0 ; } +static inline void sched_smt_present_inc (int cpu) +{ +#ifdef CONFIG_SCHED_SMT +if (cpumask_weight (cpu_smt_mask (cpu)) ==2 ) +static_branch_inc_cpuslocked (&sched_smt_present); +#endif +} + +static inline void sched_smt_present_dec (int cpu) +{ +#ifdef CONFIG_SCHED_SMT +if (cpumask_weight (cpu_smt_mask (cpu)) ==2 ) +static_branch_dec_cpuslocked (&sched_smt_present); +#endif +} +int sched_cpu_activate (unsigned int cpu) {struct rq *rq =cpu_rq (cpu);
@@ -9657,13 +9673,10 @@ int sched_cpu_activate(unsigned int cpu)*/ balance_push_set (cpu, false); -#ifdef CONFIG_SCHED_SMT /* * When going up, increment the number of cores with SMT present. */ -if (cpumask_weight (cpu_smt_mask (cpu)) ==2 ) -static_branch_inc_cpuslocked (&sched_smt_present); -#endif +sched_smt_present_inc (cpu);set_cpu_active (cpu, true);if (sched_smp_initialized) {
@@ -9732,13 +9745,12 @@ int sched_cpu_deactivate(unsigned int cp }rq_unlock_irqrestore (rq, &rf); -#ifdef CONFIG_SCHED_SMT /* * When going down, decrement the number of cores with SMT present. */ -if (cpumask_weight (cpu_smt_mask (cpu)) ==2 ) -static_branch_dec_cpuslocked (&sched_smt_present); +sched_smt_present_dec (cpu); +#ifdef CONFIG_SCHED_SMT sched_core_cpu_deactivate (cpu);#endif
Greg Kroah-Hartman
maintainerPATCH 158/189 sched/smt: Fix unbalance sched_smt_present dec/inc
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Yingliang <[email protected]>
commit e22f910a26cc2a3ac9c66b8e935ef2a7dd881117 upstream.
I got the following warn report while doing stress test:
jump label: negative count!
WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0 Call Trace: <TASK> __static_key_slow_dec_cpuslocked+0x16/0x70 sched_cpu_deactivate+0x26e/0x2a0 cpuhp_invoke_callback+0x3ad/0x10d0 cpuhp_thread_fun+0x3f5/0x680 smpboot_thread_fn+0x56d/0x8d0 kthread+0x309/0x400 ret_from_fork+0x41/0x70 ret_from_fork_asm+0x1b/0x30 </TASK>
Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(), the cpu offline failed, but sched_smt_present is decremented before calling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so fix it by incrementing sched_smt_present in the error path.
--- kernel/sched/core.c | 1 + 1 file changed, 1 insertion(+)
kernel/sched/core.c +1 -0
@@ -9760,6 +9760,7 @@ int sched_cpu_deactivate(unsigned int cpsched_update_numa (cpu, false); ret =cpuset_cpu_inactive (cpu);if (ret) { +sched_smt_present_inc (cpu);balance_push_set (cpu, false);set_cpu_active (cpu, true);sched_update_numa (cpu, true);
Greg Kroah-Hartman
maintainerPATCH 159/189 sched/core: Introduce sched_set_rq_on/offline() helper
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Yingliang <[email protected]>
commit 2f027354122f58ee846468a6f6b48672fff92e9b upstream.
Introduce sched_set_rq_on/offline() helper, so it can be called in normal or error path simply. No functional changed.
--- kernel/sched/core.c | 40 ++++++++++++++++++++++++++-------------- 1 file changed, 26 insertions(+), 14 deletions(-)
kernel/sched/core.c +26 -14
@@ -9596,6 +9596,30 @@ void set_rq_offline(struct rq *rq) } } +static inline void sched_set_rq_online (struct rq *rq,int cpu) +{ +struct rq_flags rf; + +rq_lock_irqsave (rq, &rf); +if (rq->rd) { +BUG_ON (!cpumask_test_cpu (cpu, rq->rd->span)); +set_rq_online (rq); + } +rq_unlock_irqrestore (rq, &rf); +} + +static inline void sched_set_rq_offline (struct rq *rq,int cpu) +{ +struct rq_flags rf; + +rq_lock_irqsave (rq, &rf); +if (rq->rd) { +BUG_ON (!cpumask_test_cpu (cpu, rq->rd->span)); +set_rq_offline (rq); + } +rq_unlock_irqrestore (rq, &rf); +} +/* * used to mark begin/end of suspend/resume: */
@@ -9665,7 +9689,6 @@ static inline void sched_smt_present_decint sched_cpu_activate (unsigned int cpu) {struct rq *rq =cpu_rq (cpu); -struct rq_flags rf;/* * Clear the balance_push callback and prepare to schedule
@@ -9694,12 +9717,7 @@ int sched_cpu_activate(unsigned int cpu)* 2) At runtime, if cpuset_cpu_active() fails to rebuild the * domains. */ -rq_lock_irqsave (rq, &rf); -if (rq->rd) { -BUG_ON (!cpumask_test_cpu (cpu, rq->rd->span)); -set_rq_online (rq); - } -rq_unlock_irqrestore (rq, &rf); +sched_set_rq_online (rq, cpu);return 0 ; }
@@ -9707,7 +9725,6 @@ int sched_cpu_activate(unsigned int cpu)int sched_cpu_deactivate (unsigned int cpu) {struct rq *rq =cpu_rq (cpu); -struct rq_flags rf;int ret;/*
@@ -9738,12 +9755,7 @@ int sched_cpu_deactivate(unsigned int cp*/ synchronize_rcu (); -rq_lock_irqsave (rq, &rf); -if (rq->rd) { -BUG_ON (!cpumask_test_cpu (cpu, rq->rd->span)); -set_rq_offline (rq); - } -rq_unlock_irqrestore (rq, &rf); +sched_set_rq_offline (rq, cpu);/* * When going down, decrement the number of cores with SMT present.
Greg Kroah-Hartman
maintainerPATCH 160/189 sched/core: Fix unbalance set_rq_online/offline() in sched_cpu_deactivate()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Yingliang <[email protected]>
commit fe7a11c78d2a9bdb8b50afc278a31ac177000948 upstream.
If cpuset_cpu_inactive() fails, set_rq_online() need be called to rollback.
--- kernel/sched/core.c | 1 + 1 file changed, 1 insertion(+)
kernel/sched/core.c +1 -0
@@ -9773,6 +9773,7 @@ int sched_cpu_deactivate(unsigned int cp ret =cpuset_cpu_inactive (cpu);if (ret) {sched_smt_present_inc (cpu); +sched_set_rq_online (rq, cpu);balance_push_set (cpu, false);set_cpu_active (cpu, true);sched_update_numa (cpu, true);
Greg Kroah-Hartman
maintainerPATCH 161/189 drm/bridge: analogix_dp: properly handle zero sized AUX transactions
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lucas Stach <[email protected]>
commit e82290a2e0e8ec5e836ecad1ca025021b3855c2d upstream.
Address only transactions without any data are valid and should not be flagged as short transactions. Simply return the message size when no transaction errors occured.
--- drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c +1 -4
@@ -1027,7 +1027,6 @@ ssize_t analogix_dp_transfer(struct analu32 status_reg;u8 *buffer = msg->buffer;unsigned int i; -int num_transferred =0 ;int ret;/* Buffer size of AUX CH is 16 bytes */
@@ -1079,7 +1078,6 @@ ssize_t analogix_dp_transfer(struct anal reg = buffer[i];writel (reg, dp->reg_base +ANALOGIX_DP_BUF_DATA_0 +4 * i); - num_transferred++; } }
@@ -1127,7 +1125,6 @@ ssize_t analogix_dp_transfer(struct anal reg =readl (dp->reg_base +ANALOGIX_DP_BUF_DATA_0 +4 * i); buffer[i] = (unsigned char )reg; - num_transferred++; } }
@@ -1144,7 +1141,7 @@ ssize_t analogix_dp_transfer(struct anal (msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_READ) msg->reply = DP_AUX_NATIVE_REPLY_ACK; -return num_transferred >0 ? num_transferred : -EBUSY ; +return msg->size; aux_error:/* if aux err happen, reset aux */
Greg Kroah-Hartman
maintainerPATCH 162/189 drm/dp_mst: Skip CSN if topology probing is not done yet
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wayne Lin <[email protected]>
commit ddf983488c3e8d30d5c2e2b315ae7d9cd87096ed upstream.
[Why]
During resume, observe that we receive CSN event before we start topology probing. Handling CSN at this moment based on uncertain topology is unnecessary.
[How]
Add checking condition in drm_dp_mst_handle_up_req() to skip handling CSN if the topology is yet to be probed.
--- drivers/gpu/drm/display/drm_dp_mst_topology.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/gpu/drm/display/drm_dp_mst_topology.c +11 -0
@@ -4024,6 +4024,7 @@ static int drm_dp_mst_handle_up_req(struif (up_req->msg.req_type ==DP_CONNECTION_STATUS_NOTIFY ) {const struct drm_dp_connection_status_notify *conn_stat = &up_req->msg.u.conn_stat; +bool handle_csn; drm_dbg_kms(mgr->dev, "Got CSN: pn: %d ldps:%d ddps: %d mcs: %d ip: %d pdt: %d\n", conn_stat->port_number,
@@ -4032,6 +4033,16 @@ static int drm_dp_mst_handle_up_req(stru conn_stat->message_capability_status, conn_stat->input_port, conn_stat->peer_device_type); + +mutex_lock (&mgr->probe_lock); + handle_csn = mgr->mst_primary->link_address_sent; +mutex_unlock (&mgr->probe_lock); + +if (!handle_csn) { +drm_dbg_kms (mgr->dev,"Got CSN before finish topology probing. Skip it." ); +kfree (up_req); + goto out; + } }else if (up_req->msg.req_type ==DP_RESOURCE_STATUS_NOTIFY ) {const struct drm_dp_resource_status_notify *res_stat = &up_req->msg.u.resource_stat;
Greg Kroah-Hartman
maintainerPATCH 163/189 drm/lima: Mark simple_ondemand governor as softdep
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dragan Simic <[email protected]>
commit 0c94f58cef319ad054fd909b3bf4b7d09c03e11c upstream.
Lima DRM driver uses devfreq to perform DVFS, while using simple_ondemand devfreq governor by default. This causes driver initialization to fail on boot when simple_ondemand governor isn't built into the kernel statically, as a result of the missing module dependency and, consequently, the required governor module not being included in the initial ramdisk. Thus, let's mark simple_ondemand governor as a softdep for Lima, to have its kernel module included in the initial ramdisk.
This is a rather longstanding issue that has forced distributions to build devfreq governors statically into their kernels, [1][2] or may have forced some users to introduce unnecessary workarounds.
Having simple_ondemand marked as a softdep for Lima may not resolve this issue for all Linux distributions. In particular, it will remain unresolved for the distributions whose utilities for the initial ramdisk generation do not handle the available softdep information [3] properly yet. However, some Linux distributions already handle softdeps properly while generating their initial ramdisks, [4] and this is a prerequisite step in the right direction for the distributions that don't handle them properly yet.
[1] https://gitlab.manjaro.org/manjaro-arm/packages/core/linux-pinephone/-/blob/6.7-megi/config?ref_type=heads#L5749
[2] https://gitlab.com/postmarketOS/pmaports/-/blob/7f64e287e7732c9eaa029653e73ca3d4ba1c8598/main/linux-postmarketos-allwinner/config-postmarketos-allwinner.aarch64#L4654
[3] https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/commit/?id=49d8e0b59052999de577ab732b719cfbeb89504d
[4] https://github.com/archlinux/mkinitcpio/commit/97ac4d37aae084a050be512f6d8f4489054668ad
--- drivers/gpu/drm/lima/lima_drv.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/lima/lima_drv.c +1 -0
@@ -486,3 +486,4 @@ module_platform_driver(lima_platform_driMODULE_AUTHOR ("Lima Project Developers" );MODULE_DESCRIPTION ("Lima DRM Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_SOFTDEP ("pre: governor_simpleondemand" );
Greg Kroah-Hartman
maintainerPATCH 164/189 drm/mgag200: Set DDC timeout in milliseconds
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Zimmermann <[email protected]>
commit ecde5db1598aecab54cc392282c15114f526f05f upstream.
Compute the i2c timeout in jiffies from a value in milliseconds. The original values of 2 jiffies equals 2 milliseconds if HZ has been configured to a value of 1000. This corresponds to 2.2 milliseconds used by most other DRM drivers. Update mgag200 accordingly.
--- drivers/gpu/drm/mgag200/mgag200_i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/mgag200/mgag200_i2c.c +1 -1
@@ -115,7 +115,7 @@ int mgag200_i2c_init(struct mga_device * i2c->adapter.algo_data = &i2c->bit; i2c->bit.udelay =10 ; - i2c->bit.timeout =2 ; + i2c->bit.timeout =usecs_to_jiffies (2200 ); i2c->bit.data = i2c; i2c->bit.setsda = mga_gpio_setsda; i2c->bit.setscl = mga_gpio_setscl;
Greg Kroah-Hartman
maintainerPATCH 165/189 drm/mgag200: Bind I2C lifetime to DRM device
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Zimmermann <[email protected]>
commit eb1ae34e48a09b7a1179c579aed042b032e408f4 upstream.
Managed cleanup with devm_add_action_or_reset() will release the I2C adapter when the underlying Linux device goes away. But the connector still refers to it, so this cleanup leaves behind a stale pointer in struct drm_connector.ddc.
Bind the lifetime of the I2C adapter to the connector's lifetime by using DRM's managed release. When the DRM device goes away (after the Linux device) DRM will first clean up the connector and then clean up the I2C adapter.
--- drivers/gpu/drm/mgag200/mgag200_i2c.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/gpu/drm/mgag200/mgag200_i2c.c +4 -2
@@ -31,6 +31,8 @@#include <linux/i2c.h> #include <linux/pci.h> +#include <drm/drm_managed.h> +#include "mgag200_drv.h" static int mga_i2c_read_gpio (struct mga_device *mdev)
@@ -86,7 +88,7 @@ static int mga_gpio_getscl(void *data)return (mga_i2c_read_gpio (mdev) & i2c->clock) ?1 :0 ; } -static void mgag200_i2c_release (void *res) +static void mgag200_i2c_release (struct drm_device *dev,void *res) {struct mga_i2c_chan *i2c = res;
@@ -126,5 +128,5 @@ int mgag200_i2c_init(struct mga_device *if (ret)return ret; -return devm_add_action_or_reset (dev->dev, mgag200_i2c_release, i2c); +return drmm_add_action_or_reset (dev, mgag200_i2c_release, i2c); }
Greg Kroah-Hartman
maintainerPATCH 166/189 drm/radeon: Remove __counted_by from StateArray.states[]
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bill Wendling <[email protected]>
commit 2bac084468847cfe5bbc7166082b2a208514bb1c upstream.
Work for __counted_by on generic pointers in structures (not just flexible array members) has started landing in Clang 19 (current tip of tree). During the development of this feature, a restriction was added to __counted_by to prevent the flexible array member's element type from including a flexible array member itself such as:
struct foo {
int count;
char buf[];
};
struct bar {
int count;
struct foo data[] __counted_by(count);
};because the size of data cannot be calculated with the standard array size formula:
sizeof(struct foo) * count
This restriction was downgraded to a warning but due to CONFIG_WERROR, it can still break the build. The application of __counted_by on the states member of 'struct _StateArray' triggers this restriction, resulting in:
drivers/gpu/drm/radeon/pptable.h:442:5: error: 'counted_by' should not be applied to an array with element of unknown size because 'ATOM_PPLIB_STATE_V2' (aka 'struct _ATOM_PPLIB_STATE_V2') is a struct type with a flexible array member. This will be an error in a future compiler version [-Werror,-Wbounds-safety-counted-by-elt-type-unknown-size]
442 | ATOM_PPLIB_STATE_V2 states[] __counted_by(ucNumEntries);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~1 error generated.
Remove this use of __counted_by to fix the warning/error. However, rather than remove it altogether, leave it commented, as it may be possible to support this in future compiler releases.
--- drivers/gpu/drm/radeon/pptable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/radeon/pptable.h +1 -1
@@ -439,7 +439,7 @@ typedef struct _StateArray{//how many states we have UCHAR ucNumEntries; - ATOM_PPLIB_STATE_V2 states[] __counted_by(ucNumEntries); +ATOM_PPLIB_STATE_V2 states[]/* __counted_by(ucNumEntries) */ ; }StateArray;
Greg Kroah-Hartman
maintainerPATCH 167/189 mptcp: fully established after ADD_ADDR echo on MPJ
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthieu Baerts (NGI0) <[email protected]>
commit d67c5649c1541dc93f202eeffc6f49220a4ed71d upstream.
Before this patch, receiving an ADD_ADDR echo on the just connected MP_JOIN subflow -- initiator side, after the MP_JOIN 3WHS -- was resulting in an MP_RESET. That's because only ACKs with a DSS or ADD_ADDRs without the echo bit were allowed.
Not allowing the ADD_ADDR echo after an MP_CAPABLE 3WHS makes sense, as we are not supposed to send an ADD_ADDR before because it requires to be in full established mode first. For the MP_JOIN 3WHS, that's different:
the ADD_ADDR can be sent on a previous subflow, and the ADD_ADDR echo can be received on the recently created one. The other peer will already be in fully established, so it is allowed to send that.
We can then relax the conditions here to accept the ADD_ADDR echo for MPJ subflows.
--- net/mptcp/options.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/mptcp/options.c +2 -1
@@ -958,7 +958,8 @@ static bool check_fully_established(struif (subflow->remote_key_valid && (((mp_opt->suboptions &OPTION_MPTCP_DSS ) && mp_opt->use_ack) || - ((mp_opt->suboptions &OPTION_MPTCP_ADD_ADDR ) && !mp_opt->echo))) { + ((mp_opt->suboptions &OPTION_MPTCP_ADD_ADDR ) && + (!mp_opt->echo || subflow->mp_join)))) {/* subflows are fully established as soon as we get any * additional ack, including ADD_ADDR. */
Greg Kroah-Hartman
maintainerPATCH 168/189 mptcp: pm: fix backup support in signal endpoints
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthieu Baerts (NGI0) <[email protected]>
commit 6834097fc38c5416701c793da94558cea49c0a1f upstream.
There was a support for signal endpoints, but only when the endpoint's flag was changed during a connection. If an endpoint with the signal and backup was already present, the MP_JOIN reply was not containing the backup flag as expected.
That's confusing to have this inconsistent behaviour. On the other hand, the infrastructure to set the backup flag in the SYN + ACK + MP_JOIN was already there, it was just never set before. Now when requesting the local ID from the path-manager, the backup status is also requested.
Note that when the userspace PM is used, the backup flag can be set if the local address was already used before with a backup flag, e.g. if the address was announced with the 'backup' flag, or a subflow was created with the 'backup' flag.
[ Conflicts in pm_userspace.c because the context has changed in commit
1e07938e29c5 ("net: mptcp: rename netlink handlers to mptcp_pm_nl_<blah>_{doit,dumpit}") which is not in this version. This commit is unrelated to this modification.
Conflicts in protocol.h because the context has changed in commit 9ae7846c4b6b ("mptcp: dump addrs in userspace pm list") which is not in this version. This commit is unrelated to this modification. ]
--- net/mptcp/pm.c | 12 ++++++++++++ net/mptcp/pm_netlink.c | 18 ++++++++++++++++++ net/mptcp/pm_userspace.c | 18 ++++++++++++++++++ net/mptcp/protocol.h | 3 +++ net/mptcp/subflow.c | 3 +++ 5 files changed, 54 insertions(+)
net/mptcp/pm.c +12 -0
@@ -427,6 +427,18 @@ int mptcp_pm_get_local_id(struct mptcp_sreturn mptcp_pm_nl_get_local_id (msk, &skc_local); } +bool mptcp_pm_is_backup (struct mptcp_sock *msk,struct sock_common *skc) +{ +struct mptcp_addr_info skc_local; + +mptcp_local_address ((struct sock_common *)skc, &skc_local); + +if (mptcp_pm_is_userspace (msk)) +return mptcp_userspace_pm_is_backup (msk, &skc_local); + +return mptcp_pm_nl_is_backup (msk, &skc_local); +} +int mptcp_pm_get_flags_and_ifindex_by_id (struct mptcp_sock *msk,unsigned int id,u8 *flags,int *ifindex) {
net/mptcp/pm_netlink.c +18 -0
@@ -1109,6 +1109,24 @@ int mptcp_pm_nl_get_local_id(struct mptcreturn ret; } +bool mptcp_pm_nl_is_backup (struct mptcp_sock *msk,struct mptcp_addr_info *skc) +{ +struct pm_nl_pernet *pernet =pm_nl_get_pernet_from_msk (msk); +struct mptcp_pm_addr_entry *entry; +bool backup = false; + +rcu_read_lock (); +list_for_each_entry_rcu (entry, &pernet->local_addr_list, list) { +if (mptcp_addresses_equal (&entry->addr, skc, entry->addr.port)) { + backup = !!(entry->flags &MPTCP_PM_ADDR_FLAG_BACKUP ); +break ; + } + } +rcu_read_unlock (); + +return backup; +} +#define MPTCP_PM_CMD_GRP_OFFSET 0#define MPTCP_PM_EV_GRP_OFFSET 1
net/mptcp/pm_userspace.c +18 -0
@@ -157,6 +157,24 @@ int mptcp_userspace_pm_get_local_id(strureturn mptcp_userspace_pm_append_new_local_addr (msk, &new_entry, true); } +bool mptcp_userspace_pm_is_backup (struct mptcp_sock *msk, +struct mptcp_addr_info *skc) +{ +struct mptcp_pm_addr_entry *entry; +bool backup = false; + +spin_lock_bh (&msk->pm.lock); +list_for_each_entry (entry, &msk->pm.userspace_pm_local_addr_list, list) { +if (mptcp_addresses_equal (&entry->addr, skc, false)) { + backup = !!(entry->flags &MPTCP_PM_ADDR_FLAG_BACKUP ); +break ; + } + } +spin_unlock_bh (&msk->pm.lock); + +return backup; +} +int mptcp_nl_cmd_announce (struct sk_buff *skb,struct genl_info *info) {struct nlattr *token = info->attrs[MPTCP_PM_ATTR_TOKEN ];
net/mptcp/protocol.h +3 -0
@@ -1032,6 +1032,9 @@ bool mptcp_pm_rm_addr_signal(struct mptcint mptcp_pm_get_local_id (struct mptcp_sock *msk,struct sock_common *skc);int mptcp_pm_nl_get_local_id (struct mptcp_sock *msk,struct mptcp_addr_info *skc);int mptcp_userspace_pm_get_local_id (struct mptcp_sock *msk,struct mptcp_addr_info *skc); +bool mptcp_pm_is_backup (struct mptcp_sock *msk,struct sock_common *skc); +bool mptcp_pm_nl_is_backup (struct mptcp_sock *msk,struct mptcp_addr_info *skc); +bool mptcp_userspace_pm_is_backup (struct mptcp_sock *msk,struct mptcp_addr_info *skc);static inline u8 subflow_get_local_id (const struct mptcp_subflow_context *subflow) {
net/mptcp/subflow.c +3 -0
@@ -100,6 +100,7 @@ static struct mptcp_sock *subflow_token_return NULL ; } subflow_req->local_id = local_id; + subflow_req->request_bkup =mptcp_pm_is_backup (msk, (struct sock_common *)req);return msk; }
@@ -601,6 +602,8 @@ static int subflow_chk_local_id(struct sreturn err;subflow_set_local_id (subflow, err); + subflow->request_bkup =mptcp_pm_is_backup (msk, (struct sock_common *)sk); +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 169/189 selftests: mptcp: fix error path
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paolo Abeni <[email protected]>
commit 4a2f48992ddf4b8c2fba846c6754089edae6db5a upstream.
pm_nl_check_endpoint() currently calls an not existing helper to mark the test as failed. Fix the wrong call.
[ Conflicts in mptcp_join.sh because the context has changed in commit
571d79664a4a ("selftests: mptcp: join: update endpoint ops") which is not in this version. This commit is unrelated to this modification. ]
--- tools/testing/selftests/net/mptcp/mptcp_join.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/testing/selftests/net/mptcp/mptcp_join.sh +1 -1
@@ -812,7 +812,7 @@ pm_nl_check_endpoint() done if [ -z "$id" ]; then - test_fail "bad test - missing endpoint id" + fail_test "bad test - missing endpoint id" return fi
Greg Kroah-Hartman
maintainerPATCH 170/189 mptcp: pm: deny endp with signal + subflow + port
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthieu Baerts (NGI0) <[email protected]>
commit 8af1f11865f259c882cce71d32f85ee9004e2660 upstream.
As mentioned in the 'Fixes' commit, the port flag is only supported by the 'signal' flag, and not by the 'subflow' one. Then if both the 'signal' and 'subflow' flags are set, the problem is the same: the feature cannot work with the 'subflow' flag.
Technically, if both the 'signal' and 'subflow' flags are set, it will be possible to create the listening socket, but not to establish a subflow using this source port. So better to explicitly deny it, not to create some confusions because the expected behaviour is not possible.
--- net/mptcp/pm_netlink.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/mptcp/pm_netlink.c +2 -2
@@ -1359,8 +1359,8 @@ static int mptcp_nl_cmd_add_addr(structif (ret <0 )return ret; -if (addr.addr.port && !(addr.flags &MPTCP_PM_ADDR_FLAG_SIGNAL )) { -GENL_SET_ERR_MSG (info,"flags must have signal when using port" ); +if (addr.addr.port && !address_use_port (&addr)) { +GENL_SET_ERR_MSG (info,"flags must have signal and not subflow when using port" );return -EINVAL ; }
Greg Kroah-Hartman
maintainerPATCH 171/189 block: use the right type for stub rq_integrity_vec()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jens Axboe <[email protected]>
commit 69b6517687a4b1fb250bd8c9c193a0a304c8ba17 upstream.
For !CONFIG_BLK_DEV_INTEGRITY, rq_integrity_vec() wasn't updated properly. Fix it up.
--- include/linux/blk-integrity.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/blk-integrity.h +1 -1
@@ -175,7 +175,7 @@ static inline int blk_integrity_rq(strucreturn 0 ; } -static inline struct bio_vec *rq_integrity_vec (struct request *rq) +static inline struct bio_vec rq_integrity_vec (struct request *rq) {/* the optimizer will remove all calls to this function */ return (struct bio_vec ){ };
Greg Kroah-Hartman
maintainerPATCH 172/189 Revert "drm/amd/display: Add NULL check for afb before dereferencing in amdgpu_dm_plane_handle_cursor_update"
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ivan Lipski <[email protected]>
commit 778e3979c5dc9cbdb5d1b92afed427de6bc483b4 upstream.
[WHY]
This patch is a dupplicate implementation of 14bcf29b, which we are reverting due to a regression with kms_plane_cursor IGT tests.
This reverts commit 38e6f715b02b572f74677eb2f29d3b4bc6f1ddff.
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c +4 -12
@@ -1225,22 +1225,14 @@ void amdgpu_dm_plane_handle_cursor_updat {struct amdgpu_device *adev =drm_to_adev (plane->dev);struct amdgpu_framebuffer *afb =to_amdgpu_framebuffer (plane->state->fb); -struct drm_crtc *crtc; -struct dm_crtc_state *crtc_state; -struct amdgpu_crtc *amdgpu_crtc; -u64 address; +struct drm_crtc *crtc = afb ? plane->state->crtc : old_plane_state->crtc; +struct dm_crtc_state *crtc_state = crtc ?to_dm_crtc_state (crtc->state) :NULL ; +struct amdgpu_crtc *amdgpu_crtc =to_amdgpu_crtc (crtc); +uint64_t address = afb ? afb->address :0 ;struct dc_cursor_position position = {0 };struct dc_cursor_attributes attributes;int ret; -if (!afb) -return ; - - crtc = plane->state->crtc ? plane->state->crtc : old_plane_state->crtc; - crtc_state = crtc ?to_dm_crtc_state (crtc->state) :NULL ; - amdgpu_crtc =to_amdgpu_crtc (crtc); - address = afb->address; -if (!plane->state->fb && !old_plane_state->fb)return ;
Greg Kroah-Hartman
maintainerPATCH 173/189 mm: huge_memory: dont force huge page alignment on 32 bit
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Shi <[email protected]>
commit 4ef9ad19e17676b9ef071309bc62020e2373705d upstream.
commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") caused two issues [1] [2] reported on 32 bit system or compat userspace.
It doesn't make too much sense to force huge page alignment on 32 bit system due to the constrained virtual address space.
[1] https://lore.kernel.org/linux-mm/[email protected]/
[2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/
--- mm/huge_memory.c | 4 ++++ 1 file changed, 4 insertions(+)
mm/huge_memory.c +4 -0
@@ -37,6 +37,7 @@#include <linux/page_owner.h> #include <linux/sched/sysctl.h> #include <linux/memory-tiers.h> +#include <linux/compat.h> #include <asm/tlb.h> #include <asm/pgalloc.h>
@@ -601,6 +602,9 @@ static unsigned long __thp_get_unmapped_loff_t off_align =round_up (off, size);unsigned long len_pad, ret; +if (IS_ENABLED (CONFIG_32BIT ) ||in_compat_syscall ()) +return 0 ; +if (off_end <= off_align || (off_end - off_align) < size)return 0 ;
Greg Kroah-Hartman
maintainerPATCH 174/189 mm: huge_memory: use !CONFIG_64BIT to relax huge page alignment on 32 bit machines
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Shi <[email protected]>
commit d9592025000b3cf26c742f3505da7b83aedc26d5 upstream.
Yves-Alexis Perez reported commit 4ef9ad19e176 ("mm: huge_memory: don't force huge page alignment on 32 bit") didn't work for x86_32 [1]. It is because x86_32 uses CONFIG_X86_32 instead of CONFIG_32BIT.
!CONFIG_64BIT should cover all 32 bit machines.
[1] https://lore.kernel.org/linux-mm/CAHbLzkr1LwH3pcTgM+aGQ31ip2bKqiqEQ8=FQB+t2c3dhNKNHA@mail.gmail.com/
--- mm/huge_memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/huge_memory.c +1 -1
@@ -602,7 +602,7 @@ static unsigned long __thp_get_unmapped_loff_t off_align =round_up (off, size);unsigned long len_pad, ret; -if (IS_ENABLED (CONFIG_32BIT ) ||in_compat_syscall ()) +if (!IS_ENABLED (CONFIG_64BIT ) ||in_compat_syscall ())return 0 ;if (off_end <= off_align || (off_end - off_align) < size)
Greg Kroah-Hartman
maintainerPATCH 175/189 btrfs: fix corruption after buffer fault in during direct IO append write
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit 939b656bc8ab203fdbde26ccac22bcb7f0985be5 upstream.
During an append (O_APPEND write flag) direct IO write if the input buffer was not previously faulted in, we can corrupt the file in a way that the final size is unexpected and it includes an unexpected hole.
The problem happens like this:
1) We have an empty file, with size 0, for example;
2) We do an O_APPEND direct IO with a length of 4096 bytes and the input buffer is not currently faulted in;
3) We enter btrfs_direct_write(), lock the inode and call generic_write_checks(), which calls generic_write_checks_count(), and that function sets the iocb position to 0 with the following code:
if (iocb->ki_flags & IOCB_APPEND) iocb->ki_pos = i_size_read(inode);
4) We call btrfs_dio_write() and enter into iomap, which will end up calling btrfs_dio_iomap_begin() and that calls btrfs_get_blocks_direct_write(), where we update the i_size of the inode to 4096 bytes;
5) After btrfs_dio_iomap_begin() returns, iomap will attempt to access the page of the write input buffer (at iomap_dio_bio_iter(), with a call to bio_iov_iter_get_pages()) and fail with -EFAULT, which gets returned to btrfs at btrfs_direct_write() via btrfs_dio_write();
6) At btrfs_direct_write() we get the -EFAULT error, unlock the inode, fault in the write buffer and then goto to the label 'relock';
7) We lock again the inode, do all the necessary checks again and call again generic_write_checks(), which calls generic_write_checks_count() again, and there we set the iocb's position to 4K, which is the current i_size of the inode, with the following code pointed above:
if (iocb->ki_flags & IOCB_APPEND)
iocb->ki_pos = i_size_read(inode);8) Then we go again to btrfs_dio_write() and enter iomap and the write succeeds, but it wrote to the file range [4K, 8K), leaving a hole in the [0, 4K) range and an i_size of 8K, which goes against the expectations of having the data written to the range [0, 4K) and get an i_size of 4K.
Fix this by not unlocking the inode before faulting in the input buffer, in case we get -EFAULT or an incomplete write, and not jumping to the 'relock' label after faulting in the buffer - instead jump to a location immediately before calling iomap, skipping all the write checks and relocking. This solves this problem and it's fine even in case the input buffer is memory mapped to the same file range, since only holding the range locked in the inode's io tree can cause a deadlock, it's safe to keep the inode lock (VFS lock), as was fixed and described in commit 51bd9563b678 ("btrfs: fix deadlock due to page faults during direct IO reads and writes").
A sample reproducer provided by a reporter is the following:
$ cat test.c #ifndef _GNU_SOURCE #define _GNU_SOURCE #endif
#include <fcntl.h>
#include <stdio.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
if (argc < 2) {
fprintf(stderr, "Usage: %s <test file>\n", argv[0]);
return 1;
} int fd = open(argv[1], O_WRONLY | O_CREAT | O_TRUNC | O_DIRECT |
O_APPEND, 0644);
if (fd < 0) {
perror("creating test file");
return 1;
}
char *buf = mmap(NULL, 4096, PROT_READ,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
ssize_t ret = write(fd, buf, 4096);
if (ret < 0) {
perror("pwritev2");
return 1;
}
struct stat stbuf;
ret = fstat(fd, &stbuf);
if (ret < 0) {
perror("stat");
return 1;
}
printf("size: %llu\n", (unsigned long long)stbuf.st_size);
return stbuf.st_size == 4096 ? 0 : 1;}
A test case for fstests will be sent soon.
--- fs/btrfs/ctree.h | 1 + fs/btrfs/file.c | 55 ++++++++++++++++++++++++++++++++++++++++++------------- 2 files changed, 43 insertions(+), 13 deletions(-)
fs/btrfs/ctree.h +1 -0
@@ -445,6 +445,7 @@ struct btrfs_file_private {void *filldir_buf;u64 last_index;struct extent_state *llseek_cached_state; +bool fsync_skip_inode_lock; };static inline u32 BTRFS_LEAF_DATA_SIZE (const struct btrfs_fs_info *info)
fs/btrfs/file.c +42 -13
106 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 176/189 netfilter: nf_tables: prefer nft_chain_validate
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Westphal <[email protected]>
commit cff3bd012a9512ac5ed858d38e6ed65f6391008c upstream.
nft_chain_validate already performs loop detection because a cycle will result in a call stack overflow (ctx->level >= NFT_JUMP_STACK_SIZE).
It also follows maps via ->validate callback in nft_lookup, so there appears no reason to iterate the maps again.
nf_tables_check_loops() and all its helper functions can be removed. This improves ruleset load time significantly, from 23s down to 12s.
This also fixes a crash bug. Old loop detection code can result in unbounded recursion:
BUG: TASK stack guard page was hit at .... Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1
[..]
with a suitable ruleset during validation of register stores.
I can't see any actual reason to attempt to check for this from nft_validate_register_store(), at this point the transaction is still in progress, so we don't have a full picture of the rule graph.
For nf-next it might make sense to either remove it or make this depend on table->validate_state in case we could catch an error earlier (for improved error reporting to userspace).
--- net/netfilter/nf_tables_api.c | 154 +++--------------------------------------- 1 file changed, 13 insertions(+), 141 deletions(-)
net/netfilter/nf_tables_api.c +13 -141
@@ -3743,6 +3743,15 @@ static void nf_tables_rule_release(constnf_tables_rule_destroy (ctx, rule); } +/** nft_chain_validate - loop detection and hook validation +* +* @ctx: context containing call depth and base chain +* @chain: chain to validate +* +* Walk through the rules of the given chain and chase all jumps/gotos +* and set lookups until either the jump limit is hit or all reachable +* chains have been validated. +*/ int nft_chain_validate (const struct nft_ctx *ctx,const struct nft_chain *chain) {struct nft_expr *expr, *last;
@@ -3764,6 +3773,9 @@ int nft_chain_validate(const struct nft_if (!expr->ops->validate)continue ; +/* This may call nft_chain_validate() recursively, +* callers that do so must increment ctx->level. +*/ err = expr->ops->validate (ctx, expr, &data);if (err <0 )return err;
@@ -10621,146 +10633,6 @@ int nft_chain_validate_hooks(const struc }EXPORT_SYMBOL_GPL (nft_chain_validate_hooks); -/* -* Loop detection - walk through the ruleset beginning at the destination chain -* of a new jump until either the source chain is reached (loop) or all -* reachable chains have been traversed. -* -* The loop check is performed whenever a new jump verdict is added to an -* expression or verdict map or a verdict map is bound to a new chain. -*/ - -static int nf_tables_check_loops (const struct nft_ctx *ctx, -const struct nft_chain *chain); - -static int nft_check_loops (const struct nft_ctx *ctx, -const struct nft_set_ext *ext) -{ -const struct nft_data *data; -int ret; - - data =nft_set_ext_data (ext); -switch (data->verdict.code) { -case NFT_JUMP : -case NFT_GOTO : - ret =nf_tables_check_loops (ctx, data->verdict.chain); -break ; -default : - ret =0 ; -break ; - } - -return ret; -} - -static int nf_tables_loop_check_setelem (const struct nft_ctx *ctx, -struct nft_set *set, -const struct nft_set_iter *iter, -struct nft_set_elem *elem) -{ -const struct nft_set_ext *ext =nft_set_elem_ext (set, elem->priv); - -if (nft_set_ext_exists (ext,NFT_SET_EXT_FLAGS ) && - *nft_set_ext_flags (ext) &NFT_SET_ELEM_INTERVAL_END ) -return 0 ; - -return nft_check_loops (ctx, ext); -} - -static int nft_set_catchall_loops (const struct nft_ctx *ctx, -struct nft_set *set) -{ -u8 genmask =nft_genmask_next (ctx->net); -struct nft_set_elem_catchall *catchall; -struct nft_set_ext *ext; -int ret =0 ; - -list_for_each_entry_rcu (catchall, &set->catchall_list, list) { - ext =nft_set_elem_ext (set, catchall->elem); -if (!nft_set_elem_active (ext, genmask)) -continue ; - - ret =nft_check_loops (ctx, ext); -if (ret <0 ) -return ret; - } - -return ret; -} - -static int nf_tables_check_loops (const struct nft_ctx *ctx, -const struct nft_chain *chain) -{ -const struct nft_rule *rule; -const struct nft_expr *expr, *last; -struct nft_set *set; -struct nft_set_binding *binding; -struct nft_set_iter iter; - -if (ctx->chain == chain) -return -ELOOP ; - -if (fatal_signal_pending (current)) -return -EINTR ; - -list_for_each_entry (rule, &chain->rules, list) { -nft_rule_for_each_expr (expr, last, rule) { -struct nft_immediate_expr *priv; -const struct nft_data *data; -int err; - -if (strcmp (expr->ops->type->name,"immediate" )) -continue ; - - priv =nft_expr_priv (expr); -if (priv->dreg !=NFT_REG_VERDICT ) -continue ; - - data = &priv->data; -switch (data->verdict.code) { -case NFT_JUMP : -case NFT_GOTO : - err =nf_tables_check_loops (ctx, - data->verdict.chain); -if (err <0 ) -return err; -break ; -default : -break ; - } - } - } - -list_for_each_entry (set, &ctx->table->sets, list) { -if (!nft_is_active_next (ctx->net, set)) -continue ; -if (!(set->flags &NFT_SET_MAP ) || - set->dtype !=NFT_DATA_VERDICT ) -continue ; - -list_for_each_entry (binding, &set->bindings, list) { -if (!(binding->flags &NFT_SET_MAP ) || - binding->chain != chain) -continue ; - - iter.genmask =nft_genmask_next (ctx->net); - iter.skip =0 ; - iter.count =0 ; - iter.err =0 ; - iter.fn = nf_tables_loop_check_setelem; - - set->ops->walk (ctx, set, &iter); -if (!iter.err) - iter.err =nft_set_catchall_loops (ctx, set); - -if (iter.err <0 ) -return iter.err; - } - } - -return 0 ; -} -/** * nft_parse_u32_check - fetch u32 attribute and check for maximum value *
@@ -10873,7 +10745,7 @@ static int nft_validate_register_store(cif (data !=NULL && (data->verdict.code ==NFT_GOTO || data->verdict.code ==NFT_JUMP )) { - err =nf_tables_check_loops (ctx, data->verdict.chain); + err =nft_chain_validate (ctx, data->verdict.chain);if (err <0 )return err; }
Greg Kroah-Hartman
maintainerPATCH 177/189 ipv6: fix source address selection with route leak
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Dichtel <[email protected]>
commit 252442f2ae317d109ef0b4b39ce0608c09563042 upstream.
By default, an address assigned to the output interface is selected when the source address is not specified. This is problematic when a route, configured in a vrf, uses an interface from another vrf (aka route leak). The original vrf does not own the selected source address.
Let's add a check against the output interface and call the appropriate function to select the source address.
--- include/net/ip6_route.h | 20 ++++++++++++++------ net/ipv6/ip6_output.c | 1 + net/ipv6/route.c | 2 +- 3 files changed, 16 insertions(+), 7 deletions(-)
include/net/ip6_route.h +14 -6
@@ -128,18 +128,26 @@ void rt6_age_exceptions(struct fib6_infostatic inline int ip6_route_get_saddr (struct net *net,struct fib6_info *f6i,const struct in6_addr *daddr, -unsigned int prefs, +unsigned int prefs,int l3mdev_index,struct in6_addr *saddr) { +struct net_device *l3mdev; +struct net_device *dev; +bool same_vrf;int err =0 ; -if (f6i && f6i->fib6_prefsrc.plen) { +rcu_read_lock (); + + l3mdev =dev_get_by_index_rcu (net, l3mdev_index); +if (!f6i || !f6i->fib6_prefsrc.plen || l3mdev) + dev = f6i ?fib6_info_nh_dev (f6i) :NULL ; + same_vrf = !l3mdev ||l3mdev_master_dev_rcu (dev) == l3mdev; +if (f6i && f6i->fib6_prefsrc.plen && same_vrf) *saddr = f6i->fib6_prefsrc.addr; - }else { -struct net_device *dev = f6i ?fib6_info_nh_dev (f6i) :NULL ; +else + err =ipv6_dev_get_saddr (net, same_vrf ? dev : l3mdev, daddr, prefs, saddr); - err =ipv6_dev_get_saddr (net, dev, daddr, prefs, saddr); - } +rcu_read_unlock ();return err; }
net/ipv6/ip6_output.c +1 -0
@@ -1122,6 +1122,7 @@ static int ip6_dst_lookup_tail(struct ne from = rt ?rcu_dereference (rt->from) :NULL ; err =ip6_route_get_saddr (net, from, &fl6->daddr, sk ?inet6_sk (sk)->srcprefs :0 , + fl6->flowi6_l3mdev, &fl6->saddr);rcu_read_unlock ();
net/ipv6/route.c +1 -1
@@ -5678,7 +5678,7 @@ static int rt6_fill_node(struct net *net goto nla_put_failure; }else if (dest) {struct in6_addr saddr_buf; -if (ip6_route_get_saddr (net, rt, dest,0 , &saddr_buf) ==0 && +if (ip6_route_get_saddr (net, rt, dest,0 ,0 , &saddr_buf) ==0 &&nla_put_in6_addr (skb,RTA_PREFSRC , &saddr_buf)) goto nla_put_failure; }
Greg Kroah-Hartman
maintainerPATCH 178/189 tools headers arm64: Sync arm64s cputype.h with the kernel sources
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnaldo Carvalho de Melo <[email protected]>
commit dc6abbbde4b099e936cd5428e196d86a5e119aae upstream.
To get the changes in:
0ce85db6c2141b7f ("arm64: cputype: Add Neoverse-V3 definitions") 02a0a04676fa7796 ("arm64: cputype: Add Cortex-X4 definitions") f4d9d9dcc70b96b5 ("arm64: Add Neoverse-V2 part")
That makes this perf source code to be rebuilt:
CC /tmp/build/perf-tools/util/arm-spe.o
The changes in the above patch add MIDR_NEOVERSE_V[23] and MIDR_NEOVERSE_V1 is used in arm-spe.c, so probably we need to add those and perhaps MIDR_CORTEX_X4 to that array? Or maybe we need to leave this for later when this is all tested on those machines?
static const struct midr_range neoverse_spe[] = {
MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1),
MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N2),
MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V1),
{},
};Mark Rutland recommended about arm-spe.c:
"I would not touch this for now -- someone would have to go audit the TRMs to check that those other cores have the same encoding, and I think it'd be better to do that as a follow-up."
That addresses this perf build warning:
Warning: Kernel ABI header differences:
diff -u tools/arch/arm64/include/asm/cputype.h arch/arm64/include/asm/cputype.h
--- tools/arch/arm64/include/asm/cputype.h | 6 ++++++ 1 file changed, 6 insertions(+)
tools/arch/arm64/include/asm/cputype.h +6 -0
@@ -84,6 +84,9 @@#define ARM_CPU_PART_CORTEX_X2 0xD48#define ARM_CPU_PART_NEOVERSE_N2 0xD49#define ARM_CPU_PART_CORTEX_A78C 0xD4B +#define ARM_CPU_PART_NEOVERSE_V2 0xD4F +#define ARM_CPU_PART_CORTEX_X4 0xD82 +#define ARM_CPU_PART_NEOVERSE_V3 0xD84#define APM_CPU_PART_POTENZA 0x000
@@ -153,6 +156,9 @@#define MIDR_CORTEX_X2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X2)#define MIDR_NEOVERSE_N2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_N2)#define MIDR_CORTEX_A78C MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A78C) +#define MIDR_NEOVERSE_V2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V2) +#define MIDR_CORTEX_X4 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X4) +#define MIDR_NEOVERSE_V3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V3)#define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
Greg Kroah-Hartman
maintainerPATCH 179/189 mm/hugetlb: fix potential race in __update_and_free_hugetlb_folio()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miaohe Lin <[email protected]>
commit 5596d9e8b553dacb0ac34bcf873cbbfb16c3ba3e upstream.
There is a potential race between __update_and_free_hugetlb_folio() and try_memory_failure_hugetlb():
CPU1 CPU2
__update_and_free_hugetlb_folio try_memory_failure_hugetlb
folio_test_hugetlb
-- It's still hugetlb folio.
folio_clear_hugetlb_hwpoison
spin_lock_irq(&hugetlb_lock); __get_huge_page_for_hwpoison folio_set_hugetlb_hwpoison spin_unlock_irq(&hugetlb_lock);
spin_lock_irq(&hugetlb_lock);
__folio_clear_hugetlb(folio);
-- Hugetlb flag is cleared but too late.
spin_unlock_irq(&hugetlb_lock);
When the above race occurs, raw error page info will be leaked. Even worse, raw error pages won't have hwpoisoned flag set and hit pcplists/buddy. Fix this issue by deferring folio_clear_hugetlb_hwpoison() until __folio_clear_hugetlb() is done. So all raw error pages will have hwpoisoned flag set.
--- mm/hugetlb.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
mm/hugetlb.c +7 -7
@@ -1770,13 +1770,6 @@ static void __update_and_free_hugetlb_fo }/* -* Move PageHWPoison flag from head page to the raw error pages, -* which makes any healthy subpages reusable. -*/ -if (unlikely (folio_test_hwpoison (folio))) -folio_clear_hugetlb_hwpoison (folio); - -/* * If vmemmap pages were allocated above, then we need to clear the * hugetlb destructor under the hugetlb lock. */
@@ -1787,6 +1780,13 @@ static void __update_and_free_hugetlb_fo }/* +* Move PageHWPoison flag from head page to the raw error pages, +* which makes any healthy subpages reusable. +*/ +if (unlikely (folio_test_hwpoison (folio))) +folio_clear_hugetlb_hwpoison (folio); + +/* * Non-gigantic pages demoted from CMA allocated gigantic pages * need to be given back to CMA in free_gigantic_folio. */
Greg Kroah-Hartman
maintainerPATCH 180/189 nouveau: set placement to original placement on uvmm validate.
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Airlie <[email protected]>
commit 9c685f61722d30a22d55bb8a48f7a48bb2e19bcc upstream.
When a buffer is evicted for memory pressure or TTM evict all, the placement is set to the eviction domain, this means the buffer never gets revalidated on the next exec to the correct domain.
I think this should be fine to use the initial domain from the object creation, as least with VM_BIND this won't change after init so this should be the correct answer.
--- drivers/gpu/drm/nouveau/nouveau_uvmm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/gpu/drm/nouveau/nouveau_uvmm.c +4 -2
@@ -1320,6 +1320,7 @@ nouveau_uvmm_bind_job_submit(struct nouvdrm_gpuva_for_each_op (va_op, op->ops) {struct drm_gem_object *obj =op_gem_obj (va_op); +struct nouveau_bo *nvbo;if (unlikely (!obj))continue ;
@@ -1330,8 +1331,9 @@ nouveau_uvmm_bind_job_submit(struct nouvif (unlikely (va_op->op ==DRM_GPUVA_OP_UNMAP ))continue ; - ret =nouveau_bo_validate (nouveau_gem_object (obj), - true, false); + nvbo =nouveau_gem_object (obj); +nouveau_bo_placement_set (nvbo, nvbo->valid_domains,0 ); + ret =nouveau_bo_validate (nvbo, true, false);if (ret) { op =list_last_op (&bind_job->ops); goto unwind;
Greg Kroah-Hartman
maintainerPATCH 181/189 xfs: fix log recovery buffer allocation for the legacy h_size fixup
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoph Hellwig <[email protected]>
commit 45cf976008ddef4a9c9a30310c9b4fb2a9a6602a upstream.
Commit a70f9fe52daa ("xfs: detect and handle invalid iclog size set by mkfs") added a fixup for incorrect h_size values used for the initial umount record in old xfsprogs versions. Later commit 0c771b99d6c9 ("xfs: clean up calculation of LR header blocks") cleaned up the log reover buffer calculation, but stoped using the fixed up h_size value to size the log recovery buffer, which can lead to an out of bounds access when the incorrect h_size does not come from the old mkfs tool, but a fuzzer.
Fix this by open coding xlog_logrec_hblks and taking the fixed h_size into account for this calculation.
--- fs/xfs/xfs_log_recover.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-)
fs/xfs/xfs_log_recover.c +14 -6
@@ -2965,7 +2965,7 @@ xlog_do_recovery_pass(int error =0 , h_size, h_len;int error2 =0 ;int bblks, split_bblks; -int hblks, split_hblks, wrapped_hblks; +int hblks =1 , split_hblks, wrapped_hblks;int i;struct hlist_head rhash[XLOG_RHASH_SIZE ];LIST_HEAD (buffer_list);
@@ -3021,14 +3021,22 @@ xlog_do_recovery_pass(if (error) goto bread_err1; - hblks =xlog_logrec_hblks (log, rhead); -if (hblks !=1 ) { -kmem_free (hbp); - hbp =xlog_alloc_buffer (log, hblks); +/* +* This open codes xlog_logrec_hblks so that we can reuse the +* fixed up h_size value calculated above. Without that we'd +* still allocate the buffer based on the incorrect on-disk +* size. +*/ +if (h_size >XLOG_HEADER_CYCLE_SIZE && + (rhead->h_version &cpu_to_be32 (XLOG_VERSION_2 ))) { + hblks =DIV_ROUND_UP (h_size,XLOG_HEADER_CYCLE_SIZE ); +if (hblks >1 ) { +kmem_free (hbp); + hbp =xlog_alloc_buffer (log, hblks); + } } }else {ASSERT (log->l_sectBBsize ==1 ); - hblks =1 ; hbp =xlog_alloc_buffer (log,1 ); h_size =XLOG_BIG_RECORD_BSIZE ; }
Greg Kroah-Hartman
maintainerPATCH 182/189 drm/amd/display: Defer handling mst up request in resume
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wayne Lin <[email protected]>
commit 202dc359addab29451d3d18243c3d957da5392c8 upstream.
[Why]
Like commit ec5fa9fcdeca ("drm/amd/display: Adjust the MST resume flow"), we want to avoid handling mst topology changes before restoring the old state. If we enable DP_UP_REQ_EN before calling drm_atomic_helper_resume(), have changce to handle CSN event first and fire hotplug event before restoring the cached state.
[How]
Disable mst branch sending up request event before we restoring the cached state. DP_UP_REQ_EN will be set later when we call drm_dp_mst_topology_mgr_resume().
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 - 1 file changed, 1 deletion(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +0 -1
@@ -2350,7 +2350,6 @@ static void resume_mst_branch_status(str ret =drm_dp_dpcd_writeb (mgr->aux,DP_MSTM_CTRL ,DP_MST_EN | -DP_UP_REQ_EN |DP_UPSTREAM_IS_SRC );if (ret <0 ) {drm_dbg_kms (mgr->dev,"mst write failed - undocked during suspend?\n" );
Greg Kroah-Hartman
maintainerPATCH 183/189 mptcp: pm: reduce indentation blocks
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Matthieu Baerts (NGI0)" <[email protected]>
commit c95eb32ced823a00be62202b43966b07b2f20b7f upstream.
That will simplify the following commits.
No functional changes intended.
Stable-dep-of: cd7c957f936f ("mptcp: pm: don't try to create sf if alloc failed")
--- net/mptcp/pm_netlink.c | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-)
net/mptcp/pm_netlink.c +11 -8
@@ -575,16 +575,19 @@ static void mptcp_pm_create_subflow_or_sif (msk->pm.addr_signal &BIT (MPTCP_ADD_ADDR_SIGNAL ))return ; -if (local) { -if (mptcp_pm_alloc_anno_list (msk, &local->addr)) { -__clear_bit (local->addr.id, msk->pm.id_avail_bitmap); - msk->pm.add_addr_signaled++; -mptcp_pm_announce_addr (msk, &local->addr, false); -mptcp_pm_nl_addr_send_ack (msk); - } - } +if (!local) + goto subflow; + +if (!mptcp_pm_alloc_anno_list (msk, &local->addr)) + goto subflow; + +__clear_bit (local->addr.id, msk->pm.id_avail_bitmap); + msk->pm.add_addr_signaled++; +mptcp_pm_announce_addr (msk, &local->addr, false); +mptcp_pm_nl_addr_send_ack (msk); } +subflow:/* check if should create a new subflow */ while (msk->pm.local_addr_used < local_addr_max && msk->pm.subflows < subflows_max) {
Greg Kroah-Hartman
maintainerPATCH 184/189 mptcp: pm: dont try to create sf if alloc failed
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Matthieu Baerts (NGI0)" <[email protected]>
commit cd7c957f936f8cb80d03e5152f4013aae65bd986 upstream.
It sounds better to avoid wasting cycles and / or put extreme memory pressure on the system by trying to create new subflows if it was not possible to add a new item in the announce list.
While at it, a warning is now printed if the entry was already in the list as it should not happen with the in-kernel path-manager. With this PM, mptcp_pm_alloc_anno_list() should only fail in case of memory pressure.
--- net/mptcp/pm_netlink.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
net/mptcp/pm_netlink.c +6 -4
@@ -353,7 +353,7 @@ bool mptcp_pm_alloc_anno_list(struct mpt add_entry =mptcp_lookup_anno_list_by_saddr (msk, addr);if (add_entry) { -if (mptcp_pm_is_kernel (msk)) +if (WARN_ON_ONCE (mptcp_pm_is_kernel (msk)))return false; sk_reset_timer(sk, &add_entry->add_timer,
@@ -563,8 +563,6 @@ static void mptcp_pm_create_subflow_or_s/* check first for announce */ if (msk->pm.add_addr_signaled < add_addr_signal_max) { - local =select_signal_address (pernet, msk); -/* due to racing events on both ends we can reach here while * previous add address is still running: if we invoke now * mptcp_pm_announce_addr(), that will fail and the
@@ -575,11 +573,15 @@ static void mptcp_pm_create_subflow_or_sif (msk->pm.addr_signal &BIT (MPTCP_ADD_ADDR_SIGNAL ))return ; + local =select_signal_address (pernet, msk);if (!local) goto subflow; +/* If the alloc fails, we are on memory pressure, not worth +* continuing, and trying to create subflows. +*/ if (!mptcp_pm_alloc_anno_list (msk, &local->addr)) - goto subflow; +return ;__clear_bit (local->addr.id, msk->pm.id_avail_bitmap); msk->pm.add_addr_signaled++;
Greg Kroah-Hartman
maintainerPATCH 185/189 mptcp: pm: do not ignore subflow if signal flag is also set
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Matthieu Baerts (NGI0)" <[email protected]>
commit 85df533a787bf07bf4367ce2a02b822ff1fba1a3 upstream.
Up to the 'Fixes' commit, having an endpoint with both the 'signal' and 'subflow' flags, resulted in the creation of a subflow and an address announcement using the address linked to this endpoint. After this commit, only the address announcement was done, ignoring the 'subflow' flag.
That's because the same bitmap is used for the two flags. It is OK to keep this single bitmap, the already selected local endpoint simply have to be re-used, but not via select_local_address() not to look at the just modified bitmap.
Note that it is unusual to set the two flags together: creating a new subflow using a new local address will implicitly advertise it to the other peer. So in theory, no need to advertise it explicitly as well. Maybe there are use-cases -- the subflow might not reach the other peer that way, we can ask the other peer to try initiating the new subflow without delay -- or very likely the user is confused, and put both flags "just to be sure at least the right one is set". Still, if it is allowed, the kernel should do what has been asked: using this endpoint to announce the address and to create a new subflow from it.
An alternative is to forbid the use of the two flags together, but that's probably too late, there are maybe use-cases, and it was working before. This patch will avoid people complaining subflows are not created using the endpoint they added with the 'subflow' and 'signal' flag.
Note that with the current patch, the subflow might not be created in some corner cases, e.g. if the 'subflows' limit was reached when sending the ADD_ADDR, but changed later on. It is probably not worth splitting id_avail_bitmap per target ('signal', 'subflow'), which will add another large field to the msk "just" to track (again) endpoints. Anyway, currently when the limits are changed, the kernel doesn't check if new subflows can be created or removed, because we would need to keep track of the received ADD_ADDR, and more. It sounds OK to assume that the limits should be properly configured before establishing new connections.
--- net/mptcp/pm_netlink.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-)
net/mptcp/pm_netlink.c +12 -4
@@ -520,8 +520,8 @@ __lookup_addr(struct pm_nl_pernet *pernestatic void mptcp_pm_create_subflow_or_signal_addr (struct mptcp_sock *msk) { +struct mptcp_pm_addr_entry *local, *signal_and_subflow =NULL ;struct sock *sk = (struct sock *)msk; -struct mptcp_pm_addr_entry *local;unsigned int add_addr_signal_max;unsigned int local_addr_max;struct pm_nl_pernet *pernet;
@@ -587,6 +587,9 @@ static void mptcp_pm_create_subflow_or_s msk->pm.add_addr_signaled++;mptcp_pm_announce_addr (msk, &local->addr, false);mptcp_pm_nl_addr_send_ack (msk); + +if (local->flags &MPTCP_PM_ADDR_FLAG_SUBFLOW ) + signal_and_subflow = local; } subflow:
@@ -597,9 +600,14 @@ subflow:bool fullmesh;int i, nr; - local =select_local_address (pernet, msk); -if (!local) -break ; +if (signal_and_subflow) { + local = signal_and_subflow; + signal_and_subflow =NULL ; + }else { + local =select_local_address (pernet, msk); +if (!local) +break ; + } fullmesh = !!(local->flags &MPTCP_PM_ADDR_FLAG_FULLMESH );
Greg Kroah-Hartman
maintainerPATCH 186/189 selftests: mptcp: join: ability to invert ADD_ADDR check
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Matthieu Baerts (NGI0)" <[email protected]>
commit bec1f3b119ebc613d08dfbcdbaef01a79aa7de92 upstream.
In the following commit, the client will initiate the ADD_ADDR, instead of the server. We need to way to verify the ADD_ADDR have been correctly sent.
Note: the default expected counters for when the port number is given are never changed by the caller, no need to accept them as parameter then.
The 'Fixes' tag here below is the same as the one from the previous
commit: this patch here is not fixing anything wrong in the selftests, but it validates the previous fix for an issue introduced by this commit ID.
--- tools/testing/selftests/net/mptcp/mptcp_join.sh | 40 +++++++++++++++--------- 1 file changed, 26 insertions(+), 14 deletions(-)
tools/testing/selftests/net/mptcp/mptcp_join.sh +26 -14
@@ -1559,18 +1559,28 @@ chk_add_nr() local add_nr=$1 local echo_nr=$2 local port_nr=${3:-0} - local syn_nr=${4:-$port_nr} - local syn_ack_nr=${5:-$port_nr} - local ack_nr=${6:-$port_nr} - local mis_syn_nr=${7:-0} - local mis_ack_nr=${8:-0} + local ns_invert=${4:-""} + local syn_nr=$port_nr + local syn_ack_nr=$port_nr + local ack_nr=$port_nr + local mis_syn_nr=0 + local mis_ack_nr=0 + local ns_tx=$ns1 + local ns_rx=$ns2 + local extra_msg="" local count local timeout - timeout=$(ip netns exec $ns1 sysctl -n net.mptcp.add_addr_timeout) + if [[ $ns_invert = "invert" ]]; then + ns_tx=$ns2 + ns_rx=$ns1 + extra_msg="invert" + fi + + timeout=$(ip netns exec ${ns_tx} sysctl -n net.mptcp.add_addr_timeout) print_check "add" - count=$(mptcp_lib_get_counter ${ns2} "MPTcpExtAddAddr") + count=$(mptcp_lib_get_counter ${ns_rx} "MPTcpExtAddAddr") if [ -z "$count" ]; then print_skip # if the test configured a short timeout tolerate greater then expected
@@ -1582,7 +1592,7 @@ chk_add_nr() fi print_check "echo" - count=$(mptcp_lib_get_counter ${ns1} "MPTcpExtEchoAdd") + count=$(mptcp_lib_get_counter ${ns_tx} "MPTcpExtEchoAdd") if [ -z "$count" ]; then print_skip elif [ "$count" != "$echo_nr" ]; then
@@ -1593,7 +1603,7 @@ chk_add_nr() if [ $port_nr -gt 0 ]; then print_check "pt" - count=$(mptcp_lib_get_counter ${ns2} "MPTcpExtPortAdd") + count=$(mptcp_lib_get_counter ${ns_rx} "MPTcpExtPortAdd") if [ -z "$count" ]; then print_skip elif [ "$count" != "$port_nr" ]; then
@@ -1603,7 +1613,7 @@ chk_add_nr() fi print_check "syn" - count=$(mptcp_lib_get_counter ${ns1} "MPTcpExtMPJoinPortSynRx") + count=$(mptcp_lib_get_counter ${ns_tx} "MPTcpExtMPJoinPortSynRx") if [ -z "$count" ]; then print_skip elif [ "$count" != "$syn_nr" ]; then
@@ -1614,7 +1624,7 @@ chk_add_nr() fi print_check "synack" - count=$(mptcp_lib_get_counter ${ns2} "MPTcpExtMPJoinPortSynAckRx") + count=$(mptcp_lib_get_counter ${ns_rx} "MPTcpExtMPJoinPortSynAckRx") if [ -z "$count" ]; then print_skip elif [ "$count" != "$syn_ack_nr" ]; then
@@ -1625,7 +1635,7 @@ chk_add_nr() fi print_check "ack" - count=$(mptcp_lib_get_counter ${ns1} "MPTcpExtMPJoinPortAckRx") + count=$(mptcp_lib_get_counter ${ns_tx} "MPTcpExtMPJoinPortAckRx") if [ -z "$count" ]; then print_skip elif [ "$count" != "$ack_nr" ]; then
@@ -1636,7 +1646,7 @@ chk_add_nr() fi print_check "syn" - count=$(mptcp_lib_get_counter ${ns1} "MPTcpExtMismatchPortSynRx") + count=$(mptcp_lib_get_counter ${ns_tx} "MPTcpExtMismatchPortSynRx") if [ -z "$count" ]; then print_skip elif [ "$count" != "$mis_syn_nr" ]; then
@@ -1647,7 +1657,7 @@ chk_add_nr() fi print_check "ack" - count=$(mptcp_lib_get_counter ${ns1} "MPTcpExtMismatchPortAckRx") + count=$(mptcp_lib_get_counter ${ns_tx} "MPTcpExtMismatchPortAckRx") if [ -z "$count" ]; then print_skip elif [ "$count" != "$mis_ack_nr" ]; then
@@ -1657,6 +1667,8 @@ chk_add_nr() print_ok fi fi + + print_info "$extra_msg" } chk_add_tx_nr()
Greg Kroah-Hartman
maintainerPATCH 187/189 selftests: mptcp: join: test both signal & subflow
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Matthieu Baerts (NGI0)" <[email protected]>
commit 4d2868b5d191c74262f7407972d68d1bf3245d6a upstream.
It should be quite uncommon to set both the subflow and the signal
flags: the initiator of the connection is typically the one creating new subflows, not the other peer, then no need to announce additional local addresses, and use it to create subflows.
But some people might be confused about the flags, and set both "just to be sure at least the right one is set". To verify the previous fix, and avoid future regressions, this specific case is now validated: the client announces a new address, and initiates a new subflow from the same address.
While working on this, another bug has been noticed, where the client reset the new subflow because an ADD_ADDR echo got received as the 3rd
ACK: this new test also explicitly checks that no RST have been sent by the client and server.
The 'Fixes' tag here below is the same as the one from the previous
commit: this patch here is not fixing anything wrong in the selftests, but it validates the previous fix for an issue introduced by this commit ID.
--- tools/testing/selftests/net/mptcp/mptcp_join.sh | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
tools/testing/selftests/net/mptcp/mptcp_join.sh +15 -0
@@ -2133,6 +2133,21 @@ signal_address_tests() chk_add_nr 1 1 fi + # uncommon: subflow and signal flags on the same endpoint + # or because the user wrongly picked both, but still expects the client + # to create additional subflows + if reset "subflow and signal together"; then + pm_nl_set_limits $ns1 0 2 + pm_nl_set_limits $ns2 0 2 + pm_nl_add_endpoint $ns2 10.0.3.2 flags signal,subflow + run_tests $ns1 $ns2 10.0.1.1 + chk_join_nr 1 1 1 + chk_add_nr 1 1 0 invert # only initiated by ns2 + chk_add_nr 0 0 0 # none initiated by ns1 + chk_rst_nr 0 0 invert # no RST sent by the client + chk_rst_nr 0 0 # no RST sent by the server + fi + # accept and use add_addr with additional subflows if reset "multiple subflows and signal"; then pm_nl_set_limits $ns1 0 3
Greg Kroah-Hartman
maintainerPATCH 188/189 Revert "selftests: mptcp: simult flows: mark unbalanced tests as flaky"
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Matthieu Baerts (NGI0)" <[email protected]>
This reverts commit 052c9f0c140c78e5d6826688b5d2f33e19db0ae7.
If the test doesn't pass, we can get this error:
# ./simult_flows.sh: line 275: mptcp_lib_subtest_is_flaky: command not found
This patch is not needed in v6.6: it is there to mark a test as "flaky", but the MPTCP selftests infrastructure in v6.6 doesn't support them. So it looks better to revert this patch.
--- tools/testing/selftests/net/mptcp/simult_flows.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
tools/testing/selftests/net/mptcp/simult_flows.sh +3 -3
@@ -262,7 +262,7 @@ run_test() do_transfer $small $large $time lret=$? mptcp_lib_result_code "${lret}" "${msg}" - if [ $lret -ne 0 ] && ! mptcp_lib_subtest_is_flaky; then + if [ $lret -ne 0 ]; then ret=$lret [ $bail -eq 0 ] || exit $ret fi
@@ -272,7 +272,7 @@ run_test() do_transfer $large $small $time lret=$? mptcp_lib_result_code "${lret}" "${msg}" - if [ $lret -ne 0 ] && ! mptcp_lib_subtest_is_flaky; then + if [ $lret -ne 0 ]; then ret=$lret [ $bail -eq 0 ] || exit $ret fi
@@ -305,7 +305,7 @@ run_test 10 10 0 0 "balanced bwidth" run_test 10 10 1 25 "balanced bwidth with unbalanced delay" # we still need some additional infrastructure to pass the following test-cases -MPTCP_LIB_SUBTEST_FLAKY=1 run_test 10 3 0 0 "unbalanced bwidth" +run_test 10 3 0 0 "unbalanced bwidth" run_test 10 3 1 25 "unbalanced bwidth with unbalanced delay" run_test 10 3 25 1 "unbalanced bwidth with opposed, unbalanced delay"
Greg Kroah-Hartman
maintainerPATCH 189/189 btrfs: fix double inode unlock for direct IO sync writes
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit e0391e92f9ab4fb3dbdeb139c967dcfa7ac4b115 upstream.
If we do a direct IO sync write, at btrfs_sync_file(), and we need to skip inode logging or we get an error starting a transaction or an error when flushing delalloc, we end up unlocking the inode when we shouldn't under the 'out_release_extents' label, and then unlock it again at btrfs_direct_write().
Fix that by checking if we have to skip inode unlocking under that label.
--- fs/btrfs/file.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
fs/btrfs/file.c +4 -1
@@ -2038,7 +2038,10 @@ out: out_release_extents:btrfs_release_log_ctx_extents (&ctx); -btrfs_inode_unlock (BTRFS_I (inode),BTRFS_ILOCK_MMAP ); +if (skip_ilock) +up_write (&BTRFS_I (inode)->i_mmap_lock); +else +btrfs_inode_unlock (BTRFS_I (inode),BTRFS_ILOCK_MMAP ); goto out; }
Hello,
This rc kernel passed ChromeOS CQ tests:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/5782321/1?tab=checks
Thanks,
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.46 release. There are 189 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 Wed, 14 Aug 2024 16:00:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.46-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.6.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.
## Build
* kernel: 6.6.46-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: a67ef85bc6ceebaf7fd3d7159f070b823d1dfdae
* git describe: v6.6.45-190-ga67ef85bc6ce
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.45-190-ga67ef85bc6ce
## Test Regressions (compared to v6.6.44-122-g272b28faf61f)
## Metric Regressions (compared to v6.6.44-122-g272b28faf61f)
## Test Fixes (compared to v6.6.44-122-g272b28faf61f)
## Metric Fixes (compared to v6.6.44-122-g272b28faf61f)
## Test result summary
total: 188519, pass: 163267, fail: 2264, skip: 22632, xfail: 356
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 129 total, 129 passed, 0 failed
* arm64: 38 total, 38 passed, 0 failed
* i386: 28 total, 28 passed, 0 failed
* mips: 26 total, 25 passed, 1 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 36 total, 35 passed, 1 failed
* riscv: 19 total, 19 passed, 0 failed
* s390: 14 total, 13 passed, 1 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 7 total, 7 passed, 0 failed
* x86_64: 33 total, 33 passed, 0 failed
## Test suites summary
* boot
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* 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-kcmp
* kselftest-kvm
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-mincore
* kselftest-mqueue
* kselftest-net
* kselftest-net-mptcp
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-watchdog
* kselftest-x86
* 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
Am 12.08.2024 um 18:00 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.6.46 release. There are 189 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 on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
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&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
Hi Greg
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.46 release. There are 189 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 Wed, 14 Aug 2024 16:00:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.46-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.6.y
and the diffstat can be found below.thanks,
greg k-h
6.6.46-rc1 tested.
Build successfully completed.
Boot successfully completed.
No dmesg regressions.
Video output normal.
Sound output normal.
Lenovo ThinkPad X1 Carbon Gen10(Intel i7-1260P(x86_64) arch linux)
[ 0.000000] Linux version 6.6.46-rc1rv
(takeshi@ThinkPadX1Gen10J0764) (gcc (GCC) 14.2.1 20240805, GNU ld (GNU Binutils) 2.43.0) #1 SMP PREEMPT_DYNAMIC Tue Aug 13 18:50:55 JST 2024
Thanks
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.46 release. There are 189 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.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.46 release. There are 189 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 Wed, 14 Aug 2024 16:00:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.46-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.6.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.46 release. There are 189 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 Wed, 14 Aug 2024 16:00:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.46-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.6.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.6:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
116 tests: 116 pass, 0 failLinux version: 6.6.46-rc1-ga67ef85bc6ce
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-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.46 release. There are 189 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 Wed, 14 Aug 2024 16:00:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.46-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.6.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 9 lines
This is the start of the stable review cycle for the 6.6.46 release. There are 189 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 Wed, 14 Aug 2024 16:00:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.46-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.6.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my x86_64 and ARM64 test systems. No errors or regressions.
Thanks.