[v1] xfstests: filter the default EA

Commit Message

XiaoLi Feng Dec. 19, 2018, 3:44 a.m. UTC

From: xiaoli feng <[e-mail]>

For some filesystems, such as CIFS, the file or directory has the
default extend attribute. It makes these tests generic/020
generic/337 generic/377 failed. Now add this patch to filter the
default EA.

Signed-off-by: xiaoli feng <[e-mail]>
---
 tests/generic/020 | 11 ++++++++---
 tests/generic/337 |  7 ++++++-
 tests/generic/377 |  9 +++++++--
 3 files changed, 21 insertions(+), 6 deletions(-)

Comments

Christoph Hellwig Dec. 19, 2018, 7:18 a.m. UTC | #1

On Wed, Dec 19, 2018 at 11:44:28AM +0800, XiaoLi Feng wrote:
> From: xiaoli feng <[e-mail]>
> 
> For some filesystems, such as CIFS, the file or directory has the
> default extend attribute. It makes these tests generic/020
> generic/337 generic/377 failed. Now add this patch to filter the
> default EA.

What is "the default EA"?  This sounds like a CIFS bug to me.

XiaoLi Feng Dec. 20, 2018, 2:17 a.m. UTC | #2

Hi Christoph,

----- Original Message -----
> From: "Christoph Hellwig" <[e-mail]>
> To: "XiaoLi Feng" <[e-mail]>
> Cc: [e-mail]
> Sent: Wednesday, December 19, 2018 3:18:34 PM
> Subject: Re: [PATCH v1] xfstests: filter the default EA
> 
> On Wed, Dec 19, 2018 at 11:44:28AM +0800, XiaoLi Feng wrote:
> > From: xiaoli feng <[e-mail]>
> > 
> > For some filesystems, such as CIFS, the file or directory has the
> > default extend attribute. It makes these tests generic/020
> > generic/337 generic/377 failed. Now add this patch to filter the
> > default EA.
> 
> What is "the default EA"?  This sounds like a CIFS bug to me.

the default EA means the new file or directory has extended attributes.

# touch cifs/file
# getfattr cifs/file
# file: cifs/file
user.security.selinux

I don't think it's a CIFS bug to me. But we need the CIFS developers's
analysis. cc the cifs developer mail.

Thanks.
>

Steve French Dec. 20, 2018, 2:24 a.m. UTC | #3

On Wed, Dec 19, 2018 at 8:17 PM Xiaoli Feng <[e-mail]> wrote:
>
> Hi Christoph,
>
> ----- Original Message -----
> > From: "Christoph Hellwig" <[e-mail]>
> > To: "XiaoLi Feng" <[e-mail]>
> > Cc: [e-mail]
> > Sent: Wednesday, December 19, 2018 3:18:34 PM
> > Subject: Re: [PATCH v1] xfstests: filter the default EA
> >
> > On Wed, Dec 19, 2018 at 11:44:28AM +0800, XiaoLi Feng wrote:
> > > From: xiaoli feng <[e-mail]>
> > >
> > > For some filesystems, such as CIFS, the file or directory has the
> > > default extend attribute. It makes these tests generic/020
> > > generic/337 generic/377 failed. Now add this patch to filter the
> > > default EA.
> >
> > What is "the default EA"?  This sounds like a CIFS bug to me.
>
> the default EA means the new file or directory has extended attributes.
>
> # touch cifs/file
> # getfattr cifs/file
> # file: cifs/file
> user.security.selinux

user.security.selinux is not a cifs EA.  This "default EA" is not
handled/returned by CIFS.

cifs.ko can save/return new EAs set by the user and even return a
couple pseudo-EAs (cifs.dosattrib for example) if that EA is queried
explicitly in order to return metadata (important flags needed for
backup etc.) - but this "user.security.selinux" "default EA" is not
returned by the cifs.ko code.

XiaoLi Feng Dec. 20, 2018, 3:03 a.m. UTC | #4

Hi Steve,

