All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org, Eric Sandeen <sandeen@redhat.com>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [heads-up][RFC] ext4_file_write() breakage
Date: Sat, 5 Apr 2014 07:53:28 +0100	[thread overview]
Message-ID: <20140405065328.GU18016@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20140405031507.GA18456@thunk.org>

On Fri, Apr 04, 2014 at 11:15:07PM -0400, Theodore Ts'o wrote:

> Right, but Eric's scneario was talking about unaligned *blocks* not
> *pages*.
> 
> So his scenario was one where the block size was 4k, and the write was
> unaligned with respect to the 4k block size.  For example, if with a
> 4k block size, we had one write starting at offset 0 with a size 512,
> and at the same time another write starting at offset 2048 with a size
> 1024 bytes.  The problem is that we were doing two writes inside the
> same *block*, and so if dio_zero_block() tried to operate on the same
> block at the same time, bad things would happen.
> 
> Does that make sense?

Make the first write take the following iovec array:
	{{good_pointer, 512}, {unmapped_pointer, 4096 - 512}}
and you'll get exact same scenario.   writev() on that iovec is the
same as write(fd, good_pointer, 512).  It certainly should not overwrite
the data at offsets greater than 512.

That's the whole point - it's possible to sneak an equivalent of what
ext4 considers an unaligned write (unaligned wrt fs blocks) past the
check in ext4_unaligned_aio().  You can pad a 512-byte write with
additional iovec segment that will *not* be written (->iov_base points
to something we'd just munmapped), so that the total iovec length looks
good, but passing that to writev()/pwritev()/AIO_PWRITEV will end up
with a short write.

      parent reply	other threads:[~2014-04-05  6:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-03 16:37 [heads-up][RFC] ext4_file_write() breakage Al Viro
2014-04-04  2:55 ` Theodore Ts'o
2014-04-04  6:11   ` Al Viro
2014-04-05  3:15     ` Theodore Ts'o
2014-04-05  4:32       ` Al Viro
2014-04-08  2:01         ` Theodore Ts'o
2014-04-05  6:53       ` Al Viro [this message]

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=20140405065328.GU18016@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=tytso@mit.edu \
    /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.