[PATCH v8 16/26] irqchip/gic-v3: Factor group0 detection into functions

The code to detect whether Linux has access to group0 interrupts can prove useful in other parts of the driver. Provide a separate function to do this. Signed-off-by: Julien Thierry Cc: Thomas Gleixner Cc: Jason Cooper Cc: Marc Zyngier --- drivers/irqchip/irq-gic-v3.c | 55

[PATCH v8 24/26] arm64: Skip preemption when exiting an NMI

Handling of an NMI should not set any TIF flags. For NMIs received from EL0 the current exit path is safe to use. However, an NMI received at EL1 could have interrupted some task context that has set the TIF_NEED_RESCHED flag. Preempting a task should not happen as a result of an NMI. Skip

[PATCH v8 22/26] irqchip/gic-v3: Allow interrupts to be set as pseudo-NMI

Implement NMI callbacks for GICv3 irqchip. Install NMI safe handlers when setting up interrupt line as NMI. Only SPIs and PPIs are allowed to be set up as NMI. Signed-off-by: Julien Thierry Cc: Thomas Gleixner Cc: Jason Cooper Cc: Marc Zyngier --- drivers/irqchip/irq-gic-v3.c | 84

Re: [PATCH v4 04/10] KVM/x86: intel_pmu_lbr_enable

On 1/8/2019 1:13 AM, Wei Wang wrote: On 01/07/2019 10:22 PM, Liang, Kan wrote: Thanks for sharing. I understand the point of maintaining those models at one place, but this factor-out doesn't seem very elegant to me, like below __intel_pmu_init (int model, struct x86_pmu *x86_pmu) { ...

[PATCH v8 20/26] irqchip/gic-v3: Handle pseudo-NMIs

Provide a higher priority to be used for pseudo-NMIs. When such an interrupt is received, keep interrupts fully disabled at CPU level to prevent receiving other pseudo-NMIs while handling the current one. Signed-off-by: Julien Thierry Cc: Thomas Gleixner Cc: Jason Cooper Cc: Marc Zyngier ---

Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged

On Tue, Jan 08, 2019 at 02:53:00PM +0100, Bernd Petrovitsch wrote: > On 08/01/2019 12:37, Jiri Kosina wrote: > > On Tue, 8 Jan 2019, Bernd Petrovitsch wrote: > > > >> Shouldn't the application use e.g. mlock()/ to guarantee no page > >> faults in the first place? > > > > Calling mincore()

[PATCH v8 23/26] arm64: Handle serror in NMI context

Per definition of the daifflags, Serrors can occur during any interrupt context, that includes NMI contexts. Trying to nmi_enter in an nmi context will crash. Skip nmi_enter/nmi_exit when serror occurred during an NMI. Suggested-by: James Morse Signed-off-by: Julien Thierry Cc: Catalin Marinas

[PATCH v8 25/26] arm64: Skip irqflags tracing for NMI in IRQs disabled context

When an NMI is raised while interrupts where disabled, the IRQ tracing already is in the correct state (i.e. hardirqs_off) and should be left as such when returning to the interrupted context. Check whether PMR was masking interrupts when the NMI was raised and skip IRQ tracing if necessary.

[PATCH v8 26/26] arm64: Enable the support of pseudo-NMIs

Add a build option and a command line parameter to build and enable the support of pseudo-NMIs. Signed-off-by: Julien Thierry Suggested-by: Daniel Thompson Cc: Catalin Marinas Cc: Will Deacon --- Documentation/admin-guide/kernel-parameters.txt | 6 ++ arch/arm64/Kconfig

[PATCH v8 12/26] arm64: irqflags: Use ICC_PMR_EL1 for interrupt masking

Instead disabling interrupts by setting the PSR.I bit, use a priority higher than the one used for interrupts to mask them via PMR. When using PMR to disable interrupts, the value of PMR will be used instead of PSR.[DAIF] for the irqflags. Signed-off-by: Julien Thierry Suggested-by: Daniel

[PATCH v8 15/26] arm64: alternative: Apply alternatives early in boot process

From: Daniel Thompson Currently alternatives are applied very late in the boot process (and a long time after we enable scheduling). Some alternative sequences, such as those that alter the way CPU context is stored, must be applied much earlier in the boot sequence. Introduce

[PATCH v8 19/26] irqchip/gic-v3: Detect if GIC can support pseudo-NMIs

The values non secure EL1 needs to use for PMR and RPR registers depends on the value of SCR_EL3.FIQ. The values non secure EL1 sees from the distributor and redistributor depend on whether security is enabled for the GIC or not. To avoid having to deal with two sets of values for PMR

[PATCH v8 18/26] arm64: gic-v3: Implement arch support for priority masking

Implement architecture specific primitive allowing the GICv3 driver to use priorities to mask interrupts. Signed-off-by: Julien Thierry Suggested-by: Daniel Thompson Cc: Marc Zyngier Cc: Catalin Marinas Cc: Will Deacon --- arch/arm64/include/asm/arch_gicv3.h | 8 1 file changed, 4

