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 12:45:02 -0600 [thread overview]
Message-ID: <20151208184502.GA14814@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?
Just try to catch caller errors early on, but I'll drop these.
> Also, would something like
> kernfs_relative_depth() be a better name for the function? Maybe even
> just kernfs_depth()?
ok
> ...
> > +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?
Yeah it would, dropping them.
> Furthermore, if a and b are on different roots the above may
> give the wrong answer while not doing the above would return NULL.
Right, thanks for catching that. I'm adding a check that the
roots are the same before proceeding.
> > + 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...
Actually that __must_check seems weird, I'll just drop it. (ISTM __must_check
makes sense in a fn that does something where we worry the caller doesn't
check that it succeeded, not in a fn where we are just querying a value.
> > + 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?
ok
> > +{
> > + 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? WARN_ONCE()'s first argument is condition, so
> you'd write
>
> if (WARN_ONCE(!common, "blah blah"))
> return NULL;
D'oh. Actually once isn't even right. I'll just do WARN_ON
(and try to do it right).
> > + 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?
I can change that, but the callers right now don't re-try with
larger buffer anyway, so this would actually complicate them just
a smidgeon. Would you want them changed to do that? (pr_cont_kernfs_path
right now writes into a static char[] for instance)
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 12:45:02 -0600 [thread overview]
Message-ID: <20151208184502.GA14814@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?
Just try to catch caller errors early on, but I'll drop these.
> Also, would something like
> kernfs_relative_depth() be a better name for the function? Maybe even
> just kernfs_depth()?
ok
> ...
> > +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?
Yeah it would, dropping them.
> Furthermore, if a and b are on different roots the above may
> give the wrong answer while not doing the above would return NULL.
Right, thanks for catching that. I'm adding a check that the
roots are the same before proceeding.
> > + 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...
Actually that __must_check seems weird, I'll just drop it. (ISTM __must_check
makes sense in a fn that does something where we worry the caller doesn't
check that it succeeded, not in a fn where we are just querying a value.
> > + 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?
ok
> > +{
> > + 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? WARN_ONCE()'s first argument is condition, so
> you'd write
>
> if (WARN_ONCE(!common, "blah blah"))
> return NULL;
D'oh. Actually once isn't even right. I'll just do WARN_ON
(and try to do it right).
> > + 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?
I can change that, but the callers right now don't re-try with
larger buffer anyway, so this would actually complicate them just
a smidgeon. Would you want them changed to do that? (pr_cont_kernfs_path
right now writes into a static char[] for instance)
next prev parent reply other threads:[~2015-12-08 18:45 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
[not found] ` <20151208155251.GA30240-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2015-12-08 16:46 ` Serge E. Hallyn
2015-12-08 16:46 ` Serge E. Hallyn
2015-12-08 16:46 ` Serge E. Hallyn
2015-12-08 18:45 ` Serge E. Hallyn [this message]
2015-12-08 18:45 ` Serge E. Hallyn
2015-12-08 18:45 ` Serge E. Hallyn
2015-12-08 15:52 ` Tejun Heo
[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
[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 19:46 ` Tejun Heo
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
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-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
[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
2015-12-08 10:10 ` Alban Crequy
-- 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
2015-11-27 20:52 ` serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA
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=20151208184502.GA14814@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.