gmane.linux.kernel.containers

Re: [GIT PULL] user namespace enhancements for Linux 3.5-rc1

Colin Walters — 2012-05-24T21:22:06


What system?  I'm curious about the state of your userspace
modifications.

[PATCH] cgroup: superblock can't be released with active dentries

Tejun Heo — 2012-05-24T15:41:39

From 88787c483106c5830a46d18deaffdc1e70929af7 Mon Sep 17 00:00:00 2001
From: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A< at >public.gmane.org>
Date: Thu, 24 May 2012 08:24:39 -0700

48ddbe1946 "cgroup: make css->refcnt clearing on cgroup removal
optional" allowed a css to linger after the associated cgroup is
removed.  As a css holds a reference on the cgroup's dentry, it means
that cgroup dentries may linger for a while.

cgroup_create() does grab an active reference on the superblock to
prevent it from going away while there are !root cgroups; however, the
reference is put from cgroup_diput() which is invoked on cgroup
removal, so cgroup dentries which are removed but persisting due to
lingering csses already have released their superblock active refs
allowing superblock to be killed while those dentries are around.

Given the right condition, this makes cgroup_kill_sb() call
kill_litter_super() with dentries with non-zero d_count leading to
BUG() in shrink_dcache_for_umount_subtree().

Fix it by adding cgroup_dops->

Re: [PATCH 2/2] cgroup: make css->refcnt clearing on cgroup removaloptional

Sasha Levin — 2012-05-24T13:21:20

Yup, that did the trick.

Thanks!

Let Us Invest This Fund With You. Get Back

Mr.Christopher — 2012-05-23T16:03:48

Greetings,
I wish to invest with you, I have $65 Million US dollars that I want  to move out secretly for investment purpose in your country but I need  a good partner I can trust. This fund is legal.
This is a dormant account from the previous past Libyan regime leaving  no trace behind. But the question is can I trust you when the funds gets to you? You will take your 30% for the assistance and keep the remaining for us in a safe custody.
Regards 
Mr. Christopher Field

Re: [PATCH 2/2] cgroup: make css->refcnt clearing on cgroup removaloptional

Tejun Heo — 2012-05-23T22:22:42

Hello, Sasha.

Does the following patch fix the problem you're seeing?

Thanks.

---
 kernel/cgroup.c |   17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index ad8eae5..7cf9669 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
< at >< at > -896,10 +896,13 < at >< at > static void cgroup_diput(struct dentry *dentry, struct inode *inode)
 mutex_unlock(&cgroup_mutex);
 
 /*
- * Drop the active superblock reference that we took when we
- * created the cgroup
+ * We want to drop the active superblock reference that we
+ * took when we created the cgroup after all dentry refs
+ * are gone - kill_sb gets mighty unhappy otherwise.  Set
+ * dentry->d_fsdata to cgroup_diput() to tell
+ * cgroup_d_release() to call deactivate_super().
  */
-deactivate_super(cgrp->root->sb);
+dentry->d_fsdata = cgroup_diput;
 
 /*
  * if we're getting rid of the cgroup, refcount should ensure
< at >< at > -925,6 +928,13 < at >< at > static int cgroup_delete(const struct dentry

[GIT PULL] user namespace enhancements for Linux 3.5-rc1

Eric W. Biederman — 2012-05-22T18:48:47

Linus,

please pull user namespace enhancements for v3.5-rc1 from:

git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-linus

The tree is against v3.4-rc1 aka dd775ae2549217d3ae09363e3edb305d0fa19928
The topmost commit is 4b06a81f1daee668fbd6de85557bfb36dd36078f

This is a course correction for the user namespace, so that we can reach
an inexpensive, maintainable, and reasonably complete implementation.

Highlights.
- Config guards make it impossible to enable the user namespace and
  code that has not been converted to be user namespace safe.

- Use of the new kuid_t type ensures the if you somehow get past the
  config guards the kernel will encounter type errors if you enable user
  namespaces and attempt to compile in code whose permission checks have
  not been updated to be user namespace safe.

- All uids from child user namespaces are mapped into the initial user
  namespace before they are processed.  Removing the need to add an
  additional check to see if the user names

[GIT PULL] cgroup changes for 3.5-rc1

Tejun Heo — 2012-05-22T17:34:50

Hello, Linus.

Please pull from the following branch to receive cgroup changes for
3.5-rc1.

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-3.5

cgroup file type addition / removal is updated so that file types are
added and removed instead of individual files so that dynamic file
type addition / removal can be implemented by cgroup and used by
controllers.  blkio controller changes which will come through block
tree are dependent on this.  Other changes include res_counter cleanup
and disallowing kthread / PF_THREAD_BOUND threads to be attached to
non-root cgroups.

There's a reported bug with the file type addition / removal handling
which can lead to oops on cgroup umount.  The issue is being looked
into.  It shouldn't cause problems for most setups and isn't a
security concern.

Merging with mainline causes a conflict in
feature-removal-schedule.txt.  Simple append collision which can be
trivially resolved.

Thanks.

Frederic Weisbecker (2):
      res_counter: Merge res_counter_charge

Re: [PATCH] cgroup: fix device deny of DEV_ALL

Serge Hallyn — 2012-05-22T12:48:31

Quoting Amos Kong (akong-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org):

Because until now, (apart from the special case 'a',) the devices.deny
rules have been very simple - you have to match an exact existing entry
as seen in devices.list.

I guess that was never explicitly written anywhere.  So the only reason
not to change it (apart from simplicity) is that, if I happen to have

a *:* rwm

and accidentally give myself

for seq in `1 254`; do
echo "b *:$i rwm" > devices.allow
done

and want to undo it, now i can't remove those without also removing
a *:* rwm.  (which I might not be able to get back)


Well, in light of morning, I'm not so sure this is bad.  It doesn't fit
with what I am saying above that I wanted :)  But if I had 'a *:* rwm'
and I say I don't want to be able to rw to b 254:3, then leaving me
with only 'a *:* m' does achieve that.

Still I would prefer to have to match the entries in devices.list.


I'm not following what this is actually meant to do.  It'll do the
same thing as the origina

Re: [PATCH] cgroup: fix device deny of DEV_ALL

Amos Kong — 2012-05-22T02:23:11

Hi Serge,

If we expect nothing changed ('a *:* rwm' doesn't change),
delete 135-136 will be ok.

But I have explained my patch in another email, I also think
it's unnecessary to remove 'a *:* rwm' before executing:
  < at > echo 'b 253:3 rw'>  devices.deny

Re: [PATCH] cgroup: fix device deny of DEV_ALL

Amos Kong — 2012-05-22T02:14:24


Hi serge,

My patch updated type,major,minor, it _equals to_ remove 'a *:* rwm' and 
add 'b *:* m'
It's a clear logic, why need to manually remove 'a *:* rwm'?



which bug? should not update walk->access if wh->access is not 'rwm'?

diff --git a/security/device_cgroup.c b/security/device_cgroup.c
index c43a332..e619a34 100644
--- a/security/device_cgroup.c
+++ b/security/device_cgroup.c
< at >< at > -145,7 +145,8 < at >< at > static void dev_whitelist_rm(struct dev_cgroup 
*dev_cgroup,
                         continue;

  remove:
-               walk->access &= ~wh->access;
+               if (walk->type != DEV_ALL || wh->access == ACC_MASK)
+                       walk->access &= ~wh->access;
                 if (!walk->access) {
                         list_del_rcu(&walk->list);
                         kfree_rcu(walk, rcu);

Re: [PATCH] cgroup: fix device deny of DEV_ALL

Serge E. Hallyn — 2012-05-22T02:08:57

At line 135, there is

if (walk->type == DEV_ALL)
goto remove;

I wonder if that was meant to be 'if (wh->type == DEV_ALL)'.  That
seems to fit better with what I would have meant to have happen.
But it's already handled by line 342.  So I think deleting lines
135-136 might be best.  What do you think?

Thanks again, Amos and Li.

-serge

Re: [PATCH] cgroup: fix device deny of DEV_ALL

Serge E. Hallyn — 2012-05-22T01:54:26

Quoting Li Zefan (lizefan-hv44wF8Li93QT0dZR+AlfA< at >public.gmane.org):

Yikes.  Agreed.  That's a bug.

thanks,
-serge

Re: [PATCH] cgroup: fix device deny of DEV_ALL

Li Zefan — 2012-05-22T00:34:34



No, you'll see the entry has been changed to 'a *:* m', so I think we
should at least fix this.

Re: [PATCH] cgroup: fix device deny of DEV_ALL

Serge Hallyn — 2012-05-21T14:03:24

Quoting Amos Kong (akong-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org):

Hi,

thanks.  You raise a good point, but I think it needs some discussion.

What happens right now is that if you have the 'a *:* rwm' entry and do
echo 'b 253:3 rw' > devices.deny, then when you next cat devices.list you
will still see the 'a *:* rwm' entry.  So there should be no confusion
over why the dd succeeds.  You didn't remove the entry, because there
was no match echoed into devices.deny.

You have to remove the existing whitelist entries, then add the entries
you want.  In particular, catting into devices.deny will not try to be
smart by slicing an existing whitelist entry into (matching, nonmatching)
parts so as to remove the matching and keep nonmatching.

If you'd like to submit a patch to change that, I'm quite sure I would
ack it.  The problem is that your patch doesn't do that (unless I'm grossly
misunderstanding).  Rather, it will remove both (matching, nonmatching).
Of course, in your example above, (nonmatching) would am

Order Enquiry

Mcckoy Robertson — 2012-05-20T15:35:44

Hello Sales
     I went over your contact online and found some items which we have interest in purchasing to our store in Spain for urgent supply. I will like to know the prices per each items plus the shipping cost. I also want to know if Letter of Credit or T/T is acceptable for payment. I await your quick response asap so i can proceed with my needed items and quantity.

Thank you
mcckoy robertson


N.B.M Global Supply Inc
Address: Autovía A-5,
salidas 22 y 26.
Arroyomolinos,
28939 Madrid Spain
Tel: +34 902 26 77 26
Email: nbmglobalsupply-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org
Website : http://www.brplastics.com


_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA< at >public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: [PATCH 2/2] cgroup: make css->refcnt clearing on cgroup removaloptional

Sasha Levin — 2012-05-18T18:28:56

From what I gathered, that patch means that you'll have refs to
dentries while you're trying to complete the unmount of the cgroup,
which would make something really angry.

I tested it by running two scripts to race with eachother:

First:

while [ true ];
do
mount -t cgroup dummy cgroup/
mkdir cgroup/0
rmdir cgroup/0
umount cgroup/
done

Second:

while [ true ];
do
mount -t cgroup dummy cgroup/
umount cgroup/
done

Now, if you give it a go, you'll see a BUG() and a system hang pretty fast.

Re: [PATCH 2/2] cgroup: make css->refcnt clearing on cgroupremoval optional

Tejun Heo — 2012-05-18T17:55:48

Can you please elaborate?

Thanks.

[PATCH] cgroup: fix device deny of DEV_ALL

Amos Kong — 2012-05-18T08:19:12

< at > mount -t cgroup -o devices none /cgroup
< at > mkdir /cgroups/devices
< at > ls -l /dev/dm-3
 brw-rw----. 1 root disk 253, 3 Oct 14 19:03 /dev/dm-3
< at > echo 'b 253:3 rw' > devices.deny
but I can still write it by 'dd if=/dev/zero of=/dev/dm-3'

In devcgroup_create(), we create a new whitelist, and add first
entry which type is 'DEV_ALL'. Execute "# echo 'b 253:3 rw' >
devices.deny", dev_whitelist_rm() will update access of first
entry to 1(m), but type of first entry is still 'DEV_ALL'.

Execute dd cmd to write device, __devcgroup_inode_permission()
will be called, permission checking will pass if entry type
is 'DEV_ALL'. So write operation of 'dd' is not denied.

Currently 'access' is updated by not be used, this patch updated
the type,major,minor of first entry, then permission checking
would work.

Signed-off-by: Amos Kong <akong-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>
---
 security/device_cgroup.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/security/device_cgroup.c b/security/devi

Re: [PATCH 2/2] cgroup: make css->refcnt clearing on cgroup removaloptional

Sasha Levin — 2012-05-16T22:33:05

Hi Tejun,

On Sun, Apr 1, 2012 at 8:54 PM, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A< at >public.gmane.org> wrote:

This patch allows for race when removing a cgroup since one of the
css's may still have a dentry ref when the cgroup is removed, no? Is
there a plan to deal with that before this patch gets pushed into 3.5?

International Order

Robertson Spencer — 2012-05-16T12:53:05

 Hello Sales
      I went over your contact online and found some items which we have interest in purchasing to our store in Spain for urgent supply. I will like to know the prices per each items plus the shipping cost. I Also want to know if Letter of Credit or T/T is acceptable for payment. I await your quick response asap so i can proceed with my needed items and quantity.

Thank you
Robertson Spencer


N.B.M Supply Inc
Address: Autovía A-5, 
salidas 22 y 26. 
Arroyomolinos, 
28939 Madrid Spain
Tel: +34 902 26 77 26
Email: robertsonspencer1-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org
Website : http://www.brplastics.com


_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA< at >public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: Please include user-namespace.git in linux-next

Stephen Rothwell — 2012-05-13T23:35:16

HI Eric,

On Fri, 11 May 2012 16:20:54 -0700 ebiederm-aS9lmoZGLiVWk0Htik3J/w< at >public.gmane.org (Eric W. Biederman) wrote:

I assume you left out "git.kernel.org/"  :-)

Included from today.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.