July 2005 - Darwin-kernel - lists.apple.com

Re: Unloading a KEXT with Client still connected
by Peter Lovell 13 Jul '05

13 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jul 13, 2005, at 4:25 PM, Allan Hoeltje wrote: Is there some way I can handle this? Cheers.....Peter _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Thank you all for coping with my continuous stream of newbie questions, hopefully including this one: I have a client application that connects to my KEXT and I am currently testing the KEXT by using kextload and kextunload. I noticed the hard way that if I kextunload the KEXT while my client is running and connected I get the scary "gray curtain of death" - which I guess is the kernel panic everybody refers to. Eventually my KEXT will be put in the startup folder. If the user shuts down with the client still running and connected to the KEXT will I get a kernel panic? I have looked at the XNU source code (thank you Justin!) and thought maybe there was some way for a KEXT to force close all client connections but found none. -Allan Your kext can, and probably should, refuse to unload if there are connections open. Try to think of the kext as a servant and look at the close-down sequence from the other direction. Your kext should stay there until its client (the application, or whatever) closes, and then you can unload. Don't try to close anything from your kext, but instead get the application to close the connection, with a little "help" if necessary. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Unloading a KEXT with Client still connected
by Stephane Sudre 13 Jul '05

13 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On mercredi, juillet 13, 2005, at 10:25 PM, Allan Hoeltje wrote: Thank you all for coping with my continuous stream of newbie questions, hopefully including this one: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I have a client application that connects to my KEXT and I am currently testing the KEXT by using kextload and kextunload. I noticed the hard way that if I kextunload the KEXT while my client is running and connected I get the scary "gray curtain of death" - which I guess is the kernel panic everybody refers to. Eventually my KEXT will be put in the startup folder. If the user shuts down with the client still running and connected to the KEXT will I get a kernel panic? Can it be possible to rethink the issue and wonder if instead, you could not just prevent the kext from being unloaded when the client is connected? This email sent to site_archiver(a)lists.apple.com

1 0

Unloading a KEXT with Client still connected
by Allan Hoeltje 13 Jul '05

13 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Microsoft-Entourage/10.1.4.030702.0 Thank you all for coping with my continuous stream of newbie questions, hopefully including this one: I have a client application that connects to my KEXT and I am currently testing the KEXT by using kextload and kextunload. I noticed the hard way that if I kextunload the KEXT while my client is running and connected I get the scary "gray curtain of death" - which I guess is the kernel panic everybody refers to. Eventually my KEXT will be put in the startup folder. If the user shuts down with the client still running and connected to the KEXT will I get a kernel panic? I have looked at the XNU source code (thank you Justin!) and thought maybe there was some way for a KEXT to force close all client connections but found none. Is there some way I can handle this? -Allan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: ctl_enqueuedata ENOBUFS error
by Justin C. Walker 12 Jul '05

12 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com A clarification: On Jul 12, 2005, at 13:09 , Justin C. Walker wrote: Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for General Semantics -------- When LuteFisk is outlawed, Only outlaws will have LuteFisk -------- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Jul 12, 2005, at 12:28 , Allan Hoeltje wrote: [snip] I mean: ENOBUFS usually means no space of some kind - either no buffers or no space to put buffers in, depending. Since this is not a common problem for existing code, it seems likely that it is due to something you are doing, presumably incorrectly. To what existing code do you refer? Here, I meant all of the code in Mac OS X; it runs without a lot (in general, that's "no") of ENOBUFS problems as it comes from the factory, so most of the code that is running on a Mac OS X system does not see this problem. Again, that doesn't mean there are no bugs, but the wise programmer checks his own code first :-} This email sent to site_archiver(a)lists.apple.com

1 0

Re: ctl_enqueuedata ENOBUFS error
by Justin C. Walker 12 Jul '05

