linux-kernel - Re: [ckrm-tech] [PATCH 1/7] containers (V7): Generic container system abstracted from cpusets code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070325004529.GD11794@in.ibm.com>
Date:	Sun, 25 Mar 2007 06:15:29 +0530
From:	Srivatsa Vaddagiri <vatsa@...ibm.com>
To:	Paul Jackson <pj@....com>
Cc:	sekharan@...ibm.com, ckrm-tech@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, xemul@...ru, dev@...ru,
	rohitseth@...gle.com, ebiederm@...ssion.com, mbligh@...gle.com,
	winget@...gle.com, containers@...ts.osdl.org, serue@...ibm.com,
	menage@...gle.com, devel@...nvz.org
Subject: Re: [ckrm-tech] [PATCH 1/7] containers (V7): Generic container system abstracted from cpusets code

On Sat, Mar 24, 2007 at 12:25:59PM -0700, Paul Jackson wrote:
> > P.S : cpuset.c checks for PF_EXITING twice in attach_task(), while this
> > patch seems to be checking only once. Is that fine?
> 
> I think the cpuset code is ok, because, as you note, it locks the task,
> picks off the cpuset pointer, and then checks a second time that the
> task still does not have PF_EXITING set:

Well afaics, PF_EXITING is set for the exiting task w/o taking any lock, which
makes this racy always.

> In the kernel/cpuset.c code for attach_task():
> 
>         task_lock(tsk);
>         oldcs = tsk->cpuset;
>         /*
>          * After getting 'oldcs' cpuset ptr, be sure still not exiting.
>          * If 'oldcs' might be the top_cpuset due to the_top_cpuset_hack
>          * then fail this attach_task(), to avoid breaking top_cpuset.count.
>          */
>         if (tsk->flags & PF_EXITING) {

What if PF_EXITING is set after this check? If that happens then,

>                 task_unlock(tsk);
>                 mutex_unlock(&callback_mutex);
>                 put_task_struct(tsk);
>                 return -ESRCH;
>         }

the following code becomes racy with cpuset_exit() ...

        atomic_inc(&cs->count);
        rcu_assign_pointer(tsk->cpuset, cs);
        task_unlock(tsk);


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