David Miller wrote:
> > Can you pull this into net-next please?
>
> I'll pull, but this is not how I want you to operate.
>
> If you change stuff, you must repost the entire series. And this is
> one of many reasons I want people to keep patch sets small, so that
> this is less painful.
>
> B
From: Marcelo Ricardo Leitner
Date: Thu, 7 Jul 2016 09:39:29 -0300
> When we introduced GSO support, if using auth the auth chunk was being
> left queued on the packet even after the final segment was generated.
> Later on sctp_transmit_packet it calls sctp_packet_reset, which zeroed
> the packe
From: Dan Carpenter
Date: Thu, 7 Jul 2016 11:23:09 +0300
> This code generates as static checker warning because htons(ETH_P_IPV6)
> is always true. From the context it looks like the && was intended to
> be !=.
>
> Fixes: 94758f8de037 ('bnxt_en: Add GRO logic for BCM5731X chips.')
> Signed-off
From: Alexei Starovoitov
Date: Wed, 6 Jul 2016 22:38:36 -0700
> over time there were multiple requests to access different data
> structures and fields of task_struct current, so finally add
> the helper to access 'current' as-is. Tracing bpf programs will do
> the rest of walking the pointers vi
From: Vivien Didelot
Date: Wed, 6 Jul 2016 20:03:54 -0400
> The routing table of every switch in a tree is currently initialized to
> all zeros. This is an issue since 0 is a valid port number.
>
> Add a DSA_RTABLE_NONE=-1 constant to initialize the signed values of the
> routing table pointing
This commit extends rtnl_unicast() to specify GFP flags.
This commit depends on Eric Dumazet's commits below.
ipv4: do not abuse GFP_ATOMIC in inet_netconf_notify_devconf()
ipv6: do not abuse GFP_ATOMIC in inet6_netconf_notify_devconf()
Signed-off-by: Masashi Honma
---
include/l
From: Craig Gallek
Date: Wed, 6 Jul 2016 18:44:20 -0400
> From: Craig Gallek
>
> The referenced change added a netlink notifier for processing
> device queue size events. These events are fired for all devices
> but the registered callback assumed they only occurred for tun
> devices. This f
From: Johannes Berg
Date: Wed, 6 Jul 2016 14:27:43 +0200
> People found two more bugs, so I have two more fixes. Both are related to
> memory - one's a leak, the other is a missing allocation failure check.
>
> These are both tagged for stable already, and shouldn't conflict with any
> other pa
On 2016年07月06日 09:28, Masashi Honma wrote:
> Though netlink_broadcast() ...
Thanks for reply of David Miller, Eric Dumazet, David Teigrand.
On the basis of their comment, only rtnl_unicast() looks need to add gfp
flag
argument. So I will drop almost of patches except 0005.
I will send patch v2 t
On 2016年07月09日 01:08, David Teigland wrote:
On Thu, Jul 07, 2016 at 09:35:45AM +0900, Masashi Honma wrote:
At the fs/dlm/netlink.c#dlm_timeout_warn(),
prepare_data allocates buffer with GFP_NOFS
and send_data() sends the buffer.
But send_data() uses GFP_KERNEL or GFP_ATOMIC inside it.
Should it
From: David Howells
Date: Wed, 06 Jul 2016 11:48:15 +0100
> Hi Dave,
>
> Can you pull this into net-next please?
I'll pull, but this is not how I want you to operate.
If you change stuff, you must repost the entire series. And this is
one of many reasons I want people to keep patch sets small
From: Hayes Wang
Date: Wed, 6 Jul 2016 17:03:29 +0800
> The LAN_WAKE_EN is not used to determine if the device could support
> WOL. It is used to sigal a GPIO pin when a WOL event occurs. The WOL
> still works even though it is disabled.
>
> Signed-off-by: Hayes Wang
Applied.
From: Cong Wang
Date: Tue, 5 Jul 2016 22:12:36 -0700
> Matt reported that we have a NULL pointer dereference
> in ppp_pernet() from ppp_connect_channel(),
> i.e. pch->chan_net is NULL.
>
> This is due to that a parallel ppp_unregister_channel()
> could happen while we are in ppp_connect_channel
From: Marcin Wojtas
Date: Wed, 6 Jul 2016 04:18:58 +0200
> From: Dmitri Epshtein
>
> Commit aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay") intended to
> set coalescing threshold to a value guaranteeing interrupt generation
> per each sent packet, so that buffers can be released with no d
From: k...@exchange.microsoft.com
Date: Tue, 5 Jul 2016 16:52:46 -0700
> From: K. Y. Srinivasan
>
> Use the new APIs for eliminating a copy on the receive path. These new APIs
> also
> help in minimizing the number of memory barriers we end up issuing (in the
> ringbuffer code) since we can be
From: Shmulik Ladkani
Date: Tue, 5 Jul 2016 17:05:41 +0300
> On Tue, 5 Jul 2016 15:03:27 +0200, f...@strlen.de wrote:
>> (Or did I misunderstand this setup...?)
>
> tap0 bridged with vxlan0.
> route to vxlan0's remote peer is via eth0, configured with small mtu.
Florian, any more comments?
From: Florian Westphal
Date: Mon, 4 Jul 2016 16:22:20 +0200
> hfsc_sched is huge (size: 920, cachelines: 15), but we can get it to 14
> cachelines by placing level after filter_cnt (covering 4 byte hole) and
> reducing period/nactive/flags to u32 (period is just a counter,
> incremented when cla
On Fri, Jul 8, 2016 at 4:04 PM, Hannes Frederic Sowa
wrote:
> On 08.07.2016 18:11, Alexander Duyck wrote:
>> On Fri, Jul 8, 2016 at 2:51 PM, Hannes Frederic Sowa
>> wrote:
>>> On 08.07.2016 17:27, Alexander Duyck wrote:
On Fri, Jul 8, 2016 at 1:57 PM, Hannes Frederic Sowa
wrote:
>
On Sat, Jul 09, 2016 at 01:31:40AM +0200, Eric Dumazet wrote:
> On Fri, 2016-07-08 at 17:52 +0200, Michal Kubecek wrote:
> > If socket filter truncates an udp packet below the length of UDP header
> > in udpv6_queue_rcv_skb() or udp_queue_rcv_skb(), it will trigger a
> > BUG_ON in skb_pull_rcsum().
Hi Andrew,
On Jul 7, 2016, at 9:52 AM, Andrew Lunn and...@lunn.ch wrote:
>> Also, note that this indirect access is a single-register which doesn't
>> require to wait for the operation to complete (like Switch MAC, Trunk
>> Mapping, etc.), in contrary to multi-registers indirect accesses with
>>
On Fri, 2016-07-08 at 17:52 +0200, Michal Kubecek wrote:
> If socket filter truncates an udp packet below the length of UDP header
> in udpv6_queue_rcv_skb() or udp_queue_rcv_skb(), it will trigger a
> BUG_ON in skb_pull_rcsum(). This BUG_ON (and therefore a system crash if
> kernel is configured t
Aaron Conole wrote:
> --- a/net/netfilter/core.c
> +++ b/net/netfilter/core
[..]
> +#define nf_entry_dereference(e) \
> + rcu_dereference_protected(e, lockdep_is_held(&nf_hook_mutex))
>
> -static struct list_head *nf_find_hook_list(struct net *net,
> -
Hello!
I can tell why it has not been done initially.
Main problem was in IP options, which can be present in raw packet.
They have to be properly fragmented, some options are to be deleted
on fragments. Not that it is too complicated, it is just boring and ugly
and inconsistent with IP_HDRINCL l
On 08.07.2016 18:11, Alexander Duyck wrote:
> On Fri, Jul 8, 2016 at 2:51 PM, Hannes Frederic Sowa
> wrote:
>> On 08.07.2016 17:27, Alexander Duyck wrote:
>>> On Fri, Jul 8, 2016 at 1:57 PM, Hannes Frederic Sowa
>>> wrote:
On 08.07.2016 16:17, Shmulik Ladkani wrote:
> On Fri, 8 Jul 2016
On 07/08/2016 03:54 PM, Philippe Reynes wrote:
> This reverts commit 4386f5662e63 ("net: ethernet: bcmgenet: use
> phy_ethtool_{get|set}_link_ksettings")
>
> This patch is wrong, the function phy_ethtool_{get|set}_link_ksettings
> don't check if the device is running, but the driver bcmgenet need
This reverts commit 4386f5662e63 ("net: ethernet: bcmgenet: use
phy_ethtool_{get|set}_link_ksettings")
This patch is wrong, the function phy_ethtool_{get|set}_link_ksettings
don't check if the device is running, but the driver bcmgenet need this
check.
The function {get|set}_settings need to acce
From: Jon Mason
Date: Fri, 8 Jul 2016 11:52:42 -0400
> Oops. I didn't send out the 7th patch in this series. Sending out
> shortly as 7/7.
Please don't do things like this.
If there is a mistake, always resend the entire series as a completely
new set of postings.
That way there is never any
From: Paul Jakma
Date: Fri, 8 Jul 2016 13:55:11 +0100 (BST)
> On Wed, 15 Jun 2016, Alan Davey wrote:
>
>> The only case that would break is that where an application relies on
>> the existing (documented as a bug) feature of getting an EMSGSIZE
>> return code in the case of an over-sized packet.
On Fri, Jul 8, 2016 at 2:51 PM, Hannes Frederic Sowa
wrote:
> On 08.07.2016 17:27, Alexander Duyck wrote:
>> On Fri, Jul 8, 2016 at 1:57 PM, Hannes Frederic Sowa
>> wrote:
>>> On 08.07.2016 16:17, Shmulik Ladkani wrote:
On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck
wrote:
> On
On 08.07.2016 17:19, Shmulik Ladkani wrote:
> On Fri, 8 Jul 2016 16:57:10 -0400 Hannes Frederic Sowa
> wrote:
>> On 08.07.2016 16:17, Shmulik Ladkani wrote:
>>> On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck
>>> wrote:
I get that there is an impression that it is redundant but there a
On 08.07.2016 17:27, Alexander Duyck wrote:
> On Fri, Jul 8, 2016 at 1:57 PM, Hannes Frederic Sowa
> wrote:
>> On 08.07.2016 16:17, Shmulik Ladkani wrote:
>>> On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck
>>> wrote:
On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni wrote:
> With udp tunn
On Fri, Jul 8, 2016 at 1:57 PM, Hannes Frederic Sowa
wrote:
> On 08.07.2016 16:17, Shmulik Ladkani wrote:
>> On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck
>> wrote:
>>> On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni wrote:
With udp tunnel offload in place, the kernel can do GRO for some u
On Fri, 8 Jul 2016 16:57:10 -0400 Hannes Frederic Sowa
wrote:
> On 08.07.2016 16:17, Shmulik Ladkani wrote:
> > On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck
> > wrote:
> >> I get that there is an impression that it is redundant but there are a
> >> number of paths that could lead to VXLA
On Fri, Jul 8, 2016 at 9:51 AM, Jason Gunthorpe
wrote:
> So, it appears, the dst and neigh can be used for all performances cases.
>
> For the non performance dst == null case, can we just burn cycles and
> stuff the daddr in front of the packet at hardheader time, even if we
> have to copy?
OK,
This adds kernel-doc style descriptions for 6 functions and
fixes 1 typo.
Signed-off-by: Richard Sailer
---
net/ipv4/tcp_timer.c | 66 +---
1 file changed, 57 insertions(+), 9 deletions(-)
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
i
On Thu, Jul 7, 2016 at 10:58 AM, Paolo Abeni wrote:
> currently, UDP packets with zero checksum are not allowed to
> use udp offload's GRO. This patch admits such packets to
> GRO, if the related socket settings allow it: ipv6 packets
> are not admitted if the sockets don't have the no_check6_rx
>
On 08.07.2016 16:17, Shmulik Ladkani wrote:
> On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck
> wrote:
>> On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni wrote:
>>> With udp tunnel offload in place, the kernel can do GRO for some udp tunnels
>>> at the ingress device level. Currently both the gene
On Fri, Jul 08, 2016 at 11:39:11AM -0700, Florian Fainelli wrote:
> Hi all,
>
> This patch series updates the B53 driver to support Broadcom's Northstar Plus
> Soc integrated switch.
Reviewed-by: Andrew Lunn
Andrew
On Fri, 8 Jul 2016 09:21:40 -0700 Alexander Duyck
wrote:
> On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni wrote:
> > With udp tunnel offload in place, the kernel can do GRO for some udp tunnels
> > at the ingress device level. Currently both the geneve and the vxlan drivers
> > implement an additio
On Fri, Jul 08, 2016 at 11:49:27AM -0700, Florian Fainelli wrote:
> This patch series is based on Broadcom/stblinux/devicetree/next which
> contains proper support for the BCM958625HR board. To get working
> Ethernet switch and CPU Ethernet support, the following dependencies
> based on David Mille
On Fri, Jul 8, 2016 at 8:42 AM, Colin King wrote:
> From: Colin Ian King
>
> rc is not initialized so it can contain garbage if it is not
> set by the call to bnxt_read_sfp_module_eeprom_info. Ensure
> garbage is not returned by initializing rc to 0.
>
> Signed-off-by: Colin Ian King
Thanks.
A
On 07/08/2016 11:48 AM, Florian Fainelli wrote:
> This patch series is based on Broadcom/stblinux/devicetree/next which
> contains proper support for the BCM958625HR board. To get working
> Ethernet switch and CPU Ethernet support, the following dependencies
> based on David Miller's net-next tree
Add the layout of the switch ports found on the BCM958625HR reference
board. The CPU port is hooked up to the AMAC0 Ethernet controlelr
adapter, so we also enable it.
Signed-off-by: Florian Fainelli
---
arch/arm/boot/dts/bcm958625hr.dts | 49 +++
1 file change
Add the Switch Register Access Block node, this peripheral is identical
to the BCM5301x Northstar SoC, but we utilize the SoC-wide
"brcm,nsp-srab" compatible string to illustrate the integration
difference here.
Signed-off-by: Florian Fainelli
---
arch/arm/boot/dts/bcm-nsp.dtsi | 11 +++
Add the Switch Register Access Block node, this peripheral is identical
to the BCM5301x Northstar SoC, but we utilize the SoC-wide
"brcm,nsp-srab" compatible string to illustrate the integration
difference here.
Signed-off-by: Florian Fainelli
---
arch/arm/boot/dts/bcm-nsp.dtsi | 11 +++
This patch series is based on Broadcom/stblinux/devicetree/next which
contains proper support for the BCM958625HR board. To get working
Ethernet switch and CPU Ethernet support, the following dependencies
based on David Miller's net-next tree are required:
- Jon Mason's BGMAC/AMAC support: https:/
Add the Switch Register Access Block which is a special piece of
hardware allowing us to perform indirect read/writes towards the
integrated BCM5301X Ethernet switch.
We also add the 4 Gigabit MAC Device Tree nodes within the brcm,bus-axi
bus node to get proper binding between the BCMA instantiate
This patch series is based on Broadcom/stblinux/devicetree/next which
contains proper support for the BCM958625HR board. To get working
Ethernet switch and CPU Ethernet support, the following dependencies
based on David Miller's net-next tree are required:
- Jon Mason's BGMAC/AMAC support: https:/
Add interrupt mapping for the Switch Register Access Block. Only 12
interrupts are usable at the moment even though up to 32 are dedicated
to the SRAB.
Signed-off-by: Florian Fainelli
---
arch/arm/boot/dts/bcm5301x.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/ar
Add the layout of the switch ports found on the BCM958625HR reference
board. The CPU port is hooked up to the AMAC0 Ethernet controlelr
adapter, so we also enable it.
Signed-off-by: Florian Fainelli
---
arch/arm/boot/dts/bcm958625hr.dts | 49 +++
1 file change
Update the SRAB, core driver and binding document to support the
BCM585xx/586xx/88312 integrated switch (Northstar Plus SoCs family).
Signed-off-by: Florian Fainelli
---
Documentation/devicetree/bindings/net/dsa/b53.txt | 9 +
drivers/net/dsa/b53/b53_common.c | 12 +
Hi all,
This patch series updates the B53 driver to support Broadcom's Northstar Plus
Soc integrated switch.
Unlike the version of the core present in BCM5301x/Northstar, we cannot read the
full chip id of the switch, so we need to get the information about our switch
id from Device Tree.
Other
For Northstart Plus SoCs, we cannot detect the switch because only the
revision information is provied in the Management page, instead, rely on
Device Tree to tell us the chip id, and pass it down using the
b53_platform_data structure.
Signed-off-by: Florian Fainelli
---
drivers/net/dsa/b53/b53_
On 07/07/2016 04:08 PM, Jon Mason wrote:
> Signed-off-by: Jon Mason
Reviewed-by: Florian Fainelli
Tested-by: Florian Fainelli
--
Florian
On 07/07/2016 04:08 PM, Jon Mason wrote:
> The bgmac driver is using the bcma provides device ID and revision, as
> well as the SoC ID and package, to determine which features are
> necessary to enable, reset, etc in the driver. In anticipation of
> removing the bcma requirement for this driver,
On 07/07/2016 04:08 PM, Jon Mason wrote:
> The dma buffer allocation, etc references a dma_dev device pointer from
> the bcma core. In anticipation of removing the bcma requirement for
> this driver, these must be changed to not reference that struct. Add a
> dma_dev device pointer to the bgmac s
On 07/07/2016 04:08 PM, Jon Mason wrote:
> Move the BCMA MDIO phy into a separate file, as it is very tightly
> coupled with the BCMA bus. This will help with the upcoming BCMA
> removal from the bgmac driver. Optimally, this should be moved into
> phy drivers, but it is too tightly coupled with
On 07/07/2016 04:08 PM, Jon Mason wrote:
> The bcma portion of the driver has been split off into a bcma specific
> driver. This has been mirrored for the platform driver. The last
> references to the bcma core struct have been changed into a generic
> function call. These function calls are wra
On 07/07/2016 04:08 PM, Jon Mason wrote:
> The bgmac_* print wrappers call dev_* prints with the dev pointer from
> the bcma core. In anticipation of removing the bcma requirement for
> this driver, these must be changed to not reference that struct. So,
> simply change all of the bgmac_* prints
On 07/07/2016 04:08 PM, Jon Mason wrote:
> David Miller, Please consider including patches 1-5 in net-next
>
> Florian Fainelli, Please consider including patches 6 & 7 in
> devicetree/next
David should pick all 6 patches, including the binding documentation, as
this comes with the driver, I wi
On Fri, 8 Jul 2016 09:45:25 -0700, John Fastabend wrote:
> The only distinction between VFs and queue groupings on my side is VFs
> provide RSS where as queue groupings have to be selected explicitly.
> In a programmable NIC world the distinction might be lost if a "RSS"
> program can be loaded int
Export cxgbi_ppm_release() to release
ppod manager and cxgbi_tagmask_set() to
set tag mask, they are used by cxgb3i, cxgb4i
and cxgbit.
Signed-off-by: Varun Prakash
---
drivers/net/ethernet/chelsio/libcxgb/libcxgb_ppm.c | 2 ++
drivers/scsi/cxgbi/cxgb3i/cxgb3i.c | 1 +
drivers/sc
Fix following sparse warnings
warning: symbol 'cxgb3i_ofld_init' was not declared. Should it be static?
warning: symbol 'cxgb4i_cplhandlers' was not declared. Should it be static?
warning: symbol 'cxgb4i_ofld_init' was not declared. Should it be static?
Signed-off-by: Varun Prakash
---
drivers/s
Add iSCSI DDP support in cxgb4i driver
using common iSCSI DDP Page Pod Manager.
Signed-off-by: Varun Prakash
---
drivers/scsi/cxgbi/Makefile| 2 +
drivers/scsi/cxgbi/cxgb3i/Kbuild | 1 +
drivers/scsi/cxgbi/cxgb3i/Kconfig | 1 +
drivers/scsi/cxgbi/cxgb4i/Kbuild | 1 +
drivers
Remove old ddp code from cxgb3i,cxgb4i,libcxgbi.
Next two commits adds DDP support using
common iSCSI DDP Page Pod Manager.
Signed-off-by: Varun Prakash
---
drivers/scsi/cxgbi/cxgb3i/cxgb3i.c | 128
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 142 -
drivers/scsi/cxgbi/libcxgbi.c
Add common library module(libcxgb.ko) for
Chelsio drivers to remove duplicate code.
Code for iSCSI DDP Page Pod Manager is moved
from cxgb4.ko to libcxgb.ko. Earlier only cxgbit.ko
was using this code, now cxgb3i and cxgb4i will
also use common Page Pod manager code.
In future this module will ha
Add iSCSI DDP support in cxgb3i driver
using common iSCSI DDP Page Pod Manager.
Signed-off-by: Varun Prakash
---
drivers/scsi/cxgbi/cxgb3i/cxgb3i.c | 119 -
1 file changed, 118 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.c
b/dr
Hi,
This patch series adds common library module(libcxgb.ko)
for Chelsio drivers to remove duplicate code.
This series moves common iSCSI DDP Page Pod manager
code from cxgb4.ko to libcxgb.ko, earlier this code
was used by only cxgbit.ko now it is used by
three Chelsio iSCSI drivers cxgb3i, cxgb
On 07/08/2016 01:01 AM, Nicolas Dichtel wrote:
Those 300 routers will each have at least one namespace along with the dhcp
namespaces. Depending on the nature of the routers (Distributed versus
Centralized Virtual Routers - DVR vs CVR) and whether the routers are supposed
to be "HA" there can be
On Fri, Jul 8, 2016 at 9:56 AM, Hannes Frederic Sowa
wrote:
> On 08.07.2016 12:46, Alexander Duyck wrote:
>> On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni wrote:
>>> currently, UDP packets with zero checksum are not allowed to
>>> use udp offload's GRO. This patch admits such packets to
>>> GRO, if
On 07/08/2016 12:54 PM, Vishwanath Pai wrote:
> On 07/08/2016 12:37 PM, David Laight wrote:
>> If you think some users would still want 32bit limits, then you should
>> (probably) use a _64 suffix for the new functions.
>>
>> David
>
> I am proposing a new revision for hashlimit that supports
>-Original Message-
>From: Patrick McLean [mailto:patri...@gaikai.com]
>Sent: Friday, July 08, 2016 9:45 AM
>To: zhuyj
>Cc: Tantilov, Emil S ; Rustad, Mark D
>; netdev ; intel-wired-lan
>
>Subject: Re: [Intel-wired-lan] [PATCH] (resend) ixgbe: always initialize
>setup_fc
>
>How about just
On 08.07.2016 12:46, Alexander Duyck wrote:
> On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni wrote:
>> currently, UDP packets with zero checksum are not allowed to
>> use udp offload's GRO. This patch admits such packets to
>> GRO, if the related socket settings allow it: ipv6 packets
>> are not admi
On 07/08/2016 12:37 PM, David Laight wrote:
> If you think some users would still want 32bit limits, then you should
> (probably) use a _64 suffix for the new functions.
>
> David
I am proposing a new revision for hashlimit that supports a higher rate
along with a few other changes/fixes (i
On Fri, Jul 08, 2016 at 07:18:11AM -0700, Roland Dreier wrote:
> On Thu, Jul 7, 2016 at 4:14 PM, Jason Gunthorpe
> wrote:
> > We have neighbour_priv, and ndo_neigh_construct/destruct now ..
> >
> > A first blush that would seem to be enough to let ipoib store the AH
> > and other path information
On Fri, Jul 08, 2016 at 08:56:45AM +0200, Eric Dumazet wrote:
> On Thu, 2016-07-07 at 21:16 -0700, Alexei Starovoitov wrote:
>
> > I've tried this style of prefetching in the past for normal stack
> > and it didn't help at all.
>
> This is very nice, but my experience showed opposite numbers.
> S
On 16-07-08 09:07 AM, Jakub Kicinski wrote:
> On Fri, 8 Jul 2016 17:19:43 +0200, Jesper Dangaard Brouer wrote:
>> On Fri, 8 Jul 2016 14:44:53 +0100 Jakub Kicinski
>> wrote:
>>> On Thu, 7 Jul 2016 19:22:12 -0700, Alexei Starovoitov wrote:
> If the goal is to just separate XDP traffic from non-
On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni wrote:
> currently, UDP packets with zero checksum are not allowed to
> use udp offload's GRO. This patch admits such packets to
> GRO, if the related socket settings allow it: ipv6 packets
> are not admitted if the sockets don't have the no_check6_rx
>
How about just initializing it when the rest of the struct is
initialized? This is what is done for every other model.
On Fri, Jul 8, 2016 at 2:47 AM, zhuyj wrote:
> Sure. setup_fc should not be null. Emil, your patch can fix it well.
>
> On Fri, Jul 8, 2016 at 8:18 AM, Tantilov, Emil S
> wrote:
From: Vishwanath Pai
> Sent: 08 July 2016 00:34
> I am planning to add a revision 2 for the hashlimit xtables module to
> support higher packets per second rates. This patch renames all the
> functions and variables related to revision 1 by adding _v1 at the end of
> the names.
Sounds backwards.
I
From: Eric Dumazet
Yue Cao claims that current host rate limiting of challenge ACKS
(RFC 5961) could leak enough information to allow a patient attacker
to hijack TCP sessions. He will soon provide details in an academic
paper.
This patch increases the default limit from 100 to 1000, and adds
so
On Thu, Jul 7, 2016 at 8:58 AM, Paolo Abeni wrote:
> With udp tunnel offload in place, the kernel can do GRO for some udp tunnels
> at the ingress device level. Currently both the geneve and the vxlan drivers
> implement an additional GRO aggregation point via gro_cells.
> The latter takes effect
On 07/08/2016 05:38 PM, Eric Dumazet wrote:
> With IPv4, a server can typically absorb 10 Mpps SYN without major
> disruption on linux-4.6
Well, this particular server even survived >900 MBit/sec w/o any service
disruption at IPv4 ([1])
but yesterday with a much more less attack the IPv6 issue was
On Fri, Jul 08, 2016 at 05:13:49PM +0100, Wei Liu wrote:
> On Thu, Jul 07, 2016 at 01:58:18AM -0600, Jan Beulich wrote:
> > ... as being the simpler variant.
> >
> > Signed-off-by: Jan Beulich
>
> Acked-by: Wei Liu
Please ignore this, I acked v2 instead.
Only v2 is needed.
On Fri, Jul 08, 2016 at 06:28:58AM -0600, Jan Beulich wrote:
> For single items being collected this should be preferred as being more
> typesafe (as the compiler can check format string and to-be-written-to
> variable match) and more efficient (requiring one less parameter to be
> passed).
>
> Si
On Fri, 2016-07-08 at 11:55 -0400, Hannes Frederic Sowa wrote:
> Exactly, thus we are also only touching UDP tunneling protocols at the
> moment. Did you nack the removal of gro_cell support from the udp
> protocols or are you fine with it, given that we won't take away the
> functionality to spre
Hi Jon,
In Subject line, you mean add amac entries.
On 16-07-08 08:56 AM, Jon Mason wrote:
Add device tree entries for the ethernet devices present on the
Broadcom Northstar Plus SoCs
Signed-off-by: Jon Mason
---
arch/arm/boot/dts/bcm-nsp.dtsi | 18 ++
arch/arm/boot/dts/
On Thu, Jul 07, 2016 at 01:58:18AM -0600, Jan Beulich wrote:
> ... as being the simpler variant.
>
> Signed-off-by: Jan Beulich
Acked-by: Wei Liu
On Fri, 8 Jul 2016 17:19:43 +0200, Jesper Dangaard Brouer wrote:
> On Fri, 8 Jul 2016 14:44:53 +0100 Jakub Kicinski
> wrote:
> > On Thu, 7 Jul 2016 19:22:12 -0700, Alexei Starovoitov wrote:
> > > > If the goal is to just separate XDP traffic from non-XDP traffic
> > > > you could accomplish this
If socket filter truncates an udp packet below the length of UDP header
in udpv6_queue_rcv_skb() or udp_queue_rcv_skb(), it will trigger a
BUG_ON in skb_pull_rcsum(). This BUG_ON (and therefore a system crash if
kernel is configured that way) can be easily enforced by an unprivileged
user which was
This patch is about prefetching without being opportunistic.
The idea is only to start prefetching on packets that are marked as
ready/completed in the RX ring.
This is acheived by splitting the napi_poll call mlx4_en_process_rx_cq()
loop into two. The first loop extract completed CQEs and start
On Thu, Jul 7, 2016 at 7:08 PM, Jon Mason wrote:
> David Miller, Please consider including patches 1-5 in net-next
>
> Florian Fainelli, Please consider including patches 6 & 7 in
> devicetree/next
Oops. I didn't send out the 7th patch in this series. Sending out
shortly as 7/7.
Thanks,
Jon
Add device tree entries for the ethernet devices present on the
Broadcom Northstar Plus SoCs
Signed-off-by: Jon Mason
---
arch/arm/boot/dts/bcm-nsp.dtsi | 18 ++
arch/arm/boot/dts/bcm958625k.dts | 8
2 files changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/bc
On 08.07.2016 11:33, Eric Dumazet wrote:
> On Fri, 2016-07-08 at 11:12 -0400, Hannes Frederic Sowa wrote:
>> Hi Eric,
>>
>> On 07.07.2016 12:13, Eric Dumazet wrote:
>>> On Thu, 2016-07-07 at 17:58 +0200, Paolo Abeni wrote:
GRO is now handled entirely by the udp_offload layer and there is no n
On Fri, 2016-07-08 at 11:43 -0400, Hannes Frederic Sowa wrote:
> Exactly, I can very well imagine that the stack becomes unresponsive
> during DDoS, but after the DDoS I don't see a reason why services should
> come up like in IPv4.
If the service uses different listeners, one for IPV4, one (or m
On 08.07.2016 11:38, Eric Dumazet wrote:
> On Fri, 2016-07-08 at 11:28 -0400, Hannes Frederic Sowa wrote:
>> On 08.07.2016 10:14, Eric Dumazet wrote:
>>> On Fri, 2016-07-08 at 15:51 +0200, Toralf Förster wrote:
I do run a 4.6.3 hardened Gentoo kernel at a commodity i7 server. A
DDoS with
From: Colin Ian King
rc is not initialized so it can contain garbage if it is not
set by the call to bnxt_read_sfp_module_eeprom_info. Ensure
garbage is not returned by initializing rc to 0.
Signed-off-by: Colin Ian King
---
drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 2 +-
1 file chan
On Fri, 2016-07-08 at 16:34 +0200, Toralf Förster wrote:
> On 07/08/2016 04:14 PM, Eric Dumazet wrote:
> > Are you sure conntrack is needed at all ?
>
> Erm, I didn't mention conntrack - but yes, I do have in the firewall rules.
>
> It is my understanding that conntrack is best practise, right ?
On Fri, 2016-07-08 at 11:28 -0400, Hannes Frederic Sowa wrote:
> On 08.07.2016 10:14, Eric Dumazet wrote:
> > On Fri, 2016-07-08 at 15:51 +0200, Toralf Förster wrote:
> >> I do run a 4.6.3 hardened Gentoo kernel at a commodity i7 server. A
> >> DDoS with about 300 MBit/sec over 5 mins resulted an i
On 08.07.2016 10:14, Eric Dumazet wrote:
> On Fri, 2016-07-08 at 15:51 +0200, Toralf Förster wrote:
>> I do run a 4.6.3 hardened Gentoo kernel at a commodity i7 server. A
>> DDoS with about 300 MBit/sec over 5 mins resulted an issue for ipv6 at
>> that system.
>>
>> The IPv6 monitoring from my ISP
1 - 100 of 168 matches
Mail list logo