* [PATCH v10 5/9] cpuset: Make sure that domain roots work properly with CPU hotplug
From: Waiman Long @ 2018-06-18 4:14 UTC (permalink / raw)
To: Tejun Heo, Li Zefan, Johannes Weiner, Peter Zijlstra, Ingo Molnar
Cc: cgroups, linux-kernel, linux-doc, kernel-team, pjt, luto,
Mike Galbraith, torvalds, Roman Gushchin, Juri Lelli,
Patrick Bellasi, Waiman Long
In-Reply-To: <1529295249-5207-1-git-send-email-longman@redhat.com>
When there is a cpu hotplug event (CPU online or offline), the scheduling
domains needed to be reconfigured and regenerated. So code is added to
the hotplug functions to make them work with new reserved_cpus mask to
compute the right effective_cpus for each of the affected cpusets.
Signed-off-by: Waiman Long <longman@redhat.com>
---
Documentation/admin-guide/cgroup-v2.rst | 7 +++++++
kernel/cgroup/cpuset.c | 26 ++++++++++++++++++++++++--
2 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index 5ee5e77..6ef3516 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -1626,6 +1626,13 @@ Cpuset Interface Files
2) No CPU that has been distributed to child scheduling domain
roots is deleted.
+ When all the CPUs allocated to a scheduling domain are offlined,
+ that scheduling domain will be temporaily gone and all the
+ tasks in that scheduling domain will migrate to another one that
+ belongs to the parent of the scheduling domain root. When any
+ of those offlined CPUs is onlined again, a new scheduling domain
+ will be re-created and the tasks will be migrated back.
+
Device controller
-----------------
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index b1abe3d..26ac083 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -900,7 +900,8 @@ static void update_tasks_cpumask(struct cpuset *cs)
* @parent: the parent cpuset
*
* If the parent has reserved CPUs, include them in the list of allowable
- * CPUs in computing the new effective_cpus mask.
+ * CPUs in computing the new effective_cpus mask. The cpu_active_mask is
+ * used to mask off cpus that are to be offlined.
*/
static void compute_effective_cpumask(struct cpumask *new_cpus,
struct cpuset *cs, struct cpuset *parent)
@@ -909,6 +910,7 @@ static void compute_effective_cpumask(struct cpumask *new_cpus,
cpumask_or(new_cpus, parent->effective_cpus,
parent->reserved_cpus);
cpumask_and(new_cpus, new_cpus, cs->cpus_allowed);
+ cpumask_and(new_cpus, new_cpus, cpu_active_mask);
} else {
cpumask_and(new_cpus, cs->cpus_allowed, parent->effective_cpus);
}
@@ -2571,9 +2573,17 @@ static void cpuset_hotplug_update_tasks(struct cpuset *cs)
goto retry;
}
- cpumask_and(&new_cpus, cs->cpus_allowed, parent_cs(cs)->effective_cpus);
+ compute_effective_cpumask(&new_cpus, cs, parent_cs(cs));
nodes_and(new_mems, cs->mems_allowed, parent_cs(cs)->effective_mems);
+ if (cs->nr_reserved) {
+ /*
+ * Some of the CPUs may have been distributed to child
+ * domain roots. So we need skip those when computing the
+ * real effective cpus.
+ */
+ cpumask_andnot(&new_cpus, &new_cpus, cs->reserved_cpus);
+ }
cpus_updated = !cpumask_equal(&new_cpus, cs->effective_cpus);
mems_updated = !nodes_equal(new_mems, cs->effective_mems);
@@ -2623,6 +2633,11 @@ static void cpuset_hotplug_workfn(struct work_struct *work)
cpumask_copy(&new_cpus, cpu_active_mask);
new_mems = node_states[N_MEMORY];
+ /*
+ * If reserved_cpus is populated, it is likely that the check below
+ * will produce a false positive on cpus_updated when the cpu list
+ * isn't changed. It is extra work, but it is better to be safe.
+ */
cpus_updated = !cpumask_equal(top_cpuset.effective_cpus, &new_cpus);
mems_updated = !nodes_equal(top_cpuset.effective_mems, new_mems);
@@ -2631,6 +2646,13 @@ static void cpuset_hotplug_workfn(struct work_struct *work)
spin_lock_irq(&callback_lock);
if (!on_dfl)
cpumask_copy(top_cpuset.cpus_allowed, &new_cpus);
+ /*
+ * Make sure that the reserved cpus aren't in the
+ * effective cpus.
+ */
+ if (top_cpuset.nr_reserved)
+ cpumask_andnot(&new_cpus, &new_cpus,
+ top_cpuset.reserved_cpus);
cpumask_copy(top_cpuset.effective_cpus, &new_cpus);
spin_unlock_irq(&callback_lock);
/* we don't mess with cpumasks of tasks in top_cpuset */
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v10 6/9] cpuset: Make generate_sched_domains() recognize reserved_cpus
From: Waiman Long @ 2018-06-18 4:14 UTC (permalink / raw)
To: Tejun Heo, Li Zefan, Johannes Weiner, Peter Zijlstra, Ingo Molnar
Cc: cgroups, linux-kernel, linux-doc, kernel-team, pjt, luto,
Mike Galbraith, torvalds, Roman Gushchin, Juri Lelli,
Patrick Bellasi, Waiman Long
In-Reply-To: <1529295249-5207-1-git-send-email-longman@redhat.com>
The generate_sched_domains() function is modified to make it work
correctly with the newly introduced reserved_cpus mask for schedule
domains generation.
Signed-off-by: Waiman Long <longman@redhat.com>
---
kernel/cgroup/cpuset.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 26ac083..ea640ce 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -672,13 +672,14 @@ static int generate_sched_domains(cpumask_var_t **domains,
int ndoms = 0; /* number of sched domains in result */
int nslot; /* next empty doms[] struct cpumask slot */
struct cgroup_subsys_state *pos_css;
+ bool root_load_balance = is_sched_load_balance(&top_cpuset);
doms = NULL;
dattr = NULL;
csa = NULL;
/* Special case for the 99% of systems with one, full, sched domain */
- if (is_sched_load_balance(&top_cpuset)) {
+ if (root_load_balance && !top_cpuset.nr_reserved) {
ndoms = 1;
doms = alloc_sched_domains(ndoms);
if (!doms)
@@ -701,6 +702,8 @@ static int generate_sched_domains(cpumask_var_t **domains,
csn = 0;
rcu_read_lock();
+ if (root_load_balance)
+ csa[csn++] = &top_cpuset;
cpuset_for_each_descendant_pre(cp, pos_css, &top_cpuset) {
if (cp == &top_cpuset)
continue;
@@ -711,6 +714,9 @@ static int generate_sched_domains(cpumask_var_t **domains,
* parent's cpus, so just skip them, and then we call
* update_domain_attr_tree() to calc relax_domain_level of
* the corresponding sched domain.
+ *
+ * If root is load-balancing, we can skip @cp if it
+ * is a subset of the root's effective_cpus.
*/
if (!cpumask_empty(cp->cpus_allowed) &&
!(is_sched_load_balance(cp) &&
@@ -718,11 +724,16 @@ static int generate_sched_domains(cpumask_var_t **domains,
housekeeping_cpumask(HK_FLAG_DOMAIN))))
continue;
+ if (root_load_balance &&
+ cpumask_subset(cp->cpus_allowed, top_cpuset.effective_cpus))
+ continue;
+
if (is_sched_load_balance(cp))
csa[csn++] = cp;
- /* skip @cp's subtree */
- pos_css = css_rightmost_descendant(pos_css);
+ /* skip @cp's subtree if not a scheduling domain root */
+ if (!is_sched_domain_root(cp))
+ pos_css = css_rightmost_descendant(pos_css);
}
rcu_read_unlock();
@@ -850,7 +861,12 @@ static void rebuild_sched_domains_locked(void)
* passing doms with offlined cpu to partition_sched_domains().
* Anyways, hotplug work item will rebuild sched domains.
*/
- if (!cpumask_equal(top_cpuset.effective_cpus, cpu_active_mask))
+ if (!top_cpuset.nr_reserved &&
+ !cpumask_equal(top_cpuset.effective_cpus, cpu_active_mask))
+ goto out;
+
+ if (top_cpuset.nr_reserved &&
+ !cpumask_subset(top_cpuset.effective_cpus, cpu_active_mask))
goto out;
/* Generate domain masks and attrs */
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v10 7/9] cpuset: Expose cpus.effective and mems.effective on cgroup v2 root
From: Waiman Long @ 2018-06-18 4:14 UTC (permalink / raw)
To: Tejun Heo, Li Zefan, Johannes Weiner, Peter Zijlstra, Ingo Molnar
Cc: cgroups, linux-kernel, linux-doc, kernel-team, pjt, luto,
Mike Galbraith, torvalds, Roman Gushchin, Juri Lelli,
Patrick Bellasi, Waiman Long
In-Reply-To: <1529295249-5207-1-git-send-email-longman@redhat.com>
Because of the fact that setting the "cpuset.sched.domain_root" in
a direct child of root can remove CPUs from the root's effective CPU
list, it makes sense to know what CPUs are left in the root cgroup for
scheduling purpose. So the "cpuset.cpus.effective" control file is now
exposed in the v2 cgroup root.
For consistency, the "cpuset.mems.effective" control file is exposed
as well.
Signed-off-by: Waiman Long <longman@redhat.com>
---
Documentation/admin-guide/cgroup-v2.rst | 4 ++--
kernel/cgroup/cpuset.c | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index 6ef3516..c2b61e1 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -1529,7 +1529,7 @@ Cpuset Interface Files
and won't be affected by any CPU hotplug events.
cpuset.cpus.effective
- A read-only multiple values file which exists on non-root
+ A read-only multiple values file which exists on all
cpuset-enabled cgroups.
It lists the onlined CPUs that are actually granted to this
@@ -1569,7 +1569,7 @@ Cpuset Interface Files
and won't be affected by any memory nodes hotplug events.
cpuset.mems.effective
- A read-only multiple values file which exists on non-root
+ A read-only multiple values file which exists on all
cpuset-enabled cgroups.
It lists the onlined memory nodes that are actually granted to
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index ea640ce..b609795 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -2225,14 +2225,12 @@ static s64 cpuset_read_s64(struct cgroup_subsys_state *css, struct cftype *cft)
.name = "cpus.effective",
.seq_show = cpuset_common_seq_show,
.private = FILE_EFFECTIVE_CPULIST,
- .flags = CFTYPE_NOT_ON_ROOT,
},
{
.name = "mems.effective",
.seq_show = cpuset_common_seq_show,
.private = FILE_EFFECTIVE_MEMLIST,
- .flags = CFTYPE_NOT_ON_ROOT,
},
{
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v10 8/9] cpuset: Don't rebuild sched domains if cpu changes in non-domain root
From: Waiman Long @ 2018-06-18 4:14 UTC (permalink / raw)
To: Tejun Heo, Li Zefan, Johannes Weiner, Peter Zijlstra, Ingo Molnar
Cc: cgroups, linux-kernel, linux-doc, kernel-team, pjt, luto,
Mike Galbraith, torvalds, Roman Gushchin, Juri Lelli,
Patrick Bellasi, Waiman Long
In-Reply-To: <1529295249-5207-1-git-send-email-longman@redhat.com>
With the cpuset v1, any changes to the list of allowable CPUs in a cpuset
may cause changes in the sched domain configuration depending on the
load balancing states and the cpu lists of its parent and its children.
With cpuset v2 (on default hierarchy), there are more restrictions
on how the load balancing state of a cpuset can change. As a result,
only changes made in a sched domain root will cause possible changes
to the corresponding sched domain. CPU changes to any of the non-domain
root cpusets will not cause changes in the sched domain configuration.
As a result, we don't need to call rebuild_sched_domains_locked()
for changes in a non-domain root cpuset saving precious cpu cycles.
Signed-off-by: Waiman Long <longman@redhat.com>
---
kernel/cgroup/cpuset.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index b609795..ed80663 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -986,11 +986,15 @@ static void update_cpumasks_hier(struct cpuset *cs, struct cpumask *new_cpus)
update_tasks_cpumask(cp);
/*
- * If the effective cpumask of any non-empty cpuset is changed,
- * we need to rebuild sched domains.
+ * On legacy hierarchy, if the effective cpumask of any non-
+ * empty cpuset is changed, we need to rebuild sched domains.
+ * On default hiearchy, the cpuset needs to be a sched
+ * domain root as well.
*/
if (!cpumask_empty(cp->cpus_allowed) &&
- is_sched_load_balance(cp))
+ is_sched_load_balance(cp) &&
+ (!cgroup_subsys_on_dfl(cpuset_cgrp_subsys) ||
+ is_sched_domain_root(cp)))
need_rebuild_sched_domains = true;
rcu_read_lock();
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v10 9/9] cpuset: Allow reporting of sched domain generation info
From: Waiman Long @ 2018-06-18 4:14 UTC (permalink / raw)
To: Tejun Heo, Li Zefan, Johannes Weiner, Peter Zijlstra, Ingo Molnar
Cc: cgroups, linux-kernel, linux-doc, kernel-team, pjt, luto,
Mike Galbraith, torvalds, Roman Gushchin, Juri Lelli,
Patrick Bellasi, Waiman Long
In-Reply-To: <1529295249-5207-1-git-send-email-longman@redhat.com>
This patch enables us to report sched domain generation information.
If DYNAMIC_DEBUG is enabled, issuing the following command
echo "file cpuset.c +p" > /sys/kernel/debug/dynamic_debug/control
and setting loglevel to 8 will allow the kernel to show what scheduling
domain changes are being made.
Signed-off-by: Waiman Long <longman@redhat.com>
---
kernel/cgroup/cpuset.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index ed80663..2943d7c 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -836,6 +836,23 @@ static int generate_sched_domains(cpumask_var_t **domains,
return ndoms;
}
+#ifdef CONFIG_DEBUG_KERNEL
+static inline void debug_print_domains(cpumask_var_t *doms, int ndoms)
+{
+ int i;
+ char buf[200];
+ char *ptr, *end = buf + sizeof(buf) - 1;
+
+ for (i = 0, ptr = buf, *end = '\0'; i < ndoms; i++)
+ ptr += snprintf(ptr, end - ptr, "dom%d=%*pbl ", i,
+ cpumask_pr_args(doms[i]));
+
+ pr_debug("Generated %d domains: %s\n", ndoms, buf);
+}
+#else
+static inline void debug_print_domains(cpumask_var_t *doms, int ndoms) { }
+#endif
+
/*
* Rebuild scheduler domains.
*
@@ -871,6 +888,7 @@ static void rebuild_sched_domains_locked(void)
/* Generate domain masks and attrs */
ndoms = generate_sched_domains(&doms, &attr);
+ debug_print_domains(doms, ndoms);
/* Have scheduler rebuild the domains */
partition_sched_domains(ndoms, doms, attr);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v10 2/9] cpuset: Add new v2 cpuset.sched.domain_root flag
From: Waiman Long @ 2018-06-18 4:14 UTC (permalink / raw)
To: Tejun Heo, Li Zefan, Johannes Weiner, Peter Zijlstra, Ingo Molnar
Cc: cgroups, linux-kernel, linux-doc, kernel-team, pjt, luto,
Mike Galbraith, torvalds, Roman Gushchin, Juri Lelli,
Patrick Bellasi, Waiman Long
In-Reply-To: <1529295249-5207-1-git-send-email-longman@redhat.com>
A new cpuset.sched.domain_root boolean flag is added to cpuset
v2. This new flag, if set, indicates that the cgroup is the root of
a new scheduling domain or partition that includes itself and all its
descendants except those that are scheduling domain roots themselves
and their descendants.
With this new flag, one can directly create as many partitions as
necessary without ever using the v1 trick of turning off load balancing
in specific cpusets to create partitions as a side effect.
This new flag is owned by the parent and will cause the CPUs in the
cpuset to be removed from the effective CPUs of its parent.
This is implemented internally by adding a new reserved_cpus mask that
holds the CPUs belonging to child scheduling domain cpusets so that:
reserved_cpus | effective_cpus = cpus_allowed
reserved_cpus & effective_cpus = 0
This new flag can only be turned on in a cpuset if its parent is a
scheduling domain root itself. The state of this flag cannot be changed
if the cpuset has children.
Signed-off-by: Waiman Long <longman@redhat.com>
---
Documentation/admin-guide/cgroup-v2.rst | 33 +++++
kernel/cgroup/cpuset.c | 209 +++++++++++++++++++++++++++++++-
2 files changed, 239 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index fbc30b6..d5e25a0 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -1584,6 +1584,39 @@ Cpuset Interface Files
Its value will be affected by memory nodes hotplug events.
+ cpuset.sched.domain_root
+ A read-write single value file which exists on non-root
+ cpuset-enabled cgroups. It is a binary value flag that accepts
+ either "0" (off) or "1" (on). This flag is set by the parent
+ and is not delegatable.
+
+ If set, it indicates that the current cgroup is the root of a
+ new scheduling domain or partition that comprises itself and
+ all its descendants except those that are scheduling domain
+ roots themselves and their descendants. The root cgroup is
+ always a scheduling domain root.
+
+ There are constraints on where this flag can be set. It can
+ only be set in a cgroup if all the following conditions are true.
+
+ 1) The "cpuset.cpus" is not empty and the list of CPUs are
+ exclusive, i.e. they are not shared by any of its siblings.
+ 2) The "cpuset.cpus" is also a proper subset of the parent's
+ "cpuset.cpus.effective".
+ 3) The parent cgroup is a scheduling domain root.
+ 4) There is no child cgroups with cpuset enabled. This is
+ for eliminating corner cases that have to be handled if such
+ a condition is allowed.
+
+ Setting this flag will take the CPUs away from the effective
+ CPUs of the parent cgroup. Once it is set, this flag cannot be
+ cleared if there are any child cgroups with cpuset enabled.
+
+ A parent scheduling domain root cgroup cannot distribute
+ all its CPUs to its child scheduling domain root cgroups.
+ There must be at least one cpu left in the parent scheduling
+ domain root cgroup.
+
Device controller
-----------------
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 2b5c447..68a9c25 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -109,6 +109,9 @@ struct cpuset {
cpumask_var_t effective_cpus;
nodemask_t effective_mems;
+ /* CPUs reserved for child scheduling domains */
+ cpumask_var_t reserved_cpus;
+
/*
* This is old Memory Nodes tasks took on.
*
@@ -134,6 +137,9 @@ struct cpuset {
/* for custom sched domain */
int relax_domain_level;
+
+ /* number of CPUs in reserved_cpus */
+ int nr_reserved;
};
static inline struct cpuset *css_cs(struct cgroup_subsys_state *css)
@@ -175,6 +181,7 @@ static inline bool task_has_mempolicy(struct task_struct *task)
CS_SCHED_LOAD_BALANCE,
CS_SPREAD_PAGE,
CS_SPREAD_SLAB,
+ CS_SCHED_DOMAIN_ROOT,
} cpuset_flagbits_t;
/* convenient tests for these bits */
@@ -203,6 +210,11 @@ static inline int is_sched_load_balance(const struct cpuset *cs)
return test_bit(CS_SCHED_LOAD_BALANCE, &cs->flags);
}
+static inline int is_sched_domain_root(const struct cpuset *cs)
+{
+ return test_bit(CS_SCHED_DOMAIN_ROOT, &cs->flags);
+}
+
static inline int is_memory_migrate(const struct cpuset *cs)
{
return test_bit(CS_MEMORY_MIGRATE, &cs->flags);
@@ -220,7 +232,7 @@ static inline int is_spread_slab(const struct cpuset *cs)
static struct cpuset top_cpuset = {
.flags = ((1 << CS_ONLINE) | (1 << CS_CPU_EXCLUSIVE) |
- (1 << CS_MEM_EXCLUSIVE)),
+ (1 << CS_MEM_EXCLUSIVE) | (1 << CS_SCHED_DOMAIN_ROOT)),
};
/**
@@ -881,6 +893,27 @@ static void update_tasks_cpumask(struct cpuset *cs)
css_task_iter_end(&it);
}
+/**
+ * compute_effective_cpumask - Compute the effective cpumask of the cpuset
+ * @new_cpus: the temp variable for the new effective_cpus mask
+ * @cs: the cpuset the need to recompute the new effective_cpus mask
+ * @parent: the parent cpuset
+ *
+ * If the parent has reserved CPUs, include them in the list of allowable
+ * CPUs in computing the new effective_cpus mask.
+ */
+static void compute_effective_cpumask(struct cpumask *new_cpus,
+ struct cpuset *cs, struct cpuset *parent)
+{
+ if (parent->nr_reserved) {
+ cpumask_or(new_cpus, parent->effective_cpus,
+ parent->reserved_cpus);
+ cpumask_and(new_cpus, new_cpus, cs->cpus_allowed);
+ } else {
+ cpumask_and(new_cpus, cs->cpus_allowed, parent->effective_cpus);
+ }
+}
+
/*
* update_cpumasks_hier - Update effective cpumasks and tasks in the subtree
* @cs: the cpuset to consider
@@ -903,7 +936,7 @@ static void update_cpumasks_hier(struct cpuset *cs, struct cpumask *new_cpus)
cpuset_for_each_descendant_pre(cp, pos_css, cs) {
struct cpuset *parent = parent_cs(cp);
- cpumask_and(new_cpus, cp->cpus_allowed, parent->effective_cpus);
+ compute_effective_cpumask(new_cpus, cp, parent);
/*
* If it becomes empty, inherit the effective mask of the
@@ -949,6 +982,130 @@ static void update_cpumasks_hier(struct cpuset *cs, struct cpumask *new_cpus)
}
/**
+ * update_reserved_cpumask - update the reserved_cpus mask of parent cpuset
+ * @cpuset: The cpuset that requests CPU reservation
+ * @delmask: The old reserved cpumask to be removed from the parent
+ * @addmask: The new reserved cpumask to be added to the parent
+ * Return: 0 if successful, an error code otherwise
+ *
+ * Changes to the reserved CPUs are not allowed if any of CPUs changing
+ * state are in any of the child cpusets of the parent except the requesting
+ * child.
+ *
+ * If the sched_domain_root flag changes, either the delmask (0=>1) or the
+ * addmask (1=>0) will be NULL.
+ *
+ * Called with cpuset_mutex held.
+ */
+static int update_reserved_cpumask(struct cpuset *cpuset,
+ struct cpumask *delmask, struct cpumask *addmask)
+{
+ int retval;
+ struct cpuset *parent = parent_cs(cpuset);
+ struct cpuset *sibling;
+ struct cgroup_subsys_state *pos_css;
+ int old_count = parent->nr_reserved;
+
+ /*
+ * The parent must be a scheduling domain root.
+ * The new cpumask, if present, must not be empty.
+ */
+ if (!is_sched_domain_root(parent) ||
+ (addmask && cpumask_empty(addmask)))
+ return -EINVAL;
+
+ /*
+ * The delmask, if present, must be a subset of parent's reserved
+ * CPUs.
+ */
+ if (delmask && !cpumask_empty(delmask) && (!parent->nr_reserved ||
+ !cpumask_subset(delmask, parent->reserved_cpus))) {
+ WARN_ON_ONCE(1);
+ return -EINVAL;
+ }
+
+ /*
+ * A sched_domain_root state change is not allowed if there are
+ * online children.
+ */
+ if (css_has_online_children(&cpuset->css))
+ return -EBUSY;
+
+ if (!old_count) {
+ if (!zalloc_cpumask_var(&parent->reserved_cpus, GFP_KERNEL)) {
+ retval = -ENOMEM;
+ goto out;
+ }
+ old_count = 1;
+ }
+
+ retval = -EBUSY;
+
+ /*
+ * The cpus to be added must be a proper subset of the parent's
+ * effective_cpus mask but not in the reserved_cpus mask.
+ */
+ if (addmask) {
+ if (!cpumask_subset(addmask, parent->effective_cpus) ||
+ cpumask_equal(addmask, parent->effective_cpus))
+ goto out;
+ if (parent->nr_reserved &&
+ cpumask_intersects(parent->reserved_cpus, addmask))
+ goto out;
+ }
+
+ /*
+ * Check if any CPUs in addmask or delmask are in the effective_cpus
+ * of a sibling cpuset. The implied cpu_exclusive of a scheduling
+ * domain root will ensure there are no overlap in cpus_allowed.
+ */
+ rcu_read_lock();
+ cpuset_for_each_child(sibling, pos_css, parent) {
+ if ((sibling == cpuset) || !(sibling->css.flags & CSS_ONLINE))
+ continue;
+ if (addmask &&
+ cpumask_intersects(sibling->effective_cpus, addmask))
+ goto out_unlock;
+ if (delmask &&
+ cpumask_intersects(sibling->effective_cpus, delmask))
+ goto out_unlock;
+ }
+ rcu_read_unlock();
+
+ /*
+ * Change the reserved CPU list.
+ * Newly added reserved CPUs will be removed from effective_cpus
+ * and newly deleted ones will be added back if they are online.
+ */
+ spin_lock_irq(&callback_lock);
+ if (addmask) {
+ cpumask_or(parent->reserved_cpus,
+ parent->reserved_cpus, addmask);
+ cpumask_andnot(parent->effective_cpus,
+ parent->effective_cpus, addmask);
+ }
+ if (delmask) {
+ cpumask_andnot(parent->reserved_cpus,
+ parent->reserved_cpus, delmask);
+ cpumask_or(parent->effective_cpus,
+ parent->effective_cpus, delmask);
+ }
+
+ parent->nr_reserved = cpumask_weight(parent->reserved_cpus);
+ spin_unlock_irq(&callback_lock);
+ retval = 0;
+out:
+ if (old_count && !parent->nr_reserved)
+ free_cpumask_var(parent->reserved_cpus);
+
+ return retval;
+
+out_unlock:
+ rcu_read_unlock();
+ goto out;
+}
+
+/**
* update_cpumask - update the cpus_allowed mask of a cpuset and all tasks in it
* @cs: the cpuset to consider
* @trialcs: trial cpuset
@@ -989,6 +1146,9 @@ static int update_cpumask(struct cpuset *cs, struct cpuset *trialcs,
if (retval < 0)
return retval;
+ if (is_sched_domain_root(cs))
+ return -EBUSY;
+
spin_lock_irq(&callback_lock);
cpumask_copy(cs->cpus_allowed, trialcs->cpus_allowed);
spin_unlock_irq(&callback_lock);
@@ -1317,6 +1477,7 @@ static int update_flag(cpuset_flagbits_t bit, struct cpuset *cs,
struct cpuset *trialcs;
int balance_flag_changed;
int spread_flag_changed;
+ int domain_flag_changed;
int err;
trialcs = alloc_trial_cpuset(cs);
@@ -1328,6 +1489,18 @@ static int update_flag(cpuset_flagbits_t bit, struct cpuset *cs,
else
clear_bit(bit, &trialcs->flags);
+ /*
+ * Turning on sched.domain flag (default hierarchy only) implies
+ * an implicit cpu_exclusive. Turning off sched.domain will clear
+ * the cpu_exclusive flag.
+ */
+ if (bit == CS_SCHED_DOMAIN_ROOT) {
+ if (turning_on)
+ set_bit(CS_CPU_EXCLUSIVE, &trialcs->flags);
+ else
+ clear_bit(CS_CPU_EXCLUSIVE, &trialcs->flags);
+ }
+
err = validate_change(cs, trialcs);
if (err < 0)
goto out;
@@ -1338,11 +1511,27 @@ static int update_flag(cpuset_flagbits_t bit, struct cpuset *cs,
spread_flag_changed = ((is_spread_slab(cs) != is_spread_slab(trialcs))
|| (is_spread_page(cs) != is_spread_page(trialcs)));
+ domain_flag_changed = (is_sched_domain_root(cs) !=
+ is_sched_domain_root(trialcs));
+
+ if (domain_flag_changed) {
+ err = turning_on
+ ? update_reserved_cpumask(cs, NULL, cs->cpus_allowed)
+ : update_reserved_cpumask(cs, cs->cpus_allowed, NULL);
+ if (err < 0)
+ goto out;
+ /*
+ * At this point, the state has been changed.
+ * So we can't back out with error anymore.
+ */
+ }
+
spin_lock_irq(&callback_lock);
cs->flags = trialcs->flags;
spin_unlock_irq(&callback_lock);
- if (!cpumask_empty(trialcs->cpus_allowed) && balance_flag_changed)
+ if (!cpumask_empty(trialcs->cpus_allowed) &&
+ (balance_flag_changed || domain_flag_changed))
rebuild_sched_domains_locked();
if (spread_flag_changed)
@@ -1597,6 +1786,7 @@ static void cpuset_attach(struct cgroup_taskset *tset)
FILE_MEM_EXCLUSIVE,
FILE_MEM_HARDWALL,
FILE_SCHED_LOAD_BALANCE,
+ FILE_SCHED_DOMAIN_ROOT,
FILE_SCHED_RELAX_DOMAIN_LEVEL,
FILE_MEMORY_PRESSURE_ENABLED,
FILE_MEMORY_PRESSURE,
@@ -1630,6 +1820,9 @@ static int cpuset_write_u64(struct cgroup_subsys_state *css, struct cftype *cft,
case FILE_SCHED_LOAD_BALANCE:
retval = update_flag(CS_SCHED_LOAD_BALANCE, cs, val);
break;
+ case FILE_SCHED_DOMAIN_ROOT:
+ retval = update_flag(CS_SCHED_DOMAIN_ROOT, cs, val);
+ break;
case FILE_MEMORY_MIGRATE:
retval = update_flag(CS_MEMORY_MIGRATE, cs, val);
break;
@@ -1791,6 +1984,8 @@ static u64 cpuset_read_u64(struct cgroup_subsys_state *css, struct cftype *cft)
return is_mem_hardwall(cs);
case FILE_SCHED_LOAD_BALANCE:
return is_sched_load_balance(cs);
+ case FILE_SCHED_DOMAIN_ROOT:
+ return is_sched_domain_root(cs);
case FILE_MEMORY_MIGRATE:
return is_memory_migrate(cs);
case FILE_MEMORY_PRESSURE_ENABLED:
@@ -1967,6 +2162,14 @@ static s64 cpuset_read_s64(struct cgroup_subsys_state *css, struct cftype *cft)
.flags = CFTYPE_NOT_ON_ROOT,
},
+ {
+ .name = "sched.domain_root",
+ .read_u64 = cpuset_read_u64,
+ .write_u64 = cpuset_write_u64,
+ .private = FILE_SCHED_DOMAIN_ROOT,
+ .flags = CFTYPE_NOT_ON_ROOT,
+ },
+
{ } /* terminate */
};
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v10 0/9] cpuset: Enable cpuset controller in default hierarchy
From: Waiman Long @ 2018-06-18 4:13 UTC (permalink / raw)
To: Tejun Heo, Li Zefan, Johannes Weiner, Peter Zijlstra, Ingo Molnar
Cc: cgroups, linux-kernel, linux-doc, kernel-team, pjt, luto,
Mike Galbraith, torvalds, Roman Gushchin, Juri Lelli,
Patrick Bellasi, Waiman Long
v10:
- Remove the cpuset.sched.load_balance patch for now as it may not
be that useful.
- Break the large patch 2 into smaller patches to make them a bit
easier to review.
- Test and fix issues related to changing "cpuset.cpus" and cpu
online/offline in a domain root.
- Rename isolated_cpus to reserved_cpus as this cpumask holds CPUs
reserved for child sched domains.
- Rework the scheduling domain debug printing code in the last patch.
- Document update to the newly moved
Documentation/admin-guide/cgroup-v2.rst.
v9:
- Rename cpuset.sched.domain to cpuset.sched.domain_root to better
identify its purpose as the root of a new scheduling domain or
partition.
- Clarify in the document about the purpose of domain_root and
load_balance. Using domain_root is th only way to create new
partition.
- Fix a lockdep warning in update_isolated_cpumask() function.
- Add a new patch to eliminate call to generate_sched_domains() for
v2 when a change in cpu list does not touch a domain_root.
v8:
- Remove cpuset.cpus.isolated and add a new cpuset.sched.domain flag
and rework the code accordingly.
v7:
- Add a root-only cpuset.cpus.isolated control file for CPU isolation.
- Enforce that load_balancing can only be turned off on cpusets with
CPUs from the isolated list.
- Update sched domain generation to allow cpusets with CPUs only
from the isolated CPU list to be in separate root domains.
v6:
- Hide cpuset control knobs in root cgroup.
- Rename effective_cpus and effective_mems to cpus.effective and
mems.effective respectively.
- Remove cpuset.flags and add cpuset.sched_load_balance instead
as the behavior of sched_load_balance has changed and so is
not a simple flag.
- Update cgroup-v2.txt accordingly.
v5:
- Add patch 2 to provide the cpuset.flags control knob for the
sched_load_balance flag which should be the only feature that is
essential as a replacement of the "isolcpus" kernel boot parameter.
v4:
- Further minimize the feature set by removing the flags control knob.
v3:
- Further trim the additional features down to just memory_migrate.
- Update Documentation/cgroup-v2.txt.
v7 patch: https://lkml.org/lkml/2018/4/19/448
v8 patch: https://lkml.org/lkml/2018/5/17/939
v9 patch: https://lkml.org/lkml/2018/5/29/507
The purpose of this patchset is to provide a basic set of cpuset control
files for cgroup v2. This basic set includes the non-root "cpus", "mems"
and "sched.domain_root". The "cpus.effective" and "mems.effective"
will appear in all cpuset-enabled cgroups.
The new control file that is unique to v2 is "sched.domain_root". It
is a boolean flag file that designates if a cgroup is the root of a new
scheduling domain or partition with its own set of unique list of CPUs
from scheduling perspective disjointed from other partitions. The root
cgroup is always a scheduling domain root. Multiple levels of scheduling
domains are supported with some limitations. So a container scheduling
domain root can behave like a real root.
When a scheduling domain root cgroup is removed, its list of exclusive
CPUs will be returned to the parent's cpus.effective automatically.
This patchset does not exclude the possibility of adding more features
in the future after careful consideration.
Patch 1 enables cpuset in cgroup v2 with cpus, mems and their effective
counterparts.
Patch 2 adds a new "sched.domain_root" control file for setting up
multiple scheduling domains or partitions. A scheduling domain root
implies cpu_exclusive.
Patch 3 handles the proper deletion of a domain root cgroup by turning
off the domain_root flag automatically before deletion.
Patch 4 allows "cpuset.cpus" of a domain root cgroup to be changed
subject to certain constraints.
Patch 5 makes the hotplug code deal with domain root properly.
Patch 6 updates the scheduling domain genaration code to work with
the new domain root feature.
Patch 7 exposes cpus.effective and mems.effective to the root cgroup as
enabling child scheduling domains will take CPUs away from the root cgroup.
So it will be nice to monitor what CPUs are left there.
Patch 8 eliminates the need to rebuild sched domains for v2 if cpu list
changes occur to non-domain root cpusets only.
Patch 9 enables the printing the debug information about scheduling
domain generation.
Waiman Long (9):
cpuset: Enable cpuset controller in default hierarchy
cpuset: Add new v2 cpuset.sched.domain_root flag
cpuset: Simulate auto-off of sched.domain_root at cgroup removal
cpuset: Allow changes to cpus in a domain root
cpuset: Make sure that domain roots work properly with CPU hotplug
cpuset: Make generate_sched_domains() recognize reserved_cpus
cpuset: Expose cpus.effective and mems.effective on cgroup v2 root
cpuset: Don't rebuild sched domains if cpu changes in non-domain root
cpuset: Allow reporting of sched domain generation info
Documentation/admin-guide/cgroup-v2.rst | 158 ++++++++++++-
kernel/cgroup/cpuset.c | 406 ++++++++++++++++++++++++++++++--
2 files changed, 543 insertions(+), 21 deletions(-)
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 5/5] Documentation/ABI: Add details of PCI AER statistics
From: poza @ 2018-06-17 5:24 UTC (permalink / raw)
To: Rajat Jain
Cc: Bjorn Helgaas, Jonathan Corbet, Philippe Ombredanne, Kate Stewart,
Thomas Gleixner, Greg Kroah-Hartman, Frederick Lawler,
Keith Busch, Gabriele Paoloni, Alexandru Gagniuc, Thomas Tai,
Steven Rostedt (VMware), linux-pci, linux-doc, linux-kernel,
Jes Sorensen, Kyle McMartin, rajatxjain
In-Reply-To: <20180523175808.28030-6-rajatja@google.com>
On 2018-05-23 23:28, Rajat Jain wrote:
> Add the PCI AER statistics details to
> Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
> and provide a pointer to it in
> Documentation/PCI/pcieaer-howto.txt
>
> Signed-off-by: Rajat Jain <rajatja@google.com>
> ---
> v2: Move the documentation to Documentation/ABI/
>
> .../testing/sysfs-bus-pci-devices-aer_stats | 103 ++++++++++++++++++
> Documentation/PCI/pcieaer-howto.txt | 5 +
> 2 files changed, 108 insertions(+)
> create mode 100644
> Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
> b/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
> new file mode 100644
> index 000000000000..f55c389290ac
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
> @@ -0,0 +1,103 @@
> +==========================
> +PCIe Device AER statistics
> +==========================
> +These attributes show up under all the devices that are AER capable.
> These
> +statistical counters indicate the errors "as seen/reported by the
> device".
> +Note that this may mean that if an end point is causing problems, the
> AER
> +counters may increment at its link partner (e.g. root port) because
> the
> +errors will be "seen" / reported by the link partner and not the the
> +problematic end point itself (which may report all counters as 0 as it
> never
> +saw any problems).
> +
> +Where: /sys/bus/pci/devices/<dev>/aer_stats/dev_total_cor_errs
> +Date: May 2018
> +Kernel Version: 4.17.0
> +Contact: linux-pci@vger.kernel.org, rajatja@google.com
> +Description: Total number of correctable errors seen and reported by
> this
> + PCI device using ERR_COR.
> +
> +Where: /sys/bus/pci/devices/<dev>/aer_stats/dev_total_fatal_errs
> +Date: May 2018
> +Kernel Version: 4.17.0
> +Contact: linux-pci@vger.kernel.org, rajatja@google.com
> +Description: Total number of uncorrectable fatal errors seen and
> reported
> + by this PCI device using ERR_FATAL.
> +
> +Where: /sys/bus/pci/devices/<dev>/aer_stats/dev_total_nonfatal_errs
> +Date: May 2018
> +Kernel Version: 4.17.0
> +Contact: linux-pci@vger.kernel.org, rajatja@google.com
> +Description: Total number of uncorrectable non-fatal errors seen and
> reported
> + by this PCI device using ERR_NONFATAL.
> +
> +Where: /sys/bus/pci/devices/<dev>/aer_stats/dev_breakdown_correctable
> +Date: May 2018
> +Kernel Version: 4.17.0
> +Contact: linux-pci@vger.kernel.org, rajatja@google.com
> +Description: Breakdown of of correctable errors seen and reported by
> this
> + PCI device using ERR_COR. A sample result looks like this:
> +-----------------------------------------
> +Receiver Error = 0x174
> +Bad TLP = 0x19
> +Bad DLLP = 0x3
> +RELAY_NUM Rollover = 0x0
> +Replay Timer Timeout = 0x1
> +Advisory Non-Fatal = 0x0
> +Corrected Internal Error = 0x0
> +Header Log Overflow = 0x0
> +-----------------------------------------
why hex display ? decimal is easy to read as these are counters.
> +
> +Where: /sys/bus/pci/devices/<dev>/aer_stats/dev_breakdown_uncorrectable
> +Date: May 2018
> +Kernel Version: 4.17.0
> +Contact: linux-pci@vger.kernel.org, rajatja@google.com
> +Description: Breakdown of of correctable errors seen and reported by
> this
> + PCI device using ERR_FATAL or ERR_NONFATAL. A sample result
> + looks like this:
> +-----------------------------------------
> +Undefined = 0x0
> +Data Link Protocol = 0x0
> +Surprise Down Error = 0x0
> +Poisoned TLP = 0x0
> +Flow Control Protocol = 0x0
> +Completion Timeout = 0x0
> +Completer Abort = 0x0
> +Unexpected Completion = 0x0
> +Receiver Overflow = 0x0
> +Malformed TLP = 0x0
> +ECRC = 0x0
> +Unsupported Request = 0x0
> +ACS Violation = 0x0
> +Uncorrectable Internal Error = 0x0
> +MC Blocked TLP = 0x0
> +AtomicOp Egress Blocked = 0x0
> +TLP Prefix Blocked Error = 0x0
> +-----------------------------------------
> +
> +============================
> +PCIe Rootport AER statistics
> +============================
> +These attributes showup under only the rootports that are AER capable.
> These
> +indicate the number of error messages as "reported to" the rootport.
> Please note
> +that the rootports also transmit (internally) the ERR_* messages for
> errors seen
> +by the internal rootport PCI device, so these counters includes them
> and are
> +thus cumulative of all the error messages on the PCI hierarchy
> originating
> +at that root port.
what about switches and bridges ?
Also Can you give some idea as e.g what is the difference between
dev_total_fatal_errs and rootport_total_fatal_errs (assuming that both
are same pci_dev.
rootport_total_fatal_errs gives me an idea that how many times things
have been failed under this pci_dev ?
which means num of downstream link problems. but I am still trying to
make sense as how it could be used,
since we dont have BDF information associated with the number of errors
anywhere (except these AER print messages)
and dev_total_fatal_errs as you mentioned above that problematic EP,
then say root-port will report it and increment
dev_total_fatal_errs ++
does it also increment root-port_total_fatal_errs ++ in above scenario ?
> +
> +Where: /sys/bus/pci/devices/<dev>/aer_stats/rootport_total_cor_errs
> +Date: May 2018
> +Kernel Version: 4.17.0
> +Contact: linux-pci@vger.kernel.org, rajatja@google.com
> +Description: Total number of ERR_COR messages reported to rootport.
> +
> +Where: /sys/bus/pci/devices/<dev>/aer_stats/rootport_total_fatal_errs
> +Date: May 2018
> +Kernel Version: 4.17.0
> +Contact: linux-pci@vger.kernel.org, rajatja@google.com
> +Description: Total number of ERR_FATAL messages reported to rootport.
> +
> +Where:
> /sys/bus/pci/devices/<dev>/aer_stats/rootport_total_nonfatal_errs
> +Date: May 2018
> +Kernel Version: 4.17.0
> +Contact: linux-pci@vger.kernel.org, rajatja@google.com
> +Description: Total number of ERR_NONFATAL messages reported to
> rootport.
> diff --git a/Documentation/PCI/pcieaer-howto.txt
> b/Documentation/PCI/pcieaer-howto.txt
> index acd0dddd6bb8..91b6e677cb8c 100644
> --- a/Documentation/PCI/pcieaer-howto.txt
> +++ b/Documentation/PCI/pcieaer-howto.txt
> @@ -73,6 +73,11 @@ In the example, 'Requester ID' means the ID of the
> device who sends
> the error message to root port. Pls. refer to pci express specs for
> other fields.
>
> +2.4 AER Statistics / Counters
> +
> +When PCIe AER errors are captured, the counters / statistics are also
> exposed
> +in form of sysfs attributes which are documented at
> +Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
>
> 3. Developer Guide
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] locking/memory-barriers.txt/kokr: Update Korean translation to fix broken DMA vs. MMIO ordering example
From: SeongJae Park @ 2018-06-17 5:16 UTC (permalink / raw)
To: paulmck; +Cc: linux-doc, linux-kernel, SeongJae Park
Translate this commit to Korean:
5846581e3563 ("locking/memory-barriers.txt: Fix broken DMA vs. MMIO ordering example")
Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
Documentation/translations/ko_KR/memory-barriers.txt | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
index 921739d00f69..ada0a709cce1 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -1891,19 +1891,18 @@ Mandatory 배리어들은 SMP 시스템에서도 UP 시스템에서도 SMP 효
/* 소유권을 수정 */
desc->status = DEVICE_OWN;
- /* MMIO 를 통해 디바이스에 공지를 하기 전에 메모리를 동기화 */
- wmb();
-
/* 업데이트된 디스크립터의 디바이스에 공지 */
writel(DESC_NOTIFY, doorbell);
}
dma_rmb() 는 디스크립터로부터 데이터를 읽어오기 전에 디바이스가 소유권을
- 내놓았음을 보장하게 하고, dma_wmb() 는 디바이스가 자신이 소유권을 다시
- 가졌음을 보기 전에 디스크립터에 데이터가 쓰였음을 보장합니다. wmb() 는
- 캐시 일관성이 없는 (cache incoherent) MMIO 영역에 쓰기를 시도하기 전에
- 캐시 일관성이 있는 메모리 (cache coherent memory) 쓰기가 완료되었음을
- 보장해주기 위해 필요합니다.
+ 내려놓았을 것을 보장하고, dma_wmb() 는 디바이스가 자신이 소유권을 다시
+ 가졌음을 보기 전에 디스크립터에 데이터가 쓰였을 것을 보장합니다. writel()
+ 을 사용하면 캐시 일관성이 있는 메모리 (cache coherent memory) 쓰기가 MMIO
+ 영역에의 쓰기 전에 완료되었을 것을 보장하므로 writel() 앞에 wmb() 를
+ 실행할 필요가 없음을 알아두시기 바랍니다. writel() 보다 비용이 저렴한
+ writel_relaxed() 는 이런 보장을 제공하지 않으므로 여기선 사용되지 않아야
+ 합니다.
consistent memory 에 대한 자세한 내용을 위해선 Documentation/DMA-API.txt
문서를 참고하세요.
--
2.13.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 00/10] Control Flow Enforcement - Part (3)
From: Balbir Singh @ 2018-06-17 3:16 UTC (permalink / raw)
To: Yu-cheng Yu
Cc: linux-kernel, linux-doc, linux-mm, linux-arch, x86,
H. Peter Anvin, Thomas Gleixner, Ingo Molnar, H.J. Lu,
Vedvyas Shanbhogue, Ravi V. Shankar, Dave Hansen, Andy Lutomirski,
Jonathan Corbet, Oleg Nesterov, Arnd Bergmann, Mike Kravetz
In-Reply-To: <1528988176.13101.15.camel@2b52.sc.intel.com>
On Thu, 2018-06-14 at 07:56 -0700, Yu-cheng Yu wrote:
> On Thu, 2018-06-14 at 11:07 +1000, Balbir Singh wrote:
> > On Tue, 2018-06-12 at 08:03 -0700, Yu-cheng Yu wrote:
> > > On Tue, 2018-06-12 at 20:56 +1000, Balbir Singh wrote:
> > > >
> > > > On 08/06/18 00:37, Yu-cheng Yu wrote:
> > > > > This series introduces CET - Shadow stack
> > > > >
> > > > > At the high level, shadow stack is:
> > > > >
> > > > > Allocated from a task's address space with vm_flags VM_SHSTK;
> > > > > Its PTEs must be read-only and dirty;
> > > > > Fixed sized, but the default size can be changed by sys admin.
> > > > >
> > > > > For a forked child, the shadow stack is duplicated when the next
> > > > > shadow stack access takes place.
> > > > >
> > > > > For a pthread child, a new shadow stack is allocated.
> > > > >
> > > > > The signal handler uses the same shadow stack as the main program.
> > > > >
> > > >
> > > > Even with sigaltstack()?
> > > >
> > >
> > > Yes.
> >
> > I am not convinced that it would work, as we switch stacks, oveflow might
> > be an issue. I also forgot to bring up setcontext(2), I presume those
> > will get new shadow stacks
>
> Do you mean signal stack/sigaltstack overflow or swapcontext in a signal
> handler?
>
I meant any combination of that. If there is a user space threads implementation that uses sigaltstack for switching threads
Balbir Singh.
> Yu-cheng
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RESEND v4 2/2] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
From: gengdongjiu @ 2018-06-17 2:37 UTC (permalink / raw)
To: James Morse
Cc: rkrcmar@redhat.com, corbet@lwn.net, christoffer.dall@arm.com,
marc.zyngier@arm.com, linux@armlinux.org.uk,
catalin.marinas@arm.com, will.deacon@arm.com, kvm@vger.kernel.org,
linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2530 bytes --]
>
> > >>>>> --- a/arch/arm/include/uapi/asm/kvm.h
> > >>>>> +++ b/arch/arm/include/uapi/asm/kvm.h
> > >>>>> @@ -124,6 +124,18 @@ struct kvm_sync_regs { struct
> > >>>>> kvm_arch_memory_slot { };
> > >>>>>
> > >>>>> +/* for KVM_GET/SET_VCPU_EVENTS */ struct kvm_vcpu_events {
> > >>>>> + struct {
> > >>>>> + __u8 serror_pending;
> > >>>>> + __u8 serror_has_esr;
> > >>>>> + /* Align it to 8 bytes */
> > >>>>> + __u8 pad[6];
> > >>>>> + __u64 serror_esr;
> > >>>>> + } exception;
> > >>>>> + __u32 reserved[12];
> > >>>>> +};
> > >>>>> +
> > >>>>
> > >>>> You haven't defined __KVM_HAVE_VCPU_EVENTS for 32bit, so
> > >>>> presumably this struct will never be used. Why is it here?
> > >>
> > >>> if not add it for 32 bits. the 32 arm platform will build Fail, whether you have good
> > >>> idea to avoid this Failure if not add this struct for the 32 bit?
> > >>
> > >> How does this 32bit code build without this patch?
> > >> If do you provide the struct, how will that code build with older headers?
> > >>
> > >> As far as I can see, this is what the __KVM_HAVE_VCPU_EVENTS define is for.
> > >>
> > >> This should be both, or neither. Having just the struct is useless.
> > > It because the caller of kvm_arm_vcpu_get/set_events() is in "virt/kvm/arm/arm.c".
> > > the virt/kvm/arm/arm.c will used by both arm64 and arm.
> > > so It needs to add kvm_arm_vcpu_get/set_events() for the 32 bits,
> > > however, kvm_arm_vcpu_get/set_events() will directly return,
> >
> > So you are adding a uapi struct that user-space can't actually use, to avoid a kernel build-error. Fine, it just looks really strange.
> >
> > 32bit user-space shouldn't try to call this as check-extension reports
> > it as not present. If it does, it gets -EINVAL back, which is also the default for kvm_arch_vcpu_ioctl().
Just think out a method to avoid adding the structure for the arm32.
Using below methods:
#Ifdef __KVM_HAVE_VCPU_EVENTS
xxxxxxxxxxxxxxxxxxxxx
#else
Xxxxxxxxxxxxxxxx
#endif
>
> It indeed looks strange. Because "virt/kvm/arm/arm.c" is shared by arm64 and arm32, if not adding, it will build-error. Do you have a better
> idea to avoid adding in arm32?
> I still not think out a good method. 32 user-space will not call this KVM_GET/SET_VCPU_EVENTS IOCTL as check-extension reports it as not
> present.
>
> >
> >
> > Thanks,
> >
> > James
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±v‡"žØ^n‡r¡ö¦zË\x1aëh™¨èÚ&¢ø\x1e®G«éh®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿïêäz¹Þ–Šàþf£¢·hšˆ§~ˆmš
^ permalink raw reply
* [PATCH] Documentation/process: fix reST table border error
From: Randy Dunlap @ 2018-06-17 2:02 UTC (permalink / raw)
To: linux-doc@vger.kernel.org, Jonathan Corbet; +Cc: Tim Bird, LKML
From: Randy Dunlap <rdunlap@infradead.org>
Fix reST error in Documentation/process/:
Documentation/process/2.Process.rst:131: ERROR: Malformed table.
Bottom/header table border does not match top border.
Fixes: 8962e40c1993 ("docs: update kernel versions and dates in tables")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Tim Bird <tbird20d@gmail.com>
---
Documentation/process/2.Process.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- lnx-418-rc1.orig/Documentation/process/2.Process.rst
+++ lnx-418-rc1/Documentation/process/2.Process.rst
@@ -134,7 +134,7 @@ and their maintainers are:
4.4 Greg Kroah-Hartman (very long-term stable kernel)
4.9 Greg Kroah-Hartman
4.14 Greg Kroah-Hartman
- ====== ====================== ===========================
+ ====== ====================== ==============================
The selection of a kernel for long-term support is purely a matter of a
maintainer having the need and the time to maintain that release. There
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RESEND v4 2/2] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
From: gengdongjiu @ 2018-06-17 1:30 UTC (permalink / raw)
To: James Morse
Cc: rkrcmar@redhat.com, corbet@lwn.net, christoffer.dall@arm.com,
marc.zyngier@arm.com, linux@armlinux.org.uk,
catalin.marinas@arm.com, will.deacon@arm.com, kvm@vger.kernel.org,
linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
> >>>>> --- a/arch/arm/include/uapi/asm/kvm.h
> >>>>> +++ b/arch/arm/include/uapi/asm/kvm.h
> >>>>> @@ -124,6 +124,18 @@ struct kvm_sync_regs { struct
> >>>>> kvm_arch_memory_slot { };
> >>>>>
> >>>>> +/* for KVM_GET/SET_VCPU_EVENTS */ struct kvm_vcpu_events {
> >>>>> + struct {
> >>>>> + __u8 serror_pending;
> >>>>> + __u8 serror_has_esr;
> >>>>> + /* Align it to 8 bytes */
> >>>>> + __u8 pad[6];
> >>>>> + __u64 serror_esr;
> >>>>> + } exception;
> >>>>> + __u32 reserved[12];
> >>>>> +};
> >>>>> +
> >>>>
> >>>> You haven't defined __KVM_HAVE_VCPU_EVENTS for 32bit, so presumably
> >>>> this struct will never be used. Why is it here?
> >>
> >>> if not add it for 32 bits. the 32 arm platform will build Fail, whether you have good
> >>> idea to avoid this Failure if not add this struct for the 32 bit?
> >>
> >> How does this 32bit code build without this patch?
> >> If do you provide the struct, how will that code build with older headers?
> >>
> >> As far as I can see, this is what the __KVM_HAVE_VCPU_EVENTS define is for.
> >>
> >> This should be both, or neither. Having just the struct is useless.
> > It because the caller of kvm_arm_vcpu_get/set_events() is in "virt/kvm/arm/arm.c".
> > the virt/kvm/arm/arm.c will used by both arm64 and arm.
> > so It needs to add kvm_arm_vcpu_get/set_events() for the 32 bits,
> > however, kvm_arm_vcpu_get/set_events() will directly return,
>
> So you are adding a uapi struct that user-space can't actually use, to avoid a kernel build-error. Fine, it just looks really strange.
>
> 32bit user-space shouldn't try to call this as check-extension reports it as not present. If it does, it gets -EINVAL back, which is also the
> default for kvm_arch_vcpu_ioctl().
It indeed looks strange. Because "virt/kvm/arm/arm.c" is shared by arm64 and arm32, if not adding, it will build-error. Do you have a better idea to avoid adding in arm32?
I still not think out a good method. 32 user-space will not call this KVM_GET/SET_VCPU_EVENTS IOCTL as check-extension reports it as not present.
>
>
> Thanks,
>
> James
^ permalink raw reply
* [PATCH] net: fix e100.rst Documentation build errors
From: Randy Dunlap @ 2018-06-17 0:36 UTC (permalink / raw)
To: linux-doc@vger.kernel.org, netdev@vger.kernel.org, Jeff Kirsher,
David Miller
Cc: LKML, Aaron Brown
From: Randy Dunlap <rdunlap@infradead.org>
Fix Documentation build errors in e100.rst. Several section titles
and the corresponding underlines should not be indented.
Documentation/networking/e100.rst:90: (SEVERE/4) Unexpected section title.
Documentation/networking/e100.rst:109: (SEVERE/4) Unexpected section title.
Fixes: 85d63445f411 ("Documentation: e100: Update the Intel 10/100 driver doc")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Aaron Brown <aaron.f.brown@intel.com>
---
Is there a Sphinx version problem here? Tested-by: should indicate
that there was no error like I am seeing.
Documentation/networking/e100.rst | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
--- lnx-418-rc1.orig/Documentation/networking/e100.rst
+++ lnx-418-rc1/Documentation/networking/e100.rst
@@ -86,8 +86,8 @@ Event Log Message Level: The driver use
Additional Configurations
=========================
- Configuring the Driver on Different Distributions
- -------------------------------------------------
+Configuring the Driver on Different Distributions
+-------------------------------------------------
Configuring a network driver to load properly when the system is started is
distribution dependent. Typically, the configuration process involves adding
@@ -105,8 +105,8 @@ Additional Configurations
alias eth0 e100
alias eth1 e100
- Viewing Link Messages
- ---------------------
+Viewing Link Messages
+---------------------
In order to see link messages and other Intel driver information on your
console, you must set the dmesg level up to six. This can be done by
entering the following on the command line before loading the e100 driver::
@@ -119,8 +119,8 @@ Additional Configurations
NOTE: This setting is not saved across reboots.
- ethtool
- -------
+ethtool
+-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The ethtool
@@ -129,8 +129,8 @@ Additional Configurations
The latest release of ethtool can be found from
https://www.kernel.org/pub/software/network/ethtool/
- Enabling Wake on LAN* (WoL)
- ---------------------------
+Enabling Wake on LAN* (WoL)
+---------------------------
WoL is provided through the ethtool* utility. For instructions on enabling
WoL with ethtool, refer to the ethtool man page.
@@ -138,16 +138,16 @@ Additional Configurations
this driver version, in order to enable WoL, the e100 driver must be
loaded when shutting down or rebooting the system.
- NAPI
- ----
+NAPI
+----
NAPI (Rx polling mode) is supported in the e100 driver.
See https://wiki.linuxfoundation.org/networking/napi for more information
on NAPI.
- Multiple Interfaces on Same Ethernet Broadcast Network
- ------------------------------------------------------
+Multiple Interfaces on Same Ethernet Broadcast Network
+------------------------------------------------------
Due to the default ARP behavior on Linux, it is not possible to have
one system on two IP networks in the same Ethernet broadcast domain
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] net: fix e1000.rst Documentation build errors
From: Randy Dunlap @ 2018-06-17 0:36 UTC (permalink / raw)
To: netdev@vger.kernel.org, David Miller, linux-doc@vger.kernel.org
Cc: LKML, Jeff Kirsher, aaron.f.brown
From: Randy Dunlap <rdunlap@infradead.org>
Fix Documentation build errors in e1000.rst. Several section titles and
their underlines should not be indented.
Documentation/networking/e1000.rst:358: (SEVERE/4) Unexpected section title.
Fixes: 228046e76189 ("Documentation: e1000: Update kernel documentation")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Aaron Brown <aaron.f.brown@intel.com>
---
Is there a Sphinx version problem here? Tested-by: should indicate
that there was no error like I am seeing.
Documentation/networking/e1000.rst | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- lnx-418-rc1.orig/Documentation/networking/e1000.rst
+++ lnx-418-rc1/Documentation/networking/e1000.rst
@@ -354,8 +354,8 @@ previously mentioned to force the adapte
Additional Configurations
=========================
- Jumbo Frames
- ------------
+Jumbo Frames
+------------
Jumbo Frames support is enabled by changing the MTU to a value larger than
the default of 1500. Use the ifconfig command to increase the MTU size.
For example::
@@ -389,8 +389,8 @@ Additional Configurations
Intel(R) PRO/1000 Gigabit Server Adapter
Intel(R) PRO/1000 PM Network Connection
- ethtool
- -------
+ethtool
+-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The ethtool
version 1.6 or later is required for this functionality.
@@ -398,8 +398,8 @@ Additional Configurations
The latest release of ethtool can be found from
https://www.kernel.org/pub/software/network/ethtool/
- Enabling Wake on LAN* (WoL)
- ---------------------------
+Enabling Wake on LAN* (WoL)
+---------------------------
WoL is configured through the ethtool* utility.
WoL will be enabled on the system during the next shut down or reboot.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] v4.18-rc1: fix Documentation build due to rename of main.c to mtrr.c
From: Randy Dunlap @ 2018-06-17 0:09 UTC (permalink / raw)
To: LKML, Linus Torvalds, linux-doc@vger.kernel.org, Jonathan Corbet
Cc: Ingo Molnar
From: Randy Dunlap <rdunlap@infradead.org>
Fixes this documentation build error that is due to a file rename:
Error: Cannot open file ../arch/x86/kernel/cpu/mtrr/main.c
Fixes 0afe832e55a7:
("Merge branch 'x86-cleanups-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")
Merge: 42964c6f6261 844ea8f62619
Pull x86 cleanups from Ingo Molnar:
"Misc cleanups"
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
How do you want the Fixes: info formatted?
Documentation/core-api/kernel-api.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- lnx-418-rc1.orig/Documentation/core-api/kernel-api.rst
+++ lnx-418-rc1/Documentation/core-api/kernel-api.rst
@@ -284,7 +284,7 @@ Resources Management
MTRR Handling
-------------
-.. kernel-doc:: arch/x86/kernel/cpu/mtrr/main.c
+.. kernel-doc:: arch/x86/kernel/cpu/mtrr/mtrr.c
:export:
Security Framework
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 0/5] FireWire: clean up kernel-doc, add Documentation chapter
From: Randy Dunlap @ 2018-06-16 23:55 UTC (permalink / raw)
To: Takashi Sakamoto, Randy Dunlap, linux1394-devel; +Cc: Stefan Richter, linux-doc
In-Reply-To: <52b34674-f1bd-311f-8bc4-9eb0ceb88c97@sakamocchi.jp>
On 04/15/2018 07:10 PM, Takashi Sakamoto wrote:
> Hi,
>
> On Apr 14 2018 10:27, Randy Dunlap wrote:
>> This patch series cleans up kernel-doc warnings in several
>> FireWire source files and then adds a Documentation driver-api
>> chapter for FireWire.
>>
>> [PATCH v3 1/5] FireWire: clean up firewire-cdev.h kernel-doc
>> [PATCH v3 2/5] FireWire: clean up core-iso.c kernel-doc
>> [PATCH v3 3/5] FireWire: clean up core-transaction.c kernel-doc
>> [PATCH v3 4/5] FireWire: add a Documentation driver-api chapter
>> [PATCH v3 5/5] FireWire: add driver-api Introduction section
>>
>> Documentation/driver-api/firewire.rst | 50 +++++++++++++++++++++++-
>> Documentation/driver-api/index.rst | 1
>> drivers/firewire/core-iso.c | 7 +++
>> drivers/firewire/core-transaction.c | 10 ++++
>> include/uapi/linux/firewire-cdev.h | 22 ++++++----
>> 5 files changed, 81 insertions(+), 9 deletions(-)
>
> I reviewed all of the five patches.
>
> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
>
> We're on development cycle for v4.18. Your patchset will be merged into
> mainline in next merge window by pull request from Stefan.
Stefan, are you around?
The merge window for v4.18 just closed today.
thanks,
--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 26/26] fix a series of Documentation/ broken file name references
From: Rafael J. Wysocki @ 2018-06-16 15:52 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Jonathan Corbet, Mauro Carvalho Chehab,
Linux Kernel Mailing List, Harry Wei, Vinod Koul, Dan Williams,
Darren Hart, Andy Shevchenko, David S. Miller,
Luis de Bethencourt, Salah Triki, Mike Marshall,
Martin Brandenburg, Rafael J. Wysocki, Pavel Machek, Len Brown,
linux-kernel, dmaengine, Platform Driver, sparclinux, devel,
Linux PM
In-Reply-To: <041e7a803fc0e5c5dfc1fb8b2f761074ca0baa2c.1529079120.git.mchehab+samsung@kernel.org>
On Fri, Jun 15, 2018 at 6:30 PM, Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
> As files move around, their previous links break. Fix the
> references for them.
>
> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/translations/zh_CN/io_ordering.txt | 2 +-
> drivers/dma/dmaengine.c | 2 +-
> drivers/platform/x86/Kconfig | 2 +-
> drivers/sbus/char/oradax.c | 2 +-
> fs/befs/ChangeLog | 2 +-
> fs/orangefs/orangefs-sysfs.c | 2 +-
> include/linux/platform_data/sc18is602.h | 2 +-
> kernel/power/main.c | 5 +++--
> 8 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/translations/zh_CN/io_ordering.txt b/Documentation/translations/zh_CN/io_ordering.txt
> index e592daf4e014..1f8127bdd415 100644
> --- a/Documentation/translations/zh_CN/io_ordering.txt
> +++ b/Documentation/translations/zh_CN/io_ordering.txt
> @@ -1,4 +1,4 @@
> -Chinese translated version of Documentation/io_orderings.txt
> +Chinese translated version of Documentation/io_ordering.txt
>
> If you have any comment or update to the content, please contact the
> original document maintainer directly. However, if you have a problem
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index b451354735d3..08ba8473a284 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -38,7 +38,7 @@
> * Each device has a channels list, which runs unlocked but is never modified
> * once the device is registered, it's just setup by the driver.
> *
> - * See Documentation/dmaengine.txt for more details
> + * See Documentation/driver-api/dmaengine for more details
> */
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index f27cb186437d..ac4d48830415 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -1052,7 +1052,7 @@ config SAMSUNG_LAPTOP
> function keys, wireless LED, LCD backlight level.
>
> It may also provide some sysfs files described in
> - <file:Documentation/ABI/testing/sysfs-platform-samsung-laptop>
> + <file:Documentation/ABI/testing/sysfs-driver-samsung-laptop>
>
> To compile this driver as a module, choose M here: the module
> will be called samsung-laptop.
> diff --git a/drivers/sbus/char/oradax.c b/drivers/sbus/char/oradax.c
> index 1754f55e2fac..524f9ea62e52 100644
> --- a/drivers/sbus/char/oradax.c
> +++ b/drivers/sbus/char/oradax.c
> @@ -30,7 +30,7 @@
> * the recommended way for applications to use the coprocessor, and
> * the driver interface is not intended for general use.
> *
> - * See Documentation/sparc/oradax/oracle_dax.txt for more details.
> + * See Documentation/sparc/oradax/oracle-dax.txt for more details.
> */
>
> #include <linux/uaccess.h>
> diff --git a/fs/befs/ChangeLog b/fs/befs/ChangeLog
> index 16f2dfe8c2f7..aff7eec8f327 100644
> --- a/fs/befs/ChangeLog
> +++ b/fs/befs/ChangeLog
> @@ -389,7 +389,7 @@ Version 0.4 (2001-10-28)
> (fs/nls/Config.in)
>
> * Added Configure.help entries for CONFIG_BEFS_FS and CONFIG_DEBUG_BEFS
> - (Documentation/Configure.help)
> + (currently at fs/befs/Kconfig)
>
> 2001-08-??
> ==========
> diff --git a/fs/orangefs/orangefs-sysfs.c b/fs/orangefs/orangefs-sysfs.c
> index 079a465796f3..dd28079f518c 100644
> --- a/fs/orangefs/orangefs-sysfs.c
> +++ b/fs/orangefs/orangefs-sysfs.c
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0
> /*
> - * Documentation/ABI/stable/orangefs-sysfs:
> + * Documentation/ABI/stable/sysfs-fs-orangefs:
> *
> * What: /sys/fs/orangefs/perf_counter_reset
> * Date: June 2015
> diff --git a/include/linux/platform_data/sc18is602.h b/include/linux/platform_data/sc18is602.h
> index 997b06634152..18602cab7799 100644
> --- a/include/linux/platform_data/sc18is602.h
> +++ b/include/linux/platform_data/sc18is602.h
> @@ -7,7 +7,7 @@
> * it under the terms of the GNU General Public License version 2 as
> * published by the Free Software Foundation.
> *
> - * For further information, see the Documentation/spi/sc18is602 file.
> + * For further information, see the Documentation/spi/spi-sc18is602 file.
> */
>
> /**
> diff --git a/kernel/power/main.c b/kernel/power/main.c
> index 705c2366dafe..d9706da10930 100644
> --- a/kernel/power/main.c
> +++ b/kernel/power/main.c
> @@ -455,8 +455,9 @@ struct kobject *power_kobj;
> * state - control system sleep states.
> *
> * show() returns available sleep state labels, which may be "mem", "standby",
> - * "freeze" and "disk" (hibernation). See Documentation/power/states.txt for a
> - * description of what they mean.
> + * "freeze" and "disk" (hibernation).
> + * See Documentation/admin-guide/pm/sleep-states.rst for a description of
> + * what they mean.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
for the PM part above.
> *
> * store() accepts one of those strings, translates it into the proper
> * enumerated value, and initiates a suspend transition.
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/7] Uprobes: Support SDT markers having reference count (semaphore)
From: Ravi Bangoria @ 2018-06-16 15:07 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: oleg, srikar, rostedt, peterz, mingo, acme, alexander.shishkin,
jolsa, namhyung, linux-kernel, corbet, linux-doc, ananth,
alexis.berlemont, naveen.n.rao, Ravi Bangoria
In-Reply-To: <20180616225032.3fc9a027dca76926ff198ff8@kernel.org>
Hi Masami,
On 06/16/2018 07:20 PM, Masami Hiramatsu wrote:
> Hi Ravi,
>
> Sorry for replying later.
No issues :)
>
> On Mon, 11 Jun 2018 10:01:58 +0530
> Ravi Bangoria <ravi.bangoria@linux.ibm.com> wrote:
>
>> Hi Masami,
>>
>>>>> Hmm, it sounds simple... maybe we can increment refctr in install_breakpoint/
>>>>> remove_breakpoint?
>>>>
>>>> Not really, it would be simpler if I can put it inside install_breakpoint().
>>>> Consider an mmap() case. Probed instruction resides in the text section whereas
>>>> reference counter resides in the data section. These sections gets mapped using
>>>> separate mmap() calls. So, when process mmaps the text section we will change the
>>>> instruction, but section holding the reference counter may not have been mapped
>>>> yet in the virtual memory. If so, we will fail to update the reference counter.
>>>
>>> Got it.
>>> In such case, maybe we can hook the target page mmapped and do install_breakpoint()
>>> at that point. Since the instruction is protected by a refctr, unless mmap the
>>> page on where the refctr is, the program doesn't reach the tracepoint. Is that right?
>>>
>>
>> You mean, when mmap(text) happens, save the target page somewhere and when
>> mmap(data) happens, update both instruction and ref_ctr?
>
> Yes. I think you can just clone the target(text) page but not install
> breakpoint, and if mmap(data) happens, update both.
I'm preparing a prototype according to this. The only difference in my approach is,
I'm not delaying instruction update. I.e. let instruction update happen as it is,
just mark that uprobe as delayed. Whenever vma holding reference counter gets mapped,
update the reference counter.
Will post the series soon.
Thanks for the reply,
Ravi
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/7] Uprobes: Support SDT markers having reference count (semaphore)
From: Masami Hiramatsu @ 2018-06-16 13:50 UTC (permalink / raw)
To: Ravi Bangoria
Cc: oleg, srikar, rostedt, peterz, mingo, acme, alexander.shishkin,
jolsa, namhyung, linux-kernel, corbet, linux-doc, ananth,
alexis.berlemont, naveen.n.rao
In-Reply-To: <6225481e-fa00-a242-2b57-223559e3c488@linux.ibm.com>
Hi Ravi,
Sorry for replying later.
On Mon, 11 Jun 2018 10:01:58 +0530
Ravi Bangoria <ravi.bangoria@linux.ibm.com> wrote:
> Hi Masami,
>
> >>> Hmm, it sounds simple... maybe we can increment refctr in install_breakpoint/
> >>> remove_breakpoint?
> >>
> >> Not really, it would be simpler if I can put it inside install_breakpoint().
> >> Consider an mmap() case. Probed instruction resides in the text section whereas
> >> reference counter resides in the data section. These sections gets mapped using
> >> separate mmap() calls. So, when process mmaps the text section we will change the
> >> instruction, but section holding the reference counter may not have been mapped
> >> yet in the virtual memory. If so, we will fail to update the reference counter.
> >
> > Got it.
> > In such case, maybe we can hook the target page mmapped and do install_breakpoint()
> > at that point. Since the instruction is protected by a refctr, unless mmap the
> > page on where the refctr is, the program doesn't reach the tracepoint. Is that right?
> >
>
> You mean, when mmap(text) happens, save the target page somewhere and when
> mmap(data) happens, update both instruction and ref_ctr?
Yes. I think you can just clone the target(text) page but not install
breakpoint, and if mmap(data) happens, update both.
>
> This sounds feasible. Let me think on it.
Thanks!
>
> Thanks for suggestion,
> Ravi
>
--
Masami Hiramatsu <mhiramat@kernel.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] tracing: Fix some errors in histogram documentation
From: Masami Hiramatsu @ 2018-06-16 9:48 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, kernel-team, Joel Fernandes (Google), Changbin Du,
Ingo Molnar, Jonathan Corbet, linux-doc, Steven Rostedt,
Tom Zanussi, bigeasy, mhiramat, tglx, namhyung, vedang.patel,
mathieu.desnoyers, julia, linux-rt-users
In-Reply-To: <20180614224859.55864-1-joel@joelfernandes.org>
On Thu, 14 Jun 2018 15:48:59 -0700
Joel Fernandes <joelaf@google.com> wrote:
> From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
>
> Fix typos, inconsistencies in using quotes, incorrect section number,
> etc. in the trace histogram documentation.
Looks good to me.
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Thanks!
>
> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> ---
> Documentation/trace/histogram.txt | 23 ++++++++++++-----------
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/trace/histogram.txt b/Documentation/trace/histogram.txt
> index 6e05510afc28..da955cd696f6 100644
> --- a/Documentation/trace/histogram.txt
> +++ b/Documentation/trace/histogram.txt
> @@ -1730,35 +1730,35 @@ If a variable isn't a key variable or prefixed with 'vals=', the
> associated event field will be saved in a variable but won't be summed
> as a value:
>
> - # echo 'hist:keys=next_pid:ts1=common_timestamp ... >> event/trigger
> + # echo 'hist:keys=next_pid:ts1=common_timestamp ...' >> event/trigger
>
> Multiple variables can be assigned at the same time. The below would
> result in both ts0 and b being created as variables, with both
> common_timestamp and field1 additionally being summed as values:
>
> - # echo 'hist:keys=pid:vals=$ts0,$b:ts0=common_timestamp,b=field1 ... >> \
> + # echo 'hist:keys=pid:vals=$ts0,$b:ts0=common_timestamp,b=field1 ...' >> \
> event/trigger
>
> Note that variable assignments can appear either preceding or
> following their use. The command below behaves identically to the
> command above:
>
> - # echo 'hist:keys=pid:ts0=common_timestamp,b=field1:vals=$ts0,$b ... >> \
> + # echo 'hist:keys=pid:ts0=common_timestamp,b=field1:vals=$ts0,$b ...' >> \
> event/trigger
>
> Any number of variables not bound to a 'vals=' prefix can also be
> assigned by simply separating them with colons. Below is the same
> thing but without the values being summed in the histogram:
>
> - # echo 'hist:keys=pid:ts0=common_timestamp:b=field1 ... >> event/trigger
> + # echo 'hist:keys=pid:ts0=common_timestamp:b=field1 ...' >> event/trigger
>
> Variables set as above can be referenced and used in expressions on
> another event.
>
> For example, here's how a latency can be calculated:
>
> - # echo 'hist:keys=pid,prio:ts0=common_timestamp ... >> event1/trigger
> - # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp-$ts0 ... >> event2/trigger
> + # echo 'hist:keys=pid,prio:ts0=common_timestamp ...' >> event1/trigger
> + # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp-$ts0 ...' >> event2/trigger
>
> In the first line above, the event's timetamp is saved into the
> variable ts0. In the next line, ts0 is subtracted from the second
> @@ -1767,7 +1767,7 @@ yet another variable, 'wakeup_lat'. The hist trigger below in turn
> makes use of the wakeup_lat variable to compute a combined latency
> using the same key and variable from yet another event:
>
> - # echo 'hist:key=pid:wakeupswitch_lat=$wakeup_lat+$switchtime_lat ... >> event3/trigger
> + # echo 'hist:key=pid:wakeupswitch_lat=$wakeup_lat+$switchtime_lat ...' >> event3/trigger
>
> 2.2.2 Synthetic Events
> ----------------------
> @@ -1808,10 +1808,11 @@ the command that defined it with a '!':
> At this point, there isn't yet an actual 'wakeup_latency' event
> instantiated in the event subsytem - for this to happen, a 'hist
> trigger action' needs to be instantiated and bound to actual fields
> -and variables defined on other events (see Section 6.3.3 below).
> +and variables defined on other events (see Section 2.2.3 below on
> +how that is done using hist trigger 'onmatch' action). Once that is
> +done, the 'wakeup_latency' synthetic event instance is created.
>
> -Once that is done, an event instance is created, and a histogram can
> -be defined using it:
> +A histogram can now be defined for the new synthetic event:
>
> # echo 'hist:keys=pid,prio,lat.log2:sort=pid,lat' >> \
> /sys/kernel/debug/tracing/events/synthetic/wakeup_latency/trigger
> @@ -1961,7 +1962,7 @@ hist trigger specification.
> back to that pid, the timestamp difference is calculated. If the
> resulting latency, stored in wakeup_lat, exceeds the current
> maximum latency, the values specified in the save() fields are
> - recoreded:
> + recorded:
>
> # echo 'hist:keys=pid:ts0=common_timestamp.usecs \
> if comm=="cyclictest"' >> \
> --
> 2.18.0.rc1.242.g61856ae69a-goog
>
--
Masami Hiramatsu <mhiramat@kernel.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 19/26] MAINTAINERS: fix location of some display DT bindings
From: Eric Anholt @ 2018-06-15 23:38 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List, Jonathan Corbet
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
David Airlie, David Lechner, Martin Donnelly, Martyn Welch,
Stefan Agner, Alison Wang, Peter Senna Tschudin
In-Reply-To: <5fd5928906086e37cdf8740296ee9766c85ee78f.1529079120.git.mchehab+samsung@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 312 bytes --]
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> writes:
> Those files got a manufacturer's name prepended and were moved around.
> Adjust their references accordingly.
>
> Also, due those movements, Documentation/devicetree/bindings/video
> doesn't exist anymore.
Reviewed-by: Eric Anholt <eric@anholt.net>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH v3 16/27] docs: Fix more broken references
From: Stephen Boyd @ 2018-06-15 21:42 UTC (permalink / raw)
To: Linux Doc Mailing List, Mauro Carvalho Chehab
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, linux-clk, devicetree, linux-pm, dri-devel,
linux-arm-kernel, linux-mmc, linux-samsung-soc, netdev, linux-usb,
linux-rockchip, linux-hwmon, intel-wired-lan, alsa-devel,
linux-fsdevel, linux-mediatek
In-Reply-To: <e1bf52a721005b2017434acc54ec5ddc152d6fe4.1528990947.git.mchehab+samsung@kernel.org>
Quoting Mauro Carvalho Chehab (2018-06-14 09:09:01)
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix
>
> Manually checked that produced results are valid.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> .../devicetree/bindings/clock/st/st,clkgen.txt | 8 ++++----
> .../devicetree/bindings/clock/ti/gate.txt | 2 +-
> .../devicetree/bindings/clock/ti/interface.txt | 2 +-
Acked-by: Stephen Boyd <sboyd@kernel.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [GIT PULL for v4.18-rc1] fix broken links for Documentation/* files
From: Mauro Carvalho Chehab @ 2018-06-15 21:29 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, Linux Kernel Mailing List, Jonathan Corbet,
Linux Doc Mailing List
Hi Linus,
Exceptionally, I'm sending you a pull request mainly related to
documentation. Jonathan requested me to send those directly to you
as he's "fighting a few real-world complications at the moment,
and barely have time to breathe...".
So, please pull from:
git://linuxtv.org/mchehab/experimental.git tags/docs-broken-links
It solves a series of broken links for files under Documentation,
and improves a script meant to detect such broken links
(scripts/documentation-file-ref-check).
The changes on this series are:
- can.rst: fix a footnote reference;
- crypto_engine.rst: Fix two parsing warnings;
- Fix a lot of broken references to Documentation/*;
- Improves the scripts/documentation-file-ref-check script,
in order to help detecting/fixing broken references,
preventing false-positives.
(I might have created a new branch or tree at kernel.org, but I'm
preparing to go to Japan next week, so, it sounded easier to just
point to the tree where I store my development stuff).
Thanks,
Mauro
The following changes since commit 4c5e8fc62d6a63065eeae80808c498d1dcfea4f4:
Merge tag 'linux-kselftest-4.18-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest (2018-06-15 17:26:29 +0900)
are available in the Git repository at:
git://linuxtv.org/mchehab/experimental.git tags/docs-broken-links
for you to fetch changes up to 44348e8ac145d78171c5a6f4a8bdb01b70969fc2:
fix a series of Documentation/ broken file name references (2018-06-15 18:10:01 -0300)
----------------------------------------------------------------
Solve a series of broken links for files under Documentation:
- can.rst: fix a footnote reference;
- crypto_engine.rst: Fix two parsing warnings;
- Fix a lot of broken references to Documentation/*;
- Improves the scripts/documentation-file-ref-check script,
in order to help detecting/fixing broken references,
preventing false-positives.
After this patch series, only 33 broken references to doc files are
detected by scripts/documentation-file-ref-check.
----------------------------------------------------------------
Mauro Carvalho Chehab (26):
docs: can.rst: fix a footnote reference
docs: crypto_engine.rst: Fix two parse warnings
arch/*: Kconfig: fix documentation for NMI watchdog
docs: fix broken references with multiple hints
docs: Fix some broken references
media: dvb: fix location of get_dvb_firmware script
media: dvb: point to the location of the old README.dvb-usb file
media: v4l: fix broken video4linux docs locations
media: max2175: fix location of driver's companion documentation
scripts/documentation-file-ref-check: fix help message
scripts/documentation-file-ref-check: accept more wildcards at filenames
scripts/documentation-file-ref-check: add a fix logic for DT
scripts/documentation-file-ref-check: hint: dash or underline
scripts/documentation-file-ref-check: get rid of false-positives
scripts/documentation-file-ref-check: check tools/*/Documentation
docs: Fix more broken references
bindings: nvmem/zii: Fix location of nvmem.txt
kernel-parameters.txt: fix pointers to sound parameters
MAINTAINERS: fix location of some display DT bindings
MAINTAINERS: fix location of DT npcm files
devicetree: fix some bindings file names
devicetree: fix name of pinctrl-bindings.txt
devicetree: fix a series of wrong file references
ABI: sysfs-devices-system-cpu: remove a broken reference
Documentation: rstFlatTable.py: fix a broken reference
fix a series of Documentation/ broken file name references
Documentation/ABI/obsolete/sysfs-gpio | 2 +-
Documentation/ABI/testing/sysfs-devices-system-cpu | 3 --
Documentation/admin-guide/kernel-parameters.txt | 9 ++--
Documentation/crypto/crypto_engine.rst | 8 +--
.../devicetree/bindings/clock/st/st,clkgen.txt | 8 +--
.../devicetree/bindings/clock/ti/gate.txt | 2 +-
.../devicetree/bindings/clock/ti/interface.txt | 2 +-
.../bindings/cpufreq/cpufreq-mediatek.txt | 2 +-
.../devicetree/bindings/devfreq/rk3399_dmc.txt | 2 +-
.../devicetree/bindings/display/bridge/tda998x.txt | 2 +-
.../devicetree/bindings/gpu/arm,mali-midgard.txt | 2 +-
.../devicetree/bindings/gpu/arm,mali-utgard.txt | 2 +-
.../bindings/input/rmi4/rmi_2d_sensor.txt | 2 +-
.../devicetree/bindings/input/rotary-encoder.txt | 2 +-
.../bindings/media/stih407-c8sectpfe.txt | 2 +-
Documentation/devicetree/bindings/mfd/as3722.txt | 2 +-
Documentation/devicetree/bindings/mfd/mt6397.txt | 2 +-
.../devicetree/bindings/mfd/sun6i-prcm.txt | 4 +-
.../devicetree/bindings/mmc/exynos-dw-mshc.txt | 2 +-
.../bindings/mmc/microchip,sdhci-pic32.txt | 2 +-
Documentation/devicetree/bindings/mmc/sdhci-st.txt | 2 +-
Documentation/devicetree/bindings/net/dsa/ksz.txt | 2 +-
.../devicetree/bindings/net/dsa/mt7530.txt | 2 +-
.../bindings/nvmem/zii,rave-sp-eeprom.txt | 2 +-
.../devicetree/bindings/pci/hisilicon-pcie.txt | 2 +-
.../devicetree/bindings/pci/kirin-pcie.txt | 2 +-
.../devicetree/bindings/pci/pci-keystone.txt | 4 +-
.../bindings/pinctrl/pinctrl-max77620.txt | 4 +-
.../bindings/pinctrl/pinctrl-mcp23s08.txt | 4 +-
.../devicetree/bindings/pinctrl/pinctrl-rk805.txt | 4 +-
.../devicetree/bindings/power/fsl,imx-gpc.txt | 2 +-
.../bindings/power/supply/ab8500/btemp.txt | 2 +-
.../bindings/power/supply/ab8500/chargalg.txt | 2 +-
.../bindings/power/supply/ab8500/charger.txt | 2 +-
.../devicetree/bindings/power/wakeup-source.txt | 2 +-
.../bindings/serial/microchip,pic32-uart.txt | 2 +-
.../devicetree/bindings/sound/st,stm32-i2s.txt | 2 +-
.../devicetree/bindings/sound/st,stm32-sai.txt | 2 +-
.../devicetree/bindings/spi/spi-st-ssc.txt | 2 +-
.../devicetree/bindings/usb/rockchip,dwc3.txt | 2 +-
Documentation/driver-api/gpio/consumer.rst | 2 +-
Documentation/hwmon/ina2xx | 2 +-
Documentation/kprobes.txt | 4 +-
Documentation/maintainer/pull-requests.rst | 2 +-
Documentation/networking/can.rst | 4 +-
Documentation/sphinx/rstFlatTable.py | 2 -
Documentation/trace/coresight.txt | 2 +-
Documentation/trace/events.rst | 2 +-
Documentation/trace/ftrace-uses.rst | 2 +-
Documentation/trace/histogram.txt | 2 +-
Documentation/trace/intel_th.rst | 2 +-
Documentation/trace/tracepoint-analysis.rst | 8 +--
Documentation/translations/ja_JP/howto.rst | 4 +-
Documentation/translations/ko_KR/howto.rst | 2 +-
Documentation/translations/zh_CN/SubmittingDrivers | 2 +-
Documentation/translations/zh_CN/gpio.txt | 4 +-
Documentation/translations/zh_CN/io_ordering.txt | 2 +-
Documentation/translations/zh_CN/magic-number.txt | 4 +-
.../translations/zh_CN/video4linux/omap3isp.txt | 4 +-
.../zh_CN/video4linux/v4l2-framework.txt | 6 +--
MAINTAINERS | 62 +++++++++++-----------
arch/Kconfig | 2 +-
arch/arm/Kconfig | 2 +-
arch/arm/include/asm/cacheflush.h | 2 +-
arch/arm64/include/asm/cacheflush.h | 2 +-
arch/microblaze/include/asm/cacheflush.h | 2 +-
arch/parisc/Kconfig | 2 +-
arch/sh/Kconfig | 2 +-
arch/sparc/Kconfig | 2 +-
arch/um/Kconfig.um | 2 +-
arch/unicore32/include/asm/cacheflush.h | 2 +-
arch/x86/entry/vsyscall/vsyscall_64.c | 2 +-
arch/xtensa/include/asm/cacheflush.h | 4 +-
block/Kconfig | 2 +-
certs/Kconfig | 2 +-
crypto/asymmetric_keys/asymmetric_type.c | 2 +-
crypto/asymmetric_keys/signature.c | 2 +-
drivers/char/Kconfig | 2 +-
drivers/clk/clk.c | 4 +-
drivers/clk/ingenic/cgu.h | 2 +-
drivers/dma/dmaengine.c | 2 +-
drivers/gpu/vga/Kconfig | 2 +-
drivers/gpu/vga/vgaarb.c | 2 +-
drivers/hid/usbhid/Kconfig | 2 +-
drivers/input/Kconfig | 4 +-
drivers/input/joystick/Kconfig | 14 ++---
drivers/input/joystick/iforce/Kconfig | 4 +-
drivers/input/joystick/walkera0701.c | 2 +-
drivers/input/misc/Kconfig | 4 +-
drivers/input/misc/rotary_encoder.c | 2 +-
drivers/input/mouse/Kconfig | 6 +--
drivers/input/mouse/alps.c | 2 +-
drivers/input/serio/Kconfig | 4 +-
drivers/input/touchscreen/wm97xx-core.c | 2 +-
drivers/lightnvm/pblk-rb.c | 2 +-
drivers/md/bcache/Kconfig | 2 +-
drivers/md/bcache/btree.c | 2 +-
drivers/md/bcache/extents.c | 2 +-
drivers/media/dvb-core/dvb_ringbuffer.c | 2 +-
drivers/media/dvb-frontends/Kconfig | 18 +++----
drivers/media/dvb-frontends/dib3000.h | 2 +-
drivers/media/dvb-frontends/dib3000mb.c | 2 +-
drivers/media/dvb-frontends/eds1547.h | 2 +-
drivers/media/dvb-frontends/nxt200x.c | 4 +-
drivers/media/dvb-frontends/or51211.c | 2 +-
drivers/media/dvb-frontends/sp8870.c | 2 +-
drivers/media/dvb-frontends/sp887x.c | 2 +-
drivers/media/dvb-frontends/tda1004x.c | 4 +-
drivers/media/dvb-frontends/tda10071.c | 2 +-
drivers/media/dvb-frontends/z0194a.h | 2 +-
drivers/media/i2c/max2175.c | 6 +--
drivers/media/pci/bt8xx/Kconfig | 2 +-
drivers/media/pci/cx18/cx18-dvb.c | 2 +-
drivers/media/pci/cx18/cx18-streams.c | 4 +-
drivers/media/pci/cx23885/cx23885-cards.c | 2 +-
drivers/media/pci/meye/Kconfig | 2 +-
drivers/media/pci/ttpci/Kconfig | 2 +-
drivers/media/platform/pxa_camera.c | 4 +-
.../platform/soc_camera/sh_mobile_ceu_camera.c | 2 +-
drivers/media/radio/Kconfig | 12 ++---
drivers/media/radio/si470x/Kconfig | 2 +-
drivers/media/radio/wl128x/Kconfig | 2 +-
drivers/media/usb/dvb-usb-v2/Kconfig | 2 +-
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 2 +-
drivers/media/usb/dvb-usb-v2/gl861.c | 2 +-
drivers/media/usb/dvb-usb-v2/lmedm04.c | 4 +-
drivers/media/usb/dvb-usb-v2/lmedm04.h | 2 +-
drivers/media/usb/dvb-usb-v2/mxl111sf.c | 2 +-
drivers/media/usb/dvb-usb-v2/mxl111sf.h | 2 +-
drivers/media/usb/dvb-usb/Kconfig | 2 +-
drivers/media/usb/dvb-usb/a800.c | 2 +-
drivers/media/usb/dvb-usb/af9005-fe.c | 2 +-
drivers/media/usb/dvb-usb/af9005-remote.c | 2 +-
drivers/media/usb/dvb-usb/af9005.c | 2 +-
drivers/media/usb/dvb-usb/af9005.h | 2 +-
drivers/media/usb/dvb-usb/az6027.c | 2 +-
drivers/media/usb/dvb-usb/cxusb.c | 2 +-
drivers/media/usb/dvb-usb/dibusb-common.c | 2 +-
drivers/media/usb/dvb-usb/dibusb-mb.c | 2 +-
drivers/media/usb/dvb-usb/dibusb-mc-common.c | 2 +-
drivers/media/usb/dvb-usb/dibusb-mc.c | 2 +-
drivers/media/usb/dvb-usb/dibusb.h | 2 +-
drivers/media/usb/dvb-usb/digitv.c | 2 +-
drivers/media/usb/dvb-usb/dtt200u-fe.c | 2 +-
drivers/media/usb/dvb-usb/dtt200u.c | 2 +-
drivers/media/usb/dvb-usb/dtt200u.h | 2 +-
drivers/media/usb/dvb-usb/dvb-usb-firmware.c | 2 +-
drivers/media/usb/dvb-usb/dvb-usb-init.c | 2 +-
drivers/media/usb/dvb-usb/dw2102.c | 6 +--
drivers/media/usb/dvb-usb/friio-fe.c | 2 +-
drivers/media/usb/dvb-usb/friio.c | 2 +-
drivers/media/usb/dvb-usb/friio.h | 2 +-
drivers/media/usb/dvb-usb/gp8psk.c | 4 +-
drivers/media/usb/dvb-usb/gp8psk.h | 2 +-
drivers/media/usb/dvb-usb/m920x.c | 2 +-
drivers/media/usb/dvb-usb/nova-t-usb2.c | 2 +-
drivers/media/usb/dvb-usb/opera1.c | 4 +-
drivers/media/usb/dvb-usb/ttusb2.c | 2 +-
drivers/media/usb/dvb-usb/ttusb2.h | 2 +-
drivers/media/usb/dvb-usb/umt-010.c | 2 +-
drivers/media/usb/dvb-usb/vp702x-fe.c | 2 +-
drivers/media/usb/dvb-usb/vp702x.c | 2 +-
drivers/media/usb/dvb-usb/vp7045-fe.c | 2 +-
drivers/media/usb/dvb-usb/vp7045.c | 2 +-
drivers/media/usb/dvb-usb/vp7045.h | 2 +-
drivers/media/usb/gspca/m5602/Kconfig | 2 -
drivers/media/usb/ttusb-dec/Kconfig | 6 +--
drivers/media/usb/zr364xx/Kconfig | 2 +-
drivers/net/ethernet/intel/Kconfig | 8 +--
drivers/parport/Kconfig | 6 +--
drivers/platform/x86/Kconfig | 2 +-
drivers/sbus/char/oradax.c | 2 +-
drivers/soundwire/stream.c | 8 +--
drivers/staging/fsl-mc/bus/dpio/dpio-driver.txt | 2 +-
drivers/staging/media/bcm2048/TODO | 2 +-
drivers/staging/media/zoran/Kconfig | 2 +-
drivers/video/fbdev/skeletonfb.c | 8 +--
fs/Kconfig.binfmt | 2 +-
fs/befs/ChangeLog | 2 +-
fs/binfmt_misc.c | 2 +-
fs/orangefs/orangefs-sysfs.c | 2 +-
include/keys/asymmetric-subtype.h | 2 +-
include/keys/asymmetric-type.h | 2 +-
include/linux/assoc_array.h | 2 +-
include/linux/assoc_array_priv.h | 2 +-
include/linux/circ_buf.h | 2 +-
include/linux/ftrace.h | 2 +-
include/linux/platform_data/sc18is602.h | 2 +-
include/linux/rculist_nulls.h | 2 +-
include/linux/tracepoint.h | 2 +-
include/uapi/linux/prctl.h | 2 +-
include/xen/interface/io/kbdif.h | 2 +-
kernel/cgroup/cpuset.c | 2 +-
kernel/power/main.c | 5 +-
kernel/trace/Kconfig | 16 +++---
lib/Kconfig | 2 +-
scripts/documentation-file-ref-check | 56 ++++++++++++++++---
security/device_cgroup.c | 2 +-
security/selinux/hooks.c | 2 +-
sound/core/Kconfig | 4 +-
sound/drivers/Kconfig | 4 +-
sound/pci/Kconfig | 10 ++--
tools/include/uapi/linux/prctl.h | 2 +-
tools/lib/api/fs/fs.c | 2 +-
tools/perf/util/bpf-prologue.c | 2 +-
.../pm-graph/config/custom-timeline-functions.cfg | 4 +-
206 files changed, 372 insertions(+), 339 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 00/26] Fix some doc build warnings/errors and broken links
From: Mauro Carvalho Chehab @ 2018-06-15 20:52 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Matthias Brugger, linux-arm-kernel, linux-mediatek
In-Reply-To: <20180615130951.303a3ebb@lwn.net>
Em Fri, 15 Jun 2018 13:09:51 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Fri, 15 Jun 2018 13:30:28 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > As discussed during the review of v2, your plans were to merge
> > things with potential to conflict with merges by the end of the
> > merge window. So, I'm resubmitting it in order to help you with
> > that.
>
> Is there any chance you could send them directly Linusward with my ack?
> I'm fighting a few real-world complications at the moment, and barely
> have time to breathe...
Ok, I'll send him a pull request (likely tomorrow), adding your
ack on the patches at this series.
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox