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 <[email protected]>
----
Best Regards,
Qu Fuping
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
