* Re: [Qemu-devel] [PULL v2 0/9] Ide patches
From: no-reply @ 2016-11-14 16:59 UTC (permalink / raw)
To: jsnow; +Cc: famz, qemu-devel, peter.maydell
In-Reply-To: <1479140746-22142-1-git-send-email-jsnow@redhat.com>
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PULL v2 0/9] Ide patches
Message-id: 1479140746-22142-1-git-send-email-jsnow@redhat.com
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0
# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True
commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git show --no-patch --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done
exit $failed
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
* [new tag] patchew/1479140746-22142-1-git-send-email-jsnow@redhat.com -> patchew/1479140746-22142-1-git-send-email-jsnow@redhat.com
Switched to a new branch 'test'
aac853f ahci-test: add QMP tray test for ATAPI
9aff593 libqos/ahci: Add get_sense and test_ready
7163df5 libqos/ahci: Add ATAPI tray macros
f1e2266 libqos/ahci: Support expected errors
3968b94 libqtest: add qmp_eventwait_ref
9d13ef0 block-backend: Always notify on blk_eject
341ba04 ahci-test: test atapi read_cd with bcl, nb_sectors = 0
8990ba8 ahci-test: Create smaller test ISO images
e3e34c1 atapi: classify read_cd as conditionally returning data
=== OUTPUT BEGIN ===
fatal: unrecognized argument: --no-patch
Checking PATCH 1/9: ...
ERROR: space prohibited after that open square bracket '['
#92: FILE: hw/ide/atapi.c:1324:
+ [ 0xbe ] = { cmd_read_cd, CHECK_READY | CONDDATA },
ERROR: space prohibited before that close square bracket ']'
#92: FILE: hw/ide/atapi.c:1324:
+ [ 0xbe ] = { cmd_read_cd, CHECK_READY | CONDDATA },
total: 2 errors, 0 warnings, 86 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
fatal: unrecognized argument: --no-patch
Checking PATCH 2/9: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 3/9: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 4/9: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 5/9: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 6/9: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 7/9: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 8/9: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 9/9: ...
=== OUTPUT END ===
Test command exited with code: 1
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@freelists.org
^ permalink raw reply
* Re: [Qemu-devel] Assertion failure on qcow2 disk with cluster_size != 64k
From: Eric Blake @ 2016-11-14 16:59 UTC (permalink / raw)
To: Kevin Wolf; +Cc: Ed Swierk, qemu-block, qemu-devel, Denis V. Lunev
In-Reply-To: <20161114155428.GA9518@noname.str.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]
On 11/14/2016 09:54 AM, Kevin Wolf wrote:
>>>> Our qcow2 support is currently limited to a maximum of 2M clusters;
>>>> while MAX_WRITE_ZEROES_BOUNCE_BUFFER is 32k * 512, or 16M. The
>>>> maximum-size bounce buffer should not be the problem here; but for some
>>>> reason, it looks like alignment is larger than max_transfer which should
>>>> not normally be possible. I'm still playing with what should be the
>>>> right patch, but hope to have something posted soon.
>>>
>>> Are you still playing with it?
>>
>> Patch was posted here:
>>
>> https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg01603.html
>
> Ah, yes, sorry. I didn't make the connection today because this one had
> qcow2 in the subject line and the patch doesn't.
>
> Are you going to add a qemu-iotests case then, or do you want us to
> merge the patch as it is?
I think the patch is ready to merge as-is; I'm still adding a
qemu-iotests addition, but the addition requires enhancing blkdebug
which is a bit extreme to be doing after soft freeze (so the tests are
probably 2.9 material, while the bug fix is still for 2.8)
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
^ permalink raw reply
* Re: Which version of xfs-progs to use on Debian?
From: John Henderson @ 2016-11-14 16:59 UTC (permalink / raw)
To: linux-xfs
In-Reply-To: <20161114131435.GB37689@bfoster.bfoster>
Hi Brian,
Thanks for your prompt response. More inline.
On Mon, Nov 14, 2016 at 7:14 AM, Brian Foster <bfoster@redhat.com> wrote:
> On Mon, Nov 14, 2016 at 01:23:50AM -0600, John Henderson wrote:
>> Hi,
>>
>> I'm trying to determine the optimal combination of kernel version and
>> xfs-progs version to use on a Debian Jessie system (for amd64).
>>
>> I've searched this mailing list, and noticed the following exchange:
>>
>> http://www.spinics.net/lists/xfs/msg36165.html
>>
>> specifically, Dave's response:
>>
>> "As it is, in future the version of xfsprogs will tell you what
>> kernel has the same feature support. i.e. xfsprogs 4.2.0 has exactly
>> the same code/feature support as kernel 4.2.0. Similarly for
>> xfsprogs/kernel 4.3.0."
>>
>> I'm also aware that prior to xfsprogs 4.2.0, userspace versioning did
>> not match kernel numbering, as noted:
>>
>> https://git.kernel.org/cgit/fs/xfs/xfsprogs-dev.git/refs/tags
>> https://www.spinics.net/lists/xfs/msg33984.html
>>
>> So, as I understand the situation, xfsprogs 3.2.x was associated with
>> a lot of different 3.x and 4.y (y<2) kernels. Further, I want to make
>> sure to take advantage of all the (current and future) reliability
>> improvements of the new xfs v5 on-disk format, which means (from what
>> I follow) that I need at least kernel 3.15 and xfsprogs 3.2.0, as seen
>> here:
>>
>> https://www.spinics.net/lists/xfs/msg27961.html
>>
>> My main concern focuses on the options currently available in Debian
>> (primarily Jessie + backports). Here's the matchup of what Debian
>> ships (jessie, jessie-bpo, and stretch):
>>
>> linux-kernel xfs-progs
>> Jessie: 3.16.36 3.2.1
>> Jessie Backports: 4.7.8 4.3.0
>> Stretch: 4.8.5 4.3.0
>>
>> So, at first pass, I could just use native jessie's kernel 3.16.36 and
>> xfsprogs 3.2.1 (and they seem to match well, as they were released
>> together). However, I actually have to use a more recent kernel
>> anyway for some SkyLake support issues. So, that takes us to at least
>> kernel 4.7.8. I note, though, that jessie-backports is *not*
>> packaging xfsprogs 4.7 alongside its kernel (but instead xfsprogs
>> 4.3.0); similar issues exist for the 4.8.5 kernel from stretch.
>>
>
> Others might be able to chime in on this, but that strikes me as a
> packaging issue.
Agree completely. I very strongly prefer to use 100% default packages within
single repo in Debian (ie, no pulling from Jessie backports). However, usage
of the workstation in this case requires support of the Skylake CPU, available
only in more modern 4.x series of kernels (Jessie [stable] is still at 3.16.x).
So, that means pulling some kernel like 4.7.x from Jessie backports. Oh, well.
> My understanding is that the marriage between the
> kernel revision and xfsprogs revision tracking numbers is to help define
> dependencies between the two.
Yes, I was a bit surprised that Debian testing / unstable have non-matched
kernel / xfsprogs as currently packaged (ie, 4.7 & 4.8 kernels, respectively,
with 4.3 xfsprogs). Debian stable is indeed matched with kernel 3.16.x and
xfsprogs 3.2.1. I also noted that the most recent (ie, testing / unstable)
xfsprogs uploads to Debian repos appear to be non-maintainer uploads
(NMUs); perhaps, there's something going on with Debian XFS maintainers?
> That said, it might not be a problem for
> you if you aren't using anything notable introduced between 4.3 and 4.7.
Given that crc / finobt are default, I don't plan on using anything
else, but still
am glad to check with the list, here. Thanks for your input.
>> Assuming I stick to binary packages distributed through the official
>> Debian repos, what's the recommendation of the xfs experts: would I be
>> better off (in terms of reliability) with xfsprogs 3.2.1 or xfsprogs
>> 4.3.0 used with kernel 4.7.8? As an alternative, would it be even
>> better for me to use xfsprogs 4.7 (via compiling from source, even
>> though I'd rather not)?
>>
>
> v4.7 of xfsprogs is probably best, but IMO, you'll probably be fine with
> the v4.3 in the simple cases (you haven't mentioned whether you're
> planning to use xfsprogs for anything beyond mkfs and possibly repair if
> something goes wrong).
Yes, plan is only to use xfsprogs for mkfs (+ fsck). If I'm in the situation
where I have to repair anything, perhaps that's the time to look more carefully
at getting (compiling?) xfsprogs that matches kernel specifically.
> Just keep in mind that it is out of date with
> respect to your kernel in the event that you do run into problems down
> the road and may want to update.
>
>> Also, what are current best-practice parameters for 'mkfs.xfs' in
>> order to optimize reliability? Filesystem size is ~10 TB on top of
>> LUKS-encrypted Software RAID-1 (using enterprise 512e drives).
>>
>> I'd assume, we'd at least want the following:
>>
>> -m crc=1 finobt=1
>>
>
> Usually it is best to go with defaults. Indeed, crc=1,finobt=1 are both
> defaults and have been for a while now. See commit 566ebd5a ("mkfs:
> default to CRC enabled filesystems") which first appeared in xfsprogs
> v3.2.3. I'm not aware of any special/magic options required for raid1 or
> encryption.
Yep, saw those changes in the defaults in xfs list announcements. Thanks
for reiterating.
Take care,
John
^ permalink raw reply
* [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
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.