All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Vikas Shivappa <vikas.shivappa@linux.intel.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, hpa@zytor.com,
	peterz@infradead.org, ravi.v.shankar@intel.com,
	vikas.shivappa@intel.com, tony.luck@intel.com,
	fenghua.yu@intel.com, andi.kleen@intel.com
Subject: Re: [PATCH 11/21] x86/intel_rdt/cqm: Add mkdir support for RDT monitoring
Date: Sun, 2 Jul 2017 12:58:43 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1707021213020.2296@nanos> (raw)
In-Reply-To: <1498503368-20173-12-git-send-email-vikas.shivappa@linux.intel.com>

On Mon, 26 Jun 2017, Vikas Shivappa wrote:
> +/*
> + * Common code for ctrl_mon and monitor group mkdir.
> + * The caller needs to unlock the global mutex upon success.
> + */
> +static int mkdir_rdt_common(struct kernfs_node *pkn, struct kernfs_node *prkn,

pkn and prkn are horrible to distinguish. What's wrong with keeping
*parent_kn and have *kn as the new thing?

> +			    const char *name, umode_t mode,
> +			    enum rdt_group_type rtype, struct rdtgroup **r)
>  {

Can you please split out that mkdir_rdt_common() change into a separate
patch? It can be done as a preparatory stand alone change just for the
existing rdt group code. Then the monitoring add ons come on top of it.

> -	struct rdtgroup *parent, *rdtgrp;
> +	struct rdtgroup *prgrp, *rdtgrp;
>  	struct kernfs_node *kn;
> -	int ret, closid;
> -
> -	/* Only allow mkdir in the root directory */
> -	if (parent_kn != rdtgroup_default.kn)
> -		return -EPERM;
> -
> -	/* Do not accept '\n' to avoid unparsable situation. */
> -	if (strchr(name, '\n'))
> -		return -EINVAL;
> +	uint fshift = 0;
> +	int ret;
>  
> -	parent = rdtgroup_kn_lock_live(parent_kn);
> -	if (!parent) {
> +	prgrp = rdtgroup_kn_lock_live(prkn);
> +	if (!prgrp) {
>  		ret = -ENODEV;
>  		goto out_unlock;
>  	}
>  
> -	ret = closid_alloc();
> -	if (ret < 0)
> -		goto out_unlock;
> -	closid = ret;
> -
>  	/* allocate the rdtgroup. */
>  	rdtgrp = kzalloc(sizeof(*rdtgrp), GFP_KERNEL);
>  	if (!rdtgrp) {
>  		ret = -ENOSPC;
> -		goto out_closid_free;
> +		goto out_unlock;
>  	}
> -	rdtgrp->closid = closid;
> -	list_add(&rdtgrp->rdtgroup_list, &rdt_all_groups);
> +	*r = rdtgrp;
> +	rdtgrp->parent = prgrp;
> +	rdtgrp->type = rtype;
> +	INIT_LIST_HEAD(&rdtgrp->crdtgrp_list);
>  
>  	/* kernfs creates the directory for rdtgrp */
> -	kn = kernfs_create_dir(parent->kn, name, mode, rdtgrp);
> +	kn = kernfs_create_dir(pkn, name, mode, rdtgrp);
>  	if (IS_ERR(kn)) {
>  		ret = PTR_ERR(kn);
>  		goto out_cancel_ref;
> @@ -1138,27 +1166,138 @@ static int rdtgroup_mkdir(struct kernfs_node *parent_kn, const char *name,
>  	if (ret)
>  		goto out_destroy;
>  
> -	ret = rdtgroup_add_files(kn, RF_CTRL_BASE);
> +	fshift = 1 << (RF_CTRLSHIFT + rtype);
> +	ret = rdtgroup_add_files(kn, RFTYPE_BASE | fshift);


I'd rather make this:

   	files = RFTYPE_BASE | (1U << (RF_CTRLSHIFT + rtype));
	ret = rdtgroup_add_files(kn, files);

>  	if (ret)
>  		goto out_destroy;
>  
> +	if (rdt_mon_features) {
> +		ret = alloc_rmid();
> +		if (ret < 0)
> +			return ret;
> +
> +		rdtgrp->rmid = ret;
> +	}
>  	kernfs_activate(kn);
>  
> -	ret = 0;
> -	goto out_unlock;

What unlocks prkn now? The caller, right? Please add a comment ...

> +	return 0;
>  
>  out_destroy:
>  	kernfs_remove(rdtgrp->kn);
>  out_cancel_ref:
> -	list_del(&rdtgrp->rdtgroup_list);
>  	kfree(rdtgrp);
> -out_closid_free:
> +out_unlock:
> +	rdtgroup_kn_unlock(prkn);
> +	return ret;
> +}
> +
> +static void mkdir_rdt_common_clean(struct rdtgroup *rgrp)
> +{
> +	kernfs_remove(rgrp->kn);
> +	if (rgrp->rmid)
> +		free_rmid(rgrp->rmid);

Please put that conditonal into free_rmid().

> +	kfree(rgrp);
> +}
  
> +static int rdtgroup_mkdir(struct kernfs_node *pkn, const char *name,
> +			  umode_t mode)
> +{
> +	/* Do not accept '\n' to avoid unparsable situation. */
> +	if (strchr(name, '\n'))
> +		return -EINVAL;
> +
> +	/*
> +	 * We don't allow rdtgroup ctrl_mon directories to be created anywhere
> +	 * except the root directory and dont allow rdtgroup monitor
> +	 * directories to be created anywhere execept inside mon_groups
> +	 * directory.
> +	 */
> +	if (rdt_alloc_enabled && pkn == rdtgroup_default.kn)
> +		return rdtgroup_mkdir_ctrl_mon(pkn, pkn, name, mode);
> +	else if (rdt_mon_features &&
> +		 !strcmp(pkn->name, "mon_groups"))
> +		return rdtgroup_mkdir_mon(pkn, pkn->parent, name, mode);
> +	else
> +		return -EPERM;

TBH, this is really convoluted (including the comment).

	/*
	 * If the parent directory is the root directory and RDT
	 * allocation is supported, add a control and monitoring
	 * subdirectory.
	 */
	if (rdt_alloc_capable && parent_kn == rdtgroup_default.kn)
		return rdtgroup_mkdir_ctrl_mon(...);

	/*
	 * If the parent directory is a monitoring group and RDT
	 * monitoring is supported, add a monitoring subdirectory.
	 */
	 if (rdt_mon_capable && is_mon_group(parent_kn))
		return rdtgroup_mkdir_mon(...);

	 return -EPERM;

Note, that I did not use strcmp(parent_kn->name) because that's simply
not sufficient. What prevents a user from doing:

# mkdir /sys/fs/resctrl/mon_group/mon_group
# mkdir /sys/fs/resctrl/mon_group/mon_group/foo

You need a better way to distignuish that than strcmp(). You probably want
to prevent creating subdirectories named "mon_group" as well.

Thanks,

	tglx
     

  reply	other threads:[~2017-07-02 10:59 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-26 18:55 [PATCH V1 00/21] x86/cqm3: Resctrl based cqm Vikas Shivappa
2017-06-26 18:55 ` [PATCH 01/21] x86/perf/cqm: Wipe out perf " Vikas Shivappa
2017-06-26 18:55 ` [PATCH 02/21] x86/intel_rdt: Fix memory leak during mount Vikas Shivappa
2017-06-30 19:24   ` [tip:x86/urgent] x86/intel_rdt: Fix memory leak on mount failure tip-bot for Vikas Shivappa
2017-06-26 18:55 ` [PATCH 03/21] x86/intel_rdt/cqm: Documentation for resctrl based RDT Monitoring Vikas Shivappa
2017-06-26 18:55 ` [PATCH 04/21] x86/intel_rdt: Introduce a common compile option for RDT Vikas Shivappa
2017-06-26 18:55 ` [PATCH 05/21] x86/intel_rdt: Change file names to accommodate RDT monitor code Vikas Shivappa
2017-06-26 18:55 ` [PATCH 06/21] x86/intel_rdt: Cleanup namespace to support RDT monitoring Vikas Shivappa
2017-06-26 18:55 ` [PATCH 07/21] x86/intel_rdt/cqm: Add RDT monitoring initialization Vikas Shivappa
2017-07-02  9:14   ` Thomas Gleixner
2017-07-06 21:07     ` Shivappa Vikas
2017-06-26 18:55 ` [PATCH 08/21] x86/intel_rdt/cqm: Add RMID(Resource monitoring ID) management Vikas Shivappa
2017-07-02 10:05   ` Thomas Gleixner
2017-07-03  9:55     ` Thomas Gleixner
2017-07-05 15:34       ` Peter Zijlstra
2017-07-05 17:25         ` Thomas Gleixner
2017-07-11 23:54       ` Shivappa Vikas
2017-07-12 20:14         ` Thomas Gleixner
2017-07-05 17:59     ` Tony Luck
2017-07-06  6:51       ` Thomas Gleixner
2017-06-26 18:55 ` [PATCH 09/21] x86/intel_rdt: Simplify info and base file lists Vikas Shivappa
2017-07-02 10:09   ` Thomas Gleixner
2017-07-06 21:09     ` Shivappa Vikas
2017-06-26 18:55 ` [PATCH 10/21] x86/intel_rdt/cqm: Add info files for RDT monitoring Vikas Shivappa
2017-06-26 18:55 ` [PATCH 11/21] x86/intel_rdt/cqm: Add mkdir support " Vikas Shivappa
2017-07-02 10:58   ` Thomas Gleixner [this message]
2017-07-06 21:23     ` Shivappa Vikas
2017-06-26 18:55 ` [PATCH 12/21] x86/intel_rdt/cqm: Add tasks file support Vikas Shivappa
2017-07-02 11:01   ` Thomas Gleixner
2017-07-06 21:25     ` Shivappa Vikas
2017-06-26 18:56 ` [PATCH 13/21] x86/intel_rdt/cqm: Add cpus " Vikas Shivappa
2017-07-02 11:11   ` Thomas Gleixner
2017-07-06 21:26     ` Shivappa Vikas
2017-07-02 12:29   ` Thomas Gleixner
2017-07-06 21:42     ` Shivappa Vikas
2017-07-07  6:44       ` Thomas Gleixner
2017-07-13 18:37         ` Shivappa Vikas
2017-07-13 22:09     ` Shivappa Vikas
2017-06-26 18:56 ` [PATCH 14/21] x86/intel_rdt/cqm: Add mon_data Vikas Shivappa
2017-07-02 12:43   ` Thomas Gleixner
2017-07-06 21:48     ` Shivappa Vikas
2017-07-07  6:22       ` Thomas Gleixner
2017-07-11 21:17         ` Shivappa Vikas
2017-07-11 21:37           ` Luck, Tony
2017-06-26 18:56 ` [PATCH 15/21] x86/intel_rdt/cqm: Add rmdir support Vikas Shivappa
2017-07-02 13:16   ` Thomas Gleixner
2017-07-06 21:49     ` Shivappa Vikas
2017-06-26 18:56 ` [PATCH 16/21] x86/intel_rdt/cqm: Add mount,umount support Vikas Shivappa
2017-07-02 13:22   ` Thomas Gleixner
2017-07-06 21:58     ` Shivappa Vikas
2017-06-26 18:56 ` [PATCH 17/21] x86/intel_rdt/cqm: Add sched_in support Vikas Shivappa
2017-07-02 13:37   ` Thomas Gleixner
2017-07-06 23:35     ` Shivappa Vikas
2017-06-26 18:56 ` [PATCH 18/21] x86/intel_rdt/cqm: Add hotcpu support Vikas Shivappa
2017-06-26 18:56 ` [PATCH 19/21] x86/intel_rdt/mbm: Basic counting of MBM events (total and local) Vikas Shivappa
2017-07-02 13:46   ` Thomas Gleixner
2017-07-06 23:39     ` Shivappa Vikas
2017-07-07  6:47       ` Thomas Gleixner
2017-06-26 18:56 ` [PATCH 20/21] x86/intel_rdt/mbm: Add mbm counter initialization Vikas Shivappa
2017-06-26 18:56 ` [PATCH 21/21] x86/intel_rdt/mbm: Handle counter overflow Vikas Shivappa
2017-07-02 13:57   ` Thomas Gleixner
2017-07-06 23:53     ` Shivappa Vikas
2017-07-07  6:50       ` Thomas Gleixner
2017-07-10 17:54         ` Luck, Tony
2017-07-11 15:22           ` Thomas Gleixner

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=alpine.DEB.2.20.1707021213020.2296@nanos \
    --to=tglx@linutronix.de \
    --cc=andi.kleen@intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=ravi.v.shankar@intel.com \
    --cc=tony.luck@intel.com \
    --cc=vikas.shivappa@intel.com \
    --cc=vikas.shivappa@linux.intel.com \
    --cc=x86@kernel.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.