On Mon, Jul 31, 2017 at 11:53:35AM -0400, Sean Anderson wrote: > - i_mutex(inode) > -lookup: yes > + i_rwsem(inode) > +lookup: shared > create: yes
Could you change all the 'yes' to 'exclusive' when it's changed from mutex to rwsem? > link: yes (both) > mknod: yes > @@ -92,7 +92,7 @@ atomic_open: yes > tmpfile: no > > > - Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on > + Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_rwsem on > victim. > cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem. > > @@ -111,7 +111,7 @@ prototypes: > > locking rules: > all may block > - i_mutex(inode) > + i_rwsem(inode) > list: no > get: no > set: yes > @@ -217,7 +217,7 @@ prototypes: > locking rules: > All except set_page_dirty and freepage may block > > - PageLocked(page) i_mutex > + PageLocked(page) i_rwsem > writepage: yes, unlocks (see below) > readpage: yes, unlocks > writepages: > @@ -439,6 +439,7 @@ prototypes: > ssize_t (*read_iter) (struct kiocb *, struct iov_iter *); > ssize_t (*write_iter) (struct kiocb *, struct iov_iter *); > int (*iterate) (struct file *, struct dir_context *); > + int (*iterate_shared) (struct file *, struct dir_context *); > unsigned int (*poll) (struct file *, struct poll_table_struct *); > long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long); > long (*compat_ioctl) (struct file *, unsigned int, unsigned long); > @@ -480,6 +481,10 @@ mutex or just to use i_size_read() instead. > Note: this does not protect the file->f_pos against concurrent modifications > since this is something the userspace has to take care about. > > +->iterate() is called with i_rwsem held. > + > +->iterate_shared() is called with i_rwsem shared. > + > ->fasync() is responsible for maintaining the FASYNC bit in filp->f_flags. > Most instances call fasync_helper(), which does that maintenance, so it's > not normally something one needs to worry about. Return values > 0 will be > -- > 2.13.2 > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
