David Miller <[EMAIL PROTECTED]> writes:
> I think Alexey is saying that setting ->hard_header() creates an
> agreement between the device and IP that IP will make sure
> that dev->hard_header_len bytes are available in the header
> area.
I think I now understand it: hard_header_len is guaranteed
From: Krzysztof Halasa <[EMAIL PROTECTED]>
Date: Wed, 02 Aug 2006 02:42:05 +0200
> Alexey Kuznetsov <[EMAIL PROTECTED]> writes:
>
> > Actually, it is historical hole in design, inherited from ancient
> > times. Calling conventions of dev->hard_header() just did not allow
> > to reallocate. BTW in
Alexey Kuznetsov <[EMAIL PROTECTED]> writes:
> Actually, it is historical hole in design, inherited from ancient
> times. Calling conventions of dev->hard_header() just did not allow
> to reallocate. BTW in 2.6 it can, if it uses pskb_expand_head().
Does that mean that hard_header() and then hard
From: Krzysztof Halasa <[EMAIL PROTECTED]>
Date: Wed, 02 Aug 2006 02:24:43 +0200
> Do you mean IP calls hard_header() which, in turn, does skb_push()?
>
> How about Ethernet - is it safe? There is hard_header() which blindly
> adds 14 bytes.
I think Alexey is saying that setting ->hard_header()
Hi,
Alexey Kuznetsov <[EMAIL PROTECTED]> writes:
> As I already said there is nothing wrong with the first chunk.
> Except that it hides the real problem.
The problem is already very well hidden :-) I have seen just two
reports of this problem since 1994, and I believe both of them
were related
Hello!
> Do the semantics (I'm not talking about bugs) allow skb passed
> to dev->hard_header() (if defined)
No. dev->hard_header() should get enough of space, which is
dev->hard_header_len.
Actually, it is historical hole in design, inherited from ancient
times. Calling conventions of dev->hard
Hello!
> > Alexey, any suggestions on how to handle this kind of thing?
Device, which adds something at head must check for space.
Anyone, who adds something at head, must check.
Otherwise, it will remain buggy forever.
> What's wrong with my patch?
As I already said there is nothing wrong wit
David Miller <[EMAIL PROTECTED]> writes:
>> hdlc_fr: logical PVC devices have no headers (plain IPv4 etc. as seen
>> by tcpdump), but they append FR headers (4 or 10 bytes long) just
>> before passing the skb to physical device.
>
> If you hooked up fr_hard_header into dev->hard_header instead of
From: Krzysztof Halasa <[EMAIL PROTECTED]>
Date: Tue, 01 Aug 2006 03:04:28 +0200
> hdlc_fr: logical PVC devices have no headers (plain IPv4 etc. as seen
> by tcpdump), but they append FR headers (4 or 10 bytes long) just
> before passing the skb to physical device.
If you hooked up fr_hard_header
David Miller <[EMAIL PROTECTED]> writes:
> Krzysztof, which device driver exactly creates this problem
> in the first place?
I have a report (not sure but I think it's that) with hdlc_fr (Frame
Relay).
Grepping through the tree there might be problems with:
- net/8021q/vlan.c (probably not with
From: Krzysztof Halasa <[EMAIL PROTECTED]>
Date: Mon, 31 Jul 2006 22:04:33 +0200
> This is non-trivial because hard_header and hard_start_xmit
> functions currently can't return new skb address (hard_header()
> can't use skb_realloc_headroom() at all, xmit() can't use it if
> there is a need to re
From: Krzysztof Halasa <[EMAIL PROTECTED]>
Date: Mon, 31 Jul 2006 22:04:33 +0200
> Alexey Kuznetsov <[EMAIL PROTECTED]> writes:
>
> > All the rest of places just check, that there is enough space
> > for their immediate needs. If dev->hard_header() is NULL, it means that
> > stack does not need a
Hello!
> It does seem weird that IP output won't pay attention to
Not so weird, actually.
The logic was:
Only initial skb allocation tries to reserve all the space
to avoid copies in the future.
All the rest of places just check, that there is enough space
for their immediate needs. If dev->ha
From: Krzysztof Halasa <[EMAIL PROTECTED]>
Date: Sun, 30 Jul 2006 18:40:04 +0200
> Do the semantics (I'm not talking about bugs) allow skb passed
> to dev->hard_header() (if defined) and then to dev->hard_start_xmit()
> to have less link layer header space than dev->hard_header_len?
>
> I.e., is
Hello Alexey,
Can you clarify this for me, please?
Do the semantics (I'm not talking about bugs) allow skb passed
to dev->hard_header() (if defined) and then to dev->hard_start_xmit()
to have less link layer header space than dev->hard_header_len?
I.e., is dev->hard_header_len only advisory?
--
Krzysztof Halasa <[EMAIL PROTECTED]> writes:
> Are you sure about that? It would mean almost devices, including
^^
> Ethernet, are at risk:
"almost all devices", of course.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "un
Alexey Kuznetsov <[EMAIL PROTECTED]> writes:
> ip_output() worries about the space, which it needs.
Well, I wrote ip_output() to give idea about the place but the
actual function, as shown in the patch, is ip_finish_output2().
It currently reads:
int hh_len = LL_RESERVED_SPACE(dev);
Hello!
> ip_output() ignores dev->hard_header_len
ip_output() worries about the space, which it needs.
If some place needs more, it is its problem to check.
To the moment where it is used, hard_header_len can even change.
It can be applied, but it does not change the fact, that those
placed whi
18 matches
Mail list logo
