On Tuesday, December 18, 2012 5:31:47 pm Alfred Perlstein wrote:
On 12/18/12 12:37 PM, John Baldwin wrote:
On Monday, December 17, 2012 4:21:43 pm Alfred Perlstein wrote:
On 12/17/12 11:39 AM, John Baldwin wrote:
On Saturday, December 15, 2012 1:04:17 am Bruce Evans wrote:
On Fri, 14 Dec
On 17.12.2012 23:12, Andriy Gapon wrote:
on 18/12/2012 00:02 Adrian Chadd said the following:
Why are they there, if we just ship production releases with
INVARIANTS disabled?
Because there is an axis orthogonal to asserting correctness - performance.
Indeed. There are, or will be, a
On Sunday, December 16, 2012 10:05:48 pm Adrian Chadd wrote:
On 16 December 2012 15:32, Navdeep Parhar npar...@gmail.com wrote:
The status quo _does not change_ by default.
So now we have a knob that could be used to change the behaviour of all
the KASSERTs in the system; one that
On Monday, December 17, 2012 4:21:43 pm Alfred Perlstein wrote:
On 12/17/12 11:39 AM, John Baldwin wrote:
On Saturday, December 15, 2012 1:04:17 am Bruce Evans wrote:
On Fri, 14 Dec 2012, Alfred Perlstein wrote:
On 12/14/12 4:12 PM, Robert Watson wrote:
On Fri, 14 Dec 2012, John Baldwin
On 12/18/12 12:37 PM, John Baldwin wrote:
On Monday, December 17, 2012 4:21:43 pm Alfred Perlstein wrote:
On 12/17/12 11:39 AM, John Baldwin wrote:
On Saturday, December 15, 2012 1:04:17 am Bruce Evans wrote:
On Fri, 14 Dec 2012, Alfred Perlstein wrote:
On 12/14/12 4:12 PM, Robert Watson
on 19/12/2012 00:31 Alfred Perlstein said the following:
Yes, that happens when they run -stable.
Does it?
Do you have a solution? [*]
[*] - which doesn't involve it runs so slow I am switching to Y.
--
Andriy Gapon
___
svn-src-all@freebsd.org
On 12/18/12 2:41 PM, Andriy Gapon wrote:
on 19/12/2012 00:31 Alfred Perlstein said the following:
Yes, that happens when they run -stable.
Does it?
Do you have a solution? [*]
[*] - which doesn't involve it runs so slow I am switching to Y.
I already suggested that we copy from KTR so that
On Friday, December 14, 2012 3:24:44 pm Alfred Perlstein wrote:
On 12/14/12 8:49 AM, John Baldwin wrote:
On Thursday, December 13, 2012 4:02:15 am Gleb Smirnoff wrote:
On Wed, Dec 12, 2012 at 04:53:48PM -0800, Alfred Perlstein wrote:
A The problem again is that not all the KASSERTS are
On Saturday, December 15, 2012 1:04:17 am Bruce Evans wrote:
On Fri, 14 Dec 2012, Alfred Perlstein wrote:
On 12/14/12 4:12 PM, Robert Watson wrote:
On Fri, 14 Dec 2012, John Baldwin wrote:
On Thursday, December 13, 2012 4:02:15 am Gleb Smirnoff wrote:
On Wed, Dec 12, 2012 at
On 12/17/12 11:39 AM, John Baldwin wrote:
On Saturday, December 15, 2012 1:04:17 am Bruce Evans wrote:
On Fri, 14 Dec 2012, Alfred Perlstein wrote:
On 12/14/12 4:12 PM, Robert Watson wrote:
On Fri, 14 Dec 2012, John Baldwin wrote:
On Thursday, December 13, 2012 4:02:15 am Gleb Smirnoff
on 17/12/2012 23:21 Alfred Perlstein said the following:
This is hard to explain to a customer.
customer: So we ran your debug image and got you a panic, here is the
information. So can you tell us what is the problem?
alfred: well that is due to XXX other thing that is broken, thanks for
on 18/12/2012 00:02 Adrian Chadd said the following:
Why are they there, if we just ship production releases with
INVARIANTS disabled?
Because there is an axis orthogonal to asserting correctness - performance.
--
Andriy Gapon
___
On 17 December 2012 13:47, Andriy Gapon a...@freebsd.org wrote:
But you see, the following is still illogical _to me_.
And this is the core of the problem.
A lot of developers are interpreting the KASSERT() conditions as an
invariant condition that, if in any way enabled, should be completely
On 12/17/12 14:02, Adrian Chadd wrote:
On 17 December 2012 13:47, Andriy Gapon a...@freebsd.org wrote:
But you see, the following is still illogical _to me_.
And this is the core of the problem.
A lot of developers are interpreting the KASSERT() conditions as an
invariant condition
On 12/15/12 11:45 PM, Andriy Gapon wrote:
on 16/12/2012 07:00 Ian Lepore said the following:
The question here isn't whether aborting or continuing beyond that point
is a good idea. Some developer already made that choice by coding a
KASSERT() instead of a panic(). The developer decided that
on 16/12/2012 10:06 Alfred Perlstein said the following:
On 12/15/12 11:45 PM, Andriy Gapon wrote:
on 16/12/2012 07:00 Ian Lepore said the following:
Some developer already made that choice by coding a
KASSERT() instead of a panic().
Please don't perpetuate this argument. The point of
On 15 December 2012 23:45, Andriy Gapon a...@freebsd.org wrote:
on 16/12/2012 07:00 Ian Lepore said the following:
The question here isn't whether aborting or continuing beyond that point
is a good idea. Some developer already made that choice by coding a
KASSERT() instead of a panic(). The
On Sun, Dec 16, 2012 at 09:23:13AM -0800, Adrian Chadd wrote:
On 15 December 2012 23:45, Andriy Gapon a...@freebsd.org wrote:
on 16/12/2012 07:00 Ian Lepore said the following:
The question here isn't whether aborting or continuing beyond that point
is a good idea. Some developer already
On 16 December 2012 15:32, Navdeep Parhar npar...@gmail.com wrote:
The status quo _does not change_ by default.
So now we have a knob that could be used to change the behaviour of all
the KASSERTs in the system; one that hints that it may be possible to
continue even if an assertion in the
On Fri, 14 Dec 2012, Alfred Perlstein wrote:
On 12/14/12 4:12 PM, Robert Watson wrote:
On Fri, 14 Dec 2012, John Baldwin wrote:
On Thursday, December 13, 2012 4:02:15 am Gleb Smirnoff wrote:
On Wed, Dec 12, 2012 at 04:53:48PM -0800, Alfred Perlstein wrote: A The
problem again is that not
On 12/14/12 10:04 PM, Bruce Evans wrote:
On Fri, 14 Dec 2012, Alfred Perlstein wrote:
On 12/14/12 4:12 PM, Robert Watson wrote:
On Fri, 14 Dec 2012, John Baldwin wrote:
On Thursday, December 13, 2012 4:02:15 am Gleb Smirnoff wrote:
On Wed, Dec 12, 2012 at 04:53:48PM -0800, Alfred Perlstein
On Sat, Dec 15, 2012 at 04:35:25AM -0800, Alfred Perlstein wrote:
A People keep beating this drum all invariants/panics are there for a
A reason, no, some happen to be bugs, and when I'm shipping code to a
A customer, I may need to skip one of these buggy assertions.
Yes, if you know any buggy
On 12/15/12 5:01 AM, Gleb Smirnoff wrote:
On Sat, Dec 15, 2012 at 04:35:25AM -0800, Alfred Perlstein wrote:
A People keep beating this drum all invariants/panics are there for a
A reason, no, some happen to be bugs, and when I'm shipping code to a
A customer, I may need to skip one of these
On Sat, Dec 15, 2012 at 05:29:10AM -0800, Alfred Perlstein wrote:
A On 12/15/12 5:01 AM, Gleb Smirnoff wrote:
A On Sat, Dec 15, 2012 at 04:35:25AM -0800, Alfred Perlstein wrote:
A A People keep beating this drum all invariants/panics are there for a
A A reason, no, some happen to be bugs, and
On 12/15/12 6:17 AM, Gleb Smirnoff wrote:
On Sat, Dec 15, 2012 at 05:29:10AM -0800, Alfred Perlstein wrote:
A On 12/15/12 5:01 AM, Gleb Smirnoff wrote:
A On Sat, Dec 15, 2012 at 04:35:25AM -0800, Alfred Perlstein wrote:
A A People keep beating this drum all invariants/panics are there for a
A
On Wed, Dec 12, 2012 at 04:02:58PM -0800, Navdeep Parhar wrote:
On 12/12/12 14:48, Alfred Perlstein wrote:
On 12/12/12 2:29 PM, Andriy Gapon wrote:
Now we get a new middle-ground: get both worse performance (because
KASSERTs are compiled in) and a risk of harming your data (because
On Wed, Dec 12, 2012 at 04:41:45PM -0800, Adrian Chadd wrote:
If a kassert is inviolable, then make it a panic() and include in the
default kernel.
It is inviolable. We don't include it in default kernel as panic for
performance reasons, but it doesn't mean it can happen. If it happens it
is
On Wed, Dec 12, 2012 at 04:53:48PM -0800, Alfred Perlstein wrote:
Like what if I do gzipp'd kernel dumps next? (on my todo list) How many
people will complain that gzip is too dangerous in kernel context foo
foo
Not sure, I guess I'll find out?
Well... :) savecore(8) has an option to
on 15/12/2012 23:03 Pawel Jakub Dawidek said the following:
On Wed, Dec 12, 2012 at 04:53:48PM -0800, Alfred Perlstein wrote:
Like what if I do gzipp'd kernel dumps next? (on my todo list) How many
people will complain that gzip is too dangerous in kernel context foo
foo
Not sure, I
Your use case (small swap large ram) is exactly why I would like to try this.
Do you object?
Sent from my iPhone
On Dec 15, 2012, at 1:03 PM, Pawel Jakub Dawidek p...@freebsd.org wrote:
On Wed, Dec 12, 2012 at 04:53:48PM -0800, Alfred Perlstein wrote:
Like what if I do gzipp'd kernel dumps
On Sat, Dec 15, 2012 at 02:33:37PM -0800, Alfred Perlstein wrote:
Your use case (small swap large ram) is exactly why I would like to try
this.
Do you object?
Let me quote myself, because you clearly missed my position:
I'm not against this change, but I would not use it myself.
[pruning the CC list]
On 2012-Dec-15 21:52:03 +0100, Pawel Jakub Dawidek p...@freebsd.org wrote:
On Wed, Dec 12, 2012 at 04:02:58PM -0800, Navdeep Parhar wrote:
A KASSERT() really is for a condition that should never happen.
and can't be practically recovered from.
I have sort of mixed feelings
On Sat, Dec 15, 2012 at 8:07 PM, Peter Jeremy pe...@rulingia.com wrote:
[pruning the CC list]
On 2012-Dec-15 21:52:03 +0100, Pawel Jakub Dawidek p...@freebsd.org wrote:
On Wed, Dec 12, 2012 at 04:02:58PM -0800, Navdeep Parhar wrote:
A KASSERT() really is for a condition that should never
On Sat, 2012-12-15 at 20:36 -0800, Peter Wemm wrote:
On Sat, Dec 15, 2012 at 8:07 PM, Peter Jeremy pe...@rulingia.com wrote:
[pruning the CC list]
On 2012-Dec-15 21:52:03 +0100, Pawel Jakub Dawidek p...@freebsd.org wrote:
On Wed, Dec 12, 2012 at 04:02:58PM -0800, Navdeep Parhar wrote:
A
on 16/12/2012 07:00 Ian Lepore said the following:
The question here isn't whether aborting or continuing beyond that point
is a good idea. Some developer already made that choice by coding a
KASSERT() instead of a panic(). The developer decided that a production
machine should try to keep
On Thursday, December 13, 2012 4:02:15 am Gleb Smirnoff wrote:
On Wed, Dec 12, 2012 at 04:53:48PM -0800, Alfred Perlstein wrote:
A The problem again is that not all the KASSERTS are inviolable, if you
A want to do a project to split them, then please do, it would really be
A helpful, as for
on 13/12/2012 19:01 m...@freebsd.org said the following:
Tools, not policy.
A non-panic-ing KASSERT is a tool, not enabled by default. You don't
need to use it. Someone does, so why can't we provide the tool?
So if some code is a tool and it is disabled by default and someone believes
On Fri, 14 Dec 2012, John Baldwin wrote:
On Thursday, December 13, 2012 4:02:15 am Gleb Smirnoff wrote:
On Wed, Dec 12, 2012 at 04:53:48PM -0800, Alfred Perlstein wrote: A The
problem again is that not all the KASSERTS are inviolable, if you A want
to do a project to split them, then please
On 12/14/12 4:12 PM, Robert Watson wrote:
On Fri, 14 Dec 2012, John Baldwin wrote:
On Thursday, December 13, 2012 4:02:15 am Gleb Smirnoff wrote:
On Wed, Dec 12, 2012 at 04:53:48PM -0800, Alfred Perlstein wrote: A
The problem again is that not all the KASSERTS are inviolable, if
you A want
On 12/13/12 6:37 AM, Andriy Gapon wrote:
on 12/12/2012 19:06 Adrian Chadd said the following:
kassert()s are already optional. Ie, you can choose to not compile them in.
So the __dead2() code path bit for doing KASSERT() - kassert_panic()
at compile time isn't a problem.
The problem is where
On Wed, Dec 12, 2012 at 10:49:44PM -0800, Adrian Chadd wrote:
A Let me restate it again.
A
A We can ship a STABLE kernel with INVARIANTS enabled, and it not be any
A less stable than the STABLE kernel is today.
It will be less stable, at least due to thrashing memory on free(9).
Accessing memory
On Wed, Dec 12, 2012 at 04:53:48PM -0800, Alfred Perlstein wrote:
A The problem again is that not all the KASSERTS are inviolable, if you
A want to do a project to split them, then please do, it would really be
A helpful, as for now, they are a mis-mash of death/warnings and there are
A at
On Wed, Dec 12, 2012 at 11:16:43PM -0800, Adrian Chadd wrote:
A I think the fundamental problem here is we have some pretty different
A ideas of what KASSERT should be, versus what it actually is in various
A parts of the code.
Yep, under we you probably meant you and Alfred. What both of you
on 13/12/2012 09:16 Adrian Chadd said the following:
Hi,
I think the fundamental problem here is we have some pretty different
ideas of what KASSERT should be, versus what it actually is in various
parts of the code.
Since we're lost in semantics, we're not going to get any further on
on 13/12/2012 09:16 Adrian Chadd said the following:
Hi,
I think the fundamental problem here is we have some pretty different
ideas of what KASSERT should be, versus what it actually is in various
parts of the code.
Oh, and another part of the problem is that the discussion is opinion
On Thu, Dec 13, 2012 at 1:42 AM, Andriy Gapon a...@freebsd.org wrote:
on 13/12/2012 09:16 Adrian Chadd said the following:
Hi,
I think the fundamental problem here is we have some pretty different
ideas of what KASSERT should be, versus what it actually is in various
parts of the code.
Oh,
On Tuesday, December 11, 2012 2:08:14 am Alfred Perlstein wrote:
Author: alfred
Date: Tue Dec 11 07:08:14 2012
New Revision: 244112
URL: http://svnweb.freebsd.org/changeset/base/244112
Log:
Cleanup more of the kassert_panic.
fix compile warnings on !amd64 and NULL derefs that
kassert()s are already optional. Ie, you can choose to not compile them in.
So the __dead2() code path bit for doing KASSERT() - kassert_panic()
at compile time isn't a problem.
The problem is where you do panic() - kassert_panic() (eg in the
Witness code) which is what Alfred discovered shortly
to all:
I am trying to take this offline with John so that we can discuss the
reasoning behind the change and come to an agreement on how it is
implemented, or if not to remove it.
-Alfred
On 12/12/12 7:46 AM, John Baldwin wrote:
On Tuesday, December 11, 2012 2:08:14 am Alfred Perlstein
On Wednesday, December 12, 2012 12:06:22 pm Adrian Chadd wrote:
kassert()s are already optional. Ie, you can choose to not compile them in.
So the __dead2() code path bit for doing KASSERT() - kassert_panic()
at compile time isn't a problem.
The problem is where you do panic() -
On 12 December 2012 13:58, John Baldwin j...@freebsd.org wrote:
Anything which is a KASSERT() can and should be treated as a run-time
warning just as much as a run-time crash here so I can figure out
what broke. Having the warning in a production box is going to be
helpful for developers.
On 12/12/12 2:15 PM, Adrian Chadd wrote:
On 12 December 2012 13:58, John Baldwin j...@freebsd.org wrote:
(Note that the primary reason I know for people not running with INVARIANTS
enabled is not that they don't want panics, but that they don't want the
performance hit.)
Well, it would be
on 12/12/2012 23:58 John Baldwin said the following:
Hmmm, I'll have to chew on this. Adding lots of returns because panic's are
now no longer dead2 was why I ended up backing the removal of the
RESTARTABLE_PANICS option.
I'm inclined to say that it's really bad to let a kernel known to be
on 13/12/2012 00:27 Alfred Perlstein said the following:
On 12/12/12 2:15 PM, Adrian Chadd wrote:
On 12 December 2012 13:58, John Baldwin j...@freebsd.org wrote:
(Note that the primary reason I know for people not running with INVARIANTS
enabled is not that they don't want panics, but that
on 12/12/2012 19:06 Adrian Chadd said the following:
kassert()s are already optional. Ie, you can choose to not compile them in.
So the __dead2() code path bit for doing KASSERT() - kassert_panic()
at compile time isn't a problem.
The problem is where you do panic() - kassert_panic() (eg
There are two parts to this;
* don't compile in invariants. Panics panic. Invariant conditions
aren't checked. You end up with data corruption still if there are
bugs.
* compile in invariants. Panics panic. Invariant conditions are
checked and immediately panic. You can't run this in production
On 12 December 2012 14:33, Andriy Gapon a...@freebsd.org wrote:
Yes, two of my employers were more of we want to get more debug metrics, we
have the spare cycles, but we can't deal with superfluous panics.
It also allows us non-architects to slip in a debug image when we have
spare
cpu
On 12/12/12 2:29 PM, Andriy Gapon wrote:
Now we get a new middle-ground: get both worse performance (because
KASSERTs are compiled in) and a risk of harming your data (because
KASSERTs no longer panic). The upside: there is no panic! There's just
a log message (or etc). and chance to get more
On 12/12/12 2:38 PM, Adrian Chadd wrote:
There are two parts to this;
* don't compile in invariants. Panics panic. Invariant conditions
aren't checked. You end up with data corruption still if there are
bugs.
* compile in invariants. Panics panic. Invariant conditions are
checked and
On 12/12/12 14:48, Alfred Perlstein wrote:
On 12/12/12 2:29 PM, Andriy Gapon wrote:
Now we get a new middle-ground: get both worse performance (because
KASSERTs are compiled in) and a risk of harming your data (because
KASSERTs no longer panic). The upside: there is no panic! There's just
a
On 12/12/12 4:02 PM, Navdeep Parhar wrote:
On 12/12/12 14:48, Alfred Perlstein wrote:
On 12/12/12 2:29 PM, Andriy Gapon wrote:
Now we get a new middle-ground: get both worse performance (because
KASSERTs are compiled in) and a risk of harming your data (because
KASSERTs no longer panic). The
On 12/12/12 16:09, Alfred Perlstein wrote:
On 12/12/12 4:02 PM, Navdeep Parhar wrote:
On 12/12/12 14:48, Alfred Perlstein wrote:
On 12/12/12 2:29 PM, Andriy Gapon wrote:
Now we get a new middle-ground: get both worse performance (because
KASSERTs are compiled in) and a risk of harming your
If a kassert is inviolable, then make it a panic() and include in the
default kernel.
Right now there's no distinction between kassert for a condition that
shouldn't happen, but we fail gracefully and kassert for a condition
that shouldn't happen, and we don't handle at all.
Ideally we'd create
On 12/12/12 4:25 PM, Navdeep Parhar wrote:
On 12/12/12 16:09, Alfred Perlstein wrote:
What do you think happens to a FreeBSD kernel when INVARIANTS is
compiled in and it trips an assertion after my change?
I know the new knob has sane defaults. My point was that invariants
should be
.. just make sure you've preallocated all the space needed by the gzip
code when writing those dumps. :-)
Adrian
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to
on 13/12/2012 00:38 Adrian Chadd said the following:
There are two parts to this;
* don't compile in invariants. Panics panic. Invariant conditions
aren't checked. You end up with data corruption still if there are
bugs.
* compile in invariants. Panics panic. Invariant conditions are
Let me restate it again.
We can ship a STABLE kernel with INVARIANTS enabled, and it not be any
less stable than the STABLE kernel is today.
Adrian
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To
on 13/12/2012 00:43 Adrian Chadd said the following:
On 12 December 2012 14:33, Andriy Gapon a...@freebsd.org wrote:
Yes, two of my employers were more of we want to get more debug metrics, we
have the spare cycles, but we can't deal with superfluous panics.
It also allows us non-architects
on 13/12/2012 00:48 Alfred Perlstein said the following:
On 12/12/12 2:29 PM, Andriy Gapon wrote:
Now we get a new middle-ground: get both worse performance (because KASSERTs
are compiled in) and a risk of harming your data (because KASSERTs no longer
panic). The upside: there is no panic!
Andriy,
If you are willing to enable INVARIANTS by default in GENERIC, right
now, then I think we should remove Alfred's work.
Adrian
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send
on 13/12/2012 08:49 Adrian Chadd said the following:
Let me restate it again.
We can ship a STABLE kernel with INVARIANTS enabled, and it not be any
less stable than the STABLE kernel is today.
STABLE != stable, of course.
And it will be much much slower, so no one (of the regular users)
on 13/12/2012 09:07 Adrian Chadd said the following:
Andriy,
If you are willing to enable INVARIANTS by default in GENERIC, right
now, then I think we should remove Alfred's work.
I do not see any connection.
INVARIANTS in !CURRENT will not be enabled in GENERIC regardless of Alfred'd
work.
Hi,
I think the fundamental problem here is we have some pretty different
ideas of what KASSERT should be, versus what it actually is in various
parts of the code.
Since we're lost in semantics, we're not going to get any further on
this discussion just for now, so let's take a break and think
On Wed, Dec 12, 2012 at 11:07:58PM -0800, Adrian Chadd wrote:
Andriy,
If you are willing to enable INVARIANTS by default in GENERIC, right
now, then I think we should remove Alfred's work.
It's already enabled by default in GENERIC in the development branch
(aka head), which is exactly the
On 12 December 2012 23:19, Navdeep Parhar npar...@gmail.com wrote:
On Wed, Dec 12, 2012 at 11:07:58PM -0800, Adrian Chadd wrote:
Andriy,
If you are willing to enable INVARIANTS by default in GENERIC, right
now, then I think we should remove Alfred's work.
It's already enabled by default in
on 11/12/2012 09:08 Alfred Perlstein said the following:
Author: alfred
Date: Tue Dec 11 07:08:14 2012
New Revision: 244112
URL: http://svnweb.freebsd.org/changeset/base/244112
Log:
Cleanup more of the kassert_panic.
fix compile warnings on !amd64 and NULL derefs that would happen
Author: alfred
Date: Tue Dec 11 07:08:14 2012
New Revision: 244112
URL: http://svnweb.freebsd.org/changeset/base/244112
Log:
Cleanup more of the kassert_panic.
fix compile warnings on !amd64 and NULL derefs that would happen
if kassert_panic() would return.
Modified:
77 matches
Mail list logo
