Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp793438ybj; Tue, 5 May 2020 07:38:15 -0700 (PDT) X-Google-Smtp-Source: APiQypILKSVFOT3Qi6l8YJ75oEGWtUIs+tlsOpJ8r5ScWQlE+fHh4hf3O10zcF2MK+wW9c6GEy9u X-Received: by 2002:a05:6402:b4c:: with SMTP id bx12mr3033299edb.247.1588689494977; Tue, 05 May 2020 07:38:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588689494; cv=none; d=google.com; s=arc-20160816; b=voC0KDNnoCGqUClhe28tDrIK6W3wsvwIDeYrplFzZGTnnEuPtonGbbmYrgs3M1jTGf 5sV2AGfN0s2V7FwFNz05rbdGnbQkhA69JlCLMF0qs9xa7k/R4j9XIiPHC2hDc39UXfiH WEBihx+6aNiFiMYh0xLltkiHEb6+hkxQR6n/cDI2uvBoLv+J/R445Lzrypy3EH3txgHt 3p2i7HLk7dxkdGIfA9hwiMgmNw/IQP1Ti6yoGRfKnlSpJnZZ1m6P5hElOUNFkkc1QIHb bErwXanxHyNxZWEGJ4nbFGmg6ncz76mVsy0SDxHWGV37SyvjzFjdGCOf0n3ytsNNe+5X gBew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=jxxKAc0tVlnWctaQhGaFh9jHy8CRwzAO3FypliKK8sQ=; b=S08MUB7kfp0v6bobNTvZqx6cDS21oo/gmnKUzaa9BebzGfe5IlwJhSSfIdNGfUXxHy iWAa7fVgAA1mnEI8qN4j3Y6blaAOgXpZDxy43806l6N+3GZnRsfbvCR369hyPKJ8ZEk2 6vu2XGX+yuIN0qCbplGWFfmhRkDYTQhQH3HpjtWhp0BvNAx6+J7AOeybyJYytdtrzT+q 4gJILqdpZxTMdSjkcnUuX/K7uCPKEwQ42DmKDEcjwoty/d1Yr677/kaNnIYCFhRgnvP7 gDsREN8daJwJH43z9Wlsk1mspv+Ai/DGZlK0IPI7AopP2dId8zM7KIynQFLnb0/lw17I 7yHw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gj19si1229974ejb.297.2020.05.05.07.37.50; Tue, 05 May 2020 07:38:14 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729358AbgEEOeC (ORCPT + 99 others); Tue, 5 May 2020 10:34:02 -0400 Received: from mx2.suse.de ([195.135.220.15]:57200 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727857AbgEEOeB (ORCPT ); Tue, 5 May 2020 10:34:01 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 003A9AB3D; Tue, 5 May 2020 14:34:01 +0000 (UTC) Subject: Re: [PATCH] xenbus: avoid stack overflow warning To: Arnd Bergmann , Boris Ostrovsky Cc: Stefano Stabellini , Yan Yankovskyi , Wei Liu , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com References: <20200505141546.824573-1-arnd@arndb.de> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <30d49e6d-570b-f6fd-3a6f-628abcc8b127@suse.com> Date: Tue, 5 May 2020 16:33:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200505141546.824573-1-arnd@arndb.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05.05.20 16:15, Arnd Bergmann wrote: > The __xenbus_map_ring() function has two large arrays, 'map' and > 'unmap' on its stack. When clang decides to inline it into its caller, > xenbus_map_ring_valloc_hvm(), the total stack usage exceeds the warning > limit for stack size on 32-bit architectures. > > drivers/xen/xenbus/xenbus_client.c:592:12: error: stack frame size of 1104 bytes in function 'xenbus_map_ring_valloc_hvm' [-Werror,-Wframe-larger-than=] > > As far as I can tell, other compilers don't inline it here, so we get > no warning, but the stack usage is actually the same. It is possible > for both arrays to use the same location on the stack, but the compiler > cannot prove that this is safe because they get passed to external > functions that may end up using them until they go out of scope. > > Move the two arrays into separate basic blocks to limit the scope > and force them to occupy less stack in total, regardless of the > inlining decision. Why don't you put both arrays into a union? Juergen > > Signed-off-by: Arnd Bergmann > --- > drivers/xen/xenbus/xenbus_client.c | 74 +++++++++++++++++------------- > 1 file changed, 41 insertions(+), 33 deletions(-) > > diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c > index 040d2a43e8e3..23ca70378e36 100644 > --- a/drivers/xen/xenbus/xenbus_client.c > +++ b/drivers/xen/xenbus/xenbus_client.c > @@ -470,54 +470,62 @@ static int __xenbus_map_ring(struct xenbus_device *dev, > unsigned int flags, > bool *leaked) > { > - struct gnttab_map_grant_ref map[XENBUS_MAX_RING_GRANTS]; > - struct gnttab_unmap_grant_ref unmap[XENBUS_MAX_RING_GRANTS]; > int i, j; > int err = GNTST_okay; > > - if (nr_grefs > XENBUS_MAX_RING_GRANTS) > - return -EINVAL; > + { > + struct gnttab_map_grant_ref map[XENBUS_MAX_RING_GRANTS]; > > - for (i = 0; i < nr_grefs; i++) { > - memset(&map[i], 0, sizeof(map[i])); > - gnttab_set_map_op(&map[i], addrs[i], flags, gnt_refs[i], > - dev->otherend_id); > - handles[i] = INVALID_GRANT_HANDLE; > - } > + if (nr_grefs > XENBUS_MAX_RING_GRANTS) > + return -EINVAL; > > - gnttab_batch_map(map, i); > + for (i = 0; i < nr_grefs; i++) { > + memset(&map[i], 0, sizeof(map[i])); > + gnttab_set_map_op(&map[i], addrs[i], flags, > + gnt_refs[i], dev->otherend_id); > + handles[i] = INVALID_GRANT_HANDLE; > + } > + > + gnttab_batch_map(map, i); > > - for (i = 0; i < nr_grefs; i++) { > - if (map[i].status != GNTST_okay) { > - err = map[i].status; > - xenbus_dev_fatal(dev, map[i].status, > + for (i = 0; i < nr_grefs; i++) { > + if (map[i].status != GNTST_okay) { > + err = map[i].status; > + xenbus_dev_fatal(dev, map[i].status, > "mapping in shared page %d from domain %d", > gnt_refs[i], dev->otherend_id); > - goto fail; > - } else > - handles[i] = map[i].handle; > + goto fail; > + } else > + handles[i] = map[i].handle; > + } > } > - > return GNTST_okay; > > fail: > - for (i = j = 0; i < nr_grefs; i++) { > - if (handles[i] != INVALID_GRANT_HANDLE) { > - memset(&unmap[j], 0, sizeof(unmap[j])); > - gnttab_set_unmap_op(&unmap[j], (phys_addr_t)addrs[i], > - GNTMAP_host_map, handles[i]); > - j++; > + { > + struct gnttab_unmap_grant_ref unmap[XENBUS_MAX_RING_GRANTS]; > + > + for (i = j = 0; i < nr_grefs; i++) { > + if (handles[i] != INVALID_GRANT_HANDLE) { > + memset(&unmap[j], 0, sizeof(unmap[j])); > + gnttab_set_unmap_op(&unmap[j], > + (phys_addr_t)addrs[i], > + GNTMAP_host_map, > + handles[i]); > + j++; > + } > } > - } > > - if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, unmap, j)) > - BUG(); > + if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, > + unmap, j)) > + BUG(); > > - *leaked = false; > - for (i = 0; i < j; i++) { > - if (unmap[i].status != GNTST_okay) { > - *leaked = true; > - break; > + *leaked = false; > + for (i = 0; i < j; i++) { > + if (unmap[i].status != GNTST_okay) { > + *leaked = true; > + break; > + } > } > } > >