linux-kernel - Re: [RFC, PATCH 0/5] Going forward with Resource Management

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: <1154970846.31962.17.camel@galaxy.corp.google.com>
Date:	Mon, 07 Aug 2006 10:14:06 -0700
From:	Rohit Seth <rohitseth@...gle.com>
To:	Kirill Korotaev <dev@...ru>
Cc:	vatsa@...ibm.com, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andrew Morton <akpm@...l.org>, mingo@...e.hu,
	nickpiggin@...oo.com.au, sam@...ain.net,
	linux-kernel@...r.kernel.org, dev@...nvz.org, efault@....de,
	balbir@...ibm.com, sekharan@...ibm.com, nagar@...son.ibm.com,
	haveblue@...ibm.com, pj@....com
Subject: Re: [RFC, PATCH 0/5] Going forward with Resource Management -
	A	cpu controller

On Mon, 2006-08-07 at 11:19 +0400, Kirill Korotaev wrote:
> >>>Doesnt the ability to move tasks between groups dynamically affect
> >>>(atleast) memory controller design (in giving up ownership etc)?
> >>
> >>we save object owner on the object. So if you change the container,
> >>objects are still correctly charged to the creator and are uncharged
> >>correctly on free.
> >>
> > 
> > 
> > Seems like the object owner should also change when the object moves
> > from one container to another.

> Consider a file which is opened in 2 processes. one of the processes
> wants to move to another container then. How would you decide whether
> to change the file owner or not?
> 

If a process has sufficient rights to move a file to a new container
then it should be okay to assign the file to the new container.  

Though the point is, if a resource (like file) is getting migrated to a
new container then all the attributes (like owner, #pages in memory
etc.) attached to that resource (file) should also migrate to this new
container.  Otherwise the semantics of where does the resource belong
becomes very difficult.

And if you really want a resource to not be able to migrate from one
container then we could define IMMUTABLE flag to indicate that behavior.

-rohit

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