From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
dann frazier <dannf@dannf.org>,
linux-mips@linux-mips.org
Subject: Re: [PATCH 1/2] fs: Fix sign extension problem in sys_llseek
Date: Wed, 25 Mar 2009 12:33:44 +0100 [thread overview]
Message-ID: <20090325123344.409090a3@osiris.boeblingen.de.ibm.com> (raw)
In-Reply-To: <20090325001303.GB24026@linux-mips.org>
On Wed, 25 Mar 2009 01:13:03 +0100
Ralf Baechle <ralf@linux-mips.org> wrote:
> In fs/read_write.c:
>
> SYSCALL_DEFINE5(llseek, unsigned int, fd, unsigned long, offset_high,
> unsigned long, offset_low, loff_t __user *, result,
> unsigned int, origin)
> ...
> offset = vfs_llseek(file, ((loff_t) offset_high << 32) | offset_low,
> origin);
>
> On a 64-bit system that define CONFIG_HAVE_SYSCALL_WRAPPERS SYSCALL_DEFINEx
> will truncate long arguments to 32-bit and on some architectures such as
> MIPS sign-extended to 64-bit again. On such architectures passing a
> value with bit 31 in offset_low set will result in a huge 64-bit offset
> being passed to vfs_llseek() and it failiing with EINVAL.
How is that possible? If you have CONFIG_HAVE_SYSCALL_WRAPPERS defined
then the wrapper will (in this case) cast offset_low from long to
unsigned long. It won't truncate or sign extend anything here.
The whole operation should be a NOP.
This is what you get after macro expansion (BUILD_BUG_ON removed):
long sys_llseek(unsigned int fd, unsigned long offset_high, unsigned long offset_low, loff_t * result, unsigned int origin);
static inline __attribute__((always_inline))
long SYSC_llseek(unsigned int fd, unsigned long offset_high, unsigned long offset_low, loff_t * result, unsigned int origin);
long SyS_llseek(long fd, long offset_high, long offset_low, long result, long origin)
{
return (long) SYSC_llseek((unsigned int) fd, (unsigned long) offset_high, (unsigned long) offset_low, (loff_t *) result, (unsigned int) origin);
}
asm ("\t.globl " "sys_llseek" "\n\t.set " "sys_llseek" ", " "SyS_llseek");
static inline __attribute__((always_inline))
long SYSC_llseek(unsigned int fd, unsigned long offset_high, unsigned long offset_low, loff_t * result, unsigned int origin)
{
[...]
}
prev parent reply other threads:[~2009-03-25 11:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-25 0:13 Ralf Baechle
2009-03-25 11:33 ` Heiko Carstens [this message]
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=20090325123344.409090a3@osiris.boeblingen.de.ibm.com \
--to=heiko.carstens@de.ibm.com \
--cc=dannf@dannf.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.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
all inboxes | Powered by JetHome®