<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/net/vrf.c, branch linux-5.12.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.12.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.12.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2021-07-14T14:59:57Z</updated>
<entry>
<title>vrf: do not push non-ND strict packets with a source LLA through packet taps again</title>
<updated>2021-07-14T14:59:57Z</updated>
<author>
<name>Antoine Tenart</name>
</author>
<published>2021-06-18T15:15:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c533c60a6257afcb571fd3e4032f8454358884b8'/>
<id>urn:sha1:c533c60a6257afcb571fd3e4032f8454358884b8</id>
<content type='text'>
[ Upstream commit 603113c514e95c3350598bc3cccbd03af7ea4ab2 ]

Non-ND strict packets with a source LLA go through the packet taps
again, while non-ND strict packets with other source addresses do not,
and we can see a clone of those packets on the vrf interface (we should
not). This is due to a series of changes:

Commit 6f12fa775530[1] made non-ND strict packets not being pushed again
in the packet taps. This changed with commit 205704c618af[2] for those
packets having a source LLA, as they need a lookup with the orig_iif.

The issue now is those packets do not skip the 'vrf_ip6_rcv' function to
the end (as the ones without a source LLA) and go through the check to
call packet taps again. This check was changed by commit 6f12fa775530[1]
and do not exclude non-strict packets anymore. Packets matching
'need_strict &amp;&amp; !is_ndisc &amp;&amp; is_ll_src' are now being sent through the
packet taps again. This can be seen by dumping packets on the vrf
interface.

Fix this by having the same code path for all non-ND strict packets and
selectively lookup with the orig_iif for those with a source LLA. This
has the effect to revert to the pre-205704c618af[2] condition, which
should also be easier to maintain.

[1] 6f12fa775530 ("vrf: mark skb for multicast or link-local as enslaved to VRF")
[2] 205704c618af ("vrf: packets with lladdr src needs dst at input with orig_iif when needs strict")

Fixes: 205704c618af ("vrf: packets with lladdr src needs dst at input with orig_iif when needs strict")
Cc: Stephen Suryaputra &lt;ssuryaextr@gmail.com&gt;
Reported-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: Antoine Tenart &lt;atenart@kernel.org&gt;
Reviewed-by: David Ahern &lt;dsahern@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>vrf: fix maximum MTU</title>
<updated>2021-06-23T12:43:55Z</updated>
<author>
<name>Nicolas Dichtel</name>
</author>
<published>2021-06-08T14:59:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2f032ebff9b1fca4e4888a8d50a98134e0c407f2'/>
<id>urn:sha1:2f032ebff9b1fca4e4888a8d50a98134e0c407f2</id>
<content type='text'>
[ Upstream commit 9bb392f62447d73cc7dd7562413a2cd9104c82f8 ]

My initial goal was to fix the default MTU, which is set to 65536, ie above
the maximum defined in the driver: 65535 (ETH_MAX_MTU).

In fact, it's seems more consistent, wrt min_mtu, to set the max_mtu to
IP6_MAX_MTU (65535 + sizeof(struct ipv6hdr)) and use it by default.

Let's also, for consistency, set the mtu in vrf_setup(). This function
calls ether_setup(), which set the mtu to 1500. Thus, the whole mtu config
is done in the same function.

Before the patch:
$ ip link add blue type vrf table 1234
$ ip link list blue
9: blue: &lt;NOARP,MASTER&gt; mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether fa:f5:27:70:24:2a brd ff:ff:ff:ff:ff:ff
$ ip link set dev blue mtu 65535
$ ip link set dev blue mtu 65536
Error: mtu greater than device maximum.

Fixes: 5055376a3b44 ("net: vrf: Fix ping failed when vrf mtu is set to 0")
CC: Miaohe Lin &lt;linmiaohe@huawei.com&gt;
Signed-off-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Reviewed-by: David Ahern &lt;dsahern@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>vrf: fix a comment about loopback device</title>
<updated>2021-04-14T20:13:53Z</updated>
<author>
<name>Nicolas Dichtel</name>
</author>
<published>2021-04-14T10:03:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2e1534f395e73152e2051332034bff61a56a8368'/>
<id>urn:sha1:2e1534f395e73152e2051332034bff61a56a8368</id>
<content type='text'>
This is a leftover of the below commit.

