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] [day] [month] [year] [list]
Date:	Sun, 8 Sep 2013 18:00:07 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	김은기 <eunki_kim@...sung.com>,
	linux-kernel@...r.kernel.org, Li Zefan <lizefan@...wei.com>,
	containers@...ts.linux-foundation.org, cgroups@...r.kernel.org
Subject: Re: CGROUP 관련 문의

Hi Tejun,

Sorry for delay, vacation.

On 08/28, Tejun Heo wrote:
>
> Hey, oleg.
>
> Eunki is reporting a stall in the following loop in
> kernel/cgroup.c::cgroup_attach_task()
>
> On Wed, Aug 28, 2013 at 05:19:57AM +0000, 김은기 wrote:
> >
> >      ---------------------------------------------------------------------------
> >         rcu_read_lock();
> >         do {
> >                 struct task_and_cgroup ent;
> >
> >                 /* @tsk either already exited or can't exit until the end */
> >                 if (tsk->flags & PF_EXITING)
> >                         continue;
> >
> >                 /* as per above, nr_threads may decrease, but not increase. */
> >                 BUG_ON(i >= group_size);
> >                 ent.task = tsk;
> >                 ent.cgrp = task_cgroup_from_root(tsk, root);
> >                 /* nothing to do if this task is already in the cgroup */
> >                 if (ent.cgrp == cgrp)
> >                         continue;
> >                 /*
> >                  * saying GFP_ATOMIC has no effect here because we did prealloc
> >                  * earlier, but it's good form to communicate our expectations.
> >                  */
> >                 retval = flex_array_put(group, i, &ent, GFP_ATOMIC);
> >                 BUG_ON(retval != 0);
> >                 i++;
> >
> >                 if (!threadgroup)
> >                         break;
> >         } while_each_thread(leader, tsk);
> > ---------------------------------------------------------------------------------------------
>
> where the iteration goes like
>
>   leader -> Task1 -> Task2 -> Task3  -> Task1
>
> ie. leader seems RCU unlinked.  Looking at the users of
> while_each_thread(), I'm confused about its locking requirements.

In short: it is broken. This was already discussed several times but
every time I was distracted.

I already have the patches somewhere (probably not 100% finished),
will try to return to this problem soon.

Oleg.

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