lkml.org 
[lkml]   [2002]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC] bridge-nf -- map IPv4 hooks onto bridge hooks, vs 2.5.42
Date
On Monday 14 October 2002 20:01, David S. Miller wrote:
Hello,

These are probably stupid questions to you, but here it goes.

> These changes cannot go in:
>
> 1) There is no reason the 'okfn' you use cannot be the
> function doing the MAC header copy.
>
> This is how this is supposed to work.
>
> I explained in that long thread a few weeks ago how
> this copy may not be placed in the generic IP code.
> This is final, you must find a way to make this copy
> without touching ipv4/*.c

I've checked the skb->dst->hh field and it (or skb->dst itself) was NULL for
purely bridged packets. So we'd have to fill this in ourselves. Can the
bridge code go fill in a skb->dst and skb->dst->hh? Is this considered clean?

> 2) The netfilter changes need to be approved by the netfilter
> team.
>
> I suspect, like myself, they will barf at the phys{in,out}dev
> additions to sk_buff. We already have enough junk sitting
> in sk_buff making it larger than it needs to be.

I added a third member as well... It's needed too, in my opinion.
There could ofcourse be added a pointer to a struct containing these three
values (and a copied Ethernet header). Then we go from 3 to 1 extra member...
Anyway, it's not like Lennert and me like adding new members, but we need to
save those things somewhere...

> Perhaps you can hang this off the nf_conntrack pointer and
> specify a destructor.
>
> 3) The bridging layer changes need to be approved by Lennert.
> But I'd suggest working out #1 and #2 first.

So if I change
struct nf_conntrack {
atomic_t use;
void (*destroy)(struct nf_conntrack *);
};

into this:

struct nf_conntrack {
atomic_t use;
void (*destroy)(struct nf_conntrack *);
struct brnf_data *brnf;
};

I can keep the copy of the Ethernet header in the struct brnf_data too (then I
don't have to touch skbuff->dst).
The skbuff->nfct field can already be in use by an IP connection tracker (or
something), so I can't use my own destroy function.
So I'd have to go do something in
net/ipv4/netfilter/ip_conntrack_core.c::destroy_conntrack() and I don't know
that stuff.
I sure don't like this solution more than the current situation.

Anyway, mapping the IPv4 hooks onto the bridge hooks is in my opinion by
definition a hack. But a very useful hack. So if you want this in the kernel
you'll have to be forgiving. Or present a nice solution, because I and
probably Lennert really don't see a nice(r) solution.

So, the best solution I can think of is adding a skbuff->brnf pointer to a
struct brnf_data. This will get rid of the copy in ip_output.c. Is that
enough? This will uglify the ip_tables.c patch however.

--
cheers,
Bart

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:30    [W:0.164 / U:1.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site