public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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



             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