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 5a93790d4e2df73e30c965ec6e49be82fc3ccfcepatch

经查在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的编译。




已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页