Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp940748pxv; Thu, 15 Jul 2021 20:36:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZ0Oq5iTuOGbSiozeBoUdD3RXXPaG4maA1Su1zOIidFgg23O29qIyotu39MMifbY3uT3qN X-Received: by 2002:a05:6402:49a:: with SMTP id k26mr11530627edv.279.1626406607434; Thu, 15 Jul 2021 20:36:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626406607; cv=none; d=google.com; s=arc-20160816; b=EBGg++/Afiy3GS37PmrCVFX0alr9R5qk0bxoDiimTgHypIkO+mtgeNNNAHArzyv4LQ IIjOcM50LpadM3221pbvrqR8gpWT6ImGTyoSr736PIYbPm71nhY51XxJ32H3xjv+4o60 a9Z69muun3NMzbA69D/Jd3pDYvWOF/+ReN7q2nUtiqQOsZAeCPvXUgi+HKC5qf0HA6pM KteewhByzBoc+N6EiGRwLQpzonMAU9u/eOlcb6WmqyDwe96pNzkrrF4yP4kB5/XAl+ID qbvXvS2OqvocEzvFczL0H77NWX6j36+Vk/XrVbq7/6UvUMew58TFu/kC9mbu2xoToMwP j5AQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=3o95Zg0atlOu3S7QARqgfOTllMpxRF26cOL/8Eigqrw=; b=JWk55Kt5WpwZ+690LutAr/yGh4RQ6tA2RdDEMBj4suygnNnbajaKO1ywu2WOTyOaeu MSokwx2TtNVU2R4kHslzYhp5aVNDuyzKAUEcHjv4jQ2qHHgDL2cwRucZFvEDMwWS/HKT /9p2do7T7lTovCPjRtKafIf+wumNqTUxbkyLN81HAhHHVtrTCbi4oEA+74C2G74Yi1zS /gCraV0MkgES0Q4+8Yd0Po9F6h/nvxWbP25YSrl8anDjUdga7pZ/w9r3TH2U2DGvXHqw TerBoK9QCzLpxk+f41SeN7gYIeZsxtP9FnMY9NKPpaJF7kbRoEjvLg43p0BKRskJANm6 b6lQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w10si10921655ejv.754.2021.07.15.20.36.23; Thu, 15 Jul 2021 20:36:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231481AbhGPDid (ORCPT + 99 others); Thu, 15 Jul 2021 23:38:33 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:37887 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S231230AbhGPDid (ORCPT ); Thu, 15 Jul 2021 23:38:33 -0400 Received: from callcc.thunk.org (96-65-121-81-static.hfc.comcastbusiness.net [96.65.121.81]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16G3Yvj9022484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jul 2021 23:34:58 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 72F424202F5; Thu, 15 Jul 2021 23:34:57 -0400 (EDT) Date: Thu, 15 Jul 2021 23:34:57 -0400 From: "Theodore Y. Ts'o" To: wuguanghao Cc: linux-ext4@vger.kernel.org, artem.blagodarenko@gmail.com, liuzhiqiang26@huawei.com, linfeilong@huawei.com Subject: Re: [PATCH v2 05/12] ss_create_invocation: fix memory leak and check whether NULL pointer Message-ID: References: <20210630082724.50838-2-wuguanghao3@huawei.com> <20210630082724.50838-6-wuguanghao3@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210630082724.50838-6-wuguanghao3@huawei.com> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed, Jun 30, 2021 at 04:27:17PM +0800, wuguanghao wrote: > In ss_create_invocation(), it is necessary to check whether > returned by malloc is a null pointer. > > Signed-off-by: Wu Guanghao > Signed-off-by: Zhiqiang Liu > --- > lib/ss/invocation.c | 38 ++++++++++++++++++++++++++++++++------ > 1 file changed, 32 insertions(+), 6 deletions(-) > Instead of adding all of these goto targets (which is fragile if for some reason the code gets rearranged), it would be better to make sure everything that we might want to free is initialized, i.e.: register ss_data *new_table = NULL; register ss_data **table = NULL; new_table = (ss_data *) malloc(sizeof(ss_data)); if (!new_table) goto out; memset(new_table, 0, sizeof(ss_data)); and then exit path can just look like this: out: if (new_table) { free(new_table->prompt); free(new_table->info_dirs); } free(new_table); free(table); *code_ptr = ENOMEM; return 0; ... which is much cleaner, and means in the future, you don't need to figure out which goto label you might need to jump to. Cheers, - Ted P.S. And if we are making all of these changes to the function's initializers, it might be a good time to zap the "register" keywords for any lines we are changing, or are nearby, while we're at it.