6.12.7-rc1 review
Subsystems (3)
Greg Kroah-Hartman
maintainerPATCH 145/160 udmabuf: fix racy memfd sealing check
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jann Horn <[email protected]>
commit 9cb189a882738c1d28b349d4e7c6a1ef9b3d8f87 upstream.
The current check_memfd_seals() is racy: Since we first do check_memfd_seals() and then udmabuf_pin_folios() without holding any relevant lock across both, F_SEAL_WRITE can be set in between. This is problematic because we can end up holding pins to pages in a write-sealed memfd.
Fix it using the inode lock, that's probably the easiest way. In the future, we might want to consider moving this logic into memfd, especially if anyone else wants to use memfd_pin_folios().
--- drivers/dma-buf/udmabuf.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
drivers/dma-buf/udmabuf.c +9 -4
@@ -394,14 +394,19 @@ static long udmabuf_create(struct miscde goto err; } +/* +* Take the inode lock to protect against concurrent +* memfd_add_seals(), which takes this lock in write mode. +*/ +inode_lock_shared (file_inode (memfd)); ret =check_memfd_seals (memfd); -if (ret <0 ) { -fput (memfd); - goto err; - } +if (ret) + goto out_unlock; ret =udmabuf_pin_folios (ubuf, memfd, list[i].offset, list[i].size); +out_unlock: +inode_unlock_shared (file_inode (memfd));fput (memfd);if (ret) goto err;
Greg Kroah-Hartman
maintainerPATCH 146/160 udmabuf: also check for F_SEAL_FUTURE_WRITE
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jann Horn <[email protected]>
commit 0a16e24e34f28210f68195259456c73462518597 upstream.
When F_SEAL_FUTURE_WRITE was introduced, it was overlooked that udmabuf must reject memfds with this flag, just like ones with F_SEAL_WRITE. Fix it by adding F_SEAL_FUTURE_WRITE to SEALS_DENIED.
--- drivers/dma-buf/udmabuf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/dma-buf/udmabuf.c +1 -1
@@ -256,7 +256,7 @@ static const struct dma_buf_ops udmabuf_ };#define SEALS_WANTED (F_SEAL_SHRINK) -#define SEALS_DENIED (F_SEAL_WRITE) +#define SEALS_DENIED (F_SEAL_WRITE|F_SEAL_FUTURE_WRITE)static int check_memfd_seals (struct file *memfd) {
Greg Kroah-Hartman
maintainerPATCH 147/160 of: property: fw_devlink: Do not use interrupt-parent directly
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Samuel Holland <[email protected]>
commit bc7acc0bd0f94c26bc0defc902311794a3d0fae9 upstream.
commit 7f00be96f125 ("of: property: Add device link support for interrupt-parent, dmas and -gpio(s)") started adding device links for the interrupt-parent property. commit 4104ca776ba3 ("of: property: Add fw_devlink support for interrupts") and commit f265f06af194 ("of:
property: Fix fw_devlink handling of interrupts/interrupts-extended") later added full support for parsing the interrupts and interrupts-extended properties, which includes looking up the node of the parent domain. This made the handler for the interrupt-parent property redundant.
In fact, creating device links based solely on interrupt-parent is problematic, because it can create spurious cycles. A node may have this property without itself being an interrupt controller or consumer. For example, this property is often present in the root node or a /soc bus node to set the default interrupt parent for child nodes. However, it is incorrect for the bus to depend on the interrupt controller, as some of the bus's children may not be interrupt consumers at all or may have a different interrupt parent.
Resolving these spurious dependency cycles can cause an incorrect probe order for interrupt controller drivers. This was observed on a RISC-V system with both an APLIC and IMSIC under /soc, where interrupt-parent in /soc points to the APLIC, and the APLIC msi-parent points to the IMSIC. fw_devlink found three dependency cycles and attempted to probe the APLIC before the IMSIC. After applying this patch, there were no dependency cycles and the probe order was correct.
--- drivers/of/property.c | 2 -- 1 file changed, 2 deletions(-)
drivers/of/property.c +0 -2
@@ -1213,7 +1213,6 @@ DEFINE_SIMPLE_PROP(iommus, "iommus", "#i DEFINE_SIMPLE_PROP(mboxes, "mboxes", "#mbox-cells") DEFINE_SIMPLE_PROP(io_channels, "io-channels", "#io-channel-cells") DEFINE_SIMPLE_PROP(io_backends, "io-backends", "#io-backend-cells") -DEFINE_SIMPLE_PROP(interrupt_parent, "interrupt-parent", NULL) DEFINE_SIMPLE_PROP(dmas, "dmas", "#dma-cells") DEFINE_SIMPLE_PROP(power_domains, "power-domains", "#power-domain-cells")DEFINE_SIMPLE_PROP (hwlocks,"hwlocks" ,"#hwlock-cells" )
@@ -1359,7 +1358,6 @@ static const struct supplier_bindings of { .parse_prop = parse_mboxes, }, { .parse_prop = parse_io_channels, }, { .parse_prop = parse_io_backends, }, - { .parse_prop = parse_interrupt_parent, }, { .parse_prop = parse_dmas, .optional = true, }, { .parse_prop = parse_power_domains, }, { .parse_prop = parse_hwlocks, },
Greg Kroah-Hartman
maintainerPATCH 148/160 of: address: Preserve the flags portion on 1:1 dma-ranges mapping
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrea della Porta <[email protected]>
commit 7f05e20b989ac33c9c0f8c2028ec0a566493548f upstream.
A missing or empty dma-ranges in a DT node implies a 1:1 mapping for dma translations. In this specific case, the current behaviour is to zero out the entire specifier so that the translation could be carried on as an offset from zero. This includes address specifier that has flags (e.g. PCI ranges).
Once the flags portion has been zeroed, the translation chain is broken since the mapping functions will check the upcoming address specifier against mismatching flags, always failing the 1:1 mapping and its entire purpose of always succeeding.
Set to zero only the address portion while passing the flags through.
--- drivers/of/address.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/of/address.c +2 -1
@@ -455,7 +455,8 @@ static int of_translate_one(struct devic }if (ranges ==NULL || rlen ==0 ) { offset =of_read_number (addr, na); -memset (addr,0 , pna *4 ); +/* set address to zero, pass flags through */ +memset (addr + pbus->flag_cells,0 , (pna - pbus->flag_cells) *4 );pr_debug ("empty ranges; 1:1 translation\n" ); goto finish; }
Greg Kroah-Hartman
maintainerPATCH 149/160 of: Fix error path in of_parse_phandle_with_args_map()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Herve Codina <[email protected]>
commit d7dfa7fde63dde4d2ec0083133efe2c6686c03ff upstream.
The current code uses some 'goto put;' to cancel the parsing operation and can lead to a return code value of 0 even on error cases.
Indeed, some goto calls are done from a loop without setting the ret value explicitly before the goto call and so the ret value can be set to 0 due to operation done in previous loop iteration. For instance match can be set to 0 in the previous loop iteration (leading to a new iteration) but ret can also be set to 0 it the of_property_read_u32() call succeed. In that case if no match are found or if an error is detected the new iteration, the return value can be wrongly 0.
Avoid those cases setting the ret value explicitly before the goto calls.
--- drivers/of/base.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-)
drivers/of/base.c +10 -5
@@ -1455,8 +1455,10 @@ int of_parse_phandle_with_args_map(const map_len--;/* Check if not found */ -if (!new) +if (!new) { + ret = -EINVAL ; goto put; + }if (!of_device_is_available (new)) match =0 ;
@@ -1466,17 +1468,20 @@ int of_parse_phandle_with_args_map(const goto put;/* Check for malformed properties */ -if (WARN_ON (new_size >MAX_PHANDLE_ARGS )) - goto put; -if (map_len < new_size) +if (WARN_ON (new_size >MAX_PHANDLE_ARGS ) || + map_len < new_size) { + ret = -EINVAL ; goto put; + }/* Move forward by new node's #<list>-cells amount */ map += new_size; map_len -= new_size; } -if (!match) +if (!match) { + ret = -ENOENT ; goto put; + }/* Get the <list>-map-pass-thru property (optional) */ pass =of_get_property (cur, pass_name,NULL );
Greg Kroah-Hartman
maintainerPATCH 150/160 of: Fix refcount leakage for OF node returned by __of_get_dma_parent()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zijun Hu <[email protected]>
commit 5d009e024056ded20c5bb1583146b833b23bbd5a upstream.
__of_get_dma_parent() returns OF device node @args.np, but the node's refcount is increased twice, by both of_parse_phandle_with_args() and of_node_get(), so causes refcount leakage for the node.
Fix by directly returning the node got by of_parse_phandle_with_args().
--- drivers/of/address.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/of/address.c +1 -1
@@ -616,7 +616,7 @@ struct device_node *__of_get_dma_parent(if (ret <0 )return of_get_parent (np); - return of_node_get(args.np); + return args.np; }#endif
Greg Kroah-Hartman
maintainerPATCH 151/160 ceph: give up on paths longer than PATH_MAX
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Max Kellermann <[email protected]>
commit 550f7ca98ee028a606aa75705a7e77b1bd11720f upstream.
If the full path to be built by ceph_mdsc_build_path() happens to be longer than PATH_MAX, then this function will enter an endless (retry) loop, effectively blocking the whole task. Most of the machine becomes unusable, making this a very simple and effective DoS vulnerability.
I cannot imagine why this retry was ever implemented, but it seems rather useless and harmful to me. Let's remove it and fail with ENAMETOOLONG instead.
--- fs/ceph/mds_client.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
fs/ceph/mds_client.c +4 -5
@@ -2808,12 +2808,11 @@ retry:if (pos <0 ) {/* -* A rename didn't occur, but somehow we didn't end up where -* we thought we would. Throw a warning and try again. +* The path is longer than PATH_MAX and this function +* cannot ever succeed. Creating paths that long is +* possible with Ceph, but Linux cannot use them. */ -pr_warn_client (cl,"did not end path lookup where expected (pos = %d)\n" , - pos); - goto retry; +return ERR_PTR (-ENAMETOOLONG ); } *pbase = base;
Greg Kroah-Hartman
maintainerPATCH 152/160 ceph: validate snapdirname option length when mounting
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilya Dryomov <[email protected]>
commit 12eb22a5a609421b380c3c6ca887474fb2089b2c upstream.
It becomes a path component, so it shouldn't exceed NAME_MAX characters. This was hardened in commit c152737be22b ("ceph: Use strscpy() instead of strcpy() in __get_snap_name()"), but no actual check was put in place.
--- fs/ceph/super.c | 2 ++ 1 file changed, 2 insertions(+)
fs/ceph/super.c +2 -0
@@ -431,6 +431,8 @@ static int ceph_parse_mount_param(structswitch (token) {case Opt_snapdirname: +if (strlen (param->string) >NAME_MAX ) +return invalfc (fc,"snapdirname too long" );kfree (fsopt->snapdir_name); fsopt->snapdir_name = param->string; param->string =NULL ;
Greg Kroah-Hartman
maintainerPATCH 153/160 ceph: improve error handling and short/overflow-read logic in __ceph_sync_read()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Markuze <[email protected]>
commit 9abee475803fab6ad59d4f4fc59c6a75374a7d9d upstream.
This patch refines the read logic in __ceph_sync_read() to ensure more predictable and efficient behavior in various edge cases.
- Return early if the requested read length is zero or if the file size (i_size) is zero.
- Initialize the index variable (idx) where needed and reorder some code to ensure it is always set before use.
- Improve error handling by checking for negative return values earlier.
- Remove redundant encrypted file checks after failures. Only attempt filesystem-level decryption if the read succeeded.
- Simplify leftover calculations to correctly handle cases where the read extends beyond the end of the file or stops short. This can be hit by continuously reading a file while, on another client, we keep truncating and writing new data into it.
- This resolves multiple issues caused by integer and consequent buffer overflow (pages array being accessed beyond num_pages):
- https://tracker.ceph.com/issues/67524
- https://tracker.ceph.com/issues/68980
- https://tracker.ceph.com/issues/68981
--- fs/ceph/file.c | 29 ++++++++++++++--------------- 1 file changed, 14 insertions(+), 15 deletions(-)
fs/ceph/file.c +14 -15
@@ -1066,7 +1066,7 @@ ssize_t __ceph_sync_read(struct inode *iif (ceph_inode_is_shutdown (inode))return -EIO ; -if (!len) +if (!len || !i_size)return 0 ;/* * flush any page cache pages in this range. this
@@ -1086,7 +1086,7 @@ ssize_t __ceph_sync_read(struct inode *iint num_pages;size_t page_off;bool more; -int idx; +int idx =0 ;size_t left;struct ceph_osd_req_op *op;u64 read_off = off;
@@ -1160,7 +1160,14 @@ ssize_t __ceph_sync_read(struct inode *ielse if (ret == -ENOENT ) ret =0 ; -if (ret >0 &&IS_ENCRYPTED (inode)) { +if (ret <0 ) { +ceph_osdc_put_request (req); +if (ret == -EBLOCKLISTED ) + fsc->blocklisted = true; +break ; + } + +if (IS_ENCRYPTED (inode)) {int fret; fret = ceph_fscrypt_decrypt_extents(inode, pages,
@@ -1189,7 +1196,7 @@ ssize_t __ceph_sync_read(struct inode *iceph_osdc_put_request (req);/* Short read but not EOF? Zero out the remainder. */ -if (ret >=0 && ret < len && (off + ret < i_size)) { +if (ret < len && (off + ret < i_size)) {int zlen =min (len - ret, i_size - off - ret);int zoff = page_off + ret;
@@ -1199,13 +1206,11 @@ ssize_t __ceph_sync_read(struct inode *i ret += zlen; } - idx =0 ; -if (ret <=0 ) - left =0 ; -else if (off + ret > i_size) - left = i_size - off; +if (off + ret > i_size) + left = (i_size > off) ? i_size - off :0 ;else left = ret; +while (left >0 ) {size_t plen, copied;
@@ -1223,12 +1228,6 @@ ssize_t __ceph_sync_read(struct inode *i }ceph_release_page_vector (pages, num_pages); -if (ret <0 ) { -if (ret == -EBLOCKLISTED ) - fsc->blocklisted = true; -break ; - } -if (off >= i_size || !more)break ; }
Greg Kroah-Hartman
maintainerPATCH 154/160 ceph: fix memory leaks in __ceph_sync_read()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Max Kellermann <[email protected]>
commit d6fd6f8280f0257ba93f16900a0d3d3912f32c79 upstream.
In two break statements, the call to ceph_release_page_vector() was missing, leaking the allocation from ceph_alloc_page_vector().
Instead of adding the missing ceph_release_page_vector() calls, the Ceph maintainers preferred to transfer page ownership to the ceph_osd_request by passing own_pages=true to osd_req_op_extent_osd_data_pages(). This requires postponing the ceph_osdc_put_request() call until after the block that accesses the pages.
--- fs/ceph/file.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
fs/ceph/file.c +3 -4
@@ -1127,7 +1127,7 @@ ssize_t __ceph_sync_read(struct inode *iosd_req_op_extent_osd_data_pages (req,0 , pages, read_len,offset_in_page (read_off), - false, false); + false, true); op = &req->r_ops[0 ];if (sparse) {
@@ -1193,8 +1193,6 @@ ssize_t __ceph_sync_read(struct inode *i ret =min_t (ssize_t, fret, len); } -ceph_osdc_put_request (req); -/* Short read but not EOF? Zero out the remainder. */ if (ret < len && (off + ret < i_size)) {int zlen =min (len - ret, i_size - off - ret);
@@ -1226,7 +1224,8 @@ ssize_t __ceph_sync_read(struct inode *ibreak ; } } -ceph_release_page_vector (pages, num_pages); + +ceph_osdc_put_request (req);if (off >= i_size || !more)break ;
Greg Kroah-Hartman
maintainerPATCH 155/160 ceph: fix memory leak in ceph_direct_read_write()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilya Dryomov <[email protected]>
commit 66e0c4f91461d17d48071695271c824620bed4ef upstream.
The bvecs array which is allocated in iter_get_bvecs_alloc() is leaked and pages remain pinned if ceph_alloc_sparse_ext_map() fails.
There is no need to delay the allocation of sparse_ext map until after the bvecs array is set up, so fix this by moving sparse_ext allocation a bit earlier. Also, make a similar adjustment in __ceph_sync_read() for consistency (a leak of the same kind in __ceph_sync_read() has been addressed differently).
--- fs/ceph/file.c | 43 ++++++++++++++++++++++--------------------- 1 file changed, 22 insertions(+), 21 deletions(-)
fs/ceph/file.c +22 -21
@@ -1116,6 +1116,16 @@ ssize_t __ceph_sync_read(struct inode *i len = read_off + read_len - off; more = len <iov_iter_count (to); + op = &req->r_ops[0 ]; +if (sparse) { + extent_cnt =__ceph_sparse_read_ext_count (inode, read_len); + ret =ceph_alloc_sparse_ext_map (op, extent_cnt); +if (ret) { +ceph_osdc_put_request (req); +break ; + } + } + num_pages =calc_pages_for (read_off, read_len); page_off =offset_in_page (off); pages =ceph_alloc_page_vector (num_pages,GFP_KERNEL );
@@ -1129,16 +1139,6 @@ ssize_t __ceph_sync_read(struct inode *ioffset_in_page (read_off), false, true); - op = &req->r_ops[0 ]; -if (sparse) { - extent_cnt =__ceph_sparse_read_ext_count (inode, read_len); - ret =ceph_alloc_sparse_ext_map (op, extent_cnt); -if (ret) { -ceph_osdc_put_request (req); -break ; - } - } -ceph_osdc_start_request (osdc, req); ret =ceph_osdc_wait_request (osdc, req);
@@ -1551,6 +1551,16 @@ ceph_direct_read_write(struct kiocb *iocbreak ; } + op = &req->r_ops[0 ]; +if (sparse) { + extent_cnt =__ceph_sparse_read_ext_count (inode, size); + ret =ceph_alloc_sparse_ext_map (op, extent_cnt); +if (ret) { +ceph_osdc_put_request (req); +break ; + } + } + len =iter_get_bvecs_alloc (iter, size, &bvecs, &num_pages);if (len <0 ) {ceph_osdc_put_request (req);
@@ -1560,6 +1570,8 @@ ceph_direct_read_write(struct kiocb *iocif (len != size)osd_req_op_extent_update (req,0 , len); +osd_req_op_extent_osd_data_bvecs (req,0 , bvecs, num_pages, len); +/* * To simplify error handling, allow AIO when IO within i_size * or IO can be satisfied by single OSD request.
@@ -1591,17 +1603,6 @@ ceph_direct_read_write(struct kiocb *ioc req->r_mtime = mtime; } -osd_req_op_extent_osd_data_bvecs (req,0 , bvecs, num_pages, len); - op = &req->r_ops[0 ]; -if (sparse) { - extent_cnt =__ceph_sparse_read_ext_count (inode, size); - ret =ceph_alloc_sparse_ext_map (op, extent_cnt); -if (ret) { -ceph_osdc_put_request (req); -break ; - } - } -if (aio_req) { aio_req->total_len += len; aio_req->num_reqs++;
Greg Kroah-Hartman
maintainerPATCH 156/160 mm: use aligned address in clear_gigantic_page()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kefeng Wang <[email protected]>
commit 8aca2bc96c833ba695ede7a45ad7784c836a262e upstream.
In current kernel, hugetlb_no_page() calls folio_zero_user() with the fault address. Where the fault address may be not aligned with the huge page size. Then, folio_zero_user() may call clear_gigantic_page() with the address, while clear_gigantic_page() requires the address to be huge page size aligned. So, this may cause memory corruption or information leak, addtional, use more obvious naming 'addr_hint' instead of 'addr' for clear_gigantic_page().
--- fs/hugetlbfs/inode.c | 2 +- mm/memory.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-)
fs/hugetlbfs/inode.c +1 -1
@@ -893,7 +893,7 @@ static long hugetlbfs_fallocate(struct f error =PTR_ERR (folio); goto out; } -folio_zero_user (folio,ALIGN_DOWN (addr, hpage_size)); +folio_zero_user (folio, addr);__folio_mark_uptodate (folio); error =hugetlb_add_to_page_cache (folio, mapping, index);if (unlikely (error)) {
mm/memory.c +2 -1
@@ -6780,9 +6780,10 @@ static inline int process_huge_page(return 0 ; } -static void clear_gigantic_page (struct folio *folio,unsigned long addr, +static void clear_gigantic_page (struct folio *folio,unsigned long addr_hint,unsigned int nr_pages) { +unsigned long addr =ALIGN_DOWN (addr_hint,folio_size (folio));int i;might_sleep ();
Greg Kroah-Hartman
maintainerPATCH 157/160 mm: use aligned address in copy_user_gigantic_page()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kefeng Wang <[email protected]>
commit f5d09de9f1bf9674c6418ff10d0a40cfe29268e1 upstream.
In current kernel, hugetlb_wp() calls copy_user_large_folio() with the fault address. Where the fault address may be not aligned with the huge page size. Then, copy_user_large_folio() may call copy_user_gigantic_page() with the address, while copy_user_gigantic_page() requires the address to be huge page size aligned. So, this may cause memory corruption or information leak, addtional, use more obvious naming 'addr_hint' instead of 'addr' for copy_user_gigantic_page().
--- mm/hugetlb.c | 5 ++--- mm/memory.c | 5 +++-- 2 files changed, 5 insertions(+), 5 deletions(-)
mm/hugetlb.c +2 -3
@@ -5333,7 +5333,7 @@ again:break ; } ret =copy_user_large_folio (new_folio, pte_folio, -ALIGN_DOWN (addr, sz), dst_vma); + addr, dst_vma);folio_put (pte_folio);if (ret) {folio_put (new_folio);
@@ -6632,8 +6632,7 @@ int hugetlb_mfill_atomic_pte(pte_t *dst_ *foliop =NULL ; goto out; } - ret =copy_user_large_folio (folio, *foliop, -ALIGN_DOWN (dst_addr, size), dst_vma); + ret =copy_user_large_folio (folio, *foliop, dst_addr, dst_vma);folio_put (*foliop); *foliop =NULL ;if (ret) {
mm/memory.c +3 -2
@@ -6817,13 +6817,14 @@ void folio_zero_user(struct folio *folio }static int copy_user_gigantic_page (struct folio *dst,struct folio *src, -unsigned long addr, +unsigned long addr_hint,struct vm_area_struct *vma,unsigned int nr_pages) { -int i; +unsigned long addr =ALIGN_DOWN (addr_hint,folio_size (dst));struct page *dst_page;struct page *src_page; +int i;for (i =0 ; i < nr_pages; i++) { dst_page =folio_page (dst, i);
Greg Kroah-Hartman
maintainerPATCH 158/160 mm: shmem: fix ShmemHugePages at swapout
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hugh Dickins <[email protected]>
commit dad2dc9c92e0f93f33cebcb0595b8daa3d57473f upstream.
/proc/meminfo ShmemHugePages has been showing overlarge amounts (more than Shmem) after swapping out THPs: we forgot to update NR_SHMEM_THPS.
Add shmem_update_stats(), to avoid repetition, and risk of making that mistake again: the call from shmem_delete_from_page_cache() is the bugfix; the call from shmem_replace_folio() is reassuring, but not really a bugfix (replace corrects misplaced swapin readahead, but huge swapin readahead would be a mistake).
--- mm/shmem.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-)
mm/shmem.c +12 -10
@@ -779,6 +779,14 @@ static bool shmem_huge_global_enabled(st }#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ +static void shmem_update_stats (struct folio *folio,int nr_pages) +{ +if (folio_test_pmd_mappable (folio)) +__lruvec_stat_mod_folio (folio,NR_SHMEM_THPS , nr_pages); +__lruvec_stat_mod_folio (folio,NR_FILE_PAGES , nr_pages); +__lruvec_stat_mod_folio (folio,NR_SHMEM , nr_pages); +} +/* * Somewhat like filemap_add_folio, but error if expected item has gone. */
@@ -813,10 +821,7 @@ static int shmem_add_to_page_cache(strucxas_store (&xas, folio);if (xas_error (&xas)) goto unlock; -if (folio_test_pmd_mappable (folio)) -__lruvec_stat_mod_folio (folio,NR_SHMEM_THPS , nr); -__lruvec_stat_mod_folio (folio,NR_FILE_PAGES , nr); -__lruvec_stat_mod_folio (folio,NR_SHMEM , nr); +shmem_update_stats (folio, nr); mapping->nrpages += nr; unlock:xas_unlock_irq (&xas);
@@ -844,8 +849,7 @@ static void shmem_delete_from_page_cache error =shmem_replace_entry (mapping, folio->index, folio, radswap); folio->mapping =NULL ; mapping->nrpages -= nr; -__lruvec_stat_mod_folio (folio,NR_FILE_PAGES , -nr); -__lruvec_stat_mod_folio (folio,NR_SHMEM , -nr); +shmem_update_stats (folio, -nr);xa_unlock_irq (&mapping->i_pages);folio_put_refs (folio, nr);BUG_ON (error);
@@ -1944,10 +1948,8 @@ static int shmem_replace_folio(struct fo }if (!error) {mem_cgroup_replace_folio (old, new); -__lruvec_stat_mod_folio (new,NR_FILE_PAGES , nr_pages); -__lruvec_stat_mod_folio (new,NR_SHMEM , nr_pages); -__lruvec_stat_mod_folio (old,NR_FILE_PAGES , -nr_pages); -__lruvec_stat_mod_folio (old,NR_SHMEM , -nr_pages); +shmem_update_stats (new, nr_pages); +shmem_update_stats (old, -nr_pages); }xa_unlock_irq (&swap_mapping->i_pages);
Greg Kroah-Hartman
maintainerPATCH 159/160 mm: convert partially_mapped set/clear operations to be atomic
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Usama Arif <[email protected]>
commit 42b2eb69835b0fda797f70eb5b4fc213dbe3a7ea upstream.
Other page flags in the 2nd page, like PG_hwpoison and PG_anon_exclusive can get modified concurrently. Changes to other page flags might be lost if they are happening at the same time as non-atomic partially_mapped operations. Hence, make partially_mapped operations atomic.
--- include/linux/page-flags.h | 12 ++---------- mm/huge_memory.c | 8 ++++---- 2 files changed, 6 insertions(+), 14 deletions(-)
include/linux/page-flags.h +2 -10
@@ -860,18 +860,10 @@ static inline void ClearPageCompound(strClearPageHead (page); } FOLIO_FLAG(large_rmappable, FOLIO_SECOND_PAGE) -FOLIO_TEST_FLAG (partially_mapped,FOLIO_SECOND_PAGE ) -/* -* PG_partially_mapped is protected by deferred_split split_queue_lock, -* so its safe to use non-atomic set/clear. - */ -__FOLIO_SET_FLAG(partially_mapped, FOLIO_SECOND_PAGE) -__FOLIO_CLEAR_FLAG(partially_mapped, FOLIO_SECOND_PAGE) +FOLIO_FLAG(partially_mapped, FOLIO_SECOND_PAGE)#else FOLIO_FLAG_FALSE(large_rmappable) -FOLIO_TEST_FLAG_FALSE(partially_mapped) -__FOLIO_SET_FLAG_NOOP(partially_mapped) -__FOLIO_CLEAR_FLAG_NOOP(partially_mapped) +FOLIO_FLAG_FALSE(partially_mapped)#endif #define PG_head_mask ((1UL << PG_head))
mm/huge_memory.c +4 -4
@@ -3503,7 +3503,7 @@ int split_huge_page_to_list_to_order(str !list_empty(&folio->_deferred_list)) { ds_queue->split_queue_len--;if (folio_test_partially_mapped (folio)) { -__folio_clear_partially_mapped (folio); +folio_clear_partially_mapped (folio);mod_mthp_stat (folio_order (folio),MTHP_STAT_NR_ANON_PARTIALLY_MAPPED ,-1 ); }
@@ -3615,7 +3615,7 @@ bool __folio_unqueue_deferred_split(struif (!list_empty (&folio->_deferred_list)) { ds_queue->split_queue_len--;if (folio_test_partially_mapped (folio)) { -__folio_clear_partially_mapped (folio); +folio_clear_partially_mapped (folio);mod_mthp_stat (folio_order (folio),MTHP_STAT_NR_ANON_PARTIALLY_MAPPED ,-1 ); }
@@ -3659,7 +3659,7 @@ void deferred_split_folio(struct folio *spin_lock_irqsave (&ds_queue->split_queue_lock, flags);if (partially_mapped) {if (!folio_test_partially_mapped (folio)) { -__folio_set_partially_mapped (folio); +folio_set_partially_mapped (folio);if (folio_test_pmd_mappable (folio))count_vm_event (THP_DEFERRED_SPLIT_PAGE );count_mthp_stat (folio_order (folio),MTHP_STAT_SPLIT_DEFERRED );
@@ -3752,7 +3752,7 @@ static unsigned long deferred_split_scan }else {/* We lost race with folio_put() */ if (folio_test_partially_mapped (folio)) { -__folio_clear_partially_mapped (folio); +folio_clear_partially_mapped (folio);mod_mthp_stat (folio_order (folio),MTHP_STAT_NR_ANON_PARTIALLY_MAPPED ,-1 ); }
Greg Kroah-Hartman
maintainerPATCH 160/160 epoll: Add synchronous wakeup support for ep_poll_callback
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xuewen Yan <[email protected]>
commit 900bbaae67e980945dec74d36f8afe0de7556d5a upstream.
Now, the epoll only use wake_up() interface to wake up task. However, sometimes, there are epoll users which want to use the synchronous wakeup flag to hint the scheduler, such as Android binder driver.
So add a wake_up_sync() define, and use the wake_up_sync() when the sync is true in ep_poll_callback().
--- fs/eventpoll.c | 5 ++++- include/linux/wait.h | 1 + 2 files changed, 5 insertions(+), 1 deletion(-)
fs/eventpoll.c +4 -1
@@ -1373,7 +1373,10 @@ static int ep_poll_callback(wait_queue_ebreak ; } } -wake_up (&ep->wq); +if (sync) +wake_up_sync (&ep->wq); +else +wake_up (&ep->wq); }if (waitqueue_active (&ep->poll_wait)) pwake++;
include/linux/wait.h +1 -0
@@ -221,6 +221,7 @@ void __wake_up_pollfree(struct wait_queu#define wake_up_all (x) __wake_up(x, TASK_NORMAL, 0, NULL)#define wake_up_locked (x) __wake_up_locked((x), TASK_NORMAL, 1)#define wake_up_all_locked (x) __wake_up_locked((x), TASK_NORMAL, 0) +#define wake_up_sync (x) __wake_up_sync(x, TASK_NORMAL)#define wake_up_interruptible (x) __wake_up(x, TASK_INTERRUPTIBLE, 1, NULL)#define wake_up_interruptible_nr (x, nr) __wake_up(x, TASK_INTERRUPTIBLE, nr, NULL)
Hello,
Quoted 7 lines · On Mon, 23 Dec 2024 16:56:51 +0100 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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, 27 Dec 2024 15:53:30 +0000. Anything received after that time might be too late.
This rc kernel passes DAMON functionality test[1] on my test machine. Attaching the test results summary below. Please note that I retrieved the kernel from linux-stable-rc tree[2].
[1] https://github.com/damonitor/damon-tests/tree/next/corr
[2] c157915828d8 ("Linux 6.12.7-rc1")
Thanks,
SJ
[...]
---
ok 9 selftests: damon: damos_tried_regions.py
ok 10 selftests: damon: damon_nr_regions.py
ok 11 selftests: damon: reclaim.sh
ok 12 selftests: damon: lru_sort.sh
ok 13 selftests: damon: debugfs_empty_targets.sh
ok 14 selftests: damon: debugfs_huge_count_read_write.sh
ok 15 selftests: damon: debugfs_duplicate_context_creation.sh ok 16 selftests: damon: debugfs_rm_non_contexts.sh
ok 17 selftests: damon: debugfs_target_ids_read_before_terminate_race.sh ok 18 selftests: damon: debugfs_target_ids_pid_leak.sh
ok 19 selftests: damon: sysfs_update_removed_scheme_dir.sh
ok 20 selftests: damon: sysfs_update_schemes_tried_regions_hang.py ok 1 selftests: damon-tests: kunit.sh
ok 2 selftests: damon-tests: huge_count_read_write.sh
ok 3 selftests: damon-tests: buffer_overflow.sh
ok 4 selftests: damon-tests: rm_contexts.sh
ok 5 selftests: damon-tests: record_null_deref.sh
ok 6 selftests: damon-tests: dbgfs_target_ids_read_before_terminate_race.sh ok 7 selftests: damon-tests: dbgfs_target_ids_pid_leak.sh
ok 8 selftests: damon-tests: damo_tests.sh
ok 9 selftests: damon-tests: masim-record.sh
ok 10 selftests: damon-tests: build_i386.sh
ok 11 selftests: damon-tests: build_arm64.sh # SKIP
ok 12 selftests: damon-tests: build_m68k.sh # SKIP
ok 13 selftests: damon-tests: build_i386_idle_flag.sh
ok 14 selftests: damon-tests: build_i386_highpte.sh
ok 15 selftests: damon-tests: build_nomemcg.sh
[33m
[92mPASS [39m
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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, 27 Dec 2024 15:53:30 +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.12.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Hi Greg
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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, 27 Dec 2024 15:53:30 +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.12.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
6.12.7-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.12.7-rc1rv
(takeshi@ThinkPadX1Gen10J0764) (gcc (GCC) 14.2.1 20240910, GNU ld (GNU Binutils) 2.43.0) #1 SMP PREEMPT_DYNAMIC Tue Dec 24 07:47:05 JST 2024
Thanks
Hi Greg,
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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.12.7 release. There are 160 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, 27 Dec 2024 15:53:30 +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.12.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Am 23.12.2024 um 16:56 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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.
Happy holiday season!
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]
Works as it should
AMD Ryzen 5 5600 6-Core Processor:
https://www.inet.se/produkt/5304697/amd-ryzen-5-5600-3-5-ghz-35mb on a
https://www.gigabyte.com/Motherboard/B550-AORUS-ELITE-V2-rev-12
https://www.inet.se/produkt/1903406/gigabyte-b550-aorus-elite-v2
motherboard :)
running Arch Linux with the testing repos enabled:
https://archlinux.org/ https://archboot.com/
https://wiki.archlinux.org/title/Arch_Testing_Team
and merry xmas here from Sweden :)
Den mån 23 dec. 2024 kl 17:00 skrev Greg Kroah-Hartman <[email protected]>:
Quoted 682 lines
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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, 27 Dec 2024 15:53:30 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:Greg Kroah-Hartman <[email protected]>
Linux 6.12.7-rc1Xuewen Yan <[email protected]>
epoll: Add synchronous wakeup support forep_poll_callbackUsama Arif <[email protected]>
mm: convertpartially_mappedset/clear operations to be atomicHugh Dickins <[email protected]>
mm: shmem: fix ShmemHugePages at swapoutKefeng Wang <[email protected]>
mm: use aligned address incopy_user_gigantic_page()Kefeng Wang <[email protected]>
mm: use aligned address inclear_gigantic_page()Ilya Dryomov <[email protected]>
ceph: fix memory leak inceph_direct_read_write()Max Kellermann <[email protected]>
ceph: fix memory leaks in__ceph_sync_read()Alex Markuze <[email protected]>
ceph: improve error handling and short/overflow-read logic in__ceph_sync_read()Ilya Dryomov <[email protected]>
ceph: validate snapdirname option length when mountingMax Kellermann <[email protected]>
ceph: give up on paths longer thanPATH_MAXZijun Hu <[email protected]>
of: Fix refcount leakage for OF node returned by__of_get_dma_parent()Herve Codina <[email protected]>
of: Fix error path inof_parse_phandle_with_args_map()Andrea della Porta <[email protected]>
of: address: Preserve the flags portion on 1:1 dma-ranges mappingSamuel Holland <[email protected]>
of: property:fw_devlink: Do not use interrupt-parent directlyJann Horn <[email protected]>
udmabuf: also check forF_SEAL_FUTURE_WRITEJann Horn <[email protected]>
udmabuf: fix racy memfd sealing checkEdward Adam Davis <[email protected]>
nilfs2: prevent use of deleted inodeRyusuke Konishi <[email protected]>
nilfs2: fix buffer head leaks in calls totruncate_inode_pages()Heming Zhao <[email protected]>
ocfs2: fix the space leak in LA when releasing LAZijun Hu <[email protected]>
of/irq: Fix using uninitialized variable @addr_len in APIof_irq_parse_one()Zijun Hu <[email protected]>
of/irq: Fix interrupt-map cell length check inof_irq_parse_imap_parent()Sean Christopherson <[email protected]>
KVM: SVM: Allow guest writes to setMSR_AMD64_DE_CFGbitsTrond Myklebust <[email protected]>
NFS/pnfs: Fix a live lock between recalled layouts and layoutgetPavel Begunkov <[email protected]>
io_uring: check if iowq is killed before queuingJann Horn <[email protected]>
io_uring: Fix registered ring file refcount leakTiezhu Yang <[email protected]>
selftests/bpf: Use asm constraint "m" for LoongArchIsaac J. Manjarres <[email protected]>
selftests/memfd: run sysctl tests when PID namespace support is enabledSteven Rostedt <[email protected]>
tracing: Check "%s" dereference via the field and not theTP_printkformatSteven Rostedt <[email protected]>
tracing: Add "%s" check intest_event_printk()Steven Rostedt <[email protected]>
tracing: Add missing helper functions in event pointer dereference checkSteven Rostedt <[email protected]>
tracing: Fixtest_event_printk()to process entire print argumentJacek Lawrynowicz <[email protected]>
accel/ivpu: Fix WARN inivpu_ipc_send_receive_internal()Jacek Lawrynowicz <[email protected]>
accel/ivpu: Fix general protection fault inivpu_bo_list()Enzo Matsumiya <[email protected]>
smb: client: fix TCP timers deadlock after rmmodSean Christopherson <[email protected]>
KVM: x86: Play nice with protected guests incomplete_hypercall_exit()Naman Jain <[email protected]>
x86/hyperv: Fix hv tsc page basedsched_clockfor hibernationDexuan Cui <[email protected]>
tools: hv: Fix a complier warning in the fcopy uio daemonMichael Kelley <[email protected]>
Drivers: hv: util: Avoid accessing a ringbuffer not initialized yetSteven Rostedt <[email protected]>
fgraph: Still initialize idle shadow stacks when startingAlex Deucher <[email protected]>
drm/amdgpu/mmhub4.1: fix IP version checkAlex Deucher <[email protected]>
drm/amdgpu/gfx12: fix IP version checkAlex Deucher <[email protected]>
drm/amdgpu/nbio7.0: fix IP version checkHeiko Carstens <[email protected]>
s390/mm: Fix DirectMap accountingQu Wenruo <[email protected]>
btrfs: tree-checker: reject inline extent items with 0 ref countJosef Bacik <[email protected]>
btrfs: fix improper generation check in snapshot deleteChristoph Hellwig <[email protected]>
btrfs: split bios to the fs sector size boundarySuren Baghdasaryan <[email protected]>
alloc_tag: fixset_codetag_empty()when !CONFIG_MEM_ALLOC_PROFILING_DEBUGEdward Adam Davis <[email protected]>
ring-buffer: Fix overflow in__rb_map_vmaDavid Hildenbrand <[email protected]>
mm/page_alloc: don't callpfn_to_page()on possibly non-existent PFN insplit_large_buddy()Matthew Wilcox (Oracle) <[email protected]>
vmalloc: fix accounting with i915Kairui Song <[email protected]>
zram: fix uninitialized ZRAM not releasing backing deviceKairui Song <[email protected]>
zram: refuse to use zero sized block device as backing deviceAlex Deucher <[email protected]>
drm/amdgpu/smu14.0.2: fix IP version checkAlex Deucher <[email protected]>
drm/amdgpu/nbio7.7: fix IP version checkAlex Deucher <[email protected]>
drm/amdgpu/nbio7.11: fix IP version checkSteven Rostedt <[email protected]>
trace/ring-buffer: Do not useTP_printk()formatting for boot mapped buffersMing Lei <[email protected]>
block: avoid to reusehctxnot removed from cpuhp callback listMurad Masimov <[email protected]>
hwmon: (tmp513) Fix interpretation of values of Temperature Result and Limit RegistersMurad Masimov <[email protected]>
hwmon: (tmp513) Fix Current Register value interpretationMurad Masimov <[email protected]>
hwmon: (tmp513) Fix interpretation of values of Shunt Voltage and Limit RegistersPierre-Eric Pelloux-Prayer <[email protected]>
drm/amdgpu: don't access invalid schedUmesh Nerlige Ramappa <[email protected]>
i915/guc: Accumulate active runtime on gt resetUmesh Nerlige Ramappa <[email protected]>
i915/guc: Ensure busyness counter increases motonicallyUmesh Nerlige Ramappa <[email protected]>
i915/guc: Reset engine utilization buffer before registrationMichael Trimarchi <[email protected]>
drm/panel: synaptics-r63353: Fix regulator unbalanceMarek Vasut <[email protected]>
drm/panel: st7701: Addprepare_prev_firstflag todrm_panelYang Yingliang <[email protected]>
drm/panel: novatek-nt35950: fix return value check innt35950_probe()Zhang Zekun <[email protected]>
drm/panel: himax-hx83102: Add a check to prevent NULL pointer dereferenceT.J. Mercier <[email protected]>
dma-buf: Fix__dma_buf_debugfs_list_delargument for !CONFIG_DEBUG_FSJann Horn <[email protected]>
udmabuf: fix memory leak on lastexport_udmabuf()error pathHuan Yang <[email protected]>
udmabuf:udmabuf_createpin folio codestyle cleanupMichel Dänzer <[email protected]>
drm/amdgpu: Handle NULL bo->tbo.resource (again) in amdgpu_vm_bo_updateChristian König <[email protected]>
drm/amdgpu: fixamdgpu_coredumpVille Syrjälä <[email protected]>
drm/modes: Avoid divide by zero harder indrm_mode_vrefresh()Mario Limonciello <[email protected]>
drm/amd: Update strapping for NBIO 2.5.0Krzysztof Karas <[email protected]>
drm/display: useERR_PTRon DP tunnel manager creation failMario Limonciello <[email protected]>
thunderbolt: Don't displaynvm_versionunless upgrade supportedMika Westerberg <[email protected]>
thunderbolt: Improve redrive mode handlingMika Westerberg <[email protected]>
thunderbolt: Add support for Intel Panther Lake-M/PMathias Nyman <[email protected]>
xhci: Turn NEC specific quirk for handling Stop Endpoint errors genericDaniele Palmas <[email protected]>
USB: serial: option: add Telit FE910C04 rmnet compositionsJack Wu <[email protected]>
USB: serial: option: add MediaTek T7XX compositionsMank Wang <[email protected]>
USB: serial: option: add Netprisma LCUK54 modules for WWAN ReadyMichal Hrusecky <[email protected]>
USB: serial: option: add MeiG Smart SLM770ADaniel Swanemar <[email protected]>
USB: serial: option: add TCL IK512 MBIM & ECMNathan Chancellor <[email protected]>
hexagon: Disable constant extender optimization for LLVM prior to 19.1.0James Bottomley <[email protected]>
efivarfs: Fix error on non-existent fileGeert Uytterhoeven <[email protected]>
i2c: riic: Always round-up when calculating bus periodMing Lei <[email protected]>
block: Revert "block: Fix potential deadlock while freezing queue and acquiringsysfs_lock"Jeremy Kerr <[email protected]>
net: mctp: handle skb cleanup onsock_queuefailuresDan Carpenter <[email protected]>
chelsio/chtls: prevent potential integer overflow on 32bitEric Dumazet <[email protected]>
net: tun: fixtun_napi_alloc_frags()Sean Christopherson <[email protected]>
KVM: x86: Cache CPUID.0xD XSTATE offsets+sizes during module initMarc Zyngier <[email protected]>
KVM: arm64: Do not allow ID_AA64MMFR0_EL1.ASIDbits to be overriddenBorislav Petkov (AMD) <[email protected]>
EDAC/amd64: Simplify ECC check on unified memory controllersMarc Zyngier <[email protected]>
irqchip/gic-v3: Work around insecure GIC integrationsJoe Hattori <[email protected]>
mmc: mtk-sd: disable wakeup in .remove() and in the error path of .probe()Prathamesh Shete <[email protected]>
mmc: sdhci-tegra: RemoveSDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESCquirkJoe Hattori <[email protected]>
net: mdiobus: fix an OF node reference leakAdrian Moreno <[email protected]>
psample: adjust size ifrate_as_probabilityis setJakub Kicinski <[email protected]>
netdev-genl: avoid empty messages in queue dumpVladimir Oltean <[email protected]>
net: dsa: restoredsa_software_vlan_untag()ability to operate on VLAN-untagged trafficAdrian Moreno <[email protected]>
selftests: openvswitch: fix tcpdump executionPhil Sutter <[email protected]>
netfilter: ipset: Fix for recursive locking warningDavid Laight <[email protected]>
ipvs: Fixclamp()ofip_vs_conn_tabon small memory systemsMatthias Schiffer <[email protected]>
can:m_can: fix missed interrupts withm_can_pciMatthias Schiffer <[email protected]>
can:m_can: set init flag earlier in probeEric Dumazet <[email protected]>
net: netdevsim: fixnsim_pp_hold_write()Joe Hattori <[email protected]>
net: ethernet: bgmac-platform: fix an OF node reference leakParthiban Veerasooran <[email protected]>
net: ethernet:oa_tc6: fix tx skb race condition between reference pointersParthiban Veerasooran <[email protected]>
net: ethernet:oa_tc6: fix infinite loop error when tx credits becomes 0Dan Carpenter <[email protected]>
net: hinic: Fix cleanup in create_rxqs/txqs()Daniel Borkmann <[email protected]>
team: Fix feature exposure when no ports are presentJakub Kicinski <[email protected]>
netdev: fix repeated netlink messages in queue statsJakub Kicinski <[email protected]>
netdev: fix repeated netlink messages in queue dumpMarios Makassikis <[email protected]>
ksmbd: fix broken transfers when exceeding max simultaneous operationsMarios Makassikis <[email protected]>
ksmbd: count all requests inreq_runningcounterNikita Yushchenko <[email protected]>
net: renesas: rswitch: rework ts tags managementShannon Nelson <[email protected]>
ionic: use ee->offset when returning sprom dataShannon Nelson <[email protected]>
ionic: no double destroy workqueueBrett Creeley <[email protected]>
ionic: Fix netdev notifier unregister on failureDonald Hunter <[email protected]>
tools/net/ynl: fix sub-message key lookup for nested attributesEric Dumazet <[email protected]>
netdevsim: prevent bad user input innsim_dev_health_break_write()Vladimir Oltean <[email protected]>
net: mscc: ocelot: fix incorrect IFHSRC_PORTfield inocelot_ifh_set_basic()Guangguan Wang <[email protected]>
net/smc: check return value ofsock_recvmsgwhen draining clc dataGuangguan Wang <[email protected]>
net/smc: checksmcd_v2_ext_offsetwhen receiving proposal msgGuangguan Wang <[email protected]>
net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msgGuangguan Wang <[email protected]>
net/smc: checkiparea_offsetandipv6_prefixes_cntwhen receiving proposal msgGuangguan Wang <[email protected]>
net/smc: checksndbuf_spaceagain after NOSPACE flag is set insmc_pollGuangguan Wang <[email protected]>
net/smc: protect link down work from execute after lgr freedHuaisheng Ye <[email protected]>
cxl/region: Fix region creation for greater than x2 switchesDavidlohr Bueso <[email protected]>
cxl/pci: Fix potential bogus return value upon successful probingOlaf Hering <[email protected]>
tools: hv: change permissions of NetworkManager configuration fileDarrick J. Wong <[email protected]>
xfs: fix zero byte checking in the superblock scrubberDarrick J. Wong <[email protected]>
xfs: fixsb_spino_alignchecks for large fsblock sizesDarrick J. Wong <[email protected]>
xfs: fix off-by-one error in fsmap'send_daddrusageDave Chinner <[email protected]>
xfs: fix sparse inode limits on runt AGDave Chinner <[email protected]>
xfs:sb_spino_alignis not verifiedGao Xiang <[email protected]>
erofs: use buffered I/O for file-backed mounts by defaultGao Xiang <[email protected]>
erofs: referencestruct erofs_device_infoforerofs_map_devGao Xiang <[email protected]>
erofs: usestruct erofs_device_infofor the primary deviceGao Xiang <[email protected]>
erofs: adderofs_sb_free()helperVasily Gorbik <[email protected]>
s390/mm: Consider KMSAN modules metadata for paging levelsVineeth Pillai (Google) <[email protected]>
sched/dlserver: Fix dlserver time accountingVineeth Pillai (Google) <[email protected]>
sched/dlserver: Fix dlserver double enqueueGao Xiang <[email protected]>
erofs: fix PSI memstall accountingAlexander Gordeev <[email protected]>
s390/ipl: Fix never less than zero warningVladimir Riabchun <[email protected]>
i2c: pnx: Fix timeout in wait functionsShin'ichiro Kawasaki <[email protected]>
p2sb: Do not scan and remove the P2SB device when it is unhiddenShin'ichiro Kawasaki <[email protected]>
p2sb: Move P2SB hide and unhide code top2sb_scan_and_cache()Shin'ichiro Kawasaki <[email protected]>
p2sb: Introduce the global flagp2sb_hidden_by_biosShin'ichiro Kawasaki <[email protected]>
p2sb: Factor outp2sb_read_from_cache()Peter Zijlstra <[email protected]>
sched/eevdf: More PELT vsDELAYED_DEQUEUEVincent Guittot <[email protected]>
sched/fair: Fixsched_can_stop_tick()for fair tasksK Prateek Nayak <[email protected]>
sched/fair: FixNEXT_BUDDYMichael Neuling <[email protected]>
RISC-V: KVM: Fix csr_write -> csr_set for HVIEN PMU overflow bitLevi Yun <[email protected]>
firmware: arm_ffa: Fix the race around setting ffa_dev->propertiesArnd Bergmann <[email protected]>
firmware:arm_scmi: Fix i.MX build dependencyRussell King (Oracle) <[email protected]>
net: stmmac: fix TSO DMA API usage causing oopsLion Ackermann <[email protected]>
net: sched: fix ordering of qlen adjustment-------------
Diffstat:
Makefile | 4 +- arch/arm64/kvm/sys_regs.c | 3 +- arch/hexagon/Makefile | 6 + arch/riscv/kvm/aia.c | 2 +- arch/s390/boot/startup.c | 2 + arch/s390/boot/vmem.c | 6 +- arch/s390/kernel/ipl.c | 2 +- arch/x86/kernel/cpu/mshyperv.c | 58 +++++ arch/x86/kvm/cpuid.c | 31 ++- arch/x86/kvm/cpuid.h | 1 + arch/x86/kvm/svm/svm.c | 9 - arch/x86/kvm/x86.c | 4 +- block/blk-mq-sysfs.c | 16 +- block/blk-mq.c | 40 ++-- block/blk-sysfs.c | 4 +- drivers/accel/ivpu/ivpu_gem.c | 2 +- drivers/accel/ivpu/ivpu_pm.c | 2 +- drivers/block/zram/zram_drv.c | 15 +- drivers/clocksource/hyperv_timer.c | 14 +- drivers/cxl/core/region.c | 25 +- drivers/cxl/pci.c | 3 +- drivers/dma-buf/dma-buf.c | 2 +- drivers/dma-buf/udmabuf.c | 180 ++++++++------ drivers/edac/amd64_edac.c | 32 +-- drivers/firmware/arm_ffa/bus.c | 15 +- drivers/firmware/arm_ffa/driver.c | 7 +- drivers/firmware/arm_scmi/vendors/imx/Kconfig | 1 + drivers/firmware/imx/Kconfig | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c | 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 +- drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/mmhub_v4_1_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/nbio_v7_0.c | 11 + drivers/gpu/drm/amd/amdgpu/nbio_v7_11.c | 2 +- drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c | 2 +- .../gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c | 2 +- drivers/gpu/drm/display/drm_dp_tunnel.c | 10 +- drivers/gpu/drm/drm_modes.c | 11 +- drivers/gpu/drm/i915/gt/intel_engine_types.h | 5 + drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 41 +++- drivers/gpu/drm/panel/panel-himax-hx83102.c | 2 + drivers/gpu/drm/panel/panel-novatek-nt35950.c | 4 +- drivers/gpu/drm/panel/panel-sitronix-st7701.c | 1 + drivers/gpu/drm/panel/panel-synaptics-r63353.c | 2 +- drivers/hv/hv_kvp.c | 6 + drivers/hv/hv_snapshot.c | 6 + drivers/hv/hv_util.c | 9 + drivers/hv/hyperv_vmbus.h | 2 + drivers/hwmon/tmp513.c | 10 +- drivers/i2c/busses/i2c-pnx.c | 4 +- drivers/i2c/busses/i2c-riic.c | 2 +- drivers/irqchip/irq-gic-v3.c | 17 +- drivers/mmc/host/mtk-sd.c | 2 + drivers/mmc/host/sdhci-tegra.c | 1 - drivers/net/can/m_can/m_can.c | 36 ++- drivers/net/can/m_can/m_can.h | 1 + drivers/net/can/m_can/m_can_pci.c | 1 + drivers/net/ethernet/broadcom/bgmac-platform.c | 5 +- .../chelsio/inline_crypto/chtls/chtls_main.c | 5 +- drivers/net/ethernet/huawei/hinic/hinic_main.c | 2 + drivers/net/ethernet/mscc/ocelot.c | 2 +- drivers/net/ethernet/oa_tc6.c | 11 +- drivers/net/ethernet/pensando/ionic/ionic_dev.c | 5 +- .../net/ethernet/pensando/ionic/ionic_ethtool.c | 4 +- drivers/net/ethernet/pensando/ionic/ionic_lif.c | 4 +- drivers/net/ethernet/renesas/rswitch.c | 68 +++--- drivers/net/ethernet/renesas/rswitch.h | 13 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 +- drivers/net/mdio/fwnode_mdio.c | 13 +- drivers/net/netdevsim/health.c | 2 + drivers/net/netdevsim/netdev.c | 4 +- drivers/net/team/team_core.c | 10 +- drivers/net/tun.c | 2 +- drivers/of/address.c | 5 +- drivers/of/base.c | 15 +- drivers/of/irq.c | 2 + drivers/of/property.c | 2 - drivers/platform/x86/p2sb.c | 79 ++++-- drivers/thunderbolt/nhi.c | 8 + drivers/thunderbolt/nhi.h | 4 + drivers/thunderbolt/retimer.c | 19 +- drivers/thunderbolt/tb.c | 41 ++++ drivers/usb/host/xhci-ring.c | 2 - drivers/usb/serial/option.c | 27 +++ fs/btrfs/bio.c | 10 +- fs/btrfs/ctree.h | 19 ++ fs/btrfs/extent-tree.c | 6 +- fs/btrfs/tree-checker.c | 27 ++- fs/ceph/file.c | 77 +++--- fs/ceph/mds_client.c | 9 +- fs/ceph/super.c | 2 + fs/efivarfs/inode.c | 2 +- fs/efivarfs/internal.h | 1 - fs/efivarfs/super.c | 3 - fs/erofs/data.c | 36 +-- fs/erofs/fileio.c | 9 +- fs/erofs/fscache.c | 10 +- fs/erofs/internal.h | 15 +- fs/erofs/super.c | 80 ++++--- fs/erofs/zdata.c | 4 +- fs/eventpoll.c | 5 +- fs/hugetlbfs/inode.c | 2 +- fs/nfs/pnfs.c | 2 +- fs/nilfs2/btnode.c | 1 + fs/nilfs2/gcinode.c | 2 +- fs/nilfs2/inode.c | 13 +- fs/nilfs2/namei.c | 5 + fs/nilfs2/nilfs.h | 1 + fs/ocfs2/localalloc.c | 8 +- fs/smb/client/connect.c | 36 ++- fs/smb/server/connection.c | 18 +- fs/smb/server/connection.h | 1 - fs/smb/server/server.c | 7 +- fs/smb/server/server.h | 1 + fs/smb/server/transport_ipc.c | 5 +- fs/xfs/libxfs/xfs_ialloc.c | 16 +- fs/xfs/libxfs/xfs_sb.c | 15 ++ fs/xfs/scrub/agheader.c | 29 ++- fs/xfs/xfs_fsmap.c | 29 ++- include/clocksource/hyperv_timer.h | 2 + include/linux/alloc_tag.h | 7 +- include/linux/arm_ffa.h | 13 +- include/linux/hyperv.h | 1 + include/linux/io_uring.h | 4 +- include/linux/page-flags.h | 12 +- include/linux/sched.h | 7 + include/linux/trace_events.h | 6 +- include/linux/wait.h | 1 + io_uring/io_uring.c | 7 +- kernel/sched/core.c | 2 +- kernel/sched/deadline.c | 8 +- kernel/sched/debug.c | 1 + kernel/sched/fair.c | 73 ++++-- kernel/sched/pelt.c | 2 +- kernel/sched/sched.h | 13 +- kernel/trace/fgraph.c | 8 +- kernel/trace/ring_buffer.c | 6 +- kernel/trace/trace.c | 264 +++++---------------- kernel/trace/trace.h | 6 +- kernel/trace/trace_events.c | 227 ++++++++++++++---- kernel/trace/trace_output.c | 6 +- mm/huge_memory.c | 8 +- mm/hugetlb.c | 5 +- mm/memory.c | 8 +- mm/page_alloc.c | 6 +- mm/shmem.c | 22 +- mm/vmalloc.c | 6 +- net/core/netdev-genl.c | 19 +- net/dsa/tag.h | 16 +- net/mctp/route.c | 36 ++- net/mctp/test/route-test.c | 86 +++++++ net/netfilter/ipset/ip_set_list_set.c | 3 + net/netfilter/ipvs/ip_vs_conn.c | 4 +- net/psample/psample.c | 9 +- net/sched/sch_cake.c | 2 +- net/sched/sch_choke.c | 2 +- net/smc/af_smc.c | 18 +- net/smc/smc_clc.c | 17 +- net/smc/smc_clc.h | 22 +- net/smc/smc_core.c | 9 +- sound/soc/fsl/Kconfig | 1 + tools/hv/hv_fcopy_uio_daemon.c | 8 +- tools/hv/hv_set_ifconfig.sh | 2 +- tools/net/ynl/lib/ynl.py | 6 +- tools/testing/selftests/bpf/sdt.h | 2 + tools/testing/selftests/memfd/memfd_test.c | 14 +- .../selftests/net/openvswitch/openvswitch.sh | 6 +- 168 files changed, 1685 insertions(+), 891 deletions(-)
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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, 27 Dec 2024 15:53:30 +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.12.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.12:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
116 tests: 116 pass, 0 failLinux version: 6.12.7-rc1-gc157915828d8
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 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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, 27 Dec 2024 15:53:30 +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.12.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
The following test regressions found on arm64 selftests kvm kvm_set_id_regs.
This was reported and fixed by a patch [1].
* graviton4-metal, kselftest-kvm
- kvm_set_id_regs
* rk3399-rock-pi-4b-nvhe, kselftest-kvm
- kvm_set_id_regs
* rk3399-rock-pi-4b-protected, kselftest-kvm
- kvm_set_id_regs
* rk3399-rock-pi-4b-vhe, kselftest-kvm
- kvm_set_id_regs
Test log:
-----------
# ==== Test Assertion Failure ====
# aarch64/set_id_regs.c:434: masks[idx] & ftr_bits[j].mask == ftr_bits[j].mask
# pid=2627 tid=2627 errno=22 - Invalid argument
# 1 0x0000000000402fe7: test_vm_ftr_id_regs at set_id_regs.c:434 # 2 0x0000000000401b53: main at set_id_regs.c:588 # 3 0x0000ffffa640773f: ?? ??:0 # 4 0x0000ffffa6407817: ?? ??:0 # 5 0x0000000000401e2f: _start at ??:?
# 0 != 0xf0 (masks[idx] & ftr_bits[j].mask != ftr_bits[j].mask)
not ok 7 selftests: kvm: set_id_regs # exit=254
Test report and fix link,
[1] https://lore.kernel.org/all/20241216-kvm-arm64-fix-set-id-asidbits-v1-1-8b105b888fc3@kernel.org/
Test failed Links:
---------
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.12.y/build/v6.12.6-161-gc157915828d8/testrun/26470691/suite/kselftest-kvm/test/kvm_set_id_regs/log
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.12.y/build/v6.12.6-161-gc157915828d8/testrun/26470691/suite/kselftest-kvm/test/kvm_set_id_regs/history/
## Build
* kernel: 6.12.7-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: c157915828d8f4b0a4f2e60fffed2459c27f3003
* git describe: v6.12.6-161-gc157915828d8
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.12.y/build/v6.12.6-161-gc157915828d8
## Test Regressions (compared to v6.12.5-173-g83a2a70d2d65)
* graviton4-metal, kselftest-kvm
- kvm_set_id_regs
* rk3399-rock-pi-4b-nvhe, kselftest-kvm
- kvm_set_id_regs
* rk3399-rock-pi-4b-protected, kselftest-kvm
- kvm_set_id_regs
* rk3399-rock-pi-4b-vhe, kselftest-kvm
- kvm_set_id_regs
## Metric Regressions (compared to v6.12.5-173-g83a2a70d2d65)
## Test Fixes (compared to v6.12.5-173-g83a2a70d2d65)
## Metric Fixes (compared to v6.12.5-173-g83a2a70d2d65)
## Test result summary
total: 116741, pass: 93918, fail: 4621, skip: 18202, xfail: 0
## Build Summary
* arc: 6 total, 5 passed, 1 failed
* arm: 143 total, 137 passed, 6 failed
* arm64: 58 total, 56 passed, 2 failed
* i386: 22 total, 19 passed, 3 failed
* mips: 38 total, 33 passed, 5 failed
* parisc: 5 total, 3 passed, 2 failed
* powerpc: 44 total, 40 passed, 4 failed
* riscv: 27 total, 24 passed, 3 failed
* s390: 26 total, 22 passed, 4 failed
* sh: 6 total, 5 passed, 1 failed
* sparc: 5 total, 3 passed, 2 failed
* x86_64: 50 total, 49 passed, 1 failed
## Test suites summary
* boot
* commands
* 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-rust
* 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-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* 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
Quoted 33 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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, 27 Dec 2024 15:53:30 +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.12.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
The following test regressions found on arm64 selftests kvm
kvm_set_id_regs.This was reported and fixed by a patch [1].
* graviton4-metal, kselftest-kvm
-kvm_set_id_regs* rk3399-rock-pi-4b-nvhe, kselftest-kvm
-kvm_set_id_regs
Quoted 7 lines
* rk3399-rock-pi-4b-protected, kselftest-kvm
-kvm_set_id_regs* rk3399-rock-pi-4b-vhe, kselftest-kvm
-kvm_set_id_regs
This is totally harmless, and if anything, indicates that the *fix* is doing its job, and that this patch *must* be backported.
M.
Signature · 1 line
Without deviation from the norm, progress is not possible.
Greg Kroah-Hartman
maintainerQuoted 38 lines · Marc Zyngier
Quoted 36 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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, 27 Dec 2024 15:53:30 +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.12.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
The following test regressions found on arm64 selftests kvm
kvm_set_id_regs.This was reported and fixed by a patch [1].
* graviton4-metal, kselftest-kvm
-kvm_set_id_regs* rk3399-rock-pi-4b-nvhe, kselftest-kvm
-kvm_set_id_regs* rk3399-rock-pi-4b-protected, kselftest-kvm
-kvm_set_id_regs
Quoted 7 lines
Quoted 4 lines
* rk3399-rock-pi-4b-vhe, kselftest-kvm
-kvm_set_id_regsThis is totally harmless, and if anything, indicates that the *fix* is doing its job, and that this patch *must* be backported.
Ok, but for some bizare reason someone stripped OFF the Fixes: tag, which causes this problem to now show up. Hopefully that will not happen again in the future, but now I don't know what the git id is in Linus's tree to be able to apply here.
So, what do I do now?
confused,
greg k-h
Quoted 40 lines · Greg Kroah-Hartman
Quoted 38 lines · Marc Zyngier
Quoted 36 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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, 27 Dec 2024 15:53:30 +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.12.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
The following test regressions found on arm64 selftests kvm
kvm_set_id_regs.This was reported and fixed by a patch [1].
* graviton4-metal, kselftest-kvm
-kvm_set_id_regs* rk3399-rock-pi-4b-nvhe, kselftest-kvm
-kvm_set_id_regs* rk3399-rock-pi-4b-protected, kselftest-kvm
-kvm_set_id_regs
Quoted 7 lines
Quoted 7 lines
Quoted 4 lines
* rk3399-rock-pi-4b-vhe, kselftest-kvm
-kvm_set_id_regsThis is totally harmless, and if anything, indicates that the *fix* is doing its job, and that this patch *must* be backported.
I think I caused the confusion here, as "this patch" refers to the original fix which has been queued, rather than the patch to the selftest, which I don't consider a candidate for backports.
Quoted 1 line
Ok, but for some bizare reason someone stripped OFF the Fixes: tag,
"Someone" == we, the KVM/arm64 maintainers.
And that's on purpose. A selftest patch doesn't fix anything, and I really don't want to use the "Fixes:" tag as a type of dependency. Additionally, these tests are mostly pointless anyway, specially this one, which really should be deleted.
Quoted 5 lines
which causes this problem to now show up. Hopefully that will not happen again in the future, but now I don't know what the git id is in Linus's tree to be able to apply here.
So, what do I do now?
Nothing, apart from applying the original fix, and blissfully ignoring the selftest, unless someone really want to backport it (I don't).
Thanks, and sorry for the confusion.
M.
Signature · 1 line
Without deviation from the norm, progress is not possible.
Greg Kroah-Hartman
maintainerQuoted 54 lines · Marc Zyngier
Quoted 40 lines · Greg Kroah-Hartman
Quoted 38 lines · Marc Zyngier
Quoted 36 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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, 27 Dec 2024 15:53:30 +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.12.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
The following test regressions found on arm64 selftests kvm
kvm_set_id_regs.This was reported and fixed by a patch [1].
* graviton4-metal, kselftest-kvm
-kvm_set_id_regs* rk3399-rock-pi-4b-nvhe, kselftest-kvm
-kvm_set_id_regs* rk3399-rock-pi-4b-protected, kselftest-kvm
-kvm_set_id_regsQuoted 7 lines
Quoted 7 lines
Quoted 4 lines
* rk3399-rock-pi-4b-vhe, kselftest-kvm
-kvm_set_id_regsThis is totally harmless, and if anything, indicates that the *fix* is doing its job, and that this patch *must* be backported.
I think I caused the confusion here, as "this patch" refers to the original fix which has been queued, rather than the patch to the selftest, which I don't consider a candidate for backports.
Quoted 8 lines
Quoted 1 line
Ok, but for some bizare reason someone stripped OFF the Fixes: tag,
"Someone" == we, the KVM/arm64 maintainers.
And that's on purpose. A selftest patch doesn't fix anything, and I really don't want to use the "Fixes:" tag as a type of dependency. Additionally, these tests are mostly pointless anyway, specially this one, which really should be deleted.
So should I drop something? Revert it? Add a new commit? What is going to help solve the issue that we now have selftests failing?
still confused,
greg k-h
Quoted 60 lines · Greg Kroah-Hartman
Quoted 58 lines · Marc Zyngier
Quoted 40 lines · Greg Kroah-Hartman
Quoted 38 lines · Marc Zyngier
Quoted 36 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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, 27 Dec 2024 15:53:30 +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.12.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
The following test regressions found on arm64 selftests kvm
kvm_set_id_regs.This was reported and fixed by a patch [1].
* graviton4-metal, kselftest-kvm
-kvm_set_id_regs* rk3399-rock-pi-4b-nvhe, kselftest-kvm
-kvm_set_id_regs* rk3399-rock-pi-4b-protected, kselftest-kvm
-kvm_set_id_regsQuoted 7 lines
Quoted 7 lines
Quoted 4 lines
* rk3399-rock-pi-4b-vhe, kselftest-kvm
-kvm_set_id_regsThis is totally harmless, and if anything, indicates that the *fix* is doing its job, and that this patch *must* be backported.
I think I caused the confusion here, as "this patch" refers to the original fix which has been queued, rather than the patch to the selftest, which I don't consider a candidate for backports.
Quoted 1 line
Ok, but for some bizare reason someone stripped OFF the Fixes: tag,
"Someone" == we, the KVM/arm64 maintainers.
Quoted 7 lines
Quoted 4 lines
And that's on purpose. A selftest patch doesn't fix anything, and I really don't want to use the "Fixes:" tag as a type of dependency. Additionally, these tests are mostly pointless anyway, specially this one, which really should be deleted.
So should I drop something? Revert it? Add a new commit? What is going to help solve the issue that we now have selftests failing?
There is nothing to add, as the fix for the selftest isn't upstream yet. If you are that bothered about an utterly pointless test failing, feel free to drop the backport of this patch and leave 6.12 being broken.
M.
Signature · 1 line
Without deviation from the norm, progress is not possible.
Greg Kroah-Hartman
maintainerQuoted 67 lines · Marc Zyngier
Quoted 65 lines · Greg Kroah-Hartman
Quoted 62 lines · Marc Zyngier
Quoted 40 lines · Greg Kroah-Hartman
Quoted 38 lines · Marc Zyngier
Quoted 36 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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, 27 Dec 2024 15:53:30 +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.12.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
The following test regressions found on arm64 selftests kvm
kvm_set_id_regs.This was reported and fixed by a patch [1].
* graviton4-metal, kselftest-kvm
-kvm_set_id_regs* rk3399-rock-pi-4b-nvhe, kselftest-kvm
-kvm_set_id_regs* rk3399-rock-pi-4b-protected, kselftest-kvm
-kvm_set_id_regsQuoted 7 lines
Quoted 7 lines
Quoted 4 lines
* rk3399-rock-pi-4b-vhe, kselftest-kvm
-kvm_set_id_regsThis is totally harmless, and if anything, indicates that the *fix* is doing its job, and that this patch *must* be backported.
I think I caused the confusion here, as "this patch" refers to the original fix which has been queued, rather than the patch to the selftest, which I don't consider a candidate for backports.
Quoted 1 line
Ok, but for some bizare reason someone stripped OFF the Fixes: tag,
"Someone" == we, the KVM/arm64 maintainers.
And that's on purpose. A selftest patch doesn't fix anything, and I really don't want to use the "Fixes:" tag as a type of dependency. Additionally, these tests are mostly pointless anyway, specially this one, which really should be deleted.
Quoted 7 lines
Quoted 2 lines
So should I drop something? Revert it? Add a new commit? What is going to help solve the issue that we now have selftests failing?
There is nothing to add, as the fix for the selftest isn't upstream yet. If you are that bothered about an utterly pointless test failing, feel free to drop the backport of this patch and leave 6.12 being broken.
I'm not running arm kvm selftests, so it doesn't bother me! :)
thanks,
greg k-h
On Fri, Dec 27, 2024 at 01:23:40PM +0000, Marc Zyngier wrote:
...
Quoted 3 lines
Additionally, these tests are mostly pointless anyway, specially this one, which really should be deleted.
Would it by any chance be possible to remove such pointless tests, or at least mark them as BROKEN ? Having them present suggests that people should run them, and feedback such as this one isn't really helpful. If anything, it is tremendously frustrating for anyone trying to run those tests and getting that kind of feedback when noticing and reporting that they are broken.
Thanks,
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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, 27 Dec 2024 15:53:30 +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.12.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.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 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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, 27 Dec 2024 15:53:30 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.
Quoted 5 lines
thanks,
greg k-h
-------------
OVERVIEW
Builds: 42 passed, 0 failed
Boot tests: 571 passed, 0 failed
CI systems: broonie, maestro
REVISION
Commit
name: v6.12.6-161-gc157915828d8
hash: c157915828d8f4b0a4f2e60fffed2459c27f3003
Checked out from
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.12.yBUILDS
No build failures found
BOOT TESTS
No boot failures found
See complete and up-to-date report at:
https://kcidb.kernelci.org/d/revision/revision?orgId=1&var-git_commit_hash=c157915828d8f4b0a4f2e60fffed2459c27f3003&var-patchset_hash=
Thanks,
KernelCI team
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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, 27 Dec 2024 15:53:30 +0000. Anything received after that time might be too late.
Hi Greg
6.12.7-rc1 compiles, boots and runs here on x86_64 (AMD Ryzen 5 PRO 4650G, Slackware64-15.0)
Nitpicking: On Slackware64-current (Tue Dec 24 19:32:08 UTC 2024) I notice the following info in dmesg on an AMD Ryzen 5 7520U lappy with kernel-firmware-20240904_87cae27 popping up within some minutes after booting, no negative system impact noticed; tho, once the event is logged, it seems to show up more frequent even in idle usage.
Dec 26 11:09:22 karrde kernel: rtw_8821ce 0000:02:00.0: unhandled firmware c2h interrupt Dec 26 11:10:11 karrde last message buffered 3 times Dec 26 11:12:14 karrde last message buffered 12 times Dec 26 11:21:19 karrde last message buffered 41 times
Bluetooth is enabled. This happens on both 6.12.7-rc1 and 6.12.6 (probably affects earlier 6.12.X kernels too), I can't bisect.
Pat, what about a more recent kernel-firmware package to test? :)
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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, 27 Dec 2024 15:53:30 +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.12.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.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
The kernel builds fine for v6.12.7-rc1 on x86 and arm64 Azure VM.
Thanks,
Hardik
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 6.12.7 release. There are 160 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 (obsvx2, bbb are test problems, not kernel problems):
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.12.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