From: "Serge E. Hallyn" <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org,
lxc-devel-cunTk1MwBs9qMoObBWhMNEqPaTDuhLve2LY78lusg7I@public.gmane.org,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org
Subject: Re: [PATCH 1/7] kernfs: Add API to generate relative kernfs path
Date: Tue, 8 Dec 2015 10:46:26 -0600 [thread overview]
Message-ID: <20151208164626.GA13616@mail.hallyn.com> (raw)
In-Reply-To: <20151208155251.GA30240-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
On Tue, Dec 08, 2015 at 10:52:51AM -0500, Tejun Heo wrote:
> Hello, Serge.
>
> On Mon, Dec 07, 2015 at 05:06:16PM -0600, serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org wrote:
> > +/* kernfs_node_depth - compute depth from @from to @to */
> > +static size_t kernfs_node_distance(struct kernfs_node *from, struct kernfs_node *to)
> > {
> > + size_t depth = 0;
> >
> > + BUG_ON(!to);
> > + BUG_ON(!from);
>
> Do these BUG_ON()s achieve anything? Also, would something like
> kernfs_relative_depth() be a better name for the function? Maybe even
> just kernfs_depth()?
>
> ...
> > +static struct kernfs_node *kernfs_common_ancestor(struct kernfs_node *a,
> > + struct kernfs_node *b)
> > +{
> > + size_t da = kernfs_node_distance(kernfs_root(a)->kn, a);
> > + size_t db = kernfs_node_distance(kernfs_root(b)->kn, b);
> > +
> > + if (da == 0)
> > + return a;
> > + if (db == 0)
> > + return b;
>
> Hmm... are the above two ifs necessary? Wouldn't the outcome be the
> same? Furthermore, if a and b are on different roots the above may
> give the wrong answer while not doing the above would return NULL.
>
> > + while (da > db) {
> > + a = a->parent;
> > + da--;
> > + }
> > + while (db > da) {
> > + b = b->parent;
> > + db--;
> > + }
> > +
> > + /* worst case b and a will be the same at root */
> > + while (b != a) {
> > + b = b->parent;
> > + a = a->parent;
> > + }
> > +
> > + return a;
> > +}
> ...
> > +static char *
> > +__must_check kernfs_path_from_node_locked(struct kernfs_node *kn_from,
>
> Maybe
>
> static char * __must_check
> kernfs_path...
>
> > + struct kernfs_node *kn_to, char *buf,
> > + size_t buflen)
>
> Given that @kn_from is optional and is not the target node, maybe put
> @kn_to before @kn_from?
>
> > +{
> > + char *p = buf;
> > + struct kernfs_node *kn, *common;
> > + const char parent_str[] = "/..";
> > + int i;
> > + size_t depth_from, depth_to, len = 0, nlen = 0,
> > + plen = sizeof(parent_str) - 1;
>
> Heh, idk, just put plen on a separate decl?
>
> > +
> > + /* We atleast need 2 bytes to write "/\0". */
> > + if (buflen < 2)
> > + return NULL;
> > +
> > + if (!kn_from)
> > + kn_from = kernfs_root(kn_to)->kn;
> > +
> > + if (kn_from == kn_to) {
> > + *p = '/';
> > + *(++p) = '\0';
> > + return buf;
> > + }
> > +
> > + common = kernfs_common_ancestor(kn_from, kn_to);
> > + if (!common) {
> > + WARN_ONCE("%s: kn_from and kn_to on different roots\n",
> > + __func__);
> > + return NULL;
> > + }
>
> Have you compiled it?
Yup,
> WARN_ONCE()'s first argument is condition, so
> you'd write
>
> if (WARN_ONCE(!common, "blah blah"))
> return NULL;
Well that's odd, i thought I had changed all those to
pr_*. Will fix.
> > +
> > + depth_to = kernfs_node_distance(common, kn_to);
> > + depth_from = kernfs_node_distance(common, kn_from);
> > +
> > + for (i = 0; i < depth_from; i++) {
> > + if (len + plen + 1 > buflen)
> > + return NULL;
> > + strcpy(p, parent_str);
> > + p += plen;
> > + len += plen;
> > + }
> > +
> > + /* Calculate how many bytes we need for the rest */
> > + for (kn = kn_to; kn != common; kn = kn->parent)
> > + nlen += strlen(kn->name) + 1;
> > +
> > + if (len + nlen + 1 > buflen)
> > + return NULL;
>
> Hmm... if we do this anyway, maybe we can make the function behave
> more like other string formatting function (strlcpy) and return the
> would-be length instead where ret >= len indicates truncation?
Ok, will do.
WARNING: multiple messages have this Message-ID (diff)
From: "Serge E. Hallyn" <serge.hallyn@ubuntu.com>
To: Tejun Heo <tj@kernel.org>
Cc: serge.hallyn@ubuntu.com, linux-api@vger.kernel.org,
containers@lists.linux-foundation.org, hannes@cmpxchg.org,
linux-kernel@vger.kernel.org, ebiederm@xmission.com,
lxc-devel@lists.linuxcontainers.org, gregkh@linuxfoundation.org,
cgroups@vger.kernel.org, akpm@linux-foundation.org
Subject: Re: [PATCH 1/7] kernfs: Add API to generate relative kernfs path
Date: Tue, 8 Dec 2015 10:46:26 -0600 [thread overview]
Message-ID: <20151208164626.GA13616@mail.hallyn.com> (raw)
In-Reply-To: <20151208155251.GA30240@mtj.duckdns.org>
On Tue, Dec 08, 2015 at 10:52:51AM -0500, Tejun Heo wrote:
> Hello, Serge.
>
> On Mon, Dec 07, 2015 at 05:06:16PM -0600, serge.hallyn@ubuntu.com wrote:
> > +/* kernfs_node_depth - compute depth from @from to @to */
> > +static size_t kernfs_node_distance(struct kernfs_node *from, struct kernfs_node *to)
> > {
> > + size_t depth = 0;
> >
> > + BUG_ON(!to);
> > + BUG_ON(!from);
>
> Do these BUG_ON()s achieve anything? Also, would something like
> kernfs_relative_depth() be a better name for the function? Maybe even
> just kernfs_depth()?
>
> ...
> > +static struct kernfs_node *kernfs_common_ancestor(struct kernfs_node *a,
> > + struct kernfs_node *b)
> > +{
> > + size_t da = kernfs_node_distance(kernfs_root(a)->kn, a);
> > + size_t db = kernfs_node_distance(kernfs_root(b)->kn, b);
> > +
> > + if (da == 0)
> > + return a;
> > + if (db == 0)
> > + return b;
>
> Hmm... are the above two ifs necessary? Wouldn't the outcome be the
> same? Furthermore, if a and b are on different roots the above may
> give the wrong answer while not doing the above would return NULL.
>
> > + while (da > db) {
> > + a = a->parent;
> > + da--;
> > + }
> > + while (db > da) {
> > + b = b->parent;
> > + db--;
> > + }
> > +
> > + /* worst case b and a will be the same at root */
> > + while (b != a) {
> > + b = b->parent;
> > + a = a->parent;
> > + }
> > +
> > + return a;
> > +}
> ...
> > +static char *
> > +__must_check kernfs_path_from_node_locked(struct kernfs_node *kn_from,
>
> Maybe
>
> static char * __must_check
> kernfs_path...
>
> > + struct kernfs_node *kn_to, char *buf,
> > + size_t buflen)
>
> Given that @kn_from is optional and is not the target node, maybe put
> @kn_to before @kn_from?
>
> > +{
> > + char *p = buf;
> > + struct kernfs_node *kn, *common;
> > + const char parent_str[] = "/..";
> > + int i;
> > + size_t depth_from, depth_to, len = 0, nlen = 0,
> > + plen = sizeof(parent_str) - 1;
>
> Heh, idk, just put plen on a separate decl?
>
> > +
> > + /* We atleast need 2 bytes to write "/\0". */
> > + if (buflen < 2)
> > + return NULL;
> > +
> > + if (!kn_from)
> > + kn_from = kernfs_root(kn_to)->kn;
> > +
> > + if (kn_from == kn_to) {
> > + *p = '/';
> > + *(++p) = '\0';
> > + return buf;
> > + }
> > +
> > + common = kernfs_common_ancestor(kn_from, kn_to);
> > + if (!common) {
> > + WARN_ONCE("%s: kn_from and kn_to on different roots\n",
> > + __func__);
> > + return NULL;
> > + }
>
> Have you compiled it?
Yup,
> WARN_ONCE()'s first argument is condition, so
> you'd write
>
> if (WARN_ONCE(!common, "blah blah"))
> return NULL;
Well that's odd, i thought I had changed all those to
pr_*. Will fix.
> > +
> > + depth_to = kernfs_node_distance(common, kn_to);
> > + depth_from = kernfs_node_distance(common, kn_from);
> > +
> > + for (i = 0; i < depth_from; i++) {
> > + if (len + plen + 1 > buflen)
> > + return NULL;
> > + strcpy(p, parent_str);
> > + p += plen;
> > + len += plen;
> > + }
> > +
> > + /* Calculate how many bytes we need for the rest */
> > + for (kn = kn_to; kn != common; kn = kn->parent)
> > + nlen += strlen(kn->name) + 1;
> > +
> > + if (len + nlen + 1 > buflen)
> > + return NULL;
>
> Hmm... if we do this anyway, maybe we can make the function behave
> more like other string formatting function (strlcpy) and return the
> would-be length instead where ret >= len indicates truncation?
Ok, will do.
next prev parent reply other threads:[~2015-12-08 16:46 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-07 23:06 CGroup Namespaces (v6) serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA
2015-12-07 23:06 ` serge.hallyn
2015-12-07 23:06 ` [PATCH 1/7] kernfs: Add API to generate relative kernfs path serge.hallyn
[not found] ` <1449529582-4075-2-git-send-email-serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
2015-12-08 11:51 ` Greg KH
2015-12-08 11:51 ` Greg KH
[not found] ` <20151208115120.GB26797-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2015-12-09 1:17 ` Serge E. Hallyn
2015-12-09 1:17 ` Serge E. Hallyn
2015-12-08 15:52 ` Tejun Heo
2015-12-08 15:52 ` Tejun Heo
2015-12-08 15:52 ` Tejun Heo
[not found] ` <20151208155251.GA30240-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2015-12-08 16:46 ` Serge E. Hallyn [this message]
2015-12-08 16:46 ` Serge E. Hallyn
2015-12-08 16:46 ` Serge E. Hallyn
2015-12-08 18:45 ` Serge E. Hallyn
2015-12-08 18:45 ` Serge E. Hallyn
2015-12-08 18:45 ` Serge E. Hallyn
[not found] ` <1449529582-4075-1-git-send-email-serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
2015-12-07 23:06 ` serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA
2015-12-07 23:06 ` [PATCH 2/7] sched: new clone flag CLONE_NEWCGROUP for cgroup namespace serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA
2015-12-07 23:06 ` serge.hallyn
2015-12-07 23:06 ` serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA
2015-12-07 23:06 ` [PATCH 3/7] cgroup: introduce cgroup namespaces serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA
2015-12-07 23:06 ` serge.hallyn
[not found] ` <1449529582-4075-4-git-send-email-serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
2015-12-08 16:04 ` Tejun Heo
2015-12-08 16:04 ` Tejun Heo
[not found] ` <20151208160453.GB30240-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2015-12-08 19:34 ` Serge E. Hallyn
2015-12-08 19:34 ` Serge E. Hallyn
2015-12-08 19:34 ` Serge E. Hallyn
[not found] ` <20151208193431.GB14814-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2015-12-08 19:46 ` Tejun Heo
2015-12-08 19:46 ` Tejun Heo
2015-12-08 19:46 ` Tejun Heo
[not found] ` <20151208194600.GH30240-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2015-12-08 19:47 ` Serge E. Hallyn
2015-12-08 19:47 ` Serge E. Hallyn
2015-12-08 19:47 ` Serge E. Hallyn
2015-12-08 16:04 ` Tejun Heo
2015-12-07 23:06 ` [PATCH 4/7] cgroup: cgroup namespace setns support serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA
2015-12-07 23:06 ` serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA
2015-12-07 23:06 ` serge.hallyn
2015-12-07 23:06 ` [PATCH 5/7] cgroup: mount cgroupns-root when inside non-init cgroupns serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA
2015-12-07 23:06 ` serge.hallyn
[not found] ` <1449529582-4075-6-git-send-email-serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
2015-12-08 16:20 ` Tejun Heo
2015-12-08 16:20 ` Tejun Heo
[not found] ` <20151208162040.GC30240-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2015-12-08 16:48 ` Serge E. Hallyn
2015-12-08 16:48 ` Serge E. Hallyn
2015-12-08 16:48 ` Serge E. Hallyn
2015-12-08 23:21 ` Serge E. Hallyn
2015-12-08 23:21 ` Serge E. Hallyn
[not found] ` <20151208232124.GA17234-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2015-12-09 15:48 ` Tejun Heo
2015-12-09 15:48 ` Tejun Heo
2015-12-08 23:21 ` Serge E. Hallyn
2015-12-07 23:06 ` [PATCH 6/7] cgroup: Add documentation for cgroup namespaces serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA
2015-12-07 23:06 ` serge.hallyn
2015-12-08 16:22 ` Tejun Heo
[not found] ` <1449529582-4075-7-git-send-email-serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
2015-12-08 16:22 ` Tejun Heo
2015-12-07 23:06 ` [PATCH 7/7] Add FS_USERNS_FLAG to cgroup fs serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA
2015-12-07 23:06 ` serge.hallyn
2015-12-08 10:10 ` CGroup Namespaces (v6) Alban Crequy
2015-12-08 10:10 ` Alban Crequy
2015-12-08 10:10 ` Alban Crequy
[not found] ` <CAMXgnP7vq1v+DeBMcu0wQ+LznBiXujkN-_Q21NE5FPiuNw3BUg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-08 15:22 ` Serge E. Hallyn
2015-12-08 15:22 ` Serge E. Hallyn
-- strict thread matches above, loose matches on Subject: below --
2015-11-27 20:52 CGroup Namespaces (v5) serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA
[not found] ` <1448657545-531-1-git-send-email-serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
2015-11-27 20:52 ` [PATCH 1/7] kernfs: Add API to generate relative kernfs path serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA
2015-11-27 20:52 ` serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA
2015-11-27 20:52 ` serge.hallyn
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=20151208164626.GA13616@mail.hallyn.com \
--to=serge.hallyn-gewih/nmzzlqt0dzr+alfa@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lxc-devel-cunTk1MwBs9qMoObBWhMNEqPaTDuhLve2LY78lusg7I@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.