Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp6861792ioo; Thu, 2 Jun 2022 15:36:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwuAz/izqnTbpNe5L0Mh+ChIemPkTjtSPY+q4A9cb6RunFZ1EDVQIKADtjlkblJyUvhVRBt X-Received: by 2002:a17:902:9b8a:b0:163:d0ad:f9e8 with SMTP id y10-20020a1709029b8a00b00163d0adf9e8mr7006583plp.79.1654209417413; Thu, 02 Jun 2022 15:36:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654209417; cv=none; d=google.com; s=arc-20160816; b=BFHz+TCl4qpRJGuoji962TjEl7+1VQW9OkRf7y1UQshDdzPq1ioz8cT4gEP9URuigY rnGBWDN0Y78kIvLue5BbT77SgUKRGVJgYq58xiHSt088gr2KyUsFekmbs2IHaVmWWPtw 9mlpkZm0OhXwa1JpHA2KcdoRREZQdDE6SODwRlqdlX95o3TzVW+qyVzgH0Pc3jHao7sU eo8d6wrhzZDuZJHDGIdBUXyiZd/LoxueJqzdyU4ofuomNynXBBD5lYHlLqZ1zs/o3P36 ZdzqPhzLbHcRjlfIdGaCxR/apTB/TvuraY13DAUwS3oGD8MD/GzMa2DoAtArGQzqZE75 Itbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=JZ8UPU6ugki+PkwkthIYbz7oUO9hdXo6b9SQ7nkdwtM=; b=abkcvwGqfqm5C92kL8IWWH30XGKWzXzbrGJO3jiFOTzURVJT+ncw38kd+9fMR7CNeJ sbUTanI4xL042oQc3fDiq1WC1aWjV0oHlBDTk5IpwP69glqbFC0cEIMeCZ3srI7n/mEC Omf3lfeF7cjVaOnhPNep2OMBGOl+snGsm6PGQi7jEJVyh27OG2WIy+AJFrJi+8+b5WFo EBc7JFtHKqriGtZgW0nGuHI2ttSo72xdAqhxeMqPPA9uaocS52KleyGcOGDhZtcXE+Ac q8RejKDWCtFBVqFUIVrb8OPJYYPw4ggmA8UhMksBVc0Q/hLPWy1ftpMkzLsDrn9sXKMa V4aw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="L/0QynMd"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j37-20020a635965000000b003f9f28dde0csi7553644pgm.255.2022.06.02.15.36.45; Thu, 02 Jun 2022 15:36:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="L/0QynMd"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S232427AbiFBQxg (ORCPT + 99 others); Thu, 2 Jun 2022 12:53:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55064 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237369AbiFBQxb (ORCPT ); Thu, 2 Jun 2022 12:53:31 -0400 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 211302B2EAA for ; Thu, 2 Jun 2022 09:53:24 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id m20so11070268ejj.10 for ; Thu, 02 Jun 2022 09:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JZ8UPU6ugki+PkwkthIYbz7oUO9hdXo6b9SQ7nkdwtM=; b=L/0QynMd8+v88ZZU+c9xvsS2+4IBAk0qnvPWUUmgZAkop0TG4KZxd99dk7jRpG2xjP KUc2tplVKuDgLdfIaBZhtckFNJvUhIHInGndmo36fHngmE8m6jBeiLD0zmlU+8/OdXH8 9Mhv3pV/nWVpkGYnhijstSeCiN20370swxDcIslOPlNz0qlzwWzr80kwtbP2UAzr+X5t bT2vvDe3PqbnmNaxHJbmazQRDsxxA4Yh8PekOBHYmvau5bphFYS+zjlSYH/aafxUQ8Vo hECS/upWIjnqQOS5ZSqLfaFOUr/hiOcHh2H6Rf5rblMMuM7gC2MEZPcSyYtpMgzVgJI9 7g8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JZ8UPU6ugki+PkwkthIYbz7oUO9hdXo6b9SQ7nkdwtM=; b=a1RwKaNZHHNQHajq+owJJ3N4cL10bzCW3vFQT+Jc+zvo+QCyqUC48GJLGPLib7+zA5 6O3bBwMfOnDD6ztw2MnEZVt3IX/dEzX6X41OpMPe5KSozakK57I6y0RNmpsYjUfx/TSh fijC//PBfan85ZXyQDyZqUujbhidRhJLgyXioBW30rdg6cf/CV+JDAPAR8GyWm9OwG/Y yd3PsJZIsadsTWs0V3A4774utsfbTBCzr9frMzzGl9pshUOZGxlvnMqrFZaMiwGYvGK7 bFsa8a5gNVc2JvyyMoOS5D9ggpDkRi1C1kZ93+Fdghy5q8Wb1km4bIdv2qSwaMEvDl2e SMug== X-Gm-Message-State: AOAM533GyGFEK7nb5bPCLEVOOY2JxcieovcGpcxpqb9jkpYZzpbFwIi0 qj3zy/vAxRp4tQ2zYJtGNvjlro/xA0XRRgrG8v+NvQ== X-Received: by 2002:a17:906:308f:b0:709:af33:9fa7 with SMTP id 15-20020a170906308f00b00709af339fa7mr4961024ejv.369.1654188802902; Thu, 02 Jun 2022 09:53:22 -0700 (PDT) MIME-Version: 1.0 References: <20220530102017.471865-1-jose.exposito89@gmail.com> <20220530102017.471865-2-jose.exposito89@gmail.com> In-Reply-To: From: Daniel Latypov Date: Thu, 2 Jun 2022 09:53:10 -0700 Message-ID: Subject: Re: [RFC PATCH 1/1] drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_rgb332() To: Javier Martinez Canillas Cc: =?UTF-8?B?Sm9zw6kgRXhww7NzaXRv?= , tzimmermann@suse.de, maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@linux.ie, daniel@ffwll.ch, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, kunit-dev@googlegroups.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 2, 2022 at 9:27 AM Javier Martinez Canillas wrote: > > +CFLAGS_drm_format_helper_test.o += $(DISABLE_STRUCTLEAK_PLUGIN) > > > > A comment on why this is needed would useful. Ah, I think that should not be necessary anymore. We added this to some tests to mitigate against compilers that didn't optimize away stack-local structs used internally in KUNIT_EXPECT*. Functions with ~30 or so EXPECTs could get flagged for excessively large stack frames. But in 5.18, I had some patches to reduce the naive stack usage from [48..88] => [8..32] bytes per EXPECT. I also have some RFC patches out to get it down to [0, 24] bytes. So going forward, this should only be necessary if you have something like 100s of EXPECTs in a single function (in which case you should also consider splitting that function up). Daniel