xfs
[Top] [All Lists]

Re: [PATCH] xfs: fix possible overflow in xfs_ioc_trim()

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH] xfs: fix possible overflow in xfs_ioc_trim()
From: Lukas Czerner <lczerner@xxxxxxxxxx>
Date: Tue, 6 Sep 2011 16:54:46 +0200 (CEST)
Cc: Lukas Czerner <lczerner@xxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20110906140238.GA11643@xxxxxxxxxxxxx>
References: <1315233205-27093-1-git-send-email-lczerner@xxxxxxxxxx> <20110906140238.GA11643@xxxxxxxxxxxxx>
User-agent: Alpine 2.00 (LFD 1167 2008-08-23)
On Tue, 6 Sep 2011, Christoph Hellwig wrote:

> On Mon, Sep 05, 2011 at 04:33:25PM +0200, Lukas Czerner wrote:
> > In xfs_ioc_trim it is possible that start+len might overflow. Fix it by
> > decrementing the len so that start+len equals to the file system size in
> > the worst case.
> 
> The idea of the check looks reasonable, but I think it needs to be done
> a bit different.  Was this caught by the new testcase you just sent?

Actually I have found the problem in other file systems too (ext4 and
btrfs) while doing test similar to the one sent recently to xfstests.
Then I fixed the problems, and then I have created the xfstests test for
it so it is clear what the correct behaviour should look like. So yes,
the testcase would have caught the problem.

> 
> > +   xfs_fsblock_t           max_blks =  XFS_MAX_DBLOCKS(&(mp->m_sb));
> 
> XFS_MAX_DBLOCKS is the maximum number of blocks that the given
> geometry could support.  But the last AG could be shorter than the
> others.  I think you really want to check against mp->m_sb.sb_dblocks.
> 

ah, ok, I'll change that. Thanks!

-Lukas

<Prev in Thread] Current Thread [Next in Thread>