From: john stultz <johnstul@us.ibm.com>
To: Darren Hart <dvhltc@us.ibm.com>
Cc: Andi Kleen <andi@firstfloor.org>,
Andrew Morton <akpm@linux-foundation.org>,
Arjan van de Ven <arjan@infradead.org>,
lkml <linux-kernel@vger.kernel.org>,
Mike Fulton <fultonm@ca.ibm.com>,
Sean Foley <Sean_Foley@ca.ibm.com>
Subject: Re: [RFC][PATCH] Add prctl to set sibling thread names (take two)
Date: Fri, 30 Oct 2009 12:54:12 -0700 [thread overview]
Message-ID: <1256932452.3634.7.camel@work-vm> (raw)
In-Reply-To: <4AE2786C.7000400@us.ibm.com>
On Fri, 2009-10-23 at 20:45 -0700, Darren Hart wrote:
> Hi John,
>
> Just a couple nitpics really, looks pretty good to me - other than the
> need for the wmb()s below.
>
> john stultz wrote:
> > + /*
> > + * Threads may access current->comm without holding
> > + * the task lock, so write the string carefully
> > + * to avoid non-terminating reads. Readers without a lock
> > + * with get the oldname, the newname or an empty string.
>
> s/with/will/
> s/oldname/old name/ (it isn't a variable right?)
> s/newname/new name/ (it isn't a variable right?)
Fixed. Thanks
> > + */
> > + tsk->comm[0] = NULL;
> > + /* XXX - Need an mb() here?*/
>
> I believe you do, yes. Now, which one... hrm... checking... You only
> care about ensuring the the comm[0] store occurs BEFORE the strlcpy.
> But, if no lock is held here, you can be preempted, so this is important
> for both UP and SMP. I believe what you need here is:
>
> wmb()
>
> Memory barrier experts, please enlighten us if I am missing something.
>
> > + strlcpy(tsk->comm+1, buf+1, sizeof(tsk->comm)-1);
>
> And one more here I should think, otherwise that could effectively undo
> the previous one :-)
>
> wmb()
Cool. Added. If anyone sees anything incorrect here, please let me know.
> > + tsk->comm[0] = buf[0];
> > task_unlock(tsk);
>
> To be clear, we hold the lock to prevent other threads from changing
> this at the same time as us - any other thread but the target thread
> that is?
Right, so in order to change the comm, you have to hold the task_lock
(even if your changing your own). The issue I'm trying to address is
the threads self-referencing their comm without holding the task_lock.
We don't want to slow them down by adding additional locking around
every current->comm access, but we want to allow other threads to modify
the comm.
> > +static ssize_t
> > +comm_write(struct file *file, const char __user *buf,
> > + size_t count, loff_t *offset)
> > +{
> > + struct inode *inode = file->f_path.dentry->d_inode;
> > + struct task_struct *p;
> > + char buffer[TASK_COMM_LEN];
> > +
> > + memset(buffer, 0, sizeof(buffer));
>
> What purpose does zeroing this entire buffer serve?
Just make sure we always terminate with a null.
> > + if (count > sizeof(buffer) - 1)
> > + count = sizeof(buffer) - 1;
> > + if (copy_from_user(buffer, buf, count))
> > + return -EFAULT;
> > +
>
> Extra whitespace
fixed.
Thanks for the review. I'll send a new version out shortly.
-john
next prev parent reply other threads:[~2009-10-30 19:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-24 1:21 [RFC][PATCH] Add prctl to set sibling thread names (take two) john stultz
2009-10-24 3:45 ` Darren Hart
2009-10-30 19:54 ` john stultz [this message]
2009-10-30 20:06 ` [RFC][PATCH] Allow threads to rename siblings via /proc/pid/tasks/tid/comm john stultz
2009-11-07 1:38 ` [PATCH] " john stultz
2009-11-07 22:52 ` Andi Kleen
2009-11-08 20:45 ` Arjan van de Ven
2009-11-10 1:26 ` john stultz
2009-11-16 21:11 ` john stultz
2009-11-18 21:54 ` Andrew Morton
2009-11-19 1:04 ` KOSAKI Motohiro
2009-11-21 0:33 ` john stultz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1256932452.3634.7.camel@work-vm \
--to=johnstul@us.ibm.com \
--cc=Sean_Foley@ca.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=arjan@infradead.org \
--cc=dvhltc@us.ibm.com \
--cc=fultonm@ca.ibm.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.