12 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jul 12, 2005, at 12:28 , Allan Hoeltje wrote: Jeez...wish I could cash that in ;-} I mean: ENOBUFS usually means no space of some kind - either no buffers or no space to put buffers in, depending. Since this is not a common problem for existing code, it seems likely that it is due to something you are doing, presumably incorrectly. You should be aware that the mbuf accounting rules take into account all the space in an mbuf, whether you use it or not (e.g., if you allocate an mbuf with cluster, put 1 byte in the cluster, and enqueue it, you are docked for the size of the mbuf (256 bytes) + size of cluster (2048 bytes). You may already know this but it's worth emphasizing. What do you do with the mbuf that is passed to you? Wasn't this a part of your license agreement? Cheers, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for General Semantics -------- It's not whether you win or lose... It's whether *I* win or lose. -------- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… "Justin C. Walker" <justin(a)mac.com> wrote on 7/12/05 11:57 AM: Justin, everything you have said so far I treat as pure gold. Thank you for all the time you have spent on my problem so far. To what existing code do you refer? I have Googled and Spotlighted for kern_ctl_reg, ctl_enqueuedata, mbuf_copydata, and only find the Apple docs that I have mentioned before. I see no sample code of any kind on the web. I'm referring to the Darwin kernel code. Have you checked Apple's Darwin site (<http://developer.apple.com/darwin>)? The kernel source is there, along with all other 'open source' components of Mac OS X. The kernel is in the 'xnu' project ("X is not unix"). You should download a copy and become familiar with it. This will show you how things are implemented. I am not, as far as my code goes, allocating any mbufs. I am accessing the data in the mbuf passed to me in my ipf_input_func but I do not free it nor allocate any other mbuf. The data I send via ctl_enqueuedata is _MALLOC'd and _FREE'd but it is not an mbuf. The fact remains that something is going wrong, and it's going wrong with the mbuf pool, in some way. The smart money would be on your code... This is a no-whining zone. Oh, now you tell me! :-) Yes that helps very much. Knowing that the only place to really learn this stuff is by looking directly at Darwin is the best piece of information I've gotten to date. The Apple docs should say that and then emphasize it in the section where they warn us about writing KEXTs. If there is some aspect that you believe can be improved, let Apple know (either as a bug/enhancement report, or directly to DTS). This list is not the way to let Apple know anything; it's a medium for developers to communicate with each other. This email sent to site_archiver(a)lists.apple.com

1 0

Re: ctl_enqueuedata ENOBUFS error
by Allan Hoeltje 12 Jul '05

12 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Microsoft-Entourage/10.1.4.030702.0 "Justin C. Walker" <justin(a)mac.com> wrote on 7/12/05 11:57 AM: > This is short, due to lack of time: Justin, everything you have said so far I treat as pure gold. Thank you for all the time you have spent on my problem so far. > I mean: ENOBUFS usually means no space of some kind - either no > buffers or no space to put buffers in, depending. Since this is not > a common problem for existing code, it seems likely that it is due to > something you are doing, presumably incorrectly. To what existing code do you refer? I have Googled and Spotlighted for kern_ctl_reg, ctl_enqueuedata, mbuf_copydata, and only find the Apple docs that I have mentioned before. I see no sample code of any kind on the web. > You should be aware that the mbuf accounting rules take into account > all the space in an mbuf, whether you use it or not (e.g., if you > allocate an mbuf with cluster, put 1 byte in the cluster, and enqueue > it, you are docked for the size of the mbuf (256 bytes) + size of > cluster (2048 bytes). You may already know this but it's worth > emphasizing. I am not, as far as my code goes, allocating any mbufs. I am accessing the data in the mbuf passed to me in my ipf_input_func but I do not free it nor allocate any other mbuf. The data I send via ctl_enqueuedata is _MALLOC'd and _FREE'd but it is not an mbuf. > This is a no-whining zone. Oh, now you tell me! :-) > When the going gets tough, the tough get > the kernel source and look at it to figure out what *might* be going > wrong... > ...There are no courses on > kernel internals, generally, and precious little documentation. You > need to dig into the source. > Hope this helps. Yes that helps very much. Knowing that the only place to really learn this stuff is by looking directly at Darwin is the best piece of information I've gotten to date. The Apple docs should say that and then emphasize it in the section where they warn us about writing KEXTs. Thanks! -Allan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: ctl_enqueuedata ENOBUFS error
by Justin C. Walker 12 Jul '05

12 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com This is short, due to lack of time: On Jul 12, 2005, at 11:35 , Allan Hoeltje wrote: Look for other possibilities as well: are you always freeing the mbufs you are using? Hope this helps. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for General Semantics -------- It's not whether you win or lose... It's whether *I* win or lose. -------- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I am not sure I know what you mean here. I mean: ENOBUFS usually means no space of some kind - either no buffers or no space to put buffers in, depending. Since this is not a common problem for existing code, it seems likely that it is due to something you are doing, presumably incorrectly. In my ipf_input_func (and duplicated in my ipf_output_func) I make a copy of the complete mbuf_t * data via mbuf_copydata into my own _MALLOC space. I then ctl_enqueuedata my copy and then _FREE the copy. I do not see any other mbuf_ or ctl_ methods that might come into play here. The kern_ctl_reg structure used to register a kernel control has a ctl_sendsize field that says 0 means the default size but does not say what that default is nor does it say what the size is: bytes, kBytes, ...? I want to enqueue a full IP packet so I need the ctl_sendsize to be at least 2048 bytes. You should be aware that the mbuf accounting rules take into account all the space in an mbuf, whether you use it or not (e.g., if you allocate an mbuf with cluster, put 1 byte in the cluster, and enqueue it, you are docked for the size of the mbuf (256 bytes) + size of cluster (2048 bytes). You may already know this but it's worth emphasizing. Are you sure that the queue is getting filled up? The description of ctl_enqueuedata in sys/kern_control.h says a return code of ENOBUFS means the "queue is full or there are no free mbufs". Since there isn't an mbuf associated with the ctl_enqueuedata method I can only assume that some queue somewhere is full. [snip] <whine> There is not enough documentation in this area. The "Network Kernel Extensions Programming Guide" and "Kernel Programming" docs warn about how careful one needs to be when programming in the kernel and then gives you just enough information to make you dangerous. Where does a mere mortal learn about writing proper KEXTs? </whine> This is a no-whining zone. When the going gets tough, the tough get the kernel source and look at it to figure out what *might* be going wrong. A quick (and incomplete) check of the source tells me that the routine in question will return ENOBUFS if the receive sockbuf of the socket associated with the kctlref does not have sufficient free space; or when it can't allocate an mbuf (which it will use to store the data you pass it). This is pretty straight-forward, and will help you understand the environment you are developing code for. There are no courses on kernel internals, generally, and precious little documentation. You need to dig into the source. Thanks for the netstat tip - I will do some more debugging and see if I can't narrow this thing down some more. This email sent to site_archiver(a)lists.apple.com

1 0

Re: ctl_enqueuedata ENOBUFS error
by Allan Hoeltje 12 Jul '05

12 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Microsoft-Entourage/10.1.4.030702.0 > Look for other possibilities as well: are you always freeing the > mbufs you are using? I am not sure I know what you mean here. In my ipf_input_func (and duplicated in my ipf_output_func) I make a copy of the complete mbuf_t * data via mbuf_copydata into my own _MALLOC space. I then ctl_enqueuedata my copy and then _FREE the copy. I do not see any other mbuf_ or ctl_ methods that might come into play here. The kern_ctl_reg structure used to register a kernel control has a ctl_sendsize field that says 0 means the default size but does not say what that default is nor does it say what the size is: bytes, kBytes, ...? I want to enqueue a full IP packet so I need the ctl_sendsize to be at least 2048 bytes. > Are you sure that the queue is getting filled up? The description of ctl_enqueuedata in sys/kern_control.h says a return code of ENOBUFS means the "queue is full or there are no free mbufs". Since there isn't an mbuf associated with the ctl_enqueuedata method I can only assume that some queue somewhere is full. There is no documentation that I know of that describes this queue or how one would free it from the KEXT and, of course, I also assume that the client application does not have access to mbufs or ctl queues or anything else in the kernel space except for what it gets from the socket via recv. It just seemed logical to me to assume that recv pulled data off the queue - especially since there is a MSG_PEEK flag for recv that implies one can look at incoming messages without removing any data. At least this is what W. R. Stevens says in UNIX Network Programming. <whine> There is not enough documentation in this area. The "Network Kernel Extensions Programming Guide" and "Kernel Programming" docs warn about how careful one needs to be when programming in the kernel and then gives you just enough information to make you dangerous. Where does a mere mortal learn about writing proper KEXTs? </whine> Thanks for the netstat tip - I will do some more debugging and see if I can't narrow this thing down some more. -Allan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: ctl_enqueuedata ENOBUFS error
by Stephane Sudre 12 Jul '05

12 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 12 juil. 05, at 1:53, Allan Hoeltje wrote: When you get this result you may want to: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I am using ctl_enqueuedata() in my KEXT to send data to a client application. The client is reading the socket with recv( s, buff, BUFFER_LENGTH, MSG_WAITALL ). Everything seems to work fine but the ctl_enqueuedata() call in my KEXT eventually returns "ENOBUFS - The queue is full or there are no free mbufs." So, it appears that recv() does not remove data from the queue. What do I need to do so that ctl_enqueuedata() does not fill the queue? I do not see any other function calls in sys/kern_control.h that look appropriate. At which rate are you sending data and what is the usual size of this data? - increase the recv or send "buffer" size (use the socket API because IIRC there's a bug in the ctl API in 10.4). - save the data and try to send it later. This is what the old tcp log sample code was doing. This email sent to site_archiver(a)lists.apple.com

1 0

Re: ctl_enqueuedata ENOBUFS error
by Justin C. Walker 12 Jul '05

12 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jul 11, 2005, at 16:53 , Allan Hoeltje wrote: You can use 'netstat' to get a handle on this: $ netstat -m 89 mbufs in use: 85 mbufs allocated to data 3 mbufs allocated to socket names and addresses 1 mbufs allocated to Appletalk data blocks 120/286 mbuf clusters in use 0/16 mbuf 4KB clusters in use 658 Kbytes allocated to network (39% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Cheers, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for General Semantics -------- Some people have a mental horizon of radius zero, and call it their point of view. -- David Hilbert -------- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I am using ctl_enqueuedata() in my KEXT to send data to a client application. The client is reading the socket with recv( s, buff, BUFFER_LENGTH, MSG_WAITALL ). Everything seems to work fine but the ctl_enqueuedata() call in my KEXT eventually returns "ENOBUFS - The queue is full or there are no free mbufs." So, it appears that recv() does not remove data from the queue. What do I need to do so that ctl_enqueuedata() does not fill the queue? I do not see any other function calls in sys/kern_control.h that look appropriate. Look for other possibilities as well: are you always freeing the mbufs you are using? Are you sure that the queue is getting filled up? This lets you track what your mbuf usage looks like. If you see the 'in use' count rising, it's possible that you aren't freeing them properly. $ netstat -t Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 192.168.2.7.49396 mail.mac.com.imaps ESTABLISHED .... If the receiver is not taking data off the queue, you will see his receive queue increasing (this shows you the byte count currently on the queue); likewise, if a send queue is climbing, or is non-zero and unchanging, there is likely something wrong there. Associating what's printed here with what's going on in the kernel is not straight-forward, but it's doable. Note that it is very unlikely that recv() is screwing things up; this routine is very heavily used, and I think we would have seen a problem before now, if there was one. That's not a guarantee, of course, but that's the way to bet. You are probably using the correct calls (if Josh is around, he may have a comment); now's when the tough get debugging. Consider syslogs and 2-machine debugging. It's good for your heart and arteries; and it tastes great too. :-} PS: there seems to be a bug in 'netstat'; using '-A' does not show the socket structure address for tcp4 sockets. rdar://4176992. Works on 10.3. This email sent to site_archiver(a)lists.apple.com

1 0