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 to a device without hard_header() (i.e., it probably wouldn't show with the patch applied). I have never seen this problem personally, and I've been using FR for about 10 years (in 1-3 locations - though I think at first it did use hard_header()). How about the second part of the patch? I know the second part isn't related to kernel panic but don't you think hard_header_len should be treated uniformly across the tree (i.e., shouldn't depend on hard_header() being non-NULL)? If not, fine. > Do not get it wrong. dev->hard_header_len is _NEVER_ guaranteed. > The places, which allocate skb, take it as a hint to avoid reallocation. > But each place which stuffs something at head, still must check the space. > > The only difference between the situation with dev->hard_header, > is that when dev->hard_header != NULL, the header is added by IP itself. > That's why IP checks it. 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. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
