Re: [LTP] [PATCH]Modify the cacheflush01 test case

[Gao, F. <Fen...@wi...>]

Hi,

I have tested cacheflush01 testcase in Linux 2.6.27.45 kernel, if the cache of sys_cacheflush is 0, return value also is Success. It is same with the Linux 2.6.34.1.

I have check the kernel code, from the Linux 2.6.11, sys_cacheflush function began to ignore the cache argument and never return EINVAL.
The function of cacheflush01 is checking if the sys_cacheflush's return value is correct. if there is no EINVAL as the return value in the kernel code, it is unnecessary to checking it. Otherwise the case will fail, tester will waste time to recheck this case and sys_cacheflush function.

BR,
Feng Gao

-----Original Message-----
From: Garrett Cooper [mailto:yan...@gm...]
Sent: 2010-8-31  23:46
To: Gao, Feng
Cc: ltp-list
Subject: Re: [LTP] [PATCH]Modify the cacheflush01 test case
 
2010/8/31 Gao, Feng <Fen...@wi...>:
> Hi,
>
> The cacheflush system call does not return EINVAL in the latest Linux
> kernel. see the link:
> A related patch about the cacheflush function:
> http://lkml.org/lkml/2009/4/9/203
> But Ralf had refused this patch:
> http://www.spinics.net/lists/linux-man/msg00906.html
> cacheflush01 testcase checks if the return value is EINVAL when the cache
> argument is not one of ICACHE, BCACHE or DCACHE. So it will fail in all
> boards.
>
> In this modification, checking return value SUCCESS will be added, instead
> of checking EINVAL

I got the first email :).

I am always hesitant committing patches like these because unless
there is documentation that clearly states "these are the requirements
for syscall/libcall foo", it can change at a later day without notice
and we'll work ourselves into this funk again.

Also, what happens when you execute this code on earlier kernels? I
hate getting emails from other users stating "the commit you did for
the test is broke my architecture foo on distro bar -- here's a patch
to fix it!".

The syscall needs to be fixed. If the cache argument is ignored, it
needs to be removed. Period. And the syscall needs to be renamed to
something else to avoid breaking backwards compatibility (which is
essentially what happened here).

FWIW we lack positive tests for this syscall, and we really should
have some (other than just nuking the entire contents of the syscall
directory).

Thanks,
-Garrett