From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from omta34.uswest2.a.cloudfilter.net (omta34.uswest2.a.cloudfilter.net [35.89.44.33]) (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 5FE92128835 for ; Tue, 26 Mar 2024 02:57:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=35.89.44.33 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711421873; cv=none; b=rb7MMrJiL6W1lu1eZ4uDDxc99sZg+vYcwD1cXb5KyVPpvnuoyRHAlVAd5mR5j9rHJTtNNnwZBhusncNQsce8XeD2+j+4GPg06CsTIgrREiGuRY44NPFExDV5jcfJHmSI6slRjk7YIdypBLS2vbs/ldx+EPv+8aiSucYu2s/ZCT0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711421873; c=relaxed/simple; bh=vX3bVL1HMc4EDAaj7B3gjYlT0mkkt+c/itIyWdTv+VI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=pnoUdoazDtsKYdNphc3g30nuG2gsjJNL1sJGdgQmkv7UmBUue964FVJQjSVVTqBJFdtE0abrXM2dirXGhWm/S9mZnLr531cvKJYPZpWi4Az3kHQKuipmbMLG3wSQhibdP88JPU3SMKkbfkaD3TNdcIJF6qALzL7nA7MTWFzJAOs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=embeddedor.com; spf=pass smtp.mailfrom=embeddedor.com; dkim=pass (2048-bit key) header.d=embeddedor.com header.i=@embeddedor.com header.b=dlh+DXZ0; arc=none smtp.client-ip=35.89.44.33 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=embeddedor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=embeddedor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=embeddedor.com header.i=@embeddedor.com header.b="dlh+DXZ0" Received: from eig-obgw-6010a.ext.cloudfilter.net ([10.0.30.248]) by cmsmtp with ESMTPS id omuGrSm3cHXmAox0TrcQyL; Tue, 26 Mar 2024 02:57:45 +0000 Received: from gator4166.hostgator.com ([108.167.133.22]) by cmsmtp with ESMTPS id ox0Sr7RxEQufZox0SrONIs; Tue, 26 Mar 2024 02:57:44 +0000 X-Authority-Analysis: v=2.4 cv=eK4Vjmp1 c=1 sm=1 tr=0 ts=660239a8 a=1YbLdUo/zbTtOZ3uB5T3HA==:117 a=UtBFqMlDG83dypD0sxEoAQ==:17 a=IkcTkHD0fZMA:10 a=K6JAEmCyrfEA:10 a=wYkD_t78qR0A:10 a=VwQbUJbxAAAA:8 a=yCkJhreVFDLjqfpo9JAA:9 a=QEXdDO2ut3YA:10 a=AjGcO6oz07-iQ99wixmX:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=embeddedor.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=o90u6YTpwASH2e8B6jU5tsJiGz540jLK6rTJxZ74n1E=; b=dlh+DXZ0+HwO8YHOI59tzajiU7 qmQUEJvuedN+ivIXiM+FfIAcXWLstqvZG56435B6bnHtPH5bqkuJ30xQCzNyxhe/qIwjSIIJo5gAb 74tfMHvhcn5K+NTqhs5jPpm7P3AExBIrcQ+mR6q56+/Win8S2npzBx8uELGUPlCRcpKJsPePQFnAB 8uyrn8iUYbR742Q6aWCJNeDen3PvwnqLGKWY111yZWIiwASKIMAwOpUYuDcpNrJLsXrcsi3Lm3669 KoJPufJI4vyGkljBC2rV6wZDaFT0nw3KRh+kVgTJnuMGX6zdeWkKySinxXTUkOqJkvfxafStVBPXm FoboauPg==; Received: from [201.172.174.229] (port=52604 helo=[192.168.15.10]) by gator4166.hostgator.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96.2) (envelope-from ) id 1rox0R-001mui-1e; Mon, 25 Mar 2024 21:57:44 -0500 Message-ID: <5c0bb827-e5f3-4178-ad46-8ac9b99d7726@embeddedor.com> Date: Mon, 25 Mar 2024 20:57:08 -0600 Precedence: bulk X-Mailing-List: linux-hardening@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH][next] RDMA/cm: Avoid -Wflex-array-member-not-at-end warning Content-Language: en-US To: Jason Gunthorpe , "Gustavo A. R. Silva" Cc: Leon Romanovsky , linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org References: <20240325224706.GB8419@ziepe.ca> From: "Gustavo A. R. Silva" In-Reply-To: <20240325224706.GB8419@ziepe.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4166.hostgator.com X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - embeddedor.com X-BWhitelist: no X-Source-IP: 201.172.174.229 X-Source-L: No X-Exim-ID: 1rox0R-001mui-1e X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.15.10]) [201.172.174.229]:52604 X-Source-Auth: gustavo@embeddedor.com X-Email-Count: 1 X-Org: HG=hgshared;ORG=hostgator; X-Source-Cap: Z3V6aWRpbmU7Z3V6aWRpbmU7Z2F0b3I0MTY2Lmhvc3RnYXRvci5jb20= X-Local-Domain: yes X-CMAE-Envelope: MS4xfNgW08gy/BermOfdhEVhQaBNKaMlfSO+Bw+GE/gCpN7Oqx5aILsrNtD0d0Gci6pdVlcUSvXpPQ6EyhOWb213UKOKh1on7Pd/ybClZPEFa4l+9m/5mrLJ ujmMn/2XZi3FdLQly7b/cmWlf6WDB7pN4+znGLAX45nep+N6GgsnDfZqRq4PpcB/CydEsBGS/5yBudP7drKA2Nn1sXn7UgyYbBcZpURH9tku5E9U+J20Mnl8 On 3/25/24 16:47, Jason Gunthorpe wrote: > On Mon, Mar 25, 2024 at 02:24:07PM -0600, Gustavo A. R. Silva wrote: >> -Wflex-array-member-not-at-end is coming in GCC-14, and we are getting >> ready to enable it globally. >> >> Use the `struct_group_tagged()` helper to separate the flexible array >> from the rest of the members in flexible `struct cm_work`, and avoid >> embedding the flexible-array member in `struct cm_timewait_info`. >> >> Also, use `container_of()` to retrieve a pointer to the flexible >> structure. >> >> So, with these changes, fix the following warning: >> drivers/infiniband/core/cm.c:196:24: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] >> >> Signed-off-by: Gustavo A. R. Silva >> --- >> drivers/infiniband/core/cm.c | 21 ++++++++++++--------- >> 1 file changed, 12 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c >> index bf0df6ee4f78..80c87085499c 100644 >> --- a/drivers/infiniband/core/cm.c >> +++ b/drivers/infiniband/core/cm.c >> @@ -182,18 +182,21 @@ struct cm_av { >> }; >> >> struct cm_work { >> - struct delayed_work work; >> - struct list_head list; >> - struct cm_port *port; >> - struct ib_mad_recv_wc *mad_recv_wc; /* Received MADs */ >> - __be32 local_id; /* Established / timewait */ >> - __be32 remote_id; >> - struct ib_cm_event cm_event; >> + /* New members must be added within the struct_group() macro below. */ >> + struct_group_tagged(cm_work_hdr, hdr, >> + struct delayed_work work; >> + struct list_head list; >> + struct cm_port *port; >> + struct ib_mad_recv_wc *mad_recv_wc; /* Received MADs */ >> + __be32 local_id; /* Established / timewait */ >> + __be32 remote_id; >> + struct ib_cm_event cm_event; >> + ); >> struct sa_path_rec path[]; >> }; > > I didn't look, but does it make more sense to break out the path side > into its own type and avoid the struct_group_tagged? I seem to > remember only one thing used it. > I thought about that, but I'd have to change the parameter type of `static int cm_timewait_handler(struct cm_work *work)`, and that would imply also modifying the internals of function `cm_work_handler()` (and then I didn't look much into it). So, the `struct_group_tagged()` strategy is in general more cleaner and straightforward. -- Gustavo