Maxime Villard <max%M00nBSD.net@localhost> writes:
> Doesn't seem correct to me, pfil_run_hooks can return zero but still
> free the mbuf.
When can it do that? I first thought address translation, but that
seems to be done /in situ/. Still, your suggested modification looks
right, in that the documentation says:
The filter returns an errno if the packet processing is to stop, or
0 if the processing is to continue. If the packet processing is to
stop, it is the responsibility of the filter to free the packet.
and pfil_run_hooks() is obviously prepared for a filter to return 0 and
free the mbuf. The first non-zero return value is then immediately
returned from pfil_run_hooks(), or zero if no filter returns non-zero.
> I think it should rather be:
>
> + if ((error = pfil_run_hooks(ifp->if_pfil, &m0, ifp, PFIL_OUT)) != 0)
> + goto out;
> + if (m0 == NULL)
> + goto out;
I adapted the pfil_run_hooks() calls from those in if_vlan.c, so they'll
need fixing, too. In fact, glancing at the calls to pfil_run_hooks() in
various places, they're not consistent (although they mostly agree with
what you're saying, including checking for a freed mbuf even when the
call returns 0). Also, tun_output() always returns 0, throwing away the
error codes that various parts of it carefully supply. I'll read more
carefully, and prepare a proposal that cleans up the inconsistencies.
-tih
--
Most people who graduate with CS degrees don't understand the significance
of Lisp. Lisp is the most important idea in computer science. --Alan Kay
Attachment:
signature.asc
Description: PGP signature