From: Jann Horn <jannh@google.com>
To: Oleksandr Natalenko <oleksandr@redhat.com>
Cc: kernel list <linux-kernel@vger.kernel.org>,
Kirill Tkhai <ktkhai@virtuozzo.com>,
Hugh Dickins <hughd@google.com>,
Alexey Dobriyan <adobriyan@gmail.com>,
Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@suse.com>,
Matthew Wilcox <willy@infradead.org>,
Pavel Tatashin <pasha.tatashin@soleen.com>,
Greg KH <greg@kroah.com>, Suren Baghdasaryan <surenb@google.com>,
Minchan Kim <minchan@kernel.org>,
Timofey Titovets <nefelim4ag@gmail.com>,
Aaron Tomlin <atomlin@redhat.com>,
Grzegorz Halat <ghalat@redhat.com>,
Linux-MM <linux-mm@kvack.org>,
Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH RFC 4/5] mm/ksm, proc: introduce remote merge
Date: Thu, 16 May 2019 12:00:24 +0200 [thread overview]
Message-ID: <CAG48ez2yXw_PJXO-mS=Qw5rkLpG6zDPd0saMhhGk09-du2bpaA@mail.gmail.com> (raw)
In-Reply-To: <20190516094234.9116-5-oleksandr@redhat.com>
On Thu, May 16, 2019 at 11:43 AM Oleksandr Natalenko
<oleksandr@redhat.com> wrote:
> Use previously introduced remote madvise knob to mark task's
> anonymous memory as mergeable.
>
> To force merging task's VMAs, "merge" hint is used:
>
> # echo merge > /proc/<pid>/madvise
>
> Force unmerging is done similarly:
>
> # echo unmerge > /proc/<pid>/madvise
>
> To achieve this, previously introduced ksm_madvise_*() helpers
> are used.
Why does this not require PTRACE_MODE_ATTACH_FSCREDS to the target
process? Enabling KSM on another process is hazardous because it
significantly increases the attack surface for side channels.
(Note that if you change this to require PTRACE_MODE_ATTACH_FSCREDS,
you'll want to use mm_access() in the ->open handler and drop the mm
in ->release. mm_access() from a ->write handler is not permitted.)
[...]
> @@ -2960,15 +2962,63 @@ static int proc_stack_depth(struct seq_file *m, struct pid_namespace *ns,
> static ssize_t madvise_write(struct file *file, const char __user *buf,
> size_t count, loff_t *ppos)
> {
> + /* For now, only KSM hints are implemented */
> +#ifdef CONFIG_KSM
> + char buffer[PROC_NUMBUF];
> + int behaviour;
> struct task_struct *task;
> + struct mm_struct *mm;
> + int err = 0;
> + struct vm_area_struct *vma;
> +
> + memset(buffer, 0, sizeof(buffer));
> + if (count > sizeof(buffer) - 1)
> + count = sizeof(buffer) - 1;
> + if (copy_from_user(buffer, buf, count))
> + return -EFAULT;
> +
> + if (!memcmp("merge", buffer, min(sizeof("merge")-1, count)))
This means that you also match on something like "mergeblah". Just use strcmp().
> + behaviour = MADV_MERGEABLE;
> + else if (!memcmp("unmerge", buffer, min(sizeof("unmerge")-1, count)))
> + behaviour = MADV_UNMERGEABLE;
> + else
> + return -EINVAL;
>
> task = get_proc_task(file_inode(file));
> if (!task)
> return -ESRCH;
>
> + mm = get_task_mm(task);
> + if (!mm) {
> + err = -EINVAL;
> + goto out_put_task_struct;
> + }
> +
> + down_write(&mm->mmap_sem);
Should a check for mmget_still_valid(mm) be inserted here? See commit
04f5866e41fb70690e28397487d8bd8eea7d712a.
> + switch (behaviour) {
> + case MADV_MERGEABLE:
> + case MADV_UNMERGEABLE:
This switch isn't actually necessary at this point, right?
> + vma = mm->mmap;
> + while (vma) {
> + if (behaviour == MADV_MERGEABLE)
> + ksm_madvise_merge(vma->vm_mm, vma, &vma->vm_flags);
> + else
> + ksm_madvise_unmerge(vma, vma->vm_start, vma->vm_end, &vma->vm_flags);
> + vma = vma->vm_next;
> + }
> + break;
> + }
> + up_write(&mm->mmap_sem);
> +
> + mmput(mm);
> +
> +out_put_task_struct:
> put_task_struct(task);
>
> - return count;
> + return err ? err : count;
> +#else
> + return -EINVAL;
> +#endif /* CONFIG_KSM */
> }
next prev parent reply other threads:[~2019-05-16 10:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-16 9:42 [PATCH RFC 0/5] mm/ksm, proc: introduce remote madvise Oleksandr Natalenko
2019-05-16 9:42 ` [PATCH RFC 1/5] proc: introduce madvise placeholder Oleksandr Natalenko
2019-05-16 9:42 ` [PATCH RFC 2/5] mm/ksm: introduce ksm_madvise_merge() helper Oleksandr Natalenko
2019-05-16 9:42 ` [PATCH RFC 3/5] mm/ksm: introduce ksm_madvise_unmerge() helper Oleksandr Natalenko
2019-05-16 9:42 ` [PATCH RFC 4/5] mm/ksm, proc: introduce remote merge Oleksandr Natalenko
2019-05-16 10:00 ` Jann Horn [this message]
2019-05-16 14:20 ` Oleksandr Natalenko
2019-05-16 14:43 ` Oleksandr Natalenko
2019-05-16 16:09 ` Jann Horn
2019-05-16 16:06 ` Jann Horn
2019-05-16 16:29 ` Aaron Tomlin
2019-05-16 9:42 ` [PATCH RFC 5/5] mm/ksm, proc: add remote madvise documentation Oleksandr Natalenko
2019-05-16 10:44 ` [PATCH RFC 0/5] mm/ksm, proc: introduce remote madvise Michal Hocko
2019-05-16 14:21 ` Oleksandr Natalenko
2019-05-16 17:24 ` Alexey Dobriyan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAG48ez2yXw_PJXO-mS=Qw5rkLpG6zDPd0saMhhGk09-du2bpaA@mail.gmail.com' \
--to=jannh@google.com \
--cc=adobriyan@gmail.com \
--cc=atomlin@redhat.com \
--cc=ghalat@redhat.com \
--cc=greg@kroah.com \
--cc=hughd@google.com \
--cc=ktkhai@virtuozzo.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=nefelim4ag@gmail.com \
--cc=oleksandr@redhat.com \
--cc=pasha.tatashin@soleen.com \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox