Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1700154 > unrolled thread

Re: xattr hash error in 4.13-rc with overlayfs over ext4

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: xattr hash error in 4.13-rc with overlayfs over ext4 Miklos Szeredi <miklos@szeredi.hu> - 2017-07-31 18:10 +0200
    Re: xattr hash error in 4.13-rc with overlayfs over ext4 Amir Goldstein <amir73il@gmail.com> - 2017-08-01 12:40 +0200
      Re: xattr hash error in 4.13-rc with overlayfs over ext4 Miklos Szeredi <miklos@szeredi.hu> - 2017-08-03 13:20 +0200
        Re: xattr hash error in 4.13-rc with overlayfs over ext4 "zhangyi (F)" <yizhang089@gmail.com> - 2017-08-06 14:50 +0200
          Re: xattr hash error in 4.13-rc with overlayfs over ext4 Tahsin Erdogan <tahsin@google.com> - 2017-08-06 22:10 +0200

#1700154 — Re: xattr hash error in 4.13-rc with overlayfs over ext4

On Thu, Jul 27, 2017 at 10:54 PM, Tahsin Erdogan <tahsin@google.com> wrote:
> Still no luck reproducing the error. I am using the test script below
> at v4.13-rc2. Do you mind checking my script to see what I am missing?

Don't know.   I can reliably reproduce it under UML, but not with a
VM.  What the hell is going on?

Thanks,
Miklos

[toc] | [next] | [standalone]

#1700837

On Mon, Jul 31, 2017 at 7:08 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Thu, Jul 27, 2017 at 10:54 PM, Tahsin Erdogan <tahsin@google.com> wrote:
>> Still no luck reproducing the error. I am using the test script below
>> at v4.13-rc2. Do you mind checking my script to see what I am missing?
>
> Don't know.   I can reliably reproduce it under UML, but not with a
> VM.  What the hell is going on?
>

Is it the same ext4 image for UML and VM? same image size? same mkfs version?

What inode size do you have in UML setup? e.g.:

dumpe2fs -h /dev/sda3|grep Inode.size
dumpe2fs 1.42.13 (17-May-2015)
Inode size:          256

have extra_isize feature? (not sure if that matters)

dumpe2fs -h /dev/sda3|grep isize
dumpe2fs 1.42.13 (17-May-2015)
Filesystem features:      has_journal ext_attr resize_inode dir_index
filetype needs_recovery extent flex_bg sparse_super large_file
huge_file uninit_bg dir_nlink extra_isize
Required extra isize:     28
Desired extra isize:      28

[toc] | [prev] | [next] | [standalone]

#1702952

On Tue, Aug 1, 2017 at 12:34 PM, Amir Goldstein <amir73il@gmail.com> wrote:
> On Mon, Jul 31, 2017 at 7:08 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>> On Thu, Jul 27, 2017 at 10:54 PM, Tahsin Erdogan <tahsin@google.com> wrote:
>>> Still no luck reproducing the error. I am using the test script below
>>> at v4.13-rc2. Do you mind checking my script to see what I am missing?
>>
>> Don't know.   I can reliably reproduce it under UML, but not with a
>> VM.  What the hell is going on?
>>
>
> Is it the same ext4 image for UML and VM? same image size? same mkfs version?

Exact same starting image.  Same userspace.  Same EXT4 kernel config options.

Thanks,
Miklos

[toc] | [prev] | [next] | [standalone]

#1704839

On 2017/8/3 19:10, Miklos Szeredi Wrote:
> On Tue, Aug 1, 2017 at 12:34 PM, Amir Goldstein <amir73il@gmail.com> wrote:
>> On Mon, Jul 31, 2017 at 7:08 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>>> On Thu, Jul 27, 2017 at 10:54 PM, Tahsin Erdogan <tahsin@google.com> wrote:
>>>> Still no luck reproducing the error. I am using the test script below
>>>> at v4.13-rc2. Do you mind checking my script to see what I am missing?
>>>
>>> Don't know.   I can reliably reproduce it under UML, but not with a
>>> VM.  What the hell is going on?
>>>
>>
>> Is it the same ext4 image for UML and VM? same image size? same mkfs version?
> 
> Exact same starting image.  Same userspace.  Same EXT4 kernel config options.
> 
> Thanks,
> Miklos
> 

Hi:
I think the root cause of this problem is the hash value not updated
when we overwrite the same xattr, please see ext4_xattr_set_entry():

static int ext4_xattr_set_entry(struct ext4_xattr_info *i,
				struct ext4_xattr_search *s,
				handle_t *handle, struct inode *inode,
				bool is_block)
{
...
	if (new_size && new_size == old_size) {
		size_t offs = le16_to_cpu(here->e_value_offs);
		void *val = s->base + offs;

		here->e_value_size = cpu_to_le32(i->value_len);
		if (i->value == EXT4_ZERO_XATTR_VALUE) {
			memset(val, 0, new_size);
		} else {
			memcpy(val, i->value, i->value_len);
			/* Clear padding bytes. */
			memset(val + i->value_len, 0, new_size - i->value_len);
		}

		/* Forget updating *here->e_hash* and *s->base->h_hash* here. */

		return 0;
	}
...
	/* Call ext4_xattr_hash_entry && ext4_xattr_rehash first set */
...
}

Thanks,
ZhangYi

[toc] | [prev] | [next] | [standalone]

#1704952

On Sun, Aug 6, 2017 at 5:47 AM, zhangyi (F) <yizhang089@gmail.com> wrote:
> I think the root cause of this problem is the hash value not updated
> when we overwrite the same xattr, please see ext4_xattr_set_entry():

Yes, you are right. Thanks a lot for finding the root cause.

I just sent out a fix: ("[PATCH] ext4: add missing xattr hash update")

http://patchwork.ozlabs.org/patch/798445/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web