All of lore.kernel.org
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 6/6] arm64: Add uprobe support
Date: Sun, 30 Oct 2016 14:09:01 +0000	[thread overview]
Message-ID: <20161030140901.h6mdxbb4pgqpqs7j@localhost> (raw)
In-Reply-To: <41cc70043792e65cbc3b4cc4ad7fbf6379afa550.1474960629.git.panand@redhat.com>

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.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Pratyush Anand <panand@redhat.com>
Cc: linux-arm-kernel@lists.infradead.org, linux@arm.linux.org.uk,
	srikar@linux.vnet.ibm.com, vijaya.kumar@caviumnetworks.com,
	will.deacon@arm.com, linux-kernel@vger.kernel.org,
	oleg@redhat.com, dave.long@linaro.org, steve.capper@linaro.org,
	wcohen@redhat.com
Subject: Re: [PATCH V2 6/6] arm64: Add uprobe support
Date: Sun, 30 Oct 2016 14:09:01 +0000	[thread overview]
Message-ID: <20161030140901.h6mdxbb4pgqpqs7j@localhost> (raw)
In-Reply-To: <41cc70043792e65cbc3b4cc4ad7fbf6379afa550.1474960629.git.panand@redhat.com>

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.

-- 
Catalin

  reply	other threads:[~2016-10-30 14:09 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 [this message]
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
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=20161030140901.h6mdxbb4pgqpqs7j@localhost \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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.