From patchwork Tue Nov 23 14:03:45 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Timo Teras X-Patchwork-Id: 72668 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 12944B70DE for ; Wed, 24 Nov 2010 01:03:54 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753029Ab0KWODt (ORCPT ); Tue, 23 Nov 2010 09:03:49 -0500 Received: from mail-ew0-f46.google.com ([209.85.215.46]:33450 "EHLO mail-ew0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751061Ab0KWODs (ORCPT ); Tue, 23 Nov 2010 09:03:48 -0500 Received: by ewy5 with SMTP id 5so2435191ewy.19 for ; Tue, 23 Nov 2010 06:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=bhc6zohrnvb9mLQ0M9GGP8NB+J4qI/TJQPa0mhSN0PU=; b=RSbsy9cfObGDpmdNtDDyUbZ6lSLHvJsX03E2eWD/BSKrLbfmkuVCbb3lnuWWXfk7BD 6dz+H+smXnmNGfcMdDZvMwAVTIkJKMRazWn70ZdBRglw3N8c5ixcSR4hzT7Mcz8jjrZ5 Nt23hXRnUsaqk/MTu7ErfUm3FFUUZHKRIjWSM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=kFwxhUP3gSbzUjaYFtwmkmruGX8SDa4TJ9IiSCZWl7Vco+RIx+mkKlh/pvMKteYWyq nmvA3BcRj51V46wASAkM9fU30Y/DJRp47RqBoAVGhZ21YvJaNGnNoqssNtM4bA6nb0VY z6/eb7NgkAFeefFU7Pwo6yyItRU7d5ebR2RkA= Received: by 10.14.48.10 with SMTP id u10mr1756358eeb.39.1290521027244; Tue, 23 Nov 2010 06:03:47 -0800 (PST) Received: from [10.26.34.2] (mail.fi.jw.org [83.145.235.193]) by mx.google.com with ESMTPS id w20sm5836116eeh.18.2010.11.23.06.03.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Nov 2010 06:03:46 -0800 (PST) Message-ID: <4CEBC9C1.8080101@iki.fi> Date: Tue, 23 Nov 2010 16:03:45 +0200 From: =?ISO-8859-1?Q?Timo_Ter=E4s?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: David Miller CC: netdev@vger.kernel.org, herbert@gondor.apana.org.au Subject: Re: [PATCH] xfrm: use gre key as flow upper protocol info References: <1288795298-323-1-git-send-email-timo.teras@iki.fi> <20101115.104322.212675424.davem@davemloft.net> In-Reply-To: <20101115.104322.212675424.davem@davemloft.net> X-Enigmail-Version: 1.1.2 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 11/15/2010 08:43 PM, David Miller wrote: > From: Timo Teräs > Date: Wed, 3 Nov 2010 16:41:38 +0200 > >> The GRE Key field is intended to be used for identifying an individual >> traffic flow within a tunnel. It is useful to be able to have XFRM >> policy selector matches to have different policies for different >> GRE tunnels. >> >> Signed-off-by: Timo Teräs > > I'll apply this to net-next-2.6, thanks. Hmm.. I tested this with using the "ip xfrm" sport and dport manually (without doing the actual userland support for this), and checking it in kernel with printk's in various places that the stuff matches. In these tests I checked the sport/dport by hand and apparently messed up the byte order. Now that I'm writing the GRE support for "ip xfrm" I think that missed two htons() calls. I was confused if xfrm_flowi_{s|d}port was supposed to return host or net byte order for non-TCP/UDP packets. I was under the assumption that host byte order since case IPPROTO_ICMP swaps the byte order. But it would appear that the fl->fl_icmp_* is actually host order and it's turned to network order; this is also implied by using htons instead of ntohs. Since I decided to keep fl_gre_key in network order, the return value would now be inconsistent, and make userland abi endianess dependent. I'll follow up with iproute2 patch soon. So we probably would need to do: xfrm: fix gre key endianess fl->fl_gre_key is network byte order contrary to fl->fl_icmp_*. Make xfrm_flowi_{s|d}port return network byte order values for gre key too. Signed-off-by: Timo Teräs --- 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 diff --git a/include/net/xfrm.h b/include/net/xfrm.h index 1a57ff9..916ac47 100644 --- a/include/net/xfrm.h +++ b/include/net/xfrm.h @@ -806,7 +806,7 @@ __be16 xfrm_flowi_sport(struct flowi *fl) port = htons(fl->fl_mh_type); break; case IPPROTO_GRE: - port = htonl(fl->fl_gre_key) >> 16; + port = htons(ntohl(fl->fl_gre_key) >> 16); break; default: port = 0; /*XXX*/ @@ -830,7 +830,7 @@ __be16 xfrm_flowi_dport(struct flowi *fl) port = htons(fl->fl_icmp_code); break; case IPPROTO_GRE: - port = htonl(fl->fl_gre_key) & 0xffff; + port = htons(ntohl(fl->fl_gre_key) & 0xffff); break; default: port = 0; /*XXX*/