All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
To: Cyrill Gorcunov <gorcunov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	James Bottomley
	<jbottomley-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>,
	containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org,
	Nathan Lynch <ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>,
	Alexey Dobriyan
	<adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Daniel Lezcano <dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>,
	Vasiliy Kulikov <segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org>,
	Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Subject: Re: [patch 2/2] fs, proc: Introduce the /proc/<pid>/map_files/ directory v6
Date: Wed, 7 Sep 2011 15:13:23 -0700	[thread overview]
Message-ID: <20110907151323.613e62e7.akpm@linux-foundation.org> (raw)
In-Reply-To: <20110907215329.GB28162@sun>

On Thu, 8 Sep 2011 01:53:29 +0400
Cyrill Gorcunov <gorcunov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On Wed, Sep 07, 2011 at 03:23:01PM +0400, Vasiliy Kulikov wrote:
> > Hi,
> > 
> > On Wed, Sep 07, 2011 at 02:33 +0900, Tejun Heo wrote:
> > > On Tue, Sep 06, 2011 at 09:29:52PM +0400, Vasiliy Kulikov wrote:
> > > > I agree with you.  I don't think that showing system-global debug
> > > > information to all users by default is the right thing.  But some people
> > > > doesn't agree with this point of view:
> > > > 
> > > > http://thread.gmane.org/gmane.linux.kernel/1108378
> > > 
> > > Yeap, I know there are two sides of the discussion but if one takes
> > > the position that hiding such global debug info is more harmful, it's
> > > only crazier to hide such information from each individual users of
> > > the said global facility.  So, let's just forget about information
> > > leak via freeing or not freeing here.  It's the wrong battle field.
> > 
> > Andrew, are you OK with closing the hole with pid_no_revalidate()
> > and 0600 /proc/slabinfo?  If so, I feel I have to start this discussion
> > with people participating in the discussion above: Theodore, Dan, Linus, etc.

I fell asleep a long time ago and don't know what pid_no_revalidate()
and slabinfo permissions have to do with this.  Perhaps summarising the
issues in the changelog would be appropriate, dunno.

> > By Andrew Morton
> >
> > But do we *really* need to do it in two passes?  Avoiding the temporary
> > storage would involve doing more work under mmap_sem, and a put_filp()
> > under mmap_sem might be problematic.
> 
> I fear we still need to use two passes in proc_map_files_readdir, I found no way
> to escape lockdep complains when doing all work in one pass with mmap_sem taken.
> The /maps does the same thing -- ie it fills maps file with mmap_sem taken to produce
> robust data.

The code's using three passes.

> And I'm not really sure what you mean with problematic put_filp?

I was thinking fput(), which can do a hell of a lot of stuff if it's
the final put on the inode.

