* Re: [GIT] Networking
From: Greg KH @ 2018-09-25 9:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20180924.203224.1604558581746424370.davem@davemloft.net>
On Mon, Sep 24, 2018 at 08:32:24PM -0700, David Miller wrote:
>
> 1) Fix multiqueue handling of coalesce timer in stmmac, from Jose
> Abreu.
>
> 2) Fix memory corruption in NFC, from Suren Baghdasaryan.
>
> 3) Don't write reserved bits in ravb driver, from Kazuya Mizuguchi.
>
> 4) SMC bug fixes from Karsten Graul, YueHaibing, and Ursula Braun.
>
> 5) Fix TX done race in mvpp2, from Antoine Tenart.
>
> 6) ipv6 metrics leak, from Wei Wang.
>
> 7) Adjust firmware version requirements in mlxsw, from Petr Machata.
>
> 8) Fix autonegotiation on resume in r8169, from Heiner Kallweit.
>
> 9) Fixed missing entries when dumping /proc/net/if_inet6, from Jeff
> Barnhill.
>
> 10) Fix double free in devlink, from Dan Carpenter.
>
> 11) Fix ethtool regression from UFO feature removal, from Maciej
> Żenczykowski.
>
> 12) Fix drivers that have a ndo_poll_controller() that captures the
> cpu entirely on loaded hosts by trying to drain all rx and tx
> queues, from Eric Dumazet.
>
> 13) Fix memory corruption with jumbo frames in aquantia driver, from
> Friedemann Gerold.
>
> Please pull, thanks a lot!
>
> The following changes since commit 5211da9ca526a5adddee1ccd078e6e33a583ab36:
>
> Merge gitolite.kernel.org:/pub/scm/linux/kernel/git/davem/net (2018-09-18 09:31:53 +0200)
>
> are available in the Git repository at:
>
> gitolite@ra.kernel.org:/pub/scm/linux/kernel/git/davem/net.git
Now pulled, thanks.
greg k-h
^ permalink raw reply
* Re: r8169 hang on 4.18
From: Ortwin Glück @ 2018-09-25 9:53 UTC (permalink / raw)
To: Heiner Kallweit, linux-kernel@vger.kernel.org, netdev
In-Reply-To: <680acec6-f610-7f9d-5aa2-a03e878354d1@gmail.com>
On 24.09.18 22:21, Heiner Kallweit wrote:
> Thanks for the report. Here come a few inquiries:
>
> You say the box has one on-board network port and four network ports on
> an extension card, all five driven by r8169. The on-board chip is a
> RTL8168h, what's the type of the chips on the extension card?
This is the card:
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express
Gigabit Ethernet Controller [10ec:8168] (rev 0c)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet
Controller [10ec:0123]
Flags: bus master, fast devsel, latency 0, IRQ 17
I/O ports at d000 [size=256]
Memory at f7300000 (64-bit, non-prefetchable) [size=4K]
Memory at f0300000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Capabilities: [d0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
Capabilities: [170] Latency Tolerance Reporting
Kernel driver in use: r8169
04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express
Gigabit Ethernet Controller [10ec:8168] (rev 0c)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet
Controller [10ec:0123]
Flags: bus master, fast devsel, latency 0, IRQ 18
I/O ports at c000 [size=256]
Memory at f7200000 (64-bit, non-prefetchable) [size=4K]
Memory at f0200000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Capabilities: [d0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
Capabilities: [170] Latency Tolerance Reporting
Kernel driver in use: r8169
05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express
Gigabit Ethernet Controller [10ec:8168] (rev 0c)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet
Controller [10ec:0123]
Flags: bus master, fast devsel, latency 0, IRQ 19
I/O ports at b000 [size=256]
Memory at f7100000 (64-bit, non-prefetchable) [size=4K]
Memory at f0100000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Capabilities: [d0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
Capabilities: [170] Latency Tolerance Reporting
Kernel driver in use: r8169
06:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express
Gigabit Ethernet Controller [10ec:8168] (rev 0c)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet
Controller [10ec:0123]
Flags: bus master, fast devsel, latency 0, IRQ 16
I/O ports at a000 [size=256]
Memory at f7000000 (64-bit, non-prefetchable) [size=4K]
Memory at f0000000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Capabilities: [d0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
Capabilities: [170] Latency Tolerance Reporting
Kernel driver in use: r8169
> I'm asking because r8169 supports ~ 50 chip variants of the RTL8169/8
> family.
> Are the problems the same on all five ports?
Yes, I see the WARN_ON also on the other ports. Here is one from the separate card:
[Mon Sep 24 15:47:21 2018] ------------[ cut here ]------------
[Mon Sep 24 15:47:21 2018] NETDEV WATCHDOG: lan (r8169): transmit queue 0 timed out
[Mon Sep 24 15:47:21 2018] WARNING: CPU: 2 PID: 0 at net/sched/sch_generic.c:461
dev_watchdog+0x215/0x220
[Mon Sep 24 15:47:21 2018] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.18.8 #70
[Mon Sep 24 15:47:21 2018] Hardware name: Dell Inc. OptiPlex 3050/0W0CHX, BIOS 1.6.5 09/09/2017
[Mon Sep 24 15:47:21 2018] RIP: 0010:dev_watchdog+0x215/0x220
[Mon Sep 24 15:47:21 2018] Code: 49 63 4c 24 e8 eb 8c 4c 89 ef c6 05 1a 19 ca 00 01 e8 5f 52 fd ff
89 d9 4c 89 ee 48 c7 c7 78 ab 67 af 48 89 c2 e8 1b 2b 49 ff <0f> 0b eb be 0f 1f 80 00 00 00 00 41 57
45 89 cf 41 56 49 89 d6 41
[Mon Sep 24 15:47:21 2018] RSP: 0018:ffff8a205dd03e98 EFLAGS: 00010282
[Mon Sep 24 15:47:21 2018] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
[Mon Sep 24 15:47:21 2018] RDX: 0000000000000007 RSI: 0000000000000096 RDI: ffff8a205dd15350
[Mon Sep 24 15:47:21 2018] RBP: ffff8a2045de041c R08: 0000000000000001 R09: 0000000000000763
[Mon Sep 24 15:47:21 2018] R10: 0000000000000082 R11: 0000000000000000 R12: ffff8a2045de0438
[Mon Sep 24 15:47:21 2018] R13: ffff8a2045de0000 R14: 0000000000000001 R15: ffff8a20455e1480
[Mon Sep 24 15:47:21 2018] FS: 0000000000000000(0000) GS:ffff8a205dd00000(0000) knlGS:0000000000000000
[Mon Sep 24 15:47:21 2018] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[Mon Sep 24 15:47:21 2018] CR2: 00007ff598642c38 CR3: 000000001f80a004 CR4: 00000000003606e0
[Mon Sep 24 15:47:21 2018] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[Mon Sep 24 15:47:21 2018] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[Mon Sep 24 15:47:21 2018] Call Trace:
[Mon Sep 24 15:47:21 2018] <IRQ>
[Mon Sep 24 15:47:21 2018] ? pfifo_fast_reset+0x130/0x130
[Mon Sep 24 15:47:21 2018] ? pfifo_fast_reset+0x130/0x130
[Mon Sep 24 15:47:21 2018] call_timer_fn+0x11/0x70
[Mon Sep 24 15:47:21 2018] expire_timers+0x8e/0xa0
[Mon Sep 24 15:47:21 2018] run_timer_softirq+0xb9/0x160
[Mon Sep 24 15:47:21 2018] ? __hrtimer_run_queues+0x135/0x1a0
[Mon Sep 24 15:47:21 2018] ? hw_breakpoint_pmu_read+0x10/0x10
[Mon Sep 24 15:47:21 2018] ? ktime_get+0x39/0x90
[Mon Sep 24 15:47:21 2018] ? lapic_next_event+0x20/0x20
[Mon Sep 24 15:47:21 2018] __do_softirq+0xcb/0x1f8
[Mon Sep 24 15:47:21 2018] irq_exit+0xa9/0xb0
[Mon Sep 24 15:47:21 2018] smp_apic_timer_interrupt+0x59/0x90
[Mon Sep 24 15:47:21 2018] apic_timer_interrupt+0xf/0x20
[Mon Sep 24 15:47:21 2018] </IRQ>
[Mon Sep 24 15:47:21 2018] RIP: 0010:cpuidle_enter_state+0x129/0x200
[Mon Sep 24 15:47:21 2018] Code: 45 00 89 c3 e8 d8 3b 55 ff 65 8b 3d b1 eb 45 51 e8 8c 3a 55 ff 31
ff 49 89 c4 e8 72 43 55 ff fb 48 ba cf f7 53 e3 a5 9b c4 20 <4c> 89 e1 4c 29 e9 48 89 c8 48 c1 f9 3f
48 f7 ea b8 ff ff ff 7f 48
[Mon Sep 24 15:47:21 2018] RSP: 0018:ffff9f46806e7ea8 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
[Mon Sep 24 15:47:21 2018] RAX: ffff8a205dd1f800 RBX: 0000000000000004 RCX: 000000000000001f
[Mon Sep 24 15:47:21 2018] RDX: 20c49ba5e353f7cf RSI: 00000000258f0602 RDI: 0000000000000000
[Mon Sep 24 15:47:21 2018] RBP: ffff8a205dd25ee0 R08: 00000000000003ee R09: 00000000ffffffff
[Mon Sep 24 15:47:21 2018] R10: ffff9f46806e7e90 R11: 00000000000003d5 R12: 00000752028ec2d0
[Mon Sep 24 15:47:21 2018] R13: 000007520282ea18 R14: 0000000000000004 R15: 0000000000000000
[Mon Sep 24 15:47:21 2018] ? cpuidle_enter_state+0x11e/0x200
[Mon Sep 24 15:47:21 2018] do_idle+0x1c0/0x200
[Mon Sep 24 15:47:21 2018] cpu_startup_entry+0x6a/0x70
[Mon Sep 24 15:47:21 2018] start_secondary+0x18a/0x1c0
[Mon Sep 24 15:47:21 2018] secondary_startup_64+0xa5/0xb0
[Mon Sep 24 15:47:21 2018] ---[ end trace 7ea59db719c41930 ]---
[Mon Sep 24 15:47:21 2018] r8169 0000:06:00.0 lan: link up
> Can you reproduce the problem (how)? Any specific network usage
> triggering the problem?
Actually the WARN_ON seems not to be causing the hang but to be rather a side effect of an
"unstable" port. The WARN_ON occurs every few days but the port works fine most of the time. But
when the port hangs (no more traffic) only a reboot fixes it.
These looks suspicious:
[ 8048.829832] r8169 0000:06:00.0 lan: link up
[64114.535455] r8169 0000:07:00.0 wan: link up
[74726.396319] r8169 0000:07:00.0 wan: link up
The ports seem to go up at random times (without "link down" message). This is also what we saw with
MSI enabled: links thrashing in down/up cycles.
> The root cause of the problem not necessarily is in r8169, some other
> change could have broken it too. Can you test using r8169 from 4.18
> on top of 4.17?
Unfortunately I am not able to do that.
> When stating "behaves erratic" you refer to the network hangs
> mentioned before? Or to some other issue?
please see above: links thrashing in down/up cycles.
I see that MSI/MSI-X has been disabled on quite a few chip versions (e.g. lately commit 72a579b8).
Does pci=nomsi disable MSI-X as well, or just MSI?
I could try adding my chip versions to these quirk sections. I couldn't find a way to disable
MSI/MSI-X per device.
> A similar report is here:
> https://bugzilla.kernel.org/show_bug.cgi?id=201109
Also that report has the "link up" message after the WARN_ON.
> There the problem seems to start with the upgrade from 4.18.4 to 4.18.5.
> Can you try with 4.18.4 ?
>
> The diff between 4.18.4 and 4.18.5 shows nothing related to r8169.
Exactly. I think the incident is just so rare that correlating it with a specific upgrade is hard.
Thanks,
Ortwin
^ permalink raw reply
* Re: [PATCH v2 net-next 9/9] devlink: Add Documentation/networking/devlink-params-bnxt.txt
From: Vasundhara Volam @ 2018-09-25 4:07 UTC (permalink / raw)
To: jakub.kicinski; +Cc: David Miller, michael.chan@broadcom.com, Netdev
In-Reply-To: <20180924092406.539fc54f@cakuba.netronome.com>
On Mon, Sep 24, 2018 at 9:54 PM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> On Mon, 24 Sep 2018 10:46:21 +0530, Vasundhara Volam wrote:
> > This patch adds a new file to add information about configuration
> > parameters that are supported by bnxt_en driver via devlink.
> >
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: Jonathan Corbet <corbet@lwn.net>
> > Cc: linux-doc@vger.kernel.org
> > Cc: Jiri Pirko <jiri@mellanox.com>
> > Cc: Michael Chan <michael.chan@broadcom.com>
> >
> > Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
> > ---
> > Documentation/networking/devlink-params-bnxt.txt | 35 ++++++++++++++++++++++++
> > 1 file changed, 35 insertions(+)
> > create mode 100644 Documentation/networking/devlink-params-bnxt.txt
> >
> > diff --git a/Documentation/networking/devlink-params-bnxt.txt b/Documentation/networking/devlink-params-bnxt.txt
> > new file mode 100644
> > index 0000000..ca7c457
> > --- /dev/null
> > +++ b/Documentation/networking/devlink-params-bnxt.txt
> > @@ -0,0 +1,35 @@
> > +enable_sriov [DEVICE, GENERIC]
> > + Enable Single Root I/O Virtualisation (SRIOV) in
> > + the device.
> > + Type: Boolean
> > + Configuration mode: Permanent
> > +
> > +ignore_ari [DEVICE, GENERIC]
> > + Ignore Alternative Routing-ID Interpretation (ARI)
> > + capability. If enabled, adapter will ignore ARI
> > + capability even when platforms has the support
> > + enabled and creates same number of partitions when
> > + platform does not support ARI.
> > + Type: Boolean
> > + Configuration mode: Permanent
> > +
> > +msix_vec_per_pf_max [DEVICE, GENERIC]
> > + Provides the maximum number of MSIX interrupts that
> > + a device can create. Value is same across all
> > + physical functions (PFs) in the device.
> > + Type: u32
> > + Configuration mode: Permanent
> > +
> > +msix_vec_per_pf_min [DEVICE, GENERIC]
> > + Provides the minimum number of MSIX interrupts required
> > + or the device initialization. Value is same across all
> > + physical functions (PFs) in the device.
> > + Type: u32
> > + Configuration mode: Permanent
>
> Why duplicate the description of the generic parameters?
Not all generic parameters are used by all drivers. So, I want to add
information about
type and configuration mode about generic parameters used by bnxt_en driver.
I can remove description part keeping type and configuration mode, if
it looks duplication.
>
> > +gre_ver_check [DEVICE, DRIVER-SPECIFIC]
> > + Generic Routing Encapsulation (GRE) version check will
> > + be enabled in the device. If disabled, device skips
> > + version checking for incoming packets.
> > + Type: Boolean
> > + Configuration mode: Permanent
>
^ permalink raw reply
* Re: [PATCH v2 net-next 0/9] bnxt_en: devlink param updates
From: Vasundhara Volam @ 2018-09-25 4:14 UTC (permalink / raw)
To: jakub.kicinski; +Cc: David Miller, michael.chan@broadcom.com, Netdev
In-Reply-To: <20180924093908.157f3ea2@cakuba.netronome.com>
On Mon, Sep 24, 2018 at 10:11 PM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> On Mon, 24 Sep 2018 10:46:12 +0530, Vasundhara Volam wrote:
> > This patchset adds support for 3 generic and 1 driver-specific devlink
> > parameters. Add documentation for these configuration parameters.
> >
> > Also, this patchset adds support to return proper error code if
> > HWRM_NVM_GET/SET_VARIABLE commands return error code
> > HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED.
> >
> > v1->v2:
> > -Remove hw_tc_offload parameter.
> > -Update all patches with Cc of MAINTAINERS.
> > -Add more description in commit message for device specific parameter.
> > -Add a new Documentation/networking/devlink-params.txt with some
> > generic devlink parameters information.
> > -Add a new Documentation/networking/devlink-params-bnxt_en.txt with devlink
> > parameters information that are supported by bnxt_en driver.
> >
> > Vasundhara Volam (9):
> > devlink: Add generic parameter ignore_ari
> > devlink: Add generic parameter msix_vec_per_pf_max
> > devlink: Add generic parameter msix_vec_per_pf_min
>
> Nobody agreed with me that we need structure the PCIe bits better so
> I'll let go...
>
> > bnxt_en: Use ignore_ari devlink parameter
> > bnxt_en: return proper error when FW returns
> > HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED
> > bnxt_en: Use msix_vec_per_pf_max and msix_vec_per_pf_min devlink
> > params.
> > bnxt_en: Add a driver specific gre_ver_check devlink parameter.
>
> This looks like configuring forwarding rules with devlink, but again,
Do you think, this parameter should be made generic?
> I won't object if I'm the only one who finds this inappropriate.
>
> You should CC people who gave you feedback on the previous version.
Sorry, I will add in the next version of the patchset. Thanks.
>
> > devlink: Add Documentation/networking/devlink-params.txt
> > devlink: Add Documentation/networking/devlink-params-bnxt.txt
^ permalink raw reply
* Re: [PATCH net-next v5 02/20] zinc: introduce minimal cryptography library
From: Ard Biesheuvel @ 2018-09-25 10:25 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Linux Kernel Mailing List, <netdev@vger.kernel.org>,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, David S. Miller,
Greg Kroah-Hartman, Samuel Neves, Andy Lutomirski,
Jean-Philippe Aumasson
In-Reply-To: <20180918161646.19105-3-Jason@zx2c4.com>
Hi Jason,
I have another couple of questions which are unrelated to the below,
so I will just respond again to the top message.
On Tue, 18 Sep 2018 at 18:18, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Zinc stands for "Zinc Is Neat Crypto" or "Zinc as IN Crypto" or maybe
> just "Zx2c4's INsane Cryptolib." It's also short, easy to type, and
> plays nicely with the recent trend of naming crypto libraries after
> elements. The guiding principle is "don't overdo it". It's less of a
> library and more of a directory tree for organizing well-curated direct
> implementations of cryptography primitives.
>
Kees is currently dealing with VLA uses in crypto API skcipher
invocations [0] that don't benefit from its async capabilities nor
from the runtime resolution of cipher name strings, given that they
always select the same one.
drivers/net/ppp/ppp_mppe.c: "ecb(arc4)"
drivers/usb/wusbcore/crypto.c: "cbc(aes)"
net/ceph/crypto.c: "cbc(aes)"
net/mac802154/llsec.c: "ctr(aes)"
net/rxrpc/rxkad.c: "pcbc(fcrypt)"
net/rxrpc/rxkad.c: "pcbc(fcrypt)"
net/sunrpc/auth_gss/gss_krb5_mech.c: "cbc(des)"
net/sunrpc/auth_gss/gss_krb5_mech.c: "ecb(arc4)"
net/sunrpc/auth_gss/gss_krb5_mech.c: "cbc(des3_ede)"
net/sunrpc/auth_gss/gss_krb5_mech.c: "cts(cbc(aes))"
net/sunrpc/auth_gss/gss_krb5_mech.c: "cts(cbc(aes))"
net/wireless/lib80211_crypt_tkip.c: "ecb(arc4)"
net/wireless/lib80211_crypt_wep.c: "ecb(arc4)"
To me, these are prime candidates for moving into your library [at
some point]. I guess AES should be non-controversial, but moving the
others is actually more important in my view, since we will be able to
stop exposing them via the crypto API in that case. Any thoughts?
> [From 00/20] ..., WireGuard patches will go through
> DaveM's net-next tree, while Zinc patches will go through Greg KH's tree.
>
Given the cross dependencies, I'd prefer it if we take these through
Herbert's tree [which feeds into DaveM's tree as well].
Also, you haven't yet responded to my question about WireGuard's
limitation to synchronous encryption, or whether and how you expect to
support asynchronous accelerators for ChaCha20/Poly1305 in the future.
This shouldn't impede adoption of this series, but this is something
that is going to come up sooner than you think, and so I would like to
understand whether this means your library will grow asynchronous
interfaces as well, or whether it will be moved to the crypto API.
(Also, I'd like to know whether the RFC7539 construction of ChaCha20
and Poly1305 is compatible with WireGuard's)
Thanks,
Ard.
[0] https://marc.info/?l=linux-kernel&m=153732317132090&w=2
> Zinc is a new cryptography API that is much more minimal and lower-level
> than the current one. It intends to complement it and provide a basis
> upon which the current crypto API might build, as the provider of
> software implementations of cryptographic primitives. It is motivated by
> three primary observations in crypto API design:
>
> * Highly composable "cipher modes" and related abstractions from
> 90s cryptographers did not turn out to be as terrific an idea as
> hoped, leading to a host of API misuse problems.
>
> * Most programmers are afraid of crypto code, and so prefer to
> integrate it into libraries in a highly abstracted manner, so as to
> shield themselves from implementation details. Cryptographers, on
> the other hand, prefer simple direct implementations, which they're
> able to verify for high assurance and optimize in accordance with
> their expertise.
>
> * Overly abstracted and flexible cryptography APIs lead to a host of
> dangerous problems and performance issues. The kernel is in the
> business usually not of coming up with new uses of crypto, but
> rather implementing various constructions, which means it essentially
> needs a library of primitives, not a highly abstracted enterprise-ready
> pluggable system, with a few particular exceptions.
>
> This last observation has seen itself play out several times over and
> over again within the kernel:
>
> * The perennial move of actual primitives away from crypto/ and into
> lib/, so that users can actually call these functions directly with
> no overhead and without lots of allocations, function pointers,
> string specifier parsing, and general clunkiness. For example:
> sha256, chacha20, siphash, sha1, and so forth live in lib/ rather
> than in crypto/. Zinc intends to stop the cluttering of lib/ and
> introduce these direct primitives into their proper place, lib/zinc/.
>
> * An abundance of misuse bugs with the present crypto API that have
> been very unpleasant to clean up.
>
> * A hesitance to even use cryptography, because of the overhead and
> headaches involved in accessing the routines.
>
> Zinc goes in a rather different direction. Rather than providing a
> thoroughly designed and abstracted API, Zinc gives you simple functions,
> which implement some primitive, or some particular and specific
> construction of primitives. It is not dynamic in the least, though one
> could imagine implementing a complex dynamic dispatch mechanism (such as
> the current crypto API) on top of these basic functions. After all,
> dynamic dispatch is usually needed for applications with cipher agility,
> such as IPsec, dm-crypt, AF_ALG, and so forth, and the existing crypto
> API will continue to play that role. However, Zinc will provide a non-
> haphazard way of directly utilizing crypto routines in applications
> that do have neither the need nor desire for abstraction and dynamic
> dispatch.
>
> It also organizes the implementations in a simple, straight-forward,
> and direct manner, making it enjoyable and intuitive to work on.
> Rather than moving optimized assembly implementations into arch/, it
> keeps them all together in lib/zinc/, making it simple and obvious to
> compare and contrast what's happening. This is, notably, exactly what
> the lib/raid6/ tree does, and that seems to work out rather well. It's
> also the pattern of most successful crypto libraries. The architecture-
> specific glue-code is made a part of each translation unit, rather than
> being in a separate one, so that generic and architecture-optimized code
> are combined at compile-time, and incompatibility branches compiled out by
> the optimizer.
>
> All implementations have been extensively tested and fuzzed, and are
> selected for their quality, trustworthiness, and performance. Wherever
> possible and performant, formally verified implementations are used,
> such as those from HACL* [1] and Fiat-Crypto [2]. The routines also take
> special care to zero out secrets using memzero_explicit (and future work
> is planned to have gcc do this more reliably and performantly with
> compiler plugins). The performance of the selected implementations is
> state-of-the-art and unrivaled on a broad array of hardware, though of
> course we will continue to fine tune these to the hardware demands
> needed by kernel contributors. Each implementation also comes with
> extensive self-tests and crafted test vectors, pulled from various
> places such as Wycheproof [9].
>
> Regularity of function signatures is important, so that users can easily
> "guess" the name of the function they want. Though, individual
> primitives are oftentimes not trivially interchangeable, having been
> designed for different things and requiring different parameters and
> semantics, and so the function signatures they provide will directly
> reflect the realities of the primitives' usages, rather than hiding it
> behind (inevitably leaky) abstractions. Also, in contrast to the current
> crypto API, Zinc functions can work on stack buffers, and can be called
> with different keys, without requiring allocations or locking.
>
> SIMD is used automatically when available, though some routines may
> benefit from either having their SIMD disabled for particular
> invocations, or to have the SIMD initialization calls amortized over
> several invocations of the function, and so Zinc utilizes function
> signatures enabling that in conjunction with the recently introduced
> simd_context_t.
>
> More generally, Zinc provides function signatures that allow just what
> is required by the various callers. This isn't to say that users of the
> functions will be permitted to pollute the function semantics with weird
> particular needs, but we are trying very hard not to overdo it, and that
> means looking carefully at what's actually necessary, and doing just that,
> and not much more than that. Remember: practicality and cleanliness rather
> than over-zealous infrastructure.
>
> Zinc provides also an opening for the best implementers in academia to
> contribute their time and effort to the kernel, by being sufficiently
> simple and inviting. In discussing this commit with some of the best and
> brightest over the last few years, there are many who are eager to
> devote rare talent and energy to this effort.
>
> Following the merging of this, I expect for the primitives that
> currently exist in lib/ to work their way into lib/zinc/, after intense
> scrutiny of each implementation, potentially replacing them with either
> formally-verified implementations, or better studied and faster
> state-of-the-art implementations.
>
> Also following the merging of this, I expect for the old crypto API
> implementations to be ported over to use Zinc for their software-based
> implementations.
>
> As Zinc is simply library code, its config options are un-menued, with
> the exception of CONFIG_ZINC_DEBUG, which enables various selftests and
> BUG_ONs.
>
> [1] https://github.com/project-everest/hacl-star
> [2] https://github.com/mit-plv/fiat-crypto
> [3] https://cr.yp.to/ecdh.html
> [4] https://cr.yp.to/chacha.html
> [5] https://cr.yp.to/snuffle/xsalsa-20081128.pdf
> [6] https://cr.yp.to/mac.html
> [7] https://blake2.net/
> [8] https://tools.ietf.org/html/rfc8439
> [9] https://github.com/google/wycheproof
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> Cc: Samuel Neves <sneves@dei.uc.pt>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
> ---
> MAINTAINERS | 8 ++++++++
> lib/Kconfig | 2 ++
> lib/Makefile | 2 ++
> lib/zinc/Kconfig | 32 ++++++++++++++++++++++++++++++++
> lib/zinc/Makefile | 4 ++++
> 5 files changed, 48 insertions(+)
> create mode 100644 lib/zinc/Kconfig
> create mode 100644 lib/zinc/Makefile
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4327777dce57..5967c737f3ce 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16170,6 +16170,14 @@ Q: https://patchwork.linuxtv.org/project/linux-media/list/
> S: Maintained
> F: drivers/media/dvb-frontends/zd1301_demod*
>
> +ZINC CRYPTOGRAPHY LIBRARY
> +M: Jason A. Donenfeld <Jason@zx2c4.com>
> +M: Samuel Neves <sneves@dei.uc.pt>
> +S: Maintained
> +F: lib/zinc/
> +F: include/zinc/
> +L: linux-crypto@vger.kernel.org
> +
> ZPOOL COMPRESSED PAGE STORAGE API
> M: Dan Streetman <ddstreet@ieee.org>
> L: linux-mm@kvack.org
> diff --git a/lib/Kconfig b/lib/Kconfig
> index a3928d4438b5..3e6848269c66 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -485,6 +485,8 @@ config GLOB_SELFTEST
> module load) by a small amount, so you're welcome to play with
> it, but you probably don't need it.
>
> +source "lib/zinc/Kconfig"
> +
> #
> # Netlink attribute parsing support is select'ed if needed
> #
> diff --git a/lib/Makefile b/lib/Makefile
> index ca3f7ebb900d..571d28d3f143 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -214,6 +214,8 @@ obj-$(CONFIG_PERCPU_TEST) += percpu_test.o
>
> obj-$(CONFIG_ASN1) += asn1_decoder.o
>
> +obj-y += zinc/
> +
> obj-$(CONFIG_FONT_SUPPORT) += fonts/
>
> obj-$(CONFIG_PRIME_NUMBERS) += prime_numbers.o
> diff --git a/lib/zinc/Kconfig b/lib/zinc/Kconfig
> new file mode 100644
> index 000000000000..4e2e59126a67
> --- /dev/null
> +++ b/lib/zinc/Kconfig
> @@ -0,0 +1,32 @@
> +config ZINC_DEBUG
> + bool "Zinc cryptography library debugging and self-tests"
> + help
> + This builds a series of self-tests for the Zinc crypto library, which
> + help diagnose any cryptographic algorithm implementation issues that
> + might be at the root cause of potential bugs. It also adds various
> + debugging traps.
> +
> + Unless you're developing and testing cryptographic routines, or are
> + especially paranoid about correctness on your hardware, you may say
> + N here.
> +
> +config ZINC_ARCH_ARM
> + def_bool y
> + depends on ARM && !64BIT
> +
> +config ZINC_ARCH_ARM64
> + def_bool y
> + depends on ARM64 && 64BIT
> +
> +config ZINC_ARCH_X86_64
> + def_bool y
> + depends on X86_64 && 64BIT
> + depends on !UML
> +
> +config ZINC_ARCH_MIPS
> + def_bool y
> + depends on MIPS && CPU_MIPS32_R2 && !64BIT
> +
> +config ZINC_ARCH_MIPS64
> + def_bool y
> + depends on MIPS && 64BIT
> diff --git a/lib/zinc/Makefile b/lib/zinc/Makefile
> new file mode 100644
> index 000000000000..83dfd63988c0
> --- /dev/null
> +++ b/lib/zinc/Makefile
> @@ -0,0 +1,4 @@
> +ccflags-y := -O3
> +ccflags-y += -Wframe-larger-than=$(if (CONFIG_KASAN),16384,8192)
> +ccflags-y += -D'pr_fmt(fmt)="zinc: " fmt'
> +ccflags-$(CONFIG_ZINC_DEBUG) += -DDEBUG
> --
> 2.19.0
>
^ permalink raw reply
* Re: [PATCH v2 2/7] include: add setbits32/clrbits32/clrsetbits32/setbits64/clrbits64/clrsetbits64 in linux/setbits.h
From: Christophe LEROY @ 2018-09-25 5:05 UTC (permalink / raw)
To: Corentin Labbe, Gilles.Muller, Julia.Lawall, agust, airlied,
alexandre.torgue, alistair, benh, carlo, davem, galak, joabreu,
khilman, maxime.ripard, michal.lkml, mpe, mporter, narmstrong,
nicolas.palix, oss, paulus, peppe.cavallaro, tj, vitb, wens
Cc: netdev, linux-kernel, dri-devel, linux-ide, linux-amlogic,
linuxppc-dev, cocci, linux-arm-kernel
In-Reply-To: <1537815856-31728-3-git-send-email-clabbe@baylibre.com>
Le 24/09/2018 à 21:04, Corentin Labbe a écrit :
> This patch adds setbits32/clrbits32/clrsetbits32 and
> setbits64/clrbits64/clrsetbits64 in linux/setbits.h header.
Fix the patch subject and description.
>
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
> ---
> include/linux/setbits.h | 88 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 88 insertions(+)
> create mode 100644 include/linux/setbits.h
>
> diff --git a/include/linux/setbits.h b/include/linux/setbits.h
> new file mode 100644
> index 000000000000..6e7e257134ae
> --- /dev/null
> +++ b/include/linux/setbits.h
> @@ -0,0 +1,88 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __LINUX_SETBITS_H
> +#define __LINUX_SETBITS_H
> +
> +#include <linux/io.h>
> +
> +#define __setbits(readfunction, writefunction, addr, set) \
> + writefunction((readfunction(addr) | (set)), addr)
You don't need so long names for parameters in a 2 lines macro (See
Linux Kernel Codying style §4 Naming).
A single line macro would be feasible with only 3 chars names:
#define __setbits(rfn, wfn, addr, set) wfn((rfn(addr) | (set)), addr)
> +#define __clrbits(readfunction, writefunction, addr, mask) \
> + writefunction((readfunction(addr) & ~(mask)), addr)
> +#define __clrsetbits(readfunction, writefunction, addr, mask, set) \
> + writefunction(((readfunction(addr) & ~(mask)) | (set)), addr)
> +#define __setclrbits(readfunction, writefunction, addr, mask, set) \
> + writefunction(((readfunction(addr) | (set)) & ~(mask)), addr)
> +
> +#ifndef setbits_le32
> +#define setbits_le32(addr, set) __setbits(readl, writel, addr, set)
> +#endif
> +#ifndef setbits_le32_relaxed
> +#define setbits_le32_relaxed(addr, set) __setbits(readl_relaxed, writel_relaxed, \
> + addr, set)
> +#endif
> +
> +#ifndef clrbits_le32
> +#define clrbits_le32(addr, mask) __clrbits(readl, writel, addr, mask)
> +#endif
> +#ifndef clrbits_le32_relaxed
> +#define clrbits_le32_relaxed(addr, mask) __clrbits(readl_relaxed, writel_relaxed, \
> + addr, mask)
> +#endif
> +
> +#ifndef clrsetbits_le32
> +#define clrsetbits_le32(addr, mask, set) __clrsetbits(readl, writel, addr, mask, set)
> +#endif
> +#ifndef clrsetbits_le32_relaxed
> +#define clrsetbits_le32_relaxed(addr, mask, set) __clrsetbits(readl_relaxed, \
> + writel_relaxed, \
> + addr, mask, set)
> +#endif
> +
> +#ifndef setclrbits_le32
> +#define setclrbits_le32(addr, mask, set) __setclrbits(readl, writel, addr, mask, set)
> +#endif
> +#ifndef setclrbits_le32_relaxed
> +#define setclrbits_le32_relaxed(addr, mask, set) __setclrbits(readl_relaxed, \
> + writel_relaxed, \
> + addr, mask, set)
> +#endif
> +
> +/* We cannot use CONFIG_64BIT as some x86 drivers use non-atomicwriteq() */
> +#if defined(writeq) && defined(readq)
Take care. At least Alpha Arch defines it as a static inline without
redefining it as a #define. (see arch/alpha/kernel/io.c)
Christophe
> +#ifndef setbits_le64
> +#define setbits_le64(addr, set) __setbits(readq, writeq, addr, set)
> +#endif
> +#ifndef setbits_le64_relaxed
> +#define setbits_le64_relaxed(addr, set) __setbits(readq_relaxed, writeq_relaxed, \
> + addr, set)
> +#endif
> +
> +#ifndef clrbits_le64
> +#define clrbits_le64(addr, mask) __clrbits(readq, writeq, addr, mask)
> +#endif
> +#ifndef clrbits_le64_relaxed
> +#define clrbits_le64_relaxed(addr, mask) __clrbits(readq_relaxed, writeq_relaxed, \
> + addr, mask)
> +#endif
> +
> +#ifndef clrsetbits_le64
> +#define clrsetbits_le64(addr, mask, set) __clrsetbits(readq, writeq, addr, mask, set)
> +#endif
> +#ifndef clrsetbits_le64_relaxed
> +#define clrsetbits_le64_relaxed(addr, mask, set) __clrsetbits(readq_relaxed, \
> + writeq_relaxed, \
> + addr, mask, set)
> +#endif
> +
> +#ifndef setclrbits_le64
> +#define setclrbits_le64(addr, mask, set) __setclrbits(readq, writeq, addr, mask, set)
> +#endif
> +#ifndef setclrbits_le64_relaxed
> +#define setclrbits_le64_relaxed(addr, mask, set) __setclrbits(readq_relaxed, \
> + writeq_relaxed, \
> + addr, mask, set)
> +#endif
> +
> +#endif /* writeq/readq */
> +
> +#endif /* __LINUX_SETBITS_H */
>
^ permalink raw reply
* [PATCH net-next 0/3] r8169: series with smaller improvements
From: Heiner Kallweit @ 2018-09-25 5:55 UTC (permalink / raw)
To: David Miller, Realtek linux nic maintainers; +Cc: netdev@vger.kernel.org
This series includes smaller improvements, nothing exciting.
Heiner Kallweit (3):
r8169: use default watchdog timeout
r8169: improve rtl8169_irq_mask_and_ack
r8169: improve a check in rtl_init_one
drivers/net/ethernet/realtek/r8169.c | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)
--
2.19.0
^ permalink raw reply
* [PATCH net-next 1/3] r8169: use default watchdog timeout
From: Heiner Kallweit @ 2018-09-25 5:56 UTC (permalink / raw)
To: David Miller, Realtek linux nic maintainers; +Cc: netdev@vger.kernel.org
In-Reply-To: <2dcf188b-852a-f785-c6e4-e63041b76c86@gmail.com>
The networking core has a default watchdog timeout of 5s. I see no
need to define an own timeout of 6s which is basically the same.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 1843fafb6..dd5822673 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -77,8 +77,6 @@ static const int multicast_filter_limit = 32;
#define R8169_TX_RING_BYTES (NUM_TX_DESC * sizeof(struct TxDesc))
#define R8169_RX_RING_BYTES (NUM_RX_DESC * sizeof(struct RxDesc))
-#define RTL8169_TX_TIMEOUT (6*HZ)
-
/* write/read MMIO register */
#define RTL_W8(tp, reg, val8) writeb((val8), tp->mmio_addr + (reg))
#define RTL_W16(tp, reg, val16) writew((val16), tp->mmio_addr + (reg))
@@ -7414,7 +7412,6 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
dev->dev_addr[i] = RTL_R8(tp, MAC0 + i);
dev->ethtool_ops = &rtl8169_ethtool_ops;
- dev->watchdog_timeo = RTL8169_TX_TIMEOUT;
netif_napi_add(dev, &tp->napi, rtl8169_poll, NAPI_POLL_WEIGHT);
--
2.19.0
^ permalink raw reply related
* [PATCH net-next 2/3] r8169: improve rtl8169_irq_mask_and_ack
From: Heiner Kallweit @ 2018-09-25 5:58 UTC (permalink / raw)
To: David Miller, Realtek linux nic maintainers; +Cc: netdev@vger.kernel.org
In-Reply-To: <2dcf188b-852a-f785-c6e4-e63041b76c86@gmail.com>
Code can be slightly simplified by acking even events we're not
interested in. In addition add a comment making clear that the
read has no functional purpose and is just a PCI commit.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index dd5822673..2d9e6c186 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1352,7 +1352,8 @@ static void rtl_irq_enable_all(struct rtl8169_private *tp)
static void rtl8169_irq_mask_and_ack(struct rtl8169_private *tp)
{
rtl_irq_disable(tp);
- rtl_ack_events(tp, RTL_EVENT_NAPI | tp->event_slow);
+ rtl_ack_events(tp, 0xffff);
+ /* PCI commit */
RTL_R8(tp, ChipCmd);
}
@@ -7365,14 +7366,12 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
rtl_init_rxcfg(tp);
- rtl_irq_disable(tp);
+ rtl8169_irq_mask_and_ack(tp);
rtl_hw_initialize(tp);
rtl_hw_reset(tp);
- rtl_ack_events(tp, 0xffff);
-
pci_set_master(pdev);
rtl_init_mdio_ops(tp);
--
2.19.0
^ permalink raw reply related
* [PATCH net-next 3/3] r8169: improve a check in rtl_init_one
From: Heiner Kallweit @ 2018-09-25 5:59 UTC (permalink / raw)
To: David Miller, Realtek linux nic maintainers; +Cc: netdev@vger.kernel.org
In-Reply-To: <2dcf188b-852a-f785-c6e4-e63041b76c86@gmail.com>
The check for pci_is_pcie() is redundant here because all
chip versions >=18 are PCIe only anyway. In addition use
dma_set_mask_and_coherent() instead of separate calls to
pci_set_dma_mask() and pci_set_consistent_dma_mask().
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 2d9e6c186..f882be49f 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -7346,11 +7346,9 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
tp->cp_cmd = RTL_R16(tp, CPlusCmd);
- if ((sizeof(dma_addr_t) > 4) &&
- (use_dac == 1 || (use_dac == -1 && pci_is_pcie(pdev) &&
- tp->mac_version >= RTL_GIGA_MAC_VER_18)) &&
- !pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) &&
- !pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64))) {
+ if (sizeof(dma_addr_t) > 4 && (use_dac == 1 || (use_dac == -1 &&
+ tp->mac_version >= RTL_GIGA_MAC_VER_18)) &&
+ !dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64))) {
/* CPlusCmd Dual Access Cycle is only needed for non-PCIe */
if (!pci_is_pcie(pdev))
--
2.19.0
^ permalink raw reply related
* Re: [PATCH bpf-next] flow_dissector: lookup netns by skb->sk if skb->dev is NULL
From: Song Liu @ 2018-09-25 6:13 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Networking, Alexei Starovoitov, Daniel Borkmann, David S . Miller,
Willem de Bruijn
In-Reply-To: <20180924204956.83718-1-willemdebruijn.kernel@gmail.com>
On Mon, Sep 24, 2018 at 1:52 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> From: Willem de Bruijn <willemb@google.com>
>
> BPF flow dissectors are configured per network namespace.
> __skb_flow_dissect looks up the netns through dev_net(skb->dev).
>
> In some dissector paths skb->dev is NULL, such as for Unix sockets.
> In these cases fall back to looking up the netns by socket.
>
> Analyzing the codepaths leading to __skb_flow_dissect I did not find
> a case where both skb->dev and skb->sk are NULL. Warn and fall back to
> standard flow dissector if one is found.
>
> Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
> Reported-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> net/core/flow_dissector.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> index 5c5dd74b5b3b..738c7562e1e0 100644
> --- a/net/core/flow_dissector.c
> +++ b/net/core/flow_dissector.c
> @@ -714,7 +714,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> struct flow_dissector_key_vlan *key_vlan;
> enum flow_dissect_ret fdret;
> enum flow_dissector_key_id dissector_vlan = FLOW_DISSECTOR_KEY_MAX;
> - struct bpf_prog *attached;
> + struct bpf_prog *attached = NULL;
> int num_hdrs = 0;
> u8 ip_proto = 0;
> bool ret;
> @@ -755,8 +755,14 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> target_container);
>
> rcu_read_lock();
> - attached = skb ? rcu_dereference(dev_net(skb->dev)->flow_dissector_prog)
> - : NULL;
> + if (skb) {
> + if (skb->dev)
> + attached = rcu_dereference(dev_net(skb->dev)->flow_dissector_prog);
> + else if (skb->sk)
> + attached = rcu_dereference(sock_net(skb->sk)->flow_dissector_prog);
> + else
> + WARN_ON_ONCE(1);
> + }
> if (attached) {
> /* Note that even though the const qualifier is discarded
> * throughout the execution of the BPF program, all changes(the
> --
> 2.19.0.444.g18242da7ef-goog
>
^ permalink raw reply
* Re: [PATCH rdma-next v1 0/7] Preparation to DevX extension series
From: Leon Romanovsky @ 2018-09-25 7:33 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Yishai Hadas, Saeed Mahameed,
linux-netdev
In-Reply-To: <20180922170207.GA13493@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 1893 bytes --]
On Sat, Sep 22, 2018 at 11:02:07AM -0600, Jason Gunthorpe wrote:
> On Thu, Sep 20, 2018 at 09:35:19PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > Changelog v0->v1:
> > * Update commit messages
> > * Split DevX series to small sub-series.
> > * Change static initialization from {0} to be {}
> >
> >
> > Set uid as part of various IB commands so that the firmware can manage
> > the IB object in a secured way.
> >
> > The firmware should mark this IB object with the given uid so that it
> > can be used later on only by objects with the same uid.
> >
> > Upon DEVX flows that use this objec, the pointed object must have
> > the same uid as of the issuer uid command.
> >
> > When a command is issued with uid=0 it means that the issuer of the
> > command is trusted (i.e. kernel), in that case any pointed object
> > can be used regardless of its uid.
> >
> > Thanks
> >
> > Leon Romanovsky (1):
> > net/mlx5: Update mlx5_ifc with DEVX UID bits
> >
> > Yishai Hadas (6):
> > net/mlx5: Set uid as part of CQ commands
> > net/mlx5: Set uid as part of QP commands
> > net/mlx5: Set uid as part of RQ commands
> > net/mlx5: Set uid as part of SQ commands
> > net/mlx5: Set uid as part of SRQ commands
> > net/mlx5: Set uid as part of DCT commands
>
> This and the next series look OK to me. Let me know when it is applied
> to the mlx branch
Applied after fixing Or's comments (typo and extra description in last patch).
bd37197554eb net/mlx5: Update mlx5_ifc with DEVX UID bits
774ea6eea290 net/mlx5: Set uid as part of DCT commands
a0d8c0543189 net/mlx5: Set uid as part of SRQ commands
430ae0d5a3ce net/mlx5: Set uid as part of SQ commands
d269b3afffcb net/mlx5: Set uid as part of RQ commands
4ac63ec72587 net/mlx5: Set uid as part of QP commands
9ba481e2eb3b net/mlx5: Set uid as part of CQ commands
Thanks
>
> Thanks,
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] ravb: Disable Pause Advertisement
From: Simon Horman @ 2018-09-25 7:38 UTC (permalink / raw)
To: Andrew Lunn; +Cc: David Miller, Florian Fainelli, netdev
In-Reply-To: <1537537946-24786-1-git-send-email-andrew@lunn.ch>
On Fri, Sep 21, 2018 at 03:52:26PM +0200, Andrew Lunn wrote:
> The previous commit to ravb had the side effect of making the PHY
> advertise Pause and Asym Pause, which previously did not happen. By
> default, phydev->supported has both forms of pause enabled, but
> phydev->advertising does not. The new phy_remove_link_mode() copies
> phydev->supported to phydev->advertising after removing the requested
> link mode. These Pause configuration bits appears it stops the PHY
> from completing Auto-Neg and the link remains down. Be explicit and
> remove the Pause and Asym Pause modes, so restoring the old behavior.
>
> Reported-by: Simon Horman <horms@verge.net.au>
> Fixes: 41124fa64d4b ("net: ethernet: Add helper to remove a supported link mode")
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> I reworded the commit message from what Simon tested.
> ---
> drivers/net/ethernet/renesas/ravb_main.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> index fb2a1125780d..b0f2612ad226 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -1073,9 +1073,11 @@ static int ravb_phy_init(struct net_device *ndev)
> netdev_info(ndev, "limited PHY to 100Mbit/s\n");
> }
>
> - /* 10BASE is not supported */
> + /* 10BASE, Pause and Asym Pause is not supported */
> phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_10baseT_Half_BIT);
> phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_10baseT_Full_BIT);
> + phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_Pause_BIT);
> + phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_Asym_Pause_BIT);
>
> phy_attached_info(phydev);
>
> --
> 2.19.0.rc1
>
^ permalink raw reply
* Re: [PATCH v3 net-next 07/12] net: ethernet: Add helper to remove a supported link mode
From: Simon Horman @ 2018-09-25 7:38 UTC (permalink / raw)
To: Andrew Lunn
Cc: David Miller, netdev, Florian Fainelli, Sergei Shtylyov,
linux-renesas-soc
In-Reply-To: <20180924155023.GB10667@lunn.ch>
On Mon, Sep 24, 2018 at 05:50:23PM +0200, Andrew Lunn wrote:
> On Mon, Sep 24, 2018 at 05:36:00PM +0200, Simon Horman wrote:
> > On Fri, Sep 21, 2018 at 10:17:35AM +0200, Simon Horman wrote:
> > > On Thu, Sep 20, 2018 at 02:51:06PM +0200, Andrew Lunn wrote:
> > > > > eth0: no link
> > > > > registers for MII PHY 0:
> > > > > 1140 7949 0022 1622 0981 c1e1 000d 0000
> > > >
> > > > Hi Simon
> > > >
> > > > The ID registers 0022 1622 indicate this is a Micrel KSZ9031.
> > > > Are you using the micrel PHY driver?
> > >
> > >
> > > Yes, when the Link is successfully negotiated I see:
> > >
> > > Micrel KSZ9031 Gigabit PHY e6800000.ethernet-ffffffff:00: attached PHY driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=e6800000.ethernet-ffffffff:00, irq=204)
> > >
> > > > > I note a difference in the 3rd line of hex output: 7002 vs 6002
> > > > > but I am unsure if that is relevant.
> > > >
> > > > Register 20, or 0x14. The datasheet says "Reserved" and there is no
> > > > description given :-(
> > > >
> > > > I will decode the other registers and see if i can find anything.
> > >
> > > Thanks, very much appreciated.
> > >
> > > I believe your patch to disable Asym_Pause solves the immediate
> > > problem I have observed.
> >
> > Andrew, how would you like to resolve this?
> > Let me know how I can help.
>
> Hi Simon
>
> I submitted it to netdev in the usual way. I hope DaveM will accept
> and merge it.
Thanks, I see that now. Sorry for not noticing it before pinging you.
And thanks a lot for your patience in resolving this problem.
^ permalink raw reply
* [PATCH 3/3] mac80211_hwsim: drop now unused work-queue from hwsim
From: Martin Willi @ 2018-09-25 7:41 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, Benjamin Beichler
In-Reply-To: <20180925074115.18169-1-martin@strongswan.org>
The work-queue was used for deferred destruction of hwsim radios;
this does not work well with namespaces about to exit. The one
remaining user has been migrated, so drop the now unused work-queue
instance.
Signed-off-by: Martin Willi <martin@strongswan.org>
---
drivers/net/wireless/mac80211_hwsim.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 09fcd6911020..70229a839c84 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -495,7 +495,6 @@ static const struct ieee80211_iface_combination hwsim_if_comb_p2p_dev[] = {
static spinlock_t hwsim_radio_lock;
static LIST_HEAD(hwsim_radios);
-static struct workqueue_struct *hwsim_wq;
static struct rhashtable hwsim_radios_rht;
static int hwsim_radio_idx;
static int hwsim_radios_generation = 1;
@@ -3693,13 +3692,9 @@ static int __init init_mac80211_hwsim(void)
spin_lock_init(&hwsim_radio_lock);
- hwsim_wq = alloc_workqueue("hwsim_wq", 0, 0);
- if (!hwsim_wq)
- return -ENOMEM;
-
err = rhashtable_init(&hwsim_radios_rht, &hwsim_rht_params);
if (err)
- goto out_free_wq;
+ return err;
err = register_pernet_device(&hwsim_net_ops);
if (err)
@@ -3830,8 +3825,6 @@ static int __init init_mac80211_hwsim(void)
unregister_pernet_device(&hwsim_net_ops);
out_free_rht:
rhashtable_destroy(&hwsim_radios_rht);
-out_free_wq:
- destroy_workqueue(hwsim_wq);
return err;
}
module_init(init_mac80211_hwsim);
@@ -3843,12 +3836,10 @@ static void __exit exit_mac80211_hwsim(void)
hwsim_exit_netlink();
mac80211_hwsim_free();
- flush_workqueue(hwsim_wq);
rhashtable_destroy(&hwsim_radios_rht);
unregister_netdev(hwsim_mon);
platform_driver_unregister(&mac80211_hwsim_driver);
unregister_pernet_device(&hwsim_net_ops);
- destroy_workqueue(hwsim_wq);
}
module_exit(exit_mac80211_hwsim);
--
2.17.1
^ permalink raw reply related
* [PATCH 1/3] mac80211_hwsim: fix locking when iterating radios during ns exit
From: Martin Willi @ 2018-09-25 7:41 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, Benjamin Beichler
In-Reply-To: <20180925074115.18169-1-martin@strongswan.org>
The cleanup of radios during namespace exit has recently been reworked
to directly delete a radio while temporarily releasing the spinlock,
fixing a race condition between the work-queue execution and namespace
exits. However, the temporary unlock allows unsafe modifications on the
iterated list, resulting in a potential crash when continuing the
iteration of additional radios.
Move radios about to destroy to a temporary list, and clean that up
after releasing the spinlock once iteration is complete.
Fixes: 8cfd36a0b53a ("mac80211_hwsim: fix use-after-free bug in hwsim_exit_net")
Signed-off-by: Martin Willi <martin@strongswan.org>
---
drivers/net/wireless/mac80211_hwsim.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index f3863101af78..8c76e9a3499a 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3642,6 +3642,7 @@ static __net_init int hwsim_init_net(struct net *net)
static void __net_exit hwsim_exit_net(struct net *net)
{
struct mac80211_hwsim_data *data, *tmp;
+ LIST_HEAD(list);
spin_lock_bh(&hwsim_radio_lock);
list_for_each_entry_safe(data, tmp, &hwsim_radios, list) {
@@ -3652,17 +3653,19 @@ static void __net_exit hwsim_exit_net(struct net *net)
if (data->netgroup == hwsim_net_get_netgroup(&init_net))
continue;
- list_del(&data->list);
+ list_move(&data->list, &list);
rhashtable_remove_fast(&hwsim_radios_rht, &data->rht,
hwsim_rht_params);
hwsim_radios_generation++;
- spin_unlock_bh(&hwsim_radio_lock);
+ }
+ spin_unlock_bh(&hwsim_radio_lock);
+
+ list_for_each_entry_safe(data, tmp, &list, list) {
+ list_del(&data->list);
mac80211_hwsim_del_radio(data,
wiphy_name(data->hw->wiphy),
NULL);
- spin_lock_bh(&hwsim_radio_lock);
}
- spin_unlock_bh(&hwsim_radio_lock);
ida_simple_remove(&hwsim_netgroup_ida, hwsim_net_get_netgroup(net));
}
--
2.17.1
^ permalink raw reply related
* [PATCH 2/3] mac80211_hwsim: fix race in radio destruction from netlink notifier
From: Martin Willi @ 2018-09-25 7:41 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, Benjamin Beichler
In-Reply-To: <20180925074115.18169-1-martin@strongswan.org>
The asynchronous destruction from a work-queue of radios tagged with
destroy-on-close may race with the owning namespace about to exit,
resulting in potential use-after-free of that namespace.
Instead of using a work-queue, move radios about to destroy to a
temporary list, which can be worked on synchronously after releasing
the lock. This should be safe to do from the netlink socket notifier,
as the namespace is guaranteed to not get released.
Signed-off-by: Martin Willi <martin@strongswan.org>
---
drivers/net/wireless/mac80211_hwsim.c | 22 +++++++++-------------
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 8c76e9a3499a..09fcd6911020 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -521,7 +521,6 @@ struct mac80211_hwsim_data {
int channels, idx;
bool use_chanctx;
bool destroy_on_close;
- struct work_struct destroy_work;
u32 portid;
char alpha2[2];
const struct ieee80211_regdomain *regd;
@@ -3561,30 +3560,27 @@ static struct genl_family hwsim_genl_family __ro_after_init = {
.n_mcgrps = ARRAY_SIZE(hwsim_mcgrps),
};
-static void destroy_radio(struct work_struct *work)
-{
- struct mac80211_hwsim_data *data =
- container_of(work, struct mac80211_hwsim_data, destroy_work);
-
- hwsim_radios_generation++;
- mac80211_hwsim_del_radio(data, wiphy_name(data->hw->wiphy), NULL);
-}
-
static void remove_user_radios(u32 portid)
{
struct mac80211_hwsim_data *entry, *tmp;
+ LIST_HEAD(list);
spin_lock_bh(&hwsim_radio_lock);
list_for_each_entry_safe(entry, tmp, &hwsim_radios, list) {
if (entry->destroy_on_close && entry->portid == portid) {
- list_del(&entry->list);
+ list_move(&entry->list, &list);
rhashtable_remove_fast(&hwsim_radios_rht, &entry->rht,
hwsim_rht_params);
- INIT_WORK(&entry->destroy_work, destroy_radio);
- queue_work(hwsim_wq, &entry->destroy_work);
+ hwsim_radios_generation++;
}
}
spin_unlock_bh(&hwsim_radio_lock);
+
+ list_for_each_entry_safe(entry, tmp, &list, list) {
+ list_del(&entry->list);
+ mac80211_hwsim_del_radio(entry, wiphy_name(entry->hw->wiphy),
+ NULL);
+ }
}
static int mac80211_hwsim_netlink_notify(struct notifier_block *nb,
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 0/3] mac80211_hwsim: radio destruction fixes
From: Johannes Berg @ 2018-09-25 7:44 UTC (permalink / raw)
To: Martin Willi; +Cc: linux-wireless, netdev, Benjamin Beichler
In-Reply-To: <20180925074115.18169-1-martin@strongswan.org>
On Tue, 2018-09-25 at 09:41 +0200, Martin Willi wrote:
> This small series fixes two issues for cleaning up hwsim radios. The
> first one is rather easy to hit when terminating namespaces with many
> hwsim radios. The second one affects destroy-on-close users only.
>
> Given that the use of a work-queue for deferred cleanup with namespaces
> has been and still is tricky to get right, this series switches these
> users to a synchronous cleanup in hwsim;
Cool, thanks. I wasn't really even aware of this, most our usage is with
VMs, not namespaces.
> The removal of that work-queue
> is in a dedicated commit in case we want to skip that in backports.
Yeah, also I'll probably stick that into -next only.
johannes
^ permalink raw reply
* [PATCH net-next] net: mvneta: Add support for 2500Mbps SGMII
From: Maxime Chevallier @ 2018-09-25 13:59 UTC (permalink / raw)
To: davem
Cc: Maxime Chevallier, netdev, linux-kernel, Antoine Tenart,
thomas.petazzoni, gregory.clement, miquel.raynal, nadavh, stefanc,
mw, yelena, linux-arm-kernel
The mvneta controller can handle speeds up to 2500Mbps on the SGMII
interface. This relies on serdes configuration, the lane must be
configured at 3.125Gbps and we can't use in-band autoneg at that speed.
The main issue when supporting that speed on this particular controller
is that the link partner can send ethernet frames with a shortened
preamble, which if not explicitly enabled in the controller will cause
unexpected behaviours.
This was tested on Armada 385, with the comphy configuration done in
bootloader.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/ethernet/marvell/mvneta.c | 27 +++++++++++++++++++++++----
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 59ed63102e14..650303577090 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -221,6 +221,8 @@
#define MVNETA_GMAC_AN_FLOW_CTRL_EN BIT(11)
#define MVNETA_GMAC_CONFIG_FULL_DUPLEX BIT(12)
#define MVNETA_GMAC_AN_DUPLEX_EN BIT(13)
+#define MVNETA_GMAC_CTRL_4 0x2c90
+#define MVNETA_GMAC4_SHORT_PREAMBLE_ENABLE BIT(1)
#define MVNETA_MIB_COUNTERS_BASE 0x3000
#define MVNETA_MIB_LATE_COLLISION 0x7c
#define MVNETA_DA_FILT_SPEC_MCAST 0x3400
@@ -3342,6 +3344,7 @@ static void mvneta_validate(struct net_device *ndev, unsigned long *supported,
if (state->interface != PHY_INTERFACE_MODE_NA &&
state->interface != PHY_INTERFACE_MODE_QSGMII &&
state->interface != PHY_INTERFACE_MODE_SGMII &&
+ state->interface != PHY_INTERFACE_MODE_2500BASEX &&
!phy_interface_mode_is_8023z(state->interface) &&
!phy_interface_mode_is_rgmii(state->interface)) {
bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
@@ -3354,9 +3357,15 @@ static void mvneta_validate(struct net_device *ndev, unsigned long *supported,
/* Asymmetric pause is unsupported */
phylink_set(mask, Pause);
- /* Half-duplex at speeds higher than 100Mbit is unsupported */
- phylink_set(mask, 1000baseT_Full);
- phylink_set(mask, 1000baseX_Full);
+
+ /* We cannot use 1Gbps when using the 2.5G interface. */
+ if (state->interface == PHY_INTERFACE_MODE_2500BASEX) {
+ phylink_set(mask, 2500baseT_Full);
+ phylink_set(mask, 2500baseX_Full);
+ } else {
+ phylink_set(mask, 1000baseT_Full);
+ phylink_set(mask, 1000baseX_Full);
+ }
if (!phy_interface_mode_is_8023z(state->interface)) {
/* 10M and 100M are only supported in non-802.3z mode */
@@ -3417,12 +3426,14 @@ static void mvneta_mac_config(struct net_device *ndev, unsigned int mode,
struct mvneta_port *pp = netdev_priv(ndev);
u32 new_ctrl0, gmac_ctrl0 = mvreg_read(pp, MVNETA_GMAC_CTRL_0);
u32 new_ctrl2, gmac_ctrl2 = mvreg_read(pp, MVNETA_GMAC_CTRL_2);
+ u32 new_ctrl4, gmac_ctrl4 = mvreg_read(pp, MVNETA_GMAC_CTRL_4);
u32 new_clk, gmac_clk = mvreg_read(pp, MVNETA_GMAC_CLOCK_DIVIDER);
u32 new_an, gmac_an = mvreg_read(pp, MVNETA_GMAC_AUTONEG_CONFIG);
new_ctrl0 = gmac_ctrl0 & ~MVNETA_GMAC0_PORT_1000BASE_X;
new_ctrl2 = gmac_ctrl2 & ~(MVNETA_GMAC2_INBAND_AN_ENABLE |
MVNETA_GMAC2_PORT_RESET);
+ new_ctrl4 = gmac_ctrl4 & ~(MVNETA_GMAC4_SHORT_PREAMBLE_ENABLE);
new_clk = gmac_clk & ~MVNETA_GMAC_1MS_CLOCK_ENABLE;
new_an = gmac_an & ~(MVNETA_GMAC_INBAND_AN_ENABLE |
MVNETA_GMAC_INBAND_RESTART_AN |
@@ -3455,7 +3466,7 @@ static void mvneta_mac_config(struct net_device *ndev, unsigned int mode,
if (state->duplex)
new_an |= MVNETA_GMAC_CONFIG_FULL_DUPLEX;
- if (state->speed == SPEED_1000)
+ if (state->speed == SPEED_1000 || state->speed == SPEED_2500)
new_an |= MVNETA_GMAC_CONFIG_GMII_SPEED;
else if (state->speed == SPEED_100)
new_an |= MVNETA_GMAC_CONFIG_MII_SPEED;
@@ -3494,10 +3505,18 @@ static void mvneta_mac_config(struct net_device *ndev, unsigned int mode,
MVNETA_GMAC_FORCE_LINK_DOWN);
}
+ /* When at 2.5G, the link partner can send frames with shortened
+ * preambles.
+ */
+ if (state->speed == SPEED_2500)
+ new_ctrl4 |= MVNETA_GMAC4_SHORT_PREAMBLE_ENABLE;
+
if (new_ctrl0 != gmac_ctrl0)
mvreg_write(pp, MVNETA_GMAC_CTRL_0, new_ctrl0);
if (new_ctrl2 != gmac_ctrl2)
mvreg_write(pp, MVNETA_GMAC_CTRL_2, new_ctrl2);
+ if (new_ctrl4 != gmac_ctrl4)
+ mvreg_write(pp, MVNETA_GMAC_CTRL_4, new_ctrl4);
if (new_clk != gmac_clk)
mvreg_write(pp, MVNETA_GMAC_CLOCK_DIVIDER, new_clk);
if (new_an != gmac_an)
--
2.11.0
^ permalink raw reply related
* Re: [PATCH stable 4.4 V2 0/6] fix SegmentSmack in stable branch (CVE-2018-5390)
From: maowenan @ 2018-09-25 14:10 UTC (permalink / raw)
To: netdev, gregkh, dwmw2, eric.dumazet, davem, stable, linux-kernel
In-Reply-To: <1536913450-12380-1-git-send-email-maowenan@huawei.com>
Hi Greg:
can you review this patch set?
thanks a lot.
On 2018/9/14 16:24, Mao Wenan wrote:
> There are five patches to fix CVE-2018-5390 in latest mainline
> branch, but only two patches exist in stable 4.4 and 3.18:
> dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue()
> 5fbec48 tcp: avoid collapses in tcp_prune_queue() if possible
> I have tested with stable 4.4 kernel, and found the cpu usage was very high.
> So I think only two patches can't fix the CVE-2018-5390.
> test results:
> with fix patch： 78.2% ksoftirqd
> withoutfix patch： 90% ksoftirqd
>
> Then I try to imitate 72cd43ba(tcp: free batches of packets in tcp_prune_ofo_queue())
> to drop at least 12.5 % of sk_rcvbuf to avoid malicious attacks with simple queue
> instead of RB tree. The result is not very well.
>
> After analysing the codes of stable 4.4, and debuging the
> system, shows that search of ofo_queue(tcp ofo using a simple queue) cost more cycles.
>
> So I try to backport "tcp: use an RB tree for ooo receive queue" using RB tree
> instead of simple queue, then backport Eric Dumazet 5 fixed patches in mainline,
> good news is that ksoftirqd is turn to about 20%, which is the same with mainline now.
>
> Stable 4.4 have already back port two patches,
> f4a3313d(tcp: avoid collapses in tcp_prune_queue() if possible)
> 3d4bf93a(tcp: detect malicious patterns in tcp_collapse_ofo_queue())
> If we want to change simple queue to RB tree to finally resolve, we should apply previous
> patch 9f5afeae(tcp: use an RB tree for ooo receive queue.) firstly, but 9f5afeae have many
> conflicts with 3d4bf93a and f4a3313d, which are part of patch series from Eric in
> mainline to fix CVE-2018-5390, so I need revert part of patches in stable 4.4 firstly,
> then apply 9f5afeae, and reapply five patches from Eric.
>
> V1->V2:
> 1) Don't revert 3d4bf93a and f4a3313d firstly, all of 6 patches based on 4.4.155.
> 2) Add one bug fix patch for RB tree:76f0dcbb5ae1a7c3dbeec13dd98233b8e6b0b32a tcp: fix a stale ooo_last_skb
>
> Eric Dumazet (5):
> tcp: increment sk_drops for dropped rx packets
> tcp: fix a stale ooo_last_skb after a replace
> tcp: free batches of packets in tcp_prune_ofo_queue()
> tcp: call tcp_drop() from tcp_data_queue_ofo()
> tcp: add tcp_ooo_try_coalesce() helper
>
> Yaogong Wang (1):
> tcp: use an RB tree for ooo receive queue
>
> include/linux/skbuff.h | 8 +
> include/linux/tcp.h | 7 +-
> include/net/sock.h | 7 +
> include/net/tcp.h | 2 +-
> net/core/skbuff.c | 19 +++
> net/ipv4/tcp.c | 4 +-
> net/ipv4/tcp_input.c | 417 +++++++++++++++++++++++++++++------------------
> net/ipv4/tcp_ipv4.c | 3 +-
> net/ipv4/tcp_minisocks.c | 1 -
> net/ipv6/tcp_ipv6.c | 1 +
> 10 files changed, 297 insertions(+), 172 deletions(-)
>
^ permalink raw reply
* [PATCH net 0/3 RESEND] xen-netback: hash mapping handling adjustments
From: Jan Beulich @ 2018-09-25 8:11 UTC (permalink / raw)
To: davem; +Cc: Paul Durrant, Wei Liu, xen-devel, netdev
In-Reply-To: <5B85622302000078001E2A35@prv1-mh.provo.novell.com>
(re-send just to satisfy the apparent need for "net" inside the square brackets)
First and foremost the fix for XSA-270. On top of that further changes
which looked desirable to me while investigating that XSA.
1: fix input validation in xenvif_set_hash_mapping()
2: validate queue numbers in xenvif_set_hash_mapping()
3: handle page straddling in xenvif_set_hash_mapping()
Signed-off-by: Jan Beulich <jbeulich@suse.com>
^ permalink raw reply
* Re: [PATCH iproute2 1/1] Makefile: Add check target
From: Stephen Hemminger @ 2018-09-25 8:12 UTC (permalink / raw)
To: Petr Vorel; +Cc: netdev
In-Reply-To: <20180921202916.27933-1-petr.vorel@gmail.com>
On Fri, 21 Sep 2018 22:29:16 +0200
Petr Vorel <petr.vorel@gmail.com> wrote:
> Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
Applied, thanks.
^ permalink raw reply
* [PATCH net 1/3 RESEND] xen-netback: fix input validation in xenvif_set_hash_mapping()
From: Jan Beulich @ 2018-09-25 8:12 UTC (permalink / raw)
To: davem; +Cc: Paul Durrant, Wei Liu, xen-devel, netdev
In-Reply-To: <5B85622302000078001E2A35@prv1-mh.provo.novell.com>
Both len and off are frontend specified values, so we need to make
sure there's no overflow when adding the two for the bounds check. We
also want to avoid undefined behavior and hence use off to index into
->hash.mapping[] only after bounds checking. This at the same time
allows to take care of not applying off twice for the bounds checking
against vif->num_queues.
It is also insufficient to bounds check copy_op.len, as this is len
truncated to 16 bits.
This is XSA-270 / CVE-2018-15471.
Reported-by: Felix Wilhelm <fwilhelm@google.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Tested-by: Paul Durrant <paul.durrant@citrix.com>
Cc: stable@vger.kernel.org [4.7 onwards]
---
drivers/net/xen-netback/hash.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
--- 4.19-rc1-xen-netback-set-hash-mapping.orig/drivers/net/xen-netback/hash.c
+++ 4.19-rc1-xen-netback-set-hash-mapping/drivers/net/xen-netback/hash.c
@@ -332,20 +332,22 @@ u32 xenvif_set_hash_mapping_size(struct
u32 xenvif_set_hash_mapping(struct xenvif *vif, u32 gref, u32 len,
u32 off)
{
- u32 *mapping = &vif->hash.mapping[off];
+ u32 *mapping = vif->hash.mapping;
struct gnttab_copy copy_op = {
.source.u.ref = gref,
.source.domid = vif->domid,
- .dest.u.gmfn = virt_to_gfn(mapping),
.dest.domid = DOMID_SELF,
- .dest.offset = xen_offset_in_page(mapping),
- .len = len * sizeof(u32),
+ .len = len * sizeof(*mapping),
.flags = GNTCOPY_source_gref
};
- if ((off + len > vif->hash.size) || copy_op.len > XEN_PAGE_SIZE)
+ if ((off + len < off) || (off + len > vif->hash.size) ||
+ len > XEN_PAGE_SIZE / sizeof(*mapping))
return XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER;
+ copy_op.dest.u.gmfn = virt_to_gfn(mapping + off);
+ copy_op.dest.offset = xen_offset_in_page(mapping + off);
+
while (len-- != 0)
if (mapping[off++] >= vif->num_queues)
return XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER;
^ permalink raw reply
* Re: [PATCH iproute2] iplink_vxlan: take into account preferred_family creating vxlan device
From: Stephen Hemminger @ 2018-09-25 8:12 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: netdev
In-Reply-To: <fc0937f4f788f84986fd0ace7722e8b2d3e2755e.1537536423.git.lorenzo.bianconi@redhat.com>
On Fri, 21 Sep 2018 15:34:25 +0200
Lorenzo Bianconi <lorenzo.bianconi@redhat.com> wrote:
> Take into account the configured preferred_family if neither saddr or
> daddr are provided since otherwise vxlan kernel module will use IPv4 as
> default remote inet family neglecting the one provided by userspace.
> This behaviour was originally in commit 97d564b90ccb ("vxlan: use
> preferred address family when neither group or remote is specified").
> The issue can be triggered with the following reproducer:
>
> $ip -6 link add vxlan1 type vxlan id 42 dev enp0s2 \
> proxy nolearning l2miss l3miss
> $bridge fdb add 46:47:1f:a7:1c:25 dev vxlan1 dst 2000::2
> RTNETLINK answers: Address family not supported by protocol
>
> Fixes: 1e9b8072de2c ("iplink_vxlan: Get rid of inet_get_addr()")
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Applied, thanks.
^ permalink raw reply
* [PATCH net 2/3 RESEND] xen-netback: validate queue numbers in xenvif_set_hash_mapping()
From: Jan Beulich @ 2018-09-25 8:13 UTC (permalink / raw)
To: davem; +Cc: Paul Durrant, Wei Liu, xen-devel, netdev
In-Reply-To: <5B85622302000078001E2A35@prv1-mh.provo.novell.com>
Checking them before the grant copy means nothing as to the validity of
the incoming request. As we shouldn't make the new data live before
having validated it, introduce a second instance of the mapping array.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
---
drivers/net/xen-netback/common.h | 3 ++-
drivers/net/xen-netback/hash.c | 20 ++++++++++++++------
drivers/net/xen-netback/interface.c | 3 ++-
3 files changed, 18 insertions(+), 8 deletions(-)
--- 4.19-rc1-xen-netback-set-hash-mapping.orig/drivers/net/xen-netback/common.h
+++ 4.19-rc1-xen-netback-set-hash-mapping/drivers/net/xen-netback/common.h
@@ -241,8 +241,9 @@ struct xenvif_hash_cache {
struct xenvif_hash {
unsigned int alg;
u32 flags;
+ bool mapping_sel;
u8 key[XEN_NETBK_MAX_HASH_KEY_SIZE];
- u32 mapping[XEN_NETBK_MAX_HASH_MAPPING_SIZE];
+ u32 mapping[2][XEN_NETBK_MAX_HASH_MAPPING_SIZE];
unsigned int size;
struct xenvif_hash_cache cache;
};
--- 4.19-rc1-xen-netback-set-hash-mapping.orig/drivers/net/xen-netback/hash.c
+++ 4.19-rc1-xen-netback-set-hash-mapping/drivers/net/xen-netback/hash.c
@@ -324,7 +324,8 @@ u32 xenvif_set_hash_mapping_size(struct
return XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER;
vif->hash.size = size;
- memset(vif->hash.mapping, 0, sizeof(u32) * size);
+ memset(vif->hash.mapping[vif->hash.mapping_sel], 0,
+ sizeof(u32) * size);
return XEN_NETIF_CTRL_STATUS_SUCCESS;
}
@@ -332,7 +333,7 @@ u32 xenvif_set_hash_mapping_size(struct
u32 xenvif_set_hash_mapping(struct xenvif *vif, u32 gref, u32 len,
u32 off)
{
- u32 *mapping = vif->hash.mapping;
+ u32 *mapping = vif->hash.mapping[!vif->hash.mapping_sel];
struct gnttab_copy copy_op = {
.source.u.ref = gref,
.source.domid = vif->domid,
@@ -348,9 +349,8 @@ u32 xenvif_set_hash_mapping(struct xenvi
copy_op.dest.u.gmfn = virt_to_gfn(mapping + off);
copy_op.dest.offset = xen_offset_in_page(mapping + off);
- while (len-- != 0)
- if (mapping[off++] >= vif->num_queues)
- return XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER;
+ memcpy(mapping, vif->hash.mapping[vif->hash.mapping_sel],
+ vif->hash.size * sizeof(*mapping));
if (copy_op.len != 0) {
gnttab_batch_copy(©_op, 1);
@@ -359,6 +359,12 @@ u32 xenvif_set_hash_mapping(struct xenvi
return XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER;
}
+ while (len-- != 0)
+ if (mapping[off++] >= vif->num_queues)
+ return XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER;
+
+ vif->hash.mapping_sel = !vif->hash.mapping_sel;
+
return XEN_NETIF_CTRL_STATUS_SUCCESS;
}
@@ -410,6 +416,8 @@ void xenvif_dump_hash_info(struct xenvif
}
if (vif->hash.size != 0) {
+ const u32 *mapping = vif->hash.mapping[vif->hash.mapping_sel];
+
seq_puts(m, "\nHash Mapping:\n");
for (i = 0; i < vif->hash.size; ) {
@@ -422,7 +430,7 @@ void xenvif_dump_hash_info(struct xenvif
seq_printf(m, "[%4u - %4u]: ", i, i + n - 1);
for (j = 0; j < n; j++, i++)
- seq_printf(m, "%4u ", vif->hash.mapping[i]);
+ seq_printf(m, "%4u ", mapping[i]);
seq_puts(m, "\n");
}
--- 4.19-rc1-xen-netback-set-hash-mapping.orig/drivers/net/xen-netback/interface.c
+++ 4.19-rc1-xen-netback-set-hash-mapping/drivers/net/xen-netback/interface.c
@@ -162,7 +162,8 @@ static u16 xenvif_select_queue(struct ne
if (size == 0)
return skb_get_hash_raw(skb) % dev->real_num_tx_queues;
- return vif->hash.mapping[skb_get_hash_raw(skb) % size];
+ return vif->hash.mapping[vif->hash.mapping_sel]
+ [skb_get_hash_raw(skb) % size];
}
static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
^ 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