[PATCH 20/32] tracing: Add support for dynamic tracepoints

The tracepoint infrastructure assumes statically-defined tracepoints and uses static_keys for tracepoint enablement. In order to define tracepoints on the fly, we need to have a dynamic counterpart. Add a dynamic_tracepoint_probe_register() and a dynamic param onto tracepoint_probe_unregister()

[PATCH 20/32] tracing: Add support for dynamic tracepoints

The tracepoint infrastructure assumes statically-defined tracepoints and uses static_keys for tracepoint enablement. In order to define tracepoints on the fly, we need to have a dynamic counterpart. Add a dynamic_tracepoint_probe_register() and a dynamic param onto tracepoint_probe_unregister()

[PATCH 16/32] tracing: Add variable support to hist triggers

Add support for saving the value of a current event's event field by assigning it to a variable that can be read by a subsequent event. The basic syntax for saving a variable is to simply prefix a unique variable name not corresponding to any keyword along with an '=' sign to any event field.

[PATCH 16/32] tracing: Add variable support to hist triggers

Add support for saving the value of a current event's event field by assigning it to a variable that can be read by a subsequent event. The basic syntax for saving a variable is to simply prefix a unique variable name not corresponding to any keyword along with an '=' sign to any event field.

[PATCH 25/32] tracing: Allow whitespace to surround hist trigger filter

The existing code only allows for one space before and after the 'if' specifying the filter for a hist trigger. Add code to make that more permissive as far as whitespace goes. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 19 +++

[PATCH 25/32] tracing: Allow whitespace to surround hist trigger filter

The existing code only allows for one space before and after the 'if' specifying the filter for a hist trigger. Add code to make that more permissive as far as whitespace goes. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 19 +++ 1 file changed, 15

[PATCH 24/32] tracing: Add 'onmax' hist trigger action support

Add an 'onmax(var).save(field,...)' hist trigger action which is invoked whenever an event exceeds the current maximum. The end result is that the trace event fields or variables specified as the onmax.save() params will be saved if 'var' exceeds the current maximum for that hist trigger entry.

[PATCH 27/32] tracing: Add cpu field for hist triggers

A common key to use in a histogram is the cpuid - add a new cpu 'synthetic' field for that purpose. This field is named cpu rather than $cpu or $common_cpu because 'cpu' already exists as a special filter field and it makes more sense to match that rather than add another name for the same thing.

[PATCH 14/32] tracing: Add hist_data member to hist_field

Allow hist_data access via hist_field. Some users of hist_fields require or will require more access to the associated hist_data. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-)

[PATCH 27/32] tracing: Add cpu field for hist triggers

A common key to use in a histogram is the cpuid - add a new cpu 'synthetic' field for that purpose. This field is named cpu rather than $cpu or $common_cpu because 'cpu' already exists as a special filter field and it makes more sense to match that rather than add another name for the same thing.

[PATCH 14/32] tracing: Add hist_data member to hist_field

Allow hist_data access via hist_field. Some users of hist_fields require or will require more access to the associated hist_data. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git

[PATCH 24/32] tracing: Add 'onmax' hist trigger action support

Add an 'onmax(var).save(field,...)' hist trigger action which is invoked whenever an event exceeds the current maximum. The end result is that the trace event fields or variables specified as the onmax.save() params will be saved if 'var' exceeds the current maximum for that hist trigger entry.

[PATCH 23/32] tracing: Add 'onmatch' hist trigger action support

Add an 'onmatch(matching.event).(param list)' hist trigger action which is invoked with the set of variables or event fields named in the 'param list'. The result is the generation of a synthetic event that consists of the values contained in those variables and/or fields at the time the invoking

[PATCH 23/32] tracing: Add 'onmatch' hist trigger action support

Add an 'onmatch(matching.event).(param list)' hist trigger action which is invoked with the set of variables or event fields named in the 'param list'. The result is the generation of a synthetic event that consists of the values contained in those variables and/or fields at the time the invoking

[PATCH 19/32] tracing: Add variable reference handling to hist triggers

Add the necessary infrastructure to allow the variables defined on one event to be referenced in another. This allows variables set by a previous event to be referenced and used in expressions combining the variable values saved by that previous event and the event fields of the current event.

[PATCH 19/32] tracing: Add variable reference handling to hist triggers

Add the necessary infrastructure to allow the variables defined on one event to be referenced in another. This allows variables set by a previous event to be referenced and used in expressions combining the variable values saved by that previous event and the event fields of the current event.

Re: [kernel-hardening] non-x86 per-task stack canaries

On Mon, 2017-06-26 at 14:04 -0700, Kees Cook wrote: > Hi, > > The stack protector functionality on x86_64 uses %gs:0x28 (%gs is the > percpu area) for __stack_chk_guard, and all other architectures use a > global variable instead. This means we never change the stack canary > on non-x86

Re: [kernel-hardening] non-x86 per-task stack canaries

On Mon, 2017-06-26 at 14:04 -0700, Kees Cook wrote: > Hi, > > The stack protector functionality on x86_64 uses %gs:0x28 (%gs is the > percpu area) for __stack_chk_guard, and all other architectures use a > global variable instead. This means we never change the stack canary > on non-x86

[PATCH 30/32] tracing: Add inter-event hist trigger Documentation

Add background and details on inter-event hist triggers, including hist variables, synthetic events, and actions. Signed-off-by: Tom Zanussi --- Documentation/trace/events.txt | 376 + 1 file changed, 376 insertions(+) diff

[PATCH 30/32] tracing: Add inter-event hist trigger Documentation

Add background and details on inter-event hist triggers, including hist variables, synthetic events, and actions. Signed-off-by: Tom Zanussi --- Documentation/trace/events.txt | 376 + 1 file changed, 376 insertions(+) diff --git

[PATCH 29/32] tracing: Add 'last error' error facility for hist triggers

With the addition of variables and actions, it's become necessary to provide more detailed error information to users about syntax errors. Add a 'last error' facility accessible via the erroring event's 'hist' file. Reading the hist file after an error will display more detailed information

[PATCH 26/32] tracing: Make duplicate count from tracing_map available

Though extremely rare, there can be duplicate entries in the tracing map. This isn't normally a problem, as the sorting code makes this transparent by merging them during the sort. It's useful to know however, as a check on that assumption - if a non-zero duplicate count is seen more than

[PATCH 29/32] tracing: Add 'last error' error facility for hist triggers

With the addition of variables and actions, it's become necessary to provide more detailed error information to users about syntax errors. Add a 'last error' facility accessible via the erroring event's 'hist' file. Reading the hist file after an error will display more detailed information

[PATCH 26/32] tracing: Make duplicate count from tracing_map available

Though extremely rare, there can be duplicate entries in the tracing map. This isn't normally a problem, as the sorting code makes this transparent by merging them during the sort. It's useful to know however, as a check on that assumption - if a non-zero duplicate count is seen more than

[PATCH 32/32] tracing: Add a clock attribute for hist triggers

The default clock if timestamps are used in a histogram is "global". If timestamps aren't used, the clock is irrelevant. Use the "clock=" param only if you want to override the default "global" clock for a histogram with timestamps. Signed-off-by: Tom Zanussi ---

[PATCH 31/32] tracing: Make tracing_set_clock() non-static

Allow tracing code outside of trace.c to access tracing_set_clock(). Some applications may require a particular clock in order to function properly, such as latency calculations. Also, add an accessor returning the current clock string. Signed-off-by: Tom Zanussi

[PATCH 28/32] tracing: Add hist trigger support for variable reference aliases

Add support for alias=$somevar where alias can be used as onmatch($alias). Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 46 +--- 1 file changed, 43 insertions(+), 3 deletions(-) diff --git

[PATCH 31/32] tracing: Make tracing_set_clock() non-static

Allow tracing code outside of trace.c to access tracing_set_clock(). Some applications may require a particular clock in order to function properly, such as latency calculations. Also, add an accessor returning the current clock string. Signed-off-by: Tom Zanussi --- kernel/trace/trace.c | 2

[PATCH 28/32] tracing: Add hist trigger support for variable reference aliases

Add support for alias=$somevar where alias can be used as onmatch($alias). Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 46 +--- 1 file changed, 43 insertions(+), 3 deletions(-) diff --git a/kernel/trace/trace_events_hist.c

[PATCH 32/32] tracing: Add a clock attribute for hist triggers

The default clock if timestamps are used in a histogram is "global". If timestamps aren't used, the clock is irrelevant. Use the "clock=" param only if you want to override the default "global" clock for a histogram with timestamps. Signed-off-by: Tom Zanussi --- Documentation/trace/events.txt

[PATCH 17/32] tracing: Account for variables in named trigger compatibility

Named triggers must also have the same set of variables in order to be considered compatible - update the trigger match test to account for that. The reason for this requirement is that named triggers with variables are meant to allow one or more events to set the same variable. Signed-off-by:

[PATCH 17/32] tracing: Account for variables in named trigger compatibility

Named triggers must also have the same set of variables in order to be considered compatible - update the trigger match test to account for that. The reason for this requirement is that named triggers with variables are meant to allow one or more events to set the same variable. Signed-off-by:

[PATCH 22/32] tracing: Add support for 'synthetic' events

Synthetic events are user-defined events generated from hist trigger variables saved from one or more other events. To define a synthetic event, the user writes a simple specification consisting of the name of the new event along with one or more variables and their type(s), to the

[PATCH 22/32] tracing: Add support for 'synthetic' events

Synthetic events are user-defined events generated from hist trigger variables saved from one or more other events. To define a synthetic event, the user writes a simple specification consisting of the name of the new event along with one or more variables and their type(s), to the

[PATCH 21/32] tracing: Add hist trigger action hook

Add a hook for executing extra actions whenever a histogram entry is added or updated. The default 'action' when a hist entry is added to a histogram is to update the set of values associated with it. Some applications may want to perform additional actions at that point, such as generate

[PATCH 21/32] tracing: Add hist trigger action hook

Add a hook for executing extra actions whenever a histogram entry is added or updated. The default 'action' when a hist entry is added to a histogram is to update the set of values associated with it. Some applications may want to perform additional actions at that point, such as generate

[PATCH 05/32] tracing: Give event triggers access to ring_buffer_event

The ring_buffer event can provide a timestamp that may be useful to various triggers - pass it into the handlers for that purpose. Signed-off-by: Tom Zanussi --- include/linux/trace_events.h| 14 ++- kernel/trace/trace.h| 9 +++

[PATCH 05/32] tracing: Give event triggers access to ring_buffer_event

The ring_buffer event can provide a timestamp that may be useful to various triggers - pass it into the handlers for that purpose. Signed-off-by: Tom Zanussi --- include/linux/trace_events.h| 14 ++- kernel/trace/trace.h| 9 +++

[PATCH 08/32] tracing: Break out hist trigger assignment parsing

This will make it easier to add variables, and makes the parsing code cleaner regardless. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 56 +--- 1 file changed, 35 insertions(+), 21 deletions(-) diff --git

[PATCH 06/32] tracing: Add ring buffer event param to hist field functions

Some events such as timestamps require access to a ring_buffer_event struct; add a param so that hist field functions can access that. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 39 --- 1 file changed, 24

[PATCH 06/32] tracing: Add ring buffer event param to hist field functions

Some events such as timestamps require access to a ring_buffer_event struct; add a param so that hist field functions can access that. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 39 --- 1 file changed, 24 insertions(+), 15 deletions(-)

[PATCH 08/32] tracing: Break out hist trigger assignment parsing

This will make it easier to add variables, and makes the parsing code cleaner regardless. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 56 +--- 1 file changed, 35 insertions(+), 21 deletions(-) diff --git

[PATCH 02/32] tracing: Reimplement log2

log2 as currently implemented applies only to u64 trace_event_field derived fields, and assumes that anything it's applied to is a u64 field. To prepare for synthetic fields like latencies, log2 should be applicable to those as well, so take the opportunity now to fix the current problems as well

[PATCH 02/32] tracing: Reimplement log2

log2 as currently implemented applies only to u64 trace_event_field derived fields, and assumes that anything it's applied to is a u64 field. To prepare for synthetic fields like latencies, log2 should be applicable to those as well, so take the opportunity now to fix the current problems as well

[PATCH 00/32] tracing: Inter-event (e.g. latency) support

This patchset adds support for 'inter-event' quantities to the trace event subsystem. The most important example of inter-event quantities are latencies, or the time differences between two events. This is a follow-up to the initial RFC patchset and subsequent discussion at ELC. I think I've

[PATCH 00/32] tracing: Inter-event (e.g. latency) support

This patchset adds support for 'inter-event' quantities to the trace event subsystem. The most important example of inter-event quantities are latencies, or the time differences between two events. This is a follow-up to the initial RFC patchset and subsequent discussion at ELC. I think I've

Re: [PATCH v8 3/3] mailbox: qcom: Add support for APCS clock controller

On 06/23, Georgi Djakov wrote: > diff --git a/drivers/mailbox/qcom-apcs-ipc-mailbox.c > b/drivers/mailbox/qcom-apcs-ipc-mailbox.c > index 9924c6d7f05d..da363c6580da 100644 > --- a/drivers/mailbox/qcom-apcs-ipc-mailbox.c > +++ b/drivers/mailbox/qcom-apcs-ipc-mailbox.c > @@ -11,6 +11,8 @@ > * GNU

Re: [PATCH v8 3/3] mailbox: qcom: Add support for APCS clock controller

On 06/23, Georgi Djakov wrote: > diff --git a/drivers/mailbox/qcom-apcs-ipc-mailbox.c > b/drivers/mailbox/qcom-apcs-ipc-mailbox.c > index 9924c6d7f05d..da363c6580da 100644 > --- a/drivers/mailbox/qcom-apcs-ipc-mailbox.c > +++ b/drivers/mailbox/qcom-apcs-ipc-mailbox.c > @@ -11,6 +11,8 @@ > * GNU

Re: [PATCH v3 0/4] kmod: help make deterministic

On Mon, Jun 26, 2017 at 11:37:36PM +0200, Jessica Yu wrote: > +++ Kees Cook [20/06/17 17:23 -0700]: > > On Tue, Jun 20, 2017 at 1:56 PM, Luis R. Rodriguez > > wrote: > > > On Fri, May 26, 2017 at 02:12:24PM -0700, Luis R. Rodriguez wrote: > > > > This v3 nukes the proc sysctl

Re: [PATCH v3 0/4] kmod: help make deterministic

On Mon, Jun 26, 2017 at 11:37:36PM +0200, Jessica Yu wrote: > +++ Kees Cook [20/06/17 17:23 -0700]: > > On Tue, Jun 20, 2017 at 1:56 PM, Luis R. Rodriguez > > wrote: > > > On Fri, May 26, 2017 at 02:12:24PM -0700, Luis R. Rodriguez wrote: > > > > This v3 nukes the proc sysctl interface in favor

Re: [PATCH 0/6] Update binding documentation for cp110 and ap806

On 06/23, Gregory CLEMENT wrote: > Hi Mike, > > > as you were not in CC of the thread here is the reference: > http://lists.infradead.org/pipermail/linux-arm-kernel/2017-June/514497.html > > On jeu., juin 22 2017, Rob Herring wrote: > > > On Tue, Jun 20, 2017 at 05:34:57PM

Re: [PATCH 0/6] Update binding documentation for cp110 and ap806

On 06/23, Gregory CLEMENT wrote: > Hi Mike, > > > as you were not in CC of the thread here is the reference: > http://lists.infradead.org/pipermail/linux-arm-kernel/2017-June/514497.html > > On jeu., juin 22 2017, Rob Herring wrote: > > > On Tue, Jun 20, 2017 at 05:34:57PM +0200, Gregory

[PATCH v2 2/4] soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states (ARM)

From: Brian Norris This commit adds support for the Broadcom STB S2/S3/S5 suspend states on ARM based SoCs. This requires quite a lot of code in order to deal with the different HW blocks that need to be quiesced during suspend: - DDR PHY SHIM - DDR memory

[PATCH v2 2/4] soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states (ARM)

From: Brian Norris This commit adds support for the Broadcom STB S2/S3/S5 suspend states on ARM based SoCs. This requires quite a lot of code in order to deal with the different HW blocks that need to be quiesced during suspend: - DDR PHY SHIM - DDR memory controller and sequencer - control

[PATCH v2 3/4] dt-bindings: Document MIPS Broadcom STB power management nodes

