Date: Thu, 11 Jul 2013 16:20:32 -0500 From: Kevin Day <toasty@dragondata.com> To: Artem Belevich <art@freebsd.org> Cc: hackers@freebsd.org, "Jordan K. Hubbard" <jordan.hubbard@gmail.com> Subject: Re: Kernel dumps [was Re: possible changes from Panzura] Message-ID: <D1D5C3A2-8220-4FF6-B86F-3249D566CE4E@dragondata.com> In-Reply-To: <CAFqOu6j299gbsWh22fTnbKZUFZBVuwwV6M5bcJdH%2Bm%2BCWDin9g@mail.gmail.com> References: <FDEEB55D-823B-4899-8EEC-7F5306D91F5B@elischer.org> <9890DFF1-892A-4DCA-9E33-B70681154F43@mail.turbofuzz.com> <4F0DFAB7-D6D5-4068-A543-C9DF885D1A7D@dragondata.com> <51DEC0E8.7010305@freebsd.org> <EC032F13-AF97-4A1D-8772-02EF92613DA7@turbofuzz.com> <CAFqOu6j299gbsWh22fTnbKZUFZBVuwwV6M5bcJdH%2Bm%2BCWDin9g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On Jul 11, 2013, at 4:05 PM, Artem Belevich <art@freebsd.org> wrote:
>
> It would probably work for most of the crashes, but will not work in few interesting classes of failure. Using in-kernel stack implicitly assumes that your memory allocator still works as both the stack and the interface driver will need to get their mbufs and other data somewhere. Alas it's those unusual cases that are hardest to debug and where you really do want debugger or coredump to work.
>
> Back at my previous work we did it 'embedded system way'. Interface driver provided dumb functions to re-init device, send a frame and poll for received frame. All that without using system malloc. There was a dumb malloc that gave few chunks of memory from static buffer to gzip, but the rest of the code was independent of any kernel facilities. We had simple ARP/IP/UDP/TFTP(+gzip) implementation to upload compressed image of physical memory to a specified server. Overall it worked pretty well.
That's the exact reason why we invented our own mini stack and hooks into the network driver. After many failure cases, you can no longer rely on malloc, interrupts, routing tables or other goodies to be working correctly. It's too easy for the rest of the system to be broken enough that touching any of those pieces was enough to crash again.
It really depends on the scope of problem you're trying to debug, but at minimum I think you need to revert to polled networking, disable all interrupts, and use your own stack/memory pool. Even then it's still not foolproof, but at least then you spend less time trying to debug your debugger.
[-- Attachment #2 --]
0 *H
01 0 + 0 *H
/00Šq_Mtq40
*H
0{1 0 UGB10U Greater Manchester10U Salford10U
Comodo CA Limited1!0 U AAA Certificate Services0
040101000000Z
281231235959Z01 0 UUS1 0 UUT10USalt Lake City1 0 U
The USERTRUST Network1!0 U http://www.usertrust.com1604U-UTN-USERFirst-Client Authentication and Email0"0
*H
0
9}A;bF7`u9eJGHjM5BI/ |1Nd.)բdąQ5yNh{ zɤ2 O0 nFxoY^/m/묡j.g5y iF͠ v:z'[=s "HaLi.1 ,CZ qYں
gT:
we tbh ~GeMW(t40b0, '0#0 U #0
#>)00 U g}ĝ&p KPH|=n}0U 0U 00 U %0++0U
00U 0{U t0r08642http://crl.comodoca.com/AAACertificateServices.crl06420http://crl.comodo.net/AAACertificateServices.crl0 `HB0
*H
<~ v9<O ૄ]Te;m |7,%T_!7OT klE`-QLf<J?VvÂOl atG@We"'gOWdZٍ /i)J /LQFĊ7N 1hǞċ~2hD*Q`Mt:C29V:RAC3'9N&9≸])&A곛wuʵeJc>D^s 00mOj3""2zq0
*H
01 0 UUS1 0 UUT10USalt Lake City1 0 U
The USERTRUST Network1!0 U http://www.usertrust.com1604U-UTN-USERFirst-Client Authentication and Email0
110428000000Z
200530104838Z01 0 UGB10UGreater Manchester10USalford10U
COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CA0"0
*H
0
[KW^/@ȣSX_fe2N2}UxLUB'qi2@'Vbqi c^`ʢAj HmeC*.+c8w߱ڂ2jgo \5Tq
7
PSl Y1 LR@[HhJ$ :q_㬿;%qh=XF<hmz!W42~JRrd&N`ohQcB}"cөΞD\[5 K0G0 U #0g}ĝ&p KPH|=n}0 U zN t[xcd'/[y{0U 0U 0 0U
00U 0XU Q0O0MKIGhttp://crl.usertrust.com/UTN-USERFirst-ClientAuthenticationandEmail.crl0t+h0f0=+01http://crt.usertrust.com/UTNAddTrustClient_CA.crt0%+0http://ocsp.usertrust.com0
*H
־xWUm3DRB
JAIZҭsn>&|L0(B<%>
u=9fѡMo(l tZڱuz/y VtCr`9 G:eH<=%`I?C
3_н`j;:< I3B)93i.EMiڀ =]|Gm]W0KID~y83:]&XaU!ՙC@B0Ұun0,0 7Ca`)̀0
*H
01 0 UGB10UGreater Manchester10USalford10U
COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CA0
130616000000Z
140616235959Z0&1$0" *H
toasty@dragondata.com0"0
*H
0
-`ghX/9+ˈe`?l/ E^~T׀/q+5SzSrIuert`:"k_s{&
0T
kˢbW ieK;2 LX8w.YpI!3|M19 Y2vGrA ҽ5yX^0
@JbfBќ`
T ZO$mx1}LN0Rw 00 U #0zN t[xcd'/[y{0 U p =#P}L:wqX0U 0 U 0 0 U %0+ +10 `HB 0FU ?0=0; +10+0)+ https://secure.comodo.net/CPS0WU P0N0LJHFhttp://crl.comodoca.com/COMODOClientAuthenticationandSecureEmailCA.crl0+|0z0R+0Fhttp://crt.comodoca.com/COMODOClientAuthenticationandSecureEmailCA.crt0$+0http://ocsp.comodoca.com0 U 0toasty@dragondata.com0
*H
i qk4Dlse-8 uy:1:ߩ( w}tRƼHyT 4Y=GeKr:/ܜ1n*tښ6ڇڿ3D.~fm5Q(Yœ!@'=vn5i뷹 K^#MF0=~<h GgһKR}KrBai1cvqm3RNSeEx\G4
=FwɺL4rI U10001 0 UGB10UGreater Manchester10USalford10U
COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CA 7Ca`)̀0 + 0 *H
1 *H
0 *H
1
130711212032Z0# *H
1=٧P2䅈MC\{0 +71001 0 UGB10UGreater Manchester10USalford10U
COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CA 7Ca`)̀0 *H
101 0 UGB10UGreater Manchester10USalford10U
COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CA 7Ca`)̀0
*H
uC۟X!n+ktX(* `0n-Youk٥AY$t˲lƔӱoTf` saL%B 1ߍ&:1 ŜgJ߬^l+#; p73M?䝁bxX[L&
dإY CFNe #v<YDƬɴ+\W].ɒﮃ"J¾~2auX48
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D1D5C3A2-8220-4FF6-B86F-3249D566CE4E>