- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10 0/4] A Solution to Re-enable hugetlb vmemmap optimize on ARM64
by Nanyong Sun 18 Jun '24

18 Jun '24

HVO was previously disabled on arm64 [1] due to the lack of necessary BBM(break-before-make) logic when changing page tables. This set of patches fix this by adding necessary BBM sequence when changing page table, and supporting vmemmap page fault handling to fixup kernel address translation fault if vmemmap is concurrently accessed. I have tested this patch set with concurrently accessing the vmemmap address when do BBM and can recover by vmemmap fault handler. Also tested under the config of 2/3/4 pgtable levels with 4K/64K page size and all works well. [1] commit 060a2c92d1b6 ("arm64: mm: hugetlb: Disable HUGETLB_PAGE_OPTIMIZE_VMEMMAP") Mark Rutland (1): arm64: mm: kfence: only handle translation faults Nanyong Sun (2): mm: HVO: introduce helper function to update and flush pgtable arm64: mm: HVO: support BBM of vmemmap pgtable safely Wang Kefeng (1): ARM: 9278/1: kfence: only handle translation faults arch/arm/mm/fault.c | 18 +++++- arch/arm/mm/fault.h | 9 ++- arch/arm64/include/asm/esr.h | 4 ++ arch/arm64/include/asm/pgtable.h | 6 ++ arch/arm64/include/asm/tlbflush.h | 16 +++++ arch/arm64/mm/fault.c | 98 +++++++++++++++++++++++++++++-- arch/arm64/mm/mmu.c | 29 +++++++++ mm/sparse-vmemmap.c | 49 +++++++++++++--- 8 files changed, 211 insertions(+), 18 deletions(-) -- 2.25.1

2 5

[openeuler:openEuler-1.0-LTS 11564/22966] drivers/net/ethernet/hisilicon/hns3/hns3_cae/hns3_cae_init.c:53:14: sparse: sparse: symbol 'g_hns3_cae_class' was not declared. Should it be static?
by kernel test robot 18 Jun '24

18 Jun '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 26bfb7d9b0ef31487312e8e9e6eb097acaf5d739 commit: 9e1cec03a3abb934592272fc19603d00bb62f7cb [11564/22966] net: hns3: place cae entrance procedure implementations in a separate file config: arm64-randconfig-r111-20240615 (https://download.01.org/0day-ci/archive/20240618/202406182019.kf6McR7e-lkp@…) compiler: aarch64-linux-gcc (GCC) 13.2.0 reproduce: (https://download.01.org/0day-ci/archive/20240618/202406182019.kf6McR7e-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202406182019.kf6McR7e-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> drivers/net/ethernet/hisilicon/hns3/hns3_cae/hns3_cae_init.c:53:14: sparse: sparse: symbol 'g_hns3_cae_class' was not declared. Should it be static? >> drivers/net/ethernet/hisilicon/hns3/hns3_cae/hns3_cae_init.c:54:13: sparse: sparse: symbol 'g_hns3_cae_cdev' was not declared. Should it be static? >> drivers/net/ethernet/hisilicon/hns3/hns3_cae/hns3_cae_init.c:57:5: sparse: sparse: symbol 'g_hns3_cae_init_flag' was not declared. Should it be static? >> drivers/net/ethernet/hisilicon/hns3/hns3_cae/hns3_cae_init.c:58:5: sparse: sparse: symbol 'g_hns3_cae_ref_cnt' was not declared. Should it be static? >> drivers/net/ethernet/hisilicon/hns3/hns3_cae/hns3_cae_init.c:96:43: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const [noderef] <asn:1> *from @@ got void *in_buff @@ drivers/net/ethernet/hisilicon/hns3/hns3_cae/hns3_cae_init.c:96:43: sparse: expected void const [noderef] <asn:1> *from drivers/net/ethernet/hisilicon/hns3/hns3_cae/hns3_cae_init.c:96:43: sparse: got void *in_buff >> drivers/net/ethernet/hisilicon/hns3/hns3_cae/hns3_cae_init.c:139:32: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:1> *to @@ got void *out_buf @@ drivers/net/ethernet/hisilicon/hns3/hns3_cae/hns3_cae_init.c:139:32: sparse: expected void [noderef] <asn:1> *to drivers/net/ethernet/hisilicon/hns3/hns3_cae/hns3_cae_init.c:139:32: sparse: got void *out_buf >> drivers/net/ethernet/hisilicon/hns3/hns3_cae/hns3_cae_init.c:318:38: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const [noderef] <asn:1> *from @@ got void * @@ drivers/net/ethernet/hisilicon/hns3/hns3_cae/hns3_cae_init.c:318:38: sparse: expected void const [noderef] <asn:1> *from drivers/net/ethernet/hisilicon/hns3/hns3_cae/hns3_cae_init.c:318:38: sparse: got void * vim +/g_hns3_cae_class +53 drivers/net/ethernet/hisilicon/hns3/hns3_cae/hns3_cae_init.c 52 > 53 struct class *g_hns3_cae_class; > 54 struct cdev g_hns3_cae_cdev; 55 static const char hns3_driver_name[] = "hns3"; 56 > 57 int g_hns3_cae_init_flag; > 58 int g_hns3_cae_ref_cnt; 59 60 typedef int (*driv_module) (struct hns3_nic_priv *nic_dev, void *buf_in, 61 u32 in_size, void *buf_out, u32 out_size); 62 63 struct drv_module_handle { 64 enum driver_cmd_type driv_cmd_name; 65 driv_module driv_func; 66 }; 67 68 static void free_buff_in(void *buf_in) 69 { 70 if (!buf_in) 71 return; 72 73 kfree(buf_in); 74 } 75 76 static int alloc_buff_in(struct msg_module *nt_msg, u32 in_size, void **buf_in) 77 { 78 void *msg_buf; 79 80 if (!in_size) 81 return 0; 82 83 if (in_size > MAX_MSG_IN_SIZE) { 84 pr_err("msg in size(%u) more than %u\n", 85 in_size, MAX_MSG_IN_SIZE); 86 return -ENOMEM; 87 } 88 89 msg_buf = kzalloc((unsigned long)in_size, GFP_KERNEL); 90 *buf_in = msg_buf; 91 if (ZERO_OR_NULL_PTR(*buf_in)) { 92 pr_err("alloc buf_in failed\n"); 93 return -ENOMEM; 94 } 95 > 96 if (copy_from_user(msg_buf, nt_msg->in_buff, (unsigned long)in_size)) { 97 pr_err("Copy from user failed in %s function\n", __func__); 98 kfree(msg_buf); 99 return -EFAULT; 100 } 101 102 return 0; 103 } 104 105 static void free_buff_out(void *buf_out) 106 { 107 if (!buf_out) 108 return; 109 110 kfree(buf_out); 111 } 112 113 static int alloc_buff_out(u32 out_size, void **buf_out) 114 { 115 if (!out_size) 116 return 0; 117 118 if (out_size > MAX_MSG_OUT_SIZE) { 119 pr_err("msg out size(%u) more than %u\n", 120 out_size, MAX_MSG_OUT_SIZE); 121 return -ENOMEM; 122 } 123 124 *buf_out = kzalloc((unsigned long)out_size, GFP_KERNEL); 125 if (ZERO_OR_NULL_PTR(*buf_out)) { 126 pr_err("alloc buf_out failed\n"); 127 return -ENOMEM; 128 } 129 130 return 0; 131 } 132 133 static int copy_buf_out_to_user(struct msg_module *nt_msg, u32 out_size, 134 void **buf_out) 135 { 136 int ret = 0; 137 void *msg_out = buf_out; 138 > 139 if (copy_to_user(nt_msg->out_buf, msg_out, out_size)) 140 ret = -EFAULT; 141 142 return ret; 143 } 144 145 static int hns3_cae_netdev_match_check(struct net_device *netdev) 146 { 147 struct ethtool_drvinfo drv_info; 148 149 if (netdev->ethtool_ops->get_drvinfo) 150 netdev->ethtool_ops->get_drvinfo(netdev, &drv_info); 151 152 if (!strncmp(drv_info.driver, hns3_driver_name, 153 strlen(hns3_driver_name))) 154 return 0; 155 156 netdev_err(netdev, "match hns3 driver name(%s) failed\n", 157 drv_info.driver); 158 return -1; 159 } 160 161 #if (KERNEL_VERSION(4, 16, 0) < LINUX_VERSION_CODE) 162 static int kernel_sock_ioctl(struct socket *sock, int cmd, unsigned long arg) 163 { 164 mm_segment_t oldfs = get_fs(); 165 int err; 166 167 set_fs(KERNEL_DS); 168 err = sock->ops->ioctl(sock, cmd, arg); 169 set_fs(oldfs); 170 171 return err; 172 } 173 #endif 174 175 static struct net_device *get_netdev_by_ifname(char *ifname) 176 { 177 struct socket *temp_sock = NULL; 178 struct net_device *netdev = NULL; 179 struct ifreq ifr; 180 int err; 181 182 err = sock_create(PF_INET, SOCK_DGRAM, 0, &temp_sock); 183 if (err < 0) { 184 pr_err("fail to enter sock_create, err = %d\n", err); 185 return NULL; 186 } 187 188 strncpy(ifr.ifr_ifrn.ifrn_name, ifname, (unsigned long)IFNAMSIZ); 189 kernel_sock_ioctl(temp_sock, SIOCSIFNAME, (unsigned long)&ifr); 190 netdev = dev_get_by_name(sock_net(temp_sock->sk), ifname); 191 if (!netdev) 192 goto out; 193 194 dev_put(netdev); 195 196 out: 197 sock_release(temp_sock); 198 return netdev; 199 } 200 201 static int hns3_cae_k_get_netdev_by_ifname(char *ifname, 202 struct hns3_nic_priv **nic_dev) 203 { 204 struct net_device *netdev = NULL; 205 206 netdev = get_netdev_by_ifname(ifname); 207 if (!netdev) { 208 pr_err("not find the netdevice(%s)!\n", ifname); 209 return -EFAULT; 210 } 211 212 if (hns3_cae_netdev_match_check(netdev)) { 213 netdev_err(netdev, "netdevice is not hns device.\n"); 214 return -EFAULT; 215 } 216 217 *nic_dev = (struct hns3_nic_priv *)netdev_priv(netdev); 218 if (!(*nic_dev)) { 219 netdev_err(netdev, "no private data\n"); 220 return -EFAULT; 221 } 222 223 return 0; 224 } 225 > 226 struct drv_module_handle driv_module_cmd_handle[] = { 227 {FW_VER, hns3_cae_get_fw_ver}, 228 {DRIVER_VER, hns3_cae_get_driver_ver}, 229 {CHECKSUM_CFG, hns3_cae_chs_cfg}, 230 {TM_QUEUE_CFG, hns3_cae_queue_cfg}, 231 {TM_QSET_CFG, hns3_cae_qs_cfg}, 232 {TM_PRI_CFG, hns3_cae_pri_cfg}, 233 {TM_PG_CFG, hns3_cae_pg_cfg}, 234 {TM_PORT_CFG, hns3_cae_port_cfg}, 235 {TM_ETS_CFG, hns3_cae_ets_cfg}, 236 {DCB_MODE_CFG, hns3_cae_dcb_cfg}, 237 {ETS_MODE_CFG, hns3_cae_dcb_ets_cfg}, 238 {PFC_MODE_CFG, hns3_cae_dcb_pfc_cfg}, 239 {MAC_LOOP_CFG, hns3_cae_mac_loop_cfg}, 240 {DFX_INFO_CMD, hns3_cae_get_dfx_info}, 241 {DFX_READ_CMD, hns3_cae_read_dfx_info}, 242 {EVENT_INJECTION_CMD, hns3_cae_event_injection}, 243 {SEND_PKT, hns3_cae_send_pkt}, 244 {RX_PRIV_BUFF_WL_CFG, hns3_cae_rx_priv_buff_wl_cfg}, 245 {RX_COMMON_THRD_CFG, hns3_cae_common_thrd_cfg}, 246 {RX_COMMON_WL_CFG, hns3_cae_common_wl_cfg}, 247 {SHOW_RX_PRIV_WL, hns3_cae_show_rx_priv_wl}, 248 {SHOW_RX_COMM_THRES, hns3_cae_show_comm_thres}, 249 {QCN_EN_CFG, hns3_cae_qcn_cfg}, 250 {RX_BUFF_CFG, hns3_cae_rx_buff_cfg}, 251 {TX_BUFF_CFG, hns3_cae_tx_buff_cfg}, 252 {RESET_CFG, hns3_cae_nic_reset}, 253 {TIMEOUT_CFG, hns3_cae_nic_timeout_cfg}, 254 {PROMISC_MODE_CFG, hns3_promisc_mode_cfg}, 255 {QINFO_CFG, hns3_cae_qinfo_cfg}, 256 #ifdef CONFIG_IT_VALIDATION 257 {MACTABLE_CFG, hns3_cae_opt_mactbl}, 258 #endif 259 {CLEAN_STATS, hns3_cae_clean_stats}, 260 {FD_CFG, hns3_cae_fd_cfg}, 261 {RSS_GENERIC_CFG, hns3_cae_rss_cfg}, 262 {REG_CFG, hns3_cae_reg_cfg}, 263 {COM_REG_CFG, hns3_cae_common_cmd_send}, 264 {GRO_CFG, hns3_gro_age_handle}, 265 {M7_CMD_MODE_CFG, hns3_m7_cmd_handle}, 266 {QRES_CFG, hns3_cae_qres_cfg}, 267 {STAT_CFG, hns3_stat_mode_cfg}, 268 {IRQ_CFG, hns3_irq_lli_cfg}, 269 {VLAN_UPMAPPING, hns3_cae_upmapping_cfg}, 270 #ifdef CONFIG_EXT_TEST 271 {LAMP_CFG, hns3_lamp_cfg}, 272 {EXTERN_INTERFACE_CFG, hns3_ext_interface_test}, 273 #endif 274 {XSFP_CFG, hns3_xsfp_cfg}, 275 {SHOW_PORT_INFO, hns3_get_port_info}, 276 {SHOW_HILINK_PARAM, hns3_get_hilink_param}, 277 {DCQCN_PARM_CFG, hns3_nic_dcqcn}, 278 {DCQCN_GET_MSG_CNT_CMD, hns3_dcqcn_get_msg_cnt} 279 }; 280 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-22.03-LTS-SP1 0/2] genirq: introduce handle_fasteoi_edge_irq flow handler
by Yipeng Zou 18 Jun '24

18 Jun '24

Rebase to here Yipeng Zou (2): genirq: introduce handle_fasteoi_edge_irq flow handler genirq: introduce handle_fasteoi_edge_irq for phytium drivers/irqchip/irq-gic-phytium-2500.c | 2 +- drivers/irqchip/irq-gic-v3.c | 2 +- include/linux/irq.h | 1 + kernel/irq/chip.c | 67 ++++++++++++++++++++++++++ 4 files changed, 70 insertions(+), 2 deletions(-) -- 2.34.1

2 3

[PATCH OLK-5.10 0/3] A Solution to Re-enable hugetlb vmemmap optimize on ARM64
by Nanyong Sun 18 Jun '24

18 Jun '24

HVO was previously disabled on arm64 [1] due to the lack of necessary BBM(break-before-make) logic when changing page tables. This set of patches fix this by adding necessary BBM sequence when changing page table, and supporting vmemmap page fault handling to fixup kernel address translation fault if vmemmap is concurrently accessed. I have tested this patch set with concurrently accessing the vmemmap address when do BBM and can recover by vmemmap fault handler. Also tested under the config of 2/3/4 pgtable levels with 4K/64K page size and all works well. [1] commit 060a2c92d1b6 ("arm64: mm: hugetlb: Disable HUGETLB_PAGE_OPTIMIZE_VMEMMAP") Mark Rutland (1): arm64: mm: kfence: only handle translation faults Nanyong Sun (2): mm: HVO: introduce helper function to update and flush pgtable arm64: mm: HVO: support BBM of vmemmap pgtable safely arch/arm64/include/asm/esr.h | 4 ++ arch/arm64/include/asm/pgtable.h | 6 ++ arch/arm64/include/asm/tlbflush.h | 16 +++++ arch/arm64/mm/fault.c | 98 +++++++++++++++++++++++++++++-- arch/arm64/mm/mmu.c | 29 +++++++++ mm/sparse-vmemmap.c | 49 +++++++++++++--- 6 files changed, 189 insertions(+), 13 deletions(-) -- 2.25.1

2 4

[PATCH OLK-5.10 0/2] genirq: introduce handle_fasteoi_edge_irq flow handler
by Yipeng Zou 18 Jun '24

18 Jun '24

Rebase to here Yipeng Zou (2): genirq: introduce handle_fasteoi_edge_irq flow handler genirq: introduce handle_fasteoi_edge_irq for phytium drivers/irqchip/irq-gic-phytium-2500.c | 2 +- drivers/irqchip/irq-gic-v3.c | 2 +- include/linux/irq.h | 1 + kernel/irq/chip.c | 67 ++++++++++++++++++++++++++ 4 files changed, 70 insertions(+), 2 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6] xfs: don't use current->journal_info
by Zhihao Cheng 18 Jun '24

18 Jun '24

