http://blog.gmane.org/gmane.linux.kernel.containers hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.kernel.containers/23234 <pre> What system? I'm curious about the state of your userspace modifications. </pre> Colin Walters 2012-05-24T21:22:06 http://permalink.gmane.org/gmane.linux.kernel.containers/23233 <pre>From 88787c483106c5830a46d18deaffdc1e70929af7 Mon Sep 17 00:00:00 2001 From: Tejun Heo &lt;tj-DgEjT+Ai2ygdnm+yROfE0A&lt; at &gt;public.gmane.org&gt; Date: Thu, 24 May 2012 08:24:39 -0700 48ddbe1946 "cgroup: make css-&gt;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-&gt;d_release() operation and moving deactivate_super() to it. cgroup_diput() now marks dentry-&gt;d_fsdata with itself if superblock should be deactivated and cgroup_d_release() deactivates the superblock on dentry release. Signed-off-by: Tejun Heo &lt;tj-DgEjT+Ai2ygdnm+yROfE0A&lt; at &gt;public.gmane.org&gt; Reported-by: Sasha Levin &lt;levinsasha928-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; Tested-by: Sasha Levin &lt;levinsasha928-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; LKML-Reference: &lt;CA+1xoqe5hMuxzCRhMy7J0XchDk2ZnuxOHJKikROk1-ReAzcT6g-JsoAwUIsXosN+BqQ9rBEUg&lt; at &gt;public.gmane.org&gt; --- Li, can you please ack this? Thanks. kernel/cgroup.c | 17 ++++++++++++++--- 1 files changed, 14 insertions(+), 3 deletions(-) diff --git a/kernel/cgroup.c b/kernel/cgroup.c index ad8eae5..e887b55 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c &lt; at &gt;&lt; at &gt; -896,10 +896,13 &lt; at &gt;&lt; at &gt; static void cgroup_diput(struct dentry *dentry, struct inode *inode) mutex_unlock(&amp;cgroup_mutex); /* - * Drop the active superblock reference that we took when we - * created the cgroup + * We want to drop the active superblock reference from the + * cgroup creation after all the dentry refs are gone - + * kill_sb gets mighty unhappy otherwise. Mark + * dentry-&gt;d_fsdata with cgroup_diput() to tell + * cgroup_d_release() to call deactivate_super(). */ -deactivate_super(cgrp-&gt;root-&gt;sb); +dentry-&gt;d_fsdata = cgroup_diput; /* * if we're getting rid of the cgroup, refcount should ensure &lt; at &gt;&lt; at &gt; -925,6 +928,13 &lt; at &gt;&lt; at &gt; static int cgroup_delete(const struct dentry *d) return 1; } +static void cgroup_d_release(struct dentry *dentry) +{ +/* did cgroup_diput() tell me to deactivate super? */ +if (dentry-&gt;d_fsdata == cgroup_diput) +deactivate_super(dentry-&gt;d_sb); +} + static void remove_dir(struct dentry *d) { struct dentry *parent = dget(d-&gt;d_parent); &lt; at &gt;&lt; at &gt; -1532,6 +1542,7 &lt; at &gt;&lt; at &gt; static int cgroup_get_rootdir(struct super_block *sb) static const struct dentry_operations cgroup_dops = { .d_iput = cgroup_diput, .d_delete = cgroup_delete, +.d_release = cgroup_d_release, }; struct inode *inode = </pre> Tejun Heo 2012-05-24T15:41:39 http://permalink.gmane.org/gmane.linux.kernel.containers/23232 <pre> Yup, that did the trick. Thanks! </pre> Sasha Levin 2012-05-24T13:21:20 http://permalink.gmane.org/gmane.linux.kernel.containers/23231 <pre>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 </pre> Mr.Christopher 2012-05-23T16:03:48 http://permalink.gmane.org/gmane.linux.kernel.containers/23230 <pre>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 &lt; at &gt;&lt; at &gt; -896,10 +896,13 &lt; at &gt;&lt; at &gt; static void cgroup_diput(struct dentry *dentry, struct inode *inode) mutex_unlock(&amp;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-&gt;d_fsdata to cgroup_diput() to tell + * cgroup_d_release() to call deactivate_super(). */ -deactivate_super(cgrp-&gt;root-&gt;sb); +dentry-&gt;d_fsdata = cgroup_diput; /* * if we're getting rid of the cgroup, refcount should ensure &lt; at &gt;&lt; at &gt; -925,6 +928,13 &lt; at &gt;&lt; at &gt; static int cgroup_delete(const struct dentry *d) return 1; } +static void cgroup_d_release(struct dentry *dentry) +{ +/* did cgroup_diput() tell me to deactivate super? */ +if (dentry-&gt;d_fsdata == cgroup_diput) +deactivate_super(dentry-&gt;d_sb); +} + static void remove_dir(struct dentry *d) { struct dentry *parent = dget(d-&gt;d_parent); &lt; at &gt;&lt; at &gt; -1532,6 +1542,7 &lt; at &gt;&lt; at &gt; static int cgroup_get_rootdir(struct super_block *sb) static const struct dentry_operations cgroup_dops = { .d_iput = cgroup_diput, .d_delete = cgroup_delete, +.d_release = cgroup_d_release, }; struct inode *inode = </pre> Tejun Heo 2012-05-23T22:22:42 http://permalink.gmane.org/gmane.linux.kernel.containers/23229 <pre> 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 namespace of the compared uids remains the same. - With the user namespaces compiled out the performance is as good or better than it is today. - For most operations absolutely nothing changes performance or operationally with the user namespace enabled. - The worse case performance I could come up with was timing 1 billion cache cold stat operations with the user namespace code enabled. This went from 156s to 164s on my laptop (or 156ns to 164ns per stat operation). - (uid_t)-1 and (gid_t)-1 are reserved as an internal error value. Most uid/gid setting system calls treat these value specially anyway so attempting to use -1 as a uid would likely cause entertaining failures in userspace. - If setuid is called with a uid that can not be mapped setuid fails. I have looked at sendmail, login, ssh and every other program I could think of that would call setuid and they all check for and handle the case where setuid fails. - If stat or a similar system call is called from a context in which we can not map a uid we lie and return overflowuid. The LFS experience suggests not lying and returning an error code might be better, but the historical precedent with uids is different and I can not think of anything that would break by lying about a uid we can't map. - Capabilities are localized to the current user namespace making it safe to give the initial user in a user namespace all capabilities. My git tree covers all of the modifications needed to convert the core kernel and enough changes to make a system bootable to runlevel 1. Eric W. Biederman (45): vfs: Don't allow a user namespace root to make device nodes userns: Kill bogus declaration of function release_uids userns: Replace netlink uses of cap_raised with capable. userns: Remove unnecessary cast to struct user_struct when copying cred-&gt;user. cred: Add forward declaration of init_user_ns in all cases. userns: Use cred-&gt;user_ns instead of cred-&gt;user-&gt;user_ns cred: Refcount the user_ns pointed to by the cred. userns: Add an explicit reference to the parent user namespace mqueue: Explicitly capture the user namespace to send the notification to. userns: Deprecate and rename the user_namespace reference in the user_struct userns: Start out with a full set of capabilities. userns: Replace the hard to write inode_userns with inode_capable. userns: Add kuid_t and kgid_t and associated infrastructure in uidgid.h userns: Add a Kconfig option to enforce strict kuid and kgid type checks userns: Disassociate user_struct from the user_namespace. userns: Simplify the user_namespace by making userns-&gt;creator a kuid. userns: Rework the user_namespace adding uid/gid mapping support userns: Convert group_info values from gid_t to kgid_t. userns: Store uid and gid values in struct cred with kuid_t and kgid_t types userns: Replace user_ns_map_uid and user_ns_map_gid with from_kuid and from_kgid userns: Convert sched_set_affinity and sched_set_scheduler's permission checks userns: Convert capabilities related permsion checks userns: Convert setting and getting uid and gid system calls to use kuid and kgid userns: Convert ptrace, kill, set_priority permission checks to work with kuids and kgids userns: Store uid and gid types in vfs structures with kuid_t and kgid_t types userns: Convert in_group_p and in_egroup_p to use kgid_t userns: Use uid_eq gid_eq helpers when comparing kuids and kgids in the vfs userns: Convert user specfied uids and gids in chown into kuids and kgid userns: Convert stat to return values mapped from kuids and kgids userns: Fail exec for suid and sgid binaries with ids outside our user namespace. userns: Teach inode_capable to understand inodes whose uids map to other namespaces. userns: signal remove unnecessary map_cred_ns userns: Add negative depends on entries to avoid building code that is userns unsafe userns: Convert binary formats to use kuid/kgid where appropriate userns: Convert devpts to use kuid/kgid where appropriate userns: Convert ext2 to use kuid/kgid where appropriate. userns: Convert ext3 to use kuid/kgid where appropriate userns: Convert ext4 to user kuid/kgid where appropriate userns: Convert proc to use kuid/kgid where appropriate userns: Convert sysctl permission checks to use kuid and kgids. userns: Convert sysfs to use kgid/kuid where appropriate userns: Convert tmpfs to use kuid and kgid where appropriate userns: Convert cgroup permission checks to use uid_eq userns: Convert the move_pages, and migrate_pages permission checks to use uid_eq userns: Silence silly gcc warning. Sasha Levin (1): cred: use correct cred accessor with regards to rcu read lock arch/arm/kernel/sys_oabi-compat.c | 4 +- arch/parisc/hpux/fs.c | 4 +- arch/s390/kernel/compat_linux.c | 18 +- arch/sparc/kernel/sys_sparc32.c | 4 +- arch/x86/ia32/sys_ia32.c | 4 +- arch/x86/mm/fault.c | 2 +- drivers/block/drbd/drbd_nl.c | 2 +- drivers/md/dm-log-userspace-transfer.c | 2 +- drivers/video/uvesafb.c | 2 +- fs/attr.c | 8 +- fs/binfmt_elf.c | 12 +- fs/binfmt_elf_fdpic.c | 12 +- fs/compat.c | 4 +- fs/devpts/inode.c | 24 +- fs/ecryptfs/messaging.c | 2 +- fs/exec.c | 15 +- fs/ext2/balloc.c | 5 +- fs/ext2/ext2.h | 8 +- fs/ext2/inode.c | 20 +- fs/ext2/super.c | 31 ++- fs/ext3/balloc.c | 5 +- fs/ext3/ext3.h | 8 +- fs/ext3/inode.c | 32 +- fs/ext3/super.c | 35 ++- fs/ext4/balloc.c | 4 +- fs/ext4/ext4.h | 4 +- fs/ext4/ialloc.c | 4 +- fs/ext4/inode.c | 34 +- fs/ext4/migrate.c | 4 +- fs/ext4/super.c | 38 ++- fs/fcntl.c | 6 +- fs/inode.c | 10 +- fs/ioprio.c | 18 +- fs/locks.c | 2 +- fs/namei.c | 29 +- fs/nfsd/auth.c | 5 +- fs/open.c | 16 +- fs/proc/array.c | 15 +- fs/proc/base.c | 93 +++++- fs/proc/inode.c | 4 +- fs/proc/proc_sysctl.c | 4 +- fs/proc/root.c | 2 +- fs/stat.c | 12 +- fs/sysfs/inode.c | 4 +- include/linux/capability.h | 2 + include/linux/cred.h | 33 +- include/linux/fs.h | 42 ++- include/linux/pid_namespace.h | 2 +- include/linux/proc_fs.h | 4 +- include/linux/quotaops.h | 4 +- include/linux/sched.h | 9 +- include/linux/shmem_fs.h | 4 +- include/linux/stat.h | 5 +- include/linux/uidgid.h | 200 +++++++++++ include/linux/user_namespace.h | 39 +- include/trace/events/ext3.h | 4 +- include/trace/events/ext4.h | 4 +- init/Kconfig | 130 +++++++- ipc/mqueue.c | 10 +- ipc/namespace.c | 2 +- kernel/capability.c | 21 ++ kernel/cgroup.c | 6 +- kernel/cred.c | 44 ++- kernel/exit.c | 6 +- kernel/groups.c | 50 ++-- kernel/ptrace.c | 15 +- kernel/sched/core.c | 7 +- kernel/signal.c | 51 +-- kernel/sys.c | 266 ++++++++++----- kernel/timer.c | 8 +- kernel/uid16.c | 48 ++- kernel/user.c | 51 ++- kernel/user_namespace.c | 595 ++++++++++++++++++++++++++++---- kernel/utsname.c | 2 +- mm/mempolicy.c | 4 +- mm/migrate.c | 4 +- mm/oom_kill.c | 4 +- mm/shmem.c | 22 +- net/core/sock.c | 4 +- net/ipv4/ping.c | 11 +- net/sunrpc/auth_generic.c | 4 +- net/sunrpc/auth_gss/svcauth_gss.c | 7 +- net/sunrpc/auth_unix.c | 15 +- net/sunrpc/svcauth_unix.c | 18 +- security/commoncap.c | 61 ++-- security/keys/key.c | 2 +- security/keys/permission.c | 5 +- security/keys/process_keys.c | 2 +- 88 files changed, 1790 insertions(+), 608 deletions(-) </pre> Eric W. Biederman 2012-05-22T18:48:47 http://permalink.gmane.org/gmane.linux.kernel.containers/23228 <pre>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 and res_counter_charge_nofail res_counter: Account max_usage when calling res_counter_charge_nofail() Glauber Costa (2): cgroup: pass struct mem_cgroup instead of struct cgroup to socket memcg cgroup: get rid of populate for memcg Mike Galbraith (1): cgroups: disallow attaching kthreadd or PF_THREAD_BOUND threads Tejun Heo (16): cgroup: deprecate remount option changes cgroup: move cgroup_clear_directory() call out of cgroup_populate_dir() cgroup: build list of all cgroups under a given cgroupfs_root cgroup: implement cgroup_add_cftypes() and friends cgroup: merge cft_release_agent cftype array into the base files array cgroup: relocate cftype and cgroup_subsys definitions in controllers cgroup: convert all non-memcg controllers to the new cftype interface memcg: always create memsw files if CONFIG_CGROUP_MEM_RES_CTLR_SWAP cgroup: convert memcg controller to the new cftype interface cgroup: remove cgroup_add_file[s]() cgroup: relocate __d_cgrp() and __d_cft() cgroup: introduce struct cfent cgroup: implement cgroup_rm_cftypes() cgroup: use negative bias on css-&gt;refcnt to block css_tryget() cgroup: make css-&gt;refcnt clearing on cgroup removal optional cgroup: remove cgroup_subsys-&gt;populate() Documentation/cgroups/resource_counter.txt | 4 +- Documentation/feature-removal-schedule.txt | 9 + block/blk-cgroup.c | 45 +-- include/linux/cgroup.h | 81 +++-- include/linux/res_counter.h | 2 +- include/net/sock.h | 12 +- include/net/tcp_memcontrol.h | 4 +- kernel/cgroup.c | 564 +++++++++++++++++++++------- kernel/cgroup_freezer.c | 11 +- kernel/cpuset.c | 31 +- kernel/res_counter.c | 71 ++-- kernel/sched/core.c | 16 +- mm/memcontrol.c | 115 +++--- net/core/netprio_cgroup.c | 30 +- net/core/sock.c | 10 +- net/ipv4/tcp_memcontrol.c | 77 ++-- net/sched/cls_cgroup.c | 31 +- security/device_cgroup.c | 10 +- 18 files changed, 685 insertions(+), 438 deletions(-) -- tejun </pre> Tejun Heo 2012-05-22T17:34:50 http://permalink.gmane.org/gmane.linux.kernel.containers/23227 <pre>Quoting Amos Kong (akong-H+wXaHxf7aLQT0dZR+AlfA&lt; at &gt;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" &gt; 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 original code, unless walk-&gt;type == DEV_ALL and wh-&gt;access != ACC_MASK, but that is never the case per devcgroup_update_access(). Lastly, perhaps what we actually want to do is implement blacklists instead of a pure whitelist? So we could then really say "allow everything except b 254:3 rw" with two entries. But, while it may be nice to talk about that, I have not seen any cases where someone actually wanted that. For containers, at least, a pure whitelist has always been right. thanks, -serge </pre> Serge Hallyn 2012-05-22T12:48:31 http://permalink.gmane.org/gmane.linux.kernel.containers/23226 <pre> 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: &lt; at &gt; echo 'b 253:3 rw'&gt; devices.deny </pre> Amos Kong 2012-05-22T02:23:11 http://permalink.gmane.org/gmane.linux.kernel.containers/23225 <pre> 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-&gt;access if wh-&gt;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 &lt; at &gt;&lt; at &gt; -145,7 +145,8 &lt; at &gt;&lt; at &gt; static void dev_whitelist_rm(struct dev_cgroup *dev_cgroup, continue; remove: - walk-&gt;access &amp;= ~wh-&gt;access; + if (walk-&gt;type != DEV_ALL || wh-&gt;access == ACC_MASK) + walk-&gt;access &amp;= ~wh-&gt;access; if (!walk-&gt;access) { list_del_rcu(&amp;walk-&gt;list); kfree_rcu(walk, rcu); </pre> Amos Kong 2012-05-22T02:14:24 http://permalink.gmane.org/gmane.linux.kernel.containers/23224 <pre>At line 135, there is if (walk-&gt;type == DEV_ALL) goto remove; I wonder if that was meant to be 'if (wh-&gt;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 </pre> Serge E. Hallyn 2012-05-22T02:08:57 http://permalink.gmane.org/gmane.linux.kernel.containers/23223 <pre>Quoting Li Zefan (lizefan-hv44wF8Li93QT0dZR+AlfA&lt; at &gt;public.gmane.org): Yikes. Agreed. That's a bug. thanks, -serge </pre> Serge E. Hallyn 2012-05-22T01:54:26 http://permalink.gmane.org/gmane.linux.kernel.containers/23222 <pre> No, you'll see the entry has been changed to 'a *:* m', so I think we should at least fix this. </pre> Li Zefan 2012-05-22T00:34:34 http://permalink.gmane.org/gmane.linux.kernel.containers/23221 <pre>Quoting Amos Kong (akong-H+wXaHxf7aLQT0dZR+AlfA&lt; at &gt;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' &gt; 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 amount to a huge set of rules, so in the end I'm not sure it is worth it. Note that the devices cgroup was meant to be a simple, useful stop-gap until the user and devices namespaces are ready. The user namespace is getting close, but devices ns still needs to be designed (hopefully at plumber's). So I don't mind improving on the devices cgroup. It's turned out to be quite useful. But I don't want to replace one (simple, easy to verify, but) incomplete user interface with a different one. There are sure to be existing users who would be broken. In fact, it's possbile that "fixing" the incomplete behavior would bother some users, though I suspect the improvement would be worth it to them. So for this particular patch, NACK. But thanks for bringing it up. thanks, -serge </pre> Serge Hallyn 2012-05-21T14:03:24 http://permalink.gmane.org/gmane.linux.kernel.containers/23220 <pre> 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&lt; at &gt;public.gmane.org Website : http://www.brplastics.com _______________________________________________ Containers mailing list Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA&lt; at &gt;public.gmane.org https://lists.linuxfoundation.org/mailman/listinfo/containers</pre> Mcckoy Robertson 2012-05-20T15:35:44 http://permalink.gmane.org/gmane.linux.kernel.containers/23219 <pre> 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. </pre> Sasha Levin 2012-05-18T18:28:56 http://permalink.gmane.org/gmane.linux.kernel.containers/23218 <pre> Can you please elaborate? Thanks. </pre> Tejun Heo 2012-05-18T17:55:48 http://permalink.gmane.org/gmane.linux.kernel.containers/23217 <pre>&lt; at &gt; mount -t cgroup -o devices none /cgroup &lt; at &gt; mkdir /cgroups/devices &lt; at &gt; ls -l /dev/dm-3 brw-rw----. 1 root disk 253, 3 Oct 14 19:03 /dev/dm-3 &lt; at &gt; echo 'b 253:3 rw' &gt; 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' &gt; 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 &lt;akong-H+wXaHxf7aLQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt; --- security/device_cgroup.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/security/device_cgroup.c b/security/device_cgroup.c index c43a332..d16b4bc 100644 --- a/security/device_cgroup.c +++ b/security/device_cgroup.c &lt; at &gt;&lt; at &gt; -146,6 +146,11 &lt; at &gt;&lt; at &gt; static void dev_whitelist_rm(struct dev_cgroup *dev_cgroup, remove: walk-&gt;access &amp;= ~wh-&gt;access; +if (walk-&gt;type == DEV_ALL) { +walk-&gt;type = wh-&gt;type; +walk-&gt;major = wh-&gt;major; +walk-&gt;minor = wh-&gt;minor; +} if (!walk-&gt;access) { list_del_rcu(&amp;walk-&gt;list); kfree_rcu(walk, rcu); </pre> Amos Kong 2012-05-18T08:19:12 http://permalink.gmane.org/gmane.linux.kernel.containers/23215 <pre>Hi Tejun, On Sun, Apr 1, 2012 at 8:54 PM, Tejun Heo &lt;tj-DgEjT+Ai2ygdnm+yROfE0A&lt; at &gt;public.gmane.org&gt; 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? </pre> Sasha Levin 2012-05-16T22:33:05 http://permalink.gmane.org/gmane.linux.kernel.containers/23214 <pre> 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&lt; at &gt;public.gmane.org Website : http://www.brplastics.com _______________________________________________ Containers mailing list Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA&lt; at &gt;public.gmane.org https://lists.linuxfoundation.org/mailman/listinfo/containers</pre> Robertson Spencer 2012-05-16T12:53:05 http://permalink.gmane.org/gmane.linux.kernel.containers/23213 <pre>HI Eric, On Fri, 11 May 2012 16:20:54 -0700 ebiederm-aS9lmoZGLiVWk0Htik3J/w&lt; at &gt;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. </pre> Stephen Rothwell 2012-05-13T23:35:16 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.kernel.containers