NKE: sflt_detach and sflt_unregister - panics...
NKE: sflt_detach and sflt_unregister - panics...
- Subject: NKE: sflt_detach and sflt_unregister - panics...
- From: Antoine Missout <email@hidden>
- Date: Mon, 8 Nov 2010 14:16:07 -0500
Hello,
We are using the NKE interface to register filters (sflt_register - too bad we can't register once for many domain/type/protocol).
When our driver is kextunloaded (user uninstalls or upgrades), we call sflt_unregister.
Unfortunately, this does not detach our filters, preventing us from unloading our driver immediately.
So we keep a list of all attached sockets (list is updated when sf_attach or sf_detach is called).
The stop method goes like this:
- sflt_unregister all our filters
- call sflt_detach on all sockets in our list of attached sockets
- sleep until sf_unregistered has been called for all our filters
This works great 99% of the time.
Except when sflt_detach panics. Not because the pointer is invalid, but because the socket is in the process of being closed.
More exactly:
panic(cpu 2 caller 0x3553c4): "tcp_lock: so=0xc0ad878 NO PCB! lr=0x4c3f8b lrh= 357342:3573b2 2:351d62 35747e:357547 4c44f6:4ad682 \n"@/SourceCache/xnu/xnu-1504.7.4/bsd/netinet/tcp_subr.c:2118
Backtrace (CPU 2), Frame : Return Address (4 potential args on stack)
0x925bb848 : 0x21b455 (0x5cf328 0x925bb87c 0x2238b1 0x0)
0x925bb898 : 0x3553c4 (0x5a6734 0xc0ad878 0x4c3f8b 0x879860)
0x925bb8c8 : 0x4ab120 (0xc0ad878 0x1 0x4c3f8b 0x4fdc95)
0x925bb8e8 : 0x4c3f8b (0xc0ad878 0x1 0x4c3cde 0x8dab8c0)
$ atos -arch i386 -o /mach_kernel 0x4c3f8b 0x4ab120 0x3553c4 0x21b455
sflt_detach (in mach_kernel) + 45
socket_lock (in mach_kernel) + 44
tcp_lock (in mach_kernel) + 77
panic (in mach_kernel) + 445
tcp_lock panics because so_pcb has been cleared, but sf_detach has not yet been called in our filter.
So how can we work around this ?
sf_detach is called pretty late in the socket lifecycle, maybe it would be more safe to remove sockets from our list as soon as sock_evt_closing is sent (since it seems they'll inevitably be detached anyway) ?
Thanks,
Antoine
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden