Date: Wed, 26 Apr 2000 02:11:06 -0700 From: David Greenman <dg@root.com> To: "Louis A. Mamakos" <louie@TransSys.COM> Cc: Archie Cobbs <archie@whistle.com>, luigi@FreeBSD.ORG, remy@boostworks.com, csg@waterspout.com, pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <200004260911.CAA14088@implode.root.com> In-Reply-To: Your message of "Tue, 25 Apr 2000 22:11:28 EDT." <200004260211.WAA61401@whizzo.transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>Just a thought while looking at this code - in if_ethersubr.c where
>the bpf process has been moved, the same idiom is repeated that
>was in the drivers:
>
> /* Check for a BPF tap */
> if (ifp->if_bpf != NULL) {
> struct mbuf m0;
>
> /* OK because BPF treats the mbuf as read-only */
> m0.m_next = m;
> m0.m_data = (char *)eh;
> m0.m_len = ETHER_HDR_LEN;
> bpf_mtap(ifp, &m0);
> }
>
>Now that mbufs are 256 bytes long, is this getting to be too much data
>to stick on the kernel stack? It seems like it's not a problem now, but
>this code is now going to be invoked deeper in the stack than before.
Pretty disgusting code. The mbuf isn't even initialized fully, leaving it
in a state with a bunch of garbage pointers and other cruft. It's amazing
that it even works. This must be something new that someone added - I don't
recall seeing this before.
This could/should be done using a struct bpf_pkthdr (or something) that
has an mbuf pointer, a protocol header pointer, and header length. It could
also be done by just adding a few more arguments to bpf_mtap(). Abusing
an mbuf for this is wrong no matter how you slice it.
>If this code is running at splnet(), then it ought to be safe to just
>have a static mbuf laying about for this purpose, rather than allocating
>a local on the kernel stack.
Not a good thing for SMP.
-DG
David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com
Pave the road of life with opportunities.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004260911.CAA14088>