From owner-svn-src-stable-11@freebsd.org Sat Apr 22 01:28:34 2017 Return-Path: Delivered-To: svn-src-stable-11@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 C1950D46A06; Sat, 22 Apr 2017 01:28:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (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 9F49DE0B; Sat, 22 Apr 2017 01:28:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 7151210A82D; Fri, 21 Apr 2017 21:28:32 -0400 (EDT) From: John Baldwin To: Eric Badger Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-11@freebsd.org Subject: Re: svn commit: r315949 - in stable: 10/sys/kern 10/sys/sys 10/tests/sys/kern 11/sys/kern 11/sys/sys 11/tests/sys/kern Date: Fri, 21 Apr 2017 15:11 -0700 Message-ID: <6768216.Fy5yUeFf9F@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <201703251333.v2PDXOmS004369@repo.freebsd.org> References: <201703251333.v2PDXOmS004369@repo.freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 21 Apr 2017 21:28:32 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: svn-src-stable-11@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for only the 11-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 01:28:34 -0000 On Saturday, March 25, 2017 01:33:24 PM Eric Badger wrote: > Author: badger > Date: Sat Mar 25 13:33:23 2017 > New Revision: 315949 > URL: https://svnweb.freebsd.org/changeset/base/315949 > > Log: > MFC r313992, r314075, r314118, r315484: > > r315484: > ptrace_test: eliminate assumption about thread scheduling > > A couple of the ptrace tests make assumptions about which thread in a > multithreaded process will run after a halt. This makes the tests less > portable across branches, and susceptible to future breakage. Instead, > twiddle thread scheduling and priorities to match the tests' > expectation. > > r314118: > Actually fix buildworlds other than i386/amd64/sparc64 after r313992 > > Disable offending test for platforms without a userspace visible > breakpoint(). > > r314075: > Fix world build for archs where __builtin_debugtrap() does not work. > > The offending code was introduced in r313992. > > r313992: > Defer ptracestop() signals that cannot be delivered immediately > > When a thread is stopped in ptracestop(), the ptrace(2) user may request > a signal be delivered upon resumption of the thread. Heretofore, those signals > were discarded unless ptracestop()'s caller was issignal(). Fix this by > modifying ptracestop() to queue up signals requested by the ptrace user that > will be delivered when possible. Take special care when the signal is SIGKILL > (usually generated from a PT_KILL request); no new stop events should be > triggered after a PT_KILL. > > Add a number of tests for the new functionality. Several tests were authored > by jhb. > > PR: 212607 > Sponsored by: Dell EMC So this MFC happens to break the KBI of 'struct thread' because 'struct sigqueue' is embedded in 'struct thread' (rather than a pointer). This apparently results in panics if you use an nvidia-driver package built on 11.0-release on 11.0-stable, and that's the type of KBI we try to preserve. (We tend to only add new fields to the end of 'struct thread' and 'struct proc' in stable for example.) This one is a bit ugly to deal with though. I wonder if for the stable branches only if we could move the sq_ptrace out of the sigqueue struct and add it as a new field to the end of 'struct thread' explicitly? It would probably be pretty hacky, but it would be good to fix this before 11.1 so that the KBI wouldn't be broken for a user going from 11.0 to 11.1. -- John Baldwin