6.1.158-rc1 review
Subsystems (5)
Greg Kroah-Hartman
maintainerPATCH 140/157 f2fs: remove the create argument to f2fs_map_blocks
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoph Hellwig <[email protected]>
[ Upstream commit cd8fc5226bef3a1fda13a0e61794a039ca46744a ]
The create argument is always identicaly to map->m_may_create, so use that consistently.
Stable-dep-of: 9d5c4f5c7a2c ("f2fs: fix wrong block mapping for multi-devices")
--- fs/f2fs/data.c | 65 ++++++++++++++++++-------------------------- fs/f2fs/f2fs.h | 3 -- fs/f2fs/file.c | 12 ++++---- include/trace/events/f2fs.h | 11 ++----- 4 files changed, 39 insertions(+), 52 deletions(-)
fs/f2fs/data.c +28 -37
@@ -1464,8 +1464,7 @@ int f2fs_get_block_locked(struct dnode_o* maps continuous logical blocks to physical blocks, and return such * info via f2fs_map_blocks structure. */ -int f2fs_map_blocks (struct inode *inode,struct f2fs_map_blocks *map, -int create,int flag) +int f2fs_map_blocks (struct inode *inode,struct f2fs_map_blocks *map,int flag) {unsigned int maxblocks = map->m_len;struct dnode_of_data dn;
@@ -1494,38 +1493,31 @@ int f2fs_map_blocks(struct inode *inode, pgofs = (pgoff_t )map->m_lblk; end = pgofs + maxblocks; -if (!create &&f2fs_lookup_read_extent_cache (inode, pgofs, &ei)) { -if (f2fs_lfs_mode (sbi) && flag ==F2FS_GET_BLOCK_DIO && - map->m_may_create) - goto next_dnode; - - map->m_pblk = ei.blk + pgofs - ei.fofs; - map->m_len =min ((pgoff_t )maxblocks, ei.fofs + ei.len - pgofs); - map->m_flags =F2FS_MAP_MAPPED ; -if (map->m_next_extent) - *map->m_next_extent = pgofs + map->m_len; +if (map->m_may_create || + !f2fs_lookup_read_extent_cache (inode, pgofs, &ei)) + goto next_dnode; + +/* Found the map in read extent cache */ + map->m_pblk = ei.blk + pgofs - ei.fofs; + map->m_len =min ((pgoff_t )maxblocks, ei.fofs + ei.len - pgofs); + map->m_flags =F2FS_MAP_MAPPED ; +if (map->m_next_extent) + *map->m_next_extent = pgofs + map->m_len; -/* for hardware encryption, but to avoid potential issue in future */ -if (flag ==F2FS_GET_BLOCK_DIO ) -f2fs_wait_on_block_writeback_range (inode, +/* for hardware encryption, but to avoid potential issue in future */ +if (flag ==F2FS_GET_BLOCK_DIO ) +f2fs_wait_on_block_writeback_range (inode, map->m_pblk, map->m_len); -if (map->m_multidev_dio) { -block_t blk_addr = map->m_pblk; - - bidx =f2fs_target_device_index (sbi, map->m_pblk); +if (map->m_multidev_dio) { + bidx =f2fs_target_device_index (sbi, map->m_pblk); - map->m_bdev =FDEV (bidx).bdev; - map->m_pblk -=FDEV (bidx).start_blk; - map->m_len =min (map->m_len, + map->m_bdev =FDEV (bidx).bdev; + map->m_pblk -=FDEV (bidx).start_blk; + map->m_len =min (map->m_len,FDEV (bidx).end_blk +1 - map->m_pblk); - -if (map->m_may_create) -f2fs_update_device_state (sbi, inode->i_ino, - blk_addr, map->m_len); - } - goto out; } + goto out; next_dnode:if (map->m_may_create)
@@ -1589,7 +1581,7 @@ next_block:set_inode_flag (inode,FI_APPEND_WRITE ); } }else { -if (create) { +if (map->m_may_create) {if (unlikely (f2fs_cp_error (sbi))) { err = -EIO ; goto sync_out;
@@ -1764,7 +1756,7 @@ unlock_out:f2fs_balance_fs (sbi, dn.node_changed); } out: -trace_f2fs_map_blocks (inode, map, create, flag, err); +trace_f2fs_map_blocks (inode, map, flag, err);return err; }
@@ -1786,7 +1778,7 @@ bool f2fs_overwrite_io(struct inode *inowhile (map.m_lblk < last_lblk) { map.m_len = last_lblk - map.m_lblk; - err =f2fs_map_blocks (inode, &map,0 ,F2FS_GET_BLOCK_DEFAULT ); + err =f2fs_map_blocks (inode, &map,F2FS_GET_BLOCK_DEFAULT );if (err || map.m_len ==0 )return false; map.m_lblk += map.m_len;
@@ -1960,7 +1952,7 @@ next: map.m_len = cluster_size - count_in_cluster; } - ret =f2fs_map_blocks (inode, &map,0 ,F2FS_GET_BLOCK_FIEMAP ); + ret =f2fs_map_blocks (inode, &map,F2FS_GET_BLOCK_FIEMAP );if (ret) goto out;
@@ -2093,7 +2085,7 @@ static int f2fs_read_single_page(struct map->m_lblk = block_in_file; map->m_len = last_block - block_in_file; - ret =f2fs_map_blocks (inode, map,0 ,F2FS_GET_BLOCK_DEFAULT ); + ret =f2fs_map_blocks (inode, map,F2FS_GET_BLOCK_DEFAULT );if (ret) goto out; got_it:
@@ -3850,7 +3842,7 @@ static sector_t f2fs_bmap(struct address map.m_next_pgofs =NULL ; map.m_seg_type =NO_CHECK_TYPE ; -if (!f2fs_map_blocks (inode, &map,0 ,F2FS_GET_BLOCK_BMAP )) +if (!f2fs_map_blocks (inode, &map,F2FS_GET_BLOCK_BMAP )) blknr = map.m_pblk; } out:
@@ -3958,7 +3950,7 @@ retry: map.m_seg_type =NO_CHECK_TYPE ; map.m_may_create = false; - ret =f2fs_map_blocks (inode, &map,0 ,F2FS_GET_BLOCK_FIEMAP ); + ret =f2fs_map_blocks (inode, &map,F2FS_GET_BLOCK_FIEMAP );if (ret) goto out;
@@ -4187,8 +4179,7 @@ static int f2fs_iomap_begin(struct inodeif (flags &IOMAP_WRITE ) map.m_may_create = true; - err =f2fs_map_blocks (inode, &map, flags &IOMAP_WRITE , -F2FS_GET_BLOCK_DIO ); + err =f2fs_map_blocks (inode, &map,F2FS_GET_BLOCK_DIO );if (err)return err;
fs/f2fs/f2fs.h +1 -2
@@ -3794,8 +3794,7 @@ struct page *f2fs_get_lock_data_page(strstruct page *f2fs_get_new_data_page (struct inode *inode,struct page *ipage,pgoff_t index,bool new_i_size);int f2fs_do_write_data_page (struct f2fs_io_info *fio); -int f2fs_map_blocks (struct inode *inode,struct f2fs_map_blocks *map, -int create,int flag); +int f2fs_map_blocks (struct inode *inode,struct f2fs_map_blocks *map,int flag);int f2fs_fiemap (struct inode *inode,struct fiemap_extent_info *fieinfo,u64 start,u64 len);int f2fs_encrypt_one_page (struct f2fs_io_info *fio);
fs/f2fs/file.c +6 -6
@@ -1800,7 +1800,7 @@ next_alloc:f2fs_unlock_op (sbi); map.m_seg_type =CURSEG_COLD_DATA_PINNED ; - err =f2fs_map_blocks (inode, &map,1 ,F2FS_GET_BLOCK_PRE_DIO ); + err =f2fs_map_blocks (inode, &map,F2FS_GET_BLOCK_PRE_DIO );file_dont_truncate (inode);f2fs_up_write (&sbi->pin_sem);
@@ -1813,7 +1813,7 @@ next_alloc: map.m_len = expanded; }else { - err =f2fs_map_blocks (inode, &map,1 ,F2FS_GET_BLOCK_PRE_AIO ); + err =f2fs_map_blocks (inode, &map,F2FS_GET_BLOCK_PRE_AIO ); expanded = map.m_len; } out_err:
@@ -2710,7 +2710,7 @@ static int f2fs_defragment_range(struct*/ while (map.m_lblk < pg_end) { map.m_len = pg_end - map.m_lblk; - err =f2fs_map_blocks (inode, &map,0 ,F2FS_GET_BLOCK_DEFAULT ); + err =f2fs_map_blocks (inode, &map,F2FS_GET_BLOCK_DEFAULT );if (err) goto out;
@@ -2757,7 +2757,7 @@ static int f2fs_defragment_range(struct do_map: map.m_len = pg_end - map.m_lblk; - err =f2fs_map_blocks (inode, &map,0 ,F2FS_GET_BLOCK_DEFAULT ); + err =f2fs_map_blocks (inode, &map,F2FS_GET_BLOCK_DEFAULT );if (err) goto clear_out;
@@ -3352,7 +3352,7 @@ int f2fs_precache_extents(struct inode * map.m_len = end - map.m_lblk;f2fs_down_write (&fi->i_gc_rwsem[WRITE ]); - err =f2fs_map_blocks (inode, &map,0 ,F2FS_GET_BLOCK_PRECACHE ); + err =f2fs_map_blocks (inode, &map,F2FS_GET_BLOCK_PRECACHE );f2fs_up_write (&fi->i_gc_rwsem[WRITE ]);if (err)return err;
@@ -4635,7 +4635,7 @@ static int f2fs_preallocate_blocks(struc flag =F2FS_GET_BLOCK_PRE_AIO ; } - ret =f2fs_map_blocks (inode, &map,1 , flag); + ret =f2fs_map_blocks (inode, &map, flag);/* -ENOSPC|-EDQUOT are fine to report the number of allocated blocks. */ if (ret <0 && !((ret == -ENOSPC || ret == -EDQUOT ) && map.m_len >0 ))return ret;
include/trace/events/f2fs.h +4 -7
@@ -564,10 +564,10 @@ TRACE_EVENT(f2fs_file_write_iter, ); TRACE_EVENT(f2fs_map_blocks, - TP_PROTO(struct inode *inode, struct f2fs_map_blocks *map, - int create, int flag, int ret), + TP_PROTO(struct inode *inode, struct f2fs_map_blocks *map, int flag, + int ret), - TP_ARGS(inode, map, create, flag, ret), + TP_ARGS(inode, map, flag, ret), TP_STRUCT__entry( __field(dev_t, dev)
@@ -579,7 +579,6 @@ TRACE_EVENT(f2fs_map_blocks, __field(int, m_seg_type) __field(bool, m_may_create) __field(bool, m_multidev_dio) - __field(int, create) __field(int, flag)__field (int, ret) ),
@@ -594,7 +593,6 @@ TRACE_EVENT(f2fs_map_blocks, __entry->m_seg_type = map->m_seg_type; __entry->m_may_create = map->m_may_create; __entry->m_multidev_dio = map->m_multidev_dio; - __entry->create = create; __entry->flag = flag; __entry->ret = ret; ),
@@ -602,7 +600,7 @@ TRACE_EVENT(f2fs_map_blocks, TP_printk("dev = (%d,%d), ino = %lu, file offset = %llu, " "start blkaddr = 0x%llx, len = 0x%llx, flags = %u, " "seg_type = %d, may_create = %d, multidevice = %d, " - "create = %d, flag = %d, err = %d", + "flag = %d, err = %d", show_dev_ino(__entry), (unsigned long long)__entry->m_lblk, (unsigned long long)__entry->m_pblk,
@@ -611,7 +609,6 @@ TRACE_EVENT(f2fs_map_blocks, __entry->m_seg_type, __entry->m_may_create, __entry->m_multidev_dio, - __entry->create, __entry->flag, __entry->ret) );
Greg Kroah-Hartman
maintainerPATCH 141/157 f2fs: factor a f2fs_map_blocks_cached helper
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoph Hellwig <[email protected]>
[ Upstream commit 0094e98bd1477a6b7d97c25b47b19a7317c35279 ]
Add a helper to deal with everything needed to return a f2fs_map_blocks structure based on a lookup in the extent cache.
Stable-dep-of: 9d5c4f5c7a2c ("f2fs: fix wrong block mapping for multi-devices")
--- fs/f2fs/data.c | 65 +++++++++++++++++++++++++++++++++------------------------ 1 file changed, 38 insertions(+), 27 deletions(-)
fs/f2fs/data.c +38 -27
@@ -1459,6 +1459,41 @@ int f2fs_get_block_locked(struct dnode_oreturn err; } +static bool f2fs_map_blocks_cached (struct inode *inode, +struct f2fs_map_blocks *map,int flag) +{ +struct f2fs_sb_info *sbi =F2FS_I_SB (inode); +unsigned int maxblocks = map->m_len; +pgoff_t pgoff = (pgoff_t )map->m_lblk; +struct extent_info ei = {}; + +if (!f2fs_lookup_read_extent_cache (inode, pgoff, &ei)) +return false; + + map->m_pblk = ei.blk + pgoff - ei.fofs; + map->m_len =min ((pgoff_t )maxblocks, ei.fofs + ei.len - pgoff); + map->m_flags =F2FS_MAP_MAPPED ; +if (map->m_next_extent) + *map->m_next_extent = pgoff + map->m_len; + +/* for hardware encryption, but to avoid potential issue in future */ +if (flag ==F2FS_GET_BLOCK_DIO ) +f2fs_wait_on_block_writeback_range (inode, + map->m_pblk, map->m_len); + +if (f2fs_allow_multi_device_dio (sbi, flag)) { +int bidx =f2fs_target_device_index (sbi, map->m_pblk); +struct f2fs_dev_info *dev = &sbi->devs[bidx]; + + map->m_bdev = dev->bdev; + map->m_pblk -= dev->start_blk; + map->m_len =min (map->m_len, dev->end_blk +1 - map->m_pblk); + }else { + map->m_bdev = inode->i_sb->s_bdev; + } +return true; +} +/* * f2fs_map_blocks() tries to find or build mapping relationship which * maps continuous logical blocks to physical blocks, and return such
@@ -1474,7 +1509,6 @@ int f2fs_map_blocks(struct inode *inode,int err =0 , ofs =1 ;unsigned int ofs_in_node, last_ofs_in_node;blkcnt_t prealloc; -struct extent_info ei = {0 , };block_t blkaddr;unsigned int start_pgofs;int bidx =0 ;
@@ -1482,6 +1516,9 @@ int f2fs_map_blocks(struct inode *inode,if (!maxblocks)return 0 ; +if (!map->m_may_create &&f2fs_map_blocks_cached (inode, map, flag)) + goto out; + map->m_bdev = inode->i_sb->s_bdev; map->m_multidev_dio =f2fs_allow_multi_device_dio (F2FS_I_SB (inode), flag);
@@ -1493,32 +1530,6 @@ int f2fs_map_blocks(struct inode *inode, pgofs = (pgoff_t )map->m_lblk; end = pgofs + maxblocks; -if (map->m_may_create || - !f2fs_lookup_read_extent_cache (inode, pgofs, &ei)) - goto next_dnode; - -/* Found the map in read extent cache */ - map->m_pblk = ei.blk + pgofs - ei.fofs; - map->m_len =min ((pgoff_t )maxblocks, ei.fofs + ei.len - pgofs); - map->m_flags =F2FS_MAP_MAPPED ; -if (map->m_next_extent) - *map->m_next_extent = pgofs + map->m_len; - -/* for hardware encryption, but to avoid potential issue in future */ -if (flag ==F2FS_GET_BLOCK_DIO ) -f2fs_wait_on_block_writeback_range (inode, - map->m_pblk, map->m_len); - -if (map->m_multidev_dio) { - bidx =f2fs_target_device_index (sbi, map->m_pblk); - - map->m_bdev =FDEV (bidx).bdev; - map->m_pblk -=FDEV (bidx).start_blk; - map->m_len =min (map->m_len, -FDEV (bidx).end_blk +1 - map->m_pblk); - } - goto out; - next_dnode:if (map->m_may_create)f2fs_do_map_lock (sbi, flag, true);
Greg Kroah-Hartman
maintainerPATCH 142/157 f2fs: fix wrong block mapping for multi-devices
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jaegeuk Kim <[email protected]>
[ Upstream commit 9d5c4f5c7a2c7677e1b3942772122b032c265aae ]
Assuming the disk layout as below,
disk0: 0 --- 0x00035abfff
disk1: 0x00035ac000 --- 0x00037abfff
disk2: 0x00037ac000 --- 0x00037ebfff
and we want to read data from offset=13568 having len=128 across the block devices, we can illustrate the block addresses like below.
0 .. 0x00037ac000 ------------------- 0x00037ebfff, 0x00037ec000 -------
| ^ ^ ^
| fofs 0 13568 13568+128
| ------------------------------------------------------
| LBA 0x37e8aa9 0x37ebfa9 0x37ec029
--- map 0x3caa9 0x3ffa9In this example, we should give the relative map of the target block device ranging from 0x3caa9 to 0x3ffa9 where the length should be calculated by 0x37ebfff + 1 - 0x37ebfa9.
In the below equation, however, map->m_pblk was supposed to be the original address instead of the one from the target block address.
- map->m_len = min(map->m_len, dev->end_blk + 1 - map->m_pblk);
--- fs/f2fs/data.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/f2fs/data.c +1 -1
@@ -1486,8 +1486,8 @@ static bool f2fs_map_blocks_cached(strucstruct f2fs_dev_info *dev = &sbi->devs[bidx]; map->m_bdev = dev->bdev; - map->m_pblk -= dev->start_blk; map->m_len =min (map->m_len, dev->end_blk +1 - map->m_pblk); + map->m_pblk -= dev->start_blk; }else { map->m_bdev = inode->i_sb->s_bdev; }
Greg Kroah-Hartman
maintainerPATCH 143/157 PCI: Add PCI_VDEVICE_SUB helper macro
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Piotr Kwapulinski <[email protected]>
[ Upstream commit 208fff3f567e2a3c3e7e4788845e90245c3891b4 ]
PCI_VDEVICE_SUB generates the pci_device_id struct layout for the specific PCI device/subdevice. Private data may follow the output.
Stable-dep-of: a7075f501bd3 ("ixgbevf: fix mailbox API compatibility by negotiating supported features")
--- include/linux/pci.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
include/linux/pci.h +14 -0
@@ -1027,6 +1027,20 @@ static inline struct pci_driver *to_pci_ .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, 0, 0/** +* PCI_VDEVICE_SUB - describe a specific PCI device/subdevice in a short form +* @vend: the vendor name +* @dev: the 16 bit PCI Device ID +* @subvend: the 16 bit PCI Subvendor ID +* @subdev: the 16 bit PCI Subdevice ID +* +* Generate the pci_device_id struct layout for the specific PCI +* device/subdevice. Private data may follow the output. + */ +#define PCI_VDEVICE_SUB (vend, dev, subvend, subdev) \ + .vendor = PCI_VENDOR_ID_##vend, .device = (dev), \ + .subvendor = (subvend), .subdevice = (subdev), 0, 0 + +/** * PCI_DEVICE_DATA - macro used to describe a specific PCI device in very short form * @vend: the vendor name (without PCI_VENDOR_ID_ prefix) * @dev: the device name (without PCI_DEVICE_ID_<vend>_ prefix)
Greg Kroah-Hartman
maintainerPATCH 144/157 ixgbevf: Add support for Intel(R) E610 device
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Piotr Kwapulinski <[email protected]>
[ Upstream commit 4c44b450c69b676955c2790dcf467c1f969d80f1 ]
Add support for Intel(R) E610 Series of network devices. The E610 is based on X550 but adds firmware managed link, enhanced security capabilities and support for updated server manageability
Stable-dep-of: a7075f501bd3 ("ixgbevf: fix mailbox API compatibility by negotiating supported features")
--- drivers/net/ethernet/intel/ixgbevf/defines.h | 5 ++++- drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 6 +++++- drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 12 ++++++++++-- drivers/net/ethernet/intel/ixgbevf/vf.c | 12 +++++++++++- drivers/net/ethernet/intel/ixgbevf/vf.h | 4 +++- 5 files changed, 33 insertions(+), 6 deletions(-)
drivers/net/ethernet/intel/ixgbevf/defines.h +4 -1
@@ -1,5 +1,5 @@/* SPDX-License-Identifier: GPL-2.0 */ -/* Copyright(c) 1999 - 2018 Intel Corporation. */ +/* Copyright(c) 1999 - 2024 Intel Corporation. */ #ifndef _IXGBEVF_DEFINES_H_#define _IXGBEVF_DEFINES_H_
@@ -16,6 +16,9 @@#define IXGBE_DEV_ID_X550_VF_HV 0x1564#define IXGBE_DEV_ID_X550EM_X_VF_HV 0x15A9 +#define IXGBE_DEV_ID_E610_VF 0x57AD +#define IXGBE_SUBDEV_ID_E610_VF_HV 0x00FF +#define IXGBE_VF_IRQ_CLEAR_MASK 7#define IXGBE_VF_MAX_TX_QUEUES 8#define IXGBE_VF_MAX_RX_QUEUES 8
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h +5 -1
@@ -1,5 +1,5 @@/* SPDX-License-Identifier: GPL-2.0 */ -/* Copyright(c) 1999 - 2018 Intel Corporation. */ +/* Copyright(c) 1999 - 2024 Intel Corporation. */ #ifndef _IXGBEVF_H_#define _IXGBEVF_H_
@@ -418,6 +418,8 @@ enum ixgbevf_boards { board_X550EM_x_vf, board_X550EM_x_vf_hv, board_x550em_a_vf, + board_e610_vf, + board_e610_vf_hv, }; enum ixgbevf_xcast_modes {
@@ -434,11 +436,13 @@ extern const struct ixgbevf_info ixgbevfextern const struct ixgbe_mbx_operations ixgbevf_mbx_ops;extern const struct ixgbe_mbx_operations ixgbevf_mbx_ops_legacy;extern const struct ixgbevf_info ixgbevf_x550em_a_vf_info; +extern const struct ixgbevf_info ixgbevf_e610_vf_info;extern const struct ixgbevf_info ixgbevf_82599_vf_hv_info;extern const struct ixgbevf_info ixgbevf_X540_vf_hv_info;extern const struct ixgbevf_info ixgbevf_X550_vf_hv_info;extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_hv_info; +extern const struct ixgbevf_info ixgbevf_e610_vf_hv_info;extern const struct ixgbe_mbx_operations ixgbevf_hv_mbx_ops;/* needed by ethtool.c */
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c +10 -2
@@ -1,5 +1,5 @@// SPDX-License-Identifier: GPL-2.0 -/* Copyright(c) 1999 - 2018 Intel Corporation. */ +/* Copyright(c) 1999 - 2024 Intel Corporation. */ /****************************************************************************** Copyright (c)2006 - 2007 Myricom, Inc. for some LRO specific code
@@ -39,7 +39,7 @@ static const char ixgbevf_driver_string["Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver" ;static char ixgbevf_copyright[] = -"Copyright (c) 2009 - 2018 Intel Corporation." ; +"Copyright (c) 2009 - 2024 Intel Corporation." ;static const struct ixgbevf_info *ixgbevf_info_tbl[] = { [board_82599_vf] = &ixgbevf_82599_vf_info,
@@ -51,6 +51,8 @@ static const struct ixgbevf_info *ixgbev [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info, [board_X550EM_x_vf_hv] = &ixgbevf_X550EM_x_vf_hv_info, [board_x550em_a_vf] = &ixgbevf_x550em_a_vf_info, + [board_e610_vf] = &ixgbevf_e610_vf_info, + [board_e610_vf_hv] = &ixgbevf_e610_vf_hv_info, };/* ixgbevf_pci_tbl - PCI Device ID Table
@@ -71,6 +73,9 @@ static const struct pci_device_id ixgbev {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF), board_X550EM_x_vf }, {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV), board_X550EM_x_vf_hv}, {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_A_VF), board_x550em_a_vf }, + {PCI_VDEVICE_SUB(INTEL, IXGBE_DEV_ID_E610_VF, PCI_ANY_ID, + IXGBE_SUBDEV_ID_E610_VF_HV), board_e610_vf_hv}, + {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_E610_VF), board_e610_vf},/* required last entry */ {0, } };
@@ -4686,6 +4691,9 @@ static int ixgbevf_probe(struct pci_devcase ixgbe_mac_X540_vf:dev_info (&pdev->dev,"Intel(R) X540 Virtual Function\n" );break ; +case ixgbe_mac_e610_vf: +dev_info (&pdev->dev,"Intel(R) E610 Virtual Function\n" ); +break ;case ixgbe_mac_82599_vf:default :dev_info (&pdev->dev,"Intel(R) 82599 Virtual Function\n" );
drivers/net/ethernet/intel/ixgbevf/vf.c +11 -1
@@ -1,5 +1,5 @@// SPDX-License-Identifier: GPL-2.0 -/* Copyright(c) 1999 - 2018 Intel Corporation. */ +/* Copyright(c) 1999 - 2024 Intel Corporation. */ #include "vf.h" #include "ixgbevf.h"
@@ -1076,3 +1076,13 @@ const struct ixgbevf_info ixgbevf_x550em .mac = ixgbe_mac_x550em_a_vf, .mac_ops = &ixgbevf_mac_ops, }; + +const struct ixgbevf_info ixgbevf_e610_vf_info = { + .mac = ixgbe_mac_e610_vf, + .mac_ops = &ixgbevf_mac_ops, +}; + +const struct ixgbevf_info ixgbevf_e610_vf_hv_info = { + .mac = ixgbe_mac_e610_vf, + .mac_ops = &ixgbevf_hv_mac_ops, +};
drivers/net/ethernet/intel/ixgbevf/vf.h +3 -1
@@ -1,5 +1,5 @@/* SPDX-License-Identifier: GPL-2.0 */ -/* Copyright(c) 1999 - 2018 Intel Corporation. */ +/* Copyright(c) 1999 - 2024 Intel Corporation. */ #ifndef __IXGBE_VF_H__#define __IXGBE_VF_H__
@@ -54,6 +54,8 @@ enum ixgbe_mac_type { ixgbe_mac_X550_vf, ixgbe_mac_X550EM_x_vf, ixgbe_mac_x550em_a_vf, + ixgbe_mac_e610, + ixgbe_mac_e610_vf, ixgbe_num_macs };
Greg Kroah-Hartman
maintainerPATCH 145/157 ixgbevf: fix getting link speed data for E610 devices
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jedrzej Jagielski <[email protected]>
[ Upstream commit 53f0eb62b4d23d40686f2dd51776b8220f2887bb ]
E610 adapters no longer use the VFLINKS register to read PF's link speed and linkup state. As a result VF driver cannot get actual link state and it incorrectly reports 10G which is the default option. It leads to a situation where even 1G adapters print 10G as actual link speed. The same happens when PF driver set speed different than 10G.
Add new mailbox operation to let the VF driver request a PF driver to provide actual link data. Update the mailbox api to v1.6.
Incorporate both ways of getting link status within the legacy ixgbe_check_mac_link_vf() function.
Stable-dep-of: a7075f501bd3 ("ixgbevf: fix mailbox API compatibility by negotiating supported features")
--- drivers/net/ethernet/intel/ixgbevf/defines.h | 1 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 6 drivers/net/ethernet/intel/ixgbevf/mbx.h | 4 drivers/net/ethernet/intel/ixgbevf/vf.c | 137 +++++++++++++++++----- 4 files changed, 116 insertions(+), 32 deletions(-)
drivers/net/ethernet/intel/ixgbevf/defines.h +1 -0
@@ -28,6 +28,7 @@/* Link speed */ typedef u32 ixgbe_link_speed ; +#define IXGBE_LINK_SPEED_UNKNOWN 0#define IXGBE_LINK_SPEED_1GB_FULL 0x0020#define IXGBE_LINK_SPEED_10GB_FULL 0x0080#define IXGBE_LINK_SPEED_100_FULL 0x0008
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c +5 -1
@@ -2272,6 +2272,7 @@ static void ixgbevf_negotiate_api(struct {struct ixgbe_hw *hw = &adapter->hw;static const int api[] = { + ixgbe_mbox_api_16, ixgbe_mbox_api_15, ixgbe_mbox_api_14, ixgbe_mbox_api_13,
@@ -2291,7 +2292,8 @@ static void ixgbevf_negotiate_api(struct idx++; } -if (hw->api_version >= ixgbe_mbox_api_15) { +/* Following is not supported by API 1.6, it is specific for 1.5 */ +if (hw->api_version == ixgbe_mbox_api_15) { hw->mbx.ops.init_params (hw);memcpy (&hw->mbx.ops, &ixgbevf_mbx_ops,sizeof (struct ixgbe_mbx_operations ));
@@ -2648,6 +2650,7 @@ static void ixgbevf_set_num_queues(struccase ixgbe_mbox_api_13:case ixgbe_mbox_api_14:case ixgbe_mbox_api_15: +case ixgbe_mbox_api_16:if (adapter->xdp_prog && hw->mac.max_tx_queues == rss) rss = rss >3 ?2 :1 ;
@@ -4641,6 +4644,7 @@ static int ixgbevf_probe(struct pci_devcase ixgbe_mbox_api_13:case ixgbe_mbox_api_14:case ixgbe_mbox_api_15: +case ixgbe_mbox_api_16: netdev->max_mtu =IXGBE_MAX_JUMBO_FRAME_SIZE - (ETH_HLEN +ETH_FCS_LEN );break ;
drivers/net/ethernet/intel/ixgbevf/mbx.h +4 -0
@@ -66,6 +66,7 @@ enum ixgbe_pfvf_api_rev { ixgbe_mbox_api_13,/* API version 1.3, linux/freebsd VF driver */ ixgbe_mbox_api_14,/* API version 1.4, linux/freebsd VF driver */ ixgbe_mbox_api_15,/* API version 1.5, linux/freebsd VF driver */ + ixgbe_mbox_api_16,/* API version 1.6, linux/freebsd VF driver */ /* This value should always be last */ ixgbe_mbox_api_unknown, /* indicates that API version is not known */ };
@@ -102,6 +103,9 @@ enum ixgbe_pfvf_api_rev {#define IXGBE_VF_GET_LINK_STATE 0x10/* get vf link state */ +/* mailbox API, version 1.6 VF requests */ +#define IXGBE_VF_GET_PF_LINK_STATE 0x11/* request PF to send link info */ +/* length of permanent address message returned from PF */ #define IXGBE_VF_PERMADDR_MSG_LEN 4/* word in permanent address message with the current multicast type */
drivers/net/ethernet/intel/ixgbevf/vf.c +106 -31
185 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 146/157 ixgbevf: fix mailbox API compatibility by negotiating supported features
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jedrzej Jagielski <[email protected]>
[ Upstream commit a7075f501bd33c93570af759b6f4302ef0175168 ]
There was backward compatibility in the terms of mailbox API. Various drivers from various OSes supporting 10G adapters from Intel portfolio could easily negotiate mailbox API.
This convention has been broken since introducing API 1.4. Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added support for IPSec which is specific only for the kernel ixgbe driver. None of the rest of the Intel 10G PF/VF drivers supports it. And actually lack of support was not included in the IPSec implementation - there were no such code paths. No possibility to negotiate support for the feature was introduced along with introduction of the feature itself.
Commit 339f28964147 ("ixgbevf: Add support for new mailbox communication between PF and VF") increasing API version to 1.5 did the same - it introduced code supported specifically by the PF ESX driver. It altered API version for the VF driver in the same time not touching the version defined for the PF ixgbe driver. It led to additional discrepancies, as the code provided within API 1.6 cannot be supported for Linux ixgbe driver as it causes crashes.
The issue was noticed some time ago and mitigated by Jake within the commit d0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5"). As a result we have regression for IPsec support and after increasing API to version 1.6 ixgbevf driver stopped to support ESX MBX.
To fix this mess add new mailbox op asking PF driver about supported features. Basing on a response determine whether to set support for IPSec and ESX-specific enhanced mailbox.
New mailbox op, for compatibility purposes, must be added within new API revision, as API version of OOT PF & VF drivers is already increased to 1.6 and doesn't incorporate features negotiate op.
Features negotiation mechanism gives possibility to be extended with new features when needed in the future.
--- drivers/net/ethernet/intel/ixgbevf/ipsec.c | 10 ++++ drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 7 +++ drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 32 ++++++++++++++- drivers/net/ethernet/intel/ixgbevf/mbx.h | 4 + drivers/net/ethernet/intel/ixgbevf/vf.c | 45 +++++++++++++++++++++- drivers/net/ethernet/intel/ixgbevf/vf.h | 1 6 files changed, 96 insertions(+), 3 deletions(-)
drivers/net/ethernet/intel/ixgbevf/ipsec.c +10 -0
@@ -269,6 +269,9 @@ static int ixgbevf_ipsec_add_sa(struct x adapter =netdev_priv (dev); ipsec = adapter->ipsec; +if (!(adapter->pf_features &IXGBEVF_PF_SUP_IPSEC )) +return -EOPNOTSUPP ; +if (xs->id.proto !=IPPROTO_ESP && xs->id.proto !=IPPROTO_AH ) {netdev_err (dev,"Unsupported protocol 0x%04x for IPsec offload\n" , xs->id.proto);
@@ -394,6 +397,9 @@ static void ixgbevf_ipsec_del_sa(struct adapter =netdev_priv (dev); ipsec = adapter->ipsec; +if (!(adapter->pf_features &IXGBEVF_PF_SUP_IPSEC )) +return ; +if (xs->xso.dir ==XFRM_DEV_OFFLOAD_IN ) { sa_idx = xs->xso.offload_handle -IXGBE_IPSEC_BASE_RX_INDEX ;
@@ -622,6 +628,10 @@ void ixgbevf_init_ipsec_offload(struct isize_t size;switch (adapter->hw.api_version) { +case ixgbe_mbox_api_17: +if (!(adapter->pf_features &IXGBEVF_PF_SUP_IPSEC )) +return ; +break ;case ixgbe_mbox_api_14:break ;default :
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h +7 -0
@@ -366,6 +366,13 @@ struct ixgbevf_adapter {/* Interrupt Throttle Rate */ u32 eitr_param; +u32 pf_features; +#define IXGBEVF_PF_SUP_IPSEC BIT(0) +#define IXGBEVF_PF_SUP_ESX_MBX BIT(1) + +#define IXGBEVF_SUPPORTED_FEATURES (IXGBEVF_PF_SUP_IPSEC | \ + IXGBEVF_PF_SUP_ESX_MBX) +struct ixgbevf_hw_stats stats;unsigned long state;
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c +30 -2
@@ -2268,10 +2268,35 @@ static void ixgbevf_init_last_counter_st adapter->stats.base_vfmprc = adapter->stats.last_vfmprc; } +/** +* ixgbevf_set_features - Set features supported by PF +* @adapter: pointer to the adapter struct +* +* Negotiate with PF supported features and then set pf_features accordingly. +*/ +static void ixgbevf_set_features (struct ixgbevf_adapter *adapter) +{ +u32 *pf_features = &adapter->pf_features; +struct ixgbe_hw *hw = &adapter->hw; +int err; + + err = hw->mac.ops.negotiate_features (hw, pf_features); +if (err && err != -EOPNOTSUPP ) +netdev_dbg (adapter->netdev, +"PF feature negotiation failed.\n" ); + +/* Address also pre API 1.7 cases */ +if (hw->api_version == ixgbe_mbox_api_14) + *pf_features |=IXGBEVF_PF_SUP_IPSEC ; +else if (hw->api_version == ixgbe_mbox_api_15) + *pf_features |=IXGBEVF_PF_SUP_ESX_MBX ; +} +static void ixgbevf_negotiate_api (struct ixgbevf_adapter *adapter) {struct ixgbe_hw *hw = &adapter->hw;static const int api[] = { + ixgbe_mbox_api_17, ixgbe_mbox_api_16, ixgbe_mbox_api_15, ixgbe_mbox_api_14,
@@ -2292,8 +2317,9 @@ static void ixgbevf_negotiate_api(struct idx++; } -/* Following is not supported by API 1.6, it is specific for 1.5 */ -if (hw->api_version == ixgbe_mbox_api_15) { +ixgbevf_set_features (adapter); + +if (adapter->pf_features &IXGBEVF_PF_SUP_ESX_MBX ) { hw->mbx.ops.init_params (hw);memcpy (&hw->mbx.ops, &ixgbevf_mbx_ops,sizeof (struct ixgbe_mbx_operations ));
@@ -2651,6 +2677,7 @@ static void ixgbevf_set_num_queues(struccase ixgbe_mbox_api_14:case ixgbe_mbox_api_15:case ixgbe_mbox_api_16: +case ixgbe_mbox_api_17:if (adapter->xdp_prog && hw->mac.max_tx_queues == rss) rss = rss >3 ?2 :1 ;
@@ -4645,6 +4672,7 @@ static int ixgbevf_probe(struct pci_devcase ixgbe_mbox_api_14:case ixgbe_mbox_api_15:case ixgbe_mbox_api_16: +case ixgbe_mbox_api_17: netdev->max_mtu =IXGBE_MAX_JUMBO_FRAME_SIZE - (ETH_HLEN +ETH_FCS_LEN );break ;
drivers/net/ethernet/intel/ixgbevf/mbx.h +4 -0
@@ -67,6 +67,7 @@ enum ixgbe_pfvf_api_rev { ixgbe_mbox_api_14,/* API version 1.4, linux/freebsd VF driver */ ixgbe_mbox_api_15,/* API version 1.5, linux/freebsd VF driver */ ixgbe_mbox_api_16,/* API version 1.6, linux/freebsd VF driver */ + ixgbe_mbox_api_17,/* API version 1.7, linux/freebsd VF driver */ /* This value should always be last */ ixgbe_mbox_api_unknown, /* indicates that API version is not known */ };
@@ -106,6 +107,9 @@ enum ixgbe_pfvf_api_rev {/* mailbox API, version 1.6 VF requests */ #define IXGBE_VF_GET_PF_LINK_STATE 0x11/* request PF to send link info */ +/* mailbox API, version 1.7 VF requests */ +#define IXGBE_VF_FEATURES_NEGOTIATE 0x12/* get features supported by PF*/ +/* length of permanent address message returned from PF */ #define IXGBE_VF_PERMADDR_MSG_LEN 4/* word in permanent address message with the current multicast type */
drivers/net/ethernet/intel/ixgbevf/vf.c +44 -1
99 lines not on this page · raw message
drivers/net/ethernet/intel/ixgbevf/vf.h +1 -0
@@ -26,6 +26,7 @@ struct ixgbe_mac_operations {s32 (*stop_adapter)(struct ixgbe_hw *);s32 (*get_bus_info)(struct ixgbe_hw *);s32 (*negotiate_api_version)(struct ixgbe_hw *hw,int api); +int (*negotiate_features)(struct ixgbe_hw *hw,u32 *pf_features);/* Link */ s32 (*setup_link)(struct ixgbe_hw *,ixgbe_link_speed ,bool ,bool );
Greg Kroah-Hartman
maintainerPATCH 147/157 phy: cadence: cdns-dphy: Update calibration wait time for startup state machine
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Devarsh Thakkar <[email protected]>
[ Upstream commit 2c27aaee934a1b5229152fe33a14f1fdf50da143 ]
Do read-modify-write so that we re-use the characterized reset value as specified in TRM [1] to program calibration wait time which defines number of cycles to wait for after startup state machine is in bandgap enable state.
This fixes PLL lock timeout error faced while using RPi DSI Panel on TI's AM62L and J721E SoC since earlier calibration wait time was getting overwritten to zero value thus failing the PLL to lockup and causing timeout.
[1] AM62P TRM (Section 14.8.6.3.2.1.1 DPHY_TX_DPHYTX_CMN0_CMN_DIG_TBIT2):
--- drivers/phy/cadence/cdns-dphy.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/phy/cadence/cdns-dphy.c +3 -1
@@ -31,6 +31,7 @@#define DPHY_CMN_SSM DPHY_PMA_CMN(0x20)#define DPHY_CMN_SSM_EN BIT(0) +#define DPHY_CMN_SSM_CAL_WAIT_TIME GENMASK(8, 1)#define DPHY_CMN_TX_MODE_EN BIT(9)#define DPHY_CMN_PWM DPHY_PMA_CMN(0x40)
@@ -422,7 +423,8 @@ static int cdns_dphy_power_on(struct phywritel (reg, dphy->regs +DPHY_BAND_CFG );/* Start TX state machine. */ -writel (DPHY_CMN_SSM_EN |DPHY_CMN_TX_MODE_EN , + reg =readl (dphy->regs +DPHY_CMN_SSM ); +writel ((reg &DPHY_CMN_SSM_CAL_WAIT_TIME ) |DPHY_CMN_SSM_EN |DPHY_CMN_TX_MODE_EN , dphy->regs +DPHY_CMN_SSM ); ret =cdns_dphy_wait_for_pll_lock (dphy);
Greg Kroah-Hartman
maintainerPATCH 148/157 arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kaushlendra Kumar <[email protected]>
[ Upstream commit 2eead19334516c8e9927c11b448fbe512b1f18a1 ]
Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clk_get_rate().
Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:
"The error code within @ptr if it is an error pointer; 0 otherwise."
This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be called when of_clk_get() returns NULL.
Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate().
--- drivers/base/arch_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/base/arch_topology.c +1 -1
@@ -327,7 +327,7 @@ bool __init topology_parse_cpu_capacity(* frequency (by keeping the initial freq_factor value). */ cpu_clk =of_clk_get (cpu_node,0 ); -if (!PTR_ERR_OR_ZERO (cpu_clk)) { +if (!IS_ERR_OR_NULL (cpu_clk)) {per_cpu (freq_factor, cpu) =clk_get_rate (cpu_clk) /1000 ;clk_put (cpu_clk);
Greg Kroah-Hartman
maintainerPATCH 149/157 xfs: always warn about deprecated mount options
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Darrick J. Wong" <[email protected]>
[ Upstream commit 630785bfbe12c3ee3ebccd8b530a98d632b7e39d ]
The deprecation of the 'attr2' mount option in 6.18 wasn't entirely successful because nobody noticed that the kernel never printed a warning about attr2 being set in fstab if the only xfs filesystem is the root fs; the initramfs mounts the root fs with no mount options; and the init scripts only conveyed the fstab options by remounting the root fs.
Fix this by making it complain all the time.
--- fs/xfs/xfs_super.c | 33 +++++++++++++++++++++------------ 1 file changed, 21 insertions(+), 12 deletions(-)
fs/xfs/xfs_super.c +21 -12
@@ -1201,16 +1201,25 @@ suffix_kstrtoint(static inline void xfs_fs_warn_deprecated (struct fs_context *fc, -struct fs_parameter *param, -uint64_t flag, -bool value) +struct fs_parameter *param) { -/* Don't print the warning if reconfiguring and current mount point -* already had the flag set +/* +* Always warn about someone passing in a deprecated mount option. +* Previously we wouldn't print the warning if we were reconfiguring +* and current mount point already had the flag set, but that was not +* the right thing to do. +* +* Many distributions mount the root filesystem with no options in the +* initramfs and rely on mount -a to remount the root fs with the +* options in fstab. However, the old behavior meant that there would +* never be a warning about deprecated mount options for the root fs in +* /etc/fstab. On a single-fs system, that means no warning at all. +* +* Compounding this problem are distribution scripts that copy +* /proc/mounts to fstab, which means that we can't remove mount +* options unless we're 100% sure they have only ever been advertised +* in /proc/mounts in response to explicitly provided mount options. */ -if ((fc->purpose &FS_CONTEXT_FOR_RECONFIGURE ) && - !!(XFS_M (fc->root->d_sb)->m_features & flag) == value) -return ;xfs_warn (fc->s_fs_info,"%s mount option is deprecated." , param->key); }
@@ -1349,19 +1358,19 @@ xfs_fs_parse_param(#endif /* Following mount options will be removed in September 2025 */ case Opt_ikeep: -xfs_fs_warn_deprecated (fc, param,XFS_FEAT_IKEEP , true); +xfs_fs_warn_deprecated (fc, param); parsing_mp->m_features |=XFS_FEAT_IKEEP ;return 0 ;case Opt_noikeep: -xfs_fs_warn_deprecated (fc, param,XFS_FEAT_IKEEP , false); +xfs_fs_warn_deprecated (fc, param); parsing_mp->m_features &= ~XFS_FEAT_IKEEP ;return 0 ;case Opt_attr2: -xfs_fs_warn_deprecated (fc, param,XFS_FEAT_ATTR2 , true); +xfs_fs_warn_deprecated (fc, param); parsing_mp->m_features |=XFS_FEAT_ATTR2 ;return 0 ;case Opt_noattr2: -xfs_fs_warn_deprecated (fc, param,XFS_FEAT_NOATTR2 , true); +xfs_fs_warn_deprecated (fc, param); parsing_mp->m_features |=XFS_FEAT_NOATTR2 ;return 0 ;default :
Greg Kroah-Hartman
maintainerPATCH 150/157 devcoredump: Fix circular locking dependency with devcd->mutex.
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maarten Lankhorst <[email protected]>
[ Upstream commit a91c8096590bd7801a26454789f2992094fe36da ]
The original code causes a circular locking dependency found by lockdep.
======================================================
WARNING: possible circular locking dependency detected
6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 Tainted: G S U
------------------------------------------------------
xe_fault_inject/5091 is trying to acquire lock:ffff888156815688 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}, at: __flush_work+0x25d/0x660
but task is already holding lock:
ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&devcd->mutex){+.+.}-{3:3}:
mutex_lock_nested+0x4e/0xc0
devcd_data_write+0x27/0x90
sysfs_kf_bin_write+0x80/0xf0
kernfs_fop_write_iter+0x169/0x220
vfs_write+0x293/0x560
ksys_write+0x72/0xf0
__x64_sys_write+0x19/0x30
x64_sys_call+0x2bf/0x2660
do_syscall_64+0x93/0xb60
entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #1 (kn->active#236){++++}-{0:0}:
kernfs_drain+0x1e2/0x200
__kernfs_remove+0xae/0x400
kernfs_remove_by_name_ns+0x5d/0xc0
remove_files+0x54/0x70
sysfs_remove_group+0x3d/0xa0
sysfs_remove_groups+0x2e/0x60
device_remove_attrs+0xc7/0x100
device_del+0x15d/0x3b0
devcd_del+0x19/0x30
process_one_work+0x22b/0x6f0
worker_thread+0x1e8/0x3d0
kthread+0x11c/0x250
ret_from_fork+0x26c/0x2e0
ret_from_fork_asm+0x1a/0x30
-> #0 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}:
__lock_acquire+0x1661/0x2860
lock_acquire+0xc4/0x2f0
__flush_work+0x27a/0x660
flush_delayed_work+0x5d/0xa0
dev_coredump_put+0x63/0xa0
xe_driver_devcoredump_fini+0x12/0x20 [xe]
devm_action_release+0x12/0x30
release_nodes+0x3a/0x120
devres_release_all+0x8a/0xd0
device_unbind_cleanup+0x12/0x80
device_release_driver_internal+0x23a/0x280
device_driver_detach+0x14/0x20
unbind_store+0xaf/0xc0
drv_attr_store+0x21/0x50
sysfs_kf_write+0x4a/0x80
kernfs_fop_write_iter+0x169/0x220
vfs_write+0x293/0x560
ksys_write+0x72/0xf0
__x64_sys_write+0x19/0x30
x64_sys_call+0x2bf/0x2660
do_syscall_64+0x93/0xb60
entry_SYSCALL_64_after_hwframe+0x76/0x7e
other info that might help us debug this:
Chain exists of: (work_completion)(&(&devcd->del_wk)->work) --> kn->active#236 --> &devcd->mutex
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&devcd->mutex);
lock(kn->active#236);
lock(&devcd->mutex);
lock((work_completion)(&(&devcd->del_wk)->work));
*** DEADLOCK ***
5 locks held by xe_fault_inject/5091:
#0: ffff8881129f9488 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x72/0xf0
#1: ffff88810c755078 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x123/0x220
#2: ffff8881054811a0 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x55/0x280
#3: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0
#4: ffffffff8359e020 (rcu_read_lock){....}-{1:2}, at: __flush_work+0x72/0x660
stack backtrace:
CPU: 14 UID: 0 PID: 5091 Comm: xe_fault_inject Tainted: G S U 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 PREEMPT_{RT,(lazy)}
Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER
Hardware name: Micro-Star International Co., Ltd. MS-7D25/PRO Z690-A DDR4(MS-7D25), BIOS 1.10 12/13/2021
Call Trace:
<TASK>
dump_stack_lvl+0x91/0xf0
dump_stack+0x10/0x20
print_circular_bug+0x285/0x360
check_noncircular+0x135/0x150
? register_lock_class+0x48/0x4a0
__lock_acquire+0x1661/0x2860
lock_acquire+0xc4/0x2f0
? __flush_work+0x25d/0x660
? mark_held_locks+0x46/0x90
? __flush_work+0x25d/0x660
__flush_work+0x27a/0x660
? __flush_work+0x25d/0x660
? trace_hardirqs_on+0x1e/0xd0
? __pfx_wq_barrier_func+0x10/0x10
flush_delayed_work+0x5d/0xa0
dev_coredump_put+0x63/0xa0
xe_driver_devcoredump_fini+0x12/0x20 [xe]
devm_action_release+0x12/0x30
release_nodes+0x3a/0x120
devres_release_all+0x8a/0xd0
device_unbind_cleanup+0x12/0x80
device_release_driver_internal+0x23a/0x280
? bus_find_device+0xa8/0xe0
device_driver_detach+0x14/0x20
unbind_store+0xaf/0xc0
drv_attr_store+0x21/0x50
sysfs_kf_write+0x4a/0x80
kernfs_fop_write_iter+0x169/0x220
vfs_write+0x293/0x560
ksys_write+0x72/0xf0
__x64_sys_write+0x19/0x30
x64_sys_call+0x2bf/0x2660
do_syscall_64+0x93/0xb60
? __f_unlock_pos+0x15/0x20
? __x64_sys_getdents64+0x9b/0x130
? __pfx_filldir64+0x10/0x10
? do_syscall_64+0x1a2/0xb60
? clear_bhb_loop+0x30/0x80
? clear_bhb_loop+0x30/0x80
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x76e292edd574
Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89
RSP: 002b:00007fffe247a828 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000076e292edd574
RDX: 000000000000000c RSI: 00006267f6306063 RDI: 000000000000000b
RBP: 000000000000000c R08: 000076e292fc4b20 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00006267f6306063
R13: 000000000000000b R14: 00006267e6859c00 R15: 000076e29322a000
</TASK>xe 0000:03:00.0: [drm] Xe device coredump has been deleted.
--- drivers/base/devcoredump.c | 138 +++++++++++++++++++++++++++------------------ 1 file changed, 84 insertions(+), 54 deletions(-)
drivers/base/devcoredump.c +84 -54
@@ -26,50 +26,46 @@ struct devcd_entry {void *data;size_t datalen;/* -* Here, mutex is required to serialize the calls to del_wk work between -* user/kernel space which happens when devcd is added with device_add() -* and that sends uevent to user space. User space reads the uevents, -* and calls to devcd_data_write() which try to modify the work which is -* not even initialized/queued from devcoredump. +* There are 2 races for which mutex is required. * +* The first race is between device creation and userspace writing to +* schedule immediately destruction. * +* This race is handled by arming the timer before device creation, but +* when device creation fails the timer still exists. * -* cpu0(X) cpu1(Y) +* To solve this, hold the mutex during device_add(), and set +* init_completed on success before releasing the mutex. * -* dev_coredump() uevent sent to user space -* device_add() ======================> user space process Y reads the -* uevents writes to devcd fd -* which results into writes to +* That way the timer will never fire until device_add() is called, +* it will do nothing if init_completed is not set. The timer is also +* cancelled in that case. * -* devcd_data_write() -* mod_delayed_work() -* try_to_grab_pending() -* del_timer() -* debug_assert_init() -* INIT_DELAYED_WORK() -* schedule_delayed_work() -* -* -* Also, mutex alone would not be enough to avoid scheduling of -* del_wk work after it get flush from a call to devcd_free() -* mentioned as below. -* -* disabled_store() -* devcd_free() -* mutex_lock() devcd_data_write() -* flush_delayed_work() -* mutex_unlock() -* mutex_lock() -* mod_delayed_work() -* mutex_unlock() -* So, delete_work flag is required. +* The second race involves multiple parallel invocations of devcd_free(), +* add a deleted flag so only 1 can call the destructor. */ struct mutex mutex; -bool delete_work; +bool init_completed, deleted;struct module *owner;ssize_t (*read)(char *buffer,loff_t offset,size_t count,void *data,size_t datalen);void (*free)(void *data); +/* +* If nothing interferes and device_add() was returns success, +* del_wk will destroy the device after the timer fires. +* +* Multiple userspace processes can interfere in the working of the timer: +* - Writing to the coredump will reschedule the timer to run immediately, +* if still armed. +* +* This is handled by using "if (cancel_delayed_work()) { +* schedule_delayed_work() }", to prevent re-arming after having +* been previously fired. +* - Writing to /sys/class/devcoredump/disabled will destroy the +* coredump synchronously. +* This is handled by using disable_delayed_work_sync(), and then +* checking if deleted flag is set with &devcd->mutex held. +*/ struct delayed_work del_wk;struct device *failing_dev; };
@@ -98,14 +94,27 @@ static void devcd_dev_release(struct devkfree (devcd); } +static void __devcd_del (struct devcd_entry *devcd) +{ + devcd->deleted = true; +device_del (&devcd->devcd_dev); +put_device (&devcd->devcd_dev); +} +static void devcd_del (struct work_struct *wk) {struct devcd_entry *devcd; +bool init_completed; devcd = container_of(wk, struct devcd_entry, del_wk.work); -device_del (&devcd->devcd_dev); -put_device (&devcd->devcd_dev); +/* devcd->mutex serializes against dev_coredumpm_timeout */ +mutex_lock (&devcd->mutex); + init_completed = devcd->init_completed; +mutex_unlock (&devcd->mutex); + +if (init_completed) +__devcd_del (devcd); } static ssize_t devcd_data_read(struct file *filp, struct kobject *kobj,
@@ -125,12 +134,12 @@ static ssize_t devcd_data_write(struct fstruct device *dev =kobj_to_dev (kobj);struct devcd_entry *devcd =dev_to_devcd (dev); -mutex_lock (&devcd->mutex); -if (!devcd->delete_work) { - devcd->delete_work = true; -mod_delayed_work (system_wq, &devcd->del_wk,0 ); - } -mutex_unlock (&devcd->mutex); +/* +* Although it's tempting to use mod_delayed work here, +* that will cause a reschedule if the timer already fired. +*/ +if (cancel_delayed_work (&devcd->del_wk)) +schedule_delayed_work (&devcd->del_wk,0 );return count; }
@@ -158,11 +167,21 @@ static int devcd_free(struct device *dev {struct devcd_entry *devcd =dev_to_devcd (dev); +/* +* To prevent a race with devcd_data_write(), cancel work and +* complete manually instead. +* +* We cannot rely on the return value of +* cancel_delayed_work_sync() here, because it might be in the +* middle of a cancel_delayed_work + schedule_delayed_work pair. +* +* devcd->mutex here guards against multiple parallel invocations +* of devcd_free(). +*/ +cancel_delayed_work_sync (&devcd->del_wk);mutex_lock (&devcd->mutex); -if (!devcd->delete_work) - devcd->delete_work = true; - -flush_delayed_work (&devcd->del_wk); +if (!devcd->deleted) +__devcd_del (devcd);mutex_unlock (&devcd->mutex);return 0 ; }
@@ -186,12 +205,10 @@ static ssize_t disabled_show(struct clas* put_device() <- last reference * error = fn(dev, data) devcd_dev_release() * devcd_free(dev, data) kfree(devcd) -* mutex_lock(&devcd->mutex); * * -* In the above diagram, It looks like disabled_store() would be racing with parallely -* running devcd_del() and result in memory abort while acquiring devcd->mutex which -* is called after kfree of devcd memory after dropping its last reference with +* In the above diagram, it looks like disabled_store() would be racing with parallelly +* running devcd_del() and result in memory abort after dropping its last reference with * put_device(). However, this will not happens as fn(dev, data) runs * with its own reference to device via klist_node so it is not its last reference. * so, above situation would not occur.
@@ -353,7 +370,7 @@ void dev_coredumpm(struct device *dev, s devcd->read = read; devcd->free = free; devcd->failing_dev =get_device (dev); - devcd->delete_work = false; + devcd->deleted = false;mutex_init (&devcd->mutex);device_initialize (&devcd->devcd_dev);
@@ -362,8 +379,14 @@ void dev_coredumpm(struct device *dev, s atomic_inc_return(&devcd_count)); devcd->devcd_dev.class = &devcd_class; -mutex_lock (&devcd->mutex);dev_set_uevent_suppress (&devcd->devcd_dev, true); + +/* devcd->mutex prevents devcd_del() completing until init finishes */ +mutex_lock (&devcd->mutex); + devcd->init_completed = false; +INIT_DELAYED_WORK (&devcd->del_wk, devcd_del); +schedule_delayed_work (&devcd->del_wk,DEVCD_TIMEOUT ); +if (device_add (&devcd->devcd_dev)) goto put_device;
@@ -380,13 +403,20 @@ void dev_coredumpm(struct device *dev, sdev_set_uevent_suppress (&devcd->devcd_dev, false);kobject_uevent (&devcd->devcd_dev.kobj,KOBJ_ADD ); -INIT_DELAYED_WORK (&devcd->del_wk, devcd_del); -schedule_delayed_work (&devcd->del_wk,DEVCD_TIMEOUT ); + +/* +* Safe to run devcd_del() now that we are done with devcd_dev. +* Alternatively we could have taken a ref on devcd_dev before +* dropping the lock. +*/ + devcd->init_completed = true;mutex_unlock (&devcd->mutex);return ; put_device: -put_device (&devcd->devcd_dev);mutex_unlock (&devcd->mutex); +cancel_delayed_work_sync (&devcd->del_wk); +put_device (&devcd->devcd_dev); + put_module:module_put (owner); free:
Greg Kroah-Hartman
maintainerPATCH 151/157 x86/resctrl: Fix miscount of bandwidth event when reactivating previously unavailable RMID
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Babu Moger <[email protected]>
[ Upstream commit 15292f1b4c55a3a7c940dbcb6cb8793871ed3d92 ]
Users can create as many monitoring groups as the number of RMIDs supported by the hardware. However, on AMD systems, only a limited number of RMIDs are guaranteed to be actively tracked by the hardware. RMIDs that exceed this limit are placed in an "Unavailable" state.
When a bandwidth counter is read for such an RMID, the hardware sets MSR_IA32_QM_CTR.Unavailable (bit 62). When such an RMID starts being tracked again the hardware counter is reset to zero. MSR_IA32_QM_CTR.Unavailable remains set on first read after tracking re-starts and is clear on all subsequent reads as long as the RMID is tracked.
resctrl miscounts the bandwidth events after an RMID transitions from the "Unavailable" state back to being tracked. This happens because when the hardware starts counting again after resetting the counter to zero, resctrl in turn compares the new count against the counter value stored from the previous time the RMID was tracked.
This results in resctrl computing an event value that is either undercounting (when new counter is more than stored counter) or a mistaken overflow (when new counter is less than stored counter).
Reset the stored value (arch_mbm_state::prev_msr) of MSR_IA32_QM_CTR to zero whenever the RMID is in the "Unavailable" state to ensure accurate counting after the RMID resets to zero when it starts to be tracked again.
Example scenario that results in mistaken overflow
==================================================
1. The resctrl filesystem is mounted, and a task is assigned to a monitoring group.
$mount -t resctrl resctrl /sys/fs/resctrl $mkdir /sys/fs/resctrl/mon_groups/test1/ $echo 1234 > /sys/fs/resctrl/mon_groups/test1/tasks
$cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes
21323 <- Total bytes on domain 0
"Unavailable" <- Total bytes on domain 1
Task is running on domain 0. Counter on domain 1 is "Unavailable".
2. The task runs on domain 0 for a while and then moves to domain 1. The counter starts incrementing on domain 1.
$cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes
7345357 <- Total bytes on domain 0
4545 <- Total bytes on domain 1
3. At some point, the RMID in domain 0 transitions to the "Unavailable" state because the task is no longer executing in that domain.
$cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes
"Unavailable" <- Total bytes on domain 0
434341 <- Total bytes on domain 1
4. Since the task continues to migrate between domains, it may eventually return to domain 0.
$cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes 17592178699059 <- Overflow on domain 0
3232332 <- Total bytes on domain 1
In this case, the RMID on domain 0 transitions from "Unavailable" state to active state. The hardware sets MSR_IA32_QM_CTR.Unavailable (bit 62) when the counter is read and begins tracking the RMID counting from 0.
Subsequent reads succeed but return a value smaller than the previously saved MSR value (7345357). Consequently, the resctrl's overflow logic is triggered, it compares the previous value (7345357) with the new, smaller value and incorrectly interprets this as a counter overflow, adding a large delta.
In reality, this is a false positive: the counter did not overflow but was simply reset when the RMID transitioned from "Unavailable" back to active state.
Here is the text from APM [1] available from [2].
"In PQOS Version 2.0 or higher, the MBM hardware will set the U bit on the first QM_CTR read when it begins tracking an RMID that it was not previously tracking. The U bit will be zero for all subsequent reads from that RMID while it is still tracked by the hardware. Therefore, a QM_CTR read with the U bit set when that RMID is in use by a processor can be considered 0 when calculating the difference with a subsequent read."
[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.3.3 Monitoring L3 Memory Bandwidth (MBM).
[ bp: Split commit message into smaller paragraph chunks for better
consumption. ]
--- arch/x86/kernel/cpu/resctrl/monitor.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
arch/x86/kernel/cpu/resctrl/monitor.c +6 -2
@@ -224,11 +224,15 @@ int resctrl_arch_rmid_read(struct rdt_reif (!cpumask_test_cpu (smp_processor_id (), &d->cpu_mask))return -EINVAL ; + am =get_arch_mbm_state (hw_dom, rmid, eventid); + ret =__rmid_read (rmid, eventid, &msr_val); -if (ret) +if (ret) { +if (am && ret == -EINVAL ) + am->prev_msr =0 ;return ret; + } - am =get_arch_mbm_state (hw_dom, rmid, eventid);if (am) { am->chunks +=mbm_overflow_count (am->prev_msr, msr_val, hw_res->mbm_width);
Re: [PATCH 6.1 151/157] x86/resctrl: Fix miscount of bandwidth event when reactivating previously unavailable RMID
Quoted 99 lines · Greg Kroah-Hartman
6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Babu Moger <[email protected]>
[ Upstream commit
15292f1b4c55a3a7c940dbcb6cb8793871ed3d92]Users can create as many monitoring groups as the number of RMIDs supported by the hardware. However, on AMD systems, only a limited number of RMIDs are guaranteed to be actively tracked by the hardware. RMIDs that exceed this limit are placed in an "Unavailable" state.
When a bandwidth counter is read for such an RMID, the hardware sets MSR_IA32_QM_CTR.Unavailable (bit 62). When such an RMID starts being tracked again the hardware counter is reset to zero. MSR_IA32_QM_CTR.Unavailable remains set on first read after tracking re-starts and is clear on all subsequent reads as long as the RMID is tracked.
resctrl miscounts the bandwidth events after an RMID transitions from the "Unavailable" state back to being tracked. This happens because when the hardware starts counting again after resetting the counter to zero, resctrl in turn compares the new count against the counter value stored from the previous time the RMID was tracked.
This results in resctrl computing an event value that is either undercounting (when new counter is more than stored counter) or a mistaken overflow (when new counter is less than stored counter).
Reset the stored value (
arch_mbm_state::prev_msr) ofMSR_IA32_QM_CTRto zero whenever the RMID is in the "Unavailable" state to ensure accurate counting after the RMID resets to zero when it starts to be tracked again.Example scenario that results in mistaken overflow
==================================================
1. The resctrl filesystem is mounted, and a task is assigned to a monitoring group.$mount -t resctrl resctrl
/sys/fs/resctrl$mkdir/sys/fs/resctrl/mon_groups/test1/$echo 1234 >/sys/fs/resctrl/mon_groups/test1/tasks$cat
/sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes
21323 <- Total bytes on domain 0
"Unavailable" <- Total bytes on domain 1Task is running on domain 0. Counter on domain 1 is "Unavailable".
2. The task runs on domain 0 for a while and then moves to domain 1. The counter starts incrementing on domain 1.
$cat
/sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes
7345357 <- Total bytes on domain 0
4545 <- Total bytes on domain 13. At some point, the RMID in domain 0 transitions to the "Unavailable" state because the task is no longer executing in that domain.
$cat
/sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes
"Unavailable" <- Total bytes on domain 0
434341 <- Total bytes on domain 14. Since the task continues to migrate between domains, it may eventually return to domain 0.
$cat
/sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes17592178699059 <- Overflow on domain 0
3232332 <- Total bytes on domain 1In this case, the RMID on domain 0 transitions from "Unavailable" state to active state. The hardware sets MSR_IA32_QM_CTR.Unavailable (bit 62) when the counter is read and begins tracking the RMID counting from 0.
Subsequent reads succeed but return a value smaller than the previously saved MSR value (7345357). Consequently, the resctrl's overflow logic is triggered, it compares the previous value (7345357) with the new, smaller value and incorrectly interprets this as a counter overflow, adding a large delta.
In reality, this is a false positive: the counter did not overflow but was simply reset when the RMID transitioned from "Unavailable" back to active state.
Here is the text from APM [1] available from [2].
"In PQOS Version 2.0 or higher, the MBM hardware will set the U bit on the first
QM_CTRread when it begins tracking an RMID that it was not previously tracking. The U bit will be zero for all subsequent reads from that RMID while it is still tracked by the hardware. Therefore, aQM_CTRread with the U bit set when that RMID is in use by a processor can be considered 0 when calculating the difference with a subsequent read."[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.3.3 Monitoring L3 Memory Bandwidth (MBM).
[ bp: Split commit message into smaller paragraph chunks for better
consumption. ]
Quoted 10 lines
Fixes 4d05bf71f157d ("x86/resctrl: Introduce AMD QOS feature")Signed-off-by Babu Moger <[email protected]>Signed-off-by Borislav Petkov (AMD) <[email protected]>Reviewed-by Reinette Chatre <[email protected]>Tested-by Reinette Chatre <[email protected]>Cc [email protected] # needs adjustments for <= v6.17(cherry picked from commit 15292f1b4c55a3a7c940dbcb6cb8793871ed3d92)[[email protected]: Fix conflict for v6.1 stable]Signed-off-by Greg Kroah-Hartman <[email protected]>
Thanks
Babu Moger
Greg Kroah-Hartman
maintainerPATCH 152/157 ksmbd: browse interfaces list on FSCTL_QUERY_INTERFACE_INFO IOCTL
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Namjae Jeon <[email protected]>
[ Upstream commit b2d99376c5d61eb60ffdb6c503e4b6c8f9712ddd ]
ksmbd.mount will give each interfaces list and bind_interfaces_only flags to ksmbd server. Previously, the interfaces list was sent only when bind_interfaces_only was enabled.
ksmbd server browse only interfaces list given from ksmbd.conf on FSCTL_QUERY_INTERFACE_INFO IOCTL.
--- fs/smb/server/ksmbd_netlink.h | 3 + fs/smb/server/server.h | 1 fs/smb/server/smb2pdu.c | 4 ++ fs/smb/server/transport_ipc.c | 1 fs/smb/server/transport_tcp.c | 67 +++++++++++++++++++----------------------- fs/smb/server/transport_tcp.h | 1 6 files changed, 40 insertions(+), 37 deletions(-)
fs/smb/server/ksmbd_netlink.h +2 -1
@@ -107,8 +107,9 @@ struct ksmbd_startup_request {__u32 smb2_max_credits;/* MAX credits */ __u32 smbd_max_io_size;/* smbd read write size */ __u32 max_connections;/* Number of maximum simultaneous connections */ +__s8 bind_interfaces_only;__u32 max_ip_connections;/* Number of maximum connection per ip address */ -__u32 reserved[125 ];/* Reserved room */ +__s8 reserved[499 ];/* Reserved room */ __u32 ifc_list_sz;/* interfaces list size */ __s8 ____payload[]; } __packed;
fs/smb/server/server.h +1 -0
@@ -45,6 +45,7 @@ struct ksmbd_server_config {unsigned int max_ip_connections;char *conf[SERVER_CONF_WORK_GROUP +1 ]; +bool bind_interfaces_only; };extern struct ksmbd_server_config server_conf;
fs/smb/server/smb2pdu.c +4 -0
@@ -37,6 +37,7 @@#include "mgmt/user_session.h" #include "mgmt/ksmbd_ida.h" #include "ndr.h" +#include "transport_tcp.h" static void __wbuf (struct ksmbd_work *work,void **req,void **rsp) {
@@ -7423,6 +7424,9 @@ static int fsctl_query_iface_info_ioctl(if (netdev->type ==ARPHRD_LOOPBACK )continue ; +if (!ksmbd_find_netdev_name_iface_list (netdev->name)) +continue ; + flags =dev_get_flags (netdev);if (!(flags &IFF_RUNNING ))continue ;
fs/smb/server/transport_ipc.c +1 -0
@@ -324,6 +324,7 @@ static int ipc_server_config_on_startup( ret =ksmbd_set_netbios_name (req->netbios_name); ret |=ksmbd_set_server_string (req->server_string); ret |=ksmbd_set_work_group (req->work_group); + server_conf.bind_interfaces_only = req->bind_interfaces_only; ret |=ksmbd_tcp_set_interfaces (KSMBD_STARTUP_CONFIG_INTERFACES (req), req->ifc_list_sz); out:
fs/smb/server/transport_tcp.c +31 -36
98 lines not on this page · raw message
fs/smb/server/transport_tcp.h +1 -0
@@ -7,6 +7,7 @@#define __KSMBD_TRANSPORT_TCP_H__int ksmbd_tcp_set_interfaces (char *ifc_list,int ifc_list_sz); +struct interface *ksmbd_find_netdev_name_iface_list (char *netdev_name);int ksmbd_tcp_init (void );void ksmbd_tcp_destroy (void );
Greg Kroah-Hartman
maintainerPATCH 153/157 s390/cio: Update purge function to unregister the unused subchannels
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vineeth Vijayan <[email protected]>
commit 9daa5a8795865f9a3c93d8d1066785b07ded6073 upstream.
Starting with 'commit 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers")', cio no longer unregisters subchannels when the attached device is invalid or unavailable.
As an unintended side-effect, the cio_ignore purge function no longer removes subchannels for devices on the cio_ignore list if no CCW device is attached. This situation occurs when a CCW device is non-operational or unavailable
To ensure the same outcome of the purge function as when the current cio_ignore list had been active during boot, update the purge function to remove I/O subchannels without working CCW devices if the associated device number is found on the cio_ignore list.
--- drivers/s390/cio/device.c | 39 +++++++++++++++++++++++++-------------- 1 file changed, 25 insertions(+), 14 deletions(-)
drivers/s390/cio/device.c +25 -14
@@ -1309,23 +1309,34 @@ void ccw_device_schedule_recovery(void)spin_unlock_irqrestore (&recovery_lock, flags); } -static int purge_fn (struct device *dev,void *data) +static int purge_fn (struct subchannel *sch,void *data) { -struct ccw_device *cdev =to_ccwdev (dev); -struct ccw_dev_id *id = &cdev->private->dev_id; -struct subchannel *sch =to_subchannel (cdev->dev.parent); - -spin_lock_irq (cdev->ccwlock); -if (is_blacklisted (id->ssid, id->devno) && - (cdev->private->state ==DEV_STATE_OFFLINE ) && - (atomic_cmpxchg (&cdev->private->onoff,0 ,1 ) ==0 )) { -CIO_MSG_EVENT (3 ,"ccw: purging 0.%x.%04x\n" , id->ssid, - id->devno); +struct ccw_device *cdev; + +spin_lock_irq (sch->lock); +if (sch->st !=SUBCHANNEL_TYPE_IO || !sch->schib.pmcw.dnv) + goto unlock; + +if (!is_blacklisted (sch->schid.ssid, sch->schib.pmcw.dev)) + goto unlock; + + cdev =sch_get_cdev (sch); +if (cdev) { +if (cdev->private->state !=DEV_STATE_OFFLINE ) + goto unlock; + +if (atomic_cmpxchg (&cdev->private->onoff,0 ,1 ) !=0 ) + goto unlock;ccw_device_sched_todo (cdev,CDEV_TODO_UNREG ); -css_sched_sch_todo (sch,SCH_TODO_UNREG );atomic_set (&cdev->private->onoff,0 ); } -spin_unlock_irq (cdev->ccwlock); + +css_sched_sch_todo (sch,SCH_TODO_UNREG ); +CIO_MSG_EVENT (3 ,"ccw: purging 0.%x.%04x%s\n" , sch->schid.ssid, + sch->schib.pmcw.dev, cdev ?"" :" (no cdev)" ); + +unlock: +spin_unlock_irq (sch->lock);/* Abort loop in case of pending signal. */ if (signal_pending (current))return -EINTR ;
@@ -1341,7 +1352,7 @@ static int purge_fn(struct device *dev,int ccw_purge_blacklisted (void ) {CIO_MSG_EVENT (2 ,"ccw: purging blacklisted devices\n" ); -bus_for_each_dev (&ccw_bus_type,NULL ,NULL , purge_fn); +for_each_subchannel_staged (purge_fn,NULL ,NULL );return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 154/157 mm/ksm: fix flag-dropping behavior in ksm_madvise
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jakub Acs <[email protected]>
commit f04aad36a07cc17b7a5d5b9a2d386ce6fae63e93 upstream.
syzkaller discovered the following crash: (kernel BUG)
[ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460
<snip other registers, drop unreliable trace>
[ 44.617726] Call Trace: [ 44.617926] <TASK> [ 44.619284] userfaultfd_release+0xef/0x1b0 [ 44.620976] __fput+0x3f9/0xb60 [ 44.621240] fput_close_sync+0x110/0x210 [ 44.622222] __x64_sys_close+0x8f/0x120 [ 44.622530] do_syscall_64+0x5b/0x2f0 [ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227
Kernel panics because it detects UFFD inconsistency during
userfaultfd_release_all(). Specifically, a VMA which has a valid pointer to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.
The inconsistency is caused in ksm_madvise(): when user calls madvise() with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vm_flags.
Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VM_MERGEABLE assignment.
VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value.
Fix it by changing VM_MERGEABLE constant to unsigned long, using the BIT() macro.
Note: other VM_* flags are not affected: This only happens to the VM_MERGEABLE flag, as the other VM_* flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s.
Note 2:
After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is no longer a kernel BUG, but a WARNING at the same place:
[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067
but the root-cause (flag-drop) remains the same.
--- include/linux/mm.h | 2 +- rust/bindings/bindings_helper.h | 2 ++ rust/bindings/lib.rs | 1 + 3 files changed, 4 insertions(+), 1 deletion(-)
include/linux/mm.h +1 -1
@@ -316,7 +316,7 @@ extern unsigned int kobjsize(const void#define VM_MIXEDMAP 0x10000000/* Can contain "struct page" and pure PFN pages */ #define VM_HUGEPAGE 0x20000000/* MADV_HUGEPAGE marked this vma */ #define VM_NOHUGEPAGE 0x40000000/* MADV_NOHUGEPAGE marked this vma */ -#define VM_MERGEABLE 0x80000000/* KSM may merge identical pages */ +#define VM_MERGEABLE BIT(31)/* KSM may merge identical pages */ #ifdef CONFIG_ARCH_USES_HIGH_VMA_FLAGS #define VM_HIGH_ARCH_BIT_0 32/* bit only usable on 64-bit architectures */
rust/bindings/bindings_helper.h +2 -0
@@ -7,8 +7,10 @@*/ #include <linux/slab.h> +#include <linux/mm.h> /* `bindgen` gets confused at certain things. */ const size_t BINDINGS_ARCH_SLAB_MINALIGN =ARCH_SLAB_MINALIGN ;const gfp_t BINDINGS_GFP_KERNEL =GFP_KERNEL ;const gfp_t BINDINGS___GFP_ZERO = __GFP_ZERO; +const vm_flags_t BINDINGS_VM_MERGEABLE =VM_MERGEABLE ;
rust/bindings/lib.rs +1 -0
@@ -51,3 +51,4 @@ pub use bindings_raw::*;pub const GFP_KERNEL :gfp_t =BINDINGS_GFP_KERNEL ;pub const __GFP_ZERO:gfp_t =BINDINGS___GFP_ZERO ; +pub const VM_MERGEABLE :vm_flags_t =BINDINGS_VM_MERGEABLE ;
Greg Kroah-Hartman
maintainerPATCH 155/157 Revert "selftests: mm: fix map_hugetlb failure on 64K page size systems"
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Leon Hwang <[email protected]>
This reverts commit a584c7734a4dd050451fcdd65c66317e15660e81 which is commit 91b80cc5b39f00399e8e2d17527cad2c7fa535e2 upstream.
This fixes the following build error:
map_hugetlb.c: In function 'main':
map_hugetlb.c:79:25: warning: implicit declaration of function 'default_huge_page_size' [-Wimplicit-function-declaration]
79 | hugepage_size = default_huge_page_size();
--- tools/testing/selftests/vm/map_hugetlb.c | 7 ------- 1 file changed, 7 deletions(-)
tools/testing/selftests/vm/map_hugetlb.c +0 -7
@@ -15,7 +15,6 @@#include <unistd.h> #include <sys/mman.h> #include <fcntl.h> -#include "vm_util.h" #define LENGTH (256UL*1024*1024)#define PROTECTION (PROT_READ | PROT_WRITE)
@@ -71,16 +70,10 @@ int main(int argc, char **argv) {void *addr;int ret; -size_t hugepage_size;size_t length =LENGTH ;int flags =FLAGS ;int shift =0 ; - hugepage_size =default_huge_page_size (); -/* munmap with fail if the length is not page aligned */ -if (hugepage_size > length) - length = hugepage_size; -if (argc >1 ) length =atol (argv[1 ]) <<20 ;if (argc >2 ) {
Greg Kroah-Hartman
maintainerPATCH 156/157 arm64: cputype: Add Neoverse-V3AE definitions
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
commit 3bbf004c4808e2c3241e5c1ad6cc102f38a03c39 upstream.
Add cputype definitions for Neoverse-V3AE. These will be used for errata detection in subsequent patches.
These values can be found in the Neoverse-V3AE TRM:
https://developer.arm.com/documentation/SDEN-2615521/9-0/
... in section A.6.1 ("MIDR_EL1, Main ID Register").
--- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+)
arch/arm64/include/asm/cputype.h +2 -0
@@ -93,6 +93,7 @@#define ARM_CPU_PART_NEOVERSE_V2 0xD4F#define ARM_CPU_PART_CORTEX_A720 0xD81#define ARM_CPU_PART_CORTEX_X4 0xD82 +#define ARM_CPU_PART_NEOVERSE_V3AE 0xD83#define ARM_CPU_PART_NEOVERSE_V3 0xD84#define ARM_CPU_PART_CORTEX_X925 0xD85#define ARM_CPU_PART_CORTEX_A725 0xD87
@@ -173,6 +174,7 @@#define MIDR_NEOVERSE_V2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V2)#define MIDR_CORTEX_A720 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A720)#define MIDR_CORTEX_X4 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X4) +#define MIDR_NEOVERSE_V3AE MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V3AE)#define MIDR_NEOVERSE_V3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V3)#define MIDR_CORTEX_X925 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X925)#define MIDR_CORTEX_A725 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A725)
Greg Kroah-Hartman
maintainerPATCH 157/157 arm64: errata: Apply workarounds for Neoverse-V3AE
In reply to Greg Kroah-Hartman6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
commit 0c33aa1804d101c11ba1992504f17a42233f0e11 upstream.
Neoverse-V3AE is also affected by erratum #3312417, as described in its Software Developer Errata Notice (SDEN) document:
Neoverse V3AE (MP172) SDEN v9.0, erratum 3312417
https://developer.arm.com/documentation/SDEN-2615521/9-0/
Enable the workaround for Neoverse-V3AE, and document this.
--- Documentation/arm64/silicon-errata.rst | 2 ++ arch/arm64/Kconfig | 1 + arch/arm64/kernel/cpu_errata.c | 1 + 3 files changed, 4 insertions(+)
Documentation/arm64/silicon-errata.rst +2 -0
@@ -181,6 +181,8 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-V3 | #3312417 | ARM64_ERRATUM_3194386 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Neoverse-V3AE | #3312417 | ARM64_ERRATUM_3194386 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | MMU-500 | #841119,826419 | N/A | +----------------+-----------------+-----------------+-----------------------------+ | ARM | MMU-600 | #1076982,1209401| N/A |
arch/arm64/Kconfig +1 -0
@@ -1027,6 +1027,7 @@ config ARM64_ERRATUM_3194386 * ARM Neoverse-V1 erratum 3324341 * ARM Neoverse V2 erratum 3324336 * ARM Neoverse-V3 erratum 3312417 + * ARM Neoverse-V3AE erratum 3312417 On affected cores "MSR SSBS, #0" instructions may not affect subsequent speculative instructions, which may permit unexepected
arch/arm64/kernel/cpu_errata.c +1 -0
@@ -457,6 +457,7 @@ static const struct midr_range erratum_sMIDR_ALL_VERSIONS (MIDR_NEOVERSE_V1 ),MIDR_ALL_VERSIONS (MIDR_NEOVERSE_V2 ),MIDR_ALL_VERSIONS (MIDR_NEOVERSE_V3 ), + MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V3AE), {} };#endif
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.158 release. There are 157 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 29 Oct 2025 18:34:15 +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.1.158-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.158 release. There are 157 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 29 Oct 2025 18:34:15 +0000. Anything received after that time might be too late.
6.1.158-rc1 built and run on x86_64 test system with no errors or regressions:
Slade
Am 27.10.2025 um 19:34 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.1.158 release. There are 157 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.158 release. There are 157 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 29 Oct 2025 18:34:15 +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.1.158-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 6.1.158-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: f6fcaf2c6b7f6ed4e6ee10532555e1e16764c435
* git describe: v6.1.157-158-gf6fcaf2c6b7f
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.157-158-gf6fcaf2c6b7f
## Test Regressions (compared to v6.1.156-169-gec44a71e7948)
## Metric Regressions (compared to v6.1.156-169-gec44a71e7948)
## Test Fixes (compared to v6.1.156-169-gec44a71e7948)
## Metric Fixes (compared to v6.1.156-169-gec44a71e7948)
## Test result summary
total: 86941, pass: 72310, fail: 2561, skip: 11898, xfail: 172
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 133 total, 132 passed, 1 failed
* arm64: 41 total, 38 passed, 3 failed
* i386: 21 total, 21 passed, 0 failed
* mips: 26 total, 25 passed, 1 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 32 total, 31 passed, 1 failed
* riscv: 11 total, 10 passed, 1 failed
* s390: 14 total, 13 passed, 1 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 7 total, 7 passed, 0 failed
* x86_64: 33 total, 32 passed, 1 failed
## Test suites summary
* boot
* commands
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-exec
* kselftest-fpu
* kselftest-futex
* kselftest-intel_pstate
* kselftest-kcmp
* kselftest-kvm
* kselftest-livepatch
* kselftest-membarrier
* kselftest-mincore
* kselftest-mqueue
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-sigaltstack
* kselftest-size
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-x86
* kunit
* kvm-unit-tests
* lava
* 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-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* 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 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.158 release. There are 157 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 29 Oct 2025 18:34:15 +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.1.158-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.1:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
119 tests: 119 pass, 0 failLinux version: 6.1.158-rc1-gf6fcaf2c6b7f
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.158 release. There are 157 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 29 Oct 2025 18:34:15 +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.1.158-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
# Librecast Test Results
020/020 [ OK ] liblcrq
010/010 [ OK ] libmld
120/120 [ OK ] liblibrecast
CPU/kernel: Linux auntie 6.1.158-rc1-00158-gf6fcaf2c6b7f #121 SMP PREEMPT_DYNAMIC Tue Oct 28 13:34:21 -00 2025 x86_64 AMD Ryzen 9 9950X 16-Core Processor AuthenticAMD GNU/Linux
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.158 release. There are 157 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 29 Oct 2025 18:34:15 +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.1.158-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 8 lines · On Mon, 27 Oct 2025 19:34:21 +0100 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.1.158 release. There are 157 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 29 Oct 2025 18:34:15 +0000. Anything received after that time might be too late.
Boot-tested under QEMU for Rust x86_64:
Thanks!
Cheers,
Miguel
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 6.1.158 release. There are 157 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.1.y
Best regards,
Pavel
Signature · 2 lines
In cooperation with DENX Software Engineering GmbH, HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany