Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp381156ybm; Mon, 20 May 2019 18:28:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqwRiH4ZnquQM6aMYeOgCylcbgk+BP6Cmqy3iCBN9HABfFwbE0wscbR9osqTjNRKcMkv6X+Q X-Received: by 2002:a17:902:b20f:: with SMTP id t15mr58704197plr.220.1558402095726; Mon, 20 May 2019 18:28:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558402095; cv=none; d=google.com; s=arc-20160816; b=FJ351Py5RxM9ipsyKS0VYKwSa5l96ypw1QReh5vYiRZiyngLlVc+ef9DuVrw8ZVYrj qxDSTTL8JGdfdVLWrzMK89zF1sJGSbxEv224qbrbg6mF2gMmrZ5f4bcqNuDz5qupqUD7 dONktPFbh1k+OQfBfd11WjrAnNhh0eU6ptygYpWmqf7YrNse/TD07ORh7XGE1g5QaYXB VyE3WidZj9g7o9oP1zdpxMZtMBjNOqxBz82ksl4TvUsfdf/3OqtTv88zgCzxpvvTvmi0 n0m2knBXYzjWBTfX/wK+6iQ7a5T5GbopBUe6IilG/PT6vGaLx1XOKBo8D7gAJsiQTxCJ E/9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=q5tudNQ9cSMh3fCrTxG8NdksCakwJg8DbWSQrWyIrTI=; b=xEKabvbZTDzO4nJ0nBufBrr0lj6LD5sE76sZDs8D4q+AL7hqAWmoNZrz4lDxYskTHM qFV6p0GaoxoZh2155dtsFpBAjqfr8R66ARyRQ81Y0WJPycMJq8znJ2BYiBsIF5au12Fk MLNkZiu6gaO+mn8YYv2Pp2ZuLa2Mlx1UapYeCodIubpB5sJYA2oqPYOkuXhvDZ0B/CMf qds/ksa/rFLxDHElkF5LrBtCc57dOCZIy7ODWmzUYvRqpFv6YGUoKjtrSasseHVmDQne S+8js48VdC4N2rVggy7sW+UMpM7H+n3fYUH6EHqvE8pMXBmHqcZDWPDEffKuHbKMNOP4 kV1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=DLIH2eCP; 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=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o3si18610776plk.167.2019.05.20.18.28.00; Mon, 20 May 2019 18:28:15 -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=fail header.i=@gmail.com header.s=20161025 header.b=DLIH2eCP; 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=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727281AbfEUB05 (ORCPT + 99 others); Mon, 20 May 2019 21:26:57 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:39247 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727043AbfEUB04 (ORCPT ); Mon, 20 May 2019 21:26:56 -0400 Received: by mail-pl1-f193.google.com with SMTP id g9so7556645plm.6 for ; Mon, 20 May 2019 18:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=q5tudNQ9cSMh3fCrTxG8NdksCakwJg8DbWSQrWyIrTI=; b=DLIH2eCPL/TbrcrBJeS072RZfACT/OHayR/cqOaUp7jstN6cQtTJ2IEb2WSwA905Yu CbztJl76ysh8fRQywqbHQMTK4Rtqu2TV+LgMStlkUkwDn4fgj109EcDjDtosETfHillX pAjdbYgfJtj0PofpNUmu9de9BVwPaZ6FWCF4NrS6UB4R2FgmYMg6DFxcPpyMVltTUWf6 1QvvaVsF5RCkX2nLqQFkXPI/4Ia/PTK4vdvU6FjwFgyo5LvCfhUcqE6RfsJ//mYo5vgp zn0yh4FxQMYMqrVG7Uz48HqxvkW8oi1wqdHSvAJdr88NARk0dpExcyT1I9jxgVTaC5O/ m0Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=q5tudNQ9cSMh3fCrTxG8NdksCakwJg8DbWSQrWyIrTI=; b=G/r0knRdE8ew60KYEZOwW/+qq5+CzExaSNCQx6hGLiJLCSYkcuxun9uG89Ag/bwAuY RoARuwLnl1HBoADmkoa/MxB1PlUFGWA8ybxMrOl7U2Wi99YVaY3hwuv/qVvJlbCB09Fq aiAb9GBbA+RRrrgwl37AzuHSXcFT8IUPT1Yh0QoQDXIx4gAs2A76qo8yzcQGo3rl3LWd KM5CQ1esc8HEObXo2oyqzEw6wn5LZRWeO5LjMtxw7F2JiG8a/PuHYv+BGlKQOf7WGqVn nBfJQk32lcgiWyup8WfQHX4LAA60uwE/K7/pgfy/hohffk/2ikozRT/LvUR8dyGJSyTP lRzQ== X-Gm-Message-State: APjAAAXLWdNfgalubcVGpv/o7KoBICW5JW3d0UFaCu1HKLPqmyASek8i Ewge51hfWa/46wMUH6d7/s8= X-Received: by 2002:a17:902:ba8d:: with SMTP id k13mr65556652pls.52.1558402016072; Mon, 20 May 2019 18:26:56 -0700 (PDT) Received: from google.com ([2401:fa00:d:0:98f1:8b3d:1f37:3e8]) by smtp.gmail.com with ESMTPSA id a8sm9209871pfk.14.2019.05.20.18.26.51 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 20 May 2019 18:26:54 -0700 (PDT) Date: Tue, 21 May 2019 10:26:49 +0900 From: Minchan Kim To: Oleksandr Natalenko Cc: Andrew Morton , LKML , linux-mm , Michal Hocko , Johannes Weiner , Tim Murray , Joel Fernandes , Suren Baghdasaryan , Daniel Colascione , Shakeel Butt , Sonny Rao , Brian Geffon Subject: Re: [RFC 4/7] mm: factor out madvise's core functionality Message-ID: <20190521012649.GE10039@google.com> References: <20190520035254.57579-1-minchan@kernel.org> <20190520035254.57579-5-minchan@kernel.org> <20190520142633.x5d27gk454qruc4o@butterfly.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190520142633.x5d27gk454qruc4o@butterfly.localdomain> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Oleksandr, On Mon, May 20, 2019 at 04:26:33PM +0200, Oleksandr Natalenko wrote: > Hi. > > On Mon, May 20, 2019 at 12:52:51PM +0900, Minchan Kim wrote: > > This patch factor out madvise's core functionality so that upcoming > > patch can reuse it without duplication. > > > > It shouldn't change any behavior. > > > > Signed-off-by: Minchan Kim > > --- > > mm/madvise.c | 168 +++++++++++++++++++++++++++------------------------ > > 1 file changed, 89 insertions(+), 79 deletions(-) > > > > diff --git a/mm/madvise.c b/mm/madvise.c > > index 9a6698b56845..119e82e1f065 100644 > > --- a/mm/madvise.c > > +++ b/mm/madvise.c > > @@ -742,7 +742,8 @@ static long madvise_dontneed_single_vma(struct vm_area_struct *vma, > > return 0; > > } > > > > -static long madvise_dontneed_free(struct vm_area_struct *vma, > > +static long madvise_dontneed_free(struct task_struct *tsk, > > + struct vm_area_struct *vma, > > struct vm_area_struct **prev, > > unsigned long start, unsigned long end, > > int behavior) > > @@ -754,8 +755,8 @@ static long madvise_dontneed_free(struct vm_area_struct *vma, > > if (!userfaultfd_remove(vma, start, end)) { > > *prev = NULL; /* mmap_sem has been dropped, prev is stale */ > > > > - down_read(¤t->mm->mmap_sem); > > - vma = find_vma(current->mm, start); > > + down_read(&tsk->mm->mmap_sem); > > + vma = find_vma(tsk->mm, start); > > if (!vma) > > return -ENOMEM; > > if (start < vma->vm_start) { > > @@ -802,7 +803,8 @@ static long madvise_dontneed_free(struct vm_area_struct *vma, > > * Application wants to free up the pages and associated backing store. > > * This is effectively punching a hole into the middle of a file. > > */ > > -static long madvise_remove(struct vm_area_struct *vma, > > +static long madvise_remove(struct task_struct *tsk, > > + struct vm_area_struct *vma, > > struct vm_area_struct **prev, > > unsigned long start, unsigned long end) > > { > > @@ -836,13 +838,13 @@ static long madvise_remove(struct vm_area_struct *vma, > > get_file(f); > > if (userfaultfd_remove(vma, start, end)) { > > /* mmap_sem was not released by userfaultfd_remove() */ > > - up_read(¤t->mm->mmap_sem); > > + up_read(&tsk->mm->mmap_sem); > > } > > error = vfs_fallocate(f, > > FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, > > offset, end - start); > > fput(f); > > - down_read(¤t->mm->mmap_sem); > > + down_read(&tsk->mm->mmap_sem); > > return error; > > } > > > > @@ -916,12 +918,13 @@ static int madvise_inject_error(int behavior, > > #endif > > What about madvise_inject_error() and get_user_pages_fast() in it > please? Good point. Maybe, there more places where assume context is "current" so I'm thinking to limit hints we could allow from external process. It would be better for maintainance point of view in that we could know the workload/usecases when someone ask new advises from external process without making every hints works both contexts. Thanks.