The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Adrian Cox <adrian@humboldt.co.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Filling holes in ext2
Date: Thu, 23 Aug 2001 10:46:46 -0700	[thread overview]
Message-ID: <3B854186.F0C00E3C@zip.com.au> (raw)
In-Reply-To: <3B83E9FD.6020801@humboldt.co.uk> <3B83FB3F.A0BDC056@zip.com.au> <3B853BE6.3010703@humboldt.co.uk>

Adrian Cox wrote:
> 
> Andrew Morton wrote:
> 
> > It matters.  -ac kernels handle this by clearing out the blocks
> > on the error path in __block_prepare_write().  If you retest with
> > -ac kernels, you should just see zeroes.
> 
> That doesn't help. The problem occurs just the same on -ac kernels.

OK, that code is for IO errors and disk-full.

> In this case __block_prepare_write() is successful. What happens is that
> if __copy_from_user() fails, the block remains mapped but not up to
> date. Thus the next read access to the file fetches the garbage data off
> disk, and presents it to the user.

generic_file_write() will mark the page not up-to-date in this case.
I wonder what's actually going on?  Perhaps the fact that we've
instantiated a block in ext2 outside i_size?

If you change the error path in -ac's generic_file_write() thusly:

-	goto fail_write;
+	status = -EFAULT;
+	goto sync_failure;

does it fix it?

Can you send the code you're using to demonstrate this?

-

  reply	other threads:[~2001-08-23 17:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-22 17:21 Filling holes in ext2 Adrian Cox
2001-08-22 18:34 ` Andrew Morton
2001-08-22 18:59   ` Adrian Cox
2001-08-23 17:22   ` Adrian Cox
2001-08-23 17:46     ` Andrew Morton [this message]
2001-08-23 19:17       ` Adrian Cox
2001-08-23 19:23         ` Alan Cox
2001-08-23 19:41         ` Andrew Morton
2001-08-23 21:21           ` Adrian Cox
2001-08-23 17:47     ` Alan Cox

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=3B854186.F0C00E3C@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=adrian@humboldt.co.uk \
    --cc=linux-kernel@vger.kernel.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