Fixes: 4f04256c983a ("net: vrf: Drop local rtable and rt6_info")
Signed-off-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Acked-by: David Ahern &lt;dsahern@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net</title>
<updated>2020-12-12T06:29:38Z</updated>
<author>
<name>Jakub Kicinski</name>
</author>
<published>2020-12-12T04:12:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=46d5e62dd3c34770f3bfd0642daa9a7772a00362'/>
<id>urn:sha1:46d5e62dd3c34770f3bfd0642daa9a7772a00362</id>
<content type='text'>
xdp_return_frame_bulk() needs to pass a xdp_buff
to __xdp_return().

strlcpy got converted to strscpy but here it makes no
functional difference, so just keep the right code.

Conflicts:
	net/netfilter/nf_tables_api.c

Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>vrf: handle CONFIG_IPV6 not set for vrf_add_mac_header_if_unset()</title>
<updated>2020-12-09T20:00:40Z</updated>
<author>
<name>Andrea Mayer</name>
</author>
<published>2020-12-08T17:52:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9125abe7b9cb19f2d2b1c47a8c04dd81ce0d43b2'/>
<id>urn:sha1:9125abe7b9cb19f2d2b1c47a8c04dd81ce0d43b2</id>
<content type='text'>
The vrf_add_mac_header_if_unset() is defined within a conditional
compilation block which depends on the CONFIG_IPV6 macro.
However, the vrf_add_mac_header_if_unset() needs to be called also by IPv4
related code and when the CONFIG_IPV6 is not set, this function is missing.
As a consequence, the build process stops reporting the error:

 ERROR: implicit declaration of function 'vrf_add_mac_header_if_unset'

The problem is solved by *only* moving functions
vrf_add_mac_header_if_unset() and vrf_prepare_mac_header() out of the
conditional block.

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Fixes: 0489390882202 ("vrf: add mac header for tunneled packets when sniffer is attached")
Signed-off-by: Andrea Mayer &lt;andrea.mayer@uniroma2.it&gt;
Reviewed-by: David Ahern &lt;dsahern@kernel.org&gt;
Link: https://lore.kernel.org/r/20201208175210.8906-1-andrea.mayer@uniroma2.it
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>vrf: packets with lladdr src needs dst at input with orig_iif when needs strict</title>
<updated>2020-12-05T21:46:07Z</updated>
<author>
<name>Stephen Suryaputra</name>
</author>
<published>2020-12-04T03:06:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=205704c618af0ab2366015d2281a3b0814d918a0'/>
<id>urn:sha1:205704c618af0ab2366015d2281a3b0814d918a0</id>
<content type='text'>
Depending on the order of the routes to fe80::/64 are installed on the
VRF table, the NS for the source link-local address of the originator
might be sent to the wrong interface.

This patch ensures that packets with link-local addr source is doing a
lookup with the orig_iif when the destination addr indicates that it
is strict.

Add the reproducer as a use case in self test script fcnal-test.sh.

Fixes: b4869aa2f881 ("net: vrf: ipv6 support for local traffic to local addresses")
Signed-off-by: Stephen Suryaputra &lt;ssuryaextr@gmail.com&gt;
Reviewed-by: David Ahern &lt;dsahern@kernel.org&gt;
Link: https://lore.kernel.org/r/20201204030604.18828-1-ssuryaextr@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>vrf: add mac header for tunneled packets when sniffer is attached</title>
<updated>2020-12-04T21:30:50Z</updated>
<author>
<name>Andrea Mayer</name>
</author>
<published>2020-12-02T13:05:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=048939088220278b8ee5bbf3769fd2f803ca9e3e'/>
<id>urn:sha1:048939088220278b8ee5bbf3769fd2f803ca9e3e</id>
<content type='text'>
Before this patch, a sniffer attached to a VRF used as the receiving
interface of L3 tunneled packets detects them as malformed packets and
it complains about that (i.e.: tcpdump shows bogus packets).

The reason is that a tunneled L3 packet does not carry any L2
information and when the VRF is set as the receiving interface of a
decapsulated L3 packet, no mac header is currently set or valid.
Therefore, the purpose of this patch consists of adding a MAC header to
any packet which is directly received on the VRF interface ONLY IF:

 i) a sniffer is attached on the VRF and ii) the mac header is not set.

In this case, the mac address of the VRF is copied in both the
destination and the source address of the ethernet header. The protocol
type is set either to IPv4 or IPv6, depending on which L3 packet is
received.

Signed-off-by: Andrea Mayer &lt;andrea.mayer@uniroma2.it&gt;
Reviewed-by: David Ahern &lt;dsahern@kernel.org&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: don't include ethtool.h from netdevice.h</title>
<updated>2020-11-24T01:27:04Z</updated>
<author>
<name>Jakub Kicinski</name>
</author>
<published>2020-11-20T22:50:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cc69837fcaf467426ca19e5790085c26146a2300'/>
<id>urn:sha1:cc69837fcaf467426ca19e5790085c26146a2300</id>
<content type='text'>
linux/netdevice.h is included in very many places, touching any
of its dependecies causes large incremental builds.

Drop the linux/ethtool.h include, linux/netdevice.h just needs
a forward declaration of struct ethtool_ops.

Fix all the places which made use of this implicit include.

Acked-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Acked-by: Shannon Nelson &lt;snelson@pensando.io&gt;
Reviewed-by: Jesse Brandeburg &lt;jesse.brandeburg@intel.com&gt;
Link: https://lore.kernel.org/r/20201120225052.1427503-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>vrf: Fix fast path output packet handling with async Netfilter rules</title>
<updated>2020-11-12T15:47:06Z</updated>
<author>
<name>Martin Willi</name>
</author>
<published>2020-11-06T07:30:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9e2b7fa2df4365e99934901da4fb4af52d81e820'/>
<id>urn:sha1:9e2b7fa2df4365e99934901da4fb4af52d81e820</id>
<content type='text'>
VRF devices use an optimized direct path on output if a default qdisc
is involved, calling Netfilter hooks directly. This path, however, does
not consider Netfilter rules completing asynchronously, such as with
NFQUEUE. The Netfilter okfn() is called for asynchronously accepted
packets, but the VRF never passes that packet down the stack to send
it out over the slave device. Using the slower redirect path for this
seems not feasible, as we do not know beforehand if a Netfilter hook
has asynchronously completing rules.

Fix the use of asynchronously completing Netfilter rules in OUTPUT and
POSTROUTING by using a special completion function that additionally
calls dst_output() to pass the packet down the stack. Also, slightly
adjust the use of nf_reset_ct() so that is called in the asynchronous
case, too.

Fixes: dcdd43c41e60 ("net: vrf: performance improvements for IPv4")
Fixes: a9ec54d1b0cd ("net: vrf: performance improvements for IPv6")
Signed-off-by: Martin Willi &lt;martin@strongswan.org&gt;
Link: https://lore.kernel.org/r/20201106073030.3974927-1-martin@strongswan.org
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>vrf: Handle CONFIG_SYSCTL not set</title>
<updated>2020-07-24T00:51:04Z</updated>
<author>
<name>David Ahern</name>
</author>
<published>2020-07-23T23:23:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1b6687e31a2df9fbdb12d25c1d1d372777bf96a8'/>
<id>urn:sha1:1b6687e31a2df9fbdb12d25c1d1d372777bf96a8</id>
<content type='text'>
Randy reported compile failure when CONFIG_SYSCTL is not set/enabled:

ERROR: modpost: "sysctl_vals" [drivers/net/vrf.ko] undefined!

Fix by splitting out the sysctl init and cleanup into helpers that
can be set to do nothing when CONFIG_SYSCTL is disabled. In addition,
move vrf_strict_mode and vrf_strict_mode_change to above
vrf_shared_table_handler (code move only) and wrap all of it
in the ifdef CONFIG_SYSCTL.

Update the strict mode tests to check for the existence of the
/proc/sys entry.

Fixes: 33306f1aaf82 ("vrf: add sysctl parameter for strict mode")
Cc: Andrea Mayer &lt;andrea.mayer@uniroma2.it&gt;
Reported-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Signed-off-by: David Ahern &lt;dsahern@kernel.org&gt;
Acked-by: Randy Dunlap &lt;rdunlap@infradead.org&gt; # build-tested
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
