On Sat, 2015-05-30 at 01:52 -0400, John A. Sullivan III wrote:
> Argh! yet another obstacle from my ignorance. We are attempting ingress
> traffic shaping using IFB interfaces on traffic coming via GRE / IPSec.
> Filters and hash tables are working fine with plain GRE including
> stripping the hea
Argh! yet another obstacle from my ignorance. We are attempting ingress
traffic shaping using IFB interfaces on traffic coming via GRE / IPSec.
Filters and hash tables are working fine with plain GRE including
stripping the header. We even got the ematch filter working so that the
ESP packets are
On Fri, 2015-05-29 at 22:32 -0400, John A. Sullivan III wrote:
> Hello, all. I understand there is no direct way to negate a u32 match.
> I have a setup where I am redirecting all ingress traffic from the
> physical interface to an ifb interface with a u32 match u8 0 0 action
> mirred egress redir
On 05/29/2015 04:48 PM, Tom Herbert wrote:
Hi Josh,
Why did you need to move the resubmit label?
Grabbing nhoff out of the skb's cb didn't seem relevant anymore, unless
we're requiring the decapsulating code to update the control block
before it returns. Also, since we are returning nexthdr
Hello, all. I understand there is no direct way to negate a u32 match.
I have a setup where I am redirecting all ingress traffic from the
physical interface to an ifb interface with a u32 match u8 0 0 action
mirred egress redirect filter attached to :
I do not want to send ingress ESP packets
> From: Ivan Vecera [mailto:ivec...@redhat.com]
> Sent: Thursday, May 28, 2015 2:10 PM
>
> These patches fix several bugs found during device initialization debugging.
>
> Cc: Rasesh Mody
>
> Ivan Vecera (3):
> bna: fix firmware loading on big-endian machines
> bna: remove unreasonable iocp
> From: Thomas Jarosch [mailto:thomas.jaro...@intra2net.com]
> Sent: Wednesday, May 27, 2015 9:01 AM
> To: Brown, Aaron F
> Cc: Kirsher, Jeffrey T; 'Linux Netdev List'; Eric Dumazet; e1000-devel
> Subject: Re: RE: [bisected regression] e1000e: "Detected Hardware Unit
> Hang"
>
> Hi Aaron,
>
> On
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 5/29/15 2:23 PM, Daniel Borkmann wrote:
Besides others, move bpf_tail_call_proto to the remaining definitions
of other protos, improve comments a bit (i.e. remove some obvious ones,
where the code is already self-documenting, add objectives for others),
simplify bpf_prog_array_compatible() a b
On 5/29/15 2:10 AM, Daniel Borkmann wrote:
+static void __prog_put_rcu(struct rcu_head *rcu)
+{
+struct bpf_prog_aux *aux = container_of(rcu, struct bpf_prog_aux,
rcu);
+
+free_used_maps(aux);
+bpf_prog_free(aux->prog);
Not sure if it's worth it to move these two into a common help
On May 29, 2015, at 6:15 PM, Guenter Roeck li...@roeck-us.net wrote:
> On 05/29/2015 08:51 AM, Or Gerlitz wrote:
>> On Fri, May 29, 2015 at 6:38 PM, Vivien Didelot
>> wrote:
>>> Hi,
>>>
>>> - On May 29, 2015, at 11:24 AM, Or Gerlitz gerlitz...@gmail.com wrote:
>>>
On Fri, May 29, 2015 a
Scott,
On 05/28/2015 10:02 PM, Scott Feldman wrote:
On Thu, May 28, 2015 at 2:37 PM, Vivien Didelot
wrote:
This RFC is based on v4.1-rc3.
It is meant to get a glance to the commits responsible to implement the
necessary NDOs between DSA and the Marvell 88E6352 switch driver.
With this suppor
Hi Vivien,
On 05/28/2015 02:37 PM, Vivien Didelot wrote:
This commit implements the port_vlan_add, port_vlan_kill, and
port_bridge_setlink dsa_switch_driver functions to access the VTU, and
thus add support for adding, removing VLANs, and joining ports to them.
Signed-off-by: Vivien Didelot
On Fri, 2015-05-29 at 15:02 -0700, Stephen Hemminger wrote:
> Why not use strdupa? I handles arbitrary size?
I doubt this will please security guys.
RETURN VALUE
The alloca() function returns a pointer to the beginning of the
allocated space. If the allocation causes stack overflow, pro
On 05/29/2015 08:51 AM, Or Gerlitz wrote:
On Fri, May 29, 2015 at 6:38 PM, Vivien Didelot
wrote:
Hi,
- On May 29, 2015, at 11:24 AM, Or Gerlitz gerlitz...@gmail.com wrote:
On Fri, May 29, 2015 at 12:37 AM, Vivien Didelot
wrote:
@@ -854,7 +922,9 @@ int dsa_slave_create(struct dsa_switch
On Fri, 29 May 2015 21:09:54 +0300
Vadim Kochan wrote:
> From: Vadim Kochan
>
> Used 16 char array for cong alg name instead of malloc.
>
> Fixes: 8250bc9ff4e5 ("ss: Unify inet sockets output")
> Reported-by: Jose R. Guzman Mosqueda
> Signed-off-by: Vadim Kochan
> ---
> v2:
>Used 16 byte
Hi Josh,
Why did you need to move the resubmit label?
On Fri, May 29, 2015 at 2:43 PM, Josh Hunt wrote:
> On 05/29/2015 03:27 PM, Sergei Shtylyov wrote:
>>
>> Hello.
>>
>> On 05/29/2015 11:04 PM, Josh Hunt wrote:
>>
>>> I came across this problem while trying to use UDP encapsulation with
>>> I
On 05/29/2015 03:27 PM, Sergei Shtylyov wrote:
Hello.
On 05/29/2015 11:04 PM, Josh Hunt wrote:
I came across this problem while trying to use UDP encapsulation with
IPv6. The
change below fixes that, but it was not immediately apparent if there
are any
other protocols relying on this broken be
An application may deterministically attach the underlying transport for
a PF_RDS socket by invoking setsockopt(2) with the SO_RDS_TRANSPORT
option at the SOL_RDS level. The integer argument to setsockopt must be
one of the RDS_TRANS_* transport types, e.g., RDS_TRANS_TCP. The option
must be specif
The currently attached transport for a PF_RDS socket may be obtained
from user space by invoking getsockopt(2) using the SO_RDS_TRANSPORT
option at the SOL_RDS level. The integer optval returned will be one
of the RDS_TRANS_* constants defined in linux/rds.h.
Signed-off-by: Sowmini Varadhan
---
User space applications that desire to explicitly select the
underlying transport for a PF_RDS socket may do so by using the
SO_RDS_TRANSPORT socket option at the SOL_RDS level before bind().
The integer argument provided to the socket option would be one
of the RDS_TRANS_* values, e.g., RDS_TRANS_
Today the underlying transport (TCP or IB) for a PF_RDS socket is
implicitly selected based on the local address used to bind(2) the
PF_RDS socket. This results in some non-deterministic behavior when
there are un-numbered and IPoIB interfaces sharing the same IP address.
It also places the constra
As this is already exported from tracing side via commit d9847d310ab4
("tracing: Allow BPF programs to call bpf_ktime_get_ns()"), we might
as well want to move it to the core, so also networking users can make
use of it, e.g. to measure diffs for certain flows from ingress/egress.
Signed-off-by: D
Daniel Borkmann (2):
ebpf: allow bpf_ktime_get_ns_proto also for networking
ebpf: misc core cleanup
include/linux/bpf.h | 1 +
kernel/bpf/core.c| 73
kernel/bpf/helpers.c | 47 ---
kernel/trace/bpf_
Besides others, move bpf_tail_call_proto to the remaining definitions
of other protos, improve comments a bit (i.e. remove some obvious ones,
where the code is already self-documenting, add objectives for others),
simplify bpf_prog_array_compatible() a bit.
Signed-off-by: Daniel Borkmann
---
ker
Hello.
On 05/29/2015 11:04 PM, Josh Hunt wrote:
I came across this problem while trying to use UDP encapsulation with IPv6. The
change below fixes that, but it was not immediately apparent if there are any
other protocols relying on this broken behavior. FWIW the behavior below now
matches IPv4
> > > What it requires is that for each user port, you can configure what
> > > cpu port it should use. Marvell devices have this ability, and at a
> > > first look, it seems like SF2 does as well, but i will leave Florian
> > > to answer definitively.
> >
> > That's right, such configuration happ
I came across this problem while trying to use UDP encapsulation with IPv6. The
change below fixes that, but it was not immediately apparent if there are any
other protocols relying on this broken behavior. FWIW the behavior below now
matches IPv4.
Josh
v2: Actually sets nexthdr so we can use it
On Fri, May 29, 2015 at 12:58:12PM -0700, Florian Fainelli wrote:
> On 29/05/15 11:59, Andrew Lunn wrote:
> > On Fri, May 29, 2015 at 11:49:54AM -0700, Mathieu Olivari wrote:
> >> On Fri, May 29, 2015 at 04:00:01AM +0200, Andrew Lunn wrote:
> >>> FYI:
> >>>
> >>> I have patches which allow DSA to u
On 05/29/2015 02:56 PM, Josh Hunt wrote:
I came across this problem while trying to use UDP encapsulation with IPv6. The
change below fixes that, but it was not immediately apparent if there are any
other protocols relying on this broken behavior. FWIW the behavior below now
matches IPv4.
Josh
-
On 29/05/15 11:59, Andrew Lunn wrote:
> On Fri, May 29, 2015 at 11:49:54AM -0700, Mathieu Olivari wrote:
>> On Fri, May 29, 2015 at 04:00:01AM +0200, Andrew Lunn wrote:
>>> FYI:
>>>
>>> I have patches which allow DSA to use two cpu interfaces. Seems to
>>> work on my DIR665 with a Marvell Switch.
>
I came across this problem while trying to use UDP encapsulation with IPv6. The
change below fixes that, but it was not immediately apparent if there are any
other protocols relying on this broken behavior. FWIW the behavior below now
matches IPv4.
Josh
---
UDP encapsulation is broken on IPv6 bec
Hi Neal,
I will be more happy to test the patch. Please send it my way.
Thanks,
Grant
> On May 29, 2015, at 12:46 PM, Neal Cardwell wrote:
>
> On Fri, May 29, 2015 at 3:21 PM, Grant Zhang wrote:
>> We have multiple machines running into the following trace repeatedly. The
>> trace shows up
The for loop should only probe up to G[i]bit rates, so that we
end up with T[i]bit as the last max units[] slot for snprintf(3),
and not possibly an invalid pointer in case rate is multiple of
kilo.
Fixes: 8cecdc283743 ("tc: more user friendly rates")
Reported-by: Jose R. Guzman Mosqueda
Signed-o
On Fri, May 29, 2015 at 3:21 PM, Grant Zhang wrote:
> We have multiple machines running into the following trace repeatedly. The
> trace shows up every couple of seconds on our production machines.
>
...
> May 29 18:14:04 cache-fra1230 kernel:[3080455.796188] []
> tcp_fragment+0x2e4/0x2f0
> May
We have multiple machines running into the following trace repeatedly. The
trace shows up every couple of seconds on our production machines.
May 29 18:14:04 cache-fra1230 kernel:[3080455.796143] WARNING: CPU: 7 PID: 0 at
net/ipv4/tcp_output.c:1082 tcp_fragment+0x2e4/0x2f0()
May 29 18:14:04 cach
Some boards have two CPU interfaces connected to the switch, e.g. WiFi
access points, with 1 port labeled WAN, 4 ports labeled lan1-lan4, and
two port connected to the SoC.
This patch extends DSA to allows both CPU ports to be used. The "cpu"
node in the DSA tree can now have a phandle to the host
The Dlink DIR665 has two host Ethernet interfaces connected to the
switch. Now that the DSA core and mv88e6171 driver supports multiple
CPU ports, enable the second interface.
Signed-off-by: Andrew Lunn
---
arch/arm/boot/dts/kirkwood-dir665.dts | 22 --
1 file changed, 20 ins
This is an RFC set of patches to support multiple CPU ports
in a DSA setup.
In the kirkwood DIR665 example, host eth1 is used for traffic to/from
ports lan4, lan2 and wan, where as all other ports use eth0.
RFC because it needs more testing and it would be nice to know if the
basic idea is applic
Move the DT probing of a switch port into a function of its own, since
it is about to get more complex. Add better error handling as well.
Signed-off-by: Andrew Lunn
---
net/dsa/dsa.c | 77 ++-
1 file changed, 44 insertions(+), 33 deletions
On Fri, May 29, 2015 at 11:49:54AM -0700, Mathieu Olivari wrote:
> On Fri, May 29, 2015 at 04:00:01AM +0200, Andrew Lunn wrote:
> > FYI:
> >
> > I have patches which allow DSA to use two cpu interfaces. Seems to
> > work on my DIR665 with a Marvell Switch.
> >
> > I will post the patches as an RF
On Fri, May 29, 2015 at 12:31:57PM -0400, Nicholas Krause wrote:
> This removes the function, cpsw_ale_flush and its prototype from the
> files cpsw_ale.c and cpsw_ale.h due to having no more callers. Finally
> we also remove the functions, cpsw_ale_set_vlan_entry,
> cpsw_ale_flush_ucast and cpsw_
On Fri, May 29, 2015 at 04:00:01AM +0200, Andrew Lunn wrote:
> FYI:
>
> I have patches which allow DSA to use two cpu interfaces. Seems to
> work on my DIR665 with a Marvell Switch.
>
> I will post the patches as an RFC.
>
> Andrew
Does it require the switch CPU ports to support LAG or is it
On Fri, May 29, 2015 at 10:29:46AM -0700, Florian Fainelli wrote:
> While shuffling some code around, dsa_switch_setup_one() was introduced,
> and it was modified to return either an error code using ERR_PTR() or a
> NULL pointer when running out of memory or failing to setup a switch.
>
> This is
From: Steffen Klassert
We currently rely on the PMTU discovery of xfrm.
However if a packet is localy sent, the PMTU mechanism
of xfrm tries to to local socket notification what
might not work for applications like ping that don't
check for this. So add pmtu handling to vti6_xmit to
report MTU ch
On 05/29/2015 07:47 PM, Neal Cardwell wrote:
Linux 3.17 and earlier are explicitly engineered so that if the app
doesn't specifically request a CC module on a listener before the SYN
arrives, then the child gets the system default CC when the connection
is established. See tcp_init_congestion_con
From: Vadim Kochan
Used 16 char array for cong alg name instead of malloc.
Fixes: 8250bc9ff4e5 ("ss: Unify inet sockets output")
Reported-by: Jose R. Guzman Mosqueda
Signed-off-by: Vadim Kochan
---
v2:
Used 16 byte array for cong alg name instead of malloc
suggested by Eric Dumazet
On Fri, May 29, 2015 at 10:36:49AM -0700, Mathieu Olivari wrote:
> Alternatively, we could have something similar to what happens for the phy
> in the wireless subsystems. Wireless PHYs are not registered as net_device
> but they can still be listed, queried or configured through netlink.
It is a
On Fri, May 29, 2015 at 9:42 AM, Florian Fainelli wrote:
> Currently, bcm_sysport_desc_rx() calls bcm_sysport_rx_refill() at the end of
> Rx
> packet processing loop, after the current Rx packet has already been passed to
> napi_gro_receive(). However, bcm_sysport_rx_refill() might fail to alloca
Linux 3.17 and earlier are explicitly engineered so that if the app
doesn't specifically request a CC module on a listener before the SYN
arrives, then the child gets the system default CC when the connection
is established. See tcp_init_congestion_control() in 3.17 or earlier,
which says "if no ch
On Fri, May 29, 2015 at 05:24:53PM +0100, Ian Campbell wrote:
[...]
> if (be->vif != NULL)
> return 0;
> @@ -417,12 +409,23 @@ static int backend_create_xenvif(struct backend_info
> *be)
> return (err < 0) ? err : -EINVAL;
> }
>
> + script = xenbus_rea
Alternatively, we could have something similar to what happens for the phy
in the wireless subsystems. Wireless PHYs are not registered as net_device
but they can still be listed, queried or configured through netlink.
Just thinking out loud here.
Thanks,
Mathieu
-Original Message-
From:
While shuffling some code around, dsa_switch_setup_one() was introduced,
and it was modified to return either an error code using ERR_PTR() or a
NULL pointer when running out of memory or failing to setup a switch.
This is a problem for its caler: dsa_switch_setup() which uses IS_ERR()
and expects
On Fri, May 29, 2015 at 11:46 AM, Casey Leedom wrote:
> Thanks Bjorn and no issues at all about the delay -- I definitely
> understand how
> busy we all are.
>
> I'll go ahead and submit a PCI Quirk. As part of this, would you like me to
> also commit a new PCI-E routine to find the Root Com
On 05/28/2015 12:15 PM, Alexander Duyck wrote:
On 05/28/2015 01:40 AM, Steffen Klassert wrote:
On Thu, May 28, 2015 at 12:18:51AM -0700, Alexander Duyck wrote:
On 05/27/2015 10:36 PM, Steffen Klassert wrote:
On Wed, May 27, 2015 at 10:40:32AM -0700, Alexander Duyck wrote:
This change makes it
Hi David,
These patches are highly inspired by changes from Petri on bcmgenet, last patch
is a misc fix that I had pending for a while, but is not a candidate for 'net'
at this point.
Changes in v2:
- added Petri's reviewed-by tag for patches 1 and 2
- reworked patch 2 to remove a now stale comm
On Fri, May 29, 2015 at 09:17:26AM -0400, Neil Horman wrote:
> On Thu, May 28, 2015 at 11:46:29AM -0300, Marcelo Ricardo Leitner wrote:
> > On Thu, May 28, 2015 at 10:27:32AM -0300, Marcelo Ricardo Leitner wrote:
> > > On Thu, May 28, 2015 at 08:17:27AM -0300, Marcelo Ricardo Leitner wrote:
> > > >
There is a 1:1 mapping between the software maintained control block in
priv->rx_cbs and the buffer address in priv->rx_bds, such that there is
no need to keep computing the buffer address when refiling a control
block.
Reviewed-by: Petri Gynther
Signed-off-by: Florian Fainelli
---
drivers/net/
Currently, bcm_sysport_desc_rx() calls bcm_sysport_rx_refill() at the end of Rx
packet processing loop, after the current Rx packet has already been passed to
napi_gro_receive(). However, bcm_sysport_rx_refill() might fail to allocate a
new
Rx skb, thus leaving a hole on the Rx queue where no vali
Occasionnaly we may get oversized packets from the hardware which exceed
the nomimal 2KiB buffer size we allocate SKBs with. Add an early check
which drops the packet to avoid invoking skb_over_panic() and move on to
processing the next packet.
Reviewed-by: Petri Gynther
Signed-off-by: Florian Fa
On 05/29/2015 06:17 PM, Guzman Mosqueda, Jose R wrote:
Hi Daniel and Vadim
Thanks for your prompt response and for the patch.
Also, what about the other one? Do you think it is an issue or not?
" File: tc/tc_util.c
Function: void print_rate(char *buf, int len, __u64 rate)
Line: ~264
In the ca
Thanks Bjorn and no issues at all about the delay -- I definitely understand
how
busy we all are.
I'll go ahead and submit a PCI Quirk. As part of this, would you like me to
also commit a new PCI-E routine to find the Root Complex Port for a given
PCI Device? It seem like it might prove use
When we come to tear things down in netback_remove() and generate the
uevent it is possible that the xenstore directory has already been
removed (details below).
In such cases netback_uevent() won't be able to read the hotplug
script and will write a xenstore error node.
A recent change to the hy
drivers/net/xen-netback/netback.c: In function ‘xenvif_tx_build_gops’:
drivers/net/xen-netback/netback.c:1253:8: warning: format ‘%lu’ expects
argument of type ‘long unsigned int’, but argument 5 has type ‘int’ [-Wformat=]
(txreq.offset&~PAGE_MASK) + txreq.size);
^
txreq.offset an
On 29/05/15 17:24, Ian Campbell wrote:
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -235,6 +235,7 @@ static int netback_remove(struct xenbus_device *dev)
> kobject_uevent(&dev->dev.kobj, KOBJ_OFFLINE);
> xen_unregister_watchers(b
On Fri, May 29, 2015 at 05:22:04PM +0100, Ian Campbell wrote:
> drivers/net/xen-netback/netback.c: In function ‘xenvif_tx_build_gops’:
> drivers/net/xen-netback/netback.c:1253:8: warning: format ‘%lu’ expects
> argument of type ‘long unsigned int’, but argument 5 has type ‘int’
> [-Wformat=]
>
Hi Casey,
Sorry, this one slipped through and I forgot to respond earlier.
On Thu, May 07, 2015 at 11:31:58PM +, Casey Leedom wrote:
> | From: Bjorn Helgaas [bhelg...@google.com]
> | Sent: Thursday, May 07, 2015 4:04 PM
> |
> | There are a lot of fixups in drivers/pci/quirks.c. For things t
Alexander Larsson writes:
> Now that I'm using a non-privileged user namespace for my desktop
> sandboxing system all kind of network status things are breaking. The
> reason for this is that they use netlink to enumerated interfaces, and
> to verify that the replies are from the kernel (apparent
Hi Daniel and Vadim
Thanks for your prompt response and for the patch.
Also, what about the other one? Do you think it is an issue or not?
" File: tc/tc_util.c
Function: void print_rate(char *buf, int len, __u64 rate)
Line: ~264
In the case that user inputs a high value for rate, the "for" loop
Hi Eric,
On Fri, May 29, 2015 at 08:52:11AM -0700, Eric Dumazet wrote:
> On Fri, 2015-05-29 at 08:12 -0700, Stephen Hemminger wrote:
> > I think 2.6.32 is so old no one will care.
A few will still, but at least we must ensure the old guy finishes
his days nicely :-)
(...)
> I guess a backport we
On Fri, 2015-05-29 at 08:12 -0700, Stephen Hemminger wrote:
> I think 2.6.32 is so old no one will care.
>
> Begin forwarded message:
>
> Date: Fri, 29 May 2015 09:12:45 +
> From: "bugzilla-dae...@bugzilla.kernel.org"
>
> To: "shemmin...@linux-foundation.org"
> Subject: [Bug 99161] New: 2.
On Fri, May 29, 2015 at 6:38 PM, Vivien Didelot
wrote:
> Hi,
>
> - On May 29, 2015, at 11:24 AM, Or Gerlitz gerlitz...@gmail.com wrote:
>
>> On Fri, May 29, 2015 at 12:37 AM, Vivien Didelot
>> wrote:
>>> @@ -854,7 +922,9 @@ int dsa_slave_create(struct dsa_switch *ds, struct
>>> device
>>> *p
Hi Scott,
On May 29, 2015, at 1:02 AM, Scott Feldman sfel...@gmail.com wrote:
> On Thu, May 28, 2015 at 2:37 PM, Vivien Didelot
> wrote:
>> This RFC is based on v4.1-rc3.
>>
>> It is meant to get a glance to the commits responsible to implement the
>> necessary NDOs between DSA and the Marvell 8
On Fri, May 29, 2015 at 12:50 AM, Jiri Pirko wrote:
> Thu, May 21, 2015 at 07:46:54AM CEST, sfel...@gmail.com wrote:
>>On Tue, May 19, 2015 at 1:28 PM, David Miller wrote:
>>> From: Andy Gospodarek
>>> Date: Tue, 19 May 2015 15:47:32 -0400
>>>
Are you actually saying that if users complain
Hi,
- On May 29, 2015, at 11:24 AM, Or Gerlitz gerlitz...@gmail.com wrote:
> On Fri, May 29, 2015 at 12:37 AM, Vivien Didelot
> wrote:
>> @@ -854,7 +922,9 @@ int dsa_slave_create(struct dsa_switch *ds, struct device
>> *parent,
>> if (slave_dev == NULL)
>> return -ENO
Fri, May 29, 2015 at 05:12:35PM CEST, sfel...@gmail.com wrote:
>On Thu, May 28, 2015 at 2:42 AM, Jiri Pirko wrote:
>> Mon, May 18, 2015 at 10:19:16PM CEST, da...@davemloft.net wrote:
>>>From: Roopa Prabhu
>>>Date: Sun, 17 May 2015 16:42:05 -0700
>>>
On most systems where you can offload rout
Hi Takashi,
On Fri, 29 May 2015 14:43:14 +0200 Takashi Iwai wrote:
>
> For the sound bits,
> Acked-by: Takashi Iwai
Thanks, noted.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp0duKaM_eov.pgp
Description: OpenPGP digital signature
On Fri, May 29, 2015 at 12:37 AM, Vivien Didelot
wrote:
> @@ -854,7 +922,9 @@ int dsa_slave_create(struct dsa_switch *ds, struct device
> *parent,
> if (slave_dev == NULL)
> return -ENOMEM;
>
> - slave_dev->features = master->vlan_features;
> + slave_dev->featu
On Fri, 2015-05-29 at 15:53 +0300, Vadim Kochan wrote:
> Thanks!
>
> Should I put you in "From" tag or in "Signed-off-by" ?
> Or your diff might be used from this email thread ?
Don't worry, just submit the patch officially on your own ;)
Thanks.
--
To unsubscribe from this list: send the lin
On Thu, May 28, 2015 at 2:42 AM, Jiri Pirko wrote:
> Mon, May 18, 2015 at 10:19:16PM CEST, da...@davemloft.net wrote:
>>From: Roopa Prabhu
>>Date: Sun, 17 May 2015 16:42:05 -0700
>>
>>> On most systems where you can offload routes to hardware,
>>> doing routing in software is not an option (the c
I think 2.6.32 is so old no one will care.
Begin forwarded message:
Date: Fri, 29 May 2015 09:12:45 +
From: "bugzilla-dae...@bugzilla.kernel.org"
To: "shemmin...@linux-foundation.org"
Subject: [Bug 99161] New: 2.6.32.66 PPC Oops in tcp_send_fin
https://bugzilla.kernel.org/show_bug.cgi?id
On 05/29/2015 09:23 AM, nick wrote:
> Greetings All,
> I am wondering if anything is still using the Davicom DM9000 driver recently
> as the code base states its
> from the late 1990s. Furthermore I see no reason to keep it around if
> something recent i.e. last 10 years
> is using it that is ba
On 29 May 2015, at 08:53, Yuzhou (C) wrote:
> Hi,
>
> About rx zerocopy, I have a question:
>
> If some application make a socket, then listen and accept, the client
> sends packets to it, but it doesn't recv from this socket right now, all
> persistent grant page would be in used
On 15/05/28 (木) 21:02, Eric Dumazet wrote:
On Thu, 2015-05-28 at 20:17 +0900, Toshiaki Makita wrote:
Currently packets with non-hardware-accelerated vlan cannot be handled
by GRO. This causes low performance for 802.1ad and stacked vlan, as their
vlan tags are currently not stripped by hardware.
On Thu, May 28, 2015 at 11:46:29AM -0300, Marcelo Ricardo Leitner wrote:
> On Thu, May 28, 2015 at 10:27:32AM -0300, Marcelo Ricardo Leitner wrote:
> > On Thu, May 28, 2015 at 08:17:27AM -0300, Marcelo Ricardo Leitner wrote:
> > > On Thu, May 28, 2015 at 06:15:11AM -0400, Neil Horman wrote:
> > > >
Kernel commit 04fd61ab36ec ("bpf: allow bpf programs to tail-call other
bpf programs") added support for tail calls, this patch here adds tc
front end parts for the object parser to prepopulate a given eBPF prog
array before the root prog is pushed down for classifier creation. The
prepopulation wo
On 29/05/15 11:48, David Laight wrote:
> From: Shradha Shah
>> Sent: 29 May 2015 11:01
>> On every adapter there will be one primary PF per adaptor and
>> one link control PF per port.
> ...
>> +return sprintf(buf, "%d\n",
>> + ((efx->mcdi->fn_flags) &
>> +
On Fri, May 29, 2015 at 04:04:05AM -0700, Eric Dumazet wrote:
> On Fri, 2015-05-29 at 13:30 +0300, Vadim Kochan wrote:
> > From: Vadim Kochan
> >
> > Use strdup instead of malloc, and get rid of bad strcpy.
> >
> > Signed-off-by: Vadim Kochan
> > ---
> > misc/ss.c | 3 +--
> > 1 file changed,
At Fri, 29 May 2015 19:18:47 +1000,
Stephen Rothwell wrote:
>
> Nothing in asm/io.h uses anything from vmalloc.h, so remove the include
> and fix up the build problems in an allmodconfig (64 bit and 32 bit)
> build.
>
> This may be the place where x86 builds get vmalloc.h implicitly included
> an
Hi Ingo,
On Fri, 29 May 2015 11:21:05 +0200 Ingo Molnar wrote:
>
> Good idea.
>
> Acked-by: Ingo Molnar
Thanks.
> Please also test x86 allnoconfig and defconfig 32/64, that tends to unearth
> the
> remaining places. People doing randconfig testing will find the rest.
Good idea. the allnoc
From: Eric Dumazet
ss currently dumps IPv4 sockets, then IPv6 sockets from the kernel,
even if -4 or -6 option was given. Filtering in user space then has to
drop all sockets of wrong family. Such a waste of time...
Before :
$ time ss -tn -4 | wc -l
251659
real0m1.241s
user0m0.423s
sys
From: Eric Dumazet
Lets implement a full cache with proper hash table, memory got cheaper
these days.
Before :
$ time ss -t | wc -l
529678
real0m22.708s
user0m19.591s
sys 0m2.969s
After :
$ time ss -t | wc -l
528291
real0m5.078s
user0m4.099s
sys 0m0.985s
Signed-of
From: Daniel Pieczko
When Rx packet data must be dropped, all the buffers
associated with that Rx packet must be freed. Extend
and rename efx_free_rx_buffer() to efx_free_rx_buffers()
and loop through all the fragments.
By doing so this patch fixes a possible memory leak.
Signed-off-by: Shradha
Hi Dave,
It's been a while since I sent anything for -next, but with the merge
window getting closer I wanted to send a few more things, mostly fixes.
Of course I expect that tomorrow somebody will send an important fix,
but hey :-)
johannes
The following changes since commit 658358cec93a713061
On 05/29/2015 01:04 PM, Eric Dumazet wrote:
...
I doubt TCP_CA_NAME_MAX will ever change in the kernel : 16 bytes.
Its typically "cubic" and less than 8 bytes.
Using 8 bytes to point to a malloc(8) is a waste.
Please remove the memory allocation, or store the pointer, since
tcp_show_info() doe
Hi Vadim,
On 05/29/2015 12:30 PM, Vadim Kochan wrote:
From: Vadim Kochan
Use strdup instead of malloc, and get rid of bad strcpy.
Signed-off-by: Vadim Kochan
Please also Cc the reporter (done here), and add a:
Fixes: 8250bc9ff4e5 ("ss: Unify inet sockets output")
Reported-by: Jose R. Guzm
On Fri, 2015-05-29 at 13:30 +0300, Vadim Kochan wrote:
> From: Vadim Kochan
>
> Use strdup instead of malloc, and get rid of bad strcpy.
>
> Signed-off-by: Vadim Kochan
> ---
> misc/ss.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/misc/ss.c b/misc/ss.c
> index 3
From: Shradha Shah
> Sent: 29 May 2015 11:01
> On every adapter there will be one primary PF per adaptor and
> one link control PF per port.
...
> + return sprintf(buf, "%d\n",
> +((efx->mcdi->fn_flags) &
> + (1 << MC_CMD_DRV_ATTACH_EXT_OUT_FLAG_LINKCTRL
>>> On 29.05.15 at 12:39, wrote:
> On Fri, May 29, 2015 at 11:34:07AM +0100, Jan Beulich wrote:
>> >>> On 11.05.15 at 19:25, wrote:
>> >>
>> >> Please CC the maintainers of the driver. You can get that from
>> >> 'scripts/get_maintainer.pl'
>> >>
>> >> I've done that for you.
>> >
>> > Thanks
On Thu, May 28, 2015 at 10:41 PM, Andrey Korolyov wrote:
> Hi,
>
> I am currently playing with SYNPROXY target to optimize SYN filtering
> performance and by occasion found that TCP SYN packets containing port
> 0 can result in a soft lockup when conntrack is enabled just by
> itself, given high p
1 - 100 of 144 matches
Mail list logo
