All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Liu <jeff.liu@oracle.com>
To: "Lukáš Czerner" <lczerner@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: prevent range.len underflow in xfs_ioc_trim()
Date: Wed, 11 Dec 2013 21:25:11 +0800	[thread overview]
Message-ID: <52A867B7.2040208@oracle.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1312111418460.2197@localhost.localdomain>


On 12/11 2013 21:20 PM, Lukáš Czerner wrote:
> On Wed, 11 Dec 2013, Jeff Liu wrote:
> 
>> Date: Wed, 11 Dec 2013 21:10:48 +0800
>> From: Jeff Liu <jeff.liu@oracle.com>
>> To: Lukas Czerner <lczerner@redhat.com>, xfs@oss.sgi.com
>> Subject: Re: [PATCH] xfs: prevent range.len underflow in xfs_ioc_trim()
>>
>> Hi Lukas,
>>
>> Thanks for the fix.  We have corrected this problem with the blow patch
>> which got merged intwo weeks ago. :)
>> [ commit f9fd013561 ]
> 
> Not sure where it got merged, I do not see this upstream in linus
> tree.
Now it resides in xfs-next tree, but I remember Ben have sent out the
pull request "[GIT PULL] XFS bugfixes for 3.13-rc4" to Linus yesterday.

Thanks,
-Jeff
> 
>> xfs: don't perform discard if the given range length is less than block size
>>
>> That is also discovered by generic/288 you contributed.
> 
> Right, I mentioned that in the description.
> 
> -Lukas
> 
>>
>> Thanks,
>> -Jeff
>>
>> On 12/11 2013 20:05 PM, Lukas Czerner wrote:
>>> Currently when range.len is set to 0 it will underflow. Fix it by
>>> checking for this scenario and return EINVAL in case range.len is
>>> smaller than block size.
>>>
>>> This was discovered by the xfstests generic/288 and with this patch
>>> the problem goes away.
>>>
>>> Signed-off-by: Lukas Czerner <lczerner@redhat.com>
>>> ---
>>>  fs/xfs/xfs_discard.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/fs/xfs/xfs_discard.c b/fs/xfs/xfs_discard.c
>>> index 8367d6d..9029082 100644
>>> --- a/fs/xfs/xfs_discard.c
>>> +++ b/fs/xfs/xfs_discard.c
>>> @@ -180,7 +180,8 @@ xfs_ioc_trim(
>>>  	 * matter as trimming blocks is an advisory interface.
>>>  	 */
>>>  	if (range.start >= XFS_FSB_TO_B(mp, mp->m_sb.sb_dblocks) ||
>>> -	    range.minlen > XFS_FSB_TO_B(mp, XFS_ALLOC_AG_MAX_USABLE(mp)))
>>> +	    range.minlen > XFS_FSB_TO_B(mp, XFS_ALLOC_AG_MAX_USABLE(mp)) ||
>>> +	    range.len < XFS_FSB_TO_B(mp, 1))
>>>  		return -XFS_ERROR(EINVAL);
>>>  
>>>  	start = BTOBB(range.start);
>>>
>>
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

      reply	other threads:[~2013-12-11 13:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-11 12:05 [PATCH] xfs: prevent range.len underflow in xfs_ioc_trim() Lukas Czerner
2013-12-11 13:10 ` Jeff Liu
2013-12-11 13:20   ` Lukáš Czerner
2013-12-11 13:25     ` Jeff Liu [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=52A867B7.2040208@oracle.com \
    --to=jeff.liu@oracle.com \
    --cc=lczerner@redhat.com \
    --cc=xfs@oss.sgi.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.