| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 21 Jan 2009 01:29:01 -0800
From: Paul Menage <menage@...gle.com>
To: akpm@...ux-foundation.org
Cc: linux-kernel@...r.kernel.org
Subject: [PATCH] Fix cgroup.h comments
Fix cgroup.h comments
This patch fixes the style of some multi-line comments in cgroup.h to
match Documentation/CodingStyle
Signed-off-by: Paul Menage <menage@...gle.com>
---
(This is also my first attempt at using git/stgit for local patch
management in place of quilt - feel free to shout if this format isn't
quite how you'd like it)
include/linux/cgroup.h | 71 ++++++++++++++++++++++++++++--------------------
1 files changed, 41 insertions(+), 30 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index e4e8e11..c62627e 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -47,14 +47,18 @@ enum cgroup_subsys_id {
/* Per-subsystem/per-cgroup state maintained by the system. */
struct cgroup_subsys_state {
- /* The cgroup that this subsystem is attached to. Useful
+ /*
+ * The cgroup that this subsystem is attached to. Useful
* for subsystems that want to know about the cgroup
- * hierarchy structure */
+ * hierarchy structure
+ */
struct cgroup *cgroup;
- /* State maintained by the cgroup system to allow subsystems
+ /*
+ * State maintained by the cgroup system to allow subsystems
* to be "busy". Should be accessed via css_get(),
- * css_tryget() and and css_put(). */
+ * css_tryget() and and css_put().
+ */
atomic_t refcnt;
@@ -120,8 +124,10 @@ static inline void css_put(struct cgroup_subsys_state *css)
enum {
/* Control Group is dead */
CGRP_REMOVED,
- /* Control Group has previously had a child cgroup or a task,
- * but no longer (only if CGRP_NOTIFY_ON_RELEASE is set) */
+ /*
+ * Control Group has previously had a child cgroup or a task,
+ * but no longer (only if CGRP_NOTIFY_ON_RELEASE is set)
+ */
CGRP_RELEASABLE,
/* Control Group requires release notifications to userspace */
CGRP_NOTIFY_ON_RELEASE,
@@ -130,9 +136,10 @@ enum {
struct cgroup {
unsigned long flags; /* "unsigned long" so bitops work */
- /* count users of this cgroup. >0 means busy, but doesn't
- * necessarily indicate the number of tasks in the
- * cgroup */
+ /*
+ * count users of this cgroup. >0 means busy, but doesn't
+ * necessarily indicate the number of tasks in the cgroup
+ */
atomic_t count;
/*
@@ -142,7 +149,7 @@ struct cgroup {
struct list_head sibling; /* my parent's children */
struct list_head children; /* my children */
- struct cgroup *parent; /* my parent */
+ struct cgroup *parent; /* my parent */
struct dentry *dentry; /* cgroup fs entry, RCU protected */
/* Private pointers for each registered subsystem */
@@ -177,11 +184,12 @@ struct cgroup {
struct rcu_head rcu_head;
};
-/* A css_set is a structure holding pointers to a set of
+/*
+ * A css_set is a structure holding pointers to a set of
* cgroup_subsys_state objects. This saves space in the task struct
* object and speeds up fork()/exit(), since a single inc/dec and a
- * list_add()/del() can bump the reference count on the entire
- * cgroup set for a task.
+ * list_add()/del() can bump the reference count on the entire cgroup
+ * set for a task.
*/
struct css_set {
@@ -226,13 +234,8 @@ struct cgroup_map_cb {
void *state;
};
-/* struct cftype:
- *
- * The files in the cgroup filesystem mostly have a very simple read/write
- * handling, some common function will take care of it. Nevertheless some cases
- * (read tasks) are special and therefore I define this structure for every
- * kind of file.
- *
+/*
+ * struct cftype: handler definitions for cgroup control files
*
* When reading/writing to a file:
* - the cgroup to use is file->f_dentry->d_parent->d_fsdata
@@ -241,8 +244,10 @@ struct cgroup_map_cb {
#define MAX_CFTYPE_NAME 64
struct cftype {
- /* By convention, the name should begin with the name of the
- * subsystem, followed by a period */
+ /*
+ * By convention, the name should begin with the name of the
+ * subsystem, followed by a period
+ */
char name[MAX_CFTYPE_NAME];
int private;
@@ -321,13 +326,17 @@ struct cgroup_scanner {
struct ptr_heap *heap;
};
-/* Add a new file to the given cgroup directory. Should only be
- * called by subsystems from within a populate() method */
+/*
+ * Add a new file to the given cgroup directory. Should only be
+ * called by subsystems from within a populate() method
+ */
int cgroup_add_file(struct cgroup *cgrp, struct cgroup_subsys *subsys,
const struct cftype *cft);
-/* Add a set of new files to the given cgroup directory. Should
- * only be called by subsystems from within a populate() method */
+/*
+ * Add a set of new files to the given cgroup directory. Should
+ * only be called by subsystems from within a populate() method
+ */
int cgroup_add_files(struct cgroup *cgrp,
struct cgroup_subsys *subsys,
const struct cftype cft[],
@@ -418,7 +427,8 @@ struct cgroup_iter {
struct list_head *task;
};
-/* To iterate across the tasks in a cgroup:
+/*
+ * To iterate across the tasks in a cgroup:
*
* 1) call cgroup_iter_start to intialize an iterator
*
@@ -427,9 +437,10 @@ struct cgroup_iter {
*
* 3) call cgroup_iter_end() to destroy the iterator.
*
- * Or, call cgroup_scan_tasks() to iterate through every task in a cpuset.
- * - cgroup_scan_tasks() holds the css_set_lock when calling the test_task()
- * callback, but not while calling the process_task() callback.
+ * Or, call cgroup_scan_tasks() to iterate through every task in a
+ * cgroup - cgroup_scan_tasks() holds the css_set_lock when calling
+ * the test_task() callback, but not while calling the process_task()
+ * callback.
*/
void cgroup_iter_start(struct cgroup *cgrp, struct cgroup_iter *it);
struct task_struct *cgroup_iter_next(struct cgroup *cgrp,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists