lkml.org 
[lkml]   [2006]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Linux Kernel Markers 0.13 for 2.6.17
    * Frank Ch. Eigler (fche@redhat.com) wrote:
    > Mathieu Desnoyers <compudj@krystal.dyndns.org> writes:
    >
    > > [...]
    > > > Yep, that looks reasonable. Though you could just directly test a
    > > > per-marker enable flag, rather than using "condition"...
    > > [...]
    > > I am not sure I understand your suggestion correctly.. do you mean having
    > > a per-marker flag that would be loaded and tested at every marker site ?
    >
    > I gather that one reason for working so hard with the inline assembly
    > is a race condition problem with the plain STAP_MARK style of marker
    > disconnection:
    >
    > if (pointer) (*pointer)(args ...);
    >
    > Granted, but this problem could almost certainly be dealt with simpler
    > than that. How about a compxchg or other atomic-fetch of the static
    > pointer with a local variable? That should solve the worry of an
    > (*NULL) call.
    >

    I don't really see how cmpxchg might be needed here.

    Atomic fetch of a static variable is how I will do it in my next version for the
    non optimized case :

    volatile static var = 0;
    if(var) {
    preempt disable
    call
    preempt_enable_no_resched
    }

    But, still, in the optimized case, the if(var) will depend on an immediate
    value, therefore saving the memory read.


    > If we then become concerned with a valid pointer become obsolete (the
    > probe handler function wanting to unload), we might be able to use
    > some RCU-type deferral mechanism and/or preempt controls to ensure
    > that this does not happen.
    >

    This is exactly why the preemption is disabled around the call. However, RCU
    must always _see_ a coherent version of the structure in memory.

    Calling an empty function, disabling preemption around the call and calling
    synchronize_sched() before deleting the removed function looks very much like
    a RCU-style protection (actually, that's what it is).

    Mathieu


    OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg
    Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-09-26 22:13    [W:5.552 / U:0.120 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site