* Re: [PATCH net-next v3 02/10] net: mvpp2: phylink support
From: Russell King - ARM Linux @ 2018-08-31 14:11 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180831133651.GB32574@kwain>
On Fri, Aug 31, 2018 at 03:36:51PM +0200, Antoine Tenart wrote:
> With the above code remove one case did not worked anymore: when the
> port is configured as a fixed-link because the SFP cage can't be
> described and used (on the 7040-db and 8040-db boards). In such cases
> phylink is called, mac_config() is called, but link_up() is never
> called. I'm not sure this is actually an issue in phylink, but the PPv2
> driver should probably take care of this weird case itself (by calling
> explicitly link_up()). What do you think?
Fixed link should work:
- when a fixed link is configured, link_config.link is set true.
- when phylink_start() is called, mac_config() will be called to do the
initial setup, and a resolve is triggered.
- phylink_resolve() will read the fixed link state, which in the case
of no GPIO, will inherit link_config.link.
- you will then see another mac_config() call.
Now what happens depends whether you've set the netdev's carrier state
in the driver - if you haven't, the netdev's carrier state should be
off. Since the state mismatches the link_state.link (which will be
true), you will get a mac_link_up() call.
mvneta ensures this state by always calling netif_carrier_off() in
mvneta_open(), maybe that ought to be in phylink_start() as that's the
state that phylink expects when phylink_start() has been called. So,
maybe it's a phylink bug.
Can you see any down-sides to moving the netif_carrier_off() in
mvneta_open() to phylink_start() ?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
^ permalink raw reply
* Re: [PATCH RFC net-next 00/11] udp gso
From: Eric Dumazet @ 2018-08-31 10:09 UTC (permalink / raw)
To: Paolo Abeni, Willem de Bruijn, Sowmini Varadhan
Cc: Network Development, Willem de Bruijn
In-Reply-To: <8b4de31a06d9bdb69e348f88ad0dcbf7d8576477.camel@redhat.com>
On 08/31/2018 02:09 AM, Paolo Abeni wrote:
> I hope quic can leverage such scenario, but I
> really know nothing about the protocol.
>
Most QUIC receivers are mobile phones, laptops, with wifi without GRO anyway...
Even if they had GRO, the inter-packet delay would be too high for GRO to be successful.
(vast majority of QUIC flows are < 100 Mbits because of the last mile hop)
GSO UDP is used on servers with clear gains, but there are not
really high speed receivers where GRO could be used.
^ permalink raw reply
* Re: [PATCH 04/15] soc: octeontx2: Add mailbox support infra
From: Arnd Bergmann @ 2018-08-31 14:16 UTC (permalink / raw)
To: Sunil Kovvuri
Cc: Linux Kernel Mailing List, Olof Johansson, Linux ARM, linux-soc,
amakarov, sgoutham, lbartosik, Networking, David Miller
In-Reply-To: <CA+sq2CfjJjswOwypNMtro+g8TeHGoBqAeKpFrf2ys-1=Xg+qHw@mail.gmail.com>
On Thu, Aug 30, 2018 at 8:37 PM Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote:
> On Thu, Aug 30, 2018 at 7:27 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tue, Aug 28, 2018 at 3:23 PM Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote:
> > > On Tue, Aug 28, 2018 at 6:22 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Tue, Aug 28, 2018 at 2:48 PM Sunil Kovvuri <sunil.kovvuri@gmail.com> wrote:
> > > Any PCI device here irrespective in what domain (kernel or userspace)
> > > they are in
> > > use common mailbox communication. Which is
> > > # Write a mailbox msg (format is agreed between all parties) into
> > > shared (between AF and other PF/VFs)
> > > memory region and trigger a interrupt to admin function.
> > > # Admin function processes the msg and puts reply in the same memory
> > > region and trigger
> > > IRQ to the requesting device. If the device has a driver instance
> > > in kernel then it uses
> > > IRQ and userspace applications does polling on the IRQ status bit.
> >
> > What is the purpose of the exported interface then? Is this
> > just an abstraction so each of the drivers can talk to its own
> > mailbox using a set of common helper functions?
> >
>
> Yes, that's correct.
>
> In kernel there will be a minimum of 3 drivers which will use this
> mailbox communication.
> So instead of duplicating APIs and structures in every driver, we
> thought of adding them in this AF driver and export them to ethernet
> and crypto drivers.
Ok. My feeling is then that the API is fine, but that it should not
be part of the AF module but rather be a standalone module.
My comment about the generic mailbox API no longer applies
here: you don't have a single shared mailbox hardware interface,
but each device has its own mailbox register set, so there
is no point in setting up a separate device for it, but I see
no need for creating an artificial dependency on the AF
driver. E.g. in a virtual machine that only has one ethernet
interface, you otherwise wouldn't load that driver, right?
Arnd
^ permalink raw reply
* Re: [PATCH net-next v3 02/10] net: mvpp2: phylink support
From: Andrew Lunn @ 2018-08-31 14:18 UTC (permalink / raw)
To: Antoine Tenart
Cc: Russell King - ARM Linux, davem, kishon, gregory.clement, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180831133651.GB32574@kwain>
> @@ -4691,6 +4685,9 @@ static int mvpp2_port_probe(struct platform_device *pdev,
> if (fwnode_property_read_bool(port_fwnode, "marvell,loopback"))
> port->flags |= MVPP2_F_LOOPBACK;
>
> + if (fwnode_property_present(port_fwnode, "fixed-link"))
> + port->flags |= MVPP2_F_FIXED_LINK;
> +
Hi Antoine
There is no need to go look in device tree. When phylink calls
mac_config() it passes mode == MLO_AN_FIXED, when it is using a fixed
link.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v3 02/10] net: mvpp2: phylink support
From: Antoine Tenart @ 2018-08-31 14:23 UTC (permalink / raw)
To: Andrew Lunn
Cc: Antoine Tenart, Russell King - ARM Linux, davem, kishon,
gregory.clement, jason, sebastian.hesselbarth, netdev,
linux-kernel, thomas.petazzoni, maxime.chevallier, miquel.raynal,
nadavh, stefanc, ymarkman, mw, linux-arm-kernel
In-Reply-To: <20180831141851.GA19733@lunn.ch>
Hi Andrew,
On Fri, Aug 31, 2018 at 04:18:51PM +0200, Andrew Lunn wrote:
> > @@ -4691,6 +4685,9 @@ static int mvpp2_port_probe(struct platform_device *pdev,
> > if (fwnode_property_read_bool(port_fwnode, "marvell,loopback"))
> > port->flags |= MVPP2_F_LOOPBACK;
> >
> > + if (fwnode_property_present(port_fwnode, "fixed-link"))
> > + port->flags |= MVPP2_F_FIXED_LINK;
> > +
>
> There is no need to go look in device tree. When phylink calls
> mac_config() it passes mode == MLO_AN_FIXED, when it is using a fixed
> link.
Sure. This was a proposal to have a workaround when phylink does not
call link_up(), so that we know which mode to pass to the function.
In the meantime Russell explained an assumption about the carrier link
state made by phylink, and a proposal to avoid doing this kind of hack
in the driver. I'll test his solution which will probably means we can
drop this piece of code.
Thanks!
Antoine
--
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 1/2] net/ibm/emac: wrong emac_calc_base call was used by typo
From: Ivan Mikhaylov1 @ 2018-08-31 10:18 UTC (permalink / raw)
To: Christian Lamparter; +Cc: netdev, David S . Miller, linux-kernel
In-Reply-To: <13714694.2rXNjIIGUQ@debian64>
>I do have a ot question though:
>Since you are working for IBM and probably have access to all the
>wonderful docs and the working hardware: Would you consider to be
>the emac/emac4/emac-sync maintainer? From what I can parse from
>the /MAINTAINERS file, there isn't currently anyone listed.
Unfortunately, I can't take this obligation due to some circumstances
in the future.
^ permalink raw reply
* Re: [PATCH net-next v3 02/10] net: mvpp2: phylink support
From: Andrew Lunn @ 2018-08-31 14:37 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Antoine Tenart, davem, kishon, gregory.clement, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180831141123.GM30658@n2100.armlinux.org.uk>
> Can you see any down-sides to moving the netif_carrier_off() in
> mvneta_open() to phylink_start() ?
This sounds like a good idea.
What happens on the resume path?
I've not looked at any code.... Just thinking aloud. Can we suspend
with the link up? When we resume, so long as we were not doing WoL,
the link is down. If phylink_start() is not called, we have this miss
match again.
And what about the WoL case? The link is up. What happens if you do a
netif_carrier_off() in phylink_start(), you again have a miss match.
But that case is pretty common with us developers, tftpbooting the
box, with uboot setting the link up before handing over the Linux. So
that case probably works already.
Andrew
^ permalink raw reply
* Re: [PATCH bpf-next 3/3] i40e: adapt driver to new xdp_umem structure
From: Daniel Borkmann @ 2018-08-31 10:34 UTC (permalink / raw)
To: Magnus Karlsson, bjorn.topel, ast, netdev
In-Reply-To: <1535637403-14549-4-git-send-email-magnus.karlsson@intel.com>
On 08/30/2018 03:56 PM, Magnus Karlsson wrote:
> The struct xdp_umem_props was removed in the xsk code and this commit
> adapts the i40e af_xdp zero-copy driver code to the new xdp_umem
> structure.
>
> Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_xsk.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_xsk.c b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
> index 41ca7e1..2ebfc78 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_xsk.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
> @@ -442,7 +442,7 @@ static void i40e_reuse_rx_buffer_zc(struct i40e_ring *rx_ring,
> struct i40e_rx_buffer *old_bi)
> {
> struct i40e_rx_buffer *new_bi = &rx_ring->rx_bi[rx_ring->next_to_alloc];
> - unsigned long mask = (unsigned long)rx_ring->xsk_umem->props.chunk_mask;
> + unsigned long mask = (unsigned long)rx_ring->xsk_umem->chunk_mask;
That is buggy indeed, kbuild bot complained that this hurts bisectability
because you removed struct xdp_umem_props props from umem in prior patch.
Please respin the full series with this one squashed into prior commit instead
and I'll toss the old one from bpf-next tree.
> u64 hr = rx_ring->xsk_umem->headroom + XDP_PACKET_HEADROOM;
> u16 nta = rx_ring->next_to_alloc;
>
> @@ -477,7 +477,7 @@ void i40e_zca_free(struct zero_copy_allocator *alloc, unsigned long handle)
>
> rx_ring = container_of(alloc, struct i40e_ring, zca);
> hr = rx_ring->xsk_umem->headroom + XDP_PACKET_HEADROOM;
> - mask = rx_ring->xsk_umem->props.chunk_mask;
> + mask = rx_ring->xsk_umem->chunk_mask;
>
> nta = rx_ring->next_to_alloc;
> bi = &rx_ring->rx_bi[nta];
>
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: rework SIOCGSTAMP ioctl handling
From: Willem de Bruijn @ 2018-08-31 15:08 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Network Development, David Miller, linux-arch, y2038 Mailman List,
Eric Dumazet, Willem de Bruijn, LKML, linux-hams, linux-bluetooth,
linux-can, dccp, linux-wpan, linux-sctp, linux-x25
In-Reply-To: <CAK8P3a00DLR9JyfKwbYXnKCpRf+YWuUyMbC+UfXZTfdnAJxRtg@mail.gmail.com>
> > > Looking at it again, it seems that sock_gettstamp() should
> > > actually deal with this gracefully: it will return a -EINVAL
> > > error condition if the timestamp remains at the
> > > SK_DEFAULT_STAMP initial value, which is probably
> > > just as appropriate (or better) as the current -ENOTTY
> > > default, and if we are actually recording timestamps, we
> > > might just as well report them.
> >
> > Yes, that's a nice solution. There is always some risk in changing
> > error codes. But ioctl callers should be able to support newly
> > implemented functionality. Even if partially implemented and
> > returning ENOENT instead of ENOIOCTLCMD.
>
> Ok, so do you think we should stay with the current version
> for now, and change the two points later, or should I rework
> it to integrate the locking and removing the callback?
>
> I suppose the series actually gets nicer without the
> callback, since I can simply add the generic timestamping
> implementation first, and then remove the dead ioctl
> handlers.
Agreed. I would add the locks in a separate patch, if only on the
off-chance that lockdep discovers something and it will be easier
to bisect and revise independently. I can also follow up with that
patch outside this set, of course.
^ permalink raw reply
* Re: [PATCH net-next v3 02/10] net: mvpp2: phylink support
From: Antoine Tenart @ 2018-08-31 15:08 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Antoine Tenart, davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180831141123.GM30658@n2100.armlinux.org.uk>
Hi Russell,
On Fri, Aug 31, 2018 at 03:11:23PM +0100, Russell King - ARM Linux wrote:
> On Fri, Aug 31, 2018 at 03:36:51PM +0200, Antoine Tenart wrote:
> > With the above code remove one case did not worked anymore: when the
> > port is configured as a fixed-link because the SFP cage can't be
> > described and used (on the 7040-db and 8040-db boards). In such cases
> > phylink is called, mac_config() is called, but link_up() is never
> > called. I'm not sure this is actually an issue in phylink, but the PPv2
> > driver should probably take care of this weird case itself (by calling
> > explicitly link_up()). What do you think?
>
> Fixed link should work:
>
> - when a fixed link is configured, link_config.link is set true.
> - when phylink_start() is called, mac_config() will be called to do the
> initial setup, and a resolve is triggered.
> - phylink_resolve() will read the fixed link state, which in the case
> of no GPIO, will inherit link_config.link.
> - you will then see another mac_config() call.
>
> Now what happens depends whether you've set the netdev's carrier state
> in the driver - if you haven't, the netdev's carrier state should be
> off. Since the state mismatches the link_state.link (which will be
> true), you will get a mac_link_up() call.
OK, that makes sense. Thanks for the explanations.
> mvneta ensures this state by always calling netif_carrier_off() in
> mvneta_open(), maybe that ought to be in phylink_start() as that's the
> state that phylink expects when phylink_start() has been called. So,
> maybe it's a phylink bug.
>
> Can you see any down-sides to moving the netif_carrier_off() in
> mvneta_open() to phylink_start() ?
I removed most of my previous fix, and called netif_carrier_off() just
before phylink_start() in PPv2. I worked, and it seemed to me all cases
were working fine.
As calling netif_carrier_off() seems to be a phylink assumption, I would
agree to call it directly from within phylink_start(). But I don't have
the full picture here.
If such a solution is OK for you, and if no one raises an issue in the
next days, I can send a series to add a netif_carrier_off() call, fix
PPv2, and remove mvneta's call to netif_carrier_off() in mvneta_open().
Thanks!
Antoine
--
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] rsi: remove set but not used variable 'header_size'
From: YueHaibing @ 2018-08-31 11:07 UTC (permalink / raw)
To: Kalle Valo, Pavani Muthyala, Kees Cook, Colin Ian King,
Amitkumar Karwar, Prameela Rani Garnepudi, Siva Rebbagondla,
Sushant Kumar Mishra
Cc: linux-wireless, netdev, kernel-janitors
In-Reply-To: <1535707647-191888-1-git-send-email-yuehaibing@huawei.com>
On 2018/8/31 17:27, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/rsi/rsi_91x_hal.c: In function 'rsi_send_data_pkt':
> drivers/net/wireless/rsi/rsi_91x_hal.c:288:5: warning:
> variable 'header_size' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/wireless/rsi/rsi_91x_hal.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rsi/rsi_91x_hal.c b/drivers/net/wireless/rsi/rsi_91x_hal.c
> index 01edf96..c4fb319 100644
> --- a/drivers/net/wireless/rsi/rsi_91x_hal.c
> +++ b/drivers/net/wireless/rsi/rsi_91x_hal.c
> @@ -285,7 +285,6 @@ int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb)
> struct skb_info *tx_params;
> struct ieee80211_bss_conf *bss;
> int status = -EINVAL;
> - u8 header_size;
>
> if (!skb)
> return 0;
> @@ -298,7 +297,6 @@ int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb)
> vif = info->control.vif;
> bss = &vif->bss_conf;
> tx_params = (struct skb_info *)info->driver_data;
tx_params also can be removed.
Will send V2.
> - header_size = tx_params->internal_hdr_size;
>
> if (((vif->type == NL80211_IFTYPE_STATION) ||
> (vif->type == NL80211_IFTYPE_P2P_CLIENT)) &&
>
>
> .
>
^ permalink raw reply
* [PATCH net-next 1/1] qed: Lower the severity of a dcbx log message.
From: Sudarsana Reddy Kalluru @ 2018-08-31 11:10 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon
Driver displays an error message for each unrecognized dcbx TLV that's
received from the peer or configured on the device. It is observed that
syslog will be flooded with such messages in certain scenarios e.g.,
frequent link-flaps/lldp-transactions. Changing the severity of this
message to verbose level as it's not an error scenario/message.
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
index 6bb76e6..6ce9a76 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -253,8 +253,9 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
*type = DCBX_PROTOCOL_ROCE_V2;
} else {
*type = DCBX_MAX_PROTOCOL_TYPE;
- DP_ERR(p_hwfn, "No action required, App TLV entry = 0x%x\n",
- app_prio_bitmap);
+ DP_VERBOSE(p_hwfn, QED_MSG_DCB,
+ "No action required, App TLV entry = 0x%x\n",
+ app_prio_bitmap);
return false;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next v3 02/10] net: mvpp2: phylink support
From: Russell King - ARM Linux @ 2018-08-31 15:21 UTC (permalink / raw)
To: Andrew Lunn
Cc: Antoine Tenart, davem, kishon, gregory.clement, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180831143721.GB19733@lunn.ch>
On Fri, Aug 31, 2018 at 04:37:21PM +0200, Andrew Lunn wrote:
> > Can you see any down-sides to moving the netif_carrier_off() in
> > mvneta_open() to phylink_start() ?
>
> This sounds like a good idea.
>
> What happens on the resume path?
Suspend/resume should be safe, because we force the link down when
phylink_stop() is called.
Looking at mvneta again, mvneta_stop_dev() is called in the suspend
path, which then calls phylink_stop(). This causes us to call
mac_link_down() and netif_carrier_off(). So, at the point of suspend,
the netdev carrier is set down and the mac taken down.
When resuming, mvneta_start_dev() calls phylink_start(), which undoes
the changes above, calling mac_link_up() if the link is now up.
So, as long as netdevs don't mess with the carrier state in their
suspend/resume functions, and they call phylink_start()/phylink_stop()
there, everything will work as intended - and that's really the key
issue here.
> I've not looked at any code.... Just thinking aloud. Can we suspend
> with the link up? When we resume, so long as we were not doing WoL,
> the link is down. If phylink_start() is not called, we have this miss
> match again.
It depends what you mean by "link up". Are you talking about the PHYs
link to the external world (which is normally what's responsible for
handling WOL) or are you talking about keeping the MAC and its rings
alive so it can process packets while suspended.
If the former, that's the responsibility of phylib to manage, if the
latter, the netdev must not call phylink_stop() in its suspend function.
Either way, not messing with the netdev's carrier state is key.
The only exception to this is that the carrier should be down at open()
time. However, I don't see anything in net/core that fiddles with the
carrier state for a net device, so the default state at boot should be
carrier-off.
I think some questions for Antoine are:
- what is the state of the carrier at the start of mvpp2_start() ?
- when does the missing call to mac_link_up() occur - is it the first
time the netdev is brought up, or a subsequent time?
- is the carrier always off at the end of mvpp2_stop()?
Having a local reproducer may help, so if you can point to a DT fragment
and set of steps to reproduce, it could be helpful.
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
^ permalink raw reply
* Re: [PATCH bpf-next] samples/bpf: xdpsock, minor fixes
From: Daniel Borkmann @ 2018-08-31 11:17 UTC (permalink / raw)
To: Prashant Bhole, Alexei Starovoitov, Björn Töpel,
Magnus Karlsson
Cc: netdev
In-Reply-To: <20180831010049.9388-1-bhole_prashant_q7@lab.ntt.co.jp>
On 08/31/2018 03:00 AM, Prashant Bhole wrote:
> - xsks_map size was fixed to 4, changed it MAX_SOCKS
> - Remove redundant definition of MAX_SOCKS in xdpsock_user.c
> - In dump_stats(), add NULL check for xsks[i]
>
> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
Applied, thanks Prashant!
^ permalink raw reply
* Re: [PATCH bpf-next] xsk: remove unnecessary assignment
From: Daniel Borkmann @ 2018-08-31 11:17 UTC (permalink / raw)
To: Prashant Bhole, Alexei Starovoitov, Björn Töpel,
Magnus Karlsson
Cc: netdev
In-Reply-To: <20180831005916.9276-1-bhole_prashant_q7@lab.ntt.co.jp>
On 08/31/2018 02:59 AM, Prashant Bhole wrote:
> Since xdp_umem_query() was added one assignment of bpf.command was
> missed from cleanup. Removing the assignment statement.
>
> Fixes: 84c6b86875e01a0 ("xsk: don't allow umem replace at stack level")
> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
Applied, thanks Prashant!
^ permalink raw reply
* [PATCH net-next v2 1/2] netlink: ipv4 igmp join notifications
From: Patrick Ruddy @ 2018-08-31 11:20 UTC (permalink / raw)
To: netdev; +Cc: roopa, jiri, stephen
In-Reply-To: <20180830093545.29465-2-pruddy@vyatta.att-mail.com>
Some userspace applications need to know about IGMP joins from the kernel
for 2 reasons
1. To allow the programming of multicast MAC filters in hardware
2. To form a multicast FORUS list for non link-local multicast
groups to be sent to the kernel and from there to the interested
party.
(1) can be fulfilled but simply sending the hardware multicast MAC
address to be programmed but (2) requires the L3 address to be sent
since this cannot be constructed from the MAC address whereas the
reverse translation is a standard library function.
This commit provides addition and deletion of multicast addresses
using the RTM_NEWADDR and RTM_DELADDR messages. It also provides
the RTM_GETADDR extension to allow multicast join state to be read
from the kernel.
Signed-off-by: Patrick Ruddy <pruddy@vyatta.att-mail.com>
---
v2: fix kbuild warnings.
include/linux/igmp.h | 4 ++
net/ipv4/devinet.c | 39 +++++++++++++------
net/ipv4/igmp.c | 90 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 122 insertions(+), 11 deletions(-)
diff --git a/include/linux/igmp.h b/include/linux/igmp.h
index 119f53941c12..644a548024ed 100644
--- a/include/linux/igmp.h
+++ b/include/linux/igmp.h
@@ -19,6 +19,8 @@
#include <linux/timer.h>
#include <linux/in.h>
#include <linux/refcount.h>
+#include <linux/netlink.h>
+#include <linux/netdevice.h>
#include <uapi/linux/igmp.h>
static inline struct igmphdr *igmp_hdr(const struct sk_buff *skb)
@@ -130,6 +132,8 @@ extern void ip_mc_unmap(struct in_device *);
extern void ip_mc_remap(struct in_device *);
extern void ip_mc_dec_group(struct in_device *in_dev, __be32 addr);
extern void ip_mc_inc_group(struct in_device *in_dev, __be32 addr);
+extern int ip_mc_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb,
+ struct net_device *dev);
int ip_mc_check_igmp(struct sk_buff *skb, struct sk_buff **skb_trimmed);
#endif
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index ea4bd8a52422..42f7dcc4fb5e 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -57,6 +57,7 @@
#endif
#include <linux/kmod.h>
#include <linux/netconf.h>
+#include <linux/igmp.h>
#include <net/arp.h>
#include <net/ip.h>
@@ -1651,6 +1652,7 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
int h, s_h;
int idx, s_idx;
int ip_idx, s_ip_idx;
+ int multicast, mcast_idx;
struct net_device *dev;
struct in_device *in_dev;
struct in_ifaddr *ifa;
@@ -1659,6 +1661,8 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
s_h = cb->args[0];
s_idx = idx = cb->args[1];
s_ip_idx = ip_idx = cb->args[2];
+ multicast = cb->args[3];
+ mcast_idx = cb->args[4];
for (h = s_h; h < NETDEV_HASHENTRIES; h++, s_idx = 0) {
idx = 0;
@@ -1675,18 +1679,29 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
if (!in_dev)
goto cont;
- for (ifa = in_dev->ifa_list, ip_idx = 0; ifa;
- ifa = ifa->ifa_next, ip_idx++) {
- if (ip_idx < s_ip_idx)
- continue;
- if (inet_fill_ifaddr(skb, ifa,
- NETLINK_CB(cb->skb).portid,
- cb->nlh->nlmsg_seq,
- RTM_NEWADDR, NLM_F_MULTI) < 0) {
- rcu_read_unlock();
- goto done;
+ if (!multicast) {
+ for (ifa = in_dev->ifa_list, ip_idx = 0; ifa;
+ ifa = ifa->ifa_next, ip_idx++) {
+ if (ip_idx < s_ip_idx)
+ continue;
+ if (inet_fill_ifaddr(skb, ifa,
+ NETLINK_CB(cb->skb).portid,
+ cb->nlh->nlmsg_seq,
+ RTM_NEWADDR,
+ NLM_F_MULTI) < 0) {
+ rcu_read_unlock();
+ goto done;
+ }
+ nl_dump_check_consistent(cb,
+ nlmsg_hdr(skb));
}
- nl_dump_check_consistent(cb, nlmsg_hdr(skb));
+ /* set for multicast loop */
+ multicast++;
+ }
+ /* loop over multicast addresses */
+ if (ip_mc_dump_ifaddr(skb, cb, dev) < 0) {
+ rcu_read_unlock();
+ goto done;
}
cont:
idx++;
@@ -1698,6 +1713,8 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
cb->args[0] = h;
cb->args[1] = idx;
cb->args[2] = ip_idx;
+ cb->args[3] = multicast;
+ cb->args[4] = mcast_idx;
return skb->len;
}
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index cf75f8944b05..c9bbd1d27124 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -86,6 +86,7 @@
#include <linux/inetdevice.h>
#include <linux/igmp.h>
#include <linux/if_arp.h>
+#include <net/netlink.h>
#include <linux/rtnetlink.h>
#include <linux/times.h>
#include <linux/pkt_sched.h>
@@ -1384,6 +1385,91 @@ static void ip_mc_hash_remove(struct in_device *in_dev,
}
+static int fill_addr(struct sk_buff *skb, struct net_device *dev, __be32 addr,
+ int type, unsigned int flags)
+{
+ struct nlmsghdr *nlh;
+ struct ifaddrmsg *ifm;
+
+ nlh = nlmsg_put(skb, 0, 0, type, sizeof(*ifm), flags);
+ if (!nlh)
+ return -EMSGSIZE;
+
+ ifm = nlmsg_data(nlh);
+ ifm->ifa_family = AF_INET;
+ ifm->ifa_prefixlen = 32;
+ ifm->ifa_flags = IFA_F_PERMANENT;
+ ifm->ifa_scope = RT_SCOPE_LINK;
+ ifm->ifa_index = dev->ifindex;
+
+ if (nla_put_in_addr(skb, IFA_ADDRESS, addr))
+ goto nla_put_failure;
+ nlmsg_end(skb, nlh);
+ return 0;
+
+nla_put_failure:
+ nlmsg_cancel(skb, nlh);
+ return -EMSGSIZE;
+}
+
+static inline size_t addr_nlmsg_size(void)
+{
+ return NLMSG_ALIGN(sizeof(struct ifaddrmsg))
+ + nla_total_size(sizeof(__be32));
+}
+
+static void ip_mc_addr_notify(struct net_device *dev, __be32 addr, int type)
+{
+ struct net *net = dev_net(dev);
+ struct sk_buff *skb;
+ int err = -ENOBUFS;
+
+ skb = nlmsg_new(addr_nlmsg_size(), GFP_ATOMIC);
+ if (!skb)
+ goto errout;
+
+ err = fill_addr(skb, dev, addr, type, 0);
+ if (err < 0) {
+ WARN_ON(err == -EMSGSIZE);
+ kfree_skb(skb);
+ goto errout;
+ }
+ rtnl_notify(skb, net, 0, RTNLGRP_IPV4_IFADDR, NULL, GFP_ATOMIC);
+ return;
+errout:
+ if (err < 0)
+ rtnl_set_sk_err(net, RTNLGRP_LINK, err);
+}
+
+int ip_mc_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb,
+ struct net_device *dev)
+{
+ int s_idx;
+ int idx = 0;
+ struct ip_mc_list *im;
+ struct in_device *in_dev;
+
+ ASSERT_RTNL();
+
+ s_idx = cb->args[4];
+ in_dev = __in_dev_get_rtnl(dev);
+
+ for_each_pmc_rtnl(in_dev, im) {
+ if (idx < s_idx)
+ continue;
+ if (fill_addr(skb, dev, im->multiaddr, RTM_NEWADDR,
+ NLM_F_MULTI) < 0)
+ goto done;
+ nl_dump_check_consistent(cb, nlmsg_hdr(skb));
+ idx++;
+ }
+
+ done:
+ cb->args[4] = idx;
+
+ return skb->len;
+}
+
/*
* A socket has joined a multicast group on device dev.
*/
@@ -1433,6 +1519,8 @@ static void __ip_mc_inc_group(struct in_device *in_dev, __be32 addr,
igmpv3_del_delrec(in_dev, im);
#endif
igmp_group_added(im);
+
+ ip_mc_addr_notify(in_dev->dev, addr, RTM_NEWADDR);
if (!in_dev->dead)
ip_rt_multicast_event(in_dev);
out:
@@ -1664,6 +1752,8 @@ void ip_mc_dec_group(struct in_device *in_dev, __be32 addr)
in_dev->mc_count--;
igmp_group_dropped(i);
ip_mc_clear_src(i);
+ ip_mc_addr_notify(in_dev->dev, addr,
+ RTM_DELADDR);
if (!in_dev->dead)
ip_rt_multicast_event(in_dev);
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 2/2] netlink: ipv6 MLD join notifications
From: Patrick Ruddy @ 2018-08-31 11:20 UTC (permalink / raw)
To: netdev; +Cc: roopa, jiri, stephen
In-Reply-To: <20180831112024.30477-1-pruddy@vyatta.att-mail.com>
Some userspace applications need to know about MLD joins from the
kernel for 2 reasons:
1. To allow the programming of multicast MAC filters in hardware
2. To form a multicast FORUS list for non link-local multicast
groups to be sent to the kernel and from there to the interested
party.
(1) can be fulfilled but simply sending the hardware multicast MAC
address to be programmed but (2) requires the L3 address to be sent
since this cannot be constructed from the MAC address whereas the
reverse translation is a standard library function.
This commit provides addition and deletion of multicast addresses
using the RTM_NEWADDR and RTM_DELADDR messages. It also provides
the RTM_GETADDR extension to allow multicast join state to be read
from the kernel.
Signed-off-by: Patrick Ruddy <pruddy@vyatta.att-mail.com>
---
v2: fix kbuild issues.
net/ipv6/addrconf.c | 44 +++++++++++++++++++++---------
net/ipv6/mcast.c | 66 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 98 insertions(+), 12 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index d51a8c0b3372..0b609c7897b4 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -4855,11 +4855,13 @@ static int inet6_fill_ifaddr(struct sk_buff *skb, struct inet6_ifaddr *ifa,
}
static int inet6_fill_ifmcaddr(struct sk_buff *skb, struct ifmcaddr6 *ifmca,
- u32 portid, u32 seq, int event, u16 flags)
+ u32 portid, u32 seq, int event, u16 flags)
{
struct nlmsghdr *nlh;
u8 scope = RT_SCOPE_UNIVERSE;
int ifindex = ifmca->idev->dev->ifindex;
+ int addr_type = (event == RTM_GETMULTICAST) ? IFA_MULTICAST :
+ IFA_ADDRESS;
if (ipv6_addr_scope(&ifmca->mca_addr) & IFA_SITE)
scope = RT_SCOPE_SITE;
@@ -4869,7 +4871,7 @@ static int inet6_fill_ifmcaddr(struct sk_buff *skb, struct ifmcaddr6 *ifmca,
return -EMSGSIZE;
put_ifaddrmsg(nlh, 128, IFA_F_PERMANENT, scope, ifindex);
- if (nla_put_in6_addr(skb, IFA_MULTICAST, &ifmca->mca_addr) < 0 ||
+ if (nla_put_in6_addr(skb, addr_type, &ifmca->mca_addr) < 0 ||
put_cacheinfo(skb, ifmca->mca_cstamp, ifmca->mca_tstamp,
INFINITY_LIFE_TIME, INFINITY_LIFE_TIME) < 0) {
nlmsg_cancel(skb, nlh);
@@ -4916,7 +4918,7 @@ enum addr_type_t {
/* called with rcu_read_lock() */
static int in6_dump_addrs(struct inet6_dev *idev, struct sk_buff *skb,
struct netlink_callback *cb, enum addr_type_t type,
- int s_ip_idx, int *p_ip_idx)
+ int s_ip_idx, int *p_ip_idx, int msg_type)
{
struct ifmcaddr6 *ifmca;
struct ifacaddr6 *ifaca;
@@ -4935,7 +4937,7 @@ static int in6_dump_addrs(struct inet6_dev *idev, struct sk_buff *skb,
err = inet6_fill_ifaddr(skb, ifa,
NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq,
- RTM_NEWADDR,
+ msg_type,
NLM_F_MULTI);
if (err < 0)
break;
@@ -4952,7 +4954,7 @@ static int in6_dump_addrs(struct inet6_dev *idev, struct sk_buff *skb,
err = inet6_fill_ifmcaddr(skb, ifmca,
NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq,
- RTM_GETMULTICAST,
+ msg_type,
NLM_F_MULTI);
if (err < 0)
break;
@@ -4967,7 +4969,7 @@ static int in6_dump_addrs(struct inet6_dev *idev, struct sk_buff *skb,
err = inet6_fill_ifacaddr(skb, ifaca,
NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq,
- RTM_GETANYCAST,
+ msg_type,
NLM_F_MULTI);
if (err < 0)
break;
@@ -4982,7 +4984,7 @@ static int in6_dump_addrs(struct inet6_dev *idev, struct sk_buff *skb,
}
static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,
- enum addr_type_t type)
+ enum addr_type_t type, int msg_type)
{
struct net *net = sock_net(skb->sk);
int h, s_h;
@@ -5012,7 +5014,7 @@ static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,
goto cont;
if (in6_dump_addrs(idev, skb, cb, type,
- s_ip_idx, &ip_idx) < 0)
+ s_ip_idx, &ip_idx, msg_type) < 0)
goto done;
cont:
idx++;
@@ -5029,16 +5031,34 @@ static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb,
static int inet6_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
{
- enum addr_type_t type = UNICAST_ADDR;
+ enum addr_type_t type;
+ int ret;
+
+ type = cb->args[3];
+ if (type == UNICAST_ADDR) {
+ ret = inet6_dump_addr(skb, cb, type, RTM_NEWADDR);
+ if (ret > 0)
+ goto done;
- return inet6_dump_addr(skb, cb, type);
+ /* reset indices and move on to multicast*/
+ cb->args[0] = 0;
+ cb->args[1] = 0;
+ cb->args[2] = 0;
+ type = MULTICAST_ADDR;
+ }
+
+ /* do the RTM_NEWADDR notifications for multicast type */
+ ret = inet6_dump_addr(skb, cb, type, RTM_NEWADDR);
+ done:
+ cb->args[3] = type;
+ return ret;
}
static int inet6_dump_ifmcaddr(struct sk_buff *skb, struct netlink_callback *cb)
{
enum addr_type_t type = MULTICAST_ADDR;
- return inet6_dump_addr(skb, cb, type);
+ return inet6_dump_addr(skb, cb, type, RTM_GETMULTICAST);
}
@@ -5046,7 +5066,7 @@ static int inet6_dump_ifacaddr(struct sk_buff *skb, struct netlink_callback *cb)
{
enum addr_type_t type = ANYCAST_ADDR;
- return inet6_dump_addr(skb, cb, type);
+ return inet6_dump_addr(skb, cb, type, RTM_GETANYCAST);
}
static int inet6_rtm_getaddr(struct sk_buff *in_skb, struct nlmsghdr *nlh,
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 4ae54aaca373..735fb6a8ad34 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -880,6 +880,67 @@ static struct ifmcaddr6 *mca_alloc(struct inet6_dev *idev,
return mc;
}
+static int fill_addr(struct sk_buff *skb, struct net_device *dev,
+ const struct in6_addr *addr, int type, unsigned int flags)
+{
+ struct nlmsghdr *nlh;
+ struct ifaddrmsg *ifm;
+ u8 scope = RT_SCOPE_UNIVERSE;
+
+ if (ipv6_addr_scope(addr) & IFA_SITE)
+ scope = RT_SCOPE_SITE;
+
+ nlh = nlmsg_put(skb, 0, 0, type, sizeof(*ifm), flags);
+ if (!nlh)
+ return -EMSGSIZE;
+
+ ifm = nlmsg_data(nlh);
+ ifm->ifa_family = AF_INET6;
+ ifm->ifa_prefixlen = 128;
+ ifm->ifa_flags = IFA_F_PERMANENT;
+ ifm->ifa_scope = scope;
+ ifm->ifa_index = dev->ifindex;
+
+ if (nla_put_in6_addr(skb, IFA_ADDRESS, addr))
+ goto nla_put_failure;
+ nlmsg_end(skb, nlh);
+ return 0;
+
+nla_put_failure:
+ nlmsg_cancel(skb, nlh);
+ return -EMSGSIZE;
+}
+
+static inline size_t addr_nlmsg_size(void)
+{
+ return NLMSG_ALIGN(sizeof(struct ifaddrmsg))
+ + nla_total_size(sizeof(struct in6_addr));
+}
+
+static void ipv6_mc_addr_notify(struct net_device *dev,
+ const struct in6_addr *addr, int type)
+{
+ struct net *net = dev_net(dev);
+ struct sk_buff *skb;
+ int err = -ENOBUFS;
+
+ skb = nlmsg_new(addr_nlmsg_size(), GFP_ATOMIC);
+ if (!skb)
+ goto errout;
+
+ err = fill_addr(skb, dev, addr, type, 0);
+ if (err < 0) {
+ WARN_ON(err == -EMSGSIZE);
+ kfree_skb(skb);
+ goto errout;
+ }
+ rtnl_notify(skb, net, 0, RTNLGRP_IPV6_IFADDR, NULL, GFP_ATOMIC);
+ return;
+errout:
+ if (err < 0)
+ rtnl_set_sk_err(net, RTNLGRP_IPV6_IFADDR, err);
+}
+
/*
* device multicast group inc (add if not found)
*/
@@ -932,6 +993,9 @@ static int __ipv6_dev_mc_inc(struct net_device *dev,
mld_del_delrec(idev, mc);
igmp6_group_added(mc);
+
+ ipv6_mc_addr_notify(dev, addr, RTM_NEWADDR);
+
ma_put(mc);
return 0;
}
@@ -960,6 +1024,8 @@ int __ipv6_dev_mc_dec(struct inet6_dev *idev, const struct in6_addr *addr)
igmp6_group_dropped(ma);
ip6_mc_clear_src(ma);
+ ipv6_mc_addr_notify(idev->dev, addr,
+ RTM_DELADDR);
ma_put(ma);
return 0;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] brcmsmac: Remove extra parentheses
From: Kalle Valo @ 2018-08-31 15:41 UTC (permalink / raw)
To: Varsha Rao
Cc: Lukas Bulwahn, Nicholas Mc Guire, Arend van Spriel, Franky Lin,
Hante Meuleman, Chi-Hsien Lin, Wright Feng, David S. Miller,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
brcm80211-dev-list.pdl-dY08KVG/lbpWk0Htik3J/w,
brcm80211-dev-list-+wT8y+m8/X5BDgjK7y7TUQ,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Varsha Rao
In-Reply-To: <20180725185625.4220-1-rvarsha016-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Varsha Rao <rvarsha016-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Remove the unnecessary parentheses to fix the clang warning of
> extraneous parentheses.
>
> Signed-off-by: Varsha Rao <rvarsha016-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Patch applied to wireless-drivers-next.git, thanks.
9e9e11d83238 brcmsmac: Remove extra parentheses
--
https://patchwork.kernel.org/patch/10544573/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] cw1200: Remove extra parentheses
From: Kalle Valo @ 2018-08-31 15:42 UTC (permalink / raw)
To: Varsha Rao
Cc: Lukas Bulwahn, Nicholas Mc Guire, Solomon Peachy, David S. Miller,
linux-wireless, netdev, linux-kernel, Varsha Rao
In-Reply-To: <20180725190011.4317-1-rvarsha016@gmail.com>
Varsha Rao <rvarsha016@gmail.com> wrote:
> Remove unnecessary parentheses to fix the extraneous parentheses clang
> warning.
>
> Signed-off-by: Varsha Rao <rvarsha016@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
057118edfc36 cw1200: Remove extra parentheses
--
https://patchwork.kernel.org/patch/10544575/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH RFC] net/mlx5_en: switch to Toeplitz RSS hash by default
From: Konstantin Khlebnikov @ 2018-08-31 11:29 UTC (permalink / raw)
To: netdev, Saeed Mahameed, Gal Pressman, Or Gerlitz, David S. Miller,
Tariq Toukan
XOR (MLX5_RX_HASH_FN_INVERTED_XOR8) gives only 8 bits.
It seems not enough for RFS. All other drivers use toeplitz.
Driver mlx4_en uses Toeplitz by default and warns if hash XOR is used
together with NETIF_F_RXHASH (enabled by default too): "Enabling both
XOR Hash function and RX Hashing can limit RPS functionality".
XOR is default in mlx5_en since commit 2be6967cdbc9
("net/mlx5e: Support ETH_RSS_HASH_XOR").
Hash function could be set via ethtool. But it would be nice to have
single standard for drivers or proper description why this one is special.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 5a7939e70190..def9fb5dcbff 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -4558,7 +4558,7 @@ void mlx5e_build_nic_params(struct mlx5_core_dev *mdev,
params->tx_min_inline_mode = mlx5e_params_calculate_tx_min_inline(mdev);
/* RSS */
- params->rss_hfunc = ETH_RSS_HASH_XOR;
+ params->rss_hfunc = ETH_RSS_HASH_TOP;
netdev_rss_key_fill(params->toeplitz_hash_key, sizeof(params->toeplitz_hash_key));
mlx5e_build_default_indir_rqt(params->indirection_rqt,
MLX5E_INDIR_RQT_SIZE, max_channels);
^ permalink raw reply related
* Re: [PATCH] orinoco: remove unused array encaps_hdr and macro ENCAPS_OVERHEAD
From: Kalle Valo @ 2018-08-31 15:45 UTC (permalink / raw)
To: Colin King
Cc: David S . Miller, linux-wireless, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20180816125944.7804-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Array encaps_hdr and macro ENCAPS_OVERHEAD are declared but are
> not being used, hence they are redundant and can be removed.
>
> Cleans up clang warning:
> warning: 'encaps_hdr' defined but not used [-Wunused-const-variable=]
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to wireless-drivers-next.git, thanks.
5945310a1755 orinoco: remove unused array encaps_hdr and macro ENCAPS_OVERHEAD
--
https://patchwork.kernel.org/patch/10567409/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH v2] xfrm6: call kfree_skb when skb is toobig
From: Thadeu Lima de Souza Cascardo @ 2018-08-31 11:38 UTC (permalink / raw)
To: netdev
Cc: yoshfuji, kuznet, davem, herbert, steffen.klassert, eyal.birger,
sd, cascardo
In-Reply-To: <20180830125817.4567-1-cascardo@canonical.com>
After commit d6990976af7c5d8f55903bfb4289b6fb030bf754 ("vti6: fix PMTU caching
and reporting on xmit"), some too big skbs might be potentially passed down to
__xfrm6_output, causing it to fail to transmit but not free the skb, causing a
leak of skb, and consequentially a leak of dst references.
After running pmtu.sh, that shows as failure to unregister devices in a namespace:
[ 311.397671] unregister_netdevice: waiting for veth_b to become free. Usage count = 1
The fix is to call kfree_skb in case of transmit failures.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
Fixes: dd767856a36e ("xfrm6: Don't call icmpv6_send on local error")
---
net/ipv6/xfrm6_output.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c
index 5959ce9620eb..6a74080005cf 100644
--- a/net/ipv6/xfrm6_output.c
+++ b/net/ipv6/xfrm6_output.c
@@ -170,9 +170,11 @@ static int __xfrm6_output(struct net *net, struct sock *sk, struct sk_buff *skb)
if (toobig && xfrm6_local_dontfrag(skb)) {
xfrm6_local_rxpmtu(skb, mtu);
+ kfree_skb(skb);
return -EMSGSIZE;
} else if (!skb->ignore_df && toobig && skb->sk) {
xfrm_local_error(skb, mtu);
+ kfree_skb(skb);
return -EMSGSIZE;
}
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next v2 0/2] xsk: misc code cleanup
From: Magnus Karlsson @ 2018-08-31 11:40 UTC (permalink / raw)
To: magnus.karlsson, bjorn.topel, ast, daniel, netdev,
jeffrey.t.kirsher
This patch set cleans up two code style issues with the xsk zero-copy
code. The resulting code is smaller and simpler.
Changes from v1:
* Fixed bisecatbility problem reported by Daniel Borkmann by squashing
the two last patches into one.
Patch 1: Removes a potential compiler warning reported by the Intel
0-DAY kernel test infrastructure.
Patch 2: Removes the xdp_umem_props structure. At some point, it
was used to break a dependency, but the members are these
days much better off in the xdp_umem since the dependency
does not exist anymore. Also adapts the i40e driver to this
new interface.
I based this patch set on bpf-next commit 9c4f39811db8 ("samples/bpf:
xdpsock, minor fixes")
Thanks: Magnus
Magnus Karlsson (2):
i40e: fix possible compiler warning in xsk TX path
xsk: i40e: get rid of useless struct xdp_umem_props
drivers/net/ethernet/intel/i40e/i40e_xsk.c | 10 ++++------
include/net/xdp_sock.h | 8 ++------
net/xdp/xdp_umem.c | 4 ++--
net/xdp/xdp_umem_props.h | 14 --------------
net/xdp/xsk.c | 10 ++++++----
net/xdp/xsk_queue.c | 5 +++--
net/xdp/xsk_queue.h | 13 +++++++------
7 files changed, 24 insertions(+), 40 deletions(-)
delete mode 100644 net/xdp/xdp_umem_props.h
^ permalink raw reply
* [PATCH bpf-next v2 1/2] i40e: fix possible compiler warning in xsk TX path
From: Magnus Karlsson @ 2018-08-31 11:40 UTC (permalink / raw)
To: magnus.karlsson, bjorn.topel, ast, daniel, netdev,
jeffrey.t.kirsher
In-Reply-To: <1535715602-29056-1-git-send-email-magnus.karlsson@intel.com>
With certain gcc versions, it was possible to get the warning
"'tx_desc' may be used uninitialized in this function" for the
i40e_xmit_zc. This was not possible, however this commit simplifies
the code path so that this warning is no longer emitted.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_xsk.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_xsk.c b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
index 94947a8..41ca7e1 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_xsk.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
@@ -668,9 +668,8 @@ int i40e_clean_rx_irq_zc(struct i40e_ring *rx_ring, int budget)
**/
static bool i40e_xmit_zc(struct i40e_ring *xdp_ring, unsigned int budget)
{
- unsigned int total_packets = 0;
+ struct i40e_tx_desc *tx_desc = NULL;
struct i40e_tx_buffer *tx_bi;
- struct i40e_tx_desc *tx_desc;
bool work_done = true;
dma_addr_t dma;
u32 len;
@@ -697,14 +696,13 @@ static bool i40e_xmit_zc(struct i40e_ring *xdp_ring, unsigned int budget)
build_ctob(I40E_TX_DESC_CMD_ICRC
| I40E_TX_DESC_CMD_EOP,
0, len, 0);
- total_packets++;
xdp_ring->next_to_use++;
if (xdp_ring->next_to_use == xdp_ring->count)
xdp_ring->next_to_use = 0;
}
- if (total_packets > 0) {
+ if (tx_desc) {
/* Request an interrupt for the last frame and bump tail ptr. */
tx_desc->cmd_type_offset_bsz |= (I40E_TX_DESC_CMD_RS <<
I40E_TXD_QW1_CMD_SHIFT);
--
2.7.4
^ permalink raw reply related
* [PATCH bpf-next v2 2/2] xsk: i40e: get rid of useless struct xdp_umem_props
From: Magnus Karlsson @ 2018-08-31 11:40 UTC (permalink / raw)
To: magnus.karlsson, bjorn.topel, ast, daniel, netdev,
jeffrey.t.kirsher
In-Reply-To: <1535715602-29056-1-git-send-email-magnus.karlsson@intel.com>
This commit gets rid of the structure xdp_umem_props. It was there to
be able to break a dependency at one point, but this is no longer
needed. The values in the struct are instead stored directly in the
xdp_umem structure. This simplifies the xsk code as well as af_xdp
zero-copy drivers and as a bonus gets rid of one internal header file.
The i40e driver is also adapted to the new interface in this commit.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_xsk.c | 4 ++--
include/net/xdp_sock.h | 8 ++------
net/xdp/xdp_umem.c | 4 ++--
net/xdp/xdp_umem_props.h | 14 --------------
net/xdp/xsk.c | 10 ++++++----
net/xdp/xsk_queue.c | 5 +++--
net/xdp/xsk_queue.h | 13 +++++++------
7 files changed, 22 insertions(+), 36 deletions(-)
delete mode 100644 net/xdp/xdp_umem_props.h
diff --git a/drivers/net/ethernet/intel/i40e/i40e_xsk.c b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
index 41ca7e1..2ebfc78 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_xsk.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
@@ -442,7 +442,7 @@ static void i40e_reuse_rx_buffer_zc(struct i40e_ring *rx_ring,
struct i40e_rx_buffer *old_bi)
{
struct i40e_rx_buffer *new_bi = &rx_ring->rx_bi[rx_ring->next_to_alloc];
- unsigned long mask = (unsigned long)rx_ring->xsk_umem->props.chunk_mask;
+ unsigned long mask = (unsigned long)rx_ring->xsk_umem->chunk_mask;
u64 hr = rx_ring->xsk_umem->headroom + XDP_PACKET_HEADROOM;
u16 nta = rx_ring->next_to_alloc;
@@ -477,7 +477,7 @@ void i40e_zca_free(struct zero_copy_allocator *alloc, unsigned long handle)
rx_ring = container_of(alloc, struct i40e_ring, zca);
hr = rx_ring->xsk_umem->headroom + XDP_PACKET_HEADROOM;
- mask = rx_ring->xsk_umem->props.chunk_mask;
+ mask = rx_ring->xsk_umem->chunk_mask;
nta = rx_ring->next_to_alloc;
bi = &rx_ring->rx_bi[nta];
diff --git a/include/net/xdp_sock.h b/include/net/xdp_sock.h
index 56994ad..932ca0d 100644
--- a/include/net/xdp_sock.h
+++ b/include/net/xdp_sock.h
@@ -16,11 +16,6 @@
struct net_device;
struct xsk_queue;
-struct xdp_umem_props {
- u64 chunk_mask;
- u64 size;
-};
-
struct xdp_umem_page {
void *addr;
dma_addr_t dma;
@@ -30,7 +25,8 @@ struct xdp_umem {
struct xsk_queue *fq;
struct xsk_queue *cq;
struct xdp_umem_page *pages;
- struct xdp_umem_props props;
+ u64 chunk_mask;
+ u64 size;
u32 headroom;
u32 chunk_size_nohr;
struct user_struct *user;
diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
index d179732..b3b632c 100644
--- a/net/xdp/xdp_umem.c
+++ b/net/xdp/xdp_umem.c
@@ -312,8 +312,8 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
umem->pid = get_task_pid(current, PIDTYPE_PID);
umem->address = (unsigned long)addr;
- umem->props.chunk_mask = ~((u64)chunk_size - 1);
- umem->props.size = size;
+ umem->chunk_mask = ~((u64)chunk_size - 1);
+ umem->size = size;
umem->headroom = headroom;
umem->chunk_size_nohr = chunk_size - headroom;
umem->npgs = size / PAGE_SIZE;
diff --git a/net/xdp/xdp_umem_props.h b/net/xdp/xdp_umem_props.h
deleted file mode 100644
index 40eab10..0000000
--- a/net/xdp/xdp_umem_props.h
+++ /dev/null
@@ -1,14 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/* XDP user-space packet buffer
- * Copyright(c) 2018 Intel Corporation.
- */
-
-#ifndef XDP_UMEM_PROPS_H_
-#define XDP_UMEM_PROPS_H_
-
-struct xdp_umem_props {
- u64 chunk_mask;
- u64 size;
-};
-
-#endif /* XDP_UMEM_PROPS_H_ */
diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index 569048e..5a432df 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -470,8 +470,10 @@ static int xsk_bind(struct socket *sock, struct sockaddr *addr, int addr_len)
goto out_unlock;
} else {
/* This xsk has its own umem. */
- xskq_set_umem(xs->umem->fq, &xs->umem->props);
- xskq_set_umem(xs->umem->cq, &xs->umem->props);
+ xskq_set_umem(xs->umem->fq, xs->umem->size,
+ xs->umem->chunk_mask);
+ xskq_set_umem(xs->umem->cq, xs->umem->size,
+ xs->umem->chunk_mask);
err = xdp_umem_assign_dev(xs->umem, dev, qid, flags);
if (err)
@@ -481,8 +483,8 @@ static int xsk_bind(struct socket *sock, struct sockaddr *addr, int addr_len)
xs->dev = dev;
xs->zc = xs->umem->zc;
xs->queue_id = qid;
- xskq_set_umem(xs->rx, &xs->umem->props);
- xskq_set_umem(xs->tx, &xs->umem->props);
+ xskq_set_umem(xs->rx, xs->umem->size, xs->umem->chunk_mask);
+ xskq_set_umem(xs->tx, xs->umem->size, xs->umem->chunk_mask);
xdp_add_sk_umem(xs->umem, xs);
out_unlock:
diff --git a/net/xdp/xsk_queue.c b/net/xdp/xsk_queue.c
index 6c32e92..2dc1384d 100644
--- a/net/xdp/xsk_queue.c
+++ b/net/xdp/xsk_queue.c
@@ -7,12 +7,13 @@
#include "xsk_queue.h"
-void xskq_set_umem(struct xsk_queue *q, struct xdp_umem_props *umem_props)
+void xskq_set_umem(struct xsk_queue *q, u64 size, u64 chunk_mask)
{
if (!q)
return;
- q->umem_props = *umem_props;
+ q->size = size;
+ q->chunk_mask = chunk_mask;
}
static u32 xskq_umem_get_ring_size(struct xsk_queue *q)
diff --git a/net/xdp/xsk_queue.h b/net/xdp/xsk_queue.h
index 8a64b15..82252cc 100644
--- a/net/xdp/xsk_queue.h
+++ b/net/xdp/xsk_queue.h
@@ -31,7 +31,8 @@ struct xdp_umem_ring {
};
struct xsk_queue {
- struct xdp_umem_props umem_props;
+ u64 chunk_mask;
+ u64 size;
u32 ring_mask;
u32 nentries;
u32 prod_head;
@@ -78,7 +79,7 @@ static inline u32 xskq_nb_free(struct xsk_queue *q, u32 producer, u32 dcnt)
static inline bool xskq_is_valid_addr(struct xsk_queue *q, u64 addr)
{
- if (addr >= q->umem_props.size) {
+ if (addr >= q->size) {
q->invalid_descs++;
return false;
}
@@ -92,7 +93,7 @@ static inline u64 *xskq_validate_addr(struct xsk_queue *q, u64 *addr)
struct xdp_umem_ring *ring = (struct xdp_umem_ring *)q->ring;
unsigned int idx = q->cons_tail & q->ring_mask;
- *addr = READ_ONCE(ring->desc[idx]) & q->umem_props.chunk_mask;
+ *addr = READ_ONCE(ring->desc[idx]) & q->chunk_mask;
if (xskq_is_valid_addr(q, *addr))
return addr;
@@ -173,8 +174,8 @@ static inline bool xskq_is_valid_desc(struct xsk_queue *q, struct xdp_desc *d)
if (!xskq_is_valid_addr(q, d->addr))
return false;
- if (((d->addr + d->len) & q->umem_props.chunk_mask) !=
- (d->addr & q->umem_props.chunk_mask)) {
+ if (((d->addr + d->len) & q->chunk_mask) !=
+ (d->addr & q->chunk_mask)) {
q->invalid_descs++;
return false;
}
@@ -253,7 +254,7 @@ static inline bool xskq_empty_desc(struct xsk_queue *q)
return xskq_nb_free(q, q->prod_tail, q->nentries) == q->nentries;
}
-void xskq_set_umem(struct xsk_queue *q, struct xdp_umem_props *umem_props);
+void xskq_set_umem(struct xsk_queue *q, u64 size, u64 chunk_mask);
struct xsk_queue *xskq_create(u32 nentries, bool umem_queue);
void xskq_destroy(struct xsk_queue *q_ops);
--
2.7.4
^ 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