<linux/uprobes.h> declares arch_uprobe_skip_sstep() as a weak function.
But as there is no definition of generic version so when trying to build
uprobes for an architecture that doesn't yet have a arch_uprobe_skip_sstep()
implementation, the vmlinux will try to call arch_uprobe_skip_sstep()
somehwere in Stupidhistan leading to a system crash. We rather want a
proper link error so remove arch_uprobe_skip_sstep().
Signed-off-by: Ralf Baechle <[email protected]>
include/linux/uprobes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index 2a9d75d..cec7397 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -124,7 +124,7 @@ extern int uprobe_post_sstep_notifier(struct pt_regs *regs);
extern int uprobe_pre_sstep_notifier(struct pt_regs *regs);
extern void uprobe_notify_resume(struct pt_regs *regs);
extern bool uprobe_deny_signal(void);
-extern bool __weak arch_uprobe_skip_sstep(struct arch_uprobe *aup, struct pt_regs *regs);
+extern bool arch_uprobe_skip_sstep(struct arch_uprobe *aup, struct pt_regs *regs);
extern void uprobe_clear_state(struct mm_struct *mm);
#else /* !CONFIG_UPROBES */
struct uprobes_state {
On 10/09, Ralf Baechle wrote:
>
> <linux/uprobes.h> declares arch_uprobe_skip_sstep() as a weak function.
> But as there is no definition of generic version so when trying to build
> uprobes for an architecture that doesn't yet have a arch_uprobe_skip_sstep()
> implementation, the vmlinux will try to call arch_uprobe_skip_sstep()
> somehwere in Stupidhistan leading to a system crash. We rather want a
> proper link error so remove arch_uprobe_skip_sstep().
>
> Signed-off-by: Ralf Baechle <[email protected]>
>
> include/linux/uprobes.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
> index 2a9d75d..cec7397 100644
> --- a/include/linux/uprobes.h
> +++ b/include/linux/uprobes.h
> @@ -124,7 +124,7 @@ extern int uprobe_post_sstep_notifier(struct pt_regs *regs);
> extern int uprobe_pre_sstep_notifier(struct pt_regs *regs);
> extern void uprobe_notify_resume(struct pt_regs *regs);
> extern bool uprobe_deny_signal(void);
> -extern bool __weak arch_uprobe_skip_sstep(struct arch_uprobe *aup, struct pt_regs *regs);
> +extern bool arch_uprobe_skip_sstep(struct arch_uprobe *aup, struct pt_regs *regs);
Agreed. I'll take this patch, thanks.
Oleg.
* Ralf Baechle <[email protected]> [2013-10-09 14:08:09]:
> <linux/uprobes.h> declares arch_uprobe_skip_sstep() as a weak function.
> But as there is no definition of generic version so when trying to build
> uprobes for an architecture that doesn't yet have a arch_uprobe_skip_sstep()
> implementation, the vmlinux will try to call arch_uprobe_skip_sstep()
> somehwere in Stupidhistan leading to a system crash. We rather want a
> proper link error so remove arch_uprobe_skip_sstep().
>
> Signed-off-by: Ralf Baechle <[email protected]>
>
Acked-by: Srikar Dronamraju <[email protected]>
Will be nice to have another arch(mips) support for uprobes.
--
Thanks and Regards
Srikar Dronamraju
On Fri, Oct 11, 2013 at 06:21:28AM +0530, Srikar Dronamraju wrote:
> Will be nice to have another arch(mips) support for uprobes.
It's basically ready to be merged - but it's triggering issues elsewhere
in the kernel which I have to resolve first.
The short version is that the memory special mapping created by uprobe
with VM_EXEC but not VM_READ permissions is not working but it's working
if I add VM_READ. That should not be necessary so something deep down
in the guts of arch/mips is wrong.
Ralf
On 10/11/2013 05:24 AM, Ralf Baechle wrote:
> On Fri, Oct 11, 2013 at 06:21:28AM +0530, Srikar Dronamraju wrote:
>
>> Will be nice to have another arch(mips) support for uprobes.
>
> It's basically ready to be merged - but it's triggering issues elsewhere
> in the kernel which I have to resolve first.
>
> The short version is that the memory special mapping created by uprobe
> with VM_EXEC but not VM_READ permissions is not working but it's working
> if I add VM_READ. That should not be necessary so something deep down
> in the guts of arch/mips is wrong.
>
Weird, I have a testcase that explicitly tests VM_EXEC and !VM_READ that
works.
Do you have more information about the failure, I can look at it in the
simulator and see where it goes wrong.
Thanks,
David Daney