All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Pratyush Anand <panand@redhat.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	srikar@linux.vnet.ibm.com, vijaya.kumar@caviumnetworks.com,
	Will Deacon <will.deacon@arm.com>,
	Oleg Nesterov <oleg@redhat.com>,
	open list <linux-kernel@vger.kernel.org>,
	David Long <dave.long@linaro.org>,
	Steve Capper <steve.capper@linaro.org>,
	William Cohen <wcohen@redhat.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH V2 6/6] arm64: Add uprobe support
Date: Mon, 31 Oct 2016 14:32:37 -0600	[thread overview]
Message-ID: <20161031203237.lof7uzt4ye57y7h3@localhost> (raw)
In-Reply-To: <CAHB_Gup2-yWbKK7QpMjJv7M6oNdV8Mz10wxWaS8ojzR4s8wv=g@mail.gmail.com>

Hi Pratyush,

On Mon, Oct 31, 2016 at 02:10:43PM +0530, Pratyush Anand wrote:
> On Sun, Oct 30, 2016 at 7:39 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Tue, Sep 27, 2016 at 01:18:00PM +0530, Pratyush Anand wrote:
> >> --- /dev/null
> >> +++ b/arch/arm64/kernel/probes/uprobes.c
> >> @@ -0,0 +1,221 @@
> >> +/*
> >> + * Copyright (C) 2014-2016 Pratyush Anand <panand@redhat.com>
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + */
> >> +#include <linux/highmem.h>
> >> +#include <linux/ptrace.h>
> >> +#include <linux/uprobes.h>
> >> +#include <asm/cacheflush.h>
> >> +
> >> +#include "decode-insn.h"
> >> +
> >> +#define UPROBE_INV_FAULT_CODE        UINT_MAX
> >> +
> >> +bool is_trap_insn(uprobe_opcode_t *insn)
> >> +{
> >> +     return false;
> >> +}
> >
> > On the previous series, I had a comment left unanswered with regards to
> > always returning false in is_trap_insn():
> >
> > Looking at handle_swbp(), if we hit a breakpoint for which we don't have
> > a valid uprobe, this function currently sends a SIGTRAP. But if
> > is_trap_insn() returns false always, is_trap_at_addr() would return 0 in
> > this case so the SIGTRAP is never issued.
> 
> A agreed on this that the older implementation i.e. the default one of
> is_trap_insn() is better for the time being. I sent out V2 before your
> last comment on it in V1 :(.

Thinking some more about this, the default is_trap_insn() still seems
better. It may return true occasionally for 32-bit tasks but we don't
care anyway because the subsequent arch_uprobe_analyze_insn() would
prevent the installation of the uprobe. However, always returning false
in is_trap_insn() would confuse handle_swbp() if you install uprobes in
an already debugged task.

> probably 'strtle r0, [r0], #160' would have the closest matching
> aarch32 instruction wrt BRK64_OPCODE_UPROBES(0xd42000A0). But that too
> seems a bad aarch32 instruction. So, there might not be any aarch32
> instruction which will match to uprobe BRK instruction.

As I said above, even if it matches, we don't support uprobes for 32-bit
(caught by the subsequent test).

> Therefore, if I send a V3 by removing aacrh64 is_trap_insn(), would
> that be acceptable, or do you see any other issue with this patch
> series? If there is anything else, I would address that in V3 as well.

I think I have one minor comment on arch_uprobe_analyze_insn() and v3
should look ok.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 6/6] arm64: Add uprobe support
Date: Mon, 31 Oct 2016 14:32:37 -0600	[thread overview]
Message-ID: <20161031203237.lof7uzt4ye57y7h3@localhost> (raw)
In-Reply-To: <CAHB_Gup2-yWbKK7QpMjJv7M6oNdV8Mz10wxWaS8ojzR4s8wv=g@mail.gmail.com>

Hi Pratyush,

On Mon, Oct 31, 2016 at 02:10:43PM +0530, Pratyush Anand wrote:
> On Sun, Oct 30, 2016 at 7:39 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Tue, Sep 27, 2016 at 01:18:00PM +0530, Pratyush Anand wrote:
> >> --- /dev/null
> >> +++ b/arch/arm64/kernel/probes/uprobes.c
> >> @@ -0,0 +1,221 @@
> >> +/*
> >> + * Copyright (C) 2014-2016 Pratyush Anand <panand@redhat.com>
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + */
> >> +#include <linux/highmem.h>
> >> +#include <linux/ptrace.h>
> >> +#include <linux/uprobes.h>
> >> +#include <asm/cacheflush.h>
> >> +
> >> +#include "decode-insn.h"
> >> +
> >> +#define UPROBE_INV_FAULT_CODE        UINT_MAX
> >> +
> >> +bool is_trap_insn(uprobe_opcode_t *insn)
> >> +{
> >> +     return false;
> >> +}
> >
> > On the previous series, I had a comment left unanswered with regards to
> > always returning false in is_trap_insn():
> >
> > Looking at handle_swbp(), if we hit a breakpoint for which we don't have
> > a valid uprobe, this function currently sends a SIGTRAP. But if
> > is_trap_insn() returns false always, is_trap_at_addr() would return 0 in
> > this case so the SIGTRAP is never issued.
> 
> A agreed on this that the older implementation i.e. the default one of
> is_trap_insn() is better for the time being. I sent out V2 before your
> last comment on it in V1 :(.

Thinking some more about this, the default is_trap_insn() still seems
better. It may return true occasionally for 32-bit tasks but we don't
care anyway because the subsequent arch_uprobe_analyze_insn() would
prevent the installation of the uprobe. However, always returning false
in is_trap_insn() would confuse handle_swbp() if you install uprobes in
an already debugged task.

> probably 'strtle r0, [r0], #160' would have the closest matching
> aarch32 instruction wrt BRK64_OPCODE_UPROBES(0xd42000A0). But that too
> seems a bad aarch32 instruction. So, there might not be any aarch32
> instruction which will match to uprobe BRK instruction.

As I said above, even if it matches, we don't support uprobes for 32-bit
(caught by the subsequent test).

> Therefore, if I send a V3 by removing aacrh64 is_trap_insn(), would
> that be acceptable, or do you see any other issue with this patch
> series? If there is anything else, I would address that in V3 as well.

I think I have one minor comment on arch_uprobe_analyze_insn() and v3
should look ok.

-- 
Catalin

  reply	other threads:[~2016-10-31 20:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-27  7:43 [PATCH V2 0/6] ARM64: Uprobe support added Pratyush Anand
2016-09-27  7:43 ` Pratyush Anand
2016-09-27  7:47 ` [PATCH V2 1/6] arm64: kprobe: protect/rename few definitions to be reused by uprobe Pratyush Anand
2016-09-27  7:47   ` Pratyush Anand
2016-09-27  7:47 ` [PATCH V2 2/6] arm64: kgdb_step_brk_fn: ignore other's exception Pratyush Anand
2016-09-27  7:47   ` Pratyush Anand
2016-09-27  7:47 ` [PATCH V2 3/6] arm64: Handle TRAP_TRACE for user mode as well Pratyush Anand
2016-09-27  7:47   ` Pratyush Anand
2016-09-27  7:47 ` [PATCH V2 4/6] arm64: Handle TRAP_BRKPT " Pratyush Anand
2016-09-27  7:47   ` Pratyush Anand
2016-09-27  7:47 ` [PATCH V2 5/6] arm64: introduce mm context flag to keep 32 bit task information Pratyush Anand
2016-09-27  7:47   ` Pratyush Anand
2016-09-27  7:48 ` [PATCH V2 6/6] arm64: Add uprobe support Pratyush Anand
2016-09-27  7:48   ` Pratyush Anand
2016-10-30 14:09   ` Catalin Marinas
2016-10-30 14:09     ` Catalin Marinas
2016-10-31  8:40     ` Pratyush Anand
2016-10-31  8:40       ` Pratyush Anand
2016-10-31 20:32       ` Catalin Marinas [this message]
2016-10-31 20:32         ` Catalin Marinas
2016-10-31 20:34   ` Catalin Marinas
2016-10-31 20:34     ` Catalin Marinas
2016-10-26  3:17 ` [PATCH V2 0/6] ARM64: Uprobe support added Pratyush Anand
2016-10-26  3:17   ` Pratyush Anand

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=20161031203237.lof7uzt4ye57y7h3@localhost \
    --to=catalin.marinas@arm.com \
    --cc=dave.long@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=oleg@redhat.com \
    --cc=panand@redhat.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=steve.capper@linaro.org \
    --cc=vijaya.kumar@caviumnetworks.com \
    --cc=wcohen@redhat.com \
    --cc=will.deacon@arm.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.