Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp624917rdd; Tue, 9 Jan 2024 14:46:04 -0800 (PST) X-Google-Smtp-Source: AGHT+IGD493hni0ILfTsnhJVPlwkCRHQyLEVCZxhFNFJWn8FGvanM+GnI5YqQ2h9DuNbzYdCcMTz X-Received: by 2002:a05:6870:2303:b0:204:ce:bc01 with SMTP id w3-20020a056870230300b0020400cebc01mr228018oao.23.1704840364287; Tue, 09 Jan 2024 14:46:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704840364; cv=none; d=google.com; s=arc-20160816; b=D5R/xzg3tFV5BHAYbysCD9eobrlXp+isguBxdTKX0svA2Lg6Aq5Vj2ispGoZ8joEAJ KI2TI3qsHJMKRidqfSncMB8wQ9CZ4pkivrrxg8QMVNE1sRBgAi8PKklSF7Tvj9waZFFK E/Bsp1M2n6JsQm5ldJA5HDjQ6fujgQR/6MyR4rf2rsmFsTYOJf354dt08XCDXVu1jbae sk9MZnSJC25lYld/dR7uS7K8gPHOKbbBR6YXQuaUKwoOTN4+TJ0OGpaXKz64TVowz0vK xFXaTx6brWvGKiqt3KWNAOLBV2BoROvzAXBdOgZixdeIBtHD991O/5ZqRI0IQR4M4aB3 KjKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=QU+MbqxwawRHrsDEYgSFVVAuqdSKVKukhQPKztBORYE=; fh=4ceXApwBJlVB4VWUjswkDXwoamMOBK/8ogSoVNjCRQ4=; b=zB6NoUUb1R+TZp04c292U9TN6j0wR8NcQJ7Aq4ps7qIpzZKuecyzyxgiCZiv8I0vrF oBqtrDb08UyBeP+U8SmvcukVR1aOQ2JTJZqPLZ3FSAPNSR0KMJO6soHjNckRkIJzfCUh SMesWGG0RiuWwtEXyn1mbVvAXHPY3WT3aZz7QZwENVJ+dMaOt6BUAi+zCP9EeA0XdQHz FhqucIuiCbZiVHT3p206wXpfq3lXviE9awkS4i4zGr8i5lkI5h8G9RshK1HwXllFuNkA 7IpNXJ+RzsmHhUbxoEhCjak3O54zZ5aMOaHVOFSNUN2+yTbArziFPwDQCwTJmecjwQmU lipA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=uI6KmVRw; spf=pass (google.com: domain of linux-kernel+bounces-21484-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-21484-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id a10-20020a655c8a000000b005ce0b38a6dbsi2232966pgt.580.2024.01.09.14.46.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jan 2024 14:46:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-21484-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=uI6KmVRw; spf=pass (google.com: domain of linux-kernel+bounces-21484-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-21484-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id CEFDF28872F for ; Tue, 9 Jan 2024 22:46:03 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 87A323E463; Tue, 9 Jan 2024 22:45:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uI6KmVRw" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AAD723DB8A for ; Tue, 9 Jan 2024 22:45:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2AA5CC433C7; Tue, 9 Jan 2024 22:45:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1704840357; bh=jFPT0HYrVFg+hjPzkZEL5Czqvymb2WT3tD4gy/UQ8m0=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=uI6KmVRwCQAfa4/JWMTJqrNBWYE+NxcP1CYQsUold1BMA1s5wc1CZY/yTLoRQm3va F0PmrlTstgqUR/Jkb9qQIdrmEUEwVYR33ZY+FW5WoL4p1WpHefiMAE+VRYEQtwC4yM TUX5JxWYpszU7YQ3VUEnzpObsM+i9FGIzG7e2eevlnkgVW6LjBfZcZOlQyNHYFF39K /6hT4djTTR/VocbTA+jy4lTY4cJLnmObeK82/IV3xXlGKdKCVlW0OF/WzK3ZAryd+i rigKZZA/rqIczdtioYYpIY4iFqHD2gxE0LuRV72VoeecGyNjcRnhiz57sBXBdRmHDE Z5tIU0RIigXKA== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id B9CE1CE042E; Tue, 9 Jan 2024 14:45:56 -0800 (PST) Date: Tue, 9 Jan 2024 14:45:56 -0800 From: "Paul E. McKenney" To: Stephen Rothwell Cc: Lucas De Marchi , Stephen Rothwell , lucas.dimarchi@intel.com, linux-kernel@vger.kernel.org, intel-xe@lists.freedesktop.org Subject: Re: [BUG] allmodconfig build error in next-20240108 Message-ID: Reply-To: paulmck@kernel.org References: <45ad1d0f-a10f-483e-848a-76a30252edbe@paulmck-laptop> <20240109095757.1313b2d9@canb.auug.org.au> <341a4955-0cdd-48d0-bfbd-cc6f6f09df37@paulmck-laptop> <20240110081155.48bb0cbd@oak> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240110081155.48bb0cbd@oak> On Wed, Jan 10, 2024 at 08:11:55AM +1100, Stephen Rothwell wrote: > Hi Lucas, > > On Tue, 9 Jan 2024 10:58:40 -0600 Lucas De Marchi wrote: > > > > On Mon, Jan 08, 2024 at 03:15:23PM -0800, Paul E. McKenney wrote: > > >On Tue, Jan 09, 2024 at 09:57:57AM +1100, Stephen Rothwell wrote: > > >> Hi Paul, > > >> > > >> On Mon, 8 Jan 2024 13:33:36 -0800 "Paul E. McKenney" wrote: > > >> > > > >> > Recent -next trees get the following build error for allmodconfig builds: > > >> > > > >> > ------------------------------------------------------------------------ > > >> > > > >> > drivers/gpu/drm/xe/xe_gt_pagefault.c: In function ‘xe_guc_pagefault_handler’: > > >> > ./include/linux/fortify-string.h:57:33: error: writing 16 bytes into a region of  size 0 [-Werror=stringop-overflow=] > > >> >    57 | #define __underlying_memcpy     __builtin_memcpy > > >> >       |                                 ^ > > >> > ./include/linux/fortify-string.h:644:9: note: in expansion of macro ‘__underlying_memcpy’ > > >> >   644 |         __underlying_##op(p, q, __fortify_size); \ > > >> >       |         ^~~~~~~~~~~~~ > > >> > ./include/linux/fortify-string.h:689:26: note: in expansion of macro ‘__fortify_memcpy_chk’ > > >> >   689 | #define memcpy(p, q, s)  __fortify_memcpy_chk(p, q, s, \ > > >> >       |                          ^~~~~~~~~~~~~~~~~~~~ > > >> > drivers/gpu/drm/xe/xe_gt_pagefault.c:340:17: note: in expansion of macro ‘memcpy’ > > >> >   340 |                 memcpy(pf_queue->data + pf_queue->tail, msg, len * sizeof(u32)); > > >> >       |                 ^~~~~~ > > >> > In file included from drivers/gpu/drm/xe/xe_device_types.h:17, > > >> >                  from drivers/gpu/drm/xe/xe_vm_types.h:16, > > >> >                  from drivers/gpu/drm/xe/xe_bo.h:13, > > >> >                  from drivers/gpu/drm/xe/xe_gt_pagefault.c:16: > > >> > drivers/gpu/drm/xe/xe_gt_types.h:102:25: note: at offset [1144, 265324] into destination object ‘tile’ of size 8 > > >> >   102 |         struct xe_tile *tile; > > >> >       | > > >> > > >> Which architecture? What compiler and version? Anything special in your build > > >> setup? I do x86_64 allmodconfig builds all day with gcc v13.2 and I don't see > > >> this failure. > > > > > >Good point! > > > > > >I am using gcc version 11.3.1 20230605 (Red Hat 11.4.1-2) on x86_64. > > >I see the same behavior on gcc version 8.5.0, which for all I know might > > >be too old. > > > > I could reproduce it with allmodconfig and gcc 11.4.1 from rockylinux, > > but not with gcc 9.3 or 12.3. Also it's not reproduced with gcc 11.4.1 > > when using defconfig + CONFIG_DRM_XE (even if -Wstringop-overflow is > > still added). > > > > I don't see a bug in the code, even if it inverts the head/tail > > convention. > > > > Searching around showed this which may be relevant: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101854 > > At least I can reproduce the same issue as in the snippet provided > > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101854#c7) with the buggy > > compiler. > > > > So, maybe the best thing to do for now is to disable -Wstringop-overflow > > for gcc < 12? > > > > > > ------8<----- > > diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile > > index 6952da8979ea..0433a3c6cbfd 100644 > > --- a/drivers/gpu/drm/xe/Makefile > > +++ b/drivers/gpu/drm/xe/Makefile > > @@ -17,7 +17,7 @@ subdir-ccflags-y += $(call cc-option, -Wunused-const-variable) > > subdir-ccflags-y += $(call cc-option, -Wpacked-not-aligned) > > subdir-ccflags-y += $(call cc-option, -Wformat-overflow) > > subdir-ccflags-y += $(call cc-option, -Wformat-truncation) > > -subdir-ccflags-y += $(call cc-option, -Wstringop-overflow) > > +subdir-ccflags-$(call gcc-min-version, 120000) += $(call cc-option, -Wstringop-overflow) > > subdir-ccflags-y += $(call cc-option, -Wstringop-truncation) > > # The following turn off the warnings enabled by -Wextra > > ifeq ($(findstring 2, $(KBUILD_EXTRA_WARN)),) > > ------8<----- This I did, thank you! > > and if we are tweaking the warnings, then do similarly in scripts/Makefile.extrawarn > > so it doesn't show up again with W=1 builds. Thoughts? But I failed to find anything similar in scripts/Makefile.extrawarn, so the failure persists. > The top level Makefile (in linux-next) has: > > #Currently, disable -Wstringop-overflow for GCC 11, globally. > KBUILD_CFLAGS-$(CONFIG_CC_NO_STRINGOP_OVERFLOW) += $(call cc-option, -Wno-stringop-overflow) > KBUILD_CFLAGS-$(CONFIG_CC_STRINGOP_OVERFLOW) += $(call cc-option, -Wstringop-overflow) > > and init/Kconfig has: > > # Currently, disable -Wstringop-overflow for GCC 11, globally. > config GCC11_NO_STRINGOP_OVERFLOW > def_bool y > > config CC_NO_STRINGOP_OVERFLOW > bool > default y if CC_IS_GCC && GCC_VERSION >= 110000 && GCC_VERSION < 120000 && GCC11_NO_STRINGOP_OVERFLOW > > config CC_STRINGOP_OVERFLOW > bool > default y if CC_IS_GCC && !CC_NO_STRINGOP_OVERFLOW > > So, what does "grep -E '(STRINGOP_OVERFLOW|GCC_VERSION)' .config" show for your > breaking build(s)? Here you go! CONFIG_GCC_VERSION=110400 CONFIG_GCC11_NO_STRINGOP_OVERFLOW=y CONFIG_CC_NO_STRINGOP_OVERFLOW=y Thanx, Paul