From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0E50C4360C for ; Wed, 2 Oct 2019 20:28:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5C066217D7 for ; Wed, 2 Oct 2019 20:28:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="KYUs3SsA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5C066217D7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E2BDC6B0007; Wed, 2 Oct 2019 16:28:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DD1816B0008; Wed, 2 Oct 2019 16:28:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C498F6B000A; Wed, 2 Oct 2019 16:28:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0219.hostedemail.com [216.40.44.219]) by kanga.kvack.org (Postfix) with ESMTP id 9E6836B0007 for ; Wed, 2 Oct 2019 16:28:01 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 31FD16110 for ; Wed, 2 Oct 2019 20:28:01 +0000 (UTC) X-FDA: 75999981162.23.dogs90_bb75b2dd161a X-HE-Tag: dogs90_bb75b2dd161a X-Filterd-Recvd-Size: 5721 Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Wed, 2 Oct 2019 20:28:00 +0000 (UTC) Received: by mail-lj1-f195.google.com with SMTP id b20so245183ljj.5 for ; Wed, 02 Oct 2019 13:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XdihLjEHzl6Bdj0J0VKybnqHBrV7BKaKSpUBn6TrYd8=; b=KYUs3SsAkfuNreQPOWd8l020BqbDHgpj9kTZh1yMHxS9XVgi7DHbvGyVzHZ+0SNoXF ZcvynCNbqW9sTmshD9EY97xPxWMOO+506YH04ZNWdgpzm5t/SR15nnl6ka9+ZDTIp/AU emU5WeC6YsTuq2VNWkuBYXMY7brJ+Ydm3TMCE= 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:content-transfer-encoding; bh=XdihLjEHzl6Bdj0J0VKybnqHBrV7BKaKSpUBn6TrYd8=; b=nRHlTGsHRF60jMRG6GReKXINZikIg7E7dbxrKC3O/qRI/QCzB1xICFU8ajMCDIcDLi O65rhGugbYmouH6FzhksajyfVvHcN/qf6IgzoLARg3snnT2sEyqDgb3BeANmOx67r5+b sDsgvMI88rJ2x7NOrw7ZYVJDxIq/HHqd/nUyHr03jcJLBmuucJXS6DgjAIWCUBIdr/vj ExiAN0qjb3BO6t7Gp/IxAx4FzLKfs4SAzvCPxWICm6jPspNHn6XHxEwMB97M0QeAz89M j1MrQ+XCliWMizNDPIEnpQIrTU0z94Xae6lzuqaY2zNRnOq4v6fnyGazoVTrjBkTpYZ6 /xiQ== X-Gm-Message-State: APjAAAVfDRC1w9cFMVVoqy7BVuM8bsk/k4QmbjlCge6JZPLYqHNjwerv 5qoyU8OU5x0bxFVVe8VolqibAnxcqDQ= X-Google-Smtp-Source: APXvYqyFzT62ZZ0fC48uSKalDuGoV9VKOfUSYs7AAlk9FWE98jT7SAEoq+fq8cytuYxVTtkETwhVcg== X-Received: by 2002:a2e:6344:: with SMTP id x65mr3559798ljb.59.1570048078567; Wed, 02 Oct 2019 13:27:58 -0700 (PDT) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com. [209.85.167.43]) by smtp.gmail.com with ESMTPSA id l16sm96292lja.34.2019.10.02.13.27.57 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Oct 2019 13:27:57 -0700 (PDT) Received: by mail-lf1-f43.google.com with SMTP id w67so74235lff.4 for ; Wed, 02 Oct 2019 13:27:57 -0700 (PDT) X-Received: by 2002:a19:741a:: with SMTP id v26mr3467833lfe.79.1570048077142; Wed, 02 Oct 2019 13:27:57 -0700 (PDT) MIME-Version: 1.0 References: <20191002134730.40985-1-thomas_os@shipmail.org> <20191002134730.40985-4-thomas_os@shipmail.org> <516814a5-a616-b15e-ac87-26ede681da85@shipmail.org> In-Reply-To: <516814a5-a616-b15e-ac87-26ede681da85@shipmail.org> From: Linus Torvalds Date: Wed, 2 Oct 2019 13:27:41 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 3/7] mm: Add write-protect and clean utilities for address space ranges To: =?UTF-8?Q?Thomas_Hellstr=C3=B6m_=28VMware=29?= Cc: Linux-MM , Linux Kernel Mailing List , Thomas Hellstrom , Andrew Morton , Matthew Wilcox , Will Deacon , Peter Zijlstra , Rik van Riel , Minchan Kim , Michal Hocko , Huang Ying , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , "Kirill A . Shutemov" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Oct 2, 2019 at 12:09 PM Thomas Hellstr=C3=B6m (VMware) wrote: > > Yes I typically tend towards using a "namespace_object_operation" naming > scheme, with "as_dirty" being the namespace here, We discourage that kind of mindless namespacing for core stuff. It makes sense in a driver or a filesystem: when there are 20+ different filesystems all implementing the same operation, you can't have descriptive and natural names that are unique. So having a namespace prefix for the filesystem or driver makes sense. But even then it tends ot be just a simple name, not the op it does. > Looking at Matthew's suggestion but lining up with > "unmap_mapping_range()", perhaps we could use "clean_mapping_range" and > "wp_mapping_range"? Yes, I agree with Willy that "dirty" is kind of implicit when the operation is to clean something, so the above sounds sane to me. The wp part I'm not entirely sure about: you're not actually write-protecting the range. You're doing something different. You're only doing it for shared writable mappings. And I'd rather see separate 'struct mm_walk_ops' than shared ones that then have a flag in a differfent structure to change behavior. Yes, yes, some of the levels share the same logic, but that just means that you can use the same function pointer for that level in the different "clean" vs "wp" mm_walk_op. Also, looking closer at this patch, this makes me go "Whaa?": + pte =3D (mm =3D=3D &init_mm) ? + pte_offset_kernel(pmd, addr) : + pte_offset_map_lock(mm, pmd, addr, &ptl); because I don't think that's sensible. When do you have a vma in kernel spa= ce? Also, why do you loop inside the pmd_entry function, instead of just having a pte_entry function? Linus