From: Tejun Heo <tj@kernel.org>
To: serge@hallyn.com
Cc: linux-kernel@vger.kernel.org, adityakali@google.com,
linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
cgroups@vger.kernel.org, lxc-devel@lists.linuxcontainers.org,
akpm@linux-foundation.org, ebiederm@xmission.com
Subject: Re: [PATCH 1/8] kernfs: Add API to generate relative kernfs path
Date: Tue, 24 Nov 2015 11:16:30 -0500 [thread overview]
Message-ID: <20151124161630.GL17033@mtj.duckdns.org> (raw)
In-Reply-To: <1447703505-29672-2-git-send-email-serge@hallyn.com>
Hello,
On Mon, Nov 16, 2015 at 01:51:38PM -0600, serge@hallyn.com wrote:
> +static char * __must_check kernfs_path_from_node_locked(
> + struct kernfs_node *kn_from,
> + struct kernfs_node *kn_to,
> + char *buf,
> + size_t buflen)
> +{
> + char *p = buf;
> + struct kernfs_node *kn;
> + size_t depth_from = 0, depth_to, d;
> int len;
>
> + /* We atleast need 2 bytes to write "/\0". */
> + BUG_ON(buflen < 2);
I don't think this is BUG worthy. Just return NULL? Also, the only
reason the original function returned char * was because the starting
point may not be the start of the buffer which helps keeping the
implementation simple. If this function is gonna be complex anyway, a
better approach would be returning ssize_t and implement a simliar
behavior to strlcpy().
> + /* Short-circuit the easy case - kn_to is the root node. */
> + if ((kn_from == kn_to) || (!kn_from && !kn_to->parent)) {
> + *p = '/';
> + *(p + 1) = '\0';
Hmm... so if kn_from == kn_to, the output is "/"?
> + return p;
> + }
> +
> + /* We can find the relative path only if both the nodes belong to the
> + * same kernfs root.
> + */
> + if (kn_from) {
> + BUG_ON(kernfs_root(kn_from) != kernfs_root(kn_to));
Ditto, just return NULL and maybe trigger WARN_ON_ONCE().
> + depth_from = kernfs_node_depth(kn_from);
> + }
> +
> + depth_to = kernfs_node_depth(kn_to);
> +
> + /* We compose path from left to right. So first write out all possible
^
, so
> + * "/.." strings needed to reach from 'kn_from' to the common ancestor.
> + */
Please fully-wing multiline comments.
> + if (kn_from) {
> + while (depth_from > depth_to) {
> + len = strlen("/..");
Maybe do something like the following instead?
const char parent_str[] = "/..";
size_t len = sizeof(parent_str) - 1;
> + if ((buflen - (p - buf)) < len + 1) {
> + /* buffer not big enough. */
> + buf[0] = '\0';
> + return NULL;
> + }
> + memcpy(p, "/..", len);
> + p += len;
> + *p = '\0';
> + --depth_from;
> + kn_from = kn_from->parent;
> }
> +
> + d = depth_to;
> + kn = kn_to;
> + while (depth_from < d) {
> + kn = kn->parent;
> + d--;
> + }
> +
> + /* Now we have 'depth_from == depth_to' at this point. Add more
Ditto with winging.
> + * "/.."s until we reach common ancestor. In the worst case,
> + * root node will be the common ancestor.
> + */
> + while (depth_from > 0) {
> + /* If we reached common ancestor, stop. */
> + if (kn_from == kn)
> + break;
> + len = strlen("/..");
> + if ((buflen - (p - buf)) < len + 1) {
> + /* buffer not big enough. */
> + buf[0] = '\0';
> + return NULL;
> + }
> + memcpy(p, "/..", len);
> + p += len;
> + *p = '\0';
> + --depth_from;
> + kn_from = kn_from->parent;
> + kn = kn->parent;
> + }
Hmmm... I wonder whether this and the above block can be merged.
Wouldn't it be simpler to calculate common ancestor and generate
/.. till it reached that point?
Thanks.
--
tejun
next prev parent reply other threads:[~2015-11-24 16:16 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-16 19:51 CGroup Namespaces (v4) serge
2015-11-16 19:51 ` [PATCH 1/8] kernfs: Add API to generate relative kernfs path serge
2015-11-24 16:16 ` Tejun Heo [this message]
2015-11-24 16:17 ` Tejun Heo
2015-11-24 17:43 ` Serge E. Hallyn
2015-11-27 5:25 ` Serge E. Hallyn
2015-11-30 15:11 ` Tejun Heo
2015-11-30 18:37 ` Serge E. Hallyn
2015-11-30 22:53 ` Tejun Heo
2015-12-01 2:08 ` Serge E. Hallyn
2015-11-16 19:51 ` [PATCH 2/8] sched: new clone flag CLONE_NEWCGROUP for cgroup namespace serge
2015-11-16 19:51 ` [PATCH 3/8] cgroup: add function to get task's cgroup serge
2015-11-24 16:27 ` Tejun Heo
2015-11-24 16:54 ` Tejun Heo
2015-11-16 19:51 ` [PATCH 4/8] cgroup: export cgroup_get() and cgroup_put() serge
2015-11-24 16:30 ` Tejun Heo
2015-11-24 22:35 ` Serge E. Hallyn
2015-11-16 19:51 ` [PATCH 5/8] cgroup: introduce cgroup namespaces serge
2015-11-24 16:49 ` Tejun Heo
2015-11-16 19:51 ` [PATCH 6/8] cgroup: cgroup namespace setns support serge
2015-11-24 16:52 ` Tejun Heo
2015-11-16 19:51 ` [PATCH 7/8] cgroup: mount cgroupns-root when inside non-init cgroupns serge
2015-11-24 17:16 ` Tejun Heo
2015-11-25 6:01 ` Serge E. Hallyn
2015-11-25 19:10 ` Tejun Heo
2015-11-25 19:55 ` Serge Hallyn
2015-11-25 19:57 ` Tejun Heo
2015-11-27 5:17 ` Serge E. Hallyn
2015-11-30 15:09 ` Tejun Heo
2015-12-01 4:07 ` Serge E. Hallyn
2015-12-01 16:46 ` Tejun Heo
2015-12-01 21:58 ` Serge E. Hallyn
2015-12-02 16:53 ` Tejun Heo
2015-12-02 16:56 ` Serge E. Hallyn
2015-12-02 16:58 ` Tejun Heo
2015-12-02 17:02 ` Serge E. Hallyn
2015-12-02 17:05 ` Tejun Heo
2015-12-03 22:47 ` Serge E. Hallyn
2015-12-07 15:39 ` Tejun Heo
2015-12-07 15:53 ` Serge Hallyn
2015-11-16 19:51 ` [PATCH 8/8] cgroup: Add documentation for cgroup namespaces serge
2015-11-24 17:16 ` Tejun Heo
2015-11-16 20:41 ` CGroup Namespaces (v4) Richard Weinberger
2015-11-16 20:46 ` Serge E. Hallyn
2015-11-16 20:50 ` Richard Weinberger
2015-11-16 20:54 ` Serge E. Hallyn
2015-11-16 22:24 ` Eric W. Biederman
2015-11-16 22:37 ` Tejun Heo
2015-11-17 1:13 ` Serge E. Hallyn
2015-11-17 1:40 ` Serge E. Hallyn
2015-11-17 3:54 ` Serge E. Hallyn
2015-11-18 2:30 ` Serge E. Hallyn
2015-11-18 9:18 ` Eric W. Biederman
2015-11-18 15:43 ` Serge E. Hallyn
2015-12-09 19:28 CGroup Namespaces (v7) serge.hallyn
2015-12-09 19:28 ` [PATCH 1/8] kernfs: Add API to generate relative kernfs path serge.hallyn
2015-12-09 21:38 ` Tejun Heo
2015-12-09 22:13 ` Serge Hallyn
2015-12-09 22:36 ` Tejun Heo
2015-12-09 22:51 ` Serge E. Hallyn
2015-12-10 1:28 ` Serge E. Hallyn
2015-12-23 4:23 CGroup Namespaces (v8) serge.hallyn
2015-12-23 4:23 ` [PATCH 1/8] kernfs: Add API to generate relative kernfs path serge.hallyn
2015-12-23 16:08 ` Tejun Heo
2015-12-23 16:36 ` Serge E. Hallyn
2015-12-23 16:24 ` Tejun Heo
2015-12-23 16:51 ` Greg KH
2016-01-04 19:54 CGroup Namespaces (v9) serge.hallyn
2016-01-04 19:54 ` [PATCH 1/8] kernfs: Add API to generate relative kernfs path serge.hallyn
2016-01-29 8:54 CGroup Namespaces (v10) serge.hallyn
2016-01-29 8:54 ` [PATCH 1/8] kernfs: Add API to generate relative kernfs path 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=20151124161630.GL17033@mtj.duckdns.org \
--to=tj@kernel.org \
--cc=adityakali@google.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lxc-devel@lists.linuxcontainers.org \
--cc=serge@hallyn.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome