All of lore.kernel.org
 help / color / mirror / Atom feed
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.


  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.