APPLIED: Pull request: nsmount updates

Tim Gardner tim.gardner at canonical.com
Wed Apr 6 12:10:24 UTC 2016


On 04/06/2016 12:52 PM, Seth Forshee wrote:
> On Wed, Apr 06, 2016 at 10:47:52AM +0100, Tim Gardner wrote:
>> On 04/05/2016 09:16 PM, Seth Forshee wrote:
>>> These commits bring xenial up to date wrt my branch for upstream. Most
>>> of the changes here are in response to upstream feedback. At a high
>>> level the changes are:
>>>
>>>  - A small improvement to the quota code, then disallow enabling quota
>>>    for mounts from non-init user namespaces. Since quota in non-init
>>>    namespaces isn't a requirement in 16.04 we're better off disabling it
>>>    until we know for sure how it will be handled upstream. However ext4
>>>    might temporarily enable quota during mount if recovering from an
>>>    unclean unmount, so the kernel needs to be able to handle it.
>>>
>>>  - Revert the way capabilities are determined for inodes in userns
>>>    mounts back to how it is upstream, i.e. based on both capabilities
>>>    and inode ownership, but allow a privileged user in s_user_ns to
>>>    chown if the id being changed is invalid and the other id is either
>>>    invalid or an id mapped into s_user_ns. This gives the mounter
>>>    control over inodes with unmappable ids while making it safe to have
>>>    s_user_ns != &init_user_ns for proc and kernfs-based mounts.
>>>
>>>  - Fix an incompatibility between cgroup namespaces and user namespace
>>>    mounts. Previously this was fixed as a side effect of another patch,
>>>    but that patch is being reverted.
>>>
>>>  - Remove a needless mount option initialization in fuse.
>>>
>>>  - Fix a resource leak for an error path in sget_userns().
>>>
>>> Thanks,
>>> Seth
>>>
>>
>> Ick! I hate your timing. I would feel a lot more comfortable if you had
>> some regression test results. Isn't this going to affect lxc/lxd ? How
>> about general file testing ?
> 
> Yeah, I know. I was trying to get them out last week but got held up by
> the cgroup stuff. I have my own set of regression tests I run on this
> stuff though, which includes a bunch of tests with lxc/lxd, and Serge
> has given them a spin too.
> 

Are those tests something we should get into our normal pile ?

-- 
Tim Gardner tim.gardner at canonical.com




More information about the kernel-team mailing list