Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp319766rwd; Mon, 12 Jun 2023 14:09:55 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5u4vqmj7LelN7jXQhLR8HmRU3qe/JkOQG4162bVCKGVNtxEPMEz9VGHh5TigkwvYIlculT X-Received: by 2002:a17:907:7e97:b0:981:82c0:15bb with SMTP id qb23-20020a1709077e9700b0098182c015bbmr4567370ejc.0.1686604194922; Mon, 12 Jun 2023 14:09:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686604194; cv=none; d=google.com; s=arc-20160816; b=i+QdlWbsCD47RopJ5LZH0qT6C/6RCjL8wG0+TAPDQpuNHkcKiTCRNM+fWtBTqdesaf 9aIcCps6BVlIgSX4xMoABVul0tdaMDQPsTZ2lNEtIbWrnp+xByF87MW7UcSvAL2L3H7a COpzb3iSldb856ADg/P7Kc4AiDQrXkSFJAvXHoQXzkD28XvrvKlaF+eG4i31CZt3qijI MKl2lb5XMhFLpSb/bAQOs9c/RsOoGVfALlUk0mMXm+/KpvzCOm3coSJNuDAXcTZELYK3 gOH1iQJTGrfkYSCWI1LTqEx9V1jS3zKP18d8leIyi2nSsWfaoR+QHOe9pPwc/89N3scH 16wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=6z76a8E8dMQAUjpeJuV6I+VzSgEOP0FCiMXWVQIPMyQ=; b=gi05qrylfRxU0lg06QYn1kcDyV6rkQa6oO2vGuH9Zp0rOm0gZm+Asf8nHXoju8fE1A vddyE9q6PCmPcPgHvrES8dzTbIKDmDfxrt12755lvBkKzE/bCdHIgea5vtSfYKsP0Bzo JkCcHkZffsk+wLu4NubHFfu/STZZDZZQIE5e5jJXFaIza1R12vtNQllv+o+ZbHZfCU8q N8cJKefva/MFqOZB+wq6eF4eEmkdD4X9GZG5L/UT5a+Yfh3ASVF2OlLuDcUbsBn+tcU8 /Dz2hZ4vDQN7TtIzFYRtbp+NNG0wMfMqlHLBD+BVRhROBta1YxQl/iTuaj7En5sL2VGK cySg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Gvbcalsx; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x6-20020a170906804600b00959c6dbc904si6186271ejw.258.2023.06.12.14.09.28; Mon, 12 Jun 2023 14:09:54 -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=@kernel.org header.s=k20201202 header.b=Gvbcalsx; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238755AbjFLVD4 (ORCPT + 99 others); Mon, 12 Jun 2023 17:03:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53422 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237648AbjFLVDg (ORCPT ); Mon, 12 Jun 2023 17:03:36 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 35F433580; Mon, 12 Jun 2023 13:59:49 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9083E61D67; Mon, 12 Jun 2023 20:58:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA5E1C433D2; Mon, 12 Jun 2023 20:58:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686603522; bh=fXkX7oIWIlOkq5NlC9TIb/9beHT/MF0O6/f5nJdTlJY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GvbcalsxSZLGgQNGH0etZIKYTxfZQAKT7qU7+Ectlargwp207XE0F2iQdMa/q/pM4 7xgfg2mpIidN4eWd/WOPAsvqo0oZAkxCiYTVp1RrmySWKhuM4uW/DYGxuB6Ua1+ClE qUjDT9cChK/za4I+rVcfuu327LtkDqDA1R5W3ag7qUUV8Zal1nNfyF4JfThslBn3tm 8vgiN+vmVjjiRkmlaHkJTWXsRfxeufxC0OnZS8zmtXn+UqhwNIjBNbiagvWKoCAyXt 1CZ0YSk0x41DkSuWRLM7TfkmImeqIU+f57HEgUuJzoB/KsRlFYH974YS1gF56t22+F LlcDOaDoGcUhw== Received: by pali.im (Postfix) id 1E9D67EB; Mon, 12 Jun 2023 22:58:39 +0200 (CEST) Date: Mon, 12 Jun 2023 22:58:39 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Andy Shevchenko Cc: Michal Wilczynski , linux-acpi@vger.kernel.org, rafael@kernel.org, ilpo.jarvinen@linux.intel.com, hdegoede@redhat.com, markgross@kernel.org, fengguang.wu@intel.com, dvhart@linux.intel.com, platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1] platform/x86/dell/dell-rbtn: Fix resources leaking on error path Message-ID: <20230612205839.wxo2h2ahqcdo73rc@pali> References: <20230612090250.1417940-1-michal.wilczynski@intel.com> <20230612175205.eom2guabgfmnzrce@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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 Monday 12 June 2023 23:52:30 Andy Shevchenko wrote: > On Mon, Jun 12, 2023 at 07:52:05PM +0200, Pali Rohár wrote: > > On Monday 12 June 2023 12:02:50 Michal Wilczynski wrote: > > > Currently rbtn_add() in case of failure is leaking resources. Fix this > > > by adding a proper rollback. While at it, remove unnecessary assignment > > > of NULL to device->driver_data and unnecessary whitespace, plus add a > > > break for the default case in a switch. > > ... > > > Hello! I'm looking at rbtn_add() function and there is also code: > > > > rbtn_data = devm_kzalloc(&device->dev, sizeof(*rbtn_data), GFP_KERNEL); > > if (!rbtn_data) > > return -ENOMEM; > > > > which is called after rbtn_acquire(). So it looks like when kzalloc > > fails then there is another leak... > > Side note: In that case we would need a devm wrapper on acquire call. Does it makes sense to invest time and more resources for these fixes? Driver is not used on new Dell machines, so I would not expect new users (instead less users, if they start upgrading HW to new Dell machines). Simple fix for this issue: Just move devm_kzalloc() call before rbtn_acquire(true). And call cleanup rbtn_acquire(false) exactly like Michal did in this patch. I think that this should be enough, should cover all failure paths and does not require to introduce new code or new design, which should be properly tested for no regression. What do you think?