From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bart Van Assche Subject: Re: [PATCH] infiniband: avoid overflow warning Date: Mon, 31 Jul 2017 16:17:35 +0000 Message-ID: <1501517853.2466.12.camel@wdc.com> References: <20170731065016.2947796-1-arnd@arndb.de> <1501515117.2466.9.camel@wdc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Language: en-US Content-ID: Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "arnd-r2nGTMty4D4@public.gmane.org" Cc: "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org" , "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "parav-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org" , "monis-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org" , "Michal.Kalderon-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org" , "sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org" , "danielmicay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" , "Ariel.Elior-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org" , "hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" , "davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org" , "dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" , "noaos-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org" List-Id: linux-rdma@vger.kernel.org On Mon, 2017-07-31 at 18:04 +0200, Arnd Bergmann wrote: > On Mon, Jul 31, 2017 at 5:32 PM, Bart Van Assche = wrote: > > So inetaddr_event() assigns AF_INET so .sin_family and gcc warns about = code > > that is only executed if .sin_family =3D=3D AF_INET6? Since this warnin= g is the > > result of incorrect interprocedural analysis by gcc, shouldn't this be > > reported as a bug to the gcc authors? >=20 > I think the interprocedural analysis here is just a little worse than it = could > be, but it's not actually correct. It's not gcc that prints the warning = (if > it did, then I'd agree it would be a gcc bug) but the warning is triggere= d > intentionally by the fortified version of memcpy in include/linux/string.= h. >=20 > The problem as I understand it is that gcc cannot guarantee that it > tracks the value of addr->sa_family at least as far as the size of the > stack object, and it has no strict reason to do so, so the inlined > rdma_ip2gid() will still contain both cases. Hello Arnd, Had you already considered to uninline the rdma_ip2gid() function? Bart.= -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752492AbdGaQS0 (ORCPT ); Mon, 31 Jul 2017 12:18:26 -0400 Received: from esa2.hgst.iphmx.com ([68.232.143.124]:33982 "EHLO esa2.hgst.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751054AbdGaQSY (ORCPT ); Mon, 31 Jul 2017 12:18:24 -0400 X-IronPort-AV: E=Sophos;i="5.41,304,1498492800"; d="scan'208";a="134870296" From: Bart Van Assche To: "arnd@arndb.de" CC: "linux-kernel@vger.kernel.org" , "keescook@chromium.org" , "linux-rdma@vger.kernel.org" , "parav@mellanox.com" , "monis@mellanox.com" , "Michal.Kalderon@cavium.com" , "sean.hefty@intel.com" , "danielmicay@gmail.com" , "Ariel.Elior@cavium.com" , "hal.rosenstock@gmail.com" , "davem@davemloft.net" , "dledford@redhat.com" , "noaos@mellanox.com" Subject: Re: [PATCH] infiniband: avoid overflow warning Thread-Topic: [PATCH] infiniband: avoid overflow warning Thread-Index: AQHTCclSAgfpevQT8ke8UGOQKFNr46JthC8AgAAF7gCAAIaagIAACQiAgAADtYA= Date: Mon, 31 Jul 2017 16:17:35 +0000 Message-ID: <1501517853.2466.12.camel@wdc.com> References: <20170731065016.2947796-1-arnd@arndb.de> <1501515117.2466.9.camel@wdc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Bart.VanAssche@wdc.com; x-originating-ip: [63.163.107.100] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;CY1PR0401MB1535;20:qvKbL0k6CrCo22w8WScyPucEU0jQOEzKN6Mspfut8zrzuWMpWJJ8V837DQLBoAjLE75OJMu+YXs6wVi4XcmO9VpBjesvZVXS5bXXVK2Yw9lvL5BgS1e0MIrP70yPdvNWACE6WNn5Vwswr81vGgWH+q8/zCKEMXWF3RzZsbPx0MM= x-ms-office365-filtering-correlation-id: 682b46cc-c97c-4307-6c1d-08d4d82fa7e4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:CY1PR0401MB1535; x-ms-traffictypediagnostic: CY1PR0401MB1535: wdcipoutbound: EOP-TRUE x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:CY1PR0401MB1535;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:CY1PR0401MB1535; x-forefront-prvs: 03853D523D x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39450400003)(39400400002)(39410400002)(39840400002)(39850400002)(39860400002)(377454003)(377424004)(199003)(24454002)(189002)(6116002)(3280700002)(2906002)(99286003)(2501003)(66066001)(8676002)(5660300001)(81166006)(81156014)(1730700003)(478600001)(36756003)(7416002)(305945005)(72206003)(5640700003)(86362001)(6512007)(6916009)(68736007)(2950100002)(53936002)(93886004)(103116003)(33646002)(25786009)(53546010)(2351001)(229853002)(6486002)(97736004)(77096006)(7736002)(2900100001)(6436002)(54356999)(76176999)(50986999)(6506006)(106356001)(3846002)(102836003)(105586002)(14454004)(8936002)(3660700001)(54906002)(189998001)(110136004)(6246003)(38730400002)(39060400002)(101416001)(4326008);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR0401MB1535;H:CY1PR0401MB1536.namprd04.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: MIME-Version: 1.0 X-OriginatorOrg: wdc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2017 16:17:35.6191 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0401MB1535 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v6VGIV8l017298 On Mon, 2017-07-31 at 18:04 +0200, Arnd Bergmann wrote: > On Mon, Jul 31, 2017 at 5:32 PM, Bart Van Assche wrote: > > So inetaddr_event() assigns AF_INET so .sin_family and gcc warns about code > > that is only executed if .sin_family == AF_INET6? Since this warning is the > > result of incorrect interprocedural analysis by gcc, shouldn't this be > > reported as a bug to the gcc authors? > > I think the interprocedural analysis here is just a little worse than it could > be, but it's not actually correct. It's not gcc that prints the warning (if > it did, then I'd agree it would be a gcc bug) but the warning is triggered > intentionally by the fortified version of memcpy in include/linux/string.h. > > The problem as I understand it is that gcc cannot guarantee that it > tracks the value of addr->sa_family at least as far as the size of the > stack object, and it has no strict reason to do so, so the inlined > rdma_ip2gid() will still contain both cases. Hello Arnd, Had you already considered to uninline the rdma_ip2gid() function? Bart.