From owner-freebsd-current@freebsd.org Tue Jul 12 08:13:26 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9899B92290 for ; Tue, 12 Jul 2016 08:13:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 59E541A81; Tue, 12 Jul 2016 08:13:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u6C5vrA6094162 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 12 Jul 2016 08:57:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u6C5vrA6094162 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u6C5vrTd094161; Tue, 12 Jul 2016 08:57:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Jul 2016 08:57:53 +0300 From: Konstantin Belousov To: Mark Johnston Cc: freebsd-current@FreeBSD.org Subject: Re: ptrace attach in multi-threaded processes Message-ID: <20160712055753.GI38613@kib.kiev.ua> References: <20160712011938.GA51319@wkstn-mjohnston.west.isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160712011938.GA51319@wkstn-mjohnston.west.isilon.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 08:13:26 -0000 On Mon, Jul 11, 2016 at 06:19:38PM -0700, Mark Johnston wrote: > Hi, > > It seems to be possible for ptrace(PT_ATTACH) to race with the delivery > of a signal to the same process. ptrace(PT_ATTACH) sets P_TRACED and > sends SIGSTOP to a thread in the target process. Consider the case where > a signal is delivered to a second thread, and both threads are executing > ast() concurrently. The two threads will both call issignal() and from > there call ptracestop() because P_TRACED is set, though they will be > serialized by the proc lock. If the thread receiving SIGSTOP wins the > race, it will suspend first and set p->p_xthread. The second thread will > also suspend in ptracestop(), overwriting the p_xthread field set by the > first thread. Later, ptrace(PT_DETACH) will unsuspend the threads, but > it will set td->td_xsig only in the second thread. This means that the > first thread will return SIGSTOP from ptracestop() and subsequently > suspend the process, which seems rather incorrect. Why ? In particular, why delivering STOP after attach, in the described situation, is perceived as incorrect ? Parallel STOPs, one from attach, and other from kill(2), must result in two stops. The bit about overwriting p_xsig/p_xthread indeed initially sound worrysome, but probably not too much. The only consequence of reassigning p_xthread is the selection of the 'lead' thread in sys_process.c, it seems. > > The above is just a theory to explain an unexpectedly-stopped > multi-threaded process that I've observed. Is there some mechanism I'm > missing that prevents multiple threads from suspending in ptracestop() > at the same time? If not, then I think that's the root of the problem, > since p_xthread is pretty clearly not meant to be overwritten this way. Again, why ? Note the comment * Just make wait() to work, the last stopped thread * will win. which seems to point to the situation. > Moreover, in my scenario I see a thread with TDB_XSIG set even after > ptrace(PT_DETACH) was called (P_TRACED is cleared). This is interesting, we indeed do not clear the flag consistently. But again, the only consequence seems to be a possible invalid reporting of events.