Date: Fri, 21 Apr 2017 15:11 -0700 From: John Baldwin <jhb@freebsd.org> To: Eric Badger <badger@freebsd.org> 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 Message-ID: <6768216.Fy5yUeFf9F@ralph.baldwin.cx> In-Reply-To: <201703251333.v2PDXOmS004369@repo.freebsd.org> References: <201703251333.v2PDXOmS004369@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6768216.Fy5yUeFf9F>