lkml.org 
[lkml]   [2011]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 1/3] comm: Introduce comm_lock seqlock to protect task->comm access
    From
    Date
    On Fri, 2011-05-13 at 20:13 +0900, KOSAKI Motohiro wrote:
    > Hi
    >
    > Sorry for the long delay.
    >
    > > char *get_task_comm(char *buf, struct task_struct *tsk)
    > > {
    > > - /* buf must be at least sizeof(tsk->comm) in size */
    > > - task_lock(tsk);
    > > - strncpy(buf, tsk->comm, sizeof(tsk->comm));
    > > - task_unlock(tsk);
    > > + unsigned long seq;
    > > +
    > > + do {
    > > + seq = read_seqbegin(&tsk->comm_lock);
    > > +
    > > + strncpy(buf, tsk->comm, sizeof(tsk->comm));
    > > +
    > > + } while (read_seqretry(&tsk->comm_lock, seq));
    > > +
    > > return buf;
    > > }
    >
    > Can you please explain why we should use seqlock? That said,
    > we didn't use seqlock for /proc items. because, plenty seqlock
    > write may makes readers busy wait. Then, if we don't have another
    > protection, we give the local DoS attack way to attackers.

    So you're saying that heavy write contention can cause reader
    starvation?

    > task->comm is used for very fundamentally. then, I doubt we can
    > assume write is enough rare. Why can't we use normal spinlock?

    I think writes are likely to be fairly rare. Tasks can only name
    themselves or sibling threads, so I'm not sure I see the risk here.

    Mind going into more detail?

    thanks
    -john




    \
     
     \ /
      Last update: 2011-05-13 20:31    [W:0.024 / U:0.116 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site