[-- Attachment #1: Type: text/plain, Size: 1710 bytes --] Hi Andrew, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: In file included from arch/powerpc/include/asm/mmu-hash64.h:23:0, from arch/powerpc/include/asm/mmu.h:197, from arch/powerpc/include/asm/lppaca.h:36, from arch/powerpc/include/asm/paca.h:20, from arch/powerpc/include/asm/hw_irq.h:41, from arch/powerpc/include/asm/irqflags.h:11, from include/linux/irqflags.h:15, from include/linux/spinlock.h:53, from include/linux/mmzone.h:7, from include/linux/gfp.h:5, from include/linux/mm.h:9, from include/linux/mman.h:4, from mm/madvise.c:8: mm/madvise.c: In function 'swapin_walk_pte_entry': arch/powerpc/include/asm/pgtable-ppc64.h:183:3: warning: statement with no effect [-Wunused-value] (((pte_t *) pmd_page_vaddr(*(dir))) + (((addr) >> PAGE_SHIFT) & (PTRS_PER_PTE - 1))) ^ arch/powerpc/include/asm/pgtable-ppc64.h:185:34: note: in expansion of macro 'pte_offset_kernel' #define pte_offset_map(dir,addr) pte_offset_kernel((dir), (addr)) ^ mm/madvise.c:161:2: note: in expansion of macro 'pte_offset_map' pte_offset_map(walk->pmd, start & PMD_MASK); ^ mm/madvise.c:145:9: warning: unused variable 'orig_pte' [-Wunused-variable] pte_t *orig_pte = pte - ((start & (PMD_SIZE - 1)) >> PAGE_SHIFT); ^ Introduced by commit 17336ae3d58a ("madvise: cleanup swapin_walk_pmd_entry()") -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 8538 bytes --] Hi Andrew, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: In file included from include/linux/printk.h:257:0, from include/linux/kernel.h:13, from arch/x86/include/asm/percpu.h:44, from arch/x86/include/asm/preempt.h:5, from include/linux/preempt.h:18, from include/linux/spinlock.h:50, from include/linux/seqlock.h:35, from include/linux/time.h:5, from include/linux/stat.h:18, from include/linux/module.h:10, from crypto/zlib.c:26: crypto/zlib.c: In function 'zlib_compress_update': include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'uLong' [-Wformat=] static struct _ddebug __aligned(8) \ ^ include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA' DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \ ^ include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug' dynamic_pr_debug(fmt, ##__VA_ARGS__) ^ crypto/zlib.c:171:2: note: in expansion of macro 'pr_debug' pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n", ^ include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'uLong' [-Wformat=] static struct _ddebug __aligned(8) \ ^ include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA' DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \ ^ include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug' dynamic_pr_debug(fmt, ##__VA_ARGS__) ^ crypto/zlib.c:171:2: note: in expansion of macro 'pr_debug' pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n", ^ include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 6 has type 'uLong' [-Wformat=] static struct _ddebug __aligned(8) \ ^ include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA' DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \ ^ include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug' dynamic_pr_debug(fmt, ##__VA_ARGS__) ^ crypto/zlib.c:171:2: note: in expansion of macro 'pr_debug' pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n", ^ crypto/zlib.c: In function 'zlib_compress_final': include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'uLong' [-Wformat=] static struct _ddebug __aligned(8) \ ^ include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA' DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \ ^ include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug' dynamic_pr_debug(fmt, ##__VA_ARGS__) ^ crypto/zlib.c:201:2: note: in expansion of macro 'pr_debug' pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n", ^ include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'uLong' [-Wformat=] static struct _ddebug __aligned(8) \ ^ include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA' DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \ ^ include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug' dynamic_pr_debug(fmt, ##__VA_ARGS__) ^ crypto/zlib.c:201:2: note: in expansion of macro 'pr_debug' pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n", ^ include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 6 has type 'uLong' [-Wformat=] static struct _ddebug __aligned(8) \ ^ include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA' DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \ ^ include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug' dynamic_pr_debug(fmt, ##__VA_ARGS__) ^ crypto/zlib.c:201:2: note: in expansion of macro 'pr_debug' pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n", ^ crypto/zlib.c: In function 'zlib_decompress_update': include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'uLong' [-Wformat=] static struct _ddebug __aligned(8) \ ^ include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA' DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \ ^ include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug' dynamic_pr_debug(fmt, ##__VA_ARGS__) ^ crypto/zlib.c:286:2: note: in expansion of macro 'pr_debug' pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n", ^ include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'uLong' [-Wformat=] static struct _ddebug __aligned(8) \ ^ include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA' DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \ ^ include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug' dynamic_pr_debug(fmt, ##__VA_ARGS__) ^ crypto/zlib.c:286:2: note: in expansion of macro 'pr_debug' pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n", ^ include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 6 has type 'uLong' [-Wformat=] static struct _ddebug __aligned(8) \ ^ include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA' DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \ ^ include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug' dynamic_pr_debug(fmt, ##__VA_ARGS__) ^ crypto/zlib.c:286:2: note: in expansion of macro 'pr_debug' pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n", ^ crypto/zlib.c: In function 'zlib_decompress_final': include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'uLong' [-Wformat=] static struct _ddebug __aligned(8) \ ^ include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA' DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \ ^ include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug' dynamic_pr_debug(fmt, ##__VA_ARGS__) ^ crypto/zlib.c:334:2: note: in expansion of macro 'pr_debug' pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n", ^ include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'uLong' [-Wformat=] static struct _ddebug __aligned(8) \ ^ include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA' DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \ ^ include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug' dynamic_pr_debug(fmt, ##__VA_ARGS__) ^ crypto/zlib.c:334:2: note: in expansion of macro 'pr_debug' pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n", ^ include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 6 has type 'uLong' [-Wformat=] static struct _ddebug __aligned(8) \ ^ include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA' DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \ ^ include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug' dynamic_pr_debug(fmt, ##__VA_ARGS__) ^ crypto/zlib.c:334:2: note: in expansion of macro 'pr_debug' pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n", ^ Introduced by commit 8d9dfa4b0125 ("initramfs: support initramfs that is more than 2G"). Grep is your friend :-( -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 385 bytes --] On Thu, Jun 19, 2014 at 10:27 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > Hi Andrew, > > After merging the akpm-current tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > Introduced by commit 8d9dfa4b0125 ("initramfs: support initramfs that > is more than 2G"). Grep is your friend :-( Please check if attached patch fix the problem. Yinghai [-- Attachment #2: fix_uLong_print.patch --] [-- Type: text/x-patch, Size: 2789 bytes --] diff --git a/crypto/zlib.c b/crypto/zlib.c index 06b62e5..c9ee681 100644 --- a/crypto/zlib.c +++ b/crypto/zlib.c @@ -168,7 +168,7 @@ static int zlib_compress_update(struct crypto_pcomp *tfm, } ret = req->avail_out - stream->avail_out; - pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n", + pr_debug("avail_in %lu, avail_out %lu (consumed %lu, produced %u)\n", stream->avail_in, stream->avail_out, req->avail_in - stream->avail_in, ret); req->next_in = stream->next_in; @@ -198,7 +198,7 @@ static int zlib_compress_final(struct crypto_pcomp *tfm, } ret = req->avail_out - stream->avail_out; - pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n", + pr_debug("avail_in %lu, avail_out %lu (consumed %lu, produced %u)\n", stream->avail_in, stream->avail_out, req->avail_in - stream->avail_in, ret); req->next_in = stream->next_in; @@ -283,7 +283,7 @@ static int zlib_decompress_update(struct crypto_pcomp *tfm, } ret = req->avail_out - stream->avail_out; - pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n", + pr_debug("avail_in %lu, avail_out %lu (consumed %lu, produced %u)\n", stream->avail_in, stream->avail_out, req->avail_in - stream->avail_in, ret); req->next_in = stream->next_in; @@ -331,7 +331,7 @@ static int zlib_decompress_final(struct crypto_pcomp *tfm, } ret = req->avail_out - stream->avail_out; - pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n", + pr_debug("avail_in %lu, avail_out %lu (consumed %lu, produced %u)\n", stream->avail_in, stream->avail_out, req->avail_in - stream->avail_in, ret); req->next_in = stream->next_in; diff --git a/fs/jffs2/compr_zlib.c b/fs/jffs2/compr_zlib.c index 0b9a1e4..11ea1ee 100644 --- a/fs/jffs2/compr_zlib.c +++ b/fs/jffs2/compr_zlib.c @@ -94,11 +94,11 @@ static int jffs2_zlib_compress(unsigned char *data_in, while (def_strm.total_out < *dstlen - STREAM_END_SPACE && def_strm.total_in < *sourcelen) { def_strm.avail_out = *dstlen - (def_strm.total_out + STREAM_END_SPACE); - def_strm.avail_in = min((unsigned)(*sourcelen-def_strm.total_in), def_strm.avail_out); - jffs2_dbg(1, "calling deflate with avail_in %d, avail_out %d\n", + def_strm.avail_in = min((unsigned long)(*sourcelen-def_strm.total_in), def_strm.avail_out); + jffs2_dbg(1, "calling deflate with avail_in %ld, avail_out %ld\n", def_strm.avail_in, def_strm.avail_out); ret = zlib_deflate(&def_strm, Z_PARTIAL_FLUSH); - jffs2_dbg(1, "deflate returned with avail_in %d, avail_out %d, total_in %ld, total_out %ld\n", + jffs2_dbg(1, "deflate returned with avail_in %ld, avail_out %ld, total_in %ld, total_out %ld\n", def_strm.avail_in, def_strm.avail_out, def_strm.total_in, def_strm.total_out); if (ret != Z_OK) {
[-- Attachment #1: Type: text/plain, Size: 501 bytes --] Hi Andrew, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: drivers/base/memory.c: In function 'show_valid_zones': drivers/base/memory.c:384:22: warning: unused variable 'zone_prev' [-Wunused-variable] struct zone *zone, *zone_prev; ^ Introduced by commit 46d9999e7374 ("memory-hotplug: fix not enough check of valid zones"). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #1: Type: text/plain, Size: 757 bytes --] Hi Andrew, After merging the akpm tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: drivers/of/of_reserved_mem.c: In function 'of_reserved_mem_device_init': drivers/of/of_reserved_mem.c:253:3: warning: 'return' with no value, in function returning non-void [-Wreturn-type] return; ^ drivers/of/of_reserved_mem.c:259:3: warning: 'return' with no value, in function returning non-void [-Wreturn-type] return; ^ Caused by commit 1a29544cc8c9 ("drivers: of: add return value to of_reserved_mem_device_init"). This patch changed the return type of a function but did not update any or the return statements in that function. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --]
On Fri, 26 Sep 2014 20:42:00 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> drivers/of/of_reserved_mem.c: In function 'of_reserved_mem_device_init':
> drivers/of/of_reserved_mem.c:253:3: warning: 'return' with no value, in function returning non-void [-Wreturn-type]
> return;
> ^
> drivers/of/of_reserved_mem.c:259:3: warning: 'return' with no value, in function returning non-void [-Wreturn-type]
> return;
> ^
>
> Caused by commit 1a29544cc8c9 ("drivers: of: add return value to
> of_reserved_mem_device_init"). This patch changed the return type of a
> function but did not update any or the return statements in that
> function.
OK, thanks, I dropped it. I could have fixed it but it doesn't appear
to be well tested.
[-- Attachment #1: Type: text/plain, Size: 638 bytes --] Hi Andrew, After merging the akpm tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: In file included from include/linux/mm.h:52:0, from mm/gup.c:7: arch/arm/include/asm/pgtable.h:184:0: warning: "pgd_huge" redefined #define pgd_huge(pgd) (0) ^ In file included from mm/gup.c:6:0: include/linux/hugetlb.h:183:0: note: this is the location of the previous definition #define pgd_huge(x) 0 ^ Introduced by commit fee025d5dd4e ("mm: update generic gup implementation to handle hugepage directory"). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
Stephen Rothwell <sfr@canb.auug.org.au> writes: > Hi Andrew, > > After merging the akpm tree, today's linux-next build (arm multi_v7_defconfig) > produced this warning: > > In file included from include/linux/mm.h:52:0, > from mm/gup.c:7: > arch/arm/include/asm/pgtable.h:184:0: warning: "pgd_huge" redefined > #define pgd_huge(pgd) (0) > ^ > In file included from mm/gup.c:6:0: > include/linux/hugetlb.h:183:0: note: this is the location of the previous definition > #define pgd_huge(x) 0 > ^ > > Introduced by commit fee025d5dd4e ("mm: update generic gup > implementation to handle hugepage directory"). Should be fixed by. http://mid.gmane.org/1414570785-18966-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com IIUC the changes are going via powerpc tree. So not sure how it gets updated. -aneesh
[-- Attachment #1: Type: text/plain, Size: 452 bytes --] Hi Andrew, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: fs/eventfd.c: In function 'eventfd_poll': fs/eventfd.c:121:16: warning: unused variable 'flags' [-Wunused-variable] unsigned long flags; ^ Introduced by commit a90de8a54127 ("eventfd: don't take the spinlock in eventfd_poll"). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
On Mon, Jan 19, 2015 at 2:45 AM, Stephen Rothwell
<sfr@canb.auug.org.au> wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> fs/eventfd.c: In function 'eventfd_poll':
> fs/eventfd.c:121:16: warning: unused variable 'flags'
> [-Wunused-variable]
> unsigned long flags;
> ^
>
> Introduced by commit a90de8a54127 ("eventfd: don't take the spinlock
> in
> eventfd_poll").
Whoops, I'll send a v2.
-chris
[-- Attachment #1: Type: text/plain, Size: 493 bytes --] Hi Andrew, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: warning: (GDB_SCRIPTS) selects DEBUG_INFO which has unmet direct dependencies (DEBUG_KERNEL && !COMPILE_TEST) warning: (GDB_SCRIPTS) selects DEBUG_INFO which has unmet direct dependencies (DEBUG_KERNEL && !COMPILE_TEST) Introduced by commit 3cf8bb219e44 ("scripts/gdb: add infrastructure"). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-02-04 08:48, Stephen Rothwell wrote: > Hi Andrew, > > After merging the akpm-current tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > warning: (GDB_SCRIPTS) selects DEBUG_INFO which has unmet direct dependencies (DEBUG_KERNEL && !COMPILE_TEST) > warning: (GDB_SCRIPTS) selects DEBUG_INFO which has unmet direct dependencies (DEBUG_KERNEL && !COMPILE_TEST) > > Introduced by commit 3cf8bb219e44 ("scripts/gdb: add infrastructure"). I've posted a fix earlier today [1]. The Intel test robot informed me already. Jan [1] http://thread.gmane.org/gmane.linux.kernel/1881832 - -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlTRz/EACgkQitSsb3rl5xS3dQCg1ZPql+9XOcaC/hk7WSztRHDb 6JkAn1XATlgzopMoj9KgpbMApDnkKQYc =Edbi -----END PGP SIGNATURE-----
[-- Attachment #1: Type: text/plain, Size: 361 bytes --] Hi Andrew, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: ./usr/include/linux/userfaultfd.h:14: found __[us]{8,16,32,64} type without #include <linux/types.h> Introduced by commit 2873f48b446c ("userfaultfd: uAPI"). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
Hello, On Thu, Jun 04, 2015 at 10:29:28PM +1000, Stephen Rothwell wrote: > Hi Andrew, > > After merging the akpm-current tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > ./usr/include/linux/userfaultfd.h:14: found __[us]{8,16,32,64} type without #include <linux/types.h> > > Introduced by commit 2873f48b446c ("userfaultfd: uAPI"). Here's the fix: === >From 02b31b0a5e9dd5ddbcb4ad86f63fbcb0a2b5d8f2 Mon Sep 17 00:00:00 2001 From: Andrea Arcangeli <aarcange@redhat.com> Date: Thu, 4 Jun 2015 14:54:40 +0200 Subject: [PATCH] userfaultfd: uAPI: add missing include/types.h This will avoid the below warning: ./usr/include/linux/userfaultfd.h:14: found __[us]{8,16,32,64} type without #include <linux/types.h> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> --- include/uapi/linux/userfaultfd.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/uapi/linux/userfaultfd.h b/include/uapi/linux/userfaultfd.h index 9a8cd56..09c2e2a 100644 --- a/include/uapi/linux/userfaultfd.h +++ b/include/uapi/linux/userfaultfd.h @@ -9,6 +9,8 @@ #ifndef _LINUX_USERFAULTFD_H #define _LINUX_USERFAULTFD_H +#include <linux/types.h> + #define UFFD_API ((__u64)0xAA) /* FIXME: add "|UFFD_BIT_WP" to UFFD_API_BITS after implementing it */ #define UFFD_API_BITS (UFFD_BIT_WRITE)
Hi Andrew, After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: lib/genalloc.c: In function 'gen_pool_get': /scratch/sfr/next/lib/genalloc.c:599:6: warning: passing argument 4 of 'devres_find' discards 'const' qualifier from pointer target type p = devres_find(dev, devm_gen_pool_release, devm_gen_pool_match, name); ^ In file included from /scratch/sfr/next/include/linux/node.h:17:0, from /scratch/sfr/next/include/linux/cpu.h:16, from /scratch/sfr/next/include/linux/of_device.h:4, from /scratch/sfr/next/lib/genalloc.c:37: /scratch/sfr/next/include/linux/device.h:620:14: note: expected 'void *' but argument is of type 'const char *' extern void *devres_find(struct device *dev, dr_release_t release, ^ Caused by commit e89a70fd54f2 ("genalloc: add support of multiple gen_pools per device") -- Cheers, Stephen Rothwell sfr@canb.auug.org.au
On Thu, 16 Jul 2015 15:26:00 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> lib/genalloc.c: In function 'gen_pool_get':
> /scratch/sfr/next/lib/genalloc.c:599:6: warning: passing argument 4 of 'devres_find' discards 'const' qualifier from pointer target type
> p = devres_find(dev, devm_gen_pool_release, devm_gen_pool_match, name);
> ^
> In file included from /scratch/sfr/next/include/linux/node.h:17:0,
> from /scratch/sfr/next/include/linux/cpu.h:16,
> from /scratch/sfr/next/include/linux/of_device.h:4,
> from /scratch/sfr/next/lib/genalloc.c:37:
> /scratch/sfr/next/include/linux/device.h:620:14: note: expected 'void *' but argument is of type 'const char *'
> extern void *devres_find(struct device *dev, dr_release_t release,
> ^
>
> Caused by commit
>
> e89a70fd54f2 ("genalloc: add support of multiple gen_pools per device")
urgh. devres_find()'s `void *match' argument should always have been const.
I started to fix that but the fix spreads like a virus - by the time I had a
700 line diff I gave up.
So I guess we cast away the constness at the caller, like all the other
callers do :(
--- a/lib/genalloc.c~genalloc-add-support-of-multiple-gen_pools-per-device-fix
+++ a/lib/genalloc.c
@@ -596,7 +596,8 @@ struct gen_pool *gen_pool_get(struct dev
{
struct gen_pool **p;
- p = devres_find(dev, devm_gen_pool_release, devm_gen_pool_match, name);
+ p = devres_find(dev, devm_gen_pool_release, devm_gen_pool_match,
+ (void *)name);
if (!p)
return NULL;
return *p;
_
Hi Andrew, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/scsi/ipr.c: In function 'ipr_show_device_id': drivers/scsi/ipr.c:4462:34: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=] len = snprintf(buf, PAGE_SIZE, "0x%llx\n", be64_to_cpu(res->dev_id)); ^ Lots and lots like this :-( Probably introduced by commit eef17fb79096 ("byteswap: try to avoid __builtin_constant_p gcc bug") I guess __builtin_bswap64() has type "unsigned long int" :-( -- Cheers, Stephen Rothwell
Hi All,
On Fri, 29 Apr 2016 16:45:43 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> drivers/scsi/ipr.c: In function 'ipr_show_device_id':
> drivers/scsi/ipr.c:4462:34: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
> len = snprintf(buf, PAGE_SIZE, "0x%llx\n", be64_to_cpu(res->dev_id));
> ^
>
> Lots and lots like this :-(
>
> Introduced by commit
>
> eef17fb79096 ("byteswap: try to avoid __builtin_constant_p gcc bug")
>
> I guess __builtin_bswap64() has type "unsigned long int" :-(
So, I have reverted that commit for today ... it produces too many
warnings :-(
--
Cheers,
Stephen Rothwell
On Fri, Apr 29, 2016 at 04:45:43PM +1000, Stephen Rothwell wrote: > Hi Andrew, > > After merging the akpm-current tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > drivers/scsi/ipr.c: In function 'ipr_show_device_id': > drivers/scsi/ipr.c:4462:34: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=] > len = snprintf(buf, PAGE_SIZE, "0x%llx\n", be64_to_cpu(res->dev_id)); > ^ > > Lots and lots like this :-( > > Probably introduced by commit > > eef17fb79096 ("byteswap: try to avoid __builtin_constant_p gcc bug") > > I guess __builtin_bswap64() has type "unsigned long int" :-( Hm, I suppose this is cross-compiled on a powerpc host? We probably need to add a (__u64) cast to the return value of __builtin_bswap64(), like: diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h index de56fd5..d737804 100644 --- a/include/uapi/linux/swab.h +++ b/include/uapi/linux/swab.h @@ -123,7 +123,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val) * @x: value to byteswap */ #ifdef __HAVE_BUILTIN_BSWAP64__ -#define __swab64(x) __builtin_bswap64((__u64)(x)) +#define __swab64(x) (__u64)__builtin_bswap64((__u64)(x)) #else #define __swab64(x) \ (__builtin_constant_p((__u64)(x)) ? \ -- Josh
On Fri, Apr 29, 2016 at 08:32:19AM -0500, Josh Poimboeuf wrote:
> On Fri, Apr 29, 2016 at 04:45:43PM +1000, Stephen Rothwell wrote:
> > Hi Andrew,
> >
> > After merging the akpm-current tree, today's linux-next build (x86_64
> > allmodconfig) produced this warning:
> >
> > drivers/scsi/ipr.c: In function 'ipr_show_device_id':
> > drivers/scsi/ipr.c:4462:34: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
> > len = snprintf(buf, PAGE_SIZE, "0x%llx\n", be64_to_cpu(res->dev_id));
> > ^
> >
> > Lots and lots like this :-(
> >
> > Probably introduced by commit
> >
> > eef17fb79096 ("byteswap: try to avoid __builtin_constant_p gcc bug")
> >
> > I guess __builtin_bswap64() has type "unsigned long int" :-(
>
> Hm, I suppose this is cross-compiled on a powerpc host?
>
> We probably need to add a (__u64) cast to the return value of
> __builtin_bswap64(), like:
>
> diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
> index de56fd5..d737804 100644
> --- a/include/uapi/linux/swab.h
> +++ b/include/uapi/linux/swab.h
> @@ -123,7 +123,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)
> * @x: value to byteswap
> */
> #ifdef __HAVE_BUILTIN_BSWAP64__
> -#define __swab64(x) __builtin_bswap64((__u64)(x))
> +#define __swab64(x) (__u64)__builtin_bswap64((__u64)(x))
> #else
> #define __swab64(x) \
> (__builtin_constant_p((__u64)(x)) ? \
Never mind about cross-compiling on powerpc, this has nothing to do with
that. But the above patch does seem to fix it.
--
Josh
Hi Josh,
On Fri, 29 Apr 2016 09:03:42 -0500 Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> On Fri, Apr 29, 2016 at 08:32:19AM -0500, Josh Poimboeuf wrote:
> > On Fri, Apr 29, 2016 at 04:45:43PM +1000, Stephen Rothwell wrote:
> > > Hi Andrew,
> > >
> > > After merging the akpm-current tree, today's linux-next build (x86_64
> > > allmodconfig) produced this warning:
> > >
> > > drivers/scsi/ipr.c: In function 'ipr_show_device_id':
> > > drivers/scsi/ipr.c:4462:34: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
> > > len = snprintf(buf, PAGE_SIZE, "0x%llx\n", be64_to_cpu(res->dev_id));
> > > ^
> > >
> > > Lots and lots like this :-(
> > >
> > > Probably introduced by commit
> > >
> > > eef17fb79096 ("byteswap: try to avoid __builtin_constant_p gcc bug")
> > >
> > > I guess __builtin_bswap64() has type "unsigned long int" :-(
> >
> > Hm, I suppose this is cross-compiled on a powerpc host?
> >
> > We probably need to add a (__u64) cast to the return value of
> > __builtin_bswap64(), like:
> >
> > diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
> > index de56fd5..d737804 100644
> > --- a/include/uapi/linux/swab.h
> > +++ b/include/uapi/linux/swab.h
> > @@ -123,7 +123,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)
> > * @x: value to byteswap
> > */
> > #ifdef __HAVE_BUILTIN_BSWAP64__
> > -#define __swab64(x) __builtin_bswap64((__u64)(x))
> > +#define __swab64(x) (__u64)__builtin_bswap64((__u64)(x))
> > #else
> > #define __swab64(x) \
> > (__builtin_constant_p((__u64)(x)) ? \
>
>
> Never mind about cross-compiling on powerpc, this has nothing to do with
> that. But the above patch does seem to fix it.
Thanks. I have added Andrew's tidied up version to linux-next to
replace the revert.
--
Cheers,
Stephen Rothwell
Hi Andrew, After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: mm/oom_kill.c: In function '__oom_reap_task': mm/oom_kill.c:537:2: warning: 'mm' may be used uninitialized in this function [-Wmaybe-uninitialized] mmput_async(mm); ^ Introduced by commit df1e2f56632d ("oom_reaper: close race with exiting task") This is real - the first "goto unlock_oom" is before "mm" has been assigned. -- Cheers, Stephen Rothwell
On Fri, 27 May 2016 13:07:10 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > Hi Andrew, > > After merging the akpm-current tree, today's linux-next build (arm > multi_v7_defconfig) produced this warning: > > mm/oom_kill.c: In function '__oom_reap_task': > mm/oom_kill.c:537:2: warning: 'mm' may be used uninitialized in this function [-Wmaybe-uninitialized] > mmput_async(mm); > ^ > > Introduced by commit > > df1e2f56632d ("oom_reaper: close race with exiting task") > > This is real - the first "goto unlock_oom" is before "mm" has been > assigned. Yup, thanks. From: Andrew Morton <akpm@linux-foundation.org> Subject: oom_reaper-close-race-with-exiting-task-fix fix use of unused `mm', Per Stephen Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- mm/oom_kill.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff -puN mm/oom_kill.c~oom_reaper-close-race-with-exiting-task-fix mm/oom_kill.c --- a/mm/oom_kill.c~oom_reaper-close-race-with-exiting-task-fix +++ a/mm/oom_kill.c @@ -443,7 +443,7 @@ static bool __oom_reap_task(struct task_ { struct mmu_gather tlb; struct vm_area_struct *vma; - struct mm_struct *mm; + struct mm_struct *mm = NULL; struct task_struct *p; struct zap_details details = {.check_swap_entries = true, .ignore_dirty = true}; @@ -534,7 +534,8 @@ unlock_oom: * different context because we shouldn't risk we get stuck there and * put the oom_reaper out of the way. */ - mmput_async(mm); + if (mm) + mmput_async(mm); return ret; } _
Hi Andrew, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig and x86_64 allmodconfig) produced this warning: drivers/base/node.c: In function 'node_read_meminfo': drivers/base/node.c:127:31: warning: passing argument 1 of 'node_page_state' makes pointer from integer without a cast [-Wint-conversion] nid, node_page_state(nid, NR_KERNEL_STACK) * ^ In file included from include/linux/mm.h:999:0, from drivers/base/node.c:7: include/linux/vmstat.h:200:22: note: expected 'struct pglist_data *' but argument is of type 'int' extern unsigned long node_page_state(struct pglist_data *pgdat, ^ Introduced by commit 2bfac6c1ec44 ("mm, vmstat: add infrastructure for per-node vmstats") -- Cheers, Stephen Rothwell
On Thu, Jun 23, 2016 at 04:53:21PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig and x86_64 allmodconfig) produced this warning:
>
I asked that Andrew drop the patch series that introduced this problem.
It's fixed in a private tree but it's not ready for reposting yet.
--
Mel Gorman
SUSE Labs
Hi Andrew, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: mm/hugetlb.c:1166:21: warning: 'alloc_gigantic_page' defined but not used [-Wunused-function] static struct page *alloc_gigantic_page(int nid, unsigned int order) ^ Introduced by commit 4acc8ccc3c57 ("mm/hugetlb.c: rename some allocation functions") -- Cheers, Stephen Rothwell
On Wed, Nov 09, 2016 at 03:10:06PM +1100, Stephen Rothwell wrote: Hi Stephen, > Hi Andrew, > > After merging the akpm-current tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > mm/hugetlb.c:1166:21: warning: 'alloc_gigantic_page' defined but not used [-Wunused-function] > static struct page *alloc_gigantic_page(int nid, unsigned int order) The warning should be fixed by the patch (or next version of this patch): http://marc.info/?l=linux-mm&m=147867535926059&w=2 Thanks Huang Shijie
On Wed, 9 Nov 2016 15:18:24 +0800 Huang Shijie <shijie.huang@arm.com> wrote:
> On Wed, Nov 09, 2016 at 03:10:06PM +1100, Stephen Rothwell wrote:
> Hi Stephen,
> > Hi Andrew,
> >
> > After merging the akpm-current tree, today's linux-next build (powerpc
> > ppc64_defconfig) produced this warning:
> >
> > mm/hugetlb.c:1166:21: warning: 'alloc_gigantic_page' defined but not used [-Wunused-function]
> > static struct page *alloc_gigantic_page(int nid, unsigned int order)
> The warning should be fixed by the patch (or next version of this patch):
> http://marc.info/?l=linux-mm&m=147867535926059&w=2
I'll drop "mm/hugetlb.c: rename some allocation functions" for now.
Please change it to fix this warning then add it to the surplus-page
series when resending that.
Hi Andrew,
On Wed, 9 Nov 2016 13:21:53 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 9 Nov 2016 15:18:24 +0800 Huang Shijie <shijie.huang@arm.com> wrote:
>
> > On Wed, Nov 09, 2016 at 03:10:06PM +1100, Stephen Rothwell wrote:
> > Hi Stephen,
> > > Hi Andrew,
> > >
> > > After merging the akpm-current tree, today's linux-next build (powerpc
> > > ppc64_defconfig) produced this warning:
> > >
> > > mm/hugetlb.c:1166:21: warning: 'alloc_gigantic_page' defined but not used [-Wunused-function]
> > > static struct page *alloc_gigantic_page(int nid, unsigned int order)
> > The warning should be fixed by the patch (or next version of this patch):
> > http://marc.info/?l=linux-mm&m=147867535926059&w=2
>
> I'll drop "mm/hugetlb.c: rename some allocation functions" for now.
> Please change it to fix this warning then add it to the surplus-page
> series when resending that.
I have dropped it from linux-next today.
--
Cheers,
Stephen Rothwell
Hi Andrew, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig and x86_64 allmodconfig) produced this warning: fs/ext4/file.c:279:1: warning: 'ext4_dax_huge_fault' defined but not used [-Wunused-function] ext4_dax_huge_fault(struct vm_fault *vmf) ^ Introduced by commit 80a841811260 ("mm,fs,dax: change ->pmd_fault to ->huge_fault") Looks like the replacement in ext4_dax_vm_ops may be incorrect? -- Cheers, Stephen Rothwell
Hi Andrew, After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: In file included from include/asm-generic/bug.h:15:0, from arch/arm/include/asm/bug.h:59, from include/linux/bug.h:4, from include/linux/elfcore.h:5, from include/linux/crash_core.h:5, from kernel/crash_core.c:9: kernel/crash_core.c: In function 'vmcoreinfo_append_str': include/linux/kernel.h:757:16: warning: comparison of distinct pointer types lacks a cast (void) (&min1 == &min2); \ ^ include/linux/kernel.h:760:2: note: in expansion of macro '__min' __min(typeof(x), typeof(y), \ ^ kernel/crash_core.c:360:6: note: in expansion of macro 'min' r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size); ^ Introduced by commit fc7d2b44367f ("powerpc/fadump: use the correct VMCOREINFO_NOTE_SIZE for phdr") -- Cheers, Stephen Rothwell
On 05/15/2017 at 09:56 AM, Stephen Rothwell wrote: > Hi Andrew, > > After merging the akpm-current tree, today's linux-next build (arm > multi_v7_defconfig) produced this warning: > > In file included from include/asm-generic/bug.h:15:0, > from arch/arm/include/asm/bug.h:59, > from include/linux/bug.h:4, > from include/linux/elfcore.h:5, > from include/linux/crash_core.h:5, > from kernel/crash_core.c:9: > kernel/crash_core.c: In function 'vmcoreinfo_append_str': > include/linux/kernel.h:757:16: warning: comparison of distinct pointer types lacks a cast > (void) (&min1 == &min2); \ > ^ > include/linux/kernel.h:760:2: note: in expansion of macro '__min' > __min(typeof(x), typeof(y), \ > ^ > kernel/crash_core.c:360:6: note: in expansion of macro 'min' > r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size); > ^ > > Introduced by commit > > fc7d2b44367f ("powerpc/fadump: use the correct VMCOREINFO_NOTE_SIZE for phdr") > Hi Stephen/Andrew, Sorry for the trouble. The following patch will fix it, do you want to me to send it out separately? or help merge it into fc7d2b44367f ("powerpc/fadump: use the correct VMCOREINFO_NOTE_SIZE for phdr") directly? Thanks, Xunlei =========================================== From: Xunlei Pang <xlpang@redhat.com> Subject: [PATCH] crash: Fix build warning linux-next build (arm multi_v7_defconfig) produced this warning: In file included from include/asm-generic/bug.h:15:0, from arch/arm/include/asm/bug.h:59, from include/linux/bug.h:4, from include/linux/elfcore.h:5, from include/linux/crash_core.h:5, from kernel/crash_core.c:9: kernel/crash_core.c: In function 'vmcoreinfo_append_str': include/linux/kernel.h:757:16: warning: comparison of distinct pointer types lacks a cast (void) (&min1 == &min2); \ ^ include/linux/kernel.h:760:2: note: in expansion of macro '__min' __min(typeof(x), typeof(y), \ ^ kernel/crash_core.c:360:6: note: in expansion of macro 'min' r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size); ^ This patch fixes it. Signed-off-by: Xunlei Pang <xlpang@redhat.com> --- kernel/crash_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/crash_core.c b/kernel/crash_core.c index 4a4a4ba..6db80fc 100644 --- a/kernel/crash_core.c +++ b/kernel/crash_core.c @@ -357,7 +357,7 @@ void vmcoreinfo_append_str(const char *fmt, ...) r = vscnprintf(buf, sizeof(buf), fmt, args); va_end(args); - r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size); + r = min(r, (size_t)VMCOREINFO_BYTES - vmcoreinfo_size); memcpy(&vmcoreinfo_data[vmcoreinfo_size], buf, r); -- 1.8.3.1
Hi Xunlei,
On Mon, 15 May 2017 12:02:18 +0800 Xunlei Pang <xpang@redhat.com> wrote:
>
> The following patch will fix it, do you want to me to send it out separately? or help merge it into
> fc7d2b44367f ("powerpc/fadump: use the correct VMCOREINFO_NOTE_SIZE for phdr") directly?
Andrew normally takes these as separate patches and then merges them
before sending them on.
--
Cheers,
Stephen Rothwell
Hi Andrew, After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: mm/vmstat.c: In function 'pagetypeinfo_showblockcount_print': mm/vmstat.c:1230:8: warning: 'page' may be used uninitialized in this function [-Wmaybe-uninitialized] if (!memmap_valid_within(pfn, page, zone)) ^ Introduced by commit 36c7473b3c85 ("mm, vmstat: skip reporting offline pages in pagetypeinfo") That really doesn't look good. -- Cheers, Stephen Rothwell
Hi Andrew, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: fs/jfs/jfs_metapage.c: In function 'force_metapage': fs/jfs/jfs_metapage.c:714:2: warning: ignoring return value of 'write_one_page', declared with attribute warn_unused_result [-Wunused-result] write_one_page(page); ^ fs/jfs/jfs_metapage.c: In function 'release_metapage': fs/jfs/jfs_metapage.c:759:4: warning: ignoring return value of 'write_one_page', declared with attribute warn_unused_result [-Wunused-result] write_one_page(page); ^ Introduced by commit f8652aebee02 ("mm: drop "wait" parameter from write_one_page()") These call sites were updated for the droppping of the argument, but not for the addition of __must_check :-( -- Cheers, Stephen Rothwell
On Fri, 2017-05-26 at 12:43 +1000, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> fs/jfs/jfs_metapage.c: In function 'force_metapage':
> fs/jfs/jfs_metapage.c:714:2: warning: ignoring return value of 'write_one_page', declared with attribute warn_unused_result [-Wunused-result]
> write_one_page(page);
> ^
> fs/jfs/jfs_metapage.c: In function 'release_metapage':
> fs/jfs/jfs_metapage.c:759:4: warning: ignoring return value of 'write_one_page', declared with attribute warn_unused_result [-Wunused-result]
> write_one_page(page);
> ^
>
> Introduced by commit
>
> f8652aebee02 ("mm: drop "wait" parameter from write_one_page()")
>
> These call sites were updated for the droppping of the argument, but
> not for the addition of __must_check :-(
>
(cc'ing Dave...)
Yeah, that's a known issue. When Willy reviewed the patch originally he
asked me to add a __must_check there so that JFS would pick up some
warnings for this.
JFS really ought to check the return code there and do something sane
with it. Dave?
--
Jeff Layton <jlayton@redhat.com>
On 05/26/2017 05:16 AM, Jeff Layton wrote:
> On Fri, 2017-05-26 at 12:43 +1000, Stephen Rothwell wrote:
>> Hi Andrew,
>>
>> After merging the akpm-current tree, today's linux-next build (powerpc
>> ppc64_defconfig) produced this warning:
>>
>> fs/jfs/jfs_metapage.c: In function 'force_metapage':
>> fs/jfs/jfs_metapage.c:714:2: warning: ignoring return value of 'write_one_page', declared with attribute warn_unused_result [-Wunused-result]
>> write_one_page(page);
>> ^
>> fs/jfs/jfs_metapage.c: In function 'release_metapage':
>> fs/jfs/jfs_metapage.c:759:4: warning: ignoring return value of 'write_one_page', declared with attribute warn_unused_result [-Wunused-result]
>> write_one_page(page);
>> ^
>>
>> Introduced by commit
>>
>> f8652aebee02 ("mm: drop "wait" parameter from write_one_page()")
>>
>> These call sites were updated for the droppping of the argument, but
>> not for the addition of __must_check :-(
>>
>
> (cc'ing Dave...)
>
> Yeah, that's a known issue. When Willy reviewed the patch originally he
> asked me to add a __must_check there so that JFS would pick up some
> warnings for this.
>
> JFS really ought to check the return code there and do something sane
> with it. Dave?
This is true. I promised to do something about it. I'll try to get a
patch out later today.
Dave
Hi Andrew, After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: fs/proc/task_mmu.c: In function 'show_map_vma': fs/proc/task_mmu.c:285:28: warning: unused variable 'priv' [-Wunused-variable] struct proc_maps_private *priv = m->private; ^ Introduced by commit 14ccc3193225 ("fs, proc: remove priv argument from is_stack") -- Cheers, Stephen Rothwell
Hi Andrew, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: In file included from include/linux/mmzone.h:17:0, from include/linux/mempolicy.h:10, from mm/mempolicy.c:70: mm/mempolicy.c: In function 'mpol_to_str': include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always evaluate as 'true' [-Waddress] #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? (maskp)->bits : NULL ^ mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args' nodemask_pr_args(&nodes)); ^ include/linux/nodemask.h:107:69: warning: the address of 'nodes' will always evaluate as 'true' [-Waddress] #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? (maskp)->bits : NULL ^ mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args' nodemask_pr_args(&nodes)); ^ Introduced by commit b2c1ed23bdc1 ("mm: simplify nodemask printing") -- Cheers, Stephen Rothwell
Hi Andrew, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: In file included from include/linux/printk.h:7:0, from include/linux/kernel.h:14, from lib/test_find_bit.c:28: lib/test_find_bit.c: In function 'test_find_first_bit': include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of type 'long int', but argument 2 has type 'cycles_t {aka long long unsigned int}' [-Wformat=] #define KERN_SOH "\001" /* ASCII Start Of Header */ ^ include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH' #define KERN_ERR KERN_SOH "3" /* error conditions */ ^ include/linux/printk.h:300:9: note: in expansion of macro 'KERN_ERR' printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__) ^ lib/test_find_bit.c:54:2: note: in expansion of macro 'pr_err' pr_err("find_first_bit:\t\t%ld cycles,\t%ld iterations\n", cycles, cnt); ^ lib/test_find_bit.c: In function 'test_find_next_bit': include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of type 'long int', but argument 2 has type 'cycles_t {aka long long unsigned int}' [-Wformat=] #define KERN_SOH "\001" /* ASCII Start Of Header */ ^ include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH' #define KERN_ERR KERN_SOH "3" /* error conditions */ ^ include/linux/printk.h:300:9: note: in expansion of macro 'KERN_ERR' printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__) ^ lib/test_find_bit.c:68:2: note: in expansion of macro 'pr_err' pr_err("find_next_bit:\t\t%ld cycles,\t%ld iterations\n", cycles, cnt); ^ lib/test_find_bit.c: In function 'test_find_next_zero_bit': include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of type 'long int', but argument 2 has type 'cycles_t {aka long long unsigned int}' [-Wformat=] #define KERN_SOH "\001" /* ASCII Start Of Header */ ^ include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH' #define KERN_ERR KERN_SOH "3" /* error conditions */ ^ include/linux/printk.h:300:9: note: in expansion of macro 'KERN_ERR' printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__) ^ lib/test_find_bit.c:82:2: note: in expansion of macro 'pr_err' pr_err("find_next_zero_bit:\t%ld cycles,\t%ld iterations\n", ^ lib/test_find_bit.c: In function 'test_find_last_bit': include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of type 'long int', but argument 2 has type 'cycles_t {aka long long unsigned int}' [-Wformat=] #define KERN_SOH "\001" /* ASCII Start Of Header */ ^ include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH' #define KERN_ERR KERN_SOH "3" /* error conditions */ ^ include/linux/printk.h:300:9: note: in expansion of macro 'KERN_ERR' printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__) ^ lib/test_find_bit.c:102:2: note: in expansion of macro 'pr_err' pr_err("find_last_bit:\t\t%ld cycles,\t%ld iterations\n", cycles, cnt); ^ Introduced by commit 09588b1f1d58 ("lib: test module for find_*_bit() functions") -- Cheers, Stephen Rothwell
On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> In file included from include/linux/mmzone.h:17:0,
> from include/linux/mempolicy.h:10,
> from mm/mempolicy.c:70:
> mm/mempolicy.c: In function 'mpol_to_str':
> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always evaluate as 'true' [-Waddress]
> #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? (maskp)->bits : NULL
> ^
> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
> nodemask_pr_args(&nodes));
> ^
Hmm, this warning is quite surprising to me. Sure in this particular
case maskp will always be non-NULL so we always expand to
MAX_NUMNODES, maskp->bits
which is what we want. But we have other users which may be NULL. Does
anybody understan why this warns at all?
--
Michal Hocko
SUSE Labs
On Mon 13-11-17 09:09:55, Michal Hocko wrote:
> On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
> > Hi Andrew,
> >
> > After merging the akpm-current tree, today's linux-next build (powerpc
> > ppc64_defconfig) produced this warning:
> >
> > In file included from include/linux/mmzone.h:17:0,
> > from include/linux/mempolicy.h:10,
> > from mm/mempolicy.c:70:
> > mm/mempolicy.c: In function 'mpol_to_str':
> > include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always evaluate as 'true' [-Waddress]
> > #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? (maskp)->bits : NULL
> > ^
> > mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
> > nodemask_pr_args(&nodes));
> > ^
>
> Hmm, this warning is quite surprising to me. Sure in this particular
> case maskp will always be non-NULL so we always expand to
> MAX_NUMNODES, maskp->bits
> which is what we want. But we have other users which may be NULL. Does
> anybody understan why this warns at all?
Strange I played with the following minimal test case and it warns only
for the explicit &m use while n is clearly never null as well. This all
smells like -Waddress is just confused (at least with my gcc 7.2.0-12
#include <stdio.h>
#define MAX_NUMNODES 10
struct mask {
void *bits;
};
#define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? (maskp)->bits : NULL
int foo(void)
{
struct mask m;
struct mask *n = &m;
printf("%*p\n", nodemask_pr_args(&m));
printf("%*p\n", nodemask_pr_args(n));
return 0;
}
--
Michal Hocko
SUSE Labs
On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko <mhocko@kernel.org> wrote:
> On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
>> Hi Andrew,
>>
>> After merging the akpm-current tree, today's linux-next build (powerpc
>> ppc64_defconfig) produced this warning:
>>
>> In file included from include/linux/mmzone.h:17:0,
>> from include/linux/mempolicy.h:10,
>> from mm/mempolicy.c:70:
>> mm/mempolicy.c: In function 'mpol_to_str':
>> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always evaluate as 'true' [-Waddress]
>> #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? (maskp)->bits : NULL
>> ^
>> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>> nodemask_pr_args(&nodes));
>> ^
>
> Hmm, this warning is quite surprising to me. Sure in this particular
> case maskp will always be non-NULL so we always expand to
> MAX_NUMNODES, maskp->bits
> which is what we want. But we have other users which may be NULL. Does
> anybody understan why this warns at all?
As I understand it, the warning tries to address a common typo of accidentally
testing the pointer to a stack object for being non-NULL, rather than the object
pointed to for being non-zero.
Adding an extra '!= NULL' comparison gets rid of the warning for me:
#define nodemask_pr_args(maskp) \
((maskp) != NULL) ? MAX_NUMNODES : 0, \
((maskp) != NULL) ?(maskp)->bits : NULL
Arnd
On Mon 13-11-17 12:43:08, Arnd Bergmann wrote:
> On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
> >> Hi Andrew,
> >>
> >> After merging the akpm-current tree, today's linux-next build (powerpc
> >> ppc64_defconfig) produced this warning:
> >>
> >> In file included from include/linux/mmzone.h:17:0,
> >> from include/linux/mempolicy.h:10,
> >> from mm/mempolicy.c:70:
> >> mm/mempolicy.c: In function 'mpol_to_str':
> >> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always evaluate as 'true' [-Waddress]
> >> #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? (maskp)->bits : NULL
> >> ^
> >> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
> >> nodemask_pr_args(&nodes));
> >> ^
> >
> > Hmm, this warning is quite surprising to me. Sure in this particular
> > case maskp will always be non-NULL so we always expand to
> > MAX_NUMNODES, maskp->bits
> > which is what we want. But we have other users which may be NULL. Does
> > anybody understan why this warns at all?
>
> As I understand it, the warning tries to address a common typo of accidentally
> testing the pointer to a stack object for being non-NULL, rather than the object
> pointed to for being non-zero.
>
> Adding an extra '!= NULL' comparison gets rid of the warning for me:
>
> #define nodemask_pr_args(maskp) \
> ((maskp) != NULL) ? MAX_NUMNODES : 0, \
> ((maskp) != NULL) ?(maskp)->bits : NULL
OK, that is a reasonable workaround. I was talking to our gcc guy and
he suggested to report a bug for this. Andrew, could you fold the
explicit != NULL check into the patch please?
--
Michal Hocko
SUSE Labs
On Mon, Nov 13, 2017 at 12:54 PM, Michal Hocko <mhocko@kernel.org> wrote:
> On Mon 13-11-17 12:43:08, Arnd Bergmann wrote:
>> On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko <mhocko@kernel.org> wrote:
>> > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
>> >> Hi Andrew,
>> >>
>> >> After merging the akpm-current tree, today's linux-next build (powerpc
>> >> ppc64_defconfig) produced this warning:
>> >>
>> >> In file included from include/linux/mmzone.h:17:0,
>> >> from include/linux/mempolicy.h:10,
>> >> from mm/mempolicy.c:70:
>> >> mm/mempolicy.c: In function 'mpol_to_str':
>> >> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always evaluate as 'true' [-Waddress]
>> >> #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? (maskp)->bits : NULL
>> >> ^
>> >> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>> >> nodemask_pr_args(&nodes));
>> >> ^
>> >
>> > Hmm, this warning is quite surprising to me. Sure in this particular
>> > case maskp will always be non-NULL so we always expand to
>> > MAX_NUMNODES, maskp->bits
>> > which is what we want. But we have other users which may be NULL. Does
>> > anybody understan why this warns at all?
>>
>> As I understand it, the warning tries to address a common typo of accidentally
>> testing the pointer to a stack object for being non-NULL, rather than the object
>> pointed to for being non-zero.
>>
>> Adding an extra '!= NULL' comparison gets rid of the warning for me:
>>
>> #define nodemask_pr_args(maskp) \
>> ((maskp) != NULL) ? MAX_NUMNODES : 0, \
>> ((maskp) != NULL) ?(maskp)->bits : NULL
>
> OK, that is a reasonable workaround. I was talking to our gcc guy and
> he suggested to report a bug for this.
That might also be useful. Some warnings in gcc get disabled when
they show up inside of a macro, and that could presumably be done
here too.
Arnd
On Mon 13-11-17 12:54:30, Michal Hocko wrote: > On Mon 13-11-17 12:43:08, Arnd Bergmann wrote: > > On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko <mhocko@kernel.org> wrote: > > > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote: > > >> Hi Andrew, > > >> > > >> After merging the akpm-current tree, today's linux-next build (powerpc > > >> ppc64_defconfig) produced this warning: > > >> > > >> In file included from include/linux/mmzone.h:17:0, > > >> from include/linux/mempolicy.h:10, > > >> from mm/mempolicy.c:70: > > >> mm/mempolicy.c: In function 'mpol_to_str': > > >> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always evaluate as 'true' [-Waddress] > > >> #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? (maskp)->bits : NULL > > >> ^ > > >> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args' > > >> nodemask_pr_args(&nodes)); > > >> ^ > > > > > > Hmm, this warning is quite surprising to me. Sure in this particular > > > case maskp will always be non-NULL so we always expand to > > > MAX_NUMNODES, maskp->bits > > > which is what we want. But we have other users which may be NULL. Does > > > anybody understan why this warns at all? > > > > As I understand it, the warning tries to address a common typo of accidentally > > testing the pointer to a stack object for being non-NULL, rather than the object > > pointed to for being non-zero. > > > > Adding an extra '!= NULL' comparison gets rid of the warning for me: > > > > #define nodemask_pr_args(maskp) \ > > ((maskp) != NULL) ? MAX_NUMNODES : 0, \ > > ((maskp) != NULL) ?(maskp)->bits : NULL > > OK, that is a reasonable workaround. I was talking to our gcc guy and > he suggested to report a bug for this. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82963 -- Michal Hocko SUSE Labs
Hi all,
On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
> >>
> >> After merging the akpm-current tree, today's linux-next build (powerpc
> >> ppc64_defconfig) produced this warning:
> >>
> >> In file included from include/linux/mmzone.h:17:0,
> >> from include/linux/mempolicy.h:10,
> >> from mm/mempolicy.c:70:
> >> mm/mempolicy.c: In function 'mpol_to_str':
> >> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always evaluate as 'true' [-Waddress]
> >> #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? (maskp)->bits : NULL
> >> ^
> >> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
> >> nodemask_pr_args(&nodes));
> >> ^
> >
> > Hmm, this warning is quite surprising to me. Sure in this particular
> > case maskp will always be non-NULL so we always expand to
> > MAX_NUMNODES, maskp->bits
> > which is what we want. But we have other users which may be NULL. Does
> > anybody understan why this warns at all?
>
> As I understand it, the warning tries to address a common typo of accidentally
> testing the pointer to a stack object for being non-NULL, rather than the object
> pointed to for being non-zero.
>
> Adding an extra '!= NULL' comparison gets rid of the warning for me:
>
> #define nodemask_pr_args(maskp) \
> ((maskp) != NULL) ? MAX_NUMNODES : 0, \
> ((maskp) != NULL) ?(maskp)->bits : NULL
>
> Arnd
This warning now exists in Linus' tree :-(
--
Cheers,
Stephen Rothwell
Hi all,
On Fri, 17 Nov 2017 09:44:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
> > >>
> > >> After merging the akpm-current tree, today's linux-next build (powerpc
> > >> ppc64_defconfig) produced this warning:
> > >>
> > >> In file included from include/linux/mmzone.h:17:0,
> > >> from include/linux/mempolicy.h:10,
> > >> from mm/mempolicy.c:70:
> > >> mm/mempolicy.c: In function 'mpol_to_str':
> > >> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always evaluate as 'true' [-Waddress]
> > >> #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? (maskp)->bits : NULL
> > >> ^
> > >> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
> > >> nodemask_pr_args(&nodes));
> > >> ^
> > >
> > > Hmm, this warning is quite surprising to me. Sure in this particular
> > > case maskp will always be non-NULL so we always expand to
> > > MAX_NUMNODES, maskp->bits
> > > which is what we want. But we have other users which may be NULL. Does
> > > anybody understan why this warns at all?
> >
> > As I understand it, the warning tries to address a common typo of accidentally
> > testing the pointer to a stack object for being non-NULL, rather than the object
> > pointed to for being non-zero.
> >
> > Adding an extra '!= NULL' comparison gets rid of the warning for me:
> >
> > #define nodemask_pr_args(maskp) \
> > ((maskp) != NULL) ? MAX_NUMNODES : 0, \
> > ((maskp) != NULL) ?(maskp)->bits : NULL
> >
> > Arnd
>
> This warning now exists in Linus' tree :-(
Looking closer, it seems that the above workaround doesn't work for my
compiler (gcc v5.2.0):
In file included from include/linux/mmzone.h:17:0,
from include/linux/mempolicy.h:10,
from mm/mempolicy.c:70:
mm/mempolicy.c: In function 'mpol_to_str':
include/linux/nodemask.h:108:11: warning: the comparison will always evaluate as 'true' for the address of 'nodes' will never be NULL [-Waddress]
((maskp) != NULL) ? MAX_NUMNODES : 0, \
^
mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
nodemask_pr_args(&nodes));
^
include/linux/nodemask.h:109:11: warning: the comparison will always evaluate as 'true' for the address of 'nodes' will never be NULL [-Waddress]
((maskp) != NULL) ? (maskp)->bits : NULL
^
mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
nodemask_pr_args(&nodes));
^
--
Cheers,
Stephen Rothwell
Hi, On 2017/11/17 11:53, Stephen Rothwell wrote: > Hi all, > > On Fri, 17 Nov 2017 09:44:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: >> >> On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann <arnd@arndb.de> wrote: >>> >>> On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko <mhocko@kernel.org> wrote: >>>> On Mon 13-11-17 16:42:06, Stephen Rothwell wrote: >>>>> >>>>> After merging the akpm-current tree, today's linux-next build (powerpc >>>>> ppc64_defconfig) produced this warning: >>>>> >>>>> In file included from include/linux/mmzone.h:17:0, >>>>> from include/linux/mempolicy.h:10, >>>>> from mm/mempolicy.c:70: >>>>> mm/mempolicy.c: In function 'mpol_to_str': >>>>> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always evaluate as 'true' [-Waddress] >>>>> #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? (maskp)->bits : NULL >>>>> ^ >>>>> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args' >>>>> nodemask_pr_args(&nodes)); >>>>> ^ >>>> >>>> Hmm, this warning is quite surprising to me. Sure in this particular >>>> case maskp will always be non-NULL so we always expand to >>>> MAX_NUMNODES, maskp->bits >>>> which is what we want. But we have other users which may be NULL. Does >>>> anybody understan why this warns at all? >>> >>> As I understand it, the warning tries to address a common typo of accidentally >>> testing the pointer to a stack object for being non-NULL, rather than the object >>> pointed to for being non-zero. >>> >>> Adding an extra '!= NULL' comparison gets rid of the warning for me: >>> >>> #define nodemask_pr_args(maskp) \ >>> ((maskp) != NULL) ? MAX_NUMNODES : 0, \ >>> ((maskp) != NULL) ?(maskp)->bits : NULL >>> >>> Arnd >> >> This warning now exists in Linus' tree :-( > > Looking closer, it seems that the above workaround doesn't work for my > compiler (gcc v5.2.0): > I also came across this issue using Linus' tree and my gcc is gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.5). CC drivers/clk/renesas/rcar-gen3-cpg.o In file included from ./include/linux/mmzone.h:17:0, from ./include/linux/mempolicy.h:10, from mm/mempolicy.c:70: mm/mempolicy.c: In function ‘mpol_to_str’: ./include/linux/nodemask.h:108:11: warning: the comparison will always evaluate as ‘true’ for the address of ‘nodes’ will never be NULL [-Waddress] ((maskp) != NULL) ? MAX_NUMNODES : 0, \ ^ mm/mempolicy.c:2817:11: note: in expansion of macro ‘nodemask_pr_args’ nodemask_pr_args(&nodes)); ^ ./include/linux/nodemask.h:109:11: warning: the comparison will always evaluate as ‘true’ for the address of ‘nodes’ will never be NULL [-Waddress] ((maskp) != NULL) ? (maskp)->bits : NULL ^ mm/mempolicy.c:2817:11: note: in expansion of macro ‘nodemask_pr_args’ nodemask_pr_args(&nodes)); ^ CC drivers/clk/renesas/renesas-cpg-mssr.o Thanks, Shaokun > In file included from include/linux/mmzone.h:17:0, > from include/linux/mempolicy.h:10, > from mm/mempolicy.c:70: > mm/mempolicy.c: In function 'mpol_to_str': > include/linux/nodemask.h:108:11: warning: the comparison will always evaluate as 'true' for the address of 'nodes' will never be NULL [-Waddress] > ((maskp) != NULL) ? MAX_NUMNODES : 0, \ > ^ > mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args' > nodemask_pr_args(&nodes)); > ^ > include/linux/nodemask.h:109:11: warning: the comparison will always evaluate as 'true' for the address of 'nodes' will never be NULL [-Waddress] > ((maskp) != NULL) ? (maskp)->bits : NULL > ^ > mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args' > nodemask_pr_args(&nodes)); > ^ >
On Fri, Nov 17, 2017 at 4:53 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Fri, 17 Nov 2017 09:44:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
>> >
>> > On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko <mhocko@kernel.org> wrote:
>> > > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
>> > >>
>> > >> After merging the akpm-current tree, today's linux-next build (powerpc
>> > >> ppc64_defconfig) produced this warning:
>> > >>
>> > >> In file included from include/linux/mmzone.h:17:0,
>> > >> from include/linux/mempolicy.h:10,
>> > >> from mm/mempolicy.c:70:
>> > >> mm/mempolicy.c: In function 'mpol_to_str':
>> > >> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always evaluate as 'true' [-Waddress]
>> > >> #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? (maskp)->bits : NULL
>> > >> ^
>> > >> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>> > >> nodemask_pr_args(&nodes));
>> > >> ^
>> > >
>> > > Hmm, this warning is quite surprising to me. Sure in this particular
>> > > case maskp will always be non-NULL so we always expand to
>> > > MAX_NUMNODES, maskp->bits
>> > > which is what we want. But we have other users which may be NULL. Does
>> > > anybody understan why this warns at all?
>> >
>> > As I understand it, the warning tries to address a common typo of accidentally
>> > testing the pointer to a stack object for being non-NULL, rather than the object
>> > pointed to for being non-zero.
>> >
>> > Adding an extra '!= NULL' comparison gets rid of the warning for me:
>> >
>> > #define nodemask_pr_args(maskp) \
>> > ((maskp) != NULL) ? MAX_NUMNODES : 0, \
>> > ((maskp) != NULL) ?(maskp)->bits : NULL
>> >
>> > Arnd
>>
>> This warning now exists in Linus' tree :-(
>
> Looking closer, it seems that the above workaround doesn't work for my
> compiler (gcc v5.2.0):
Right, I see now that all versions from gcc-4.6 to gcc-6 are affected
by this, while 4.5 and
earlier as well as 7 and 8 are not.
I'll try to come up with an alternative workaround, it will probably
be even uglier.
Arnd
Hi Andrew, After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: fs/super.c: In function 'sget_userns': fs/super.c:521:2: warning: ignoring return value of 'register_shrinker', declared with attribute warn_unused_result [-Wunused-result] register_shrinker(&s->s_shrink); ^ drivers/gpu/drm/ttm/ttm_page_alloc.c: In function 'ttm_pool_mm_shrink_init': drivers/gpu/drm/ttm/ttm_page_alloc.c:451:2: warning: ignoring return value of 'register_shrinker', declared with attribute warn_unused_result [-Wunused-result] register_shrinker(&manager->mm_shrink); ^ drivers/gpu/drm/ttm/ttm_page_alloc_dma.c: In function 'ttm_dma_pool_mm_shrink_init': drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:1185:2: warning: ignoring return value of 'register_shrinker', declared with attribute warn_unused_result [-Wunused-result] register_shrinker(&manager->mm_shrink); ^ Introduced by commit 488251e1e892 ("mm,vmscan: mark register_shrinker() as __must_check") Yes, I realise that it is meant to flush the users out ... -- Cheers, Stephen Rothwell
Hi Andrew, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: mm/khugepaged.c: In function 'khugepaged': mm/khugepaged.c:1757:31: warning: 'vma' may be used uninitialized in this function [-Wmaybe-uninitialized] if (khugepaged_test_exit(mm) || !vma) { ^ mm/khugepaged.c:1659:25: note: 'vma' was declared here struct vm_area_struct *vma; ^ Introduced by commit 0951b59acf3a ("mm: thp: use down_read_trylock() in khugepaged to avoid long block") -- Cheers, Stephen Rothwell
Hi Andrew, After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: WARNING: vmlinux: 'abort' exported twice. Previous export was in vmlinux WARNING: vmlinux: 'abort' exported twice. Previous export was in vmlinux Introduced by commit 3ff677e9abdf ("kernel/exit.c: export abort() to modules") EXPORT_SYMBOL(abort) already exists in arch/arc/kernel/traps.c arch/arm/kernel/traps.c arch/m32r/kernel/traps.c arch/unicore32/kernel/traps.c -- Cheers, Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 529 bytes --] Hi Andrew, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: mm/memcontrol.c: In function 'memory_events_show': mm/memcontrol.c:5453:23: warning: array subscript is above array bounds [-Warray-bounds] atomic_long_read(&memcg->memory_events[OOM_KILL])); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Introduced by commit 725844c87a0d ("mm: memcg: make sure memory.events is uptodate when waking pollers") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 650 bytes --] Hi Andrew, After merging the akpm-current tree, today's linux-next build (x86_64_allmodconfig) produced this warning: drivers/block/zram/zram_drv.c: In function 'read_block_state': drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 5 has type '__kernel_time_t {aka long int}' [-Wformat=] "%12lu %12llu.%06lu %c%c%c\n", ~~~~~^ %12lu (unsigned long)index, ts.tv_sec, ~~~~~~~~~ Introduced by commit 827c7dbda8eb ("zram-introduce-zram-memory-tracking-update-fix-fix") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On 05/03/2018 09:17 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build
> (x86_64_allmodconfig) produced this warning:
>
> drivers/block/zram/zram_drv.c: In function 'read_block_state':
> drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 5 has type '__kernel_time_t {aka long int}' [-Wformat=]
> "%12lu %12llu.%06lu %c%c%c\n",
> ~~~~~^
> %12lu
> (unsigned long)index, ts.tv_sec,
> ~~~~~~~~~
>
> Introduced by commit
>
> 827c7dbda8eb ("zram-introduce-zram-memory-tracking-update-fix-fix")
>
typedef __s64 time64_t;
struct timespec64 {
time64_t tv_sec; /* seconds */
long tv_nsec; /* nanoseconds */
};
time64_t is signed. Also, %lu on i386 et al is for 32-bit longs.
I guess that "we" will need to cast ts.tv_sec to (s64) and use %lld to print it
in order to satisfy other $arch.
Andrew, want to add a fix-fix-fix patch?
--
~Randy
On Fri, May 04, 2018 at 08:39:43AM -0700, Randy Dunlap wrote: > On 05/03/2018 09:17 PM, Stephen Rothwell wrote: > > Hi Andrew, > > > > After merging the akpm-current tree, today's linux-next build > > (x86_64_allmodconfig) produced this warning: > > > > drivers/block/zram/zram_drv.c: In function 'read_block_state': > > drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 5 has type '__kernel_time_t {aka long int}' [-Wformat=] > > "%12lu %12llu.%06lu %c%c%c\n", > > ~~~~~^ > > %12lu > > (unsigned long)index, ts.tv_sec, > > ~~~~~~~~~ > > > > Introduced by commit > > > > 827c7dbda8eb ("zram-introduce-zram-memory-tracking-update-fix-fix") > > > > typedef __s64 time64_t; > > struct timespec64 { > time64_t tv_sec; /* seconds */ > long tv_nsec; /* nanoseconds */ > }; > > time64_t is signed. Also, %lu on i386 et al is for 32-bit longs. > I guess that "we" will need to cast ts.tv_sec to (s64) and use %lld to print it > in order to satisfy other $arch. > > Andrew, want to add a fix-fix-fix patch? Thanks for the fix during I am absent, Andrew and Randy. Here goes fix. Andrew please fold this patchset. >From 16569c7abb641930b4e4ec66b4dc2005e6c87be8 Mon Sep 17 00:00:00 2001 From: Minchan Kim <minchan@kernel.org> Date: Mon, 7 May 2018 23:00:16 +0900 Subject: [PATCH] zram-introduce-zram-memory-tracking-update-fix-fix-fix fix compile warning drivers/block/zram/zram_drv.c: In function 'read_block_state': drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 5 has type '__kernel_time_t {aka long int}' [-Wformat=] "%12lu %12llu.%06lu %c%c%c\n", ~~~~~^ %12lu (unsigned long)index, ts.tv_sec, ~~~~~~~~~ Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Minchan Kim <minchan@kernel.org> --- drivers/block/zram/zram_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index f2f3104b2b48..635307e3238b 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -671,8 +671,8 @@ static ssize_t read_block_state(struct file *file, char __user *buf, ts = ktime_to_timespec64(zram->table[index].ac_time); copied = snprintf(kbuf + written, count, - "%12lu %12llu.%06lu %c%c%c\n", - (unsigned long)index, ts.tv_sec, + "%12lu %12lld.%06ld %c%c%c\n", + (unsigned long)index, (s64)ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC, zram_test_flag(zram, index, ZRAM_SAME) ? 's' : '.', zram_test_flag(zram, index, ZRAM_WB) ? 'w' : '.', -- 2.17.0.441.gb46fe60e1d-goog
On 05/07/2018 07:10 AM, Minchan Kim wrote:
> On Fri, May 04, 2018 at 08:39:43AM -0700, Randy Dunlap wrote:
>> On 05/03/2018 09:17 PM, Stephen Rothwell wrote:
>>> Hi Andrew,
>>>
>>> After merging the akpm-current tree, today's linux-next build
>>> (x86_64_allmodconfig) produced this warning:
>>>
>>> drivers/block/zram/zram_drv.c: In function 'read_block_state':
>>> drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 5 has type '__kernel_time_t {aka long int}' [-Wformat=]
>>> "%12lu %12llu.%06lu %c%c%c\n",
>>> ~~~~~^
>>> %12lu
>>> (unsigned long)index, ts.tv_sec,
>>> ~~~~~~~~~
>>>
>>> Introduced by commit
>>>
>>> 827c7dbda8eb ("zram-introduce-zram-memory-tracking-update-fix-fix")
>>>
>>
>> typedef __s64 time64_t;
>>
>> struct timespec64 {
>> time64_t tv_sec; /* seconds */
>> long tv_nsec; /* nanoseconds */
>> };
>>
>> time64_t is signed. Also, %lu on i386 et al is for 32-bit longs.
>> I guess that "we" will need to cast ts.tv_sec to (s64) and use %lld to print it
>> in order to satisfy other $arch.
>>
>> Andrew, want to add a fix-fix-fix patch?
>
> Thanks for the fix during I am absent, Andrew and Randy.
> Here goes fix.
> Andrew please fold this patchset.
>
> From 16569c7abb641930b4e4ec66b4dc2005e6c87be8 Mon Sep 17 00:00:00 2001
> From: Minchan Kim <minchan@kernel.org>
> Date: Mon, 7 May 2018 23:00:16 +0900
> Subject: [PATCH] zram-introduce-zram-memory-tracking-update-fix-fix-fix
>
> fix compile warning
>
> drivers/block/zram/zram_drv.c: In function 'read_block_state':
> drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 5 has type '__kernel_time_t {aka long int}' [-Wformat=]
> "%12lu %12llu.%06lu %c%c%c\n",
> ~~~~~^
> %12lu
> (unsigned long)index, ts.tv_sec,
> ~~~~~~~~~
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Minchan Kim <minchan@kernel.org>
> ---
> drivers/block/zram/zram_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index f2f3104b2b48..635307e3238b 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -671,8 +671,8 @@ static ssize_t read_block_state(struct file *file, char __user *buf,
>
> ts = ktime_to_timespec64(zram->table[index].ac_time);
> copied = snprintf(kbuf + written, count,
> - "%12lu %12llu.%06lu %c%c%c\n",
> - (unsigned long)index, ts.tv_sec,
> + "%12lu %12lld.%06ld %c%c%c\n",
> + (unsigned long)index, (s64)ts.tv_sec,
> ts.tv_nsec / NSEC_PER_USEC,
> zram_test_flag(zram, index, ZRAM_SAME) ? 's' : '.',
> zram_test_flag(zram, index, ZRAM_WB) ? 'w' : '.',
>
ssize_t index,
so why not print it with %zd (or %12zd) and skip the cast?
--
~Randy
On Mon, May 07, 2018 at 09:47:54AM -0700, Randy Dunlap wrote: > On 05/07/2018 07:10 AM, Minchan Kim wrote: > > On Fri, May 04, 2018 at 08:39:43AM -0700, Randy Dunlap wrote: > >> On 05/03/2018 09:17 PM, Stephen Rothwell wrote: > >>> Hi Andrew, > >>> > >>> After merging the akpm-current tree, today's linux-next build > >>> (x86_64_allmodconfig) produced this warning: > >>> > >>> drivers/block/zram/zram_drv.c: In function 'read_block_state': > >>> drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 5 has type '__kernel_time_t {aka long int}' [-Wformat=] > >>> "%12lu %12llu.%06lu %c%c%c\n", > >>> ~~~~~^ > >>> %12lu > >>> (unsigned long)index, ts.tv_sec, > >>> ~~~~~~~~~ > >>> > >>> Introduced by commit > >>> > >>> 827c7dbda8eb ("zram-introduce-zram-memory-tracking-update-fix-fix") > >>> > >> > >> typedef __s64 time64_t; > >> > >> struct timespec64 { > >> time64_t tv_sec; /* seconds */ > >> long tv_nsec; /* nanoseconds */ > >> }; > >> > >> time64_t is signed. Also, %lu on i386 et al is for 32-bit longs. > >> I guess that "we" will need to cast ts.tv_sec to (s64) and use %lld to print it > >> in order to satisfy other $arch. > >> > >> Andrew, want to add a fix-fix-fix patch? > > > > Thanks for the fix during I am absent, Andrew and Randy. > > Here goes fix. > > Andrew please fold this patchset. > > > > From 16569c7abb641930b4e4ec66b4dc2005e6c87be8 Mon Sep 17 00:00:00 2001 > > From: Minchan Kim <minchan@kernel.org> > > Date: Mon, 7 May 2018 23:00:16 +0900 > > Subject: [PATCH] zram-introduce-zram-memory-tracking-update-fix-fix-fix > > > > fix compile warning > > > > drivers/block/zram/zram_drv.c: In function 'read_block_state': > > drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 5 has type '__kernel_time_t {aka long int}' [-Wformat=] > > "%12lu %12llu.%06lu %c%c%c\n", > > ~~~~~^ > > %12lu > > (unsigned long)index, ts.tv_sec, > > ~~~~~~~~~ > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Cc: Randy Dunlap <rdunlap@infradead.org> > > Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> > > Cc: Andrew Morton <akpm@linux-foundation.org> > > Cc: Stephen Rothwell <sfr@canb.auug.org.au> > > Signed-off-by: Minchan Kim <minchan@kernel.org> > > --- > > drivers/block/zram/zram_drv.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c > > index f2f3104b2b48..635307e3238b 100644 > > --- a/drivers/block/zram/zram_drv.c > > +++ b/drivers/block/zram/zram_drv.c > > @@ -671,8 +671,8 @@ static ssize_t read_block_state(struct file *file, char __user *buf, > > > > ts = ktime_to_timespec64(zram->table[index].ac_time); > > copied = snprintf(kbuf + written, count, > > - "%12lu %12llu.%06lu %c%c%c\n", > > - (unsigned long)index, ts.tv_sec, > > + "%12lu %12lld.%06ld %c%c%c\n", > > + (unsigned long)index, (s64)ts.tv_sec, > > ts.tv_nsec / NSEC_PER_USEC, > > zram_test_flag(zram, index, ZRAM_SAME) ? 's' : '.', > > zram_test_flag(zram, index, ZRAM_WB) ? 'w' : '.', > > > > ssize_t index, > > so why not print it with %zd (or %12zd) and skip the cast? Thanks for the suggestion. Resend. Andrew, Could you pick up this? >From 8af033804a8a7a0538629545957728c48d14d261 Mon Sep 17 00:00:00 2001 From: Minchan Kim <minchan@kernel.org> Date: Mon, 7 May 2018 23:00:16 +0900 Subject: [PATCH] zram-introduce-zram-memory-tracking-update-fix-fix-fix fix compile warning and use zd for ssize_t by Randy's suggestion. drivers/block/zram/zram_drv.c: In function 'read_block_state': drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 5 has type '__kernel_time_t {aka long int}' [-Wformat=] "%12lu %12llu.%06lu %c%c%c\n", ~~~~~^ %12lu (unsigned long)index, ts.tv_sec, ~~~~~~~~~ Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Minchan Kim <minchan@kernel.org> --- drivers/block/zram/zram_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index f2f3104b2b48..ceadcd1245b3 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -671,8 +671,8 @@ static ssize_t read_block_state(struct file *file, char __user *buf, ts = ktime_to_timespec64(zram->table[index].ac_time); copied = snprintf(kbuf + written, count, - "%12lu %12llu.%06lu %c%c%c\n", - (unsigned long)index, ts.tv_sec, + "%12zd %12lld.%06ld %c%c%c\n", + index, (s64)ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC, zram_test_flag(zram, index, ZRAM_SAME) ? 's' : '.', zram_test_flag(zram, index, ZRAM_WB) ? 'w' : '.', -- 2.17.0.441.gb46fe60e1d-goog
[-- Attachment #1: Type: text/plain, Size: 730 bytes --] Hi Andrew, After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: In file included from fs/fat/inode.c:24:0: fs/fat/inode.c: In function '__fat_get_block': fs/fat/inode.c:163:9: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'sector_t {aka long long unsigned int}' [-Wformat=] "invalid FAT chain (i_pos %lld, last_block %ld)", ^ fs/fat/fat.h:397:24: note: in definition of macro 'fat_fs_error' __fat_fs_error(sb, 1, fmt , ## args) ^~~ Introduced by commit 3bdac70a1921 ("fat: use fat_fs_error() instead of BUG_ON() in __fat_get_block()") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2278 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: In file included from arch/x86/include/asm/percpu.h:45, from arch/x86/include/asm/current.h:6, from include/linux/sched.h:12, from include/linux/uaccess.h:5, from fs/proc/base.c:51: fs/proc/base.c: In function 'proc_smack_attr_dir_lookup': include/linux/kernel.h:73:25: warning: passing argument 4 of 'proc_pident_lookup' makes pointer from integer without a cast [-Wint-conversion] #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ fs/proc/base.c:2602:7: note: in expansion of macro 'ARRAY_SIZE' ARRAY_SIZE(LSM##_attr_dir_stuff)); \ ^~~~~~~~~~ fs/proc/base.c:2615:1: note: in expansion of macro 'LSM_DIR_OPS' LSM_DIR_OPS(smack); ^~~~~~~~~~~ fs/proc/base.c:2454:31: note: expected 'const struct pid_entry *' but argument is of type 'long unsigned int' const struct pid_entry *end) ~~~~~~~~~~~~~~~~~~~~~~~~^~~ Introduced by commit f6e3521a4c5b ("proc: calculate end pointer for /proc/*/* lookup at compile time") interacting with commit 6d9c939dbe4d ("procfs: add smack subdir to attrs") from the security tree. I have applied the following merge fix patch From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 31 Jan 2019 15:56:56 +1100 Subject: [PATCH] proc: merge fix for proc_pident_lookup() API change Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- fs/proc/base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc/base.c b/fs/proc/base.c index 4ac7f32c1929..3daca4367d29 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -2599,7 +2599,7 @@ static struct dentry *proc_##LSM##_attr_dir_lookup(struct inode *dir, \ { \ return proc_pident_lookup(dir, dentry, \ LSM##_attr_dir_stuff, \ - ARRAY_SIZE(LSM##_attr_dir_stuff)); \ + LSM##_attr_dir_stuff + ARRAY_SIZE(LSM##_attr_dir_stuff)); \ } \ \ static const struct inode_operations proc_##LSM##_attr_dir_inode_ops = { \ -- 2.20.1 --- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 438 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: lib/list_sort.c:17:36: warning: 'pure' attribute ignored [-Wattributes] struct list_head const *, struct list_head const *); ^~~~~~~~~ Introduced by commit 820c81be5237 ("lib/list_sort: simplify and remove MAX_LIST_LENGTH_BITS") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 583 bytes --] Hi all, On Fri, 29 Mar 2019 13:39:14 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the akpm-current tree, today's linux-next build (arm > multi_v7_defconfig) produced this warning: > > lib/list_sort.c:17:36: warning: 'pure' attribute ignored [-Wattributes] > struct list_head const *, struct list_head const *); > ^~~~~~~~~ > > Introduced by commit > > 820c81be5237 ("lib/list_sort: simplify and remove MAX_LIST_LENGTH_BITS") I am still getting that warning :-( -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, 16 Apr 2019 16:52:56 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Fri, 29 Mar 2019 13:39:14 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the akpm-current tree, today's linux-next build (arm
> > multi_v7_defconfig) produced this warning:
> >
> > lib/list_sort.c:17:36: warning: 'pure' attribute ignored [-Wattributes]
> > struct list_head const *, struct list_head const *);
> > ^~~~~~~~~
> >
> > Introduced by commit
> >
> > 820c81be5237 ("lib/list_sort: simplify and remove MAX_LIST_LENGTH_BITS")
>
> I am still getting that warning :-(
Me too and I can't figure it out.
Shrug, I guess we take a pass on it until someone has time/inclination
to revisit it.
--- a/lib/list_sort.c~lib-list_sort-simplify-and-remove-max_list_length_bits-fix
+++ a/lib/list_sort.c
@@ -7,13 +7,7 @@
#include <linux/list_sort.h>
#include <linux/list.h>
-/*
- * By declaring the compare function with the __pure attribute, we give
- * the compiler more opportunity to optimize. Ideally, we'd use this in
- * the prototype of list_sort(), but that would involve a lot of churn
- * at all call sites, so just cast the function pointer passed in.
- */
-typedef int __pure __attribute__((nonnull(2,3))) (*cmp_func)(void *,
+typedef int __attribute__((nonnull(2,3))) (*cmp_func)(void *,
struct list_head const *, struct list_head const *);
/*
_
[-- Attachment #1: Type: text/plain, Size: 493 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: net/tipc/sysctl.c:42:12: warning: 'one' defined but not used [-Wunused-variable] static int one = 1; ^~~ net/tipc/sysctl.c:41:12: warning: 'zero' defined but not used [-Wunused-variable] static int zero; ^~~~ Introduced by commit 6a33853c5773 ("proc/sysctl: add shared variables for range check") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Thu, May 30, 2019 at 6:55 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> net/tipc/sysctl.c:42:12: warning: 'one' defined but not used [-Wunused-variable]
> static int one = 1;
> ^~~
> net/tipc/sysctl.c:41:12: warning: 'zero' defined but not used [-Wunused-variable]
> static int zero;
> ^~~~
>
> Introduced by commit
>
> 6a33853c5773 ("proc/sysctl: add shared variables for range check")
>
> --
> Cheers,
> Stephen Rothwell
Hi,
this is due the merge of:
commit 4bcd4ec1017205644a2697bccbc3b5143f522f5f
Author: Jie Liu <liujie165@huawei.com>
Date: Tue Apr 16 13:10:09 2019 +0800
tipc: set sysctl_tipc_rmem and named_timeout right range
I'm making a patch to suppress the warning.
Regards,
--
Matteo Croce
per aspera ad upstream
[-- Attachment #1: Type: text/plain, Size: 437 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: lib/rbtree_test.c: In function 'check_augmented': lib/rbtree_test.c:220:18: warning: unused variable 'rb' [-Wunused-variable] struct rb_node *rb; ^~ Introduced by commit 33a64f781816 ("augmented-rbtree-add-new-rb_declare_callbacks_max-macro-fix-2") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 475 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/infiniband/sw/siw/siw_mem.c: In function 'siw_free_plist': drivers/infiniband/sw/siw/siw_mem.c:66:16: warning: unused variable 'p' [-Wunused-variable] struct page **p = chunk->plist; ^ Introduced by commit 63630f9a8d72 ("mm/gup: add make_dirty arg to put_user_pages_dirty_lock()") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 499 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: mm/memcontrol.c: In function 'invalidate_reclaim_iterators': mm/memcontrol.c:1160:11: warning: suggest parentheses around assignment used as truth value [-Wparentheses] } while (memcg = parent_mem_cgroup(memcg)); ^~~~~ Introduced by commit c48a2f5ce935 ("mm/memcontrol.c: fix use after free in mem_cgroup_iter()") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 485 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: fs/ocfs2/xattr.c:1493:13: warning: 'ocfs2_xa_add_entry' defined but not used [-Wunused-function] static void ocfs2_xa_add_entry(struct ocfs2_xa_loc *loc, u32 name_hash) ^~~~~~~~~~~~~~~~~~ Introduced by commit 45d9aa3d263d ("fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Wed, 2019-07-31 at 16:11 +1000, Stephen Rothwell wrote: > Hi all, > > After merging the akpm-current tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > mm/memcontrol.c: In function 'invalidate_reclaim_iterators': > mm/memcontrol.c:1160:11: warning: suggest parentheses around assignment used as truth value [-Wparentheses] > } while (memcg = parent_mem_cgroup(memcg)); > ^~~~~ > Hi Stephen, Thanks for the telling me this. Sorry for the build warning. Should I send patch v5 to the mailing list to fix this? Miles > Introduced by commit > > c48a2f5ce935 ("mm/memcontrol.c: fix use after free in mem_cgroup_iter()") >
On 2019/7/31 14:16, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> fs/ocfs2/xattr.c:1493:13: warning: 'ocfs2_xa_add_entry' defined but not used [-Wunused-function]
> static void ocfs2_xa_add_entry(struct ocfs2_xa_loc *loc, u32 name_hash)
> ^~~~~~~~~~~~~~~~~~
>
> Introduced by commit
>
> 45d9aa3d263d ("fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()")
>
I look at the code again.
The function ocfs2_xa_add_entry() is never called when using this patch.
Thus, I think the definition of ocfs2_xa_add_entry() could be removed.
If it is okay, I can send a new patch (v3).
Best wishes,
Jia-Ju Bai
[-- Attachment #1: Type: text/plain, Size: 934 bytes --] Hi Miles, On Wed, 31 Jul 2019 14:28:04 +0800 Miles Chen <miles.chen@mediatek.com> wrote: > > On Wed, 2019-07-31 at 16:11 +1000, Stephen Rothwell wrote: > > > > After merging the akpm-current tree, today's linux-next build (powerpc > > ppc64_defconfig) produced this warning: > > > > mm/memcontrol.c: In function 'invalidate_reclaim_iterators': > > mm/memcontrol.c:1160:11: warning: suggest parentheses around assignment used as truth value [-Wparentheses] > > } while (memcg = parent_mem_cgroup(memcg)); > > ^~~~~ > > > > Hi Stephen, > > Thanks for the telling me this. Sorry for the build warning. > Should I send patch v5 to the mailing list to fix this? You might as well (cc'ing Andrew, of course). I would suggest finishing that loop like this: memcg = parent_mem_cgroup(memcg); } while (memcg); rather than adding a set of parentheses. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Thu 01-08-19 15:51:30, Stephen Rothwell wrote: > Hi Miles, > > On Wed, 31 Jul 2019 14:28:04 +0800 Miles Chen <miles.chen@mediatek.com> wrote: > > > > On Wed, 2019-07-31 at 16:11 +1000, Stephen Rothwell wrote: > > > > > > After merging the akpm-current tree, today's linux-next build (powerpc > > > ppc64_defconfig) produced this warning: > > > > > > mm/memcontrol.c: In function 'invalidate_reclaim_iterators': > > > mm/memcontrol.c:1160:11: warning: suggest parentheses around assignment used as truth value [-Wparentheses] > > > } while (memcg = parent_mem_cgroup(memcg)); > > > ^~~~~ > > > > > > > Hi Stephen, > > > > Thanks for the telling me this. Sorry for the build warning. > > Should I send patch v5 to the mailing list to fix this? > > You might as well (cc'ing Andrew, of course). > > I would suggest finishing that loop like this: > > memcg = parent_mem_cgroup(memcg); > } while (memcg); > > rather than adding a set of parentheses. Qian has already posted a patch http://lkml.kernel.org/r/1564580753-17531-1-git-send-email-cai@lca.pw -- Michal Hocko SUSE Labs
On Thu, 2019-08-01 at 08:15 +0200, Michal Hocko wrote: > On Thu 01-08-19 15:51:30, Stephen Rothwell wrote: > > Hi Miles, > > > > On Wed, 31 Jul 2019 14:28:04 +0800 Miles Chen <miles.chen@mediatek.com> wrote: > > > > > > On Wed, 2019-07-31 at 16:11 +1000, Stephen Rothwell wrote: > > > > > > > > After merging the akpm-current tree, today's linux-next build (powerpc > > > > ppc64_defconfig) produced this warning: > > > > > > > > mm/memcontrol.c: In function 'invalidate_reclaim_iterators': > > > > mm/memcontrol.c:1160:11: warning: suggest parentheses around assignment used as truth value [-Wparentheses] > > > > } while (memcg = parent_mem_cgroup(memcg)); > > > > ^~~~~ > > > > > > > > > > Hi Stephen, > > > > > > Thanks for the telling me this. Sorry for the build warning. > > > Should I send patch v5 to the mailing list to fix this? > > > > You might as well (cc'ing Andrew, of course). > > > > I would suggest finishing that loop like this: > > > > memcg = parent_mem_cgroup(memcg); > > } while (memcg); > > > > rather than adding a set of parentheses. thanks for the advise > > Qian has already posted a patch http://lkml.kernel.org/r/1564580753-17531-1-git-send-email-cai@lca.pw Thanks Qian's quick fix. It's the first time that I receive a build warning after the patch has been merged to -mm tree. The build warning had been fixed by Qian, should I send another change for this?
On Thu 01-08-19 14:30:03, Miles Chen wrote:
[...]
> It's the first time that I receive a build warning after the patch has
> been merged to -mm tree. The build warning had been fixed by Qian,
> should I send another change for this?
No need. Andrew has already picked up the fix for mmotm tree and it
should show up in linux-next soon.
Thanks!
--
Michal Hocko
SUSE Labs
[-- Attachment #1: Type: text/plain, Size: 336 bytes --] Hi Miles, On Thu, 1 Aug 2019 14:30:03 +0800 Miles Chen <miles.chen@mediatek.com> wrote: > > It's the first time that I receive a build warning after the patch has > been merged to -mm tree. The build warning had been fixed by Qian, > should I send another change for this? No, that will do. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Thu, 2019-08-01 at 16:39 +1000, Stephen Rothwell wrote:
> Hi Miles,
>
> On Thu, 1 Aug 2019 14:30:03 +0800 Miles Chen <miles.chen@mediatek.com> wrote:
> >
> > It's the first time that I receive a build warning after the patch has
> > been merged to -mm tree. The build warning had been fixed by Qian,
> > should I send another change for this?
>
> No, that will do.
got it. thanks
[-- Attachment #1: Type: text/plain, Size: 726 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/linux/bits.h:22, from arch/x86/include/asm/msr-index.h:5, from arch/x86/boot/cpucheck.c:28: include/linux/build_bug.h:49: warning: "BUILD_BUG_ON" redefined #define BUILD_BUG_ON(condition) \ In file included from arch/x86/boot/cpucheck.c:22: arch/x86/boot/boot.h:31: note: this is the location of the previous definition #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)])) Caused by commit d72f2a993607 ("linux/bits.h: add compile time sanity check of GENMASK inputs") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi Stephen, Andrew
On Wed, Aug 07, 2019 at 06:00:41PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/bits.h:22,
> from arch/x86/include/asm/msr-index.h:5,
> from arch/x86/boot/cpucheck.c:28:
> include/linux/build_bug.h:49: warning: "BUILD_BUG_ON" redefined
> #define BUILD_BUG_ON(condition) \
>
> In file included from arch/x86/boot/cpucheck.c:22:
> arch/x86/boot/boot.h:31: note: this is the location of the previous definition
> #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
>
> Caused by commit
>
> d72f2a993607 ("linux/bits.h: add compile time sanity check of GENMASK inputs")
>
> --
> Cheers,
> Stephen Rothwell
Please drop this patch, it has additional issues that needs to be fixed
in another revision.
Rikard
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --] Hi Rikard, On Wed, 7 Aug 2019 13:29:17 +0200 Rikard Falkeborn <rikard.falkeborn@gmail.com> wrote: > > Hi Stephen, Andrew > > On Wed, Aug 07, 2019 at 06:00:41PM +1000, Stephen Rothwell wrote: > > Hi all, > > > > After merging the akpm-current tree, today's linux-next build (x86_64 > > allmodconfig) failed like this: > > > > In file included from include/linux/bits.h:22, > > from arch/x86/include/asm/msr-index.h:5, > > from arch/x86/boot/cpucheck.c:28: > > include/linux/build_bug.h:49: warning: "BUILD_BUG_ON" redefined > > #define BUILD_BUG_ON(condition) \ > > > > In file included from arch/x86/boot/cpucheck.c:22: > > arch/x86/boot/boot.h:31: note: this is the location of the previous definition > > #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)])) > > > > Caused by commit > > > > d72f2a993607 ("linux/bits.h: add compile time sanity check of GENMASK inputs") > > > > -- > > Cheers, > > Stephen Rothwell > > Please drop this patch, it has additional issues that needs to be fixed > in another revision. I have removed it from linux-next for today. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 492 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: lib/vsprintf.c: In function 'ptr_to_hashval': lib/vsprintf.c:766:14: warning: unused variable 'str' [-Wunused-variable] 766 | const char *str = sizeof(ptr) == 8 ? "(____ptrval____)" : "(ptrval)"; | ^~~ Introduced by commit aea87b9b95b9 ("rss_stat: add support to detect RSS updates of external mm") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 604 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: lib/cpumask.c: In function 'cpumask_local_spread': lib/cpumask.c:302:1: warning: the frame size of 5472 bytes is larger than 2048 bytes [-Wframe-larger-than=] 302 | } | ^ Introduced by commit 3d591f2836cf ("lib: optimize cpumask_local_spread()") MAX_NUMNODES == (1 << NODES_SHIFT) and NODES_SHIFT == CONFIG_NODES_SHIFT== 10, so MAX_NUMNODES == 1024 and there is an int array and a bool array of that size declared here :-( -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi Stephen, On 2019/11/6 15:05, Stephen Rothwell wrote: > Hi all, > > After merging the akpm-current tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > lib/cpumask.c: In function 'cpumask_local_spread': > lib/cpumask.c:302:1: warning: the frame size of 5472 bytes is larger than 2048 bytes [-Wframe-larger-than=] > 302 | } > | ^ > > Introduced by commit > > 3d591f2836cf ("lib: optimize cpumask_local_spread()") > > MAX_NUMNODES == (1 << NODES_SHIFT) and NODES_SHIFT == CONFIG_NODES_SHIFT== 10, > so MAX_NUMNODES == 1024 and there is an int array and a bool array of that > size declared here :-( Thanks for the report and sorry for the warning, Michal has pointed this[1]. We are preparing the new solution and will post it soon. [1] https://lkml.org/lkml/2019/11/5/66 Thanks, Shaokun >
[-- Attachment #1: Type: text/plain, Size: 1320 bytes --] Hi all, [Also earlier reported by Randy Dunlap] After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: In file included from mm/migrate.c:39: include/linux/hugetlb_cgroup.h:146:21: warning: 'struct file_region' declared inside parameter list will not be visible outside of this definition or declaration 146 | struct file_region *rg, | ^~~~~~~~~~~ include/linux/hugetlb_cgroup.h:145:63: warning: 'struct resv_map' declared inside parameter list will not be visible outside of this definition or declaration 145 | static inline void hugetlb_cgroup_uncharge_file_region(struct resv_map *resv, | ^~~~~~~~ include/linux/hugetlb_cgroup.h:233:59: warning: 'struct resv_map' declared inside parameter list will not be visible outside of this definition or declaration 233 | static inline void hugetlb_cgroup_uncharge_counter(struct resv_map *resv, | ^~~~~~~~ Introduced by commits 0b42cb2e47b6 ("hugetlb_cgroup: add reservation accounting for private mappings") 881818698361 ("hugetlb_cgroup: add accounting for shared mappings") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1514 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: mm/kasan/common.o: warning: objtool: kasan_report()+0x17: call to report_enabled() with UACCESS enabled In file included from include/linux/bitmap.h:9, from include/linux/cpumask.h:12, from arch/x86/include/asm/paravirt.h:17, from arch/x86/include/asm/irqflags.h:72, from include/linux/irqflags.h:16, from include/linux/rcupdate.h:26, from include/linux/rculist.h:11, from include/linux/pid.h:5, from include/linux/sched.h:14, from include/linux/uaccess.h:6, from arch/x86/include/asm/fpu/xstate.h:5, from arch/x86/include/asm/pgtable.h:26, from include/linux/kasan.h:15, from lib/test_kasan.c:12: In function 'memmove', inlined from 'kmalloc_memmove_invalid_size' at lib/test_kasan.c:301:2: include/linux/string.h:441:9: warning: '__builtin_memmove' specified bound 18446744073709551614 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=] 441 | return __builtin_memmove(p, q, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Introduced by commit 519e500fac64 ("kasan: add test for invalid size in memmove") That's a bit annoying during a normal x86_64 allmodconfig build ... -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Thu, Mar 5, 2020 at 6:37 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the akpm-current tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > mm/kasan/common.o: warning: objtool: kasan_report()+0x17: call to report_enabled() with UACCESS enabled > In file included from include/linux/bitmap.h:9, > from include/linux/cpumask.h:12, > from arch/x86/include/asm/paravirt.h:17, > from arch/x86/include/asm/irqflags.h:72, > from include/linux/irqflags.h:16, > from include/linux/rcupdate.h:26, > from include/linux/rculist.h:11, > from include/linux/pid.h:5, > from include/linux/sched.h:14, > from include/linux/uaccess.h:6, > from arch/x86/include/asm/fpu/xstate.h:5, > from arch/x86/include/asm/pgtable.h:26, > from include/linux/kasan.h:15, > from lib/test_kasan.c:12: > In function 'memmove', > inlined from 'kmalloc_memmove_invalid_size' at lib/test_kasan.c:301:2: > include/linux/string.h:441:9: warning: '__builtin_memmove' specified bound 18446744073709551614 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=] +kasan-dev We probably need to make this 18446744073709551614 constant "dynamic" so that compiler does not see it. Walter, will you take a look? Thanks > 441 | return __builtin_memmove(p, q, size); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Introduced by commit > > 519e500fac64 ("kasan: add test for invalid size in memmove") > > That's a bit annoying during a normal x86_64 allmodconfig build ... > > -- > Cheers, > Stephen Rothwell
On Thu, 2020-03-05 at 16:37 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> mm/kasan/common.o: warning: objtool: kasan_report()+0x17: call to report_enabled() with UACCESS enabled
> In file included from include/linux/bitmap.h:9,
> from include/linux/cpumask.h:12,
> from arch/x86/include/asm/paravirt.h:17,
> from arch/x86/include/asm/irqflags.h:72,
> from include/linux/irqflags.h:16,
> from include/linux/rcupdate.h:26,
> from include/linux/rculist.h:11,
> from include/linux/pid.h:5,
> from include/linux/sched.h:14,
> from include/linux/uaccess.h:6,
> from arch/x86/include/asm/fpu/xstate.h:5,
> from arch/x86/include/asm/pgtable.h:26,
> from include/linux/kasan.h:15,
> from lib/test_kasan.c:12:
> In function 'memmove',
> inlined from 'kmalloc_memmove_invalid_size' at lib/test_kasan.c:301:2:
> include/linux/string.h:441:9: warning: '__builtin_memmove' specified bound 18446744073709551614 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
> 441 | return __builtin_memmove(p, q, size);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Introduced by commit
>
> 519e500fac64 ("kasan: add test for invalid size in memmove")
>
> That's a bit annoying during a normal x86_64 allmodconfig build ...
>
Hi Stephen and Dmitry,
I'm sorry for the build warning, it doesn't generate in our local
environment(arm64/x86_64). Would you tell me what toolchains can
reproduce it?
Dmitry, Thanks for your suggestion.
Thanks
Walter
[-- Attachment #1: Type: text/plain, Size: 462 bytes --] Hi Walter, On Thu, 5 Mar 2020 16:54:36 +0800 Walter Wu <walter-zh.wu@mediatek.com> wrote: > > I'm sorry for the build warning, it doesn't generate in our local > environment(arm64/x86_64). Would you tell me what toolchains can > reproduce it? I am using a PowerPC LE hosted x86_64 gcc v9.2.1 (Debian cross compiler). $ /usr/bin/x86_64-linux-gnu-gcc --version x86_64-linux-gnu-gcc (Debian 9.2.1-21) 9.2.1 20191130 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Thu, 2020-03-05 at 20:33 +1100, Stephen Rothwell wrote:
> Hi Walter,
>
> On Thu, 5 Mar 2020 16:54:36 +0800 Walter Wu <walter-zh.wu@mediatek.com> wrote:
> >
> > I'm sorry for the build warning, it doesn't generate in our local
> > environment(arm64/x86_64). Would you tell me what toolchains can
> > reproduce it?
>
> I am using a PowerPC LE hosted x86_64 gcc v9.2.1 (Debian cross compiler).
>
> $ /usr/bin/x86_64-linux-gnu-gcc --version
> x86_64-linux-gnu-gcc (Debian 9.2.1-21) 9.2.1 20191130
>
Hi Stephen,
Thanks for your information, It doesn't generate warning message in
gcc-8.3.0(Debian 8.3.0-6) after apply below patch.
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -286,17 +286,19 @@ static noinline void __init
kmalloc_oob_in_memset(void)
static noinline void __init kmalloc_memmove_invalid_size(void)
{
char *ptr;
- size_t size = 64;
+ size_t size1 = 64;
+ size_t size2 = 62;
pr_info("invalid size in memmove\n");
- ptr = kmalloc(size, GFP_KERNEL);
+ ptr = kmalloc(size1, GFP_KERNEL);
if (!ptr) {
pr_err("Allocation failed\n");
return;
}
- memset((char *)ptr, 0, 64);
- memmove((char *)ptr, (char *)ptr + 4, -2);
+ memset((char *)ptr, 0, size1);
+ /* the size of memmove() is negative numbers */
+ memmove((char *)ptr, (char *)ptr + 4, size2 - size1);
kfree(ptr);
}
On Sat, 2020-03-07 at 02:59 +0800, Walter Wu wrote:
> On Thu, 2020-03-05 at 20:33 +1100, Stephen Rothwell wrote:
> > Hi Walter,
> >
> > On Thu, 5 Mar 2020 16:54:36 +0800 Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > >
> > > I'm sorry for the build warning, it doesn't generate in our local
> > > environment(arm64/x86_64). Would you tell me what toolchains can
> > > reproduce it?
> >
> > I am using a PowerPC LE hosted x86_64 gcc v9.2.1 (Debian cross compiler).
> >
> > $ /usr/bin/x86_64-linux-gnu-gcc --version
> > x86_64-linux-gnu-gcc (Debian 9.2.1-21) 9.2.1 20191130
> >
> Hi Stephen,
>
> Thanks for your information, It doesn't generate warning message in
> gcc-8.3.0(Debian 8.3.0-6) after apply below patch.
>
>
> --- a/lib/test_kasan.c
> +++ b/lib/test_kasan.c
> @@ -286,17 +286,19 @@ static noinline void __init
> kmalloc_oob_in_memset(void)
> static noinline void __init kmalloc_memmove_invalid_size(void)
> {
> char *ptr;
> - size_t size = 64;
> + size_t size1 = 64;
> + size_t size2 = 62;
>
> pr_info("invalid size in memmove\n");
> - ptr = kmalloc(size, GFP_KERNEL);
> + ptr = kmalloc(size1, GFP_KERNEL);
> if (!ptr) {
> pr_err("Allocation failed\n");
> return;
> }
>
> - memset((char *)ptr, 0, 64);
> - memmove((char *)ptr, (char *)ptr + 4, -2);
> + memset((char *)ptr, 0, size1);
> + /* the size of memmove() is negative numbers */
> + memmove((char *)ptr, (char *)ptr + 4, size2 - size1);
> kfree(ptr);
> }
>
Hi Stephen,
Please ignore previous mail, I miss the message. Below the patch will
fix the warning.
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -286,17 +286,19 @@ static noinline void __init
kmalloc_oob_in_memset(void)
static noinline void __init kmalloc_memmove_invalid_size(void)
{
char *ptr;
- size_t size = 64;
+ size_t size1 = 64;
+ volatile size_t size2 = -2;
pr_info("invalid size in memmove\n");
- ptr = kmalloc(size, GFP_KERNEL);
+ ptr = kmalloc(size1, GFP_KERNEL);
if (!ptr) {
pr_err("Allocation failed\n");
return;
}
- memset((char *)ptr, 0, 64);
- memmove((char *)ptr, (char *)ptr + 4, -2);
+ memset((char *)ptr, 0, size1);
+ /* the size of memmove() is negative number */
+ memmove((char *)ptr, (char *)ptr + 4, size2);
kfree(ptr);
}
On Thu, 2020-03-05 at 06:54 +0100, Dmitry Vyukov wrote: > On Thu, Mar 5, 2020 at 6:37 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > Hi all, > > > > After merging the akpm-current tree, today's linux-next build (x86_64 > > allmodconfig) produced this warning: > > > > mm/kasan/common.o: warning: objtool: kasan_report()+0x17: call to report_enabled() with UACCESS enabled > > In file included from include/linux/bitmap.h:9, > > from include/linux/cpumask.h:12, > > from arch/x86/include/asm/paravirt.h:17, > > from arch/x86/include/asm/irqflags.h:72, > > from include/linux/irqflags.h:16, > > from include/linux/rcupdate.h:26, > > from include/linux/rculist.h:11, > > from include/linux/pid.h:5, > > from include/linux/sched.h:14, > > from include/linux/uaccess.h:6, > > from arch/x86/include/asm/fpu/xstate.h:5, > > from arch/x86/include/asm/pgtable.h:26, > > from include/linux/kasan.h:15, > > from lib/test_kasan.c:12: > > In function 'memmove', > > inlined from 'kmalloc_memmove_invalid_size' at lib/test_kasan.c:301:2: > > include/linux/string.h:441:9: warning: '__builtin_memmove' specified bound 18446744073709551614 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=] > > +kasan-dev > > We probably need to make this 18446744073709551614 constant "dynamic" > so that compiler does not see it. > > Walter, will you take a look? Thanks Hi Dmitry, Yes, I have fixed it. This warning need newer gcc enough to reproduce. Maybe I should replace original gcc-7.4.0. Thanks. --- a/lib/test_kasan.c +++ b/lib/test_kasan.c @@ -286,17 +286,19 @@ static noinline void __init kmalloc_oob_in_memset(void) static noinline void __init kmalloc_memmove_invalid_size(void) { char *ptr; - size_t size = 64; + size_t size1 = 64; + volatile size_t size2 = -2; pr_info("invalid size in memmove\n"); - ptr = kmalloc(size, GFP_KERNEL); + ptr = kmalloc(size1, GFP_KERNEL); if (!ptr) { pr_err("Allocation failed\n"); return; } - memset((char *)ptr, 0, 64); - memmove((char *)ptr, (char *)ptr + 4, -2); + memset((char *)ptr, 0, size1); + /* the size of memmove() is negative number */ + memmove((char *)ptr, (char *)ptr + 4, size2); kfree(ptr); } > > > 441 | return __builtin_memmove(p, q, size); > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Introduced by commit > > > > 519e500fac64 ("kasan: add test for invalid size in memmove") > > > > That's a bit annoying during a normal x86_64 allmodconfig build ... > > > > -- > > Cheers, > > Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 486 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: mm/gup.c:119:13: warning: 'put_compound_head' defined but not used [-Wunused-function] 119 | static void put_compound_head(struct page *page, int refs, unsigned int flags) | ^~~~~~~~~~~~~~~~~ Introduced by commit 6379e529ebe4 ("mm/gup: fixup for 9947ea2c1e608e32 "mm/gup: track FOLL_PIN pages"") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 975 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: fs/hugetlbfs/inode.c: In function 'remove_inode_hugepages': fs/hugetlbfs/inode.c:460:44: warning: 'hash' may be used uninitialized in this function [-Wmaybe-uninitialized] 460 | mutex_unlock(&hugetlb_fault_mutex_table[hash]); | ^ fs/hugetlbfs/inode.c:463:5: warning: 'index' may be used uninitialized in this function [-Wmaybe-uninitialized] 463 | hugetlb_vmdelete_list(&mapping->i_mmap, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 464 | index * pages_per_huge_page(h), | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 465 | (index + 1) * pages_per_huge_page(h)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Introduced by commit 6fdc8f8d1781 ("hugetlbfs: use i_mmap_rwsem to address page fault/truncate race") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On 3/12/20 12:31 AM, Stephen Rothwell wrote: > Hi all, > > After merging the akpm-current tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > fs/hugetlbfs/inode.c: In function 'remove_inode_hugepages': > fs/hugetlbfs/inode.c:460:44: warning: 'hash' may be used uninitialized in this function [-Wmaybe-uninitialized] > 460 | mutex_unlock(&hugetlb_fault_mutex_table[hash]); > | ^ > fs/hugetlbfs/inode.c:463:5: warning: 'index' may be used uninitialized in this function [-Wmaybe-uninitialized] > 463 | hugetlb_vmdelete_list(&mapping->i_mmap, > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 464 | index * pages_per_huge_page(h), > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 465 | (index + 1) * pages_per_huge_page(h)); > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Introduced by commit > > 6fdc8f8d1781 ("hugetlbfs: use i_mmap_rwsem to address page fault/truncate race") > This is a false positive. However, there are more serious issues with this patch series as reported here: https://lore.kernel.org/linux-mm/1584028670.7365.182.camel@lca.pw/ I'm working on the issue, but these may need to be reverted if I can not come up with a solution quickly. So, I am ignoring the false positive warning until the more serious issue is resolved. -- Mike Kravetz
On Thu, 12 Mar 2020 18:27:25 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> mm/gup.c:119:13: warning: 'put_compound_head' defined but not used [-Wunused-function]
> 119 | static void put_compound_head(struct page *page, int refs, unsigned int flags)
> | ^~~~~~~~~~~~~~~~~
>
> Introduced by commit
>
> 6379e529ebe4 ("mm/gup: fixup for 9947ea2c1e608e32 "mm/gup: track FOLL_PIN pages"")
>
Thanks.
I think this is right. And I don't think it'll apply to most recent
-next.
--- a/mm/gup.c~mm-gup-track-foll_pin-pages-fix-2-fix
+++ a/mm/gup.c
@@ -78,21 +78,6 @@ static __maybe_unused struct page *try_g
return NULL;
}
-static void put_compound_head(struct page *page, int refs, unsigned int flags)
-{
- if (flags & FOLL_PIN)
- refs *= GUP_PIN_COUNTING_BIAS;
-
- VM_BUG_ON_PAGE(page_ref_count(page) < refs, page);
- /*
- * Calling put_page() for each ref is unnecessarily slow. Only the last
- * ref needs a put_page().
- */
- if (refs > 1)
- page_ref_sub(page, refs - 1);
- put_page(page);
-}
-
/**
* try_grab_page() - elevate a page's refcount by a flag-dependent amount
*
@@ -1967,7 +1952,24 @@ EXPORT_SYMBOL(get_user_pages_unlocked);
* This code is based heavily on the PowerPC implementation by Nick Piggin.
*/
#ifdef CONFIG_HAVE_FAST_GUP
+
+static void put_compound_head(struct page *page, int refs, unsigned int flags)
+{
+ if (flags & FOLL_PIN)
+ refs *= GUP_PIN_COUNTING_BIAS;
+
+ VM_BUG_ON_PAGE(page_ref_count(page) < refs, page);
+ /*
+ * Calling put_page() for each ref is unnecessarily slow. Only the last
+ * ref needs a put_page().
+ */
+ if (refs > 1)
+ page_ref_sub(page, refs - 1);
+ put_page(page);
+}
+
#ifdef CONFIG_GUP_GET_PTE_LOW_HIGH
+
/*
* WARNING: only to be used in the get_user_pages_fast() implementation.
*
_
[-- Attachment #1: Type: text/plain, Size: 1015 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (x86_64 allnoconfig) produced this warning: mm/sparse.c:311:12: warning: 'fill_subsection_map' defined but not used [-Wunused-function] 311 | static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages) | ^~~~~~~~~~~~~~~~~~~ mm/sparse.c:306:13: warning: 'is_subsection_map_empty' defined but not used [-Wunused-function] 306 | static bool is_subsection_map_empty(struct mem_section *ms) | ^~~~~~~~~~~~~~~~~~~~~~~ mm/sparse.c:301:12: warning: 'clear_subsection_map' defined but not used [-Wunused-function] 301 | static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages) | ^~~~~~~~~~~~~~~~~~~~ Introduced by commits 38eb09ac7c29 ("mm/sparse.c: introduce new function fill_subsection_map()") 334411156ba6 ("mm/sparse.c: introduce a new function clear_subsection_map()") Or maybe laster patches. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On 03/13/20 at 09:42pm, Stephen Rothwell wrote: > Hi all, > > After merging the akpm-current tree, today's linux-next build (x86_64 > allnoconfig) produced this warning: I tried with allnoconfig on x86_64, make doesn't trigger below warnings. Hi Andrew, Should we fix this kind of warning? If have to, I'll try to make several macro functions like subsection_map_init does for !CONFIG_SPARSEMEM. > > mm/sparse.c:311:12: warning: 'fill_subsection_map' defined but not used [-Wunused-function] > 311 | static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages) > | ^~~~~~~~~~~~~~~~~~~ > mm/sparse.c:306:13: warning: 'is_subsection_map_empty' defined but not used [-Wunused-function] > 306 | static bool is_subsection_map_empty(struct mem_section *ms) > | ^~~~~~~~~~~~~~~~~~~~~~~ > mm/sparse.c:301:12: warning: 'clear_subsection_map' defined but not used [-Wunused-function] > 301 | static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages) > | ^~~~~~~~~~~~~~~~~~~~ > > Introduced by commits > > 38eb09ac7c29 ("mm/sparse.c: introduce new function fill_subsection_map()") > 334411156ba6 ("mm/sparse.c: introduce a new function clear_subsection_map()") > > Or maybe laster patches. > > -- > Cheers, > Stephen Rothwell
On 03/13/20 at 09:42pm, Stephen Rothwell wrote: > Hi all, > > After merging the akpm-current tree, today's linux-next build (x86_64 > allnoconfig) produced this warning: > > mm/sparse.c:311:12: warning: 'fill_subsection_map' defined but not used [-Wunused-function] > 311 | static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages) > | ^~~~~~~~~~~~~~~~~~~ > mm/sparse.c:306:13: warning: 'is_subsection_map_empty' defined but not used [-Wunused-function] > 306 | static bool is_subsection_map_empty(struct mem_section *ms) > | ^~~~~~~~~~~~~~~~~~~~~~~ > mm/sparse.c:301:12: warning: 'clear_subsection_map' defined but not used [-Wunused-function] > 301 | static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages) > | ^~~~~~~~~~~~~~~~~~~~ > > Introduced by commits > > 38eb09ac7c29 ("mm/sparse.c: introduce new function fill_subsection_map()") > 334411156ba6 ("mm/sparse.c: introduce a new function clear_subsection_map()") Hi Stephen, I made below change, but I can't triger these warnings. Could you try below patch, see if it's works? From 9be668f1e30b6bb4ed5f4a07e7d3bb76d3f58f35 Mon Sep 17 00:00:00 2001 From: Baoquan He <bhe@redhat.com> Date: Fri, 13 Mar 2020 20:25:54 +0800 Subject: [PATCH] mm/sparse.c: fix the building warning with !SPARSEMEM Stephen reported below warnings are seen with allnoconfig on x86_64. Fix it by making those dummy functions sub-section map handling visible with CONFIG_SPARSEMEM enabled. mm/sparse.c:311:12: warning: 'fill_subsection_map' defined but not used [-Wunused-function] 311 | static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages) | ^~~~~~~~~~~~~~~~~~~ mm/sparse.c:306:13: warning: 'is_subsection_map_empty' defined but not used [-Wunused-function] 306 | static bool is_subsection_map_empty(struct mem_section *ms) | ^~~~~~~~~~~~~~~~~~~~~~~ mm/sparse.c:301:12: warning: 'clear_subsection_map' defined but not used [-Wunused-function] 301 | static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages) | ^~~~~~~~~~~~~~~~~~~~ Signed-off-by: Baoquan He <bhe@redhat.com> --- mm/sparse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/sparse.c b/mm/sparse.c index 362018e82e22..9e08d118719f 100644 --- a/mm/sparse.c +++ b/mm/sparse.c @@ -293,7 +293,7 @@ static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages) return rc; } -#else +#elif defined(CONFIG_SPARSEMEM) void __init subsection_map_init(unsigned long pfn, unsigned long nr_pages) { } -- 2.17.2
[-- Attachment #1: Type: text/plain, Size: 2064 bytes --] Hi Baoquan, On Fri, 13 Mar 2020 20:56:27 +0800 Baoquan He <bhe@redhat.com> wrote: > > I made below change, but I can't triger these warnings. Could you try > below patch, see if it's works? I needed to add "ARCH=x86_64" to the "make allnoconfig" command line (and the subsequent "make") otherwise I get a 32 bit build. > From 9be668f1e30b6bb4ed5f4a07e7d3bb76d3f58f35 Mon Sep 17 00:00:00 2001 > From: Baoquan He <bhe@redhat.com> > Date: Fri, 13 Mar 2020 20:25:54 +0800 > Subject: [PATCH] mm/sparse.c: fix the building warning with !SPARSEMEM > > Stephen reported below warnings are seen with allnoconfig on x86_64. > Fix it by making those dummy functions sub-section map handling visible > with CONFIG_SPARSEMEM enabled. > > mm/sparse.c:311:12: warning: 'fill_subsection_map' defined but not used [-Wunused-function] > 311 | static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages) > | ^~~~~~~~~~~~~~~~~~~ > mm/sparse.c:306:13: warning: 'is_subsection_map_empty' defined but not used [-Wunused-function] > 306 | static bool is_subsection_map_empty(struct mem_section *ms) > | ^~~~~~~~~~~~~~~~~~~~~~~ > mm/sparse.c:301:12: warning: 'clear_subsection_map' defined but not used [-Wunused-function] > 301 | static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages) > | ^~~~~~~~~~~~~~~~~~~~ > > Signed-off-by: Baoquan He <bhe@redhat.com> > --- > mm/sparse.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/sparse.c b/mm/sparse.c > index 362018e82e22..9e08d118719f 100644 > --- a/mm/sparse.c > +++ b/mm/sparse.c > @@ -293,7 +293,7 @@ static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages) > > return rc; > } > -#else > +#elif defined(CONFIG_SPARSEMEM) > void __init subsection_map_init(unsigned long pfn, unsigned long nr_pages) > { > } This didn't make any difference as CONFIG_SPARSEMEM is set for the x86_64 allnoconfig build. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On 03/14/20 at 11:09am, Stephen Rothwell wrote: > Hi Baoquan, > > On Fri, 13 Mar 2020 20:56:27 +0800 Baoquan He <bhe@redhat.com> wrote: > > > > I made below change, but I can't triger these warnings. Could you try > > below patch, see if it's works? > > I needed to add "ARCH=x86_64" to the "make allnoconfig" command line > (and the subsequent "make") otherwise I get a 32 bit build. Ok, I now see the warnings with 'allnoconfig ARCH=x86_64', thanks. > > > From 9be668f1e30b6bb4ed5f4a07e7d3bb76d3f58f35 Mon Sep 17 00:00:00 2001 > > From: Baoquan He <bhe@redhat.com> > > Date: Fri, 13 Mar 2020 20:25:54 +0800 > > Subject: [PATCH] mm/sparse.c: fix the building warning with !SPARSEMEM > > > > Stephen reported below warnings are seen with allnoconfig on x86_64. > > Fix it by making those dummy functions sub-section map handling visible > > with CONFIG_SPARSEMEM enabled. > > > > mm/sparse.c:311:12: warning: 'fill_subsection_map' defined but not used [-Wunused-function] > > 311 | static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages) > > | ^~~~~~~~~~~~~~~~~~~ > > mm/sparse.c:306:13: warning: 'is_subsection_map_empty' defined but not used [-Wunused-function] > > 306 | static bool is_subsection_map_empty(struct mem_section *ms) > > | ^~~~~~~~~~~~~~~~~~~~~~~ > > mm/sparse.c:301:12: warning: 'clear_subsection_map' defined but not used [-Wunused-function] > > 301 | static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages) > > | ^~~~~~~~~~~~~~~~~~~~ > > > > Signed-off-by: Baoquan He <bhe@redhat.com> > > --- > > mm/sparse.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/sparse.c b/mm/sparse.c > > index 362018e82e22..9e08d118719f 100644 > > --- a/mm/sparse.c > > +++ b/mm/sparse.c > > @@ -293,7 +293,7 @@ static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages) > > > > return rc; > > } > > -#else > > +#elif defined(CONFIG_SPARSEMEM) > > void __init subsection_map_init(unsigned long pfn, unsigned long nr_pages) > > { > > } > > This didn't make any difference as CONFIG_SPARSEMEM is set for the > x86_64 allnoconfig build. You are right, CONFIG_SPARSEMEM is set for x86_64. I will work out a patch after testing. Thanks for these details.
On 03/13/20 at 09:42pm, Stephen Rothwell wrote: > After merging the akpm-current tree, today's linux-next build (x86_64 > allnoconfig) produced this warning: > > mm/sparse.c:311:12: warning: 'fill_subsection_map' defined but not used [-Wunused-function] > 311 | static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages) > | ^~~~~~~~~~~~~~~~~~~ > mm/sparse.c:306:13: warning: 'is_subsection_map_empty' defined but not used [-Wunused-function] > 306 | static bool is_subsection_map_empty(struct mem_section *ms) > | ^~~~~~~~~~~~~~~~~~~~~~~ > mm/sparse.c:301:12: warning: 'clear_subsection_map' defined but not used [-Wunused-function] > 301 | static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages) > | ^~~~~~~~~~~~~~~~~~~~ Hi Stephen, Andrew, I made a patch to fix these warnings, the reason has been told in the log. Or just drop below patch. Both is fine to me. mm-sparsec-move-subsection_map-related-functions-together.patch From 273196eeb7bbc4af93bef18f594af91541e3ce8a Mon Sep 17 00:00:00 2001 From: Baoquan He <bhe@redhat.com> Date: Sat, 14 Mar 2020 17:01:01 +0800 Subject: [PATCH] mm/sparse.c: move functions into CONFIG_MEMORY_HOTPLUG ifdeffery scope Stephen reported warnings are seen with allnoconfig on x86_64: mm/sparse.c:311:12: warning: 'fill_subsection_map' defined but not used [-Wunused-function] 311 | static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages) | ^~~~~~~~~~~~~~~~~~~ mm/sparse.c:306:13: warning: 'is_subsection_map_empty' defined but not used [-Wunused-function] 306 | static bool is_subsection_map_empty(struct mem_section *ms) | ^~~~~~~~~~~~~~~~~~~~~~~ mm/sparse.c:301:12: warning: 'clear_subsection_map' defined but not used [-Wunused-function] 301 | static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages) | ^~~~~~~~~~~~~~~~~~~~ This is because allnoconfig on x86_64 sets CONFIG_SPARSEMEM=y and CONFIG_MEMORY_HOTPLUG=n. Functions clear_subsection_map(), is_subsection_map_empty() and fill_subsection_map() are all defined outside CONFIG_MEMORY_HOTPLUG ifdeffery scope. However, their callers, section_activate() and section_deactivate() are inside CONFIG_MEMORY_HOTPLUG ifdeffery scope. So let's move them into the CONFIG_MEMORY_HOTPLUG iddeffery scope which includes their callers. Signed-off-by: Baoquan He <bhe@redhat.com> --- mm/sparse.c | 128 ++++++++++++++++++++++++++-------------------------- 1 file changed, 64 insertions(+), 64 deletions(-) diff --git a/mm/sparse.c b/mm/sparse.c index bb99633575b5..9b845621b854 100644 --- a/mm/sparse.c +++ b/mm/sparse.c @@ -244,74 +244,10 @@ void __init subsection_map_init(unsigned long pfn, unsigned long nr_pages) nr_pages -= pfns; } } - -static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages) -{ - DECLARE_BITMAP(map, SUBSECTIONS_PER_SECTION) = { 0 }; - DECLARE_BITMAP(tmp, SUBSECTIONS_PER_SECTION) = { 0 }; - struct mem_section *ms = __pfn_to_section(pfn); - unsigned long *subsection_map = ms->usage - ? &ms->usage->subsection_map[0] : NULL; - - subsection_mask_set(map, pfn, nr_pages); - if (subsection_map) - bitmap_and(tmp, map, subsection_map, SUBSECTIONS_PER_SECTION); - - if (WARN(!subsection_map || !bitmap_equal(tmp, map, SUBSECTIONS_PER_SECTION), - "section already deactivated (%#lx + %ld)\n", - pfn, nr_pages)) - return -EINVAL; - - bitmap_xor(subsection_map, map, subsection_map, SUBSECTIONS_PER_SECTION); - return 0; -} - -static bool is_subsection_map_empty(struct mem_section *ms) -{ - return bitmap_empty(&ms->usage->subsection_map[0], - SUBSECTIONS_PER_SECTION); -} - -static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages) -{ - struct mem_section *ms = __pfn_to_section(pfn); - DECLARE_BITMAP(map, SUBSECTIONS_PER_SECTION) = { 0 }; - unsigned long *subsection_map; - int rc = 0; - - subsection_mask_set(map, pfn, nr_pages); - - subsection_map = &ms->usage->subsection_map[0]; - - if (bitmap_empty(map, SUBSECTIONS_PER_SECTION)) - rc = -EINVAL; - else if (bitmap_intersects(map, subsection_map, SUBSECTIONS_PER_SECTION)) - rc = -EEXIST; - else - bitmap_or(subsection_map, map, subsection_map, - SUBSECTIONS_PER_SECTION); - - return rc; -} #else void __init subsection_map_init(unsigned long pfn, unsigned long nr_pages) { } - -static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages) -{ - return 0; -} - -static bool is_subsection_map_empty(struct mem_section *ms) -{ - return true; -} - -static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages) -{ - return 0; -} #endif /* Record a memory area against a node. */ @@ -730,6 +666,55 @@ static void free_map_bootmem(struct page *memmap) vmemmap_free(start, end, NULL); } + +static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages) +{ + DECLARE_BITMAP(map, SUBSECTIONS_PER_SECTION) = { 0 }; + DECLARE_BITMAP(tmp, SUBSECTIONS_PER_SECTION) = { 0 }; + struct mem_section *ms = __pfn_to_section(pfn); + unsigned long *subsection_map = ms->usage + ? &ms->usage->subsection_map[0] : NULL; + + subsection_mask_set(map, pfn, nr_pages); + if (subsection_map) + bitmap_and(tmp, map, subsection_map, SUBSECTIONS_PER_SECTION); + + if (WARN(!subsection_map || !bitmap_equal(tmp, map, SUBSECTIONS_PER_SECTION), + "section already deactivated (%#lx + %ld)\n", + pfn, nr_pages)) + return -EINVAL; + + bitmap_xor(subsection_map, map, subsection_map, SUBSECTIONS_PER_SECTION); + return 0; +} + +static bool is_subsection_map_empty(struct mem_section *ms) +{ + return bitmap_empty(&ms->usage->subsection_map[0], + SUBSECTIONS_PER_SECTION); +} + +static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages) +{ + struct mem_section *ms = __pfn_to_section(pfn); + DECLARE_BITMAP(map, SUBSECTIONS_PER_SECTION) = { 0 }; + unsigned long *subsection_map; + int rc = 0; + + subsection_mask_set(map, pfn, nr_pages); + + subsection_map = &ms->usage->subsection_map[0]; + + if (bitmap_empty(map, SUBSECTIONS_PER_SECTION)) + rc = -EINVAL; + else if (bitmap_intersects(map, subsection_map, SUBSECTIONS_PER_SECTION)) + rc = -EEXIST; + else + bitmap_or(subsection_map, map, subsection_map, + SUBSECTIONS_PER_SECTION); + + return rc; +} #else struct page * __meminit populate_section_memmap(unsigned long pfn, unsigned long nr_pages, int nid, struct vmem_altmap *altmap) @@ -773,6 +758,21 @@ static void free_map_bootmem(struct page *memmap) put_page_bootmem(page); } } + +static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages) +{ + return 0; +} + +static bool is_subsection_map_empty(struct mem_section *ms) +{ + return true; +} + +static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages) +{ + return 0; +} #endif /* CONFIG_SPARSEMEM_VMEMMAP */ /* -- 2.17.2
[-- Attachment #1: Type: text/plain, Size: 635 bytes --] Hi Baoquan, On Mon, 16 Mar 2020 12:58:04 +0800 Baoquan He <bhe@redhat.com> wrote: > > I made a patch to fix these warnings, the reason has been told in the > log. Or just drop below patch. Both is fine to me. > > mm-sparsec-move-subsection_map-related-functions-together.patch > > From 273196eeb7bbc4af93bef18f594af91541e3ce8a Mon Sep 17 00:00:00 2001 > From: Baoquan He <bhe@redhat.com> > Date: Sat, 14 Mar 2020 17:01:01 +0800 > Subject: [PATCH] mm/sparse.c: move functions into CONFIG_MEMORY_HOTPLUG > ifdeffery scope I have applied this to linux-next today to see how it goes. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On 03/16/20 at 05:13pm, Stephen Rothwell wrote:
> Hi Baoquan,
>
> On Mon, 16 Mar 2020 12:58:04 +0800 Baoquan He <bhe@redhat.com> wrote:
> >
> > I made a patch to fix these warnings, the reason has been told in the
> > log. Or just drop below patch. Both is fine to me.
> >
> > mm-sparsec-move-subsection_map-related-functions-together.patch
> >
> > From 273196eeb7bbc4af93bef18f594af91541e3ce8a Mon Sep 17 00:00:00 2001
> > From: Baoquan He <bhe@redhat.com>
> > Date: Sat, 14 Mar 2020 17:01:01 +0800
> > Subject: [PATCH] mm/sparse.c: move functions into CONFIG_MEMORY_HOTPLUG
> > ifdeffery scope
>
> I have applied this to linux-next today to see how it goes.
Thanks.
[-- Attachment #1: Type: text/plain, Size: 837 bytes --] Hi all, On Mon, 16 Mar 2020 17:13:26 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi Baoquan, > > On Mon, 16 Mar 2020 12:58:04 +0800 Baoquan He <bhe@redhat.com> wrote: > > > > I made a patch to fix these warnings, the reason has been told in the > > log. Or just drop below patch. Both is fine to me. > > > > mm-sparsec-move-subsection_map-related-functions-together.patch > > > > From 273196eeb7bbc4af93bef18f594af91541e3ce8a Mon Sep 17 00:00:00 2001 > > From: Baoquan He <bhe@redhat.com> > > Date: Sat, 14 Mar 2020 17:01:01 +0800 > > Subject: [PATCH] mm/sparse.c: move functions into CONFIG_MEMORY_HOTPLUG > > ifdeffery scope > > I have applied this to linux-next today to see how it goes. Tested-by: Stephen Rothwell <sfr@canb.auug.org.au> # compile tested -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 690 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (i386 defconfig) produced this warning: mm/hugetlb.c: In function 'huge_pte_offset': cc1: warning: function may return address of local variable [-Wreturn-local-addr] mm/hugetlb.c:5361:14: note: declared here 5361 | pud_t *pud, pud_entry; | ^~~~~~~~~ cc1: warning: function may return address of local variable [-Wreturn-local-addr] mm/hugetlb.c:5360:14: note: declared here 5360 | p4d_t *p4d, p4d_entry; | ^~~~~~~~~ Introduced by commit 826ddc88e2cf ("mm/hugetlb: fix a addressing exception caused by huge_pte_offset") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, 31 Mar 2020 19:56:12 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (i386
> defconfig) produced this warning:
>
> mm/hugetlb.c: In function 'huge_pte_offset':
> cc1: warning: function may return address of local variable [-Wreturn-local-addr]
> mm/hugetlb.c:5361:14: note: declared here
> 5361 | pud_t *pud, pud_entry;
> | ^~~~~~~~~
> cc1: warning: function may return address of local variable [-Wreturn-local-addr]
> mm/hugetlb.c:5360:14: note: declared here
> 5360 | p4d_t *p4d, p4d_entry;
> | ^~~~~~~~~
>
> Introduced by commit
>
> 826ddc88e2cf ("mm/hugetlb: fix a addressing exception caused by huge_pte_offset")
I can reproduce this (i386 defconfig, gcc-7.2.0).
I can see no way in which this makes any sense. Hopefully it's a gcc
bug but it's hard to see how it could have messed up this fairly simple
code.
On Wed, Apr 01, 2020 at 03:58:31PM -0700, Andrew Morton wrote:
> On Tue, 31 Mar 2020 19:56:12 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi all,
> >
> > After merging the akpm-current tree, today's linux-next build (i386
> > defconfig) produced this warning:
> >
> > mm/hugetlb.c: In function 'huge_pte_offset':
> > cc1: warning: function may return address of local variable [-Wreturn-local-addr]
> > mm/hugetlb.c:5361:14: note: declared here
> > 5361 | pud_t *pud, pud_entry;
> > | ^~~~~~~~~
> > cc1: warning: function may return address of local variable [-Wreturn-local-addr]
> > mm/hugetlb.c:5360:14: note: declared here
> > 5360 | p4d_t *p4d, p4d_entry;
> > | ^~~~~~~~~
> >
> > Introduced by commit
> >
> > 826ddc88e2cf ("mm/hugetlb: fix a addressing exception caused by huge_pte_offset")
>
> I can reproduce this (i386 defconfig, gcc-7.2.0).
>
> I can see no way in which this makes any sense. Hopefully it's a gcc
> bug but it's hard to see how it could have messed up this fairly simple
> code.
It is a code bug, there was a little thread about this. It happens
because the address of a stack variable is passed into the pXX_offset
functions which return that address when the page levels are folded.
I recommend to drop this patch until it is adjusted..
Jason
On 4/1/20 4:00 PM, Jason Gunthorpe wrote: > On Wed, Apr 01, 2020 at 03:58:31PM -0700, Andrew Morton wrote: >> On Tue, 31 Mar 2020 19:56:12 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: >> >>> Hi all, >>> >>> After merging the akpm-current tree, today's linux-next build (i386 >>> defconfig) produced this warning: >>> >>> mm/hugetlb.c: In function 'huge_pte_offset': >>> cc1: warning: function may return address of local variable [-Wreturn-local-addr] >>> mm/hugetlb.c:5361:14: note: declared here >>> 5361 | pud_t *pud, pud_entry; >>> | ^~~~~~~~~ >>> cc1: warning: function may return address of local variable [-Wreturn-local-addr] >>> mm/hugetlb.c:5360:14: note: declared here >>> 5360 | p4d_t *p4d, p4d_entry; >>> | ^~~~~~~~~ >>> >>> Introduced by commit >>> >>> 826ddc88e2cf ("mm/hugetlb: fix a addressing exception caused by huge_pte_offset") >> >> I can reproduce this (i386 defconfig, gcc-7.2.0). >> >> I can see no way in which this makes any sense. Hopefully it's a gcc >> bug but it's hard to see how it could have messed up this fairly simple >> code. > > It is a code bug, there was a little thread about this. It happens > because the address of a stack variable is passed into the pXX_offset > functions which return that address when the page levels are folded. > > I recommend to drop this patch until it is adjusted.. Yes, this patch causes at least the BUG here, https://lore.kernel.org/linux-mm/CA+G9fYsJgZhhWLMzUxu_ZQ+THdCcJmFbHQ2ETA_YPP8M6yxOYA@mail.gmail.com/ -- Mike Kravetz
[-- Attachment #1: Type: text/plain, Size: 303 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: WARNING: modpost: missing MODULE_LICENSE() in lib/test_bits.o Introduced by commit 37f7d07028d1 ("lib/test_bits.c: add tests of GENMASK") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 444 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (i386 defconfig) produced this warning: mm/hugetlb.c:49:20: warning: 'hugetlb_cma' defined but not used [-Wunused-variable] 49 | static struct cma *hugetlb_cma[MAX_NUMNODES]; | ^~~~~~~~~~~ Maybe introduced by commit c70205bf186e ("mm/hugetlb: avoid hardcoding while checking if cma is enable") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 931 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: mm/vmstat.c:614: warning: "MAX_THRESHOLD" redefined 614 | #define MAX_THRESHOLD 0 | mm/vmstat.c:172: note: this is the location of the previous definition 172 | #define MAX_THRESHOLD 125 | mm/vmstat.c:614: warning: "MAX_THRESHOLD" redefined 614 | #define MAX_THRESHOLD 0 | mm/vmstat.c:172: note: this is the location of the previous definition 172 | #define MAX_THRESHOLD 125 | Introduced by commit 5f6bac149e10 ("mm: vmstat: fix /proc/sys/vm/stat_refresh generating false warnings") The preproccesor directives look like this: #ifdef CONFIG_SMP #define MAX_THRESHOLD 125 #ifdef CONFIG_HAVE_CMPXCHG_LOCAL #else #define MAX_THRESHOLD 0 So I guess the second MAX_THRESHOLD was put after the wrong #else? -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Fri, Jul 17, 2020 at 08:31:27PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the akpm-current tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > mm/vmstat.c:614: warning: "MAX_THRESHOLD" redefined > 614 | #define MAX_THRESHOLD 0 > | > mm/vmstat.c:172: note: this is the location of the previous definition > 172 | #define MAX_THRESHOLD 125 > | > mm/vmstat.c:614: warning: "MAX_THRESHOLD" redefined > 614 | #define MAX_THRESHOLD 0 > | > mm/vmstat.c:172: note: this is the location of the previous definition > 172 | #define MAX_THRESHOLD 125 > | > > Introduced by commit > > 5f6bac149e10 ("mm: vmstat: fix /proc/sys/vm/stat_refresh generating false warnings") > > The preproccesor directives look like this: > > #ifdef CONFIG_SMP > #define MAX_THRESHOLD 125 > #ifdef CONFIG_HAVE_CMPXCHG_LOCAL > #else > #define MAX_THRESHOLD 0 > > So I guess the second MAX_THRESHOLD was put after the wrong #else? Right, I missed it. Sorry for the inconvenience! And thank you for pointing at it! The following diff fixes it. Andrew, can you, please, squash it into the "mm: vmstat: fix /proc/sys/vm/stat_refresh generating false warnings" ? Thank you! -- diff --git a/mm/vmstat.c b/mm/vmstat.c index 8f0ef8aaf8ee..08e415e0a15d 100644 --- a/mm/vmstat.c +++ b/mm/vmstat.c @@ -168,9 +168,12 @@ EXPORT_SYMBOL(vm_numa_stat); EXPORT_SYMBOL(vm_node_stat); #ifdef CONFIG_SMP - #define MAX_THRESHOLD 125 +#else +#define MAX_THRESHOLD 0 +#endif +#ifdef CONFIG_SMP int calculate_pressure_threshold(struct zone *zone) { int threshold; @@ -611,8 +614,6 @@ void dec_node_page_state(struct page *page, enum node_stat_item item) EXPORT_SYMBOL(dec_node_page_state); #else -#define MAX_THRESHOLD 0 - /* * Use interrupt disable to serialize counter updates */ -- 2.26.2
[-- Attachment #1: Type: text/plain, Size: 428 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: mm/madvise.c: In function 'madvise_inject_error': mm/madvise.c:875:15: warning: unused variable 'zone' [-Wunused-variable] 875 | struct zone *zone; | ^~~~ Introduced by commit 51fe27319785 ("mm,hwpoison: drop unneeded pcplist draining") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 11077 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: In file included from lib/test_kasan_module.c:16: lib/../mm/kasan/kasan.h:232:6: warning: conflicting types for built-in function '__asan_register_globals'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch] 232 | void __asan_register_globals(struct kasan_global *globals, size_t size); | ^~~~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:233:6: warning: conflicting types for built-in function '__asan_unregister_globals'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch] 233 | void __asan_unregister_globals(struct kasan_global *globals, size_t size); | ^~~~~~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:235:6: warning: conflicting types for built-in function '__asan_alloca_poison'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch] 235 | void __asan_alloca_poison(unsigned long addr, size_t size); | ^~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:236:6: warning: conflicting types for built-in function '__asan_allocas_unpoison'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch] 236 | void __asan_allocas_unpoison(const void *stack_top, const void *stack_bottom); | ^~~~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:238:6: warning: conflicting types for built-in function '__asan_load1'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 238 | void __asan_load1(unsigned long addr); | ^~~~~~~~~~~~ lib/../mm/kasan/kasan.h:239:6: warning: conflicting types for built-in function '__asan_store1'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 239 | void __asan_store1(unsigned long addr); | ^~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:240:6: warning: conflicting types for built-in function '__asan_load2'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 240 | void __asan_load2(unsigned long addr); | ^~~~~~~~~~~~ lib/../mm/kasan/kasan.h:241:6: warning: conflicting types for built-in function '__asan_store2'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 241 | void __asan_store2(unsigned long addr); | ^~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:242:6: warning: conflicting types for built-in function '__asan_load4'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 242 | void __asan_load4(unsigned long addr); | ^~~~~~~~~~~~ lib/../mm/kasan/kasan.h:243:6: warning: conflicting types for built-in function '__asan_store4'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 243 | void __asan_store4(unsigned long addr); | ^~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:244:6: warning: conflicting types for built-in function '__asan_load8'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 244 | void __asan_load8(unsigned long addr); | ^~~~~~~~~~~~ lib/../mm/kasan/kasan.h:245:6: warning: conflicting types for built-in function '__asan_store8'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 245 | void __asan_store8(unsigned long addr); | ^~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:246:6: warning: conflicting types for built-in function '__asan_load16'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 246 | void __asan_load16(unsigned long addr); | ^~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:247:6: warning: conflicting types for built-in function '__asan_store16'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 247 | void __asan_store16(unsigned long addr); | ^~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:248:6: warning: conflicting types for built-in function '__asan_loadN'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch] 248 | void __asan_loadN(unsigned long addr, size_t size); | ^~~~~~~~~~~~ lib/../mm/kasan/kasan.h:249:6: warning: conflicting types for built-in function '__asan_storeN'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch] 249 | void __asan_storeN(unsigned long addr, size_t size); | ^~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:251:6: warning: conflicting types for built-in function '__asan_load1_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 251 | void __asan_load1_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:252:6: warning: conflicting types for built-in function '__asan_store1_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 252 | void __asan_store1_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:253:6: warning: conflicting types for built-in function '__asan_load2_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 253 | void __asan_load2_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:254:6: warning: conflicting types for built-in function '__asan_store2_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 254 | void __asan_store2_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:255:6: warning: conflicting types for built-in function '__asan_load4_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 255 | void __asan_load4_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:256:6: warning: conflicting types for built-in function '__asan_store4_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 256 | void __asan_store4_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:257:6: warning: conflicting types for built-in function '__asan_load8_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 257 | void __asan_load8_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:258:6: warning: conflicting types for built-in function '__asan_store8_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 258 | void __asan_store8_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:259:6: warning: conflicting types for built-in function '__asan_load16_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 259 | void __asan_load16_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:260:6: warning: conflicting types for built-in function '__asan_store16_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 260 | void __asan_store16_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:261:6: warning: conflicting types for built-in function '__asan_loadN_noabort'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch] 261 | void __asan_loadN_noabort(unsigned long addr, size_t size); | ^~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:262:6: warning: conflicting types for built-in function '__asan_storeN_noabort'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch] 262 | void __asan_storeN_noabort(unsigned long addr, size_t size); | ^~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:264:6: warning: conflicting types for built-in function '__asan_report_load1_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 264 | void __asan_report_load1_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:265:6: warning: conflicting types for built-in function '__asan_report_store1_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 265 | void __asan_report_store1_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:266:6: warning: conflicting types for built-in function '__asan_report_load2_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 266 | void __asan_report_load2_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:267:6: warning: conflicting types for built-in function '__asan_report_store2_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 267 | void __asan_report_store2_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:268:6: warning: conflicting types for built-in function '__asan_report_load4_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 268 | void __asan_report_load4_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:269:6: warning: conflicting types for built-in function '__asan_report_store4_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 269 | void __asan_report_store4_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:270:6: warning: conflicting types for built-in function '__asan_report_load8_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 270 | void __asan_report_load8_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:271:6: warning: conflicting types for built-in function '__asan_report_store8_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 271 | void __asan_report_store8_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:272:6: warning: conflicting types for built-in function '__asan_report_load16_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 272 | void __asan_report_load16_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:273:6: warning: conflicting types for built-in function '__asan_report_store16_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] 273 | void __asan_report_store16_noabort(unsigned long addr); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:274:6: warning: conflicting types for built-in function '__asan_report_load_n_noabort'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch] 274 | void __asan_report_load_n_noabort(unsigned long addr, size_t size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ lib/../mm/kasan/kasan.h:275:6: warning: conflicting types for built-in function '__asan_report_store_n_noabort'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch] 275 | void __asan_report_store_n_noabort(unsigned long addr, size_t size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c: In function 'common_nfc_set_geometry': drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c:514:3: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] 514 | nanddev_get_ecc_requirements(&chip->base); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ Introduced by commit 77e7d1c8c356 ("KASAN: Port KASAN Tests to KUnit") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[+kasan-dev, +kunit-dev] On Mon, Sep 14, 2020 at 3:01 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the akpm-current tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > In file included from lib/test_kasan_module.c:16: > lib/../mm/kasan/kasan.h:232:6: warning: conflicting types for built-in function '__asan_register_globals'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch] > 232 | void __asan_register_globals(struct kasan_global *globals, size_t size); > | ^~~~~~~~~~~~~~~~~~~~~~~ > lib/../mm/kasan/kasan.h:233:6: warning: conflicting types for built-in function '__asan_unregister_globals'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch] > 233 | void __asan_unregister_globals(struct kasan_global *globals, size_t size); > | ^~~~~~~~~~~~~~~~~~~~~~~~~ > lib/../mm/kasan/kasan.h:235:6: warning: conflicting types for built-in function '__asan_alloca_poison'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch] > 235 | void __asan_alloca_poison(unsigned long addr, size_t size); > | ^~~~~~~~~~~~~~~~~~~~ > lib/../mm/kasan/kasan.h:236:6: warning: conflicting types for built-in function '__asan_allocas_unpoison'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch] > 236 | void __asan_allocas_unpoison(const void *stack_top, const void *stack_bottom); > | ^~~~~~~~~~~~~~~~~~~~~~~ > lib/../mm/kasan/kasan.h:238:6: warning: conflicting types for built-in function '__asan_load1'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch] > 238 | void __asan_load1(unsigned long addr); > | ^~~~~~~~~~~~ [...some more similar warnings truncated...] Whoops -- these are an issue with the patch: the test_kasan_module.c file should be built with -fno-builtin. I've out a new version of the series which fixes this: https://lore.kernel.org/linux-mm/20200915035828.570483-1-davidgow@google.com/T/#t Basically, the fix is just: diff --git a/lib/Makefile b/lib/Makefile index 8c94cad26db7..d4af75136c54 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -69,6 +69,7 @@ obj-$(CONFIG_KASAN_KUNIT_TEST) += test_kasan.o CFLAGS_test_kasan.o += -fno-builtin CFLAGS_test_kasan.o += $(call cc-disable-warning, vla) obj-$(CONFIG_TEST_KASAN_MODULE) += test_kasan_module.o +CFLAGS_test_kasan_module.o += -fno-builtin obj-$(CONFIG_TEST_UBSAN) += test_ubsan.o CFLAGS_test_ubsan.o += $(call cc-disable-warning, vla) UBSAN_SANITIZE_test_ubsan.o := y -- 2.28.0.618.gf4bc123cb7-goog > drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c: In function 'common_nfc_set_geometry': > drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c:514:3: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] > 514 | nanddev_get_ecc_requirements(&chip->base); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ > I was unable to reproduce this warning: it looks unrelated, so I'm assuming it was attributed. > Introduced by commit > > 77e7d1c8c356 ("KASAN: Port KASAN Tests to KUnit") > > -- > Cheers, > Stephen Rothwell Sorry for the mess, -- David
[-- Attachment #1: Type: text/plain, Size: 630 bytes --] Hi David, On Tue, 15 Sep 2020 12:03:08 +0800 David Gow <davidgow@google.com> wrote: > > > drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c: In function 'common_nfc_set_geometry': > > drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c:514:3: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] > > 514 | nanddev_get_ecc_requirements(&chip->base); > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > I was unable to reproduce this warning: it looks unrelated, so I'm > assuming it was attributed. Yeah, sorry, that was included by accident. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, 15 Sep 2020 at 06:03, 'David Gow' via kasan-dev
<kasan-dev@googlegroups.com> wrote:
>
> [+kasan-dev, +kunit-dev]
>
> On Mon, Sep 14, 2020 at 3:01 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the akpm-current tree, today's linux-next build (x86_64
> > allmodconfig) produced this warning:
> >
> > In file included from lib/test_kasan_module.c:16:
> > lib/../mm/kasan/kasan.h:232:6: warning: conflicting types for built-in function '__asan_register_globals'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch]
> > 232 | void __asan_register_globals(struct kasan_global *globals, size_t size);
> > | ^~~~~~~~~~~~~~~~~~~~~~~
> > lib/../mm/kasan/kasan.h:233:6: warning: conflicting types for built-in function '__asan_unregister_globals'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch]
> > 233 | void __asan_unregister_globals(struct kasan_global *globals, size_t size);
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~
> > lib/../mm/kasan/kasan.h:235:6: warning: conflicting types for built-in function '__asan_alloca_poison'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch]
> > 235 | void __asan_alloca_poison(unsigned long addr, size_t size);
> > | ^~~~~~~~~~~~~~~~~~~~
> > lib/../mm/kasan/kasan.h:236:6: warning: conflicting types for built-in function '__asan_allocas_unpoison'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch]
> > 236 | void __asan_allocas_unpoison(const void *stack_top, const void *stack_bottom);
> > | ^~~~~~~~~~~~~~~~~~~~~~~
> > lib/../mm/kasan/kasan.h:238:6: warning: conflicting types for built-in function '__asan_load1'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
> > 238 | void __asan_load1(unsigned long addr);
> > | ^~~~~~~~~~~~
> [...some more similar warnings truncated...]
>
> Whoops -- these are an issue with the patch: the test_kasan_module.c
> file should be built with -fno-builtin. I've out a new version of the
> series which fixes this:
> https://lore.kernel.org/linux-mm/20200915035828.570483-1-davidgow@google.com/T/#t
>
> Basically, the fix is just:
>
> diff --git a/lib/Makefile b/lib/Makefile
> index 8c94cad26db7..d4af75136c54 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -69,6 +69,7 @@ obj-$(CONFIG_KASAN_KUNIT_TEST) += test_kasan.o
> CFLAGS_test_kasan.o += -fno-builtin
> CFLAGS_test_kasan.o += $(call cc-disable-warning, vla)
> obj-$(CONFIG_TEST_KASAN_MODULE) += test_kasan_module.o
> +CFLAGS_test_kasan_module.o += -fno-builtin
> obj-$(CONFIG_TEST_UBSAN) += test_ubsan.o
> CFLAGS_test_ubsan.o += $(call cc-disable-warning, vla)
> UBSAN_SANITIZE_test_ubsan.o := y
That's reasonable, given it's already done for test_kasan.o.
Although the warnings only occur because it's including
"../mm/kasan/kasan.h", which include declarations for the
instrumentation functions. AFAIK, those declarations only exist to
avoid missing-declaration warnings; in which case all of them could
just be moved above their definitions in generic.c (which would also
avoid some repetition for the ones defined with macros). But given the
various other KASAN patches in-flight, to avoid conflicts let's leave
this as-is, but it's something to improve in case we wanted to get rid
of the fno-builtin.
Thanks,
-- Marco
[-- Attachment #1: Type: text/plain, Size: 9464 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (htmldocs) produced this warning: Documentation/filesystems/proc.rst:296: WARNING: Malformed table. Text in column margin in table line 61. ========================== =================================================== Field Content ========================== =================================================== Name filename of the executable Umask file mode creation mask State state (R is running, S is sleeping, D is sleeping in an uninterruptible wait, Z is zombie, T is traced or stopped) Tgid thread group ID Ngid NUMA group ID (0 if none) Pid process id PPid process id of the parent process TracerPid PID of process tracing this process (0 if not) Uid Real, effective, saved set, and file system UIDs Gid Real, effective, saved set, and file system GIDs FDSize number of file descriptor slots currently allocated Groups supplementary group list NStgid descendant namespace thread group ID hierarchy NSpid descendant namespace process ID hierarchy NSpgid descendant namespace process group ID hierarchy NSsid descendant namespace session ID hierarchy VmPeak peak virtual memory size VmSize total program size VmLck locked memory size VmPin pinned memory size VmHWM peak resident set size ("high water mark") VmRSS size of memory portions. It contains the three following parts (VmRSS = RssAnon + RssFile + RssShmem) RssAnon size of resident anonymous memory RssFile size of resident file mappings RssShmem size of resident shmem memory (includes SysV shm, mapping of tmpfs and shared anonymous mappings) VmData size of private data segments VmStk size of stack segments VmExe size of text segment VmLib size of shared library code VmPTE size of page table entries VmSwap amount of swap used by anonymous private data (shmem swap usage is not included) HugetlbPages size of hugetlb memory portions CoreDumping process's memory is currently being dumped (killing the process may lead to a corrupted core) THP_enabled process is allowed to use THP (returns 0 when PR_SET_THP_DISABLE is set on the process Threads number of threads SigQ number of signals queued/max. number for queue SigPnd bitmap of pending signals for the thread ShdPnd bitmap of shared pending signals for the process SigBlk bitmap of blocked signals SigIgn bitmap of ignored signals SigCgt bitmap of caught signals CapInh bitmap of inheritable capabilities CapPrm bitmap of permitted capabilities CapEff bitmap of effective capabilities CapBnd bitmap of capabilities bounding set CapAmb bitmap of ambient capabilities NoNewPrivs no_new_privs, like prctl(PR_GET_NO_NEW_PRIV, ...) Seccomp seccomp mode, like prctl(PR_GET_SECCOMP, ...) Speculation_Store_Bypass speculative store bypass mitigation status Speculation_Indirect_Branch indirect branch speculation mode Cpus_allowed mask of CPUs on which this process may run Cpus_allowed_list Same as previous, but in "list format" Mems_allowed mask of memory nodes allowed to this process Mems_allowed_list Same as previous, but in "list format" voluntary_ctxt_switches number of voluntary context switches nonvoluntary_ctxt_switches number of non voluntary context switches ========================== =================================================== Documentation/filesystems/proc.rst:234: WARNING: Error parsing content block for the "table" directive: exactly one table expected. .. table:: Table 1-2: Contents of the status files (as of 4.19) ========================== =================================================== Field Content ========================== =================================================== Name filename of the executable Umask file mode creation mask State state (R is running, S is sleeping, D is sleeping in an uninterruptible wait, Z is zombie, T is traced or stopped) Tgid thread group ID Ngid NUMA group ID (0 if none) Pid process id PPid process id of the parent process TracerPid PID of process tracing this process (0 if not) Uid Real, effective, saved set, and file system UIDs Gid Real, effective, saved set, and file system GIDs FDSize number of file descriptor slots currently allocated Groups supplementary group list NStgid descendant namespace thread group ID hierarchy NSpid descendant namespace process ID hierarchy NSpgid descendant namespace process group ID hierarchy NSsid descendant namespace session ID hierarchy VmPeak peak virtual memory size VmSize total program size VmLck locked memory size VmPin pinned memory size VmHWM peak resident set size ("high water mark") VmRSS size of memory portions. It contains the three following parts (VmRSS = RssAnon + RssFile + RssShmem) RssAnon size of resident anonymous memory RssFile size of resident file mappings RssShmem size of resident shmem memory (includes SysV shm, mapping of tmpfs and shared anonymous mappings) VmData size of private data segments VmStk size of stack segments VmExe size of text segment VmLib size of shared library code VmPTE size of page table entries VmSwap amount of swap used by anonymous private data (shmem swap usage is not included) HugetlbPages size of hugetlb memory portions CoreDumping process's memory is currently being dumped (killing the process may lead to a corrupted core) THP_enabled process is allowed to use THP (returns 0 when PR_SET_THP_DISABLE is set on the process Threads number of threads SigQ number of signals queued/max. number for queue SigPnd bitmap of pending signals for the thread ShdPnd bitmap of shared pending signals for the process SigBlk bitmap of blocked signals SigIgn bitmap of ignored signals SigCgt bitmap of caught signals CapInh bitmap of inheritable capabilities CapPrm bitmap of permitted capabilities CapEff bitmap of effective capabilities CapBnd bitmap of capabilities bounding set CapAmb bitmap of ambient capabilities NoNewPrivs no_new_privs, like prctl(PR_GET_NO_NEW_PRIV, ...) Seccomp seccomp mode, like prctl(PR_GET_SECCOMP, ...) Speculation_Store_Bypass speculative store bypass mitigation status Speculation_Indirect_Branch indirect branch speculation mode Cpus_allowed mask of CPUs on which this process may run Cpus_allowed_list Same as previous, but in "list format" Mems_allowed mask of memory nodes allowed to this process Mems_allowed_list Same as previous, but in "list format" voluntary_ctxt_switches number of voluntary context switches nonvoluntary_ctxt_switches number of non voluntary context switches ========================== =================================================== Introduced by commit 60b492d745d5 ("proc: provide details on indirect branch speculation") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Thu, Nov 05, 2020 at 05:45:49PM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the akpm-current tree, today's linux-next build (htmldocs) > produced this warning: > > Documentation/filesystems/proc.rst:296: WARNING: Malformed table. > Text in column margin in table line 61. > > ========================== =================================================== > Field Content > ========================== =================================================== ... > Speculation_Store_Bypass speculative store bypass mitigation status > Speculation_Indirect_Branch indirect branch speculation mode ... > ========================== =================================================== > Documentation/filesystems/proc.rst:234: WARNING: Error parsing content block for the "table" directive: exactly one table expected. Looks like left column became too wide, so rather than shift the right column to the right, I'd suggest to drop underscores in Speculation*. > > .. table:: Table 1-2: Contents of the status files (as of 4.19) > > ========================== =================================================== > Field Content > ========================== =================================================== ... > Speculation_Store_Bypass speculative store bypass mitigation status > Speculation_Indirect_Branch indirect branch speculation mode > Cpus_allowed mask of CPUs on which this process may run > Cpus_allowed_list Same as previous, but in "list format" > Mems_allowed mask of memory nodes allowed to this process > Mems_allowed_list Same as previous, but in "list format" > voluntary_ctxt_switches number of voluntary context switches > nonvoluntary_ctxt_switches number of non voluntary context switches > ========================== =================================================== Same here. > Introduced by commit > > 60b492d745d5 ("proc: provide details on indirect branch speculation") > > -- > Cheers, > Stephen Rothwell -- Sincerely yours, Mike.
On Thu, 5 Nov 2020 at 18:03, Mike Rapoport <rppt@kernel.org> wrote: > > On Thu, Nov 05, 2020 at 05:45:49PM +1100, Stephen Rothwell wrote: > > Hi all, > > > > After merging the akpm-current tree, today's linux-next build (htmldocs) > > produced this warning: > > > > Documentation/filesystems/proc.rst:296: WARNING: Malformed table. > > Text in column margin in table line 61. > > > > ========================== =================================================== > > Field Content > > ========================== =================================================== > ... > > Speculation_Store_Bypass speculative store bypass mitigation status > > Speculation_Indirect_Branch indirect branch speculation mode > ... > > ========================== =================================================== > > Documentation/filesystems/proc.rst:234: WARNING: Error parsing content block for the "table" directive: exactly one table expected. > > Looks like left column became too wide, so rather than shift the right > column to the right, I'd suggest to drop underscores in Speculation*. Hm. That makes it inconsistent with Speculation_Store_Bypass. I guess it's the lesser of two evils. How would I go about fixing this? Send a new (v2), fixed patch to the mailing list? I'm not that familiar with how patches get merged through the branches. > > > > > .. table:: Table 1-2: Contents of the status files (as of 4.19) > > > > ========================== =================================================== > > Field Content > > ========================== =================================================== > ... > > Speculation_Store_Bypass speculative store bypass mitigation status > > Speculation_Indirect_Branch indirect branch speculation mode > > Cpus_allowed mask of CPUs on which this process may run > > Cpus_allowed_list Same as previous, but in "list format" > > Mems_allowed mask of memory nodes allowed to this process > > Mems_allowed_list Same as previous, but in "list format" > > voluntary_ctxt_switches number of voluntary context switches > > nonvoluntary_ctxt_switches number of non voluntary context switches > > ========================== =================================================== > > Same here. > > > Introduced by commit > > > > 60b492d745d5 ("proc: provide details on indirect branch speculation") > > > > -- > > Cheers, > > Stephen Rothwell > > > > -- > Sincerely yours, > Mike. -- Anand K. Mistry Software Engineer Google Australia
SNIPPED
> >
> > Looks like left column became too wide, so rather than shift the right
> > column to the right, I'd suggest to drop underscores in Speculation*.
>
> Hm. That makes it inconsistent with Speculation_Store_Bypass. I guess
> it's the lesser of two evils.
Oh, do you mean renaming the existing Speculation_Store_Bypass? I
thought that was a big no-no for the kernel?
[-- Attachment #1: Type: text/plain, Size: 560 bytes --] Hi Anand, On Thu, 5 Nov 2020 18:42:23 +1100 "Anand K. Mistry" <amistry@google.com> wrote: > > How would I go about fixing this? Send a new (v2), fixed patch to the > mailing list? I'm not that familiar with how patches get merged > through the branches. Since this is in Andrew's quilt series, either a v2, or an incremental patch (to wherever the original went - including cc'ing Andrew). If you send a v2, he will probably turn it into an incremental patch and then squash it back before sending it to Linus. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 888 bytes --] Hi Anand, On Thu, 5 Nov 2020 19:00:11 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Thu, 5 Nov 2020 18:42:23 +1100 "Anand K. Mistry" <amistry@google.com> wrote: > > > > How would I go about fixing this? Send a new (v2), fixed patch to the > > mailing list? I'm not that familiar with how patches get merged > > through the branches. > > Since this is in Andrew's quilt series, either a v2, or an incremental > patch (to wherever the original went - including cc'ing Andrew). If > you send a v2, he will probably turn it into an incremental patch and > then squash it back before sending it to Linus. And if you cc me as well, I will add it to the copy of Andrew's series that I have in linux-next (so I won't have to worry about the warning until Andrew gets around to sending out a new version of his quilt series). -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Thu, Nov 05, 2020 at 06:45:04PM +1100, Anand K. Mistry wrote:
> SNIPPED
>
> > >
> > > Looks like left column became too wide, so rather than shift the right
> > > column to the right, I'd suggest to drop underscores in Speculation*.
> >
> > Hm. That makes it inconsistent with Speculation_Store_Bypass. I guess
> > it's the lesser of two evils.
>
> Oh, do you mean renaming the existing Speculation_Store_Bypass? I
> thought that was a big no-no for the kernel?
Right, renaming is not an option :)
I thought Speculation_Store_Bypass was also introduced by the same
patch, sorry about the confusion.
--
Sincerely yours,
Mike.
[-- Attachment #1: Type: text/plain, Size: 331 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (htmldocs) produced this warning: include/linux/kfence.h:138: warning: Function parameter or member 'addr' not described in 'kfence_object_start' Introduced by patch mm: add Kernel Electric-Fence infrastructure -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 325 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: WARNING: modpost: missing MODULE_LICENSE() in lib/cmdline_kunit.o Introduced by commit f1a15df76475 ("lib/cmdline_kunit: add a new test suite for cmdline API") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Fri, Nov 13, 2020 at 05:01:01PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> WARNING: modpost: missing MODULE_LICENSE() in lib/cmdline_kunit.o
>
> Introduced by commit
>
> f1a15df76475 ("lib/cmdline_kunit: add a new test suite for cmdline API")
I'm on it right now, thanks!
--
With Best Regards,
Andy Shevchenko
[-- Attachment #1: Type: text/plain, Size: 447 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (htmldocs) produced this warning: Documentation/vm/page_owner.rst:44: WARNING: Literal block ends without a blank line; unexpected unindent. Documentation/vm/page_owner.rst:49: WARNING: Literal block ends without a blank line; unexpected unindent. Introduced by commit 6cf22751938a ("mm/page_owner: Record timestamp and pid") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Thanks for the report Stephen!
Andrew, I have sent you an updated patch. Please let me know if you prefer
a follow-up fix instead.
BR,
Georgi
On 12/10/20 11:38, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (htmldocs)
> produced this warning:
>
> Documentation/vm/page_owner.rst:44: WARNING: Literal block ends without a blank line; unexpected unindent.
> Documentation/vm/page_owner.rst:49: WARNING: Literal block ends without a blank line; unexpected unindent.
>
> Introduced by commit
>
> 6cf22751938a ("mm/page_owner: Record timestamp and pid")
>
[-- Attachment #1: Type: text/plain, Size: 350 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (htmldocs) produced this warning: Documentation/ABI/testing/sysfs-kernel-mm-cma:2: WARNING: Inline interpreted text or phrase reference start-string without end-string. Introduced by commit 439d477342a3 ("mm: cma: support sysfs") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Mon, Mar 15, 2021 at 04:35:22PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (htmldocs)
> produced this warning:
>
> Documentation/ABI/testing/sysfs-kernel-mm-cma:2: WARNING: Inline interpreted text or phrase reference start-string without end-string.
>
> Introduced by commit
>
> 439d477342a3 ("mm: cma: support sysfs")
>
Hmm, I don't get it what happened here. Was it false-positive?
[-- Attachment #1: Type: text/plain, Size: 732 bytes --] Hi Minchan, On Tue, 16 Mar 2021 11:18:11 -0700 Minchan Kim <minchan@kernel.org> wrote: > > On Mon, Mar 15, 2021 at 04:35:22PM +1100, Stephen Rothwell wrote: > > Hi all, > > > > After merging the akpm-current tree, today's linux-next build (htmldocs) > > produced this warning: > > > > Documentation/ABI/testing/sysfs-kernel-mm-cma:2: WARNING: Inline interpreted text or phrase reference start-string without end-string. > > > > Introduced by commit > > > > 439d477342a3 ("mm: cma: support sysfs") > > > > Hmm, I don't get it what happened here. Was it false-positive? I get the above from a "make htmldocs" run ... I don't know what causes it, sorry. [cc'ing Jon] -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Stephen Rothwell <sfr@canb.auug.org.au> writes: [Adding Mauro] > On Tue, 16 Mar 2021 11:18:11 -0700 Minchan Kim <minchan@kernel.org> wrote: >> >> On Mon, Mar 15, 2021 at 04:35:22PM +1100, Stephen Rothwell wrote: >> > Hi all, >> > >> > After merging the akpm-current tree, today's linux-next build (htmldocs) >> > produced this warning: >> > >> > Documentation/ABI/testing/sysfs-kernel-mm-cma:2: WARNING: Inline interpreted text or phrase reference start-string without end-string. >> > >> > Introduced by commit >> > >> > 439d477342a3 ("mm: cma: support sysfs") >> > >> >> Hmm, I don't get it what happened here. Was it false-positive? > > I get the above from a "make htmldocs" run ... I don't know what causes > it, sorry. [cc'ing Jon] OK, this took a while to figure out. The problem is this text in sysfs-kernel-mm-cma: > Each CMA heap subdirectory (that is, each > /sys/kernel/mm/cma/<cma-heap-name> directory) contains the > following items: When scripts/get_abi.pl sees the /sys/kernel/mm/... string it wants to turn it into a link to the matching ABI entry; at that point, the <text in angle brackets> collides with the Sphinx directive and you get that totally useless warning. I think this is a bug in get_abi.pl. Honestly I wonder if all these cross-links are needed at all; if they truly are, then we shouldn't be making bogus ones. Mauro, how hard would it be to make this do the right thing? Thanks, jon
Em Tue, 16 Mar 2021 17:09:20 -0600 Jonathan Corbet <corbet@lwn.net> escreveu: > Stephen Rothwell <sfr@canb.auug.org.au> writes: > > [Adding Mauro] > > > On Tue, 16 Mar 2021 11:18:11 -0700 Minchan Kim <minchan@kernel.org> wrote: > >> > >> On Mon, Mar 15, 2021 at 04:35:22PM +1100, Stephen Rothwell wrote: > >> > Hi all, > >> > > >> > After merging the akpm-current tree, today's linux-next build (htmldocs) > >> > produced this warning: > >> > > >> > Documentation/ABI/testing/sysfs-kernel-mm-cma:2: WARNING: Inline interpreted text or phrase reference start-string without end-string. > >> > > >> > Introduced by commit > >> > > >> > ("mm: cma: support sysfs") > >> > > >> > >> Hmm, I don't get it what happened here. Was it false-positive? > > > > I get the above from a "make htmldocs" run ... I don't know what causes > > it, sorry. [cc'ing Jon] > > OK, this took a while to figure out. The problem is this text in > sysfs-kernel-mm-cma: > > > Each CMA heap subdirectory (that is, each > > /sys/kernel/mm/cma/<cma-heap-name> directory) contains the > > following items: > > When scripts/get_abi.pl sees the /sys/kernel/mm/... string it wants to > turn it into a link to the matching ABI entry; at that point, the > <text in angle brackets> collides with the Sphinx directive and you get > that totally useless warning. > > I think this is a bug in get_abi.pl. Honestly I wonder if all these > cross-links are needed at all; if they truly are, then we shouldn't be > making bogus ones. Mauro, how hard would it be to make this do the > right thing? Actually, we need the "<>" syntax a the output document. Basically, the script assumes that everything inside the ABI description is ReST. So, it preserves the text untouched, except when creating cross-references, which is the case here. The script expects an entry for every cross-referenced symbol. In other words, something like: /sys/kernel/mm/cma/ should be converted into: :ref:`/sys/kernel/mm/cma/ <abi_sys_kernel_mm_cma>` The actual output is more complex than that, as there are some special chars that need to be escaped at the naming part. You can check the full output of this single file with: $ mkdir Documentation/ABI/aa && cp Documentation/ABI/testing/sysfs-kernel-mm-cma $ ./scripts/get_abi.pl --dir=Documentation/ABI/aa rest Symbols under /sys/kernel ------------------------- .. _abi_sys_kernel_mm_cma: +-------------------------+ | **/sys/kernel/mm/cma/** | +-------------------------+ Defined on file :ref:`sysfs-kernel-mm-cma <abi_file_aa_sysfs_kernel_mm_cma>` :ref:`\/sys\/kernel\/mm\/cma\/ <abi_sys_kernel_mm_cma>` contains a subdirectory for each CMA heap name (also sometimes called CMA areas). Each CMA heap subdirectory (that is, each :ref:`\/sys\/kernel\/mm\/cma\/ <abi_sys_kernel_mm_cma>`<cma-heap-name> directory) contains the following items: alloc_pages_success alloc_pages_fail .. _abi_sys_kernel_mm_cma_cma_heap_name_alloc_pages_fail: +-------------------------------------------------------------+ | **/sys/kernel/mm/cma/<cma\-heap\-name>/alloc\_pages\_fail** | +-------------------------------------------------------------+ Defined on file :ref:`sysfs-kernel-mm-cma <abi_file_aa_sysfs_kernel_mm_cma>` the number of pages CMA API failed to allocate .. _abi_sys_kernel_mm_cma_cma_heap_name_alloc_pages_success: +----------------------------------------------------------------+ | **/sys/kernel/mm/cma/<cma\-heap\-name>/alloc\_pages\_success** | +----------------------------------------------------------------+ Defined on file :ref:`sysfs-kernel-mm-cma <abi_file_aa_sysfs_kernel_mm_cma>` the number of pages CMA API succeeded to allocate .. _abi_file_aa_sysfs_kernel_mm_cma: File aa/sysfs\-kernel\-mm\-cma ------------------------------ Has the following ABI: - :ref:`\/sys\/kernel\/mm\/cma\/ <abi_sys_kernel_mm_cma>` - :ref:`\/sys\/kernel\/mm\/cma\/\<cma\-heap\-name\>\/alloc_pages_success <abi_sys_kernel_mm_cma_cma_heap_name_alloc_pages_success>` - :ref:`\/sys\/kernel\/mm\/cma\/\<cma\-heap\-name\>\/alloc_pages_fail <abi_sys_kernel_mm_cma_cma_heap_name_alloc_pages_fail>` There are two separated issues here: 1) the cross-reference for "/sys/kernel/mm/cma/<cma-heap-name>" doesn't exist. The fix would be to do something like: What: /sys/kernel/mm/cma/ Date: Feb 2021 Contact: Minchan Kim <minchan@kernel.org> Description: /sys/kernel/mm/cma/ contains a subdirectory for each CMA heap name (also sometimes called CMA areas). Each CMA heap subdirectory contains the following items: /sys/kernel/mm/cma/<cma-heap-name>/alloc_pages_success /sys/kernel/mm/cma/<cma-heap-name>/alloc_pages_fail This way, the /sys/kernel/mm/cma/<cma-heap-name>/* will produce the right cross-references; 2) The get_abi.pl doesn't escape "<" and ">" chars. The enclosed patch should do the trick. Please notice that I didn't check if this won't cause side effects - I'm in vacations until next week... too lazy to do a full test those days ;-) Thanks, Mauro [PATCH] script: get_abi.pl: escape "<" and ">" characters Those characters should be escaped on cross-references. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> diff --git a/scripts/get_abi.pl b/scripts/get_abi.pl index 92d9aa6cc4f5..79d195b48652 100755 --- a/scripts/get_abi.pl +++ b/scripts/get_abi.pl @@ -305,7 +305,7 @@ sub output_rest { } my $w = $what; - $w =~ s/([\(\)\_\-\*\=\^\~\\])/\\$1/g; + $w =~ s/([\(\)\_\-\*\=\^\~\\\<\>])/\\$1/g; if ($type ne "File") { my $cur_part = $what;
[-- Attachment #1: Type: text/plain, Size: 350 bytes --] Hi all, After merging the akpm-current tree, yesterday's linux-next build (htmldocs) produced this warning: mm/vmalloc.c:425: warning: expecting prototype for vunmap_range_noflush(). Prototype was for vunmap_range() instead Introduced by commit cde193f42509 ("mm/vmalloc: remove unmap_kernel_range") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 515 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: mm/swapfile.c:1039:22: warning: 'scan_swap_map' defined but not used [-Wunused-function] 1039 | static unsigned long scan_swap_map(struct swap_info_struct *si, | ^~~~~~~~~~~~~ Introduced by commit c9ea6b99df3c ("mm/swapfile: move get_swap_page_of_type() under CONFIG_HIBERNATION") # CONFIG_HIBERNATION is not set -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On 2021/5/21 13:39, Stephen Rothwell wrote: > Hi all, > > After merging the akpm-current tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > mm/swapfile.c:1039:22: warning: 'scan_swap_map' defined but not used [-Wunused-function] > 1039 | static unsigned long scan_swap_map(struct swap_info_struct *si, > | ^~~~~~~~~~~~~ > > Introduced by commit > > c9ea6b99df3c ("mm/swapfile: move get_swap_page_of_type() under CONFIG_HIBERNATION") > > # CONFIG_HIBERNATION is not set It seems that scan_swap_map is only used by get_swap_page_of_type(). I should have been more careful and move it under CONFIG_HIBERNATION too. I will send a patch to fix this. Many thanks! >
[-- Attachment #1: Type: text/plain, Size: 445 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (i386 defconfig) produced this warning: mm/hugetlb.c: In function 'dequeue_huge_page_vma': mm/hugetlb.c:1180:1: warning: label 'check_reserve' defined but not used [-Wunused-label] 1180 | check_reserve: | ^~~~~~~~~~~~~ Introduced by commit df178183cf05 ("mm/hugetlb: add support for mempolicy MPOL_PREFERRED_MANY") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2029 bytes --] Hi Stephen, On Mon, Jul 19, 2021 at 05:52:03PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the akpm-current tree, today's linux-next build (i386 > defconfig) produced this warning: > > mm/hugetlb.c: In function 'dequeue_huge_page_vma': > mm/hugetlb.c:1180:1: warning: label 'check_reserve' defined but not used [-Wunused-label] > 1180 | check_reserve: > | ^~~~~~~~~~~~~ > > Introduced by commit > > df178183cf05 ("mm/hugetlb: add support for mempolicy MPOL_PREFERRED_MANY") Thanks for the report! The below patch should fix it (Also attached). Andrew, Could you help to fold it to the 4/6 of patchset of "introducing multi-preference memplicy": [PATCH v6 4/6] mm/hugetlb: add support for mempolicy MPOL_PREFERRED_MANY Thanks! - Feng --------------------------------8<----------------------------------- From 4d3b4b0037bf4e1eacae4886387ffe4af90f5a1f Mon Sep 17 00:00:00 2001 From: Feng Tang <feng.tang@intel.com> Date: Mon, 19 Jul 2021 16:24:23 +0800 Subject: [PATCH] mm/hugetlb: fix compile warning for !CONFIG_NUMA build Stephen Rothwell reported the i386 build with CONFIG_NUMA=n will have a warning: mm/hugetlb.c: In function 'dequeue_huge_page_vma': mm/hugetlb.c:1180:1: warning: label 'check_reserve' defined but not used [-Wunused-label] 1180 | check_reserve: | ^~~~~~~~~~~~~ introduced by commit df178183cf05 ("mm/hugetlb: add support for mempolicy MPOL_PREFERRED_MANY") Signed-off-by: Feng Tang <feng.tang@intel.com> --- mm/hugetlb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index ae1a39e11bcf..528947da65c8 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1177,7 +1177,9 @@ static struct page *dequeue_huge_page_vma(struct hstate *h, #endif page = dequeue_huge_page_nodemask(h, gfp_mask, nid, nodemask); +#ifdef CONFIG_NUMA check_reserve: +#endif if (page && !avoid_reserve && vma_has_reserves(vma, chg)) { SetHPageRestoreReserve(page); h->resv_huge_pages--; -- 2.7.4 > -- > Cheers, > Stephen Rothwell [-- Attachment #2: 0001-mm-hugetlb-fix-compile-warning-for-CONFIG_NUMA-build.patch --] [-- Type: text/x-diff, Size: 1148 bytes --] From 4d3b4b0037bf4e1eacae4886387ffe4af90f5a1f Mon Sep 17 00:00:00 2001 From: Feng Tang <feng.tang@intel.com> Date: Mon, 19 Jul 2021 16:24:23 +0800 Subject: [PATCH] mm/hugetlb: fix compile warning for !CONFIG_NUMA build Stephen Rothwell reported the i386 build with CONFIG_NUMA=n will have a warning: mm/hugetlb.c: In function 'dequeue_huge_page_vma': mm/hugetlb.c:1180:1: warning: label 'check_reserve' defined but not used [-Wunused-label] 1180 | check_reserve: | ^~~~~~~~~~~~~ introduced by commit df178183cf05 ("mm/hugetlb: add support for mempolicy MPOL_PREFERRED_MANY") Signed-off-by: Feng Tang <feng.tang@intel.com> --- mm/hugetlb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index ae1a39e11bcf..528947da65c8 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1177,7 +1177,9 @@ static struct page *dequeue_huge_page_vma(struct hstate *h, #endif page = dequeue_huge_page_nodemask(h, gfp_mask, nid, nodemask); +#ifdef CONFIG_NUMA check_reserve: +#endif if (page && !avoid_reserve && vma_has_reserves(vma, chg)) { SetHPageRestoreReserve(page); h->resv_huge_pages--; -- 2.7.4
[-- Attachment #1: Type: text/plain, Size: 1077 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (htmldocs) produced this warning: Documentation/filesystems/proc.rst:429: WARNING: Malformed table. No bottom table border found. ======= ==================================== [heap] the heap of the program [stack] the stack of the main process [vdso] the "virtual dynamic shared object", the kernel system call handler Documentation/filesystems/proc.rst:434: WARNING: Block quote ends without a blank line; unexpected unindent. Documentation/filesystems/proc.rst:436: WARNING: Block quote ends without a blank line; unexpected unindent. Documentation/filesystems/proc.rst:436: WARNING: Malformed table. No bottom table border found. ======= ==================================== or if empty, the mapping is anonymous. Introduced by commit 2df148be9486 ("mm: add a field to store names for private anonymous memory") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Mon, Nov 22, 2021 at 9:26 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the akpm-current tree, today's linux-next build (htmldocs) > produced this warning: > > Documentation/filesystems/proc.rst:429: WARNING: Malformed table. > No bottom table border found. > > ======= ==================================== > [heap] the heap of the program > [stack] the stack of the main process > [vdso] the "virtual dynamic shared object", > the kernel system call handler > Documentation/filesystems/proc.rst:434: WARNING: Block quote ends without a blank line; unexpected unindent. > Documentation/filesystems/proc.rst:436: WARNING: Block quote ends without a blank line; unexpected unindent. > Documentation/filesystems/proc.rst:436: WARNING: Malformed table. > No bottom table border found. > > ======= ==================================== > > or if empty, the mapping is anonymous. > > Introduced by commit > > 2df148be9486 ("mm: add a field to store names for private anonymous memory") Thank you for reporting! I'll try to fix it first thing in the morning. Thanks, Suren. > > -- > Cheers, > Stephen Rothwell
On Tue, Nov 23, 2021 at 12:38 AM Suren Baghdasaryan <surenb@google.com> wrote: > > On Mon, Nov 22, 2021 at 9:26 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > Hi all, > > > > After merging the akpm-current tree, today's linux-next build (htmldocs) > > produced this warning: > > > > Documentation/filesystems/proc.rst:429: WARNING: Malformed table. > > No bottom table border found. > > > > ======= ==================================== > > [heap] the heap of the program > > [stack] the stack of the main process > > [vdso] the "virtual dynamic shared object", > > the kernel system call handler > > Documentation/filesystems/proc.rst:434: WARNING: Block quote ends without a blank line; unexpected unindent. > > Documentation/filesystems/proc.rst:436: WARNING: Block quote ends without a blank line; unexpected unindent. > > Documentation/filesystems/proc.rst:436: WARNING: Malformed table. > > No bottom table border found. > > > > ======= ==================================== > > > > or if empty, the mapping is anonymous. > > > > Introduced by commit > > > > 2df148be9486 ("mm: add a field to store names for private anonymous memory") > > Thank you for reporting! I'll try to fix it first thing in the morning. Hi Stephen, I just posted a fix for the warning at https://lore.kernel.org/linux-next/20211123185928.2513763-1-surenb@google.com/T/#u One thing I'm not sure is that I used SHA from linux-next in the Fixes: field: Fixes: 2df148be9486 ("mm: add a field to store names for private anonymous memory") Not sure if that's acceptable. Please let me know if you want me to repost the fix without that line. Thanks, Suren. > Thanks, > Suren. > > > > > -- > > Cheers, > > Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 647 bytes --] Hi Suren, On Tue, 23 Nov 2021 11:03:47 -0800 Suren Baghdasaryan <surenb@google.com> wrote: > > I just posted a fix for the warning at > https://lore.kernel.org/linux-next/20211123185928.2513763-1-surenb@google.com/T/#u > One thing I'm not sure is that I used SHA from linux-next in the Fixes: field: > > Fixes: 2df148be9486 ("mm: add a field to store names for private > anonymous memory") > > Not sure if that's acceptable. Please let me know if you want me to > repost the fix without that line. It doesn't really matter as Andrew will most likely squash this fixup into the original patch. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, Nov 23, 2021 at 2:26 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi Suren, > > On Tue, 23 Nov 2021 11:03:47 -0800 Suren Baghdasaryan <surenb@google.com> wrote: > > > > I just posted a fix for the warning at > > https://lore.kernel.org/linux-next/20211123185928.2513763-1-surenb@google.com/T/#u > > One thing I'm not sure is that I used SHA from linux-next in the Fixes: field: > > > > Fixes: 2df148be9486 ("mm: add a field to store names for private > > anonymous memory") > > > > Not sure if that's acceptable. Please let me know if you want me to > > repost the fix without that line. > > It doesn't really matter as Andrew will most likely squash this fixup > into the original patch. Perfect! Please let me know if anything else is needed. Thanks, Suren. > > -- > Cheers, > Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 752 bytes --] Hi all, After merging the akpm-current tree, yesterday's linux-next build (htmldocs) produced this warning: Documentation/admin-guide/sysctl/kernel.rst:798: WARNING: Malformed table. Text in column margin in table line 7. ===== ============================================ bit 0 print all tasks info bit 1 print system memory info bit 2 print timer info bit 3 print locks info if ``CONFIG_LOCKDEP`` is on bit 4 print ftrace buffer bit 5: print all printk messages in buffer bit 6: print all CPUs backtrace (if available in the arch) ===== ============================================ Introduced by commit 658a6ba2a287 ("panic: add option to dump all CPUs backtraces in panic_print") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 821 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (htmldocs) produced this warning: Documentation/admin-guide/sysctl/kernel.rst:798: WARNING: Malformed table. Text in column margin in table line 7. ===== ============================================ bit 0 print all tasks info bit 1 print system memory info bit 2 print timer info bit 3 print locks info if ``CONFIG_LOCKDEP`` is on bit 4 print ftrace buffer bit 5: print all printk messages in buffer bit 6: print all CPUs backtrace (if available in the arch) ===== ============================================ Introduced by commits 934d51cad60c ("docs: sysctl/kernel: add missing bit to panic_print") addc64999934 ("panic: add option to dump all CPUs backtraces in panic_print") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 540 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (htmldocs) produced this warning: Documentation/admin-guide/sysctl/kernel.rst:603: WARNING: Malformed table. Text in column margin in table line 2. = ================================= 0x0 NUMA_BALANCING_DISABLED 0x1 NUMA_BALANCING_NORMAL 0x2 NUMA_BALANCING_MEMORY_TIERING = ================================= Introduced by commit 49ec6eb41c49 ("NUMA balancing: optimize page placement for memory tiering system") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Wed, 2 Feb 2022 14:54:37 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (htmldocs)
> produced this warning:
>
> Documentation/admin-guide/sysctl/kernel.rst:603: WARNING: Malformed table.
> Text in column margin in table line 2.
>
> = =================================
> 0x0 NUMA_BALANCING_DISABLED
> 0x1 NUMA_BALANCING_NORMAL
> 0x2 NUMA_BALANCING_MEMORY_TIERING
> = =================================
>
> Introduced by commit
>
> 49ec6eb41c49 ("NUMA balancing: optimize page placement for memory tiering system")
I assume this fixes? (With gratuitous grammar fixes)
--- a/Documentation/admin-guide/sysctl/kernel.rst~numa-balancing-optimize-page-placement-for-memory-tiering-system-fix
+++ a/Documentation/admin-guide/sysctl/kernel.rst
@@ -595,14 +595,14 @@ Documentation/admin-guide/kernel-paramet
numa_balancing
==============
-Enables/disables and configure automatic page fault based NUMA memory
-balancing. Memory is moved automatically to nodes that access it
-often. The value to set can be the result to OR the following,
+Enables/disables and configures automatic page fault based NUMA memory
+balancing. Memory is moved automatically to nodes that access it often.
+The value to set can be the result of ORing the following,
= =================================
-0x0 NUMA_BALANCING_DISABLED
-0x1 NUMA_BALANCING_NORMAL
-0x2 NUMA_BALANCING_MEMORY_TIERING
+0 NUMA_BALANCING_DISABLED
+1 NUMA_BALANCING_NORMAL
+2 NUMA_BALANCING_MEMORY_TIERING
= =================================
Or NUMA_BALANCING_NORMAL to optimize page placement among different
_
On 2/3/22 15:06, Andrew Morton wrote: > On Wed, 2 Feb 2022 14:54:37 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > >> Hi all, >> >> After merging the akpm-current tree, today's linux-next build (htmldocs) >> produced this warning: >> >> Documentation/admin-guide/sysctl/kernel.rst:603: WARNING: Malformed table. >> Text in column margin in table line 2. >> >> = ================================= >> 0x0 NUMA_BALANCING_DISABLED >> 0x1 NUMA_BALANCING_NORMAL >> 0x2 NUMA_BALANCING_MEMORY_TIERING >> = ================================= >> >> Introduced by commit >> >> 49ec6eb41c49 ("NUMA balancing: optimize page placement for memory tiering system") > > I assume this fixes? (With gratuitous grammar fixes) > Looks good. --- a/Documentation/admin-guide/sysctl/kernel.rst~numa-balancing-optimize-page-placement-for-memory-tiering-system-fix > +++ a/Documentation/admin-guide/sysctl/kernel.rst > @@ -595,14 +595,14 @@ Documentation/admin-guide/kernel-paramet > numa_balancing > ============== > > -Enables/disables and configure automatic page fault based NUMA memory > -balancing. Memory is moved automatically to nodes that access it > -often. The value to set can be the result to OR the following, > +Enables/disables and configures automatic page fault based NUMA memory > +balancing. Memory is moved automatically to nodes that access it often. > +The value to set can be the result of ORing the following, except for that ending comma... > > = ================================= > -0x0 NUMA_BALANCING_DISABLED > -0x1 NUMA_BALANCING_NORMAL > -0x2 NUMA_BALANCING_MEMORY_TIERING > +0 NUMA_BALANCING_DISABLED > +1 NUMA_BALANCING_NORMAL > +2 NUMA_BALANCING_MEMORY_TIERING > = ================================= > > Or NUMA_BALANCING_NORMAL to optimize page placement among different > _ > Thanks. -- ~Randy
[-- Attachment #1: Type: text/plain, Size: 551 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: fs/proc/task_mmu.c: In function 'pagemap_pmd_range': fs/proc/task_mmu.c:1444:14: warning: unused variable 'migration' [-Wunused-variable] 1444 | bool migration = false; | ^~~~~~~~~ Introduced by commit 78cff485ae77 ("fs-proc-task_mmuc-dont-read-mapcount-for-migration-entry-v4") "migration" is only used when CONFIG_TRANSPARENT_HUGEPAGE is defined. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 418 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (htmldocs) produced this warning: Documentation/admin-guide/sysctl/kernel.rst:603: WARNING: Inconsistent literal block quoting. Maybe introduced or exposed by commit 68d17e593eb9 ("numa-balancing-optimize-page-placement-for-memory-tiering-system-fix-fix") I am not clear what the warning means. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Stephen Rothwell <sfr@canb.auug.org.au> writes: > Hi all, > > After merging the akpm-current tree, today's linux-next build (htmldocs) > produced this warning: > > Documentation/admin-guide/sysctl/kernel.rst:603: WARNING: Inconsistent literal block quoting. > > Maybe introduced or exposed by commit > > 68d17e593eb9 ("numa-balancing-optimize-page-placement-for-memory-tiering-system-fix-fix") > > I am not clear what the warning means. Hi, Stephen, Found this is a restructuredtext format issue, the following patch fixes it for me. Best Regards, Huang, Ying -------------------------------------8<------------------------------------------- From fb8b9aa5cbf49d37950d04fc808f464589c7e344 Mon Sep 17 00:00:00 2001 From: Huang Ying <ying.huang@intel.com> Date: Wed, 9 Feb 2022 16:04:11 +0800 Subject: [PATCH] numa-balancing-optimize-page-placement-for-memory-tiering-system-fix-fix-fix Fix the following warnings of `make htmldocs`, Documentation/admin-guide/sysctl/kernel.rst:603: WARNING: Inconsistent literal block quoting. --- Documentation/admin-guide/sysctl/kernel.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 078e1aff4adc..59c3b4ce37cd 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -597,7 +597,7 @@ numa_balancing Enables/disables and configures automatic page fault based NUMA memory balancing. Memory is moved automatically to nodes that access it often. -The value to set can be the result of ORing the following:: +The value to set can be the result of ORing the following: = ================================= 0 NUMA_BALANCING_DISABLED -- 2.30.2
[-- Attachment #1: Type: text/plain, Size: 1007 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (i386 defconfig) produced this warning: WARNING: unmet direct dependencies detected for ARCH_HAS_NONLEAF_PMD_YOUNG Depends on [n]: PGTABLE_LEVELS [=2]>2 Selected by [y]: - X86 [=y] WARNING: unmet direct dependencies detected for ARCH_HAS_NONLEAF_PMD_YOUNG Depends on [n]: PGTABLE_LEVELS [=2]>2 Selected by [y]: - X86 [=y] WARNING: unmet direct dependencies detected for ARCH_HAS_NONLEAF_PMD_YOUNG Depends on [n]: PGTABLE_LEVELS [=2]>2 Selected by [y]: - X86 [=y] WARNING: unmet direct dependencies detected for ARCH_HAS_NONLEAF_PMD_YOUNG Depends on [n]: PGTABLE_LEVELS [=2]>2 Selected by [y]: - X86 [=y] WARNING: unmet direct dependencies detected for ARCH_HAS_NONLEAF_PMD_YOUNG Depends on [n]: PGTABLE_LEVELS [=2]>2 Selected by [y]: - X86 [=y] Introduced by commit 7613417c58a8 ("mm: x86: add CONFIG_ARCH_HAS_NONLEAF_PMD_YOUNG") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Wed, Apr 13, 2022 at 03:15:13PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the akpm-current tree, today's linux-next build (i386 > defconfig) produced this warning: > > WARNING: unmet direct dependencies detected for ARCH_HAS_NONLEAF_PMD_YOUNG > Depends on [n]: PGTABLE_LEVELS [=2]>2 > Selected by [y]: > - X86 [=y] > > Introduced by commit > > 7613417c58a8 ("mm: x86: add CONFIG_ARCH_HAS_NONLEAF_PMD_YOUNG") Sorry about the hassle. I'll fix it up in the next version. Meanwhile, mind applying this so that it doesn't block your progress? Thanks. diff --git a/arch/Kconfig b/arch/Kconfig index c626bed3553d..1f0f39262d84 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -1380,7 +1380,6 @@ config HAVE_ARCH_NODE_DEV_GROUP config ARCH_HAS_NONLEAF_PMD_YOUNG bool - depends on PGTABLE_LEVELS > 2 help Architectures that select this option are capable of setting the accessed bit in non-leaf PMD entries when using them as part of linear diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 42c84e1ad73f..a2110f3c3209 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -86,7 +86,7 @@ config X86 select ARCH_HAS_PMEM_API if X86_64 select ARCH_HAS_PTE_DEVMAP if X86_64 select ARCH_HAS_PTE_SPECIAL - select ARCH_HAS_NONLEAF_PMD_YOUNG + select ARCH_HAS_NONLEAF_PMD_YOUNG if PGTABLE_LEVELS > 2 select ARCH_HAS_UACCESS_FLUSHCACHE if X86_64 select ARCH_HAS_COPY_MC if X86_64 select ARCH_HAS_SET_MEMORY
[-- Attachment #1: Type: text/plain, Size: 329 bytes --] Hi all, After merging the akpm-current tree, today's linux-next build (htmldocs) produced this warning: lib/maple_tree.c:5578: warning: Function parameter or member 'gfp' not described in 'mas_preallocate' Introduced by commit 00d332902d28 ("Maple Tree: add new data structure") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 476 bytes --] * Stephen Rothwell <sfr@canb.auug.org.au> [220427 02:41]: > Hi all, > > After merging the akpm-current tree, today's linux-next build (htmldocs) > produced this warning: > > lib/maple_tree.c:5578: warning: Function parameter or member 'gfp' not described in 'mas_preallocate' > > Introduced by commit > > 00d332902d28 ("Maple Tree: add new data structure") Hi Stephen, Here is a patch to add the missing parameter to the documentation. Thanks, Liam [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-maple_tree-Fix-mas_store_prealloc-documentation.patch --] [-- Type: text/x-diff; name="0001-maple_tree-Fix-mas_store_prealloc-documentation.patch", Size: 892 bytes --] From c7446bac64d59eb26cbf500cc035d6c50e5260fb Mon Sep 17 00:00:00 2001 From: "Liam R. Howlett" <Liam.Howlett@oracle.com> Date: Wed, 27 Apr 2022 10:13:52 -0400 Subject: [PATCH] maple_tree: Fix mas_store_prealloc() documentation Add gfp flags to the docs Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com> --- lib/maple_tree.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/maple_tree.c b/lib/maple_tree.c index 75fd119f8224..c7b7a10b15d5 100644 --- a/lib/maple_tree.c +++ b/lib/maple_tree.c @@ -5571,6 +5571,7 @@ void mas_store_prealloc(struct ma_state *mas, void *entry) * mas_preallocate() - Preallocate enough nodes for a store operation * @mas: The maple state * @entry: The entry that will be stored + * @gfp: The GFP_FLAGS to use for allocations. * * Return: 0 on success, -ENOMEM if memory could not be allocated. */ -- 2.35.1