From: Paul Mackerras <paulus@linuxcare.com.au>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org
Subject: page->mapping == 0
Date: Sun, 29 Oct 2000 20:38:02 +1100 (EST) [thread overview]
Message-ID: <14843.61434.167836.293141@argo.linuxcare.com.au> (raw)
In-Reply-To: <Pine.LNX.4.10.10010262325440.864-100000@penguin.transmeta.com>
In-Reply-To: <14841.7644.853174.666385@argo.linuxcare.com.au> <Pine.LNX.4.10.10010262325440.864-100000@penguin.transmeta.com>
Linus,
I have tracked down why I am getting the oops with page->mapping == 0
in block_read_full_page. Well, at least if not the ultimate cause,
then the penultimate cause. It's basically yet another truncate bug
(tm). I have some fairly detailed traces which I can send you if you
like, but the executive summary is that a page can get truncated out
from under us while we are sleeping in lock_page. The scenario I
observed is this:
Process A goes to read some data from a file. It finds or makes a
page cache page and starts the read into the page.
Process B goes to read the same data from the same file. It gets down
into do_generic_file_read, finds the existing page cache page,
increments its count, sees that it is not up-to-date, and calls
lock_page, which calls ___wait_on_page.
At some later time the read completes, the page becomes up-to-date and
process B is woken. But by this time process C is running. It is
also trying to read the same data from the same file. It completes
the read without blocking and then does a truncate on the file (in
preparation for rewriting it; the canonical example is when several
bashes exit at the same time, and they all go to read and rewrite
the ~/.bash_history file).
So process C calls vmtruncate() which calls truncate_inode_pages()
which calls truncate_complete_page() on all of the complete pages of
the file. That in turn calls remove_inode_page() which calls
__remove_inode_page() which sets page->mapping to NULL. (This code
doesn't seem to check page->count at all.)
Then process B actually gets to run. It returns from ___wait_on_page
to lock_page to do_generic_file_read. It now has the page locked but
it is no longer really the page it wants. It has page->mapping set to
NULL and it isn't on the page list for the mapping any more. The code
in do_generic_file_read doesn't check this but just charges on to call
mapping->a_ops->readpage.
I am not any kind of expert on the page cache but it seems to me that
maybe after locking the page we should check if it is still the page
we want (i.e. page->mapping and page->index are still correct), and go
back and look up the page again if not. Presumably there will be
quite a few places besides do_generic_file_read where that check would
be needed also.
Regards,
Paul.
--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare. Support for the revolution.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next parent reply other threads:[~2000-10-29 10:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <14841.7644.853174.666385@argo.linuxcare.com.au>
[not found] ` <Pine.LNX.4.10.10010262325440.864-100000@penguin.transmeta.com>
2000-10-29 9:38 ` Paul Mackerras [this message]
2000-10-29 12:39 ` page->mapping == 0 Daniel Phillips
2000-10-29 18:05 ` Linus Torvalds
2000-10-29 18:32 ` Alexander Viro
2000-10-29 19:12 ` Linus Torvalds
2000-10-29 19:33 ` Linus Torvalds
2000-10-30 1:57 ` Daniel Phillips
2000-10-29 20:32 ` Alan Cox
2000-10-29 20:42 ` Alexander Viro
2000-10-29 22:26 ` Jeff V. Merkey
2000-10-29 23:12 ` Jeff Dike
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=14843.61434.167836.293141@argo.linuxcare.com.au \
--to=paulus@linuxcare.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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