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 X-Spam-Level: X-Spam-Status: No, score=-7.9 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 41A6DC433DF for ; Wed, 27 May 2020 20:55:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EC03B2088E for ; Wed, 27 May 2020 20:55:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="tnKZJrMI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EC03B2088E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9C35A8001A; Wed, 27 May 2020 16:55:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9736080010; Wed, 27 May 2020 16:55:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 838F08001A; Wed, 27 May 2020 16:55:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0252.hostedemail.com [216.40.44.252]) by kanga.kvack.org (Postfix) with ESMTP id 6C93480010 for ; Wed, 27 May 2020 16:55:40 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 2F2AC5E0D6 for ; Wed, 27 May 2020 20:55:40 +0000 (UTC) X-FDA: 76863705240.16.sort13_88b0855177520 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id DE08C10069319 for ; Wed, 27 May 2020 20:55:39 +0000 (UTC) X-HE-Tag: sort13_88b0855177520 X-Filterd-Recvd-Size: 5718 Received: from mail-ot1-f67.google.com (mail-ot1-f67.google.com [209.85.210.67]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Wed, 27 May 2020 20:55:38 +0000 (UTC) Received: by mail-ot1-f67.google.com with SMTP id u23so697208otq.10 for ; Wed, 27 May 2020 13:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=CR9dwsvfsyVy6G6eufz7hLC4jiMaO3cWV54dCy7eHCU=; b=tnKZJrMIcf0/z4kaB+rJl3FXPTJHht//RCQa4J59uzyChfalXhlpPFz5E0fYsdyFFE ZJvl5QVLp1xf7s4kzKZpAW5feSDjc2nAFIp4uAutc73kgMQqJ7Qf4gVH0kuM6JXaf4rr Cc5K/SBc3R3k210aYcI++2fWr6jGHExFKnZYm/oJqnBwanurHfAFGaTRti3RuuUw2v1a KjoFcUj5mweabEKNICEPUCPMZzsVLMma4k1+nxXVAD/X/3p/r9fScN26LuA3aBf30jkv WRC8LDsOwmZKb7/sIxW3Qk/N0n3lIJT5LPbRwMNKnRAl8DuZN85iuQMQXMRdU6NhSJ2A ONMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=CR9dwsvfsyVy6G6eufz7hLC4jiMaO3cWV54dCy7eHCU=; b=TaegahYDjAIbfBzquVr9USLwZ+nCX9os1JsSKJXkyfAvNUKg32KkXeX7WGRXP3rY2g kXh9zdG1CeYYKmkR5jGUs9cu4GhpV3DPp04qHL41wd4cuWmBGCOX8RJnWJy1Cjhc7Dzv KJDgjspNqPDYJZCjGvHWZ3/VNfg6hgKqKEcj7o+J90D6MouiCcEIEFL6p4S3bWe9fzXo Bqqm2hxEgGiCpRxYH3OoxLxMedQW2WeN38P7/nnYSltKXcdCI+Ne/JHuSdlQ5L19/30A Gy0jrqSRdX/+15s4BVSgVYHl4K/4P3KXElk/jgEVhy+uYYEfhJhQxww3Zj8UbZq1weEo Rc+Q== X-Gm-Message-State: AOAM533IhQPb6sw1t/tNOeCfmwkCps2sbqUx6h+dfIbHZSPwAvLHYqar vEP1HQ/bsruF2y9osTVkrv5klQ== X-Google-Smtp-Source: ABdhPJxe3WPDsF/Ss6eKC+aL78ToDj1r+IEd2rMAwohSMI+2b4yzHLOnjhl8EBq8paJZUxhB9cJ54g== X-Received: by 2002:a05:6830:18a:: with SMTP id q10mr6226851ota.25.1590612937438; Wed, 27 May 2020 13:55:37 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id g22sm1150339ooh.36.2020.05.27.13.55.34 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Wed, 27 May 2020 13:55:36 -0700 (PDT) Date: Wed, 27 May 2020 13:55:18 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: maobibo cc: Andrew Morton , Thomas Bogendoerfer , Jiaxun Yang , Huacai Chen , Paul Burton , Dmitry Korotin , =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= , Stafford Horne , Steven Price , Anshuman Khandual , linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, Mike Rapoport , Sergei Shtylyov , "Maciej W. Rozycki" , linux-mm@kvack.org, David Hildenbrand Subject: Re: [PATCH v3 3/3] mm/memory.c: Add memory read privilege before filling PTE entry In-Reply-To: Message-ID: References: <1589778529-25627-1-git-send-email-maobibo@loongson.cn> <1589778529-25627-3-git-send-email-maobibo@loongson.cn> <20200518135747.d8837ba6742b2d193e14fbb0@linux-foundation.org> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Rspamd-Queue-Id: DE08C10069319 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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, 19 May 2020, maobibo wrote: > On 05/19/2020 04:57 AM, Andrew Morton wrote: > > On Mon, 18 May 2020 13:08:49 +0800 Bibo Mao wrote: > > > >> On mips platform, hw PTE entry valid bit is set in pte_mkyoung > >> function, it is used to set physical page with readable privilege. > > > > pte_mkyoung() seems to be a strange place to set the pte's valid bit. > > Why is it done there? Can it be done within mips's mk_pte()? > On MIPS system hardware cannot set PAGE_ACCESS bit when accessing the page, > software sets PAGE_ACCESS software bit and PAGE_VALID hw bit together during page > fault stage. > > If mk_pte is called in page fault flow, it is ok to set both bits. If it is not > called in page fault, PAGE_ACCESS is set however there is no actual memory accessing. Sorry for joining in so late, but would you please explain that some more: preferably in the final commit message, if not here. I still don't understand why this is not done in the same way as on other architectures - those that care (I just checked x86, powerpc, arm, arm64, but not all of them) make sure that all the bits they want are there in mm/mmap.c's protection_map[16], which then feeds into vma->vm_page_prot, and so into mk_pte() as Andrew indicated. And I can see that arch/mips/mm/cache.c has a setup_protection_map() to do that: why does it not set the additional bits that you want? including the valid bit and the accessed (young) bit, as others do. Are you saying that there are circumstances in which it is wrong for mk_pte() to set the additional bits? I'm afraid that generic mm developers will have no clue as to whether or not to add a pte_sw_mkyoung() after a mk_pte(); and generic source will be the cleaner if it turns out not to be needed (but thank you for making sure that it does nothing on the other architectures). Hugh