The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] make last_inode counter in new_inode 32-bit on kernels that offer x86 compatability
Date: Mon, 06 Nov 2006 13:12:05 -0500	[thread overview]
Message-ID: <1162836725.6952.28.camel@dantu.rdu.redhat.com> (raw)

Some (generally not disk-based) filesystems use the new_inode() function
to allocate and populate inode structs. This function uses a static
unsigned long counter to populate i_ino. On most 64-bit platforms, this
is a 64-bit integer, but on ia32, this is a 32-bit int.

If stat() is called from a 32-bit program that was not compiled with
-D_FILE_OFFSET_BITS=64 on one of these inodes, then glibc will generate
an EOVERFLOW error in userspace (since the st_ino returned by the stat64
call won't fit in the old-style stat struct).

This creates a situation where these programs will run just fine on a
32-bit kernel, but will eventually start falling down with EOVERFLOW
errors on a 64-bit kernel. One way to reproduce this is to write a
program that repeatedly calls pipe() and then does an fstat() on one of
the pipe filehandles, and compile the program as a 32-bit app w/o
-D_FILE_OFFSET_BITS=64. Eventually, the fstat will consistently fail
with an EOVERFLOW.

The attached patch remedies this by making the last_inode counter be an
unsigned int on kernels that have ia32 compatability mode enabled.

My rationale is that we're eventually going to overflow this counter
regardless. This does make it happen sooner, but this is no worse that
what already happens on ia32.

Signed-off-by: Jeff Layton <jlayton@redhat.com>

--- linux-2.6/fs/inode.c.lastino
+++ linux-2.6/fs/inode.c
@@ -524,7 +524,11 @@ repeat:
  */
 struct inode *new_inode(struct super_block *sb)
 {
+#if (defined CONFIG_IA32_EMULATION || defined CONFIG_IA32_SUPPORT)
+	static unsigned int last_ino;
+#else
 	static unsigned long last_ino;
+#endif
 	struct inode * inode;
 
 	spin_lock_prefetch(&inode_lock);



             reply	other threads:[~2006-11-06 18:12 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-06 18:12 Jeff Layton [this message]
2006-11-06 18:22 ` [PATCH] make last_inode counter in new_inode 32-bit on kernels that offer x86 compatability Matthew Wilcox
2006-11-06 18:31   ` Jeff Layton
2006-11-06 18:47   ` Jeff Layton
2006-11-06 20:23     ` Jörn Engel
2006-11-06 20:31       ` Eric Dumazet
2006-11-06 20:56         ` Jeff Layton
2006-11-06 20:50       ` Eric Sandeen
2006-11-06 21:11         ` Jörn Engel
2006-11-06 21:36           ` Eric Sandeen
2006-11-06 22:01             ` Andreas Dilger
2006-11-07 15:56             ` Jeff Layton
2006-11-07 16:07               ` Jeff Layton
2006-11-07 16:10               ` Matthew Wilcox
2006-11-07 17:04               ` Jörn Engel
2006-11-07 17:28               ` Jörn Engel
2006-11-07 17:42                 ` Jörn Engel
2006-11-07 17:53                   ` Dave Kleikamp
2006-11-07 18:07                     ` Jörn Engel
2006-11-07 17:56                   ` Jörn Engel
2006-11-07 18:01                     ` Jörn Engel
2006-11-07 18:10                       ` Eric Sandeen
2006-11-07 19:41                     ` Jeff Layton
2006-11-07 20:41                       ` Jörn Engel
2006-11-07 21:13                         ` Jeff Layton
2006-11-07 21:20                           ` Matthew Wilcox
2006-11-07 22:09                             ` Jeff Layton
2006-11-07 18:01                 ` Jeff Layton
2006-11-07 18:14                   ` Jörn Engel
2006-11-07 18:23                     ` Jeff Layton

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=1162836725.6952.28.camel@dantu.rdu.redhat.com \
    --to=jlayton@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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