----- Original Message -----
> From: "Steve French" <[e-mail]>
> To: "Xiaoli Feng" <[e-mail]>
> Cc: "Christoph Hellwig" <[e-mail]>, [e-mail], "Ronnie Sahlberg" <[e-mail]>,
> "sprabhu" <[e-mail]>, "CIFS" <[e-mail]>
> Sent: Thursday, December 20, 2018 10:24:26 AM
> Subject: Re: [PATCH v1] xfstests: filter the default EA
> 
> On Wed, Dec 19, 2018 at 8:17 PM Xiaoli Feng <[e-mail]> wrote:
> >
> > Hi Christoph,
> >
> > ----- Original Message -----
> > > From: "Christoph Hellwig" <[e-mail]>
> > > To: "XiaoLi Feng" <[e-mail]>
> > > Cc: [e-mail]
> > > Sent: Wednesday, December 19, 2018 3:18:34 PM
> > > Subject: Re: [PATCH v1] xfstests: filter the default EA
> > >
> > > On Wed, Dec 19, 2018 at 11:44:28AM +0800, XiaoLi Feng wrote:
> > > > From: xiaoli feng <[e-mail]>
> > > >
> > > > For some filesystems, such as CIFS, the file or directory has the
> > > > default extend attribute. It makes these tests generic/020
> > > > generic/337 generic/377 failed. Now add this patch to filter the
> > > > default EA.
> > >
> > > What is "the default EA"?  This sounds like a CIFS bug to me.
> >
> > the default EA means the new file or directory has extended attributes.
> >
> > # touch cifs/file
> > # getfattr cifs/file
> > # file: cifs/file
> > user.security.selinux
> 
> user.security.selinux is not a cifs EA.  This "default EA" is not
> handled/returned by CIFS.
> 
> cifs.ko can save/return new EAs set by the user and even return a
> couple pseudo-EAs (cifs.dosattrib for example) if that EA is queried
> explicitly in order to return metadata (important flags needed for
> backup etc.) - but this "user.security.selinux" "default EA" is not
> returned by the cifs.ko code.

# getfattr ~/cifs
# mount //localhost/cifs ~/cifs -o user=root,password=redhat
# getfattr ~/cifs
getfattr: Removing leading '/' from absolute path names
# file: root/cifs
user.security.selinux

After mount the cifs share, the mountpoint ~/cifs already has "
user.security.selinux" extended attributes. I don't know who add it.


> 
> 
> --
> Thanks,
> 
> Steve
>

Steve French Dec. 20, 2018, 3:53 a.m. UTC | #5

What server type (presumably Samba if mounting to localhost)?  What
dialect (if RHEL since it is older it would default to cifs with posix
extensions, if kernel from last few years would default to smb3.02
dialect)?

What does the getfattr on the local path show as the attributes?

On Wed, Dec 19, 2018 at 9:03 PM Xiaoli Feng <[e-mail]> wrote:
>
> Hi Steve,
>
> ----- Original Message -----
> > From: "Steve French" <[e-mail]>
> > To: "Xiaoli Feng" <[e-mail]>
> > Cc: "Christoph Hellwig" <[e-mail]>, [e-mail], "Ronnie Sahlberg" <[e-mail]>,
> > "sprabhu" <[e-mail]>, "CIFS" <[e-mail]>
> > Sent: Thursday, December 20, 2018 10:24:26 AM
> > Subject: Re: [PATCH v1] xfstests: filter the default EA
> >
> > On Wed, Dec 19, 2018 at 8:17 PM Xiaoli Feng <[e-mail]> wrote:
> > >
> > > Hi Christoph,
> > >
> > > ----- Original Message -----
> > > > From: "Christoph Hellwig" <[e-mail]>
> > > > To: "XiaoLi Feng" <[e-mail]>
> > > > Cc: [e-mail]
> > > > Sent: Wednesday, December 19, 2018 3:18:34 PM
> > > > Subject: Re: [PATCH v1] xfstests: filter the default EA
> > > >
> > > > On Wed, Dec 19, 2018 at 11:44:28AM +0800, XiaoLi Feng wrote:
> > > > > From: xiaoli feng <[e-mail]>
> > > > >
> > > > > For some filesystems, such as CIFS, the file or directory has the
> > > > > default extend attribute. It makes these tests generic/020
> > > > > generic/337 generic/377 failed. Now add this patch to filter the
> > > > > default EA.
> > > >
> > > > What is "the default EA"?  This sounds like a CIFS bug to me.
> > >
> > > the default EA means the new file or directory has extended attributes.
> > >
> > > # touch cifs/file
> > > # getfattr cifs/file
> > > # file: cifs/file
> > > user.security.selinux
> >
> > user.security.selinux is not a cifs EA.  This "default EA" is not
> > handled/returned by CIFS.
> >
> > cifs.ko can save/return new EAs set by the user and even return a
> > couple pseudo-EAs (cifs.dosattrib for example) if that EA is queried
> > explicitly in order to return metadata (important flags needed for
> > backup etc.) - but this "user.security.selinux" "default EA" is not
> > returned by the cifs.ko code.
>
> # getfattr ~/cifs
> # mount //localhost/cifs ~/cifs -o user=root,password=redhat
> # getfattr ~/cifs
> getfattr: Removing leading '/' from absolute path names
> # file: root/cifs
> user.security.selinux
>
> After mount the cifs share, the mountpoint ~/cifs already has "
> user.security.selinux" extended attributes. I don't know who add it.
>
>
> >
> >
> > --
> > Thanks,
> >
> > Steve
> >

XiaoLi Feng Dec. 20, 2018, 5:23 a.m. UTC | #6

Hello,

----- Original Message -----
> From: "Steve French" <[e-mail]>
> To: "Xiaoli Feng" <[e-mail]>
> Cc: "Christoph Hellwig" <[e-mail]>, [e-mail], "Ronnie Sahlberg" <[e-mail]>, "CIFS"
> <[e-mail]>
> Sent: Thursday, December 20, 2018 11:53:09 AM
> Subject: Re: [PATCH v1] xfstests: filter the default EA
> 
> What server type (presumably Samba if mounting to localhost)?  What

Yes, it's Samba.

> dialect (if RHEL since it is older it would default to cifs with posix
> extensions, if kernel from last few years would default to smb3.02
> dialect)?

The dialect is smb3.02.

> 
> What does the getfattr on the local path show as the attributes?

It shows nothing for local path on xfs filesystem.

# touch /file
# getfattr /file
#

> 
> On Wed, Dec 19, 2018 at 9:03 PM Xiaoli Feng <[e-mail]> wrote:
> >
> > Hi Steve,
> >
> > ----- Original Message -----
> > > From: "Steve French" <[e-mail]>
> > > To: "Xiaoli Feng" <[e-mail]>
> > > Cc: "Christoph Hellwig" <[e-mail]>, [e-mail],
> > > "Ronnie Sahlberg" <[e-mail]>,
> > > "sprabhu" <[e-mail]>, "CIFS" <[e-mail]>
> > > Sent: Thursday, December 20, 2018 10:24:26 AM
> > > Subject: Re: [PATCH v1] xfstests: filter the default EA
> > >
> > > On Wed, Dec 19, 2018 at 8:17 PM Xiaoli Feng <[e-mail]> wrote:
> > > >
> > > > Hi Christoph,
> > > >
> > > > ----- Original Message -----
> > > > > From: "Christoph Hellwig" <[e-mail]>
> > > > > To: "XiaoLi Feng" <[e-mail]>
> > > > > Cc: [e-mail]
> > > > > Sent: Wednesday, December 19, 2018 3:18:34 PM
> > > > > Subject: Re: [PATCH v1] xfstests: filter the default EA
> > > > >
> > > > > On Wed, Dec 19, 2018 at 11:44:28AM +0800, XiaoLi Feng wrote:
> > > > > > From: xiaoli feng <[e-mail]>
> > > > > >
> > > > > > For some filesystems, such as CIFS, the file or directory has the
> > > > > > default extend attribute. It makes these tests generic/020
> > > > > > generic/337 generic/377 failed. Now add this patch to filter the
> > > > > > default EA.
> > > > >
> > > > > What is "the default EA"?  This sounds like a CIFS bug to me.
> > > >
> > > > the default EA means the new file or directory has extended attributes.
> > > >
> > > > # touch cifs/file
> > > > # getfattr cifs/file
> > > > # file: cifs/file
> > > > user.security.selinux
> > >
> > > user.security.selinux is not a cifs EA.  This "default EA" is not
> > > handled/returned by CIFS.
> > >
> > > cifs.ko can save/return new EAs set by the user and even return a
> > > couple pseudo-EAs (cifs.dosattrib for example) if that EA is queried
> > > explicitly in order to return metadata (important flags needed for
> > > backup etc.) - but this "user.security.selinux" "default EA" is not
> > > returned by the cifs.ko code.
> >
> > # getfattr ~/cifs
> > # mount //localhost/cifs ~/cifs -o user=root,password=redhat
> > # getfattr ~/cifs
> > getfattr: Removing leading '/' from absolute path names
> > # file: root/cifs
> > user.security.selinux
> >
> > After mount the cifs share, the mountpoint ~/cifs already has "
> > user.security.selinux" extended attributes. I don't know who add it.
> >
> >
> > >
> > >
> > > --
> > > Thanks,
> > >
> > > Steve
> > >
> 
> 
> 
> --
> Thanks,
> 
> Steve
>

