(Bug found himself before the selection can be more in-depth analysis of the problem on the next course)
patch corresponding to commit: 9af831cdf6d2328e6f6fcd85dd1d5523fd8681d3

BUG found

Individual learning linux or linux related coding practices, like using qemu start a virtual machine (start fast, easy to replace the kernel).
at the beginning of the contact ltp, began cross-platform execution ltp (to see under ltp compatibility), then FAIL many use cases one by one and then start the analysis until utimensat_tests.sh, error: "chattr: Inappropriate ioctl for device while reading flags on testfile".

BUG analysis

1. Preliminary analysis
Used LTP knows, LTP's success, tips or failure are accompanied by TPASS / TCONF / TFAIL, however: error in front of "chattr Inappropriate ioctl for device while reading flags on testfile" and LTP is no built-in message tags, so for the first time to see the feel is an unusual case, the exception is the case in undiscovered by.

2. Problem reproduce & Positioning
The method for positioning a shell script, the best way is sh -x command mode.
1) First, cd to testcases / bin directory, direct sh utimensat_tests.sh, so in order to reproduce the problem. Could not be performed because of the need to add LTP_ROOT environment variable in the script. Xxx.sh changed. ./Xxx.sh (small problem, you can try to solve).
2) Since the problem and found sh utimensat_tests.sh can reproduce is executed sh -x utimensat_tests.sh &> log. -X execution flow parameters will shell script to print out, including intermediate variable assignment, execution log Import log.
3) open utimensat_tests.sh last execution process log and each row contrast, to find the error location (in this case dual better Oh).
command eventually found hanging chattr -ai FILEThisin( $FILEThisin($You can add echo $ FILE FILE printed in error location)
reproducing step:

# echo "testfile" > testfile
# chattr +a testfile
chattr: Inappropriate ioctl for device while reading flags on testfile

3. Analysis
for analysis of the problem, several methods are summarized individuals, wherein the order of priority is:
google search for answers> SEE characteristics data (data chattr)> look at the source code (linux need to understand that it is an error or mistake chattr)> LTP community-mail questions

We go step by step:
1) google search for answers (you can try to Baidu, the basic will not get the answers you want)
by google search, can see many problems associated with the given discussion. For us, need to look past each each, and then search for useful information
for example
https://www.linuxquestions.org/questions/linux-software-2/lsattr-inappropriate-ioctl-for-device-while-reading-flags-910119/

I have turned off Selinux on this computer. So the issue of Selinux should not arise. Thanks

Or
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/469664

eCryptfs doesn’t support lsattr. It is an ext[345] specific tool that is shipped in e2fsprogs. It simply just isn’t supposed to work on eCryptfs.

So, in fact most of the answers hidden in here.

In the middle you can try your local environment, rule out some possible. For example Selinux, I certainly did not install qemu can be excluded; eCryptfs I did not System (mount view the file system mount type), but the middle of a very important piece of information, "It is an ext [345] specific tool that is shipped in e2fsprogs ", here we refer chattr. Like this, because I qemu virtual machine's file system mount type tmpfs, that is, memory file system, not ext [345].
but the above is only speculation, we guess with read on.

2) Check the characteristics data
here speak only way a few good access to commands or system calls, in fact, I also mentioned other blog
google chattr: If you do not understand the chattr, recommended Baidu or google, next to understand what it is functional;
man chattr: official documents, definitely worth a look;
is recommended not to see the other, these enough. Through the above analysis can probably chattr to be added to the file attributes, such as + to increase property - is deleted.

3) look at the source code
linux kernel mode problem is to distinguish between user mode problem or the problem (error have different signs). For beginners, it is recommended strace command:

#strace chattr +a testfile
…
openat(AT_FDCWD, "testfile", O_RDONLY|O_NONBLOCK) = 3
ioctl(3, FS_IOC32_GETFLAGS or FS_IOC_GETFLAGS, 0xfffffd1b9ca4) = -1 ENOTTY (Inappropriate ioctl for device)
close(3)                                = 0
…

The key error in the ioctl (3, FS_IOC32_GETFLAGS or FS_IOC_GETFLAGS, 0xfffffd1b9ca4) = -1 ENOTTY (Inappropriate ioctl for device), where the error is reported out of it, according to the command: Command -> related system call -> libc library - > linux kernel, we searched one by one.

a. chattr source

# which chattr
/usr/bin/chattr
# rpm -qf /usr/bin/chattr
e2fsprogs-xxx.aarch64 (I hide the version number ha)

All commands can access the package source by the above method
then the corresponding version of the package google, search must extract:
locations:https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
I downloaded the latest version, in theory, you should download the corresponding version with Kazakhstan

$ tar -xvf e2fsprogs-1.44.3.tar.gz
$ cd e2fsprogs-1.44.3
$ grep "Inappropriate ioctl for device" -rn *
$ 

Other results:
glibc：

$ grep "Inappropriate ioctl for device" -rn *
sysdeps/unix/bsd/bsd4.4/bits/errno.h:66:#define ENOTTY          25              /* Inappropriate ioctl for device */
sysdeps/gnu/errlist.c:285:    [ERR_REMAP (ENOTTY)] = N_("Inappropriate ioctl for device"),
sysdeps/mach/hurd/bits/errno.h:63:#define       ENOTTY          _HURD_ERRNO (25)/* Inappropriate ioctl for device */

linux：

$ grep "Inappropriate ioctl for device" -rn *
fs/fat/file.c:137:              return -ENOTTY; /* Inappropriate ioctl for device */

After analysis found that not much value.

4) and then look back to official information (man chattr)
positioning problem like this, it is possible to directly find, there may run into a wall, it does not matter, we further in-depth look at (personally think that this is the time growing up).

BUGS AND LIMITATIONS
The ‘c’, ‘s’, and ‘u’ attributes are not honored by the ext2, ext3, and ext4 filesystems as implemented in the current mainline Linux kernels.
The ‘j’ option is only useful if the filesystem is mounted as ext3 or ext4.
The ‘D’ option is only useful on Linux kernel 2.5.19 and later.

and also

Not all flags are supported or utilized by all filesystems; refer to
filesystem-specific man pages such as btrfs(5), ext4(5), and xfs(5)
for more filesystem-specific details.

Combination of the above questions, is not it a little way out of feeling, not all file system types support this feature. We do a test:
ext3 file system mount directory (/ dev / sda2 on / type ext3 (rw, relatime)), as follows

# cd /
# echo "testfile" > testfile
# chattr +a testfile

Directory mount tmpfs file system (tmpfs on / run type tmpfs) (rw, nosuid, nodev, mode = 755), as follows

# cd /run
# echo "testfile" > testfile
# chattr +a testfile
chattr: Inappropriate ioctl for device while reading flags on testfile

It has a relationship with the original file system type. Back then look up the information, you will find attr characteristics ext [234] support, tmpfs is not supported.

Submit Patch

Specific way submit patch in the back of my blog (LTP (Linux Test Project) learning (seven) - LTP submit patches）
stickers just to patch content (plus a check)

commit 9af831cdf6d2328e6f6fcd85dd1d5523fd8681d3
Author: Cui Bixuan <cuibixuan@huawei.com>
Date:   Wed Apr 29 08:53:40 2015 +0800

    syscalls/utimensat01: "chattr" command error

    The "chattr" command in case failed in some file system(such as memory fs):
    'chattr: Inappropriate ioctl for device while reading flags on'

    I learn that chattr command only can be used in ext2 or ext3 (ext4 is ok now).
    So we check it before running.

    Signed-off-by: Cui Bixuan <cuibixuan@huawei.com>

diff --git a/testcases/kernel/syscalls/utimensat/utimensat_tests.sh b/testcases/kernel/syscalls/utimensat/utimensat_tests.sh
index 6bc2030..6adc042 100755
--- a/testcases/kernel/syscalls/utimensat/utimensat_tests.sh
+++ b/testcases/kernel/syscalls/utimensat/utimensat_tests.sh
@@ -295,6 +295,15 @@ nuke_sudoers()
 }
sudo $s_arg -u $test_user mkdir -p $TEST_DIR
+
+# Make sure chattr command is supported
+touch $TEST_DIR/tmp_file
+chattr +a $TEST_DIR/tmp_file
+if [ $? -ne 0 ] ; then
+       rm -rf $TEST_DIR
+       tst_brkm TCONF "chattr not supported"
+fi
+
 cd $TEST_DIR
 chown root $LTPROOT/testcases/bin/$TEST_PROG
 chmod ugo+x,u+s $LTPROOT/testcases/bin/$TEST_PROG

Other similar:

commit 34bf3e86ab1a14b2d38f5bb4ab2ffae65b5ec68d
Author: Cui Bixuan <cuibixuan@huawei.com>
Date:   Mon May 18 20:40:57 2015 +0800

    open/open12: Check the kernel version for 'MS_STRICTATIME'

    Call tst_kvercmp() to check the kernel version(newer than 2.6.30) before
    calling SAFE_MOUNT( MS_STRICTATIME ).

    Signed-off-by: Cui Bixuan <cuibixuan@huawei.com>

diff --git a/testcases/kernel/syscalls/open/open12.c b/testcases/kernel/syscalls/open/open12.c
index af3fab3..5bbf9ee 100644
--- a/testcases/kernel/syscalls/open/open12.c
+++ b/testcases/kernel/syscalls/open/open12.c
@@ -90,6 +90,14 @@ static void setup(void)
        if (tst_path_has_mnt_flags(cleanup, NULL, mount_flags)) {
                const char *fs_type;

+               if ((tst_kvercmp(2, 6, 30)) < 0) {
+                       tst_resm(TCONF,
+                               "MS_STRICTATIME flags for mount(2) needs kernel 2.6.30 "
+                               "or higher");
+                       skip_noatime = 1;
+                       return;
+               }
+

From

man mount(2)
MS_STRICTATIME (since Linux 2.6.30)
              Always  update  the last access time (atime) when files on this filesystem are accessed.  (This was the default behavior before Linux 2.6.30.)  Specifying this flag overrides the effect of
              setting the MS_NOATIME and MS_RELATIME flags.