From: fs <fs@ercist.iscas.ac.cn>
To: viro@parcelfarce.linux.theplanet.co.uk
Cc: linux-fsdevel@vger.kernel.org,
iscas-linaccident <iscas-linaccident@intellilink.co.jp>,
Andrew Morton <akpm@osdl.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: [PATCH] VFS mmap wrong behavior when I/O failure occurs
Date: Wed, 11 May 2005 14:47:11 -0400 [thread overview]
Message-ID: <1115837231.3599.55.camel@CoolQ> (raw)
Related FS:
EXT2, EXT3, XFS
Related files:
fs/buffer.c mm/filemap.c
Bug description:
Make a partition in USB storage HDD, create a 64M file.
Write a program, do: open - mmap - read memory at offset 16M
(from disk) - munmap - close. After each operation, pause for a
while, such as 3 seconds. Between mmap and read memory, unplug a
USB wire to force a I/O error. The read memory will report no error
and get 0x00 back, while the right result is SIGBUS.
Bug analysis:
When accessing a page mmaped, kernel calls
do_no_page->..->filemap_nopage->mapping->a_ops->readpage to read a
page from disk. In filemap_nopage(), if !Uptodate(page) (i.e.:
readpage() fails) , it will ClearPageError(page) and try readpage()
again. Most FS will call mpage_readpage(). For EXT2/EXT3/XFS,
it calls block_read_full_page().
1st readpage()->block_read_full_page():
get_block fails(because of I/O failure),
if (iblock < lblock) {
if (get_block(inode, iblock, bh, 0))
SetPageError(page);
}
if (!buffer_mapped(bh)) {
void *kaddr = kmap_atomic(page, KM_USER0);
memset(kaddr + i * blocksize, 0, blocksize);
flush_dcache_page(page);
kunmap_atomic(kaddr, KM_USER0);
set_buffer_uptodate(bh); //NOTICE HERE
continue;
}
...
Then ClearPageError(page);
2nd readpage()->block_read_full_page():
for every buffer:
if (buffer_uptodate(bh))
continue;
So at the end, the page/buffer is uptodate, no Error set.
filemap_nopage will happily return a page memset with 0 without any
error!
Way around:
A. do not set buffer uptodate
Or
B. do not call readpage() twice.
Patch:
Since the buffer is memset to 0, no need to set_buffer_uptodate.
diff -uNp linux-2.6.11.8-orig/fs/buffer.c linux-2.6.11.8/fs/buffer.c
--- linux-2.6.11.8-orig/fs/buffer.c 2005-05-11 14:41:03.000000000
-0400
+++ linux-2.6.11.8/fs/buffer.c 2005-05-11 14:38:55.000000000 -0400
@@ -2105,7 +2105,6 @@ int block_read_full_page(struct page *pa
memset(kaddr + i * blocksize, 0,
blocksize);
flush_dcache_page(page);
kunmap_atomic(kaddr, KM_USER0);
- set_buffer_uptodate(bh);
continue;
}
/*
Signed-off-by: Qu Fuping <fs@ercist.iscas.ac.cn>
----
Best Regards,
Qu Fuping
next reply other threads:[~2005-05-11 7:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-11 18:47 fs [this message]
2005-05-11 8:19 ` [PATCH] VFS mmap wrong behavior when I/O failure occurs Andrew Morton
2005-05-11 20:31 ` fs
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=1115837231.3599.55.camel@CoolQ \
--to=fs@ercist.iscas.ac.cn \
--cc=akpm@osdl.org \
--cc=iscas-linaccident@intellilink.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/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