From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 79E28C32771 for ; Wed, 28 Sep 2022 21:51:01 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id DC26483914; Wed, 28 Sep 2022 23:50:58 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="pAz95xC2"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 58E7C838DB; Wed, 28 Sep 2022 23:50:57 +0200 (CEST) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 9354A83B43 for ; Wed, 28 Sep 2022 23:50:54 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=seanga2@gmail.com Received: by mail-qv1-xf2b.google.com with SMTP id x13so1905409qvn.4 for ; Wed, 28 Sep 2022 14:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=A1wAHPxVhDpe3zqhihZU28aYnwI8SmUwjU4IgY9ONoE=; b=pAz95xC2hDzNp+Jx5mYUznC+gufyM4vtzilCfOU5jsdCxnyxVYrFYWSHjsiu9zB02Q Hno7ioaUl4RiYPvAzD/Tqc1CeyaaafuPn9g3NWGGLkUrJ8clYSVxtz9Xx6+gGCzZyoeS u+aKFOEcAQ7HGVsDAyiwYKN3WmxQWXPLz11eBvKIp4gnGkRqNLuhOyVaPpPHB8Te7YMA 9KxlQFtCThy27mOCIR7guwdjdpF0yEDlP9+/UhS4PRhw2xeCxOZl6rqzFTUQ6cOdBv4H RS4nv2+YgUnNkuWtnjx+mFCDmEq4qOxNI8QDccbHU1CsoC1PWjpg9apAr4xDS8MpYxi3 KSIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=A1wAHPxVhDpe3zqhihZU28aYnwI8SmUwjU4IgY9ONoE=; b=6r44c4vi/V8h7rWChoP4TNjq/OMJGnwcQZOh+1qFBuVUlM/tg0wHVMhcjqHqt7h00+ Mww3wEdwnQCnE7vwFboewqNbz9dk4EZWGBdrxZezuBNWV2FNGoWxYB1r0MVCVMfmiUKw LXSw3bKAIJAqtYolBQe5A0kFV52cEDm+asGkaxK76ZTCE01SsMhd6yOAYAYYic+1eReG s8CVP/1kFHAzkaeGbm+K86LlkqnP0XcCh1SBhMk+yFX5zUrSDA+hDW9BTDCeJGdDGytR 3mWKmwYuG91qMe5uJO22QRqxA3EIqAkcBQTkbP31J7JtGGQRWFfLiRheeGhFufFOf6i5 9vNg== X-Gm-Message-State: ACrzQf0QFXzPZ34mvbm65k4nU7LgRXR8065ZqWJyEWRxq58DMLVu5Ez0 XOawLlSPty5Go2UFQGKyVuU= X-Google-Smtp-Source: AMsMyM5sxJyxTuzq17WXy+s9rjakutz1UKzI1sFj2Uvefg7yKZkC7K8GoBMiHAlbmPoNsOsKGBuCbA== X-Received: by 2002:a05:6214:29e7:b0:4af:487d:c049 with SMTP id jv7-20020a05621429e700b004af487dc049mr149434qvb.96.1664401853286; Wed, 28 Sep 2022 14:50:53 -0700 (PDT) Received: from [192.168.1.201] (pool-173-73-95-180.washdc.fios.verizon.net. [173.73.95.180]) by smtp.gmail.com with ESMTPSA id az11-20020a05620a170b00b006b615cd8c13sm3950457qkb.106.2022.09.28.14.50.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Sep 2022 14:50:52 -0700 (PDT) Message-ID: <90ea7fd1-e162-098d-37e7-90505fd7a408@gmail.com> Date: Wed, 28 Sep 2022 17:50:51 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v2 12/45] test: Support testing malloc() failures Content-Language: en-US To: Simon Glass Cc: U-Boot Mailing List , Kishon Vijay Abraham I , Michal Simek , =?UTF-8?Q?Marek_Beh=c3=ban?= , Tom Rini , Heinrich Schuchardt References: <20220907022733.66423-1-sjg@chromium.org> <20220907022733.66423-13-sjg@chromium.org> From: Sean Anderson In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean On 9/28/22 17:06, Simon Glass wrote: > Hi Sean, > > On Wed, 28 Sept 2022 at 11:18, Sean Anderson wrote: >> >> On 9/6/22 22:27, Simon Glass wrote: >>> It is helpful to test that out-of-memory checks work correctly in code >>> that calls malloc(). >>> >>> Add a simple way to force failure after a given number of malloc() calls. >>> >>> Fix a header guard to avoid a build error on sandbox_vpl. >>> >>> Signed-off-by: Simon Glass >>> --- >>> >>> (no changes since v1) >>> >>> arch/sandbox/include/asm/malloc.h | 1 + >>> common/dlmalloc.c | 19 +++++++++++++++++++ >>> include/malloc.h | 12 ++++++++++++ >>> test/test-main.c | 1 + >>> 4 files changed, 33 insertions(+) >>> >>> diff --git a/arch/sandbox/include/asm/malloc.h b/arch/sandbox/include/asm/malloc.h >>> index a1467b5eadd..8aaaa9cb87b 100644 >>> --- a/arch/sandbox/include/asm/malloc.h >>> +++ b/arch/sandbox/include/asm/malloc.h >>> @@ -6,6 +6,7 @@ >>> */ >>> >>> #ifndef __ASM_MALLOC_H >>> +#define __ASM_MALLOC_H >>> >>> void *malloc(size_t size); >>> void free(void *ptr); >>> diff --git a/common/dlmalloc.c b/common/dlmalloc.c >>> index f48cd2a333d..41c7230424c 100644 >>> --- a/common/dlmalloc.c >>> +++ b/common/dlmalloc.c >>> @@ -596,6 +596,9 @@ ulong mem_malloc_start = 0; >>> ulong mem_malloc_end = 0; >>> ulong mem_malloc_brk = 0; >>> >>> +static bool malloc_testing; /* enable test mode */ >>> +static int malloc_max_allocs; /* return NULL after this many calls to malloc() */ >>> + >>> void *sbrk(ptrdiff_t increment) >>> { >>> ulong old = mem_malloc_brk; >>> @@ -1307,6 +1310,11 @@ Void_t* mALLOc(bytes) size_t bytes; >>> return malloc_simple(bytes); >>> #endif >>> >>> + if (CONFIG_IS_ENABLED(UNIT_TEST) && malloc_testing) { >>> + if (--malloc_max_allocs < 0) >>> + return NULL; >>> + } >>> + >>> /* check if mem_malloc_init() was run */ >>> if ((mem_malloc_start == 0) && (mem_malloc_end == 0)) { >>> /* not initialized yet */ >>> @@ -2470,6 +2478,17 @@ int initf_malloc(void) >>> return 0; >>> } >>> >>> +void malloc_enable_testing(int max_allocs) >>> +{ >>> + malloc_testing = true; >>> + malloc_max_allocs = max_allocs; >>> +} >>> + >>> +void malloc_disable_testing(void) >>> +{ >>> + malloc_testing = false; >>> +} >>> + >>> /* >>> >>> History: >>> diff --git a/include/malloc.h b/include/malloc.h >>> index e8c8b254c0d..161ccbd1298 100644 >>> --- a/include/malloc.h >>> +++ b/include/malloc.h >>> @@ -883,6 +883,18 @@ extern Void_t* sbrk(); >>> >>> void malloc_simple_info(void); >>> >>> +/** >>> + * malloc_enable_testing() - Put malloc() into test mode >>> + * >>> + * This only works if UNIT_TESTING is enabled >>> + * >>> + * @max_allocs: return -ENOMEM after max_allocs calls to malloc() >>> + */ >>> +void malloc_enable_testing(int max_allocs); >>> + >>> +/** malloc_disable_testing() - Put malloc() into normal mode */ >>> +void malloc_disable_testing(void); >>> + >>> #if CONFIG_IS_ENABLED(SYS_MALLOC_SIMPLE) >>> #define malloc malloc_simple >>> #define realloc realloc_simple >>> diff --git a/test/test-main.c b/test/test-main.c >>> index c65cbd7c351..5b6b5ba5bbe 100644 >>> --- a/test/test-main.c >>> +++ b/test/test-main.c >>> @@ -46,6 +46,7 @@ static int dm_test_pre_run(struct unit_test_state *uts) >>> uts->force_fail_alloc = false; >>> uts->skip_post_probe = false; >>> gd->dm_root = NULL; >>> + malloc_disable_testing(); >>> if (CONFIG_IS_ENABLED(UT_DM) && !CONFIG_IS_ENABLED(OF_PLATDATA)) >>> memset(dm_testdrv_op_count, '\0', sizeof(dm_testdrv_op_count)); >>> arch_reset_for_test(); >> >> Reviewed-by: Sean Anderson >> >> but do we need to instrument rEALLOc too? > > We could, but I'd prefer to have a test which needs it first. Actually > realloc() calls malloc() in some cases, so we are already messing with > things here. Maybe it would be better to do this at the "top-level" instead. E.g. redefine the malloc() et al macro. That way we remove any double-counting. --Sean