From: Tao Ma <tm@tao.ma>
To: boxi liu <boxi10liu@gmail.com>
Cc: "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: it may be a ext4 feature-inlinedata bug
Date: Thu, 23 May 2013 14:48:48 +0800 [thread overview]
Message-ID: <519DBBD0.2070204@tao.ma> (raw)
In-Reply-To: <CAAFszuUGv=0cKFw_ku7A12uZK7wNb5huMOUPKtC4b2REMMuFjA@mail.gmail.com>
Hi Boxi,
On 05/20/2013 10:50 PM, boxi liu wrote:
> In fs/ext4/xattr.c file, the function ex4_xattr_set_entry(), the size
> of xattr space we use the pad to count it .In line 675:
> size_t size = EXT4_XATTR_SIZE(i->value_len);
> We use the EXT_XATTR_SIZE to count the value_len,then get the xattr's
> used space.
> But in fs/ext4/inline.c file,we just use the actual size to count the
> inlinedata free size,in function get_max_inline_xattr_value_size()
> ,line 75,such as:
> free += le32_to_cpu(entry->e_value_size);
> This may bring in a bug about count the inlinedata free space.
> The bug reproduction way:
> 1. in the subarea with inline_data feature
> touch test
> 2. use echo to add to write the test file 129 bytes
> 3. use the "stat" to get the test file's status
> stat test
> the result is: .....size:129 block:0 .....
> 4.use echo to add one byte in the test file
> echo -n "0">>test
> 5.use the "stat" to get the test file's status
> stat test
> the result is: .....size:130 block:8 .....
> It is incorrect.In inline_data feature,only when the size is bigger
> then 132,it will use the block.
OK, so it seems to be an improvement, not a bug since there is no data
loss and only some contents are moved to a block even if it can be
stored in the inode. But yes, the patch looks good to me.
So could you please read the Documentation/SubmittingPatches and submit
a real patch for it?
Thanks,
Tao
>
> The patch about this bug:
> diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
> index 3e2bf87..bea5ced 100644
> --- a/fs/ext4/inline.c
> +++ b/fs/ext4/inline.c
> @@ -72,7 +72,7 @@ static int get_max_inline_xattr_value_size(struct
> inode *inode,
> entry = (struct ext4_xattr_entry *)
> ((void *)raw_inode + EXT4_I(inode)->i_inline_off);
>
> - free += le32_to_cpu(entry->e_value_size);
> + free += EXT4_XATTR_SIZE(le32_to_cpu(entry->e_value_size));
> goto out;
> }
> It might be fix this bug.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
prev parent reply other threads:[~2013-05-23 6:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-20 14:50 it may be a ext4 feature-inlinedata bug boxi liu
2013-05-23 6:48 ` Tao Ma [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=519DBBD0.2070204@tao.ma \
--to=tm@tao.ma \
--cc=boxi10liu@gmail.com \
--cc=linux-ext4@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).