* [Devel] patch request for tbxfload.c
From: scole_mail @ 2016-11-14 16:58 UTC (permalink / raw)
To: devel
[-- Attachment #1: Type: text/plain, Size: 2070 bytes --]
I was hoping this patch could be added. I am trying to run
netbsd/ia64 on a simulator (ski). Without the patch, I get a
segfault. With it, I get the same messages as previous acpica
versions with no seg-faulting.
I'm not sure if it is a just a ia64/ski issue, but it seems like
AcpiGbl_DsdtIndex is never getting set. It looks like only
AcpiTbInstallFixedTable() sets it, but I'm not seeing that called.
AcpiTbInstallTableWithOverride() has a comment saying it sets it, but
I don't see AcpiGbl_DsdtIndex passed to it either.
Output with the patch is below.
Thanks
*** ./acpica-unix-20160930/source/components/tables/tbxfload.c.orig Mon Nov 14 08:44:43 2016
--- ./acpica-unix-20160930/source/components/tables/tbxfload.c Mon Nov 14 08:47:04 2016
***************
*** 236,241 ****
--- 236,250 ----
(void) AcpiUtAcquireMutex (ACPI_MTX_TABLES);
/*
+ * If AcpiGbl_DsdtIndex uninitialized, give up.
+ */
+ if (AcpiGbl_DsdtIndex == ACPI_INVALID_TABLE_INDEX)
+ {
+ Status = AE_NO_ACPI_TABLES;
+ goto UnlockAndExit;
+ }
+
+ /*
* Load the namespace. The DSDT is required, but any SSDT and
* PSDT tables are optional. Verify the DSDT.
*/
ACPI: RSDP 0x0000000000120420 00002C (v02 FBSD )
ACPI: XSDT 0x0000000000120444 00002C (v00 FBSD SKI 00000000 FBSD 00000000)
ACPI BIOS Warning (bug): Incorrect checksum in table [APIC] - 0x00, should be 0x0C (20160930/tbprint-233)
ACPI: APIC 0x0000000000120470 000080 (v00 FBSD SKI 00000000 FBSD 00000000)
ACPI Exception: AE_NO_ACPI_TABLES, While loading namespace from ACPI tables (20160930/tbxfload-111)
ACPI Warning: AcpiEnable failed (20160930/utxfinit-184)
acpi_probe: failed to enable subsystem
ACPI Error: Could not remove SCI handler (20160930/evmisc-312)
acpi0 at mainbus0: Intel ACPICA 20160930
acpi0: X/RSDT: OemId < FBSD, SKI,00000000>, AslId <FBSD,00000000>
ACPI Warning: AcpiEnable failed (20160930/utxfinit-184)
acpi_attach: failed to initialize ACPI: AE_NO_ACPI_TABLES
^ permalink raw reply
* [Buildroot] [PATCH 1/1] package/nodejs: bump version to 6.9.1
From: Patrick Devlin @ 2016-11-14 16:58 UTC (permalink / raw)
To: buildroot
https://nodejs.org/en/blog/release/v6.9.1/
The patches from 6.7.0 have been copied to 6.9.1.
Signed-off-by: Patrick Devlin <cloudyparts@icloud.com>
---
.../{6.7.0 => 6.9.1}/0001-gyp-force-link-command-to-use-CXX.patch | 0
.../0002-inspector-don-t-build-when-ssl-support-is-disabled.patch | 0
package/nodejs/Config.in | 2 +-
package/nodejs/nodejs.hash | 4 ++--
4 files changed, 3 insertions(+), 3 deletions(-)
rename package/nodejs/{6.7.0 => 6.9.1}/0001-gyp-force-link-command-to-use-CXX.patch (100%)
rename package/nodejs/{6.7.0 => 6.9.1}/0002-inspector-don-t-build-when-ssl-support-is-disabled.patch (100%)
diff --git a/package/nodejs/6.7.0/0001-gyp-force-link-command-to-use-CXX.patch b/package/nodejs/6.9.1/0001-gyp-force-link-command-to-use-CXX.patch
similarity index 100%
rename from package/nodejs/6.7.0/0001-gyp-force-link-command-to-use-CXX.patch
rename to package/nodejs/6.9.1/0001-gyp-force-link-command-to-use-CXX.patch
diff --git a/package/nodejs/6.7.0/0002-inspector-don-t-build-when-ssl-support-is-disabled.patch b/package/nodejs/6.9.1/0002-inspector-don-t-build-when-ssl-support-is-disabled.patch
similarity index 100%
rename from package/nodejs/6.7.0/0002-inspector-don-t-build-when-ssl-support-is-disabled.patch
rename to package/nodejs/6.9.1/0002-inspector-don-t-build-when-ssl-support-is-disabled.patch
diff --git a/package/nodejs/Config.in b/package/nodejs/Config.in
index 976be50..a47ba37 100644
--- a/package/nodejs/Config.in
+++ b/package/nodejs/Config.in
@@ -43,7 +43,7 @@ config BR2_PACKAGE_NODEJS_V8_ARCH_SUPPORTS
config BR2_PACKAGE_NODEJS_VERSION_STRING
string
- default "6.7.0" if BR2_PACKAGE_NODEJS_V8_ARCH_SUPPORTS
+ default "6.9.1" if BR2_PACKAGE_NODEJS_V8_ARCH_SUPPORTS
default "0.10.47"
config BR2_PACKAGE_NODEJS_NPM
diff --git a/package/nodejs/nodejs.hash b/package/nodejs/nodejs.hash
index f334a47..5df79af 100644
--- a/package/nodejs/nodejs.hash
+++ b/package/nodejs/nodejs.hash
@@ -1,5 +1,5 @@
# From upstream URL: http://nodejs.org/dist/v0.10.47/SHASUMS256.txt
sha256 335bdf4db702885a8acaf2c9f241c70cabd62497361da81aca65c8e8a8e7ff09 node-v0.10.47.tar.xz
-# From upstream URL: http://nodejs.org/dist/v6.7.0/SHASUMS256.txt
-sha256 ceb028324aab1ee8c7ea6a62026f036f3ea71f5ef5212593d0f833f999dd3be5 node-v6.7.0.tar.xz
+# From upstream URL: http://nodejs.org/dist/v6.9.1/SHASUMS256.txt
+sha256 0bdd8d1305777cc8cd206129ea494d6c6ce56001868dd80147aff531d6df0729 node-v6.9.1.tar.xz
--
1.9.1
^ permalink raw reply related
* Re: [PATCH tip/core/rcu 1/2] documentation: Present updated RCU guarantee
From: Pranith Kumar @ 2016-11-14 16:57 UTC (permalink / raw)
To: Paul E. McKenney
Cc: LKML, Ingo Molnar, Lai Jiangshan, Dipankar Sarma, Andrew Morton,
Mathieu Desnoyers, Josh Triplett, Thomas Gleixner, Peter Zijlstra,
Steven Rostedt, David Howells, Eric Dumazet, Darren Hart,
Frederic Weisbecker, Oleg Nesterov
In-Reply-To: <1479142030-15102-1-git-send-email-paulmck@linux.vnet.ibm.com>
Hi Paul,
On Mon, Nov 14, 2016 at 11:47 AM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> Recent memory-model work deduces the relationships of RCU read-side
> critical sections and grace periods based on the relationships of
> accesses within a critical section and accesses preceding and following
> the grace period. This commit therefore adds this viewpoint.
>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> ---
> .../RCU/Design/Requirements/Requirements.html | 25 +++++++++++++++++++++-
> 1 file changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/RCU/Design/Requirements/Requirements.html b/Documentation/RCU/Design/Requirements/Requirements.html
> index a4d3838130e4..81b40cb83435 100644
> --- a/Documentation/RCU/Design/Requirements/Requirements.html
> +++ b/Documentation/RCU/Design/Requirements/Requirements.html
> @@ -547,7 +547,7 @@ The <tt>rcu_access_pointer()</tt> on line 6 is similar to
> It could reuse a value formerly fetched from this same pointer.
> It could also fetch the pointer from <tt>gp</tt> in a byte-at-a-time
> manner, resulting in <i>load tearing</i>, in turn resulting a bytewise
> - mash-up of two distince pointer values.
> + mash-up of two distinct pointer values.
> It might even use value-speculation optimizations, where it makes
> a wrong guess, but by the time it gets around to checking the
> value, an update has changed the pointer to match the wrong guess.
> @@ -659,6 +659,29 @@ systems with more than one CPU:
> In other words, a given instance of <tt>synchronize_rcu()</tt>
> can avoid waiting on a given RCU read-side critical section only
> if it can prove that <tt>synchronize_rcu()</tt> started first.
> +
> + <p>
> + A related question is “When <tt>rcu_read_lock()</tt>
> + doesn't generate any code, why does it matter how it relates
> + to a grace period?”
> + The answer if that it is not the relationship of
s/if/is?
> + <tt>rcu_read_lock()</tt> itself that is important, but rather
> + the relationship of the code within the enclosed RCU read-side
> + critical section to the code preceding and following the
> + grace period.
> + If we take this viewpoint, then a given RCU read-side critical
> + section begins before a given grace period when some access
> + preceding the grace period observes the effect of some access
> + within the critical section, in which case none of the accesses
> + within the critical section may observe the effects of any
> + access following the grace period.
> +
> + <p>
> + As of late 2016, mathematical models of RCU take this
> + viewpoint, for example, see slides 62 and 63
> + of the
> + <a href="http://www2.rdrop.com/users/paulmck/scalability/paper/LinuxMM.2016.10.04c.LCE.pdf">2016 LinuxCon EU</a>
> + presentation.
> </font></td></tr>
> <tr><td> </td></tr>
> </table>
> --
> 2.5.2
>
--
Pranith
^ permalink raw reply
* Re: [PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale
From: Linus Walleij @ 2016-11-14 16:58 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Lars-Peter Clausen, Eva Rachel Retuya, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org, Michael Hennerich, Hartmut Knaack,
Peter Meerwald, Greg KH
In-Reply-To: <c9a4b2b3-6c4b-4c3c-da79-eba8398a5a0d@kernel.org>
On Sat, Nov 12, 2016 at 3:24 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> Is it just me who thought, we need a fixed GPI like a fixed regulator?
> Would allow this sort of fixed wiring to be simply defined.
>
> Linus, worth exploring?
So if fixed regulator is for a voltage provider, this would be
pretty much the inverse: deciding for a voltage range by switching
a GPIO.
No previous experience with that, it should be outside of the
GPIO subsystem for sure...
Yours,
Linus Walleij
^ permalink raw reply
* Re: Calculate average latencies on the fly
From: Clark Williams @ 2016-11-14 16:58 UTC (permalink / raw)
To: Piotr Gregor; +Cc: Mathieu Poirier, John Kacur, linux-rt-users
In-Reply-To: <CAK+oA4ViNMd-8bKxuP82=bq_c6SopxwyR_8-Uu3uEBO3OC4GZg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 602 bytes --]
On Mon, 14 Nov 2016 16:11:58 +0000
Piotr Gregor <piotrgregor@rsyncme.org> wrote:
> Hi Mathieu,
>
> I am newer most likely - many thanks for your advise.
>
> cheers,
> Piotr
> --
Luckily this list is *much* lower traffic than LKML and we're not quite as strict as they are, since we don't have the volume of patches to deal with.
That being said, very good advice and I'll make a note to follow it :)
Piotr, John Kacur or I will look at adding in your patch to cyclictest shortly. Thanks for the submission.
--
United States Coast Guard
Ruining Natural Selection since 1790
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-binding: remoteproc: venus rproc dt binding document
From: Rob Herring @ 2016-11-14 16:58 UTC (permalink / raw)
To: Stanimir Varbanov
Cc: Ohad Ben-Cohen, Bjorn Andersson, Stephen Boyd, Andy Gross,
Mark Rutland, Srinivas Kandagatla, linux-remoteproc, linux-kernel,
linux-arm-msm, linux-soc, devicetree
In-Reply-To: <1478539853-23218-3-git-send-email-stanimir.varbanov@linaro.org>
On Mon, Nov 07, 2016 at 07:30:52PM +0200, Stanimir Varbanov wrote:
> Add devicetree binding document for Venus remote processor.
>
> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
> ---
> .../devicetree/bindings/remoteproc/qcom,venus.txt | 33 ++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt b/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
> new file mode 100644
> index 000000000000..06a2db60fa38
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
> @@ -0,0 +1,33 @@
> +Qualcomm Venus Peripheral Image Loader
> +
> +This document defines the binding for a component that loads and boots firmware
> +on the Qualcomm Venus remote processor core.
> +
> +- compatible:
> + Usage: required
> + Value type: <string>
> + Definition: must contain "qcom,venus-pil"
> +
> +- memory-region:
> + Usage: required
> + Value type: <phandle>
> + Definition: a phandle to a node describing reserved memory
> +
> +* An example
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + venus_mem: venus@89900000 {
> + compatible = "shared-dma-pool";
> + reg = <0x0 0x89900000 0x0 0x800000>;
> + alignment = <0x1000>;
> + no-map;
> + };
> + };
> +
> + rproc_venus@0 {
s/_/-/
With that,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH tip/core/rcu 6/7] rcu: Make expedited grace periods recheck dyntick idle state
From: Paul E. McKenney @ 2016-11-14 16:57 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, dvhart, fweisbec, oleg,
bobby.prani, Paul E. McKenney
In-Reply-To: <20161114165648.GA15216@linux.vnet.ibm.com>
Expedited grace periods check dyntick-idle state, and avoid sending
IPIs to idle CPUs, including those running guest OSes, and, on NOHZ_FULL
kernels, nohz_full CPUs. However, the kernel has been observed checking
a CPU while it was non-idle, but sending the IPI after it has gone
idle. This commit therefore rechecks idle state immediately before
sending the IPI, refraining from IPIing CPUs that have since gone idle.
Reported-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
kernel/rcu/tree.h | 1 +
kernel/rcu/tree_exp.h | 12 +++++++++++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index e99a5234d9ed..fe98dd24adf8 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -404,6 +404,7 @@ struct rcu_data {
atomic_long_t exp_workdone1; /* # done by others #1. */
atomic_long_t exp_workdone2; /* # done by others #2. */
atomic_long_t exp_workdone3; /* # done by others #3. */
+ int exp_dynticks_snap; /* Double-check need for IPI. */
/* 7) Callback offloading. */
#ifdef CONFIG_RCU_NOCB_CPU
diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
index 24343eb87b58..d3053e99fdb6 100644
--- a/kernel/rcu/tree_exp.h
+++ b/kernel/rcu/tree_exp.h
@@ -358,8 +358,10 @@ static void sync_rcu_exp_select_cpus(struct rcu_state *rsp,
struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu);
struct rcu_dynticks *rdtp = &per_cpu(rcu_dynticks, cpu);
+ rdp->exp_dynticks_snap =
+ atomic_add_return(0, &rdtp->dynticks);
if (raw_smp_processor_id() == cpu ||
- !(atomic_add_return(0, &rdtp->dynticks) & 0x1) ||
+ !(rdp->exp_dynticks_snap & 0x1) ||
!(rnp->qsmaskinitnext & rdp->grpmask))
mask_ofl_test |= rdp->grpmask;
}
@@ -377,9 +379,17 @@ static void sync_rcu_exp_select_cpus(struct rcu_state *rsp,
/* IPI the remaining CPUs for expedited quiescent state. */
for_each_leaf_node_possible_cpu(rnp, cpu) {
unsigned long mask = leaf_node_cpu_bit(rnp, cpu);
+ struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu);
+ struct rcu_dynticks *rdtp = &per_cpu(rcu_dynticks, cpu);
+
if (!(mask_ofl_ipi & mask))
continue;
retry_ipi:
+ if (atomic_add_return(0, &rdtp->dynticks) !=
+ rdp->exp_dynticks_snap) {
+ mask_ofl_test |= mask;
+ continue;
+ }
ret = smp_call_function_single(cpu, func, rsp, 0);
if (!ret) {
mask_ofl_ipi &= ~mask;
--
2.5.2
^ permalink raw reply related
* [PATCH tip/core/rcu 4/7] rcu: RCU_TRACE enables event tracing as well as debugfs
From: Paul E. McKenney @ 2016-11-14 16:57 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, dvhart, fweisbec, oleg,
bobby.prani, Nikolay Borisov, Paul E. McKenney
In-Reply-To: <20161114165648.GA15216@linux.vnet.ibm.com>
From: Nikolay Borisov <kernel@kyup.com>
The commit brings the RCU_TRACE Kconfig option's help text up to date
by noting that it enables additional event tracing as well as debugfs.
Signed-off-by: Nikolay Borisov <kernel@kyup.com>
[ paulmck: Do some wordsmithing. ]
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
lib/Kconfig.debug | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 33bc56cf60d7..4a431f18f218 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1430,7 +1430,8 @@ config RCU_TRACE
select TRACE_CLOCK
help
This option provides tracing in RCU which presents stats
- in debugfs for debugging RCU implementation.
+ in debugfs for debugging RCU implementation. It also enables
+ additional tracepoints for ftrace-style event tracing.
Say Y here if you want to enable RCU tracing
Say N if you are unsure.
--
2.5.2
^ permalink raw reply related
* [PATCH tip/core/rcu 5/7] torture: Trace long read-side delays
From: Paul E. McKenney @ 2016-11-14 16:57 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, dvhart, fweisbec, oleg,
bobby.prani, Paul E. McKenney
In-Reply-To: <20161114165648.GA15216@linux.vnet.ibm.com>
Although rcutorture will occasionally do a 50-millisecond grace-period
delay, these delays are quite rare. And rightly so, because otherwise
the read rate would be quite low. Thie means that it can be important
to identify whether or not a given run contained a long-delay read.
This commit therefore inserts a trace_rcu_torture_read() event to flag
runs containing long delays.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
include/trace/events/rcu.h | 5 ++++-
kernel/rcu/rcutorture.c | 11 ++++++++++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h
index d3e756539d44..b31e05bc8e26 100644
--- a/include/trace/events/rcu.h
+++ b/include/trace/events/rcu.h
@@ -698,7 +698,10 @@ TRACE_EVENT(rcu_batch_end,
/*
* Tracepoint for rcutorture readers. The first argument is the name
* of the RCU flavor from rcutorture's viewpoint and the second argument
- * is the callback address.
+ * is the callback address. The third callback is the start time in
+ * seconds, and the last two arguments are the grace period numbers
+ * and the beginning and end of the read, respectively. Note that the
+ * callback address can be NULL.
*/
TRACE_EVENT(rcu_torture_read,
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index bf08fee53dc7..87c51225ceec 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -289,15 +289,24 @@ static int rcu_torture_read_lock(void) __acquires(RCU)
static void rcu_read_delay(struct torture_random_state *rrsp)
{
+ unsigned long started;
+ unsigned long completed;
const unsigned long shortdelay_us = 200;
const unsigned long longdelay_ms = 50;
+ unsigned long long ts;
/* We want a short delay sometimes to make a reader delay the grace
* period, and we want a long delay occasionally to trigger
* force_quiescent_state. */
- if (!(torture_random(rrsp) % (nrealreaders * 2000 * longdelay_ms)))
+ if (!(torture_random(rrsp) % (nrealreaders * 2000 * longdelay_ms))) {
+ started = cur_ops->completed();
+ ts = rcu_trace_clock_local();
mdelay(longdelay_ms);
+ completed = cur_ops->completed();
+ do_trace_rcu_torture_read(cur_ops->name, NULL, ts,
+ started, completed);
+ }
if (!(torture_random(rrsp) % (nrealreaders * 2 * shortdelay_us)))
udelay(shortdelay_us);
#ifdef CONFIG_PREEMPT
--
2.5.2
^ permalink raw reply related
* [PATCH tip/core/rcu 3/7] rcu: Remove obsolete comment from __call_rcu()
From: Paul E. McKenney @ 2016-11-14 16:57 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, dvhart, fweisbec, oleg,
bobby.prani, Paul E. McKenney
In-Reply-To: <20161114165648.GA15216@linux.vnet.ibm.com>
The __call_rcu() comment about opportunistically noting grace period
beginnings and endings is obsolete. RCU still does such opportunistic
noting, but in __call_rcu_core() rather than __call_rcu(), and there
already is an appropriate comment in __call_rcu_core(). This commit
therefore removes the obsolete comment.
Reported-by: Michalis Kokologiannakis <mixaskok@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
kernel/rcu/tree.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index d52780024f9f..865af187498e 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3131,13 +3131,6 @@ __call_rcu(struct rcu_head *head, rcu_callback_t func,
}
head->func = func;
head->next = NULL;
-
- /*
- * Opportunistically note grace-period endings and beginnings.
- * Note that we might see a beginning right after we see an
- * end, but never vice versa, since this CPU has to pass through
- * a quiescent state betweentimes.
- */
local_irq_save(flags);
rdp = this_cpu_ptr(rsp->rda);
--
2.5.2
^ permalink raw reply related
* [PATCH RFC 3/2] ARM: improve arch_irq_work_has_interrupt()
From: Russell King - ARM Linux @ 2016-11-14 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2e14b943-e3a5-6993-48c7-68200c8b08a2@arm.com>
On Mon, Nov 14, 2016 at 04:30:57PM +0000, Marc Zyngier wrote:
> Hi Russell,
>
> On 14/11/16 15:36, Russell King - ARM Linux wrote:
> > Following on from the previous patch, I think this makes more sense to
> > determine whether we can support IRQ work interrupts.
> >
> > Whether we can support them or not depends on two things:
> >
> > (a) whether the kernel has support for receiving IPIs
> > (b) whether it's possible to send an IPI to CPUs including the raising CPU.
> >
> > (a) is a function of how the kernel is built - and in the case of ARM, it
> > depends whether the kernel is built with SMP enabled or not.
> > (b) is a property of the interrupt controller.
> >
> > It hasn't ever been a function of the CPU or architecture.
> >
> > Commit 059e232089e4 ("irqchip/gic: Allow self-SGIs for SMP on UP
> > configurations") changes the GIC IPI code such that we can raise
> > SGIs on uniprocessor systems running on a SMP kernel, which means
> > we can support IRQ work interrupts here as well.
> >
> > So, we shouldn't be using cpu_smp() (or its previous is_smp() here
> > at all. Use a flag to indicate whether we can IPI and use that to
> > indicate whether we support irq work interrupts.
> >
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > ---
> > arch/arm/include/asm/irq_work.h | 11 +++++++++--
> > arch/arm/kernel/irq.c | 0
> > arch/arm/kernel/smp.c | 3 +++
> > drivers/irqchip/irq-gic.c | 17 +++++++++++++----
> > 4 files changed, 25 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/irq_work.h b/arch/arm/include/asm/irq_work.h
> > index 2dc8d7995b48..d7262a3c2f2e 100644
> > --- a/arch/arm/include/asm/irq_work.h
> > +++ b/arch/arm/include/asm/irq_work.h
> > @@ -1,11 +1,18 @@
> > #ifndef __ASM_ARM_IRQ_WORK_H
> > #define __ASM_ARM_IRQ_WORK_H
> >
> > -#include <asm/smp_plat.h>
> > +extern bool irq_controller_can_ipi;
> > +#define irq_controller_can_ipi irq_controller_can_ipi
> >
> > static inline bool arch_irq_work_has_interrupt(void)
> > {
> > - return cpu_smp();
> > +#ifdef CONFIG_SMP
> > + /* This depends on the IRQ controller */
> > + return irq_controller_can_ipi;
> > +#else
> > + /* The kernel is not built to support IPIs */
> > + return false;
> > +#endif
> > }
> >
> > #endif /* _ASM_ARM_IRQ_WORK_H */
> > diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> > index 7dd14e8395e6..1fa9412cc4aa 100644
> > --- a/arch/arm/kernel/smp.c
> > +++ b/arch/arm/kernel/smp.c
> > @@ -473,6 +473,9 @@ void __init set_smp_cross_call(void (*fn)(const struct cpumask *, unsigned int))
> > __smp_cross_call = fn;
> > }
> >
> > +/* This indicates whether the IRQ controller can IPI (including self-IPI) */
> > +bool irq_controller_can_ipi;
>
> We probably need to initialize this to false, since we have at least 4
> other users of set_smp_cross_call() in the tree.
C programming 101: BSS variables are initialised to zero at the start
of the program.
> > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> > index d6c404b3584d..abe8d5807c0f 100644
> > --- a/drivers/irqchip/irq-gic.c
> > +++ b/drivers/irqchip/irq-gic.c
> > @@ -1187,9 +1187,6 @@ static int __init __gic_init_bases(struct gic_chip_data *gic,
> > */
> > for (i = 0; i < NR_GIC_CPU_IF; i++)
> > gic_cpu_map[i] = 0xff;
> > -#ifdef CONFIG_SMP
> > - set_smp_cross_call(gic_raise_softirq);
> > -#endif
> > cpuhp_setup_state_nocalls(CPUHP_AP_IRQ_GIC_STARTING,
> > "AP_IRQ_GIC_STARTING",
> > gic_starting_cpu, NULL);
> > @@ -1207,8 +1204,20 @@ static int __init __gic_init_bases(struct gic_chip_data *gic,
> > }
> >
> > ret = gic_init_bases(gic, irq_start, handle);
> > - if (ret)
> > + if (ret) {
> > kfree(name);
> > + return ret;
> > + }
> > +
> > + if (gic == &gic_data[0]) {
> > +#ifdef CONFIG_SMP
> > + set_smp_cross_call(gic_raise_softirq);
> > +#ifdef irq_controller_can_ipi
> > + if (nr_cpu_ids == 1 || hweight8(gic_cpu_map[0]) == 1)
> > + irq_controller_can_ipi = true;
>
> Am I missing something, or is there any sane configuration where this
> isn't true?
I hope not, but I want to duplicate here the conditions where
gic_raise_softirq() actually _works_ so we stop running into corner
cases where we get "irq work fails" etc.
> Also, maybe it would make some sense to have a more
> streamlined interface to the architecture code. Something along the
> lines of:
>
> diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
> index 3d6dc8b..45612d2 100644
> --- a/arch/arm/include/asm/smp.h
> +++ b/arch/arm/include/asm/smp.h
> @@ -48,6 +48,16 @@ extern void smp_init_cpus(void);
> */
> extern void set_smp_cross_call(void (*)(const struct cpumask *, unsigned int));
>
> +#ifdef CONFIG_SMP
> +#define setup_smp_ipi(f,i) \
> + do { \
> + set_smp_cross_call(f); \
> + irq_controller_can_ipi = (i); \
> + } while(0)
> +#else
> +#define setup_smp_ipi(f,i) do { } while (0)
> +#endif
> +
> /*
> * Called from platform specific assembly code, this is the
> * secondary CPU entry point.
>
> with the similar entry point for arm64?
I'd prefer to keep the two things separate, but we should definitely
provide a stub for set_smp_cross_call() for when SMP is disabled.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
From: Auger Eric @ 2016-11-14 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114162037.GC14829@8bytes.org>
Hi Joerg,
On 14/11/2016 17:20, Joerg Roedel wrote:
> On Mon, Nov 14, 2016 at 05:08:16PM +0100, Auger Eric wrote:
>> There are potentially several MSI doorbell physical pages in the SOC
>> that are accessed through the IOMMU (translated). Each of those must
>> have a corresponding IOVA and IOVA/PA mapping programmed in the IOMMU.
>> Else MSI will fault.
>>
>> - step 1 was to define a usable IOVA range for MSI mapping. So now we
>> decided the base address and size would be hardcoded for ARM. The
>> get_dm_region can be used to retrieve that hardcoded region.
>> - Step2 is to allocate IOVAs within that range and map then for each of
>> those MSI doorbells. This is done in the MSI controller compose() callback.
>>
>> I hope I succeeded in clarifying this time.
>>
>> Robin sent today a new version of its cookie think using a dummy
>> allocator. I am currently integrating it.
>
> Okay, I understand. A simple bitmap-allocator would probably be
> sufficient, and doesn't have the overhead the iova allocator has. About
> how many pages are we talking here?
Very few actually. In the systems I have access to I only have a single
page. In most advanced systems we could imagine per-cpu doorbells but
this does not exist yet as far as I know.
Thanks
Eric
>
>
> Joerg
>
^ permalink raw reply
* Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
From: Auger Eric @ 2016-11-14 16:57 UTC (permalink / raw)
To: Joerg Roedel
Cc: drjones, alex.williamson, jason, kvm, marc.zyngier, punit.agrawal,
will.deacon, linux-kernel, diana.craciun, iommu,
pranav.sawargaonkar, christoffer.dall, tglx, robin.murphy,
linux-arm-kernel, eric.auger.pro
In-Reply-To: <20161114162037.GC14829@8bytes.org>
Hi Joerg,
On 14/11/2016 17:20, Joerg Roedel wrote:
> On Mon, Nov 14, 2016 at 05:08:16PM +0100, Auger Eric wrote:
>> There are potentially several MSI doorbell physical pages in the SOC
>> that are accessed through the IOMMU (translated). Each of those must
>> have a corresponding IOVA and IOVA/PA mapping programmed in the IOMMU.
>> Else MSI will fault.
>>
>> - step 1 was to define a usable IOVA range for MSI mapping. So now we
>> decided the base address and size would be hardcoded for ARM. The
>> get_dm_region can be used to retrieve that hardcoded region.
>> - Step2 is to allocate IOVAs within that range and map then for each of
>> those MSI doorbells. This is done in the MSI controller compose() callback.
>>
>> I hope I succeeded in clarifying this time.
>>
>> Robin sent today a new version of its cookie think using a dummy
>> allocator. I am currently integrating it.
>
> Okay, I understand. A simple bitmap-allocator would probably be
> sufficient, and doesn't have the overhead the iova allocator has. About
> how many pages are we talking here?
Very few actually. In the systems I have access to I only have a single
page. In most advanced systems we could imagine per-cpu doorbells but
this does not exist yet as far as I know.
Thanks
Eric
>
>
> Joerg
>
^ permalink raw reply
* [PATCH tip/core/rcu 1/7] rcu: Tighten up __call_rcu() rcu_head alignment check
From: Paul E. McKenney @ 2016-11-14 16:57 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, dvhart, fweisbec, oleg,
bobby.prani, Paul E. McKenney
In-Reply-To: <20161114165648.GA15216@linux.vnet.ibm.com>
Commit 720abae3d68ae ("rcu: force alignment on struct
callback_head/rcu_head") forced the rcu_head (AKA callback_head)
structure's alignment to pointer size, that is, to 4-byte boundaries on
32-bit systems and to 8-byte boundaries on 64-bit systems. This
commit therefore checks for this same alignment in __call_rcu(),
which used to contain a looser check for two-byte alignment.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
kernel/rcu/tree.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 69a5611a7e7c..37e4f7d2be0c 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3121,7 +3121,9 @@ __call_rcu(struct rcu_head *head, rcu_callback_t func,
unsigned long flags;
struct rcu_data *rdp;
- WARN_ON_ONCE((unsigned long)head & 0x1); /* Misaligned rcu_head! */
+ /* Misaligned rcu_head! */
+ WARN_ON_ONCE((unsigned long)head & (sizeof(void *) - 1));
+
if (debug_rcu_head_queue(head)) {
/* Probable double call_rcu(), so leak the callback. */
WRITE_ONCE(head->func, rcu_leak_callback);
--
2.5.2
^ permalink raw reply related
* [PATCH tip/core/rcu 2/7] rcu: Remove obsolete rcu_check_callbacks() header comment
From: Paul E. McKenney @ 2016-11-14 16:57 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, dvhart, fweisbec, oleg,
bobby.prani, Paul E. McKenney
In-Reply-To: <20161114165648.GA15216@linux.vnet.ibm.com>
In the deep past, rcu_check_callbacks() was only invoked if rcu_pending()
returned true. Which was fine, but these days rcu_check_callbacks()
is invoked unconditionally. This commit therefore removes the obsolete
sentence from the header comment.
Reported-by: Michalis Kokologiannakis <mixaskok@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
kernel/rcu/tree.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 37e4f7d2be0c..d52780024f9f 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2828,8 +2828,7 @@ static void rcu_do_batch(struct rcu_state *rsp, struct rcu_data *rdp)
* Also schedule RCU core processing.
*
* This function must be called from hardirq context. It is normally
- * invoked from the scheduling-clock interrupt. If rcu_pending returns
- * false, there is no point in invoking rcu_check_callbacks().
+ * invoked from the scheduling-clock interrupt.
*/
void rcu_check_callbacks(int user)
{
--
2.5.2
^ permalink raw reply related
* [PATCH tip/core/rcu 7/7] rcu: Don't kick unless grace period or request
From: Paul E. McKenney @ 2016-11-14 16:57 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, dvhart, fweisbec, oleg,
bobby.prani, Paul E. McKenney
In-Reply-To: <20161114165648.GA15216@linux.vnet.ibm.com>
The current code can result in spurious kicks when there are no grace
periods in progress and no grace-period-related requests. This is
sort of OK for a diagnostic aid, but the resulting ftrace-dump messages
in dmesg are annoying. This commit therefore avoids spurious kicks
in the common case.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
kernel/rcu/tree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 865af187498e..96c52e43f7ca 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1304,7 +1304,8 @@ static void rcu_stall_kick_kthreads(struct rcu_state *rsp)
if (!rcu_kick_kthreads)
return;
j = READ_ONCE(rsp->jiffies_kick_kthreads);
- if (time_after(jiffies, j) && rsp->gp_kthread) {
+ if (time_after(jiffies, j) && rsp->gp_kthread &&
+ (rcu_gp_in_progress(rsp) || READ_ONCE(rsp->gp_flags))) {
WARN_ONCE(1, "Kicking %s grace-period kthread\n", rsp->name);
rcu_ftrace_dump(DUMP_ALL);
wake_up_process(rsp->gp_kthread);
--
2.5.2
^ permalink raw reply related
* [PATCH tip/core/rcu 0/7] Miscellaneous fixes for 4.10
From: Paul E. McKenney @ 2016-11-14 16:56 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, dvhart, fweisbec, oleg,
bobby.prani
Hello!
This series contains miscellaneous fixes to RCU:
1. Tighten up __call_rcu's alignment check for the rcu_head structure
now that no arch does two-byte alignment of pointers.
2. Remove obsolete comment about when rcu_check_callbacks() was invoked.
3. Remove obsolete comment about which function opportunistically
notes grace periods beginnings and endings.
4. Update the RCU_TRACE Kconfig option's help text to note that
it enables event tracing in addition to debugfs, courtesy of
Nikolay Borisov.
5. Add event tracing for long read-side delays in rcutorture
in order to better debug too-short grace periods.
6. Make expedited grace periods recheck dyntick-idle state to avoid
sending needless IPIs.
7. Don't kick CPUs unless there is grace-period activity currently
in progress.
Thanx, Paul
------------------------------------------------------------------------
include/trace/events/rcu.h | 5 ++++-
kernel/rcu/rcutorture.c | 11 ++++++++++-
kernel/rcu/tree.c | 17 ++++++-----------
kernel/rcu/tree.h | 1 +
kernel/rcu/tree_exp.h | 12 +++++++++++-
lib/Kconfig.debug | 3 ++-
6 files changed, 34 insertions(+), 15 deletions(-)
^ permalink raw reply
* [U-Boot] [PATCH] drivers: SPI: sunxi SPL: fix warning
From: Tom Rini @ 2016-11-14 16:56 UTC (permalink / raw)
To: u-boot
In-Reply-To: <6df01a4b-10a8-6fc0-4105-de2d64b30221@arm.com>
On Mon, Nov 14, 2016 at 04:47:26PM +0000, Andre Przywara wrote:
> Hi,
>
> On 14/11/16 16:30, Jagan Teki wrote:
> > On Thu, Nov 3, 2016 at 6:28 AM, Andre Przywara <andre.przywara@arm.com> wrote:
> >> Somehow an int returning function without a return statement sneaked
> >> in. Fix it.
> >>
> >> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> >> ---
> >> drivers/mtd/spi/sunxi_spi_spl.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/mtd/spi/sunxi_spi_spl.c b/drivers/mtd/spi/sunxi_spi_spl.c
> >> index 67c7edd..7502314 100644
> >> --- a/drivers/mtd/spi/sunxi_spi_spl.c
> >> +++ b/drivers/mtd/spi/sunxi_spi_spl.c
> >> @@ -158,9 +158,10 @@ static void spi0_disable_clock(void)
> >> (1 << AHB_RESET_SPI0_SHIFT));
> >> }
> >>
> >> -static int spi0_init(void)
> >> +static void spi0_init(void)
> >> {
> >> unsigned int pin_function = SUNXI_GPC_SPI0;
> >> +
> >
> > Space not needed or unrelated, please remove this.
>
> This is Linux coding style, which U-Boot adheres to.
> "WARNING: Missing a blank line after declarations"
>
> I thought I should fix this since this is was in the context of this
> very simple patch and it improves readability.
> If this is too much, then please remove the line before committing.
Making things checkpatch clean is good, in the future please also
mention that in commit messages. Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161114/57c0e803/attachment.sig>
^ permalink raw reply
* Can't get nftables ct mark to trigger iproute rule
From: Øyvind Kaurstad @ 2016-11-14 16:56 UTC (permalink / raw)
To: netfilter
Hi,
I have spent a lot of time investigating this myself, and I believe what
I am trying should have worked, so I am now at a dead end.
I have a custom Linux machine (kernel version 4.1.6), which has two
physical ethernet interfaces and one ppp interface.
Here's the setup (with fictious IP addresses):
eth0 has IP 192.168.10.10
eth1 has IP 192.168.100.10
ppp0 has IP 10.10.10.10
eth0 is connected to the local LAN, while eth1 is connected to a network
of different devices. ppp0 is connected to a remote network.
Please note that the address of the ppp interface is not static, it
changes frequently (at the whim of the mobile operator).
In the eth1 network there is a server with IP 192.168.100.1, and this
server listens to UDP ports 41000-41002. I need to be able to
communicate with this server both via eth0 and ppp0. Incoming packets to
either of these interfaces will therefore need to be DNATed to reach
this host.
So, here's my initial nftables config:
table ip firewall {
chain incoming {
type filter hook input priority 0; policy drop;
ct state established,related accept
iifname "lo" accept
icmp type echo-request accept
tcp dport { ssh} accept
}
chain prerouting {
type nat hook prerouting priority 0; policy accept;
iifname "ppp0" udp dport 41000-41002 dnat 192.168.100.1
iifname "eth0" udp dport 41000-41002 dnat 192.168.100.1
}
chain postrouting {
type nat hook postrouting priority 100; policy accept;
oifname != "lo" masquerade
}
}
My routing rules for iproute2 looks like this (the rule with prio 2000
is updated whenever the ppp address changes):
0: from all lookup local
1000: from 192.168.100.1 lookup ppproute
2000: from 10.10.10.10 lookup ppproute
32766: from all lookup main
32767: from all lookup default
And the ppproute table only contains a default route over ppp0:
default dev ppp0 scope link
With this setup, everything works correctly if the inbound traffic comes
in over ppp0. Packets are correctly rewritten by nftables/netfilter, and
exits out eth1. The return traffic hits the 1000 rule, and exits back to
the sender.
If the traffic comes in over eth0, it also hits the host at
192.168.100.1 as it should, but the return traffic is also routed back
out over ppp0, which is my problem. I obviously need those packets to go
back out eth0 to reach the client.
Since I have masquerading enabled for all but the lo interface, the
packets coming back from the host at 192.168.100.1 has a destination
address of 192.168.100.10. The 1000 rule works because it takes any
traffic coming from 192.168.100.1 and sends it to ppp0. This is clearly
the wrong approach, as I also need to be able to talk to the server over
eth0.
To be able to distinguish the traffic that comes in over ppp0, I tried
to change the DNAT rule for traffic from ppp0 to this:
iifname "ppp0" udp dport 41000-41002 ct mark set 0x1 dnat 192.168.100.1
...and then I changed the ip rules to this:
Code:
0: from all lookup local
1000: from 192.168.100.1 fwmark 0x01 lookup ppproute
2000: from 10.10.10.10 lookup ppproute
32766: from all lookup main
32767: from all lookup default
Now I can communicate over eth0, but if the traffic comes in over ppp0,
the return traffic also goes back out eth0, so rule 1000 isn't being hit.
When I check the connection track entry, I see this:
udp 17 25 src=10.11.12.13 dst=10.10.10.10 sport=34624 dport=41000
src=192.168.100.1 dst=192.168.100.10 sport=41000 dport=34624 mark=1 use=1
The connection is marked with 0x01 as dictated by the DNAT rule, and the
server replied as it should. However, the routing rule that should
trigger on the mark isn't hit.
I also added a forward chain with counters to see if packets was marked,
and the counters were hit.
In other words, return traffic traversing the forward chain was
correctly marked, so I can't understand why the routing rule doesn't
send the traffic back out ppp0.
rp_filtering is turned off for all interfaces, and forwarding is enabled.
--
________________________________________________
Øyvind Kaurstad, Grutlekleiva 16, 5517 Haugesund
Tlf: 52 72 41 98, Mob: 990 86 990
Email: oyvind@dynator.no
^ permalink raw reply
* Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode
From: Stefan Hajnoczi @ 2016-11-14 16:56 UTC (permalink / raw)
To: Karl Rister
Cc: Fam Zheng, Andrew Theurer, Paolo Bonzini, qemu-devel,
Stefan Hajnoczi
In-Reply-To: <5829CFA5.3060605@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2600 bytes --]
On Mon, Nov 14, 2016 at 08:52:21AM -0600, Karl Rister wrote:
> On 11/14/2016 07:53 AM, Fam Zheng wrote:
> > On Fri, 11/11 13:59, Karl Rister wrote:
> >>
> >> Stefan
> >>
> >> I ran some quick tests with your patches and got some pretty good gains,
> >> but also some seemingly odd behavior.
> >>
> >> These results are for a 5 minute test doing sequential 4KB requests from
> >> fio using O_DIRECT, libaio, and IO depth of 1. The requests are
> >> performed directly against the virtio-blk device (no filesystem) which
> >> is backed by a 400GB NVme card.
> >>
> >> QEMU_AIO_POLL_MAX_NS IOPs
> >> unset 31,383
> >> 1 46,860
> >> 2 46,440
> >> 4 35,246
> >> 8 34,973
> >> 16 46,794
> >> 32 46,729
> >> 64 35,520
> >> 128 45,902
> >
> > For sequential read with ioq=1, each request takes >20000ns under 45,000 IOPs.
> > Isn't a poll time of 128ns a mismatching order of magnitude? Have you tried
> > larger values? Not criticizing, just trying to understand how it workd.
>
> Not yet, I was just trying to get something out as quick as I could
> (while juggling this with some other stuff...). Frankly I was a bit
> surprised that the low values made such an impact and then got
> distracted by the behaviors of 4, 8, and 64.
>
> >
> > Also, do you happen to have numbers for unpatched QEMU (just to confirm that
> > "unset" case doesn't cause regression) and baremetal for comparison?
>
> I didn't run this exact test on the same qemu.git master changeset
> unpatched. I did however previously try it against the v2.7.0 tag and
> got somewhere around 27.5K IOPs. My original intention was to apply the
> patches to v2.7.0 but it wouldn't build.
>
> We have done a lot of testing and tracing on the qemu-rhev package and
> 27K IOPs is about what we see there (with tracing disabled).
>
> Given the patch discussions I saw I was mainly trying to get a sniff
> test out and then do a more complete workup with whatever updates are made.
>
> I should probably note that there are a lot of pinning optimizations
> made here to assist in our tracing efforts which also result in improved
> performance. Ultimately, in a proper evaluation of these patches most
> of that will be removed so the behavior may change somewhat.
To clarify: QEMU_AIO_POLL_MAX_NS unset or 0 disables polling completely.
Therefore it's not necessary to run unpatched.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH] bsg: Add sparse annotations to bsg_request_fn()
From: Jens Axboe @ 2016-11-14 16:56 UTC (permalink / raw)
To: Bart Van Assche; +Cc: linux-block@vger.kernel.org
In-Reply-To: <b8f96aed-5cd5-26f0-5c14-4f1ace05dd51@sandisk.com>
On 11/14/2016 09:55 AM, Bart Van Assche wrote:
> On 09/25/2016 07:54 PM, Bart Van Assche wrote:
>> Avoid that sparse complains about unbalanced lock actions.
>>
>> Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
>> ---
>> block/bsg-lib.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/block/bsg-lib.c b/block/bsg-lib.c
>> index 650f427..b2a61e3 100644
>> --- a/block/bsg-lib.c
>> +++ b/block/bsg-lib.c
>> @@ -161,6 +161,8 @@ failjob_rls_job:
>> * Drivers/subsys should pass this to the queue init function.
>> */
>> void bsg_request_fn(struct request_queue *q)
>> + __releases(q->queue_lock)
>> + __acquires(q->queue_lock)
>> {
>> struct device *dev = q->queuedata;
>> struct request *req;
>>
>
> Hi Jens,
>
> Do you agree with this patch? If so, can you queue it for kernel v4.10?
Yep, I'll add it for 4.10, thanks Bart.
--
Jens Axboe
^ permalink raw reply
* RE: [PATCH] drm/amdgpu: refine cz uvd clock gate logic.
From: Deucher, Alexander @ 2016-11-14 16:56 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org; +Cc: Zhu, Rex
In-Reply-To: <1478841892-30332-1-git-send-email-Rex.Zhu-5C7GfCeVMHo@public.gmane.org>
> -----Original Message-----
> From: amd-gfx [mailto:amd-gfx-bounces@lists.freedesktop.org] On Behalf
> Of Rex Zhu
> Sent: Friday, November 11, 2016 12:25 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex
> Subject: [PATCH] drm/amdgpu: refine cz uvd clock gate logic.
>
> sw clockgate was used on uvd6.0.
> when uvd is idle, we gate the uvd clock.
> when decode, we ungate the uvd clock.
>
> Change-Id: I79ecdc5d0f48e97919386a08acca994f1fa05484
> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Assuming clockgating still works properly:
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/cz_dpm.c | 6 ++----
> drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c | 4 ++--
> 2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/cz_dpm.c
> b/drivers/gpu/drm/amd/amdgpu/cz_dpm.c
> index 41fa351..ba2b66b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/cz_dpm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/cz_dpm.c
> @@ -2111,9 +2111,8 @@ static void cz_dpm_powergate_uvd(struct
> amdgpu_device *adev, bool gate)
>
> if (gate) {
> if (pi->caps_uvd_pg) {
> - /* disable clockgating so we can properly shut down
> the block */
> ret = amdgpu_set_clockgating_state(adev,
> AMD_IP_BLOCK_TYPE_UVD,
> -
> AMD_CG_STATE_UNGATE);
> +
> AMD_CG_STATE_GATE);
> if (ret) {
> DRM_ERROR("UVD DPM Power Gating failed
> to set clockgating state\n");
> return;
> @@ -2159,9 +2158,8 @@ static void cz_dpm_powergate_uvd(struct
> amdgpu_device *adev, bool gate)
> return;
> }
>
> - /* enable clockgating. hw will dynamically
> gate/ungate clocks on the fly */
> ret = amdgpu_set_clockgating_state(adev,
> AMD_IP_BLOCK_TYPE_UVD,
> -
> AMD_CG_STATE_GATE);
> +
> AMD_CG_STATE_UNGATE);
> if (ret) {
> DRM_ERROR("UVD DPM Power Gating Failed
> to set clockgating state\n");
> return;
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c
> index 2028980..b0c63c5 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c
> @@ -169,7 +169,7 @@ int cz_dpm_powergate_uvd(struct pp_hwmgr
> *hwmgr, bool bgate)
> if (bgate) {
> cgs_set_clockgating_state(hwmgr->device,
> AMD_IP_BLOCK_TYPE_UVD,
> - AMD_CG_STATE_UNGATE);
> + AMD_CG_STATE_GATE);
> cgs_set_powergating_state(hwmgr->device,
> AMD_IP_BLOCK_TYPE_UVD,
> AMD_PG_STATE_GATE);
> @@ -182,7 +182,7 @@ int cz_dpm_powergate_uvd(struct pp_hwmgr
> *hwmgr, bool bgate)
> AMD_CG_STATE_UNGATE);
> cgs_set_clockgating_state(hwmgr->device,
> AMD_IP_BLOCK_TYPE_UVD,
> - AMD_PG_STATE_GATE);
> + AMD_PG_STATE_UNGATE);
> cz_dpm_update_uvd_dpm(hwmgr, false);
> }
>
> --
> 1.9.1
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"
From: Sharma, Shashank @ 2016-11-14 16:56 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Jose Abreu, Jia, Lin A, Akashdeep Sharma, Emil Velikov, dri-devel,
Daniel Vetter, Jim Bride
In-Reply-To: <20161114164518.GA31595@intel.com>
On 11/14/2016 10:15 PM, Ville Syrjälä wrote:
> On Mon, Nov 14, 2016 at 10:12:04PM +0530, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 11/14/2016 9:50 PM, Ville Syrjälä wrote:
>>> On Mon, Nov 14, 2016 at 09:37:18PM +0530, Sharma, Shashank wrote:
>>>> Regards
>>>>
>>>> Shashank
>>>>
>>>>
>>>> On 11/14/2016 9:19 PM, Ville Syrjälä wrote:
>>>>> On Mon, Nov 14, 2016 at 08:14:34PM +0530, Sharma, Shashank wrote:
>>>>>> Regards
>>>>>> Shashank
>>>>>>> the revert:
>>>>>>>
>>>>>>> HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 700mm x 390mm
>>>>>>> - 1920x1080 60.00*+
>>>>>>> - 1920x1080i 60.00 50.00
>>>>>>> + 1920x1080 60.00*+ 50.00 59.94 30.00 25.00 24.00 29.97 23.98
>>>>>>> + 1920x1080i 60.00 50.00 59.94
>>>>>>> 1600x1200 60.00
>>>>>>> 1680x1050 59.88
>>>>>>> 1280x1024 75.02 60.02
>>>>>>> @@ -13,30 +13,29 @@
>>>>>>> 1360x768 60.02
>>>>>>> 1280x800 59.91
>>>>>>> 1152x864 75.00
>>>>>>> - 1280x720 60.00 50.00
>>>>>>> + 1280x720 60.00 50.00 59.94
>>>>>>> 1024x768 75.03 70.07 60.00
>>>>>>> 832x624 74.55
>>>>>>> 800x600 72.19 75.00 60.32
>>>>>>> - 640x480 75.00 72.81 66.67 59.94
>>>>>>> + 720x576 50.00
>>>>>>> + 720x480 60.00 59.94
>>>>>>> + 640x480 75.00 72.81 66.67 60.00 59.94
>>>>>>> 720x400 70.08
>>>>>> None of these aspect ratios are new modes / new aspect ratios from HDMI
>>>>>> 2.0/CEA-861-F
>>>>>> These are the existing modes, and should be independent of reverted
>>>>>> patches.
>>>>> They're affected because your patches changed them by adding the aspect
>>>>> ratio flags to them.
>>>> Yes, But they are independent of reverted patch, which adds aspect ratio
>>>> for HDMI 2.0 ratios (64:27 and 256:135)
>>> The second patch had to be reverted so that the first patch would revert
>>> cleanly.
>>>
>>>>>>> This was with sna, which does this:
>>>>>>> #define KNOWN_MODE_FLAGS ((1<<14)-1)
>>>>>>> if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS)
>>>>>>> mode->status = MODE_BAD; /* unknown flags => unhandled */
>>>>>>> so all the modes with an aspect ratio just vanished.
>>>>>>>
>>>>>>> -modesetting and -ati on the other hand just copy over the unknown
>>>>>>> bits into the xrandr mode structure, which sounds dubious at best:
>>>>>>> mode->Flags = kmode->flags; //& FLAG_BITS;
>>>>>>> I've not checked what damage it can actually cause.
>>>>>>>
>>>>>>>
>>>>>>> It looks like a few modes disappeared from the kernel's mode list
>>>>>>> as well, presumably because some cea modes in the list originated from
>>>>>>> DTDs and whanot so they don't have an aspect ratio and that causes
>>>>>>> add_alternate_cea_modes() to ignore them. So not populating an aspect
>>>>>>> ratio for cea modes originating from a source other than
>>>>>>> edid_cea_modes[] looks like another bug to me as well.
>>>>>> I am writing a patch series to cap the aspect ratio implementation under
>>>>>> a drm_cap_hdmi2_aspect_ratios
>>>>>> This is how its going to work (inspired from the 2D/stereo series from
>>>>>> damien L)
>>>>>>
>>>>>> - Add a new capability hdmi2_ar
>>>>> It should be just a generic "expose aspect ratio flags to userspace?"
>>>> Makes sense, in this way we can even revert the aspect_ratio property
>>>> for HDMI connector, as discussed during
>>>> the code review sessions of this patch series. In this way, when kernel
>>>> will expose the aspect ratios, it will either
>>>> do the aspect ratios as per EDID, or wont.
>>>>>> - by default parsing the new hdmi 2.0 aspect ratio will be disabled
>>>>>> under check of this cap
>>>>>> - during bootup time, while initializing the display, a userspace can
>>>>>> get_cap on the hdmi2_aspect_ratio
>>>>>> - If it wants HDMI 2.0 aspect ratio support, it will set the cap, and
>>>>>> kernel will expose these aspect ratios
>>>>>>> Another bug I think might be the ordering of the modes with aspect ratio
>>>>>>> specified. IIRC the spec says that the preferred aspect ratio should be
>>>>>>> listed first in the EDID, but I don't think we preserve that ordering
>>>>>>> in the final mode list. I guess we could fix that by somehow noting
>>>>>>> which aspect ratio is preferred and sort based on that, or we try to
>>>>>>> preserve the order from the EDID until we're ready to sort, and then do
>>>>>>> the sorting with a stable algorithm.
>>>>>> AFAIK The mode order and priority is decided and arranged in userspace,
>>>>>> based on various factors like
>>>>>> - preferred mode.
>>>>>> - previously applied mode in previous sessions (like for android tvs)
>>>>>> - Bigger h/w vs better refresh rate ?
>>>>>> - Xserver applies its own algorithms to decide which mode should be
>>>>>> shown first.
>>>>> Xorg does sort on its own. But since it doesn't know anything about
>>>>> aspect ratios and whatnot I wouldn't rely on that for anything. I
>>>>> also wouldn't expect eg. wayland compositors to do their own sorting.
>>>>> And yeah, looks like weston at least doesn't do any sorting whatsoever.
>>>>>
>>>>>> I dont think kernel needs to bother about it.
>>>>> So I'm going to say that we in fact do need to bother.
>>>>>
>>>> IMHO, making policies for UI is not a part of kernel design, a UI
>>>> manager (Hardware composed, X or Wayland) should take care of it, as
>>>> they have access to much information (Like previously applied mode, user
>>>> preference etc). When it comes to sorting of modes, the only general rule
>>>> across drivers like FB, V4L2, I have seen is the first mode in the list
>>>> should be preferred mode, which we are still keeping. And after that our
>>>> probed_modes were
>>>> anyways not sorted now, so it doesn't matter further.
>>> Having userspace be responsible for sorting the aspect ratios would
>>> perhaps require that userspace parses the EDID, which is pretty crazy.
>> Why ?
>> userspace has to just set cap for aspect ratio, and kernel can read
>> EDID, parse the CEA block, populate the aspect ratios flags
>> and add the modes (Just what this patch was doing, except the cap part)
>> Once userspace has the getResources/getConnector call filled, it can
>> access all the modes (with and without aspect) and do the sorting
>> in any way it wants.
>>> I guess it could try to deduce something from the physical aspect ratio
>>> of the display, but I'm not sure that's quite what we want either.
>>>
>>> Also we already sort the modes in the kernel anyway, so it's not like
>>> we'd be doing something new by also considering the aspect ratios.
>>> I would at the very least want to avoid a totally random order between
>>> modes that differ only by the aspect ratio.
>> Path: get_connector -> probe_single_connector_mode -> drm_add_edid_modes
>> Again, IMHO, we don't sort the modes in kernel, we populate modes in a
>> particular order, which is:
>> (From drm_edid.c::drm_add_edid_modes)
>> ##############################################################
>> /*
>> * EDID spec says modes should be preferred in this order:
>> * - preferred detailed mode
>> * - other detailed modes from base block
>> * - detailed modes from extension blocks
>> * - CVT 3-byte code modes
>> * - standard timing codes
>> * - established timing codes
>> * - modes inferred from GTF or CVT range information
>> *
>> * We get this pretty much right.
>> *
>> * XXX order for additional mode types in extension blocks?
>> */
>> num_modes += add_detailed_modes(connector, edid, quirks);
>> num_modes += add_cvt_modes(connector, edid);
>> num_modes += add_standard_modes(connector, edid);
>> num_modes += add_established_modes(connector, edid);
>> num_modes += add_cea_modes(connector, edid);
>> num_modes += add_alternate_cea_modes(connector, edid);
>> num_modes += add_displayid_detailed_modes(connector, edid);
>> ###############################################################
>>
>> Here the modes are added in the connector, in the same order they are
>> arranged into their respective blocks in EDID.
>> But the order to read the block is a preferred order (no sorting).
>>
>> Now, in this patch series, we are adding aspect ratio information in
>> edid_cea_modes db, which is going to affect only
>> add_cea/alternate_cea_modes() call, and the modes accordingly.
>> Please let me know if I misunderstood something here.
> We explicitly sort the modes after this.
>
In any case, I guess addition of a cap for aspect ratio should fix the
current objections for this implementation.
And I will keep it 0 by default, so that no aspect ratio information is
added until userspace sets the cap to 1 on its own.
Regards
Shashank
>> Regards
>> Shashank
>>>> If X server doesn't know what to do with aspect ratio flags, it can
>>>> chose not to set the cap, and if HWC knows, it can chose to set. This is
>>>> the same situation as 2D stereo modes
>>>> which are existing already.
>>>>
>>>> Regards
>>>> Shashank
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: BUG: KASAN: use-after-free in snd_usb_audio_free
From: Shuah Khan @ 2016-11-14 16:55 UTC (permalink / raw)
To: Takashi Iwai, Shuah Khan; +Cc: alsa-devel, LKML, Shuah Khan
In-Reply-To: <s5hr36e2waq.wl-tiwai@suse.de>
On 11/14/2016 03:25 AM, Takashi Iwai wrote:
> On Sat, 12 Nov 2016 00:34:38 +0100,
> Shuah Khan wrote:
>>
>> Hi Takashi,
>>
>> I am seeing the following use-after-free error when I disconnect an
>> USB speaker. I saw this on 4.9-rc4 and 4.8.7. There might be race
>> condition between the disconnect and pcm close perhaps.
>
> Thanks, this looks like a new discovery.
> Could you check whether the patch below works?
>
>
> Takashi
>
> ---
> diff --git a/sound/usb/card.c b/sound/usb/card.c
> index 9e5276d6dda0..2ddc034673a8 100644
> --- a/sound/usb/card.c
> +++ b/sound/usb/card.c
> @@ -315,7 +315,8 @@ static int snd_usb_audio_free(struct snd_usb_audio *chip)
> snd_usb_endpoint_free(ep);
>
> mutex_destroy(&chip->mutex);
> - dev_set_drvdata(&chip->dev->dev, NULL);
> + if (!atomic_read(&chip->shutdown))
> + dev_set_drvdata(&chip->dev->dev, NULL);
> kfree(chip);
> return 0;
> }
>
Hi Takashi,
The patch fixed the problem on 4.9-rc4. Didn't get a chance
to test it on 4.8.7.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH] bsg: Add sparse annotations to bsg_request_fn()
From: Bart Van Assche @ 2016-11-14 16:55 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-block@vger.kernel.org
In-Reply-To: <6dfb1793-ca6a-c3b6-b3fc-272e68ca6880@sandisk.com>
On 09/25/2016 07:54 PM, Bart Van Assche wrote:
> Avoid that sparse complains about unbalanced lock actions.
>
> Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
> ---
> block/bsg-lib.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/block/bsg-lib.c b/block/bsg-lib.c
> index 650f427..b2a61e3 100644
> --- a/block/bsg-lib.c
> +++ b/block/bsg-lib.c
> @@ -161,6 +161,8 @@ failjob_rls_job:
> * Drivers/subsys should pass this to the queue init function.
> */
> void bsg_request_fn(struct request_queue *q)
> + __releases(q->queue_lock)
> + __acquires(q->queue_lock)
> {
> struct device *dev = q->queuedata;
> struct request *req;
>
Hi Jens,
Do you agree with this patch? If so, can you queue it for kernel v4.10?
Thanks,
Bart.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.