6.9.11-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 158/163 wifi: cfg80211: wext: set ssids=NULL for passive scans
In reply to Greg Kroah-Hartman6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <[email protected]>
commit 0941772342d59e48733131ac3a202fa1a4d832e9 upstream.
In nl80211, we always set the ssids of a scan request to NULL when n_ssids==0 (passive scan). Drivers have relied on this behaviour in the past, so we fixed it in 6 GHz scan requests as well, and added a warning so we'd have assurance the API would always be called that way.
syzbot found that wext doesn't ensure that, so we reach the check and trigger the warning. Fix the wext code to set the ssids pointer to NULL when there are none.
--- net/wireless/scan.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
net/wireless/scan.c +3 -1
@@ -3492,8 +3492,10 @@ int cfg80211_wext_siwscan(struct net_devmemcpy (creq->ssids[0 ].ssid, wreq->essid, wreq->essid_len); creq->ssids[0 ].ssid_len = wreq->essid_len; } -if (wreq->scan_type ==IW_SCAN_TYPE_PASSIVE ) +if (wreq->scan_type ==IW_SCAN_TYPE_PASSIVE ) { + creq->ssids =NULL ; creq->n_ssids =0 ; + } }for (i =0 ; i <NUM_NL80211_BANDS ; i++)
Greg Kroah-Hartman
maintainerPATCH 159/163 wifi: mac80211: disable softirqs for queued frame handling
In reply to Greg Kroah-Hartman6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <[email protected]>
commit 321028bc45f01edb9e57b0ae5c11c5c3600d00ca upstream.
As noticed by syzbot, calling ieee80211_handle_queued_frames() (and actually handling frames there) requires softirqs to be disabled, since we call into the RX code. Fix that in the case of cleaning up frames left over during shutdown.
--- net/mac80211/main.c | 1 + net/mac80211/util.c | 2 ++ 2 files changed, 3 insertions(+)
net/mac80211/main.c +1 -0
@@ -423,6 +423,7 @@ u64 ieee80211_reset_erp_info(struct ieeeBSS_CHANGED_ERP_SLOT ; } +/* context: requires softirqs disabled */ void ieee80211_handle_queued_frames (struct ieee80211_local *local) {struct sk_buff *skb;
net/mac80211/util.c +2 -0
@@ -1567,7 +1567,9 @@ u32 ieee80211_sta_get_rates(struct ieee8void ieee80211_stop_device (struct ieee80211_local *local) { +local_bh_disable ();ieee80211_handle_queued_frames (local); +local_bh_enable ();ieee80211_led_radio (local, false);ieee80211_mod_tpt_led_trig (local,0 ,IEEE80211_TPT_LEDTRIG_FL_RADIO );
Greg Kroah-Hartman
maintainerPATCH 160/163 wifi: iwlwifi: mvm: dont wake up rx_sync_waitq upon RFKILL
In reply to Greg Kroah-Hartman6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Emmanuel Grumbach <[email protected]>
commit e715c9302b1c6fae990b9898a80fac855549d1f0 upstream.
Since we now want to sync the queues even when we're in RFKILL, we shouldn't wake up the wait queue since we still expect to get all the notifications from the firmware.
--- drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 6 ++---- drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 6 ++---- 2 files changed, 4 insertions(+), 8 deletions(-)
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c +2 -4
@@ -6189,11 +6189,9 @@ void iwl_mvm_sync_rx_queues_internal(strif (sync) {lockdep_assert_held (&mvm->mutex); ret =wait_event_timeout (mvm->rx_sync_waitq, -READ_ONCE (mvm->queue_sync_state) ==0 || -iwl_mvm_is_radio_hw_killed (mvm), +READ_ONCE (mvm->queue_sync_state) ==0 ,SYNC_RX_QUEUE_TIMEOUT ); -WARN_ONCE (!ret && !iwl_mvm_is_radio_hw_killed (mvm), -"queue sync: failed to sync, state is 0x%lx, cookie %d\n" , +WARN_ONCE (!ret,"queue sync: failed to sync, state is 0x%lx, cookie %d\n" , mvm->queue_sync_state, mvm->queue_sync_cookie); }
drivers/net/wireless/intel/iwlwifi/mvm/ops.c +2 -4
@@ -1854,12 +1854,10 @@ static bool iwl_mvm_set_hw_rfkill_state(bool rfkill_safe_init_done =READ_ONCE (mvm->rfkill_safe_init_done);bool unified =iwl_mvm_has_unified_ucode (mvm); -if (state) { +if (state)set_bit (IWL_MVM_STATUS_HW_RFKILL , &mvm->status); -wake_up (&mvm->rx_sync_waitq); - }else { +else clear_bit (IWL_MVM_STATUS_HW_RFKILL , &mvm->status); - }iwl_mvm_set_rfkill_state (mvm);
Greg Kroah-Hartman
maintainerPATCH 161/163 netfs, fscache: export fscache_put_volume() and add fscache_try_get_volume()
In reply to Greg Kroah-Hartman6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Baokun Li <[email protected]>
[ Upstream commit 85b08b31a22b481ec6528130daf94eee4452e23f ]
Export fscache_put_volume() and add fscache_try_get_volume() helper function to allow cachefiles to get/put fscache_volume via linux/fscache-cache.h.
Stable-dep-of: 522018a0de6b ("cachefiles: fix slab-use-after-free in fscache_withdraw_volume()")
Stable-dep-of: 5d8f80578907 ("cachefiles: fix slab-use-after-free in cachefiles_withdraw_cookie()")
--- fs/netfs/fscache_volume.c | 14 ++++++++++++++ fs/netfs/internal.h | 2 -- include/linux/fscache-cache.h | 6 ++++++ 3 files changed, 20 insertions(+), 2 deletions(-)
fs/netfs/fscache_volume.c +14 -0
@@ -27,6 +27,19 @@ struct fscache_volume *fscache_get_volumreturn volume; } +struct fscache_volume *fscache_try_get_volume (struct fscache_volume *volume, +enum fscache_volume_trace where) +{ +int ref; + +if (!__refcount_inc_not_zero (&volume->ref, &ref)) +return NULL ; + +trace_fscache_volume (volume->debug_id, ref +1 , where); +return volume; +} +EXPORT_SYMBOL (fscache_try_get_volume); +static void fscache_see_volume (struct fscache_volume *volume,enum fscache_volume_trace where) {
@@ -420,6 +433,7 @@ void fscache_put_volume(struct fscache_vfscache_free_volume (volume); } } +EXPORT_SYMBOL (fscache_put_volume);/* * Relinquish a volume representation cookie.
fs/netfs/internal.h +0 -2
@@ -326,8 +326,6 @@ extern const struct seq_operations fscacstruct fscache_volume *fscache_get_volume (struct fscache_volume *volume,enum fscache_volume_trace where); -void fscache_put_volume (struct fscache_volume *volume, -enum fscache_volume_trace where);bool fscache_begin_volume_access (struct fscache_volume *volume,struct fscache_cookie *cookie,enum fscache_access_trace why);
include/linux/fscache-cache.h +6 -0
@@ -19,6 +19,7 @@enum fscache_cache_trace ;enum fscache_cookie_trace ;enum fscache_access_trace ; +enum fscache_volume_trace ;enum fscache_cache_state {FSCACHE_CACHE_IS_NOT_PRESENT ,/* No cache is present for this name */
@@ -97,6 +98,11 @@ extern void fscache_withdraw_cookie(struextern void fscache_io_error (struct fscache_cache *cache); +extern struct fscache_volume * +fscache_try_get_volume (struct fscache_volume *volume, +enum fscache_volume_trace where); +extern void fscache_put_volume (struct fscache_volume *volume, +enum fscache_volume_trace where);extern void fscache_end_volume_access (struct fscache_volume *volume,struct fscache_cookie *cookie,enum fscache_access_trace why);
Greg Kroah-Hartman
maintainerPATCH 162/163 cachefiles: fix slab-use-after-free in fscache_withdraw_volume()
In reply to Greg Kroah-Hartman6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Baokun Li <[email protected]>
[ Upstream commit 522018a0de6b6fcce60c04f86dfc5f0e4b6a1b36 ]
We got the following issue in our fault injection stress test:
==================================================================
BUG: KASAN: slab-use-after-free in fscache_withdraw_volume+0x2e1/0x370 Read of size 4 at addr ffff88810680be08 by task ondemand-04-dae/5798 CPU: 0 PID: 5798 Comm: ondemand-04-dae Not tainted 6.8.0-dirty #565 Call Trace: kasan_check_range+0xf6/0x1b0 fscache_withdraw_volume+0x2e1/0x370 cachefiles_withdraw_volume+0x31/0x50 cachefiles_withdraw_cache+0x3ad/0x900 cachefiles_put_unbind_pincount+0x1f6/0x250 cachefiles_daemon_release+0x13b/0x290 __fput+0x204/0xa00 task_work_run+0x139/0x230 Allocated by task 5820: __kmalloc+0x1df/0x4b0 fscache_alloc_volume+0x70/0x600 __fscache_acquire_volume+0x1c/0x610 erofs_fscache_register_volume+0x96/0x1a0 erofs_fscache_register_fs+0x49a/0x690 erofs_fc_fill_super+0x6c0/0xcc0 vfs_get_super+0xa9/0x140 vfs_get_tree+0x8e/0x300 do_new_mount+0x28c/0x580 [...] Freed by task 5820: kfree+0xf1/0x2c0 fscache_put_volume.part.0+0x5cb/0x9e0 erofs_fscache_unregister_fs+0x157/0x1b0 erofs_kill_sb+0xd9/0x1c0 deactivate_locked_super+0xa3/0x100 vfs_get_super+0x105/0x140 vfs_get_tree+0x8e/0x300 do_new_mount+0x28c/0x580 [...] ==================================================================
Following is the process that triggers the issue:
mount failed | daemon exit
------------------------------------------------------------
deactivate_locked_super cachefiles_daemon_release
erofs_kill_sb
erofs_fscache_unregister_fs
fscache_relinquish_volume
__fscache_relinquish_volume
fscache_put_volume(fscache_volume, fscache_volume_put_relinquish)
zero = __refcount_dec_and_test(&fscache_volume->ref, &ref);
cachefiles_put_unbind_pincount
cachefiles_daemon_unbind
cachefiles_withdraw_cache
cachefiles_withdraw_volumes
list_del_init(&volume->cache_link)
fscache_free_volume(fscache_volume)
cache->ops->free_volume
cachefiles_free_volume
list_del_init(&cachefiles_volume->cache_link);
kfree(fscache_volume)
cachefiles_withdraw_volume
fscache_withdraw_volume
fscache_volume->n_accesses
// fscache_volume UAF !!!The fscache_volume in cache->volumes must not have been freed yet, but its reference count may be 0. So use the new fscache_try_get_volume() helper function try to get its reference count.
If the reference count of fscache_volume is 0, fscache_put_volume() is freeing it, so wait for it to be removed from cache->volumes.
If its reference count is not 0, call cachefiles_withdraw_volume() with reference count protection to avoid the above issue.
--- fs/cachefiles/cache.c | 10 ++++++++++ include/trace/events/fscache.h | 4 ++++ 2 files changed, 14 insertions(+)
fs/cachefiles/cache.c +10 -0
@@ -8,6 +8,7 @@#include <linux/slab.h> #include <linux/statfs.h> #include <linux/namei.h> +#include <trace/events/fscache.h> #include "internal.h" /*
@@ -319,12 +320,20 @@ static void cachefiles_withdraw_volumes(_enter ("" );for (;;) { +struct fscache_volume *vcookie =NULL ;struct cachefiles_volume *volume =NULL ;spin_lock (&cache->object_list_lock);if (!list_empty (&cache->volumes)) { volume =list_first_entry (&cache->volumes, struct cachefiles_volume, cache_link); + vcookie =fscache_try_get_volume (volume->vcookie, + fscache_volume_get_withdraw); +if (!vcookie) { +spin_unlock (&cache->object_list_lock); +cpu_relax (); +continue ; + }list_del_init (&volume->cache_link); }spin_unlock (&cache->object_list_lock);
@@ -332,6 +341,7 @@ static void cachefiles_withdraw_volumes(break ;cachefiles_withdraw_volume (volume); +fscache_put_volume (vcookie, fscache_volume_put_withdraw); }_leave ("" );
include/trace/events/fscache.h +4 -0
@@ -35,12 +35,14 @@ enum fscache_volume_trace { fscache_volume_get_cookie, fscache_volume_get_create_work, fscache_volume_get_hash_collision, + fscache_volume_get_withdraw, fscache_volume_free, fscache_volume_new_acquire, fscache_volume_put_cookie, fscache_volume_put_create_work, fscache_volume_put_hash_collision, fscache_volume_put_relinquish, + fscache_volume_put_withdraw, fscache_volume_see_create_work, fscache_volume_see_hash_wake, fscache_volume_wait_create_work,
@@ -120,12 +122,14 @@ enum fscache_access_trace { EM(fscache_volume_get_cookie, "GET cook ") \ EM(fscache_volume_get_create_work, "GET creat") \ EM(fscache_volume_get_hash_collision, "GET hcoll") \ + EM(fscache_volume_get_withdraw, "GET withd") \ EM(fscache_volume_free, "FREE ") \ EM(fscache_volume_new_acquire, "NEW acq ") \ EM(fscache_volume_put_cookie, "PUT cook ") \ EM(fscache_volume_put_create_work, "PUT creat") \ EM(fscache_volume_put_hash_collision, "PUT hcoll") \ EM(fscache_volume_put_relinquish, "PUT relnq") \ + EM(fscache_volume_put_withdraw, "PUT withd") \ EM(fscache_volume_see_create_work, "SEE creat") \ EM(fscache_volume_see_hash_wake, "SEE hwake") \E_ (fscache_volume_wait_create_work,"WAIT crea" )
Greg Kroah-Hartman
maintainerPATCH 163/163 cachefiles: fix slab-use-after-free in cachefiles_withdraw_cookie()
In reply to Greg Kroah-Hartman6.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Baokun Li <[email protected]>
[ Upstream commit 5d8f805789072ea7fd39504694b7bd17e5f751c4 ]
We got the following issue in our fault injection stress test:
==================================================================
BUG: KASAN: slab-use-after-free in cachefiles_withdraw_cookie+0x4d9/0x600 Read of size 8 at addr ffff888118efc000 by task kworker/u78:0/109 CPU: 13 PID: 109 Comm: kworker/u78:0 Not tainted 6.8.0-dirty #566 Call Trace: <TASK> kasan_report+0x93/0xc0 cachefiles_withdraw_cookie+0x4d9/0x600 fscache_cookie_state_machine+0x5c8/0x1230 fscache_cookie_worker+0x91/0x1c0 process_one_work+0x7fa/0x1800 [...] Allocated by task 117: kmalloc_trace+0x1b3/0x3c0 cachefiles_acquire_volume+0xf3/0x9c0 fscache_create_volume_work+0x97/0x150 process_one_work+0x7fa/0x1800 [...] Freed by task 120301: kfree+0xf1/0x2c0 cachefiles_withdraw_cache+0x3fa/0x920 cachefiles_put_unbind_pincount+0x1f6/0x250 cachefiles_daemon_release+0x13b/0x290 __fput+0x204/0xa00 task_work_run+0x139/0x230 do_exit+0x87a/0x29b0 [...] ==================================================================
Following is the process that triggers the issue:
p1 | p2
------------------------------------------------------------
fscache_begin_lookup
fscache_begin_volume_access
fscache_cache_is_live(fscache_cache)cachefiles_daemon_release
cachefiles_put_unbind_pincount
cachefiles_daemon_unbind
cachefiles_withdraw_cache
fscache_withdraw_cache
fscache_set_cache_state(cache, FSCACHE_CACHE_IS_WITHDRAWN);
cachefiles_withdraw_objects(cache)
fscache_wait_for_objects(fscache)
atomic_read(&fscache_cache->object_count) == 0
fscache_perform_lookup
cachefiles_lookup_cookie
cachefiles_alloc_object
refcount_set(&object->ref, 1);
object->volume = volume
fscache_count_object(vcookie->cache);
atomic_inc(&fscache_cache->object_count)
cachefiles_withdraw_volumes
cachefiles_withdraw_volume
fscache_withdraw_volume
__cachefiles_free_volume
kfree(cachefiles_volume)
fscache_cookie_state_machine
cachefiles_withdraw_cookie
cache = object->volume->cache;
// cachefiles_volume UAF !!!After setting FSCACHE_CACHE_IS_WITHDRAWN, wait for all the cookie lookups to complete first, and then wait for fscache_cache->object_count == 0 to avoid the cookie exiting after the volume has been freed and triggering the above issue. Therefore call fscache_withdraw_volume() before calling cachefiles_withdraw_objects().
This way, after setting FSCACHE_CACHE_IS_WITHDRAWN, only the following two cases will occur:
1) fscache_begin_lookup fails in fscache_begin_volume_access().
2) fscache_withdraw_volume() will ensure that fscache_count_object() has been executed before calling fscache_wait_for_objects().
--- fs/cachefiles/cache.c | 35 ++++++++++++++++++++++++++++++++++- fs/cachefiles/volume.c | 1 - 2 files changed, 34 insertions(+), 2 deletions(-)
fs/cachefiles/cache.c +34 -1
@@ -313,7 +313,39 @@ static void cachefiles_withdraw_objects( }/* -* Withdraw volumes. +* Withdraw fscache volumes. +*/ +static void cachefiles_withdraw_fscache_volumes (struct cachefiles_cache *cache) +{ +struct list_head *cur; +struct cachefiles_volume *volume; +struct fscache_volume *vcookie; + +_enter ("" ); +retry: +spin_lock (&cache->object_list_lock); +list_for_each (cur, &cache->volumes) { + volume = list_entry(cur, struct cachefiles_volume, cache_link); + +if (atomic_read (&volume->vcookie->n_accesses) ==0 ) +continue ; + + vcookie =fscache_try_get_volume (volume->vcookie, + fscache_volume_get_withdraw); +if (vcookie) { +spin_unlock (&cache->object_list_lock); +fscache_withdraw_volume (vcookie); +fscache_put_volume (vcookie, fscache_volume_put_withdraw); + goto retry; + } + } +spin_unlock (&cache->object_list_lock); + +_leave ("" ); +} + +/* +* Withdraw cachefiles volumes. */ static void cachefiles_withdraw_volumes (struct cachefiles_cache *cache) {
@@ -381,6 +413,7 @@ void cachefiles_withdraw_cache(struct capr_info ("File cache on %s unregistering\n" , fscache->name);fscache_withdraw_cache (fscache); +cachefiles_withdraw_fscache_volumes (cache);/* we now have to destroy all the active objects pertaining to this * cache - which we do by passing them off to thread pool to be
fs/cachefiles/volume.c +0 -1
@@ -133,7 +133,6 @@ void cachefiles_free_volume(struct fscacvoid cachefiles_withdraw_volume (struct cachefiles_volume *volume) { -fscache_withdraw_volume (volume->vcookie);cachefiles_set_volume_xattr (volume);__cachefiles_free_volume (volume); }
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.9.11 release. There are 163 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 Thu, 25 Jul 2024 18:01:03 +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.9.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.9.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
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 6.9.11 release. There are 163 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.9.y
6.6 passes our testing, too:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.6.y
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.9.11 release. There are 163 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 Thu, 25 Jul 2024 18:01:03 +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.9.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.9.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.9:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
116 tests: 116 pass, 0 failLinux version: 6.9.11-rc1-gebb35f61e5d3
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 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.9.11 release. There are 163 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 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.9.11 release. There are 163 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.
Am 23.07.2024 um 20:22 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.9.11 release. There are 163 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]
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.9.11 release. There are 163 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 Thu, 25 Jul 2024 18:01:03 +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.9.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.9.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.9.11 release. There are 163 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 Thu, 25 Jul 2024 18:01:03 +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.9.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.9.y
and the diffstat can be found below.thanks,
greg k-h
Tested rc1 against the Fedora build system (aarch64, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.9.11 release. There are 163 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 Thu, 25 Jul 2024 18:01:03 +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.9.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.9.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 6.9.11-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: ebb35f61e5d39f0baaca27b0bf8aa63f2c135ba5
* git describe: v6.9.10-164-gebb35f61e5d3
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.9.y/build/v6.9.10-164-gebb35f61e5d3
## Test Regressions (compared to v6.9.8-338-g61dff5687633)
## Metric Regressions (compared to v6.9.8-338-g61dff5687633)
## Test Fixes (compared to v6.9.8-338-g61dff5687633)
## Metric Fixes (compared to v6.9.8-338-g61dff5687633)
## Test result summary
total: 258631, pass: 223032, fail: 4979, skip: 30112, xfail: 508
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 127 total, 127 passed, 0 failed
* arm64: 36 total, 36 passed, 0 failed
* i386: 27 total, 27 passed, 0 failed
* mips: 24 total, 24 passed, 0 failed
* parisc: 3 total, 3 passed, 0 failed
* powerpc: 34 total, 34 passed, 0 failed
* riscv: 17 total, 17 passed, 0 failed
* s390: 12 total, 12 passed, 0 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 31 total, 31 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
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.9.11 release. There are 163 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 Thu, 25 Jul 2024 18:01:03 +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.9.11-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.9.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).