I believe that this is exactly what is happening, and I believe that
the culprit in this situation is the Linux (2.0.36pre6) kernel. The
problematic bit happens in fs/read_write.c:sys_lseek(), around line
45 in 2.0.36pre6. The code reads (extracted):
switch (origin) {
[...]
case 1:
tmp = file->f_pos + offset;
break;
[...]
}
if (tmp < 0)
return -EINVAL;
I believe that file->f_pos is the magic cookie from NFS's readdir
operation, which may have the high bit set. If it does, this code (when
the offset is 0) computes, obviously, a 'tmp' value that is negative
(although perfectly valid, being the current value of file->f_pos),
which fails the test and causes lseek() to return an EINVAL error.
Unfortunately, I don't see a good fix for the problem. Even if the
kernel didn't trip up over that test, it would be returning a negative
value from the system call. For better or worse, the system call setup
of Linux appears to treat negative returns from most system calls as
errors, with the errno encoded as the (negative) number. (Cf, say,
the _syscallN() macros in asm/unistd.h.)
---
"there used to be two moons
then one of them
discovered coffee." - Curtis Yarvin
cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html