Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp416022yba; Thu, 16 May 2019 03:03:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqxwCjmAgOXSVCE0VvuGaJF/cNxLxkpVBihOJ6nt7jCocxm9iaWtXpS+WlZeYfHr0chhwWJ+ X-Received: by 2002:a62:5f02:: with SMTP id t2mr12946636pfb.7.1558001030748; Thu, 16 May 2019 03:03:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558001030; cv=none; d=google.com; s=arc-20160816; b=vuiFfMQzxWh5N3kyKHAkn9f78ahZYRZLtdIsUd1C10+3OLudtiwmIfuyYU/Omt+Fq/ uZfuNNyEIDriG6iVZRqr3Hf8K9xKtkx0LYTCe9QEK4MLuAFzZpJCc8qtw5EpkM49wffM og12Yd5PDf+65YBkT7WrzcJycHNcB4ck0z19ynQe8NOsrY3DbaAnIoMtKnFDxinFLO3s aFxnHSn6bLNEbnjN4OeFAI4oQEWgftwaKLJdf22cO0sjgjVyQE24j7Z0wVKgIwznkkpz UPK+W/9r/aPIETEmBvYoi3BAThah6SHXy3LwcqJOnwH34d/+3um7vRfvtyFzDTvU7pdm tJCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=dC3aSgv+o3HSYvM8J8FMKymuhEQ4FThUEnqG0ntB4g0=; b=ayRc/1z4yTNETZ1NruUVVn6FegZXoJkCrwAC1GRB76xy2a4rPsxaB+UBlvucPB4QMc f3MzhUlK7H3gdW7AdP5n2gZgukqm0bTTU9Eqdolzc0dgNDpqU6Nwrx5xHvrVonMOlZjI XGjlThU5fN1icq42JBho7kov8Sm/p5JgyVPCo5X096vvOW96Ngkr47VEppDH/2GMcifo 7mTsw6nP2wrrnfuA12GzzKyHiEgJoXsGdtqNW5+IwAQTLDwSy4QIKk+nBw4+KkMnxtGv wDgKk8rgt5cCBYUzBpWC2CxhkHAZ07sbS5H47V7OZSh4D2OoFHve5Vk0WQJ5zM3aO5FU UYnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=rusCImqc; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a1si4455982pln.75.2019.05.16.03.03.34; Thu, 16 May 2019 03:03:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=rusCImqc; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727157AbfEPKAw (ORCPT + 99 others); Thu, 16 May 2019 06:00:52 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:40665 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726374AbfEPKAw (ORCPT ); Thu, 16 May 2019 06:00:52 -0400 Received: by mail-oi1-f194.google.com with SMTP id r136so2053937oie.7 for ; Thu, 16 May 2019 03:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dC3aSgv+o3HSYvM8J8FMKymuhEQ4FThUEnqG0ntB4g0=; b=rusCImqcsRelViq7BjTj8x6kkzQ7cL9BId6Q2hif54CzbiF2xexI8tw8D5bQ3Q6HLt l4Fc8osLWvc/mFIQ0lcIGpQelUQltkxqLGCz+/Oe6Un0I0xiembCGtk90t1JUC8cFExL hiM8oJYcfzEbVRzLR+jVGIv2X+WSy8ArgEm6sDYpKjifpSCcPcFIaQ42Qg4wirz6BBHO RKDlH9nba+5XQn6n19kOSVR/TU/lT++yDt/HW6vWFf86nDvW72knrug0SBpJeZIKzOOD W5xi2wekab69fIhm12WD6de9sXy3LG6XrRTh7bl6poYUh4ZyEl4VUbR4nVo667mnp3wj UpsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dC3aSgv+o3HSYvM8J8FMKymuhEQ4FThUEnqG0ntB4g0=; b=sApnQiaqw7TsHuGIkQWgfU763oXzm35MlNVctvaRoP/fjVck21eQJyCqR/EeRDxhNf qTsNkm4TzSJ4DloSvmKPwNm1Q6e2jccqKi5I6QoGDURLU0OF5JGQHGg39/mzJBWblvQE cy36DkSbTBR9Jk9nY85mQF0e5lcxgMgfRnzH9AJYM7eI0iSuEES0eanjvM5a1BA8rdkP /zA7WdE7C57p39LbEVwvb53O6r8HWopG9jCxod9F6/hMWeBA4eTOzeiInrt2svdWZrSI xE4XszQOvvmDbf08gk5L4WQgL7orMfvGJqk8hBkCxQNUW/1a6fpC3OtdXFrciLsa8k92 InLg== X-Gm-Message-State: APjAAAUYRnoc/gV5ePKTo+pkIomjeXoc3nStowq1h24KJMnm3hjtPl7h 4kI4ZkMjG6aqmLDXZT6Q2+uc2GfBPrjfFJGa1g6pxw== X-Received: by 2002:aca:180d:: with SMTP id h13mr9485857oih.39.1558000850840; Thu, 16 May 2019 03:00:50 -0700 (PDT) MIME-Version: 1.0 References: <20190516094234.9116-1-oleksandr@redhat.com> <20190516094234.9116-5-oleksandr@redhat.com> In-Reply-To: <20190516094234.9116-5-oleksandr@redhat.com> From: Jann Horn Date: Thu, 16 May 2019 12:00:24 +0200 Message-ID: Subject: Re: [PATCH RFC 4/5] mm/ksm, proc: introduce remote merge To: Oleksandr Natalenko Cc: kernel list , Kirill Tkhai , Hugh Dickins , Alexey Dobriyan , Vlastimil Babka , Michal Hocko , Matthew Wilcox , Pavel Tatashin , Greg KH , Suren Baghdasaryan , Minchan Kim , Timofey Titovets , Aaron Tomlin , Grzegorz Halat , Linux-MM , Linux API Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 16, 2019 at 11:43 AM Oleksandr Natalenko 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//madvise > > Force unmerging is done similarly: > > # echo unmerge > /proc//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 */ > }