>
> ...
>
> +static int proc_map_files_readdir(struct file *filp, void *dirent, filldir_t filldir)
> +{
> +	struct dentry *dentry = filp->f_path.dentry;
> +	struct inode *inode = dentry->d_inode;
> +	struct vm_area_struct *vma;
> +	struct task_struct *task;
> +	struct mm_struct *mm;
> +	ino_t ino;
> +	int ret;
> +
> +	ret = -ENOENT;
> +	task = get_proc_task(inode);
> +	if (!task)
> +		goto out_no_task;
> +
> +	ret = -EPERM;
> +	if (!ptrace_may_access(task, PTRACE_MODE_READ))
> +		goto out;
> +
> +	ret = 0;
> +	switch (filp->f_pos) {
> +	case 0:
> +		ino = inode->i_ino;
> +		if (filldir(dirent, ".", 1, 0, ino, DT_DIR) < 0)
> +			goto out;
> +		filp->f_pos++;
> +	case 1:
> +		ino = parent_ino(dentry);
> +		if (filldir(dirent, "..", 2, 1, ino, DT_DIR) < 0)
> +			goto out;
> +		filp->f_pos++;
> +	default:
> +	{
> +		unsigned long nr_files, used, pos, i;
> +		struct flex_array *fa = NULL;
> +		struct map_files_info info;
> +		struct map_files_info *p;
> +
> +		mm = get_task_mm(task);
> +		if (!mm)
> +			goto out;
> +		down_read(&mm->mmap_sem);
> +
> +		nr_files = 0;
> +		used = 0;
> +
> +		/*
> +		 * We need two passes here:
> +		 *
> +		 *  1) Collect vmas of mapped files with mmap_sem taken
> +		 *  2) Release mmap_sem and instantiate entries
> +		 *
> +		 * otherwise we get lockdep complained, since filldir()
> +		 * routine might require mmap_sem taken in might_fault().
> +		 */
> +
> +		for (vma = mm->mmap; vma; vma = vma->vm_next) {
> +			if (vma->vm_file)
> +				nr_files++;
> +		}
> +
> +		if (nr_files) {
> +			ret = -ENOMEM;
> +			fa = flex_array_alloc(sizeof(info), nr_files, GFP_KERNEL);
> +			if (!fa)
> +				goto err;
> +			if (flex_array_prealloc(fa, 0, nr_files, GFP_KERNEL))
> +				goto err;
> +			for (vma = mm->mmap, pos = 2; vma; vma = vma->vm_next) {
> +				if (!vma->vm_file)
> +					continue;
> +				if (++pos <= filp->f_pos)
> +					continue;
> +
> +				get_file(vma->vm_file);
> +				info.file = vma->vm_file;
> +				info.len = snprintf(info.name, sizeof(info.name),
> +						    "%lx-%lx", vma->vm_start,
> +						    vma->vm_end);
> +				if (flex_array_put(fa, used, &info, GFP_KERNEL)) {
> +					/*
> +					 * This must never happen on preallocated array,
> +					 * but just to be sure.
> +					 */
> +					WARN_ON_ONCE(1);
> +					put_filp(vma->vm_file);
> +					goto err;
> +				}
> +				used++;
> +			}
> +			ret = 0;
> +		}
> +err:
> +		up_read(&mm->mmap_sem);
> +
> +		for (i = 0; i < used && !ret; i++) {

The "&& !ret" is unneeded?

> +			p = flex_array_get(fa, i);
> +			ret = proc_fill_cache(filp, dirent, filldir,
> +					      p->name, p->len,
> +					      proc_map_files_instantiate,
> +					      task, p->file);
> +			if (ret)
> +				break;
> +			filp->f_pos++;
> +			put_filp(p->file);
> +		}
> +
> +		for (; i < used; i++) {
> +			p = flex_array_get(fa, i);
> +			put_filp(p->file);
> +		}

Still unclear why we need the third loop.

> +		if (fa)
> +			flex_array_free(fa);
> +
> +		mmput(mm);
> +	}
> +	}
> +
> +out:
> +	put_task_struct(task);
> +out_no_task:
> +	return ret;
> +}
>
> ...
>

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Vasiliy Kulikov <segoon@openwall.com>, Tejun Heo <tj@kernel.org>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	containers@lists.osdl.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, Nathan Lynch <ntl@pobox.com>,
	kernel-hardening@lists.openwall.com,
	Oren Laadan <orenl@cs.columbia.edu>,
	Daniel Lezcano <dlezcano@fr.ibm.com>,
	Glauber Costa <glommer@parallels.com>,
	James Bottomley <jbottomley@parallels.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Al Viro <viro@ZenIV.linux.org.uk>,
	Pavel Emelyanov <xemul@parallels.com>
Subject: [kernel-hardening] Re: [patch 2/2] fs, proc: Introduce the /proc/<pid>/map_files/ directory v6
Date: Wed, 7 Sep 2011 15:13:23 -0700	[thread overview]
Message-ID: <20110907151323.613e62e7.akpm@linux-foundation.org> (raw)
In-Reply-To: <20110907215329.GB28162@sun>

