> > > <<<test_start>>>
> > > tag=posix_fadvise03_64 stime=2430
> > > cmdline=" posix_fadvise03_64"
> > > contacts=""
> > > analysis=exit
> > > initiation_status="ok"
> > > <<<test_output>>>
> > > posix_fadvise03 1 FAIL : call succeeded unexpectedly
> >
> > I still don't understand why these calls are succeeded.
> > Could you tell me the name of distribution you are using?
> > Or could you give me the output of
> >
> > $ strace POSIX_FADVISE03_64
> >
> > Here POSIX_FADVISE03_64 stands for the complete path to the
> > executable of posix_fadvise03_64 test case file.
>
> Please, forget what I wrote above.
> Now I understand the reason why these calls are succeeded.
> I'm looking for the way to avoid.
Pramod, I think you run the test on the system which mounts
ext2 file system which enables CONFIG_EXT2_FS_XIP.
The posix_fadvise03_64 test case test fadvise64_64 system call
checks the 4th parameter ADVISE whether is valid or not.
Look at code:
linux-2.6.15/mm/fadvise.c:
asmlinkage long sys_fadvise64_64(int fd, loff_t offset, loff_t len, int
advice)
{
struct file *file = fget(fd);
struct address_space *mapping;
struct backing_dev_info *bdi;
loff_t endbyte;
pgoff_t start_index;
pgoff_t end_index;
unsigned long nrpages;
int ret = 0;
if (!file)
return -EBADF;
mapping = file->f_mapping;
if (!mapping || len < 0) {
ret = -EINVAL;
goto out;
}
if (mapping->a_ops->get_xip_page)
/* no bad return value, but ignore advice */
goto out;
...<snip>...
out:
fput(file);
return ret;
}
The reason "call succeeded unexpectedly" is that
mapping->a_ops->get_xip_page is not NULL. Generally this pointer
to the function is NULL. However, if fd points a file on ext2 file
system which enables CONFIG_EXT2_FS_XIP, the pointer is filled
by `ext2_get_xip_page()'. As I explain below, I cannot fix the
problem quickly. Please wait.
LTP and kernel hackers, I'd like to get some advises.
There is no way to know (1) whether mapping->a_ops->get_xip_page
points NULL or not, and (2) whether CONFIG_EXT2_FS_XIP is enabeld
or not both when running the test case and building the test case.
Only the method to know is calling fadvise64_64 with broken advise
value like INT_MAX:
int advice = INT_MAX;
int r;
r = fadvise64_64(fd, loff_t offset, len, advice);
if (r == 0) {
printf("this test runs on CONFIG_EXT2_FS_XIP enabled fs\n");
exit(0);
}
However, the method is the same to the test itself.
I think this is a kind of kernel bug. How do you think?
Following is my proposal to fix the kernel.
If this patch is acceptable to kernel, I don't have to
modify the test case side.
Signed-off-by: Masatake YAMATO <[EMAIL PROTECTED]>
--- fadvise.c.orig 2008-01-08 12:07:43.000000000 +0900
+++ fadvise.c 2008-01-08 12:11:17.000000000 +0900
@@ -43,9 +43,22 @@
goto out;
}
- if (mapping->a_ops->get_xip_page)
- /* no bad return value, but ignore advice */
+ if (mapping->a_ops->get_xip_page) {
+ switch (advice) {
+ case POSIX_FADV_NORMAL:
+ case POSIX_FADV_RANDOM:
+ case POSIX_FADV_SEQUENTIAL:
+ case POSIX_FADV_WILLNEED:
+ case POSIX_FADV_NOREUSE:
+ case POSIX_FADV_DONTNEED:
+ /* no bad return value, but ignore advice */
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
goto out;
+ }
/* Careful about overflows. Len == 0 means "as much as possible" */
endbyte = offset + len;
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
