* Re: [PATCH net-next v5 02/20] zinc: introduce minimal cryptography library
From: Jason A. Donenfeld @ 2018-09-25 14:44 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Jean-Philippe Aumasson
In-Reply-To: <CAKv+Gu_Wsp7s31KowyA20ag4t=VyiPLLhzg1ySp31sOFvo7FQQ@mail.gmail.com>
Hey Ard,
On Tue, Sep 25, 2018 at 12:25 PM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> 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?
In order of priority, I'll probably tackle lib/ first and then the
cases like you mentioned after. Indeed AES is an obvious candidate.
For the others, we'll evaluate them on a case-by-case basis. For
example, Ted T'so's "halfmd4" algorithm was moved from lib/ directly
into that portion of the ext4 driver, since it's some "half"-baked
random crypto that should only be used in that one place and then
never again. On the other hand, it seems likely RC4 and DES are used
multiple places, and so we'll have to carefully evaluate these. We can
also discuss this in November and see where thoughts are at that time.
> 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.
I have no concrete plans to introduce an asynchronous interface to
Zinc at this time, but that could change at some later date. At the
moment however, I prefer for it to be just a simple collection of
software ciphers, just as the description reads. Regarding hardware
acceleration in WireGuard: I've actually been talking to some people
interested in producing these types of ASICs lately, and hopefully
something cool will come out of it. It's not obvious, however, that
this _must_ imply an asynchronous interface, even though that may very
well seem like the intuitive thing. This is, as well, a discussion for
the future indeed.
> (Also, I'd like to know whether the RFC7539 construction of ChaCha20
> and Poly1305 is compatible with WireGuard's)
WireGuard uses 64-bit nonces, but since they're both little-endian,
and because of the maximum size of a series of IP fragments (namely,
less than 2^32), they're "compatible".
Jason
^ permalink raw reply
* Re: [PATCH net v2 1/2] net: core: add member wol_enabled to struct net_device
From: Michal Kubecek @ 2018-09-25 8:28 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Andrew Lunn, Florian Fainelli, David Miller,
Realtek linux nic maintainers, netdev@vger.kernel.org
In-Reply-To: <6a574380-06f6-4bce-9705-e2b554359337@gmail.com>
(I wrote my comment to v1 because I overlooked there is a v2 already;
duplicating it here.)
On Mon, Sep 24, 2018 at 09:58:59PM +0200, Heiner Kallweit wrote:
> Add flag wol_enabled to struct net_device indicating whether
> Wake-on-LAN is enabled. As first user phy_suspend() will use it to
> decide whether PHY can be suspended or not.
>
> Fixes: f1e911d5d0df ("r8169: add basic phylib support")
> Fixes: e8cfd9d6c772 ("net: phy: call state machine synchronously in phy_stop")
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> include/linux/netdevice.h | 3 +++
> net/core/ethtool.c | 9 ++++++++-
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 1cbbf77a6..f5f1f1450 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1756,6 +1756,8 @@ enum netdev_priv_flags {
> * switch driver and used to set the phys state of the
> * switch port.
> *
> + * @wol_enabled: Wake-on-LAN is enabled
> + *
> * FIXME: cleanup struct net_device such that network protocol info
> * moves out.
> */
> @@ -2039,6 +2041,7 @@ struct net_device {
> struct lock_class_key *qdisc_tx_busylock;
> struct lock_class_key *qdisc_running_key;
> bool proto_down;
> + unsigned wol_enabled:1;
> };
> #define to_net_dev(d) container_of(d, struct net_device, dev)
>
As there is no bitfield yet, this would add 4 bytes to struct net_device.
How about using a bit in net_device::priv_flags like IFF_RXFH_CONFIGURED
in ethtool_set_rxfh_indir() and ethtool_set_rxfh()?
Michal Kubecek
^ permalink raw reply
* Re: [PATCH net 1/2] net: core: add member wol_enabled to struct net_device
From: Michal Kubecek @ 2018-09-25 8:25 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Andrew Lunn, Florian Fainelli, David Miller,
Realtek linux nic maintainers, netdev@vger.kernel.org
In-Reply-To: <f7bd66f8-8d4a-c09e-f82c-0825618a191d@gmail.com>
On Mon, Sep 24, 2018 at 08:09:48PM +0200, Heiner Kallweit wrote:
> Add flag wol_enabled to struct net_device indicating whether
> Wake-on-LAN is enabled. As first user phy_suspend() will use it to
> decide whether PHY can be suspended or not.
>
> Fixes: f1e911d5d0df ("r8169: add basic phylib support")
> Fixes: e8cfd9d6c772 ("net: phy: call state machine synchronously in phy_stop")
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> include/linux/netdevice.h | 3 +++
> net/core/ethtool.c | 9 ++++++++-
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 1cbbf77a6..f5f1f1450 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1756,6 +1756,8 @@ enum netdev_priv_flags {
> * switch driver and used to set the phys state of the
> * switch port.
> *
> + * @wol_enabled: Wake-on-LAN is enabled
> + *
> * FIXME: cleanup struct net_device such that network protocol info
> * moves out.
> */
> @@ -2039,6 +2041,7 @@ struct net_device {
> struct lock_class_key *qdisc_tx_busylock;
> struct lock_class_key *qdisc_running_key;
> bool proto_down;
> + unsigned wol_enabled:1;
> };
> #define to_net_dev(d) container_of(d, struct net_device, dev)
>
As there is no bitfield yet, this would add 4 bytes to struct net_device.
How about using a bit in net_device::priv_flags like IFF_RXFH_CONFIGURED
in ethtool_set_rxfh_indir() and ethtool_set_rxfh()?
Michal Kubecek
^ permalink raw reply
* Re: Ping: [PATCH 0/3] xen-netback: hash mapping hanling adjustments
From: Jan Beulich @ 2018-09-25 8:18 UTC (permalink / raw)
To: davem; +Cc: Paul Durrant, Wei Liu, xen-devel, netdev
In-Reply-To: <C61B6A85020000F18A491530@prv1-mh.provo.novell.com>
>>> On 24.09.18 at 18:49, <davem@davemloft.net> wrote:
> From: "Jan Beulich" <JBeulich@suse.com>
> Date: Mon, 24 Sep 2018 01:43:50 -0600
>
>> Dave? I notice none of the patches is in 4.19-rc5, not even the security
>> fix, the advisory for which had gone public over a month ago.
>
> If it's not in my patchwork queue, you have to resend the series and
> make it clear that it should be applied to the networking tree by
> putting "[PATCH net N/M]" in the Subject lines.
I'm sure this requirement is documented somewhere, but some searching
in Documentation/process/ did not turn up anything. For the occasional
contributor, such extra tag addition requirements are pretty unhelpful.
Anyway - I've done the resend, hopefully now meeting the requirements
to avoid further delays.
Jan
^ permalink raw reply
* [PATCH net 3/3 RESEND] xen-netback: handle page straddling 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>
There's no guarantee that the mapping array doesn't cross a page
boundary. Use a second grant copy operation if necessary.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
---
drivers/net/xen-netback/hash.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 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
@@ -334,28 +334,39 @@ u32 xenvif_set_hash_mapping(struct xenvi
u32 off)
{
u32 *mapping = vif->hash.mapping[!vif->hash.mapping_sel];
- struct gnttab_copy copy_op = {
+ unsigned int nr = 1;
+ struct gnttab_copy copy_op[2] = {{
.source.u.ref = gref,
.source.domid = vif->domid,
.dest.domid = DOMID_SELF,
.len = len * sizeof(*mapping),
.flags = GNTCOPY_source_gref
- };
+ }};
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);
+ copy_op[0].dest.u.gmfn = virt_to_gfn(mapping + off);
+ copy_op[0].dest.offset = xen_offset_in_page(mapping + off);
+ if (copy_op[0].dest.offset + copy_op[0].len > XEN_PAGE_SIZE) {
+ copy_op[1] = copy_op[0];
+ copy_op[1].source.offset = XEN_PAGE_SIZE - copy_op[0].dest.offset;
+ copy_op[1].dest.u.gmfn = virt_to_gfn(mapping + off + len);
+ copy_op[1].dest.offset = 0;
+ copy_op[1].len = copy_op[0].len - copy_op[1].source.offset;
+ copy_op[0].len = copy_op[1].source.offset;
+ nr = 2;
+ }
memcpy(mapping, vif->hash.mapping[vif->hash.mapping_sel],
vif->hash.size * sizeof(*mapping));
- if (copy_op.len != 0) {
- gnttab_batch_copy(©_op, 1);
+ if (copy_op[0].len != 0) {
+ gnttab_batch_copy(copy_op, nr);
- if (copy_op.status != GNTST_okay)
+ if (copy_op[0].status != GNTST_okay ||
+ copy_op[nr - 1].status != GNTST_okay)
return XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER;
}
^ 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
* 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 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 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 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 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-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 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 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
* [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 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
* 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
* 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 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 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
* [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
* [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 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 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
* 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
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