[lkml]   [2007]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Thread flags modified without set_thread_flag() (non atomically)
    On Thu, 1 Mar 2007 10:34:51 +0100 Haavard Skinnemoen <> wrote:

    > > On Mon, 26 Feb 2007 12:10:37 -0800 Mathieu Desnoyers <> wrote:
    > > > avr32/kernel/ptrace.c: ti->flags |= _TIF_BREAKPOINT;
    > >
    > > No, I don't immediately see anything in the flush_old_exec() code path
    > > which tells us that nobody else can look up this thread_info (or be holding
    > > a ref to it) in this context.
    > >
    > >
    > > > avr32/kernel/ptrace.c: ti->flags |= TIF_SINGLE_STEP;
    > >
    > > heh. Haarvard, you got a bug.
    > Heh, yeah. That would indeed explain some strange gdb behaviour. It
    > will only trigger when single-stepping into an exception or interrupt
    > handler so thanks for pointing it out; I would have had a hard time
    > figuring it out on my own...

    yup, tricky.

    If there's a lesson here, it is "don't provide #defines in the header for
    both versions".

    The block code does a similar thing:

    #define REQ_RW (1 << __REQ_RW)
    #define REQ_FAILFAST (1 << __REQ_FAILFAST)
    #define REQ_SORTED (1 << __REQ_SORTED)

    and I've caught Jens using the wrong identifier at least twice in the past.

    It's better I think to just provide #defines for the bit offsets and
    open-code the shifting if needed. Like PG_foo and BH_Foo.

    > I don't think either of those need to be atomic though, since both of
    > them happen in monitor mode with interrupts disabled.

    That's true until you implement SMP ;)
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-03-01 10:49    [W:0.021 / U:5.724 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site