From: Chris Mason <chris.mason@oracle.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Andrew Morton <akpm@linux-foundation.org>,
handygewinnspiel@gmx.de, rjw@sisk.pl, HWerner4@gmx.de,
viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, mchehab@infradead.org
Subject: Re: [linux-dvb] compiling on 2.6.28 broken?
Date: Wed, 14 Jan 2009 13:29:10 -0500 [thread overview]
Message-ID: <1231957750.8269.28.camel@think.oraclecorp.com> (raw)
In-Reply-To: <20090113203843.GJ29283@parisc-linux.org>
On Tue, 2009-01-13 at 13:38 -0700, Matthew Wilcox wrote:
> On Tue, Jan 13, 2009 at 11:37:00AM -0800, Andrew Morton wrote:
> > I'd have expected to see stat() returning -EOVERFLOW, but it isn't there.
> >
> > googling around a bit seems to indcate that this might be a glibc issue:
> >
> > http://sourceware.org/bugzilla/show_bug.cgi?id=1864
> > http://bugs.gentoo.org/show_bug.cgi?id=146951
> >
> > But the traces are all using stat64() and fstat64(). And why would it
> > just start occurring now?
>
> Maybe glibc is using the 64-bit stat calls and returning -EOVERFLOW to
> the application when the results from the kernel turn out to be > 32-bit
> in size?
>
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6c31b93a14a453c8756ffd228e24910ffdf30c5d
I'd guess the commit above is related, although I don't see any way for
it to make things interesting without the user doing mount -o inode64.
strace -v should show us more, it would show if the inode numbers coming
out of stat64 are big.
-chris
next prev parent reply other threads:[~2009-01-14 18:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090112190420.51f75853@pedra.chehab.org>
[not found] ` <20090112132130.6c932b85.akpm@linux-foundation.org>
[not found] ` <20090112220624.4fbfee34@pedra.chehab.org>
[not found] ` <20090112162337.318dd61d.akpm@linux-foundation.org>
2009-01-13 18:47 ` [linux-dvb] compiling on 2.6.28 broken? handygewinnspiel
2009-01-13 18:59 ` Andrew Morton
2009-01-13 19:17 ` handygewinnspiel
2009-01-13 19:37 ` Andrew Morton
2009-01-13 20:02 ` handygewinnspiel
2009-01-13 20:38 ` Matthew Wilcox
2009-01-14 18:29 ` Chris Mason [this message]
2009-01-14 21:19 ` wk
2009-01-14 21:24 ` Chris Mason
2009-01-14 21:35 ` Eric Sandeen
2009-01-14 21:40 ` Chris Mason
2009-01-14 23:00 ` Kay Sievers
2009-01-15 1:54 ` Chris Mason
2009-01-14 21:41 ` Eric Sandeen
2009-01-14 21:44 ` Andrew Morton
2009-01-14 21:48 ` Eric Sandeen
2009-01-14 22:57 ` Lachlan McIlroy
2009-01-18 22:06 ` Christoph Hellwig
2009-01-14 21:41 ` wk
2009-01-14 22:30 ` Dave Chinner
2009-01-15 19:41 ` wk
2009-01-15 22:23 ` Dave Chinner
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=1231957750.8269.28.camel@think.oraclecorp.com \
--to=chris.mason@oracle.com \
--cc=HWerner4@gmx.de \
--cc=akpm@linux-foundation.org \
--cc=handygewinnspiel@gmx.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=mchehab@infradead.org \
--cc=rjw@sisk.pl \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).