Re: BUG_ON() in workingset_node_shadows_dec() triggers

On Thu, Oct 06, 2016 at 04:59:20PM -0700, Linus Torvalds wrote: > We should just switch BUG() over and be done with it. The whole point > it that since it should never trigger in the first place, the > semantics on BUG() should never matter. > > And if you have some code that depends on the

Re: BUG_ON() in workingset_node_shadows_dec() triggers

On Thu, Oct 06, 2016 at 04:59:20PM -0700, Linus Torvalds wrote: > We should just switch BUG() over and be done with it. The whole point > it that since it should never trigger in the first place, the > semantics on BUG() should never matter. > > And if you have some code that depends on the

Re: [PATCH 0/2 v2] userns: show current values of user namespace counters

Hello Eric, What do you think about this series? It should be useful to know current usage for user counters. Thanks, Andrei On Mon, Aug 15, 2016 at 01:10:20PM -0700, Andrei Vagin wrote: > Recently Eric added user namespace counters. User namespace counters is > a feature that allows to limit

Re: [PATCH 0/2 v2] userns: show current values of user namespace counters

Hello Eric, What do you think about this series? It should be useful to know current usage for user counters. Thanks, Andrei On Mon, Aug 15, 2016 at 01:10:20PM -0700, Andrei Vagin wrote: > Recently Eric added user namespace counters. User namespace counters is > a feature that allows to limit

Re: [PATCH 30/54] md/raid5: Delete two error messages for a failed memory allocation

On 10/06/2016 11:30 AM, SF Markus Elfring wrote: From: Markus Elfring Date: Wed, 5 Oct 2016 09:43:40 +0200 Omit extra messages for a memory allocation failure in this function. Link:

Re: [PATCH 30/54] md/raid5: Delete two error messages for a failed memory allocation

On 10/06/2016 11:30 AM, SF Markus Elfring wrote: From: Markus Elfring Date: Wed, 5 Oct 2016 09:43:40 +0200 Omit extra messages for a memory allocation failure in this function. Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf

Re: scripts/coccicheck: Update for a comment?

On Fri, 7 Oct 2016, SF Markus Elfring wrote: > Hello, > > Information from a commit like "docs: sphinxify coccinelle.txt and add it > to dev-tools" caught also my software development attention. >

Re: scripts/coccicheck: Update for a comment?

On Fri, 7 Oct 2016, SF Markus Elfring wrote: > Hello, > > Information from a commit like "docs: sphinxify coccinelle.txt and add it > to dev-tools" caught also my software development attention. >

scripts/coccicheck: Update for a comment?

Hello, Information from a commit like "docs: sphinxify coccinelle.txt and add it to dev-tools" caught also my software development attention. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/coccinelle.txt?id=4b9033a33494ec9154d63e706e9e47f7eb3fd59e Did an

scripts/coccicheck: Update for a comment?

Hello, Information from a commit like "docs: sphinxify coccinelle.txt and add it to dev-tools" caught also my software development attention. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/coccinelle.txt?id=4b9033a33494ec9154d63e706e9e47f7eb3fd59e Did an

[PATCH 2/4] mm: prevent double decrease of nr_reserved_highatomic

There is race between page freeing and unreserved highatomic. CPU 0 CPU 1 free_hot_cold_page mt = get_pfnblock_migratetype set_pcppage_migratetype(page, mt) unreserve_highatomic_pageblock

[PATCH 3/4] mm: unreserve highatomic free pages fully before OOM

After fixing the race of highatomic page count, I still encounter OOM with many free memory reserved as highatomic. One of reason in my testing was we unreserve free pages only if reclaim has progress. Otherwise, we cannot have chance to unreseve. Other problem after fixing it was it doesn't

[PATCH 1/4] mm: adjust reserved highatomic count

In page freeing path, migratetype is racy so that a highorderatomic page could free into non-highorderatomic free list. If that page is allocated, VM can change the pageblock from higorderatomic to something. In that case, we should adjust nr_reserved_highatomic. Otherwise, VM cannot reserve

[PATCH 1/4] mm: adjust reserved highatomic count

In page freeing path, migratetype is racy so that a highorderatomic page could free into non-highorderatomic free list. If that page is allocated, VM can change the pageblock from higorderatomic to something. In that case, we should adjust nr_reserved_highatomic. Otherwise, VM cannot reserve

[PATCH 2/4] mm: prevent double decrease of nr_reserved_highatomic

There is race between page freeing and unreserved highatomic. CPU 0 CPU 1 free_hot_cold_page mt = get_pfnblock_migratetype set_pcppage_migratetype(page, mt) unreserve_highatomic_pageblock

[PATCH 3/4] mm: unreserve highatomic free pages fully before OOM

After fixing the race of highatomic page count, I still encounter OOM with many free memory reserved as highatomic. One of reason in my testing was we unreserve free pages only if reclaim has progress. Otherwise, we cannot have chance to unreseve. Other problem after fixing it was it doesn't

[PATCH 4/4] mm: skip to reserve pageblock crossed zone boundary for HIGHATOMIC

In CONFIG_SPARSEMEM, VM shares a pageblock_flags of a mem_section between two zones if the pageblock cross zone boundaries. It means a zone lock cannot protect pageblock migratype change's race. It might be not a problem because migratetype inherently was racy but intrdocuing with CMA, it was not

[PATCH 4/4] mm: skip to reserve pageblock crossed zone boundary for HIGHATOMIC

In CONFIG_SPARSEMEM, VM shares a pageblock_flags of a mem_section between two zones if the pageblock cross zone boundaries. It means a zone lock cannot protect pageblock migratype change's race. It might be not a problem because migratetype inherently was racy but intrdocuing with CMA, it was not

[PATCH 0/4] use up highorder free pages before OOM

I got OOM report from production team with v4.4 kernel. It has enough free memory but failed to allocate order-0 page and finally encounter OOM kill. I could reproduce it with my test easily. Look at below. The reason is free pages(19M) of DMA32 zone are reserved for HIGHORDERATOMIC and doesn't

[PATCH 0/4] use up highorder free pages before OOM

I got OOM report from production team with v4.4 kernel. It has enough free memory but failed to allocate order-0 page and finally encounter OOM kill. I could reproduce it with my test easily. Look at below. The reason is free pages(19M) of DMA32 zone are reserved for HIGHORDERATOMIC and doesn't

[PATCH] hwmon: fix platform_no_drv_owner.cocci warnings

No need to set .owner here. The core will do it. Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Signed-off-by: Julia Lawall Signed-off-by: Fengguang Wu --- tree: https://github.com/0day-ci/linux

[PATCH] hwmon: fix platform_no_drv_owner.cocci warnings

No need to set .owner here. The core will do it. Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Signed-off-by: Julia Lawall Signed-off-by: Fengguang Wu --- tree: https://github.com/0day-ci/linux Chris-Packham/hwmon-Add-tc654-driver/20161007-054116 head:

Re: [GIT PULL] MD update for 4.9

Mr. Li, There is another thread in [linux-raid] discussing pre-fetches in the raid-6 AVX2 code. My testing implies that the prefetch distance is too short. In your new AVX512 code, it looks like there are 24 instructions, each with latencies of 1, between the prefetch and the actual memory

Re: [GIT PULL] MD update for 4.9

Mr. Li, There is another thread in [linux-raid] discussing pre-fetches in the raid-6 AVX2 code. My testing implies that the prefetch distance is too short. In your new AVX512 code, it looks like there are 24 instructions, each with latencies of 1, between the prefetch and the actual memory

[PATCH V5 05/10] dmaengine: qcom_hidma: make pending_tre_count atomic

Getting ready for the MSI interrupts. The pending_tre_count is used in the interrupt handler to make sure all outstanding requests are serviced. The driver will allocate 11 MSI interrupts. Each MSI interrupt can be assigned to a different CPU. Then, we have a race condition for common variables

[PATCH V5 08/10] dmaengine: qcom_hidma: protect common data structures

When MSI interrupts are supported, error and the transfer interrupt can come from multiple processor contexts. Each error interrupt is an MSI interrupt. If the channel is disabled by the first error interrupt, the remaining error interrupts will gracefully return in the interrupt handler. If an

[PATCH V5 05/10] dmaengine: qcom_hidma: make pending_tre_count atomic

Getting ready for the MSI interrupts. The pending_tre_count is used in the interrupt handler to make sure all outstanding requests are serviced. The driver will allocate 11 MSI interrupts. Each MSI interrupt can be assigned to a different CPU. Then, we have a race condition for common variables

[PATCH V5 08/10] dmaengine: qcom_hidma: protect common data structures

When MSI interrupts are supported, error and the transfer interrupt can come from multiple processor contexts. Each error interrupt is an MSI interrupt. If the channel is disabled by the first error interrupt, the remaining error interrupts will gracefully return in the interrupt handler. If an

