All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <peterz@infradead.org>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Anton Arapov <anton@redhat.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/7] uprobes: Fix handle_swbp() vs unregister() + register() race
Date: Sun, 7 Oct 2012 12:42:31 +0530	[thread overview]
Message-ID: <20121007071231.GD9143@linux.vnet.ibm.com> (raw)
In-Reply-To: <20121006185337.GA14697@redhat.com>

* Oleg Nesterov <oleg@redhat.com> [2012-10-06 20:53:37]:

> On 10/06, Srikar Dronamraju wrote:
> >
> > >
> > > for the future changes... (say, we can remove bp if consumers do not
> > > want to trace this task). Not sure it makes sense to change it right
> > > now.
> > >
> > > So. Should I leave this patch as is? Or do you want me to move this
> > > check into handler_chain() and make it return "bool restart"?
> >
> > Lets keep it as is for now.
> >
> > Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> 
> Thanks...
> 
> But I am starting to think that I misunderstood your comment, you
> did not suggest to add this check into skip_sstep() as I wrongly
> thought.
> 
> And yes, I agree it would be more clean to move it out from
> find_active_uprobe() and avoid put_uprobe && clear_swbp....
> 
> So how about v2 below?

Yes, this is what I meant. Thanks for the relooking into it.
This will mean, change in one hunk in patch 7/7.

Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>

> 
> ------------------------------------------------------------------------------
> [PATCH 4/7] uprobes: Fix handle_swbp() vs unregister() + register() race
> 
> Strictly speaking this race was added by me in 56bb4cf6. However
> I think that this bug is just another indication that we should
> move copy_insn/uprobe_analyze_insn code from install_breakpoint()
> to uprobe_register(), there are a lot of other reasons for that.
> Until then, add a hack to close the race.
> 
> A task can hit uprobe U1, but before it calls find_uprobe() this
> uprobe can be unregistered *AND* another uprobe U2 can be added to
> uprobes_tree at the same inode/offset. In this case handle_swbp()
> will use the not-fully-initialized U2, in particular its arch.insn
> for xol.
> 
> Add the additional !UPROBE_COPY_INSN check into handle_swbp(),
> if this flag is not set we simply restart as if the new uprobe was
> not inserted yet. This is not very nice, we need barriers, but we
> will remove this hack when we change uprobe_register().
> 
> Note: with or without this patch install_breakpoint() can race with
> itself, yet another reson to kill UPROBE_COPY_INSN altogether. And
> even the usage of uprobe->flags is not safe. See the next patches.
> 
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>
> Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> ---
>  kernel/events/uprobes.c |    9 +++++++++
>  1 files changed, 9 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index cfa22c4..dbbca3a 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -596,6 +596,7 @@ install_breakpoint(struct uprobe *uprobe, struct mm_struct *mm,
>  		BUG_ON((uprobe->offset & ~PAGE_MASK) +
>  				UPROBE_SWBP_INSN_SIZE > PAGE_SIZE);
> 
> +		smp_wmb(); /* pairs with rmb() in find_active_uprobe() */
>  		uprobe->flags |= UPROBE_COPY_INSN;
>  	}
> 
> @@ -1436,6 +1437,14 @@ static void handle_swbp(struct pt_regs *regs)
>  		}
>  		return;
>  	}
> +	/*
> +	 * TODO: move copy_insn/etc into _register and remove this hack.
> +	 * After we hit the bp, _unregister + _register can install the
> +	 * new and not-yet-analyzed uprobe at the same address, restart.
> +	 */
> +	smp_rmb(); /* pairs with wmb() in install_breakpoint() */
> +	if (unlikely(!(uprobe->flags & UPROBE_COPY_INSN)))
> +		goto restart;
> 
>  	utask = current->utask;
>  	if (!utask) {
> -- 
> 1.5.5.1
> 
> 


  reply	other threads:[~2012-10-07  7:11 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-30 19:41 [PATCH 0/7] uprobes: register/unregister bugfixes Oleg Nesterov
2012-09-30 19:41 ` [PATCH 1/7] uprobes/x86: Only rep+nop can be emulated correctly Oleg Nesterov
2012-10-06  7:20   ` Srikar Dronamraju
2012-09-30 19:42 ` [PATCH 2/7] uprobes: Don't return success if alloc_uprobe() fails Oleg Nesterov
2012-10-06  7:25   ` Srikar Dronamraju
2012-09-30 19:42 ` [PATCH 3/7] uprobes: Do not delete uprobe if uprobe_unregister() fails Oleg Nesterov
2012-10-06  8:48   ` Srikar Dronamraju
2012-09-30 19:42 ` [PATCH 4/7] uprobes: Fix handle_swbp() vs unregister() + register() race Oleg Nesterov
2012-10-02 18:42   ` Oleg Nesterov
2012-10-06  9:33   ` Srikar Dronamraju
2012-10-06 17:25     ` Oleg Nesterov
2012-10-06 17:37       ` Srikar Dronamraju
2012-10-06 18:53         ` Oleg Nesterov
2012-10-07  7:12           ` Srikar Dronamraju [this message]
2012-09-30 19:42 ` [PATCH 5/7] uprobes: Introduce uprobe_copy_insn() Oleg Nesterov
2012-10-06  9:45   ` Srikar Dronamraju
2012-10-06 17:10     ` Oleg Nesterov
2012-10-06 17:38       ` Srikar Dronamraju
2012-10-06 18:59         ` Oleg Nesterov
2012-10-07  7:14           ` Srikar Dronamraju
2012-09-30 19:42 ` [PATCH 6/7] uprobes: Fix uprobe_copy_insn() race with itself Oleg Nesterov
2012-10-06  9:52   ` Srikar Dronamraju
2012-09-30 19:42 ` [PATCH 7/7] uprobes: Fix the racy uprobe->flags manipulation Oleg Nesterov
2012-10-04  8:57   ` Anton Arapov
2012-10-06  9:54   ` Srikar Dronamraju
2012-09-30 19:44 ` [PATCH 0/7] uprobes: register/unregister bugfixes Oleg Nesterov
2012-10-01 12:55   ` Srikar Dronamraju
2012-10-01 14:03     ` Oleg Nesterov

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=20121007071231.GD9143@linux.vnet.ibm.com \
    --to=srikar@linux.vnet.ibm.com \
    --cc=ananth@in.ibm.com \
    --cc=anton@redhat.com \
    --cc=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=peterz@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.