offset needs to be retained for the life of the syscall,
> which means it needs to happen at the actual entry point).
>
> Signed-off-by: Kees Cook
Reviewed-by: Thomas Gleixner
Len,
On Mon, Mar 29 2021 at 18:16, Len Brown wrote:
> On Mon, Mar 29, 2021 at 2:49 PM Thomas Gleixner wrote:
> Let me know if this problem description is fair:
>
> Many-core Xeon servers will support AMX, and when I run an AMX application
> on one, when I take an interrupt with AM
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: 9a98bc2cf08a095367449b3548c3d9ad4ad2cd20
Gitweb:
https://git.kernel.org/tip/9a98bc2cf08a095367449b3548c3d9ad4ad2cd20
Author:Thomas Gleixner
AuthorDate:Thu, 18 Mar 2021 20:26:48 +01:00
On Mon, Mar 29 2021 at 13:25, Jindong Yue wrote:
> /*
> * Debugging: see timer_list.c
> @@ -115,8 +116,20 @@ void tick_install_broadcast_device(struct
> clock_event_device *dev)
>* notification the systems stays stuck in periodic mode
>* forever.
>*/
> - if
Waiman,
On Mon, Mar 29 2021 at 15:57, Waiman Long wrote:
> On 3/29/21 8:42 AM, Thomas Gleixner wrote:
>> On Sun, Mar 28 2021 at 20:52, Waiman Long wrote:
>>> It was found that the following circular locking dependency warning
>>> could happen in some sys
On Mon, Mar 29 2021 at 11:43, Len Brown wrote:
> On Mon, Mar 29, 2021 at 9:33 AM Thomas Gleixner wrote:
> But yes, if a bare metal OS doesn't support any threading libraries
> that query XCR0 with xgetbv, and they don't care about the performance
> impact of switching XCR0, they
On Mon, Mar 29 2021 at 08:36, Richard Cochran wrote:
> On Mon, Mar 29, 2021 at 04:57:55PM +0200, Thomas Gleixner wrote:
>> I think adjtimex is the right place and not yet another random file
>> somewhere. Something like the below.
>
> Perfect.
>
> Acked-by: Richar
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 8188d74e68174b11ff7c4a635ffc8fd31eacc6b9
Gitweb:
https://git.kernel.org/tip/8188d74e68174b11ff7c4a635ffc8fd31eacc6b9
Author:Thomas Gleixner
AuthorDate:Fri, 26 Mar 2021 16:29:34 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: fae37feee096bd3c85f6453713131a471404c6f5
Gitweb:
https://git.kernel.org/tip/fae37feee096bd3c85f6453713131a471404c6f5
Author:Thomas Gleixner
AuthorDate:Fri, 26 Mar 2021 16:29:35 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: f5a98866e506a816f6a855df1e7ed41e1891ec66
Gitweb:
https://git.kernel.org/tip/f5a98866e506a816f6a855df1e7ed41e1891ec66
Author:Thomas Gleixner
AuthorDate:Fri, 26 Mar 2021 16:29:38 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: f7efc4799f8114ba85b68584f83293f435009de4
Gitweb:
https://git.kernel.org/tip/f7efc4799f8114ba85b68584f83293f435009de4
Author:Thomas Gleixner
AuthorDate:Fri, 26 Mar 2021 16:29:36 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: f41dcc18698e660668a33cde8ab965e0298ac341
Gitweb:
https://git.kernel.org/tip/f41dcc18698e660668a33cde8ab965e0298ac341
Author:Thomas Gleixner
AuthorDate:Fri, 26 Mar 2021 16:29:39 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 37350e3b2655eb0fce4e0e6ce8ce631c781136fe
Gitweb:
https://git.kernel.org/tip/37350e3b2655eb0fce4e0e6ce8ce631c781136fe
Author:Thomas Gleixner
AuthorDate:Fri, 26 Mar 2021 16:29:37 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: c2c360ed7f28fd6b7eb7e39e70af2d2ae405f466
Gitweb:
https://git.kernel.org/tip/c2c360ed7f28fd6b7eb7e39e70af2d2ae405f466
Author:Thomas Gleixner
AuthorDate:Fri, 26 Mar 2021 16:29:43 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: d7a2edb890c0bfe467140c0cd79fe7cf65249376
Gitweb:
https://git.kernel.org/tip/d7a2edb890c0bfe467140c0cd79fe7cf65249376
Author:Thomas Gleixner
AuthorDate:Fri, 26 Mar 2021 16:29:40 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 70c80103aafdeae99126694bc1cd54de016bc258
Gitweb:
https://git.kernel.org/tip/70c80103aafdeae99126694bc1cd54de016bc258
Author:Thomas Gleixner
AuthorDate:Fri, 26 Mar 2021 16:29:41 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: a51a327f3bcdcb1a37ed9325ad07e1456cd4d426
Gitweb:
https://git.kernel.org/tip/a51a327f3bcdcb1a37ed9325ad07e1456cd4d426
Author:Thomas Gleixner
AuthorDate:Fri, 26 Mar 2021 16:29:44 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 82cd5b1039e26b1b1254886464991e34de439ac5
Gitweb:
https://git.kernel.org/tip/82cd5b1039e26b1b1254886464991e34de439ac5
Author:Thomas Gleixner
AuthorDate:Fri, 26 Mar 2021 16:29:42 +01:00
On Mon, Mar 29 2021 at 07:26, Richard Cochran wrote:
> On Mon, Mar 29, 2021 at 11:16:48AM +0200, Miroslav Lichvar wrote:
>> There are at least two issues with handling a zero offset as a special
>> value. One is that zero could potentially be a valid value in distant
>> future.
>
> I not losing
On Mon, Mar 29 2021 at 09:31, Len Brown wrote:
> On Sat, Mar 27, 2021 at 6:20 PM Thomas Gleixner wrote:
>
>> What's the actual downside of issuing TILERELEASE conditionally
>> depending on prev->AMX INIT=0? Is it slow or what's the real
>> problem here?
On Mon, Mar 29 2021 at 09:14, Len Brown wrote:
> On Sat, Mar 20, 2021 at 6:14 PM Thomas Gleixner wrote:
>>
>> On Sun, Feb 21 2021 at 10:56, Chang S. Bae wrote:
>> > +
>> > +/* Update MSR IA32_XFD with xfirstuse_not_detected() if needed. */
>> > +static in
Waiman,
On Sun, Mar 28 2021 at 20:52, Waiman Long wrote:
> It was found that the following circular locking dependency warning
> could happen in some systems:
>
> [ 218.097878] ==
> [ 218.097879] WARNING: possible circular locking dependency
On Sun, Mar 28 2021 at 23:58, Willy Tarreau wrote:
> On Sun, Mar 28, 2021 at 11:14:05PM +0300, Andy Shevchenko wrote:
>> Where did you get an idea that it had 64-bit SoC from?
>
> It's an N2600, and I bought this laptop because N2600 supports 64-bit
> (and do have another mini-itx motherboard at
Waiman,
On Sun, Mar 28 2021 at 15:58, Waiman Long wrote:
> It was found that the following circular locking dependency warning
> could happen in some systems:
>
> [ 218.097878] ==
> [ 218.097879] WARNING: possible circular locking dependency
On Fri, Jan 29 2021 at 13:17, Chris Friesen wrote:
> I have a CentOS 7 linux system with 48 logical CPUs and a number of
Kernel version?
> Intel NICs running the i40e driver. It was booted with
> irqaffinity=0-1,24-25 in the kernel boot args, resulting in
> /proc/irq/default_smp_affinity
Kees,
On Fri, Mar 19 2021 at 14:28, Kees Cook wrote:
> +/*
> + * Do not use this anywhere else in the kernel. This is used here because
> + * it provides an arch-agnostic way to grow the stack with correct
> + * alignment. Also, since this use is being explicitly masked to a max of
> + * 10 bits,
On Fri, Mar 19 2021 at 14:28, Kees Cook wrote:
> +
> + /*
> + * x86_64 stack alignment means 3 bits are ignored, so keep
> + * the top 5 bits. x86_32 needs only 2 bits of alignment, so
> + * the top 6 bits will be used.
> + */
> + choose_random_kstack_offset(rdtsc() &
On Sun, Mar 28 2021 at 00:25, Willy Tarreau wrote:
> On Sat, Mar 27, 2021 at 10:13:22PM +0100, Mateusz Jonczyk wrote:
> FWIW I tested on my ASUS 1025C which runs on an Atom N2600 forced to
> 32-bit. I had already tried in the past but wanted to give it a try
> again in case I'd have missed
Andy,
On Fri, Mar 26 2021 at 16:18, Andy Lutomirski wrote:
> arch_prctl(ARCH_SET_XCR0, xcr0, lazy_states, sigsave_states,
> sigclear_states, 0);
>
> Sets xcr0. All states are preallocated except that states in
> lazy_states may be unallocated in the kernel until used. (Not
> supported at all in
Len,
On Sat, Mar 27 2021 at 00:53, Len Brown wrote:
>> 3.3 RECOMMENDATIONS FOR SYSTEM SOFTWARE
>>
>> System software may disable use of Intel AMX by clearing XCR0[18:17],
>> by clearing CR4.OSXSAVE, or by setting
>> IA32_XFD[18]. It is recommended that system software initialize AMX
>> state
ret;
And the same for _cpu_down(), which obviously begs for a helper
function, which in turn needs tons of comments to explain why that place
is not a dump ground for random hacks of the day and what might if at
all be justified to be called there along with the implications of that
But that's a d
Len,
On Fri, Mar 26 2021 at 11:27, Len Brown wrote:
> On Thu, Mar 25, 2021 at 7:10 PM Dave Hansen wrote:
>> From some IRC chats with Thomaas and Andy, I think it's safe to say that
>> they're not comfortable blindly enabling even our "simple features". I
>> think we're going to need at least
The warning as written is expensive and not really required for a
production kernel. Make it depend on rt mutex debugging and use !in_task()
for the condition which generates far better code and gives the same
answer.
Signed-off-by: Thomas Gleixner
---
kernel/locking/rtmutex.c |2 +-
1 file
From: Thomas Gleixner
The signal handling in __rt_mutex_slowlock() is open coded.
Use signal_pending_state() instead.
Aside of the cleanup this also prepares for the RT lock substituions which
require support for TASK_KILLABLE.
Signed-off-by: Thomas Gleixner
---
kernel/locking/rtmutex.c
Preemption is disabled in mark_wakeup_next_waiter() not in
rt_mutex_slowunlock().
Signed-off-by: Thomas Gleixner
---
kernel/locking/rtmutex.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1305,7 +1305,7 @@ void
it
to the caller. The futex code uses a different function.
Signed-off-by: Thomas Gleixner
---
V2: Make lockdep work by design and not just by chance
---
kernel/locking/rtmutex.c | 144 +++
1 file changed, 59 insertions(+), 85 deletions(-)
--- a/kernel
make sense and mark
the rest __sched.
Signed-off-by: Thomas Gleixner
---
kernel/locking/rtmutex.c | 152 +++
1 file changed, 76 insertions(+), 76 deletions(-)
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -49,7 +49,7 @@
* set
The conditional debug handling is just another layer of obfuscation. Split
the function so rt_mutex_init_proxy_locked() can invoke the inner init and
__rt_mutex_init() gets the full treatment.
Signed-off-by: Thomas Gleixner
---
kernel/locking/rtmutex.c| 10 --
kernel/locking
There is no value in having two header files providing just empty stubs and
a C file which implements trivial debug functions which can just be inlined.
Signed-off-by: Thomas Gleixner
---
kernel/locking/Makefile |2 -
kernel/locking/rtmutex-debug.c | 65
None of these functions is used when CONFIG_RT_MUTEXES=n.
Remove the gunk. Remove pointless comments and clean up the coding style
mess while at it.
Signed-off-by: Thomas Gleixner
---
V2: Bring back the #ifdef and provide a proper stub for rt_mutex_owner()
which is used unconditionally
tter needs a seperate cleanup.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
include/linux/rtmutex.h |7 --
kernel/locking/rtmutex-debug.c | 97
kernel/locking/rtmutex-debug.h |9 ---
kernel/locking/rtmutex.c
No users or useless and therefore just ballast.
Signed-off-by: Thomas Gleixner
---
V2: Remove them properly
---
include/linux/rtmutex.h| 14 ++
kernel/locking/rtmutex-debug.c |9 -
kernel/locking/rtmutex-debug.h |3 ---
kernel/locking/rtmutex.c
Prepare for removing the header maze.
Signed-off-by: Thomas Gleixner
---
kernel/locking/rtmutex-debug.c |6 --
kernel/locking/rtmutex.c |8
2 files changed, 8 insertions(+), 6 deletions(-)
--- a/kernel/locking/rtmutex-debug.c
+++ b/kernel/locking/rtmutex-debug.c
There is no point for this wrapper at all.
Signed-off-by: Thomas Gleixner
---
kernel/locking/rtmutex.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -343,14 +343,9 @@ static void rt_mutex_adjust_prio(struct
(), no further usage
Remove them along with unused inlines and macros leftovers related to
the long gone deadlock tester.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
include/linux/rtmutex.h |7 ++-
kernel/locking/rtmutex-debug.c |7 +--
kernel
-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
include/linux/rtmutex.h | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
--- a/include/linux/rtmutex.h
+++ b/include/linux/rtmutex.h
@@ -43,6 +43,7 @@ struct hrtimer_sleeper;
extern int
This is V2 of this cleanup. V1 can be found here:
https://lore.kernel.org/r/87h7kydka0@nanos.tec.linutronix.de
While working on the rtmutex related RT bits we noticed quite some
inconsistencies and bitrot in the rtmutex code.
The series is based on
From: Sebastian Andrzej Siewior
rt_mutex_timed_lock() has no callers since commit c051b21f71d1f ("rtmutex:
Confine deadlock logic to futex")
Remove it.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
include/linux/rtmutex.h |3 ---
kernel/locking
On Fri, Mar 26 2021 at 10:32, Marc Zyngier wrote:
> On Thu, 25 Mar 2021 18:59:48 +,
> Thomas Gleixner wrote:
>> Though that leaves the question of the data type for 'val'. While u64 is
>> probably good enough for most stuff, anything which needs more than that
>> is
Daphne,
On Sat, Mar 13 2021 at 17:44, bugzilla-daemon wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=212265
I'm leaving the text from the BZ entry untrimmed so everyone on Cc is on
the same page.
> In order for CLOCK_TAI to function properly, a program (usually ntpd)
> has to use the
Len,
On Thu, Mar 25 2021 at 18:59, Len Brown wrote:
> On Sat, Mar 20, 2021 at 4:57 PM Thomas Gleixner wrote:
>
>> We won't enable features which are unknown ever. Keep that presilicon
>> test gunk where it belongs: In the Intel poison cabinet along with the
>> rest of th
On Thu, Mar 25 2021 at 19:11, Peter Zijlstra wrote:
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -3867,7 +3867,7 @@ static bool blk_mq_poll_hybrid(struct request_queue *q,
> int blk_poll(struct request_queue *q, blk_qc_t cookie, bool spin)
> {
> struct blk_mq_hw_ctx *hctx;
> -
On Thu, Mar 25 2021 at 17:43, Marc Zyngier wrote:
> On Fri, 26 Feb 2021 20:11:16 +,
> Megha Dey wrote:
>> +
>> +#include
>> +
>> +#ifdef CONFIG_IMS_MSI_ARRAY
>
> Given that this covers the whole driver, what is this #defined used
> for? You might as well make the driver depend on this config
On Thu, Mar 25 2021 at 17:23, Marc Zyngier wrote:
>> +/**
>> + * irq_set_auxdata - Set auxiliary data
>> + * @irq:Interrupt to update
>> + * @which: Selector which data to update
>> + * @auxval: Auxiliary data value
>> + *
>> + * Function to update auxiliary data for an interrupt, e.g. to
On Thu, Mar 25 2021 at 17:08, Marc Zyngier wrote:
> Megha Dey wrote:
>> @@ -434,6 +434,12 @@ int __msi_domain_alloc_irqs(struct irq_domain *domain,
>> struct device *dev,
>> if (ret)
>> return ret;
>>
>> +if (ops->msi_alloc_store) {
>> +ret =
On Thu, Mar 25 2021 at 18:55, Thomas Gleixner wrote:
> On Tue, Mar 23 2021 at 22:58, Heiko Carstens wrote:
>> Since commit d60d7de3e16d ("lib/vdso: Allow to add architecture-specific
>> vdso data") it is possible to provide arch specific VDSO data.
>>
>> This w
Therefore remove it again.
>
> Signed-off-by: Heiko Carstens
Please route that with the rest of the fixes.
Reviewed-by: Thomas Gleixner
On Tue, Mar 23 2021 at 17:38, Yang Li wrote:
> fixed the following coccicheck:
> ./kernel/irq/manage.c:2193:8-28: ERROR: Threaded IRQ with no primary
> handler requested without IRQF_ONESHOT
This fixes nothing because it's for a nested thread and not relevant to
that check at all.
Thanks,
On Thu, Mar 25 2021 at 16:34, Feng Tang wrote:
> On Wed, Mar 03, 2021 at 04:50:31PM +0100, Thomas Gleixner wrote:
>
> I've checked one open-sourced BIOS code project: EDK2
> (https://github.com/tianocore/edk2),
> where I did some grep and can't find places writting to tsc_adjust m
Manish,
On Wed, Mar 24 2021 at 22:18, Manish Varma wrote:
> On Mon, Mar 22, 2021 at 2:40 PM Thomas Gleixner wrote:
>>
>> Not that I expect any real dependencies on it, but as always the devil
>> is in the details.
>
> Right, there are some userspace which depends on
Dmitry,
On Tue, Mar 23 2021 at 15:44, Dmitry Torokhov wrote:
> On Thu, Mar 04, 2021 at 07:50:31PM +0100, Thomas Gleixner wrote:
>> Please hold on:
>>
>>
>> https://lkml.kernel.org/r/CAHk-=wgZjJ89jeH72TC3i6N%2Bz9WEY=3ysp8zr9narucsqca...@mail.gmail.com
>>
&g
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 1238b7032101ba420a114f64b86a8e3de609d0e8
Gitweb:
https://git.kernel.org/tip/1238b7032101ba420a114f64b86a8e3de609d0e8
Author:Thomas Gleixner
AuthorDate:Tue, 23 Mar 2021 22:30:25 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 3ac7d0ecf0e18b44c2c7dc968ce5afc5beadf17c
Gitweb:
https://git.kernel.org/tip/3ac7d0ecf0e18b44c2c7dc968ce5afc5beadf17c
Author:Thomas Gleixner
AuthorDate:Tue, 23 Mar 2021 22:30:33 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: c86c6bdd1099f398706b59b145148f3d39a587b7
Gitweb:
https://git.kernel.org/tip/c86c6bdd1099f398706b59b145148f3d39a587b7
Author:Thomas Gleixner
AuthorDate:Tue, 23 Mar 2021 22:30:28 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 143d13d824e4ae416433eb92eb428b6771f94f00
Gitweb:
https://git.kernel.org/tip/143d13d824e4ae416433eb92eb428b6771f94f00
Author:Thomas Gleixner
AuthorDate:Tue, 23 Mar 2021 22:30:29 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 5677c86221d14c18c6edea59d8f0f02e36e2b2db
Gitweb:
https://git.kernel.org/tip/5677c86221d14c18c6edea59d8f0f02e36e2b2db
Author:Thomas Gleixner
AuthorDate:Tue, 23 Mar 2021 22:30:32 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 31120afb21f5892aa981af635b425a074e978cab
Gitweb:
https://git.kernel.org/tip/31120afb21f5892aa981af635b425a074e978cab
Author:Thomas Gleixner
AuthorDate:Tue, 23 Mar 2021 22:30:26 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: fec6b6a56b6135163f45332570e4c2cc51484a64
Gitweb:
https://git.kernel.org/tip/fec6b6a56b6135163f45332570e4c2cc51484a64
Author:Thomas Gleixner
AuthorDate:Tue, 23 Mar 2021 22:30:24 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 18970ac4e37011fd0c709b6c2a640f01eecf2dd7
Gitweb:
https://git.kernel.org/tip/18970ac4e37011fd0c709b6c2a640f01eecf2dd7
Author:Thomas Gleixner
AuthorDate:Tue, 23 Mar 2021 22:30:27 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 3934afd2a81eb3a5cb52e64677adcc0983487c62
Gitweb:
https://git.kernel.org/tip/3934afd2a81eb3a5cb52e64677adcc0983487c62
Author:Thomas Gleixner
AuthorDate:Tue, 23 Mar 2021 22:30:30 +01:00
On Tue, Mar 23 2021 at 22:30, Thomas Gleixner wrote:
Ignore this one. I shot myself in the foot
On Tue, Mar 23 2021 at 22:30, Thomas Gleixner wrote:
> While working on the rtmutex related RT bits we noticed quite some
> inconsistencies and bitrot in the rtmutex code.
Sorry, forgot to mention that this is based on
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git lockin
The warning as written is expensive and not really required for a
production kernel. Make it depend on rt mutex debugging and use !in_task()
for the condition which generates far better code and gives the same
answer.
Signed-off-by: Thomas Gleixner
---
kernel/locking/rtmutex.c |7 +++
1
it
to the caller. The futex code uses a different function.
Signed-off-by: Thomas Gleixner
---
kernel/locking/rtmutex.c | 129 +--
1 file changed, 49 insertions(+), 80 deletions(-)
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1299,13
Preemption is disabled in mark_wakeup_next_waiter() not in
rt_mutex_slowunlock().
Signed-off-by: Thomas Gleixner
---
kernel/locking/rtmutex.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1305,7 +1305,7 @@ void
make sense and mark
the rest __sched.
Signed-off-by: Thomas Gleixner
---
kernel/locking/rtmutex.c | 152 +++
1 file changed, 76 insertions(+), 76 deletions(-)
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -49,7 +49,7 @@
* set
There is no value in having two header files providing just empty stubs and
a C file which implements trivial debug functions which can just be inlined.
Signed-off-by: Thomas Gleixner
---
kernel/locking/Makefile |2 -
kernel/locking/rtmutex-debug.c | 65
The conditional debug handling is just another layer of obfuscation. Split
the function so rt_mutex_init_proxy_locked() can invoke the inner init and
__rt_mutex_init() gets the full treatment.
Signed-off-by: Thomas Gleixner
---
kernel/locking/rtmutex.c| 11 ---
kernel/locking
None of these functions is used when CONFIG_RT_MUTEXES=n.
Remove the gunk. Remove pointless comments and clean up the coding style
mess while at it.
Signed-off-by: Thomas Gleixner
---
kernel/locking/rtmutex_common.h | 56 +++-
1 file changed, 11 insertions
There is no point for this wrapper at all.
Signed-off-by: Thomas Gleixner
---
kernel/locking/rtmutex.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -343,14 +343,9 @@ static void rt_mutex_adjust_prio(struct
Prepare for removing the header maze.
Signed-off-by: Thomas Gleixner
---
kernel/locking/rtmutex-debug.c |6 --
kernel/locking/rtmutex.c |8
2 files changed, 8 insertions(+), 6 deletions(-)
--- a/kernel/locking/rtmutex-debug.c
+++ b/kernel/locking/rtmutex-debug.c
No users just ballast.
Signed-off-by: Thomas Gleixner
---
include/linux/rtmutex.h| 14 ++
kernel/locking/rtmutex-debug.c |9 -
kernel/locking/rtmutex.c | 17 -
kernel/locking/rtmutex.h |2 --
4 files changed, 2 insertions
tter needs a seperate cleanup.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
include/linux/rtmutex.h |7 --
kernel/locking/rtmutex-debug.c | 97
kernel/locking/rtmutex-debug.h |9 ---
kernel/locking/rtmutex.c
-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
include/linux/rtmutex.h | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
--- a/include/linux/rtmutex.h
+++ b/include/linux/rtmutex.h
@@ -43,6 +43,7 @@ struct hrtimer_sleeper;
extern int
(), no further usage
Remove them along with unused inlines and macros leftovers related to
the long gone deadlock tester.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
include/linux/rtmutex.h |7 ++-
kernel/locking/rtmutex-debug.c |7 +--
kernel
From: Sebastian Andrzej Siewior
rt_mutex_timed_lock() has no callers since commit c051b21f71d1f ("rtmutex:
Confine deadlock logic to futex")
Remove it.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
include/linux/rtmutex.h |3 ---
kernel/locking
While working on the rtmutex related RT bits we noticed quite some
inconsistencies and bitrot in the rtmutex code.
Mop it up.
Thanks,
tglx
---
b/include/linux/rtmutex.h | 35 ---
b/kernel/locking/Makefile |2
b/kernel/locking/rtmutex.c| 379
g mechanism making it
unconditionally available is preferred over more conditional code or new
magic tunables.
Signed-off-by: Thomas Gleixner
---
V5: Self reaping was only mostly correct. Don't try to be smart and
make it simple _and_ correct (Oleg)
V4: Handle the self reaping case correctly (Oleg)
V3: U
On Tue, Mar 23 2021 at 19:04, Oleg Nesterov wrote:
> On 03/22, Thomas Gleixner wrote:
>> +static void sigqueue_cache_or_free(struct sigqueue *q, bool cache)
>> +if (q) {
>> +tsk->sigqueue_cache = NULL;
>> +/* If task is sel
The following commit has been merged into the locking/urgent branch of tip:
Commit-ID: 291da9d4a9eb3a1cb0610b7f4480f5b52b1825e7
Gitweb:
https://git.kernel.org/tip/291da9d4a9eb3a1cb0610b7f4480f5b52b1825e7
Author:Thomas Gleixner
AuthorDate:Mon, 22 Mar 2021 09:46:13 +01:00
The following commit has been merged into the locking/core branch of tip:
Commit-ID: ebdbd41bf2536ac57bf315ce9690245e08c5e506
Gitweb:
https://git.kernel.org/tip/ebdbd41bf2536ac57bf315ce9690245e08c5e506
Author:Thomas Gleixner
AuthorDate:Mon, 22 Mar 2021 09:46:13 +01:00
Manish,
On Mon, Mar 22 2021 at 10:15, Manish Varma wrote:
> On Thu, Mar 18, 2021 at 6:04 AM Thomas Gleixner wrote:
>> > +static atomic_t instance_count = ATOMIC_INIT(0);
>>
>> instance_count is misleading as it does not do any accounting of
>> instances as the name
From: Thomas Gleixner
The idea for this originates from the real time tree to make signal
delivery for realtime applications more efficient. In quite some of these
application scenarios a control tasks signals workers to start their
computations. There is usually only one signal per worker
There is no point in having the conditional at the callsite.
Just hand in the allocation mode flag to __sigqueue_alloc() and use it to
initialize sigqueue::flags.
No functional change.
Signed-off-by: Thomas Gleixner
---
kernel/signal.c | 17 +++--
1 file changed, 7 insertions
This is a follow up to the V2/V3 submission which can be found here:
https://lore.kernel.org/r/20210311132036.228542...@linutronix.de
Signal sending requires a kmem cache allocation at the sender side and the
receiver hands it back to the kmem cache when consuming the signal.
This works
efine")
Signed-off-by: Thomas Gleixner
Cc: sta...@vger.kernel.org
---
include/linux/mutex.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -185,7 +185,7 @@ extern void mutex_lock_io(struct mutex *
# define mutex_lock_interrupti
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: 81e2073c175b887398e5bca6c004efa89983f58d
Gitweb:
https://git.kernel.org/tip/81e2073c175b887398e5bca6c004efa89983f58d
Author:Thomas Gleixner
AuthorDate:Wed, 17 Mar 2021 15:38:52 +01:00
On Sun, Feb 21 2021 at 10:56, Chang S. Bae wrote:
> +
> +/* Update MSR IA32_XFD with xfirstuse_not_detected() if needed. */
> +static inline void xdisable_switch(struct fpu *prev, struct fpu *next)
> +{
> + if (!static_cpu_has(X86_FEATURE_XFD) || !xfirstuse_enabled())
> + return;
>
On Sun, Feb 21 2021 at 10:56, Chang S. Bae wrote:
>
> +static void check_xtile_data_against_struct(int size)
> +{
> + u32 max_palid, palid, state_size;
> + u32 eax, ebx, ecx, edx;
> + u16 max_tile;
> +
> + /*
> + * Check the maximum palette id:
> + * eax: the highest
On Sun, Feb 21 2021 at 10:56, Chang S. Bae wrote:
> In 64-bit mode, include the AMX state components in
> XFEATURE_MASK_USER_SUPPORTED.
>
> The XFD feature will be used to dynamically expand the xstate per-task
> buffer on the first use.
This patch touches absolutely nothing XFD related. What's
101 - 200 of 29423 matches
Mail list logo
