Linux基础备忘_08: LTP(Linux test project)

https://github.com/linux-test-project/ltp

ltp-scanner的编译需要:

# yum install flex

#yum install byacc

如果使用auto configuration，还需要

#yum install autoconf automake

configuration:

#./configure

#make all

#make install

#/opt/ltp/runltp

log文件: /opt/ltp/results/

ltp组织结构相关:

默认run scenario_groups/default中的test cases，或者

run -f nfs,commands,/tmp/testfile 后面是runtest目录里的description文件。

ltp 2017/04/10/ master的一些FAIL（run在一铭server7上, kenel  3.10.0-327.36.1.el7.x86_64）:

======

1）getxattr04 1 

注意这里的错误代码并不是syscall getxattr返回的错误代码

分析:

getxattr(TESTFILE, "trusted.small",..,...)

调试时可以只编译该文件，例如：gcc -g -O2 -g -O2 -fno-strict-aliasing -pipe -Wall -W -Wold-style-definition -D_FORTIFY_SOURCE=2 -I/root/Downloads/ltp-master_20170411/ltp-master/testcases/kernel/include -I../../../../include -I../../../../include -I../../../../include/old/   -L../../../../lib  getxattr05.c   -lltp -o getxattr05

【20170411】怀疑是ltp代码问题，open了一个ltp的issue。

结论：并不是ltp问题，该case如果fail，是linux kernel一个bug没有fix，commit 5a93790d4e2df73e30c965ec6e49be82fc3ccfce, patch

经查在3.16kernel中，xfs_attr_get()中还在做xfs_inode_hasattr()的判断，还没有fix这个bug.

======

2）dirtyc0w

该测试的内容是：打开文件"test",mmap进内存

对FAIL的考虑一：execlp无法正确调用dirtyc0w_child?

execlp("date", "date", NULL) 输出日期，运行至PASS。

作为完全不要框架，单独的case：main()中的 execlp("./test.sh", "./test.sh", NULL);

作为框架中的case：dirtyc0w_test()中的 execlp("./test.sh", "./test.sh", NULL);不工作，其它条件完全相同。

但是测试目录中，即使copy to /usr/bin/dirtyc0w_child，仍然同样的fail，所以必须先修改FAIL考虑二。

经验证：

#cd /opt/ltp/testcases/bin/

#cp dirtyc0w_child dirtyc0w_child.bak

编写dirtyc0w_child: pwd;touch -f /tmp/abc; date;

结论：可以从测试目录/opt/ltp/testcases/bin/中正确调用dirtyc0w_child.

对FAIL的考虑二：

这个FAIL与一个redhat的安全漏洞有关，该安全漏洞"dirty COW"参考https://access.redhat.com/security/vulnerabilities/DirtyCow

Linux COW简介：http://www.cnblogs.com/biyeymyhjob/archive/2012/07/20/2601655.html

syscall madvise简介：http://blog.csdn.net/wenjieky/article/details/8865272

#man madvise

/proc/self/mem is not writable on Red Hat Enterprise Linux 5 and 6. 所以这个case是会failed.

后续可以从https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c16展开一些systemtap(1),(2),(3)的研究。

结论：同getxatrr()类似，这个case也是对某个bug的fix的regression测试：commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619， 详细介绍和patch看这里。

======

3）memfd_create01/02

实际返回的错误是EINVID（name or flag not support）

CHECK_MFD_NEW()宏-->sys_memfd_create()-->syscall(NR,name,flag)，调用系统调用memfd_create()

参考http://www.man7.org/linux/man-pages/man2/memfd_create.2.html

在/usr/src/kernels/3.10.0-327.36.1.el7.x86_64/include/uapi/linux/memfd.h中定义了MFD_ALLOW_SEALING，

但在系统的fcntl.h并没找到F_SEAL_*，即使include了ltp安装目录中的fcntl.h后，系统调用memfd_create()还是会fail，

应该还是linux升级问题，memfd_create()和F_*_SEAL在kernel 3.17引入。

在cases中有对memfd_create()的assert，结论是能syscall但没有seal， flags如果用MFD_ALLOW_SEALING会失败。

用例子代码验证得知： syscall(319, name, flag)flag为0或1没问题，但 syscall(319, name, 2)会EINVAL。

值得注意的是从这个case可以发现：在ltp的框架内，因为被预编译了，strace往往发现不了其中的syscall的，

主要看case中有无main()入口吧。

======

4）dio30

kernel/io/direct_io/diotest6 -b 65536 -n 100 -i 1000 -o 1024000

child=100，nvector = 20，iter=1000

100个子进程，循环1000次，20个vector，每个的buf是64k。

rerun PASS

以上FAIL使用CENTOS RPM 将内核升级到3.10.0-514.16.1.el7.x86_64后，全部PASS

======

5）grep -nr tst_info ./ 这个函数在network/stress中用到，却没有定义，将来编译可能出错？，现在make时跳过了对network的编译。