* [net:master 113/114] drivers/net/vxlan.c:947:21: warning: unused variable 'sock6'
From: kbuild test robot @ 2016-10-30 1:16 UTC (permalink / raw)
To: pravin shelar; +Cc: kbuild-all, netdev
[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
head: fceb9c3e38252992bbf1a3028cc2f7b871211533
commit: c6fcc4fc5f8b592600c7409e769ab68da0fb1eca [113/114] vxlan: avoid using stale vxlan socket.
config: i386-randconfig-x012-201644 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout c6fcc4fc5f8b592600c7409e769ab68da0fb1eca
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/net/vxlan.c: In function 'vxlan_group_used':
>> drivers/net/vxlan.c:947:21: warning: unused variable 'sock6' [-Wunused-variable]
struct vxlan_sock *sock6 = NULL;
^~~~~
vim +/sock6 +947 drivers/net/vxlan.c
931 NUD_REACHABLE,
932 NLM_F_EXCL|NLM_F_CREATE,
933 vxlan->cfg.dst_port,
934 vxlan->default_dst.remote_vni,
935 0, NTF_SELF);
936 spin_unlock(&vxlan->hash_lock);
937 }
938
939 return false;
940 }
941
942 /* See if multicast group is already in use by other ID */
943 static bool vxlan_group_used(struct vxlan_net *vn, struct vxlan_dev *dev)
944 {
945 struct vxlan_dev *vxlan;
946 struct vxlan_sock *sock4;
> 947 struct vxlan_sock *sock6 = NULL;
948 unsigned short family = dev->default_dst.remote_ip.sa.sa_family;
949
950 sock4 = rtnl_dereference(dev->vn4_sock);
951
952 /* The vxlan_sock is only used by dev, leaving group has
953 * no effect on other vxlan devices.
954 */
955 if (family == AF_INET && sock4 && atomic_read(&sock4->refcnt) == 1)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28871 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] genetlink: Fix generic netlink family unregister
From: David Miller @ 2016-10-30 0:58 UTC (permalink / raw)
To: pshelar; +Cc: netdev, johannes
In-Reply-To: <1477695701-1147-1-git-send-email-pshelar@ovn.org>
From: Pravin B Shelar <pshelar@ovn.org>
Date: Fri, 28 Oct 2016 16:01:41 -0700
> This patch fixes a typo in unregister operation.
>
> Following crash is fixed by this patch. It can be easily reproduced
> by repeating modprobe and rmmod module that uses genetlink.
...
> Fixes: 2ae0f17df1c ("genetlink: use idr to track families").
>
> Reported-by: Jarno Rajahalme <jarno@ovn.org>
> CC: Johannes Berg <johannes@sipsolutions.net>
> Signed-off-by: Pravin B Shelar <pshelar@ovn.org>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v2 net 2/2] geneve: avoid using stale geneve socket.
From: David Miller @ 2016-10-30 0:56 UTC (permalink / raw)
To: pshelar; +Cc: netdev
In-Reply-To: <1477673956-127319-2-git-send-email-pshelar@ovn.org>
From: Pravin B Shelar <pshelar@ovn.org>
Date: Fri, 28 Oct 2016 09:59:16 -0700
> This patch is similar to earlier vxlan patch.
> Geneve device close operation frees geneve socket. This
> operation can race with geneve-xmit function which
> dereferences geneve socket. Following patch uses RCU
> mechanism to avoid this situation.
>
> Signed-off-by: Pravin B Shelar <pshelar@ovn.org>
> Acked-by: John W. Linville <linville@tuxdriver.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net 1/2] vxlan: avoid using stale vxlan socket.
From: David Miller @ 2016-10-30 0:56 UTC (permalink / raw)
To: pshelar; +Cc: netdev
In-Reply-To: <1477673956-127319-1-git-send-email-pshelar@ovn.org>
From: Pravin B Shelar <pshelar@ovn.org>
Date: Fri, 28 Oct 2016 09:59:15 -0700
> When vxlan device is closed vxlan socket is freed. This
> operation can race with vxlan-xmit function which
> dereferences vxlan socket. Following patch uses RCU
> mechanism to avoid this situation.
>
> Signed-off-by: Pravin B Shelar <pshelar@ovn.org>
Applied.
^ permalink raw reply
* Re: [PATCH net] qede: Fix out-of-bound fastpath memory access
From: David Miller @ 2016-10-30 0:52 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: netdev
In-Reply-To: <1477749875-30529-1-git-send-email-Yuval.Mintz@cavium.com>
From: Yuval Mintz <Yuval.Mintz@cavium.com>
Date: Sat, 29 Oct 2016 17:04:35 +0300
> Driver allocates a shadow array for transmitted SKBs with X entries;
> That means valid indices are {0,...,X - 1}. [X == 8191]
> Problem is the driver also uses X as a mask for a
> producer/consumer in order to choose the right entry in the
> array which allows access to entry X which is out of bounds.
>
> To fix this, simply allocate X + 1 entries in the shadow array.
>
> Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ibmveth: v1 calculate correct gso_size and set gso_type
From: Jonathan Maxwell @ 2016-10-30 0:21 UTC (permalink / raw)
To: Eric Dumazet
Cc: Thomas Falcon, Jon Maxwell, hofrat, linux-kernel, jarod, netdev,
paulus, Tom Herbert, Marcelo Ricardo Leitner, linuxppc-dev,
David Miller
In-Reply-To: <1477591717.7065.237.camel@edumazet-glaptop3.roam.corp.google.com>
On Fri, Oct 28, 2016 at 5:08 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2016-10-27 at 12:54 -0500, Thomas Falcon wrote:
>> On 10/27/2016 10:26 AM, Eric Dumazet wrote:
>> > On Wed, 2016-10-26 at 11:09 +1100, Jon Maxwell wrote:
>> >> We recently encountered a bug where a few customers using ibmveth on the
>> >> same LPAR hit an issue where a TCP session hung when large receive was
>> >> enabled. Closer analysis revealed that the session was stuck because the
>> >> one side was advertising a zero window repeatedly.
>> >>
>> >> We narrowed this down to the fact the ibmveth driver did not set gso_size
>> >> which is translated by TCP into the MSS later up the stack. The MSS is
>> >> used to calculate the TCP window size and as that was abnormally large,
>> >> it was calculating a zero window, even although the sockets receive buffer
>> >> was completely empty.
>> >>
>> >> We were able to reproduce this and worked with IBM to fix this. Thanks Tom
>> >> and Marcelo for all your help and review on this.
>> >>
>> >> The patch fixes both our internal reproduction tests and our customers tests.
>> >>
>> >> Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
>> >> ---
>> >> drivers/net/ethernet/ibm/ibmveth.c | 20 ++++++++++++++++++++
>> >> 1 file changed, 20 insertions(+)
>> >>
>> >> diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c
>> >> index 29c05d0..c51717e 100644
>> >> --- a/drivers/net/ethernet/ibm/ibmveth.c
>> >> +++ b/drivers/net/ethernet/ibm/ibmveth.c
>> >> @@ -1182,6 +1182,8 @@ static int ibmveth_poll(struct napi_struct *napi, int budget)
>> >> int frames_processed = 0;
>> >> unsigned long lpar_rc;
>> >> struct iphdr *iph;
>> >> + bool large_packet = 0;
>> >> + u16 hdr_len = ETH_HLEN + sizeof(struct tcphdr);
>> >>
>> >> restart_poll:
>> >> while (frames_processed < budget) {
>> >> @@ -1236,10 +1238,28 @@ static int ibmveth_poll(struct napi_struct *napi, int budget)
>> >> iph->check = 0;
>> >> iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl);
>> >> adapter->rx_large_packets++;
>> >> + large_packet = 1;
>> >> }
>> >> }
>> >> }
>> >>
>> >> + if (skb->len > netdev->mtu) {
>> >> + iph = (struct iphdr *)skb->data;
>> >> + if (be16_to_cpu(skb->protocol) == ETH_P_IP &&
>> >> + iph->protocol == IPPROTO_TCP) {
>> >> + hdr_len += sizeof(struct iphdr);
>> >> + skb_shinfo(skb)->gso_type = SKB_GSO_TCPV4;
>> >> + skb_shinfo(skb)->gso_size = netdev->mtu - hdr_len;
>> >> + } else if (be16_to_cpu(skb->protocol) == ETH_P_IPV6 &&
>> >> + iph->protocol == IPPROTO_TCP) {
>> >> + hdr_len += sizeof(struct ipv6hdr);
>> >> + skb_shinfo(skb)->gso_type = SKB_GSO_TCPV6;
>> >> + skb_shinfo(skb)->gso_size = netdev->mtu - hdr_len;
>> >> + }
>> >> + if (!large_packet)
>> >> + adapter->rx_large_packets++;
>> >> + }
>> >> +
>> >>
>> > This might break forwarding and PMTU discovery.
>> >
>> > You force gso_size to device mtu, regardless of real MSS used by the TCP
>> > sender.
>> >
>> > Don't you have the MSS provided in RX descriptor, instead of guessing
>> > the value ?
>> >
>> >
>> >
>> The MSS is not always available unfortunately, so this is the best solution there is at the moment.
>
> Hmm... then what about skb_shinfo(skb)->gso_segs ?
>
> ip_rcv() for example has :
>
> __IP_ADD_STATS(net,
> IPSTATS_MIB_NOECTPKTS + (iph->tos & INET_ECN_MASK),
> max_t(unsigned short, 1, skb_shinfo(skb)->gso_segs));
>
>
Okay thanks Eric. As the MSS is the main concern, let me work with the
team here and see if we find can a better way to do this. Will take care of
the other points you raised at the same time.
>
> Also prefer : (skb->protocol == htons(ETH_P_IP)) tests
>
> And the ipv6 test is wrong :
>
> } else if (be16_to_cpu(skb->protocol) == ETH_P_IPV6 &&
> iph->protocol == IPPROTO_TCP) {
>
>
> Since iph is a pointer to ipv4 iphdr .
>
>
>
^ permalink raw reply
* Re: [PATCH net-next 2/2] net/mlx4_en: Refactor the XDP forwarding rings scheme
From: Brenden Blanco @ 2016-10-29 23:18 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: Tariq Toukan, David S. Miller, netdev, Eran Ben Elisha
In-Reply-To: <20161028010701.GB49550@ast-mbp.thefacebook.com>
On Thu, Oct 27, 2016 at 06:07:02PM -0700, Alexei Starovoitov wrote:
> On Thu, Oct 27, 2016 at 05:52:04PM +0300, Tariq Toukan wrote:
> > Separately manage the two types of TX rings: regular ones, and XDP.
> > Upon an XDP set, do not borrow regular TX rings and convert them
> > into XDP ones, but allocate new ones, unless we hit the max number
> > of rings.
> > Which means that in systems with smaller #cores we will not consume
> > the current TX rings for XDP, while we are still in the num TX limit.
>
> The commit log is too scarce for details...
> So questions:
> - Did you test with changing the number of channels after xdp prog is loaded?
> That was the recent bug that Brenden fixed.
> - does it still have 256 tx queue limit or xdp tx rings can go over?
> - Any performance implications ?
>
> Brenden, could you please review this patch?
Sure, sorry for the delay...was traveling.
>
^ permalink raw reply
* Re: [PATCH net-next 1/1] net: phy: Add support for Microsemi VSC 8530/40 Fast Ethernet PHY
From: David Miller @ 2016-10-29 21:31 UTC (permalink / raw)
To: allan.nielsen; +Cc: netdev, andrew, raju.lakkaraju
In-Reply-To: <1477649411-31036-2-git-send-email-allan.nielsen@microsemi.com>
From: "Allan W. Nielsen" <allan.nielsen@microsemi.com>
Date: Fri, 28 Oct 2016 12:10:11 +0200
> From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
>
> Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
> Signed-off-by: Allan W. Nielsen <allan.nielsen@microsemi.com>
Applied.
^ permalink raw reply
* Re: pull-request: mac80211-next 2016-10-28
From: David Miller @ 2016-10-29 21:27 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161028070614.17583-1-johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date: Fri, 28 Oct 2016 09:06:13 +0200
> First update for 4.10 - nothing major, new features as usual (FILS), and
> sometimes we deprecate old stuff (WDS).
>
> I don't have the fixes for the on-stack crypto/SG handling in this tree
> (you already have them via mac80211.git), but we did make sure that the
> fils_aead code doesn't re-introduce such an issue.
>
> Please pull and let me know if there's any problem.
Pulled, thanks Johannes.
^ permalink raw reply
* Re: [PATCH] net: phy: dp83848: add dp83822 PHY support
From: David Miller @ 2016-10-29 21:26 UTC (permalink / raw)
To: rogerq; +Cc: f.fainelli, afd, dmurphy, netdev, linux-kernel
In-Reply-To: <1477647620-7315-1-git-send-email-rogerq@ti.com>
From: Roger Quadros <rogerq@ti.com>
Date: Fri, 28 Oct 2016 12:40:20 +0300
> This PHY has a compatible register set with DP83848x so
> add support for it.
>
> Acked-by: Andrew F. Davis <afd@ti.com>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] enic: fix rq disable
From: David Miller @ 2016-10-29 21:25 UTC (permalink / raw)
To: gvaradar; +Cc: netdev, benve, _govind
In-Reply-To: <20161027230103.35242-1-gvaradar@cisco.com>
From: Govindarajulu Varadarajan <gvaradar@cisco.com>
Date: Thu, 27 Oct 2016 16:01:03 -0700
> When MTU is changed from 9000 to 1500 while there is burst of inbound 9000
> bytes packets, adaptor sometimes delivers 9000 bytes packets to 1500 bytes
> buffers. This causes memory corruption and sometimes crash.
>
> This is because of a race condition in adaptor between "RQ disable"
> clearing descriptor mini-cache and mini-cache valid bit being set by
> completion of descriptor fetch. This can result in stale RQ desc being
> cached and used when packets arrive. In this case, the stale descriptor
> have old MTU value.
>
> Solution is to write RQ->disable twice. The first write will stop any
> further desc fetches, allowing the second disable to clear the mini-cache
> valid bit without danger of a race.
>
> Also, the check for rq->running becoming 0 after writing rq->enable to 0
> is not done properly. When incoming packets are flooding the interface,
> rq->running will pulse high for each dropped packet. Since the driver was
> waiting for 10us between each poll, it is possible to see rq->running = 1
> 1000 times in a row, even though it is not actually stuck running.
> This results in false failure of vnic_rq_disable(). Fix is to try more
> than 1000 time without delay between polls to ensure we do not miss when
> running goes low.
>
> In old adaptors rq->enable needs to be re-written to 0 when posted_index
> is reset in vnic_rq_clean() in order to keep rq->prefetch_index in sync.
>
> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 1/1] tipc: fix broadcast link synchronization problem
From: David Miller @ 2016-10-29 21:21 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, paul.gortmaker, parthasarathy.bhuvaragan, ying.xue, maloy,
tipc-discussion
In-Reply-To: <1477608715-28003-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Thu, 27 Oct 2016 18:51:55 -0400
> In commit 2d18ac4ba745 ("tipc: extend broadcast link initialization
> criteria") we tried to fix a problem with the initial synchronization
> of broadcast link acknowledge values. Unfortunately that solution is
> not sufficient to solve the issue.
>
> We have seen it happen that LINK_PROTOCOL/STATE packets with a valid
> non-zero unicast acknowledge number may bypass BCAST_PROTOCOL
> initialization, NAME_DISTRIBUTOR and other STATE packets with invalid
> broadcast acknowledge numbers, leading to premature opening of the
> broadcast link. When the bypassed packets finally arrive, they are
> inadvertently accepted, and the already correctly initialized
> acknowledge number in the broadcast receive link is overwritten by
> the invalid (zero) value of the said packets. After this the broadcast
> link goes stale.
>
> We now fix this by marking the packets where we know the acknowledge
> value is or may be invalid, and then ignoring the acks from those.
>
> To this purpose, we claim an unused bit in the header to indicate that
> the value is invalid. We set the bit to 1 in the initial BCAST_PROTOCOL
> synchronization packet and all initial ("bulk") NAME_DISTRIBUTOR
> packets, plus those LINK_PROTOCOL packets sent out before the broadcast
> links are fully synchronized.
>
> This minor protocol update is fully backwards compatible.
>
> Reported-by: John Thompson <thompa.atl@gmail.com>
> Tested-by: John Thompson <thompa.atl@gmail.com>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied, thanks Jon.
^ permalink raw reply
* Re: [PATCH net v1 2/2] ibmvnic: Fix missing brackets in init_sub_crq_irqs
From: David Miller @ 2016-10-29 21:19 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev
In-Reply-To: <1477589332-513-2-git-send-email-tlfalcon@linux.vnet.ibm.com>
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date: Thu, 27 Oct 2016 12:28:52 -0500
> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
> ---
> v1: caught by kbuild bot with -Wmisleading-indentation after
> after submitting previous patch
Applied.
^ permalink raw reply
* Re: [PATCH net v2 1/2] ibmvnic: Fix releasing of sub-CRQ IRQs in interrupt context
From: David Miller @ 2016-10-29 21:19 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev
In-Reply-To: <1477589332-513-1-git-send-email-tlfalcon@linux.vnet.ibm.com>
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date: Thu, 27 Oct 2016 12:28:51 -0500
> Schedule these XPORT event tasks in the shared workqueue
> so that IRQs are not freed in an interrupt context when
> sub-CRQs are released.
>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
> ---
> v2: correct warnings by kbuild bot
Applied.
^ permalink raw reply
* Re: [patch net-next v2] rocker: set physical device for port netdevice
From: David Miller @ 2016-10-29 21:16 UTC (permalink / raw)
To: jiri; +Cc: netdev
In-Reply-To: <1477600342-2752-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 27 Oct 2016 22:32:22 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> Do this so the sysfs has "device" link correctly set.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> v1->v2:
> - make pdev non-const as pointerd out by kbuild test robot
Applied, thanks Jiri.
^ permalink raw reply
* Re: [net 0/4][pull request] Intel Wired LAN Driver Updates 2016-10-27
From: David Miller @ 2016-10-29 21:14 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene, guru.anbalagane
In-Reply-To: <1477603677-39957-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 27 Oct 2016 14:27:53 -0700
> This series contains fixes to ixgbe and i40e.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net-next] tcp_bbr: add a state transition diagram and accompanying comment
From: David Miller @ 2016-10-29 21:13 UTC (permalink / raw)
To: ncardwell; +Cc: netdev, ycheng, edumazet, soheil
In-Reply-To: <1477589197-18123-1-git-send-email-ncardwell@google.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Thu, 27 Oct 2016 13:26:37 -0400
> Document the possible state transitions for a BBR flow, and also add a
> prose summary of the state machine, covering the life of a typical BBR
> flow.
>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v1 04/16] tipc: rename struct tipc_skb_cb member handle to bytes_read
From: David Miller @ 2016-10-29 21:01 UTC (permalink / raw)
To: parthasarathy.bhuvaragan; +Cc: jon.maloy, netdev, tipc-discussion
In-Reply-To: <1477578157-13256-5-git-send-email-parthasarathy.bhuvaragan@ericsson.com>
From: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Date: Thu, 27 Oct 2016 16:22:25 +0200
> @@ -95,7 +95,7 @@ struct plist;
> #define TIPC_MEDIA_INFO_OFFSET 5
>
> struct tipc_skb_cb {
> - void *handle;
> + u32 bytes_read;
> struct sk_buff *tail;
> bool validated;
> bool wakeup_pending;
If this is now a u32, then:
> - u32 offset = (u32)(unsigned long)(TIPC_SKB_CB(buf)->handle);
> + u32 offset = (u32)(TIPC_SKB_CB(buf)->bytes_read);
This cast is unnecessary as are the parenthesis.
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
^ permalink raw reply
* Re: [PATCH v7 0/6] Add eBPF hooks for cgroups
From: Daniel Borkmann @ 2016-10-29 20:29 UTC (permalink / raw)
To: Lorenzo Colitti, Alexei Starovoitov
Cc: Daniel Mack, Pablo Neira Ayuso, htejun, ast, David Miller, kafai,
Florian Westphal, harald, netdev@vger.kernel.org, Sargun Dhillon,
cgroups
In-Reply-To: <CAKD1Yr3QfL-biSjQfFgzjMFNoLV7FP9DSB=KNbp+_KyxyQmVMg@mail.gmail.com>
On 10/29/2016 05:34 PM, Lorenzo Colitti wrote:
> On Sat, Oct 29, 2016 at 3:24 PM, Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>> it could be solved by swapping the order of cgroup_bpf_run_filter()
>> and NF_INET_POST_ROUTING in patch 5. It was proposed some time back, but
>> the current patch, I think, is more symmetrical.
>> cgroup+bpf runs after nf hook on rx and runs before it on tx.
>> imo it's more consistent.
>
> I guess what I was trying to say was: what does doing this filtering
> in ip_output give you over running this from the netfilter hooks?
> Doing this filtering in netfilter is much more general because there
> can be complex rules both before and after the filtering is applied. I
> hadn't thought of the scalability issue you note below though.
>
> For accounting you probably want to run after the hooks, both for
> ingress and for egress, because the hooks can do all sorts of stuff
> like drop packets, change packet sizes, reroute them to different
> interfaces, etc. Do you see use cases where you want to run before the
> hooks?
Fwiw, not sure if swapping brings much, even after netfilter there could
be complex processing that would potentially drop, mangle, redirect, etc
from tc layer (egress or from qdisc itself). But also at even lower layers
(although rather unlikely, but not impossible), for example in drivers or
shortly before passing skb to them during segmentation (GSO), etc.
Eventually, for that you'd need to monitor various things, and the cgroup
one is just at higher layers with different semantics.
>> Regardless of this choice... are you going to backport cgroupv2 to
>> android? Because this set is v2 only.
>
> Certainly anything that can't easily be backported to, say,
> android-4.4 is not really feasible in the short term. I don't think we
> use network cgroups at all, so if v2 network cgroups can coexist with
> v1 cgroups of other types (which what little I've read seems to
> indicate) then that should be possible.
>
>> yes. that's certainly doable, but sooner or later such approach will hit
>> scalability issue when number of cgroups is large. Same issue we saw
>> with cls_bpf and bpf_skb_under_cgroup(). Hence this patch set was needed
>> that is centered around cgroups instead of hooks. Note, unlike, tc and nf
>> there is no way to attach to a hook. The bpf program is attached to a cgroup.
>> It's an important distinction vs everything that currently exists in the stack.
>
> Ah, I see. Out of curiosity, what was the first scaling limitation you
> hit? eBPF program length? eBPF map size?
The scalability issue is not really program length or map size from eBPF
side in this context. While for v1, you have the bpf_get_cgroup_classid()
helper available on egress (not ingress though) that can scale with larger
number of cgroups since it works on the user-defined net_cls tagging, but
for v2, bpf_skb_under_cgroup() was initially introduced, which can only test
whether the sk's v2 cgroup related to the skb is in the sub-hierarchy of
a specific cgroup that is provided via maps. Effectively, when you have a
larger number of v2 cgroups that boolean test will not scale and you need
to linearly test through various cgroups. It's good enough when need to
special case only few cgroups in the v2 hierarchy on egress. Idea was that
attaching to cgroup itself would resolve this from a different angle for
egress and also ingress in a complementary way, but also seems to open up
for various other use-cases at the same time as seen from various patches
on the list.
Cheers,
Daniel
^ permalink raw reply
* Re: [PATCH 00/17] pull request for net-next: batman-adv 2016-10-27
From: David Miller @ 2016-10-29 20:28 UTC (permalink / raw)
To: sw-2YrNx6rUIHYiY0qSoAWiAoQuADTiUCJX
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <20161027190150.7880-1-sw-2YrNx6rUIHYiY0qSoAWiAoQuADTiUCJX@public.gmane.org>
From: Simon Wunderlich <sw-2YrNx6rUIHYiY0qSoAWiAoQuADTiUCJX@public.gmane.org>
Date: Thu, 27 Oct 2016 21:01:33 +0200
> this is our first feature pull request for batman-adv (mostly
> containing code cleanup stuff), there are at least two more to come.
>
> Please pull or let me know of any problem!
Pulled, thanks Simon.
^ permalink raw reply
* Re: [PATCH net 00/10] mlx4 misc fixes for 4.9
From: David Miller @ 2016-10-29 20:24 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe
In-Reply-To: <1477574842-29688-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Thu, 27 Oct 2016 16:27:12 +0300
> This patchset contains several bug fixes from the team to the
> mlx4 Eth and Core drivers.
>
> Series generated against net commit:
> ecc515d7238f 'sctp: fix the panic caused by route update'
Series applied, thanks Tariq.
^ permalink raw reply
* Re: [net-next 00/17][pull request] 40GbE Intel Wired LAN Driver Updates 2016-10-28
From: David Miller @ 2016-10-29 20:21 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene, guru.anbalagane
In-Reply-To: <1477726258-111563-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 29 Oct 2016 00:30:41 -0700
> This series contains updates to i40e and i40evf only.
Pulled, thanks Jeff.
^ permalink raw reply
* [PATCH net-next] firewire: net: really fix maximum possible MTU
From: Stefan Richter @ 2016-10-29 20:16 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux1394-devel, Jarod Wilson, linux-kernel
In-Reply-To: <20161023163056.6bc38610@kant>
The maximum unicast datagram size /without/ link fragmentation is
4096 - 4 = 4092 (max IEEE 1394 async payload size at >= S800 bus speed,
minus unfragmented encapssulation header). Max broadcast datagram size
without fragmentation is 8 bytes less than that (due to GASP header).
The maximum datagram size /with/ link fragmentation is 0xfff = 4095
for unicast and broadcast. This is because the RFC 2734 fragment
encapsulation header field for datagram size is only 12 bits wide.
Fixes: 5d48f00d836a('firewire: net: fix maximum possible MTU')
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/firewire/net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index 03715e7d9d92..363fc5ec1a4e 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -1465,7 +1465,7 @@ static int fwnet_probe(struct fw_unit *unit,
net->mtu = 1500U;
net->min_mtu = ETH_MIN_MTU;
- net->max_mtu = ETH_MAX_MTU;
+ net->max_mtu = 0xfff;
/* Set our hardware address while we're at it */
ha = (union fwnet_hwaddr *)net->dev_addr;
--
Stefan Richter
-======----- =-=- ===-=
http://arcgraph.de/sr/
^ permalink raw reply related
* Re: [PATCH RDS v1] rds: debug messages are enabled by default
From: David Miller @ 2016-10-29 19:56 UTC (permalink / raw)
To: shamir.rabinovitch; +Cc: netdev, santosh.shilimkar
In-Reply-To: <1477561598-20186-1-git-send-email-shamir.rabinovitch@oracle.com>
From: shamir.rabinovitch@oracle.com
Date: Thu, 27 Oct 2016 05:46:38 -0400
> From: shamir rabinovitch <shamir.rabinovitch@oracle.com>
>
> rds use Kconfig option called "RDS_DEBUG" to enable rds debug messages.
> This option cause the rds Makefile to add -DDEBUG to the rds gcc command
> line.
>
> When CONFIG_DYNAMIC_DEBUG is enabled, the "DEBUG" macro is used by
> include/linux/dynamic_debug.h to decide if dynamic debug prints should
> be sent by default to the kernel log.
>
> rds should not enable this macro for production builds. rds dynamic
> debug work as expected follow this fix.
>
> Signed-off-by: Shamir Rabinovitch <shamir.rabinovitch@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bpf: Print function name in addition to function id
From: David Miller @ 2016-10-29 19:56 UTC (permalink / raw)
To: tgraf; +Cc: netdev, daniel, ast
In-Reply-To: <67466f1b43b8a586bcf63fa1e5e292ed340d515c.1477560166.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Thu, 27 Oct 2016 11:23:51 +0200
> The verifier currently prints raw function ids when printing CALL
> instructions or when complaining:
>
> 5: (85) call 23
> unknown func 23
>
> print a meaningful function name instead:
>
> 5: (85) call bpf_redirect#23
> unknown func bpf_redirect#23
>
> Moves the function documentation to a single comment and renames all
> helpers names in the list to conform to the bpf_ prefix notation so
> they can be greped in the kernel source.
>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Applied.
^ 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