From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932242AbdBHQl1 (ORCPT ); Wed, 8 Feb 2017 11:41:27 -0500 Received: from smtp-out4.electric.net ([192.162.216.183]:56622 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751859AbdBHQlD (ORCPT ); Wed, 8 Feb 2017 11:41:03 -0500 X-Greylist: delayed 2393 seconds by postgrey-1.27 at vger.kernel.org; Wed, 08 Feb 2017 11:41:01 EST From: David Laight To: "'Johannes Berg'" , Arnd Bergmann , David Miller , "netdev@vger.kernel.org" CC: "stable@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Andrey Ryabinin" , "nikolay@cumulusnetworks.com" , "nicolas.dichtel@6wind.com" , "adobriyan@gmail.com" , linux-wireless Subject: RE: KASAN+netlink, was: [PATCH] [net-next?] hns: avoid stack overflow with CONFIG_KASAN Thread-Topic: KASAN+netlink, was: [PATCH] [net-next?] hns: avoid stack overflow with CONFIG_KASAN Thread-Index: AQHSggpIKEmJG9eHM0qpsX+UffqeAKFfQq8Q Date: Wed, 8 Feb 2017 16:00:24 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB027F2B4@AcuExch.aculab.com> References: <20170203163607.3488037-1-arnd@arndb.de> <20170206.120318.1268240226202516488.davem@davemloft.net> <4910112.l20yySyWnA@wuerfel> (sfid-20170208_130733_449950_64BEF84C) <1486556665.24745.6.camel@sipsolutions.net> In-Reply-To: <1486556665.24745.6.camel@sipsolutions.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 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 base64 to 8bit by mail.home.local id v18Gg8lb008366 > From: Johannes Berg > Sent: 08 February 2017 12:24 ... > Btw, what's causing this to start with? Can't the compiler reuse the > stack places? Only if it realises they've gone out of scope - which probably doesn't happen when the functions are inlined. The address of the parameter can be saved by the calling function and used in a later call. Something like this is valid: int foo(int *p, int v) { static int *sv; int old = -1; if (sv) {old = *sv; *sv = v;} sv = v; return old; } void bar(...) { int a, b; ... foo(&a, 0); ... foo(&b, 1); ... foo(NULL, 2); ... If the compiler starts sharing stack it all goes wrong. David