Re: [RFC][PATCH] mutex: Optimize mutex_trylock() fast-path

On Wed, 01 Jun 2016, Peter Zijlstra wrote: A while back Viro posted a number of 'interesting' mutex_is_locked() users on IRC, one of those was RCU. RCU seems to use mutex_is_locked() to avoid doing mutex_trylock(), the regular load before modify pattern. While the use isn't wrong per se, its

Re: [PATCH 2/4] perf stat: Add computation of TopDown formulas

On Thu, Jun 02, 2016 at 06:56:51AM -0500, Nilay Vaish wrote: > Andi, I am talking about the if statement. I don't know why it would > happen that nothing got measured. I am guessing you saw it happen. > May be we can add a comment in the patch that it is possible that all > counter values are

[PATCH] thermal: fix race condition when updating cooling device

When multiple thermal zones are bound to the same cooling device, multiple kernel threads may want to update the cooling device state by calling thermal_cdev_update(). Having cdev not protected by a mutex can lead to a race condition. Consider the following situation with two kernel threads k1 and

[PATCH] thermal: fix race condition when updating cooling device

When multiple thermal zones are bound to the same cooling device, multiple kernel threads may want to update the cooling device state by calling thermal_cdev_update(). Having cdev not protected by a mutex can lead to a race condition. Consider the following situation with two kernel threads k1 and

[PATCH 01/11] ARM: davinci: Sort frequency table

This is required for some of the changes in cpufreq core. There was only one function dependent on the order of the table, that is fixed as well. Cc: Sekhar Nori Cc: Kevin Hilman Signed-off-by: Viresh Kumar ---

[PATCH 01/11] ARM: davinci: Sort frequency table

This is required for some of the changes in cpufreq core. There was only one function dependent on the order of the table, that is fixed as well. Cc: Sekhar Nori Cc: Kevin Hilman Signed-off-by: Viresh Kumar --- arch/arm/mach-davinci/da850.c | 16 +--- 1 file changed, 9

[PATCH 02/11] cpufreq: davinci: Reuse cpufreq_generic_frequency_table_verify()

policy->freq_table will always be valid for this platform, otherwise driver's probe() would fail. And so this routine will *always* return after calling cpufreq_frequency_table_verify(). This can be done using the generic callback provided by core, lets use it instead. Cc: Sekhar Nori

[PATCH 02/11] cpufreq: davinci: Reuse cpufreq_generic_frequency_table_verify()

policy->freq_table will always be valid for this platform, otherwise driver's probe() would fail. And so this routine will *always* return after calling cpufreq_frequency_table_verify(). This can be done using the generic callback provided by core, lets use it instead. Cc: Sekhar Nori

[PATCH 05/11] cpufreq: elanfreq: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH 05/11] cpufreq: elanfreq: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH 03/11] cpufreq: Use policy->freq_table in ->target_index()

The 'policy' already contains a pointer to the freq table, use that instead of using driver specific tables name. This is done in order to make sure that the 'index' passed to the ->target_index() callback is used *only* to index into the policy->freq_table and nothing else. Later patches would

[PATCH 03/11] cpufreq: Use policy->freq_table in ->target_index()

The 'policy' already contains a pointer to the freq table, use that instead of using driver specific tables name. This is done in order to make sure that the 'index' passed to the ->target_index() callback is used *only* to index into the policy->freq_table and nothing else. Later patches would

Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait()

On Thu, Jun 02, 2016 at 01:52:02PM +0200, Peter Zijlstra wrote: [snip] > --- a/arch/powerpc/include/asm/spinlock.h > +++ b/arch/powerpc/include/asm/spinlock.h > @@ -27,6 +27,8 @@ > #include > #include > #include > +#include > +#include > > #ifdef CONFIG_PPC64 > /* use 0x80yy when

[PATCH] drm/exynos: don't use HW trigger for Exynos5420/5422/5800

Commit a6f75aa161c5 ("drm/exynos: fimd: add HW trigger support") added hardware trigger support to the FIMD controller driver. But this broke the display in at least the Exynos5800 Peach Pi Chromebook. So until the issue is fixed, avoid using HW trigger for the Exynos5420 based boards and use SW

[PATCH] drm/exynos: don't use HW trigger for Exynos5420/5422/5800

