* Re: [virtio-dev] Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
From: Cornelia Huck @ 2018-06-25 9:55 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, konrad.wilk,
Jakub Kicinski, Samudrala, Sridhar, qemu-devel, virtualization,
Siwei Liu, Venu Busireddy, Netdev, boris.ostrovsky, aaron.f.brown,
Joao Martins
In-Reply-To: <20180622214259-mutt-send-email-mst@kernel.org>
On Fri, 22 Jun 2018 22:05:50 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Fri, Jun 22, 2018 at 05:09:55PM +0200, Cornelia Huck wrote:
> > On Thu, 21 Jun 2018 21:20:13 +0300
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >
> > > On Thu, Jun 21, 2018 at 04:59:13PM +0200, Cornelia Huck wrote:
> > > > OK, so what about the following:
> > > >
> > > > - introduce a new feature bit, VIRTIO_NET_F_STANDBY_UUID that indicates
> > > > that we have a new uuid field in the virtio-net config space
> > > > - in QEMU, add a property for virtio-net that allows to specify a uuid,
> > > > offer VIRTIO_NET_F_STANDBY_UUID if set
> > > > - when configuring, set the property to the group UUID of the vfio-pci
> > > > device
> > > > - in the guest, use the uuid from the virtio-net device's config space
> > > > if applicable; else, fall back to matching by MAC as done today
> > > >
> > > > That should work for all virtio transports.
> > >
> > > True. I'm a bit unhappy that it's virtio net specific though
> > > since down the road I expect we'll have a very similar feature
> > > for scsi (and maybe others).
> > >
> > > But we do not have a way to have fields that are portable
> > > both across devices and transports, and I think it would
> > > be a useful addition. How would this work though? Any idea?
> >
> > Can we introduce some kind of device-independent config space area?
> > Pushing back the device-specific config space by a certain value if the
> > appropriate feature is negotiated and use that for things like the uuid?
>
> So config moves back and forth?
> Reminds me of the msi vector mess we had with pci.
Yes, that would be a bit unfortunate.
> I'd rather have every transport add a new config.
You mean via different mechanisms?
>
> > But regardless of that, I'm not sure whether extending this approach to
> > other device types is the way to go. Tying together two different
> > devices is creating complicated situations at least in the hypervisor
> > (even if it's fairly straightforward in the guest). [I have not come
> > around again to look at the "how to handle visibility in QEMU"
> > questions due to lack of cycles, sorry about that.]
> >
> > So, what's the goal of this approach? Only to allow migration with
> > vfio-pci, or also to plug in a faster device and use it instead of an
> > already attached paravirtualized device?
>
> These are two sides of the same coin, I think the second approach
> is closer to what we are doing here.
Thinking about it, do we need any knob to keep the vfio device
invisible if the virtio device is not present? IOW, how does the
hypervisor know that the vfio device is supposed to be paired with a
virtio device? It seems we need an explicit tie-in.
>
> > What about migration of vfio devices that are not easily replaced by a
> > paravirtualized device? I'm thinking of vfio-ccw, where our main (and
> > currently only) supported device is dasd (disks) -- which can do a lot
> > of specialized things that virtio-blk does not support (and should not
> > or even cannot support).
>
> But maybe virtio-scsi can?
I don't think so. Dasds have some channel commands that don't map
easily to scsi commands.
>
> > Would it be more helpful to focus on generic
> > migration support for vfio instead of going about it device by device?
> >
> > This network device approach already seems far along, so it makes sense
> > to continue with it. But I'm not sure whether we want to spend time and
> > energy on that for other device types rather than working on a general
> > solution for vfio migration.
>
> I'm inclined to say finalizing this feature would be a good first step
> and will teach us how we can move forward.
I'm not opposed to figuring out this one, but I'm not sure whether we
want to extend it to more device types.
Are people looking into generic migration support? I have it on my
things-to-look-at list (figuring out what needs to be device specific
and what can be generic, figuring out how we can support vfio-ccw,
etc.).
^ permalink raw reply
* RE: bnx2x: kernel panic in the bnx2x driver
From: Kalluru, Sudarsana @ 2018-06-25 9:20 UTC (permalink / raw)
To: Vishwanath Pai, Elior, Ariel, Dept-Eng Everest Linux L2
Cc: davem@davemloft.net, netdev@vger.kernel.org, dbanerje@akamai.com,
pai.vishwain@gmail.com
In-Reply-To: <20180622182738.GA13219@akamai.com>
Hi Vishwanath,
Thanks for your help. Will plan to post the patch to net branch.
Thanks,
Sudarsana
-----Original Message-----
From: Vishwanath Pai [mailto:vpai@akamai.com]
Sent: 22 June 2018 23:58
To: Kalluru, Sudarsana <Sudarsana.Kalluru@cavium.com>; Elior, Ariel <Ariel.Elior@cavium.com>; Dept-Eng Everest Linux L2 <Dept-EngEverestLinuxL2@cavium.com>
Cc: davem@davemloft.net; netdev@vger.kernel.org; dbanerje@akamai.com; pai.vishwain@gmail.com
Subject: Re: bnx2x: kernel panic in the bnx2x driver
The patch below worked for me (on 4.14.51 LTS kernel):
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
index 1e33abd..2b3863a 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
@@ -3387,14 +3387,20 @@ static int bnx2x_set_rss_flags(struct bnx2x *bp, struct ethtool_rxnfc *info)
DP(BNX2X_MSG_ETHTOOL,
"rss re-configured, UDP 4-tupple %s\n",
udp_rss_requested ? "enabled" : "disabled");
- return bnx2x_rss(bp, &bp->rss_conf_obj, false, true);
+ if (bp->state == BNX2X_STATE_OPEN)
+ return bnx2x_rss(bp, &bp->rss_conf_obj, false, true);
+ else
+ return 0;
} else if ((info->flow_type == UDP_V6_FLOW) &&
(bp->rss_conf_obj.udp_rss_v6 != udp_rss_requested)) {
bp->rss_conf_obj.udp_rss_v6 = udp_rss_requested;
DP(BNX2X_MSG_ETHTOOL,
"rss re-configured, UDP 4-tupple %s\n",
udp_rss_requested ? "enabled" : "disabled");
- return bnx2x_rss(bp, &bp->rss_conf_obj, false, true);
+ if (bp->state == BNX2X_STATE_OPEN)
+ return bnx2x_rss(bp, &bp->rss_conf_obj, false, true);
+ else
+ return 0;
}
return 0;
Although I think there might be another place where we may need to fix this as well:
bnx2x_config_rss_eth()
Thanks,
Vishwanath
On 06/22/2018 10:57 AM, Vishwanath Pai wrote:
> Ah, that is great! I will test it out on my machine and let you know.
>
> Thanks,
> Vishwanath
>
> On 06/22/2018 10:21 AM, Kalluru, Sudarsana wrote:
>> Hi Vishwanath,
>> The config will be cached in the device structure (bp->rss_conf_obj.udp_rss_v4) in this scenario, and will be applied in the load path (bnx2x_nic_load() --> bnx2x_init_rss()). Have unit tested the change on my setup.
>>
>> Thanks,
>> Sudarsana
>>
>> -----Original Message-----
>> From: Vishwanath Pai [mailto:vpai@akamai.com]
>> Sent: 22 June 2018 18:52
>> To: Kalluru, Sudarsana <Sudarsana.Kalluru@cavium.com>; Elior, Ariel
>> <Ariel.Elior@cavium.com>; Dept-Eng Everest Linux L2
>> <Dept-EngEverestLinuxL2@cavium.com>
>> Cc: davem@davemloft.net; netdev@vger.kernel.org; dbanerje@akamai.com;
>> pai.vishwain@gmail.com
>> Subject: Re: bnx2x: kernel panic in the bnx2x driver
>>
>> Hi Sudarsana,
>>
>> Thanks for taking a look at my email. The fix you suggested would definitely fix the kernel panic, but at the same time wouldn't it also silently ignore the request by ethtool to set rx-flow-hash?
>>
>> Thanks,
>> Vishwanath
>>
>> On 06/22/2018 06:20 AM, Kalluru, Sudarsana wrote:
>>> Hi Vishwanath,
>>> Thanks for your mail, and the analysis.
>>> The fix would be to invoke bnx2x_rss() only when the device is opened,
>>> if (bp->state == BNX2X_STATE_OPEN)
>>> return bnx2x_rss(bp, &bp->rss_conf_obj, false, true);
>>> else
>>> return 0;
>>> Ariel,
>>> Could you please review the path (bnx2x_set_rss_flags()--> bnx2x_rss()) and confirm/correct on the above.
>>>
>>> Thanks,
>>> Sudarsana
>>>
>>> -----Original Message-----
>>> From: Vishwanath Pai [mailto:vpai@akamai.com]
>>> Sent: 22 June 2018 10:37
>>> To: Elior, Ariel <Ariel.Elior@cavium.com>; Dept-Eng Everest Linux L2
>>> <Dept-EngEverestLinuxL2@cavium.com>
>>> Cc: davem@davemloft.net; netdev@vger.kernel.org;
>>> dbanerje@akamai.com; pai.vishwain@gmail.com
>>> Subject: bnx2x: kernel panic in the bnx2x driver
>>>
>>> External Email
>>>
>>> Hi,
>>>
>>> We recently noticed a kernel panic in the bnx2x driver when trying
>>> to set rx-flow-hash parameters via ethtool during if-pre-up.d. I am
>>> running kernel
>>> v4.17.2 from ubuntu-mainline-ppa. I have added the stack trace below:
>>>
>>> [ 18.280209] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
>>> [ 18.280212] PGD 8000000407a79067 P4D 8000000407a79067 PUD 40ce8a067 PMD 0
>>> [ 18.280214] Oops: 0010 [#1] SMP PTI
>>> [ 18.280215] Modules linked in: intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel joydev input_led kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc hid_eneric aesni_intel gpio_ich aes_x86_64 usbhid lpc_ich crpto_simd ie31200_edac cryptd glue_helper intel_cstate mac_hid intel_rapl_perf bnx2x mdio tcp_bbr netconsole ipmi_devintf ipmi_msghandler i2c_i801 coretemp autofs4 raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 multipath linear sha26_mb mcryptd sha256_ssse3 hid ast i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt mpt3sas fb_sys_fops drm raid_class scsi_transport_sas ahci libahci shpchp video
>>> [ 18.280241] CPU: 6 PID: 1081 Comm: ethtool Not tainted 4.17.2-041702-generic #201806160433
>>> [ 18.280242] Hardware name: Foxconn CangJie/CangJie, BIOS CC1F108D 02/26/2014
>>> [ 18.280243] RIP: 0010: (null)
>>> [ 18.280243] RSP: 0018:ffffb84bc260b9c0 EFLAGS: 00010246
>>> [ 18.280244] RAX: 0000000000000000 RBX: ffff92f987f020f0 RCX: 0000000000000000
>>> [ 18.280245] RDX: 0000000000000000 RSI: ffffb84bc260b9f8 RDI: ffff92f987f020f0
>>> [ 18.280245] RBP: ffffb8bc260b9e8 R08: 0000000000000001 R09: 0000000000000000
>>> [ 18.280246] R10: ffffb84bc260bd20 R11: 0000000000000000 R12: ffffb84bc260b9f8
>>> [ 18.280246] R13: ffff92f987f008c0 R14: 00007ffdb75bec40 R15: 0000000000000000
>>> [ 18.280247] FS: 00007fc0e8798700(0000) GS:ffff92f99fd80000(0000) knlGS:0000000000000000
>>> [ 18.280248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [ 18.280249] CR2: 0000000000000000 CR3: 0000000409b4c003 CR4: 00000000001606e0
>>> [ 18.280249] Call Trace:
>>> [ 18.280263] ? bnx2x_config_rss+0x2f/0xd0 [bnx2x]
>>> [ 18.280270] bnx2x_rss+0x1d9/0x210 [bnx2x]
>>> [ 18.280276] bnx2x_set_rxnfc+0x17d/0x380 [bnx2x]
>>> [ 18.280279] ethtool_set_rxnfc+0x9b/0x110
>>> [ 18.280281] ? __do_page_cache_readahead+0x1da/0x2c0
>>> [ 18.280283] ? security_capable+0x3c/0x60
>>> [ 18.280284] dev_ethtool+0350/0x2610
>>> [ 18.280286] ? page_cache_async_readahead+0x71/0x80
>>> [ 18.280288] ? page_add_file_rmap+0x5d/0x220
>>> [ 18.280290] ? inet_ioctl+0x182/0x1a0
>>> [ 18.280291] dev_ioctl+0x203/0x3f0
>>> [ 18.280293] ? dev_ioctl+0x203/0x3f0
>>> [ 18.280294] sock_do_ioctl+0xae/0x150
>>> [ 18.280296] sock_ioctl+0x1e2/0x330
>>> [ 18.280296] ? sock_ioctl+0x1e2/0x330
>>> [ 18.280299] do_vfs_ioctl+0xa8/0x620
>>> [ 18.280300] ? dlci_ioctl_set+0x30/0x30
>>> [ 18.280301] ? do_vfs_ioctl+0xa8/0x620
>>> [ 18.280302] ? handle_mm_fault+0xe3/0x220
>>> [ 18.280304] ksys_ioctl+0x75/0x80
>>> [ 18.280305] __x64_sys_ioctl+0x1a/0x20
>>> [ 18.280307] do_syscall_64+0x5a/0x120
>>> [ 18.280309] entry_SYSCALL_64_aftr_hwframe+0x44/0xa9
>>> [ 18.280310] RIP: 0033:0x7fc0e7fba107
>>> [ 18.280311] RSP: 002b:00007ffdb75beb78 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
>>> [ 18.280312] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc0e7fba107
>>> [ 18.280312] RDX: 00007ffdb75bed60 RSI: 0000000000008946 RDI: 0000000000000003
>>> [ 18.280313] RBP: 00007ffdb75bed50 R08: 00007ffdb75bed60 R09: 0000000000000001
>>> [ 18.280313] R10: 0000000000000541 R11: 0000000000000206 R12: 00007ffdb75beed0
>>> [ 18.280314] R13: 0000000000421020 R14: 000000000041fe28 R15: 0000000000000003
>>> [ 18.280315] Code: Bad RIP value.
>>> [ 18.280317] RIP: (null) RSP: ffffb84bc260b9c0
>>> [ 18.280318] CR2: 0000000000000000
>>> [ 18.280319] ---[ end trace 5f361db3fb9059f1 ]---
>>>
>>> To reproduce this I created a bash script in "/etc/network/if-pre-up.d/" with these two lines:
>>> ethtool -N $IFACE rx-flow-hash udp4 "sdfn"
>>> ethtool -N $IFACE rx-flow-hash udp6 "sdfn"
>>>
>>> The problem here is that rss_obj in bnx2x struct for the device
>>> hasn't been initialized yet, which causes an exception in
>>> bnx2x_config_rss() when calling "r->set_pending(r)" because
>>> r->set_pending is NULL. It looks like a lot many things haven't been
>>> initialized at this point, most of that happens in this
>>> function: "bnx2x_init_bp_objs()" which isn't called until ifup. Any thoughts on how this can be fixed? Would it be possible to safely move bnx2x_init_bp_objs() to maybe bnx2x_init_one() which runs much before ifup?
>>>
>>> Thanks,
>>> Vishwanath
>>>
>
^ permalink raw reply related
* Re: [PATCH RFT] net: dsa: Allow configuring CPU port VLANs
From: Ilias Apalodimas @ 2018-06-25 9:17 UTC (permalink / raw)
To: Petr Machata
Cc: Florian Fainelli, netdev, jiri, Andrew Lunn, Vivien Didelot,
David S. Miller, open list
In-Reply-To: <wih4lhrgrfd.fsf@dev-r-vrt-156.mtr.labs.mlnx>
On Mon, Jun 25, 2018 at 12:13:10PM +0300, Petr Machata wrote:
> Florian Fainelli <f.fainelli@gmail.com> writes:
>
> > if (netif_is_bridge_master(vlan->obj.orig_dev))
> > - return -EOPNOTSUPP;
> > + info.port = dp->cpu_dp->index;
>
> The condition above will trigger also when a VLAN is added on a member
> port, and there's no other port with that VLAN. In that case the VLAN
> comes without the BRIDGE_VLAN_INFO_BRENTRY flag. In mlxsw we have this
> to get the bridge VLANs:
>
> if (netif_is_bridge_master(orig_dev)) {
> [...]
> if ((vlan->flags & BRIDGE_VLAN_INFO_BRENTRY) &&
> [...]
>
> This doesn't appear to be done in DSA unless I'm missing something.
Petr's right. This will trigger for VLANs added on 'not cpu ports' if the VLAN
is not already a member.
This command has BRIDGE_VLAN_INFO_BRENTRY set:
bridge vlan add dev br0 vid 100 pvid untagged self
I had the same issue on my CPSW RFC and solved it
exactly the same was as Petr suggested.
>
> Thanks,
> Petr
Regards
Ilias
^ permalink raw reply
* Re: [PATCH net-next] route: add support for directed broadcast forwarding
From: Xin Long @ 2018-06-25 9:15 UTC (permalink / raw)
To: Ido Schimmel; +Cc: network dev, davem, David Ahern
In-Reply-To: <20180625090956.GA19457@splinter.mtl.com>
On Mon, Jun 25, 2018 at 5:09 PM, Ido Schimmel <idosch@idosch.org> wrote:
> Hi Xin,
>
> On Mon, Jun 25, 2018 at 10:45:08AM +0800, Xin Long wrote:
>> This patch implements the feature described in rfc1812#section-5.3.5.2
>> and rfc2644. It allows the router to forward directed broadcast when
>> sysctl mc_forwarding is enabled.
>
> You mean bc_forwarding?
yes, typo, bc_forwarding.
>
>>
>> Note that this feature could be done by iptables -j TEE, but it would
>> cause some problems:
>> - target TEE's gateway param has to be set with a specific address,
>> and it's not flexible especially when the route wants forward all
>> directed broadcasts.
>> - this duplicates the directed broadcasts so this may cause side
>> effects to applications.
>>
>> Besides, to keep consistent with other os router like BSD, it's also
>> necessary to implement it in the route rx path.
>
> Regarding the test you posted later in the thread, did you consider
> adding it as part of tools/testing/selftests/net/forwarding/ ? I believe
> you can write the test using VRFs instead of name spaces.
didn't know that, but sounds good, will have a try. :)
Thanks.
>
> Thanks
^ permalink raw reply
* Re: [PATCH RFT] net: dsa: Allow configuring CPU port VLANs
From: Petr Machata @ 2018-06-25 9:13 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, jiri, ilias.apalodimas, Andrew Lunn, Vivien Didelot,
David S. Miller, open list
In-Reply-To: <20180624153339.13572-1-f.fainelli@gmail.com>
Florian Fainelli <f.fainelli@gmail.com> writes:
> if (netif_is_bridge_master(vlan->obj.orig_dev))
> - return -EOPNOTSUPP;
> + info.port = dp->cpu_dp->index;
The condition above will trigger also when a VLAN is added on a member
port, and there's no other port with that VLAN. In that case the VLAN
comes without the BRIDGE_VLAN_INFO_BRENTRY flag. In mlxsw we have this
to get the bridge VLANs:
if (netif_is_bridge_master(orig_dev)) {
[...]
if ((vlan->flags & BRIDGE_VLAN_INFO_BRENTRY) &&
[...]
This doesn't appear to be done in DSA unless I'm missing something.
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH net-next] route: add support for directed broadcast forwarding
From: Xin Long @ 2018-06-25 9:13 UTC (permalink / raw)
To: network dev; +Cc: davem, David Ahern, Davide Caratti
In-Reply-To: <671e900d14a124f1de7785ee44c437d0826b9e2a.1529894708.git.lucien.xin@gmail.com>
On Mon, Jun 25, 2018 at 10:45 AM, Xin Long <lucien.xin@gmail.com> wrote:
> This patch implements the feature described in rfc1812#section-5.3.5.2
> and rfc2644. It allows the router to forward directed broadcast when
> sysctl mc_forwarding is enabled.
>
> Note that this feature could be done by iptables -j TEE, but it would
> cause some problems:
> - target TEE's gateway param has to be set with a specific address,
> and it's not flexible especially when the route wants forward all
> directed broadcasts.
> - this duplicates the directed broadcasts so this may cause side
> effects to applications.
>
> Besides, to keep consistent with other os router like BSD, it's also
> necessary to implement it in the route rx path.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> include/linux/inetdevice.h | 1 +
> include/uapi/linux/ip.h | 1 +
> include/uapi/linux/netconf.h | 1 +
> net/ipv4/devinet.c | 7 +++++++
> net/ipv4/route.c | 6 +++++-
> 5 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
> index 27650f1..c759d1c 100644
> --- a/include/linux/inetdevice.h
> +++ b/include/linux/inetdevice.h
> @@ -93,6 +93,7 @@ static inline void ipv4_devconf_setall(struct in_device *in_dev)
>
> #define IN_DEV_FORWARD(in_dev) IN_DEV_CONF_GET((in_dev), FORWARDING)
> #define IN_DEV_MFORWARD(in_dev) IN_DEV_ANDCONF((in_dev), MC_FORWARDING)
> +#define IN_DEV_BFORWARD(in_dev) IN_DEV_ANDCONF((in_dev), BC_FORWARDING)
> #define IN_DEV_RPFILTER(in_dev) IN_DEV_MAXCONF((in_dev), RP_FILTER)
> #define IN_DEV_SRC_VMARK(in_dev) IN_DEV_ORCONF((in_dev), SRC_VMARK)
> #define IN_DEV_SOURCE_ROUTE(in_dev) IN_DEV_ANDCONF((in_dev), \
> diff --git a/include/uapi/linux/ip.h b/include/uapi/linux/ip.h
> index b24a742..2b756b5 100644
> --- a/include/uapi/linux/ip.h
> +++ b/include/uapi/linux/ip.h
> @@ -139,6 +139,7 @@ enum
> {
> IPV4_DEVCONF_FORWARDING=1,
> IPV4_DEVCONF_MC_FORWARDING,
> + IPV4_DEVCONF_BC_FORWARDING,
> IPV4_DEVCONF_PROXY_ARP,
> IPV4_DEVCONF_ACCEPT_REDIRECTS,
> IPV4_DEVCONF_SECURE_REDIRECTS,
> diff --git a/include/uapi/linux/netconf.h b/include/uapi/linux/netconf.h
> index c84fcdf..a5cd70e 100644
> --- a/include/uapi/linux/netconf.h
> +++ b/include/uapi/linux/netconf.h
> @@ -15,6 +15,7 @@ enum {
> NETCONFA_FORWARDING,
> NETCONFA_RP_FILTER,
> NETCONFA_MC_FORWARDING,
> + NETCONFA_BC_FORWARDING,
> NETCONFA_PROXY_NEIGH,
> NETCONFA_IGNORE_ROUTES_WITH_LINKDOWN,
> NETCONFA_INPUT,
As Davide Caratti noticed, this breaks UAPI, I will append it instead
in next version if the rest part is ok. Thanks Davide.
> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
> index d7585ab..ea30ab6 100644
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c
> @@ -1827,6 +1827,8 @@ static int inet_netconf_msgsize_devconf(int type)
> size += nla_total_size(4);
> if (all || type == NETCONFA_MC_FORWARDING)
> size += nla_total_size(4);
> + if (all || type == NETCONFA_BC_FORWARDING)
> + size += nla_total_size(4);
> if (all || type == NETCONFA_PROXY_NEIGH)
> size += nla_total_size(4);
> if (all || type == NETCONFA_IGNORE_ROUTES_WITH_LINKDOWN)
> @@ -1873,6 +1875,10 @@ static int inet_netconf_fill_devconf(struct sk_buff *skb, int ifindex,
> nla_put_s32(skb, NETCONFA_MC_FORWARDING,
> IPV4_DEVCONF(*devconf, MC_FORWARDING)) < 0)
> goto nla_put_failure;
> + if ((all || type == NETCONFA_BC_FORWARDING) &&
> + nla_put_s32(skb, NETCONFA_BC_FORWARDING,
> + IPV4_DEVCONF(*devconf, BC_FORWARDING)) < 0)
> + goto nla_put_failure;
> if ((all || type == NETCONFA_PROXY_NEIGH) &&
> nla_put_s32(skb, NETCONFA_PROXY_NEIGH,
> IPV4_DEVCONF(*devconf, PROXY_ARP)) < 0)
> @@ -2259,6 +2265,7 @@ static struct devinet_sysctl_table {
> DEVINET_SYSCTL_COMPLEX_ENTRY(FORWARDING, "forwarding",
> devinet_sysctl_forward),
> DEVINET_SYSCTL_RO_ENTRY(MC_FORWARDING, "mc_forwarding"),
> + DEVINET_SYSCTL_RW_ENTRY(BC_FORWARDING, "bc_forwarding"),
>
> DEVINET_SYSCTL_RW_ENTRY(ACCEPT_REDIRECTS, "accept_redirects"),
> DEVINET_SYSCTL_RW_ENTRY(SECURE_REDIRECTS, "secure_redirects"),
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 1df6e97..b678466 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -1996,8 +1996,11 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
> goto no_route;
> }
>
> - if (res->type == RTN_BROADCAST)
> + if (res->type == RTN_BROADCAST) {
> + if (IN_DEV_BFORWARD(in_dev))
> + goto make_route;
> goto brd_input;
> + }
>
> if (res->type == RTN_LOCAL) {
> err = fib_validate_source(skb, saddr, daddr, tos,
> @@ -2014,6 +2017,7 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
> if (res->type != RTN_UNICAST)
> goto martian_destination;
>
> +make_route:
> err = ip_mkroute_input(skb, res, in_dev, daddr, saddr, tos, flkeys);
> out: return err;
>
> --
> 2.1.0
>
^ permalink raw reply
* Re: [PATCH net-next] route: add support for directed broadcast forwarding
From: Ido Schimmel @ 2018-06-25 9:09 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, davem, David Ahern
In-Reply-To: <671e900d14a124f1de7785ee44c437d0826b9e2a.1529894708.git.lucien.xin@gmail.com>
Hi Xin,
On Mon, Jun 25, 2018 at 10:45:08AM +0800, Xin Long wrote:
> This patch implements the feature described in rfc1812#section-5.3.5.2
> and rfc2644. It allows the router to forward directed broadcast when
> sysctl mc_forwarding is enabled.
You mean bc_forwarding?
>
> Note that this feature could be done by iptables -j TEE, but it would
> cause some problems:
> - target TEE's gateway param has to be set with a specific address,
> and it's not flexible especially when the route wants forward all
> directed broadcasts.
> - this duplicates the directed broadcasts so this may cause side
> effects to applications.
>
> Besides, to keep consistent with other os router like BSD, it's also
> necessary to implement it in the route rx path.
Regarding the test you posted later in the thread, did you consider
adding it as part of tools/testing/selftests/net/forwarding/ ? I believe
you can write the test using VRFs instead of name spaces.
Thanks
^ permalink raw reply
* Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1
From: Daniel Borkmann @ 2018-06-25 8:48 UTC (permalink / raw)
To: Peter Robinson, Eric Dumazet; +Cc: netdev, linux-arm-kernel, labbott
In-Reply-To: <CALeDE9Nkz+cbueruiez_43ZS1ebAiQHDaVZRARE8raypYz323A@mail.gmail.com>
On 06/24/2018 11:24 AM, Peter Robinson wrote:
>>> I'm seeing this netlink/sk_filter_trim_cap crash on ARMv7 across quite
>>> a few ARMv7 platforms on Fedora with 4.18rc1. I've tested RPi2/RPi3
>>> (doesn't happen on aarch64), AllWinner H3, BeagleBone and a few
>>> others, both LPAE/normal kernels.
>>>
>>> I'm a bit out of my depth in this part of the kernel but I'm wondering
>>> if it's known, I couldn't find anything that looked obvious on a few
>>> mailing lists.
>>>
>>> Peter
>>
>> Hi Peter
>>
>> Could you provide symbolic information ?
>
> I passed in through scripts/decode_stacktrace.sh is that what you were after:
>
> [ 8.673880] Internal error: Oops: a06 [#10] SMP ARM
> [ 8.673949] ---[ end trace 049df4786ea3140a ]---
> [ 8.678754] Modules linked in:
> [ 8.678766] CPU: 1 PID: 206 Comm: systemd-udevd Tainted: G D
> 4.18.0-0.rc1.git0.1.fc29.armv7hl+lpae #1
> [ 8.678769] Hardware name: Allwinner sun8i Family
> [ 8.678781] PC is at sk_filter_trim_cap ()
> [ 8.678790] LR is at (null)
> [ 8.709463] pc : lr : psr: 60000013 ()
> [ 8.715722] sp : c996bd60 ip : 00000000 fp : 00000000
> [ 8.720939] r10: ee79dc00 r9 : c12c9f80 r8 : 00000000
> [ 8.726157] r7 : 00000000 r6 : 00000001 r5 : f1648000 r4 : 00000000
> [ 8.732674] r3 : 00000007 r2 : 00000000 r1 : 00000000 r0 : 00000000
> [ 8.739193] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> [ 8.746318] Control: 30c5387d Table: 6e7bc880 DAC: ffe75ece
> [ 8.752055] Process systemd-udevd (pid: 206, stack limit = 0x(ptrval))
> [ 8.758574] Stack: (0xc996bd60 to 0xc996c000)
[...]
Should be fixed by (PR to Linus with fix is pending):
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=9262478220eac908ae6e168c3df2c453c87e2da3
Sorry for that,
Daniel
^ permalink raw reply
* Re: [PATCH rdma-next 09/12] RDMA/mlx5: Fix shift overflow in mlx5_ib_create_wq
From: Leon Romanovsky @ 2018-06-25 8:10 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Hadar Hen Zion, Matan Barak,
Michael J Ruhl, Noa Osherovich, Raed Salem, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180624195624.GL19151@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 2911 bytes --]
On Sun, Jun 24, 2018 at 01:56:24PM -0600, Jason Gunthorpe wrote:
> On Sun, Jun 24, 2018 at 11:23:50AM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > [ 61.182439] UBSAN: Undefined behaviour in drivers/infiniband/hw/mlx5/qp.c:5366:34
> > [ 61.183673] shift exponent 4294967288 is too large for 32-bit type 'unsigned int'
> > [ 61.185530] CPU: 0 PID: 639 Comm: qp Not tainted 4.18.0-rc1-00037-g4aa1d69a9c60-dirty #96
> > [ 61.186981] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014
> > [ 61.188315] Call Trace:
> > [ 61.188661] dump_stack+0xc7/0x13b
> > [ 61.190427] ubsan_epilogue+0x9/0x49
> > [ 61.190899] __ubsan_handle_shift_out_of_bounds+0x1ea/0x22f
> > [ 61.197040] mlx5_ib_create_wq+0x1c99/0x1d50
> > [ 61.206632] ib_uverbs_ex_create_wq+0x499/0x820
> > [ 61.213892] ib_uverbs_write+0x77e/0xae0
> > [ 61.248018] vfs_write+0x121/0x3b0
> > [ 61.249831] ksys_write+0xa1/0x120
> > [ 61.254024] do_syscall_64+0x7c/0x2a0
> > [ 61.256178] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > [ 61.259211] RIP: 0033:0x7f54bab70e99
> > [ 61.262125] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89
> > [ 61.268678] RSP: 002b:00007ffe1541c318 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
> > [ 61.271076] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f54bab70e99
> > [ 61.273795] RDX: 0000000000000070 RSI: 0000000020000240 RDI: 0000000000000003
> > [ 61.276982] RBP: 00007ffe1541c330 R08: 00000000200078e0 R09: 0000000000000002
> > [ 61.280035] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004005c0
> > [ 61.283279] R13: 00007ffe1541c420 R14: 0000000000000000 R15: 0000000000000000
> >
> > Cc: <stable@vger.kernel.org> # 4.7
> > Fixes: 79b20a6c3014 ("IB/mlx5: Add receive Work Queue verbs")
> > Cc: syzkaller <syzkaller@googlegroups.com>
> > Reported-by: Noa Osherovich <noaos@mellanox.com>
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > drivers/infiniband/hw/mlx5/qp.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
> > index 6034a670859f..8e40263fd40e 100644
> > +++ b/drivers/infiniband/hw/mlx5/qp.c
> > @@ -5377,7 +5377,11 @@ static int set_user_rq_size(struct mlx5_ib_dev *dev,
> >
> > rwq->wqe_count = ucmd->rq_wqe_count;
> > rwq->wqe_shift = ucmd->rq_wqe_shift;
> > - rwq->buf_size = (rwq->wqe_count << rwq->wqe_shift);
> > + rwq->buf_size =
> > + shift_overflow((size_t)rwq->wqe_count, (size_t)rwq->wqe_shift);
>
> The casts are redundant, the function argument is already size_t so
> implicit promotion is guaranteed.
rwq->wqe_count and rwq->wqe_shift are declared as u32 and not as size_t.
https://elixir.bootlin.com/linux/latest/source/drivers/infiniband/hw/mlx5/mlx5_ib.h#L296
Thanks
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH rdma-next 06/12] RDMA/uverbs: Don't overwrite NULL pointer with ZERO_SIZE_PTR
From: Leon Romanovsky @ 2018-06-25 8:08 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Hadar Hen Zion, Matan Barak,
Michael J Ruhl, Noa Osherovich, Raed Salem, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180624195751.GM19151@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 877 bytes --]
On Sun, Jun 24, 2018 at 01:57:51PM -0600, Jason Gunthorpe wrote:
> On Sun, Jun 24, 2018 at 11:23:47AM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > Number of specs is provided by user and in valid case can be equal to zero.
> > Such argument causes to call to kcalloc() with zero-length request and in
> > return the ZERO_SIZE_PTR is assigned. This pointer is different from NULL
> > and makes various if (..) checks to success.
>
> The one seems really weird. There is nothing wrong with ZERO_SIZE_PTR,
> but this description and fix suggest that something did
>
> ptr = kalloc(0);
> ptr[0] = ...;
>
> Which is not allowed of course. Doesn't this mean there is also a
> missing range check someplace?
I don't know, this issue was found during code review of
ib_uvrebs_ex_create_flow(), may or may not be real issue.
Thanks
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] igb: allow optionally getting mac address from device tree
From: David Miller @ 2018-06-25 8:05 UTC (permalink / raw)
To: marcel
Cc: netdev, intel-wired-lan, jeffrey.t.kirsher, marcel.ziswiler,
linux-kernel
In-Reply-To: <20180625080042.32286-1-marcel@ziswiler.com>
From: Marcel Ziswiler <marcel@ziswiler.com>
Date: Mon, 25 Jun 2018 10:00:42 +0200
> @@ -3122,7 +3124,11 @@ static int igb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> break;
> }
>
> - if (eth_platform_get_mac_address(&pdev->dev, hw->mac.addr)) {
> + /* try to get the MAC address from device tree data */
> + iap = of_get_mac_address(pdev->dev.of_node);
> + if (iap)
> + memcpy(hw->mac.addr, iap, ETH_ALEN);
This is exactly what eth_platform_get_mac_address() shoule be doing.
^ permalink raw reply
* [PATCH] net: usb: asix: allow optionally getting mac address from device tree
From: Marcel Ziswiler @ 2018-06-25 8:01 UTC (permalink / raw)
To: netdev
Cc: Oliver Neukum, Marcel Ziswiler, linux-usb, David S. Miller,
Dean Jenkins, linux-kernel, Andrey Konovalov
From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
For Embedded use where e.g. AX88772B chips may be used without external
EEPROMs the boot loader may choose to pass the MAC address to be used
via device tree. Therefore, allow for optionally getting the MAC
address from device tree data e.g. as follows (excerpt from a T30 based
board, local-mac-address to be filled in by boot loader):
/* EHCI instance 1: USB2_DP/N -> AX88772B */
usb@7d004000 {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
asix@1 {
reg = <1>;
local-mac-address = [00 00 00 00 00 00];
};
};
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
drivers/net/usb/asix.h | 1 +
drivers/net/usb/asix_devices.c | 39 ++++++++++++++++++++++++---------------
2 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/drivers/net/usb/asix.h b/drivers/net/usb/asix.h
index 9a4171b90947..c8161960cef2 100644
--- a/drivers/net/usb/asix.h
+++ b/drivers/net/usb/asix.h
@@ -37,6 +37,7 @@
#include <linux/usb/usbnet.h>
#include <linux/slab.h>
#include <linux/if_vlan.h>
+#include <linux/of_net.h>
#define DRIVER_VERSION "22-Dec-2011"
#define DRIVER_NAME "asix"
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index 3d4f7959dabb..a88d65dfc64c 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -690,25 +690,34 @@ static int ax88772_bind(struct usbnet *dev, struct usb_interface *intf)
u8 buf[ETH_ALEN], chipcode = 0;
u32 phyid;
struct asix_common_private *priv;
+ const u8 *mac_addr;
- usbnet_get_endpoints(dev,intf);
+ usbnet_get_endpoints(dev, intf);
- /* Get the MAC address */
- if (dev->driver_info->data & FLAG_EEPROM_MAC) {
- for (i = 0; i < (ETH_ALEN >> 1); i++) {
- ret = asix_read_cmd(dev, AX_CMD_READ_EEPROM, 0x04 + i,
- 0, 2, buf + i * 2, 0);
- if (ret < 0)
- break;
- }
+ /* Maybe the boot loader passed the MAC address via device tree */
+ mac_addr = of_get_mac_address(dev->udev->dev.of_node);
+ if (mac_addr) {
+ memcpy(buf, mac_addr, ETH_ALEN);
} else {
- ret = asix_read_cmd(dev, AX_CMD_READ_NODE_ID,
- 0, 0, ETH_ALEN, buf, 0);
- }
+ /* Try getting the MAC address from EEPROM */
+ if (dev->driver_info->data & FLAG_EEPROM_MAC) {
+ for (i = 0; i < (ETH_ALEN >> 1); i++) {
+ ret = asix_read_cmd(dev, AX_CMD_READ_EEPROM,
+ 0x04 + i, 0, 2, buf + i * 2,
+ 0);
+ if (ret < 0)
+ break;
+ }
+ } else {
+ ret = asix_read_cmd(dev, AX_CMD_READ_NODE_ID,
+ 0, 0, ETH_ALEN, buf, 0);
+ }
- if (ret < 0) {
- netdev_dbg(dev->net, "Failed to read MAC address: %d\n", ret);
- return ret;
+ if (ret < 0) {
+ netdev_dbg(dev->net, "Failed to read MAC address: %d\n",
+ ret);
+ return ret;
+ }
}
asix_set_netdev_dev_addr(dev, buf);
--
2.14.4
^ permalink raw reply related
* [PATCH] igb: allow optionally getting mac address from device tree
From: Marcel Ziswiler @ 2018-06-25 8:00 UTC (permalink / raw)
To: netdev
Cc: intel-wired-lan, Jeff Kirsher, Marcel Ziswiler, David S. Miller,
linux-kernel
From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
For Embedded use where e.g. i210/i211 chips may be used without
external EEPROMs but regardless of whether or not the MAC address is
actually programmed into the iNVM the boot loader may choose to pass
the MAC address to be used via device tree. Therefore, allow for
optionally getting the MAC address from device tree data e.g. as
follows (excerpt from a TK1 based board, local-mac-address to be
filled in by boot loader):
pcie@1003000 {
...
/* I210 Gigabit Ethernet Controller */
pci@2,0 {
...
status = "okay";
pcie@0 {
reg = <0 0 0 0 0>;
local-mac-address = [00 00 00 00 00 00];
};
};
};
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index f707709969ac..0abf3698b05c 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -37,6 +37,7 @@
#include <linux/dca.h>
#endif
#include <linux/i2c.h>
+#include <linux/of_net.h>
#include "igb.h"
#define MAJ 5
@@ -2931,6 +2932,7 @@ static int igb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
const struct e1000_info *ei = igb_info_tbl[ent->driver_data];
int err, pci_using_dac;
u8 part_str[E1000_PBANUM_LENGTH];
+ const void *iap;
/* Catch broken hardware that put the wrong VF device ID in
* the PCIe SR-IOV capability.
@@ -3122,7 +3124,11 @@ static int igb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
break;
}
- if (eth_platform_get_mac_address(&pdev->dev, hw->mac.addr)) {
+ /* try to get the MAC address from device tree data */
+ iap = of_get_mac_address(pdev->dev.of_node);
+ if (iap)
+ memcpy(hw->mac.addr, iap, ETH_ALEN);
+ else if (eth_platform_get_mac_address(&pdev->dev, hw->mac.addr)) {
/* copy the MAC address out of the NVM */
if (hw->mac.ops.read_mac_addr(hw))
dev_err(&pdev->dev, "NVM Read Error\n");
--
2.14.4
^ permalink raw reply related
* [PATCH net-next 6/6] selftests: forwarding: Test routed bridge interface
From: Ido Schimmel @ 2018-06-25 7:48 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, petrm, mlxsw, Ido Schimmel
In-Reply-To: <20180625074818.17073-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Add test for cases where bridge itself acts as a router interface, with
front panel port attached to the bridge in question.
In the first test (router_bridge.sh), VLAN memberships are not
configured in any way, and everything uses default PVID of 1. Thus
traffic in $h1 and $h2 is untagged. This test ensures that the previous
patches didn't break a currently working scenario.
In the second test (router_bridge_vlan.sh), a VLAN 555 pvid untagged is
added to the bridge CPU port, with that VLAN leaving the bridge tagged
through its sole member port. The traffic is therefore expected to come
out tagged at $h1. This tests the fix introduced in the previous
patches.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
.../selftests/net/forwarding/router_bridge.sh | 113 ++++++++++++++++++
.../selftests/net/forwarding/router_bridge_vlan.sh | 132 +++++++++++++++++++++
2 files changed, 245 insertions(+)
create mode 100755 tools/testing/selftests/net/forwarding/router_bridge.sh
create mode 100755 tools/testing/selftests/net/forwarding/router_bridge_vlan.sh
diff --git a/tools/testing/selftests/net/forwarding/router_bridge.sh b/tools/testing/selftests/net/forwarding/router_bridge.sh
new file mode 100755
index 000000000000..ebc596a272f7
--- /dev/null
+++ b/tools/testing/selftests/net/forwarding/router_bridge.sh
@@ -0,0 +1,113 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+ALL_TESTS="
+ ping_ipv4
+ ping_ipv6
+"
+NUM_NETIFS=4
+source lib.sh
+
+h1_create()
+{
+ simple_if_init $h1 192.0.2.1/28 2001:db8:1::1/64
+ ip -4 route add 192.0.2.128/28 vrf v$h1 nexthop via 192.0.2.2
+ ip -6 route add 2001:db8:2::/64 vrf v$h1 nexthop via 2001:db8:1::2
+}
+
+h1_destroy()
+{
+ ip -6 route del 2001:db8:2::/64 vrf v$h1
+ ip -4 route del 192.0.2.128/28 vrf v$h1
+ simple_if_fini $h1 192.0.2.1/28 2001:db8:1::1/64
+}
+
+h2_create()
+{
+ simple_if_init $h2 192.0.2.130/28 2001:db8:2::2/64
+ ip -4 route add 192.0.2.0/28 vrf v$h2 nexthop via 192.0.2.129
+ ip -6 route add 2001:db8:1::/64 vrf v$h2 nexthop via 2001:db8:2::1
+}
+
+h2_destroy()
+{
+ ip -6 route del 2001:db8:1::/64 vrf v$h2
+ ip -4 route del 192.0.2.0/28 vrf v$h2
+ simple_if_fini $h2 192.0.2.130/28 2001:db8:2::2/64
+}
+
+router_create()
+{
+ ip link add name br1 type bridge vlan_filtering 1
+ ip link set dev br1 up
+
+ ip link set dev $swp1 master br1
+ ip link set dev $swp1 up
+ __addr_add_del br1 add 192.0.2.2/28 2001:db8:1::2/64
+
+ ip link set dev $swp2 up
+ __addr_add_del $swp2 add 192.0.2.129/28 2001:db8:2::1/64
+}
+
+router_destroy()
+{
+ __addr_add_del $swp2 del 192.0.2.129/28 2001:db8:2::1/64
+ ip link set dev $swp2 down
+
+ __addr_add_del br1 del 192.0.2.2/28 2001:db8:1::2/64
+ ip link set dev $swp1 down
+ ip link set dev $swp1 nomaster
+
+ ip link del dev br1
+}
+
+setup_prepare()
+{
+ h1=${NETIFS[p1]}
+ swp1=${NETIFS[p2]}
+
+ swp2=${NETIFS[p3]}
+ h2=${NETIFS[p4]}
+
+ vrf_prepare
+
+ h1_create
+ h2_create
+
+ router_create
+
+ forwarding_enable
+}
+
+cleanup()
+{
+ pre_cleanup
+
+ forwarding_restore
+
+ router_destroy
+
+ h2_destroy
+ h1_destroy
+
+ vrf_cleanup
+}
+
+ping_ipv4()
+{
+ ping_test $h1 192.0.2.130
+}
+
+ping_ipv6()
+{
+ ping6_test $h1 2001:db8:2::2
+}
+
+trap cleanup EXIT
+
+setup_prepare
+setup_wait
+
+tests_run
+
+exit $EXIT_STATUS
diff --git a/tools/testing/selftests/net/forwarding/router_bridge_vlan.sh b/tools/testing/selftests/net/forwarding/router_bridge_vlan.sh
new file mode 100755
index 000000000000..fef88eb4b873
--- /dev/null
+++ b/tools/testing/selftests/net/forwarding/router_bridge_vlan.sh
@@ -0,0 +1,132 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+ALL_TESTS="
+ ping_ipv4
+ ping_ipv6
+ vlan
+"
+NUM_NETIFS=4
+source lib.sh
+
+h1_create()
+{
+ simple_if_init $h1
+ vlan_create $h1 555 v$h1 192.0.2.1/28 2001:db8:1::1/64
+ ip -4 route add 192.0.2.128/28 vrf v$h1 nexthop via 192.0.2.2
+ ip -6 route add 2001:db8:2::/64 vrf v$h1 nexthop via 2001:db8:1::2
+}
+
+h1_destroy()
+{
+ ip -6 route del 2001:db8:2::/64 vrf v$h1
+ ip -4 route del 192.0.2.128/28 vrf v$h1
+ vlan_destroy $h1 555
+ simple_if_fini $h1
+}
+
+h2_create()
+{
+ simple_if_init $h2 192.0.2.130/28 2001:db8:2::2/64
+ ip -4 route add 192.0.2.0/28 vrf v$h2 nexthop via 192.0.2.129
+ ip -6 route add 2001:db8:1::/64 vrf v$h2 nexthop via 2001:db8:2::1
+}
+
+h2_destroy()
+{
+ ip -6 route del 2001:db8:1::/64 vrf v$h2
+ ip -4 route del 192.0.2.0/28 vrf v$h2
+ simple_if_fini $h2 192.0.2.130/28
+}
+
+router_create()
+{
+ ip link add name br1 type bridge vlan_filtering 1
+ ip link set dev br1 up
+
+ ip link set dev $swp1 master br1
+ ip link set dev $swp1 up
+
+ bridge vlan add dev br1 vid 555 self pvid untagged
+ bridge vlan add dev $swp1 vid 555
+
+ __addr_add_del br1 add 192.0.2.2/28 2001:db8:1::2/64
+
+ ip link set dev $swp2 up
+ __addr_add_del $swp2 add 192.0.2.129/28 2001:db8:2::1/64
+}
+
+router_destroy()
+{
+ __addr_add_del $swp2 del 192.0.2.129/28 2001:db8:2::1/64
+ ip link set dev $swp2 down
+
+ __addr_add_del br1 del 192.0.2.2/28 2001:db8:1::2/64
+ ip link set dev $swp1 down
+ ip link set dev $swp1 nomaster
+
+ ip link del dev br1
+}
+
+setup_prepare()
+{
+ h1=${NETIFS[p1]}
+ swp1=${NETIFS[p2]}
+
+ swp2=${NETIFS[p3]}
+ h2=${NETIFS[p4]}
+
+ vrf_prepare
+
+ h1_create
+ h2_create
+
+ router_create
+
+ forwarding_enable
+}
+
+cleanup()
+{
+ pre_cleanup
+
+ forwarding_restore
+
+ router_destroy
+
+ h2_destroy
+ h1_destroy
+
+ vrf_cleanup
+}
+
+vlan()
+{
+ RET=0
+
+ bridge vlan add dev br1 vid 333 self
+ check_err $? "Can't add a non-PVID VLAN"
+ bridge vlan del dev br1 vid 333 self
+ check_err $? "Can't remove a non-PVID VLAN"
+
+ log_test "vlan"
+}
+
+ping_ipv4()
+{
+ ping_test $h1 192.0.2.130
+}
+
+ping_ipv6()
+{
+ ping6_test $h1 2001:db8:2::2
+}
+
+trap cleanup EXIT
+
+setup_prepare
+setup_wait
+
+tests_run
+
+exit $EXIT_STATUS
--
2.14.4
^ permalink raw reply related
* [PATCH net-next 5/6] mlxsw: spectrum_switchdev: Ban PVID change if bridge has a RIF
From: Ido Schimmel @ 2018-06-25 7:48 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, petrm, mlxsw, Ido Schimmel
In-Reply-To: <20180625074818.17073-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
When traffic passes through a router port, it needs to be assigned a FID
for ASIC to forward correctly. For bridges, this FID used to be the one
corresponding to VLAN 1. In a previous patch, this was changed to
instead use the PVID at the time that the RIF is created. This patch
guards PVID changes after the RIF was introduced.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
.../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 47 +++++++++++++++++++++-
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index eea5666a86b2..da94e1eb9e16 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -1135,6 +1135,39 @@ mlxsw_sp_bridge_port_vlan_add(struct mlxsw_sp_port *mlxsw_sp_port,
return err;
}
+static int
+mlxsw_sp_br_ban_rif_pvid_change(struct mlxsw_sp *mlxsw_sp,
+ const struct net_device *br_dev,
+ const struct switchdev_obj_port_vlan *vlan)
+{
+ struct mlxsw_sp_rif *rif;
+ struct mlxsw_sp_fid *fid;
+ u16 pvid;
+ u16 vid;
+
+ rif = mlxsw_sp_rif_find_by_dev(mlxsw_sp, br_dev);
+ if (!rif)
+ return 0;
+ fid = mlxsw_sp_rif_fid(rif);
+ pvid = mlxsw_sp_fid_8021q_vid(fid);
+
+ for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
+ if (vlan->flags & BRIDGE_VLAN_INFO_PVID) {
+ if (vid != pvid) {
+ netdev_err(br_dev, "Can't change PVID, it's used by router interface\n");
+ return -EBUSY;
+ }
+ } else {
+ if (vid == pvid) {
+ netdev_err(br_dev, "Can't remove PVID, it's used by router interface\n");
+ return -EBUSY;
+ }
+ }
+ }
+
+ return 0;
+}
+
static int mlxsw_sp_port_vlans_add(struct mlxsw_sp_port *mlxsw_sp_port,
const struct switchdev_obj_port_vlan *vlan,
struct switchdev_trans *trans)
@@ -1146,8 +1179,18 @@ static int mlxsw_sp_port_vlans_add(struct mlxsw_sp_port *mlxsw_sp_port,
struct mlxsw_sp_bridge_port *bridge_port;
u16 vid;
- if (netif_is_bridge_master(orig_dev))
- return -EOPNOTSUPP;
+ if (netif_is_bridge_master(orig_dev)) {
+ int err = 0;
+
+ if ((vlan->flags & BRIDGE_VLAN_INFO_BRENTRY) &&
+ br_vlan_enabled(orig_dev) &&
+ switchdev_trans_ph_prepare(trans))
+ err = mlxsw_sp_br_ban_rif_pvid_change(mlxsw_sp,
+ orig_dev, vlan);
+ if (!err)
+ err = -EOPNOTSUPP;
+ return err;
+ }
if (switchdev_trans_ph_prepare(trans))
return 0;
--
2.14.4
^ permalink raw reply related
* [PATCH net-next 4/6] mlxsw: spectrum_router: Add mlxsw_sp_rif_fid()
From: Ido Schimmel @ 2018-06-25 7:48 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, petrm, mlxsw, Ido Schimmel
In-Reply-To: <20180625074818.17073-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
In order to allow querying of the VID for which a RIF was created, add
a new function that returns a FID for a given RIF.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 5 +++++
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 880092c6c94c..88bd27ace8d9 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -6122,6 +6122,11 @@ const struct net_device *mlxsw_sp_rif_dev(const struct mlxsw_sp_rif *rif)
return rif->dev;
}
+struct mlxsw_sp_fid *mlxsw_sp_rif_fid(const struct mlxsw_sp_rif *rif)
+{
+ return rif->fid;
+}
+
static struct mlxsw_sp_rif *
mlxsw_sp_rif_create(struct mlxsw_sp *mlxsw_sp,
const struct mlxsw_sp_rif_params *params,
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.h
index 5a258b1db03c..52e25695625c 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.h
@@ -77,6 +77,7 @@ u32 mlxsw_sp_ipip_dev_ul_tb_id(const struct net_device *ol_dev);
int mlxsw_sp_rif_dev_ifindex(const struct mlxsw_sp_rif *rif);
u8 mlxsw_sp_router_port(const struct mlxsw_sp *mlxsw_sp);
const struct net_device *mlxsw_sp_rif_dev(const struct mlxsw_sp_rif *rif);
+struct mlxsw_sp_fid *mlxsw_sp_rif_fid(const struct mlxsw_sp_rif *rif);
int mlxsw_sp_rif_counter_value_get(struct mlxsw_sp *mlxsw_sp,
struct mlxsw_sp_rif *rif,
enum mlxsw_sp_rif_counter_dir dir,
--
2.14.4
^ permalink raw reply related
* [PATCH net-next 3/6] mlxsw: spectrum_router: Publish mlxsw_sp_rif_find_by_dev()
From: Ido Schimmel @ 2018-06-25 7:48 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, petrm, mlxsw, Ido Schimmel
In-Reply-To: <20180625074818.17073-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
In order to guard against removal of a PVID for which a FID was
allocated, spectrum_switchdev needs to first determine whether there is
a RIF associated with a given bridge. To that end, publish a preexisting
function mlxsw_sp_rif_find_by_dev().
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 6 +-----
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.h | 2 ++
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index c7243d3f91df..880092c6c94c 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -343,10 +343,6 @@ static void mlxsw_sp_rif_counters_free(struct mlxsw_sp_rif *rif)
mlxsw_sp_rif_counter_free(mlxsw_sp, rif, MLXSW_SP_RIF_COUNTER_EGRESS);
}
-static struct mlxsw_sp_rif *
-mlxsw_sp_rif_find_by_dev(const struct mlxsw_sp *mlxsw_sp,
- const struct net_device *dev);
-
#define MLXSW_SP_PREFIX_COUNT (sizeof(struct in6_addr) * BITS_PER_BYTE + 1)
struct mlxsw_sp_prefix_usage {
@@ -5968,7 +5964,7 @@ static int mlxsw_sp_router_fib_event(struct notifier_block *nb,
return NOTIFY_DONE;
}
-static struct mlxsw_sp_rif *
+struct mlxsw_sp_rif *
mlxsw_sp_rif_find_by_dev(const struct mlxsw_sp *mlxsw_sp,
const struct net_device *dev)
{
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.h
index a01edcf56797..5a258b1db03c 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.h
@@ -66,6 +66,8 @@ struct mlxsw_sp_neigh_entry;
struct mlxsw_sp_nexthop;
struct mlxsw_sp_ipip_entry;
+struct mlxsw_sp_rif *mlxsw_sp_rif_find_by_dev(const struct mlxsw_sp *mlxsw_sp,
+ const struct net_device *dev);
struct mlxsw_sp_rif *mlxsw_sp_rif_by_index(const struct mlxsw_sp *mlxsw_sp,
u16 rif_index);
u16 mlxsw_sp_rif_index(const struct mlxsw_sp_rif *rif);
--
2.14.4
^ permalink raw reply related
* [PATCH net-next 2/6] mlxsw: spectrum_router: Allocate FID according to PVID
From: Ido Schimmel @ 2018-06-25 7:48 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, petrm, mlxsw, Ido Schimmel
In-Reply-To: <20180625074818.17073-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
For bridge netdevices, instead of assuming that the router traffic is on
VLAN 1, look at the bridge PVID.
This patch assumes that the PVID doesn't change after the router
interface is created (i.e. after the IP address is assigned).
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 05c52e486330..c7243d3f91df 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -6870,7 +6870,20 @@ static struct mlxsw_sp_fid *
mlxsw_sp_rif_vlan_fid_get(struct mlxsw_sp_rif *rif,
struct netlink_ext_ack *extack)
{
- u16 vid = is_vlan_dev(rif->dev) ? vlan_dev_vlan_id(rif->dev) : 1;
+ u16 vid;
+ int err;
+
+ if (is_vlan_dev(rif->dev)) {
+ vid = vlan_dev_vlan_id(rif->dev);
+ } else {
+ err = br_vlan_get_pvid(rif->dev, &vid);
+ if (!vid)
+ err = -EINVAL;
+ if (err) {
+ NL_SET_ERR_MSG_MOD(extack, "Couldn't determine bridge PVID");
+ return ERR_PTR(err);
+ }
+ }
return mlxsw_sp_fid_8021q_get(rif->mlxsw_sp, vid);
}
--
2.14.4
^ permalink raw reply related
* [PATCH net-next 1/6] mlxsw: spectrum_router: Propagate extack to .fid_get()
From: Ido Schimmel @ 2018-06-25 7:48 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, petrm, mlxsw, Ido Schimmel
In-Reply-To: <20180625074818.17073-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
In the follow-up patch, mlxsw_sp_rif_vlan_fid_get() will be changed in a
way that could fail. Give that function a possibility to explain the
failure through extack.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 6aaaf3d9ba31..05c52e486330 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -163,7 +163,8 @@ struct mlxsw_sp_rif_ops {
const struct mlxsw_sp_rif_params *params);
int (*configure)(struct mlxsw_sp_rif *rif);
void (*deconfigure)(struct mlxsw_sp_rif *rif);
- struct mlxsw_sp_fid * (*fid_get)(struct mlxsw_sp_rif *rif);
+ struct mlxsw_sp_fid * (*fid_get)(struct mlxsw_sp_rif *rif,
+ struct netlink_ext_ack *extack);
};
static void mlxsw_sp_lpm_tree_hold(struct mlxsw_sp_lpm_tree *lpm_tree);
@@ -6162,7 +6163,7 @@ mlxsw_sp_rif_create(struct mlxsw_sp *mlxsw_sp,
rif->ops = ops;
if (ops->fid_get) {
- fid = ops->fid_get(rif);
+ fid = ops->fid_get(rif, extack);
if (IS_ERR(fid)) {
err = PTR_ERR(fid);
goto err_fid_get;
@@ -6267,7 +6268,7 @@ mlxsw_sp_port_vlan_router_join(struct mlxsw_sp_port_vlan *mlxsw_sp_port_vlan,
}
/* FID was already created, just take a reference */
- fid = rif->ops->fid_get(rif);
+ fid = rif->ops->fid_get(rif, extack);
err = mlxsw_sp_fid_port_vid_map(fid, mlxsw_sp_port, vid);
if (err)
goto err_fid_port_vid_map;
@@ -6775,7 +6776,8 @@ static void mlxsw_sp_rif_subport_deconfigure(struct mlxsw_sp_rif *rif)
}
static struct mlxsw_sp_fid *
-mlxsw_sp_rif_subport_fid_get(struct mlxsw_sp_rif *rif)
+mlxsw_sp_rif_subport_fid_get(struct mlxsw_sp_rif *rif,
+ struct netlink_ext_ack *extack)
{
return mlxsw_sp_fid_rfid_get(rif->mlxsw_sp, rif->rif_index);
}
@@ -6865,7 +6867,8 @@ static void mlxsw_sp_rif_vlan_deconfigure(struct mlxsw_sp_rif *rif)
}
static struct mlxsw_sp_fid *
-mlxsw_sp_rif_vlan_fid_get(struct mlxsw_sp_rif *rif)
+mlxsw_sp_rif_vlan_fid_get(struct mlxsw_sp_rif *rif,
+ struct netlink_ext_ack *extack)
{
u16 vid = is_vlan_dev(rif->dev) ? vlan_dev_vlan_id(rif->dev) : 1;
@@ -6937,7 +6940,8 @@ static void mlxsw_sp_rif_fid_deconfigure(struct mlxsw_sp_rif *rif)
}
static struct mlxsw_sp_fid *
-mlxsw_sp_rif_fid_fid_get(struct mlxsw_sp_rif *rif)
+mlxsw_sp_rif_fid_fid_get(struct mlxsw_sp_rif *rif,
+ struct netlink_ext_ack *extack)
{
return mlxsw_sp_fid_8021d_get(rif->mlxsw_sp, rif->dev->ifindex);
}
--
2.14.4
^ permalink raw reply related
* [PATCH net-next 0/6] mlxsw: Support bridge router interfaces with non-default VLAN
From: Ido Schimmel @ 2018-06-25 7:48 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, petrm, mlxsw, Ido Schimmel
Petr says:
When traffic is inserted on a router interface associated with an 802.1q
bridge, the VLAN that the traffic appears on is determined by PVID of
the bridge device itself. However currently mlxsw always configures such
traffic to be forwarded to VLAN 1, regardless of the bridge PVID.
Fix the problem by modifying the FID-handling code to assign such
traffic not to FID that corresponds to VLAN 1, but to a FID that
corresponds to the configured PVID. Bail out if there is no PVID. This
is implemented in patches #1 and #2.
>From that point on, also forbid any changes to bridge device PVID,
because such changes would not be reflected. This is implemented in
patches #3, #4 and #5.
Finally in patch #6, introduce tests that use bridge as a routed
interface, and test mlxsw in both the currently-supported scenario of
using PVID 1, and the newly-supported one of using a custom PVID.
Petr Machata (6):
mlxsw: spectrum_router: Propagate extack to .fid_get()
mlxsw: spectrum_router: Allocate FID according to PVID
mlxsw: spectrum_router: Publish mlxsw_sp_rif_find_by_dev()
mlxsw: spectrum_router: Add mlxsw_sp_rif_fid()
mlxsw: spectrum_switchdev: Ban PVID change if bridge has a RIF
selftests: forwarding: Test routed bridge interface
.../net/ethernet/mellanox/mlxsw/spectrum_router.c | 42 +++++--
.../net/ethernet/mellanox/mlxsw/spectrum_router.h | 3 +
.../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 47 +++++++-
.../selftests/net/forwarding/router_bridge.sh | 113 ++++++++++++++++++
.../selftests/net/forwarding/router_bridge_vlan.sh | 132 +++++++++++++++++++++
5 files changed, 323 insertions(+), 14 deletions(-)
create mode 100755 tools/testing/selftests/net/forwarding/router_bridge.sh
create mode 100755 tools/testing/selftests/net/forwarding/router_bridge_vlan.sh
--
2.14.4
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2018-06-25 7:45 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix netpoll OOPS in r8169, from Ville Syrjälä.
2) Fix bpf instruction alignment on powerpc et al., from
Eric Dumazet.
3) Don't ignore IFLA_MTU attribute when creating new ipvlan
links. From Xin Long.
4) Fix use after free in AF_PACKET, from Eric Dumazet.
5) Mis-matched RTNL unlock in xen-netfront, from Ross
Lagerwall.
6) Fix VSOCK loopback on big-endian, from Claudio Imbrenda.
7) Missing RX buffer offset correction when computing DMA
addresses in mvneta driver, from Antoine Tenart.
8) Fix crashes in DCCP's ccid3_hc_rx_send_feedback, from Eric
Dumazet.
Please pull, thanks a lot!
The following changes since commit 1abd8a8f39cd9a2925149000056494523c85643a:
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma (2018-06-21 07:22:30 +0900)
are available in the Git repository at:
gitolite@ra.kernel.org:/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 829eb05365ff06e8adc23f2541597d0cc3c18348:
sfc: make function efx_rps_hash_bucket static (2018-06-24 23:08:25 +0900)
----------------------------------------------------------------
Aleksander Morgado (1):
qmi_wwan: add support for the Dell Wireless 5821e module
Anders Roxell (2):
selftests: net: add config fragments
selftests: net: add tcp_inq to gitignore
Antoine Tenart (3):
net: mscc: fix the injection header
net: mvneta: fix the Rx desc DMA address in the Rx path
net: mscc: make sparse happy
Bartosz Golaszewski (1):
net: davinci_emac: match the mdio device against its compatible if possible
Claudio Imbrenda (1):
VSOCK: fix loopback on big-endian systems
Colin Ian King (2):
net: ethernet: ti: davinci_cpdma: make function cpdma_desc_pool_create static
sfc: make function efx_rps_hash_bucket static
Cong Wang (1):
net_sched: remove a bogus warning in hfsc
David S. Miller (2):
Merge branch 'xen-netfront-fixes'
Merge branch 'dccp-fixes-around-rx_tstamp_last_feedback'
Eric Dumazet (4):
bpf: enforce correct alignment for instructions
net/packet: fix use-after-free
net: dccp: avoid crash in ccid3_hc_rx_send_feedback()
net: dccp: switch rx_tstamp_last_feedback to monotonic clock
Ganesh Goudar (1):
cxgb4: when disabling dcb set txq dcb priority to 0
Geert Uytterhoeven (2):
MAINTAINERS: Add file patterns for dsa device tree bindings
net: Remove depends on HAS_DMA in case of platform dependency
Hangbin Liu (1):
ipv6: mcast: fix unsolicited report interval after receiving querys
Harini Katakam (1):
net: macb: Fix ptp time adjustment for large negative delta
Jason Wang (1):
vhost_net: validate sock before trying to put its fd
Marcelo Ricardo Leitner (1):
sctp: fix erroneous inc of snmp SctpFragUsrMsgs
Matteo Croce (1):
bpfilter: fix user mode helper cross compilation
Paolo Abeni (1):
cls_flower: fix use after free in flower S/W path
Ross Lagerwall (2):
xen-netfront: Fix mismatched rtnl_unlock
xen-netfront: Update features after registering netdev
Tobin C. Harding (4):
Documentation: e100: Use correct heading adornment
Documentation: e1000: Use correct heading adornment
Documentation: e100: Fix docs build error
Documentation: e1000: Fix docs build error
Vakul Garg (2):
strparser: Don't schedule in workqueue in paused state
strparser: Corrected typo in documentation.
Ville Syrjälä (1):
r8169: Fix netpoll oops
Xin Long (1):
ipvlan: fix IFLA_MTU ignored on NEWLINK
Documentation/networking/e100.rst | 112 ++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------------
Documentation/networking/e1000.rst | 76 +++++++++++++++++++++++++++++++++---------------------------------
Documentation/networking/strparser.txt | 2 +-
MAINTAINERS | 1 +
drivers/net/ethernet/amd/Kconfig | 2 +-
drivers/net/ethernet/apm/xgene-v2/Kconfig | 1 -
drivers/net/ethernet/apm/xgene/Kconfig | 1 -
drivers/net/ethernet/arc/Kconfig | 6 ++++--
drivers/net/ethernet/broadcom/Kconfig | 2 --
drivers/net/ethernet/cadence/macb_ptp.c | 5 +----
drivers/net/ethernet/calxeda/Kconfig | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 2 +-
drivers/net/ethernet/hisilicon/Kconfig | 2 +-
drivers/net/ethernet/marvell/Kconfig | 8 +++----
drivers/net/ethernet/marvell/mvneta.c | 2 +-
drivers/net/ethernet/mellanox/mlxsw/Kconfig | 2 +-
drivers/net/ethernet/mscc/ocelot.c | 11 +++++-----
drivers/net/ethernet/realtek/r8169.c | 2 +-
drivers/net/ethernet/renesas/Kconfig | 2 --
drivers/net/ethernet/sfc/efx.c | 1 +
drivers/net/ethernet/ti/davinci_cpdma.c | 2 +-
drivers/net/ethernet/ti/davinci_emac.c | 4 ++++
drivers/net/ipvlan/ipvlan_main.c | 3 ++-
drivers/net/usb/qmi_wwan.c | 1 +
drivers/net/wireless/broadcom/brcm80211/Kconfig | 1 -
drivers/net/wireless/quantenna/qtnfmac/Kconfig | 2 +-
drivers/net/xen-netfront.c | 11 +++++-----
drivers/vhost/net.c | 3 ++-
include/linux/filter.h | 4 +++-
net/bpfilter/Makefile | 2 +-
net/dccp/ccids/ccid3.c | 16 +++++++-------
net/ipv6/mcast.c | 9 +++++---
net/packet/af_packet.c | 16 +++++++-------
net/sched/cls_flower.c | 21 +++++++++++++++----
net/sched/sch_hfsc.c | 4 ++--
net/sctp/chunk.c | 4 +++-
net/strparser/strparser.c | 5 +----
net/vmw_vsock/virtio_transport.c | 2 +-
tools/testing/selftests/net/.gitignore | 1 +
tools/testing/selftests/net/config | 2 ++
40 files changed, 190 insertions(+), 165 deletions(-)
^ permalink raw reply
* [PATCH] net/nfp: cast sizeof() to int when comparing with error code
From: Chengguang Xu @ 2018-06-25 7:33 UTC (permalink / raw)
To: jakub.kicinski, davem; +Cc: oss-drivers, netdev, Chengguang Xu
Negative error code will be larger than sizeof().
Signed-off-by: Chengguang Xu <cgxu519@gmx.com>
---
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nffw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nffw.c b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nffw.c
index cd34097b79f1..37a6d7822a38 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nffw.c
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nffw.c
@@ -232,7 +232,7 @@ struct nfp_nffw_info *nfp_nffw_info_open(struct nfp_cpp *cpp)
err = nfp_cpp_read(cpp, nfp_resource_cpp_id(state->res),
nfp_resource_address(state->res),
fwinf, sizeof(*fwinf));
- if (err < sizeof(*fwinf))
+ if (err < (int)sizeof(*fwinf))
goto err_release;
if (!nffw_res_flg_init_get(fwinf))
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next 3/5] sctp: add spp_ipv6_flowlabel and spp_dscp for sctp_paddrparams
From: David Miller @ 2018-06-25 7:31 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <adc389159b825d29f2768c61f1428d6be9105819.1529892764.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Mon, 25 Jun 2018 10:14:35 +0800
> struct sctp_paddrparams {
> @@ -773,6 +775,8 @@ struct sctp_paddrparams {
> __u32 spp_pathmtu;
> __u32 spp_sackdelay;
> __u32 spp_flags;
> + __u32 spp_ipv6_flowlabel;
> + __u8 spp_dscp;
> } __attribute__((packed, aligned(4)));
I don't think you can change the size of this structure like this.
This check in sctp_setsockopt_peer_addr_params():
if (optlen != sizeof(struct sctp_paddrparams))
return -EINVAL;
is going to trigger in old kernels when executing programs
built against the new struct definition.
^ permalink raw reply
* Re: [PATCH net-next 1/5] ipv4: add __ip_queue_xmit() that supports tos param
From: David Miller @ 2018-06-25 7:26 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <6d8aa86ce11166620c9fd4e50fdcce1baab69ab6.1529892764.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Mon, 25 Jun 2018 10:14:33 +0800
> +EXPORT_SYMBOL(__ip_queue_xmit);
> +
> +int ip_queue_xmit(struct sock *sk, struct sk_buff *skb, struct flowi *fl)
> +{
> + return __ip_queue_xmit(sk, skb, fl, inet_sk(sk)->tos);
> +}
> EXPORT_SYMBOL(ip_queue_xmit);
Maybe better to only export __ip_queue_xmit() and make ip_queue_xmit() an
inline function in net/ip.h?
^ permalink raw reply
* [PATCH 1/1] r8152: napi hangup fix after disconnect
From: Jiri Slaby @ 2018-06-25 7:26 UTC (permalink / raw)
To: davem; +Cc: linux-kernel, Jiri Slaby, linux-usb, netdev
When unplugging an r8152 adapter while the interface is UP, the NIC
becomes unusable. usb->disconnect (aka rtl8152_disconnect) deletes
napi. Then, rtl8152_disconnect calls unregister_netdev and that invokes
netdev->ndo_stop (aka rtl8152_close). rtl8152_close tries to
napi_disable, but the napi is already deleted by disconnect above. So
the first while loop in napi_disable never finishes. This results in
complete deadlock of the network layer as there is rtnl_mutex held by
unregister_netdev.
So avoid the call to napi_disable in rtl8152_close when the device is
already gone.
The other calls to usb_kill_urb, cancel_delayed_work_sync,
netif_stop_queue etc. seem to be fine. The urb and netdev is not
destroyed yet.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: linux-usb@vger.kernel.org
Cc: netdev@vger.kernel.org
---
drivers/net/usb/r8152.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c08c0d633407..1fd165090163 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3964,7 +3964,8 @@ static int rtl8152_close(struct net_device *netdev)
#ifdef CONFIG_PM_SLEEP
unregister_pm_notifier(&tp->pm_notifier);
#endif
- napi_disable(&tp->napi);
+ if (!test_bit(RTL8152_UNPLUG, &tp->flags))
+ napi_disable(&tp->napi);
clear_bit(WORK_ENABLE, &tp->flags);
usb_kill_urb(tp->intr_urb);
cancel_delayed_work_sync(&tp->schedule);
--
2.17.1
^ permalink raw reply related
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