From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1CAEDC47DDF for ; Thu, 1 Feb 2024 08:53:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5CBF66B0074; Thu, 1 Feb 2024 03:53:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 57C2F6B0075; Thu, 1 Feb 2024 03:53:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 444E56B0078; Thu, 1 Feb 2024 03:53:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 369376B0074 for ; Thu, 1 Feb 2024 03:53:41 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id CED781A08EC for ; Thu, 1 Feb 2024 08:53:40 +0000 (UTC) X-FDA: 81742621800.27.A6AFD2E Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) by imf24.hostedemail.com (Postfix) with ESMTP id 326B218000A for ; Thu, 1 Feb 2024 08:53:39 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=4UQEBmBU; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of elver@google.com designates 209.85.217.48 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706777619; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9X/QBAjvJKlfeOxD/oXT29ra0R70AXdnTz+IJPfF+Ec=; b=2gw9MogM/5i+ygvufbAk1E3PneRsUBV5sxZG4ayOyhL2XwOCX1Z43ZPEWR+eXjzkI+ggnW lqt6aryvC/4a8llxuGFYsqemmhQ/lHQR2BD4iKXdILQIiM8ewPJhv7Bu1PZfsJ4lT7weXn +9Ay6/cVUg+4k6nooHgGsVOxKx9V6wI= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=4UQEBmBU; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of elver@google.com designates 209.85.217.48 as permitted sender) smtp.mailfrom=elver@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706777619; a=rsa-sha256; cv=none; b=z3zBLbV+Igd1UrPrJdH6NMAAouQTEVYm8ZNtIvJ0rNaQa+tbtDV7rMYQv7PcRSdaWpdAAE 5W7/krtrjUziaoRrZNJSXbDWMBLhUTjsDPkpRFsL0bRT3cqgiLDHodgfcjIcGmNCIWQmtY WmdU1XIJcPIJ5NHvwc/y71dl12GgOoI= Received: by mail-vs1-f48.google.com with SMTP id ada2fe7eead31-46b35fad293so281021137.1 for ; Thu, 01 Feb 2024 00:53:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706777618; x=1707382418; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9X/QBAjvJKlfeOxD/oXT29ra0R70AXdnTz+IJPfF+Ec=; b=4UQEBmBUXXoPrDMAeY/v4JyD9YfL95oFZMH5XHBJr4XP8WgT15qCvohybdDhu5bvlI pBSGD7+axRBwAEXQHgBMlDCmUjYfKE3PZtuqIXsT71l5S4ajdvq8Unr0L6kHIFk03yxE DgLjr6rToihdJw9Y5aSTHTYLNNjE31wFYyJi4eVwm3W0WqggG4s1RBak1hwpvZeibXq+ c8dOdc3U6lr0aZGAXhJmoBqOCRD4dZILPFkdhNiGypVeFCTgeQtNwWvOvQn6dQkG3gYz qbEfp8RNpF22YDTj00H+PpzY2mfK0fa5gDe63sEHWJFu4qv+5NwGKAnIhfvTA7b5TtZl bPHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706777618; x=1707382418; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9X/QBAjvJKlfeOxD/oXT29ra0R70AXdnTz+IJPfF+Ec=; b=CvBtln1TieuLRBc1WMyiU1xW4RNlYzM8V7UThM7HdH2768CBYtpi96W1uHT8Xz+O/P Fi7ZTB9G6na8HFnIibzrZvPMmVSR84QXFrJNCY2UMoYnV0X2slGoaa/Y8zyV7oK1178m WxK03ZG07NXaXmH75lp7I5M8FgIl/nrjKlNhTORAIBLudZrNI9zaJiSkICYzTBArrNuK CvGH7fl/9j9bqUB6zwkLDf/AHsWqxbEVmAkYF/5o/G1d3wPzDNT7EkFuy39FcWirANnO HdfQ/hk+JMdTKcJ5qXIZbYkBK+SwHLgB5xIdaV18ldLIxQO+DhGdZj2vXysKDqSZUpbR uipg== X-Gm-Message-State: AOJu0YwHRny51pxApfo5pNzK/G2yBUkf6wvlQ0TFu94aOLesKDr5qpDJ XOwIvOpFSi2TvaIkJ7ESzKnCjrolMrB09xIieWdyLi0y30B8n4kIg9hMXXB+balY3JDamzcojMY ZN9Yyp6h4BcTbt6TOPZUFmWOnCtcGiOwNQtqt X-Google-Smtp-Source: AGHT+IGnQ/PU+QeHPHQoIQRSPkvcrHjczMglXbm4uDY0nigyNzDdWVpMlxI8b0RDHD2EKFpFp7aSpvF1C94AADCtkSE= X-Received: by 2002:a05:6102:364:b0:46b:29df:6977 with SMTP id f4-20020a056102036400b0046b29df6977mr4054423vsa.10.1706777618171; Thu, 01 Feb 2024 00:53:38 -0800 (PST) MIME-Version: 1.0 References: <20240201083259.1734865-1-elver@google.com> In-Reply-To: <20240201083259.1734865-1-elver@google.com> From: Marco Elver Date: Thu, 1 Feb 2024 09:52:59 +0100 Message-ID: Subject: Re: [PATCH -mm] stackdepot: do not use flex_array_size() in memcpy() To: elver@google.com, Andrew Morton Cc: Andrey Konovalov , Alexander Potapenko , Dmitry Vyukov , Vlastimil Babka , linux-kernel@vger.kernel.org, linux-mm@kvack.org, kasan-dev@googlegroups.com, Stephen Rothwell , "Gustavo A . R . Silva" , Kees Cook Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 326B218000A X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: eym9ngxbysdwsbt9bzzhya4chn4x7ees X-HE-Tag: 1706777619-928166 X-HE-Meta: U2FsdGVkX189rRAOfQhHEfwgF8aArx2xRSRSRvKNv212y378sU2xcUDhkwsY751E+JCEZntBG7W95ZiRKcqWAsN5Vaos1hDCVsReO4OaeQhKQ0gPzAuYY/Vds8yq5zh9EjKQUXihZUTXtbJ/oMKmA+KMZ8C/ldRjQdj4PHjv8a5FycLUC3F/htxdicd97ujLk2oV+IhW9T7LhO7wDlsumiQN5GahZpanRijFQ4kPokcExIYaVsAlFI/EwFmhKS2bYEflfXNoeA0ba8FMXsqcJA4bViBCvqSe7wVyzHh4MUwrp2p3NXwv0BlJXqD/8lWfczOItxk2olloT8hbWDIIs4TL1A7U19prBgLqYQaZVfshCEG3J2KISDRd8FMO8IHFNKzkcmcaHH1WXn4+RWbCDpIf63Gr0aZDytoc0HlQpXv49Zq2y8i3NZh+QasMxyB0HW5Cmv5M66gdBqUuyhtCKj8CazLB5igrzb/q0ruTVSD05S2o+4Y37msfbklys+qZHO4SDOwZGWeOAf3hgYsx/2aWV7Ng/uoexK9MEXPcaRYYN2kr4cJM5kjIlN6ssh10NAbPxasTHmIJYJBVWP/HUyZi3YPb5PPgmEzBspC05rY6ClB0IPSO48UJ1g9ee2JyMpsWU1e664SZw1n2Jb7yrTLeUwqwL04taQVMneKAuEMrsR2qtLtHxzJRT/0QWwOaY2hPbgvXMfITcDGfzdQ/GhBIZuuj3GH1Xi4/V5/iFW2qo5NFCnigNzT70SfhPxwOUBm6rpJchltN1XBPyWuKZkMSNrGN1femLmNGoBOUJ6f88LJ837ach8vSPxCySYOX1UHX3KLD50H263Vi9Wn09OmC83sk4vi+QTqyrp3kmP5Mawim53caKZ+/Q5HkURQehTAlpK46Apb+mJdO+IwB4wIbMU2tkee53GFNLStBTakrf+s0MJoq3yLnsQsz2ujhVkksaGbZyhs7+dUHQwC Uxs0QURb x9hkBzIiQwoG9cHCyPxmiy0PZzl0BGQH3gkXTGUaxjzLbKFMaojM1i/gYcSOXAw8Ebm8T3imAcym6NR8Mh4yWfw/RbjUuOEkIwKlXN4dqQbFa2/0xgkbSWmMVvl3p2ASRCIhIRU6T3QgwbZuqW7zIdaNOIyKFXpB9A1Y3YYIBMN8PjOAlJ72T9iVQGWcn/9ZD+t+dWhazyuADpVuwveTC8CLx2gQXNWz5ouDdsG4CbklLpB8sXpxwSXCe5DEcfBW+vOYGkyM4Vff6jnzhMlMd08NnH2/xhUTzuKDq3/8T9Pbpx5tt7vAnkZGwv+q+YeHzS8PXE9F81xH3ZqoM82CaUNfsI/KKZVxFn690mAcMJjjTfTcGOTc+MbTBnRmo7bnDuoLbZZzvmIgRoBLG1k27X4jHXv7i2DoQDwQ5VvrCCwYkg3wvyjkyGYrkUKGzxkFgBWtuOPaqWPeReT+eW2pbf3v40YkjuVGBz5lU X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, 1 Feb 2024 at 09:35, Marco Elver wrote: > > Since 113a61863ecb ("Makefile: Enable -Wstringop-overflow globally") > string overflow checking is enabled by default. Unfortunately the > compiler still isn't smart enough to always see that the size will never > overflow. > > Specifically, in stackdepot, we have this before memcpy()'ing a > stacktrace: > > if (nr_entries > CONFIG_STACKDEPOT_MAX_FRAMES) > nr_entries = CONFIG_STACKDEPOT_MAX_FRAMES; > ... > memcpy(stack->entries, entries, flex_array_size(stack, entries, nr_entries)); > > Where 'entries' is an array of unsigned long, and STACKDEPOT_MAX_FRAMES > is 64 by default (configurable up to 256), thus the maximum size in > bytes (on 32-bit) would be 1024. For some reason the compiler (GCC > 13.2.0) assumes that an 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 > > Silence the false positive warning by inlining the multiplication > ourselves. > > Link: https://lore.kernel.org/all/20240201135747.18eca98e@canb.auug.org.au/ > Fixes: d869d3fb362c ("stackdepot: use variable size records for non-evictable entries") > Reported-by: Stephen Rothwell > Signed-off-by: Marco Elver > Cc: Gustavo A. R. Silva > Cc: Kees Cook > --- > lib/stackdepot.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/stackdepot.c b/lib/stackdepot.c > index 8f3b2c84ec2d..e6047f58ad62 100644 > --- a/lib/stackdepot.c > +++ b/lib/stackdepot.c > @@ -456,7 +456,7 @@ depot_alloc_stack(unsigned long *entries, int nr_entries, u32 hash, depot_flags_ Sigh, switching this 'int nr_entries' to 'unsigned int' also fixes it - please disregard this patch.