From mboxrd@z Thu Jan 1 00:00:00 1970 From: Willem de Bruijn Subject: Re: [PATCH] packet: Allow packets with only a header (but no payload) Date: Tue, 21 Jul 2015 12:51:04 -0400 Message-ID: References: <1437495247-471-1-git-send-email-martin.blumenstingl@googlemail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Network Development , Eric Dumazet , Daniel Borkmann , David Miller , johann.baudy@gnu-log.net To: Martin Blumenstingl Return-path: Received: from mail-yk0-f172.google.com ([209.85.160.172]:34346 "EHLO mail-yk0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751503AbbGUQvf (ORCPT ); Tue, 21 Jul 2015 12:51:35 -0400 Received: by ykax123 with SMTP id x123so171161969yka.1 for ; Tue, 21 Jul 2015 09:51:34 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Tue, Jul 21, 2015 at 12:38 PM, Martin Blumenstingl wrote: > Hi Willem, > > On Tue, Jul 21, 2015 at 6:28 PM, Willem de Bruijn 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