On Thu, 1 Aug 2024 16:12:24 +0800, Lizhi Xu wrote: > > > > > syzbot report KMSAN: uninit-value in pick_link, this is because the > > > > > corresponding folio was not found from the mapping, and the memory was > > > > > not initialized when allocating a new folio for the filemap. > > > > > > > > > > To avoid the occurrence of kmsan report uninit-value, initialize the > > > > > newly allocated folio memory to 0. > > > > > > > > NAK. > > > > > > > > You are papering over the real bug here. > > > Did you see the splat? I think you didn't see that. > > > > Sigh... It is stepping into uninitialized data in pick_link(), and by > > the look of traces it's been created by page_get_link(). > > > > What page_get_link() does is reading from page cache of symlink; > > the contents should have come from ->read_folio() (if it's really > > a symlink on squashfs, that would be squashfs_symlink_read_folio()). > > > > Uninit might have happened if > > * ->read_folio() hadn't been called at all (which is an obvios > > bug - that's what should've read the symlink contents) or > > * ->read_folio() had been called, it failed and yet we are > > still trying to use the resulting page. Again, an obvious bug - if > > trying to read fails, we should _not_ use the results or leave it > > in page cache for subsequent callers. > > * ->read_folio() had been called, claimed to have succeeded and > > yet it had left something in range 0..inode->i_size-1 uninitialized. > > Again, a bug, this time in ->read_folio() instance. > read_folio, have you noticed that the file value was passed to read_folio is NULL? > fs/namei.c > const char *page_get_link(struct dentry *dentry, struct inode *inode > ... > 5272 read_mapping_page(mapping, 0, NULL); > > So, Therefore, no matter what, the value of folio will not be initialized by file > in read_folio. Oh, in read_folio, it will use mapping->host to init folio, I will research why not init in do_read_cache_folio. -- Lizhi