[PATCH v8 21/26] irqchip/gic: Add functions to access irq priorities

Add accessors to the GIC distributor/redistributors priority registers. Signed-off-by: Julien Thierry Cc: Thomas Gleixner Cc: Jason Cooper Cc: Marc Zyngier --- drivers/irqchip/irq-gic-common.c | 10 ++ drivers/irqchip/irq-gic-common.h | 2 ++ 2 files changed, 12 insertions(+) diff

[PATCH v8 17/26] arm64: Switch to PMR masking when starting CPUs

Once the boot CPU has been prepared or a new secondary CPU has been brought up, use ICC_PMR_EL1 to mask interrupts on that CPU and clear PSR.I bit. Since ICC_PMR_EL1 is initialized at CPU bringup, avoid overwriting it in the GICv3 driver. Signed-off-by: Julien Thierry Suggested-by: Daniel

[PATCH v8 11/26] efi: Let architectures decide the flags that should be saved/restored

Currently, irqflags are saved before calling runtime services and checked for mismatch on return. Provide a pair of overridable macros to save and restore (if needed) the state that need to be preserved on return from a runtime service. This allows to check for flags that are not necesarly

[PATCH v8 07/26] arm64: ptrace: Provide definitions for PMR values

Introduce fixed values for PMR that are going to be used to mask and unmask interrupts by priority. The current priority given to GIC interrupts is 0xa0, so clearing PMR's most significant bit is enough to mask interrupts. Signed-off-by: Julien Thierry Suggested-by: Daniel Thompson Cc: Oleg

[PATCH v8 10/26] arm64: kvm: Unmask PMR before entering guest

Interrupts masked by ICC_PMR_EL1 will not be signaled to the CPU. This means that hypervisor will not receive masked interrupts while running a guest. Avoid this by making sure ICC_PMR_EL1 is unmasked when we enter a guest. Signed-off-by: Julien Thierry Cc: Christoffer Dall Cc: Marc Zyngier

[PATCH v8 09/26] arm64: Unmask PMR before going idle

CPU does not received signals for interrupts with a priority masked by ICC_PMR_EL1. This means the CPU might not come back from a WFI instruction. Make sure ICC_PMR_EL1 does not mask interrupts when doing a WFI. Since the logic of cpu_do_idle is becoming a bit more complex than just two

[PATCH v8 06/26] irqchip/gic-v3: Switch to PMR masking before calling IRQ handler

Mask the IRQ priority through PMR and re-enable IRQs at CPU level, allowing only higher priority interrupts to be received during interrupt handling. Signed-off-by: Julien Thierry Acked-by: Catalin Marinas Cc: Catalin Marinas Cc: Will Deacon Cc: Thomas Gleixner Cc: Jason Cooper Cc: Marc

[PATCH v8 04/26] arm64: cpufeature: Add cpufeature for IRQ priority masking

Add a cpufeature indicating whether a cpu supports masking interrupts by priority. The feature will be properly enabled in a later patch. Signed-off-by: Julien Thierry Reviewed-by: Suzuki K Poulose Reviewed-by: Mark Rutland Acked-by: Catalin Marinas Cc: Catalin Marinas Cc: Will Deacon Cc:

Re: [PATCH v2 0/3] add support for power off check in suspend

On 08.01.2019 13:46, Rafael J. Wysocki wrote: > On Tue, Jan 8, 2019 at 11:56 AM wrote: >> >> From: Claudiu Beznea >> >> Hi, >> >> AT91 platforms support a power saving mode where SoC's power is cut off (we >> call >> it backup mode). The resume is done with the help of bootloaders. > > But

[PATCH v8 01/26] arm64: Fix HCR.TGE status for NMI contexts

When using VHE, the host needs to clear HCR_EL2.TGE bit in order to interract with guest TLBs, switching from EL2&0 translation regime to EL1&0. However, some non-maskable asynchronous event could happen while TGE is cleared like SDEI. Because of this address translation operations relying on

[PATCH v8 00/26] arm64: provide pseudo NMI with GICv3

Hi, This series is a continuation of the work started by Daniel [1]. The goal is to use GICv3 interrupt priorities to simulate an NMI. The patches depend on the core API for NMIs patches [2]. Both series can be found on this branch: git clone http://linux-arm.org/linux-jt.git -b v4.20-pseudo-nmi

RE: [PATCH 2/3] powerpc/dts/fsl: t4240rdb: use the Cortina PHY driver compatible

> -Original Message- > From: Scott Wood > Sent: Saturday, December 22, 2018 06:07 > To: Camelia Alexandra Groza ; > robh...@kernel.org; mark.rutl...@arm.com; b...@kernel.crashing.org > Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > pau...@samba.org;

[PATCH] dio: Fix buffer overflow in case of unknown board

With gcc 8.2.0: drivers/dio/dio.c: In function ‘dio_init’: drivers/dio/dio.c:240:17: warning: ‘strcpy’ writing 69 or more bytes into a region of size 64 overflows the destination [-Wstringop-overflow=] strcpy(dev->name,dio_getname(dev->id));

