From owner-freebsd-current@freebsd.org Tue Jul 12 18:20:46 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 C3F27B92020 for ; Tue, 12 Jul 2016 18:20:46 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F0381BD7 for ; Tue, 12 Jul 2016 18:20:46 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf0-x230.google.com with SMTP id t190so9376753pfb.3 for ; Tue, 12 Jul 2016 11:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=+cpVBxkwRI2Qx6LKn6y3yhPRR1Wuus4KIWwjKiFpLhQ=; b=CeABf4v9fcV0KKH7bvPIaA6gemwqrby2q8haNgZoQGovMYDk2HkBxFs2Yvb4uWfU7n d+ofTtc1Z0qcVhFB9azLBCn0eN9A5Uzi35krevt6rLvsRBD8MD8GGEmuMc6580oNYe7d DHsiK1bRJzgUR8pApM1D10GVeKhcCGj8rY/VQ6o3846wiCPft8lB8gDbEELRfVk6sE+O 3uqceLmlZ9+zr/bpq6bTpGQoN51hlMUHDldtAcoHeOhHslwi7vTvGIKnfX35kaFj14Dj Cqg3qBVUl7GNZ4xkLv2wvTQg/brRsbCu8PWZLnakQAEyA1J6qggSJeCiioAE+4900JZx hGzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=+cpVBxkwRI2Qx6LKn6y3yhPRR1Wuus4KIWwjKiFpLhQ=; b=PTY6G+pVRZncNof6pdufnPNoC/YW0mx+oXyhFFfKfUeEaUgDge1nFPDMbAYUIBylAx fT96ULRHZMoFreJ1SNqIfeCsyISHALbY18U5LLUR/gA4Fqjsl3ZBRa9e9UY7CueZCqfI evhc5CBSbKG0k6EdzkUA1D/NBKdk0dNln0ypxYj5phopcSMcHX6WoCebhj9Gd7rusyGe 86Cxc8R96hKlfNr1bonlIIl2fUqolYZiMG6zkSQc1vYtF+5gBe7w/7CqJdsHP/HMVrG+ lZHTFSUvi5fS3pTdk3RMjM6Ur0ek+rJmObYAkimgXR71PDx04DXbql2G8YWnpRNlJbmu e7KQ== X-Gm-Message-State: ALyK8tKN63ndKUnvgnnNaGzTVnboPHACIL5gzoB8xmdXyvVcj69oV3vEuNdB4X+yz2TMAQ== X-Received: by 10.98.157.12 with SMTP id i12mr30127456pfd.164.1468347646193; Tue, 12 Jul 2016 11:20:46 -0700 (PDT) Received: from wkstn-mjohnston.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net. [76.104.201.218]) by smtp.gmail.com with ESMTPSA id e187sm6813351pfg.43.2016.07.12.11.20.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jul 2016 11:20:45 -0700 (PDT) Sender: Mark Johnston Date: Tue, 12 Jul 2016 11:24:14 -0700 From: Mark Johnston To: Konstantin Belousov Cc: freebsd-current@FreeBSD.org Subject: Re: ptrace attach in multi-threaded processes Message-ID: <20160712182414.GC71220@wkstn-mjohnston.west.isilon.com> References: <20160712011938.GA51319@wkstn-mjohnston.west.isilon.com> <20160712055753.GI38613@kib.kiev.ua> <20160712170502.GA71220@wkstn-mjohnston.west.isilon.com> <20160712175150.GP38613@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160712175150.GP38613@kib.kiev.ua> User-Agent: Mutt/1.6.1 (2016-04-27) 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 18:20:46 -0000 On Tue, Jul 12, 2016 at 08:51:50PM +0300, Konstantin Belousov wrote: > On Tue, Jul 12, 2016 at 10:05:02AM -0700, Mark Johnston wrote: > > On Tue, Jul 12, 2016 at 08:57:53AM +0300, Konstantin Belousov wrote: > > I suppose it is not strictly incorrect. I find it surprising that a > > PT_ATTACH followed by a PT_DETACH may leave the process in a different > > state than it was in before the attach. This means that it is not > > possible to gcore a process without potentially leaving it stopped, for > > instance. This result may occur in a single-threaded process > > as well, since a signal may already be queued when the PT_ATTACH handler > > sends SIGSTOP. > I still miss somethine. Isn't this an expected outcome from sending a > signal with STOP action ? It is. But I also expect a PT_DETACH operation to resume a stopped process, assuming that a second SIGSTOP was not posted while the process was suspended. > > > Indeed, I somehow missed that. I had assumed that the leaked TDB_XSIG > > represented a bug in ptracestop(). > It could, I did not made any statements that deny the bug: To be clear, the root of my issue comes from the following: the SIGSTOP from PT_ATTACH may be handled concurrently with a second signal delivered to a second thread in the same process. Then, the resulting behaviour depends on the order in which the recipient threads suspend in ptracestop(). If the thread that received SIGSTOP suspends last, its td_xsig will be overwritten with the userland-provided value in the PT_DETACH handler. If it suspends first, its td_xsig will be preserved, and upon PT_DETACH the process will be suspended again in issignal(). I'm not sure if this is considered a bug. ptracestop() is handling all signals (including the SIGSTOP generated by the PT_ATTACH handler) in a consistent way, but this results in inconsistent behaviour from the perspective of a ptrace(2) consumer. > > > > > 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.