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:
> O
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-head@freebsd.org ma
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 tha
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 wro
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 2
On Sunday, December 16, 2012 10:05:48 pm Adrian Chadd wrote:
> On 16 December 2012 15:32, Navdeep Parhar 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 tha
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 couple
On 12/17/12 14:02, Adrian Chadd wrote:
> On 17 December 2012 13:47, Andriy Gapon 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
On 17 December 2012 13:47, Andriy Gapon 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
trusted, believe
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
___
svn-src-head@free
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, thank
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 wrot
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
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
On 16 December 2012 15:32, Navdeep Parhar 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 FreeBSD kern
On Sun, Dec 16, 2012 at 09:23:13AM -0800, Adrian Chadd wrote:
> On 15 December 2012 23:45, 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
On 15 December 2012 23:45, 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
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 poin
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 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 kee
On Sat, 2012-12-15 at 20:36 -0800, Peter Wemm wrote:
> On Sat, Dec 15, 2012 at 8:07 PM, Peter Jeremy wrote:
> > [pruning the CC list]
> > On 2012-Dec-15 21:52:03 +0100, Pawel Jakub Dawidek wrote:
> >>On Wed, Dec 12, 2012 at 04:02:58PM -0800, Navdeep Parhar wrote:
> >>> A KASSERT() really is for a
On Sat, Dec 15, 2012 at 8:07 PM, Peter Jeremy wrote:
> [pruning the CC list]
> On 2012-Dec-15 21:52:03 +0100, Pawel Jakub Dawidek 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 practical
[pruning the CC list]
On 2012-Dec-15 21:52:03 +0100, Pawel Jakub Dawidek 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 about this c
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 mys
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 wrote:
> 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
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"
>>
>>
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 opt
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 u
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 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 fo
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 b
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 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 bu
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 w
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 al
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 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 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 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 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, a
On Thu, Dec 13, 2012 at 1:42 AM, Andriy Gapon 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, and
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 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 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 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 l
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 mem
On 12 December 2012 23:19, Navdeep Parhar 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 GENERIC
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 th
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 ab
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
wor
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)
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-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, sen
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 pani
on 13/12/2012 00:43 Adrian Chadd said the following:
> On 12 December 2012 14:33, Andriy Gapon 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
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-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To uns
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
>
.. just make sure you've preallocated all the space needed by the gzip
code when writing those dumps. :-)
Adrian
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-
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 consider
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 crea
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 ha
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 up
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 jus
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 immediately
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 l
On 12 December 2012 14:33, Andriy Gapon 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 with
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 to
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(
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 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
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
On 12/12/12 2:15 PM, Adrian Chadd wrote:
On 12 December 2012 13:58, John Baldwin 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 nice to be able to
On 12 December 2012 13:58, John Baldwin 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.
>
> Hmmm,
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() -> kas
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 wro
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 shortl
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 t
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 woul
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:
head/sys/kern/subr
77 matches
Mail list logo
