| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 6 Jun 2007 22:20:02 -0400 From: Jeff Dike <jdike@...toit.com> To: Paul Mackerras <paulus@...ba.org> Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>, Nicholas Miell <nmiell@...cast.net>, Davide Libenzi <davidel@...ilserver.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Linux Kernel list <linux-kernel@...r.kernel.org>, Andrew Morton <akpm@...ux-foundation.org> Subject: Re: signalfd API issues (was Re: [PATCH/RFC] signal races/bugs, losing TIF_SIGPENDING and other woes) On Thu, Jun 07, 2007 at 08:43:42AM +1000, Paul Mackerras wrote: > What Ben was talking about was stealing a synchronous SEGV from a task > without stopping it, and as Ben says that makes no sense. > Intercepting a signal and stopping the task is reasonable, and that is > what ptrace does, and I assume also UML. It is, but I can also see UML stealing the SEGV from the child. The UML skas does this - a ptrace extension, PTRACE_FAULTINFO, is used to extract page fault information from the child, and other pieces of the patch are used to fix the fault without the child continuing until it's fixed. So, in this case, the child never sees the SEGV. Jeff -- Work email - jdike at linux dot intel dot com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists