Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp4136716pxb; Mon, 27 Sep 2021 10:07:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxQ1o/5mEfWn0vyuMwepVXnPnYNeJhweYBDKqlwzVsjCz5eq2BCQ2Hzqn5iQZfaj0pDl7It X-Received: by 2002:a17:902:e8ce:b0:132:b140:9540 with SMTP id v14-20020a170902e8ce00b00132b1409540mr1009971plg.28.1632762476238; Mon, 27 Sep 2021 10:07:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632762476; cv=none; d=google.com; s=arc-20160816; b=ssEJr6S03AYH3NrN+OPmNa5LgC/AxyRapFm46k1UuF0FFpWPoHKTWENl8U5ARoBZrx uJUEZb2ZNd4XWelNVeddhXJe2Wt95J+MlK1PI8VldcWcyIEUrIEWmQtoTZsWdKehWHsc +pnaFnUZGpsKBnCPfrO9l9fWnpeYcd+SyMK1HU4SaZ8ZW+2pi3ZghyZvsXNjItNEKcUj itL49FJZhTFeTelduwOM2Zop6Zar91XKX9dA998p9B2tV1diogHEvCGlt53ePwowee3T MUiELg+xJ3jbLPcvv7Uv7Ou26Ib97fTDdw+3aDgZpEjkWKPsExCjieqCryKaw3M0XYAF uxKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=48jVMHX41/ps9LEJuFvc7h4CuN4X3EA23x1A3hsMmf8=; b=BNJ1oulNWqQaBGp27pySW7ikDgcZfXa5ZCFS+DGa57Fp+EI/0Al3vygwDEl2iQN4qA PPX3D+TqEnHRVoE2pEOROjTtnuGxYAltX+LoXDBj73lZzzjyX7N37+r5hFmoMJkksYBC 0sGo1Z5wQlVjJAN2tvx22b362pYdSkHAqDx8kiRpG7zG7lmO5W6LL+Bp6rHlYxaO/Zwx Ok/XR9aPAM2j9jMgEE4dzNmTGAB0YtBU406dalurqP1sQJ6ISPaK1DPTg/TdYu217TDi 7uh2IPo7SMbTKqc9asETPmlBXZRITnizS0TeGoFqB4AjN4x7GmS0plvCrtWXaAdlIbkd i7nw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=t5UaLGU1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t11si116095pjm.9.2021.09.27.10.07.43; Mon, 27 Sep 2021 10:07:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=t5UaLGU1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236210AbhI0RIb (ORCPT + 99 others); Mon, 27 Sep 2021 13:08:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:47542 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235905AbhI0RH1 (ORCPT ); Mon, 27 Sep 2021 13:07:27 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4BAE261205; Mon, 27 Sep 2021 17:05:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1632762349; bh=Ygtg/+XzXhDufM+0SYgjdXnmsWYJkslIlLUbEy1s+Hg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=t5UaLGU1jzv/OEQ1J4Hv82MkoVESEz0tT0Eap47E4e9hrYxTiV2hzBG3Pst/vIg0V W2E2jpwd3E4BHP/Llw5F/AXMci36hjHoKkgnThp7ILhe8YRJmpXCGLjvdjvCbZDoXr fQM/g4crATOWWBXoILn6yR8dcPs3BBepP+eRj268= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Guenter Roeck , "David S. Miller" , Linus Torvalds , Sasha Levin Subject: [PATCH 5.4 57/68] sparc: avoid stringop-overread errors Date: Mon, 27 Sep 2021 19:02:53 +0200 Message-Id: <20210927170221.942033905@linuxfoundation.org> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20210927170219.901812470@linuxfoundation.org> References: <20210927170219.901812470@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Linus Torvalds [ Upstream commit fc7c028dcdbfe981bca75d2a7b95f363eb691ef3 ] The sparc mdesc code does pointer games with 'struct mdesc_hdr', but didn't describe to the compiler how that header is then followed by the data that the header describes. As a result, gcc is now unhappy since it does stricter pointer range tracking, and doesn't understand about how these things work. This results in various errors like: arch/sparc/kernel/mdesc.c: In function ‘mdesc_node_by_name’: arch/sparc/kernel/mdesc.c:647:22: error: ‘strcmp’ reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread] 647 | if (!strcmp(names + ep[ret].name_offset, name)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ which are easily avoided by just describing 'struct mdesc_hdr' better, and making the node_block() helper function look into that unsized data[] that follows the header. This makes the sparc64 build happy again at least for my cross-compiler version (gcc version 11.2.1). Link: https://lore.kernel.org/lkml/CAHk-=wi4NW3NC0xWykkw=6LnjQD6D_rtRtxY9g8gQAJXtQMi8A@mail.gmail.com/ Cc: Guenter Roeck Cc: David S. Miller Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- arch/sparc/kernel/mdesc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/sparc/kernel/mdesc.c b/arch/sparc/kernel/mdesc.c index 8e645ddac58e..30f171b7b00c 100644 --- a/arch/sparc/kernel/mdesc.c +++ b/arch/sparc/kernel/mdesc.c @@ -39,6 +39,7 @@ struct mdesc_hdr { u32 node_sz; /* node block size */ u32 name_sz; /* name block size */ u32 data_sz; /* data block size */ + char data[]; } __attribute__((aligned(16))); struct mdesc_elem { @@ -612,7 +613,7 @@ EXPORT_SYMBOL(mdesc_get_node_info); static struct mdesc_elem *node_block(struct mdesc_hdr *mdesc) { - return (struct mdesc_elem *) (mdesc + 1); + return (struct mdesc_elem *) mdesc->data; } static void *name_block(struct mdesc_hdr *mdesc) -- 2.33.0