Hello Shiyang Ruan, The patch 1447ac26a964: "fsdax: output address in dax_iomap_pfn() and rename it" from Jun 3, 2022, leads to the following Smatch static checker warning: fs/dax.c:1085 dax_iomap_direct_access() error: uninitialized symbol 'rc'. fs/dax.c 1052 static int dax_iomap_direct_access(const struct iomap *iomap, loff_t pos, 1053 size_t size, void **kaddr, pfn_t *pfnp) 1054 { 1055 pgoff_t pgoff = dax_iomap_pgoff(iomap, pos); 1056 int id, rc; 1057 long length; 1058 1059 id = dax_read_lock(); 1060 length = dax_direct_access(iomap->dax_dev, pgoff, PHYS_PFN(size), 1061 DAX_ACCESS, kaddr, pfnp); 1062 if (length < 0) { 1063 rc = length; 1064 goto out; 1065 } 1066 if (!pfnp) 1067 goto out_check_addr; Is this an error path? 1068 rc = -EINVAL; 1069 if (PFN_PHYS(length) < size) 1070 goto out; 1071 if (pfn_t_to_pfn(*pfnp) & (PHYS_PFN(size)-1)) 1072 goto out; 1073 /* For larger pages we need devmap */ 1074 if (length > 1 && !pfn_t_devmap(*pfnp)) 1075 goto out; 1076 rc = 0; 1077 1078 out_check_addr: 1079 if (!kaddr) 1080 goto out; How is it supposed to be handled if both "pfnp" and "kaddr" are NULL? Smatch says that "kaddr" can never be NULL so this code is just future proofing but I didn't look at it carefully. 1081 if (!*kaddr) 1082 rc = -EFAULT; 1083 out: 1084 dax_read_unlock(id); --> 1085 return rc; 1086 } regards, dan carpenter