⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 locking

📁 linux 内核源代码
💻
📖 第 1 页 / 共 2 页
字号:
	The text below describes the locking rules for VFS-related methods.It is (believed to be) up-to-date. *Please*, if you change anything inprototypes or locking protocols - update this file. And update the relevantinstances in the tree, don't leave that to maintainers of filesystems/devices/etc. At the very least, put the list of dubious cases in the end of this file.Don't turn it into log - maintainers of out-of-the-tree code are supposed tobe able to use diff(1).	Thing currently missing here: socket operations. Alexey?--------------------------- dentry_operations --------------------------prototypes:	int (*d_revalidate)(struct dentry *, int);	int (*d_hash) (struct dentry *, struct qstr *);	int (*d_compare) (struct dentry *, struct qstr *, struct qstr *);	int (*d_delete)(struct dentry *);	void (*d_release)(struct dentry *);	void (*d_iput)(struct dentry *, struct inode *);	char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);locking rules:	none have BKL		dcache_lock	rename_lock	->d_lock	may blockd_revalidate:	no		no		no		yesd_hash		no		no		no		yesd_compare:	no		yes		no		no d_delete:	yes		no		yes		nod_release:	no		no		no		yesd_iput:		no		no		no		yesd_dname:	no		no		no		no--------------------------- inode_operations --------------------------- prototypes:	int (*create) (struct inode *,struct dentry *,int, struct nameidata *);	struct dentry * (*lookup) (struct inode *,struct dentry *, struct nameidata *);	int (*link) (struct dentry *,struct inode *,struct dentry *);	int (*unlink) (struct inode *,struct dentry *);	int (*symlink) (struct inode *,struct dentry *,const char *);	int (*mkdir) (struct inode *,struct dentry *,int);	int (*rmdir) (struct inode *,struct dentry *);	int (*mknod) (struct inode *,struct dentry *,int,dev_t);	int (*rename) (struct inode *, struct dentry *,			struct inode *, struct dentry *);	int (*readlink) (struct dentry *, char __user *,int);	int (*follow_link) (struct dentry *, struct nameidata *);	void (*truncate) (struct inode *);	int (*permission) (struct inode *, int, struct nameidata *);	int (*setattr) (struct dentry *, struct iattr *);	int (*getattr) (struct vfsmount *, struct dentry *, struct kstat *);	int (*setxattr) (struct dentry *, const char *,const void *,size_t,int);	ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t);	ssize_t (*listxattr) (struct dentry *, char *, size_t);	int (*removexattr) (struct dentry *, const char *);locking rules:	all may block, none have BKL		i_mutex(inode)lookup:		yescreate:		yeslink:		yes (both)mknod:		yessymlink:	yesmkdir:		yesunlink:		yes (both)rmdir:		yes (both)	(see below)rename:		yes (all)	(see below)readlink:	nofollow_link:	notruncate:	yes		(see below)setattr:	yespermission:	nogetattr:	nosetxattr:	yesgetxattr:	nolistxattr:	noremovexattr:	yes	Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex onvictim.	cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem.	->truncate() is never called directly - it's a callback, not amethod. It's called by vmtruncate() - library function normally used by->setattr(). Locking information above applies to that call (i.e. isinherited from ->setattr() - vmtruncate() is used when ATTR_SIZE had beenpassed).See Documentation/filesystems/directory-locking for more detailed discussionof the locking scheme for directory operations.--------------------------- super_operations ---------------------------prototypes:	struct inode *(*alloc_inode)(struct super_block *sb);	void (*destroy_inode)(struct inode *);	void (*read_inode) (struct inode *);	void (*dirty_inode) (struct inode *);	int (*write_inode) (struct inode *, int);	void (*put_inode) (struct inode *);	void (*drop_inode) (struct inode *);	void (*delete_inode) (struct inode *);	void (*put_super) (struct super_block *);	void (*write_super) (struct super_block *);	int (*sync_fs)(struct super_block *sb, int wait);	void (*write_super_lockfs) (struct super_block *);	void (*unlockfs) (struct super_block *);	int (*statfs) (struct dentry *, struct kstatfs *);	int (*remount_fs) (struct super_block *, int *, char *);	void (*clear_inode) (struct inode *);	void (*umount_begin) (struct super_block *);	int (*show_options)(struct seq_file *, struct vfsmount *);	ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t);	ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t);locking rules:	All may block.			BKL	s_lock	s_umountalloc_inode:		no	no	nodestroy_inode:		noread_inode:		no				(see below)dirty_inode:		no				(must not sleep)write_inode:		noput_inode:		nodrop_inode:		no				!!!inode_lock!!!delete_inode:		noput_super:		yes	yes	nowrite_super:		no	yes	readsync_fs:		no	no	readwrite_super_lockfs:	?unlockfs:		?statfs:			no	no	noremount_fs:		yes	yes	maybe		(see below)clear_inode:		noumount_begin:		yes	no	noshow_options:		no				(vfsmount->sem)quota_read:		no	no	no		(see below)quota_write:		no	no	no		(see below)->read_inode() is not a method - it's a callback used in iget().->remount_fs() will have the s_umount lock if it's already mounted.When called from get_sb_single, it does NOT have the s_umount lock.->quota_read() and ->quota_write() functions are both guaranteed tobe the only ones operating on the quota file by the quota code (viadqio_sem) (unless an admin really wants to screw up something andwrites to quota files with quotas on). For other details about lockingsee also dquot_operations section.--------------------------- file_system_type ---------------------------prototypes:	int (*get_sb) (struct file_system_type *, int,		       const char *, void *, struct vfsmount *);	void (*kill_sb) (struct super_block *);locking rules:		may block	BKLget_sb		yes		yeskill_sb		yes		yes->get_sb() returns error or 0 with locked superblock attached to the vfsmount(exclusive on ->s_umount).->kill_sb() takes a write-locked superblock, does all shutdown work on it,unlocks and drops the reference.--------------------------- address_space_operations --------------------------prototypes:	int (*writepage)(struct page *page, struct writeback_control *wbc);	int (*readpage)(struct file *, struct page *);	int (*sync_page)(struct page *);	int (*writepages)(struct address_space *, struct writeback_control *);	int (*set_page_dirty)(struct page *page);	int (*readpages)(struct file *filp, struct address_space *mapping,			struct list_head *pages, unsigned nr_pages);	int (*prepare_write)(struct file *, struct page *, unsigned, unsigned);	int (*commit_write)(struct file *, struct page *, unsigned, unsigned);	sector_t (*bmap)(struct address_space *, sector_t);	int (*invalidatepage) (struct page *, unsigned long);	int (*releasepage) (struct page *, int);	int (*direct_IO)(int, struct kiocb *, const struct iovec *iov,			loff_t offset, unsigned long nr_segs);	int (*launder_page) (struct page *);locking rules:	All except set_page_dirty may block			BKL	PageLocked(page)	i_semwritepage:		no	yes, unlocks (see below)readpage:		no	yes, unlockssync_page:		no	maybewritepages:		noset_page_dirty		no	noreadpages:		noprepare_write:		no	yes			yescommit_write:		no	yes			yeswrite_begin:		no	locks the page		yeswrite_end:		no	yes, unlocks		yesperform_write:		no	n/a			yesbmap:			yesinvalidatepage:		no	yesreleasepage:		no	yesdirect_IO:		nolaunder_page:		no	yes	->prepare_write(), ->commit_write(), ->sync_page() and ->readpage()may be called from the request handler (/dev/loop).	->readpage() unlocks the page, either synchronously or via I/Ocompletion.	->readpages() populates the pagecache with the passed pages and startsI/O against them.  They come unlocked upon I/O completion.	->writepage() is used for two purposes: for "memory cleansing" and for"sync".  These are quite different operations and the behaviour may differdepending upon the mode.If writepage is called for sync (wbc->sync_mode != WBC_SYNC_NONE) thenit *must* start I/O against the page, even if that would involveblocking on in-progress I/O.If writepage is called for memory cleansing (sync_mode ==WBC_SYNC_NONE) then its role is to get as much writeout underway aspossible.  So writepage should try to avoid blocking againstcurrently-in-progress I/O.If the filesystem is not called for "sync" and it determines that itwould need to block against in-progress I/O to be able to start new I/Oagainst the page the filesystem should redirty the page withredirty_page_for_writepage(), then unlock the page and return zero.This may also be done to avoid internal deadlocks, but rarely.If the filesystem is called for sync then it must wait on anyin-progress I/O and then start new I/O.The filesystem should unlock the page synchronously, before returning to thecaller, unless ->writepage() returns special WRITEPAGE_ACTIVATEvalue. WRITEPAGE_ACTIVATE means that page cannot really be written outcurrently, and VM should stop calling ->writepage() on this page for sometime. VM does this by moving page to the head of the active list, hence thename.Unless the filesystem is going to redirty_page_for_writepage(), unlock the pageand return zero, writepage *must* run set_page_writeback() against the page,followed by unlocking it.  Once set_page_writeback() has been run against thepage, write I/O can be submitted and the write I/O completion handler must runend_page_writeback() once the I/O is complete.  If no I/O is submitted, thefilesystem must run end_page_writeback() against the page before returning fromwritepage.That is: after 2.5.12, pages which are under writeout are *not* locked.  Note,if the filesystem needs the page to be locked during writeout, that is ok, too,the page is allowed to be unlocked at any point in time between the calls toset_page_writeback() and end_page_writeback().Note, failure to run either redirty_page_for_writepage() or the combination ofset_page_writeback()/end_page_writeback() on a page submitted to writepagewill leave the page itself marked clean but it will be tagged as dirty in theradix tree.  This incoherency can lead to all sorts of hard-to-debug problemsin the filesystem like having dirty inodes at umount and losing written data.	->sync_page() locking rules are not well-defined - usually it is calledwith lock on page, but that is not guaranteed. Considering the currentlyexisting instances of this method ->sync_page() itself doesn't lookwell-defined...	->writepages() is used for periodic writeback and for syscall-initiatedsync operations.  The address_space should start I/O against at least*nr_to_write pages.  *nr_to_write must be decremented for each page which iswritten.  The address_space implementation may write more (or less) pagesthan *nr_to_write asks for, but it should try to be reasonably close.  Ifnr_to_write is NULL, all dirty pages must be written.writepages should _only_ write pages which are present onmapping->io_pages.	->set_page_dirty() is called from various places in the kernelwhen the target page is marked as needing writeback.  It may be called

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -