for no reason.
Split the handling function out and invoke it from both entry points.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/apic/apic.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel
RSP back
Document the unholy asm() logic while at it to reduce the amount of head
scratching required a half year from now.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/irq_stack.h | 104 +++
1 file changed, 104 insertions(+)
--- a/arch/x86/include
stack data type which
is on 64bit only used to declare the backing store. Move the definition
next to the inuse flag so they end up in the same cache line.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/irq_stack.h |6 +++---
arch/x86/include/asm/processor.h |7 +++
arch/x86/
The following commit has been merged into the timers/urgent branch of tip:
Commit-ID: ebb22a05943666155e6da04407cc6e913974c78c
Gitweb:
https://git.kernel.org/tip/ebb22a05943666155e6da04407cc6e913974c78c
Author:Thomas Gleixner
AuthorDate:Mon, 01 Feb 2021 20:24:17 +01:00
On Mon, Feb 01 2021 at 11:32, Linus Torvalds wrote:
> On Mon, Feb 1, 2021 at 11:24 AM Thomas Gleixner wrote:
>>
>> While it cures the problem on the reporters machine it breaks machines
>> with Intel chipsets which use bit 0-5 of the D register. So check only
>> for
: 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs")
Reported-by: Serge Belyshev
Reported-by: Dirk Gouders
Signed-off-by: Thomas Gleixner
---
V2: Provide the actual delta patch. Should have stayed away from
computers today
---
drivers/rtc/rtc-cmos.c |4 ++--
drive
: 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs")
Reported-by: Serge Belyshev
Reported-by: Dirk Gouders
Signed-off-by: Thomas Gleixner
---
drivers/rtc/rtc-cmos.c |8
drivers/rtc/rtc-mc146818-lib.c |7 +++
2 files changed, 15 insertions(+)
--- a/drive
Linus,
please pull the latest core/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
core-urgent-2021-01-31
up to: 41c1a06d1d15: entry: Unbreak single step reporting behaviour
A single fix for the single step reporting regression caused by getting the
condition
recent UIP handling changes the time readout of non-existent RTCs hangs
forever as the read returns always 0xFF which means the UIP bit is
set. Sanity check the RTC before registering by checking the RTC_VALID
register for correctness.
Thanks,
tglx
-->
Thomas Gleixner
On Fri, Jan 29 2021 at 10:08, Peter Zijlstra wrote:
> On Fri, Jan 29, 2021 at 12:28:41AM +0100, Thomas Gleixner wrote:
>
>> Add a test case which covers this scenario. This is modeled after the
>> WINE testcase, but changes the expect in step #2 to:
>>
>>- Ex
the GDB expectations are met as well.
Make it work for both 32 and 64 bit and fix the broken calculation of
number of tests for 32 bit as well.
Signed-off-by: Thomas Gleixner
---
tools/testing/selftests/breakpoints/breakpoint_test.c | 115 --
1 file changed, 107 insertions(+), 8
On Thu, Jan 28 2021 at 13:59, Marcelo Tosatti wrote:
>> The whole pile wants to be reverted. It's simply broken in several ways.
>
> I was asking for your comments on interaction with CPU hotplug :-)
Which I answered in an seperate mail :)
> So housekeeping_cpumask has multiple meanings. In this
Barry,
On Fri, Jan 08 2021 at 11:39, Barry Song wrote:
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index ab8567f32501..2b28314e2572 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -1693,6 +1693,9 @@ __setup_irq(unsigned int irq, struct irq_desc *desc,
> struct i
On Wed, Jan 27 2021 at 09:19, Marcelo Tosatti wrote:
> On Wed, Jan 27, 2021 at 11:57:16AM +, Robin Murphy wrote:
>> > + hk_flags = HK_FLAG_DOMAIN | HK_FLAG_MANAGED_IRQ;
>> > + mask = housekeeping_cpumask(hk_flags);
>>
>> AFAICS, this generally resolves to something based on cpu_possible_mask
On Wed, Jan 27 2021 at 10:09, Marcelo Tosatti wrote:
> On Wed, Jan 27, 2021 at 12:36:30PM +, Robin Murphy wrote:
>> > > >/**
>> > > > * cpumask_next - get the next cpu in a cpumask
>> > > > @@ -205,22 +206,27 @@ void __init
>> > > > free_bootmem_cpumask_var(cpumask_var_t mask)
>> > > >
On Wed, Jan 27 2021 at 20:55, Gabriel Krisman Bertazi wrote:
> Yuxuan Shui writes:
>
> To gather the right attention, you should directly CC the correct
> maintainers.
You could have cc'ed them on your reply
> Fixes: 64eb35f701f0 ("ptrace: Migrate TIF_SYSCALL_EMU to use SYSCALL_WORK
> flag
On Thu, Jan 28 2021 at 16:29, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> locking/core
> head: 997acaf6b4b59c6a9c259740312a69ea549cc684
> commit: 997acaf6b4b59c6a9c259740312a69ea549cc684 [10/10] lockdep: report
> broken irq restoration
> conf
Liu,
On Fri, Jan 22 2021 at 08:47, Liu Chao wrote:
> Replace the cpumask used in irq_calc_affinity_vectors from all possible
> CPUs to only housekeeping CPUs.
>
> When we have isolated CPUs used by real-time tasks, IRQs will be move to
> housekeeping CPUs.
No.
> If there are too many IRQ vectors
Fenghua,
On Wed, Jan 27 2021 at 22:39, Fenghua Yu wrote:
>> On Wed, Jan 27, 2021 2:16 PM, Thomas Gleixner wrote:
>> On Tue, Nov 24 2020 at 20:52, Fenghua Yu wrote:
>>
>> > A bus lock is acquired though either split locked access to writeback
>> > (WB) memory o
On Tue, Nov 24 2020 at 20:52, Fenghua Yu wrote:
> Since #DB for bus lock detect changes the split_lock_detect parameter,
> update the documentation for the changes.
Why is this seperate and an all in one thing? patch 2/4 changes the
parameter first and 3/4 adds a new option
>
> Signed-off-by:
On Tue, Nov 24 2020 at 20:52, Fenghua Yu wrote:
> To enforce user application throttling or mitigations, extend the
> existing split lock detect kernel parameter:
> split_lock_detect=ratelimit:N
>
> It limits bus lock rate to N per second for non-root users.
Yet another changelog which descr
On Tue, Nov 24 2020 at 20:52, Fenghua Yu wrote:
> #DB for bus lock is enabled by bus lock detection bit 2 in DEBUGCTL MSR
> while #AC for split lock is enabled by split lock detection bit 29 in
> TEST_CTRL MSR.
>
> Delivery of #DB for bus lock in userspace clears DR6[11]. To avoid
> confusion in i
On Tue, Nov 24 2020 at 20:52, Fenghua Yu wrote:
> A bus lock is acquired though either split locked access to
> writeback (WB) memory or any locked access to non-WB memory. This is
> typically >1000 cycles slower than an atomic operation within a cache
> line. It also disrupts performance on other
The following commit has been merged into the timers/urgent branch of tip:
Commit-ID: 211e5db19d15a721b2953ea54b8f26c2963720eb
Gitweb:
https://git.kernel.org/tip/211e5db19d15a721b2953ea54b8f26c2963720eb
Author:Thomas Gleixner
AuthorDate:Tue, 26 Jan 2021 18:02:11 +01:00
The following commit has been merged into the locking/urgent branch of tip:
Commit-ID: 2156ac1934166d6deb6cd0f6ffc4c1076ec63697
Gitweb:
https://git.kernel.org/tip/2156ac1934166d6deb6cd0f6ffc4c1076ec63697
Author:Thomas Gleixner
AuthorDate:Wed, 20 Jan 2021 11:32:07 +01:00
The following commit has been merged into the locking/urgent branch of tip:
Commit-ID: f2dac39d93987f7de1e20b3988c8685523247ae2
Gitweb:
https://git.kernel.org/tip/f2dac39d93987f7de1e20b3988c8685523247ae2
Author:Thomas Gleixner
AuthorDate:Tue, 19 Jan 2021 16:26:38 +01:00
The following commit has been merged into the locking/urgent branch of tip:
Commit-ID: 12bb3f7f1b03d5913b3f9d4236a488aa7774dfe9
Gitweb:
https://git.kernel.org/tip/12bb3f7f1b03d5913b3f9d4236a488aa7774dfe9
Author:Thomas Gleixner
AuthorDate:Wed, 20 Jan 2021 16:00:24 +01:00
The following commit has been merged into the locking/urgent branch of tip:
Commit-ID: 04b79c55201f02ffd675e1231d731365e335c307
Gitweb:
https://git.kernel.org/tip/04b79c55201f02ffd675e1231d731365e335c307
Author:Thomas Gleixner
AuthorDate:Tue, 19 Jan 2021 16:06:10 +01:00
The following commit has been merged into the locking/urgent branch of tip:
Commit-ID: c5cade200ab9a2a3be9e7f32a752c8d86b502ec7
Gitweb:
https://git.kernel.org/tip/c5cade200ab9a2a3be9e7f32a752c8d86b502ec7
Author:Thomas Gleixner
AuthorDate:Tue, 19 Jan 2021 15:21:35 +01:00
The following commit has been merged into the locking/urgent branch of tip:
Commit-ID: 34b1a1ce1458f50ef27c54e28eb9b1947012907a
Gitweb:
https://git.kernel.org/tip/34b1a1ce1458f50ef27c54e28eb9b1947012907a
Author:Thomas Gleixner
AuthorDate:Mon, 18 Jan 2021 19:01:21 +01:00
The following commit has been merged into the locking/urgent branch of tip:
Commit-ID: 6ccc84f917d33312eb2846bd7b567639f585ad6d
Gitweb:
https://git.kernel.org/tip/6ccc84f917d33312eb2846bd7b567639f585ad6d
Author:Thomas Gleixner
AuthorDate:Wed, 20 Jan 2021 11:35:19 +01:00
_time data.
Reported-by: Mickaël Salaün
Signed-off-by: Thomas Gleixner
Tested-by: Mickaël Salaün
---
V2: Fixed the sizeof() as spotted by Mickaël
---
drivers/rtc/rtc-cmos.c |8
drivers/rtc/rtc-mc146818-lib.c |7 +++
2 files changed, 15 insertions(+)
--- a/drivers/rtc/rtc-cm
On Tue, Jan 26 2021 at 15:17, Mickaël Salaün wrote:
> Thanks for the fix! It boots now with a new message:
> rtc_cmos rtc_cmos: not accessible
>> spin_lock_irqsave(&rtc_lock, flags);
>> +/* Ensure that the RTC is accessible. Bit 0-6 must be 0! */
>> +if (WARN_ON_ONCE((CMOS_READ(RTC_VAL
there is no RTC and therefore the CMOS_READ($REG) returns
0xFF which makes the loop stuck because RTC_UIP is always set.
Yet another proof that VIRT creates more problems than it solves.
Fix below.
Thanks,
tglx
---
Subject: rtc: mc146818: Detect and handle broken RTCs
From: Thomas Gleixner
David,
On Tue, Jan 19 2021 at 12:12, David Woodhouse wrote:
> On Tue, 2020-12-15 at 22:20 +0100, Thomas Gleixner wrote:
> We've been playing with this a little. There's a proof-of-concept hack
> below; don't look too hard because it's only really for figuring out
&g
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: ce09ccc50208c04a1b03abfd530b5d6314258fd0
Gitweb:
https://git.kernel.org/tip/ce09ccc50208c04a1b03abfd530b5d6314258fd0
Author:Thomas Gleixner
AuthorDate:Wed, 13 Jan 2021 15:43:18 +01:00
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: 4bae052dde14c5538eca39592777b1d1987234ba
Gitweb:
https://git.kernel.org/tip/4bae052dde14c5538eca39592777b1d1987234ba
Author:Thomas Gleixner
AuthorDate:Tue, 12 Jan 2021 21:23:55 +01:00
eported-by: Andreas Larsson
Signed-off-by: Thomas Gleixner
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
---
arch/sparc/include/asm/highmem.h |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/arch/sparc/include/asm/highmem.h
+++ b/arch/sparc/include/asm/highme
ned-off-by: Thomas Gleixner
Cc: Michael Ellerman
Cc: linuxppc-...@lists.ozlabs.org
---
arch/powerpc/include/asm/highmem.h |2 ++
1 file changed, 2 insertions(+)
--- a/arch/powerpc/include/asm/highmem.h
+++ b/arch/powerpc/include/asm/highmem.h
@@ -58,6 +58,8 @@ extern pte_t *pkmap_page_table;
ned-off-by: Thomas Gleixner
---
arch/mips/include/asm/highmem.h |1 +
1 file changed, 1 insertion(+)
--- a/arch/mips/include/asm/highmem.h
+++ b/arch/mips/include/asm/highmem.h
@@ -51,6 +51,7 @@ extern void kmap_flush_tlb(unsigned long
#define flush_cache_kmaps()BUG_ON(cpu_has_
The kmap_local conversion wreckaged sparc, mips and powerpc as it missed
some of the details in the original implementation.
The following series addresses that.
Thanks,
tglx
---
arch/mips/include/asm/highmem.h |1 +
arch/sparc/include/asm/highmem.h |9 +
b/arch
The generic kmap_local() map function uses set_pte_at(), but MIPS requires
set_pte() and PowerPC wants __set_pte_at().
Provide arch_kmap_local_set_pte() and default it to set_pte_at().
Signed-off-by: Thomas Gleixner
---
mm/highmem.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion
On Sun, Dec 27 2020 at 11:20, Guenter Roeck wrote:
> On Thu, Dec 10, 2020 at 08:25:38PM +0100, Thomas Gleixner wrote:
> Yes, but that means that irq_check_status_bit() may be called from modules,
> but it is not exported, resulting in build errors such as the following.
>
> arm
On Tue, Dec 29 2020 at 20:41, Geert Uytterhoeven wrote:
> Hi Thomas,
>> Reported-by: Miroslav Lichvar
>> Signed-off-by: Thomas Gleixner
>
> Thanks for your patch, which is now commit c9e6189fb03123a7 ("ntp: Make
> the RTC synchronization more reliable").
>
&g
On Fri, Jan 08 2021 at 12:46, Peter Zijlstra wrote:
> On Sat, Dec 26, 2020 at 10:51:08AM +0800, Lai Jiangshan wrote:
>> From: Lai Jiangshan
>>
>> 06249738a41a ("workqueue: Manually break affinity on hotplug")
>> said that scheduler will not force break affinity for us.
>
> So I've been looking at
event these things from creeping up again.
Thanks,
tglx
------>
Thomas Gleixner (30):
genirq: Move irq_has_action() into core code
genirq: Move status flag checks to core
genirq: Move irq_set_lockdep_class() to core
genirq: Provide irq_get_effective_
On Tue, Dec 22 2020 at 18:58, Andreas Larsson wrote:
> From as far as I have gotten into hunting down the problem, I get a
> failure from load_elf_binary here:
>
> /* First of all, some simple consistency checks */
> if (memcmp(elf_ex->e_ident, ELFMAG, SELFMAG) != 0)
> go
On Fri, Dec 18 2020 at 13:58, Dan Williams wrote:
> On Fri, Dec 18, 2020 at 1:06 PM Thomas Gleixner wrote:
>> kmap_local() is fine. That can work automatically because it's strict
>> local to the context which does the mapping.
>>
>> kmap() is dubious because it&
On Fri, Dec 18 2020 at 11:42, Ira Weiny wrote:
> On Fri, Dec 18, 2020 at 02:57:51PM +0100, Thomas Gleixner wrote:
>> 2) Modify kmap() so that it marks the to be mapped page as 'globaly
>> unprotected' instead of doing this global unprotect PKS dance.
>>
On Fri, Dec 18 2020 at 11:20, Dan Williams wrote:
> On Fri, Dec 18, 2020 at 5:58 AM Thomas Gleixner wrote:
> [..]
>> 5) The DAX case which you made "work" with dev_access_enable() and
>> dev_access_disable(), i.e. with yet another lazy approach of
>>
On Thu, Dec 17 2020 at 23:43, Thomas Gleixner wrote:
> The only use case for this in your tree is: kmap() and the possible
> usage of that mapping outside of the thread context which sets it up.
>
> The only hint for doing this at all is:
>
> Some users, such as kmap(), some
On Thu, Dec 17 2020 at 15:50, Thomas Gleixner wrote:
> On Fri, Nov 06 2020 at 15:29, ira weiny wrote:
>
>> +void write_pkrs(u32 new_pkrs)
>> +{
>> +u32 *pkrs;
>> +
>> +if (!static_cpu_has(X86_FEATURE_PKS))
>> +return;
>> +
>>
"x86/entry: Unbreak 32bit fast syscall")
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/common.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -130,8 +130,10 @@ static noinstr bool __do_fast_syscall_32
On Mon, Nov 23 2020 at 22:09, ira weiny wrote:
> From: Ira Weiny
>
> Currently struct irqentry_state_t only contains a single bool value
> which makes passing it by value is reasonable. However, future patches
> add information to this struct. This includes the PKRS thread state,
> included in t
On Fri, Nov 06 2020 at 15:29, ira weiny wrote:
> +#ifdef CONFIG_ARCH_HAS_SUPERVISOR_PKEYS
> +/*
> + * PKRS is a per-logical-processor MSR which overlays additional protection
> for
> + * pages which have been mapped with a protection key.
> + *
> + * The register is not maintained with XSAVE so we
On Fri, Nov 06 2020 at 15:29, ira weiny wrote:
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -43,6 +43,7 @@
> #include
> #include
> #include
> +#include
>
> #include "process.h"
>
> @@ -187,6 +188,27 @@ int copy_thread(unsigned long clone_flags, unsigned long
On Fri, Dec 11 2020 at 14:14, Andy Lutomirski wrote:
> On Mon, Nov 23, 2020 at 10:10 PM wrote:
> After contemplating this for a bit, I think this isn't really the
> right approach. It *works*, but we've mostly just created a bit of an
> unfortunate situation. Our stack, on a (possibly nested) en
On Wed, Dec 16 2020 at 13:19, Paul E. McKenney wrote:
> On Wed, Dec 16, 2020 at 01:27:43AM +0100, Thomas Gleixner wrote:
>> So my intent was to document that this code does not care about anything
>> else than what I'd consider to be plain compiler bugs.
>>
>>
On Sat, Dec 12 2020 at 22:29, Randy Dunlap wrote:
> Little to my knowledge, this came up with
> CONFIG_PHYSICAL_START=0x8100
...
> I tracked it down to this large value of CONFIG_PHYSICAL_START
> and changed it back to its default value, then the kernel
> built with no problems.
>
> So far I ha
Kai,
On Wed, Dec 16 2020 at 22:18, shenkai wrote:
> After some tests, the conclusion that time cost is from deep C-state
> turns out to be wrong
>
> Sorry for that.
No problem.
> In kexec case, first let APs spinwait like what I did in that patch,
> but wake APs up by sending apic INIT and SIP
On Wed, Dec 16 2020 at 15:55, Naresh Kamboju wrote:
> On Tue, 15 Dec 2020 at 23:52, Jakub Kicinski wrote:
>> > Or you could place checks for being in a BH-disable further up in
>> > the code. Or build with CONFIG_DEBUG_INFO=y to allow more precise
>> > interpretation of this stack trace.
>
> I wi
The following commit has been merged into the timers/urgent branch of tip:
Commit-ID: f12ad423c4af877b2e4b5a80928b95195fccab04
Gitweb:
https://git.kernel.org/tip/f12ad423c4af877b2e4b5a80928b95195fccab04
Author:Thomas Gleixner
AuthorDate:Sun, 06 Dec 2020 22:12:54 +01:00
The following commit has been merged into the timers/urgent branch of tip:
Commit-ID: ba8ea8e7dd6e1662e34e730eadfc52aa6816f9dd
Gitweb:
https://git.kernel.org/tip/ba8ea8e7dd6e1662e34e730eadfc52aa6816f9dd
Author:Thomas Gleixner
AuthorDate:Sun, 06 Dec 2020 22:12:55 +01:00
Kai,
On Wed, Dec 16 2020 at 16:45, shenkai wrote:
> 在 2020/12/16 5:20, Thomas Gleixner 写道:
>>
>>
> Thanks for your and Andy's precious comments. I would like to take a try on
>
> reconstructing this patch to make it more decent and generic.
>> It would be inter
On Wed, Dec 16 2020 at 09:19, Peter Zijlstra wrote:
> On Tue, Dec 15, 2020 at 06:52:49PM +0100, Thomas Gleixner wrote:
>> I might be missing something, but how is the CPU which runs the pinned
>> kernel thread, i.e. the hotplug thread, supposed to go idle between the
>> two ca
On Tue, Dec 08 2020 at 07:03, Paul E. McKenney wrote:
> On Tue, Dec 08, 2020 at 09:11:29AM +0100, Peter Zijlstra wrote:
>> On Mon, Dec 07, 2020 at 11:44:06AM -0800, Paul E. McKenney wrote:
>>
>> > Also, in this particular case, why data_race() rather than READ_ONCE()?
>> > Do we really expect the
On Tue, Dec 15 2020 at 07:59, Marcelo Tosatti wrote:
> On Fri, Dec 11, 2020 at 10:59:59PM +0100, Paolo Bonzini wrote:
>> So it's still true that the time advances during live migration brownout;
>> 0.1 seconds is just the final part of the live migration process. But for
>> _live_ migration there
On Tue, Dec 15 2020 at 21:12, Enrico Weigelt wrote:
> On 09.12.20 00:01, Thomas Gleixner wrote:
>> 3) It's invoked from __handle_domain_irq() when the 'hwirq' which is
>> handed in by the caller does not resolve to a mapped Linux
>> interrupt whic
On Tue, Dec 15 2020 at 08:31, Andy Lutomirski wrote:
> On Tue, Dec 15, 2020 at 6:46 AM shenkai (D) wrote:
>>
>> From: shenkai
>> Date: Tue, 15 Dec 2020 01:58:06 +
>> Subject: [PATCH] use x86 cpu park to speedup smp_init in kexec situation
>>
>> In kexec reboot on x86 machine, APs will be halt
On Tue, Dec 15 2020 at 16:05, Peter Zijlstra wrote:
> On Tue, Dec 15, 2020 at 09:34:15AM -0500, Steven Rostedt wrote:
>> On Tue, 15 Dec 2020 15:23:39 +0100 (CET)
>> Anna-Maria Behnsen wrote:
>>
>> > > > + /*
>> > > > + * Remove CPU from nohz.idle_cpus_mask to prevent participating
>>
3-its: Flag device allocation as proxied if behind a PCI
bridge
Mauro Carvalho Chehab (1):
genirq: Fix kernel-doc markups
Shenming Lu (1):
irqchip/gic-v4.1: Reduce the delay when polling GICR_VPENDBASER.Dirty
Thomas Gleixner (13):
genirq: Remove GENERIC_IRQ_LEGACY_ALLOC_HWIRQ
On Mon, Dec 14 2020 at 18:02, Linus Torvalds wrote:
> On Mon, Dec 14, 2020 at 12:25 PM Thomas Gleixner wrote:
>>
>>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
>> irq-core-2020-12-14
>
> What?
>
> This is completely broken, and doesn't
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 3dcb8b53cbd2cc5618863b19ef00f8ea82f27e83
Gitweb:
https://git.kernel.org/tip/3dcb8b53cbd2cc5618863b19ef00f8ea82f27e83
Author:Thomas Gleixner
AuthorDate:Tue, 15 Dec 2020 12:14:38 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 3c41e57a1e168d879e923c5583adeae47eec9f64
Gitweb:
https://git.kernel.org/tip/3c41e57a1e168d879e923c5583adeae47eec9f64
Author:Thomas Gleixner
AuthorDate:Tue, 15 Dec 2020 10:48:07 +01:00
Shuah,
On Mon, Dec 14 2020 at 13:57, Shuah Khan wrote:
> On 12/14/20 1:41 PM, Thomas Gleixner wrote:
> Here is the processor and BIOS info:
> AMD Ryzen 7 4700G with Radeon Graphics
> LENOVO ThinkCentre Embedded Controller -[O4ZCT12A-1.12]-
> LENOVO ThinkCentre BIOS Boot Bloc
On Mon, Dec 14 2020 at 21:41, Thomas Gleixner wrote:
> On Mon, Dec 14 2020 at 09:11, Shuah Khan wrote:
>> On 12/12/20 12:33 PM, Thomas Gleixner wrote:
>>> On Fri, Dec 11 2020 at 13:41, Shuah Khan wrote:
>>>
>>>> I am debugging __common_interrupt: 1.55 No i
On Mon, Dec 14 2020 at 09:11, Shuah Khan wrote:
> On 12/12/20 12:33 PM, Thomas Gleixner wrote:
>> On Fri, Dec 11 2020 at 13:41, Shuah Khan wrote:
>>
>>> I am debugging __common_interrupt: 1.55 No irq handler for vector
>>> messages and noticed comments and code do
Linus,
please pull the latest efi/core branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-core-2020-12-14
up to: 54649911f31b: efi: stub: get rid of efi_get_max_fdt_addr()
EFI updates collected by Ard Biesheuvel:
- Don't move BSS section around pointlessly in the
FPU protections
Thanks,
tglx
-->
Thomas Gleixner (2):
x86/fpu: Simplify fpregs_[un]lock()
x86/fpu: Make kernel FPU protection RT friendly
arch/x86/include/asm/fpu/api.h | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --
Linus,
please pull the latest perf/kprobes branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-kprobes-2020-12-14
up to: a70a04b3844f: locking/atomics: Regenerate the atomics-check SHA1's
perf/kprobes updates:
- Make kretprobes lockless to avoid the rp->lock perf
x86: Wire up TIF_NOTIFY_SIGNAL
Sven Schnelle (5):
entry: Rename enter_from_user_mode()
entry: Rename exit_to_user_mode()
entry_Add_enter_from_user_mode_wrapper
entry: Add exit_to_user_mode() wrapper
entry: Add syscall_exit_to_user_mode_work()
Thomas Gle
lho Chehab (1):
hrtimer: Fix kernel-doc markups
Niklas Söderlund (1):
clocksource/drivers/sh_cmt: Fix potential deadlock when calling runtime PM
Sebastian Andrzej Siewior (1):
timers: Don't block on ->expiry_lock for TIMER_IRQSAFE timers
Thomas Gleixner (16):
timekeep
Linus,
please pull the latest perf/core branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-core-2020-12-14
up to: c2208046bba6: perf/x86/intel: Add Tremont Topdown support
Perf updates:
Core:
- Better handling of page table leaves on archictectures which ha
Linus,
On Mon, Dec 14 2020 at 20:22, Thomas Gleixner wrote:
> Linus,
>
> please pull the latest efi/core branch from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> efi-core-2020-12-14
please ignore this one. There is some last minute unclear issue wit
ID check from hyperv_irq_remapping_select()
Thomas Gleixner (18):
x86/apic/uv: Fix inconsistent destination mode
x86/devicetree: Fix the ioapic interrupt type table
x86/apic: Cleanup delivery mode defines
x86/apic: Replace pointless apic:: Dest_logical usage
x86/apic: Ge
Linus,
please pull the latest locking/core branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-core-2020-12-14
up to: cb262935a166: seqlock: kernel-doc: Specify when preemption is
automatically altered
A moderate set of locking updates:
- A few extensions to
of PMD_FLAGS_DEC_WP
Masami Hiramatsu (1):
x86/kprobes: Fix optprobe to detect INT3 padding correctly
Thomas Gleixner (1):
x86/apic/vector: Fix ordering in vector assignment
Xiaochen Shen (1):
x86/resctrl: Fix incorrect local bandwidth when mba_sc is enabled
arch/x86/include/
The following commit has been merged into the irq/core branch of tip:
Commit-ID: d11e2d4fc53d68c1f94b294b97838b78fac5763f
Gitweb:
https://git.kernel.org/tip/d11e2d4fc53d68c1f94b294b97838b78fac5763f
Author:Thomas Gleixner
AuthorDate:Sun, 13 Dec 2020 13:49:30 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 3bda84519c6c2d57e7378417ac116f61d50abae1
Gitweb:
https://git.kernel.org/tip/3bda84519c6c2d57e7378417ac116f61d50abae1
Author:Thomas Gleixner
AuthorDate:Sun, 13 Dec 2020 14:33:57 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 5684f2a950727020ebaece04fe89e00d04e3b479
Gitweb:
https://git.kernel.org/tip/5684f2a950727020ebaece04fe89e00d04e3b479
Author:Thomas Gleixner
AuthorDate:Sun, 13 Dec 2020 14:08:51 +01:00
On Sat, Dec 12 2020 at 13:26, Marco Elver wrote:
> On Thu, Mar 07, 2019 at 10:14AM +0100, Arnd Bergmann wrote:
>> -static void __init futex_detect_cmpxchg(void)
>> +static noinline void futex_detect_cmpxchg(void)
>> {
>> #ifndef CONFIG_HAVE_FUTEX_CMPXCHG
>> u32 curval;
>
> What ever happened
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 559db8c7e6ed1f24baf7264a6966ee4f051c6446
Gitweb:
https://git.kernel.org/tip/559db8c7e6ed1f24baf7264a6966ee4f051c6446
Author:Thomas Gleixner
AuthorDate:Sat, 12 Dec 2020 20:35:24 +01:00
On Fri, Dec 11 2020 at 13:41, Shuah Khan wrote:
> I am debugging __common_interrupt: 1.55 No irq handler for vector
> messages and noticed comments and code don't agree:
I bet that's on an AMD system with broken AGESA BIOS Good luck
debugging it :) BIOS updates are on the way so I'm told.
>
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 9b23ffcbfa15f2d4959eaa42faae11e3e39d027a
Gitweb:
https://git.kernel.org/tip/9b23ffcbfa15f2d4959eaa42faae11e3e39d027a
Author:Thomas Gleixner
AuthorDate:Thu, 10 Dec 2020 20:26:02 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 3d18847680102182fed60b90ae65cbbb3d929a3c
Gitweb:
https://git.kernel.org/tip/3d18847680102182fed60b90ae65cbbb3d929a3c
Author:Thomas Gleixner
AuthorDate:Thu, 10 Dec 2020 20:25:58 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: f23130b1af7bccb23dff1e9223d826869c2ad45d
Gitweb:
https://git.kernel.org/tip/f23130b1af7bccb23dff1e9223d826869c2ad45d
Author:Thomas Gleixner
AuthorDate:Thu, 10 Dec 2020 20:25:57 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: f07147b162a1cec348d8a9a7e7e73fdf7ce5f88b
Gitweb:
https://git.kernel.org/tip/f07147b162a1cec348d8a9a7e7e73fdf7ce5f88b
Author:Thomas Gleixner
AuthorDate:Thu, 10 Dec 2020 20:26:06 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: ca00c76aa8acf5a7563dd9f5020f9c6dc9a0577d
Gitweb:
https://git.kernel.org/tip/ca00c76aa8acf5a7563dd9f5020f9c6dc9a0577d
Author:Thomas Gleixner
AuthorDate:Thu, 10 Dec 2020 20:25:59 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 26599cd34323b73894ebcb5197693cdd668b4aa8
Gitweb:
https://git.kernel.org/tip/26599cd34323b73894ebcb5197693cdd668b4aa8
Author:Thomas Gleixner
AuthorDate:Thu, 10 Dec 2020 20:26:01 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 16b2efd9e4c60f9010f27ada31b0c7d73f23e0d3
Gitweb:
https://git.kernel.org/tip/16b2efd9e4c60f9010f27ada31b0c7d73f23e0d3
Author:Thomas Gleixner
AuthorDate:Thu, 10 Dec 2020 20:26:00 +01:00
401 - 500 of 7668 matches
Mail list logo