Steve French Dec. 20, 2018, 5:37 a.m. UTC | #7

On Wed, Dec 19, 2018 at 11:23 PM Xiaoli Feng <[e-mail]> wrote:
>
> Hello,
>
> ----- Original Message -----
> > From: "Steve French" <[e-mail]>
> > To: "Xiaoli Feng" <[e-mail]>
> > Cc: "Christoph Hellwig" <[e-mail]>, [e-mail], "Ronnie Sahlberg" <[e-mail]>, "CIFS"
> > <[e-mail]>
> > Sent: Thursday, December 20, 2018 11:53:09 AM
> > Subject: Re: [PATCH v1] xfstests: filter the default EA
> >
> > What server type (presumably Samba if mounting to localhost)?  What
>
> Yes, it's Samba.
<snip>
> The dialect is smb3.02.

Since cifs.ko does not know about or special case this attribute, the
next step is to figure out who is returning this attribute - Samba
server or something above the client.
Typically I approach this by doing a quick wireshark trace (or follow
the process described at
https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Wire_Captures),
that will very quickly allow you to determine if it even came from the
server.  If it came from the server, follow the normal process for
enabling Samba logging (setting log level in smb.conf and looking at
why the xattr is being returned by examining the corresponding log
file in /var/log/samba/).   If you don't see it coming from the
server, then enabling the usual dynamic trace (trace-cmd) of the
syscall may be helpful.
Note that there are a fairly large number of xattr related trace
points (see /sys/kernel/tracing/events/syscalls).  Looking at this
does remind me that I should add dynamic trace points to cifs.ko for
smb3_get/set xattrs (for the error and success cases) although it
probably wouldn't be needed in this case - it would have allowed us to
more quickly rule out Samba returning this.

> > What does the getfattr on the local path show as the attributes?
>
> It shows nothing for local path on xfs filesystem.
>
> # touch /file
> # getfattr /file
> #

Christoph Hellwig Dec. 20, 2018, 7:41 a.m. UTC | #8

On Wed, Dec 19, 2018 at 08:24:26PM -0600, Steve French wrote:
> > # touch cifs/file
> > # getfattr cifs/file
> > # file: cifs/file
> > user.security.selinux
> 
> user.security.selinux is not a cifs EA.  This "default EA" is not
> handled/returned by CIFS.

The user. prefix for security.selinux is bogus.  Someone on either
the server or client side has a bad bug here.

XiaoLi Feng Dec. 21, 2018, 4:01 a.m. UTC | #9

----- Original Message -----
> From: "Steve French" <[e-mail]>
> To: "Xiaoli Feng" <[e-mail]>
> Cc: "Christoph Hellwig" <[e-mail]>, [e-mail], "Ronnie Sahlberg" <[e-mail]>, "CIFS"
> <[e-mail]>
> Sent: Thursday, December 20, 2018 1:37:57 PM
> Subject: Re: [PATCH v1] xfstests: filter the default EA
> 
> On Wed, Dec 19, 2018 at 11:23 PM Xiaoli Feng <[e-mail]> wrote:
> >
> > Hello,
> >
> > ----- Original Message -----
> > > From: "Steve French" <[e-mail]>
> > > To: "Xiaoli Feng" <[e-mail]>
> > > Cc: "Christoph Hellwig" <[e-mail]>, [e-mail],
> > > "Ronnie Sahlberg" <[e-mail]>, "CIFS"
> > > <[e-mail]>
> > > Sent: Thursday, December 20, 2018 11:53:09 AM
> > > Subject: Re: [PATCH v1] xfstests: filter the default EA
> > >
> > > What server type (presumably Samba if mounting to localhost)?  What
> >
> > Yes, it's Samba.
> <snip>
> > The dialect is smb3.02.
> 
> Since cifs.ko does not know about or special case this attribute, the
> next step is to figure out who is returning this attribute - Samba
> server or something above the client.
> Typically I approach this by doing a quick wireshark trace (or follow
> the process described at
> https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Wire_Captures),
> that will very quickly allow you to determine if it even came from the
> server.  If it came from the server, follow the normal process for
> enabling Samba logging (setting log level in smb.conf and looking at
> why the xattr is being returned by examining the corresponding log
> file in /var/log/samba/).   If you don't see it coming from the
> server, then enabling the usual dynamic trace (trace-cmd) of the
> syscall may be helpful.
> Note that there are a fairly large number of xattr related trace
> points (see /sys/kernel/tracing/events/syscalls).  Looking at this
> does remind me that I should add dynamic trace points to cifs.ko for
> smb3_get/set xattrs (for the error and success cases) although it
> probably wouldn't be needed in this case - it would have allowed us to
> more quickly rule out Samba returning this.

This EA information is returned from Samba server.

GetInfo Response (0x10)
        [Class: FILE_INFO (0x01)]
        [InfoLevel: SMB2_FILE_FULL_EA_INFO (0x0f)]
        StructureSize: 0x0009
            0000 0000 0000 100. = Fixed Part Length: 4
            .... .... .... ...1 = Dynamic Part: True
        Blob Offset: 0x00000048
        Blob Length: 56
        SMB2_FILE_FULL_EA_INFO
            EA: security.selinux := unconfined_u:object_r:mnt_t:s0
                Next Offset: 0
                EA Flags: 0x00
                EA Name Length: 16
                EA Data Length: 31
                EA Name: security.selinux
                EA Data: 756e636f6e66696e65645f753a6f626a6563745f723a6d6e...


> 
> > > What does the getfattr on the local path show as the attributes?
> >
> > It shows nothing for local path on xfs filesystem.
> >
> > # touch /file
> > # getfattr /file
> > #
>

Steve French Dec. 21, 2018, 4:14 a.m. UTC | #10

Adding Samba technical.

Interesting that (apparently) it isn't returned by the local xfs
"getfattr" from bash but is picked up when Samba server queries xfs
for xattrs.  Strange

