All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Ming Lei <tom.leiming@gmail.com>
Cc: Carlos Maiolino <cmaiolino@redhat.com>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	linux-block <linux-block@vger.kernel.org>
Subject: Re: [PATCH] fs: fix guard_bio_eod to check for real EOD errors
Date: Mon, 25 Feb 2019 08:36:49 +1100	[thread overview]
Message-ID: <20190224213649.GA1522@dastard> (raw)
In-Reply-To: <CACVXFVOBqTxXrMhqEAvQ8nMe9aYdrevj372_67aiZhXUFxjcgQ@mail.gmail.com>

On Sat, Feb 23, 2019 at 07:33:21AM +0800, Ming Lei wrote:
> Hi Carlos,
> 
> Cc block list given it is related with interface between fs and block layer.
> 
> On Fri, Feb 22, 2019 at 10:14 PM Carlos Maiolino <cmaiolino@redhat.com> wrote:
> >
> > guard_bio_eod() can truncate a segment in bio to allow it to do IO on
> > odd last sectors of a device.
> >
> > It already checks if the IO starts past EOD, but it does not consider
> > the possibility of an IO request starting within device boundaries can
> > contain more than one segment past EOD.
> >
> > In such cases, truncated_bytes can be bigger than PAGE_SIZE, and will
> > underflow bvec->bv_len.
> 
> It can cause memory corruption even for < PAGE_SIZE, also it can be correct
> to see > PAGE_SIZE truncated_bytes:
> 
> - xfs is going to support big block size which may be 64k

FYI, this isn't an XFS problem and never will be - XFS doesn't use
bufferheads and mpage_readpages() anymore, it goes down the
iomap_readpages() path which does not need this whacky
guard_bio_eod() thingy.

> - suppose fs block size is 4k, bio sector is 1022 and size is 4k, and
> disk size is
> 1024,

XFS won't do that, either - it checks at mount time if it can read
the very last sector of the filesystem via uncached IO (see
xfs_check_sizes() and xfs_rtmount_init()). If any of the EOD reads
fail, it won't mount.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2019-02-24 21:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-22 14:13 [PATCH] fs: fix guard_bio_eod to check for real EOD errors Carlos Maiolino
2019-02-22 14:47 ` Carlos Maiolino
2019-02-22 23:33 ` Ming Lei
2019-02-24 21:36   ` Dave Chinner [this message]
2019-02-25 13:26   ` Carlos Maiolino
2019-02-26  2:03     ` Ming Lei
2019-02-26  9:37       ` Carlos Maiolino

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=20190224213649.GA1522@dastard \
    --to=david@fromorbit.com \
    --cc=cmaiolino@redhat.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tom.leiming@gmail.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.