Document the different nodes required for supporting S2/S3/S5 suspend states on MIPS-based Broadcom STB SoCs. Signed-off-by: Florian Fainelli --- .../devicetree/bindings/mips/brcm/soc.txt | 153 + 1 file changed, 153 insertions(+) diff --git

[PATCH v2 3/4] dt-bindings: Document MIPS Broadcom STB power management nodes

Document the different nodes required for supporting S2/S3/S5 suspend states on MIPS-based Broadcom STB SoCs. Signed-off-by: Florian Fainelli --- .../devicetree/bindings/mips/brcm/soc.txt | 153 + 1 file changed, 153 insertions(+) diff --git

[PATCH 3/4] dt-bindings: Document the Broadcom STB wake-up timer node

Document the binding for the Broadcom STB SoCs wake-up timer node allowing the system to generate alarms and exit low power states. Acked-by: Rob Herring Signed-off-by: Florian Fainelli --- .../bindings/rtc/brcm,brcmstb-waketimer.txt| 22

Re: [PATCH v2 0/4] Broadcom STB S2/S3/S5 support for ARM and MIPS

On 06/26/2017 03:32 PM, Florian Fainelli wrote: > Hi, > > This patch series adds support for S2/S3/S5 suspend/resume states on > ARM and MIPS based Broadcom STB SoCs. > > This was submitted a long time ago by Brian, and I am now picking this > up and trying to get this included with support for

[PATCH 3/4] dt-bindings: Document the Broadcom STB wake-up timer node

Document the binding for the Broadcom STB SoCs wake-up timer node allowing the system to generate alarms and exit low power states. Acked-by: Rob Herring Signed-off-by: Florian Fainelli --- .../bindings/rtc/brcm,brcmstb-waketimer.txt| 22 ++ 1 file changed, 22

Re: [PATCH v2 0/4] Broadcom STB S2/S3/S5 support for ARM and MIPS

On 06/26/2017 03:32 PM, Florian Fainelli wrote: > Hi, > > This patch series adds support for S2/S3/S5 suspend/resume states on > ARM and MIPS based Broadcom STB SoCs. > > This was submitted a long time ago by Brian, and I am now picking this > up and trying to get this included with support for

[PATCH] netfilter: ip_tables: remove useless variable assignment in get_info()

Value assigned to variable _ret_ at line 970 is overwritten either at line 986 or 988, before it can be used. This makes such variable assignment useless. Addresses-Coverity-ID: 1226932 Signed-off-by: Gustavo A. R. Silva --- net/ipv4/netfilter/ip_tables.c | 2 +- 1 file

[PATCH 2/4] misc: sram-exec: Use aligned fncpy instead of memcpy

