From patchwork Tue Feb 19 20:04:25 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jerome Glisse X-Patchwork-Id: 10820727 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 3970014E1 for ; Tue, 19 Feb 2019 20:05:14 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2750E2CAAF for ; Tue, 19 Feb 2019 20:05:14 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1BB9A2CB8E; Tue, 19 Feb 2019 20:05:14 +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 7668C2CAAF for ; Tue, 19 Feb 2019 20:05:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D95628E0008; Tue, 19 Feb 2019 15:05:11 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id D6B728E0002; Tue, 19 Feb 2019 15:05:11 -0500 (EST) 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 C5BBD8E0008; Tue, 19 Feb 2019 15:05:11 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by kanga.kvack.org (Postfix) with ESMTP id 9E2EF8E0002 for ; Tue, 19 Feb 2019 15:05:11 -0500 (EST) Received: by mail-qk1-f199.google.com with SMTP id b187so620485qkf.3 for ; Tue, 19 Feb 2019 12:05:11 -0800 (PST) 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=d3L8LEk8AB5D2JhmIyE9exlLcnknyD9XBU5141tFhtg=; b=ZPWqLWhIT+IN2zn1urX4b8MkeEj0V9qvXUfgCOqc4l89ablYCfVEjwEEK55krRKuZe 23t7XjzCRAT1N/32yV+Wk0/jW3YQpMXwnuB0d/Bxqf2t7sZN2FCTAqTVGtz/tHr8nkL6 X5jVRHVBRTstSNOshjjeCx+/mvLbvY7eRrdVsf9Hd2PufhyTZ07dXwnP2hhVzgzw/vM1 hYgjVud7mfr9Z2F3ly5N/2p9b4h5T/onWS1FW+F3OpsGRTG7Uesc3u5bKjTYr7MpBrW4 d0f2SsUtJzJgUUOhPv0zxi3nvQla7CSzBqgwIWkxfIOw0vEFShaoHv3/NOFP3bxfwv7G SICg== 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: AHQUAuZJiRxfuf3s0Qb2QdlI4jedotKmvWfvQ3ftu+TjkHdHJS+Apx6K EXVvkD2sJe3epRwefWQbc0ZAhBUKQdStWmbNuPH8swOy3hv6YaGE7N8X3Y6DjpEh553tgq1T77l fpPNCj8MfUHkgGxdBcQmtBD+E7DAF8w2G5i1sTnVxb8Tc96CdQ4LWaZJ9uec886ihGA== X-Received: by 2002:a0c:b626:: with SMTP id f38mr22923248qve.166.1550606711340; Tue, 19 Feb 2019 12:05:11 -0800 (PST) X-Google-Smtp-Source: AHgI3IamSLLCTOYTovvsjQtsm2kJ0cte4BRI4zSwo1a6s09HBrE/iphhFvSf5IS/TqwWpPFFgppN X-Received: by 2002:a0c:b626:: with SMTP id f38mr22923167qve.166.1550606710339; Tue, 19 Feb 2019 12:05:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550606710; cv=none; d=google.com; s=arc-20160816; b=ultoW2sAyCrsPbyTgAJnTCDs7TX5XYZ6Mpw84FZuCqAgwWGnT4Y7U7GXvtneXcXqMT lXAW2wh5aIkdackllU0jZhqOhEuN6OzrOUr/8XCWgRn4Qo3HwaXdOhxYeXcxOV3yblgu 5ojT43MfVWYldee45+pmdYHtQ4CV9dPsn1CkNQD9zzZOjFmRnpB5fx1e3un9reKjn12J 7GYgGMqWDuUG0TlMciEOmMF8eFcrdV0rUP2t/9YxhIzRZP4I2PICP3cIlXVlj57WYdOa fUo0woIvrVlCyIXE7VSqru5aNz/6daWoownJodN/qpapB/+qxrRiRhj5UqgTm2Z8/LsJ Y4Eg== 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=d3L8LEk8AB5D2JhmIyE9exlLcnknyD9XBU5141tFhtg=; b=CateUk9GBW2UxpFJ0Kn00l1c937ZcOEggx1Y5tk1MxDEzvW2xYpKtdCZpL+zK9JxMy ho4TpJp1QHhm6D6eiyceW0uZXFNl6Su2xXY2N2yGfB97IstG6fCSPD0Ri+tXHwcRxC8c yBMEeNpVQLzZBYBsfXPckbTtzzqi/mZ/z56vsNWGlanvr+PdJpV1fd5hYON5YZ3vBMCi Po/NOIZkwMCCMxbjh/cD6DwpMefFaU3lHzVP4Qs+PeLy8ZS/Wai6Y3NgAYabWRWQatNX erGk1PmG/5bNpe30lN2i06qgjU7MDFKYdsYogqZw8ilf0xjBCDslXE+32V7pc844Itsb YIfw== 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 r46si2248581qta.43.2019.02.19.12.05.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Feb 2019 12:05:10 -0800 (PST) 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-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DB5ADC1047E2; Tue, 19 Feb 2019 20:05:08 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-122-134.rdu2.redhat.com [10.10.122.134]) by smtp.corp.redhat.com (Postfix) with ESMTP id 32198600C8; Tue, 19 Feb 2019 20:04:57 +0000 (UTC) From: jglisse@redhat.com To: linux-mm@kvack.org, Andrew Morton Cc: linux-kernel@vger.kernel.org, =?utf-8?b?SsOpcsO0bWUgR2xpc3Nl?= , =?utf-8?q?Christian_?= =?utf-8?q?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 v5 4/9] mm/mmu_notifier: contextual information for event enums Date: Tue, 19 Feb 2019 15:04:25 -0500 Message-Id: <20190219200430.11130-5-jglisse@redhat.com> In-Reply-To: <20190219200430.11130-1-jglisse@redhat.com> References: <20190219200430.11130-1-jglisse@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 19 Feb 2019 20:05:09 +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: 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 /*