Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3254573ybb; Tue, 31 Mar 2020 01:17:56 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsnhMDoMaNYImy33C+myLuEXW+cmBlm5WQOLxcR8n4k+1Ymg0k0WHPfnI0jLR0I4jlv+IB4 X-Received: by 2002:aca:56c2:: with SMTP id k185mr1208107oib.141.1585642676317; Tue, 31 Mar 2020 01:17:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585642676; cv=none; d=google.com; s=arc-20160816; b=x/wjs+MPvTI8l6yTGXThXnhTr1GAk4XZkCREpnAliNZr27Q4/uVbIpZBJ/vO5FvKlK MboUOP3KIzwkcgJL+Bu0i0wnxWDF9q/tXtjo47h6Bp1QnHUYQ/pyoA5ietjGeK228s1r kBrY5BMQsnDwq7TH4ri4fs0QM7hYZBjcC8KZE9mtfa9MyNMjStX9BiDXPpkkNpCZ0AbL iYEDchOTHR37VR0PGnf8dRh6HchnhaDYU3zDM6iZU7yY5RJIQ8IekT4Quh2FtS/cUfUD CKs6ZC23CjdWmAKODWCnVJIApkTnfdwQH+02GYCIF9IvzAXt2Y6MvkCmy2viQEnb+9wu H+lQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=oBUIF3Aj+90dtEbmboZVGTsiN35/mQh7qjLfWdNfEbo=; b=tJGcrJ2Q97ARbFKc4YmDC7rGOOA8HlSK1i7E13s402TfrbCZbj/RSF+djLYRooY6A8 tL5jg6+W3X/3svrRztAU3r/wneW13+QAFkQMubtQJ/eG1EKi9UNXG0tRs3ENojzmJKAt 0fxNKDW1lRtiy+4F5lAQwmpLhwMqyNZMA82lYKFmroG4mG9euBJD3q5A4qqTSbDo3NYj T4tzT/U8rkGqVWvjBCGEgG24DdRNJ5OBCTZ471qfoZq1JOc60lgun8ZQvUJODq6JM2CO 2M/h/FX0XVZIjQZqJfOwGGsmXBuwqRmx3ZMZqHk4C1OhtN4knjgUy8Iw6iL1zqWLUBfh Wz1g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u137si6406593oie.160.2020.03.31.01.17.43; Tue, 31 Mar 2020 01:17:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729958AbgCaIQM (ORCPT + 99 others); Tue, 31 Mar 2020 04:16:12 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:58420 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726397AbgCaIQL (ORCPT ); Tue, 31 Mar 2020 04:16:11 -0400 Received: from DGGEMS409-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id F16CE5E95C5B64C7B4DB; Tue, 31 Mar 2020 16:16:00 +0800 (CST) Received: from [127.0.0.1] (10.173.220.25) by DGGEMS409-HUB.china.huawei.com (10.3.19.209) with Microsoft SMTP Server id 14.3.487.0; Tue, 31 Mar 2020 16:15:51 +0800 Subject: Re: [RFC][Qusetion] the value of cleared_(ptes|pmds|puds|p4ds) in struct mmu_gather To: Peter Zijlstra , CC: , , , , , , , Marc Zyngier , , , , , References: <20200330121654.GL20696@hirez.programming.kicks-ass.net> From: Zhenyu Ye Message-ID: <9c75a85e-5d80-0286-1ce5-89479d49170e@huawei.com> Date: Tue, 31 Mar 2020 16:15:49 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: <20200330121654.GL20696@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset="gbk" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.173.220.25] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter, On 2020/3/30 20:16, Peter Zijlstra wrote: > On Sat, Mar 28, 2020 at 12:30:50PM +0800, Zhenyu Ye wrote: >> Hi all, >> >> commit a6d60245 "Track which levels of the page tables have been cleared" >> added cleared_(ptes|pmds|puds|p4ds) in struct mmu_gather, and the values >> of them are set in some places. For example: >> >> In include/asm-generic/tlb.h, pte_free_tlb() set the tlb->cleared_pmds: >> ---8<--- >> #ifndef pte_free_tlb >> #define pte_free_tlb(tlb, ptep, address) \ >> do { \ >> __tlb_adjust_range(tlb, address, PAGE_SIZE); \ >> tlb->freed_tables = 1; \ >> tlb->cleared_pmds = 1; \ >> __pte_free_tlb(tlb, ptep, address); \ >> } while (0) >> #endif >> ---8<--- >> >> >> However, in arch/s390/include/asm/tlb.h, pte_free_tlb() set the tlb->cleared_ptes: >> ---8<--- >> static inline void pte_free_tlb(struct mmu_gather *tlb, pgtable_t pte, >> unsigned long address) >> { >> __tlb_adjust_range(tlb, address, PAGE_SIZE); >> tlb->mm->context.flush_mm = 1; >> tlb->freed_tables = 1; >> tlb->cleared_ptes = 1; >> /* >> * page_table_free_rcu takes care of the allocation bit masks >> * of the 2K table fragments in the 4K page table page, >> * then calls tlb_remove_table. >> */ >> page_table_free_rcu(tlb, (unsigned long *) pte, address); >> } >> ---8<--- >> >> >> In my view, the cleared_(ptes|pmds|puds) and (pte|pmd|pud)_free_tlb >> correspond one-to-one. So we should set cleared_ptes in pte_free_tlb(), >> then use it when needed. > > So pte_free_tlb() clears a table of PTE entries, or a PMD level entity, > also see free_pte_range(). So the generic code makes sense to me. The > PTE level invalidations will have happened on tlb_remove_tlb_entry(). > Thanks for your explanation. I can understand now. >> I'm very confused about this. Which is wrong? Or is there something >> I understand wrong? > > I agree the s390 case is puzzling, Martin does s390 need a PTE level > invalidate for removing a PTE table or was this a mistake? > Then we should wait for @ Martin's reply. Though s390 has never used this value, I think we still should correct it if this is a mistake. Thanks, Zhenyu