Received: by 10.223.185.116 with SMTP id b49csp5359508wrg; Wed, 7 Mar 2018 10:23:37 -0800 (PST) X-Google-Smtp-Source: AG47ELvMFQzSMk8GBx+iD0+6gCyNPzNpg+J0FyF33LCyBmjKjlZ+XsCNBMs7abY0YhxsFWnf+LTE X-Received: by 2002:a17:902:b713:: with SMTP id d19-v6mr17859855pls.91.1520447016914; Wed, 07 Mar 2018 10:23:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520447016; cv=none; d=google.com; s=arc-20160816; b=I6ZEnU5Fyi6k2pnqDcx9hbk2/pIqH1+eeEzQO/zoq+UtuUfGs8tEKU0owMH8n9nl2e fjERZDvjO/sM+43qwCYHlRVCDVXglBqif7F05YowzLaTu/NkkTow7Mf7NZMuipkqY5Z5 kQH5GWszQ5yKFsOowpiVsNlLOPiI7P5hL3G8PdmOL22RHSsrSJD19ntakmequ9T004Ho /MaMj++krlb5ZcHsI9xPGBqVs1Wa87GeoXa+VofCuwQtNUg6rLwbavOcwuBCmbsDyWYG DnAt+HGUUy5d+iJ6FMnaYitWRl2Ff9Rq6yUqCw3jghEUCRRKj+2bHeP6vMyubO3f47/f T68A== 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=znwNlOZ0DjYMzAMOc6P8IVezbX0EsxvKeqz6qecvRTw=; b=dRT7YelexazSlVuM9YymLyBwuuN1cg2oCnKVXIezyc27OJtFzBGaA2bUKZFD9p0v5X eZ/wg0tMV/FSQajLby/WVlhsh9HdGAKVqFQ01/I62PHtdvCNjDkyCeuFdZtfJtk+ehR8 VVOGkiJiDupJyrqox1PswolK9QHWBgz7RopL/r1/YxmuWeKfgCYP7oXw3yOdQof61MRq M+6yu2sdelRYdjT7G1gQo/1LW+cDbTQrlsHROAaOzcwnKa6rVXVGB01swuOpGdNzRbXX QGzS0FFuwQR8+Bb9lHHPODSIS6EU5JcUY6zGrD9BRfjoWeRSPoXx5nJPnvGC0T8D3BJW brqQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=SLRDVEid; 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 i63si14216611pfj.365.2018.03.07.10.23.22; Wed, 07 Mar 2018 10:23:36 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=SLRDVEid; 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 S1754592AbeCGSWT (ORCPT + 99 others); Wed, 7 Mar 2018 13:22:19 -0500 Received: from mail-pl0-f65.google.com ([209.85.160.65]:38598 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754397AbeCGSWO (ORCPT ); Wed, 7 Mar 2018 13:22:14 -0500 Received: by mail-pl0-f65.google.com with SMTP id m22-v6so1798559pls.5; Wed, 07 Mar 2018 10:22:14 -0800 (PST) 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=znwNlOZ0DjYMzAMOc6P8IVezbX0EsxvKeqz6qecvRTw=; b=SLRDVEidDF7iVPQ3MM9tUqjnyjqSn7Rr+8/hJpeCBhfpBwUuOY/vO8l4SvS4U9iK0e 4Gzq2sJ+gHg7Qwcs+Uyb0zkj0pKDZfWcnVQbgCY2NlB3M9NJsYztkW1RT/H4PejT667c BN2W6ZsAwI5iN0A0r2RBnXu1118OsZj7V49PrgJ5Gl9X6qMN+4eNxbobj3OAZQIwPrut r0F64AHBhq5A8AgtnUUUIhJ/ByrPvrJRZeZhgv9YY8zJ08Fth733vDODSOna7Ux433c5 ntjcCirV5eqr6nxYU9UkZaenWNxCrBfP1RH/VT7frwtlvafMLpR6di8sj+uAq3fID5FL 19/w== 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=znwNlOZ0DjYMzAMOc6P8IVezbX0EsxvKeqz6qecvRTw=; b=YB8jlD7PsiZbTCDvHdIW2jDBU9Jgn9XCcT3eGeraZjMny+IHHyVRBtzwE6YiGHgXKt AY1Ul6lnpv0e81gWEFU5xMT4reCer7ORuwBanc1wMCbhMwma22dOzmE6Hxd5S+OvI+yh OFdDSZSRxer07kmIrVEoWM8NOPRroCw6MwwrWwHsfIEvJV/P6aKX5sEKyiPY0ULypWLU wxnYcslBUOOcopMwHJG8Hk15dsd5U5DOIixxpHukOdLQYv/jzi2kMEp+9hgdFOerIuVU XKNTpe4r7CDuBxGxFqxEKbdgHqLXVmt3tYn1heR3dS2Mez2PWRVvGmlKc/memSUD3CBj kfXg== X-Gm-Message-State: APf1xPD3Rc9kCyz/93aOELnZbb5StADzGQYwuxJRtbp5eAzGviHx1O8m 0gluI1CtBKruQYCfOczsuQUOEA== X-Received: by 2002:a17:902:7883:: with SMTP id q3-v6mr21207200pll.361.1520446933891; Wed, 07 Mar 2018 10:22:13 -0800 (PST) Received: from [192.168.0.104] ([106.51.29.61]) by smtp.gmail.com with ESMTPSA id k83sm42629513pfg.110.2018.03.07.10.22.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Mar 2018 10:22:13 -0800 (PST) Subject: Re: [PATCH] ssb:: use put_device() if device_register fail To: =?UTF-8?Q?Michael_B=c3=bcsch?= References: <20180307174700.013e20ae@wiggum> <5AA01E5E.8070002@gmail.com> <20180307183858.63172de9@wiggum> Cc: linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org From: arvindY Message-ID: <5AA02DD2.2090709@gmail.com> Date: Wed, 7 Mar 2018 23:52:10 +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: <20180307183858.63172de9@wiggum> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 07 March 2018 11:08 PM, Michael B?sch wrote: > On Wed, 7 Mar 2018 22:46:14 +0530 > arvindY wrote: >>>> diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c >>>> index 65420a9..c4449e0 100644 >>>> --- a/drivers/ssb/main.c >>>> +++ b/drivers/ssb/main.c >>>> @@ -521,6 +521,7 @@ static int ssb_devices_register(struct ssb_bus *bus) >>>> ssb_err("Could not register %s\n", dev_name(dev)); >>>> /* Set dev to NULL to not unregister >>>> * dev on error unwinding. */ >>>> + put_device(dev); >>>> sdev->dev = NULL; >>>> kfree(devwrap); >>>> goto error; >>> I don't think this is correct. >>> The dev structure is allocated as part of devwrap, which is freed here. >>> >>> Why do you think we need put_device here? >>> >> Yes this patch is not correct, We must not use kfree() after you called >> device_register() (even >> if it was not successful!) -- see the comment for device_register(). >> I will delete kfree() and send updated patch. > > Is device_put() going to call ssb_release_dev() to free the structure? > > Can you please elaborate on why device_put() must be used? The comment > is not really of any use here. > put_device() will call kobject_put(). By calling this, The kobject core will automatically clean up all of the memory allocated with the kobject. Internally kobject_put() will call kobject_cleanup() which is responsible to call 'dev -> release' and also free other kobject resources. we should always avoid kfree() if device_register() returned an error. Otherwise it'll not do clean up of other kobject resources. ~arvind