From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andi Kleen <ak@muc.de>
Subject: Re: negative seek offsets in VFS
Date: 25 May 2005 20:48:48 +0200
Message-ID: <20050525184848.GS86087@muc.de>
References: <20050525163905.GP86087@muc.de> <1117040204.12336.32.camel@lade.trondhjem.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: viro@www.linux.org.uk, linux-fsdevel@vger.kernel.org
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from colin.muc.de ([193.149.48.1]:48900 "EHLO mail.muc.de")
	by vger.kernel.org with ESMTP id S261536AbVEYSs5 (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Wed, 25 May 2005 14:48:57 -0400
Date: Wed, 25 May 2005 20:48:48 +0200
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Content-Disposition: inline
In-Reply-To: <1117040204.12336.32.camel@lade.trondhjem.org>
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Wed, May 25, 2005 at 12:56:44PM -0400, Trond Myklebust wrote:
> 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.

Yes, but that is not enough. read/write have these checks too,
even pread/pwrite.

-Andi