* [PATCH net-next 0/3] XDP support for tap
From: Jason Wang @ 2017-07-27 9:25 UTC (permalink / raw)
To: davem, mst, netdev, linux-kernel; +Cc: Jason Wang
Hi all:
This series tries to implement XDP support for tap. Two path were
implemented:
- fast path: small & non-gso packet, For performance reason we do it
at page level and use build_skb() to create skb if necessary.
- slow path: big or gso packet, we don't want to lose the capability
compared to generic XDP, so we export some generic xdp helpers and
do it after skb was created.
xdp1 shows about 47% improvement.
Please review.
Jason Wang (3):
tap: use build_skb() for small packet
net: export some generic xdp helpers
tap: XDP support
drivers/net/tun.c | 247 ++++++++++++++++++++++++++++++++++++++++++----
include/linux/netdevice.h | 2 +
net/core/dev.c | 14 +--
3 files changed, 236 insertions(+), 27 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH iproute2] utils: also check AF_INET family when rtm_type is RTN_MULTICAST
From: Phil Sutter @ 2017-07-27 9:11 UTC (permalink / raw)
To: Hangbin Liu; +Cc: netdev, Nikolay Aleksandrov, Stephen Hemminger
In-Reply-To: <1501146109-30032-1-git-send-email-liuhangbin@gmail.com>
Hi Hangbin,
On Thu, Jul 27, 2017 at 05:01:49PM +0800, Hangbin Liu wrote:
[...]
> diff --git a/lib/utils.c b/lib/utils.c
> index e77bd30..0479e00 100644
> --- a/lib/utils.c
> +++ b/lib/utils.c
> @@ -1215,5 +1215,6 @@ int get_real_family(int rtm_type, int rtm_family)
> if (rtm_type != RTN_MULTICAST)
> return rtm_family;
>
> - return rtm_family == RTNL_FAMILY_IPMR ? AF_INET : AF_INET6;
> + return (rtm_family == RTNL_FAMILY_IPMR ||
> + rtm_family == AF_INET) ? AF_INET : AF_INET6;
> }
I think this is not very readable. How about this instead:
- return rtm_family == RTNL_FAMILY_IPMR ? AF_INET : AF_INET6;
+ if (rtm_family == RTNL_FAMILY_IPMR)
+ return AF_INET;
+
+ return rtm_family;
Thanks, Phil
^ permalink raw reply
* [PATCH iproute2] utils: also check AF_INET family when rtm_type is RTN_MULTICAST
From: Hangbin Liu @ 2017-07-27 9:01 UTC (permalink / raw)
To: netdev; +Cc: Nikolay Aleksandrov, Stephen Hemminger, Hangbin Liu
When we get a multicast route, the rtm_type is RTN_MULTICAST, but the
rtm_family may be AF_INET. If we only check the type with RTNL_FAMILY_IPMR,
we will get malformed address. e.g.
+ ip -4 route add multicast 172.111.1.1 dev em1 table main
Before fix:
+ ip route list type multicast table main
multicast ac6f:101:800:400:400:0:3c00:0 dev em1 scope link
After fix:
+ ip route list type multicast table main
multicast 172.111.1.1 dev em1 scope link
Fixes: 56e3eb4c3400 ("ip: route: fix multicast route dumps")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
lib/utils.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/utils.c b/lib/utils.c
index e77bd30..0479e00 100644
--- a/lib/utils.c
+++ b/lib/utils.c
@@ -1215,5 +1215,6 @@ int get_real_family(int rtm_type, int rtm_family)
if (rtm_type != RTN_MULTICAST)
return rtm_family;
- return rtm_family == RTNL_FAMILY_IPMR ? AF_INET : AF_INET6;
+ return (rtm_family == RTNL_FAMILY_IPMR ||
+ rtm_family == AF_INET) ? AF_INET : AF_INET6;
}
--
2.5.5
^ permalink raw reply related
* Re: [PATCH net-next 2/2] bnxt_en: define sriov_lock unconditionally
From: Sathya Perla @ 2017-07-27 9:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Michael Chan, David S. Miller, Somnath Kotur, Netdev, open list
In-Reply-To: <CAK8P3a1hiEwZrPoEsCXbATM2RZPKPnhkMFjyX0t6Yee+px9afQ@mail.gmail.com>
On Thu, Jul 27, 2017 at 1:18 PM, Arnd Bergmann <arnd@arndb.de> wrote:
[...]
>
> On today's linux-next:
>
> drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.o: In function `bnxt_dl_register':
> bnxt_vfr.c:(.text+0x1440): undefined reference to `devlink_alloc'
> bnxt_vfr.c:(.text+0x14c0): undefined reference to `devlink_register'
> bnxt_vfr.c:(.text+0x14e0): undefined reference to `devlink_free'
> drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.o: In function `bnxt_dl_unregister':
> bnxt_vfr.c:(.text+0x1534): undefined reference to `devlink_unregister'
> bnxt_vfr.c:(.text+0x153c): undefined reference to `devlink_free'
>
> I think you are just missing a "depends on MAY_USE_DEVLINK"
> in INFINIBAND_BNXT_RE, which uses 'select BNXT'.
>
> This is a tricky corner case for Kconfig, where the MAY_USE_DEVLINK
> dependency is silently ignored for BNXT as long as MAY_USE_DEVLINK
> is not "=n".
Can you pls share your .config so that I can reproduce this issue and
ensure that my fix really works...
^ permalink raw reply
* Re: [patch net-next 2/2] mlxsw: spectrum: Add support for access cable info via ethtool
From: Arkadi Sharshevsky @ 2017-07-27 8:28 UTC (permalink / raw)
To: Andrew Lunn, Jiri Pirko; +Cc: netdev, davem, idosch, mlxsw
In-Reply-To: <20170726141833.GB12049@lunn.ch>
On 07/26/2017 05:18 PM, Andrew Lunn wrote:
>> +static int mlxsw_sp_get_module_info(struct net_device *netdev,
>> + struct ethtool_modinfo *modinfo)
>> +{
>> + struct mlxsw_sp_port *mlxsw_sp_port = netdev_priv(netdev);
>> + u8 module_info[MLXSW_SP_EEPROM_MODULE_INFO_SIZE];
>> + u8 module_rev_id, module_id;
>> + unsigned int read_size;
>> + int err;
>> +
>> + err = mlxsw_sp_query_module_eeprom(mlxsw_sp_port, 0,
>> + MLXSW_SP_EEPROM_MODULE_INFO_SIZE,
>> + module_info, &read_size);
>> + if (err)
>> + return err;
>> +
>> + if (read_size < MLXSW_SP_EEPROM_MODULE_INFO_SIZE)
>> + return -EIO;
>> +
>> + module_rev_id = module_info[MLXSW_SP_EEPROM_MODULE_INFO_REV_ID];
>> + module_id = module_info[MLXSW_SP_EEPROM_MODULE_INFO_ID];
>> +
>> + switch (module_id) {
>> + case MLXSW_SP_EEPROM_MODULE_INFO_ID_QSFP:
>> + modinfo->type = ETH_MODULE_SFF_8436;
>> + modinfo->eeprom_len = ETH_MODULE_SFF_8436_LEN;
>> + break;
>> + case MLXSW_SP_EEPROM_MODULE_INFO_ID_QSFP_PLUS:
>> + case MLXSW_SP_EEPROM_MODULE_INFO_ID_QSFP28:
>> + if (module_id == MLXSW_SP_EEPROM_MODULE_INFO_ID_QSFP28 ||
>> + module_rev_id >= MLXSW_SP_EEPROM_MODULE_INFO_REV_ID_8636) {
>> + modinfo->type = ETH_MODULE_SFF_8636;
>> + modinfo->eeprom_len = ETH_MODULE_SFF_8636_LEN;
>> + } else {
>> + modinfo->type = ETH_MODULE_SFF_8436;
>> + modinfo->eeprom_len = ETH_MODULE_SFF_8436_LEN;
>> + }
>> + break;
>> + case MLXSW_SP_EEPROM_MODULE_INFO_ID_SFP:
>> + modinfo->type = ETH_MODULE_SFF_8472;
>> + modinfo->eeprom_len = ETH_MODULE_SFF_8472_LEN;
>> + break;
>> + default:
>> + return -EINVAL;
>
> Hi Jiri
>
> I remember seeing a few different implementations of this function in
> various drivers. Could you pull it out into a helper, passing in the
> array of bytes and mod info? bnxt, mlx4, mlx5, igb, ixgbe and sfc
> could then use the helper.
>
> Andrew
>
Yeah, it seems generic for all modules, it can be moved into ethtool
I think.
Thanks,
Arkadi
^ permalink raw reply
* Re: [PATCH net] xen-netback: correctly schedule rate-limited queues
From: Jean-Louis Dupond @ 2017-07-27 8:21 UTC (permalink / raw)
To: David Miller; +Cc: wei.liu2, netdev, xen-devel, Paul.Durrant
In-Reply-To: <20170622.111648.301858879592718577.davem@davemloft.net>
Op 2017-06-22 17:16, schreef David Miller:
> From: Wei Liu <wei.liu2@citrix.com>
> Date: Wed, 21 Jun 2017 10:21:22 +0100
>
>> Add a flag to indicate if a queue is rate-limited. Test the flag in
>> NAPI poll handler and avoid rescheduling the queue if true, otherwise
>> we risk locking up the host. The rescheduling will be done in the
>> timer callback function.
>>
>> Reported-by: Jean-Louis Dupond <jean-louis@dupond.be>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> Tested-by: Jean-Louis Dupond <jean-louis@dupond.be>
>
> Applied.
Could this get applied to stable & LTS kernels also?
Seems important enough in my opinion.
Thanks!
^ permalink raw reply
* RE: [PATCH net-next 2/3] nfp: look for firmware image by device serial number and PCI name
From: David Laight @ 2017-07-27 8:20 UTC (permalink / raw)
To: 'Jakub Kicinski', netdev@vger.kernel.org
Cc: oss-drivers@netronome.com
In-Reply-To: <20170726180948.3220-3-jakub.kicinski@netronome.com>
From: Jakub Kicinski
> Sent: 26 July 2017 19:10
> We generally look up firmware by card type, but that doesn't allow
> users who have more than one card of the same type in their system
> to select firmware per adapter.
>
> Unfortunately user space firmware helper seems fraught with
> difficulties and to be on its way out. In particular support for
> handling firmware uevents have been dropped from systemd and most
> distributions don't enable the FW fallback by default any more.
>
> To allow users selecting firmware for a particular device look up
> firmware names by serial and pci_name(). Use the direct lookup to
> disable generating uevents when enabled in Kconfig and not print
> any warnings to logs if adapter-specific files are missing. Users
> can place in /lib/firmware/netronome files named:
>
> pci-${pci_name}.nffw
> serial-${serial}.nffw
>
> to target a specific card. E.g.:
>
> pci-0000:04:00.0.nffw
> pci-0000:82:00.0.nffw
> serial-00-aa-bb-11-22-33-10-ff.nffw
>
> We use the full serial number including the interface id, as it
> appears in lspci output (bytes separated by '-').
Where does lspci get that from?
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
> drivers/net/ethernet/netronome/nfp/nfp_main.c | 20 +++++++++++++++++++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/netronome/nfp/nfp_main.c
> b/drivers/net/ethernet/netronome/nfp/nfp_main.c
> index d67969d3e484..13d056da0765 100644
> --- a/drivers/net/ethernet/netronome/nfp/nfp_main.c
> +++ b/drivers/net/ethernet/netronome/nfp/nfp_main.c
> @@ -188,9 +188,27 @@ nfp_net_fw_find(struct pci_dev *pdev, struct nfp_pf *pf)
> struct nfp_eth_table_port *port;
> const char *fw_model;
> char fw_name[256];
> + const u8 *serial;
> int spc, err = 0;
> + u16 interface;
> int i, j;
>
> + /* First try to find a firmware image specific for this device */
> + interface = nfp_cpp_interface(pf->cpp);
> + nfp_cpp_serial(pf->cpp, &serial);
> + sprintf(fw_name, "netronome/serial-%pMF-%02hhx-%02hhx.nffw",
> + serial, interface >> 8, interface & 0xff);
WTF???
- use snprintf().
- kill those hh, the arguments are of type 'int'.
In fact make 'interface' 'unsigned int' as well.
David
^ permalink raw reply
* Re: [oss-drivers] [PATCH net-next 0/3] nfp: extend firmware request logic
From: Simon Horman @ 2017-07-27 8:09 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, oss-drivers
In-Reply-To: <20170726180948.3220-1-jakub.kicinski@netronome.com>
On Wed, Jul 26, 2017 at 11:09:45AM -0700, Jakub Kicinski wrote:
> Hi!
>
> We have been pondering for some time how to support loading different
> application firmwares onto NFP. We want to support both users selecting
> one of the firmware images provided by Netronome (which are optimized
> for different use cases each) as well as firmware images created by
> users themselves or other companies.
>
> In the end we decided to go with the simplest solution - depending on
> the right firmware image being placed in /lib/firmware. This vastly
> simplifies driver logic and also doesn't require any new API.
>
> Different NICs on one system may want to run different applications
> therefore we first try to load firmware specific to the device (by
> serial number of PCI slot) and if not present try the device model
> based name we have been using so far.
>
>
> Jakub Kicinski (3):
> nfp: remove the probe deferral when FW not present
> nfp: look for firmware image by device serial number and PCI name
> nfp: only use direct firmware requests
Thanks Jakub, this looks good to me.
All patches:
Reviewed-by: Simon Horman <simon.horman@netronome.com>
^ permalink raw reply
* Re: [PATCH net-next 2/2] bnxt_en: define sriov_lock unconditionally
From: Arnd Bergmann @ 2017-07-27 7:48 UTC (permalink / raw)
To: Sathya Perla
Cc: Michael Chan, David S. Miller, Somnath Kotur, Netdev, open list
In-Reply-To: <CAK8P3a2crDS+D4C0cOBbr+RpcgH=YqotPovfNZVsXR0HbW382g@mail.gmail.com>
On Wed, Jul 26, 2017 at 3:18 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Jul 26, 2017 at 12:54 PM, Sathya Perla
> <sathya.perla@broadcom.com> wrote:
>> On Wed, Jul 26, 2017 at 2:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> [...]
>>>> Sathya already sent 3 patches to fix some of these issues. But I need
>>>> to rework one of his patch and resend.
>>>
>>> Ok, thanks. I just ran into one more issue, and don't know if that's included
>>> as well. If not, please also add the patch below (or fold it into the one
>>> that adds the switchdev dependency to the ethernet driver):
>>>
>>> 8<----------
>>> Subject: [PATCH] RDMA/bnxt_re: add NET_SWITCHDEV dependency
>>>
>>> The rdma side of BNXT enables the ethernet driver and has a list
>>> of its dependencies. However, the ethernet driver now also depends
>>> on NET_SWITCHDEV, so we have to add that dependency for both:
>>
>> Arnd, after the patch "bnxt_en: use SWITCHDEV_SET_OPS() for setting
>> vf_rep_switchdev_ops" the bnxt_en driver doesn't need an explicit
>> NET_SWITCHDEV dependency. So, the bnxt_re driver shouldn't need one
>> either. Are you still seeing the bnxt_re issue even after pulling the
>> above patch??
>
> I think that's fine then. I missed that patch when it went in, so I only
> needed the add-on since I still had my own earlier patch. I'll drop both
> from my test tree now, and will let you know in case something else
> remains.
On today's linux-next:
drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.o: In function `bnxt_dl_register':
bnxt_vfr.c:(.text+0x1440): undefined reference to `devlink_alloc'
bnxt_vfr.c:(.text+0x14c0): undefined reference to `devlink_register'
bnxt_vfr.c:(.text+0x14e0): undefined reference to `devlink_free'
drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.o: In function `bnxt_dl_unregister':
bnxt_vfr.c:(.text+0x1534): undefined reference to `devlink_unregister'
bnxt_vfr.c:(.text+0x153c): undefined reference to `devlink_free'
I think you are just missing a "depends on MAY_USE_DEVLINK"
in INFINIBAND_BNXT_RE, which uses 'select BNXT'.
This is a tricky corner case for Kconfig, where the MAY_USE_DEVLINK
dependency is silently ignored for BNXT as long as MAY_USE_DEVLINK
is not "=n".
Arnd
^ permalink raw reply
* [PATCH] net: thunderx: Fix BGX transmit stall due to underflow
From: sunil.kovvuri @ 2017-07-27 7:23 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, linux-arm-kernel, Sunil Goutham
From: Sunil Goutham <sgoutham@cavium.com>
For SGMII/RGMII/QSGMII interfaces when physical link goes down
while traffic is high is resulting in underflow condition being set
on that specific BGX's LMAC. Which assets a backpresure and VNIC stops
transmitting packets.
This is due to BGX being disabled in link status change callback while
packet is in transit. This patch fixes this issue by not disabling BGX
but instead just disables packet Rx and Tx.
Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 27 ++++++++++++++++++-----
drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 2 ++
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 7911256..5e5c4d7 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -292,11 +292,30 @@ static void bgx_sgmii_change_link_state(struct lmac *lmac)
u64 cmr_cfg;
u64 port_cfg = 0;
u64 misc_ctl = 0;
+ bool tx_en, rx_en;
cmr_cfg = bgx_reg_read(bgx, lmac->lmacid, BGX_CMRX_CFG);
- cmr_cfg &= ~CMR_EN;
+ tx_en = cmr_cfg & CMR_PKT_TX_EN;
+ rx_en = cmr_cfg & CMR_PKT_RX_EN;
+ cmr_cfg &= ~(CMR_PKT_RX_EN | CMR_PKT_TX_EN);
bgx_reg_write(bgx, lmac->lmacid, BGX_CMRX_CFG, cmr_cfg);
+ /* Wait for BGX RX to be idle */
+ if (bgx_poll_reg(bgx, lmac->lmacid, BGX_GMP_GMI_PRTX_CFG,
+ GMI_PORT_CFG_RX_IDLE, false)) {
+ dev_err(&bgx->pdev->dev, "BGX%d LMAC%d GMI RX not idle\n",
+ bgx->bgx_id, lmac->lmacid);
+ return;
+ }
+
+ /* Wait for BGX TX to be idle */
+ if (bgx_poll_reg(bgx, lmac->lmacid, BGX_GMP_GMI_PRTX_CFG,
+ GMI_PORT_CFG_TX_IDLE, false)) {
+ dev_err(&bgx->pdev->dev, "BGX%d LMAC%d GMI TX not idle\n",
+ bgx->bgx_id, lmac->lmacid);
+ return;
+ }
+
port_cfg = bgx_reg_read(bgx, lmac->lmacid, BGX_GMP_GMI_PRTX_CFG);
misc_ctl = bgx_reg_read(bgx, lmac->lmacid, BGX_GMP_PCS_MISCX_CTL);
@@ -347,10 +366,8 @@ static void bgx_sgmii_change_link_state(struct lmac *lmac)
bgx_reg_write(bgx, lmac->lmacid, BGX_GMP_PCS_MISCX_CTL, misc_ctl);
bgx_reg_write(bgx, lmac->lmacid, BGX_GMP_GMI_PRTX_CFG, port_cfg);
- port_cfg = bgx_reg_read(bgx, lmac->lmacid, BGX_GMP_GMI_PRTX_CFG);
-
- /* Re-enable lmac */
- cmr_cfg |= CMR_EN;
+ /* Restore CMR config settings */
+ cmr_cfg |= (rx_en ? CMR_PKT_RX_EN : 0) | (tx_en ? CMR_PKT_TX_EN : 0);
bgx_reg_write(bgx, lmac->lmacid, BGX_CMRX_CFG, cmr_cfg);
if (bgx->is_rgx && (cmr_cfg & (CMR_PKT_RX_EN | CMR_PKT_TX_EN)))
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
index 6b7fe6fd..23acdc5 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
@@ -170,6 +170,8 @@
#define GMI_PORT_CFG_DUPLEX BIT_ULL(2)
#define GMI_PORT_CFG_SLOT_TIME BIT_ULL(3)
#define GMI_PORT_CFG_SPEED_MSB BIT_ULL(8)
+#define GMI_PORT_CFG_RX_IDLE BIT_ULL(12)
+#define GMI_PORT_CFG_TX_IDLE BIT_ULL(13)
#define BGX_GMP_GMI_RXX_JABBER 0x38038
#define BGX_GMP_GMI_TXX_THRESH 0x38210
#define BGX_GMP_GMI_TXX_APPEND 0x38218
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net] udp6: fix socket leak on early demux
From: Eric Dumazet @ 2017-07-27 7:06 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev, David S. Miller, Eric Dumazet, Sam Edwards, Marc Haber,
Subash Abhinov Kasiviswanathan
In-Reply-To: <fa8561e5d814bfcd8aeb20f09732a716ffca772c.1501082940.git.pabeni@redhat.com>
On Wed, 2017-07-26 at 17:29 +0200, Paolo Abeni wrote:
> When an early demuxed packet reaches __udp6_lib_lookup_skb(), the
> sk reference is retrieved and used, but the relevant reference
> count is leaked and the socket destructor is never called.
> Beyond leaking the sk memory, if there are pending UDP packets
> in the receive queue, even the related accounted memory is leaked.
>
> In the long run, this will cause persistent forward allocation errors
> and no UDP skbs (both ipv4 and ipv6) will be able to reach the
> user-space.
>
> Fix this by explicitly accessing the early demux reference before
> the lookup, and properly decreasing the socket reference count
> after usage.
>
> Also drop the skb_steal_sock() in __udp6_lib_lookup_skb(), and
> the now obsoleted comment about "socket cache".
>
> The newly added code is derived from the current ipv4 code for the
> similar path.
Nice catch Paolo.
I believe there is one point to discuss, see below.
>
> Reported-by: Sam Edwards <CFSworks@gmail.com>
> Reported-by: Marc Haber <mh+netdev@zugschlus.de>
> Fixes: 5425077d73e0 ("net: ipv6: Add early demux handler for UDP unicast")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> include/net/udp.h | 1 +
> net/ipv4/udp.c | 3 ++-
> net/ipv6/udp.c | 28 +++++++++++++++++++---------
> 3 files changed, 22 insertions(+), 10 deletions(-)
>
> diff --git a/include/net/udp.h b/include/net/udp.h
> index 56ce2d2a612d..cc8036987dcb 100644
> --- a/include/net/udp.h
> +++ b/include/net/udp.h
> @@ -260,6 +260,7 @@ static inline struct sk_buff *skb_recv_udp(struct sock *sk, unsigned int flags,
> }
>
> void udp_v4_early_demux(struct sk_buff *skb);
> +void udp_sk_rx_dst_set(struct sock *sk, struct dst_entry *dst);
> int udp_get_port(struct sock *sk, unsigned short snum,
> int (*saddr_cmp)(const struct sock *,
> const struct sock *));
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index fac7cb9e3b0f..e6276fa3750b 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1928,7 +1928,7 @@ static int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
> /* For TCP sockets, sk_rx_dst is protected by socket lock
> * For UDP, we use xchg() to guard against concurrent changes.
> */
> -static void udp_sk_rx_dst_set(struct sock *sk, struct dst_entry *dst)
> +void udp_sk_rx_dst_set(struct sock *sk, struct dst_entry *dst)
> {
> struct dst_entry *old;
>
> @@ -1937,6 +1937,7 @@ static void udp_sk_rx_dst_set(struct sock *sk, struct dst_entry *dst)
> dst_release(old);
> }
> }
> +EXPORT_SYMBOL(udp_sk_rx_dst_set);
>
> /*
> * Multicasts and broadcasts go to each listener.
> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
> index 4a3e65626e8b..e74fe497d823 100644
> --- a/net/ipv6/udp.c
> +++ b/net/ipv6/udp.c
> @@ -291,11 +291,7 @@ static struct sock *__udp6_lib_lookup_skb(struct sk_buff *skb,
> struct udp_table *udptable)
> {
> const struct ipv6hdr *iph = ipv6_hdr(skb);
> - struct sock *sk;
>
> - sk = skb_steal_sock(skb);
> - if (unlikely(sk))
> - return sk;
> return __udp6_lib_lookup(dev_net(skb->dev), &iph->saddr, sport,
> &iph->daddr, dport, inet6_iif(skb),
> udptable, skb);
> @@ -804,6 +800,25 @@ int __udp6_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
> if (udp6_csum_init(skb, uh, proto))
> goto csum_error;
>
> + /* Check if the socket is already available, e.g. due to early demux */
> + sk = skb_steal_sock(skb);
> + if (sk) {
> + struct dst_entry *dst = skb_dst(skb);
> + int ret;
> +
> + if (unlikely(sk->sk_rx_dst != dst))
> + udp_sk_rx_dst_set(sk, dst);
> +
> + ret = udpv6_queue_rcv_skb(sk, skb);
> + sock_put(sk);
> + /* a return value > 0 means to resubmit the input, but
> + * it wants the return to be -protocol, or 0
> + */
> + if (ret > 0)
> + return -ret;
IPv6 and IPv4 have different behavior for resubmit
I believe "return ret;" would be more appropriate here.
> + return 0;
> + }
> +
> /*
> * Multicast receive code
> */
> @@ -812,11 +827,6 @@ int __udp6_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
> saddr, daddr, udptable, proto);
>
> /* Unicast */
> -
> - /*
> - * check socket cache ... must talk to Alan about his plans
> - * for sock caches... i'll skip this for now.
> - */
> sk = __udp6_lib_lookup_skb(skb, uh->source, uh->dest, udptable);
> if (sk) {
> int ret;
^ permalink raw reply
* Re: [PATCH net-next v2 01/10] net: dsa: lan9303: Fixed MDIO interface
From: kbuild test robot @ 2017-07-27 7:07 UTC (permalink / raw)
To: Egil Hjelmeland
Cc: kbuild-all, corbet, andrew, vivien.didelot, f.fainelli, davem,
kernel, linux-doc, linux-kernel, netdev, Egil Hjelmeland
In-Reply-To: <20170725161553.30147-2-privat@egil-hjelmeland.no>
[-- Attachment #1: Type: text/plain, Size: 652 bytes --]
Hi Egil,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Egil-Hjelmeland/net-dsa-lan9303-unicast-offload-fdb-mdb-STP/20170727-074246
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> ERROR: "lan9303_indirect_phy_ops" [drivers/net/dsa/lan9303_i2c.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 60986 bytes --]
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] qed/qede: Enhancements
From: David Miller @ 2017-07-27 7:05 UTC (permalink / raw)
To: manish.chopra; +Cc: netdev, Yuval.Mintz, rahul.verma, sudarsana.kalluru
In-Reply-To: <20170726130715.12976-1-manish.chopra@cavium.com>
From: Manish Chopra <manish.chopra@cavium.com>
Date: Wed, 26 Jul 2017 06:07:08 -0700
> This patch series adds these below features support in qed/qede
>
> 1) Ntuple filter configuration [via ethtool -n/N]
> 2) EEE (energy efficient ethernet) support [ethtool --set-eee/show-eee]
> 3) Coalescing configuration support for VFs [via ethtool -c/C]
>
> Please consider applying this to "net-next"
>
> V1->V2:
> * Fixes below Kbuild test robot warning.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] sctp: fix the check for _sctp_walk_params and _sctp_walk_errors
From: David Miller @ 2017-07-27 7:03 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman, glider
In-Reply-To: <81a6fb647ad305525c840eae623c41b7ba52c975.1501057499.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Wed, 26 Jul 2017 16:24:59 +0800
> Commit b1f5bfc27a19 ("sctp: don't dereference ptr before leaving
> _sctp_walk_{params, errors}()") tried to fix the issue that it
> may overstep the chunk end for _sctp_walk_{params, errors} with
> 'chunk_end > offset(length) + sizeof(length)'.
>
> But it introduced a side effect: When processing INIT, it verifies
> the chunks with 'param.v == chunk_end' after iterating all params
> by sctp_walk_params(). With the check 'chunk_end > offset(length)
> + sizeof(length)', it would return when the last param is not yet
> accessed. Because the last param usually is fwdtsn supported param
> whose size is 4 and 'chunk_end == offset(length) + sizeof(length)'
>
> This is a badly issue even causing sctp couldn't process 4-shakes.
> Client would always get abort when connecting to server, due to
> the failure of INIT chunk verification on server.
>
> The patch is to use 'chunk_end <= offset(length) + sizeof(length)'
> instead of 'chunk_end < offset(length) + sizeof(length)' for both
> _sctp_walk_params and _sctp_walk_errors.
>
> Fixes: b1f5bfc27a19 ("sctp: don't dereference ptr before leaving _sctp_walk_{params, errors}()")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] dccp: fix a memleak for dccp_feat_init err process
From: David Miller @ 2017-07-27 7:01 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev
In-Reply-To: <62b8165447ec57830c1199af42a3490d896fbc26.1501050015.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Wed, 26 Jul 2017 14:20:15 +0800
> In dccp_feat_init, when ccid_get_builtin_ccids failsto alloc
> memory for rx.val, it should free tx.val before returning an
> error.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Also applied and queued up for -stable.
Thanks.
^ permalink raw reply
* Re: [PATCH net] dccp: fix a memleak that dccp_ipv4 doesn't put reqsk properly
From: David Miller @ 2017-07-27 7:01 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev
In-Reply-To: <795235abacd1bbf9f1144f3094b1f604d513cf65.1501049986.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Wed, 26 Jul 2017 14:19:46 +0800
> The patch "dccp: fix a memleak that dccp_ipv6 doesn't put reqsk
> properly" fixed reqsk refcnt leak for dccp_ipv6. The same issue
> exists on dccp_ipv4.
>
> This patch is to fix it for dccp_ipv4.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] dccp: fix a memleak that dccp_ipv6 doesn't put reqsk properly
From: David Miller @ 2017-07-27 7:01 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev
In-Reply-To: <17b2008535695e5885775418a31ee74f3ca704f5.1501049949.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Wed, 26 Jul 2017 14:19:09 +0800
> In dccp_v6_conn_request, after reqsk gets alloced and hashed into
> ehash table, reqsk's refcnt is set 3. one is for req->rsk_timer,
> one is for hlist, and the other one is for current using.
>
> The problem is when dccp_v6_conn_request returns and finishes using
> reqsk, it doesn't put reqsk. This will cause reqsk refcnt leaks and
> reqsk obj never gets freed.
>
> Jianlin found this issue when running dccp_memleak.c in a loop, the
> system memory would run out.
>
> dccp_memleak.c:
> int s1 = socket(PF_INET6, 6, IPPROTO_IP);
> bind(s1, &sa1, 0x20);
> listen(s1, 0x9);
> int s2 = socket(PF_INET6, 6, IPPROTO_IP);
> connect(s2, &sa1, 0x20);
> close(s1);
> close(s2);
>
> This patch is to put the reqsk before dccp_v6_conn_request returns,
> just as what tcp_conn_request does.
>
> Reported-by: Jianlin Shi <jishi@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next v2 00/10] netvsc fixes and new features
From: David Miller @ 2017-07-27 6:59 UTC (permalink / raw)
To: stephen; +Cc: kys, haiyangz, sthemmin, corbet, devel, linux-doc, netdev
In-Reply-To: <20170726234029.7342-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Wed, 26 Jul 2017 16:40:19 -0700
> The next group of patches aims to reduce the driver memory footprint
> by reducing the size of the per-device receive and send buffers, and
> the per-channel receive completion queue.
Sorry Stephen, I have to draw the line with those module parameters.
Search out alternate mechanism which can work at run time, such as
using devlink or similar.
Don't tell me it's "impossible" or "hard", simply do.
Thanks.
^ permalink raw reply
* Re: nf_nat_pptp 4.12.3 kernel lockup/reboot
From: Denys Fedoryshchenko @ 2017-07-27 6:29 UTC (permalink / raw)
To: Florian Westphal; +Cc: Linux Kernel Network Developers
In-Reply-To: <20170724162039.GC23964@breakpoint.cc>
On 2017-07-24 19:20, Florian Westphal wrote:
> Florian Westphal <fw@strlen.de> wrote:
>> Denys Fedoryshchenko <nuclearcat@nuclearcat.com> wrote:
>> > Hi,
>> >
>> > I am trying to upgrade kernel 4.11.8 to 4.12.3 (it is a nat/router, handling
>> > approx 2gbps of pppoe users traffic) and noticed that after while server
>> > rebooting(i have set reboot on panic and etc).
>> > I can't run serial console, and in pstore / netconsole there is nothing.
>> > Best i got is some very short message about softlockup in ipmi, but as
>> > storage very limited there - it is near useless.
>> >
>> > By preliminary testing (can't do it much, as it's production) - it seems
>> > following lines causing issue, they worked in 4.11.8 and no more in 4.12.3.
>>
>> Wild guess here, does this help?
>>
>> diff --git a/net/netfilter/nf_conntrack_helper.c
>> b/net/netfilter/nf_conntrack_helper.c
>> --- a/net/netfilter/nf_conntrack_helper.c
>> +++ b/net/netfilter/nf_conntrack_helper.c
>> @@ -266,6 +266,8 @@ int __nf_ct_try_assign_helper(struct nf_conn *ct,
>> struct nf_conn *tmpl,
>> help = nf_ct_helper_ext_add(ct, helper, flags);
>> if (help == NULL)
>> return -ENOMEM;
>> + if (!nf_ct_ext_add(ct, NF_CT_EXT_NAT, flags));
>
> sigh, stupid typo, should be no ';' at the end above.
Tested-by: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
Tested and no more hangs for 2 days, definitely improvement.
Any chance it will go to stable 4.12.x and new kernel?
Thank you very much!
^ permalink raw reply
* Re: TC-pedit man page examples error
From: Phil Sutter @ 2017-07-27 6:08 UTC (permalink / raw)
To: Tyler Bautista; +Cc: netdev
In-Reply-To: <CAEPezq4Emc=D7zspWqLOq=80WGUjVdfT0xkqoJ1XQPXqaL3w6w@mail.gmail.com>
Hi Tyler,
On Wed, Jul 26, 2017 at 09:47:51AM -0700, Tyler Bautista wrote:
> Thank you for taking my message. I have gotten a solution working so
> feel free to ignore the rest of this email. By vanilla iproute2 do you
> mean the latest package through the yum or apt repository? All I can
> tell you is that in the example I gave the iproute2 package was the
> latest one through the RHEL 7 yum repository.
'Vanilla' is a widely used term[1], I meant using latest iproute2 from
upstream[2], ideally from Git. You have to report problems with RHEL
packages in Red Hat bugzilla[3].
Cheers, Phil
[1] https://en.wikipedia.org/wiki/Vanilla_software
[2] https://wiki.linuxfoundation.org/networking/iproute2
[3] https://bugzilla.redhat.com/
^ permalink raw reply
* qmi_wwan: Null pointer dereference when removing driver
From: Nathaniel Roach @ 2017-07-27 5:31 UTC (permalink / raw)
To: netdev
Unsure at which point was added, but issue not present in stock debian 4.11 kernel.
Running on a Thinkpad X220 with coreboot.
I'm building from upstream. When I attempt to remove the qmi_wwan module (which also happens pre-suspend) the rmmod process gets killed, and the following shows in dmesg:
[ 59.979791] usb 2-1.4: USB disconnect, device number 4
[ 59.980102] qmi_wwan 2-1.4:1.6 wwp0s29u1u4i6: unregister 'qmi_wwan' usb-0000:00:1d.0-1.4, WWAN/QMI device
[ 60.006821] BUG: unable to handle kernel NULL pointer dereference at 00000000000000e0
[ 60.006879] IP: qmi_wwan_disconnect+0x25/0xc0 [qmi_wwan]
[ 60.006911] PGD 0
[ 60.006911] P4D 0
[ 60.006957] Oops: 0000 [#1] SMP
[ 60.006978] Modules linked in: fuse(E) ccm(E) rfcomm(E) cmac(E) bnep(E) qmi_wwan(E) cdc_wdm(E) cdc_ether(E) usbnet(E) mii(E) btusb(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) joydev(E) xpad(E) ecdh_generic(E) ff_memless(E) binfmt_misc(E) snd_hda_codec_hdmi(E) snd_hda_codec_conexant(E) snd_hda_codec_generic(E) arc4(E) iTCO_wdt(E) iTCO_vendor_support(E) intel_rapl(E) x86_pkg_temp_thermal(E) kvm_intel(E) kvm(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) ghash_clmulni_intel(E) aesni_intel(E) iwlmvm(E) aes_x86_64(E) crypto_simd(E) mac80211(E) cryptd(E) glue_helper(E) snd_hda_intel(E) snd_hda_codec(E) iwlwifi(E) snd_hwdep(E) psmouse(E) snd_hda_core(E) snd_pcm(E) serio_raw(E) sdhci_pci(E) pcspkr(E) snd_timer(E) ehci_pci(E) e1000e(E) i2c_i801(E) ehci_hcd(E) snd(E) sg(E) i
915(E) lpc_ich(E)
[ 60.007366] ptp(E) usbcore(E) cfg80211(E) mfd_core(E) pps_core(E) shpchp(E) ac(E) battery(E) tpm_tis(E) tpm_tis_core(E) evdev(E) tpm(E) parport_pc(E) ppdev(E) lp(E) parport(E) ip_tables(E) x_tables(E) autofs4(E)
[ 60.007474] CPU: 2 PID: 33 Comm: kworker/2:1 Tainted: G E 4.12.3-nr44-normandy-r1500619820+ #1
[ 60.007524] Hardware name: LENOVO 4291LR7/4291LR7, BIOS CBET4000 4.6-810-g50522254fb 07/21/2017
[ 60.007580] Workqueue: usb_hub_wq hub_event [usbcore]
[ 60.007609] task: ffff8c882b716040 task.stack: ffffb8e800d84000
[ 60.007644] RIP: 0010:qmi_wwan_disconnect+0x25/0xc0 [qmi_wwan]
[ 60.007678] RSP: 0018:ffffb8e800d87b38 EFLAGS: 00010246
[ 60.007711] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 60.007752] RDX: 0000000000000001 RSI: ffff8c8824f3f1d0 RDI: ffff8c8824ef6400
[ 60.007792] RBP: ffff8c8824ef6400 R08: 0000000000000000 R09: 0000000000000000
[ 60.007833] R10: ffffb8e800d87780 R11: 0000000000000011 R12: ffffffffc07ea0e8
[ 60.007874] R13: ffff8c8824e2e000 R14: ffff8c8824e2e098 R15: 0000000000000000
[ 60.007915] FS: 0000000000000000(0000) GS:ffff8c8835300000(0000) knlGS:0000000000000000
[ 60.007960] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 60.007994] CR2: 00000000000000e0 CR3: 0000000229ca5000 CR4: 00000000000406e0
[ 60.008035] Call Trace:
[ 60.008065] ? usb_unbind_interface+0x71/0x270 [usbcore]
[ 60.008101] ? device_release_driver_internal+0x154/0x210
[ 60.008135] ? qmi_wwan_unbind+0x6d/0xc0 [qmi_wwan]
[ 60.008168] ? usbnet_disconnect+0x6c/0xf0 [usbnet]
[ 60.008194] ? qmi_wwan_disconnect+0x87/0xc0 [qmi_wwan]
[ 60.008232] ? usb_unbind_interface+0x71/0x270 [usbcore]
[ 60.008264] ? device_release_driver_internal+0x154/0x210
[ 60.008296] ? bus_remove_device+0xf5/0x160
[ 60.008324] ? device_del+0x1dc/0x310
[ 60.008355] ? usb_remove_ep_devs+0x1b/0x30 [usbcore]
[ 60.008393] ? usb_disable_device+0x93/0x250 [usbcore]
[ 60.008430] ? usb_disconnect+0x90/0x260 [usbcore]
[ 60.008468] ? hub_event+0x1d9/0x14a0 [usbcore]
[ 60.008500] ? process_one_work+0x175/0x370
[ 60.008528] ? worker_thread+0x4a/0x380
[ 60.008555] ? kthread+0xfc/0x130
[ 60.008579] ? process_one_work+0x370/0x370
[ 60.008606] ? kthread_park+0x60/0x60
[ 60.008631] ? ret_from_fork+0x22/0x30
[ 60.008656] Code: 66 0f 1f 44 00 00 66 66 66 66 90 55 48 89 fd 53 48 83 ec 10 48 8b 9f c8 00 00 00 65 48 8b 04 25 28 00 00 00 48 89 44 24 08 31 c0 <f6> 83 e0 00 00 00 02 74 51 e8 0d b3 2b cd 85 c0 74 67 48 8b bb
[ 60.011925] RIP: qmi_wwan_disconnect+0x25/0xc0 [qmi_wwan] RSP: ffffb8e800d87b38
[ 60.013564] CR2: 00000000000000e0
[ 60.022125] ---[ end trace e536b59f45bc0f25 ]---
[ 60.025385] IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready
If I attempt a second rmmod, the process hangs. If I attempt it on 4.11.x it works as expected:
[ 16.897783] fuse init (API version 7.26)
[ 68.073552] usbcore: deregistering interface driver qmi_wwan
[ 68.075808] qmi_wwan 2-1.4:1.6 wwp0s29u1u4i6: unregister 'qmi_wwan' usb-0000:00:1d.0-1.4, WWAN/QMI device
[ 72.431403] e1000e: enp0s25 NIC Link is Down
So I'm pretty certain it's not coreboot causing the issue.
^ permalink raw reply
* [PATCH V2 net] Revert "vhost: cache used event for better performance"
From: Jason Wang @ 2017-07-27 3:22 UTC (permalink / raw)
To: mst, jasowang; +Cc: netdev, linux-kernel, kvm, virtualization
This reverts commit 809ecb9bca6a9424ccd392d67e368160f8b76c92. Since it
was reported to break vhost_net. We want to cache used event and use
it to check for notification. The assumption was that guest won't move
the event idx back, but this could happen in fact when 16 bit index
wraps around after 64K entries.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
- Changes from V1: tweak commit log
- The patch is needed for -stable.
---
drivers/vhost/vhost.c | 28 ++++++----------------------
drivers/vhost/vhost.h | 3 ---
2 files changed, 6 insertions(+), 25 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index e4613a3..9cb3f72 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -308,7 +308,6 @@ static void vhost_vq_reset(struct vhost_dev *dev,
vq->avail = NULL;
vq->used = NULL;
vq->last_avail_idx = 0;
- vq->last_used_event = 0;
vq->avail_idx = 0;
vq->last_used_idx = 0;
vq->signalled_used = 0;
@@ -1402,7 +1401,7 @@ long vhost_vring_ioctl(struct vhost_dev *d, int ioctl, void __user *argp)
r = -EINVAL;
break;
}
- vq->last_avail_idx = vq->last_used_event = s.num;
+ vq->last_avail_idx = s.num;
/* Forget the cached index value. */
vq->avail_idx = vq->last_avail_idx;
break;
@@ -2241,6 +2240,10 @@ static bool vhost_notify(struct vhost_dev *dev, struct vhost_virtqueue *vq)
__u16 old, new;
__virtio16 event;
bool v;
+ /* Flush out used index updates. This is paired
+ * with the barrier that the Guest executes when enabling
+ * interrupts. */
+ smp_mb();
if (vhost_has_feature(vq, VIRTIO_F_NOTIFY_ON_EMPTY) &&
unlikely(vq->avail_idx == vq->last_avail_idx))
@@ -2248,10 +2251,6 @@ static bool vhost_notify(struct vhost_dev *dev, struct vhost_virtqueue *vq)
if (!vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX)) {
__virtio16 flags;
- /* Flush out used index updates. This is paired
- * with the barrier that the Guest executes when enabling
- * interrupts. */
- smp_mb();
if (vhost_get_avail(vq, flags, &vq->avail->flags)) {
vq_err(vq, "Failed to get flags");
return true;
@@ -2266,26 +2265,11 @@ static bool vhost_notify(struct vhost_dev *dev, struct vhost_virtqueue *vq)
if (unlikely(!v))
return true;
- /* We're sure if the following conditions are met, there's no
- * need to notify guest:
- * 1) cached used event is ahead of new
- * 2) old to new updating does not cross cached used event. */
- if (vring_need_event(vq->last_used_event, new + vq->num, new) &&
- !vring_need_event(vq->last_used_event, new, old))
- return false;
-
- /* Flush out used index updates. This is paired
- * with the barrier that the Guest executes when enabling
- * interrupts. */
- smp_mb();
-
if (vhost_get_avail(vq, event, vhost_used_event(vq))) {
vq_err(vq, "Failed to get used event idx");
return true;
}
- vq->last_used_event = vhost16_to_cpu(vq, event);
-
- return vring_need_event(vq->last_used_event, new, old);
+ return vring_need_event(vhost16_to_cpu(vq, event), new, old);
}
/* This actually signals the guest, using eventfd. */
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index f720958..bb7c29b 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -115,9 +115,6 @@ struct vhost_virtqueue {
/* Last index we used. */
u16 last_used_idx;
- /* Last used evet we've seen */
- u16 last_used_event;
-
/* Used flags */
u16 used_flags;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/4] can: dev: Add support for limiting configured bitrate
From: Franklin S Cooper Jr @ 2017-07-27 1:44 UTC (permalink / raw)
To: Oliver Hartkopp, linux-kernel, devicetree, netdev, linux-can, wg,
mkl, robh+dt, quentin.schulz, andrew
In-Reply-To: <20170726200403.GD6873@airbook.vandijck-laurijssen.be>
Hi Kurt,
On 07/26/2017 03:04 PM, Kurt Van Dijck wrote:
> Hi,
>
> I know my response is late ...
>
>> Hi Oliver
>> On 07/20/2017 02:43 AM, Oliver Hartkopp wrote:
>>> Hi Franklin,
>>>
>>> On 07/20/2017 01:36 AM, Franklin S Cooper Jr wrote:
>>>
>>>> +#ifdef CONFIG_OF
>>>> +void of_transceiver_is_fixed(struct net_device *dev)
>>>> +{
>>>
>>> (..)
>>>
>>>> +}
>>>> +EXPORT_SYMBOL(of_transceiver_is_fixed);
>>>> +#endif
>>>
>>> I'm not sure about the naming here.
>>>
>>> As this is a CAN transceiver related option it should be named accordingly:
>
> I contest the the name too:
> 1) the can transceiver isn't fixed at all, it limited to the higher
> bitrates.
Its "possible" that this subnode may have additional properties beyond
bitrates in the future. But your right as of now it is specifically
addressing max bit rates. The naming of this function and subnode is
based on "fixed-link". So "fixed" is just implying that certain
properties can't be changed.
>
> 2) of_can_transceiver_is_fixed suggests to test if a transceiver is
> fixed, it does not suggest to load some properties from the device tree.
> of_can_load_transceiver looks way more clear to me.
I address this partially in my rev 2 that I've already sent. I'm now
using of_can_transceiver_fixed. The fact its of_ already implies it is
loading properties from device tree. So I don't think
of_can_load_transceiver really makes things clearer.
>
> That's my opinion.
> The important things, like the contents of the functions, look good.
You mind throwing your two cents in the thread for my latest patch?
Specifically the conversation regarding naming the properties. A couple
of people prefer to not use "arbitration" in one of the property names.
Currently I believe there are two options on property names that can be
used and I'm open to a majority vote on which one to go with.
>
> Kind regards,
> Kurt Van Dijck
>
^ permalink raw reply
* RE: [PATCH V2 net-next] TLP: Don't reschedule PTO when there's one outstanding TLP retransmission
From: maowenan @ 2017-07-27 1:33 UTC (permalink / raw)
To: Sergei Shtylyov, netdev@vger.kernel.org, davem@davemloft.net,
ncardwell@google.com, ycheng@google.com, nanditad@google.com,
weiyongjun (A), Chenweilong, Wangkefeng (Kevin)
In-Reply-To: <71ae9007-aedb-2b4e-6aee-b365cb28b0fb@cogentembedded.com>
> -----Original Message-----
> From: Sergei Shtylyov [mailto:sergei.shtylyov@cogentembedded.com]
> Sent: Wednesday, July 26, 2017 6:03 PM
> To: maowenan; netdev@vger.kernel.org; davem@davemloft.net;
> ncardwell@google.com; ycheng@google.com; nanditad@google.com;
> weiyongjun (A); Chenweilong; Wangkefeng (Kevin)
> Subject: Re: [PATCH V2 net-next] TLP: Don't reschedule PTO when there's one
> outstanding TLP retransmission
>
> On 7/26/2017 12:44 PM, Mao Wenan wrote:
>
> > If there is one TLP probe went out(TLP use the write_queue_tail packet
> > as TLP probe, we assume this first TLP probe named A), and this TLP
> > probe was not acked by receive side.
> >
> > Then the transmit side sent the next two packetes out(named B,C), but
> > unfortunately these two packets are also not acked by receive side.
> >
> > And then there is one data packet with ack_seq A arrive at transmit
> > side, in tcp_ack() will call tcp_schedule_loss_probe() to rearm PTO,
> > the handler tcp_send_loss_probe() is to check
> > if(tp->tlp_high_seq) then go to rearm_timer(because there is one
> > outstanding TLP named A), so the new TLP probe can't be sent out and
> > it needs to rearm the RTO timer(timeout is relative to the transmit
> > time of the write queue head).
> >
> > After that, there is another data packet with ack_seq A is received,
> > if the tlp_time_stamp is greater than rto_time_stamp, it will reset
> > the TLP timeout, which is before previous RTO timeout, so PTO is rearm
> > and previous RTO is cleared. Because there is no retransmission packet
> > was sent or no TLP sack receive, tp->tlp_high_seq can't be reset to
> > zero and the next TLP probe also can't be sent out, so there is no
> > way(or very long time) to retransmit the lost packet.
> >
> > This fix is to check(tp->tlp_high_seq) in tcp_schedule_loss_probe()
> > when TLP PTO is after RTO, It is not needed to reschedule PTO when
> > there is one outstanding TLP retransmission, so if the TLP A is lost
> > RTO can retransmit lost packet, then tp->tlp_high_seq will be set to
> > 0, and TLP will go to the normal work process.
> >
> > v1->v2
> > refine some words of code and patch comments.
> >
> > Signed-off-by: Mao Wenan <maowenan@huawei.com>
> > ---
> > net/ipv4/tcp_output.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index
> > 886d874..f85c7ef 100644
> > --- a/net/ipv4/tcp_output.c
> > +++ b/net/ipv4/tcp_output.c
> > @@ -2423,6 +2423,12 @@ bool tcp_schedule_loss_probe(struct sock *sk)
> > tlp_time_stamp = tcp_jiffies32 + timeout;
> > rto_time_stamp = (u32)inet_csk(sk)->icsk_timeout;
> > if ((s32)(tlp_time_stamp - rto_time_stamp) > 0) {
> > + /* It is not needed to reschedule PTO when there
> > + * is one outstanding TLP retransmission.
> > + */
> > + if (tp->tlp_high_seq) {
> > + return false;
> > + }
>
> I have already told you to remove the needless {}... :-/
Thanks, sorry for this.
>
> [...]
>
> MBR, Sergei
^ permalink raw reply
* RE: [PATCH net-next] TLP: Don't reschedule PTO when there's one outstanding TLP retransmission.
From: maowenan @ 2017-07-27 1:28 UTC (permalink / raw)
To: Yuchung Cheng
Cc: Neal Cardwell, Netdev, David Miller, weiyongjun (A), Chenweilong,
Nandita Dukkipati, Wangkefeng (Kevin)
In-Reply-To: <CAK6E8=ciCn1MFkoPXmBV3k34QxzhwK-yLC5_2hd=bb12dG2jRA@mail.gmail.com>
> -----Original Message-----
> From: Yuchung Cheng [mailto:ycheng@google.com]
> Sent: Thursday, July 27, 2017 12:45 AM
> To: maowenan
> Cc: Neal Cardwell; Netdev; David Miller; weiyongjun (A); Chenweilong; Nandita
> Dukkipati; Wangkefeng (Kevin)
> Subject: Re: [PATCH net-next] TLP: Don't reschedule PTO when there's one
> outstanding TLP retransmission.
>
> On Tue, Jul 25, 2017 at 7:12 PM, maowenan <maowenan@huawei.com>
> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Neal Cardwell [mailto:ncardwell@google.com]
> > > Sent: Tuesday, July 25, 2017 9:30 PM
> > > To: maowenan
> > > Cc: Netdev; David Miller; weiyongjun (A); Chenweilong; Yuchung
> > > Cheng; Nandita Dukkipati
> > > Subject: Re: [PATCH net-next] TLP: Don't reschedule PTO when there's
> > > one outstanding TLP retransmission.
> > >
> > > On Tue, Jul 25, 2017 at 4:35 AM, Mao Wenan <maowenan@huawei.com>
> > > wrote:
> > > > If there is one TLP probe went out(TLP use the write_queue_tail
> > > > packet as TLP probe, we assume this first TLP probe named A), and
> > > > this TLP probe was not acked by receive side.
> > > >
> > > > Then the transmit side sent the next two packetes out(named B,C),
> > > > but unfortunately these two packets are also not acked by receive side.
> > > >
> > > > And then there is one data packet with ack_seq A arrive, in
> > > > tcp_ack() will call tcp_schedule_loss_probe() to rearm PTO, the
> > > > handler
> > > > tcp_send_loss_probe() pass if(tp->tlp_high_seq)(because there is
> > > > one outstanding TLP named A,tp->tlp_high_seq is not zero), so the
> > > > new TLP probe can't be went out and need to rearm the RTO
> > > > timer(timeout is relative to the transmit time of the write queue head).
> > > >
> > > > After this, another data packet with ack_seq A is received, if the
> > > > tlp_time_stamp is after rto_time_stamp, it will reset the TLP
> > > > timeout with delta value, which is before previous RTO timeout, so
> > > > PTO is rearm and previous RTO is cleared. This TLP probe also
> > > > can't be sent out because of tp->tlp_high_seq != 0, so there is no
> > > > way(or need very long time)to retransmit the packet because of TLP A is
> lost.
> > > >
> > > > This fix is not to pass the if(tp->tlp_high_seq) in
> > > > tcp_schedule_loss_probe() when TLP PTO is after RTO, It is no need
> > > > to reschedule PTO when there is one outstanding TLP
> > > > retransmission, so if the TLP A is lost then RTO can retransmit
> > > > that packet, and
> > > > tp->tlp_high_seq will be set to 0. After this TLP will go to the
> > > > tp->normal work
> > > process.
> > > >
> > > > Signed-off-by: Mao Wenan <maowenan@huawei.com>
> > >
> > > Thanks for posting this. This is a pretty involved scenario. To help
> > > document/test precisely what the behavior is before and after your
> > > patch, would you be able to post a packetdrill (
> > > https://github.com/google/packetdrill ) test case for this scenario?
> > >
> > > Can I ask if you saw this scenario in an actual trace, or noticed
> > > this by inspection?
> > [Mao Wenan] It is my actual product scenario, from some debug trace
> > info I found that PTO is always rescheduled before RTO, this is PTO is
> > trigged by receiving one tcp_ack packets. After this patch, the
> > product works well and there is no previous issue happen. The packet
> > can retransmit with RTO if TLP probe is lost.
> > I will say sorry that my local test can't reproduce because i can't
> > build successfully the same complex scenario, I don't have mature test
> > case to reproduce now but I will do my best to try in local test environment.
> tcpdump output of an example trace also helps. Feel free to remove IP address,
> ports, or payload information. We only need the timing and TCP header info.
Ok, please check as below. Server: 192.169.0.18, client: 192.169.0.17
......
20:36:12.239562 IP 192.169.0.18.1234 > 192.169.0.17.56246: P 501216544:501216616(72) ack 2308880351 win 92
20:36:12.240034 IP 192.169.0.18.1234 > 192.169.0.17.56246: P 501216616:501216688(72) ack 2308880351 win 92
20:36:12.260764 IP 192.169.0.18.1234 > 192.169.0.17.56246: P 501216616:501216688(72) ack 2308880351 win 92 /* first TLP probe A, seq: 501216616 */
20:36:13.018020 IP 192.169.0.17.56246 > 192.169.0.18.1234: . ack 501216616 win 1970
20:36:13.018386 IP 192.169.0.18.1234 > 192.169.0.17.56246: P 501216688:501216760(72) ack 2308880351 win 92 /* server send packet B */
20:36:13.022448 IP 192.169.0.18.1234 > 192.169.0.17.56246: P 501216760:501216832(72) ack 2308880351 win 92 /* server send packet C */
20:36:13.033813 IP 192.169.0.17.56246 > 192.169.0.18.1234: P 2308880351:2308880437(86) ack 501216616 win 1970 /* receive client data packet ack 501216616 */
20:36:13.034213 IP 192.169.0.17.56246 > 192.169.0.18.1234: P 2308880437:2308880523(86) ack 501216616 win 1970 /* receive client data packet ack 501216616 */
20:36:13.034633 IP 192.169.0.18.1234 > 192.169.0.17.56246: . ack 2308880523 win 92 /* server pure ack client */
20:36:13.039512 IP 192.169.0.17.56246 > 192.169.0.18.1234: P 2308880523:2308880659(136) ack 501216616 win 1970
20:36:13.040083 IP 192.169.0.17.56246 > 192.169.0.18.1234: P 2308880659:2308880795(136) ack 501216616 win 1970
20:36:13.040491 IP 192.169.0.18.1234 > 192.169.0.17.56246: . ack 2308880795 win 92
20:36:13.041161 IP 192.169.0.17.56246 > 192.169.0.18.1234: P 2308880795:2308880931(136) ack 501216616 win 1970
20:36:13.042828 IP 192.169.0.17.56246 > 192.169.0.18.1234: P 2308880931:2308881032(101) ack 501216616 win 1970
20:36:13.043198 IP 192.169.0.18.1234 > 192.169.0.17.56246: . ack 2308881032 win 92
......
>
>
> > Thank you.
> > >
> > > thanks,
> > > neal
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox