Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp4387753ioa; Wed, 27 Apr 2022 02:42:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxgyXwUMz7usVCH8us7iFVWZVpw/M3wC1+J2sy87lbKbmThVUuh+uWlUkzepHlVuUq8005f X-Received: by 2002:a17:902:b606:b0:158:f7d1:c085 with SMTP id b6-20020a170902b60600b00158f7d1c085mr27577825pls.12.1651052561168; Wed, 27 Apr 2022 02:42:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651052561; cv=none; d=google.com; s=arc-20160816; b=NK351ZiB/79M5hLE2hMJqCPX49eZtJjjmoy8Aq+CpyeytFQIqZxTy9e+yr8PQVOY8A 2+ZFioiKxQtB/NxHlJGaVCMXmx+zXWwsh/zeorsAErP82HE0/w7xkevzsOyEaDlB/wcd b/mzDT+liezZiVpXZYkc6eM0eGrcuLrtZ6dGO2xmkw1R+vj2KGSmQM1eovBx3sq8lZRz jGApAXS7zdQn06Ouzz8F2E5MTIyic7BlP0Mb1EIV5Ch04EBbOzYrVj4Q+riLCy7am9lb JCGfs2GQVV2z2b9wl7WC8MqJTE9NF6JO+4qNsm6kfaoRhrge4FoaVEt4VOR39jLcad0m IvfA== 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=sTyKSDm8OUEDphbP/fy4/ucOerWUVhiZWBgtnRYZdZw=; b=Z8+NAw81mQnBeI/jXHlsYKYiOSxqeuznxudhrI54ifXy3a/qa4xcF967zFMtVg7Myy 2U/6vDbk+rhfvUw36nhpZAGxnl0tMhvPRAWwv2a5bg7buJPZKnNz9PFeK0xGt0QbY0Rq guC6HxkpGH2a1vKPzu2YpR136qySJy5sSNRhqJQPLRJ90z+y19HdKNWiK9ui9dgzXG/t rZRXBSXXmerksj+9cg7kUmTvLqqMfBH3CpuzqsJ+MabnaTTLGRkYlpbkP+n+DZkJvMyT VXY3NQJ4lPqJbP3e+62gmyQOqFcYSZUCxzvHagHRUloquAYVz5s0u7ZHvJnn+G4tNJBg FzOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=hrSd0P29; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id 139-20020a630591000000b003aba0e9aa20si941678pgf.828.2022.04.27.02.42.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 02:42:41 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=hrSd0P29; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7346B2783E9; Wed, 27 Apr 2022 02:17:55 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355505AbiDZVfY (ORCPT + 99 others); Tue, 26 Apr 2022 17:35:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46444 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355466AbiDZVfW (ORCPT ); Tue, 26 Apr 2022 17:35:22 -0400 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD95942A0A for ; Tue, 26 Apr 2022 14:32:10 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id gh6so14584270ejb.0 for ; Tue, 26 Apr 2022 14:32:10 -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=sTyKSDm8OUEDphbP/fy4/ucOerWUVhiZWBgtnRYZdZw=; b=hrSd0P29IeYe6JLT8G7WLSBdSI48pYOP7RhBuJIBtv4ClnQVYjjErhR34j0o200+qB ZmfPY98iMRNovl+NLZxfdhxJ3/MvNXFHB9ii9TPtVwPFc2KOg2+t3+AWecp78bb59SEs k3gJZOBTeyKxuzsujMgaNfukSda0/QDU6ee1ATJySsYy756ykIh1JNgCMhQSoJ7YcWWt HWPhI/N31gng2lgoFCDipErbgkUNhhm/+YP2rVyQEZ2EWRJ4dWojw4VULFeC+PxD9Ea9 plVLdr1s5D3D0Lvs+uEbKotSgi+iVq5gk3V/rOO7Ay5N2JH0Bv9lyryuC7Tr0dznWNXf IQOw== 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=sTyKSDm8OUEDphbP/fy4/ucOerWUVhiZWBgtnRYZdZw=; b=DxMEJUu3AmmjKXzi6GkewVrtFBGrqJwG5bQGjrksUO0ov/jtzjuwSVjukqDdZ7NmbK kVsrNzKdgblB0eDgTIDG9vptUA8sy9UOkqGd5LOnln7RsZyezDgpBWzPeThIR6G03k+s jqs8WH0/pcZ9RIePJRlHNkwVfHPwiTVcmwAJImOr5UefwVGmrCWjzixA6Xt6cCfayT4J jH0A8PwQ+5cvUwzNy7NjkybPaJ/lDPXBP7FTGma1ooTkY4PmdwVHknwBfhrrp1piynoS vkBxnvL1Q2ZBmj+3o8Cln8cXw5y/eOry/r/WF4yGEsKEadyyNf7Vw3w+ejPiFdAtGd23 D7oQ== X-Gm-Message-State: AOAM530EGmtWSSsWOrVu2FEGBmnbuwCxdj8LBFQlyXWcWbQRxpQnTuvd wPsjvtP7EEluwi6myM4yhV8cgNXYb8JOdzr/72mdsw== X-Received: by 2002:a17:907:eab:b0:6da:8ec5:d386 with SMTP id ho43-20020a1709070eab00b006da8ec5d386mr23479103ejc.668.1651008729111; Tue, 26 Apr 2022 14:32:09 -0700 (PDT) MIME-Version: 1.0 References: <20220402043530.923747-1-davidgow@google.com> <20220402043530.923747-2-davidgow@google.com> In-Reply-To: <20220402043530.923747-2-davidgow@google.com> From: Brendan Higgins Date: Tue, 26 Apr 2022 17:31:57 -0400 Message-ID: Subject: Re: [PATCH v2 2/2] kunit: Rework kunit_resource allocation policy To: David Gow Cc: Daniel Latypov , Shuah Khan , kunit-dev@googlegroups.com, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,USER_IN_DEF_DKIM_WL autolearn=no 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 Sat, Apr 2, 2022 at 12:35 AM 'David Gow' via KUnit Development wrote: > > KUnit's test-managed resources can be created in two ways: > - Using the kunit_add_resource() family of functions, which accept a > struct kunit_resource pointer, typically allocated statically or on > the stack during the test. > - Using the kunit_alloc_resource() family of functions, which allocate a > struct kunit_resource using kzalloc() behind the scenes. > > Both of these families of functions accept a 'free' function to be > called when the resource is finally disposed of. > > At present, KUnit will kfree() the resource if this 'free' function is > specified, and will not if it is NULL. However, this can lead > kunit_alloc_resource() to leak memory (if no 'free' function is passed > in), or kunit_add_resource() to incorrectly kfree() memory which was > allocated by some other means (on the stack, as part of a larger > allocation, etc), if a 'free' function is provided. > > Instead, always kfree() if the resource was allocated with > kunit_alloc_resource(), and never kfree() if it was passed into > kunit_add_resource() by the user. (If the user of kunit_add_resource() > wishes the resource be kfree()ed, they can call kfree() on the resource > from within the 'free' function. > > This is implemented by adding a 'should_free' member to > struct kunit_resource and setting it appropriately. To facilitate this, > the various resource add/alloc functions have been refactored somewhat, > making them all call a __kunit_add_resource() helper after setting the > 'should_free' member appropriately. In the process, all other functions > have been made static inline functions. > > Signed-off-by: David Gow > Tested-by: Daniel Latypov Reviewed-by: Brendan Higgins