Re: [PATCH v3 6/8] socket: Add SO_TIMESTAMP[NS]_NEW

On Mon, Jan 7, 2019 at 10:29 PM Deepa Dinamani wrote: > > Add SO_TIMESTAMP_NEW and SO_TIMESTAMPNS_NEW variants of > socket timestamp options. > These are the y2038 safe versions of the SO_TIMESTAMP_OLD > and SO_TIMESTAMPNS_OLD for all architectures. > > Note that the format of

Re: linux-next: build failure after merge of the drm-misc tree

On 1/8/19 3:37 AM, Daniel Vetter wrote: > On Tue, Jan 08, 2019 at 11:12:41AM +1100, Stephen Rothwell wrote: >> Hi all, >> >> After merging the drm-misc tree, today's linux-next build (x86_64 >> allmodconfig) failed like this: >> >> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In

[PATCH] ARM: irq: Add IRQ_SET_MASK_OK_DONE handling in migrate_one_irq()

Arm TC2 (multi_v7_defconfig plus CONFIG_ARM_BIG_LITTLE_CPUFREQ=y and CONFIG_ARM_VEXPRESS_SPC_CPUFREQ=y) fails hotplug stress tests. This issue was tracked down to a missing copy of the new affinity cpumask of the vexpress-spc interrupt into struct irq_common_data.affinity when the interrupt is

Re: remove dma_zalloc_coherent

On Tue, 8 Jan 2019, Julia Lawall wrote: > > > On Tue, 8 Jan 2019, Christoph Hellwig wrote: > > > Hi Linus and world, > > > > We've always had a weird situation around dma_zalloc_coherent. To > > safely support mapping the allocations to userspace major architectures > > like x86 and arm have

Re: remove dma_zalloc_coherent

On Tue, 8 Jan 2019, Christoph Hellwig wrote: > Hi Linus and world, > > We've always had a weird situation around dma_zalloc_coherent. To > safely support mapping the allocations to userspace major architectures > like x86 and arm have always zeroed allocations from dma_alloc_coherent, > but a

Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged

On 08/01/2019 12:37, Jiri Kosina wrote: > On Tue, 8 Jan 2019, Bernd Petrovitsch wrote: > >> Shouldn't the application use e.g. mlock()/ to guarantee no page >> faults in the first place? > > Calling mincore() on pages you've just mlock()ed is sort of pointless > though. Obviously;-)

Re: [PATCH v3 0/8] net: y2038-safe socket timestamps

On Tue, Jan 8, 2019 at 8:37 AM Willem de Bruijn wrote: > > On Mon, Jan 7, 2019 at 10:29 PM Deepa Dinamani wrote: > > > > The series introduces new socket timestamps that are > > y2038 safe. > > > > The time data types used for the existing socket timestamp > > options: SO_TIMESTAMP,

[PATCH v9 1/4] clk: meson: add one based divider support for sclk divider

When CLK_DIVIDER_ONE_BASED flag is set, the sclk divider will be: one based divider (div = val), and zero value gates the clock Signed-off-by: Jianxin Pan --- drivers/clk/meson/Makefile | 3 ++- drivers/clk/meson/clkc-audio.h | 8 -- drivers/clk/meson/clkc.h | 10 ++-

[PATCH v9 2/4] clk: meson: add emmc sub clock phase delay driver

From: Yixun Lan Export the emmc sub clock phase delay ops which will be used by the emmc sub clock driver itself. Signed-off-by: Yixun Lan Signed-off-by: Jianxin Pan --- drivers/clk/meson/Makefile | 1 + drivers/clk/meson/clk-phase-delay.c | 73 +

[PATCH v9 3/4] clk: meson: add DT documentation for emmc clock controller

From: Yixun Lan Document the MMC sub clock controller driver, the potential consumer of this driver is MMC or NAND. Also add four clock bindings IDs which provided by this driver. Reviewed-by: Rob Herring Signed-off-by: Yixun Lan Signed-off-by: Jianxin Pan ---

[PATCH v9 4/4] clk: meson: add sub MMC clock controller driver

From: Yixun Lan The patch will add a MMC clock controller driver which used by MMC or NAND, It provide a mux and divider clock, and three phase clocks - core, tx, tx. Two clocks are provided as the parent of MMC clock controller from upper layer clock controller - eg "amlogic,axg-clkc" in AXG

[PATCH RESEND v9 0/4] clk: meson: add a sub EMMC clock controller support

This driver will add a MMC clock controller driver support. The original idea about adding a clock controller is during the discussion in the NAND driver mainline effort[1]. This driver is tested in the S400 board (AXG platform) with NAND driver. Changes since v8 [9] - fix auto build test

Re: general protection fault in spk_ttyio_ldisc_close

On Tue, Jan 08, 2019 at 08:37:37AM -0500, Kyungtae Kim wrote: > We report a bug in linux-4.20: "general protection fault in > spk_ttyio_ldisc_close" > > kernel config: https://kt0755.github.io/etc/config_v4.20_stable > repro: https://kt0755.github.io/etc/repro.a670e.c > > This occurs when the

