Re: svn commit: r332860 - head/sys/kern

2018-04-24 Thread Conrad Meyer
Next time you encounter something like this, please file a bug. There's no reason to have broken kernel dumps for a year. It took 10 minutes to diagnose. On Tue, Apr 24, 2018 at 10:38 AM, Andrew Gallatin wrote: > On 04/24/18 13:24, Jonathan T. Looney wrote: >> >> On Mon, Apr 23, 2018 at 6:04 PM,

Re: svn commit: r332860 - head/sys/kern

2018-04-24 Thread John Baldwin
On Tuesday, April 24, 2018 01:24:30 PM Jonathan T. Looney wrote: > On Mon, Apr 23, 2018 at 6:04 PM, John Baldwin wrote: > > > > I think this is actually a key question. In my experience to date I have > not > > encountered a large number of post-panic assertion failures. Given that > > we alread

Re: svn commit: r332860 - head/sys/kern

2018-04-24 Thread Mark Johnston
On Tue, Apr 24, 2018 at 01:24:30PM -0400, Jonathan T. Looney wrote: > On Mon, Apr 23, 2018 at 6:04 PM, John Baldwin wrote: > > > > I think this is actually a key question. In my experience to date I have > not > > encountered a large number of post-panic assertion failures. Given that > > we alr

Re: svn commit: r332860 - head/sys/kern

2018-04-24 Thread Andrew Gallatin
On 04/24/18 13:24, Jonathan T. Looney wrote: On Mon, Apr 23, 2018 at 6:04 PM, John Baldwin > wrote: > > I think this is actually a key question.  In my experience to date I have not > encountered a large number of post-panic assertion failures.  Given that > we alre

Re: svn commit: r332860 - head/sys/kern

2018-04-24 Thread Jonathan T. Looney
On Mon, Apr 23, 2018 at 6:04 PM, John Baldwin wrote: > > I think this is actually a key question. In my experience to date I have not > encountered a large number of post-panic assertion failures. Given that > we already break all locks and disable assertions for locks I'd be curious > which ass

Re: svn commit: r332860 - head/sys/kern

2018-04-23 Thread John Baldwin
On Monday, April 23, 2018 02:00:24 PM Mark Johnston wrote: > On Mon, Apr 23, 2018 at 11:12:32AM -0400, Jonathan T. Looney wrote: > > Hi Mark, > > > > Let me start by saying that I appreciate your well-reasoned response. (I > > think) I understand your reasoning, I appreciate your well-explained >

Re: svn commit: r332860 - head/sys/kern

2018-04-23 Thread Mark Johnston
On Mon, Apr 23, 2018 at 11:12:32AM -0400, Jonathan T. Looney wrote: > Hi Mark, > > Let me start by saying that I appreciate your well-reasoned response. (I > think) I understand your reasoning, I appreciate your well-explained > argument, and I respect your opinion. I just wanted to make that clea

Re: svn commit: r332860 - head/sys/kern

2018-04-23 Thread Warner Losh
On Mon, Apr 23, 2018 at 9:12 AM, Jonathan T. Looney wrote: > > If we leave the default alone, I agree we should print the assertion > message (albeit with some rate limit). > We should print the first N asserts we hit during a kernel panic core dump, then stop. I'd suggest N should be 10 or 20.

Re: svn commit: r332860 - head/sys/kern

2018-04-23 Thread Jonathan T. Looney
Hi Mark, Let me start by saying that I appreciate your well-reasoned response. (I think) I understand your reasoning, I appreciate your well-explained argument, and I respect your opinion. I just wanted to make that clear up front. On Sun, Apr 22, 2018 at 1:11 PM, Mark Johnston wrote: > > > All

Re: svn commit: r332860 - head/sys/kern

2018-04-22 Thread Mark Johnston
On Sat, Apr 21, 2018 at 04:33:33PM -0400, Jonathan Looney wrote: > On Sat, Apr 21, 2018 at 1:53 PM, Conrad Meyer wrote: > > > > I don't think this should be enabled by default. Can we leave it > > disabled by default and let consumers opt-in? > > I'm willing to change the default if there's a go

Re: svn commit: r332860 - head/sys/kern

2018-04-21 Thread Jonathan Looney
On Sat, Apr 21, 2018 at 1:53 PM, Conrad Meyer wrote: > > I don't think this should be enabled by default. Can we leave it > disabled by default and let consumers opt-in? I'm willing to change the default if there's a good reason or consensus for that. However, it is not obvious to me that the de

Re: svn commit: r332860 - head/sys/kern

2018-04-21 Thread Eitan Adler
On 21 April 2018 at 10:05, Jonathan T. Looney wrote: > Author: jtl > Date: Sat Apr 21 17:05:00 2018 > New Revision: 332860 > URL: https://svnweb.freebsd.org/changeset/base/332860 > > Log: > When running with INVARIANTS, the kernel contains extra checks. However, > these assumptions may not ho

Re: svn commit: r332860 - head/sys/kern

2018-04-21 Thread Conrad Meyer
On Sat, Apr 21, 2018 at 10:41 AM, Bruce Evans wrote: > panic() can't return, but I see that KASSERT() has already been broken > to use kassert_panic() which does return in some cases including this > new one. Oddly enough, I find myself agreeing with Bruce on this. That kassert_panic does not al

Re: svn commit: r332860 - head/sys/kern

2018-04-21 Thread Conrad Meyer
On Sat, Apr 21, 2018 at 10:05 AM, Jonathan T. Looney wrote: > Author: jtl > Date: Sat Apr 21 17:05:00 2018 > New Revision: 332860 > URL: https://svnweb.freebsd.org/changeset/base/332860 > > Log: > When running with INVARIANTS, the kernel contains extra checks. However, > these assumptions may

Re: svn commit: r332860 - head/sys/kern

2018-04-21 Thread Bruce Evans
On Sat, 21 Apr 2018, Jonathan T. Looney wrote: Log: When running with INVARIANTS, the kernel contains extra checks. However, these assumptions may not hold true once we've panic'd. Therefore, the checks hold less value after a panic. Additionally, if one of the checks fails while we are al

svn commit: r332860 - head/sys/kern

2018-04-21 Thread Jonathan T. Looney
Author: jtl Date: Sat Apr 21 17:05:00 2018 New Revision: 332860 URL: https://svnweb.freebsd.org/changeset/base/332860 Log: When running with INVARIANTS, the kernel contains extra checks. However, these assumptions may not hold true once we've panic'd. Therefore, the checks hold less value a