From: Andrew Morton <akpm@linux-foundation.org>
To: joakim.tjernlund@transmode.se
Cc: adobriyan@parallels.com, akpm@linuxfoundation.org,
viro@ftp.linux.org.uk, linux-kernel@vger.kernel.org,
busybox@busybox.net
Subject: Re: [PATCH] seq_file: make seq_lseek accept SEEK_END
Date: Wed, 11 Jun 2008 14:29:09 -0700 [thread overview]
Message-ID: <20080611142909.2e18f2b1.akpm@linux-foundation.org> (raw)
In-Reply-To: <1213012375.16530.9.camel@gentoo-jocke.transmode.se>
On Mon, 09 Jun 2008 13:52:55 +0200
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> busybox has been fixed, at least in trunk, not to do
> xlseek(fd, 0, SEEK_END) anymore to address this problem.
> Perhaps there are other apps out there that needs this too, but I don't
> know of any. Older busyboxes needs this change though.
> I have moved on and don't have a setup handy where I can test this.
> Perhaps someone at the bb list has, CC:ing bb list.
>
Nevertheless it'd be nice to fix old versions.
To some extent that depends on when we broke it. See below.
>
> On Mon, 2008-06-09 at 15:01 +0400, Alexey Dobriyan wrote:
> > Apologies for delay, such simple thing should have been sent long ago.
> > Joakim, please, confirm.
> > -------------------------------------------
> > [PATCH] seq_file: make seq_lseek accept SEEK_END
> >
> > and pretend seq_files have zero length. This should be enough
> > to fix busybox start-stop-daemon:
> > http://marc.info/?t=120836691600002&r=1&w=2
> >
> > It does xlseek(fd, 0, SEEK_END) to estimate amount of memory to malloc
> > but satisfied with 0. Sudden -EINVAL from lseek(2) breaks it.
> >
> > X-Introduced-By: f16278c679aa72e28288435b313ba2d4494d6be5
> > Signed-off-by: Alexey Dobriyan <adobriyan@parallels.com>
> > ---
> >
> > fs/seq_file.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > --- a/fs/seq_file.c
> > +++ b/fs/seq_file.c
> > @@ -254,6 +254,8 @@ loff_t seq_lseek(struct file *file, loff_t offset, int origin)
> > switch (origin) {
> > case 1:
> > offset += file->f_pos;
> > + case 2:
> > + /* pretend it's zero length */
> > case 0:
> > if (offset < 0)
> > break;
> >
> >
Is returning zero logical, given what we do with SEEK_SET?
afait we _could_ just do
offset = <largenum>
/* fall through */
and let the SEEK_SET code do its thing. But I might have misread it.
But still, it looks like it'd be possible to return a true(ish) value
from SEEK_END?
> > X-Introduced-By: f16278c679aa72e28288435b313ba2d4494d6be5
Please don't do that. Instead, quote the commit ID _and_ the first few
lines of the commit itself, like:
commit f16278c679aa72e28288435b313ba2d4494d6be5
Author: Hans Rosenfeld <hans.rosenfeld@amd.com>
Date: Fri Mar 21 18:46:59 2008 -0500
Change pagemap output format to allow for future reporting of huge pages
And here we see one reason: that commit cannot be the one which
introduced this problem.
next prev parent reply other threads:[~2008-06-11 21:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-09 11:01 [PATCH] seq_file: make seq_lseek accept SEEK_END Alexey Dobriyan
2008-06-09 11:52 ` Joakim Tjernlund
2008-06-11 21:29 ` Andrew Morton [this message]
2008-06-15 22:58 ` Alexey Dobriyan
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=20080611142909.2e18f2b1.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=adobriyan@parallels.com \
--cc=akpm@linuxfoundation.org \
--cc=busybox@busybox.net \
--cc=joakim.tjernlund@transmode.se \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ftp.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