Re: [PATCHv11 2.6.36-rc2-tip 3/15] 3: uprobes: Slot allocationfor Execution out of line(XOL)

[Srikar Dronamraju]

* Peter Zijlstra <peterz@xxxxxxxxxxxxx> [2010-09-03 18:51:54]:

> On Fri, 2010-09-03 at 22:10 +0530, Srikar Dronamraju wrote:
> > > > +   mb();
> > > 
> > > Where is the matching barrier?
> > 
> > I dont want the compiler to reorder the instructions and do the
> > assignment for user_bkpt to be done before we complete the copy above.
> > 
> > If the assignment happens before we copy the content into the slot,
> > someother thread that might hit the same probe actually things the slot
> > is ready and tries to jump to that slot even before the slot is
> > initialized.
> > 
> > Please let me know if I could have done it differently. 
> 
> 
> If you want a compiler barrier, use barrier(), but here you seem to
> describe a multi-threaded situation, in which case the observer thread
> needs at least a rmb() in order for that mb() to mean anything other
> than the compiler barrier it implies.
> 
> Also, use smp_* barriers.
> 
> 
> 

Okay,  would something like this suffice?


static unsigned long xol_get_insn_slot(struct user_bkpt *user_bkpt,
				struct uprobes_xol_area *xol_area)
{
	unsigned long flags, xol_vaddr = 0;
	int len;

	if (unlikely(!xol_area))
		return 0;

	smp_rmb();
	if (user_bkpt->xol_vaddr)
		return user_bkpt->xol_vaddr;

	spin_lock_irqsave(&xol_area->lock, flags);
	xol_vaddr = xol_take_insn_slot(xol_area);
	spin_unlock_irqrestore(&xol_area->lock, flags);

	/*
	 * Initialize the slot if user_bkpt->vaddr points to valid
	 * instruction slot.
	 */
	if (!xol_vaddr)
		return 0;

	len = access_process_vm(current, xol_vaddr, user_bkpt->insn,
					UPROBES_XOL_SLOT_BYTES, 1);
	if (unlikely(len < UPROBES_XOL_SLOT_BYTES))
		printk(KERN_ERR "Failed to copy instruction at %#lx "
				"len = %d\n", user_bkpt->vaddr, len);

	/*
	 * Update user_bkpt->xol_vaddr after giving a chance for the slot to
	 * be initialized.
	 */
	smp_mb();
	user_bkpt->xol_vaddr = xol_vaddr;
	return user_bkpt->xol_vaddr;
}

-- 
Thanks and Regards
Srikar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/