[RFC][PATCH 6/7] perf: Fix race between event install and jump_labels

perf_install_in_context() relies upon the context switch hooks to have scheduled in events when the IPI misses its target -- after all, if the task has moved from the CPU (or wasn't running at all), it will have to context switch to run elsewhere. This however doesn't appear to be happening. It

[RFC][PATCH 4/7] perf: Fix scaling vs enable_on_exec

Oleg reported that enable_on_exec results in weird scale factors. The recent commit 3e349507d12d ("perf: Fix perf_enable_on_exec() event scheduling") caused this by moving task_ctx_sched_out() from before __perf_event_mask_enable() to after it. The overlooked concequence of that change is that

[RFC][PATCH 5/7] perf: Fix cloning

Alexander reported that when the 'original' context gets destroyed, no new clones happen. This can happen irrespective of the ctx switch optimization, any task can die, even the parent, and we want to continue monitoring the task hierarchy until we either close the event or no tasks are left in

[RFC][PATCH 5/7] perf: Fix cloning

Alexander reported that when the 'original' context gets destroyed, no new clones happen. This can happen irrespective of the ctx switch optimization, any task can die, even the parent, and we want to continue monitoring the task hierarchy until we either close the event or no tasks are left in

[RFC][PATCH 2/7] perf: Do not double free

In case of: err_file: fput(event_file), we'll end up calling perf_release() which in turn will free the event. Do not then free the event _again_. Signed-off-by: Peter Zijlstra (Intel) --- kernel/events/core.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-)

[RFC][PATCH 0/7] perf: more fuzzer inspired patches

Most of these patches are a result of syz-kaller runs. With these patches I get a significant reduction in fail, but we're not there yet. There is at least one known issue with unthrottling events (if only it wouldn't not go into hiding whenever I add more debug code), and there are a number of

[RFC][PATCH 2/7] perf: Do not double free

In case of: err_file: fput(event_file), we'll end up calling perf_release() which in turn will free the event. Do not then free the event _again_. Signed-off-by: Peter Zijlstra (Intel) --- kernel/events/core.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) ---

[RFC][PATCH 0/7] perf: more fuzzer inspired patches

Most of these patches are a result of syz-kaller runs. With these patches I get a significant reduction in fail, but we're not there yet. There is at least one known issue with unthrottling events (if only it wouldn't not go into hiding whenever I add more debug code), and there are a number of

[RFC][PATCH 3/7] perf: Allow perf_release() with !event->ctx

In the err_file: fput(event_file) case, the event will not yet have been attached to a context. However perf_release() does assume it has been. Cure this. Signed-off-by: Peter Zijlstra (Intel) --- kernel/events/core.c | 16 +--- 1 file changed, 13

[RFC][PATCH 1/7] perf: Close install vs exit race

The following scenario: CPU0 CPU1 ctx = find_get_ctx(); perf_event_exit_task_context() mutex_lock(>mutex); perf_install_in_context(ctx, ...); /* NO-OP */ mutex_unlock(>mutex); ... perf_release()

Re: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI on Marvell 7K/8K

On Fri, Feb 19, 2016 at 02:47:29PM +, Marc Zyngier wrote: > On 19/02/16 14:28, Jason Cooper wrote: > > On Fri, Feb 19, 2016 at 02:15:46PM +, Marc Zyngier wrote: > >> On 19/02/16 13:34, Thomas Petazzoni wrote: > >>> This commits adds a new irqchip driver that handles the ODMI > >>>

[RFC][PATCH 3/7] perf: Allow perf_release() with !event->ctx

In the err_file: fput(event_file) case, the event will not yet have been attached to a context. However perf_release() does assume it has been. Cure this. Signed-off-by: Peter Zijlstra (Intel) --- kernel/events/core.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-)

[RFC][PATCH 1/7] perf: Close install vs exit race

The following scenario: CPU0 CPU1 ctx = find_get_ctx(); perf_event_exit_task_context() mutex_lock(>mutex); perf_install_in_context(ctx, ...); /* NO-OP */ mutex_unlock(>mutex); ... perf_release()

Re: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI on Marvell 7K/8K

On Fri, Feb 19, 2016 at 02:47:29PM +, Marc Zyngier wrote: > On 19/02/16 14:28, Jason Cooper wrote: > > On Fri, Feb 19, 2016 at 02:15:46PM +, Marc Zyngier wrote: > >> On 19/02/16 13:34, Thomas Petazzoni wrote: > >>> This commits adds a new irqchip driver that handles the ODMI > >>>

[GIT PULL] irqchip core changes for v4.6

Thomas, Here's my first round of irqchip changes for v4.6. My schedule is settling down, but still unpredictable. So I'm favoring sending PRs earlier so as to avoid missing the window. These changes have been through one cycle of -next. Except Armada, which has been in two. Note: the Armada

[GIT PULL] irqchip core changes for v4.6

Thomas, Here's my first round of irqchip changes for v4.6. My schedule is settling down, but still unpredictable. So I'm favoring sending PRs earlier so as to avoid missing the window. These changes have been through one cycle of -next. Except Armada, which has been in two. Note: the Armada

Re: [Xen-devel] [PATCH 8/9] x86/rtc: replace paravirt_enabled() check with subarch check

On Fri, Feb 19, 2016 at 02:22:12PM +0100, Juergen Gross wrote: > On 19/02/16 14:08, Luis R. Rodriguez wrote: > > The current check is a super long winded way of asking if this > > is on lguest. The flags is used for legacy features, this is > > What about Xen pv-domU? I wouldn't expect those to

Re: [Xen-devel] [PATCH 8/9] x86/rtc: replace paravirt_enabled() check with subarch check

On Fri, Feb 19, 2016 at 02:22:12PM +0100, Juergen Gross wrote: > On 19/02/16 14:08, Luis R. Rodriguez wrote: > > The current check is a super long winded way of asking if this > > is on lguest. The flags is used for legacy features, this is > > What about Xen pv-domU? I wouldn't expect those to

Re: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI on Marvell 7K/8K

On 19/02/16 14:28, Jason Cooper wrote: > On Fri, Feb 19, 2016 at 02:15:46PM +, Marc Zyngier wrote: >> On 19/02/16 13:34, Thomas Petazzoni wrote: >>> This commits adds a new irqchip driver that handles the ODMI >>> controller found on Marvell 7K/8K processors. The ODMI controller >>> provide

Re: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI on Marvell 7K/8K

On 19/02/16 14:28, Jason Cooper wrote: > On Fri, Feb 19, 2016 at 02:15:46PM +, Marc Zyngier wrote: >> On 19/02/16 13:34, Thomas Petazzoni wrote: >>> This commits adds a new irqchip driver that handles the ODMI >>> controller found on Marvell 7K/8K processors. The ODMI controller >>> provide

[PATCH] ARM: at91/dt: fix typo in sama5d2 pinmux descriptions

PIN_PA15 macro has the same value as PIN_PA14 so we were overriding PA14 mux/configuration. Signed-off-by: Ludovic Desroches Reported-by: Cyrille Pitchen Fixes: 7f16cb676c00 ("ARM: at91/dt: add sama5d2 pinmux") Cc: sta...@vger.kernel.org

[PATCH] ARM: at91/dt: fix typo in sama5d2 pinmux descriptions

PIN_PA15 macro has the same value as PIN_PA14 so we were overriding PA14 mux/configuration. Signed-off-by: Ludovic Desroches Reported-by: Cyrille Pitchen Fixes: 7f16cb676c00 ("ARM: at91/dt: add sama5d2 pinmux") Cc: sta...@vger.kernel.org #4.4 and later --- arch/arm/boot/dts/sama5d2-pinfunc.h |

Re: [PATCH v2 07/14] KVM: x86: remove unnecessary uses of PIT state lock

2016-02-18 19:03+0100, Paolo Bonzini: > On 17/02/2016 20:14, Radim Krčmář wrote: > > + /* All members before "struct mutex lock" are protected by the lock. */ > > ... except reinject, according to the commit message. :) Ah, thanks.

Re: [PATCH v2 07/14] KVM: x86: remove unnecessary uses of PIT state lock

2016-02-18 19:03+0100, Paolo Bonzini: > On 17/02/2016 20:14, Radim Krčmář wrote: > > + /* All members before "struct mutex lock" are protected by the lock. */ > > ... except reinject, according to the commit message. :) Ah, thanks.

Re: [PATCH v2 01/14] KVM: x86: change PIT discard tick policy

[Cc'd Peter, the last guy that touched timers in libvirt, because he might know what tick policies are supposed to be.] 2016-02-18 18:55+0100, Paolo Bonzini: > On 18/02/2016 18:33, Paolo Bonzini wrote: >> On 18/02/2016 17:56, Radim Krčmář wrote: >>> 2016-02-18 17:13+0100, Paolo Bonzini: On

Re: [PATCH v2 01/14] KVM: x86: change PIT discard tick policy

[Cc'd Peter, the last guy that touched timers in libvirt, because he might know what tick policies are supposed to be.] 2016-02-18 18:55+0100, Paolo Bonzini: > On 18/02/2016 18:33, Paolo Bonzini wrote: >> On 18/02/2016 17:56, Radim Krčmář wrote: >>> 2016-02-18 17:13+0100, Paolo Bonzini: On

Re: [PATCH v5 3/3] irqchip: add nps Internal and external irqchips

Hi Jason, The patch set got change log, see cover letter that summarize all changes with respect to whole set. https://lkml.org/lkml/2016/2/11/609 Let me know if it works for you. Noam

Re: [PATCH v5 3/3] irqchip: add nps Internal and external irqchips

Hi Jason, The patch set got change log, see cover letter that summarize all changes with respect to whole set. https://lkml.org/lkml/2016/2/11/609 Let me know if it works for you. Noam

Re: [PATCH v1 1/4] net: ti: netcp: restore get/set_pad_info() functionality

On Thursday 18 February 2016 14:46:14 Murali Karicheri wrote: > From: Arnd Bergmann > > The commit 899077791403 ("netcp: try to reduce type confusion in > descriptors") introduces a regression in Kernel 4.5-rc1 and it breaks > get/set_pad_info() functionality. > > The TI NETCP

Re: [PATCH v1 1/4] net: ti: netcp: restore get/set_pad_info() functionality

On Thursday 18 February 2016 14:46:14 Murali Karicheri wrote: > From: Arnd Bergmann > > The commit 899077791403 ("netcp: try to reduce type confusion in > descriptors") introduces a regression in Kernel 4.5-rc1 and it breaks > get/set_pad_info() functionality. > > The TI NETCP driver uses pad0

Re: [Xen-devel] [PATCH 1/9] x86/boot: enumerate documentation for the x86 hardware_subarch

On Fri, Feb 19, 2016 at 01:40:33PM +, David Vrabel wrote: > On 19/02/16 13:08, Luis R. Rodriguez wrote: > > Although hardware_subarch has been in place since the x86 boot > > protocol 2.07 it hasn't been used much. Enumerate current possible > > values to avoid misuses and help with semantics

Re: [Xen-devel] [PATCH 1/9] x86/boot: enumerate documentation for the x86 hardware_subarch

On Fri, Feb 19, 2016 at 01:40:33PM +, David Vrabel wrote: > On 19/02/16 13:08, Luis R. Rodriguez wrote: > > Although hardware_subarch has been in place since the x86 boot > > protocol 2.07 it hasn't been used much. Enumerate current possible > > values to avoid misuses and help with semantics

Re: [PATCH v5 1/7] asm-generic: consolidate mark_rodata_ro()

On Wed, Feb 17, 2016 at 02:41:12PM -0800, Kees Cook wrote: > Instead of defining mark_rodata_ro() in each architecture, consolidate it. > > Signed-off-by: Kees Cook > Cc: Russell King > Cc: Catalin Marinas > Cc: Will

Re: [PATCH v1 3/4] net: netcp: rename {get/set}pad_info to {get/set}_sw_data

On Thursday 18 February 2016 14:46:16 Murali Karicheri wrote: > Rename the helpers to match with the updated dma desc field sw_data. > > Cc: Wingman Kwok > Cc: Mugunthan V N > CC: Arnd Bergmann > CC: Grygorii Strashko

Re: [PATCH v5 1/7] asm-generic: consolidate mark_rodata_ro()

On Wed, Feb 17, 2016 at 02:41:12PM -0800, Kees Cook wrote: > Instead of defining mark_rodata_ro() in each architecture, consolidate it. > > Signed-off-by: Kees Cook > Cc: Russell King > Cc: Catalin Marinas > Cc: Will Deacon > Cc: "James E.J. Bottomley" > --- >

Re: [PATCH v1 3/4] net: netcp: rename {get/set}pad_info to {get/set}_sw_data

On Thursday 18 February 2016 14:46:16 Murali Karicheri wrote: > Rename the helpers to match with the updated dma desc field sw_data. > > Cc: Wingman Kwok > Cc: Mugunthan V N > CC: Arnd Bergmann > CC: Grygorii Strashko > CC: David Laight > Signed-off-by: Murali Karicheri > --- > v1 - new

Re: [Xen-devel] [PATCH 0/9] x86/init: replace paravirt_enabled() were possible

On Fri, Feb 19, 2016 at 01:34:59PM +, David Vrabel wrote: > On 19/02/16 13:08, Luis R. Rodriguez wrote: > > I originally set out to rename paravirt_enabled() to paravirt_legacy() > > but we instead decided to remove paravirt_enabled() completely. Although > > I have some linker table work

[PATCH 2/2] RFC: chrdev: allocate chardevs in all unused holes

This is a duct-tape-and-chewing-gum solution to the problem with the major numbers running out when allocating major numbers dynamically. To avoid collissions in the major space, we supply a list of "holes" that exist in the lower range of major numbers [0-254] and pick numbers from there once

[PATCH 1/2] chrdev: emit a warning when we go below dynamic major range

Currently a dynamically allocated character device major is taken from 254 and downward. This mechanism is used for RTC, IIO and a few other subsystems. The kernel currently has no check prevening these dynamic allocations from eating into the assigned numbers at 233 and downward. In a recent

Re: [Xen-devel] [PATCH 0/9] x86/init: replace paravirt_enabled() were possible

On Fri, Feb 19, 2016 at 01:34:59PM +, David Vrabel wrote: > On 19/02/16 13:08, Luis R. Rodriguez wrote: > > I originally set out to rename paravirt_enabled() to paravirt_legacy() > > but we instead decided to remove paravirt_enabled() completely. Although > > I have some linker table work

[PATCH 2/2] RFC: chrdev: allocate chardevs in all unused holes

This is a duct-tape-and-chewing-gum solution to the problem with the major numbers running out when allocating major numbers dynamically. To avoid collissions in the major space, we supply a list of "holes" that exist in the lower range of major numbers [0-254] and pick numbers from there once

[PATCH 1/2] chrdev: emit a warning when we go below dynamic major range

Currently a dynamically allocated character device major is taken from 254 and downward. This mechanism is used for RTC, IIO and a few other subsystems. The kernel currently has no check prevening these dynamic allocations from eating into the assigned numbers at 233 and downward. In a recent

Re: [PATCH v1 2/4] soc: ti: knav_dma: rename pad in struct knav_dma_desc to sw_data

On Thursday 18 February 2016 14:46:15 Murali Karicheri wrote: > Rename the pad to sw_data as per description of this field in the hardware > spec(refer sprugr9 from www.ti.com). Latest version of the document is > at http://www.ti.com/lit/ug/sprugr9h/sprugr9h.pdf and section 3.1 > Host Packet

Re: [PATCH v1 2/4] soc: ti: knav_dma: rename pad in struct knav_dma_desc to sw_data

On Thursday 18 February 2016 14:46:15 Murali Karicheri wrote: > Rename the pad to sw_data as per description of this field in the hardware > spec(refer sprugr9 from www.ti.com). Latest version of the document is > at http://www.ti.com/lit/ug/sprugr9h/sprugr9h.pdf and section 3.1 > Host Packet

[PATCH v2 2/2] clk: add artpec-6 clock controller

Add a driver for the main clock controller of the Artpec-6 Soc. Signed-off-by: Lars Persson --- drivers/clk/Makefile | 1 + drivers/clk/axis/Makefile| 1 + drivers/clk/axis/clk-artpec6.c | 177

[PATCH v2 2/2] clk: add artpec-6 clock controller

Add a driver for the main clock controller of the Artpec-6 Soc. Signed-off-by: Lars Persson --- drivers/clk/Makefile | 1 + drivers/clk/axis/Makefile| 1 + drivers/clk/axis/clk-artpec6.c | 177 +++

Re: [PATCH 5/6] hisi_sas: add hisi_sas_slave_configure()

On 02/19/2016 11:46 AM, John Garry wrote: > On 18/02/2016 10:57, John Garry wrote: >> On 18/02/2016 10:30, Hannes Reinecke wrote: >>> On 02/18/2016 11:12 AM, John Garry wrote: On 18/02/2016 07:40, Hannes Reinecke wrote: >>> [ .. ] > Well, the classical thing would be to associate each

Re: [PATCH 5/6] hisi_sas: add hisi_sas_slave_configure()

On 02/19/2016 11:46 AM, John Garry wrote: > On 18/02/2016 10:57, John Garry wrote: >> On 18/02/2016 10:30, Hannes Reinecke wrote: >>> On 02/18/2016 11:12 AM, John Garry wrote: On 18/02/2016 07:40, Hannes Reinecke wrote: >>> [ .. ] > Well, the classical thing would be to associate each

[PATCH v2 1/2] clk: add device tree binding for Artpec-6 clock controller

Add device tree documentation for the main clock controller in the Artpec-6 SoC. Signed-off-by: Lars Persson --- .../devicetree/bindings/clock/artpec6.txt | 41 ++ 1 file changed, 41 insertions(+) create mode 100644

[PATCH v2 1/2] clk: add device tree binding for Artpec-6 clock controller

Add device tree documentation for the main clock controller in the Artpec-6 SoC. Signed-off-by: Lars Persson --- .../devicetree/bindings/clock/artpec6.txt | 41 ++ 1 file changed, 41 insertions(+) create mode 100644

Re: [PATCH v4.1] arm64: hw_breakpoint: Allow EL2 breakpoints if running in HYP

On Wed, Feb 17, 2016 at 05:58:43PM +, Marc Zyngier wrote: > With VHE, we place kernel {watch,break}-points at EL2 to get things > like kgdb and "perf -e mem:..." working. > > This requires a bit of repainting in the low-level encore/decode, > but is otherwise pretty simple. > >

[PATCH v2 0/2] clk: Add Artpec-6 SoC support

Add clock support for the Artpec-6 SoC port. The ARM parts are in the series "arm: Add Artpec-6 SoC" and it goes through the arm-soc tree. Changes since v1: - The driver now provides all clocks from the main clock controller block through one DT node. - Added a header file for the clock

Re: [PATCH v4.1] arm64: hw_breakpoint: Allow EL2 breakpoints if running in HYP

On Wed, Feb 17, 2016 at 05:58:43PM +, Marc Zyngier wrote: > With VHE, we place kernel {watch,break}-points at EL2 to get things > like kgdb and "perf -e mem:..." working. > > This requires a bit of repainting in the low-level encore/decode, > but is otherwise pretty simple. > >

[PATCH v2 0/2] clk: Add Artpec-6 SoC support

Add clock support for the Artpec-6 SoC port. The ARM parts are in the series "arm: Add Artpec-6 SoC" and it goes through the arm-soc tree. Changes since v1: - The driver now provides all clocks from the main clock controller block through one DT node. - Added a header file for the clock

Re: [PATCH v4.1] arm64: perf: Count EL2 events if the kernel is running in HYP

On Wed, Feb 17, 2016 at 05:57:39PM +, Marc Zyngier wrote: > When the kernel is running in HYP (with VHE), it is necessary to > include EL2 events if the user requests counting kernel or > hypervisor events. > > Reviewed-by: Christoffer Dall > Acked-by: Catalin

Re: [PATCH v4.1] arm64: perf: Count EL2 events if the kernel is running in HYP

On Wed, Feb 17, 2016 at 05:57:39PM +, Marc Zyngier wrote: > When the kernel is running in HYP (with VHE), it is necessary to > include EL2 events if the user requests counting kernel or > hypervisor events. > > Reviewed-by: Christoffer Dall > Acked-by: Catalin Marinas > Signed-off-by: Marc

Re: [PATCH] crypto: allow rfc3686 aes-ctr variants in fips mode.

Am Freitag, 19. Februar 2016, 13:34:28 schrieb Marcus Meissner: Hi Marcus, > RFC 3686 CTR in various authenc methods. > > rfc3686(ctr(aes)) is already marked fips compliant, > so these should be fine. > > Signed-off-by: Marcus Meissner Acked-by: Stephan Mueller

Re: [PATCH] crypto: allow rfc3686 aes-ctr variants in fips mode.

Am Freitag, 19. Februar 2016, 13:34:28 schrieb Marcus Meissner: Hi Marcus, > RFC 3686 CTR in various authenc methods. > > rfc3686(ctr(aes)) is already marked fips compliant, > so these should be fine. > > Signed-off-by: Marcus Meissner Acked-by: Stephan Mueller > --- > crypto/testmgr.c |

RE: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values

On 19 Feb 2016, Arnd Bergmann wrote: > On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote: > > > > Acked-by: Nicolas Pitre > > > > Is there a way to provide a default for defaults? > > We could have something like > > config PHYS_OFFSET_0 > bool > > config

RE: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values

On 19 Feb 2016, Arnd Bergmann wrote: > On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote: > > > > Acked-by: Nicolas Pitre > > > > Is there a way to provide a default for defaults? > > We could have something like > > config PHYS_OFFSET_0 > bool > > config PHYS_OFFSET_1 >

Re: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI on Marvell 7K/8K

On Fri, Feb 19, 2016 at 02:15:46PM +, Marc Zyngier wrote: > On 19/02/16 13:34, Thomas Petazzoni wrote: > > This commits adds a new irqchip driver that handles the ODMI > > controller found on Marvell 7K/8K processors. The ODMI controller > > provide MSI interrupt functionality to on-board

Re: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI on Marvell 7K/8K

On Fri, Feb 19, 2016 at 02:15:46PM +, Marc Zyngier wrote: > On 19/02/16 13:34, Thomas Petazzoni wrote: > > This commits adds a new irqchip driver that handles the ODMI > > controller found on Marvell 7K/8K processors. The ODMI controller > > provide MSI interrupt functionality to on-board

Re: [PATCH 1/3] [RESEND] ARM: pass -march=armv7-a when building NEON files with clang

On Thursday 18 February 2016 12:31:35 Nicolas Pitre wrote: > On Thu, 18 Feb 2016, Arnd Bergmann wrote: > > > clang ignores the -mfpu=neon flag when building with -march=armv6: > > > > In file included from lib/raid6/neon1.c:27: > > clang/3.8.0/include/arm_neon.h:28:2: error: "NEON support not

Re: [PATCH 1/3] [RESEND] ARM: pass -march=armv7-a when building NEON files with clang

On Thursday 18 February 2016 12:31:35 Nicolas Pitre wrote: > On Thu, 18 Feb 2016, Arnd Bergmann wrote: > > > clang ignores the -mfpu=neon flag when building with -march=armv6: > > > > In file included from lib/raid6/neon1.c:27: > > clang/3.8.0/include/arm_neon.h:28:2: error: "NEON support not

Re: [PATCH 1/2] sched/deadline: add per rq tracking of admitted bandwidth

On Fri, 19 Feb 2016 14:43:47 +0100 luca abeni wrote: > So, the first attached patch (to be applied over Juri's patch) just > moves two __dl_sub_ac() and __dl_add_ac() invocations from > dl_overflow() to deadline.c, using the switched_from_dl() and > switched_to_dl()

Re: [PATCH 1/2] sched/deadline: add per rq tracking of admitted bandwidth

On Fri, 19 Feb 2016 14:43:47 +0100 luca abeni wrote: > So, the first attached patch (to be applied over Juri's patch) just > moves two __dl_sub_ac() and __dl_add_ac() invocations from > dl_overflow() to deadline.c, using the switched_from_dl() and > switched_to_dl() methods. This should cover

[RFC v2 1/6] x86/boot: add BIT() to boot/bitops.h

The boot/bitops.h has guards against including the regular bitops (include/asm-generic/bitops.h), it only implements what we need at early boot. We'll be making use of BIT() later so add it. Users of boot/boot.h must include it prior to asm/setup.h otherwise the guard protection devised against

[RFC v2 1/6] x86/boot: add BIT() to boot/bitops.h

The boot/bitops.h has guards against including the regular bitops (include/asm-generic/bitops.h), it only implements what we need at early boot. We'll be making use of BIT() later so add it. Users of boot/boot.h must include it prior to asm/setup.h otherwise the guard protection devised against

[RFC v2 0/6] x86/init: use linker table

/log/?h=20160219-linker-table-v2 [4] https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux.git/log/?h=20160219-linker-table-v2 Luis R. Rodriguez (6): x86/boot: add BIT() to boot/bitops.h x86/init: use linker tables to simplify x86 init and annotate dependencies x86/init: move ebda

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Thu, 18 Feb 2016, Kirill A. Shutemov wrote: > I worth minimizing kernel config on which you can see the bug. Things like > CONFIG_DEBUG_PAGEALLOC used to interfere with THP before. I disabled all debugging options (using arch/s390/configs/performance_defconfig) - we still chrashed. Sebastian

[RFC v2 0/6] x86/init: use linker table

/log/?h=20160219-linker-table-v2 [4] https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux.git/log/?h=20160219-linker-table-v2 Luis R. Rodriguez (6): x86/boot: add BIT() to boot/bitops.h x86/init: use linker tables to simplify x86 init and annotate dependencies x86/init: move ebda

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Thu, 18 Feb 2016, Kirill A. Shutemov wrote: > I worth minimizing kernel config on which you can see the bug. Things like > CONFIG_DEBUG_PAGEALLOC used to interfere with THP before. I disabled all debugging options (using arch/s390/configs/performance_defconfig) - we still chrashed. Sebastian

Re: [PATCH] Create sysfs entries for PCI VPDI and VPDR tags

On 02/19/2016 03:07 PM, Jordan Hargrave wrote: > On Fri, Feb 19, 2016 at 4:00 AM, Hannes Reinecke wrote: >> >> On 02/18/2016 09:04 PM, Jordan Hargrave wrote: >>> The VPD-R is a readonly area of the PCI Vital Product Data region. >>> There are some standard keywords for serial

Re: [PATCH] Create sysfs entries for PCI VPDI and VPDR tags

On 02/19/2016 03:07 PM, Jordan Hargrave wrote: > On Fri, Feb 19, 2016 at 4:00 AM, Hannes Reinecke wrote: >> >> On 02/18/2016 09:04 PM, Jordan Hargrave wrote: >>> The VPD-R is a readonly area of the PCI Vital Product Data region. >>> There are some standard keywords for serial number,

Re: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI on Marvell 7K/8K

Marc, On Fri, 19 Feb 2016 14:15:46 +, Marc Zyngier wrote: > > .../marvell,odmi-controller.txt| 41 > > drivers/irqchip/Kconfig| 4 + > > drivers/irqchip/Makefile | 1 + > > drivers/irqchip/irq-mvebu-odmi.c

Re: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI on Marvell 7K/8K

Marc, On Fri, 19 Feb 2016 14:15:46 +, Marc Zyngier wrote: > > .../marvell,odmi-controller.txt| 41 > > drivers/irqchip/Kconfig| 4 + > > drivers/irqchip/Makefile | 1 + > > drivers/irqchip/irq-mvebu-odmi.c

[RFC v2 4/6] x86/init: use linker table for i386 early setup

This also annotates this is only used for PC and lguest hardware subarchitectures. v2: add X86_SUBARCH_XEN as well, as noted by Konrad, now tested by 0-day bot. Signed-off-by: Luis R. Rodriguez --- arch/x86/kernel/head32.c | 9 + 1 file changed, 5 insertions(+),

[RFC v2 4/6] x86/init: use linker table for i386 early setup

This also annotates this is only used for PC and lguest hardware subarchitectures. v2: add X86_SUBARCH_XEN as well, as noted by Konrad, now tested by 0-day bot. Signed-off-by: Luis R. Rodriguez --- arch/x86/kernel/head32.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-)

[RFC v2 6/6] x86/init: use linker table for mid early setup

Using the linker table removes the need for the #ifdef'ery and clutter on head32.c and head64.c, if this is linked in and the subarch matches it will run. Cc: Andy Shevchenko Signed-off-by: Luis R. Rodriguez --- arch/x86/include/asm/setup.h

[RFC v2 5/6] x86/init: user linker table for ce4100 early setup

Using the linker table removes the need for the #ifdef'ery and clutter on head32.c. Signed-off-by: Luis R. Rodriguez --- arch/x86/include/asm/setup.h | 6 -- arch/x86/kernel/head32.c | 3 --- arch/x86/platform/ce4100/ce4100.c | 4 +++- 3 files changed, 3

[RFC v2 6/6] x86/init: use linker table for mid early setup

Using the linker table removes the need for the #ifdef'ery and clutter on head32.c and head64.c, if this is linked in and the subarch matches it will run. Cc: Andy Shevchenko Signed-off-by: Luis R. Rodriguez --- arch/x86/include/asm/setup.h| 6 -- arch/x86/kernel/head32.c

[RFC v2 5/6] x86/init: user linker table for ce4100 early setup

Using the linker table removes the need for the #ifdef'ery and clutter on head32.c. Signed-off-by: Luis R. Rodriguez --- arch/x86/include/asm/setup.h | 6 -- arch/x86/kernel/head32.c | 3 --- arch/x86/platform/ce4100/ce4100.c | 4 +++- 3 files changed, 3 insertions(+), 10

[RFC v2 3/6] x86/init: move ebda reservations into linker table

This lets us annotate its requirements specifically for PC and lguest subarchitectures. While at it since head.c just has ebda data rename it. Since we're using linker tables and both x86 32-bit and 64-bit have them we don't need to declare a call for this separately. This lets us also keep this

[RFC v2 3/6] x86/init: move ebda reservations into linker table

This lets us annotate its requirements specifically for PC and lguest subarchitectures. While at it since head.c just has ebda data rename it. Since we're using linker tables and both x86 32-bit and 64-bit have them we don't need to declare a call for this separately. This lets us also keep this

[RFC v2 2/6] x86/init: use linker tables to simplify x86 init and annotate dependencies

Any failure on the x86 init path can be catastrophic. A simple shift of a call from one place to another can easily break things. Likewise adding a new call to one path without considering all x86 requirements can make certain x86 run time environments crash. We currently account for these

[RFC v2 2/6] x86/init: use linker tables to simplify x86 init and annotate dependencies

Any failure on the x86 init path can be catastrophic. A simple shift of a call from one place to another can easily break things. Likewise adding a new call to one path without considering all x86 requirements can make certain x86 run time environments crash. We currently account for these

Re: [RFC v2 7/7] kprobes: port to linker table

On Fri, Feb 19, 2016 at 05:45:59AM -0800, Luis R. Rodriguez wrote: > kprobe makes use of two custom sections: > > type name beginend > init.data _kprobe_blacklist __start_kprobe_blacklist __stop_kprobe_blacklist > text .kprobes.text

Re: [RFC v2 7/7] kprobes: port to linker table

On Fri, Feb 19, 2016 at 05:45:59AM -0800, Luis R. Rodriguez wrote: > kprobe makes use of two custom sections: > > type name beginend > init.data _kprobe_blacklist __start_kprobe_blacklist __stop_kprobe_blacklist > text .kprobes.text

Re: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI on Marvell 7K/8K

On 19/02/16 13:34, Thomas Petazzoni wrote: > This commits adds a new irqchip driver that handles the ODMI > controller found on Marvell 7K/8K processors. The ODMI controller > provide MSI interrupt functionality to on-board peripherals, much like > the GIC-v2m. > > Signed-off-by: Thomas Petazzoni

Re: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI on Marvell 7K/8K

On 19/02/16 13:34, Thomas Petazzoni wrote: > This commits adds a new irqchip driver that handles the ODMI > controller found on Marvell 7K/8K processors. The ODMI controller > provide MSI interrupt functionality to on-board peripherals, much like > the GIC-v2m. > > Signed-off-by: Thomas Petazzoni

Re: [PATCH][QUESTION] Intentional memory leak in ipmi_msghandler?

On 02/19/2016 12:41 AM, Calvin Owens wrote: Hello, I've got a few boxes that are leaking memory in handle_new_recv_msgs() in ipmi_msghandler. AFAICS this is intentional, there's even an explicit counter that tracks the number of times smi_msg is leaked. Are you 100% sure about this? There's

Re: [PATCH][QUESTION] Intentional memory leak in ipmi_msghandler?

On 02/19/2016 12:41 AM, Calvin Owens wrote: Hello, I've got a few boxes that are leaking memory in handle_new_recv_msgs() in ipmi_msghandler. AFAICS this is intentional, there's even an explicit counter that tracks the number of times smi_msg is leaked. Are you 100% sure about this? There's

[PATCH] Revert "regulator: tps65217: remove tps65217.dtsi file"

This reverts commit 8e6ebfaa9b384088002baa10f7534efa73a0794e. Without the patch reverted regulators will not work. This prevents MMC to be working for example so the boards can not boot to MMC rootfs. Tested it on beaglebone white and bisect also points to the reverted commit. The issue can be

[PATCH] Revert "regulator: tps65217: remove tps65217.dtsi file"

This reverts commit 8e6ebfaa9b384088002baa10f7534efa73a0794e. Without the patch reverted regulators will not work. This prevents MMC to be working for example so the boards can not boot to MMC rootfs. Tested it on beaglebone white and bisect also points to the reverted commit. The issue can be

Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

On Tue, Feb 16, 2016 at 05:59:57PM +0100, Paolo Bonzini wrote: > > > On 16/02/2016 15:25, Marcelo Tosatti wrote: > > On Tue, Feb 16, 2016 at 02:48:16PM +0100, Marcelo Tosatti wrote: > >> On Mon, Feb 08, 2016 at 04:18:31PM +0100, Paolo Bonzini wrote: > >>> When an NTP server is running, it may

Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

On Tue, Feb 16, 2016 at 05:59:57PM +0100, Paolo Bonzini wrote: > > > On 16/02/2016 15:25, Marcelo Tosatti wrote: > > On Tue, Feb 16, 2016 at 02:48:16PM +0100, Marcelo Tosatti wrote: > >> On Mon, Feb 08, 2016 at 04:18:31PM +0100, Paolo Bonzini wrote: > >>> When an NTP server is running, it may

Re: [PATCH] Create sysfs entries for PCI VPDI and VPDR tags

On Fri, Feb 19, 2016 at 4:00 AM, Hannes Reinecke wrote: > > On 02/18/2016 09:04 PM, Jordan Hargrave wrote: > > The VPD-R is a readonly area of the PCI Vital Product Data region. > > There are some standard keywords for serial number, manufacturer, > > and vendor-specific values.

Re: [PATCH] Create sysfs entries for PCI VPDI and VPDR tags

On Fri, Feb 19, 2016 at 4:00 AM, Hannes Reinecke wrote: > > On 02/18/2016 09:04 PM, Jordan Hargrave wrote: > > The VPD-R is a readonly area of the PCI Vital Product Data region. > > There are some standard keywords for serial number, manufacturer, > > and vendor-specific values. Dell Servers use

Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64

On Friday 19 February 2016 15:59:59 Yury Norov wrote: > On Fri, Feb 19, 2016 at 09:23:35AM +0100, Arnd Bergmann wrote: > > On Friday 19 February 2016 01:35:06 Yury Norov wrote: > > In > > https://github.com/norov/glibc/commit/5d4290435e428267171ece871539b76e1d079d11 > > you are defining a struct

Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64

On Friday 19 February 2016 15:59:59 Yury Norov wrote: > On Fri, Feb 19, 2016 at 09:23:35AM +0100, Arnd Bergmann wrote: > > On Friday 19 February 2016 01:35:06 Yury Norov wrote: > > In > > https://github.com/norov/glibc/commit/5d4290435e428267171ece871539b76e1d079d11 > > you are defining a struct

<    4   5   6   7   8   9   10   11   12   13   >