On Mon, Apr 18, 2011 at 9:21 AM, Steve French <[email protected]> wrote: > Is there a reproduction scenario or bug report for this (or was it > noted by inspection)? > > On Mon, Apr 18, 2011 at 8:44 AM, <[email protected]> wrote: >> From: Shirish Pargaonkar <[email protected]> >> >> >> It is possible that a close can occur while a file is >> being reopened which can result in list entry deleted >> from the list and an oops. >> Use list_for_each_entry_safe instead. >> >> >> Signed-off-by: Shirish Pargaonkar <[email protected]> >> --- >> fs/cifs/file.c | 5 +++-- >> 1 files changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/fs/cifs/file.c b/fs/cifs/file.c >> index faf5952..aa29167 100644 >> --- a/fs/cifs/file.c >> +++ b/fs/cifs/file.c >> @@ -1056,7 +1056,7 @@ struct cifsFileInfo *find_readable_file(struct >> cifsInodeInfo *cifs_inode, >> struct cifsFileInfo *find_writable_file(struct cifsInodeInfo *cifs_inode, >> bool fsuid_only) >> { >> - struct cifsFileInfo *open_file; >> + struct cifsFileInfo *open_file, *tmpf; >> struct cifs_sb_info *cifs_sb; >> bool any_available = false; >> int rc; >> @@ -1079,7 +1079,8 @@ struct cifsFileInfo *find_writable_file(struct >> cifsInodeInfo *cifs_inode, >> >> spin_lock(&cifs_file_list_lock); >> refind_writable: >> - list_for_each_entry(open_file, &cifs_inode->openFileList, flist) { >> + list_for_each_entry_safe(open_file, tmpf, &cifs_inode->openFileList, >> + >> flist) { >> if (!any_available && open_file->pid != current->tgid) >> continue; >> if (fsuid_only && open_file->uid != current_fsuid()) >> -- >> 1.6.0.2 >> >> > > > > -- > Thanks, > > Steve >
Steve, IBM internal bugzilla 71379. I think a stressed CIFS/SMB server can make cifs client this way! Perhaps harder to recreate strating 1.69 version of cifs (which has Jeff's patches for a slow server). Regards, Shirish -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