On Thu, Dec 20, 2018 at 10:01 PM Xiaoli Feng <[e-mail]> wrote:
>
>
>
> ----- Original Message -----
> > From: "Steve French" <[e-mail]>
> > To: "Xiaoli Feng" <[e-mail]>
> > Cc: "Christoph Hellwig" <[e-mail]>, [e-mail], "Ronnie Sahlberg" <[e-mail]>, "CIFS"
> > <[e-mail]>
> > Sent: Thursday, December 20, 2018 1:37:57 PM
> > Subject: Re: [PATCH v1] xfstests: filter the default EA
> >
> > On Wed, Dec 19, 2018 at 11:23 PM Xiaoli Feng <[e-mail]> wrote:
> > >
> > > Hello,
> > >
> > > ----- Original Message -----
> > > > From: "Steve French" <[e-mail]>
> > > > To: "Xiaoli Feng" <[e-mail]>
> > > > Cc: "Christoph Hellwig" <[e-mail]>, [e-mail],
> > > > "Ronnie Sahlberg" <[e-mail]>, "CIFS"
> > > > <[e-mail]>
> > > > Sent: Thursday, December 20, 2018 11:53:09 AM
> > > > Subject: Re: [PATCH v1] xfstests: filter the default EA
> > > >
> > > > What server type (presumably Samba if mounting to localhost)?  What
> > >
> > > Yes, it's Samba.
> > <snip>
> > > The dialect is smb3.02.
> >
> > Since cifs.ko does not know about or special case this attribute, the
> > next step is to figure out who is returning this attribute - Samba
> > server or something above the client.
> > Typically I approach this by doing a quick wireshark trace (or follow
> > the process described at
> > https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Wire_Captures),
> > that will very quickly allow you to determine if it even came from the
> > server.  If it came from the server, follow the normal process for
> > enabling Samba logging (setting log level in smb.conf and looking at
> > why the xattr is being returned by examining the corresponding log
> > file in /var/log/samba/).   If you don't see it coming from the
> > server, then enabling the usual dynamic trace (trace-cmd) of the
> > syscall may be helpful.
> > Note that there are a fairly large number of xattr related trace
> > points (see /sys/kernel/tracing/events/syscalls).  Looking at this
> > does remind me that I should add dynamic trace points to cifs.ko for
> > smb3_get/set xattrs (for the error and success cases) although it
> > probably wouldn't be needed in this case - it would have allowed us to
> > more quickly rule out Samba returning this.
>
> This EA information is returned from Samba server.
>
> GetInfo Response (0x10)
>         [Class: FILE_INFO (0x01)]
>         [InfoLevel: SMB2_FILE_FULL_EA_INFO (0x0f)]
>         StructureSize: 0x0009
>             0000 0000 0000 100. = Fixed Part Length: 4
>             .... .... .... ...1 = Dynamic Part: True
>         Blob Offset: 0x00000048
>         Blob Length: 56
>         SMB2_FILE_FULL_EA_INFO
>             EA: security.selinux := unconfined_u:object_r:mnt_t:s0
>                 Next Offset: 0
>                 EA Flags: 0x00
>                 EA Name Length: 16
>                 EA Data Length: 31
>                 EA Name: security.selinux
>                 EA Data: 756e636f6e66696e65645f753a6f626a6563745f723a6d6e...
>
>
> >
> > > > What does the getfattr on the local path show as the attributes?
> > >
> > > It shows nothing for local path on xfs filesystem.
> > >
> > > # touch /file
> > > # getfattr /file
> > > #
> >

Patch

diff --git a/tests/generic/020 b/tests/generic/020
index 936d848..8fb1d1d 100755
--- a/tests/generic/020
+++ b/tests/generic/020
@@ -39,7 +39,7 @@  do_getfattr()
 {
     _getfattr $* 2>$tmp.err >$tmp.out
     exit=$?
-    _filter $tmp.out
+    _filter $tmp.out | grep -v "$defaultEA"
     _filter $tmp.err 1>&2
     return $exit
 }
@@ -66,13 +66,18 @@  _require_attrs
 rm -f $seqres.full
 
 testfile=$TEST_DIR/attribute_$$
+defaultEA="NODEFAULTEA"
 
 echo "*** list non-existant file"
 _attr_list $testfile
 
 echo "*** list empty file"
 touch $testfile
-_attr_list $testfile
+defaultEA_tmp=`do_getfattr -d -e text --absolute-names $testfile`
+if [ -n "$defaultEA_tmp" ]; then
+	defaultEA=`echo "$defaultEA_tmp" | grep -v ^#`
+fi
+_attr_list $testfile | grep -v ^# | grep -v ^$
 
 echo "*** query non-existant attribute"
 _attr -g "nonexistant" $testfile 2>&1
@@ -110,7 +115,7 @@  done
 
 echo "*** check"
 # don't print it all out...
-_getfattr --absolute-names $testfile \
+_getfattr --absolute-names $testfile | grep -v `echo "$defaultEA" | cut -d = -f 1` \
     | tee -a $seqres.full \
     | $AWK_PROG '
     	/^#/ { next }
diff --git a/tests/generic/337 b/tests/generic/337
index 344a365..57e4f9b 100755
--- a/tests/generic/337
+++ b/tests/generic/337
@@ -35,12 +35,17 @@  rm -f $seqres.full
 
 _scratch_mkfs >>$seqres.full 2>&1
 _scratch_mount
+defaultEA="NODEFAULTEA"
 
 # Create our test file with a few xattrs. The first 3 xattrs have a name that
 # when given as input to a crc32c function result in the same checksum. This
 # made btrfs list only one of the xattrs through listxattrs system call (because
 # it packs xattrs with the same name checksum into the same btree item).
 touch $SCRATCH_MNT/testfile
+defaultEA_tmp=`_getfattr --absolute-names --dump $SCRATCH_MNT/testfile`
+if [ -n "$defaultEA_tmp" ]; then
+        defaultEA=`echo "$defaultEA_tmp" | grep -v ^#`
+fi
 $SETFATTR_PROG -n user.foobar -v 123 $SCRATCH_MNT/testfile
 $SETFATTR_PROG -n user.WvG1c1Td -v qwerty $SCRATCH_MNT/testfile
 $SETFATTR_PROG -n user.J3__T_Km3dVsW_ -v hello $SCRATCH_MNT/testfile
@@ -49,7 +54,7 @@  $SETFATTR_PROG -n user.ping -v pong $SCRATCH_MNT/testfile
 
 # Now call getfattr with --dump, which calls the listxattrs system call.
 # It should list all the xattrs we have set before.
-_getfattr --absolute-names --dump $SCRATCH_MNT/testfile | _filter_scratch
+_getfattr --absolute-names --dump $SCRATCH_MNT/testfile |grep -v "$defaultEA" | _filter_scratch
 
 status=0
 exit
diff --git a/tests/generic/377 b/tests/generic/377
index f7835ee..4692053 100755
--- a/tests/generic/377
+++ b/tests/generic/377
@@ -37,18 +37,23 @@  rm -f $seqres.full
 
 _scratch_mkfs >>$seqres.full 2>&1
 _scratch_mount
+defaultEA="NODEFAULTEA"
 
 # Create a testfile with three xattrs such that the sum of namelengths of the
 # first two is bigger than the namelength of the third. This is needed for
 # the 5th testcase that tests one of the cornercases.
 testfile=${SCRATCH_MNT}/testfile
 touch $testfile
+defaultEA_tmp=`$listxattr $SCRATCH_MNT/testfile`
+if [ -n "$defaultEA_tmp" ]; then
+        defaultEA=`echo "$defaultEA_tmp" | grep -v ^#`
+fi
 $SETFATTR_PROG -n user.foo -v bar $testfile
 $SETFATTR_PROG -n user.ping -v pong $testfile
 $SETFATTR_PROG -n user.hello -v there $testfile
 
 # 1. Call listxattr without buffer length argument. This should succeed.
-$listxattr $testfile | sort
+$listxattr $testfile | grep -v "$defaultEA" | sort
 
 # 2. Calling listxattr on nonexistant file should fail with -ENOENT.
 $listxattr ""
@@ -66,7 +71,7 @@  $listxattr $testfile 9
 $listxattr $testfile 11
 
 # 6. Calling listxattr with buffersize bigger than needed should succeed.
-$listxattr $testfile 500 | sort
+$listxattr $testfile 500 | grep -v "$defaultEA" | sort
 
 status=0
 exit