* [PATCH v12 02/13] doc: Add doc for the Ingenic TCU hardware
From: Paul Cercueil @ 2019-05-21 14:51 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Ralf Baechle, Paul Burton, James Hogan,
Jonathan Corbet, Daniel Lezcano, Thomas Gleixner,
Michael Turquette, Stephen Boyd, Jason Cooper, Marc Zyngier,
Lee Jones
Cc: Mathieu Malaterre, linux-kernel, devicetree, linux-mips,
linux-doc, linux-clk, od, Paul Cercueil
In-Reply-To: <20190521145141.9813-1-paul@crapouillou.net>
Add a documentation file about the Timer/Counter Unit (TCU) present in
the Ingenic JZ47xx SoCs.
The Timer/Counter Unit (TCU) in Ingenic JZ47xx SoCs is a multi-function
hardware block. It features up to to eight channels, that can be used as
counters, timers, or PWM.
- JZ4725B, JZ4750, JZ4755 only have six TCU channels. The other SoCs all
have eight channels.
- JZ4725B introduced a separate channel, called Operating System Timer
(OST). It is a 32-bit programmable timer. On JZ4770 and above, it is
64-bit.
- Each one of the TCU channels has its own clock, which can be reparented
to three different clocks (pclk, ext, rtc), gated, and reclocked, through
their TCSR register.
* The watchdog and OST hardware blocks also feature a TCSR register with
the same format in their register space.
* The TCU registers used to gate/ungate can also gate/ungate the watchdog
and OST clocks.
- Each TCU channel works in one of two modes:
* mode TCU1: channels cannot work in sleep mode, but are easier to
operate.
* mode TCU2: channels can work in sleep mode, but the operation is a bit
more complicated than with TCU1 channels.
- The mode of each TCU channel depends on the SoC used:
* On the oldest SoCs (up to JZ4740), all of the eight channels operate in
TCU1 mode.
* On JZ4725B, channel 5 operates as TCU2, the others operate as TCU1.
* On newest SoCs (JZ4750 and above), channels 1-2 operate as TCU2, the
others operate as TCU1.
- Each channel can generate an interrupt. Some channels share an interrupt
line, some don't, and this changes between SoC versions:
* on older SoCs (JZ4740 and below), channel 0 and channel 1 have their
own interrupt line; channels 2-7 share the last interrupt line.
* On JZ4725B, channel 0 has its own interrupt; channels 1-5 share one
interrupt line; the OST uses the last interrupt line.
* on newer SoCs (JZ4750 and above), channel 5 has its own interrupt;
channels 0-4 and (if eight channels) 6-7 all share one interrupt line;
the OST uses the last interrupt line.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
---
Notes:
v4: New patch in this series
v5: Added information about number of channels, and improved
documentation about channel modes
v6: Add info about OST (can be 32-bit on older SoCs)
v7-v11: No change
v12: Add details about new implementation
Documentation/mips/ingenic-tcu.txt | 63 ++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
create mode 100644 Documentation/mips/ingenic-tcu.txt
diff --git a/Documentation/mips/ingenic-tcu.txt b/Documentation/mips/ingenic-tcu.txt
new file mode 100644
index 000000000000..1a753805779c
--- /dev/null
+++ b/Documentation/mips/ingenic-tcu.txt
@@ -0,0 +1,63 @@
+Ingenic JZ47xx SoCs Timer/Counter Unit hardware
+-----------------------------------------------
+
+The Timer/Counter Unit (TCU) in Ingenic JZ47xx SoCs is a multi-function
+hardware block. It features up to to eight channels, that can be used as
+counters, timers, or PWM.
+
+- JZ4725B, JZ4750, JZ4755 only have six TCU channels. The other SoCs all
+ have eight channels.
+
+- JZ4725B introduced a separate channel, called Operating System Timer
+ (OST). It is a 32-bit programmable timer. On JZ4760B and above, it is
+ 64-bit.
+
+- Each one of the TCU channels has its own clock, which can be reparented
+ to three different clocks (pclk, ext, rtc), gated, and reclocked, through
+ their TCSR register.
+ * The watchdog and OST hardware blocks also feature a TCSR register with
+ the same format in their register space.
+ * The TCU registers used to gate/ungate can also gate/ungate the watchdog
+ and OST clocks.
+
+- Each TCU channel works in one of two modes:
+ * mode TCU1: channels cannot work in sleep mode, but are easier to
+ operate.
+ * mode TCU2: channels can work in sleep mode, but the operation is a bit
+ more complicated than with TCU1 channels.
+
+- The mode of each TCU channel depends on the SoC used:
+ * On the oldest SoCs (up to JZ4740), all of the eight channels operate in
+ TCU1 mode.
+ * On JZ4725B, channel 5 operates as TCU2, the others operate as TCU1.
+ * On newest SoCs (JZ4750 and above), channels 1-2 operate as TCU2, the
+ others operate as TCU1.
+
+- Each channel can generate an interrupt. Some channels share an interrupt
+ line, some don't, and this changes between SoC versions:
+ * on older SoCs (JZ4740 and below), channel 0 and channel 1 have their
+ own interrupt line; channels 2-7 share the last interrupt line.
+ * On JZ4725B, channel 0 has its own interrupt; channels 1-5 share one
+ interrupt line; the OST uses the last interrupt line.
+ * on newer SoCs (JZ4750 and above), channel 5 has its own interrupt;
+ channels 0-4 and (if eight channels) 6-7 all share one interrupt line;
+ the OST uses the last interrupt line.
+
+Implementation
+--------------
+
+The functionalities of the TCU hardware are spread across multiple drivers:
+- boilerplate: drivers/mfd/ingenic-tcu.c
+- clocks: drivers/clk/ingenic/tcu.c
+- interrupts: drivers/irqchip/irq-ingenic-tcu.c
+- timers: drivers/clocksource/ingenic-timer.c
+- PWM: drivers/pwm/pwm-jz4740.c
+- watchdog: drivers/watchdog/jz4740_wdt.c
+- OST: drivers/clocksource/ingenic-ost.c
+
+Because various functionalities of the TCU that belong to different drivers
+and frameworks can be controlled from the same registers, all of these
+drivers access their registers through the same regmap.
+
+For more information regarding the devicetree bindings of the TCU drivers,
+have a look at Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
--
2.21.0.593.g511ec345e18
^ permalink raw reply related
* Ingenic Timer/Counter Unit (TCU) patchset v12
From: Paul Cercueil @ 2019-05-21 14:51 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Ralf Baechle, Paul Burton, James Hogan,
Jonathan Corbet, Daniel Lezcano, Thomas Gleixner,
Michael Turquette, Stephen Boyd, Jason Cooper, Marc Zyngier,
Lee Jones
Cc: Mathieu Malaterre, linux-kernel, devicetree, linux-mips,
linux-doc, linux-clk, od
Hi,
Here's the V12 of my patchset to add support for the Timer/Counter Unit
(TCU) present on the JZ47xx SoCs from Ingenic.
This patchset is much shorter at only 13 patches vs. 27 patches in V11;
the remaining patches will be sent in parallel (if applicable) or as a
follow-up patchset once this one is merged.
In V11 the clocksource maintainers weren't happy with the size of the
ingenic-timer driver, which included clocks and irqchip setup code.
On the other hand, devicetree maintainers wanted one single node for
the TCU hardware since it's effectively just one hardware block.
In this patchset the functionality is cut in four different drivers:
a MFD one to provide the regmap, probe the children and which provides
several API functions; a clocks driver; a irqchip driver; a clocksource
driver. All these drivers work with the same regmap, have the same
compatible strings, and will probe _with the same devicetree node_.
Regards,
-Paul
^ permalink raw reply
* Re: [PATCH 0/2] Enable new kprobe event at boot
From: Steven Rostedt @ 2019-05-21 13:33 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Ingo Molnar, Naveen N . Rao, Anil S Keshavamurthy,
David S . Miller, linux-kernel, linux-doc
In-Reply-To: <155842537599.4253.14690293652007233645.stgit@devnote2>
On Tue, 21 May 2019 16:56:16 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:
> Note that 'trace_event=' option enables trace event at very early
> timing, but the events added by 'kprobe_event=' are enabled right
> before enabling device drivers at this point. It is enough for
> tracing device driver initialization etc.
Nice!
I wonder if we can have this called before the trace_event boot is
analyzed. Then have the kprobe_event work more like the kprobe_events
file, and not enable the kprobes but only create them. If you want to
enable them you do a trace_event=kprobes as well.
Perhaps we could enable kprobes at early init?
What do you think? Or is there something else in kprobes that prevents
such an early enabling of it?
-- Steve
^ permalink raw reply
* Re: [PATCH v7 1/1] iommu: enhance IOMMU dma mode build options
From: John Garry @ 2019-05-21 12:59 UTC (permalink / raw)
To: Zhen Lei, 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: <20190520135947.14960-2-thunder.leizhen@huawei.com>
On 20/05/2019 14:59, Zhen Lei wrote:
> 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.
>
> The default IOMMU dma modes on each ARCHs have no change.
>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Apart from more minor comments, FWIW:
Reviewed-by: John Garry <john.garry@huawei.com>
> ---
> arch/ia64/kernel/pci-dma.c | 2 +-
> arch/powerpc/platforms/powernv/pci-ioda.c | 3 ++-
> arch/s390/pci/pci_dma.c | 2 +-
> arch/x86/kernel/pci-dma.c | 7 ++---
> drivers/iommu/Kconfig | 44 ++++++++++++++++++++++++++-----
> drivers/iommu/amd_iommu_init.c | 3 ++-
> drivers/iommu/intel-iommu.c | 2 +-
> drivers/iommu/iommu.c | 3 ++-
> 8 files changed, 48 insertions(+), 18 deletions(-)
>
> diff --git a/arch/ia64/kernel/pci-dma.c b/arch/ia64/kernel/pci-dma.c
> index fe988c49f01ce6a..655511dbf3c3b34 100644
> --- a/arch/ia64/kernel/pci-dma.c
> +++ b/arch/ia64/kernel/pci-dma.c
> @@ -22,7 +22,7 @@
> int force_iommu __read_mostly;
> #endif
>
> -int iommu_pass_through;
> +int iommu_pass_through = IS_ENABLED(CONFIG_IOMMU_DEFAULT_PASSTHROUGH);
As commented privately, I could never see this set for ia64, and it
seems to exist just to keep the linker happy. Anyway, I am not sure if
ever suitable to be set.
>
> static int __init pci_iommu_init(void)
> {
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 3ead4c237ed0ec9..383e082a9bb985c 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -85,7 +85,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/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/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> index d460998ae828514..fb2bab42a0a3173 100644
> --- a/arch/x86/kernel/pci-dma.c
> +++ b/arch/x86/kernel/pci-dma.c
> @@ -43,11 +43,8 @@
> * 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[];
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 6f07f3b21816c64..8a1f1793cde76b4 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -74,17 +74,47 @@ 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_PASSTHROUGH if (PPC_POWERNV && PCI)
> + default IOMMU_DEFAULT_LAZY if (AMD_IOMMU || INTEL_IOMMU || S390_IOMMU)
> + default IOMMU_DEFAULT_STRICT
> + help
> + This option allows IOMMU DMA mode to be chose at build time, to
I'd say /s/allows IOMMU/allows an IOMMU/, /s/chose/chosen/
> + override the default DMA mode of each ARCHs, removing the need to
ARCHs should be singular
> + 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.
> +
> +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
> depends on OF && IOMMU_API
> diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
> index ff40ba758cf365e..16c02b08adb4cb2 100644
> --- a/drivers/iommu/amd_iommu_init.c
> +++ b/drivers/iommu/amd_iommu_init.c
> @@ -166,7 +166,8 @@ 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 */
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 28cb713d728ceef..0c3cc716210f35a 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -362,7 +362,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;
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 109de67d5d727c2..0ec5952ac60e2a3 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -43,7 +43,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
* Re: [PATCH v2] doc: kernel-parameters.txt: fix documentation of nmi_watchdog parameter
From: Steven Rostedt @ 2019-05-21 12:56 UTC (permalink / raw)
To: Zhenzhong Duan
Cc: linux-kernel, linux-doc, paulmck, josh, mathieu.desnoyers,
jiangshanlai, joel, corbet, tglx, mingo, gregkh, keescook,
srinivas.eeda
In-Reply-To: <064f1230-be51-37ef-9283-69a7277fdd67@oracle.com>
On Tue, 21 May 2019 17:42:28 +0800
Zhenzhong Duan <zhenzhong.duan@oracle.com> wrote:
> On 2019/5/15 3:21, Steven Rostedt wrote:
> > On Sun, 12 May 2019 11:35:27 +0800
> > Zhenzhong Duan <zhenzhong.duan@oracle.com> wrote:
> >
> >> The default behavior of hardlockup depends on the config of
> >> CONFIG_BOOTPARAM_HARDLOCKUP_PANIC.
> >>
> >> Fix the description of nmi_watchdog to make it clear.
> >>
> >> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
> >> Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> >> Cc: Steven Rostedt <rostedt@goodmis.org>
> > Perhaps it should have been:
> >
> > Suggested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> >
> > As the wording is what I suggested ;-)
>
> Sure, I should have done that. Just not familiar with which one is better.
>
> Not clear if I should send a v3 adding Suggested-by and Acked-by?
Yep, it's fine to add both:
Suggested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-- Steve
>
> Zhenzhong
^ permalink raw reply
* Re: [PATCH] [linux-next] docs: tracing: Fix typos in histogram.rst
From: Steven Rostedt @ 2019-05-21 12:55 UTC (permalink / raw)
To: Masanari Iida; +Cc: corbet, linux-doc, linux-kernel, mingo, rdunlap
In-Reply-To: <20190521123000.24544-1-standby24x7@gmail.com>
On Tue, 21 May 2019 21:30:00 +0900
Masanari Iida <standby24x7@gmail.com> wrote:
> This patch fixes some spelling typos in histogram.rst
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Jon,
Care to take this in your tree?
-- Steve
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
> ---
^ permalink raw reply
* [PATCH] [linux-next] docs: tracing: Fix typos in histogram.rst
From: Masanari Iida @ 2019-05-21 12:30 UTC (permalink / raw)
To: corbet, linux-doc, linux-kernel, rostedt, mingo, rdunlap; +Cc: Masanari Iida
This patch fixes some spelling typos in histogram.rst
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
---
Documentation/trace/histogram.rst | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/trace/histogram.rst b/Documentation/trace/histogram.rst
index fb621a1c2638..8408670d0328 100644
--- a/Documentation/trace/histogram.rst
+++ b/Documentation/trace/histogram.rst
@@ -1010,7 +1010,7 @@ Extended error information
For example, suppose we wanted to take a look at the relative
weights in terms of skb length for each callpath that leads to a
- netif_receieve_skb event when downloading a decent-sized file using
+ netif_receive_skb event when downloading a decent-sized file using
wget.
First we set up an initially paused stacktrace trigger on the
@@ -1843,7 +1843,7 @@ practice, not every handler.action combination is currently supported;
if a given handler.action combination isn't supported, the hist
trigger will fail with -EINVAL;
-The default 'handler.action' if none is explicity specified is as it
+The default 'handler.action' if none is explicitly specified is as it
always has been, to simply update the set of values associated with an
entry. Some applications, however, may want to perform additional
actions at that point, such as generate another event, or compare and
@@ -2088,7 +2088,7 @@ The following commonly-used handler.action pairs are available:
and the saved values corresponding to the max are displayed
following the rest of the fields.
- If a snaphot was taken, there is also a message indicating that,
+ If a snapshot was taken, there is also a message indicating that,
along with the value and event that triggered the global maximum:
# cat /sys/kernel/debug/tracing/events/sched/sched_switch/hist
@@ -2176,7 +2176,7 @@ The following commonly-used handler.action pairs are available:
hist trigger entry.
Note that in this case the changed value is a global variable
- associated withe current trace instance. The key of the specific
+ associated with current trace instance. The key of the specific
trace event that caused the value to change and the global value
itself are displayed, along with a message stating that a snapshot
has been taken and where to find it. The user can use the key
@@ -2203,7 +2203,7 @@ The following commonly-used handler.action pairs are available:
and the saved values corresponding to that value are displayed
following the rest of the fields.
- If a snaphot was taken, there is also a message indicating that,
+ If a snapshot was taken, there is also a message indicating that,
along with the value and event that triggered the snapshot::
# cat /sys/kernel/debug/tracing/events/tcp/tcp_probe/hist
--
2.22.0.rc1
^ permalink raw reply related
* Re: [PATCH 3/4] ima: don't ignore INTEGRITY_UNKNOWN EVM status
From: Mimi Zohar @ 2019-05-21 11:48 UTC (permalink / raw)
To: Roberto Sassu, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-doc, linux-security-module, linux-kernel,
silviu.vlasceanu, stable
In-Reply-To: <e81b761c-9133-a432-4d06-3cfe57e29e4b@huawei.com>
On Tue, 2019-05-21 at 09:26 +0200, Roberto Sassu wrote:
> On 5/20/2019 11:20 PM, Mimi Zohar wrote:
> > On Thu, 2019-05-16 at 18:12 +0200, Roberto Sassu wrote:
> >> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> >> index 52e6fbb042cc..80e1c233656b 100644
> >> --- a/Documentation/admin-guide/kernel-parameters.txt
> >> +++ b/Documentation/admin-guide/kernel-parameters.txt
> >> @@ -1588,6 +1588,9 @@
> >> Format: { "off" | "enforce" | "fix" | "log" }
> >> default: "enforce"
> >>
> >> + ima_appraise_req_evm
> >> + [IMA] require EVM for appraisal with file digests.
> >
> > As much as possible we want to limit the number of new boot command
> > line options as possible. Is there a reason for not extending
> > "ima_appraise=" with "require-evm" or "enforce-evm"?
>
> ima-appraise= can be disabled with CONFIG_IMA_APPRAISE_BOOTPARAM, which
> probably is done when the system is in production.
>
> Should I allow to use ima-appraise=require-evm even if
> CONFIG_IMA_APPRAISE_BOOTPARAM=n?
Yes, that should be fine. It's making "ima_appraise" stricter.
Mimi
^ permalink raw reply
* Re: [PATCH] docs: reorder memory-hotplug documentation
From: David Hildenbrand @ 2019-05-21 10:41 UTC (permalink / raw)
To: Mike Rapoport, Jonathan Corbet; +Cc: linux-doc, linux-mm, linux-kernel
In-Reply-To: <1557822213-19058-1-git-send-email-rppt@linux.ibm.com>
On 14.05.19 10:23, Mike Rapoport wrote:
> The "Locking Internals" section of the memory-hotplug documentation is
> duplicated in admin-guide and core-api. Drop the admin-guide copy as
> locking internals does not belong there.
>
> While on it, move the "Future Work" section to the core-api part.
Looks sane, but the future work part is really outdated, can we remove
this completely?
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
> Documentation/admin-guide/mm/memory-hotplug.rst | 51 -------------------------
> Documentation/core-api/memory-hotplug.rst | 11 ++++++
> 2 files changed, 11 insertions(+), 51 deletions(-)
>
> diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst
> index 5c4432c..72090ba 100644
> --- a/Documentation/admin-guide/mm/memory-hotplug.rst
> +++ b/Documentation/admin-guide/mm/memory-hotplug.rst
> @@ -391,54 +391,3 @@ Physical memory remove
> Need more implementation yet....
> - Notification completion of remove works by OS to firmware.
> - Guard from remove if not yet.
> -
> -
> -Locking Internals
> -=================
> -
> -When adding/removing memory that uses memory block devices (i.e. ordinary RAM),
> -the device_hotplug_lock should be held to:
> -
> -- synchronize against online/offline requests (e.g. via sysfs). This way, memory
> - block devices can only be accessed (.online/.state attributes) by user
> - space once memory has been fully added. And when removing memory, we
> - know nobody is in critical sections.
> -- synchronize against CPU hotplug and similar (e.g. relevant for ACPI and PPC)
> -
> -Especially, there is a possible lock inversion that is avoided using
> -device_hotplug_lock when adding memory and user space tries to online that
> -memory faster than expected:
> -
> -- device_online() will first take the device_lock(), followed by
> - mem_hotplug_lock
> -- add_memory_resource() will first take the mem_hotplug_lock, followed by
> - the device_lock() (while creating the devices, during bus_add_device()).
> -
> -As the device is visible to user space before taking the device_lock(), this
> -can result in a lock inversion.
> -
> -onlining/offlining of memory should be done via device_online()/
> -device_offline() - to make sure it is properly synchronized to actions
> -via sysfs. Holding device_hotplug_lock is advised (to e.g. protect online_type)
> -
> -When adding/removing/onlining/offlining memory or adding/removing
> -heterogeneous/device memory, we should always hold the mem_hotplug_lock in
> -write mode to serialise memory hotplug (e.g. access to global/zone
> -variables).
> -
> -In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
> -mode allows for a quite efficient get_online_mems/put_online_mems
> -implementation, so code accessing memory can protect from that memory
> -vanishing.
> -
> -
> -Future Work
> -===========
> -
> - - allowing memory hot-add to ZONE_MOVABLE. maybe we need some switch like
> - sysctl or new control file.
> - - showing memory block and physical device relationship.
> - - test and make it better memory offlining.
> - - support HugeTLB page migration and offlining.
> - - memmap removing at memory offline.
> - - physical remove memory.
> diff --git a/Documentation/core-api/memory-hotplug.rst b/Documentation/core-api/memory-hotplug.rst
> index de7467e..e08be1c 100644
> --- a/Documentation/core-api/memory-hotplug.rst
> +++ b/Documentation/core-api/memory-hotplug.rst
> @@ -123,3 +123,14 @@ In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
> mode allows for a quite efficient get_online_mems/put_online_mems
> implementation, so code accessing memory can protect from that memory
> vanishing.
> +
> +Future Work
> +===========
> +
> + - allowing memory hot-add to ZONE_MOVABLE. maybe we need some switch like
> + sysctl or new control file.
... that already works if I am not completely missing the point here
> + - showing memory block and physical device relationship.
... that is available for s390x only AFAIK
> + - test and make it better memory offlining.
... no big news ;)
> + - support HugeTLB page migration and offlining.
... I remember that Oscar was doing something in that area, Oscar?
> + - memmap removing at memory offline.
... no, we don't want this. However, we should properly clean up zone
information when offlining
> + - physical remove memory.
... I don't even understand what that means.
I'd vote for removing the future work part, this is pretty outdated.
--
Thanks,
David / dhildenb
^ permalink raw reply
* Великденски бонуси
From: Radoslav Dobrev @ 2019-05-21 9:55 UTC (permalink / raw)
To: linux-doc
Уважаеми Господине/Госпожо,
Съвременната социална придобивка ваучери за храна, които могат да бъдат използвани в широка търговска мрежа от супермаркети и заведения за хранене в страната, е инструмент, който ефективно повишава ефикасността на персонала.
Това се потвърждава и от проучването на Световната здравна организация (СЗО), което показва, че служител, който получава доплащане за храна, е по-ефективен с 20%, а отсъствията му намаляват с 27%.
Изборът на нашите ваучери за храна като форма на социална придобивка е равнозначно не само на продуктивен и мотивиран екип за работодателя, но и финансово облекчение - стойността на изразходваните средства не се облага с данък.
Желаете ли да Ви предоставя повече информация относно ваучерите за храна за служители?
Радослав Добрев
Head of HR Benefit Team
www.myocard.eu
^ permalink raw reply
* Re: [PATCH v2] doc: kernel-parameters.txt: fix documentation of nmi_watchdog parameter
From: Zhenzhong Duan @ 2019-05-21 9:42 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-doc, paulmck, josh, mathieu.desnoyers,
jiangshanlai, joel, corbet, tglx, mingo, gregkh, keescook,
srinivas.eeda
In-Reply-To: <20190514152113.336e6116@oasis.local.home>
On 2019/5/15 3:21, Steven Rostedt wrote:
> On Sun, 12 May 2019 11:35:27 +0800
> Zhenzhong Duan <zhenzhong.duan@oracle.com> wrote:
>
>> The default behavior of hardlockup depends on the config of
>> CONFIG_BOOTPARAM_HARDLOCKUP_PANIC.
>>
>> Fix the description of nmi_watchdog to make it clear.
>>
>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
>> Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
>> Cc: Steven Rostedt <rostedt@goodmis.org>
> Perhaps it should have been:
>
> Suggested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
>
> As the wording is what I suggested ;-)
Sure, I should have done that. Just not familiar with which one is better.
Not clear if I should send a v3 adding Suggested-by and Acked-by?
Zhenzhong
>
> -- Steve
>
>> ---
>> v2: fix description using words suggested by Steven Rostedt
>>
>> Documentation/admin-guide/kernel-parameters.txt | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 08df588..b9d4358 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -2805,8 +2805,9 @@
>> 0 - turn hardlockup detector in nmi_watchdog off
>> 1 - turn hardlockup detector in nmi_watchdog on
>> When panic is specified, panic when an NMI watchdog
>> - timeout occurs (or 'nopanic' to override the opposite
>> - default). To disable both hard and soft lockup detectors,
>> + timeout occurs (or 'nopanic' to not panic on an NMI
>> + watchdog, if CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is set)
>> + To disable both hard and soft lockup detectors,
>> please see 'nowatchdog'.
>> This is useful when you use a panic=... timeout and
>> need the box quickly up again.
^ permalink raw reply
* [PATCH 2/2] tracing/kprobe: Add kprobe_event= boot parameter
From: Masami Hiramatsu @ 2019-05-21 7:56 UTC (permalink / raw)
To: Steven Rostedt
Cc: Ingo Molnar, Naveen N . Rao, Anil S Keshavamurthy,
David S . Miller, Masami Hiramatsu, linux-kernel, linux-doc
In-Reply-To: <155842537599.4253.14690293652007233645.stgit@devnote2>
Add kprobe_event= boot parameter to define kprobe events
at boot time.
The definition syntax is similar to tracefs/kprobe_events
interface, but use ',' and ';' instead of ' ' and '\n'
respectively. e.g.
kprobe_event=p,vfs_read,$arg1,$arg2
This puts a probe on vfs_read with argument1 and 2, and
enable the new event.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
---
Documentation/admin-guide/kernel-parameters.txt | 13 ++++++
Documentation/trace/kprobetrace.rst | 14 ++++++
kernel/trace/trace_kprobe.c | 54 +++++++++++++++++++++++
3 files changed, 81 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 2b8ee90bb644..96b22db7f763 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2002,6 +2002,19 @@
Built with CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y,
the default is off.
+ kprobe_event=[probe-list]
+ [FTRACE] Add kprobe events and enable at boot time.
+ The probe-list is a semicolon delimited list of probe
+ definitions. Each definition is same as kprobe_events
+ interface, but the parameters are comma delimited.
+ For example, to add a kprobe event on vfs_read with
+ arg1 and arg2, add to the command line;
+
+ kprobe_event=p,vfs_read,$arg1,$arg2
+
+ See also Documentation/trace/kprobetrace.rst "Kernel
+ Boot Parameter" section.
+
kpti= [ARM64] Control page table isolation of user
and kernel address spaces.
Default: enabled on cores which need mitigation.
diff --git a/Documentation/trace/kprobetrace.rst b/Documentation/trace/kprobetrace.rst
index 235ce2ab131a..5b129215ba33 100644
--- a/Documentation/trace/kprobetrace.rst
+++ b/Documentation/trace/kprobetrace.rst
@@ -124,6 +124,20 @@ You can check the total number of probe hits and probe miss-hits via
The first column is event name, the second is the number of probe hits,
the third is the number of probe miss-hits.
+Kernel Boot Parameter
+---------------------
+You can add and enable new kprobe events when booting up the kernel by
+"kprobe_event=" parameter. The parameter accepts a semicolon-delimited
+kprobe events, which format is similar to the kprobe_events.
+The difference is that the probe definition parameters are comma-delimited
+instead of space. For example, adding myprobe event on do_sys_open like below
+
+ p:myprobe do_sys_open dfd=%ax filename=%dx flags=%cx mode=+4($stack)
+
+should be below for kernel boot parameter (just replace spaces with comma)
+
+ p:myprobe,do_sys_open,dfd=%ax,filename=%dx,flags=%cx,mode=+4($stack)
+
Usage examples
--------------
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 7d736248a070..6983435ff017 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -12,6 +12,8 @@
#include <linux/rculist.h>
#include <linux/error-injection.h>
+#include <asm/setup.h> /* for COMMAND_LINE_SIZE */
+
#include "trace_dynevent.h"
#include "trace_kprobe_selftest.h"
#include "trace_probe.h"
@@ -19,6 +21,17 @@
#define KPROBE_EVENT_SYSTEM "kprobes"
#define KRETPROBE_MAXACTIVE_MAX 4096
+#define MAX_KPROBE_CMDLINE_SIZE 1024
+
+/* Kprobe early definition from command line */
+static char kprobe_boot_events_buf[COMMAND_LINE_SIZE] __initdata;
+
+static int __init set_kprobe_boot_events(char *str)
+{
+ strlcpy(kprobe_boot_events_buf, str, COMMAND_LINE_SIZE);
+ return 0;
+}
+__setup("kprobe_event=", set_kprobe_boot_events);
static int trace_kprobe_create(int argc, const char **argv);
static int trace_kprobe_show(struct seq_file *m, struct dyn_event *ev);
@@ -1450,6 +1463,44 @@ void destroy_local_trace_kprobe(struct trace_event_call *event_call)
}
#endif /* CONFIG_PERF_EVENTS */
+static __init void enable_boot_kprobe_events(void)
+{
+ struct trace_array *tr = top_trace_array();
+ struct trace_event_file *file;
+ struct trace_kprobe *tk;
+ struct dyn_event *pos;
+
+ mutex_lock(&event_mutex);
+ for_each_trace_kprobe(tk, pos) {
+ list_for_each_entry(file, &tr->events, list)
+ if (file->event_call == &tk->tp.call)
+ trace_event_enable_disable(file, 1, 0);
+ }
+ mutex_unlock(&event_mutex);
+}
+
+static __init void setup_boot_kprobe_events(void)
+{
+ char *p, *cmd = kprobe_boot_events_buf;
+ int ret;
+
+ strreplace(kprobe_boot_events_buf, ',', ' ');
+
+ while (cmd && *cmd != '\0') {
+ p = strchr(cmd, ';');
+ if (p)
+ *p++ = '\0';
+
+ ret = trace_run_command(cmd, create_or_delete_trace_kprobe);
+ if (ret)
+ pr_warn("Failed to add event(%d): %s\n", ret, cmd);
+
+ cmd = p;
+ }
+
+ enable_boot_kprobe_events();
+}
+
/* Make a tracefs interface for controlling probe points */
static __init int init_kprobe_trace(void)
{
@@ -1481,6 +1532,9 @@ static __init int init_kprobe_trace(void)
if (!entry)
pr_warn("Could not create tracefs 'kprobe_profile' entry\n");
+
+ setup_boot_kprobe_events();
+
return 0;
}
fs_initcall(init_kprobe_trace);
^ permalink raw reply related
* [PATCH 1/2] kprobes: Initialize kprobes at subsys_initcall
From: Masami Hiramatsu @ 2019-05-21 7:56 UTC (permalink / raw)
To: Steven Rostedt
Cc: Ingo Molnar, Naveen N . Rao, Anil S Keshavamurthy,
David S . Miller, Masami Hiramatsu, linux-kernel, linux-doc
In-Reply-To: <155842537599.4253.14690293652007233645.stgit@devnote2>
Initialize kprobes at subsys_initcall stage instead of module_init
since kprobes is not a module. This will allow ftrace kprobe
event to add new events when it is initializing because ftrace
kprobe event is initialized at fs_initcall.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
---
kernel/kprobes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index c83e54727131..b7b6c90bb59c 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2617,4 +2617,4 @@ static int __init debugfs_kprobe_init(void)
late_initcall(debugfs_kprobe_init);
#endif /* CONFIG_DEBUG_FS */
-module_init(init_kprobes);
+subsys_initcall(init_kprobes);
^ permalink raw reply related
* [PATCH 0/2] Enable new kprobe event at boot
From: Masami Hiramatsu @ 2019-05-21 7:56 UTC (permalink / raw)
To: Steven Rostedt
Cc: Ingo Molnar, Naveen N . Rao, Anil S Keshavamurthy,
David S . Miller, Masami Hiramatsu, linux-kernel, linux-doc
This series adds a kernel parameter, 'kprobe_event=' to add and enable
new kprobe events at boot time.
Currently ftrace can enable some existing trace events at boot time.
This also allows admin/developer to add new kprobe-events at boot
time to debug device drivers etc.
The syntax is similar to tracing/kprobe_events interface, but
uses ',' and ';' instead of ' ' and '\n' respectively. e.g.
kprobe_event=p,func1,$arg1,$arg2;p,func2,$arg1
will add probes on func1 with the 1st and the 2nd arguments and on
func2 with the 1st argument.
Note that 'trace_event=' option enables trace event at very early
timing, but the events added by 'kprobe_event=' are enabled right
before enabling device drivers at this point. It is enough for
tracing device driver initialization etc.
Thank you,
---
Masami Hiramatsu (2):
kprobes: Initialize kprobes at subsys_initcall
tracing/kprobe: Add kprobe_event= boot parameter
Documentation/admin-guide/kernel-parameters.txt | 13 ++++++
Documentation/trace/kprobetrace.rst | 14 ++++++
kernel/kprobes.c | 2 -
kernel/trace/trace_kprobe.c | 54 +++++++++++++++++++++++
4 files changed, 82 insertions(+), 1 deletion(-)
--
Masami Hiramatsu (Linaro)
^ permalink raw reply
* Re: [PATCH 4/4] ima: only audit failed appraisal verifications
From: Roberto Sassu @ 2019-05-21 7:32 UTC (permalink / raw)
To: Mimi Zohar, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-doc, linux-security-module, linux-kernel,
silviu.vlasceanu, stable
In-Reply-To: <1558387225.4039.78.camel@linux.ibm.com>
On 5/20/2019 11:20 PM, Mimi Zohar wrote:
> On Thu, 2019-05-16 at 18:12 +0200, Roberto Sassu wrote:
>> This patch ensures that integrity_audit_msg() is called only when the
>> status is not INTEGRITY_PASS.
>>
>> Fixes: 8606404fa555c ("ima: digital signature verification support")
>> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
>> Cc: stable@vger.kernel.org
>> ---
>> security/integrity/ima/ima_appraise.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
>> index a32ed5d7afd1..f5f4506bcb8e 100644
>> --- a/security/integrity/ima/ima_appraise.c
>> +++ b/security/integrity/ima/ima_appraise.c
>> @@ -359,8 +359,9 @@ int ima_appraise_measurement(enum ima_hooks func,
>> status = INTEGRITY_PASS;
>> }
>>
>> - integrity_audit_msg(AUDIT_INTEGRITY_DATA, inode, filename,
>> - op, cause, rc, 0);
>> + if (status != INTEGRITY_PASS)
>> + integrity_audit_msg(AUDIT_INTEGRITY_DATA, inode,
>> + filename, op, cause, rc, 0);
>
> For some reason, the integrity verification has failed. In some
> specific cases, we'll let it pass, but do we really want to remove any
> indication that it failed in all cases?
Ok. It is fine for me to discard the patch.
Roberto
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI
^ permalink raw reply
* Inquiry 20/May/2019
From: Daniel Murray @ 2019-05-20 13:31 UTC (permalink / raw)
To: linux-doc
Hi,friend,
This is Daniel Murray and i am from Sinara Group Co.Ltd in Russia.
We are glad to know about your company from the web and we are interested in your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Best Regards,
Daniel Murray
Purchasing Manager
^ permalink raw reply
* Re: [PATCH 3/4] ima: don't ignore INTEGRITY_UNKNOWN EVM status
From: Roberto Sassu @ 2019-05-21 7:26 UTC (permalink / raw)
To: Mimi Zohar, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-doc, linux-security-module, linux-kernel,
silviu.vlasceanu, stable
In-Reply-To: <1558387212.4039.77.camel@linux.ibm.com>
On 5/20/2019 11:20 PM, Mimi Zohar wrote:
> On Thu, 2019-05-16 at 18:12 +0200, Roberto Sassu wrote:
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 52e6fbb042cc..80e1c233656b 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -1588,6 +1588,9 @@
>> Format: { "off" | "enforce" | "fix" | "log" }
>> default: "enforce"
>>
>> + ima_appraise_req_evm
>> + [IMA] require EVM for appraisal with file digests.
>
> As much as possible we want to limit the number of new boot command
> line options as possible. Is there a reason for not extending
> "ima_appraise=" with "require-evm" or "enforce-evm"?
ima-appraise= can be disabled with CONFIG_IMA_APPRAISE_BOOTPARAM, which
probably is done when the system is in production.
Should I allow to use ima-appraise=require-evm even if
CONFIG_IMA_APPRAISE_BOOTPARAM=n?
Thanks
Roberto
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI
^ permalink raw reply
* Re: [kbuild:kunit 14/17] htmldocs: include/kunit/kunit-stream.h:58: warning: Function parameter or member '2' not described in '__printf'
From: Randy Dunlap @ 2019-05-21 4:49 UTC (permalink / raw)
To: Brendan Higgins, kbuild test robot
Cc: kbuild-all, linux-kbuild, Masahiro Yamada, Felix Guo,
linux-doc@vger.kernel.org, Jonathan Corbet
In-Reply-To: <CAFd5g46nZ0=Djo6d6iqdSQLaLP0Qq5bC+uzyjpqp5fXnty7YOg@mail.gmail.com>
On 5/10/19 2:03 PM, Brendan Higgins wrote:
> On Thu, May 9, 2019 at 6:23 PM kbuild test robot <lkp@intel.com> wrote:
>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git kunit
>> head: c505c0b2e6237c729634327c178f5b0094f1c958
>> commit: c69e87665049970d1c2d6fe2fa1ae7a7c8655420 [14/17] Documentation: kunit: add documentation for KUnit
>> reproduce: make htmldocs
>>
>> If you fix the issue, kindly add following tag
>> Reported-by: kbuild test robot <lkp@intel.com>
>>
>> All warnings (new ones prefixed by >>):
> < snip >
>> drivers/gpu/drm/i915/i915_vma.h:50: warning: cannot understand function prototype: 'struct i915_vma '
>> drivers/gpu/drm/i915/i915_vma.h:1: warning: no structured comments found
>> drivers/gpu/drm/i915/intel_guc_fwif.h:536: warning: cannot understand function prototype: 'struct guc_log_buffer_state '
>> drivers/gpu/drm/i915/i915_trace.h:1: warning: no structured comments found
>> drivers/gpu/drm/i915/i915_reg.h:156: warning: bad line:
>> include/linux/interconnect.h:1: warning: no structured comments found
>>>> include/kunit/kunit-stream.h:58: warning: Function parameter or member '2' not described in '__printf'
>
> This looks like a bug in the kernel-doc parser: __printf in this context is:
>
>> 8dcda743 Brendan Higgins 2019-05-01 56 void __printf(2, 3) kunit_stream_add(struct kunit_stream *this,
>> 8dcda743 Brendan Higgins 2019-05-01 57 const char *fmt, ...);
>
> which is an attribute to tell the compiler that this is a printf style
> function with a printf style format string; it doesn't make sense to
> describe it's parameters.
Yes. I'm a little surprised that this has never come up before, but in my
quick examination, it seems that most people put the __printf() attribute
in a header file but not in the .c implementation file, then they document
the function in the .c file, not in the header file, so it hasn't been needed.
Ignoring __printf() could be added to scripts/kernel-doc. I added
kernel-doc notation to <linux/kernel.h> panic() and then tested it with
the patch below. ItWorksForMe. :)
>> include/kunit/kunit-stream.h:58: warning: Function parameter or member '3' not described in '__printf'
>> include/kunit/kunit-stream.h:58: warning: Excess function parameter 'this' description in '__printf'
>> include/kunit/kunit-stream.h:58: warning: Excess function parameter 'fmt' description in '__printf'
>> include/linux/skbuff.h:897: warning: Function parameter or member 'dev_scratch' not described in 'sk_buff'
> < snip >
>> fs/debugfs/file.c:439: WARNING: Inline literal start-string without end-string.
>>
>> vim +58 include/kunit/kunit-stream.h
>>
>> 8dcda743 Brendan Higgins 2019-05-01 48
>> 8dcda743 Brendan Higgins 2019-05-01 49 /**
>> 8dcda743 Brendan Higgins 2019-05-01 50 * kunit_stream_add(): adds the formatted input to the internal buffer.
>> 8dcda743 Brendan Higgins 2019-05-01 51 * @this: the stream being operated on.
>> 8dcda743 Brendan Higgins 2019-05-01 52 * @fmt: printf style format string to append to stream.
>> 8dcda743 Brendan Higgins 2019-05-01 53 *
>> 8dcda743 Brendan Higgins 2019-05-01 54 * Appends the formatted string, @fmt, to the internal buffer.
>> 8dcda743 Brendan Higgins 2019-05-01 55 */
>> 8dcda743 Brendan Higgins 2019-05-01 56 void __printf(2, 3) kunit_stream_add(struct kunit_stream *this,
>> 8dcda743 Brendan Higgins 2019-05-01 57 const char *fmt, ...);
>> 8dcda743 Brendan Higgins 2019-05-01 @58
>>
>> :::::: The code at line 58 was first introduced by commit
>> :::::: 8dcda743c31c1ffc0ac13f3d23f3dd1b85b545f8 kunit: test: add kunit_stream a std::stream like logger
>
> Thanks!
---
From: Randy Dunlap <rdunlap@infradead.org>
Ignore __printf() function attributes just as other __attribute__
strings are ignored.
Fixes this kernel-doc warning message:
include/kunit/kunit-stream.h:58: warning: Function parameter or member '2' not described in '__printf'
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Brendan Higgins <brendanhiggins@google.com>
---
scripts/kernel-doc | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20190520.orig/scripts/kernel-doc
+++ linux-next-20190520/scripts/kernel-doc
@@ -1580,6 +1580,7 @@ sub dump_function($$) {
$prototype =~ s/__must_check +//;
$prototype =~ s/__weak +//;
$prototype =~ s/__sched +//;
+ $prototype =~ s/__printf\s*\(\s*\d*\s*,\s*\d*\s*\) +//;
my $define = $prototype =~ s/^#\s*define\s+//; #ak added
$prototype =~ s/__attribute__\s*\(\(
(?:
^ permalink raw reply
* [PATCH] net-next: net: Fix typos in ip-sysctl.txt
From: Masanari Iida @ 2019-05-21 3:41 UTC (permalink / raw)
To: corbet, linux-doc, linux-kernel, netdev, davem; +Cc: Masanari Iida
This patch fixes some spelling typos found in ip-sysctl.txt
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
---
Documentation/networking/ip-sysctl.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 725b8bea58a7..14fe93049d28 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -560,10 +560,10 @@ tcp_comp_sack_delay_ns - LONG INTEGER
Default : 1,000,000 ns (1 ms)
tcp_comp_sack_nr - INTEGER
- Max numer of SACK that can be compressed.
+ Max number of SACK that can be compressed.
Using 0 disables SACK compression.
- Detault : 44
+ Default : 44
tcp_slow_start_after_idle - BOOLEAN
If set, provide RFC2861 behavior and time out the congestion
--
2.22.0.rc1
^ permalink raw reply related
* Re: [PATCH] networking: : fix typos in code comments
From: David Miller @ 2019-05-21 0:24 UTC (permalink / raw)
To: houweitaoo; +Cc: corbet, netdev, linux-doc, linux-kernel
In-Reply-To: <20190520052317.27871-1-houweitaoo@gmail.com>
From: Weitao Hou <houweitaoo@gmail.com>
Date: Mon, 20 May 2019 13:23:17 +0800
> fix accelleration to acceleration
>
> Signed-off-by: Weitao Hou <houweitaoo@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 08/10] dt: fix refs that were renamed to json with the same file name
From: Rob Herring @ 2019-05-20 23:00 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel@vger.kernel.org, Jonathan Corbet, Mark Rutland,
Michael Turquette, Stephen Boyd, Thomas Gleixner, Jason Cooper,
Marc Zyngier, Jacek Anaszewski, Pavel Machek, Dan Murphy,
David S. Miller, Greg Kroah-Hartman, Linus Walleij, Nicolas Ferre,
Paul E. McKenney, devicetree, linux-clk, Linux LED Subsystem
In-Reply-To: <20190520131344.39635733@coco.lan>
On Mon, May 20, 2019 at 11:14 AM Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
>
> Em Mon, 20 May 2019 10:57:47 -0500
> Rob Herring <robh+dt@kernel.org> escreveu:
>
> > On Mon, May 20, 2019 at 9:48 AM Mauro Carvalho Chehab
> > <mchehab+samsung@kernel.org> wrote:
> > >
> > > This file was converted to json, but the references weren't
> >
> > Technically, converted to json-schema (the language) or yaml (the format).
>
> Ok. Do you want me to change it at the patch and resend?
No, I can fixup.
>
> >
> > > renamed.
> > >
> > > Fixes: 66ed144f147a ("dt-bindings: interrupt-controller: Convert ARM GIC to json-schema")
> > > (and other similar commits)
> > >
> > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > > ---
> > > Documentation/devicetree/bindings/arm/omap/crossbar.txt | 2 +-
> > > .../devicetree/bindings/clock/samsung,s5pv210-clock.txt | 2 +-
> > > .../bindings/interrupt-controller/marvell,odmi-controller.txt | 2 +-
> > > Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt | 2 +-
> > > MAINTAINERS | 4 ++--
> > > 5 files changed, 6 insertions(+), 6 deletions(-)
> >
> > FYI, I'm actively looking for this in conversions now as we've had a
> > few of these. For cases where we have a lot of references, I'm fixing
> > this by keeping the .txt file with a reference to the .yaml file.
>
> If the file name remains with the same name, except for the .txt -> .yaml,
> you can just run the "scripts/documentation-file-ref-check --fix"
> after this patch:
>
> Subject: [PATCH 04/10] scripts/documentation-file-ref-check: teach about .txt -> .yaml renames
>
> and it should detect and automatically fix all the references. As any
> auto-hint script, you need to double-check the results.
Nice!
>
> > I'll pick up the DT patches in the series.
>
> OK. There are a few such fixes inside patch 10/10. Do you want me
> to split it or can it go through Jonathan's doc tree?
Jon's tree is fine.
Rob
^ permalink raw reply
* [PATCH] lib/sort.c: fix kernel-doc notation warnings
From: Randy Dunlap @ 2019-05-20 21:20 UTC (permalink / raw)
To: LKML, Andrew Morton; +Cc: George Spelvin, linux-doc@vger.kernel.org
From: Randy Dunlap <rdunlap@infradead.org>
Fix kernel-doc notation in lib/sort.c by using correct function
parameter names.
../lib/sort.c:59: warning: Excess function parameter 'size' description in 'swap_words_32'
../lib/sort.c:83: warning: Excess function parameter 'size' description in 'swap_words_64'
../lib/sort.c:110: warning: Excess function parameter 'size' description in 'swap_bytes'
Fixes: 37d0ec34d111a ("lib/sort: make swap functions more generic")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: George Spelvin <lkml@sdf.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
This patch still leaves these Sphinx warnings, which appears to be
some kind of "feature." :(
../lib/list_sort.c:128: WARNING: Definition list ends without a blank line; unexpected unindent.
../lib/list_sort.c:161: WARNING: Unexpected indentation.
../lib/list_sort.c:162: WARNING: Block quote ends without a blank line; unexpected unindent.
lib/sort.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
--- lnx-52-rc1.orig/lib/sort.c
+++ lnx-52-rc1/lib/sort.c
@@ -43,8 +43,9 @@ static bool is_aligned(const void *base,
/**
* swap_words_32 - swap two elements in 32-bit chunks
- * @a, @b: pointers to the elements
- * @size: element size (must be a multiple of 4)
+ * @a: pointer to the first element to swap
+ * @b: pointer to the second element to swap
+ * @n: element size (must be a multiple of 4)
*
* Exchange the two objects in memory. This exploits base+index addressing,
* which basically all CPUs have, to minimize loop overhead computations.
@@ -65,8 +66,9 @@ static void swap_words_32(void *a, void
/**
* swap_words_64 - swap two elements in 64-bit chunks
- * @a, @b: pointers to the elements
- * @size: element size (must be a multiple of 8)
+ * @a: pointer to the first element to swap
+ * @b: pointer to the second element to swap
+ * @n: element size (must be a multiple of 8)
*
* Exchange the two objects in memory. This exploits base+index
* addressing, which basically all CPUs have, to minimize loop overhead
@@ -100,8 +102,9 @@ static void swap_words_64(void *a, void
/**
* swap_bytes - swap two elements a byte at a time
- * @a, @b: pointers to the elements
- * @size: element size
+ * @a: pointer to the first element to swap
+ * @b: pointer to the second element to swap
+ * @n: element size
*
* This is the fallback if alignment doesn't allow using larger chunks.
*/
^ permalink raw reply
* Re: [PATCH 4/4] ima: only audit failed appraisal verifications
From: Mimi Zohar @ 2019-05-20 21:20 UTC (permalink / raw)
To: Roberto Sassu, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-doc, linux-security-module, linux-kernel,
silviu.vlasceanu, stable
In-Reply-To: <20190516161257.6640-4-roberto.sassu@huawei.com>
On Thu, 2019-05-16 at 18:12 +0200, Roberto Sassu wrote:
> This patch ensures that integrity_audit_msg() is called only when the
> status is not INTEGRITY_PASS.
>
> Fixes: 8606404fa555c ("ima: digital signature verification support")
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> Cc: stable@vger.kernel.org
> ---
> security/integrity/ima/ima_appraise.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
> index a32ed5d7afd1..f5f4506bcb8e 100644
> --- a/security/integrity/ima/ima_appraise.c
> +++ b/security/integrity/ima/ima_appraise.c
> @@ -359,8 +359,9 @@ int ima_appraise_measurement(enum ima_hooks func,
> status = INTEGRITY_PASS;
> }
>
> - integrity_audit_msg(AUDIT_INTEGRITY_DATA, inode, filename,
> - op, cause, rc, 0);
> + if (status != INTEGRITY_PASS)
> + integrity_audit_msg(AUDIT_INTEGRITY_DATA, inode,
> + filename, op, cause, rc, 0);
For some reason, the integrity verification has failed. In some
specific cases, we'll let it pass, but do we really want to remove any
indication that it failed in all cases?
Mimi
> } else {
> ima_cache_flags(iint, func);
> }
^ permalink raw reply
* Re: [PATCH 3/4] ima: don't ignore INTEGRITY_UNKNOWN EVM status
From: Mimi Zohar @ 2019-05-20 21:20 UTC (permalink / raw)
To: Roberto Sassu, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-doc, linux-security-module, linux-kernel,
silviu.vlasceanu, stable
In-Reply-To: <20190516161257.6640-3-roberto.sassu@huawei.com>
On Thu, 2019-05-16 at 18:12 +0200, Roberto Sassu wrote:
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 52e6fbb042cc..80e1c233656b 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1588,6 +1588,9 @@
> Format: { "off" | "enforce" | "fix" | "log" }
> default: "enforce"
>
> + ima_appraise_req_evm
> + [IMA] require EVM for appraisal with file digests.
As much as possible we want to limit the number of new boot command
line options as possible. Is there a reason for not extending
"ima_appraise=" with "require-evm" or "enforce-evm"?
Mimi
> +
> ima_appraise_tcb [IMA] Deprecated. Use ima_policy= instead.
> The builtin appraise policy appraises all files
> owned by uid=0.
^ permalink raw reply
* Re: [PATCH 2/4] evm: reset status in evm_inode_post_setattr()
From: Mimi Zohar @ 2019-05-20 21:19 UTC (permalink / raw)
To: Roberto Sassu, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-doc, linux-security-module, linux-kernel,
silviu.vlasceanu, stable
In-Reply-To: <20190516161257.6640-2-roberto.sassu@huawei.com>
On Thu, 2019-05-16 at 18:12 +0200, Roberto Sassu wrote:
> This patch adds a call to evm_reset_status() in evm_inode_post_setattr(),
> before security.evm is updated. The same is done in the other
> evm_inode_post_* functions.
>
> Fixes: 523b74b16bcbb ("evm: reset EVM status when file attributes change")
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> Cc: stable@vger.kernel.org
Why all of a sudden do we also need to clear the EVM cached status
when modifying the file attributes? The HMAC is being recalculated.
If the reason is because of EVM portable and immutable signatures,
then the "Fixes" tag is incorrect.
Mimi
> ---
> security/integrity/evm/evm_main.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/security/integrity/evm/evm_main.c b/security/integrity/evm/evm_main.c
> index b6d9f14bc234..b41c2d8a8834 100644
> --- a/security/integrity/evm/evm_main.c
> +++ b/security/integrity/evm/evm_main.c
> @@ -512,8 +512,11 @@ void evm_inode_post_setattr(struct dentry *dentry, int ia_valid)
> if (!evm_key_loaded())
> return;
>
> - if (ia_valid & (ATTR_MODE | ATTR_UID | ATTR_GID))
> + if (ia_valid & (ATTR_MODE | ATTR_UID | ATTR_GID)) {
> + evm_reset_status(dentry->d_inode);
> +
> evm_update_evmxattr(dentry, NULL, NULL, 0);
> + }
> }
>
> /*
^ 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