On 10/07/2010 01:24 AM, Jeff Layton wrote: > The count for cifsFileInfo is currently an atomic, but that just adds > complexity for little value. We generally need to hold cifs_file_list_lock > to traverse the lists anyway so we might as well make this counter > non-atomic and simply use the cifs_file_list_lock to protect it. > > Signed-off-by: Jeff Layton <[email protected]> > --- > fs/cifs/cifsglob.h | 9 ++++++--- > fs/cifs/file.c | 8 +++++--- > 2 files changed, 11 insertions(+), 6 deletions(-) > > diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h > index 531a768..f3c4e00 100644 > --- a/fs/cifs/cifsglob.h > +++ b/fs/cifs/cifsglob.h > @@ -393,16 +393,19 @@ struct cifsFileInfo { > struct list_head llist; /* list of byte range locks we have. */ > bool invalidHandle:1; /* file closed via session abend */ > bool oplock_break_cancelled:1; > - atomic_t count; /* reference count */ > + int count; /* refcount -- protected by cifs_file_list_lock > */ > struct mutex fh_mutex; /* prevents reopen race after dead ses*/ > struct cifs_search_info srch_inf; > struct work_struct oplock_break; /* work for oplock breaks */ > }; > > -/* Take a reference on the file private data */ > +/* > + * Take a reference on the file private data. Must be called with > + * cifs_file_list_lock held for read or write. > + */ > static inline void cifsFileInfo_get(struct cifsFileInfo *cifs_file) > { > - atomic_inc(&cifs_file->count); > + ++cifs_file->count;
Since we now use cifs_file_list_lock to protect cifs_file->count too, shouldn't all the callers of cifsFileInfo_get() need to acquire a write lock instead of read lock? -- Suresh Jayaraman -- 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
