Re: [PATCH v9 01/10] clk: fix initial state of critical clock's parents

On Mon, 2016-07-11 at 16:24 +0800, James Liao wrote: > Hi Mike, > > On Fri, 2016-07-08 at 16:32 -0700, Michael Turquette wrote: > > Hi James, > > > > Quoting James Liao (2016-07-03 20:51:48) > > > On Fri, 2016-07-01 at 18:21 -0700, Stephen Boyd wrote: > > > > (Resending to everyone) > > > > > >

Re: [PATCH v9 01/10] clk: fix initial state of critical clock's parents

On Mon, 2016-07-11 at 16:24 +0800, James Liao wrote: > Hi Mike, > > On Fri, 2016-07-08 at 16:32 -0700, Michael Turquette wrote: > > Hi James, > > > > Quoting James Liao (2016-07-03 20:51:48) > > > On Fri, 2016-07-01 at 18:21 -0700, Stephen Boyd wrote: > > > > (Resending to everyone) > > > > > >

Re: [PATCH] mips: lantiq: fix irq_chip name to not land in new parent field

On Tue, Aug 02, 2016 at 02:54:47PM -0400, Paul Gortmaker wrote: > As of commit be45beb2df69 ("genirq: Add runtime power management > support for IRQ chips") the irq_chip struct got a struct *device > parent_device field added to it. However, it was added at the > beginning of the struct, which

Re: [PATCH] mips: lantiq: fix irq_chip name to not land in new parent field

On Tue, Aug 02, 2016 at 02:54:47PM -0400, Paul Gortmaker wrote: > As of commit be45beb2df69 ("genirq: Add runtime power management > support for IRQ chips") the irq_chip struct got a struct *device > parent_device field added to it. However, it was added at the > beginning of the struct, which

Re: [PATCH] raid5: fix incorrectly counter of conf->empty_inactive_list_nr

Thanks for you replay. I think it may be on the temp inactive list. An active sh was handled and put to temp inactive list firstly, then moved to inactive list. If sh is on the temp inactive list, sh->count is zero too. -- Original -- From:

Re: [PATCH] raid5: fix incorrectly counter of conf->empty_inactive_list_nr

Thanks for you replay. I think it may be on the temp inactive list. An active sh was handled and put to temp inactive list firstly, then moved to inactive list. If sh is on the temp inactive list, sh->count is zero too. -- Original -- From: "NeilBrown"; Date:

Re: ARC stable backport request

On Tue, Aug 02, 2016 at 09:45:56AM +0200, Jiri Slaby wrote: > On 08/02/2016, 09:00 AM, Greg KH wrote: > > On Wed, May 25, 2016 at 05:13:31PM +0530, Vineet Gupta wrote: > >> Hi, > >> > >> Can we please backport a6416f57ce57fb390b "ARC: use ASL assembler > >> mnemonic". > >> Newer binutils don't

Re: ARC stable backport request

On Tue, Aug 02, 2016 at 09:45:56AM +0200, Jiri Slaby wrote: > On 08/02/2016, 09:00 AM, Greg KH wrote: > > On Wed, May 25, 2016 at 05:13:31PM +0530, Vineet Gupta wrote: > >> Hi, > >> > >> Can we please backport a6416f57ce57fb390b "ARC: use ASL assembler > >> mnemonic". > >> Newer binutils don't

[PATCH v2 3/3] mm: memcontrol: add sanity checks for memcg->id.ref on get/put

Signed-off-by: Vladimir Davydov --- mm/memcontrol.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 67109d556a4a..32b2f33865f9 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -4033,6 +4033,7 @@ static

[PATCH v2 3/3] mm: memcontrol: add sanity checks for memcg->id.ref on get/put

Signed-off-by: Vladimir Davydov --- mm/memcontrol.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 67109d556a4a..32b2f33865f9 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -4033,6 +4033,7 @@ static

[PATCH] lkdtm: Mark lkdtm_rodata_do_nothing() notrace

lkdtm_rodata_do_nothing() is an empty function which is generated in order to test the non-executability of rodata. Currently if function tracing is enabled then an mcount callsite will be generated for lkdtm_rodata_do_nothing(), and it will appear in the list of available functions for function

[PATCH] lkdtm: Mark lkdtm_rodata_do_nothing() notrace

lkdtm_rodata_do_nothing() is an empty function which is generated in order to test the non-executability of rodata. Currently if function tracing is enabled then an mcount callsite will be generated for lkdtm_rodata_do_nothing(), and it will appear in the list of available functions for function

