From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] readdir mess
Date: Tue, 12 Aug 2008 21:59:43 +0100 [thread overview]
Message-ID: <20080812205943.GX28946@ZenIV.linux.org.uk> (raw)
In-Reply-To: <alpine.LFD.1.10.0808121303510.3462@nehalem.linux-foundation.org>
On Tue, Aug 12, 2008 at 01:05:43PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 13 Aug 2008, OGAWA Hirofumi wrote:
> >
> > However, there are some similar stuff: ->st_size, ->st_nlink and
> > ->st_ino in stat() (cp_old_stat()). Maybe EOVERFLOW is the reason for
> > consistency...
>
> .. I actually had an old binary that triggered that case (actually, it was
> O_LARGEFILE in open()), and didn't work as a result. I only needed to run
> it once, so I literally hacked up a once-time-use kernel that just removed
> the EOVERFLOW in open.
>
> So no, I'm not a fan of EOVERFLOW at all. Not in readdir(), not really
> anywhere else.
Um... Here it would happen only on attempt to return an entry for file
that really has an inumber not fitting into the field; what would you
do in such case? open() on a huge file is a different story, since you
would get a valid opened file and that'd be it; the logics in case of
open() is, IIRC, "I guess your binary is old, so it'll probably do other
things that would really have to trigger -EOVERFLOW; better bail out right
now". In this case, though, you either generate an error or get wrong
values silently stored in userland struct (wrapped around inumber).
next prev parent reply other threads:[~2008-08-12 20:59 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-12 6:22 [RFC] readdir mess Al Viro
2008-08-12 17:02 ` OGAWA Hirofumi
2008-08-12 17:18 ` Linus Torvalds
2008-08-12 18:10 ` Al Viro
2008-08-12 18:22 ` Al Viro
2008-08-12 18:37 ` Al Viro
2008-08-12 19:24 ` Al Viro
2008-08-12 20:02 ` Linus Torvalds
2008-08-12 20:21 ` Linus Torvalds
2008-08-12 20:38 ` Al Viro
2008-08-12 21:04 ` Linus Torvalds
2008-08-13 0:04 ` Al Viro
2008-08-13 0:28 ` Linus Torvalds
2008-08-13 1:19 ` Al Viro
2008-08-13 1:51 ` Linus Torvalds
2008-08-13 8:36 ` Brad Boyer
2008-08-13 16:19 ` Al Viro
2008-08-15 5:06 ` Jan Harkes
2008-08-15 5:34 ` Al Viro
2008-08-15 16:58 ` Linus Torvalds
2008-08-24 10:10 ` Al Viro
2008-08-24 11:03 ` Al Viro
2008-08-25 16:16 ` J. Bruce Fields
2008-08-24 17:20 ` Linus Torvalds
2008-08-24 19:59 ` Al Viro
2008-08-24 23:51 ` Linus Torvalds
2008-08-25 1:33 ` Al Viro
2008-08-25 1:44 ` Al Viro
2008-08-12 19:45 ` OGAWA Hirofumi
2008-08-12 20:05 ` Linus Torvalds
2008-08-12 20:59 ` Al Viro [this message]
2008-08-12 21:24 ` Linus Torvalds
2008-08-12 21:54 ` Al Viro
2008-08-12 22:04 ` Linus Torvalds
2008-08-13 16:20 ` J. Bruce Fields
2008-08-12 21:47 ` Alan Cox
2008-08-12 22:20 ` Linus Torvalds
2008-08-12 22:10 ` Alan Cox
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=20080812205943.GX28946@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=hirofumi@mail.parknet.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).