mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: torvalds@osdl.org, akpm@osdl.org
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org#,
	dhowells@redhat.com
Subject: [PATCH 0/4] Use 64-bit inode numbers internally in the kernel
Date: Mon, 14 Aug 2006 22:15:04 +0100	[thread overview]
Message-ID: <20060814211504.27190.10491.stgit@warthog.cambridge.redhat.com> (raw)


These patches make the kernel use 64-bit inode numbers internally, even on a
32-bit system.  They are required because some filesystems have intrinsic
64-bit inode numbers: NFS and XFS for example.  The 64-bit inode numbers are
then propagated to userspace automatically where the arch supports it.

Problems have been seen with userspace (eg: ld.so) using the 64-bit inode
number returned by stat64() or getdents64() to differentiate files, and failing
because the 64-bit inode number space was compressed to 32-bits, and so
overlaps occur.


There are four patches:

 (1) Supply __udivdi3() and __umoddi3() so that the compiler can do 64-bit
     division and modulus.  __udivmoddi4() is also supplied as the other two
     are wrappers around that.

 (2) Make __kernel_ino_t consistently typedef'd to "unsigned long long" on all
     archs.

     Where ino_t has been used in userspace facing structures (such as struct
     stat), it has been replaced with whatever ino_t used to be defined as on
     that arch.

     struct inode::i_ino and struct kstat::ino are changed to ino_t type.

 (3) Fix print format warnings in general code due to the change in type of
     i_ino.  These should now all carry an "ll" modifier.

 (4) As for (3), but fix the CacheFiles code.

David

             reply	other threads:[~2006-08-14 21:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-14 21:15 David Howells [this message]
2006-08-14 21:15 ` [RHEL5 PATCH 1/4] Provide fallback full 64-bit divide/modulus ops for gcc David Howells
2006-08-15  6:44   ` Jan Engelhardt
2006-08-15  8:10   ` Andi Kleen
2006-08-15  8:29   ` David Howells
2006-08-18  8:39     ` Pavel Machek
2006-08-18 10:33     ` David Howells
2006-08-14 21:15 ` [RHEL5 PATCH 2/4] VFS: Make inode numbers 64-bits David Howells
2006-08-15  1:31   ` Al Viro
2006-08-15  6:48   ` Jan Engelhardt
2006-08-15  8:21   ` David Howells
2006-08-15  9:06     ` Al Viro
2006-08-15  8:32   ` David Howells
2006-08-15  9:02     ` Al Viro
2006-08-15  9:25     ` David Howells
2006-08-15 12:45       ` Stephen Rothwell
2006-08-14 21:15 ` [RHEL5 PATCH 3/4] VFS: Clear up u-long-long ino_t print format warnings David Howells
2006-08-14 21:15 ` [RHEL5 PATCH 4/4] VFS: Fix 64-bit ino_t warning in CacheFiles facility David Howells
2006-08-15  0:36 ` [PATCH 0/4] Use 64-bit inode numbers internally in the kernel Josh Boyer
2006-08-15  8:21 ` David Howells
2006-08-15  9:13   ` Al Viro

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=20060814211504.27190.10491.stgit@warthog.cambridge.redhat.com \
    --to=dhowells@redhat.com \
    --cc=akpm@osdl.org \
    --cc=linux-fsdevel@vger.kernel.org# \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /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

Powered by JetHome