From: Dave Chinner <dchinner(a)redhat.com> mainline inclusion from mainline-v6.9-rc2 commit f2e812c1522dab847912309b00abcc762dd696da category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA6CG1 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------------- syzbot reported an ext4 panic during a page fault where found a journal handle when it didn't expect to find one. The structure it tripped over had a value of 'TRAN' in the first entry in the structure, and that indicates it tripped over a struct xfs_trans instead of a jbd2 handle. The reason for this is that the page fault was taken during a copy-out to a user buffer from an xfs bulkstat operation. XFS uses an "empty" transaction context for bulkstat to do automated metadata buffer cleanup, and so the transaction context is valid across the copyout of the bulkstat info into the user buffer. We are using empty transaction contexts like this in XFS to reduce the risk of failing to release objects we reference during the operation, especially during error handling. Hence we really need to ensure that we can take page faults from these contexts without leaving landmines for the code processing the page fault to trip over. However, this same behaviour could happen from any other filesystem that triggers a page fault or any other exception that is handled on-stack from within a task context that has current->journal_info set. Having a page fault from some other filesystem bounce into XFS where we have to run a transaction isn't a bug at all, but the usage of current->journal_info means that this could result corruption of the outer task's journal_info structure. The problem is purely that we now have two different contexts that now think they own current->journal_info. IOWs, no filesystem can allow page faults or on-stack exceptions while current->journal_info is set by the filesystem because the exception processing might use current->journal_info itself. If we end up with nested XFS transactions whilst holding an empty transaction, then it isn't an issue as the outer transaction does not hold a log reservation. If we ignore the current->journal_info usage, then the only problem that might occur is a deadlock if the exception tries to take the same locks the upper context holds. That, however, is not a problem that setting current->journal_info would solve, so it's largely an irrelevant concern here. IOWs, we really only use current->journal_info for a warning check in xfs_vm_writepages() to ensure we aren't doing writeback from a transaction context. Writeback might need to do allocation, so it can need to run transactions itself. Hence it's a debug check to warn us that we've done something silly, and largely it is not all that useful. So let's just remove all the use of current->journal_info in XFS and get rid of all the potential issues from nested contexts where current->journal_info might get misused by another filesystem context. Reported-by: syzbot+cdee56dbcdf0096ef605(a)syzkaller.appspotmail.com Signed-off-by: Dave Chinner <dchinner(a)redhat.com> Reviewed-by: "Darrick J. Wong" <djwong(a)kernel.org> Reviewed-by: Mark Tinguely <mark.tinguely(a)oracle.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Chandan Babu R <chandanbabu(a)kernel.org> Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> --- fs/xfs/scrub/common.c | 4 +--- fs/xfs/xfs_aops.c | 7 ------- fs/xfs/xfs_icache.c | 8 +++++--- fs/xfs/xfs_trans.h | 9 +-------- 4 files changed, 7 insertions(+), 21 deletions(-) diff --git a/fs/xfs/scrub/common.c b/fs/xfs/scrub/common.c index 23944fcc1a6c..08e292485268 100644 --- a/fs/xfs/scrub/common.c +++ b/fs/xfs/scrub/common.c @@ -978,9 +978,7 @@ xchk_irele( struct xfs_scrub *sc, struct xfs_inode *ip) { - if (current->journal_info != NULL) { - ASSERT(current->journal_info == sc->tp); - + if (sc->tp) { /* * If we are in a transaction, we /cannot/ drop the inode * ourselves, because the VFS will trigger writeback, which diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c index a2e1f73f84dd..82f18f28c1c1 100644 --- a/fs/xfs/xfs_aops.c +++ b/fs/xfs/xfs_aops.c @@ -477,13 +477,6 @@ xfs_vm_writepages( { struct xfs_writepage_ctx wpc = { }; - /* - * Writing back data in a transaction context can result in recursive - * transactions. This is bad, so issue a warning and get out of here. - */ - if (WARN_ON_ONCE(current->journal_info)) - return 0; - xfs_iflags_clear(XFS_I(mapping->host), XFS_ITRUNCATED); return iomap_writepages(mapping, wbc, &wpc.ctx, &xfs_writeback_ops); } diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index f4971bd1de05..370c0df1a7a5 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -2037,8 +2037,10 @@ xfs_inodegc_want_queue_work( * - Memory shrinkers queued the inactivation worker and it hasn't finished. * - The queue depth exceeds the maximum allowable percpu backlog. * - * Note: If the current thread is running a transaction, we don't ever want to - * wait for other transactions because that could introduce a deadlock. + * Note: If we are in a NOFS context here (e.g. current thread is running a + * transaction) the we don't want to block here as inodegc progress may require + * filesystem resources we hold to make progress and that could result in a + * deadlock. Hence we skip out of here if we are in a scoped NOFS context. */ static inline bool xfs_inodegc_want_flush_work( @@ -2046,7 +2048,7 @@ xfs_inodegc_want_flush_work( unsigned int items, unsigned int shrinker_hits) { - if (current->journal_info) + if (current->flags & PF_MEMALLOC_NOFS) return false; if (shrinker_hits > 0) diff --git a/fs/xfs/xfs_trans.h b/fs/xfs/xfs_trans.h index 4e38357237c3..ead65f5f8dc3 100644 --- a/fs/xfs/xfs_trans.h +++ b/fs/xfs/xfs_trans.h @@ -277,19 +277,14 @@ static inline void xfs_trans_set_context( struct xfs_trans *tp) { - ASSERT(current->journal_info == NULL); tp->t_pflags = memalloc_nofs_save(); - current->journal_info = tp; } static inline void xfs_trans_clear_context( struct xfs_trans *tp) { - if (current->journal_info == tp) { - memalloc_nofs_restore(tp->t_pflags); - current->journal_info = NULL; - } + memalloc_nofs_restore(tp->t_pflags); } static inline void @@ -297,10 +292,8 @@ xfs_trans_switch_context( struct xfs_trans *old_tp, struct xfs_trans *new_tp) { - ASSERT(current->journal_info == old_tp); new_tp->t_pflags = old_tp->t_pflags; old_tp->t_pflags = 0; - current->journal_info = new_tp; } #endif /* __XFS_TRANS_H__ */ -- 2.31.1

2 1

[PATCH OLK-5.10] xfs: don't use current->journal_info
by Zhihao Cheng 18 Jun '24

18 Jun '24

From: Dave Chinner <dchinner(a)redhat.com> mainline inclusion from mainline-v6.9-rc2 commit f2e812c1522dab847912309b00abcc762dd696da category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA6CG1 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------------- syzbot reported an ext4 panic during a page fault where found a journal handle when it didn't expect to find one. The structure it tripped over had a value of 'TRAN' in the first entry in the structure, and that indicates it tripped over a struct xfs_trans instead of a jbd2 handle. The reason for this is that the page fault was taken during a copy-out to a user buffer from an xfs bulkstat operation. XFS uses an "empty" transaction context for bulkstat to do automated metadata buffer cleanup, and so the transaction context is valid across the copyout of the bulkstat info into the user buffer. We are using empty transaction contexts like this in XFS to reduce the risk of failing to release objects we reference during the operation, especially during error handling. Hence we really need to ensure that we can take page faults from these contexts without leaving landmines for the code processing the page fault to trip over. However, this same behaviour could happen from any other filesystem that triggers a page fault or any other exception that is handled on-stack from within a task context that has current->journal_info set. Having a page fault from some other filesystem bounce into XFS where we have to run a transaction isn't a bug at all, but the usage of current->journal_info means that this could result corruption of the outer task's journal_info structure. The problem is purely that we now have two different contexts that now think they own current->journal_info. IOWs, no filesystem can allow page faults or on-stack exceptions while current->journal_info is set by the filesystem because the exception processing might use current->journal_info itself. If we end up with nested XFS transactions whilst holding an empty transaction, then it isn't an issue as the outer transaction does not hold a log reservation. If we ignore the current->journal_info usage, then the only problem that might occur is a deadlock if the exception tries to take the same locks the upper context holds. That, however, is not a problem that setting current->journal_info would solve, so it's largely an irrelevant concern here. IOWs, we really only use current->journal_info for a warning check in xfs_vm_writepages() to ensure we aren't doing writeback from a transaction context. Writeback might need to do allocation, so it can need to run transactions itself. Hence it's a debug check to warn us that we've done something silly, and largely it is not all that useful. So let's just remove all the use of current->journal_info in XFS and get rid of all the potential issues from nested contexts where current->journal_info might get misused by another filesystem context. Reported-by: syzbot+cdee56dbcdf0096ef605(a)syzkaller.appspotmail.com Signed-off-by: Dave Chinner <dchinner(a)redhat.com> Reviewed-by: "Darrick J. Wong" <djwong(a)kernel.org> Reviewed-by: Mark Tinguely <mark.tinguely(a)oracle.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Chandan Babu R <chandanbabu(a)kernel.org> Conflicts: fs/xfs/scrub/common.c fs/xfs/xfs_aops.c [ a03297a0ca9f2("xfs: manage inode DONTCACHE status at irele time") is not applied. 21b4ee7029c90("xfs: drop ->writepage completely") is not applied.] Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> --- fs/xfs/xfs_aops.c | 13 ------------- fs/xfs/xfs_icache.c | 8 +++++--- fs/xfs/xfs_trans.h | 9 +-------- 3 files changed, 6 insertions(+), 24 deletions(-) diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c index ef7db9defef1..e751cf34ccba 100644 --- a/fs/xfs/xfs_aops.c +++ b/fs/xfs/xfs_aops.c @@ -552,12 +552,6 @@ xfs_vm_writepage( { struct xfs_writepage_ctx wpc = { }; - if (WARN_ON_ONCE(current->journal_info)) { - redirty_page_for_writepage(wbc, page); - unlock_page(page); - return 0; - } - return iomap_writepage(page, wbc, &wpc.ctx, &xfs_writeback_ops); } @@ -568,13 +562,6 @@ xfs_vm_writepages( { struct xfs_writepage_ctx wpc = { }; - /* - * Writing back data in a transaction context can result in recursive - * transactions. This is bad, so issue a warning and get out of here. - */ - if (WARN_ON_ONCE(current->journal_info)) - return 0; - xfs_iflags_clear(XFS_I(mapping->host), XFS_ITRUNCATED); return iomap_writepages(mapping, wbc, &wpc.ctx, &xfs_writeback_ops); } diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index bdf55ed88680..fae443e0d120 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -2043,8 +2043,10 @@ xfs_inodegc_want_queue_work( * - Memory shrinkers queued the inactivation worker and it hasn't finished. * - The queue depth exceeds the maximum allowable percpu backlog. * - * Note: If the current thread is running a transaction, we don't ever want to - * wait for other transactions because that could introduce a deadlock. + * Note: If we are in a NOFS context here (e.g. current thread is running a + * transaction) the we don't want to block here as inodegc progress may require + * filesystem resources we hold to make progress and that could result in a + * deadlock. Hence we skip out of here if we are in a scoped NOFS context. */ static inline bool xfs_inodegc_want_flush_work( @@ -2052,7 +2054,7 @@ xfs_inodegc_want_flush_work( unsigned int items, unsigned int shrinker_hits) { - if (current->journal_info) + if (current->flags & PF_MEMALLOC_NOFS) return false; if (shrinker_hits > 0) diff --git a/fs/xfs/xfs_trans.h b/fs/xfs/xfs_trans.h index 731af3f04c83..d512fdd5f7c3 100644 --- a/fs/xfs/xfs_trans.h +++ b/fs/xfs/xfs_trans.h @@ -271,19 +271,14 @@ static inline void xfs_trans_set_context( struct xfs_trans *tp) { - ASSERT(current->journal_info == NULL); tp->t_pflags = memalloc_nofs_save(); - current->journal_info = tp; } static inline void xfs_trans_clear_context( struct xfs_trans *tp) { - if (current->journal_info == tp) { - memalloc_nofs_restore(tp->t_pflags); - current->journal_info = NULL; - } + memalloc_nofs_restore(tp->t_pflags); } static inline void @@ -291,10 +286,8 @@ xfs_trans_switch_context( struct xfs_trans *old_tp, struct xfs_trans *new_tp) { - ASSERT(current->journal_info == old_tp); new_tp->t_pflags = old_tp->t_pflags; old_tp->t_pflags = 0; - current->journal_info = new_tp; } #endif /* __XFS_TRANS_H__ */ -- 2.31.1

2 1

[PATCH OLK-5.10] xfs: don't use current->journal_info
by Zhihao Cheng 18 Jun '24

18 Jun '24

From: Dave Chinner <dchinner(a)redhat.com> mainline inclusion from mainline-v6.9-rc2 commit f2e812c1522dab847912309b00abcc762dd696da category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA6CG1 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------------- syzbot reported an ext4 panic during a page fault where found a journal handle when it didn't expect to find one. The structure it tripped over had a value of 'TRAN' in the first entry in the structure, and that indicates it tripped over a struct xfs_trans instead of a jbd2 handle. The reason for this is that the page fault was taken during a copy-out to a user buffer from an xfs bulkstat operation. XFS uses an "empty" transaction context for bulkstat to do automated metadata buffer cleanup, and so the transaction context is valid across the copyout of the bulkstat info into the user buffer. We are using empty transaction contexts like this in XFS to reduce the risk of failing to release objects we reference during the operation, especially during error handling. Hence we really need to ensure that we can take page faults from these contexts without leaving landmines for the code processing the page fault to trip over. However, this same behaviour could happen from any other filesystem that triggers a page fault or any other exception that is handled on-stack from within a task context that has current->journal_info set. Having a page fault from some other filesystem bounce into XFS where we have to run a transaction isn't a bug at all, but the usage of current->journal_info means that this could result corruption of the outer task's journal_info structure. The problem is purely that we now have two different contexts that now think they own current->journal_info. IOWs, no filesystem can allow page faults or on-stack exceptions while current->journal_info is set by the filesystem because the exception processing might use current->journal_info itself. If we end up with nested XFS transactions whilst holding an empty transaction, then it isn't an issue as the outer transaction does not hold a log reservation. If we ignore the current->journal_info usage, then the only problem that might occur is a deadlock if the exception tries to take the same locks the upper context holds. That, however, is not a problem that setting current->journal_info would solve, so it's largely an irrelevant concern here. IOWs, we really only use current->journal_info for a warning check in xfs_vm_writepages() to ensure we aren't doing writeback from a transaction context. Writeback might need to do allocation, so it can need to run transactions itself. Hence it's a debug check to warn us that we've done something silly, and largely it is not all that useful. So let's just remove all the use of current->journal_info in XFS and get rid of all the potential issues from nested contexts where current->journal_info might get misused by another filesystem context. Reported-by: syzbot+cdee56dbcdf0096ef605(a)syzkaller.appspotmail.com Signed-off-by: Dave Chinner <dchinner(a)redhat.com> Reviewed-by: "Darrick J. Wong" <djwong(a)kernel.org> Reviewed-by: Mark Tinguely <mark.tinguely(a)oracle.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Chandan Babu R <chandanbabu(a)kernel.org> Conflicts: fs/xfs/scrub/common.c fs/xfs/xfs_aops.c [ a03297a0ca9f2("xfs: manage inode DONTCACHE status at irele time") is not applied. 21b4ee7029c90("xfs: drop ->writepage completely") is not applied.] Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> --- fs/xfs/xfs_aops.c | 13 ------------- fs/xfs/xfs_icache.c | 8 +++++--- fs/xfs/xfs_trans.h | 9 +-------- 3 files changed, 6 insertions(+), 24 deletions(-) diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c index ef7db9defef1..e751cf34ccba 100644 --- a/fs/xfs/xfs_aops.c +++ b/fs/xfs/xfs_aops.c @@ -552,12 +552,6 @@ xfs_vm_writepage( { struct xfs_writepage_ctx wpc = { }; - if (WARN_ON_ONCE(current->journal_info)) { - redirty_page_for_writepage(wbc, page); - unlock_page(page); - return 0; - } - return iomap_writepage(page, wbc, &wpc.ctx, &xfs_writeback_ops); } @@ -568,13 +562,6 @@ xfs_vm_writepages( { struct xfs_writepage_ctx wpc = { }; - /* - * Writing back data in a transaction context can result in recursive - * transactions. This is bad, so issue a warning and get out of here. - */ - if (WARN_ON_ONCE(current->journal_info)) - return 0; - xfs_iflags_clear(XFS_I(mapping->host), XFS_ITRUNCATED); return iomap_writepages(mapping, wbc, &wpc.ctx, &xfs_writeback_ops); } diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index bdf55ed88680..fae443e0d120 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -2043,8 +2043,10 @@ xfs_inodegc_want_queue_work( * - Memory shrinkers queued the inactivation worker and it hasn't finished. * - The queue depth exceeds the maximum allowable percpu backlog. * - * Note: If the current thread is running a transaction, we don't ever want to - * wait for other transactions because that could introduce a deadlock. + * Note: If we are in a NOFS context here (e.g. current thread is running a + * transaction) the we don't want to block here as inodegc progress may require + * filesystem resources we hold to make progress and that could result in a + * deadlock. Hence we skip out of here if we are in a scoped NOFS context. */ static inline bool xfs_inodegc_want_flush_work( @@ -2052,7 +2054,7 @@ xfs_inodegc_want_flush_work( unsigned int items, unsigned int shrinker_hits) { - if (current->journal_info) + if (current->flags & PF_MEMALLOC_NOFS) return false; if (shrinker_hits > 0) diff --git a/fs/xfs/xfs_trans.h b/fs/xfs/xfs_trans.h index 731af3f04c83..d512fdd5f7c3 100644 --- a/fs/xfs/xfs_trans.h +++ b/fs/xfs/xfs_trans.h @@ -271,19 +271,14 @@ static inline void xfs_trans_set_context( struct xfs_trans *tp) { - ASSERT(current->journal_info == NULL); tp->t_pflags = memalloc_nofs_save(); - current->journal_info = tp; } static inline void xfs_trans_clear_context( struct xfs_trans *tp) { - if (current->journal_info == tp) { - memalloc_nofs_restore(tp->t_pflags); - current->journal_info = NULL; - } + memalloc_nofs_restore(tp->t_pflags); } static inline void @@ -291,10 +286,8 @@ xfs_trans_switch_context( struct xfs_trans *old_tp, struct xfs_trans *new_tp) { - ASSERT(current->journal_info == old_tp); new_tp->t_pflags = old_tp->t_pflags; old_tp->t_pflags = 0; - current->journal_info = new_tp; } #endif /* __XFS_TRANS_H__ */ -- 2.31.1

1 0

[PATCH OLK-6.6] xfs: don't use current->journal_info
by Zhihao Cheng 18 Jun '24

18 Jun '24

From: Dave Chinner <dchinner(a)redhat.com> mainline inclusion from mainline-v6.9-rc2 commit f2e812c1522dab847912309b00abcc762dd696da category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA6CG1 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------------- syzbot reported an ext4 panic during a page fault where found a journal handle when it didn't expect to find one. The structure it tripped over had a value of 'TRAN' in the first entry in the structure, and that indicates it tripped over a struct xfs_trans instead of a jbd2 handle. The reason for this is that the page fault was taken during a copy-out to a user buffer from an xfs bulkstat operation. XFS uses an "empty" transaction context for bulkstat to do automated metadata buffer cleanup, and so the transaction context is valid across the copyout of the bulkstat info into the user buffer. We are using empty transaction contexts like this in XFS to reduce the risk of failing to release objects we reference during the operation, especially during error handling. Hence we really need to ensure that we can take page faults from these contexts without leaving landmines for the code processing the page fault to trip over. However, this same behaviour could happen from any other filesystem that triggers a page fault or any other exception that is handled on-stack from within a task context that has current->journal_info set. Having a page fault from some other filesystem bounce into XFS where we have to run a transaction isn't a bug at all, but the usage of current->journal_info means that this could result corruption of the outer task's journal_info structure. The problem is purely that we now have two different contexts that now think they own current->journal_info. IOWs, no filesystem can allow page faults or on-stack exceptions while current->journal_info is set by the filesystem because the exception processing might use current->journal_info itself. If we end up with nested XFS transactions whilst holding an empty transaction, then it isn't an issue as the outer transaction does not hold a log reservation. If we ignore the current->journal_info usage, then the only problem that might occur is a deadlock if the exception tries to take the same locks the upper context holds. That, however, is not a problem that setting current->journal_info would solve, so it's largely an irrelevant concern here. IOWs, we really only use current->journal_info for a warning check in xfs_vm_writepages() to ensure we aren't doing writeback from a transaction context. Writeback might need to do allocation, so it can need to run transactions itself. Hence it's a debug check to warn us that we've done something silly, and largely it is not all that useful. So let's just remove all the use of current->journal_info in XFS and get rid of all the potential issues from nested contexts where current->journal_info might get misused by another filesystem context. Reported-by: syzbot+cdee56dbcdf0096ef605(a)syzkaller.appspotmail.com Signed-off-by: Dave Chinner <dchinner(a)redhat.com> Reviewed-by: "Darrick J. Wong" <djwong(a)kernel.org> Reviewed-by: Mark Tinguely <mark.tinguely(a)oracle.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Chandan Babu R <chandanbabu(a)kernel.org> Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/xfs/scrub/common.c | 4 +--- fs/xfs/xfs_aops.c | 7 ------- fs/xfs/xfs_icache.c | 8 +++++--- fs/xfs/xfs_trans.h | 9 +-------- 4 files changed, 7 insertions(+), 21 deletions(-) diff --git a/fs/xfs/scrub/common.c b/fs/xfs/scrub/common.c index 23944fcc1a6c..08e292485268 100644 --- a/fs/xfs/scrub/common.c +++ b/fs/xfs/scrub/common.c @@ -978,9 +978,7 @@ xchk_irele( struct xfs_scrub *sc, struct xfs_inode *ip) { - if (current->journal_info != NULL) { - ASSERT(current->journal_info == sc->tp); - + if (sc->tp) { /* * If we are in a transaction, we /cannot/ drop the inode * ourselves, because the VFS will trigger writeback, which diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c index a2e1f73f84dd..82f18f28c1c1 100644 --- a/fs/xfs/xfs_aops.c +++ b/fs/xfs/xfs_aops.c @@ -477,13 +477,6 @@ xfs_vm_writepages( { struct xfs_writepage_ctx wpc = { }; - /* - * Writing back data in a transaction context can result in recursive - * transactions. This is bad, so issue a warning and get out of here. - */ - if (WARN_ON_ONCE(current->journal_info)) - return 0; - xfs_iflags_clear(XFS_I(mapping->host), XFS_ITRUNCATED); return iomap_writepages(mapping, wbc, &wpc.ctx, &xfs_writeback_ops); } diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index f4971bd1de05..370c0df1a7a5 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -2037,8 +2037,10 @@ xfs_inodegc_want_queue_work( * - Memory shrinkers queued the inactivation worker and it hasn't finished. * - The queue depth exceeds the maximum allowable percpu backlog. * - * Note: If the current thread is running a transaction, we don't ever want to - * wait for other transactions because that could introduce a deadlock. + * Note: If we are in a NOFS context here (e.g. current thread is running a + * transaction) the we don't want to block here as inodegc progress may require + * filesystem resources we hold to make progress and that could result in a + * deadlock. Hence we skip out of here if we are in a scoped NOFS context. */ static inline bool xfs_inodegc_want_flush_work( @@ -2046,7 +2048,7 @@ xfs_inodegc_want_flush_work( unsigned int items, unsigned int shrinker_hits) { - if (current->journal_info) + if (current->flags & PF_MEMALLOC_NOFS) return false; if (shrinker_hits > 0) diff --git a/fs/xfs/xfs_trans.h b/fs/xfs/xfs_trans.h index 4e38357237c3..ead65f5f8dc3 100644 --- a/fs/xfs/xfs_trans.h +++ b/fs/xfs/xfs_trans.h @@ -277,19 +277,14 @@ static inline void xfs_trans_set_context( struct xfs_trans *tp) { - ASSERT(current->journal_info == NULL); tp->t_pflags = memalloc_nofs_save(); - current->journal_info = tp; } static inline void xfs_trans_clear_context( struct xfs_trans *tp) { - if (current->journal_info == tp) { - memalloc_nofs_restore(tp->t_pflags); - current->journal_info = NULL; - } + memalloc_nofs_restore(tp->t_pflags); } static inline void @@ -297,10 +292,8 @@ xfs_trans_switch_context( struct xfs_trans *old_tp, struct xfs_trans *new_tp) { - ASSERT(current->journal_info == old_tp); new_tp->t_pflags = old_tp->t_pflags; old_tp->t_pflags = 0; - current->journal_info = new_tp; } #endif /* __XFS_TRANS_H__ */ -- 2.31.1

1 0

[PATCH openEuler-22.03-LTS-SP1] xfs: don't use current->journal_info
by Zhihao Cheng 18 Jun '24

18 Jun '24

From: Dave Chinner <dchinner(a)redhat.com> mainline inclusion from mainline-v6.9-rc2 commit f2e812c1522dab847912309b00abcc762dd696da category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA6CG1 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------------- syzbot reported an ext4 panic during a page fault where found a journal handle when it didn't expect to find one. The structure it tripped over had a value of 'TRAN' in the first entry in the structure, and that indicates it tripped over a struct xfs_trans instead of a jbd2 handle. The reason for this is that the page fault was taken during a copy-out to a user buffer from an xfs bulkstat operation. XFS uses an "empty" transaction context for bulkstat to do automated metadata buffer cleanup, and so the transaction context is valid across the copyout of the bulkstat info into the user buffer. We are using empty transaction contexts like this in XFS to reduce the risk of failing to release objects we reference during the operation, especially during error handling. Hence we really need to ensure that we can take page faults from these contexts without leaving landmines for the code processing the page fault to trip over. However, this same behaviour could happen from any other filesystem that triggers a page fault or any other exception that is handled on-stack from within a task context that has current->journal_info set. Having a page fault from some other filesystem bounce into XFS where we have to run a transaction isn't a bug at all, but the usage of current->journal_info means that this could result corruption of the outer task's journal_info structure. The problem is purely that we now have two different contexts that now think they own current->journal_info. IOWs, no filesystem can allow page faults or on-stack exceptions while current->journal_info is set by the filesystem because the exception processing might use current->journal_info itself. If we end up with nested XFS transactions whilst holding an empty transaction, then it isn't an issue as the outer transaction does not hold a log reservation. If we ignore the current->journal_info usage, then the only problem that might occur is a deadlock if the exception tries to take the same locks the upper context holds. That, however, is not a problem that setting current->journal_info would solve, so it's largely an irrelevant concern here. IOWs, we really only use current->journal_info for a warning check in xfs_vm_writepages() to ensure we aren't doing writeback from a transaction context. Writeback might need to do allocation, so it can need to run transactions itself. Hence it's a debug check to warn us that we've done something silly, and largely it is not all that useful. So let's just remove all the use of current->journal_info in XFS and get rid of all the potential issues from nested contexts where current->journal_info might get misused by another filesystem context. Reported-by: syzbot+cdee56dbcdf0096ef605(a)syzkaller.appspotmail.com Signed-off-by: Dave Chinner <dchinner(a)redhat.com> Reviewed-by: "Darrick J. Wong" <djwong(a)kernel.org> Reviewed-by: Mark Tinguely <mark.tinguely(a)oracle.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Chandan Babu R <chandanbabu(a)kernel.org> Conflicts: fs/xfs/scrub/common.c fs/xfs/xfs_aops.c [ a03297a0ca9f2("xfs: manage inode DONTCACHE status at irele time") is not applied. 21b4ee7029c90("xfs: drop ->writepage completely") is not applied.] Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> --- fs/xfs/xfs_aops.c | 13 ------------- fs/xfs/xfs_icache.c | 8 +++++--- fs/xfs/xfs_trans.h | 9 +-------- 3 files changed, 6 insertions(+), 24 deletions(-) diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c index ef7db9defef1..e751cf34ccba 100644 --- a/fs/xfs/xfs_aops.c +++ b/fs/xfs/xfs_aops.c @@ -552,12 +552,6 @@ xfs_vm_writepage( { struct xfs_writepage_ctx wpc = { }; - if (WARN_ON_ONCE(current->journal_info)) { - redirty_page_for_writepage(wbc, page); - unlock_page(page); - return 0; - } - return iomap_writepage(page, wbc, &wpc.ctx, &xfs_writeback_ops); } @@ -568,13 +562,6 @@ xfs_vm_writepages( { struct xfs_writepage_ctx wpc = { }; - /* - * Writing back data in a transaction context can result in recursive - * transactions. This is bad, so issue a warning and get out of here. - */ - if (WARN_ON_ONCE(current->journal_info)) - return 0; - xfs_iflags_clear(XFS_I(mapping->host), XFS_ITRUNCATED); return iomap_writepages(mapping, wbc, &wpc.ctx, &xfs_writeback_ops); } diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index bdf55ed88680..fae443e0d120 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -2043,8 +2043,10 @@ xfs_inodegc_want_queue_work( * - Memory shrinkers queued the inactivation worker and it hasn't finished. * - The queue depth exceeds the maximum allowable percpu backlog. * - * Note: If the current thread is running a transaction, we don't ever want to - * wait for other transactions because that could introduce a deadlock. + * Note: If we are in a NOFS context here (e.g. current thread is running a + * transaction) the we don't want to block here as inodegc progress may require + * filesystem resources we hold to make progress and that could result in a + * deadlock. Hence we skip out of here if we are in a scoped NOFS context. */ static inline bool xfs_inodegc_want_flush_work( @@ -2052,7 +2054,7 @@ xfs_inodegc_want_flush_work( unsigned int items, unsigned int shrinker_hits) { - if (current->journal_info) + if (current->flags & PF_MEMALLOC_NOFS) return false; if (shrinker_hits > 0) diff --git a/fs/xfs/xfs_trans.h b/fs/xfs/xfs_trans.h index 731af3f04c83..d512fdd5f7c3 100644 --- a/fs/xfs/xfs_trans.h +++ b/fs/xfs/xfs_trans.h @@ -271,19 +271,14 @@ static inline void xfs_trans_set_context( struct xfs_trans *tp) { - ASSERT(current->journal_info == NULL); tp->t_pflags = memalloc_nofs_save(); - current->journal_info = tp; } static inline void xfs_trans_clear_context( struct xfs_trans *tp) { - if (current->journal_info == tp) { - memalloc_nofs_restore(tp->t_pflags); - current->journal_info = NULL; - } + memalloc_nofs_restore(tp->t_pflags); } static inline void @@ -291,10 +286,8 @@ xfs_trans_switch_context( struct xfs_trans *old_tp, struct xfs_trans *new_tp) { - ASSERT(current->journal_info == old_tp); new_tp->t_pflags = old_tp->t_pflags; old_tp->t_pflags = 0; - current->journal_info = new_tp; } #endif /* __XFS_TRANS_H__ */ -- 2.31.1

2 1