* Re: [PATCH v2 2/5] dt-bindings: perf: stm32: ddrperfm support
From: Rob Herring @ 2019-06-13 23:04 UTC (permalink / raw)
To: Gerald BAEZA
Cc: will.deacon@arm.com, mark.rutland@arm.com, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, Alexandre TORGUE, corbet@lwn.net,
linux@armlinux.org.uk, olof@lixom.net, horms+renesas@verge.net.au,
arnd@arndb.de, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Gerald BAEZA
In-Reply-To: <1558366019-24214-3-git-send-email-gerald.baeza@st.com>
On Mon, 20 May 2019 15:27:16 +0000, Gerald BAEZA wrote:
> The DDRPERFM is the DDR Performance Monitor embedded in STM32MP1 SOC.
>
> This documentation indicates how to enable stm32-ddr-pmu driver on
> DDRPERFM peripheral, via the device tree.
>
> Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
> ---
> .../devicetree/bindings/perf/stm32-ddr-pmu.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/perf/stm32-ddr-pmu.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: hwmon: Add DT bindings for TI ads1000/ads1100 ADCs
From: Rob Herring @ 2019-06-13 20:33 UTC (permalink / raw)
To: Serge Semin
Cc: Jean Delvare, Guenter Roeck, Mark Rutland, Jonathan Corbet,
Serge Semin, linux-hwmon, devicetree, linux-kernel, linux-doc
In-Reply-To: <20190514225810.12591-2-fancer.lancer@gmail.com>
On Wed, May 15, 2019 at 01:58:08AM +0300, Serge Semin wrote:
> Add dt-binding documentation for the Texas Instruments ads1000/ads1100 ADCs
> driver.
>
> Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> ---
> .../devicetree/bindings/hwmon/ads1000.txt | 61 ++++++++++++++++
Bindings should be separate patch.
> Documentation/hwmon/ads1000.rst | 72 +++++++++++++++++++
> 2 files changed, 133 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/ads1000.txt
> create mode 100644 Documentation/hwmon/ads1000.rst
>
> diff --git a/Documentation/devicetree/bindings/hwmon/ads1000.txt b/Documentation/devicetree/bindings/hwmon/ads1000.txt
> new file mode 100644
> index 000000000000..3907b7da9b33
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/ads1000.txt
> @@ -0,0 +1,61 @@
> +ADS1000/ADS1100 (I2C)
> +
> +This device is a 12-16 bit A-D converter with 1 input.
ADC's should be in bindings/iio/adc/
> +
> +The inputs can be used either as a differential pair of Vin+ Vin- or as a single
> +ended sensor for Vin+ GND. The inputs mode is platform-dependent and isn't
> +configured by software in any case.
> +
> +Device A-D converter sensitivity can be configured using two parameters:
> + - pga is the programmable gain amplifier
> + 0: x1 (default)
> + 1: x2
> + 2: x4
> + 3: x8
> + - data_rate in samples per second also affecting the output code accuracy
> + 0: 128SPS - +/- Vdd*0.488mV (default, ads1000 accepts this rate only)
> + 1: 32SPS - +/- Vdd*0.122mV
> + 2: 16SPS - +/- Vdd*0.061mV
> + 3: 8SPS - +/- Vdd*0.030mV
> + Since this parameter also affects the output accuracy, be aware the greater
> + SPS the worse accuracy.
> +
> +As a result the output value is calculated by the next formulae:
> +dVin = Cod * Vdd / (PGA * max(|Cod|)), where
> +max(|Cod|) - maximum possible value of the output code, which depends on the SPS
> +setting from the table above.
> +
> +The ADS1000/ADS1100 dts-node:
> +
> + Required properties:
> + - compatible : must be "ti,ads1000" or "ti,ads1100"
> + - reg : I2C bus address of the device
> + - #address-cells : must be <1>
> + - #size-cells : must be <0>
> + - vdd-supply : regulator for reference supply voltage (usually fixed)
> +
> + Optional properties:
> + - ti,gain : the programmable gain amplifier setting
> + - ti,datarate : the converter data rate
IIRC, we have standard properties for these.
> + - ti,voltage-divider : <R1 R2> Ohms inbound voltage dividers,
> + so dVin = (R1 + R2)/R2 * dVin
> +
> +Example:
> +
> +vdd_5v0: fixedregulator@0 {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd-ref";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> +};
> +
> +tiadc: ads1000@48 {
adc@48
> + compatible = "ti,ads1000";
> + reg = <0x48>;
> +
> + vdd-supply = <&vdd_5v0>;
> + ti,gain = <0>;
> + ti,voltage-divider = <31600 3600>;
> +};
> +
^ permalink raw reply
* dringender Kredit
From: Herr David Williams @ 2019-06-13 15:27 UTC (permalink / raw)
--
Benötigen Sie dringend einen Kredit? Wenn ja, antworten Sie für weitere
Details
^ permalink raw reply
* Re: [PATCH v4 1/2] fTPM: firmware TPM running in TEE
From: Sasha Levin @ 2019-06-13 17:11 UTC (permalink / raw)
To: Sumit Garg
Cc: peterhuewe, Jarkko Sakkinen, jgg, corbet,
Linux Kernel Mailing List, linux-doc, linux-integrity,
Microsoft Linux Kernel List, Thirupathaiah Annapureddy,
Bryan Kelly (CSI), tee-dev
In-Reply-To: <CAFA6WYMOjgHRw9RVrjherNo0ZNbTtEonPwSFFC0dT4CZO=A1NQ@mail.gmail.com>
On Wed, Jun 05, 2019 at 04:39:36PM +0530, Sumit Garg wrote:
>On Wed, 5 Jun 2019 at 01:39, Sasha Levin <sashal@kernel.org> wrote:
>>
>> On Tue, Jun 04, 2019 at 11:45:52AM +0530, Sumit Garg wrote:
>> >On Thu, 30 May 2019 at 20:58, Sasha Levin <sashal@kernel.org> wrote:
>> >> + /* Open context with TEE driver */
>> >> + pvt_data->ctx = tee_client_open_context(NULL, ftpm_tee_match, NULL,
>> >> + NULL);
>> >> + if (IS_ERR(pvt_data->ctx)) {
>> >> + dev_err(dev, "%s:tee_client_open_context failed\n", __func__);
>> >
>> >Is this well tested? I see this misleading error multiple times as
>> >follows although TEE driver works pretty well.
>>
>> Yes, this was all functionally tested.
>
>Can you share your build instructions and testing approach?
Yes: it looks like you got all the kernel bits, but not the firmware.
There are instructions for it here: https://github.com/microsoft/ms-tpm-20-ref
Once it's running, you can test it by running your favorite TPM usecases
through /dev/tpm0.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v4 18/28] docs: convert docs to ReST and rename to *.rst
From: Srivatsa S. Bhat @ 2019-06-13 0:25 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet,
Sebastian Reichel, Rafael J. Wysocki, Viresh Kumar, Len Brown,
Pavel Machek, Nishanth Menon, Stephen Boyd, Liam Girdwood,
Mark Brown, Mathieu Poirier, Suzuki K Poulose, Harry Wei,
Alex Shi, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, x86, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
David Airlie, Daniel Vetter, Bjorn Helgaas, Johannes Berg,
David S. Miller, linux-pm, linux-arm-kernel, intel-gfx, dri-devel,
linux-pci, linux-wireless, netdev
In-Reply-To: <fac44e1fbab5ea755a93601a4fdfa34fcc57ae9e.1560361364.git.mchehab+samsung@kernel.org>
On 6/12/19 10:52 AM, Mauro Carvalho Chehab wrote:
> Convert the PM documents to ReST, in order to allow them to
> build with Sphinx.
>
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - mark literal blocks;
> - adjust title markups.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> Acked-by: Mark Brown <broonie@kernel.org>
> ---
[...]
> diff --git a/Documentation/power/suspend-and-cpuhotplug.txt b/Documentation/power/suspend-and-cpuhotplug.rst
> similarity index 90%
> rename from Documentation/power/suspend-and-cpuhotplug.txt
> rename to Documentation/power/suspend-and-cpuhotplug.rst
> index a8751b8df10e..9df664f5423a 100644
> --- a/Documentation/power/suspend-and-cpuhotplug.txt
> +++ b/Documentation/power/suspend-and-cpuhotplug.rst
> @@ -1,10 +1,15 @@
> +====================================================================
> Interaction of Suspend code (S3) with the CPU hotplug infrastructure
> +====================================================================
>
> - (C) 2011 - 2014 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
> +(C) 2011 - 2014 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
>
>
> -I. How does the regular CPU hotplug code differ from how the Suspend-to-RAM
> - infrastructure uses it internally? And where do they share common code?
> +I. Differences between CPU hotplug and Suspend-to-RAM
> +======================================================
> +
> +How does the regular CPU hotplug code differ from how the Suspend-to-RAM
> +infrastructure uses it internally? And where do they share common code?
>
> Well, a picture is worth a thousand words... So ASCII art follows :-)
>
[...]
> @@ -101,7 +108,7 @@ execution during resume):
>
> It is to be noted here that the system_transition_mutex lock is acquired at the very
> beginning, when we are just starting out to suspend, and then released only
> -after the entire cycle is complete (i.e., suspend + resume).
> +after the entire cycle is complete (i.e., suspend + resume)::
>
I think that should be a period, not a colon, because it is clarifying
the text above it (as opposed to referring to the example below it).
Other than that, for suspend-and-cpuhotplug.txt:
Acked-by: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu>
Regards,
Srivatsa
VMware Photon OS
^ permalink raw reply
* Re: [PATCH] crypto: doc - improve the skcipher API example code
From: Herbert Xu @ 2019-06-13 6:54 UTC (permalink / raw)
To: Eric Biggers; +Cc: linux-crypto, linux-doc
In-Reply-To: <20190603054408.5903-1-ebiggers@kernel.org>
Eric Biggers <ebiggers@kernel.org> wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Rewrite the skcipher API example, changing it to encrypt a buffer with
> AES-256-XTS. This addresses various problems with the previous example:
>
> - It requests a specific driver "cbc-aes-aesni", which is unusual.
> Normally users ask for "cbc(aes)", not a specific driver.
>
> - It encrypts only a single AES block. For the reader, that doesn't
> clearly distinguish the "skcipher" API from the "cipher" API.
>
> - Showing how to encrypt something with bare CBC is arguably a poor
> choice of example, as it doesn't follow modern crypto trends. Now,
> usually authenticated encryption is recommended, in which case the
> user would use the AEAD API, not skcipher. Disk encryption is still a
> legitimate use for skcipher, but for that usually XTS is recommended.
>
> - Many other bugs and poor coding practices, such as not setting
> CRYPTO_TFM_REQ_MAY_SLEEP, unnecessarily allocating a heap buffer for
> the IV, unnecessary NULL checks, using a pointless wrapper struct, and
> forgetting to set an error code in one case.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
> Documentation/crypto/api-samples.rst | 176 ++++++++++++---------------
> 1 file changed, 77 insertions(+), 99 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC 0/7] Introduce TEE based Trusted Keys support
From: Casey Schaufler @ 2019-06-13 16:40 UTC (permalink / raw)
To: Sumit Garg, keyrings, linux-integrity, linux-security-module
Cc: jens.wiklander, corbet, dhowells, jejb, jarkko.sakkinen, zohar,
jmorris, serge, ard.biesheuvel, daniel.thompson, linux-doc,
linux-kernel, tee-dev
In-Reply-To: <1560421833-27414-1-git-send-email-sumit.garg@linaro.org>
On 6/13/2019 3:30 AM, Sumit Garg wrote:
> Add support for TEE based trusted keys where TEE provides the functionality
> to seal and unseal trusted keys using hardware unique key. Also, this is
> an alternative in case platform doesn't possess a TPM device.
>
> This series also adds some TEE features like:
Please expand the acronym TEE on first use. That will
help people who don't work with it on a daily basis
understand what you're going on about.
>
> Patch #1, #2 enables support for registered kernel shared memory with TEE.
>
> Patch #3 enables support for private kernel login method required for
> cases like trusted keys where we don't wan't user-space to directly access
> TEE service to retrieve trusted key contents.
>
> Rest of the patches from #4 to #7 adds support for TEE based trusted keys.
>
> This patch-set has been tested with OP-TEE based pseudo TA which can be
> found here [1].
>
> Looking forward to your valuable feedback/suggestions.
>
> [1] https://github.com/OP-TEE/optee_os/pull/3082
>
> Sumit Garg (7):
> tee: optee: allow kernel pages to register as shm
> tee: enable support to register kernel memory
> tee: add private login method for kernel clients
> KEYS: trusted: Introduce TEE based Trusted Keys
> KEYS: encrypted: Allow TEE based trusted master keys
> doc: keys: Document usage of TEE based Trusted Keys
> MAINTAINERS: Add entry for TEE based Trusted Keys
>
> Documentation/security/keys/tee-trusted.rst | 93 +++++
> MAINTAINERS | 9 +
> drivers/tee/optee/call.c | 7 +
> drivers/tee/tee_core.c | 6 +
> drivers/tee/tee_shm.c | 16 +-
> include/keys/tee_trusted.h | 84 ++++
> include/keys/trusted-type.h | 1 +
> include/linux/tee_drv.h | 1 +
> include/uapi/linux/tee.h | 2 +
> security/keys/Kconfig | 3 +
> security/keys/Makefile | 3 +
> security/keys/encrypted-keys/masterkey_trusted.c | 10 +-
> security/keys/tee_trusted.c | 506 +++++++++++++++++++++++
> 13 files changed, 737 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/security/keys/tee-trusted.rst
> create mode 100644 include/keys/tee_trusted.h
> create mode 100644 security/keys/tee_trusted.c
>
^ permalink raw reply
* Re: [PATCH v8 1/7] iommu: enhance IOMMU default DMA mode build options
From: Leizhen (ThunderTown) @ 2019-06-13 8:30 UTC (permalink / raw)
To: John Garry, Jean-Philippe Brucker, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Sebastian Ott,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tony Luck, Fenghua Yu, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, David Woodhouse, iommu,
linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Hanjun Guo, Linuxarm
In-Reply-To: <55d0e30c-5bca-41fc-5bf0-4366dc387afd@huawei.com>
On 2019/5/31 18:42, John Garry wrote:
>
>>>> -config IOMMU_DEFAULT_PASSTHROUGH
>>>> - bool "IOMMU passthrough by default"
>>>> +choice
>>>> + prompt "IOMMU default DMA mode"
>>>> depends on IOMMU_API
>>>> - help
>>>> - Enable passthrough by default, removing the need to pass in
>>>> - iommu.passthrough=on or iommu=pt through command line. If this
>>>> - is enabled, you can still disable with iommu.passthrough=off
>>>> - or iommu=nopt depending on the architecture.
>>>> + default IOMMU_DEFAULT_STRICT
>>>> + help
>>>> + This option allows IOMMU DMA mode to be chose at build time, to
>>>
>>> As before:
>>> /s/chose/chosen/, /s/allows IOMMU/allows an IOMMU/
>> I'm sorry that the previous version was not modified.
>>
>>>
>>>> + override the default DMA mode of each ARCHs, removing the need to
>>>
>>> Again, as before:
>>> ARCHs should be singular
>> OK
>>
>>>
>>>> + pass in kernel parameters through command line. You can still use
>>>> + ARCHs specific boot options to override this option again.
>
> *
>
>>>> +
>>>> +config IOMMU_DEFAULT_PASSTHROUGH
>>>> + bool "passthrough"
>>>> + help
>>>> + In this mode, the DMA access through IOMMU without any addresses
>>>> + translation. That means, the wrong or illegal DMA access can not
>>>> + be caught, no error information will be reported.
>>>>
>>>> If unsure, say N here.
>>>>
>>>> +config IOMMU_DEFAULT_LAZY
>>>> + bool "lazy"
>>>> + help
>>>> + Support lazy mode, where for every IOMMU DMA unmap operation, the
>>>> + flush operation of IOTLB and the free operation of IOVA are deferred.
>>>> + They are only guaranteed to be done before the related IOVA will be
>>>> + reused.
>>>
>>> why no advisory on how to set if unsure?
>> Because the LAZY and STRICT have their own advantages and disadvantages.
>>
>> Should I say: If unsure, keep the default。
>
> Maybe. So you could put this in the help for the choice, * above, and remove the advisory on IOMMU_DEFAULT_PASSTHROUGH.
OK, I'll revise it according to this idea in v9.
>
> However the maintainer may have a different view.
>
> Thanks,
> John
>
>>
>>>
>>>> +
>>>> +config IOMMU_DEFAULT_STRICT
>>>> + bool "strict"
>>>> + help
>>>> + For every IOMMU DMA unmap operation, the flush operation of IOTLB and
>>>> + the free operation of IOVA are guaranteed to be done in the unmap
>>>> + function.
>>>> +
>>>> + This mode is safer than the two above, but it maybe slower in some
>>>> + high performace scenarios.
>>>
>>> and here?
>
>
> .
>
^ permalink raw reply
* [PATCH] docs: stop suggesting strlcpy
From: Stephen Kitt @ 2019-06-13 16:25 UTC (permalink / raw)
To: corbet, federico.vaga, linux-doc; +Cc: keescook, linux-kernel, Stephen Kitt
Since strlcpy is deprecated, the documentation shouldn't suggest using
it. This patch fixes the examples to use strscpy instead. It also uses
sizeof instead of underlying constants as far as possible, to simplify
future changes to the corresponding data structures.
Signed-off-by: Stephen Kitt <steve@sk2.org>
---
Documentation/hid/hid-transport.txt | 6 +++---
Documentation/i2c/instantiating-devices | 2 +-
Documentation/i2c/upgrading-clients | 4 ++--
Documentation/kernel-hacking/locking.rst | 6 +++---
Documentation/translations/it_IT/kernel-hacking/locking.rst | 6 +++---
5 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/Documentation/hid/hid-transport.txt b/Documentation/hid/hid-transport.txt
index 3dcba9fd4a3a..4f41d67f1b4b 100644
--- a/Documentation/hid/hid-transport.txt
+++ b/Documentation/hid/hid-transport.txt
@@ -194,9 +194,9 @@ with HID core:
goto err_<...>;
}
- strlcpy(hid->name, <device-name-src>, 127);
- strlcpy(hid->phys, <device-phys-src>, 63);
- strlcpy(hid->uniq, <device-uniq-src>, 63);
+ strscpy(hid->name, <device-name-src>, sizeof(hid->name));
+ strscpy(hid->phys, <device-phys-src>, sizeof(hid->phys));
+ strscpy(hid->uniq, <device-uniq-src>, sizeof(hid->uniq));
hid->ll_driver = &custom_ll_driver;
hid->bus = <device-bus>;
diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices
index 0d85ac1935b7..8bc7d99133e3 100644
--- a/Documentation/i2c/instantiating-devices
+++ b/Documentation/i2c/instantiating-devices
@@ -137,7 +137,7 @@ static int usb_hcd_nxp_probe(struct platform_device *pdev)
(...)
i2c_adap = i2c_get_adapter(2);
memset(&i2c_info, 0, sizeof(struct i2c_board_info));
- strlcpy(i2c_info.type, "isp1301_nxp", I2C_NAME_SIZE);
+ strscpy(i2c_info.type, "isp1301_nxp", sizeof(i2c_info.type));
isp1301_i2c_client = i2c_new_probed_device(i2c_adap, &i2c_info,
normal_i2c, NULL);
i2c_put_adapter(i2c_adap);
diff --git a/Documentation/i2c/upgrading-clients b/Documentation/i2c/upgrading-clients
index ccba3ffd6e80..96392cc5b5c7 100644
--- a/Documentation/i2c/upgrading-clients
+++ b/Documentation/i2c/upgrading-clients
@@ -43,7 +43,7 @@ static int example_attach(struct i2c_adapter *adap, int addr, int kind)
example->client.adapter = adap;
i2c_set_clientdata(&state->i2c_client, state);
- strlcpy(client->i2c_client.name, "example", I2C_NAME_SIZE);
+ strscpy(client->i2c_client.name, "example", sizeof(client->i2c_client.name));
ret = i2c_attach_client(&state->i2c_client);
if (ret < 0) {
@@ -138,7 +138,7 @@ can be removed:
- example->client.flags = 0;
- example->client.adapter = adap;
-
-- strlcpy(client->i2c_client.name, "example", I2C_NAME_SIZE);
+- strscpy(client->i2c_client.name, "example", sizeof(client->i2c_client.name));
The i2c_set_clientdata is now:
diff --git a/Documentation/kernel-hacking/locking.rst b/Documentation/kernel-hacking/locking.rst
index 519673df0e82..dc698ea456e0 100644
--- a/Documentation/kernel-hacking/locking.rst
+++ b/Documentation/kernel-hacking/locking.rst
@@ -451,7 +451,7 @@ to protect the cache and all the objects within it. Here's the code::
if ((obj = kmalloc(sizeof(*obj), GFP_KERNEL)) == NULL)
return -ENOMEM;
- strlcpy(obj->name, name, sizeof(obj->name));
+ strscpy(obj->name, name, sizeof(obj->name));
obj->id = id;
obj->popularity = 0;
@@ -660,7 +660,7 @@ Here is the code::
}
@@ -63,6 +94,7 @@
- strlcpy(obj->name, name, sizeof(obj->name));
+ strscpy(obj->name, name, sizeof(obj->name));
obj->id = id;
obj->popularity = 0;
+ obj->refcnt = 1; /* The cache holds a reference */
@@ -774,7 +774,7 @@ the lock is no longer used to protect the reference count itself.
}
@@ -94,7 +76,7 @@
- strlcpy(obj->name, name, sizeof(obj->name));
+ strscpy(obj->name, name, sizeof(obj->name));
obj->id = id;
obj->popularity = 0;
- obj->refcnt = 1; /* The cache holds a reference */
diff --git a/Documentation/translations/it_IT/kernel-hacking/locking.rst b/Documentation/translations/it_IT/kernel-hacking/locking.rst
index 0ef31666663b..5fd8a1abd2be 100644
--- a/Documentation/translations/it_IT/kernel-hacking/locking.rst
+++ b/Documentation/translations/it_IT/kernel-hacking/locking.rst
@@ -468,7 +468,7 @@ e tutti gli oggetti che contiene. Ecco il codice::
if ((obj = kmalloc(sizeof(*obj), GFP_KERNEL)) == NULL)
return -ENOMEM;
- strlcpy(obj->name, name, sizeof(obj->name));
+ strscpy(obj->name, name, sizeof(obj->name));
obj->id = id;
obj->popularity = 0;
@@ -678,7 +678,7 @@ Ecco il codice::
}
@@ -63,6 +94,7 @@
- strlcpy(obj->name, name, sizeof(obj->name));
+ strscpy(obj->name, name, sizeof(obj->name));
obj->id = id;
obj->popularity = 0;
+ obj->refcnt = 1; /* The cache holds a reference */
@@ -792,7 +792,7 @@ contatore stesso.
}
@@ -94,7 +76,7 @@
- strlcpy(obj->name, name, sizeof(obj->name));
+ strscpy(obj->name, name, sizeof(obj->name));
obj->id = id;
obj->popularity = 0;
- obj->refcnt = 1; /* The cache holds a reference */
--
2.11.0
^ permalink raw reply related
* [PATCH v9 1/7] iommu: enhance IOMMU default DMA mode build options
From: Zhen Lei @ 2019-06-13 8:42 UTC (permalink / raw)
To: Jean-Philippe Brucker, John Garry, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Sebastian Ott,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tony Luck, Fenghua Yu, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, David Woodhouse, iommu,
linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Zhen Lei
In-Reply-To: <20190613084240.16768-1-thunder.leizhen@huawei.com>
First, add build option IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
opportunity to set {lazy|strict} mode as default at build time. Then put
the three config options in an choice, make people can only choose one of
the three at a time.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
drivers/iommu/Kconfig | 44 ++++++++++++++++++++++++++++++++++++--------
drivers/iommu/iommu.c | 3 ++-
2 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 83664db5221df02..fe715fb295c6ed2 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -75,16 +75,44 @@ config IOMMU_DEBUGFS
debug/iommu directory, and then populate a subdirectory with
entries as required.
-config IOMMU_DEFAULT_PASSTHROUGH
- bool "IOMMU passthrough by default"
+choice
+ prompt "IOMMU default DMA mode"
depends on IOMMU_API
- help
- Enable passthrough by default, removing the need to pass in
- iommu.passthrough=on or iommu=pt through command line. If this
- is enabled, you can still disable with iommu.passthrough=off
- or iommu=nopt depending on the architecture.
+ default IOMMU_DEFAULT_STRICT
+ help
+ This option allows an IOMMU DMA mode to be chosen at build time, to
+ override the default DMA mode of each ARCH, removing the need to
+ pass in kernel parameters through command line. You can still use
+ ARCH specific boot options to override this option again.
- If unsure, say N here.
+ If unsure, keep the default.
+
+config IOMMU_DEFAULT_PASSTHROUGH
+ bool "passthrough"
+ help
+ In this mode, the DMA access through IOMMU without any addresses
+ translation. That means, the wrong or illegal DMA access can not
+ be caught, no error information will be reported.
+
+config IOMMU_DEFAULT_LAZY
+ bool "lazy"
+ help
+ Support lazy mode, where for every IOMMU DMA unmap operation, the
+ flush operation of IOTLB and the free operation of IOVA are deferred.
+ They are only guaranteed to be done before the related IOVA will be
+ reused.
+
+config IOMMU_DEFAULT_STRICT
+ bool "strict"
+ help
+ For every IOMMU DMA unmap operation, the flush operation of IOTLB and
+ the free operation of IOVA are guaranteed to be done in the unmap
+ function.
+
+ This mode is safer than the two above, but it maybe slower in some
+ high performace scenarios.
+
+endchoice
config OF_IOMMU
def_bool y
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index f9cacce909d3ae9..05171dd0bd03aee 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -31,7 +31,8 @@
#else
static unsigned int iommu_def_domain_type = IOMMU_DOMAIN_DMA;
#endif
-static bool iommu_dma_strict __read_mostly = true;
+static bool iommu_dma_strict __read_mostly =
+ IS_ENABLED(CONFIG_IOMMU_DEFAULT_STRICT);
struct iommu_group {
struct kobject kobj;
--
1.8.3
^ permalink raw reply related
* [PATCH v9 0/7] iommu: enhance IOMMU default DMA mode build options
From: Zhen Lei @ 2019-06-13 8:42 UTC (permalink / raw)
To: Jean-Philippe Brucker, John Garry, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Sebastian Ott,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tony Luck, Fenghua Yu, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, David Woodhouse, iommu,
linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Zhen Lei
v8--> v9
1. Fix some text editing errors
v7--> v8
1. Split into multiple small patches base on ARCHs or IOMMU drivers.
2. Hide the unsupported build options on the related ARCH or IOMMU.
v6 --> v7:
1. Fix some text editing errors
v5 --> v6:
1. give up adding boot option iommu.dma_mode
v4 --> v5:
As Hanjun and Thomas Gleixner's suggestion:
1. Keep the old ARCH specific boot options no change.
2. Keep build option CONFIG_IOMMU_DEFAULT_PASSTHROUGH no change.
v4:
As Robin Murphy's suggestion:
"It's also not necessarily obvious to the user how this interacts with
IOMMU_DEFAULT_PASSTHROUGH, so if we really do go down this route, maybe it
would be better to refactor the whole lot into a single selection of something
like IOMMU_DEFAULT_MODE anyway."
In this version, I tried to normalize the IOMMU dma mode boot options for all
ARCHs. When IOMMU is enabled, there are 3 dma modes: paasthrough(bypass),
lazy(mapping but defer the IOTLB invalidation), strict. But currently each
ARCHs defined their private boot options, different with each other. For
example, to enable/disable "passthrough", ARM64 use iommu.passthrough=1/0,
X86 use iommu=pt/nopt, PPC/POWERNV use iommu=nobypass.
Zhen Lei (7):
iommu: enhance IOMMU default DMA mode build options
x86/dma: use IS_ENABLED() to simplify the code
s390/pci: add support for IOMMU default DMA mode build options
powernv/iommu: add support for IOMMU default DMA mode build options
iommu/vt-d: add support for IOMMU default DMA mode build options
iommu/amd: add support for IOMMU default DMA mode build options
ia64: hide build option IOMMU_DEFAULT_PASSTHROUGH
arch/powerpc/platforms/powernv/pci-ioda.c | 3 +-
arch/s390/pci/pci_dma.c | 2 +-
arch/x86/kernel/pci-dma.c | 6 +---
drivers/iommu/Kconfig | 48 +++++++++++++++++++++++++------
drivers/iommu/amd_iommu_init.c | 2 +-
drivers/iommu/intel-iommu.c | 2 +-
drivers/iommu/iommu.c | 3 +-
7 files changed, 48 insertions(+), 18 deletions(-)
--
1.8.3
^ permalink raw reply
* [PATCH v9 5/7] iommu/vt-d: add support for IOMMU default DMA mode build options
From: Zhen Lei @ 2019-06-13 8:42 UTC (permalink / raw)
To: Jean-Philippe Brucker, John Garry, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Sebastian Ott,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tony Luck, Fenghua Yu, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, David Woodhouse, iommu,
linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Zhen Lei
In-Reply-To: <20190613084240.16768-1-thunder.leizhen@huawei.com>
The default DMA mode of INTEL IOMMU is LAZY, this patch make it can be
set to STRICT at build time. It can be overridden by boot option.
There is no functional change.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
drivers/iommu/Kconfig | 2 +-
drivers/iommu/intel-iommu.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index bfbcaa24e283aad..fd297b0e0330d27 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -79,7 +79,7 @@ choice
prompt "IOMMU default DMA mode"
depends on IOMMU_API
default IOMMU_DEFAULT_PASSTHROUGH if (PPC_POWERNV && PCI)
- default IOMMU_DEFAULT_LAZY if S390_IOMMU
+ default IOMMU_DEFAULT_LAZY if (INTEL_IOMMU || S390_IOMMU)
default IOMMU_DEFAULT_STRICT
help
This option allows an IOMMU DMA mode to be chosen at build time, to
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 162b3236e72c3c8..ec5515b7831b23f 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -354,7 +354,7 @@ static int domain_detach_iommu(struct dmar_domain *domain,
static int dmar_map_gfx = 1;
static int dmar_forcedac;
-static int intel_iommu_strict;
+static int intel_iommu_strict = IS_ENABLED(CONFIG_IOMMU_DEFAULT_STRICT);
static int intel_iommu_superpage = 1;
static int intel_iommu_sm;
static int iommu_identity_mapping;
--
1.8.3
^ permalink raw reply related
* [PATCH v9 4/7] powernv/iommu: add support for IOMMU default DMA mode build options
From: Zhen Lei @ 2019-06-13 8:42 UTC (permalink / raw)
To: Jean-Philippe Brucker, John Garry, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Sebastian Ott,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tony Luck, Fenghua Yu, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, David Woodhouse, iommu,
linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Zhen Lei
In-Reply-To: <20190613084240.16768-1-thunder.leizhen@huawei.com>
The default DMA mode is PASSTHROUGH on powernv, this patch make it can be
set to STRICT at build time. It can be overridden by boot option.
There is no functional change.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 3 ++-
drivers/iommu/Kconfig | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 10cc42b9e541c46..27e25e8e3a9c637 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -81,7 +81,8 @@ void pe_level_printk(const struct pnv_ioda_pe *pe, const char *level,
va_end(args);
}
-static bool pnv_iommu_bypass_disabled __read_mostly;
+static bool pnv_iommu_bypass_disabled __read_mostly =
+ !IS_ENABLED(CONFIG_IOMMU_DEFAULT_PASSTHROUGH);
static bool pci_reset_phbs __read_mostly;
static int __init iommu_setup(char *str)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index a8dd69d175fb3c6..bfbcaa24e283aad 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -78,6 +78,7 @@ config IOMMU_DEBUGFS
choice
prompt "IOMMU default DMA mode"
depends on IOMMU_API
+ default IOMMU_DEFAULT_PASSTHROUGH if (PPC_POWERNV && PCI)
default IOMMU_DEFAULT_LAZY if S390_IOMMU
default IOMMU_DEFAULT_STRICT
help
@@ -98,6 +99,7 @@ config IOMMU_DEFAULT_PASSTHROUGH
config IOMMU_DEFAULT_LAZY
bool "lazy"
+ depends on !PPC_POWERNV
help
Support lazy mode, where for every IOMMU DMA unmap operation, the
flush operation of IOTLB and the free operation of IOVA are deferred.
--
1.8.3
^ permalink raw reply related
* [PATCH v9 3/7] s390/pci: add support for IOMMU default DMA mode build options
From: Zhen Lei @ 2019-06-13 8:42 UTC (permalink / raw)
To: Jean-Philippe Brucker, John Garry, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Sebastian Ott,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tony Luck, Fenghua Yu, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, David Woodhouse, iommu,
linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Zhen Lei
In-Reply-To: <20190613084240.16768-1-thunder.leizhen@huawei.com>
The default DMA mode is LAZY on s390, this patch make it can be set to
STRICT at build time. It can be overridden by boot option.
There is no functional change.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Acked-by: Sebastian Ott <sebott@linux.ibm.com>
---
arch/s390/pci/pci_dma.c | 2 +-
drivers/iommu/Kconfig | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/s390/pci/pci_dma.c b/arch/s390/pci/pci_dma.c
index 9e52d1527f71495..784ad1e0acecfb1 100644
--- a/arch/s390/pci/pci_dma.c
+++ b/arch/s390/pci/pci_dma.c
@@ -17,7 +17,7 @@
static struct kmem_cache *dma_region_table_cache;
static struct kmem_cache *dma_page_table_cache;
-static int s390_iommu_strict;
+static int s390_iommu_strict = IS_ENABLED(CONFIG_IOMMU_DEFAULT_STRICT);
static int zpci_refresh_global(struct zpci_dev *zdev)
{
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index fe715fb295c6ed2..a8dd69d175fb3c6 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -78,6 +78,7 @@ config IOMMU_DEBUGFS
choice
prompt "IOMMU default DMA mode"
depends on IOMMU_API
+ default IOMMU_DEFAULT_LAZY if S390_IOMMU
default IOMMU_DEFAULT_STRICT
help
This option allows an IOMMU DMA mode to be chosen at build time, to
@@ -89,6 +90,7 @@ choice
config IOMMU_DEFAULT_PASSTHROUGH
bool "passthrough"
+ depends on !S390_IOMMU
help
In this mode, the DMA access through IOMMU without any addresses
translation. That means, the wrong or illegal DMA access can not
--
1.8.3
^ permalink raw reply related
* [PATCH v9 2/7] x86/dma: use IS_ENABLED() to simplify the code
From: Zhen Lei @ 2019-06-13 8:42 UTC (permalink / raw)
To: Jean-Philippe Brucker, John Garry, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Sebastian Ott,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tony Luck, Fenghua Yu, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, David Woodhouse, iommu,
linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Zhen Lei
In-Reply-To: <20190613084240.16768-1-thunder.leizhen@huawei.com>
Remove the ifdefs around CONFIG_IOMMU_DEFAULT_PASSTHROUGH to improve
readablity.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
arch/x86/kernel/pci-dma.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index dcd272dbd0a9330..8c82b2e28a0fe2d 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -43,11 +43,7 @@
* It is also possible to disable by default in kernel config, and enable with
* iommu=nopt at boot time.
*/
-#ifdef CONFIG_IOMMU_DEFAULT_PASSTHROUGH
-int iommu_pass_through __read_mostly = 1;
-#else
-int iommu_pass_through __read_mostly;
-#endif
+int iommu_pass_through __read_mostly = IS_ENABLED(CONFIG_IOMMU_DEFAULT_PASSTHROUGH);
extern struct iommu_table_entry __iommu_table[], __iommu_table_end[];
--
1.8.3
^ permalink raw reply related
* [PATCH v9 6/7] iommu/amd: add support for IOMMU default DMA mode build options
From: Zhen Lei @ 2019-06-13 8:42 UTC (permalink / raw)
To: Jean-Philippe Brucker, John Garry, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Sebastian Ott,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tony Luck, Fenghua Yu, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, David Woodhouse, iommu,
linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Zhen Lei
In-Reply-To: <20190613084240.16768-1-thunder.leizhen@huawei.com>
The default DMA mode of AMD IOMMU is LAZY, this patch make it can be set
to STRICT at build time. It can be overridden by boot option.
There is no functional change.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
drivers/iommu/Kconfig | 2 +-
drivers/iommu/amd_iommu_init.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index fd297b0e0330d27..70741fd73b07785 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -79,7 +79,7 @@ choice
prompt "IOMMU default DMA mode"
depends on IOMMU_API
default IOMMU_DEFAULT_PASSTHROUGH if (PPC_POWERNV && PCI)
- default IOMMU_DEFAULT_LAZY if (INTEL_IOMMU || S390_IOMMU)
+ default IOMMU_DEFAULT_LAZY if (AMD_IOMMU || INTEL_IOMMU || S390_IOMMU)
default IOMMU_DEFAULT_STRICT
help
This option allows an IOMMU DMA mode to be chosen at build time, to
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 07d84dbab564e4d..b7d5c1757425946 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -154,7 +154,7 @@ struct ivmd_header {
to handle */
LIST_HEAD(amd_iommu_unity_map); /* a list of required unity mappings
we find in ACPI */
-bool amd_iommu_unmap_flush; /* if true, flush on every unmap */
+bool amd_iommu_unmap_flush = IS_ENABLED(CONFIG_IOMMU_DEFAULT_STRICT); /* if true, flush on every unmap */
LIST_HEAD(amd_iommu_list); /* list of all AMD IOMMUs in the
system */
--
1.8.3
^ permalink raw reply related
* [PATCH v9 7/7] ia64: hide build option IOMMU_DEFAULT_PASSTHROUGH
From: Zhen Lei @ 2019-06-13 8:42 UTC (permalink / raw)
To: Jean-Philippe Brucker, John Garry, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Sebastian Ott,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tony Luck, Fenghua Yu, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, David Woodhouse, iommu,
linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Zhen Lei
In-Reply-To: <20190613084240.16768-1-thunder.leizhen@huawei.com>
The DMA mode PASSTHROUGH is not used on ia64.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
drivers/iommu/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 70741fd73b07785..63506f1cad3d149 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -91,7 +91,7 @@ choice
config IOMMU_DEFAULT_PASSTHROUGH
bool "passthrough"
- depends on !S390_IOMMU
+ depends on (!S390_IOMMU && !IA64)
help
In this mode, the DMA access through IOMMU without any addresses
translation. That means, the wrong or illegal DMA access can not
--
1.8.3
^ permalink raw reply related
* Re: [PATCH] block/switching-sched.txt: Update to blk-mq schedulers
From: Jens Axboe @ 2019-06-13 8:59 UTC (permalink / raw)
To: Andreas Herrmann, Jonathan Corbet; +Cc: linux-doc, linux-kernel, linux-block
In-Reply-To: <20190612065009.GA11361@suselix>
On 6/12/19 12:50 AM, Andreas Herrmann wrote:
>
> Remove references to CFQ and legacy block layer which are gone.
> Update example with what's available under blk-mq.
Applied, thanks.
--
Jens Axboe
^ permalink raw reply
* [PATCH v5 0/2] arm64 relaxed ABI
From: Vincenzo Frascino @ 2019-06-13 15:51 UTC (permalink / raw)
To: linux-arm-kernel, linux-doc, linux-mm, linux-arch,
linux-kselftest, linux-kernel
Cc: Catalin Marinas, Will Deacon, Andrey Konovalov, Alexander Viro
In-Reply-To: <cover.1560339705.git.andreyknvl@google.com>
On arm64 the TCR_EL1.TBI0 bit has been always enabled on the arm64 kernel,
hence the userspace (EL0) is allowed to set a non-zero value in the top
byte but the resulting pointers are not allowed at the user-kernel syscall
ABI boundary.
This patchset proposes a relaxation of the ABI with which it is possible
to pass tagged tagged pointers to the syscalls, when these pointers are in
memory ranges obtained as described in tagged-address-abi.txt contained in
this patch series.
Since it is not desirable to relax the ABI to allow tagged user addresses
into the kernel indiscriminately, this patchset documents a new sysctl
interface (/proc/sys/abi/tagged_addr) that is used to prevent the applications
from enabling the relaxed ABI and a new prctl() interface that can be used to
enable or disable the relaxed ABI.
This patchset should be merged together with [1].
[1] https://patchwork.kernel.org/cover/10674351/
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
CC: Andrey Konovalov <andreyknvl@google.com>
CC: Alexander Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Vincenzo Frascino (2):
arm64: Define Documentation/arm64/tagged-address-abi.txt
arm64: Relax Documentation/arm64/tagged-pointers.txt
Documentation/arm64/tagged-address-abi.txt | 134 +++++++++++++++++++++
Documentation/arm64/tagged-pointers.txt | 23 ++--
2 files changed, 150 insertions(+), 7 deletions(-)
create mode 100644 Documentation/arm64/tagged-address-abi.txt
--
2.21.0
^ permalink raw reply
* [PATCH v5 1/2] arm64: Define Documentation/arm64/tagged-address-abi.txt
From: Vincenzo Frascino @ 2019-06-13 15:51 UTC (permalink / raw)
To: linux-arm-kernel, linux-doc, linux-mm, linux-arch,
linux-kselftest, linux-kernel
Cc: Catalin Marinas, Will Deacon, Andrey Konovalov, Alexander Viro
In-Reply-To: <20190613155137.47675-1-vincenzo.frascino@arm.com>
On arm64 the TCR_EL1.TBI0 bit has been always enabled hence
the userspace (EL0) is allowed to set a non-zero value in the
top byte but the resulting pointers are not allowed at the
user-kernel syscall ABI boundary.
With the relaxed ABI proposed through this document, it is now possible
to pass tagged pointers to the syscalls, when these pointers are in
memory ranges obtained by an anonymous (MAP_ANONYMOUS) mmap().
This change in the ABI requires a mechanism to requires the userspace
to opt-in to such an option.
Specify and document the way in which sysctl and prctl() can be used
in combination to allow the userspace to opt-in this feature.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
CC: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
---
Documentation/arm64/tagged-address-abi.txt | 134 +++++++++++++++++++++
1 file changed, 134 insertions(+)
create mode 100644 Documentation/arm64/tagged-address-abi.txt
diff --git a/Documentation/arm64/tagged-address-abi.txt b/Documentation/arm64/tagged-address-abi.txt
new file mode 100644
index 000000000000..0ae900d4bb2d
--- /dev/null
+++ b/Documentation/arm64/tagged-address-abi.txt
@@ -0,0 +1,134 @@
+ARM64 TAGGED ADDRESS ABI
+========================
+
+This document describes the usage and semantics of the Tagged Address
+ABI on arm64.
+
+1. Introduction
+---------------
+
+On arm64 the TCR_EL1.TBI0 bit has been always enabled on the kernel, hence
+the userspace (EL0) is entitled to perform a user memory access through a
+64-bit pointer with a non-zero top byte but the resulting pointers are not
+allowed at the user-kernel syscall ABI boundary.
+
+This document describes a relaxation of the ABI that makes it possible to
+to pass tagged pointers to the syscalls, when these pointers are in memory
+ranges obtained as described in section 2.
+
+Since it is not desirable to relax the ABI to allow tagged user addresses
+into the kernel indiscriminately, arm64 provides a new sysctl interface
+(/proc/sys/abi/tagged_addr) that is used to prevent the applications from
+enabling the relaxed ABI and a new prctl() interface that can be used to
+enable or disable the relaxed ABI.
+A detailed description of the newly introduced mechanisms will be provided
+in section 2.
+
+2. ARM64 Tagged Address ABI
+---------------------------
+
+From the kernel syscall interface perspective, we define, for the purposes
+of this document, a "valid tagged pointer" as a pointer that either has a
+zero value set in the top byte or has a non-zero value, it is in memory
+ranges privately owned by a userspace process and it is obtained in one of
+the following ways:
+ - mmap() done by the process itself, where either:
+ * flags have MAP_PRIVATE and MAP_ANONYMOUS
+ * flags have MAP_PRIVATE and the file descriptor refers to a regular
+ file or "/dev/zero"
+ - brk() system call done by the process itself (i.e. the heap area between
+ the initial location of the program break at process creation and its
+ current location).
+ - any memory mapped by the kernel in the process's address space during
+ creation and following the restrictions presented above (i.e. data, bss,
+ stack).
+
+The ARM64 Tagged Address ABI is an opt-in feature, and an application can
+control it using the following:
+ - /proc/sys/abi/tagged_addr: a new sysctl interface that can be used to
+ prevent the applications from enabling the relaxed ABI.
+ The sysctl is meant also for testing purposes in order to provide a
+ simple way for the userspace to verify the return error checking of
+ the prctl() commands without having to reconfigure the kernel.
+ The sysctl supports the following configuration options:
+ - 0: Disable ARM64 Tagged Address ABI for all the applications.
+ - 1 (Default): Enable ARM64 Tagged Address ABI for all the
+ applications.
+ If the ARM64 Tagged Address ABI is disabled at a certain point in
+ time, all the applications that were using tagging before this event
+ occurs, will continue to use tagging.
+
+ - prctl()s:
+ - PR_SET_TAGGED_ADDR_CTRL: can be used to enable or disable the Tagged
+ Address ABI.
+ The (unsigned int) arg2 argument is a bit mask describing the
+ control mode used:
+ - PR_TAGGED_ADDR_ENABLE: Enable ARM64 Tagged Address ABI.
+ The arguments arg3, arg4, and arg5 are ignored.
+
+ - PR_GET_TAGGED_ADDR_CTRL: can be used to check the status of the Tagged
+ Address ABI.
+ The arguments arg2, arg3, arg4, and arg5 are ignored.
+
+The ABI properties set by the mechanisms described above are inherited by threads
+of the same application and fork()'ed children but cleared by execve().
+
+As a consequence of invoking PR_SET_TAGGED_ADDR_CTRL prctl() by an applications,
+the ABI guarantees the following behaviours:
+
+ - Every current or newly introduced syscall can accept any valid tagged
+ pointers.
+
+ - If a non valid tagged pointer is passed to a syscall then the behaviour
+ is undefined.
+
+ - Every valid tagged pointer is expected to work as an untagged one.
+
+ - The kernel preserves any valid tagged pointers and returns them to the
+ userspace unchanged (i.e. on syscall return) in all the cases except the
+ ones documented in the "Preserving tags" section of tagged-pointers.txt.
+
+A definition of the meaning of tagged pointers on arm64 can be found in:
+Documentation/arm64/tagged-pointers.txt.
+
+3. ARM64 Tagged Address ABI Exceptions
+--------------------------------------
+
+The behaviours described in section 2, with particular reference to the
+acceptance by the syscalls of any valid tagged pointer are not applicable
+to the following cases:
+ - mmap() addr parameter.
+ - mremap() new_address parameter.
+ - prctl_set_mm() struct prctl_map fields.
+ - prctl_set_mm_map() struct prctl_map fields.
+
+Any attempt to use non-zero tagged pointers will lead to undefined behaviour.
+
+4. Example of correct usage
+---------------------------
+
+void main(void)
+{
+ static int tbi_enabled = 0;
+ unsigned long tag = 0;
+
+ char *ptr = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE,
+ MAP_ANONYMOUS, -1, 0);
+
+ if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE,
+ 0, 0, 0) == 0)
+ tbi_enabled = 1;
+
+ if (ptr == (void *)-1) /* MAP_FAILED */
+ return -1;
+
+ if (tbi_enabled)
+ tag = rand() & 0xff;
+
+ ptr = (char *)((unsigned long)ptr | (tag << TAG_SHIFT));
+
+ *ptr = 'a';
+
+ ...
+}
+
--
2.21.0
^ permalink raw reply related
* [PATCH v5 2/2] arm64: Relax Documentation/arm64/tagged-pointers.txt
From: Vincenzo Frascino @ 2019-06-13 15:51 UTC (permalink / raw)
To: linux-arm-kernel, linux-doc, linux-mm, linux-arch,
linux-kselftest, linux-kernel
Cc: Catalin Marinas, Will Deacon, Andrey Konovalov, Alexander Viro
In-Reply-To: <20190613155137.47675-1-vincenzo.frascino@arm.com>
On arm64 the TCR_EL1.TBI0 bit has been always enabled hence
the userspace (EL0) is allowed to set a non-zero value in the
top byte but the resulting pointers are not allowed at the
user-kernel syscall ABI boundary.
With the relaxed ABI proposed in this set, it is now possible to pass
tagged pointers to the syscalls, when these pointers are in memory
ranges obtained by an anonymous (MAP_ANONYMOUS) mmap().
Relax the requirements described in tagged-pointers.txt to be compliant
with the behaviours guaranteed by the ARM64 Tagged Address ABI.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
CC: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
---
Documentation/arm64/tagged-pointers.txt | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/Documentation/arm64/tagged-pointers.txt b/Documentation/arm64/tagged-pointers.txt
index a25a99e82bb1..e33af14478e3 100644
--- a/Documentation/arm64/tagged-pointers.txt
+++ b/Documentation/arm64/tagged-pointers.txt
@@ -18,7 +18,8 @@ Passing tagged addresses to the kernel
--------------------------------------
All interpretation of userspace memory addresses by the kernel assumes
-an address tag of 0x00.
+an address tag of 0x00, unless the userspace opts-in the ARM64 Tagged
+Address ABI via the PR_SET_TAGGED_ADDR_CTRL prctl().
This includes, but is not limited to, addresses found in:
@@ -31,18 +32,23 @@ This includes, but is not limited to, addresses found in:
- the frame pointer (x29) and frame records, e.g. when interpreting
them to generate a backtrace or call graph.
-Using non-zero address tags in any of these locations may result in an
-error code being returned, a (fatal) signal being raised, or other modes
-of failure.
+Using non-zero address tags in any of these locations when the
+userspace application did not opt-in to the ARM64 Tagged Address ABI
+may result in an error code being returned, a (fatal) signal being raised,
+or other modes of failure.
-For these reasons, passing non-zero address tags to the kernel via
-system calls is forbidden, and using a non-zero address tag for sp is
-strongly discouraged.
+For these reasons, when the userspace application did not opt-in, passing
+non-zero address tags to the kernel via system calls is forbidden, and using
+a non-zero address tag for sp is strongly discouraged.
Programs maintaining a frame pointer and frame records that use non-zero
address tags may suffer impaired or inaccurate debug and profiling
visibility.
+A definition of the meaning of ARM64 Tagged Address ABI and of the
+guarantees that the ABI provides when the userspace opts-in via prctl()
+can be found in: Documentation/arm64/tagged-address-abi.txt.
+
Preserving tags
---------------
@@ -57,6 +63,9 @@ be preserved.
The architecture prevents the use of a tagged PC, so the upper byte will
be set to a sign-extension of bit 55 on exception return.
+These behaviours are preserved even when the userspace opts-in to the ARM64
+Tagged Address ABI via the PR_SET_TAGGED_ADDR_CTRL prctl().
+
Other considerations
--------------------
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v4 1/2] arm64: Define Documentation/arm64/tagged-address-abi.txt
From: Catalin Marinas @ 2019-06-13 9:20 UTC (permalink / raw)
To: Szabolcs Nagy
Cc: Vincenzo Frascino, linux-arm-kernel@lists.infradead.org,
linux-doc@vger.kernel.org, linux-mm@kvack.org,
linux-arch@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org, nd, Will Deacon, Andrey Konovalov,
Alexander Viro
In-Reply-To: <a90da586-8ff6-4bed-d940-9306d517a18c@arm.com>
Hi Szabolcs,
On Wed, Jun 12, 2019 at 05:30:34PM +0100, Szabolcs Nagy wrote:
> On 12/06/2019 15:21, Vincenzo Frascino wrote:
> > +2. ARM64 Tagged Address ABI
> > +---------------------------
> > +
> > +From the kernel syscall interface prospective, we define, for the purposes
> ^^^^^^^^^^^
> perspective
>
> > +of this document, a "valid tagged pointer" as a pointer that either it has
> > +a zero value set in the top byte or it has a non-zero value, it is in memory
> > +ranges privately owned by a userspace process and it is obtained in one of
> > +the following ways:
> > + - mmap() done by the process itself, where either:
> > + * flags = MAP_PRIVATE | MAP_ANONYMOUS
> > + * flags = MAP_PRIVATE and the file descriptor refers to a regular
> > + file or "/dev/zero"
>
> this does not make it clear if MAP_FIXED or other flags are valid
> (there are many map flags i don't know, but at least fixed should work
> and stack/growsdown. i'd expect anything that's not incompatible with
> private|anon to work).
Just to clarify, this document tries to define the memory ranges from
where tagged addresses can be passed into the kernel in the context
of TBI only (not MTE); that is for hwasan support. FIXED or GROWSDOWN
should not affect this.
> > + - a mapping below sbrk(0) done by the process itself
>
> doesn't the mmap rule cover this?
IIUC it doesn't cover it as that's memory mapped by the kernel
automatically on access vs a pointer returned by mmap(). The statement
above talks about how the address is obtained by the user.
> > + - any memory mapped by the kernel in the process's address space during
> > + creation and following the restrictions presented above (i.e. data, bss,
> > + stack).
>
> OK.
>
> Can a null pointer have a tag?
> (in case NULL is valid to pass to a syscall)
Good point. I don't think it can. We may change this for MTE where we
give a hint tag but no hint address, however, this document only covers
TBI for now.
> > +The ARM64 Tagged Address ABI is an opt-in feature, and an application can
> > +control it using the following prctl()s:
> > + - PR_SET_TAGGED_ADDR_CTRL: can be used to enable the Tagged Address ABI.
> > + - PR_GET_TAGGED_ADDR_CTRL: can be used to check the status of the Tagged
> > + Address ABI.
> > +
> > +As a consequence of invoking PR_SET_TAGGED_ADDR_CTRL prctl() by an applications,
> > +the ABI guarantees the following behaviours:
> > +
> > + - Every current or newly introduced syscall can accept any valid tagged
> > + pointers.
> > +
> > + - If a non valid tagged pointer is passed to a syscall then the behaviour
> > + is undefined.
> > +
> > + - Every valid tagged pointer is expected to work as an untagged one.
> > +
> > + - The kernel preserves any valid tagged pointers and returns them to the
> > + userspace unchanged in all the cases except the ones documented in the
> > + "Preserving tags" paragraph of tagged-pointers.txt.
>
> OK.
>
> i guess pointers of another process are not "valid tagged pointers"
> for the current one, so e.g. in ptrace the ptracer has to clear the
> tags before PEEK etc.
Another good point. Are there any pros/cons here or use-cases? When we
add MTE support, should we handle this differently?
> > +A definition of the meaning of tagged pointers on arm64 can be found in:
> > +Documentation/arm64/tagged-pointers.txt.
> > +
> > +3. ARM64 Tagged Address ABI Exceptions
> > +--------------------------------------
> > +
> > +The behaviours described in paragraph 2, with particular reference to the
> > +acceptance by the syscalls of any valid tagged pointer are not applicable
> > +to the following cases:
> > + - mmap() addr parameter.
> > + - mremap() new_address parameter.
> > + - prctl_set_mm() struct prctl_map fields.
> > + - prctl_set_mm_map() struct prctl_map fields.
>
> i don't understand the exception: does it mean that passing a tagged
> address to these syscalls is undefined?
I'd say it's as undefined as it is right now without these patches. We
may be able to explain this better in the document.
--
Catalin
^ permalink raw reply
* Re: [PATCH v3 2/3] x86: Use static_cpu_has in uaccess region to avoid instrumentation
From: Peter Zijlstra @ 2019-06-13 9:21 UTC (permalink / raw)
To: Marco Elver
Cc: aryabinin, dvyukov, glider, andreyknvl, mark.rutland, hpa, corbet,
tglx, mingo, bp, x86, arnd, jpoimboe, linux-doc, linux-kernel,
linux-arch, kasan-dev
In-Reply-To: <20190531150828.157832-3-elver@google.com>
On Fri, May 31, 2019 at 05:08:30PM +0200, Marco Elver wrote:
> This patch is a pre-requisite for enabling KASAN bitops instrumentation;
> using static_cpu_has instead of boot_cpu_has avoids instrumentation of
> test_bit inside the uaccess region. With instrumentation, the KASAN
> check would otherwise be flagged by objtool.
>
> For consistency, kernel/signal.c was changed to mirror this change,
> however, is never instrumented with KASAN (currently unsupported under
> x86 32bit).
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Thanks!
>
> Signed-off-by: Marco Elver <elver@google.com>
> Suggested-by: H. Peter Anvin <hpa@zytor.com>
> ---
> Changes in v3:
> * Use static_cpu_has instead of moving boot_cpu_has outside uaccess
> region.
>
> Changes in v2:
> * Replaces patch: 'tools/objtool: add kasan_check_* to uaccess
> whitelist'
> ---
> arch/x86/ia32/ia32_signal.c | 2 +-
> arch/x86/kernel/signal.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
> index 629d1ee05599..1cee10091b9f 100644
> --- a/arch/x86/ia32/ia32_signal.c
> +++ b/arch/x86/ia32/ia32_signal.c
> @@ -358,7 +358,7 @@ int ia32_setup_rt_frame(int sig, struct ksignal *ksig,
> put_user_ex(ptr_to_compat(&frame->uc), &frame->puc);
>
> /* Create the ucontext. */
> - if (boot_cpu_has(X86_FEATURE_XSAVE))
> + if (static_cpu_has(X86_FEATURE_XSAVE))
> put_user_ex(UC_FP_XSTATE, &frame->uc.uc_flags);
> else
> put_user_ex(0, &frame->uc.uc_flags);
> diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
> index 364813cea647..52eb1d551aed 100644
> --- a/arch/x86/kernel/signal.c
> +++ b/arch/x86/kernel/signal.c
> @@ -391,7 +391,7 @@ static int __setup_rt_frame(int sig, struct ksignal *ksig,
> put_user_ex(&frame->uc, &frame->puc);
>
> /* Create the ucontext. */
> - if (boot_cpu_has(X86_FEATURE_XSAVE))
> + if (static_cpu_has(X86_FEATURE_XSAVE))
> put_user_ex(UC_FP_XSTATE, &frame->uc.uc_flags);
> else
> put_user_ex(0, &frame->uc.uc_flags);
> --
> 2.22.0.rc1.257.g3120a18244-goog
>
^ permalink raw reply
* Re: [PATCH v4 1/2] arm64: Define Documentation/arm64/tagged-address-abi.txt
From: Catalin Marinas @ 2019-06-13 15:39 UTC (permalink / raw)
To: Dave Martin
Cc: linux-arch, linux-doc, Szabolcs Nagy, Andrey Konovalov,
Will Deacon, linux-kernel, linux-mm, Alexander Viro,
linux-kselftest, Vincenzo Frascino, linux-arm-kernel
In-Reply-To: <20190613132342.GZ28398@e103592.cambridge.arm.com>
On Thu, Jun 13, 2019 at 02:23:43PM +0100, Dave P Martin wrote:
> On Thu, Jun 13, 2019 at 01:28:21PM +0100, Catalin Marinas wrote:
> > On Thu, Jun 13, 2019 at 12:37:32PM +0100, Dave P Martin wrote:
> > > On Thu, Jun 13, 2019 at 11:15:34AM +0100, Vincenzo Frascino wrote:
> > > > On 12/06/2019 16:35, Catalin Marinas wrote:
> > > > > On Wed, Jun 12, 2019 at 03:21:10PM +0100, Vincenzo Frascino wrote:
> > > > >> + - PR_GET_TAGGED_ADDR_CTRL: can be used to check the status of the Tagged
> > > > >> + Address ABI.
> > [...]
> > > Is there a canonical way to detect whether this whole API/ABI is
> > > available? (i.e., try to call this prctl / check for an HWCAP bit,
> > > etc.)
> >
> > The canonical way is a prctl() call. HWCAP doesn't make sense since it's
> > not a hardware feature. If you really want a different way of detecting
> > this (which I don't think it's worth), we can reinstate the AT_FLAGS
> > bit.
>
> Sure, I think this probably makes sense -- I'm still getting my around
> which parts of the design are directly related to MTE and which aren't.
>
> I was a bit concerned about the interaction between
> PR_SET_TAGGED_ADDR_CTRL and the sysctl: the caller might conclude that
> this API is unavailable when actually tagged addresses are stuck on.
>
> I'm not sure whether this matters, but it's a bit weird.
>
> One option would be to change the semantics, so that the sysctl just
> forbids turning tagging from off to on. Alternatively, we could return
> a different error code to distinguish this case.
This is the intention, just to forbid turning tagging on. We could
return -EPERM instead, though my original intent was to simply pretend
that the prctl does not exist like in an older kernel version.
--
Catalin
^ permalink raw reply
* Re: [PATCH v4 18/28] docs: convert docs to ReST and rename to *.rst
From: Mauro Carvalho Chehab @ 2019-06-13 9:58 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Sebastian Reichel, Rafael J. Wysocki,
Viresh Kumar, Len Brown, Pavel Machek, Nishanth Menon,
Stephen Boyd, Liam Girdwood, Mark Brown, Mathieu Poirier,
Suzuki K Poulose, Harry Wei, Alex Shi, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, x86, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, David Airlie, Daniel Vetter,
Bjorn Helgaas, Johannes Berg, David S. Miller, linux-pm,
linux-arm-kernel, intel-gfx, dri-devel, linux-pci, linux-wireless,
netdev
In-Reply-To: <7dc94cb4-ebf1-22ab-29c9-fcb2b875a9ac@csail.mit.edu>
Em Wed, 12 Jun 2019 17:25:39 -0700
"Srivatsa S. Bhat" <srivatsa@csail.mit.edu> escreveu:
> On 6/12/19 10:52 AM, Mauro Carvalho Chehab wrote:
> > Convert the PM documents to ReST, in order to allow them to
> > build with Sphinx.
> >
> > The conversion is actually:
> > - add blank lines and identation in order to identify paragraphs;
> > - fix tables markups;
> > - add some lists markups;
> > - mark literal blocks;
> > - adjust title markups.
> >
> > At its new index.rst, let's add a :orphan: while this is not linked to
> > the main index.rst file, in order to avoid build warnings.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> > Acked-by: Mark Brown <broonie@kernel.org>
> > ---
>
> [...]
>
> > diff --git a/Documentation/power/suspend-and-cpuhotplug.txt b/Documentation/power/suspend-and-cpuhotplug.rst
> > similarity index 90%
> > rename from Documentation/power/suspend-and-cpuhotplug.txt
> > rename to Documentation/power/suspend-and-cpuhotplug.rst
> > index a8751b8df10e..9df664f5423a 100644
> > --- a/Documentation/power/suspend-and-cpuhotplug.txt
> > +++ b/Documentation/power/suspend-and-cpuhotplug.rst
> > @@ -1,10 +1,15 @@
> > +====================================================================
> > Interaction of Suspend code (S3) with the CPU hotplug infrastructure
> > +====================================================================
> >
> > - (C) 2011 - 2014 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
> > +(C) 2011 - 2014 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
> >
> >
> > -I. How does the regular CPU hotplug code differ from how the Suspend-to-RAM
> > - infrastructure uses it internally? And where do they share common code?
> > +I. Differences between CPU hotplug and Suspend-to-RAM
> > +======================================================
> > +
> > +How does the regular CPU hotplug code differ from how the Suspend-to-RAM
> > +infrastructure uses it internally? And where do they share common code?
> >
> > Well, a picture is worth a thousand words... So ASCII art follows :-)
> >
>
> [...]
>
> > @@ -101,7 +108,7 @@ execution during resume):
> >
> > It is to be noted here that the system_transition_mutex lock is acquired at the very
> > beginning, when we are just starting out to suspend, and then released only
> > -after the entire cycle is complete (i.e., suspend + resume).
> > +after the entire cycle is complete (i.e., suspend + resume)::
> >
>
> I think that should be a period, not a colon, because it is clarifying
> the text above it (as opposed to referring to the example below it).
>
> Other than that, for suspend-and-cpuhotplug.txt:
>
> Acked-by: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu>
Ah, ok. I'll change it to:
after the entire cycle is complete (i.e., suspend + resume).
::
and add your acked-by.
>
> Regards,
> Srivatsa
> VMware Photon OS
Thanks,
Mauro
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox