Re: [PATCH] lib: make sg_pool explicitly non-modular

On Wed, 2016-04-20 at 15:13 -0400, Paul Gortmaker wrote: > The recently added Kconfig controlling compilation of this code is: > > lib/Kconfig:config SG_POOL > lib/Kconfig:def_bool n > > ...meaning that it currently is not being built as a module by anyone. > > Lets remove the modular code

Re: [PATCH] lib: make sg_pool explicitly non-modular

On Wed, 2016-04-20 at 15:13 -0400, Paul Gortmaker wrote: > The recently added Kconfig controlling compilation of this code is: > > lib/Kconfig:config SG_POOL > lib/Kconfig:def_bool n > > ...meaning that it currently is not being built as a module by anyone. > > Lets remove the modular code

[GIT PULL 1/2] bcm2835 DT changes for 4.7

Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: https://github.com/anholt/linux tags/bcm2835-dt-next-2016-04-20 for you to fetch changes up to 896ad420db8d5ec4cc4727b786d15e28eb59b366: dt/bindings: bcm2835: correct description for DMA-int (2016-04-19

[GIT PULL 1/2] bcm2835 DT changes for 4.7

Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: https://github.com/anholt/linux tags/bcm2835-dt-next-2016-04-20 for you to fetch changes up to 896ad420db8d5ec4cc4727b786d15e28eb59b366: dt/bindings: bcm2835: correct description for DMA-int (2016-04-19

[GIT PULL 2/2] bcm2835 defconfig changes for 4.7

Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: https://github.com/anholt/linux tags/bcm2835-defconfig-next-2016-04-20 for you to fetch changes up to 3652bb35abf6ee11333cbec1d2855c1c0f9f6b27: ARM: bcm2835: Enable NFS root support. (2016-04-04 11:03:30

[RFC 0/3] net: dsa: cross-chip operations

This patchset aims to start a thread on cross-chips operations in DSA, no need to spend time on reviewing the details of the code (especially for mv88e6xxx). So when several switch chips are interconnected, we need to configure them all to ensure correct hardware switching. We can think about

[GIT PULL 2/2] bcm2835 defconfig changes for 4.7

Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: https://github.com/anholt/linux tags/bcm2835-defconfig-next-2016-04-20 for you to fetch changes up to 3652bb35abf6ee11333cbec1d2855c1c0f9f6b27: ARM: bcm2835: Enable NFS root support. (2016-04-04 11:03:30

[RFC 0/3] net: dsa: cross-chip operations

This patchset aims to start a thread on cross-chips operations in DSA, no need to spend time on reviewing the details of the code (especially for mv88e6xxx). So when several switch chips are interconnected, we need to configure them all to ensure correct hardware switching. We can think about

[RFC 3/3] net: dsa: mv88e6xxx: setup PVT

Instead of allowing any external frame to egress any internal port, configure the Cross-chip Port VLAN Table (PVT) to forbid that. When an external source port joins or leaves a bridge crossing this switch, mask it in the PVT to allow or forbid frames to egress. Add support for the cross-chip

[RFC 2/3] net: dsa: mv88e6xxx: initialize PVT

Expand the Cross-chip Port Based VLAN Table initilization code, and make sure the "5 Bit Port" bit is cleared. This commit doesn't make any functional change to the current code. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx.c | 48

[RFC 1/3] net: dsa: add cross-chip notification for bridge

When multiple switch chips are chained together, one needs to know about the bridge membership of others. For instance, switches like Marvell 6352 have cross-chip port-based VLAN table to allow or forbid cross-chip frames to egress. Add a cross_chip_bridge DSA driver function, used to notify a

[RFC 3/3] net: dsa: mv88e6xxx: setup PVT

Instead of allowing any external frame to egress any internal port, configure the Cross-chip Port VLAN Table (PVT) to forbid that. When an external source port joins or leaves a bridge crossing this switch, mask it in the PVT to allow or forbid frames to egress. Add support for the cross-chip

[RFC 2/3] net: dsa: mv88e6xxx: initialize PVT

Expand the Cross-chip Port Based VLAN Table initilization code, and make sure the "5 Bit Port" bit is cleared. This commit doesn't make any functional change to the current code. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx.c | 48 -

[RFC 1/3] net: dsa: add cross-chip notification for bridge

When multiple switch chips are chained together, one needs to know about the bridge membership of others. For instance, switches like Marvell 6352 have cross-chip port-based VLAN table to allow or forbid cross-chip frames to egress. Add a cross_chip_bridge DSA driver function, used to notify a

Re: [PATCH v4 0/2] Skylake PSys support

On Wed, Apr 20, 2016 at 8:28 PM, Srinivas Pandruvada wrote: > On Wed, 2016-04-20 at 15:59 +0200, Peter Zijlstra wrote: >> On Sun, Apr 17, 2016 at 03:02:59PM -0700, Srinivas Pandruvada wrote: >> > >> > Skylake processor supports a new set of RAPL registers for

Re: [PATCH v4 0/2] Skylake PSys support

On Wed, Apr 20, 2016 at 8:28 PM, Srinivas Pandruvada wrote: > On Wed, 2016-04-20 at 15:59 +0200, Peter Zijlstra wrote: >> On Sun, Apr 17, 2016 at 03:02:59PM -0700, Srinivas Pandruvada wrote: >> > >> > Skylake processor supports a new set of RAPL registers for >> > controlling >> > entire SoC

Re: [PATCH v2 2/2] asus-laptop: correct error handling in sysfs_acpi_set

On Sat, Apr 16, 2016 at 03:01:57AM +0300, Giedrius Statkevičius wrote: > Properly return rv back to the caller in the case of an error in > parse_arg. In the process remove a unused variable 'out'. The initial problem if I recall was value being uninitialized. Is that correct? > >

Re: [PATCH v2 2/2] asus-laptop: correct error handling in sysfs_acpi_set

On Sat, Apr 16, 2016 at 03:01:57AM +0300, Giedrius Statkevičius wrote: > Properly return rv back to the caller in the case of an error in > parse_arg. In the process remove a unused variable 'out'. The initial problem if I recall was value being uninitialized. Is that correct? > >

Re: [PATCH -tip v3 3/3] locking/pvqspinlock: Robustify init_qspinlock_stat()

On 04/20/2016 12:17 AM, Davidlohr Bueso wrote: locking/pvqspinlock: Robustify init_qspinlock_stat() Specifically around the debugfs file creation calls, I have no idea if they could ever possibly fail, but this is core code (debug aside) so lets at least check the return value and inform

Re: [PATCH -tip v3 3/3] locking/pvqspinlock: Robustify init_qspinlock_stat()

On 04/20/2016 12:17 AM, Davidlohr Bueso wrote: locking/pvqspinlock: Robustify init_qspinlock_stat() Specifically around the debugfs file creation calls, I have no idea if they could ever possibly fail, but this is core code (debug aside) so lets at least check the return value and inform

[PATCH v3] MCS spinlock: Use smp_cond_load_acquire() in spin loop

This patch applies on top of: git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git locking/rfc --- For qspinlocks on ARM64, we would like to use WFE instead of purely spinning. Qspinlocks internally have lock contenders spin on an MCS lock. Update arch_mcs_spin_lock_contended() such

[PATCH v3] MCS spinlock: Use smp_cond_load_acquire() in spin loop

This patch applies on top of: git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git locking/rfc --- For qspinlocks on ARM64, we would like to use WFE instead of purely spinning. Qspinlocks internally have lock contenders spin on an MCS lock. Update arch_mcs_spin_lock_contended() such

stable-security kernel updates

Hi all, Updates for stable-security kernels have been released: - v3.12.58-security - v3.14.67-security - v3.18.31-security - v4.1.22-security - v4.4.8-security - v4.5.2-security They are available at:

stable-security kernel updates

Hi all, Updates for stable-security kernels have been released: - v3.12.58-security - v3.14.67-security - v3.18.31-security - v4.1.22-security - v4.4.8-security - v4.5.2-security They are available at:

[PATCH 02/14] mm, compaction: change COMPACT_ constants into enum

From: Michal Hocko compaction code is doing weird dances between COMPACT_FOO -> int -> unsigned long but there doesn't seem to be any reason for that. All functions which return/use one of those constants are not expecting any other value so it really makes sense to define an

[PATCH 02/14] mm, compaction: change COMPACT_ constants into enum

