From: Andrew Morton <akpm@osdl.org>
To: Andrea Arcangeli <andrea@suse.de>
Cc: linux-kernel@vger.kernel.org, torvalds@osdl.org, mason@suse.com
Subject: Re: writepage fs corruption fixes
Date: Fri, 9 Jul 2004 22:56:34 -0700 [thread overview]
Message-ID: <20040709225634.2eb0b8b0.akpm@osdl.org> (raw)
In-Reply-To: <20040710045920.GY20947@dualathlon.random>
Andrea Arcangeli <andrea@suse.de> wrote:
>
> +page_is_mapped:
> +
> + end_index = i_size >> PAGE_CACHE_SHIFT;
> if (page->index >= end_index) {
> - unsigned offset = i_size_read(inode) & (PAGE_CACHE_SIZE - 1);
> + unsigned offset = i_size & (PAGE_CACHE_SIZE - 1);
> char *kaddr;
>
> if (page->index > end_index || !offset)
> @@ -503,8 +506,6 @@ mpage_writepage(struct bio *bio, struct
> kunmap_atomic(kaddr, KM_USER0);
> }
>
> -page_is_mapped:
What's the thinking behind moving the page_is_mapped label here?
We've established that we have found `first_unmapped' number of uptodate
and dirty buffers at the "front" of the page, and we're about to stick
(first_unmapped<<blkbits) bytes of this page into the BIO for writeout.
Hence everything which will go into the BIO is known to be uptodate and
dirty. So I'm wondering why this change was made.
The change is correct, though. It prevents us from writing non-zero data
between i_size and the end of the final bh to the file.
block_write_full_page() does it too:
/*
* The page straddles i_size. It must be zeroed out on each and every
* writepage invokation because it may be mmapped. "A file is mapped
* in multiples of the page size. For a file that is not a multiple of
* the page size, the remaining memory is zeroed when mapped, and
* writes to that region are not written out to the file."
*/
(Note that this is a "best effort" thing - userspace could still write
non-zero data into the mmapped page outside i_size even while I/O is in
flight. Can't do much about that).
But was this the reason for you making this change?
next prev parent reply other threads:[~2004-07-10 5:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-09 4:01 writepage fs corruption fixes Andrea Arcangeli
2004-07-09 4:06 ` Andrea Arcangeli
2004-07-09 4:19 ` Andrea Arcangeli
2004-07-09 4:29 ` Andrew Morton
2004-07-09 4:42 ` Andrea Arcangeli
2004-07-09 4:56 ` Andrew Morton
2004-07-09 12:43 ` Chris Mason
2004-07-10 0:16 ` Andrea Arcangeli
2004-07-10 1:07 ` Andrea Arcangeli
2004-07-10 4:30 ` Andrew Morton
2004-07-10 4:59 ` Andrea Arcangeli
2004-07-10 5:56 ` Andrew Morton [this message]
2004-07-10 6:11 ` Andrea Arcangeli
2004-07-10 6:13 ` Andrew Morton
2004-07-14 16:14 ` Andrea Arcangeli
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=20040709225634.2eb0b8b0.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mason@suse.com \
--cc=torvalds@osdl.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.