* [PATCH net 0/2] sfc: more ARFS fixes
From: Edward Cree @ 2018-04-27 14:07 UTC (permalink / raw)
To: linux-net-drivers, David Miller; +Cc: netdev
A couple more bits of breakage in my recent ARFS and async filters work.
Patch #1 in particular fixes a bug that leads to memory trampling and
consequent crashes.
Edward Cree (2):
sfc: Use filter index rather than ID for rps_flow_id table
sfc: fix ARFS expiry check on EF10
drivers/net/ethernet/sfc/ef10.c | 5 +++--
drivers/net/ethernet/sfc/rx.c | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH net 1/2] sfc: Use filter index rather than ID for rps_flow_id table
From: Edward Cree @ 2018-04-27 14:08 UTC (permalink / raw)
To: linux-net-drivers, David Miller; +Cc: netdev
In-Reply-To: <480b987f-2dad-96d9-22ee-d2c25f0c3d92@solarflare.com>
efx->type->filter_insert() returns an ID rather than the index that
efx->type->filter_async_insert() used to, which causes it to exceed
efx->type->max_rx_ip_filters on some EF10 configurations, leading to out-
of-bounds array writes.
So, in efx_filter_rfs_work(), convert this back into an index (which is
what the remove call in the expiry path expects, anyway).
Fixes: 3af0f34290f6 ("sfc: replace asynchronous filter operations")
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
drivers/net/ethernet/sfc/rx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
index 64a94f242027..d2e254f2f72b 100644
--- a/drivers/net/ethernet/sfc/rx.c
+++ b/drivers/net/ethernet/sfc/rx.c
@@ -839,6 +839,8 @@ static void efx_filter_rfs_work(struct work_struct *data)
int rc;
rc = efx->type->filter_insert(efx, &req->spec, true);
+ if (rc >= 0)
+ rc %= efx->type->max_rx_ip_filters;
if (efx->rps_hash_table) {
spin_lock_bh(&efx->rps_hash_lock);
rule = efx_rps_hash_find(efx, &req->spec);
^ permalink raw reply related
* [PATCH net 2/2] sfc: fix ARFS expiry check on EF10
From: Edward Cree @ 2018-04-27 14:08 UTC (permalink / raw)
To: linux-net-drivers, David Miller; +Cc: netdev
In-Reply-To: <480b987f-2dad-96d9-22ee-d2c25f0c3d92@solarflare.com>
Owing to a missing conditional, the result of rps_may_expire_flow() was
being ignored and filters were being removed even if we'd decided not to
expire them.
Fixes: f8d6203780b7 ("sfc: ARFS filter IDs")
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
drivers/net/ethernet/sfc/ef10.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c
index 63036d9bf3e6..d90a7b1f4088 100644
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -4784,8 +4784,9 @@ static bool efx_ef10_filter_rfs_expire_one(struct efx_nic *efx, u32 flow_id,
* will set rule->filter_id to EFX_ARFS_FILTER_ID_PENDING, meaning that
* the rule is not removed by efx_rps_hash_del() below.
*/
- ret = efx_ef10_filter_remove_internal(efx, 1U << spec->priority,
- filter_idx, true) == 0;
+ if (ret)
+ ret = efx_ef10_filter_remove_internal(efx, 1U << spec->priority,
+ filter_idx, true) == 0;
/* While we can't safely dereference rule (we dropped the lock), we can
* still test it for NULL.
*/
^ permalink raw reply related
* tc: Using u32 filter
From: Jose Abreu @ 2018-04-27 14:15 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: Joao Pinto
Hi,
I'm trying to use u32 filter to filter specific fields of packets
by HW *only* but I'm having a hard time in trying to run tc to
configure it.
I implemented a dummy .ndo_setup_tc callback which always returns
success and I set NETIF_F_HW_TC field in hw_features. Then I run
tc, like this:
# tc filter add dev eth0 u32 skip_sw sample u32 20 ffff at 0
At this stage I'm not really caring about the packet content (the
"20 ffff at 0"), I just want to see the configuration reaching my
driver but I'm getting a "RTNETLINK answers: Operation not
supported" error.
Can you tell me what I'm I doing wrong?
Thanks and Best Regards,
Jose Miguel Abreu
^ permalink raw reply
* Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally
From: David Miller @ 2018-04-27 14:39 UTC (permalink / raw)
To: gregkh; +Cc: whissi, stable, nicolas.dichtel, netdev
In-Reply-To: <20180427135125.GA31860@kroah.com>
From: Greg KH <gregkh@linuxfoundation.org>
Date: Fri, 27 Apr 2018 15:51:25 +0200
> On Fri, Apr 27, 2018 at 02:20:07PM +0200, Thomas Deutschmann wrote:
>> On 2018-04-22 23:50, Thomas Deutschmann wrote:
>> > Hi,
>> >
>> > please add
>> >
>> >> From f15ca723c1ebe6c1a06bc95fda6b62cd87b44559 Mon Sep 17 00:00:00 2001
>> >> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> >> Date: Thu, 25 Jan 2018 19:03:03 +0100
>> >> Subject: net: don't call update_pmtu unconditionally
>> >>
>> >> Some dst_ops (e.g. md_dst_ops)) doesn't set this handler. It may result to:
>> >> "BUG: unable to handle kernel NULL pointer dereference at (null)"
>> >>
>> >> Let's add a helper to check if update_pmtu is available before calling it.
>> >>
>> >> Fixes: 52a589d51f10 ("geneve: update skb dst pmtu on tx path")
>> >> Fixes: a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path")
>> >> CC: Roman Kapl <code@rkapl.cz>
>> >> CC: Xin Long <lucien.xin@gmail.com>
>> >> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> >> Signed-off-by: David S. Miller <davem@davemloft.net>
>> >
>> > to 4.14.x.
>> >
>> > This fixes NULL derefs caused by a93bf0ff4490 ("vxlan: update
>> > skb dst pmtu on tx path"), which was backported to 4.14.24.
>>
>> *ping* - Not yet applied and not yet queued. Is there a problem with the
>> patch which prevents a cherry-pick for 4.14.x?
>
> This looks like an "obvious" fix for me to pick up.
>
> Dave, any objections for me just grabbing it as-is?
No objections, thanks everyone.
^ permalink raw reply
* Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally
From: Greg KH @ 2018-04-27 14:45 UTC (permalink / raw)
To: Thomas Deutschmann; +Cc: stable, davem, nicolas.dichtel, netdev
In-Reply-To: <20180427135125.GA31860@kroah.com>
On Fri, Apr 27, 2018 at 03:51:25PM +0200, Greg KH wrote:
> On Fri, Apr 27, 2018 at 02:20:07PM +0200, Thomas Deutschmann wrote:
> > On 2018-04-22 23:50, Thomas Deutschmann wrote:
> > > Hi,
> > >
> > > please add
> > >
> > >> From f15ca723c1ebe6c1a06bc95fda6b62cd87b44559 Mon Sep 17 00:00:00 2001
> > >> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> > >> Date: Thu, 25 Jan 2018 19:03:03 +0100
> > >> Subject: net: don't call update_pmtu unconditionally
> > >>
> > >> Some dst_ops (e.g. md_dst_ops)) doesn't set this handler. It may result to:
> > >> "BUG: unable to handle kernel NULL pointer dereference at (null)"
> > >>
> > >> Let's add a helper to check if update_pmtu is available before calling it.
> > >>
> > >> Fixes: 52a589d51f10 ("geneve: update skb dst pmtu on tx path")
> > >> Fixes: a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path")
> > >> CC: Roman Kapl <code@rkapl.cz>
> > >> CC: Xin Long <lucien.xin@gmail.com>
> > >> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> > >> Signed-off-by: David S. Miller <davem@davemloft.net>
> > >
> > > to 4.14.x.
> > >
> > > This fixes NULL derefs caused by a93bf0ff4490 ("vxlan: update
> > > skb dst pmtu on tx path"), which was backported to 4.14.24.
> >
> > *ping* - Not yet applied and not yet queued. Is there a problem with the
> > patch which prevents a cherry-pick for 4.14.x?
>
> This looks like an "obvious" fix for me to pick up.
Well, it would be "obvious" if it actually applied to the 4.14.y tree :(
Thomas, did you try this patch out? I can't apply it as-is, it will
need a backport. Please work on that, and test it out, as I don't get
the impression that you did that here.
Then post the working backport and I'll be glad to consider it for
future 4.14.y releases.
thanks,
greg k-h
^ permalink raw reply
* Re: ip6-in-ip{4,6} ipsec tunnel issues with 1280 MTU
From: David Ahern @ 2018-04-27 14:48 UTC (permalink / raw)
To: Ashwanth Goli, Paolo Abeni; +Cc: netdev, maloney, edumazet, netdev-owner
In-Reply-To: <a3e39b94de731f86d2e9ecd8f0230643@codeaurora.org>
On 4/27/18 5:02 AM, Ashwanth Goli wrote:
> On 2018-04-26 17:21, Paolo Abeni wrote:
>> Hi,
>>
>> [fixed CC list]
>>
>> On Wed, 2018-04-25 at 21:43 +0530, Ashwanth Goli wrote:
>>> Hi Pablo,
>>
>> Actually I'm Paolo, but yours is a recurring mistake ;)
>>
>>> I am noticing an issue similar to the one reported by Alexis Perez
>>> [Regression for ip6-in-ip4 IPsec tunnel in 4.14.16]
>>>
>>> In my IPsec setup outer MTU is set to 1280, ip6_setup_cork sees an MTU
>>> less than IPV6_MIN_MTU because of the tunnel headers. -EINVAL is being
>>> returned as a result of the MTU check that got added with below patch.
If you know you are running ipsec over the link why are you setting the
outer MTU to 1280? RFC 2460 suggests the fragmentation of packets for
links with MTU < 1280 should be done below the IPv6 layer:
5. Packet Size Issues
IPv6 requires that every link in the internet have an MTU of 1280
octets or greater. On any link that cannot convey a 1280-octet
packet in one piece, link-specific fragmentation and reassembly must
be provided at a layer below IPv6.
Links that have a configurable MTU (for example, PPP links [RFC-
1661]) must be configured to have an MTU of at least 1280 octets; it
is recommended that they be configured with an MTU of 1500 octets or
greater, to accommodate possible encapsulations (i.e., tunneling)
without incurring IPv6-layer fragmentation.
^ permalink raw reply
* Re: [PATCH v2] net: qrtr: Expose tunneling endpoint to user space
From: David Miller @ 2018-04-27 14:55 UTC (permalink / raw)
To: bjorn.andersson; +Cc: clew, linux-kernel, netdev, linux-arm-msm
In-Reply-To: <20180423214653.10016-1-bjorn.andersson@linaro.org>
From: Bjorn Andersson <bjorn.andersson@linaro.org>
Date: Mon, 23 Apr 2018 14:46:53 -0700
> + count = min_t(size_t, iov_iter_count(to), skb->len);
> + if (copy_to_iter(skb->data, count, to) != count)
> + count = -EFAULT;
> +
> + kfree_skb(skb);
As noted by Chris, you should be using consume_skb() here.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 4/5] ipv6: sr: Add seg6local action End.BPF
From: David Miller @ 2018-04-27 14:59 UTC (permalink / raw)
To: m.xhonneux; +Cc: netdev, dlebrun, alexei.starovoitov
In-Reply-To: <223e33f96b2cb9868a55a686c5d9321162a67ddb.1524591163.git.m.xhonneux@gmail.com>
From: Mathieu Xhonneux <m.xhonneux@gmail.com>
Date: Tue, 24 Apr 2018 18:44:15 +0100
> This patch adds the End.BPF action to the LWT seg6local infrastructure.
> This action works like any other seg6local End action, meaning that an IPv6
> header with SRH is needed, whose DA has to be equal to the SID of the
> action. It will also advance the SRH to the next segment, the BPF program
> does not have to take care of this.
I'd like to see some BPF developers review this change.
But on my side I wonder if, instead of validating the whole thing afterwards,
we should make the helpers accessible by the eBPF program validate the changes
as they are made.
^ permalink raw reply
* Re: [PATCH v1 net-next] lan78xx: Lan7801 Support for Fixed PHY
From: David Miller @ 2018-04-27 15:00 UTC (permalink / raw)
To: raghuramchary.jallipalli; +Cc: netdev, unglinuxdriver, woojung.huh
In-Reply-To: <20180425064306.5513-1-raghuramchary.jallipalli@microchip.com>
From: Raghuram Chary J <raghuramchary.jallipalli@microchip.com>
Date: Wed, 25 Apr 2018 12:13:06 +0530
> Adding Fixed PHY support to the lan78xx driver.
>
> Signed-off-by: Raghuram Chary J <raghuramchary.jallipalli@microchip.com>
> ---
> v0->v1:
> * Remove driver version #define
> * Modify netdev_info to netdev_dbg
> * Move lan7801 specific to new routine and add switch case
> * Minor cleanup
This patch doesn't apply cleanly to net-next, please respin.
^ permalink raw reply
* Re: [PATCH net-next] l2tp: centralise parsing of sockaddr_pppol2tp*
From: David Miller @ 2018-04-27 15:03 UTC (permalink / raw)
To: g.nault; +Cc: netdev, jchapman
In-Reply-To: <fa923854b6bdb86990cc26c8e90e14a2dc906559.1524670082.git.g.nault@alphalink.fr>
From: Guillaume Nault <g.nault@alphalink.fr>
Date: Wed, 25 Apr 2018 17:50:31 +0200
> @DaveM, I have some know bugs in pppol2tp_connect() that I'm going to
> work on soon. That's probably going to create some conflicts between
> net and net-next. They should be easy to resolve, but if you prefer, I
> can resend this patch later, after all known issues get fixed.
Let's fix the bugs in net first, then do this cleanup on top after those
fixes make it into net-next.
Thanks!
^ permalink raw reply
* Re: [net 1/1] tipc: fix bug in function tipc_nl_node_dump_monitor
From: David Miller @ 2018-04-27 15:04 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, mohan.krishna.ghanta.krishnamurthy, tung.q.nguyen,
hoang.h.le, canh.d.luu, ying.xue, tipc-discussion
In-Reply-To: <1524673765-28878-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Wed, 25 Apr 2018 18:29:25 +0200
> Commit 36a50a989ee8 ("tipc: fix infinite loop when dumping link monitor
> summary") intended to fix a problem with user tool looping when max
> number of bearers are enabled.
>
> Unfortunately, the wrong version of the commit was posted, so the
> problem was not solved at all.
>
> This commit adds the missing part.
>
> Fixes: 36a50a989ee8 ("tipc: fix infinite loop when dumping link monitor summary")
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: tc: Using u32 filter
From: Jiri Pirko @ 2018-04-27 15:04 UTC (permalink / raw)
To: Jose Abreu; +Cc: netdev@vger.kernel.org, Joao Pinto
In-Reply-To: <27482470-930e-916d-2ace-deedf3019369@synopsys.com>
Fri, Apr 27, 2018 at 04:15:46PM CEST, Jose.Abreu@synopsys.com wrote:
>Hi,
>
>I'm trying to use u32 filter to filter specific fields of packets
>by HW *only* but I'm having a hard time in trying to run tc to
>configure it.
>I implemented a dummy .ndo_setup_tc callback which always returns
>success and I set NETIF_F_HW_TC field in hw_features. Then I run
Did you register a block cb?
>tc, like this:
>
> # tc filter add dev eth0 u32 skip_sw sample u32 20 ffff at 0
>
>At this stage I'm not really caring about the packet content (the
>"20 ffff at 0"), I just want to see the configuration reaching my
>driver but I'm getting a "RTNETLINK answers: Operation not
>supported" error.
>
>Can you tell me what I'm I doing wrong?
>
>Thanks and Best Regards,
>Jose Miguel Abreu
^ permalink raw reply
* Re: [net-next 1/1] tipc: introduce ioctl for fetching node identity
From: David Miller @ 2018-04-27 15:05 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, mohan.krishna.ghanta.krishnamurthy, tung.q.nguyen,
hoang.h.le, canh.d.luu, ying.xue, tipc-discussion
In-Reply-To: <1524677376-29004-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Wed, 25 Apr 2018 19:29:36 +0200
> After the introduction of a 128-bit node identity it may be difficult
> for a user to correlate between this identity and the generated node
> hash address.
>
> We now try to make this easier by introducing a new ioctl() call for
> fetching a node identity by using the hash value as key. This will
> be particularly useful when we extend some of the commands in the
> 'tipc' tool, but we also expect regular user applications to need
> this feature.
>
> Acked-by: Ying Xue <ying.xue@windriver.com>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
I hate ioctls, but I can't suggest anything better in this case.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] l2tp: consistent reference counting in procfs and debufs
From: David Miller @ 2018-04-27 15:06 UTC (permalink / raw)
To: g.nault; +Cc: netdev, jchapman
In-Reply-To: <05e09a546a94331e43d9e771f6ce515b1cdbf521.1524678712.git.g.nault@alphalink.fr>
From: Guillaume Nault <g.nault@alphalink.fr>
Date: Wed, 25 Apr 2018 19:54:14 +0200
> The 'pppol2tp' procfs and 'l2tp/tunnels' debugfs files handle reference
> counting of sessions differently than for tunnels.
>
> For consistency, use the same mechanism for handling both sessions and
> tunnels. That is, drop the reference on the previous session just
> before looking up the next one (rather than in .show()). If necessary
> (if dump stops before *_next_session() returns NULL), drop the last
> reference in .stop().
>
> Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Applied.
Your continued bug fixing and clenaups in this area are very much appreciated.
^ permalink raw reply
* Re: [PATCH net-next 6/6] liquidio: enhanced ethtool --set-channels feature
From: kbuild test robot @ 2018-04-27 15:07 UTC (permalink / raw)
To: Felix Manlunas
Cc: kbuild-all, davem, netdev, raghu.vatsavayi, derek.chickles,
satananda.burla, felix.manlunas, intiyaz.basha
In-Reply-To: <20180425182350.GA13911@felix-thinkpad.cavium.com>
Hi Intiyaz,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Felix-Manlunas/liquidio-enhanced-ethtool-set-channels-feature/20180427-195934
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:869:22: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [unsigned] [usertype] major @@ got short [unsigned] [usertype] major @@
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:869:22: expected unsigned short [unsigned] [usertype] major
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:869:22: got restricted __be16 [usertype] <noident>
>> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:870:22: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [unsigned] [usertype] minor @@ got short [unsigned] [usertype] minor @@
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:870:22: expected unsigned short [unsigned] [usertype] minor
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:870:22: got restricted __be16 [usertype] <noident>
>> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:871:22: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [unsigned] [usertype] micro @@ got short [unsigned] [usertype] micro @@
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:871:22: expected unsigned short [unsigned] [usertype] micro
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:871:22: got restricted __be16 [usertype] <noident>
>> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:840:5: sparse: symbol 'lio_23xx_reconfigure_queue_count' was not declared. Should it be static?
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1126:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1126:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1126:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1126:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1126:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1126:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1126:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1128:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1128:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1128:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1128:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1128:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1128:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1128:20: sparse: expression using sizeof(void)
Please review and possibly fold the followup patch.
vim +869 drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
839
> 840 int lio_23xx_reconfigure_queue_count(struct lio *lio)
841 {
842 struct octeon_device *oct = lio->oct_dev;
843 struct liquidio_if_cfg_context *ctx;
844 u32 resp_size, ctx_size, data_size;
845 struct liquidio_if_cfg_resp *resp;
846 struct octeon_soft_command *sc;
847 union oct_nic_if_cfg if_cfg;
848 struct lio_version *vdata;
849 u32 ifidx_or_pfnum;
850 int retval;
851 int j;
852
853 resp_size = sizeof(struct liquidio_if_cfg_resp);
854 ctx_size = sizeof(struct liquidio_if_cfg_context);
855 data_size = sizeof(struct lio_version);
856 sc = (struct octeon_soft_command *)
857 octeon_alloc_soft_command(oct, data_size,
858 resp_size, ctx_size);
859 if (!sc) {
860 dev_err(&oct->pci_dev->dev, "%s: Failed to allocate soft command\n",
861 __func__);
862 return -1;
863 }
864
865 resp = (struct liquidio_if_cfg_resp *)sc->virtrptr;
866 ctx = (struct liquidio_if_cfg_context *)sc->ctxptr;
867 vdata = (struct lio_version *)sc->virtdptr;
868
> 869 vdata->major = cpu_to_be16(LIQUIDIO_BASE_MAJOR_VERSION);
> 870 vdata->minor = cpu_to_be16(LIQUIDIO_BASE_MINOR_VERSION);
> 871 vdata->micro = cpu_to_be16(LIQUIDIO_BASE_MICRO_VERSION);
872
873 ifidx_or_pfnum = oct->pf_num;
874 WRITE_ONCE(ctx->cond, 0);
875 ctx->octeon_id = lio_get_device_id(oct);
876 init_waitqueue_head(&ctx->wc);
877
878 if_cfg.u64 = 0;
879 if_cfg.s.num_iqueues = oct->sriov_info.num_pf_rings;
880 if_cfg.s.num_oqueues = oct->sriov_info.num_pf_rings;
881 if_cfg.s.base_queue = oct->sriov_info.pf_srn;
882 if_cfg.s.gmx_port_id = oct->pf_num;
883
884 sc->iq_no = 0;
885 octeon_prepare_soft_command(oct, sc, OPCODE_NIC,
886 OPCODE_NIC_QCOUNT_UPDATE, 0,
887 if_cfg.u64, 0);
888 sc->callback = lio_if_cfg_callback;
889 sc->callback_arg = sc;
890 sc->wait_time = LIO_IFCFG_WAIT_TIME;
891
892 retval = octeon_send_soft_command(oct, sc);
893 if (retval == IQ_SEND_FAILED) {
894 dev_err(&oct->pci_dev->dev,
895 "iq/oq config failed status: %x\n",
896 retval);
897 goto qcount_update_fail;
898 }
899
900 if (sleep_cond(&ctx->wc, &ctx->cond) == -EINTR) {
901 dev_err(&oct->pci_dev->dev, "Wait interrupted\n");
902 return -1;
903 }
904
905 retval = resp->status;
906 if (retval) {
907 dev_err(&oct->pci_dev->dev, "iq/oq config failed\n");
908 goto qcount_update_fail;
909 }
910
911 octeon_swap_8B_data((u64 *)(&resp->cfg_info),
912 (sizeof(struct liquidio_if_cfg_info)) >> 3);
913
914 lio->ifidx = ifidx_or_pfnum;
915 lio->linfo.num_rxpciq = hweight64(resp->cfg_info.iqmask);
916 lio->linfo.num_txpciq = hweight64(resp->cfg_info.iqmask);
917 for (j = 0; j < lio->linfo.num_rxpciq; j++) {
918 lio->linfo.rxpciq[j].u64 =
919 resp->cfg_info.linfo.rxpciq[j].u64;
920 }
921
922 for (j = 0; j < lio->linfo.num_txpciq; j++) {
923 lio->linfo.txpciq[j].u64 =
924 resp->cfg_info.linfo.txpciq[j].u64;
925 }
926
927 lio->linfo.hw_addr = resp->cfg_info.linfo.hw_addr;
928 lio->linfo.gmxport = resp->cfg_info.linfo.gmxport;
929 lio->linfo.link.u64 = resp->cfg_info.linfo.link.u64;
930 lio->txq = lio->linfo.txpciq[0].s.q_no;
931 lio->rxq = lio->linfo.rxpciq[0].s.q_no;
932
933 octeon_free_soft_command(oct, sc);
934 dev_info(&oct->pci_dev->dev, "Queue count updated to %d\n",
935 lio->linfo.num_rxpciq);
936
937 return 0;
938
939 qcount_update_fail:
940 octeon_free_soft_command(oct, sc);
941
942 return -1;
943 }
944
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [RFC PATCH] liquidio: lio_23xx_reconfigure_queue_count() can be static
From: kbuild test robot @ 2018-04-27 15:07 UTC (permalink / raw)
To: Felix Manlunas
Cc: kbuild-all, davem, netdev, raghu.vatsavayi, derek.chickles,
satananda.burla, felix.manlunas, intiyaz.basha
In-Reply-To: <20180425182350.GA13911@felix-thinkpad.cavium.com>
Fixes: a6b1f70737e0 ("liquidio: enhanced ethtool --set-channels feature")
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
lio_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
index 7ca246e..4877776d 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
@@ -837,7 +837,7 @@ lio_ethtool_get_ringparam(struct net_device *netdev,
ering->rx_jumbo_max_pending = 0;
}
-int lio_23xx_reconfigure_queue_count(struct lio *lio)
+static int lio_23xx_reconfigure_queue_count(struct lio *lio)
{
struct octeon_device *oct = lio->oct_dev;
struct liquidio_if_cfg_context *ctx;
^ permalink raw reply related
* [PATCH net-next v2 1/6] net: bridge: Publish bridge accessor functions
From: Ido Schimmel @ 2018-04-27 15:11 UTC (permalink / raw)
To: netdev, bridge; +Cc: Ido Schimmel, mlxsw, nikolay, jiri, petrm, davem
In-Reply-To: <20180427151111.22099-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Add a couple new functions to allow querying FDB and vlan settings of a
bridge.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
include/linux/if_bridge.h | 28 ++++++++++++++++++++++++++++
net/bridge/br_fdb.c | 22 ++++++++++++++++++++++
net/bridge/br_private.h | 11 +++++++++++
net/bridge/br_vlan.c | 39 +++++++++++++++++++++++++++++++++++++++
4 files changed, 100 insertions(+)
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index 02639ebea2f0..769cf71efbdf 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -93,11 +93,39 @@ static inline bool br_multicast_router(const struct net_device *dev)
#if IS_ENABLED(CONFIG_BRIDGE) && IS_ENABLED(CONFIG_BRIDGE_VLAN_FILTERING)
bool br_vlan_enabled(const struct net_device *dev);
+int br_vlan_pvid_rtnl(const struct net_device *dev, u16 *p_pvid);
+int br_vlan_info_rtnl(const struct net_device *dev, u16 vid,
+ struct bridge_vlan_info *p_vinfo);
#else
static inline bool br_vlan_enabled(const struct net_device *dev)
{
return false;
}
+
+static inline int br_vlan_pvid_rtnl(const struct net_device *dev, u16 *p_pvid)
+{
+ return -1;
+}
+
+static inline int br_vlan_info_rtnl(const struct net_device *dev, u16 vid,
+ struct bridge_vlan_info *p_vinfo)
+{
+ return -1;
+}
+#endif
+
+#if IS_ENABLED(CONFIG_BRIDGE)
+struct net_device *br_fdb_find_port_rtnl(const struct net_device *br_dev,
+ const unsigned char *addr,
+ __u16 vid);
+#else
+static inline struct net_device *
+br_fdb_find_port_rtnl(const struct net_device *br_dev,
+ const unsigned char *addr,
+ __u16 vid)
+{
+ return NULL;
+}
#endif
#endif
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index d9e69e4514be..51c7720aaba9 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -121,6 +121,28 @@ static struct net_bridge_fdb_entry *br_fdb_find(struct net_bridge *br,
return fdb;
}
+struct net_device *br_fdb_find_port_rtnl(const struct net_device *br_dev,
+ const unsigned char *addr,
+ __u16 vid)
+{
+ struct net_bridge_fdb_entry *f;
+ struct net_device *dev = NULL;
+ struct net_bridge *br;
+
+ ASSERT_RTNL();
+
+ if (!netif_is_bridge_master(br_dev))
+ return NULL;
+
+ br = netdev_priv(br_dev);
+ f = br_fdb_find(br, addr, vid);
+ if (f && f->dst)
+ dev = f->dst->dev;
+
+ return dev;
+}
+EXPORT_SYMBOL_GPL(br_fdb_find_port_rtnl);
+
struct net_bridge_fdb_entry *br_fdb_find_rcu(struct net_bridge *br,
const unsigned char *addr,
__u16 vid)
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index a7cb3ece5031..1a5093115534 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -594,11 +594,22 @@ static inline bool br_rx_handler_check_rcu(const struct net_device *dev)
return rcu_dereference(dev->rx_handler) == br_handle_frame;
}
+static inline bool br_rx_handler_check_rtnl(const struct net_device *dev)
+{
+ return rcu_dereference_rtnl(dev->rx_handler) == br_handle_frame;
+}
+
static inline struct net_bridge_port *br_port_get_check_rcu(const struct net_device *dev)
{
return br_rx_handler_check_rcu(dev) ? br_port_get_rcu(dev) : NULL;
}
+static inline struct net_bridge_port *
+br_port_get_check_rtnl(const struct net_device *dev)
+{
+ return br_rx_handler_check_rtnl(dev) ? br_port_get_rtnl_rcu(dev) : NULL;
+}
+
/* br_ioctl.c */
int br_dev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
int br_ioctl_deviceless_stub(struct net *net, unsigned int cmd,
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index 9896f4975353..821014da3ef3 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -1149,3 +1149,42 @@ void br_vlan_get_stats(const struct net_bridge_vlan *v,
stats->tx_packets += txpackets;
}
}
+
+int br_vlan_pvid_rtnl(const struct net_device *dev, u16 *p_pvid)
+{
+ struct net_bridge_vlan_group *vg;
+
+ ASSERT_RTNL();
+ if (netif_is_bridge_master(dev))
+ vg = br_vlan_group(netdev_priv(dev));
+ else
+ return -EINVAL;
+
+ *p_pvid = br_get_pvid(vg);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(br_vlan_pvid_rtnl);
+
+int br_vlan_info_rtnl(const struct net_device *dev, u16 vid,
+ struct bridge_vlan_info *p_vinfo)
+{
+ struct net_bridge_vlan_group *vg;
+ struct net_bridge_vlan *v;
+ struct net_bridge_port *p;
+
+ ASSERT_RTNL();
+ p = br_port_get_check_rtnl(dev);
+ if (p)
+ vg = nbp_vlan_group(p);
+ else
+ return -EINVAL;
+
+ v = br_vlan_find(vg, vid);
+ if (!v)
+ return -ENOENT;
+
+ p_vinfo->vid = vid;
+ p_vinfo->flags = v->flags;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(br_vlan_info_rtnl);
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v2 0/6] mlxsw: SPAN: Support routes pointing at bridges
From: Ido Schimmel @ 2018-04-27 15:11 UTC (permalink / raw)
To: netdev, bridge; +Cc: davem, jiri, petrm, nikolay, stephen, mlxsw, Ido Schimmel
Petr says:
When mirroring to a gretap or ip6gretap netdevice, the route that
directs the encapsulated packets can reference a bridge. In that case,
in the software model, the packet is switched.
Thus when offloading mirroring like that, take into consideration FDB,
STP, PVID configured at the bridge, and whether that VLAN ID should be
tagged on egress.
Patch #1 introduces functions to get bridge PVID, VLAN flags and to look
up an FDB entry.
Patches #2 and #3 refactor some existing code and introduce a new
accessor function.
With patches #4 and #5 mlxsw calls mlxsw_sp_span_respin() on switchdev
events as well. There is no impact yet, because bridge as an underlay
device is still not allowed.
That is implemented in patch #6, which uses the new interfaces to figure
out on which one port the mirroring should be configured, and whether
the mirrored packets should be VLAN-tagged and how.
Changes from v1 to v2:
- Change the suite of bridge accessor functions to br_vlan_pvid_rtnl(),
br_vlan_info_rtnl(), br_fdb_find_port_rtnl().
Petr Machata (6):
net: bridge: Publish bridge accessor functions
mlxsw: spectrum: Extract mlxsw_sp_stp_spms_state()
mlxsw: spectrum_switchdev: Publish two functions
mlxsw: spectrum: Register SPAN before switchdev
mlxsw: Respin SPAN on switchdev events
mlxsw: spectrum_span: Allow bridge for gretap mirror
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 50 ++++++------
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 1 +
.../net/ethernet/mellanox/mlxsw/spectrum_span.c | 95 ++++++++++++++++++++--
.../net/ethernet/mellanox/mlxsw/spectrum_span.h | 1 +
.../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 72 ++++++++++++++--
.../ethernet/mellanox/mlxsw/spectrum_switchdev.h | 43 ++++++++++
include/linux/if_bridge.h | 28 +++++++
net/bridge/br_fdb.c | 22 +++++
net/bridge/br_private.h | 11 +++
net/bridge/br_vlan.c | 39 +++++++++
10 files changed, 326 insertions(+), 36 deletions(-)
create mode 100644 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.h
--
2.14.3
^ permalink raw reply
* [PATCH net-next v2 2/6] mlxsw: spectrum: Extract mlxsw_sp_stp_spms_state()
From: Ido Schimmel @ 2018-04-27 15:11 UTC (permalink / raw)
To: netdev, bridge; +Cc: davem, jiri, petrm, nikolay, stephen, mlxsw, Ido Schimmel
In-Reply-To: <20180427151111.22099-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Instead of duplicating the decision regarding port forwarding state made
by mlxsw_sp_port_vid_stp_set(), extract the decision-making into a new
function and reuse.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 26 +++++++++++++-------------
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 1 +
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index ca38a30fbe91..7317fb8079d1 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -441,29 +441,29 @@ static void mlxsw_sp_txhdr_construct(struct sk_buff *skb,
mlxsw_tx_hdr_type_set(txhdr, MLXSW_TXHDR_TYPE_CONTROL);
}
-int mlxsw_sp_port_vid_stp_set(struct mlxsw_sp_port *mlxsw_sp_port, u16 vid,
- u8 state)
+enum mlxsw_reg_spms_state mlxsw_sp_stp_spms_state(u8 state)
{
- struct mlxsw_sp *mlxsw_sp = mlxsw_sp_port->mlxsw_sp;
- enum mlxsw_reg_spms_state spms_state;
- char *spms_pl;
- int err;
-
switch (state) {
case BR_STATE_FORWARDING:
- spms_state = MLXSW_REG_SPMS_STATE_FORWARDING;
- break;
+ return MLXSW_REG_SPMS_STATE_FORWARDING;
case BR_STATE_LEARNING:
- spms_state = MLXSW_REG_SPMS_STATE_LEARNING;
- break;
+ return MLXSW_REG_SPMS_STATE_LEARNING;
case BR_STATE_LISTENING: /* fall-through */
case BR_STATE_DISABLED: /* fall-through */
case BR_STATE_BLOCKING:
- spms_state = MLXSW_REG_SPMS_STATE_DISCARDING;
- break;
+ return MLXSW_REG_SPMS_STATE_DISCARDING;
default:
BUG();
}
+}
+
+int mlxsw_sp_port_vid_stp_set(struct mlxsw_sp_port *mlxsw_sp_port, u16 vid,
+ u8 state)
+{
+ enum mlxsw_reg_spms_state spms_state = mlxsw_sp_stp_spms_state(state);
+ struct mlxsw_sp *mlxsw_sp = mlxsw_sp_port->mlxsw_sp;
+ char *spms_pl;
+ int err;
spms_pl = kmalloc(MLXSW_REG_SPMS_LEN, GFP_KERNEL);
if (!spms_pl)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
index 804d4d2c8031..4a519d8edec8 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
@@ -364,6 +364,7 @@ int __mlxsw_sp_port_headroom_set(struct mlxsw_sp_port *mlxsw_sp_port, int mtu,
int mlxsw_sp_port_ets_maxrate_set(struct mlxsw_sp_port *mlxsw_sp_port,
enum mlxsw_reg_qeec_hr hr, u8 index,
u8 next_index, u32 maxrate);
+enum mlxsw_reg_spms_state mlxsw_sp_stp_spms_state(u8 stp_state);
int mlxsw_sp_port_vid_stp_set(struct mlxsw_sp_port *mlxsw_sp_port, u16 vid,
u8 state);
int mlxsw_sp_port_vp_mode_set(struct mlxsw_sp_port *mlxsw_sp_port, bool enable);
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v2 3/6] mlxsw: spectrum_switchdev: Publish two functions
From: Ido Schimmel @ 2018-04-27 15:11 UTC (permalink / raw)
To: netdev, bridge; +Cc: davem, jiri, petrm, nikolay, stephen, mlxsw, Ido Schimmel
In-Reply-To: <20180427151111.22099-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Publish the existing function mlxsw_sp_bridge_port_find(), and add
another service accessor mlxsw_sp_bridge_port_stp_state(). Publish both
in a new file spectrum_switchdev.h.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
.../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 9 ++++-
.../ethernet/mellanox/mlxsw/spectrum_switchdev.h | 43 ++++++++++++++++++++++
2 files changed, 51 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.h
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index c11c9a635866..db4aea0f8996 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -50,6 +50,7 @@
#include <net/switchdev.h>
#include "spectrum_router.h"
+#include "spectrum_switchdev.h"
#include "spectrum.h"
#include "core.h"
#include "reg.h"
@@ -239,7 +240,7 @@ __mlxsw_sp_bridge_port_find(const struct mlxsw_sp_bridge_device *bridge_device,
return NULL;
}
-static struct mlxsw_sp_bridge_port *
+struct mlxsw_sp_bridge_port *
mlxsw_sp_bridge_port_find(struct mlxsw_sp_bridge *bridge,
struct net_device *brport_dev)
{
@@ -2297,6 +2298,12 @@ static struct notifier_block mlxsw_sp_switchdev_notifier = {
.notifier_call = mlxsw_sp_switchdev_event,
};
+u8
+mlxsw_sp_bridge_port_stp_state(struct mlxsw_sp_bridge_port *bridge_port)
+{
+ return bridge_port->stp_state;
+}
+
static int mlxsw_sp_fdb_init(struct mlxsw_sp *mlxsw_sp)
{
struct mlxsw_sp_bridge *bridge = mlxsw_sp->bridge;
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.h
new file mode 100644
index 000000000000..bc44d5effc28
--- /dev/null
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0
+ * drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.h
+ * Copyright (c) 2018 Mellanox Technologies. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * 3. Neither the names of the copyright holders nor the names of its
+ * contributors may be used to endorse or promote products derived from
+ * this software without specific prior written permission.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include <linux/netdevice.h>
+
+struct mlxsw_sp_bridge;
+struct mlxsw_sp_bridge_port;
+
+struct mlxsw_sp_bridge_port *
+mlxsw_sp_bridge_port_find(struct mlxsw_sp_bridge *bridge,
+ struct net_device *brport_dev);
+
+u8 mlxsw_sp_bridge_port_stp_state(struct mlxsw_sp_bridge_port *bridge_port);
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v2 4/6] mlxsw: spectrum: Register SPAN before switchdev
From: Ido Schimmel @ 2018-04-27 15:11 UTC (permalink / raw)
To: netdev, bridge; +Cc: davem, jiri, petrm, nikolay, stephen, mlxsw, Ido Schimmel
In-Reply-To: <20180427151111.22099-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Since switchdev events can trigger SPAN respin, it is necessary that the
data structures are available. Register SPAN first, with a commentary on
what the dependencies are.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index 7317fb8079d1..94132f6cec61 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -3666,6 +3666,15 @@ static int mlxsw_sp_init(struct mlxsw_core *mlxsw_core,
goto err_lag_init;
}
+ /* Initialize SPAN before router and switchdev, so that those components
+ * can call mlxsw_sp_span_respin().
+ */
+ err = mlxsw_sp_span_init(mlxsw_sp);
+ if (err) {
+ dev_err(mlxsw_sp->bus_info->dev, "Failed to init span system\n");
+ goto err_span_init;
+ }
+
err = mlxsw_sp_switchdev_init(mlxsw_sp);
if (err) {
dev_err(mlxsw_sp->bus_info->dev, "Failed to initialize switchdev\n");
@@ -3684,15 +3693,6 @@ static int mlxsw_sp_init(struct mlxsw_core *mlxsw_core,
goto err_afa_init;
}
- err = mlxsw_sp_span_init(mlxsw_sp);
- if (err) {
- dev_err(mlxsw_sp->bus_info->dev, "Failed to init span system\n");
- goto err_span_init;
- }
-
- /* Initialize router after SPAN is initialized, so that the FIB and
- * neighbor event handlers can issue SPAN respin.
- */
err = mlxsw_sp_router_init(mlxsw_sp);
if (err) {
dev_err(mlxsw_sp->bus_info->dev, "Failed to initialize router\n");
@@ -3739,14 +3739,14 @@ static int mlxsw_sp_init(struct mlxsw_core *mlxsw_core,
err_netdev_notifier:
mlxsw_sp_router_fini(mlxsw_sp);
err_router_init:
- mlxsw_sp_span_fini(mlxsw_sp);
-err_span_init:
mlxsw_sp_afa_fini(mlxsw_sp);
err_afa_init:
mlxsw_sp_counter_pool_fini(mlxsw_sp);
err_counter_pool_init:
mlxsw_sp_switchdev_fini(mlxsw_sp);
err_switchdev_init:
+ mlxsw_sp_span_fini(mlxsw_sp);
+err_span_init:
mlxsw_sp_lag_fini(mlxsw_sp);
err_lag_init:
mlxsw_sp_buffers_fini(mlxsw_sp);
@@ -3768,10 +3768,10 @@ static void mlxsw_sp_fini(struct mlxsw_core *mlxsw_core)
mlxsw_sp_acl_fini(mlxsw_sp);
unregister_netdevice_notifier(&mlxsw_sp->netdevice_nb);
mlxsw_sp_router_fini(mlxsw_sp);
- mlxsw_sp_span_fini(mlxsw_sp);
mlxsw_sp_afa_fini(mlxsw_sp);
mlxsw_sp_counter_pool_fini(mlxsw_sp);
mlxsw_sp_switchdev_fini(mlxsw_sp);
+ mlxsw_sp_span_fini(mlxsw_sp);
mlxsw_sp_lag_fini(mlxsw_sp);
mlxsw_sp_buffers_fini(mlxsw_sp);
mlxsw_sp_traps_fini(mlxsw_sp);
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v2 5/6] mlxsw: Respin SPAN on switchdev events
From: Ido Schimmel @ 2018-04-27 15:11 UTC (permalink / raw)
To: netdev, bridge; +Cc: davem, jiri, petrm, nikolay, stephen, mlxsw, Ido Schimmel
In-Reply-To: <20180427151111.22099-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Changes to switchdev artifact can make a SPAN entry offloadable or
unoffloadable. To that end:
- Listen to SWITCHDEV_FDB_*_TO_BRIDGE notifications in addition to
the *_TO_DEVICE ones, to catch whatever activity is sent to the
bridge (likely by mlxsw itself).
On each FDB notification, respin SPAN to reconcile it with the FDB
changes.
- Also respin on switchdev port attribute changes (which currently
covers changes to STP state of ports) and port object additions and
removals.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
.../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 63 ++++++++++++++++++++--
1 file changed, 59 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index db4aea0f8996..1af99fe5fd32 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -49,6 +49,7 @@
#include <linux/netlink.h>
#include <net/switchdev.h>
+#include "spectrum_span.h"
#include "spectrum_router.h"
#include "spectrum_switchdev.h"
#include "spectrum.h"
@@ -923,6 +924,9 @@ static int mlxsw_sp_port_attr_set(struct net_device *dev,
break;
}
+ if (switchdev_trans_ph_commit(trans))
+ mlxsw_sp_span_respin(mlxsw_sp_port->mlxsw_sp);
+
return err;
}
@@ -1647,18 +1651,57 @@ mlxsw_sp_port_mrouter_update_mdb(struct mlxsw_sp_port *mlxsw_sp_port,
}
}
+struct mlxsw_sp_span_respin_work {
+ struct work_struct work;
+ struct mlxsw_sp *mlxsw_sp;
+};
+
+static void mlxsw_sp_span_respin_work(struct work_struct *work)
+{
+ struct mlxsw_sp_span_respin_work *respin_work =
+ container_of(work, struct mlxsw_sp_span_respin_work, work);
+
+ rtnl_lock();
+ mlxsw_sp_span_respin(respin_work->mlxsw_sp);
+ rtnl_unlock();
+ kfree(respin_work);
+}
+
+static void mlxsw_sp_span_respin_schedule(struct mlxsw_sp *mlxsw_sp)
+{
+ struct mlxsw_sp_span_respin_work *respin_work;
+
+ respin_work = kzalloc(sizeof(*respin_work), GFP_ATOMIC);
+ if (!respin_work)
+ return;
+
+ INIT_WORK(&respin_work->work, mlxsw_sp_span_respin_work);
+ respin_work->mlxsw_sp = mlxsw_sp;
+
+ mlxsw_core_schedule_work(&respin_work->work);
+}
+
static int mlxsw_sp_port_obj_add(struct net_device *dev,
const struct switchdev_obj *obj,
struct switchdev_trans *trans)
{
struct mlxsw_sp_port *mlxsw_sp_port = netdev_priv(dev);
+ const struct switchdev_obj_port_vlan *vlan;
int err = 0;
switch (obj->id) {
case SWITCHDEV_OBJ_ID_PORT_VLAN:
- err = mlxsw_sp_port_vlans_add(mlxsw_sp_port,
- SWITCHDEV_OBJ_PORT_VLAN(obj),
- trans);
+ vlan = SWITCHDEV_OBJ_PORT_VLAN(obj);
+ err = mlxsw_sp_port_vlans_add(mlxsw_sp_port, vlan, trans);
+
+ if (switchdev_trans_ph_commit(trans)) {
+ /* The event is emitted before the changes are actually
+ * applied to the bridge. Therefore schedule the respin
+ * call for later, so that the respin logic sees the
+ * updated bridge state.
+ */
+ mlxsw_sp_span_respin_schedule(mlxsw_sp_port->mlxsw_sp);
+ }
break;
case SWITCHDEV_OBJ_ID_PORT_MDB:
err = mlxsw_sp_port_mdb_add(mlxsw_sp_port,
@@ -1809,6 +1852,8 @@ static int mlxsw_sp_port_obj_del(struct net_device *dev,
break;
}
+ mlxsw_sp_span_respin(mlxsw_sp_port->mlxsw_sp);
+
return err;
}
@@ -2236,8 +2281,16 @@ static void mlxsw_sp_switchdev_event_work(struct work_struct *work)
fdb_info = &switchdev_work->fdb_info;
mlxsw_sp_port_fdb_set(mlxsw_sp_port, fdb_info, false);
break;
+ case SWITCHDEV_FDB_ADD_TO_BRIDGE: /* fall through */
+ case SWITCHDEV_FDB_DEL_TO_BRIDGE:
+ /* These events are only used to potentially update an existing
+ * SPAN mirror.
+ */
+ break;
}
+ mlxsw_sp_span_respin(mlxsw_sp_port->mlxsw_sp);
+
out:
rtnl_unlock();
kfree(switchdev_work->fdb_info.addr);
@@ -2266,7 +2319,9 @@ static int mlxsw_sp_switchdev_event(struct notifier_block *unused,
switch (event) {
case SWITCHDEV_FDB_ADD_TO_DEVICE: /* fall through */
- case SWITCHDEV_FDB_DEL_TO_DEVICE:
+ case SWITCHDEV_FDB_DEL_TO_DEVICE: /* fall through */
+ case SWITCHDEV_FDB_ADD_TO_BRIDGE: /* fall through */
+ case SWITCHDEV_FDB_DEL_TO_BRIDGE:
memcpy(&switchdev_work->fdb_info, ptr,
sizeof(switchdev_work->fdb_info));
switchdev_work->fdb_info.addr = kzalloc(ETH_ALEN, GFP_ATOMIC);
--
2.14.3
^ permalink raw reply related
* [PATCH net-next] udp: remove stray export symbol
From: Willem de Bruijn @ 2018-04-27 15:12 UTC (permalink / raw)
To: netdev; +Cc: davem, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
UDP GSO needs to export __udp_gso_segment to call it from ipv6.
I accidentally exported static ipv4 function __udp4_gso_segment.
Remove that EXPORT_SYMBOL_GPL.
Fixes: ee80d1ebe5ba ("udp: add udp gso")
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/ipv4/udp_offload.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index dc5158cba66e..f78fb3673472 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -247,7 +247,6 @@ static struct sk_buff *__udp4_gso_segment(struct sk_buff *gso_skb,
udp_v4_check(sizeof(struct udphdr) + mss,
iph->saddr, iph->daddr, 0));
}
-EXPORT_SYMBOL_GPL(__udp4_gso_segment);
static struct sk_buff *udp4_ufo_fragment(struct sk_buff *skb,
netdev_features_t features)
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* [PATCH net-next v2 6/6] mlxsw: spectrum_span: Allow bridge for gretap mirror
From: Ido Schimmel @ 2018-04-27 15:11 UTC (permalink / raw)
To: netdev, bridge; +Cc: davem, jiri, petrm, nikolay, stephen, mlxsw, Ido Schimmel
In-Reply-To: <20180427151111.22099-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
When handling mirroring to a gretap or ip6gretap netdevice in mlxsw, the
underlay address (i.e. the remote address of the tunnel) may be routed
to a bridge.
In that case, look up the resolved neighbor Ethernet address in that
bridge's FDB. Then configure the offload to direct the mirrored traffic
to that port, possibly with tagging.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
.../net/ethernet/mellanox/mlxsw/spectrum_span.c | 95 ++++++++++++++++++++--
.../net/ethernet/mellanox/mlxsw/spectrum_span.h | 1 +
2 files changed, 90 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
index 65a77708ff61..adac4304dad5 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
@@ -32,6 +32,7 @@
* POSSIBILITY OF SUCH DAMAGE.
*/
+#include <linux/if_bridge.h>
#include <linux/list.h>
#include <net/arp.h>
#include <net/gre.h>
@@ -39,8 +40,9 @@
#include <net/ip6_tunnel.h>
#include "spectrum.h"
-#include "spectrum_span.h"
#include "spectrum_ipip.h"
+#include "spectrum_span.h"
+#include "spectrum_switchdev.h"
int mlxsw_sp_span_init(struct mlxsw_sp *mlxsw_sp)
{
@@ -167,6 +169,72 @@ mlxsw_sp_span_entry_unoffloadable(struct mlxsw_sp_span_parms *sparmsp)
return 0;
}
+static struct net_device *
+mlxsw_sp_span_entry_bridge_8021q(const struct net_device *br_dev,
+ unsigned char *dmac,
+ u16 *p_vid)
+{
+ struct bridge_vlan_info vinfo;
+ struct net_device *edev;
+ u16 pvid;
+
+ if (WARN_ON(br_vlan_pvid_rtnl(br_dev, &pvid)))
+ return NULL;
+ if (!pvid)
+ return NULL;
+
+ edev = br_fdb_find_port_rtnl(br_dev, dmac, pvid);
+ if (!edev)
+ return NULL;
+
+ if (br_vlan_info_rtnl(edev, pvid, &vinfo))
+ return NULL;
+ if (!(vinfo.flags & BRIDGE_VLAN_INFO_UNTAGGED))
+ *p_vid = pvid;
+ return edev;
+}
+
+static struct net_device *
+mlxsw_sp_span_entry_bridge_8021d(const struct net_device *br_dev,
+ unsigned char *dmac)
+{
+ return br_fdb_find_port_rtnl(br_dev, dmac, 0);
+}
+
+static struct net_device *
+mlxsw_sp_span_entry_bridge(const struct net_device *br_dev,
+ unsigned char dmac[ETH_ALEN],
+ u16 *p_vid)
+{
+ struct mlxsw_sp_bridge_port *bridge_port;
+ enum mlxsw_reg_spms_state spms_state;
+ struct mlxsw_sp_port *port;
+ struct net_device *dev;
+ u8 stp_state;
+
+ if (br_vlan_enabled(br_dev))
+ dev = mlxsw_sp_span_entry_bridge_8021q(br_dev, dmac, p_vid);
+ else
+ dev = mlxsw_sp_span_entry_bridge_8021d(br_dev, dmac);
+ if (!dev)
+ return NULL;
+
+ port = mlxsw_sp_port_dev_lower_find(dev);
+ if (!port)
+ return NULL;
+
+ bridge_port = mlxsw_sp_bridge_port_find(port->mlxsw_sp->bridge, dev);
+ if (!bridge_port)
+ return NULL;
+
+ stp_state = mlxsw_sp_bridge_port_stp_state(bridge_port);
+ spms_state = mlxsw_sp_stp_spms_state(stp_state);
+ if (spms_state != MLXSW_REG_SPMS_STATE_FORWARDING)
+ return NULL;
+
+ return dev;
+}
+
static __maybe_unused int
mlxsw_sp_span_entry_tunnel_parms_common(struct net_device *l3edev,
union mlxsw_sp_l3addr saddr,
@@ -177,13 +245,22 @@ mlxsw_sp_span_entry_tunnel_parms_common(struct net_device *l3edev,
struct mlxsw_sp_span_parms *sparmsp)
{
unsigned char dmac[ETH_ALEN];
+ u16 vid = 0;
if (mlxsw_sp_l3addr_is_zero(gw))
gw = daddr;
- if (!l3edev || !mlxsw_sp_port_dev_check(l3edev) ||
- mlxsw_sp_span_dmac(tbl, &gw, l3edev, dmac))
- return mlxsw_sp_span_entry_unoffloadable(sparmsp);
+ if (!l3edev || mlxsw_sp_span_dmac(tbl, &gw, l3edev, dmac))
+ goto unoffloadable;
+
+ if (netif_is_bridge_master(l3edev)) {
+ l3edev = mlxsw_sp_span_entry_bridge(l3edev, dmac, &vid);
+ if (!l3edev)
+ goto unoffloadable;
+ }
+
+ if (!mlxsw_sp_port_dev_check(l3edev))
+ goto unoffloadable;
sparmsp->dest_port = netdev_priv(l3edev);
sparmsp->ttl = ttl;
@@ -191,7 +268,11 @@ mlxsw_sp_span_entry_tunnel_parms_common(struct net_device *l3edev,
memcpy(sparmsp->smac, l3edev->dev_addr, ETH_ALEN);
sparmsp->saddr = saddr;
sparmsp->daddr = daddr;
+ sparmsp->vid = vid;
return 0;
+
+unoffloadable:
+ return mlxsw_sp_span_entry_unoffloadable(sparmsp);
}
#if IS_ENABLED(CONFIG_NET_IPGRE)
@@ -268,9 +349,10 @@ mlxsw_sp_span_entry_gretap4_configure(struct mlxsw_sp_span_entry *span_entry,
/* Create a new port analayzer entry for local_port. */
mlxsw_reg_mpat_pack(mpat_pl, pa_id, local_port, true,
MLXSW_REG_MPAT_SPAN_TYPE_REMOTE_ETH_L3);
+ mlxsw_reg_mpat_eth_rspan_pack(mpat_pl, sparms.vid);
mlxsw_reg_mpat_eth_rspan_l2_pack(mpat_pl,
MLXSW_REG_MPAT_ETH_RSPAN_VERSION_NO_HEADER,
- sparms.dmac, false);
+ sparms.dmac, !!sparms.vid);
mlxsw_reg_mpat_eth_rspan_l3_ipv4_pack(mpat_pl,
sparms.ttl, sparms.smac,
be32_to_cpu(sparms.saddr.addr4),
@@ -368,9 +450,10 @@ mlxsw_sp_span_entry_gretap6_configure(struct mlxsw_sp_span_entry *span_entry,
/* Create a new port analayzer entry for local_port. */
mlxsw_reg_mpat_pack(mpat_pl, pa_id, local_port, true,
MLXSW_REG_MPAT_SPAN_TYPE_REMOTE_ETH_L3);
+ mlxsw_reg_mpat_eth_rspan_pack(mpat_pl, sparms.vid);
mlxsw_reg_mpat_eth_rspan_l2_pack(mpat_pl,
MLXSW_REG_MPAT_ETH_RSPAN_VERSION_NO_HEADER,
- sparms.dmac, false);
+ sparms.dmac, !!sparms.vid);
mlxsw_reg_mpat_eth_rspan_l3_ipv6_pack(mpat_pl, sparms.ttl, sparms.smac,
sparms.saddr.addr6,
sparms.daddr.addr6);
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.h
index 4b87ec20e658..14a6de904db1 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.h
@@ -63,6 +63,7 @@ struct mlxsw_sp_span_parms {
unsigned char smac[ETH_ALEN];
union mlxsw_sp_l3addr daddr;
union mlxsw_sp_l3addr saddr;
+ u16 vid;
};
struct mlxsw_sp_span_entry_ops;
--
2.14.3
^ 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