From: Ralf Baechle <ralf@linux-mips.org>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-api@vger.kernel.org
Subject: Re: [PATCH v3 0/3] preadv & pwritev syscalls.
Date: Tue, 16 Dec 2008 16:05:02 +0000 [thread overview]
Message-ID: <20081216160502.GA15331@linux-mips.org> (raw)
In-Reply-To: <4946C4B4.1020605@redhat.com>
On Mon, Dec 15, 2008 at 09:57:24PM +0100, Gerd Hoffmann wrote:
> > It fixes the alignment issue but still won't work; on MIPS 32-bit userspace
> > will pass the 64-bit argument in two registers but the 64-bit kernel code
> > will assume it to be passed in a single registers. It'd be ugly but passing
> > a pointer to a 64-bit argument would solve the issue; something like this:
> >
> > sys_preadv(unsigned long fd, const struct iovec __user *vec,
> > unsigned long vlen, loff_t __user *pos);
> > compat_sys_preadv(unsigned long fd, const struct compat_iovec __user *vec,
> > unsigned long vlen, loff_t __user *pos);
>
> Suggestion from the s390 front was to explicitly pass high and low part
> of pos as two arguments. A bit ugly too, but should work fine as well
> and it avoids the user pointer dereference. What do you think about this?
That's what the wrapper which you deleted, was doing ;-) So yes, I like
it. It just raises one new problem, endianess - are arguments being passed
as low/high or high/low? On MIPS we've been solving the issue with the
merge_64() macro which is defined depending on the byte order:
#ifdef __MIPSEB__
#define merge_64(r1, r2) ((((r1) & 0xffffffffUL) << 32) + ((r2) & 0xffffffffUL))
#endif
#ifdef __MIPSEL__
#define merge_64(r1, r2) ((((r2) & 0xffffffffUL) << 32) + ((r1) & 0xffffffffUL))
#endif
The actual syscall wrapper could use it like:
asmlinkage int compat_sys_pwritev(unsigned long fd,
const struct compat_iovec __user *vec,
unsigned a3, unsigned a4, unsigned long vlen)
{
loff_t offset = merge_64(a3, a4);
...
If merge_64() was a standard macro in <asm/compat.h> on all architectures,
compat_sys_pwrite() could invoke it directly and the need for the compat
wrapper around the compat wrapper would go away.
> > I'm surprised this works for x86; does x86-64 code really expect 64-bit
> > arguments as 2 32-bit arguments?
>
> Args are passed on the stack, not in registers.
Same as 32-bit MIPS for argument #4 and up which will be passed on the
stack - but the requirement for passing a long long is for it to be
passed as an aligned pair of arguments and the original patch got
that wrong.
Ralf
next prev parent reply other threads:[~2008-12-16 16:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-15 11:36 [PATCH v3 0/3] preadv & pwritev syscalls Gerd Hoffmann
2008-12-15 11:36 ` Gerd Hoffmann
2008-12-15 11:36 ` [PATCH v3 1/3] Add missing accounting calls to compat_sys_{readv,writev} Gerd Hoffmann
2008-12-15 11:36 ` [PATCH v3 2/3] Add preadv and pwritev system calls Gerd Hoffmann
[not found] ` <1229340977-24345-1-git-send-email-kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-12-15 11:36 ` [PATCH v3 3/3] MIPS: Add preadv(2) and pwritev(2) syscalls Gerd Hoffmann
2008-12-15 11:36 ` Gerd Hoffmann
2008-12-15 16:03 ` [PATCH v3 0/3] preadv & pwritev syscalls Ralf Baechle
2008-12-15 16:03 ` Ralf Baechle
2008-12-15 20:02 ` David Miller
2008-12-15 20:57 ` Gerd Hoffmann
2008-12-16 16:05 ` Ralf Baechle [this message]
2008-12-16 16:25 ` Kyle McMartin
[not found] ` <20081216160502.GA15331-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>
2008-12-16 16:48 ` Gerd Hoffmann
2008-12-16 16:48 ` Gerd Hoffmann
2008-12-16 17:02 ` Kyle McMartin
2008-12-16 21:03 ` Arnd Bergmann
[not found] ` <20081216170209.GC410-PfSpb0PWhxZc2C7mugBRk2EX/6BAtgUQ@public.gmane.org>
2008-12-16 21:34 ` Gerd Hoffmann
2008-12-16 21:34 ` Gerd Hoffmann
[not found] ` <49481EF9.3090304-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-12-16 22:39 ` Heiko Carstens
2008-12-16 22:39 ` Heiko Carstens
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=20081216160502.GA15331@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=kraxel@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 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.