Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4704216ybl; Mon, 13 Jan 2020 19:05:19 -0800 (PST) X-Google-Smtp-Source: APXvYqxvqkO3NgHzVb7SBTNgcRHlaTKEvu4e8qYTPWb3Jzl8x67Q4lFDx7E5/pkJ/x7BfsHFJ2/e X-Received: by 2002:aca:6108:: with SMTP id v8mr14373996oib.96.1578971119108; Mon, 13 Jan 2020 19:05:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578971119; cv=none; d=google.com; s=arc-20160816; b=zHdl1V4Zn6wKOw+R+9Xx2GUytBwqCPQpJaoeIhMf12433pdO4lSAAq6AIKU3wX0N6d eZMxf7DqF0BhslTRAMMLCtlSTAGtlQ9hOPLUjcIaZpoqYn4Uq77q4Uy3pYdZIBImYVYj Ce/TYD8lPIHycQPqw8XToV+DBaWfFq8O5SLwqKYD50Ns0dVhlNoDXnFux49fHLRvAJKS CBNfUxLyvLT7iK2thpmlWQfN7R+j/uRg2gBAKLZI2HjSauyPreV2lh8kx7FizL72VKzT AeXMkisWVVSA1ngGRwSaYXNlPppLMYSbbJUpOHqaHyaLQdkbbYALtwPpCbP8gKvqdODT 3RnQ== 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=zUSom5y/SpzD4gpSNkPj43/HDsOCuEZmG337PZbQYo8=; b=WDbk1leTx+PO43dW9BpzmJMEFSI2nx/fRLrbW9IHYLbQIbhJniIFRuQpIjlgNXFH5M nbAKV4OVrLJPV+1pCmfaPrgXTwfb6ENeJ1RWqWlNWeF3XjUcTDYsXIJ1d58Sreq6dJsC LKBmlJ9h0pKshhpL+gNz9CQkRZXTKDZ9TNEK8LParvtkMUJW5prBkGzFb4I05gNBvrKJ FlgUtbxMd2d6wAq1hISPc9J3rCeEJPBtVa6vNTkZFzJPmF6pHN8ZcUp/LnabC5zdtquR ijC+W+1U9qypa0+yJVzlRvcMvm/4X7Ku8mqd60wvtgU2W3iPcllIGHZSZjIFD7NO4yAT zQTw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=cyYkFlQZ; 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 10si6752160ois.76.2020.01.13.19.05.06; Mon, 13 Jan 2020 19:05:19 -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=cyYkFlQZ; 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 S1729548AbgANCNF (ORCPT + 99 others); Mon, 13 Jan 2020 21:13:05 -0500 Received: from mail-pg1-f194.google.com ([209.85.215.194]:42909 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729267AbgANCNE (ORCPT ); Mon, 13 Jan 2020 21:13:04 -0500 Received: by mail-pg1-f194.google.com with SMTP id s64so5624399pgb.9 for ; Mon, 13 Jan 2020 18:13:04 -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=zUSom5y/SpzD4gpSNkPj43/HDsOCuEZmG337PZbQYo8=; b=cyYkFlQZok93LSehSRlnGBzLEkIUdGUnVOT/p74e4fpEWiw8zHElU9fJYZ9Wne7d00 /OdxwVagUz7ZshYpxrEv+HqLxweEPH9giSHzK4Pp3kXrJvWFt6nYb7U45yu0uwsqf2Ot 8RBkAWXb5+ttdVKyDPy06bgU9MrkZe4RaGdeqAoNaR0BM+DUG6yJNQrqpP4GRu5/nSmi LFp0lBPL4OdIgASUy/yeCMcBDrUnL9xQswb2qhRBoBLemYGqu0RaWp1deB9CUlk66o4w bvLc3QlmQvsUMEtLQOtn9I0RJooADxrvrdgaSQP5j135CBGOPc8S4trhEF2qL5YuSIke Uwlw== 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=zUSom5y/SpzD4gpSNkPj43/HDsOCuEZmG337PZbQYo8=; b=NNIjRgxLdSv0vN0ocVZPIJl7It03d8O7TIoyxvoQx95DaVoFs1jV/t2DI9j4yWa8am oLyyM4sYW6bj2tAl/gc6MkKXE16YTgJV/Je5HMcgcToWwqauVb5vGInrR88Yy0TxrTx7 pDilTIzZTuW8CDe3N70tr3HI5T9a1zDrRAPqtFPm02AUWrS+IuNRobG5ynmxJ7uBAd4+ UgTZjsPEGuU+RdsqS2Q3b+TEp/c7LaYHg2GUT3x2x8we3F3lZ0YWcSHHCJFYcI8HwBo9 4DMjfvu5woCFYlv5Qrdu3HsBe37Eog3HsTNRv0Jk7pF3oAEIIKwtlViJ+iBBnqmuBPjF PrpQ== X-Gm-Message-State: APjAAAX/pWsCtfaUnu6cCl/lSovxYCBoH5Y0Vz98F4vUDHLu+DMgVadV jBjn7MkAGrUugd1VWeFLW+WQsNRSsL91waUbNVmGhA== X-Received: by 2002:aa7:93ce:: with SMTP id y14mr22918972pff.185.1578967983633; Mon, 13 Jan 2020 18:13:03 -0800 (PST) MIME-Version: 1.0 References: <20200110134337.1752000-1-arnd@arndb.de> In-Reply-To: <20200110134337.1752000-1-arnd@arndb.de> From: Brendan Higgins Date: Mon, 13 Jan 2020 18:12:52 -0800 Message-ID: Subject: Re: [PATCH] [RFC] kunit: move binary assertion out of line To: Arnd Bergmann Cc: Kees Cook , Ard Biesheuvel , Stephen Boyd , Dmitry Torokhov , "Rafael J. Wysocki" , "open list:KERNEL SELFTEST FRAMEWORK" , KUnit Development , Shuah Khan , Greg Kroah-Hartman , Logan Gunthorpe , Linux Kernel Mailing List 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 On Fri, Jan 10, 2020 at 5:43 AM Arnd Bergmann wrote: > > In combination with the structleak gcc plugin, kunit can lead to excessive > stack usage when each assertion adds another structure to the stack from > of the calling function: > > base/test/property-entry-test.c:99:1: error: the frame size of 3032 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] > > As most assertions are binary, change those over to a direct function > call that does not have this problem. This can probably be improved > further, I just went for a straightforward conversion, but a function > call with 12 fixed arguments plus varargs it not great either. Yeah, I am not exactly excited by maintaining such a set of functions. I don't think anyone wants to go with the heap allocation route. Along the lines of the union/single copy idea[1]. What if we just put a union of all the assertion types in the kunit struct? One is already allocated for every test case and we only need one assertion object for each test case at a time, so I imagine that sould work. I will start messing around with the idea. Still, it sounds like we are down to either reducing the number of instances of this struct that get created per test case, or we need to remove it entirely (as you have done here). Cheers