Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp906466ybf; Fri, 28 Feb 2020 09:54:03 -0800 (PST) X-Google-Smtp-Source: APXvYqy+iBwYK3vp5W/egbJmX8PYv3Y1wo7qP+ZukaM2YmZvYMqiIXwTpm+e+Irn5E46IclDIZ9x X-Received: by 2002:a9d:66c1:: with SMTP id t1mr3893080otm.73.1582912442988; Fri, 28 Feb 2020 09:54:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582912442; cv=none; d=google.com; s=arc-20160816; b=kPZRS90Sbc83v3iSKbiWDl1unNiBOBsSveHNYE+KPpQPhEMMuu0wdbH10/B3pnYzmv 4XyZGIAy6txkGVIH6N26K4Rm5Me5CNmyvb6I3iWOfyAJnMEEAOce2Bn+p2JTkVEGhcT7 equ1GvOpOCsx2EMPv0K2S1zydAJkvHfrz1YeSqwrnPNJ3EHcCGcRXcI+Urd+/8oXinA+ Ah3ahKz1uPx9uu6kqJYzst0VFWeZdnADluzlwPTR/DM/9t1XccmzKgspEO6jL519EAqX 9k6iYfqaXsL+bgooS9ea2/zQk8xOtH3Yw9EMPghUfu8AxwMc9if0kNdh5BLzLjDaTwlj y9Kw== 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=7A81NCRtl/YMUGoXqhguAxYpB741arq6+hyuPYrsxj8=; b=UsHITOyIlpiebXXorHgRNI8Z3RsneaHoyJ9rWH2P9cpsPcH+XTJ2YdVkgFyNtbZhne obfKXNT/+p6ewXDnqUh/0SOS6CzT7UFzuzkf/FHs7Lh5kQkBC/0Y5FNmpQPhcZ0CdHB4 s2uU9ssY/MB3aT+9IIcUrQdU+lMG+Vvu79bwti/M96rdrVvemP48x2qqbnDnUiT6y3fl pC1KWHx2q4BCcsmYCM6A2VeSHooFAup6g8E1B61pE2jZfOcuRxfZLmVqmzmgZpllK6+Q NkARfpsLtc2m6nZtNOILHJX4zRjKV/rNzBHVx8xKz3LIEdYRIkTbn5LSyg6KdICCTyZm Bf3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=sY0DpGEQ; 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 k4si1991067otp.186.2020.02.28.09.53.49; Fri, 28 Feb 2020 09:54:02 -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=sY0DpGEQ; 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 S1725928AbgB1Rxi (ORCPT + 99 others); Fri, 28 Feb 2020 12:53:38 -0500 Received: from mail-qk1-f193.google.com ([209.85.222.193]:42120 "EHLO mail-qk1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725730AbgB1Rxi (ORCPT ); Fri, 28 Feb 2020 12:53:38 -0500 Received: by mail-qk1-f193.google.com with SMTP id o28so3764962qkj.9 for ; Fri, 28 Feb 2020 09:53:37 -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=7A81NCRtl/YMUGoXqhguAxYpB741arq6+hyuPYrsxj8=; b=sY0DpGEQqcJV+Om5EC5uuAuFwKAdjsRvhCmg7xEn8ttC+eOSqdtl9G7psxfJzUGzyq CFgexnJMO3BoZGn/iSzwSiVKiNzwcPPDrFaf2Kub18f4onnWtjyleou7j3D2qhFdanI8 98t3lMngB6DyG5RzEw7SjgPkXdKjFb3VE9dGVTR5oeAa+IK8b22h9bpLrpLx/BgQzkUe Toz5kRGpIoqs7+ZszYosKGlJnWIVNnjOECOmsMnWFqnLNWmKzGIpmPLHE0mrnCM6fr0q CIvoVZX6V+zY/5T2ce6U9NoaV0KO+J1Ir2Q/sD+StqT1lsJW9n9C8bqwLC/RPl6XtCpv 6fyA== 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=7A81NCRtl/YMUGoXqhguAxYpB741arq6+hyuPYrsxj8=; b=Rt0UKUP2UVgH6hIGEGlWJPCP45W8p+vFnmtzUK0HcCFQfKULFd6GfhWjiItohtopGJ qhyCI60t9IGdl/zQ6OTbu07xFUef1MKMgdDXOcjoEBwVeTt61HlkulU28ACbV040ymYo lwL+P43Z3lnadPGWQjI6axhCxQp7eILJpLUuFHEhc8Sr+m03xwNQ9I+vJdmUkLsrJohS j7gqZouVKcRHkCul9AQO7eBihsiegcRnuBLIRqbMwETfSAGN6TsXl6H/0gGNUyADk5XS mHSx1U8KL3xh+3bBJSg/GsprHNV+WqPJiNVU0IeYnrapQtOQDMH/NAj3l0lpvXKqPRfY XY1g== X-Gm-Message-State: APjAAAUGr7irbUTiDY+ZhnjHtTVBBNKLx3YfBQRijtfpqlHuOpxrZ09x sL6JsyLOYekp4beokdQ/pOMM/4u5ub97r+XiVZoZ X-Received: by 2002:ae9:f301:: with SMTP id p1mr5320690qkg.422.1582912416914; Fri, 28 Feb 2020 09:53:36 -0800 (PST) MIME-Version: 1.0 References: <20200228012036.15682-1-brendanhiggins@google.com> <20200228012036.15682-2-brendanhiggins@google.com> In-Reply-To: From: Iurii Zaikin Date: Fri, 28 Feb 2020 09:53:00 -0800 Message-ID: Subject: Re: [PATCH v3 1/7] vmlinux.lds.h: add linker section for KUnit test suites To: Brendan Higgins Cc: Jeff Dike , Richard Weinberger , Anton Ivanov , Arnd Bergmann , Kees Cook , Shuah Khan , Alan Maguire , David Gow , Andrew Morton , rppt@linux.ibm.com, Frank Rowand , Greg KH , Stephen Boyd , Logan Gunthorpe , Luis Chamberlain , linux-um , linux-arch@vger.kernel.org, "open list:KERNEL SELFTEST FRAMEWORK" , KUnit Development , Linux Kernel Mailing List , "open list:DOCUMENTATION" 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 We went with this alignment precisely because it's the largest that any supported arch may possibly need. The problem as I understood it was that the compiler, seeing a bunch of pointers decided to put them at the memory-access efficient alignment rather than at the section start. Remember that the section start used to be unaligned for some reason. Note that the alignment that is a multiple of smaller alignment is still aligned wrt the smaller alignment, so the compiler shouldn't need to put the pointers elsewhere. I wonder if there's a more robust way of forcing the compiler to put the pointers right at the section start and insert no gaps between them than playing with alignment. On Thu, Feb 27, 2020 at 11:22 PM Brendan Higgins wrote: > > On Thu, Feb 27, 2020 at 5:20 PM Brendan Higgins > wrote: > > > > Add a linker section where KUnit can put references to its test suites. > > This patch is the first step in transitioning to dispatching all KUnit > > tests from a centralized executor rather than having each as its own > > separate late_initcall. > > > > Co-developed-by: Iurii Zaikin > > Signed-off-by: Iurii Zaikin > > Signed-off-by: Brendan Higgins > > Reviewed-by: Stephen Boyd > > --- > > include/asm-generic/vmlinux.lds.h | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h > > index e00f41aa8ec4f..99a866f49cb3d 100644 > > --- a/include/asm-generic/vmlinux.lds.h > > +++ b/include/asm-generic/vmlinux.lds.h > > @@ -856,6 +856,13 @@ > > KEEP(*(.con_initcall.init)) \ > > __con_initcall_end = .; > > > > +/* Alignment must be consistent with (kunit_suite *) in include/kunit/test.h */ > > +#define KUNIT_TEST_SUITES \ > > + . = ALIGN(8); \ > > After posting this, I saw I had gotten an email from 0day[1]. After > some investigation, I discovered that this 8 byte alignment works for > x86 64 bit fine, but only *sometimes* for 32 bit. 4 byte alignment > seems to work in all cases (so far). I am not sure why we went with > such a large alignment in hindsight. In any case, I should have a > fixed revision out pretty soon. > > > + __kunit_suites_start = .; \ > > + KEEP(*(.kunit_test_suites)) \ > > + __kunit_suites_end = .; > > + > > #ifdef CONFIG_BLK_DEV_INITRD > > #define INIT_RAM_FS \ > > . = ALIGN(4); \ > > @@ -1024,6 +1031,7 @@ > > INIT_CALLS \ > > CON_INITCALL \ > > INIT_RAM_FS \ > > + KUNIT_TEST_SUITES \ > > } > > > > #define BSS_SECTION(sbss_align, bss_align, stop_align) \ > > -- > > [1] https://lists.01.org/hyperkitty/list/lkp@lists.01.org/thread/4I4UW4OAT63ETMIEUJQTOF3BFTMO6ROD/