From patchwork Tue Mar 26 16:47:43 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jerome Glisse X-Patchwork-Id: 10871617 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 8C5C0139A for ; Tue, 26 Mar 2019 16:48:18 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 75B6828D00 for ; Tue, 26 Mar 2019 16:48:18 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 69BA228D5D; Tue, 26 Mar 2019 16:48:18 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BD2F228D00 for ; Tue, 26 Mar 2019 16:48:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E23C6B028D; Tue, 26 Mar 2019 12:48:12 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 8910D6B0290; Tue, 26 Mar 2019 12:48:12 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 70F136B0291; Tue, 26 Mar 2019 12:48:12 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by kanga.kvack.org (Postfix) with ESMTP id 4E4416B028D for ; Tue, 26 Mar 2019 12:48:12 -0400 (EDT) Received: by mail-qt1-f200.google.com with SMTP id x58so14159794qtc.1 for ; Tue, 26 Mar 2019 09:48:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:from:to:cc :subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=qd+j517MeUYcwakOP+kXZkhhiv8aT+TIOX0bOZ6xYI0=; b=kxZD11mOb4iRe6Py1bMZMcKOBl+gTiMflzs7sxcIpoHXagUvK0K4otr/vlIP3lqmgS Ii291Cagjrj1a6gRg2o9Jk5uZ+pBRWgFhfsEqMamAbxm8nUNdyvGRpQqRyJiVsl7BpJF bfTP8/qma8MqLNRd3zYEZrr2MoAf94PhMa0wNAlDSDd3UqRCecnt5vT0YGMgPd0HTELb shkfHDzlCOjXdwXg133yASfWhlziRRWAgYguoHOlY2cGTVU6H6gy3WkhfshBbbfPE7/i QGwKdR7ihqKHHyvmTyWj8TzaETFwsKpzlrC7DNR7vM3A+YpvjPoLeHjz0z90bN4nouu3 5nsQ== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of jglisse@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=jglisse@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com X-Gm-Message-State: APjAAAVi11TrePEu1AadhI/QT1zAU4GbNYSGflYlbwQ2dhG4Gy0LYUNV sv7v+fx9UKW+WPgrCvkCnaEZWbScC+n/RlGt8ympeHwk+kjm+KC9K1nkhMjLIIIcYOwGnspgsp1 0z9KKjMhSCBfW5/2JvsE0VMIeihLU98sWlC2UtRmQZWK5dnP0clq7O1lI7MRGHM43oQ== X-Received: by 2002:a0c:b00c:: with SMTP id k12mr26923791qvc.118.1553618892079; Tue, 26 Mar 2019 09:48:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqweGED+Fpk4SZn7BTvuU2FSSM3nHji3fcEPiZfHyTjNAe/JGSID5nTY0QXv/Fmkk9RuhhJ2 X-Received: by 2002:a0c:b00c:: with SMTP id k12mr26923743qvc.118.1553618891440; Tue, 26 Mar 2019 09:48:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553618891; cv=none; d=google.com; s=arc-20160816; b=qQxk3IAUgi+DYvKQc5P8kZ5J8DmPbuCQQ4Vef88eGh9coIPCLNMoS1WwNwVOzFgtxC uDxKCPJ3lddMOQtM35WkpQ+VFanxjuW5lYb+RMDKt5Q2gfHZgl1gYuwcbu2XpvNbeFSg EULSuFiSFIAmWvmjvTCM46heOMWBUcX8CP/WVt7bDZUEESg64Ws5QAzUaRxZwAdcFqGe DMDZFZv9YXjtYbFHm74Xm59b7rGo3V71BVQbjPoiudT4LBYRqMBFhCmPfvSmRutzwPOZ Dd5u8i8XwhEUDk7hBCNkJ0KmZStFfx2c8W8nqabcRCQgruRVpEAbAAz2cQigP9YXT9OC keaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from; bh=qd+j517MeUYcwakOP+kXZkhhiv8aT+TIOX0bOZ6xYI0=; b=Uc1Rl4lUSNnwawnHmkTfsLjmOm/G1a5q0CDKqfmCpLReVUe7Lj5lP7S+jZjOzxBO8N 7rZy72VD/iX7nvcXqJzTvRcPXBVBzPrtUflcoh3lRnSjhBnNMYkghVvGckJ4i0YC0/Dq zhYghU+Nc7yeLshKElEJtbXMrp7fq0Wfg1FFOb8CVTqx+lSf4K8QQzREOUvxSA2Eu+fg s1lms/Rv3Cl3ILdZv3p2/HBBx4QqUIebiK9PiqsokydsX8uG2er6wQqvNOJmutbVTF+R WXD1hMcuyZ2uIR29Kd9Uy0Z3tySTuB0VEdprbGViAviFyDUZNVqhNVo/QFR4XsSDoOSI mM2Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of jglisse@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=jglisse@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id a66si3571927qkg.30.2019.03.26.09.48.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 09:48:11 -0700 (PDT) Received-SPF: pass (google.com: domain of jglisse@redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; Authentication-Results: mx.google.com; spf=pass (google.com: domain of jglisse@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=jglisse@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 761CCC04B2F6; Tue, 26 Mar 2019 16:48:10 +0000 (UTC) Received: from localhost.localdomain.com (unknown [10.20.6.236]) by smtp.corp.redhat.com (Postfix) with ESMTP id 53C89176B1; Tue, 26 Mar 2019 16:48:08 +0000 (UTC) From: jglisse@redhat.com To: linux-kernel@vger.kernel.org Cc: =?utf-8?b?SsOpcsO0bWUgR2xpc3Nl?= , Andrew Morton , linux-mm@kvack.org, =?utf-8?q?Ch?= =?utf-8?q?ristian_K=C3=B6nig?= , Joonas Lahtinen , Jani Nikula , Rodrigo Vivi , Jan Kara , Andrea Arcangeli , Peter Xu , Felix Kuehling , Jason Gunthorpe , Ross Zwisler , Dan Williams , Paolo Bonzini , =?utf-8?b?UmFkaW0gS3LEjW3DocWZ?= , Michal Hocko , Ralph Campbell , John Hubbard , kvm@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-rdma@vger.kernel.org, Arnd Bergmann Subject: [PATCH v6 4/8] mm/mmu_notifier: contextual information for event enums Date: Tue, 26 Mar 2019 12:47:43 -0400 Message-Id: <20190326164747.24405-5-jglisse@redhat.com> In-Reply-To: <20190326164747.24405-1-jglisse@redhat.com> References: <20190326164747.24405-1-jglisse@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 26 Mar 2019 16:48:10 +0000 (UTC) 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: X-Virus-Scanned: ClamAV using ClamSMTP From: Jérôme Glisse CPU page table update can happens for many reasons, not only as a result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also as a result of kernel activities (memory compression, reclaim, migration, ...). This patch introduce a set of enums that can be associated with each of the events triggering a mmu notifier. Latter patches take advantages of those enum values. - UNMAP: munmap() or mremap() - CLEAR: page table is cleared (migration, compaction, reclaim, ...) - PROTECTION_VMA: change in access protections for the range - PROTECTION_PAGE: change in access protections for page in the range - SOFT_DIRTY: soft dirtyness tracking Being able to identify munmap() and mremap() from other reasons why the page table is cleared is important to allow user of mmu notifier to update their own internal tracking structure accordingly (on munmap or mremap it is not longer needed to track range of virtual address as it becomes invalid). Signed-off-by: Jérôme Glisse Cc: Andrew Morton Cc: linux-mm@kvack.org Cc: Christian König Cc: Joonas Lahtinen Cc: Jani Nikula Cc: Rodrigo Vivi Cc: Jan Kara Cc: Andrea Arcangeli Cc: Peter Xu Cc: Felix Kuehling Cc: Jason Gunthorpe Cc: Ross Zwisler Cc: Dan Williams Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Michal Hocko Cc: Christian Koenig Cc: Ralph Campbell Cc: John Hubbard Cc: kvm@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-rdma@vger.kernel.org Cc: Arnd Bergmann --- include/linux/mmu_notifier.h | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h index c8672c366f67..2386e71ac1b8 100644 --- a/include/linux/mmu_notifier.h +++ b/include/linux/mmu_notifier.h @@ -10,6 +10,36 @@ struct mmu_notifier; struct mmu_notifier_ops; +/** + * enum mmu_notifier_event - reason for the mmu notifier callback + * @MMU_NOTIFY_UNMAP: either munmap() that unmap the range or a mremap() that + * move the range + * + * @MMU_NOTIFY_CLEAR: clear page table entry (many reasons for this like + * madvise() or replacing a page by another one, ...). + * + * @MMU_NOTIFY_PROTECTION_VMA: update is due to protection change for the range + * ie using the vma access permission (vm_page_prot) to update the whole range + * is enough no need to inspect changes to the CPU page table (mprotect() + * syscall) + * + * @MMU_NOTIFY_PROTECTION_PAGE: update is due to change in read/write flag for + * pages in the range so to mirror those changes the user must inspect the CPU + * page table (from the end callback). + * + * @MMU_NOTIFY_SOFT_DIRTY: soft dirty accounting (still same page and same + * access flags). User should soft dirty the page in the end callback to make + * sure that anyone relying on soft dirtyness catch pages that might be written + * through non CPU mappings. + */ +enum mmu_notifier_event { + MMU_NOTIFY_UNMAP = 0, + MMU_NOTIFY_CLEAR, + MMU_NOTIFY_PROTECTION_VMA, + MMU_NOTIFY_PROTECTION_PAGE, + MMU_NOTIFY_SOFT_DIRTY, +}; + #ifdef CONFIG_MMU_NOTIFIER /*