Re: Regression in v5.0-rc1: Panic at boot

Hi, Logan, Logan Gunthorpe writes: > Hey, > > I found a regression in v5.0-rc1 this morning. My system panics on boot. > I've attached a log of the panic. > > I bisected to find the problematic commit is: > > Fixes: 9d037ad707ed ("block: remove req->timeout_list") > > But it makes no sense to

Re: [PATCH] m68k/atari: Avoid VLA use in atari_switches_setup()

Hi Arnd, On Tue, Jan 8, 2019 at 2:25 PM Arnd Bergmann wrote: > On Mon, Jan 7, 2019 at 10:29 AM Geert Uytterhoeven > wrote: > > With gcc 7.3.0: > > > > arch/m68k/atari/config.c: In function ‘atari_switches_setup’: > > arch/m68k/atari/config.c:151:2: warning: ISO C90 forbids variable >

Re: [PATCH v3 6/8] socket: Add SO_TIMESTAMP[NS]_NEW

On Mon, Jan 7, 2019 at 10:29 PM Deepa Dinamani wrote: > > Add SO_TIMESTAMP_NEW and SO_TIMESTAMPNS_NEW variants of > socket timestamp options. > These are the y2038 safe versions of the SO_TIMESTAMP_OLD > and SO_TIMESTAMPNS_OLD for all architectures. > > Note that the format of

Re: [PATCH 0/6] tools/lib/traceevent: Some more library updates

Em Fri, Nov 30, 2018 at 11:08:07PM -0500, Steven Rostedt escreveu: > Arnaldo and Jiri, > > Here's another set of patches to get us closer to having a legitimate > standalone library for libtraceevent. There's still a lot of man pages > to come, but I need to continue reviewing them. Thanks,

[PATCH v12 05/10] powerpc: Activate CONFIG_THREAD_INFO_IN_TASK

This patch activates CONFIG_THREAD_INFO_IN_TASK which moves the thread_info into task_struct. Moving thread_info into task_struct has the following advantages: - It protects thread_info from corruption in the case of stack overflows. - Its address is harder to determine if stack addresses are

[PATCH v12 03/10] powerpc: Only use task_struct 'cpu' field on SMP

When moving to CONFIG_THREAD_INFO_IN_TASK, the thread_info 'cpu' field gets moved into task_struct and only defined when CONFIG_SMP is set. This patch ensures that TI_CPU is only used when CONFIG_SMP is set and that task_struct 'cpu' field is not used directly out of SMP code. Signed-off-by:

[PATCH v12 06/10] powerpc: regain entire stack space

thread_info is not anymore in the stack, so the entire stack can now be used. There is also no risk anymore of corrupting task_cpu(p) with a stack overflow so the patch removes the test. When doing this, an explicit test for NULL stack pointer is needed in validate_sp() as it is not anymore

[PATCH v12 09/10] powerpc/64: Remove CURRENT_THREAD_INFO

Now that current_thread_info is located at the beginning of 'current' task struct, CURRENT_THREAD_INFO macro is not really needed any more. This patch replaces it by loads of the value at PACACURRENT(r13). Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/exception-64s.h | 4

[PATCH v12 01/10] powerpc/irq: use memblock functions returning virtual address

Since only the virtual address of allocated blocks is used, lets use functions returning directly virtual address. Those functions have the advantage of also zeroing the block. Suggested-by: Mike Rapoport Signed-off-by: Christophe Leroy --- @Mike: Part of this is taken from your serie. I was

[PATCH v12 04/10] powerpc: Prepare for moving thread_info into task_struct

This patch cleans the powerpc kernel before activating CONFIG_THREAD_INFO_IN_TASK: - The purpose of the pointer given to call_do_softirq() and call_do_irq() is to point the new stack ==> change it to void* and rename it 'sp' - Don't use CURRENT_THREAD_INFO() to locate the stack. - Fix a few

[PATCH v12 10/10] powerpc: clean stack pointers naming

Some stack pointers used to also be thread_info pointers and were called tp. Now that they are only stack pointers, rename them sp. Signed-off-by: Christophe Leroy --- arch/powerpc/kernel/irq.c | 17 +++-- arch/powerpc/kernel/setup_64.c | 11 +++ 2 files changed, 10

[PATCH v12 02/10] book3s/64: avoid circular header inclusion in mmu-hash.h

When activating CONFIG_THREAD_INFO_IN_TASK, linux/sched.h includes asm/current.h. This generates a circular dependency. To avoid that, asm/processor.h shall not be included in mmu-hash.h In order to do that, this patch moves into a new header called asm/task_size_user64.h the information from

[PATCH v12 08/10] powerpc/32: Remove CURRENT_THREAD_INFO and rename TI_CPU

Now that thread_info is similar to task_struct, its address is in r2 so CURRENT_THREAD_INFO() macro is useless. This patch removes it. At the same time, as the 'cpu' field is not anymore in thread_info, this patch renames it to TASK_CPU. Signed-off-by: Christophe Leroy ---

[PATCH v12 07/10] powerpc: 'current_set' is now a table of task_struct pointers

The table of pointers 'current_set' has been used for retrieving the stack and current. They used to be thread_info pointers as they were pointing to the stack and current was taken from the 'task' field of the thread_info. Now, the pointers of 'current_set' table are now both pointers to

[PATCH v12 00/10] powerpc: Switch to CONFIG_THREAD_INFO_IN_TASK

The purpose of this serie is to activate CONFIG_THREAD_INFO_IN_TASK which moves the thread_info into task_struct. Moving thread_info into task_struct has the following advantages: - It protects thread_info from corruption in the case of stack overflows. - Its address is harder to determine if

Re: [PATCH v5 10/15] KVM: s390: add functions to (un)register GISC with GISA

On Tue, 8 Jan 2019 14:36:13 +0100 Halil Pasic wrote: > On Tue, 8 Jan 2019 11:34:44 +0100 > Cornelia Huck wrote: > > > > >> > > > >>> + spin_unlock(>arch.iam_ref_lock); > > > >>> + > > > >>> + return gib->nisc; > > > >>> +} > > > >>> +EXPORT_SYMBOL_GPL(kvm_s390_gisc_register); > >

Re: [PATCH] drm/mediatek: Add MTK Framebuffer-Device (mt7623)

On Mon, Jan 7, 2019 at 11:36 AM Daniel Vetter wrote: > > On Wed, Jan 02, 2019 at 09:49:17AM +0100, Frank Wunderlich wrote: > > From: CK Hu > > > > This patch adds Framebuffer-Driver for Mediatek > > > > currently tested on mt7623, maybe works on other platforms > > MTK-FBDev written by CK Hu and

Re: [PATCH v3 7/8] socket: Add SO_TIMESTAMPING_NEW

On Mon, Jan 7, 2019 at 10:29 PM Deepa Dinamani wrote: > > Add SO_TIMESTAMPING_NEW variant of socket timestamp options. > This is the y2038 safe versions of the SO_TIMESTAMPING_OLD > for all architectures. > > Signed-off-by: Deepa Dinamani > Cc: ch...@zankel.net > Cc: fenghua...@intel.com > Cc:

general protection fault in spk_ttyio_ldisc_close

We report a bug in linux-4.20: "general protection fault in spk_ttyio_ldisc_close" kernel config: https://kt0755.github.io/etc/config_v4.20_stable repro: https://kt0755.github.io/etc/repro.a670e.c This occurs when the function kfree is about to execute (driver/staging/speakup/spk_ttyio.c:68).

Re: [PATCH v3 0/8] net: y2038-safe socket timestamps

On Mon, Jan 7, 2019 at 10:29 PM Deepa Dinamani wrote: > > The series introduces new socket timestamps that are > y2038 safe. > > The time data types used for the existing socket timestamp > options: SO_TIMESTAMP, SO_TIMESTAMPNS and SO_TIMESTAMPING > are not y2038 safe. The series introduces

Re: [PATCH] m68k: Avoid VLA use in mangle_kernel_stack()

On Mon, Jan 7, 2019 at 10:29 AM Geert Uytterhoeven wrote: > > With gcc 7.3.0: > > arch/m68k/kernel/signal.c: In function ‘mangle_kernel_stack’: > arch/m68k/kernel/signal.c:654:3: warning: ISO C90 forbids variable length > array ‘buf’ [-Wvla] >unsigned long buf[fsize / 2]; /* yes,

Re: [PATCH v5 10/15] KVM: s390: add functions to (un)register GISC with GISA

On Tue, 8 Jan 2019 11:34:44 +0100 Cornelia Huck wrote: > > >> > > >>> + spin_unlock(>arch.iam_ref_lock); > > >>> + > > >>> + return gib->nisc; > > >>> +} > > >>> +EXPORT_SYMBOL_GPL(kvm_s390_gisc_register); > > >>> + > > >>> +int kvm_s390_gisc_unregister(struct kvm *kvm, u32 gisc)

Re: [PATCH 8/9] tools/lib/traceevent: Introduce new libtracevent API: tep_override_comm()

Em Fri, Nov 30, 2018 at 10:44:11AM -0500, Steven Rostedt escreveu: > From: Tzvetomir Stoyanov > > This patch adds a new API of tracevent library: tep_override_comm() > It registers a pid / command mapping. If a mapping with the same > pid already exists, the entry is updated with the new

Re: [PATCH v5 10/15] KVM: s390: add functions to (un)register GISC with GISA

On Tue, 8 Jan 2019 14:07:06 +0100 Michael Mueller wrote: > On 08.01.19 11:34, Cornelia Huck wrote: > > On Mon, 7 Jan 2019 18:38:02 +0100 > > Michael Mueller wrote: > > > >> On 04.01.19 14:19, Cornelia Huck wrote: > >>> On Wed, 2 Jan 2019 18:29:00 +0100 > >>> Pierre Morel wrote: > >>>

Re: [PATCH] x86:kernel:e820c:kmemdup instead of duplicating its function

> Subject: Re: [PATCH] x86:kernel:e820c:kmemdup instead of duplicating its > function The tip tree preferred format for patch subject prefixes is 'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:', 'genirq/core:'. Please do not use file names or complete file paths as

Re: [RFC PATCH v1 3/5] Yama: Enforces noexec mounts or file executability through O_MAYEXEC

On 03/01/2019 12:17, Jann Horn wrote: > On Thu, Dec 13, 2018 at 3:49 PM Mickaël Salaün > wrote: >> On 12/12/2018 18:09, Jann Horn wrote: >>> On Wed, Dec 12, 2018 at 9:18 AM Mickaël Salaün wrote: Enable to either propagate the mount options from the underlying VFS mount to prevent

Re: [RFC PATCH 0/4] x86_64/mm: remove bottom-up allocation style by pushing forward the parsing of mem hotplug info

On Tue, Jan 8, 2019 at 6:06 PM Chao Fan wrote: > > On Mon, Jan 07, 2019 at 04:24:41PM +0800, Pingfan Liu wrote: > >Background about the defect of the current bottom-up allocation style, take > >the following scenario: > > | unmovable node | movable node | > > |

Re: [PATCH v6 09/11] mmc: sdhci-acpi: Make PCI dependency explicit

On Sat, Jan 5, 2019 at 11:06 AM Sinan Kaya wrote: > > After 'commit 5d32a66541c4 ("PCI/ACPI: Allow ACPI to be built without > CONFIG_PCI set")' dependencies on CONFIG_PCI that previously were > satisfied implicitly through dependencies on CONFIG_ACPI have to be > specified directly. This driver

Re: [PATCH] media: imx: queue subdev events to reachable video devices

On 12/09/18 20:57, Steve Longerbeam wrote: > From: Steve Longerbeam > > Forward events from a sub-device to its list of reachable video > devices. > > Note this will queue the event to a video device even if there is > no actual _enabled_ media path from the sub-device to the video device. > So

[PATCH v2] staging: erofs: Add identifier for function definition arguments

Add identifier for function definition arguments in xattr_iter_handlers, this change clears the checkpatch.pl issue and make code more explicit. Signed-off-by: Sidong Yang --- drivers/staging/erofs/xattr.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git

Re: [PATCH] m68k/atari: Avoid VLA use in atari_switches_setup()

On Mon, Jan 7, 2019 at 10:29 AM Geert Uytterhoeven wrote: > > With gcc 7.3.0: > > arch/m68k/atari/config.c: In function ‘atari_switches_setup’: > arch/m68k/atari/config.c:151:2: warning: ISO C90 forbids variable length > array ‘switches’ [-Wvla] > char switches[strlen(str) + 1]; >

Re: [PATCH v3 0/2] perf tests: Check for ARM [vectors] page

Em Tue, Jan 01, 2019 at 06:39:26PM +0100, Jiri Olsa escreveu: > On Thu, Dec 20, 2018 at 07:43:35PM -0800, Florian Fainelli wrote: > > I just painfully learned that perf would segfault when > > CONFIG_KUSER_HELPERS is disabled because it unconditionally makes use of > > it. This patch series adds

Re: [PATCH 2/8] gpio: zynq: Wakeup gpio controller when it is used as IRQ controller

On 07. 01. 19 16:42, Thomas Petazzoni wrote: > Hello, > > I am reviving this old thread, because the proposed patch (almost) > solves the problem I recently reported with the bad interaction of > runtime PM with the Zynq GPIO driver (see > https://www.spinics.net/lists/linux-gpio/msg35437.html).

Re: Regression in v5.0-rc1: Panic at boot

On Mon, Jan 07, 2019 at 12:41:06PM -0700, Logan Gunthorpe wrote: > Hey, > > I found a regression in v5.0-rc1 this morning. My system panics on boot. > I've attached a log of the panic. > > I bisected to find the problematic commit is: > > Fixes: 9d037ad707ed ("block: remove req->timeout_list")

Re: [PATCH v3] mm/page_owner: fix for deferred struct page init

On Tue, 2019-01-08 at 09:20 +0100, Michal Hocko wrote: > On Mon 07-01-19 20:53:08, Qian Cai wrote: > > > > > > On 1/7/19 1:43 PM, Michal Hocko wrote: > > > On Fri 04-01-19 15:18:08, Qian Cai wrote: > > > [...] > > > > Though, I can't see any really benefit of this approach apart from > > > >

[PATCH] arch/openrisc: Fix issues with access_ok()

The commit 594cc251fdd0 ("make 'user_access_begin()' do 'access_ok()'") exposed incorrect implementations of access_ok() macro in several architectures. This change fixes 2 issues found in OpenRISC. OpenRISC was not properly using parenthesis for arguments and also using arguments twice. This

Re: [PATCH v4 05/13] arm: perf: conditionally use PERF_PMU_CAP_NO_EXCLUDE

On Tue, Jan 08, 2019 at 02:10:31PM +0100, Peter Zijlstra wrote: > On Tue, Jan 08, 2019 at 01:07:41PM +, Andrew Murray wrote: > > > Yes I found lots of examples like this across the tree whilst doing this > > work. However I decided to initially start with simply removing duplicated > > code

Re: [tip:x86/timers] x86/tsc: Make calibration refinement more robust

Hi Thomas, Ingo, Peter. I'm wondering, was x86/timers branch of tip tree merged to linus' tree for v5.0-rc1? Somehow I do not see this patch make it through... Am I doing something wrong? --nX On Tue, Nov 6, 2018 at 9:58 PM tip-bot for Daniel Vacek wrote: > > Commit-ID:

Re: [PATCH v4 10/13] x86: perf/core: use PERF_PMU_CAP_NO_EXCLUDE for exclude incapable PMUs

On Tue, Jan 08, 2019 at 11:48:41AM +0100, Peter Zijlstra wrote: > On Mon, Jan 07, 2019 at 04:27:27PM +, Andrew Murray wrote: > > For drivers that do not support context exclusion let's advertise the > > PERF_PMU_CAP_NOEXCLUDE capability. This ensures that perf will > > prevent us from handling

Re: fix DMA ops layering violations in vmwgfx

On Tue, Jan 08, 2019 at 09:51:45AM +, Thomas Hellstrom wrote: > Hi, Christoph, > > On Sat, 2019-01-05 at 09:01 +0100, Christoph Hellwig wrote: > > Hi Thomas, > > > > vmwgfx has been doing some odd checks based on DMA ops which rely > > on deep DMA mapping layer internals, and I think the

Re: [PATCH v4 05/13] arm: perf: conditionally use PERF_PMU_CAP_NO_EXCLUDE

On Tue, Jan 08, 2019 at 01:07:41PM +, Andrew Murray wrote: > Yes I found lots of examples like this across the tree whilst doing this > work. However I decided to initially start with simply removing duplicated > code as a result of adding this flag and attempting to preserve existing >

Re: possible deadlock in __wake_up_common_lock

On Wed, Jan 02, 2019 at 01:51:01PM +0100, Vlastimil Babka wrote: > > syz-executor0/8529 is trying to acquire lock: > > 5e7fb829 (>kswapd_wait){}, at: > > __wake_up_common_lock+0x19e/0x330 kernel/sched/wait.c:120 > > From the backtrace at the end of report I see it's coming from >

Re: [PATCH v4 11/13] x86: perf/core: use PERF_PMU_CAP_NO_EXCLUDE for exclude incapable PMUs

On Tue, Jan 08, 2019 at 11:49:40AM +0100, Peter Zijlstra wrote: > On Mon, Jan 07, 2019 at 04:27:28PM +, Andrew Murray wrote: > > This patch has the exact same subject as the previous one.. that seems > sub-optimal. Ah yes, I'll update that in subsquent revisions. (The reason for two patches

[BUG] rmmod g_mass_storage result to segmentation fault

: g_ncm] [ 144.021308] CPU: 3 PID: 9158 Comm: rmmod Not tainted 5.0.0-rc1-next-20190108 #1 [ 144.028623] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 144.035170] PC is at usb_gadget_unregister_driver+0xac/0xd4 [ 144.040748] LR is at 0x1242afc4 [ 144.043895] pc : []lr

Re: [PATCH v4 05/13] arm: perf: conditionally use PERF_PMU_CAP_NO_EXCLUDE

On Tue, Jan 08, 2019 at 11:28:02AM +0100, Peter Zijlstra wrote: > On Mon, Jan 07, 2019 at 04:27:22PM +, Andrew Murray wrote: > > @@ -393,9 +386,8 @@ __hw_perf_event_init(struct perf_event *event) > > /* > > * Check whether we need to exclude the counter from certain modes. > > */

