public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Bernd Schubert <bernd-schubert@web.de>,
	Andreas Schwab <schwab@suse.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: x86_64: 32bit emulation problems
Date: 3 Mar 2005 10:19:08 +0100
Date: Thu, 3 Mar 2005 10:19:08 +0100	[thread overview]
Message-ID: <20050303091908.GC5215@muc.de> (raw)
In-Reply-To: <1109782387.9667.11.camel@lade.trondhjem.org>

On Wed, Mar 02, 2005 at 08:53:07AM -0800, Trond Myklebust wrote:
> on den 02.03.2005 Klokka 12:33 (+0100) skreiv Bernd Schubert:
> 
> > > I can see no good reason for truncating inode number values on platforms
> > > that actually do support 64-bit inode numbers, but I can see several
> > 
> > Well, at least we would have a reason ;)
> 
> A 32-bit emulation mode is clearly a "platform" which does NOT support
> 64-bit inode numbers, however there is (currently) no way for the kernel
> to detect that you are running that. Any extra truncation should
> therefore ideally be done by the emulation layer rather than the kernel
> itself.

The problem here is that glibc uses stat64() which supports
64bit inode numbers. But glibc does the overflow checking itself
and generates the EOVERFLOW in user space. Nothing we can do
about that. The 64bit inodes work under 32bit too, so your
code checking for 64bitness is totally bogus.

The old stat interface doesn't check that case currently either
(will fix that), but that's not the problem here.

But in general the emulation layer cannot do truncation because
it doesn't know if it is ok to do for the low level file system.
If anything this has to be done in the fs.

-Andi

  parent reply	other threads:[~2005-03-03  9:23 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-28 20:54 x86_64: 32bit emulation problems Bernd Schubert
2005-02-28 21:00 ` Bernd Schubert
2005-03-01 20:24 ` Andi Kleen
2005-03-01 21:07   ` Bernd Schubert
2005-03-01 21:48     ` Andi Kleen
2005-03-01 22:30       ` Bernd Schubert
2005-03-01 23:07         ` Andi Kleen
2005-03-01 22:10     ` Andreas Schwab
2005-03-01 22:19       ` Andi Kleen
2005-03-01 23:22         ` Andreas Schwab
2005-03-01 23:19       ` Bernd Schubert
2005-03-01 23:39         ` Andreas Schwab
2005-03-01 23:46         ` Andreas Schwab
2005-03-02  8:18           ` Andi Kleen
2005-03-02  9:13             ` Trond Myklebust
2005-03-02 11:33               ` Bernd Schubert
2005-03-02 16:53                 ` Trond Myklebust
2005-03-02 18:14                   ` Bernd Schubert
2005-03-03  9:19                   ` Andi Kleen [this message]
2005-03-03 21:16                     ` Bernd Schubert
2005-03-03 21:32                       ` Andi Kleen
2005-03-03 21:37                     ` Trond Myklebust
2005-03-03 21:46                       ` Andi Kleen
2005-03-03 22:21                         ` Trond Myklebust
2005-03-03  9:12               ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050303091908.GC5215@muc.de \
    --to=ak@muc.de \
    --cc=bernd-schubert@web.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwab@suse.de \
    --cc=trond.myklebust@fys.uio.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox