From: Oleg Nesterov <oleg@redhat.com>
To: Chris Metcalf <cmetcalf@tilera.com>
Cc: linux-kernel@vger.kernel.org, Roland McGrath <roland@redhat.com>
Subject: Re: [PATCH] arch/tile: provide PT_FLAGS_COMPAT value in pt_regs
Date: Thu, 13 Dec 2012 00:43:07 +0100 [thread overview]
Message-ID: <20121212234307.GA7694@redhat.com> (raw)
In-Reply-To: <201212122227.qBCMRiNg000851@farm-0002.internal.tilera.com>
Hi Chris,
it is too late for me to even try to read this patch, but...
On 12/12, Chris Metcalf wrote:
>
> This flag is set for ptrace GETREGS or PEEKUSER for processes
> that are COMPAT, i.e. 32-bit.
^^^^^^^^^^^^^^^^^^^
at least on x86 this is not the same. TS_COMPAT can also be set if a 64-bit
task calls the 32-bit syscall.
> --- a/arch/tile/include/uapi/asm/ptrace.h
> +++ b/arch/tile/include/uapi/asm/ptrace.h
> @@ -84,5 +84,11 @@ struct pt_regs {
> #define PTRACE_O_TRACEMIGRATE 0x00010000
> #define PTRACE_EVENT_MIGRATE 16
>
> +/*
> + * Flag bits in pt_regs.flags that are part of the ptrace API.
> + * We start our numbering higher up to avoid confusion with the
> + * non-ABI kernel-internal values that use the low 16 bits.
> + */
> +#define PT_FLAGS_COMPAT 0x10000 /* process is an -m32 compat process */
Can't understand how this connects to ptrace (I mean task->ptrace).
OK, let it live in asm/ptrace.h, but it seems that it is similar to
(say) PT_FLAGS_RESTORE_REGS and thus it should be 8?
And. arch/tile/kernel/ptrace.c:arch_ptrace() does
case PTRACE_SETOPTIONS:
/* Support TILE-specific ptrace options. */
child->ptrace &= ~PT_TRACE_MASK_TILE;
tmp = data & PTRACE_O_MASK_TILE;
data &= ~PTRACE_O_MASK_TILE;
AFAICS we need something like BUILD_BUG_ON(PTRACE_O_MASK_TILE & PTRACE_O_MASK),
and
ret = ptrace_request(child, request, addr, data);
if (tmp & PTRACE_O_TRACEMIGRATE)
child->ptrace |= PT_TRACE_MIGRATE;
this also needs "ret == 0" check, and "&= ~PT_TRACE_MASK_TILE" abobe should
be moved here, no?
OTOH using /bin/grep I can't see where do we check ">ptrace & PT_TRACE_MIGRATE".
In short: confused ;)
Oleg.
next prev parent reply other threads:[~2012-12-12 23:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-12 22:24 [PATCH] arch/tile: provide PT_FLAGS_COMPAT value in pt_regs Chris Metcalf
2012-12-12 23:43 ` Oleg Nesterov [this message]
2012-12-13 14:58 ` Chris Metcalf
2012-12-13 15:49 ` Oleg Nesterov
2012-12-13 16:15 ` Chris Metcalf
2012-12-13 16:27 ` Oleg Nesterov
2012-12-13 16:34 ` [PATCH] arch/tile: clean up tile-specific PTRACE_SETOPTIONS Chris Metcalf
2012-12-14 17:26 ` Oleg Nesterov
2012-12-13 16:41 ` [PATCH] arch/tile: provide PT_FLAGS_COMPAT value in pt_regs Chris Metcalf
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=20121212234307.GA7694@redhat.com \
--to=oleg@redhat.com \
--cc=cmetcalf@tilera.com \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.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.