* [PATCH] cgroup: Fix typo in comments and documents
@ 2021-07-30 5:16 ` Cai Huoqing
0 siblings, 0 replies; 14+ messages in thread
From: Cai Huoqing @ 2021-07-30 5:16 UTC (permalink / raw)
To: tj, lizefan.x, hannes, corbet; +Cc: cgroups, linux-doc, Cai Huoqing
Fix typo: iff ==> if
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
---
Documentation/admin-guide/cgroup-v1/cgroups.rst | 2 +-
Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst | 4 ++--
kernel/cgroup/cgroup-v1.c | 4 ++--
kernel/cgroup/cgroup.c | 6 +++---
kernel/cgroup/cpuset.c | 4 ++--
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v1/cgroups.rst b/Documentation/admin-guide/cgroup-v1/cgroups.rst
index b0688011ed06..fa747466e304 100644
--- a/Documentation/admin-guide/cgroup-v1/cgroups.rst
+++ b/Documentation/admin-guide/cgroup-v1/cgroups.rst
@@ -573,7 +573,7 @@ cgroup_for_each_descendant_pre() for details.
``void css_offline(struct cgroup *cgrp);``
(cgroup_mutex held by caller)
-This is the counterpart of css_online() and called iff css_online()
+This is the counterpart of css_online() and called if css_online()
has succeeded on @cgrp. This signifies the beginning of the end of
@cgrp. @cgrp is being removed and the subsystem should start dropping
all references it's holding on @cgrp. When all references are dropped,
diff --git a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
index 582d3427de3f..a908c5226bde 100644
--- a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
+++ b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
@@ -56,7 +56,7 @@ expected.
The cgroup freezer is hierarchical. Freezing a cgroup freezes all
tasks belonging to the cgroup and all its descendant cgroups. Each
cgroup has its own state (self-state) and the state inherited from the
-parent (parent-state). Iff both states are THAWED, the cgroup is
+parent (parent-state). If both states are THAWED, the cgroup is
THAWED.
The following cgroupfs files are created by cgroup freezer.
@@ -87,7 +87,7 @@ The following cgroupfs files are created by cgroup freezer.
* freezer.self_freezing: Read only.
Shows the self-state. 0 if the self-state is THAWED; otherwise, 1.
- This value is 1 iff the last write to freezer.state was "FROZEN".
+ This value is 1 if the last write to freezer.state was "FROZEN".
* freezer.parent_freezing: Read only.
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index de2c432dee20..71d2b46d1968 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -120,7 +120,7 @@ int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from)
goto out_err;
/*
- * Migrate tasks one-by-one until @from is empty. This fails iff
+ * Migrate tasks one-by-one until @from is empty. This fails if
* ->can_attach() fails.
*/
do {
@@ -215,7 +215,7 @@ static void cgroup_pidlist_destroy_work_fn(struct work_struct *work)
mutex_lock(&l->owner->pidlist_mutex);
/*
- * Destroy iff we didn't get queued again. The state won't change
+ * Destroy if we didn't get queued again. The state won't change
* as destroy_dwork can only be queued while locked.
*/
if (!delayed_work_pending(dwork)) {
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 3a0161c21b6b..b831554372a2 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -793,7 +793,7 @@ static bool css_set_populated(struct css_set *cset)
* One of the css_sets associated with @cgrp is either getting its first
* task or losing the last. Update @cgrp->nr_populated_* accordingly. The
* count is propagated towards root so that a given cgroup's
- * nr_populated_children is zero iff none of its descendants contain any
+ * nr_populated_children is zero if none of its descendants contain any
* tasks.
*
* @cgrp's interface file "cgroup.populated" is zero if both
@@ -2410,7 +2410,7 @@ struct task_struct *cgroup_taskset_next(struct cgroup_taskset *tset,
* @mgctx: migration context
*
* Migrate tasks in @mgctx as setup by migration preparation functions.
- * This function fails iff one of the ->can_attach callbacks fails and
+ * This function fails if one of the ->can_attach callbacks fails and
* guarantees that either all or none of the tasks in @mgctx are migrated.
* @mgctx is consumed regardless of success.
*/
@@ -4264,7 +4264,7 @@ struct cgroup_subsys_state *css_next_child(struct cgroup_subsys_state *pos,
* increasing unique serial number and always appended to the
* sibling list, the next one can be found by walking the parent's
* children until the first css with higher serial number than
- * @pos's. While this path can be slower, it happens iff iteration
+ * @pos's. While this path can be slower, it happens if iteration
* races against release and the race window is very small.
*/
if (!pos) {
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index adb5190c4429..f09fc0347550 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -782,7 +782,7 @@ static int generate_sched_domains(cpumask_var_t **domains,
if (cp == &top_cpuset)
continue;
/*
- * Continue traversing beyond @cp iff @cp has some CPUs and
+ * Continue traversing beyond @cp if @cp has some CPUs and
* isn't load balancing. The former is obvious. The
* latter: All child cpusets contain a subset of the
* parent's cpus, so just skip them, and then we call
@@ -1801,7 +1801,7 @@ static int update_nodemask(struct cpuset *cs, struct cpuset *trialcs,
}
/*
- * An empty mems_allowed is ok iff there are no tasks in the cpuset.
+ * An empty mems_allowed is ok if there are no tasks in the cpuset.
* Since nodelist_parse() fails on an empty mask, we special case
* that parsing. The validate_change() call ensures that cpusets
* with tasks have memory.
--
2.25.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH] cgroup: Fix typo in comments and documents
2021-07-30 5:16 ` Cai Huoqing
@ 2021-07-30 13:43 ` Hu Haowen
-1 siblings, 0 replies; 14+ messages in thread
From: Hu Haowen @ 2021-07-30 13:43 UTC (permalink / raw)
To: Cai Huoqing, tj, lizefan.x, hannes, corbet; +Cc: cgroups, linux-doc
在 2021/7/30 下午1:16, Cai Huoqing 写道:
> Fix typo: iff ==> if
>
> Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Reviewed-by: Hu Haowen <src.res@email.cn>
> ---
> Documentation/admin-guide/cgroup-v1/cgroups.rst | 2 +-
> Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst | 4 ++--
> kernel/cgroup/cgroup-v1.c | 4 ++--
> kernel/cgroup/cgroup.c | 6 +++---
> kernel/cgroup/cpuset.c | 4 ++--
> 5 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/admin-guide/cgroup-v1/cgroups.rst b/Documentation/admin-guide/cgroup-v1/cgroups.rst
> index b0688011ed06..fa747466e304 100644
> --- a/Documentation/admin-guide/cgroup-v1/cgroups.rst
> +++ b/Documentation/admin-guide/cgroup-v1/cgroups.rst
> @@ -573,7 +573,7 @@ cgroup_for_each_descendant_pre() for details.
> ``void css_offline(struct cgroup *cgrp);``
> (cgroup_mutex held by caller)
>
> -This is the counterpart of css_online() and called iff css_online()
> +This is the counterpart of css_online() and called if css_online()
> has succeeded on @cgrp. This signifies the beginning of the end of
> @cgrp. @cgrp is being removed and the subsystem should start dropping
> all references it's holding on @cgrp. When all references are dropped,
> diff --git a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
> index 582d3427de3f..a908c5226bde 100644
> --- a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
> +++ b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
> @@ -56,7 +56,7 @@ expected.
> The cgroup freezer is hierarchical. Freezing a cgroup freezes all
> tasks belonging to the cgroup and all its descendant cgroups. Each
> cgroup has its own state (self-state) and the state inherited from the
> -parent (parent-state). Iff both states are THAWED, the cgroup is
> +parent (parent-state). If both states are THAWED, the cgroup is
> THAWED.
>
> The following cgroupfs files are created by cgroup freezer.
> @@ -87,7 +87,7 @@ The following cgroupfs files are created by cgroup freezer.
> * freezer.self_freezing: Read only.
>
> Shows the self-state. 0 if the self-state is THAWED; otherwise, 1.
> - This value is 1 iff the last write to freezer.state was "FROZEN".
> + This value is 1 if the last write to freezer.state was "FROZEN".
>
> * freezer.parent_freezing: Read only.
>
> diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
> index de2c432dee20..71d2b46d1968 100644
> --- a/kernel/cgroup/cgroup-v1.c
> +++ b/kernel/cgroup/cgroup-v1.c
> @@ -120,7 +120,7 @@ int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from)
> goto out_err;
>
> /*
> - * Migrate tasks one-by-one until @from is empty. This fails iff
> + * Migrate tasks one-by-one until @from is empty. This fails if
> * ->can_attach() fails.
> */
> do {
> @@ -215,7 +215,7 @@ static void cgroup_pidlist_destroy_work_fn(struct work_struct *work)
> mutex_lock(&l->owner->pidlist_mutex);
>
> /*
> - * Destroy iff we didn't get queued again. The state won't change
> + * Destroy if we didn't get queued again. The state won't change
> * as destroy_dwork can only be queued while locked.
> */
> if (!delayed_work_pending(dwork)) {
> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> index 3a0161c21b6b..b831554372a2 100644
> --- a/kernel/cgroup/cgroup.c
> +++ b/kernel/cgroup/cgroup.c
> @@ -793,7 +793,7 @@ static bool css_set_populated(struct css_set *cset)
> * One of the css_sets associated with @cgrp is either getting its first
> * task or losing the last. Update @cgrp->nr_populated_* accordingly. The
> * count is propagated towards root so that a given cgroup's
> - * nr_populated_children is zero iff none of its descendants contain any
> + * nr_populated_children is zero if none of its descendants contain any
> * tasks.
> *
> * @cgrp's interface file "cgroup.populated" is zero if both
> @@ -2410,7 +2410,7 @@ struct task_struct *cgroup_taskset_next(struct cgroup_taskset *tset,
> * @mgctx: migration context
> *
> * Migrate tasks in @mgctx as setup by migration preparation functions.
> - * This function fails iff one of the ->can_attach callbacks fails and
> + * This function fails if one of the ->can_attach callbacks fails and
> * guarantees that either all or none of the tasks in @mgctx are migrated.
> * @mgctx is consumed regardless of success.
> */
> @@ -4264,7 +4264,7 @@ struct cgroup_subsys_state *css_next_child(struct cgroup_subsys_state *pos,
> * increasing unique serial number and always appended to the
> * sibling list, the next one can be found by walking the parent's
> * children until the first css with higher serial number than
> - * @pos's. While this path can be slower, it happens iff iteration
> + * @pos's. While this path can be slower, it happens if iteration
> * races against release and the race window is very small.
> */
> if (!pos) {
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index adb5190c4429..f09fc0347550 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -782,7 +782,7 @@ static int generate_sched_domains(cpumask_var_t **domains,
> if (cp == &top_cpuset)
> continue;
> /*
> - * Continue traversing beyond @cp iff @cp has some CPUs and
> + * Continue traversing beyond @cp if @cp has some CPUs and
> * isn't load balancing. The former is obvious. The
> * latter: All child cpusets contain a subset of the
> * parent's cpus, so just skip them, and then we call
> @@ -1801,7 +1801,7 @@ static int update_nodemask(struct cpuset *cs, struct cpuset *trialcs,
> }
>
> /*
> - * An empty mems_allowed is ok iff there are no tasks in the cpuset.
> + * An empty mems_allowed is ok if there are no tasks in the cpuset.
> * Since nodelist_parse() fails on an empty mask, we special case
> * that parsing. The validate_change() call ensures that cpusets
> * with tasks have memory.
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH] cgroup: Fix typo in comments and documents
@ 2021-07-30 13:43 ` Hu Haowen
0 siblings, 0 replies; 14+ messages in thread
From: Hu Haowen @ 2021-07-30 13:43 UTC (permalink / raw)
To: Cai Huoqing, tj, lizefan.x, hannes, corbet; +Cc: cgroups, linux-doc
ÔÚ 2021/7/30 ÏÂÎç1:16, Cai Huoqing дµÀ:
> Fix typo: iff ==> if
>
> Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Reviewed-by: Hu Haowen <src.res@email.cn>
> ---
> Documentation/admin-guide/cgroup-v1/cgroups.rst | 2 +-
> Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst | 4 ++--
> kernel/cgroup/cgroup-v1.c | 4 ++--
> kernel/cgroup/cgroup.c | 6 +++---
> kernel/cgroup/cpuset.c | 4 ++--
> 5 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/admin-guide/cgroup-v1/cgroups.rst b/Documentation/admin-guide/cgroup-v1/cgroups.rst
> index b0688011ed06..fa747466e304 100644
> --- a/Documentation/admin-guide/cgroup-v1/cgroups.rst
> +++ b/Documentation/admin-guide/cgroup-v1/cgroups.rst
> @@ -573,7 +573,7 @@ cgroup_for_each_descendant_pre() for details.
> ``void css_offline(struct cgroup *cgrp);``
> (cgroup_mutex held by caller)
>
> -This is the counterpart of css_online() and called iff css_online()
> +This is the counterpart of css_online() and called if css_online()
> has succeeded on @cgrp. This signifies the beginning of the end of
> @cgrp. @cgrp is being removed and the subsystem should start dropping
> all references it's holding on @cgrp. When all references are dropped,
> diff --git a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
> index 582d3427de3f..a908c5226bde 100644
> --- a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
> +++ b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
> @@ -56,7 +56,7 @@ expected.
> The cgroup freezer is hierarchical. Freezing a cgroup freezes all
> tasks belonging to the cgroup and all its descendant cgroups. Each
> cgroup has its own state (self-state) and the state inherited from the
> -parent (parent-state). Iff both states are THAWED, the cgroup is
> +parent (parent-state). If both states are THAWED, the cgroup is
> THAWED.
>
> The following cgroupfs files are created by cgroup freezer.
> @@ -87,7 +87,7 @@ The following cgroupfs files are created by cgroup freezer.
> * freezer.self_freezing: Read only.
>
> Shows the self-state. 0 if the self-state is THAWED; otherwise, 1.
> - This value is 1 iff the last write to freezer.state was "FROZEN".
> + This value is 1 if the last write to freezer.state was "FROZEN".
>
> * freezer.parent_freezing: Read only.
>
> diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
> index de2c432dee20..71d2b46d1968 100644
> --- a/kernel/cgroup/cgroup-v1.c
> +++ b/kernel/cgroup/cgroup-v1.c
> @@ -120,7 +120,7 @@ int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from)
> goto out_err;
>
> /*
> - * Migrate tasks one-by-one until @from is empty. This fails iff
> + * Migrate tasks one-by-one until @from is empty. This fails if
> * ->can_attach() fails.
> */
> do {
> @@ -215,7 +215,7 @@ static void cgroup_pidlist_destroy_work_fn(struct work_struct *work)
> mutex_lock(&l->owner->pidlist_mutex);
>
> /*
> - * Destroy iff we didn't get queued again. The state won't change
> + * Destroy if we didn't get queued again. The state won't change
> * as destroy_dwork can only be queued while locked.
> */
> if (!delayed_work_pending(dwork)) {
> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> index 3a0161c21b6b..b831554372a2 100644
> --- a/kernel/cgroup/cgroup.c
> +++ b/kernel/cgroup/cgroup.c
> @@ -793,7 +793,7 @@ static bool css_set_populated(struct css_set *cset)
> * One of the css_sets associated with @cgrp is either getting its first
> * task or losing the last. Update @cgrp->nr_populated_* accordingly. The
> * count is propagated towards root so that a given cgroup's
> - * nr_populated_children is zero iff none of its descendants contain any
> + * nr_populated_children is zero if none of its descendants contain any
> * tasks.
> *
> * @cgrp's interface file "cgroup.populated" is zero if both
> @@ -2410,7 +2410,7 @@ struct task_struct *cgroup_taskset_next(struct cgroup_taskset *tset,
> * @mgctx: migration context
> *
> * Migrate tasks in @mgctx as setup by migration preparation functions.
> - * This function fails iff one of the ->can_attach callbacks fails and
> + * This function fails if one of the ->can_attach callbacks fails and
> * guarantees that either all or none of the tasks in @mgctx are migrated.
> * @mgctx is consumed regardless of success.
> */
> @@ -4264,7 +4264,7 @@ struct cgroup_subsys_state *css_next_child(struct cgroup_subsys_state *pos,
> * increasing unique serial number and always appended to the
> * sibling list, the next one can be found by walking the parent's
> * children until the first css with higher serial number than
> - * @pos's. While this path can be slower, it happens iff iteration
> + * @pos's. While this path can be slower, it happens if iteration
> * races against release and the race window is very small.
> */
> if (!pos) {
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index adb5190c4429..f09fc0347550 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -782,7 +782,7 @@ static int generate_sched_domains(cpumask_var_t **domains,
> if (cp == &top_cpuset)
> continue;
> /*
> - * Continue traversing beyond @cp iff @cp has some CPUs and
> + * Continue traversing beyond @cp if @cp has some CPUs and
> * isn't load balancing. The former is obvious. The
> * latter: All child cpusets contain a subset of the
> * parent's cpus, so just skip them, and then we call
> @@ -1801,7 +1801,7 @@ static int update_nodemask(struct cpuset *cs, struct cpuset *trialcs,
> }
>
> /*
> - * An empty mems_allowed is ok iff there are no tasks in the cpuset.
> + * An empty mems_allowed is ok if there are no tasks in the cpuset.
> * Since nodelist_parse() fails on an empty mask, we special case
> * that parsing. The validate_change() call ensures that cpusets
> * with tasks have memory.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] cgroup: Fix typo in comments and documents
2021-07-30 5:16 ` Cai Huoqing
@ 2021-07-30 13:44 ` Hu Haowen
-1 siblings, 0 replies; 14+ messages in thread
From: Hu Haowen @ 2021-07-30 13:44 UTC (permalink / raw)
To: Cai Huoqing, tj, lizefan.x, hannes, corbet
Cc: cgroups, linux-doc, linux-kernel
在 2021/7/30 下午1:16, Cai Huoqing 写道:
> Fix typo: iff ==> if
>
> Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Reviewed-by: Hu Haowen <src.res@email.cn>
> ---
> Documentation/admin-guide/cgroup-v1/cgroups.rst | 2 +-
> Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst | 4 ++--
> kernel/cgroup/cgroup-v1.c | 4 ++--
> kernel/cgroup/cgroup.c | 6 +++---
> kernel/cgroup/cpuset.c | 4 ++--
> 5 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/admin-guide/cgroup-v1/cgroups.rst b/Documentation/admin-guide/cgroup-v1/cgroups.rst
> index b0688011ed06..fa747466e304 100644
> --- a/Documentation/admin-guide/cgroup-v1/cgroups.rst
> +++ b/Documentation/admin-guide/cgroup-v1/cgroups.rst
> @@ -573,7 +573,7 @@ cgroup_for_each_descendant_pre() for details.
> ``void css_offline(struct cgroup *cgrp);``
> (cgroup_mutex held by caller)
>
> -This is the counterpart of css_online() and called iff css_online()
> +This is the counterpart of css_online() and called if css_online()
> has succeeded on @cgrp. This signifies the beginning of the end of
> @cgrp. @cgrp is being removed and the subsystem should start dropping
> all references it's holding on @cgrp. When all references are dropped,
> diff --git a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
> index 582d3427de3f..a908c5226bde 100644
> --- a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
> +++ b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
> @@ -56,7 +56,7 @@ expected.
> The cgroup freezer is hierarchical. Freezing a cgroup freezes all
> tasks belonging to the cgroup and all its descendant cgroups. Each
> cgroup has its own state (self-state) and the state inherited from the
> -parent (parent-state). Iff both states are THAWED, the cgroup is
> +parent (parent-state). If both states are THAWED, the cgroup is
> THAWED.
>
> The following cgroupfs files are created by cgroup freezer.
> @@ -87,7 +87,7 @@ The following cgroupfs files are created by cgroup freezer.
> * freezer.self_freezing: Read only.
>
> Shows the self-state. 0 if the self-state is THAWED; otherwise, 1.
> - This value is 1 iff the last write to freezer.state was "FROZEN".
> + This value is 1 if the last write to freezer.state was "FROZEN".
>
> * freezer.parent_freezing: Read only.
>
> diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
> index de2c432dee20..71d2b46d1968 100644
> --- a/kernel/cgroup/cgroup-v1.c
> +++ b/kernel/cgroup/cgroup-v1.c
> @@ -120,7 +120,7 @@ int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from)
> goto out_err;
>
> /*
> - * Migrate tasks one-by-one until @from is empty. This fails iff
> + * Migrate tasks one-by-one until @from is empty. This fails if
> * ->can_attach() fails.
> */
> do {
> @@ -215,7 +215,7 @@ static void cgroup_pidlist_destroy_work_fn(struct work_struct *work)
> mutex_lock(&l->owner->pidlist_mutex);
>
> /*
> - * Destroy iff we didn't get queued again. The state won't change
> + * Destroy if we didn't get queued again. The state won't change
> * as destroy_dwork can only be queued while locked.
> */
> if (!delayed_work_pending(dwork)) {
> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> index 3a0161c21b6b..b831554372a2 100644
> --- a/kernel/cgroup/cgroup.c
> +++ b/kernel/cgroup/cgroup.c
> @@ -793,7 +793,7 @@ static bool css_set_populated(struct css_set *cset)
> * One of the css_sets associated with @cgrp is either getting its first
> * task or losing the last. Update @cgrp->nr_populated_* accordingly. The
> * count is propagated towards root so that a given cgroup's
> - * nr_populated_children is zero iff none of its descendants contain any
> + * nr_populated_children is zero if none of its descendants contain any
> * tasks.
> *
> * @cgrp's interface file "cgroup.populated" is zero if both
> @@ -2410,7 +2410,7 @@ struct task_struct *cgroup_taskset_next(struct cgroup_taskset *tset,
> * @mgctx: migration context
> *
> * Migrate tasks in @mgctx as setup by migration preparation functions.
> - * This function fails iff one of the ->can_attach callbacks fails and
> + * This function fails if one of the ->can_attach callbacks fails and
> * guarantees that either all or none of the tasks in @mgctx are migrated.
> * @mgctx is consumed regardless of success.
> */
> @@ -4264,7 +4264,7 @@ struct cgroup_subsys_state *css_next_child(struct cgroup_subsys_state *pos,
> * increasing unique serial number and always appended to the
> * sibling list, the next one can be found by walking the parent's
> * children until the first css with higher serial number than
> - * @pos's. While this path can be slower, it happens iff iteration
> + * @pos's. While this path can be slower, it happens if iteration
> * races against release and the race window is very small.
> */
> if (!pos) {
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index adb5190c4429..f09fc0347550 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -782,7 +782,7 @@ static int generate_sched_domains(cpumask_var_t **domains,
> if (cp == &top_cpuset)
> continue;
> /*
> - * Continue traversing beyond @cp iff @cp has some CPUs and
> + * Continue traversing beyond @cp if @cp has some CPUs and
> * isn't load balancing. The former is obvious. The
> * latter: All child cpusets contain a subset of the
> * parent's cpus, so just skip them, and then we call
> @@ -1801,7 +1801,7 @@ static int update_nodemask(struct cpuset *cs, struct cpuset *trialcs,
> }
>
> /*
> - * An empty mems_allowed is ok iff there are no tasks in the cpuset.
> + * An empty mems_allowed is ok if there are no tasks in the cpuset.
> * Since nodelist_parse() fails on an empty mask, we special case
> * that parsing. The validate_change() call ensures that cpusets
> * with tasks have memory.
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH] cgroup: Fix typo in comments and documents
@ 2021-07-30 13:44 ` Hu Haowen
0 siblings, 0 replies; 14+ messages in thread
From: Hu Haowen @ 2021-07-30 13:44 UTC (permalink / raw)
To: Cai Huoqing, tj, lizefan.x, hannes, corbet
Cc: cgroups, linux-doc, linux-kernel
ÔÚ 2021/7/30 ÏÂÎç1:16, Cai Huoqing дµÀ:
> Fix typo: iff ==> if
>
> Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Reviewed-by: Hu Haowen <src.res@email.cn>
> ---
> Documentation/admin-guide/cgroup-v1/cgroups.rst | 2 +-
> Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst | 4 ++--
> kernel/cgroup/cgroup-v1.c | 4 ++--
> kernel/cgroup/cgroup.c | 6 +++---
> kernel/cgroup/cpuset.c | 4 ++--
> 5 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/admin-guide/cgroup-v1/cgroups.rst b/Documentation/admin-guide/cgroup-v1/cgroups.rst
> index b0688011ed06..fa747466e304 100644
> --- a/Documentation/admin-guide/cgroup-v1/cgroups.rst
> +++ b/Documentation/admin-guide/cgroup-v1/cgroups.rst
> @@ -573,7 +573,7 @@ cgroup_for_each_descendant_pre() for details.
> ``void css_offline(struct cgroup *cgrp);``
> (cgroup_mutex held by caller)
>
> -This is the counterpart of css_online() and called iff css_online()
> +This is the counterpart of css_online() and called if css_online()
> has succeeded on @cgrp. This signifies the beginning of the end of
> @cgrp. @cgrp is being removed and the subsystem should start dropping
> all references it's holding on @cgrp. When all references are dropped,
> diff --git a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
> index 582d3427de3f..a908c5226bde 100644
> --- a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
> +++ b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
> @@ -56,7 +56,7 @@ expected.
> The cgroup freezer is hierarchical. Freezing a cgroup freezes all
> tasks belonging to the cgroup and all its descendant cgroups. Each
> cgroup has its own state (self-state) and the state inherited from the
> -parent (parent-state). Iff both states are THAWED, the cgroup is
> +parent (parent-state). If both states are THAWED, the cgroup is
> THAWED.
>
> The following cgroupfs files are created by cgroup freezer.
> @@ -87,7 +87,7 @@ The following cgroupfs files are created by cgroup freezer.
> * freezer.self_freezing: Read only.
>
> Shows the self-state. 0 if the self-state is THAWED; otherwise, 1.
> - This value is 1 iff the last write to freezer.state was "FROZEN".
> + This value is 1 if the last write to freezer.state was "FROZEN".
>
> * freezer.parent_freezing: Read only.
>
> diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
> index de2c432dee20..71d2b46d1968 100644
> --- a/kernel/cgroup/cgroup-v1.c
> +++ b/kernel/cgroup/cgroup-v1.c
> @@ -120,7 +120,7 @@ int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from)
> goto out_err;
>
> /*
> - * Migrate tasks one-by-one until @from is empty. This fails iff
> + * Migrate tasks one-by-one until @from is empty. This fails if
> * ->can_attach() fails.
> */
> do {
> @@ -215,7 +215,7 @@ static void cgroup_pidlist_destroy_work_fn(struct work_struct *work)
> mutex_lock(&l->owner->pidlist_mutex);
>
> /*
> - * Destroy iff we didn't get queued again. The state won't change
> + * Destroy if we didn't get queued again. The state won't change
> * as destroy_dwork can only be queued while locked.
> */
> if (!delayed_work_pending(dwork)) {
> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> index 3a0161c21b6b..b831554372a2 100644
> --- a/kernel/cgroup/cgroup.c
> +++ b/kernel/cgroup/cgroup.c
> @@ -793,7 +793,7 @@ static bool css_set_populated(struct css_set *cset)
> * One of the css_sets associated with @cgrp is either getting its first
> * task or losing the last. Update @cgrp->nr_populated_* accordingly. The
> * count is propagated towards root so that a given cgroup's
> - * nr_populated_children is zero iff none of its descendants contain any
> + * nr_populated_children is zero if none of its descendants contain any
> * tasks.
> *
> * @cgrp's interface file "cgroup.populated" is zero if both
> @@ -2410,7 +2410,7 @@ struct task_struct *cgroup_taskset_next(struct cgroup_taskset *tset,
> * @mgctx: migration context
> *
> * Migrate tasks in @mgctx as setup by migration preparation functions.
> - * This function fails iff one of the ->can_attach callbacks fails and
> + * This function fails if one of the ->can_attach callbacks fails and
> * guarantees that either all or none of the tasks in @mgctx are migrated.
> * @mgctx is consumed regardless of success.
> */
> @@ -4264,7 +4264,7 @@ struct cgroup_subsys_state *css_next_child(struct cgroup_subsys_state *pos,
> * increasing unique serial number and always appended to the
> * sibling list, the next one can be found by walking the parent's
> * children until the first css with higher serial number than
> - * @pos's. While this path can be slower, it happens iff iteration
> + * @pos's. While this path can be slower, it happens if iteration
> * races against release and the race window is very small.
> */
> if (!pos) {
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index adb5190c4429..f09fc0347550 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -782,7 +782,7 @@ static int generate_sched_domains(cpumask_var_t **domains,
> if (cp == &top_cpuset)
> continue;
> /*
> - * Continue traversing beyond @cp iff @cp has some CPUs and
> + * Continue traversing beyond @cp if @cp has some CPUs and
> * isn't load balancing. The former is obvious. The
> * latter: All child cpusets contain a subset of the
> * parent's cpus, so just skip them, and then we call
> @@ -1801,7 +1801,7 @@ static int update_nodemask(struct cpuset *cs, struct cpuset *trialcs,
> }
>
> /*
> - * An empty mems_allowed is ok iff there are no tasks in the cpuset.
> + * An empty mems_allowed is ok if there are no tasks in the cpuset.
> * Since nodelist_parse() fails on an empty mask, we special case
> * that parsing. The validate_change() call ensures that cpusets
> * with tasks have memory.
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH] cgroup: Fix typo in comments and documents
2021-07-30 13:44 ` Hu Haowen
(?)
@ 2021-07-30 14:53 ` Shakeel Butt
2021-07-30 14:54 ` Cai,Huoqing
-1 siblings, 1 reply; 14+ messages in thread
From: Shakeel Butt @ 2021-07-30 14:53 UTC (permalink / raw)
To: Hu Haowen
Cc: Cai Huoqing, Tejun Heo, Zefan Li, Johannes Weiner,
Jonathan Corbet, Cgroups, linux-doc, LKML
On Fri, Jul 30, 2021 at 6:44 AM Hu Haowen <src.res@email.cn> wrote:
>
>
> 在 2021/7/30 下午1:16, Cai Huoqing 写道:
> > Fix typo: iff ==> if
This is not a typo. 'iff' means 'if and only if'. For details see
https://en.wikipedia.org/wiki/If_and_only_if.
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [PATCH] cgroup: Fix typo in comments and documents
2021-07-30 14:53 ` Shakeel Butt
@ 2021-07-30 14:54 ` Cai,Huoqing
2021-07-30 16:07 ` Hu Haowen
0 siblings, 1 reply; 14+ messages in thread
From: Cai,Huoqing @ 2021-07-30 14:54 UTC (permalink / raw)
To: Shakeel Butt, Hu Haowen
Cc: Tejun Heo, Zefan Li, Johannes Weiner, Jonathan Corbet, Cgroups,
linux-doc, LKML
Forget it - -
-----Original Message-----
From: Shakeel Butt <shakeelb@google.com>
Sent: 2021年7月30日 22:53
To: Hu Haowen <src.res@email.cn>
Cc: Cai,Huoqing <caihuoqing@baidu.com>; Tejun Heo <tj@kernel.org>; Zefan Li <lizefan.x@bytedance.com>; Johannes Weiner <hannes@cmpxchg.org>; Jonathan Corbet <corbet@lwn.net>; Cgroups <cgroups@vger.kernel.org>; linux-doc@vger.kernel.org; LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] cgroup: Fix typo in comments and documents
On Fri, Jul 30, 2021 at 6:44 AM Hu Haowen <src.res@email.cn> wrote:
>
>
> 在 2021/7/30 下午1:16, Cai Huoqing 写道:
> > Fix typo: iff ==> if
This is not a typo. 'iff' means 'if and only if'. For details see https://en.wikipedia.org/wiki/If_and_only_if.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] cgroup: Fix typo in comments and documents
2021-07-30 14:54 ` Cai,Huoqing
@ 2021-07-30 16:07 ` Hu Haowen
0 siblings, 0 replies; 14+ messages in thread
From: Hu Haowen @ 2021-07-30 16:07 UTC (permalink / raw)
To: Cai,Huoqing, Shakeel Butt
Cc: Tejun Heo, Zefan Li, Johannes Weiner, Jonathan Corbet, Cgroups,
linux-doc, LKML
在 2021/7/30 下午10:54, Cai,Huoqing 写道:
> Forget it - -
>
> -----Original Message-----
> From: Shakeel Butt <shakeelb@google.com>
> Sent: 2021年7月30日 22:53
> To: Hu Haowen <src.res@email.cn>
> Cc: Cai,Huoqing <caihuoqing@baidu.com>; Tejun Heo <tj@kernel.org>; Zefan Li <lizefan.x@bytedance.com>; Johannes Weiner <hannes@cmpxchg.org>; Jonathan Corbet <corbet@lwn.net>; Cgroups <cgroups@vger.kernel.org>; linux-doc@vger.kernel.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH] cgroup: Fix typo in comments and documents
>
> On Fri, Jul 30, 2021 at 6:44 AM Hu Haowen <src.res@email.cn> wrote:
>>
>> 在 2021/7/30 下午1:16, Cai Huoqing 写道:
>>> Fix typo: iff ==> if
> This is not a typo. 'iff' means 'if and only if'. For details see https://en.wikipedia.org/wiki/If_and_only_if.
Sorry, my mistake.
Thx,
Hu Haowen
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] cgroup: Fix typo in comments and documents
2021-07-30 5:16 ` Cai Huoqing
` (2 preceding siblings ...)
(?)
@ 2021-07-30 14:51 ` Jonathan Corbet
2021-07-30 15:03 ` Matthew Wilcox
-1 siblings, 1 reply; 14+ messages in thread
From: Jonathan Corbet @ 2021-07-30 14:51 UTC (permalink / raw)
To: Cai Huoqing, tj, lizefan.x, hannes; +Cc: cgroups, linux-doc, Cai Huoqing
Cai Huoqing <caihuoqing@baidu.com> writes:
> Fix typo: iff ==> if
>
> Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
This is becoming an FAQ ... "iff" in mathematical English means "if and
only if"; its usage in these documents is correct.
Thanks,
jon
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH] cgroup: Fix typo in comments and documents
2021-07-30 14:51 ` Jonathan Corbet
@ 2021-07-30 15:03 ` Matthew Wilcox
2021-07-30 19:16 ` Jonathan Corbet
2021-08-01 3:39 ` Hu Haowen
0 siblings, 2 replies; 14+ messages in thread
From: Matthew Wilcox @ 2021-07-30 15:03 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: Cai Huoqing, tj, lizefan.x, hannes, cgroups, linux-doc
On Fri, Jul 30, 2021 at 08:51:29AM -0600, Jonathan Corbet wrote:
> Cai Huoqing <caihuoqing@baidu.com> writes:
>
> > Fix typo: iff ==> if
> >
> > Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
>
> This is becoming an FAQ ... "iff" in mathematical English means "if and
> only if"; its usage in these documents is correct.
... and yet it's clearly not understood. Similarly to the [start..end)
convention (also the [start..end[ convention). Should we deprecate
use of it in kernel documentation, and if so, what should we replace it
with?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] cgroup: Fix typo in comments and documents
2021-07-30 15:03 ` Matthew Wilcox
@ 2021-07-30 19:16 ` Jonathan Corbet
2021-08-01 3:39 ` Hu Haowen
1 sibling, 0 replies; 14+ messages in thread
From: Jonathan Corbet @ 2021-07-30 19:16 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: Cai Huoqing, tj, lizefan.x, hannes, cgroups, linux-doc
Matthew Wilcox <willy@infradead.org> writes:
> On Fri, Jul 30, 2021 at 08:51:29AM -0600, Jonathan Corbet wrote:
>> Cai Huoqing <caihuoqing@baidu.com> writes:
>>
>> > Fix typo: iff ==> if
>> >
>> > Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
>>
>> This is becoming an FAQ ... "iff" in mathematical English means "if and
>> only if"; its usage in these documents is correct.
>
> ... and yet it's clearly not understood. Similarly to the [start..end)
> convention (also the [start..end[ convention). Should we deprecate
> use of it in kernel documentation, and if so, what should we replace it
> with?
I'm never quite sure what to do with these things...we want to be
inclusive, but we don't want to hobble the language we use beyond a
certain point. We could ask people to spell out "if and only if", I
suppose, but that sounds like the kind of thing that leads to unpleasant
messages in my inbox.
Thanks,
jon
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] cgroup: Fix typo in comments and documents
2021-07-30 15:03 ` Matthew Wilcox
@ 2021-08-01 3:39 ` Hu Haowen
2021-08-01 3:39 ` Hu Haowen
1 sibling, 0 replies; 14+ messages in thread
From: Hu Haowen @ 2021-08-01 3:39 UTC (permalink / raw)
To: Matthew Wilcox, Jonathan Corbet
Cc: Cai Huoqing, tj, lizefan.x, hannes, cgroups, linux-doc
在 2021/7/30 下午11:03, Matthew Wilcox 写道:
> On Fri, Jul 30, 2021 at 08:51:29AM -0600, Jonathan Corbet wrote:
>> Cai Huoqing <caihuoqing@baidu.com> writes:
>>
>>> Fix typo: iff ==> if
>>>
>>> Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
>> This is becoming an FAQ ... "iff" in mathematical English means "if and
>> only if"; its usage in these documents is correct.
> ... and yet it's clearly not understood. Similarly to the [start..end)
> convention (also the [start..end[ convention). Should we deprecate
> use of it in kernel documentation, and if so, what should we replace it
> with?
What about establishing a documentation section which gives clear
definitions to each words whose meaning isn't easy to understand for
common people, such as this situation? In this case readers are able to
get rid of their questions on their own, instead of asking maintainers
for any explanation.
Regards,
Hu Haowen
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] cgroup: Fix typo in comments and documents
@ 2021-08-01 3:39 ` Hu Haowen
0 siblings, 0 replies; 14+ messages in thread
From: Hu Haowen @ 2021-08-01 3:39 UTC (permalink / raw)
To: Matthew Wilcox, Jonathan Corbet
Cc: Cai Huoqing, tj, lizefan.x, hannes, cgroups, linux-doc
ÔÚ 2021/7/30 ÏÂÎç11:03, Matthew Wilcox дµÀ:
> On Fri, Jul 30, 2021 at 08:51:29AM -0600, Jonathan Corbet wrote:
>> Cai Huoqing <caihuoqing@baidu.com> writes:
>>
>>> Fix typo: iff ==> if
>>>
>>> Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
>> This is becoming an FAQ ... "iff" in mathematical English means "if and
>> only if"; its usage in these documents is correct.
> ... and yet it's clearly not understood. Similarly to the [start..end)
> convention (also the [start..end[ convention). Should we deprecate
> use of it in kernel documentation, and if so, what should we replace it
> with?
What about establishing a documentation section which gives clear
definitions to each words whose meaning isn't easy to understand for
common people, such as this situation? In this case readers are able to
get rid of their questions on their own, instead of asking maintainers
for any explanation.
Regards,
Hu Haowen
^ permalink raw reply [flat|nested] 14+ messages in thread