Re: [PATCH] task name handling in proc fs

[Mike Kravetz]

On Thu, Jul 01, 2004 at 04:03:35PM -0700, Andrew Morton wrote:
> 
> But this just makes it a bit less racy than it used to be.

Agreed!

> If we need locking around task->comm (and it seems that we do) then
> let's do it.

I'm not sure if there is a need/desire for locking.  But, I don't
have any proc fs history.  What we saw were really badly formed
task names: nulls embedded within strings.  My goal was to simply
provide well formed strings (even if they didn't make sense).

I guess the question is 'how important is it to make sure that
data in these files is consistent/accurate when reported?'.  If it
is highly important, then we need to consider locking down the
task for the duration of gathering all data we want to display
(not just task->comm).  However, my guess is that we would want
to sacrifice this accuracy/consistency to avoid taking locks if
possible.  Again, this is just my opinion and I don't have any
history here ... but would be happy to code up any recommendation.

P.S. Note that these code paths already get the task lock once
as a result of calling get_task_mm().

-- 
Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/