Hi,

Alexey Kuznetsov [off-list ref] 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