Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4953874ybl; Tue, 14 Jan 2020 00:44:37 -0800 (PST) X-Google-Smtp-Source: APXvYqx+fLLzpV1xINiq34Z6S6x56U8h7/uvrKXnSlf3/yJNtcnc14us+81ii4l5+LNkhiUthysn X-Received: by 2002:a54:4086:: with SMTP id i6mr16020580oii.65.1578991477297; Tue, 14 Jan 2020 00:44:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578991477; cv=none; d=google.com; s=arc-20160816; b=iWjPUwihOB0gCieyJaoryiqghcmC2Wn/6RAGTrfrlB+0VkmW/7TYM2XhGmGCm0DTTm lHzDpjxtdoMIIl6fH6Lm2LqHcA0V9cSdWaaPvPE39jv2VW4tNd7lKxDn2GKPkCUaxmub nQhsVuwuVtYfzRqy5F6rqiFH+d/U4ELA2IPsntdju3fcqPbZhPXK1YV1Bu/wZFQImOFy 79py+fMLeg1OXdRWzKrMKRV5OPMwA9/oOMhpJw8xJQcH8YAQ8mmw4V7ekCupkvGbi6FR XXYZ4kD8YmaoCH2p/T4CR3uANiGL3fGk5E9VX/AFaTv17Ilu2+rZI5tb0HyS3d5fq+6k glJg== 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; bh=ejpnAx858bN7xAD6kglyW+SUkaoeUYaE2bUSEYPdNy8=; b=cQzVqIt03mqPQR7brvrZO593oEp0VwlU1kjuIlq+Cgqu+j1llytelJ8t4WVBQhi3U4 Agx/HbZ5A3F7l6sY4I+M2SJoL3fRj2S8SuBr8slF32UO2Qzc9n0/kwBx2y9Li2rKKAHY lDxBwni9UC+z5cJIayZsrX2rJrW/2l83AuGUaH/69Oj3bcHU8CwY/4PRFAm7MDQCNCPt whcve8Ib7rcteOlAeaOh56zR5I5Vj6aGckr+nN1Vr7xTWGx0hUwwwIqeuyLVjO5VFhT6 JD1EMUgZPgCOnTGZLkEliadJ7Y7dutYXVugPp/hPIiPlOTCc+MCmpLawiPwjb6UChln7 Jwpg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b137si7102525oii.63.2020.01.14.00.44.25; Tue, 14 Jan 2020 00:44:37 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728797AbgANIm0 (ORCPT + 99 others); Tue, 14 Jan 2020 03:42:26 -0500 Received: from mout.kundenserver.de ([212.227.126.134]:45133 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725842AbgANImZ (ORCPT ); Tue, 14 Jan 2020 03:42:25 -0500 Received: from mail-qv1-f47.google.com ([209.85.219.47]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.129]) with ESMTPSA (Nemesis) id 1N5G1V-1jpXMb0r8X-011DMH; Tue, 14 Jan 2020 09:42:24 +0100 Received: by mail-qv1-f47.google.com with SMTP id dp13so5288694qvb.7; Tue, 14 Jan 2020 00:42:23 -0800 (PST) X-Gm-Message-State: APjAAAWlw9t3c2G9F62XI6aneaxBdeKfPLh9jknZL4cVsYbgtg2xEHKB rjAK/PwouSN3VMVUDWLqKSV+1wnQaJNUfzhvKcU= X-Received: by 2002:a0c:e7c7:: with SMTP id c7mr15837659qvo.222.1578991342846; Tue, 14 Jan 2020 00:42:22 -0800 (PST) MIME-Version: 1.0 References: <20200110134337.1752000-1-arnd@arndb.de> In-Reply-To: From: Arnd Bergmann Date: Tue, 14 Jan 2020 09:42:06 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] [RFC] kunit: move binary assertion out of line To: Brendan Higgins 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" X-Provags-ID: V03:K1:9547x2bVt3blggZ1UxBmuWeDc52ZrKwp9cZzwP3O+Z0QxT2vzbn p2YrZZllygUR5/yhEMbPoqz1Iv7dLM1SiMQPKZh/nXEk3gYzvEen2UqczXxNJKcOhbY8+cu PTNWMURzNUctheXmbrcQoJ0WzEMzpmNpkC+ERLgRCFSw0LBY9kj5qwWQs6Ps4MjYDTMljIH VCM7uy+67v6q/UhZQyyVA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:bHcbYbgWn2g=:McvsmWOR1P9y2FOt5ylA3t aPn2KuyOFoaeODWp/Xo3jzzX/04V92SO1itz1WaVpSajr+WVf1R8hc/qBGnfiM3Fexb0iipdH 1CkwsZRSC5VZHH3j8mG2gx00UTGYnUKjAHWjiWwcAYyY5sPcpRGIegwrDxUotVH+zZh3Vh+qT 0nGrqYzwdqQ0LeCqcNcg6Sz4zSajTffSt1SVSA+TAnPg3H4R80pLisDS6evjqOtS5kDXHfMtr FVLF/HRCL/3Xrf/qhj9tsxG9P5fuA/BIiBrTUZWyaRxpLGuZ64i6mhJv/BEHMlpB62EetxB9Z 01iR0NHzZ/VXCE3SfJKJUQAOEpPeOEKw/g6pcxicG/ugf6bmzIJt65XtLCMIUehy7q+DUQx9l luRl9m7i5yebqtDpb4WXGPVj3psACHEvviJ6tKAcb7KhXL584dQ6Gv8gp2xQOqyp5Vnwq0eHn idc36T6fRKV+0JBot6DasVUxmkmw831Ri3/NY1lSwr/GWD0rV/E4WPue7bJt/LwgSNtQQOiEb aFD9iCP06P8J4BuwrNnXfAD75YAOd+nEi4xo999HeqS8i8xUuglGfw5i0x84oiOfMR/wweAYE 12MzcBiBni5EBjGWVC12oyFumj7be9a3FRj3JXs7SHYQkqyijmbvAnlxVtHbg06emzKAUnkML b5EF2udYSCwYj23WYCkYizyh092x9o/WiOJ9RI6n1L+ev4jfmctTogTZ50Ff2FzQ6wFlU/jrs fUBdsNiNCwMtBhIRqt/zsJatUZahBJ2IQ+vOi7n2Twq8wxS8TidO2vPpieTr5AY8e234whtS+ AuIyfLKkYQabVlHWQz5lvluV+ZVEIbLviOHf2itXIjFGeF7qp4EYw+bvJaEp/vdmP8Fycaf7n bf7s9rQ0wfGpLZITPuuw== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 14, 2020 at 3:13 AM 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. Ok. > 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. Ah right, that should work fine, and may also lead to better object code if the compiler can avoid repeated assignments of the same values, e.g. ".file = __FILE__". Arnd