Re: [PATCH 1/1] net: pegasus: simplify logical constraint

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.

RE: [PATCH linux-firmware] qed: Add FW 8.10.5.0

> 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]

RE: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

> 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;

[PATCH net V2] tuntap: correctly wake up process during uninit

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

Re: [PATCH net] tuntap: correctly wake up process during uninit

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

Re: [PATCH 1/1 RFC] net/phy: Add Lantiq PHY driver

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.

Re: [PATCH iproute2] ss: Tell user about -EOPNOTSUPP for SOCK_DESTROY

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

Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

I'm travelling and very busy with the merge window. So sorry I won't be able to think about this for some time.

Re: [net-next PATCH 0/2] Follow-ups for GUEoIPv6 patches

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

Re: [GIT] Networking

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

Re: [PATCH iproute2] ss: Tell user about -EOPNOTSUPP for SOCK_DESTROY

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

Re: [patch net-next 1/3] mlxsw: spectrum: Reduce number of supported 802.1D bridges

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

Re: [PATCH iproute2] ss: Tell user about -EOPNOTSUPP for SOCK_DESTROY

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. >

Re: [PATCH iproute2] ss: Tell user about -EOPNOTSUPP for SOCK_DESTROY

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,

Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

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;

RE: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

> 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;

Re: [PATCH iproute2] ss: Tell user about -EOPNOTSUPP for SOCK_DESTROY

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

[PATCH] net/atm: sk_err_soft must be positive

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

Re: [net-next PATCH 0/2] Follow-ups for GUEoIPv6 patches

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:

Re: [net-next PATCH 0/2] Follow-ups for GUEoIPv6 patches

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

Re: [PATCH v2] ethernet:arc: Fix racing of TX ring buffer

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

Re: [PATCH v7 net-next 02/16] net: define gso types for IPx over IPv4 and IPv6

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

Re: [PATCH net-next 1/4] scsi_tcp: block BH in TCP callbacks

On Wed, 2016-05-18 at 15:48 -0500, Mike Christie wrote: > Reviewed and tested. Thanks > > Acked-by: Mike Christie Excellent, thanks Mike !

Re: [PATCH] net: suppress warnings on dev_alloc_skb

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

Re: [RFC PATCH net] e1000e: keep vlan interfaces functional after rxvlan off

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

Re: [PATCHv2 bluetooth-next 04/10] ndisc: add addr_len parameter to ndisc_opt_addr_space

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:

Re: [net-next PATCH 0/2] Follow-ups for GUEoIPv6 patches

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

Re: [PATCH net] bpf: rather use get_random_int for randomizations

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

Re: [PATCH] net: suppress warnings on dev_alloc_skb

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 > >>

Re: [PATCH net-next 1/4] scsi_tcp: block BH in TCP callbacks

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_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() variant

Re: [PATCH] net: suppress warnings on dev_alloc_skb

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

Re: [RFC][PATCH net] bpf: Use mount_nodev not mount_ns to mount the bpf filesystem

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

Re: [RFC][PATCH net] bpf: Use mount_nodev not mount_ns to mount the bpf filesystem

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

Re: [PATCH v2] ethernet:arc: Fix racing of TX ring buffer

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

Re: [PATCH] Revert "phy: add support for a reset-gpio specification"

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:

Re: [PATCH] net: suppress warnings on dev_alloc_skb

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: >

Re: [GIT] Networking

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

Re: [GIT] Networking

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

[ANNOUNCE] iproute2 4.6

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:

Re: [GIT] Networking

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

[PATCH] iwlwifi: mvm: fix merge damage in tx.c

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

Re: [GIT] Networking

"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

Re: [GIT] Networking

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

Re: [GIT] Networking

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

Re: [PATCH iproute2] ss: Tell user about -EOPNOTSUPP for SOCK_DESTROY

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

Re: [GIT] Networking

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

[PATCH 1/1] net: pegasus: simplify logical constraint

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 ---

Re: [PATCH net 2/2] RDS: TCP: Avoid rds connection churn from rogue SYNs

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

Re: [PATCH net 1/2] RDS: TCP: rds_tcp_accept_worker() must exit gracefully when terminating rds-tcp

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

Re: Make TCP work better with re-ordered frames?

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

Re: [PATCH] net: suppress warnings on dev_alloc_skb

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:

Re: [PATCH net-next 1/4] scsi_tcp: block BH in TCP callbacks

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_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() variant

[net-next PATCH 1/2] ip6_gre: Do not allow segmentation offloads GRE_CSUM is enabled with FOU/GUE

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-next PATCH 2/2] intel: Add support for IPv6 IP-in-IP offload

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