Commit a6f75aa161c5 ("drm/exynos: fimd: add HW trigger support") added hardware trigger support to the FIMD controller driver. But this broke the display in at least the Exynos5800 Peach Pi Chromebook. So until the issue is fixed, avoid using HW trigger for the Exynos5420 based boards and use SW

Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait()

On Thu, Jun 02, 2016 at 01:52:02PM +0200, Peter Zijlstra wrote: [snip] > --- a/arch/powerpc/include/asm/spinlock.h > +++ b/arch/powerpc/include/asm/spinlock.h > @@ -27,6 +27,8 @@ > #include > #include > #include > +#include > +#include > > #ifdef CONFIG_PPC64 > /* use 0x80yy when

Re: [PATCH 09/16] sched/fair: Let asymmetric cpu configurations balance at wake-up

On Mon, May 23, 2016 at 11:58:51AM +0100, Morten Rasmussen wrote: > Currently, SD_WAKE_AFFINE always takes priority over wakeup balancing if > SD_BALANCE_WAKE is set on the sched_domains. For asymmetric > configurations SD_WAKE_AFFINE is only desirable if the waking task's > compute demand

Re: [PATCH 09/16] sched/fair: Let asymmetric cpu configurations balance at wake-up

On Mon, May 23, 2016 at 11:58:51AM +0100, Morten Rasmussen wrote: > Currently, SD_WAKE_AFFINE always takes priority over wakeup balancing if > SD_BALANCE_WAKE is set on the sched_domains. For asymmetric > configurations SD_WAKE_AFFINE is only desirable if the waking task's > compute demand

[PATCH 08/11] cpufreq: imx: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH 08/11] cpufreq: imx: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH 07/11] cpufreq: ia64: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH 09/11] cpufreq: maple: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH 06/11] cpufreq: exynos: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

Re: [RFC PATCH v1 0/2]

On Wed, Jun 01, 2016 at 10:54:09AM +0800, Yakir Yang wrote: > Hi Daniel, > > On 05/31/2016 10:38 PM, Daniel Vetter wrote: > > On Tue, May 31, 2016 at 09:37:36PM +0800, Yakir Yang wrote: > > > The full name of PSR is Panel Self Refresh, panel device could refresh > > > itself with the hardware

Re: [RFC PATCH v1 0/2]

On Wed, Jun 01, 2016 at 10:54:09AM +0800, Yakir Yang wrote: > Hi Daniel, > > On 05/31/2016 10:38 PM, Daniel Vetter wrote: > > On Tue, May 31, 2016 at 09:37:36PM +0800, Yakir Yang wrote: > > > The full name of PSR is Panel Self Refresh, panel device could refresh > > > itself with the hardware

[PATCH 07/11] cpufreq: ia64: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH 09/11] cpufreq: maple: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH 06/11] cpufreq: exynos: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

Re: [PATCH v2 0/2] KVM: x86: avoid simultaneous queueing of both IRQ and SMI

2016-06-01 22:25+0200, Paolo Bonzini: > This was reported as a vmentry failure while running Windows with SMM > enabled. It's not that rare if your processor lacks APICv---it happens > about 20-30% of the time while installing Windows 10. > > I now understand the interrupt injection code

[PATCH 00/11] cpufreq: Keep policy->freq_table sorted

Hi Rafael, This series fixes all cpufreq drivers that provide a 'target_index' callback or in other words, which provide a freq-table to cpufreq core, to make sure they *only* use the 'index' argument to ->target_index() with the policy->freq_table. This change allows us to remove the

Re: [PATCH v2 0/2] KVM: x86: avoid simultaneous queueing of both IRQ and SMI

2016-06-01 22:25+0200, Paolo Bonzini: > This was reported as a vmentry failure while running Windows with SMM > enabled. It's not that rare if your processor lacks APICv---it happens > about 20-30% of the time while installing Windows 10. > > I now understand the interrupt injection code

[PATCH 00/11] cpufreq: Keep policy->freq_table sorted

Hi Rafael, This series fixes all cpufreq drivers that provide a 'target_index' callback or in other words, which provide a freq-table to cpufreq core, to make sure they *only* use the 'index' argument to ->target_index() with the policy->freq_table. This change allows us to remove the

