* Re: [RFC] RESEND - rdmatool - tool for RDMA users
From: Leon Romanovsky @ 2017-01-18 18:28 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Ariel Almog, linux-rdma@vger.kernel.org, Linux Netdev List
In-Reply-To: <CAJ3xEMiR1+NGghUZJ6aGq+=xTdOHU5Ph-BcPii5OUB8dT4Vq-A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1226 bytes --]
On Wed, Jan 18, 2017 at 07:50:26PM +0200, Or Gerlitz wrote:
> On Wed, Jan 18, 2017 at 7:33 PM, Leon Romanovsky wrote:
> > On Wed, Jan 18, 2017 at 06:48:21PM +0200, Or Gerlitz wrote:
> >> On Wed, Jan 18, 2017 at 5:19 PM, Ariel Almog
> >> <arielalmogworkemails@gmail.com> wrote:
>
> >>> As of today, there is no single, simple, tool that allows monitoring
> >>> and configuration of RDMA stack.
>
> >> Before tool, what kernel UAPI you thought to use?
>
> > I'm aware of the following options:
> > 1) netlink
> > 2) RDMA ABI https://www.spinics.net/lists/linux-rdma/msg43960.html
> > 3) ioctl
> > 4) write/read
> >
> > The items 1 and 2 are preferred options and one of the main goals
> > for this RFC is to chose between them.
> >
> > For example, RDMA ABI has native support of querying and discovering
> > device capabilities via merge tree feature.
>
> To make it clear, when you wrote ABI in your initial email, I tend to
> think it was sort of unclear to the netdev crowd that you are talking
> on new UAPI which is now under the works for the IB subsystem, so with
> my netdev community member hat, I got confused... anyway
You are right, I missed it in my review for Ariel who wrote this RFC
and sent this RFC.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH net-next] fq_codel: Avoid regenerating skb flow hash unless necessary
From: Andrew Collins @ 2017-01-18 21:04 UTC (permalink / raw)
To: netdev; +Cc: eric.dumazet, tom, Andrew Collins
The fq_codel qdisc currently always regenerates the skb flow hash.
This wastes some cycles and prevents flow seperation in cases where
the traffic has been encrypted and can no longer be understood by the
flow dissector.
Change it to use the prexisting flow hash if one exists, and only
regenerate if necessary.
Signed-off-by: Andrew Collins <acollins@cradlepoint.com>
---
net/sched/sch_fq_codel.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/net/sched/sch_fq_codel.c b/net/sched/sch_fq_codel.c
index a5ea0e9..2f50e4c 100644
--- a/net/sched/sch_fq_codel.c
+++ b/net/sched/sch_fq_codel.c
@@ -57,7 +57,6 @@ struct fq_codel_sched_data {
struct fq_codel_flow *flows; /* Flows table [flows_cnt] */
u32 *backlogs; /* backlog table [flows_cnt] */
u32 flows_cnt; /* number of flows */
- u32 perturbation; /* hash perturbation */
u32 quantum; /* psched_mtu(qdisc_dev(sch)); */
u32 drop_batch_size;
u32 memory_limit;
@@ -75,9 +74,7 @@ struct fq_codel_sched_data {
static unsigned int fq_codel_hash(const struct fq_codel_sched_data *q,
struct sk_buff *skb)
{
- u32 hash = skb_get_hash_perturb(skb, q->perturbation);
-
- return reciprocal_scale(hash, q->flows_cnt);
+ return reciprocal_scale(skb_get_hash(skb), q->flows_cnt);
}
static unsigned int fq_codel_classify(struct sk_buff *skb, struct Qdisc *sch,
@@ -482,7 +479,6 @@ static int fq_codel_init(struct Qdisc *sch, struct nlattr *opt)
q->memory_limit = 32 << 20; /* 32 MBytes */
q->drop_batch_size = 64;
q->quantum = psched_mtu(qdisc_dev(sch));
- q->perturbation = prandom_u32();
INIT_LIST_HEAD(&q->new_flows);
INIT_LIST_HEAD(&q->old_flows);
codel_params_init(&q->cparams);
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v3] audit: log 32-bit socketcalls
From: Paul Moore @ 2017-01-18 20:46 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: netdev, linux-audit, linux-kernel
In-Reply-To: <299e5702e5876404ee2863cf95847f73cddb0a45.1484669022.git.rgb@redhat.com>
On Tue, Jan 17, 2017 at 11:07 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> 32-bit socketcalls were not being logged by audit on x86_64 systems.
> Log them. This is basically a duplicate of the call from
> net/socket.c:sys_socketcall(), but it addresses the impedance mismatch
> between 32-bit userspace process and 64-bit kernel audit.
>
> See: https://github.com/linux-audit/audit-kernel/issues/14
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> v3:
> Proper spacing around operators and functions. Local var ordering.
> Ditch unlikely, return early.
>
> v2:
> Move work to audit_socketcall_compat() and use audit_dummy_context().
> ---
> include/linux/audit.h | 20 ++++++++++++++++++++
> net/compat.c | 17 ++++++++++++++---
> 2 files changed, 34 insertions(+), 3 deletions(-)
Merged, thanks.
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 9d4443f..2be99b2 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -387,6 +387,20 @@ static inline int audit_socketcall(int nargs, unsigned long *args)
> return __audit_socketcall(nargs, args);
> return 0;
> }
> +
> +static inline int audit_socketcall_compat(int nargs, u32 *args)
> +{
> + unsigned long a[AUDITSC_ARGS];
> + int i;
> +
> + if (audit_dummy_context())
> + return 0;
> +
> + for (i = 0; i < nargs; i++)
> + a[i] = (unsigned long)args[i];
> + return __audit_socketcall(nargs, a);
> +}
> +
> static inline int audit_sockaddr(int len, void *addr)
> {
> if (unlikely(!audit_dummy_context()))
> @@ -513,6 +527,12 @@ static inline int audit_socketcall(int nargs, unsigned long *args)
> {
> return 0;
> }
> +
> +static inline int audit_socketcall_compat(int nargs, u32 *args)
> +{
> + return 0;
> +}
> +
> static inline void audit_fd_pair(int fd1, int fd2)
> { }
> static inline int audit_sockaddr(int len, void *addr)
> diff --git a/net/compat.c b/net/compat.c
> index 1cd2ec0..a96fd2f 100644
> --- a/net/compat.c
> +++ b/net/compat.c
> @@ -22,6 +22,7 @@
> #include <linux/filter.h>
> #include <linux/compat.h>
> #include <linux/security.h>
> +#include <linux/audit.h>
> #include <linux/export.h>
>
> #include <net/scm.h>
> @@ -781,14 +782,24 @@ COMPAT_SYSCALL_DEFINE5(recvmmsg, int, fd, struct compat_mmsghdr __user *, mmsg,
>
> COMPAT_SYSCALL_DEFINE2(socketcall, int, call, u32 __user *, args)
> {
> - int ret;
> - u32 a[6];
> + u32 a[AUDITSC_ARGS];
> + unsigned int len;
> u32 a0, a1;
> + int ret;
>
> if (call < SYS_SOCKET || call > SYS_SENDMMSG)
> return -EINVAL;
> - if (copy_from_user(a, args, nas[call]))
> + len = nas[call];
> + if (len > sizeof(a))
> + return -EINVAL;
> +
> + if (copy_from_user(a, args, len))
> return -EFAULT;
> +
> + ret = audit_socketcall_compat(len / sizeof(a[0]), a);
> + if (ret)
> + return ret;
> +
> a0 = a[0];
> a1 = a[1];
>
> --
> 1.7.1
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: dsa: use cpu_switch instead of ds[0]
From: Florian Fainelli @ 2017-01-18 20:38 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot; +Cc: netdev, linux-kernel, kernel, David S. Miller
In-Reply-To: <20170118125057.GB7690@lunn.ch>
On 01/18/2017 04:50 AM, Andrew Lunn wrote:
> On Tue, Jan 17, 2017 at 08:41:39PM -0500, Vivien Didelot wrote:
>> Now that the DSA Ethernet switches are true Linux devices, the CPU
>> switch is not necessarily the first one. If its address is higher than
>> the second switch on the same MDIO bus, its index will be 1, not 0.
>>
>> Avoid any confusion by using dst->cpu_switch instead of dst->ds[0].
>>
>> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: resend: tcp: performance issue with fastopen connections (mss > window)
From: Neal Cardwell @ 2017-01-18 18:33 UTC (permalink / raw)
To: Eric Dumazet
Cc: Yuchung Cheng, Alexey Kodanev, Eric Dumazet, David Miller, netdev,
Vasily Isaenko
In-Reply-To: <CANn89i+5E0nXEox0EHU7s3me00KegXNA4ZeKQWxQoWRC4jNbHQ@mail.gmail.com>
On Wed, Jan 18, 2017 at 1:16 PM, Eric Dumazet <edumazet@google.com> wrote:
>
> On Wed, Jan 18, 2017 at 10:13 AM, Yuchung Cheng <ycheng@google.com> wrote:
> > On Wed, Jan 18, 2017 at 9:35 AM, Eric Dumazet <edumazet@google.com> wrote:
> >>
> >> On Wed, Jan 18, 2017 at 9:32 AM, Alexey Kodanev
> >> <alexey.kodanev@oracle.com> wrote:
> >> > Hi Eric,
> >> >
> >> > On 01/13/2017 08:07 PM, Alexey Kodanev wrote:
> >> >
> >>
> >> > Looks like max_window not correctly initialized for tfo sockets.
> >> > On my test machine it has set to '5592320' in tcp_fastopen_create_child().
> >> >
> >> > This diff fixes the issue, the question: is this the right place to do it?
> >> >
> >> > diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
> >> > index 4e777a3..33ed508 100644
> >> > --- a/net/ipv4/tcp_fastopen.c
> >> > +++ b/net/ipv4/tcp_fastopen.c
> >> > @@ -206,6 +206,8 @@ static struct sock *tcp_fastopen_create_child(struct
> >> > sock *sk,
> >> > */
> >> > tp->snd_wnd = ntohs(tcp_hdr(skb)->window);
> >> >
> >> > + tp->max_window = tp->snd_wnd;
> >> > +
> >>
> >> Excellent catch. Let me test our regression tests with this.
> > Indeed nice catch. Thanks for the investigative work!
> >
>
> We do have 2 failures, but tests might have depended on undocumented behavior
>
> (For googlers :
> Ran 211 tests: 209 passing, 0 flaky 2 failing
> Sponge: http://sponge/f1575065-6e1c-4514-bced-9167ce56d2ee
> )
Yes, exactly, those test failures look fine. Looks like the test was
implicitly expecting the old buggy behavior (and it wasn't noticed
because the 10*MSS output matches IW10, so it looked fine. But now
with the fix, I believe we are seeing the correct new behavior because
tcp_xmit_size_goal() is calling tcp_bound_to_half_wnd(), and now with
max_window fixed, the outgoing TSO skb is now the correct 5*MSS (half
of the rwin of 10000). So the test results look good to me.
Thanks, Alexey, for tracking this down! :-)
neal
^ permalink raw reply
* Re: [PATCH net] net: fix harmonize_features() vs NETIF_F_HIGHDMA
From: David Miller @ 2017-01-18 20:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: pshelar, ashiduka, fugang.duan, netdev, pshelar
In-Reply-To: <1484770337.13165.120.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 18 Jan 2017 12:12:17 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Ashizuka reported a highmem oddity and sent a patch for freescale
> fec driver.
>
> But the problem root cause is that core networking stack
> must ensure no skb with highmem fragment is ever sent through
> a device that does not assert NETIF_F_HIGHDMA in its features.
>
> We need to call illegal_highdma() from harmonize_features()
> regardless of CSUM checks.
>
> Fixes: ec5f06156423 ("net: Kill link between CSUM and SG features.")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Pravin Shelar <pshelar@ovn.org>
> Reported-by: "Ashizuka, Yuusuke" <ashiduka@jp.fujitsu.com>
Applied, thanks Eric.
I guess few devices support SG and lack highmem support.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: dsa: use cpu_switch instead of ds[0]
From: Florian Fainelli @ 2017-01-18 20:35 UTC (permalink / raw)
To: Vivien Didelot, netdev; +Cc: linux-kernel, kernel, David S. Miller, Andrew Lunn
In-Reply-To: <20170118014139.31417-2-vivien.didelot@savoirfairelinux.com>
On 01/17/2017 05:41 PM, Vivien Didelot wrote:
> Now that the DSA Ethernet switches are true Linux devices, the CPU
> switch is not necessarily the first one. If its address is higher than
> the second switch on the same MDIO bus, its index will be 1, not 0.
>
> Avoid any confusion by using dst->cpu_switch instead of dst->ds[0].
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: store CPU switch structure in the tree
From: Florian Fainelli @ 2017-01-18 20:35 UTC (permalink / raw)
To: Vivien Didelot, netdev; +Cc: linux-kernel, kernel, David S. Miller, Andrew Lunn
In-Reply-To: <20170118014139.31417-1-vivien.didelot@savoirfairelinux.com>
On 01/17/2017 05:41 PM, Vivien Didelot wrote:
> Store a dsa_switch pointer to the CPU switch in the tree instead of only
> its index. This avoids the need to initialize it to -1.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [PATCH net-next] vxlan: preserve type of dst_port parm for encap_bypass_if_local()
From: Lance Richardson @ 2017-01-18 20:24 UTC (permalink / raw)
To: netdev
Eliminate sparse warning by maintaining type of dst_port
as __be16.
Signed-off-by: Lance Richardson <lrichard@redhat.com>
---
drivers/net/vxlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index ca7196c..19b1653 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1951,7 +1951,7 @@ static void vxlan_encap_bypass(struct sk_buff *skb, struct vxlan_dev *src_vxlan,
static int encap_bypass_if_local(struct sk_buff *skb, struct net_device *dev,
struct vxlan_dev *vxlan, union vxlan_addr *daddr,
- __be32 dst_port, __be32 vni, struct dst_entry *dst,
+ __be16 dst_port, __be32 vni, struct dst_entry *dst,
u32 rt_flags)
{
#if IS_ENABLED(CONFIG_IPV6)
--
2.5.5
^ permalink raw reply related
* RE: [PATCH iproute2] Revert "man pages: add man page for skbmod action"
From: Rosen, Rami @ 2017-01-18 20:34 UTC (permalink / raw)
To: Jiri Benc, netdev@vger.kernel.org
Cc: Lucas Bates, Jamal Hadi Salim, Stephen Hemminger
In-Reply-To: <d73859201d17931dfe19e31227bf98ea725a1178.1484742998.git.jbenc@redhat.com>
Acked-by: Rami Rosen <rami.rosen@intel.com>
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Jiri Benc
Sent: Wednesday, January 18, 2017 14:37
To: netdev@vger.kernel.org
Cc: Lucas Bates <lucasb@mojatatu.com>; Jamal Hadi Salim <jhs@mojatatu.com>; Stephen Hemminger <stephen@networkplumber.org>
Subject: [PATCH iproute2] Revert "man pages: add man page for skbmod action"
This reverts commit a40995d1c79e5a1b8711f6cd26eca9807fc4dd50.
The patch is missing the actual tc-skbmod.8 file which causes 'make install' to fail:
install -m 0755 -d /tmp/ip/usr/share/man/man8 install -m 0644 ip-address.8 ip-link.8 ip-route.8 ip.8 arpd.8 lnstat.8
routel.8 rtacct.8 rtmon.8 rtpr.8 ss.8 tc.8 tc-bfifo.8 tc-bpf.8 tc-cbq.8
tc-cbq-details.8 tc-choke.8 tc-codel.8 tc-fq.8 tc-drr.8 tc-ematch.8
tc-fq_codel.8 tc-hfsc.8 tc-htb.8 tc-pie.8 tc-mqprio.8 tc-netem.8 tc-pfifo.8
tc-pfifo_fast.8 tc-prio.8 tc-red.8 tc-sfb.8 tc-sfq.8 tc-stab.8 tc-tbf.8
bridge.8 rtstat.8 ctstat.8 nstat.8 routef.8 ip-addrlabel.8 ip-fou.8 ip-gue.8
ip-l2tp.8 ip-macsec.8 ip-maddress.8 ip-monitor.8 ip-mroute.8 ip-neighbour.8
ip-netns.8 ip-ntable.8 ip-rule.8 ip-tunnel.8 ip-xfrm.8 ip-tcp_metrics.8
ip-netconf.8 ip-token.8 tipc.8 tipc-bearer.8 tipc-link.8 tipc-media.8
tipc-nametable.8 tipc-node.8 tipc-socket.8 tc-basic.8 tc-cgroup.8 tc-flow.8
tc-flower.8 tc-fw.8 tc-route.8 tc-tcindex.8 tc-u32.8 tc-matchall.8
tc-connmark.8 tc-csum.8 tc-mirred.8 tc-nat.8 tc-pedit.8 tc-police.8
tc-simple.8 tc-skbedit.8 tc-vlan.8 tc-xt.8 tc-ife.8 tc-skbmod.8
tc-tunnel_key.8 devlink.8 devlink-dev.8 devlink-monitor.8 devlink-port.8
devlink-sb.8 /tmp/ip/usr/share/man/man8
install: cannot stat ‘tc-skbmod.8’: No such file or directory
make[2]: *** [install] Error 1
make[1]: *** [install] Error 2
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
man/man8/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/man/man8/Makefile b/man/man8/Makefile index d4cb01ac3f13..77d347ca98fc 100644
--- a/man/man8/Makefile
+++ b/man/man8/Makefile
@@ -16,7 +16,7 @@ MAN8PAGES = $(TARGETS) ip.8 arpd.8 lnstat.8 routel.8 rtacct.8 rtmon.8 rtpr.8 ss.
tc-basic.8 tc-cgroup.8 tc-flow.8 tc-flower.8 tc-fw.8 tc-route.8 \
tc-tcindex.8 tc-u32.8 tc-matchall.8 \
tc-connmark.8 tc-csum.8 tc-mirred.8 tc-nat.8 tc-pedit.8 tc-police.8 \
- tc-simple.8 tc-skbedit.8 tc-vlan.8 tc-xt.8 tc-ife.8 tc-skbmod.8 \
+ tc-simple.8 tc-skbedit.8 tc-vlan.8 tc-xt.8 tc-ife.8 \
tc-tunnel_key.8 \
devlink.8 devlink-dev.8 devlink-monitor.8 devlink-port.8 devlink-sb.8
--
1.8.3.1
^ permalink raw reply
* Re: fq_codel and skb->hash
From: Eric Dumazet @ 2017-01-18 20:25 UTC (permalink / raw)
To: Andrew Collins; +Cc: Tom Herbert, Linux Kernel Network Developers, Eric Dumazet
In-Reply-To: <c8b93aa5-7e34-d6b0-aefc-6863e75402e0@cradlepoint.com>
On Wed, 2017-01-18 at 13:21 -0700, Andrew Collins wrote:
>
> Any interest in me spinning a real patch for this? I agree that it'd be better
> if we were guaranteed to get a pre-encryption flow hash for any IPsec traffic,
> but in my particular case I don't care, as I control the HW and can make it give
> me a hash. :)
You certainly can send this as a patch of its own.
The pre-encryption flow hash would be a separate patch and is not a
prereq.
Thanks.
^ permalink raw reply
* [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM
From: Remanan Pillai @ 2017-01-18 20:25 UTC (permalink / raw)
To: boris.ostrovsky, jgross, davem, xen-devel, netdev, linux-kernel
Cc: Vineeth Remanan Pillai, kamatam, aliguori
From: Vineeth Remanan Pillai <vineethp@amazon.com>
During an OOM scenario, request slots could not be created as skb
allocation fails. So the netback cannot pass in packets and netfront
wrongly assumes that there is no more work to be done and it disables
polling. This causes Rx to stall.
The issue is with the retry logic which schedules the timer if the
created slots are less than NET_RX_SLOTS_MIN. The count of new request
slots to be pushed are calculated as a difference between new req_prod
and rsp_cons which could be more than the actual slots, if there are
unconsumed responses.
The fix is to calculate the count of newly created slots as the
difference between new req_prod and old req_prod.
Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
Changes in v2:
- Removed the old implementation of enabling polling on
skb allocation error.
- Corrected the refill timer logic to schedule when newly
created slots since last push is less than NET_RX_SLOTS_MIN.
drivers/net/xen-netfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 40f26b6..2c7c29f 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -321,7 +321,7 @@ static void xennet_alloc_rx_buffers(struct netfront_queue *queue)
queue->rx.req_prod_pvt = req_prod;
/* Not enough requests? Try again later. */
- if (req_prod - queue->rx.rsp_cons < NET_RX_SLOTS_MIN) {
+ if (req_prod - queue->rx.sring->req_prod < NET_RX_SLOTS_MIN) {
mod_timer(&queue->rx_refill_timer, jiffies + (HZ/10));
return;
}
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM
From: Vineeth Remanan Pillai @ 2017-01-18 20:24 UTC (permalink / raw)
To: David Miller
Cc: jgross, netdev, kamatam, linux-kernel, aliguori, xen-devel,
boris.ostrovsky
In-Reply-To: <20170118.151000.1216322099401442834.davem@davemloft.net>
On 01/18/2017 12:10 PM, David Miller wrote:
> This v2 never made it into patchwork. I don't know why, so please resend it to
> netdev with the accumulated reviewed-by etc. tags added.
>
> Thanks.
Sorry about that. Will resend as a separate thread right away.
Thanks
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH] net: fec: Fixed panic problem with non-tso
From: Eric Dumazet @ 2017-01-18 19:51 UTC (permalink / raw)
To: Pravin Shelar
Cc: Ashizuka, Yuusuke, Andy Duan, netdev@vger.kernel.org,
Pravin B Shelar
In-Reply-To: <CAOrHB_A-oJid6RTeQB_xy0GDKsJjvEDwdTepMXN336qSi5h8AA@mail.gmail.com>
On Wed, 2017-01-18 at 10:18 -0800, Pravin Shelar wrote:
\
> Right, this high mem check should be decoupled from csum check.
I must say I am surprised nobody hit this problem before today.
linux-3.10 is more than 3 years old.
^ permalink raw reply
* [PATCH net] net: fix harmonize_features() vs NETIF_F_HIGHDMA
From: Eric Dumazet @ 2017-01-18 20:12 UTC (permalink / raw)
To: Pravin Shelar, David Miller
Cc: Ashizuka, Yuusuke, Andy Duan, netdev@vger.kernel.org,
Pravin B Shelar
In-Reply-To: <1484769077.13165.111.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
Ashizuka reported a highmem oddity and sent a patch for freescale
fec driver.
But the problem root cause is that core networking stack
must ensure no skb with highmem fragment is ever sent through
a device that does not assert NETIF_F_HIGHDMA in its features.
We need to call illegal_highdma() from harmonize_features()
regardless of CSUM checks.
Fixes: ec5f06156423 ("net: Kill link between CSUM and SG features.")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Pravin Shelar <pshelar@ovn.org>
Reported-by: "Ashizuka, Yuusuke" <ashiduka@jp.fujitsu.com>
---
net/core/dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 07b307b0b414730688b64fdb2295b0fa1b721e51..7f218e095361520d11c243d650e053321ea7274f 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2795,9 +2795,9 @@ static netdev_features_t harmonize_features(struct sk_buff *skb,
if (skb->ip_summed != CHECKSUM_NONE &&
!can_checksum_protocol(features, type)) {
features &= ~(NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK);
- } else if (illegal_highdma(skb->dev, skb)) {
- features &= ~NETIF_F_SG;
}
+ if (illegal_highdma(skb->dev, skb))
+ features &= ~NETIF_F_SG;
return features;
}
^ permalink raw reply related
* Re: [PATCH v2 0/2] xen-netback: fix memory leaks on XenBus disconnect
From: David Miller @ 2017-01-18 20:11 UTC (permalink / raw)
To: igor.druzhinin; +Cc: xen-devel, Paul.Durrant, wei.liu2, linux-kernel, netdev
In-Reply-To: <1484686178-76959-1-git-send-email-igor.druzhinin@citrix.com>
From: Igor Druzhinin <igor.druzhinin@citrix.com>
Date: Tue, 17 Jan 2017 20:49:36 +0000
> Just split the initial patch in two as proposed by Wei.
>
> Since the approach for locking netdev statistics is inconsistent (tends not
> to have any locking at all) accross the kernel we'd better to rely on our
> internal lock for this purpose.
Series applied, thanks.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM
From: David Miller @ 2017-01-18 20:10 UTC (permalink / raw)
To: vineethp
Cc: jgross, netdev, kamatam, linux-kernel, aliguori, xen-devel,
boris.ostrovsky
In-Reply-To: <79c6ecce-bfcb-ebaa-afd2-05c1d86004d7@amazon.com>
This v2 never made it into patchwork. I don't know why, so please resend it to
netdev with the accumulated reviewed-by etc. tags added.
Thanks.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM
From: David Miller @ 2017-01-18 20:08 UTC (permalink / raw)
To: vineethp
Cc: jgross, netdev, kamatam, linux-kernel, aliguori, xen-devel,
boris.ostrovsky
In-Reply-To: <79c6ecce-bfcb-ebaa-afd2-05c1d86004d7@amazon.com>
From: Vineeth Remanan Pillai <vineethp@amazon.com>
Date: Wed, 18 Jan 2017 09:02:17 -0800
>
> On 01/15/2017 10:24 PM, Juergen Gross wrote:
>> On 13/01/17 18:55, Remanan Pillai wrote:
>>> From: Vineeth Remanan Pillai <vineethp@amazon.com>
>>>
>>> During an OOM scenario, request slots could not be created as skb
>>> allocation fails. So the netback cannot pass in packets and netfront
>>> wrongly assumes that there is no more work to be done and it disables
>>> polling. This causes Rx to stall.
>>>
>>> The issue is with the retry logic which schedules the timer if the
>>> created slots are less than NET_RX_SLOTS_MIN. The count of new request
>>> slots to be pushed are calculated as a difference between new req_prod
>>> and rsp_cons which could be more than the actual slots, if there are
>>> unconsumed responses.
>>>
>>> The fix is to calculate the count of newly created slots as the
>>> difference between new req_prod and old req_prod.
>>>
>>> Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
>> Reviewed-by: Juergen Gross <jgross@suse.com>
> Thanks Juergen.
>
> David,
>
> Could you please pick up this change for net-next if there no more
> concerns..
Why would I pick up "this change", if the author of the patch has
stated that he will resubmit the change implemented differently based
upon my feedback?
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH net 0/3] ethtool fix
From: David Miller @ 2017-01-18 19:58 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe
In-Reply-To: <1484673559-21687-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Tue, 17 Jan 2017 19:19:16 +0200
> This patchset from Eran contains a fix to ethtool set_channels, where the call
> to get_channels with an uninitialized parameter might result in garbage fields.
> It also contains two followup changes in our mlx4/mlx5 Eth drivers.
>
> Series generated against net commit:
> 0faa9cb5b383 net sched actions: fix refcnt when GETing of action after bind
Looks good, series applied, thanks.
^ permalink raw reply
* Re: [PATCH] netfilter: ipt_CLUSTERIP: fix build error without procfs
From: Pablo Neira Ayuso @ 2017-01-18 19:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Patrick McHardy, Jozsef Kadlecsik, David S. Miller,
Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI, Xin Long,
netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <20170113154204.2737978-1-arnd@arndb.de>
On Fri, Jan 13, 2017 at 04:41:03PM +0100, Arnd Bergmann wrote:
> We can't access c->pde if CONFIG_PROC_FS is disabled:
>
> net/ipv4/netfilter/ipt_CLUSTERIP.c: In function 'clusterip_config_find_get':
> net/ipv4/netfilter/ipt_CLUSTERIP.c:147:9: error: 'struct clusterip_config' has no member named 'pde'
>
> This moves the check inside of another #ifdef.
>
> Fixes: 6c5d5cfbe3c5 ("netfilter: ipt_CLUSTERIP: check duplicate config when initializing")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks Arnd.
^ permalink raw reply
* Re: [PATCHv4 net-next 0/6] sctp: add sender-side procedures for stream reconf ssn reset request chunk
From: David Miller @ 2017-01-18 19:55 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman, vyasevich
In-Reply-To: <cover.1484670664.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Wed, 18 Jan 2017 00:44:41 +0800
> Patch 6/6 is to implement sender-side procedures for the Outgoing
> and Incoming SSN Reset Request Parameter described in rfc6525
> section 5.1.2 and 5.1.3
>
> Patches 1-5/6 are ahead of it to define some apis and asoc members
> for it.
>
> Note that with this patchset, asoc->reconf_enable has no chance yet to
> be set, until the patch "sctp: add get and set sockopt for reconf_enable"
> is applied in the future. As we can not just enable it when sctp is not
> capable of processing reconf chunk yet.
>
> v1->v2:
> - put these into a smaller group.
> - rename some temporary variables in the codes.
> - rename the titles of the commits and improve some changelogs.
> v2->v3:
> - re-split the patchset and make sure it has no dead codes for review.
> v3->v4:
> - move sctp_make_reconf() into patch 1/6 to avoid kbuild warning.
> - drop unused struct sctp_strreset_req.
Series applied, thank you.
^ permalink raw reply
* Re: [Xen-devel] xennet_start_xmit assumptions
From: Konrad Rzeszutek Wilk @ 2017-01-18 19:25 UTC (permalink / raw)
To: Sowmini Varadhan, wei.liu2, paul.durrant; +Cc: netdev, xen-devel
In-Reply-To: <20170118153132.GB9258@oracle.com>
On Wed, Jan 18, 2017 at 10:31:32AM -0500, Sowmini Varadhan wrote:
> As I was playing around with pf_packet, I accidentally wrote
> a buggy application program that bzero'ed the msghdr, then set
> up the msg_name, msg_namelen correctly, and then did a sendmsg
> on the pf_packet/SOCK_RAW fd.
>
> This causes packet_snd to set up an skb with a lot of issues,
> e.g., skb->len = 0, skb_headlen(skb) is 0, etc. I think we can/should
> drop the packet in packet_snd if the skb->len is 0, but there
> may be other driver bugs going on:
>
> Turns out that ixgbe and sunvnet handle this problematic
> skb correctly (they drop it and system remains stable),
> but it creates a panic in xen_netfront (xennet_start_xmit()
> hits a null pointer deref when xennet_make_first_txreq() returns
> NULL)
>
> I'm new to the xen driver code, so I'm hoping that
> the experts can comment here: reading the code in xennet_start_xmit,
> it seems like it mandatorily requires the skb_headlen() to be
> non-zero in order to create the first_tx? That may not always be
> true, how does the code recover for purely non-linear skbs?
>
> --Sowmini
CC-ing the two folks from the MAINTAINERS file.
^ permalink raw reply
* Re: Initializing MAC address at run-time
From: Uwe Kleine-König @ 2017-01-18 18:54 UTC (permalink / raw)
To: Mason
Cc: Mark Rutland, DT, Arnd Bergmann, Kevin Hilman, netdev,
Thibaud Cornic, Linux ARM
In-Reply-To: <e083ed68-0e8e-380e-23bd-5ad387c88575@free.fr>
Hello,
On Wed, Jan 18, 2017 at 03:03:57PM +0100, Mason wrote:
> When my system boots up, eth0 is given a seemingly random MAC address.
>
> [ 0.950734] nb8800 26000.ethernet eth0: MAC address ba:de:d6:38:b8:38
> [ 0.957334] nb8800 26000.ethernet eth0: MAC address 6e:f1:48:de:d6:c4
>
>
> The DT node for eth0 is:
>
> eth0: ethernet@26000 {
> compatible = "sigma,smp8734-ethernet";
> reg = <0x26000 0x800>;
> interrupts = <38 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clkgen SYS_CLK>;
> };
>
> Documentation/devicetree/bindings/net/ethernet.txt mentions
> - local-mac-address: array of 6 bytes, specifies the MAC address that was
> assigned to the network device;
>
> And indeed, if I define this property, eth0 ends up with the MAC address
> I specify in the device tree. But of course, I don't want all my boards
> to share the same MAC address. Every interface has a unique MAC address.
>
> In fact, the boot loader (not Uboot, a custom non-DT boot loader) stores
> the MAC address somewhere in MMIO space, in some weird custom format.
Where does your machine get the dtb from? You write it to the boot
medium at a certain point of time I assume. So AFAICT you have the
following options (in no particular order):
a) Describe in the dtb how to find out how the MAC address is stored
(already pointed out Mark and Robin)
b) Make your bootloader dt aware and let it provide the
local-mac-address property.
c) Adapt the dtb before it is written to the boot medium.
d) Let the bootloader configure the device and teach the driver to pick
up the mac from the device's address space.
e) Accept that the mac address is random during development, and make
Userspace configure the MAC address, which is early enough for
production use.
Not sure d) is considered ok today, but some drivers have this feature.
I'd say b) is the best choice.
> I need to do something similar with the NAND partitions. The boot loader
> stores the partition offsets somewhere, and I need to pass this info
> to the NAND framework, so I assumed that inserting the corresponding
> properties at run-time was the correct way to do it.
The list of options here is similar to the list above. d) doesn't work,
but instead you can pass the partitioning on the kernel commandline.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [net-next 2/4] tipc: add functionality to lookup multicast destination nodes
From: Jon Maloy @ 2017-01-18 18:50 UTC (permalink / raw)
To: davem
Cc: netdev, parthasarathy.bhuvaragan, ying.xue, maloy,
tipc-discussion, Jon Maloy
In-Reply-To: <1484765453-16258-1-git-send-email-jon.maloy@ericsson.com>
As a further preparation for the upcoming 'replicast' functionality,
we add some necessary structs and functions for looking up and returning
a list of all nodes that host destinations for a given multicast message.
Reviewed-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
net/tipc/bcast.c | 33 +++++++++++++++++++++++++++++++--
net/tipc/bcast.h | 15 ++++++++++++++-
net/tipc/name_table.c | 38 +++++++++++++++++++++++++++++++++-----
net/tipc/name_table.h | 9 +++++++++
4 files changed, 87 insertions(+), 8 deletions(-)
diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
index 3256276..412d335 100644
--- a/net/tipc/bcast.c
+++ b/net/tipc/bcast.c
@@ -39,9 +39,8 @@
#include "socket.h"
#include "msg.h"
#include "bcast.h"
-#include "name_distr.h"
#include "link.h"
-#include "node.h"
+#include "name_table.h"
#define BCLINK_WIN_DEFAULT 50 /* bcast link window size (default) */
#define BCLINK_WIN_MIN 32 /* bcast minimum link window size */
@@ -434,3 +433,33 @@ void tipc_bcast_stop(struct net *net)
kfree(tn->bcbase);
kfree(tn->bcl);
}
+
+void tipc_nlist_init(struct tipc_nlist *nl, u32 self)
+{
+ memset(nl, 0, sizeof(*nl));
+ INIT_LIST_HEAD(&nl->list);
+ nl->self = self;
+}
+
+void tipc_nlist_add(struct tipc_nlist *nl, u32 node)
+{
+ if (node == nl->self)
+ nl->local = true;
+ else if (u32_push(&nl->list, node))
+ nl->remote++;
+}
+
+void tipc_nlist_del(struct tipc_nlist *nl, u32 node)
+{
+ if (node == nl->self)
+ nl->local = false;
+ else if (u32_del(&nl->list, node))
+ nl->remote--;
+}
+
+void tipc_nlist_purge(struct tipc_nlist *nl)
+{
+ u32_list_purge(&nl->list);
+ nl->remote = 0;
+ nl->local = 0;
+}
diff --git a/net/tipc/bcast.h b/net/tipc/bcast.h
index 855d53c..18f3791 100644
--- a/net/tipc/bcast.h
+++ b/net/tipc/bcast.h
@@ -42,9 +42,22 @@
struct tipc_node;
struct tipc_msg;
struct tipc_nl_msg;
-struct tipc_node_map;
+struct tipc_nlist;
+struct tipc_nitem;
extern const char tipc_bclink_name[];
+struct tipc_nlist {
+ struct list_head list;
+ u32 self;
+ u16 remote;
+ bool local;
+};
+
+void tipc_nlist_init(struct tipc_nlist *nl, u32 self);
+void tipc_nlist_purge(struct tipc_nlist *nl);
+void tipc_nlist_add(struct tipc_nlist *nl, u32 node);
+void tipc_nlist_del(struct tipc_nlist *nl, u32 node);
+
int tipc_bcast_init(struct net *net);
void tipc_bcast_stop(struct net *net);
void tipc_bcast_add_peer(struct net *net, struct tipc_link *l,
diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index 5a86df1..9be6592 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -645,6 +645,39 @@ int tipc_nametbl_mc_translate(struct net *net, u32 type, u32 lower, u32 upper,
return res;
}
+/* tipc_nametbl_lookup_dst_nodes - find broadcast destination nodes
+ * - Creates list of nodes that overlap the given multicast address
+ * - Determines if any node local ports overlap
+ */
+void tipc_nametbl_lookup_dst_nodes(struct net *net, u32 type, u32 lower,
+ u32 upper, u32 domain,
+ struct tipc_nlist *nodes)
+{
+ struct sub_seq *sseq, *stop;
+ struct publication *publ;
+ struct name_info *info;
+ struct name_seq *seq;
+
+ rcu_read_lock();
+ seq = nametbl_find_seq(net, type);
+ if (!seq)
+ goto exit;
+
+ spin_lock_bh(&seq->lock);
+ sseq = seq->sseqs + nameseq_locate_subseq(seq, lower);
+ stop = seq->sseqs + seq->first_free;
+ for (; sseq->lower <= upper && sseq != stop; sseq++) {
+ info = sseq->info;
+ list_for_each_entry(publ, &info->zone_list, zone_list) {
+ if (tipc_in_scope(domain, publ->node))
+ tipc_nlist_add(nodes, publ->node);
+ }
+ }
+ spin_unlock_bh(&seq->lock);
+exit:
+ rcu_read_unlock();
+}
+
/*
* tipc_nametbl_publish - add name publication to network name tables
*/
@@ -1022,11 +1055,6 @@ int tipc_nl_name_table_dump(struct sk_buff *skb, struct netlink_callback *cb)
return skb->len;
}
-struct u32_item {
- struct list_head list;
- u32 value;
-};
-
bool u32_find(struct list_head *l, u32 value)
{
struct u32_item *item;
diff --git a/net/tipc/name_table.h b/net/tipc/name_table.h
index c89bb3f..6ebdeb1 100644
--- a/net/tipc/name_table.h
+++ b/net/tipc/name_table.h
@@ -39,6 +39,7 @@
struct tipc_subscription;
struct tipc_plist;
+struct tipc_nlist;
/*
* TIPC name types reserved for internal TIPC use (both current and planned)
@@ -100,6 +101,9 @@ int tipc_nl_name_table_dump(struct sk_buff *skb, struct netlink_callback *cb);
u32 tipc_nametbl_translate(struct net *net, u32 type, u32 instance, u32 *node);
int tipc_nametbl_mc_translate(struct net *net, u32 type, u32 lower, u32 upper,
u32 limit, struct list_head *dports);
+void tipc_nametbl_lookup_dst_nodes(struct net *net, u32 type, u32 lower,
+ u32 upper, u32 domain,
+ struct tipc_nlist *nodes);
struct publication *tipc_nametbl_publish(struct net *net, u32 type, u32 lower,
u32 upper, u32 scope, u32 port_ref,
u32 key);
@@ -116,6 +120,11 @@ void tipc_nametbl_unsubscribe(struct tipc_subscription *s);
int tipc_nametbl_init(struct net *net);
void tipc_nametbl_stop(struct net *net);
+struct u32_item {
+ struct list_head list;
+ u32 value;
+};
+
bool u32_push(struct list_head *l, u32 value);
u32 u32_pop(struct list_head *l);
bool u32_find(struct list_head *l, u32 value);
--
2.7.4
^ permalink raw reply related
* [net-next 0/4] tipc: emulate multicast through replication
From: Jon Maloy @ 2017-01-18 18:50 UTC (permalink / raw)
To: davem
Cc: netdev, parthasarathy.bhuvaragan, ying.xue, maloy,
tipc-discussion, Jon Maloy
TIPC multicast messages are currently distributed via L2 broadcast
or IP multicast to all nodes in the cluster, irrespective of the
number of real destinations of the message.
In this series we introduce an option to transport messages via
replication ("replicast") across a selected number of unicast links,
instead of relying on the underlying media. This option is used when
true broadcast/multicast is not supported by the media, or when the
number of true destinations is much smaller than the cluster size.
Jon Maloy (4):
tipc: add function for checking broadcast support in bearer
tipc: add functionality to lookup multicast destination nodes
tipc: introduce replicast as transport option for multicast
tipc: make replicast a user selectable option
include/uapi/linux/tipc.h | 6 +-
net/tipc/bcast.c | 200 +++++++++++++++++++++++++++++++++++++++-------
net/tipc/bcast.h | 33 +++++++-
net/tipc/bearer.c | 15 +++-
net/tipc/bearer.h | 8 +-
net/tipc/link.c | 12 ++-
net/tipc/msg.c | 17 ++++
net/tipc/msg.h | 9 +--
net/tipc/name_table.c | 38 +++++++--
net/tipc/name_table.h | 9 +++
net/tipc/node.c | 27 ++++---
net/tipc/node.h | 4 +-
net/tipc/socket.c | 61 ++++++++++----
net/tipc/udp_media.c | 8 +-
14 files changed, 374 insertions(+), 73 deletions(-)
--
2.7.4
^ 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