On Thu, 8 Sep 2011 01:53:29 +0400
Cyrill Gorcunov <gorcunov@gmail.com> wrote:

> On Wed, Sep 07, 2011 at 03:23:01PM +0400, Vasiliy Kulikov wrote:
> > Hi,
> > 
> > On Wed, Sep 07, 2011 at 02:33 +0900, Tejun Heo wrote:
> > > On Tue, Sep 06, 2011 at 09:29:52PM +0400, Vasiliy Kulikov wrote:
> > > > I agree with you.  I don't think that showing system-global debug
> > > > information to all users by default is the right thing.  But some people
> > > > doesn't agree with this point of view:
> > > > 
> > > > http://thread.gmane.org/gmane.linux.kernel/1108378
> > > 
> > > Yeap, I know there are two sides of the discussion but if one takes
> > > the position that hiding such global debug info is more harmful, it's
> > > only crazier to hide such information from each individual users of
> > > the said global facility.  So, let's just forget about information
> > > leak via freeing or not freeing here.  It's the wrong battle field.
> > 
> > Andrew, are you OK with closing the hole with pid_no_revalidate()
> > and 0600 /proc/slabinfo?  If so, I feel I have to start this discussion
> > with people participating in the discussion above: Theodore, Dan, Linus, etc.

I fell asleep a long time ago and don't know what pid_no_revalidate()
and slabinfo permissions have to do with this.  Perhaps summarising the
issues in the changelog would be appropriate, dunno.

> > By Andrew Morton
> >
> > But do we *really* need to do it in two passes?  Avoiding the temporary
> > storage would involve doing more work under mmap_sem, and a put_filp()
> > under mmap_sem might be problematic.
> 
> I fear we still need to use two passes in proc_map_files_readdir, I found no way
> to escape lockdep complains when doing all work in one pass with mmap_sem taken.
> The /maps does the same thing -- ie it fills maps file with mmap_sem taken to produce
> robust data.

The code's using three passes.

> And I'm not really sure what you mean with problematic put_filp?

I was thinking fput(), which can do a hell of a lot of stuff if it's
the final put on the inode.

>
> ...
>
> +static int proc_map_files_readdir(struct file *filp, void *dirent, filldir_t filldir)
> +{
> +	struct dentry *dentry = filp->f_path.dentry;
> +	struct inode *inode = dentry->d_inode;
> +	struct vm_area_struct *vma;
> +	struct task_struct *task;
> +	struct mm_struct *mm;
> +	ino_t ino;
> +	int ret;
> +
> +	ret = -ENOENT;
> +	task = get_proc_task(inode);
> +	if (!task)
> +		goto out_no_task;
> +
> +	ret = -EPERM;
> +	if (!ptrace_may_access(task, PTRACE_MODE_READ))
> +		goto out;
> +
> +	ret = 0;
> +	switch (filp->f_pos) {
> +	case 0:
> +		ino = inode->i_ino;
> +		if (filldir(dirent, ".", 1, 0, ino, DT_DIR) < 0)
> +			goto out;
> +		filp->f_pos++;
> +	case 1:
> +		ino = parent_ino(dentry);
> +		if (filldir(dirent, "..", 2, 1, ino, DT_DIR) < 0)
> +			goto out;
> +		filp->f_pos++;
> +	default:
> +	{
> +		unsigned long nr_files, used, pos, i;
> +		struct flex_array *fa = NULL;
> +		struct map_files_info info;
> +		struct map_files_info *p;
> +
> +		mm = get_task_mm(task);
> +		if (!mm)
> +			goto out;
> +		down_read(&mm->mmap_sem);
> +
> +		nr_files = 0;
> +		used = 0;
> +
> +		/*
> +		 * We need two passes here:
> +		 *
> +		 *  1) Collect vmas of mapped files with mmap_sem taken
> +		 *  2) Release mmap_sem and instantiate entries
> +		 *
> +		 * otherwise we get lockdep complained, since filldir()
> +		 * routine might require mmap_sem taken in might_fault().
> +		 */
> +
> +		for (vma = mm->mmap; vma; vma = vma->vm_next) {
> +			if (vma->vm_file)
> +				nr_files++;
> +		}
> +
> +		if (nr_files) {
> +			ret = -ENOMEM;
> +			fa = flex_array_alloc(sizeof(info), nr_files, GFP_KERNEL);
> +			if (!fa)
> +				goto err;
> +			if (flex_array_prealloc(fa, 0, nr_files, GFP_KERNEL))
> +				goto err;
> +			for (vma = mm->mmap, pos = 2; vma; vma = vma->vm_next) {
> +				if (!vma->vm_file)
> +					continue;
> +				if (++pos <= filp->f_pos)
> +					continue;
> +
> +				get_file(vma->vm_file);
> +				info.file = vma->vm_file;
> +				info.len = snprintf(info.name, sizeof(info.name),
> +						    "%lx-%lx", vma->vm_start,
> +						    vma->vm_end);
> +				if (flex_array_put(fa, used, &info, GFP_KERNEL)) {
> +					/*
> +					 * This must never happen on preallocated array,
> +					 * but just to be sure.
> +					 */
> +					WARN_ON_ONCE(1);
> +					put_filp(vma->vm_file);
> +					goto err;
> +				}
> +				used++;
> +			}
> +			ret = 0;
> +		}
> +err:
> +		up_read(&mm->mmap_sem);
> +
> +		for (i = 0; i < used && !ret; i++) {

The "&& !ret" is unneeded?

> +			p = flex_array_get(fa, i);
> +			ret = proc_fill_cache(filp, dirent, filldir,
> +					      p->name, p->len,
> +					      proc_map_files_instantiate,
> +					      task, p->file);
> +			if (ret)
> +				break;
> +			filp->f_pos++;
> +			put_filp(p->file);
> +		}
> +
> +		for (; i < used; i++) {
> +			p = flex_array_get(fa, i);
> +			put_filp(p->file);
> +		}

Still unclear why we need the third loop.

> +		if (fa)
> +			flex_array_free(fa);
> +
> +		mmput(mm);
> +	}
> +	}
> +
> +out:
> +	put_task_struct(task);
> +out_no_task:
> +	return ret;
> +}
>
> ...
>

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Vasiliy Kulikov <segoon@openwall.com>, Tejun Heo <tj@kernel.org>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	containers@lists.osdl.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, Nathan Lynch <ntl@pobox.com>,
	kernel-hardening@lists.openwall.com,
	Oren Laadan <orenl@cs.columbia.edu>,
	Daniel Lezcano <dlezcano@fr.ibm.com>,
	Glauber Costa <glommer@parallels.com>,
	James Bottomley <jbottomley@parallels.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Al Viro <viro@ZenIV.linux.org.uk>,
	Pavel Emelyanov <xemul@parallels.com>
Subject: Re: [patch 2/2] fs, proc: Introduce the /proc/<pid>/map_files/ directory v6
Date: Wed, 7 Sep 2011 15:13:23 -0700	[thread overview]
Message-ID: <20110907151323.613e62e7.akpm@linux-foundation.org> (raw)
In-Reply-To: <20110907215329.GB28162@sun>

On Thu, 8 Sep 2011 01:53:29 +0400
Cyrill Gorcunov <gorcunov@gmail.com> wrote:

> On Wed, Sep 07, 2011 at 03:23:01PM +0400, Vasiliy Kulikov wrote:
> > Hi,
> > 
> > On Wed, Sep 07, 2011 at 02:33 +0900, Tejun Heo wrote:
> > > On Tue, Sep 06, 2011 at 09:29:52PM +0400, Vasiliy Kulikov wrote:
> > > > I agree with you.  I don't think that showing system-global debug
> > > > information to all users by default is the right thing.  But some people
> > > > doesn't agree with this point of view:
> > > > 
> > > > http://thread.gmane.org/gmane.linux.kernel/1108378
> > > 
> > > Yeap, I know there are two sides of the discussion but if one takes
> > > the position that hiding such global debug info is more harmful, it's
> > > only crazier to hide such information from each individual users of
> > > the said global facility.  So, let's just forget about information
> > > leak via freeing or not freeing here.  It's the wrong battle field.
> > 
> > Andrew, are you OK with closing the hole with pid_no_revalidate()
> > and 0600 /proc/slabinfo?  If so, I feel I have to start this discussion
> > with people participating in the discussion above: Theodore, Dan, Linus, etc.

