From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B76C7C433DB for ; Wed, 24 Mar 2021 06:57:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 266FF619F2 for ; Wed, 24 Mar 2021 06:57:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 266FF619F2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7C6B96B027E; Wed, 24 Mar 2021 02:57:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 776266B027F; Wed, 24 Mar 2021 02:57:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F0586B0280; Wed, 24 Mar 2021 02:57:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0027.hostedemail.com [216.40.44.27]) by kanga.kvack.org (Postfix) with ESMTP id 447AB6B027E for ; Wed, 24 Mar 2021 02:57:30 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id EE877181AEF3F for ; Wed, 24 Mar 2021 06:57:29 +0000 (UTC) X-FDA: 77953861818.35.C44B6E8 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by imf14.hostedemail.com (Postfix) with ESMTP id 7DE02C0007C9 for ; Wed, 24 Mar 2021 06:57:27 +0000 (UTC) Received: by mail-pl1-f178.google.com with SMTP id l1so7416818plg.12 for ; Tue, 23 Mar 2021 23:57:29 -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=ZmE8A4u2RoY+npXAaMKLQ5GU1tNuInjLYgTPzPSqVD2hrPcbbgq3mCstP/ztNui9gq T33QJQKah1uYDNxPAR82QkMqdnmY1j/szpUabBlXJvkiuuEVRBK8oIq5AR9CiovlFZQS uI5bU08Mq9aKeex6UwhEkoiEnKIiKxaaJOWb6asHtfJBOZGKd/j2TtBvemfv5cPQUrrV yCfJe5VcHj1yTRE5x0+UU3KB82c6UBby+LNK/dte/19QmSNgFtdRk1W6ulDMgGk3tKHh QsXaLgdKl53c/fDc3hP+k3pkWxNT0LlCPAKx1wZJB+tkSnp3BqONUmPttJV5qFP+DLuW I03w== X-Gm-Message-State: AOAM531lzzQkfjSz6hs6gXWwV7t8/JGGoLBT761HNW97/7qbPLci6gtk X+ayqfKZxv7BdLUoTMVubGE= X-Google-Smtp-Source: ABdhPJyV6LTIV3eQhlgRvDRng5tA3Ts5Kxk4NUa62fM11thJhBU9qJbpTyV/DZ9TiMeGjTn2MX6IfQ== 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) 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> X-Stat-Signature: xcw8dp7sfgm7zrg4rj3occmj5s33qn9w X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 7DE02C0007C9 Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf14; identity=mailfrom; envelope-from=""; helo=mail-pl1-f178.google.com; client-ip=209.85.214.178 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616569047-742113 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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.