On Mon, Jul 11, 2016 at 06:06:48AM +0900, James Bottomley wrote: > On Sun, 2016-07-10 at 15:29 -0500, Eric W. Biederman wrote: > > Andrew Vagin <avagin@xxxxxxxxxxxxx> writes: > > > > > On Fri, Jul 08, 2016 at 10:13:08PM -0500, Eric W. Biederman wrote: > > > > "W. Trevor King" <wking@xxxxxxxxxx> writes: > > > > > > > > > On Thu, Jul 07, 2016 at 08:01:52AM -0700, James Bottomley > > > > > wrote: > > > > > > In theory, we could get nsfs to show this information as an > > > > > > option > > > > > > (just add a show_options entry to the superblock ops), but > > > > > > the > > > > > > problem is that although each namespace has a parent user_ns, > > > > > > there's no way to get it without digging in the namespace > > > > > > specific > > > > > > structure. Probably we should restructure to move it into > > > > > > ns_common, then we could display it (and enforce all > > > > > > namespaces > > > > > > having owning user_ns) but it would be a reasonably large > > > > > > (but > > > > > > mechanical) change. > > > > > > > > > > It sounds like everyone is either positive or or neutral on > > > > > this > > > > > groundwork, even if we haven't decided if/how to expose the > > > > > information to userspace. I'm happy to work up a patch while > > > > > the rest > > > > > of the discussion continues. I'm also happy to let someone > > > > > else work > > > > > up the patch, if anyone else is chomping at the bit ;). > > > > > > > > I am dubious on moving all of the user namespace members into > > > > ns_common. > > > > > > > > I would happy to be proved wrong but I suspect in the cases where > > > > we > > > > actually use that user namespace the code will become uglier. > > > > Making > > > > the ordinary uses uglier to make a rare corner case nicer is the > > > > wrong > > > > trade off. > > > > > > > > But feel free to try it is certainly worth doing if it doesn't > > > > make the > > > > code that uses the user namespaces uglier. > > > > > > If it's interesting for someone, I have this patch in my tree > > > https://github.com/avagin/linux-task-diag/commit/63b32df68ae8d3a384 > > > 2bae42bbcae3468db76d85 > > > > > > I can't say that it makes something uglier. > > > > I have only skimmed things but overall it looks better than I had > > feared. > > It looks about as messy as I feared, but since someone else has done > all the hard work, I'm happy. > > > At the same time I really really don't like losing the parent pointer > > in the user namespace case. That is seriously obfuscating. We can do something like this: @@ -27,11 +27,13 @@ struct user_namespace { ... - struct ns_common ns; + union { + struct user_namespace *parent; + struct ns_common ns; + }; unsigned long flags; ... @@ -97,6 +97,7 @@ int create_user_ns(struct cred *new) ... atomic_set(&ns->count, 1); /* Leave the new->user_ns reference with the new user namespace. */ + BUILD_BUG_ON(&ns->ns.user_ns != &ns->parent); ns->parent = parent_ns; > > Because it has a slightly different meaning from all other namespaces? > If I assume that's what you mean, I think looking at it in a different > way can solve the problem: The pointer in ns_common is always to the > owning user_ns, so we can label it as such. Even for a child user_ns, > the owning user_ns is simply the parent. I think it makes logical > sense to think of all user_ns to namespace relationships as > owning/owned rather than most as owning/owned and some as parent/child. I think we can rename ns.user_ns to ns.owner or ns.owner_ns. Thanks, Andrew > > James > > > Eric > > > > _______________________________________________ > > Containers mailing list > > Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx > > https://lists.linuxfoundation.org/mailman/listinfo/containers > > > -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
