* + mm-functions-may-simplify-the-use-of-return-values.patch added to mm-unstable branch
@ 2022-05-07 17:50 Andrew Morton
2022-05-09 7:20 ` Peter Zijlstra
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Morton @ 2022-05-07 17:50 UTC (permalink / raw)
To: mm-commits, tglx, peterz, mingo, luto, hpa, dave.hansen, bp, kunyu, akpm
The patch titled
Subject: mm: functions may simplify the use of return values
has been added to the -mm mm-unstable branch. Its filename is
mm-functions-may-simplify-the-use-of-return-values.patch
This patch should soon appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Li kunyu <kunyu@nfschina.com>
Subject: mm: functions may simplify the use of return values
p4d_clear_huge may be optimized for void return type and function usage.
vunmap_p4d_range function saves a few steps here.
Link: https://lkml.kernel.org/r/20220507150630.90399-1-kunyu@nfschina.com
Signed-off-by: Li kunyu <kunyu@nfschina.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/x86/mm/pgtable.c | 3 +--
include/linux/pgtable.h | 12 +++---------
mm/vmalloc.c | 7 ++-----
3 files changed, 6 insertions(+), 16 deletions(-)
--- a/arch/x86/mm/pgtable.c~mm-functions-may-simplify-the-use-of-return-values
+++ a/arch/x86/mm/pgtable.c
@@ -686,9 +686,8 @@ int p4d_set_huge(p4d_t *p4d, phys_addr_t
*
* No 512GB pages yet -- always return 0
*/
-int p4d_clear_huge(p4d_t *p4d)
+void p4d_clear_huge(p4d_t *p4d)
{
- return 0;
}
#endif
--- a/include/linux/pgtable.h~mm-functions-may-simplify-the-use-of-return-values
+++ a/include/linux/pgtable.h
@@ -1443,16 +1443,13 @@ static inline int pmd_protnone(pmd_t pmd
#ifndef __PAGETABLE_P4D_FOLDED
int p4d_set_huge(p4d_t *p4d, phys_addr_t addr, pgprot_t prot);
-int p4d_clear_huge(p4d_t *p4d);
+void p4d_clear_huge(p4d_t *p4d);
#else
static inline int p4d_set_huge(p4d_t *p4d, phys_addr_t addr, pgprot_t prot)
{
return 0;
}
-static inline int p4d_clear_huge(p4d_t *p4d)
-{
- return 0;
-}
+static inline void p4d_clear_huge(p4d_t *p4d) { }
#endif /* !__PAGETABLE_P4D_FOLDED */
int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot);
@@ -1475,10 +1472,7 @@ static inline int pmd_set_huge(pmd_t *pm
{
return 0;
}
-static inline int p4d_clear_huge(p4d_t *p4d)
-{
- return 0;
-}
+static inline void p4d_clear_huge(p4d_t *p4d) { }
static inline int pud_clear_huge(pud_t *pud)
{
return 0;
--- a/mm/vmalloc.c~mm-functions-may-simplify-the-use-of-return-values
+++ a/mm/vmalloc.c
@@ -389,18 +389,15 @@ static void vunmap_p4d_range(pgd_t *pgd,
{
p4d_t *p4d;
unsigned long next;
- int cleared;
p4d = p4d_offset(pgd, addr);
do {
next = p4d_addr_end(addr, end);
- cleared = p4d_clear_huge(p4d);
- if (cleared || p4d_bad(*p4d))
+ p4d_clear_huge(p4d);
+ if (p4d_bad(*p4d))
*mask |= PGTBL_P4D_MODIFIED;
- if (cleared)
- continue;
if (p4d_none_or_clear_bad(p4d))
continue;
vunmap_pud_range(p4d, addr, next, mask);
_
Patches currently in -mm which might be from kunyu@nfschina.com are
mm-functions-may-simplify-the-use-of-return-values.patch
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: + mm-functions-may-simplify-the-use-of-return-values.patch added to mm-unstable branch
2022-05-07 17:50 + mm-functions-may-simplify-the-use-of-return-values.patch added to mm-unstable branch Andrew Morton
@ 2022-05-09 7:20 ` Peter Zijlstra
2022-05-09 17:07 ` Andrew Morton
0 siblings, 1 reply; 3+ messages in thread
From: Peter Zijlstra @ 2022-05-09 7:20 UTC (permalink / raw)
To: Andrew Morton; +Cc: mm-commits, tglx, mingo, luto, hpa, dave.hansen, bp, kunyu
On Sat, May 07, 2022 at 10:50:26AM -0700, Andrew Morton wrote:
>
> The patch titled
> Subject: mm: functions may simplify the use of return values
> has been added to the -mm mm-unstable branch. Its filename is
> mm-functions-may-simplify-the-use-of-return-values.patch
>
> This patch should soon appear in the mm-unstable branch at
> git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
>
> Before you just go and hit "reply", please:
> a) Consider who else should be cc'ed
> b) Prefer to cc a suitable mailing list as well
> c) Ideally: find the original patch on the mailing list and do a
> reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
>
> The -mm tree is included into linux-next via the mm-everything
> branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> and is updated there every 2-3 working days
>
> ------------------------------------------------------
> From: Li kunyu <kunyu@nfschina.com>
> Subject: mm: functions may simplify the use of return values
>
> p4d_clear_huge may be optimized for void return type and function usage.
> vunmap_p4d_range function saves a few steps here.
>
> Link: https://lkml.kernel.org/r/20220507150630.90399-1-kunyu@nfschina.com
> Signed-off-by: Li kunyu <kunyu@nfschina.com>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Please, no:
arch/x86/mm/pgtable.c: * p4d_clear_huge - clear kernel P4D mapping when it is set
arch/x86/mm/pgtable.c:int p4d_clear_huge(p4d_t *p4d)
arch/x86/mm/pgtable.c: * pud_clear_huge - clear kernel PUD mapping when it is set
arch/x86/mm/pgtable.c:int pud_clear_huge(pud_t *pud)
arch/x86/mm/pgtable.c: * pmd_clear_huge - clear kernel PMD mapping when it is set
arch/x86/mm/pgtable.c:int pmd_clear_huge(pmd_t *pmd)
why would the p4d one need to be different from the rest?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: + mm-functions-may-simplify-the-use-of-return-values.patch added to mm-unstable branch
2022-05-09 7:20 ` Peter Zijlstra
@ 2022-05-09 17:07 ` Andrew Morton
0 siblings, 0 replies; 3+ messages in thread
From: Andrew Morton @ 2022-05-09 17:07 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: mm-commits, tglx, mingo, luto, hpa, dave.hansen, bp, kunyu
On Mon, 9 May 2022 09:20:35 +0200 Peter Zijlstra <peterz@infradead.org> wrote:
>
> Please, no:
>
> arch/x86/mm/pgtable.c: * p4d_clear_huge - clear kernel P4D mapping when it is set
> arch/x86/mm/pgtable.c:int p4d_clear_huge(p4d_t *p4d)
> arch/x86/mm/pgtable.c: * pud_clear_huge - clear kernel PUD mapping when it is set
> arch/x86/mm/pgtable.c:int pud_clear_huge(pud_t *pud)
> arch/x86/mm/pgtable.c: * pmd_clear_huge - clear kernel PMD mapping when it is set
> arch/x86/mm/pgtable.c:int pmd_clear_huge(pmd_t *pmd)
>
> why would the p4d one need to be different from the rest?
Because the p4d one doesn't return anything, whereas the others do?
Any code which tests the p4d_clear_huge() return value is probably
buggy, so making p4d_clear_huge() return void permits us to detect such
a bug with the C type system.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-05-09 17:07 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-07 17:50 + mm-functions-may-simplify-the-use-of-return-values.patch added to mm-unstable branch Andrew Morton
2022-05-09 7:20 ` Peter Zijlstra
2022-05-09 17:07 ` Andrew Morton
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.