* Re: [net-next PATCH iproute2 v2 1/1] tc: introduce IFE action
From: Jamal Hadi Salim @ 2016-04-21 21:27 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, phil
In-Reply-To: <20160313232651.354f6087@xeon-e3>
Sorry dropped the ball on this..
On 16-03-14 02:26 AM, Stephen Hemminger wrote:
> On Wed, 9 Mar 2016 07:04:36 -0500
> Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>
> This code has diverged way from the general rule that ip utilities display
> format should match the command format. For example the properties shown
> on "ip route show" match those of "ip route add".
>
Valid point (and thanks for catching this since i tend to be the biggest
whiner on this topic ;-> I will make the changes - doesnt seem to be
far off already.
Note: in ife case it may not always symetric because there are optional
fields which may be absent in a request to the kernel but present in
a response.
> Also over the last several years, the code in iproute2 has switched from casting
> RTA_DATA() everywhere to a cleaner interface rte_getattr_u32() more like what
> is used in mnl library.
>
Will convert where it makes sense..
> The code has also gotten deeply intended creating lots of lines that are too long.
>
Is this you or the script saying the above? How is the conclusion that
we have deep indentation come about?
I checked there are some code lines that are > 80 characters because
it doesnt make sense to break them down.
> WARNING: 'doesnt' may be misspelled - perhaps 'doesn't'?
> #21:
What, checking my spelling now? ;->
I am on the internets dude!
> then provide a default so the user doesnt have to specify it.
>
> WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line)
> #25:
> "Distributing Linux Traffic Control Classifier-Action Subsystem"
>
75 character? ;-> What happened to 80?
> WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> #143:
> new file mode 100644
>
> ERROR: "foo * bar" should be "foo *bar"
Will fix above and rest shortly.
Also, promise to send man page later. Ive coerced someone to do it;->
cheers,
jamal
^ permalink raw reply
* Re: [RFC PATCH v3 net-next 2/3] tcp: Handle eor bit when coalescing skb
From: Soheil Hassas Yeganeh @ 2016-04-21 21:14 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: netdev, Eric Dumazet, Neal Cardwell, Willem de Bruijn,
Yuchung Cheng, Kernel Team
In-Reply-To: <20160421165633.GA74969@kafai-mba.local>
On Thu, Apr 21, 2016 at 12:56 PM, Martin KaFai Lau <kafai@fb.com> wrote:
> On Wed, Apr 20, 2016 at 04:04:54PM -0400, Soheil Hassas Yeganeh wrote:
>> > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
>> > index a6e4a83..96bdf98 100644
>> > --- a/net/ipv4/tcp_output.c
>> > +++ b/net/ipv4/tcp_output.c
>> > @@ -2494,6 +2494,7 @@ static void tcp_collapse_retrans(struct sock *sk, struct sk_buff *skb)
>> > * packet counting does not break.
>> > */
>> > TCP_SKB_CB(skb)->sacked |= TCP_SKB_CB(next_skb)->sacked & TCPCB_EVER_RETRANS;
>> > + TCP_SKB_CB(skb)->eor = TCP_SKB_CB(next_skb)->eor;
>> >
>> > /* changed transmit queue under us so clear hints */
>> > tcp_clear_retrans_hints_partial(tp);
>> > @@ -2545,6 +2546,9 @@ static void tcp_retrans_try_collapse(struct sock *sk, struct sk_buff *to,
>> > if (!tcp_can_collapse(sk, skb))
>> > break;
>> >
>> > + if (TCP_SKB_CB(to)->eor)
>> > + break;
>> > +
>>
>> nit: Perhaps a better place to check for eor is right after entering
>> the loop? to skip a few instructions and tcp_can_collapse, in an
>> unlikely case eor is set.
> hmm... Not sure I understand it.
> You meant moving the unlikely case before (or after?) the more likely
> cases which may have a better chance to break the loop sooner?
Well I don't have strong preference here. So, feel free to ignore.
Though I'm not sure how "likely" are the checks in tcp_can_collapse.
On another note, do you think putting this is a self-documenting
helper function, say tcp_can_collapse_to(), would help readability?
Thanks.
^ permalink raw reply
* Re: [PATCH] wcn36xx: Set SMD timeout to 10 seconds
From: John Stultz @ 2016-04-21 21:11 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Eugene Krasnikov, Kalle Valo, linux-wireless, netdev, lkml
In-Reply-To: <1461272982-7233-1-git-send-email-bjorn.andersson@linaro.org>
On Thu, Apr 21, 2016 at 2:09 PM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> After booting the wireless subsystem and uploading the NV blob to the
> WCNSS_CTRL service the remote continues to do things and will not start
> servicing wlan-requests for another 2-5 seconds (measured).
>
> The downstream code does not have any special handling for this case,
> but has a timeout of 10 seconds for the communication layer. By
> extending the wcn36xx timeout to match this we follows the same flow for
> the boot procedure and can successfully configure WiFi as wlan0 is
> registered.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
I've been using this with my nexus7 tree, and its avoided issues I was
seeing without it.
Tested-by: John Stultz <john.stultz@linaro.org>
thanks
-john
^ permalink raw reply
* [PATCH] wcn36xx: Set SMD timeout to 10 seconds
From: Bjorn Andersson @ 2016-04-21 21:09 UTC (permalink / raw)
To: Eugene Krasnikov, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel, John Stultz
After booting the wireless subsystem and uploading the NV blob to the
WCNSS_CTRL service the remote continues to do things and will not start
servicing wlan-requests for another 2-5 seconds (measured).
The downstream code does not have any special handling for this case,
but has a timeout of 10 seconds for the communication layer. By
extending the wcn36xx timeout to match this we follows the same flow for
the boot procedure and can successfully configure WiFi as wlan0 is
registered.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
drivers/net/wireless/ath/wcn36xx/smd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.h b/drivers/net/wireless/ath/wcn36xx/smd.h
index e6aadd273c46..6310560901f0 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.h
+++ b/drivers/net/wireless/ath/wcn36xx/smd.h
@@ -24,7 +24,7 @@
#define WCN36XX_HAL_BUF_SIZE 4096
-#define HAL_MSG_TIMEOUT 500
+#define HAL_MSG_TIMEOUT 10000
#define WCN36XX_SMSM_WLAN_TX_ENABLE 0x00000400
#define WCN36XX_SMSM_WLAN_TX_RINGS_EMPTY 0x00000200
/* The PNO version info be contained in the rsp msg */
--
2.5.0
^ permalink raw reply related
* Re: [PATCH] ixgbevf: Fix relaxed order settings in VF driver
From: Alexander Duyck @ 2016-04-21 21:00 UTC (permalink / raw)
To: Babu Moger
Cc: Jeff Kirsher, Brandeburg, Jesse, shannon nelson, Carolyn Wyborny,
Skidmore, Donald C, Bruce W Allan, John Ronciak, Mitch Williams,
intel-wired-lan, Netdev, linux-kernel@vger.kernel.org,
Sowmini Varadhan
In-Reply-To: <57192C7D.9080507@oracle.com>
On Thu, Apr 21, 2016 at 12:39 PM, Babu Moger <babu.moger@oracle.com> wrote:
> Hi Alex,
>
> On 4/21/2016 2:22 PM, Alexander Duyck wrote:
>> On Thu, Apr 21, 2016 at 11:13 AM, Alexander Duyck
>> <alexander.duyck@gmail.com> wrote:
>>> On Thu, Apr 21, 2016 at 10:21 AM, Babu Moger <babu.moger@oracle.com> wrote:
>>>> Current code writes the tx/rx relaxed order without reading it first.
>>>> This can lead to unintended consequences as we are forcibly writing
>>>> other bits.
>>>
>>> The consequences were very much intended as there are situations where
>>> enabling relaxed ordering can lead to data corruption.
>>>
>>>> We noticed this problem while testing VF driver on sparc. Relaxed
>>>> order settings for rx queue were all messed up which was causing
>>>> performance drop with VF interface.
>>>
>>> What additional relaxed ordering bits are you enabling on Sparc? I'm
>>> assuming it is just the Rx data write back but I want to verify.
>>>
>>>> Fixed it by reading the registers first and setting the specific
>>>> bit of interest. With this change we are able to match the bandwidth
>>>> equivalent to PF interface.
>>>>
>>>> Signed-off-by: Babu Moger <babu.moger@oracle.com>
>>>
>>> Fixed is a relative term here since you are only chasing performance
>>> from what I can tell. We need to make certain that this doesn't break
>>> the driver on any other architectures by leading to things like data
>>> corruption.
>>>
>>> - Alex
>>
>> It occurs to me that what might be easier is instead of altering the
>> configuration on all architectures you could instead wrap the write so
>> that on SPARC you include the extra bits you need and on all other
>> architectures you leave the write as-is similar to how the code in the
>> ixgbe_start_hw_gen2 only clears the bits if CONFIG_SPARC is not
>> defined.
>
>
> Here are the default values that I see when testing on Sparc.
>
> Default tx value 0x2a00
>
> All below 3 set
> #define IXGBE_DCA_TXCTRL_DESC_RRO_EN (1 << 9) /* Tx rd Desc Relax Order */
> #define IXGBE_DCA_TXCTRL_DESC_WRO_EN (1 << 11) /* Tx Desc writeback RO bit */
> #define IXGBE_DCA_TXCTRL_DATA_RRO_EN (1 << 13) /* Tx rd data Relax Order */
>
> I am not too worried about tx values. I can keep it as it is. It did not
> seem to cause any problems right now.
>
>
> Default rx value 0xb200
>
> All below 3 set plus one more
>
> #define IXGBE_DCA_RXCTRL_DESC_RRO_EN (1 << 9) /* DCA Rx rd Desc Relax Order */
> #define IXGBE_DCA_RXCTRL_DATA_WRO_EN (1 << 13) /* Rx wr data Relax Order */
> #define IXGBE_DCA_RXCTRL_HEAD_WRO_EN (1 << 15) /* Rx wr header RO */
So that looks like the register defaults. Which based on the released
data-sheet for 82599 are a bit off. The "one more" bit that is set is
supposed to be written as 0 as per the 82599 datasheet, but it
defaults to 1 for some reason. On the x540 data-sheet that appears to
be a no-snoop bit that you are enabling which should not be enabled.
It won't necessarily hurt things either though as I believe the
no-snoop bit is not being set in the descriptors.
> Is there a reason to disable IXGBE_DCA_RXCTRL_DATA_WRO_EN and
> IXGBE_DCA_RXCTRL_HEAD_WRO_EN for RX?
In the case of HEAD_WRO_EN it doesn't give us anything because we
don't have packet split/replication enabled anyway. That feature is
broken on the 82599, and was deprecated some time ago in the ixgbe
driver.
I don't have the fully history on the data writeback but I believe
there was an issue of where some x86 chipsets had issues when the
device enabled relaxed ordering. That was why relaxed ordering was
disabled on all writes for the device. I was the one that went
through and re-enabled relaxed ordering on reads from the device so we
at least allowed that much on most architectures.
You would probably only need to add IXGBE_DCA_RXCTRL_DATA_WRO_EN to
the write in the case of CONFIG_SPARC being defined. Another approach
might be to have a define value that you end up passing that is
defined one way if SPARC and another if a different architecture.
> I would think CONFIG_SPARC should be our last option. What do you think?
I was thinking CONFIG_SPARC would allow us to have feature parity with
the PF. If you look that is how this issue is solved there in
function ixgbe_start_hw_gen2(). That was why I was thinking that may
be the approach we want to take. Otherwise we have to write up some
complicated setup where we would have to use the API in order to
determine if the PF has already taken care of this for us which I
would prefer not to have to do.
- Alex
^ permalink raw reply
* Re: [RFC PATCH v2 net-next 2/7] tcp: Merge tx_flags/tskey/txstamp_ack in tcp_collapse_retrans
From: Willem de Bruijn @ 2016-04-21 20:25 UTC (permalink / raw)
To: Soheil Hassas Yeganeh
Cc: Martin KaFai Lau, Eric Dumazet, netdev, Neal Cardwell,
Soheil Hassas Yeganeh, Willem de Bruijn, Yuchung Cheng,
Kernel Team
In-Reply-To: <CACSApvbzAtCTnom+xyQmaG=ATwncMnvLLDdxqCAYWG7rgYbBmw@mail.gmail.com>
On Tue, Apr 19, 2016 at 2:24 PM, Soheil Hassas Yeganeh
<soheil@google.com> wrote:
> On Tue, Apr 19, 2016 at 2:18 PM, Martin KaFai Lau <kafai@fb.com> wrote:
>> On Tue, Apr 19, 2016 at 10:35:52AM -0700, Eric Dumazet wrote:
>>> On Tue, Apr 19, 2016 at 10:28 AM, Martin KaFai Lau <kafai@fb.com> wrote:
>>>
>>> > A bit off topic, I feel like the SKBTX_ACK_TSTAMP and txstamp_ack are sort
>>> > of redundant but I have not look into the details yet, so not completely
>>> > sure. It wwould be a separate cleanup patch if it is the case.
Yes, with the introduction of txstamp_ack, SKBTX_ACK_TSTAMP is completely
redundant.
>>>
>>> Please read 6b084928baac562ed61866f540a96120e9c9ddb7 changelog ;)
>>>
>>> A cache line miss avoidance is critical
>> I looked at the patch but I probably am missing something :(
>> Is checking txstamp_ack alone enough and SKBTX_ACK_TSTAMP is not needed
>> since they are always set together?
>
> That's right, the check on "(shinfo->tx_flags & SKBTX_ACK_TSTAMP)" in
> tcp_ack_tstamp() is redundant and I had a patch prepared to remove it.
You can even remove the flag completely and
- tcb->txstamp_ack = !!(shinfo->tx_flags & SKBTX_ACK_TSTAMP);
+ if (tsflags & SOF_TIMESTAMPING_TX_ACK)
+ tcb->txstamp_ack = 1;
> But I thought it's better to wait for
> https://patchwork.ozlabs.org/patch/611938/ to be merged first.
>
> Feel free to remove it in your patches, if you'd prefer that.
^ permalink raw reply
* [PATCH net] ipv4/fib: don't warn when primary address is missing if in_dev is dead
From: Paolo Abeni @ 2016-04-21 20:23 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Alexey Kuznetsov, linux-kernel
After commit fbd40ea0180a ("ipv4: Don't do expensive useless work
during inetdev destroy.") when deleting an interface,
fib_del_ifaddr() can be executed without any primary address
present on the dead interface.
The above is safe, but triggers some "bug: prim == NULL" warnings.
This commit avoids warning if the in_dev is dead
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
net/ipv4/fib_frontend.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 8a9246d..63566ec 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -904,7 +904,11 @@ void fib_del_ifaddr(struct in_ifaddr *ifa, struct in_ifaddr *iprim)
if (ifa->ifa_flags & IFA_F_SECONDARY) {
prim = inet_ifa_byprefix(in_dev, any, ifa->ifa_mask);
if (!prim) {
- pr_warn("%s: bug: prim == NULL\n", __func__);
+ /* if the device has been deleted, we don't perform
+ * address promotion
+ */
+ if (!in_dev->dead)
+ pr_warn("%s: bug: prim == NULL\n", __func__);
return;
}
if (iprim && iprim != prim) {
--
1.8.3.1
^ permalink raw reply related
* RE: [net-next 15/17] fm10k: fix possible null pointer deref after kcalloc
From: Keller, Jacob E @ 2016-04-21 20:09 UTC (permalink / raw)
To: Kirsher, Jeffrey T, David Miller
Cc: netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com
In-Reply-To: <1461268100.3018.5.camel@intel.com>
> On Thu, 2016-04-21 at 15:47 -0400, David Miller wrote:
> > From: "Keller, Jacob E" <jacob.e.keller@intel.com>
> > Date: Thu, 21 Apr 2016 19:44:24 +0000
> >
> > > Dave, please don't pull this patch. Krishneil found an issue with
> > > this patch, and I sent a corrected fix to squash in but it didn't
> > > make it into this one. I'd like to get the fix squashed in a resend
> > > before this is pulled into net-next.
> >
> > Too late, it's already in my tree.
>
> I will address Jakes concerns in my next fm10k pull request.
Thanks Jeff. Sorry I didn't notice this earlier.
Regards,
Jake
^ permalink raw reply
* Re: [PATCH net 0/2] tcp: Merge timestamp info when coalescing skbs
From: Willem de Bruijn @ 2016-04-21 19:58 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: Network Development, Eric Dumazet, Neal Cardwell,
Soheil Hassas Yeganeh, Willem de Bruijn, Yuchung Cheng,
Kernel Team
In-Reply-To: <1461130769-1442865-1-git-send-email-kafai@fb.com>
On Wed, Apr 20, 2016 at 1:39 AM, Martin KaFai Lau <kafai@fb.com> wrote:
> This series is separated from the RFC series related to
> tcp_sendmsg(MSG_EOR) and it is targeting for the net branch.
> This patchset is focusing on fixing cases where TCP
> timestamp could be lost after coalescing skbs.
Thanks for fixing these edge cases, Martin. And for the detailed
packetdrill tests to reproduce them. Those are very informative.
It took me too long to study the retransmit and especially the SACK
code to Ack the patches in a timely manner. But, yes, these code
paths had definitely escaped me when working on the earlier tcp
timestamping patches. Fixes look great, too, so fwiw a belated
Acked-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2016-04-21 19:55 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix memory leak in iwlwifi, from Matti Gottlieb.
2) Add missing registration of netfilter arp_tables into initial
namespace, from Florian Westphal.
3) Fix potential NULL deref in DecNET routing code.
4) Restrict NETLINK_URELEASE to truly bound sockets only, from Dmitry
Ivanov.
5) Fix dst ref counting in VRF, from David Ahern.
6) Fix TSO segmenting limits in i40e driver, from Alexander Duyck.
7) Fix heap leak in PACKET_DIAG_MCLIST, from Mathias Krause.
8) Ravalidate IPV6 datagram socket cached routes properly, particularly
with UDP, from Martin KaFai Lau.
9) Fix endian bug in RDS dp_ack_seq handling, from Qing Huang.
10) Fix stats typing in bcmgenet driver, from Eric Dumazet.
11) Openvswitch needs to orphan SKBs before ipv6 fragmentation
handing, from Joe Stringer.
12) SPI device reference leak in spi_ks8895 PHY driver, from Mark
Brown.
13) atl2 doesn't actually support scatter-gather, so don't advertise
the feature. From Ben Hucthings.
Please pull, thanks a lot!
The following changes since commit 183c948a3cb3efbf45eabed41fa7ee04c19378fc:
Merge tag 'tty-4.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty (2016-04-09 12:32:44 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to b4f70527f052b0c00be4d7cac562baa75b212df5:
openvswitch: use flow protocol when recalculating ipv6 checksums (2016-04-21 15:28:47 -0400)
----------------------------------------------------------------
Alexander Duyck (1):
i40e/i40evf: Limit TSO to 7 descriptors for payload instead of 8 per packet
Alexei Starovoitov (1):
bpf/verifier: reject invalid LD_ABS | BPF_DW instruction
Andrew Goodbody (2):
cpsw: Prevent NUll pointer dereference with two PHYs
Revert "Prevent NUll pointer dereference with two PHYs on cpsw"
Arnd Bergmann (3):
bcma: fix building without OF_IRQ
rtlwifi: fix gcc-6 indentation warning
macsec: fix crypto Kconfig dependency
Ben Hutchings (1):
atl2: Disable unimplemented scatter/gather feature
Bjørn Mork (1):
cdc_mbim: apply "NDP to end" quirk to all Huawei devices
Chris Friesen (1):
route: do not cache fib route info on local routes with oif
Craig Gallek (2):
soreuseport: fix ordering for mixed v4/v6 sockets
soreuseport: test mixed v4/v6 sockets
Daniel Borkmann (1):
vlan: pull on __vlan_insert_tag error path and fix csum correction
Daniel Jurgens (2):
net/mlx4_core: Implement pci_resume callback
net/mlx4_core: Avoid repeated calls to pci enable/disable
David Ahern (3):
net: vrf: Fix dst reference counting
net: vrf: Fix dev refcnt leak due to IPv6 prefix route
net: ipv6: Do not keep linklocal and loopback addresses
David Daney (1):
net: thunderx: Fix broken of_node_put() code.
David S. Miller (12):
decnet: Do not build routes to devices without decnet private data.
Merge branch 'tipc-fixes'
Merge tag 'wireless-drivers-for-davem-2016-04-13' of git://git.kernel.org/.../kvalo/wireless-drivers
Merge git://git.kernel.org/.../pablo/nf
Merge branch 'master' of git://git.kernel.org/.../jkirsher/net-queue
Merge tag 'mac80211-for-davem-2016-04-14' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'ipv6-dgram-dst-cache'
Merge branch 'soreuseport-mixed-v4-v6-fixes'
Merge branch 'dsa-mv88e6xxx-fix-cross-chip-bridging'
Merge branch 'tcp-coalesce-merge-timestamps'
Merge branch 'qed-fixes'
Merge branch 'mlx4-fixes'
Dmitry Ivanov (2):
netlink: don't send NETLINK_URELEASE for unbound sockets
nl80211: check netlink protocol in socket release notification
Emmanuel Grumbach (1):
iwlwifi: pcie: lower the debug level for RSA semaphore access
Emrah Demir (1):
mISDN: Fixing missing validation in base_sock_bind()
Eran Ben Elisha (1):
net/mlx4_en: Split SW RX dropped counter per RX ring
Eric Dumazet (1):
net: bcmgenet: device stats are unsigned long
Erik Hugne (2):
tipc: make dist queue pernet
tipc: purge deferred updates from dead nodes
Eugenia Emantayev (1):
net/mlx4_core: Don't allow to VF change global pause settings
Felix Fietkau (1):
bgmac: fix MAC soft-reset bit for corerev > 4
Florian Westphal (1):
netfilter: arp_tables: register table in initns
Grygorii Strashko (1):
drivers: net: cpsw: fix wrong regs access in cpsw_ndo_open
Hariprasad Shenai (1):
cxgb4: Stop Rx Queues before freeing it up
Jacob Keller (1):
fm10k: fix multi-bit VLAN update requests from VF
Jia-Ju Bai (1):
b43: Fix memory leaks in b43_bus_dev_ssb_init and b43_bus_dev_bcma_init
Joe Stringer (1):
openvswitch: Orphan skbs before IPv6 defrag
John Crispin (1):
net: mediatek: update the IRQ part of the binding document
Jorgen Hansen (1):
VSOCK: Only check error on skb_recv_datagram when skb is NULL
Jozsef Kadlecsik (1):
netfilter: nf_conntrack_tcp: Fix stack out of bounds when parsing TCP options
Kalle Valo (1):
Merge tag 'iwlwifi-for-kalle-2016-03-30' of https://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Konstantin Khlebnikov (3):
net/mlx4_en: allocate non 0-order pages for RX ring with __GFP_NOMEMALLOC
net/mlx4_en: do batched put_page using atomic_sub
cls_cgroup: get sk_classid only from full sockets
Lars Persson (1):
net: sched: do not requeue a NULL skb
Manish Chopra (3):
qede: Fix various memory allocation error flows for fastpath
qede: Fix setting Skb network header
qede: Fix single MTU sized packet from firmware GRO flow
Marcelo Ricardo Leitner (1):
sctp: avoid refreshing heartbeat timer too often
Mark Brown (1):
net: phy: spi_ks8895: Don't leak references to SPI devices
Martin KaFai Lau (7):
ipv6: datagram: Refactor flowi6 init codes to a new function
ipv6: datagram: Refactor dst lookup and update codes to a new function
ipv6: datagram: Update dst cache of a connected datagram sk during pmtu update
ipv6: udp: Do a route lookup and update during release_cb
tcp: Fix SOF_TIMESTAMPING_TX_ACK when handling dup acks
tcp: Merge tx_flags and tskey in tcp_collapse_retrans
tcp: Merge tx_flags and tskey in tcp_shifted_skb
Mathias Krause (1):
packet: fix heap info leak in PACKET_DIAG_MCLIST sock_diag interface
Matti Gottlieb (1):
iwlwifi: mvm: fix memory leak in paging
Neil Armstrong (2):
net: ethernet: davinci_emac: Fix Unbalanced pm_runtime_enable
net: ethernet: davinci_emac: Fix platform_data overwrite
Phil Reid (1):
net: stmmac: socfgpa: Ensure emac bit set in System Manger for PTP
Phil Sutter (1):
netfilter: ebtables: Fix extension lookup with identical name
Qing Huang (1):
RDS: fix endianness for dp_ack_seq
Rafał Miłecki (1):
bgmac: reset & enable Ethernet core before using it
Sergei Shtylyov (1):
sh_eth: re-enable-E-MAC interrupts in sh_eth_set_ringparam()
Shrikrishna Khare (1):
Driver: Vmxnet3: set CHECKSUM_UNNECESSARY for IPv6 packets
Simon Horman (1):
openvswitch: use flow protocol when recalculating ipv6 checksums
Vivien Didelot (3):
net: dsa: mv88e6xxx: unlock DSA and CPU ports
net: dsa: mv88e6xxx: enable SA learning on DSA ports
net: dsa: mv88e6xxx: share the same default FDB
Wolfram Sang (1):
net: ethernet: renesas: ravb_main: test clock rate to avoid division by 0
santosh.shilimkar@oracle.com (1):
RDS: Fix the atomicity for congestion map update
stephen hemminger (1):
devlink: add missing install of header
Documentation/devicetree/bindings/net/mediatek-net.txt | 7 ++-
drivers/bcma/main.c | 17 ++------
drivers/isdn/mISDN/socket.c | 3 ++
drivers/net/Kconfig | 1 +
drivers/net/dsa/mv88e6xxx.c | 34 +++------------
drivers/net/ethernet/atheros/atlx/atl2.c | 2 +-
drivers/net/ethernet/broadcom/bgmac.c | 5 +++
drivers/net/ethernet/broadcom/bgmac.h | 6 +--
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 6 ++-
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 5 ++-
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 3 ++
drivers/net/ethernet/chelsio/cxgb4/sge.c | 20 +++++++--
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 33 ++++++++++++++
drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 30 +++++++++----
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 49 +++++++++++----------
drivers/net/ethernet/intel/i40e/i40e_txrx.h | 10 +++--
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 49 +++++++++++----------
drivers/net/ethernet/intel/i40evf/i40e_txrx.h | 10 +++--
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 5 ++-
drivers/net/ethernet/mellanox/mlx4/en_port.c | 5 ++-
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 12 ++++--
drivers/net/ethernet/mellanox/mlx4/main.c | 76 ++++++++++++++++++++++++--------
drivers/net/ethernet/mellanox/mlx4/mlx4.h | 2 +
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 +
drivers/net/ethernet/mellanox/mlx4/port.c | 13 ++++++
drivers/net/ethernet/qlogic/qede/qede_main.c | 157 ++++++++++++++++++++++++++++++++++++++++++------------------------
drivers/net/ethernet/renesas/ravb_main.c | 3 ++
drivers/net/ethernet/renesas/sh_eth.c | 6 +--
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 16 +++++--
drivers/net/ethernet/ti/cpsw.c | 4 +-
drivers/net/ethernet/ti/davinci_emac.c | 3 +-
drivers/net/phy/spi_ks8995.c | 2 +-
drivers/net/usb/cdc_mbim.c | 9 +++-
drivers/net/vmxnet3/vmxnet3_drv.c | 12 ++++--
drivers/net/vmxnet3/vmxnet3_int.h | 4 +-
drivers/net/vrf.c | 177 +++++++--------------------------------------------------------------------
drivers/net/wireless/broadcom/b43/main.c | 6 ++-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 2 +
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 2 -
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 4 +-
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c | 6 +--
include/linux/mlx4/device.h | 7 +++
include/linux/rculist_nulls.h | 39 +++++++++++++++++
include/net/cls_cgroup.h | 7 ++-
include/net/ip6_route.h | 3 ++
include/net/ipv6.h | 2 +
include/net/route.h | 3 ++
include/net/sctp/structs.h | 8 +++-
include/net/sock.h | 6 ++-
include/net/tcp.h | 2 +
include/uapi/linux/Kbuild | 1 +
kernel/bpf/verifier.c | 1 +
net/bridge/netfilter/ebtables.c | 6 ++-
net/core/skbuff.c | 7 ++-
net/decnet/dn_route.c | 9 +++-
net/ipv4/netfilter/arptable_filter.c | 6 +++
net/ipv4/route.c | 19 ++++++--
net/ipv4/tcp_input.c | 4 +-
net/ipv4/tcp_output.c | 16 +++++++
net/ipv4/udp.c | 9 +++-
net/ipv6/addrconf.c | 22 +++++++++-
net/ipv6/datagram.c | 169 ++++++++++++++++++++++++++++++++++++++++++++---------------------------
net/ipv6/route.c | 19 ++++++--
net/ipv6/udp.c | 1 +
net/netfilter/nf_conntrack_proto_tcp.c | 4 ++
net/netlink/af_netlink.c | 2 +-
net/openvswitch/actions.c | 4 +-
net/openvswitch/conntrack.c | 1 +
net/packet/af_packet.c | 1 +
net/rds/cong.c | 4 +-
net/rds/ib_cm.c | 2 +-
net/sched/sch_generic.c | 5 ++-
net/sctp/outqueue.c | 15 ++++---
net/sctp/sm_make_chunk.c | 3 +-
net/sctp/sm_sideeffect.c | 36 +++++++---------
net/sctp/transport.c | 19 +++++---
net/tipc/core.c | 1 +
net/tipc/core.h | 3 ++
net/tipc/name_distr.c | 35 +++++++++++----
net/vmw_vsock/vmci_transport.c | 7 +--
net/wireless/nl80211.c | 2 +-
tools/testing/selftests/net/.gitignore | 1 +
tools/testing/selftests/net/Makefile | 2 +-
tools/testing/selftests/net/reuseport_dualstack.c | 208 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
84 files changed, 1009 insertions(+), 529 deletions(-)
create mode 100644 tools/testing/selftests/net/reuseport_dualstack.c
^ permalink raw reply
* Re: [net-next 15/17] fm10k: fix possible null pointer deref after kcalloc
From: Jeff Kirsher @ 2016-04-21 19:48 UTC (permalink / raw)
To: David Miller, jacob.e.keller; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20160421.154727.1143899173479860095.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 516 bytes --]
On Thu, 2016-04-21 at 15:47 -0400, David Miller wrote:
> From: "Keller, Jacob E" <jacob.e.keller@intel.com>
> Date: Thu, 21 Apr 2016 19:44:24 +0000
>
> > Dave, please don't pull this patch. Krishneil found an issue with
> > this patch, and I sent a corrected fix to squash in but it didn't
> > make it into this one. I'd like to get the fix squashed in a resend
> > before this is pulled into net-next.
>
> Too late, it's already in my tree.
I will address Jakes concerns in my next fm10k pull request.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [net-next 15/17] fm10k: fix possible null pointer deref after kcalloc
From: David Miller @ 2016-04-21 19:47 UTC (permalink / raw)
To: jacob.e.keller; +Cc: jeffrey.t.kirsher, netdev, nhorman, sassmann, jogreene
In-Reply-To: <02874ECE860811409154E81DA85FBB5857A7C1E0@ORSMSX115.amr.corp.intel.com>
From: "Keller, Jacob E" <jacob.e.keller@intel.com>
Date: Thu, 21 Apr 2016 19:44:24 +0000
> Dave, please don't pull this patch. Krishneil found an issue with
> this patch, and I sent a corrected fix to squash in but it didn't
> make it into this one. I'd like to get the fix squashed in a resend
> before this is pulled into net-next.
Too late, it's already in my tree.
^ permalink raw reply
* Re: [PATCH net-next 1/2] tcp: Carry txstamp_ack in tcp_fragment_tstamp
From: Willem de Bruijn @ 2016-04-21 19:45 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: Network Development, Eric Dumazet, Neal Cardwell,
Soheil Hassas Yeganeh, Willem de Bruijn, Yuchung Cheng,
Kernel Team
In-Reply-To: <1461131448-1460418-2-git-send-email-kafai@fb.com>
On Wed, Apr 20, 2016 at 1:50 AM, Martin KaFai Lau <kafai@fb.com> wrote:
> When a tcp skb is sliced into two smaller skbs (e.g. in
> tcp_fragment() and tso_fragment()), it does not carry
> the txstamp_ack bit to the newly created skb if it is needed.
> The end result is a timestamping event (SCM_TSTAMP_ACK) will
> be missing from the sk->sk_error_queue.
>
> This patch carries this bit to the new skb2
> in tcp_fragment_tstamp().
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> Cc: Soheil Hassas Yeganeh <soheil@google.com>
> Cc: Willem de Bruijn <willemb@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* RE: [net-next 15/17] fm10k: fix possible null pointer deref after kcalloc
From: Keller, Jacob E @ 2016-04-21 19:44 UTC (permalink / raw)
To: Kirsher, Jeffrey T, davem@davemloft.net
Cc: netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com
In-Reply-To: <1461218969-68578-16-git-send-email-jeffrey.t.kirsher@intel.com>
> -----Original Message-----
> From: Kirsher, Jeffrey T
> Sent: Wednesday, April 20, 2016 11:09 PM
> To: davem@davemloft.net
> Cc: Keller, Jacob E <jacob.e.keller@intel.com>; netdev@vger.kernel.org;
> nhorman@redhat.com; sassmann@redhat.com; jogreene@redhat.com;
> Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>
> Subject: [net-next 15/17] fm10k: fix possible null pointer deref after kcalloc
>
> From: Jacob Keller <jacob.e.keller@intel.com>
>
> When writing a new default redirection table, we needed to populate
> a new RSS table using ethtool_rxfh_indir_default. We populated this
> table into a region of memory allocated using kcalloc, but never checked
> this for NULL. Fix this by moving the default table generation into
> fm10k_write_reta. If this function is passed a table, use it. Otherwise,
> generate the default table using ethtool_rxfh_indir_default, 4 at at
> time.
>
> Fixes: 0ea7fae44094 ("fm10k: use ethtool_rxfh_indir_default for default
> redirection table")
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
Hi Dave, and Jeff,
Dave, please don't pull this patch. Krishneil found an issue with this patch, and I sent a corrected fix to squash in but it didn't make it into this one. I'd like to get the fix squashed in a resend before this is pulled into net-next.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH] ixgbevf: Fix relaxed order settings in VF driver
From: Babu Moger @ 2016-04-21 19:39 UTC (permalink / raw)
To: Alexander Duyck
Cc: Jeff Kirsher, Brandeburg, Jesse, shannon nelson, Carolyn Wyborny,
Skidmore, Donald C, Bruce W Allan, John Ronciak, Mitch Williams,
intel-wired-lan, Netdev, linux-kernel@vger.kernel.org,
Sowmini Varadhan
In-Reply-To: <CAKgT0UdEP9ZMnNjSSqh-vZvaEc9N8_X_KWvykChxRv1bretYtw@mail.gmail.com>
Hi Alex,
On 4/21/2016 2:22 PM, Alexander Duyck wrote:
> On Thu, Apr 21, 2016 at 11:13 AM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Thu, Apr 21, 2016 at 10:21 AM, Babu Moger <babu.moger@oracle.com> wrote:
>>> Current code writes the tx/rx relaxed order without reading it first.
>>> This can lead to unintended consequences as we are forcibly writing
>>> other bits.
>>
>> The consequences were very much intended as there are situations where
>> enabling relaxed ordering can lead to data corruption.
>>
>>> We noticed this problem while testing VF driver on sparc. Relaxed
>>> order settings for rx queue were all messed up which was causing
>>> performance drop with VF interface.
>>
>> What additional relaxed ordering bits are you enabling on Sparc? I'm
>> assuming it is just the Rx data write back but I want to verify.
>>
>>> Fixed it by reading the registers first and setting the specific
>>> bit of interest. With this change we are able to match the bandwidth
>>> equivalent to PF interface.
>>>
>>> Signed-off-by: Babu Moger <babu.moger@oracle.com>
>>
>> Fixed is a relative term here since you are only chasing performance
>> from what I can tell. We need to make certain that this doesn't break
>> the driver on any other architectures by leading to things like data
>> corruption.
>>
>> - Alex
>
> It occurs to me that what might be easier is instead of altering the
> configuration on all architectures you could instead wrap the write so
> that on SPARC you include the extra bits you need and on all other
> architectures you leave the write as-is similar to how the code in the
> ixgbe_start_hw_gen2 only clears the bits if CONFIG_SPARC is not
> defined.
Here are the default values that I see when testing on Sparc.
Default tx value 0x2a00
All below 3 set
#define IXGBE_DCA_TXCTRL_DESC_RRO_EN (1 << 9) /* Tx rd Desc Relax Order */
#define IXGBE_DCA_TXCTRL_DESC_WRO_EN (1 << 11) /* Tx Desc writeback RO bit */
#define IXGBE_DCA_TXCTRL_DATA_RRO_EN (1 << 13) /* Tx rd data Relax Order */
I am not too worried about tx values. I can keep it as it is. It did not
seem to cause any problems right now.
Default rx value 0xb200
All below 3 set plus one more
#define IXGBE_DCA_RXCTRL_DESC_RRO_EN (1 << 9) /* DCA Rx rd Desc Relax Order */
#define IXGBE_DCA_RXCTRL_DATA_WRO_EN (1 << 13) /* Rx wr data Relax Order */
#define IXGBE_DCA_RXCTRL_HEAD_WRO_EN (1 << 15) /* Rx wr header RO */
Is there a reason to disable IXGBE_DCA_RXCTRL_DATA_WRO_EN and
IXGBE_DCA_RXCTRL_HEAD_WRO_EN for RX?
I would think CONFIG_SPARC should be our last option. What do you think?
>
> - Alex
>
^ permalink raw reply
* Re: [PATCH net-next 0/7] net: network drivers should not depend on geneve/vxlan
From: David Miller @ 2016-04-21 19:36 UTC (permalink / raw)
To: hannes; +Cc: netdev, jesse
In-Reply-To: <1461224591.4101216.585253121.498EBE7C@webmail.messagingengine.com>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Thu, 21 Apr 2016 09:43:11 +0200
> Hi David,
>
> On Wed, Apr 20, 2016, at 03:11, David Miller wrote:
>> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
>> Date: Wed, 20 Apr 2016 03:06:13 +0200
>>
>> > On Wed, Apr 20, 2016, at 02:27, David Miller wrote:
>> >> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
>> >> Date: Mon, 18 Apr 2016 21:19:41 +0200
>> >>
>> >> > This patchset removes the dependency of network drivers on vxlan or
>> >> > geneve, so those don't get autoloaded when the nic driver is loaded.
>> >> >
>> >> > Also audited the code such that vxlan_get_rx_port and geneve_get_rx_port
>> >> > are not called without rtnl lock.
>> >>
>> >> In net-next, the 'qed' driver has tunneling offload support too.
>> >> Don't you need to update this series to handle that driver as
>> >> well?
>> >
>> > I audited qede as well:
>> >
>> > qede calls {vxlan,geneve}_get_rx_port only from ndo_open which isn't
>> > reused anywhere else in the driver, only from ndo_open, which holds
>> > rtnl_lock also. Thus the driver is safe and doesn't need a change.
>>
>> I'm talking about your final patches which elide the dependencies.
>
> could you look at this again? If you have further feedback I am happy to
> incooperate those.
Series applied, thanks Hannes.
^ permalink raw reply
* Re: [PATCH v2 0/4] net: thunderx: Add multiqset support for DPDK
From: David Miller @ 2016-04-21 19:31 UTC (permalink / raw)
To: sunil.kovvuri
Cc: netdev, linux-kernel, linux-arm-kernel, sgoutham, robert.richter
In-Reply-To: <1461221872-38841-1-git-send-email-sunil.kovvuri@gmail.com>
From: sunil.kovvuri@gmail.com
Date: Thu, 21 Apr 2016 12:27:48 +0530
> This patch series mainly adds support for userspace application
> like DPDK with a VNIC VF attached to request additional QSets
> for having morethan the default 8 queues.
I don't think it's appropriate to add facilities for non-upstream
features, especially DPDK.
Thanks.
^ permalink raw reply
* Re: [PATCH net] openvswitch: use flow protocol when recalculating ipv6 checksums
From: David Miller @ 2016-04-21 19:29 UTC (permalink / raw)
To: simon.horman; +Cc: pshelar, jesse, netdev, dev, jrajahalme
In-Reply-To: <1461203355-3088-1-git-send-email-simon.horman@netronome.com>
From: Simon Horman <simon.horman@netronome.com>
Date: Thu, 21 Apr 2016 11:49:15 +1000
> When using masked actions the ipv6_proto field of an action
> to set IPv6 fields may be zero rather than the prevailing protocol
> which will result in skipping checksum recalculation.
>
> This patch resolves the problem by relying on the protocol
> in the flow key rather than that in the set field action.
>
> Fixes: 83d2b9ba1abc ("net: openvswitch: Support masked set actions.")
> Cc: Jarno Rajahalme <jrajahalme@nicira.com>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
Looks good to me, applied and queued up for -stable.
Thanks Simon.
^ permalink raw reply
* Re: [PATCH net] Driver: Vmxnet3: set CHECKSUM_UNNECESSARY for IPv6 packets
From: David Miller @ 2016-04-21 19:29 UTC (permalink / raw)
To: skhare; +Cc: netdev, linux-kernel, pv-drivers, heoj
In-Reply-To: <1461201149-45583-1-git-send-email-skhare@vmware.com>
From: Shrikrishna Khare <skhare@vmware.com>
Date: Wed, 20 Apr 2016 18:12:29 -0700
> For IPv6, if the device indicates that the checksum is correct, set
> CHECKSUM_UNNECESSARY.
>
> Reported-by: Subbarao Narahari <snarahari@vmware.com>
> Signed-off-by: Shrikrishna Khare <skhare@vmware.com>
> Signed-off-by: Jin Heo <heoj@vmware.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ixgbevf: Fix relaxed order settings in VF driver
From: Alexander Duyck @ 2016-04-21 19:22 UTC (permalink / raw)
To: Babu Moger
Cc: Jeff Kirsher, Brandeburg, Jesse, shannon nelson, Carolyn Wyborny,
Skidmore, Donald C, Bruce W Allan, John Ronciak, Mitch Williams,
intel-wired-lan, Netdev, linux-kernel@vger.kernel.org,
Sowmini Varadhan
In-Reply-To: <CAKgT0UeU+Q1HDvR8pK3kxYofjEqk8jVeh5xONoUpD34MsPZCCA@mail.gmail.com>
On Thu, Apr 21, 2016 at 11:13 AM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Thu, Apr 21, 2016 at 10:21 AM, Babu Moger <babu.moger@oracle.com> wrote:
>> Current code writes the tx/rx relaxed order without reading it first.
>> This can lead to unintended consequences as we are forcibly writing
>> other bits.
>
> The consequences were very much intended as there are situations where
> enabling relaxed ordering can lead to data corruption.
>
>> We noticed this problem while testing VF driver on sparc. Relaxed
>> order settings for rx queue were all messed up which was causing
>> performance drop with VF interface.
>
> What additional relaxed ordering bits are you enabling on Sparc? I'm
> assuming it is just the Rx data write back but I want to verify.
>
>> Fixed it by reading the registers first and setting the specific
>> bit of interest. With this change we are able to match the bandwidth
>> equivalent to PF interface.
>>
>> Signed-off-by: Babu Moger <babu.moger@oracle.com>
>
> Fixed is a relative term here since you are only chasing performance
> from what I can tell. We need to make certain that this doesn't break
> the driver on any other architectures by leading to things like data
> corruption.
>
> - Alex
It occurs to me that what might be easier is instead of altering the
configuration on all architectures you could instead wrap the write so
that on SPARC you include the extra bits you need and on all other
architectures you leave the write as-is similar to how the code in the
ixgbe_start_hw_gen2 only clears the bits if CONFIG_SPARC is not
defined.
- Alex
^ permalink raw reply
* Re: [PATCH net] atl2: Disable unimplemented scatter/gather feature
From: David Miller @ 2016-04-21 19:12 UTC (permalink / raw)
To: ben; +Cc: netdev, jyackoski
In-Reply-To: <20160420222308.GJ3348@decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Wed, 20 Apr 2016 23:23:08 +0100
> atl2 includes NETIF_F_SG in hw_features even though it has no support
> for non-linear skbs. This bug was originally harmless since the
> driver does not claim to implement checksum offload and that used to
> be a requirement for SG.
>
> Now that SG and checksum offload are independent features, if you
> explicitly enable SG *and* use one of the rare protocols that can use
> SG without checkusm offload, this potentially leaks sensitive
> information (before you notice that it just isn't working). Therefore
> this obscure bug has been designated CVE-2016-2117.
>
> Reported-by: Justin Yackoski <jyackoski@crypto-nite.com>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> Fixes: ec5f06156423 ("net: Kill link between CSUM and SG features.")
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [net-next PATCH v2 0/3] Feature tweaks/fixes follow-up to GSO partial patches
From: David Miller @ 2016-04-21 19:11 UTC (permalink / raw)
To: aduyck; +Cc: netdev, alexander.duyck
In-Reply-To: <20160420144720.3100.74116.stgit@ahduyck-xeon-server>
From: Alexander Duyck <aduyck@mirantis.com>
Date: Wed, 20 Apr 2016 10:49:00 -0400
> This patch series is a set of minor fix-ups and tweaks following the GSO
> partial and TSO with IPv4 ID mangling patches. It mostly is just meant to
> make certain that if we have GSO partial support at the device we can make
> use of it from the far end of the tunnel.
>
> v2: Added cover page which was forgotten with first submission.
> Added patch that enables TSOv4 IP ID mangling w/ tunnels and/or VLANs.
Since I already applied the first two patches, I just applied the third one
here by itself.
I hope that's OK.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next V3 00/11] Mellanox 100G mlx5 driver receive path optimizations
From: David Miller @ 2016-04-21 19:09 UTC (permalink / raw)
To: saeedm; +Cc: netdev, ogerlitz, talal, tariqt, eranbe, edumazet, brouer
In-Reply-To: <1461178939-20687-1-git-send-email-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Wed, 20 Apr 2016 22:02:08 +0300
...
> This series includes Some RX modifications and optimizations for
> the mlx5 Ethernet driver.
...
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/2] net: bcmsysport: utilize newer NAPI APIs
From: David Miller @ 2016-04-21 19:06 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, edumazet, pgynther
In-Reply-To: <1461177429-23553-1-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 20 Apr 2016 11:37:07 -0700
> These two patches are very analoguous to what was already submitted for
> BCMGENET and switch the SYSTEMPORT driver to utilizing __napi_schedule_irqoff()
> and napi_complete_done for the RX NAPI context.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net 0/4] Mellaox 40G driver fixes for 4.6-rc
From: David Miller @ 2016-04-21 19:03 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev, eranbe, yishaih
In-Reply-To: <1461157278-18528-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Wed, 20 Apr 2016 16:01:14 +0300
> With the fix for ARM bug being under the works, these are
> few other fixes for mlx4 we have ready to go.
>
> Eran addressed the problematic/wrong reporting of dropped packets, Daniel
> fixed some matters related to PPC EEH's and Jenny's patch makes sure
> VFs can't change the port's pause settings.
Series applied, thanks.
^ 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