From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: negative seek offsets in VFS Date: 26 May 2005 21:20:58 +0200 Message-ID: <20050526192058.GV86087@muc.de> References: <20050525163905.GP86087@muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, viro@www.linux.org.uk Return-path: Received: from colin.muc.de ([193.149.48.1]:3589 "EHLO mail.muc.de") by vger.kernel.org with ESMTP id S261699AbVEZTVL (ORCPT ); Thu, 26 May 2005 15:21:11 -0400 Date: Thu, 26 May 2005 21:20:58 +0200 To: Bryan Henderson Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, May 25, 2005 at 05:56:26PM -0700, Bryan Henderson wrote: > >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. x86-64 addresses are negative. > > 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. No I meant what I wrote. > 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? The same as any other Linux kernel interfaces do it. The range from -4096 to -1 is reserved for error codes, the rest is free to use. This is what glibc uses too. It has nothing to do with POSIX. -Andi