All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: linux-mips@vger.kernel.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Subject: [RFC] mips ptrace32.c and compat_ptr()
Date: Mon, 1 Apr 2019 01:01:04 +0100	[thread overview]
Message-ID: <20190401000104.GF2217@ZenIV.linux.org.uk> (raw)

	There's something odd going on:

1)
static inline void __user *compat_ptr(compat_uptr_t uptr)
{
        /* cast to a __user pointer via "unsigned long" makes sparse happy */
        return (void __user *)(unsigned long)(long)uptr;
}

Huh?  The first impression is that it wants to sign-extend
the argument, but... compat_uptr_t is and always had been
unsigned.  Initially it went
+typedef u32            compat_uptr_t;
+
+static inline void *compat_ptr(compat_uptr_t uptr)
+{
+       return (void *)(long)uptr;
+}
so there never had been any sign-extension in that thing.
So what is that cast to long in the current version about?

2)
long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
                        compat_ulong_t caddr, compat_ulong_t cdata)
{
        int addr = caddr;
        int data = cdata;
...
                ret = put_user(tmp, (u32 __user *) (unsigned long) data);
                break;
and quite a few similar in the same function.  Here we _do_ get sign
extension.  Which is bloody odd, seeing that all other compat syscalls
end up using compat_ptr(), either explicitly or in the syscall glue.

Shouldn't it be doing
                ret = put_user(tmp, (u32 __user *)compat_ptr(cdata));
                break;
instead?

             reply	other threads:[~2019-04-01  0:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-01  0:01 Al Viro [this message]
2019-04-03 21:59 ` [RFC] mips ptrace32.c and compat_ptr() Paul Burton

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=20190401000104.GF2217@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-mips@vger.kernel.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 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.