site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=GwHOSrEeoAYtBxIjTNOnR1+nPZ8ubifNxmfuYc67yZ29tsNsdI5MQb9llHFcZo3Ra30kBYbMQMUC+IhHP/6122HW2/jxHMXyxbvMezjn63zE7K2JDQY3BAh4htLqNLTQ1T8LyWFRZaQoBLDbRo0HjNbo4WUWGnxwQd+z5JiWHew= I'm working on an ipfilter NKE that needs to defer processing on certain TCP connections. Basically the NKE sends selected data up to a userland daemon that inspects the data on the connection and optionally invokes a user interface to prompt the user for how to handle the data. The packet is then released outbound and everything continues on as normal. I'm currently using msleep() in the ipfilter outbound callback function to delay, and waking up the channel when the daemon responds. This is all working great so far, but there's a problem when the daemon/UI process takes a long time to return (e.g. if the user takes a while to handle the prompts). It looks like when the sleep runs for a certain amount of time, the network stack deadlocks until the msleep() call times out. I've confirmed this by varying the sleep anywhere from 10 milliseconds to 30 seconds. Even when all I do is sleep in the output function (with literally no other processing) this can be reproduced. This happens whether I call msleep() once with a long timeout, or repeatedly with short timeouts. The symptoms are that when the sleep hits this threshold (which seems to vary depending on the volume of traffic on the system) no traffic reaches the network stack (including loopback traffic) and no traffic is sent over the wire until the sleep times out or is woken up. However, I've noticed that sleeping in and of itself doesn't appear create any problems - tests seem to have proven that traffic on another connection can still be passed even while the hook function is sleeping. Anyone have any ideas on how to keep the rest of the network stack from deadlocking like this? The Apple docs suggest that msleep() is safe within an NKE and do not clearly present any alternatives. Due to the purpose of the application, dropping the packet and reinjecting it (via returning EJUSTRETURN and using ipf_inject_output) is not a viable option at this point, so I'd really like to avoid rearchitecting the application (especially since the bulk of the application works flawlessly). - Frank _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com