From: Michal Hocko compaction code is doing weird dances between COMPACT_FOO -> int -> unsigned long but there doesn't seem to be any reason for that. All functions which return/use one of those constants are not expecting any other value so it really makes sense to define an enum for them and

[PATCH 07/14] mm, compaction: Simplify __alloc_pages_direct_compact feedback interface

From: Michal Hocko __alloc_pages_direct_compact communicates potential back off by two variables: - deferred_compaction tells that the compaction returned COMPACT_DEFERRED - contended_compaction is set when there is a contention on zone->lock

[PATCH 07/14] mm, compaction: Simplify __alloc_pages_direct_compact feedback interface

From: Michal Hocko __alloc_pages_direct_compact communicates potential back off by two variables: - deferred_compaction tells that the compaction returned COMPACT_DEFERRED - contended_compaction is set when there is a contention on zone->lock resp.

[PATCH 04/14] mm, compaction: distinguish COMPACT_DEFERRED from COMPACT_SKIPPED

From: Michal Hocko try_to_compact_pages can currently return COMPACT_SKIPPED even when the compaction is defered for some zone just because zone DMA is skipped in 99% of cases due to watermark checks. This makes COMPACT_DEFERRED basically unusable for the page allocator as a

[PATCH 04/14] mm, compaction: distinguish COMPACT_DEFERRED from COMPACT_SKIPPED

From: Michal Hocko try_to_compact_pages can currently return COMPACT_SKIPPED even when the compaction is defered for some zone just because zone DMA is skipped in 99% of cases due to watermark checks. This makes COMPACT_DEFERRED basically unusable for the page allocator as a feedback mechanism.

[PATCH 14/14] mm, oom, compaction: prevent from should_compact_retry looping for ever for costly orders

From: Michal Hocko "mm: consider compaction feedback also for costly allocation" has removed the upper bound for the reclaim/compaction retries based on the number of reclaimed pages for costly orders. While this is desirable the patch did miss a mis interaction between reclaim,

[PATCH 10/14] mm, oom: rework oom detection

From: Michal Hocko __alloc_pages_slowpath has traditionally relied on the direct reclaim and did_some_progress as an indicator that it makes sense to retry allocation rather than declaring OOM. shrink_zones had to rely on zone_reclaimable if shrink_zone didn't make any progress

[PATCH 14/14] mm, oom, compaction: prevent from should_compact_retry looping for ever for costly orders

From: Michal Hocko "mm: consider compaction feedback also for costly allocation" has removed the upper bound for the reclaim/compaction retries based on the number of reclaimed pages for costly orders. While this is desirable the patch did miss a mis interaction between reclaim, compaction and

[PATCH 10/14] mm, oom: rework oom detection

From: Michal Hocko __alloc_pages_slowpath has traditionally relied on the direct reclaim and did_some_progress as an indicator that it makes sense to retry allocation rather than declaring OOM. shrink_zones had to rely on zone_reclaimable if shrink_zone didn't make any progress to prevent from a

[PATCH 12/14] mm, oom: protect !costly allocations some more

From: Michal Hocko should_reclaim_retry will give up retries for higher order allocations if none of the eligible zones has any requested or higher order pages available even if we pass the watermak check for order-0. This is done because there is no guarantee that the

[PATCH 12/14] mm, oom: protect !costly allocations some more

From: Michal Hocko should_reclaim_retry will give up retries for higher order allocations if none of the eligible zones has any requested or higher order pages available even if we pass the watermak check for order-0. This is done because there is no guarantee that the reclaimable and currently

[PATCH 13/14] mm: consider compaction feedback also for costly allocation

From: Michal Hocko PAGE_ALLOC_COSTLY_ORDER retry logic is mostly handled inside should_reclaim_retry currently where we decide to not retry after at least order worth of pages were reclaimed or the watermark check for at least one zone would succeed after reclaiming all pages if

[PATCH 09/14] mm: use compaction feedback for thp backoff conditions

From: Michal Hocko THP requests skip the direct reclaim if the compaction is either deferred or contended to reduce stalls which wouldn't help the allocation success anyway. These checks are ignoring other potential feedback modes which we have available now. It clearly doesn't

[PATCH 13/14] mm: consider compaction feedback also for costly allocation

