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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>