On Wed, 26 Aug 2020 13:36:15 +0000 "[email protected]" <[email protected]> wrote:
> > > > -----Original Message----- > > From: [email protected] <[email protected]> > > Sent: Wednesday, August 26, 2020 6:26 PM > > To: Masami Hiramatsu <[email protected]> > > Cc: Eddy Wu (RD-TW) <[email protected]>; [email protected]; > > [email protected] > > Subject: Re: x86/kprobes: kretprobe fails to triggered if kprobe at > > function entry is not optimized (trigger by int3 breakpoint) > > > > On Wed, Aug 26, 2020 at 07:00:41PM +0900, Masami Hiramatsu wrote: > > > Of course, this doesn't solve the llist_del_first() contention in the > > > pre_kretprobe_handler(). So anyway we need a lock for per-probe llist > > > (if I understand llist.h comment correctly.) > > > > Bah, lemme think about that. Kprobes really shouldn't be using locks :/ > > Maybe we can have per-cpu free list for retprobe_instance? > This ensure we only have one user requesting free instance at a time, given > that pre_kretprobe_handler() wont recursive. That will restrict kretprobe not to probe the recursive call loop... and if a thread is scheduled, another thread will not be probed too. I think lockless kretprobe is finally implemented by merging it's shadow-stack with func-graph tracer. Thank you, > > We may be wasting memory if target function perfer some cpu though. > > > TREND MICRO EMAIL NOTICE > > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. If > you are not the intended recipient, you are not authorized to use or disclose > this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > > For details about what personal information we collect and why, please see > our Privacy Notice on our website at: Read privacy > policy<http://www.trendmicro.com/privacy> -- Masami Hiramatsu <[email protected]>
