public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: linux-kernel@vger.kernel.org
Cc: viro@math.psu.edu
Subject: [RFC] 2.4 truncate locking
Date: Wed, 17 Apr 2002 08:09:12 -0700	[thread overview]
Message-ID: <20020417150912.GI23767@holomorphy.com> (raw)

I did some research on how truncate_inode_pages()'s locking works.
Please feel free to clarify and/or correct my notes on the subject,
which I'd like to turn into a docpatch soon.

Thanks to Al Viro, Rik van Riel, Arjan van de Ven, and Christoph Hellwig
for their help to clarify these rules.


Cheers,
Bill

(1) exclusion from freeing of the inode

	inode->i_count for holding a reference count to protect against
	prematurely freeing the inode.

(2) exclusion from simultaneous manipulation of the inode page lists

	pagecache_lock protects page->list and the inode list heads.


(3) exclusion from creation of memory mappings to the affected region

	inode->i_shared_lock and inode->i_mmap_lock serialize mmap
	operations, but are not held by truncate_inode_pages() and so
	proceed simultaneously. No pages are allocated by this operation
	to refer to the inode, as this is done lazily at fault-time.
	See (8) for fault-time exclusion.


(4) exclusion from writes to the affected region

	inode->i_sem

(5) exclusion from reads to the affected region

	reads beyond inode->i_size do not perform pagecache lookup
	pagecache_lock serializes pagecache access while truncation
	simultaneously proceeds

(6) exclusion from pageout of the affected region

	pagemap_lru_lock

(7) exclusion from multiple simultaneous truncate operations

	inode->i_sem

(8) exclusion from memory-mapped reads or writes of the affected region

	either

	(1) unmapping the pages from all processes referencing the pages
		to obtain unique references to them all by means of
		vmtruncate() / zap_page_range()
			*or*
	(2) a unique reference to the inode itself (vma's mapping a file
		have ->vm_file which holds a reference to the inode)

(9) exclusion from simultaneous manipulation of page->mapping

	pagemap_lru_lock

(10) exclusion from simultaneous manipulation of pages by buffer cache

	PG_locked
		and
	unique reference to page by page->buffers == NULL

             reply	other threads:[~2002-04-17 15:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-17 15:09 William Lee Irwin III [this message]
2002-04-19  4:37 ` [RFC] 2.4 truncate locking William Lee Irwin III

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020417150912.GI23767@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@math.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox