Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

On Thu, 2017-08-17 at 15:50 -0700, Andrew Morton wrote:

On Tue, 15 Aug 2017 22:18:19 -0400 Rik van Riel [off-list ref]
wrote:

quoted

quoted

quoted

--- a/mm/madvise.c
+++ b/mm/madvise.c

@@ -80,6 +80,17 @@ static long madvise_behavior(struct

vm_area_struct *vma,
__		}
__		new_flags &= ~VM_DONTCOPY;
__		break;
+	case MADV_WIPEONFORK:
+		/* MADV_WIPEONFORK is only supported on
anonymous
memory. */
+		if (vma->vm_file || vma->vm_flags & VM_SHARED)
{
+			error = -EINVAL;
+			goto out;
+		}
+		new_flags |= VM_WIPEONFORK;
+		break;
+	case MADV_KEEPONFORK:
+		new_flags &= ~VM_WIPEONFORK;
+		break;
__	case MADV_DONTDUMP:
__		new_flags |= VM_DONTDUMP;
__		break;

It seems odd to permit MADV_KEEPONFORK against other-than-anon
vmas?

Given that the only way to set VM_WIPEONFORK is through
MADV_WIPEONFORK, calling MADV_KEEPONFORK on an
other-than-anon vma would be equivalent to a noop.

If new_flags == vma->vm_flags, madvise_behavior() will
immediately exit.

Yes, but calling MADV_WIPEONFORK against an other-than-anon vma is
presumably a userspace bug.  A bug which will probably result in
userspace having WIPEONFORK memory which it didn't want.  The kernel
can trivially tell userspace that it has this bug so why not do so?

Uh, what?

Calling MADV_WIPEONFORK on an other-than-anon vma results
in NOT getting VM_WIPEONFORK semantics on that VMA.

The code you are commenting on is the bit that CLEARS
the VM_WIPEONFORK code, not the bit where it gets set.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>