On Fri, Apr 15, 2016 at 11:23 AM, Dave Jones <da...@codemonkey.org.uk> wrote:
>
> To put my mind at rest though, am I wrong about that absent task_lock() stuff
> ?
So the task shouldn't be going away, because we are using the
proc_single_file_operations, which use proc_single_show(), which in
turn do a
task = get_pid_task(pid, PIDTYPE_PID);
...
put_task_struct(task);
around it all.
So dereferencing the task pointer is all safe, and the only reason to
use task_lock() is if you end up doing something more complicated.
I'm not seeing anything wrong there. It does do the get_task_mm()
before touching mm fields, and the signal fields get protected by
lock_task_sighand(). The rest seems to just dereference the task
struct directly, and if those values fluctuate that's fine: you get
one or the other, no amount of locking will make /proc/pid/status give
"reliable" values in the big picture, since the user-space reader
won't have the lock anyway.
So it all looks fine to me, but I'm not saying I did some exhaustive check.
Linus
