site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com User-agent: Thunderbird 1.5.0.4 (Windows/20060516) Anton Thanks, -josh On Jun 9, 2006, at 12:20 PM, Anton Kuzmin wrote: _______________________________________________ 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... Thanks, I'll file a report later today, and what about the second question, about the way it's designed to free the whole list if a single packet fails or gets filtered? Or is that also a design flaw and going to be changed in the next release? Also, is there any chance of fixing this in 10.4.7 update? We've got some pretty unhappy customers due to this and I couldn't find any straightforward workaround. Josh Graessley wrote: That is definitely a bug. Please file a bug report. It does look like this is fixed in the sources for the next major release (part of some re-factoring), but it doesn't look like there were any changes made for a software update fix. I've been trying to nail down a mysterious kernel panic that occurs when our KPI interface filter is enabled and stumbled across a possible reason for it: in dlil_output_list after a call to filt_output, a check for EJUSTRETURN leads to what seems to be an erroneous "continue", which skips to the next interface filter instead of bailing out. So basically any packet consumed by an interface filter still gets passed to if_output and freed, which leads to a nasty surprise for an unsuspecting filter still referencing the freed mbuf. Could someone do a sanity check on this and if it's indeed a bug, I'll file a radar. Also, I would be grateful if someone could explain why a failure to process a single packet from a list should cause freeing of the whole list. This email sent to site_archiver@lists.apple.com