Subject: Re: [PATCH] ARM64: Clear out any singlestep state on a ptrace detach
operation
From: Will Deacon
Date: 12/04/2015 04:03 AM
To: "Blackwood, John"
CC: "linux-kernel@vger.kernel.org" , "o...@redhat.com"
, "fweis...@gmail.com"
On Thu, Dec 03,
previously ptraced task will die off with a SIGTRAP signal
if the debugger just previously singlestepped the ptraced task.
Signed-off-by: John Blackwood
Index: b/arch/arm64/kernel/ptrace.c
===
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch
numa: numa_balancing sysctl scope change
Make the 'numa_balancing' sysctl parameter no longer dependent upon
CONFIG_SCHED_DEBUG so it can be used in non-debug kernels.
Signed-off-by: John Blackwood
Index: b/kerne
his issue:
--- ---
Fix a race in the PRT wait for completion simple wait code.
A wait_for_completion() waiter task can be awoken by a task calling
complete(), but fail to consume the 'done' completion resource if it
looses a race with another task calling
attempt
to use the non-zeroed area as actual command entries.
Signed-off-by: John Blackwood
Index: b/kernel/debug/kdb/kdb_main.c
===
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -3341,7 +334
Roland Dreier wrote:
Thanks for the explanation...
> But basically, with CONFIG_PREEMPT_RT enabled, the lock points, such as
> aqcuiring a spinlock, potentially become places where the current task
> may be context switched out / preempted.
>
> Therefore, when a call is made to lock a spin
> Subject: Re: [ofa-general] [PATCH] [WORKAROUND] CONFIG_PREEMPT_RT and
ib_umad_close() issue
> From: Roland Dreier <[EMAIL PROTECTED]>
> Date: Mon, 17 Sep 2007 08:56:01 -0700
> To: John Blackwood <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.or
When using OFED-1.2.5 based infiniband kernel modules on 2.6.22 based
kernels with the Ingo Molnar CONFIG_PREEMPT_RT applied, then commands
such as ibnetdiscvoer, smpquery, sminfo, etc. will hang. The problem is
with the downgrade_write() rw semaphore usage in the ib_umad_close()
routine.
Th
Hi Neil,
We've been having problems with this select patch change.
Specifically -- previously, when a ptrace attach was done to a task
blocked in a select() call and that task had a timeout value,
the task would restart the select() call with an updated timeout value.
With this patch in place,
Hi Jeremy,
I was doing some tests that attempt to read the VDSO area of a
task through either the /proc/pid/mem or ptrace(PTRACE_PEEKTEXT,
...) interfaces, and it seems that when the CONFIG_COMPAT_VDSO kernel
parameter is enabled, we can no longer successfully read the VDSO area
on i386 kernels.
> Subject: Re: [RFC] [PATCH] selective signal ptracing
> From: Oleg Nesterov <[EMAIL PROTECTED]>
> Date: Sat, 16 Jun 2007 13:24:15 +0400
> To: John Blackwood <[EMAIL PROTECTED]>
> CC: Alan Cox <[EMAIL PROTECTED]>, Roland McGrath
<[EMAIL PROTECTED]>,
Selective Ptraced Signal Support - A proposed enhancement
This is a proposal for a ptrace enhancement that adds two new ptrace(2)
commands that let a debugger view and modify the set of signals that
are being ptraced.
By default all signals are ptraced as before. However, a debugger
may now modi
Hello Andrea,
I believe that we are seeing a problem with one change from the patch
2005/01/03 20:15:21-08:00 [EMAIL PROTECTED]
[PATCH] mempolicy optimisation
in the mpol_free_shared_policy() routine in mm/mempolicy.c, where a
rb_erase() line was removed.
The corresponding portion of the o
13 matches
Mail list logo
