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/63b32df68ae8d3a3842bae42bbcae3468db76d85 > > I can't say that it makes something uglier. I have only skimmed things but overall it looks better than I had feared. At the same time I really really don't like losing the parent pointer in the user namespace case. That is seriously obfuscating. Eric -- 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
