Thread (10 messages) flat view 10 messages, 3 authors, 2017-08-19

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

From: Andrew Morton <akpm@linux-foundation.org>
Date: 2017-08-17 22:50:37
Also in: linux-mm, lkml

On Tue, 15 Aug 2017 22:18:19 -0400 Rik van Riel [off-list ref] wrote:
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help