From: Minchan Kim <minchan@kernel.org>
To: John Hubbard <jhubbard@nvidia.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
surenb@google.com, joaodias@google.com, willy@infradead.org
Subject: Re: [PATCH v2] mm: cma: support sysfs
Date: Tue, 9 Feb 2021 13:13:17 -0800 [thread overview]
Message-ID: <YCL67QzPiyRhhbor@google.com> (raw)
In-Reply-To: <09e60732-6a46-dd00-f9d5-4ef17ee685c8@nvidia.com>
On Tue, Feb 09, 2021 at 12:11:20PM -0800, John Hubbard wrote:
> On 2/9/21 9:49 AM, Greg KH wrote:
> > > > That's fine if you want to add it to the parent. If so, then the
> > > > kobject controls the lifetime of the structure, nothing else can.
> > >
> > > The problem was parent object(i.e., struct cma cma_areas) is
> > > static arrary so kobj->release function will be NULL or just
> > > dummy. Is it okay? I thought it was one of the what you wanted
> > > to avoid it.
> >
> > No, that is not ok.
> >
> > > > Either is fine with me, what is "forbidden" is having a kobject and
> > > > somehow thinking that it does not control the lifetime of the structure.
> > >
> > > Since parent object is static arrary, there is no need to control the
> > > lifetime so I am curious if parent object approach is okay from kobject
> > > handling point of view.
> >
> > So the array is _NEVER_ freed? If not, fine, don't provide a release
> > function for the kobject, but ick, just make a dynamic kobject I don't
> > see the problem for something so tiny and not very many...
> >
>
> Yeah, I wasn't trying to generate so much discussion, I initially thought it
> would be a minor comment: "just use an embedded struct and avoid some extra
> code", at first.
>
> > I worry that any static kobject might be copied/pasted as someone might
> > think this is an ok thing to do. And it's not an ok thing to do.
> >
>
> Overall, then, we're seeing that there is a small design hole: in order
> to use sysfs most naturally, you either much provide a dynamically allocated
> item for it, or you must use the static kobject, and the second one sets a
> bad example.
>
> I think we should just use a static kobject, with a cautionary comment to
> would-be copy-pasters, that explains the design constraints above. That way,
> we still get a nice, less-code implementation, a safe design, and it only
> really costs us a single carefully written comment.
>
> thanks,
Agreed. How about this for the warning part?
+
+/*
+ * note: kobj_type should provide a release function to free dynamically
+ * allocated object since kobject is responsible for controlling lifespan
+ * of the object. However, cma_area is static object so technially, it
+ * doesn't need release function. It's very exceptional case so pleaes
+ * do not follow this model.
+ */
static struct kobj_type cma_ktype = {
.sysfs_ops = &kobj_sysfs_ops,
.default_groups = cma_groups
+ .release = NULL, /* do not follow. See above */
};
next prev parent reply other threads:[~2021-02-09 21:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-08 18:01 [PATCH v2] mm: cma: support sysfs Minchan Kim
2021-02-08 21:34 ` John Hubbard
2021-02-08 23:36 ` Minchan Kim
2021-02-09 1:57 ` John Hubbard
2021-02-09 4:19 ` Minchan Kim
2021-02-09 5:18 ` John Hubbard
2021-02-09 5:27 ` John Hubbard
2021-02-09 6:13 ` Greg KH
2021-02-09 6:27 ` John Hubbard
2021-02-09 6:34 ` John Hubbard
2021-02-09 6:56 ` Greg KH
2021-02-09 15:55 ` Minchan Kim
2021-02-09 17:49 ` Greg KH
2021-02-09 20:11 ` John Hubbard
2021-02-09 21:13 ` Minchan Kim [this message]
2021-02-10 6:43 ` Greg KH
2021-02-10 7:12 ` Minchan Kim
2021-02-10 7:16 ` John Hubbard
2021-02-10 7:26 ` Greg KH
2021-02-10 7:50 ` John Hubbard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YCL67QzPiyRhhbor@google.com \
--to=minchan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=jhubbard@nvidia.com \
--cc=joaodias@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=surenb@google.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.