On Fri, Mar 23, 2007 at 11:12:22AM -0700, Stone, Joshua I wrote:
> The ability to disable/reenable kprobes would be an interesting
> enhancement. However, unregister_disabled_kprobes() shouldn't have a
> global effect, because there might be a concurrent kprobes user that
> disabled a probe with t
On Fri, Mar 23, 2007 at 02:22:48PM -0400, Frank Ch. Eigler wrote:
> Really? What possible problems can occur? The worst that occurs to
> me is that if someone forgets to call the commit function, the kprobes
> will still be disabled, but memory won't be recycled for a while.
Exactly. It's a ver
Hi Anil,
Keshavamurthy, Anil S wrote:
> On Mon, Mar 26, 2007 at 12:17:49PM +0900, Masami Hiramatsu wrote:
>> Hi Christoph and Anil,
>>
>> Thank you for your comments.
>>
>> Christoph Hellwig wrote:
>>> Speeding up the unregistration is a very good idea, but this interface
>>> is rather horrible.
Hi Christoph and Anil,
Thank you for your comments.
Christoph Hellwig wrote:
> Speeding up the unregistration is a very good idea, but this interface
> is rather horrible. It's almost a receipe for users to get it wrong.
Keshavamurthy, Anil S wrote:
> I agree with Christop that the interface is
Hi -
"Keshavamurthy, Anil S" <[EMAIL PROTECTED]> writes:
> [...]
> > Really? What possible problems can occur? The worst that occurs
> > to me is that if someone forgets to call the commit function, the
> > kprobes will still be disabled, but memory won't be recycled for a
> > while. [...]
>
Hi -
Keshavamurthy, Anil S wrote:
> I agree with Christoph that the interface is horrible and error prone.
Really? What possible problems can occur? The worst that occurs to
me is that if someone forgets to call the commit function, the kprobes
will still be disabled, but memory won't be recycl
Keshavamurthy, Anil S wrote:
> I agree with Christop that the interface is horrible and error prone.
> However, I see the use case where people want to disable the probes
> quickly and would like to reenable them again. Looking closely at
> your patch,
> I think this can be acheived.
> Here is my
On Fri, Mar 23, 2007 at 11:43:48PM +0900, Masami Hiramatsu wrote:
> I'd like to suggest introducing following two interfaces for this issue.
> The first interface is unregister_*probe_fast(). This removes
> breakpoint instruction from kernel code and adds specified probe
> to the unregistering list
Hi Ananth,
Here is a series of patches which introduce two kinds of interfaces
for speeding up unregistering process of kprobes.
Currently, the unregister_*probe() function takes a long time to
unregister specified probe because it waits the rcu synchronization
after each unregistration. So we ne
9 matches
Mail list logo
