Suravee,
On Wed, Nov 18 2020 at 17:29, Suravee Suthikulpanit wrote:
> On 11/17/20 9:00 AM, Suravee Suthikulpanit wrote:
>
> I might need your help debugging this issue. I'm seeing the following error:
>
> [ 14.005937] irq 29, desc: d200500b, depth: 0, count: 0, unhandled: > 0
> [
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: 907f8eb8e0eb2b3312b292e67dc4dbc493424747
Gitweb:
https://git.kernel.org/tip/907f8eb8e0eb2b3312b292e67dc4dbc493424747
Author:Thomas Gleixner
AuthorDate:Tue, 17 Nov 2020 21:23:35 +01:00
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 860aaabac8235cfde10fe556aa82abbbe3117888
Gitweb:
https://git.kernel.org/tip/860aaabac8235cfde10fe556aa82abbbe3117888
Author:Thomas Gleixner
AuthorDate:Tue, 17 Nov 2020 21:23:34 +01:00
On Mon, Nov 02 2020 at 21:35, Thomas Gleixner wrote:
> On Mon, Nov 02 2020 at 17:32, John Garry wrote:
> Correct. I have a halfways working solution for that, but I need to fix
> some other thing first.
Sorry for the delay. Supporting this truly on x86 needs some more
thought an
Document the functionality of copy_from_user_nmi() to avoid further
confusion. Fix the typo in the existing comment while at it.
Requested-by: Borislav Petkov
Signed-off-by: Thomas Gleixner
---
V2: New patch
---
arch/x86/lib/usercopy.c | 22 ++
1 file changed, 18
This is the second version of the patch to prevent access to a foreign
tasks user space in copy_code(). It addresses the review comments from
Boris and adds a new patch which provides documentation for
copy_from_user_nmi() to avoid further confusion about it's usage.
V1 can be found here:
sts otherwise.
Reported-by: Oleg Nesterov
Signed-off-by: Thomas Gleixner
Reviewed-by: Borislav Petkov
Tested-by: Borislav Petkov
Acked-by: Oleg Nesterov
Link: https://lore.kernel.org/r/87blfxx8ps@nanos.tec.linutronix.de
---
V2: Fixed changelog, comment and Reported-by attribution (Boris)
---
ar
On Tue, Nov 17 2020 at 12:19, David Woodhouse wrote:
> On Tue, 2020-11-17 at 10:53 +0100, Thomas Gleixner wrote:
>> But that does not solve the problem either simply because then the IOMMU
>> will catch the rogue MSIs and you get an interrupt storm on the IOMMU
>> error inte
and why we don't worry about it.
Signed-off-by: Thomas Gleixner
---
kernel/time/tick-sched.c | 46 +-
1 file changed, 33 insertions(+), 13 deletions(-)
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -59,11 +59,29 @@ static void
Yunfeng proposed a change to tick_do_update_jiffies64() to reduce the
contention on jiffies_seq sequence counter:
https://lore.kernel.org/r/ac822c72-673e-73e1-9622-c5f12591b...@huawei.com
This made me look deeper and there are lots of other things to optimize,
but also things to document which
()
tick_broadcast_switch_to_oneshot()
or
tick_check_oneshot_change()
tick_nohz_switch_to_nohz()
tick_switch_to_oneshot()
tick_broadcast_switch_to_oneshot()
Signed-off-by: Thomas Gleixner
---
kernel/time/tick-broadcast.c | 23 ---
1 file changed, 20
calc_load_global() does not need the sequence count protection.
Signed-off-by: Thomas Gleixner
---
kernel/time/tick-sched.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -20,6 +20,7 @@
#include
#include
this variable at
all. It's just a pointless indirection and all usage sites can just use the
TICK_NSEC constant.
Signed-off-by: Thomas Gleixner
---
kernel/time/tick-broadcast.c |2 +-
kernel/time/tick-common.c|8 +++-
kernel/time/tick-internal.h |1 -
kernel/time/tick-sched.c
The protection rules for tick_next_period and last_jiffies_update are blury
at best. Clarify this.
Signed-off-by: Thomas Gleixner
---
kernel/time/tick-common.c |4 +++-
kernel/time/tick-sched.c |4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
--- a/kernel/time/tick-common.c
If jiffies are up to date already (caller lost the race against another
CPU) there is no point to change the sequence count. Doing that just forces
other CPUs into the seqcount retry loop in tick_nohz_next_event() for
nothing.
Just bail out early.
Reported-by: Yunfeng Ye
Signed-off-by: Thomas
Now that it's clear that there is always one tick to account, simplify the
calculations some more.
Signed-off-by: Thomas Gleixner
---
kernel/time/tick-sched.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
On Mon, Nov 16 2020 at 19:06, Eric W. Biederman wrote:
> Bjorn Helgaas writes:
> My two top candidates are poking the IOMMUs early to shut things off,
> and figuring out if we can delay enabling interrupts until we have
> initialized pci.
Keeping interrupts disabled post PCI initialization would
On Mon, Nov 16 2020 at 23:51, Kevin Tian wrote:
>> From: Jason Gunthorpe
> btw Jason/Thomas, how do you think about the proposal down in this
> thread (ims=[auto|on|off])? Does it sound a good tradeoff to move forward?
What does it solve? It defaults to auto and then you still need to solve
the
On Mon, Nov 16 2020 at 15:04, Andy Lutomirski wrote:
> On Mon, Nov 16, 2020 at 2:01 PM Thomas Gleixner wrote:
>> arch/x86/kernel/dumpstack.c | 23 +++
>> 1 file changed, 19 insertions(+), 4 deletions(-)
>>
>> --- a/arch/x86/kernel/dumpstack
e current tasks
user space mapping or faulted.
Fix below.
Thanks,
tglx
---
Subject: x86/dumpstack: Don't try to access user space code of other tasks
From: Thomas Gleixner
Date: Mon, 16 Nov 2020 22:26:52 +0100
sysrq-t ends up invoking show_opcodes() for each task which tries to access
On Mon, Nov 16 2020 at 14:02, Jason Gunthorpe wrote:
> On Mon, Nov 16, 2020 at 06:56:33PM +0100, Thomas Gleixner wrote:
>> On Mon, Nov 16 2020 at 11:46, Jason Gunthorpe wrote:
>>
>> > On Mon, Nov 16, 2020 at 07:31:49AM +, Tian, Kevin wrote:
>> >
>> &g
Ira,
On Mon, Nov 16 2020 at 10:49, Ira Weiny wrote:
> On Sun, Nov 15, 2020 at 07:58:52PM +0100, Thomas Gleixner wrote:
>> > Currently struct irqentry_state_t only contains a single bool value
>> > which makes passing it by value is reasonable. However, future patche
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 1eb0616c2df5b78c301eaa7bd2ee859f43915001
Gitweb:
https://git.kernel.org/tip/1eb0616c2df5b78c301eaa7bd2ee859f43915001
Author:Thomas Gleixner
AuthorDate:Mon, 16 Nov 2020 11:32:53 -08:00
On Mon, Nov 16 2020 at 11:32, Max Filippov wrote:
> From: Thomas Gleixner
>
> The conversion to the generic kmap_atomic() implementation missed the fact
> that xtensa's fixmap works bottom up while all other implementations work
> top down. There is no real reason why xtens
On Sun, Nov 15 2020 at 18:22, Corentin Labbe wrote:
> I have lot of board booting with "hdaudio hdaudioC0D2: Unable to bind the
> codec".
> This is, for all of them, due to missing the HDA realtek codec.
>
> In fact CONFIG_SND_HDA_CODEC_REALTEK was already enabled via commit
> 5cb04df8d3f0
On Mon, Nov 16 2020 at 15:32, Harald Arnesen wrote:
> I get the following compile error, which reverting commit
> ff828729be446b86957f7c294068758231cd2183 fixes (and the resulting kernel
> boots fine).
> CC drivers/iommu/intel/dmar.o
> drivers/iommu/intel/dmar.c: In function
On Mon, Nov 16 2020 at 11:46, Jason Gunthorpe wrote:
> On Mon, Nov 16, 2020 at 07:31:49AM +, Tian, Kevin wrote:
>
>> > The subdevices require PASID & IOMMU in native, but inside the guest there
>> > is no
>> > need for IOMMU unless you want to build SVM on top. subdevices work
>> > without
>>
On Mon, Nov 16 2020 at 13:17, Peter Zijlstra wrote:
> On Fri, Nov 13, 2020 at 03:02:17PM +0100, Thomas Gleixner wrote:
>
>> -#define irq_count() (preempt_count() & (HARDIRQ_MASK | SOFTIRQ_MASK \
>> - | NMI_MASK))
>> +#define irq_count()
Max,
On Mon, Nov 16 2020 at 06:47, Max Filippov wrote:
> On Fri, Nov 13, 2020 at 2:34 PM Thomas Gleixner wrote:
>> I agree that the top down mechanics is not really intuitive, but that
>> does not justify the ifdeffery in the generic code.
>
> But then maybe xtensa did
On Mon, Nov 16 2020 at 16:26, Arnd Bergmann wrote:
> On Mon, Nov 16, 2020 at 3:03 PM Thomas Gleixner wrote:
>> So instead of trying to chase all these places we really want to rename
>> the global 'nr_irqs' variable.
>
> Fair enough, yes.
>
>> Something like the un
early return is correct.
>
> Fixes: aaf2bc50df1f ("rcu: Abstract out rcu_irq_enter_check_tick() from
> rcu_nmi_enter()")
> Reported-by: "Eugenio Pérez"
> Signed-off-by: Peter Zijlstra (Intel)
> Reviewed-by: Andy Lutomirski
> Reviewed-by: Paul E. McKenney
Reviewed-by: Thomas Gleixner
The following commit has been merged into the timers/core branch of tip:
Commit-ID: cc947f2b9c04113d84eeef67cc7c6326e1982019
Gitweb:
https://git.kernel.org/tip/cc947f2b9c04113d84eeef67cc7c6326e1982019
Author:Thomas Gleixner
AuthorDate:Mon, 16 Nov 2020 10:53:38 +01:00
On Mon, Nov 16 2020 at 21:24, Yunfeng Ye wrote:
> On 2020/11/16 19:29, Thomas Gleixner wrote:
>> There are quite some other inefficiencies in that code and the seqcount
>> held time can be reduced way further. Let me stare at it.
>>
> I think the write
On Mon, Oct 26 2020 at 17:20, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> When building with W=2, there are tons of warnings about conflicting
> local and global definitions of 'nr_irqs' in common header files:
>
> include/linux/irqdomain.h: In function 'irq_domain_alloc_irqs':
>
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 8986f223bd777a73119f5d593c15b4d630ff49bb
Gitweb:
https://git.kernel.org/tip/8986f223bd777a73119f5d593c15b4d630ff49bb
Author:Thomas Gleixner
AuthorDate:Mon, 16 Nov 2020 13:52:47 +01:00
Geert,
On Mon, Nov 16 2020 at 10:47, Geert Uytterhoeven wrote:
> On Thu, Nov 12, 2020 at 8:16 PM Thomas Gleixner wrote:
>> The recent changes to store the MSI irqdomain pointer in struct device
>> missed that Intel DMAR does not register virtual function devices. Due to
>>
On Mon, Nov 16 2020 at 14:07, Yunfeng Ye wrote:
> On 2020/11/16 3:43, Thomas Gleixner wrote:
>>> and the conflict between jiffies_lock and jiffies_seq increases,
>>> especially in multi-core scenarios.
>>
>> This does not make sense. The sequence counter is upd
The following commit has been merged into the timers/core branch of tip:
Commit-ID: c1ce406e80fb15fa52b2b48dfd48fad6f3d2a32f
Gitweb:
https://git.kernel.org/tip/c1ce406e80fb15fa52b2b48dfd48fad6f3d2a32f
Author:Thomas Gleixner
AuthorDate:Sun, 15 Nov 2020 21:09:31 +01:00
On Sun, Nov 15 2020 at 11:08, Joe Perches wrote:
> On Sun, 2020-11-15 at 18:56 +, tip-bot2 for Ira Weiny wrote:
>> The following commit has been merged into the core/entry branch of tip:
> []
>> s/assemenbly/assembly/
> []
>> diff --git a/include/linux/entry-common.h
On Fri, Nov 13 2020 at 15:24, Alex Shi wrote:
> The kernel-doc interface error cause some warning:
I fixes the lot up and applied it. Please look at the changes I did and
be more careful next time.
Thanks,
tglx
On Fri, Nov 13 2020 at 15:24, Alex Shi wrote:
> /**
> * pvclock_gtod_register_notifier - register a pvclock timedata update
> listener
> + * @nb: a notifier entry which register on pvclock_gtod_chain.
What is a notifier entry? The struct is named notifier_block and the
argument is a pointer
On Fri, Nov 13 2020 at 15:24, Alex Shi wrote:
Subject: timekeeping: add ts/tk explaination for kernel-doc
Sentence after the colon starts with an uppercase letter.
s/explaination/explanation/ Please use a spell checker.
Also what is ts/tk? The short log sentence has to be concise and easy to
On Fri, Nov 13 2020 at 15:24, Alex Shi wrote:
> Fix the kernel-doc markup:
> kernel/time/timekeeping.c:1563: warning: Function parameter or member
> 'wall_time' not described in 'read_persistent_wall_and_boot_offset'
> kernel/time/timekeeping.c:1563: warning: Function parameter or member
>
On Sun, Nov 15 2020 at 11:31, Ashok Raj wrote:
> On Sun, Nov 15, 2020 at 12:26:22PM +0100, Thomas Gleixner wrote:
>> > opt-in by device or kernel? The way we are planning to support this is:
>> >
>> > Device support for IMS - Can discover in device specific mea
On Fri, Nov 13 2020 at 15:24, Alex Shi wrote:
> Fix the kernel-doc markup and remove the following warning:
> kernel/time/timekeeping.c:415: warning: Function parameter or member
> 'tkf' not described in 'update_fast_timekeeper'
> kernel/time/timekeeping.c:464: warning: Function parameter or
On Wed, Nov 11 2020 at 17:11, Yunfeng Ye wrote:
> When nohz or nohz_full is configured, the concurrency calls of
> tick_do_update_jiffies64 increases,
Why?
> and the conflict between jiffies_lock and jiffies_seq increases,
> especially in multi-core scenarios.
This does not make sense. The
On Sun, Nov 15 2020 at 18:01, Lukas Wunner wrote:
> On Sun, Nov 15, 2020 at 04:11:43PM +0100, Thomas Gleixner wrote:
>> Unfortunately there is no way to tell the APIC "Mask vector X" and the
>> dump kernel does neither know which device it comes from nor does it
>>
Ira,
On Fri, Nov 06 2020 at 15:29, ira weiny wrote:
Subject prefix wants to 'entry:'. This changes generic code and the x86
part is just required to fix the generic code change.
> Currently struct irqentry_state_t only contains a single bool value
> which makes passing it by value is
On Fri, Nov 13 2020 at 22:29, Gabriel Krisman Bertazi wrote:
> This a refactor work moving the work done by features like seccomp,
> ptrace, audit and tracepoints out of the TI flags. The reasons are:
>
>1) Scarcity of TI flags in x86 32-bit.
>
>2) TI flags are defined by the
On Fri, Nov 13 2020 at 22:29, Gabriel Krisman Bertazi wrote:
>
> enum syscall_work_bit {
> +
> SYSCALL_WORK_SECCOMP= 0,
> + SYSCALL_WORK_SYSCALL_TRACEPOINT = 1,
No assignment required. Enums just do that for you.
Thanks,
tglx
On Fri, Nov 13 2020 at 22:29, Gabriel Krisman Bertazi wrote:
"kernel: entry:" is not the right subsystem prefix.
git log kernel/entry/ might give you a hint.
> Prepares the common entry code to use the SYSCALL_WORK flags. They
> will
s/Prepares/Prepare/
> be defined in subsequent patches for
On Fri, Nov 13 2020 at 22:29, Gabriel Krisman Bertazi wrote:
>
> +enum syscall_work_bit {
> + SYSCALL_WORK_SECCOMP= 0,
enums start at 0, so why do you need an explicit assignment?
> +};
> +
> +#define _SYSCALL_WORK_SECCOMP BIT(SYSCALL_WORK_SECCOMP)
Do we really have to repeat
On Sat, Nov 14 2020 at 11:22, Christoph Hellwig wrote:
>> +#ifdef CONFIG_GENERIC_ENTRY
>> +static inline void __set_task_syscall_work(struct thread_info *ti, int flag)
>> +{
>> +set_bit(flag, (unsigned long *)>syscall_work);
>> +}
>> +static inline int __test_task_syscall_work(struct
On Sun, Nov 15 2020 at 08:29, Eric W. Biederman wrote:
> ebied...@xmission.com (Eric W. Biederman) writes:
> For ordinary irqs you can have this with level triggered irqs
> and the kernel has code that will shutdown the irq at the ioapic
> level. Then the kernel continues by polling the irq
Linus,
please pull the latest sched/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-2020-11-15
up to: 8d4d9c7b4333: sched/debug: Fix memory corruption caused by multiple
small reads of flags
A set of scheduler fixes:
- Address a load balancer
Linus,
please pull the latest perf/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-2020-11-15
up to: 1a8cfa24e21c: perf/x86/intel/uncore: Fix Add BW copypasta
A set of fixes for perf:
- A set of commits which reduce the stack usage of various
orm/uv: Fix copied UV5 output archtype
Thomas Gleixner (1):
iommu/vt-d: Cure VF irqdomain hickup
arch/x86/include/asm/uv/uv.h | 10 --
arch/x86/kernel/apic/x2apic_uv_x.c | 6 +++---
drivers/iommu/intel/dmar.c | 19 ++-
3 files changed, 21 insertions(+),
Linus,
please pull the latest locking/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-urgent-2020-11-15
up to: d61fc96a3760: lockdep: Avoid to modify chain keys in validate_chain()
Two fixes for the locking subsystem:
- Prevent an unconditional
On Sat, Nov 14 2020 at 13:18, Ashok Raj wrote:
> On Sat, Nov 14, 2020 at 10:34:30AM +, Christoph Hellwig wrote:
>> On Thu, Nov 12, 2020 at 11:42:46PM +0100, Thomas Gleixner wrote:
>> Which is why I really think we need explicit opt-ins for "native"
>> SIOV handli
The following commit has been merged into the irq/core branch of tip:
Commit-ID: e906a546bd8653ed2e7a14cb300fd17952d7f862
Gitweb:
https://git.kernel.org/tip/e906a546bd8653ed2e7a14cb300fd17952d7f862
Author:Thomas Gleixner
AuthorDate:Sat, 14 Nov 2020 23:36:28 +01:00
No users outside of the core code.
Signed-off-by: Thomas Gleixner
---
include/linux/irqdomain.h |2 --
kernel/irq/irqdomain.c|2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -387,8 +387,6 @@ extern int
The following commit has been merged into the irq/core branch of tip:
Commit-ID: f296dcd629aa412a80a53215e46087f53af87f08
Gitweb:
https://git.kernel.org/tip/f296dcd629aa412a80a53215e46087f53af87f08
Author:Thomas Gleixner
AuthorDate:Sat, 14 Nov 2020 22:01:45 +01:00
Commit bb9d812643d8 ("arch: remove tile port") removed the last user of
this cruft two years ago...
Signed-off-by: Thomas Gleixner
---
include/linux/irq.h | 15 ---
kernel/irq/Kconfig |5 -
kernel/irq/irqdes
Bjorn,
On Sat, Nov 14 2020 at 14:39, Bjorn Helgaas wrote:
> On Sat, Nov 14, 2020 at 12:40:10AM +0100, Thomas Gleixner wrote:
>> On Sat, Nov 14 2020 at 00:31, Thomas Gleixner wrote:
>> > On Fri, Nov 13 2020 at 10:46, Bjorn Helgaas wrote:
>> >> pci_device_shutdown
On Mon, Nov 09 2020 at 20:46, Alexey Kardashevskiy wrote:
> PCI devices share 4 legacy INTx interrupts from the same PCI host bridge.
> Device drivers map/unmap hardware interrupts via irq_create_mapping()/
> irq_dispose_mapping(). The problem with that these interrupts are
> shared and when
Lukas,
On Fri, Nov 13 2020 at 18:20, Lukas Bulwahn wrote:
> Commit ba31c1a48538 ("futex: Move futex exit handling into futex code")
> introduced compat_exit_robust_list() with a full-fledged implementation for
> CONFIG_COMPAT, and an empty-body function for !CONFIG_COMPAT.
> However,
Bjorn,
On Sat, Nov 14 2020 at 00:31, Thomas Gleixner wrote:
> On Fri, Nov 13 2020 at 10:46, Bjorn Helgaas wrote:
>> pci_device_shutdown() still clears the Bus Master Enable bit if we're
>> doing a kexec and the device is in D0-D3hot, which should also disable
>> MSI/MSI-X. W
Bjorn,
On Fri, Nov 13 2020 at 10:46, Bjorn Helgaas wrote:
> On Fri, Nov 06, 2020 at 10:14:14AM -0300, Guilherme G. Piccoli wrote:
>> On 23/10/2018 14:03, Bjorn Helgaas wrote:
> I guess Thomas' patch [2] (from thread [1]) doesn't solve this
> problem?
No. As I explained in [1] patch from [2]
On Fri, Nov 13 2020 at 13:53, Peter Zijlstra wrote:
> [ 139.226724] WARNING: CPU: 9 PID: 2290 at kernel/rcu/tree.c:932
> __rcu_irq_enter_check_tick+0x84/0xd0
> [ 139.226753] irqentry_enter+0x25/0x40
> [ 139.226753] exc_page_fault+0x38/0x4c0
> [ 139.226753] asm_exc_page_fault+0x1e/0x30
...
Max,
On Fri, Nov 13 2020 at 08:34, Max Filippov wrote:
> On Fri, Nov 13, 2020 at 6:36 AM Thomas Gleixner wrote:
>> On Fri, Nov 13 2020 at 05:50, Max Filippov wrote:
>> > On Fri, Nov 13, 2020 at 5:40 AM Thomas Gleixner wrote:
>> >> What's wrong with just doing the
Max,
On Fri, Nov 13 2020 at 05:50, Max Filippov wrote:
> On Fri, Nov 13, 2020 at 5:40 AM Thomas Gleixner wrote:
>> On Fri, Nov 13 2020 at 04:23, Max Filippov wrote:
>> > Fixmap on xtensa grows upwards, i.e. bigger fixmap entry index
>> > corresponds to a higher vir
SH can now use the generic irq_cpustat_t. Define ack_bad_irq so the generic
header does not emit the generic version of it.
Signed-off-by: Thomas Gleixner
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: linux...@vger.kernel.org
---
arch/sh/include/asm/hardirq.h | 14 --
1 file changed, 4
irq_cpustat_t is exactly the same as the asm-generic one. Define
ack_bad_irq so the generic header does not emit the generic version of it.
Signed-off-by: Thomas Gleixner
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Marc Zyngier
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm64/include/asm
irq_cpustat_t and ack_bad_irq() are exactly the same as the asm-generic
ones.
Signed-off-by: Thomas Gleixner
Cc: Jeff Dike
Cc: Richard Weinberger
Cc: Anton Ivanov
Cc: linux...@lists.infradead.org
---
arch/um/include/asm/hardirq.h | 17 +
1 file changed, 1 insertion(+), 16
Nothing uses this anymore.
Signed-off-by: Thomas Gleixner
---
include/linux/irq_cpustat.h |4
1 file changed, 4 deletions(-)
--- a/include/linux/irq_cpustat.h
+++ b/include/linux/irq_cpustat.h
@@ -19,10 +19,6 @@
#ifndef __ARCH_IRQ_STAT
DECLARE_PER_CPU_ALIGNED(irq_cpustat_t
.
Signed-off-by: Thomas Gleixner
---
include/linux/hardirq.h |1 +
include/linux/preempt.h |6 +-
include/linux/sched.h |3 +++
3 files changed, 9 insertions(+), 1 deletion(-)
--- a/include/linux/hardirq.h
+++ b/include/linux/hardirq.h
@@ -6,6 +6,7 @@
#include
#include
#include
To allow reuse of the bulk of softirq processing code for RT and to avoid
#ifdeffery all over the place, split protections for various code sections
out into inline helpers so the RT variant can just replace them in one go.
Signed-off-by: Thomas Gleixner
---
kernel/softirq.c | 53
Soft interrupt disabled sections can legitimately be preempted or schedule
out when blocking on a lock on RT enabled kernels so the RCU preempt check
warning has to be disabled for RT kernels.
Signed-off-by: Thomas Gleixner
---
include/linux/rcupdate.h |3 ++-
1 file changed, 2 insertions
processing
thread. If the tasklet is processed on a different CPU then the
local_bh_disable()/enable() pair is just a waste of processor cycles.
Signed-off-by: Thomas Gleixner
---
include/linux/interrupt.h |8 ++--
kernel/softirq.c | 38 +-
2
To prepare for adding a RT aware variant of softirq serialization and
processing move related code into one section so the necessary #ifdeffery
is reduced to one.
Signed-off-by: Thomas Gleixner
---
kernel/softirq.c | 107 +++
1 file changed
A barrier() in a tight loop which waits for something to happen on a remote
CPU is a pointless exercise. Replace it with cpu_relax() which allows HT
siblings to make progress.
Signed-off-by: Thomas Gleixner
---
include/linux/interrupt.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion
Inlines exist for a reason.
Signed-off-by: Thomas Gleixner
---
include/linux/interrupt.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -672,9 +672,9 @@ static inline void tasklet_unlock_wait(s
irq_cpustat_t is exactly the same as the asm-generic one. Define
ack_bad_irq so the generic header does not emit the generic version of it.
Signed-off-by: Thomas Gleixner
Cc: Russell King
Cc: Marc Zyngier
Cc: Valentin Schneider
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/include
Provide a local lock based serialization for soft interrupts on RT which
allows the local_bh_disabled() sections and servicing soft interrupts to be
preemptible.
Provide the necessary inline helpers which allow to reuse the bulk of the
softirq processing code.
Signed-off-by: Thomas Gleixner
Add an optional __nmi_count member to irq_cpustat_t so more architectures
can use the generic version.
Signed-off-by: Thomas Gleixner
---
include/asm-generic/hardirq.h |3 +++
1 file changed, 3 insertions(+)
--- a/include/asm-generic/hardirq.h
+++ b/include/asm-generic/hardirq.h
@@ -7,6
nmi_count() is a historical leftover and SH is the only user. Replace it
with regular per cpu accessors.
Signed-off-by: Thomas Gleixner
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: linux...@vger.kernel.org
---
arch/sh/kernel/irq.c |2 +-
arch/sh/kernel/traps.c |2 +-
2 files changed, 2
Move the declaration of the irq_cpustat per cpu variable to
asm-generic/hardirq.h and remove the now empty linux/irq_cpustat.h header.
Signed-off-by: Thomas Gleixner
---
include/asm-generic/hardirq.h |3 ++-
include/linux/irq_cpustat.h | 24
2 files changed, 2
is
temporarily blocked as well which means that such a warning is a false
positive.
To prevent that check the per CPU state which indicates that a scheduled
out task has soft interrupts disabled.
Signed-off-by: Thomas Gleixner
---
include/linux/bottom_half.h |6 ++
kernel/softirq.c
the
softirq representation for RT just falls into place.
- Update comments and move the deprecated macros aside
Signed-off-by: Thomas Gleixner
---
include/linux/preempt.h | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
--- a/include/linux/preempt.h
+++ b/include
RT runs softirq processing always in thread context and it requires that
both the softirq execution and the BH disabled sections are preemptible.
This is achieved by serialization through per CPU local locks and
substituting a few parts of the existing softirq processing code with
helper
This is a leftover from a historical array based implementation and unused.
Signed-off-by: Thomas Gleixner
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: linux-par...@vger.kernel.org
---
arch/parisc/include/asm/hardirq.h |1 -
1 file changed, 1 deletion(-)
--- a/arch/parisc/i
On Fri, Nov 13 2020 at 09:19, Marc Zyngier wrote:
> On 2020-11-12 21:34, Thomas Gleixner wrote:
>> That would allow to add a irq_find_matching_fwspec() based lookup to
>> pci_msi_get_device_domain().
>
> Just so that I understand the issue: is the core of the problem that
>
Max,
On Fri, Nov 13 2020 at 04:23, Max Filippov wrote:
> Fixmap on xtensa grows upwards, i.e. bigger fixmap entry index
> corresponds to a higher virtual address. This was lost in highmem
> generalization resulting in the following runtime warnings:
Sorry for not noticing.
> Fix it by adding
On Fri, Nov 13 2020 at 02:42, Kevin Tian wrote:
>> From: Thomas Gleixner
> CPUID#1_ECX is a x86 thing. Do we need to figure out probably_on_
> bare_metal for every architecture altogether, or is it OK to just
> handle it for x86 arch at this stage? Based on previous discussions
&g
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: ff828729be446b86957f7c294068758231cd2183
Gitweb:
https://git.kernel.org/tip/ff828729be446b86957f7c294068758231cd2183
Author:Thomas Gleixner
AuthorDate:Thu, 12 Nov 2020 20:14:16 +01:00
On Thu, Nov 12 2020 at 14:32, Konrad Rzeszutek Wilk wrote:
>> 4. Using CPUID to detect running as guest. But as Thomas pointed out, this
>> approach is less reliable as not all hypervisors do this way.
>
> Is that truly true? It is the first time I see the argument that extra
> steps are needed
On Thu, Nov 12 2020 at 20:15, Thomas Gleixner wrote:
> The recent changes to store the MSI irqdomain pointer in struct device
> missed that Intel DMAR does not register virtual function devices. Due to
> that a VF device gets the plain PCI-MSI domain assigned and then issues
> compat
mm/vt-d: Store irq domain in struct device")
Reported-by: Jason Gunthorpe
Signed-off-by: Thomas Gleixner
---
drivers/iommu/intel/dmar.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -333
On Thu, Nov 12 2020 at 08:26, Bjorn Helgaas wrote:
> On Thu, Nov 12, 2020 at 02:50:42PM +0100, Thomas Gleixner wrote:
>> So I had a closer look and the reason why it only matters for the
>> chained handler case is that
>>
>>__irq_set_handler(..., is_chained =
On Thu, Nov 12 2020 at 15:15, Thomas Gleixner wrote:
> On Thu, Nov 12 2020 at 08:55, Jason Gunthorpe wrote:
>> On Wed, Aug 26, 2020 at 01:16:28PM +0200, Thomas Gleixner wrote:
>> They were unable to bisect further into the series because some of the
>> interior commits don't
801 - 900 of 29421 matches
Mail list logo
