On Tue, Jul 21, 2015 at 12:38 PM, Martin Blumenstingl
[off-list ref] wrote:

Hi Willem,

On Tue, Jul 21, 2015 at 6:28 PM, Willem de Bruijn [off-list ref] wrote:

quoted

Interesting. 9c7077622dd9 only extended the check from tpacket_snd to
packet_snd to make the two paths equivalent. The existing check had the
ominous statement

    /* net device doesn't like empty head */

OK, I guess it's best to find out what the purpose of this comment is.

quoted

so allowing a header-only packet while correct in your case may not be
safe in some edge cases (specific device drivers?).

I'm wondering how a good fix would look like (I can think of a few
things, like renaming hard_header_len to something min_packet_size)?
I am open for suggestions since I have zero knowledge about the inner
workings of the packet framework.

I don't see a simple way of verifying the safety of allowing packets
without data short of a code audit, which would be huge, especially
when taking device driver logic into account. Perhaps someone
remembers why that statement was added and what edge case(s)
it refers to. I'm afraid that I don't. It was added in 69e3c75f4d54. I
added the author to this thread.

quoted

This was also discussed previously

  http://www.spinics.net/lists/netdev/msg309677.html

In any case, I don't think that reverting the patch and restoring the old
inconsistent state is a fix.

I totally agree with you that it's a bad fix if this means that we
could break other drivers.
My primary goal was to fix PPPoE connections - I guess I should have
simply added "RFC" to the subject.


Regards,
Martin