[PATCH 10/11] cpufreq: Keep a single (sorted) freq_table

Now that all drivers providing ->target_index() callback are updated to use 'index' only for indexing into policy->freq_table, we can safely avoid keeping two separate freq-tables. Which also means that cpufreq core doesn't use the freq_table passed to cpufreq_table_validate_and_show(), once that

Re: [PATCH] coresight: Handle build path error

On 1 June 2016 at 12:04, Suzuki K Poulose wrote: > On 06/05/16 15:43, Mathieu Poirier wrote: >> >> On 6 May 2016 at 08:35, Suzuki K Poulose wrote: >>> >>> Enabling a component via sysfs (echo 1 > enable_source), would >>> trigger building a path

Re: [PATCH] coresight: Handle build path error

On 1 June 2016 at 12:04, Suzuki K Poulose wrote: > On 06/05/16 15:43, Mathieu Poirier wrote: >> >> On 6 May 2016 at 08:35, Suzuki K Poulose wrote: >>> >>> Enabling a component via sysfs (echo 1 > enable_source), would >>> trigger building a path from the enabled sources to the sink. >>> If there

[PATCH 10/11] cpufreq: Keep a single (sorted) freq_table

Now that all drivers providing ->target_index() callback are updated to use 'index' only for indexing into policy->freq_table, we can safely avoid keeping two separate freq-tables. Which also means that cpufreq core doesn't use the freq_table passed to cpufreq_table_validate_and_show(), once that

[PATCH 04/11] cpufreq: blackfin: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH 11/11] cpufreq: drivers: Free frequency tables after being used

The cpufreq core doesn't use these tables anymore after cpufreq_table_validate_and_show() has returned. And so these can be freed early. Signed-off-by: Viresh Kumar --- drivers/cpufreq/acpi-cpufreq.c | 7 +++ drivers/cpufreq/at32ap-cpufreq.c| 6 +++---

[PATCH 11/11] cpufreq: drivers: Free frequency tables after being used

The cpufreq core doesn't use these tables anymore after cpufreq_table_validate_and_show() has returned. And so these can be freed early. Signed-off-by: Viresh Kumar --- drivers/cpufreq/acpi-cpufreq.c | 7 +++ drivers/cpufreq/at32ap-cpufreq.c| 6 +++---

[PATCH 04/11] cpufreq: blackfin: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

Re: [PATCH 1/5] clk: qcom: ipq4019: Modified the fixed clock rate to proper values

The PLLs on IPQ4019 cannot be reconfigured by design. The recommendation is to program these PLLS only once. Since, the Bootloaders configure the PLLs and clocks already. we did not support the recalc rate and marked them as fixed clocks. On 6/2/2016 3:48 AM, Stephen Boyd wrote: This was a

Re: [PATCH 1/5] clk: qcom: ipq4019: Modified the fixed clock rate to proper values

The PLLs on IPQ4019 cannot be reconfigured by design. The recommendation is to program these PLLS only once. Since, the Bootloaders configure the PLLs and clocks already. we did not support the recalc rate and marked them as fixed clocks. On 6/2/2016 3:48 AM, Stephen Boyd wrote: This was a

Re: [PATCH resend v2 1/6] regulator: axp20x: support AXP809 variant

On Thu, Jun 2, 2016 at 9:25 PM, Mark Brown wrote: > On Thu, Jun 02, 2016 at 07:05:22PM +0800, Chen-Yu Tsai wrote: >> On Thu, Jun 2, 2016 at 6:27 PM, Mark Brown wrote: > >> >> The mfd patches this one depended on were pushed around a week before >> >> the

Re: [PATCH resend v2 1/6] regulator: axp20x: support AXP809 variant

On Thu, Jun 2, 2016 at 9:25 PM, Mark Brown wrote: > On Thu, Jun 02, 2016 at 07:05:22PM +0800, Chen-Yu Tsai wrote: >> On Thu, Jun 2, 2016 at 6:27 PM, Mark Brown wrote: > >> >> The mfd patches this one depended on were pushed around a week before >> >> the merge window, about a month after you

Re: [PATCH] security: Use || instead of | for boolean expressions

