diff for duplicates of <87y3kwh1t5.fsf@xmission.com> diff --git a/a/1.txt b/N1/1.txt index 8f7815a..4d2630d 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -78,81 +78,3 @@ SIGFPE. > > I'd be more inclined to agree with you if VFP exceptions were synchronous > but they aren't. - -From your description there still seems to be an association with an -instruction so I don't know if I would really call the signal -asynchronous. It sounds like the exception is delayed and not -asynchronous. - ->> Was there some particular program being broken by the force_sig_info() ->> here? -> -> I don't recall. - -> commit da41119af78864d27ccbf505949df788d5e8aaf5 -> Author: Russell King <rmk@dyn-67.arm.linux.org.uk> -> Date: Wed Jun 29 23:02:02 2005 +0100 -> -> [PATCH] ARM: Don't force SIGFPE -> -> We were forcing SIGFPE on to a user program for no good reason. -> Use send_sig_info() instead. -> -> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> - -The commit looks like it was a case of the code not looking right -and you just switching to send_sig_info. - -force_sig_info really out to be called something like synchronous_sig. - -I am looking at sorting that out as part of cleaning up the signal -handling. There is currently a small bug where under the right -circumstances these synchronous signals might be improperly delivered -after a thread specific signal. To make that very unlikely there is a -special case in dequeue_signal for synchronous signals but it is -imperfect and slower than necessary. - -The function really ought to look something like: - -void synch_sig(struct siginfo *info) -{ - struct task_struct *tsk = current; - int sig = info->si_signo; - struct ksignal ksig; - struct k_sigaction *ka; - bool blocked, ignored; - unsigned long flags; - - WARN_ON(!siginmask(sig, SYNCHRONOUS_MASK)); - - copy_siginfo(info, &ksig.info); - spin_lock_irqsave(&tsk->sighand->siglock, flags); - ka = &tsk->sighand->action[sig - 1]; - ignored = ka->sa.sa_handler == SIG_IGN; - blocked = sigismember(&tsk->blocked, sig); - ksig.ka = *ka; - if (blocked || ignored) { - ksig.ka.sa.sa_handler = SIG_DFL; - } else if (ka->sa.sa_flags & SA_ONESHOT) { - ka->sa.sa_handler = SIG_DFL; - } - spin_unlock_irqrestore(&tsk->sighand->siglock, flags); - - if (ksig.ka.sa.sa_handler == SIG_DFL) { - do_coredump(&ksig->info); - do_group_exit(sig); - /* NOTREACHED */ - } - - handle_signal(&ksig, signal_pt_regs()); -} - -Which is both clearer and faster and less buggy than the current -implementation as it delivers the signal immediately with no chance -of the signal queue to reorder things. - -But it is going to take a little bit to get there as there are a number -of implementations of handle_signal like the ones on arm and arm64 that -perform needed register adjustments outside of handle_signal. - -Eric diff --git a/a/content_digest b/N1/content_digest index 676b1fc..3e30690 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -107,84 +107,6 @@ "> having been invoked, and it triggers the latent generation of the SIGFPE.\n" ">\n" "> I'd be more inclined to agree with you if VFP exceptions were synchronous\n" - "> but they aren't.\n" - "\n" - "From your description there still seems to be an association with an\n" - "instruction so I don't know if I would really call the signal\n" - "asynchronous. It sounds like the exception is delayed and not\n" - "asynchronous.\n" - "\n" - ">> Was there some particular program being broken by the force_sig_info()\n" - ">> here?\n" - ">\n" - "> I don't recall.\n" - "\n" - "> commit da41119af78864d27ccbf505949df788d5e8aaf5\n" - "> Author: Russell King <rmk@dyn-67.arm.linux.org.uk>\n" - "> Date: Wed Jun 29 23:02:02 2005 +0100\n" - "> \n" - "> [PATCH] ARM: Don't force SIGFPE\n" - "> \n" - "> We were forcing SIGFPE on to a user program for no good reason.\n" - "> Use send_sig_info() instead.\n" - "> \n" - "> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>\n" - "\n" - "The commit looks like it was a case of the code not looking right\n" - "and you just switching to send_sig_info.\n" - "\n" - "force_sig_info really out to be called something like synchronous_sig.\n" - "\n" - "I am looking at sorting that out as part of cleaning up the signal\n" - "handling. There is currently a small bug where under the right\n" - "circumstances these synchronous signals might be improperly delivered\n" - "after a thread specific signal. To make that very unlikely there is a\n" - "special case in dequeue_signal for synchronous signals but it is\n" - "imperfect and slower than necessary.\n" - "\n" - "The function really ought to look something like:\n" - "\n" - "void synch_sig(struct siginfo *info)\n" - "{\n" - "\tstruct task_struct *tsk = current;\n" - " int sig = info->si_signo;\n" - " struct ksignal ksig;\n" - "\tstruct k_sigaction *ka;\n" - " bool blocked, ignored;\n" - " unsigned long flags;\n" - "\n" - " WARN_ON(!siginmask(sig, SYNCHRONOUS_MASK));\n" - "\n" - "\tcopy_siginfo(info, &ksig.info);\n" - "\tspin_lock_irqsave(&tsk->sighand->siglock, flags);\n" - "\tka = &tsk->sighand->action[sig - 1];\n" - "\tignored = ka->sa.sa_handler == SIG_IGN;\n" - "\tblocked = sigismember(&tsk->blocked, sig);\n" - "\tksig.ka = *ka;\n" - "\tif (blocked || ignored) {\n" - "\t\tksig.ka.sa.sa_handler = SIG_DFL;\n" - "\t} else if (ka->sa.sa_flags & SA_ONESHOT) {\n" - "\t\tka->sa.sa_handler = SIG_DFL;\n" - "\t}\n" - "\tspin_unlock_irqrestore(&tsk->sighand->siglock, flags);\n" - "\n" - "\tif (ksig.ka.sa.sa_handler == SIG_DFL) {\n" - "\t\tdo_coredump(&ksig->info);\n" - "\t\tdo_group_exit(sig);\n" - "\t\t/* NOTREACHED */\n" - "\t}\n" - "\n" - "\thandle_signal(&ksig, signal_pt_regs());\n" - "}\n" - "\n" - "Which is both clearer and faster and less buggy than the current\n" - "implementation as it delivers the signal immediately with no chance\n" - "of the signal queue to reorder things.\n" - "\n" - "But it is going to take a little bit to get there as there are a number\n" - "of implementations of handle_signal like the ones on arm and arm64 that\n" - "perform needed register adjustments outside of handle_signal.\n" - "\n" - Eric + > but they aren't. -23473eae26793edf6b93e445af2d7e31a6381d3260b2c06ab92a5cfcca1f08e1 +2a7a2ff12828e87706919cd3b60e85631a93cac6ef19bf1228075e9912d94e59
diff --git a/a/1.txt b/N2/1.txt index 8f7815a..1efb909 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -79,7 +79,7 @@ SIGFPE. > I'd be more inclined to agree with you if VFP exceptions were synchronous > but they aren't. -From your description there still seems to be an association with an +>From your description there still seems to be an association with an instruction so I don't know if I would really call the signal asynchronous. It sounds like the exception is delayed and not asynchronous. diff --git a/a/content_digest b/N2/content_digest index 676b1fc..a2a24c7 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -8,24 +8,9 @@ "ref\020180117121505.GD22781@e103592.cambridge.arm.com\0" "ref\020180117123752.GN17719@n2100.armlinux.org.uk\0" "From\0ebiederm@xmission.com (Eric W. Biederman)\0" - "Subject\0Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS\0" + "Subject\0[PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS\0" "Date\0Wed, 17 Jan 2018 10:45:10 -0600\0" - "To\0Russell King - ARM Linux <linux@armlinux.org.uk>\0" - "Cc\0Dave Martin <Dave.Martin@arm.com>" - linux-arch@vger.kernel.org - Arnd Bergmann <arnd@arndb.de> - Nicolas Pitre <nico@linaro.org> - Tony Lindgren <tony@atomide.com> - Catalin Marinas <catalin.marinas@arm.com> - Tyler Baicar <tbaicar@codeaurora.org> - Will Deacon <will.deacon@arm.com> - linux-kernel@vger.kernel.org - Oleg Nesterov <oleg@redhat.com> - James Morse <james.morse@arm.com> - Al Viro <viro@zeniv.linux.org.uk> - Olof Johansson <olof@lixom.net> - Santosh Shilimkar <santosh.shilimkar@ti.com> - " linux-arm-kernel@lists.infradead.org\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "Russell King - ARM Linux <linux@armlinux.org.uk> writes:\n" @@ -109,7 +94,7 @@ "> I'd be more inclined to agree with you if VFP exceptions were synchronous\n" "> but they aren't.\n" "\n" - "From your description there still seems to be an association with an\n" + ">From your description there still seems to be an association with an\n" "instruction so I don't know if I would really call the signal\n" "asynchronous. It sounds like the exception is delayed and not\n" "asynchronous.\n" @@ -187,4 +172,4 @@ "\n" Eric -23473eae26793edf6b93e445af2d7e31a6381d3260b2c06ab92a5cfcca1f08e1 +1708bcdb4bb862439dd8b80aa9bc2c86c17e892cb3dbd92093d3cddbf6510654
diff --git a/a/1.txt b/N3/1.txt index 8f7815a..1efb909 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -79,7 +79,7 @@ SIGFPE. > I'd be more inclined to agree with you if VFP exceptions were synchronous > but they aren't. -From your description there still seems to be an association with an +>From your description there still seems to be an association with an instruction so I don't know if I would really call the signal asynchronous. It sounds like the exception is delayed and not asynchronous. diff --git a/a/content_digest b/N3/content_digest index 676b1fc..4e600ce 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -109,7 +109,7 @@ "> I'd be more inclined to agree with you if VFP exceptions were synchronous\n" "> but they aren't.\n" "\n" - "From your description there still seems to be an association with an\n" + ">From your description there still seems to be an association with an\n" "instruction so I don't know if I would really call the signal\n" "asynchronous. It sounds like the exception is delayed and not\n" "asynchronous.\n" @@ -187,4 +187,4 @@ "\n" Eric -23473eae26793edf6b93e445af2d7e31a6381d3260b2c06ab92a5cfcca1f08e1 +4893586f4cefeb6147f8b4fd8b717e37689327aef8ee2ff9dc53fb584d77dacc
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.