lkml.org 
[lkml]   [2007]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Kwatch: kernel watchpoints using CPU debug registers
    On Tue, 6 Feb 2007, Roland McGrath wrote:

    > > So for the sake of argument, let's assume that debug registers can be
    > > assigned with priority values ranging from 0 to 7 (overkill, but who
    > > cares?). By fiat, ptrace assignments use priority 4. Then kwatch callers
    > > can request whatever priority they like. The well-behaved cases you've
    > > been discussing will use priority 0, and the invasive cases can use
    > > priority 7. (With appropriate symbolic names instead of raw numeric
    > > values, naturally.)
    >
    > Sure. Or make it signed with lower value wins, have ptrace use -1 and the
    > average bear use 0 or something especially unobtrusive use >0, and
    > something very obtrusive use -many.

    I wonder where this convention of using lower numbers to indicate higher
    priorities comes from... It seems to be quite prevalent even though it's
    obviously backwards.

    > Unless you are really going to pack it
    > into a few bits somewhere, I'd make it an arbitrary int rather than a
    > special small range; it's just for sort order comparison. Bottom line, I
    > don't really care about the numerology. Just so "break ptrace", "don't
    > break ptrace", and "readily get out of the way on demand" can be expressed.
    > We can always fine-tune it later as there are more concrete users.

    Okay; I'm not fixated on any particular size.

    > > Or maybe that's too complicated. Perhaps all userspace assignments should
    > > always use the same priority level.
    >
    > No, I want priorities among user-mode watchpoint users too. ptrace is
    > rigid, but newer facilities can coexist with ptrace on the same thread and
    > with kwatch, and do fancy new things to fall back when there is debugreg
    > allocation pressure. Future user facilities might be able to do VM tricks
    > that are harder to make workable for kernel mode, for example.

    All right. However this means thread_struct will have to grow in order to
    hold each task's debug-register allocations and priorities. Would that be
    acceptable? (This might be a good reason to keep the number of bits
    down.)

    Another question: How can a program using the ptrace API ever give up a
    debug-register allocation? Disabling the register isn't sufficient; a
    user program should be able to store a watchpoint address in dr1, enable
    it in dr7, disable it in dr7, and then re-enable it in the expectation
    that the address stored in dr1 hasn't been overwritten. As far as I can
    see, ptrace-type allocations have to be permanent (until the task exits or
    execs, or uses some other to-be-determined API to do the de-allocation.)

    Alan Stern

    -
    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: 2007-02-07 20:25    [W:2.715 / U:0.228 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site