* 46775 netdev
From: cbordinaro @ 2016-11-12 9:40 UTC (permalink / raw)
To: netdev
[-- Attachment #1: MESSAGE_645923_netdev.zip --]
[-- Type: application/zip, Size: 3670 bytes --]
^ permalink raw reply
* I Hope You Get My Message This Time
From: Mr Friedrich Mayrhofer @ 2016-11-12 5:58 UTC (permalink / raw)
--
This is the second time i am sending you this mail.
I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me
personally for more details.
Regards.
Friedrich Mayrhofer
^ permalink raw reply
* Re: net/sctp: BUG: KASAN: stack-out-of-bounds in memcmp
From: Baozeng Ding @ 2016-11-12 10:12 UTC (permalink / raw)
To: Xin Long
Cc: Vladislav Yasevich, Neil Horman, David Miller, linux-sctp,
network dev
In-Reply-To: <CADvbK_ebJHcvvBFcnn0sfhabPe20BTB3A5ny95MZq_uN4MibTw@mail.gmail.com>
On 2016/11/10 13:48, Xin Long wrote:
> On Sat, Oct 15, 2016 at 4:28 PM, Baozeng Ding <sploving1@gmail.com> wrote:
>> Hello Xin Long,
>>
>> On 2016/10/14 19:13, Xin Long wrote:
>>> On Sat, Aug 20, 2016 at 3:51 PM, Baozeng Ding <sploving1@gmail.com> wrote:
>>>> Hello all,
>>>> The following program triggers stack-out-of-bounds in memcmp. The kernel version is 4.8.0-rc1+ (on Aug 13 commit 118253a593bd1c57de2d1193df1ccffe1abe745b). Thanks.
>>> ...
>>>>
>>>> #define _GNU_SOURCE
>>>> #include <unistd.h>
>>>> #include <stdint.h>
>>>> #include <sys/socket.h>
>>>> #include <sys/mman.h>
>>>> #include <linux/in.h>
>>>> #include <fcntl.h>
>>>> #include <string.h>
>>>> #include <stdio.h>
>>>>
>>>> int main()
>>>> {
>>>> int fd;
>>>> mmap((void *)0x20000000ul, 0xff2000ul, 0x3ul, 0x32ul, -1, 0x0ul);
>>>> fd = socket(AF_INET6, SOCK_STREAM, IPPROTO_SCTP);
>>>> memcpy((void*)0x20f82f80, "\x0a\x00\xab\x12\x72\xd4\x19\x9a\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x85\xda\x00\xa0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", 128);
>>>> bind(fd, (struct sockaddr*)0x20f82f80ul, 0x80ul);
>>>> *(uint64_t*)0x202e1fc8 = (uint64_t)0x20f77f80;
>>>> *(uint32_t*)0x202e1fd0 = (uint32_t)0x80;
>>>> *(uint64_t*)0x202e1fd8 = (uint64_t)0x20f7dfe0;
>>>> *(uint64_t*)0x202e1fe0 = (uint64_t)0x2;
>>>> *(uint64_t*)0x202e1fe8 = (uint64_t)0x20f77000;
>>>> *(uint64_t*)0x202e1ff0 = (uint64_t)0x3;
>>>> *(uint32_t*)0x202e1ff8 = (uint32_t)0x80;
>>>> memcpy((void*)0x20f77f80, "\x0a\x00\xab\x12\xb0\xb3\x20\x7b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xc2\xc2\x0b\xb2\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", 128);
>>>> *(uint64_t*)0x20f7dfe0 = (uint64_t)0x20f77fc5;
>>>> *(uint64_t*)0x20f7dfe8 = (uint64_t)0x3b;
>>>> *(uint64_t*)0x20f7dff0 = (uint64_t)0x20f77fac;
>>>> *(uint64_t*)0x20f7dff8 = (uint64_t)0x54;
>>>> memcpy((void*)0x20f77fc5, "\xa5\x7d\xf3\xc4\xfe\xd3\xfd\x44\x63\x00\x8c\x1e\x4c\x2e\x8d\x8d\x9a\x9c\x9c\x9d\x5b\x7c\xe1\x06\xf7\x15\x16\xed\x68\xd1\xfc\xf4\xa4\x3a\xe4\x69\x51\x16\x74\xf4\x1a\xcf\x0e\x99\xc3\xa3\x87\xe7\x81\x6c\x10\x78\x75\x17\x69\x9d\x11\x0c\xc7", 59);
>>>> memcpy((void*)0x20f77fac, "\x86\x08\x89\x3c\xf3\x58\xea\xe7\x64\x6a\xfb\xb5\xe8\xdd\x5f\x69\xa5\xd4\xdc\xd9\xe7\x71\x95\x07\x78\x7b\x21\xda\x43\x9c\x62\x4d\xca\x64\xb5\x6e\x96\x55\xe9\x58\x76\x66\x1d\xb9\x7b\xe6\x20\xc1\xa9\xed\x70\xc1\x2b\x7c\x86\x8c\xba\x28\xb3\x2c\xb9\x64\xb7\x84\x65\x0d\x7f\xa6\x98\x6f\x49\xcb\x35\xad\x5a\xdf\x13\x75\x99\x57\x7e\xbb\x38\x89", 84);
>>>> *(uint64_t*)0x20f77000 = (uint64_t)0x15;
>>>> *(uint32_t*)0x20f77008 = (uint32_t)0x1;
>>>> *(uint32_t*)0x20f7700c = (uint32_t)0xfffffffffffffffe;
>>>> *(uint8_t*)0x20f77010 = (uint8_t)0xbb;
>>>> *(uint8_t*)0x20f77011 = (uint8_t)0x2;
>>>> *(uint8_t*)0x20f77012 = (uint8_t)0x5;
>>>> *(uint8_t*)0x20f77013 = (uint8_t)0x2;
>>>> *(uint8_t*)0x20f77014 = (uint8_t)0x80000000;
>>>> *(uint64_t*)0x20f77015 = (uint64_t)0x10;
>>>> *(uint32_t*)0x20f7701d = (uint32_t)0xffff;
>>>> *(uint32_t*)0x20f77021 = (uint32_t)0x1;
>>>> *(uint64_t*)0x20f77025 = (uint64_t)0x13;
>>>> *(uint32_t*)0x20f7702d = (uint32_t)0x6;
>>>> *(uint32_t*)0x20f77031 = (uint32_t)0xfffffffffffffe00;
>>>> *(uint8_t*)0x20f77035 = (uint8_t)0x80000000;
>>>> *(uint8_t*)0x20f77036 = (uint8_t)0xfffffffffffffff8;
>>>> sendmmsg(fd, (struct mmsghdr *)0x202e1fc8ul, 0x1ul, 0x1ul);
>>>> return 0;
>>>> }
>>>>
>>> Hi, Baozeng, I couldn't reproduce this issue with this script,
>>> even in 118253a593bd1c57de2d1193df1ccffe1abe745b
>>> do I need to do some extra config for this ?
>>>
>> You need config KASAN.
>> CONFIG_HAVE_ARCH_KASAN=y
>> CONFIG_KASAN=y
>> CONFIG_KASAN_INLINE=y
>> CONFIG_KASAN_SHADOW_OFFSET=0xdffffc0000000000
>>
>> I justed tested with b67be92feb486f800d80d72c67fd87b47b79b18e(Octor 12),
>> it sitll exits. If you still cannot reproduce it, i will send the .config to you privately. Thanks.
>>
>
> Hi Baozeng, sorry for so late. but this issue is always on my radar.
>
> I still couldnot reproduce it, even on
> b67be92feb486f800d80d72c67fd87b47b79b18e in any of
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
>
> with:
> CONFIG_KASAN_SHADOW_OFFSET=0xdffffc0000000000
> CONFIG_HAVE_ARCH_KASAN=y
> CONFIG_KASAN=y
> # CONFIG_KASAN_OUTLINE is not set
> CONFIG_KASAN_INLINE=y
> # CONFIG_TEST_KASAN is not set
> ...
> attachment is my .config from linux.git
>
> I also tried with your .config, but in my box, it could only build 105
> .ko instead of 2000+. I don't think it works.
>
I used qemu to run the it:
qemu-system-x86_64 -m 1024 -net nic -net user,host=10.0.2.10,hostfwd=tcp::16059-:22 -display none -serial stdio -no-reboot -enable-kvm -numa node,nodeid=0,cpus=0-1 -numa node,nodeid=1,cpus=2-3 -smp sockets=2,cores=2,threads=1 -usb -usbdevice mouse -usbdevice tablet -soundhw all -hda ./wheezy.img -snapshot -kernel ./bzImage -append console=ttyS0 vsyscall=native rodata=n oops=panic panic_on_warn=1 panic=-1 ftrace_dump_on_oops=orig_cpu earlyprintk=serial slub_debug=UZ root=/dev/sda
> did I miss something ?
>
^ permalink raw reply
* did you receive my previous email ?
From: Friedrich Mayrhofer @ 2016-11-12 8:28 UTC (permalink / raw)
--
This is the second time i am sending you this mail.
I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me
personally for more details.
Regards.
Friedrich Mayrhofer
^ permalink raw reply
* Re: [PATCH net 2/2] r8152: rx descriptor check
From: Mark Lord @ 2016-11-12 13:21 UTC (permalink / raw)
To: Francois Romieu, Hayes Wang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <20161111121311.GA19673@electric-eye.fr.zoreil.com>
On 16-11-11 07:13 AM, Francois Romieu wrote:
> Hayes Wang <hayeswang@realtek.com> :
>> For some platforms, the data in memory is not the same with the one
>> from the device. That is, the data of memory is unbelievable. The
>> check is used to find out this situation.
>
> Invalid packet size corrupted receive descriptors in Realtek's device
> reminds of CVE-2009-4537.
>
> Is the silicium of both devices different enough to prevent the same
> exploit to happen ?
I don't know if the hardware can do it, but the existing Linux device
driver regularly attempts to process huge unreal packet sizes here.
I've had to patch it to reject "packets" larger than the configured MRU.
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply
* I Hope You Get My Message This Time
From: Mr Friedrich Mayrhofer @ 2016-11-12 8:17 UTC (permalink / raw)
--
This is the second time i am sending you this mail.
I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me
personally for more details.
Regards.
Friedrich Mayrhofer
^ permalink raw reply
* Spurious code in commit 1bf40ada6290 ("amd-xgbe: Add support for clause 37 auto-negotiation"
From: Marion & Christophe JAILLET @ 2016-11-12 14:34 UTC (permalink / raw)
To: thomas.lendacky, davem; +Cc: netdev, linux-kernel, Kernel Janitors
Hi,
in commit 1bf40ada6290 ("amd-xgbe: Add support for clause 37
auto-negotiation"), we can find:
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-common.h
b/drivers/net/ethernet/amd/xgbe/xgbe-common.h
index 695e982..8bcf4ef 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-common.h
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-common.h
[...]
#define XGBE_AN_CL37_PCS_MODE_MASK 0x06
#define XGBE_AN_CL37_PCS_MODE_BASEX 0x00
#define XGBE_AN_CL37_PCS_MODE_SGMII 0x04
#define XGBE_AN_CL37_TX_CONFIG_MASK 0x08
[...]
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
index d5bfbe4..723eb90 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
[...]
/* Set up the Control register */
reg = XMDIO_READ(pdata, MDIO_MMD_VEND2, MDIO_VEND2_AN_CTRL);
reg &= XGBE_AN_CL37_TX_CONFIG_MASK;
reg &= XGBE_AN_CL37_PCS_MODE_MASK;
[...]
the "reg &=" statements look spurious. The 2 constants being 0x06 and
0x08, the current code is equivalent to "reg = 0"
It is likely that "reg |=" (or "reg &= ~") was expected here.
Best regards,
CJ
^ permalink raw reply
* Re: Source address fib invalidation on IPv6
From: Jason A. Donenfeld @ 2016-11-12 15:40 UTC (permalink / raw)
To: David Ahern; +Cc: Netdev, LKML, WireGuard mailing list
In-Reply-To: <CAHmME9o_AM1Lms6CJSpbjfAgcyGuRx8yqwSaNWEbSnY7gGnt6w@mail.gmail.com>
Hi again,
I've done some pretty in depth debugging now to determine exactly what
the behavior of ipv6_stub->ipv6_dst_lookup is. First I'll start with
ip_route_output_flow, which I believe to be well behaved, and then
I'll show ipv6_stub->ipv6_dst_lookup, which seems ill-behaved:
Userspace:
ip addr add 192.168.1.2/24 dev eth0
Kernelspace:
struct flowi4 fl = {
.saddr = 192.168.1.2,
.daddr = 192.168.1.99,
};
rt = ip_route_output_flow(sock_net(sock), &fl, sock);
// rt returns valid rt for routing to 192.168.1.99 from
192.168.1.2 using eth0
Userspace:
ip addr add 192.168.1.3/24 dev eth0
ip addr del 192.168.1.2/24 dev eth0
Kernelspace:
struct flowi4 fl = {
.saddr = 192.168.1.2,
.daddr = 192.168.1.99,
};
rt = ip_route_output_flow(sock_net(sock), &fl, sock);
// PTR_ERR(rt) == -EINVAL
This seems correct behavior to me, since no interface has 192.168.1.2
as a source address.
Now for the incorrect IPv6 behavior:
Userspace:
ip -6 addr add abcd::2/96 dev eth0
Kernelspace:
struct flowi6 fl = {
.saddr = abcd::2,
.daddr = abcd::99,
};
ret = ipv6_stub->ipv6_dst_lookup(sock_net(sock), sock, &dst, &fl);
// ret is 0, and dst is a non-null dst routing to abcd::99 from
abcd::2 using eth0
Userspace:
ip -6 addr add abcd::3/96 dev eth0
ip -6 addr del abcd::2/96 dev eth0
Kernelspace:
struct flowi6 fl = {
.saddr = abcd::2,
.daddr = abcd::99,
};
ret = ipv6_stub->ipv6_dst_lookup(sock_net(sock), sock, &dst, &fl);
// ret is 0, and dst is a non-null dst routing to abcd::99 from
abcd::2 using eth0 **INCORRECT BEHAVIOR!**
This seems *INCORRECT* behavior to me, since no interface has abcd::2
as a source address.
So, to summarize, the problem is that ipv6_dst_lookup will happily
return a dst even though the source IP has been removed from the
interface.
I hope this clarifies things. I await your response.
Regards,
Jason
^ permalink raw reply
* Re: Spurious code in commit 1bf40ada6290 ("amd-xgbe: Add support for clause 37 auto-negotiation"
From: Tom Lendacky @ 2016-11-12 15:47 UTC (permalink / raw)
To: Marion & Christophe JAILLET, davem
Cc: netdev, linux-kernel, Kernel Janitors
In-Reply-To: <80c6a7b3-4a03-e087-3638-7048adebbda8@wanadoo.fr>
On 11/12/2016 8:34 AM, Marion & Christophe JAILLET wrote:
> Hi,
>
> in commit 1bf40ada6290 ("amd-xgbe: Add support for clause 37
> auto-negotiation"), we can find:
>
> diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-common.h
> b/drivers/net/ethernet/amd/xgbe/xgbe-common.h
> index 695e982..8bcf4ef 100644
> --- a/drivers/net/ethernet/amd/xgbe/xgbe-common.h
> +++ b/drivers/net/ethernet/amd/xgbe/xgbe-common.h
> [...]
> #define XGBE_AN_CL37_PCS_MODE_MASK 0x06
> #define XGBE_AN_CL37_PCS_MODE_BASEX 0x00
> #define XGBE_AN_CL37_PCS_MODE_SGMII 0x04
> #define XGBE_AN_CL37_TX_CONFIG_MASK 0x08
> [...]
>
> diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
> b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
> index d5bfbe4..723eb90 100644
> --- a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
> +++ b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
> [...]
> /* Set up the Control register */
> reg = XMDIO_READ(pdata, MDIO_MMD_VEND2, MDIO_VEND2_AN_CTRL);
> reg &= XGBE_AN_CL37_TX_CONFIG_MASK;
> reg &= XGBE_AN_CL37_PCS_MODE_MASK;
> [...]
>
> the "reg &=" statements look spurious. The 2 constants being 0x06 and
> 0x08, the current code is equivalent to "reg = 0"
>
> It is likely that "reg |=" (or "reg &= ~") was expected here.
Yes, those should have been "reg &= ~". I didn't find this in my testing
because the register is all zeroes after reset. I'll submit a patch to
fix that.
Thanks,
Tom
>
> Best regards,
> CJ
>
^ permalink raw reply
* [PATCH] net: atheros: atl1c: use new api ethtool_{get|set}_link_ksettings
From: Philippe Reynes @ 2016-11-12 16:32 UTC (permalink / raw)
To: jcliburn, chris.snook, davem; +Cc: netdev, linux-kernel, Philippe Reynes
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
---
drivers/net/ethernet/atheros/atl1c/atl1c_ethtool.c | 54 +++++++++++---------
1 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_ethtool.c b/drivers/net/ethernet/atheros/atl1c/atl1c_ethtool.c
index 872b7ab..cfe86a2 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_ethtool.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_ethtool.c
@@ -26,46 +26,52 @@
#include "atl1c.h"
-static int atl1c_get_settings(struct net_device *netdev,
- struct ethtool_cmd *ecmd)
+static int atl1c_get_link_ksettings(struct net_device *netdev,
+ struct ethtool_link_ksettings *cmd)
{
struct atl1c_adapter *adapter = netdev_priv(netdev);
struct atl1c_hw *hw = &adapter->hw;
+ u32 supported, advertising;
- ecmd->supported = (SUPPORTED_10baseT_Half |
+ supported = (SUPPORTED_10baseT_Half |
SUPPORTED_10baseT_Full |
SUPPORTED_100baseT_Half |
SUPPORTED_100baseT_Full |
SUPPORTED_Autoneg |
SUPPORTED_TP);
if (hw->link_cap_flags & ATL1C_LINK_CAP_1000M)
- ecmd->supported |= SUPPORTED_1000baseT_Full;
+ supported |= SUPPORTED_1000baseT_Full;
- ecmd->advertising = ADVERTISED_TP;
+ advertising = ADVERTISED_TP;
- ecmd->advertising |= hw->autoneg_advertised;
+ advertising |= hw->autoneg_advertised;
- ecmd->port = PORT_TP;
- ecmd->phy_address = 0;
- ecmd->transceiver = XCVR_INTERNAL;
+ cmd->base.port = PORT_TP;
+ cmd->base.phy_address = 0;
if (adapter->link_speed != SPEED_0) {
- ethtool_cmd_speed_set(ecmd, adapter->link_speed);
+ cmd->base.speed = adapter->link_speed;
if (adapter->link_duplex == FULL_DUPLEX)
- ecmd->duplex = DUPLEX_FULL;
+ cmd->base.duplex = DUPLEX_FULL;
else
- ecmd->duplex = DUPLEX_HALF;
+ cmd->base.duplex = DUPLEX_HALF;
} else {
- ethtool_cmd_speed_set(ecmd, SPEED_UNKNOWN);
- ecmd->duplex = DUPLEX_UNKNOWN;
+ cmd->base.speed = SPEED_UNKNOWN;
+ cmd->base.duplex = DUPLEX_UNKNOWN;
}
- ecmd->autoneg = AUTONEG_ENABLE;
+ cmd->base.autoneg = AUTONEG_ENABLE;
+
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+ supported);
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+ advertising);
+
return 0;
}
-static int atl1c_set_settings(struct net_device *netdev,
- struct ethtool_cmd *ecmd)
+static int atl1c_set_link_ksettings(struct net_device *netdev,
+ const struct ethtool_link_ksettings *cmd)
{
struct atl1c_adapter *adapter = netdev_priv(netdev);
struct atl1c_hw *hw = &adapter->hw;
@@ -74,12 +80,12 @@ static int atl1c_set_settings(struct net_device *netdev,
while (test_and_set_bit(__AT_RESETTING, &adapter->flags))
msleep(1);
- if (ecmd->autoneg == AUTONEG_ENABLE) {
+ if (cmd->base.autoneg == AUTONEG_ENABLE) {
autoneg_advertised = ADVERTISED_Autoneg;
} else {
- u32 speed = ethtool_cmd_speed(ecmd);
+ u32 speed = cmd->base.speed;
if (speed == SPEED_1000) {
- if (ecmd->duplex != DUPLEX_FULL) {
+ if (cmd->base.duplex != DUPLEX_FULL) {
if (netif_msg_link(adapter))
dev_warn(&adapter->pdev->dev,
"1000M half is invalid\n");
@@ -88,12 +94,12 @@ static int atl1c_set_settings(struct net_device *netdev,
}
autoneg_advertised = ADVERTISED_1000baseT_Full;
} else if (speed == SPEED_100) {
- if (ecmd->duplex == DUPLEX_FULL)
+ if (cmd->base.duplex == DUPLEX_FULL)
autoneg_advertised = ADVERTISED_100baseT_Full;
else
autoneg_advertised = ADVERTISED_100baseT_Half;
} else {
- if (ecmd->duplex == DUPLEX_FULL)
+ if (cmd->base.duplex == DUPLEX_FULL)
autoneg_advertised = ADVERTISED_10baseT_Full;
else
autoneg_advertised = ADVERTISED_10baseT_Half;
@@ -284,8 +290,6 @@ static int atl1c_nway_reset(struct net_device *netdev)
}
static const struct ethtool_ops atl1c_ethtool_ops = {
- .get_settings = atl1c_get_settings,
- .set_settings = atl1c_set_settings,
.get_drvinfo = atl1c_get_drvinfo,
.get_regs_len = atl1c_get_regs_len,
.get_regs = atl1c_get_regs,
@@ -297,6 +301,8 @@ static int atl1c_nway_reset(struct net_device *netdev)
.get_link = ethtool_op_get_link,
.get_eeprom_len = atl1c_get_eeprom_len,
.get_eeprom = atl1c_get_eeprom,
+ .get_link_ksettings = atl1c_get_link_ksettings,
+ .set_link_ksettings = atl1c_set_link_ksettings,
};
void atl1c_set_ethtool_ops(struct net_device *netdev)
--
1.7.4.4
^ permalink raw reply related
* 15405 netdev
From: clinicallaw @ 2016-11-12 17:09 UTC (permalink / raw)
To: netdev
[-- Attachment #1: MESSAGE_884059386788_netdev.zip --]
[-- Type: application/zip, Size: 3581 bytes --]
^ permalink raw reply
* [PATCH] ps3_gelic: fix spelling mistake in debug message
From: Colin King @ 2016-11-12 17:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
David S . Miller, Muhammad Falak R Wani, Christophe Jaillet,
Jarod Wilson, netdev, linuxppc-dev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake "unmached" to "unmatched" in
debug message.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/toshiba/ps3_gelic_wireless.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c b/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
index b3abd02..eed18f8 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
@@ -1694,7 +1694,7 @@ struct gelic_wl_scan_info *gelic_wl_find_best_bss(struct gelic_wl_info *wl)
pr_debug("%s: bssid matched\n", __func__);
break;
} else {
- pr_debug("%s: bssid unmached\n", __func__);
+ pr_debug("%s: bssid unmatched\n", __func__);
continue;
}
}
--
2.10.2
^ permalink raw reply related
* [PATCH] net: ethernet: ixp4xx_eth: fix spelling mistake in debug message
From: Colin King @ 2016-11-12 17:44 UTC (permalink / raw)
To: Krzysztof Halasa, netdev; +Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake "successed" to "succeeded"
in debug message. Also unwrap multi-line literal string.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/xscale/ixp4xx_eth.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xscale/ixp4xx_eth.c b/drivers/net/ethernet/xscale/ixp4xx_eth.c
index 46cc33b..07d862d 100644
--- a/drivers/net/ethernet/xscale/ixp4xx_eth.c
+++ b/drivers/net/ethernet/xscale/ixp4xx_eth.c
@@ -708,8 +708,7 @@ static int eth_poll(struct napi_struct *napi, int budget)
if (!qmgr_stat_below_low_watermark(rxq) &&
napi_reschedule(napi)) { /* not empty again */
#if DEBUG_RX
- printk(KERN_DEBUG "%s: eth_poll"
- " napi_reschedule successed\n",
+ printk(KERN_DEBUG "%s: eth_poll napi_reschedule succeeded\n",
dev->name);
#endif
qmgr_disable_irq(rxq);
--
2.10.2
^ permalink raw reply related
* Re: Source address fib invalidation on IPv6
From: David Ahern @ 2016-11-12 18:14 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Netdev, Hannes Frederic Sowa, LKML, WireGuard mailing list,
YOSHIFUJI Hideaki
In-Reply-To: <CAHmME9oeAuBQJguTFivYsYw4fMoc4+sgxcdS4MArN474m7NjTQ@mail.gmail.com>
On 11/12/16 8:40 AM, Jason A. Donenfeld wrote:
> Hi again,
>
> I've done some pretty in depth debugging now to determine exactly what
> the behavior of ipv6_stub->ipv6_dst_lookup is. First I'll start with
> ip_route_output_flow, which I believe to be well behaved, and then
> I'll show ipv6_stub->ipv6_dst_lookup, which seems ill-behaved:
>
> Userspace:
> ip addr add 192.168.1.2/24 dev eth0
> Kernelspace:
> struct flowi4 fl = {
> .saddr = 192.168.1.2,
> .daddr = 192.168.1.99,
> };
> rt = ip_route_output_flow(sock_net(sock), &fl, sock);
> // rt returns valid rt for routing to 192.168.1.99 from
> 192.168.1.2 using eth0
> Userspace:
> ip addr add 192.168.1.3/24 dev eth0
> ip addr del 192.168.1.2/24 dev eth0
> Kernelspace:
> struct flowi4 fl = {
> .saddr = 192.168.1.2,
> .daddr = 192.168.1.99,
> };
> rt = ip_route_output_flow(sock_net(sock), &fl, sock);
> // PTR_ERR(rt) == -EINVAL
I believe that is coming from __ip_route_output_key_hash(), line 2232 with __ip_dev_find not finding a device with that address.
Not applicable for your use case, but __ip_dev_find does not have any checks on which L3 domain the device belongs to so the check does not handle VRF for example. I'll take a look at fixing this next week.
>
> This seems correct behavior to me, since no interface has 192.168.1.2
> as a source address.
>
> Now for the incorrect IPv6 behavior:
>
> Userspace:
> ip -6 addr add abcd::2/96 dev eth0
> Kernelspace:
> struct flowi6 fl = {
> .saddr = abcd::2,
> .daddr = abcd::99,
> };
> ret = ipv6_stub->ipv6_dst_lookup(sock_net(sock), sock, &dst, &fl);
> // ret is 0, and dst is a non-null dst routing to abcd::99 from
> abcd::2 using eth0
> Userspace:
> ip -6 addr add abcd::3/96 dev eth0
> ip -6 addr del abcd::2/96 dev eth0
> Kernelspace:
> struct flowi6 fl = {
> .saddr = abcd::2,
> .daddr = abcd::99,
> };
> ret = ipv6_stub->ipv6_dst_lookup(sock_net(sock), sock, &dst, &fl);
> // ret is 0, and dst is a non-null dst routing to abcd::99 from
> abcd::2 using eth0 **INCORRECT BEHAVIOR!**
>
> This seems *INCORRECT* behavior to me, since no interface has abcd::2
> as a source address.
Gotcha. I don't see any checks that the saddr is valid similar to what IPv4 does.
I think the right place to add a check is in ip6_dst_lookup_tail():
if (!ipv6_addr_any(&fl6->saddr)) {
// saddr is valid for L3 domain
}
^ permalink raw reply
* Re: Source address fib invalidation on IPv6
From: Jason A. Donenfeld @ 2016-11-12 19:08 UTC (permalink / raw)
To: David Ahern
Cc: Netdev, Hannes Frederic Sowa, LKML, WireGuard mailing list,
YOSHIFUJI Hideaki
In-Reply-To: <0dbf5deb-bffb-4878-a268-1adb17c47676@cumulusnetworks.com>
Hi David,
On Sat, Nov 12, 2016 at 7:14 PM, David Ahern <dsa@cumulusnetworks.com> wrote:
> I believe that is coming from __ip_route_output_key_hash(), line 2232 with __ip_dev_find not finding a device with that address.
It's possible we simply are looking at different source trees, but I
have the -EINVAL return in 4.8 route.c sources happening due to the
assignment on line 2175 and the jump on line 2220.
> Not applicable for your use case, but __ip_dev_find does not have any checks on which L3 domain the device belongs to so the check does not handle VRF for example. I'll take a look at fixing this next week.
Interesting.
>
> Gotcha. I don't see any checks that the saddr is valid similar to what IPv4 does.
>
> I think the right place to add a check is in ip6_dst_lookup_tail():
> if (!ipv6_addr_any(&fl6->saddr)) {
> // saddr is valid for L3 domain
> }
Right. It should probably do the check here, and return
ERR_PTR(-EINVAL), the same as the v4 version, so that ret codes can be
checked consistently.
Thanks for looking into this. If you're backed up and would like me to
submit a patch, just let me know, and I'll give it my best shot.
Regards,
Jason
^ permalink raw reply
* Re: [PATCH] genetlink: fix unsigned int comparison with less than zero
From: Johannes Berg @ 2016-11-12 21:37 UTC (permalink / raw)
To: Cong Wang, Colin King
Cc: David S . Miller, pravin shelar, Wei Yongjun, Florian Westphal,
Tycho Andersen, Tom Herbert, Linux Kernel Network Developers,
LKML
In-Reply-To: <CAM_iQpW=q4nm97dNouSL19Cr2cEWT9xQHXAm4CNJk=AY8z_2MA@mail.gmail.com>
On Thu, 2016-11-10 at 09:11 -0800, Cong Wang wrote:
> On Thu, Nov 10, 2016 at 7:57 AM, Colin King <colin.king@canonical.com
> > wrote:
> >
> > From: Colin Ian King <colin.king@canonical.com>
> >
> > family->id is unsigned, so the less than zero check for
> > failure return from idr_alloc is never true and so the error exit
> > is never handled. Instead, assign err and check if this is less
> > than zero since this is a signed integer.
>
> Why family->id can't be just signed int? For me it should be.
I suppose it could be, since family IDs are allocated in a 16-bit range
anyway. But family IDs can also never actually be negative, so having
an unsigned int in the struct makes sense too.
I tend to think this patch is fine.
johannes
^ permalink raw reply
* [PATCH] net: atheros: atl1e: use new api ethtool_{get|set}_link_ksettings
From: Philippe Reynes @ 2016-11-12 22:16 UTC (permalink / raw)
To: jcliburn, chris.snook, davem; +Cc: netdev, linux-kernel, Philippe Reynes
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
The previous implementation of set_settings was modifying
the value of advertising, but with the new API, it's not
possible. The structure ethtool_link_ksettings is defined
as const.
Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
---
drivers/net/ethernet/atheros/atl1e/atl1e_ethtool.c | 62 +++++++++++--------
1 files changed, 36 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_ethtool.c b/drivers/net/ethernet/atheros/atl1e/atl1e_ethtool.c
index 8e3dbd4..cb489e7 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e_ethtool.c
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e_ethtool.c
@@ -26,73 +26,83 @@
#include "atl1e.h"
-static int atl1e_get_settings(struct net_device *netdev,
- struct ethtool_cmd *ecmd)
+static int atl1e_get_link_ksettings(struct net_device *netdev,
+ struct ethtool_link_ksettings *cmd)
{
struct atl1e_adapter *adapter = netdev_priv(netdev);
struct atl1e_hw *hw = &adapter->hw;
+ u32 supported, advertising;
- ecmd->supported = (SUPPORTED_10baseT_Half |
+ supported = (SUPPORTED_10baseT_Half |
SUPPORTED_10baseT_Full |
SUPPORTED_100baseT_Half |
SUPPORTED_100baseT_Full |
SUPPORTED_Autoneg |
SUPPORTED_TP);
if (hw->nic_type == athr_l1e)
- ecmd->supported |= SUPPORTED_1000baseT_Full;
+ supported |= SUPPORTED_1000baseT_Full;
- ecmd->advertising = ADVERTISED_TP;
+ advertising = ADVERTISED_TP;
- ecmd->advertising |= ADVERTISED_Autoneg;
- ecmd->advertising |= hw->autoneg_advertised;
+ advertising |= ADVERTISED_Autoneg;
+ advertising |= hw->autoneg_advertised;
- ecmd->port = PORT_TP;
- ecmd->phy_address = 0;
- ecmd->transceiver = XCVR_INTERNAL;
+ cmd->base.port = PORT_TP;
+ cmd->base.phy_address = 0;
if (adapter->link_speed != SPEED_0) {
- ethtool_cmd_speed_set(ecmd, adapter->link_speed);
+ cmd->base.speed = adapter->link_speed;
if (adapter->link_duplex == FULL_DUPLEX)
- ecmd->duplex = DUPLEX_FULL;
+ cmd->base.duplex = DUPLEX_FULL;
else
- ecmd->duplex = DUPLEX_HALF;
+ cmd->base.duplex = DUPLEX_HALF;
} else {
- ethtool_cmd_speed_set(ecmd, SPEED_UNKNOWN);
- ecmd->duplex = DUPLEX_UNKNOWN;
+ cmd->base.speed = SPEED_UNKNOWN;
+ cmd->base.duplex = DUPLEX_UNKNOWN;
}
- ecmd->autoneg = AUTONEG_ENABLE;
+ cmd->base.autoneg = AUTONEG_ENABLE;
+
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+ supported);
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+ advertising);
+
return 0;
}
-static int atl1e_set_settings(struct net_device *netdev,
- struct ethtool_cmd *ecmd)
+static int atl1e_set_link_ksettings(struct net_device *netdev,
+ const struct ethtool_link_ksettings *cmd)
{
struct atl1e_adapter *adapter = netdev_priv(netdev);
struct atl1e_hw *hw = &adapter->hw;
+ u32 advertising;
+
+ ethtool_convert_link_mode_to_legacy_u32(&advertising,
+ cmd->link_modes.advertising);
while (test_and_set_bit(__AT_RESETTING, &adapter->flags))
msleep(1);
- if (ecmd->autoneg == AUTONEG_ENABLE) {
+ if (cmd->base.autoneg == AUTONEG_ENABLE) {
u16 adv4, adv9;
- if ((ecmd->advertising&ADVERTISE_1000_FULL)) {
+ if (advertising & ADVERTISE_1000_FULL) {
if (hw->nic_type == athr_l1e) {
hw->autoneg_advertised =
- ecmd->advertising & AT_ADV_MASK;
+ advertising & AT_ADV_MASK;
} else {
clear_bit(__AT_RESETTING, &adapter->flags);
return -EINVAL;
}
- } else if (ecmd->advertising&ADVERTISE_1000_HALF) {
+ } else if (advertising & ADVERTISE_1000_HALF) {
clear_bit(__AT_RESETTING, &adapter->flags);
return -EINVAL;
} else {
hw->autoneg_advertised =
- ecmd->advertising & AT_ADV_MASK;
+ advertising & AT_ADV_MASK;
}
- ecmd->advertising = hw->autoneg_advertised |
+ advertising = hw->autoneg_advertised |
ADVERTISED_TP | ADVERTISED_Autoneg;
adv4 = hw->mii_autoneg_adv_reg & ~ADVERTISE_ALL;
@@ -367,8 +377,6 @@ static int atl1e_nway_reset(struct net_device *netdev)
}
static const struct ethtool_ops atl1e_ethtool_ops = {
- .get_settings = atl1e_get_settings,
- .set_settings = atl1e_set_settings,
.get_drvinfo = atl1e_get_drvinfo,
.get_regs_len = atl1e_get_regs_len,
.get_regs = atl1e_get_regs,
@@ -380,6 +388,8 @@ static int atl1e_nway_reset(struct net_device *netdev)
.get_eeprom_len = atl1e_get_eeprom_len,
.get_eeprom = atl1e_get_eeprom,
.set_eeprom = atl1e_set_eeprom,
+ .get_link_ksettings = atl1e_get_link_ksettings,
+ .set_link_ksettings = atl1e_set_link_ksettings,
};
void atl1e_set_ethtool_ops(struct net_device *netdev)
--
1.7.4.4
^ permalink raw reply related
* [PATCH] net/phy/vitesse: Configure RGMII skew on VSC8601, if needed
From: Alexandru Gagniuc @ 2016-11-12 23:32 UTC (permalink / raw)
To: f.fainelli; +Cc: gokhan, netdev, linux-kernel, Alexandru Gagniuc
With RGMII, we need a 1.5 to 2ns skew between clock and data lines. The
VSC8601 can handle this internally. While the VSC8601 can set more
fine-grained delays, the standard skew settings work out of the box.
The same heuristic is used to determine when this skew should be enabled
as in vsc824x_config_init().
Tested on custom board with AM3352 SOC and VSC801 PHY.
Signed-off-by: Alexandru Gagniuc <alex.g@adaptrum.com>
---
drivers/net/phy/vitesse.c | 31 ++++++++++++++++++++++++++++++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
index 2e37eb3..7923831 100644
--- a/drivers/net/phy/vitesse.c
+++ b/drivers/net/phy/vitesse.c
@@ -62,6 +62,10 @@
/* Vitesse Extended Page Access Register */
#define MII_VSC82X4_EXT_PAGE_ACCESS 0x1f
+/* Vitesse VSC8601 Extended PHY Control Register 1 */
+#define MII_VSC8601_EPHY_CTL 0x17
+#define MII_VSC8601_EPHY_CTL_RGMII_SKEW (1 << 8)
+
#define PHY_ID_VSC8234 0x000fc620
#define PHY_ID_VSC8244 0x000fc6c0
#define PHY_ID_VSC8514 0x00070670
@@ -111,6 +115,31 @@ static int vsc824x_config_init(struct phy_device *phydev)
return err;
}
+static int vsc8601_add_skew(struct phy_device *phydev)
+{
+ int ret;
+
+ ret = phy_read(phydev, MII_VSC8601_EPHY_CTL);
+ if (ret < 0)
+ return ret;
+
+ ret |= MII_VSC8601_EPHY_CTL_RGMII_SKEW;
+ return phy_write(phydev, MII_VSC8601_EPHY_CTL, ret);
+}
+
+static int vsc8601_config_init(struct phy_device *phydev)
+{
+ int ret = 0;
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
+ ret = vsc8601_add_skew(phydev);
+
+ if (ret < 0)
+ return ret;
+
+ return genphy_config_init(phydev);
+}
+
static int vsc824x_ack_interrupt(struct phy_device *phydev)
{
int err = 0;
@@ -275,7 +304,7 @@ static struct phy_driver vsc82xx_driver[] = {
.phy_id_mask = 0x000ffff0,
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
- .config_init = &genphy_config_init,
+ .config_init = &vsc8601_config_init,
.config_aneg = &genphy_config_aneg,
.read_status = &genphy_read_status,
.ack_interrupt = &vsc824x_ack_interrupt,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v13 7/8] openvswitch: add Ethernet push and pop actions
From: Pravin Shelar @ 2016-11-12 23:57 UTC (permalink / raw)
To: Jiri Benc; +Cc: ovs dev, Linux Kernel Network Developers, Simon Horman
In-Reply-To: <fefa3d36d50639e176e831fefbc53d38ab2f04f6.1478791347.git.jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Thu, Nov 10, 2016 at 7:28 AM, Jiri Benc <jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> It's not allowed to push Ethernet header in front of another Ethernet
> header.
>
> It's not allowed to pop Ethernet header if there's a vlan tag. This
> preserves the invariant that L3 packet never has a vlan tag.
>
> Based on previous versions by Lorand Jakab and Simon Horman.
>
> Signed-off-by: Lorand Jakab <lojakab-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Simon Horman <simon.horman-wFxRvT7yatFl57MIdRCFDg@public.gmane.org>
> Signed-off-by: Jiri Benc <jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Acked-by: Pravin B Shelar <pshelar-LZ6Gd1LRuIk@public.gmane.org>
^ permalink raw reply
* Re: [PATCH net-next v13 5/8] openvswitch: add processing of L3 packets
From: Pravin Shelar @ 2016-11-12 23:58 UTC (permalink / raw)
To: Jiri Benc
Cc: Linux Kernel Network Developers, ovs dev, Lorand Jakab,
Simon Horman
In-Reply-To: <05254a13fdb29c1c3eaa1840ba2d127d98f8c418.1478791347.git.jbenc@redhat.com>
On Thu, Nov 10, 2016 at 7:28 AM, Jiri Benc <jbenc@redhat.com> wrote:
> Support receiving, extracting flow key and sending of L3 packets (packets
> without an Ethernet header).
>
> Note that even after this patch, non-Ethernet interfaces are still not
> allowed to be added to bridges. Similarly, netlink interface for sending and
> receiving L3 packets to/from user space is not in place yet.
>
> Based on previous versions by Lorand Jakab and Simon Horman.
>
> Signed-off-by: Lorand Jakab <lojakab@cisco.com>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
> ---
> v13:
> - fix incorrect setting of packet to NULL in ovs_packet_cmd_execute
> - dropping packet for interfaces with wrong type
> ---
Thanks for working on this.
Acked-by: Pravin B Shelar <pshelar@ovn.org>
^ permalink raw reply
* Debugging Ethernet issues
From: Mason @ 2016-11-13 0:01 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Mans Rullgard, Sergei Shtylyov, Tom Lendacky,
Zach Brown, Andrew Lunn, Shaohui Xie, Tim Beale, Brian Hill,
Vince Bridgers, Balakumaran Kannan, David S. Miller,
Sebastian Frias, Kirill Kapranov
Hello everyone,
In a past thread ("Ethernet not working on a different SoC with
same eth HW") I was struggling getting Ethernet to work at all on
a new board using a recent 4.7 kernel.
After much hair-pulling, it turned out that *some* of the breakage
was caused by a local patch which should have been guarded by a
preprocessor macro.
But even after reverting that patch, Ethernet does not work well
on this board with kernel 4.7 whereas if I use an ancient 3.4 kernel,
then Ethernet works much better.
Differences:
When connected to a 100 Mbps switch
3.4 negotiates a LAN DHCP setup instantly
4.7 times out
When connected to a Gigabit switch
3.4 negotiates a LAN DHCP setup instantly
4.7 requires over 5 seconds to do so
(In case it matters, my board is using an Atheros 8035 PHY.)
I am aware that there have been hundreds of patches to the phy
and net frameworks in the 3.4 to 4.7 time-frame. I'm wondering
if there are important events I can log, to see what is going
wrong in the 4.7 case?
Are there kernel debugging options I might turn on, to better
understand what is going wrong?
I would be extremely grateful for any insight on this subject.
Regards.
^ permalink raw reply
* Re: Source address fib invalidation on IPv6
From: Jason A. Donenfeld @ 2016-11-13 0:43 UTC (permalink / raw)
To: David Ahern
Cc: Netdev, WireGuard mailing list, LKML, YOSHIFUJI Hideaki,
Hannes Frederic Sowa
In-Reply-To: <CAHmME9owJNvMfF9jHGW7i_jPMaxwPhxQE5W6cxjw14nL0HK0eQ@mail.gmail.com>
On Sat, Nov 12, 2016 at 8:08 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>> Gotcha. I don't see any checks that the saddr is valid similar to what IPv4 does.
>>
>> I think the right place to add a check is in ip6_dst_lookup_tail():
>> if (!ipv6_addr_any(&fl6->saddr)) {
>> // saddr is valid for L3 domain
>> }
>
> Right. It should probably do the check here, and return
> ERR_PTR(-EINVAL), the same as the v4 version, so that ret codes can be
> checked consistently.
>
> Thanks for looking into this. If you're backed up and would like me to
> submit a patch, just let me know, and I'll give it my best shot.
In perusing through the v6 FIB code, I don't even see an analog of
__ip_dev_find... Hm?
^ permalink raw reply
* Re: Source address fib invalidation on IPv6
From: Hannes Frederic Sowa @ 2016-11-13 0:51 UTC (permalink / raw)
To: Jason A. Donenfeld, David Ahern
Cc: Netdev, LKML, WireGuard mailing list, YOSHIFUJI Hideaki
In-Reply-To: <CAHmME9pMzcwjveOoa08-fVCnZTkaoMz8y9DEc7f6b-4PeWu4xQ@mail.gmail.com>
On Sun, Nov 13, 2016, at 01:43, Jason A. Donenfeld wrote:
> On Sat, Nov 12, 2016 at 8:08 PM, Jason A. Donenfeld <Jason@zx2c4.com>
> wrote:
> >> Gotcha. I don't see any checks that the saddr is valid similar to what IPv4 does.
> >>
> >> I think the right place to add a check is in ip6_dst_lookup_tail():
> >> if (!ipv6_addr_any(&fl6->saddr)) {
> >> // saddr is valid for L3 domain
> >> }
> >
> > Right. It should probably do the check here, and return
> > ERR_PTR(-EINVAL), the same as the v4 version, so that ret codes can be
> > checked consistently.
> >
> > Thanks for looking into this. If you're backed up and would like me to
> > submit a patch, just let me know, and I'll give it my best shot.
>
> In perusing through the v6 FIB code, I don't even see an analog of
> __ip_dev_find... Hm?
You probably need some combination of ipv6_chk_addr and/or
ipv6_check_addr_and_flags (where dev can also be NULL). Be careful if a
IFA_HOST or IFA_LINK address switches from one interface to another.
Bye,
Hannes
^ permalink raw reply
* Re: Source address fib invalidation on IPv6
From: Jason A. Donenfeld @ 2016-11-13 0:51 UTC (permalink / raw)
To: David Ahern
Cc: Netdev, Hannes Frederic Sowa, LKML, WireGuard mailing list,
YOSHIFUJI Hideaki
In-Reply-To: <CAHmME9pMzcwjveOoa08-fVCnZTkaoMz8y9DEc7f6b-4PeWu4xQ@mail.gmail.com>
On Sun, Nov 13, 2016 at 1:43 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> In perusing through the v6 FIB code, I don't even see an analog of
> __ip_dev_find... Hm?
Of all places, the iscsi code actually has a nice side-by-side
comparison. So far as I can see, the other protocols just omit this
check in the v6 case, which I believe to be errant behavior. For
example, grep for ip_dev_find in the sctp v4 code. The equivalent v6
code is missing the dev check. Ugly! Here's the block I found in
cxgbit_cm.c:
static struct net_device *cxgbit_ipv4_netdev(__be32 saddr)
{
struct net_device *ndev;
ndev = __ip_dev_find(&init_net, saddr, false);
if (!ndev)
return NULL;
return cxgbit_get_real_dev(ndev);
}
static struct net_device *cxgbit_ipv6_netdev(struct in6_addr *addr6)
{
struct net_device *ndev = NULL;
bool found = false;
if (IS_ENABLED(CONFIG_IPV6)) {
for_each_netdev_rcu(&init_net, ndev)
if (ipv6_chk_addr(&init_net, addr6, ndev, 1)) {
found = true;
break;
}
}
if (!found)
return NULL;
return cxgbit_get_real_dev(ndev);
}
It seems like __ip6_dev_find could be made out of that inner loop.
Then existing uses like that iscsi code can be replaced with that
helper function, and the existing ip6 route tail function can be
augmented in the manner you recommended. Seem like a decent
implementation strategy?
I might submit some patches, unless you beat me to it.
Jason
^ permalink raw reply
* Re: Source address fib invalidation on IPv6
From: Jason A. Donenfeld @ 2016-11-13 1:00 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: David Ahern, YOSHIFUJI Hideaki, LKML, WireGuard mailing list,
Netdev
In-Reply-To: <1478998272.2299343.785875225.19237693@webmail.messagingengine.com>
Hi Hannes,
On Sun, Nov 13, 2016 at 1:51 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> You probably need some combination of ipv6_chk_addr and/or
> ipv6_check_addr_and_flags (where dev can also be NULL). Be careful if a
> IFA_HOST or IFA_LINK address switches from one interface to another.
I can confirm this trick works beautifully:
https://git.zx2c4.com/WireGuard/commit/?id=eb65810fc6350c50b42abedd1291b12337d3dc3d
I'll see if I can fold this into the routing function so that it
behaves the same as v4, unless David gets there first.
Regards,
Jason
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox