| To: | Lukas Czerner <lczerner@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH] xfs: fix possible overflow in xfs_ioc_trim() |
| From: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
| Date: | Tue, 6 Sep 2011 10:02:38 -0400 |
| Cc: | xfs@xxxxxxxxxxx, hch@xxxxxxxxxxxxx |
| In-reply-to: | <1315233205-27093-1-git-send-email-lczerner@xxxxxxxxxx> |
| References: | <1315233205-27093-1-git-send-email-lczerner@xxxxxxxxxx> |
| User-agent: | Mutt/1.5.21 (2010-09-15) |
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? > + 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. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | XFS status update for August 2011, Christoph Hellwig |
|---|---|
| Next by Date: | Re: [PATCH] xfs: fix possible overflow in xfs_ioc_trim(), Lukas Czerner |
| Previous by Thread: | [PATCH] xfs: fix possible overflow in xfs_ioc_trim(), Lukas Czerner |
| Next by Thread: | Re: [PATCH] xfs: fix possible overflow in xfs_ioc_trim(), Lukas Czerner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |