Re: [PATCH] of: Add stub for of_get_next_parent()

On Wed, Apr 27, 2016 at 01:13:33PM +0200, Arnd Bergmann wrote: > On Wednesday 27 April 2016 14:11:40 Heikki Krogerus wrote: > > Fixes a compiler error: > > > > drivers/phy/phy-core.c: In function ‘__of_phy_provider_register’: > > drivers/phy/phy-core.c:848:13: error: implicit declaration of

Re: [PATCH] of: Add stub for of_get_next_parent()

On Wed, Apr 27, 2016 at 01:13:33PM +0200, Arnd Bergmann wrote: > On Wednesday 27 April 2016 14:11:40 Heikki Krogerus wrote: > > Fixes a compiler error: > > > > drivers/phy/phy-core.c: In function ‘__of_phy_provider_register’: > > drivers/phy/phy-core.c:848:13: error: implicit declaration of

[PATCH 6/6] mm, page_alloc: don't duplicate code in free_pcp_prepare

The new free_pcp_prepare() function shares a lot of code with free_pages_prepare(), which makes this a maintenance risk when some future patch modifies only one of them. We should be able to achieve the same effect (skipping free_pages_check() from !DEBUG_VM configs) by adding a parameter to

[PATCH 6/6] mm, page_alloc: don't duplicate code in free_pcp_prepare

The new free_pcp_prepare() function shares a lot of code with free_pages_prepare(), which makes this a maintenance risk when some future patch modifies only one of them. We should be able to achieve the same effect (skipping free_pages_check() from !DEBUG_VM configs) by adding a parameter to

