* [PATCH v3 20/20] docs: pci: fix broken links due to conversion from pci.txt to pci.rst
From: Mauro Carvalho Chehab @ 2019-06-07 18:54 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Alan Stern, Andrea Parri, Will Deacon,
Peter Zijlstra, Boqun Feng, Nicholas Piggin, David Howells,
Jade Alglave, Luc Maranget, Paul E. McKenney, Akira Yokosawa,
Daniel Lustig, Don Brace, James E.J. Bottomley,
Martin K. Petersen, linux-arch, esc.storagedev, linux-scsi
In-Reply-To: <ff457774d46d96e8fe56b45409aba39d87a8672a.1559933665.git.mchehab+samsung@kernel.org>
Some documentation files were still pointing to the old place.
Fixes: 229b4e0728e0 ("Documentation: PCI: convert pci.txt to reST")
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/memory-barriers.txt | 2 +-
Documentation/translations/ko_KR/memory-barriers.txt | 2 +-
drivers/scsi/hpsa.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index f70ebcdfe592..f4170aae1d75 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -548,7 +548,7 @@ There are certain things that the Linux kernel memory barriers do not guarantee:
[*] For information on bus mastering DMA and coherency please read:
- Documentation/PCI/pci.txt
+ Documentation/PCI/pci.rst
Documentation/DMA-API-HOWTO.txt
Documentation/DMA-API.txt
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
index db0b9d8619f1..07725b1df002 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -569,7 +569,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE
[*] 버스 마스터링 DMA 와 일관성에 대해서는 다음을 참고하시기 바랍니다:
- Documentation/PCI/pci.txt
+ Documentation/PCI/pci.rst
Documentation/DMA-API-HOWTO.txt
Documentation/DMA-API.txt
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 1bef1da273c2..53df6f7dd3f9 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -7760,7 +7760,7 @@ static void hpsa_free_pci_init(struct ctlr_info *h)
hpsa_disable_interrupt_mode(h); /* pci_init 2 */
/*
* call pci_disable_device before pci_release_regions per
- * Documentation/PCI/pci.txt
+ * Documentation/PCI/pci.rst
*/
pci_disable_device(h->pdev); /* pci_init 1 */
pci_release_regions(h->pdev); /* pci_init 2 */
@@ -7843,7 +7843,7 @@ static int hpsa_pci_init(struct ctlr_info *h)
clean1:
/*
* call pci_disable_device before pci_release_regions per
- * Documentation/PCI/pci.txt
+ * Documentation/PCI/pci.rst
*/
pci_disable_device(h->pdev);
pci_release_regions(h->pdev);
--
2.21.0
^ permalink raw reply related
* [PATCH v3 13/20] docs: net: dpio-driver.rst: fix two codeblock warnings
From: Mauro Carvalho Chehab @ 2019-06-07 18:54 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, David S. Miller, netdev
In-Reply-To: <ff457774d46d96e8fe56b45409aba39d87a8672a.1559933665.git.mchehab+samsung@kernel.org>
Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst:43: WARNING: Definition list ends without a blank line; unexpected unindent.
Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst:63: WARNING: Unexpected indentation. looking for now-outdated files... none found
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
.../networking/device_drivers/freescale/dpaa2/dpio-driver.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst b/Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst
index 5045df990a4c..17dbee1ac53e 100644
--- a/Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst
+++ b/Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst
@@ -39,8 +39,7 @@ The Linux DPIO driver consists of 3 primary components--
DPIO service-- provides APIs to other Linux drivers for services
- QBman portal interface-- sends portal commands, gets responses
-::
+ QBman portal interface-- sends portal commands, gets responses::
fsl-mc other
bus drivers
@@ -60,6 +59,7 @@ The Linux DPIO driver consists of 3 primary components--
The diagram below shows how the DPIO driver components fit with the other
DPAA2 Linux driver components::
+
+------------+
| OS Network |
| Stack |
--
2.21.0
^ permalink raw reply related
* [PATCH v3 07/20] docs: amd-memory-encryption.rst get rid of warnings
From: Mauro Carvalho Chehab @ 2019-06-07 18:54 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Paolo Bonzini, Radim Krčmář, kvm
In-Reply-To: <ff457774d46d96e8fe56b45409aba39d87a8672a.1559933665.git.mchehab+samsung@kernel.org>
Get rid of those warnings:
Documentation/virtual/kvm/amd-memory-encryption.rst:244: WARNING: Citation [white-paper] is not referenced.
Documentation/virtual/kvm/amd-memory-encryption.rst:246: WARNING: Citation [amd-apm] is not referenced.
Documentation/virtual/kvm/amd-memory-encryption.rst:247: WARNING: Citation [kvm-forum] is not referenced.
For references that aren't mentioned at the text by adding an
explicit reference to them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
---
Documentation/virtual/kvm/amd-memory-encryption.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/virtual/kvm/amd-memory-encryption.rst b/Documentation/virtual/kvm/amd-memory-encryption.rst
index 659bbc093b52..d18c97b4e140 100644
--- a/Documentation/virtual/kvm/amd-memory-encryption.rst
+++ b/Documentation/virtual/kvm/amd-memory-encryption.rst
@@ -241,6 +241,9 @@ Returns: 0 on success, -negative on error
References
==========
+
+See [white-paper]_, [api-spec]_, [amd-apm]_ and [kvm-forum]_ for more info.
+
.. [white-paper] http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
.. [api-spec] http://support.amd.com/TechDocs/55766_SEV-KM_API_Specification.pdf
.. [amd-apm] http://support.amd.com/TechDocs/24593.pdf (section 15.34)
--
2.21.0
^ permalink raw reply related
* [PATCH v3 04/20] docs: mm: numaperf.rst: get rid of a build warning
From: Mauro Carvalho Chehab @ 2019-06-07 18:54 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <ff457774d46d96e8fe56b45409aba39d87a8672a.1559933665.git.mchehab+samsung@kernel.org>
When building it, it gets this warning:
Documentation/admin-guide/mm/numaperf.rst:168: WARNING: Footnote [1] is not referenced.
The problem is that this is not really a reference, as it is not
mentioned within the documentation.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/admin-guide/mm/numaperf.rst | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/mm/numaperf.rst b/Documentation/admin-guide/mm/numaperf.rst
index c067ed145158..a80c3c37226e 100644
--- a/Documentation/admin-guide/mm/numaperf.rst
+++ b/Documentation/admin-guide/mm/numaperf.rst
@@ -165,5 +165,6 @@ write-through caching.
========
See Also
========
-.. [1] https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf
- Section 5.2.27
+
+[1] https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf
+- Section 5.2.27
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2 00/22] Some documentation fixes
From: Mauro Carvalho Chehab @ 2019-06-07 18:44 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, netdev, bpf
In-Reply-To: <20190607115521.6bf39030@lwn.net>
Em Fri, 7 Jun 2019 11:55:21 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Tue, 4 Jun 2019 11:17:34 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > Fix several warnings and broken links.
> >
> > This series was generated against linux-next, but was rebased to be applied at
> > docs-next. It should apply cleanly on either tree.
> >
> > There's a git tree with all of them applied on the top of docs/docs-next
> > at:
> >
> > https://git.linuxtv.org/mchehab/experimental.git/log/?h=fix_doc_links_v2
>
> So I'll admit I've kind of lost track of which of these are applied, which
> have comments, etc. When you feel things have settled, can you get me an
> updated set and I'll get them applied?
What I usually do here to check what was already applied (besides
looking e-mails) is to reset my tree against yours, then pull from
linux-next and pull from my old branch with those patches.
Then, I reset again to your tree, in order to make easier for you
to apply. It should be noticed that, due to this, you might actually
see a few more warnings on your tree, if a patch on this series
fix an issue that it is at linux next but didn't arrive your
tree.
Yet, all patches apply cleanly on your tree.
After doing that, there are 17 patches yet to be applied. Two new
patches are now needed too, due to vfs.txt -> vfs.rst and
pci.txt -> pci.rst renames.
The patches against your tree are at:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=fix_doc_links_v3.3
For convenience, I'm sending them again as a new patch series
(with the two extra patches fixing the recent issues).
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v10 2/3] watchdog: introduce CONFIG_WATCHDOG_OPEN_TIMEOUT
From: Guenter Roeck @ 2019-06-07 18:39 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: linux-watchdog@vger.kernel.org, Wim Van Sebroeck, Jonathan Corbet,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Esben Haabendal, Jerry Hoemann, Rasmus Villemoes
In-Reply-To: <20190605140628.618-3-rasmus.villemoes@prevas.dk>
On Wed, Jun 05, 2019 at 02:06:43PM +0000, Rasmus Villemoes wrote:
> This allows setting a default value for the watchdog.open_timeout
> commandline parameter via Kconfig.
>
> Some BSPs allow remote updating of the kernel image and root file
> system, but updating the bootloader requires physical access. Hence, if
> one has a firmware update that requires relaxing the
> watchdog.open_timeout a little, the value used must be baked into the
> kernel image itself and cannot come from the u-boot environment via the
> kernel command line.
>
> Being able to set the initial value in .config doesn't change the fact
> that the value on the command line, if present, takes precedence, and is
> of course immensely useful for development purposes while one has
> console acccess, as well as usable in the cases where one can make a
> permanent update of the kernel command line.
>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> Documentation/watchdog/watchdog-parameters.txt | 8 ++++----
> drivers/watchdog/Kconfig | 9 +++++++++
> drivers/watchdog/watchdog_dev.c | 5 +++--
> 3 files changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt
> index 32d3606caa65..ec919dc895ff 100644
> --- a/Documentation/watchdog/watchdog-parameters.txt
> +++ b/Documentation/watchdog/watchdog-parameters.txt
> @@ -11,10 +11,10 @@ modules.
> The watchdog core parameter watchdog.open_timeout is the maximum time,
> in seconds, for which the watchdog framework will take care of pinging
> a running hardware watchdog until userspace opens the corresponding
> -/dev/watchdogN device. A value of 0 (the default) means an infinite
> -timeout. Setting this to a non-zero value can be useful to ensure that
> -either userspace comes up properly, or the board gets reset and allows
> -fallback logic in the bootloader to try something else.
> +/dev/watchdogN device. A value of 0 means an infinite timeout. Setting
> +this to a non-zero value can be useful to ensure that either userspace
> +comes up properly, or the board gets reset and allows fallback logic
> +in the bootloader to try something else.
>
>
> -------------------------------------------------
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index ffe754539f5a..a8bd621e12f8 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -58,6 +58,15 @@ config WATCHDOG_HANDLE_BOOT_ENABLED
> the watchdog on its own. Thus if your userspace does not start fast
> enough your device will reboot.
>
> +config WATCHDOG_OPEN_TIMEOUT
> + int "Timeout value for opening watchdog device"
> + default 0
> + help
> + The maximum time, in seconds, for which the watchdog framework takes
> + care of pinging a hardware watchdog. A value of 0 means infinite. The
> + value set here can be overridden by the commandline parameter
> + "watchdog.open_timeout".
> +
> config WATCHDOG_SYSFS
> bool "Read different watchdog information through sysfs"
> help
> diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
> index e4b51db48f0e..334b810db2cf 100644
> --- a/drivers/watchdog/watchdog_dev.c
> +++ b/drivers/watchdog/watchdog_dev.c
> @@ -88,7 +88,7 @@ static struct kthread_worker *watchdog_kworker;
> static bool handle_boot_enabled =
> IS_ENABLED(CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED);
>
> -static unsigned open_timeout;
> +static unsigned open_timeout = CONFIG_WATCHDOG_OPEN_TIMEOUT;
>
> static bool watchdog_past_open_deadline(struct watchdog_core_data *data)
> {
> @@ -1214,4 +1214,5 @@ MODULE_PARM_DESC(handle_boot_enabled,
>
> module_param(open_timeout, uint, 0644);
> MODULE_PARM_DESC(open_timeout,
> - "Maximum time (in seconds, 0 means infinity) for userspace to take over a running watchdog (default=0)");
> + "Maximum time (in seconds, 0 means infinity) for userspace to take over a running watchdog (default="
> + __MODULE_STRING(CONFIG_WATCHDOG_OPEN_TIMEOUT) ")");
^ permalink raw reply
* Re: [PATCH v10 1/3] watchdog: introduce watchdog.open_timeout commandline parameter
From: Guenter Roeck @ 2019-06-07 18:38 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: linux-watchdog@vger.kernel.org, Wim Van Sebroeck, Jonathan Corbet,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Esben Haabendal, Jerry Hoemann, Rasmus Villemoes
In-Reply-To: <20190605140628.618-2-rasmus.villemoes@prevas.dk>
On Wed, Jun 05, 2019 at 02:06:41PM +0000, Rasmus Villemoes wrote:
> The watchdog framework takes care of feeding a hardware watchdog until
> userspace opens /dev/watchdogN. If that never happens for some reason
> (buggy init script, corrupt root filesystem or whatnot) but the kernel
> itself is fine, the machine stays up indefinitely. This patch allows
> setting an upper limit for how long the kernel will take care of the
> watchdog, thus ensuring that the watchdog will eventually reset the
> machine.
>
> A value of 0 (the default) means infinite timeout, preserving the
> current behaviour.
>
> This is particularly useful for embedded devices where some fallback
> logic is implemented in the bootloader (e.g., use a different root
> partition, boot from network, ...).
>
> There is already handle_boot_enabled serving a similar purpose. However,
> such a binary choice is unsuitable if the hardware watchdog cannot be
> programmed by the bootloader to provide a timeout long enough for
> userspace to get up and running. Many of the embedded devices we see use
> external (gpio-triggered) watchdogs with a fixed timeout of the order of
> 1-2 seconds.
>
> The open timeout only applies for the first open from
> userspace. Should userspace need to close the watchdog device, with
> the intention of re-opening it shortly, the application can emulate
> the open timeout feature by combining the nowayout feature with an
> appropriate WDIOC_SETTIMEOUT immediately prior to closing the device.
>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> .../watchdog/watchdog-parameters.txt | 8 +++++
> drivers/watchdog/watchdog_dev.c | 36 ++++++++++++++++++-
> 2 files changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt
> index 0b88e333f9e1..32d3606caa65 100644
> --- a/Documentation/watchdog/watchdog-parameters.txt
> +++ b/Documentation/watchdog/watchdog-parameters.txt
> @@ -8,6 +8,14 @@ See Documentation/admin-guide/kernel-parameters.rst for information on
> providing kernel parameters for builtin drivers versus loadable
> modules.
>
> +The watchdog core parameter watchdog.open_timeout is the maximum time,
> +in seconds, for which the watchdog framework will take care of pinging
> +a running hardware watchdog until userspace opens the corresponding
> +/dev/watchdogN device. A value of 0 (the default) means an infinite
> +timeout. Setting this to a non-zero value can be useful to ensure that
> +either userspace comes up properly, or the board gets reset and allows
> +fallback logic in the bootloader to try something else.
> +
>
> -------------------------------------------------
> acquirewdt:
> diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
> index 252a7c7b6592..e4b51db48f0e 100644
> --- a/drivers/watchdog/watchdog_dev.c
> +++ b/drivers/watchdog/watchdog_dev.c
> @@ -69,6 +69,7 @@ struct watchdog_core_data {
> struct mutex lock;
> ktime_t last_keepalive;
> ktime_t last_hw_keepalive;
> + ktime_t open_deadline;
> struct hrtimer timer;
> struct kthread_work work;
> unsigned long status; /* Internal status bits */
> @@ -87,6 +88,19 @@ static struct kthread_worker *watchdog_kworker;
> static bool handle_boot_enabled =
> IS_ENABLED(CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED);
>
> +static unsigned open_timeout;
> +
> +static bool watchdog_past_open_deadline(struct watchdog_core_data *data)
> +{
> + return ktime_after(ktime_get(), data->open_deadline);
> +}
> +
> +static void watchdog_set_open_deadline(struct watchdog_core_data *data)
> +{
> + data->open_deadline = open_timeout ?
> + ktime_get() + ktime_set(open_timeout, 0) : KTIME_MAX;
> +}
> +
> static inline bool watchdog_need_worker(struct watchdog_device *wdd)
> {
> /* All variables in milli-seconds */
> @@ -211,7 +225,13 @@ static bool watchdog_worker_should_ping(struct watchdog_core_data *wd_data)
> {
> struct watchdog_device *wdd = wd_data->wdd;
>
> - return wdd && (watchdog_active(wdd) || watchdog_hw_running(wdd));
> + if (!wdd)
> + return false;
> +
> + if (watchdog_active(wdd))
> + return true;
> +
> + return watchdog_hw_running(wdd) && !watchdog_past_open_deadline(wd_data);
> }
>
> static void watchdog_ping_work(struct kthread_work *work)
> @@ -824,6 +844,15 @@ static int watchdog_open(struct inode *inode, struct file *file)
> if (!hw_running)
> kref_get(&wd_data->kref);
>
> + /*
> + * open_timeout only applies for the first open from
> + * userspace. Set open_deadline to infinity so that the kernel
> + * will take care of an always-running hardware watchdog in
> + * case the device gets magic-closed or WDIOS_DISABLECARD is
> + * applied.
> + */
> + wd_data->open_deadline = KTIME_MAX;
> +
> /* dev/watchdog is a virtual (and thus non-seekable) filesystem */
> return stream_open(inode, file);
>
> @@ -983,6 +1012,7 @@ static int watchdog_cdev_register(struct watchdog_device *wdd, dev_t devno)
>
> /* Record time of most recent heartbeat as 'just before now'. */
> wd_data->last_hw_keepalive = ktime_sub(ktime_get(), 1);
> + watchdog_set_open_deadline(wd_data);
>
> /*
> * If the watchdog is running, prevent its driver from being unloaded,
> @@ -1181,3 +1211,7 @@ module_param(handle_boot_enabled, bool, 0444);
> MODULE_PARM_DESC(handle_boot_enabled,
> "Watchdog core auto-updates boot enabled watchdogs before userspace takes over (default="
> __MODULE_STRING(IS_ENABLED(CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED)) ")");
> +
> +module_param(open_timeout, uint, 0644);
> +MODULE_PARM_DESC(open_timeout,
> + "Maximum time (in seconds, 0 means infinity) for userspace to take over a running watchdog (default=0)");
^ permalink raw reply
* Re: [PATCH v10 3/3] watchdog: make the device time out at open_deadline when open_timeout is used
From: Guenter Roeck @ 2019-06-07 18:38 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: linux-watchdog@vger.kernel.org, Wim Van Sebroeck, Jonathan Corbet,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Esben Haabendal, Jerry Hoemann, Rasmus Villemoes
In-Reply-To: <20190605140628.618-4-rasmus.villemoes@prevas.dk>
On Wed, Jun 05, 2019 at 02:06:44PM +0000, Rasmus Villemoes wrote:
> When the watchdog device is not open by userspace, the kernel takes
> care of pinging it. When the open_timeout feature is in use, we should
> ensure that the hardware fires close to open_timeout seconds after the
> kernel has assumed responsibility for the device.
>
> To do this, simply reuse the logic that is already in place for
> ensuring the same thing when userspace is responsible for regularly
> pinging the device:
>
> - When watchdog_active(wdd), this patch doesn't change anything.
>
> - When !watchdoc_active(wdd), the "virtual timeout" should be taken to
s/watchdoc_active/watchdog_active/
otherwise
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> be ->open_deadline". When the open_timeout feature is not used or the
> device has been opened at least once, ->open_deadline is KTIME_MAX,
> and the arithmetic ends up returning keepalive_interval as we used to.
>
> This has been tested on a Wandboard with various combinations of
> open_timeout and timeout-sec properties for the on-board watchdog by
> booting with 'init=/bin/sh', timestamping the lines on the serial
> console, and comparing the timestamp of the 'imx2-wdt 20bc000.wdog:
> timeout nnn sec' line with the timestamp of the 'U-Boot SPL ...'
> line (which appears just after reset).
>
> Suggested-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> ---
> drivers/watchdog/watchdog_dev.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
> index 334b810db2cf..edfb884044e0 100644
> --- a/drivers/watchdog/watchdog_dev.c
> +++ b/drivers/watchdog/watchdog_dev.c
> @@ -133,14 +133,15 @@ static ktime_t watchdog_next_keepalive(struct watchdog_device *wdd)
> ktime_t virt_timeout;
> unsigned int hw_heartbeat_ms;
>
> - virt_timeout = ktime_add(wd_data->last_keepalive,
> - ms_to_ktime(timeout_ms));
> + if (watchdog_active(wdd))
> + virt_timeout = ktime_add(wd_data->last_keepalive,
> + ms_to_ktime(timeout_ms));
> + else
> + virt_timeout = wd_data->open_deadline;
> +
> hw_heartbeat_ms = min_not_zero(timeout_ms, wdd->max_hw_heartbeat_ms);
> keepalive_interval = ms_to_ktime(hw_heartbeat_ms / 2);
>
> - if (!watchdog_active(wdd))
> - return keepalive_interval;
> -
> /*
> * To ensure that the watchdog times out wdd->timeout seconds
> * after the most recent ping from userspace, the last
^ permalink raw reply
* Re: [PATCH] Documentation: xfs: Fix typo
From: Darrick J. Wong @ 2019-06-07 18:34 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: Shiyang Ruan, linux-doc, linux-kernel, linux-xfs
In-Reply-To: <20190607114415.32cb32dd@lwn.net>
On Fri, Jun 07, 2019 at 11:44:15AM -0600, Jonathan Corbet wrote:
> On Thu, 9 May 2019 11:05:49 +0800
> Shiyang Ruan <ruansy.fnst@cn.fujitsu.com> wrote:
>
> > In "Y+P" of this line, there are two non-ASCII characters(0xd9 0x8d)
> > following behind the 'Y'. Shown as a small '=' under the '+' in VIM
> > and a '賺' in webpage[1].
> >
> > I think it's a mistake and remove these strange characters.
> >
> > [1]: https://www.kernel.org/doc/Documentation/filesystems/xfs-delayed-logging-design.txt
> >
> > Signed-off-by: Shiyang Ruan <ruansy.fnst@cn.fujitsu.com>
> > ---
> > Documentation/filesystems/xfs-delayed-logging-design.txt | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/filesystems/xfs-delayed-logging-design.txt b/Documentation/filesystems/xfs-delayed-logging-design.txt
> > index 2ce36439c09f..9a6dd289b17b 100644
> > --- a/Documentation/filesystems/xfs-delayed-logging-design.txt
> > +++ b/Documentation/filesystems/xfs-delayed-logging-design.txt
> > @@ -34,7 +34,7 @@ transaction:
> > D A+B+C+D X+n+m+o
> > <object written to disk>
> > E E Y (> X+n+m+o)
> > - F E+F Yٍ+p
> > + F E+F Y+p
>
> OK, that does look funky, applied.
>
> This patch probably should have been copied to the XFS list (added), even
> though get_maintainer.pl doesn't know that.
Yeah, it's "Y+p" not "Y<weird plusequals thing>p" in the xfs
documentation repo:
https://git.kernel.org/pub/scm/fs/xfs/xfs-documentation.git/tree/design/XFS_Filesystem_Structure/delayed_logging.asciidoc
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
I doubt the value of maintaining duplicate copies of this document in
the kernel and the xfs documentation repo, and since the xfs docs and
kernel licences aren't compatible maybe we should withdraw one...
...but since Dave is the author I'm gonna punt to him. IMHO either we
should claim responsibility for those files in MAINTAINERS or drop them.
:)
Thanks for the heads-up,
--D
> Thanks,
>
> jon
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Andy Lutomirski @ 2019-06-07 18:29 UTC (permalink / raw)
To: Dave Hansen
Cc: Peter Zijlstra, Yu-cheng Yu, x86, H. Peter Anvin, Thomas Gleixner,
Ingo Molnar, linux-kernel, linux-doc, linux-mm, linux-arch,
linux-api, Arnd Bergmann, Balbir Singh, Borislav Petkov,
Cyrill Gorcunov, Dave Hansen, Eugene Syromiatnikov,
Florian Weimer, H.J. Lu, Jann Horn, Jonathan Corbet, Kees Cook,
Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek,
Randy Dunlap, Ravi V. Shankar, Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <b3de4110-5366-fdc7-a960-71dea543a42f@intel.com>
> On Jun 7, 2019, at 10:59 AM, Dave Hansen <dave.hansen@intel.com> wrote:
>
>> On 6/7/19 10:43 AM, Peter Zijlstra wrote:
>> I've no idea what the kernel should do; since you failed to answer the
>> question what happens when you point this to garbage.
>>
>> Does it then fault or what?
>
> Yeah, I think you'll fault with a rather mysterious CR2 value since
> you'll go look at the instruction that faulted and not see any
> references to the CR2 value.
>
> I think this new MSR probably needs to get included in oops output when
> CET is enabled.
This shouldn’t be able to OOPS because it only happens at CPL 3, right? We should put it into core dumps, though.
>
> Why don't we require that a VMA be in place for the entire bitmap?
> Don't we need a "get" prctl function too in case something like a JIT is
> running and needs to find the location of this bitmap to set bits itself?
>
> Or, do we just go whole-hog and have the kernel manage the bitmap
> itself. Our interface here could be:
>
> prctl(PR_MARK_CODE_AS_LEGACY, start, size);
>
> and then have the kernel allocate and set the bitmap for those code
> locations.
Given that the format depends on the VA size, this might be a good idea. I bet we can reuse the special mapping infrastructure for this — the VMA could
be a MAP_PRIVATE special mapping named [cet_legacy_bitmap] or similar, and we can even make special rules to core dump it intelligently if needed. And we can make mremap() on it work correctly if anyone (CRIU?) cares.
Hmm. Can we be creative and skip populating it with zeros? The CPU should only ever touch a page if we miss an ENDBR on it, so, in normal operation, we don’t need anything to be there. We could try to prevent anyone from *reading* it outside of ENDBR tracking if we want to avoid people accidentally wasting lots of memory by forcing it to be fully populated when the read it.
The one downside is this forces it to be per-mm, but that seems like a generally reasonable model anyway.
This also gives us an excellent opportunity to make it read-only as seen from userspace to prevent exploits from just poking it full of ones before redirecting execution.
^ permalink raw reply
* Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file
From: Dave Martin @ 2019-06-07 18:01 UTC (permalink / raw)
To: Yu-cheng Yu
Cc: x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel,
linux-doc, linux-mm, linux-arch, linux-api, Arnd Bergmann,
Andy Lutomirski, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Peter Zijlstra, Randy Dunlap,
Ravi V. Shankar, Vedvyas Shanbhogue
In-Reply-To: <20190606200646.3951-23-yu-cheng.yu@intel.com>
On Thu, Jun 06, 2019 at 01:06:41PM -0700, Yu-cheng Yu wrote:
> An ELF file's .note.gnu.property indicates features the executable file
> can support. For example, the property GNU_PROPERTY_X86_FEATURE_1_AND
> indicates the file supports GNU_PROPERTY_X86_FEATURE_1_IBT and/or
> GNU_PROPERTY_X86_FEATURE_1_SHSTK.
>
> With this patch, if an arch needs to setup features from ELF properties,
> it needs CONFIG_ARCH_USE_GNU_PROPERTY to be set, and a specific
> arch_setup_property().
>
> For example, for X86_64:
>
> int arch_setup_property(void *ehdr, void *phdr, struct file *f, bool inter)
> {
> int r;
> uint32_t property;
>
> r = get_gnu_property(ehdr, phdr, f, GNU_PROPERTY_X86_FEATURE_1_AND,
> &property);
> ...
> }
Although this code works for the simple case, I have some concerns about
some aspects of the implementation here. There appear to be some bounds
checking / buffer overrun issues, and the code seems quite complex.
Maybe this patch tries too hard to be compatible with toolchains that do
silly things such as embedding huge notes in an executable, or mixing
NT_GNU_PROPERTY_TYPE_0 in a single PT_NOTE with a load of junk not
relevant to the loader. I wonder whether Linux can dictate what
interpretation(s) of the ELF specs it is prepared to support, rather than
trying to support absolutely anything.
I've commented on some potential issues below, but my review isn't
exhaustive -- I may also have simply not understood the code in some
cases, so I apologise in advance for that!
I've also marked a few coding style nits that make the code harder to
read than necessary (but this is partly a matter of taste).
Comments below.
Cheers
---Dave
>
> Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> ---
> fs/Kconfig.binfmt | 3 +
> fs/Makefile | 1 +
> fs/binfmt_elf.c | 13 ++
> fs/gnu_property.c | 351 +++++++++++++++++++++++++++++++++++++++
> include/linux/elf.h | 12 ++
> include/uapi/linux/elf.h | 14 ++
> 6 files changed, 394 insertions(+)
> create mode 100644 fs/gnu_property.c
>
> diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
> index f87ddd1b6d72..397138ab305b 100644
> --- a/fs/Kconfig.binfmt
> +++ b/fs/Kconfig.binfmt
> @@ -36,6 +36,9 @@ config COMPAT_BINFMT_ELF
> config ARCH_BINFMT_ELF_STATE
> bool
>
> +config ARCH_USE_GNU_PROPERTY
> + bool
> +
> config BINFMT_ELF_FDPIC
> bool "Kernel support for FDPIC ELF binaries"
> default y if !BINFMT_ELF
> diff --git a/fs/Makefile b/fs/Makefile
> index c9aea23aba56..b69f18c14e09 100644
> --- a/fs/Makefile
> +++ b/fs/Makefile
> @@ -44,6 +44,7 @@ obj-$(CONFIG_BINFMT_ELF) += binfmt_elf.o
> obj-$(CONFIG_COMPAT_BINFMT_ELF) += compat_binfmt_elf.o
> obj-$(CONFIG_BINFMT_ELF_FDPIC) += binfmt_elf_fdpic.o
> obj-$(CONFIG_BINFMT_FLAT) += binfmt_flat.o
> +obj-$(CONFIG_ARCH_USE_GNU_PROPERTY) += gnu_property.o
>
> obj-$(CONFIG_FS_MBCACHE) += mbcache.o
> obj-$(CONFIG_FS_POSIX_ACL) += posix_acl.o
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 8264b468f283..c3ea73787e93 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -1080,6 +1080,19 @@ static int load_elf_binary(struct linux_binprm *bprm)
> goto out_free_dentry;
> }
>
> + if (interpreter) {
> + retval = arch_setup_property(&loc->interp_elf_ex,
> + interp_elf_phdata,
> + interpreter, true);
> + } else {
> + retval = arch_setup_property(&loc->elf_ex,
> + elf_phdata,
> + bprm->file, false);
> + }
> +
> + if (retval < 0)
> + goto out_free_dentry;
> +
> if (interpreter) {
> unsigned long interp_map_addr = 0;
>
> diff --git a/fs/gnu_property.c b/fs/gnu_property.c
> new file mode 100644
> index 000000000000..9c4d1d5ebf00
> --- /dev/null
> +++ b/fs/gnu_property.c
> @@ -0,0 +1,351 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Extract an ELF file's .note.gnu.property.
> + *
> + * The path from the ELF header to the note section is the following:
> + * elfhdr->elf_phdr->elf_note->property[].
> + */
> +
> +#include <uapi/linux/elf-em.h>
> +#include <linux/processor.h>
> +#include <linux/binfmts.h>
> +#include <linux/elf.h>
> +#include <linux/slab.h>
> +#include <linux/fs.h>
> +#include <linux/uaccess.h>
> +#include <linux/string.h>
> +#include <linux/compat.h>
> +
> +/*
> + * The .note.gnu.property layout:
> + *
> + * struct elf_note {
> + * u32 n_namesz; --> sizeof(n_name[]); always (4)
> + * u32 n_ndescsz;--> sizeof(property[])
> + * u32 n_type; --> always NT_GNU_PROPERTY_TYPE_0
> + * };
> + * char n_name[4]; --> always 'GNU\0'
> + *
> + * struct {
> + * struct gnu_property {
> + * u32 pr_type;
> + * u32 pr_datasz;
> + * };
> + * u8 pr_data[pr_datasz];
> + * }[];
> + */
> +
> +#define BUF_SIZE (PAGE_SIZE / 4)
Nit: magic number in disguise. What does the size of ELF notes have
to do with the page size?
> +
> +typedef bool (test_item_fn)(void *buf, u32 *arg, u32 type);
> +typedef void *(next_item_fn)(void *buf, u32 *arg, u32 type);
> +
> +static inline bool test_note_type(void *buf, u32 *align, u32 note_type)
> +{
> + struct elf_note *n = buf;
> +
> + return ((n->n_type == note_type) && (n->n_namesz == 4) &&
> + (memcmp(n + 1, "GNU", 4) == 0));
> +}
> +
> +static inline void *next_note(void *buf, u32 *align, u32 note_type)
> +{
> + struct elf_note *n = buf;
> + u64 size;
> +
> + if (check_add_overflow((u64)sizeof(*n), (u64)n->n_namesz, &size))
> + return NULL;
sizeof(*n) is a small integer under our control, and n->n_namesz is a
u32.
So, I'm not sure how we would overflow 64 bits here, although if we can
get arbitrarily close to ~(u64)0 then:
> +
> + size = round_up(size, *align);
this can overflow too.
> +
> + if (check_add_overflow(size, (u64)n->n_descsz, &size))
> + return NULL;
> +
> + size = round_up(size, *align);
Similarly here.
> +
> + if (buf + size < buf)
Isn't this undefined behaviour of it overflows? If so, the compiler can
probably delete the check entirely, making it useless. Does UBSAN warn
about it?
> + return NULL;
> + else
> + return (buf + size);
Nit: Unnecessary () (There are surplus () all over this patch; I won't
comment on them all.)
> +}
> +
> +static inline bool test_property(void *buf, u32 *max_type, u32 pr_type)
> +{
> + struct gnu_property *pr = buf;
> +
> + /*
> + * Property types must be in ascending order.
> + * Keep track of the max when testing each.
> + */
> + if (pr->pr_type > *max_type)
> + *max_type = pr->pr_type;
Is this worthwhile? In general we don't try very hard to check that the
ELF file is well-formed.
Ideally we could search by binary chop, but the property size is
variable, so the sortedness is useless to us (yay).
> +
> + return (pr->pr_type == pr_type);
> +}
> +
> +static inline void *next_property(void *buf, u32 *max_type, u32 pr_type)
Nit: does this need to be inline? The compiler's guess is usually good
enough...
> +{
> + struct gnu_property *pr = buf;
> +
> + if ((buf + sizeof(*pr) + pr->pr_datasz < buf) ||
Nit: random extra space, redundant (), etc.
> + (pr->pr_type > pr_type) ||
> + (pr->pr_type > *max_type))
> + return NULL;
> + else
> + return (buf + sizeof(*pr) + pr->pr_datasz);
We can exceed the underlying buffer bounds here, which is technically
undefined behaviour.
I suspect we may be relying on similar tricks all over the kernel, but
IT MAy be best avoided anyway.
If we always pass in the buffer base pointer and the size of the buffer, say
static int next_property(void *buf, size_t *offset,
size_t bufsz, ...)
then we may be able to use direct comparisons that can't overflow
rather than relying on potentially undefined behaviour. For example:
size_t o = *offset;
if (o > bufsz || sizeof (*pr) > bufsz - o)
return -1;
pr = buf + o;
if (pr->pr_type > pr_type || pr->pr_type > *max_type)
return -1;
if (pr->pr_datasz > bufsz - o - sizeof (*pr))
return -1;
*offset = o + sizeof (*pr) + pr->pr_datasz;
return 0;
(There may be neater ways to do this.)
> +}
> +
> +/*
> + * Scan 'buf' for a pattern; return true if found.
> + * *pos is the distance from the beginning of buf to where
> + * the searched item or the next item is located.
> + */
> +static int scan(u8 *buf, u32 buf_size, int item_size, test_item_fn test_item,
> + next_item_fn next_item, u32 *arg, u32 type, u32 *pos)
> +{
> + int found = 0;
> + u8 *p, *max;
> +
> + max = buf + buf_size;
> + if (max < buf)
See comment about undefined behaviour above.
Also, I'm not sure this check adds anything. We know buf_size is
<= BUF_SIZE (though we could stick a WARN_ON() here and bail out if we
want to make absolutely sure).
If buf is always the base pointer returned by kmalloc(BUF_SIZE), then
I think buf_size can never go outside its bounds?
> + return 0;
> +
> + p = buf;
> +
> + while ((p + item_size < max) && (p + item_size > buf)) {
^ <= ? ^ undefined behaviour?
> + if (test_item(p, arg, type)) {
> + found = 1;
> + break;
> + }
> +
> + p = next_item(p, arg, type);
> + }
> +
> + *pos = (p + item_size <= buf) ? 0 : (u32)(p - buf);
Can this be written more simply, say:
if (p + item_size > buf)
*pos += p - buf;
Also, since next_property() adds pr_datasz onto buf, could we get
unlucky and wrap past (void *)~0UL? Then (u32)(p - buf) may be giant.
Not sure whether this breaks code elsewhere.
> + return found;
> +}
> +
> +/*
> + * Search an NT_GNU_PROPERTY_TYPE_0 for the property of 'pr_type'.
> + */
> +static int find_property(struct file *file, unsigned long desc_size,
> + loff_t file_offset, u8 *buf,
> + u32 pr_type, u32 *property)
> +{
> + u32 buf_pos;
> + unsigned long read_size;
> + unsigned long done;
> + int found = 0;
> + int ret = 0;
> + u32 last_pr = 0;
> +
> + *property = 0;
> + buf_pos = 0;
> +
> + for (done = 0; done < desc_size; done += buf_pos) {
> + read_size = desc_size - done;
> + if (read_size > BUF_SIZE)
> + read_size = BUF_SIZE;
> +
> + ret = kernel_read(file, buf, read_size, &file_offset);
> +
> + if (ret != read_size)
> + return (ret < 0) ? ret : -EIO;
> +
> + ret = 0;
> + found = scan(buf, read_size, sizeof(struct gnu_property),
> + test_property, next_property,
> + &last_pr, pr_type, &buf_pos);
> +
> + if ((!buf_pos) || found)
> + break;
> +
> + file_offset += buf_pos - read_size;
> + }
> +
> + if (found) {
> + struct gnu_property *pr =
> + (struct gnu_property *)(buf + buf_pos);
> +
> + if (pr->pr_datasz == 4) {
> + u32 *max = (u32 *)(buf + read_size);
> + u32 *data = (u32 *)((u8 *)pr + sizeof(*pr));
> +
> + if (data + 1 <= max) {
> + *property = *data;
> + } else {
> + file_offset += buf_pos - read_size;
> + file_offset += sizeof(*pr);
> + ret = kernel_read(file, property, 4,
> + &file_offset);
> + }
> + }
> + }
> +
> + return ret;
> +}
> +
> +/*
> + * Search a PT_NOTE segment for NT_GNU_PROPERTY_TYPE_0.
> + */
> +static int find_note_type_0(struct file *file, loff_t file_offset,
> + unsigned long note_size, u32 align,
> + u32 pr_type, u32 *property)
> +{
> + u8 *buf;
> + u32 buf_pos;
> + unsigned long read_size;
> + unsigned long done;
> + int found = 0;
> + int ret = 0;
> +
> + buf = kmalloc(BUF_SIZE, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
Do we really need to alloc/free this once per note?
> +
> + *property = 0;
> + buf_pos = 0;
> +
> + for (done = 0; done < note_size; done += buf_pos) {
> + read_size = note_size - done;
> + if (read_size > BUF_SIZE)
> + read_size = BUF_SIZE;
> +
> + ret = kernel_read(file, buf, read_size, &file_offset);
> +
> + if (ret != read_size) {
> + ret = (ret < 0) ? ret : -EIO;
> + kfree(buf);
> + return ret;
> + }
> +
> + /*
> + * item_size = sizeof(struct elf_note) + elf_note.n_namesz.
> + * n_namesz is 4 for the note type we look for.
> + */
> + ret = scan(buf, read_size, sizeof(struct elf_note) + 4,
> + test_note_type, next_note,
> + &align, NT_GNU_PROPERTY_TYPE_0, &buf_pos);
> +
> + file_offset += buf_pos - read_size;
> +
> + if (ret && !found) {
> + struct elf_note *n =
> + (struct elf_note *)(buf + buf_pos);
> + u64 start = round_up(sizeof(*n) + n->n_namesz, align);
> + u64 total = 0;
> +
> + if (check_add_overflow(start, (u64)n->n_descsz, &total)) {
> + ret = -EINVAL;
> + break;
> + }
> + total = round_up(total, align);
> +
> + ret = find_property(file, n->n_descsz,
> + file_offset + start,
> + buf, pr_type, property);
> + found++;
> + file_offset += total;
> + buf_pos += total;
> + } else if (!buf_pos || ret) {
> + ret = 0;
> + *property = 0;
> + break;
> + }
> + }
Do we really need this complexity? How big are the notes realistically
going to be?
Since a file with bloated notes is going to be inefficient to exec
anyway if we have to scan all the way through them, would it be better
just to choke on it and force the toolchain to do something more
sensible?
This in one reason why it would be good for the kernel to require
PT_GNU_PROPERTY if possible, so we know the precise offset and size
without having to search...
> +
> + kfree(buf);
> + return ret;
> +}
> +
> +/*
> + * Look at an ELF file's PT_NOTE segments, then NT_GNU_PROPERTY_TYPE_0, then
> + * the property of pr_type.
> + *
> + * Input:
> + * file: the file to search;
> + * phdr: the file's elf header;
> + * phnum: number of entries in phdr;
> + * pr_type: the property type.
> + *
> + * Output:
> + * The property found.
> + *
> + * Return:
> + * Zero or error.
> + */
> +static int scan_segments_64(struct file *file, struct elf64_phdr *phdr,
> + int phnum, u32 pr_type, u32 *property)
> +{
> + int i;
> + int err = 0;
> +
> + for (i = 0; i < phnum; i++, phdr++) {
> + if ((phdr->p_type != PT_NOTE) || (phdr->p_align != 8))
> + continue;
> +
> + /*
> + * Search the PT_NOTE segment for NT_GNU_PROPERTY_TYPE_0.
> + */
> + err = find_note_type_0(file, phdr->p_offset, phdr->p_filesz,
> + phdr->p_align, pr_type, property);
> + if (err)
> + return err;
> + }
> +
> + return 0;
> +}
> +
> +static int scan_segments_32(struct file *file, struct elf32_phdr *phdr,
> + int phnum, u32 pr_type, u32 *property)
> +{
> + int i;
> + int err = 0;
> +
> + for (i = 0; i < phnum; i++, phdr++) {
> + if ((phdr->p_type != PT_NOTE) || (phdr->p_align != 4))
> + continue;
> +
> + /*
> + * Search the PT_NOTE segment for NT_GNU_PROPERTY_TYPE_0.
> + */
> + err = find_note_type_0(file, phdr->p_offset, phdr->p_filesz,
> + phdr->p_align, pr_type, property);
> + if (err)
> + return err;
> + }
> +
> + return 0;
> +}
> +
> +int get_gnu_property(void *ehdr_p, void *phdr_p, struct file *f,
> + u32 pr_type, u32 *property)
> +{
> + struct elf64_hdr *ehdr64 = ehdr_p;
> + int err = 0;
> +
> + *property = 0;
> +
> + if (ehdr64->e_ident[EI_CLASS] == ELFCLASS64) {
> + struct elf64_phdr *phdr64 = phdr_p;
> +
> + err = scan_segments_64(f, phdr64, ehdr64->e_phnum,
> + pr_type, property);
> + if (err < 0)
> + goto out;
> + } else {
> + struct elf32_hdr *ehdr32 = ehdr_p;
> +
> + if (ehdr32->e_ident[EI_CLASS] == ELFCLASS32) {
> + struct elf32_phdr *phdr32 = phdr_p;
> +
> + err = scan_segments_32(f, phdr32, ehdr32->e_phnum,
> + pr_type, property);
> + if (err < 0)
> + goto out;
> + }
> + }
> +
> +out:
> + return err;
> +}
> diff --git a/include/linux/elf.h b/include/linux/elf.h
> index e3649b3e970e..c15febebe7f2 100644
> --- a/include/linux/elf.h
> +++ b/include/linux/elf.h
> @@ -56,4 +56,16 @@ static inline int elf_coredump_extra_notes_write(struct coredump_params *cprm) {
> extern int elf_coredump_extra_notes_size(void);
> extern int elf_coredump_extra_notes_write(struct coredump_params *cprm);
> #endif
> +
> +#ifdef CONFIG_ARCH_USE_GNU_PROPERTY
> +extern int arch_setup_property(void *ehdr, void *phdr, struct file *f,
> + bool interp);
> +extern int get_gnu_property(void *ehdr_p, void *phdr_p, struct file *f,
> + u32 pr_type, u32 *feature);
> +#else
> +static inline int arch_setup_property(void *ehdr, void *phdr, struct file *f,
> + bool interp) { return 0; }
> +static inline int get_gnu_property(void *ehdr_p, void *phdr_p, struct file *f,
> + u32 pr_type, u32 *feature) { return 0; }
> +#endif
> #endif /* _LINUX_ELF_H */
> diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
> index 34c02e4290fe..316177ce9e76 100644
> --- a/include/uapi/linux/elf.h
> +++ b/include/uapi/linux/elf.h
> @@ -372,6 +372,7 @@ typedef struct elf64_shdr {
> #define NT_PRFPREG 2
> #define NT_PRPSINFO 3
> #define NT_TASKSTRUCT 4
> +#define NT_GNU_PROPERTY_TYPE_0 5
Should this be in a separate block. This required n_name = "GNU",
whereas the rest are "LINUX" notes AFAIK: it's really a separate
namespace.
I think the gap between 4 and 6 may be just coincidence: glibc's elf.h
already has NT_PLATFORM here (whatever that is).
> #define NT_AUXV 6
> /*
> * Note to userspace developers: size of NT_SIGINFO note may increase
> @@ -443,4 +444,17 @@ typedef struct elf64_note {
> Elf64_Word n_type; /* Content type */
> } Elf64_Nhdr;
>
> +/* NT_GNU_PROPERTY_TYPE_0 header */
> +struct gnu_property {
> + __u32 pr_type;
> + __u32 pr_datasz;
> +};
> +
> +/* .note.gnu.property types */
> +#define GNU_PROPERTY_X86_FEATURE_1_AND (0xc0000002)
> +
> +/* Bits of GNU_PROPERTY_X86_FEATURE_1_AND */
> +#define GNU_PROPERTY_X86_FEATURE_1_IBT (0x00000001)
> +#define GNU_PROPERTY_X86_FEATURE_1_SHSTK (0x00000002)
> +
Redundant (). The rest of the file doesn't have them; can we conform to
the prevailing style there?
> #endif /* _UAPI_LINUX_ELF_H */
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Dave Hansen @ 2019-06-07 17:59 UTC (permalink / raw)
To: Peter Zijlstra, Yu-cheng Yu
Cc: x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel,
linux-doc, linux-mm, linux-arch, linux-api, Arnd Bergmann,
Andy Lutomirski, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <20190607174336.GM3436@hirez.programming.kicks-ass.net>
On 6/7/19 10:43 AM, Peter Zijlstra wrote:
> I've no idea what the kernel should do; since you failed to answer the
> question what happens when you point this to garbage.
>
> Does it then fault or what?
Yeah, I think you'll fault with a rather mysterious CR2 value since
you'll go look at the instruction that faulted and not see any
references to the CR2 value.
I think this new MSR probably needs to get included in oops output when
CET is enabled.
Why don't we require that a VMA be in place for the entire bitmap?
Don't we need a "get" prctl function too in case something like a JIT is
running and needs to find the location of this bitmap to set bits itself?
Or, do we just go whole-hog and have the kernel manage the bitmap
itself. Our interface here could be:
prctl(PR_MARK_CODE_AS_LEGACY, start, size);
and then have the kernel allocate and set the bitmap for those code
locations.
^ permalink raw reply
* Re: [PATCH] Documentation: {u,k}probes: add tracing_on before tracing
From: Jonathan Corbet @ 2019-06-07 17:57 UTC (permalink / raw)
To: lecopzer.chen
Cc: linux-kernel, linux-doc, mhiramat, srv_heupstream, yj.chiang
In-Reply-To: <1557397876-18153-1-git-send-email-lecopzer.chen@mediatek.com>
On Thu, 9 May 2019 18:31:16 +0800
<lecopzer.chen@mediatek.com> wrote:
> From: Lecopzer Chen <lecopzer.chen@mediatek.com>
>
> After following the document step by step, the `cat trace` can't be
> worked without enabling tracing_on and might mislead newbies about
> the functionality.
>
> Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v2 00/22] Some documentation fixes
From: Jonathan Corbet @ 2019-06-07 17:55 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, netdev, bpf
In-Reply-To: <cover.1559656538.git.mchehab+samsung@kernel.org>
On Tue, 4 Jun 2019 11:17:34 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> Fix several warnings and broken links.
>
> This series was generated against linux-next, but was rebased to be applied at
> docs-next. It should apply cleanly on either tree.
>
> There's a git tree with all of them applied on the top of docs/docs-next
> at:
>
> https://git.linuxtv.org/mchehab/experimental.git/log/?h=fix_doc_links_v2
So I'll admit I've kind of lost track of which of these are applied, which
have comments, etc. When you feel things have settled, can you get me an
updated set and I'll get them applied?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH 2/3] treewide: trivial: fix s/poped/popped/ typo
From: Jonathan Corbet @ 2019-06-07 17:50 UTC (permalink / raw)
To: George G. Davis
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Jiri Kosina,
Masami Hiramatsu, Steven Rostedt, Andi Kleen, Jann Horn,
Nadav Amit, open list:DOCUMENTATION, open list
In-Reply-To: <1559766612-12178-2-git-send-email-george_davis@mentor.com>
On Wed, 5 Jun 2019 16:30:10 -0400
"George G. Davis" <george_davis@mentor.com> wrote:
> Fix a couple of s/poped/popped/ typos.
>
> Cc: Jiri Kosina <trivial@kernel.org>
> Signed-off-by: George G. Davis <george_davis@mentor.com>
I've applied this one, thanks.
jon
^ permalink raw reply
* Re: [PATCH] Documentation: xfs: Fix typo
From: Jonathan Corbet @ 2019-06-07 17:44 UTC (permalink / raw)
To: Shiyang Ruan; +Cc: linux-doc, linux-kernel, linux-xfs
In-Reply-To: <20190509030549.2253-1-ruansy.fnst@cn.fujitsu.com>
On Thu, 9 May 2019 11:05:49 +0800
Shiyang Ruan <ruansy.fnst@cn.fujitsu.com> wrote:
> In "Y+P" of this line, there are two non-ASCII characters(0xd9 0x8d)
> following behind the 'Y'. Shown as a small '=' under the '+' in VIM
> and a '賺' in webpage[1].
>
> I think it's a mistake and remove these strange characters.
>
> [1]: https://www.kernel.org/doc/Documentation/filesystems/xfs-delayed-logging-design.txt
>
> Signed-off-by: Shiyang Ruan <ruansy.fnst@cn.fujitsu.com>
> ---
> Documentation/filesystems/xfs-delayed-logging-design.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/filesystems/xfs-delayed-logging-design.txt b/Documentation/filesystems/xfs-delayed-logging-design.txt
> index 2ce36439c09f..9a6dd289b17b 100644
> --- a/Documentation/filesystems/xfs-delayed-logging-design.txt
> +++ b/Documentation/filesystems/xfs-delayed-logging-design.txt
> @@ -34,7 +34,7 @@ transaction:
> D A+B+C+D X+n+m+o
> <object written to disk>
> E E Y (> X+n+m+o)
> - F E+F Yٍ+p
> + F E+F Y+p
OK, that does look funky, applied.
This patch probably should have been copied to the XFS list (added), even
though get_maintainer.pl doesn't know that.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Peter Zijlstra @ 2019-06-07 17:43 UTC (permalink / raw)
To: Yu-cheng Yu
Cc: x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel,
linux-doc, linux-mm, linux-arch, linux-api, Arnd Bergmann,
Andy Lutomirski, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <aa8a92ef231d512b5c9855ef416db050b5ab59a6.camel@intel.com>
On Fri, Jun 07, 2019 at 09:23:43AM -0700, Yu-cheng Yu wrote:
> On Fri, 2019-06-07 at 10:08 +0200, Peter Zijlstra wrote:
> > On Thu, Jun 06, 2019 at 01:09:15PM -0700, Yu-cheng Yu wrote:
> > > Indirect Branch Tracking (IBT) provides an optional legacy code bitmap
> > > that allows execution of legacy, non-IBT compatible library by an
> > > IBT-enabled application. When set, each bit in the bitmap indicates
> > > one page of legacy code.
> > >
> > > The bitmap is allocated and setup from the application.
> > > +int cet_setup_ibt_bitmap(unsigned long bitmap, unsigned long size)
> > > +{
> > > + u64 r;
> > > +
> > > + if (!current->thread.cet.ibt_enabled)
> > > + return -EINVAL;
> > > +
> > > + if (!PAGE_ALIGNED(bitmap) || (size > TASK_SIZE_MAX))
> > > + return -EINVAL;
> > > +
> > > + current->thread.cet.ibt_bitmap_addr = bitmap;
> > > + current->thread.cet.ibt_bitmap_size = size;
> > > +
> > > + /*
> > > + * Turn on IBT legacy bitmap.
> > > + */
> > > + modify_fpu_regs_begin();
> > > + rdmsrl(MSR_IA32_U_CET, r);
> > > + r |= (MSR_IA32_CET_LEG_IW_EN | bitmap);
> > > + wrmsrl(MSR_IA32_U_CET, r);
> > > + modify_fpu_regs_end();
> > > +
> > > + return 0;
> > > +}
> >
> > So you just program a random user supplied address into the hardware.
> > What happens if there's not actually anything at that address or the
> > user munmap()s the data after doing this?
>
> This function checks the bitmap's alignment and size, and anything else is the
> app's responsibility. What else do you think the kernel should check?
I've no idea what the kernel should do; since you failed to answer the
question what happens when you point this to garbage.
Does it then fault or what?
^ permalink raw reply
* Re: [PATCH] linux: README: reduced README size by 1 byte by removing unnecessary space character
From: Markus Heiser @ 2019-06-07 17:43 UTC (permalink / raw)
To: Alex, paulmck; +Cc: linux-doc, linux-kernel, trivial, Aaron A Montoya
In-Reply-To: <20190607055917.17040-1-awaitingvictory@gmail.com>
Am 07.06.19 um 07:59 schrieb Alex:
> From: Aaron A Montoya <aaron.a.montoya@gmail.com>
>
> On line 9 of the README there is an unnecessary extra space character,
> after the period, that adds 1 byte of size to the file. By removing the
> unnecessary space, Linux downloads will be 1 byte smaller and therefor be
> faster to download and take up less space on a user's system, all while
> correcting a sentence structure issue. This change is one of the few
> optimizations with practically no downsides, besides taking time out
> of the hardworking Linux maintainers day to implement the change.
> Remove extra space after the period on line 9 of the README.
> Commit 0619770a02a30834 ("Removed unnecessary space character from README")
>
best joke today but wrong in two ways ;)
1. size matter? The commit (-message) adds to more bytes to the repo ;)
2. Be correct formated? The extra Space is for 'sentence spacing' [1]
e.g. emacs text modes are formating such spacing.
[1] https://en.wikipedia.org/wiki/Sentence_spacing
-- Markus --
^ permalink raw reply
* Re: [PATCH v2] Documentation: nvdimm: Fix typo
From: Jonathan Corbet @ 2019-06-07 17:39 UTC (permalink / raw)
To: Shiyang Ruan; +Cc: linux-doc, linux-kernel, linux-nvdimm
In-Reply-To: <20190509074049.12192-1-ruansy.fnst@cn.fujitsu.com>
On Thu, 9 May 2019 15:40:49 +0800
Shiyang Ruan <ruansy.fnst@cn.fujitsu.com> wrote:
> Remove the extra 'we '.
>
> Signed-off-by: Shiyang Ruan <ruansy.fnst@cn.fujitsu.com>
> ---
> Documentation/nvdimm/nvdimm.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/nvdimm/nvdimm.txt b/Documentation/nvdimm/nvdimm.txt
> index e894de69915a..1669f626b037 100644
> --- a/Documentation/nvdimm/nvdimm.txt
> +++ b/Documentation/nvdimm/nvdimm.txt
> @@ -284,8 +284,8 @@ A bus has a 1:1 relationship with an NFIT. The current expectation for
> ACPI based systems is that there is only ever one platform-global NFIT.
> That said, it is trivial to register multiple NFITs, the specification
> does not preclude it. The infrastructure supports multiple busses and
> -we we use this capability to test multiple NFIT configurations in the
> -unit test.
> +we use this capability to test multiple NFIT configurations in the unit
> +test.
Applied, thanks.
I note this has languished for a bit; please don't hesitate to ping after
a week or so if you don't get a response on a patch posting.
jon
^ permalink raw reply
* Re: [PATCH] doc:it_IT: documentation alignment
From: Jonathan Corbet @ 2019-06-07 17:37 UTC (permalink / raw)
To: Federico Vaga; +Cc: linux-doc, linux-kernel, Mauro Carvalho Chehab
In-Reply-To: <20190530201455.12412-2-federico.vaga@vaga.pv.it>
On Thu, 30 May 2019 22:14:55 +0200
Federico Vaga <federico.vaga@vaga.pv.it> wrote:
> Documentation alignment for the following changes:
> a700767a7682 (doc/docs-next) docs: requirements.txt: recommend Sphinx 1.7.9
>
> Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] doc:it_IT: fix file references
From: Jonathan Corbet @ 2019-06-07 17:36 UTC (permalink / raw)
To: Federico Vaga; +Cc: linux-doc, linux-kernel, Mauro Carvalho Chehab
In-Reply-To: <20190530201455.12412-1-federico.vaga@vaga.pv.it>
On Thu, 30 May 2019 22:14:54 +0200
Federico Vaga <federico.vaga@vaga.pv.it> wrote:
> Fix italian translation file references based on
> `scripts/documentation-file-ref-check` output.
>
> Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] docs: clk: fix struct syntax
From: Jonathan Corbet @ 2019-06-07 17:35 UTC (permalink / raw)
To: Luca Ceresoli; +Cc: linux-doc, linux-kernel
In-Reply-To: <20190531143016.23185-1-luca@lucaceresoli.net>
On Fri, 31 May 2019 16:30:16 +0200
Luca Ceresoli <luca@lucaceresoli.net> wrote:
> The clk_foo_ops struct example has syntax errors. Fix it so it can be
> copy-pasted and used more easily.
>
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] docs: Kbuild/Makefile: allow check for missing docs at build time
From: Jonathan Corbet @ 2019-06-07 17:34 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Masahiro Yamada, Randy Dunlap
In-Reply-To: <8ac254a7cf0569f1eeced9c9263cd7b0bfe4ed78.1559651025.git.mchehab+samsung@kernel.org>
On Tue, 4 Jun 2019 09:26:27 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> While this doesn't make sense for production Kernels, in order to
> avoid regressions when documents are touched, let's add a
> check target at the make file.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH trivial] KVM: arm/arm64: Always capitalize ITS
From: Jonathan Corbet @ 2019-06-07 17:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Paolo Bonzini, Radim Krčmář, Jiri Kosina, kvm,
linux-doc, linux-kernel
In-Reply-To: <20190607112951.14418-1-geert+renesas@glider.be>
On Fri, 7 Jun 2019 13:29:51 +0200
Geert Uytterhoeven <geert+renesas@glider.be> wrote:
> All but one reference is capitalized. Fix the remaining one.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Documentation/virtual/kvm/devices/arm-vgic-its.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/virtual/kvm/devices/arm-vgic-its.txt b/Documentation/virtual/kvm/devices/arm-vgic-its.txt
> index 4f0c9fc403656d29..eeaa95b893a89b7a 100644
> --- a/Documentation/virtual/kvm/devices/arm-vgic-its.txt
> +++ b/Documentation/virtual/kvm/devices/arm-vgic-its.txt
> @@ -103,7 +103,7 @@ Groups:
> The following ordering must be followed when restoring the GIC and the ITS:
> a) restore all guest memory and create vcpus
> b) restore all redistributors
> -c) provide the its base address
> +c) provide the ITS base address
> (KVM_DEV_ARM_VGIC_GRP_ADDR)
> d) restore the ITS in the following order:
> 1. Restore GITS_CBASER
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH trivial] Documentation: net: dsa: Grammar s/the its/its/
From: Jonathan Corbet @ 2019-06-07 17:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: David S . Miller, Jiri Kosina, netdev, linux-doc, linux-kernel
In-Reply-To: <20190607110842.12876-1-geert+renesas@glider.be>
On Fri, 7 Jun 2019 13:08:42 +0200
Geert Uytterhoeven <geert+renesas@glider.be> wrote:
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Documentation/networking/dsa/dsa.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst
> index ca87068b9ab904a9..563d56c6a25c924e 100644
> --- a/Documentation/networking/dsa/dsa.rst
> +++ b/Documentation/networking/dsa/dsa.rst
> @@ -531,7 +531,7 @@ Bridge VLAN filtering
> a software implementation.
>
> .. note:: VLAN ID 0 corresponds to the port private database, which, in the context
> - of DSA, would be the its port-based VLAN, used by the associated bridge device.
> + of DSA, would be its port-based VLAN, used by the associated bridge device.
>
> - ``port_fdb_del``: bridge layer function invoked when the bridge wants to remove a
> Forwarding Database entry, the switch hardware should be programmed to delete
> @@ -554,7 +554,7 @@ Bridge VLAN filtering
> associated with this VLAN ID.
>
> .. note:: VLAN ID 0 corresponds to the port private database, which, in the context
> - of DSA, would be the its port-based VLAN, used by the associated bridge device.
> + of DSA, would be its port-based VLAN, used by the associated bridge device.
Applied, thanks.
jon
^ 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