Received: by 10.192.165.148 with SMTP id m20csp877909imm; Wed, 25 Apr 2018 09:01:55 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/2nnRfxTk05WZvl6jbdy831XaW28qdqE/FYtLy8s//0Ps06QqSJSs7HR8+9ExS2Pn2/Fbt X-Received: by 10.98.15.23 with SMTP id x23mr27143068pfi.3.1524672115886; Wed, 25 Apr 2018 09:01:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524672115; cv=none; d=google.com; s=arc-20160816; b=II49b1Mg+jtUQJIbXM2Wpke3HmB/j0X+g/cJeiYAXrth+CJRkCPCB584/HSlcI3MLi +zxMyPUTifnutvC999A45mS7CCiMmQ6fP+4snc9J8FfbGLOGWWnizsLPWwxYyA1GaW8g 5KnKT1mqbrR5rK4wJ1sC4slu8vWPisj1ypji+LPeyT5c7eTKZtqu2WreCSSIDi6rdS0l lBxGNAZTDCMOxLKIPp08O303XH0wcZdBrjeUTOTD5JdsFoxcRmYlPX7+RWpdxZb2fnXL upS4ob+lP27nweHWbQOqaoaGqA8bu/5E74YhZMWYGnBeHllKkqc3kCbpQu7/333+umiS tLHA== 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:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:dkim-signature:arc-authentication-results; bh=2fGh81/TZEmFDOYMHHAO4HkQYVkxn8sphkmozDBTASU=; b=sFaDaZqqhEZuCLkdvND8Sh6ixrApTY+YprrixMQDCqtJdbNYTuHTo4Hw0s3z2Ub1zr af8zHpDjxNy51kKq0ktQJ9eHzUS8UR8IENEI/AxxzAI73D0Ayq5VfRiHUnapMnM3gNHC CYA+yfEy85hc4uB1SSW19tAo4avFCjGGcbenGfzs5riqYmL3+ZiJ3gJRgc3sYYFlPdBM +O5WMuh18VfN6b4WeKN6lmaBzQbGwXXWr4m5l7I3ajMwG+Kjgp2c1NKqGqEKnyTSOp2x cO+Xgl54nIOkc0E5ey0zaDQr9sE7KK6r4IdICtYEEWwLhUGgJQn2cwo81SStfZqzQg+V rA2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mkdwc/Oi; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u78si8937161pgb.136.2018.04.25.09.01.39; Wed, 25 Apr 2018 09:01:55 -0700 (PDT) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mkdwc/Oi; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755794AbeDYQAG (ORCPT + 99 others); Wed, 25 Apr 2018 12:00:06 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:38236 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755321AbeDYQAC (ORCPT ); Wed, 25 Apr 2018 12:00:02 -0400 Received: by mail-pf0-f196.google.com with SMTP id o76so10888633pfi.5; Wed, 25 Apr 2018 09:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=2fGh81/TZEmFDOYMHHAO4HkQYVkxn8sphkmozDBTASU=; b=mkdwc/OifyRhMx1q+TgqtySYbEB4C0JJ0i+nwj9SszdfGEmT2TyknjZcdgNuBfDmch /UAcrI6uST2G0/bT8xGHyhSdEYupuzUdFlD4BbFChbLuXmCMcZOgvNoufoEGTCumVqkQ mMV1+yF9HRn2REPDUh0ZN4SGPp1bVEqiru2JH4HcH40zjmBJ8qNUXWaxfdzKEA5wkYFm yc6F+LHNMYZJ9Vv8i46SHARCzbaFO3g2TwwvvhA+L1L88RHKsS+FJ24Ml2Kh8CSuD28w mXc19PTJy7nb1OQzU+yVAmFvbc5Ad632pi458BX5bCTBYGxmiTKlg9QLCoLfCFV2619W H8Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2fGh81/TZEmFDOYMHHAO4HkQYVkxn8sphkmozDBTASU=; b=PrGqq6IDjKFGgUoNShmu2DGYw7QasTg+HwY7Gn/GXEyoGGOAN0tlpgIgMMfWrF0k6z WYFtTGiK/ctx2ueQWoQ/r76ilmGjxJhMSJkjeak66xJejC1OmYQ3rL7K7y1tn5uVk/fK KkrdACm+pYgXFA2486xddurOl9DjWX7IpvARCfcUebj7y4l1MeM7L1FfbS+wjIgwKEOs eWLpwfn5nSLlnFUHDJhjm8lpslgAQ72ASzY1aEiOkwhe9UWR6cuc9xXFUZ761y7udB6L RcyqGyM+fLUj8Dnx63n6PZkslpYkn4p+71PjEsroeXAM548AK4R7N9t5kmk5nYUl9cJ5 EL3A== X-Gm-Message-State: ALQs6tDxtcdWk88EN4bSiDCph1w/oQTnkcJ/oYAz0r6k6FhbzqYFGZz8 tXTGVot5Dbq/NifWTuxyJ242fw== X-Received: by 10.101.75.2 with SMTP id r2mr5201976pgq.82.1524672001241; Wed, 25 Apr 2018 09:00:01 -0700 (PDT) Received: from [192.168.0.106] ([106.51.29.61]) by smtp.gmail.com with ESMTPSA id 126sm2286099pfd.130.2018.04.25.08.59.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Apr 2018 09:00:00 -0700 (PDT) Subject: Re: [PATCH] sparc: vio: use put_device() instead of kfree() To: Shannon Nelson , davem@davemloft.net, jag.raman@oracle.com, liam.merwick@oracle.com References: Cc: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org From: arvindY Message-ID: <5AE0A5FD.3060009@gmail.com> Date: Wed, 25 Apr 2018 21:29:57 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 25 April 2018 09:14 PM, Shannon Nelson wrote: > On 4/25/2018 7:56 AM, Arvind Yadav wrote: >> Never directly free @dev after calling device_register(), even >> if it returned an error. Always use put_device() to give up the >> reference initialized. >> >> Signed-off-by: Arvind Yadav >> --- >> arch/sparc/kernel/vio.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/sparc/kernel/vio.c b/arch/sparc/kernel/vio.c >> index 1a0fa10..32bae68 100644 >> --- a/arch/sparc/kernel/vio.c >> +++ b/arch/sparc/kernel/vio.c >> @@ -403,7 +403,7 @@ static struct vio_dev *vio_create_one(struct >> mdesc_handle *hp, u64 mp, >> if (err) { >> printk(KERN_ERR "VIO: Could not register device %s, err=%d\n", >> dev_name(&vdev->dev), err); >> - kfree(vdev); >> + put_device(&vdev->dev); > > Hmmm... I can see why the put_device() might be a good idea, but I > think we still need the kfree() so as to not leak the memory that was > kzalloc'd above for vdev. > There is no need to call kfree() here. Because put_device() will decrement the last reference and then free the memory by calling dev->release(It'll call vio_dev_release()). Internally put_device() -> kobject_put() -> kobject_cleanup() which is responsible to call 'dev -> release' and also free other kobject resources. If we will call kfree() here, Then It'll be a redundant call. ~arvind > sln > >> return NULL; >> } >> if (vdev->dp) >>