linux-kernel - Re: [Fwd: [-mm] Add an owner to the mm

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: <20080417161936.GB4482@tv-sign.ru>
Date:	Thu, 17 Apr 2008 20:19:36 +0400
From:	Oleg Nesterov <oleg@...sign.ru>
To:	Paul Menage <menage@...gle.com>
Cc:	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>, serue@...ibm.com,
	penberg@...helsinki.fi, linux-kernel@...r.kernel.org
Subject: Re: [Fwd: [-mm] Add an owner to the mm_struct (v9)]

On 04/17, Paul Menage wrote:
>
> On Thu, Apr 17, 2008 at 4:30 AM, Oleg Nesterov <oleg@...sign.ru> wrote:
> >  >
> >  > I had this loop earlier (inspired from zap_threads()), is this loop more
> >  > efficient than what we have?
> >
> >  All sub-threads have the same ->mm. Once we see that c->mm != mm, we don't
> >  need to waste CPU iterating over the all other threads in the thread group.
> 
> Technically they don't have to have the same mm, right? You can use
> CLONE_THREAD without CLONE_VM when creating a new subthread.

No, no, this is not possible/allowed.

Please look at copy_process, CLONE_THREAD requires CLONE_SIGHAND,
CLONE_SIGHAND needs CLONE_VM.

> >  chance you have the "for dummies" explanation what mm->owner is?
> >  I mean, I can't understand how it is possible that 2 CLONE_VM tasks
> >  are not equal wrt "ownering".
> 
> The idea is to be able to get from an mm to a task, where that task is
> representative of the tasks using the mm. Uses include:

Thanks! but...

Let's suppose 2 task belongs to different cgroups, but share ->mm,

> - swap cgroup - when swapping from an mm, find a task whose swap
> cgroup we can charge the swap page to

now we will charge the somewhat "random" cgroup. The one to which
the result of the last "find the next suitable owner" belongs.

This looks a bit strange to me... but OK, as I said, I don't know
what cgroup is, please ignore me ;)

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/