Re: [PATCH v5 10/15] KVM: s390: add functions to (un)register GISC with GISA

On 08.01.19 11:34, Cornelia Huck wrote: On Mon, 7 Jan 2019 18:38:02 +0100 Michael Mueller wrote: On 04.01.19 14:19, Cornelia Huck wrote: On Wed, 2 Jan 2019 18:29:00 +0100 Pierre Morel wrote: On 19/12/2018 20:17, Michael Mueller wrote: Add the IAM (Interruption Alert Mask) to the

[PATCH 3/3] dma-mapping: remove dma_zalloc_coherent()

From: Luis Chamberlain dma_zalloc_coherent() is no longer needed as it has no users because dma_alloc_coherent() already zeroes out memory for us. The Coccinelle grammar rule that used to check for dma_alloc_coherent() + memset() is modified so that it just tells the user that the memset is not

[PATCH 2/3] cross-tree: phase out dma_zalloc_coherent() on headers

From: Luis Chamberlain The last few stragglers coccinelle doesn't pick up are on driver specific header files. Phase those out as well as dma_alloc_coherent() zeroes out the memory as well now too. Suggested-by: Christoph Hellwig Signed-off-by: Luis Chamberlain Signed-off-by: Christoph

remove dma_zalloc_coherent

Hi Linus and world, We've always had a weird situation around dma_zalloc_coherent. To safely support mapping the allocations to userspace major architectures like x86 and arm have always zeroed allocations from dma_alloc_coherent, but a couple other architectures were missing that zeroing either

