Date: Tue, 21 Nov 2017 17:44:59 +0100 From: "Kristof Provost" <kristof@sigsegv.be> To: "Catalin Salgau" <csalgau@users.sourceforge.net> Cc: freebsd-net@freebsd.org Subject: Re: BPF packet pagesize limit Message-ID: <65E7BF88-EBEA-47DA-806B-5BFD6783F2B4@sigsegv.be> In-Reply-To: <e52b9a29-ccc3-af47-9fdb-4e856bda4e49@users.sourceforge.net> References: <966f384c-10b4-d018-efb1-68a7064c9521@users.sourceforge.net> <A2A39E3C-8A17-4C17-A52D-0EF72F809F99@sigsegv.be> <e52b9a29-ccc3-af47-9fdb-4e856bda4e49@users.sourceforge.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 Nov 2017, at 17:14, Catalin Salgau wrote:
> Actually m_getm2() will always produce a chain for a size larger than
> the page size, due to m_getjcl() being called with MJUMPAGESIZE every
> time a large buffer is requested. The function could probably be
> called
> with MJUM9BYTES in this case, but this should be dependant on backing
> interface configuration(?).
I’d be tempted to just always allocate MJUM9BYTES, but that’s
wasteful of memory.
I believe the most common use case for this code is the DHCP client,
where large packets are not a requirement.
There doesn’t seem to be an obvious way to allocate a contiguous mbuf,
other than allocating the memory yourself, and creating an M_EXT mbuf.
Some care must be taken to ensure the memory is correctly freed, but at
first glance that looks possible.
> On the other hand, as you pointed out, bpf_filter really needs a
> single
> mbuf, and so does the call to uiomove(). The filter call, as it
> stands,
> will overread due to being passed the larger len value, instead of the
> mbuf's len.
> As a note, to avoid the overruns and related panics, I'd suggest
> anyone
> else trying this replace the assertion with an explicit
> if (m->m_next != NULL) {
> error = EIO;
> goto bad;
> }
>
Yes, that would be better.
Regards,
Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?65E7BF88-EBEA-47DA-806B-5BFD6783F2B4>