Hi John,
On Thursday 19 May 2016 06:50:56, John Crispin wrote:
> On 18/05/2016 18:24, Florian Fainelli wrote:
> > CC'ing Andrew, John,
>
> also CC'ing Matthias and Hauke. we have had a driver in OpenWrt/LEDE for
> several years that seems a little more complete than this one.
>
> https://git.led
On 16-05-18 20:40:51, Heinrich Schuchardt wrote:
> If !count is true, count < 4 is also true.
Yep, you're right. However, gcc optimizes away the first condition. What you
really got me to think about is whether 4 is the right number. I guess i shall
refer to the HW documentation.
> Hi,
>
> Please consider applying this to `linux-firmware'.
>
> Thanks,
> Yuval
I don't like to nag [and surely not so early after sending this], but do
you have an ETA for when you're going to flush the linux-firmware pipe?
[Asking as last time due to the holidays it took ~3 weeks]
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, May 19, 2016 12:13
> To: Dexuan Cui
> Cc: KY Srinivasan ; o...@aepfle.de;
> gre...@linuxfoundation.org; jasow...@redhat.com; linux-
> ker...@vger.kernel.org; j...@perches.com; netdev@vger.kernel.org;
> a...@canonical.com; de...@li
We used to check dev->reg_state against NETREG_REGISTERED after each
time we are woke up. But after commit 9e641bdcfa4e ("net-tun:
restructure tun_do_read for better sleep/wakeup efficiency"), it uses
skb_recv_datagram() which does not check dev->reg_state. This will
result if we delete a tun/tap d
On 2016年05月18日 21:01, Eric Dumazet wrote:
On Wed, 2016-05-18 at 18:58 +0800, Jason Wang wrote:
We used to check dev->reg_state against NETREG_REGISTERED after each
time we are woke up. But after commit 9e641bdcfa4e ("net-tun:
restructure tun_do_read for better sleep/wakeup efficiency"), it use
Hi,
On 18/05/2016 18:24, Florian Fainelli wrote:
> CC'ing Andrew, John,
>
also CC'ing Matthias and Hauke. we have had a driver in OpenWrt/LEDE for
several years that seems a little more complete than this one.
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/lantiq/patches-4.4/0
On Wed, 2016-05-18 at 22:05 -0600, David Ahern wrote:
> You think it is ok to send a request to the kernel, the kernel says "I
> can't do it" and the command says nothing to the user? That is current
> behavior. How on Earth is that acceptable?
I don't know. Tell me what is acceptable on a 'dum
I'm travelling and very busy with the merge window. So sorry I won't be able
to think about this for some time.
From: Jeff Kirsher
Date: Wed, 18 May 2016 14:27:58 -0700
> On Wed, 2016-05-18 at 10:44 -0700, Alexander Duyck wrote:
>> This patch series is meant to be applied after:
>> [PATCH v7 net-next 00/16] ipv6: Enable GUEoIPv6 and more fixes for v6
>> tunneling
>>
>> The first patch addresses an issue w
From: Linus Torvalds
Date: Wed, 18 May 2016 11:45:06 -0700
> David, do you happen to recall that merge conflict? I think you must
> have removed that "skb_info" variable declaration and initialization
> manually (due to the "unused variable" warning, which in turn was due
> to the incorrect merge
On 5/18/16 9:47 PM, Eric Dumazet wrote:
On Wed, 2016-05-18 at 21:02 -0600, David Ahern wrote:
On 5/18/16 6:55 PM, Lorenzo Colitti wrote:
On Wed, May 18, 2016 at 3:35 AM, wrote:
Would it be acceptable to have a separate column which displays the result of
the sock destroy operation per socket
From: Jiri Pirko
Date: Wed, 18 May 2016 14:40:50 +0200
> This patch, commit b555cf4a50c17a9714715a2d7c8574dca1a7b356 ("mlxsw: spectrum:
> Reduce number of supported 802.1D bridges") reduced the resources the
> device allocates during init. Newer firmware versions now force a hard
> limit on these
On Wed, 2016-05-18 at 21:02 -0600, David Ahern wrote:
> On 5/18/16 6:55 PM, Lorenzo Colitti wrote:
> > On Wed, May 18, 2016 at 3:35 AM, wrote:
> >> Would it be acceptable to have a separate column which displays the result
> >> of the sock destroy operation per socket.
> >> State... Killed
>
On 5/18/16 6:55 PM, Lorenzo Colitti wrote:
On Wed, May 18, 2016 at 3:35 AM, wrote:
Would it be acceptable to have a separate column which displays the result of
the sock destroy operation per socket.
State... Killed
ESTAB Y
TIME_WAIT N
Fine by me, but... what problem are we t
On Thu, May 19, 2016 at 12:59:09AM +, Dexuan Cui wrote:
> > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
> > Behalf
> > Of Dexuan Cui
> > Sent: Tuesday, May 17, 2016 10:46
> > To: David Miller
> > Cc: o...@aepfle.de; gre...@linuxfoundation.org; jasow...@redhat.com;
>
> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf
> Of Dexuan Cui
> Sent: Tuesday, May 17, 2016 10:46
> To: David Miller
> Cc: o...@aepfle.de; gre...@linuxfoundation.org; jasow...@redhat.com;
> linux-ker...@vger.kernel.org; j...@perches.com; netdev@vger.kernel.org;
>
On Wed, May 18, 2016 at 3:35 AM, wrote:
> Would it be acceptable to have a separate column which displays the result of
> the sock destroy operation per socket.
> State... Killed
> ESTAB Y
> TIME_WAIT N
Fine by me, but... what problem are we trying to address? People who
compile
The sk_err and sk_err_soft fields are positive errno values and
userspace applications rely on this when using getsockopt(SO_ERROR).
ATM code places an -errno into sk_err_soft in sigd_send() and returns it
from svc_addparty()/svc_dropparty().
Although I am not familiar with ATM code I came to thi
On Wed, 2016-05-18 at 16:19 -0700, Alexander Duyck wrote:
> On Wed, May 18, 2016 at 2:27 PM, Jeff Kirsher
> wrote:
> > On Wed, 2016-05-18 at 10:44 -0700, Alexander Duyck wrote:
> >> This patch series is meant to be applied after:
> >> [PATCH v7 net-next 00/16] ipv6: Enable GUEoIPv6 and more fixes
On Wed, May 18, 2016 at 2:27 PM, Jeff Kirsher
wrote:
> On Wed, 2016-05-18 at 10:44 -0700, Alexander Duyck wrote:
>> This patch series is meant to be applied after:
>> [PATCH v7 net-next 00/16] ipv6: Enable GUEoIPv6 and more fixes for v6
>> tunneling
>>
>> The first patch addresses an issue we alre
Lino Sanfilippo :
[...]
> what about the (only compile tested) code below?
I may have misunderstood some parts but it nonetheless seems broken.
> The smp_wmb() in tx function combined with the smp_rmb() in tx_clean ensures
> that the CPU running tx_clean sees consistent values for info, data and
On Wed, 2016-05-18 at 09:06 -0700, Tom Herbert wrote:
> This patch defines two new GSO definitions SKB_GSO_IPXIP4 and
> SKB_GSO_IPXIP6 along with corresponding NETIF_F_GSO_IPXIP4 and
> NETIF_F_GSO_IPXIP6. These are used to described IP in IP
> tunnel and what the outer protocol is. The inner protoc
On Wed, 2016-05-18 at 15:48 -0500, Mike Christie wrote:
> Reviewed and tested. Thanks
>
> Acked-by: Mike Christie
Excellent, thanks Mike !
On Wed, 2016-05-18 at 17:09 -0400, Neil Horman wrote:
> Oh, my bad, I misread what he was saying. Yeah, thats the way to go.
Please submit a v2 ;)
Thanks
On Tue, 2016-05-17 at 15:03 -0400, Jarod Wilson wrote:
> I've got a bug report about an e1000e interface, where a vlan interface
> is
> set up on top of it:
>
> $ ip link add link ens1f0 name ens1f0.99 type vlan id 99
> $ ip link set ens1f0 up
> $ ip link set ens1f0.99 up
> $ ip addr add 192.168.9
Alexander Aring wrote:
> What I did in the patch series to store short address in neighbour
> private data, which makes everything 802.15.4 6lowpan specific.
FYI: there are a whole family of network types which have multiple
addresses (long/short). This includes:
1) BTLE - RFC 7668 IPv6
On Wed, 2016-05-18 at 10:44 -0700, Alexander Duyck wrote:
> This patch series is meant to be applied after:
> [PATCH v7 net-next 00/16] ipv6: Enable GUEoIPv6 and more fixes for v6
> tunneling
>
> The first patch addresses an issue we already resolved in the GREv4 and
> is
> now present in GREv6 wi
On Wed, May 18, 2016 at 07:17:48AM -0700, Eric Dumazet wrote:
> On Wed, 2016-05-18 at 15:28 +0200, Hannes Frederic Sowa wrote:
>
> > I don't consider this a big thing, I just mentioned that we probably
> > shouldn't use prandom_u32 if the value somehow could leak to user space
> > and should be us
On Wed, May 18, 2016 at 01:48:15PM -0700, Alexander Duyck wrote:
> On Wed, May 18, 2016 at 12:29 PM, Neil Horman wrote:
> > On Wed, May 18, 2016 at 10:57:21AM -0700, Alexander Duyck wrote:
> >> On Wed, May 18, 2016 at 9:01 AM, Eric Dumazet
> >> wrote:
> >> > On Wed, 2016-05-18 at 11:25 -0400, Ne
On 05/17/2016 07:44 PM, Eric Dumazet wrote:
> iscsi_sw_tcp_data_ready() and iscsi_sw_tcp_state_change() were
> using read_lock(&sk->sk_callback_lock) which is fine if caller
> disabled BH.
>
> TCP stack no longer has this requirement and can run from
> process context.
>
> Use read_lock_bh() vari
On Wed, May 18, 2016 at 12:29 PM, Neil Horman wrote:
> On Wed, May 18, 2016 at 10:57:21AM -0700, Alexander Duyck wrote:
>> On Wed, May 18, 2016 at 9:01 AM, Eric Dumazet wrote:
>> > On Wed, 2016-05-18 at 11:25 -0400, Neil Horman wrote:
>> >> Noticed an allocation failure in a network driver the ot
On 18.05.2016 22:43, Daniel Borkmann wrote:
> On 05/18/2016 04:56 PM, Eric W. Biederman wrote:
>> Hannes Frederic Sowa writes:
>>> On 18.05.2016 01:12, Eric W. Biederman wrote:
While reviewing the filesystems that set FS_USERNS_MOUNT I spotted the
bpf filesystem. Looking at the cod
On 05/18/2016 04:56 PM, Eric W. Biederman wrote:
Hannes Frederic Sowa writes:
On 18.05.2016 01:12, Eric W. Biederman wrote:
While reviewing the filesystems that set FS_USERNS_MOUNT I spotted the
bpf filesystem. Looking at the code I saw a broken usage of mount_ns
with current->nsproxy->mnt_n
On 18.05.2016 02:01, Francois Romieu wrote:
> The smp_wmb() and wmb() could be made side-by-side once *info is
> updated but I don't see the adequate idiom to improve the smp_wmb + wmb
> combo. :o/
>
>> And the wmb() looks like it should be a dma_wmb().
>
> I see two points against it:
> - it co
On Wed, May 18, 2016 at 09:52:22AM -0700, Florian Fainelli wrote:
> On 05/18/2016 09:05 AM, Fabio Estevam wrote:
> > Commit da47b4572056 ("phy: add support for a reset-gpio specification")
> > causes the following xtensa qemu crash according to Guenter Roeck:
> >
> > [9.366256] libphy: ethoc-m
On Wed, May 18, 2016 at 10:57:21AM -0700, Alexander Duyck wrote:
> On Wed, May 18, 2016 at 9:01 AM, Eric Dumazet wrote:
> > On Wed, 2016-05-18 at 11:25 -0400, Neil Horman wrote:
> >> Noticed an allocation failure in a network driver the other day on a 32 bit
> >> system:
> >>
> >> DMA-API: debuggi
Linus Torvalds writes:
> On Wed, May 18, 2016 at 11:58 AM, Kalle Valo wrote:
>>
>> It would be best if you could send a patch either directly to Dave or
>> Linus to resolve this quickly.
>
> I'm committing my patch myself right now, since this bug makes my
> laptop useless, and I will take credi
On Wed, 2016-05-18 at 12:00 -0700, Linus Torvalds wrote:
> On Wed, May 18, 2016 at 11:58 AM, Kalle Valo
> wrote:
> >
> >
> > It would be best if you could send a patch either directly to Dave
> > or
> > Linus to resolve this quickly.
> I'm committing my patch myself right now, since this bug mak
Update to iproute2 utility to support new features in Linux 4.5.
Major things are improvements to bridg mdb management, and bpf.
Also, support for new devlink infrastructure
Source:
http://www.kernel.org/pub/linux/utils/net/iproute2/iproute2-4.6.0.tar.gz
Repository:
git://git.kernel.org/pub/s
From: Luca Coelho
During the merge in commit 909b27f70643 ("Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net"), there was a
small merge damage where one instance of info was not converted into
skb_info. Fix this.
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/m
On Wed, May 18, 2016 at 11:58 AM, Kalle Valo wrote:
>
> It would be best if you could send a patch either directly to Dave or
> Linus to resolve this quickly.
I'm committing my patch myself right now, since this bug makes my
laptop useless, and I will take credit for finding and testing it on
my
"Coelho, Luciano" writes:
> Kalle, David, what is the status with the fix that is on the way via
> your trees?
It would be best if you could send a patch either directly to Dave or
Linus to resolve this quickly.
--
Kalle Valo
On Wed, May 18, 2016 at 11:45 AM, Linus Torvalds
wrote:
>
> From what I can tell, there's a merge bug in commit 909b27f70643,
> where David seems to have lost some of the changes to
> iwl_mvm_set_tx_cmd().
>
> I do not know if that's the reason for the problem I see. But I will test.
Yes. The att
On Wed, 2016-05-18 at 11:45 -0700, Linus Torvalds wrote:
> On Wed, May 18, 2016 at 7:23 AM, Coelho, Luciano
> wrote:
> >
> >
> > I can confirm that 4.6 contains the same bug. And reverting the
> > patch
> > I mentioned does solve the problem...
> >
> > The same patch works fine in our internal
On Tue, 17 May 2016 12:35:53 -0600
subas...@codeaurora.org wrote:
> On 2016-05-16 20:29, Lorenzo Colitti wrote:
> > On Tue, May 17, 2016 at 11:24 AM, David Ahern
> > wrote:
> >> As I mentioned we can print the unsupported once or per socket matched
> >> and
> >> with the socket params. e.g.,
>
On Wed, May 18, 2016 at 7:23 AM, Coelho, Luciano
wrote:
>
> I can confirm that 4.6 contains the same bug. And reverting the patch
> I mentioned does solve the problem...
>
> The same patch works fine in our internal tree. I'll have to figure
> out together with Emmanuel what the problem actually
If !count is true, count < 4 is also true.
Signed-off-by: Heinrich Schuchardt
---
drivers/net/usb/pegasus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
index 36cd7f0..9bbe0161 100644
--- a/drivers/net/usb/pegasus.c
+++
On 5/18/2016 10:06 AM, Sowmini Varadhan wrote:
When a rogue SYN is received after the connection arbitration
algorithm has converged, the incoming SYN should not needlessly
quiesce the transmit path, and it should not result in needless
TCP connection resets due to re-execution of the connection
On 5/18/2016 10:06 AM, Sowmini Varadhan wrote:
There are two instances where we want to terminate RDS-TCP: when
exiting the netns or during module unload. In either case, the
termination sequence is to stop the listen socket, mark the
rtn->rds_tcp_listen_sock as null, and flush any accept workqs.
On Wed, May 18, 2016 at 9:02 AM, Eric Dumazet wrote:
>
> On Wed, 2016-05-18 at 08:46 -0700, Ben Greear wrote:
>
> > I will work on captures...do you care if it is from transmitter or
> > receiver's perspective?
>
> Receiver would probably be more useful.
Can I get sender side traces too? I am wor
On Wed, May 18, 2016 at 9:01 AM, Eric Dumazet wrote:
> On Wed, 2016-05-18 at 11:25 -0400, Neil Horman wrote:
>> Noticed an allocation failure in a network driver the other day on a 32 bit
>> system:
>>
>> DMA-API: debugging out of memory - disabling
>> bnx2fc: adapter_lookup: hba NULL
>> lldpad: p
On 05/17/2016 07:44 PM, Eric Dumazet wrote:
> iscsi_sw_tcp_data_ready() and iscsi_sw_tcp_state_change() were
> using read_lock(&sk->sk_callback_lock) which is fine if caller
> disabled BH.
>
> TCP stack no longer has this requirement and can run from
> process context.
>
> Use read_lock_bh() vari
This patch addresses the same issue we had for IPv4 where enabling GRE with
an inner checksum cannot be supported with FOU/GUE due to the fact that
they will jump past the GRE header at it is treated like a tunnel header.
Signed-off-by: Alexander Duyck
---
net/ipv6/ip6_gre.c | 12
This patch adds support for offloading IPXIP6 type packets that represent
either IPv4 or IPv6 encapsulated inside of an IPv6 outer IP header. In
addition with this change we should also be able to support FOU
encapsulated traffic with outer IPv6 headers.
Signed-off-by: Alexander Duyck
---
drive
This patch series is meant to be applied after:
[PATCH v7 net-next 00/16] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling
The first patch addresses an issue we already resolved in the GREv4 and is
now present in GREv6 with the introduction of FOU/GUE for IPv6 based GRE
tunnels.
The second p
On Wed, May 18, 2016 at 10:32 AM, Alexander Duyck
wrote:
> On Wed, May 18, 2016 at 9:06 AM, Tom Herbert wrote:
>> This patch set:
>> - Fixes GRE6 to process translate flags correctly from configuration
>> - Adds support for GSO and GRO for ip6ip6 and ip4ip6
>> - Add support for FOU and GUE
On Wed, May 18, 2016 at 9:06 AM, Tom Herbert wrote:
> This patch set:
> - Fixes GRE6 to process translate flags correctly from configuration
> - Adds support for GSO and GRO for ip6ip6 and ip4ip6
> - Add support for FOU and GUE in IPv6
> - Support GRE, ip6ip6 and ip4ip6 over FOU/GUE
> -
On Wed, 2016-05-18 at 12:21 -0500, Mike Christie wrote:
> Can I just confirm that nested bh lock calls like:
>
> spin_lock_bh(lock1);
> spin_lock_bh(lock2);
>
> do something
>
> spin_unlock_bh(lock2);
> spin_unlock_bh(lock1);
>
> is ok? It seems smatch sometimes warns about this.
It is ok.
M
On Tue, May 17, 2016 at 4:38 PM, Jamal Hadi Salim wrote:
> diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c
> index 014f9a6..f581e01 100644
> --- a/net/sched/act_bpf.c
> +++ b/net/sched/act_bpf.c
> @@ -156,6 +156,7 @@ static int tcf_bpf_dump(struct sk_buff *skb, struct
> tc_action *act,
>
>
On Wed, 2016-05-18 at 19:19 +0300, Andrey Ryabinin wrote:
> ->sk_shutdown bits share one bitfield with some other bits in sock struct,
> such as ->sk_no_check_[r,t]x, ->sk_userlocks ...
> sock_setsockopt() may write to these bits, while holding the socket lock.
>
> In case of AF_UNIX sockets, we c
On Wed, May 18, 2016 at 10:07 AM, Cong Wang wrote:
> On Wed, May 18, 2016 at 9:30 AM, Tom Herbert wrote:
>> On Wed, May 18, 2016 at 1:30 AM, Simon Horman
>> wrote:
>>> During initialisation sk->sk_user_data should be initialised before
>>> it is referenced via a call to gue_encap_init().
>>>
>>
On Tue, May 17, 2016 at 2:19 PM, Jamal Hadi Salim wrote:
> From: Jamal Hadi Salim
>
> Signed-off-by: Jamal Hadi Salim
Acked-by: Cong Wang
On Tue, May 17, 2016 at 2:19 PM, Jamal Hadi Salim wrote:
> From: Jamal Hadi Salim
>
> Signed-off-by: Jamal Hadi Salim
Looks good to me. I assume this patch passes checkpatch.pl. ;)
Acked-by: Cong Wang
On Wed, May 18, 2016 at 9:30 AM, Tom Herbert wrote:
> On Wed, May 18, 2016 at 1:30 AM, Simon Horman
> wrote:
>> During initialisation sk->sk_user_data should be initialised before
>> it is referenced via a call to gue_encap_init().
>>
> I think this is should be fixed by proposed patch "fou:
> Ca
We have been testing the RDS-TCP code with a connection spammer
that sends incoming SYNs to the RDS listen port well after
an rds-tcp connection has been established, and found a few
race-windows that are fixed by this patch series.
Patch 1 avoids a null pointer deref when an incoming SYN
shows
When a rogue SYN is received after the connection arbitration
algorithm has converged, the incoming SYN should not needlessly
quiesce the transmit path, and it should not result in needless
TCP connection resets due to re-execution of the connection
arbitration logic.
Signed-off-by: Sowmini Varadh
There are two instances where we want to terminate RDS-TCP: when
exiting the netns or during module unload. In either case, the
termination sequence is to stop the listen socket, mark the
rtn->rds_tcp_listen_sock as null, and flush any accept workqs.
Thus any workqs that get flushed at this point w
> For LEDs, we had a patch series floating around adding LED triggers [1],
> and it seems to me like the LEDs class subsystem would be a good fit for
> controlling PHY LEDs, possibly with the help of PHYLIB when it comes to
> doing the low-level work of registering LEDs and their names with the
> L
On 05/18/2016 09:05 AM, Fabio Estevam wrote:
> Commit da47b4572056 ("phy: add support for a reset-gpio specification")
> causes the following xtensa qemu crash according to Guenter Roeck:
>
> [9.366256] libphy: ethoc-mdio: probed
> [9.367389] (null): could not attach to PHY
> [9.36855
->sk_shutdown bits share one bitfield with some other bits in sock struct,
such as ->sk_no_check_[r,t]x, ->sk_userlocks ...
sock_setsockopt() may write to these bits, while holding the socket lock.
In case of AF_UNIX sockets, we change ->sk_shutdown bits while holding only
unix_state_lock(). So co
On Wed, May 18, 2016 at 09:41:03AM -0700, Eric Dumazet wrote:
> On Wed, 2016-05-18 at 19:26 +0300, Michael S. Tsirkin wrote:
> > On Wed, May 18, 2016 at 10:13:59AM +0200, Jesper Dangaard Brouer wrote:
> > > I agree. It is sad to see everybody is implementing the same thing,
> > > open coding an arr
On Wed, May 18, 2016 at 1:30 AM, Simon Horman
wrote:
> During initialisation sk->sk_user_data should be initialised before
> it is referenced via a call to gue_encap_init().
Or just use 'fou' directly?
diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
index eeec7d6..0b7a983 100644
--- a/net/ipv4/fou.
On Wed, May 18, 2016 at 11:07 PM, Alexander Duyck
wrote:
> On Wed, May 18, 2016 at 1:55 AM, Xin Long wrote:
>> vlan_features is used to set the vlan_dev->features when we create
>> a vlan device. it shouldn't have the vlan related flag, like
>> NETIF_F_HW_VLAN_CTAG_FILTER, which will cause vlan_d
On Wed, 2016-05-18 at 19:26 +0300, Michael S. Tsirkin wrote:
> On Wed, May 18, 2016 at 10:13:59AM +0200, Jesper Dangaard Brouer wrote:
> > I agree. It is sad to see everybody is implementing the same thing,
> > open coding an array/circular based ring buffer. This kind of code is
> > hard to maint
On Wed, May 18, 2016 at 1:30 AM, Simon Horman
wrote:
> During initialisation sk->sk_user_data should be initialised before
> it is referenced via a call to gue_encap_init().
>
I think this is should be fixed by proposed patch "fou:
Call-setup_udp_tunnel_sock".
Thanks,
Tom
> Found by bisection af
On Wed, May 18, 2016 at 10:13:59AM +0200, Jesper Dangaard Brouer wrote:
> I agree. It is sad to see everybody is implementing the same thing,
> open coding an array/circular based ring buffer. This kind of code is
> hard to maintain and get right with barriers etc. We can achieve the
> same perfo
CC'ing Andrew, John,
On 05/18/2016 09:03 AM, Alexander Stein wrote:
> This currently only supports PEF7071 and allows to specify max-speed and
> is able to read the LED configuration from device-tree.
>
> Signed-off-by: Alexander Stein
> ---
> The main purpose for now is to set a LED configurati
Commit da47b4572056 ("phy: add support for a reset-gpio specification")
causes the following xtensa qemu crash according to Guenter Roeck:
[9.366256] libphy: ethoc-mdio: probed
[9.367389] (null): could not attach to PHY
[9.368555] (null): failed to probe MDIO bus
[9.371540] Unabl
Add netlink and setup for encapsulation
Signed-off-by: Tom Herbert
---
net/ipv6/ip6_gre.c | 79 +++---
1 file changed, 75 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 4541fa5..6fb1b89 100644
--- a/net/ip
Consolidate all the ip_tunnel_encap definitions in one spot in the
header file. Also, move ip_encap_hlen and ip_tunnel_encap from
ip_tunnel.c to ip_tunnels.h so they call be called without a dependency
on ip_tunnel module. Similarly, move iptun_encaps to ip_tunnel_core.c.
Signed-off-by: Tom Herber
This patch add a new fou6 module that provides encapsulation
operations for IPv6.
Signed-off-by: Tom Herbert
---
include/net/fou.h | 2 +-
net/ipv6/Makefile | 1 +
net/ipv6/fou6.c | 140 ++
3 files changed, 142 insertions(+), 1 deletion(-
In ip6_input_finish the nexthdr protocol is retrieved from the
next header offset that is returned in the cb of the skb.
This method does not work for UDP encapsulation that may not
even have a concept of a nexthdr field (e.g. FOU).
This patch checks for a final protocol (INET6_PROTO_FINAL) when a
Use helper function to set up UDP tunnel related information for a fou
socket.
Signed-off-by: Tom Herbert
---
net/ipv4/fou.c | 50 --
1 file changed, 16 insertions(+), 34 deletions(-)
diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
index eeec7d6..6cb
Add encap_hlen and ip_tunnel_encap structure to ip6_tnl. Add functions
for getting encap hlen, setting up encap on a tunnel, performing
encapsulation operation.
Signed-off-by: Tom Herbert
---
include/net/ip6_tunnel.h | 58 +
net/ipv4/ip_tunnel_core.c | 5 +++
net/ip
This patch adds receive path support for IPv6 with fou.
- Add address family to fou structure for open sockets. This supports
AF_INET and AF_INET6. Lookups for fou ports are performed on both the
port number and family.
- In fou and gue receive adjust tot_len in IPv4 header or payload_len
ba
In several gso_segment functions there are checks of gso_type against
a seemingly arbitrary list of SKB_GSO_* flags. This seems like an
attempt to identify unsupported GSO types, but since the stack is
the one that set these GSO types in the first place this seems
unnecessary to do. If a combinatio
Since iptunnel_handle_offloads() is called in all paths we can
probably drop the block in ip6_tnl_xmit that was checking for
skb->encapsulation and resetting the inner headers.
Signed-off-by: Tom Herbert
---
net/ipv6/ip6_tunnel.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/net/ipv6/i
When performing foo-over-UDP, UDP packets are processed by the
encapsulation handler which returns another protocol to process.
This may result in processing two (or more) protocols in the
loop that are marked as INET6_PROTO_FINAL. The actions taken
for hitting a final protocol, in particular the s
Signed-off-by: Tom Herbert
---
net/ipv6/ip6_offload.c | 24 +---
net/ipv6/ip6_tunnel.c | 5 +
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index 787e55f..332d6a0 100644
--- a/net/ipv6/ip6_offload.c
+++ b/
Signed-off-by: Tom Herbert
---
include/net/inet_common.h | 5 +
net/ipv4/af_inet.c| 12 +++-
net/ipv6/ip6_offload.c| 33 -
net/ipv6/ip6_tunnel.c | 5 +
4 files changed, 49 insertions(+), 6 deletions(-)
diff --git a/include/net/ine
Add netlink and setup for encapsulation
Signed-off-by: Tom Herbert
---
net/ipv6/ip6_tunnel.c | 72 +++
1 file changed, 72 insertions(+)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 64ddbeac..74b35e4 100644
--- a/net/ipv6/ip6_tu
Need to set dev features, use same values that are used in GREv6.
Signed-off-by: Tom Herbert
---
net/ipv6/ip6_tunnel.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 74b35e4..cabf492 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ip
This patch defines two new GSO definitions SKB_GSO_IPXIP4 and
SKB_GSO_IPXIP6 along with corresponding NETIF_F_GSO_IPXIP4 and
NETIF_F_GSO_IPXIP6. These are used to described IP in IP
tunnel and what the outer protocol is. The inner protocol
can be deduced from other GSO types (e.g. SKB_GSO_TCPV4 and
Create __fou_build_header and __gue_build_header. These implement the
protocol generic parts of building the fou and gue header.
fou_build_header and gue_build_header implement the IPv4 specific
functions and call the __*_build_header functions.
Signed-off-by: Tom Herbert
---
include/net/fou.h |
This patch set:
- Fixes GRE6 to process translate flags correctly from configuration
- Adds support for GSO and GRO for ip6ip6 and ip4ip6
- Add support for FOU and GUE in IPv6
- Support GRE, ip6ip6 and ip4ip6 over FOU/GUE
- Fixes ip6_input to deal with UDP encapsulations
- Some other mi
This currently only supports PEF7071 and allows to specify max-speed and
is able to read the LED configuration from device-tree.
Signed-off-by: Alexander Stein
---
The main purpose for now is to set a LED configuration from device tree and
to limit the maximum speed. The latter one in my case har
On Wed, 2016-05-18 at 08:46 -0700, Ben Greear wrote:
> I will work on captures...do you care if it is from transmitter or receiver's
> perspective?
Receiver would probably be more useful.
On Wed, 2016-05-18 at 11:25 -0400, Neil Horman wrote:
> Noticed an allocation failure in a network driver the other day on a 32 bit
> system:
>
> DMA-API: debugging out of memory - disabling
> bnx2fc: adapter_lookup: hba NULL
> lldpad: page allocation failure. order:0, mode:0x4120
> Pid: 4556, com
On 05/18/2016 08:25 AM, Eric Dumazet wrote:
On Wed, 2016-05-18 at 08:07 -0700, Ben Greear wrote:
On 05/18/2016 07:29 AM, Eric Dumazet wrote:
On Wed, 2016-05-18 at 07:00 -0700, Ben Greear wrote:
We are investigating a system that has fairly poor TCP throughput
with the 3.17 and 4.0 kernels, bu
1 - 100 of 174 matches
Mail list logo
