Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp852737ybl; Wed, 8 Jan 2020 07:00:23 -0800 (PST) X-Google-Smtp-Source: APXvYqxj8hWWaAHR7jDdwWEFiBfCqzSw9EaKE2YSdLYLoEHSyO/on6Y6tz0AcBpajJLQ/sZZZ1xE X-Received: by 2002:aca:d5d3:: with SMTP id m202mr3165054oig.161.1578495623484; Wed, 08 Jan 2020 07:00:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578495623; cv=none; d=google.com; s=arc-20160816; b=OV3ADemWqgKdhL45t9Ka+s9MeMjMPhosWqcsit3PsWzGW8aWTHSecvzf8ALAR7cSCI W4RYYv3g+qkP7VNj9426EbSf5FJHVx9VontoGo5gAclEH7D4MmbP5nCz++iYe1bUws2D 1CIjHhq4f5w3ELoBcpDV/n1J1GvQEGhOAGM/mf+YMVvrV2dRKR5xgDGH/gl5Orueyslm dP0mTsPTau+K7hAwDczgSwwbUEGMBFU0zMYHYFB/PkS+Rmb9tcBEDgH32pIzwIY++gDP WLmHodkMqr4YYmULP0Zgi88zlQXlqEezm86Ff4NR16MMmQ4tONzEjmAsPRb3vxJkMHP0 khPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Pmfr4lT+9w9idepjsVRbi3vih8NhxWk03pCzh2kY1TM=; b=PGPT27vBWqDK0qT0Umkk8nXb2yJ2V9zA0JWWMYNe9gJ6PslR5HY6xQ8BgTQyPLLjcO LC0m+J2GG3UXtWdHRGTRqBMef7ymBWl0s6WtvsfQQLKN2WPw6eG+Zn7bt/wLIdvOOgs+ AkjAggChxdZKBpRwWjHNWcJvppXerV6wS9vu2Ny4xHFsmVOCIMUxxjo4o6nujanFZBSB bLO9BbDDqKco1OcCxPt/Gi2nbEyyKb9oZGKsGTpQ2G3OaGh0LRju9yWF9KdYrc12VW09 /NbeV96IR0e6ym1PHjq7bFDFWaONW50UjFB1dzEnQ7rAe2YA46VlnsOLu5RTSwU2QdS7 yZ2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=H37n2vyI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p16si2535201otr.134.2020.01.08.07.00.10; Wed, 08 Jan 2020 07:00:23 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=H37n2vyI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728433AbgAHOlq (ORCPT + 99 others); Wed, 8 Jan 2020 09:41:46 -0500 Received: from mail-pg1-f196.google.com ([209.85.215.196]:41298 "EHLO mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727903AbgAHOlq (ORCPT ); Wed, 8 Jan 2020 09:41:46 -0500 Received: by mail-pg1-f196.google.com with SMTP id x8so1679271pgk.8 for ; Wed, 08 Jan 2020 06:41:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Pmfr4lT+9w9idepjsVRbi3vih8NhxWk03pCzh2kY1TM=; b=H37n2vyIH55gzmQlLagmHwa+ll3F9/TwM2PMzE71ifUtYXqOpcSIaHMJq1YMdsVuOy 4Qh6w06cGhhxeRo3z3Ib+a6XxhOf1kjpCQOojK0GCr3P9mesVRYsOuvCHmXRJ9epZNLk YopMferNnK1gLz6vW0EatYwdbceYUKyXGzxrW6A2vqtV6ksiHTuk9Why+mWTCEPDj2bU rsp7itq17//T03fscxF7lam4D3IPEO7IZRHSB7wBo5dCu3djjZpRTkypjWyVnECgd9f6 I9qaeaWx6v7hX0MkFk/y8bpqKuNPnEQCyiLExjBTOH7q05TRi66QdKaHbbUv9GnWzyma wXWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Pmfr4lT+9w9idepjsVRbi3vih8NhxWk03pCzh2kY1TM=; b=VskxJFjBIkLsPEvsF7Gr5Mh1dGr2ucVkGDEASsexb+aevd88wbiaAgQAKADgLMxYZq K2Y0sSNcmcZGQudm0vY+k5a/7JJsDbGl7D54ni/CshKYULFs0HOnB17onqI9WfDh7YSv IaA47zE3hWk1K1YSkLefTnrmp/STvwOYqTv5gyc1zdX5ZB2UktE1z/9hug6e+e6mmn5j qU1skJ4dVnU02jgEoO9rx3oe5M2ep3CQvlBahTEC3QFpSJVHd7JrknDwOB/vJK1C90wb TJnHlESsdaorVQdpRVjiBxRwRa5yFrPNOYW1JDJ/t2bCGQe1b54Zfhjn6EHBru6jfFN+ v1Uw== X-Gm-Message-State: APjAAAUIxsWLTVLlHB3Vu6W3eKSBstDoe24s++iSh1vMLajlseF9Dv1S +AXTzOofYa6tjqFvDuJqw0KYaazynDtuKIniiUoK5A== X-Received: by 2002:aa7:961b:: with SMTP id q27mr5376393pfg.23.1578494505168; Wed, 08 Jan 2020 06:41:45 -0800 (PST) MIME-Version: 1.0 References: <201912301716.xBUHGKTi016375@pmwg-server-01.pmwglab> In-Reply-To: From: Brendan Higgins Date: Wed, 8 Jan 2020 06:41:31 -0800 Message-ID: Subject: Re: kunit stack usage, was: pmwg-ci report v5.5-rc4-147-gc62d43442481 To: Arnd Bergmann , Stephen Boyd Cc: PMWG CI , Dmitry Torokhov , "Rafael J. Wysocki" , Linux Kernel Mailing List , Private Kernel Alias , Kees Cook , Ard Biesheuvel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +Stephen Boyd On Tue, Jan 7, 2020 at 4:37 AM Arnd Bergmann wrote: > > On Mon, Dec 30, 2019 at 6:16 PM PMWG CI wrote: > > > > > > The error/warning: 1 drivers/base/test/property-entry-test.c:214:1: warning: the frame size of 3128 bytes is larger than 2048 bytes [-Wframe-larger-than=] > > ... was introduced by commit: > > > > commit c032ace71c29d513bf9df64ace1885fe5ff24981 > > Author: Dmitry Torokhov > > Date: Wed Dec 4 10:53:15 2019 -0800 > > > > software node: add basic tests for property entries > > This problem is a result of the KUNIT_ASSERTION() definition that puts > a local struct on the stack interacting badly with the structleak_plugin > when CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL is set in > allmodconfig: > > pe_test_uint_arrays() contains a couple of larger variables, plus 41 > instances of KUNIT_EXPECT_*() or KUNIT_ASSERT_*(), each one > of these adds its own copy of the structure, eventually exceeding > the warning limit. Uh oh, sorry about that. > We can work around this locally by splitting up the largest four > functions in this file (pe_test_uints, pe_test_uint_arrays, pe_test_strings, > and pe_test_reference) into smaller functions that stay below the > warning limit, but it would be nice to find a way for kunit to not > use as much stack space. Any suggestions? Agreed. I have a couple ideas. The grossest idea, which I am guessing most people won't like is to go back to the stream builder method, basically build the message as we go on the heap; however, the current method was created specifically to not do that which much help from Stephen (CC'ed), so probably not want we want to do. Another idea, the struct just exists to pack up data and ship it off to a function which handles the expectation/assertion. Consequently, the struct is only used inside the expectation/assertion macro; it is not needed before the macro block and is not needed after it. So could we maybe make some kind of expectation/assertion union so that we know they are all the same size, and then somehow tag the stack allocation so that we only ever have one copy in a stack frame? I am not sure if that kind of compiler magic exists. I guess one way to accomplish this is to make a dummy function in KUnit whose job it is to call the unit test function, which allocates the object, and then calls the unit test function with a reference to the object allocation; then we could just reuse that allocation and we can avoid making a bunch of piecemeal heap allocations. What do people think? Any other ideas? Also, sorry in advance for delayed responses: I am on vacation until the 13th and then I will be at LCA until the 18th. Cheers!