[PATCH 03/13] perf/core: Update perf_*_sample() to include perf_arch_regs

perf_prepare_sample is extended to include the perf_arch_regs_mask in the sample header size calculation. Update perf_output_sample() to dump the perf_arch_regs_mask to sample output. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Jiri Olsa Cc: Arnaldo Carvalho de Melo Cc:

[PATCH 06/13] powerpc/perf: Add support for perf_arch_regs in powerpc

Patch defines struct perf_arch_regs{} for powerpc and update the per-cpu perf pmu structure to include perf_arch_regs bits. perf_arch_reg_value(), perf_get_arch_reg() and perf_get_arch_regs_mask() are implemented to return proper values for powerpc. Finally adds code to call the processor specific

[PATCH 09/13] powerpc/perf: Add support for perf_arch_regs for PPC970 processor

Add code to define support functions and registers mask for PPC970 processor. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Jiri Olsa Cc: Arnaldo Carvalho de Melo Cc: Stephane Eranian Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Benjamin Herrenschmidt Cc:

[PATCH 04/13] perf/core: Extend perf_output_sample_regs() to include perf_arch_regs

Extend perf_output_sample_regs() to take in perf_regs structure as a parameter instead of pt_regs. Add code to check for arch_regs_mask and dump the arch registers to the output sample. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Jiri Olsa Cc: Arnaldo Carvalho de Melo Cc:

[PATCH 02/13] perf/core: Extend perf_sample_regs_intr() to include perf_arch_regs update

Extend perf_sample_regs_intr() to support the updates needed for perf_arch_reg structure and perf_arch_regs_mask. Also add code to init the arch_regs_mask to zero incase of regs_user in perf_sample_regs_user(). Ideally this should be done in perf_sample_data_init, but due to commit 2565711fb7d7

[PATCH 00/13] Add support for perf_arch_regs

Patchset to extend PERF_SAMPLE_REGS_INTR to include platform specific PMU registers. Patchset applies cleanly on tip:perf/core branch It's a perennial request from hardware folks to be able to see the raw values of the pmu registers. Partly it's so that they can verify perf is doing what they

[PATCH 01/13] perf/core: Add perf_arch_regs and mask to perf_regs structure

It's a perennial request from hardware folks to be able to see the raw values of the pmu registers. Partly it's so that they can verify perf is doing what they want, and some of it is that they're interested in some of the more obscure info that isn't plumbed out through other perf interfaces.

[PATCH 02/13] perf/core: Extend perf_sample_regs_intr() to include perf_arch_regs update

Extend perf_sample_regs_intr() to support the updates needed for perf_arch_reg structure and perf_arch_regs_mask. Also add code to init the arch_regs_mask to zero incase of regs_user in perf_sample_regs_user(). Ideally this should be done in perf_sample_data_init, but due to commit 2565711fb7d7

[PATCH 00/13] Add support for perf_arch_regs

Patchset to extend PERF_SAMPLE_REGS_INTR to include platform specific PMU registers. Patchset applies cleanly on tip:perf/core branch It's a perennial request from hardware folks to be able to see the raw values of the pmu registers. Partly it's so that they can verify perf is doing what they

[PATCH 01/13] perf/core: Add perf_arch_regs and mask to perf_regs structure

It's a perennial request from hardware folks to be able to see the raw values of the pmu registers. Partly it's so that they can verify perf is doing what they want, and some of it is that they're interested in some of the more obscure info that isn't plumbed out through other perf interfaces.

Re: ARM,SoC: About the use DT-defined properties by 3rd-party drivers

On Wed, Aug 24, 2016 at 9:29 AM, Sebastian Frias wrote: > > If this is really not possible, it forces the SoC manufacturer to expose > those properties in a different way, thus wasting a (seemingly) perfectly > fine way of doing so: the DT and its documentation. When you submit

Re: ARM,SoC: About the use DT-defined properties by 3rd-party drivers

On Wed, Aug 24, 2016 at 9:29 AM, Sebastian Frias wrote: > > If this is really not possible, it forces the SoC manufacturer to expose > those properties in a different way, thus wasting a (seemingly) perfectly > fine way of doing so: the DT and its documentation. When you submit a new driver

[git pull] drm fixes for rc4 or 5

Hi, I probably missed -rc4 by minutes, but maybe pointless GPL enforcement debates are distracting you enough! Anyways, a bunch of fixes covering i915, amdgpu, one tegra and some core DRM ones. Nothing too strange at this point. Dave. The following changes since commit

[git pull] drm fixes for rc4 or 5

Hi, I probably missed -rc4 by minutes, but maybe pointless GPL enforcement debates are distracting you enough! Anyways, a bunch of fixes covering i915, amdgpu, one tegra and some core DRM ones. Nothing too strange at this point. Dave. The following changes since commit

[PATCH] nfsd: constify reply_cache_stats_operations structure

reply_cache_stats_operations, of type struct file_operations, is never modified, so declare it as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- fs/nfsd/nfsctl.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] nfsd: constify reply_cache_stats_operations structure

reply_cache_stats_operations, of type struct file_operations, is never modified, so declare it as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- fs/nfsd/nfsctl.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfsd/nfsctl.c

[PATCH] watchdog: iTCO_wdt: constify iTCO_wdt_pm structure

iTCO_wdt_pm, of type struct dev_pm_ops, is never modified, so declare it as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/watchdog/iTCO_wdt.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] watchdog: iTCO_wdt: constify iTCO_wdt_pm structure

iTCO_wdt_pm, of type struct dev_pm_ops, is never modified, so declare it as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/watchdog/iTCO_wdt.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/iTCO_wdt.c

Re: [patch 2/2] i2c: mux: mellanox: add driver

nce) to record what (public, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/vadimp-mellanox-com/i2c-add-master-driver-for-mellanox-systems/20160828-225625 base: ht

Re: [patch 2/2] i2c: mux: mellanox: add driver

nce) to record what (public, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/vadimp-mellanox-com/i2c-add-master-driver-for-mellanox-systems/20160828-225625 base: ht

Re: [Ksummit-discuss] checkkpatch (in)sanity ?

On Sun, 28 Aug 2016, Joe Perches wrote: > Are there other existing tools for blame history viewing? fugitive vim plugin has 'Gblame' command, which I personally find rather useful, and given the text-oriented nature could potentially be useful for your needs. -- Jiri Kosina SUSE Labs

Re: [Ksummit-discuss] checkkpatch (in)sanity ?

On Sun, 28 Aug 2016, Joe Perches wrote: > Are there other existing tools for blame history viewing? fugitive vim plugin has 'Gblame' command, which I personally find rather useful, and given the text-oriented nature could potentially be useful for your needs. -- Jiri Kosina SUSE Labs

[PATCH] scsi: constify sr_pm_ops structure

sr_pm_ops, of type struct dev_pm_ops, is never modified, so declare it as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/scsi/sr.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/sr.c

[PATCH] scsi: constify sr_pm_ops structure

sr_pm_ops, of type struct dev_pm_ops, is never modified, so declare it as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/scsi/sr.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c index

Re: Misuses of ** ? (was Re: [PATCH 1/1] ASoC: Intel: Atom: add a missing star in a memcpy call)

On Sun, 2016-08-28 at 21:38 +0200, Julia Lawall wrote: > On Sun, 28 Aug 2016, Nicolas Iooss wrote: > > On 28/08/16 19:50, Joe Perches wrote: > > > On Sun, 2016-08-28 at 19:39 +0200, Nicolas Iooss wrote: > > >> In sst_prepare_and_post_msg(), when a response is received in "block", > > >> the

Re: Misuses of ** ? (was Re: [PATCH 1/1] ASoC: Intel: Atom: add a missing star in a memcpy call)

On Sun, 2016-08-28 at 21:38 +0200, Julia Lawall wrote: > On Sun, 28 Aug 2016, Nicolas Iooss wrote: > > On 28/08/16 19:50, Joe Perches wrote: > > > On Sun, 2016-08-28 at 19:39 +0200, Nicolas Iooss wrote: > > >> In sst_prepare_and_post_msg(), when a response is received in "block", > > >> the

Re: [PATCH v2] arch: all: include: asm: bitops: Use bool instead of int for all bit test functions

ons/20160828-230301 config: m68k-allmodconfig (attached as .config) compiler: m68k-linux-gcc (GCC) 4.9.0 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .con

Re: [PATCH v2] arch: all: include: asm: bitops: Use bool instead of int for all bit test functions

ons/20160828-230301 config: m68k-allmodconfig (attached as .config) compiler: m68k-linux-gcc (GCC) 4.9.0 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .con

Re: [RFC 1/3] x86/vdso: create vdso file, use it for mapping

On Thu, Aug 25, 2016 at 06:21:08PM +0300, Dmitry Safonov wrote: > I added here a new in-kernel fs with ramfs-like options. > Created vdso file in this fs (yet for testing, only 64-bit vdso). > Mapped this file to process's mm on setup_additional_pages. > Just for testing purpose it's done only for

Re: [RFC 1/3] x86/vdso: create vdso file, use it for mapping

On Thu, Aug 25, 2016 at 06:21:08PM +0300, Dmitry Safonov wrote: > I added here a new in-kernel fs with ramfs-like options. > Created vdso file in this fs (yet for testing, only 64-bit vdso). > Mapped this file to process's mm on setup_additional_pages. > Just for testing purpose it's done only for

PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422

[1.] One line summary of the problem: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 [2.] Full description of the problem/report: No usb 3.0 devices are being detected when attached while USB 2.0 devices work on the same port. USB 3.0 works after applying patches [9.1] and [9.2], but

PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422

[1.] One line summary of the problem: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 [2.] Full description of the problem/report: No usb 3.0 devices are being detected when attached while USB 2.0 devices work on the same port. USB 3.0 works after applying patches [9.1] and [9.2], but

Re: [Ksummit-discuss] checkkpatch (in)sanity ?

On Sun, 2016-08-28 at 11:59 +0200, Julia Lawall wrote: > On Sun, 28 Aug 2016, Alexey Dobriyan wrote: [] > > The problem is that c-h.pl generates noise in the commit history and > > makes git-blame less useful than it can be. > > Could it be that this is a problem with git blame, rather than with

Re: [Ksummit-discuss] checkkpatch (in)sanity ?

On Sun, 2016-08-28 at 11:59 +0200, Julia Lawall wrote: > On Sun, 28 Aug 2016, Alexey Dobriyan wrote: [] > > The problem is that c-h.pl generates noise in the commit history and > > makes git-blame less useful than it can be. > > Could it be that this is a problem with git blame, rather than with

Re: Misuses of ** ? (was Re: [PATCH 1/1] ASoC: Intel: Atom: add a missing star in a memcpy call)

On Sun, 28 Aug 2016, Nicolas Iooss wrote: > On 28/08/16 19:50, Joe Perches wrote: > > On Sun, 2016-08-28 at 19:39 +0200, Nicolas Iooss wrote: > >> In sst_prepare_and_post_msg(), when a response is received in "block", > >> the following code gets executed: > >> > >> *data =

Re: Misuses of ** ? (was Re: [PATCH 1/1] ASoC: Intel: Atom: add a missing star in a memcpy call)

On Sun, 28 Aug 2016, Nicolas Iooss wrote: > On 28/08/16 19:50, Joe Perches wrote: > > On Sun, 2016-08-28 at 19:39 +0200, Nicolas Iooss wrote: > >> In sst_prepare_and_post_msg(), when a response is received in "block", > >> the following code gets executed: > >> > >> *data =

Re: perf: WARNING in perf_event_read

On 28 August 2016 at 20:03, Dmitry Vyukov wrote: > Hello, > > I've got the following WARNING while running syzkaller fuzzer: > > [ cut here ] > WARNING: CPU: 3 PID: 23874 at kernel/events/core.c:3554 Looks like the same as this, with patch from Jiri

Re: perf: WARNING in perf_event_read

On 28 August 2016 at 20:03, Dmitry Vyukov wrote: > Hello, > > I've got the following WARNING while running syzkaller fuzzer: > > [ cut here ] > WARNING: CPU: 3 PID: 23874 at kernel/events/core.c:3554 Looks like the same as this, with patch from Jiri Olsa:

Re: sound: division by 0 in snd_hrtimer_callback

On 28 August 2016 at 20:39, Dmitry Vyukov wrote: > Hello, > > The following program triggers divide error in snd_hrtimer_callback: > > divide error: [#1] SMP DEBUG_PAGEALLOC KASAN > Dumping ftrace buffer: >(ftrace buffer empty) > Modules linked in: > CPU: 3 PID: 17469

Re: sound: division by 0 in snd_hrtimer_callback

On 28 August 2016 at 20:39, Dmitry Vyukov wrote: > Hello, > > The following program triggers divide error in snd_hrtimer_callback: > > divide error: [#1] SMP DEBUG_PAGEALLOC KASAN > Dumping ftrace buffer: >(ftrace buffer empty) > Modules linked in: > CPU: 3 PID: 17469 Comm: syz-executor

[PATCH v2 1/1] ASoC: Intel: Atom: add a missing star in a memcpy call

In sst_prepare_and_post_msg(), when a response is received in "block", the following code gets executed: *data = kzalloc(block->size, GFP_KERNEL); memcpy(data, (void *) block->data, block->size); The memcpy() call overwrites the content of the *data pointer instead of filling the

[PATCH v2 1/1] ASoC: Intel: Atom: add a missing star in a memcpy call

In sst_prepare_and_post_msg(), when a response is received in "block", the following code gets executed: *data = kzalloc(block->size, GFP_KERNEL); memcpy(data, (void *) block->data, block->size); The memcpy() call overwrites the content of the *data pointer instead of filling the

drm: GPF in drm_context_switch_complete

Hello, The following program triggers GPF in drm_context_switch_complete: kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 1 PID: 1965 Comm:

drm: GPF in drm_context_switch_complete

Hello, The following program triggers GPF in drm_context_switch_complete: kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 1 PID: 1965 Comm:

Re: Misuses of ** ? (was Re: [PATCH 1/1] ASoC: Intel: Atom: add a missing star in a memcpy call)

On 28/08/16 19:50, Joe Perches wrote: > On Sun, 2016-08-28 at 19:39 +0200, Nicolas Iooss wrote: >> In sst_prepare_and_post_msg(), when a response is received in "block", >> the following code gets executed: >> >> *data = kzalloc(block->size, GFP_KERNEL); >> memcpy(data, (void *)

Re: Misuses of ** ? (was Re: [PATCH 1/1] ASoC: Intel: Atom: add a missing star in a memcpy call)

On 28/08/16 19:50, Joe Perches wrote: > On Sun, 2016-08-28 at 19:39 +0200, Nicolas Iooss wrote: >> In sst_prepare_and_post_msg(), when a response is received in "block", >> the following code gets executed: >> >> *data = kzalloc(block->size, GFP_KERNEL); >> memcpy(data, (void *)

drm: GPF in drm_legacy_lock_free

Hello, The following program trigger GPF in drm_legacy_lock_free: general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN Modules linked in: CPU: 2 PID: 3379 Comm: syz-executor Not tainted 4.8.0-rc3+ #35 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task:

Re: [PATCH] tpm: fix a race condition in tpm2_unseal_trusted()

On Sun, Aug 28, 2016 at 08:36:52AM +0200, Jarkko Sakkinen wrote: > > @@ -576,7 +576,8 @@ static int tpm2_load(struct tpm_chip *chip, > goto out; > } > > - rc = tpm_transmit_cmd(chip, buf.data, PAGE_SIZE, "loading blob"); > + rc = tpm_transmit_cmd(chip, buf.data,

drm: GPF in drm_legacy_lock_free

Hello, The following program trigger GPF in drm_legacy_lock_free: general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN Modules linked in: CPU: 2 PID: 3379 Comm: syz-executor Not tainted 4.8.0-rc3+ #35 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task:

Re: [PATCH] tpm: fix a race condition in tpm2_unseal_trusted()

On Sun, Aug 28, 2016 at 08:36:52AM +0200, Jarkko Sakkinen wrote: > > @@ -576,7 +576,8 @@ static int tpm2_load(struct tpm_chip *chip, > goto out; > } > > - rc = tpm_transmit_cmd(chip, buf.data, PAGE_SIZE, "loading blob"); > + rc = tpm_transmit_cmd(chip, buf.data,

sound: division by 0 in snd_hrtimer_callback

Hello, The following program triggers divide error in snd_hrtimer_callback: divide error: [#1] SMP DEBUG_PAGEALLOC KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 3 PID: 17469 Comm: syz-executor Not tainted 4.8.0-rc3+ #33 Hardware name: QEMU Standard PC (i440FX

sound: division by 0 in snd_hrtimer_callback

Hello, The following program triggers divide error in snd_hrtimer_callback: divide error: [#1] SMP DEBUG_PAGEALLOC KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 3 PID: 17469 Comm: syz-executor Not tainted 4.8.0-rc3+ #33 Hardware name: QEMU Standard PC (i440FX

Re: [PATCH 1/5] IA64-IRQ: Use kmalloc_array() in sn_irq_lh_init()

On Sun, 2016-08-28 at 11:28 +0200, Julia Lawall wrote: > I do think that there is some value in doing similar things in a uniform > way, using meaningful names, even if in a particular case it doesn't help > performance or reduce code size.  Even duplicating code could be OK if it > is not in a

Re: [PATCH 1/5] IA64-IRQ: Use kmalloc_array() in sn_irq_lh_init()

On Sun, 2016-08-28 at 11:28 +0200, Julia Lawall wrote: > I do think that there is some value in doing similar things in a uniform > way, using meaningful names, even if in a particular case it doesn't help > performance or reduce code size.  Even duplicating code could be OK if it > is not in a

Re: [PATCH 1/1] ASoC: Intel: Atom: add a missing star in a memcpy call

On 28/08/16 20:17, Joe Perches wrote: > On Sun, 2016-08-28 at 19:39 +0200, Nicolas Iooss wrote: >> In sst_prepare_and_post_msg(), when a response is received in "block", >> the following code gets executed: >> >> *data = kzalloc(block->size, GFP_KERNEL); >> memcpy(data, (void *)

Re: [PATCH 1/1] ASoC: Intel: Atom: add a missing star in a memcpy call

On 28/08/16 20:17, Joe Perches wrote: > On Sun, 2016-08-28 at 19:39 +0200, Nicolas Iooss wrote: >> In sst_prepare_and_post_msg(), when a response is received in "block", >> the following code gets executed: >> >> *data = kzalloc(block->size, GFP_KERNEL); >> memcpy(data, (void *)

Re: [PATCH] selftests/x86: fix spelling mistake "preseve" -> "preserve"

On Sun, Aug 28, 2016 at 3:51 AM, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistakes in printf messages. Acked-by: Andy Lutomirski

Re: [PATCH] selftests/x86: fix spelling mistake "preseve" -> "preserve"

On Sun, Aug 28, 2016 at 3:51 AM, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistakes in printf messages. Acked-by: Andy Lutomirski

[PATCH] x86/topology: Fallback to SMT level only once

Jirka, Peter and Jean-Pierre reported performance drop on some cpus after making cpu offline and online again. The reason is the kernel logic that falls back to SMT level topology if more than one node is detected within CPU package. During the system boot this logic cuts out the DIE topology

[PATCH] x86/topology: Fallback to SMT level only once

Jirka, Peter and Jean-Pierre reported performance drop on some cpus after making cpu offline and online again. The reason is the kernel logic that falls back to SMT level topology if more than one node is detected within CPU package. During the system boot this logic cuts out the DIE topology

Re: [PATCH 1/1] ASoC: Intel: Atom: add a missing star in a memcpy call

On Sun, 2016-08-28 at 19:39 +0200, Nicolas Iooss wrote: > In sst_prepare_and_post_msg(), when a response is received in "block", > the following code gets executed: > > *data = kzalloc(block->size, GFP_KERNEL); > memcpy(data, (void *) block->data, block->size); > > The memcpy() call

Re: [PATCH 1/1] ASoC: Intel: Atom: add a missing star in a memcpy call

On Sun, 2016-08-28 at 19:39 +0200, Nicolas Iooss wrote: > In sst_prepare_and_post_msg(), when a response is received in "block", > the following code gets executed: > > *data = kzalloc(block->size, GFP_KERNEL); > memcpy(data, (void *) block->data, block->size); > > The memcpy() call

Re: chipidea: udc: kernel panic in isr_setup_status_phase

On Sat, Aug 27, 2016 at 01:21:52AM +0800, Peter Chen wrote: > The gadget triggers UI interrupt due to host sends packet. > > I really can't understand that, why host does not send bus reset > before sending packet (eg, GET_DESCRIPTOR)? It violates USB spec. > > Are you sure the first interrupt

Re: chipidea: udc: kernel panic in isr_setup_status_phase

On Sat, Aug 27, 2016 at 01:21:52AM +0800, Peter Chen wrote: > The gadget triggers UI interrupt due to host sends packet. > > I really can't understand that, why host does not send bus reset > before sending packet (eg, GET_DESCRIPTOR)? It violates USB spec. > > Are you sure the first interrupt

Re: [tip:perf/core] perf/core: Check return value of the perf_event_read() IPI

On Mon, Aug 22, 2016 at 12:38:23PM +0200, Jiri Olsa wrote: > On Mon, Aug 22, 2016 at 10:29:32AM +0200, Jiri Olsa wrote: > > On Mon, Aug 22, 2016 at 09:17:37AM +0200, Jiri Olsa wrote: > > > On Sun, Aug 21, 2016 at 02:10:07PM +0200, Vegard Nossum wrote: > > > > > > SNIP > > > > > > > [] ?

Re: [tip:perf/core] perf/core: Check return value of the perf_event_read() IPI

On Mon, Aug 22, 2016 at 12:38:23PM +0200, Jiri Olsa wrote: > On Mon, Aug 22, 2016 at 10:29:32AM +0200, Jiri Olsa wrote: > > On Mon, Aug 22, 2016 at 09:17:37AM +0200, Jiri Olsa wrote: > > > On Sun, Aug 21, 2016 at 02:10:07PM +0200, Vegard Nossum wrote: > > > > > > SNIP > > > > > > > [] ?

perf: WARNING in perf_event_read

Hello, I've got the following WARNING while running syzkaller fuzzer: [ cut here ] WARNING: CPU: 3 PID: 23874 at kernel/events/core.c:3554 CPU: 3 PID: 23874 Comm: syz-executor Not tainted 4.8.0-rc3+ #31 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs

perf: WARNING in perf_event_read

Hello, I've got the following WARNING while running syzkaller fuzzer: [ cut here ] WARNING: CPU: 3 PID: 23874 at kernel/events/core.c:3554 CPU: 3 PID: 23874 Comm: syz-executor Not tainted 4.8.0-rc3+ #31 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs

[PATCH 2/4 v3] spinlock.h: Move smp_mb__after_unlock_lock to spinlock.h

v3: If smp_mb__after_unlock_lock() is in barrier.h, then for arm64, kernel/rcu/tree.c doesn't compile because barrier.h is not included in kernel/rcu/tree.c (v2 was: add example from Paul, something that can happen on real HW) spin_unlock() + spin_lock() together do not form a full memory

[PATCH 2/4 v3] spinlock.h: Move smp_mb__after_unlock_lock to spinlock.h

v3: If smp_mb__after_unlock_lock() is in barrier.h, then for arm64, kernel/rcu/tree.c doesn't compile because barrier.h is not included in kernel/rcu/tree.c (v2 was: add example from Paul, something that can happen on real HW) spin_unlock() + spin_lock() together do not form a full memory

[PATCH] media: usb: dvb-usb: fix DIBUSB_MB usage of dib3000mc functions

From: Randy Dunlap The problem is that this driver uses a "common" driver supplement which calls a few dib3000mc*() functions but that driver is not "select"ed by DVB_USB_DIBUSB_MB. We can fix the build errors by selecting DVB_DIB3000MC (at the expense of around 8 KB on

Re: [PATCH 2/4] barrier.h: Move smp_mb__after_unlock_lock to barrier.h

On 08/28/2016 03:43 PM, Paul E. McKenney wrote: Without the smp_mb__after_unlock_lock(), other CPUs can observe the write to d without seeing the write to a. Signed-off-by: Manfred Spraul With the upgraded commit log, I am OK with the patch below. Done. However,

[PATCH] media: usb: dvb-usb: fix DIBUSB_MB usage of dib3000mc functions

From: Randy Dunlap The problem is that this driver uses a "common" driver supplement which calls a few dib3000mc*() functions but that driver is not "select"ed by DVB_USB_DIBUSB_MB. We can fix the build errors by selecting DVB_DIB3000MC (at the expense of around 8 KB on x86_64) just to add a few

Re: [PATCH 2/4] barrier.h: Move smp_mb__after_unlock_lock to barrier.h

On 08/28/2016 03:43 PM, Paul E. McKenney wrote: Without the smp_mb__after_unlock_lock(), other CPUs can observe the write to d without seeing the write to a. Signed-off-by: Manfred Spraul With the upgraded commit log, I am OK with the patch below. Done. However, others will probably want

Re: checkkpatch (in)sanity ?

On Sun, Aug 28, 2016 at 10:15:57AM -0700, Joe Perches wrote: > On Sat, 2016-08-27 at 22:47 -0400, Levin, Alexander wrote: > > > > By default you should only get the most critical warnings we have in the > > > > kernel like missing S-O-B or corrupt patch. > > > I don't think so, but if you do, add

Re: checkkpatch (in)sanity ?

On Sun, Aug 28, 2016 at 10:15:57AM -0700, Joe Perches wrote: > On Sat, 2016-08-27 at 22:47 -0400, Levin, Alexander wrote: > > > > By default you should only get the most critical warnings we have in the > > > > kernel like missing S-O-B or corrupt patch. > > > I don't think so, but if you do, add

Misuses of ** ? (was Re: [PATCH 1/1] ASoC: Intel: Atom: add a missing star in a memcpy call)

On Sun, 2016-08-28 at 19:39 +0200, Nicolas Iooss wrote: > In sst_prepare_and_post_msg(), when a response is received in "block", > the following code gets executed: > > *data = kzalloc(block->size, GFP_KERNEL); > memcpy(data, (void *) block->data, block->size); Yuck, thanks. Julia, Dan,

Misuses of ** ? (was Re: [PATCH 1/1] ASoC: Intel: Atom: add a missing star in a memcpy call)

On Sun, 2016-08-28 at 19:39 +0200, Nicolas Iooss wrote: > In sst_prepare_and_post_msg(), when a response is received in "block", > the following code gets executed: > > *data = kzalloc(block->size, GFP_KERNEL); > memcpy(data, (void *) block->data, block->size); Yuck, thanks. Julia, Dan,

Re: [PATCH 6/6] KVM: PPC: e500: Rename jump labels in kvmppc_e500_tlb_init()

On Sun, 28 Aug 2016, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 28 Aug 2016 18:45:26 +0200 > > Adjust jump labels according to the current Linux coding style convention. > > Signed-off-by: Markus Elfring > --- >

Re: [PATCH 6/6] KVM: PPC: e500: Rename jump labels in kvmppc_e500_tlb_init()

On Sun, 28 Aug 2016, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 28 Aug 2016 18:45:26 +0200 > > Adjust jump labels according to the current Linux coding style convention. > > Signed-off-by: Markus Elfring > --- > arch/powerpc/kvm/e500_mmu.c | 9 - > 1 file changed, 4

Re: [PATCH 5/6] KVM: PPC: e500: Use kmalloc_array() in kvmppc_e500_tlb_init()

On Sun, 28 Aug 2016, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 28 Aug 2016 18:40:08 +0200 > > * A multiplication for the size determination of a memory allocation > indicated that an array data structure should be processed. > Thus use the

Re: constification and cocci / kernel build test robot ?

On Sun, 28 Aug 2016, Joe Perches wrote: > On Sun, 2016-08-28 at 15:13 +0200, Julia Lawall wrote: > > [Adding Kees, in case it's of interest] > > > Below is the list of types of top-level initialized structures and the > > number that are const.  For quicker reading, here are some that are > >

Re: [PATCH 5/6] KVM: PPC: e500: Use kmalloc_array() in kvmppc_e500_tlb_init()

On Sun, 28 Aug 2016, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 28 Aug 2016 18:40:08 +0200 > > * A multiplication for the size determination of a memory allocation > indicated that an array data structure should be processed. > Thus use the corresponding function

Re: constification and cocci / kernel build test robot ?

On Sun, 28 Aug 2016, Joe Perches wrote: > On Sun, 2016-08-28 at 15:13 +0200, Julia Lawall wrote: > > [Adding Kees, in case it's of interest] > > > Below is the list of types of top-level initialized structures and the > > number that are const.  For quicker reading, here are some that are > >

drm: WARNING in ioremap_wc

Hello, The following program triggers WARNING in ioremap_wc: [ cut here ] LoadPin: kernel-module denied obj="/memfd: (deleted)" pid=12061 cmdline="/tmp/syz-executor" WARNING: CPU: 1 PID: 12056 at arch/x86/mm/ioremap.c:121[< none >] __ioremap_caller+0x348/0x6b0

drm: WARNING in ioremap_wc

Hello, The following program triggers WARNING in ioremap_wc: [ cut here ] LoadPin: kernel-module denied obj="/memfd: (deleted)" pid=12061 cmdline="/tmp/syz-executor" WARNING: CPU: 1 PID: 12056 at arch/x86/mm/ioremap.c:121[< none >] __ioremap_caller+0x348/0x6b0

[PATCH 1/2] power: bq24735-charger: Request status GPIO with initial input setup

This requests the status GPIO with initial input setup. it is required to read the GPIO status at probe time and thus correctly avoid sending i2c messages when AC is not plugged. When requesting the GPIO without initial input setup, it always reads 0 which causes probe to fail as it assumes the

[PATCH 3/4] ARM: tegra: nyan-big: Include compatible revisions for proper detection

Depthcharge (the payload used with cros devices) will attempt to detect boards using their revision. This includes all the known revisions for the nyan-big board so that the dtb can be selected preferably. Signed-off-by: Paul Kocialkowski ---

[PATCH 2/4] ARM: tegra: nyan: Use external control for bq24735 charger

Nyan boards come with an embedded controller that controls when to enable and disable the charge. Thus, it should not be left up to the kernel to handle that. Using the ti,external-control property allows specifying this use-case. Signed-off-by: Paul Kocialkowski ---

[PATCH 1/2] power: bq24735-charger: Request status GPIO with initial input setup

This requests the status GPIO with initial input setup. it is required to read the GPIO status at probe time and thus correctly avoid sending i2c messages when AC is not plugged. When requesting the GPIO without initial input setup, it always reads 0 which causes probe to fail as it assumes the

[PATCH 3/4] ARM: tegra: nyan-big: Include compatible revisions for proper detection

Depthcharge (the payload used with cros devices) will attempt to detect boards using their revision. This includes all the known revisions for the nyan-big board so that the dtb can be selected preferably. Signed-off-by: Paul Kocialkowski --- arch/arm/boot/dts/tegra124-nyan-big.dts | 7 ++-

[PATCH 2/4] ARM: tegra: nyan: Use external control for bq24735 charger

Nyan boards come with an embedded controller that controls when to enable and disable the charge. Thus, it should not be left up to the kernel to handle that. Using the ti,external-control property allows specifying this use-case. Signed-off-by: Paul Kocialkowski ---

[PATCH 1/4] ARM: tegra: nyan: Use proper IRQ type definitions

This switches a few interrupt definitions that were using GPIO_ACTIVE_HIGH as IRQ type, which is invalid. Signed-off-by: Paul Kocialkowski --- arch/arm/boot/dts/tegra124-nyan.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 1/4] ARM: tegra: nyan: Use proper IRQ type definitions

This switches a few interrupt definitions that were using GPIO_ACTIVE_HIGH as IRQ type, which is invalid. Signed-off-by: Paul Kocialkowski --- arch/arm/boot/dts/tegra124-nyan.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/tegra124-nyan.dtsi

[PATCH 2/2] power: bq24735-charger: Assume not charging when charger is missing

When the charger is missing (disconnected), it is safe to assume that the charger chip is no charging. This is especially relevant when a status GPIO is present and the charger is getting disconnected. bq24735_charger_is_charging will be triggered due to the interrupt then, it will attempt to

[PATCH] i40e: avoid potential null pointer dereference when assigning len

From: Colin Ian King There is a sanitcy check for desc being null in the first line of function i40evf_debug_aq. However, before that, aq_desc is cast from desc, and aq_desc is being dereferenced on the assignment of len, so this could be a potential null pointer

[PATCH 4/4] ARM: tegra: nyan-blaze: Include compatible revisions for proper detection

Depthcharge (the payload used with cros devices) will attempt to detect boards using their revision. This includes all the known revisions for the nyan-blaze board so that the dtb can be selected preferably. Signed-off-by: Paul Kocialkowski ---

[PATCH 2/2] power: bq24735-charger: Assume not charging when charger is missing

When the charger is missing (disconnected), it is safe to assume that the charger chip is no charging. This is especially relevant when a status GPIO is present and the charger is getting disconnected. bq24735_charger_is_charging will be triggered due to the interrupt then, it will attempt to

[PATCH] i40e: avoid potential null pointer dereference when assigning len

From: Colin Ian King There is a sanitcy check for desc being null in the first line of function i40evf_debug_aq. However, before that, aq_desc is cast from desc, and aq_desc is being dereferenced on the assignment of len, so this could be a potential null pointer deference. Fix this by moving

[PATCH 4/4] ARM: tegra: nyan-blaze: Include compatible revisions for proper detection

Depthcharge (the payload used with cros devices) will attempt to detect boards using their revision. This includes all the known revisions for the nyan-blaze board so that the dtb can be selected preferably. Signed-off-by: Paul Kocialkowski --- arch/arm/boot/dts/tegra124-nyan-blaze.dts | 8

<    1   2   3   4   5   6   >