From: Michal Hocko PAGE_ALLOC_COSTLY_ORDER retry logic is mostly handled inside should_reclaim_retry currently where we decide to not retry after at least order worth of pages were reclaimed or the watermark check for at least one zone would succeed after reclaiming all pages if the reclaim

[PATCH 09/14] mm: use compaction feedback for thp backoff conditions

From: Michal Hocko THP requests skip the direct reclaim if the compaction is either deferred or contended to reduce stalls which wouldn't help the allocation success anyway. These checks are ignoring other potential feedback modes which we have available now. It clearly doesn't make much sense

[PATCH 11/14] mm: throttle on IO only when there are too many dirty and writeback pages

From: Michal Hocko wait_iff_congested has been used to throttle allocator before it retried another round of direct reclaim to allow the writeback to make some progress and prevent reclaim from looping over dirty/writeback pages without making any progress. We used to do

[PATCH 11/14] mm: throttle on IO only when there are too many dirty and writeback pages

From: Michal Hocko wait_iff_congested has been used to throttle allocator before it retried another round of direct reclaim to allow the writeback to make some progress and prevent reclaim from looping over dirty/writeback pages without making any progress. We used to do congestion_wait before

[PATCH 06/14] mm, compaction: Update compaction_result ordering

From: Michal Hocko compaction_result will be used as the primary feedback channel for compaction users. At the same time try_to_compact_pages (and potentially others) assume a certain ordering where a more specific feedback takes precendence. This gets a bit awkward when we have

[PATCH 01/14] vmscan: consider classzone_idx in compaction_ready

From: Michal Hocko while playing with the oom detection rework [1] I have noticed that my heavy order-9 (hugetlb) load close to OOM ended up in an endless loop where the reclaim hasn't made any progress but did_some_progress didn't reflect that and compaction_suitable was

[PATCH 01/14] vmscan: consider classzone_idx in compaction_ready

From: Michal Hocko while playing with the oom detection rework [1] I have noticed that my heavy order-9 (hugetlb) load close to OOM ended up in an endless loop where the reclaim hasn't made any progress but did_some_progress didn't reflect that and compaction_suitable was backing off because no

[PATCH 06/14] mm, compaction: Update compaction_result ordering

From: Michal Hocko compaction_result will be used as the primary feedback channel for compaction users. At the same time try_to_compact_pages (and potentially others) assume a certain ordering where a more specific feedback takes precendence. This gets a bit awkward when we have conflicting

[PATCH 03/14] mm, compaction: cover all compaction mode in compact_zone

From: Michal Hocko the compiler is complaining after "mm, compaction: change COMPACT_ constants into enum" mm/compaction.c: In function ‘compact_zone’: mm/compaction.c:1350:2: warning: enumeration value ‘COMPACT_DEFERRED’ not handled in switch [-Wswitch] switch (ret) { ^

[PATCH 0.14] oom detection rework v6

Hi, This is v6 of the series. The previous version was posted [1]. The code hasn't changed much since then. I have found one old standing bug (patch 1) which just got much more severe and visible with this series. Other than that I have reorganized the series and put the compaction feedback

[PATCH 08/14] mm, compaction: Abstract compaction feedback to helpers

From: Michal Hocko Compaction can provide a wild variation of feedback to the caller. Many of them are implementation specific and the caller of the compaction (especially the page allocator) shouldn't be bound to specifics of the current implementation. This patch abstracts

[PATCH 05/14] mm, compaction: distinguish between full and partial COMPACT_COMPLETE

From: Michal Hocko COMPACT_COMPLETE now means that compaction and free scanner met. This is not very useful information if somebody just wants to use this feedback and make any decisions based on that. The current caller might be a poor guy who just happened to scan tiny portion

[PATCH 03/14] mm, compaction: cover all compaction mode in compact_zone

From: Michal Hocko the compiler is complaining after "mm, compaction: change COMPACT_ constants into enum" mm/compaction.c: In function ‘compact_zone’: mm/compaction.c:1350:2: warning: enumeration value ‘COMPACT_DEFERRED’ not handled in switch [-Wswitch] switch (ret) { ^

[PATCH 0.14] oom detection rework v6

Hi, This is v6 of the series. The previous version was posted [1]. The code hasn't changed much since then. I have found one old standing bug (patch 1) which just got much more severe and visible with this series. Other than that I have reorganized the series and put the compaction feedback

[PATCH 08/14] mm, compaction: Abstract compaction feedback to helpers

From: Michal Hocko Compaction can provide a wild variation of feedback to the caller. Many of them are implementation specific and the caller of the compaction (especially the page allocator) shouldn't be bound to specifics of the current implementation. This patch abstracts the feedback into

[PATCH 05/14] mm, compaction: distinguish between full and partial COMPACT_COMPLETE

From: Michal Hocko COMPACT_COMPLETE now means that compaction and free scanner met. This is not very useful information if somebody just wants to use this feedback and make any decisions based on that. The current caller might be a poor guy who just happened to scan tiny portion of the zone and

Re: [PATCH] char: Drop bogus dependency of DEVPORT on !M68K

On 04/11/2016 02:40 AM, Geert Uytterhoeven wrote: > According to full-history-linux commit d3794f4fa7c3edc3 ("[PATCH] M68k > update (part 25)"), port operations are allowed on m68k if CONFIG_ISA is > defined. > > However, commit 153dcc54df826d2f ("[PATCH] mem driver: fix conditional > on isa i/o

Re: [PATCH] char: Drop bogus dependency of DEVPORT on !M68K

On 04/11/2016 02:40 AM, Geert Uytterhoeven wrote: > According to full-history-linux commit d3794f4fa7c3edc3 ("[PATCH] M68k > update (part 25)"), port operations are allowed on m68k if CONFIG_ISA is > defined. > > However, commit 153dcc54df826d2f ("[PATCH] mem driver: fix conditional > on isa i/o

Re: [PATCH 1/2] kernfs_path_from_node_locked: don't overwrite nlen

On Sun, Apr 17, 2016 at 03:04:31PM -0500, serge.hal...@ubuntu.com wrote: > From: Serge Hallyn > > We've calculated @len to be the bytes we need for '/..' entries from > @kn_from to the common ancestor, and calculated @nlen to be the extra > bytes we need to get from the

Re: [PATCH 1/2] kernfs_path_from_node_locked: don't overwrite nlen

On Sun, Apr 17, 2016 at 03:04:31PM -0500, serge.hal...@ubuntu.com wrote: > From: Serge Hallyn > > We've calculated @len to be the bytes we need for '/..' entries from > @kn_from to the common ancestor, and calculated @nlen to be the extra > bytes we need to get from the common ancestor to

Re: [PATCH v2] ARM: dts: imx6: Add dts for Embest MarS Board

Hi Fabio, On 19-04-2016 08:34, Fabio Estevam wrote: On Mon, Apr 11, 2016 at 9:25 PM, Sergio Prado wrote: + { + pinctrl-names = "default"; + pinctrl-0 = <_enet>; + phy-mode = "rgmii"; + phy-reset-gpios = < 31 GPIO_ACTIVE_HIGH>; Are you

Re: [PATCH v2] ARM: dts: imx6: Add dts for Embest MarS Board

Hi Fabio, On 19-04-2016 08:34, Fabio Estevam wrote: On Mon, Apr 11, 2016 at 9:25 PM, Sergio Prado wrote: + { + pinctrl-names = "default"; + pinctrl-0 = <_enet>; + phy-mode = "rgmii"; + phy-reset-gpios = < 31 GPIO_ACTIVE_HIGH>; Are you sure this is really active

[for-next][PATCH 03/30] tracing: Add infrastructure to allow set_event_pid to follow children

From: Steven Rostedt Add the infrastructure needed to have the PIDs in set_event_pid to automatically add PIDs of the children of the tasks that have their PIDs in set_event_pid. This will also remove PIDs from set_event_pid when a task exits This is implemented by adding

[for-next][PATCH 00/30] tracing: Add features for event-fork and histograms

git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git for-next Head SHA1: d50c744ecde7ee3ba4d7ffb0e1c55e7a2f6bbc8e Masami Hiramatsu (3): kselftests/ftrace : Add event trigger testcases kselftests/ftrace: Add hist trigger testcases kselftests/ftrace: Add a

[for-next][PATCH 03/30] tracing: Add infrastructure to allow set_event_pid to follow children

From: Steven Rostedt Add the infrastructure needed to have the PIDs in set_event_pid to automatically add PIDs of the children of the tasks that have their PIDs in set_event_pid. This will also remove PIDs from set_event_pid when a task exits This is implemented by adding hooks into the fork

[for-next][PATCH 00/30] tracing: Add features for event-fork and histograms

git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git for-next Head SHA1: d50c744ecde7ee3ba4d7ffb0e1c55e7a2f6bbc8e Masami Hiramatsu (3): kselftests/ftrace : Add event trigger testcases kselftests/ftrace: Add hist trigger testcases kselftests/ftrace: Add a

[for-next][PATCH 10/30] tracing: Add hist trigger support for compound keys

From: Tom Zanussi Allow users to specify multiple trace event fields to use in keys by allowing multiple fields in the 'keys=' keyword. With this addition, any unique combination of any of the fields named in the 'keys' keyword will result in a new entry being added

Re: [RFC] arm64: Implement WFE based spin wait for MCS spinlocks

On Wed, 2016-04-20 at 12:30 +0200, Peter Zijlstra wrote: > On Thu, Apr 14, 2016 at 12:13:38AM -0700, Jason Low wrote: > > Use WFE to avoid most spinning with MCS spinlocks. This is implemented > > with the new cmpwait() mechanism for comparing and waiting for the MCS > > locked value to change

[for-next][PATCH 01/30] tracing: Rename check_ignore_pid() to ignore_this_task()

From: Steven Rostedt The name "check_ignore_pid" is confusing in trying to figure out if the pid should be ignored or not. Rename it to "ignore_this_task" which is pretty straight forward, as a task (not a pid) is passed in, and should if true should be ignored.

[for-next][PATCH 04/30] tracing: Update the documentation to describe "event-fork" option

From: "Steven Rostedt (Red Hat)" Add documentation to the ftrace.txt file in Documentation to describe the event-fork option. Also add the missing "display-graph" option now that it shows up in the trace_options file (from a previous commit). Signed-off-by: Steven Rostedt

[for-next][PATCH 09/30] tracing: Add hist trigger support for multiple values (vals= param)

From: Tom Zanussi Allow users to specify trace event fields to use in aggregated sums via a new 'vals=' keyword. Before this addition, the only aggregated sum supported was the implied value 'hitcount'. With this addition, 'hitcount' is also supported as an

[for-next][PATCH 10/30] tracing: Add hist trigger support for compound keys

From: Tom Zanussi Allow users to specify multiple trace event fields to use in keys by allowing multiple fields in the 'keys=' keyword. With this addition, any unique combination of any of the fields named in the 'keys' keyword will result in a new entry being added to the hash table. Link:

Re: [RFC] arm64: Implement WFE based spin wait for MCS spinlocks

On Wed, 2016-04-20 at 12:30 +0200, Peter Zijlstra wrote: > On Thu, Apr 14, 2016 at 12:13:38AM -0700, Jason Low wrote: > > Use WFE to avoid most spinning with MCS spinlocks. This is implemented > > with the new cmpwait() mechanism for comparing and waiting for the MCS > > locked value to change

[for-next][PATCH 01/30] tracing: Rename check_ignore_pid() to ignore_this_task()

From: Steven Rostedt The name "check_ignore_pid" is confusing in trying to figure out if the pid should be ignored or not. Rename it to "ignore_this_task" which is pretty straight forward, as a task (not a pid) is passed in, and should if true should be ignored. Signed-off-by: Steven Rostedt

[for-next][PATCH 04/30] tracing: Update the documentation to describe "event-fork" option

From: "Steven Rostedt (Red Hat)" Add documentation to the ftrace.txt file in Documentation to describe the event-fork option. Also add the missing "display-graph" option now that it shows up in the trace_options file (from a previous commit). Signed-off-by: Steven Rostedt ---

[for-next][PATCH 09/30] tracing: Add hist trigger support for multiple values (vals= param)

From: Tom Zanussi Allow users to specify trace event fields to use in aggregated sums via a new 'vals=' keyword. Before this addition, the only aggregated sum supported was the implied value 'hitcount'. With this addition, 'hitcount' is also supported as an explicit value field, as is any

[for-next][PATCH 02/30] tracing: Use pid bitmap instead of a pid array for set_event_pid

From: Steven Rostedt In order to add the ability to let tasks that are filtered by the events have their children also be traced on fork (and then not traced on exit), convert the array into a pid bitmask. Most of the time the number of pids is only 32768 pids or a 4k

[for-next][PATCH 02/30] tracing: Use pid bitmap instead of a pid array for set_event_pid

From: Steven Rostedt In order to add the ability to let tasks that are filtered by the events have their children also be traced on fork (and then not traced on exit), convert the array into a pid bitmask. Most of the time the number of pids is only 32768 pids or a 4k bitmask, which is the same

[for-next][PATCH 06/30] tracing: Fix TRACING_MAP Kconfig

From: "Steven Rostedt (Red Hat)" The config option for TRACING_MAP has "default n", which is not needed because the default of configs is 'n'. Also, since the TRACING_MAP has no config prompt, there's no reason to include "If in doubt, say N" in the help text. Fixed a typo

[for-next][PATCH 18/30] tracing: Add hist trigger support for stacktraces as keys

From: Tom Zanussi It's often useful to be able to use a stacktrace as a hash key, for keeping a count of the number of times a particular call path resulted in a trace event, for instance. Add a special key named 'stacktrace' which can be used as key in a 'keys='

[for-next][PATCH 06/30] tracing: Fix TRACING_MAP Kconfig

From: "Steven Rostedt (Red Hat)" The config option for TRACING_MAP has "default n", which is not needed because the default of configs is 'n'. Also, since the TRACING_MAP has no config prompt, there's no reason to include "If in doubt, say N" in the help text. Fixed a typo in the comments of

[for-next][PATCH 18/30] tracing: Add hist trigger support for stacktraces as keys

From: Tom Zanussi It's often useful to be able to use a stacktrace as a hash key, for keeping a count of the number of times a particular call path resulted in a trace event, for instance. Add a special key named 'stacktrace' which can be used as key in a 'keys=' param for this purpose: #

[for-next][PATCH 20/30] tracing: Remove restriction on string position in hist trigger keys

From: Tom Zanussi If we assume the maximum size for a string field, we don't have to worry about its position. Since we only allow two keys in a compound key and having more than one string key in a given compound key doesn't make much sense anyway, trading a bit of

[for-next][PATCH 20/30] tracing: Remove restriction on string position in hist trigger keys

From: Tom Zanussi If we assume the maximum size for a string field, we don't have to worry about its position. Since we only allow two keys in a compound key and having more than one string key in a given compound key doesn't make much sense anyway, trading a bit of extra space instead of

[for-next][PATCH 24/30] tracing: Add support for named triggers

From: Tom Zanussi Named triggers are sets of triggers that share a common set of trigger data. An example of functionality that could benefit from this type of capability would be a set of inlined probes that would each contribute event counts, for example, to a

[for-next][PATCH 24/30] tracing: Add support for named triggers

From: Tom Zanussi Named triggers are sets of triggers that share a common set of trigger data. An example of functionality that could benefit from this type of capability would be a set of inlined probes that would each contribute event counts, for example, to a shared counter data structure.

[for-next][PATCH 29/30] kselftests/ftrace: Add a test for log2 modifier of hist trigger

From: Masami Hiramatsu Add a test for log2 modifier of hist trigger in hist_mod.tc. Here is the test result. # ./ftracetest test.d/trigger/trigger-hist-mod.tc === Ftrace unit tests === [1] event trigger - test histogram modifiers [PASS] # of

[for-next][PATCH 29/30] kselftests/ftrace: Add a test for log2 modifier of hist trigger

From: Masami Hiramatsu Add a test for log2 modifier of hist trigger in hist_mod.tc. Here is the test result. # ./ftracetest test.d/trigger/trigger-hist-mod.tc === Ftrace unit tests === [1] event trigger - test histogram modifiers [PASS] # of passed: 1 # of failed: 0 # of

[for-next][PATCH 26/30] kselftests/ftrace : Add event trigger testcases

From: Masami Hiramatsu This adds simple event trigger testcases for ftracetest, which covers following triggers. - traceon-traceoff trigger - enable/disable_event trigger - snapshot trigger - stacktrace trigger - trigger filters Here is the test result.

[for-next][PATCH 19/30] tracing: Support string type key properly

From: Namhyung Kim The string in a trace event is usually recorded as dynamic array which is variable length. But current hist code only support fixed length array so it cannot support most strings. This patch fixes it by checking filter_type of the field and get proper

[for-next][PATCH 19/30] tracing: Support string type key properly

From: Namhyung Kim The string in a trace event is usually recorded as dynamic array which is variable length. But current hist code only support fixed length array so it cannot support most strings. This patch fixes it by checking filter_type of the field and get proper pointer with it. With

[for-next][PATCH 26/30] kselftests/ftrace : Add event trigger testcases

From: Masami Hiramatsu This adds simple event trigger testcases for ftracetest, which covers following triggers. - traceon-traceoff trigger - enable/disable_event trigger - snapshot trigger - stacktrace trigger - trigger filters Here is the test result. # ./ftracetest

[for-next][PATCH 16/30] tracing: Add hist trigger execname modifier

From: Tom Zanussi Allow users to have common_pid field values displayed as program names in the output by appending '.execname' to a common_pid field name: # echo hist:keys=common_pid.execname ... \ [ if filter] > event/trigger Link:

[for-next][PATCH 16/30] tracing: Add hist trigger execname modifier

From: Tom Zanussi Allow users to have common_pid field values displayed as program names in the output by appending '.execname' to a common_pid field name: # echo hist:keys=common_pid.execname ... \ [ if filter] > event/trigger Link:

[for-next][PATCH 27/30] kselftests/ftrace: Add hist trigger testcases

From: Masami Hiramatsu Add the hist trigger testcases for ftracetest. This checks the basic histogram trigger behaviors like as; - Histogram trigger itself - Histogram with string key - Histogram with compound keys - Histogram with sort key - Histogram

[for-next][PATCH 27/30] kselftests/ftrace: Add hist trigger testcases

From: Masami Hiramatsu Add the hist trigger testcases for ftracetest. This checks the basic histogram trigger behaviors like as; - Histogram trigger itself - Histogram with string key - Histogram with compound keys - Histogram with sort key - Histogram trigger modifiers (execname, hex,

[for-next][PATCH 23/30] tracing: Add support for multiple hist triggers per event

From: Tom Zanussi Allow users to define any number of hist triggers per trace event. Any number of hist triggers may be added for a given event, which may differ by key, value, or filter. Reading the event's 'hist' file will display the output of all the hist

Re: [RFC PATCH 07/13] bpf tools: Load ubpf program

Em Wed, Apr 20, 2016 at 06:01:47PM +, Wang Nan escreveu: > In bpf_program__load(), load ubpf program according to its engine type. > > API is improvemented to hold 'struct ubpf_vm *'. > > Signed-off-by: Wang Nan > Cc: Arnaldo Carvalho de Melo > Cc:

Re: [RFC PATCH 07/13] bpf tools: Load ubpf program

Em Wed, Apr 20, 2016 at 06:01:47PM +, Wang Nan escreveu: > In bpf_program__load(), load ubpf program according to its engine type. > > API is improvemented to hold 'struct ubpf_vm *'. > > Signed-off-by: Wang Nan > Cc: Arnaldo Carvalho de Melo > Cc: Alexei Starovoitov > Cc: Brendan Gregg

[for-next][PATCH 23/30] tracing: Add support for multiple hist triggers per event

From: Tom Zanussi Allow users to define any number of hist triggers per trace event. Any number of hist triggers may be added for a given event, which may differ by key, value, or filter. Reading the event's 'hist' file will display the output of all the hist triggers defined on an event

Re: [PATCH 1/3] staging/android: remove redundant comments on sync_merge_data

I messed up with the subject prefix, but this is v11, adds typecheck() to patch 2. 2016-04-20 Gustavo Padovan : > From: Gustavo Padovan > > struct sync_merge_data already have documentation on top of the > struct definition. No need to

Re: [PATCH 1/3] staging/android: remove redundant comments on sync_merge_data

I messed up with the subject prefix, but this is v11, adds typecheck() to patch 2. 2016-04-20 Gustavo Padovan : > From: Gustavo Padovan > > struct sync_merge_data already have documentation on top of the > struct definition. No need to duplicate it. > > Signed-off-by: Gustavo Padovan >

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