From owner-freebsd-current@freebsd.org Wed Jul 13 16:39:24 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 DB3EDB97203 for ; Wed, 13 Jul 2016 16:39:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 A3D881A16 for ; Wed, 13 Jul 2016 16:39:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pa0-x22b.google.com with SMTP id pp5so12600487pac.3 for ; Wed, 13 Jul 2016 09:39:24 -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=Di2dBtOi0PIo7TdkGTSO38FAuo/eOTYuR4rfz/bQa7U=; b=iSjS3eRRg4lCAznXRrVObcK3JFUEi+PKt5iWC3jmBar5x0aqzZST5QnXQLZyM/U2uF JSN2KccGUZwEDTXe70puIDx2ajl/Hx8As0vtkFvO7XiMjyMEkoTZF1ddXn64B4fJiEK7 df6AuT9L/iZSjlQgrpKge7sUTJEn6LxUiNHAIR7LIqAzZ8CN2Lb0IJIhCxpSksy8iysr XffyleifABw0y0H7YXUpaqihQR30BJJPe3iQHKdX+o79kLWuMueZzwrE9z9AcyRQBUhD IYAAwnqUQMpUP7AfriLukdHP4dq7NXmCbgEkCD47AWPYf6PNBaZSeo5FnF/lyCR4js3k xYcg== 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=Di2dBtOi0PIo7TdkGTSO38FAuo/eOTYuR4rfz/bQa7U=; b=j7LPeorlEZ8g/s7vwzcMUxdyKvlvGCPlt0Z8j0IJ0+FGo/KwxtrpeXT+/H/zaOIrzq FploGLBhAUYYmdoFffUiic0QUjX+DB97WmLHSxpf+2EbpOQDl6wSI9SUGF/WbzX61xjg OuS3pQkafX9FXkVwmAsiLEA6HJXgETkoVxXgmN6rChno52Jlqkm+4RyoSK5pHLoBpeCT 5QgAJO/boLYmL4wiLHfTw06lhntBo/PFUy5l9gwQ/cAJH0zMoheJBmow0gKswx3A/H7u rn8W7EEUIXLXmyRs7h8atimOyuYYBdGAPJsMq/OXlNqUpri85YZdvBdwUgaQewemvXzE 6F4Q== X-Gm-Message-State: ALyK8tJH0fY2WLCClV/+48X6pg4aw5GtjERhPzR9zsby/3cFSQi8Kz/fS7AE92kbc783hA== X-Received: by 10.66.161.195 with SMTP id xu3mr1087561pab.68.1468427964163; Wed, 13 Jul 2016 09:39:24 -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 9sm3007038pfo.74.2016.07.13.09.39.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jul 2016 09:39:23 -0700 (PDT) Sender: Mark Johnston Date: Wed, 13 Jul 2016 09:42:47 -0700 From: Mark Johnston To: Konstantin Belousov Cc: freebsd-current@FreeBSD.org Subject: Re: ptrace attach in multi-threaded processes Message-ID: <20160713164247.GA2066@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> <20160712182414.GC71220@wkstn-mjohnston.west.isilon.com> <20160713033036.GR38613@kib.kiev.ua> <20160713040210.GA89573@wkstn-mjohnston.west.isilon.com> <20160713045439.GT38613@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160713045439.GT38613@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: Wed, 13 Jul 2016 16:39:25 -0000 On Wed, Jul 13, 2016 at 07:54:39AM +0300, Konstantin Belousov wrote: > I finally see. Might be something like the patch below is a step in > the desired direction. Idea is in the proc_next_xthread(): p_xthread > should be set to the next thread with a pending signal. Do you have a > test case that demonstrates the issue ? Not yet, I'll work on one. I've only seen this occur once in an Isilon test cluster. The diff makes sense to me, thanks. I'd find the code easier to read if proc_next_xthread() was a pure function that returned the flagged thread instead of setting p_xthread. I'm having trouble determining if the diff changes any userland-visible behaviour. It seems that the only potential problem with the current p_xthread handling is in stopevent(), since a thread calling stopevent() from postsig() may clear p_xthread after it was set by another thread in ptracestop(). But I also don't understand why we call stopevent(S_SIG) from both issignal() and postsig() - this would appear to stop the thread twice for the same signal. With respect to the desired direction, do you agree that the SIGSTOP from PT_ATTACH should effectively be ignored if a different signal stops the process first? As I said in a previous post, it seems that the SA_STOP property of PT_ATTACH's SIGSTOP is not used in the common case, since ptracestop() will stop the process if any signal is received, and the PT_DETACH operation will typically overwrite the SIGSTOP with 0 in td_xsig.