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
next prev parent 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: linkBe 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.