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.121 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site