From: Dave Gerlach Currently the sram-exec functionality, which allows allocation of executable memory and provides an API to move code to it, is only selected in configs for the ARM architecture. Based on commit 5756e9dd0de6 ("ARM: 6640/1: Thumb-2: Symbol manipulation macros

[PATCH v2 4/4] soc bcm: brcmstb: Add support for S2/S3/S5 suspend states (MIPS)

From: Justin Chen This commit adds support for the Broadcom STB S2/S3/S5 suspend states on MIPS based SoCs. This requires quite a lot of code in order to deal with the different HW blocks that need to be quiesced during suspend: - DDR PHY - DDR memory controller and

[PATCH] netfilter: ip_tables: remove useless variable assignment in get_info()

Value assigned to variable _ret_ at line 970 is overwritten either at line 986 or 988, before it can be used. This makes such variable assignment useless. Addresses-Coverity-ID: 1226932 Signed-off-by: Gustavo A. R. Silva --- net/ipv4/netfilter/ip_tables.c | 2 +- 1 file changed, 1 insertion(+),

[PATCH 2/4] misc: sram-exec: Use aligned fncpy instead of memcpy

From: Dave Gerlach Currently the sram-exec functionality, which allows allocation of executable memory and provides an API to move code to it, is only selected in configs for the ARM architecture. Based on commit 5756e9dd0de6 ("ARM: 6640/1: Thumb-2: Symbol manipulation macros for function body

[PATCH v2 4/4] soc bcm: brcmstb: Add support for S2/S3/S5 suspend states (MIPS)

From: Justin Chen This commit adds support for the Broadcom STB S2/S3/S5 suspend states on MIPS based SoCs. This requires quite a lot of code in order to deal with the different HW blocks that need to be quiesced during suspend: - DDR PHY - DDR memory controller and arbiter - control processor

[PATCH 1/4] misc: sram: Allow ARM64 to select SRAM_EXEC

Now that ARM64 also has a fncpy() implementation, allow selection SRAM_EXEC for ARM64 as well. Signed-off-by: Florian Fainelli --- drivers/misc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index

[PATCH 1/4] misc: sram: Allow ARM64 to select SRAM_EXEC

Now that ARM64 also has a fncpy() implementation, allow selection SRAM_EXEC for ARM64 as well. Signed-off-by: Florian Fainelli --- drivers/misc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index

[PATCH v2 1/4] dt-bindings: ARM: brcmstb: Update Broadcom STB Power Management binding

Update the Broadcom STB Power Management binding document with new compatible strings for the DDR PHY and memory controller found on newer chips. Signed-off-by: Florian Fainelli --- Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt | 6 +- 1 file changed, 5

[PATCH 4/4] rtc: brcmstb-waketimer: Add Broadcom STB wake-timer

From: Brian Norris This adds support for the Broadcom STB wake-timer which is a timer in the chip's 27Mhz clock domain that offers the ability to wake the system (wake-up source) from suspend states (S2, S3, S5). It is supported using the rtc framework allowing us to

[PATCH 4/4] rtc: brcmstb-waketimer: Add Broadcom STB wake-timer

From: Brian Norris This adds support for the Broadcom STB wake-timer which is a timer in the chip's 27Mhz clock domain that offers the ability to wake the system (wake-up source) from suspend states (S2, S3, S5). It is supported using the rtc framework allowing us to configure alarms for system

[PATCH v2 1/4] dt-bindings: ARM: brcmstb: Update Broadcom STB Power Management binding

Update the Broadcom STB Power Management binding document with new compatible strings for the DDR PHY and memory controller found on newer chips. Signed-off-by: Florian Fainelli --- Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt | 6 +- 1 file changed, 5 insertions(+), 1

[PATCH v2 0/4] Broadcom STB S2/S3/S5 support for ARM and MIPS

Hi, This patch series adds support for S2/S3/S5 suspend/resume states on ARM and MIPS based Broadcom STB SoCs. This was submitted a long time ago by Brian, and I am now picking this up and trying to get this included with support for our latest chips. Provided that I can collect the necessary

[PATCH v2 0/4] Broadcom STB S2/S3/S5 support for ARM and MIPS

Hi, This patch series adds support for S2/S3/S5 suspend/resume states on ARM and MIPS based Broadcom STB SoCs. This was submitted a long time ago by Brian, and I am now picking this up and trying to get this included with support for our latest chips. Provided that I can collect the necessary

Re: [PATCH 00/20] LightNVM: pblk patches for 4.13

On Mon, Jun 26 2017, Javier González wrote: > Hi Matias, > > Here you have the pblk patchset for this window. > > Apart from small fixes for LightNVM core and pblk, there are three > relevant changes: > > - Metadata for each line is no longer issued on a separate workqueue, >but instead,

Re: [PATCH 00/20] LightNVM: pblk patches for 4.13

On Mon, Jun 26 2017, Javier González wrote: > Hi Matias, > > Here you have the pblk patchset for this window. > > Apart from small fixes for LightNVM core and pblk, there are three > relevant changes: > > - Metadata for each line is no longer issued on a separate workqueue, >but instead,

[PATCH] video: fbdev: aty: remove useless variable assignments in aty_var_to_crtc()

Value assigned to variable vdisplay at line 990 is overwritten at line 1039 before it can be used. Also, variable assignment at line 987 is the same as at line 1039. This makes such variable assignments useless. Remove these variable assignments and the code related. Addresses-Covertity-ID:

[PATCH] video: fbdev: aty: remove useless variable assignments in aty_var_to_crtc()

Value assigned to variable vdisplay at line 990 is overwritten at line 1039 before it can be used. Also, variable assignment at line 987 is the same as at line 1039. This makes such variable assignments useless. Remove these variable assignments and the code related. Addresses-Covertity-ID:

Re: [PATCH v2 1/3] crypto: ccp - Use devres interface to allocate PCI/iomap and cleanup

On 06/26/2017 04:17 PM, Tom Lendacky wrote: +const struct ccp_vdata ccpv3_platform = { +.version = CCP_VERSION(3, 0), +.setup = NULL, +.perform = _actions, +.bar = 2, Platform devices don't use BARs so should probably delete this (unless you want to make it more generic and

Re: [PATCH v2 1/3] crypto: ccp - Use devres interface to allocate PCI/iomap and cleanup

On 06/26/2017 04:17 PM, Tom Lendacky wrote: +const struct ccp_vdata ccpv3_platform = { +.version = CCP_VERSION(3, 0), +.setup = NULL, +.perform = _actions, +.bar = 2, Platform devices don't use BARs so should probably delete this (unless you want to make it more generic and

[PATCH] sh/ftrace: Remove only user of ftrace_arch_read_dyn_info()

I noticed that there's only one user of ftrace_arch_read_dyn_info(). That was used a while ago during the NMI updating in x86, and superh copied it to implement its version of handling NMIs during stop_machine(). But that is a debug feature, and this code hasn't been touched since 2009. Also,

[PATCH] sh/ftrace: Remove only user of ftrace_arch_read_dyn_info()

I noticed that there's only one user of ftrace_arch_read_dyn_info(). That was used a while ago during the NMI updating in x86, and superh copied it to implement its version of handling NMIs during stop_machine(). But that is a debug feature, and this code hasn't been touched since 2009. Also,

[PATCH] kthread: Atomically set completion and perform dequeue in __kthread_parkme

kthread_park waits for the target kthread to park itself with __kthread_parkme using a completion variable. __kthread_parkme - which is invoked by the target kthread - sets the completion variable before calling schedule() to voluntarily get itself off of the runqueue. This causes an interesting

[PATCH] kthread: Atomically set completion and perform dequeue in __kthread_parkme

kthread_park waits for the target kthread to park itself with __kthread_parkme using a completion variable. __kthread_parkme - which is invoked by the target kthread - sets the completion variable before calling schedule() to voluntarily get itself off of the runqueue. This causes an interesting

Re: [PATCH] spi: rockchip: Keep master alive when CS asserted

Hi Jeffy, On Mon, Jun 26, 2017 at 11:10:06AM +0800, Jeffy Chen wrote: > The cros_ec requires CS line to be active after last message. But the CS > would be toggled when powering off/on rockchip spi, which breaks ec xfer. I believe Doug's point was larger than just the CS line. He was guessing

Re: [PATCH] spi: rockchip: Keep master alive when CS asserted

Hi Jeffy, On Mon, Jun 26, 2017 at 11:10:06AM +0800, Jeffy Chen wrote: > The cros_ec requires CS line to be active after last message. But the CS > would be toggled when powering off/on rockchip spi, which breaks ec xfer. I believe Doug's point was larger than just the CS line. He was guessing

Re: clean up and modularize arch dma_mapping interface V2

On 06/26/2017 02:47 AM, Christoph Hellwig wrote: On Sat, Jun 24, 2017 at 10:36:56AM -0500, Benjamin Herrenschmidt wrote: I think we still need to do it. For example we have a bunch new "funky" cases. I have no plan to do away with the selection - I just want a better interface than the

Re: clean up and modularize arch dma_mapping interface V2

On 06/26/2017 02:47 AM, Christoph Hellwig wrote: On Sat, Jun 24, 2017 at 10:36:56AM -0500, Benjamin Herrenschmidt wrote: I think we still need to do it. For example we have a bunch new "funky" cases. I have no plan to do away with the selection - I just want a better interface than the

Re: linux-next: build failure after merge of the akpm tree

Hi Michal, On Mon, 26 Jun 2017 09:13:46 +0200 Michal Hocko wrote: > > On Mon 26-06-17 16:53:43, Stephen Rothwell wrote: > > > > After merging the akpm tree, today's linux-next build (sparc64 defconfig) > > failed like this: > > > > arch/sparc/kernel/mdesc.c: In function

Re: linux-next: build failure after merge of the akpm tree

Hi Michal, On Mon, 26 Jun 2017 09:13:46 +0200 Michal Hocko wrote: > > On Mon 26-06-17 16:53:43, Stephen Rothwell wrote: > > > > After merging the akpm tree, today's linux-next build (sparc64 defconfig) > > failed like this: > > > > arch/sparc/kernel/mdesc.c: In function 'mdesc_kmalloc': > >

Re: [PATCH v2 2/2] rtc: brcmstb-waketimer: Add Broadcom STB wake-timer

On 26/06/2017 at 14:15:03 -0700, Florian Fainelli wrote: > From: Brian Norris > > This adds support for the Broadcom STB wake-timer which is a timer in > the chip's 27Mhz clock domain that offers the ability to wake the system > (wake-up source) from suspend states

Re: [PATCH v2 2/2] rtc: brcmstb-waketimer: Add Broadcom STB wake-timer

On 26/06/2017 at 14:15:03 -0700, Florian Fainelli wrote: > From: Brian Norris > > This adds support for the Broadcom STB wake-timer which is a timer in > the chip's 27Mhz clock domain that offers the ability to wake the system > (wake-up source) from suspend states (S2, S3, S5). It is supported

Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures]

On Sat, Jun 24, 2017 at 06:45:37AM +0200, Greg Kroah-Hartman wrote: > On Sat, Jun 24, 2017 at 02:34:07AM +0200, Luis R. Rodriguez wrote: > > So taking the position that any kselftest script on linux-next or a future > > kernel should never break stable implicate that *any* fix going upstream for >

Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures]

On Sat, Jun 24, 2017 at 06:45:37AM +0200, Greg Kroah-Hartman wrote: > On Sat, Jun 24, 2017 at 02:34:07AM +0200, Luis R. Rodriguez wrote: > > So taking the position that any kselftest script on linux-next or a future > > kernel should never break stable implicate that *any* fix going upstream for >

Re: [PATCH] firmware: wake all waiters

On Fri, Jun 23, 2017 at 4:37 PM, Jakub Kicinski wrote: > - swake_up(_st->wq); > + swake_up_all(_st->wq); Why is that code using the braindamaed "swait" model in the first place? That's the real problem here - swait() is a very

Re: [PATCH] firmware: wake all waiters

On Fri, Jun 23, 2017 at 4:37 PM, Jakub Kicinski wrote: > - swake_up(_st->wq); > + swake_up_all(_st->wq); Why is that code using the braindamaed "swait" model in the first place? That's the real problem here - swait() is a very specialized interface, and it does not

Re: [PATCH 2/2] rtc: brcmstb-waketimer: Add Broadcom STB wake-timer

On 06/26/2017 02:35 PM, Alexandre Belloni wrote: > On 26/06/2017 at 10:15:46 -0700, Florian Fainelli wrote: >>> This is not needed since d68778b80dd7 >> >> Great, I will take that out. >> >> Do you care whether some dev_dbg() prints are left in the driver or >> should I remove those in v2? >> > >

Re: [PATCH 2/2] rtc: brcmstb-waketimer: Add Broadcom STB wake-timer

On 06/26/2017 02:35 PM, Alexandre Belloni wrote: > On 26/06/2017 at 10:15:46 -0700, Florian Fainelli wrote: >>> This is not needed since d68778b80dd7 >> >> Great, I will take that out. >> >> Do you care whether some dev_dbg() prints are left in the driver or >> should I remove those in v2? >> > >

Re: [PATCH v3 0/4] kmod: help make deterministic

+++ Kees Cook [20/06/17 17:23 -0700]: On Tue, Jun 20, 2017 at 1:56 PM, Luis R. Rodriguez wrote: On Fri, May 26, 2017 at 02:12:24PM -0700, Luis R. Rodriguez wrote: This v3 nukes the proc sysctl interface in favor for just letting userspace just check kernel revision. Prior

Re: [PATCH v3 0/4] kmod: help make deterministic

+++ Kees Cook [20/06/17 17:23 -0700]: On Tue, Jun 20, 2017 at 1:56 PM, Luis R. Rodriguez wrote: On Fri, May 26, 2017 at 02:12:24PM -0700, Luis R. Rodriguez wrote: This v3 nukes the proc sysctl interface in favor for just letting userspace just check kernel revision. Prior to whenever this is

<    1   2   3   4   5   6   7   8   9   10   >