From patchwork Tue Aug 12 19:05:23 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Borkmann X-Patchwork-Id: 379454 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3F24A1400B7 for ; Wed, 13 Aug 2014 05:05:36 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754684AbaHLTFb (ORCPT ); Tue, 12 Aug 2014 15:05:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36282 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753925AbaHLTFa (ORCPT ); Tue, 12 Aug 2014 15:05:30 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7CJ5Qmx013860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Aug 2014 15:05:26 -0400 Received: from [10.36.4.150] (vpn1-4-150.ams2.redhat.com [10.36.4.150]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7CJ5NTd011521 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 12 Aug 2014 15:05:26 -0400 Message-ID: <53EA6573.4060204@redhat.com> Date: Tue, 12 Aug 2014 21:05:23 +0200 From: Daniel Borkmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Marcel Holtmann CC: Network Development Subject: Re: protocol 0000 is buggy, dev nlmon References: <8CB882A0-240B-4759-A119-8867FCF70957@holtmann.org> In-Reply-To: <8CB882A0-240B-4759-A119-8867FCF70957@holtmann.org> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 08/03/2014 08:05 PM, Marcel Holtmann wrote: ... > And on that note, I also found that we can not get the multicast group id from nlmon. > This is something we should include to be able to distinguish where netlink messages > are send to. Just to follow-up on this thread first for general discussion [ sorry was/am very busy recently ]. My suggestion was something like the following pseudocode: fit into struct tpacket_auxdata which is for non-mmap operational mode, however imho this would be an option to go for. The other options are (as suggested by you) are a split of the 4 byte into {tp_mac, tp_net} tuple + status flag, or a split into {tp_vlan_tci, tp_vlan_tpid} tuple plus status flag since both are also exported via tpacket_auxdata. The first variant is not possible as at least tp_mac contains the start offset although tp_net would be unused as it carries the same value as tp_mac; however, another issue with that could be that applications do not check status flags before accessing tp_{mac,net}, so I don't really like it. Also it makes it impossible for usage with BPF filters. The same goes for the tp_vlan_{tci,tpid} variant, it would not be possible to reliably use it with BPF filters attached as opposed to the hash version. Next, encoding this over tp_vlan_{tci,tpid} would require special casing in AF_PACKET since we fetch and fill 'em via vlan_tx_tag_get(skb) and ntohs(skb->vlan_proto). Yet another option would be to introduce something like struct tpacket_auxdata2 which carries more meta data with it, but that I'd really don't like -- AF_PACKET has already too many versions of mmap'ed API which is horrible. Therefore, I am still in favour of going with skb->hash as it's the cleanest. --- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- a/net/netlink/af_netlink.c +++ b/net/netlink/af_netlink.c @@ -212,10 +212,11 @@ static int __netlink_deliver_tap_skb(struct sk_buff *skb, [...] nskb->protocol = htons((u16) sk->sk_protocol); nskb->pkt_type = netlink_is_kernel(sk) ? PACKET_KERNEL : PACKET_USER; + nskb->sw_hash = 1; + nskb->hash = NETLINK_CB(nskb).dst_group; [...] The hash itself should currently be 0 actually as it's unused. The upside for this approach is that it can be used as is, e.g. in BPF socket filters, TPACKET_V3 exports it to user space already and we could add it to TPACKET_V2 meta data (as we currently have 4 byte padding left). The downside, it doesn't