6.6.79-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 141/152 md: add a new callback pers->bitmap_sector()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yu Kuai <[email protected]>
commit 0c984a283a3ea3f10bebecd6c57c1d41b2e4f518 upstream.
This callback will be used in raid5 to convert io ranges from array to bitmap.
--- drivers/md/md.h | 3 +++ 1 file changed, 3 insertions(+)
drivers/md/md.h +3 -0
@@ -661,6 +661,9 @@ struct md_personalityvoid *(*takeover) (struct mddev *mddev);/* Changes the consistency policy of an active array. */ int (*change_consistency_policy)(struct mddev *mddev,const char *buf); +/* convert io ranges from array to bitmap */ +void (*bitmap_sector)(struct mddev *mddev,sector_t *offset, +unsigned long *sectors); };struct md_sysfs_entry {
Greg Kroah-Hartman
maintainerPATCH 142/152 md/raid5: implement pers->bitmap_sector()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yu Kuai <[email protected]>
commit 9c89f604476cf15c31fbbdb043cff7fbf1dbe0cb upstream.
Bitmap is used for the whole array for raid1/raid10, hence IO for the array can be used directly for bitmap. However, bitmap is used for underlying disks for raid5, hence IO for the array can't be used directly for bitmap.
Implement pers->bitmap_sector() for raid5 to convert IO ranges from the array to the underlying disks.
--- drivers/md/raid5.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+)
drivers/md/raid5.c +51 -0
@@ -5996,6 +5996,54 @@ static enum reshape_loc get_reshape_loc(return LOC_BEHIND_RESHAPE ; } +static void raid5_bitmap_sector (struct mddev *mddev,sector_t *offset, +unsigned long *sectors) +{ +struct r5conf *conf = mddev->private; +sector_t start = *offset; +sector_t end = start + *sectors; +sector_t prev_start = start; +sector_t prev_end = end; +int sectors_per_chunk; +enum reshape_loc loc; +int dd_idx; + + sectors_per_chunk = conf->chunk_sectors * + (conf->raid_disks - conf->max_degraded); + start =round_down (start, sectors_per_chunk); + end =round_up (end, sectors_per_chunk); + + start =raid5_compute_sector (conf, start,0 , &dd_idx,NULL ); + end =raid5_compute_sector (conf, end,0 , &dd_idx,NULL ); + +/* +* For LOC_INSIDE_RESHAPE, this IO will wait for reshape to make +* progress, hence it's the same as LOC_BEHIND_RESHAPE. +*/ + loc =get_reshape_loc (mddev, conf, prev_start); +if (likely (loc !=LOC_AHEAD_OF_RESHAPE )) { + *offset = start; + *sectors = end - start; +return ; + } + + sectors_per_chunk = conf->prev_chunk_sectors * + (conf->previous_raid_disks - conf->max_degraded); + prev_start =round_down (prev_start, sectors_per_chunk); + prev_end =round_down (prev_end, sectors_per_chunk); + + prev_start =raid5_compute_sector (conf, prev_start,1 , &dd_idx,NULL ); + prev_end =raid5_compute_sector (conf, prev_end,1 , &dd_idx,NULL ); + +/* +* for LOC_AHEAD_OF_RESHAPE, reshape can make progress before this IO +* is handled in make_stripe_request(), we can't know this here hence +* we set bits for both. +*/ + *offset =min (start, prev_start); + *sectors =max (end, prev_end) - *offset; +} +static enum stripe_result make_stripe_request (struct mddev *mddev,struct r5conf *conf,struct stripe_request_ctx *ctx,sector_t logical_sector,struct bio *bi)
@@ -9099,6 +9147,7 @@ static struct md_personality raid6_perso .quiesce = raid5_quiesce, .takeover = raid6_takeover, .change_consistency_policy = raid5_change_consistency_policy, + .bitmap_sector = raid5_bitmap_sector, };static struct md_personality raid5_personality = {
@@ -9124,6 +9173,7 @@ static struct md_personality raid5_perso .quiesce = raid5_quiesce, .takeover = raid5_takeover, .change_consistency_policy = raid5_change_consistency_policy, + .bitmap_sector = raid5_bitmap_sector, }; static struct md_personality raid4_personality =
@@ -9150,6 +9200,7 @@ static struct md_personality raid4_perso .quiesce = raid5_quiesce, .takeover = raid4_takeover, .change_consistency_policy = raid5_change_consistency_policy, + .bitmap_sector = raid5_bitmap_sector, };static int __init raid5_init (void )
Greg Kroah-Hartman
maintainerPATCH 143/152 md/md-bitmap: move bitmap_{start, end}write to md upper layer
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yu Kuai <[email protected]>
commit cd5fc653381811f1e0ba65f5d169918cab61476f upstream.
There are two BUG reports that raid5 will hang at bitmap_startwrite([1],[2]), root cause is that bitmap start write and end write is unbalanced, it's not quite clear where, and while reviewing raid5 code, it's found that bitmap operations can be optimized. For example, for a 4 disks raid5, with chunksize=8k, if user issue a IO (0 + 48k) to the array:
┌────────────────────────────────────────────────────────────┐ │chunk 0 │ │ ┌────────────┬─────────────┬─────────────┬────────────┼ │ sh0 │A0: 0 + 4k │A1: 8k + 4k │A2: 16k + 4k │A3: P │ │ ┼────────────┼─────────────┼─────────────┼────────────┼ │ sh1 │B0: 4k + 4k │B1: 12k + 4k │B2: 20k + 4k │B3: P │ ┼──────┴────────────┴─────────────┴─────────────┴────────────┼ │chunk 1 │ │ ┌────────────┬─────────────┬─────────────┬────────────┤ │ sh2 │C0: 24k + 4k│C1: 32k + 4k │C2: P │C3: 40k + 4k│ │ ┼────────────┼─────────────┼─────────────┼────────────┼ │ sh3 │D0: 28k + 4k│D1: 36k + 4k │D2: P │D3: 44k + 4k│ └──────┴────────────┴─────────────┴─────────────┴────────────┘
Before this patch, 4 stripe head will be used, and each sh will attach bio for 3 disks, and each attached bio will trigger bitmap_startwrite() once, which means total 12 times.
- 3 times (0 + 4k), for (A0, A1 and A2)
- 3 times (4 + 4k), for (B0, B1 and B2)
- 3 times (8 + 4k), for (C0, C1 and C3)
- 3 times (12 + 4k), for (D0, D1 and D3)
After this patch, md upper layer will calculate that IO range (0 + 48k) is corresponding to the bitmap (0 + 16k), and call bitmap_startwrite() just once.
Noted that this patch will align bitmap ranges to the chunks, for example, if user issue a IO (0 + 4k) to array:
- Before this patch, 1 time (0 + 4k), for A0;
- After this patch, 1 time (0 + 8k) for chunk 0;
Usually, one bitmap bit will represent more than one disk chunk, and this doesn't have any difference. And even if user really created a array that one chunk contain multiple bits, the overhead is that more data will be recovered after power failure.
Also remove STRIPE_BITMAP_PENDING since it's not used anymore.
[1] https://lore.kernel.org/all/CAJpMwyjmHQLvm6zg1cmQErttNNQPDAAXPKM3xgTjMhbfts986Q@mail.gmail.com/
[2] https://lore.kernel.org/all/[email protected]/
[There is no bitmap_operations, resolve conflicts by replacing bitmap_ops->{startwrite, endwrite} with md_bitmap_{startwrite, endwrite}]
--- drivers/md/md-bitmap.c | 2 - drivers/md/md.c | 26 ++++++++++++++++++++++++ drivers/md/md.h | 2 + drivers/md/raid1.c | 5 ---- drivers/md/raid10.c | 4 --- drivers/md/raid5-cache.c | 2 - drivers/md/raid5.c | 50 ++++------------------------------------------- drivers/md/raid5.h | 3 -- 8 files changed, 33 insertions(+), 61 deletions(-)
drivers/md/md-bitmap.c +0 -2
@@ -1517,7 +1517,6 @@ int md_bitmap_startwrite(struct bitmap * }return 0 ; } -EXPORT_SYMBOL_GPL (md_bitmap_startwrite);void md_bitmap_endwrite (struct bitmap *bitmap,sector_t offset,unsigned long sectors)
@@ -1564,7 +1563,6 @@ void md_bitmap_endwrite(struct bitmap *b sectors =0 ; } } -EXPORT_SYMBOL_GPL (md_bitmap_endwrite);static int __bitmap_start_sync (struct bitmap *bitmap,sector_t offset,sector_t *blocks,int degraded)
drivers/md/md.c +26 -0
@@ -8713,12 +8713,32 @@ void md_submit_discard_bio(struct mddev }EXPORT_SYMBOL_GPL (md_submit_discard_bio); +static void md_bitmap_start (struct mddev *mddev, +struct md_io_clone *md_io_clone) +{ +if (mddev->pers->bitmap_sector) + mddev->pers->bitmap_sector (mddev, &md_io_clone->offset, + &md_io_clone->sectors); + +md_bitmap_startwrite (mddev->bitmap, md_io_clone->offset, + md_io_clone->sectors); +} + +static void md_bitmap_end (struct mddev *mddev,struct md_io_clone *md_io_clone) +{ +md_bitmap_endwrite (mddev->bitmap, md_io_clone->offset, + md_io_clone->sectors); +} +static void md_end_clone_io (struct bio *bio) {struct md_io_clone *md_io_clone = bio->bi_private;struct bio *orig_bio = md_io_clone->orig_bio;struct mddev *mddev = md_io_clone->mddev; +if (bio_data_dir (orig_bio) ==WRITE && mddev->bitmap) +md_bitmap_end (mddev, md_io_clone); +if (bio->bi_status && !orig_bio->bi_status) orig_bio->bi_status = bio->bi_status;
@@ -8743,6 +8763,12 @@ static void md_clone_bio(struct mddev *mif (blk_queue_io_stat (bdev->bd_disk->queue)) md_io_clone->start_time =bio_start_io_acct (*bio); +if (bio_data_dir (*bio) ==WRITE && mddev->bitmap) { + md_io_clone->offset = (*bio)->bi_iter.bi_sector; + md_io_clone->sectors =bio_sectors (*bio); +md_bitmap_start (mddev, md_io_clone); + } + clone->bi_end_io = md_end_clone_io; clone->bi_private = md_io_clone; *bio = clone;
drivers/md/md.h +2 -0
@@ -746,6 +746,8 @@ struct md_io_clone {struct mddev *mddev;struct bio *orig_bio;unsigned long start_time; +sector_t offset; +unsigned long sectors;struct bio bio_clone; };
drivers/md/raid1.c +0 -5
@@ -421,9 +421,6 @@ static void close_write(struct r1bio *r1 }if (test_bit (R1BIO_BehindIO, &r1_bio->state))md_bitmap_end_behind_write (r1_bio->mddev); -/* clear the bitmap if all writes complete successfully */ -md_bitmap_endwrite (r1_bio->mddev->bitmap, r1_bio->sector, - r1_bio->sectors);md_write_end (r1_bio->mddev); }
@@ -1517,8 +1514,6 @@ static void raid1_write_request(struct mif (test_bit (R1BIO_BehindIO, &r1_bio->state))md_bitmap_start_behind_write (mddev); -md_bitmap_startwrite (bitmap, r1_bio->sector, - r1_bio->sectors); first_clone =0 ; }
drivers/md/raid10.c +0 -4
@@ -427,9 +427,6 @@ static void raid10_end_read_request(strustatic void close_write (struct r10bio *r10_bio) { -/* clear the bitmap if all writes complete successfully */ -md_bitmap_endwrite (r10_bio->mddev->bitmap, r10_bio->sector, - r10_bio->sectors);md_write_end (r10_bio->mddev); }
@@ -1541,7 +1538,6 @@ static void raid10_write_request(structmd_account_bio (mddev, &bio); r10_bio->master_bio = bio;atomic_set (&r10_bio->remaining,1 ); -md_bitmap_startwrite (mddev->bitmap, r10_bio->sector, r10_bio->sectors);for (i =0 ; i < conf->copies; i++) {if (r10_bio->devs[i].bio)
drivers/md/raid5-cache.c +0 -2
@@ -313,8 +313,6 @@ void r5c_handle_cached_data_endio(structif (sh->dev[i].written) {set_bit (R5_UPTODATE , &sh->dev[i].flags);r5c_return_dev_pending_writes (conf, &sh->dev[i]); -md_bitmap_endwrite (conf->mddev->bitmap, sh->sector, -RAID5_STRIPE_SECTORS (conf)); } } }
drivers/md/raid5.c +5 -45
110 lines not on this page · raw message
drivers/md/raid5.h +0 -3
@@ -371,9 +371,6 @@ enum {STRIPE_ON_RELEASE_LIST ,STRIPE_BATCH_READY ,STRIPE_BATCH_ERR , -STRIPE_BITMAP_PENDING ,/* Being added to bitmap, don't add -* to batch yet. -*/ STRIPE_LOG_TRAPPED, /* trapped into log (see raid5-cache.c)* this bit is used in two scenarios: *
Greg Kroah-Hartman
maintainerPATCH 144/152 arm64: Filter out SVE hwcaps when FEAT_SVE isnt implemented
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Zyngier <[email protected]>
commit 064737920bdbca86df91b96aed256e88018fef3a upstream.
The hwcaps code that exposes SVE features to userspace only considers ID_AA64ZFR0_EL1, while this is only valid when ID_AA64PFR0_EL1.SVE advertises that SVE is actually supported.
The expectations are that when ID_AA64PFR0_EL1.SVE is 0, the ID_AA64ZFR0_EL1 register is also 0. So far, so good.
Things become a bit more interesting if the HW implements SME. In this case, a few ID_AA64ZFR0_EL1 fields indicate *SME* features. And these fields overlap with their SVE interpretations. But the architecture says that the SME and SVE feature sets must match, so we're still hunky-dory.
This goes wrong if the HW implements SME, but not SVE. In this case, we end-up advertising some SVE features to userspace, even if the HW has none. That's because we never consider whether SVE is actually implemented. Oh well.
Fix it by restricting all SVE capabilities to ID_AA64PFR0_EL1.SVE being non-zero. The HWCAPS documentation is amended to reflect the actually checks performed by the kernel.
--- Documentation/arch/arm64/elf_hwcaps.rst | 36 ++++++++++++++++++++---------- arch/arm64/kernel/cpufeature.c | 38 +++++++++++++++++++++----------- 2 files changed, 50 insertions(+), 24 deletions(-)
Documentation/arch/arm64/elf_hwcaps.rst +24 -12
@@ -174,22 +174,28 @@ HWCAP2_DCPODP Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010. HWCAP2_SVE2 - Functionality implied by ID_AA64ZFR0_EL1.SVEVer == 0b0001. + Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and + ID_AA64ZFR0_EL1.SVEver == 0b0001. HWCAP2_SVEAES - Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0001. + Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and + ID_AA64ZFR0_EL1.AES == 0b0001. HWCAP2_SVEPMULL - Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0010. + Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and + ID_AA64ZFR0_EL1.AES == 0b0010. HWCAP2_SVEBITPERM - Functionality implied by ID_AA64ZFR0_EL1.BitPerm == 0b0001. + Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and + ID_AA64ZFR0_EL1.BitPerm == 0b0001. HWCAP2_SVESHA3 - Functionality implied by ID_AA64ZFR0_EL1.SHA3 == 0b0001. + Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and + ID_AA64ZFR0_EL1.SHA3 == 0b0001. HWCAP2_SVESM4 - Functionality implied by ID_AA64ZFR0_EL1.SM4 == 0b0001. + Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and + ID_AA64ZFR0_EL1.SM4 == 0b0001. HWCAP2_FLAGM2 Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0010.
@@ -198,16 +204,20 @@ HWCAP2_FRINT Functionality implied by ID_AA64ISAR1_EL1.FRINTTS == 0b0001. HWCAP2_SVEI8MM - Functionality implied by ID_AA64ZFR0_EL1.I8MM == 0b0001. + Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and + ID_AA64ZFR0_EL1.I8MM == 0b0001. HWCAP2_SVEF32MM - Functionality implied by ID_AA64ZFR0_EL1.F32MM == 0b0001. + Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and + ID_AA64ZFR0_EL1.F32MM == 0b0001. HWCAP2_SVEF64MM - Functionality implied by ID_AA64ZFR0_EL1.F64MM == 0b0001. + Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and + ID_AA64ZFR0_EL1.F64MM == 0b0001. HWCAP2_SVEBF16 - Functionality implied by ID_AA64ZFR0_EL1.BF16 == 0b0001. + Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and + ID_AA64ZFR0_EL1.BF16 == 0b0001. HWCAP2_I8MM Functionality implied by ID_AA64ISAR1_EL1.I8MM == 0b0001.
@@ -273,7 +283,8 @@ HWCAP2_EBF16 Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0010. HWCAP2_SVE_EBF16 - Functionality implied by ID_AA64ZFR0_EL1.BF16 == 0b0010. + Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and + ID_AA64ZFR0_EL1.BF16 == 0b0010. HWCAP2_CSSC Functionality implied by ID_AA64ISAR2_EL1.CSSC == 0b0001.
@@ -282,7 +293,8 @@ HWCAP2_RPRFM Functionality implied by ID_AA64ISAR2_EL1.RPRFM == 0b0001. HWCAP2_SVE2P1 - Functionality implied by ID_AA64ZFR0_EL1.SVEver == 0b0010. + Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and + ID_AA64ZFR0_EL1.SVEver == 0b0010. HWCAP2_SME2 Functionality implied by ID_AA64SMFR0_EL1.SMEver == 0b0001.
arch/arm64/kernel/cpufeature.c +26 -12
@@ -2762,6 +2762,13 @@ static const struct arm64_cpu_capabiliti .matches = match, \ } +#define HWCAP_CAP_MATCH_ID (match, reg, field, min_value, cap_type, cap) \ + { \ + __HWCAP_CAP(#cap, cap_type, cap) \ + HWCAP_CPUID_MATCH(reg, field, min_value) \ + .matches = match, \ + } + #ifdef CONFIG_ARM64_PTR_AUTH static const struct arm64_cpu_capabilities ptr_auth_hwcap_addr_matches[] = { {
@@ -2790,6 +2797,13 @@ static const struct arm64_cpu_capabiliti };#endif +#ifdef CONFIG_ARM64_SVE +static bool has_sve_feature (const struct arm64_cpu_capabilities *cap,int scope) +{ +return system_supports_sve () &&has_user_cpuid_feature (cap, scope); +} +#endif +static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {HWCAP_CAP (ID_AA64ISAR0_EL1 ,AES ,PMULL ,CAP_HWCAP ,KERNEL_HWCAP_PMULL ),HWCAP_CAP (ID_AA64ISAR0_EL1 ,AES ,AES ,CAP_HWCAP ,KERNEL_HWCAP_AES ),
@@ -2827,18 +2841,18 @@ static const struct arm64_cpu_capabiliti HWCAP_CAP(ID_AA64MMFR2_EL1, AT, IMP, CAP_HWCAP, KERNEL_HWCAP_USCAT),#ifdef CONFIG_ARM64_SVE HWCAP_CAP (ID_AA64PFR0_EL1 ,SVE ,IMP ,CAP_HWCAP ,KERNEL_HWCAP_SVE ), -HWCAP_CAP (ID_AA64ZFR0_EL1 , SVEver, SVE2p1,CAP_HWCAP ,KERNEL_HWCAP_SVE2P1 ), -HWCAP_CAP (ID_AA64ZFR0_EL1 , SVEver,SVE2 ,CAP_HWCAP ,KERNEL_HWCAP_SVE2 ), -HWCAP_CAP (ID_AA64ZFR0_EL1 ,AES ,IMP ,CAP_HWCAP ,KERNEL_HWCAP_SVEAES ), -HWCAP_CAP (ID_AA64ZFR0_EL1 ,AES ,PMULL128 ,CAP_HWCAP ,KERNEL_HWCAP_SVEPMULL ), -HWCAP_CAP (ID_AA64ZFR0_EL1 , BitPerm,IMP ,CAP_HWCAP ,KERNEL_HWCAP_SVEBITPERM ), -HWCAP_CAP (ID_AA64ZFR0_EL1 ,BF16 ,IMP ,CAP_HWCAP ,KERNEL_HWCAP_SVEBF16 ), -HWCAP_CAP (ID_AA64ZFR0_EL1 ,BF16 ,EBF16 ,CAP_HWCAP ,KERNEL_HWCAP_SVE_EBF16 ), -HWCAP_CAP (ID_AA64ZFR0_EL1 ,SHA3 ,IMP ,CAP_HWCAP ,KERNEL_HWCAP_SVESHA3 ), -HWCAP_CAP (ID_AA64ZFR0_EL1 ,SM4 ,IMP ,CAP_HWCAP ,KERNEL_HWCAP_SVESM4 ), -HWCAP_CAP (ID_AA64ZFR0_EL1 ,I8MM ,IMP ,CAP_HWCAP ,KERNEL_HWCAP_SVEI8MM ), -HWCAP_CAP (ID_AA64ZFR0_EL1 ,F32MM ,IMP ,CAP_HWCAP ,KERNEL_HWCAP_SVEF32MM ), -HWCAP_CAP (ID_AA64ZFR0_EL1 ,F64MM ,IMP ,CAP_HWCAP ,KERNEL_HWCAP_SVEF64MM ), +HWCAP_CAP_MATCH_ID (has_sve_feature,ID_AA64ZFR0_EL1 , SVEver, SVE2p1,CAP_HWCAP ,KERNEL_HWCAP_SVE2P1 ), +HWCAP_CAP_MATCH_ID (has_sve_feature,ID_AA64ZFR0_EL1 , SVEver,SVE2 ,CAP_HWCAP ,KERNEL_HWCAP_SVE2 ), +HWCAP_CAP_MATCH_ID (has_sve_feature,ID_AA64ZFR0_EL1 ,AES ,IMP ,CAP_HWCAP ,KERNEL_HWCAP_SVEAES ), +HWCAP_CAP_MATCH_ID (has_sve_feature,ID_AA64ZFR0_EL1 ,AES ,PMULL128 ,CAP_HWCAP ,KERNEL_HWCAP_SVEPMULL ), +HWCAP_CAP_MATCH_ID (has_sve_feature,ID_AA64ZFR0_EL1 , BitPerm,IMP ,CAP_HWCAP ,KERNEL_HWCAP_SVEBITPERM ), +HWCAP_CAP_MATCH_ID (has_sve_feature,ID_AA64ZFR0_EL1 ,BF16 ,IMP ,CAP_HWCAP ,KERNEL_HWCAP_SVEBF16 ), +HWCAP_CAP_MATCH_ID (has_sve_feature,ID_AA64ZFR0_EL1 ,BF16 ,EBF16 ,CAP_HWCAP ,KERNEL_HWCAP_SVE_EBF16 ), +HWCAP_CAP_MATCH_ID (has_sve_feature,ID_AA64ZFR0_EL1 ,SHA3 ,IMP ,CAP_HWCAP ,KERNEL_HWCAP_SVESHA3 ), +HWCAP_CAP_MATCH_ID (has_sve_feature,ID_AA64ZFR0_EL1 ,SM4 ,IMP ,CAP_HWCAP ,KERNEL_HWCAP_SVESM4 ), +HWCAP_CAP_MATCH_ID (has_sve_feature,ID_AA64ZFR0_EL1 ,I8MM ,IMP ,CAP_HWCAP ,KERNEL_HWCAP_SVEI8MM ), +HWCAP_CAP_MATCH_ID (has_sve_feature,ID_AA64ZFR0_EL1 ,F32MM ,IMP ,CAP_HWCAP ,KERNEL_HWCAP_SVEF32MM ), +HWCAP_CAP_MATCH_ID (has_sve_feature,ID_AA64ZFR0_EL1 ,F64MM ,IMP ,CAP_HWCAP ,KERNEL_HWCAP_SVEF64MM ), #endifHWCAP_CAP (ID_AA64PFR1_EL1 ,SSBS ,SSBS2 ,CAP_HWCAP ,KERNEL_HWCAP_SSBS ), #ifdef CONFIG_ARM64_BTI
Greg Kroah-Hartman
maintainerPATCH 145/152 mm: gup: fix infinite loop within __get_longterm_locked
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhaoyang Huang <[email protected]>
commit 1aaf8c122918aa8897605a9aa1e8ed6600d6f930 upstream.
We can run into an infinite loop in __get_longterm_locked() when collect_longterm_unpinnable_folios() finds only folios that are isolated from the LRU or were never added to the LRU. This can happen when all folios to be pinned are never added to the LRU, for example when vm_ops->fault allocated pages using cma_alloc() and never added them to the LRU.
Fix it by simply taking a look at the list in the single caller, to see if anything was added.
--- mm/gup.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-)
mm/gup.c +4 -10
@@ -1946,14 +1946,14 @@ struct page *get_dump_page(unsigned long/* * Returns the number of collected pages. Return value is always >= 0. */ -static unsigned long collect_longterm_unpinnable_pages ( +static void collect_longterm_unpinnable_pages (struct list_head *movable_page_list,unsigned long nr_pages,struct page **pages) { -unsigned long i, collected =0 ;struct folio *prev_folio =NULL ;bool drain_allow = true; +unsigned long i;for (i =0 ; i < nr_pages; i++) {struct folio *folio =page_folio (pages[i]);
@@ -1965,8 +1965,6 @@ static unsigned long collect_longterm_unif (folio_is_longterm_pinnable (folio))continue ; - collected++; -if (folio_is_device_coherent (folio))continue ;
@@ -1988,8 +1986,6 @@ static unsigned long collect_longterm_unNR_ISOLATED_ANON +folio_is_file_lru (folio), folio_nr_pages(folio)); } - -return collected; }/*
@@ -2082,12 +2078,10 @@ err:static long check_and_migrate_movable_pages (unsigned long nr_pages,struct page **pages) { -unsigned long collected;LIST_HEAD (movable_page_list); - collected =collect_longterm_unpinnable_pages (&movable_page_list, - nr_pages, pages); -if (!collected) +collect_longterm_unpinnable_pages (&movable_page_list, nr_pages, pages); +if (list_empty (&movable_page_list))return 0 ; return migrate_longterm_unpinnable_pages(&movable_page_list, nr_pages,
Greg Kroah-Hartman
maintainerPATCH 146/152 alpha: replace hardcoded stack offsets with autogenerated ones
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ivan Kokshaysky <[email protected]>
commit 77b823fa619f97d16409ca37ad4f7936e28c5f83 upstream.
This allows the assembly in entry.S to automatically keep in sync with changes in the stack layout (struct pt_regs and struct switch_stack).
--- arch/alpha/kernel/asm-offsets.c | 2 ++ arch/alpha/kernel/entry.S | 4 ---- 2 files changed, 2 insertions(+), 4 deletions(-)
arch/alpha/kernel/asm-offsets.c +2 -0
@@ -34,7 +34,9 @@ void foo(void)DEFINE (CRED_EGID , offsetof(struct cred , egid));BLANK (); +DEFINE (SP_OFF , offsetof(struct pt_regs , ps));DEFINE (SIZEOF_PT_REGS ,sizeof (struct pt_regs )); +DEFINE (SWITCH_STACK_SIZE ,sizeof (struct switch_stack ));DEFINE (PT_PTRACED ,PT_PTRACED );DEFINE (CLONE_VM ,CLONE_VM );DEFINE (CLONE_UNTRACED ,CLONE_UNTRACED );
arch/alpha/kernel/entry.S +0 -4
@@ -15,10 +15,6 @@ .set noat .cfi_sections .debug_frame -/* Stack offsets. */ -#define SP_OFF 184 -#define SWITCH_STACK_SIZE 64 - .macro CFI_START_OSF_FRAME func .align 4 .globl \func
Greg Kroah-Hartman
maintainerPATCH 147/152 HID: hid-steam: Dont use cancel_delayed_work_sync in IRQ context
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vicki Pfau <[email protected]>
commit b051ffa2aeb2a60e092387b6fb2af1ad42f51a3c upstream.
Lockdep reported that, as steam_do_deck_input_event is called from steam_raw_event inside of an IRQ context, it can lead to issues if that IRQ occurs while the work to be cancelled is running. By using cancel_delayed_work, this issue can be avoided. The exact ordering of the work and the event processing is not super important, so this is safe.
--- drivers/hid/hid-steam.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hid/hid-steam.c +1 -1
@@ -1615,7 +1615,7 @@ static void steam_do_deck_input_event(stif (!(b9 &BIT (6 )) && steam->did_mode_switch) { steam->did_mode_switch = false; -cancel_delayed_work_sync (&steam->mode_switch); +cancel_delayed_work (&steam->mode_switch); }else if (!steam->client_opened && (b9 &BIT (6 )) && !steam->did_mode_switch) { steam->did_mode_switch = true;schedule_delayed_work (&steam->mode_switch,45 *HZ /100 );
Greg Kroah-Hartman
maintainerPATCH 148/152 io_uring/kbuf: reallocate buf lists on upgrade
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Begunkov <[email protected]>
commit 8802766324e1f5d414a81ac43365c20142e85603 upstream.
IORING_REGISTER_PBUF_RING can reuse an old struct io_buffer_list if it was created for legacy selected buffer and has been emptied. It violates the requirement that most of the field should stay stable after publish. Always reallocate it instead.
--- io_uring/kbuf.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
io_uring/kbuf.c +11 -4
@@ -301,6 +301,12 @@ void io_destroy_buffers(struct io_ring_c } } +static void io_destroy_bl (struct io_ring_ctx *ctx,struct io_buffer_list *bl) +{ +xa_erase (&ctx->io_bl_xa, bl->bgid); +io_put_bl (ctx, bl); +} +int io_remove_buffers_prep (struct io_kiocb *req,const struct io_uring_sqe *sqe) { struct io_provide_buf *p = io_kiocb_to_cmd(req, struct io_provide_buf);
@@ -642,12 +648,13 @@ int io_register_pbuf_ring(struct io_ring/* if mapped buffer ring OR classic exists, don't allow */ if (bl->is_mapped || !list_empty (&bl->buf_list))return -EEXIST ; - }else { - free_bl = bl =kzalloc (sizeof (*bl),GFP_KERNEL ); -if (!bl) -return -ENOMEM ; +io_destroy_bl (ctx, bl); } + free_bl = bl =kzalloc (sizeof (*bl),GFP_KERNEL ); +if (!bl) +return -ENOMEM ; +if (!(reg.flags &IOU_PBUF_RING_MMAP )) ret =io_pin_pbuf_ring (®, bl);else
Greg Kroah-Hartman
maintainerPATCH 149/152 vsock: Keep the binding until socket destruction
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Luczaj <[email protected]>
commit fcdd2242c0231032fc84e1404315c245ae56322a upstream.
Preserve sockets bindings; this includes both resulting from an explicit bind() and those implicitly bound through autobind during connect().
Prevents socket unbinding during a transport reassignment, which fixes a use-after-free:
1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)
2. transport->release() calls vsock_remove_bound() without checking if sk was bound and moved to bound list (refcnt=1)
3. vsock_bind() assumes sk is in unbound list and before __vsock_insert_bound(vsock_bound_sockets()) calls __vsock_remove_bound() which does:
list_del_init(&vsk->bound_table); // nop
sock_put(&vsk->sk); // refcnt=0
BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730 Read of size 4 at addr ffff88816b46a74c by task a.out/2057 dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 __vsock_bind+0x62e/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 2057: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 __vsock_create.constprop.0+0x2e/0xb60 vsock_create+0xe4/0x420 __sock_create+0x241/0x650 __sys_socket+0xf2/0x1a0 __x64_sys_socket+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2057: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 __vsock_bind+0x5e1/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150 RIP: 0010:refcount_warn_saturate+0xce/0x150 __vsock_bind+0x66d/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
refcount_t: underflow; use-after-free.
WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150 RIP: 0010:refcount_warn_saturate+0xee/0x150 vsock_remove_bound+0x187/0x1e0 __vsock_release+0x383/0x4a0 vsock_release+0x90/0x120 __sock_release+0xa3/0x250 sock_close+0x14/0x20 __fput+0x359/0xa80 task_work_run+0x107/0x1d0 do_exit+0x847/0x2560 do_group_exit+0xb8/0x250 __x64_sys_exit_group+0x3a/0x50 x64_sys_call+0xfec/0x14f0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
--- net/vmw_vsock/af_vsock.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
net/vmw_vsock/af_vsock.c +6 -2
@@ -336,7 +336,10 @@ EXPORT_SYMBOL_GPL(vsock_find_connected_svoid vsock_remove_sock (struct vsock_sock *vsk) { -vsock_remove_bound (vsk); +/* Transport reassignment must not remove the binding. */ +if (sock_flag (sk_vsock (vsk),SOCK_DEAD )) +vsock_remove_bound (vsk); +vsock_remove_connected (vsk); }EXPORT_SYMBOL_GPL (vsock_remove_sock);
@@ -820,12 +823,13 @@ static void __vsock_release(struct sock*/ lock_sock_nested (sk, level); +sock_orphan (sk); +if (vsk->transport) vsk->transport->release (vsk);else if (sock_type_connectible (sk->sk_type))vsock_remove_sock (vsk); -sock_orphan (sk); sk->sk_shutdown =SHUTDOWN_MASK ;skb_queue_purge (&sk->sk_receive_queue);
Greg Kroah-Hartman
maintainerPATCH 150/152 vsock: Orphan socket after transport release
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Luczaj <[email protected]>
commit 78dafe1cf3afa02ed71084b350713b07e72a18fb upstream.
During socket release, sock_orphan() is called without considering that it sets sk->sk_wq to NULL. Later, if SO_LINGER is enabled, this leads to a null pointer dereferenced in virtio_transport_wait_close().
Orphan the socket only after transport release.
Partially reverts the 'Fixes:' commit.
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] lock_acquire+0x19e/0x500 _raw_spin_lock_irqsave+0x47/0x70 add_wait_queue+0x46/0x230 virtio_transport_release+0x4e7/0x7f0 __vsock_release+0xfd/0x490 vsock_release+0x90/0x120 __sock_release+0xa3/0x250 sock_close+0x14/0x20 __fput+0x35e/0xa90 __x64_sys_close+0x78/0xd0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
--- net/vmw_vsock/af_vsock.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
net/vmw_vsock/af_vsock.c +7 -1
@@ -823,13 +823,19 @@ static void __vsock_release(struct sock*/ lock_sock_nested (sk, level); -sock_orphan (sk); +/* Indicate to vsock_remove_sock() that the socket is being released and +* can be removed from the bound_table. Unlike transport reassignment +* case, where the socket must remain bound despite vsock_remove_sock() +* being called from the transport release() callback. +*/ +sock_set_flag (sk,SOCK_DEAD );if (vsk->transport) vsk->transport->release (vsk);else if (sock_type_connectible (sk->sk_type))vsock_remove_sock (vsk); +sock_orphan (sk); sk->sk_shutdown =SHUTDOWN_MASK ;skb_queue_purge (&sk->sk_receive_queue);
Greg Kroah-Hartman
maintainerPATCH 151/152 x86/i8253: Disable PIT timer 0 when not in use
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Woodhouse <[email protected]>
commit 70e6b7d9ae3c63df90a7bba7700e8d5c300c3c60 upstream.
Leaving the PIT interrupt running can cause noticeable steal time for virtual guests. The VMM generally has a timer which toggles the IRQ input to the PIC and I/O APIC, which takes CPU time away from the guest. Even on real hardware, running the counter may use power needlessly (albeit not much).
Make sure it's turned off if it isn't going to be used.
--- arch/x86/kernel/i8253.c | 11 +++++++++-- drivers/clocksource/i8253.c | 13 +++++++++---- include/linux/i8253.h | 1 + 3 files changed, 19 insertions(+), 6 deletions(-)
arch/x86/kernel/i8253.c +9 -2
@@ -8,6 +8,7 @@#include <linux/timex.h> #include <linux/i8253.h> +#include <asm/hypervisor.h> #include <asm/apic.h> #include <asm/hpet.h> #include <asm/time.h>
@@ -39,9 +40,15 @@ static bool __init use_pit(void)bool __init pit_timer_init (void ) { -if (!use_pit ()) +if (!use_pit ()) { +/* +* Don't just ignore the PIT. Ensure it's stopped, because +* VMMs otherwise steal CPU time just to pointlessly waggle +* the (masked) IRQ. +*/ +clockevent_i8253_disable ();return false; - + }clockevent_i8253_init (true); global_clock_event = &i8253_clockevent;return true;
drivers/clocksource/i8253.c +9 -4
@@ -108,11 +108,8 @@ int __init clocksource_i8253_init(void)#endif #ifdef CONFIG_CLKEVT_I8253 -static int pit_shutdown (struct clock_event_device *evt) +void clockevent_i8253_disable (void ) { -if (!clockevent_state_oneshot (evt) && !clockevent_state_periodic (evt)) -return 0 ; -raw_spin_lock (&i8253_lock);outb_p (0x30 ,PIT_MODE );
@@ -123,6 +120,14 @@ static int pit_shutdown(struct clock_eve }raw_spin_unlock (&i8253_lock); +} + +static int pit_shutdown (struct clock_event_device *evt) +{ +if (!clockevent_state_oneshot (evt) && !clockevent_state_periodic (evt)) +return 0 ; + +clockevent_i8253_disable ();return 0 ; }
include/linux/i8253.h +1 -0
@@ -24,6 +24,7 @@ extern raw_spinlock_t i8253_lock;extern bool i8253_clear_counter_on_shutdown;extern struct clock_event_device i8253_clockevent;extern void clockevent_i8253_init (bool oneshot); +extern void clockevent_i8253_disable (void );extern void setup_pit_timer (void );
Greg Kroah-Hartman
maintainerPATCH 152/152 Revert "vfio/platform: check the bounds of read/write syscalls"
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <[email protected]>
This reverts commit 03844b1908114680ca35fa0a0aba3d906a6d78af.
It had been committed multiple times to the tree, and isn't needed again.
--- drivers/vfio/platform/vfio_platform_common.c | 10 ---------- 1 file changed, 10 deletions(-)
drivers/vfio/platform/vfio_platform_common.c +0 -10
@@ -393,11 +393,6 @@ static ssize_t vfio_platform_read_mmio(s count =min_t (size_t, count, reg->size - off); -if (off >= reg->size) -return -EINVAL ; - - count =min_t (size_t, count, reg->size - off); -if (!reg->ioaddr) { reg->ioaddr =ioremap (reg->addr, reg->size);
@@ -479,11 +474,6 @@ static ssize_t vfio_platform_write_mmio(if (off >= reg->size)return -EINVAL ; - - count =min_t (size_t, count, reg->size - off); - -if (off >= reg->size) -return -EINVAL ; count =min_t (size_t, count, reg->size - off);
Am 19.02.2025 um 09:26 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.6.79 release. There are 152 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.6.79 release. There are 152 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 Fri, 21 Feb 2025 08:25:11 +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.79-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.79-rc1-gde6988e4026e
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
The kernel, bpf tool, perf tool, and kselftest builds fine for v6.6.79-rc1 on x86 and arm64 Azure VM.
Kernel binary size for x86 build:
text data bss dec hex filename 27310300 16707994 4644864 48663158 2e68a76 vmlinux
Kernel binary size for arm64 build:
text data bss dec hex filename 34663631 13841778 970368 49475777 2f2f0c1 vmlinux
Thanks,
Hardik
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.79 release. There are 152 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 Fri, 21 Feb 2025 08:25:11 +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.79-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 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.79 release. There are 152 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 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.79 release. There are 152 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 Fri, 21 Feb 2025 08:25:11 +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.79-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.79-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: de6988e4026e1da2b3653e74a33e46860cb3f717
* git describe: v6.6.78-153-gde6988e4026e
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.78-153-gde6988e4026e
## Test Regressions (compared to v6.6.77-274-ge4f2e2ad0f5f)
## Metric Regressions (compared to v6.6.77-274-ge4f2e2ad0f5f)
## Test Fixes (compared to v6.6.77-274-ge4f2e2ad0f5f)
## Metric Fixes (compared to v6.6.77-274-ge4f2e2ad0f5f)
## Test result summary
total: 67097, pass: 53621, fail: 1765, skip: 11452, xfail: 259
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 127 total, 127 passed, 0 failed
* arm64: 39 total, 39 passed, 0 failed
* i386: 26 total, 22 passed, 4 failed
* mips: 24 total, 24 passed, 0 failed
* parisc: 3 total, 3 passed, 0 failed
* powerpc: 30 total, 30 passed, 0 failed
* riscv: 18 total, 18 passed, 0 failed
* s390: 13 total, 12 passed, 1 failed
* sh: 12 total, 10 passed, 2 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 32 total, 32 passed, 0 failed
## Test suites summary
* boot
* commands
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-exec
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-kcmp
* kselftest-kvm
* 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-x86
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-build-clang
* log-parser-build-gcc
* log-parser-test
* ltp-capability
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-crypto
* ltp-cve
* 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-syscalls
* ltp-tracing
* perf
* rcutorture
--
Linaro LKFT
https://lkft.linaro.org
Hi Greg,
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.79 release. There are 152 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.
No problems seen on x86_64 and aarch64 with our testing.
Thanks,
Harshit
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.79 release. There are 152 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 Fri, 21 Feb 2025 08:25:11 +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.79-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 test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.79 release. There are 152 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.
Hi Greg,
No regressions or any sort of issues to speak of. Builds fine on my x86_64 test machine.
All the best,
Slade
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.79 release. There are 152 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 Fri, 21 Feb 2025 08:25:11 +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.79-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