[net-next PATCH 0/2] Follow-ups for GUEoIPv6 patches

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

Re: [PATCH v7 net-next 00/16] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling

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

Re: [PATCH v7 net-next 00/16] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling

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

Re: [PATCH net-next 1/4] scsi_tcp: block BH in TCP callbacks

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.

Re: [net-next RFC 1/1] net sched actions: introduce timestamp for first time used

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 >

Re: [PATCH v4] net: sock: move ->sk_shutdown out of bitfields.

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

Re: [PATCH net] fou: avoid using sk_user_data before it is initialised

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

Re: [net-next PATCH 2/2] net sched: actions use tcf_lastuse_update

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

Re: [net-next PATCH 1/2] net sched: indentation and other stylistic fixes

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

Re: [PATCH net] fou: avoid using sk_user_data before it is initialised

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

[PATCH net 0/2] RDS: TCP: connection spamming fixes

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

[PATCH net 2/2] RDS: TCP: Avoid rds connection churn from rogue SYNs

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

[PATCH net 1/2] RDS: TCP: rds_tcp_accept_worker() must exit gracefully when terminating rds-tcp

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

Re: [PATCH 1/1 RFC] net/phy: Add Lantiq PHY driver

> 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 >

Re: [PATCH] Revert "phy: add support for a reset-gpio specification"

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 > [

[PATCH v4] net: sock: move ->sk_shutdown out of bitfields.

->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

Re: [PATCH net-next] tuntap: introduce tx skb ring

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

Re: [PATCH net] fou: avoid using sk_user_data before it is initialised

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

Re: [Intel-wired-lan] [PATCH next-queue] ixgbe: netdev->vlan_features shouldn't have the vlan related flag

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 >>

Re: [PATCH net-next] tuntap: introduce tx skb ring

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

Re: [PATCH net] fou: avoid using sk_user_data before it is initialised

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,

Re: [PATCH net-next] tuntap: introduce tx skb ring

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

Re: [PATCH 1/1 RFC] net/phy: Add Lantiq PHY driver

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

[PATCH] Revert "phy: add support for a reset-gpio specification"

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]

[PATCH v7 net-next 11/16] ip6_gre: Add support for fou/gue encapsulation

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

[PATCH v7 net-next 05/16] net: Cleanup encap items in ip_tunnels.h

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

[PATCH v7 net-next 10/16] fou: Add encap ops for IPv6 tunnels

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

[PATCH v7 net-next 03/16] ipv6: Fix nexthdr for reinjection

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

[PATCH v7 net-next 06/16] fou: Call setup_udp_tunnel_sock

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

[PATCH v7 net-next 09/16] ip6_tun: Add infrastructure for doing encapsulation

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 +

[PATCH v7 net-next 08/16] fou: Support IPv6 in fou

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

[PATCH v7 net-next 01/16] gso: Remove arbitrary checks for unsupported GSO

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

[PATCH v7 net-next 16/16] ipv6: Don't reset inner headers in ip6_tnl_xmit

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(-)

[PATCH v7 net-next 15/16] ip4ip6: Support for GSO/GRO

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

[PATCH v7 net-next 12/16] ip6_tunnel: Add support for fou/gue encapsulation

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

[PATCH v7 net-next 13/16] ipv6: Set features for IPv6 tunnels

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 ---

[PATCH v7 net-next 02/16] net: define gso types for IPx over IPv4 and IPv6

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

[PATCH v7 net-next 04/16] ipv6: Change "final" protocol processing for encapsulation

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

[PATCH v7 net-next 14/16] ip6ip6: Support for GSO/GRO

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 ---

[PATCH v7 net-next 07/16] fou: Split out {fou,gue}_build_header

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

[PATCH v7 net-next 00/16] ipv6: Enable GUEoIPv6 and more fixes for v6 tunneling

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

[PATCH 1/1 RFC] net/phy: Add Lantiq PHY driver

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

Re: Make TCP work better with re-ordered frames?

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.

Re: [PATCH] net: suppress warnings on dev_alloc_skb

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,

Re: Make TCP work better with re-ordered frames?

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,

Re: Crashes in -next due to 'phy: add support for a reset-gpio specification'

On Tue, May 17, 2016 at 10:01:37PM -0700, Florian Fainelli wrote: > Le 17/05/2016 21:37, Guenter Roeck a écrit : > > Hi, > > > > my xtensa qemu tests crash in -next as follows. > > > > [ ... ] > > > > [9.366256] libphy: ethoc-mdio: probed > > [9.367389] (null): could not attach to PHY

  1   2   >