All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, Dave Chinner <dchinner@redhat.com>,
	xfs@oss.sgi.com
Subject: Re: fs corruption exposed by "xfs: increase prealloc size to double that of the previous extent"
Date: Sun, 16 Mar 2014 02:39:31 +0000	[thread overview]
Message-ID: <20140316023931.GR18016@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20140316022105.GQ18016@ZenIV.linux.org.uk>

On Sun, Mar 16, 2014 at 02:21:05AM +0000, Al Viro wrote:
> On Sat, Mar 15, 2014 at 09:02:16PM +0000, Al Viro wrote:
> 
> > And that's essentially what makes generic/263 complain.  Note, BTW, that
> > fallocate and hole-punching is irrelevant - test in generic/263 steps into
> > those, but the same thing happens with these operations disabled (by -F -H).
> > 
> > I've found the thread from last June where you've mentioned generic/263
> > regression; AFAICS, Dave's comments there had been wrong...
> 
> BTW, experimenting with that thing shows that junk in the tail of the page
> actually comes from some unused sectors on the same device.  So it's an
> information leak at the very least - I have seen it pick bits and pieces of
> previously removed files that way.

Hrm...  s/unused/not zeroed out/, actually - block size is 4K.  So we have
an empty file extended by ftruncate(), then mmap+msync+munmap in its tail,
then O_DIRECT write starting from a couple of blocks prior to EOF and
extending it by ~15 blocks.  New EOF is 2.5Kb off the beginning of the
(new) last block.  Then it's closed.  Remaining 1.5Kb of that last
block is _not_ zeroed out; moreover, pagefault on that page ends up
reading the entire block, the junk in the tail not getting zeroed out
in in-core copy either.  Interesting...

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Brian Foster <bfoster@redhat.com>
Cc: xfs@oss.sgi.com, Dave Chinner <dchinner@redhat.com>,
	linux-fsdevel@vger.kernel.org
Subject: Re: fs corruption exposed by "xfs: increase prealloc size to double that of the previous extent"
Date: Sun, 16 Mar 2014 02:39:31 +0000	[thread overview]
Message-ID: <20140316023931.GR18016@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20140316022105.GQ18016@ZenIV.linux.org.uk>

On Sun, Mar 16, 2014 at 02:21:05AM +0000, Al Viro wrote:
> On Sat, Mar 15, 2014 at 09:02:16PM +0000, Al Viro wrote:
> 
> > And that's essentially what makes generic/263 complain.  Note, BTW, that
> > fallocate and hole-punching is irrelevant - test in generic/263 steps into
> > those, but the same thing happens with these operations disabled (by -F -H).
> > 
> > I've found the thread from last June where you've mentioned generic/263
> > regression; AFAICS, Dave's comments there had been wrong...
> 
> BTW, experimenting with that thing shows that junk in the tail of the page
> actually comes from some unused sectors on the same device.  So it's an
> information leak at the very least - I have seen it pick bits and pieces of
> previously removed files that way.

Hrm...  s/unused/not zeroed out/, actually - block size is 4K.  So we have
an empty file extended by ftruncate(), then mmap+msync+munmap in its tail,
then O_DIRECT write starting from a couple of blocks prior to EOF and
extending it by ~15 blocks.  New EOF is 2.5Kb off the beginning of the
(new) last block.  Then it's closed.  Remaining 1.5Kb of that last
block is _not_ zeroed out; moreover, pagefault on that page ends up
reading the entire block, the junk in the tail not getting zeroed out
in in-core copy either.  Interesting...

  reply	other threads:[~2014-03-16  2:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-15 21:02 fs corruption exposed by "xfs: increase prealloc size to double that of the previous extent" Al Viro
2014-03-15 21:02 ` Al Viro
2014-03-16  2:21 ` Al Viro
2014-03-16  2:39   ` Al Viro [this message]
2014-03-16  2:39     ` Al Viro
2014-03-16 20:56     ` Al Viro
2014-03-16 20:56       ` Al Viro
2014-03-17  1:36       ` Dave Chinner
2014-03-17  1:36         ` Dave Chinner
2014-03-17  2:43         ` Dave Chinner
2014-03-18  1:16           ` Dave Chinner
2014-03-17  0:11 ` Dave Chinner
2014-03-17  0:11   ` Dave Chinner
2014-03-17  0:29   ` Al Viro
2014-03-17  0:29     ` Al Viro
2014-03-17  1:28     ` Al Viro
2014-03-17  1:38       ` Al Viro
2014-03-17  1:41       ` Dave Chinner
2014-03-17  1:41         ` Dave Chinner

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=20140316023931.GR18016@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=bfoster@redhat.com \
    --cc=dchinner@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=xfs@oss.sgi.com \
    /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.