Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp848852pxf; Wed, 24 Mar 2021 18:25:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw22IUOYuvGaqG1UNrgrUVKh26JdgDBtgfv4G4+CBvWCeHwRC4CnXkHCIa1689uzMftWVP9 X-Received: by 2002:a17:906:7f01:: with SMTP id d1mr6848547ejr.136.1616635522914; Wed, 24 Mar 2021 18:25:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616635522; cv=none; d=google.com; s=arc-20160816; b=RdgaoIniG2J5l+m60dNlIfPxmx0bQnpg++gGC8Kac7SecdHx3bBdKbaa9eZIkIGMVa H0zHqitaChWw62Q70gfJC4ocQKUa2JVZaO2DV8YcFkfn6kZ9MwV8SqfkJhSvYiM0Bkbd XVYrNyKqFx1d3kUkt2m1kPmHq++DDxNdrfMI8e7MATRjSNXA/4ucg3YIUOjncaSU3y5/ 4f2f6BKwSaakmIcS9+12JWU9zAAE+yDGqw9EXgX/8jommAMtRs8IQTru+LUhkTY9AbXu wStfiA3LdPXwW0ReKyi3VooMyzxPnLfwQUHjDlAypqXBY1kgSKFGMFO72KPurZbr1cS7 kkPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=OnGKpgIvLuYM7scx4oRxksHU+RCOWiPa3dXT8Vz5QQ4=; b=Cex+USweasqRRQmSQ7RkVflCV4hydBht61JB/lrARlgyy8srotWN/W3+qM8o6aHRV1 mhGCUPoeZufGpV7JeXQ34pdYQp+mRnocfRKQxX2RNfNFLS2GgL1UPEdIDW4ttDiCFNCK mgIUCUzh2x7zzfvYKuLAzdbjtlheFWZD3E3PY0UEpMPjJrBY4QdjFZD22QGMk14rKs3p hgLQWwDtV+tHLVfDO8/Q5Z3i935cfM75TyqeSIEn0scq7cwVOqahgRGUxsJojPu83n4t emQgUrTly+8e23IQihovohJrHFYub/Fm5trgrPHQJz2/TrDbUjuy+OMNPIalpUXu3J6j V4vA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=t88tXejx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f24si2901468ejz.234.2021.03.24.18.24.59; Wed, 24 Mar 2021 18:25:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=t88tXejx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S230454AbhCXG5t (ORCPT + 99 others); Wed, 24 Mar 2021 02:57:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36224 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230147AbhCXG53 (ORCPT ); Wed, 24 Mar 2021 02:57:29 -0400 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E93FFC061763 for ; Tue, 23 Mar 2021 23:57:28 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id ha17so11245682pjb.2 for ; Tue, 23 Mar 2021 23:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=OnGKpgIvLuYM7scx4oRxksHU+RCOWiPa3dXT8Vz5QQ4=; b=t88tXejx64fTCDwm9tyjz18zKydYQ53MTdOrzdVa6DFMiArNYbCivM9Y3RTmtNd5z0 Xkb6ltRUaqNl/qs+y9mDZr1h4zRI0mye5kv1uZx5r9hAjhSsjs/y+C+Vlhz+e+tWXRYO /OUJXFOTPWyhprR+qOTL4CaX5/qChk71rnk04tjzfAL2yTeQSCiPfEXj+bJonQq2Akxm otdKv9oVpGu5YxcVTPd70QXMyxjIMbIVYyE2WQUQM3E7wlK1uingHsPTDGkpQtI31bGx uV2589ExFzo9iu68DDnlRpP0TEU7OK8fxY6pY6FagrvMFx/vJ87FpIVEDfpEB8N9IoIN gv+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=OnGKpgIvLuYM7scx4oRxksHU+RCOWiPa3dXT8Vz5QQ4=; b=SQ0yO62hwwjINXNmPdRYoyhOsF5RbVhmsoOwcYMwkoPNOtT1hm9YVK2p1+mG4aH5oT QbeX81/VOVGOOuZGQ9O5a3BejnG7myRZNq09mKnKH/owGklox6RAirRlDucSjkPjkp2a wZq9apl/NGz4olXmTHVNXmZWAAris9Jx379kzjCUVSNMIvpxSZ0AQuxYhW904F95FM3J 4iKvxBEFxWp02ydWrXE0V7dmEr5ojR60AVTS1VSzSxMTiQRp1Vqst14qdxW+Th+wABIq /b9vkrCZPV6XHy53P8j1+72fZzTFXvXspvGN+9FePD1+RXGgDe+pEko1wm8UGXUL5h0A cgbA== X-Gm-Message-State: AOAM531Xhsa2Epj3XNWw+i69XxbcgHCH4ILeSf3WyM7yCELV8CqqBmAn lSUhSgTEj+c3FVS03WsfeSU= X-Received: by 2002:a17:90a:ff0f:: with SMTP id ce15mr1996245pjb.15.1616569048481; Tue, 23 Mar 2021 23:57:28 -0700 (PDT) Received: from google.com ([2620:15c:211:201:7dfa:1e53:536:7976]) by smtp.gmail.com with ESMTPSA id a65sm1268299pfb.116.2021.03.23.23.57.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Mar 2021 23:57:27 -0700 (PDT) Sender: Minchan Kim Date: Tue, 23 Mar 2021 23:57:25 -0700 From: Minchan Kim To: John Hubbard Cc: Andrew Morton , linux-mm , LKML , gregkh@linuxfoundation.org, surenb@google.com, joaodias@google.com, willy@infradead.org, digetx@gmail.com Subject: Re: [PATCH v6] mm: cma: support sysfs Message-ID: References: <20210324010547.4134370-1-minchan@kernel.org> <71b7914d-d9ff-2200-d6c9-6eab28499887@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71b7914d-d9ff-2200-d6c9-6eab28499887@nvidia.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 23, 2021 at 11:26:08PM -0700, John Hubbard wrote: > On 3/23/21 10:44 PM, Minchan Kim wrote: > > On Tue, Mar 23, 2021 at 09:47:27PM -0700, John Hubbard wrote: > > > On 3/23/21 8:27 PM, Minchan Kim wrote: > > > ... > > > > > > +static int __init cma_sysfs_init(void) > > > > > > +{ > > > > > > + unsigned int i; > > > > > > + > > > > > > + cma_kobj_root = kobject_create_and_add("cma", mm_kobj); > > > > > > + if (!cma_kobj_root) > > > > > > + return -ENOMEM; > > > > > > + > > > > > > + for (i = 0; i < cma_area_count; i++) { > > > > > > + int err; > > > > > > + struct cma *cma; > > > > > > + struct cma_kobject *cma_kobj; > > > > > > + > > > > > > + cma_kobj = kzalloc(sizeof(*cma_kobj), GFP_KERNEL); > > > > > > + if (!cma_kobj) { > > > > > > + kobject_put(cma_kobj_root); > > > > > > + return -ENOMEM; > > > > > > > > > > This leaks little cma_kobj's all over the floor. :) > > > > > > > > I thought kobject_put(cma_kobj_root) should deal with it. No? > > > > > > > If this fails when i > 0, there will be cma_kobj instances that > > > were stashed in the cma_areas[] array. But this code only deletes > > > the most recently allocated cma_kobj, not anything allocated on > > > previous iterations of the loop. > > > > Oh, I misunderstood that destroying of root kobject will release > > children recursively. Seems not true. Go back to old version. > > > > > > index 16c81c9cb9b7..418951a3f138 100644 > > --- a/mm/cma_sysfs.c > > +++ b/mm/cma_sysfs.c > > @@ -80,20 +80,19 @@ static struct kobj_type cma_ktype = { > > static int __init cma_sysfs_init(void) > > { > > unsigned int i; > > + int err; > > + struct cma *cma; > > + struct cma_kobject *cma_kobj; > > > > cma_kobj_root = kobject_create_and_add("cma", mm_kobj); > > if (!cma_kobj_root) > > return -ENOMEM; > > > > for (i = 0; i < cma_area_count; i++) { > > - int err; > > - struct cma *cma; > > - struct cma_kobject *cma_kobj; > > - > > cma_kobj = kzalloc(sizeof(*cma_kobj), GFP_KERNEL); > > if (!cma_kobj) { > > - kobject_put(cma_kobj_root); > > - return -ENOMEM; > > + err = -ENOMEM; > > + goto out; > > } > > > > cma = &cma_areas[i]; > > @@ -103,11 +102,21 @@ static int __init cma_sysfs_init(void) > > cma_kobj_root, "%s", cma->name); > > if (err) { > > kobject_put(&cma_kobj->kobj); > > - kobject_put(cma_kobj_root); > > - return err; > > + goto out; > > } > > } > > > > return 0; > > +out: > > + while (--i >= 0) { > > + cma = &cma_areas[i]; > > + > > + kobject_put(&cma->kobj->kobj); > > > OK. As long as you are spinning a new version, let's fix up the naming to > be a little better, too. In this case, with a mildly dizzying mix of cma's > and kobjects, it actually makes a real difference. I wouldn't have asked, > but the above cma->kobj->kobj chain really made it obvious for me just now. > > So instead of this (in cma.h): > > struct cma_kobject { > struct cma *cma; > struct kobject kobj; > }; > > struct cma { > ... > struct cma_kobject *kobj; > }; > > , how about approximately this: > > struct cma_kobject_wrapper { > struct cma *parent; > struct kobject kobj; > }; > > struct cma { > ... > struct cma_kobject_wrapper *cma_kobj_wrapper; > }; > > > ...thus allowing readers of cma_sysfs.c to read that file more easily. I agree cma->kobj->kobj is awkward but personally, I don't like the naming: cma_kobject_wrapper parent pointer. cma_kobject is alredy wrapper so it sounds me redundant and it's not a parent in same hierarchy. Since the kobj->kobj is just one line in the code(I don't imagine it could grow up in cma_sysfs in future), I don't think it would be a problem. If we really want to make it more clear, maybe? cma->cma_kobj->kobj It would be consistent with other variables in cma_sysfs_init.