On Wed, Jun 01, 2016 at 02:03:02PM +0800, Rui Teng wrote: > Sparse spits out the following warning: > security/commoncap.c:989:41: warning: dubious: !x | y > > Bitwise and logical are equivalent here, but logical was intended. > Replacing the bit-wise '|' with the boolean '||' silences the

Re: [PATCH] security: Use || instead of | for boolean expressions

On Wed, Jun 01, 2016 at 02:03:02PM +0800, Rui Teng wrote: > Sparse spits out the following warning: > security/commoncap.c:989:41: warning: dubious: !x | y > > Bitwise and logical are equivalent here, but logical was intended. > Replacing the bit-wise '|' with the boolean '||' silences the

[PATCH 8/8] nilfs2: refactor parser of snapshot mount option

Move parser of snapshot mount option to a separate function nilfs_parse_snapshot_option(), replace simple_strtoull() with kstrtoull() to avoid checkpatch.pl warning "WARNING: simple_strtoull is obsolete, use kstrtoull instead", and refine the error message of the parser. Signed-off-by: Ryusuke

[PATCH 8/8] nilfs2: refactor parser of snapshot mount option

Move parser of snapshot mount option to a separate function nilfs_parse_snapshot_option(), replace simple_strtoull() with kstrtoull() to avoid checkpatch.pl warning "WARNING: simple_strtoull is obsolete, use kstrtoull instead", and refine the error message of the parser. Signed-off-by: Ryusuke

Re: [PATCH 2/2] HID: multitouch: enable the Surface 3 Type Cover to report multitouch data

On May 31 2016 or thereabouts, Andy Shevchenko wrote: > On Tue, 2016-05-31 at 18:07 +0200, Benjamin Tissoires wrote: > > On May 20 2016 or thereabouts, Benjamin Tissoires wrote: > > > On May 13 2016 or thereabouts, Andy Shevchenko wrote: > > > > On Fri, 2016-05-13 at 19:09 +0300, Andy Shevchenko

Re: [PATCH 2/2] HID: multitouch: enable the Surface 3 Type Cover to report multitouch data

On May 31 2016 or thereabouts, Andy Shevchenko wrote: > On Tue, 2016-05-31 at 18:07 +0200, Benjamin Tissoires wrote: > > On May 20 2016 or thereabouts, Benjamin Tissoires wrote: > > > On May 13 2016 or thereabouts, Andy Shevchenko wrote: > > > > On Fri, 2016-05-13 at 19:09 +0300, Andy Shevchenko

[PATCH V2 6/6] cpufreq: Return index from cpufreq_frequency_table_target()

This routine can't fail unless the frequency table is invalid and doesn't contain any valid entries. Make it return the index and WARN() in case it is used for an invalid table. Signed-off-by: Viresh Kumar --- Documentation/cpu-freq/cpu-drivers.txt | 7 +++

[PATCH V2 5/6] cpufreq: Drop 'freq_table' argument of __target_index()

It is already present as part of the policy and so no need to pass it from the caller. Also, 'freq_table' is guaranteed to be valid in this function and so no need to check it. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq.c | 21 +++-- 1 file

[PATCH V2 5/6] cpufreq: Drop 'freq_table' argument of __target_index()

It is already present as part of the policy and so no need to pass it from the caller. Also, 'freq_table' is guaranteed to be valid in this function and so no need to check it. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq.c | 21 +++-- 1 file changed, 7 insertions(+),

[PATCH V2 6/6] cpufreq: Return index from cpufreq_frequency_table_target()

This routine can't fail unless the frequency table is invalid and doesn't contain any valid entries. Make it return the index and WARN() in case it is used for an invalid table. Signed-off-by: Viresh Kumar --- Documentation/cpu-freq/cpu-drivers.txt | 7 +++

[PATCH V2 3/6] cpufreq: ondemand: Don't keep a copy of freq_table pointer

There is absolutely no need to keep a copy to the freq-table in 'struct od_policy_dbs_info'. Use policy->freq_table instead. Signed-off-by: Viresh Kumar --- drivers/cpufreq/amd_freq_sensitivity.c | 7 +++ drivers/cpufreq/cpufreq_ondemand.c | 22

[PATCH V2 4/6] cpufreq: Drop freq-table param to cpufreq_frequency_table_target()

