From: Andrew Morton <akpm@osdl.org>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] problem of cont_prepare_write()
Date: Mon, 22 Nov 2004 18:30:06 -0800 [thread overview]
Message-ID: <20041122183006.5ef3b41c.akpm@osdl.org> (raw)
In-Reply-To: <87k6sdwbhy.fsf@devron.myhome.or.jp>
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> wrote:
>
> Andrew Morton <akpm@osdl.org> writes:
>
> >> Umm... however, if ->i_size is updated before ->commit_write(),
> >> doesn't it allow access to those pages, before all write() work is
> >> successful?
> >
> > That's OK. A thread which is read()ing that page will either
> >
> > a) decide that the page is outside i_size, and won't read it anyway or
> >
> > b) decide that the page is inside i_size and will read the page's contents.
> >
> > Still, I'd be inclined to update i_size after running ->commit_write. It
> > looks like we can simply replace the call to __block_commit_write() with a
> > call to generic_commit_write().
>
> If ->prepare_write() failed, I thought we should restore the ->i_size
> by vmtruncate() before running ->prepare_write().
^^^^^^ I assume you meant "after"
>
> But, it's not required... yes?
yes, it's needed in theory - see generic_file_buffered_write(). I'm trying
to remember why...
I think the only problem which that is solving is that the filesystem may
have left some blocks in the file outside i_size. That's a minor
consistency issue which a fsck will fix up. But I guess a subsequent lseek
may permit unwritten disk blocks to be read.
This problem is present whenever ->prepare_write() is called and we really
shouldn't be open-coding it everywhere.
> Anyway, fixed patch is the following.
Thanks. Does it pass all your testing?
> --
> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>
>
>
> fs/buffer.c | 3 +--
> 1 files changed, 1 insertion(+), 2 deletions(-)
>
> diff -puN fs/buffer.c~cont_prepare_write-fix fs/buffer.c
> --- linux-2.6.10-rc2/fs/buffer.c~cont_prepare_write-fix 2004-11-23 11:10:10.000000000 +0900
> +++ linux-2.6.10-rc2-hirofumi/fs/buffer.c 2004-11-23 11:10:10.000000000 +0900
> @@ -2224,8 +2224,7 @@ int cont_prepare_write(struct page *page
> memset(kaddr+zerofrom, 0, PAGE_CACHE_SIZE-zerofrom);
> flush_dcache_page(new_page);
> kunmap_atomic(kaddr, KM_USER0);
> - __block_commit_write(inode, new_page,
> - zerofrom, PAGE_CACHE_SIZE);
> + generic_commit_write(NULL, new_page, zerofrom, PAGE_CACHE_SIZE);
> unlock_page(new_page);
> page_cache_release(new_page);
> }
> _
next prev parent reply other threads:[~2004-11-23 2:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-22 10:30 [RFC][PATCH] problem of cont_prepare_write() OGAWA Hirofumi
2004-11-22 10:41 ` Andrew Morton
2004-11-22 10:46 ` Andrew Morton
2004-11-22 11:03 ` Anton Altaparmakov
2004-11-22 21:53 ` Andrew Morton
2004-11-22 23:30 ` Anton Altaparmakov
2004-11-22 23:43 ` Andrew Morton
2005-01-13 14:47 ` write barriers - Was: " Anton Altaparmakov
2005-01-13 15:56 ` Chris Friesen
2005-01-13 18:08 ` Florian Weimer
2004-11-22 11:38 ` OGAWA Hirofumi
2004-11-22 21:43 ` Andrew Morton
2004-11-23 2:22 ` OGAWA Hirofumi
2004-11-23 2:30 ` Andrew Morton [this message]
2004-11-23 2:55 ` OGAWA Hirofumi
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=20041122183006.5ef3b41c.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=hirofumi@mail.parknet.co.jp \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox