Re: [RFC 01/10] crypto: factor async completion for general use
Hi Eric, On Thu, May 11, 2017 at 6:55 AM, Eric Biggers wrote: > Hi Gilad, > > On Sat, May 06, 2017 at 03:59:50PM +0300, Gilad Ben-Yossef wrote: >> Invoking a possibly async. crypto op and waiting for completion >> while correctly handling backlog processing is a common task >> in the crypto API implementation and outside users of it. >> >> This patch re-factors one of the in crypto API implementation in >> preparation for using it across the board instead of hand >> rolled versions. > > Thanks for doing this! It annoyed me too that there wasn't a helper function > for this. Just a few comments below: > Thank you for the review. I will incorporate the feedback into v2. ... > With regards to the wait being uninterruptible, I agree that this should be > the > default behavior, because I think users waiting for specific crypto requests > are > generally not prepared to handle the wait actually being interrupted. After > interruption the crypto operation will still proceed in the background, and it > will use buffers which the caller has in many cases already freed. However, > I'd > suggest taking a close look at anything that was actually doing an > interruptible > wait before, to see whether it was a bug or intentional (or "doesn't matter"). > > And yes there could always be a crypto_wait_req_interruptible() introduced if > some users need it. So this one was a bit of a shocker. I though the _interruptible use sites seemed wrong in the sense of being needless. However, after reading your feedback and reviewing the code I'm pretty sure every single one of them (including the one I've added in dm-verity-target.c this merge window) are down right dangerous and can cause random data corruption... so thanks for pointing this out! I though of this patch set as a "make the code pretty" for 4.13 kind of patch set. Looks like it's a bug fix now, maybe even stable material. Anyway, I'll roll a v2 and we'll see. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 01/10] crypto: factor async completion for general use
On Thu, May 11, 2017 at 10:29:47AM +0300, Gilad Ben-Yossef wrote: > > With regards to the wait being uninterruptible, I agree that this should be > > the > > default behavior, because I think users waiting for specific crypto > > requests are > > generally not prepared to handle the wait actually being interrupted. After > > interruption the crypto operation will still proceed in the background, and > > it > > will use buffers which the caller has in many cases already freed. > > However, I'd > > suggest taking a close look at anything that was actually doing an > > interruptible > > wait before, to see whether it was a bug or intentional (or "doesn't > > matter"). > > > > And yes there could always be a crypto_wait_req_interruptible() introduced > > if > > some users need it. > > So this one was a bit of a shocker. I though the _interruptible use > sites seemed > wrong in the sense of being needless. However, after reading your feedback and > reviewing the code I'm pretty sure every single one of them (including > the one I've > added in dm-verity-target.c this merge window) are down right dangerous and > can cause random data corruption... so thanks for pointing this out! > > I though of this patch set as a "make the code pretty" for 4.13 kind > of patch set. > Looks like it's a bug fix now, maybe even stable material. > > Anyway, I'll roll a v2 and we'll see. > Any that are called only by kernel threads would theoretically be safe since kernel threads don't ordinarily receive signals. But I think that at least the drbg and gcm waits can be reached by user threads, since they can be called via algif_rng and algif_aead respectively. I recommend putting any important fixes first, so they can be backported without depending on crypto_wait_req(). Eric -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] doc: replace FTP URL to kernel.org with HTTPS one
FTP services were shutdown some weeks ago, so the FTP URL does not work anymore. Fix this by replacing it with corresponding HTTPS URL. Signed-off-by: Michael Heimpold --- Documentation/admin-guide/README.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/admin-guide/README.rst b/Documentation/admin-guide/README.rst index 02f639a..b96e80f7 100644 --- a/Documentation/admin-guide/README.rst +++ b/Documentation/admin-guide/README.rst @@ -362,7 +362,7 @@ If something goes wrong as is, otherwise you will have to use the ``ksymoops`` program to make sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred). This utility can be downloaded from - ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/ . + https://www.kernel.org/pub/linux/utils/kernel/ksymoops/ . Alternatively, you can do the dump lookup by hand: - In debugging dumps like the above, it helps enormously if you can -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] input: edt-ft5x06: increase allowed data range for threshold parameter
On 2017-05-08 18:11, Rob Herring wrote: > On Tue, May 02, 2017 at 05:00:59PM +0200, Martin Kepplinger wrote: >> The datasheet and application note does not mention an allowed range for >> the M09_REGISTER_THRESHOLD parameter. One of our customers needs to set >> lower values than 20 and they seem to work just fine on EDT EP0xx0M09 with >> T5x06 touch. >> >> So, lacking a known lower limit, we increase the range for thresholds, >> and set the lower limit to 0. The documentation is updated accordingly. >> >> Signed-off-by: Schoefegger Stefan >> Signed-off-by: Manfred Schlaegl >> Signed-off-by: Martin Kepplinger >> --- >> Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt | 2 +- >> Documentation/input/devices/edt-ft5x06.rst | 2 +- >> drivers/input/touchscreen/edt-ft5x06.c | 2 +- >> 3 files changed, 3 insertions(+), 3 deletions(-) > > Acked-by: Rob Herring > Dmitry, any objections or thoughts? thanks martin -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 01/10] crypto: factor async completion for general use
On Thu, May 11, 2017 at 11:09 AM, Eric Biggers wrote: > On Thu, May 11, 2017 at 10:29:47AM +0300, Gilad Ben-Yossef wrote: >> > With regards to the wait being uninterruptible, I agree that this should >> > be the >> > default behavior, because I think users waiting for specific crypto >> > requests are >> > generally not prepared to handle the wait actually being interrupted. >> > After >> > interruption the crypto operation will still proceed in the background, >> > and it >> > will use buffers which the caller has in many cases already freed. >> > However, I'd >> > suggest taking a close look at anything that was actually doing an >> > interruptible >> > wait before, to see whether it was a bug or intentional (or "doesn't >> > matter"). >> > >> > And yes there could always be a crypto_wait_req_interruptible() introduced >> > if >> > some users need it. >> >> So this one was a bit of a shocker. I though the _interruptible use >> sites seemed >> wrong in the sense of being needless. However, after reading your feedback >> and >> reviewing the code I'm pretty sure every single one of them (including >> the one I've >> added in dm-verity-target.c this merge window) are down right dangerous and >> can cause random data corruption... so thanks for pointing this out! >> >> I though of this patch set as a "make the code pretty" for 4.13 kind >> of patch set. >> Looks like it's a bug fix now, maybe even stable material. >> >> Anyway, I'll roll a v2 and we'll see. >> > > Any that are called only by kernel threads would theoretically be safe since > kernel threads don't ordinarily receive signals. But I think that at least > the > drbg and gcm waits can be reached by user threads, since they can be called > via > algif_rng and algif_aead respectively. > > I recommend putting any important fixes first, so they can be backported > without > depending on crypto_wait_req(). > OK, I'll send out a separate bug fix series first and rebase the crypto_wait one on top of it then. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] docs-rst: add input docs at main index and use kernel-figure
Em Tue, 9 May 2017 13:41:53 -0600 Jonathan Corbet escreveu: > On Tue, 11 Apr 2017 07:01:19 -0300 > Mauro Carvalho Chehab wrote: > > > The input subsystem documentation got converted into ReST. > > > > Add it to the main documentation index and use kernel-figure > > for the two svg images there. > > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > > > Jon/Dmitry, > > > > This patch contains the final bits of the input documentation > > conversion. The linux-input tree has already the ReST conversion > > patches, but it doesn't have the > > Documentation/sphinx/load_config.py script with implements > > the kernel-figure directive, as it got merged via docs tree. > > > > So, either one of you should merge from the other tree or this > > patch should be sent in separate upstream after both trees > > gets merged. What do you prefer? > > This is now applied. Thanks! > I do reserve the right to break apart and reorganize this documentation, > a bit; it's got the classic problem of jumbling stuff for different > audiences into one big document. But that's for another day when I have > some time...2022 or so... Yeah, it makes sense to better organize things, but I suspect that, if we do that after converting everything to ReST, it would be easier to identify what would be the best way to group the documentation per audience. Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] crypto: Documentation: fix none signal safe sample
The sample code was showing use of wait_for_completion_interruptible()
for waiting for an async. crypto op to finish. However, if a signal
arrived it would free the buffers used even while crypto HW might
still DMA from/into the buffers.
Resolve this by using wait_for_completion() instead.
Reported-by: Eric Biggers
Signed-off-by: Gilad Ben-Yossef
---
Documentation/crypto/api-samples.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/crypto/api-samples.rst
b/Documentation/crypto/api-samples.rst
index d021fd9..944f08b 100644
--- a/Documentation/crypto/api-samples.rst
+++ b/Documentation/crypto/api-samples.rst
@@ -48,7 +48,7 @@ Code Example For Symmetric Key Cipher Operation
break;
case -EINPROGRESS:
case -EBUSY:
-rc = wait_for_completion_interruptible(
+rc = wait_for_completion(
&sk->result.completion);
if (!rc && !sk->result.err) {
reinit_completion(&sk->result.completion);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] crypto: gcm wait for crypto op not signal safe
crypto_gcm_setkey() was using wait_for_completion_interruptible() to
wait for completion of async crypto op but if a signal occurs it
may return before DMA ops of HW crypto provider finish, thus
corrupting the data buffer that is kfree'ed in this case.
Resolve this by using wait_for_completion() instead.
Reported-by: Eric Biggers
Signed-off-by: Gilad Ben-Yossef
CC: sta...@vger.kernel.org
---
crypto/drbg.c | 4 ++--
crypto/gcm.c | 6 ++
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index fa9054d..cdb27ac 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1767,8 +1767,8 @@ static int drbg_kcapi_sym_ctr(struct drbg_state *drbg,
break;
case -EINPROGRESS:
case -EBUSY:
- ret = wait_for_completion(&drbg->ctr_completion);
- if (!ret && !drbg->ctr_async_err) {
+ wait_for_completion(&drbg->ctr_completion);
+ if (!drbg->ctr_async_err) {
reinit_completion(&drbg->ctr_completion);
break;
}
diff --git a/crypto/gcm.c b/crypto/gcm.c
index b7ad808..3841b5e 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -152,10 +152,8 @@ static int crypto_gcm_setkey(struct crypto_aead *aead,
const u8 *key,
err = crypto_skcipher_encrypt(&data->req);
if (err == -EINPROGRESS || err == -EBUSY) {
- err = wait_for_completion_interruptible(
- &data->result.completion);
- if (!err)
- err = data->result.err;
+ wait_for_completion(&data->result.completion);
+ err = data->result.err;
}
if (err)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] crypto: handle EBUSY due to backlog correctly
public_key_verify_signature() was passing the CRYPTO_TFM_REQ_MAY_BACKLOG
flag to akcipher_request_set_callback() but was not handling correctly
the case where a -EBUSY error could be returned from the call to
crypto_akcipher_verify() if backlog was used, possibly casuing
data corruption due to use-after-free of buffers.
Resolve this by handling -EBUSY correctly.
Signed-off-by: Gilad Ben-Yossef
CC: sta...@vger.kernel.org
---
crypto/asymmetric_keys/public_key.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/asymmetric_keys/public_key.c
b/crypto/asymmetric_keys/public_key.c
index d3a989e..3cd6e12 100644
--- a/crypto/asymmetric_keys/public_key.c
+++ b/crypto/asymmetric_keys/public_key.c
@@ -141,7 +141,7 @@ int public_key_verify_signature(const struct public_key
*pkey,
* signature and returns that to us.
*/
ret = crypto_akcipher_verify(req);
- if (ret == -EINPROGRESS) {
+ if ((ret == -EINPROGRESS) || (ret == -EBUSY)) {
wait_for_completion(&compl.completion);
ret = compl.err;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] crypto: async crypto op fixes
This patch set fixes various usage and documentation errors in waiting for async crypto op to complete which can result in data corruption. Note: these were discovered in the process of working on a patch set that replaces these call sites and more with a generic implementation that will prevent these problems going forward. These are just the fix ups for current code. Signed-off-by: Gilad Ben-Yossef CC: sta...@vger.kernel.org CC: Eric Biggers Gilad Ben-Yossef (4): crypto: handle EBUSY due to backlog correctly crypto: drbg wait for crypto op not signal safe crypto: gcm wait for crypto op not signal safe crypto: Documentation: fix none signal safe sample Documentation/crypto/api-samples.rst | 2 +- crypto/asymmetric_keys/public_key.c | 2 +- crypto/drbg.c| 5 ++--- crypto/gcm.c | 6 ++ 4 files changed, 6 insertions(+), 9 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] crypto: drbg wait for crypto op not signal safe
drbg_kcapi_sym_ctr() was using wait_for_completion_interruptible() to
wait for completion of async crypto op but if a signal occurs it
may return before DMA ops of HW crypto provider finish, thus
corrupting the output buffer.
Resolve this by using wait_for_completion() instead.
Reported-by: Eric Biggers
Signed-off-by: Gilad Ben-Yossef
CC: sta...@vger.kernel.org
---
crypto/drbg.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index fa749f4..fa9054d 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1767,8 +1767,7 @@ static int drbg_kcapi_sym_ctr(struct drbg_state *drbg,
break;
case -EINPROGRESS:
case -EBUSY:
- ret = wait_for_completion_interruptible(
- &drbg->ctr_completion);
+ ret = wait_for_completion(&drbg->ctr_completion);
if (!ret && !drbg->ctr_async_err) {
reinit_completion(&drbg->ctr_completion);
break;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 04/10] pinctrl: sunxi: switch A20's pinctrl driver to use the A10 version
On Thu, May 4, 2017 at 3:50 PM, Icenowy Zheng wrote: > As we added A20 support to A10 pinctrl driver, now we can delete the > dedicated A20 pinctrl driver, and enable A10 driver for A20. > > Signed-off-by: Icenowy Zheng Looks all right to me but I'm waiting for Maxime's review on these patches. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/10] ARM: dts: sun8i: Add board dts file for Banana Pi M2 Ultra
On Thu, May 4, 2017 at 3:50 PM, Icenowy Zheng wrote:
> From: Chen-Yu Tsai
>
> The Banana Pi M2 Ultra is an SBC based on the Allwinner R40 SoC. The
> form factor and position of various connectors, leds and buttons is
> similar to the Banana Pi M1+, Banana Pi M3, and is exactly the same
> as the latest Banana Pi M64.
>
> It features:
>
> - X-Powers AXP221s PMIC connected to i2c0
> - 2 GB DDR3 DRAM
> - 8 GB eMMC
> - micro SD card slot
> - DC power jack
> - HDMI output
> - MIPI DSI connector
> - 2x USB 2.0 hosts
> - 1x USB 2.0 OTG
> - gigabit ethernet with Realtek RTL8211E transceiver
> - WiFi/Bluetooth with AP6212 chip, with external antenna connector
> - SATA and power connectors for native SATA support
> - camera sensor connector
> - consumer IR receiver
> - audio out headphone jack
> - onboard microphone
> - red, green, and blue LEDs
> - debug UART pins
> - Li-Po battery connector
> - Raspberry Pi B+ compatible GPIO header
> - power, reset, and boot control buttons
>
> This patch adds a dts file that enables debug UART and MMC support.
>
> Signed-off-by: Chen-Yu Tsai
> Signed-off-by: Icenowy Zheng
Eric put a lot of time and effort into naming the GPIO lines on the
other Pi board.
So please follow the good example and name the GPIO lines on this board
like in the other rpi boards, should be something like:
&pio {
gpio-line-names = "...", "...";
};
This is very helpful for users.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 7/9] coresight: add support for CPU debug module
On Tue, May 09, 2017 at 10:50:00AM +0800, Leo Yan wrote: > Coresight includes debug module and usually the module connects with CPU > debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has > description for related info in "Part H: External Debug". > > Chapter H7 "The Sample-based Profiling Extension" introduces several > sampling registers, e.g. we can check program counter value with > combined CPU exception level, secure state, etc. So this is helpful for > analysis CPU lockup scenarios, e.g. if one CPU has run into infinite > loop with IRQ disabled. In this case the CPU cannot switch context and > handle any interrupt (including IPIs), as the result it cannot handle > SMP call for stack dump. > > This patch is to enable coresight debug module, so firstly this driver > is to bind apb clock for debug module and this is to ensure the debug > module can be accessed from program or external debugger. And the driver > uses sample-based registers for debug purpose, e.g. when system triggers > panic, the driver will dump program counter and combined context > registers (EDCIDSR, EDVIDSR); by parsing context registers so can > quickly get to know CPU secure state, exception level, etc. > > Some of the debug module registers are located in CPU power domain, so > this requires the CPU power domain stays on when access related debug > registers, but the power management for CPU power domain is quite > dependent on SoC integration for power management. For the platforms > which with sane power controller implementations, this driver follows > the method to set EDPRCR to try to pull the CPU out of low power state > and then set 'no power down request' bit so the CPU has no chance to > lose power. > > If the SoC has not followed up this design well for power management > controller, the user should use the command line parameter or sysfs > to constrain all or partial idle states to ensure the CPU power > domain is enabled and access coresight CPU debug component safely. > > Signed-off-by: Leo Yan > --- > drivers/hwtracing/coresight/Kconfig | 14 + > drivers/hwtracing/coresight/Makefile | 1 + > drivers/hwtracing/coresight/coresight-cpu-debug.c | 693 > ++ > 3 files changed, 708 insertions(+) > create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c > > diff --git a/drivers/hwtracing/coresight/Kconfig > b/drivers/hwtracing/coresight/Kconfig > index 130cb21..8d55d6d 100644 > --- a/drivers/hwtracing/coresight/Kconfig > +++ b/drivers/hwtracing/coresight/Kconfig > @@ -89,4 +89,18 @@ config CORESIGHT_STM > logging useful software events or data coming from various entities > in the system, possibly running different OSs > > +config CORESIGHT_CPU_DEBUG > + tristate "CoreSight CPU Debug driver" > + depends on ARM || ARM64 > + depends on DEBUG_FS > + help > + This driver provides support for coresight debugging module. This > + is primarily used to dump sample-based profiling registers when > + system triggers panic, the driver will parse context registers so > + can quickly get to know program counter (PC), secure state, > + exception level, etc. Before use debugging functionality, platform > + needs to ensure the clock domain and power domain are enabled > + properly, please refer Documentation/trace/coresight-cpu-debug.txt > + for detailed description and the example for usage. > + > endif > diff --git a/drivers/hwtracing/coresight/Makefile > b/drivers/hwtracing/coresight/Makefile > index af480d9..433d590 100644 > --- a/drivers/hwtracing/coresight/Makefile > +++ b/drivers/hwtracing/coresight/Makefile > @@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \ > coresight-etm4x-sysfs.o > obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o > obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o > +obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o > diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c > b/drivers/hwtracing/coresight/coresight-cpu-debug.c > new file mode 100644 > index 000..ab12ec1 > --- /dev/null > +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c > @@ -0,0 +1,693 @@ > +/* > + * Copyright (c) 2017 Linaro Limited. All rights reserved. > + * > + * Author: Leo Yan > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 as published > by > + * the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for > + * more details. > + * > + * You should have received a copy of the GNU General Public License along > with > + * this program. If
Re: [PATCH v9 8/9] arm64: dts: hi6220: register debug module
On Tue, May 09, 2017 at 10:50:01AM +0800, Leo Yan wrote:
> Bind debug module driver for Hi6220.
>
> Signed-off-by: Leo Yan
Reviewed-by: Mathieu Poirier
> ---
> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 64
> +++
> 1 file changed, 64 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 470461d..467aa15 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -913,5 +913,69 @@
> };
> };
> };
> +
> + debug@f659 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf659 0 0x1000>;
> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&cpu0>;
> + };
> +
> + debug@f6592000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf6592000 0 0x1000>;
> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&cpu1>;
> + };
> +
> + debug@f6594000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf6594000 0 0x1000>;
> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&cpu2>;
> + };
> +
> + debug@f6596000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf6596000 0 0x1000>;
> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&cpu3>;
> + };
> +
> + debug@f65d {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf65d 0 0x1000>;
> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&cpu4>;
> + };
> +
> + debug@f65d2000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf65d2000 0 0x1000>;
> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&cpu5>;
> + };
> +
> + debug@f65d4000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf65d4000 0 0x1000>;
> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&cpu6>;
> + };
> +
> + debug@f65d6000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0 0xf65d6000 0 0x1000>;
> + clocks = <&sys_ctrl HI6220_DAPB_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&cpu7>;
> + };
> };
> };
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 9/9] arm64: dts: qcom: msm8916: Add debug unit
On Tue, May 09, 2017 at 10:50:02AM +0800, Leo Yan wrote:
> Add debug unit on Qualcomm msm8916 based platforms, including the
> DragonBoard 410c board.
>
> Signed-off-by: Leo Yan
Reviewed-by: Mathieu Poirier
> ---
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index 68a8e67..3af814b 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -1104,6 +1104,38 @@
> };
> };
>
> + debug@85 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0x85 0x1000>;
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&CPU0>;
> + };
> +
> + debug@852000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0x852000 0x1000>;
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&CPU1>;
> + };
> +
> + debug@854000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0x854000 0x1000>;
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&CPU2>;
> + };
> +
> + debug@856000 {
> + compatible = "arm,coresight-cpu-debug","arm,primecell";
> + reg = <0x856000 0x1000>;
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> + cpu = <&CPU3>;
> + };
> +
> etm@85c000 {
> compatible = "arm,coresight-etm4x", "arm,primecell";
> reg = <0x85c000 0x1000>;
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 2/9] doc: Add documentation for Coresight CPU debug
On Tue, May 09, 2017 at 10:49:55AM +0800, Leo Yan wrote: > Add detailed documentation for Coresight CPU debug driver, which > contains the info for driver implementation, Mike Leach excellent > summary for "clock and power domain". At the end some examples on how > to enable the debugging functionality are provided. > > Suggested-by: Mike Leach > Signed-off-by: Leo Yan Reviewed-by: Mathieu Poirier > --- > Documentation/trace/coresight-cpu-debug.txt | 174 > > 1 file changed, 174 insertions(+) > create mode 100644 Documentation/trace/coresight-cpu-debug.txt > > diff --git a/Documentation/trace/coresight-cpu-debug.txt > b/Documentation/trace/coresight-cpu-debug.txt > new file mode 100644 > index 000..0426d50 > --- /dev/null > +++ b/Documentation/trace/coresight-cpu-debug.txt > @@ -0,0 +1,174 @@ > + Coresight CPU Debug Module > + == > + > + Author: Leo Yan > + Date: April 5th, 2017 > + > +Introduction > + > + > +Coresight CPU debug module is defined in ARMv8-a architecture reference > manual > +(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate > +debug module and it is mainly used for two modes: self-hosted debug and > +external debug. Usually the external debug mode is well known as the external > +debugger connects with SoC from JTAG port; on the other hand the program can > +explore debugging method which rely on self-hosted debug mode, this document > +is to focus on this part. > + > +The debug module provides sample-based profiling extension, which can be used > +to sample CPU program counter, secure state and exception level, etc; usually > +every CPU has one dedicated debug module to be connected. Based on > self-hosted > +debug mechanism, Linux kernel can access these related registers from mmio > +region when the kernel panic happens. The callback notifier for kernel panic > +will dump related registers for every CPU; finally this is good for assistant > +analysis for panic. > + > + > +Implementation > +-- > + > +- During driver registration, use EDDEVID and EDDEVID1 two device ID > + registers to decide if sample-based profiling is implemented or not. On > some > + platforms this hardware feature is fully or partialy implemented; and if > + this feature is not supported then registration will fail. > + > +- When write this doc, the debug driver mainly relies on three sampling > + registers. The kernel panic callback notifier gathers info from EDPCSR > + EDVIDSR and EDCIDSR; from EDPCSR we can get program counter, EDVIDSR has > + information for secure state, exception level, bit width, etc; EDCIDSR is > + context ID value which contains the sampled value of CONTEXTIDR_EL1. > + > +- The driver supports CPU running mode with either AArch64 or AArch32. The > + registers naming convention is a bit different between them, AArch64 uses > + 'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses > + 'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to > + use AArch64 naming convention. > + > +- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different > + register bits definition. So the driver consolidates two difference: > + > + If PCSROffset=0b, on ARMv8-a the feature of EDPCSR is not implemented; > + but ARMv7-a defines "PCSR samples are offset by a value that depends on the > + instruction set state". For ARMv7-a, the driver checks furthermore if CPU > + runs with ARM or thumb instruction set and calibrate PCSR value, the > + detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter > + C11.11.34 "DBGPCSR, Program Counter Sampling Register". > + > + If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have > + no offset applied and do not sample the instruction set state in AArch32 > + state". So on ARMv8 if EDDEVID1.PCSROffset is 0b0010 and the CPU operates > + in AArch32 state, EDPCSR is not sampled; when the CPU operates in AArch64 > + state EDPCSR is sampled and no offset are applied. > + > + > +Clock and power domain > +-- > + > +Before accessing debug registers, we should ensure the clock and power domain > +have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1 > +Debug registers', the debug registers are spread into two domains: the debug > +domain and the CPU domain. > + > ++---+ > +| | > +| | > + +--+--+| > + dbg_clk -->| |**||<-- cpu_clk > + |Debug |**| CPU | > + dbg_pd -->| |**||<-- cpu_pd > + +--+--+| > +| | > +
Re: [PATCH v9 3/9] doc: Add coresight_cpu_debug.enable to kernel-parameters.txt
On Tue, May 09, 2017 at 10:49:56AM +0800, Leo Yan wrote: > Add coresight_cpu_debug.enable to kernel-parameters.txt, this flag is > used to enable/disable the CPU sampling based debugging. > > Signed-off-by: Leo Yan Reviewed-by: Mathieu Poirier > --- > Documentation/admin-guide/kernel-parameters.txt | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index e4c9e0e..010ae02 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -649,6 +649,13 @@ > /proc//coredump_filter. > See also Documentation/filesystems/proc.txt. > > + coresight_cpu_debug.enable > + [ARM,ARM64] > + Format: > + Enable/disable the CPU sampling based debugging. > + 0: default value, disable debugging > + 1: enable debugging at boot time > + > cpuidle.off=1 [CPU_IDLE] > disable the cpuidle sub-system > > -- > 2.7.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 4/9] MAINTAINERS: update file entries for Coresight subsystem
On Tue, May 09, 2017 at 10:49:57AM +0800, Leo Yan wrote: > Update document file entries for Coresight debug module. > > Signed-off-by: Leo Yan Reviewed-by: Mathieu Poirier > --- > MAINTAINERS | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index b948dfa..a4b1f60 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1191,7 +1191,9 @@ L: linux-arm-ker...@lists.infradead.org (moderated > for non-subscribers) > S: Maintained > F: drivers/hwtracing/coresight/* > F: Documentation/trace/coresight.txt > +F: Documentation/trace/coresight-cpu-debug.txt > F: Documentation/devicetree/bindings/arm/coresight.txt > +F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt > F: Documentation/ABI/testing/sysfs-bus-coresight-devices-* > F: tools/perf/arch/arm/util/pmu.c > F: tools/perf/arch/arm/util/auxtrace.c > -- > 2.7.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 7/9] coresight: add support for CPU debug module
On 09/05/17 03:50, Leo Yan wrote: Coresight includes debug module and usually the module connects with CPU debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has description for related info in "Part H: External Debug". Chapter H7 "The Sample-based Profiling Extension" introduces several sampling registers, e.g. we can check program counter value with combined CPU exception level, secure state, etc. So this is helpful for analysis CPU lockup scenarios, e.g. if one CPU has run into infinite loop with IRQ disabled. In this case the CPU cannot switch context and handle any interrupt (including IPIs), as the result it cannot handle SMP call for stack dump. This patch is to enable coresight debug module, so firstly this driver is to bind apb clock for debug module and this is to ensure the debug module can be accessed from program or external debugger. And the driver uses sample-based registers for debug purpose, e.g. when system triggers panic, the driver will dump program counter and combined context registers (EDCIDSR, EDVIDSR); by parsing context registers so can quickly get to know CPU secure state, exception level, etc. Some of the debug module registers are located in CPU power domain, so this requires the CPU power domain stays on when access related debug registers, but the power management for CPU power domain is quite dependent on SoC integration for power management. For the platforms which with sane power controller implementations, this driver follows the method to set EDPRCR to try to pull the CPU out of low power state and then set 'no power down request' bit so the CPU has no chance to lose power. If the SoC has not followed up this design well for power management controller, the user should use the command line parameter or sysfs to constrain all or partial idle states to ensure the CPU power domain is enabled and access coresight CPU debug component safely. Signed-off-by: Leo Yan With comments from Mathieu addressed, Reviewed-by: Suzuki K Poulose -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] docs-rst: add input docs at main index and use kernel-figure
On Thu, 11 May 2017 07:44:24 -0300 Mauro Carvalho Chehab wrote: > > I do reserve the right to break apart and reorganize this documentation, > > a bit; it's got the classic problem of jumbling stuff for different > > audiences into one big document. But that's for another day when I have > > some time...2022 or so... > > Yeah, it makes sense to better organize things, but I suspect that, > if we do that after converting everything to ReST, it would be easier > to identify what would be the best way to group the documentation > per audience. Well, it would be nice, when possible, to put things where we want them sooner and avoid yet another move; some people get grumpy when you move the docs around too much :) That said, I know better than to believe we're going to get all of this right on the first try. Progress is a good thing. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] doc: replace FTP URL to kernel.org with HTTPS one
On Thu, 11 May 2017 10:13:44 +0200 Michael Heimpold wrote: > FTP services were shutdown some weeks ago, so the FTP URL > does not work anymore. Fix this by replacing it with > corresponding HTTPS URL. Applied, we definitely don't want to have broken pointers. That said, I have to wonder...does anybody actually use ksymoops anymore? It's certainly not an active area of development these days... Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] A few small documentation updates
The following changes since commit 4a1e31c68e9f40be32838944931178b0d9ed9162: Merge tag 'arc-4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc (2017-05-09 10:10:15 -0700) are available in the git repository at: git://git.lwn.net/linux.git tags/docs-4.12-2 for you to fetch changes up to 25a0da73f24c95d57381bedd9cd89e4929b1bfde: doc: replace FTP URL to kernel.org with HTTPS one (2017-05-11 11:52:52 -0600) Connect the newly RST-formatted documentation to the rest; this had to wait until the input pull was done. There's also a few small fixes that wandered in. Andre Przywara (1): Documentation: earlycon: fix Marvell Armada 3700 UART name Helmut Grohne (1): docs: update references to the device io book Mauro Carvalho Chehab (1): docs-rst: add input docs at main index and use kernel-figure Michael Heimpold (1): doc: replace FTP URL to kernel.org with HTTPS one Documentation/admin-guide/README.rst | 2 +- Documentation/admin-guide/kernel-parameters.txt | 2 +- Documentation/index.rst | 1 + Documentation/input/ff.rst | 4 ++-- Documentation/memory-barriers.txt| 4 ++-- Documentation/translations/ko_KR/memory-barriers.txt | 4 ++-- 6 files changed, 9 insertions(+), 8 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mm, docs: update memory.stat description with workingset* entries
Commit 4b4cea91691d ("mm: vmscan: fix IO/refault regression in
cache workingset transition") introduced three new entries in memory
stat file:
- workingset_refault,
- workingset_activate,
- workingset_nodereclaim.
This commit adds a corresponding description to the cgroup v2 docs.
Signed-off-by: Roman Gushchin
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Vladimir Davydov
Cc: Tejun Heo
Cc: Li Zefan
Cc: cgro...@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
Documentation/cgroup-v2.txt | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
index e50b95c..dc5e2dc 100644
--- a/Documentation/cgroup-v2.txt
+++ b/Documentation/cgroup-v2.txt
@@ -918,6 +918,18 @@ PAGE_SIZE multiple when read back.
Number of major page faults incurred
+ workingset_refault
+
+ Number of refaults of previously evicted pages
+
+ workingset_activate
+
+ Number of refaulted pages that were immediately activated
+
+ workingset_nodereclaim
+
+ Number of times a shadow node has been reclaimed
+
memory.swap.current
A read-only single value file which exists on non-root
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mm: per-cgroup memory reclaim stats
Track the following reclaim counters for every memory cgroup:
PGREFILL, PGSCAN, PGSTEAL, PGACTIVATE, PGDEACTIVATE, PGLAZYFREE and
PGLAZYFREED.
These values are exposed using the memory.stats interface of cgroup v2.
The meaning of each value is the same as for global counters,
available using /proc/vmstat.
Also, for consistency, rename mem_cgroup_count_vm_event() to
count_memcg_event_mm().
Signed-off-by: Roman Gushchin
Suggested-by: Johannes Weiner
Cc: Johannes Weiner
Cc: Tejun Heo
Cc: Li Zefan
Cc: Michal Hocko
Cc: Vladimir Davydov
Cc: cgro...@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux...@kvack.org
---
Documentation/cgroup-v2.txt | 28 ++
fs/dax.c| 2 +-
fs/ncpfs/mmap.c | 2 +-
include/linux/memcontrol.h | 48 ++---
mm/filemap.c| 2 +-
mm/memcontrol.c | 10 ++
mm/memory.c | 4 ++--
mm/shmem.c | 3 +--
mm/swap.c | 1 +
mm/vmscan.c | 30 +---
10 files changed, 113 insertions(+), 17 deletions(-)
diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
index e50b95c..5804355 100644
--- a/Documentation/cgroup-v2.txt
+++ b/Documentation/cgroup-v2.txt
@@ -918,6 +918,34 @@ PAGE_SIZE multiple when read back.
Number of major page faults incurred
+ pgrefill
+
+ Amount of scanned pages (in an active LRU list)
+
+ pgscan
+
+ Amount of scanned pages (in an inactive LRU list)
+
+ pgsteal
+
+ Amount of reclaimed pages
+
+ pgactivate
+
+ Amount of pages moved to the active LRU list
+
+ pgdeactivate
+
+ Amount of pages moved to the inactive LRU lis
+
+ pglazyfree
+
+ Amount of pages postponed to be freed under memory pressure
+
+ pglazyfreed
+
+ Amount of reclaimed lazyfree pages
+
memory.swap.current
A read-only single value file which exists on non-root
diff --git a/fs/dax.c b/fs/dax.c
index 66d7906..9aac521d 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1230,7 +1230,7 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,
case IOMAP_MAPPED:
if (iomap.flags & IOMAP_F_NEW) {
count_vm_event(PGMAJFAULT);
- mem_cgroup_count_vm_event(vmf->vma->vm_mm, PGMAJFAULT);
+ count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
major = VM_FAULT_MAJOR;
}
error = dax_insert_mapping(mapping, iomap.bdev, iomap.dax_dev,
diff --git a/fs/ncpfs/mmap.c b/fs/ncpfs/mmap.c
index 0c3905e..6719c0b 100644
--- a/fs/ncpfs/mmap.c
+++ b/fs/ncpfs/mmap.c
@@ -89,7 +89,7 @@ static int ncp_file_mmap_fault(struct vm_fault *vmf)
* -- nyc
*/
count_vm_event(PGMAJFAULT);
- mem_cgroup_count_vm_event(vmf->vma->vm_mm, PGMAJFAULT);
+ count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
return VM_FAULT_MAJOR;
}
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 899949b..b2a5b1c 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -357,6 +357,17 @@ static inline unsigned short mem_cgroup_id(struct
mem_cgroup *memcg)
}
struct mem_cgroup *mem_cgroup_from_id(unsigned short id);
+static inline struct mem_cgroup *lruvec_memcg(struct lruvec *lruvec)
+{
+ struct mem_cgroup_per_node *mz;
+
+ if (mem_cgroup_disabled())
+ return NULL;
+
+ mz = container_of(lruvec, struct mem_cgroup_per_node, lruvec);
+ return mz->memcg;
+}
+
/**
* parent_mem_cgroup - find the accounting parent of a memcg
* @memcg: memcg whose parent to find
@@ -546,8 +557,23 @@ unsigned long mem_cgroup_soft_limit_reclaim(pg_data_t
*pgdat, int order,
gfp_t gfp_mask,
unsigned long *total_scanned);
-static inline void mem_cgroup_count_vm_event(struct mm_struct *mm,
-enum vm_event_item idx)
+static inline void count_memcg_events(struct mem_cgroup *memcg,
+ enum vm_event_item idx,
+ unsigned long count)
+{
+ if (!mem_cgroup_disabled())
+ this_cpu_add(memcg->stat->events[idx], count);
+}
+
+static inline void count_memcg_page_event(struct page *page,
+ enum memcg_stat_item idx)
+{
+ if (page->mem_cgroup)
+ count_memcg_events(page->mem_cgroup, idx, 1);
+}
+
+static inline void count_memcg_event_mm(struct mm_struct *mm,
+ enum vm_event_item idx)
{
struct mem_cgroup *memcg;
@@ -675,6 +701,11 @@ static inline struct mem_cgroup
*
Re: [PATCH] doc: replace FTP URL to kernel.org with HTTPS one
Hi, Am Donnerstag, 11. Mai 2017, 11:53:49 CEST schrieb Jonathan Corbet: > On Thu, 11 May 2017 10:13:44 +0200 > > Michael Heimpold wrote: > > FTP services were shutdown some weeks ago, so the FTP URL > > does not work anymore. Fix this by replacing it with > > corresponding HTTPS URL. > > Applied, we definitely don't want to have broken pointers. That said, I > have to wonder...does anybody actually use ksymoops anymore? It's > certainly not an active area of development these days... I must admit that I just stumbled upon the URL. But I'm not a user of ksymoops, nor ever has been... Regards, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 7/9] coresight: add support for CPU debug module
On Thu, May 11, 2017 at 11:12:32AM -0600, Mathieu Poirier wrote:
[...]
> > +static int debug_probe(struct amba_device *adev, const struct amba_id *id)
> > +{
> > + void __iomem *base;
> > + struct device *dev = &adev->dev;
> > + struct debug_drvdata *drvdata;
> > + struct resource *res = &adev->res;
> > + struct device_node *np = adev->dev.of_node;
> > + int ret;
> > +
> > + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> > + if (!drvdata)
> > + return -ENOMEM;
> > +
> > + drvdata->cpu = np ? of_coresight_get_cpu(np) : 0;
> > + if (per_cpu(debug_drvdata, drvdata->cpu)) {
> > + dev_err(dev, "CPU%d drvdata has been initialized, "
>
> s/"has been"/"has already been"
>
> That way it really look like an error message.
Will fix.
> Also debug_probe() uses dev_xyz() but everywhere else in the driver it is
> pr_xyz() - any specific reason for that? I suggest moving to dev_xyz().
Some logs are shared for all device instances, so I think should use
pr_xyz(); will spin a new version to change other places to use
dev_xyz() if the logs are for specific device instance.
> Otherwise things look good.
[...]
Thanks,
Leo Yan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: per-cgroup memory reclaim stats
On Thu, 2017-05-11 at 20:16 +0100, Roman Gushchin wrote:
> Track the following reclaim counters for every memory cgroup:
> PGREFILL, PGSCAN, PGSTEAL, PGACTIVATE, PGDEACTIVATE, PGLAZYFREE and
> PGLAZYFREED.
>
> These values are exposed using the memory.stats interface of cgroup v2.
The changelog could also describe what is currently there and what
is missing. Is there a user space program that uses the newly exported
values? Or is this just for consistency of stats?
>
> The meaning of each value is the same as for global counters,
> available using /proc/vmstat.
>
> Also, for consistency, rename mem_cgroup_count_vm_event() to
> count_memcg_event_mm().
>
I still prefer the mem_cgroup_count_vm_event() name, or memcg_count_vm_event(),
the namespace upfront makes it easier to parse where to look for the the
implementation and also grep. In any case the rename should be independent
patch, but I don't like the name you've proposed.
> Signed-off-by: Roman Gushchin
> Suggested-by: Johannes Weiner
> Cc: Johannes Weiner
> Cc: Tejun Heo
> Cc: Li Zefan
> Cc: Michal Hocko
> Cc: Vladimir Davydov
> Cc: cgro...@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux...@kvack.org
> ---
> Documentation/cgroup-v2.txt | 28 ++
> fs/dax.c| 2 +-
> fs/ncpfs/mmap.c | 2 +-
> include/linux/memcontrol.h | 48
> ++---
> mm/filemap.c| 2 +-
> mm/memcontrol.c | 10 ++
> mm/memory.c | 4 ++--
> mm/shmem.c | 3 +--
> mm/swap.c | 1 +
> mm/vmscan.c | 30 +---
> 10 files changed, 113 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
> index e50b95c..5804355 100644
> --- a/Documentation/cgroup-v2.txt
> +++ b/Documentation/cgroup-v2.txt
> @@ -918,6 +918,34 @@ PAGE_SIZE multiple when read back.
>
> Number of major page faults incurred
>
> + pgrefill
> +
> + Amount of scanned pages (in an active LRU list)
> +
> + pgscan
> +
> + Amount of scanned pages (in an inactive LRU list)
> +
> + pgsteal
> +
> + Amount of reclaimed pages
> +
> + pgactivate
> +
> + Amount of pages moved to the active LRU list
> +
> + pgdeactivate
> +
> + Amount of pages moved to the inactive LRU lis
> +
> + pglazyfree
> +
> + Amount of pages postponed to be freed under memory pressure
> +
> + pglazyfreed
> +
> + Amount of reclaimed lazyfree pages
> +
>memory.swap.current
>
> A read-only single value file which exists on non-root
> diff --git a/fs/dax.c b/fs/dax.c
> index 66d7906..9aac521d 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -1230,7 +1230,7 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,
> case IOMAP_MAPPED:
> if (iomap.flags & IOMAP_F_NEW) {
> count_vm_event(PGMAJFAULT);
> - mem_cgroup_count_vm_event(vmf->vma->vm_mm, PGMAJFAULT);
> + count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
> major = VM_FAULT_MAJOR;
> }
> error = dax_insert_mapping(mapping, iomap.bdev, iomap.dax_dev,
> diff --git a/fs/ncpfs/mmap.c b/fs/ncpfs/mmap.c
> index 0c3905e..6719c0b 100644
> --- a/fs/ncpfs/mmap.c
> +++ b/fs/ncpfs/mmap.c
> @@ -89,7 +89,7 @@ static int ncp_file_mmap_fault(struct vm_fault *vmf)
>* -- nyc
>*/
> count_vm_event(PGMAJFAULT);
> - mem_cgroup_count_vm_event(vmf->vma->vm_mm, PGMAJFAULT);
> + count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
> return VM_FAULT_MAJOR;
> }
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 899949b..b2a5b1c 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -357,6 +357,17 @@ static inline unsigned short mem_cgroup_id(struct
> mem_cgroup *memcg)
> }
> struct mem_cgroup *mem_cgroup_from_id(unsigned short id);
>
> +static inline struct mem_cgroup *lruvec_memcg(struct lruvec *lruvec)
mem_cgroup_from_lruvec()?
> +{
> + struct mem_cgroup_per_node *mz;
> +
> + if (mem_cgroup_disabled())
> + return NULL;
> +
> + mz = container_of(lruvec, struct mem_cgroup_per_node, lruvec);
> + return mz->memcg;
> +}
> +
> /**
> * parent_mem_cgroup - find the accounting parent of a memcg
> * @memcg: memcg whose parent to find
> @@ -546,8 +557,23 @@ unsigned long mem_cgroup_soft_limit_reclaim(pg_data_t
> *pgdat, int order,
> gfp_t gfp_mask,
> unsigned long *total_scanned);
>
> -static inline void mem_cgroup_count_vm_event(struct mm_struct *mm,
> - enum vm_event_item idx)
