tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Adding packet filtering to tun interfaces

Maxime Villard <> 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.

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

Home | Main Index | Thread Index | Old Index