lkml.org 
[lkml]   [2011]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/3] comm: Introduce comm_lock spinlock to protect task->comm access
    (2011/05/18 7:27), John Stultz wrote:
    > On Tue, 2011-05-17 at 23:27 +0200, Ingo Molnar wrote:
    >> * John Stultz<john.stultz@linaro.org> 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.

    Right.


    >> 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. :)

    Heh, I did ask you current locking rule of task->comm after you introduced
    writable /proc/<pid>/comm.


    >> 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.

    Probably, this is safer choice.



    \
     
     \ /
      Last update: 2011-05-18 03:05    [W:4.830 / U:0.176 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site