Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4700504ybl; Mon, 13 Jan 2020 19:01:05 -0800 (PST) X-Google-Smtp-Source: APXvYqylIdCEjDP0Peo1ugyDmpPL+ZGiCUzp/kzQv2vDj5E87FaslpyMNh6Fup4kp/L/wh6YPgBy X-Received: by 2002:a05:6830:1112:: with SMTP id w18mr15639241otq.356.1578970865031; Mon, 13 Jan 2020 19:01:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578970865; cv=none; d=google.com; s=arc-20160816; b=assMKA1bV3QMgxZJzcAndGMz8yNSp2FLR0B2DQ7ikLG26J09x2Z5D7Hbo3NwM/Ps9w pOUqg9XFxdN9/4K44JGMW6DLSXpICd3PK8olxatQZfAaaJwKt8LtguoPKPZkbXJDWJ0m GSNBWmorwZSS+AKFkCZn2OE3MGs00V3Dzv2yYW8fbeVkUEMX9RkVLn9KDdpo4sgn0nYW BXOe9ku8+vqXOo7ysoHBlPUtmhsWrbJf1aiItRJwJUBGuURo2nbwsLHY0Ip7xyfmCCh2 zz5uJ7VH+VIJww37FH9bnLQPmotSQYOOZZgdwPYoGelO2JcfI8bHHjFHbU5scfLrtfXh HdEQ== 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=+z8kiB27wPGXn90Jifmc7GvqCcTTfQFQ09TVSilQ62U=; b=dPHDOtTd1Ydkef4KC4r+s69C7i0jr0CJWSGeYBFnux+lqDLzTBajeQbGegxFp5CaQZ yU6sTy1O3dMzfviSBW0TivZLkNfpRlQAEwyQle/6SuvvZP9U0bacUnIJXgnsNqAw7sRm QPrTYGI0ghiUKxblHPpt4BhnJjKDPGMhx1CzOGx/mtFVMcw+seM+YaonzTKIw3aKPhvb JxB56C3FnRB3ADfKKUm3ILl96+a7v5KW4zBjOW4pAULkKoXXN+kk0QEk3/lSnOBgKd9P YxePrR5CTJrtqybM7YmKNvf32fqwMkGdwMx6/T9A1oLOzzUVC8fHcXtZENQwZ1w5rjx0 2onQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=nz5Aooyy; 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 q6si9437994otg.248.2020.01.13.19.00.52; Mon, 13 Jan 2020 19:01:05 -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=nz5Aooyy; 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 S1729427AbgANCNv (ORCPT + 99 others); Mon, 13 Jan 2020 21:13:51 -0500 Received: from mail-pj1-f66.google.com ([209.85.216.66]:33613 "EHLO mail-pj1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728922AbgANCNv (ORCPT ); Mon, 13 Jan 2020 21:13:51 -0500 Received: by mail-pj1-f66.google.com with SMTP id u63so427301pjb.0 for ; Mon, 13 Jan 2020 18:13:51 -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=+z8kiB27wPGXn90Jifmc7GvqCcTTfQFQ09TVSilQ62U=; b=nz5AooyyO8UV4W2raMKoiKBMXtT/bo9PatBrL5aEBihU5Bu8dzhJ8lIyBnJQ+7UN76 P+8/m5ClVTYTjII38MEWxWvX3IgSd4aJJ5WHnTZBjPegsX3qCbvmzuugoTbHeCGxKb4D x4Tz6JqgNPET3RWsCkuix5TjP3xnI2zk1U5FIhqepS7I66Q5kXX0uOyeIxJgvG80qeSF xxacbzLRmtPQRQNpVGry/ia8R+OdKCBfLrFLnw5bvA0fTBwrEhvK38+x3T07HMggXDyN L3ZMnfshrU53TdeSuwwYqAH4t9yzn8peHp4uA1EZQ7oD09Aj36dwrTV0bi7V3NhYvo8o 1BBA== 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=+z8kiB27wPGXn90Jifmc7GvqCcTTfQFQ09TVSilQ62U=; b=h+nZsiJ8T1x3QMjFYhHClRWDI9C9TuXm7LX5NJvzJuaHxEd+3+p0aaKJogl1YvTRUd TJYOaKDgdlDPZ/HNgajo8Px0TTUWIM3VnSM0E4TKBNrgZgzs5diR05HcI8XNW42nWYVc iOIrtqaJU5XfIg8rAV1H/n8sRZsHdnzPDjKSXCRX+yY+m8AtfqixUX/Xlc3w42bWj9zs frYMl/+WGYkTIGb9lYWqTlGoovp45Xd/wfogRYY2Y6rvBZmDuk1f+ytv+Murb2Cnxx5a 2ffd3+QZ14lhh9N2M8ay386qitI1jhO2h9GYlsdbsTKM3SBDY4QSrmRe6AEyhYuNhtq6 cFFA== X-Gm-Message-State: APjAAAVLBzI39bJ4sMz3kclPJwZWUjwsVuv8u7RUSuZMDMFbSTUrCNIG XHpZFE1E0/+lmHhv0kEU/Bqv86+ilS7Qs3TwnmhqKw== X-Received: by 2002:a17:902:fe8d:: with SMTP id x13mr17781759plm.232.1578968030398; Mon, 13 Jan 2020 18:13:50 -0800 (PST) MIME-Version: 1.0 References: <20200110134337.1752000-1-arnd@arndb.de> In-Reply-To: From: Brendan Higgins Date: Mon, 13 Jan 2020 18:13:39 -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 Mon, Jan 13, 2020 at 6:12 PM Brendan Higgins wrote: > > 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 Woops forgot to link the original discussion. [1] https://lkml.org/lkml/2020/1/13/1166