On Thu, Feb 2, 2012 at 1:31 PM, Li Zefan <l...@cn.fujitsu.com> wrote:
> Yan, Zheng wrote:
>> On Thu, Jan 27, 2011 at 4:46 PM, Li Zefan <l...@cn.fujitsu.com> wrote:
>>> Suppose:
>>> - the source extent is: [0, 100]
>>> - the src offset is 10
>>> - the clone length is 90
>>> - the dest offset is 0
>>>
>>> This statement:
>>>
>>> new_key.offset = key.offset + destoff - off
>>>
>>> will produce such an extent for the dest file:
>>>
>>> [ino, BTRFS_EXTENT_DATA_KEY, -10]
>>>
>>> , which is obviously wrong.
>>>
>>> Signed-off-by: Li Zefan <l...@cn.fujitsu.com>
>>> ---
>>> fs/btrfs/ioctl.c | 5 ++++-
>>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
>>> index f87552a..1b61dab 100644
>>> --- a/fs/btrfs/ioctl.c
>>> +++ b/fs/btrfs/ioctl.c
>>> @@ -1788,7 +1788,10 @@ static noinline long btrfs_ioctl_clone(struct file
>>> *file, unsigned long srcfd,
>>>
>>> memcpy(&new_key, &key, sizeof(new_key));
>>> new_key.objectid = inode->i_ino;
>>> - new_key.offset = key.offset + destoff - off;
>>> + if (off <= key.offset)
>>> + new_key.offset = key.offset + destoff - off;
>>> + else
>>> + new_key.offset = destoff;
>>>
>>> trans = btrfs_start_transaction(root, 1);
>>> if (IS_ERR(trans)) {
>>
>> This is a disk format change, will cause Oops when deleting or
>> truncating the file.
>>
>
> This is a bug fix, never mean to make a change on disk format. I'll
> appreciate if you point out what exactly is wrong in this fix.
sorry, I was misleaded by the backref discuss, your fix is correct
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
