* [LTP] LTP's filecaps test gives false positive results
@ 2010-03-02 10:11 Iranna D Ankad
2010-03-02 15:21 ` Serge E. Hallyn
2010-03-02 16:39 ` Garrett Cooper
0 siblings, 2 replies; 13+ messages in thread
From: Iranna D Ankad @ 2010-03-02 10:11 UTC (permalink / raw)
To: ltp-list; +Cc: Rishikesh K Rajak, Serge E Hallyn
[-- Attachment #1.1: Type: text/plain, Size: 11871 bytes --]
Hello ..
When I am trying to run LTP's filecaps test, it does not actually run the
test, but ltp-pan report test PASSED.
This is happening in the latest LTP (ltp-full-20100228), including couple
of past LTP releases (ex. November, December releases)
---------------------------------------------------------------------------------------------------------------------------------------------------
mx3950:/opt/ltp # ./runltp -f filecaps
INFO: creating /opt/ltp/results directory
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
LSB_VERSION="core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64"
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 1
Linux mx3950 2.6.32.8-default #1 SMP Fri Feb 26 18:45:10 EST 2010 x86_64
x86_64 x86_64 GNU/Linux
Gnu C gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision
152973]
Gnu make 3.81
util-linux ng 2.16)
mount ng 2.16 (with libblkid and selinux support)
modutils 3.11.1
e2fsprogs 1.41.9
PPP 2.4.5
Linux C Library 2.11.1
Dynamic linker (ldd) 2.11.1
Procps 3.2.7
Net-tools 1.60
iproute2 iproute2-ss090324
Kbd 1.14.1
Sh-utils 6.12
Modules Loaded radeon ttm drm_kms_helper drm i2c_algo_bit ipv6
microcode fuse loop dm_mod rtc_cmos ses i2c_piix4 rtc_core sr_mod
usb_storage rtc_lib acpi_memhotplug sg pcspkr serio_raw joydev enclosure
button i2c_core cdrom usbhid hid ohci_hcd ehci_hcd sd_mod ssb crc_t10dif
mmc_core usbcore pcmcia pcmcia_core edd ext3 mbcache jbd fan processor
ata_generic thermal thermal_sys hwmon
free reports:
total used free shared buffers cached
Mem: 33019056 2530968 30488088 0 108020 1218628
-/+ buffers/cache: 1204320 31814736
Swap: 20964816 0 20964816
/proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Xeon(TM) CPU 3.16GHz
stepping : 8
cpu MHz : 3169.236
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
lm constant_tsc pebs bts pni dtes64 monitor ds_cpl vmx est tm2 cid cx16
xtpr pdcm lahf_lm tpr_shadow vnmi
bogomips : 6338.47
clflush size : 64
cache_alignment : 128
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Xeon(TM) CPU 3.16GHz
stepping : 8
cpu MHz : 3169.236
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
lm constant_tsc pebs bts pni dtes64 monitor ds_cpl vmx est tm2 cid cx16
xtpr pdcm lahf_lm tpr_shadow vnmi
bogomips : 6339.10
clflush size : 64
cache_alignment : 128
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Xeon(TM) CPU 3.16GHz
stepping : 8
cpu MHz : 3169.236
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
lm constant_tsc pebs bts pni dtes64 monitor ds_cpl vmx est tm2 cid cx16
xtpr pdcm lahf_lm tpr_shadow vnmi
bogomips : 6339.19
clflush size : 64
cache_alignment : 128
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Xeon(TM) CPU 3.16GHz
stepping : 8
cpu MHz : 3169.236
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
lm constant_tsc pebs bts pni dtes64 monitor ds_cpl vmx est tm2 cid cx16
xtpr pdcm lahf_lm tpr_shadow vnmi
bogomips : 6339.16
clflush size : 64
cache_alignment : 128
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 4
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Xeon(TM) CPU 3.16GHz
stepping : 8
cpu MHz : 3169.236
cache size : 8192 KB
physical id : 1
siblings : 4
core id : 0
cpu cores : 2
apicid : 4
initial apicid : 4
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
lm constant_tsc pebs bts pni dtes64 monitor ds_cpl vmx est tm2 cid cx16
xtpr pdcm lahf_lm tpr_shadow vnmi
bogomips : 6339.29
clflush size : 64
cache_alignment : 128
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 5
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Xeon(TM) CPU 3.16GHz
stepping : 8
cpu MHz : 3169.236
cache size : 8192 KB
physical id : 1
siblings : 4
core id : 0
cpu cores : 2
apicid : 5
initial apicid : 5
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
lm constant_tsc pebs bts pni dtes64 monitor ds_cpl vmx est tm2 cid cx16
xtpr pdcm lahf_lm tpr_shadow vnmi
bogomips : 6339.25
clflush size : 64
cache_alignment : 128
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 6
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Xeon(TM) CPU 3.16GHz
stepping : 8
cpu MHz : 3169.236
cache size : 8192 KB
physical id : 1
siblings : 4
core id : 1
cpu cores : 2
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
lm constant_tsc pebs bts pni dtes64 monitor ds_cpl vmx est tm2 cid cx16
xtpr pdcm lahf_lm tpr_shadow vnmi
bogomips : 6339.28
clflush size : 64
cache_alignment : 128
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 7
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Xeon(TM) CPU 3.16GHz
stepping : 8
cpu MHz : 3169.236
cache size : 8192 KB
physical id : 1
siblings : 4
core id : 1
cpu cores : 2
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
lm constant_tsc pebs bts pni dtes64 monitor ds_cpl vmx est tm2 cid cx16
xtpr pdcm lahf_lm tpr_shadow vnmi
bogomips : 6339.29
clflush size : 64
cache_alignment : 128
address sizes : 40 bits physical, 48 bits virtual
power management:
remove test cases which require the block device.
You can specify it with option -b
COMMAND: /opt/ltp/bin/ltp-pan -e -S -a 12064 -n 12064 -p -f
/tmp/ltp-P00GfUUqLS/alltests -l
/opt/ltp/results/LTP_RUN_ON-2010_Mar_02-04h_14m_57s.log -C
/opt/ltp/output/LTP_RUN_ON-2010_Mar_02-04h_14m_57s.failed
LOG File: /opt/ltp/results/LTP_RUN_ON-2010_Mar_02-04h_14m_57s.log
FAILED COMMAND File:
/opt/ltp/output/LTP_RUN_ON-2010_Mar_02-04h_14m_57s.failed
Running tests.......
<<<test_start>>>
tag=Filecaps stime=1267521297
cmdline="filecapstest.sh"
contacts=""
analysis=exit
<<<test_output>>>
incrementing stop
Filecaps 0 CONF : System doesn't support execution of the test
setcap not installed. Please install libcap-2.11 or newer from
ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/libcap2
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
INFO: ltp-pan reported all tests PASS
LTP Version: LTP-20100131
###############################################################"
Done executing testcases."
LTP Version: LTP-20100131
###############################################################"
mx3950:/opt/ltp #
---------------------------------------------------------------------------------------------------------------------------------------------------
LTP reports setcap is installed, but actually, my system has setcap
installed, along with all required libcap related rpms.
mx3950:/opt/ltp # setc
setcap setconsole setctsid
mx3950:/opt/ltp #
mx3950:/opt/ltp # rpm -qa | grep cap
libcap1-1.10-6.10
libcap2-2.11-2.15
libcap-progs-2.11-2.15
libpcap0-0.9.8-50.4.32
libcap2-32bit-2.11-2.15
libcap1-32bit-1.10-6.10
mx3950:/opt/ltp #
---------------------------------------------------------------------------------------------------------------------------------------------------
Here is the false positive log, which shows test PASSED, without actually
running the test.
---------------------------------------------------------------------------------------------------------------------------------------------------
mx3950:/opt/ltp # cat results/LTP_RUN_ON-2010_Mar_02-04h_14m_57s.log
Test Start Time: Tue Mar 2 04:14:57 2010
-----------------------------------------
Testcase Result Exit Value
-------- ------ ----------
Filecaps PASS 0
-----------------------------------------------
Total Tests: 1
Total Failures: 0
Kernel Version: 2.6.32.8-default
Machine Architecture: x86_64
Hostname: mx3950
mx3950:/opt/ltp #
---------------------------------------------------------------------------------------------------------------------------------------------------
Thanks!
-Iranna D Ankad
----------------------------------------------------------------------------------------------------
Linux-Technology Center, IBM India Software Labs
Manyata Embassy Park, BENGALURU - 560045,
Ph: +91-080-28055007 Extn: 55007
----------------------------------------------------------------------------------------------------
"If you don't have patience to test the software, the software will test
your patience !!"
[-- Attachment #1.2: Type: text/html, Size: 30985 bytes --]
[-- Attachment #2: Type: text/plain, Size: 345 bytes --]
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
[-- Attachment #3: Type: text/plain, Size: 155 bytes --]
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] LTP's filecaps test gives false positive results
2010-03-02 10:11 [LTP] LTP's filecaps test gives false positive results Iranna D Ankad
@ 2010-03-02 15:21 ` Serge E. Hallyn
2010-03-02 16:25 ` Garrett Cooper
2010-03-02 16:39 ` Garrett Cooper
1 sibling, 1 reply; 13+ messages in thread
From: Serge E. Hallyn @ 2010-03-02 15:21 UTC (permalink / raw)
To: Iranna D Ankad; +Cc: Rishikesh K Rajak, ltp-list
Quoting Iranna D Ankad (iranna.ankad@in.ibm.com):
> LTP reports setcap is installed, but actually, my system has setcap
> installed, along with all required libcap related rpms.
>
> mx3950:/opt/ltp # setc
> setcap setconsole setctsid
> mx3950:/opt/ltp #
>
> mx3950:/opt/ltp # rpm -qa | grep cap
> libcap1-1.10-6.10
> libcap2-2.11-2.15
> libcap-progs-2.11-2.15
> libpcap0-0.9.8-50.4.32
> libcap2-32bit-2.11-2.15
> libcap1-32bit-1.10-6.10
> mx3950:/opt/ltp #
THere are a bunch of #if directives in there (only looked at
check_simple_capset.c which I assume is where your trouble is) which
are not defined on my fedora 10 test system. Don't know where they
came from - they predate the git history.
HAVE_SYS_CAPABILITY_H, HAVE_DECL_CAP_FROM_TEXT, etc.
-serge
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] LTP's filecaps test gives false positive results
2010-03-02 15:21 ` Serge E. Hallyn
@ 2010-03-02 16:25 ` Garrett Cooper
2010-03-02 17:35 ` Serge E. Hallyn
0 siblings, 1 reply; 13+ messages in thread
From: Garrett Cooper @ 2010-03-02 16:25 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: Rishikesh K Rajak, Iranna D Ankad, ltp-list
Sent from my iPhone
On Mar 2, 2010, at 7:21 AM, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> Quoting Iranna D Ankad (iranna.ankad@in.ibm.com):
>> LTP reports setcap is installed, but actually, my system has setcap
>> installed, along with all required libcap related rpms.
>>
>> mx3950:/opt/ltp # setc
>> setcap setconsole setctsid
>> mx3950:/opt/ltp #
>>
>> mx3950:/opt/ltp # rpm -qa | grep cap
>> libcap1-1.10-6.10
>> libcap2-2.11-2.15
>> libcap-progs-2.11-2.15
>> libpcap0-0.9.8-50.4.32
>> libcap2-32bit-2.11-2.15
>> libcap1-32bit-1.10-6.10
>> mx3950:/opt/ltp #
>
> THere are a bunch of #if directives in there (only looked at
> check_simple_capset.c which I assume is where your trouble is) which
> are not defined on my fedora 10 test system. Don't know where they
> came from - they predate the git history.
>
> HAVE_SYS_CAPABILITY_H, HAVE_DECL_CAP_FROM_TEXT, etc.
>
> -serge
That would be from me; I do that via autoconf and they probably
fubared the headers on Redhat or something... Do you have libcap-devel
installed?
Fwiw, that probably could be grossly simplified at the top of the file
or something, do I'll look into doing that later.
Thanks,
-Garrett
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] LTP's filecaps test gives false positive results
2010-03-02 10:11 [LTP] LTP's filecaps test gives false positive results Iranna D Ankad
2010-03-02 15:21 ` Serge E. Hallyn
@ 2010-03-02 16:39 ` Garrett Cooper
1 sibling, 0 replies; 13+ messages in thread
From: Garrett Cooper @ 2010-03-02 16:39 UTC (permalink / raw)
To: Iranna D Ankad; +Cc: Rishikesh K Rajak, ltp-list, Serge E Hallyn
[-- Attachment #1.1: Type: text/plain, Size: 3338 bytes --]
On Mar 2, 2010, at 2:11 AM, Iranna D Ankad <iranna.ankad@in.ibm.com>
wrote:
>
> Hello ..
> When I am trying to run LTP's filecaps test, it does not actually
> run the test, but ltp-pan report test PASSED.
> This is happening in the latest LTP (ltp-full-20100228), including
> couple of past LTP releases (ex. November, December releases)
> remove test cases which require the block device.
> You can specify it with option -b
> COMMAND: /opt/ltp/bin/ltp-pan -e -S -a 12064 -n 12064 -p
> -f /tmp/ltp-P00GfUUqLS/alltests -l /opt/ltp/results/
> LTP_RUN_ON-2010_Mar_02-04h_14m_57s.log -C /opt/ltp/output/
> LTP_RUN_ON-2010_Mar_02-04h_14m_57s.failed
> LOG File: /opt/ltp/results/LTP_RUN_ON-2010_Mar_02-04h_14m_57s.log
> FAILED COMMAND File: /opt/ltp/output/
> LTP_RUN_ON-2010_Mar_02-04h_14m_57s.failed
> Running tests.......
> <<<test_start>>>
> tag=Filecaps stime=1267521297
> cmdline="filecapstest.sh"
> contacts=""
> analysis=exit
> <<<test_output>>>
> incrementing stop
> Filecaps 0 CONF : System doesn't support execution of the test
> setcap not installed. Please install libcap-2.11 or newer from
> ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/libcap2
> <<<execution_status>>>
> initiation_status="ok"
> duration=0 termination_type=exited termination_id=0 corefile=no
> cutime=0 cstime=0
> <<<test_end>>>
> INFO: ltp-pan reported all tests PASS
> LTP Version: LTP-20100131
The _libraries and apps_ are installed, not the _headers_.
> LTP reports setcap is installed, but actually, my system has setcap
> installed, along with all required libcap related rpms.
>
> mx3950:/opt/ltp # setc
> setcap setconsole setctsid
> mx3950:/opt/ltp #
>
> mx3950:/opt/ltp # rpm -qa | grep cap
> libcap1-1.10-6.10
> libcap2-2.11-2.15
> libcap-progs-2.11-2.15
> libpcap0-0.9.8-50.4.32
> libcap2-32bit-2.11-2.15
> libcap1-32bit-1.10-6.10
> mx3950:/opt/ltp #
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---------------------------------------------------------------------
>
>
> Here is the false positive log, which shows test PASSED, without
> actually running the test.
The problem is that TCONF should return 0 (in this case the library's
functionality isn't available on the running system, so the tests
can't be run).
I don't see a problem with this 'error' -- the problem I see that
needs to be rectified is the -devel packages need to be installed on
the machine.
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---
> ---------------------------------------------------------------------
>
> mx3950:/opt/ltp # cat results/LTP_RUN_ON-2010_Mar_02-04h_14m_57s.log
> Test Start Time: Tue Mar 2 04:14:57 2010
> -----------------------------------------
> Testcase Result Exit Value
> -------- ------ ----------
> Filecaps PASS 0
> -----------------------------------------------
> Total Tests: 1
> Total Failures: 0
> Kernel Version: 2.6.32.8-default
> Machine Architecture: x86_64
> Hostname: mx3950
>
> mx3950:/opt/ltp #
Thanks,
-Garrett
[-- Attachment #1.2: Type: text/html, Size: 7146 bytes --]
[-- Attachment #2: Type: text/plain, Size: 345 bytes --]
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
[-- Attachment #3: Type: text/plain, Size: 155 bytes --]
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] LTP's filecaps test gives false positive results
2010-03-02 16:25 ` Garrett Cooper
@ 2010-03-02 17:35 ` Serge E. Hallyn
2010-03-02 18:25 ` Garrett Cooper
0 siblings, 1 reply; 13+ messages in thread
From: Serge E. Hallyn @ 2010-03-02 17:35 UTC (permalink / raw)
To: Garrett Cooper; +Cc: Rishikesh K Rajak, Iranna D Ankad, ltp-list
Quoting Garrett Cooper (yanegomi@gmail.com):
> Sent from my iPhone
>
> On Mar 2, 2010, at 7:21 AM, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
>
> >Quoting Iranna D Ankad (iranna.ankad@in.ibm.com):
> >>LTP reports setcap is installed, but actually, my system has setcap
> >>installed, along with all required libcap related rpms.
> >>
> >>mx3950:/opt/ltp # setc
> >>setcap setconsole setctsid
> >>mx3950:/opt/ltp #
> >>
> >>mx3950:/opt/ltp # rpm -qa | grep cap
> >>libcap1-1.10-6.10
> >>libcap2-2.11-2.15
> >>libcap-progs-2.11-2.15
> >>libpcap0-0.9.8-50.4.32
> >>libcap2-32bit-2.11-2.15
> >>libcap1-32bit-1.10-6.10
> >>mx3950:/opt/ltp #
> >
> >THere are a bunch of #if directives in there (only looked at
> >check_simple_capset.c which I assume is where your trouble is) which
> >are not defined on my fedora 10 test system. Don't know where they
> >came from - they predate the git history.
> >
> >HAVE_SYS_CAPABILITY_H, HAVE_DECL_CAP_FROM_TEXT, etc.
> >
> >-serge
>
> That would be from me; I do that via autoconf and they probably
> fubared the headers on Redhat or something... Do you have
Oh, ok. Well I suspect we can ditch the check_simple_capset.c
altogether if autoconf is (eventually :) doing the detection for
us. The only point of check_simple_capset.c was to check whether
libcap is there and whether we should run the real tests.
> libcap-devel installed?
yup:
[root@oracer4b ltp-dev]# rpm -qa|grep libcap
libcap-2.10-2.fc10.x86_64
libcap-devel-2.10-2.fc10.x86_64
[root@oracer4b ltp-dev]# grep CAP_LIB *
config.log:CAP_LIBS=''
config.status:S["CAP_LIBS"]=""
configure:CAP_LIBS'
configure: CAP_LIBS="-lcap"
so somehow -lcap was not detected by configure?
> Fwiw, that probably could be grossly simplified at the top of the
> file or something, do I'll look into doing that later.
Thanks
-serge
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] LTP's filecaps test gives false positive results
2010-03-02 17:35 ` Serge E. Hallyn
@ 2010-03-02 18:25 ` Garrett Cooper
2010-03-03 5:56 ` Rishikesh K Rajak
0 siblings, 1 reply; 13+ messages in thread
From: Garrett Cooper @ 2010-03-02 18:25 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: Rishikesh K Rajak, Iranna D Ankad, ltp-list
On Mar 2, 2010, at 9:35 AM, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> Quoting Garrett Cooper (yanegomi@gmail.com):
>> Sent from my iPhone
>>
>> On Mar 2, 2010, at 7:21 AM, "Serge E. Hallyn" <serue@us.ibm.com>
>> wrote:
>>
>>> Quoting Iranna D Ankad (iranna.ankad@in.ibm.com):
>>>> LTP reports setcap is installed, but actually, my system has setcap
>>>> installed, along with all required libcap related rpms.
>>>>
>>>> mx3950:/opt/ltp # setc
>>>> setcap setconsole setctsid
>>>> mx3950:/opt/ltp #
>>>>
>>>> mx3950:/opt/ltp # rpm -qa | grep cap
>>>> libcap1-1.10-6.10
>>>> libcap2-2.11-2.15
>>>> libcap-progs-2.11-2.15
>>>> libpcap0-0.9.8-50.4.32
>>>> libcap2-32bit-2.11-2.15
>>>> libcap1-32bit-1.10-6.10
>>>> mx3950:/opt/ltp #
>>>
>>> THere are a bunch of #if directives in there (only looked at
>>> check_simple_capset.c which I assume is where your trouble is) which
>>> are not defined on my fedora 10 test system. Don't know where they
>>> came from - they predate the git history.
>>>
>>> HAVE_SYS_CAPABILITY_H, HAVE_DECL_CAP_FROM_TEXT, etc.
>>>
>>> -serge
>>
>> That would be from me; I do that via autoconf and they probably
>> fubared the headers on Redhat or something... Do you have
>
> Oh, ok. Well I suspect we can ditch the check_simple_capset.c
> altogether if autoconf is (eventually :) doing the detection for
> us. The only point of check_simple_capset.c was to check whether
> libcap is there and whether we should run the real tests.
>
>> libcap-devel installed?
>
> yup:
>
> [root@oracer4b ltp-dev]# rpm -qa|grep libcap
> libcap-2.10-2.fc10.x86_64
> libcap-devel-2.10-2.fc10.x86_64
>
> [root@oracer4b ltp-dev]# grep CAP_LIB *
> config.log:CAP_LIBS=''
> config.status:S["CAP_LIBS"]=""
> configure:CAP_LIBS'
> configure: CAP_LIBS="-lcap"
>
> so somehow -lcap was not detected by configure?
Well some of the definitions are there but maybe not all of them.
config.log would help...
>> Fwiw, that probably could be grossly simplified at the top of the
>> file or something, do I'll look into doing that later.
Cheers!
-Garrett
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] LTP's filecaps test gives false positive results
2010-03-02 18:25 ` Garrett Cooper
@ 2010-03-03 5:56 ` Rishikesh K Rajak
2010-03-03 9:14 ` Garrett Cooper
0 siblings, 1 reply; 13+ messages in thread
From: Rishikesh K Rajak @ 2010-03-03 5:56 UTC (permalink / raw)
To: Garrett Cooper; +Cc: Rishikesh K Rajak, ltp-list, Iranna D Ankad
On Tue, Mar 02, 2010 at 10:25:23AM -0800, Garrett Cooper wrote:
> On Mar 2, 2010, at 9:35 AM, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
>
> > Quoting Garrett Cooper (yanegomi@gmail.com):
> >>
> >> That would be from me; I do that via autoconf and they probably
> >> fubared the headers on Redhat or something... Do you have
> >
> > Oh, ok. Well I suspect we can ditch the check_simple_capset.c
> > altogether if autoconf is (eventually :) doing the detection for
> > us. The only point of check_simple_capset.c was to check whether
> > libcap is there and whether we should run the real tests.
> >
> >> libcap-devel installed?
> >
> > yup:
> >
> > [root@oracer4b ltp-dev]# rpm -qa|grep libcap
> > libcap-2.10-2.fc10.x86_64
> > libcap-devel-2.10-2.fc10.x86_64
> >
> > [root@oracer4b ltp-dev]# grep CAP_LIB *
> > config.log:CAP_LIBS=''
> > config.status:S["CAP_LIBS"]=""
> > configure:CAP_LIBS'
> > configure: CAP_LIBS="-lcap"
> >
> > so somehow -lcap was not detected by configure?
>
> Well some of the definitions are there but maybe not all of them.
> config.log would help...
>
Here is the config.log snapshot, it seems it has some error:
...
configure:5543: checking whether CAP_BSET_DROP is declared
configure:5574: gcc -c -g -O2 conftest.c >&5
conftest.c: In function 'main':
conftest.c:38: error: 'CAP_BSET_DROP' undeclared (first use in this
function)
conftest.c:38: error: (Each undeclared identifier is reported only once
conftest.c:38: error: for each function it appears in.)
configure:5581: $? = 1
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "ltp"
| #define PACKAGE_TARNAME "ltp"
| #define PACKAGE_VERSION "LTP_VERSION"
| #define PACKAGE_STRING "ltp LTP_VERSION"
| #define PACKAGE_BUGREPORT "ltp-results@lists.sourceforge.net"
| #define PACKAGE "ltp"
| #define VERSION "LTP_VERSION"
| #define YYTEXT_POINTER 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_IFADDRS_H 1
| #define HAVE_PTHREAD_H 1
| #define HAVE_LINUX_GENETLINK_H 1
| #define HAVE_LINUX_MEMPOLICY_H 1
| #define HAVE_LINUX_NETLINK_H 1
| #define HAVE_SYS_EPOLL_H 1
| #define HAVE_SYS_INOTIFY_H 1
| #define HAVE_SYS_PRCTL_H 1
| #define HAVE_SYS_CAPABILITY_H 1
| #define HAVE_ATTR_XATTR_H 1
| /* end confdefs.h. */
| #include <sys/capability.h>
|
|
| int
| main ()
| {
| #ifndef CAP_BSET_DROP
| (void) CAP_BSET_DROP;
| #endif
|
| ;
| return 0;
2879,13
Which file will contains this macro definition ?
--
Thanks & Regards
Rishi
LTP Maintainer
IBM, LTC, Bangalore
Please join IRC #ltp @ irc.freenode.net
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] LTP's filecaps test gives false positive results
2010-03-03 5:56 ` Rishikesh K Rajak
@ 2010-03-03 9:14 ` Garrett Cooper
2010-03-03 9:23 ` Rishikesh K Rajak
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Garrett Cooper @ 2010-03-03 9:14 UTC (permalink / raw)
To: Garrett Cooper, Serge E. Hallyn, Rishikesh K Rajak,
Iranna D Ankad, ltp-list
On Tue, Mar 2, 2010 at 9:56 PM, Rishikesh K Rajak
<risrajak@linux.vnet.ibm.com> wrote:
> On Tue, Mar 02, 2010 at 10:25:23AM -0800, Garrett Cooper wrote:
>> On Mar 2, 2010, at 9:35 AM, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
>>
>> > Quoting Garrett Cooper (yanegomi@gmail.com):
>> >>
>> >> That would be from me; I do that via autoconf and they probably
>> >> fubared the headers on Redhat or something... Do you have
>> >
>> > Oh, ok. Well I suspect we can ditch the check_simple_capset.c
>> > altogether if autoconf is (eventually :) doing the detection for
>> > us. The only point of check_simple_capset.c was to check whether
>> > libcap is there and whether we should run the real tests.
>> >
>> >> libcap-devel installed?
>> >
>> > yup:
>> >
>> > [root@oracer4b ltp-dev]# rpm -qa|grep libcap
>> > libcap-2.10-2.fc10.x86_64
>> > libcap-devel-2.10-2.fc10.x86_64
>> >
>> > [root@oracer4b ltp-dev]# grep CAP_LIB *
>> > config.log:CAP_LIBS=''
>> > config.status:S["CAP_LIBS"]=""
>> > configure:CAP_LIBS'
>> > configure: CAP_LIBS="-lcap"
>> >
>> > so somehow -lcap was not detected by configure?
>>
>> Well some of the definitions are there but maybe not all of them.
>> config.log would help...
>>
>
> Here is the config.log snapshot, it seems it has some error:
>
> ...
> configure:5543: checking whether CAP_BSET_DROP is declared
> configure:5574: gcc -c -g -O2 conftest.c >&5
> conftest.c: In function 'main':
> conftest.c:38: error: 'CAP_BSET_DROP' undeclared (first use in this
> function)
> conftest.c:38: error: (Each undeclared identifier is reported only once
> conftest.c:38: error: for each function it appears in.)
Yes -- and I think this is because the constants no longer have
the same name:
http://fxr.watson.org/fxr/source/include/linux/prctl.h?v=linux-2.6#L68
Note -- CAP_BSET_DROP should be: PR_CAPBSET_DROP, etc.
Which is why I stress _not_ putting these hardcoded constants in
test files (POLLHDRDUP -- or whatever it was in ppoll01 -- is the only
real violation I can remember OTOH that I need to clean up
eventually). We need to be consistent with any and all documentation
provided to end-developers or we [LTP] are going to shoot ourselves in
the foot if and when the underlying functionality changes.
I'll update the tests this weekend, but I would like it if someone
test the tests on an outdated distro (RHEL 4.x?) once I provide a
patch to ensure that nothing's being regressed. Based on some really
simple inspection it appears that these tests are compatible only with
libcapability 2.x+, but I could be wrong...
Thanks,
-Garrett
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] LTP's filecaps test gives false positive results
2010-03-03 9:14 ` Garrett Cooper
@ 2010-03-03 9:23 ` Rishikesh K Rajak
2010-03-03 16:00 ` Serge E. Hallyn
2010-03-18 9:25 ` Rishikesh K Rajak
2 siblings, 0 replies; 13+ messages in thread
From: Rishikesh K Rajak @ 2010-03-03 9:23 UTC (permalink / raw)
To: Garrett Cooper; +Cc: Rishikesh K Rajak, ltp-list, Iranna D Ankad
On Wed, Mar 03, 2010 at 01:14:12AM -0800, Garrett Cooper wrote:
> I'll update the tests this weekend, but I would like it if someone
> test the tests on an outdated distro (RHEL 4.x?) once I provide a
> patch to ensure that nothing's being regressed. Based on some really
> simple inspection it appears that these tests are compatible only with
> libcapability 2.x+, but I could be wrong...
Yes will definitely do the regression test on 4.x .
--
Thanks & Regards
Rishi
LTP Maintainer
IBM, LTC, Bangalore
Please join IRC #ltp @ irc.freenode.net
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] LTP's filecaps test gives false positive results
2010-03-03 9:14 ` Garrett Cooper
2010-03-03 9:23 ` Rishikesh K Rajak
@ 2010-03-03 16:00 ` Serge E. Hallyn
2010-03-18 9:25 ` Rishikesh K Rajak
2 siblings, 0 replies; 13+ messages in thread
From: Serge E. Hallyn @ 2010-03-03 16:00 UTC (permalink / raw)
To: Garrett Cooper; +Cc: Rishikesh K Rajak, Iranna D Ankad, ltp-list
Quoting Garrett Cooper (yanegomi@gmail.com):
> On Tue, Mar 2, 2010 at 9:56 PM, Rishikesh K Rajak
> <risrajak@linux.vnet.ibm.com> wrote:
> > On Tue, Mar 02, 2010 at 10:25:23AM -0800, Garrett Cooper wrote:
> >> On Mar 2, 2010, at 9:35 AM, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> >>
> >> > Quoting Garrett Cooper (yanegomi@gmail.com):
> >> >>
> >> >> That would be from me; I do that via autoconf and they probably
> >> >> fubared the headers on Redhat or something... Do you have
> >> >
> >> > Oh, ok. Well I suspect we can ditch the check_simple_capset.c
> >> > altogether if autoconf is (eventually :) doing the detection for
> >> > us. The only point of check_simple_capset.c was to check whether
> >> > libcap is there and whether we should run the real tests.
> >> >
> >> >> libcap-devel installed?
> >> >
> >> > yup:
> >> >
> >> > [root@oracer4b ltp-dev]# rpm -qa|grep libcap
> >> > libcap-2.10-2.fc10.x86_64
> >> > libcap-devel-2.10-2.fc10.x86_64
> >> >
> >> > [root@oracer4b ltp-dev]# grep CAP_LIB *
> >> > config.log:CAP_LIBS=''
> >> > config.status:S["CAP_LIBS"]=""
> >> > configure:CAP_LIBS'
> >> > configure: CAP_LIBS="-lcap"
> >> >
> >> > so somehow -lcap was not detected by configure?
> >>
> >> Well some of the definitions are there but maybe not all of them.
> >> config.log would help...
> >>
> >
> > Here is the config.log snapshot, it seems it has some error:
> >
> > ...
> > configure:5543: checking whether CAP_BSET_DROP is declared
> > configure:5574: gcc -c -g -O2 conftest.c >&5
> > conftest.c: In function 'main':
> > conftest.c:38: error: 'CAP_BSET_DROP' undeclared (first use in this
> > function)
> > conftest.c:38: error: (Each undeclared identifier is reported only once
> > conftest.c:38: error: for each function it appears in.)
>
> Yes -- and I think this is because the constants no longer have
> the same name:
>
> http://fxr.watson.org/fxr/source/include/linux/prctl.h?v=linux-2.6#L68
>
> Note -- CAP_BSET_DROP should be: PR_CAPBSET_DROP, etc.
>
> Which is why I stress _not_ putting these hardcoded constants in
> test files (POLLHDRDUP -- or whatever it was in ppoll01 -- is the only
1. this was (almost certainly) a typo on my part
2. not using these constants, like PR_CAPBSET_READ, when testing
prctl(PR_CAPBSET_READ)? I think I must be misunderstanding what
you are suggesting
3. this type of thing almost inevitably results from the desire to
enable ltp to test features early. When features hit -mm for instance,
it is possible for names and such to still change before hitting
upstream. For an extreme example look at
git whatchanged -p include/linux/securebits.h
in the kernel - those features had been there for years, but didn't
get their publically exported names until late last year. I have
been wanting to send ltp testcases for those for years (and have
some sitting around for as long), but the naming problem is exactly
what caused my latest delay.
One day I need to finish those up, bc it's a subtle, rarely-used
and never-tested spot in the kernel code right now. Guess I was
waiting to see when /usr/include/sys/securebits.h magically shows up
in a fedora or ubuntu system.
> real violation I can remember OTOH that I need to clean up
> eventually). We need to be consistent with any and all documentation
> provided to end-developers or we [LTP] are going to shoot ourselves in
> the foot if and when the underlying functionality changes.
> I'll update the tests this weekend, but I would like it if someone
> test the tests on an outdated distro (RHEL 4.x?) once I provide a
I can find/build a RHEL5 box to test on
> patch to ensure that nothing's being regressed. Based on some really
> simple inspection it appears that these tests are compatible only with
> libcapability 2.x+, but I could be wrong...
jinkeys - yes, libcap 1 had its last update in august 2007, and I don't
think it supports 64-bit capabilities.
Note that cap_bound also has a dud 'check_for_libcap.sh' file which
your autoconf magic <waves hands around mysteriously> should be able
to better replace. There is something that could stand to be in ltp
git tree - a little 1-page tutorial for properly adding (1) kernel
feature and (2) library tests to control compilation and running of
ltp tests to autoconf.
> Thanks,
> -Garrett
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] LTP's filecaps test gives false positive results
2010-03-03 9:14 ` Garrett Cooper
2010-03-03 9:23 ` Rishikesh K Rajak
2010-03-03 16:00 ` Serge E. Hallyn
@ 2010-03-18 9:25 ` Rishikesh K Rajak
2010-03-18 14:55 ` Serge E. Hallyn
2 siblings, 1 reply; 13+ messages in thread
From: Rishikesh K Rajak @ 2010-03-18 9:25 UTC (permalink / raw)
To: Garrett Cooper; +Cc: Rishikesh K Rajak, ltp-list, Iranna D Ankad
On Wed, Mar 03, 2010 at 01:14:12AM -0800, Garrett Cooper wrote:
> Yes -- and I think this is because the constants no longer have
> the same name:
>
> http://fxr.watson.org/fxr/source/include/linux/prctl.h?v=linux-2.6#L68
>
> Note -- CAP_BSET_DROP should be: PR_CAPBSET_DROP, etc.
>
> Which is why I stress _not_ putting these hardcoded constants in
> test files (POLLHDRDUP -- or whatever it was in ppoll01 -- is the only
> real violation I can remember OTOH that I need to clean up
> eventually). We need to be consistent with any and all documentation
> provided to end-developers or we [LTP] are going to shoot ourselves in
> the foot if and when the underlying functionality changes.
> I'll update the tests this weekend, but I would like it if someone
> test the tests on an outdated distro (RHEL 4.x?) once I provide a
Hi Garret,
Can you please look this again ?
-Rishi
> patch to ensure that nothing's being regressed. Based on some really
> simple inspection it appears that these tests are compatible only with
> libcapability 2.x+, but I could be wrong...
> Thanks,
> -Garrett
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] LTP's filecaps test gives false positive results
2010-03-18 9:25 ` Rishikesh K Rajak
@ 2010-03-18 14:55 ` Serge E. Hallyn
2010-03-18 19:13 ` Garrett Cooper
0 siblings, 1 reply; 13+ messages in thread
From: Serge E. Hallyn @ 2010-03-18 14:55 UTC (permalink / raw)
To: Garrett Cooper, Rishikesh K Rajak, Iranna D Ankad, ltp-list
Quoting Rishikesh K Rajak (risrajak@linux.vnet.ibm.com):
> On Wed, Mar 03, 2010 at 01:14:12AM -0800, Garrett Cooper wrote:
> > Yes -- and I think this is because the constants no longer have
> > the same name:
> >
> > http://fxr.watson.org/fxr/source/include/linux/prctl.h?v=linux-2.6#L68
> >
> > Note -- CAP_BSET_DROP should be: PR_CAPBSET_DROP, etc.
> >
> > Which is why I stress _not_ putting these hardcoded constants in
> > test files (POLLHDRDUP -- or whatever it was in ppoll01 -- is the only
> > real violation I can remember OTOH that I need to clean up
> > eventually). We need to be consistent with any and all documentation
> > provided to end-developers or we [LTP] are going to shoot ourselves in
> > the foot if and when the underlying functionality changes.
> > I'll update the tests this weekend, but I would like it if someone
> > test the tests on an outdated distro (RHEL 4.x?) once I provide a
>
> Hi Garret,
>
> Can you please look this again ?
Wait, what? Was the original complaint just about a #warning? Note
that it will #warn but then go ahead and define it, so there should not
be a real problem.
Anyway I'll try to get time tomorrow to rewrite this to use the constants
from the new securebits.h (which may not be in sys/ yet, but is in linux/
atm and will show up under sys/ at some point). If Garret could help me
with doing an automate thingamagiggy to detect whether prctl(CAP_BSET_DROP)
returns -ENOSYS and not compile/install/run the tests in that case, that'd
be great.
And maybe I'll finally implement some of the new securebits testcases I
spelled out a year or two ago.
thanks,
-serge
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] LTP's filecaps test gives false positive results
2010-03-18 14:55 ` Serge E. Hallyn
@ 2010-03-18 19:13 ` Garrett Cooper
0 siblings, 0 replies; 13+ messages in thread
From: Garrett Cooper @ 2010-03-18 19:13 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: Rishikesh K Rajak, Iranna D Ankad, ltp-list
On Thu, Mar 18, 2010 at 7:55 AM, Serge E. Hallyn <serue@us.ibm.com> wrote:
> Quoting Rishikesh K Rajak (risrajak@linux.vnet.ibm.com):
>> On Wed, Mar 03, 2010 at 01:14:12AM -0800, Garrett Cooper wrote:
>> > Yes -- and I think this is because the constants no longer have
>> > the same name:
>> >
>> > http://fxr.watson.org/fxr/source/include/linux/prctl.h?v=linux-2.6#L68
>> >
>> > Note -- CAP_BSET_DROP should be: PR_CAPBSET_DROP, etc.
>> >
>> > Which is why I stress _not_ putting these hardcoded constants in
>> > test files (POLLHDRDUP -- or whatever it was in ppoll01 -- is the only
>> > real violation I can remember OTOH that I need to clean up
>> > eventually). We need to be consistent with any and all documentation
>> > provided to end-developers or we [LTP] are going to shoot ourselves in
>> > the foot if and when the underlying functionality changes.
>> > I'll update the tests this weekend, but I would like it if someone
>> > test the tests on an outdated distro (RHEL 4.x?) once I provide a
>>
>> Hi Garret,
>>
>> Can you please look this again ?
>
> Wait, what? Was the original complaint just about a #warning? Note
> that it will #warn but then go ahead and define it, so there should not
> be a real problem.
>
> Anyway I'll try to get time tomorrow to rewrite this to use the constants
> from the new securebits.h (which may not be in sys/ yet, but is in linux/
> atm and will show up under sys/ at some point). If Garret could help me
> with doing an automate thingamagiggy to detect whether prctl(CAP_BSET_DROP)
> returns -ENOSYS and not compile/install/run the tests in that case, that'd
> be great.
>
> And maybe I'll finally implement some of the new securebits testcases I
> spelled out a year or two ago.
Hi Serge,
AC_RUN_IFELSE is what you want :
http://www.gnu.org/software/autoconf/manual/autoconf.html#Runtime --
make sure to write a cross-compile statement with a sensible default
(enabled?).
I'll help you write up a test once you have something to compile :).
Thanks,
-Garrett
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2010-03-18 19:13 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-03-02 10:11 [LTP] LTP's filecaps test gives false positive results Iranna D Ankad
2010-03-02 15:21 ` Serge E. Hallyn
2010-03-02 16:25 ` Garrett Cooper
2010-03-02 17:35 ` Serge E. Hallyn
2010-03-02 18:25 ` Garrett Cooper
2010-03-03 5:56 ` Rishikesh K Rajak
2010-03-03 9:14 ` Garrett Cooper
2010-03-03 9:23 ` Rishikesh K Rajak
2010-03-03 16:00 ` Serge E. Hallyn
2010-03-18 9:25 ` Rishikesh K Rajak
2010-03-18 14:55 ` Serge E. Hallyn
2010-03-18 19:13 ` Garrett Cooper
2010-03-02 16:39 ` Garrett Cooper
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.