* Re: [PATCH net] Revert "net: Add driver helper functions to determine checksum offloadability"
From: David Miller @ 2016-10-14 14:03 UTC (permalink / raw)
To: stephen; +Cc: tom, netdev
In-Reply-To: <20161011130409.7e6b54ff@xeon-e3>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 11 Oct 2016 13:04:09 -0700
>
> This reverts commit 6ae23ad36253a8033c5714c52b691b84456487c5.
>
> The code has been in kernel since 4.4 but there are no in tree
> code that uses. Unused code is broken code, remove it.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied to net-next, thanks Stephen.
Please put proper "[PATCH net-next]" tags in your Subject lines when
patches are targetting net-next.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: limit a number of namespaces which can be cleaned up concurrently
From: David Miller @ 2016-10-14 14:09 UTC (permalink / raw)
To: ebiederm-aS9lmoZGLiVWk0Htik3J/w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
avagin-5HdwGun5lf+gSpxsJD1C4w, avagin-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <87k2db39zf.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
Date: Thu, 13 Oct 2016 22:06:28 -0500
> Oh that is a surprise. We can definitely skip genenerating uevents for
> network namespaces that are exiting because by definition no one can see
> those network namespaces. If a socket existed that could see those
> uevents it would hold a reference to the network namespace and as such
> the network namespace could not exit.
>
> That sounds like it is worth investigating a little more deeply.
>
> I am surprised that allocation and freeing is so heavy we are spending
> lots of time doing that. On the other hand kobj_bcast_filter is very
> dumb and very late so I expect something can be moved earlier and make
> that code cheaper with the tiniest bit of work.
I definitely would rather see the uevents removed to kill ~%99 of the
namespace removal overhead rather than limiting.
^ permalink raw reply
* Re: [PATCH 1/2] net: wan: slic_ds26522: add SPI device ID table to fix module autoload
From: David Miller @ 2016-10-14 14:12 UTC (permalink / raw)
To: javier; +Cc: linux-kernel, netdev, qiang.zhao
In-Reply-To: <1476298541-7354-1-git-send-email-javier@osg.samsung.com>
From: Javier Martinez Canillas <javier@osg.samsung.com>
Date: Wed, 12 Oct 2016 15:55:40 -0300
> If the driver is built as a module, module alias information isn't filled
> so the module won't be autoloaded. Add a SPI device ID table and use the
> MODULE_DEVICE_TABLE() macro so the information is exported in the module.
>
> Before this patch:
>
> $ modinfo drivers/net/wan/slic_ds26522.ko | grep alias
> $
>
> After this patch:
>
> $ modinfo drivers/net/wan/slic_ds26522.ko | grep alias
> alias: spi:ds26522
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] net: wan: slic_ds26522: Export OF module alias information
From: David Miller @ 2016-10-14 14:12 UTC (permalink / raw)
To: javier; +Cc: linux-kernel, netdev, qiang.zhao
In-Reply-To: <1476298541-7354-2-git-send-email-javier@osg.samsung.com>
From: Javier Martinez Canillas <javier@osg.samsung.com>
Date: Wed, 12 Oct 2016 15:55:41 -0300
> When the device is registered via OF, the OF table is used to match the
> driver instead of the SPI device ID table, but the entries in the later
> are used as aliasses to load the module if the driver was not built-in.
>
> This is because the SPI core always reports an SPI module alias instead
> of an OF one, but that could change so it's better to always export it.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: wan: slic_ds26522: Allow driver to built if COMPILE_TEST is enabled
From: David Miller @ 2016-10-14 14:12 UTC (permalink / raw)
To: javier; +Cc: linux-kernel, netdev, qiang.zhao
In-Reply-To: <1476299159-21094-1-git-send-email-javier@osg.samsung.com>
From: Javier Martinez Canillas <javier@osg.samsung.com>
Date: Wed, 12 Oct 2016 16:05:59 -0300
> The driver only has runtime but no build time dependency with FSL_SOC ||
> ARCH_MXC || ARCH_LAYERSCAPE. So it can be built for testing purposes if
> the COMPILE_TEST option is enabled.
>
> This is useful to have more build coverage and make sure that the driver
> is not affected by changes that could cause build regressions.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] ipv6: correctly add local routes when lo goes up
From: David Miller @ 2016-10-14 14:06 UTC (permalink / raw)
To: nicolas.dichtel
Cc: netdev, Balakumaran.Kannan, Maruthi.Thotad, sd, hannes,
chenweilong, gaofeng
In-Reply-To: <1476259840-26261-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Wed, 12 Oct 2016 10:10:40 +0200
> The goal of the patch is to fix this scenario:
> ip link add dummy1 type dummy
> ip link set dummy1 up
> ip link set lo down ; ip link set lo up
>
> After that sequence, the local route to the link layer address of dummy1 is
> not there anymore.
>
> When the loopback is set down, all local routes are deleted by
> addrconf_ifdown()/rt6_ifdown(). At this time, the rt6_info entry still
> exists, because the corresponding idev has a reference on it. After the rcu
> grace period, dst_rcu_free() is called, and thus ___dst_free(), which will
> set obsolete to DST_OBSOLETE_DEAD.
>
> In this case, init_loopback() is called before dst_rcu_free(), thus
> obsolete is still sets to something <= 0. So, the function doesn't add the
> route again. To avoid that race, let's check the rt6 refcnt instead.
>
> Fixes: 25fb6ca4ed9c ("net IPv6 : Fix broken IPv6 routing table after loopback down-up")
> Fixes: a881ae1f625c ("ipv6: don't call addrconf_dst_alloc again when enable lo")
> Fixes: 33d99113b110 ("ipv6: reallocate addrconf router for ipv6 address when lo device up")
> Reported-by: Francesco Santoro <francesco.santoro@6wind.com>
> Reported-by: Samuel Gauthier <samuel.gauthier@6wind.com>
...
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next 00/11] net: Fix netdev adjacency tracking
From: David Miller @ 2016-10-14 14:17 UTC (permalink / raw)
To: dsa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR
Cc: jiri-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
j.vosburgh-Re5JQEeQqe8AvxtiuMwx3w, vfalico-Re5JQEeQqe8AvxtiuMwx3w,
andy-QlMahl40kYEqcZcGjlUOXw,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
intel-wired-lan-qjLDD68F18P21nG7glBr7A
In-Reply-To: <1476305519-28833-1-git-send-email-dsa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
From: David Ahern <dsa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
Date: Wed, 12 Oct 2016 13:51:48 -0700
> The netdev adjacency tracking is failing to create proper dependencies
> for some topologies. For example this topology
>
> +--------+
> | myvrf |
> +--------+
> | |
> | +---------+
> | | macvlan |
> | +---------+
> | |
> +----------+
> | bridge |
> +----------+
> |
> +--------+
> | bond0 |
> +--------+
> |
> +--------+
> | eth3 |
> +--------+
>
> hits 1 of 2 problems depending on the order of enslavement. The base set of
> commands for both cases:
>
> ip link add bond1 type bond
> ip link set bond1 up
Your diagram uses the device name "bond0" but all of your command examples
use "bond1". Please fix this up, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack
From: Ard Biesheuvel @ 2016-10-14 14:22 UTC (permalink / raw)
To: Johannes Berg
Cc: Andy Lutomirski, Sergey Senozhatsky,
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Herbert Xu, David S. Miller,
<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jouni Malinen
In-Reply-To: <1476452792.31114.46.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> On 14 Oct 2016, at 14:46, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
>
>
>>
>> Is the aad[] actually reused? I would assume it only affects the mac
>> on encryption, and the verification on decryption but I don't think
>> we actually need it back from the crypto routines.
>
> I don't think it's reused.
>
>> Exactly what you said above :-) My patch only touches CCM but as you
>> said,
>>
>> """
>> 'Also there's B_0/J_0 for CCM/GCM, and the 'zero' thing that GMAC
>> has.
>> """
>
> Ah, but we can/should do the same for the others, no?
>
Yes, but then we end up kmalloc/kfreeing chunks of 16 bytes, which is actually another problem.
I still think we are not violating the api by putting aead_req on the stack (but herbert should confirm). The aad[] issue does violate the api, so it deserves a separate fix imo
^ permalink raw reply
* Re: [PATCH v4 net-next 0/4] act_mirred: Ingress actions support
From: David Miller @ 2016-10-14 14:23 UTC (permalink / raw)
To: shmulik.ladkani; +Cc: jhs, edumazet, xiyou.wangcong, daniel, netdev
In-Reply-To: <1476338804-25440-1-git-send-email-shmulik.ladkani@gmail.com>
From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Date: Thu, 13 Oct 2016 09:06:40 +0300
> This patch series implements action mirred 'ingress' actions
> TCA_INGRESS_REDIR and TCA_INGRESS_MIRROR.
>
> This allows attaching filters whose target is to hand matching skbs into
> the rx processing of a specified device.
>
> v4:
> in 4/4, check ret code of netif_receive_skb, as suggested by Cong Wang
> v3:
> in 4/4, addressed non coherency due to reading m->tcfm_eaction multiple
> times, as spotted by Eric Dumazet
> v2:
> in 1/4, declare tcfm_mac_header_xmit as bool instead of int
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] Documentation/networking: update git urls to use https over http
From: David Miller @ 2016-10-14 14:27 UTC (permalink / raw)
To: alexander; +Cc: netdev, corbet, linux-doc, linux-kernel
In-Reply-To: <20161013150951.4615-1-alexander@alemayhu.com>
From: Alexander Alemayhu <alexander@alemayhu.com>
Date: Thu, 13 Oct 2016 17:09:51 +0200
> This fixes the following errors when trying to clone the urls:
>
> Cloning into 'net'...
> fatal: repository 'http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/' not found
> Cloning into 'net-next'...
> fatal: repository 'http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/' not found
> Cloning into 'linux'...
> fatal: repository 'http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/' not found
> Cloning into 'stable-queue'...
> fatal: repository 'http://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/' not found
>
> Signed-off-by: Alexander Alemayhu <alexander@alemayhu.com>
Since this is simply a documentation fix I applied this to 'net', thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/4] rxrpc: Fixes
From: David Miller @ 2016-10-14 14:45 UTC (permalink / raw)
To: dhowells; +Cc: netdev, linux-afs, dan.carpenter, linux-kernel
In-Reply-To: <147637512988.17348.9857198849984467857.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Thu, 13 Oct 2016 17:12:09 +0100
>
> This set of patches contains a bunch of fixes:
>
> (1) Fix use of kunmap() after change from kunmap_atomic() within AFS.
>
> (2) Don't use of ERR_PTR() with an always zero value.
>
> (3) Check the right error when using ip6_route_output().
>
> (4) Be consistent about whether call->operation_ID is BE or CPU-E within
> AFS.
>
> The patches can be found here also:
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rewrite
>
> Tagged thusly:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> rxrpc-rewrite-20161013
Pulled, thanks David.
^ permalink raw reply
* Re: [PATCH v3] IB/ipoib: move back IB LL address into the hard header
From: Paolo Abeni @ 2016-10-14 14:48 UTC (permalink / raw)
To: Or Gerlitz
Cc: David Miller, Doug Ledford, Erez Shitrit, Alex Vesker,
linux-rdma@vger.kernel.org, Sean Hefty, Hal Rosenstock,
Jason Gunthorpe, Linux Netdev List, talal@mellanox.com
In-Reply-To: <CAJ3xEMi7DY7_3vM+553dC4w17W==CdUdtn5PdzzCCUxtj434dQ@mail.gmail.com>
On Fri, 2016-10-14 at 13:23 +0300, Or Gerlitz wrote:
>
> Paolo,
>
> Is this fix backportable to any kernel since the breakage?
yes, AFAIK this is beck-portable.
> AFAIR,
> Roland mentioned
> that a 2nd change introduced in 4.7-rc1 changed things a bit more such
> that the fix
> he had in his head didn't apply any more.
If you refer to shrinking both IPoIB and gso control buffer, as proposed
by Roland in:
http://marc.info/?l=linux-kernel&m=146787279825501&w=2
that will not work, since the gso control buffer is grown a bit since
the first time the bug was detected.
This patch does not have that sort of issue.
> I am still travelling after netdev and would like to put an eye on the
> patch and also see that @mellanox.com someone
Not sure if that helps, but a 3rd party has already confirmed privately
that this patch fixes the bug for them.
Paolo
^ permalink raw reply
* Re: [PATCH v3] IB/ipoib: move back IB LL address into the hard header
From: David Miller @ 2016-10-14 14:55 UTC (permalink / raw)
To: pabeni; +Cc: linux-rdma, dledford, sean.hefty, hal.rosenstock, jgunthorpe,
netdev
In-Reply-To: <9fce9b87ecc4c5c4f03401359806f40b1dcd0eb3.1476374992.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Thu, 13 Oct 2016 18:26:56 +0200
> After the commit 9207f9d45b0a ("net: preserve IP control block
> during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
> That destroy the IPoIB address information cached there,
> causing a severe performance regression, as better described here:
>
> http://marc.info/?l=linux-kernel&m=146787279825501&w=2
>
> This change moves the data cached by the IPoIB driver from the
> skb control lock into the IPoIB hard header, as done before
> the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
> and use skb->cb to stash LL addresses").
> In order to avoid GRO issue, on packet reception, the IPoIB driver
> stash into the skb a dummy pseudo header, so that the received
> packets have actually a hard header matching the declared length.
> To avoid changing the connected mode maximum mtu, the allocated
> head buffer size is increased by the pseudo header length.
>
> After this commit, IPoIB performances are back to pre-regression
> value.
>
> v2 -> v3: rebased
> v1 -> v2: avoid changing the max mtu, increasing the head buf size
>
> Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] IPv6: Drop the temporary address regen_timer
From: David Miller @ 2016-10-14 14:59 UTC (permalink / raw)
To: jbohac; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <20161013165002.zn7wgjbacs34i73i@dwarf.suse.cz>
From: Jiri Bohac <jbohac@suse.cz>
Date: Thu, 13 Oct 2016 18:50:02 +0200
> The randomized interface identifier (rndid) was periodically updated from
> the regen_timer timer. Simplify the code by updating the rndid only when
> needed by ipv6_try_regen_rndid().
>
> This makes the follow-up DESYNC_FACTOR fix much simpler. Also it fixes a
> reference counting error in this error path, where an in6_dev_put was
> missing:
> err = addrconf_sysctl_register(ndev);
> if (err) {
> ipv6_mc_destroy_dev(ndev);
> - del_timer(&ndev->regen_timer);
> snmp6_unregister_dev(ndev);
> goto err_release;
>
> Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] IPv6: fix DESYNC_FACTOR
From: David Miller @ 2016-10-14 14:59 UTC (permalink / raw)
To: jbohac; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <20161013165215.52jxdlkh7v5octl7@dwarf.suse.cz>
From: Jiri Bohac <jbohac@suse.cz>
Date: Thu, 13 Oct 2016 18:52:15 +0200
> The IPv6 temporary address generation uses a variable called DESYNC_FACTOR
> to prevent hosts updating the addresses at the same time. Quoting RFC 4941:
>
> ... The value DESYNC_FACTOR is a random value (different for each
> client) that ensures that clients don't synchronize with each other and
> generate new addresses at exactly the same time ...
>
> DESYNC_FACTOR is defined as:
>
> DESYNC_FACTOR -- A random value within the range 0 - MAX_DESYNC_FACTOR.
> It is computed once at system start (rather than each time it is used)
> and must never be greater than (TEMP_VALID_LIFETIME - REGEN_ADVANCE).
>
> First, I believe the RFC has a typo in it and meant to say: "and must
> never be greater than (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE)"
>
> The reason is that at various places in the RFC, DESYNC_FACTOR is used in
> a calculation like (TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR) or
> (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR). It needs to be
> smaller than (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE) for the result of
> these calculations to be larger than zero. It's never used in a
> calculation together with TEMP_VALID_LIFETIME.
>
> I already submitted an errata to the rfc-editor:
> https://www.rfc-editor.org/errata_search.php?rfc=4941
>
> The Linux implementation of DESYNC_FACTOR is very wrong:
> max_desync_factor is used in places DESYNC_FACTOR should be used.
> max_desync_factor is initialized to the RFC-recommended value for
> MAX_DESYNC_FACTOR (600) but the whole point is to get a _random_ value.
>
> And nothing ensures that the value used is not greater than
> (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE), which leads to underflows. The
> effect can easily be observed when setting the temp_prefered_lft sysctl
> e.g. to 60. The preferred lifetime of the temporary addresses will be
> bogus.
>
> TEMP_PREFERRED_LIFETIME and REGEN_ADVANCE are not constants and can be
> influenced by these three sysctls: regen_max_retry, dad_transmits and
> temp_prefered_lft. Thus, the upper bound for desync_factor needs to be
> re-calculated each time a new address is generated and if desync_factor is
> larger than the new upper bound, a new random value needs to be
> re-generated.
>
> And since we already have max_desync_factor configurable per interface, we
> also need to calculate and store desync_factor per interface.
>
> Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/5] udp: Flow dissection for tunnels
From: David Miller @ 2016-10-14 15:03 UTC (permalink / raw)
To: tom; +Cc: netdev, kernel-team
In-Reply-To: <CALx6S35hEQzc=pCb6ko23HNFdK96-nb=F8Ni2+c=inSpJC16og@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 13 Oct 2016 12:29:46 -0700
> On Thu, Oct 13, 2016 at 12:17 PM, David Miller <davem@davemloft.net> wrote:
>> This socket lookup is very heavy handed, and I realize that you
>> need this because we no longer store the encapsulation socket in
>> skb->sk these days.
>>
> I don't quite understand your point about the encapsulation socket.
On the transmit side we used to have an issue wrt. what socket lives
on skb->sk when encapsulation is involved.
The problem is that we need skb->sk to be the transport level socket,
but in the output path we used to make tests on "skb->sk" to determine
things such as the multicast loopback flag. But we should be looking
at the tunnel socket for that, otherwise we could do crazy things
like dereference an AF_PACKET socket as if it were an inet socket one.
As such we modified the output path to pass the inner tunnel socket
'sk' down through the call chain, as an argument to functions such as
ip_queue_xmit(), ip_local_out*(), etc.
^ permalink raw reply
* Re: [PATCH net-next v11 1/1] net: phy: Cleanup the Edge-Rate feature in Microsemi PHYs.
From: David Miller @ 2016-10-14 15:05 UTC (permalink / raw)
To: allan.nielsen; +Cc: netdev, andrew, f.fainelli, raju.lakkaraju
In-Reply-To: <1476382890-7275-2-git-send-email-allan.nielsen@microsemi.com>
From: "Allan W. Nielsen" <allan.nielsen@microsemi.com>
Date: Thu, 13 Oct 2016 20:21:30 +0200
> Edge-Rate cleanup include the following:
> - Updated device tree bindings documentation for edge-rate
> - The edge-rate is now specified as a "slowdown", meaning that it is now
> being specified as positive values instead of negative (both
> documentation and implementation wise).
> - Only explicitly documented values for "vsc8531,vddmac" and
> "vsc8531,edge-slowdown" are accepted by the device driver.
> - Deleted include/dt-bindings/net/mscc-phy-vsc8531.h as it was not needed.
> - Read/validate devicetree settings in probe instead of init
>
> Signed-off-by: Allan W. Nielsen <allan.nielsen@microsemi.com>
> Signed-off-by: Raju Lakkaraju <raju.lakkaraju@microsemi.com>
This patch does not apply to the net-next tree.
Take my tree, put this email of your's into a file, and run this:
bash$ git am file
and you will get:
[davem@dhcp-10-15-49-210 net-next]$ git am --signoff net-next-v11-1-1-net-phy-Cleanup-the-Edge-Rate-feature-in-Microsemi-PHYs..patch
Applying: net: phy: Cleanup the Edge-Rate feature in Microsemi PHYs.
error: patch failed: Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt:6
error: Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt: patch does not apply
error: patch failed: drivers/net/phy/mscc.c:12
error: drivers/net/phy/mscc.c: patch does not apply
error: include/dt-bindings/net/mscc-phy-vsc8531.h: does not exist in index
Patch failed at 0001 net: phy: Cleanup the Edge-Rate feature in Microsemi PHYs.
The copy of the patch that failed is found in:
/home/davem/src/GIT/net-next/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Please do not resubmit this patch until you can successfully email the
patch to yourself and apply it cleanly to the net-next tree.
^ permalink raw reply
* Re: [PATCH net 0/3] qed: Fix dependencies and warnings series
From: David Miller @ 2016-10-14 15:07 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: netdev, arnd, dan.carpenter
In-Reply-To: <1476388623-31032-1-git-send-email-Yuval.Mintz@caviumnetworks.com>
From: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
Date: Thu, 13 Oct 2016 22:57:00 +0300
> The first patch in this series follows Dan Carpenter's reports about
> Smatch warnings for recent qed additions and fixes those.
>
> The second patch is the most significant one [and the reason this is
> ntended for 'net'] - it's based on Arnd Bermann's suggestion for fixing
> compilation issues that were introduced with the roce addition as a result
> of certain combinations of qed, qede and qedr Kconfig options.
>
> The third follows the discussion with Arnd and clears a lot of the warnings
> that arise when compiling the drivers with "C=1".
>
> Please consider applying this series to 'net'.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: fixup xdp tx irq to match rx
From: David Miller @ 2016-10-14 15:14 UTC (permalink / raw)
To: bblanco
Cc: netdev, alexei.starovoitov, ttoukan.linux, gerlitz.or, saeedm,
brouer
In-Reply-To: <20161013201311.20844-1-bblanco@plumgrid.com>
From: Brenden Blanco <bblanco@plumgrid.com>
Date: Thu, 13 Oct 2016 13:13:11 -0700
> In cases where the number of tx rings is not a multiple of the number of
> rx rings, the tx completion event will be handled on a different core
> from the transmit and population of the ring. Races on the ring will
> lead to a double-free of the page, and possibly other corruption.
>
> The rings are initialized by default with a valid multiple of rings,
> based on the number of cpus, therefore an invalid configuration requires
> ethtool to change the ring layout. For instance 'ethtool -L eth0 rx 9 tx
> 8' will cause packets received on rx0, and XDP_TX'd to tx48, to be
> completed on cpu3 (48 % 9 == 3).
>
> Resolve this discrepancy by shifting the irq for the xdp tx queues to
> start again from 0, modulo rx_ring_num.
>
> Fixes: 9ecc2d86171a ("net/mlx4_en: add xdp forwarding and data write support")
> Reported-by: Jesper Dangaard Brouer <brouer@redhat.com>
> Signed-off-by: Brenden Blanco <bblanco@plumgrid.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/2] lwtunnel: Add destroy state operation
From: David Miller @ 2016-10-14 15:15 UTC (permalink / raw)
To: tom; +Cc: netdev, roopa, kernel-team
In-Reply-To: <20161014005743.288956-2-tom@herbertland.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 13 Oct 2016 17:57:42 -0700
> @@ -130,6 +130,19 @@ int lwtunnel_build_state(struct net_device *dev, u16 encap_type,
> }
> EXPORT_SYMBOL(lwtunnel_build_state);
>
> +void lwtstate_free(struct lwtunnel_state *lws)
There should only be one space between "void" and "lwstate_free".
^ permalink raw reply
* Re: [PATCH trivial] net: add bbr to config DEFAULT_TCP_CONG
From: David Miller @ 2016-10-14 15:17 UTC (permalink / raw)
To: markus; +Cc: eric.dumazet, ncardwell, netdev
In-Reply-To: <20161014080716.GA306@x4>
From: Markus Trippelsdorf <markus@trippelsdorf.de>
Date: Fri, 14 Oct 2016 10:07:16 +0200
> On 2016.10.14 at 09:43 +0200, Eric Dumazet wrote:
>> On Fri, 2016-10-14 at 09:33 +0200, Markus Trippelsdorf wrote:
>> > While playing with BBR I noticed that it was missing in the list of
>> > possible config DEFAULT_TCP_CONG choices. Fixed thusly.
>> >
>> > Signed-off-by: Markus Trippelsdorf <markus@trippelsdorf.de>
>> >
>> > diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
>> > index 300b06888fdf..b54b3ca939db 100644
>> > --- a/net/ipv4/Kconfig
>> > +++ b/net/ipv4/Kconfig
>> > @@ -715,6 +715,7 @@ config DEFAULT_TCP_CONG
>> > default "reno" if DEFAULT_RENO
>> > default "dctcp" if DEFAULT_DCTCP
>> > default "cdg" if DEFAULT_CDG
>> > + default "bbr" if DEFAULT_BBR
>> > default "cubic"
>>
>> Not sure if we want this at this moment.
>>
>> BBR needs FQ packet scheduler, and this is not exactly trivial to
>> achieve.
>
> For a start, it could be automatically selected:
Right but FQ has to be properly enabled and configured as well.
^ permalink raw reply
* Re: [PATCH v2] net: Require exact match for TCP socket lookups if dif is l3mdev
From: David Ahern @ 2016-10-14 15:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <25e3a7a9-a74e-5392-742a-38bd224343f6@cumulusnetworks.com>
On 10/14/16 6:21 AM, David Ahern wrote:
>> So you might need to let the caller pass IP6CB(skb)->flags (or
>> TCP_SKB_CB(skb)->header.h6.flags ) instead of skb since
>> inet6_exact_dif_match() does not know where to fetch the flags.
>>
>> Same issue for IPv4.
>
> I'll update the match functions to pull from TCP_SKB_CB instead of IP6CB and make a note of the above.
IPv6 does the move after the socket lookup where IPv4 does it before.
^ permalink raw reply
* Re: [PATCH v3 net-next 0/7] qed*: driver updates
From: David Miller @ 2016-10-14 16:00 UTC (permalink / raw)
To: manish.chopra; +Cc: netdev, Yuval.Mintz, manish.chopra
In-Reply-To: <1476436763-5274-1-git-send-email-manish.chopra@qlogic.com>
From: Manish Chopra <manish.chopra@qlogic.com>
Date: Fri, 14 Oct 2016 05:19:16 -0400
> There are several new additions in this series;
> Most are connected to either Tx offloading or Rx classifications
> [either fastpath changes or supporting configuration].
>
> In addition, there's a single IOV enhancement.
>
> Please consider applying this series to `net-next'.
>
> V2->V3:
> Fixes below kbuild warning
> call to '__compiletime_assert_60' declared with
> attribute error: Need native word sized stores/loads for atomicity.
>
> V1->V2:
> Added a fix for the race in ramrod handling
> pointed by Eric Dumazet [patch 7].
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] FUJITSU Extended Socket driver version 1.2
From: David Miller @ 2016-10-14 16:05 UTC (permalink / raw)
To: izumi.taku; +Cc: netdev
In-Reply-To: <1476444345-28673-1-git-send-email-izumi.taku@jp.fujitsu.com>
From: Taku Izumi <izumi.taku@jp.fujitsu.com>
Date: Fri, 14 Oct 2016 20:25:44 +0900
> This patchset updates FUJITSU Extended Socket network driver into version 1.2.
> This includes the following enhancements:
> - ethtool -d support
> - ethtool -S enhancement
> - ethtool -w/-W support
> - Add some debugging feature (tracepoints etc)
>
> v1 -> v2:
> - Use u64 instead of phys_addr_t as TP_STRUCT__entry
> - Use ethtool facility to achieve debug mode instead of using debugfs
Series applied, thanks.
^ permalink raw reply
* RE: bug in ixgbe_atr
From: Duyck, Alexander H @ 2016-10-14 16:09 UTC (permalink / raw)
To: Sowmini Varadhan; +Cc: netdev@vger.kernel.org
In-Reply-To: <20161014034831.GC14253@oracle.com>
> -----Original Message-----
> From: Sowmini Varadhan [mailto:sowmini.varadhan@oracle.com]
> Sent: Thursday, October 13, 2016 8:49 PM
> To: Duyck, Alexander H <alexander.h.duyck@intel.com>
> Cc: netdev@vger.kernel.org
> Subject: Re: bug in ixgbe_atr
>
> On (10/14/16 02:06), Duyck, Alexander H wrote:
> > > + case ETH_P_IP:
> > > + skb_header_pointer(skb, ETH_HLEN, sizeof (struct iphdr),
> > > + &ip_hdr);
> > > /* access ihl as u8 to avoid unaligned access on ia64 */
> > > - hlen = (hdr.network[0] & 0x0F) << 2;
> > > - l4_proto = hdr.ipv4->protocol;
> > > + hlen = ip_hdr.ipv4.ihl << 2;
> > > + l4_proto = ip_hdr.ipv4.protocol;
> > > break;
> :
> > The problem is this will break other stuff, for example I have seen
> > the ihl access actually cause problems with unaligned accesses as some
> > architectures decide to pull it as a u32 and then mask it.
>
> Yes, I noticed that u8 comment for ia64.. if that's the only issue here, we could
> just reset hdr.network to &ip_hdr..
>
> However, I suspect the above patch is probably not going to work for the vlan
> case (it was just a first-pass hack)
I kind of figured that. Ideally we only wat to pick out the pieces we need. I would prefer to avoid skb_header_pointer if possible since we only need a few parts of the header and don't really need to copy the whole thing.
> > My advice would be to keep this simple. Add a check to make sure we
> > have room for at least skb_headlen(skb) - 40 >= hrd.raw - skb->data.
>
> I don't parse that- the hdr union in ixgbe_atr doesnt have a ->raw field. Can you
> explain?
Sorry I was thinking of a different piece of code. In the case of the atr code it would be hdr.network, not hdr.raw. Basically the thought was to validate that there is enough data in skb_headlen() that we can verify that from where the network header should be we have at least 40 bytes of data as that would be the minimum needed for a TCP header and an IPv4 header, or just an IPv6 header. We would probably need a separate follow-up for the TCP header after we validate network header.
> > Messing with the protocol bits will break stuff since there is support
> > for tunneling also floating around in here now.
> >
> > I believe we are planning on dropping this code in favor of
> > ndo_rx_flow_steer in the future. If we do that then the whole problem
> > becomes moot.
>
> Dropping it is fine with me I guess - maybe just return, if the
> skb_headlen() doesnt have enough bytes for a network header, i.e., skb_headlen
> is at least ETH_HLEN + sizeof (struct iphdr) for ETH_P_IP, or ETH_HLEN + sizeof
> (struct ipv6hdr) for ETH_P_IPV6?
>
> --Sowmini
Right that is kind of what I was thinking. If we validate that we have at least 40 before inspecting the network header, and at least 20 before we validate the TCP header that would work for me.
- Alex
^ 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