Description of problem:

  ps is showing all threads in the same cgroup/cpuset when they are on different cgroup/cpuset.

Version-Release number of selected component (if applicable):
  procps-3.2.8-34.el6_7.x86_64

How reproducible:
  Always

Steps to Reproduce:
  On a RHEL6, with auditd installed (just to show an example):

1 Mount cgroup interface
  # mkdir /cgroup/
  # mount -t tmpfs cgroup_root /cgroup/
  # mkdir /cgroup/cpuset
  # mount -t cgroup -ocpuset cpuset /cgroup/cpuset/

2. Create a cpuset:
  # cd /cgroup/cpuset/
  # mkdir app
  # cd app/
  # echo 0 > cpuset.cpus 
  # echo 0 > cpuset.mems 

3. select a multi-threaded proc (e.g auditd):

  # ps -eLo pid,lwp,comm,cgroup | grep audit
   1025  1025 kauditd         cpuset:/
   1364  1364 auditd          cpuset:/
   1364  1365 auditd          cpuset:/

4. Insert the thread with the same pid/lwp in this new cgroup/cpuset:
  # echo 1364 > tasks 
  # cat tasks 
  1364

5. List the threads showing its cgroup/cpuset:
  # ps -eLo pid,lwp,comm,cgroup | grep audit
   1025  1025 kauditd         cpuset:/
   1364  1364 auditd          cpuset:/app
   1364  1365 auditd          cpuset:/app

Actual results:
ps shows all threads in the same cgroup/cpuset, but they are not in the same cgroup/cpuset.

Expected results:
ps showing the correct cgroup/cpuset for threads.

Additional info:

Stracing the ps, it the following:
  It opens the proc/PID/ dir and checks the status of the proc.
	stat("/proc/1364", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
	open("/proc/1364/stat", O_RDONLY)       = 5
	read(5, "1364 (auditd) S 1 1364 1364 0 -1"..., 1023) = 249
	close(5)                                = 0
	open("/proc/1364/status", O_RDONLY)     = 5
	read(5, "Name:\tauditd\nState:\tS (sleeping)"..., 1023) = 870
	close(5)                                = 0

  It checks the threads of the proc:
	open("/proc/1364/task", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
	getdents(5, /* 4 entries */, 32768)     = 96

  It checks first thread:
	stat("/proc/1364/task/1364", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
	open("/proc/1364/task/1364/stat", O_RDONLY) = 6
	read(6, "1364 (auditd) S 1 1364 1364 0 -1"..., 1023) = 249
	close(6)                                = 0
	open("/proc/1364/task/1364/status", O_RDONLY) = 6
	read(6, "Name:\tauditd\nState:\tS (sleeping)"..., 1023) = 870
	close(6)                                = 0

  Then it checks the cgroup file of the process (not the thread)
	open("/proc/1364/cgroup", O_RDONLY)     = 6
	fstat(6, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
	mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5a8567f000
	read(6, "1:cpuset:/\n", 1024)           = 11
	read(6, "", 1024)                       = 0
	close(6)                                = 0
	munmap(0x7f5a8567f000, 4096)            = 0
	write(1, " 1364  1364 auditd          cpus"..., 37) = 37

  It checks first thread:
	stat("/proc/1364/task/1365", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
	open("/proc/1364/task/1365/stat", O_RDONLY) = 6
	read(6, "1365 (auditd) S 1 1364 1364 0 -1"..., 1023) = 252
	close(6)                                = 0
	open("/proc/1364/task/1365/status", O_RDONLY) = 6
	read(6, "Name:\tauditd\nState:\tS (sleeping)"..., 1023) = 868
	close(6)                                = 0

  Then it checks the cgroup file of the process (not the thread) AGAIN???
	open("/proc/1364/cgroup", O_RDONLY)     = 6
	fstat(6, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
	mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5a8567f000
	read(6, "1:cpuset:/\n", 1024)           = 11
	read(6, "", 1024)                       = 0
	close(6)                                = 0
	munmap(0x7f5a8567f000, 4096)            = 0
	write(1, " 1364  1365 auditd          cpus"..., 37) = 37
	getdents(5, /* 0 entries */, 32768)     = 0

  Than, it goes to the next thread....
	stat("/proc/1398", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0


IMHO, the "open("/proc/1364/cgroup", O_RDONLY)" twice in the same file is the
problem, I think that it was inteded to open the "/proc/PID/tasks/TID/cgroup"
file, and not the "/proc/PID/cgroup" file.