The policy already has this pointer set, use it instead. Signed-off-by: Viresh Kumar --- Documentation/cpu-freq/cpu-drivers.txt | 1 - drivers/cpufreq/amd_freq_sensitivity.c | 3 +-- drivers/cpufreq/cpufreq.c | 4 ++-- drivers/cpufreq/cpufreq_ondemand.c

[PATCH V2 1/6] cpufreq: s3c24xx: Remove useless checks

These aren't required at all, remove them. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Viresh Kumar --- drivers/cpufreq/s3c24xx-cpufreq.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/cpufreq/s3c24xx-cpufreq.c

[PATCH V2 2/6] cpufreq: Remove cpufreq_frequency_get_table()

Most of the callers of cpufreq_frequency_get_table() already have the pointer to a valid 'policy' structure and they don't really need to go through the per-cpu variable first and then a check to validate the frequency, in order to find the freq-table for the policy. Directly use the

[PATCH V2 1/6] cpufreq: s3c24xx: Remove useless checks

These aren't required at all, remove them. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Viresh Kumar --- drivers/cpufreq/s3c24xx-cpufreq.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/cpufreq/s3c24xx-cpufreq.c b/drivers/cpufreq/s3c24xx-cpufreq.c index

[PATCH V2 2/6] cpufreq: Remove cpufreq_frequency_get_table()

Most of the callers of cpufreq_frequency_get_table() already have the pointer to a valid 'policy' structure and they don't really need to go through the per-cpu variable first and then a check to validate the frequency, in order to find the freq-table for the policy. Directly use the

[PATCH V2 3/6] cpufreq: ondemand: Don't keep a copy of freq_table pointer

There is absolutely no need to keep a copy to the freq-table in 'struct od_policy_dbs_info'. Use policy->freq_table instead. Signed-off-by: Viresh Kumar --- drivers/cpufreq/amd_freq_sensitivity.c | 7 +++ drivers/cpufreq/cpufreq_ondemand.c | 22 +++---

[PATCH V2 4/6] cpufreq: Drop freq-table param to cpufreq_frequency_table_target()

The policy already has this pointer set, use it instead. Signed-off-by: Viresh Kumar --- Documentation/cpu-freq/cpu-drivers.txt | 1 - drivers/cpufreq/amd_freq_sensitivity.c | 3 +-- drivers/cpufreq/cpufreq.c | 4 ++-- drivers/cpufreq/cpufreq_ondemand.c | 11 +--

[PATCH V2 0/6] cpufreq: cleanups and reorganization

Hi Rafael, This cleans up cpufreq core and few platform drivers a bit. Its mostly around cleaning up the usage of cpufreq_frequency_table_target(), which will be optimized in a separate series. This is just preparatory cleanup for that. V1->V2: - Dropped one powernv patch which wasn't really

[PATCH 1/8] nilfs2: hide function name argument from nilfs_error()

Simplify nilfs_error(), an output function used to report critical issues in file system. This renames the original nilfs_error() function to __nilfs_error() and redefines it as a macro to hide its function name argument within the macro. Every call site of nilfs_error() is changed to strip

[PATCH V2 0/6] cpufreq: cleanups and reorganization

Hi Rafael, This cleans up cpufreq core and few platform drivers a bit. Its mostly around cleaning up the usage of cpufreq_frequency_table_target(), which will be optimized in a separate series. This is just preparatory cleanup for that. V1->V2: - Dropped one powernv patch which wasn't really

[PATCH 1/8] nilfs2: hide function name argument from nilfs_error()

Simplify nilfs_error(), an output function used to report critical issues in file system. This renames the original nilfs_error() function to __nilfs_error() and redefines it as a macro to hide its function name argument within the macro. Every call site of nilfs_error() is changed to strip

[PATCH 3/8] nilfs2: embed a back pointer to super block instance in nilfs object

Insert a back pointer to super block instance in nilfs object so that functions of nilfs2 easily refer to the super block instance. This simplifies replacement of printk() in the successive change. Signed-off-by: Ryusuke Konishi --- fs/nilfs2/super.c | 2 +-

[PATCH 3/8] nilfs2: embed a back pointer to super block instance in nilfs object

Insert a back pointer to super block instance in nilfs object so that functions of nilfs2 easily refer to the super block instance. This simplifies replacement of printk() in the successive change. Signed-off-by: Ryusuke Konishi --- fs/nilfs2/super.c | 2 +- fs/nilfs2/the_nilfs.c | 7

[PATCH 7/6] mm, oom: task_will_free_mem should skip oom_reaped tasks

From: Michal Hocko 0-day robot has encountered the following: [ 82.694232] Out of memory: Kill process 3914 (trinity-c0) score 167 or sacrifice child [ 82.695110] Killed process 3914 (trinity-c0) total-vm:55864kB, anon-rss:1512kB, file-rss:1088kB, shmem-rss:25616kB [

[PATCH 7/6] mm, oom: task_will_free_mem should skip oom_reaped tasks

From: Michal Hocko 0-day robot has encountered the following: [ 82.694232] Out of memory: Kill process 3914 (trinity-c0) score 167 or sacrifice child [ 82.695110] Killed process 3914 (trinity-c0) total-vm:55864kB, anon-rss:1512kB, file-rss:1088kB, shmem-rss:25616kB [ 82.706724]

[PATCH 0/8] nilfs2 updates

Hi Andrew, Please queue the following changes for the next merge window: Ryusuke Konishi (8): nilfs2: hide function name argument from nilfs_error() nilfs2: add nilfs_msg() message interface nilfs2: embed a back pointer to super block instance in nilfs object nilfs2:

[PATCH 5/8] nilfs2: replace nilfs_warning() with nilfs_msg()

Use nilfs_msg() to output warning messages and get rid of nilfs_warning() function. This also removes function names from the messages unless we embed them explicitly in format strings. Instead, some messages are revised to clarify the context. Signed-off-by: Ryusuke Konishi

[PATCH 5/8] nilfs2: replace nilfs_warning() with nilfs_msg()

Use nilfs_msg() to output warning messages and get rid of nilfs_warning() function. This also removes function names from the messages unless we embed them explicitly in format strings. Instead, some messages are revised to clarify the context. Signed-off-by: Ryusuke Konishi ---

[PATCH 0/8] nilfs2 updates

Hi Andrew, Please queue the following changes for the next merge window: Ryusuke Konishi (8): nilfs2: hide function name argument from nilfs_error() nilfs2: add nilfs_msg() message interface nilfs2: embed a back pointer to super block instance in nilfs object nilfs2:

[PATCH 6/8] nilfs2: emit error message when I/O error is detected

When nilfs returned -EIO as an error code, it's not always clear if it came from the underlying block device or not. This will mend the issue by having low level I/O routines of nilfs output an error message when they detected an I/O error. Signed-off-by: Ryusuke Konishi

[PATCH 6/8] nilfs2: emit error message when I/O error is detected

When nilfs returned -EIO as an error code, it's not always clear if it came from the underlying block device or not. This will mend the issue by having low level I/O routines of nilfs output an error message when they detected an I/O error. Signed-off-by: Ryusuke Konishi --- fs/nilfs2/btree.c

[PATCH 7/8] nilfs2: do not use yield()

Use cond_resched() instead of yield() in the loop of nilfs_transaction_lock() since the usage corresponds to the "be nice for others" case that the comment of yield() says. This removes the following checkpatch.pl warning: "WARNING: Using yield() is generally wrong. See yield() kernel-doc

[PATCH 4/8] nilfs2: reduce bare use of printk() with nilfs_msg()

Replace most use of printk() in nilfs2 implementation with nilfs_msg(), and reduce the following checkpatch.pl warning: "WARNING: Prefer [subsystem eg: netdev]_crit([subsystem]dev, ... then dev_crit(dev, ... then pr_crit(... to printk(KERN_CRIT ..." This patch also fixes a minor checkpatch

[PATCH 4/8] nilfs2: reduce bare use of printk() with nilfs_msg()

Replace most use of printk() in nilfs2 implementation with nilfs_msg(), and reduce the following checkpatch.pl warning: "WARNING: Prefer [subsystem eg: netdev]_crit([subsystem]dev, ... then dev_crit(dev, ... then pr_crit(... to printk(KERN_CRIT ..." This patch also fixes a minor checkpatch

[PATCH 7/8] nilfs2: do not use yield()

Use cond_resched() instead of yield() in the loop of nilfs_transaction_lock() since the usage corresponds to the "be nice for others" case that the comment of yield() says. This removes the following checkpatch.pl warning: "WARNING: Using yield() is generally wrong. See yield() kernel-doc

Re: [PATCH v3 3/3] ACPI / button: Add quirks for initial lid state notification

On Thu, 2016-06-02 at 01:08 +, Zheng, Lv wrote: > Hi, > > > From: Bastien Nocera [mailto:had...@hadess.net] > > Subject: Re: [PATCH v3 3/3] ACPI / button: Add quirks for initial > > lid state > > notification > > > > On Wed, 2016-06-01 at 18:10 +0800, Lv Zheng wrote: > > > Linux userspace

Re: [PATCH v3 3/3] ACPI / button: Add quirks for initial lid state notification

On Thu, 2016-06-02 at 01:08 +, Zheng, Lv wrote: > Hi, > > > From: Bastien Nocera [mailto:had...@hadess.net] > > Subject: Re: [PATCH v3 3/3] ACPI / button: Add quirks for initial > > lid state > > notification > > > > On Wed, 2016-06-01 at 18:10 +0800, Lv Zheng wrote: > > > Linux userspace

[PATCH 2/8] nilfs2: add nilfs_msg() message interface

Define an own output routine to replace bare use of printk() function. The output routine is implemented with a macro and a helper function, which are named nilfs_msg() and __nilfs_msg(), respectively. __nilfs_msg() formats a message like "NILFS (): ", prefixing it with a given log level, and

[PATCH 2/8] nilfs2: add nilfs_msg() message interface

Define an own output routine to replace bare use of printk() function. The output routine is implemented with a macro and a helper function, which are named nilfs_msg() and __nilfs_msg(), respectively. __nilfs_msg() formats a message like "NILFS (): ", prefixing it with a given log level, and

Re: [PATCH 1/3] pci: introduce read_bridge/write_bridge pci ops

On Wed, Jun 01, 2016 at 10:37:28PM +0200, Arnd Bergmann wrote: > On Wednesday, June 1, 2016 2:04:30 PM CEST Bjorn Helgaas wrote: > > On Wed, Jun 01, 2016 at 05:41:53PM +0200, Arnd Bergmann wrote: > > > On Wednesday, June 1, 2016 10:09:29 AM CEST Bjorn Helgaas wrote: > > > > Hi Arnd, > > > > > > >

Re: [PATCH 1/3] pci: introduce read_bridge/write_bridge pci ops

On Wed, Jun 01, 2016 at 10:37:28PM +0200, Arnd Bergmann wrote: > On Wednesday, June 1, 2016 2:04:30 PM CEST Bjorn Helgaas wrote: > > On Wed, Jun 01, 2016 at 05:41:53PM +0200, Arnd Bergmann wrote: > > > On Wednesday, June 1, 2016 10:09:29 AM CEST Bjorn Helgaas wrote: > > > > Hi Arnd, > > > > > > >

Re: [PATCH] sched/cputime: add steal clock warps handling during cpu hotplug

On Thu, 2016-06-02 at 14:00 +0200, Peter Zijlstra wrote: > On Thu, Jun 02, 2016 at 07:57:19PM +0800, Wanpeng Li wrote: > > > > From: Wanpeng Li > > > > I observed that sometimes st is 100% instantaneous, then idle is > > 100%  > > even if there is a cpu hog on the guest

Re: [PATCH] sched/cputime: add steal clock warps handling during cpu hotplug

On Thu, 2016-06-02 at 14:00 +0200, Peter Zijlstra wrote: > On Thu, Jun 02, 2016 at 07:57:19PM +0800, Wanpeng Li wrote: > > > > From: Wanpeng Li > > > > I observed that sometimes st is 100% instantaneous, then idle is > > 100%  > > even if there is a cpu hog on the guest cpu after the cpu

Re: [PATCH 2/2] aer: add support aer interrupt with none MSI/MSI-X/INTx mode

On Thu, Jun 02, 2016 at 05:01:19AM +, Po Liu wrote: > > -Original Message- > > From: Bjorn Helgaas [mailto:helg...@kernel.org] > > Sent: Thursday, June 02, 2016 11:48 AM > > To: Po Liu > > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > >

Re: [PATCH 2/2] aer: add support aer interrupt with none MSI/MSI-X/INTx mode

On Thu, Jun 02, 2016 at 05:01:19AM +, Po Liu wrote: > > -Original Message- > > From: Bjorn Helgaas [mailto:helg...@kernel.org] > > Sent: Thursday, June 02, 2016 11:48 AM > > To: Po Liu > > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > >

[PATCH 2/2] ARM: dts: keystone: add interrupt property to PCI controller bindings

Now that Keystone PCIe controller supports error interrupt handling add interrupt property to PCI controller DT bindings to enable error interrupt handling. Signed-off-by: Murali Karicheri --- - applies to master v4.7-rcx at kernel.org git repo

[PATCH 1/2] ARM: dts: keystone: fix to PCI bindings

The PCI DT bindings contain a bogus entry for IO space which is not supported on Keystone. The current bogus entry has an invalid size and throws following error during boot. [0.420713] keystone-pcie 21021000.pcie: error -22: failed to map resource [io 0x-0x40003fff] So

[PATCH 2/2] ARM: dts: keystone: add interrupt property to PCI controller bindings

Now that Keystone PCIe controller supports error interrupt handling add interrupt property to PCI controller DT bindings to enable error interrupt handling. Signed-off-by: Murali Karicheri --- - applies to master v4.7-rcx at kernel.org git repo arch/arm/boot/dts/keystone-k2e.dtsi | 2 ++

[PATCH 1/2] ARM: dts: keystone: fix to PCI bindings

The PCI DT bindings contain a bogus entry for IO space which is not supported on Keystone. The current bogus entry has an invalid size and throws following error during boot. [0.420713] keystone-pcie 21021000.pcie: error -22: failed to map resource [io 0x-0x40003fff] So

Re: [PATCH] sched/cputime: Fix steal time accouting during cpu hotplug

On Thu, 2016-06-02 at 13:38 +0800, Wanpeng Li wrote: > From: Wanpeng Li >  > I believe rq->prev_irq_time has similar issue. So this patch fix it > by setting  > rq->prev_* to current irq time and steal clock timestamp after a cpu > hotplug  > comes back. > > Fixes:

Re: [PATCH] sched/cputime: Fix steal time accouting during cpu hotplug

On Thu, 2016-06-02 at 13:38 +0800, Wanpeng Li wrote: > From: Wanpeng Li >  > I believe rq->prev_irq_time has similar issue. So this patch fix it > by setting  > rq->prev_* to current irq time and steal clock timestamp after a cpu > hotplug  > comes back. > > Fixes: 'commit e9532e69b8d1

Re: [PATCH 4/4] ARM: exynos_defconfig: Save defconfig on current linux-next

Hello Krzysztof, On 06/02/2016 01:55 AM, Krzysztof Kozlowski wrote: > Save defconfig on next-20160602. Most of changes are just re-ordering of > symbols. Removed symbols: > - FHANDLE (default y), > - THERMAL, EXYNOS_THERMAL (selected by ARCH_EXYNOS), > - CHROME_PLAT

Re: [PATCH 4/4] ARM: exynos_defconfig: Save defconfig on current linux-next

Hello Krzysztof, On 06/02/2016 01:55 AM, Krzysztof Kozlowski wrote: > Save defconfig on next-20160602. Most of changes are just re-ordering of > symbols. Removed symbols: > - FHANDLE (default y), > - THERMAL, EXYNOS_THERMAL (selected by ARCH_EXYNOS), > - CHROME_PLAT

Re: [BUG] Page allocation failures with newest kernels

On Thu, Jun 02, 2016 at 07:48:38AM +0200, Marcin Wojtas wrote: > Hi Will, > > I think I found a right trace. Following one-liner fixes the issue > beginning from v4.2-rc1 up to v4.4 included: > > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -294,7 +294,7 @@ static inline bool >

Re: [BUG] Page allocation failures with newest kernels

On Thu, Jun 02, 2016 at 07:48:38AM +0200, Marcin Wojtas wrote: > Hi Will, > > I think I found a right trace. Following one-liner fixes the issue > beginning from v4.2-rc1 up to v4.4 included: > > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -294,7 +294,7 @@ static inline bool >

<    7   8   9   10   11   12   13   14   15   16   >