All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: NeilBrown <neilb@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, Nick Piggin <npiggin@suse.de>
Subject: Re: [PATCH 001 of 2] Fix read/truncate race.
Date: Thu, 7 Jun 2007 09:19:30 +0200	[thread overview]
Message-ID: <20070607071929.GL4735@kernel.dk> (raw)
In-Reply-To: <1070607014653.27304@suse.de>

On Thu, Jun 07 2007, NeilBrown wrote:
> 
> do_generic_mapping_read currently samples the i_size at the start
> and doesn't do so again unless it needs to call ->readpage to load
> a page.  After ->readpage it has to re-sample i_size as a truncate
> may have caused that page to be filled with zeros, and the read()
> call should not see these.
> 
> However there are other activities that might cause ->readpage to be
> called on a page between the time that do_generic_mapping_read
> samples i_size and when it finds that it has an uptodate page.  These
> include at least read-ahead and possibly another thread performing a
> read.
> 
> So do_generic_mapping_read must sample i_size *after* it has an
> uptodate page.  Thus the current sampling at the start and after a read
> can be replaced with a sampling before the copy-out.
> 
> The same change applied to __generic_file_splice_read.
> 
> Note that this fixes any race with truncate_complete_page, but does
> not fix a possible race with truncate_partial_page.  If a partial
> truncate happens after do_generic_mapping_read samples i_size and
> before the copy_out, the nuls that truncate_partial_page place in the
> page could be copied out incorrectly.
> 
> I think the best fix for that is to *not* zero out parts of the page
> in truncate_partial_page, but rather to zero out the tail of a page
> when increasing i_size.

Thanks Neil, if you don't mind I'll steal the splice bits and add them
to the splice branch, as this particular patch conflicts with other
isize fixes that Hugh and I have been working on.

-- 
Jens Axboe


  reply	other threads:[~2007-06-07  7:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-07  1:46 [PATCH 000 of 2] Fix some bugs with 'read' racing with 'truncate' NeilBrown
2007-06-07  1:46 ` [PATCH 001 of 2] Fix read/truncate race NeilBrown
2007-06-07  7:19   ` Jens Axboe [this message]
2007-06-08  1:18   ` Andrew Morton
2007-06-08  2:48     ` Neil Brown
2007-06-08  6:10       ` Andrew Morton
2007-06-12  0:16         ` Neil Brown
2007-06-12  0:35           ` Andrew Morton
2007-06-07  1:47 ` [PATCH 002 of 2] Make sure readv stops reading when it hits end-of-file NeilBrown

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=20070607071929.GL4735@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=npiggin@suse.de \
    /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.