From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: negative seek offsets in VFS Date: Wed, 25 May 2005 12:56:44 -0400 Message-ID: <1117040204.12336.32.camel@lade.trondhjem.org> References: <20050525163905.GP86087@muc.de> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: viro@www.linux.org.uk, linux-fsdevel@vger.kernel.org Return-path: Received: from pat.uio.no ([129.240.130.16]:38345 "EHLO pat.uio.no") by vger.kernel.org with ESMTP id S261478AbVEYQ5D (ORCPT ); Wed, 25 May 2005 12:57:03 -0400 To: Andi Kleen In-Reply-To: <20050525163905.GP86087@muc.de> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org on den 25.05.2005 Klokka 18:39 (+0200) skreiv Andi Kleen: > 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. For seek I could > fix it in drivers/char/mem.c, but for read/pread/write etc. > it needs VFS changes. > > 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? Isn't /dev/kmem overriding the default llseek()? AFAICS, drivers/char/mem.c defines "memory_lseek()" for precisely the above reason. Cheers, Trond