* BUG_ON() vs ASSERT()
@ 2016-09-12 15:23 Jan Beulich
2016-09-13 13:10 ` Konrad Rzeszutek Wilk
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Jan Beulich @ 2016-09-12 15:23 UTC (permalink / raw)
To: xen-devel
All,
in
https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01201.html
and
https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01210.html
Andrew basically suggests that we should switch away from using
ASSERT() and over to BUG_ON() in perhaps quite broad a set of
cases. And honestly I'm not convinced of this: We've been adding
quite a few ASSERT()s over the last years with the aim of doing
sanity checking in debug builds, without adding overhead to non-
debug builds. I can certainly see possible cases where using
BUG_ON() to prevent further possible damage is appropriate, but
I don't think we should overdo here.
Thanks for other's opinions,
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: BUG_ON() vs ASSERT() 2016-09-12 15:23 BUG_ON() vs ASSERT() Jan Beulich @ 2016-09-13 13:10 ` Konrad Rzeszutek Wilk 2016-09-13 13:46 ` Mihai Donțu 2016-09-13 13:24 ` Paul Durrant 2016-09-13 18:16 ` Andrew Cooper 2 siblings, 1 reply; 10+ messages in thread From: Konrad Rzeszutek Wilk @ 2016-09-13 13:10 UTC (permalink / raw) To: Jan Beulich; +Cc: xen-devel On Mon, Sep 12, 2016 at 09:23:41AM -0600, Jan Beulich wrote: > All, > > in > https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01201.html > and > https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01210.html > Andrew basically suggests that we should switch away from using > ASSERT() and over to BUG_ON() in perhaps quite broad a set of > cases. And honestly I'm not convinced of this: We've been adding > quite a few ASSERT()s over the last years with the aim of doing > sanity checking in debug builds, without adding overhead to non- > debug builds. I can certainly see possible cases where using > BUG_ON() to prevent further possible damage is appropriate, but > I don't think we should overdo here. > > Thanks for other's opinions, I am in the mindset that ASSERTS are in the cases where a check has been done earlier and the ASSERT is more of a catch if we ended up somehow in the wrong state. We can then slowly follow the breadcrumbs to see what changed the state. In other words - something that the hypervisor has checked for and that invariant should have not changed. But a BUG_ON is in the same category - it should not have happend. Perhaps the distinction is that for ASSERTS() it is to catch me messing things up. While BUG_ON() is something (or somebody) else messing things up. It is kind of hard to describe the semantic of an ASSERT vs BUG_ON now that I think of it .. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: BUG_ON() vs ASSERT() 2016-09-13 13:10 ` Konrad Rzeszutek Wilk @ 2016-09-13 13:46 ` Mihai Donțu 2016-09-13 18:25 ` Andrew Cooper 0 siblings, 1 reply; 10+ messages in thread From: Mihai Donțu @ 2016-09-13 13:46 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: xen-devel, Jan Beulich On Tue, 13 Sep 2016 09:10:32 -0400 Konrad Rzeszutek Wilk wrote: > On Mon, Sep 12, 2016 at 09:23:41AM -0600, Jan Beulich wrote: > > All, > > > > in > > https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01201.html > > and > > https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01210.html > > Andrew basically suggests that we should switch away from using > > ASSERT() and over to BUG_ON() in perhaps quite broad a set of > > cases. And honestly I'm not convinced of this: We've been adding > > quite a few ASSERT()s over the last years with the aim of doing > > sanity checking in debug builds, without adding overhead to non- > > debug builds. I can certainly see possible cases where using > > BUG_ON() to prevent further possible damage is appropriate, but > > I don't think we should overdo here. > > > > Thanks for other's opinions, > > I am in the mindset that ASSERTS are in the cases where a check > has been done earlier and the ASSERT is more of a catch if we ended up > somehow in the wrong state. We can then slowly follow the breadcrumbs to > see what changed the state. In other words - something that the hypervisor > has checked for and that invariant should have not changed. > > But a BUG_ON is in the same category - it should not have happend. > > Perhaps the distinction is that for ASSERTS() it is to catch me messing > things up. While BUG_ON() is something (or somebody) else messing things up. > > It is kind of hard to describe the semantic of an ASSERT vs BUG_ON now > that I think of it .. I would see ASSERT() used to check for conditions that have immediate and visible consequences, like the ones that lead to lack of functionality (like a hw feature misdetection) or straight crashes (like NULL-dereference). BUG_ON(), on the other hand, would be an early warning for subtle corruptions that can lead to a hypervisor crash or corrupted data after many hours of use (close to impossible to track down). For example, a while ago I posted a small patch that would BUG_ON() when it detected that the heap chunks were not properly linked. That's the type of bug that's a pain to detect. -- Mihai Donțu _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: BUG_ON() vs ASSERT() 2016-09-13 13:46 ` Mihai Donțu @ 2016-09-13 18:25 ` Andrew Cooper 2016-09-14 17:01 ` Mihai Donțu 0 siblings, 1 reply; 10+ messages in thread From: Andrew Cooper @ 2016-09-13 18:25 UTC (permalink / raw) To: Mihai Donțu, Konrad Rzeszutek Wilk; +Cc: xen-devel, Jan Beulich On 13/09/16 14:46, Mihai Donțu wrote: > On Tue, 13 Sep 2016 09:10:32 -0400 Konrad Rzeszutek Wilk wrote: >> On Mon, Sep 12, 2016 at 09:23:41AM -0600, Jan Beulich wrote: >>> All, >>> >>> in >>> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01201.html >>> and >>> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01210.html >>> Andrew basically suggests that we should switch away from using >>> ASSERT() and over to BUG_ON() in perhaps quite broad a set of >>> cases. And honestly I'm not convinced of this: We've been adding >>> quite a few ASSERT()s over the last years with the aim of doing >>> sanity checking in debug builds, without adding overhead to non- >>> debug builds. I can certainly see possible cases where using >>> BUG_ON() to prevent further possible damage is appropriate, but >>> I don't think we should overdo here. >>> >>> Thanks for other's opinions, >> I am in the mindset that ASSERTS are in the cases where a check >> has been done earlier and the ASSERT is more of a catch if we ended up >> somehow in the wrong state. We can then slowly follow the breadcrumbs to >> see what changed the state. In other words - something that the hypervisor >> has checked for and that invariant should have not changed. >> >> But a BUG_ON is in the same category - it should not have happend. >> >> Perhaps the distinction is that for ASSERTS() it is to catch me messing >> things up. While BUG_ON() is something (or somebody) else messing things up. >> >> It is kind of hard to describe the semantic of an ASSERT vs BUG_ON now >> that I think of it .. > I would see ASSERT() used to check for conditions that have immediate > and visible consequences, like the ones that lead to lack of > functionality (like a hw feature misdetection) or straight crashes > (like NULL-dereference). NULL dereferences in the context of PV guests are also a security issue, as the PV guest controls what is mapped at 0. > BUG_ON(), on the other hand, would be an early > warning for subtle corruptions that can lead to a hypervisor crash or > corrupted data after many hours of use (close to impossible to track > down). > > For example, a while ago I posted a small patch that would BUG_ON() > when it detected that the heap chunks were not properly linked. That's > the type of bug that's a pain to detect. Speaking of, what happened to that patch? ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: BUG_ON() vs ASSERT() 2016-09-13 18:25 ` Andrew Cooper @ 2016-09-14 17:01 ` Mihai Donțu 0 siblings, 0 replies; 10+ messages in thread From: Mihai Donțu @ 2016-09-14 17:01 UTC (permalink / raw) To: Andrew Cooper; +Cc: xen-devel, Jan Beulich On Tue, 13 Sep 2016 19:25:54 +0100 Andrew Cooper wrote: > On 13/09/16 14:46, Mihai Donțu wrote: > > On Tue, 13 Sep 2016 09:10:32 -0400 Konrad Rzeszutek Wilk wrote: > >> On Mon, Sep 12, 2016 at 09:23:41AM -0600, Jan Beulich wrote: > >>> All, > >>> > >>> in > >>> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01201.html > >>> and > >>> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01210.html > >>> Andrew basically suggests that we should switch away from using > >>> ASSERT() and over to BUG_ON() in perhaps quite broad a set of > >>> cases. And honestly I'm not convinced of this: We've been adding > >>> quite a few ASSERT()s over the last years with the aim of doing > >>> sanity checking in debug builds, without adding overhead to non- > >>> debug builds. I can certainly see possible cases where using > >>> BUG_ON() to prevent further possible damage is appropriate, but > >>> I don't think we should overdo here. > >>> > >>> Thanks for other's opinions, > >> I am in the mindset that ASSERTS are in the cases where a check > >> has been done earlier and the ASSERT is more of a catch if we ended up > >> somehow in the wrong state. We can then slowly follow the breadcrumbs to > >> see what changed the state. In other words - something that the hypervisor > >> has checked for and that invariant should have not changed. > >> > >> But a BUG_ON is in the same category - it should not have happend. > >> > >> Perhaps the distinction is that for ASSERTS() it is to catch me messing > >> things up. While BUG_ON() is something (or somebody) else messing things up. > >> > >> It is kind of hard to describe the semantic of an ASSERT vs BUG_ON now > >> that I think of it .. > > I would see ASSERT() used to check for conditions that have immediate > > and visible consequences, like the ones that lead to lack of > > functionality (like a hw feature misdetection) or straight crashes > > (like NULL-dereference). > > NULL dereferences in the context of PV guests are also a security issue, > as the PV guest controls what is mapped at 0. > > > BUG_ON(), on the other hand, would be an early > > warning for subtle corruptions that can lead to a hypervisor crash or > > corrupted data after many hours of use (close to impossible to track > > down). > > > > For example, a while ago I posted a small patch that would BUG_ON() > > when it detected that the heap chunks were not properly linked. That's > > the type of bug that's a pain to detect. > > Speaking of, what happened to that patch? I did not post and updated version after the last review because I wanted to produce some numbers too (wrt performance impact) ... and I stopped there as I got distracted by other issues. I have a good mind to update it, write a quick test and publish them. I hope I can do this all sometime next week. -- Mihai Donțu _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: BUG_ON() vs ASSERT() 2016-09-12 15:23 BUG_ON() vs ASSERT() Jan Beulich 2016-09-13 13:10 ` Konrad Rzeszutek Wilk @ 2016-09-13 13:24 ` Paul Durrant 2016-09-13 18:16 ` Andrew Cooper 2 siblings, 0 replies; 10+ messages in thread From: Paul Durrant @ 2016-09-13 13:24 UTC (permalink / raw) To: Jan Beulich, xen-devel > -----Original Message----- > From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Jan > Beulich > Sent: 12 September 2016 16:24 > To: xen-devel <xen-devel@lists.xenproject.org> > Subject: [Xen-devel] BUG_ON() vs ASSERT() > > All, > > in > https://lists.xenproject.org/archives/html/xen-devel/2016- > 09/msg01201.html > and > https://lists.xenproject.org/archives/html/xen-devel/2016- > 09/msg01210.html > Andrew basically suggests that we should switch away from using > ASSERT() and over to BUG_ON() in perhaps quite broad a set of cases. And > honestly I'm not convinced of this: We've been adding quite a few ASSERT()s > over the last years with the aim of doing sanity checking in debug builds, > without adding overhead to non- debug builds. I can certainly see possible > cases where using > BUG_ON() to prevent further possible damage is appropriate, but I don't > think we should overdo here. > > Thanks for other's opinions, If there's a situation where code can survive a 'should not happen' then an ASSERT is good to catch the 'should not happen' when debugging, but being compiled out in production is fine. If the code is definitely not going to survive a 'should not happen' then I think a BUG_ON at the earliest opportunity is a good thing because it makes post mortem diagnosis much easier. Clearly this does have to be balanced against the cost of calculation of the subject of the BUG_ON though. Paul > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: BUG_ON() vs ASSERT() 2016-09-12 15:23 BUG_ON() vs ASSERT() Jan Beulich 2016-09-13 13:10 ` Konrad Rzeszutek Wilk 2016-09-13 13:24 ` Paul Durrant @ 2016-09-13 18:16 ` Andrew Cooper 2016-09-14 8:35 ` George Dunlap 2 siblings, 1 reply; 10+ messages in thread From: Andrew Cooper @ 2016-09-13 18:16 UTC (permalink / raw) To: Jan Beulich, xen-devel On 12/09/16 16:23, Jan Beulich wrote: > All, > > in > https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01201.html > and > https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01210.html > Andrew basically suggests that we should switch away from using > ASSERT() and over to BUG_ON() in perhaps quite broad a set of > cases. And honestly I'm not convinced of this: We've been adding > quite a few ASSERT()s over the last years with the aim of doing > sanity checking in debug builds, without adding overhead to non- > debug builds. I can certainly see possible cases where using > BUG_ON() to prevent further possible damage is appropriate, but > I don't think we should overdo here. I am not advocating switching all ASSERT()s to BUG_ON()s. That would be silly. However, ASSERT()'s as a bounds check very definitely are dangerous. If there is any uncertainty about the bounds, the check must not disappear in a release build. (Better yet, code which copes cleanly with insufficient bounds). For anyone reading this email who hasn't already worked out the details of XSA-186, the data corruption issue is here: static int hvmemul_insn_fetch(...) { unsigned int insn_off = offset - hvmemul_ctxt->insn_buf_eip; ... ASSERT(insn_off + bytes <= sizeof(hvmemul_ctxt->insn_buf)); memcpy(&hvmemul_ctxt->insn_buf[insn_off], p_data, bytes); ... It is left as an exercise to the reader to work out how to exploit this on a release build of Xen, but it is hopefully obvious that the ASSERT() isn't helpful. A BUG_ON() in this case would have been a host DoS, which is substantially better than a guest escape. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: BUG_ON() vs ASSERT() 2016-09-13 18:16 ` Andrew Cooper @ 2016-09-14 8:35 ` George Dunlap 2016-09-14 9:11 ` Andrew Cooper 2016-09-14 9:26 ` Sander Eikelenboom 0 siblings, 2 replies; 10+ messages in thread From: George Dunlap @ 2016-09-14 8:35 UTC (permalink / raw) To: Andrew Cooper; +Cc: xen-devel, Jan Beulich On Tue, Sep 13, 2016 at 7:16 PM, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > On 12/09/16 16:23, Jan Beulich wrote: >> All, >> >> in >> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01201.html >> and >> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01210.html >> Andrew basically suggests that we should switch away from using >> ASSERT() and over to BUG_ON() in perhaps quite broad a set of >> cases. And honestly I'm not convinced of this: We've been adding >> quite a few ASSERT()s over the last years with the aim of doing >> sanity checking in debug builds, without adding overhead to non- >> debug builds. I can certainly see possible cases where using >> BUG_ON() to prevent further possible damage is appropriate, but >> I don't think we should overdo here. > > I am not advocating switching all ASSERT()s to BUG_ON()s. That would be > silly. > > However, ASSERT()'s as a bounds check very definitely are dangerous. If > there is any uncertainty about the bounds, the check must not disappear > in a release build. (Better yet, code which copes cleanly with > insufficient bounds). > > > For anyone reading this email who hasn't already worked out the details > of XSA-186, the data corruption issue is here: > > static int hvmemul_insn_fetch(...) > { > unsigned int insn_off = offset - hvmemul_ctxt->insn_buf_eip; > ... > ASSERT(insn_off + bytes <= sizeof(hvmemul_ctxt->insn_buf)); > memcpy(&hvmemul_ctxt->insn_buf[insn_off], p_data, bytes); > ... > > It is left as an exercise to the reader to work out how to exploit this > on a release build of Xen, but it is hopefully obvious that the ASSERT() > isn't helpful. A BUG_ON() in this case would have been a host DoS, > which is substantially better than a guest escape. This seems quite sensible, and I'm glad Andy clarified. (Although in a lot of these cases, a domain_crash() would be preferable to a BUG_ON() if possible.) -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: BUG_ON() vs ASSERT() 2016-09-14 8:35 ` George Dunlap @ 2016-09-14 9:11 ` Andrew Cooper 2016-09-14 9:26 ` Sander Eikelenboom 1 sibling, 0 replies; 10+ messages in thread From: Andrew Cooper @ 2016-09-14 9:11 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel, Jan Beulich On 14/09/16 09:35, George Dunlap wrote: > On Tue, Sep 13, 2016 at 7:16 PM, Andrew Cooper > <andrew.cooper3@citrix.com> wrote: >> On 12/09/16 16:23, Jan Beulich wrote: >>> All, >>> >>> in >>> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01201.html >>> and >>> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01210.html >>> Andrew basically suggests that we should switch away from using >>> ASSERT() and over to BUG_ON() in perhaps quite broad a set of >>> cases. And honestly I'm not convinced of this: We've been adding >>> quite a few ASSERT()s over the last years with the aim of doing >>> sanity checking in debug builds, without adding overhead to non- >>> debug builds. I can certainly see possible cases where using >>> BUG_ON() to prevent further possible damage is appropriate, but >>> I don't think we should overdo here. >> I am not advocating switching all ASSERT()s to BUG_ON()s. That would be >> silly. >> >> However, ASSERT()'s as a bounds check very definitely are dangerous. If >> there is any uncertainty about the bounds, the check must not disappear >> in a release build. (Better yet, code which copes cleanly with >> insufficient bounds). >> >> >> For anyone reading this email who hasn't already worked out the details >> of XSA-186, the data corruption issue is here: >> >> static int hvmemul_insn_fetch(...) >> { >> unsigned int insn_off = offset - hvmemul_ctxt->insn_buf_eip; >> ... >> ASSERT(insn_off + bytes <= sizeof(hvmemul_ctxt->insn_buf)); >> memcpy(&hvmemul_ctxt->insn_buf[insn_off], p_data, bytes); >> ... >> >> It is left as an exercise to the reader to work out how to exploit this >> on a release build of Xen, but it is hopefully obvious that the ASSERT() >> isn't helpful. A BUG_ON() in this case would have been a host DoS, >> which is substantially better than a guest escape. > This seems quite sensible, and I'm glad Andy clarified. (Although in > a lot of these cases, a domain_crash() would be preferable to a > BUG_ON() if possible.) Absolutely. Clean error handling without a crash is certainly preferable when possible. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: BUG_ON() vs ASSERT() 2016-09-14 8:35 ` George Dunlap 2016-09-14 9:11 ` Andrew Cooper @ 2016-09-14 9:26 ` Sander Eikelenboom 1 sibling, 0 replies; 10+ messages in thread From: Sander Eikelenboom @ 2016-09-14 9:26 UTC (permalink / raw) To: George Dunlap; +Cc: Andrew Cooper, Jan Beulich, xen-devel Wednesday, September 14, 2016, 10:35:30 AM, you wrote: > On Tue, Sep 13, 2016 at 7:16 PM, Andrew Cooper > <andrew.cooper3@citrix.com> wrote: >> On 12/09/16 16:23, Jan Beulich wrote: >>> All, >>> >>> in >>> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01201.html >>> and >>> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01210.html >>> Andrew basically suggests that we should switch away from using >>> ASSERT() and over to BUG_ON() in perhaps quite broad a set of >>> cases. And honestly I'm not convinced of this: We've been adding >>> quite a few ASSERT()s over the last years with the aim of doing >>> sanity checking in debug builds, without adding overhead to non- >>> debug builds. I can certainly see possible cases where using >>> BUG_ON() to prevent further possible damage is appropriate, but >>> I don't think we should overdo here. >> >> I am not advocating switching all ASSERT()s to BUG_ON()s. That would be >> silly. >> >> However, ASSERT()'s as a bounds check very definitely are dangerous. If >> there is any uncertainty about the bounds, the check must not disappear >> in a release build. (Better yet, code which copes cleanly with >> insufficient bounds). >> >> >> For anyone reading this email who hasn't already worked out the details >> of XSA-186, the data corruption issue is here: >> >> static int hvmemul_insn_fetch(...) >> { >> unsigned int insn_off = offset - hvmemul_ctxt->insn_buf_eip; >> ... >> ASSERT(insn_off + bytes <= sizeof(hvmemul_ctxt->insn_buf)); >> memcpy(&hvmemul_ctxt->insn_buf[insn_off], p_data, bytes); >> ... >> >> It is left as an exercise to the reader to work out how to exploit this >> on a release build of Xen, but it is hopefully obvious that the ASSERT() >> isn't helpful. A BUG_ON() in this case would have been a host DoS, >> which is substantially better than a guest escape. > This seems quite sensible, and I'm glad Andy clarified. (Although in > a lot of these cases, a domain_crash() would be preferable to a > BUG_ON() if possible.) > -George Just my two cents, but please try to limit BUG_ON()'s to only really unrecoverable cases. Because it is quite a disaster especially on remote administrated machines to have the host crash on a BUG_ON() (with or without auto restart). Try to recover (for instance if necessary by crashing the guest instead of the host) as much as you can to make at least the hypervisor and dom0 survive. Put a big fat warning in xl dmesg and taint the hypervisor (preferably in a way you could easily read out with monitoring tools), so you could propagate that to the sysadmin that the system is now deemed instable, so he can investigate (and report the bug), triage and schedule a reboot. Instead of only having a hard to debug crashing machine with probably no or limited logs to go by. In the Linux kernel the problem now is to get a lot of them converted back to ratelimited warnings instead of BUG_ON()'s. -- Sander _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-09-14 17:01 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-09-12 15:23 BUG_ON() vs ASSERT() Jan Beulich 2016-09-13 13:10 ` Konrad Rzeszutek Wilk 2016-09-13 13:46 ` Mihai Donțu 2016-09-13 18:25 ` Andrew Cooper 2016-09-14 17:01 ` Mihai Donțu 2016-09-13 13:24 ` Paul Durrant 2016-09-13 18:16 ` Andrew Cooper 2016-09-14 8:35 ` George Dunlap 2016-09-14 9:11 ` Andrew Cooper 2016-09-14 9:26 ` Sander Eikelenboom
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.