* Re: [PATCH net 1/1] MAINTAINERS: Update cavium networking drivers
From: David Miller @ 2019-01-25 6:31 UTC (permalink / raw)
To: sudarsana.kalluru; +Cc: netdev, Ameen.Rahman
In-Reply-To: <20190124020320.31400-1-sudarsana.kalluru@cavium.com>
From: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
Date: Wed, 23 Jan 2019 18:03:20 -0800
> Following Marvell's acquisition of Cavium, we need to update all the
> Cavium drivers maintainer's entries to point to our new e-mail addresses.
>
> Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
> Signed-off-by: Ameen Rahman <Ameen.Rahman@cavium.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/2] tcp_bbr: Improving TCP BBR performance for WiFi and cellular networks
From: David Miller @ 2019-01-25 6:27 UTC (permalink / raw)
To: priyarjha; +Cc: netdev
In-Reply-To: <20190123200454.260121-1-priyarjha@google.com>
From: Priyaranjan Jha <priyarjha@google.com>
Date: Wed, 23 Jan 2019 12:04:52 -0800
> Ack aggregation is quite prevalent with wifi, cellular and cable modem
> link tchnologies, ACK decimation in middleboxes, and common offloading
> techniques such as TSO and GRO, at end hosts. Previously, BBR was often
> cwnd-limited in the presence of severe ACK aggregation, which resulted in
> low throughput due to insufficient data in flight.
>
> To achieve good throughput for wifi and other paths with aggregation, this
> patch series implements an ACK aggregation estimator for BBR, which
> estimates the maximum recent degree of ACK aggregation and adapts cwnd
> based on it. The algorithm is further described by the following
> presentation:
> https://datatracker.ietf.org/meeting/101/materials/slides-101-iccrg-an-update-on-bbr-work-at-google-00
>
> (1) A preparatory patch, which refactors bbr_target_cwnd for generic
> inflight provisioning.
>
> (2) Implements BBR ack aggregation estimator and adapts cwnd based
> on measured degree of ACK aggregation.
Looks great.
Series applied, thanks!
^ permalink raw reply
* Re: [PATCH net-next] r8169: factor out PHY init sequence adjusting 10M and ALDPS
From: David Miller @ 2019-01-25 6:26 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <f7fe696e-2485-755a-468b-da1c91b991d3@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Wed, 23 Jan 2019 20:47:30 +0100
> Few chip versions use the same sequence to adjust 10M and ALDPS, so
> let's factor it out. This patch also fixes a (most likely) typo in
> rtl8168g_1_hw_phy_config. There bit 8 in reg 0x14 on page 0x0bcc
> was set and not cleared. According to the vendor driver this bit
> needs to be cleared in all cases.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] r8169: factor out disabling ALDPS
From: David Miller @ 2019-01-25 6:26 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <53a6b46d-e58c-9b22-9324-dbe73e7a9f08@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Wed, 23 Jan 2019 20:39:09 +0100
> Chip versions from RTL8168g onward use the same sequence to disable
> ALDPS (Advanced Link-Down Power Saving). So let's factor this out.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [GIT PULL] Hyper-V hv_netvsc commits for 5.0
From: David Miller @ 2019-01-25 6:22 UTC (permalink / raw)
To: sashal; +Cc: linux-kernel, kys, haiyangz, sthemmin, linux-kernel, netdev
In-Reply-To: <20190123183030.9CFEE21872@mail.kernel.org>
From: Sasha Levin <sashal@kernel.org>
Date: Wed, 23 Jan 2019 13:30:29 -0500
> Three patches from Haiyang Zhang to fix settings hash key using ethtool,
> and Adrian Vladu's first patch fixing a few spelling mistakes.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH bpf-next v3 12/16] ppc: bpf: implement jitting of JMP32
From: Sandipan Das @ 2019-01-25 6:22 UTC (permalink / raw)
To: Jiong Wang; +Cc: ast, daniel, netdev, oss-drivers, Naveen N . Rao
In-Reply-To: <1548375028-8308-13-git-send-email-jiong.wang@netronome.com>
Hi Jiong,
On 25/01/19 5:40 AM, Jiong Wang wrote:
> This patch implements code-gen for new JMP32 instructions on ppc.
>
> For JMP32 | JSET, instruction encoding for PPC_RLWINM_DOT is added to check
> the result of ANDing low 32-bit of operands.
>
> Cc: Naveen N. Rao <naveen.n.rao@linux.ibm.com>
> Cc: Sandipan Das <sandipan@linux.ibm.com>
> Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
> ---
> arch/powerpc/include/asm/ppc-opcode.h | 1 +
> arch/powerpc/net/bpf_jit.h | 4 ++
> arch/powerpc/net/bpf_jit_comp64.c | 120 ++++++++++++++++++++++++++++++----
> 3 files changed, 111 insertions(+), 14 deletions(-)
>
> [...]
Looks good to me.
Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
--
With Regards,
Sandipan
^ permalink raw reply
* Re: [PATCH net-next] bonding: count master 3ad stats separately
From: David Miller @ 2019-01-25 6:20 UTC (permalink / raw)
To: nikolay; +Cc: netdev, j.vosburgh, roopa, vfalico, andy
In-Reply-To: <20190123171450.5062-1-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Wed, 23 Jan 2019 19:14:50 +0200
> I made a dumb mistake when I summed up the slave stats, obviously slaves
> can come and go which would make the master stats unreliable.
> Count and export the master stats separately.
>
> Fixes: a258aeacd7f0 ("bonding: add support for xstats and export 3ad stats")
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Applied, thanks Nikolay.
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] net: phy: improve starting PHY
From: David Miller @ 2019-01-25 6:19 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev, Shyam-sundar.S-k
In-Reply-To: <bddac7b8-a4be-196e-f75e-32a2f44d8807@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Wed, 23 Jan 2019 07:25:38 +0100
> This patch series improves few aspects of starting the PHY.
>
> v2:
> - improve a warning in patch 4
> v3:
> - extend commit message for patch 2
Series applied, thanks Heiner.
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: Fix return value check in qcom_ethqos_probe()
From: David Miller @ 2019-01-25 6:13 UTC (permalink / raw)
To: weiyongjun1
Cc: vkoul, niklas.cassel, peppe.cavallaro, alexandre.torgue, joabreu,
mcoquelin.stm32, netdev, linux-stm32, linux-arm-kernel,
kernel-janitors
In-Reply-To: <1548224358-83281-1-git-send-email-weiyongjun1@huawei.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Wed, 23 Jan 2019 06:19:18 +0000
> In case of error, the function devm_clk_get() returns ERR_PTR() and
> never returns NULL. The NULL test in the return value check should be
> replaced with IS_ERR().
>
> Fixes: a7c30e62d4b8 ("net: stmmac: Add driver for Qualcomm ethqos")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/7] Devlink health updates
From: David Miller @ 2019-01-25 6:08 UTC (permalink / raw)
To: jiri; +Cc: eranbe, netdev, jiri, saeedm, moshe
In-Reply-To: <20190122165821.GC2121@nanopsycho>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 22 Jan 2019 17:58:21 +0100
> Tue, Jan 22, 2019 at 04:57:17PM CET, eranbe@mellanox.com wrote:
>>This patchset fixes some comments that were received for the devlink
>>health series, mostly around the devlink health buffers API.
>>
>>It offers a new devlink<->driver API for passing health dump and diagnose info.
>>As part of this patchset, the new API is developed and integrated into the
>>devlink health and mlx5e TX reporter.
>>Also, added some helpers together with the new API, which reduce the code
>>required by the driver to fill dump and diagnose significantly.
>>
>>Eventually, it also deletes the old API.
>>
>>In addition, it includes some small fixes in the devlink and mlx5e TX reporter.
>
> Okay, just leaving, going to review this tomorrow. I would much rather
> review the patchset from the beginning, not this incremental patchset.
> It changes a lot of things, deprecating api what was just introduced.
> Review nightmare :/
>
> Could we do revert, repost? For my health sakes :)
Eran are you ok with the revert?
I'll do it once I have Eran's confirmation.
^ permalink raw reply
* Re: [PATCH] net: amd8111e: clean up two minor indentation issues
From: David Miller @ 2019-01-25 6:06 UTC (permalink / raw)
To: colin.king; +Cc: netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190122143755.32527-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 22 Jan 2019 14:37:55 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> Two statements are incorrecly indented, fix these by removing a space.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v4 0/4] Introduce ENETC ethernet drivers
From: David Miller @ 2019-01-25 6:03 UTC (permalink / raw)
To: claudiu.manoil; +Cc: netdev, alexandru.marginean
In-Reply-To: <1548163797-20192-1-git-send-email-claudiu.manoil@nxp.com>
From: Claudiu Manoil <claudiu.manoil@nxp.com>
Date: Tue, 22 Jan 2019 15:29:53 +0200
> ENETC is a multi-port virtualized Ethernet controller supporting GbE
> designs and Time-Sensitive Networking (TSN) functionality.
> ENETC is operating as an SR-IOV multi-PF capable Root Complex Integrated
> Endpoint (RCIE). As such, it contains multiple physical (PF) and virtual
> (VF) PCIe functions, discoverable by standard PCI Express.
>
> The patch series adds basic enablement for these otherwise standard
> buffer descriptor (BD) ring based ethernet devices (PCIe PFs and VFs),
> currently included in the 64-bit dual ARMv8 processors LS1028A SoC.
> The driver is portable to 32-bit designs, and it's independent of CPU
> endianness.
>
> Contributors:
> Alex Marginean <alexandru.marginean@nxp.com>
> Catalin Horghidan <catalin.horghidan@nxp.com>
>
> TODO list:
> * IEEE 1588 PTP support;
> * TSN support;
> * MDIO support and VF link management;
> * power management support;
> * flow control support;
> * TC offloading with h/w MQPRIO;
> * interrupt coalescing, configurable BD ring sizes, and other usual
> config options if missing.
Looks good to start with, series applied, thanks!
^ permalink raw reply
* Re: WoL broken in r8169.c since kernel 4.19
From: Marc Haber @ 2019-01-25 5:59 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev@vger.kernel.org
In-Reply-To: <3c3249f8-6e09-43a7-e4e2-f4fc2b9531ab@gmail.com>
Hi Heiner,
On Tue, Jan 22, 2019 at 07:47:45PM +0100, Heiner Kallweit wrote:
> Which version of 4.18 are you running that is ok? To check the code ..
I pull over drivers/net/ethernet/realtek/r8169.c from an unpacked
4.18.16 source tree. It sets RTL8169_VERSION "2.3LK-NAPI". The last
commit in this file's history is
commit 241e5a13a5ad75fd0b5a47b583e098fa08917d5c
Author: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Date: Thu Oct 11 16:02:10 2018 +0200
r8169: set RX_MULTI_EN bit in RxConfig for 8168F-family chips
Unfortunately, very different r8169.c in 4.20.3 also sets RTL8169_VERSION "2.3LK-NAPI", so we cannot use this as identification.
> Based on what I wrote above, could you try the following sequence and
> check whether wake from S3 works then?
>
> ethtool -s <if> wol d
> ethtool -s <if> wol g
This test was done with the Debian kernel package 4.20.0-trunk-amd64,
which contains a kernel 4.20.1 compiled on 2018-12-24, from Debian's
experimental repository.
This are my steps:
(1) ethtool -s lanc0 wol d
(2) ethtool -s lanc0 wol g
(3) systemctl suspend
(4) system gows down into Suspend to RAM, an audible *click* from a
relay, power LED blinking, Switch reporting that the ethernet link state
changed from 1000Full to down and then to 10Full.
(5) sent a magic packet
(6) *click* system up again. This is good.
(7) switch reported link state change from 10Full to down and then to
1000Full
(8) system and network operational
(9) shut down the system completely, remove power. all LEDs off, link
down
(10) re-plug power, all LEDs off, link 10Full
(11) push power button, bring system up again with Debian's 4.20 kernel
(12) link up at 1000Full
(12a) take register dump, exhibit 12a
(13) systemctl suspend
(14) system gows down into Suspend to RAM, an audible *click* from a
relay, power LED blinking, Switch reporting that the ethernet link state
changed from 1000Full to down and then to 10Full.
(15) send magic packet identical to step (5)
(16) system remains suspended, blinking LED; link 10Full
(17) push any key on keyboard
(18) *click* system up again. This is good.
(19) switch reported link state change from 10Full to down and then to
1000Full
(19a) take register dump, exhibit 19a
(20) system and network operational
(21) repeat steps (1) through (5)
(22) system reacts to magic packet and wakes up
(23) ethtool -s lanc0 wol d
(24) ethtool -s lanc0 wol g
(25) take register dump, exhibit 25
(26) systemctl suspend
(27) system gows down into Suspend to RAM, an audible *click* from a
relay, power LED blinking, Switch reporting that the ethernet link state
changed from 1000Full to down and then to 10Full.
(28) sent a magic packet
(29) *click* system up again. This is good.
(30) switch reported link state change from 10Full to down and then to
1000Full
(31) take register dump, exhibit 31
(32) system and network operational
So, our hypothesis is now that the older driver does "something" that
the new driver doesn't, but what is needed for my machine to wake up on
magic packet from suspend to RAM. the two ethtool calls do seem to fix
that.
Unfortunately, exhibits 19a, 25 and 31 are identical, and exhibit 12a
only differs in a single line, PHY access holding 0x8001796d instead of
0x80040de1. So, whatever the two ethtools do, it is not visible in the
register dump.
I repaeted the experiment with stock 4.20.4, with the same results, and
4.20.4 with a r8169.c transplant from 4.18.16, with the result of
ethtool not needed.
Exhibits from the stock 4.20.4 experiments:
exhibit-4.20.4-preeth-presleep - direct after boot
exhibit-4.20.4-preeth-postsleep - after suspend with manual wakeup needed
exhibit-4.20.4-posteth-presleep - after the two ethtool calls
exhibit-4.20.4-posteth-postsleep - after successful wake on lan
Exhibits from the 4.20.4+transplant experiments:
exhibit-4.18-presleep - direct after boot
exhibit-4.18-postsleep - after successful wake on LAN.
I hope this helps. Let me know if additional data is helpful.
Greetings
Marc
Exhibits:
==> exhibit-12a <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x1ab90000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x1f153000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x03
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x8001796d
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9C: PM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x1f152000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
==> exhibit-19a <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x1ab90000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x1f153000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x03
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x80040de1
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9C: PM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x1f152000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
==> exhibit-25 <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x1ab90000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x1f153000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x03
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x80040de1
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9C: PM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x1f152000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
==> exhibit-31 <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x1ab90000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x1f153000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x03
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x80040de1
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9C: PM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x1f152000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
==> exhibit-4.20.4-preeth-presleep <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x1f7c2000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x0ce91000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x03
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x8001796d
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9C: PM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x0ce8e000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
==> exhibit-4.20.4-preeth-postsleep <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x1f7c2000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x0ce91000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x03
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x80040de1
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9C: PM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x0ce8e000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
==> exhibit-4.20.4-posteth-presleep <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x1f7c2000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x0ce91000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x03
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x80040de1
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9C: PM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x0ce8e000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
==> exhibit-4.20.4-posteth-postsleep <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x1f7c2000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x0ce91000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: fig 4 0x51
0x56: Config 5 0x03
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x80040de1
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9C: PM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x0ce8e000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
==> exhibit-4.18-presleep <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x20651000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x0e02c000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x02
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x8005c1e1
0x64: TBI control and status 0x84321043
0x68: I Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9C: PM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x0e02d000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
==> exhibit-4.18-postsleep <==
RealTek RTL8168evl/8111evl registers:
--------------------------------------------------------
0x00: MAC Address 54:04:a6:82:21:00
0x08: Multicast Address Filter 0x024a0040 0x80c14082
0x10: Dump Tally Counter Command 0x20651000 0x00000004
0x20: Tx Normal Priority Ring Addr 0x0e02c000 0x00000004
0x28: Tx High Priority Ring Addr 0x00000000 0x00000000
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x803f
SERR LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x2f900f80
0x44: Rx Configuration 0x0002c70e
0x48: Timer count 0x00000000
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x10
0x51: Config 0 0x00
0x52: Config 1 0xcf
0x53: Config 2 0xbd
0x54: Config 3 0x60
0x55: Config 4 0x51
0x56: Config 5 0x02
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x80040de1
0x64: TBI control and status 0x84321043
0x68: TBI Autonegotiation advertisement (ANAR) 0xf02c
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x93
0x84: PM wakeup frame 0 0x00000000 0x00000000
0x8C: PM wakeup frame 1 0x00000000 0x4af63565
0x94: PM wakeup frame 2 (low) 0x6202016b 0x8ab829be
0x9CM wakeup frame 2 (high) 0x40bee65e 0x800e2860
0xA4: PM wakeup frame 3 (low) 0x44280748 0x1ceea050
0xAC: PM wakeup frame 3 (high) 0xc465e124 0xc4650000
0xB4: PM wakeup frame 4 (low) 0xffffffff 0xffffffff
0xBC: PM wakeup frame 4 (high) 0x00000000 0x00000000
0xC4: Wakeup frame 0 CRC 0x0000
0xC6: Wakeup frame 1 CRC 0x0000
0xC8: Wakeup frame 2 CRC 0x0000
0xCA: Wakeup frame 3 CRC 0x0000
0xCC: Wakeup frame 4 CRC 0x0000
0xDA: RX packet maximum size 0x4000
0xE0: C+ Command 0x20e1
VLAN de-tagging
RX checksumming
0xE2: Interrupt Mitigation 0x5151
TxTimer: 5
TxPackets: 1
RxTimer: 5
RxPackets: 1
0xE4: Rx Ring Addr 0x0e02d000 0x00000004
0xEC: Early Tx threshold 0x27
0xF0: Func Event 0x00400030
0xF4: Func Event Mask 0x00000000
0xF8: Func Preset State 0x000303ff
0xFC: Func Force Event 0x00000000
-
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply
* Re: [PATCH net-next] net/mlx4_core: A write memory barrier is sufficient in EQ ci update
From: David Miller @ 2019-01-25 5:54 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe, edumazet
In-Reply-To: <1548163550-16750-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Tue, 22 Jan 2019 15:25:50 +0200
> Soften the memory barrier call of mb() by a sufficient wmb() in the
> consumer index update of the event queues.
>
> Suggested-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Applied, thank you.
^ permalink raw reply
* Re: pull-request: can 2019-01-22
From: David Miller @ 2019-01-25 5:52 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel
In-Reply-To: <20190122132116.7074-1-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Tue, 22 Jan 2019 14:21:12 +0100
> this is a pull request of 4 patches for net/master.
>
> The first patch by is by Manfred Schlaegl and reverts a patch that caused wrong
> warning messages in certain use cases. The next patch is by Oliver Hartkopp for
> the bcm that adds sanity checks for the timer value before using it to detect
> potential interger overflows. The last two patches are for the flexcan driver,
> YueHaibing's patch fixes the the return value in the error path of the
> flexcan_setup_stop_mode() function. The second patch is by Uwe Kleine-König and
> fixes a NULL pointer deref on older flexcan cores in flexcan_chip_start().
Pulled, thanks Marc.
^ permalink raw reply
* Re: [PATCH net 0/2] mlx4_core fixes for 5.0-rc
From: David Miller @ 2019-01-25 5:51 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe
In-Reply-To: <1548163185-13986-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Tue, 22 Jan 2019 15:19:43 +0200
> This patchset includes two fixes for the mlx4_core driver.
>
> First patch by Aya fixes inaccurate parsing of some FW fields, mistakenly
> including additional (mostly reserved) bits.
>
> Second patch by Jack fixes a wrong (yet harmless) error handling of
> calls to copy_to_user() during the CQs init stage.
>
>
> Series generated against net commit:
> 49a57857aeea Linux 5.0-rc3
Series applied, and patch #1 queued up for -stable.
^ permalink raw reply
* Re: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock
From: Alexei Starovoitov @ 2019-01-25 4:47 UTC (permalink / raw)
To: paulmck@linux.ibm.com
Cc: Alexei Starovoitov, Jann Horn, Peter Zijlstra, Alexei Starovoitov,
David S. Miller, Daniel Borkmann, jakub.kicinski@netronome.com,
Network Development, Kernel Team, Ingo Molnar, Will Deacon
In-Reply-To: <20190125043158.GB4240@linux.ibm.com>
On 1/24/19 8:31 PM, Paul E. McKenney wrote:
> On Fri, Jan 25, 2019 at 04:27:02AM +0000, Alexei Starovoitov wrote:
>> On 1/24/19 6:38 PM, Alexei Starovoitov wrote:
>>>> For programs created with CAP_SYS_ADMIN,
>>>> things get more tricky because you can create your own functions and
>>>> call them repeatedly; I'm not sure whether the pessimal runtime there
>>>> becomes exponential, or whether there is some check that catches this.
>>> I think you're referring to bpf-to-bpf calls.
>>> The limit it still the same. 4k per program including all calls.
>>> tail calls are not allowed when bpf-to-bpf is used. So no 32 multiplier.
>>
>> Jann,
>>
>> I think you meant
>> main:
>> call A
>> call A
>> call A
>> exit
>> A:
>> call B
>> call B
>> call B
>> exit
>> B:
>> call C
>> ...
>>
>> scenario when everything fits into 4k?
>> Would be great if you can construct such test while we're fixing
>> the rest of the issues brought up in this thread.
>> It will definitely be no more than BPF_COMPLEXITY_LIMIT_INSNS
>> which is 128k, but I wonder what will be the actual number of
>> executed insns.
>> I think such clever constructed sequence can actually
>> hit 128k executed too.
>> It would be awesome test to add to test_verifier.c
>> We have some of such pushing-the-boundary tests in lib/test_bpf.c
>> that are generated in assembler.
>> The longest takes 23853 nanoseconds, but clever bpf2bpf call hack
>> like above with map_update call in the leaf function should
>> certainly take much longer.
>> I accept Paul's challenge to try to get such fancy bpf prog
>> to take 100 millseconds :)
>
> Fair enough! But once you meet my challenge, the RCU CPU stall warning
> code will challenge you to hit 21 seconds (or only three seconds given
> an appropriately configured kernel). ;-)
if (till_stall_check < 3) {
WRITE_ONCE(rcu_cpu_stall_timeout, 3);
till_stall_check = 3;
let's change that limit to 1 !
Seriously though folks have proposed to teach bpf verifier
to sprinkle cond_resched() automatically into bpf program
when critical path through the program reaches certain insn limit.
The verifier can easily be taught to compute the longest path.
Other folks proposed to get rid of 4k limit when prog
is preemptable and executing in user context.
That's when srcu will come into play.
^ permalink raw reply
* Re: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock
From: Paul E. McKenney @ 2019-01-25 4:31 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, Jann Horn, Peter Zijlstra, Alexei Starovoitov,
David S. Miller, Daniel Borkmann, jakub.kicinski@netronome.com,
Network Development, Kernel Team, Ingo Molnar, Will Deacon
In-Reply-To: <150dc5d3-21c3-bbb6-6e5b-2ab8ab0e3f38@fb.com>
On Fri, Jan 25, 2019 at 04:27:02AM +0000, Alexei Starovoitov wrote:
> On 1/24/19 6:38 PM, Alexei Starovoitov wrote:
> >> For programs created with CAP_SYS_ADMIN,
> >> things get more tricky because you can create your own functions and
> >> call them repeatedly; I'm not sure whether the pessimal runtime there
> >> becomes exponential, or whether there is some check that catches this.
> > I think you're referring to bpf-to-bpf calls.
> > The limit it still the same. 4k per program including all calls.
> > tail calls are not allowed when bpf-to-bpf is used. So no 32 multiplier.
>
> Jann,
>
> I think you meant
> main:
> call A
> call A
> call A
> exit
> A:
> call B
> call B
> call B
> exit
> B:
> call C
> ...
>
> scenario when everything fits into 4k?
> Would be great if you can construct such test while we're fixing
> the rest of the issues brought up in this thread.
> It will definitely be no more than BPF_COMPLEXITY_LIMIT_INSNS
> which is 128k, but I wonder what will be the actual number of
> executed insns.
> I think such clever constructed sequence can actually
> hit 128k executed too.
> It would be awesome test to add to test_verifier.c
> We have some of such pushing-the-boundary tests in lib/test_bpf.c
> that are generated in assembler.
> The longest takes 23853 nanoseconds, but clever bpf2bpf call hack
> like above with map_update call in the leaf function should
> certainly take much longer.
> I accept Paul's challenge to try to get such fancy bpf prog
> to take 100 millseconds :)
Fair enough! But once you meet my challenge, the RCU CPU stall warning
code will challenge you to hit 21 seconds (or only three seconds given
an appropriately configured kernel). ;-)
Thanx, Paul
^ permalink raw reply
* Re: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock
From: Alexei Starovoitov @ 2019-01-25 4:27 UTC (permalink / raw)
To: Alexei Starovoitov, Jann Horn
Cc: paulmck@linux.ibm.com, Peter Zijlstra, Alexei Starovoitov,
David S. Miller, Daniel Borkmann, jakub.kicinski@netronome.com,
Network Development, Kernel Team, Ingo Molnar, Will Deacon
In-Reply-To: <20190125023816.zolpqls5bcsbqsga@ast-mbp.dhcp.thefacebook.com>
On 1/24/19 6:38 PM, Alexei Starovoitov wrote:
>> For programs created with CAP_SYS_ADMIN,
>> things get more tricky because you can create your own functions and
>> call them repeatedly; I'm not sure whether the pessimal runtime there
>> becomes exponential, or whether there is some check that catches this.
> I think you're referring to bpf-to-bpf calls.
> The limit it still the same. 4k per program including all calls.
> tail calls are not allowed when bpf-to-bpf is used. So no 32 multiplier.
Jann,
I think you meant
main:
call A
call A
call A
exit
A:
call B
call B
call B
exit
B:
call C
...
scenario when everything fits into 4k?
Would be great if you can construct such test while we're fixing
the rest of the issues brought up in this thread.
It will definitely be no more than BPF_COMPLEXITY_LIMIT_INSNS
which is 128k, but I wonder what will be the actual number of
executed insns.
I think such clever constructed sequence can actually
hit 128k executed too.
It would be awesome test to add to test_verifier.c
We have some of such pushing-the-boundary tests in lib/test_bpf.c
that are generated in assembler.
The longest takes 23853 nanoseconds, but clever bpf2bpf call hack
like above with map_update call in the leaf function should
certainly take much longer.
I accept Paul's challenge to try to get such fancy bpf prog
to take 100 millseconds :)
^ permalink raw reply
* Re: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock
From: Paul E. McKenney @ 2019-01-25 4:11 UTC (permalink / raw)
To: Jann Horn
Cc: Alexei Starovoitov, Peter Zijlstra, Alexei Starovoitov,
David S. Miller, Daniel Borkmann, jakub.kicinski,
Network Development, kernel-team, Ingo Molnar, Will Deacon
In-Reply-To: <CAG48ez0+pPq3OJpYnXEidNqN9vi13K0BO-pg1XLu59kPx4c+Dw@mail.gmail.com>
On Fri, Jan 25, 2019 at 02:46:55AM +0100, Jann Horn wrote:
> On Fri, Jan 25, 2019 at 2:22 AM Paul E. McKenney <paulmck@linux.ibm.com> wrote:
> > On Thu, Jan 24, 2019 at 04:05:16PM -0800, Alexei Starovoitov wrote:
> > > On Thu, Jan 24, 2019 at 03:42:32PM -0800, Paul E. McKenney wrote:
> > > > On Thu, Jan 24, 2019 at 07:56:52PM +0100, Peter Zijlstra wrote:
> > > > > On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> > > > > >
> > > > > > Thanks for having kernel/locking people on Cc...
> > > > > >
> > > > > > On Wed, Jan 23, 2019 at 08:13:55PM -0800, Alexei Starovoitov wrote:
> > > > > >
> > > > > > > Implementation details:
> > > > > > > - on !SMP bpf_spin_lock() becomes nop
> > > > > >
> > > > > > Because no BPF program is preemptible? I don't see any assertions or
> > > > > > even a comment that says this code is non-preemptible.
> > > > > >
> > > > > > AFAICT some of the BPF_RUN_PROG things are under rcu_read_lock() only,
> > > > > > which is not sufficient.
> > > > > >
> > > > > > > - on architectures that don't support queued_spin_lock trivial lock is used.
> > > > > > > Note that arch_spin_lock cannot be used, since not all archs agree that
> > > > > > > zero == unlocked and sizeof(arch_spinlock_t) != sizeof(__u32).
> > > > > >
> > > > > > I really don't much like direct usage of qspinlock; esp. not as a
> > > > > > surprise.
> > > >
> > > > Substituting the lightweight-reader SRCU as discussed earlier would allow
> > > > use of a more generic locking primitive, for example, one that allowed
> > > > blocking, at least in cases were the context allowed this.
> > > >
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> > > > branch srcu-lr.2019.01.16a.
> > > >
> > > > One advantage of a more generic locking primitive would be keeping BPF
> > > > programs independent of internal changes to spinlock primitives.
> > >
> > > Let's keep "srcu in bpf" discussion separate from bpf_spin_lock discussion.
> > > bpf is not switching to srcu any time soon.
> > > If/when it happens it will be only for certain prog+map types
> > > like bpf syscall probes that need to be able to do copy_from_user
> > > from bpf prog.
> >
> > Hmmm... What prevents BPF programs from looping infinitely within an
> > RCU reader, and as you noted, preemption disabled?
> >
> > If BPF programs are in fact allowed to loop infinitely, it would be
> > very good for the health of the kernel to have preemption enabled.
> > And to be within an SRCU read-side critical section instead of an RCU
> > read-side critical section.
>
> The BPF verifier prevents loops; this is in push_insn() in
> kernel/bpf/verifier.c, which errors out with -EINVAL when a back edge
> is encountered. For non-root programs, that limits the maximum number
> of instructions per eBPF engine execution to
> BPF_MAXINSNS*MAX_TAIL_CALL_CNT==4096*32==131072 (but that includes
> call instructions, which can cause relatively expensive operations
> like hash table lookups). For programs created with CAP_SYS_ADMIN,
> things get more tricky because you can create your own functions and
> call them repeatedly; I'm not sure whether the pessimal runtime there
> becomes exponential, or whether there is some check that catches this.
Whew!!! ;-)
So no more than (say) 100 milliseconds?
Thanx, Paul
^ permalink raw reply
* Re: [PATCH net-next] libceph, ceph: use struct_size() in kmalloc()
From: Gustavo A. R. Silva @ 2019-01-25 3:50 UTC (permalink / raw)
To: Ilya Dryomov
Cc: Yan, Zheng, Sage Weil, David S. Miller, Ceph Development, netdev,
linux-kernel
In-Reply-To: <CAOi1vP_yWH2mhquFObC6VnUzNTzc7PX7tqA3RP=ci71BMm-gqA@mail.gmail.com>
On 1/17/19 8:17 AM, Ilya Dryomov wrote:
> On Tue, Jan 15, 2019 at 8:41 PM Gustavo A. R. Silva
> <gustavo@embeddedor.com> wrote:
>>
>> One of the more common cases of allocation size calculations is finding
>> the size of a structure that has a zero-sized array at the end, along
>> with memory for some number of elements for that array. For example:
>>
>> struct foo {
>> int stuff;
>> struct boo entry[];
>> };
>>
>> instance = kmalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL);
>>
>> Instead of leaving these open-coded and prone to type mistakes, we can
>> now use the new struct_size() helper:
>>
>> instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL);
>>
>> This code was detected with the help of Coccinelle.
>>
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>> ---
>> net/ceph/osdmap.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/net/ceph/osdmap.c b/net/ceph/osdmap.c
>> index 98c0ff3d6441..48a31dc9161c 100644
>> --- a/net/ceph/osdmap.c
>> +++ b/net/ceph/osdmap.c
>> @@ -495,9 +495,8 @@ static struct crush_map *crush_decode(void *pbyval, void *end)
>> / sizeof(struct crush_rule_step))
>> goto bad;
>> #endif
>> - r = c->rules[i] = kmalloc(sizeof(*r) +
>> - yes*sizeof(struct crush_rule_step),
>> - GFP_NOFS);
>> + r = kmalloc(struct_size(r, steps, yes), GFP_NOFS);
>> + c->rules[i] = r;
>> if (r == NULL)
>> goto badmem;
>> dout(" rule %d is at %p\n", i, r);
>
> Applied.
>
Thanks, Ilya.
--
Gustavo
^ permalink raw reply
* RE: [PATCH -next] ptp: fix debugfs_simple_attr.cocci warnings
From: Y.b. Lu @ 2019-01-25 3:33 UTC (permalink / raw)
To: YueHaibing, Richard Cochran, davem@davemloft.net
Cc: netdev@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <1548383339-159403-1-git-send-email-yuehaibing@huawei.com>
> -----Original Message-----
> From: YueHaibing <yuehaibing@huawei.com>
> Sent: Friday, January 25, 2019 10:29 AM
> To: Y.b. Lu <yangbo.lu@nxp.com>; Richard Cochran
> <richardcochran@gmail.com>; davem@davemloft.net
> Cc: YueHaibing <yuehaibing@huawei.com>; netdev@vger.kernel.org;
> kernel-janitors@vger.kernel.org
> Subject: [PATCH -next] ptp: fix debugfs_simple_attr.cocci warnings
>
> Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE for
> debugfs files.
>
> Semantic patch information:
> Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file() imposes some
> significant overhead as compared to DEFINE_DEBUGFS_ATTRIBUTE +
> debugfs_create_file_unsafe().
>
> Generated by: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
[Y.b. Lu] It makes sense to me.
Acked-by: Yangbo Lu <yangbo.lu@nxp.com>
> ---
> drivers/ptp/ptp_qoriq_debugfs.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/ptp/ptp_qoriq_debugfs.c b/drivers/ptp/ptp_qoriq_debugfs.c
> index d904332..97059502 100644
> --- a/drivers/ptp/ptp_qoriq_debugfs.c
> +++ b/drivers/ptp/ptp_qoriq_debugfs.c
> @@ -33,8 +33,8 @@ static int ptp_qoriq_fiper1_lpbk_set(void *data, u64 val)
> return 0;
> }
>
> -DEFINE_SIMPLE_ATTRIBUTE(ptp_qoriq_fiper1_fops,
> ptp_qoriq_fiper1_lpbk_get,
> - ptp_qoriq_fiper1_lpbk_set, "%llu\n");
> +DEFINE_DEBUGFS_ATTRIBUTE(ptp_qoriq_fiper1_fops,
> ptp_qoriq_fiper1_lpbk_get,
> + ptp_qoriq_fiper1_lpbk_set, "%llu\n");
>
> static int ptp_qoriq_fiper2_lpbk_get(void *data, u64 *val) { @@ -64,8
> +64,8 @@ static int ptp_qoriq_fiper2_lpbk_set(void *data, u64 val)
> return 0;
> }
>
> -DEFINE_SIMPLE_ATTRIBUTE(ptp_qoriq_fiper2_fops,
> ptp_qoriq_fiper2_lpbk_get,
> - ptp_qoriq_fiper2_lpbk_set, "%llu\n");
> +DEFINE_DEBUGFS_ATTRIBUTE(ptp_qoriq_fiper2_fops,
> ptp_qoriq_fiper2_lpbk_get,
> + ptp_qoriq_fiper2_lpbk_set, "%llu\n");
>
> void ptp_qoriq_create_debugfs(struct qoriq_ptp *qoriq_ptp) { @@ -79,11
> +79,11 @@ void ptp_qoriq_create_debugfs(struct qoriq_ptp *qoriq_ptp)
>
> qoriq_ptp->debugfs_root = root;
>
> - if (!debugfs_create_file("fiper1-loopback", 0600, root, qoriq_ptp,
> - &ptp_qoriq_fiper1_fops))
> + if (!debugfs_create_file_unsafe("fiper1-loopback", 0600, root,
> + qoriq_ptp, &ptp_qoriq_fiper1_fops))
> goto err_node;
> - if (!debugfs_create_file("fiper2-loopback", 0600, root, qoriq_ptp,
> - &ptp_qoriq_fiper2_fops))
> + if (!debugfs_create_file_unsafe("fiper2-loopback", 0600, root,
> + qoriq_ptp, &ptp_qoriq_fiper2_fops))
> goto err_node;
> return;
>
>
^ permalink raw reply
* [PATCH net-next] net: hns3: Fix potential NULL dereference on allocation error
From: YueHaibing @ 2019-01-25 3:13 UTC (permalink / raw)
To: davem, yisen.zhuang, salil.mehta, lipeng321
Cc: linux-kernel, netdev, YueHaibing
hclge_mac_update_stats_complete doesn't check for NULL
returns of kcalloc, it may result in an Oops.
Fixes: d174ea75c96a ("net: hns3: add statistics for PFC frames and MAC control frames")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 64b1589..7971606 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -343,6 +343,9 @@ static int hclge_mac_update_stats_complete(struct hclge_dev *hdev, u32 desc_num)
int ret;
desc = kcalloc(desc_num, sizeof(struct hclge_desc), GFP_KERNEL);
+ if (!desc)
+ return -ENOMEM;
+
hclge_cmd_setup_basic_desc(&desc[0], HCLGE_OPC_STATS_MAC_ALL, true);
ret = hclge_cmd_send(&hdev->hw, desc, desc_num);
if (ret) {
--
2.7.0
^ permalink raw reply related
* Re: [PATCH net-next V4 5/5] vhost: access vq metadata through kernel virtual address
From: Michael S. Tsirkin @ 2019-01-25 3:03 UTC (permalink / raw)
To: Jason Wang; +Cc: virtualization, netdev, linux-kernel, kvm, aarcange
In-Reply-To: <20190123095557.30168-6-jasowang@redhat.com>
On Wed, Jan 23, 2019 at 05:55:57PM +0800, Jason Wang wrote:
> It was noticed that the copy_user() friends that was used to access
> virtqueue metdata tends to be very expensive for dataplane
> implementation like vhost since it involves lots of software checks,
> speculation barrier, hardware feature toggling (e.g SMAP). The
> extra cost will be more obvious when transferring small packets since
> the time spent on metadata accessing become more significant.
>
> This patch tries to eliminate those overheads by accessing them
> through kernel virtual address by vmap(). To make the pages can be
> migrated, instead of pinning them through GUP, we use MMU notifiers to
> invalidate vmaps and re-establish vmaps during each round of metadata
> prefetching if necessary. For devices that doesn't use metadata
> prefetching, the memory accessors fallback to normal copy_user()
> implementation gracefully. The invalidation was synchronized with
> datapath through vq mutex, and in order to avoid hold vq mutex during
> range checking, MMU notifier was teared down when trying to modify vq
> metadata.
>
> Another thing is kernel lacks efficient solution for tracking dirty
> pages by vmap(), this will lead issues if vhost is using file backed
> memory which needs care of writeback. This patch solves this issue by
> just skipping the vma that is file backed and fallback to normal
> copy_user() friends. This might introduce some overheads for file
> backed users but consider this use case is rare we could do
> optimizations on top.
>
> Note that this was only done when device IOTLB is not enabled. We
> could use similar method to optimize it in the future.
>
> Tests shows at most about 22% improvement on TX PPS when using
> virtio-user + vhost_net + xdp1 + TAP on 2.6GHz Broadwell:
>
> SMAP on | SMAP off
> Before: 5.0Mpps | 6.6Mpps
> After: 6.1Mpps | 7.4Mpps
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/vhost/vhost.c | 288 +++++++++++++++++++++++++++++++++++++++++-
> drivers/vhost/vhost.h | 13 ++
> mm/shmem.c | 1 +
> 3 files changed, 300 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 37e2cac8e8b0..096ae3298d62 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -440,6 +440,9 @@ void vhost_dev_init(struct vhost_dev *dev,
> vq->indirect = NULL;
> vq->heads = NULL;
> vq->dev = dev;
> + memset(&vq->avail_ring, 0, sizeof(vq->avail_ring));
> + memset(&vq->used_ring, 0, sizeof(vq->used_ring));
> + memset(&vq->desc_ring, 0, sizeof(vq->desc_ring));
> mutex_init(&vq->mutex);
> vhost_vq_reset(dev, vq);
> if (vq->handle_kick)
> @@ -510,6 +513,73 @@ static size_t vhost_get_desc_size(struct vhost_virtqueue *vq, int num)
> return sizeof(*vq->desc) * num;
> }
>
> +static void vhost_uninit_vmap(struct vhost_vmap *map)
> +{
> + if (map->addr)
> + vunmap(map->unmap_addr);
> +
> + map->addr = NULL;
> + map->unmap_addr = NULL;
> +}
> +
> +static int vhost_invalidate_vmap(struct vhost_virtqueue *vq,
> + struct vhost_vmap *map,
> + unsigned long ustart,
> + size_t size,
> + unsigned long start,
> + unsigned long end,
> + bool blockable)
> +{
> + if (end < ustart || start > ustart - 1 + size)
> + return 0;
> +
> + if (!blockable)
> + return -EAGAIN;
> +
> + mutex_lock(&vq->mutex);
> + vhost_uninit_vmap(map);
> + mutex_unlock(&vq->mutex);
> +
> + return 0;
> +}
> +
> +static int vhost_invalidate_range_start(struct mmu_notifier *mn,
> + const struct mmu_notifier_range *range)
> +{
> + struct vhost_dev *dev = container_of(mn, struct vhost_dev,
> + mmu_notifier);
> + int i;
> +
> + for (i = 0; i < dev->nvqs; i++) {
> + struct vhost_virtqueue *vq = dev->vqs[i];
> +
> + if (vhost_invalidate_vmap(vq, &vq->avail_ring,
> + (unsigned long)vq->avail,
> + vhost_get_avail_size(vq, vq->num),
> + range->start, range->end,
> + range->blockable))
> + return -EAGAIN;
> + if (vhost_invalidate_vmap(vq, &vq->desc_ring,
> + (unsigned long)vq->desc,
> + vhost_get_desc_size(vq, vq->num),
> + range->start, range->end,
> + range->blockable))
> + return -EAGAIN;
> + if (vhost_invalidate_vmap(vq, &vq->used_ring,
> + (unsigned long)vq->used,
> + vhost_get_used_size(vq, vq->num),
> + range->start, range->end,
> + range->blockable))
> + return -EAGAIN;
> + }
> +
> + return 0;
> +}
> +
> +static const struct mmu_notifier_ops vhost_mmu_notifier_ops = {
> + .invalidate_range_start = vhost_invalidate_range_start,
> +};
> +
> /* Caller should have device mutex */
> long vhost_dev_set_owner(struct vhost_dev *dev)
> {
It seems questionable to merely track .invalidate_range_start.
Don't we care about keeping pages young/accessed?
MMU will think they aren't and will penalize vhost by pushing
them out.
I note that MMU documentation says
* invalidate_range_start() and invalidate_range_end() must be
* paired
and it seems questionable that they are not paired here.
I also wonder about things like write-protecting the pages.
It does not look like a range is invalidated when page
is write-protected, even though I might have missed that.
If not we can be corrupting memory in a variety of ways
e.g. when using KSM, or with COW.
> @@ -541,7 +611,14 @@ long vhost_dev_set_owner(struct vhost_dev *dev)
> if (err)
> goto err_cgroup;
>
> + dev->mmu_notifier.ops = &vhost_mmu_notifier_ops;
> + err = mmu_notifier_register(&dev->mmu_notifier, dev->mm);
> + if (err)
> + goto err_mmu_notifier;
> +
> return 0;
> +err_mmu_notifier:
> + vhost_dev_free_iovecs(dev);
> err_cgroup:
> kthread_stop(worker);
> dev->worker = NULL;
> @@ -632,6 +709,97 @@ static void vhost_clear_msg(struct vhost_dev *dev)
> spin_unlock(&dev->iotlb_lock);
> }
>
> +/* Suppress the vma that needs writeback since we can not track dirty
> + * pages now.
> + */
> +static bool vma_can_vmap(struct vm_area_struct *vma)
> +{
> + return vma_is_anonymous(vma) || is_vm_hugetlb_page(vma) ||
> + vma_is_shmem(vma);
> +}
> +
IIUC a second but anonymous memory needs writeback too, just to swap.
I'm not an MM person so I might be off.
> +static int vhost_init_vmap(struct vhost_dev *dev,
> + struct vhost_vmap *map, unsigned long uaddr,
> + size_t size, int write)
> +{
> + struct mm_struct *mm = dev->mm;
> + struct vm_area_struct *vma;
> + struct page **pages;
> + int npages = DIV_ROUND_UP(size, PAGE_SIZE);
> + int npinned;
> + void *vaddr;
> + int err = 0;
> +
> + down_read(&mm->mmap_sem);
> + vma = find_vma(mm, uaddr);
> + if (!vma || !vma_can_vmap(vma) ||
> + vma->vm_end < uaddr - 1 + size) {
> + err = -EINVAL;
> + goto err_vma;
> + }
> +
> + pages = kmalloc_array(npages, sizeof(struct page *), GFP_KERNEL);
> + if (!pages) {
> + err = -ENOMEM;
> + goto err_alloc;
> + }
> +
> + npinned = get_user_pages_fast(uaddr, npages, write, pages);
> + if (npinned != npages) {
> + err = -EFAULT;
> + goto err_gup;
> + }
> +
> + vaddr = vmap(pages, npages, VM_MAP, PAGE_KERNEL);
> + if (!vaddr) {
> + err = EFAULT;
> + goto err_gup;
> + }
> +
> + map->addr = vaddr + (uaddr & (PAGE_SIZE - 1));
> + map->unmap_addr = vaddr;
> +
> +err_gup:
> + /* Don't pin pages, mmu notifier will notify us about page
> + * migration.
> + */
> + if (npinned > 0)
> + release_pages(pages, npinned);
> +err_alloc:
> + kfree(pages);
> +err_vma:
> + up_read(&mm->mmap_sem);
> + return err;
> +}
> +
> +static void vhost_clean_vmaps(struct vhost_virtqueue *vq)
> +{
> + vhost_uninit_vmap(&vq->avail_ring);
> + vhost_uninit_vmap(&vq->desc_ring);
> + vhost_uninit_vmap(&vq->used_ring);
> +}
> +
> +static int vhost_setup_avail_vmap(struct vhost_virtqueue *vq,
> + unsigned long avail)
> +{
> + return vhost_init_vmap(vq->dev, &vq->avail_ring, avail,
> + vhost_get_avail_size(vq, vq->num), false);
> +}
> +
> +static int vhost_setup_desc_vmap(struct vhost_virtqueue *vq,
> + unsigned long desc)
> +{
> + return vhost_init_vmap(vq->dev, &vq->desc_ring, desc,
> + vhost_get_desc_size(vq, vq->num), false);
> +}
> +
> +static int vhost_setup_used_vmap(struct vhost_virtqueue *vq,
> + unsigned long used)
> +{
> + return vhost_init_vmap(vq->dev, &vq->used_ring, used,
> + vhost_get_used_size(vq, vq->num), true);
> +}
> +
> void vhost_dev_cleanup(struct vhost_dev *dev)
> {
> int i;
> @@ -661,8 +829,12 @@ void vhost_dev_cleanup(struct vhost_dev *dev)
> kthread_stop(dev->worker);
> dev->worker = NULL;
> }
> - if (dev->mm)
> + if (dev->mm) {
> + mmu_notifier_unregister(&dev->mmu_notifier, dev->mm);
> mmput(dev->mm);
> + }
> + for (i = 0; i < dev->nvqs; i++)
> + vhost_clean_vmaps(dev->vqs[i]);
> dev->mm = NULL;
> }
> EXPORT_SYMBOL_GPL(vhost_dev_cleanup);
> @@ -891,6 +1063,16 @@ static inline void __user *__vhost_get_user(struct vhost_virtqueue *vq,
>
> static inline int vhost_put_avail_event(struct vhost_virtqueue *vq)
> {
> + if (!vq->iotlb) {
> + struct vring_used *used = vq->used_ring.addr;
> +
> + if (likely(used)) {
> + *((__virtio16 *)&used->ring[vq->num]) =
> + cpu_to_vhost16(vq, vq->avail_idx);
> + return 0;
> + }
> + }
> +
> return vhost_put_user(vq, cpu_to_vhost16(vq, vq->avail_idx),
> vhost_avail_event(vq));
> }
> @@ -899,6 +1081,16 @@ static inline int vhost_put_used(struct vhost_virtqueue *vq,
> struct vring_used_elem *head, int idx,
> int count)
> {
> + if (!vq->iotlb) {
> + struct vring_used *used = vq->used_ring.addr;
> +
> + if (likely(used)) {
> + memcpy(used->ring + idx, head,
> + count * sizeof(*head));
> + return 0;
> + }
> + }
> +
> return vhost_copy_to_user(vq, vq->used->ring + idx, head,
> count * sizeof(*head));
> }
> @@ -906,6 +1098,15 @@ static inline int vhost_put_used(struct vhost_virtqueue *vq,
> static inline int vhost_put_used_flags(struct vhost_virtqueue *vq)
>
> {
> + if (!vq->iotlb) {
> + struct vring_used *used = vq->used_ring.addr;
> +
> + if (likely(used)) {
> + used->flags = cpu_to_vhost16(vq, vq->used_flags);
> + return 0;
> + }
> + }
> +
> return vhost_put_user(vq, cpu_to_vhost16(vq, vq->used_flags),
> &vq->used->flags);
> }
> @@ -913,6 +1114,15 @@ static inline int vhost_put_used_flags(struct vhost_virtqueue *vq)
> static inline int vhost_put_used_idx(struct vhost_virtqueue *vq)
>
> {
> + if (!vq->iotlb) {
> + struct vring_used *used = vq->used_ring.addr;
> +
> + if (likely(used)) {
> + used->idx = cpu_to_vhost16(vq, vq->last_used_idx);
> + return 0;
> + }
> + }
> +
> return vhost_put_user(vq, cpu_to_vhost16(vq, vq->last_used_idx),
> &vq->used->idx);
> }
> @@ -958,12 +1168,30 @@ static void vhost_dev_unlock_vqs(struct vhost_dev *d)
> static inline int vhost_get_avail_idx(struct vhost_virtqueue *vq,
> __virtio16 *idx)
> {
> + if (!vq->iotlb) {
> + struct vring_avail *avail = vq->avail_ring.addr;
> +
> + if (likely(avail)) {
> + *idx = avail->idx;
> + return 0;
> + }
> + }
> +
> return vhost_get_avail(vq, *idx, &vq->avail->idx);
> }
>
> static inline int vhost_get_avail_head(struct vhost_virtqueue *vq,
> __virtio16 *head, int idx)
> {
> + if (!vq->iotlb) {
> + struct vring_avail *avail = vq->avail_ring.addr;
> +
> + if (likely(avail)) {
> + *head = avail->ring[idx & (vq->num - 1)];
> + return 0;
> + }
> + }
> +
> return vhost_get_avail(vq, *head,
> &vq->avail->ring[idx & (vq->num - 1)]);
> }
> @@ -971,24 +1199,60 @@ static inline int vhost_get_avail_head(struct vhost_virtqueue *vq,
> static inline int vhost_get_avail_flags(struct vhost_virtqueue *vq,
> __virtio16 *flags)
> {
> + if (!vq->iotlb) {
> + struct vring_avail *avail = vq->avail_ring.addr;
> +
> + if (likely(avail)) {
> + *flags = avail->flags;
> + return 0;
> + }
> + }
> +
> return vhost_get_avail(vq, *flags, &vq->avail->flags);
> }
>
> static inline int vhost_get_used_event(struct vhost_virtqueue *vq,
> __virtio16 *event)
> {
> + if (!vq->iotlb) {
> + struct vring_avail *avail = vq->avail_ring.addr;
> +
> + if (likely(avail)) {
> + *event = (__virtio16)avail->ring[vq->num];
> + return 0;
> + }
> + }
> +
> return vhost_get_avail(vq, *event, vhost_used_event(vq));
> }
>
> static inline int vhost_get_used_idx(struct vhost_virtqueue *vq,
> __virtio16 *idx)
> {
> + if (!vq->iotlb) {
> + struct vring_used *used = vq->used_ring.addr;
> +
> + if (likely(used)) {
> + *idx = used->idx;
> + return 0;
> + }
> + }
> +
> return vhost_get_used(vq, *idx, &vq->used->idx);
> }
>
> static inline int vhost_get_desc(struct vhost_virtqueue *vq,
> struct vring_desc *desc, int idx)
> {
> + if (!vq->iotlb) {
> + struct vring_desc *d = vq->desc_ring.addr;
> +
> + if (likely(d)) {
> + *desc = *(d + idx);
> + return 0;
> + }
> + }
> +
> return vhost_copy_from_user(vq, desc, vq->desc + idx, sizeof(*desc));
> }
>
> @@ -1329,8 +1593,16 @@ int vq_meta_prefetch(struct vhost_virtqueue *vq)
> {
> unsigned int num = vq->num;
>
> - if (!vq->iotlb)
> + if (!vq->iotlb) {
> + if (unlikely(!vq->avail_ring.addr))
> + vhost_setup_avail_vmap(vq, (unsigned long)vq->avail);
> + if (unlikely(!vq->desc_ring.addr))
> + vhost_setup_desc_vmap(vq, (unsigned long)vq->desc);
> + if (unlikely(!vq->used_ring.addr))
> + vhost_setup_used_vmap(vq, (unsigned long)vq->used);
> +
> return 1;
> + }
>
> return iotlb_access_ok(vq, VHOST_ACCESS_RO, (u64)(uintptr_t)vq->desc,
> vhost_get_desc_size(vq, num), VHOST_ADDR_DESC) &&
> @@ -1482,6 +1754,13 @@ long vhost_vring_ioctl(struct vhost_dev *d, unsigned int ioctl, void __user *arg
>
> mutex_lock(&vq->mutex);
>
> + /* Unregister MMU notifer to allow invalidation callback
> + * can access vq->avail, vq->desc , vq->used and vq->num
> + * without holding vq->mutex.
> + */
> + if (d->mm)
> + mmu_notifier_unregister(&d->mmu_notifier, d->mm);
> +
> switch (ioctl) {
> case VHOST_SET_VRING_NUM:
> /* Resizing ring with an active backend?
> @@ -1498,6 +1777,7 @@ long vhost_vring_ioctl(struct vhost_dev *d, unsigned int ioctl, void __user *arg
> r = -EINVAL;
> break;
> }
> + vhost_clean_vmaps(vq);
> vq->num = s.num;
> break;
> case VHOST_SET_VRING_BASE:
> @@ -1575,6 +1855,8 @@ long vhost_vring_ioctl(struct vhost_dev *d, unsigned int ioctl, void __user *arg
> }
> }
>
> + vhost_clean_vmaps(vq);
> +
> vq->log_used = !!(a.flags & (0x1 << VHOST_VRING_F_LOG));
> vq->desc = (void __user *)(unsigned long)a.desc_user_addr;
> vq->avail = (void __user *)(unsigned long)a.avail_user_addr;
> @@ -1655,6 +1937,8 @@ long vhost_vring_ioctl(struct vhost_dev *d, unsigned int ioctl, void __user *arg
> if (pollstart && vq->handle_kick)
> r = vhost_poll_start(&vq->poll, vq->kick);
>
> + if (d->mm)
> + mmu_notifier_register(&d->mmu_notifier, d->mm);
> mutex_unlock(&vq->mutex);
>
> if (pollstop && vq->handle_kick)
> diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
> index 4e21011b6628..c04bc327db9f 100644
> --- a/drivers/vhost/vhost.h
> +++ b/drivers/vhost/vhost.h
> @@ -12,6 +12,8 @@
> #include <linux/virtio_config.h>
> #include <linux/virtio_ring.h>
> #include <linux/atomic.h>
> +#include <linux/pagemap.h>
> +#include <linux/mmu_notifier.h>
>
> struct vhost_work;
> typedef void (*vhost_work_fn_t)(struct vhost_work *work);
> @@ -80,6 +82,11 @@ enum vhost_uaddr_type {
> VHOST_NUM_ADDRS = 3,
> };
>
> +struct vhost_vmap {
> + void *addr;
> + void *unmap_addr;
> +};
> +
> /* The virtqueue structure describes a queue attached to a device. */
> struct vhost_virtqueue {
> struct vhost_dev *dev;
> @@ -90,6 +97,11 @@ struct vhost_virtqueue {
> struct vring_desc __user *desc;
> struct vring_avail __user *avail;
> struct vring_used __user *used;
> +
> + struct vhost_vmap avail_ring;
> + struct vhost_vmap desc_ring;
> + struct vhost_vmap used_ring;
> +
> const struct vhost_umem_node *meta_iotlb[VHOST_NUM_ADDRS];
> struct file *kick;
> struct eventfd_ctx *call_ctx;
> @@ -158,6 +170,7 @@ struct vhost_msg_node {
>
> struct vhost_dev {
> struct mm_struct *mm;
> + struct mmu_notifier mmu_notifier;
> struct mutex mutex;
> struct vhost_virtqueue **vqs;
> int nvqs;
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 6ece1e2fe76e..745e7c7f7a6c 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -237,6 +237,7 @@ bool vma_is_shmem(struct vm_area_struct *vma)
> {
> return vma->vm_ops == &shmem_vm_ops;
> }
> +EXPORT_SYMBOL_GPL(vma_is_shmem);
>
> static LIST_HEAD(shmem_swaplist);
> static DEFINE_MUTEX(shmem_swaplist_mutex);
> --
> 2.17.1
^ permalink raw reply
* Re: [PATCH net-next V4 5/5] vhost: access vq metadata through kernel virtual address
From: Michael S. Tsirkin @ 2019-01-25 3:00 UTC (permalink / raw)
To: Jason Wang; +Cc: virtualization, netdev, linux-kernel, kvm
In-Reply-To: <335ba55b-087f-4b35-6311-540070b9647f@redhat.com>
On Thu, Jan 24, 2019 at 12:07:54PM +0800, Jason Wang wrote:
> > Meanwhile, could you pls post data comparing this last patch with the
> > below? This removes the speculation barrier replacing it with a
> > (useless but at least more lightweight) data dependency.
>
>
> SMAP off
>
> Your patch: 7.2MPPs
>
> vmap: 7.4Mpps
OK so while we keep looking into vmap, why don't we merge something like
the below? Seems quite straight forward ...
> I don't test SMAP on, since it will be much slow for sure.
>
> Thanks
>
>
> >
> > Thanks!
> >
> >
> > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > index bac939af8dbb..352ee7e14476 100644
> > --- a/drivers/vhost/vhost.c
> > +++ b/drivers/vhost/vhost.c
> > @@ -739,7 +739,7 @@ static int vhost_copy_to_user(struct vhost_virtqueue *vq, void __user *to,
> > int ret;
> > if (!vq->iotlb)
> > - return __copy_to_user(to, from, size);
> > + return copy_to_user(to, from, size);
> > else {
> > /* This function should be called after iotlb
> > * prefetch, which means we're sure that all vq
> > @@ -752,7 +752,7 @@ static int vhost_copy_to_user(struct vhost_virtqueue *vq, void __user *to,
> > VHOST_ADDR_USED);
> > if (uaddr)
> > - return __copy_to_user(uaddr, from, size);
> > + return copy_to_user(uaddr, from, size);
> > ret = translate_desc(vq, (u64)(uintptr_t)to, size, vq->iotlb_iov,
> > ARRAY_SIZE(vq->iotlb_iov),
> > @@ -774,7 +774,7 @@ static int vhost_copy_from_user(struct vhost_virtqueue *vq, void *to,
> > int ret;
> > if (!vq->iotlb)
> > - return __copy_from_user(to, from, size);
> > + return copy_from_user(to, from, size);
> > else {
> > /* This function should be called after iotlb
> > * prefetch, which means we're sure that vq
> > @@ -787,7 +787,7 @@ static int vhost_copy_from_user(struct vhost_virtqueue *vq, void *to,
> > struct iov_iter f;
> > if (uaddr)
> > - return __copy_from_user(to, uaddr, size);
> > + return copy_from_user(to, uaddr, size);
> > ret = translate_desc(vq, (u64)(uintptr_t)from, size, vq->iotlb_iov,
> > ARRAY_SIZE(vq->iotlb_iov),
> > @@ -855,13 +855,13 @@ static inline void __user *__vhost_get_user(struct vhost_virtqueue *vq,
> > ({ \
> > int ret = -EFAULT; \
> > if (!vq->iotlb) { \
> > - ret = __put_user(x, ptr); \
> > + ret = put_user(x, ptr); \
> > } else { \
> > __typeof__(ptr) to = \
> > (__typeof__(ptr)) __vhost_get_user(vq, ptr, \
> > sizeof(*ptr), VHOST_ADDR_USED); \
> > if (to != NULL) \
> > - ret = __put_user(x, to); \
> > + ret = put_user(x, to); \
> > else \
> > ret = -EFAULT; \
> > } \
> > @@ -872,14 +872,14 @@ static inline void __user *__vhost_get_user(struct vhost_virtqueue *vq,
> > ({ \
> > int ret; \
> > if (!vq->iotlb) { \
> > - ret = __get_user(x, ptr); \
> > + ret = get_user(x, ptr); \
> > } else { \
> > __typeof__(ptr) from = \
> > (__typeof__(ptr)) __vhost_get_user(vq, ptr, \
> > sizeof(*ptr), \
> > type); \
> > if (from != NULL) \
> > - ret = __get_user(x, from); \
> > + ret = get_user(x, from); \
> > else \
> > ret = -EFAULT; \
> > } \
^ 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