From patchwork Wed Jan 23 22:23:07 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jerome Glisse X-Patchwork-Id: 10777971 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 8DF491390 for ; Wed, 23 Jan 2019 22:23:36 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7FDCF2D368 for ; Wed, 23 Jan 2019 22:23:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 738D82D396; Wed, 23 Jan 2019 22:23:36 +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=unavailable 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 E4E9C2D368 for ; Wed, 23 Jan 2019 22:23:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4699C8E004F; Wed, 23 Jan 2019 17:23:34 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 415DB8E0047; Wed, 23 Jan 2019 17:23:34 -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 3048B8E004F; Wed, 23 Jan 2019 17:23:34 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by kanga.kvack.org (Postfix) with ESMTP id 091588E0047 for ; Wed, 23 Jan 2019 17:23:34 -0500 (EST) Received: by mail-qt1-f198.google.com with SMTP id n50so4350077qtb.9 for ; Wed, 23 Jan 2019 14:23:34 -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=Ah2At7Z9WHVesdrMLiCK0xNMPj6Yxfh/2asilkzerWc=; b=Pb9RDlBtJPydFo6h/9MFX0r2ufEzL3MNK7iaWpgu8ob6F/IiGt4xk1pfDMDrQHnDVE 9pKKqHffvsuCH+eIo7P13KLDuWlAY3udkpP6ndR2kV4yGkzpe4M1Vmww1uYAmAiXtQXs XEkZxTkZWTEf33FJpKBNjiq0jF6b+iVKkCozagC3qt0CE+dIOB0TyfjjnCrYbY3NJU0n ojY9Bby0/tGbAdMrVj2o2nQIq5wSvq/ohGjuI1XOcLSB2VX/Otd3qZjNSQTrHFiY0s9D 1EIwIqoiGPKVEyGQPa1j1URXSCocTO3725ANXYzwr0BbYz7BclTDspjBvjeX68IhG2yK kfJQ== 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: AJcUukeztNmcS51rbc+6RoBxb/CuKmpXDXhNpCE6jjw2Pkn0/ri+YEhQ VnFNXT6rcxJ9oNtT2s4wFzOBD5gb4KC8qokL52RvJ25rat49mmOPnt02bpvFLqUBq6eWuqpEJf2 9GbJOIzILDEIuZ9HmKvW3a5y1SHlmp35np5mTXD7jvI5sc8DF32NUrFXh8RPxwQDOdg== X-Received: by 2002:a37:7cc5:: with SMTP id x188mr3308050qkc.307.1548282213748; Wed, 23 Jan 2019 14:23:33 -0800 (PST) X-Google-Smtp-Source: ALg8bN5E4gKbBW6irRY6OSWxxadsG8bMC5LBjRtVg8fGKfaceEMegsaJGpvKJvxzKySh5fe1DxRs X-Received: by 2002:a37:7cc5:: with SMTP id x188mr3308032qkc.307.1548282213248; Wed, 23 Jan 2019 14:23:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548282213; cv=none; d=google.com; s=arc-20160816; b=EFnEys3Lfl39CCbhpgZlgBnSaqziYb5OXTmgkak3AZNTF8kgmlgntCydlqIcdhrEfq zF7AMXcUNQOAUo4bqg+C5eWfFsk3FYvi3qejEryht6+5UXXKHMVH/0gUAhQGKkmUjwSY m4NSikmtVMfuJNrb6K9gbj9uRkTyiIs0+gE4a8s8oSpnlcoBSji/Mjm0RnoQtAgSFvF0 JRU/GeuDNV00tvgWwDFu7woDCq3RdsW6edWvPDRVXkOUXjrrhkqX+n3l9KHEob6iX4/s rFRqCIqahifXxQ6ZUERPQ8oFyQ8cHlIoEAZPVwA0/K4AZEkQ+R8vrn7nE7gHpv2QkH3m IP0g== 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=Ah2At7Z9WHVesdrMLiCK0xNMPj6Yxfh/2asilkzerWc=; b=k+7ckw0Smrsh8dwKV19ruTKAC5yYtmM+Rdw0SjJ2bHZoFC0RYCCiD6bJq3u+/veACH dIfgeS30T7ALxNAQ77ZesSEUO6GSdzPkFvo7bX6XBF7L4Kl51Y/CltLnlYyhs0xXPm8U 02zZ4XCJaZPL6RA5rbUqUhNPDfheBf9vIRxwaH6iBoKEVPWIvvKBxs37v9Vn0+xNV7tx kQ1Yf+h6/CjSxkbpel918GDBUzp52bDhZhecDoPlUgfdbgz0whgUfvMPBpS9KsLmjJJI t2+6eYsRFyH+aBbzTzJ3QXeimv8aojTmaqR4rFFBrZE6Pi5Mw/SjN8unqOlOFjnqdphR 8etw== 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 r65si8550397qtd.301.2019.01.23.14.23.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Jan 2019 14:23:33 -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-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 20E67461FF; Wed, 23 Jan 2019 22:23:32 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-120-127.rdu2.redhat.com [10.10.120.127]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7FF865D964; Wed, 23 Jan 2019 22:23:29 +0000 (UTC) From: jglisse@redhat.com To: linux-mm@kvack.org Cc: Andrew Morton , linux-kernel@vger.kernel.org, =?utf-8?b?SsOpcsO0bWUgR2xpc3Nl?= , =?utf-8?q?Christian_?= =?utf-8?q?K=C3=B6nig?= , Jan Kara , Felix Kuehling , Jason Gunthorpe , Matthew Wilcox , 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, linux-fsdevel@vger.kernel.org, Arnd Bergmann Subject: [PATCH v4 1/9] mm/mmu_notifier: contextual information for event enums Date: Wed, 23 Jan 2019 17:23:07 -0500 Message-Id: <20190123222315.1122-2-jglisse@redhat.com> In-Reply-To: <20190123222315.1122-1-jglisse@redhat.com> References: <20190123222315.1122-1-jglisse@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 23 Jan 2019 22:23:32 +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: Jan Kara Cc: Felix Kuehling Cc: Jason Gunthorpe Cc: Andrew Morton Cc: Matthew Wilcox Cc: Ross Zwisler Cc: Dan Williams Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Michal Hocko Cc: Ralph Campbell Cc: John Hubbard Cc: kvm@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-rdma@vger.kernel.org Cc: linux-fsdevel@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 4050ec1c3b45..abc9dbb7bcb6 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 /*