From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,sfr@canb.auug.org.au,andreyknvl@gmail.com,elver@google.com,akpm@linux-foundation.org
Subject: [folded-merged] stackdepot-use-variable-size-records-for-non-evictable-entries-fix.patch removed from -mm tree
Date: Fri, 23 Feb 2024 17:21:25 -0800 [thread overview]
Message-ID: <20240224012126.797C3C433C7@smtp.kernel.org> (raw)
The quilt patch titled
Subject: stackdepot: fix -Wstringop-overflow warning
has been removed from the -mm tree. Its filename was
stackdepot-use-variable-size-records-for-non-evictable-entries-fix.patch
This patch was dropped because it was folded into stackdepot-use-variable-size-records-for-non-evictable-entries.patch
------------------------------------------------------
From: Marco Elver <elver@google.com>
Subject: stackdepot: fix -Wstringop-overflow warning
Date: Thu, 1 Feb 2024 10:04:30 +0100
Since 113a61863ecb ("Makefile: Enable -Wstringop-overflow globally")
string overflow checking is enabled by default. Within stackdepot, the
compiler (GCC 13.2.0) assumes that a multiplication overflow may be
possible and flex_array_size() can return SIZE_MAX (4294967295 on
32-bit), resulting in this warning:
In function 'depot_alloc_stack',
inlined from 'stack_depot_save_flags' at lib/stackdepot.c:688:4:
arch/x86/include/asm/string_32.h:150:25: error: '__builtin_memcpy' specified bound 4294967295 exceeds maximum object size 2147483647 [-Werror=stringop-overflow=]
150 | #define memcpy(t, f, n) __builtin_memcpy(t, f, n)
| ^~~~~~~~~~~~~~~~~~~~~~~~~
lib/stackdepot.c:459:9: note: in expansion of macro 'memcpy'
459 | memcpy(stack->entries, entries, flex_array_size(stack, entries, nr_entries));
| ^~~~~~
cc1: all warnings being treated as errors
This is due to depot_alloc_stack() accepting an 'int nr_entries' which
could be negative without deeper analysis of callers.
The call to depot_alloc_stack() from stack_depot_save_flags(), however,
only passes in its nr_entries which is unsigned int. Fix the warning by
switching depot_alloc_stack()'s nr_entries to also be unsigned.
Link: https://lore.kernel.org/all/20240201135747.18eca98e@canb.auug.org.au/
Link: https://lkml.kernel.org/r/20240201090434.1762340-1-elver@google.com
Link: https://lore.kernel.org/all/CABXGCsOzpRPZGg23QqJAzKnqkZPKzvieeg=W7sgjgi3q0pBo0g@mail.gmail.com/
Fixes: d869d3fb362c ("stackdepot: use variable size records for non-evictable entries")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Marco Elver <elver@google.com>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/stackdepot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/lib/stackdepot.c~stackdepot-use-variable-size-records-for-non-evictable-entries-fix
+++ a/lib/stackdepot.c
@@ -420,7 +420,7 @@ static inline size_t depot_stack_record_
/* Allocates a new stack in a stack depot pool. */
static struct stack_record *
-depot_alloc_stack(unsigned long *entries, int nr_entries, u32 hash, depot_flags_t flags, void **prealloc)
+depot_alloc_stack(unsigned long *entries, unsigned int nr_entries, u32 hash, depot_flags_t flags, void **prealloc)
{
struct stack_record *stack = NULL;
size_t record_size;
_
Patches currently in -mm which might be from elver@google.com are
stackdepot-use-variable-size-records-for-non-evictable-entries.patch
kasan-revert-eviction-of-stack-traces-in-generic-mode.patch
reply other threads:[~2024-02-24 1:21 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240224012126.797C3C433C7@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=elver@google.com \
--cc=mm-commits@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.