Re: 2.2.13 ISDN funnies

Karsten Keil (kkeil@suse.de)
Thu, 28 Oct 1999 03:17:38 +0200

On Thu, Oct 28, 1999 at 12:37:09AM +0200, Henner Eisen wrote:
>
> Karsten Keil <kkeil@suse.de> writes:
>
> >Again, no headroom isn't a error, only a bad thing, which cost a extra
> >copy of the frame to have enought place for the header.
>
> I'd really consider this to be an error. The net device posts its
> requirement for the link layer's skb headspace in the dev->hard_header_len
> field. If the network layer passed an skb to the device (dev->hard_header())
> with insufficient headroom < dev->hard_header, this would be a bug in the
> network layer. (BTW, the network layers already reallocates headroom if
> necessary. Thus, it should never be necessary inside the driver).

Yes of course, what I like to say was:
No headroom isn't a bug which drop the connection or make it unstable, since
we have the workaround.

BTW: What about routing, where the needed headroom is realloced ?
What I mean:
e.g. a eth0 and a syncppp interface.
A packet comes from the ethernet, the ethernet devices allocates the skb for
it (I think with no additional headroom, because it don't know about the
destination of this packet) then it is send to the network stack, which
send it to the syncppp device.
Which function allocates skb with the right headroom ?

>
> If dev->hard_header_len were set too small compared to the real
> requirements of the driver, this would be a bug in the driver. There is
> a possible bug which could cause this in theory, but this could only be
> triggered if two different HL drivers were used but the one with the larger
> headspace requirements was insmod'ed after the network interface was
> registered. No reasonnable setup scripts would do so anyway and the error
> reports received until now only use one driver insmod'ed before
> the interface is registered. Thus, this potential driver bug is certaninly
> not responsible for the error reports.
>

dev->hard_header_len
I looked trough the code and don't find a place, where ppp increase the
dev->hard_header_len for its need, but maybe the ETH_HLEN (14) is allways
bigger as the ppp headers ?

Only in isdn_net.c dev->hard_header_len is calculated:

dev->hard_header_len = ETH_HLEN + max_hlhdr_len;

max_hlhdr_len is the max from all hardware drivers (for HiSax 4, but this is
only used with X.75, with other low layer protocols here is no additional
header.)

> I really doubt that the problem is caused inside the linux network layers.
> Otherwise, the same bug would trigger skb_uflow panics with any
> net_device driver.
>

I heared similar problems with ppp over ethernet and normal ppp.

Karsten

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