* [PATCH RFC 1/5] powerpc: Use regular rcu_dereference_raw API
From: Joel Fernandes (Google) @ 2019-05-24 23:49 UTC (permalink / raw)
To: linux-kernel
Cc: rcu, Jonathan Corbet, linux-doc, Lai Jiangshan, Josh Triplett,
kvm-ppc, Miguel Ojeda, Ingo Molnar, Mathieu Desnoyers,
Steven Rostedt, Joel Fernandes (Google), Paul E. McKenney,
linuxppc-dev
In-Reply-To: <20190524234933.5133-1-joel@joelfernandes.org>
rcu_dereference_raw already does not do any tracing. There is no need to
use the _notrace variant of it and this series removes that API, so let us
use the regular variant here.
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
---
arch/powerpc/include/asm/kvm_book3s_64.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h b/arch/powerpc/include/asm/kvm_book3s_64.h
index 21b1ed5df888..c15c9bbf0206 100644
--- a/arch/powerpc/include/asm/kvm_book3s_64.h
+++ b/arch/powerpc/include/asm/kvm_book3s_64.h
@@ -546,7 +546,7 @@ static inline void note_hpte_modification(struct kvm *kvm,
*/
static inline struct kvm_memslots *kvm_memslots_raw(struct kvm *kvm)
{
- return rcu_dereference_raw_notrace(kvm->memslots[0]);
+ return rcu_dereference_raw(kvm->memslots[0]);
}
extern void kvmppc_mmu_debugfs_init(struct kvm *kvm);
--
2.22.0.rc1.257.g3120a18244-goog
^ permalink raw reply related
* [PATCH RFC 0/5] Remove some notrace RCU APIs
From: Joel Fernandes (Google) @ 2019-05-24 23:49 UTC (permalink / raw)
To: linux-kernel
Cc: rcu, Jonathan Corbet, linux-doc, Lai Jiangshan, Josh Triplett,
kvm-ppc, Miguel Ojeda, Ingo Molnar, Mathieu Desnoyers,
Steven Rostedt, Joel Fernandes (Google), Paul E. McKenney,
linuxppc-dev
The series removes users of the following APIs, and the APIs themselves, since
the regular non - _notrace variants don't do any tracing anyway.
* hlist_for_each_entry_rcu_notrace
* rcu_dereference_raw_notrace
Joel Fernandes (Google) (5):
powerpc: Use regular rcu_dereference_raw API
trace: Use regular rcu_dereference_raw API
hashtable: Use the regular hlist_for_each_entry_rcu API
rculist: Remove hlist_for_each_entry_rcu_notrace since no users
rcu: Remove rcu_dereference_raw_notrace since no users
.clang-format | 1 -
.../RCU/Design/Requirements/Requirements.html | 6 +++---
arch/powerpc/include/asm/kvm_book3s_64.h | 2 +-
include/linux/hashtable.h | 2 +-
include/linux/rculist.h | 20 -------------------
include/linux/rcupdate.h | 9 ---------
kernel/trace/ftrace.c | 4 ++--
kernel/trace/ftrace_internal.h | 8 ++++----
kernel/trace/trace.c | 4 ++--
9 files changed, 13 insertions(+), 43 deletions(-)
--
2.22.0.rc1.257.g3120a18244-goog
^ permalink raw reply
* [PATCH RFC 2/5] trace: Use regular rcu_dereference_raw API
From: Joel Fernandes (Google) @ 2019-05-24 23:49 UTC (permalink / raw)
To: linux-kernel
Cc: rcu, Jonathan Corbet, linux-doc, Lai Jiangshan, Josh Triplett,
kvm-ppc, Miguel Ojeda, Ingo Molnar, Mathieu Desnoyers,
Steven Rostedt, Joel Fernandes (Google), Paul E. McKenney,
linuxppc-dev
In-Reply-To: <20190524234933.5133-1-joel@joelfernandes.org>
rcu_dereference_raw already does not do any tracing. There is no need to
use the _notrace variant of it and this series removes that API, so let us
use the regular variant here.
While at it, also replace the only user of
hlist_for_each_entry_rcu_notrace (which indirectly uses the
rcu_dereference_raw_notrace API) with hlist_for_each_entry_rcu which
also does not do any tracing.
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
---
kernel/trace/ftrace.c | 4 ++--
kernel/trace/ftrace_internal.h | 8 ++++----
kernel/trace/trace.c | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index b920358dd8f7..f7d5f0ee69de 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -706,7 +706,7 @@ ftrace_find_profiled_func(struct ftrace_profile_stat *stat, unsigned long ip)
if (hlist_empty(hhd))
return NULL;
- hlist_for_each_entry_rcu_notrace(rec, hhd, node) {
+ hlist_for_each_entry_rcu(rec, hhd, node) {
if (rec->ip == ip)
return rec;
}
@@ -1135,7 +1135,7 @@ __ftrace_lookup_ip(struct ftrace_hash *hash, unsigned long ip)
key = ftrace_hash_key(hash, ip);
hhd = &hash->buckets[key];
- hlist_for_each_entry_rcu_notrace(entry, hhd, hlist) {
+ hlist_for_each_entry_rcu(entry, hhd, hlist) {
if (entry->ip == ip)
return entry;
}
diff --git a/kernel/trace/ftrace_internal.h b/kernel/trace/ftrace_internal.h
index 0515a2096f90..e3530a284f46 100644
--- a/kernel/trace/ftrace_internal.h
+++ b/kernel/trace/ftrace_internal.h
@@ -6,22 +6,22 @@
/*
* Traverse the ftrace_global_list, invoking all entries. The reason that we
- * can use rcu_dereference_raw_notrace() is that elements removed from this list
+ * can use rcu_dereference_raw() is that elements removed from this list
* are simply leaked, so there is no need to interact with a grace-period
- * mechanism. The rcu_dereference_raw_notrace() calls are needed to handle
+ * mechanism. The rcu_dereference_raw() calls are needed to handle
* concurrent insertions into the ftrace_global_list.
*
* Silly Alpha and silly pointer-speculation compiler optimizations!
*/
#define do_for_each_ftrace_op(op, list) \
- op = rcu_dereference_raw_notrace(list); \
+ op = rcu_dereference_raw(list); \
do
/*
* Optimized for just a single item in the list (as that is the normal case).
*/
#define while_for_each_ftrace_op(op) \
- while (likely(op = rcu_dereference_raw_notrace((op)->next)) && \
+ while (likely(op = rcu_dereference_raw((op)->next)) && \
unlikely((op) != &ftrace_list_end))
extern struct ftrace_ops __rcu *ftrace_ops_list;
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index ec439999f387..cb8d696d9cde 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2638,10 +2638,10 @@ static void ftrace_exports(struct ring_buffer_event *event)
preempt_disable_notrace();
- export = rcu_dereference_raw_notrace(ftrace_exports_list);
+ export = rcu_dereference_raw(ftrace_exports_list);
while (export) {
trace_process_export(export, event);
- export = rcu_dereference_raw_notrace(export->next);
+ export = rcu_dereference_raw(export->next);
}
preempt_enable_notrace();
--
2.22.0.rc1.257.g3120a18244-goog
^ permalink raw reply related
* [PATCH RFC 3/5] hashtable: Use the regular hlist_for_each_entry_rcu API
From: Joel Fernandes (Google) @ 2019-05-24 23:49 UTC (permalink / raw)
To: linux-kernel
Cc: rcu, Jonathan Corbet, linux-doc, Lai Jiangshan, Josh Triplett,
kvm-ppc, Miguel Ojeda, Ingo Molnar, Mathieu Desnoyers,
Steven Rostedt, Joel Fernandes (Google), Paul E. McKenney,
linuxppc-dev
In-Reply-To: <20190524234933.5133-1-joel@joelfernandes.org>
hlist_for_each_entry_rcu already does not do any tracing. This series
removes the notrace variant of it, so let us just use the regular API.
In a future patch, we can also remove the
hash_for_each_possible_rcu_notrace API that this patch touches.
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
---
include/linux/hashtable.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/hashtable.h b/include/linux/hashtable.h
index 417d2c4bc60d..47fa7b673c1b 100644
--- a/include/linux/hashtable.h
+++ b/include/linux/hashtable.h
@@ -189,7 +189,7 @@ static inline void hash_del_rcu(struct hlist_node *node)
* not do any RCU debugging or tracing.
*/
#define hash_for_each_possible_rcu_notrace(name, obj, member, key) \
- hlist_for_each_entry_rcu_notrace(obj, \
+ hlist_for_each_entry_rcu(obj, \
&name[hash_min(key, HASH_BITS(name))], member)
/**
--
2.22.0.rc1.257.g3120a18244-goog
^ permalink raw reply related
* [PATCH RFC 4/5] rculist: Remove hlist_for_each_entry_rcu_notrace since no users
From: Joel Fernandes (Google) @ 2019-05-24 23:49 UTC (permalink / raw)
To: linux-kernel
Cc: rcu, Jonathan Corbet, linux-doc, Lai Jiangshan, Josh Triplett,
kvm-ppc, Miguel Ojeda, Ingo Molnar, Mathieu Desnoyers,
Steven Rostedt, Joel Fernandes (Google), Paul E. McKenney,
linuxppc-dev
In-Reply-To: <20190524234933.5133-1-joel@joelfernandes.org>
The series removes all users of the API and with this patch, the API
itself.
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
---
.clang-format | 1 -
include/linux/rculist.h | 20 --------------------
2 files changed, 21 deletions(-)
diff --git a/.clang-format b/.clang-format
index 2ffd69afc1a8..aa935923f5cb 100644
--- a/.clang-format
+++ b/.clang-format
@@ -287,7 +287,6 @@ ForEachMacros:
- 'hlist_for_each_entry_from_rcu'
- 'hlist_for_each_entry_rcu'
- 'hlist_for_each_entry_rcu_bh'
- - 'hlist_for_each_entry_rcu_notrace'
- 'hlist_for_each_entry_safe'
- '__hlist_for_each_rcu'
- 'hlist_for_each_safe'
diff --git a/include/linux/rculist.h b/include/linux/rculist.h
index e91ec9ddcd30..0d3d77cf4f07 100644
--- a/include/linux/rculist.h
+++ b/include/linux/rculist.h
@@ -628,26 +628,6 @@ static inline void hlist_add_behind_rcu(struct hlist_node *n,
pos = hlist_entry_safe(rcu_dereference_raw(hlist_next_rcu(\
&(pos)->member)), typeof(*(pos)), member))
-/**
- * hlist_for_each_entry_rcu_notrace - iterate over rcu list of given type (for tracing)
- * @pos: the type * to use as a loop cursor.
- * @head: the head for your list.
- * @member: the name of the hlist_node within the struct.
- *
- * This list-traversal primitive may safely run concurrently with
- * the _rcu list-mutation primitives such as hlist_add_head_rcu()
- * as long as the traversal is guarded by rcu_read_lock().
- *
- * This is the same as hlist_for_each_entry_rcu() except that it does
- * not do any RCU debugging or tracing.
- */
-#define hlist_for_each_entry_rcu_notrace(pos, head, member) \
- for (pos = hlist_entry_safe (rcu_dereference_raw_notrace(hlist_first_rcu(head)),\
- typeof(*(pos)), member); \
- pos; \
- pos = hlist_entry_safe(rcu_dereference_raw_notrace(hlist_next_rcu(\
- &(pos)->member)), typeof(*(pos)), member))
-
/**
* hlist_for_each_entry_rcu_bh - iterate over rcu list of given type
* @pos: the type * to use as a loop cursor.
--
2.22.0.rc1.257.g3120a18244-goog
^ permalink raw reply related
* [PATCH RFC 5/5] rcu: Remove rcu_dereference_raw_notrace since no users
From: Joel Fernandes (Google) @ 2019-05-24 23:49 UTC (permalink / raw)
To: linux-kernel
Cc: rcu, Jonathan Corbet, linux-doc, Lai Jiangshan, Josh Triplett,
kvm-ppc, Miguel Ojeda, Ingo Molnar, Mathieu Desnoyers,
Steven Rostedt, Joel Fernandes (Google), Paul E. McKenney,
linuxppc-dev
In-Reply-To: <20190524234933.5133-1-joel@joelfernandes.org>
The series removes all users of the API and with this patch, the API
itself. Also fix documentation.
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
---
Documentation/RCU/Design/Requirements/Requirements.html | 6 +++---
include/linux/rcupdate.h | 9 ---------
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/Documentation/RCU/Design/Requirements/Requirements.html b/Documentation/RCU/Design/Requirements/Requirements.html
index 5a9238a2883c..9727278893e6 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.html
+++ b/Documentation/RCU/Design/Requirements/Requirements.html
@@ -2512,9 +2512,9 @@ disabled across the entire RCU read-side critical section.
<p>
It is possible to use tracing on RCU code, but tracing itself
uses RCU.
-For this reason, <tt>rcu_dereference_raw_notrace()</tt>
-is provided for use by tracing, which avoids the destructive
-recursion that could otherwise ensue.
+This is the other reason for using, <tt>rcu_dereference_raw()</tt>,
+for use by tracing, which avoids the destructive recursion that could
+otherwise ensue.
This API is also used by virtualization in some architectures,
where RCU readers execute in environments in which tracing
cannot be used.
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 922bb6848813..f917a27fc115 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -472,15 +472,6 @@ static inline void rcu_preempt_sleep_check(void) { }
__rcu_dereference_check((p), (c) || rcu_read_lock_sched_held(), \
__rcu)
-/*
- * The tracing infrastructure traces RCU (we want that), but unfortunately
- * some of the RCU checks causes tracing to lock up the system.
- *
- * The no-tracing version of rcu_dereference_raw() must not call
- * rcu_read_lock_held().
- */
-#define rcu_dereference_raw_notrace(p) __rcu_dereference_check((p), 1, __rcu)
-
/**
* rcu_dereference_protected() - fetch RCU pointer when updates prevented
* @p: The pointer to read, prior to dereferencing
--
2.22.0.rc1.257.g3120a18244-goog
^ permalink raw reply related
* Re: [PATCH 2/2] powerpc/perf: Fix mmcra corruption by bhrb_filter
From: Michael Ellerman @ 2019-05-25 0:54 UTC (permalink / raw)
To: Ravi Bangoria, peterz, jolsa, maddy
Cc: Ravi Bangoria, linuxppc-dev, linux-kernel, acme
In-Reply-To: <20190511024217.4013-2-ravi.bangoria@linux.ibm.com>
On Sat, 2019-05-11 at 02:42:17 UTC, Ravi Bangoria wrote:
> Consider a scenario where user creates two events:
>
> 1st event:
> attr.sample_type |= PERF_SAMPLE_BRANCH_STACK;
> attr.branch_sample_type = PERF_SAMPLE_BRANCH_ANY;
> fd = perf_event_open(attr, 0, 1, -1, 0);
>
> This sets cpuhw->bhrb_filter to 0 and returns valid fd.
>
> 2nd event:
> attr.sample_type |= PERF_SAMPLE_BRANCH_STACK;
> attr.branch_sample_type = PERF_SAMPLE_BRANCH_CALL;
> fd = perf_event_open(attr, 0, 1, -1, 0);
>
> It overrides cpuhw->bhrb_filter to -1 and returns with error.
>
> Now if power_pmu_enable() gets called by any path other than
> power_pmu_add(), ppmu->config_bhrb(-1) will set mmcra to -1.
>
> Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
> Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/3202e35ec1c8fc19cea24253ff83edf7
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Return for invalid IMC domain
From: Michael Ellerman @ 2019-05-25 0:54 UTC (permalink / raw)
To: Anju T Sudhakar; +Cc: pavsubra, maddy, linuxppc-dev, anju
In-Reply-To: <20190520085753.19670-1-anju@linux.vnet.ibm.com>
On Mon, 2019-05-20 at 08:57:53 UTC, Anju T Sudhakar wrote:
> Currently init_imc_pmu() can be failed either because
> an IMC unit with invalid domain(i.e an IMC node not
> supported by the kernel) is attempted a pmu-registration
> or something went wrong while registering a valid IMC unit.
> In both the cases kernel provides a 'Registration failed'
> error message.
>
> Example:
> Log message, when trace-imc node is not supported by the kernel, and the
> skiboot supports trace-imc node.
>
> So for kernel, trace-imc node is now an unknown domain.
>
> [ 1.731870] nest_phb5_imc performance monitor hardware support registered
> [ 1.731944] nest_powerbus0_imc performance monitor hardware support registered
> [ 1.734458] thread_imc performance monitor hardware support registered
> [ 1.734460] IMC Unknown Device type
> [ 1.734462] IMC PMU (null) Register failed
> [ 1.734558] nest_xlink0_imc performance monitor hardware support registered
> [ 1.734614] nest_xlink1_imc performance monitor hardware support registered
> [ 1.734670] nest_xlink2_imc performance monitor hardware support registered
> [ 1.747043] Initialise system trusted keyrings
> [ 1.747054] Key type blacklist registered
>
>
> To avoid ambiguity on the error message, return for invalid domain
> before attempting a pmu registration.
>
> Fixes: 8f95faaac56c1 (`powerpc/powernv: Detect and create IMC device`)
> Reported-by: Pavaman Subramaniyam <pavsubra@in.ibm.com>
> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
> Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/b59bd3527fe3c1939340df558d7f9d56
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Fix loading of kernel + initramfs with kexec_file_load()
From: Michael Ellerman @ 2019-05-25 0:54 UTC (permalink / raw)
To: Thiago Jung Bauermann, linuxppc-dev
Cc: AKASHI Takahiro, Thiago Jung Bauermann, kexec, linux-kernel,
Mimi Zohar
In-Reply-To: <20190522220158.18479-1-bauerman@linux.ibm.com>
On Wed, 2019-05-22 at 22:01:58 UTC, Thiago Jung Bauermann wrote:
> Commit b6664ba42f14 ("s390, kexec_file: drop arch_kexec_mem_walk()")
> changed kexec_add_buffer() to skip searching for a memory location if
> kexec_buf.mem is already set, and use the address that is there.
>
> In powerpc code we reuse a kexec_buf variable for loading both the kernel
> and the initramfs by resetting some of the fields between those uses, but
> not mem. This causes kexec_add_buffer() to try to load the kernel at the
> same address where initramfs will be loaded, which is naturally rejected:
>
> # kexec -s -l --initrd initramfs vmlinuz
> kexec_file_load failed: Invalid argument
>
> Setting the mem field before every call to kexec_add_buffer() fixes this
> regression.
>
> Fixes: b6664ba42f14 ("s390, kexec_file: drop arch_kexec_mem_walk()")
> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> Reviewed-by: Dave Young <dyoung@redhat.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/8b909e3548706cbebc0a676067b81aad
cheers
^ permalink raw reply
* Re: [PATCH RFC 0/5] Remove some notrace RCU APIs
From: Steven Rostedt @ 2019-05-25 3:24 UTC (permalink / raw)
To: Joel Fernandes (Google)
Cc: rcu, Jonathan Corbet, linux-doc, Lai Jiangshan, linux-kernel,
kvm-ppc, Josh Triplett, Miguel Ojeda, Ingo Molnar,
Mathieu Desnoyers, Paul E. McKenney, linuxppc-dev
In-Reply-To: <20190524234933.5133-1-joel@joelfernandes.org>
On Fri, 24 May 2019 19:49:28 -0400
"Joel Fernandes (Google)" <joel@joelfernandes.org> wrote:
> The series removes users of the following APIs, and the APIs themselves, since
> the regular non - _notrace variants don't do any tracing anyway.
> * hlist_for_each_entry_rcu_notrace
> * rcu_dereference_raw_notrace
>
I guess the difference between the _raw_notrace and just _raw variants
is that _notrace ones do a rcu_check_sparse(). Don't we want to keep
that check?
-- Steve
^ permalink raw reply
* Re: [PATCH RFC 0/5] Remove some notrace RCU APIs
From: Joel Fernandes @ 2019-05-25 8:14 UTC (permalink / raw)
To: Steven Rostedt
Cc: rcu, Jonathan Corbet, linux-doc, Lai Jiangshan, linux-kernel,
kvm-ppc, Josh Triplett, Miguel Ojeda, Ingo Molnar,
Mathieu Desnoyers, Paul E. McKenney, linuxppc-dev
In-Reply-To: <20190524232458.4bcf4eb4@gandalf.local.home>
On Fri, May 24, 2019 at 11:24:58PM -0400, Steven Rostedt wrote:
> On Fri, 24 May 2019 19:49:28 -0400
> "Joel Fernandes (Google)" <joel@joelfernandes.org> wrote:
>
> > The series removes users of the following APIs, and the APIs themselves, since
> > the regular non - _notrace variants don't do any tracing anyway.
> > * hlist_for_each_entry_rcu_notrace
> > * rcu_dereference_raw_notrace
> >
>
> I guess the difference between the _raw_notrace and just _raw variants
> is that _notrace ones do a rcu_check_sparse(). Don't we want to keep
> that check?
This is true.
Since the users of _raw_notrace are very few, is it worth keeping this API
just for sparse checking? The API naming is also confusing. I was expecting
_raw_notrace to do fewer checks than _raw, instead of more. Honestly, I just
want to nuke _raw_notrace as done in this series and later we can introduce a
sparse checking version of _raw if need-be. The other option could be to
always do sparse checking for _raw however that used to be the case and got
changed in http://lists.infradead.org/pipermail/linux-afs/2016-July/001016.html
thanks a lot,
- Joel
>
> -- Steve
^ permalink raw reply
* Re: [PATCH RFC 0/5] Remove some notrace RCU APIs
From: Steven Rostedt @ 2019-05-25 11:08 UTC (permalink / raw)
To: Joel Fernandes
Cc: rcu, Jonathan Corbet, linux-doc, Lai Jiangshan, linux-kernel,
kvm-ppc, Josh Triplett, Miguel Ojeda, Ingo Molnar,
Mathieu Desnoyers, Paul E. McKenney, linuxppc-dev
In-Reply-To: <20190525081444.GC197789@google.com>
On Sat, 25 May 2019 04:14:44 -0400
Joel Fernandes <joel@joelfernandes.org> wrote:
> > I guess the difference between the _raw_notrace and just _raw variants
> > is that _notrace ones do a rcu_check_sparse(). Don't we want to keep
> > that check?
>
> This is true.
>
> Since the users of _raw_notrace are very few, is it worth keeping this API
> just for sparse checking? The API naming is also confusing. I was expecting
> _raw_notrace to do fewer checks than _raw, instead of more. Honestly, I just
> want to nuke _raw_notrace as done in this series and later we can introduce a
> sparse checking version of _raw if need-be. The other option could be to
> always do sparse checking for _raw however that used to be the case and got
> changed in http://lists.infradead.org/pipermail/linux-afs/2016-July/001016.html
What if we just rename _raw to _raw_nocheck, and _raw_notrace to _raw ?
-- Steve
^ permalink raw reply
* Re: [PATCH RFC 0/5] Remove some notrace RCU APIs
From: Joel Fernandes @ 2019-05-25 14:19 UTC (permalink / raw)
To: Steven Rostedt
Cc: rcu, Jonathan Corbet, linux-doc, Lai Jiangshan, linux-kernel,
kvm-ppc, Josh Triplett, Miguel Ojeda, Ingo Molnar,
Mathieu Desnoyers, Paul E. McKenney, linuxppc-dev
In-Reply-To: <20190525070826.16f76ee7@gandalf.local.home>
On Sat, May 25, 2019 at 07:08:26AM -0400, Steven Rostedt wrote:
> On Sat, 25 May 2019 04:14:44 -0400
> Joel Fernandes <joel@joelfernandes.org> wrote:
>
> > > I guess the difference between the _raw_notrace and just _raw variants
> > > is that _notrace ones do a rcu_check_sparse(). Don't we want to keep
> > > that check?
> >
> > This is true.
> >
> > Since the users of _raw_notrace are very few, is it worth keeping this API
> > just for sparse checking? The API naming is also confusing. I was expecting
> > _raw_notrace to do fewer checks than _raw, instead of more. Honestly, I just
> > want to nuke _raw_notrace as done in this series and later we can introduce a
> > sparse checking version of _raw if need-be. The other option could be to
> > always do sparse checking for _raw however that used to be the case and got
> > changed in http://lists.infradead.org/pipermail/linux-afs/2016-July/001016.html
>
> What if we just rename _raw to _raw_nocheck, and _raw_notrace to _raw ?
That would also mean changing 160 usages of _raw to _raw_nocheck in the
kernel :-/.
The tracing usage of _raw_notrace is only like 2 or 3 users. Can we just call
rcu_check_sparse directly in the calling code for those and eliminate the APIs?
I wonder what Paul thinks about the matter as well.
thanks, Steven!
^ permalink raw reply
* Re: [PATCH RFC 0/5] Remove some notrace RCU APIs
From: Paul E. McKenney @ 2019-05-25 15:50 UTC (permalink / raw)
To: Joel Fernandes
Cc: rcu, Jonathan Corbet, linux-doc, Lai Jiangshan, Josh Triplett,
Steven Rostedt, linux-kernel, Miguel Ojeda, Ingo Molnar,
Mathieu Desnoyers, kvm-ppc, linuxppc-dev
In-Reply-To: <20190525141954.GA176647@google.com>
On Sat, May 25, 2019 at 10:19:54AM -0400, Joel Fernandes wrote:
> On Sat, May 25, 2019 at 07:08:26AM -0400, Steven Rostedt wrote:
> > On Sat, 25 May 2019 04:14:44 -0400
> > Joel Fernandes <joel@joelfernandes.org> wrote:
> >
> > > > I guess the difference between the _raw_notrace and just _raw variants
> > > > is that _notrace ones do a rcu_check_sparse(). Don't we want to keep
> > > > that check?
> > >
> > > This is true.
> > >
> > > Since the users of _raw_notrace are very few, is it worth keeping this API
> > > just for sparse checking? The API naming is also confusing. I was expecting
> > > _raw_notrace to do fewer checks than _raw, instead of more. Honestly, I just
> > > want to nuke _raw_notrace as done in this series and later we can introduce a
> > > sparse checking version of _raw if need-be. The other option could be to
> > > always do sparse checking for _raw however that used to be the case and got
> > > changed in http://lists.infradead.org/pipermail/linux-afs/2016-July/001016.html
> >
> > What if we just rename _raw to _raw_nocheck, and _raw_notrace to _raw ?
>
> That would also mean changing 160 usages of _raw to _raw_nocheck in the
> kernel :-/.
>
> The tracing usage of _raw_notrace is only like 2 or 3 users. Can we just call
> rcu_check_sparse directly in the calling code for those and eliminate the APIs?
>
> I wonder what Paul thinks about the matter as well.
My thought is that it is likely that a goodly number of the current uses
of _raw should really be some form of _check, with lockdep expressions
spelled out. Not that working out what exactly those lockdep expressions
should be is necessarily a trivial undertaking. ;-)
That aside, if we are going to change the name of an API that is
used 160 places throughout the tree, we would need to have a pretty
good justification. Without such a justification, it will just look
like pointless churn to the various developers and maintainers on the
receiving end of the patches.
Thanx, Paul
> thanks, Steven!
>
^ permalink raw reply
* Re: [PATCH RFC 0/5] Remove some notrace RCU APIs
From: Joel Fernandes @ 2019-05-25 18:14 UTC (permalink / raw)
To: Paul E. McKenney
Cc: rcu, Jonathan Corbet, linux-doc, Lai Jiangshan, Josh Triplett,
Steven Rostedt, linux-kernel, Miguel Ojeda, Ingo Molnar,
Mathieu Desnoyers, kvm-ppc, linuxppc-dev
In-Reply-To: <20190525155035.GE28207@linux.ibm.com>
On Sat, May 25, 2019 at 08:50:35AM -0700, Paul E. McKenney wrote:
> On Sat, May 25, 2019 at 10:19:54AM -0400, Joel Fernandes wrote:
> > On Sat, May 25, 2019 at 07:08:26AM -0400, Steven Rostedt wrote:
> > > On Sat, 25 May 2019 04:14:44 -0400
> > > Joel Fernandes <joel@joelfernandes.org> wrote:
> > >
> > > > > I guess the difference between the _raw_notrace and just _raw variants
> > > > > is that _notrace ones do a rcu_check_sparse(). Don't we want to keep
> > > > > that check?
> > > >
> > > > This is true.
> > > >
> > > > Since the users of _raw_notrace are very few, is it worth keeping this API
> > > > just for sparse checking? The API naming is also confusing. I was expecting
> > > > _raw_notrace to do fewer checks than _raw, instead of more. Honestly, I just
> > > > want to nuke _raw_notrace as done in this series and later we can introduce a
> > > > sparse checking version of _raw if need-be. The other option could be to
> > > > always do sparse checking for _raw however that used to be the case and got
> > > > changed in http://lists.infradead.org/pipermail/linux-afs/2016-July/001016.html
> > >
> > > What if we just rename _raw to _raw_nocheck, and _raw_notrace to _raw ?
> >
> > That would also mean changing 160 usages of _raw to _raw_nocheck in the
> > kernel :-/.
> >
> > The tracing usage of _raw_notrace is only like 2 or 3 users. Can we just call
> > rcu_check_sparse directly in the calling code for those and eliminate the APIs?
> >
> > I wonder what Paul thinks about the matter as well.
>
> My thought is that it is likely that a goodly number of the current uses
> of _raw should really be some form of _check, with lockdep expressions
> spelled out. Not that working out what exactly those lockdep expressions
> should be is necessarily a trivial undertaking. ;-)
Yes, currently where I am a bit stuck is the rcu_dereference_raw()
cannot possibly know what SRCU domain it is under, so lockdep cannot check if
an SRCU lock is held without the user also passing along the SRCU domain. I
am trying to change lockdep to see if it can check if *any* srcu domain lock
is held (regardless of which one) and complain if none are. This is at least
better than no check at all.
However, I think it gets tricky for mutexes. If you have something like:
mutex_lock(some_mutex);
p = rcu_dereference_raw(gp);
mutex_unlock(some_mutex);
This might be a perfectly valid invocation of _raw, however my checks (patch
is still cooking) trigger a lockdep warning becase _raw cannot know that this
is Ok. lockdep thinks it is not in a reader section. This then gets into the
territory of a new rcu_derference_raw_protected(gp, assert_held(some_mutex))
which sucks because its yet another API. To circumvent this issue, can we
just have callers of rcu_dereference_raw ensure that they call
rcu_read_lock() if they are protecting dereferences by a mutex? That would
make things a lot easier and also may be Ok since rcu_read_lock is quite
cheap.
> That aside, if we are going to change the name of an API that is
> used 160 places throughout the tree, we would need to have a pretty
> good justification. Without such a justification, it will just look
> like pointless churn to the various developers and maintainers on the
> receiving end of the patches.
Actually, the API name change is not something I want to do, it is Steven
suggestion. My suggestion is let us just delete _raw_notrace and just use the
_raw API for tracing, since _raw doesn't do any tracing anyway. Steve pointed
that _raw_notrace does sparse checking unlike _raw, but I think that isn't an
issue since _raw doesn't do such checking at the moment anyway.. (if possible
check my cover letter again for details/motivation of this series).
thanks!
- Joel
> Thanx, Paul
>
> > thanks, Steven!
> >
>
^ permalink raw reply
* Re: [PATCH RFC 0/5] Remove some notrace RCU APIs
From: Joel Fernandes @ 2019-05-25 18:18 UTC (permalink / raw)
To: Paul E. McKenney
Cc: rcu, Jonathan Corbet, linux-doc, Lai Jiangshan, Josh Triplett,
Steven Rostedt, linux-kernel, Miguel Ojeda, Ingo Molnar,
Mathieu Desnoyers, kvm-ppc, linuxppc-dev
In-Reply-To: <20190525181407.GA220326@google.com>
On Sat, May 25, 2019 at 02:14:07PM -0400, Joel Fernandes wrote:
[snip]
> > That aside, if we are going to change the name of an API that is
> > used 160 places throughout the tree, we would need to have a pretty
> > good justification. Without such a justification, it will just look
> > like pointless churn to the various developers and maintainers on the
> > receiving end of the patches.
>
> Actually, the API name change is not something I want to do, it is Steven
> suggestion. My suggestion is let us just delete _raw_notrace and just use the
> _raw API for tracing, since _raw doesn't do any tracing anyway. Steve pointed
> that _raw_notrace does sparse checking unlike _raw, but I think that isn't an
> issue since _raw doesn't do such checking at the moment anyway.. (if possible
> check my cover letter again for details/motivation of this series).
Come to think of it, if we/I succeed in adding lockdep checking in _raw, then
we can just keep the current APIs and not delete anything. And we can have
_raw_notrace skip the lockdep checks. The sparse check question would still
be an open one though, since _raw doesn't do sparse checks at the moment
unlike _raw_notrace as Steve pointed.
Thanks,
- Joel
^ permalink raw reply
* Re: [PATCH v2] mm: add account_locked_vm utility function
From: Andrew Morton @ 2019-05-25 21:51 UTC (permalink / raw)
To: Daniel Jordan
Cc: Mark Rutland, Davidlohr Bueso, kvm, Alan Tull,
Alexey Kardashevskiy, linux-fpga, linux-kernel, kvm-ppc, linux-mm,
Alex Williamson, Jason Gunthorpe, Moritz Fischer, Steve Sistare,
Christoph Lameter, linuxppc-dev, Wu Hao
In-Reply-To: <20190524175045.26897-1-daniel.m.jordan@oracle.com>
On Fri, 24 May 2019 13:50:45 -0400 Daniel Jordan <daniel.m.jordan@oracle.com> wrote:
> locked_vm accounting is done roughly the same way in five places, so
> unify them in a helper. Standardize the debug prints, which vary
> slightly, but include the helper's caller to disambiguate between
> callsites.
>
> Error codes stay the same, so user-visible behavior does too. The one
> exception is that the -EPERM case in tce_account_locked_vm is removed
> because Alexey has never seen it triggered.
>
> ...
>
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1564,6 +1564,25 @@ long get_user_pages_unlocked(unsigned long start, unsigned long nr_pages,
> int get_user_pages_fast(unsigned long start, int nr_pages,
> unsigned int gup_flags, struct page **pages);
>
> +int __account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc,
> + struct task_struct *task, bool bypass_rlim);
> +
> +static inline int account_locked_vm(struct mm_struct *mm, unsigned long pages,
> + bool inc)
> +{
> + int ret;
> +
> + if (pages == 0 || !mm)
> + return 0;
> +
> + down_write(&mm->mmap_sem);
> + ret = __account_locked_vm(mm, pages, inc, current,
> + capable(CAP_IPC_LOCK));
> + up_write(&mm->mmap_sem);
> +
> + return ret;
> +}
That's quite a mouthful for an inlined function. How about uninlining
the whole thing and fiddling drivers/vfio/vfio_iommu_type1.c to suit.
I wonder why it does down_write_killable and whether it really needs
to...
^ permalink raw reply
* [PATCH] dlpar: Fix a missing-check bug in dlpar_parse_cc_property()
From: Gen Zhang @ 2019-05-26 2:42 UTC (permalink / raw)
To: benh, paulus; +Cc: nfont, linuxppc-dev, linux-kernel
In dlpar_parse_cc_property(), 'prop->name' is allocated by kstrdup().
kstrdup() may return NULL, so it should be checked and handle error.
And prop should be freed if 'prop->name' is NULL.
Signed-off-by: Gen Zhang <blackgod016574@gmail.com>
---
diff --git a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c
index 1795804..c852024 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -61,6 +61,10 @@ static struct property *dlpar_parse_cc_property(struct cc_workarea *ccwa)
name = (char *)ccwa + be32_to_cpu(ccwa->name_offset);
prop->name = kstrdup(name, GFP_KERNEL);
+ if (!prop->name) {
+ dlpar_free_cc_property(prop);
+ return NULL;
+ }
prop->length = be32_to_cpu(ccwa->prop_length);
value = (char *)ccwa + be32_to_cpu(ccwa->prop_offset);
---
^ permalink raw reply related
* Re: [PATCH RFC 4/5] rculist: Remove hlist_for_each_entry_rcu_notrace since no users
From: Miguel Ojeda @ 2019-05-26 16:20 UTC (permalink / raw)
To: Joel Fernandes (Google)
Cc: rcu, Jonathan Corbet, Linux Doc Mailing List, Lai Jiangshan,
linux-kernel, kvm-ppc, Josh Triplett, Ingo Molnar,
Mathieu Desnoyers, Steven Rostedt, Paul E. McKenney, linuxppc-dev
In-Reply-To: <20190524234933.5133-5-joel@joelfernandes.org>
On Sat, May 25, 2019 at 1:50 AM Joel Fernandes (Google)
<joel@joelfernandes.org> wrote:
>
> The series removes all users of the API and with this patch, the API
> itself.
>
> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> ---
> .clang-format | 1 -
Ack for clang-format, and thanks for removing it there too! :-)
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v2 1/2] open: add close_range()
From: Szabolcs Nagy @ 2019-05-26 20:20 UTC (permalink / raw)
To: Christian Brauner
Cc: linux-ia64, linux-sh, oleg, dhowells, linux-kselftest, sparclinux,
shuah, linux-arch, linux-s390, miklos, x86, torvalds, linux-mips,
linux-xtensa, tkjos, arnd, jannh, linux-m68k, viro, tglx, ldv,
linux-arm-kernel, fweimer, linux-parisc, linux-api, linux-kernel,
linux-alpha, linux-fsdevel, linuxppc-dev
In-Reply-To: <20190523154747.15162-2-christian@brauner.io>
* Christian Brauner <christian@brauner.io> [2019-05-23 17:47:46 +0200]:
> This adds the close_range() syscall. It allows to efficiently close a range
> of file descriptors up to all file descriptors of a calling task.
>
> The syscall came up in a recent discussion around the new mount API and
> making new file descriptor types cloexec by default. During this
> discussion, Al suggested the close_range() syscall (cf. [1]). Note, a
> syscall in this manner has been requested by various people over time.
>
> First, it helps to close all file descriptors of an exec()ing task. This
> can be done safely via (quoting Al's example from [1] verbatim):
>
> /* that exec is sensitive */
> unshare(CLONE_FILES);
> /* we don't want anything past stderr here */
> close_range(3, ~0U);
> execve(....);
this does not work in a hosted c implementation unless the libc
guarantees not to use libc internal fds (e.g. in execve).
(the libc cannot easily abstract fds, so the syscall abi layer
fd semantics is necessarily visible to user code.)
i think this is a new constraint for userspace runtimes.
(not entirely unreasonable though)
> The code snippet above is one way of working around the problem that file
> descriptors are not cloexec by default. This is aggravated by the fact that
> we can't just switch them over without massively regressing userspace. For
> a whole class of programs having an in-kernel method of closing all file
> descriptors is very helpful (e.g. demons, service managers, programming
> language standard libraries, container managers etc.).
was cloexec_range(a,b) considered?
> (Please note, unshare(CLONE_FILES) should only be needed if the calling
> task is multi-threaded and shares the file descriptor table with another
> thread in which case two threads could race with one thread allocating
> file descriptors and the other one closing them via close_range(). For the
> general case close_range() before the execve() is sufficient.)
assuming there is no unblocked signal handler that may open fds.
a syscall that tramples on fds not owned by the caller is ugly
(not generally safe to use and may break things if it gets used),
i don't have a better solution for fd leaks or missing cloexec,
but i think it needs more analysis how it can be used.
^ permalink raw reply
* Re: [PATCH v2 20/45] drivers: tty: serial: msm_serial: use devm_* functions
From: Bjorn Andersson @ 2019-05-27 5:57 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-arm-msm, yamada.masahiro, macro, jacmet, festevam,
stefan.wahren, f.fainelli, bcm-kernel-feedback-list, linux-imx,
linux-serial, u.kleine-koenig, andy.gross, tklauser, david.brown,
rjui, s.hauer, slemieux.tyco, linuxppc-dev, vz, matthias.bgg,
andriy.shevchenko, baohua, sbranden, eric, richard.genoud, gregkh,
linux-kernel, kernel, shawnguo
In-Reply-To: <1552602855-26086-21-git-send-email-info@metux.net>
On Thu 14 Mar 15:33 PDT 2019, Enrico Weigelt, metux IT consult wrote:
> Use the safer devm versions of memory mapping functions.
>
> Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
As pointed out by others, this resource does not follow the life cycle
of the port->dev, so I don't think this improves the code.
Regards,
Bjorn
> ---
> drivers/tty/serial/msm_serial.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
> index 1090960..e8e0c87 100644
> --- a/drivers/tty/serial/msm_serial.c
> +++ b/drivers/tty/serial/msm_serial.c
> @@ -1324,8 +1324,8 @@ static void msm_release_port(struct uart_port *port)
> return;
> size = resource_size(uart_resource);
>
> - release_mem_region(port->mapbase, size);
> - iounmap(port->membase);
> + devm_release_mem_region(port->dev, port->mapbase, size);
> + devm_iounmap(port->dev, port->membase);
> port->membase = NULL;
> }
>
> @@ -1342,10 +1342,13 @@ static int msm_request_port(struct uart_port *port)
>
> size = resource_size(uart_resource);
>
> - if (!request_mem_region(port->mapbase, size, "msm_serial"))
> + if (!devm_request_mem_region(port->dev,
> + port->mapbase,
> + size,
> + "msm_serial"))
> return -EBUSY;
>
> - port->membase = ioremap(port->mapbase, size);
> + port->membase = ioremap(port->dev, port->mapbase, size);
> if (!port->membase) {
> ret = -EBUSY;
> goto fail_release_port;
> @@ -1354,7 +1357,7 @@ static int msm_request_port(struct uart_port *port)
> return 0;
>
> fail_release_port:
> - release_mem_region(port->mapbase, size);
> + devm_release_mem_region(port->dev, port->mapbase, size);
> return ret;
> }
>
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 10/10] docs: fix broken documentation links
From: Rafael J. Wysocki @ 2019-05-27 8:43 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: kvm, Linux Doc Mailing List, Linux PCI, Platform Driver,
Linux Memory Management List, linux-i2c, linux-kselftest, devel,
Jonathan Corbet, the arch/x86 maintainers, ACPI Devel Maling List,
xen-devel, open list:EDAC-CORE, devicetree@vger.kernel.org,
linux-arm-msm, Mauro Carvalho Chehab, linux-gpio, linux-amlogic,
virtualization, Linux ARM,
open list:ACPI COMPONENT ARCHITECTURE (ACPICA), netdev,
Linux Kernel Mailing List, linux-security-module, linuxppc-dev
In-Reply-To: <4fd1182b4a41feb2447c7ccde4d7f0a6b3c92686.1558362030.git.mchehab+samsung@kernel.org>
On Mon, May 20, 2019 at 4:48 PM Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
>
> Mostly due to x86 and acpi conversion, several documentation
> links are still pointing to the old file. Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
For the ACPI part:
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
^ permalink raw reply
* Re: [PATCH] mm/nvdimm: Use correct alignment when looking at first pfn from a region
From: Aneesh Kumar K.V @ 2019-05-27 9:35 UTC (permalink / raw)
To: Dan Williams; +Cc: Linux MM, linuxppc-dev, linux-nvdimm
In-Reply-To: <925e41ad-cc57-bc03-a2b6-6913c9e98abf@linux.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> On 5/14/19 9:59 AM, Dan Williams wrote:
>> On Mon, May 13, 2019 at 7:55 PM Aneesh Kumar K.V
>> <aneesh.kumar@linux.ibm.com> wrote:
>>>
>>> We already add the start_pad to the resource->start but fails to section
>>> align the start. This make sure with altmap we compute the right first
>>> pfn when start_pad is zero and we are doing an align down of start address.
>>>
>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>>> ---
>>> kernel/memremap.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/kernel/memremap.c b/kernel/memremap.c
>>> index a856cb5ff192..23d77b60e728 100644
>>> --- a/kernel/memremap.c
>>> +++ b/kernel/memremap.c
>>> @@ -59,9 +59,9 @@ static unsigned long pfn_first(struct dev_pagemap *pgmap)
>>> {
>>> const struct resource *res = &pgmap->res;
>>> struct vmem_altmap *altmap = &pgmap->altmap;
>>> - unsigned long pfn;
>>> + unsigned long pfn = PHYS_PFN(res->start);
>>>
>>> - pfn = res->start >> PAGE_SHIFT;
>>> + pfn = SECTION_ALIGN_DOWN(pfn);
>>
>> This does not seem right to me it breaks the assumptions of where the
>> first expected valid pfn occurs in the passed in range.
>>
>
> How do we define the first valid pfn? Isn't that at pfn_sb->dataoff ?
for altmap the pfn_first should be
pfn_first = altmap->base_pfn + vmem_altmap_offset(altmap);
?
-aneesh
^ permalink raw reply
* Re: [PATCH v2] powerpc/power: Expose pfn_is_nosave prototype
From: Rafael J. Wysocki @ 2019-05-27 10:53 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Len Brown, linux-s390, linux-pm, Heiko Carstens, linux-kernel,
Paul Mackerras, Pavel Machek, Martin Schwidefsky, linuxppc-dev
In-Reply-To: <20190524104418.17194-1-malat@debian.org>
On Friday, May 24, 2019 12:44:18 PM CEST Mathieu Malaterre wrote:
> The declaration for pfn_is_nosave is only available in
> kernel/power/power.h. Since this function can be override in arch,
> expose it globally. Having a prototype will make sure to avoid warning
> (sometime treated as error with W=1) such as:
>
> arch/powerpc/kernel/suspend.c:18:5: error: no previous prototype for 'pfn_is_nosave' [-Werror=missing-prototypes]
>
> This moves the declaration into a globally visible header file and add
> missing include to avoid a warning on powerpc. Also remove the
> duplicated prototypes since not required anymore.
>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> v2: As suggestion by christophe remove duplicates prototypes
>
> arch/powerpc/kernel/suspend.c | 1 +
> arch/s390/kernel/entry.h | 1 -
> include/linux/suspend.h | 1 +
> kernel/power/power.h | 2 --
> 4 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/suspend.c b/arch/powerpc/kernel/suspend.c
> index a531154cc0f3..9e1b6b894245 100644
> --- a/arch/powerpc/kernel/suspend.c
> +++ b/arch/powerpc/kernel/suspend.c
> @@ -8,6 +8,7 @@
> */
>
> #include <linux/mm.h>
> +#include <linux/suspend.h>
> #include <asm/page.h>
> #include <asm/sections.h>
>
> diff --git a/arch/s390/kernel/entry.h b/arch/s390/kernel/entry.h
> index 20420c2b8a14..b2956d49b6ad 100644
> --- a/arch/s390/kernel/entry.h
> +++ b/arch/s390/kernel/entry.h
> @@ -63,7 +63,6 @@ void __init startup_init(void);
> void die(struct pt_regs *regs, const char *str);
> int setup_profiling_timer(unsigned int multiplier);
> void __init time_init(void);
> -int pfn_is_nosave(unsigned long);
> void s390_early_resume(void);
> unsigned long prepare_ftrace_return(unsigned long parent, unsigned long sp, unsigned long ip);
>
> diff --git a/include/linux/suspend.h b/include/linux/suspend.h
> index 6b3ea9ea6a9e..e8b8a7bede90 100644
> --- a/include/linux/suspend.h
> +++ b/include/linux/suspend.h
> @@ -395,6 +395,7 @@ extern bool system_entering_hibernation(void);
> extern bool hibernation_available(void);
> asmlinkage int swsusp_save(void);
> extern struct pbe *restore_pblist;
> +int pfn_is_nosave(unsigned long pfn);
> #else /* CONFIG_HIBERNATION */
> static inline void register_nosave_region(unsigned long b, unsigned long e) {}
> static inline void register_nosave_region_late(unsigned long b, unsigned long e) {}
> diff --git a/kernel/power/power.h b/kernel/power/power.h
> index 9e58bdc8a562..44bee462ff57 100644
> --- a/kernel/power/power.h
> +++ b/kernel/power/power.h
> @@ -75,8 +75,6 @@ static inline void hibernate_reserved_size_init(void) {}
> static inline void hibernate_image_size_init(void) {}
> #endif /* !CONFIG_HIBERNATION */
>
> -extern int pfn_is_nosave(unsigned long);
> -
> #define power_attr(_name) \
> static struct kobj_attribute _name##_attr = { \
> .attr = { \
>
With an ACK from the powerpc maintainers, I could apply this one.
^ permalink raw reply
* [PATCH v3 01/11] mm/memory_hotplug: Simplify and fix check_hotplug_memory_range()
From: David Hildenbrand @ 2019-05-27 11:11 UTC (permalink / raw)
To: linux-mm
Cc: linux-s390, Michal Hocko, linux-ia64, Pavel Tatashin, linux-sh,
Mathieu Malaterre, David Hildenbrand, linux-kernel, Wei Yang,
Arun KS, Qian Cai, Wei Yang, Igor Mammedov, akpm, linuxppc-dev,
Dan Williams, linux-arm-kernel, Oscar Salvador
In-Reply-To: <20190527111152.16324-1-david@redhat.com>
By converting start and size to page granularity, we actually ignore
unaligned parts within a page instead of properly bailing out with an
error.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Qian Cai <cai@lca.pw>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Arun KS <arunks@codeaurora.org>
Cc: Mathieu Malaterre <malat@debian.org>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Wei Yang <richardw.yang@linux.intel.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
mm/memory_hotplug.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index e096c987d261..762887b2358b 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1051,16 +1051,11 @@ int try_online_node(int nid)
static int check_hotplug_memory_range(u64 start, u64 size)
{
- unsigned long block_sz = memory_block_size_bytes();
- u64 block_nr_pages = block_sz >> PAGE_SHIFT;
- u64 nr_pages = size >> PAGE_SHIFT;
- u64 start_pfn = PFN_DOWN(start);
-
/* memory range must be block size aligned */
- if (!nr_pages || !IS_ALIGNED(start_pfn, block_nr_pages) ||
- !IS_ALIGNED(nr_pages, block_nr_pages)) {
+ if (!size || !IS_ALIGNED(start, memory_block_size_bytes()) ||
+ !IS_ALIGNED(size, memory_block_size_bytes())) {
pr_err("Block size [%#lx] unaligned hotplug range: start %#llx, size %#llx",
- block_sz, start, size);
+ memory_block_size_bytes(), start, size);
return -EINVAL;
}
--
2.20.1
^ permalink raw reply related
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