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 X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31180C433E0 for ; Tue, 9 Jun 2020 00:42:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 12DCC20737 for ; Tue, 9 Jun 2020 00:42:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591663342; bh=dCH3TA1DCiaFdQ1F7bwY/Y5DKvvY+zxPYFzhURPkjUM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=hfsR8Uuz4xve67Dx1CYpE6ef2xbR3g0/b2XSTNjLbQXt+r4abIqn/c2nuMBGvMvIp 8ISQL5p4Ywuafe/bgI6NpLiuKHWpw1a4l/evIMc/eJCOWBPWk5met+zWtF4YSUOgFk mr7iolWArqJYP6GBKA+WBVU907YADyqhduIeaQ0Q= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729129AbgFHXMa (ORCPT ); Mon, 8 Jun 2020 19:12:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:60008 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729107AbgFHXM3 (ORCPT ); Mon, 8 Jun 2020 19:12:29 -0400 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6F2D120897; Mon, 8 Jun 2020 23:12:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591657949; bh=dCH3TA1DCiaFdQ1F7bwY/Y5DKvvY+zxPYFzhURPkjUM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NQ+tn1mlFxMw1n+s0+rRdP9kEDIVtLaQF9lQEiS6hdBw+O8J1cJMg2d9RI2ht/L7V uxuRcTy6KkNmmgGZeckd37wZUiaO9CULQD7MMK6JRW1FtTWUyMOv9vcqQkIgBuN+Oy w2TTiK1jMkB0pVJpLRouUPh+3T7TWcHvYnDDMhMI= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Linus Torvalds , Greg Kroah-Hartman , linux-kbuild@vger.kernel.org Subject: [PATCH AUTOSEL 5.6 014/606] gcc-10: disable 'restrict' warning for now Date: Mon, 8 Jun 2020 19:02:19 -0400 Message-Id: <20200608231211.3363633-14-sashal@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200608231211.3363633-1-sashal@kernel.org> References: <20200608231211.3363633-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Linus Torvalds commit adc71920969870dfa54e8f40dac8616284832d02 upstream. gcc-10 now warns about passing aliasing pointers to functions that take restricted pointers. That's actually a great warning, and if we ever start using 'restrict' in the kernel, it might be quite useful. But right now we don't, and it turns out that the only thing this warns about is an idiom where we have declared a few functions to be "printf-like" (which seems to make gcc pick up the restricted pointer thing), and then we print to the same buffer that we also use as an input. And people do that as an odd concatenation pattern, with code like this: #define sysfs_show_gen_prop(buffer, fmt, ...) \ snprintf(buffer, PAGE_SIZE, "%s"fmt, buffer, __VA_ARGS__) where we have 'buffer' as both the destination of the final result, and as the initial argument. Yes, it's a bit questionable. And outside of the kernel, people do have standard declarations like int snprintf( char *restrict buffer, size_t bufsz, const char *restrict format, ... ); where that output buffer is marked as a restrict pointer that cannot alias with any other arguments. But in the context of the kernel, that 'use snprintf() to concatenate to the end result' does work, and the pattern shows up in multiple places. And we have not marked our own version of snprintf() as taking restrict pointers, so the warning is incorrect for now, and gcc picks it up on its own. If we do start using 'restrict' in the kernel (and it might be a good idea if people find places where it matters), we'll need to figure out how to avoid this issue for snprintf and friends. But in the meantime, this warning is not useful. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Makefile b/Makefile index 8584003bfbca..955b57a8ec15 100644 --- a/Makefile +++ b/Makefile @@ -862,6 +862,9 @@ KBUILD_CFLAGS += $(call cc-disable-warning, zero-length-bounds) KBUILD_CFLAGS += $(call cc-disable-warning, array-bounds) KBUILD_CFLAGS += $(call cc-disable-warning, stringop-overflow) +# Another good warning that we'll want to enable eventually +KBUILD_CFLAGS += $(call cc-disable-warning, restrict) + # Enabled with W=2, disabled by default as noisy KBUILD_CFLAGS += $(call cc-disable-warning, maybe-uninitialized) -- 2.25.1