Re: dlil_output_list and interface filters
Re: dlil_output_list and interface filters
- Subject: Re: dlil_output_list and interface filters
- From: Josh Graessley <email@hidden>
- Date: Fri, 9 Jun 2006 15:26:00 -0700
Hi Anton,
You should file bugs for all of the issues you came across.
I could respond and say that, from looking at the code, it looks like
the re-factoring fixes those bugs too but I don't know when it will
make it out. That's all speculation on my part with no official
documentation to track it. Bug reports act as that documentation
ensuring that stuff does get taken care of.
I can't comment on whether or not a specific fix will make it in to a
software update. There are things that make it more likely that a fix
will make it in to a software update. There must be a bug, preferably
filed by someone outside of Apple. Contacting DTS to escalate the bug
may also help.
-josh
On Jun 9, 2006, at 2:59 PM, Anton Kuzmin wrote:
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.
Anton
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.
Thanks,
-josh
On Jun 9, 2006, at 12:20 PM, Anton Kuzmin wrote:
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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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