Received: by 10.213.65.68 with SMTP id h4csp252426imn; Sat, 17 Mar 2018 02:39:06 -0700 (PDT) X-Google-Smtp-Source: AG47ELsrWiedqG3Sm5EDx4Jf/A/uv1oNKxMu0VU/b35h2c3QELm/vmIuqEI+PkzTRtz4rauat6rK X-Received: by 10.99.44.22 with SMTP id s22mr3973051pgs.111.1521279546360; Sat, 17 Mar 2018 02:39:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521279546; cv=none; d=google.com; s=arc-20160816; b=RlPop7TvDTuScEMH2xxzQcOuFUOr1r4ZcDdFb99EH+k4ucLk9YtPCA51H/LY1xRnbf Nl2pLi++98xEGe/uAct3uLkjG3QHiWWCEskh92rkTylL5W7XwViMNxUwwbekNSf3Cuhu Xwe+BIGvI7v0RsC8qe0zCwUAH66EfOh+HE5Mmk/a7vMm3yMTQ1cJ/OS6Zn7kHsW3CDEv 90F8AkbHKAa2JorgHMvRgeCiamZZ0CBjrAOpZfLhtgYRVSDxJpCBvIZVRU+3T2EB+FMz Km8VgJNHACLCpibNx6rcatOt+uoYFOBa4/NDItdJWMCCVRwVomdHOxMCKK9tKT+6nf7J B8wg== 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:references:to:subject :dkim-signature:arc-authentication-results; bh=t0gmYb4/mVQiVZ4xcc10DBAdlImeGm8Tyti7Tlea0TU=; b=AWSgvLB8/8BK6EPgfFpGnV3afl3auTPVtqjvySPYrTzon2heH0GMT8O3xyZSVyF1Ol LaMRXZ5ZGi0LIIyRk1vIvRhwBspx7N/On9Ap/3bZ+51JG1Rtl5VKGZYWf9AQ9uOJjPDe JzSRJ6jkcF06AClcCensgC1wQ9v+7i12Yu8QdTA8lfKWIun23XvPBJH7CC/B/W0FKYpl jSt6DbJd+UJU3HY1Y8k/lSnYmoqsbbwjKc5d1F9dPrutn188rlj23Cd8L0qjkw13S3VW cLXw+DUVSrP687WP9pNpssV8g+yuHsaCkUN+xxD1arAeUQQ2RAirS0/XBLtrkF/XfHfe mVsg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mwesaGol; 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 a63-v6si1768413pla.718.2018.03.17.02.38.51; Sat, 17 Mar 2018 02:39:06 -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=mwesaGol; 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 S1751832AbeCQJiB (ORCPT + 99 others); Sat, 17 Mar 2018 05:38:01 -0400 Received: from mail-it0-f65.google.com ([209.85.214.65]:55001 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750888AbeCQJh7 (ORCPT ); Sat, 17 Mar 2018 05:37:59 -0400 Received: by mail-it0-f65.google.com with SMTP id w3-v6so4870470itc.4; Sat, 17 Mar 2018 02:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=t0gmYb4/mVQiVZ4xcc10DBAdlImeGm8Tyti7Tlea0TU=; b=mwesaGol5O73YO5LVJ04S129IrLd6/FyisKRN08fZdikN1Y6MRn0EwI8rqQMXPNfQ4 E5IZj6sCnyE9UFtRnIZKxCwqy8tAnL9OFYkDIZaa118wHFnKS43NyfVX+8W2ymwg7ajj p3N8t7fBhXKZUMFGwt+09SjLG/y9PNc4HEWhlX6RMKQzKymDLkR2SmJdi6EP/go34TjJ lsAC4JN+66mBByo8qo64xUwkZwOQ8rATk43By/QX0iYbgDjxzR3Qwfvf/ejulLwQ5VcG aW4ZGe6r4hEcDtv3tKaW7jY42HFfhYnegcuPM+EuD+xKIBlZGemX/D0gWHwRuui/dTom CbPA== 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:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=t0gmYb4/mVQiVZ4xcc10DBAdlImeGm8Tyti7Tlea0TU=; b=XFFYhO0he7YPXRM+MWXaFTyw9iaQOb6t2IYkj63FZZ08oFXrF2E6ycZhfdby0KR21y EwFwGPmQrYBQ2J/AjIXpP1r3dwKnp9Q/B/vMbzySV4PBE1pXreK4VrBC/pZ9wZ4p0QaT q/bdNJ560VgWs1fa1pYv6v42KbfO5DrfoGouUCl0YYKA7yBnCUzgsYhnssUtTotdRgpT t+OVJsyBpsqchmCsYPGuAxSxl8ZzlvSgD+OFS/VwTFGrnhniooVECsLdTJ/g2ZiNpSLg g5EnvsZM8eJUcBWl3PnN1iDxzwLn8MeX/2xcnFziuWZfRoLWF4Me9o3wO6YgYUC+fdMX Zcdw== X-Gm-Message-State: AElRT7GRRkW2SebOO7CgbezPnBarL8YTiVBfWIr0/HpFjat/wVPO2fZk ao3+oaVskawTP1tLIr6iTKCGzQ== X-Received: by 2002:a24:f04d:: with SMTP id p13-v6mr5606478iti.72.1521279478624; Sat, 17 Mar 2018 02:37:58 -0700 (PDT) Received: from [192.168.0.103] ([106.51.29.61]) by smtp.gmail.com with ESMTPSA id v18sm5744012ita.22.2018.03.17.02.37.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Mar 2018 02:37:57 -0700 (PDT) Subject: Re: [PATCH] scsi: scsi_transport_iscsi: use put_device() instead of kfree() To: Chris Leech , lduncan@suse.com, jejb@linux.vnet.ibm.com, martin.petersen@oracle.com, linux-kernel@vger.kernel.org, open-iscsi@googlegroups.com, linux-scsi@vger.kernel.org References: <20180315174448.GB32176@straylight.hirudinean.org> From: arvindY Message-ID: <5AACE1F0.1080109@gmail.com> Date: Sat, 17 Mar 2018 15:07:52 +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: <20180315174448.GB32176@straylight.hirudinean.org> Content-Type: text/plain; charset=windows-1252; 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 Thursday 15 March 2018 11:14 PM, Chris Leech wrote: > On Wed, Mar 07, 2018 at 05:07:33PM +0530, 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 >> --- >> drivers/scsi/scsi_transport_iscsi.c | 27 +++++++++++++-------------- >> 1 file changed, 13 insertions(+), 14 deletions(-) >> >> @@ -783,7 +781,7 @@ struct iscsi_iface * >> >> free_iface: >> put_device(iface->dev.parent); >> - kfree(iface); >> + put_device(&iface->dev); >> return NULL; >> } >> EXPORT_SYMBOL_GPL(iscsi_create_iface); > Am I reading the device code correctly that the parent reference is only > released in the unregister path (device_unregister calls device_del) and > so the manual put_device on the parent here is still correct? > > Just want to make sure that's still needed with the call to put_device. The manual put_device on the parent is not correct. This should be removed for here. we should call put_device(&iface->dev) only and It'll released parent reference. > Other than that question, I this all looks good. > Thanks. > > Signed-off-by: Chris Leech > ~arvind