| Message ID | 20240220034835.507022-1-mawupeng1@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Cleanup for PAT | expand |
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
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(-)