[Top][All Lists]

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

[patch #6851] fix a bug in BPF

From: Thomas Schwinge
Subject: [patch #6851] fix a bug in BPF
Date: Wed, 29 Jul 2009 09:04:50 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv: Gecko/2009070811 Ubuntu/9.04 (jaunty) Firefox/3.0.12

Follow-up Comment #3, patch #6851 (project hurd):

> The packet delivered from gnumach should have the packet header. NPF
returns the packet_header and pfinet always assumes that the packet from
gnumach has the packet_header.

OK, I understand that, and it is fine, but is there a specific reason to send
package_header to user-space?  (That is,  if it's *not* required, then we
should perhaps change pfinet and net_filter to not handle it?)  If I
understand the code correctly, packets that go from pfinet to the kernel to be
sent out, *do not* contain the packet_header, but packets that go from the
kernel to pfinet *do* contain the packet_header.  Why this asymmetry?  Perhaps
I fail to understand what this packet_header is actually good for.  (All that
is unrelated to this bug report, of course, but while we're at it...)

> For your first question, the return value of net_do_filter is boolean,
i.e., it can only be passed or not passed, but bpf_do_filter returns the size
of the data that passes the filter.

OK, I see.  The code could be written in a way that this is more obvious... 
(15 years old code, I know.)

My question also was whether net_do_filter should be changed to not handle
the packet_header-part of the packet, as that is not related to the actual
packet data (as I understand it), and thus should not be involved in deciding
whether to allow or deny a given packet.  (That's also unrelated to this bug

Given the same instructions as in bug #20612, please install this patch. 
(And then we can think about the other issues I'm talking above.)


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]