Re: negative seek offsets in VFS

["Paul Taysom" <Paul.Taysom@novell.com>]

The addresses returned from /proc/kallsyms on the x86_64 are negative and when
I print the address of a kernel variable with "%p" it comes out negative.

Paul Taysom

>>> Bryan Henderson <hbryan@us.ibm.com> 5/25/2005 6:56:26 PM >>>
>My x86-64 users are complaining again that they cannot reach kernel
>text addresses in /dev/kmem. The reason is that they are negative and
>the the VFS read and seek code just EINVALs them.

Come now -- the kernel addresses are not negative, and neither is any file 
offset.

You apparently mean that when you coerce a kernel address which exceeds 
the range of a file offset type into a file offset type, it comes out 
negative.

>I dont quite get why they are there anyways, the super block has 
>max file size field and checking against that should be enough for
>all the filesystems, no?

But this isn't about exceeding a maximum file size -- it's about exceeding 
the range of offsets that is representable in this C data type.

So I guess the real question is why is the loff_t type signed, thereby 
making it incapable of representing sufficiently large offsets?  The 
answer is that there are POSIX interfaces that overload a single data 
structure as both a file offset or size and a status code.  If a loff_t 
value is positive, it is a file offset, but if it's negative, it's a 
status code.  Consider lseek -- if you allowed a negative offset and just 
declared that it stands for the large positive offset you'd get if you 
coerced it to an unsigned 64 bit integer, then how would you tell a 
success from a failure in the return code?

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org 
More majordomo info at  http://vger.kernel.org/majordomo-info.html