Eddy A. Latham | 1 Aug 01:59 2007

Notification


Attachment (Notification.zip): application/octet-stream, 12 KiB
_______________________________________________
Containers mailing list
Containers@...
https://lists.linux-foundation.org/mailman/listinfo/containers

CAPWIP's 8th MGGR Training, 12-19 November 2007, Manila, Philippines

Dear Colleagues and Friends,

Greetings from the Center for Asia Pacific Women in Politics (CAPWIP) Institute for Gender, Governance &
Leadership! 

We are pleased to invite you to the 8th training on "Making Governance Gender Responsive (MGGR)", which
will be held on November 12-19, 2007 in Manila, Philippines. 

The course is designed for parliamentarians, middle and senior level government executives and
officials, women and men in local governments, political parties, research and training institutes and
civil society organizations and non-government organizations who are leading or participating in
governance reform initiatives in their respective countries.

The objectives of the training are the following: 

-	Enhance their understanding of Gender and Development (GAD) and governance concepts;
-	Gain appreciation of gender-related and governance issues and concerns;
-	Identify gender biases in governance;
-	Acquire skills in identifying and analyzing gender biases and concerns through case examples of
strategies and practices to address gender biases;
-	Identify gender biases in the participant's sphere of influence-A Change Management Approach; and
-	Formulate Action Plans: Institutional and Individual 

The course is composed of modules developed to enhance the participants' understanding of the link
between gender and governance, as well as increase their awareness of gender biases in governance.

This is the eight-time (8th time) that we are offering this course within the last three (3) years.  The seven
(7) batches of MGGR trainings were successfully held last February, June, October of 2004, January and
October of 2005, February and June of 2007 at the CAPWIP Institute for Gender, Governance and Leadership
(CIGGL) located at Hostelling (HI) Manila, 4227-4229 Tomas Claudio Street, Baclaran, Paranaque City,
(Continue reading)

Samantha Bowling | 1 Aug 06:14 2007
Picon

Problems with erection?


_______________________________________________
Containers mailing list
Containers@...
https://lists.linux-foundation.org/mailman/listinfo/containers
sukadev | 1 Aug 08:16 2007
Picon

Re: [PATCH 14/15] Destroy pid namespace on init's death

Oleg Nesterov [oleg@...] wrote:
| On 07/30, sukadev@... wrote:
| >
| > --- lx26-23-rc1-mm1.orig/kernel/exit.c	2007-07-26 20:08:16.000000000 -0700
| > +++ lx26-23-rc1-mm1/kernel/exit.c	2007-07-30 23:10:30.000000000 -0700
| >  <at>  <at>  -915,6 +915,7  <at>  <at>  fastcall NORET_TYPE void do_exit(long co
| >  {
| >  	struct task_struct *tsk = current;
| >  	int group_dead;
| > +	struct pid_namespace *pid_ns = tsk->nsproxy->pid_ns;
| >  
| >  	profile_task_exit(tsk);
| >  
| >  <at>  <at>  -925,9 +926,10  <at>  <at>  fastcall NORET_TYPE void do_exit(long co
| >  	if (unlikely(!tsk->pid))
| >  		panic("Attempted to kill the idle task!");
| >  	if (unlikely(tsk == task_child_reaper(tsk))) {
| > -		if (task_active_pid_ns(tsk) != &init_pid_ns)
| > -			task_active_pid_ns(tsk)->child_reaper =
| > -					init_pid_ns.child_reaper;
| > +		if (pid_ns != &init_pid_ns) {
| > +			zap_pid_ns_processes(pid_ns);
| > +			pid_ns->child_reaper = init_pid_ns.child_reaper;
| > +		}
| >  		else
| >  			panic("Attempted to kill init!");
| >  	}
| 
| Just to remind you, this is not right when init is multi-threaded,
| we should do this only when the last thread exits.
(Continue reading)

Eric W. Biederman | 1 Aug 11:22 2007

Re: [PATCH 06/14] sysfs: Rewrite sysfs_get_dentry

Tejun Heo <htejun@...> writes:

> On Tue, Jul 31, 2007 at 08:34:47PM +0900, Tejun Heo wrote:
>> > If sysfs_mutex nested the other way things would be easier,
>> > and we could grab all of the i_mutexes we wanted.  I wonder if we can
>> > be annoying in sysfs_lookup and treat that as the lock inversion
>> > case using mutex_trylock etc.  And have sysfs_mutex be on the
>> > outside for the rest of the cases?
>> 
>> The problem with treating sysfs_lookup as inversion case is that vfs
>> layer grabs i_mutex outside of sysfs_lookup.  Releasing i_mutex from
>> inside sysfs_lookup would be a hacky layering violation.
>> 
>> Then again, the clean up which can come from the new sysfs_looukp_dentry
>> is very significant.  I'll think about it a bit more.
>
> How about something like this?  __sysfs_get_dentry() never creates any
> dentry, it just looks up existing ones.  sysfs_get_dentry() calls
> __sysfs_get_dentry() and if it fails, it builds a path string and look
> up using regular vfs_path_lookup().  Once in the creation path,
> sysfs_get_dentry() is allowed to fail, so allocating path buf is fine.
>
> It still needs to retry when vfs_path_lookup() returns -ENOENT or the
> wrong dentry but things are much simpler now.  It doesn't violate any
> VFS locking rule while maintaining all the benefits of
> sysfs_get_dentry() cleanup.
>
> Something like LOOKUP_KERNEL is needed to ignore security checks;
> otherwise, we'll need to resurrect lookup_one_len_kern() and open code
> look up.
(Continue reading)

Tejun Heo | 1 Aug 12:02 2007
Picon

Re: [PATCH 06/14] sysfs: Rewrite sysfs_get_dentry

Hello, Eric.

Eric W. Biederman wrote:
> I will look a little more and see.  But right now it looks like the
> real problem with locking is that we use sysfs_mutex to lock the
> sysfs_dirent s_children list.
> 
> Instead it really looks like we should use i_mutex from the appropriate
> inode.  Or is there a real performance problem with forcing the directory
> inodes in core when we modify the directories?

I don't think there is any performance problem.  Problems with using
i_mutex were...

* It was messy.  I don't remember all the details now but IIRC symlink
walk code was pretty complex.

* And more importantly, inodes are reclaimable and might or might not be
there.

--

-- 
tejun
Dave Hansen | 1 Aug 18:00 2007
Picon

Re: [PATCH 14/15] Destroy pid namespace on init's death

On Tue, 2007-07-31 at 23:16 -0700, sukadev@... wrote:
> Oleg Nesterov [oleg@...] wrote:
> | On 07/30, sukadev@... wrote:
> | >
> | > --- lx26-23-rc1-mm1.orig/kernel/exit.c	2007-07-26 20:08:16.000000000 -0700
> | > +++ lx26-23-rc1-mm1/kernel/exit.c	2007-07-30 23:10:30.000000000 -0700
> | >  <at>  <at>  -915,6 +915,7  <at>  <at>  fastcall NORET_TYPE void do_exit(long co
> | >  {
> | >  	struct task_struct *tsk = current;
> | >  	int group_dead;
> | > +	struct pid_namespace *pid_ns = tsk->nsproxy->pid_ns;
> | >  
> | >  	profile_task_exit(tsk);
> | >  
> | >  <at>  <at>  -925,9 +926,10  <at>  <at>  fastcall NORET_TYPE void do_exit(long co
> | >  	if (unlikely(!tsk->pid))
> | >  		panic("Attempted to kill the idle task!");
> | >  	if (unlikely(tsk == task_child_reaper(tsk))) {
> | > -		if (task_active_pid_ns(tsk) != &init_pid_ns)
> | > -			task_active_pid_ns(tsk)->child_reaper =
> | > -					init_pid_ns.child_reaper;
> | > +		if (pid_ns != &init_pid_ns) {
> | > +			zap_pid_ns_processes(pid_ns);
> | > +			pid_ns->child_reaper = init_pid_ns.child_reaper;
> | > +		}
> | >  		else
> | >  			panic("Attempted to kill init!");
> | >  	}
> | 
> | Just to remind you, this is not right when init is multi-threaded,
(Continue reading)

Serge E. Hallyn | 1 Aug 18:13 2007
Picon

Re: [PATCH 11/15] Signal semantics

Quoting Pavel Emelyanov (xemul@...):
> [snip]
> 
> >>| Maybe it's worth disabling cross-namespaces ptracing...
> >>
> >>I think so too. Its probably not a serious limitation ?
> >
> >Several people think we will implement 'namespace entering' through a
> >ptrace hack, where maybe the admin ptraces the init in a child pidns,
> 
> Why not implement namespace entering w/o any hacks? :)

I did, as a patch on top of the nsproxy container subsystem.  The
response was that that is a hack, and ptrace is cleaner  :)

So the current options for namespace entering would be:

	* using Cedric's bind_ns() functionality, which assigns an
	  integer global id to a namespace, and allows a process to
	  enter a namespace by that global id
	* using my nsproxy container subsystem patch, which lets
	  a process enter another namespace using
	  	echo pid > /container/some/cont/directory/tasks
	  and eventually might allow construction of custom
	  namespaces, i.e.
	  	mkdir /container/c1/c2
		ln -s /container/c1/c1/network /container/c1/c2/network
		echo $$ > /container/c1/c2/tasks
	* using ptrace to coerce a process in the target namespace
	  into forking and executing the desired program.
(Continue reading)

Delaney Cordelia | 1 Aug 19:01 2007

e-mail


Attachment (e-mail.zip): application/octet-stream, 19 KiB
_______________________________________________
Containers mailing list
Containers@...
https://lists.linux-foundation.org/mailman/listinfo/containers
Eric W. Biederman | 1 Aug 19:07 2007

Re: [PATCH 06/14] sysfs: Rewrite sysfs_get_dentry

Tejun Heo <htejun@...> writes:

> Hello, Eric.
>
> Eric W. Biederman wrote:
>> I will look a little more and see.  But right now it looks like the
>> real problem with locking is that we use sysfs_mutex to lock the
>> sysfs_dirent s_children list.
>> 
>> Instead it really looks like we should use i_mutex from the appropriate
>> inode.  Or is there a real performance problem with forcing the directory
>> inodes in core when we modify the directories?
>
> I don't think there is any performance problem.  Problems with using
> i_mutex were...
>
> * It was messy.  I don't remember all the details now but IIRC symlink
> walk code was pretty complex.
>
> * And more importantly, inodes are reclaimable and might or might not be
> there.

Yes.  But we can always force inodes into the cache when we need them.
When I complete it I will have to show you a patch using the inode lock
for locking directory modifications.  From what I can tell so far it allows
me to fix the weird lock order problems and generally simplify the locking.

Eric

Gmane