[GIT] Networking

Here are the build and merge fixups for the networking stuff. Please pull, thanks a lot! The following changes since commit 41844e36206be90cd4d962ea49b0abc3612a99d0: Merge tag 'staging-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging (2016-10-05 14:50:51 -0700) are

Re: [PATCH net-next v2 2/3] openvswitch: remove unreachable code in vlan parsing

On Wed, Oct 5, 2016 at 6:07 AM, Jiri Benc wrote: > Now when the first vlan tag is always in skb->vlan_tci, drop code that > assumed it might not be the case. > User can turn off TX vlan offload for OVS internal device that would allow vlan tagged packet with vlan header on the

Re: [PATCH net] Fixing a bug in team driver due to incorrect 'unsigned int' to 'int' conversion

From: Alex Sidorenko Date: Wed, 05 Oct 2016 09:06:04 -0400 > Roundrobin runner of team driver uses 'unsigned int' variable to count the > number of sent_packets. > Later it is passed to a subroutine team_num_to_port_index(struct team *team, > int num) as > 'num'

[PATCH v3 1/4] net: phy: dp83867: Add documentation for optional impedance control

Add documention of ti,impedance-control which can be used to correct MAC impedance mismatch using phy extended registers. Signed-off-by: Mugunthan V N --- Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 1 file changed, 12 insertions(+) diff --git

[PATCH v3 0/4] add support for impedance control for TI dp83867 phy and fix 2nd ethernet on dra72 rev C evm

Add support for configurable impedance control for TI dp83867 phy via devicetree. More documentation in [1]. CPSW second ethernet is not working, fix it by enabling impedance configuration on the phy. Verified the patch on DRA72 Rev C evm, logs at [2]. Also pushed a branch [3] for others to test.

[PATCH v3 2/4] net: phy: dp83867: add support for MAC impedance configuration

Add support for programmable MAC impedance configuration Signed-off-by: Mugunthan V N --- drivers/net/phy/dp83867.c | 28 1 file changed, 28 insertions(+) diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c index 91177a4..1b63924

[PATCH v3 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay

The current delay settings of the phy are not the optimal value, fix it with correct values. Signed-off-by: Mugunthan V N --- arch/arm/boot/dts/dra72-evm-revc.dts | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[PATCH v3 3/4] ARM: dts: dra72-evm-revc: add phy impedance settings

The default impedance settings of the phy is not the optimal value, due to this the second ethernet is not working. Fix it with correct values which makes the second ethernet port to work. Signed-off-by: Mugunthan V N --- arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++ 1 file

Re: [GIT] Networking

Hi Dave, On Wed, 05 Oct 2016 22:56:12 -0400 (EDT) David Miller wrote: > > Yes, this is where the change got lost. No worries. > I have all of the fixups queued up in my net tree and will send in a pull > request later. Thanks. -- Cheers, Stephen Rothwell

web.upgrades

ATENCIÓN; Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de

Re: error: 'struct net_device' has no member named 'nf_hooks_ingress'

On (10/06/16 06:11), Eric Dumazet wrote: > On Wed, 2016-10-05 at 22:56 +0200, Michal Sojka wrote: > > > this commit is now in mainline as > > e3b37f11e6e4e6b6f02cc762f182ce233d2c1c9d and it breaks my build: > > > > net/netfilter/core.c: In function 'nf_set_hooks_head': > >

Re: [GIT] Networking

From: Stephen Rothwell Date: Thu, 6 Oct 2016 13:51:52 +1100 > On Wed, 5 Oct 2016 19:14:21 -0700 Linus Torvalds > wrote: >> >> On Wed, Oct 5, 2016 at 5:52 PM, Stephen Rothwell >> wrote: >> > >> > Except that commit

Re: [GIT] Networking

Hi Linus, On Wed, 5 Oct 2016 19:14:21 -0700 Linus Torvalds wrote: > > On Wed, Oct 5, 2016 at 5:52 PM, Stephen Rothwell > wrote: > > > > Except that commit effectively moved that function from > > net/netfilter/nf_tables_netdev.c to > >

Re: [GIT] Networking

On Wed, Oct 5, 2016 at 5:52 PM, Stephen Rothwell wrote: > > Except that commit effectively moved that function from > net/netfilter/nf_tables_netdev.c to > include/net/netfilter/nf_tables_ipv4.h while commit c73c24849011 > ("netfilter: nf_tables_netdev: remove redundant

Re: [PATCH v2] phy: micrel.c: Enable ksz9031 energy-detect power-down mode

From: Mike Looijmans Date: Tue, 4 Oct 2016 07:52:04 +0200 > Set bit 0 in register 1C.23 to enable the EDPD feature of the > KSZ9031 PHY. This reduces power consumption when the link is > down. > > Signed-off-by: Mike Looijmans > --- > v2:

Re: [GIT] Networking

Hi Linus, On Wed, 5 Oct 2016 15:37:17 -0700 Linus Torvalds wrote: > > On Wed, Oct 5, 2016 at 3:29 PM, Stephen Rothwell > wrote: > > > > I have been carrying the following merge fix patch (for the merge of > > the net-next tree with Linus'

Re: [GIT] Networking

From: Pablo Neira Ayuso Date: Thu, 6 Oct 2016 02:09:45 +0200 > On Wed, Oct 05, 2016 at 03:37:17PM -0700, Linus Torvalds wrote: >> On Wed, Oct 5, 2016 at 3:29 PM, Stephen Rothwell >> wrote: >> > >> > I have been carrying the following merge fix patch

Re: [PATCH 0/5] Netfilter fixes for net-next

From: Pablo Neira Ayuso Date: Thu, 6 Oct 2016 02:07:44 +0200 > This is a pull request to address fallout from previous nf-next pull > request, only fixes going on here: > > 1) Address a potential null dereference in nf_unregister_net_hook() >when becomes

Re: [GIT] Networking

On Wed, Oct 05, 2016 at 03:37:17PM -0700, Linus Torvalds wrote: > On Wed, Oct 5, 2016 at 3:29 PM, Stephen Rothwell > wrote: > > > > I have been carrying the following merge fix patch (for the merge of > > the net-next tree with Linus' tree) for a while now which seems to

[PATCH 2/5] netfilter: accommodate different kconfig in nf_set_hooks_head

From: Aaron Conole When CONFIG_NETFILTER_INGRESS is unset (or no), we need to handle the request for registration properly by dropping the hook. This releases the entry during the set. Fixes: e3b37f11e6e4 ("netfilter: replace list_head with single linked list")

[PATCH 3/5] netfilter: xt_hashlimit: Fix link error in 32bit arch because of 64bit division

From: Vishwanath Pai Division of 64bit integers will cause linker error undefined reference to `__udivdi3'. Fix this by replacing divisions with div64_64 Fixes: 11d5f15723c9 ("netfilter: xt_hashlimit: Create revision 2 to ...") Signed-off-by: Vishwanath Pai

[PATCH 0/5] Netfilter fixes for net-next

Hi David, This is a pull request to address fallout from previous nf-next pull request, only fixes going on here: 1) Address a potential null dereference in nf_unregister_net_hook() when becomes nf_hook_entry_head is NULL, from Aaron Conole. 2) Missing ifdef for CONFIG_NETFILTER_INGRESS,

[PATCH 5/5] netfilter: nft_limit: fix divided by zero panic

From: Liping Zhang After I input the following nftables rule, a panic happened on my system: # nft add rule filter OUTPUT limit rate 0xf bytes/second divide error: [#1] SMP [ ... ] RIP: 0010:[] [] nft_limit_pkt_bytes_eval+0x2e/0xa0

[PATCH 4/5] netfilter: fix namespace handling in nf_log_proc_dostring

From: Jann Horn nf_log_proc_dostring() used current's network namespace instead of the one corresponding to the sysctl file the write was performed on. Because the permission check happens at open time and the nf_log files in namespaces are accessible for the namespace owner,

[PATCH 1/5] netfilter: Fix potential null pointer dereference

From: Aaron Conole It's possible for nf_hook_entry_head to return NULL. If two nf_unregister_net_hook calls happen simultaneously with a single hook entry in the list, both will enter the nf_hook_mutex critical section. The first will successfully delete the head, but the

Re: [PATCH net] netlink: do not enter direct reclaim from netlink_dump()

On Thu, Oct 06, 2016 at 08:30:11AM +0900, Eric Dumazet wrote: > On Wed, 2016-10-05 at 15:24 -0700, Alexei Starovoitov wrote: > > On Thu, Oct 06, 2016 at 04:13:18AM +0900, Eric Dumazet wrote: > > > > > > While we are at it, since we do an order-3 allocation, allow to use > > > all the allocated

Re: [PATCH net] netlink: do not enter direct reclaim from netlink_dump()

On Thu, Oct 06, 2016 at 08:35:21AM +0900, Eric Dumazet wrote: > On Wed, 2016-10-05 at 15:24 -0700, Alexei Starovoitov wrote: > > On Thu, Oct 06, 2016 at 04:13:18AM +0900, Eric Dumazet wrote: > > > > > > While we are at it, since we do an order-3 allocation, allow to use > > > all the allocated

Re: [PATCH net] netlink: do not enter direct reclaim from netlink_dump()

On Wed, 2016-10-05 at 15:24 -0700, Alexei Starovoitov wrote: > On Thu, Oct 06, 2016 at 04:13:18AM +0900, Eric Dumazet wrote: > > > > While we are at it, since we do an order-3 allocation, allow to use > > all the allocated bytes instead of 16384 to reduce syscalls during > > large dumps. > > > >

Re: [PATCH net] netlink: do not enter direct reclaim from netlink_dump()

On Wed, 2016-10-05 at 15:24 -0700, Alexei Starovoitov wrote: > On Thu, Oct 06, 2016 at 04:13:18AM +0900, Eric Dumazet wrote: > > > > While we are at it, since we do an order-3 allocation, allow to use > > all the allocated bytes instead of 16384 to reduce syscalls during > > large dumps. > > > >

Re: [GIT] Networking

On Wed, Oct 5, 2016 at 3:29 PM, Stephen Rothwell wrote: > > I have been carrying the following merge fix patch (for the merge of > the net-next tree with Linus' tree) for a while now which seems to have > got missed: Ugh. It doesn't seem to be a merge error, because that

Re: [GIT] Networking

Hi Linus, Dave, On Wed, 05 Oct 2016 01:44:37 -0400 (EDT) David Miller wrote: > I have been carrying the following merge fix patch (for the merge of the net-next tree with Linus' tree) for a while now which seems to have got missed: From: Stephen Rothwell

Re: [PATCH] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel

On Thu, 2016-10-06 at 00:13 +0200, Pavel Machek wrote: > On Wed 2016-10-05 12:15:34, Joe Perches wrote: > > On Wed, 2016-10-05 at 21:11 +0200, Pavel Machek wrote: > > > On Wed 2016-10-05 10:53:16, Joe Perches wrote: [] > > > > trivia: > > > > It's generally faster to use bool instead of u8 foo:1;

Re: [PATCH net] netlink: do not enter direct reclaim from netlink_dump()

On Thu, Oct 06, 2016 at 04:13:18AM +0900, Eric Dumazet wrote: > > While we are at it, since we do an order-3 allocation, allow to use > all the allocated bytes instead of 16384 to reduce syscalls during > large dumps. > > iproute2 already uses 32KB recvmsg() buffer sizes. > diff --git

Re: [RFC v3 03/22] bpf,landlock: Add a new arraymap type to deal with (Landlock) handles

On 04/10/2016 01:53, Kees Cook wrote: > On Wed, Sep 14, 2016 at 12:23 AM, Mickaël Salaün wrote: >> This new arraymap looks like a set and brings new properties: >> * strong typing of entries: the eBPF functions get the array type of >> elements instead of CONST_PTR_TO_MAP

Re: [PATCH] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel

On Wed 2016-10-05 12:15:34, Joe Perches wrote: > On Wed, 2016-10-05 at 21:11 +0200, Pavel Machek wrote: > > On Wed 2016-10-05 10:53:16, Joe Perches wrote: > > > On Wed, 2016-10-05 at 13:14 +0200, Marcel Holtmann wrote: > > > > Hi Pavel, > > > > > > > > > bluetooth.h is not part of user API, so __

Re: [PATCHv2] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel

Hi Pavel, > bluetooth.h is not part of user API, so __ variants are not neccessary > here. > > Signed-off-by: Pavel Machek > > --- > v2: not touching stuff that Marcel does not want touched, as it will > become API later. patch has been applied to bluetooth-next tree. Regards

Re: [RFC v3 16/22] bpf/cgroup,landlock: Handle Landlock hooks per cgroup

On Wed, Oct 5, 2016 at 1:58 PM, Mickaël Salaün wrote: > > > On 04/10/2016 01:43, Kees Cook wrote: >> On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: >>> This allows to add new eBPF programs to Landlock hooks dedicated to a >>> cgroup thanks to the

Re: error: 'struct net_device' has no member named 'nf_hooks_ingress'

On Wed, 2016-10-05 at 22:56 +0200, Michal Sojka wrote: > this commit is now in mainline as > e3b37f11e6e4e6b6f02cc762f182ce233d2c1c9d and it breaks my build: > > net/netfilter/core.c: In function 'nf_set_hooks_head': > net/netfilter/core.c:96:3: error: 'struct net_device' has no member

Re: [PATCH net-next v2 1/3] openvswitch: normalize vlan rx path

On Wed, 5 Oct 2016 15:21:32 -0400, Eric Garver wrote: > How about this incremental change? Feel free to submit it as a standalone patch. It has nothing to do with this patchset. In this particular regard, the code is identical before and after the patchset and is in no way altered by this patch.

Re: [RFC v3 11/22] seccomp,landlock: Handle Landlock hooks per process hierarchy

On 04/10/2016 01:52, Kees Cook wrote: > On Wed, Sep 14, 2016 at 3:34 PM, Mickaël Salaün wrote: >> >> On 14/09/2016 20:43, Andy Lutomirski wrote: >>> On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: A Landlock program will be triggered according

error: 'struct net_device' has no member named 'nf_hooks_ingress'

Hi, On Tue, Oct 04 2016, Sergey Senozhatsky wrote: > On (09/27/16 19:03), Sergey Senozhatsky wrote: >> Hello, >> >> On (09/27/16 16:40), Stephen Rothwell wrote: >> > >> > Changes since 20160923: >> > >> >> seems that commit e3b37f11e6e4e6b6 ("netfilter: replace list_head with >> single linked

Re: [RFC v3 19/22] landlock: Add interrupted origin

On 04/10/2016 01:46, Kees Cook wrote: > On Wed, Sep 14, 2016 at 6:19 PM, Andy Lutomirski wrote: >> On Wed, Sep 14, 2016 at 3:14 PM, Mickaël Salaün wrote: >>> >>> On 14/09/2016 20:29, Andy Lutomirski wrote: On Wed, Sep 14, 2016 at 12:24 AM, Mickaël

Re: [RFC v3 16/22] bpf/cgroup,landlock: Handle Landlock hooks per cgroup

On 04/10/2016 01:43, Kees Cook wrote: > On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün wrote: >> This allows to add new eBPF programs to Landlock hooks dedicated to a >> cgroup thanks to the BPF_PROG_ATTACH command. Like for socket eBPF >> programs, the Landlock hooks

[PATCHv2] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel

bluetooth.h is not part of user API, so __ variants are not neccessary here. Signed-off-by: Pavel Machek --- v2: not touching stuff that Marcel does not want touched, as it will become API later. diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h

Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing

On 04/10/2016 00:56, Kees Cook wrote: > On Tue, Sep 20, 2016 at 10:08 AM, Mickaël Salaün wrote: >> >> On 15/09/2016 11:19, Pavel Machek wrote: >>> Hi! >>> This series is a proof of concept to fill some missing part of seccomp as the ability to check syscall

Re: [PATCH net] netlink: do not enter direct reclaim from netlink_dump()

On Thu, 2016-10-06 at 04:13 +0900, Eric Dumazet wrote: > From: Eric Dumazet > > Since linux-3.15, netlink_dump() can use up to 16384 bytes skb > allocations. > > Due to struct skb_shared_info ~320 bytes overhead, we end up using > order-3 (on x86) page allocations, that

RE: [net-next 08/13] fsl/fman: check pcsphy pointer before use

> -Original Message- > From: David Laight [mailto:david.lai...@aculab.com] > Sent: Tuesday, October 04, 2016 5:44 PM > To: Madalin-Cristian Bucur ; > netdev@vger.kernel.org > Cc: linuxdev.baldr...@gmail.com; linuxppc-...@lists.ozlabs.org; > da...@davemloft.net;

Re: [PATCH net] Fixing a bug in team driver due to incorrect 'unsigned int' to 'int' conversion

On Wed, 2016-10-05 at 09:06 -0400, Alex Sidorenko wrote: > Roundrobin runner of team driver uses 'unsigned int' variable to count the > number of sent_packets. > Later it is passed to a subroutine team_num_to_port_index(struct team *team, > int num) as > 'num' and when we reach MAXINT (2**31-1),

[PATCH] net: bgmac: Fix errant feature flag check

During the conversion to the feature flags, a check against ci->id != BCMA_CHIP_ID_BCM47162 became bgmac->feature_flags & BGMAC_FEAT_CLKCTLS instead of !(bgmac->feature_flags & BGMAC_FEAT_CLKCTLS) Reported-by: Rafał Miłecki Signed-off-by: Jon Mason ---

Re: [PATCH net-next v2 1/3] openvswitch: normalize vlan rx path

On Wed, Oct 05, 2016 at 09:07:09PM +0200, Jiri Benc wrote: > On Wed, 5 Oct 2016 14:44:26 -0400, Eric Garver wrote: > > On Wed, Oct 05, 2016 at 08:31:52PM +0300, Eyal Birger wrote: > > > Just seemed less future safe to keep a pointer to an old packet lying > > > around. > > > > I agree.

Re: [PATCH] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel

On Wed, 2016-10-05 at 21:11 +0200, Pavel Machek wrote: > On Wed 2016-10-05 10:53:16, Joe Perches wrote: > > On Wed, 2016-10-05 at 13:14 +0200, Marcel Holtmann wrote: > > > Hi Pavel, > > > > > > > bluetooth.h is not part of user API, so __ variants are not neccessary > > > > here. > > > > > > > >

[PATCH net] netlink: do not enter direct reclaim from netlink_dump()

From: Eric Dumazet Since linux-3.15, netlink_dump() can use up to 16384 bytes skb allocations. Due to struct skb_shared_info ~320 bytes overhead, we end up using order-3 (on x86) page allocations, that might trigger direct reclaim and add stress. The intent was really to

Re: [PATCH] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel

On Wed 2016-10-05 10:53:16, Joe Perches wrote: > On Wed, 2016-10-05 at 13:14 +0200, Marcel Holtmann wrote: > > Hi Pavel, > > > > > bluetooth.h is not part of user API, so __ variants are not neccessary > > > here. > > > > > > Signed-off-by: Pavel Machek > > > > > > diff --git

Re: [PATCH net-next v2 1/3] openvswitch: normalize vlan rx path

On Wed, 5 Oct 2016 14:44:26 -0400, Eric Garver wrote: > On Wed, Oct 05, 2016 at 08:31:52PM +0300, Eyal Birger wrote: > > Just seemed less future safe to keep a pointer to an old packet lying > > around. > > I agree. Alternatively refresh the eth pointer. Sorry guys, that just doesn't make

Re: [PATCH net-next v2 1/3] openvswitch: normalize vlan rx path

On Wed, Oct 05, 2016 at 08:31:52PM +0300, Eyal Birger wrote: > On Wed, Oct 5, 2016 at 8:23 PM, Jiri Benc wrote: > > On Wed, 5 Oct 2016 17:18:08 +0300, Eyal Birger wrote: > >> I think at this point, 'eth' may point to a freed packet. > > > > It may but how does that matter? eth

Re: [PATCH net] Panic when tc_lookup_action_n finds a partially initialized action.

On Wed, Oct 5, 2016 at 11:01 AM, Cong Wang wrote: > On Tue, Oct 4, 2016 at 11:52 PM, Krister Johansen > wrote: >> On Mon, Oct 03, 2016 at 11:22:33AM -0700, Cong Wang wrote: >>> Please try the attached patch. I also convert the read path to RCU

Re: [PATCH net] Panic when tc_lookup_action_n finds a partially initialized action.

On Tue, Oct 4, 2016 at 11:52 PM, Krister Johansen wrote: > On Mon, Oct 03, 2016 at 11:22:33AM -0700, Cong Wang wrote: >> Please try the attached patch. I also convert the read path to RCU >> to avoid a possible deadlock. A quick test shows no lockdep splat. > > I tried

Re: [PATCH] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel

On Wed, 2016-10-05 at 13:14 +0200, Marcel Holtmann wrote: > Hi Pavel, > > > bluetooth.h is not part of user API, so __ variants are not neccessary > > here. > > > > Signed-off-by: Pavel Machek > > > > diff --git a/include/net/bluetooth/bluetooth.h > >

Re: [PATCH net-next v2 1/3] openvswitch: normalize vlan rx path

On Wed, Oct 5, 2016 at 8:23 PM, Jiri Benc wrote: > On Wed, 5 Oct 2016 17:18:08 +0300, Eyal Birger wrote: >> I think at this point, 'eth' may point to a freed packet. > > It may but how does that matter? eth is not used beyond that point. Definitely a nit. For sure not critical.

Re: [PATCH net-next v2 1/3] openvswitch: normalize vlan rx path

On Wed, 5 Oct 2016 17:18:08 +0300, Eyal Birger wrote: > I think at this point, 'eth' may point to a freed packet. It may but how does that matter? eth is not used beyond that point. Jiri

Re: Kernel 4.6.7-rt13: Intel Ethernet driver igb causes huge latencies in cyclictest

On Wed, Oct 05, 2016 at 07:02:21AM +, Koehrer Mathias (ETAS/ESW5) wrote: > Hi Julia, > > > > In the meanwhile I have detected another finding which might be relevant: > > > > > > With the 3.18 kernel the igb driver comes with two interrupts per > > > NIC (e.g. eth2 and eth2-TxRx0) with the

Re: [Xen-devel] [PATCH v2 net-next 2/7] xen-netback: retire guest rx side prefix GSO feature

On Wed, Oct 05, 2016 at 05:30:26PM +0200, Roger Pau Monné wrote: > [...] > Also, IIRC NetBSD doesn't have a Xen GSO implementation [1], but I would let > Manuel answer that one. I confirm, we don't support GSO at this time. -- Manuel Bouyer NetBSD: 26 ans

Re: [Xen-devel] [PATCH v2 net-next 2/7] xen-netback: retire guest rx side prefix GSO feature

On Tue, Oct 04, 2016 at 10:24:04AM -0400, Konrad Rzeszutek Wilk wrote: > On Tue, Oct 04, 2016 at 01:35:41PM +, Paul Durrant wrote: > > > -Original Message- > > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > > > Sent: 04 October 2016 13:52 > > > To: Paul Durrant

Re: [PATCH net-next v2 1/3] openvswitch: normalize vlan rx path

Hi, On Wed, Oct 5, 2016 at 4:07 PM, Jiri Benc wrote: > diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c > index 4d67ea856067..c47b3da8ecf2 100644 > --- a/net/openvswitch/datapath.c > +++ b/net/openvswitch/datapath.c > @@ -594,6 +594,16 @@ static int

[PATCH net] packet: call fanout_release, while UNREGISTERING a netdev

If a socket has FANOUT sockopt set, a new proto_hook is registered as part of fanout_add(). When processing a NETDEV_UNREGISTER event in af_packet, __fanout_unlink is called for all sockets, but prot_hook which was registered as part of fanout_add is not removed. Call fanout_release, on a

Re: Intel Ethernet driver igb causes huge latencies with cyclictest (rt-tests)

On Wed, 2016-10-05 at 08:29 +, Koehrer Mathias (ETAS/ESW5) wrote: > Hi all, > > I noticed that with fairly new versions of the Linux kernel, the igb driver > causes huge latencies with the cyclictest in a RT_PREEMPT environment. > The root cause seems to be the number of interrupts that are

[PATCH] devicetree: net: micrel-ksz90x1.txt: Properly explain skew settings

The KSZ9031 skew registers contain an offset, the chip's default value is "neutral" which does not add any skew. Programming a 0 into a skew property will actually set it the maximal negative adjustment and not to a neutral position as one would expect. Explain this situation in the devicetree

Re: [PATCH v2 net-next 0/2] bnx2x: page allocation failure

On 10/03/2016 08:19 PM, David Miller wrote: > From: "Baron, Jason" > Date: Mon, 3 Oct 2016 20:24:32 + > >> Or should I just send the incremental at this point? > Incremental is required at this point. Hi David, Ok. The above question was sent out erroneously. I have

RE: [PATCH net-next v2 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi

Hi Sergei, David, I think modifying that as below is clear and scalable. Agree? static bool mtk_is_hwlro_supported(struct mtk_eth *eth) { switch (eth->chip_id) { case MT7623_ETH: return true; } return false; } Thanks. Nelson -Original

RE: [PATCH net-next v2 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi

From: Nelson Chang > Sent: 05 October 2016 13:46 > > +static bool mtk_is_hwlro_supported(struct mtk_eth *eth) { > > + if (eth->chip_id == MT7623_ETH) > > + return true; > > + else > > + return false; > > return eth->chip_id == MT7623_ETH; > > => Since

[PATCH net-next v2 3/3] openvswitch: fix vlan subtraction from packet length

When the packet has its vlan tag in skb->vlan_tci, the length of the VLAN header is not counted in skb->len. It doesn't make sense to subtract it. In addition, to honor the comment below the code, the VLAN header length should not be subtracted if there's a vlan tag in skb->vlan_tci. This leads

[PATCH net-next v2 0/3] openvswitch: make vlan handling consistent

Always keep the first vlan tag "accelerated", i.e. in skb->vlan_tci. This simplifies things considerably. v2: added the first patch Jiri Benc (3): openvswitch: normalize vlan rx path openvswitch: remove unreachable code in vlan parsing openvswitch: fix vlan subtraction from packet length

[PATCH net-next v2 2/3] openvswitch: remove unreachable code in vlan parsing

Now when the first vlan tag is always in skb->vlan_tci, drop code that assumed it might not be the case. This patch also removes the wrong likely() statement around skb_vlan_tag_present introduced by 018c1dda5ff1 ("openvswitch: 802.1AD Flow handling, actions, vlan parsing, netlink attributes").

[PATCH net] Fixing a bug in team driver due to incorrect 'unsigned int' to 'int' conversion

Roundrobin runner of team driver uses 'unsigned int' variable to count the number of sent_packets. Later it is passed to a subroutine team_num_to_port_index(struct team *team, int num) as 'num' and when we reach MAXINT (2**31-1), 'num' becomes negative. This leads to using incorrect hash-bucket

[PATCH net-next v2 1/3] openvswitch: normalize vlan rx path

Similarly to how the core networking stack behaves, let the first vlan tag be always stored in skb->vlan_tci. This is already ensured in __netif_receive_skb_core for packets that were received from the kernel and honored by skb_vlan_push and skb_vlan_pop. The only remaining place are packets

[PATCH net-next v2] openvswitch: correctly fragment packet with mpls headers

If mpls headers were pushed to a defragmented packet, the refragmentation no longer works correctly after 48d2ab609b6b ("net: mpls: Fixups for GSO"). The network header has to be shifted after the mpls headers for the fragmentation and restored afterwards. Fixes: 48d2ab609b6b ("net: mpls: Fixups

Re: [PATCH net-next v2 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi

On 10/05/2016 03:46 PM, Nelson Chang wrote: +static bool mtk_is_hwlro_supported(struct mtk_eth *eth) { + if (eth->chip_id == MT7623_ETH) + return true; + else + return false; return eth->chip_id == MT7623_ETH; => Since there will be more chips support

Re: [PATCH net-next 1/2] openvswitch: remove nonreachable code in vlan parsing

On Tue, 4 Oct 2016 20:06:18 -0400, Eric Garver wrote: > This code is also called for packets passed back down from userspace > (after the flow key miss and upcall). So it does happen that we have a > skb without skb->vlan_tci set. That sucks. The vlan handling should be really consistent, Jiri

Re: [PATCH net-next] openvswitch: correctly fragment packet with mpls headers

On Tue, 4 Oct 2016 19:03:46 -0700, Pravin Shelar wrote: > We could have encapsulated packet defragmented in physical bridge. > that mean the packet is entering OVS after egressing tunnel device. > That use case would break due to this patch. Okay, thanks for explanation. I missed this use case

RE: [PATCH net-next v2 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi

Hi Sergei, Sorry, miss that. > +static bool mtk_is_hwlro_supported(struct mtk_eth *eth) { > + if (eth->chip_id == MT7623_ETH) > + return true; > + else > + return false; return eth->chip_id == MT7623_ETH; => Since there will be more chips support hw lro

RE: [PATCH net-next v2 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi

Hi Sergei, Thanks for your comments. Modified. Nelson -Original Message- From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com] Sent: Wednesday, October 05, 2016 8:18 PM To: Nelson Chang (張家祥); j...@phrozen.org; da...@davemloft.net Cc: n...@openwrt.org;

[PATCH net-next v2 RESEND 1/3] net: ethernet: mediatek: get the chip id by ETHDMASYS registers

The driver gets the chip id by ETHSYS_CHIPID0_3/ETHSYS_CHIPID4_7 registers in mtk_probe(). Signed-off-by: Nelson Chang --- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 29 + drivers/net/ethernet/mediatek/mtk_eth_soc.h | 5 + 2 files

[PATCH net-next v2 RESEND 3/3] net: ethernet: mediatek: remove hwlro property in the device tree

Since the proper way to check the hw lro capability is by the chip id, hwlro property in the device tree should be removed. Signed-off-by: Nelson Chang --- Documentation/devicetree/bindings/net/mediatek-net.txt | 2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH net-next v2 RESEND 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi

Because hw lro started to be supported from MT7623, the proper way to check if the feature is capable is to judge by the chip id instead of by the dtsi. Signed-off-by: Nelson Chang --- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 12 ++--

[PATCH net-next v2 RESEND 0/3] net: ethernet: mediatek: check the hw lro capability by the chip id instead of the dtsi

The series modify to check if hw lro is supported by the chip id. changes since v2: - Refine mtk_get_chip_id() function changes since v1: - Because hw lro started to be supported from MT7623, the proper way to check if the feature is capable is to judge by the chip id instead of by the dtsi.

Re: [PATCH net-next v2 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi

Hello. On 10/05/2016 03:12 PM, Nelson Chang wrote: Because hw lro started to be supported from MT7623, the proper way to check if the feature is capable is to judge by the chip id instead of by the dtsi. Signed-off-by: Nelson Chang ---

[PATCH net-next v2 0/3] net: ethernet: mediatek: check the hw lro capability by the chip id instead of the dtsi

The series modify to check if hw lro is supported by the chip id. changes since v2: - Refine mtk_get_chip_id() function changes since v1: - Because hw lro started to be supported from MT7623, the proper way to check if the feature is capable is to judge by the chip id instead of by the dtsi.

[PATCH net-next v2 3/3] net: ethernet: mediatek: remove hwlro property in the device tree

Since the proper way to check the hw lro capability is by the chip id, hwlro property in the device tree should be removed. Signed-off-by: Nelson Chang --- Documentation/devicetree/bindings/net/mediatek-net.txt | 2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH net-next v2 1/3] net: ethernet: mediatek: get the chip id by ETHDMASYS registers

The driver gets the chip id by ETHSYS_CHIPID0_3/ETHSYS_CHIPID4_7 registers in mtk_probe(). Signed-off-by: Nelson Chang --- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 29 + drivers/net/ethernet/mediatek/mtk_eth_soc.h | 5 + 2 files

[PATCH net-next v2 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi

Because hw lro started to be supported from MT7623, the proper way to check if the feature is capable is to judge by the chip id instead of by the dtsi. Signed-off-by: Nelson Chang --- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 12 ++--

Re: [PATCH v8 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.

> - As per review comment, Added DT vddmac, slowdown value error check. So i said an exact match, which this is not. How about something like: static u8 vsc85xx_edge_rate_magic_get(u16 vddmac, u8 slowdown) { u8 vdd; u8 sd; for (vdd = 0; vdd < ARRAY_SIZE(edge_table);

Re: [PATCH 3/3] mac80211: multicast to unicast conversion

On Wed, 2016-10-05 at 13:40 +0200, michael-dev wrote: > Am 05.10.2016 12:19, schrieb Johannes Berg: > > > > > > > > on both ends. Furthermore, I've seen a few mobile phone stations > > > locally that indicate qos support but won't complete DHCP if > > > their broadcasts are encapsulated as

Re: [PATCH 3/3] mac80211: multicast to unicast conversion

Am 05.10.2016 12:19, schrieb Johannes Berg: on both ends. Furthermore, I've seen a few mobile phone stations locally that indicate qos support but won't complete DHCP if their broadcasts are encapsulated as A-MSDU. Though they work fine with this series approach. Presumably those phones also

[PATCH v8 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.

From: Raju Lakkaraju Edge-rate: As system and networking speeds increase, a signal's output transition, also know as the edge rate or slew rate (V/ns), takes on greater importance because high-speed signals come with a price. That price is an assortment of

Re: [PATCH] bluetooth.h: __ variants of u8 and friends are not neccessary inside kernel

Hi Pavel, > bluetooth.h is not part of user API, so __ variants are not neccessary > here. > > Signed-off-by: Pavel Machek > > diff --git a/include/net/bluetooth/bluetooth.h > b/include/net/bluetooth/bluetooth.h > index bfd1590..aea0371 100644 > ---

Re: [patch net 0/2] mlxsw: Couple of fixes

Wed, Oct 05, 2016 at 02:29:27AM CEST, da...@davemloft.net wrote: >From: Jiri Pirko >Date: Tue, 4 Oct 2016 09:46:03 +0200 > >> Couple of fixes from Yotam. > >Series applied, thanks. > >Note that needed_headroom is a request, rather than a guarantee, so you >may in some rare

tg3 BUG: spinlock lockup suspected

I am testing 4.8 on my sparcs and got this on Sun V210 (sparc64). This is reproducible. 4.8.0-rc3-00013 did not have this problem, will bisect when I get some time. [ 74.123859] tg3.c:v3.137 (May 11, 2014) [ 74.123880] PCI: Enabling device: (:00:02.0), cmd 2 [ 74.315794] tg3

Re: [PATCH 3/3] mac80211: multicast to unicast conversion

+netdev > IEEE802.11-2012 proposes directed multicast service (DMS) using A- > MSDU frames and a station initiated control protocol. It has the > advantage that the station can recover the destination multicast mac > address, but it is not backward compatible with non QOS stations and > does not

Re: kernel v4.8: iptables logs are truncated with the 4.8 kernel?

On Tue, Oct 4, 2016 at 8:58 PM, Liping Zhang wrote: > Hi Justin, > > 2016-10-05 6:02 GMT+08:00 Justin Piszcz : >> Hello, >> [ .. ] > > Which one are you using? iptables or nftables? # iptables -V iptables v1.6.0 > > Could you please paste the

Re: net-next tree broken with CONFIG_NETFILTER_INGRESS=n

David Miller wrote: > From: Marcel Holtmann > Date: Wed, 5 Oct 2016 09:48:42 +0200 > > > I really wonder what is going on here. Normally if you break the > > build, you fix it. However it seems nobody really cares enough. If I > > am not mistaken, then

  1   2   >