On Fri, Mar 19 2021 at 17:17, Thomas Gleixner wrote:
> On Wed, Mar 17 2021 at 11:12, Andy Lutomirski wrote:
>> +
>> +#define DEBUG_ENTRY_WARN_ONCE(condition, format...) do {} while (0)
>
> So we have a stub for !DEBUG
>
>> +static __always_inline void kentr
On Wed, Mar 17 2021 at 11:12, Andy Lutomirski wrote:
> -/**
> - * exit_to_user_mode - Fixup state when exiting to user mode
> - *
> - * Syscall/interrupt exit enables interrupts, but the kernel state is
> - * interrupts disabled when this is invoked. Also tell RCU about it.
> - *
> - * 1) Trace
On Wed, Mar 17 2021 at 11:12, Andy Lutomirski wrote:
> @@ -119,31 +119,12 @@ static inline __must_check int
> arch_syscall_enter_tracehook(struct pt_regs *regs
> void enter_from_user_mode(struct pt_regs *regs);
>
> /**
> + * kentry_syscall_begin - Prepare to invoke a syscall handler
> *
On Wed, Mar 17 2021 at 11:12, Andy Lutomirski wrote:
> +
> +#define DEBUG_ENTRY_WARN_ONCE(condition, format...) do {} while (0)
So we have a stub for !DEBUG
> +static __always_inline void kentry_cpu_depth_add(unsigned int n) {}
> +static void kentry_cpu_depth_check(unsigned int n) {}
> +static
On Wed, Mar 17 2021 at 11:12, Andy Lutomirski wrote:
> The new common syscall API had a large and confusing API surface. Simplify
> it. Now there is exactly one way to use it. It's a bit more verbose than
> the old way for the simple x86_64 native case, but it's much easier to use
> right,
and
On Wed, Mar 17 2021 at 11:12, Andy Lutomirski wrote:
> ret_from_fork is written in asm, slightly differently, for x86_32 and
> x86_64. Convert it to C.
> +__visible void noinstr ret_from_fork(struct task_struct *prev,
> + int (*kernel_thread_fn)(void *),
> +
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: a501b048a95b79e1e34f03cac3c87ff1e9f229ad
Gitweb:
https://git.kernel.org/tip/a501b048a95b79e1e34f03cac3c87ff1e9f229ad
Author:Thomas Gleixner
AuthorDate:Thu, 18 Mar 2021 20:26:47 +01:00
g used.
>
> Change the configuration check to be correct.
>
> [1] https://lore.kernel.org/lkml/20210304083825.GB17830@xsang-OptiPlex-9020/
>
> Cc: Thomas Gleixner
> Cc: Oliver Sang
> Cc: Chaitanya Kulkarni
> Cc: David Sterba
> Cc: Andrew Mor
and treat it as non existent despite a routing entry claiming
otherwise.
Fixes: d32932d02e18 ("x86/irq: Convert IOAPIC to use hierarchical irqdomain
interfaces")
Reported-by: Vitaly Kuznetsov
Signed-off-by: Thomas Gleixner
Tested-by: Vitaly Kuznetsov
Cc: sta...@vger.kernel.org
Link: htt
On Thu, Mar 18 2021 at 08:58, Vitaly Kuznetsov wrote:
> Thomas Gleixner writes:
>> There is a way more useful way to handle this. In such a case the bit is
>> NOT set in the alloc map. So:
>>
>> if (!WARN_ON_ONCE(test_and_clear_bit(bit, cm->alloc_map)))
>&
To prevent another incidental removal of the IRQ2 ignore logic in the
IO/APIC code going unnoticed add a sanity check. Add some commentry at the
other place which ignores IRQ2 while at it.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/apic/vector.c | 13 +
1 file changed, 13
Cure for the IRQ2 ignore logic which got lost during the irqdomain
conversion and a related sanity check.
Thanks,
tglx
On Thu, Mar 18, 2021 at 05:57:04AM +0100, Christoph Hellwig wrote:
> arch/mips/configs/malta_kvm_guest_defconfig | 3 ---
that file is gone in mips-next.
I could take all MIPS patches into mips-next, if you want...
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but i
Manish,
On Mon, Mar 01 2021 at 19:49, Manish Varma wrote:
> All together, that will give us names like the following:
>
> 1) timerfd file descriptor: [timerfd14:system_server]
> 2) eventpoll top-level per-process wakesource: epoll:system_server
> 3) eventpoll-on-timerfd per-descriptor
On Thu, Mar 18 2021 at 09:29, Vitaly Kuznetsov wrote:
> Thomas Gleixner writes:
>> Out of paranoia I'd rather ignore that IO/APIC pin completely if it
>> claims to be IRQ2. I assume there is no device connected to it at all,
>> right?
>
> The original issue was obse
t; This is similar with the commit d195b1d1d1196 ("powerpc/bpf: Enable
> > bpf_probe_read{, str}() on powerpc again").
> >
> > Fixes: 0ebeea8ca8a4 ("bpf: Restrict bpf_probe_read{, str}() only to archs
> > where they work")
> > Signed-off-by: Tiez
On Wed, Mar 17 2021 at 22:40, Thomas Gleixner wrote:
> af174783b925 ("x86: I/O APIC: Never configure IRQ2")
>
> has a very nice explanation why.
>
> Back then the logic was quite different. All legacy PIC interrupts
> (0-15) were bound to the legacy vectors
On Wed, Mar 17 2021 at 22:18, Thomas Gleixner wrote:
> On Wed, Mar 17 2021 at 21:14, Thomas Gleixner wrote:
>> On Fri, Feb 19 2021 at 12:31, Vitaly Kuznetsov wrote:
>> Even without looking at the machine I can tell you what's going on. MP
>> config or ACPI has a pin assigne
On Wed, Mar 17 2021 at 21:14, Thomas Gleixner wrote:
> On Fri, Feb 19 2021 at 12:31, Vitaly Kuznetsov wrote:
> Even without looking at the machine I can tell you what's going on. MP
> config or ACPI has a pin assigned to IRQ 2 which I've not seen before.
> The code there is ignoring I
On Fri, Feb 19 2021 at 12:31, Vitaly Kuznetsov wrote:
> When irq_matrix_assign()/irq_matrix_free() calls get unsynced, weird
> effects are possible, e.g. when cm->allocated goes negative CPU hotplug
> may get blocked. Add WARN_ON_ONCE() to simplify detecting such situations.
>
> Signed-off-by:
On Fri, Feb 19 2021 at 12:31, Vitaly Kuznetsov wrote:
> Trying to offline/online CPU0 seems to work only once:
>
> # echo 0 > /sys/devices/system/cpu/cpu0/online
> # echo 1 > /sys/devices/system/cpu/cpu0/online
> # echo 0 > /sys/devices/system/cpu/cpu0/online
> -bash: echo: write error: No
On Wed, Mar 17 2021 at 11:41, Mike Galbraith wrote:
> On Wed, 2021-03-17 at 10:46 +0100, Ingo Molnar wrote:
>> * Mike Galbraith wrote:
>>
>> > On Tue, 2021-03-16 at 19:20 +0800, Wang Qing wrote:
>> > > Why not just use wake_up_process().
>> >
>> > IMO this is not an improvement. There are other
On Wed, Mar 17 2021 at 12:38, tip-bot wrote:
> The following commit has been merged into the sched/core branch of tip:
>
> Commit-ID: 873d7c4c6a920d43ff82e44121e54053d4edba93
> Gitweb:
> https://git.kernel.org/tip/873d7c4c6a920d43ff82e44121e54053d4edba93
> Author:Nicholas
On Wed, Mar 17 2021 at 15:48, Sebastian Andrzej Siewior wrote:
> On 2021-03-17 15:38:52 [+0100], Thomas Gleixner wrote:
>> thread(irq_A)
>> irq_handler(A)
>> spin_lock(>lock);
>>
>> interrupt(irq_B)
>> irq_handler(B)
>> spin_l
The following commit has been merged into the irq/core branch of tip:
Commit-ID: d2da74d1278a1b51ef18beafa9da770f0db1c617
Gitweb:
https://git.kernel.org/tip/d2da74d1278a1b51ef18beafa9da770f0db1c617
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:42:04 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: b0cd02c2a9494dbf0a1cc7dc7a3b8b400c158d37
Gitweb:
https://git.kernel.org/tip/b0cd02c2a9494dbf0a1cc7dc7a3b8b400c158d37
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:42:07 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: ca5f625118955fc544c3cb3dee7055d33ecadafb
Gitweb:
https://git.kernel.org/tip/ca5f625118955fc544c3cb3dee7055d33ecadafb
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:42:06 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 6951547a1399c8f56468ed93bea8f769b891aec3
Gitweb:
https://git.kernel.org/tip/6951547a1399c8f56468ed93bea8f769b891aec3
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:42:05 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: eb2dafbba8b824ee77f166629babd470dd0b1c0a
Gitweb:
https://git.kernel.org/tip/eb2dafbba8b824ee77f166629babd470dd0b1c0a
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:42:10 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 6516b386d8a07102aac353daf9c0fe0045faeb74
Gitweb:
https://git.kernel.org/tip/6516b386d8a07102aac353daf9c0fe0045faeb74
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:55:54 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 728b478d2d358480b333b42d0e10e0fecb20114c
Gitweb:
https://git.kernel.org/tip/728b478d2d358480b333b42d0e10e0fecb20114c
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:55:53 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 6fd4e861250b5c89ad460a9f265caeb1bbbfc323
Gitweb:
https://git.kernel.org/tip/6fd4e861250b5c89ad460a9f265caeb1bbbfc323
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:42:17 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 8b1c04acad082dec76f3f8f7e1fa13493d6cbb79
Gitweb:
https://git.kernel.org/tip/8b1c04acad082dec76f3f8f7e1fa13493d6cbb79
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:55:56 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: f02fc963e91160e7343933823e8b73a0b2ab0a16
Gitweb:
https://git.kernel.org/tip/f02fc963e91160e7343933823e8b73a0b2ab0a16
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:55:55 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 47c218dcae6587fb5bce30f1656b13e22391c8e3
Gitweb:
https://git.kernel.org/tip/47c218dcae6587fb5bce30f1656b13e22391c8e3
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:55:57 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: ba9e6cab49c1465c2c322dcb03d771d5cbecb692
Gitweb:
https://git.kernel.org/tip/ba9e6cab49c1465c2c322dcb03d771d5cbecb692
Author:Thomas Gleixner
AuthorDate:Tue, 09 Mar 2021 09:55:58 +01:00
ernels there is no issue.
Fixes: 8d32a307e4fa ("genirq: Provide forced interrupt threading")
Reported-by: Johan Hovold
Signed-off-by: Thomas Gleixner
Cc: Eric Dumazet
Cc: Sebastian Andrzej Siewior
Cc: netdev
Cc: "David S. Miller"
Cc: Krzysztof Kozlowski
Cc: Greg Kroah-Hartma
On Wed, Mar 17 2021 at 15:00, Johan Hovold wrote:
> On Wed, Mar 17, 2021 at 02:24:04PM +0100, Thomas Gleixner wrote:
>> Something like the below.
>
> Looks good to me. Do you want to spin that into a patch or shall I do
> it after some testing?
I'll send one in a few
e yes. "Advisable" I think so. Thomas knows better than I what
> performance would be.
The performance impact is only relevant for 32bit machines with HIGHMEM
enabled. On 64bit kmap_local is a NOOP except when you enable
CONFIG_DEBUG_KMAP_LOCAL there which then actually doe
un the test to see if I am correct?
Why? The whole point of CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is to allow
testing of this kmap_local/atomic stuff w/o HIGHMEM, e.g. on 64 bit.
> Thomas wouldn't the following enable checks make more sense? Or perhaps be
> more consistent with the processing of kmap_ctrl?
Neither no
Johan,
On Tue, Mar 16 2021 at 11:56, Johan Hovold wrote:
> We've gotten reports of lockdep splats correctly identifying a potential
> deadlock in serial drivers when running with forced interrupt threading.
>
> Typically, a serial driver takes the port spin lock in its interrupt
> handler, but
The following changes since commit bd67b711bfaa02cf19e88aa2d9edae5c1c1d2739:
MIPS: kernel: Reserve exception base early to prevent corruption (2021-03-09
11:22:59 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/
ytes")
> Cc: Bjørn Mork
> Signed-off-by: Paul Cercueil
> ---
> arch/mips/kernel/vmlinux.lds.S | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied to mips-fixes.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
in function
> `tegra_usb_phy_init':
> phy-tegra-usb.c:(.text+0x1dd4): undefined reference to `clk_get_parent'
hmm, why not make it use common clock framework ? And shouldn't
include/linux/clk.h provide what you need, if CONFIG_HAVE_CLK is not set ?
Thomas.
--
Crap can work. Given
On Tue, Mar 16 2021 at 11:03, Davidlohr Bueso wrote:
> On Tue, 16 Mar 2021, Peter Zijlstra wrote:
>>IIRC we made the explicit choice to never loop here. That saves having
>>to worry about getting stuck in in-kernel loops.
>>
>>Userspace triggering the case where the futex goes corrupt is UB, after
On Tue, Mar 16 2021 at 19:10, Oleg Nesterov wrote:
> On 02/04, Oleg Nesterov wrote:
>>
>> It seems that nobody objects,
>>
>> Andrew, Andy, Thomas, how do you think this series should be routed?
>
> ping...
>
> What can I do to finally get this merged?
>
On Tue, Mar 16 2021 at 16:10, Eugeniu Rosca wrote:
> If no other comments in the next days, I will resubmit your proposal as
> v2, marked with 'Suggested-by: Thomas Gleixner '.
>
> Alternatively, feel free to author the patch and submit it with us in Cc.
Just send a v2 please
On Mon, Mar 15 2021 at 16:44, Eugeniu Rosca wrote:
> From: Dirk Behme
>
> In case this BUG() is hit, it helps debugging a lot to get an idea
> what tasklet is the root cause. So, be slightly more verbose here.
>
> Signed-off-by: Dirk Behme
> Signed-off-by: Eugeniu Rosca
> ---
>
On Sat, Mar 13 2021 at 17:49, Oleg Nesterov wrote:
> On 03/12, Thomas Gleixner wrote:
>>
>> On Fri, Mar 12 2021 at 20:26, Thomas Gleixner wrote:
>> > On Fri, Mar 12 2021 at 17:11, Oleg Nesterov wrote:
>> >> On 03/11, Thomas Gleixner wrote:
>> &
TEE request from a
client, then further command submission to queue will be disabled.
Fixes: 33960acccfbd (crypto: ccp - add TEE support for Raven Ridge)
Reviewed-by: Devaraj Rangasamy
Signed-off-by: Rijo Thomas
---
drivers/crypto/ccp/tee-dev.c | 49 +---
drivers
helps to resolve that.
v3:
* Fixed checkpatch.pl warning
v2:
* Updated copyright year as a part of code change
Rijo Thomas (2):
crypto: ccp - reduce tee command status polling interval from 5ms to
1ms
crypto: ccp - fix command queuing to TEE ring buffer
drivers/crypto/ccp/tee-dev.c | 57
The PSP TEE device driver polls the command status variable every
5ms to check for command completion. Reduce this time to 1ms so that
there is an improvement in driver response time to clients which submit
TEE commands.
Reviewed-by: Devaraj Rangasamy
Signed-off-by: Rijo Thomas
---
drivers
ndled by v4l2 instead.
Software rendering (i.e., anything wrt dumb buffers) likely reads back
framebuffer content during blit operations. For devices where this is a
slow operation (e.g., PCI read) we set struct
drm_mode_config.prefer_shadow to hint renderers to use shadow buffering.
Best re
Linus,
please pull the latest sched/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-2021-03-14
up to: ce29ddc47b91: sched/membarrier: fix missing local execution of
ipi_sync_rq_state()
A set of scheduler updates:
- Prevent a NULL pointer
Linus,
please pull the latest timers/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-2021-03-14
up to: 46eb1701c046: hrtimer: Update softirq_expires_next correctly after
__hrtimer_get_next_event()
A single fix in for hrtimers to prevent an
Linus,
please pull the latest irq/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
irq-urgent-2021-03-14
up to: b470ebc9e0e5: Merge tag 'irqchip-fixes-5.12-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent
A set of irqchip
Linus,
please pull the latest objtool/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
objtool-urgent-2021-03-14
up to: ba08abca66d4: objtool,x86: Fix uaccess PUSHF/POPF validation
A single objtool fix to handle the PUSHF/POPF validation correctly for the
Linus,
please pull the latest locking/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-urgent-2021-03-14
up to: 4817a52b3061: seqlock,lockdep: Fix seqcount_latch_init()
A couple of locking fixes:
- A fix for the static_call mechanism so it handles
f-by: Wang Qing
> ---
> arch/mips/kernel/spinlock_test.c | 8
> 1 file changed, 4 insertions(+), 4 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 ]
From: Thomas Gleixner
Subject: signal: Allow tasks to cache one sigqueue struct
Date: Wed, 03 Mar 2021 15:20:25 +0100
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
On Fri, Mar 12 2021 at 20:26, Thomas Gleixner wrote:
> On Fri, Mar 12 2021 at 17:11, Oleg Nesterov wrote:
>> On 03/11, Thomas Gleixner wrote:
>>>
>>> @@ -456,7 +460,12 @@ static void __sigqueue_free(struct sigqu
>>> return;
>>>
On Thu, Mar 11 2021 at 15:13, Eric W. Biederman wrote:
> Thomas Gleixner writes:
>
>> This is a follow up to the initial submission which can be found here:
>>
>> https://lore.kernel.org/r/20210303142025.wbbt2nnr6dtgw...@linutronix.de
>>
>> Signal send
On Fri, Mar 12 2021 at 17:11, Oleg Nesterov wrote:
> On 03/11, Thomas Gleixner wrote:
>>
>> @@ -456,7 +460,12 @@ static void __sigqueue_free(struct sigqu
>> return;
>> if (atomic_dec_and_test(>user->sigpending))
>> fre
On Fri, Mar 12 2021 at 17:18, Oleg Nesterov wrote:
> On 03/12, Sebastian Andrzej Siewior wrote:
>>
>> On 2021-03-11 14:20:39 [+0100], Thomas Gleixner wrote:
>> > --- a/kernel/signal.c
>> > +++ b/kernel/signal.c
>> > @@ -433,7 +433,11 @@ static
not. As the prerequisite of custom memory map has been removed, this results
> in the full memory range of 0x0 - 0x800 to be marked as reserved for this
> platform.
and where is the problem here ?
Thomas.
--
Crap can work. Given enough thrust
2 ---
> 1 file changed, 47 insertions(+), 45 deletions(-)
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 ]
isplay,kd035g6-54nt.yaml | 1 -
> 1 file changed, 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 ]
1 file changed, 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 ]
ou please point me to where this is
really documented ?
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
.../include/asm/mach-loongson64/boot_param.h | 18 --
> .../include/asm/mach-loongson64/loongson.h | 18 ++
> drivers/irqchip/irq-loongson-liointc.c | 2 +-
> 3 files changed, 19 insertions(+), 19 deletions(-)
applied to mips-next.
Thomas.
--
Crap
hanged, 1 insertion(+), 72 deletions(-)
> delete mode 100644 arch/mips/loongson64/platform.c
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 ]
620.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 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 ]
svmb.dts | 4 ++--
> arch/mips/boot/dts/brcm/bcm97420c.dts | 2 +-
> arch/mips/boot/dts/brcm/bcm97425svmb.dts | 4 ++--
> arch/mips/boot/dts/brcm/bcm97435svmb.dts | 4 ++--
> arch/mips/boot/dts/brcm/bcm9ejtagprb.dts
On Tue, Mar 09 2021 at 10:40, Xiangyang Yu wrote:
> In our performance tests, we find that the performance of
> sysbench is descend. Function call consumes too many instructions,
> change pi_state_update_owner() to an inline function.
Serioulsy? sysbench does not use PI futexes which means that
On Thu, Mar 11 2021 at 13:45, Thomas Gleixner wrote:
> On Thu, Mar 11 2021 at 00:56, Thomas Gleixner wrote:
>> Rant aside, there is no massive benefit of doing that caching in
>> general, but there is not much of a downside either and for particular
>> use cases it'
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
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
To prepare for caching a sigqueue per task, implement a dedicated function
to flush the sigqueue of the exiting task.
No functional change.
Signed-off-by: Thomas Gleixner
---
include/linux/signal.h |1 +
kernel/exit.c |3 +--
kernel/signal.c|9 +
3 files
This is a follow up to the initial submission which can be found here:
https://lore.kernel.org/r/20210303142025.wbbt2nnr6dtgw...@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
On Thu, Mar 11 2021 at 00:56, Thomas Gleixner wrote:
> Rant aside, there is no massive benefit of doing that caching in
> general, but there is not much of a downside either and for particular
> use cases it's useful even outside of PREEMPT_RT.
>
> IMO, having it there unconditio
5aedb24f8 ("z3fold: stricter locking and more careful reclaim")
Cc: sta...@vger.kernel.org
Signed-off-by: Thomas Hebb
---
mm/z3fold.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index 0152ad9931a8..8ae944eeb8e2 100644
Hi
Am 10.03.21 um 20:02 schrieb Paul Cercueil:
Hi Thomas,
Le lun. 8 mars 2021 à 9:41, Thomas Zimmermann a
écrit :
Hi Paul,
having individual functions for each mode only makes sense if the
decision is at compile time. But in patch 5, you're working around
your earlier design
On Wed, Mar 10 2021 at 15:57, Eric W. Biederman wrote:
> Thomas Gleixner writes:
>> IMO, not bothering with an extra counter and rlimit plus the required
>> atomic operations is just fine and having this for all tasks
>> unconditionally looks like a clear win.
>>
>
On Thu, Mar 04 2021 at 21:58, Thomas Gleixner wrote:
> On Thu, Mar 04 2021 at 13:04, Eric W. Biederman wrote:
>> Thomas Gleixner writes:
>>>
>>> We could of course do the caching unconditionally for all tasks.
>>
>> Is there any advantage to only doing thi
10 ++-
> arch/mips/kernel/syscalls/syscallhdr.sh | 36 -
> 2 files changed, 2 insertions(+), 44 deletions(-)
> delete mode 100644 arch/mips/kernel/syscalls/syscallhdr.sh
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but
On Mon, Mar 01, 2021 at 04:29:57PM +0100, Thomas Bogendoerfer wrote:
> After removal of the guest part of KVM TE (trap and emulate), also remove
> the host part.
>
> Signed-off-by: Thomas Bogendoerfer
> ---
> arch/mips/configs/loongson3_defconfig |1 -
> arch/mips/i
On Mon, Mar 01, 2021 at 04:29:56PM +0100, Thomas Bogendoerfer wrote:
> KVM_GUEST is broken and unmaintained, so let's remove it.
>
> Signed-off-by: Thomas Bogendoerfer
> ---
> arch/mips/Kconfig | 17 -
> arch/mips/configs/malta_kvm_gue
config.
>
> [1] https://github.com/iovisor/bpftrace/blob/master/INSTALL.md
>
> Signed-off-by: Tiezhu Yang
> ---
> arch/mips/configs/loongson3_defconfig | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
applied to mip
On Fri, Mar 05, 2021 at 07:35:35AM +0530, Bhaskar Chowdhury wrote:
>
>
> s/revelant/relevant/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> arch/mips/bcm63xx/clk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied to mips-next with fixed subject.
Th
---
> arch/mips/kernel/syscalls/syscalltbl.sh | 36 -
> 7 files changed, 17 insertions(+), 71 deletions(-)
> delete mode 100644 arch/mips/kernel/syscalls/syscalltbl.sh
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 ]
This adds the RockPro64’s infrared receiver to its dtsi. The configuration is
almost the same as on rk3328-rock64, except for the GPIO pins, and thus adapted
from there.
Signed-off-by: Thomas Schneider
---
arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi | 13 +
1 file changed
On Tue, Mar 09 2021 at 13:01, Thomas Gleixner wrote:
> On Fri, Mar 05 2021 at 11:57, Oleg Nesterov wrote:
>> On 03/04, Thomas Gleixner wrote:
>>> On Wed, Mar 03 2021 at 16:37, Oleg Nesterov wrote:
>>> >> +static bool sigqueue_add_cache(struct task_stru
On Tue, Mar 09 2021 at 16:21, Sebastian Andrzej Siewior wrote:
> On 2021-03-09 16:00:37 [+0100], To Thomas Gleixner wrote:
>> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
>> index 07c7329d21aa7..1c14ccd351091 100644
>> --- a/include/linux/interrupt.h
&
The PSP TEE device driver polls the command status variable every
5ms to check for command completion. Reduce this time to 1ms so that
there is an improvement in driver response time to clients which submit
TEE commands.
Reviewed-by: Devaraj Rangasamy
Signed-off-by: Rijo Thomas
---
drivers
helps to resolve that.
v2:
* Updated copyright year as a part of code change
Rijo Thomas (2):
crypto: ccp - reduce tee command status polling interval from 5ms to
1ms
crypto: ccp - fix command queuing to TEE ring buffer
drivers/crypto/ccp/tee-dev.c | 57
TEE request from a
client, then further command submission to queue will be disabled.
Fixes: 33960acccfbd (crypto: ccp - add TEE support for Raven Ridge)
Signed-off-by: Rijo Thomas
---
drivers/crypto/ccp/tee-dev.c | 49 +---
drivers/crypto/ccp/tee-dev.h | 20
On 09/03/21 10:06 pm, Tom Lendacky wrote:
> On 3/9/21 2:11 AM, Rijo Thomas wrote:
>> The first patch helps to improve the response time by reducing the
>> polling time of the tee command status variable.
>>
>> Second patch is a bug fix to handle multi-threaded use-ca
On 09/03/21 10:03 pm, Tom Lendacky wrote:
> On 3/9/21 2:11 AM, Rijo Thomas wrote:
>> Update the copyright year for PSP TEE driver files.
>>
>> Signed-off-by: Rijo Thomas
>
> The copyright updates really should occur as part of the changes in the
> other pat
Paul Cercueil (1):
MIPS: boot/compressed: Copy DTB to aligned address
Thomas Bogendoerfer (1):
MIPS: kernel: Reserve exception base early to prevent corruption
arch/mips/boot/compressed/decompress.c | 8
arch/mips/crypto/Makefile | 4 ++--
arch/mips/include/asm
nd',
> 'mtk,mt7621-mc', and 'mtk,mt7621-cpc'.
>
> Acked-by: Greg Kroah-Hartman
> Signed-off-by: Sergio Paracuellos
> ---
> arch/mips/ralink/mt7621.c | 6 +++---
Acked-by: Thomas Bogendoerfer
Thomas.
--
Crap can work. Given enough thrust pigs will fl
401 - 500 of 38838 matches
Mail list logo
