Message ID | 20240220034835.507022-1-mawupeng1@huawei.com |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-72309-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2685:b0:108:e6aa:91d0 with SMTP id mn5csp182117dyc; Mon, 19 Feb 2024 20:08:39 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWA0P6uor04wkrmOjfZ3JSiqJmsU+IgWaiwxcx1ga2K4EBLAjivDdOLCMCOhvM+VDDGv5MHFt01F9rB6eN2v011wl2qAw== X-Google-Smtp-Source: AGHT+IGhkyYIXIZW7BrxKt21kSy1iLek1V9KovAPZdY1DncbAlBkJnOnA6OeD1djENNckFoyRdO1 X-Received: by 2002:a05:6a20:889d:b0:19e:cd5d:8903 with SMTP id d29-20020a056a20889d00b0019ecd5d8903mr12403635pzf.24.1708402119466; Mon, 19 Feb 2024 20:08:39 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708402119; cv=pass; d=google.com; s=arc-20160816; b=l5zrlsesypihiMU3Rj3fGcguOctlTfJAJwjz3d4rO7v/uYildkAZNnhpq0kIsR4Aok M4t2O2RURgzwAgxXnTPMrJ7EOoKul+X1ziOQnEao3aWdh2zVrmzLK2IyXtULDo3nRcxf FPDtl8zJhS+6dIaKBKZWJ5UPFGIEo3wtnA2uhnm7qvwgaiNgkdCgkGjlYt5MtAt7H5sw J/vx6mv8QAY6LjEwmp+TaAocQDf33HNExChMlTgcoEyJyBTS0bpkkEo+QBmGbm/4BHRF KHfAZ5QcgLpHmNFLiP6HzaOHRzPEpRJzxpYttyIeyDB44jy5ctmjok0fcO6cSN5FIHLv PqYA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from; bh=tkz9kXCf4qk0KNOhtQOL6+KYyW747vUshHKY9ctWqGc=; fh=zpgpHhi7NFRm0UrQnwLzLdFqTpbxRncqQ6HhcVWeB8c=; b=pKrVGCAsmG3kcbTyy3Cht67puxcy5hK+2X2R4ymuwRkBaAn1fiUvLbBtC5ADZvMgH9 SJ27eia8Etyw4V2mmgVWK+pbnznEiMeFMa35M1Z0+EAbew84aVjOSZ4DeJkiRrVWqzLT VoSCnlq20g+dq8aBmb+f06NEDfR4nJa/CNakhKumSsl1CAH9HgEZp0/tNflrgEp7MSt2 zsCHhFiLdM6jfl78CljKoGnYb5FY4yhzLkm4Z8o3D9RMHA1Bb3lJJJO7VyxwR28JtHq6 BL9yGAQervApEdYQ3ANyTxYbH6kdAObuZKTZ1qglZcp/tsFBHihQ+6knCTY6piecVQPH qdww==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-72309-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-72309-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id i8-20020a17090a974800b002997a4298e2si3945327pjw.140.2024.02.19.20.08.39 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Feb 2024 20:08:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-72309-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-72309-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-72309-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 2D938B22754 for <ouuuleilei@gmail.com>; Tue, 20 Feb 2024 04:08:35 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 856B456B69; Tue, 20 Feb 2024 04:08:24 +0000 (UTC) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2C3C6168B8 for <linux-kernel@vger.kernel.org>; Tue, 20 Feb 2024 04:08:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.189 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708402103; cv=none; b=p0vgnEAkaoeOpXhizXgVvB1OFPuvfggNRt8I66b5HhF/GqT13MHevPovnroFsdvbk5GsLIRGoeoNsk44Gr8/hg27QycsqENM88sUJmzF5Yzs+yShRE1+ZgSBLIl1Bpht0IwATT28eWrrdbZGzs/uziWD6uawFFpSXUiw8WBctDY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708402103; c=relaxed/simple; bh=2j4D5kYG7JtSUKyxtW/u2iHPXr2uOOtuX8szenPUMeY=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=Ivzi2/NcK1WTmoRIDZJRQIaSFoguH886GQAq8T8SW4kz4DR7htz31oi02K8hLoH7sH2iIz2zFSLchbosiaxqOzw5H/kCJtdkFLROM/jSu3v3TOofhbXiDXJhazs1aCRSYK6SQRcItlh1+OgjkURAMbDjRazMMStErZmIxcgC6aI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.189 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.88.105]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4Tf52G06ZtzNlm1; Tue, 20 Feb 2024 11:47:18 +0800 (CST) Received: from dggpemd200001.china.huawei.com (unknown [7.185.36.224]) by mail.maildlp.com (Postfix) with ESMTPS id A70F0140257; Tue, 20 Feb 2024 11:48:39 +0800 (CST) Received: from localhost.localdomain (10.175.112.125) by dggpemd200001.china.huawei.com (7.185.36.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.1258.28; Tue, 20 Feb 2024 11:48:38 +0800 From: Wupeng Ma <mawupeng1@huawei.com> To: <akpm@linux-foundation.org>, <dave.hansen@linux.intel.com>, <luto@kernel.org>, <tglx@linutronix.de>, <peterz@infradead.org>, <hpa@zytor.com> CC: <linux-kernel@vger.kernel.org>, <x86@kernel.org>, <mawupeng1@huawei.com>, <bp@suse.de>, <mingo@redhat.com>, <rdunlap@infradead.org>, <bhelgaas@google.com>, <linux-mm@kvack.org> Subject: [PATCH v4 0/3] Cleanup for PAT Date: Tue, 20 Feb 2024 11:48:32 +0800 Message-ID: <20240220034835.507022-1-mawupeng1@huawei.com> X-Mailer: git-send-email 2.25.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemd200001.china.huawei.com (7.185.36.224) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791389460984123282 X-GMAIL-MSGID: 1791389460984123282 |
Series | Cleanup for PAT | |
Message
mawupeng
Feb. 20, 2024, 3:48 a.m. UTC
From: Ma Wupeng <mawupeng1@huawei.com>
Patch #1 move follow_phys to memtype.c since only pat use this.
Patch #2 cleanup parameter in follow_phys.
Patch #3 drop the unnecessary WARN_ON_ONCE if follow_phys fails.
Changelog since v3:
- rebase to latest linux
- fix compile warnings
Changelog since v2:
- rebase to latest linux
Changelog since v1:
- split patch #1 into two patches based on Boris's advise
Ma Wupeng (3):
x86/mm/pat: Move follow_phys to pat-related file
x86/mm/pat: Cleanup unused parameter in follow_phys
x86/mm/pat: Remove WARN_ON_ONCE if follow_phys fails
arch/x86/mm/pat/memtype.c | 32 ++++++++++++++++++++++++++------
include/linux/mm.h | 2 --
mm/memory.c | 28 ----------------------------
3 files changed, 26 insertions(+), 36 deletions(-)
Comments
On 2/19/2024 7:48 PM, Wupeng Ma wrote: > From: Ma Wupeng <mawupeng1@huawei.com> > This patch set is all about follow_phys() cleanups, so "Cleanup for PAT" seems too generic. > Patch #1 move follow_phys to memtype.c since only pat use this. > Patch #2 cleanup parameter in follow_phys. > Patch #3 drop the unnecessary WARN_ON_ONCE if follow_phys fails. I'm more curious why follow_phys() ended up this way? follow_phys() was introduced in commit 28b2ee20c7cba ("access_process_vm device memory infrastructure") in 2008 for getting a physical page address for a virtual address, and used in generic_access_phys(). And later it's used in x86 PAT code. Commit 03668a4debf4f ("mm: use generic follow_pte() in follow_phys()") made follow_phys() more of a wrapper of follow_pte(), and commit 96667f8a4382d ("mm: Close race in generic_access_phys") replaced follow_phys() with follow_pte() in generic_access_phys(). And the end result is that follow_phys() is used in x86 PAT code only. As follow_phys() in untrack_pfn() can be replaced with follow_pfn(), then maybe we don't have to keep follow_phys(), and just use follow_pte() in track_pfn_copy()? Thanks! Xin > > Changelog since v3: > - rebase to latest linux > - fix compile warnings > > Changelog since v2: > - rebase to latest linux > > Changelog since v1: > - split patch #1 into two patches based on Boris's advise > > Ma Wupeng (3): > x86/mm/pat: Move follow_phys to pat-related file > x86/mm/pat: Cleanup unused parameter in follow_phys > x86/mm/pat: Remove WARN_ON_ONCE if follow_phys fails > > arch/x86/mm/pat/memtype.c | 32 ++++++++++++++++++++++++++------ > include/linux/mm.h | 2 -- > mm/memory.c | 28 ---------------------------- > 3 files changed, 26 insertions(+), 36 deletions(-) >
On 2024/2/20 16:37, Xin Li wrote: > On 2/19/2024 7:48 PM, Wupeng Ma wrote: >> From: Ma Wupeng <mawupeng1@huawei.com> >> > > This patch set is all about follow_phys() cleanups, so "Cleanup for PAT" > seems too generic. > >> Patch #1 move follow_phys to memtype.c since only pat use this. >> Patch #2 cleanup parameter in follow_phys. >> Patch #3 drop the unnecessary WARN_ON_ONCE if follow_phys fails. > > I'm more curious why follow_phys() ended up this way? > > follow_phys() was introduced in commit 28b2ee20c7cba ("access_process_vm > device memory infrastructure") in 2008 for getting a physical page address > for a virtual address, and used in generic_access_phys(). And later it's > used in x86 PAT code. > > Commit 03668a4debf4f ("mm: use generic follow_pte() in follow_phys()") made > follow_phys() more of a wrapper of follow_pte(), and commit 96667f8a4382d > ("mm: Close race in generic_access_phys") replaced follow_phys() with > follow_pte() in generic_access_phys(). And the end result is that > follow_phys() is used in x86 PAT code only. Thanks for the explanation. I have a better understanding of the history of this function. > > As follow_phys() in untrack_pfn() can be replaced with follow_pfn(), then Yes, this can be replaced with follow_pfn(). > maybe we don't have to keep follow_phys(), and just use follow_pte() in > track_pfn_copy()? As follow_phys() will return unsigned long *prot which is need in track_pfn_copy(), we need to do something with this. Can we replace follow_pfn with follow_phys()? Thanks! Ma > > Thanks! > Xin > >> >> Changelog since v3: >> - rebase to latest linux >> - fix compile warnings >> >> Changelog since v2: >> - rebase to latest linux >> >> Changelog since v1: >> - split patch #1 into two patches based on Boris's advise >> >> Ma Wupeng (3): >> x86/mm/pat: Move follow_phys to pat-related file >> x86/mm/pat: Cleanup unused parameter in follow_phys >> x86/mm/pat: Remove WARN_ON_ONCE if follow_phys fails >> >> arch/x86/mm/pat/memtype.c | 32 ++++++++++++++++++++++++++------ >> include/linux/mm.h | 2 -- >> mm/memory.c | 28 ---------------------------- >> 3 files changed, 26 insertions(+), 36 deletions(-) >> > >
On 2/20/2024 1:06 AM, mawupeng wrote: > On 2024/2/20 16:37, Xin Li wrote: >> On 2/19/2024 7:48 PM, Wupeng Ma wrote: >> follow_phys() was introduced in commit 28b2ee20c7cba ("access_process_vm >> device memory infrastructure") in 2008 for getting a physical page address >> for a virtual address, and used in generic_access_phys(). And later it's >> used in x86 PAT code. >> >> Commit 03668a4debf4f ("mm: use generic follow_pte() in follow_phys()") made >> follow_phys() more of a wrapper of follow_pte(), and commit 96667f8a4382d >> ("mm: Close race in generic_access_phys") replaced follow_phys() with >> follow_pte() in generic_access_phys(). And the end result is that >> follow_phys() is used in x86 PAT code only. > > Thanks for the explanation. I have a better understanding of the history of > this function. > "git blame" tells the story. >> >> As follow_phys() in untrack_pfn() can be replaced with follow_pfn(), then > > Yes, this can be replaced with follow_pfn(). > >> maybe we don't have to keep follow_phys(), and just use follow_pte() in >> track_pfn_copy()? > > As follow_phys() will return unsigned long *prot which is need in track_pfn_copy(), > we need to do something with this. Commit 96667f8a4382d did that already. > Can we replace follow_pfn with follow_phys()? Sorry, I don't get your point. Thanks! Xin