From: Chen Li <chenli@uniontech.com>
To: akpm@linux-foundation.org
Cc: mm-commits@vger.kernel.org, David Hildenbrand <david@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [PATCH v2] nommu: remove __GFP_HIGHMEM in vmalloc/vzalloc
Date: Mon, 10 May 2021 09:49:11 +0800 [thread overview]
Message-ID: <87tunb2wa0.wl-chenli@uniontech.com> (raw)
In-Reply-To: <20210509041323.k6DtiMDiu%akpm@linux-foundation.org>
On Sun, 09 May 2021 12:13:23 +0800,
akpm@linux-foundation.org wrote:
>
>
> The patch titled
> Subject: nommu-remove-__gfp_highmem-in-vmalloc-vzalloc-checkpatch-fixes
> has been added to the -mm tree. Its filename is
> nommu-remove-__gfp_highmem-in-vmalloc-vzalloc-checkpatch-fixes.patch
>
> This patch should soon appear at
> https://ozlabs.org/~akpm/mmots/broken-out/nommu-remove-__gfp_highmem-in-vmalloc-vzalloc-checkpatch-fixes.patch
> and later at
> https://ozlabs.org/~akpm/mmotm/broken-out/nommu-remove-__gfp_highmem-in-vmalloc-vzalloc-checkpatch-fixes.patch
>
> 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 and is updated
> there every 3-4 working days
>
> ------------------------------------------------------
> From: Andrew Morton <akpm@linux-foundation.org>
> Subject: nommu-remove-__gfp_highmem-in-vmalloc-vzalloc-checkpatch-fixes
>
> Cc: Chen Li <chenli@uniontech.com>
>
> WARNING: please, no spaces at the start of a line
> #37: FILE: mm/nommu.c:226:
> + return __vmalloc(size, GFP_KERNEL);$
>
> total: 0 errors, 1 warnings, 16 lines checked
>
> NOTE: For some of the reported defects, checkpatch may be able to
> mechanically convert to the typical style using --fix or --fix-inplace.
>
> ./patches/nommu-remove-__gfp_highmem-in-vmalloc-vzalloc.patch has style problems, please review.
>
> NOTE: If any of the errors are false positives, please report
> them to the maintainer, see CHECKPATCH in MAINTAINERS.
>
> Please run checkpatch prior to sending patches
>
> Cc: Chen Li <chenli@uniontech.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> mm/nommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/mm/nommu.c~nommu-remove-__gfp_highmem-in-vmalloc-vzalloc-checkpatch-fixes
> +++ a/mm/nommu.c
> @@ -223,7 +223,7 @@ long vread(char *buf, char *addr, unsign
> */
> void *vmalloc(unsigned long size)
> {
> - return __vmalloc(size, GFP_KERNEL);
> + return __vmalloc(size, GFP_KERNEL);
> }
> EXPORT_SYMBOL(vmalloc);
>
> _
>
> Patches currently in -mm which might be from akpm@linux-foundation.org are
>
> mm.patch
> mm-gup-pack-has_pinned-in-mmf_has_pinned-checkpatch-fixes.patch
> mm-memcg-optimize-user-context-object-stock-access-checkpatch-fixes.patch
> nommu-remove-__gfp_highmem-in-vmalloc-vzalloc-checkpatch-fixes.patch
> linux-next-git-rejects.patch
> kernel-forkc-export-kernel_thread-to-modules.patch
>
>
>
From mm/nommu.c:
void *__vmalloc(unsigned long size, gfp_t gfp_mask)
{
/*
* You can't specify __GFP_HIGHMEM with kmalloc() since kmalloc()
* returns only a logical address.
*/
return kmalloc(size, (gfp_mask | __GFP_COMP) & ~__GFP_HIGHMEM);
}
__vmalloc just elimitate __GFP_HIGHMEM, so it makes no sense to add
__GFP_HIGHMEM for nommu's vmalloc/vzalloc.
changelog:
*v2: Also fix a space style warning reported from checkpatch, which is
introduced via commit 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Chen Li <chenli@uniontech.com>
Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Reviewed-by: David Hildenbrand <david@redhat.com>
---
mm/nommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index 5c9ab799c0e6..f1794e818348 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -233,7 +233,7 @@ long vwrite(char *buf, char *addr, unsigned long count)
*/
void *vmalloc(unsigned long size)
{
- return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM);
+ return __vmalloc(size, GFP_KERNEL);
}
EXPORT_SYMBOL(vmalloc);
@@ -251,7 +251,7 @@ EXPORT_SYMBOL(vmalloc);
*/
void *vzalloc(unsigned long size)
{
- return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO);
+ return __vmalloc(size, GFP_KERNEL | __GFP_ZERO);
}
EXPORT_SYMBOL(vzalloc);
--
2.31.1
parent reply other threads:[~2021-05-10 1:52 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20210509041323.k6DtiMDiu%akpm@linux-foundation.org>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tunb2wa0.wl-chenli@uniontech.com \
--to=chenli@uniontech.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mm-commits@vger.kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox