From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on gnuweeb.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by gnuweeb.org (Postfix) with ESMTPS id 5D8067E77D for ; Sat, 30 Apr 2022 13:08:10 +0000 (UTC) Authentication-Results: gnuweeb.org; dkim=pass (2048-bit key; unprotected) header.d=kernel-dk.20210112.gappssmtp.com header.i=@kernel-dk.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=F9dESD7N; dkim-atps=neutral Received: by mail-pj1-f51.google.com with SMTP id l11-20020a17090a49cb00b001d923a9ca99so9441248pjm.1 for ; Sat, 30 Apr 2022 06:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=M5VDwtLgTTW6fupYE3P3tISqyvfbw58e9xX/+aympG8=; b=F9dESD7NK1J6UEI68TT8XiZTIopSWx5BMSPjGEVRI4obs3dNKBfco8xqSumrk5ejKH pXHck6gcXl1Yx87K90+RaY5bCwmL812MeUEmV96dNVjTUOdrs+Ec42gz01EeEFRcO9z0 7Nc5nczZCg/FEozu9bFBdQ5yCYcbS6UOHV2TQRBYZANxrAQxCGDf0LBy/Lh9qsf9ComQ ixQZY5BfPARifPc5DLZ0JnD3HYUynjPNYMBtD8DPoJzLchtrqAznzvVAfquKFXL9XCRV rmbyxO5crGOvMHuX0MDqB3PsxG2fkvgur/vzMsNw5oi29FYo79Bkj5etezxsA5KU9CJR vKqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=M5VDwtLgTTW6fupYE3P3tISqyvfbw58e9xX/+aympG8=; b=YDJw+56Pj/EXu6kZGFw13PKDKMD+ZOj6ky5z0iC5FVATkcpBaqLVv0UpeOsdHXnGmb UbrqDhgCPrgL3+OWGTAayGYGURFAmrIfgxrsxojWexn1OhtNcxG6nElrbYROC4BWfUxC 6ahSi0GCr2sgtCdrmO5g/kbTYVvac8f3vh7PbUnadjZNE1iZv6q+JPgkWGNiSe0hrcwX HDvK+Wv3pj9CgrbZAaH7DqiCkp5rYYAv93GPHGcyGE41990VXpabt3k+yg1cMlZ9hlUd U3I96bz51XeluhzYqBai/xQOVWp0Fy2/C8YcAp4glxUVaiTb91ACkSXdoddjCIyTeyFr hClg== X-Gm-Message-State: AOAM533xPnzEBo/EN5yECfukn+lc9g36LW3yKTjAuejesI4NgeQs8RoW V7p4GVV0srSbJu8oEWLsXkcSkw== X-Google-Smtp-Source: ABdhPJzVKR+GBLN+VpvY5o0h71f10/m9kIp0jXG6VG6bstA/kswGO6BW4P9t7qCvVltdy5p/6NYR6Q== X-Received: by 2002:a17:90a:c302:b0:1bd:14ff:15 with SMTP id g2-20020a17090ac30200b001bd14ff0015mr9051704pjt.19.1651324088446; Sat, 30 Apr 2022 06:08:08 -0700 (PDT) Received: from [192.168.1.100] ([198.8.77.157]) by smtp.gmail.com with ESMTPSA id d16-20020a170902b71000b0015e8d4eb228sm1441112pls.114.2022.04.30.06.08.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 30 Apr 2022 06:08:07 -0700 (PDT) Message-ID: <15f7bb93-9633-23cd-976d-4b8fc3ebde51@kernel.dk> Date: Sat, 30 Apr 2022 07:08:06 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v1 8/8] client: Add ENOMEM handling on `malloc()`, `calloc()` and `strdup()` calls Content-Language: en-US To: Ammar Faizi Cc: Alviro Iskandar Setiawan , Niklas Cassel , fio Mailing List , GNU/Weeb Mailing List References: <20220429004705.260034-1-ammarfaizi2@gnuweeb.org> <20220429004705.260034-9-ammarfaizi2@gnuweeb.org> From: Jens Axboe In-Reply-To: <20220429004705.260034-9-ammarfaizi2@gnuweeb.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: On 4/28/22 6:47 PM, Ammar Faizi wrote: > From: Ammar Faizi > > Avoid a NULL pointer dereference bug. There are many places that don't > handle the ENOMEM case. Add it. > > Signed-off-by: Ammar Faizi > --- > client.c | 107 +++++++++++++++++++++++++++++++++++++++++++++---------- > 1 file changed, 89 insertions(+), 18 deletions(-) > > @@ -473,6 +478,8 @@ int fio_client_add(struct client_ops *ops, const char *hostname, void **cookie) > } > > client = get_new_client(); > + if (!client) > + return -ENOMEM; I don't think we should be using -errno in fio if we can avoid it. Are there cases where we need to discern one failure from another for alloc fixes? Looking at this case, we really just want a non-zero return. -- Jens Axboe