Bugzilla – Bug 1223731
VUL-0: CVE-2024-26944: kernel: btrfs: zoned: use-after-free in do_zone_finish()
Last modified: 2024-07-19 11:56:46 UTC
In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free in do_zone_finish() Shinichiro reported the following use-after-free triggered by the device replace operation in fstests btrfs/070. BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0 ================================================================== BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs] Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007 CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G W 6.8.0-rc5-kts #1 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0x200/0x3e0 kasan_report+0xd8/0x110 ? do_zone_finish+0x91a/0xb90 [btrfs] ? do_zone_finish+0x91a/0xb90 [btrfs] do_zone_finish+0x91a/0xb90 [btrfs] btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs] ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs] ? btrfs_put_root+0x2d/0x220 [btrfs] ? btrfs_clean_one_deleted_snapshot+0x299/0x430 [btrfs] cleaner_kthread+0x21e/0x380 [btrfs] ? __pfx_cleaner_kthread+0x10/0x10 [btrfs] kthread+0x2e3/0x3c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Allocated by task 3493983: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 btrfs_alloc_device+0xb3/0x4e0 [btrfs] device_list_add.constprop.0+0x993/0x1630 [btrfs] btrfs_scan_one_device+0x219/0x3d0 [btrfs] btrfs_control_ioctl+0x26e/0x310 [btrfs] __x64_sys_ioctl+0x134/0x1b0 do_syscall_64+0x99/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Freed by task 3494056: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3f/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x32/0x70 kfree+0x11b/0x320 btrfs_rm_dev_replace_free_srcdev+0xca/0x280 [btrfs] btrfs_dev_replace_finishing+0xd7e/0x14f0 [btrfs] btrfs_dev_replace_by_ioctl+0x1286/0x25a0 [btrfs] btrfs_ioctl+0xb27/0x57d0 [btrfs] __x64_sys_ioctl+0x134/0x1b0 do_syscall_64+0x99/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 The buggy address belongs to the object at ffff8881543c8000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 96 bytes inside of freed 1024-byte region [ffff8881543c8000, ffff8881543c8400) The buggy address belongs to the physical page: page:00000000fe2c1285 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1543c8 head:00000000fe2c1285 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x17ffffc0000840(slab|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 0017ffffc0000840 ffff888100042dc0 ffffea0019e8f200 dead000000000002 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881543c7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8881543c7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8881543c8000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881543c8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881543c8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb This UAF happens because we're accessing stale zone information of a already removed btrfs_device in do_zone_finish(). The sequence of events is as follows: btrfs_dev_replace_start btrfs_scrub_dev btrfs_dev_replace_finishing btrfs_dev_replace_update_device_in_mapping_tree <-- devices replaced btrfs_rm_dev_replace_free_srcdev btrfs_free_device <-- device freed cleaner_kthread btrfs_delete_unused_bgs btrfs_zone_finish do_zone_finish <-- refers the freed device The reason for this is that we're using a ---truncated--- References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-26944 https://www.cve.org/CVERecord?id=CVE-2024-26944 https://git.kernel.org/stable/c/1ec17ef59168a1a6f1105f5dc517f783839a5302 https://git.kernel.org/stable/c/34ca809e055eca5cfe63d9c7efbf80b7c21b4e57 https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2024/CVE-2024-26944.mbox https://bugzilla.redhat.com/show_bug.cgi?id=2278210
This is for zoned btrfs only. Do we actually support zoned filesystems on any SLE releases?
(In reply to Filipe Manana from comment #3) > This is for zoned btrfs only. Do we actually support zoned filesystems on > any SLE releases? No we don't. We don't support zoned for TW either, though it may be enabled in the future. Fix is recommended but not mandatory.
I did a deeper check. The patch is relevant for v6.8 as indicated in the patch. The btrfs_block_group structure did not have physical_map variable, access to which shows up in the stack trace. I am not sure if dev_replace.rwsem will be of any help.
(In reply to Goldwyn Rodrigues from comment #7) > I did a deeper check. The patch is relevant for v6.8 as indicated in the Don't always guide by the version tagged in the CC stable line. It's 6.8 because the backport is simple against 6.8 but complex and a lot of work for anything below it (see below why). > patch. The btrfs_block_group structure did not have physical_map variable, Are you sure? Which branch were you looking at? It exists in both SLE15-SP6 and SLE15-SP5, just like in upstream kernels 6.4 and 5.18. For SLE15-SP6: https://github.com/SUSE/kernel/blob/SLE15-SP6/fs/btrfs/zoned.c#L1321 > access to which shows up in the stack trace. > > I am not sure if dev_replace.rwsem will be of any help. The use of the semaphore is precisely to have safe access to the ->physical_map member of a block group. The problem with this patch is that it has a lot of dependencies. In SLE kernels the physical_map is not reference counted, and I don't see a good way to solve it without making it reference counted, which happened in the following large patch from upstream (landed in kernel 6.8): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7dc66abb5a47778d7db327783a0ba172b8cff0b5 So adapting the fix to SLE15-SP6 without that change would result in code very different from what we have upstream, and make future backports diverging more and more. Now that's an important change I would like to have in SLE15-SP6, since it would facilitate a lot of future backports. But in order to do it, it needs the backport of several other fixes, cleanups and refactorings. I've been doing it and so far there's really a lot of patches, some of them quite large, so far 50 patches, which are: commit b5345d6ceeee3ef378e4800f538c8fc06bf9de48 6.5-rc1 Author: Naohiro Aota <naota@elisp.net> Date: Wed Apr 26 00:19:40 2023 +0900 btrfs: export bitmap_test_range_all_{set,zero} commit f880fe6e0b4b127d6e2a007fe68bdf5651677ae2 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Mon May 8 07:58:39 2023 -0700 btrfs: don't hold an extra reference for redirtied buffers commit adbe7e388e4239d9c1754d475aea791136927137 6.5-rc1 Author: Anand Jain <anand.jain@oracle.com> Date: Sat Apr 15 19:32:38 2023 +0800 btrfs: use SECTOR_SHIFT to convert LBA to physical offset commit dd8b7b0416704efb0dcd74801a1a48aa221f1cf5 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 24 17:03:04 2023 +0200 btrfs: optimize out btrfs_is_zoned for !CONFIG_BLK_DEV_ZONED commit e9cb93b9fbd0bfcef2774e82d095362ad16acf6e 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 24 17:03:05 2023 +0200 btrfs: don't call btrfs_record_physical_zoned for failed append commit 6e4b2479ab38b3f949a85964da212295d32102f0 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 24 17:03:06 2023 +0200 btrfs: mark the len field in struct btrfs_ordered_sum as unsigned commit 5cfe76f846d5034058c0c4813259d5d831757c36 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 24 17:03:07 2023 +0200 btrfs: rename the bytenr field in struct btrfs_ordered_sum to logical commit cbfce4c7fbde23cc8bcba44822a58c728caf6ec9 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 24 17:03:08 2023 +0200 btrfs: optimize the logical to physical mapping for zoned writes commit 3887653c44ec1de089b8624bd53af05b946939e9 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Fri Jun 9 07:27:04 2023 +0200 btrfs: record orig_physical only for the original bio commit a6f3e205e4916e4f29ce2c4c38d520616e6b0080 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 24 17:03:09 2023 +0200 btrfs: move split_extent_map to extent_map.c commit ebdb44a00e257641a398fe2484ba9c65a03beea1 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 24 17:03:10 2023 +0200 btrfs: reorder conditions in btrfs_extract_ordered_extent commit b0307e28642efa3bcc6353b9af213711f6d3848e 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 24 17:03:11 2023 +0200 btrfs: return the new ordered_extent from btrfs_split_ordered_extent commit 53d9981ca20efcded0f6cf6b480d713f490ca9f1 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 24 17:03:13 2023 +0200 btrfs: split btrfs_alloc_ordered_extent to allocation and insertion helpers commit 816f589b8d43f7c258b0c10a5ce29daf01614651 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 24 17:03:14 2023 +0200 btrfs: atomically insert the new extent in btrfs_split_ordered_extent commit 52b1fdca23ac0fbcad363a1a5b426bf0d56b715a 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 24 17:03:15 2023 +0200 btrfs: handle completed ordered extents in btrfs_split_ordered_extent commit 71df088c1cc090d232eb691d8f42284a2c6409eb 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 24 17:03:16 2023 +0200 btrfs: defer splitting of ordered extents until I/O completion commit 71df088c1cc090d232eb691d8f42284a2c6409eb 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 24 17:03:16 2023 +0200 btrfs: defer splitting of ordered extents until I/O completion commit f000bc6fe43ce66c55fa1691000115b14ba95b33 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 24 17:03:17 2023 +0200 btrfs: pass the new logical address to split_extent_map commit 3965a4c793d3b031119ff455c4773441584aee30 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 31 06:17:34 2023 +0200 btrfs: remove unused BTRFS_MAP_DISCARD commit 78a213a05df3510200331bfcc232bf0278c6ed50 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 31 06:17:35 2023 +0200 btrfs: optimize simple reads in btrfsic_map_block commit d69d7ffc26f10d7be3768a6762809c57f6443a43 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 31 06:17:36 2023 +0200 btrfs: remove unused btrfs_map_block commit cd4efd210edfb34f8cec3a0184899af751dc2d71 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 31 06:17:37 2023 +0200 btrfs: rename __btrfs_map_block to btrfs_map_block commit 723b8bb17e2e680934f59823ab1e72c1000d88d6 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 31 06:17:38 2023 +0200 btrfs: open code btrfs_map_sblock commit 8680e58761eba8ea3552146ea005be30dfed2948 6.5-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Wed May 31 06:17:39 2023 +0200 btrfs: open code need_full_stripe conditions commit 07a3bb95ea1f7fa77e360cf3b0f06dff41dbf391 6.6-rc1 Author: Julia Lawall <Julia.Lawall@inria.fr> Date: Fri Jun 23 23:14:43 2023 +0200 btrfs: zoned: use vcalloc instead of for vzalloc in btrfs_get_dev_zone_info commit 861093eff4f01319edfc1d1ee276a7f2bf720f1d 6.6-rc1 Author: Naohiro Aota <naohiro.aota@wdc.com> Date: Tue Aug 8 01:12:31 2023 +0900 btrfs: introduce struct to consolidate extent buffer write context commit 7db94301a980c9da4168ac7ce61e7bde297306ba 6.6-rc1 Author: Naohiro Aota <naohiro.aota@wdc.com> Date: Tue Aug 8 01:12:32 2023 +0900 btrfs: zoned: introduce block group context to btrfs_eb_write_context commit 2ad8c0510a965113404cfe670b41ddc34fb66100 6.6-rc1 Author: Naohiro Aota <naohiro.aota@wdc.com> Date: Tue Aug 8 01:12:33 2023 +0900 btrfs: zoned: return int from btrfs_check_meta_write_pointer commit 0356ad41e0ddb8cf0ea4d68820c92598413e445b 6.6-rc1 Author: Naohiro Aota <naohiro.aota@wdc.com> Date: Tue Aug 8 01:12:34 2023 +0900 btrfs: zoned: defer advancing meta write pointer commit c1c3c2bc2917d09bbb19cb9894ba5950254b9502 6.6-rc1 Author: Naohiro Aota <naohiro.aota@wdc.com> Date: Tue Aug 8 01:12:35 2023 +0900 btrfs: zoned: update meta write pointer on zone finish commit a7e1ac7bdc5af91af2d52e6269fdbd92fe9ee353 6.6-rc1 Author: Naohiro Aota <naohiro.aota@wdc.com> Date: Tue Aug 8 01:12:36 2023 +0900 btrfs: zoned: reserve zones for an active metadata/system block group commit 13bb483d32abb6f8ebd40141d87eb68f11cc2dd2 6.6-rc1 Author: Naohiro Aota <naohiro.aota@wdc.com> Date: Tue Aug 8 01:12:37 2023 +0900 btrfs: zoned: activate metadata block group on write time commit 6a8ebc773ef64c8f12d6d60fd6e53d5ccc81314b 6.6-rc1 Author: Naohiro Aota <naohiro.aota@wdc.com> Date: Tue Aug 8 01:12:38 2023 +0900 btrfs: zoned: no longer count fresh BG region as zone unusable commit 5a7d107e5ef9b452cf0aa96ac931b29ea980d997 6.6-rc1 Author: Naohiro Aota <naohiro.aota@wdc.com> Date: Tue Aug 8 01:12:39 2023 +0900 btrfs: zoned: don't activate non-DATA BG on allocation commit 5b135b382a360f4c87cf8896d1465b0b07f10cb0 6.6-rc1 Author: Naohiro Aota <naohiro.aota@wdc.com> Date: Tue Aug 8 01:12:40 2023 +0900 btrfs: zoned: re-enable metadata over-commit for zoned mode commit 332581bde2a419d5f12a93a1cdc2856af649a3cc 6.6-rc1 Author: Naohiro Aota <naohiro.aota@wdc.com> Date: Fri Jul 21 16:42:14 2023 +0900 btrfs: zoned: do not zone finish data relocation block group commit c02d35d89b317994bd713ba82e160c5e7f22d9c8 6.6-rc1 Author: Naohiro Aota <naohiro.aota@wdc.com> Date: Sat Aug 19 01:26:07 2023 +0900 btrfs: zoned: skip splitting and logical rewriting on pre-alloc write commit ed3764f726b24099396734aa1a5b41ae7e0fac60 6.6-rc1 Author: Qu Wenruo <wqu@suse.com> Date: Tue Jun 27 15:34:31 2023 +0800 btrfs: add comments for btrfs_map_block() commit 9fb2acc2fe07f15b6cfe94a4bf910d3dfcd6e127 6.7-rc1 Author: Qu Wenruo <wqu@suse.com> Date: Sun Sep 17 19:36:21 2023 +0930 btrfs: remove the need_raid_map parameter from btrfs_map_block() commit 15c12fcc50a1b12a747f8b6ec05cdb18c537a4d1 6.7-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Mon Jun 5 10:51:05 2023 +0200 btrfs: zoned: introduce a zone_info struct in btrfs_load_block_group_zone_info commit 09a46725cc84165af452d978a3532d6b97a28796 6.7-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Mon Jun 5 10:51:06 2023 +0200 btrfs: zoned: factor out per-zone logic from btrfs_load_block_group_zone_info commit 9e0e3e74dc6928a0956f4e27e24d473c65887e96 6.7-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Mon Jun 5 10:51:07 2023 +0200 btrfs: zoned: factor out single bg handling from btrfs_load_block_group_zone_info commit 87463f7e0250d471fac41e7c9c45ae21d83b5f85 6.7-rc1 Author: Christoph Hellwig <hch@lst.de> Date: Mon Jun 5 10:51:08 2023 +0200 btrfs: zoned: factor out DUP bg handling from btrfs_load_block_group_zone_info commit 7dc66abb5a47778d7db327783a0ba172b8cff0b5 6.8-rc1 Author: Filipe Manana <fdmanana@suse.com> Date: Tue Nov 21 13:38:38 2023 +0000 btrfs: use a dedicated data structure for chunk maps commit 71fca47b644910485c49d1da31bc963cf286fe77 6.8-rc1 Author: Filipe Manana <fdmanana@suse.com> Date: Tue Nov 21 13:38:39 2023 +0000 btrfs: remove stripe size local variable from insert_dev_extents() commit d967c914a633ee797255261808720f791b658f24 6.8-rc2 Author: Naohiro Aota <naohiro.aota@wdc.com> Date: Fri Dec 22 01:46:16 2023 +0900 btrfs: fix unbalanced unlock of mapping_tree_lock commit 88e81a67773017a2b93f6d5fe7c78bb0c5a6e4dd 6.8-rc5 Author: Filipe Manana <fdmanana@suse.com> Date: Mon Feb 12 21:50:53 2024 +0000 btrfs: zoned: fix chunk map leak when loading block group zone info commit 1ec17ef59168a1a6f1105f5dc517f783839a5302 6.9-rc2 Author: Johannes Thumshirn <johannes.thumshirn@wdc.com> Date: Wed Feb 28 12:13:27 2024 +0100 btrfs: zoned: fix use-after-free in do_zone_finish() commit cebae292e0c32a228e8f2219c270a7237be24a6a 6.10-rc5 Author: Johannes Thumshirn <johannes.thumshirn@wdc.com> Date: Fri Jun 7 13:27:48 2024 +0200 btrfs: zoned: allocate dummy checksums for zoned NODATASUM writes And this is SLE15-SP6. What do we do about SLE15-SP5? And can we get it clear if we are going to support btrfs on zoned devices for SLE15-SP6, or SP5? There are more CVE fixes for zoned mode coming in, and they depend on previous fixes we don't have. There's also quite a lot of zoned fixes coming in frequently upstream, and that requires extra work which is very hard to find time for, considering the swarm of other CVEs and non-CVE fixes. Goldwyn?
(In reply to Filipe Manana from comment #8) > (In reply to Goldwyn Rodrigues from comment #7) > > I did a deeper check. The patch is relevant for v6.8 as indicated in the > > Don't always guide by the version tagged in the CC stable line. > It's 6.8 because the backport is simple against 6.8 but complex and a lot of > work for anything below it (see below why). > > > patch. The btrfs_block_group structure did not have physical_map variable, > > Are you sure? Which branch were you looking at? > It exists in both SLE15-SP6 and SLE15-SP5, just like in upstream kernels 6.4 > and 5.18. Looks like I tried SLE15-SP5 and it does not have the physical_map variable. > > For SLE15-SP6: > > https://github.com/SUSE/kernel/blob/SLE15-SP6/fs/btrfs/zoned.c#L1321 > > > access to which shows up in the stack trace. > > > > I am not sure if dev_replace.rwsem will be of any help. > > The use of the semaphore is precisely to have safe access to the > ->physical_map member of a block group. > > The problem with this patch is that it has a lot of dependencies. > In SLE kernels the physical_map is not reference counted, and I don't see a > good way to solve it without making it reference counted, which happened in > the following large patch from upstream (landed in kernel 6.8): > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=7dc66abb5a47778d7db327783a0ba172b8cff0b5 > > So adapting the fix to SLE15-SP6 without that change would result in code > very different from what we have upstream, and make future backports > diverging more and more. > > Now that's an important change I would like to have in SLE15-SP6, since it > would facilitate a lot of future backports. > > But in order to do it, it needs the backport of several other fixes, > cleanups and refactorings. I've been doing it and so far there's really a > lot of patches, some of them quite large, so far 50 patches, which are: > <snipped> > > And this is SLE15-SP6. This is quite a long list and the risk of adding so much code inadvertently introducing bugs is high. This is not worth a feature which we do not support. > > What do we do about SLE15-SP5? > > And can we get it clear if we are going to support btrfs on zoned devices > for SLE15-SP6, or SP5? There are more CVE fixes for zoned mode coming in, > and they depend on previous fixes we don't have. There's also quite a lot of > zoned fixes coming in frequently upstream, and that requires extra work > which is very hard to find time for, considering the swarm of other CVEs and > non-CVE fixes. > > Goldwyn? Zoned devices is not supported for SLE15SP6. We will put a warning in btrfsprogs/mkfs to warn when the user creates a filesystem with zoned support.
(In reply to Goldwyn Rodrigues from comment #9) > (In reply to Filipe Manana from comment #8) > > (In reply to Goldwyn Rodrigues from comment #7) > > > I did a deeper check. The patch is relevant for v6.8 as indicated in the > > > > Don't always guide by the version tagged in the CC stable line. > > It's 6.8 because the backport is simple against 6.8 but complex and a lot of > > work for anything below it (see below why). > > > > > patch. The btrfs_block_group structure did not have physical_map variable, > > > > Are you sure? Which branch were you looking at? > > It exists in both SLE15-SP6 and SLE15-SP5, just like in upstream kernels 6.4 > > and 5.18. > > Looks like I tried SLE15-SP5 and it does not have the physical_map variable. > > > > > For SLE15-SP6: > > > > https://github.com/SUSE/kernel/blob/SLE15-SP6/fs/btrfs/zoned.c#L1321 > > > > > access to which shows up in the stack trace. > > > > > > I am not sure if dev_replace.rwsem will be of any help. > > > > The use of the semaphore is precisely to have safe access to the > > ->physical_map member of a block group. > > > > The problem with this patch is that it has a lot of dependencies. > > In SLE kernels the physical_map is not reference counted, and I don't see a > > good way to solve it without making it reference counted, which happened in > > the following large patch from upstream (landed in kernel 6.8): > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > > ?id=7dc66abb5a47778d7db327783a0ba172b8cff0b5 > > > > So adapting the fix to SLE15-SP6 without that change would result in code > > very different from what we have upstream, and make future backports > > diverging more and more. > > > > Now that's an important change I would like to have in SLE15-SP6, since it > > would facilitate a lot of future backports. > > > > But in order to do it, it needs the backport of several other fixes, > > cleanups and refactorings. I've been doing it and so far there's really a > > lot of patches, some of them quite large, so far 50 patches, which are: > > > > <snipped> > > > > > And this is SLE15-SP6. > > This is quite a long list and the risk of adding so much code inadvertently > introducing bugs is high. This is not worth a feature which we do not > support. Yes, but as I said in the team meeting, backporting all these (and now they are 64 patches), is a good thing to do because it makes the code much more close to upstream and facilitates backports of other fixes. That's why I have been spending the last few days working on the backports, which I've just pushed to git (branch users/fdmanana/SLE15-SP6/for-next). > > > > > What do we do about SLE15-SP5? > > > > And can we get it clear if we are going to support btrfs on zoned devices > > for SLE15-SP6, or SP5? There are more CVE fixes for zoned mode coming in, > > and they depend on previous fixes we don't have. There's also quite a lot of > > zoned fixes coming in frequently upstream, and that requires extra work > > which is very hard to find time for, considering the swarm of other CVEs and > > non-CVE fixes. > > > > Goldwyn? > > Zoned devices is not supported for SLE15SP6. We will put a warning in > btrfsprogs/mkfs to warn when the user creates a filesystem with zoned > support.