Re: [kernel-hardening] Re: Linker segfault on powerpc when CONFIG_LKDTM=y (was Re: [kernel-hardening] [PATCH 3/5] lkdtm: add function for testing .rodata section)

Kees Cook writes: > On Mon, Aug 1, 2016 at 8:12 PM, Michael Ellerman wrote: >> Kees Cook writes: >>> On Mon, Aug 1, 2016 at 5:37 AM, Michael Ellerman >>> wrote: scripts/link-vmlinux.sh: line

Re: [kernel-hardening] Re: Linker segfault on powerpc when CONFIG_LKDTM=y (was Re: [kernel-hardening] [PATCH 3/5] lkdtm: add function for testing .rodata section)

Kees Cook writes: > On Mon, Aug 1, 2016 at 8:12 PM, Michael Ellerman wrote: >> Kees Cook writes: >>> On Mon, Aug 1, 2016 at 5:37 AM, Michael Ellerman >>> wrote: scripts/link-vmlinux.sh: line 52: 36260 Segmentation fault (core dumped) ${LD} ${LDFLAGS} ${LDFLAGS_vmlinux}

[GIT] Networking

1) Fix several cases of missing of_node_put() calls in various networking drivers. From Peter Chen. 2) Don't try to remove unconfigured VLANs in qed driver, from Yuval Mintz. 3) Unbalanced locking in TIPC error handling, from Wei Yongjun. 4) Fix lockups in CPDMA driver, from Grygorii

[GIT] Networking

1) Fix several cases of missing of_node_put() calls in various networking drivers. From Peter Chen. 2) Don't try to remove unconfigured VLANs in qed driver, from Yuval Mintz. 3) Unbalanced locking in TIPC error handling, from Wei Yongjun. 4) Fix lockups in CPDMA driver, from Grygorii

Re: [PATCH 1/5] bfa: mark symbols static where possible

Hi Arnd, [auto build test ERROR on scsi/for-next] [also build test ERROR on v4.7 next-20160802] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Arnd-Bergmann/bfa-fix-W-1-build-warnings/20160803

Re: [PATCH 1/5] bfa: mark symbols static where possible

Hi Arnd, [auto build test ERROR on scsi/for-next] [also build test ERROR on v4.7 next-20160802] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Arnd-Bergmann/bfa-fix-W-1-build-warnings/20160803

Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?

On Thu, Mar 03, 2016 at 11:05:43AM -0800, H. Peter Anvin wrote: > On March 3, 2016 10:35:50 AM PST, "Michael S. Tsirkin" > wrote: > >On Thu, Mar 03, 2016 at 04:34:53PM +0100, Peter Zijlstra wrote: > >> On Thu, Mar 03, 2016 at 04:27:39PM +0100, Ingo Molnar wrote: > >> > > >> > *

Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?

On Thu, Mar 03, 2016 at 11:05:43AM -0800, H. Peter Anvin wrote: > On March 3, 2016 10:35:50 AM PST, "Michael S. Tsirkin" > wrote: > >On Thu, Mar 03, 2016 at 04:34:53PM +0100, Peter Zijlstra wrote: > >> On Thu, Mar 03, 2016 at 04:27:39PM +0100, Ingo Molnar wrote: > >> > > >> > * Dexuan Cui

Re: [PATCH] phy: fix the bug when remove the phy driver

On August 2, 2016 9:22:53 PM MST, Ding Tianhong wrote: >On 2016/8/3 10:41, Florian Fainelli wrote: >> On August 2, 2016 6:21:52 PM MST, Ding Tianhong > wrote: >>> On 2016/8/3 0:42, Florian Fainelli wrote: Le 02/08/2016 à 06:00, Ding Tianhong

Re: [PATCH] phy: fix the bug when remove the phy driver

On August 2, 2016 9:22:53 PM MST, Ding Tianhong wrote: >On 2016/8/3 10:41, Florian Fainelli wrote: >> On August 2, 2016 6:21:52 PM MST, Ding Tianhong > wrote: >>> On 2016/8/3 0:42, Florian Fainelli wrote: Le 02/08/2016 à 06:00, Ding Tianhong a écrit : > The nic in my board use the phy

Re: [PATCH] phy: fix the bug when remove the phy driver

On 2016/8/3 10:41, Florian Fainelli wrote: > On August 2, 2016 6:21:52 PM MST, Ding Tianhong > wrote: >> On 2016/8/3 0:42, Florian Fainelli wrote: >>> Le 02/08/2016 à 06:00, Ding Tianhong a écrit : The nic in my board use the phy dev from marvell, and the

Re: [PATCH 2/2] soc: nxp: Add a RCPM driver

On Mon, Aug 1, 2016 at 8:25 PM, Arnd Bergmann wrote: > On Monday, August 1, 2016 5:49:03 PM CEST Chenhui Zhao wrote: >> The NXP's QorIQ Processors based on ARM Core have a RCPM module >> (Run Control and Power Management), which performs all device-level >> tasks associated with

Re: [PATCH] phy: fix the bug when remove the phy driver

On 2016/8/3 10:41, Florian Fainelli wrote: > On August 2, 2016 6:21:52 PM MST, Ding Tianhong > wrote: >> On 2016/8/3 0:42, Florian Fainelli wrote: >>> Le 02/08/2016 à 06:00, Ding Tianhong a écrit : The nic in my board use the phy dev from marvell, and the system will load the marvell

Re: [PATCH 2/2] soc: nxp: Add a RCPM driver

On Mon, Aug 1, 2016 at 8:25 PM, Arnd Bergmann wrote: > On Monday, August 1, 2016 5:49:03 PM CEST Chenhui Zhao wrote: >> The NXP's QorIQ Processors based on ARM Core have a RCPM module >> (Run Control and Power Management), which performs all device-level >> tasks associated with power management.

Re: [PATCH] uprobe: Add uprobe_pre/post_sstep_notifier to NOKPROBE_SYMBOL

Hi Masami, On 03/08/2016:12:45:24 AM, Masami Hiramatsu wrote: > On Tue, 2 Aug 2016 12:14:06 +0530 > Pratyush Anand wrote: > > > uprobe_pre_sstep_notifier and uprobe_post_sstep_notifier are called from > > debug exception handler, so blacklist them for kprobing. > >

Re: [PATCH] uprobe: Add uprobe_pre/post_sstep_notifier to NOKPROBE_SYMBOL

Hi Masami, On 03/08/2016:12:45:24 AM, Masami Hiramatsu wrote: > On Tue, 2 Aug 2016 12:14:06 +0530 > Pratyush Anand wrote: > > > uprobe_pre_sstep_notifier and uprobe_post_sstep_notifier are called from > > debug exception handler, so blacklist them for kprobing. > > Actually, these exception

[v9.2 PATCH 3/6] phy: Add USB Type-C PHY driver for rk3399

Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB Type-C PHY is designed to support the USB3 and DP applications. The PHY basically has two main components: USB3 and DisplyPort. USB3 operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2 data rates. Hence, create 2

[v9.2 PATCH 3/6] phy: Add USB Type-C PHY driver for rk3399

Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB Type-C PHY is designed to support the USB3 and DP applications. The PHY basically has two main components: USB3 and DisplyPort. USB3 operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2 data rates. Hence, create 2

Re: [PATCH -next v2] virtio: fix possible memory leak in virtqueue_add()

On Tue, Aug 02, 2016 at 02:16:31PM +, Wei Yongjun wrote: > 'desc' is malloced in virtqueue_add() and should be freed before > leaving from the error handling cases, otherwise it will cause > memory leak. > > Signed-off-by: Wei Yongjun Appliecd except I moved this to

Re: [PATCH -next v2] virtio: fix possible memory leak in virtqueue_add()

On Tue, Aug 02, 2016 at 02:16:31PM +, Wei Yongjun wrote: > 'desc' is malloced in virtqueue_add() and should be freed before > leaving from the error handling cases, otherwise it will cause > memory leak. > > Signed-off-by: Wei Yongjun Appliecd except I moved this to before END_USE - seems

[PATCH] virtio: fix error handling for debug builds

On error, virtqueue_add calls START_USE but not END_USE. Thankfully that's normally empty anyway, but might not be when debugging. Fix it up. Signed-off-by: Michael S. Tsirkin --- drivers/virtio/virtio_ring.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] virtio: fix error handling for debug builds

On error, virtqueue_add calls START_USE but not END_USE. Thankfully that's normally empty anyway, but might not be when debugging. Fix it up. Signed-off-by: Michael S. Tsirkin --- drivers/virtio/virtio_ring.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/virtio/virtio_ring.c

Re: [PATCH] uprobe: Add uprobe_pre/post_sstep_notifier to NOKPROBE_SYMBOL

Hi Oleg, On 02/08/2016:10:30:35 PM, Oleg Nesterov wrote: > On 08/02, Pratyush Anand wrote: > > > > uprobe_pre_sstep_notifier and uprobe_post_sstep_notifier are called from > > debug exception handler, so blacklist them for kprobing. > > Let me add kprobes maintainers, I am a bit confused... > >

Re: [PATCH] uprobe: Add uprobe_pre/post_sstep_notifier to NOKPROBE_SYMBOL

Hi Oleg, On 02/08/2016:10:30:35 PM, Oleg Nesterov wrote: > On 08/02, Pratyush Anand wrote: > > > > uprobe_pre_sstep_notifier and uprobe_post_sstep_notifier are called from > > debug exception handler, so blacklist them for kprobing. > > Let me add kprobes maintainers, I am a bit confused... > >

Re: [PATCH] Support resetting WARN*_ONCE

Hi Andi, [auto build test ERROR on asm-generic/master] [also build test ERROR on v4.7 next-20160802] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Andi-Kleen/Support-resetting-WARN-_ONCE

Re: [PATCH] Support resetting WARN*_ONCE

Hi Andi, [auto build test ERROR on asm-generic/master] [also build test ERROR on v4.7 next-20160802] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Andi-Kleen/Support-resetting-WARN-_ONCE

Re: [PATCH stable 4.6+] radix-tree: account nodes to memcg only if explicitly requested

On Tue, Aug 02, 2016 at 03:45:34PM +0300, Vladimir Davydov wrote: > Radix trees may be used not only for storing page cache pages, so > unconditionally accounting radix tree nodes to the current memory cgroup > is bad: if a radix tree node is used for storing data shared among > different cgroups

Re: [PATCH stable 4.6+] radix-tree: account nodes to memcg only if explicitly requested

On Tue, Aug 02, 2016 at 03:45:34PM +0300, Vladimir Davydov wrote: > Radix trees may be used not only for storing page cache pages, so > unconditionally accounting radix tree nodes to the current memory cgroup > is bad: if a radix tree node is used for storing data shared among > different cgroups

[PATCH v6 0/2] Input: SiS 9200 family I2C touchscreen controller driver

Hi, Here are the v6 patches for SiS 9200 I2C multitouch controller. Cleanups, fixes and simplifications from the last review are included. Rebased to 4.7. Thanks, Mika [PATCH v6 1/2] Input: Driver for SiS-9200 family I2C touchscreen controller [PATCH v6 2/2] Input: SiS 9200 documentation parts

[PATCH v6 0/2] Input: SiS 9200 family I2C touchscreen controller driver

Hi, Here are the v6 patches for SiS 9200 I2C multitouch controller. Cleanups, fixes and simplifications from the last review are included. Rebased to 4.7. Thanks, Mika [PATCH v6 1/2] Input: Driver for SiS-9200 family I2C touchscreen controller [PATCH v6 2/2] Input: SiS 9200 documentation parts

Re: [PATCH RESEND v4] locking/pvqspinlock: Fix double hash race

On 07/27/2016 07:30 AM, Wanpeng Li wrote: From: Wanpeng Li When the lock holder vCPU is racing with the queue head vCPU: lock holder vCPU queue head vCPU === node->locked = 1;

Re: [PATCH RESEND v4] locking/pvqspinlock: Fix double hash race

On 07/27/2016 07:30 AM, Wanpeng Li wrote: From: Wanpeng Li When the lock holder vCPU is racing with the queue head vCPU: lock holder vCPU queue head vCPU === node->locked = 1; READ_ONCE(node->locked) ...

linux-next: Tree for Aug 3

Hi all, Please do not add material destined for v4.9 to your linux-next included branches until after v4.8-rc1 has been released. Changes since 20160802: My fixes tree is empty again. Non-merge commits (relative to Linus' tree): 1166 1375 files changed, 45683 insertions(+), 12773 deletions

[PATCH 2/2] KVM: lapic: don't recalculate apic map table twice when enabling LAPIC

From: Wanpeng Li APIC map table is recalculated during reset APIC ID to the initial value when enabling LAPIC. This patch move the recalculate_apic_map() to the next branch since we don't need to recalculate apic map twice in current codes. Cc: Paolo Bonzini

[PATCH 1/2] KVM: lapic: fix access preemption timer stuff even if kernel_irqchip=off

From: Wanpeng Li BUG: unable to handle kernel NULL pointer dereference at 008c IP: [] kvm_lapic_hv_timer_in_use+0x10/0x20 [kvm] PGD 0 Oops: [#1] SMP Call Trace: kvm_arch_vcpu_load+0x86/0x260 [kvm] vcpu_load+0x46/0x60 [kvm] kvm_vcpu_ioctl+0x79/0x7c0

linux-next: Tree for Aug 3

Hi all, Please do not add material destined for v4.9 to your linux-next included branches until after v4.8-rc1 has been released. Changes since 20160802: My fixes tree is empty again. Non-merge commits (relative to Linus' tree): 1166 1375 files changed, 45683 insertions(+), 12773 deletions

[PATCH 2/2] KVM: lapic: don't recalculate apic map table twice when enabling LAPIC

From: Wanpeng Li APIC map table is recalculated during reset APIC ID to the initial value when enabling LAPIC. This patch move the recalculate_apic_map() to the next branch since we don't need to recalculate apic map twice in current codes. Cc: Paolo Bonzini Cc: Radim Krčmář Signed-off-by:

[PATCH 1/2] KVM: lapic: fix access preemption timer stuff even if kernel_irqchip=off

From: Wanpeng Li BUG: unable to handle kernel NULL pointer dereference at 008c IP: [] kvm_lapic_hv_timer_in_use+0x10/0x20 [kvm] PGD 0 Oops: [#1] SMP Call Trace: kvm_arch_vcpu_load+0x86/0x260 [kvm] vcpu_load+0x46/0x60 [kvm] kvm_vcpu_ioctl+0x79/0x7c0 [kvm] ?

Re: [GIT PULL] KVM changes for 4.8 merge window

Paolo Bonzini writes: ... > - arch/powerpc: what a mess. For the idle_book3s.S conflict, the KVM > tree is the right one; everything else is trivial. In this case I am > not quite sure what went wrong. The commit that is causing the mess > (fd7bacbca47a, "KVM: PPC: Book3S

Re: [GIT PULL] KVM changes for 4.8 merge window

Paolo Bonzini writes: ... > - arch/powerpc: what a mess. For the idle_book3s.S conflict, the KVM > tree is the right one; everything else is trivial. In this case I am > not quite sure what went wrong. The commit that is causing the mess > (fd7bacbca47a, "KVM: PPC: Book3S HV: Fix TB corruption

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

Al Viro wrote: > > Which just might mean that we have *three* issues here - > (1) buggered __copy_to_user_inatomic() (and friends) on some sparcs > (2) your ssl-only corruption > (3) Alan's x86_64 corruption on plain TCP read - no ssl *or* sparc > anywhere, and no multi-segment

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

Al Viro wrote: > > Which just might mean that we have *three* issues here - > (1) buggered __copy_to_user_inatomic() (and friends) on some sparcs > (2) your ssl-only corruption > (3) Alan's x86_64 corruption on plain TCP read - no ssl *or* sparc > anywhere, and no multi-segment

Re: perf test BPF failing on f24: fix

On 2016/8/3 10:41, Wangnan (F) wrote: On 2016/8/3 3:51, Arnaldo Carvalho de Melo wrote: Hi Wang, Something changed and a function used in a perf test for BPF is not anymore appearing on vmlinux, albeit still available on /proc/kallsyms: # readelf -wi /lib/modules/4.7.0+/build/vmlinux

Re: perf test BPF failing on f24: fix

On 2016/8/3 10:41, Wangnan (F) wrote: On 2016/8/3 3:51, Arnaldo Carvalho de Melo wrote: Hi Wang, Something changed and a function used in a perf test for BPF is not anymore appearing on vmlinux, albeit still available on /proc/kallsyms: # readelf -wi /lib/modules/4.7.0+/build/vmlinux

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, 2 Aug 2016 22:31:25 -0500 Josh Poimboeuf wrote: > Yeah, we do need to add a parameter to ftrace_push_return_trace(). But > callers which don't implement it could just pass zero like they do with > 'fp'. > Right, if zero is passed in, then just ignore it. Bed

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, 2 Aug 2016 22:31:25 -0500 Josh Poimboeuf wrote: > Yeah, we do need to add a parameter to ftrace_push_return_trace(). But > callers which don't implement it could just pass zero like they do with > 'fp'. > Right, if zero is passed in, then just ignore it. Bed time! -- Steve

RE: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to include/linux/fsl

Hi Uffe, > -Original Message- > From: Scott Wood [mailto:o...@buserror.net] > Sent: Wednesday, August 03, 2016 5:41 AM > To: Yangbo Lu; Michael Ellerman; Arnd Bergmann; Ulf Hansson > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org;

RE: [PATCH v11 4/5] powerpc/fsl: move mpc85xx.h to include/linux/fsl

Hi Uffe, > -Original Message- > From: Scott Wood [mailto:o...@buserror.net] > Sent: Wednesday, August 03, 2016 5:41 AM > To: Yangbo Lu; Michael Ellerman; Arnd Bergmann; Ulf Hansson > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org;

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, 2 Aug 2016 22:12:33 -0500 Josh Poimboeuf wrote: > Sounds good. I was thinking I could also add a similar define to > indicate whether an arch passes the return address stack pointer to > ftrace_push_return_trace(). HAVE_FUNCTION_GRAPH_RET_ADDR_PTR? > If you are

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, 2 Aug 2016 22:12:33 -0500 Josh Poimboeuf wrote: > Sounds good. I was thinking I could also add a similar define to > indicate whether an arch passes the return address stack pointer to > ftrace_push_return_trace(). HAVE_FUNCTION_GRAPH_RET_ADDR_PTR? > If you are making this function

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, Aug 02, 2016 at 11:21:04PM -0400, Steven Rostedt wrote: > On Tue, 2 Aug 2016 23:18:57 -0400 > Steven Rostedt wrote: > > > On Tue, 2 Aug 2016 22:12:33 -0500 > > Josh Poimboeuf wrote: > > > > > > > Sounds good. I was thinking I could also add a

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, Aug 02, 2016 at 11:21:04PM -0400, Steven Rostedt wrote: > On Tue, 2 Aug 2016 23:18:57 -0400 > Steven Rostedt wrote: > > > On Tue, 2 Aug 2016 22:12:33 -0500 > > Josh Poimboeuf wrote: > > > > > > > Sounds good. I was thinking I could also add a similar define to > > > indicate whether

Re: [PATCH 2/2] soc: nxp: Add a RCPM driver

On Mon, Aug 1, 2016 at 9:22 PM, Marc Zyngier wrote: > > On 01/08/16 10:49, Chenhui Zhao wrote: > > The NXP's QorIQ Processors based on ARM Core have a RCPM module > > (Run Control and Power Management), which performs all device-level > > tasks associated with power

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, Aug 02, 2016 at 11:18:57PM -0400, Steven Rostedt wrote: > On Tue, 2 Aug 2016 22:12:33 -0500 > Josh Poimboeuf wrote: > > > > Sounds good. I was thinking I could also add a similar define to > > indicate whether an arch passes the return address stack pointer to > >

Re: [PATCH 2/2] soc: nxp: Add a RCPM driver

On Mon, Aug 1, 2016 at 9:22 PM, Marc Zyngier wrote: > > On 01/08/16 10:49, Chenhui Zhao wrote: > > The NXP's QorIQ Processors based on ARM Core have a RCPM module > > (Run Control and Power Management), which performs all device-level > > tasks associated with power management. > > > > This patch

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, Aug 02, 2016 at 11:18:57PM -0400, Steven Rostedt wrote: > On Tue, 2 Aug 2016 22:12:33 -0500 > Josh Poimboeuf wrote: > > > > Sounds good. I was thinking I could also add a similar define to > > indicate whether an arch passes the return address stack pointer to > >

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

"Luis R. Rodriguez" writes: > Are linux-next builds being tested for powerpc with allyesconfig and > allmodconfig ? Yes, every single version: http://kisskb.ellerman.id.au/kisskb/target/2659/ > I have some changes I'm making and while debugging my > build issues I decided

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

"Luis R. Rodriguez" writes: > Are linux-next builds being tested for powerpc with allyesconfig and > allmodconfig ? Yes, every single version: http://kisskb.ellerman.id.au/kisskb/target/2659/ > I have some changes I'm making and while debugging my > build issues I decided to give a clean

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, 2 Aug 2016 23:18:57 -0400 Steven Rostedt wrote: > On Tue, 2 Aug 2016 22:12:33 -0500 > Josh Poimboeuf wrote: > > > > Sounds good. I was thinking I could also add a similar define to > > indicate whether an arch passes the return address stack

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, 2 Aug 2016 23:18:57 -0400 Steven Rostedt wrote: > On Tue, 2 Aug 2016 22:12:33 -0500 > Josh Poimboeuf wrote: > > > > Sounds good. I was thinking I could also add a similar define to > > indicate whether an arch passes the return address stack pointer to > > ftrace_push_return_trace().

[git pull] drm zpos property support

Hi Linus, This tree was waiting on some media stuff I hadn't had time to get a stable branchpoint off, so I just waited until it was all in your tree first, it's been around a bit on the list and shouldn't affect anything outside adding the generic API and moving some ARM drivers to using it.

[git pull] drm zpos property support

Hi Linus, This tree was waiting on some media stuff I hadn't had time to get a stable branchpoint off, so I just waited until it was all in your tree first, it's been around a bit on the list and shouldn't affect anything outside adding the generic API and moving some ARM drivers to using it.

Re: [v9.1 PATCH 3/6] phy: Add USB Type-C PHY driver for rk3399

On Tue, Aug 2, 2016 at 7:03 PM, Chris Zhong wrote: > Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB > Type-C PHY is designed to support the USB3 and DP applications. The > PHY basically has two main components: USB3 and DisplyPort. USB3 > operates in

Re: [v9.1 PATCH 3/6] phy: Add USB Type-C PHY driver for rk3399

On Tue, Aug 2, 2016 at 7:03 PM, Chris Zhong wrote: > Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB > Type-C PHY is designed to support the USB3 and DP applications. The > PHY basically has two main components: USB3 and DisplyPort. USB3 > operates in SuperSpeed mode and the DP

Re: [PATCH v4 1/2] Documentation: kdump: remind user of nr_cpus

Hi Wenjian, On 08/03/16 at 10:31am, Zhou Wenjian wrote: > v3->v4: update the description of bring up SMP dump-capture kernel > v2->v3: add description of nr_cpus. > v1->v2: change nr_cpus to maxcpus > > nr_cpus can help to save memory. So we should remind user of it. > > Signed-off-by: Zhou

Re: [PATCH v4 1/2] Documentation: kdump: remind user of nr_cpus

Hi Wenjian, On 08/03/16 at 10:31am, Zhou Wenjian wrote: > v3->v4: update the description of bring up SMP dump-capture kernel > v2->v3: add description of nr_cpus. > v1->v2: change nr_cpus to maxcpus > > nr_cpus can help to save memory. So we should remind user of it. > > Signed-off-by: Zhou

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, Aug 02, 2016 at 10:59:36PM -0400, Steven Rostedt wrote: > On Tue, 2 Aug 2016 21:50:12 -0500 > Josh Poimboeuf wrote: > > > > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h > > index 1e814ae..fc508a7 100644 > > --- a/include/linux/ftrace.h > > +++

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, Aug 02, 2016 at 10:59:36PM -0400, Steven Rostedt wrote: > On Tue, 2 Aug 2016 21:50:12 -0500 > Josh Poimboeuf wrote: > > > > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h > > index 1e814ae..fc508a7 100644 > > --- a/include/linux/ftrace.h > > +++ b/include/linux/ftrace.h >

Private Message

I once again try to notify you as my earlier letter was returned undelivered. In the said letter, you were bequeathed by late Client. Kindly get in touch J. O'Neill Sole Principal

Private Message

I once again try to notify you as my earlier letter was returned undelivered. In the said letter, you were bequeathed by late Client. Kindly get in touch J. O'Neill Sole Principal

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, 2 Aug 2016 21:50:12 -0500 Josh Poimboeuf wrote: > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h > index 1e814ae..fc508a7 100644 > --- a/include/linux/ftrace.h > +++ b/include/linux/ftrace.h > @@ -795,7 +795,9 @@ struct ftrace_ret_stack { >

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, 2 Aug 2016 21:50:12 -0500 Josh Poimboeuf wrote: > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h > index 1e814ae..fc508a7 100644 > --- a/include/linux/ftrace.h > +++ b/include/linux/ftrace.h > @@ -795,7 +795,9 @@ struct ftrace_ret_stack { > unsigned long func; >

Re: perf test BPF failing on f24: fix

On Tue, Aug 02, 2016 at 11:15:34PM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Aug 02, 2016 at 02:03:33PM -0700, Alexei Starovoitov escreveu: > > On Tue, Aug 02, 2016 at 04:51:02PM -0300, Arnaldo Carvalho de Melo wrote: > > > Hi Wang, > > > > > > Something changed and a function used in a

Re: perf test BPF failing on f24: fix

On Tue, Aug 02, 2016 at 11:15:34PM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Aug 02, 2016 at 02:03:33PM -0700, Alexei Starovoitov escreveu: > > On Tue, Aug 02, 2016 at 04:51:02PM -0300, Arnaldo Carvalho de Melo wrote: > > > Hi Wang, > > > > > > Something changed and a function used in a

"Failed to create /dev/root: -14" after commit e6978e4bf1 ("ARM: save and reset the address limit when entering an exception")

Hi, I see the following crash when running a qemu arm 'kzm' runtime test with the current mainline. Failed to create /dev/root: -14 [ followed by panic ] A complete log file is at [1]. Bisect points to commit e6978e4bf1 ("ARM: save and reset the address limit when entering an exception").

"Failed to create /dev/root: -14" after commit e6978e4bf1 ("ARM: save and reset the address limit when entering an exception")

Hi, I see the following crash when running a qemu arm 'kzm' runtime test with the current mainline. Failed to create /dev/root: -14 [ followed by panic ] A complete log file is at [1]. Bisect points to commit e6978e4bf1 ("ARM: save and reset the address limit when entering an exception").

Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template

On 2016年08月02日 16:27, Johannes Berg wrote: This explicitly configures *HT capability* though - that's even the name of the parameter. If you enable HT40 in the capability, the resulting BSS might still not actually *use* 40 MHz bandwidth, as required by overlapping BSS detection. OK, I see.

Re: [GIT PULL] KVM changes for 4.8 merge window

On Tue, 2 Aug 2016 16:17:39 -0400 Linus Torvalds wrote: > On Tue, Aug 2, 2016 at 2:42 PM, Linus Torvalds > wrote: > > > > No, I don't use the merge from linux-next directly. I just re-generate > > the merge myself, and if the pull

[ANNOUNCE]: SCST 3.2 pre-release freeze

Hi All, I'm glad to announce SCST 3.2 pre-release code freeze in the SCST SVN branch 3.2.x. You can get it by command: $ svn co https://scst.svn.sourceforge.net/svnroot/scst/branches/3.2.x It is going to be released after few weeks of testing, if no significant issues found. SCST is

Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template

On 2016年08月02日 16:27, Johannes Berg wrote: This explicitly configures *HT capability* though - that's even the name of the parameter. If you enable HT40 in the capability, the resulting BSS might still not actually *use* 40 MHz bandwidth, as required by overlapping BSS detection. OK, I see.

Re: [GIT PULL] KVM changes for 4.8 merge window

On Tue, 2 Aug 2016 16:17:39 -0400 Linus Torvalds wrote: > On Tue, Aug 2, 2016 at 2:42 PM, Linus Torvalds > wrote: > > > > No, I don't use the merge from linux-next directly. I just re-generate > > the merge myself, and if the pull request then includes a merge > > resolution (either as just a

[ANNOUNCE]: SCST 3.2 pre-release freeze

Hi All, I'm glad to announce SCST 3.2 pre-release code freeze in the SCST SVN branch 3.2.x. You can get it by command: $ svn co https://scst.svn.sourceforge.net/svnroot/scst/branches/3.2.x It is going to be released after few weeks of testing, if no significant issues found. SCST is

Re: [PATCH] perf/core: Add a tracepoint for perf sampling

On Fri, Jul 29, 2016 at 8:34 PM, Wangnan (F) wrote: > > > On 2016/7/30 2:05, Brendan Gregg wrote: >> >> On Tue, Jul 19, 2016 at 4:20 PM, Brendan Gregg wrote: >>> >>> When perf is performing hrtimer-based sampling, this tracepoint can be >>> used >>> by

Re: [PATCH] perf/core: Add a tracepoint for perf sampling

On Fri, Jul 29, 2016 at 8:34 PM, Wangnan (F) wrote: > > > On 2016/7/30 2:05, Brendan Gregg wrote: >> >> On Tue, Jul 19, 2016 at 4:20 PM, Brendan Gregg wrote: >>> >>> When perf is performing hrtimer-based sampling, this tracepoint can be >>> used >>> by BPF to run additional logic on each sample.

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, Aug 02, 2016 at 10:30:11PM -0400, Steven Rostedt wrote: > On Tue, 2 Aug 2016 20:56:56 -0500 > Josh Poimboeuf wrote: > > > It's not specific to NMIs. The problem is that dump_trace() is starting > > from the frame pointed to by a pt_regs, rather than the current

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, Aug 02, 2016 at 10:30:11PM -0400, Steven Rostedt wrote: > On Tue, 2 Aug 2016 20:56:56 -0500 > Josh Poimboeuf wrote: > > > It's not specific to NMIs. The problem is that dump_trace() is starting > > from the frame pointed to by a pt_regs, rather than the current frame. > > Instead of

[PATCH v2 2/3] samples/bpf: Add a sampling BPF example

This example samples the instruction pointer at a timed interval, and frequency counts it in a BPF map. It is an example of summarizing sampled data in-kernel for passing to user space. It uses the perf:perf_hrtimer tracepoint with perf_events sampling. Example output: Sampling at 99 Hertz for 5

[PATCH v2 2/3] samples/bpf: Add a sampling BPF example

This example samples the instruction pointer at a timed interval, and frequency counts it in a BPF map. It is an example of summarizing sampled data in-kernel for passing to user space. It uses the perf:perf_hrtimer tracepoint with perf_events sampling. Example output: Sampling at 99 Hertz for 5

  1   2   3   4   5   6   7   8   9   10   >