[lkml]   [2011]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/3] comm: Introduce comm_lock spinlock to protect task->comm access
    On Tue, 2011-05-17 at 23:27 +0200, Ingo Molnar wrote:
    > * John Stultz <> wrote:
    > > The implicit rules for current->comm access being safe without locking are no
    > > longer true. Accessing current->comm without holding the task lock may result
    > > in null or incomplete strings (however, access won't run off the end of the
    > > string).
    > This is rather unfortunate - task->comm is used in a number of performance
    > critical codepaths such as tracing.
    > Why does this matter so much? A NULL string is not a big deal.

    I'll defer to KOSAKI Motohiro and David on this bit. :)

    > Note, since task->comm is 16 bytes there's the CMPXCHG16B instruction on x86
    > which could be used to update it atomically, should atomicity really be
    > desired.

    Could we use this where cmpxchg16b is available and fall back to locking
    if not? Or does that put too much of a penalty on arches that don't have
    cmpxchg16b support?

    Alternatively, we can have locked accessors that are safe in the
    majority of slow-path warning printks, and provide unlocked accessors
    for cases where the performance is critical and the code can properly
    handle possibly incomplete comms.


     \ /
      Last update: 2011-05-18 00:29    [W:0.020 / U:2.528 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site