mm: Add a user_ns owner to mm_struct and fix ptrace_may_access

Hi Eric! A few days ago we've noticed that our zombie00 test case started
failing: https://ci.openvz.org/job/CRIU/view/All/job/CRIU-linux-next/406/console
---
======================== Run zdtm/static/zombie00 in h ========================= Start test
./zombie00 --pidfile=zombie00.pid --outfile=zombie00.out
Run criu dump
Run criu restore
Send the 15 signal to 30
Wait for zdtm/static/zombie00(30) to die for 0.100000 ################ Test zdtm/static/zombie00 FAIL at result check ################

I've narrowed problem down to commit

 | From ce99dd5fd5f600f9f4f0d37bb8847c1cb7c6e4fc Mon Sep 17 00:00:00 2001
 | From: "Eric W. Biederman" <[email protected]>
 | Date: Thu, 13 Oct 2016 21:23:16 -0500
 | Subject: [PATCH] mm: Add a user_ns owner to mm_struct and fix
 |  ptrace_may_access
 |
 | During exec dumpable is cleared if the file that is being executed is
 | not readable by the user executing the file.  A bug in
 | ptrace_may_access allows reading the file if the executable happens to
 | enter into a subordinate user namespace (aka clone(CLONE_NEWUSER),
 | unshare(CLONE_NEWUSER), or setns(fd, CLONE_NEWUSER).

and the reason is that the zombie tasks do not have task::mm and in resut we're obtaining -EPERM when trying to read task->exit_code from /proc/pid/stat.

Looking into commit I suspect when mm = NULL we've to move back the test ptrace_has_cap(__task_cred(task)->user_ns, mode)?

Hi Eric! A few days ago we've noticed that our zombie00 test case started
failing: https://ci.openvz.org/job/CRIU/view/All/job/CRIU-linux-next/406/console

---
======================== Run zdtm/static/zombie00 in h ========================= Start test
./zombie00 --pidfile=zombie00.pid --outfile=zombie00.out
Run criu dump
Run criu restore
Send the 15 signal to 30
Wait for zdtm/static/zombie00(30) to die for 0.100000 ################ Test zdtm/static/zombie00 FAIL at result check ################

I've narrowed problem down to commit

 | From ce99dd5fd5f600f9f4f0d37bb8847c1cb7c6e4fc Mon Sep 17 00:00:00 2001
 | From: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]>
 | Date: Thu, 13 Oct 2016 21:23:16 -0500
 | Subject: [PATCH] mm: Add a user_ns owner to mm_struct and fix
 |  ptrace_may_access
 |
 | During exec dumpable is cleared if the file that is being executed is
 | not readable by the user executing the file.  A bug in
 | ptrace_may_access allows reading the file if the executable happens to
 | enter into a subordinate user namespace (aka clone(CLONE_NEWUSER),
 | unshare(CLONE_NEWUSER), or setns(fd, CLONE_NEWUSER).

and the reason is that the zombie tasks do not have task::mm and in resut we're obtaining -EPERM when trying to read task->exit_code from /proc/pid/stat.

Looking into commit I suspect when mm = NULL we've to move back the test ptrace_has_cap(__task_cred(task)->user_ns, mode)?

Adding the containers list because that is the general place for these kinds of discussions.

Quoted 27 lines · Cyrill Gorcunov

Hi Eric! A few days ago we've noticed that our zombie00 test case started
failing: https://ci.openvz.org/job/CRIU/view/All/job/CRIU-linux-next/406/console

---
======================== Run zdtm/static/zombie00 in h ========================= Start test
./zombie00 --pidfile=zombie00.pid --outfile=zombie00.out
Run criu dump
Run criu restore
Send the 15 signal to 30
Wait for zdtm/static/zombie00(30) to die for 0.100000 ################ Test zdtm/static/zombie00 FAIL at result check ################

I've narrowed problem down to commit

 | From ce99dd5fd5f600f9f4f0d37bb8847c1cb7c6e4fc Mon Sep 17 00:00:00 2001
 | From: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]>
 | Date: Thu, 13 Oct 2016 21:23:16 -0500
 | Subject: [PATCH] mm: Add a user_ns owner to mm_struct and fix
 |  ptrace_may_access
 |
 | During exec dumpable is cleared if the file that is being executed is
 | not readable by the user executing the file.  A bug in
 | ptrace_may_access allows reading the file if the executable happens to
 | enter into a subordinate user namespace (aka clone(CLONE_NEWUSER),
 | unshare(CLONE_NEWUSER), or setns(fd, CLONE_NEWUSER).

Quoted 3 lines

and the reason is that the zombie tasks do not have task::mm and in resut we're obtaining -EPERM when trying to read task->exit_code from /proc/pid/stat.

Hmm. As I read the code exit_code should be returned to userspace as a
0. It does not look to me as if userspace should see an error in that case.

Quoted 3 lines

Looking into commit I suspect when mm = NULL we've to move back the test ptrace_has_cap(__task_cred(task)->user_ns, mode)?

Maybe.

We might want to consider if these lines from do_task_stat make any sense.

	if (permitted)
		seq_put_decimal_ll(m, " ", task->exit_code);
	else
		seq_puts(m, " 0");

Looking at the code. Nothing changes behavior except for privileged tasks looking at processes without an mm. So yes it may be sane to tweak that part of the check.

AKA in the in for-next branch the code currenty says:

	mm = task->mm;
	if (!mm ||
	    ((get_dumpable(mm) != SUID_DUMP_USER) &&
	     !ptrace_has_cap(mm->user_ns, mode)))
	    return -EPERM;

And in the case there is no mm there is no way to get past returning -EPERM.

Looking at why we use ptrace_may_access in the exit_code case I see a couple of relevant commits.

The commit that added task->exit_code:

commit 5b172087f99189416d5f47fd7ab5e6fb762a9ba3

Author: Cyrill Gorcunov <[email protected]>
Date:   Thu May 31 16:26:44 2012 -0700

c/r: procfs: add arg_start/end, env_start/end and exit_code members to /proc/$pid/stat

We would like to have an ability to restore command line arguments and program environment pointers but first we need to obtain them somehow. Thus we put these values into /proc/$pid/stat. The exit_code is needed to restore zombie tasks.

Signed-off-by Cyrill Gorcunov <[email protected]>

Acked-by Kees Cook <[email protected]>

Cc Pavel Emelyanov <[email protected]>

Cc Serge Hallyn <[email protected]>

Cc KAMEZAWA Hiroyuki <[email protected]>

Cc Alexey Dobriyan <[email protected]>

Cc Tejun Heo <[email protected]>

Cc Andrew Vagin <[email protected]>

Cc Vasiliy Kulikov <segoon-cxoSlKxDwOJWk0Htik3J/[email protected]>

Cc Alexey Dobriyan <[email protected]>

Cc "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]>

Signed-off-by Andrew Morton <akpm-de/[email protected]>

Signed-off-by Linus Torvalds <torvalds-de/[email protected]>

Looking at do_task_stat everything else that requires permitted in do_tack_stat is an address. exit_code is something else so I am not at all certain the ptrace_may_access permission check makes sense.

A process without an mm is fundamentally undumpable so an error should be returned in any case. So I don't see any harm in failing ptrace_may_access in general. At the same time I can see how not preserving the existing behavior is problematic.

So I am probably going to tweak the !mm case so that instead of failing we perform the old capable check in that case. That seems the mot certain way to avoid regressions. With that said, why is exit_code behind a ptrace_may_access permission check?

Adding the containers list because that is the general place for these kinds of discussions.

Quoted 27 lines · Cyrill Gorcunov

Hi Eric! A few days ago we've noticed that our zombie00 test case started
failing: https://ci.openvz.org/job/CRIU/view/All/job/CRIU-linux-next/406/console

---
======================== Run zdtm/static/zombie00 in h ========================= Start test
./zombie00 --pidfile=zombie00.pid --outfile=zombie00.out
Run criu dump
Run criu restore
Send the 15 signal to 30
Wait for zdtm/static/zombie00(30) to die for 0.100000 ################ Test zdtm/static/zombie00 FAIL at result check ################

I've narrowed problem down to commit

 | From ce99dd5fd5f600f9f4f0d37bb8847c1cb7c6e4fc Mon Sep 17 00:00:00 2001
 | From: "Eric W. Biederman" <[email protected]>
 | Date: Thu, 13 Oct 2016 21:23:16 -0500
 | Subject: [PATCH] mm: Add a user_ns owner to mm_struct and fix
 |  ptrace_may_access
 |
 | During exec dumpable is cleared if the file that is being executed is
 | not readable by the user executing the file.  A bug in
 | ptrace_may_access allows reading the file if the executable happens to
 | enter into a subordinate user namespace (aka clone(CLONE_NEWUSER),
 | unshare(CLONE_NEWUSER), or setns(fd, CLONE_NEWUSER).

Quoted 3 lines

and the reason is that the zombie tasks do not have task::mm and in resut we're obtaining -EPERM when trying to read task->exit_code from /proc/pid/stat.

Hmm. As I read the code exit_code should be returned to userspace as a
0. It does not look to me as if userspace should see an error in that case.

Quoted 3 lines

Looking into commit I suspect when mm = NULL we've to move back the test ptrace_has_cap(__task_cred(task)->user_ns, mode)?

Maybe.

We might want to consider if these lines from do_task_stat make any sense.

	if (permitted)
		seq_put_decimal_ll(m, " ", task->exit_code);
	else
		seq_puts(m, " 0");

Looking at the code. Nothing changes behavior except for privileged tasks looking at processes without an mm. So yes it may be sane to tweak that part of the check.

AKA in the in for-next branch the code currenty says:

	mm = task->mm;
	if (!mm ||
	    ((get_dumpable(mm) != SUID_DUMP_USER) &&
	     !ptrace_has_cap(mm->user_ns, mode)))
	    return -EPERM;

And in the case there is no mm there is no way to get past returning -EPERM.

Looking at why we use ptrace_may_access in the exit_code case I see a couple of relevant commits.

The commit that added task->exit_code:

commit 5b172087f99189416d5f47fd7ab5e6fb762a9ba3

Author: Cyrill Gorcunov <[email protected]>
Date:   Thu May 31 16:26:44 2012 -0700

c/r: procfs: add arg_start/end, env_start/end and exit_code members to /proc/$pid/stat

We would like to have an ability to restore command line arguments and program environment pointers but first we need to obtain them somehow. Thus we put these values into /proc/$pid/stat. The exit_code is needed to restore zombie tasks.

Signed-off-by Cyrill Gorcunov <[email protected]>

Acked-by Kees Cook <[email protected]>

Cc Pavel Emelyanov <[email protected]>

Cc Serge Hallyn <[email protected]>

Cc KAMEZAWA Hiroyuki <[email protected]>

Cc Alexey Dobriyan <[email protected]>

Cc Tejun Heo <[email protected]>

Cc Andrew Vagin <[email protected]>

Cc Vasiliy Kulikov <[email protected]>

Cc Alexey Dobriyan <[email protected]>

Cc "Eric W. Biederman" <[email protected]>

Signed-off-by Andrew Morton <[email protected]>

Signed-off-by Linus Torvalds <[email protected]>

Looking at do_task_stat everything else that requires permitted in do_tack_stat is an address. exit_code is something else so I am not at all certain the ptrace_may_access permission check makes sense.

A process without an mm is fundamentally undumpable so an error should be returned in any case. So I don't see any harm in failing ptrace_may_access in general. At the same time I can see how not preserving the existing behavior is problematic.

So I am probably going to tweak the !mm case so that instead of failing we perform the old capable check in that case. That seems the mot certain way to avoid regressions. With that said, why is exit_code behind a ptrace_may_access permission check?

Quoted 4 lines · Eric W. Biederman

So I am probably going to tweak the !mm case so that instead of failing we perform the old capable check in that case. That seems the mot certain way to avoid regressions. With that said, why is exit_code behind a ptrace_may_access permission check?

Yes, this would be great! And as to @exit_code I think better ask Kees, CC'ed.

Quoted 8 lines · Cyrill Gorcunov

Quoted 4 lines · Eric W. Biederman

So I am probably going to tweak the !mm case so that instead of failing we perform the old capable check in that case. That seems the mot certain way to avoid regressions. With that said, why is exit_code behind a ptrace_may_access permission check?

Yes, this would be great! And as to @exit_code I think better ask Kees, CC'ed.

My concern was that this was an exposure in the sense that it is internal program state that isn't visible through other means (without being the parent, for example). Under the ptrace check, it has an equivalency that seemed correct at the time.

As already covered, I'd agree: it looks like ce99dd5fd5f6 accidentally added a dependency on task->mm where it didn't before. That section of logic was entirely around dumpability, not an mm existing. It should be "EPERM if mm and dumpable != SUID_DUMP_USER".

That said, I'd also agree that ptrace against no mm is crazy (though I suppose that should return EINVAL or ESRCH or something), so perhaps a better access control on @exit_code is needed here.

Quoted 8 lines · Cyrill Gorcunov

Quoted 4 lines · Eric W. Biederman

So I am probably going to tweak the !mm case so that instead of failing we perform the old capable check in that case. That seems the mot certain way to avoid regressions. With that said, why is exit_code behind a ptrace_may_access permission check?

Yes, this would be great! And as to @exit_code I think better ask Kees, CC'ed.

My concern was that this was an exposure in the sense that it is internal program state that isn't visible through other means (without being the parent, for example). Under the ptrace check, it has an equivalency that seemed correct at the time.

As already covered, I'd agree: it looks like ce99dd5fd5f6 accidentally added a dependency on task->mm where it didn't before. That section of logic was entirely around dumpability, not an mm existing. It should be "EPERM if mm and dumpable != SUID_DUMP_USER".

That said, I'd also agree that ptrace against no mm is crazy (though I suppose that should return EINVAL or ESRCH or something), so perhaps a better access control on @exit_code is needed here.

Quoted 15 lines · Kees Cook

Quoted 8 lines · Cyrill Gorcunov

Quoted 4 lines · Eric W. Biederman

So I am probably going to tweak the !mm case so that instead of failing we perform the old capable check in that case. That seems the mot certain way to avoid regressions. With that said, why is exit_code behind a ptrace_may_access permission check?

Yes, this would be great! And as to @exit_code I think better ask Kees, CC'ed.

My concern was that this was an exposure in the sense that it is internal program state that isn't visible through other means (without being the parent, for example). Under the ptrace check, it has an equivalency that seemed correct at the time.

Quoted 8 lines

As already covered, I'd agree: it looks like ce99dd5fd5f6 accidentally added a dependency on task->mm where it didn't before. That section of logic was entirely around dumpability, not an mm existing. It should be "EPERM if mm and dumpable != SUID_DUMP_USER".

That said, I'd also agree that ptrace against no mm is crazy (though I suppose that should return EINVAL or ESRCH or something), so perhaps a better access control on @exit_code is needed here.

I traced down the original logic of why we had that dumpable variable, and it was ancient conservative on my part when we started using the ptrace permission checks for proc files.

That same conservatism has resulted in the regression under discussion.

Given that we already have a very full set of permission checks separate from dumpable in ptrace_may_access I think it makes sense to simply ignore dumpable when there is no mm.
AKA:

	mm = task->mm;
	if (mm &&
	    ((get_dumpable(mm) != SUID_DUMP_USER) &&
	     !ptrace_has_cap(mm->user_ns, mode)))
	    return -EPERM;

Because while it has been used for other things dumpable is fundamentally about do you have permission to read the mm. So there is no real point in permission checks that protect the mm if the mm has gone away.

It also looks like I may need to update the check that sets PT_PTRACE_CAP to look at mm->user_ns as well.

Quoted 15 lines · Kees Cook

Quoted 8 lines · Cyrill Gorcunov

Quoted 4 lines · Eric W. Biederman

So I am probably going to tweak the !mm case so that instead of failing we perform the old capable check in that case. That seems the mot certain way to avoid regressions. With that said, why is exit_code behind a ptrace_may_access permission check?

Yes, this would be great! And as to @exit_code I think better ask Kees, CC'ed.

My concern was that this was an exposure in the sense that it is internal program state that isn't visible through other means (without being the parent, for example). Under the ptrace check, it has an equivalency that seemed correct at the time.

Quoted 8 lines

As already covered, I'd agree: it looks like ce99dd5fd5f6 accidentally added a dependency on task->mm where it didn't before. That section of logic was entirely around dumpability, not an mm existing. It should be "EPERM if mm and dumpable != SUID_DUMP_USER".

That said, I'd also agree that ptrace against no mm is crazy (though I suppose that should return EINVAL or ESRCH or something), so perhaps a better access control on @exit_code is needed here.

I traced down the original logic of why we had that dumpable variable, and it was ancient conservative on my part when we started using the ptrace permission checks for proc files.

That same conservatism has resulted in the regression under discussion.

Given that we already have a very full set of permission checks separate from dumpable in ptrace_may_access I think it makes sense to simply ignore dumpable when there is no mm.
AKA:

	mm = task->mm;
	if (mm &&
	    ((get_dumpable(mm) != SUID_DUMP_USER) &&
	     !ptrace_has_cap(mm->user_ns, mode)))
	    return -EPERM;

Because while it has been used for other things dumpable is fundamentally about do you have permission to read the mm. So there is no real point in permission checks that protect the mm if the mm has gone away.

It also looks like I may need to update the check that sets PT_PTRACE_CAP to look at mm->user_ns as well.

During exec dumpable is cleared if the file that is being executed is not readable by the user executing the file. A bug in ptrace_may_access allows reading the file if the executable happens to enter into a subordinate user namespace (aka clone(CLONE_NEWUSER), unshare(CLONE_NEWUSER), or setns(fd, CLONE_NEWUSER).

This problem is fixed with only necessary userspace breakage by adding a user namespace owner to mm_struct, captured at the time of exec, so it is clear in which user namespace CAP_SYS_PTRACE must be present in to be able to safely give read permission to the executable.

The function ptrace_may_access is modified to verify that the ptracer has CAP_SYS_ADMIN in task->mm->user_ns instead of task->cred->user_ns. This ensures that if the task changes it's cred into a subordinate user namespace it does not become ptraceable.

The function ptrace_attach is modified to only set PT_PTRACE_CAP when CAP_SYS_PTRACE is held over task->mm->user_ns. The intent of PT_PTRACE_CAP is to be a flag to note that whatever permission changes the task might go through the tracer has sufficient permissions for it not to be an issue. task->cred->user_ns is always the same as or descendent of mm->user_ns. Which guarantees that having CAP_SYS_PTRACE over mm->user_ns is the worst case for the tasks credentials.

Cc [email protected]

Fixes 8409cca70561 ("userns: allow ptrace from non-init user namespaces")

Signed-off-by "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]>

I can't imagine either of these changes making a practical difference to anyone but I am calling them out in case someone can.

 include/linux/mm_types.h |  1 +
 kernel/fork.c            |  9 ++++++---
 kernel/ptrace.c          | 26 +++++++++++---------------
 mm/init-mm.c             |  2 ++
 4 files changed, 20 insertions(+), 18 deletions(-)

During exec dumpable is cleared if the file that is being executed is not readable by the user executing the file. A bug in ptrace_may_access allows reading the file if the executable happens to enter into a subordinate user namespace (aka clone(CLONE_NEWUSER), unshare(CLONE_NEWUSER), or setns(fd, CLONE_NEWUSER).

This problem is fixed with only necessary userspace breakage by adding a user namespace owner to mm_struct, captured at the time of exec, so it is clear in which user namespace CAP_SYS_PTRACE must be present in to be able to safely give read permission to the executable.

The function ptrace_may_access is modified to verify that the ptracer has CAP_SYS_ADMIN in task->mm->user_ns instead of task->cred->user_ns. This ensures that if the task changes it's cred into a subordinate user namespace it does not become ptraceable.

The function ptrace_attach is modified to only set PT_PTRACE_CAP when CAP_SYS_PTRACE is held over task->mm->user_ns. The intent of PT_PTRACE_CAP is to be a flag to note that whatever permission changes the task might go through the tracer has sufficient permissions for it not to be an issue. task->cred->user_ns is always the same as or descendent of mm->user_ns. Which guarantees that having CAP_SYS_PTRACE over mm->user_ns is the worst case for the tasks credentials.

Cc [email protected]

Fixes 8409cca70561 ("userns: allow ptrace from non-init user namespaces")

Signed-off-by "Eric W. Biederman" <[email protected]>

I can't imagine either of these changes making a practical difference to anyone but I am calling them out in case someone can.

 include/linux/mm_types.h |  1 +
 kernel/fork.c            |  9 ++++++---
 kernel/ptrace.c          | 26 +++++++++++---------------
 mm/init-mm.c             |  2 ++
 4 files changed, 20 insertions(+), 18 deletions(-)

Quoted 10 lines · Eric W. Biederman

I can't imagine either of these changes making a practical difference to anyone but I am calling them out in case someone can.

 include/linux/mm_types.h |  1 +
 kernel/fork.c            |  9 ++++++---
 kernel/ptrace.c          | 26 +++++++++++---------------
 mm/init-mm.c             |  2 ++
 4 files changed, 20 insertions(+), 18 deletions(-)

Thanks a huge, Eric! And really sorry for delay in response, I managed to miss this quite important mail for me in mail storm. Gonna test it and will write you the results. Overall looks great, but better be sure and run the tests.

Reviewed-by Cyrill Gorcunov <[email protected]>

Quoted 10 lines · Eric W. Biederman

I can't imagine either of these changes making a practical difference to anyone but I am calling them out in case someone can.

 include/linux/mm_types.h |  1 +
 kernel/fork.c            |  9 ++++++---
 kernel/ptrace.c          | 26 +++++++++++---------------
 mm/init-mm.c             |  2 ++
 4 files changed, 20 insertions(+), 18 deletions(-)

Thanks a huge, Eric! And really sorry for delay in response, I managed to miss this quite important mail for me in mail storm. Gonna test it and will write you the results. Overall looks great, but better be sure and run the tests.

Reviewed-by Cyrill Gorcunov <[email protected]>

Quoted 12 lines · Cyrill Gorcunov

Quoted 10 lines · Eric W. Biederman

I can't imagine either of these changes making a practical difference to anyone but I am calling them out in case someone can.

 include/linux/mm_types.h |  1 +
 kernel/fork.c            |  9 ++++++---
 kernel/ptrace.c          | 26 +++++++++++---------------
 mm/init-mm.c             |  2 ++
 4 files changed, 20 insertions(+), 18 deletions(-)

Quoted 6 lines

Thanks a huge, Eric! And really sorry for delay in response, I managed to miss this quite important mail for me in mail storm. Gonna test it and will write you the results. Overall looks great, but better be sure and run the tests.

Reviewed-by Cyrill Gorcunov <[email protected]>

Eric, on which kernel the patch is on top of?
It doesn't apply on linux-next for some reason.

 | Date:   Thu Oct 27 14:21:59 2016 +1100
 | 
 |     Add linux-next specific files for 20161027
 |     
 |     Signed-off-by: Stephen Rothwell <[email protected]>

I applied it on Linus' master and tests passed fine (but they were passing fine even without the patch,
only linux-next failed).

Quoted 29 lines · Cyrill Gorcunov

Quoted 12 lines · Cyrill Gorcunov

Quoted 10 lines · Eric W. Biederman

I can't imagine either of these changes making a practical difference to anyone but I am calling them out in case someone can.

 include/linux/mm_types.h |  1 +
 kernel/fork.c            |  9 ++++++---
 kernel/ptrace.c          | 26 +++++++++++---------------
 mm/init-mm.c             |  2 ++
 4 files changed, 20 insertions(+), 18 deletions(-)

Quoted 6 lines

Thanks a huge, Eric! And really sorry for delay in response, I managed to miss this quite important mail for me in mail storm. Gonna test it and will write you the results. Overall looks great, but better be sure and run the tests.

Reviewed-by Cyrill Gorcunov <[email protected]>

Eric, on which kernel the patch is on top of?
It doesn't apply on linux-next for some reason.

 | Date:   Thu Oct 27 14:21:59 2016 +1100
 | 
 |     Add linux-next specific files for 20161027
 |     
 |     Signed-off-by: Stephen Rothwell <[email protected]>

Quoted 3 lines

I applied it on Linus' master and tests passed fine (but they were passing fine even without the patch,
only linux-next failed).

Odd. I don't think I have taken the old version out of
linux-next yet. So you can probably revert the old version out of
linux-next and apply this one. All of my development at this point is against v4.9-rc1.

I suspect you will find my last version on top of against v4.9-rc1 will pass. Since my tree is only one deep and I don't think anyone except linux-next is based on it, I plan to drop and readd this patch. Especially since it is candidate for backporting.

Mind if I add your tested-by?

To see Linus's tree fail with my patch you can apply the patch below. That is the essence of what I changed to fix things. Just ignoring dumpable when an mm exists.

Mind if I add your tested-by?

To see Linus's tree fail with my patch you can apply the patch below. That is the essence of what I changed to fix things. Just ignoring dumpable when an mm exists.