Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp836859pxa; Wed, 12 Aug 2020 14:44:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw2Dr8O4msUO6gJUEH7XLTDhSlCScDXYCxWOS5D5oj7zHCwblnWE1LyoYO5wPJ2o616SXHn X-Received: by 2002:a05:6402:1587:: with SMTP id c7mr1909347edv.213.1597268669232; Wed, 12 Aug 2020 14:44:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597268669; cv=none; d=google.com; s=arc-20160816; b=j3ZBRMp13uzF+hk/6z9BLK2487uRmm//j4UC3mI1BPg1av7Fl9QsFMbxLYmiPLoe5/ l2oj/eyGImF7TdwD2oeIa6fpLmwUfh4kC8XxQUNzyrQMqgozYEQmyJiDhjfWwjfv29I0 w6vUjGQOGu65s7O6gwlfDrkt/EyjuHRaGXzn1N7pTsyMufb5qm1xHmXdiqPcot83g3Vj HoVWhB5PYGFgU1qODNa6Z5xoABCXdpZcKz9E3cWheUWVbQXEMV7RxssAnOX4av55Tu8r u4CJ7sMeeCtYPGbyYrvyLQwi9zzQOegf56xJBwhbSuclDhqDT6uEV9xX/4rNKVKlmgQv sdyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=wHvShR0jg16/HmK/V4N01J5lPerETXbF2tid6sMGzZs=; b=ojbCz81jbge7CHCJrts0w86oLU80PspcGq5x+/SfbThEGqT/SGf+U6E1tqVVfRaZ7F iWuRkq8whfW0c/6KhRvY8JfI0Y03TWNXHyvhC/LCBKtuJa6COztM4Vc4828J+ILUVV96 VqP57AjTwTW/k1BNMFZA1BZivdHtnsGhY3a+LI47WmqGuCwjkf4RrdOPvDQEuQPt1LUw TsEy4OC9YGb6loKYvO9hCrohm41N9deFbb3lo4QUGtDiZGSXr6keovbRiuqS3cVwYBxS KojWGTaj4c5xJZkV+YP3qNoLfxQ2h3kMkyrlp8kUy2iE6Exaq3wtnpS3lEtHI1qrM9vd S1+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v10si1999010ejg.203.2020.08.12.14.44.06; Wed, 12 Aug 2020 14:44:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726557AbgHLVnf (ORCPT + 99 others); Wed, 12 Aug 2020 17:43:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56754 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726508AbgHLVnf (ORCPT ); Wed, 12 Aug 2020 17:43:35 -0400 Received: from shards.monkeyblade.net (shards.monkeyblade.net [IPv6:2620:137:e000::1:9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47041C061383; Wed, 12 Aug 2020 14:43:35 -0700 (PDT) Received: from localhost (50-47-102-2.evrt.wa.frontiernet.net [50.47.102.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 15F2012A18E8C; Wed, 12 Aug 2020 14:26:48 -0700 (PDT) Date: Wed, 12 Aug 2020 14:43:32 -0700 (PDT) Message-Id: <20200812.144332.2288214156822456254.davem@davemloft.net> To: mathieu.desnoyers@efficios.com Cc: dsahern@kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH 2/3] ipv4/icmp: l3mdev: Perform icmp error route lookup on source device routing table From: David Miller In-Reply-To: <20200811195003.1812-3-mathieu.desnoyers@efficios.com> References: <20200811195003.1812-1-mathieu.desnoyers@efficios.com> <20200811195003.1812-3-mathieu.desnoyers@efficios.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Wed, 12 Aug 2020 14:26:48 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mathieu Desnoyers Date: Tue, 11 Aug 2020 15:50:02 -0400 > @@ -465,6 +465,7 @@ static struct rtable *icmp_route_lookup(struct net *net, > int type, int code, > struct icmp_bxm *param) > { > + struct net_device *route_lookup_dev = NULL; > struct rtable *rt, *rt2; > struct flowi4 fl4_dec; > int err; > @@ -479,7 +480,17 @@ static struct rtable *icmp_route_lookup(struct net *net, > fl4->flowi4_proto = IPPROTO_ICMP; > fl4->fl4_icmp_type = type; > fl4->fl4_icmp_code = code; > - fl4->flowi4_oif = l3mdev_master_ifindex(skb_dst(skb_in)->dev); > + /* > + * The device used for looking up which routing table to use is > + * preferably the source whenever it is set, which should ensure > + * the icmp error can be sent to the source host, else fallback > + * on the destination device. > + */ > + if (skb_in->dev) > + route_lookup_dev = skb_in->dev; > + else if (skb_dst(skb_in)) > + route_lookup_dev = skb_dst(skb_in)->dev; > + fl4->flowi4_oif = l3mdev_master_ifindex(route_lookup_dev); The caller of icmp_route_lookup() uses the opposite prioritization of devices for determining the network namespace to use: if (rt->dst.dev) net = dev_net(rt->dst.dev); else if (skb_in->dev) net = dev_net(skb_in->dev); else goto out; Do we have to reverse the ordering there too? And when I read fallback in your commit message description, I imagined that you would have a two tiered lookup scheme. First you would be trying the skb_in->dev for a lookup (to accomodate the VRF case), and if that failed you'd try again with skb_dst()->dev.