* Re: [PATCH] textsearch: fix typos in library helpers
From: David Miller @ 2017-10-22 2:15 UTC (permalink / raw)
To: rdunlap; +Cc: netdev
In-Reply-To: <8d229510-1022-b6fd-f95a-085dbc545c0a@infradead.org>
From: Randy Dunlap <rdunlap@infradead.org>
Date: Fri, 20 Oct 2017 12:15:52 -0700
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix spellos (typos) in textsearch library helpers.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/2] ibmvnic: Tunable parameter support
From: David Miller @ 2017-10-22 2:16 UTC (permalink / raw)
To: jallen; +Cc: netdev, tlfalcon, nfont
In-Reply-To: <9bafaca4-75e7-ba82-8eea-35a69c61b6db@linux.vnet.ibm.com>
From: John Allen <jallen@linux.vnet.ibm.com>
Date: Fri, 20 Oct 2017 16:00:54 -0500
> This series implements support for changing tunable parameters such as the
> mtu, number of tx/rx queues, and number of buffers per queue via ethtool
> and ifconfig.
These patches do not apply to net-next.
^ permalink raw reply
* Re: [PATCH] net: smc_close: mark expected switch fall-throughs
From: David Miller @ 2017-10-22 2:19 UTC (permalink / raw)
To: garsilva; +Cc: ubraun, linux-s390, netdev, linux-kernel
In-Reply-To: <20171021202100.Horde.z-7P99HVhWm0m3hXj5cOjur@gator4166.hostgator.com>
From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Date: Sat, 21 Oct 2017 20:21:00 -0500
>
> Quoting David Miller <davem@davemloft.net>:
>
>> From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
>> Date: Thu, 19 Oct 2017 17:02:44 -0500
>>
>>> @@ -360,7 +360,8 @@ static void smc_close_passive_work(struct
>>> work_struct *work)
>>> case SMC_PEERCLOSEWAIT1:
>>> if (rxflags->peer_done_writing)
>>> sk->sk_state = SMC_PEERCLOSEWAIT2;
>>> - /* fall through to check for closing */
>>> + /* to check for closing */
>>> + /* fall through */
>>
>> Gustavo please look at what you are doing to the code.
>>
>> This was a nice easy to read sentence in the comment, and now
>> you've chopped it up into two pieces and made it awkward and
>> more difficult to read.
>
> You're right.
>
> What about this instead:
>
> /* fall through */
> /* to check for closing */
I'm surprised gcc cares if it's all on one line or not, actually.
^ permalink raw reply
* Re: [PATCH v2] of_mdio: Fix broken PHY IRQ in case of probe deferral
From: David Miller @ 2017-10-22 2:21 UTC (permalink / raw)
To: f.fainelli-Re5JQEeQqe8AvxtiuMwx3w
Cc: geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ, andrew-g2DYL2Zd6BY,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <FD695891-F3B8-4388-8887-A9DC997828B4-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Sat, 21 Oct 2017 19:01:45 -0700
> Reviewed-by : Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> I still can't make sure this is not a problem for multiple PHYs
> hanging off the same bus, but like anything else, we'll deal with
> problems later if they arise.
Thanks Florian.
Applied, thanks everyone.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] ipv6: flowlabel: do not leave opt->tot_len with garbage
From: David Miller @ 2017-10-22 2:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1508613983.30291.33.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 21 Oct 2017 12:26:23 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> When syzkaller team brought us a C repro for the crash [1] that
> had been reported many times in the past, I finally could find
> the root cause.
>
> If FlowLabel info is merged by fl6_merge_options(), we leave
> part of the opt_space storage provided by udp/raw/l2tp with random value
> in opt_space.tot_len, unless a control message was provided at sendmsg()
> time.
>
> Then ip6_setup_cork() would use this random value to perform a kzalloc()
> call. Undefined behavior and crashes.
>
> Fix is to properly set tot_len in fl6_merge_options()
>
> At the same time, we can also avoid consuming memory and cpu cycles
> to clear it, if every option is copied via a kmemdup(). This is the
> change in ip6_setup_cork().
Nice detective work.
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] stmmac: Don't access tx_q->dirty_tx before netif_tx_lock
From: David Miller @ 2017-10-22 2:25 UTC (permalink / raw)
To: bernd.edlinger; +Cc: peppe.cavallaro, alexandre.torgue, netdev, linux-kernel
In-Reply-To: <AM5PR0701MB2657DAF1EEA20231A0FFF50EE4400@AM5PR0701MB2657.eurprd07.prod.outlook.com>
From: Bernd Edlinger <bernd.edlinger@hotmail.de>
Date: Sat, 21 Oct 2017 06:51:30 +0000
> This is the possible reason for different hard to reproduce
> problems on my ARMv7-SMP test system.
>
> The symptoms are in recent kernels imprecise external aborts,
> and in older kernels various kinds of network stalls and
> unexpected page allocation failures.
>
> My testing indicates that the trouble started between v4.5 and v4.6
> and prevails up to v4.14.
>
> Using the dirty_tx before acquiring the spin lock is clearly
> wrong and was first introduced with v4.6.
>
> Fixes: e3ad57c96715 ("stmmac: review RX/TX ring management")
>
> Signed-off-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Applied, thank you.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2017-10-22 2:34 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
A little more than usual this time around. Been travelling, so that is
part of it.
Anyways, here are the highlights:
1) Deal with memcontrol races wrt. listener dismantle, from Eric
Dumazet.
2) Handle page allocation failures properly in nfp driver, from
Jaku Kicinski.
3) Fix memory leaks in macsec, from Sabrina Dubroca.
4) Fix crashes in pppol2tp_session_ioctl(), from Guillaume Nault.
5) Several fixes in bnxt_en driver, including preventing potential NVRAM
parameter corruption from Michael Chan.
6) Fix for KRACK attacks in wireless, from Johannes Berg.
7) rtnetlink event generation fixes from Xin Long.
8) Deadlock in mlxsw driver, from Ido Schimmel.
9) Disallow arithmetic operations on context pointers in bpf, from
Jakub Kicinski.
10) Missing sock_owned_by_user() check in sctp_icmp_redirect(), from
Xin Long.
11) Only TCP is supported for sockmap, make that explicit with a check,
from John Fastabend.
12) Fix IP options state races in DCCP and TCP, from Eric Dumazet.
13) Fix panic in packet_getsockopt(), also from Eric Dumazet.
14) Add missing locked in hv_sock layer, from Dexuan Cui.
15) Various aquantia bug fixes, including several statistics handling
cures. From Igor Russkikh et al.
16) Fix arithmetic overflow in devmap code, from John Fastabend.
17) Fix busted socket memory accounting when we get a fault in the tcp
zero copy paths. From Willem de Bruijn.
18) Don't leave opt->tot_len uninitialized in ipv6, from Eric Dumazet.
Please pull, thanks a lot!
The following changes since commit 529a86e063e9ff625c4ff247d8aa17d8072444fb:
Merge branch 'ppc-bundle' (bundle from Michael Ellerman) (2017-10-09 19:08:32 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 8d5f4b07174976c55a5f5d6967777373c6826944:
stmmac: Don't access tx_q->dirty_tx before netif_tx_lock (2017-10-22 03:24:43 +0100)
----------------------------------------------------------------
Alexander Duyck (1):
i40e: Fix memory leak related filter programming status
Arnd Bergmann (2):
brcmsmac: make some local variables 'static const' to reduce stack size
liquidio: fix timespec64_to_ns typo
Behan Webster (1):
wimax/i2400m: Remove VLAIS
Bernd Edlinger (1):
stmmac: Don't access tx_q->dirty_tx before netif_tx_lock
Chaya Rachel Ivgi (1):
iwlwifi: nvm: set the correct offsets to 3168 series
Colin Ian King (1):
can: bcm: check for null sk before deferencing it via the call to sock_net
Cong Wang (1):
tun: call dev_get_valid_name() before register_netdevice()
Craig Gallek (1):
soreuseport: fix initialization race
Daniel Borkmann (6):
mm, percpu: add support for __GFP_NOWARN flag
bpf: fix splat for illegal devmap percpu allocation
bpf: do not test for PCPU_MIN_UNIT_SIZE before percpu allocations
bpf: fix off by one for range markings with L{T, E} patterns
bpf: fix pattern matches for direct packet access
bpf: add test cases to bpf selftests to cover all access tests
Daniel Drake (1):
r8169: only enable PCI wakeups when WOL is active
David Howells (1):
rxrpc: Don't release call mutex on error pointer
David S. Miller (14):
Merge branch '40GbE' of git://git.kernel.org/.../jkirsher/net-queue
Merge branch 'nfp-fix-ethtool-stats-and-page-allocation'
Merge tag 'wireless-drivers-for-davem-2017-10-13' of git://git.kernel.org/.../kvalo/wireless-drivers
Merge branch 'bnxt_en-fixes'
Merge branch 'rtnetlink-dev-notification-fixes'
Merge tag 'mac80211-for-davem-2017-10-16' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'ena-fixes'
Merge branch 'bpf-Fix-for-BPF-devmap-percpu-allocation-splat'
Merge branch 'sockmap-fixes'
Merge tag 'linux-can-fixes-for-4.14-20171019' of git://git.kernel.org/.../mkl/linux-can
Merge branch 'aquantia-fixes'
Merge branch 'bpf-range-marking-fixes'
Merge branch 'mlxsw-fixes'
Merge branch 'stmmac-hw-tstamp-fixes'
Dexuan Cui (1):
hv_sock: add locking in the open/close/release code paths
Emiliano Ingrassia (1):
net: stmmac: dwmac_lib: fix interchanged sleep/timeout values in DMA reset function
Eric Dumazet (7):
net: memcontrol: defer call to mem_cgroup_sk_alloc()
net: defer call to cgroup_sk_alloc()
Revert "net: defer call to cgroup_sk_alloc()"
net: call cgroup_sk_alloc() earlier in sk_clone_lock()
tcp/dccp: fix ireq->opt races
packet: avoid panic in packet_getsockopt()
ipv6: flowlabel: do not leave opt->tot_len with garbage
Gavin Shan (3):
net/ncsi: Disable HWA mode when no channels are found
net/ncsi: Enforce failover on link monitor timeout
net/ncsi: Fix length of GVI response packet
Geert Uytterhoeven (1):
of_mdio: Fix broken PHY IRQ in case of probe deferral
Golan Ben Ami (1):
iwlwifi: stop dbgc recording before stopping DMA
Guillaume Nault (1):
l2tp: check ps->sock before running pppol2tp_session_ioctl()
Ido Schimmel (1):
mlxsw: core: Fix possible deadlock
Igor Russkikh (7):
net: aquantia: Reset nic statistics on interface up/down
net: aquantia: Add queue restarts stats counter
net: aquantia: Fixed transient link up/down/up notification
net: aquantia: Limit number of MSIX irqs to the number of cpus
net: aquantia: mmio unmap was not performed on driver removal
net: aquantia: Enable coalescing management via ethtool interface
net: aquantia: Bad udp rate on default interrupt coalescing
Jakub Kicinski (3):
nfp: fix ethtool stats gather retry
nfp: handle page allocation failures
bpf: disallow arithmetic operations on context pointer
Johannes Berg (3):
iwlwifi: nvm-parse: unify channel flags printing
mac80211: accept key reinstall without changing anything
netlink: fix netlink_ack() extack race
John Fastabend (6):
bpf: enforce TCP only support for sockmap
bpf: avoid preempt enable/disable in sockmap using tcp_skb_cb region
bpf: remove mark access for SK_SKB program types
bpf: require CAP_NET_ADMIN when using sockmap maps
bpf: require CAP_NET_ADMIN when using devmap
bpf: devmap fix arithmetic overflow in bitmap_size calculation
Jose Abreu (3):
net: stmmac: Add missing call to dev_kfree_skb()
net: stmmac: Fix stmmac_get_rx_hwtstamp()
net: stmmac: Prevent infinite loop in get_rx_timestamp_status()
Kalle Valo (1):
Merge tag 'iwlwifi-for-kalle-2017-10-06' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Kevin Cernekee (1):
brcmfmac: Add check for short event packets
Larry Finger (1):
rtlwifi: rtl8821ae: Fix connection lost problem
Luca Coelho (1):
iwlwifi: mvm: return -ENODATA when reading the temperature with the FW down
Marc Kleine-Budde (2):
can: af_can: do not access proto_tab directly use rcu_access_pointer instead
can: af_can: can_pernet_init(): add missing error handling for kzalloc returning NULL
Matteo Croce (1):
udp: make some messages more descriptive
Michael Chan (4):
bnxt_en: Improve VF/PF link change logic.
bnxt_en: Don't use rtnl lock to protect link change logic in workqueue.
bnxt_en: Fix VF resource checking.
bnxt_en: Fix possible corrupted NVRAM parameters from firmware response.
Netanel Belgazal (3):
net: ena: reduce the severity of some printouts
net: ena: fix rare kernel crash when bar memory remap fails
net: ena: fix wrong max Tx/Rx queues on ethtool
Nicolas Dichtel (1):
net: enable interface alias removal via rtnl
Niklas Söderlund (1):
net: ethtool: remove error check for legacy setting transceiver type
Nikolay Aleksandrov (1):
net: bridge: fix returning of vlan range op errors
Or Gerlitz (1):
net/sched: cls_flower: Set egress_dev mark when calling into the HW driver
Petr Machata (2):
mlxsw: reg: Add Tunneling IPinIP General Configuration Register
mlxsw: spectrum_router: Configure TIGCR on init
Randy Dunlap (1):
textsearch: fix typos in library helpers
Sabrina Dubroca (1):
macsec: fix memory leaks when skb_to_sgvec fails
Samuel Mendoza-Jonas (3):
net/ncsi: Don't limit vids based on hot_channel
net/ncsi: Fix AEN HNCDSC packet length
net/ncsi: Stop monitor if channel times out or is inactive
Sankar Patchineelam (1):
bnxt_en: Fix possible corruption in DCB parameters from firmware.
Shaul Triebitz (1):
iwlwifi: mvm: do not print security error in monitor mode
Stefan Mätje (1):
can: esd_usb2: Fix can_dlc value for received RTR, frames
Stefano Brivio (2):
i40e: Fix comment about locking for __i40e_read_nvm_word()
geneve: Fix function matching VNI and tunnel ID on big-endian
Stephen Hemminger (1):
ip: update policy routing config help
Thomas Falcon (1):
ibmvnic: Fix calculation of number of TX header descriptors
Vasundhara Volam (1):
bnxt_en: Fix VF PCIe link speed and width logic.
Vivien Didelot (1):
net: dsa: mv88e6060: fix switch MAC address
Wenhua Shi (1):
net: fix typo in skbuff.c
Willem de Bruijn (1):
sock: correct sk_wmem_queued accounting on efault in tcp zerocopy
Wolfgang Grandegger (1):
can: gs_usb: fix busy loop if no more TX context is available
Xin Long (9):
rtnetlink: bring NETDEV_CHANGEMTU event process back in rtnetlink_event
rtnetlink: bring NETDEV_CHANGE_TX_QUEUE_LEN event process back in rtnetlink_event
rtnetlink: bring NETDEV_POST_TYPE_CHANGE event process back in rtnetlink_event
rtnetlink: bring NETDEV_CHANGEUPPER event process back in rtnetlink_event
rtnetlink: check DO_SETLINK_NOTIFY correctly in do_setlink
rtnetlink: do not set notification for tx_queue_len in do_setlink
dev_ioctl: add missing NETDEV_CHANGE_TX_QUEUE_LEN event notification
sctp: do not peel off an assoc from one netns to another one
sctp: add the missing sock_owned_by_user check in sctp_icmp_redirect
ZHU Yi (ST-FIR/ENG1-Zhu) (6):
can: flexcan: fix state transition regression
can: flexcan: rename legacy error state quirk
can: flexcan: implement error passive state quirk
can: flexcan: fix i.MX6 state transition issue
can: flexcan: fix i.MX28 state transition issue
can: flexcan: fix p1010 state transition issue
drivers/net/can/flexcan.c | 91 +++++++--
drivers/net/can/usb/esd_usb2.c | 2 +-
drivers/net/can/usb/gs_usb.c | 10 +-
drivers/net/dsa/mv88e6060.c | 10 +-
drivers/net/ethernet/amazon/ena/ena_ethtool.c | 4 +-
drivers/net/ethernet/amazon/ena/ena_netdev.c | 7 +-
drivers/net/ethernet/aquantia/atlantic/aq_cfg.h | 8 +-
drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c | 157 ++++++++------
drivers/net/ethernet/aquantia/atlantic/aq_hw.h | 5 +-
drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 39 +++-
drivers/net/ethernet/aquantia/atlantic/aq_nic.h | 4 +-
drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c | 14 +-
drivers/net/ethernet/aquantia/atlantic/aq_vec.c | 3 +
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_a0.c | 21 +-
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c | 89 ++++----
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0_internal.h | 3 +
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c | 69 +++++--
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.h | 18 +-
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 99 ++++++---
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 5 +
drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c | 23 ++-
drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 8 +-
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 11 +-
drivers/net/ethernet/cavium/liquidio/lio_main.c | 2 +-
drivers/net/ethernet/ibm/ibmvnic.c | 16 +-
drivers/net/ethernet/intel/i40e/i40e_nvm.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 63 +++---
drivers/net/ethernet/mellanox/mlxsw/core.c | 11 +-
drivers/net/ethernet/mellanox/mlxsw/reg.h | 31 +++
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 11 +-
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 20 +-
drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c | 8 +-
drivers/net/ethernet/realtek/r8169.c | 2 -
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 17 +-
drivers/net/geneve.c | 6 -
drivers/net/macsec.c | 2 +
drivers/net/tun.c | 3 +
drivers/net/wimax/i2400m/fw.c | 2 +-
drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c | 3 +-
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c | 197 +++++++++---------
drivers/net/wireless/intel/iwlwifi/cfg/7000.c | 1 +
drivers/net/wireless/intel/iwlwifi/cfg/8000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/a000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/fw/api/nvm-reg.h | 2 +
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 7 +-
drivers/net/wireless/intel/iwlwifi/fw/dbg.h | 15 ++
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 16 +-
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 137 ++++++-------
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 7 +
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 5 +-
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 21 +-
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 2 +-
drivers/of/of_mdio.c | 39 ++--
include/linux/filter.h | 2 +-
include/linux/netdevice.h | 3 +
include/net/inet_sock.h | 2 +-
include/net/tcp.h | 5 +
kernel/bpf/arraymap.c | 2 +-
kernel/bpf/devmap.c | 10 +-
kernel/bpf/hashtab.c | 4 -
kernel/bpf/sockmap.c | 28 ++-
kernel/bpf/verifier.c | 65 ++++--
lib/ts_fsm.c | 2 +-
lib/ts_kmp.c | 2 +-
mm/memcontrol.c | 15 --
mm/percpu.c | 15 +-
net/bridge/br_netlink.c | 2 +-
net/can/af_can.c | 20 +-
net/can/bcm.c | 5 +-
net/core/dev.c | 6 +-
net/core/dev_ioctl.c | 13 +-
net/core/ethtool.c | 5 +-
net/core/filter.c | 31 +--
net/core/rtnetlink.c | 13 +-
net/core/skbuff.c | 6 +-
net/core/sock.c | 8 +-
net/core/sock_reuseport.c | 12 +-
net/dccp/ipv4.c | 13 +-
net/ipv4/Kconfig | 8 +-
net/ipv4/cipso_ipv4.c | 24 +--
net/ipv4/inet_connection_sock.c | 9 +-
net/ipv4/inet_hashtables.c | 5 +-
net/ipv4/syncookies.c | 2 +-
net/ipv4/tcp_input.c | 2 +-
net/ipv4/tcp_ipv4.c | 22 +-
net/ipv4/udp.c | 9 +-
net/ipv6/ip6_flowlabel.c | 1 +
net/ipv6/ip6_output.c | 4 +-
net/l2tp/l2tp_ppp.c | 3 +
net/mac80211/key.c | 21 +-
net/ncsi/internal.h | 1 +
net/ncsi/ncsi-aen.c | 2 +-
net/ncsi/ncsi-manage.c | 52 +++--
net/ncsi/ncsi-rsp.c | 2 +-
net/netlink/af_netlink.c | 8 +-
net/packet/af_packet.c | 24 ++-
net/rxrpc/af_rxrpc.c | 5 +-
net/sched/cls_flower.c | 2 +
net/sctp/input.c | 2 +-
net/sctp/socket.c | 4 +
net/vmw_vsock/hyperv_transport.c | 22 +-
samples/sockmap/sockmap_kern.c | 2 +-
tools/include/uapi/linux/bpf.h | 3 +-
tools/testing/selftests/bpf/bpf_helpers.h | 2 +-
tools/testing/selftests/bpf/sockmap_verdict_prog.c | 4 +-
tools/testing/selftests/bpf/test_maps.c | 12 +-
tools/testing/selftests/bpf/test_verifier.c | 510 +++++++++++++++++++++++++++++++++++++++++++++-
113 files changed, 1735 insertions(+), 689 deletions(-)
^ permalink raw reply
* [net-next] tcp: do tcp_mstamp_refresh before retransmits on TSQ handler
From: Koichiro Den @ 2017-10-22 3:38 UTC (permalink / raw)
To: netdev; +Cc: eric.dumazet, davem, kuznet, yoshfuji
When retransmission on TSQ handler was introduced in the commit
f9616c35a0d7 ("tcp: implement TSQ for retransmits"), the retransmitted
skbs' timestamps were updated on the actual transmission. In the later
commit 385e20706fac ("tcp: use tp->tcp_mstamp in output path"), it stops
being done so. In the commit, the comment says "We try to refresh
tp->tcp_mstamp only when necessary", and at present tcp_tsq_handler and
tcp_v4_mtu_reduced applies to this. About the latter, it's okay since
it's rare enough.
About the former, even though possible retransmissions on the tasklet
comes just after the destructor run in NET_RX softirq handling, the time
between them could be nonnegligibly large to the extent that
tcp_rack_advance or rto rearming be affected if other (remaining) RX,
BLOCK and (preceding) TASKLET sofirq handlings are unexpectedly heavy.
So in the same way as tcp_write_timer_handler does, doing tcp_mstamp_refresh
ensures the accuracy of algorithms relying on it.
Signed-off-by: Koichiro Den <den@klaipeden.com>
---
net/ipv4/tcp_output.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 988733f289c8..7a4d9b719b47 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -743,8 +743,10 @@ static void tcp_tsq_handler(struct sock *sk)
struct tcp_sock *tp = tcp_sk(sk);
if (tp->lost_out > tp->retrans_out &&
- tp->snd_cwnd > tcp_packets_in_flight(tp))
+ tp->snd_cwnd > tcp_packets_in_flight(tp)) {
+ tcp_mstamp_refresh(tp);
tcp_xmit_retransmit_queue(sk);
+ }
tcp_write_xmit(sk, tcp_current_mss(sk), tp->nonagle,
0, GFP_ATOMIC);
--
2.9.4
^ permalink raw reply related
* Re: [net-next] tcp: do tcp_mstamp_refresh before retransmits on TSQ handler
From: Eric Dumazet @ 2017-10-22 3:52 UTC (permalink / raw)
To: Koichiro Den; +Cc: netdev, davem
In-Reply-To: <20171022033808.12641-1-den@klaipeden.com>
On Sun, 2017-10-22 at 12:38 +0900, Koichiro Den wrote:
> When retransmission on TSQ handler was introduced in the commit
> f9616c35a0d7 ("tcp: implement TSQ for retransmits"), the retransmitted
> skbs' timestamps were updated on the actual transmission. In the later
> commit 385e20706fac ("tcp: use tp->tcp_mstamp in output path"), it stops
> being done so. In the commit, the comment says "We try to refresh
> tp->tcp_mstamp only when necessary", and at present tcp_tsq_handler and
> tcp_v4_mtu_reduced applies to this. About the latter, it's okay since
> it's rare enough.
>
> About the former, even though possible retransmissions on the tasklet
> comes just after the destructor run in NET_RX softirq handling, the time
> between them could be nonnegligibly large to the extent that
> tcp_rack_advance or rto rearming be affected if other (remaining) RX,
> BLOCK and (preceding) TASKLET sofirq handlings are unexpectedly heavy.
>
> So in the same way as tcp_write_timer_handler does, doing tcp_mstamp_refresh
> ensures the accuracy of algorithms relying on it.
>
> Signed-off-by: Koichiro Den <den@klaipeden.com>
> ---
> net/ipv4/tcp_output.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Very nice catch, thanks a lot Koichiro.
This IMO would target net tree, since it is a bug fix.
Fixes: 385e20706fac ("tcp: use tp->tcp_mstamp in output path")
Thanks !
We should have caught that in our regression packetdrill tests...
^ permalink raw reply
* Re: [net-next] tcp: do tcp_mstamp_refresh before retransmits on TSQ handler
From: Eric Dumazet @ 2017-10-22 3:52 UTC (permalink / raw)
To: Koichiro Den; +Cc: netdev, davem
In-Reply-To: <1508644334.30291.38.camel@edumazet-glaptop3.roam.corp.google.com>
On Sat, 2017-10-21 at 20:52 -0700, Eric Dumazet wrote:
> Very nice catch, thanks a lot Koichiro.
>
> This IMO would target net tree, since it is a bug fix.
>
> Fixes: 385e20706fac ("tcp: use tp->tcp_mstamp in output path")
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* RE: [PATCH 02/15] drivers, net, ethernet: convert mtk_eth.dma_refcnt from atomic_t to refcount_t
From: Sean Wang @ 2017-10-22 4:06 UTC (permalink / raw)
To: Reshetova, Elena
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-rdma@vger.kernel.org,
linux-hams@vger.kernel.org, linux-ppp@vger.kernel.org,
ganeshgr@chelsio.com, nbd@openwrt.org, john@phrozen.org,
matthias.bgg@gmail.com, yishaih@mellanox.com, saeedm@mellanox.com,
"matanb@mell
In-Reply-To: <2236FBA76BA1254E88B949DDB74E612B802B37EE@IRSMSX102.ger.corp.intel.com>
On Fri, 2017-10-20 at 10:37 +0000, Reshetova, Elena wrote:
> > On Fri, 2017-10-20 at 10:23 +0300, Elena Reshetova wrote:
> > > atomic_t variables are currently used to implement reference
> > > counters with the following properties:
> > > - counter is initialized to 1 using atomic_set()
> > > - a resource is freed upon counter reaching zero
> > > - once counter reaches zero, its further
> > > increments aren't allowed
> > > - counter schema uses basic atomic operations
> > > (set, inc, inc_not_zero, dec_and_test, etc.)
> > >
> > > Such atomic variables should be converted to a newly provided
> > > refcount_t type and API that prevents accidental counter overflows
> > > and underflows. This is important since overflows and underflows
> > > can lead to use-after-free situation and be exploitable.
> > >
> > > The variable mtk_eth.dma_refcnt is used as pure reference counter.
> > > Convert it to refcount_t and fix up the operations.
> > >
> > > Suggested-by: Kees Cook <keescook@chromium.org>
> > > Reviewed-by: David Windsor <dwindsor@gmail.com>
> > > Reviewed-by: Hans Liljestrand <ishkamiel@gmail.com>
> > > Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
> > > ---
> > > drivers/net/ethernet/mediatek/mtk_eth_soc.c | 8 +++++---
> > > drivers/net/ethernet/mediatek/mtk_eth_soc.h | 4 +++-
> > > 2 files changed, 8 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > index 5e81a72..54adfd9 100644
> > > --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > @@ -1817,7 +1817,7 @@ static int mtk_open(struct net_device *dev)
> > > struct mtk_eth *eth = mac->hw;
> > >
> > > /* we run 2 netdevs on the same dma ring so we only bring it up once
> > */
> > > - if (!atomic_read(ð->dma_refcnt)) {
> > > + if (!refcount_read(ð->dma_refcnt)) {
> > > int err = mtk_start_dma(eth);
> > >
> > > if (err)
> > > @@ -1827,8 +1827,10 @@ static int mtk_open(struct net_device *dev)
> > > napi_enable(ð->rx_napi);
> > > mtk_tx_irq_enable(eth, MTK_TX_DONE_INT);
> > > mtk_rx_irq_enable(eth, MTK_RX_DONE_INT);
> > > + refcount_set(ð->dma_refcnt, 1);
> >
> > the existing driver seems to have a missing initial atomic_set for the
> > eth->dma_refcnt.
> >
> > > }
> > > - atomic_inc(ð->dma_refcnt);
> > > + else
> > > + refcount_inc(ð->dma_refcnt);
> > >
> >
> > how about add the initial refcount_set into probe handler, and keep
> > logic else unchanged ?
>
> Sure, I guess you mean mtk_probe() function? I can move the refcount_set to be there
> and remove this change.
>
> Should I resend the modified patch to you (maybe then two of the ethernet patches)?
>
> Best Regards,
> Elena.
The entire series has been applies to net-next, I think I can make the
follow-ups patches relative to your work.
Sean
> >
> > > phy_start(dev->phydev);
> > > netif_start_queue(dev);
> > > @@ -1868,7 +1870,7 @@ static int mtk_stop(struct net_device *dev)
> > > phy_stop(dev->phydev);
> > >
> > > /* only shutdown DMA if this is the last user */
> > > - if (!atomic_dec_and_test(ð->dma_refcnt))
> > > + if (!refcount_dec_and_test(ð->dma_refcnt))
> > > return 0;
> > >
> > > mtk_tx_irq_disable(eth, MTK_TX_DONE_INT);
> > > diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> > b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> > > index 3d3c24a..a3af466 100644
> > > --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> > > +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> > > @@ -15,6 +15,8 @@
> > > #ifndef MTK_ETH_H
> > > #define MTK_ETH_H
> > >
> > > +#include <linux/refcount.h>
> > > +
> > > #define MTK_QDMA_PAGE_SIZE 2048
> > > #define MTK_MAX_RX_LENGTH 1536
> > > #define MTK_TX_DMA_BUF_LEN 0x3fff
> > > @@ -632,7 +634,7 @@ struct mtk_eth {
> > > struct regmap *pctl;
> > > u32 chip_id;
> > > bool hwlro;
> > > - atomic_t dma_refcnt;
> > > + refcount_t dma_refcnt;
> > > struct mtk_tx_ring tx_ring;
> > > struct mtk_rx_ring
> > rx_ring[MTK_MAX_RX_RING_NUM];
> > > struct mtk_rx_ring rx_ring_qdma;
> >
>
^ permalink raw reply
* Re: [net-next] tcp: do tcp_mstamp_refresh before retransmits on TSQ handler
From: Koichiro Den @ 2017-10-22 4:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem
In-Reply-To: <1508644334.30291.38.camel@edumazet-glaptop3.roam.corp.google.com>
On Sat, 2017-10-21 at 20:52 -0700, Eric Dumazet wrote:
> On Sun, 2017-10-22 at 12:38 +0900, Koichiro Den wrote:
> > When retransmission on TSQ handler was introduced in the commit
> > f9616c35a0d7 ("tcp: implement TSQ for retransmits"), the retransmitted
> > skbs' timestamps were updated on the actual transmission. In the later
> > commit 385e20706fac ("tcp: use tp->tcp_mstamp in output path"), it stops
> > being done so. In the commit, the comment says "We try to refresh
> > tp->tcp_mstamp only when necessary", and at present tcp_tsq_handler and
> > tcp_v4_mtu_reduced applies to this. About the latter, it's okay since
> > it's rare enough.
> >
> > About the former, even though possible retransmissions on the tasklet
> > comes just after the destructor run in NET_RX softirq handling, the time
> > between them could be nonnegligibly large to the extent that
> > tcp_rack_advance or rto rearming be affected if other (remaining) RX,
> > BLOCK and (preceding) TASKLET sofirq handlings are unexpectedly heavy.
> >
> > So in the same way as tcp_write_timer_handler does, doing tcp_mstamp_refresh
> > ensures the accuracy of algorithms relying on it.
> >
> > Signed-off-by: Koichiro Den <den@klaipeden.com>
> > ---
> > net/ipv4/tcp_output.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
>
> Very nice catch, thanks a lot Koichiro.
>
> This IMO would target net tree, since it is a bug fix.
>
> Fixes: 385e20706fac ("tcp: use tp->tcp_mstamp in output path")
Ok I will submit it to net tree. Thanks!
>
> Thanks !
>
> We should have caught that in our regression packetdrill tests...
In its "remote" mode testing not relying on tun xmit, I agree it could be
caught. If it's better to write, test and attach the script, please let me know.
Thank you.
^ permalink raw reply
* [net] tcp: do tcp_mstamp_refresh before retransmits on TSQ handler
From: Koichiro Den @ 2017-10-22 4:13 UTC (permalink / raw)
To: netdev; +Cc: eric.dumazet, davem, kuznet, yoshfuji
When retransmission on TSQ handler was introduced in the commit
f9616c35a0d7 ("tcp: implement TSQ for retransmits"), the retransmitted
skbs' timestamps were updated on the actual transmission. In the later
commit 385e20706fac ("tcp: use tp->tcp_mstamp in output path"), it stops
being done so. In the commit, the comment says "We try to refresh
tp->tcp_mstamp only when necessary", and at present tcp_tsq_handler and
tcp_v4_mtu_reduced applies to this. About the latter, it's okay since
it's rare enough.
About the former, even though possible retransmissions on the tasklet
comes just after the destructor run in NET_RX softirq handling, the time
between them could be nonnegligibly large to the extent that
tcp_rack_advance or rto rearming be affected if other (remaining) RX,
BLOCK and (preceding) TASKLET sofirq handlings are unexpectedly heavy.
So in the same way as tcp_write_timer_handler does, doing tcp_mstamp_refresh
ensures the accuracy of algorithms relying on it.
Fixes: 385e20706fac ("tcp: use tp->tcp_mstamp in output path")
Signed-off-by: Koichiro Den <den@klaipeden.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/tcp_output.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 0bc9e46a5369..973befc36fd4 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -739,8 +739,10 @@ static void tcp_tsq_handler(struct sock *sk)
struct tcp_sock *tp = tcp_sk(sk);
if (tp->lost_out > tp->retrans_out &&
- tp->snd_cwnd > tcp_packets_in_flight(tp))
+ tp->snd_cwnd > tcp_packets_in_flight(tp)) {
+ tcp_mstamp_refresh(tp);
tcp_xmit_retransmit_queue(sk);
+ }
tcp_write_xmit(sk, tcp_current_mss(sk), tp->nonagle,
0, GFP_ATOMIC);
--
2.9.4
^ permalink raw reply related
* Re: [net-next] tcp: do tcp_mstamp_refresh before retransmits on TSQ handler
From: Eric Dumazet @ 2017-10-22 5:21 UTC (permalink / raw)
To: Koichiro Den; +Cc: netdev, davem
In-Reply-To: <1508645419.9317.7.camel@klaipeden.com>
On Sun, 2017-10-22 at 13:10 +0900, Koichiro Den wrote:
> On Sat, 2017-10-21 at 20:52 -0700, Eric Dumazet wrote:
> > On Sun, 2017-10-22 at 12:38 +0900, Koichiro Den wrote:
> > > When retransmission on TSQ handler was introduced in the commit
> > > f9616c35a0d7 ("tcp: implement TSQ for retransmits"), the retransmitted
> > > skbs' timestamps were updated on the actual transmission. In the later
> > > commit 385e20706fac ("tcp: use tp->tcp_mstamp in output path"), it stops
> > > being done so. In the commit, the comment says "We try to refresh
> > > tp->tcp_mstamp only when necessary", and at present tcp_tsq_handler and
> > > tcp_v4_mtu_reduced applies to this. About the latter, it's okay since
> > > it's rare enough.
> > >
> > > About the former, even though possible retransmissions on the tasklet
> > > comes just after the destructor run in NET_RX softirq handling, the time
> > > between them could be nonnegligibly large to the extent that
> > > tcp_rack_advance or rto rearming be affected if other (remaining) RX,
> > > BLOCK and (preceding) TASKLET sofirq handlings are unexpectedly heavy.
> > >
> > > So in the same way as tcp_write_timer_handler does, doing tcp_mstamp_refresh
> > > ensures the accuracy of algorithms relying on it.
> > >
> > > Signed-off-by: Koichiro Den <den@klaipeden.com>
> > > ---
> > > net/ipv4/tcp_output.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > Very nice catch, thanks a lot Koichiro.
> >
> > This IMO would target net tree, since it is a bug fix.
> >
> > Fixes: 385e20706fac ("tcp: use tp->tcp_mstamp in output path")
> Ok I will submit it to net tree. Thanks!
> >
> > Thanks !
> >
> > We should have caught that in our regression packetdrill tests...
> In its "remote" mode testing not relying on tun xmit, I agree it could be
> caught. If it's better to write, test and attach the script, please let me know.
Packetdrill in the normal (local) mode will do it.
Push fq packet scheduler on tun0, and packets will be held long enough
in FQ that TSQ will be effective.
Adding TCP TS support on folloginw packetdrill test should demonstrate
the issue and if your patch cures it.
// Test if TSQ applies to retransmits.
`tc qdisc replace dev tun0 root fq quantum 1514 initial_quantum 1514 flow_limit 5
sysctl -e -q net.ipv4.tcp_min_tso_segs=1`
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
+0 < S 0:0(0) win 32792 <mss 1460,sackOK,nop,nop,nop,wscale 7>
+0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8>
+.01 < . 1:1(0) ack 1 win 1500
+0 accept(3, ..., ...) = 4
+0 %{ assert tcpi_snd_cwnd == 10, tcpi_snd_cwnd }%
// send one frame per ms
+0 setsockopt(4, SOL_SOCKET, SO_MAX_PACING_RATE, [1514000], 4) = 0
+0 setsockopt(4, SOL_SOCKET, SO_SNDBUF, [1000000], 4) = 0
+0 write(4, ..., 120000) = 120000
+0 > . 1:1461(1460) ack 1
+.001 > . 1461:2921(1460) ack 1
+.001 > . 2921:4381(1460) ack 1
+.001 > . 4381:5841(1460) ack 1
+.001 > . 5841:7301(1460) ack 1
+.001 > . 7301:8761(1460) ack 1
+.001 > . 8761:10221(1460) ack 1
+.001 > . 10221:11681(1460) ack 1
+.001 > . 11681:13141(1460) ack 1
+.001 > . 13141:14601(1460) ack 1
+.01 < . 1:1(0) ack 14601 win 1500
+.001 > . 14601:16061(1460) ack 1
+.001 > . 16061:17521(1460) ack 1
+.001 > . 17521:18981(1460) ack 1
+.001 > . 18981:20441(1460) ack 1
+.001 > . 20441:21901(1460) ack 1
+.001 > . 21901:23361(1460) ack 1
+.001 > . 23361:24821(1460) ack 1
+.001 > . 24821:26281(1460) ack 1
+.001 > . 26281:27741(1460) ack 1
+.001 > . 27741:29201(1460) ack 1
+.001 > . 29201:30661(1460) ack 1
+.001 > . 30661:32121(1460) ack 1
+.001 > . 32121:33581(1460) ack 1
+.001 > . 33581:35041(1460) ack 1
+.001 > . 35041:36501(1460) ack 1
+.001 > . 36501:37961(1460) ack 1
+.001 > . 37961:39421(1460) ack 1
+.001 > . 39421:40881(1460) ack 1
+.001 > . 40881:42341(1460) ack 1
+.001 > . 42341:43801(1460) ack 1
+.01 < . 1:1(0) ack 43801 win 1500
+.001 > . 43801:45261(1460) ack 1
+.001 > . 45261:46721(1460) ack 1
+.001 > . 46721:48181(1460) ack 1
+.001 > . 48181:49641(1460) ack 1
+.001 > . 49641:51101(1460) ack 1
+.001 > . 51101:52561(1460) ack 1
+.001 > . 52561:54021(1460) ack 1
+.001 > . 54021:55481(1460) ack 1
+.001 > . 55481:56941(1460) ack 1
+.001 > . 56941:58401(1460) ack 1
+.001 > . 58401:59861(1460) ack 1
+.001 > . 59861:61321(1460) ack 1
+.001 > . 61321:62781(1460) ack 1
+.001 > . 62781:64241(1460) ack 1
+.001 > . 64241:65701(1460) ack 1
+.001 > . 65701:67161(1460) ack 1
+.001 > . 67161:68621(1460) ack 1
+.001 > . 68621:70081(1460) ack 1
+.001 > . 70081:71541(1460) ack 1
+.001 > . 71541:73001(1460) ack 1
+.001 > . 73001:74461(1460) ack 1
+.001 > . 74461:75921(1460) ack 1
+.001 > . 75921:77381(1460) ack 1
+.001 > . 77381:78841(1460) ack 1
+.001 > . 78841:80301(1460) ack 1
+.001 > . 80301:81761(1460) ack 1
+.001 > . 81761:83221(1460) ack 1
+.001 > . 83221:84681(1460) ack 1
+.001 > . 84681:86141(1460) ack 1
+.001 > . 86141:87601(1460) ack 1
+.001 > . 87601:89061(1460) ack 1
+.001 > . 89061:90521(1460) ack 1
+.001 > . 90521:91981(1460) ack 1
+.001 > . 91981:93441(1460) ack 1
+.001 > . 93441:94901(1460) ack 1
+.001 > . 94901:96361(1460) ack 1
+.001 > . 96361:97821(1460) ack 1
+.001 > . 97821:99281(1460) ack 1
+.001 > . 99281:100741(1460) ack 1
+.001 > . 100741:102201(1460) ack 1
// Ok lets trigger a bunch of rtx !
+.001 < . 1:1(0) ack 43801 win 1500 <nop,nop, sack 78841:102201>
+.001 > . 43801:45261(1460) ack 1
+.001 > . 45261:46721(1460) ack 1
+.001 > . 46721:48181(1460) ack 1
+.001 > . 48181:49641(1460) ack 1
+.001 > . 49641:51101(1460) ack 1
+.001 > . 51101:52561(1460) ack 1
+.001 > . 52561:54021(1460) ack 1
+.001 > . 54021:55481(1460) ack 1
+.001 > . 55481:56941(1460) ack 1
+.001 > . 56941:58401(1460) ack 1
+.001 > . 58401:59861(1460) ack 1
+.001 > . 59861:61321(1460) ack 1
+.001 > . 61321:62781(1460) ack 1
+.001 > . 62781:64241(1460) ack 1
+.001 > . 64241:65701(1460) ack 1
+.001 > . 65701:67161(1460) ack 1
^ permalink raw reply
* Re: [PATCH 1/2] slab, slub, slob: add slab_flags_t
From: Pekka Enberg @ 2017-10-22 6:40 UTC (permalink / raw)
To: Alexey Dobriyan, akpm
Cc: linux-mm, cl, penberg, rientjes, iamjoonsoo.kim, ecryptfs,
linux-xfs, kasan-dev, netdev
In-Reply-To: <20171021100225.GA22428@avx2>
On 21/10/2017 13.02, Alexey Dobriyan wrote:
> Add sparse-checked slab_flags_t for struct kmem_cache::flags
> (SLAB_POISON, etc).
>
> SLAB is bloated temporarily by switching to "unsigned long",
> but only temporarily.
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Acked-by: Pekka Enberg <penberg@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/2] slab, slub, slob: convert slab_flags_t to 32-bit
From: Pekka Enberg @ 2017-10-22 6:40 UTC (permalink / raw)
To: Alexey Dobriyan, akpm
Cc: linux-mm, cl, penberg, rientjes, iamjoonsoo.kim, ecryptfs,
linux-xfs, kasan-dev, netdev
In-Reply-To: <20171021100635.GA8287@avx2>
On 21/10/2017 13.06, Alexey Dobriyan wrote:
> struct kmem_cache::flags is "unsigned long" which is unnecessary on
> 64-bit as no flags are defined in the higher bits.
>
> Switch the field to 32-bit and save some space on x86_64 until such
> flags appear:
>
> add/remove: 0/0 grow/shrink: 0/107 up/down: 0/-657 (-657)
> function old new delta
> sysfs_slab_add 720 719 -1
> ...
> check_object 699 676 -23
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Acked-by: Pekka Enberg <penberg@kernel.org>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH RFC] Add Microchip KSZ8895 DSA driver
From: Pavel Machek @ 2017-10-22 11:01 UTC (permalink / raw)
To: Tristram.Ha
Cc: Andrew Lunn, Florian Fainelli, muvarov, nathan.leigh.conrad,
vivien.didelot, UNGLinuxDriver, netdev, linux-kernel
In-Reply-To: <1507322033-15222-2-git-send-email-Tristram.Ha@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]
Hi!
> diff --git a/drivers/net/dsa/microchip/Kconfig b/drivers/net/dsa/microchip/Kconfig
> index cb95d3d..b854c4b 100644
> --- a/drivers/net/dsa/microchip/Kconfig
> +++ b/drivers/net/dsa/microchip/Kconfig
> @@ -27,3 +27,20 @@ config MICROCHIP_KSZ8795_SPI_DRIVER
>
> It is required to use the KSZ8795 switch driver as the only access
> is through SPI.
> +
> +menuconfig MICROCHIP_KSZ8895
> + tristate "Microchip KSZ8895 series switch support"
> + depends on NET_DSA
> + select NET_DSA_TAG_KSZ8795
Aha. So this depends not only on "preparation" series, but also on
8795 driver. Surprise!
If you had a git tree with series applied, that would be nice.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [MERGE README] net --> net-next
From: David Miller @ 2017-10-22 12:57 UTC (permalink / raw)
To: netdev; +Cc: daniel, ast, john.fastabend
There were quite a few BPF conflicts during the merge I just did of
'net' into 'net-next'.
In particular, all of the packet pointer branch tests in the verifier
had to be resolved wrt. three different sets of changes.
The off-by-one stuff. The allowance of the 'data_end > ptr + x' form
of packet pointer checks. And finally, the metadata stuff.
I would really appreciate an audit and double check of my merge work
by the interested parties.
Thank you.
^ permalink raw reply
* Re: [net-next] tcp: do tcp_mstamp_refresh before retransmits on TSQ handler
From: Koichiro Den @ 2017-10-22 12:59 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem
In-Reply-To: <1508649690.30291.44.camel@edumazet-glaptop3.roam.corp.google.com>
On Sat, 2017-10-21 at 22:21 -0700, Eric Dumazet wrote:
> On Sun, 2017-10-22 at 13:10 +0900, Koichiro Den wrote:
> > On Sat, 2017-10-21 at 20:52 -0700, Eric Dumazet wrote:
> > > On Sun, 2017-10-22 at 12:38 +0900, Koichiro Den wrote:
> > > > When retransmission on TSQ handler was introduced in the commit
> > > > f9616c35a0d7 ("tcp: implement TSQ for retransmits"), the retransmitted
> > > > skbs' timestamps were updated on the actual transmission. In the later
> > > > commit 385e20706fac ("tcp: use tp->tcp_mstamp in output path"), it stops
> > > > being done so. In the commit, the comment says "We try to refresh
> > > > tp->tcp_mstamp only when necessary", and at present tcp_tsq_handler and
> > > > tcp_v4_mtu_reduced applies to this. About the latter, it's okay since
> > > > it's rare enough.
> > > >
> > > > About the former, even though possible retransmissions on the tasklet
> > > > comes just after the destructor run in NET_RX softirq handling, the time
> > > > between them could be nonnegligibly large to the extent that
> > > > tcp_rack_advance or rto rearming be affected if other (remaining) RX,
> > > > BLOCK and (preceding) TASKLET sofirq handlings are unexpectedly heavy.
> > > >
> > > > So in the same way as tcp_write_timer_handler does, doing
> > > > tcp_mstamp_refresh
> > > > ensures the accuracy of algorithms relying on it.
> > > >
> > > > Signed-off-by: Koichiro Den <den@klaipeden.com>
> > > > ---
> > > > net/ipv4/tcp_output.c | 4 +++-
> > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > Very nice catch, thanks a lot Koichiro.
> > >
> > > This IMO would target net tree, since it is a bug fix.
> > >
> > > Fixes: 385e20706fac ("tcp: use tp->tcp_mstamp in output path")
> >
> > Ok I will submit it to net tree. Thanks!
> > >
> > > Thanks !
> > >
> > > We should have caught that in our regression packetdrill tests...
> >
> > In its "remote" mode testing not relying on tun xmit, I agree it could be
> > caught. If it's better to write, test and attach the script, please let me
> > know.
>
> Packetdrill in the normal (local) mode will do it.
>
> Push fq packet scheduler on tun0, and packets will be held long enough
> in FQ that TSQ will be effective.
Ah yes, I missed it, thank you.
>
> Adding TCP TS support on folloginw packetdrill test should demonstrate
> the issue and if your patch cures it.
Thanks for the demo script. I thought making the issue described in my commit
message obvious with a packetdrill script on its own was a bit difficult without
heavy load on test bed (or intentionally injecting time-consuming code).
IIUC, whether or not TCP TS val reflects a bit later timestamp than its last
reception, which triggered TSQ handler, sounds much better. Though it is still
like "With some probability, one millisecond delay is reflected on TS val, so
the packetdrill test passes. Otherwise we can say that the test fails."
Am I correct? To be honest I am still wondering what is the best way to make the
issue obvious.
> // Test if TSQ applies to retransmits.
>
> `tc qdisc replace dev tun0 root fq quantum 1514 initial_quantum 1514
> flow_limit 5
> sysctl -e -q net.ipv4.tcp_min_tso_segs=1`
>
> 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
> +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> +0 bind(3, ..., ...) = 0
> +0 listen(3, 1) = 0
>
> +0 < S 0:0(0) win 32792 <mss 1460,sackOK,nop,nop,nop,wscale 7>
> +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8>
> +.01 < . 1:1(0) ack 1 win 1500
> +0 accept(3, ..., ...) = 4
>
> +0 %{ assert tcpi_snd_cwnd == 10, tcpi_snd_cwnd }%
> // send one frame per ms
> +0 setsockopt(4, SOL_SOCKET, SO_MAX_PACING_RATE, [1514000], 4) = 0
> +0 setsockopt(4, SOL_SOCKET, SO_SNDBUF, [1000000], 4) = 0
>
> +0 write(4, ..., 120000) = 120000
>
> +0 > . 1:1461(1460) ack 1
> +.001 > . 1461:2921(1460) ack 1
> +.001 > . 2921:4381(1460) ack 1
> +.001 > . 4381:5841(1460) ack 1
> +.001 > . 5841:7301(1460) ack 1
> +.001 > . 7301:8761(1460) ack 1
> +.001 > . 8761:10221(1460) ack 1
> +.001 > . 10221:11681(1460) ack 1
> +.001 > . 11681:13141(1460) ack 1
> +.001 > . 13141:14601(1460) ack 1
> +.01 < . 1:1(0) ack 14601 win 1500
>
> +.001 > . 14601:16061(1460) ack 1
> +.001 > . 16061:17521(1460) ack 1
> +.001 > . 17521:18981(1460) ack 1
> +.001 > . 18981:20441(1460) ack 1
> +.001 > . 20441:21901(1460) ack 1
> +.001 > . 21901:23361(1460) ack 1
> +.001 > . 23361:24821(1460) ack 1
> +.001 > . 24821:26281(1460) ack 1
> +.001 > . 26281:27741(1460) ack 1
> +.001 > . 27741:29201(1460) ack 1
> +.001 > . 29201:30661(1460) ack 1
> +.001 > . 30661:32121(1460) ack 1
> +.001 > . 32121:33581(1460) ack 1
> +.001 > . 33581:35041(1460) ack 1
> +.001 > . 35041:36501(1460) ack 1
> +.001 > . 36501:37961(1460) ack 1
> +.001 > . 37961:39421(1460) ack 1
> +.001 > . 39421:40881(1460) ack 1
> +.001 > . 40881:42341(1460) ack 1
> +.001 > . 42341:43801(1460) ack 1
> +.01 < . 1:1(0) ack 43801 win 1500
>
> +.001 > . 43801:45261(1460) ack 1
> +.001 > . 45261:46721(1460) ack 1
> +.001 > . 46721:48181(1460) ack 1
> +.001 > . 48181:49641(1460) ack 1
> +.001 > . 49641:51101(1460) ack 1
> +.001 > . 51101:52561(1460) ack 1
> +.001 > . 52561:54021(1460) ack 1
> +.001 > . 54021:55481(1460) ack 1
> +.001 > . 55481:56941(1460) ack 1
> +.001 > . 56941:58401(1460) ack 1
> +.001 > . 58401:59861(1460) ack 1
> +.001 > . 59861:61321(1460) ack 1
> +.001 > . 61321:62781(1460) ack 1
> +.001 > . 62781:64241(1460) ack 1
> +.001 > . 64241:65701(1460) ack 1
> +.001 > . 65701:67161(1460) ack 1
> +.001 > . 67161:68621(1460) ack 1
> +.001 > . 68621:70081(1460) ack 1
> +.001 > . 70081:71541(1460) ack 1
> +.001 > . 71541:73001(1460) ack 1
> +.001 > . 73001:74461(1460) ack 1
> +.001 > . 74461:75921(1460) ack 1
> +.001 > . 75921:77381(1460) ack 1
> +.001 > . 77381:78841(1460) ack 1
> +.001 > . 78841:80301(1460) ack 1
> +.001 > . 80301:81761(1460) ack 1
> +.001 > . 81761:83221(1460) ack 1
> +.001 > . 83221:84681(1460) ack 1
> +.001 > . 84681:86141(1460) ack 1
> +.001 > . 86141:87601(1460) ack 1
> +.001 > . 87601:89061(1460) ack 1
> +.001 > . 89061:90521(1460) ack 1
> +.001 > . 90521:91981(1460) ack 1
> +.001 > . 91981:93441(1460) ack 1
> +.001 > . 93441:94901(1460) ack 1
> +.001 > . 94901:96361(1460) ack 1
> +.001 > . 96361:97821(1460) ack 1
> +.001 > . 97821:99281(1460) ack 1
> +.001 > . 99281:100741(1460) ack 1
> +.001 > . 100741:102201(1460) ack 1
>
> // Ok lets trigger a bunch of rtx !
> +.001 < . 1:1(0) ack 43801 win 1500 <nop,nop, sack 78841:102201>
> +.001 > . 43801:45261(1460) ack 1
> +.001 > . 45261:46721(1460) ack 1
> +.001 > . 46721:48181(1460) ack 1
> +.001 > . 48181:49641(1460) ack 1
> +.001 > . 49641:51101(1460) ack 1
> +.001 > . 51101:52561(1460) ack 1
> +.001 > . 52561:54021(1460) ack 1
> +.001 > . 54021:55481(1460) ack 1
> +.001 > . 55481:56941(1460) ack 1
> +.001 > . 56941:58401(1460) ack 1
> +.001 > . 58401:59861(1460) ack 1
> +.001 > . 59861:61321(1460) ack 1
> +.001 > . 61321:62781(1460) ack 1
> +.001 > . 62781:64241(1460) ack 1
> +.001 > . 64241:65701(1460) ack 1
> +.001 > . 65701:67161(1460) ack 1
>
>
>
>
>
^ permalink raw reply
* Re: [MERGE README] net --> net-next
From: Daniel Borkmann @ 2017-10-22 13:09 UTC (permalink / raw)
To: David Miller, netdev; +Cc: ast, john.fastabend
In-Reply-To: <20171022.135717.971703426919688431.davem@davemloft.net>
On 10/22/2017 02:57 PM, David Miller wrote:
>
> There were quite a few BPF conflicts during the merge I just did of
> 'net' into 'net-next'.
>
> In particular, all of the packet pointer branch tests in the verifier
> had to be resolved wrt. three different sets of changes.
>
> The off-by-one stuff. The allowance of the 'data_end > ptr + x' form
> of packet pointer checks. And finally, the metadata stuff.
>
> I would really appreciate an audit and double check of my merge work
> by the interested parties.
I will do a review today in the evening, thanks David!
^ permalink raw reply
* [PATCH] net: ethernet: fsl: don't en/disable refclk on open/close
From: Richard Leitner @ 2017-10-22 13:11 UTC (permalink / raw)
To: fugang.duan; +Cc: netdev, linux-kernel, Richard Leitner, stable
From: Richard Leitner <richard.leitner@skidata.com>
From: Richard Leitner <richard.leitner@skidata.com>
Some PHYs (for example the LAN8710) doesn't allow turning the ethernet
ref clocks off and on again without reset (according to their datasheet).
Exactly this behaviour was introduced for power saving reasons by
commit e8fcfcd5684a ("net: fec: optimize the clock management to save...")
Therefore remove those en/disables of the refclk during probe, open and
close of the fec.
Generally speaking is this issue only be relevant if the ref clk for
the PHY is generated by the SoC. In our specific case (PCB) this problem
does occur at about every 10th to 50th POR of an LAN8710 connected to an
i.MX6 SoC. The typical symptom of this problem is a "swinging" ethernet
link. Similar issues were experienced by users of the NXP forum:
https://community.nxp.com/thread/389902
https://community.nxp.com/message/309354
With this patch applied the issue didn't occur for at least a few
thousand PORs of our board.
Fixes: e8fcfcd5684a ("net: fec: optimize the clock management to sa...")
Cc: stable@vger.kernel.org
Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
---
drivers/net/ethernet/freescale/fec_main.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 3dc2d771a222..8f696b53d8b8 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2844,9 +2844,6 @@ fec_enet_open(struct net_device *ndev)
return ret;
pinctrl_pm_select_default_state(&fep->pdev->dev);
- ret = fec_enet_clk_enable(ndev, true);
- if (ret)
- goto clk_enable;
/* I should reset the ring buffers here, but I don't yet know
* a simple way to do that.
@@ -2879,8 +2876,6 @@ fec_enet_open(struct net_device *ndev)
err_enet_mii_probe:
fec_enet_free_buffers(ndev);
err_enet_alloc:
- fec_enet_clk_enable(ndev, false);
-clk_enable:
pm_runtime_mark_last_busy(&fep->pdev->dev);
pm_runtime_put_autosuspend(&fep->pdev->dev);
pinctrl_pm_select_sleep_state(&fep->pdev->dev);
@@ -2907,7 +2902,6 @@ fec_enet_close(struct net_device *ndev)
fec_enet_update_ethtool_stats(ndev);
- fec_enet_clk_enable(ndev, false);
pinctrl_pm_select_sleep_state(&fep->pdev->dev);
pm_runtime_mark_last_busy(&fep->pdev->dev);
pm_runtime_put_autosuspend(&fep->pdev->dev);
@@ -3495,7 +3489,6 @@ fec_probe(struct platform_device *pdev)
/* Carrier starts down, phylib will bring it up */
netif_carrier_off(ndev);
- fec_enet_clk_enable(ndev, false);
pinctrl_pm_select_sleep_state(&pdev->dev);
ret = register_netdev(ndev);
--
2.11.0
^ permalink raw reply related
* Re: Linux 4.12+ memory leak on router with i40e NICs
From: Anders K. Pedersen | Cohaesio @ 2017-10-22 13:56 UTC (permalink / raw)
To: alexander.duyck@gmail.com
Cc: pstaszewski@itcare.pl, netdev@vger.kernel.org,
pavlos.parissis@gmail.com, intel-wired-lan@lists.osuosl.org,
alexander.h.duyck@intel.com
In-Reply-To: <CAKgT0Ud1ftJ187qz_XBVnx+X_1BQTgWWe4sA307_3VmpMSSVaw@mail.gmail.com>
On tor, 2017-10-19 at 08:40 -0700, Alexander Duyck wrote:
> On Thu, Oct 19, 2017 at 5:19 AM, Anders K. Pedersen | Cohaesio
> <akp@cohaesio.com> wrote:
> > Hi Alex,
> >
> > On ons, 2017-10-18 at 16:37 -0700, Alexander Duyck wrote:
> > > When we last talked I had asked if you could do a git bisect to
> > > find
> > > the memory leak and you said you would look into it. The most
> > > useful
> > > way to solve this would be to do a git bisect between your
> > > current
> > > kernel and the 4.11 kernel to find the point at which this
> > > started.
> > > If
> > > we can do that then fixing this becomes much simpler as we just
> > > have
> > > to fix the patch that introduced the issue.
> >
> > We're also seeing a smaller memory leak (about 1 GB per day) than
> > the
> > original one even with the "Fix memory leak related filter
> > programming
> > status" fix applied. So far I've determined that the leak is
> > present on
> > 4.13.7 and was introduced between 4.11 and 4.12, so I'll do another
> > round of bisection to identify the patch that introduced this.
> >
> > Since the router must run for a couple of hours before I can be
> > sure
> > whether a kernel is good or bad, and I can't reboot it during
> > working
> > hours, it'll probably be about a week before I have a result.
> >
> > --
> > Venlig hilsen / Best Regards
> >
> > Anders K. Pedersen
> > Senior Technical Manager
>
> Anders,
>
> I'll do some digging on my side to see if I can find any other memory
> leaks that might be floating around in the driver that could have
> been
> introduced during that time-frame.
>
> One thing you might try that would help with your testing would be to
> just disable the ATR functionality in i40e. You can do that with the
> ethtool command "ethtool --set-priv-flags <iface> flow-director-atr
> off". That should allow you to bisect this without needing to deal
> with the "programming status" patches since you won't be programming
> ATR filters which is what caused that leak.
>
> Thanks for looking into this.
>
> - Alex
Hi Alex,
I began bisecting, where I applied the known fix patches to the steps,
where they were applicable (i.e. without changing the flow-director-atr
flag), but some of the steps had a high amount of packet drops, which
caused problems for our network, so I couldn't leave them running for
several hours, which is necessary to determine if the leak is present
or not. The part of the bisection I got through had the same outcome as
the last bisection, which led to "i40e: Fix support for flow
director programming status".
After that I experimented a bit with the flow-director-atr flag, and it
turns out that if I disable this flag on all the NICs, then the memory
leak is gone, so I suspected that the smaller memory leak was also
caused by "i40e: Fix support for flow director programming status".
I tried to revert this patch from 4.13 (with manual fixup for the trace
point that had been added later), but that brought back the packet
drops, so I couldn't let it run.
This morning I saw your "i40e: Add programming descriptors to
cleaned_count" patch, so I tried 4.13.9 with that patch and the
previous "i40e: Fix memory leak related filter programming status"
without turning off the flow-director-atr flag. So far this combination
is running stable without any memory leaks.
Thanks for fixing this.
Regards,
Anders
^ permalink raw reply
* [PATCH iproute2 1/1] tc/actions: introduce support for jump action
From: Jamal Hadi Salim @ 2017-10-22 14:48 UTC (permalink / raw)
To: stephen; +Cc: netdev, jiri, xiyou.wangcong, Jamal Hadi Salim
From: Jamal Hadi Salim <jhs@mojatatu.com>
Seems like my old patches didnt make it into the tree - so here goes
Sample use case:
... add ingress qdisc
sudo $TC qdisc add dev $ETH ingress
... if we exceed rate of 1kbps (burst of 90K), do an absolute jump of 2 actions
sudo $TC actions add action police rate 1kbit burst 90k conform-exceed jump 2 / pipe
sudo $TC -s actions ls action police
---
action order 0: police 0x4 rate 1Kbit burst 23440b mtu 2Kb action jump 2/pipe overhead 0b
ref 1 bind 0 installed 41 sec used 41 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
--
... lets add a couple of marks so we can use them to mark exceed/not exceed
sudo $TC actions add action skbedit mark 11 ok index 11
sudo $TC actions add action skbedit mark 12 ok index 12
... if we dont exceed our rate we get a mark of 11, else mark of 12
sudo $TC filter add dev $ETH parent ffff: protocol ip prio 8 u32 \
match ip dst 127.0.0.8/32 flowid 1:10 \
action police index 4 \
action skbedit index 11 \
action skbedit index 12
Ok, lets keep this thing a little busy..
sudo ping -f -c 10000 127.0.0.8
... now lets see the filters..
sudo $TC -s filter ls dev $ETH parent ffff: protocol ip
----
filter pref 8 u32 chain 0
filter pref 8 u32 chain 0 fh 800: ht divisor 1
filter pref 8 u32 chain 0 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 not_in_hw (rule hit 20000 success 10000)
match 7f000008/ffffffff at 16 (success 10000 )
action order 1: police 0x4 rate 1Kbit burst 23440b mtu 2Kb action jump 2/pipe overhead 0b
ref 2 bind 1 installed 198 sec used 2 sec
Action statistics:
Sent 840000 bytes 10000 pkt (dropped 0, overlimits 9721 requeues 0)
backlog 0b 0p requeues 0
action order 2: skbedit mark 11 pass
index 11 ref 2 bind 1 installed 127 sec used 2 sec
Action statistics:
Sent 23436 bytes 279 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
action order 3: skbedit mark 12 pass
index 12 ref 2 bind 1 installed 127 sec used 2 sec
Action statistics:
Sent 816564 bytes 9721 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
-----
As can be seen 97.21% of the packets were marked as exceeding the allocated
rate; you could do something clever with the skb mark after this.
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
---
tc/m_gact.c | 6 ++++--
tc/tc_util.c | 16 ++++++++++++++++
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/tc/m_gact.c b/tc/m_gact.c
index df143c9..38949e9 100644
--- a/tc/m_gact.c
+++ b/tc/m_gact.c
@@ -46,18 +46,20 @@ explain(void)
fprintf(stderr, "Usage: ... gact <ACTION> [RAND] [INDEX]\n");
fprintf(stderr,
"Where: \tACTION := reclassify | drop | continue | pass | pipe |\n"
- " \t goto chain <CHAIN_INDEX>\n"
+ " \t goto chain <CHAIN_INDEX> | jump <JUMP_COUNT>\n"
"\tRAND := random <RANDTYPE> <ACTION> <VAL>\n"
"\tRANDTYPE := netrand | determ\n"
"\tVAL : = value not exceeding 10000\n"
+ "\tJUMP_COUNT := Absolute jump from start of action list\n"
"\tINDEX := index value used\n"
"\n");
#else
fprintf(stderr, "Usage: ... gact <ACTION> [INDEX]\n");
fprintf(stderr,
"Where: \tACTION := reclassify | drop | continue | pass | pipe |\n"
- " \t goto chain <CHAIN_INDEX>\n"
+ " \t goto chain <CHAIN_INDEX> | jump <JUMP_COUNT>\n"
"\tINDEX := index value used\n"
+ "\tJUMP_COUNT := Absolute jump from start of action list\n"
"\n");
#endif
}
diff --git a/tc/tc_util.c b/tc/tc_util.c
index 50d3550..b39e550 100644
--- a/tc/tc_util.c
+++ b/tc/tc_util.c
@@ -417,6 +417,8 @@ static const char *action_n2a(int action)
if (TC_ACT_EXT_CMP(action, TC_ACT_GOTO_CHAIN))
return "goto";
+ if (TC_ACT_EXT_CMP(action, TC_ACT_JUMP))
+ return "jump";
switch (action) {
case TC_ACT_UNSPEC:
return "continue";
@@ -463,6 +465,7 @@ static int action_a2n(char *arg, int *result, bool allow_num)
{"reclassify", TC_ACT_RECLASSIFY},
{"pipe", TC_ACT_PIPE},
{"goto", TC_ACT_GOTO_CHAIN},
+ {"jump", TC_ACT_JUMP},
{"trap", TC_ACT_TRAP},
{ NULL },
}, *iter;
@@ -510,6 +513,17 @@ static int __parse_action_control(int *argc_p, char ***argv_p, int *result_p,
}
result |= chain_index;
}
+ if (result == TC_ACT_JUMP) {
+ __u32 jump_cnt = 0;
+
+ NEXT_ARG();
+ if (get_u32(&jump_cnt, *argv, 10) ||
+ jump_cnt > TC_ACT_EXT_VAL_MASK) {
+ fprintf(stderr, "Invalid \"jump count\" (%s)\n", *argv);
+ return -1;
+ }
+ result |= jump_cnt;
+ }
NEXT_ARG_FWD();
*argc_p = argc;
*argv_p = argv;
@@ -637,6 +651,8 @@ void print_action_control(FILE *f, const char *prefix,
fprintf(f, "%s%s", prefix, action_n2a(action));
if (TC_ACT_EXT_CMP(action, TC_ACT_GOTO_CHAIN))
fprintf(f, " chain %u", action & TC_ACT_EXT_VAL_MASK);
+ if (TC_ACT_EXT_CMP(action, TC_ACT_JUMP))
+ fprintf(f, " %u", action & TC_ACT_EXT_VAL_MASK);
fprintf(f, "%s", suffix);
}
--
1.9.1
^ permalink raw reply related
* Fwd: bug report: iproute2 policer parsing broken
From: Jamal Hadi Salim @ 2017-10-22 15:17 UTC (permalink / raw)
To: netdev@vger.kernel.org, Phil Sutter, Stephen Hemminger,
Jiri Pirko
Cc: Lucas Bates
In-Reply-To: <6c0937de-c8a2-c25f-4fbf-545ba2ea5abd@mojatatu.com>
forgot to cc netdev...
cheers,
jamal
-------- Forwarded Message --------
Subject: bug report: iproute2 policer parsing broken
Date: Sun, 22 Oct 2017 10:59:07 -0400
From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Phil Sutter <phil@nwl.cc>, Stephen Hemminger
<stephen@networkplumber.org>, Jiri Pirko <jiri@resnulli.us>
CC: Lucas Bates <lucasb@mojatatu.com>
It seems policer parsing with conform-exceed is broken.
I have verified this with a few actions.
git bisect indicates things were working before refactoring
into tc-utils.c - Unfortunately I dont have time to dig.
There seem to be two issues:
1) Has to do with whether you have space before or after "/"
#doesnt work
sudo $TC actions add action police rate 1kbit burst 90k \
conform-exceed A /B
#doesnt work
sudo $TC actions add action police rate 1kbit burst 90k \
conform-exceed A/B
#doesnt work
sudo $TC actions add action police rate 1kbit burst 90k \
conform-exceed A/ B
#works
sudo $TC actions add action police rate 1kbit burst 90k \
conform-exceed A / B
I tried a few actions but focussed on the "goto chain" and
"jump" actions.
2) specifying and index with "goto chain" but maybe consistent
across other actions
#works
sudo $TC actions add action police rate 1kbit burst 90k conform-exceed
pipe / goto chain 111
#doesnt work
sudo $TC actions add action police rate 1kbit burst 90k conform-exceed
pipe / goto chain 111 index 111
I may be able to get to it around netdev2.2 time if nobody else does.
cheers,
jamal
^ permalink raw reply
* Re: [net-next] tcp: do tcp_mstamp_refresh before retransmits on TSQ handler
From: Eric Dumazet @ 2017-10-22 16:49 UTC (permalink / raw)
To: Koichiro Den; +Cc: netdev, davem, ncardwell
In-Reply-To: <1508677159.3011.1.camel@klaipeden.com>
On Sun, 2017-10-22 at 21:59 +0900, Koichiro Den wrote:
> On Sat, 2017-10-21 at 22:21 -0700, Eric Dumazet wrote:
> > On Sun, 2017-10-22 at 13:10 +0900, Koichiro Den wrote:
> > > On Sat, 2017-10-21 at 20:52 -0700, Eric Dumazet wrote:
> > > > On Sun, 2017-10-22 at 12:38 +0900, Koichiro Den wrote:
> > > > > When retransmission on TSQ handler was introduced in the commit
> > > > > f9616c35a0d7 ("tcp: implement TSQ for retransmits"), the retransmitted
> > > > > skbs' timestamps were updated on the actual transmission. In the later
> > > > > commit 385e20706fac ("tcp: use tp->tcp_mstamp in output path"), it stops
> > > > > being done so. In the commit, the comment says "We try to refresh
> > > > > tp->tcp_mstamp only when necessary", and at present tcp_tsq_handler and
> > > > > tcp_v4_mtu_reduced applies to this. About the latter, it's okay since
> > > > > it's rare enough.
> > > > >
> > > > > About the former, even though possible retransmissions on the tasklet
> > > > > comes just after the destructor run in NET_RX softirq handling, the time
> > > > > between them could be nonnegligibly large to the extent that
> > > > > tcp_rack_advance or rto rearming be affected if other (remaining) RX,
> > > > > BLOCK and (preceding) TASKLET sofirq handlings are unexpectedly heavy.
> > > > >
> > > > > So in the same way as tcp_write_timer_handler does, doing
> > > > > tcp_mstamp_refresh
> > > > > ensures the accuracy of algorithms relying on it.
> > > > >
> > > > > Signed-off-by: Koichiro Den <den@klaipeden.com>
> > > > > ---
> > > > > net/ipv4/tcp_output.c | 4 +++-
> > > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > Very nice catch, thanks a lot Koichiro.
> > > >
> > > > This IMO would target net tree, since it is a bug fix.
> > > >
> > > > Fixes: 385e20706fac ("tcp: use tp->tcp_mstamp in output path")
> > >
> > > Ok I will submit it to net tree. Thanks!
> > > >
> > > > Thanks !
> > > >
> > > > We should have caught that in our regression packetdrill tests...
> > >
> > > In its "remote" mode testing not relying on tun xmit, I agree it could be
> > > caught. If it's better to write, test and attach the script, please let me
> > > know.
> >
> > Packetdrill in the normal (local) mode will do it.
> >
> > Push fq packet scheduler on tun0, and packets will be held long enough
> > in FQ that TSQ will be effective.
> Ah yes, I missed it, thank you.
> >
> > Adding TCP TS support on folloginw packetdrill test should demonstrate
> > the issue and if your patch cures it.
> Thanks for the demo script. I thought making the issue described in my commit
> message obvious with a packetdrill script on its own was a bit difficult without
> heavy load on test bed (or intentionally injecting time-consuming code).
>
> IIUC, whether or not TCP TS val reflects a bit later timestamp than its last
> reception, which triggered TSQ handler, sounds much better. Though it is still
> like "With some probability, one millisecond delay is reflected on TS val, so
> the packetdrill test passes. Otherwise we can say that the test fails."
> Am I correct? To be honest I am still wondering what is the best way to make the
> issue obvious.
Here is the test I cooked.
Note that it actually passes just fine, do I am wondering if your patch
is needed after all..
# cat fq-pacing-tsq-rtx-ts.pkt
// Test if TSQ applies to retransmits.
`tc qdisc replace dev tun0 root fq quantum 1514 initial_quantum 1514 flow_limit 5
sysctl -e -q net.ipv4.tcp_min_tso_segs=1`
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
+0 < S 0:0(0) win 65535 <mss 1460,sackOK,TS val 190 ecr 0>
+0 > S. 0:0(0) ack 1 <mss 1460,sackOK,TS val 5000 ecr 190>
+.01 < . 1:1(0) ack 1 win 65535 <nop,nop,TS val 200 ecr 5000>
+0 accept(3, ..., ...) = 4
+0 %{ assert tcpi_snd_cwnd == 10, tcpi_snd_cwnd }%
// send one frame per ms
+0 setsockopt(4, SOL_SOCKET, SO_MAX_PACING_RATE, [1514000], 4) = 0
+0 setsockopt(4, SOL_SOCKET, SO_SNDBUF, [1000000], 4) = 0
+0 write(4, ..., 120000) = 120000
+.000 > . 1:1449(1448) ack 1 <nop, nop, TS val 400 ecr 200>
+.001 > . 1449:2897(1448) ack 1 <nop, nop, TS val 401 ecr 200>
+.001 > . 2897:4345(1448) ack 1 <nop, nop, TS val 402 ecr 200>
+.001 > . 4345:5793(1448) ack 1 <nop, nop, TS val 403 ecr 200>
+.001 > . 5793:7241(1448) ack 1 <nop, nop, TS val 404 ecr 200>
+.001 > . 7241:8689(1448) ack 1 <nop, nop, TS val 405 ecr 200>
+.001 > . 8689:10137(1448) ack 1 <nop, nop, TS val 406 ecr 200>
+.001 > . 10137:11585(1448) ack 1 <nop, nop, TS val 407 ecr 200>
+.001 > . 11585:13033(1448) ack 1 <nop, nop, TS val 408 ecr 200>
+.001 > . 13033:14481(1448) ack 1 <nop, nop, TS val 409 ecr 200>
+.01 < . 1:1(0) ack 14481 win 65535 <nop, nop, TS val 220 ecr 409>
+.000 > . 14481:15929(1448) ack 1 <nop, nop, TS val 420 ecr 220>
+.001 > . 15929:17377(1448) ack 1 <nop, nop, TS val 421 ecr 220>
+.001 > . 17377:18825(1448) ack 1 <nop, nop, TS val 422 ecr 220>
+.001 > . 18825:20273(1448) ack 1 <nop, nop, TS val 423 ecr 220>
+.001 > . 20273:21721(1448) ack 1 <nop, nop, TS val 424 ecr 220>
+.001 > . 21721:23169(1448) ack 1 <nop, nop, TS val 425 ecr 220>
+.001 > . 23169:24617(1448) ack 1 <nop, nop, TS val 426 ecr 220>
+.001 > . 24617:26065(1448) ack 1 <nop, nop, TS val 427 ecr 220>
+.001 > . 26065:27513(1448) ack 1 <nop, nop, TS val 428 ecr 220>
+.001 > . 27513:28961(1448) ack 1 <nop, nop, TS val 429 ecr 220>
+.001 > . 28961:30409(1448) ack 1 <nop, nop, TS val 430 ecr 220>
+.001 > . 30409:31857(1448) ack 1 <nop, nop, TS val 431 ecr 220>
+.001 > . 31857:33305(1448) ack 1 <nop, nop, TS val 432 ecr 220>
+.001 > . 33305:34753(1448) ack 1 <nop, nop, TS val 433 ecr 220>
+.001 > . 34753:36201(1448) ack 1 <nop, nop, TS val 434 ecr 220>
+.001 > . 36201:37649(1448) ack 1 <nop, nop, TS val 435 ecr 220>
+.001 > P. 37649:39097(1448) ack 1 <nop, nop, TS val 436 ecr 220>
+.001 > . 39097:40545(1448) ack 1 <nop, nop, TS val 437 ecr 220>
+.001 > . 40545:41993(1448) ack 1 <nop, nop, TS val 438 ecr 220>
+.001 > . 41993:43441(1448) ack 1 <nop, nop, TS val 439 ecr 220>
+.01 < . 1:1(0) ack 43441 win 65535 <nop, nop, TS val 240 ecr 439>
+.000 > . 43441:44889(1448) ack 1 <nop, nop, TS val 450 ecr 240>
+.001 > . 44889:46337(1448) ack 1 <nop, nop, TS val 451 ecr 240>
+.001 > . 46337:47785(1448) ack 1 <nop, nop, TS val 452 ecr 240>
+.001 > . 47785:49233(1448) ack 1 <nop, nop, TS val 453 ecr 240>
+.001 > . 49233:50681(1448) ack 1 <nop, nop, TS val 454 ecr 240>
+.001 > . 50681:52129(1448) ack 1 <nop, nop, TS val 455 ecr 240>
+.001 > . 52129:53577(1448) ack 1 <nop, nop, TS val 456 ecr 240>
+.001 > . 53577:55025(1448) ack 1 <nop, nop, TS val 457 ecr 240>
+.001 > . 55025:56473(1448) ack 1 <nop, nop, TS val 458 ecr 240>
+.001 > . 56473:57921(1448) ack 1 <nop, nop, TS val 459 ecr 240>
+.001 > . 57921:59369(1448) ack 1 <nop, nop, TS val 460 ecr 240>
+.001 > . 59369:60817(1448) ack 1 <nop, nop, TS val 461 ecr 240>
+.001 > . 60817:62265(1448) ack 1 <nop, nop, TS val 462 ecr 240>
+.001 > . 62265:63713(1448) ack 1 <nop, nop, TS val 463 ecr 240>
+.001 > . 63713:65161(1448) ack 1 <nop, nop, TS val 464 ecr 240>
+.001 > . 65161:66609(1448) ack 1 <nop, nop, TS val 465 ecr 240>
+.001 > . 66609:68057(1448) ack 1 <nop, nop, TS val 466 ecr 240>
+.001 > . 68057:69505(1448) ack 1 <nop, nop, TS val 467 ecr 240>
+.001 > P. 69505:70953(1448) ack 1 <nop, nop, TS val 468 ecr 240>
+.001 > . 70953:72401(1448) ack 1 <nop, nop, TS val 469 ecr 240>
+.001 > . 72401:73849(1448) ack 1 <nop, nop, TS val 470 ecr 240>
+.001 > . 73849:75297(1448) ack 1 <nop, nop, TS val 471 ecr 240>
+.001 > . 75297:76745(1448) ack 1 <nop, nop, TS val 472 ecr 240>
+.001 > . 76745:78193(1448) ack 1 <nop, nop, TS val 473 ecr 240>
+.001 > . 78193:79641(1448) ack 1 <nop, nop, TS val 474 ecr 240>
+.001 > . 79641:81089(1448) ack 1 <nop, nop, TS val 475 ecr 240>
+.001 > . 81089:82537(1448) ack 1 <nop, nop, TS val 476 ecr 240>
+.001 > . 82537:83985(1448) ack 1 <nop, nop, TS val 477 ecr 240>
+.001 > . 83985:85433(1448) ack 1 <nop, nop, TS val 478 ecr 240>
+.001 > . 85433:86881(1448) ack 1 <nop, nop, TS val 479 ecr 240>
+.001 > . 86881:88329(1448) ack 1 <nop, nop, TS val 480 ecr 240>
+.001 > . 88329:89777(1448) ack 1 <nop, nop, TS val 481 ecr 240>
+.001 > . 89777:91225(1448) ack 1 <nop, nop, TS val 482 ecr 240>
+.001 > . 91225:92673(1448) ack 1 <nop, nop, TS val 483 ecr 240>
+.001 > . 92673:94121(1448) ack 1 <nop, nop, TS val 484 ecr 240>
+.001 > . 94121:95569(1448) ack 1 <nop, nop, TS val 485 ecr 240>
+.001 > . 95569:97017(1448) ack 1 <nop, nop, TS val 486 ecr 240>
+.001 > . 97017:98465(1448) ack 1 <nop, nop, TS val 487 ecr 240>
+.001 > . 98465:99913(1448) ack 1 <nop, nop, TS val 488 ecr 240>
+.001 > . 99913:101361(1448) ack 1 <nop, nop, TS val 489 ecr 240>
// Ok lets trigger a bunch of rtx !
+.001 < . 1:1(0) ack 43441 win 65535 <nop,nop, TS val 280 ecr 489, nop, nop, sack 78841:101361>
+.000 > . 43441:44889(1448) ack 1 <nop, nop, TS val 500 ecr 280>
+.001 > . 44889:46337(1448) ack 1 <nop, nop, TS val 501 ecr 280>
+.001 > . 46337:47785(1448) ack 1 <nop, nop, TS val 502 ecr 280>
+.001 > . 47785:49233(1448) ack 1 <nop, nop, TS val 503 ecr 280>
+.001 > . 49233:50681(1448) ack 1 <nop, nop, TS val 504 ecr 280>
+.001 > . 50681:52129(1448) ack 1 <nop, nop, TS val 505 ecr 280>
+.001 > . 52129:53577(1448) ack 1 <nop, nop, TS val 506 ecr 280>
+.001 > . 53577:55025(1448) ack 1 <nop, nop, TS val 507 ecr 280>
+.001 > . 55025:56473(1448) ack 1 <nop, nop, TS val 508 ecr 280>
+.001 > . 56473:57921(1448) ack 1 <nop, nop, TS val 509 ecr 280>
+.001 > . 57921:59369(1448) ack 1 <nop, nop, TS val 510 ecr 280>
+.001 > . 59369:60817(1448) ack 1 <nop, nop, TS val 511 ecr 280>
+.001 > . 60817:62265(1448) ack 1 <nop, nop, TS val 512 ecr 280>
+.001 > . 62265:63713(1448) ack 1 <nop, nop, TS val 513 ecr 280>
+.001 > . 63713:65161(1448) ack 1 <nop, nop, TS val 514 ecr 280>
A "tcpdump -p -n -s 0 -i any port 8080" while packetdrill runs, shows for the RTX phase :
09:43:46.008860 IP 192.0.2.1.33257 > 192.168.105.33.8080: Flags [.], ack 43441, win 65535, options [nop,nop,TS val 280 ecr 895244774,nop,nop,sack 1 {78841:101361}], length 0
09:43:46.008882 IP 192.168.105.33.8080 > 192.0.2.1.33257: Flags [.], seq 43441:44889, ack 1, win 28960, options [nop,nop,TS val 895244777 ecr 280], length 1448: HTTP
09:43:46.009832 IP 192.168.105.33.8080 > 192.0.2.1.33257: Flags [.], seq 44889:46337, ack 1, win 28960, options [nop,nop,TS val 895244777 ecr 280], length 1448: HTTP
09:43:46.010831 IP 192.168.105.33.8080 > 192.0.2.1.33257: Flags [.], seq 46337:47785, ack 1, win 28960, options [nop,nop,TS val 895244777 ecr 280], length 1448: HTTP
09:43:46.011832 IP 192.168.105.33.8080 > 192.0.2.1.33257: Flags [.], seq 47785:49233, ack 1, win 28960, options [nop,nop,TS val 895244777 ecr 280], length 1448: HTTP
09:43:46.012831 IP 192.168.105.33.8080 > 192.0.2.1.33257: Flags [.], seq 49233:50681, ack 1, win 28960, options [nop,nop,TS val 895244777 ecr 280], length 1448: HTTP
09:43:46.013832 IP 192.168.105.33.8080 > 192.0.2.1.33257: Flags [.], seq 50681:52129, ack 1, win 28960, options [nop,nop,TS val 895244777 ecr 280], length 1448: HTTP
09:43:46.014832 IP 192.168.105.33.8080 > 192.0.2.1.33257: Flags [.], seq 52129:53577, ack 1, win 28960, options [nop,nop,TS val 895244778 ecr 280], length 1448: HTTP
09:43:46.015831 IP 192.168.105.33.8080 > 192.0.2.1.33257: Flags [.], seq 53577:55025, ack 1, win 28960, options [nop,nop,TS val 895244779 ecr 280], length 1448: HTTP
09:43:46.016831 IP 192.168.105.33.8080 > 192.0.2.1.33257: Flags [.], seq 55025:56473, ack 1, win 28960, options [nop,nop,TS val 895244780 ecr 280], length 1448: HTTP
09:43:46.017831 IP 192.168.105.33.8080 > 192.0.2.1.33257: Flags [.], seq 56473:57921, ack 1, win 28960, options [nop,nop,TS val 895244781 ecr 280], length 1448: HTTP
09:43:46.018831 IP 192.168.105.33.8080 > 192.0.2.1.33257: Flags [.], seq 57921:59369, ack 1, win 28960, options [nop,nop,TS val 895244782 ecr 280], length 1448: HTTP
09:43:46.019832 IP 192.168.105.33.8080 > 192.0.2.1.33257: Flags [.], seq 59369:60817, ack 1, win 28960, options [nop,nop,TS val 895244783 ecr 280], length 1448: HTTP
09:43:46.020831 IP 192.168.105.33.8080 > 192.0.2.1.33257: Flags [.], seq 60817:62265, ack 1, win 28960, options [nop,nop,TS val 895244784 ecr 280], length 1448: HTTP
09:43:46.021831 IP 192.168.105.33.8080 > 192.0.2.1.33257: Flags [.], seq 62265:63713, ack 1, win 28960, options [nop,nop,TS val 895244785 ecr 280], length 1448: HTTP
09:43:46.022831 IP 192.168.105.33.8080 > 192.0.2.1.33257: Flags [.], seq 63713:65161, ack 1, win 28960, options [nop,nop,TS val 895244786 ecr 280], length 1448: HTTP
We do see the TS val being properly incremented (after the initial burst to hit TSQ limit)
^ 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