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: Sat, 6 Oct 2012 15:03:11 +0530	[thread overview]
Message-ID: <20121006093311.GB9145@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120930194211.GA11333@redhat.com>

* Oleg Nesterov <oleg@redhat.com> [2012-09-30 21:42:11]:

> 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 find_active_uprobe,
> 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>
> ---
>  kernel/events/uprobes.c |   11 +++++++++++
>  1 files changed, 11 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index 6058231..a81080f 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;
>  	}
> 
> @@ -1391,6 +1392,16 @@ static struct uprobe *find_active_uprobe(unsigned long bp_vaddr, int *is_swbp)
>  	if (!uprobe && test_and_clear_bit(MMF_RECALC_UPROBES, &mm->flags))
>  		mmf_recalc_uprobes(mm);
>  	up_read(&mm->mmap_sem);
> +	/*
> +	 * 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 (uprobe && unlikely(!(uprobe->flags & UPROBE_COPY_INSN))) {
> +		uprobe = NULL;
> +		*is_swbp = 0;
> +	}
> 
>  	return uprobe;
>  }

Should we be adding this check handle_swbp() around can_skip_step()?

The earliest we access arch.insn is in can_skip_step. So we give some
more time for the instruction to be copied.

Also it will probably be a little cleaner, (Not having to drop a uprobe
reference, not having to reset is_swbp.)

-- 
Thanks and Regards
Srikar


  parent reply	other threads:[~2012-10-06  9:32 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 [this message]
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
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=20121006093311.GB9145@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.