Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp1886934ybc; Wed, 20 Nov 2019 05:45:14 -0800 (PST) X-Google-Smtp-Source: APXvYqwc+vgk0K7fUa4+IoB7yGlUtT50H9m9hqQjg7oRh3EH6bkBktXCSNvnN8r/I3HhLaUe14OC X-Received: by 2002:a17:907:205b:: with SMTP id pg27mr5439378ejb.144.1574257514335; Wed, 20 Nov 2019 05:45:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574257514; cv=none; d=google.com; s=arc-20160816; b=B/q++IxhtbrY5yESeCihJNbfNnU/au2T1jtvherXzljmq+PtlmbnwqmXAkauRGoHfO 56HOQ75Yg7953JOVfC8gTqQXwjUTiEIB8nS77NUO2DmVBtPa5R3QYnssrFg0AdrKcZCS yG+VWsOZ0mhsSlpUKtcUt9KlAfthebHCdMfvI5P9TT3QuQ98QwkMfIt+HkM8m41XtJrL EI539HcbqrWGVocuyfaLwccJtoJ7FlnyQ5mQ9rx6v4hOdU/65gBpirQ5jbhbQ8oqcpYA ntCJSkZyTgrFxQ9pJ+gKdRnsp4unTQKrvjZYlpuka2qYQu3xC9sjl1s5vU4AVk/b0wXK 75ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:references:in-reply-to:subject:cc:to:from; bh=DU/dnKT/C9RAvAIBnF/aebC55rzj42wmzGnPrN4AV38=; b=TCCKzLZRRlP6+Upju1/2H1Hi/pFxKuNncwueVX5Oh9ty++KwOQQM+sRnINTR77Oma2 puWv0Bod/pwsNQ4RhNOzYieck3NIIOfOL4QMrwNFGCU7/hgswNGu89c12O51/8j09z8a Auwx+EajHgnuaWP0c6rePPE2/9W+OaYfeSv3lQpZdOWNSQnDokOFegTBVx8K1co+4fCg xTYchOY8HuTRwXsqqC5umFutlh9eTBdk1M2NEDi93SqqAWMXAGjhAfOr8ssEZq9q32Q1 CUSglkCGR0iM2Hg90FUGnW2s4xeZ6Sz807v8wDUEtuAXSF2koxOrarNI/PpE4UG1ECwO Vrgw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v2si15752584ejh.313.2019.11.20.05.44.50; Wed, 20 Nov 2019 05:45:14 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729999AbfKTNiT convert rfc822-to-8bit (ORCPT + 99 others); Wed, 20 Nov 2019 08:38:19 -0500 Received: from mga03.intel.com ([134.134.136.65]:43545 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729792AbfKTNiQ (ORCPT ); Wed, 20 Nov 2019 08:38:16 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2019 05:38:15 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,222,1571727600"; d="scan'208";a="200717654" Received: from um.fi.intel.com (HELO um) ([10.237.72.57]) by orsmga008.jf.intel.com with ESMTP; 20 Nov 2019 05:38:13 -0800 From: Alexander Shishkin To: Wen Yang Cc: zhiche.yy@alibaba-inc.com, xlpang@linux.alibaba.com, Greg Kroah-Hartman , linux-kernel@vger.kernel.org, alexander.shishkin@linux.intel.com Subject: Re: [PATCH] intel_th: avoid double free in error flow In-Reply-To: <7e2a501f-955a-5bd1-f70d-ad69e7223981@linux.alibaba.com> References: <20191119173447.2454-1-wenyang@linux.alibaba.com> <87y2wad7e5.fsf@ashishki-desk.ger.corp.intel.com> <7e2a501f-955a-5bd1-f70d-ad69e7223981@linux.alibaba.com> Date: Wed, 20 Nov 2019 15:38:12 +0200 Message-ID: <87v9red5x7.fsf@ashishki-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Wen Yang writes: > Another example after a few lines lower: > >         err = device_add(&thdev->dev); > >         if (err) { >                  put_device(&thdev->dev); >                  goto fail_free_res; > >          } > > device_add() has increased the reference count, > > so when it returns an error, an additional call to put_device() > > is needed here to reduce the reference count. > > So the code in this place is correct. No, device_add() drops its own extra reference in case of error (as it should), so in "if (err) ..." branch we still only have just one reference before it goes free. Regards, -- Alex