k/mt7621.c | 29 +++---
> arch/mips/ralink/of.c | 2 ++
> 4 files changed, 32 insertions(+), 7 deletions(-)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
depending on DEBUG_KERNEL.
>
> Signed-off-by: Julian Braha
> ---
> arch/mips/Kconfig.debug | 1 +
> 1 file changed, 1 insertion(+)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
> arch/mips/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
estore the original branch and stop patching, run "git am --abort".
dim: ERROR: git apply-mbox failed
Best regards
Thomas
Am 19.03.21 um 10:23 schrieb KuoHsiang Chou:
[Bug][AST2500]
V1:
When AST2500 acts as stand-alone VGA so that DRAM and DVO initialization
have to be achieved by V
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 wo
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 de
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 showi
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() & 0x
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 anything
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 (e.g.
On Sat, Mar 27, 2021 at 09:35:43AM -0700, Ilya Lipnitskiy wrote:
> On Sat, Mar 27, 2021 at 2:46 AM Thomas Bogendoerfer
> wrote:
> >
> > On Thu, Mar 25, 2021 at 07:45:23PM -0700, Ilya Lipnitskiy wrote:
> > > On Thu, Mar 25, 2021 at 3:01 AM Thomas Bogendoerfer
> >
s_frozen)
+ cpusets_wait_for_hotplug();
return 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
On Thu, Mar 25, 2021 at 07:45:23PM -0700, Ilya Lipnitskiy wrote:
> On Thu, Mar 25, 2021 at 3:01 AM Thomas Bogendoerfer
> wrote:
> >
> > On Tue, Mar 16, 2021 at 10:59:02PM -0700, Ilya Lipnitskiy wrote:
> > > From: Chuanhong Guo
> > >
> > > mt7621 has t
On Fri, Mar 26, 2021 at 10:45:39AM -0700, Florian Fainelli wrote:
>
>
> On 3/25/2021 2:57 AM, Thomas Bogendoerfer wrote:
> > On Tue, Mar 23, 2021 at 03:20:43PM -0700, Florian Fainelli wrote:
> >> Provide hooks to intercept bad usages of virt_to_phys() and
> >> __
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 som
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
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 in
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
er 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
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
git://git.kernel.org/pub/scm/linux/k
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
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
>
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 adjti
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
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;
> - lon
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 upda
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 = ops->msi_alloc_sto
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 ts
f MIPS EVA (Enhanced Virtual
> Addressing)
> is set, I saw that ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE should be
> restricted
> to archs with non-overlapping address ranges.
>
> I wonder whether MIPS EVA will generate overlapping address ranges?
they can overlap in EVA mode.
&g
prom_soc_init lacks a __init
annotation or the annotation of mt7621_memory_detect is wrong.
Can you please fix this ?
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
te mode 100644 arch/mips/boot/dts/loongson/loongson64_2core_2k1000.dts
> create mode 100644 arch/mips/configs/loongson2k_defconfig
series applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
EXPORT_SYMBOL_GPL like two other stubs in the file.
> 2. Add Ack
> ---
> arch/mips/ralink/clk.c | 14 ++++++
> 1 file changed, 14 insertions(+)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
n Fainelli
> ---
> Changes in v2:
> - fixed sparse warning in arch/mips/kernel/vdso.c
checkpatch warns about a missing SPDX license in arch/mips/mm/physaddr.c,
can you please add one ?
And as checkpatch is also unhappy about the volatiles, do we really
need them here ?
Thomas.
--
Crap c
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
ristoph Hellwig
> ---
> arch/mips/configs/sb1250_swarm_defconfig | 3 ---
> 1 file changed, 3 deletions(-)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
; 1 file changed, 1 insertion(+), 1 deletion(-)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
On Fri, Mar 19, 2021 at 10:45:14AM +0530, Bhaskar Chowdhury wrote:
>
> s/packt/packet/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> arch/mips/pci/pci-xtalk-bridge.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied to mips-next.
Thomas.
--
Crap can work
> enabled.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/mips/configs/malta_kvm_defconfig | 3 ---
> arch/mips/configs/malta_kvm_guest_defconfig | 3 ---
> arch/mips/configs/maltaup_xpa_defconfig | 3 ---
> 3 files changed, 9 deletions(-)
applied to mips-next.
21832901251107.an...@mba.ocn.ne.jp/
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/mips/configs/rbtx49xx_defconfig | 3 ---
> 1 file changed, 3 deletions(-)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but
tions(+), 3 deletions(-)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
y enabled.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/mips/configs/bigsur_defconfig | 4
> 1 file changed, 4 deletions(-)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.
have no remote access to it either, but this is supposed not to need
> run-time verification. Build-tested only then.
>
> Please apply.
series applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
ions(-)
Marc, if you are ok with this change, I'd like to apply the series
to mips-next...
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
42.3: BPF prologue generation : Ok
#
Signed-off-by: Thomas Richter
---
tools/perf/tests/bpf.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/tools/perf/tests/bpf.c b/tools/perf/tests/bpf.c
index f57e075b0ed2..c72adbd67386 100644
--- a/tools/perf/tests/bpf.c
+++ b/
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 3/23/21 7:06 PM, Arnaldo Carvalho de Melo wrote:
> Em Mon, Mar 22, 2021 at 01:53:39PM +0100, Thomas Richter escreveu:
>> For some time now the perf test 42: BPF filter returns an error
>> on bpf relocation subtest, at least on x86 and s390. This is caused by
>>
>>
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
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
er 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
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 +-
no real downside of this caching 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 s
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
: Ok
42.3: BPF prologue generation : Ok
42.4: BPF relocation checker: Ok
#
Signed-off-by: Thomas Richter
---
tools/perf/tests/bpf-script-test-relocation.c | 4 ++--
tools/perf/tests/bpf.c| 11 +++
2 files changed, 13 insertions(+), 2 deletion
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 on
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 pretty
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;
>
301 - 400 of 10905 matches
Mail list logo