linux-ext4 - Re: [Ext4 punch hole 3/5 v6] Ext4 Punch Hole Support: Punch out extents

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 6 May 2011 09:57:00 +0800
From:	Yongqiang Yang <xiaoqiangnk@...il.com>
To:	Allison Henderson <achender@...ux.vnet.ibm.com>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [Ext4 punch hole 3/5 v6] Ext4 Punch Hole Support: Punch out extents

>> Hi there,
>>
>> Sorry for so late voice.
>>
>> ext4_ext_remove_space() are supposed to be used by truncate, so it
>> remove blocks from EOF to start as indicated by while-loop.   Now it
>> has an end, so I think we'd better limit the while loop from the end
>> to the start, but not from EOF to the start.
>>
>> we can achieve this by assigning path right before while-loop.
>
> Hi there,
>
> Well, I tried setting the path using find_extent, but it doesnt look like it
> quite worked out. Could you expand a little more on this?  It is not
> immediately clear to me how we can do this by setting path.  It looks like
> path is an array of paths that keep track of where we are in the tree.  The
> current sequence of paths represent the current location, but I dont know
> how we could set up a particular sequence of paths with out walking into the
> tree to know what it is.  I think the while loop just detects when the
> search has come back around to top of the tree. If I understand the code
> correctly, we would need a sequence of the paths starting at the  deepest
> path that can still descend to all the extents in the hole, and the sequence
> would need to end at the path that points to the extent that contains the
> end of the hole. Thus limiting the search to only that subtree that spans
> the hole.  At least that is my interpretation of the code.  It that correct,
> or maybe there is something I missed?
Correct.
>
> If that is how it works, maybe what we could do instead check
> (path[i].p_idx->ei_block < end) when deciding weather or not to descend?  I
> think that would get rid of needlessly walking space that is beyond the end
> of the hole.  And then when we return from the ext4_ext_rm_leaf, we can
> check to see if the leaf contains extents appearing before the hole, and
> then quit out if it does.  Does that sound correct?  Thx!
Yes, it's applicable and easier.

find_extent doe not work, because path.p_block is used to another
thing, it is different from find_extent.

Setting path just can control end, start can not be controlled this way.

Yongqiang.

>
> Allison Henderson
>
>>
>>>                        /* root level has p_bh == NULL, brelse() eats this
>>> */
>>>                        brelse(path[i].p_bh);
>>>                        path[i].p_bh = NULL;
>>> @@ -3443,7 +3565,7 @@ void ext4_ext_truncate(struct inode *inode)
>>>
>>>        last_block = (inode->i_size + sb->s_blocksize - 1)
>>>                        >>  EXT4_BLOCK_SIZE_BITS(sb);
>>> -       err = ext4_ext_remove_space(inode, last_block);
>>> +       err = ext4_ext_remove_space(inode, last_block, EXT_MAX_BLOCK);
>>>
>>>        /* In a multi-transaction truncate, we only make the final
>>>         * transaction synchronous.
>>> --
>>> 1.7.1
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>> the body of a message to majordomo@...r.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>>
>>
>
>



-- 
Best Wishes
Yongqiang Yang
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html