Re: [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On Wed, Apr 27, 2016 at 7:38 AM, Michael S. Tsirkin wrote: > On Wed, Apr 27, 2016 at 07:31:43AM -0700, Andy Lutomirski wrote: >> On Wed, Apr 27, 2016 at 7:23 AM, Joerg Roedel wrote: >> > On Wed, Apr 27, 2016 at 04:37:04PM +0300, Michael S. Tsirkin wrote: >> >>

Re: [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On Wed, Apr 27, 2016 at 7:38 AM, Michael S. Tsirkin wrote: > On Wed, Apr 27, 2016 at 07:31:43AM -0700, Andy Lutomirski wrote: >> On Wed, Apr 27, 2016 at 7:23 AM, Joerg Roedel wrote: >> > On Wed, Apr 27, 2016 at 04:37:04PM +0300, Michael S. Tsirkin wrote: >> >> One correction: it's a feature of

[PATCH 4/6] mm, page_alloc: un-inline the bad part of free_pages_check

From: Vlastimil Babka !DEBUG_VM size and bloat-o-meter: add/remove: 1/0 grow/shrink: 0/2 up/down: 124/-370 (-246) function old new delta free_pages_check_bad - 124+124 free_pcppages_bulk

[PATCH 4/6] mm, page_alloc: un-inline the bad part of free_pages_check

From: Vlastimil Babka !DEBUG_VM size and bloat-o-meter: add/remove: 1/0 grow/shrink: 0/2 up/down: 124/-370 (-246) function old new delta free_pages_check_bad - 124+124 free_pcppages_bulk 1288

Re: [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On Wed, Apr 27, 2016 at 05:54:57PM +0300, Michael S. Tsirkin wrote: > Point is, QEMU is not the only virtio implementation out there. > So we can't know no virtio implementations have an IOMMU as long as > linux supports this IOMMU. > virtio always used physical addresses since it was born and if

Re: [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On Wed, Apr 27, 2016 at 05:54:57PM +0300, Michael S. Tsirkin wrote: > Point is, QEMU is not the only virtio implementation out there. > So we can't know no virtio implementations have an IOMMU as long as > linux supports this IOMMU. > virtio always used physical addresses since it was born and if

Re: [GIT PULL rcu/next] RCU commits for 4.7

* Paul E. McKenney wrote: > Hello, Ingo, > > The changes in this series include: > > 1.Documentation updates, including fixes to the design-level > requirements documentation and a fixed version of the design-level > data-structure documentation.

Re: [PATCH] Input: Do not add SYN_REPORT in between a single packet data

On Thu, Apr 7, 2016 at 2:13 AM, Aniroop Mathur wrote: > Hello Mr. Henrik, > > On Thu, Apr 7, 2016 at 1:21 AM, Henrik Rydberg wrote: >> Hi Aniroop, >> I am not sure what the urgency is. It is more of a theoretical problem ans so far the

Re: [PATCH 1/1] mm: thp: kvm: fix memory corruption in KVM with THP enabled

On Wed, Apr 27, 2016 at 04:50:30PM +0300, Kirill A. Shutemov wrote: > I know nothing about kvm. How do you protect against pmd splitting between > get_user_pages() and the check? get_user_pages_fast() runs fully lockless and unpins the page right away (we need a get_user_pages_fast without the

Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

On Wed 2016-04-27 16:39:51, Borislav Petkov wrote: > On Wed, Apr 27, 2016 at 04:30:45PM +0200, Pavel Machek wrote: > > That does not answer the question. "Why would I want SME on my > > system?". > > Because your question wasn't formulated properly. Here's some text from > the 0th mail which you

Re: [GIT PULL rcu/next] RCU commits for 4.7

* Paul E. McKenney wrote: > Hello, Ingo, > > The changes in this series include: > > 1.Documentation updates, including fixes to the design-level > requirements documentation and a fixed version of the design-level > data-structure documentation. These fixes include removing

Re: [PATCH] Input: Do not add SYN_REPORT in between a single packet data

On Thu, Apr 7, 2016 at 2:13 AM, Aniroop Mathur wrote: > Hello Mr. Henrik, > > On Thu, Apr 7, 2016 at 1:21 AM, Henrik Rydberg wrote: >> Hi Aniroop, >> I am not sure what the urgency is. It is more of a theoretical problem ans so far the proposed solutions were actually introducing more

Re: [PATCH 1/1] mm: thp: kvm: fix memory corruption in KVM with THP enabled

On Wed, Apr 27, 2016 at 04:50:30PM +0300, Kirill A. Shutemov wrote: > I know nothing about kvm. How do you protect against pmd splitting between > get_user_pages() and the check? get_user_pages_fast() runs fully lockless and unpins the page right away (we need a get_user_pages_fast without the

Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

On Wed 2016-04-27 16:39:51, Borislav Petkov wrote: > On Wed, Apr 27, 2016 at 04:30:45PM +0200, Pavel Machek wrote: > > That does not answer the question. "Why would I want SME on my > > system?". > > Because your question wasn't formulated properly. Here's some text from > the 0th mail which you

[PATCH 1/6] mm, page_alloc: Only check PageCompound for high-order pages -fix

Vlastimil Babka pointed out that an unlikely annotation in free_pages_prepare shrinks stack usage by moving compound handling to the end of the function. add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-30 (-30) function old new delta free_pages_prepare

[PATCH 1/6] mm, page_alloc: Only check PageCompound for high-order pages -fix

Vlastimil Babka pointed out that an unlikely annotation in free_pages_prepare shrinks stack usage by moving compound handling to the end of the function. add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-30 (-30) function old new delta free_pages_prepare

[PATCH 2/6] mm, page_alloc: move might_sleep_if check to the allocator slowpath -revert

Vlastimil Babka pointed out that a patch weakens a zone_reclaim test which while "safe" defeats the purposes of the debugging check. As most configurations eliminate this check anyway, I thought it was better to simply revert the patch instead of adding a second check in zone_reclaim. This is a

[PATCH 2/6] mm, page_alloc: move might_sleep_if check to the allocator slowpath -revert

Vlastimil Babka pointed out that a patch weakens a zone_reclaim test which while "safe" defeats the purposes of the debugging check. As most configurations eliminate this check anyway, I thought it was better to simply revert the patch instead of adding a second check in zone_reclaim. This is a

[PATCH 5/6] mm, page_alloc: pull out side effects from free_pages_check

Check without side-effects should be easier to maintain. It also removes the duplicated cpupid and flags reset done in !DEBUG_VM variant of both free_pcp_prepare() and then bulkfree_pcp_prepare(). Finally, it enables the next patch. It shouldn't result in new branches, thanks to inlining of the

[PATCH 3/6] mm, page_alloc: Check once if a zone has isolated pageblocks -fix

Vlastimil Babka pointed out that the original code was protected by the zone lock and provided a fix. This is a fix to the mmotm patch mm-page_alloc-check-once-if-a-zone-has-isolated-pageblocks.patch . Once applied the following line should be removed from the changelog "Technically this is

[PATCH 5/6] mm, page_alloc: pull out side effects from free_pages_check

Check without side-effects should be easier to maintain. It also removes the duplicated cpupid and flags reset done in !DEBUG_VM variant of both free_pcp_prepare() and then bulkfree_pcp_prepare(). Finally, it enables the next patch. It shouldn't result in new branches, thanks to inlining of the

[PATCH 3/6] mm, page_alloc: Check once if a zone has isolated pageblocks -fix

Vlastimil Babka pointed out that the original code was protected by the zone lock and provided a fix. This is a fix to the mmotm patch mm-page_alloc-check-once-if-a-zone-has-isolated-pageblocks.patch . Once applied the following line should be removed from the changelog "Technically this is

[PATCH 0/6] Optimise page alloc/free fast paths followup v2

This is a follow-up series based on Vlastimil Babka's review feedback. The first change is that the second patch in the previous series was dropped as the patch "mm, page_alloc: inline the fast path of the zonelist iterator" is fine. The nodemask pointer is the same between cpuset retries. If the

[PATCH 0/6] Optimise page alloc/free fast paths followup v2

This is a follow-up series based on Vlastimil Babka's review feedback. The first change is that the second patch in the previous series was dropped as the patch "mm, page_alloc: inline the fast path of the zonelist iterator" is fine. The nodemask pointer is the same between cpuset retries. If the

Re: [PATCH] x86/efi-bgrt: Switch all pr_err() to pr_debug() for invalid BGRT

On 04/27/2016 03:56 PM, Josh Boyer wrote: On Wed, Apr 27, 2016 at 9:26 AM, Môshe van der Sterre wrote: (additionally CC-ing Josh Triplett) Thanks for doing so. I completely forgot. On 04/27/2016 02:50 PM, Josh Boyer wrote: The promise of pretty boot splashes from firmware

Re: [PATCH] x86/efi-bgrt: Switch all pr_err() to pr_debug() for invalid BGRT

On 04/27/2016 03:56 PM, Josh Boyer wrote: On Wed, Apr 27, 2016 at 9:26 AM, Môshe van der Sterre wrote: (additionally CC-ing Josh Triplett) Thanks for doing so. I completely forgot. On 04/27/2016 02:50 PM, Josh Boyer wrote: The promise of pretty boot splashes from firmware via BGRT was at

Re: [PATCH V4] powerpc: Implement {cmp}xchg for u8 and u16

On Wed, Apr 27, 2016 at 10:50:34PM +0800, Boqun Feng wrote: > > Sorry, my bad, we can't implement cmpxchg like this.. please ignore > this, I should really go to bed soon... > > But still, we can save the "tmp" for xchg() I think. > No.. we can't. Sorry for all the noise. This patch looks

Re: [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On Wed, Apr 27, 2016 at 05:34:30PM +0300, Michael S. Tsirkin wrote: > On Wed, Apr 27, 2016 at 04:23:32PM +0200, Joerg Roedel wrote: > QEMU can choose to bypass IOMMU for one device and not the other. > IOMMU in QEMU isn't involved when it's bypassed. And it is QEMU's task to tell the OS, right?

Re: [PATCH V4] powerpc: Implement {cmp}xchg for u8 and u16

On Wed, Apr 27, 2016 at 10:50:34PM +0800, Boqun Feng wrote: > > Sorry, my bad, we can't implement cmpxchg like this.. please ignore > this, I should really go to bed soon... > > But still, we can save the "tmp" for xchg() I think. > No.. we can't. Sorry for all the noise. This patch looks

Re: [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On Wed, Apr 27, 2016 at 05:34:30PM +0300, Michael S. Tsirkin wrote: > On Wed, Apr 27, 2016 at 04:23:32PM +0200, Joerg Roedel wrote: > QEMU can choose to bypass IOMMU for one device and not the other. > IOMMU in QEMU isn't involved when it's bypassed. And it is QEMU's task to tell the OS, right?

Re: [RFT PATCH] iio: magn: Add support for BMM150 magnetometer

On Tue, Apr 26, 2016 at 9:39 AM, Daniel Baluta wrote: > BMM150 is register compatible with magnetometer part of > BMC156. > > Datasheet is at: > http://www.mouser.com/ds/2/783/BST-BMM150-DS001-01-786480.pdf > > Signed-off-by: Daniel Baluta > ---

Re: [RFT PATCH] iio: magn: Add support for BMM150 magnetometer

On Tue, Apr 26, 2016 at 9:39 AM, Daniel Baluta wrote: > BMM150 is register compatible with magnetometer part of > BMC156. > > Datasheet is at: > http://www.mouser.com/ds/2/783/BST-BMM150-DS001-01-786480.pdf > > Signed-off-by: Daniel Baluta > --- > Lucas let me know if it works for you. I don't

Re: [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On Wed, Apr 27, 2016 at 07:43:07AM -0700, Andy Lutomirski wrote: > On Wed, Apr 27, 2016 at 7:38 AM, Michael S. Tsirkin wrote: > > On Wed, Apr 27, 2016 at 07:31:43AM -0700, Andy Lutomirski wrote: > >> On Wed, Apr 27, 2016 at 7:23 AM, Joerg Roedel wrote: > >> > On

Re: [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On Wed, Apr 27, 2016 at 07:43:07AM -0700, Andy Lutomirski wrote: > On Wed, Apr 27, 2016 at 7:38 AM, Michael S. Tsirkin wrote: > > On Wed, Apr 27, 2016 at 07:31:43AM -0700, Andy Lutomirski wrote: > >> On Wed, Apr 27, 2016 at 7:23 AM, Joerg Roedel wrote: > >> > On Wed, Apr 27, 2016 at 04:37:04PM

[PATCH 14/30] perf hists: Clear dummy entry accumulated period

From: Kan Liang The accumulated period for dummy entry should also be 0. Otherwise, the total overhead could be overcounted. $ perf record -e '{LLC-load-misses,cpu/instructions/}' --call-graph=lbr ./tchain $ perf report --stdio # To display the perf.data header

[PATCH 14/30] perf hists: Clear dummy entry accumulated period

From: Kan Liang The accumulated period for dummy entry should also be 0. Otherwise, the total overhead could be overcounted. $ perf record -e '{LLC-load-misses,cpu/instructions/}' --call-graph=lbr ./tchain $ perf report --stdio # To display the perf.data header info, please use

[PATCH 28/30] perf bench: Remove one more die() call

From: Arnaldo Carvalho de Melo Propagate the error instead. Cc: David Ahern Cc: Hitoshi Mitake Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link:

[PATCH 28/30] perf bench: Remove one more die() call

From: Arnaldo Carvalho de Melo Propagate the error instead. Cc: David Ahern Cc: Hitoshi Mitake Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link: http://lkml.kernel.org/n/tip-z6erjg35d1gekevwujoa0...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo ---

[PATCH] MAINTAINERS: net: Change maintainer for GRETH 10/100/1G Ethernet MAC device driver

Signed-off-by: Andreas Larsson --- MAINTAINERS |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1d5b4be..08ffebd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4903,7 +4903,7 @@ F:net/ipv4/gre_offload.c F:

[PATCH] MAINTAINERS: net: Change maintainer for GRETH 10/100/1G Ethernet MAC device driver

Signed-off-by: Andreas Larsson --- MAINTAINERS |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1d5b4be..08ffebd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4903,7 +4903,7 @@ F:net/ipv4/gre_offload.c F: include/net/gre.h

[PATCH 18/30] perf probe: Let probe_file__add_event return 0 if succeeded

From: Masami Hiramatsu Since other methods return 0 if succeeded (or filedesc), let probe_file__add_event() return 0 instead of the length of written bytes. Signed-off-by: Masami Hiramatsu Cc: Ananth N Mavinakayanahalli Cc:

[PATCH 18/30] perf probe: Let probe_file__add_event return 0 if succeeded

From: Masami Hiramatsu Since other methods return 0 if succeeded (or filedesc), let probe_file__add_event() return 0 instead of the length of written bytes. Signed-off-by: Masami Hiramatsu Cc: Ananth N Mavinakayanahalli Cc: Hemant Kumar Cc: Namhyung Kim Cc: Peter Zijlstra Link:

[PATCH 20/30] perf trace: Move perf_flags beautifier to tools/perf/trace/beauty/

From: Arnaldo Carvalho de Melo To reduce the size of builtin-trace.c. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link:

[PATCH 20/30] perf trace: Move perf_flags beautifier to tools/perf/trace/beauty/

From: Arnaldo Carvalho de Melo To reduce the size of builtin-trace.c. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link: http://lkml.kernel.org/n/tip-8r3gmymyn3r0ynt4yuzsp...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo ---

[PATCH 12/30] perf bench futex: Simplify wrapper for LOCK_PI

From: Davidlohr Bueso Given that the 'val' parameter is ignored for FUTEX_LOCK_PI, get rid of the bogus deadlock detection flag in the wrapper code and avoid the extra argument, making it resemble its unlock counterpart. And if nothing else, we already only pass 0 anyway.

[PATCH v2 2/2] net: nps_enet: bug fix - handle lost tx interrupts

From: Elad Kanfi The tx interrupt is of edge type, and in case such interrupt is triggered while it is masked it will not be handled even after tx interrupts are re-enabled in the end of NAPI poll. This will cause tx network to stop in the following scenario: * Rx is being

[PATCH 12/30] perf bench futex: Simplify wrapper for LOCK_PI

From: Davidlohr Bueso Given that the 'val' parameter is ignored for FUTEX_LOCK_PI, get rid of the bogus deadlock detection flag in the wrapper code and avoid the extra argument, making it resemble its unlock counterpart. And if nothing else, we already only pass 0 anyway. Signed-off-by:

[PATCH v2 2/2] net: nps_enet: bug fix - handle lost tx interrupts

From: Elad Kanfi The tx interrupt is of edge type, and in case such interrupt is triggered while it is masked it will not be handled even after tx interrupts are re-enabled in the end of NAPI poll. This will cause tx network to stop in the following scenario: * Rx is being handled, hence

[PATCH 10/30] perf tools: Remove duplicate const qualifier

From: Eric Engestrom Signed-off-by: Eric Engestrom Cc: Adrian Hunter Cc: David Ahern Cc: Peter Zijlstra Link:

[PATCH 10/30] perf tools: Remove duplicate const qualifier

From: Eric Engestrom Signed-off-by: Eric Engestrom Cc: Adrian Hunter Cc: David Ahern Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1461577678-29517-1-git-send-email-eric.engest...@imgtec.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/thread.c | 2 +- 1 file changed, 1

[PATCH 02/30] perf trace: Extract evsel contructor from perf_evlist__add_pgfault

From: Arnaldo Carvalho de Melo Prep work for next patches, where we'll need access to the created evsels, to possibly configure callchains. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim

[PATCH 02/30] perf trace: Extract evsel contructor from perf_evlist__add_pgfault

From: Arnaldo Carvalho de Melo Prep work for next patches, where we'll need access to the created evsels, to possibly configure callchains. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link:

[PATCH 11/30] perf tests: Replace assignment with comparison on assert check

From: Colin Ian King The current assert check is checking an assignment, which will always be true. Instead, the assert should be checking if scale is equal to 0.122 Signed-off-by: Colin Ian King Reviewed-by: Masami Hiramatsu

[PATCH 11/30] perf tests: Replace assignment with comparison on assert check

From: Colin Ian King The current assert check is checking an assignment, which will always be true. Instead, the assert should be checking if scale is equal to 0.122 Signed-off-by: Colin Ian King Reviewed-by: Masami Hiramatsu Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Peter Zijlstra Link:

[PATCH 19/30] perf probe: Set default kprobe group name if it is not given

From: Masami Hiramatsu Set kprobe group name as "probe" if it is not given. Signed-off-by: Masami Hiramatsu Signed-off-by: Masami Hiramatsu Cc: Ananth N Mavinakayanahalli Cc:

[PATCH 27/30] perf tools: Update x86's syscall_64.tbl, adding preadv2 & pwritev2

From: Arnaldo Carvalho de Melo Introduced in commit 4babf2c5efb7 ("x86: wire up preadv2 and pwritev2"). This will make 'perf trace' aware of them. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Milian Wolff

[PATCH 06/30] perf trace: Make --pf honour --min-stack too

From: Arnaldo Carvalho de Melo To check deeply nested page fault callchains. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Milian Wolff Cc: Namhyung Kim Cc: Wang

[PATCH 19/30] perf probe: Set default kprobe group name if it is not given

From: Masami Hiramatsu Set kprobe group name as "probe" if it is not given. Signed-off-by: Masami Hiramatsu Signed-off-by: Masami Hiramatsu Cc: Ananth N Mavinakayanahalli Cc: Hemant Kumar Cc: Namhyung Kim Cc: Peter Zijlstra Link:

[PATCH 27/30] perf tools: Update x86's syscall_64.tbl, adding preadv2 & pwritev2

From: Arnaldo Carvalho de Melo Introduced in commit 4babf2c5efb7 ("x86: wire up preadv2 and pwritev2"). This will make 'perf trace' aware of them. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Milian Wolff Cc: Namhyung Kim Cc: Wang Nan Link:

[PATCH 06/30] perf trace: Make --pf honour --min-stack too

From: Arnaldo Carvalho de Melo To check deeply nested page fault callchains. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Milian Wolff Cc: Namhyung Kim Cc: Wang Nan Link: http://lkml.kernel.org/n/tip-wuji34xx003kr88nmqt6j...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

[PATCH 08/30] perf tools: Make the x86 clean quiet

From: Jiri Olsa Turn current clean output: $ make clean rm -f arch/x86/include/generated/asm/syscalls_64.c CLEANlibbpf CLEANlibapi into: $ make clean CLEANx86 CLEANlibapi CLEANlibbpf Signed-off-by: Jiri Olsa

[PATCH 08/30] perf tools: Make the x86 clean quiet

From: Jiri Olsa Turn current clean output: $ make clean rm -f arch/x86/include/generated/asm/syscalls_64.c CLEANlibbpf CLEANlibapi into: $ make clean CLEANx86 CLEANlibapi CLEANlibbpf Signed-off-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo

Re: [RFC PATCH v1 01/18] x86: Set the write-protect cache mode for AMD processors

On Wed, Apr 27, 2016 at 7:44 AM, Tom Lendacky wrote: > On 04/27/2016 09:33 AM, Andy Lutomirski wrote: >> On Tue, Apr 26, 2016 at 3:56 PM, Tom Lendacky >> wrote: >>> For AMD processors that support PAT, set the write-protect cache mode >>>

Re: [RFC PATCH v1 01/18] x86: Set the write-protect cache mode for AMD processors

On Wed, Apr 27, 2016 at 7:44 AM, Tom Lendacky wrote: > On 04/27/2016 09:33 AM, Andy Lutomirski wrote: >> On Tue, Apr 26, 2016 at 3:56 PM, Tom Lendacky >> wrote: >>> For AMD processors that support PAT, set the write-protect cache mode >>> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect

Re: [PATCH V4] powerpc: Implement {cmp}xchg for u8 and u16

On Wed, Apr 27, 2016 at 09:58:17PM +0800, Boqun Feng wrote: > On Wed, Apr 27, 2016 at 05:16:45PM +0800, Pan Xinhui wrote: > > From: Pan Xinhui > > > > Implement xchg{u8,u16}{local,relaxed}, and > > cmpxchg{u8,u16}{,local,acquire,relaxed}. > > > > It works on all

Re: [PATCH V4] powerpc: Implement {cmp}xchg for u8 and u16

On Wed, Apr 27, 2016 at 09:58:17PM +0800, Boqun Feng wrote: > On Wed, Apr 27, 2016 at 05:16:45PM +0800, Pan Xinhui wrote: > > From: Pan Xinhui > > > > Implement xchg{u8,u16}{local,relaxed}, and > > cmpxchg{u8,u16}{,local,acquire,relaxed}. > > > > It works on all ppc. > > > > remove volatile of

Re: [RFC PATCH v1 01/18] x86: Set the write-protect cache mode for AMD processors

On 04/27/2016 09:33 AM, Andy Lutomirski wrote: > On Tue, Apr 26, 2016 at 3:56 PM, Tom Lendacky wrote: >> For AMD processors that support PAT, set the write-protect cache mode >> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05). > > What's the purpose

Re: [RFC PATCH v1 01/18] x86: Set the write-protect cache mode for AMD processors

On 04/27/2016 09:33 AM, Andy Lutomirski wrote: > On Tue, Apr 26, 2016 at 3:56 PM, Tom Lendacky wrote: >> For AMD processors that support PAT, set the write-protect cache mode >> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05). > > What's the purpose of using the WP memory

[PATCH 01/30] perf buildid: Fix off-by-one in write_buildid()

From: Andrey Ryabinin write_buildid() increments 'name_len' with intention to take into account trailing zero byte. However, 'name_len' was already incremented in machine__write_buildid_table() before. So this leads to out-of-bounds read in do_write(): $ ./perf

[PATCH 01/30] perf buildid: Fix off-by-one in write_buildid()

From: Andrey Ryabinin write_buildid() increments 'name_len' with intention to take into account trailing zero byte. However, 'name_len' was already incremented in machine__write_buildid_table() before. So this leads to out-of-bounds read in do_write(): $ ./perf record sleep 0 [ perf

[PATCH 09/30] tools build: Fix perf_clean target

From: Jiri Olsa Fix perf_clean target to follow the same logic as perf target. Fixes the following make invokation: $ cd && make tools/perf_clean Reported-by: TJ Signed-off-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo

Re: [PATCH 1/2] mm: add PF_MEMALLOC_NOFS

Michal Hocko wrote: > On Wed 27-04-16 19:53:21, Tetsuo Handa wrote: > [...] > > > Let's hope that filesystems will drop direct GFP_NOFS (resp. ~__GFP_FS) > > > usage as much and possible and only use a properly documented > > > memalloc_nofs_{save,restore} checkpoints where they are appropriate. >

[PATCH 09/30] tools build: Fix perf_clean target

From: Jiri Olsa Fix perf_clean target to follow the same logic as perf target. Fixes the following make invokation: $ cd && make tools/perf_clean Reported-by: TJ Signed-off-by: Jiri Olsa Tested-by: Arnaldo Carvalho de Melo Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Bugzilla:

Re: [PATCH 1/2] mm: add PF_MEMALLOC_NOFS

Michal Hocko wrote: > On Wed 27-04-16 19:53:21, Tetsuo Handa wrote: > [...] > > > Let's hope that filesystems will drop direct GFP_NOFS (resp. ~__GFP_FS) > > > usage as much and possible and only use a properly documented > > > memalloc_nofs_{save,restore} checkpoints where they are appropriate. >

Re: [PATCH v3] usb: core: hub: hub_port_init lock controller instead of bus

On 25.04.2016 15:48, Chris Bainbridge wrote: The XHCI controller presents two USB buses to the system - one for USB2 and one for USB3. The hub init code (hub_port_init) is reentrant but only locks one bus per thread, leading to a race condition failure when two threads attempt to simultaneously

Re: [PATCH v3] usb: core: hub: hub_port_init lock controller instead of bus

On 25.04.2016 15:48, Chris Bainbridge wrote: The XHCI controller presents two USB buses to the system - one for USB2 and one for USB3. The hub init code (hub_port_init) is reentrant but only locks one bus per thread, leading to a race condition failure when two threads attempt to simultaneously

[PATCH 16/30] perf probe: Close target file on error path

From: Masami Hiramatsu Fix a bug to close target elf file in get_text_start_address(). Signed-off-by: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Link:

[PATCH 16/30] perf probe: Close target file on error path

From: Masami Hiramatsu Fix a bug to close target elf file in get_text_start_address(). Signed-off-by: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20160426064737.1443.44093.stgit@devbox Signed-off-by: Arnaldo Carvalho de Melo ---

[PATCH 26/30] perf probe: Fix module probe issue if no dwarf support

From: Ravi Bangoria Perf is not able to register probe in kernel module when dwarf supprt is not there(and so it goes for symtab). Perf passes full path of module where only module name is required which is causing the problem. This patch fixes this issue.

[PATCH 21/30] perf trace: Do not beautify the 'pid' parameter as a simple integer

From: Arnaldo Carvalho de Melo Leave it alone so that it ends up assigned to SCA_PID via its type, 'pid_t', that will look up the pid on the machine thread rb_tree and possibly find its COMM. Cc: Adrian Hunter Cc: David Ahern Cc:

Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

On Tue, Apr 26, 2016 at 3:55 PM, Tom Lendacky wrote: > This RFC patch series provides support for AMD's new Secure Memory > Encryption (SME) feature. > > SME can be used to mark individual pages of memory as encrypted through the > page tables. A page of memory that is

[PATCH 24/30] perf trace: Read thread's COMM from /proc when not set

From: Arnaldo Carvalho de Melo We get notifications for threads that gets created while we're tracing, but for preexisting threads we may end not having synthesized them, like when tracing a 'perf trace' session that will use '--pid' to trace some other thread. And besides we

[PATCH 26/30] perf probe: Fix module probe issue if no dwarf support

From: Ravi Bangoria Perf is not able to register probe in kernel module when dwarf supprt is not there(and so it goes for symtab). Perf passes full path of module where only module name is required which is causing the problem. This patch fixes this issue. Before applying patch: $ dpkg -s

[PATCH 21/30] perf trace: Do not beautify the 'pid' parameter as a simple integer

From: Arnaldo Carvalho de Melo Leave it alone so that it ends up assigned to SCA_PID via its type, 'pid_t', that will look up the pid on the machine thread rb_tree and possibly find its COMM. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Milian Wolff Cc: Namhyung Kim Cc: Wang Nan

Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

On Tue, Apr 26, 2016 at 3:55 PM, Tom Lendacky wrote: > This RFC patch series provides support for AMD's new Secure Memory > Encryption (SME) feature. > > SME can be used to mark individual pages of memory as encrypted through the > page tables. A page of memory that is marked encrypted will be

[PATCH 24/30] perf trace: Read thread's COMM from /proc when not set

From: Arnaldo Carvalho de Melo We get notifications for threads that gets created while we're tracing, but for preexisting threads we may end not having synthesized them, like when tracing a 'perf trace' session that will use '--pid' to trace some other thread. And besides we should probably

Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

On Wed, Apr 27, 2016 at 04:30:45PM +0200, Pavel Machek wrote: > That does not answer the question. "Why would I want SME on my > system?". Because your question wasn't formulated properly. Here's some text from the 0th mail which you could've found on your own: "The following links provide

Re: [PATCH 1/2] regulator: core: Allow use of "status = disabled" in regulator dts nodes

Hi, On 27-04-16 16:37, Mark Brown wrote: On Wed, Apr 27, 2016 at 04:31:02PM +0200, Hans de Goede wrote: On 27-04-16 16:24, Mark Brown wrote: The regulator API should not touch any regulators that it doesn't have permission to change the state for. All other regulators are strictly read

[PATCH 05/30] perf trace: Make --event honour --min-stack too

From: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Milian Wolff Cc: Namhyung Kim Cc: Wang Nan Link:

Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

On Wed, Apr 27, 2016 at 04:30:45PM +0200, Pavel Machek wrote: > That does not answer the question. "Why would I want SME on my > system?". Because your question wasn't formulated properly. Here's some text from the 0th mail which you could've found on your own: "The following links provide

Re: [PATCH 1/2] regulator: core: Allow use of "status = disabled" in regulator dts nodes

Hi, On 27-04-16 16:37, Mark Brown wrote: On Wed, Apr 27, 2016 at 04:31:02PM +0200, Hans de Goede wrote: On 27-04-16 16:24, Mark Brown wrote: The regulator API should not touch any regulators that it doesn't have permission to change the state for. All other regulators are strictly read

[PATCH 05/30] perf trace: Make --event honour --min-stack too

From: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Milian Wolff Cc: Namhyung Kim Cc: Wang Nan Link: http://lkml.kernel.org/n/tip-shj0fazntmskhjild5i6x...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/builtin-trace.c | 21

Re: [PATCH v4 1/2] KVM: remove NULL return path for vcpu ids >= KVM_MAX_VCPUS

2016-04-27 05:40-0400, Gerg Kurz: > Quoting Greg Kurz : > >> Commit c896939f7cff ("KVM: use heuristic for fast VCPU lookup by id") added >> a return path that prevents vcpu ids to exceed KVM_MAX_VCPUS. This is a >> problem for powerpc where vcpu ids can grow up to

Re: [PATCH v4 1/2] KVM: remove NULL return path for vcpu ids >= KVM_MAX_VCPUS

2016-04-27 05:40-0400, Gerg Kurz: > Quoting Greg Kurz : > >> Commit c896939f7cff ("KVM: use heuristic for fast VCPU lookup by id") added >> a return path that prevents vcpu ids to exceed KVM_MAX_VCPUS. This is a >> problem for powerpc where vcpu ids can grow up to 8*KVM_MAX_VCPUS. >> >> This

Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer

HI, > Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi : > > On 04/27/2016 05:10 PM, Tero Kristo wrote: >> On 27/04/16 16:10, H. Nikolaus Schaller wrote: >>> Am 27.04.2016 um 14:31 schrieb Tero Kristo : On 27/04/16 09:04, H. Nikolaus Schaller

Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer

HI, > Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi : > > On 04/27/2016 05:10 PM, Tero Kristo wrote: >> On 27/04/16 16:10, H. Nikolaus Schaller wrote: >>> Am 27.04.2016 um 14:31 schrieb Tero Kristo : On 27/04/16 09:04, H. Nikolaus Schaller wrote: > >> Am 26.04.2016 um

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