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>] [day] [month] [year] [list]
Message-ID: <20070411164253.GA26228@in.ibm.com>
Date:	Wed, 11 Apr 2007 22:12:53 +0530
From:	Srivatsa Vaddagiri <vatsa@...ibm.com>
To:	menage@...gle.com
Cc:	akpm@...ux-foundation.org, sekharan@...ibm.com, dev@...ru,
	xemul@...ru, serue@...ibm.com, ebiederm@...ssion.com,
	ckrm-tech@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
	containers@...ts.osdl.org, mbligh@...gle.com, rohitseth@...gle.com,
	devel@...nvz.org
Subject: Re: [PATCH 3/7] Containers (V8): Add generic multi-subsystem API to containers

Coming from a "simplify things" pov:

On Fri, Apr 06, 2007 at 04:32:24PM -0700, menage@...gle.com wrote:
>  struct container {
>  	unsigned long flags;		/* "unsigned long" so bitops work */
> 
>  	/*
> -	 * Count is atomic so can incr (fork) or decr (exit) without a lock.
> -	 */
> -	atomic_t count;			/* count tasks using this container */
> -
> -	/*
>  	 * We link our 'sibling' struct into our parent's 'children'.
>  	 * Our children link their 'sibling' into our 'children'.
>  	 */
> @@ -43,11 +106,13 @@ struct container {
>  	struct list_head children;	/* my children */
> 
>  	struct container *parent;	/* my parent */
> -	struct dentry *dentry;		/* container fs entry */
> +	struct dentry *dentry;	  	/* container fs entry */
> 
> -#ifdef CONFIG_CPUSETS
> -	struct cpuset *cpuset;
> -#endif
> +	/* Private pointers for each registered subsystem */
> +	struct container_subsys_state *subsys[CONTAINER_SUBSYS_COUNT];
> +
> +	struct containerfs_root *root;

Could this root pointer derived from dentry pointer
(cont->dentry->d_sb->s_fs_info)?

> +	struct container *top_container;

and this as well?

	cont->dentry->d_sb->s_fs_info->top_container

>  };

So we have the foward subsys pointer array being stored in both 
'struct container' and 'struct container_group' and reverse container pointer 
stored in struct container_subsys_state. Can we reduce this pointer maze by:

	struct container {
		/* All shared stuff like flags, parent/child pointers etc */
		..

		struct container_group *my_group;
		
	}

The forward mapping from 'struct container' to subsys objects is made via
'my_group'. This also lets 'struct container' be a placeholder strictly for
shared state. 

On further thoughts, perhaps even my_group can be avoided by having:

	dentry->d_fsdata point to my_group 

and cont->dentry->d_fsdata will point to my_group which we wanted to store
above.

I don't see distinct adv of doing this, but I suspect it will simplify
the structure relationship (and code) a bit.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