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
w
On Wed, Jan 02, 2019 at 01:51:01PM +0100, Vlastimil Babka wrote:
> > syz-executor0/8529 is trying to acquire lock:
> > 5e7fb829 (&pgdat->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 fr
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
> functi
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 chan
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
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 as
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: a786ef152cdcfebc923a67
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 pa
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
> > > > "bea
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")
>
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).
>
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 an
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];
>
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 a/drivers/sta
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
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
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 |
> > |
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 exec
> 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
prefix.
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:
> >>>
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 command.
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,
On Tue, 8 Jan 2019 11:34:44 +0100
Cornelia Huck wrote:
> > >>
> > >>> + spin_unlock(&kvm->arch.iam_ref_lock);
> > >>> +
> > >>> + return gib->nisc;
> > >>> +}
> > >>> +EXPORT_SYMBOL_GPL(kvm_s390_gisc_register);
> > >>> +
> > >>> +int kvm_s390_gisc_unregister(struct kvm *kvm, u32 g
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).
Par
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 SO_TIM
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: r.
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
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(&kvm->arch.iam_ref_lock);
> > > >>> +
> > > >>> + return gib->nisc;
> > > >>> +}
> > > >>> +EXPORT_SYMBOL_GPL(kvm_s390_gisc_register);
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 stac
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
---
arch/powerpc/Makefile
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 task_str
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 +
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 n
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 comment
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 inse
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 impli
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 asm/
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: Chri
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
leak
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, appli
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 scm_timestamping.ts[
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
> >
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 me
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 fun
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 ERROR
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 ++-
drivers
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 +
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
---
.../devicetree/bindings/clock/a
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 pl
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;-)
Sorry
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, SO_TIMESTAMPN
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
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 a
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 mig
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 fun
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 scm_timestamping.ts[
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));
^
> -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; linuxppc-...@lists.ozla
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
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 EL2&
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 st
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: M
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 instructi
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 Zyng
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
Cc
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 Nes
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 related
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 Thomps
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 i
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 -
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 apply_boot_alterna
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
masking/unm
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 Thomp
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.
Sign
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
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
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
---
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() on
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 ++
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)
{
...
s
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 preemp
The addition of PMR should not bypass the semantics of daifflags.
When DA_F are set, I bit is also set as no interrupts (even of higher
priority) is allowed.
When DA_F are cleared, I bit is cleared and interrupt enabling/disabling
goes through ICC_PMR_EL1.
Signed-off-by: Julien Thierry
Cc: Cata
In preparation for the application of alternatives at different points
during the boot process, provide the possibility to check whether
alternatives for a feature of interest was already applied instead of
having a global boolean for all alternatives.
Make VHE enablement code check for the VHE fe
On Sat, Dec 29, 2018 at 3:25 PM Geert Uytterhoeven wrote:
> On Fri, Aug 24, 2018 at 12:00 AM Joe Perches wrote:
> > On Thu, 2018-08-23 at 23:52 +0200, Geert Uytterhoeven wrote:
> > > Reverted locally (incl. the follow-up), applied Andrew's fix, detected new
> > > warnings in v4.18+, and sent patc
In order to replace PSR.I interrupt disabling/enabling with ICC_PMR_EL1
interrupt masking, ICC_PMR_EL1 needs to be saved/restored when
taking/returning from an exception. This mimics the way hardware saves
and restores PSR.I bit in spsr_el1 for exceptions and ERET.
Add PMR to the registers to save
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 ++
Add helper functions to access system registers related to interrupt
priorities: PMR and RPR.
Signed-off-by: Julien Thierry
Reviewed-by: Mark Rutland
Acked-by: Catalin Marinas
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Marc Zyngier
---
arch/arm/include/asm/arch_gicv3.h | 16
There are some helpers to modify PSR.[DAIF] bits that are not referenced
anywhere. The less these bits are available outside of local_irq_*
functions the better.
Get rid of those unused helpers.
Signed-off-by: Julien Thierry
Reviewed-by: Mark Rutland
Acked-by: Catalin Marinas
Cc: Catalin Marin
It is not supported to have some CPUs using GICv3 sysreg CPU interface
while some others do not.
Once ICC_SRE_EL1.SRE is set on a CPU, the bit cannot be cleared. Since
matching this feature require setting ICC_SRE_EL1.SRE, it cannot be
turned off if found on a CPU.
Set the feature as STRICT_BOOT,
Sir/madam,My name is John cavedo,I seek for investment plan in your
country,we may be of value to each other.Get back to me for more
details on below email(attorney.cav...@gmail.com)
On 1/7/19 11:15 PM, Su Yanjun wrote:
>
>
> On 1/8/2019 1:07 PM, Darrick J. Wong wrote:
>> On Tue, Jan 08, 2019 at 12:58:43PM +0800, Su Yanjun
>> wrote:
>>>
>>> On 1/8/2019 2:04 AM, Eric Sandeen wrote:
On 1/7/19 11:52 AM, Darrick J. Wong wrote:
> On Mon, Jan 07, 2019 at 04:53:10AM -
On Tue, Jan 8, 2019 at 8:50 AM Greg KH wrote:
>
> 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://kt07
> Subject: [PATCH 2/2] drm/msm/gpu: fix building without debugfs
>
> When debugfs is disabled, but coredump is turned on, the adreno driver fails
> to
> build:
>
> drivers/gpu/drm/msm/adreno/a3xx_gpu.c:460:4: error: 'struct msm_gpu_funcs'
> has no member named 'show'
>.show = adreno_show,
Hi Dietmar,
On 08/01/2019 13:58, Dietmar Eggemann wrote:
> 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 inte
On Jan 08 2019, Geert Uytterhoeven wrote:
> @@ -90,7 +90,7 @@ static struct dioname names[] =
> #undef DIOFBNAME
>
> static const char *unknowndioname
> -= "unknown DIO board -- please email
> !";
> + = "unknown DIO board, please email linux-m...@lists.linux-m68k.org";
This cou
From: Tetsuo Handa
If memcg OOM events in different domains are pending, already OOM-killed
threads needlessly wait for pending memcg OOM events in different domains.
An out_of_memory() call is slow because it involves printk(). With slow
serial consoles, out_of_memory() might take more than a se
Hi,
On Tue, Jan 08, 2019 at 11:02:24AM +0100, Christophe Leroy wrote:
>
> Le 31/12/2018 à 10:29, Mike Rapoport a écrit :
> >There are a several places that allocate memory using memblock APIs that
> >return a physical address, convert the returned address to the virtual
> >address and frequently
On Wed, Jan 02, 2019 at 10:59:53AM +0100, Peter Rajnoha wrote:
> On 12/19/18 10:24 AM, Greg KH wrote:
> > On Fri, Dec 07, 2018 at 01:28:52PM +0100, Peter Rajnoha wrote:
> >> On 12/7/18 1:01 PM, Greg KH wrote:
> >>> On Fri, Dec 07, 2018 at 12:46:07PM +0100, Peter Rajnoha wrote:
> This patch add
On Tue, 8 Jan 2019 14:41:35 +0100
Cornelia Huck wrote:
> 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(&kvm->arch.iam_ref_lock);
> > > > >>> +
> > > > >>> + return gib-
On Tue, Jan 08, 2019 at 09:15:02AM -0500, Kyungtae Kim wrote:
> On Tue, Jan 8, 2019 at 8:50 AM Greg KH wrote:
> >
> > 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 conf
301 - 400 of 1482 matches
Mail list logo