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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C3262C433F5 for ; Tue, 12 Oct 2021 23:21:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 577D660E78 for ; Tue, 12 Oct 2021 23:21:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 577D660E78 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id D78B06B006C; Tue, 12 Oct 2021 19:21:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D01766B0071; Tue, 12 Oct 2021 19:21:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA233900002; Tue, 12 Oct 2021 19:21:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0054.hostedemail.com [216.40.44.54]) by kanga.kvack.org (Postfix) with ESMTP id A72796B006C for ; Tue, 12 Oct 2021 19:21:00 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 55CFE2D4B9 for ; Tue, 12 Oct 2021 23:21:00 +0000 (UTC) X-FDA: 78689357880.35.32DEFF7 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf01.hostedemail.com (Postfix) with ESMTP id F27805070E5E for ; Tue, 12 Oct 2021 23:20:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634080859; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0YWw1Q0O2bPasj7SCnF09IYwhm+YOxcxGZBuzn6oinI=; b=dIcbcOUlTkWLJlbT62yHrcIR992DBbBn9FBAJmP/89WKya8iHCly12B+DQxS9bRZYIqZHb VzxsQSukIna4GZPij4ca5tEIOvYnJxXtzv+DeRoANp3luMn0xKILk2FX02ycV/OXNAlx7k TrIbywxLEdxfRhq17nI2TN4InE7bK+A= Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-372-K5b_l0y6MjiSDy9OUPjQew-1; Tue, 12 Oct 2021 19:20:58 -0400 X-MC-Unique: K5b_l0y6MjiSDy9OUPjQew-1 Received: by mail-pf1-f198.google.com with SMTP id j2-20020a056a00174200b0044d39a43c9bso414430pfc.22 for ; Tue, 12 Oct 2021 16:20:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=0YWw1Q0O2bPasj7SCnF09IYwhm+YOxcxGZBuzn6oinI=; b=rMvhixOF20EiU4pTYT+s/YYBKprgXz1CReyC/MXg/iK79k8sj61a79cONBwBS1M2gW dREss2flzTYR/AgEQ12ZKHlOdLFjHDBAzTfBz2fkdmpTUBPCYtKmqZEtTUG+akpRusKb CmcXizsdvXmLVWoZBNU1fBB1FI9WuNp4qLQLoVDHUf+wtT84OVdkVYPSpjBC0jubkRgZ /KikWqY6JI1JW4N8WOGxhXkJq60AQuZ4EWCADgqXdjchrGbo00cOkNidnaY0lfR4KKo2 XW3XhTGQNxkJyJ9wVtIuZYdvC1lsm1Wto5M0POqB/GN7EM+y6ALMIhQlvh9DzxOAcuLY CnAg== X-Gm-Message-State: AOAM530c99cbyBycTIPd/hNRt/buMoaqgbrPdLZBh/6WMc3S9b0pmm9q IBrG7aHQ5XZM233tySaIRFWBJ1u/4D8nsM/EpepDTj5TMmn8Tr+kUW0WuV582kUBnrOs41JOkdw h5eXOt7LD6ig= X-Received: by 2002:a17:90b:4c47:: with SMTP id np7mr9309043pjb.22.1634080856893; Tue, 12 Oct 2021 16:20:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwmOhwcb0Oa2rArtwbCqQ7Ouy966RmprkJtGRyDEc5YCYE6ThfeIsNh32iMYC6n30dLqnoSSA== X-Received: by 2002:a17:90b:4c47:: with SMTP id np7mr9308996pjb.22.1634080856460; Tue, 12 Oct 2021 16:20:56 -0700 (PDT) Received: from t490s ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id v2sm3938258pje.15.2021.10.12.16.20.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Oct 2021 16:20:55 -0700 (PDT) Date: Wed, 13 Oct 2021 07:20:48 +0800 From: Peter Xu To: Nadav Amit Cc: Andrew Morton , LKML , Linux-MM , Andrea Arcangeli , Andrew Cooper , Andy Lutomirski , Dave Hansen , Peter Zijlstra , Thomas Gleixner , Will Deacon , Yu Zhao , Nick Piggin , x86@kernel.org Subject: Re: [PATCH 1/2] mm/mprotect: use mmu_gather Message-ID: References: <20210925205423.168858-1-namit@vmware.com> <20210925205423.168858-2-namit@vmware.com> <2CED2F72-4D1C-4DBC-AC03-4B246E1673C2@gmail.com> MIME-Version: 1.0 In-Reply-To: <2CED2F72-4D1C-4DBC-AC03-4B246E1673C2@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: F27805070E5E X-Stat-Signature: m5arqcbunsthycu5bfufaqpzkaiftws1 Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dIcbcOUl; spf=none (imf01.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam06 X-HE-Tag: 1634080859-301091 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 Tue, Oct 12, 2021 at 10:31:45AM -0700, Nadav Amit wrote: >=20 >=20 > > On Oct 12, 2021, at 3:16 AM, Peter Xu wrote: > >=20 > > On Sat, Sep 25, 2021 at 01:54:22PM -0700, Nadav Amit wrote: > >> @@ -338,25 +344,25 @@ static unsigned long change_protection_range(s= truct vm_area_struct *vma, > >> struct mm_struct *mm =3D vma->vm_mm; > >> pgd_t *pgd; > >> unsigned long next; > >> - unsigned long start =3D addr; > >> unsigned long pages =3D 0; > >> + struct mmu_gather tlb; > >>=20 > >> BUG_ON(addr >=3D end); > >> pgd =3D pgd_offset(mm, addr); > >> flush_cache_range(vma, addr, end); > >> inc_tlb_flush_pending(mm); > >> + tlb_gather_mmu(&tlb, mm); > >> + tlb_start_vma(&tlb, vma); > >=20 > > Pure question: > >=20 > > I actually have no idea why tlb_start_vma() is needed here, as protec= tion range > > can be just a single page, but anyway.. I do see that tlb_start_vma()= contains > > a whole-vma flush_cache_range() when the arch needs it, then does it = mean that > > besides the inc_tlb_flush_pending() to be dropped, so as to the other= call to > > flush_cache_range() above? >=20 > Good point. >=20 > tlb_start_vma() and tlb_end_vma() are required since some archs do not > batch TLB flushes across VMAs (e.g., ARM). Sorry I didn't follow here - as change_protection() is per-vma anyway, so= I don't see why it needs to consider vma crossing. In all cases, it'll be great if you could add some explanation into commi= t message on why we need tlb_{start|end}_vma(), as I think it could not be obvious to all people. > I am not sure whether that=E2=80=99s the best behavior for all archs, b= ut I do not > want to change it. >=20 > Anyhow, you make a valid point that the flush_cache_range() should be > dropped as well. I will do so for next version. Thanks, --=20 Peter Xu