[PATCH V5 07/10] dmaengine: qcom_hidma: add a common API to setup the interrupt

Introducing the hidma_ll_setup_irq function to set up the interrupt type externally from the OS interface. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma.h| 2 ++ drivers/dma/qcom/hidma_ll.c | 27 +++ 2 files changed, 25 insertions(+), 4

[PATCH V5 06/10] dmaengine: qcom_hidma: bring out interrupt cause

Bring out the interrupt cause to the top level so that MSI interrupts can be hooked at a later stage. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma_ll.c | 57 ++--- 1 file changed, 33 insertions(+), 24 deletions(-) diff --git

[PATCH V5 09/10] dmaengine: qcom_hidma: break completion processing on error

We try to consume as much successful transfers as possible. Now that we support MSI interrupts, an error interrupt might be observed by another processor while we are finishing the successful ones. Try to abort successful processing if this is the case. Signed-off-by: Sinan Kaya

[PATCH V5 10/10] dmaengine: qcom_hidma: add MSI support for interrupts

The interrupts can now be delivered as platform MSI interrupts on newer platforms. The code looks for a new OF and ACPI strings in order to enable the functionality. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma.c| 143

[PATCH V5 07/10] dmaengine: qcom_hidma: add a common API to setup the interrupt

Introducing the hidma_ll_setup_irq function to set up the interrupt type externally from the OS interface. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma.h| 2 ++ drivers/dma/qcom/hidma_ll.c | 27 +++ 2 files changed, 25 insertions(+), 4 deletions(-) diff

[PATCH V5 06/10] dmaengine: qcom_hidma: bring out interrupt cause

Bring out the interrupt cause to the top level so that MSI interrupts can be hooked at a later stage. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma_ll.c | 57 ++--- 1 file changed, 33 insertions(+), 24 deletions(-) diff --git

[PATCH V5 09/10] dmaengine: qcom_hidma: break completion processing on error

We try to consume as much successful transfers as possible. Now that we support MSI interrupts, an error interrupt might be observed by another processor while we are finishing the successful ones. Try to abort successful processing if this is the case. Signed-off-by: Sinan Kaya ---

[PATCH V5 10/10] dmaengine: qcom_hidma: add MSI support for interrupts

The interrupts can now be delivered as platform MSI interrupts on newer platforms. The code looks for a new OF and ACPI strings in order to enable the functionality. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma.c| 143 ++--

[PATCH V5 03/10] of: irq: make of_msi_configure accessible from modules

The of_msi_configure routine is only accessible by the built-in kernel drivers. Export this function so that modules can use it too. This function is useful for configuring MSI on child device tree nodes on hierarchical objects. Acked-by: Rob Herring Signed-off-by: Sinan Kaya

[PATCH V5 03/10] of: irq: make of_msi_configure accessible from modules

The of_msi_configure routine is only accessible by the built-in kernel drivers. Export this function so that modules can use it too. This function is useful for configuring MSI on child device tree nodes on hierarchical objects. Acked-by: Rob Herring Signed-off-by: Sinan Kaya ---

[PATCH V5 02/10] Documentation: DT: qcom_hidma: correct spelling mistakes

Fix the spelling mistakes and extra and statements in the sentences. Acked-by: Rob Herring Signed-off-by: Sinan Kaya --- Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH V5 01/10] Documentation: DT: qcom_hidma: update binding for MSI

Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting MSI interrupts from the older revision. Signed-off-by: Sinan Kaya --- Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git

[PATCH V5 02/10] Documentation: DT: qcom_hidma: correct spelling mistakes

Fix the spelling mistakes and extra and statements in the sentences. Acked-by: Rob Herring Signed-off-by: Sinan Kaya --- Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH V5 01/10] Documentation: DT: qcom_hidma: update binding for MSI

Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting MSI interrupts from the older revision. Signed-off-by: Sinan Kaya --- Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git

[PATCH V5 04/10] dmaengine: qcom_hidma: configure DMA and MSI for OF

Configure the DMA bindings for the device tree based firmware. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma_mgmt.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c index

[PATCH V5 04/10] dmaengine: qcom_hidma: configure DMA and MSI for OF

Configure the DMA bindings for the device tree based firmware. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma_mgmt.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c index 82f36e4..185d29c 100644 ---

Re: [PATCH V1 05/10] thermal: da9062/61: Thermal junction temperature monitoring driver

Steve, On Thursday 06 October 2016 02:13 PM, Steve Twiss wrote: From: Steve Twiss Add junction temperature monitoring supervisor device driver, compatible with the DA9062 and DA9061 PMICs. If the PMIC's internal junction temperature rises above TEMP_WARN (125

Re: [PATCH V1 05/10] thermal: da9062/61: Thermal junction temperature monitoring driver

Steve, On Thursday 06 October 2016 02:13 PM, Steve Twiss wrote: From: Steve Twiss Add junction temperature monitoring supervisor device driver, compatible with the DA9062 and DA9061 PMICs. If the PMIC's internal junction temperature rises above TEMP_WARN (125 degC) an interrupt is issued.

Re: [PATCH] mm/slab: fix kmemcg cache creation delayed issue

On Thu, Oct 06, 2016 at 09:02:00AM -0700, Doug Smythies wrote: > It was my (limited) understanding that the subsequent 2 patch set > superseded this patch. Indeed, the 2 patch set seems to solve > both the SLAB and SLUB bug reports. It would mean that patch 1 solves both the SLAB and SLUB bug

Re: [PATCH] mm/slab: fix kmemcg cache creation delayed issue

On Thu, Oct 06, 2016 at 09:02:00AM -0700, Doug Smythies wrote: > It was my (limited) understanding that the subsequent 2 patch set > superseded this patch. Indeed, the 2 patch set seems to solve > both the SLAB and SLUB bug reports. It would mean that patch 1 solves both the SLAB and SLUB bug

Re: [RFC PATCH] mm, compaction: allow compaction for GFP_NOFS requests

On 10/04/2016 10:12 AM, Michal Hocko wrote: From: Michal Hocko compaction has been disabled for GFP_NOFS and GFP_NOIO requests since the direct compaction was introduced by 56de7263fcf3 ("mm: compaction: direct compact when a high-order allocation fails"). The main reason is

Re: [RFC PATCH] mm, compaction: allow compaction for GFP_NOFS requests

On 10/04/2016 10:12 AM, Michal Hocko wrote: From: Michal Hocko compaction has been disabled for GFP_NOFS and GFP_NOIO requests since the direct compaction was introduced by 56de7263fcf3 ("mm: compaction: direct compact when a high-order allocation fails"). The main reason is that the migration

Re: Scrolling down broken with "perf top --hierarchy"

On 2016.10.07 at 06:56 +0200, Markus Trippelsdorf wrote: > On 2016.10.07 at 06:32 +0200, Markus Trippelsdorf wrote: > > On 2016.10.07 at 13:22 +0900, Namhyung Kim wrote: > > > On Fri, Oct 07, 2016 at 05:51:18AM +0200, Markus Trippelsdorf wrote: > > > > On 2016.10.07 at 10:17 +0900, Namhyung Kim

Re: Scrolling down broken with "perf top --hierarchy"

On 2016.10.07 at 06:56 +0200, Markus Trippelsdorf wrote: > On 2016.10.07 at 06:32 +0200, Markus Trippelsdorf wrote: > > On 2016.10.07 at 13:22 +0900, Namhyung Kim wrote: > > > On Fri, Oct 07, 2016 at 05:51:18AM +0200, Markus Trippelsdorf wrote: > > > > On 2016.10.07 at 10:17 +0900, Namhyung Kim

[PATCH] perf top: Fix refreshing hierarchy entries on TUI

Markus reported that 'perf top --hierarchy' cannot scroll down after refresh. This was because the number of entries are not updated when hierarchy is enabled. Unlike normal report view, hierarchy mode needs to keep its own entry count since it can have non-leaf entries which can

[PATCH] perf top: Fix refreshing hierarchy entries on TUI

Markus reported that 'perf top --hierarchy' cannot scroll down after refresh. This was because the number of entries are not updated when hierarchy is enabled. Unlike normal report view, hierarchy mode needs to keep its own entry count since it can have non-leaf entries which can

[GIT PULL] drm-vc4-next-2016-10-06

These are fixes that have been on the list for 1-3 weeks that didn't make it into 4.9. I've been running most of them most of the time, some have been merged downstream, and some have also been merged to the Fedora kernel build. This is about as much testing as we ever get on vc4, so I feel

[GIT PULL] drm-vc4-next-2016-10-06

These are fixes that have been on the list for 1-3 weeks that didn't make it into 4.9. I've been running most of them most of the time, some have been merged downstream, and some have also been merged to the Fedora kernel build. This is about as much testing as we ever get on vc4, so I feel

Re: Scrolling down broken with "perf top --hierarchy"

On 2016.10.07 at 06:32 +0200, Markus Trippelsdorf wrote: > On 2016.10.07 at 13:22 +0900, Namhyung Kim wrote: > > On Fri, Oct 07, 2016 at 05:51:18AM +0200, Markus Trippelsdorf wrote: > > > On 2016.10.07 at 10:17 +0900, Namhyung Kim wrote: > > > > On Thu, Oct 06, 2016 at 06:33:33PM +0200, Markus

Re: Scrolling down broken with "perf top --hierarchy"

On 2016.10.07 at 06:32 +0200, Markus Trippelsdorf wrote: > On 2016.10.07 at 13:22 +0900, Namhyung Kim wrote: > > On Fri, Oct 07, 2016 at 05:51:18AM +0200, Markus Trippelsdorf wrote: > > > On 2016.10.07 at 10:17 +0900, Namhyung Kim wrote: > > > > On Thu, Oct 06, 2016 at 06:33:33PM +0200, Markus

Re: Scrolling down broken with "perf top --hierarchy"

Cc-ing perf maintainers, On Fri, Oct 07, 2016 at 06:32:29AM +0200, Markus Trippelsdorf wrote: > On 2016.10.07 at 13:22 +0900, Namhyung Kim wrote: > > On Fri, Oct 07, 2016 at 05:51:18AM +0200, Markus Trippelsdorf wrote: > > > On 2016.10.07 at 10:17 +0900, Namhyung Kim wrote: > > > > On Thu, Oct

Re: Scrolling down broken with "perf top --hierarchy"

Cc-ing perf maintainers, On Fri, Oct 07, 2016 at 06:32:29AM +0200, Markus Trippelsdorf wrote: > On 2016.10.07 at 13:22 +0900, Namhyung Kim wrote: > > On Fri, Oct 07, 2016 at 05:51:18AM +0200, Markus Trippelsdorf wrote: > > > On 2016.10.07 at 10:17 +0900, Namhyung Kim wrote: > > > > On Thu, Oct

[PATCH 01/01] drivers:input:byd fix greedy detection of Sentelic FSP by the BYD touchpad driver

From: Christophe TORDEUX With kernel v4.6 and later, the Sentelic touchpad STL3888_C0 and probably other Sentelic FSP touchpads are detected as a BYD touchpad and lose multitouch features. During the BYD handshake in the byd_detect function, the BYD driver mistakenly

[PATCH 01/01] drivers:input:byd fix greedy detection of Sentelic FSP by the BYD touchpad driver

From: Christophe TORDEUX With kernel v4.6 and later, the Sentelic touchpad STL3888_C0 and probably other Sentelic FSP touchpads are detected as a BYD touchpad and lose multitouch features. During the BYD handshake in the byd_detect function, the BYD driver mistakenly interprets a standard PS/2

[RESEND PATCH v3] scsi: ufshcd: fix possible unclocked register access

Vendor specific setup_clocks callback may require the clocks managed by ufshcd driver to be ON. So if the vendor specific setup_clocks callback is called while the required clocks are turned off, it could result into unclocked register access. To prevent possible unclock register access, this

[RESEND PATCH v3] scsi: ufshcd: fix possible unclocked register access

Vendor specific setup_clocks callback may require the clocks managed by ufshcd driver to be ON. So if the vendor specific setup_clocks callback is called while the required clocks are turned off, it could result into unclocked register access. To prevent possible unclock register access, this

Re: [PATCH v2] mount: dont execute propagate_umount() many times for same mounts

Andrei Vagin writes: > On Thu, Oct 06, 2016 at 02:46:30PM -0500, Eric W. Biederman wrote: >> Andrei Vagin writes: >> >> > The reason of this optimization is that umount() can hold namespace_sem >> > for a long time, this semaphore is global, so it

Re: [PATCH v2] mount: dont execute propagate_umount() many times for same mounts

Andrei Vagin writes: > On Thu, Oct 06, 2016 at 02:46:30PM -0500, Eric W. Biederman wrote: >> Andrei Vagin writes: >> >> > The reason of this optimization is that umount() can hold namespace_sem >> > for a long time, this semaphore is global, so it affects all users. >> > Recently Eric W.

Re: [PATCH] staging: sm750fb: Fix printk() style warning

On Sun, Oct 02, 2016 at 08:13:01PM +0200, Greg KH wrote: > On Sun, Oct 02, 2016 at 11:05:05AM -0700, Edward Lipinsky wrote: > > This patch fixes the checkpatch.pl warning: > > > > WARNING: printk() should include KERN_ facility level > > > > Signed-off-by: Edward Lipinsky

Re: [PATCH] staging: sm750fb: Fix printk() style warning

On Sun, Oct 02, 2016 at 08:13:01PM +0200, Greg KH wrote: > On Sun, Oct 02, 2016 at 11:05:05AM -0700, Edward Lipinsky wrote: > > This patch fixes the checkpatch.pl warning: > > > > WARNING: printk() should include KERN_ facility level > > > > Signed-off-by: Edward Lipinsky > > --- > >

Re: [tip:x86/apic] x86/acpi: Introduce persistent storage for cpuid <-> apicid mapping

Hi Yinghai At 10/07/2016 05:20 AM, Yinghai Lu wrote: On Thu, Oct 6, 2016 at 1:06 AM, Dou Liyang wrote: I seem to remember that in x2APIC Spec the x2APIC ID may be at 255 or greater. Good to know. Maybe later when one package have more cores like 30 cores etc.

Re: [tip:x86/apic] x86/acpi: Introduce persistent storage for cpuid <-> apicid mapping

Hi Yinghai At 10/07/2016 05:20 AM, Yinghai Lu wrote: On Thu, Oct 6, 2016 at 1:06 AM, Dou Liyang wrote: I seem to remember that in x2APIC Spec the x2APIC ID may be at 255 or greater. Good to know. Maybe later when one package have more cores like 30 cores etc. If we do that judgment, it

Re: [PATCH 1/2] watchdog: Introduce update_arch_nmi_watchdog

On Thu, Oct 06, 2016 at 03:16:42PM -0700, Babu Moger wrote: > Currently we do not have a way to enable/disable arch specific > watchdog handlers if it was implemented by any of the architectures. > > This patch introduces new function update_arch_nmi_watchdog > which can be used to enable/disable

Re: [PATCH 1/2] watchdog: Introduce update_arch_nmi_watchdog

On Thu, Oct 06, 2016 at 03:16:42PM -0700, Babu Moger wrote: > Currently we do not have a way to enable/disable arch specific > watchdog handlers if it was implemented by any of the architectures. > > This patch introduces new function update_arch_nmi_watchdog > which can be used to enable/disable

Re: Scrolling down broken with "perf top --hierarchy"

On 2016.10.07 at 13:22 +0900, Namhyung Kim wrote: > On Fri, Oct 07, 2016 at 05:51:18AM +0200, Markus Trippelsdorf wrote: > > On 2016.10.07 at 10:17 +0900, Namhyung Kim wrote: > > > On Thu, Oct 06, 2016 at 06:33:33PM +0200, Markus Trippelsdorf wrote: > > > > Scrolling down is broken when using

Re: Scrolling down broken with "perf top --hierarchy"

On 2016.10.07 at 13:22 +0900, Namhyung Kim wrote: > On Fri, Oct 07, 2016 at 05:51:18AM +0200, Markus Trippelsdorf wrote: > > On 2016.10.07 at 10:17 +0900, Namhyung Kim wrote: > > > On Thu, Oct 06, 2016 at 06:33:33PM +0200, Markus Trippelsdorf wrote: > > > > Scrolling down is broken when using

Re: Scrolling down broken with "perf top --hierarchy"

On Fri, Oct 07, 2016 at 05:51:18AM +0200, Markus Trippelsdorf wrote: > On 2016.10.07 at 10:17 +0900, Namhyung Kim wrote: > > On Thu, Oct 06, 2016 at 06:33:33PM +0200, Markus Trippelsdorf wrote: > > > Scrolling down is broken when using "perf top --hierarchy". > > > When it starts up everything is

Re: Scrolling down broken with "perf top --hierarchy"

On Fri, Oct 07, 2016 at 05:51:18AM +0200, Markus Trippelsdorf wrote: > On 2016.10.07 at 10:17 +0900, Namhyung Kim wrote: > > On Thu, Oct 06, 2016 at 06:33:33PM +0200, Markus Trippelsdorf wrote: > > > Scrolling down is broken when using "perf top --hierarchy". > > > When it starts up everything is

