On Tue, Jul 21, 2015 at 12:38 PM, Martin Blumenstingl <martin.blumensti...@googlemail.com> wrote: > Hi Willem, > > On Tue, Jul 21, 2015 at 6:28 PM, Willem de Bruijn <will...@google.com> wrote: >> 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. > >> 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. >> 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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