I fell asleep a long time ago and don't know what pid_no_revalidate()
and slabinfo permissions have to do with this.  Perhaps summarising the
issues in the changelog would be appropriate, dunno.

> > By Andrew Morton
> >
> > But do we *really* need to do it in two passes?  Avoiding the temporary
> > storage would involve doing more work under mmap_sem, and a put_filp()
> > under mmap_sem might be problematic.
> 
> I fear we still need to use two passes in proc_map_files_readdir, I found no way
> to escape lockdep complains when doing all work in one pass with mmap_sem taken.
> The /maps does the same thing -- ie it fills maps file with mmap_sem taken to produce
> robust data.

The code's using three passes.

> And I'm not really sure what you mean with problematic put_filp?

I was thinking fput(), which can do a hell of a lot of stuff if it's
the final put on the inode.

>
> ...
>
> +static int proc_map_files_readdir(struct file *filp, void *dirent, filldir_t filldir)
> +{
> +	struct dentry *dentry = filp->f_path.dentry;
> +	struct inode *inode = dentry->d_inode;
> +	struct vm_area_struct *vma;
> +	struct task_struct *task;
> +	struct mm_struct *mm;
> +	ino_t ino;
> +	int ret;
> +
> +	ret = -ENOENT;
> +	task = get_proc_task(inode);
> +	if (!task)
> +		goto out_no_task;
> +
> +	ret = -EPERM;
> +	if (!ptrace_may_access(task, PTRACE_MODE_READ))
> +		goto out;
> +
> +	ret = 0;
> +	switch (filp->f_pos) {
> +	case 0:
> +		ino = inode->i_ino;
> +		if (filldir(dirent, ".", 1, 0, ino, DT_DIR) < 0)
> +			goto out;
> +		filp->f_pos++;
> +	case 1:
> +		ino = parent_ino(dentry);
> +		if (filldir(dirent, "..", 2, 1, ino, DT_DIR) < 0)
> +			goto out;
> +		filp->f_pos++;
> +	default:
> +	{
> +		unsigned long nr_files, used, pos, i;
> +		struct flex_array *fa = NULL;
> +		struct map_files_info info;
> +		struct map_files_info *p;
> +
> +		mm = get_task_mm(task);
> +		if (!mm)
> +			goto out;
> +		down_read(&mm->mmap_sem);
> +
> +		nr_files = 0;
> +		used = 0;
> +
> +		/*
> +		 * We need two passes here:
> +		 *
> +		 *  1) Collect vmas of mapped files with mmap_sem taken
> +		 *  2) Release mmap_sem and instantiate entries
> +		 *
> +		 * otherwise we get lockdep complained, since filldir()
> +		 * routine might require mmap_sem taken in might_fault().
> +		 */
> +
> +		for (vma = mm->mmap; vma; vma = vma->vm_next) {
> +			if (vma->vm_file)
> +				nr_files++;
> +		}
> +
> +		if (nr_files) {
> +			ret = -ENOMEM;
> +			fa = flex_array_alloc(sizeof(info), nr_files, GFP_KERNEL);
> +			if (!fa)
> +				goto err;
> +			if (flex_array_prealloc(fa, 0, nr_files, GFP_KERNEL))
> +				goto err;
> +			for (vma = mm->mmap, pos = 2; vma; vma = vma->vm_next) {
> +				if (!vma->vm_file)
> +					continue;
> +				if (++pos <= filp->f_pos)
> +					continue;
> +
> +				get_file(vma->vm_file);
> +				info.file = vma->vm_file;
> +				info.len = snprintf(info.name, sizeof(info.name),
> +						    "%lx-%lx", vma->vm_start,
> +						    vma->vm_end);
> +				if (flex_array_put(fa, used, &info, GFP_KERNEL)) {
> +					/*
> +					 * This must never happen on preallocated array,
> +					 * but just to be sure.
> +					 */
> +					WARN_ON_ONCE(1);
> +					put_filp(vma->vm_file);
> +					goto err;
> +				}
> +				used++;
> +			}
> +			ret = 0;
> +		}
> +err:
> +		up_read(&mm->mmap_sem);
> +
> +		for (i = 0; i < used && !ret; i++) {

The "&& !ret" is unneeded?

> +			p = flex_array_get(fa, i);
> +			ret = proc_fill_cache(filp, dirent, filldir,
> +					      p->name, p->len,
> +					      proc_map_files_instantiate,
> +					      task, p->file);
> +			if (ret)
> +				break;
> +			filp->f_pos++;
> +			put_filp(p->file);
> +		}
> +
> +		for (; i < used; i++) {
> +			p = flex_array_get(fa, i);
> +			put_filp(p->file);
> +		}

Still unclear why we need the third loop.

> +		if (fa)
> +			flex_array_free(fa);
> +
> +		mmput(mm);
> +	}
> +	}
> +
> +out:
> +	put_task_struct(task);
> +out_no_task:
> +	return ret;
> +}
>
> ...
>

  reply	other threads:[~2011-09-07 22:13 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-31  7:58 [patch 0/2] Introduce /proc/pid/map_files v6 Cyrill Gorcunov
2011-08-31  7:58 ` [patch 1/2] fs, proc: Make proc_get_link to use dentry instead of inode Cyrill Gorcunov
2011-08-31  7:58 ` [patch 2/2] fs, proc: Introduce the /proc/<pid>/map_files/ directory v6 Cyrill Gorcunov
2011-08-31  9:06   ` Vasiliy Kulikov
2011-08-31 10:12     ` Cyrill Gorcunov
2011-08-31 11:26     ` Cyrill Gorcunov
2011-08-31 14:04       ` Kirill A. Shutemov
2011-08-31 14:09         ` Cyrill Gorcunov
2011-08-31 14:26         ` Cyrill Gorcunov
2011-08-31 22:10           ` Andrew Morton
2011-09-01  3:07             ` Kyle Moffett
2011-09-01  3:07               ` Kyle Moffett
2011-09-01  7:58             ` Pavel Emelyanov
2011-09-01 11:50               ` Tejun Heo
2011-09-01 12:13                 ` Pavel Emelyanov
2011-09-01 17:13                   ` Tejun Heo
2011-09-02 19:15                     ` Matt Helsley
2011-09-02  0:09               ` Matt Helsley
2011-09-01  8:05             ` Cyrill Gorcunov
2011-09-02 16:37               ` Vasiliy Kulikov
2011-09-02 16:37                 ` [kernel-hardening] " Vasiliy Kulikov
2011-09-05 18:53                 ` Vasiliy Kulikov
2011-09-05 18:53                   ` [kernel-hardening] " Vasiliy Kulikov
2011-09-05 19:20                   ` Cyrill Gorcunov
2011-09-05 19:20                     ` [kernel-hardening] " Cyrill Gorcunov
2011-09-05 19:49                     ` Vasiliy Kulikov
2011-09-05 19:49                       ` [kernel-hardening] " Vasiliy Kulikov
2011-09-05 20:36                       ` Cyrill Gorcunov
2011-09-05 20:36                         ` [kernel-hardening] " Cyrill Gorcunov
2011-09-06 10:15                         ` Vasiliy Kulikov
2011-09-06 10:15                           ` [kernel-hardening] " Vasiliy Kulikov
2011-09-06 16:51                           ` Tejun Heo
2011-09-06 16:51                             ` [kernel-hardening] " Tejun Heo
2011-09-06 17:29                             ` Vasiliy Kulikov
2011-09-06 17:29                               ` [kernel-hardening] " Vasiliy Kulikov
2011-09-06 17:33                               ` Tejun Heo
2011-09-06 17:33                                 ` [kernel-hardening] " Tejun Heo
2011-09-06 18:15                                 ` Cyrill Gorcunov
2011-09-06 18:15                                   ` [kernel-hardening] " Cyrill Gorcunov
     [not found]                                 ` <20110906173341.GM18425-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2011-09-07 11:23                                   ` Vasiliy Kulikov
2011-09-07 11:23                                     ` [kernel-hardening] " Vasiliy Kulikov
2011-09-07 21:53                                     ` Cyrill Gorcunov
2011-09-07 21:53                                       ` [kernel-hardening] " Cyrill Gorcunov
2011-09-07 22:13                                       ` Andrew Morton [this message]
2011-09-07 22:13                                         ` Andrew Morton
2011-09-07 22:13                                         ` [kernel-hardening] " Andrew Morton
2011-09-07 22:42                                         ` Cyrill Gorcunov
2011-09-07 22:42                                           ` [kernel-hardening] " Cyrill Gorcunov
2011-09-07 22:53                                           ` Andrew Morton
2011-09-07 22:53                                             ` Andrew Morton
2011-09-07 22:53                                             ` [kernel-hardening] " Andrew Morton
2011-09-08  5:48                                             ` Cyrill Gorcunov
2011-09-08  5:48                                               ` [kernel-hardening] " Cyrill Gorcunov
2011-09-08  5:50                                               ` Cyrill Gorcunov
2011-09-08  5:50                                                 ` [kernel-hardening] " Cyrill Gorcunov
2011-09-08  6:04                                                 ` Cyrill Gorcunov
2011-09-08  6:04                                                   ` [kernel-hardening] " Cyrill Gorcunov
2011-09-08 23:52                                                   ` Andrew Morton
2011-09-08 23:52                                                     ` Andrew Morton
2011-09-08 23:52                                                     ` [kernel-hardening] " Andrew Morton
2011-09-09  0:24                                                     ` Pavel Emelyanov
2011-09-09  0:24                                                       ` [kernel-hardening] " Pavel Emelyanov
2011-09-09  5:48                                                     ` Cyrill Gorcunov
2011-09-09  5:48                                                       ` [kernel-hardening] " Cyrill Gorcunov
2011-09-09  6:00                                                       ` Andrew Morton
2011-09-09  6:00                                                         ` [kernel-hardening] " Andrew Morton
2011-09-09  6:22                                                         ` Cyrill Gorcunov
2011-09-09  6:22                                                           ` [kernel-hardening] " Cyrill Gorcunov
2011-09-10 13:21                                                   ` Vasiliy Kulikov
2011-09-10 13:49                                                     ` Cyrill Gorcunov
2011-09-01 10:46             ` Cyrill Gorcunov
2011-09-01 22:49               ` Andrew Morton
2011-09-01 23:04                 ` Tejun Heo
2011-09-02  5:54                   ` Cyrill Gorcunov
2011-09-02  5:53                 ` Cyrill Gorcunov
2011-08-31 22:50           ` Andrew Morton
2011-09-02  1:54   ` Nicholas Miell
2011-09-02  1:58     ` Tejun Heo
2011-09-02  2:04       ` Nicholas Miell
2011-09-02  2:29         ` Tejun Heo
2011-09-02  8:07           ` Kirill A. Shutemov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110907151323.613e62e7.akpm@linux-foundation.org \
    --to=akpm-de/tnxtf+jlsfhdxvbkv3wd2fqjk+8+b@public.gmane.org \
    --cc=adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
    --cc=dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org \
    --cc=gorcunov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=jbottomley-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
    --cc=kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org \
    --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org \
    --cc=segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org \
    --cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
    --cc=xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.