Re: [PATCH] ftrace: Support full glob matching

Hi Masami, On Wed, Oct 05, 2016 at 08:58:15PM +0900, Masami Hiramatsu wrote: > Use glob_match() to support flexible glob wildcards (*,?) > and character classes ([) for ftrace. > Since the full glob matching is slower than the current > partial matching routines(*pat, pat*, *pat*), this leaves >

Re: [PATCH] ftrace: Support full glob matching

Hi Masami, On Wed, Oct 05, 2016 at 08:58:15PM +0900, Masami Hiramatsu wrote: > Use glob_match() to support flexible glob wildcards (*,?) > and character classes ([) for ftrace. > Since the full glob matching is slower than the current > partial matching routines(*pat, pat*, *pat*), this leaves >

Re: [PATCH] tools lib traceevent: Fix kbuffer_read_at_offset()

Hi Steve, On Wed, Oct 05, 2016 at 09:28:01AM -0400, Steven Rostedt wrote: > On Sat, 1 Oct 2016 19:17:00 +0900 > Namhyung Kim wrote: > > > When it's called with an offset less than or equal to the first event, > > it'll return a garbage value since the data is not

Re: [PATCH] tools lib traceevent: Fix kbuffer_read_at_offset()

Hi Steve, On Wed, Oct 05, 2016 at 09:28:01AM -0400, Steven Rostedt wrote: > On Sat, 1 Oct 2016 19:17:00 +0900 > Namhyung Kim wrote: > > > When it's called with an offset less than or equal to the first event, > > it'll return a garbage value since the data is not initialized. > > Well, it can

[PATCH - stable 4.1 backport] block: don't release bdi while request_queue has live references

Hi, This patch was marked for stable v4.2+, but is needed for v4.1 as well. It fixes a regression introduced by: Fixes: 6cd18e711dd8 ("block: destroy bdi before blockdev is unregistered.") This is a backport to 4.1.33 which has been tested and confirmed to work. Bug report at

[PATCH - stable 4.1 backport] block: don't release bdi while request_queue has live references

Hi, This patch was marked for stable v4.2+, but is needed for v4.1 as well. It fixes a regression introduced by: Fixes: 6cd18e711dd8 ("block: destroy bdi before blockdev is unregistered.") This is a backport to 4.1.33 which has been tested and confirmed to work. Bug report at

loop mount: kernel BUG at lib/percpu-refcount.c:231

Hi, Below bug happened to me while loop mount a file image after stopping a kvm guest. But it only happend once til now.. [ 4761.031686] [ cut here ] [ 4761.075984] kernel BUG at lib/percpu-refcount.c:231! [ 4761.120184] invalid opcode: [#1] SMP [ 4761.164307]

loop mount: kernel BUG at lib/percpu-refcount.c:231

Hi, Below bug happened to me while loop mount a file image after stopping a kvm guest. But it only happend once til now.. [ 4761.031686] [ cut here ] [ 4761.075984] kernel BUG at lib/percpu-refcount.c:231! [ 4761.120184] invalid opcode: [#1] SMP [ 4761.164307]

[GIT PULL] Please pull powerpc/linux.git powerpc-4.9-1 tag

Hi Linus, Please pull the first batch of powerpc updates for 4.9: The following changes since commit c6935931c1894ff857616ff8549b61236a19148f: Linux 4.8-rc5 (2016-09-04 14:31:46 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git

[GIT PULL] Please pull powerpc/linux.git powerpc-4.9-1 tag

Hi Linus, Please pull the first batch of powerpc updates for 4.9: The following changes since commit c6935931c1894ff857616ff8549b61236a19148f: Linux 4.8-rc5 (2016-09-04 14:31:46 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git

Re: [PATCH 4.8 00/10] 4.8.1-stable review

On Thu, Oct 06, 2016 at 11:51:01AM -0700, Guenter Roeck wrote: > On Thu, Oct 06, 2016 at 10:18:23AM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.8.1 release. > > There are 10 patches in this series, all will be posted as a response > > to this one.

Re: CONFIG_DEBUG_TEST_DRIVER_REMOVE needs a warning

On Thu, Oct 6, 2016 at 6:53 PM, Laura Abbott wrote: > On a whim, I decided to turn on CONFIG_DEBUG_TEST_DRIVER_REMOVE on > Fedora rawhide since it sounded harmless enough. It spewed warnings > and panicked some systems. Clearly it's doing its job > well of finding drivers

Re: CONFIG_DEBUG_TEST_DRIVER_REMOVE needs a warning

On Thu, Oct 6, 2016 at 6:53 PM, Laura Abbott wrote: > On a whim, I decided to turn on CONFIG_DEBUG_TEST_DRIVER_REMOVE on > Fedora rawhide since it sounded harmless enough. It spewed warnings > and panicked some systems. Clearly it's doing its job > well of finding drivers that can't handle

Re: [PATCH 4.8 00/10] 4.8.1-stable review

On Thu, Oct 06, 2016 at 11:51:01AM -0700, Guenter Roeck wrote: > On Thu, Oct 06, 2016 at 10:18:23AM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.8.1 release. > > There are 10 patches in this series, all will be posted as a response > > to this one.

Re: [PATCH 4.7 000/141] 4.7.7-stable review

On Thu, Oct 06, 2016 at 11:54:02AM -0700, Guenter Roeck wrote: > On Thu, Oct 06, 2016 at 10:27:16AM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.7.7 release. > > There are 141 patches in this series, all will be posted as a response > > to this one.

Re: Change CONFIG_DEVKMEM default value to n

On Fri, Oct 07, 2016 at 10:04:11AM +0800, Dave Young wrote: > Kconfig comment suggests setting it as "n" if in doubt thus move the > default value to 'n'. > > Signed-off-by: Dave Young > Suggested-by: Kees Cook > --- > drivers/char/Kconfig |2 +- >

Re: [PATCH 4.7 000/141] 4.7.7-stable review

On Thu, Oct 06, 2016 at 11:54:02AM -0700, Guenter Roeck wrote: > On Thu, Oct 06, 2016 at 10:27:16AM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.7.7 release. > > There are 141 patches in this series, all will be posted as a response > > to this one.

Re: Change CONFIG_DEVKMEM default value to n

On Fri, Oct 07, 2016 at 10:04:11AM +0800, Dave Young wrote: > Kconfig comment suggests setting it as "n" if in doubt thus move the > default value to 'n'. > > Signed-off-by: Dave Young > Suggested-by: Kees Cook > --- > drivers/char/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1

Re: [PATCH 4.8 00/10] 4.8.1-stable review

On Thu, Oct 06, 2016 at 01:56:28PM -0600, Shuah Khan wrote: > On 10/06/2016 02:18 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.8.1 release. > > There are 10 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH] staging: lustre: lprocfs_status.h: fix sparse error: symbol redeclared with different type

On Thu, Oct 06, 2016 at 06:52:07PM +0200, Samuele Baisi wrote: > drivers/staging/lustre/lustre/obdclass/lprocfs_status.c:1554:5: error: > symbol 'lprocfs_wr_root_squash' redeclared with different type (originally > declared at >

Re: [PATCH 4.8 00/10] 4.8.1-stable review

On Thu, Oct 06, 2016 at 01:56:28PM -0600, Shuah Khan wrote: > On 10/06/2016 02:18 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.8.1 release. > > There are 10 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH] staging: lustre: lprocfs_status.h: fix sparse error: symbol redeclared with different type

On Thu, Oct 06, 2016 at 06:52:07PM +0200, Samuele Baisi wrote: > drivers/staging/lustre/lustre/obdclass/lprocfs_status.c:1554:5: error: > symbol 'lprocfs_wr_root_squash' redeclared with different type (originally > declared at >

Re: [PATCH 4.7 122/141] scsi: ses: use scsi_is_sas_rphy instead of is_sas_attached

On Thu, Oct 06, 2016 at 09:25:34PM +0800, James Bottomley wrote: > On Thu, 2016-10-06 at 10:29 +0200, Greg Kroah-Hartman wrote: > > 4.7-stable review patch. If anyone has any objections, please let me > > know. > > This doesn't build if SCSI_SAS_ATTRS isn't set without this patch: > > > commit

Re: CONFIG_DEBUG_TEST_DRIVER_REMOVE needs a warning

On Thu, Oct 06, 2016 at 04:53:20PM -0700, Laura Abbott wrote: > On a whim, I decided to turn on CONFIG_DEBUG_TEST_DRIVER_REMOVE on > Fedora rawhide since it sounded harmless enough. It spewed warnings > and panicked some systems. Clearly it's doing its job > well of finding drivers that can't

  1   2   3   4   5   6   7   8   9   10   >