All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Phillip Susi <psusi@ubuntu.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH] e2fslibs: fix llseek on i386
Date: Thu, 24 Jan 2013 14:51:58 -0500	[thread overview]
Message-ID: <20130124195158.GC9477@thunk.org> (raw)
In-Reply-To: <1359044517-18243-1-git-send-email-psusi@ubuntu.com>

On Thu, Jan 24, 2013 at 11:21:56AM -0500, Phillip Susi wrote:
> ext2fs_llseek() was using lseek instead of lseek64.  The
> only time it would use lseek64 is if passed an offset that
> overflowed 32 bits.  This works for SEEK_SET, but not
> SEEK_CUR, which can apply a small offset to move the file
> pointer past the 32 bit limit.
> 
> The code has been changed to instead try lseek64 first, and
> fall back to lseek if that fails.  It also was doing a
> runtime check of the size of off_t.  This has been moved to
> compile time.
> 
> Signed-off-by: Phillip Susi <psusi@ubuntu.com>

How did you find this?  I've done a quick search for SEEK_CUR, and it
looks like only place where this could cause a problem is with
e2image.  And a quick test of a i386 version of e2image with a large
file system is that it does indeed blow up with an "Inappropriate
ioctl for device" error.

Is there any other potential problems that are caused by this bug?  I
like to explain the impacts of bug fixes in libext2fs for folks who
are doing bug fix / code archeology.

Thanks,


					- Ted

  reply	other threads:[~2013-01-24 19:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-24 16:21 [PATCH] e2fslibs: fix llseek on i386 Phillip Susi
2013-01-24 19:51 ` Theodore Ts'o [this message]
2013-01-24 20:22   ` Phillip Susi
2013-01-24 20:32     ` Theodore Ts'o
2013-01-25  2:25       ` Zheng Liu
2013-01-25  2:16         ` Theodore Ts'o
2013-01-25  2:48           ` Zheng Liu
2013-01-25  4:13 ` Theodore Ts'o
2013-01-25  4:14   ` [PATCH] libext2fs: fix ext2fs_llseek " Theodore Ts'o
2013-01-25  4:34     ` Phillip Susi

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=20130124195158.GC9477@thunk.org \
    --to=tytso@mit.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=psusi@ubuntu.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.