From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754302AbbCXS4J (ORCPT ); Tue, 24 Mar 2015 14:56:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32847 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752227AbbCXS4G (ORCPT ); Tue, 24 Mar 2015 14:56:06 -0400 Date: Tue, 24 Mar 2015 19:54:00 +0100 From: Oleg Nesterov To: Andrew Morton , Pavel Labath Cc: Josh Stone , Pedro Alves , Vince Harron , linux-kernel@vger.kernel.org Subject: [PATCH 0/2] ptrace: fix race between ptrace_resume() and wait_task_stopped() Message-ID: <20150324185400.GA11826@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/24, Pavel Labath wrote: > > I have tested your patch and I can confirm that the error is gone when > running a patched kernel. Great! Thanks a lot for the detailed/clear report and testing. So I am sending this fix + another patch. 2/2 is "while at it" change, just because ptrace_detach() can resume the tracee with the new code too, so it makes sense to add a comment and remove the outdated logic. > I am still seeing one very rare failure where the SIGUSR does not > appear to be reported. However, I will need to dig around this a bit > more to make sure there is no error on our end. Hmm, perhaps we have (yet) another bug... please let me know if/when you have more details. > Now I am thinking about how to work around these bugs, as our code > will need to run on unpatched kernels as well. As for this > ptrace/waitpid race, I think I will just refactor the code to make > wait and ptrace calls on the same thread. This should sidestep the > race, right? Yes sure, this will hide the problem. > Regarding your bug, I am not exactly sure what are the implications. > Could you briefly describe the situations in which this behavior can > occur? Am I correct in understanding that this is always a race > between a SIGKILL and another non-lethal signal? And that the SIGKILL > will be (eventually) reported? No, SIGKILL can be never reported. But note that ptrace_stop() does set_current_state(TASK_TRACED); current->last_siginfo = info; current->exit_code = exit_code; and this is another case when wait_task_stopped() can consume/report this exit_code even if the tracee won't actually stop because it is killed. Usually this is not that bad, we can pretend that it was killed after stop. Still this can confuse the debugger which sends SIGKILL to the stopped tracee. We need more fatal_signal_pending() checks in ptrace_stop(). And in fact in get_signal(), I think. The problem is that we need other cleanups here. But fortunately this problem is minor. Oleg.