[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120726173126.GA5787@redhat.com>
Date: Thu, 26 Jul 2012 19:31:26 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-kernel@...r.kernel.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Ingo Molnar <mingo@...hat.com>,
Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Subject: Re: [PATCH] uprobes: don't enable/disable signle step if the user
did it
Well. I agree, this needs changes. To begin with, uprobe should avoid
user_enable_single_step() which does access_process_vm(). And I suspect
uprobes have the problems with TIF_FORCED_TF logic.
But I am not sure about this patch...
On 07/26, Sebastian Andrzej Siewior wrote:
>
> @@ -1528,7 +1528,10 @@ static void handle_swbp(struct pt_regs *regs)
>
> utask->state = UTASK_SSTEP;
> if (!pre_ssout(uprobe, regs, bp_vaddr)) {
> - user_enable_single_step(current);
> + if (test_tsk_thread_flag(current, TIF_SINGLESTEP))
> + uprobe->flags |= UPROBE_USER_SSTEP;
> + else
> + user_enable_single_step(current);
This is x86 specific, TIF_SINGLESTEP is not defined on every arch.
> @@ -1569,7 +1572,10 @@ static void handle_singlestep(struct uprobe_task *utask, struct pt_regs *regs)
> put_uprobe(uprobe);
> utask->active_uprobe = NULL;
> utask->state = UTASK_RUNNING;
> - user_disable_single_step(current);
> + if (uprobe->flags & UPROBE_USER_SSTEP)
> + uprobe->flags &= ~UPROBE_USER_SSTEP;
> + else
> + user_disable_single_step(current);
This is not enough (and I am not sure this is portable).
If SINGLESTEP was set, we should send SIGTRAP here. With this patch
we return with X86_EFLAGS_TF set, gdb will be notified only after the
next insn. And if we notify gdb, there is no need to keep X86_EFLAGS_TF.
I'm afraid this needs more thinking and new arch-dependant helpers.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists