[PATCH v3 6/8] coccicheck: add support for requring a coccinelle version

Enable Coccinelle SmPL patches to require a specific version of Coccinelle. In the event that the version does not match we just inform the user, if the user asked to go through all SmPL patches we just inform them of the need for a new version of coccinelle for the SmPL patch and continue on with

[PATCH v3 5/8] scripts: add Linux .cocciconfig for coccinelle

Help Coccinelle when used against Linux with a set of sensible defaults options for Linux. This hints to coccinelle git can be used for 'git grep' queries over coccigrep. A timeout of 200 seconds should suffice for now. If you use idutils you can override for 'make coccicheck' by using the

[PATCH v3 3/8] coccicheck: enable parmap support

Coccinelle has had parmap support since 1.0.2, this means it supports --jobs, enabling built-in multithreaded functionality, instead of needing one to script it out. Just look for --jobs in the help output to determine if this is supported. Also enable the load balancing to be dynamic, so that if

[PATCH v3 4/8] coccicheck: replace --very-quiet with --quit when debugging

When debugging (using --profile or --show-trying) you want to avoid supressing output, use --quiet instead. While at it, extend documentation for SPFLAGS use. For instance one can use: $ export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci $ make coccicheck DEBUG_FILE="poo.err" MODE=report

[PATCH v3 3/8] coccicheck: enable parmap support

Coccinelle has had parmap support since 1.0.2, this means it supports --jobs, enabling built-in multithreaded functionality, instead of needing one to script it out. Just look for --jobs in the help output to determine if this is supported. Also enable the load balancing to be dynamic, so that if

[PATCH v3 4/8] coccicheck: replace --very-quiet with --quit when debugging

When debugging (using --profile or --show-trying) you want to avoid supressing output, use --quiet instead. While at it, extend documentation for SPFLAGS use. For instance one can use: $ export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci $ make coccicheck DEBUG_FILE="poo.err" MODE=report

[PATCH v3 0/8] coccicheck: modernize

o his tree. This is also rebased on to linux-next next-20160621 These changes are also visible on kernel.org, on a branch based on linux-next next-20160621 with Deepa's commit merged first. [0] http://lkml.kernel.org/r/1466116292-21843-1-git-send-email-mcg...@kernel.org [1] https://git.kernel.org/cgit/li

[PATCH v3 0/8] coccicheck: modernize

o his tree. This is also rebased on to linux-next next-20160621 These changes are also visible on kernel.org, on a branch based on linux-next next-20160621 with Deepa's commit merged first. [0] http://lkml.kernel.org/r/1466116292-21843-1-git-send-email-mcg...@kernel.org [1] https://git.kernel.org/cgit/li

[PATCH v3 2/8] coccicheck: make SPFLAGS more useful

SPFLAGS is set early, it means that any heuristics done on coccicheck cannot be overridden currently. Move SPFLAGS after OPTIONS and set this at the end. This lets you override any heuristics as coccinelle treats conflicts by only listening to the last option that makes sense. Signed-off-by: Luis

[PATCH v3 1/8] coccicheck: move spatch binary check up

This has no functional changes. This is being done to enable us to later use spatch binary for some flag checking for certain features early on. Signed-off-by: Luis R. Rodriguez --- scripts/coccicheck | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff

[PATCH v3 1/8] coccicheck: move spatch binary check up

This has no functional changes. This is being done to enable us to later use spatch binary for some flag checking for certain features early on. Signed-off-by: Luis R. Rodriguez --- scripts/coccicheck | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git

[PATCH v3 2/8] coccicheck: make SPFLAGS more useful

SPFLAGS is set early, it means that any heuristics done on coccicheck cannot be overridden currently. Move SPFLAGS after OPTIONS and set this at the end. This lets you override any heuristics as coccinelle treats conflicts by only listening to the last option that makes sense. Signed-off-by: Luis

Re: [PATCH] static_key: fix concurrent static_key_slow_inc

On Tue, Jun 21, 2016 at 06:52:17PM +0200, Paolo Bonzini wrote: > The following scenario is possible: > > CPU 1 CPU 2 > static_key_slow_inc > atomic_inc_not_zero > -> key.enabled == 0, no increment > jump_label_lock > atomic_inc_return

Re: [PATCH] static_key: fix concurrent static_key_slow_inc

On Tue, Jun 21, 2016 at 06:52:17PM +0200, Paolo Bonzini wrote: > The following scenario is possible: > > CPU 1 CPU 2 > static_key_slow_inc > atomic_inc_not_zero > -> key.enabled == 0, no increment > jump_label_lock > atomic_inc_return

Re: [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback

On Tue, Jun 21, 2016 at 11:49 AM, Stephan Mueller wrote: > Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz: > > Hi John, > >> I don't see in the above an explanation of *why* you're using >> ktime_get_raw_ns() instead of ktime_get_ns(). > > Could you help me

Re: [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback

On Tue, Jun 21, 2016 at 11:49 AM, Stephan Mueller wrote: > Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz: > > Hi John, > >> I don't see in the above an explanation of *why* you're using >> ktime_get_raw_ns() instead of ktime_get_ns(). > > Could you help me understand what the

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 08:50:48PM +0200, Peter Zijlstra wrote: > I've no idea; I use this thing: > > git://git.infradead.org/users/segher/buildall.git > > Although I've got some local modifications, none are to the actual > toolchain building part (although I suppose I should send segher a >

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 08:50:48PM +0200, Peter Zijlstra wrote: > I've no idea; I use this thing: > > git://git.infradead.org/users/segher/buildall.git > > Although I've got some local modifications, none are to the actual > toolchain building part (although I suppose I should send segher a >

Re: [RFC] regmap: Add regmap_pipe_read API

On Thu, Jun 16, 2016 at 06:24:36PM +0300, Crestez Dan Leonard wrote: > + val = ((u8*)val) + read_len; This cast looks broken, you should be able to do pointer arithmetic on void pointers as though they were char *. signature.asc Description: PGP signature

Re: [RFC] regmap: Add regmap_pipe_read API

On Thu, Jun 16, 2016 at 06:24:36PM +0300, Crestez Dan Leonard wrote: > + val = ((u8*)val) + read_len; This cast looks broken, you should be able to do pointer arithmetic on void pointers as though they were char *. signature.asc Description: PGP signature

[PATCH v2 2/2] netfilter/nflog: nflog-range does not truncate packets (userspace)

netfilter/nflog: nflog-range does not truncate packets The option --nflog-range has never worked, but we cannot just fix this because users might be using this feature option and their behavior would change. Instead add a new option --nflog-size. This option works the same way nflog-range should

[PATCH v2 2/2] netfilter/nflog: nflog-range does not truncate packets (userspace)

netfilter/nflog: nflog-range does not truncate packets The option --nflog-range has never worked, but we cannot just fix this because users might be using this feature option and their behavior would change. Instead add a new option --nflog-size. This option works the same way nflog-range should

Re: the usage of __SYSCALL_MASK in entry_SYSCALL_64/do_syscall_64 is not consistent

On Mon, Jun 20, 2016 at 10:53 AM, Oleg Nesterov wrote: > On 06/19, Andy Lutomirski wrote: >> >> Something's clearly buggy there, > > The usage of __X32_SYSCALL_BIT doesn't look right too. Nothing serious > but still. > > Damn, initially I thought I have found the serious bug in

Re: the usage of __SYSCALL_MASK in entry_SYSCALL_64/do_syscall_64 is not consistent

On Mon, Jun 20, 2016 at 10:53 AM, Oleg Nesterov wrote: > On 06/19, Andy Lutomirski wrote: >> >> Something's clearly buggy there, > > The usage of __X32_SYSCALL_BIT doesn't look right too. Nothing serious > but still. > > Damn, initially I thought I have found the serious bug in entry_64.S > and

[PATCH v2 1/2] netfilter/nflog: nflog-range does not truncate packets

netfilter/nflog: nflog-range does not truncate packets li->u.ulog.copy_len is currently ignored by the kernel, we should truncate the packet to either li->u.ulog.copy_len (if set) or copy_range before sending it to userspace. 0 is a valid input for copy_len, so add a new flag to indicate whether

[PATCH v2 1/2] netfilter/nflog: nflog-range does not truncate packets

netfilter/nflog: nflog-range does not truncate packets li->u.ulog.copy_len is currently ignored by the kernel, we should truncate the packet to either li->u.ulog.copy_len (if set) or copy_range before sending it to userspace. 0 is a valid input for copy_len, so add a new flag to indicate whether

Re: [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback

Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz: Hi John, > I don't see in the above an explanation of *why* you're using > ktime_get_raw_ns() instead of ktime_get_ns(). Could you help me understand what the difference is or point me to some documentation? I understood that we only

Re: [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback

Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz: Hi John, > I don't see in the above an explanation of *why* you're using > ktime_get_raw_ns() instead of ktime_get_ns(). Could you help me understand what the difference is or point me to some documentation? I understood that we only

Re: [PATCH cgroup/for-4.8] cgroup: allow NULL return from ss->css_alloc()

Hello, On Tue, Jun 21, 2016 at 02:14:04PM -0400, Johannes Weiner wrote: > Would it be better to remove the error code instead and have everybody > return NULL? AFAICS, everybody is returning either the object or the > -ENOMEM error code right now. > > What error condition is there for an

Re: [PATCH cgroup/for-4.8] cgroup: allow NULL return from ss->css_alloc()

Hello, On Tue, Jun 21, 2016 at 02:14:04PM -0400, Johannes Weiner wrote: > Would it be better to remove the error code instead and have everybody > return NULL? AFAICS, everybody is returning either the object or the > -ENOMEM error code right now. > > What error condition is there for an

[PATCH] cgroup: Use lld instead of ld when printing pids controller events_limit

The `events_limit` variable needs to be formatted with %lld and not %ld. This fixes the following warning discovered by kbuild test robot: kernel/cgroup_pids.c: In function 'pids_events_show': kernel/cgroup_pids.c:313:24: warning: format '%ld' expects argument of type 'long int', but

[PATCH] cgroup: Use lld instead of ld when printing pids controller events_limit

The `events_limit` variable needs to be formatted with %lld and not %ld. This fixes the following warning discovered by kbuild test robot: kernel/cgroup_pids.c: In function 'pids_events_show': kernel/cgroup_pids.c:313:24: warning: format '%ld' expects argument of type 'long int', but

Re: [PATCH v3] gpio: add Intel WhiskeyCove GPIO driver

On Tue, Jun 21, 2016 at 02:19:57AM +0300, Andy Shevchenko wrote: > My comments below. Thanks for your review. > > +config GPIO_WHISKEY_COVE > > + tristate "GPIO support for Whiskey Cove PMIC" > > + depends on INTEL_SOC_PMIC > > + select GPIOLIB_IRQCHIP > > + help > > +

Re: [PATCH v3] gpio: add Intel WhiskeyCove GPIO driver

On Tue, Jun 21, 2016 at 02:19:57AM +0300, Andy Shevchenko wrote: > My comments below. Thanks for your review. > > +config GPIO_WHISKEY_COVE > > + tristate "GPIO support for Whiskey Cove PMIC" > > + depends on INTEL_SOC_PMIC > > + select GPIOLIB_IRQCHIP > > + help > > +

Applied "ASoC: dwc: make pcm support built-in when necessary" to the asoc tree

The patch ASoC: dwc: make pcm support built-in when necessary has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "ASoC: dwc: make pcm support built-in when necessary" to the asoc tree

The patch ASoC: dwc: make pcm support built-in when necessary has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "ASoC: max9860: fix non static symbol warnings" to the asoc tree

The patch ASoC: max9860: fix non static symbol warnings has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

Applied "ASoC: cs53l30: Fix non static symbol warnings" to the asoc tree

The patch ASoC: cs53l30: Fix non static symbol warnings has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

Applied "ASoC: max9860: fix non static symbol warnings" to the asoc tree

The patch ASoC: max9860: fix non static symbol warnings has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

Applied "ASoC: cs53l30: Fix non static symbol warnings" to the asoc tree

The patch ASoC: cs53l30: Fix non static symbol warnings has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

Applied "spi: imx: wait_for_completion_timeout(..) for PIO transfers" to the spi tree

The patch spi: imx: wait_for_completion_timeout(..) for PIO transfers has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "regulator: lp873x: Drop _nlr parameter from LP873X_REGULATOR()" to the regulator tree

The patch regulator: lp873x: Drop _nlr parameter from LP873X_REGULATOR() has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "spi: imx: wait_for_completion_timeout(..) for PIO transfers" to the spi tree

The patch spi: imx: wait_for_completion_timeout(..) for PIO transfers has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "regulator: lp873x: Drop _nlr parameter from LP873X_REGULATOR()" to the regulator tree

The patch regulator: lp873x: Drop _nlr parameter from LP873X_REGULATOR() has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "ASoC: cs53l30: Set idle_bias_off true" to the asoc tree

The patch ASoC: cs53l30: Set idle_bias_off true has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Applied "ASoC: cs53l30: Set idle_bias_off true" to the asoc tree

The patch ASoC: cs53l30: Set idle_bias_off true has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Re: [PATCH] torture: use ktime_t consistently

On Mon, Jun 20, 2016 at 09:29:56PM +0200, Arnd Bergmann wrote: > On Monday, June 20, 2016 11:37:57 AM CEST Paul E. McKenney wrote: > > On Mon, Jun 20, 2016 at 08:29:48PM +0200, Arnd Bergmann wrote: > > > On Monday, June 20, 2016 11:21:05 AM CEST Paul E. McKenney wrote: > > > > On Mon, Jun 20, 2016

Re: [PATCH] torture: use ktime_t consistently

On Mon, Jun 20, 2016 at 09:29:56PM +0200, Arnd Bergmann wrote: > On Monday, June 20, 2016 11:37:57 AM CEST Paul E. McKenney wrote: > > On Mon, Jun 20, 2016 at 08:29:48PM +0200, Arnd Bergmann wrote: > > > On Monday, June 20, 2016 11:21:05 AM CEST Paul E. McKenney wrote: > > > > On Mon, Jun 20, 2016

Re: [patch V2 05/20] driver/net/ethernet/tile: Initialize timer as pinned

On Fri, Jun 17, 2016 at 01:26:32PM -, Thomas Gleixner wrote: > @@ -1004,7 +1004,7 @@ static void tile_net_register(void *dev_ > BUG(); > > /* Initialize the egress timer. */ > - init_timer(>egress_timer); > + init_pinned_timer(>egress_timer); init_timer_pinned()

Re: [patch V2 05/20] driver/net/ethernet/tile: Initialize timer as pinned

On Fri, Jun 17, 2016 at 01:26:32PM -, Thomas Gleixner wrote: > @@ -1004,7 +1004,7 @@ static void tile_net_register(void *dev_ > BUG(); > > /* Initialize the egress timer. */ > - init_timer(>egress_timer); > + init_pinned_timer(>egress_timer); init_timer_pinned()

Re: [PATCH v4 0/4] Introduce the latent_entropy gcc plugin

On Mon, Jun 20, 2016 at 11:39 AM, Emese Revfy wrote: > I would like to introduce the latent_entropy gcc plugin. This plugin > mitigates the problem of the kernel having too little entropy during and > after boot for generating crypto keys. > > This plugin mixes random values

Re: [PATCH v4 0/4] Introduce the latent_entropy gcc plugin

On Mon, Jun 20, 2016 at 11:39 AM, Emese Revfy wrote: > I would like to introduce the latent_entropy gcc plugin. This plugin > mitigates the problem of the kernel having too little entropy during and > after boot for generating crypto keys. > > This plugin mixes random values into the

[PATCH] coresight: document binding acronyms

It can be hard for people not familiar with the CoreSight IP blocks to make sense of the acronyms found in the current bindings. As such this patch expands each acronym in the hope of providing a better description of the IP block they represent. Signed-off-by: Mathieu Poirier

[PATCH] coresight: document binding acronyms

It can be hard for people not familiar with the CoreSight IP blocks to make sense of the acronyms found in the current bindings. As such this patch expands each acronym in the hope of providing a better description of the IP block they represent. Signed-off-by: Mathieu Poirier ---

Re: [PATCH v5 0/7] /dev/random - a new approach

Am Dienstag, 21. Juni 2016, 14:22:48 schrieb Austin S. Hemmelgarn: Hi Austin, > On 2016-06-21 12:28, Stephan Mueller wrote: > > Am Dienstag, 21. Juni 2016, 12:03:56 schrieb Austin S. Hemmelgarn: > > > > Hi Austin, > > > >> On 2016-06-21 03:32, Stephan Mueller wrote: > >>> Am Dienstag, 21. Juni

Re: [PATCH v5 0/7] /dev/random - a new approach

Am Dienstag, 21. Juni 2016, 14:22:48 schrieb Austin S. Hemmelgarn: Hi Austin, > On 2016-06-21 12:28, Stephan Mueller wrote: > > Am Dienstag, 21. Juni 2016, 12:03:56 schrieb Austin S. Hemmelgarn: > > > > Hi Austin, > > > >> On 2016-06-21 03:32, Stephan Mueller wrote: > >>> Am Dienstag, 21. Juni

[PATCH v02 5/5] not required, used to test ctxsw, do not merge

DO NOT MERGE. Provided only to verify bug fix. Change kernel and perf tool to activate tracking and context switch for kernel branches. Signed-off-by: David Carrillo-Cisneros --- arch/x86/events/intel/lbr.c | 3 ++- tools/perf/util/evsel.c | 17 ++--- 2

[PATCH v02 5/5] not required, used to test ctxsw, do not merge

DO NOT MERGE. Provided only to verify bug fix. Change kernel and perf tool to activate tracking and context switch for kernel branches. Signed-off-by: David Carrillo-Cisneros --- arch/x86/events/intel/lbr.c | 3 ++- tools/perf/util/evsel.c | 17 ++--- 2 files changed, 16

[PATCH v02 4/5] perf/x86/intel: MSR_LAST_BRANCH_FROM_x quirk for ctx switch

Add quirk for context switch to save/restore the value of MSR_LAST_BRANCH_FROM_x when LBR is enabled and there is potential for kernel addresses to be in the lbr_from register. To test this patch, use a perf tool and kernel with the patch next in this series. That patch removes the work around

[PATCH v02 4/5] perf/x86/intel: MSR_LAST_BRANCH_FROM_x quirk for ctx switch

Add quirk for context switch to save/restore the value of MSR_LAST_BRANCH_FROM_x when LBR is enabled and there is potential for kernel addresses to be in the lbr_from register. To test this patch, use a perf tool and kernel with the patch next in this series. That patch removes the work around

[PATCH v02 3/5] perf/x86/intel: trivial format and style fix

Replace spaces by tabs in LBR_FROM_* constants to align with newly defined constant. Use BIT_ULL. Signed-off-by: David Carrillo-Cisneros Reviewed-by: Stephane Eranian --- arch/x86/events/intel/lbr.c | 6 +++--- 1 file changed, 3 insertions(+), 3

[PATCH v02 3/5] perf/x86/intel: trivial format and style fix

Replace spaces by tabs in LBR_FROM_* constants to align with newly defined constant. Use BIT_ULL. Signed-off-by: David Carrillo-Cisneros Reviewed-by: Stephane Eranian --- arch/x86/events/intel/lbr.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH v02 1/5] perf/x86/intel: output LBR support statement after validation

commit 338b522ca43c ("perf/x86/intel: Protect LBR and extra_regs against KVM lying") added an additional test to LBR support detection that is performed after printing the LBR support statement to dmesg. Move the LBR support output after the very last test. Signed-off-by: David

[PATCH v02 1/5] perf/x86/intel: output LBR support statement after validation

commit 338b522ca43c ("perf/x86/intel: Protect LBR and extra_regs against KVM lying") added an additional test to LBR support detection that is performed after printing the LBR support statement to dmesg. Move the LBR support output after the very last test. Signed-off-by: David

Re: [kernel-hardening] Re: [PATCH v3 06/13] fork: Add generic vmalloced stack support

On Tue, 2016-06-21 at 10:13 -0700, Kees Cook wrote: > On Tue, Jun 21, 2016 at 9:59 AM, Andy Lutomirski > wrote: > >  > > I'm tempted to explicitly disallow VM_NO_GUARD in the vmalloc > > range. > > It has no in-tree users for non-fixed addresses right now. > What about the

Re: [kernel-hardening] Re: [PATCH v3 06/13] fork: Add generic vmalloced stack support

On Tue, 2016-06-21 at 10:13 -0700, Kees Cook wrote: > On Tue, Jun 21, 2016 at 9:59 AM, Andy Lutomirski > wrote: > >  > > I'm tempted to explicitly disallow VM_NO_GUARD in the vmalloc > > range. > > It has no in-tree users for non-fixed addresses right now. > What about the lack of pre-range guard

Re: linux-next: Tree for Jun 21

On 6/21/2016 2:28 PM, Peter Zijlstra wrote: On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote: >OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I >can build me a kernel with it. The below, much larger than desired, patch seems to make it go again. I had to

Re: [PATCH v2] pwm: improve args checking in pwm_apply_state()

Hi Geert, On Tue, Jun 21, 2016 at 04:42:04PM +0200, Geert Uytterhoeven wrote: > On Fri, May 27, 2016 at 6:45 PM, Brian Norris > wrote: > > It seems like in the process of refactoring pwm_config() to utilize the > > newly-introduced pwm_apply_state() API, some

Re: linux-next: Tree for Jun 21

On 6/21/2016 2:28 PM, Peter Zijlstra wrote: On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote: >OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I >can build me a kernel with it. The below, much larger than desired, patch seems to make it go again. I had to

Re: [PATCH v2] pwm: improve args checking in pwm_apply_state()

Hi Geert, On Tue, Jun 21, 2016 at 04:42:04PM +0200, Geert Uytterhoeven wrote: > On Fri, May 27, 2016 at 6:45 PM, Brian Norris > wrote: > > It seems like in the process of refactoring pwm_config() to utilize the > > newly-introduced pwm_apply_state() API, some args/bounds checking was > >

[PATCH v02 0/5] fix MSR_LAST_BRANCH_FROM Haswell support

commit 338b522ca43c ("perf/x86/intel: Protect LBR and extra_regs against KVM lying") introduced an extra test for LBR support but did not move the dmesg accordingly. This problem is fixed in first patch in this series. When a machine that used LBR is rebooted using kexec, the extra test for LBR

[PATCH v02 2/5] perf/x86/intel: fix for MSR_LAST_BRANCH_FROM_x bug when no TSX

Intel's SDM states that bits 61:62 in MSR_LAST_BRANCH_FROM_x are the TSX flags for formats with LBR_TSX flags (i.e. LBR_FORMAT_EIP_EFLAGS2). However, when the CPU has TSX support deactivated, bits 61:62 actually behave as follows: - For wrmsr, bits 61:62 are considered part of the sign

[PATCH v02 0/5] fix MSR_LAST_BRANCH_FROM Haswell support

commit 338b522ca43c ("perf/x86/intel: Protect LBR and extra_regs against KVM lying") introduced an extra test for LBR support but did not move the dmesg accordingly. This problem is fixed in first patch in this series. When a machine that used LBR is rebooted using kexec, the extra test for LBR

[PATCH v02 2/5] perf/x86/intel: fix for MSR_LAST_BRANCH_FROM_x bug when no TSX

Intel's SDM states that bits 61:62 in MSR_LAST_BRANCH_FROM_x are the TSX flags for formats with LBR_TSX flags (i.e. LBR_FORMAT_EIP_EFLAGS2). However, when the CPU has TSX support deactivated, bits 61:62 actually behave as follows: - For wrmsr, bits 61:62 are considered part of the sign

Re: [PATCH 10/10] perf script: Add stackcollapse.py script

On Mon, Jun 20, 2016 at 3:23 PM, Arnaldo Carvalho de Melo wrote: > From: Paolo Bonzini > > Add stackcollapse.py script as an example of parsing call chains, and > also of using optparse to access command line options. > > The flame graph tools include a set

RE: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

> -Original Message- > From: Pali Rohár [mailto:pali.ro...@gmail.com] > Sent: Tuesday, June 21, 2016 1:29 PM > To: Limonciello, Mario > Cc: dvh...@infradead.org; gabriele@gmail.com; l...@kernel.org; > alex.h...@canonical.com; mj...@srcf.ucam.org;

Re: [PATCH 10/10] perf script: Add stackcollapse.py script

On Mon, Jun 20, 2016 at 3:23 PM, Arnaldo Carvalho de Melo wrote: > From: Paolo Bonzini > > Add stackcollapse.py script as an example of parsing call chains, and > also of using optparse to access command line options. > > The flame graph tools include a set of scripts that parse output from >

RE: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

> -Original Message- > From: Pali Rohár [mailto:pali.ro...@gmail.com] > Sent: Tuesday, June 21, 2016 1:29 PM > To: Limonciello, Mario > Cc: dvh...@infradead.org; gabriele@gmail.com; l...@kernel.org; > alex.h...@canonical.com; mj...@srcf.ucam.org; ker...@kempniu.pl; >

Re: [PATCH v3] cgroup: Add pids controller event when fork fails because of pid limit

Thanks for the feedback Tejun! On 6/21/16, 1:12 PM, "Tejun Heo" wrote: >Hello, > >Just a couple nits. > >On Tue, Jun 21, 2016 at 09:56:38AM -0700, Kenny Yu wrote: >> Summary: > >No need for "Summary:" tag. > >> This patch adds more visibility into

Re: [PATCH v3] cgroup: Add pids controller event when fork fails because of pid limit

Thanks for the feedback Tejun! On 6/21/16, 1:12 PM, "Tejun Heo" wrote: >Hello, > >Just a couple nits. > >On Tue, Jun 21, 2016 at 09:56:38AM -0700, Kenny Yu wrote: >> Summary: > >No need for "Summary:" tag. > >> This patch adds more visibility into the pids controller when the controller >>

[PATCH v4] cgroup: Add pids controller event when fork fails because of pid limit

This patch adds more visibility into the pids controller when the controller rejects a fork request. Whenever fork fails because the limit on the number of pids in the cgroup is reached, the controller will log this and also notify the newly added cgroups events file. The `max` key in the events

[PATCH v4] cgroup: Add pids controller event when fork fails because of pid limit

This patch adds more visibility into the pids controller when the controller rejects a fork request. Whenever fork fails because the limit on the number of pids in the cgroup is reached, the controller will log this and also notify the newly added cgroups events file. The `max` key in the events

Re: [PATCH v2 00/15] clk: sunxi: introduce "modern" clock support

On Tue, 21 Jun 2016 16:47:52 +0200 Maxime Ripard wrote: > > But I had some problems with some features as the 'mode select' in the > > A83T MMC2 clock. > > Also, I think that you did not go far enough in the changes. > > At some point, you also have to support

Re: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

On Tuesday 21 June 2016 20:16:09 mario_limoncie...@dell.com wrote: > > -Original Message- > > From: Darren Hart [mailto:dvh...@infradead.org] > > Sent: Tuesday, June 21, 2016 1:06 PM > > To: Pali Rohár > > Cc: Gabriele Mazzotta ; Andy

Re: [PATCH v2 00/15] clk: sunxi: introduce "modern" clock support

On Tue, 21 Jun 2016 16:47:52 +0200 Maxime Ripard wrote: > > But I had some problems with some features as the 'mode select' in the > > A83T MMC2 clock. > > Also, I think that you did not go far enough in the changes. > > At some point, you also have to support what's used out there, > otherwise

Re: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

On Tuesday 21 June 2016 20:16:09 mario_limoncie...@dell.com wrote: > > -Original Message- > > From: Darren Hart [mailto:dvh...@infradead.org] > > Sent: Tuesday, June 21, 2016 1:06 PM > > To: Pali Rohár > > Cc: Gabriele Mazzotta ; Andy Lutomirski > > ; Alex Hung ; Matthew > > Garrett ;

[PATCH v4 4/4] drm/i915: Enable polling when we don't have hpd

Unfortunately, there's two situations where we lose hpd right now: - Runtime suspend - When we've shut off all of the power wells on Valleyview/Cherryview While it would be nice if this didn't cause issues, this has the ability to get us in some awkward states where a user won't be able to get

Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices

On Tue, Jun 21 2016 at 11:44am -0400, Kani, Toshimitsu wrote: > On Tue, 2016-06-21 at 09:41 -0400, Mike Snitzer wrote: > > On Mon, Jun 20 2016 at  6:22pm -0400, > > Mike Snitzer wrote: > > > > > > On Mon, Jun 20 2016 at  5:28pm -0400, > > > Kani,

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote: > OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I > can build me a kernel with it. The below, much larger than desired, patch seems to make it go again. I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a

[PATCH v4 4/4] drm/i915: Enable polling when we don't have hpd

Unfortunately, there's two situations where we lose hpd right now: - Runtime suspend - When we've shut off all of the power wells on Valleyview/Cherryview While it would be nice if this didn't cause issues, this has the ability to get us in some awkward states where a user won't be able to get

Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices

On Tue, Jun 21 2016 at 11:44am -0400, Kani, Toshimitsu wrote: > On Tue, 2016-06-21 at 09:41 -0400, Mike Snitzer wrote: > > On Mon, Jun 20 2016 at  6:22pm -0400, > > Mike Snitzer wrote: > > > > > > On Mon, Jun 20 2016 at  5:28pm -0400, > > > Kani, Toshimitsu wrote: > > > >  : > > > Looks

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote: > OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I > can build me a kernel with it. The below, much larger than desired, patch seems to make it go again. I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a

Re: sound: use-after-free in hrtimer_cancel

On Mon, Jun 6, 2016 at 4:11 PM, Takashi Iwai wrote: > On Sat, 04 Jun 2016 20:27:50 +0200, > Dmitry Vyukov wrote: >> >> On Sat, Jun 4, 2016 at 8:00 PM, Dmitry Vyukov wrote: >> > Hello, >> > >> > The following program triggers use-after-free: >> >> Forget to

Re: sound: use-after-free in hrtimer_cancel

On Mon, Jun 6, 2016 at 4:11 PM, Takashi Iwai wrote: > On Sat, 04 Jun 2016 20:27:50 +0200, > Dmitry Vyukov wrote: >> >> On Sat, Jun 4, 2016 at 8:00 PM, Dmitry Vyukov wrote: >> > Hello, >> > >> > The following program triggers use-after-free: >> >> Forget to mention that you need to run it in a

RE: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Tuesday, June 21, 2016 1:06 PM > To: Pali Rohár > Cc: Gabriele Mazzotta ; Andy Lutomirski > ; Alex Hung ; Matthew >

RE: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Tuesday, June 21, 2016 1:06 PM > To: Pali Rohár > Cc: Gabriele Mazzotta ; Andy Lutomirski > ; Alex Hung ; Matthew > Garrett ; Michał Kępień ; > Limonciello, Mario ; platform-driver- > x...@vger.kernel.org;

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-21 09:19, Tomas Mraz wrote: On Út, 2016-06-21 at 09:05 -0400, Austin S. Hemmelgarn wrote: On 2016-06-20 14:32, Stephan Mueller wrote: [1] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf Specific things I notice about this: 1. QEMU systems are reporting higher values than

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-21 09:19, Tomas Mraz wrote: On Út, 2016-06-21 at 09:05 -0400, Austin S. Hemmelgarn wrote: On 2016-06-20 14:32, Stephan Mueller wrote: [1] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf Specific things I notice about this: 1. QEMU systems are reporting higher values than

Re: [PATCH v3] cgroup: Add pids controller event when fork fails because of pid limit

Hello, On Tue, Jun 21, 2016 at 05:23:40PM +, Kenny Yu wrote: > >It'd be better to use atomic64_inc_and_test() instead. > > > > if (err) { > > if (atomic64_inc_and_test()) { > > pr_xxx...; > > } > > cgroup_file_notify(>events_file); >

Re: [PATCH v3] cgroup: Add pids controller event when fork fails because of pid limit

Hello, On Tue, Jun 21, 2016 at 05:23:40PM +, Kenny Yu wrote: > >It'd be better to use atomic64_inc_and_test() instead. > > > > if (err) { > > if (atomic64_inc_and_test()) { > > pr_xxx...; > > } > > cgroup_file_notify(>events_file); >

<    3   4   5   6   7   8   9   10   11   12   >