most (all?) x86_64 canaries seems to be failing this way,
no 32-bit ARM (well 0x7ffd00000000 is above the 32-bit boundary...)

As discovered by Shawn, the GetFileAttributes test was added today by this CL:
https://chromium-review.googlesource.com/#/c/340132/

The test implementation at line 301-303 looks questionable
https://chromium-review.googlesource.com/#/c/340132/13/cryptohome/platform_unittest.cc
  const int64_t flags = FS_UNRM_FL | FS_NODUMP_FL;
  ASSERT_GT(flags, 0);
  EXPECT_GE(ioctl(fd, FS_IOC_SETFLAGS, &flags), 0);

Not sure if the FS_IOC_SETFLAGS ioctl parameters is really an 'int64_t' or actually a 'long' ?

adding people knowledgeable about CL 340132

so:
FS_IOC_GETFLAGS parameter is a 'long' type :
#define	FS_IOC_GETVERSION		_IOR('v', 1, long)
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.14/include/uapi/linux/fs.h#161

but the ioctl for ext4 seems to return just an int :
	case EXT4_IOC_GETFLAGS:
		ext4_get_inode_flags(ei);
		flags = ei->i_flags & EXT4_FL_USER_VISIBLE;
		return put_user(flags, (int __user *) arg);
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.14/fs/ext4/ioctl.c#226

Short of a better short term solution, the revert for CL 340132 is there :
https://chromium-review.googlesource.com/#/c/351124/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/3ac728f9027eb3a6f21afc29f3487f652e5f2f24

commit 3ac728f9027eb3a6f21afc29f3487f652e5f2f24
Author: Vincent Palatin <vpalatin@chromium.org>
Date: Thu Jun 09 01:28:35 2016

Revert "cryptohome: Add equivalents of getxattr and lsattr to platform."

This reverts commit ba202dc05f867008c02385f739a58ae5cc5d1209.

The GetFileAttributes unittest is failing on x86_64 canaries:
see  crbug.com/618523 

BUG= chromium:618523 
TEST=none

Change-Id: I939fe6fd10dac69a1a1596da1ec29a60953d5f78
Reviewed-on: https://chromium-review.googlesource.com/351124
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>

[modify] https://crrev.com/3ac728f9027eb3a6f21afc29f3487f652e5f2f24/cryptohome/platform_unittest.cc
[modify] https://crrev.com/3ac728f9027eb3a6f21afc29f3487f652e5f2f24/cryptohome/platform.cc
[modify] https://crrev.com/3ac728f9027eb3a6f21afc29f3487f652e5f2f24/cryptohome/platform.h

Tried to investigate why this made it passed the CQ. We do have both parrot- and umaro- paladin, both are marked important, and both run unit tests. So I'm mostly mystified.

My suspicion is that the failure here is intermittent / flaky, and the CL got lucky when it was in the CQ. In the previous CQ run I see that this failed on only umaro and not parrot, which generally supports that theory.

> Tried to investigate why this made it passed the CQ.
[...]
> My suspicion is that the failure here is intermittent / flaky, 
> and the CL got lucky when it was in the CQ.

Yes from my analysis, it seems that the upper 32-bit of the variable is undefined,
so it's random but likely depends on what was run before.

Sorry for my mistake and thank you for your investigation.
Comment 2 makes perfect sense.
When the unit test failed I only updated the production code, but forgot to update the test.

I don't think #2 was actually the issue triggering the bad behavior, see #4.
IMO in CL 351140, Platform::GetFileAttributes() can still return a random upper word on EXT4.

An interesting discussion about the weird kernel interface for FS_IOC_GETFLAGS / FS_IOC_SETFLAGS:
https://lwn.net/Articles/575846/

Ah, thanks. So descarding upper word by casting long to int will solve the
problem right?

I found FS_IOC32_GETFLAGS takes int.
Using this instead of confusing FS_IOC_GETFLAGS might be better.

https://cs.corp.google.com/chromeos_public/src/third_party/kernel/v3.14/include/uapi/linux/fs.h?q=FS_IOC32_GETFLAGS&sq=package:%5Echromeos_public$&l=164&dr=CSs

Sorry FS_IOC32_GETFLAGS doesn't work.
I used int instead of long for the value passed to FS_IOC_GETFLAGS, and confirmed test passes using link, x86-alex, umaro.
Reland CL: https://chromium-review.googlesource.com/#/c/351140/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/959250c43694a8e553873ad03e5ac642492668eb

commit 959250c43694a8e553873ad03e5ac642492668eb
Author: Keigo Oka <oka@chromium.org>
Date: Thu Apr 21 03:59:34 2016

cryptohome: Add equivalents of getxattr and lsattr to platform.

This is relanding of
https://chromium-review.googlesource.com/#/c/340132/.
Unit test was failing on x86_64 because FS_IOC_GETFLAGS in ext4
actually returns int though the signature suggests long. I replaced
the argument to FS_IOC_GETFLAGS from long to int and (hopefully)
fixed the issue.

They will be used by cryptohome to distinguish the Drive cache directory under
encrypted environment.
Design doc:
https://docs.google.com/document/d/1Kdq-b5kpudbotQ1q2GRNd52f-oZUrf7mfuZb1XUqH4U/edit#heading=h.sa3sh9r88p48

BUG= chromium:533750 , chromium:618523 
TEST=P2_TEST_FILTER="PlatformTest.*" cros_workon_make --test cryptohome
(BOARD=link, x86-alex, umaro)

Change-Id: I318091ffb329554aad68dac8a4040d66985ee333
Reviewed-on: https://chromium-review.googlesource.com/351140
Commit-Ready: Keigo Oka <oka@chromium.org>
Tested-by: Keigo Oka <oka@chromium.org>
Reviewed-by: Keigo Oka <oka@chromium.org>
Reviewed-by: Darren Krahn <dkrahn@chromium.org>

[modify] https://crrev.com/959250c43694a8e553873ad03e5ac642492668eb/cryptohome/platform_unittest.cc
[modify] https://crrev.com/959250c43694a8e553873ad03e5ac642492668eb/cryptohome/platform.cc
[modify] https://crrev.com/959250c43694a8e553873ad03e5ac642492668eb/cryptohome/platform.h