Andrew - the following should address your concerns in patch:
proc-dont-lock-task_structs-indefinitely-cpuset-fix.patch
where you had to include "../fs/proc/internal.h" in kernel/cpuset.c
Eric wrote (off list in a patch to Andrew, apparently):
> I just refactored fs/proc/base.c to use task_refs to ensure there are not
> long user triggerable hold times of task_struct. It looks like I missed
> cpuset.c. Oops.
>
> This patch updates proc_cpuset_show to handle the task dying between when
> the file is opened and when data is read out.
Thanks for catching this, Eric.
I was just about to send a patch that moved the cpuset_open(),
cpuset_release() and proc_cpuset_operations{} code from kernel
cpuset.c to fs/proc/base.c, leaving behind a now publically
exported proc_cpuset_show() routine that handles the cpuset
specific details.
For lurkers, this is the code that prints a tasks cpuset path
in the file /proc/<pid>/cpuset. That code had some proc file
specific details buried in its kernel/cpuset.c implementation,
and Eric is changing those proc details. Proc stuff should go
in proc/fs and cpuset stuff in kernel/cpuset.c
I will remerge with your fixes to handle possibly null task_refs
correctly and try again to send my above patch.
However, I have some debugging to do on this kernel first.
It blows up on boot (ia64 sn2_defconfig).
I haven't started to analyze it any yet. I don't know if it's a bug
or pilot error yet.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
