The x86 selftests frequently register and clean up signal handlers, but
the sethandler() and clearhandler() functions have been redundantly
copied across multiple .c files.
Move these functions to helpers.h to enable reuse across tests,
eliminating around 250 lines of duplicate code.
Converge
With the refactored test cases, another xstate exposure to userspace is
through signal delivery. While amx.c includes signal-related scenarios,
its primary focus is on xstate permission management, which is largely
specific to dynamic states.
The remaining gap is testing xstate preservation and
On Wed, 06 Nov 2024 17:07:51 +, Mark Brown wrote:
> We don't currently validate that we exit streaming mode and clear ZA when
> we enter a signal handler. Add simple checks for this in the SSVE and ZA
> tests.
>
>
Applied to arm64 (for-next/kselftest), thanks!
[1/1] ks
On Thu, 07 Nov 2024 01:39:19 +, Mark Brown wrote:
> Currently we test signal delivery to the programs run by fp-stress but
> our signal handlers simply count the number of signals seen and don't do
> anything with the floating point state. The original fpsimd-test and
> sve-
On Tue, Nov 12, 2024 at 11:30:14AM +, Catalin Marinas wrote:
> On Wed, Nov 06, 2024 at 05:07:51PM +, Mark Brown wrote:
> > + fprintf(stderr, "Unexpected SVCR %llx\n", get_svcr());
> > + return 1;
> > + }
> I think I'll change both printf specifiers to %lx here since
On Wed, Nov 06, 2024 at 05:07:51PM +, Mark Brown wrote:
> diff --git a/tools/testing/selftests/arm64/signal/testcases/ssve_regs.c
> b/tools/testing/selftests/arm64/signal/testcases/ssve_regs.c
> index
> 6dbe48cf8b09ed8b7a5ab47690bd87e39e18e1e6..3dee68fa36d1cf2716f54d5f328b
On Thu, 07 Nov 2024 01:39:19 +, Mark Brown wrote:
> Currently we test signal delivery to the programs run by fp-stress but
> our signal handlers simply count the number of signals seen and don't do
> anything with the floating point state. The original fpsimd-test and
> sve-
can improve the chances of triggering any issues
> with context switching the signal handling code. Do a quick change to
> increase the rate of signal delivery, trying to avoid excessive impact
> on emulated platforms, and a further change to mitigate the impact that
> thi
this we can improve the chances of triggering any issues
> with context switching the signal handling code. Do a quick change to
> increase the rate of signal delivery, trying to avoid excessive impact
> on emulated platforms, and a further change to mitigate the impact that
> thi
Currently in fp-stress we test signal delivery to the test threads by
sending SIGUSR2 which simply counts how many signals are delivered. The
test programs now also all have a SIGUSR1 handler which for the threads
doing userspace testing additionally modifies the floating point register
state in
Currently we test signal delivery to the programs run by fp-stress but
our signal handlers simply count the number of signals seen and don't do
anything with the floating point state. The original fpsimd-test and
sve-test programs had signal handlers called irritators which modify the
We don't currently validate that we exit streaming mode and clear ZA when
we enter a signal handler. Add simple checks for this in the SSVE and ZA
tests.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/signal/sve_helpers.h | 13 +
tools/testing/selftests/
On Wed, Oct 23, 2024 at 09:38:34PM +0100, Mark Brown wrote:
> Currently in fp-stress we test signal delivery to the test threads by
> sending SIGUSR2 which simply counts how many signals are delivered. The
> test programs now also all have a SIGUSR1 handler which for the threads
> doi
the signal handling code. Do a quick change to
increase the rate of signal delivery, trying to avoid excessive impact
on emulated platforms, and a further change to mitigate the impact that
this creates during startup.
Signed-off-by: Mark Brown
---
Changes in v2:
- Minor clarifications in commit
Currently we only deliver signals to the processes being tested about once
a second, meaning that the signal code paths are subject to relatively
little stress. Increase this frequency substantially to 25ms intervals,
along with some minor refactoring to make this more readily tuneable and
On Tue, Oct 29, 2024 at 03:43:37PM +, Mark Rutland wrote:
> On those emulated platforms (FVP?), does this change trigger the faukure
> more often?
Yes.
> I gave this a quick test, and with this change, running fp-stress on a
> defconfig kernel running on 1 CPU triggers the "Bad SVCR: 0" spla
Hi Mark,
On Tue, Oct 29, 2024 at 12:10:39AM +, Mark Brown wrote:
> Currently we only deliver signals to the processes being tested about
> once a second, meaning that the signal code paths are subject to
> relatively little stress. Increase this frequency substantially to
> 25
On 10/8/24 23:14, Dev Jain wrote:
This patch series is motivated by the following observation:
Raise a signal, jump to signal handler. The ucontext_t structure dumped
by kernel to userspace has a uc_sigmask field having the mask of blocked
signals. If you run a fresh minimalistic program doing
Pingplease pull this
Currently we only deliver signals to the processes being tested about once
a second, meaning that the signal code paths are subject to relatively
little stress. Increase this frequency substantially to 25ms intervals,
along with some minor refactoring to make this more readily tuneable and
the signal handling code. Do a quick change to
increase the rate of signal delivery, trying to avoid excessive impact
on emulated platforms, and a further change to mitigate the impact that
this creates during startup.
Signed-off-by: Mark Brown
---
Mark Brown (2):
kselftest/arm64: Increase
On Wed, Oct 23, 2024 at 09:38:28PM +0100, Mark Brown wrote:
> Currently we test signal delivery to the programs run by fp-stress but
> our signal handlers simply count the number of signals seen and don't do
> anything with the floating point state. The original fpsimd-test
fp-stress.c main loop to trigger
>a signal every ~1ms (by reducing the epoll_wait() timeout to 1 and
>scaling the overall timeout to 1 accordingly), and those changes
>make the tests reliably trigger the "Bad SVCR" splats within a few
>seconds after a few
Currently in fp-stress we test signal delivery to the test threads by
sending SIGUSR2 which simply counts how many signals are delivered. The
test programs now also all have a SIGUSR1 handler which for the threads
doing userspace testing additionally modifies the floating point register
state in
Currently we test signal delivery to the programs run by fp-stress but
our signal handlers simply count the number of signals seen and don't do
anything with the floating point state. The original fpsimd-test and
sve-test programs had signal handlers called irritators which modify the
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski :
On Mon, 14 Oct 2024 16:05:59 +0200 you wrote:
> MPTCP connection requests toward a listening socket created by the
> in-kernel PM for a port based signal endpoint will never be accepted,
> they need to be e
ted by Cong Wang, the splat is false positive, but the code
path leading to the report is an unexpected one: a client is
attempting an MPC handshake towards the in-kernel listener created
by the in-kernel PM for a port based signal endpoint.
Such connection will be never accepted; many of them can ma
MPTCP connection requests toward a listening socket created by the
in-kernel PM for a port based signal endpoint will never be accepted,
they need to be explicitly rejected.
- Patch 1: Explicitly reject such requests. A fix for >= v5.12.
- Patch 2: Cover this case in the MPTCP selftests to av
Rename sigaltstack to generic signal directory, to allow adding more
signal tests in the future.
Signed-off-by: Dev Jain
Reviewed-by: Mark Brown
Acked-by: Shuah Khan
---
tools/testing/selftests/Makefile| 2 +-
tools/testing/selftests/{sigaltstack => sig
This patch series is motivated by the following observation:
Raise a signal, jump to signal handler. The ucontext_t structure dumped
by kernel to userspace has a uc_sigmask field having the mask of blocked
signals. If you run a fresh minimalistic program doing this, this field
is empty, even if
On Mon, Oct 07, 2024 at 10:07:24AM +0530, Dev Jain wrote:
> On 9/16/24 09:28, Dev Jain wrote:
> > Gentle ping, adding all x86 maintainers and the x86 list, in case they
> > missed.
> Gentle ping
Given that this was posted prior to the merge window you should probably
resend it at this point.
s
10:29, Dev Jain wrote:
On 8/27/24 17:16, Dev Jain wrote:
On 8/27/24 17:14, Shuah Khan wrote:
On 8/22/24 06:14, Dev Jain wrote:
Rename sigaltstack to generic signal directory, to allow
adding more
signal tests in the future.
Sorry - I think I mentioned I don't like this test renamed.
17:16, Dev Jain wrote:
On 8/27/24 17:14, Shuah Khan wrote:
On 8/22/24 06:14, Dev Jain wrote:
Rename sigaltstack to generic signal directory, to allow
adding more
signal tests in the future.
Sorry - I think I mentioned I don't like this test renamed.
Why are you sending
this rename
17:14, Shuah Khan wrote:
On 8/22/24 06:14, Dev Jain wrote:
Rename sigaltstack to generic signal directory, to allow adding more
signal tests in the future.
Sorry - I think I mentioned I don't like this test renamed. Why are you sending
this rename still included in the patch series?
I a
/24 06:14, Dev Jain wrote:
Rename sigaltstack to generic signal directory, to allow
adding more
signal tests in the future.
Sorry - I think I mentioned I don't like this test renamed. Why
are you sending
this rename still included in the patch series?
I am not renaming the test, jus
sigaltstack to generic signal directory, to allow adding more
signal tests in the future.
Sorry - I think I mentioned I don't like this test renamed. Why are you sending
this rename still included in the patch series?
I am not renaming the test, just the directory. The directory name
is chang
ites, they create runtime overhead.
> to
> consider the new test as not testing signals, but a specific syscall
> "sigaction"
> and its interaction with blocking of signals, how about naming the new
> directory "sigaction"?
That's not going to scale amazingly i
On 9/4/24 22:35, Shuah Khan wrote:
On 9/3/24 22:52, Dev Jain wrote:
On 9/4/24 03:14, Shuah Khan wrote:
On 8/30/24 10:29, Dev Jain wrote:
On 8/27/24 17:16, Dev Jain wrote:
On 8/27/24 17:14, Shuah Khan wrote:
On 8/22/24 06:14, Dev Jain wrote:
Rename sigaltstack to generic signal
On 9/3/24 22:52, Dev Jain wrote:
On 9/4/24 03:14, Shuah Khan wrote:
On 8/30/24 10:29, Dev Jain wrote:
On 8/27/24 17:16, Dev Jain wrote:
On 8/27/24 17:14, Shuah Khan wrote:
On 8/22/24 06:14, Dev Jain wrote:
Rename sigaltstack to generic signal directory, to allow adding more
signal tests
On 9/4/24 03:14, Shuah Khan wrote:
On 8/30/24 10:29, Dev Jain wrote:
On 8/27/24 17:16, Dev Jain wrote:
On 8/27/24 17:14, Shuah Khan wrote:
On 8/22/24 06:14, Dev Jain wrote:
Rename sigaltstack to generic signal directory, to allow adding more
signal tests in the future.
Sorry - I think
On 8/30/24 10:29, Dev Jain wrote:
On 8/27/24 17:16, Dev Jain wrote:
On 8/27/24 17:14, Shuah Khan wrote:
On 8/22/24 06:14, Dev Jain wrote:
Rename sigaltstack to generic signal directory, to allow adding more
signal tests in the future.
Sorry - I think I mentioned I don't like this
This series has some fixups found when I was doing a deep dive
documentation of the OpenRISC FPU support which was added in 2023.
http://stffrdhrn.github.io/hardware/embedded/openrisc/2023/08/24/or1k-fpu-linux-and-compilers.html
The FPU handling has issues of being inefficient and also not pro
As long as a fatal signal is pending, alloc_contig_range() will fail with
-EINTR. This makes it impossible for tag storage allocation to succeed, and
the page allocator will print an OOM splat.
The process is going to be killed, so return 0 (success) from
reserve_tag_storage() to allow the page
er+0x3c/0x68
> do_debug_exception+0xac/0x180
> el0_dbg+0x34/0x58
> el0_sync_handler+0x50/0xb8
> el0_sync+0x180/0x1c0
>
> It has been fixed by
> 0c34700de5e7 ("arm64: signal: Use ARCH_RT_DELAYS_SIGNAL_SEND.") in
> higher versions of the kernel. This patch nee
force_sig_fault_to_task+0x54/0x78
force_sig_fault+0x1c/0x28
arm64_force_sig_fault+0x48/0x78
send_user_sigtrap+0x4c/0x80
brk_handler+0x3c/0x68
do_debug_exception+0xac/0x180
el0_dbg+0x34/0x58
el0_sync_handler+0x50/0xb8
el0_sync+0x180/0x1c0
It has been fixed by
0c34700de5e7 ("arm64: signal
equested) to the task where an event occurred.
> >
> > Acked-by: Geert Uytterhoeven # m68k
> > Acked-by: Arnd Bergmann # asm-generic
> > Signed-off-by: Marco Elver
>
> This patch landed in linux-next as commit fb6cc127e0b6 ("signal:
> Introduce TRAP_PERF
m68k
> Acked-by: Arnd Bergmann # asm-generic
> Signed-off-by: Marco Elver
This patch landed in linux-next as commit fb6cc127e0b6 ("signal:
Introduce TRAP_PERF si_code and si_perf to siginfo"). It causes
regression on my test systems (arm 32bit and 64bit). Most systems fails
tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Liam-Howlett/arm64-armv8_deprecated-Fix-swp_handler-signal-generation/20210421-005252
bas
On Tue, Apr 20 2021 at 11:08, kernel test robot wrote:
> FYI, we noticed a -3.3% regression of will-it-scale.per_thread_ops due to
> commit:
>
> commit: 4bad58ebc8bc4f20d89cff95417c9b4674769709 ("signal: Allow tasks to
> cache one sigqueue struct")
> https://git.kern
arm64_notify_segfault() was written to decide on the si_code from the
assembly emulation of the swp_handler(), but was also used for the
signal generation from failed access_ok() and unaligned instructions.
When access_ok() fails, there is no need to search for the offending
address in the VMA
correct si_code of SI_KERNEL by using arm64_notify_die(). In
the case of !access_ok(), simply return SIGSEGV with si_code
SEGV_ACCERR.
This change requires exporting arm64_notfiy_die() to the arm64 traps.h
Fixes: f71016a8a8c5 (arm64: signal: Call arm64_notify_segfault when
failing to deliver signal
The main thread could start to send SIG_IPI at any time, even before signal
blocked on vcpu thread. Reuse the sem_vcpu_stop to sync on that, so when
SIG_IPI is sent the signal will always land correctly as an -EINTR.
Without this patch, on very busy cores the dirty_log_test could fail directly
On 17/04/21 16:36, Peter Xu wrote:
The main thread could start to send SIG_IPI at any time, even before signal
blocked on vcpu thread. Reuse the sem_vcpu_stop to sync on that, so when
SIG_IPI is sent the signal will always land correctly as an -EINTR.
Without this patch, on very busy cores the
The main thread could start to send SIG_IPI at any time, even before signal
blocked on vcpu thread. Reuse the sem_vcpu_stop to sync on that, so when
SIG_IPI is sent the signal will always land correctly as an -EINTR.
Without this patch, on very busy cores the dirty_log_test could fail directly
: Peter Zijlstra
CommitterDate: Fri, 16 Apr 2021 16:32:41 +02:00
signal: Introduce TRAP_PERF si_code and si_perf to siginfo
Introduces the TRAP_PERF si_code, and associated siginfo_t field
si_perf. These will be used by the perf event subsystem to send signals
(if requested) to the task where
/* user requested, ignore socket errors
> >>> */ if (test_bit(NBD_RT_DISCONNECT_REQUESTED,
> >>> &config->runtime_flags)) ret =
> >>> 0; if (test_bit(NBD_RT_TIMEDOUT,
> >>> &config->runtime_flags)) ret =
> >>> -ETIME
Committer: Peter Zijlstra
CommitterDate: Wed, 14 Apr 2021 18:04:08 +02:00
signal: Hand SIGQUEUE_PREALLOC flag to __sigqueue_alloc()
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
Committer: Peter Zijlstra
CommitterDate: Wed, 14 Apr 2021 18:04:08 +02:00
signal: Allow tasks to cache one sigqueue struct
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
> >>> /* user requested, ignore socket errors
> >>> */ if (test_bit(NBD_RT_DISCONNECT_REQUESTED,
> >>> &config->runtime_flags)) ret =
> >>> 0; if (test_bit(NBD_RT_TIMEDOUT,
> >>> &config->runtime_flags)) ret =
> &g
recv_threads) of workqueue jobs and then waits for them to
finish. It waits interruptedly. Now, any signal would make
wait_event_interruptible() to return -ERESTARTSYS. Livepatch fake
signal is no exception there. The error is then propagated back to
the userspace. Unless a user requested a disconnecti
> >
> > /* user requested, ignore socket errors
> > */ if (test_bit(NBD_RT_DISCONNECT_REQUESTED,
> > &config->runtime_flags)) ret =
> > 0; if (test_bit(NBD_RT_TIMEDOUT,
> > &config->runtime_flags)) ret =
> &g
> >
> > /* user requested, ignore socket errors
> > */ if (test_bit(NBD_RT_DISCONNECT_REQUESTED,
> > &config->runtime_flags)) ret =
> > 0; if (test_bit(NBD_RT_TIMEDOUT,
> > &config->runtime_flags)) ret =
> &g
ppen.
So sigaltstack(2) says in the NOTES:
Functions called from a signal handler executing on an alternate
signal stack
will also use the alternate signal stack. (This also applies to any
handlers
invoked for other signals while the process is executing on the
* Borislav Petkov:
> On Mon, Apr 12, 2021 at 10:30:23PM +, Bae, Chang Seok wrote:
>> On Mar 26, 2021, at 03:30, Borislav Petkov wrote:
>> > On Thu, Mar 25, 2021 at 09:56:53PM -0700, Andy Lutomirski wrote:
>> >> We really ought to have a SIGSIGFAIL signal that&#x
ret = 0;
>
> if (test_bit(NBD_RT_TIMEDOUT, &config->runtime_flags))
>
> ret = -ETIMEDOUT;
>
> return ret;
On Mon, Apr 12, 2021 at 10:30:23PM +, Bae, Chang Seok wrote:
> On Mar 26, 2021, at 03:30, Borislav Petkov wrote:
> > On Thu, Mar 25, 2021 at 09:56:53PM -0700, Andy Lutomirski wrote:
> >> We really ought to have a SIGSIGFAIL signal that's sent, double-fault
> >&g
It will be used to implement process_vm_exec.
Signed-off-by: Andrei Vagin
---
arch/x86/kernel/signal.c | 78 ++--
1 file changed, 43 insertions(+), 35 deletions(-)
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index be0d7d4152ec..cc269a20dd
if (test_bit(NBD_RT_TIMEDOUT, &config->runtime_flags))
ret = -ETIMEDOUT;
return ret;
}
When the nbd waits for atomic_read(&config-&
Our driver while supporting HDR didn't send the proper colorimetry info
in the AVI infoframe.
Let's add the property needed so that the userspace can let us know what
the colorspace is supposed to be.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- New patch
---
drivers/gpu/drm/vc4/vc4_
On Mon, 12 Apr 2021, at 16:20, Steven Lee wrote:
> The 04/09/2021 12:14, Andrew Jeffery wrote:
> > Hi Steven,
> >
> > On Thu, 8 Apr 2021, at 11:22, Steven Lee wrote:
> > > AST2600-A2 EVB provides reference design to support toggling signal
> > > voltag
On Mar 26, 2021, at 03:30, Borislav Petkov wrote:
> On Thu, Mar 25, 2021 at 09:56:53PM -0700, Andy Lutomirski wrote:
>> We really ought to have a SIGSIGFAIL signal that's sent, double-fault
>> style, when we fail to send a signal.
>
> Yeap, we should be able to tell
The 04/09/2021 12:14, Andrew Jeffery wrote:
> Hi Steven,
>
> On Thu, 8 Apr 2021, at 11:22, Steven Lee wrote:
> > AST2600-A2 EVB provides reference design to support toggling signal
> > voltage between 3.3v and 1.8v by power-switch-gpio pin that defined in
> > th
Hi Steven,
On Thu, 8 Apr 2021, at 11:22, Steven Lee wrote:
> AST2600-A2 EVB provides reference design to support toggling signal
> voltage between 3.3v and 1.8v by power-switch-gpio pin that defined in
> the device tree.
Is this something you think we need support for beyond the EVB? I
Introduces the TRAP_PERF si_code, and associated siginfo_t field
si_perf. These will be used by the perf event subsystem to send signals
(if requested) to the task where an event occurred.
Acked-by: Geert Uytterhoeven # m68k
Acked-by: Arnd Bergmann # asm-generic
Signed-off-by: Marco Elver
---
AST2600-A2 EVB provides reference design to support toggling signal
voltage between 3.3v and 1.8v by power-switch-gpio pin that defined in
the device tree. It also supporting enabling/disabling SD bus power by
power-gpio.
In the reference design, GPIOV0 of AST2600-A2 EVB is connected to power
Hello,
This series implements support for toggling SD bus signal voltage by
GPIO pin.
This series has been tested on AST2600-A2 EVB with APLL and 200MHz HCLK
clock source with sdr104, sdr50, sdr25, sdr12 and high speed mode.
This series were also be tested on AST2600-A1 EVB and AST2500 EVB that
This set of patches corrects and improves VSync-related register setup
on the MDP5 block. Values written to the registers were way too high
leading to the MDSS block counting way too many ticks on the vclk before
emitting a vsync interrupt, resulting in significant update issues on
command- and vi
On Sat, Apr 03, 2021 at 04:10:16PM +0800, Ming Lei wrote:
> We still may shutdown blktrace if current is the last opener, otherwise
> new blktrace can't be started and memory should be leaked forever, and
> what do you think of the revised version?
I don't think this works. For one there might be
On Sat, Apr 03, 2021 at 04:10:16PM +0800, Ming Lei wrote:
> On Fri, Apr 02, 2021 at 07:27:30PM +0200, Christoph Hellwig wrote:
> > On Wed, Mar 31, 2021 at 08:16:50AM +0800, Ming Lei wrote:
> > > On Tue, Mar 30, 2021 at 06:53:30PM +0200, Christoph Hellwig wrote:
> > > > On Tue, Mar 23, 2021 at 04:14
On Fri, Apr 02, 2021 at 07:27:30PM +0200, Christoph Hellwig wrote:
> On Wed, Mar 31, 2021 at 08:16:50AM +0800, Ming Lei wrote:
> > On Tue, Mar 30, 2021 at 06:53:30PM +0200, Christoph Hellwig wrote:
> > > On Tue, Mar 23, 2021 at 04:14:39PM +0800, Ming Lei wrote:
> > > > blktrace may allocate lots of
On Wed, Mar 31, 2021 at 08:16:50AM +0800, Ming Lei wrote:
> On Tue, Mar 30, 2021 at 06:53:30PM +0200, Christoph Hellwig wrote:
> > On Tue, Mar 23, 2021 at 04:14:39PM +0800, Ming Lei wrote:
> > > blktrace may allocate lots of memory, if the process is terminated
> > > by user or OOM, we need to prov
On Tue, Mar 30, 2021 at 06:53:30PM +0200, Christoph Hellwig wrote:
> On Tue, Mar 23, 2021 at 04:14:39PM +0800, Ming Lei wrote:
> > blktrace may allocate lots of memory, if the process is terminated
> > by user or OOM, we need to provide one chance to remove the trace
> > buffer, otherwise memory le
On Tue, Mar 23, 2021 at 04:14:39PM +0800, Ming Lei wrote:
> blktrace may allocate lots of memory, if the process is terminated
> by user or OOM, we need to provide one chance to remove the trace
> buffer, otherwise memory leak may be caused.
>
> Fix the issue by shutdown blktrace in case of task e
On Mon, 29 Mar 2021, Miroslav Benes wrote:
> Livepatch sends a fake signal to all remaining blocking tasks of a
> running transition after a set period of time. It uses TIF_SIGPENDING
> flag for the purpose. Commit 12db8b690010 ("entry: Add support for
> TIF_NOTIFY_SIGNAL&
Committer: Ingo Molnar
CommitterDate: Mon, 29 Mar 2021 15:57:05 +02:00
locking/rtmutex: Clean up signal handling in __rt_mutex_slowlock()
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
On 3/29/21 9:28 AM, Miroslav Benes wrote:
Livepatch sends a fake signal to all remaining blocking tasks of a
running transition after a set period of time. It uses TIF_SIGPENDING
flag for the purpose. Commit 12db8b690010 ("entry: Add support for
TIF_NOTIFY_SIGNAL") added a generic infr
Livepatch sends a fake signal to all remaining blocking tasks of a
running transition after a set period of time. It uses TIF_SIGPENDING
flag for the purpose. Commit 12db8b690010 ("entry: Add support for
TIF_NOTIFY_SIGNAL") added a generic infrastructure to achieve the same.
Replace o
On Fri 2021-03-26 15:30:21, Miroslav Benes wrote:
> Livepatch sends a fake signal to all remaining blocking tasks of a
> running transition after a set period of time. It uses TIF_SIGPENDING
> flag for the purpose. Commit 12db8b690010 ("entry: Add support for
> TIF_NOTIFY_SIGNAL&
On 3/26/21 8:30 AM, Miroslav Benes wrote:
> Livepatch sends a fake signal to all remaining blocking tasks of a
> running transition after a set period of time. It uses TIF_SIGPENDING
> flag for the purpose. Commit 12db8b690010 ("entry: Add support for
> TIF_NOTIFY_SIGNAL&
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
This reverts commit 5be28c8f85ce99ed2d329d2ad8bdd18ea19473a5.
IO threads now take signals just fine, so there's no reason to limit them
specifically. Revert the change that prevented that from happening.
Signed-off-by: Jens Axboe
---
kernel/signal.c | 3 ---
1 file changed, 3 deletions(-)
diff
This reverts commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597.
The IO threads allow and handle SIGSTOP now, so don't special case them
anymore in task_set_jobctl_pending().
Signed-off-by: Jens Axboe
---
kernel/signal.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/
This reverts commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597.
The IO threads allow and handle SIGSTOP now, so don't special case them
anymore in task_set_jobctl_pending().
Signed-off-by: Jens Axboe
---
kernel/signal.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/
This reverts commit 5be28c8f85ce99ed2d329d2ad8bdd18ea19473a5.
IO threads now take signals just fine, so there's no reason to limit them
specifically. Revert the change that prevented that from happening.
Signed-off-by: Jens Axboe
---
kernel/signal.c | 3 ---
1 file changed, 3 deletions(-)
diff
Livepatch sends a fake signal to all remaining blocking tasks of a
running transition after a set period of time. It uses TIF_SIGPENDING
flag for the purpose. Commit 12db8b690010 ("entry: Add support for
TIF_NOTIFY_SIGNAL") added a generic infrastructure to achieve the same.
Replace o
ts gettin' annoying.
> We really ought to have a SIGSIGFAIL signal that's sent, double-fault
> style, when we fail to send a signal.
Yeap, we should be able to tell userspace that we couldn't send a
signal, hohumm.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
I forgot to mention why I cc'd all you fine Xen folk:
On Thu, Mar 25, 2021 at 11:13 AM Andy Lutomirski wrote:
>
> > } else if (IS_ENABLED(CONFIG_X86_32) &&
> >!onsigstack &&
> >regs->ss != __USER_DS &&
This bit here seems really dubious on Xen PV.
0;
> > - int onsigstack = on_sig_stack(sp);
> > + bool already_onsigstack = on_sig_stack(sp);
> > + bool entering_altstack = false;
> > int ret;
> >
> > /* redzone */
> > @@ -246,15 +247,25 @@ get_sigframe(struct k_sigaction *ka, struct pt_
This reverts commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597.
The IO threads allow and handle SIGSTOP now, so don't special case them
anymore in task_set_jobctl_pending().
Signed-off-by: Jens Axboe
---
kernel/signal.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/
This reverts commit 5be28c8f85ce99ed2d329d2ad8bdd18ea19473a5.
IO threads now take signals just fine, so there's no reason to limit them
specifically. Revert the change that prevented that from happening.
Signed-off-by: Jens Axboe
---
kernel/signal.c | 3 ---
1 file changed, 3 deletions(-)
diff
1 - 100 of 3365 matches
Mail list logo