[PATCH v2 4/4] ASoC: add imx-audmix DT binding documentation

Add the DT binding documentation for Audio Mixer machine driver. Signed-off-by: Viorel Suman --- .../devicetree/bindings/sound/imx-audmix.txt | 24 ++ 1 file changed, 24 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/imx-audmix.txt diff

[PATCH v2 3/4] ASoC: fsl: Add Audio Mixer machine driver

This patch implements Audio Mixer machine driver for NXP iMX8 SOCs. It connects together Audio Mixer and related SAI instances. Signed-off-by: Viorel Suman --- sound/soc/fsl/Kconfig | 9 ++ sound/soc/fsl/Makefile | 2 + sound/soc/fsl/imx-audmix.c | 333

[PATCH v2 2/4] ASoC: add fsl_audmix DT binding documentation

Add the DT binding documentation for NXP Audio Mixer CPU DAI driver. Signed-off-by: Viorel Suman --- .../devicetree/bindings/sound/fsl,audmix.txt | 44 ++ 1 file changed, 44 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/fsl,audmix.txt diff

[PATCH v2 1/4] ASoC: fsl: Add Audio Mixer CPU DAI driver

This patch implements Audio Mixer CPU DAI driver for NXP iMX8 SOCs. The Audio Mixer is a on-chip functional module that allows mixing of two audio streams into a single audio stream. Audio Mixer datasheet is available here: https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf

[PATCH v2 0/4] Add NXP AUDMIX device and machine drivers

The patchset adds NXP Audio Mixer (AUDMIX) device and machine drivers and related DT bindings documentation. Changes since V1: 1. Original patch split into distinct patches for the device driver and DT binding documentation. 2. Replaced AMIX with AUDMIX in both code and file names as it looks

[PATCH] isdn: i4l: isdn_tty: Fix some concurrency double-free bugs

The functions isdn_tty_tiocmset() and isdn_tty_set_termios() may be concurrently executed. isdn_tty_tiocmset isdn_tty_modem_hup line 719: kfree(info->dtmf_state); line 721: kfree(info->silence_state); line 723: kfree(info->adpcms); line 725: kfree(info->adpcmr);

Re: [PATCH 1/2] media: dt-bindings: media: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem

Hi Vishal, The patchset hard escaped me somehow earlier and your reply to Rob made me notice it again. Thanks. :-) On Wed, May 30, 2018 at 12:24:43AM +0530, Vishal Sagar wrote: > Add bindings documentation for Xilinx MIPI CSI-2 Rx Subsystem. > > The Xilinx MIPI CSI-2 Rx Subsystem consists of a

Re: [PATCH v6 07/11] drivers: thermal: int3406_thermal: Make PCI dependency explicit

On Tue, Jan 8, 2019 at 6:58 AM Zhang Rui wrote: > > On 一, 2019-01-07 at 12:19 +0100, Rafael J. Wysocki wrote: > > On Sat, Jan 5, 2019 at 11:06 AM Sinan Kaya wrote: > > > > > > > > > After 'commit 5d32a66541c4 ("PCI/ACPI: Allow ACPI to be built > > > without > > > CONFIG_PCI set")' dependencies

[PATCH] x86/cpu_entry_area: move percpu_setup_debug_store() to __init section

WARNING: vmlinux.o(.text.unlikely+0x498d): Section mismatch in reference from the function percpu_setup_debug_store() to the function .init.text:cea_map_percpu_pages() Signed-off-by: Sergey Senozhatsky --- arch/x86/mm/cpu_entry_area.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH] x86/fpu: move init_xstate_size() to __init section

WARNING: vmlinux.o(.text.unlikely+0x1c05): Section mismatch in reference from the function init_xstate_size() to the function .init.text:get_xsave_size() WARNING: vmlinux.o(.text.unlikely+0x1c19): Section mismatch in reference from the function init_xstate_size() to the

Re: [PATCH v5 13/15] KVM: s390: add function process_gib_alert_list()

On Wed, 19 Dec 2018 20:17:54 +0100 Michael Mueller wrote: > This function processes the Gib Alert List (GAL). It is required > to run when either a gib alert interruption has been received or > a gisa that is in the alert list is cleared or dropped. > > The GAL is build up by millicode, when

Re: [PATCH] net: nvidia: forcedeth: Fix two possible concurrency use-after-free bugs

On 2019/1/8 20:54, Zhu Yanjun wrote: 在 2019/1/8 20:45, Jia-Ju Bai 写道: In drivers/net/ethernet/nvidia/forcedeth.c, the functions nv_start_xmit() and nv_start_xmit_optimized() can be concurrently executed with nv_poll_controller(). nv_start_xmit line 2321: prev_tx_ctx->skb = skb;

<    7   8   9   10   11   12   13   14   15   >