Hi Dan, Thanks for pointing it out. Seems like I did miss an error check for build_path_from_dentry. I will fix this and send the updated patch. Regards Meetakshi -----Original Message----- From: Dan Carpenter <dan.carpenter@xxxxxxxxxx> Sent: Tuesday, February 27, 2024 8:54 PM To: Meetakshi Setiya <msetiya@xxxxxxxxxxxxx> Cc: linux-cifs@xxxxxxxxxxxxxxx Subject: [EXTERNAL] [bug report] smb: client: do not defer close open handles to deleted files [You don't often get email from dan.carpenter@xxxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Hello Meetakshi Setiya, The patch 05211603b73a: "smb: client: do not defer close open handles to deleted files" from Feb 9, 2024 (linux-next), leads to the following Smatch static checker warning: fs/smb/client/misc.c:871 cifs_mark_open_handles_for_deleted_file() error: 'full_path' dereferencing possible ERR_PTR() fs/smb/client/misc.c 860 void cifs_mark_open_handles_for_deleted_file(struct cifs_tcon *tcon, 861 const char *path) 862 { 863 struct cifsFileInfo *cfile; 864 void *page; 865 const char *full_path; 866 867 page = alloc_dentry_path(); 868 spin_lock(&tcon->open_file_lock); 869 list_for_each_entry(cfile, &tcon->openFileList, tlist) { 870 full_path = build_path_from_dentry(cfile->dentry, page); build_path_from_dentry() can only fail when the name is too long. I don't know if that's possible here... --> 871 if (strcmp(full_path, path) == 0) ^^^^^^^^^ This is the dereference Smatch is warning about. Feel free to ignore this warning if it's a false positive. These are one time emails so it's not a huge stress situation. 872 cfile->status_file_deleted = true; 873 } 874 spin_unlock(&tcon->open_file_lock); 875 free_dentry_path(page); 876 } regards, dan carpenter
