On Wed, May 25, 2011 at 5:07 AM, Ted Ts'o <tytso@xxxxxxx> wrote:
> On Mon, May 23, 2011 at 05:30:57PM +0800, Yongqiang Yang wrote:
>> @@ -982,20 +997,13 @@ static int ext4_ext_split(handle_t *handle, struct inode *inode,
>> err = -EIO;
>> goto cleanup;
>> }
>> - while (path[i].p_idx <= EXT_MAX_INDEX(path[i].p_hdr)) {
>> - ext_debug("%d: move %d:%llu in new index %llu\n", i,
>> - le32_to_cpu(path[i].p_idx->ei_block),
>> - ext4_idx_pblock(path[i].p_idx),
>> - newblock);
>> - /*memmove(++fidx, path[i].p_idx++,
>> - sizeof(struct ext4_extent_idx));
>> - neh->eh_entries++;
>> - BUG_ON(neh->eh_entries > neh->eh_max);*/
>> - path[i].p_idx++;
>> - m++;
>> - }
>> + /* start copy indexes */
>> + m = EXT_MAX_INDEX(path[i].p_hdr) - path[i].p_idx++;
>> + ext_debug("cur 0x%p, last 0x%p\n", path[i].p_idx,
>> + EXT_MAX_INDEX(path[i].p_hdr));
>> + ext4_ext_show_move(inode, path, newblock, i);
>> if (m) {
>> - memmove(++fidx, path[i].p_idx - m,
>> + memmove(++fidx, path[i].p_idx,
>> sizeof(struct ext4_extent_idx) * m);
>> le16_add_cpu(&neh->eh_entries, m);
>> }
>
Hi Ted,
Thank you for your review. I had looked at this case.
> So the old code mutates path[i].p_idx, where as your new code doesn't.
path[i]p_idx is mutated to EXT_MAX_INDEX(path[i].p_hdr) + 1, it is
meaningless. ext4_ext_split() is used only by
ext4_ext_create_new_leaf() which drops the path after ext4_ext_split()
returns, so the path[i].p_idx is no longer used.
> The one thing that scares me is that ext4_ext_insert_index() is passed
> &path[at], the function preferences path[at].p_idx.
ext4_ext_split() insert k indexes, where k = depth - at -1, starting
from depth - 1 to depth - 1 - k + 1 = depth - k = at + 1.
So old code does not mutate depth[at].p_idx.
I had tested the patch with fsx. I am not sure if this test is
enough. If you want more tests, I can do it.
Thanks,
Yongqiang.
>
> Have you looked at this case?
>
> - Ted
>
--
Best Wishes
Yongqiang Yang
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
