On Thu, Mar 19, 2015 at 08:14:05PM -0500, Eric W. Biederman wrote: > > Yes please, I'd be more confident if you did this than me, there's > > already enough to worry about with the series. > > Given that this patchset is a security hole waiting to happen I don't > see why Al should bother unless there are good reasons to do this > otherwise.
There might be, actually. &...->mnt_ns->ns is a lot saner candidate for a reference in nsproxy than ...->mnt_ns - *that* is the part nsproxy-related code cares about anyway, and unlike the rest of struct mnt_namespace it doesn't have to be opaque for everything outside of (small part of) core VFS. Additionally, ->mnt_ns is a bad name choice - it sounds like a field of struct mount and, worse yet, there *is* a field of struct mount with that name. Confusing for no good reason and makes both harder to grep for. And current_mnt_ns() is definitely open-coded too many times - the first commit in that series makes sense regardless of anything else. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
