mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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