All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Liu Bo <bo.li.liu@oracle.com>
Cc: Qu Wenruo <quwenruo.btrfs@gmx.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 3/7] Btrfs: check if extent buffer is aligned to sectorsize
Date: Tue, 17 May 2016 11:39:52 +0200	[thread overview]
Message-ID: <20160517093952.GH511@twin.jikos.cz> (raw)
In-Reply-To: <20160516180141.GB11100@localhost.localdomain>

On Mon, May 16, 2016 at 11:01:41AM -0700, Liu Bo wrote:
> On Sat, May 14, 2016 at 06:30:52PM +0800, Qu Wenruo wrote:
> > Hi Liu,
> > 
> > Thanks for your patch first.
> > 
> > On 05/14/2016 08:06 AM, Liu Bo wrote:
> > > Thanks to fuzz testing, we can pass an invalid bytenr to extent buffer
> > > via alloc_extent_buffer().  An unaligned eb can have more pages than it
> > > should have, which ends up extent buffer's leak or some corrupted content
> > > in extent buffer.
> > > 
> > > This adds a warning to let us quickly know what was happening.
> > > 
> > > Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
> > > ---
> > >  fs/btrfs/extent_io.c | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
> > > index d247fc0..e601e0f 100644
> > > --- a/fs/btrfs/extent_io.c
> > > +++ b/fs/btrfs/extent_io.c
> > > @@ -4868,6 +4868,10 @@ struct extent_buffer *alloc_extent_buffer(struct btrfs_fs_info *fs_info,
> > >  	int uptodate = 1;
> > >  	int ret;
> > > 
> > > +	WARN_ONCE(!IS_ALIGNED(start, fs_info->tree_root->sectorsize),
> > > +		  KERN_WARNING "eb->start(%llu) is not aligned to root->sectorsize(%u)\n",
> > > +		  start, fs_info->tree_root->sectorsize);
> > > +
> > 
> > IMHO this is a quite big problem. As almost all other things rely on the
> > assumption that extent buffer are at least sectorsize aligned.
> 
> It won't cause too much trouble as reading eb's page can prevent btrfs
> using this eb.
> 
> > What about warning and returning NULL? WARN_ONCE() only won't info user
> > quick enough.
> 
> I'm OK with warning, but I just realized that warning doesn't show which
> filesystem has problems, so btrfs_crit and -EINVAL is preferable.

NULL means it's allocation error, so please convert it to IS_ERR and
return more fine grained errors so we can distinguish the problems. An
unaligned 'start' almost always means a corruption or other problem in
the callers of alloc_extent_buffer().

  reply	other threads:[~2016-05-17  9:40 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-14  0:06 [PATCH 1/7] Btrfs: replace BUG() with WARN_ONCE in raid56 Liu Bo
2016-05-14  0:06 ` [PATCH 2/7] Btrfs: replace BUG_ON with WARN_ONCE in cow_file_range Liu Bo
2016-05-14  0:06 ` [PATCH 3/7] Btrfs: check if extent buffer is aligned to sectorsize Liu Bo
2016-05-14 10:30   ` Qu Wenruo
2016-05-16 18:01     ` Liu Bo
2016-05-17  9:39       ` David Sterba [this message]
2016-05-17 17:38         ` Liu Bo
2016-05-14  0:06 ` [PATCH 4/7] Btrfs: free sys_array eb as soon as possible Liu Bo
2016-05-16  8:45   ` David Sterba
2016-05-14  0:07 ` [PATCH 5/7] Btrfs: replace BUG_ON with WARN in merge_bio Liu Bo
2016-05-16  8:44   ` David Sterba
2016-05-16 17:24     ` Liu Bo
2016-05-17  9:55       ` David Sterba
2016-05-17 17:30         ` Liu Bo
2016-05-18 13:54           ` David Sterba
2016-05-14  0:07 ` [PATCH 6/7] Btrfs: fix eb memory leak due to readpage failure Liu Bo
2016-05-18 19:38   ` Josef Bacik
2016-05-14  0:07 ` [PATCH 7/7] Btrfs: fix memory leak due to invalid btree height Liu Bo
2016-09-06 16:50   ` David Sterba
2016-09-06 22:04     ` Liu Bo
2016-05-14 10:42 ` [PATCH 1/7] Btrfs: replace BUG() with WARN_ONCE in raid56 Qu Wenruo
2016-05-15 14:19 ` Holger Hoffstätte
2016-05-16  8:32   ` David Sterba
2016-10-12 15:06     ` David Sterba
2016-10-12 19:14       ` Liu Bo
2016-06-30  0:57 ` [PATCH v2] Btrfs: remove BUG() " Liu Bo
2016-07-26 16:58   ` David Sterba
2016-07-27  5:11     ` Liu Bo
2016-07-27 18:56   ` [PATCH v3] " Liu Bo
2016-07-29 16:53     ` David Sterba
2016-07-29 17:57     ` [PATCH v4] " Liu Bo
2016-08-24 12:11       ` David Sterba

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=20160517093952.GH511@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=bo.li.liu@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.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.