Messages in this thread | | | Subject | Re: [PATCH 1/3] comm: Introduce comm_lock seqlock to protect task->comm access | From | John Stultz <> | Date | Fri, 13 May 2011 11:27:56 -0700 |
| |
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
| |