Re: [PATCH] stmmac: Add support for SIMATIC IOT2000 platform

On 2017-04-24 23:27, Andy Shevchenko wrote: > On Mon, Apr 24, 2017 at 10:27 PM, Jan Kiszka wrote: >> The IOT2000 is industrial controller platform, derived from the Intel >> Galileo Gen2 board. The variant IOT2020 comes with one LAN port, the >> IOT2040 has two of them.

Re: net/ipv6: slab-out-of-bounds in ip6_tnl_xmit

On Mon, Apr 24, 2017 at 9:47 AM, Cong Wang wrote: > > We use ipv4 dst in ip6_tunnel and cast an IPv4 neigh key as an > IPv6 address... > > > neigh = dst_neigh_lookup(skb_dst(skb), > _hdr(skb)->daddr); >

Re: [PATCH RFC] ptr_ring: add ptr_ring_unconsume

On 2017年04月24日 20:00, Michael S. Tsirkin wrote: On Mon, Apr 24, 2017 at 07:54:18PM +0800, Jason Wang wrote: On 2017年04月24日 07:28, Michael S. Tsirkin wrote: On Tue, Apr 18, 2017 at 11:07:42AM +0800, Jason Wang wrote: On 2017年04月17日 07:19, Michael S. Tsirkin wrote: Applications that consume

[PATCH net 1/1] qed: Fix error in the dcbx app meta data initialization.

DCBX app_data array is initialized with the incorrect values for personality field. This would prevent offloaded protocols from honoring the PFC. Signed-off-by: Sudarsana Reddy Kalluru --- drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 10 +- 1 file changed,

Re: qed*: debug infrastructures

On Mon, 24 Apr 2017 17:38:57 +, Elior, Ariel wrote: > Hi Dave, Hi Ariel! I'm not Dave but let me share my perspective :) > According to the recent messages on the list indicating debugfs is not the way > to go, I am looking for some guidance on what is. dpipe approach was > mentioned as

[PATCH net-next v2] sparc64: Improve 64-bit constant loading in eBPF JIT.

Doing a full 64-bit decomposition is really stupid especially for simple values like 0 and -1. But if we are going to optimize this, go all the way and try for all 2 and 3 instruction sequences not requiring a temporary register as well. First we do the easy cases where it's a zero or sign

Re: [PATCH net-next] sparc64: Improve 64-bit constant loading in eBPF JIT.

From: Alexei Starovoitov Date: Mon, 24 Apr 2017 20:18:56 -0700 > all gcc-ism actually gives confidence that most likely > it's all good and battle proven logic :) Yes, this is old code written 15 years ago :) I'll fix up the spaces.

Re: [PATCH net] netvsc: fix calculation of available send sections

On Mon, 2017-04-24 at 18:33 -0700, Stephen Hemminger wrote: > My change (introduced in 4.11) to use find_first_clear_bit > incorrectly assumed that the size argument was words, not bits. Oops... > The effect was only a small limited number of the available send > sections were being actually

Re: [PATCH net-next] sparc64: Improve 64-bit constant loading in eBPF JIT.

On 4/24/17 7:53 PM, David Miller wrote: Doing a full 64-bit decomposition is really stupid especially for simple values like 0 and -1. But if we are going to optimize this, go all the way and try for all 2 and 3 instruction sequences not requiring a temporary register as well. Signed-off-by:

[PATCH net-next] sparc64: Improve 64-bit constant loading in eBPF JIT.

Doing a full 64-bit decomposition is really stupid especially for simple values like 0 and -1. But if we are going to optimize this, go all the way and try for all 2 and 3 instruction sequences not requiring a temporary register as well. Signed-off-by: David S. Miller ---

Re: [PATCH v2] net: core: Prevent from dereferencing null pointer when

On Mon, Apr 24, 2017 at 09:44:50PM -0400, David Miller wrote: > From: Myungho Jung > Date: Mon, 24 Apr 2017 18:00:52 -0700 > > > On Mon, Apr 24, 2017 at 12:02:35PM -0400, David Miller wrote: > >> From: Myungho Jung > >> Date: Thu, 20 Apr 2017 16:59:20 -0700

Re: [PATCH net-next 0/2] flower: add MPLS matching support

On Mon, 24 Apr 2017 22:06:08 -0400, Jamal Hadi Salim wrote: > On 17-04-24 10:00 PM, Jamal Hadi Salim wrote: > > On 17-04-24 09:48 PM, Jamal Hadi Salim wrote: > > > > > Hrm. maybe I am wrong. > > Lets say user sets all of the 8 bits in BOS, > > what does setting > > key_val->mpls_bos =

Re: [PATCH net-next 0/2] flower: add MPLS matching support

On 17-04-24 10:00 PM, Jamal Hadi Salim wrote: On 17-04-24 09:48 PM, Jamal Hadi Salim wrote: Hrm. maybe I am wrong. Lets say user sets all of the 8 bits in BOS, what does setting key_val->mpls_bos = nla_get_u8 do? Same with the 20 bits for the label in the u32 or 3 bit bits in the u8 tc.

Re: [PATCH net-next 0/2] flower: add MPLS matching support

On 17-04-24 09:48 PM, Jamal Hadi Salim wrote: On 17-04-24 09:20 PM, Jakub Kicinski wrote: On Mon, 24 Apr 2017 20:58:18 -0400, Jamal Hadi Salim wrote: On 17-04-24 02:32 PM, David Miller wrote: You have 3 TLVs, one of which is u8 that only allows use of 3 bits. The other is a u32 which allows

[PATCH net-next] bpf: map_get_next_key to return first key on NULL

From: Teng Qin When iterating through a map, we need to find a key that does not exist in the map so map_get_next_key will give us the first key of the map. This often requires a lot of guessing in production systems. This patch makes map_get_next_key return the first key when

Re: [PATCH 7/7] liquidio: use pcie_flr instead of duplicating it

From: Christoph Hellwig Date: Fri, 14 Apr 2017 21:11:31 +0200 > Signed-off-by: Christoph Hellwig > --- > drivers/net/ethernet/cavium/liquidio/lio_vf_main.c | 15 +-- > 1 file changed, 1 insertion(+), 14 deletions(-) > > diff --git

Re: [PATCH net-next 0/2] flower: add MPLS matching support

On 17-04-24 09:20 PM, Jakub Kicinski wrote: On Mon, 24 Apr 2017 20:58:18 -0400, Jamal Hadi Salim wrote: On 17-04-24 02:32 PM, David Miller wrote: You have 3 TLVs, one of which is u8 that only allows use of 3 bits. The other is a u32 which allows only 20 bits to be set. I don't think we

Re: [PATCH v2] net: core: Prevent from dereferencing null pointer when

From: Myungho Jung Date: Mon, 24 Apr 2017 18:00:52 -0700 > On Mon, Apr 24, 2017 at 12:02:35PM -0400, David Miller wrote: >> From: Myungho Jung >> Date: Thu, 20 Apr 2017 16:59:20 -0700 >> >> > Added NULL check to make __dev_kfree_skb_irq consistent with

Re: [PATCH v2] net: core: Prevent from dereferencing null pointer when

On Mon, Apr 24, 2017 at 06:10:32PM -0700, Eric Dumazet wrote: > On Mon, Apr 24, 2017 at 6:00 PM, Myungho Jung wrote: > > On Mon, Apr 24, 2017 at 12:02:35PM -0400, David Miller wrote: > >> From: Myungho Jung > >> Date: Thu, 20 Apr 2017 16:59:20 -0700 > >> >

[PATCH net] netvsc: fix calculation of available send sections

My change (introduced in 4.11) to use find_first_clear_bit incorrectly assumed that the size argument was words, not bits. The effect was only a small limited number of the available send sections were being actually used. This can cause performance loss with some workloads. Since map_words is

[PATCH net-next] selftests/net: Fix broken test case in psock_fanout

From: Mike Maloney The error return falue form sock_fanout_open is -1, not zero. One test case was checking for 0 instead of -1. Tested: Built and tested in clean client. Signed-off-by: Mike Maloney --- tools/testing/selftests/net/psock_fanout.c | 2 +-

Re: [PATCH net-next 0/2] flower: add MPLS matching support

On 17-04-24 09:05 PM, Benjamin LaHaise wrote: On Mon, Apr 24, 2017 at 08:58:18PM -0400, Jamal Hadi Salim wrote: On 17-04-24 02:32 PM, David Miller wrote: You have 3 TLVs, one of which is u8 that only allows use of 3 bits. The other is a u32 which allows only 20 bits to be set. What are the

Re: [PATCH net-next 0/2] flower: add MPLS matching support

On Mon, 24 Apr 2017 20:58:18 -0400, Jamal Hadi Salim wrote: > On 17-04-24 02:32 PM, David Miller wrote: > > From: Benjamin LaHaise > > > > > Series applied, but in the future: > > > > 1) Put the "v2", "v3", whatever in the inital [PATCH xxx] bracketed > >

EXTREMELY IMPORTANT

Dear Beloved, Sorry for the inconvenience, I am getting in touch with you regarding an extremely important and urgent matter, Please I need your urgent assistance and idea to finish up a project (Orphanage Home) Due to my health condition, Everything is available to finish up the project, All I

Re: [PATCH v2] net: core: Prevent from dereferencing null pointer when

On Mon, Apr 24, 2017 at 6:00 PM, Myungho Jung wrote: > On Mon, Apr 24, 2017 at 12:02:35PM -0400, David Miller wrote: >> From: Myungho Jung >> Date: Thu, 20 Apr 2017 16:59:20 -0700 >> >> > Added NULL check to make __dev_kfree_skb_irq consistent with kfree >>

Re: [PATCH net-next 0/2] flower: add MPLS matching support

On Mon, Apr 24, 2017 at 08:58:18PM -0400, Jamal Hadi Salim wrote: > On 17-04-24 02:32 PM, David Miller wrote: > > From: Benjamin LaHaise > > > > > Series applied, but in the future: > > > > 1) Put the "v2", "v3", whatever in the inital [PATCH xxx] bracketed > >

Re: [PATCH v2] net: core: Prevent from dereferencing null pointer when

On Mon, Apr 24, 2017 at 12:02:35PM -0400, David Miller wrote: > From: Myungho Jung > Date: Thu, 20 Apr 2017 16:59:20 -0700 > > > Added NULL check to make __dev_kfree_skb_irq consistent with kfree > > family of functions. > > > > Link:

Re: [PATCH net-next 0/2] flower: add MPLS matching support

On 17-04-24 02:32 PM, David Miller wrote: From: Benjamin LaHaise Series applied, but in the future: 1) Put the "v2", "v3", whatever in the inital [PATCH xxx] bracketed part of the subject line, otherwise it ends up in the GIT commit message header line

Re: Fw: New Defects reported by Coverity Scan for Linux

Yeah, not sure i see it either. cheers, jamal On Mon, Apr 24, 2017 at 8:09 PM, Cong Wang wrote: > On Mon, Apr 24, 2017 at 4:41 PM, Stephen Hemminger > wrote: >> This looks like a false positive >>

Re: Fw: New Defects reported by Coverity Scan for Linux

On Mon, Apr 24, 2017 at 4:41 PM, Stephen Hemminger wrote: > This looks like a false positive > > *** CID 1405487: Resource leaks (RESOURCE_LEAK) >

Re: [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.

Florian Fainelli writes: > On 04/24/2017 02:50 PM, Eric Anholt wrote: >> Cygnus has a single amac controller connected to the B53 switch with 2 >> PHYs. On the BCM911360_EP platform, those two PHYs are connected to >> the external ethernet jacks. >> >> Signed-off-by: Eric

Re: [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.

Andrew Lunn writes: >> +mdio: mdio@18002000 { >> +compatible = "brcm,iproc-mdio"; >> +reg = <0x18002000 0x8>; >> +#size-cells = <1>; >> +#address-cells = <0>; >> + >> +

Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

On 17-04-24 04:54 PM, Eric Anholt wrote: Scott Branden writes: Minor comment in line On 17-04-24 02:50 PM, Eric Anholt wrote: Cygnus is a small family of SoCs, of which we currently have devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the same

Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

Scott Branden writes: > Minor comment in line > > On 17-04-24 02:50 PM, Eric Anholt wrote: >> Cygnus is a small family of SoCs, of which we currently have >> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the >> same as 58xx, just requiring a tiny

Fw: New Defects reported by Coverity Scan for Linux

This looks like a false positive Date: Mon, 24 Apr 2017 14:40:46 -0700 From: scan-ad...@coverity.com To: step...@networkplumber.org Subject: New Defects reported by Coverity Scan for Linux 1 new defect(s) introduced to Linux found with Coverity Scan. 2 defect(s), reported by Coverity Scan

Re: [PATCH net-next v3 0/5] virtio-net tx napi

On Mon, Apr 24, 2017 at 01:49:25PM -0400, Willem de Bruijn wrote: > From: Willem de Bruijn > > Add napi for virtio-net transmit completion processing. Acked-by: Michael S. Tsirkin > Changes: > v2 -> v3: > - convert __netif_tx_trylock to

Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

On 04/24/2017 04:15 PM, Arun Parameswaran wrote: > > > On 17-04-24 04:07 PM, Florian Fainelli wrote: >> On 04/24/2017 04:03 PM, Arun Parameswaran wrote: >>> Hi Eric >>> >>> A comment on the Device ID. >>> >>> >>> On 17-04-24 02:50 PM, Eric Anholt wrote: Cygnus is a small family of SoCs, of

Re: test_progs packed...

On 4/24/17 4:06 PM, David Miller wrote: Alexei, why the packed attribute usage in test_progs.c? There should be no reason for this and it results in the object(s) having odd addresses (and thus be unaligned) on sparc. because in: static struct { struct ethhdr eth; struct

Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

On 17-04-24 04:07 PM, Florian Fainelli wrote: > On 04/24/2017 04:03 PM, Arun Parameswaran wrote: >> Hi Eric >> >> A comment on the Device ID. >> >> >> On 17-04-24 02:50 PM, Eric Anholt wrote: >>> Cygnus is a small family of SoCs, of which we currently have >>> devicetree for BCM11360 and

Re: [PATCH] sparc64: Support cbcond instructions in eBPF JIT.

On 4/24/17 4:02 PM, David Miller wrote: cbcond combines a compare with a branch into a single instruction. The limitations are: 1) Only newer chips support it 2) For immediate compares we are limited to 5-bit signed immediate values 3) The branch displacement is limited to 10-bit signed

Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

On 04/24/2017 04:03 PM, Arun Parameswaran wrote: > Hi Eric > > A comment on the Device ID. > > > On 17-04-24 02:50 PM, Eric Anholt wrote: >> Cygnus is a small family of SoCs, of which we currently have >> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the >> same as 58xx, just

test_progs packed...

Alexei, why the packed attribute usage in test_progs.c? There should be no reason for this and it results in the object(s) having odd addresses (and thus be unaligned) on sparc.

Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

Hi Eric A comment on the Device ID. On 17-04-24 02:50 PM, Eric Anholt wrote: > Cygnus is a small family of SoCs, of which we currently have > devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the > same as 58xx, just requiring a tiny bit of setup that was previously > missing. >

[PATCH] sparc64: Support cbcond instructions in eBPF JIT.

cbcond combines a compare with a branch into a single instruction. The limitations are: 1) Only newer chips support it 2) For immediate compares we are limited to 5-bit signed immediate values 3) The branch displacement is limited to 10-bit signed 4) We cannot use it for JSET Also,

RE: [Intel-wired-lan] [PATCH] ixgbe: initialize u64_stats_sync structures early at ixgbe_probe

-Original Message- From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On Behalf Of Liwei Song Sent: Sunday, December 4, 2016 7:41 PM To: Kirsher, Jeffrey T Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org;

Re: [PATCH net-next v5 1/2] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch

On 17-04-24 06:24 PM, David Miller wrote: I think we should eat the pain now and use the strict checks for all new features like this. I'm sorry if this makes more work for you, but this is really how we have to proceed moving forward. There is no work for me to do in tc if i push this in

Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

Minor comment in line On 17-04-24 02:50 PM, Eric Anholt wrote: Cygnus is a small family of SoCs, of which we currently have devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the same as 58xx, just requiring a tiny bit of setup that was previously missing. Signed-off-by: Eric

Re: [PATCH net 0/3] net: dsa: b53: BCM58xx devices fixes

From: Florian Fainelli Date: Mon, 24 Apr 2017 14:27:20 -0700 > This patch series contains fixes for the 58xx devices (Broadcom Northstar > Plus), which were identified thanks to the help of Eric Anholt. Series applied, thanks Florian.

Re: Blogpost evaluation this [PATCH v4 net-next RFC] net: Generic XDP

From: Jesper Dangaard Brouer Date: Mon, 24 Apr 2017 16:24:05 +0200 > I've done a very detailed evaluation of this patch, and I've created a > blogpost like report here: > > > https://prototype-kernel.readthedocs.io/en/latest/blogposts/xdp25_eval_generic_xdp_tx.html Thanks

Re: [PATCH net-next v5 1/2] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch

From: Jamal Hadi Salim Date: Mon, 24 Apr 2017 18:18:42 -0400 > With the posted patch: unknow bits set will result in a kernel > rejection unless the user space explicitly ask the kernel to ignore > flags it doesnt understand and just handles what it knows. This > reduces the

Re: Get amount of fast retransmissions from TCP info

> On 24 Apr 2017, at 23:31, Lars Erik Storbukås wrote: > > 2017-04-24 23:00 GMT+02:00 Neal Cardwell : >> On Mon, Apr 24, 2017 at 4:20 PM, Lars Erik Storbukås >> wrote: >>> 2017-04-24 21:42 GMT+02:00 Neal Cardwell

Re: [PATCH net-next v5 1/2] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch

On 17-04-24 04:30 PM, David Miller wrote: Which is fine. But two things: 1) Again, bits you aren't using now, make sure userspace doesn't set them. And if it does, reject. I meet those goals on the bit checks but i went a slightly different path with a patch I posted[1] With the

Re: [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.

> + mdio: mdio@18002000 { > + compatible = "brcm,iproc-mdio"; > + reg = <0x18002000 0x8>; > + #size-cells = <1>; > + #address-cells = <0>; > + > + gphy0: eth-gphy@0 { > +

Re: [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.

On 04/24/2017 02:50 PM, Eric Anholt wrote: > Cygnus has a single amac controller connected to the B53 switch with 2 > PHYs. On the BCM911360_EP platform, those two PHYs are connected to > the external ethernet jacks. > > Signed-off-by: Eric Anholt This looks fine, just a few

[PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.

Cygnus has a single amac controller connected to the B53 switch with 2 PHYs. On the BCM911360_EP platform, those two PHYs are connected to the external ethernet jacks. Signed-off-by: Eric Anholt --- arch/arm/boot/dts/bcm-cygnus.dtsi | 60 ++

[PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

Cygnus is a small family of SoCs, of which we currently have devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the same as 58xx, just requiring a tiny bit of setup that was previously missing. Signed-off-by: Eric Anholt ---

Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

On 04/24/2017 02:50 PM, Eric Anholt wrote: > Cygnus is a small family of SoCs, of which we currently have > devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the > same as 58xx, just requiring a tiny bit of setup that was previously > missing. > > Signed-off-by: Eric Anholt

[PATCH 0/2] net: dsa: b53: BCM11360 support

This little patch series follows on from Florian's fixes that he just sent, and enables the ethernet on the 911360_EP board. Without Florian's fixes, the controller comes up and forwarding happens between eth1 and eth2, but the CPU's eth0 packets don't get forwarded. Eric Anholt (2): net: dsa:

Re: [PATCH net 0/3] net: dsa: b53: BCM58xx devices fixes

Florian Fainelli writes: > Hi David, > > This patch series contains fixes for the 58xx devices (Broadcom Northstar > Plus), which were identified thanks to the help of Eric Anholt. This series is: Tested-by: Eric Anholt Thanks for all your help

Re: Get amount of fast retransmissions from TCP info

2017-04-24 23:00 GMT+02:00 Neal Cardwell : > On Mon, Apr 24, 2017 at 4:20 PM, Lars Erik Storbukås > wrote: >> 2017-04-24 21:42 GMT+02:00 Neal Cardwell : >>> On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås >>>

[PATCH net 2/3] net: dsa: b53: Implement software reset for 58xx devices

Implement the correct software reset sequence for 58xx devices by setting all 3 reset bits and polling for the SW_RST bit to clear itself without a given timeout. We cannot use is58xx() here because that would also include the 7445/7278 Starfighter 2 which have their own driver doing the reset

Re: [PATCH] stmmac: Add support for SIMATIC IOT2000 platform

On Mon, Apr 24, 2017 at 10:27 PM, Jan Kiszka wrote: > The IOT2000 is industrial controller platform, derived from the Intel > Galileo Gen2 board. The variant IOT2020 comes with one LAN port, the > IOT2040 has two of them. They can be told apart based on the board asset >

[PATCH net 3/3] net: dsa: b53: Fix CPU port for 58xx devices

The 58xx devices (Northstar Plus) do actually have their CPU port wired at port 8, it was unfortunately set to port 5 (B53_CPU_PORT_25) which is incorrect, since that is the second possible management port. Fixes: 991a36bb4645 ("net: dsa: b53: Add support for BCM585xx/586xx/88312 integrated

[PATCH net 1/3] net: dsa: b53: Include IMP/CPU port in dumb forwarding mode

Since Broadcom tags are not enabled in b53 (DSA_PROTO_TAG_NONE), we need to make sure that the IMP/CPU port is included in the forwarding decision. Without this change, switching between non-management ports would work, but not between management ports and non-management ports thus breaking the

[PATCH net 0/3] net: dsa: b53: BCM58xx devices fixes

Hi David, This patch series contains fixes for the 58xx devices (Broadcom Northstar Plus), which were identified thanks to the help of Eric Anholt. Florian Fainelli (3): net: dsa: b53: Include IMP/CPU port in dumb forwarding mode net: dsa: b53: Implement software reset for 58xx devices

Re: [PATCH v3 net] net: ipv6: regenerate host route if moved to gc list

On Mon, Apr 24, 2017 at 01:37:00PM -0600, David Ahern wrote: > On 4/24/17 10:39 AM, Eric Dumazet wrote: > > > > Very nice changelog ! > > > Thanks. Given my aggressive brain cell recycling program, I needed to > write down the analysis. > > > > >> diff --git a/net/ipv6/addrconf.c

Re: Get amount of fast retransmissions from TCP info

" On Mon, Apr 24, 2017 at 4:20 PM, Lars Erik Storbukås wrote: > 2017-04-24 21:42 GMT+02:00 Neal Cardwell : >> On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås >> wrote: >>> I'm trying to get amount of congestion events

[PATCH] net: ethernet: ti: netcp_core: remove unused compl queue mapping

This code is unused and probably was unintentionally left while moving completion queue mapping in submit function. Signed-off-by: Ivan Khoronzhuk --- Based on net-next/master drivers/net/ethernet/ti/netcp_core.c | 4 1 file changed, 4 deletions(-) diff --git

Re: [PATCH net-next v5 1/2] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch

From: Jamal Hadi Salim Date: Mon, 24 Apr 2017 08:49:00 -0400 > Yes, space is important and if i can express upto 32 flags > with one TLV rather than 32 TLVs i choose one TLV. Which is fine. But two things: 1) Again, bits you aren't using now, make sure userspace doesn't

Re: [PATCH net-next 0/3] Misc BPF cleanup

From: Alexander Alemayhu Date: Mon, 24 Apr 2017 15:31:05 +0200 > while looking into making the Makefile in samples/bpf better handle O= I saw > several warnings when running `make clean && make samples/bpf/`. This series > reduces those warnings. Series applied, thanks.

Re: Get amount of fast retransmissions from TCP info

2017-04-24 21:42 GMT+02:00 Neal Cardwell : > On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås > wrote: >> I'm trying to get amount of congestion events in TCP caused by >> DUPACK's (fast retransmissions), and can't seem to find any variable >> in

Re: [PATCH net-next] bpf: make bpf_xdp_adjust_head support mandatory

From: Daniel Borkmann Date: Mon, 24 Apr 2017 22:14:35 +0200 > Now that also the last in-tree user of the xdp_adjust_head bit has > been removed, we can remove the flag from struct bpf_prog altogether. > > This, at the same time, also makes sure that any future driver for >

EXTREMELY IMPORTANT

Dear Beloved, Sorry for the inconvenience, I am getting in touch with you regarding an extremely important and urgent matter, Please I need your urgent assistance and idea to finish up a project (Orphanage Home) Due to my health condition, Everything is available to finish up the project, All I

[PATCH net-next] bpf: make bpf_xdp_adjust_head support mandatory

Now that also the last in-tree user of the xdp_adjust_head bit has been removed, we can remove the flag from struct bpf_prog altogether. This, at the same time, also makes sure that any future driver for XDP comes with bpf_xdp_adjust_head() support right away. A rejection based on this flag

Re: [PATCH 1/1] qlcnic: fix unchecked return value

aFrom: Pan Bian Date: Sun, 23 Apr 2017 20:04:04 +0800 > From: Pan Bian > > Function pci_find_ext_capability() may return 0, which is an invalid > address. In function qlcnic_sriov_virtid_fn(), its return value is used > without validation. This may

Re: [stable] Networking security fixes

From: Ben Hutchings Date: Mon, 24 Apr 2017 20:47:29 +0100 > Please queue up these fixes for 4.10.y: > > 8605330aac5a tcp: fix SCM_TIMESTAMPING_OPT_STATS for normal skbs > 4ef1b2869447 tcp: mark skbs with SCM_TIMESTAMPING_OPT_STATS Ok, queued up, thanks. > Please

Re: PATCH drivers:net:cris/eth_v10: alternate string char arrary

From: Karim Eshapa Date: Mon, 24 Apr 2017 21:54:42 +0200 > On Mon, 24 Apr 2017 14:18:58 -0400 (EDT), David Miller wrote: >> Mon, 24 Apr 2017 19:49:39 +0200, Karim Eshapa wrote: >>> >>> static char pointer creates two variables in final assembly. >>> static string and

Re: [pull request][net 0/7] Mellanox, mlx5 fixes 2017-04-22

From: Saeed Mahameed Date: Sun, 23 Apr 2017 13:07:55 +0300 > This series contains some mlx5 fixes for net. > > For your convenience, the series doesn't introduce any conflict with > the ongoing net-next pull request. > > Please pull and let me know if there's any problem.

RE:PATCH drivers:net:cris/eth_v10: alternate string char arrary

On Mon, 24 Apr 2017 14:18:58 -0400 (EDT), David Miller wrote: > Mon, 24 Apr 2017 19:49:39 +0200, Karim Eshapa wrote: >> >> static char pointer creates two variables in final assembly. >> static string and pointer to it according to >> Jeff Garzik janitors TODO. > > Instead of trusting some

Re: [PATCH 5/7] IB/hfi1: use pcie_flr instead of duplicating it

On 04/24/2017 10:35 AM, Christoph Hellwig wrote: On Mon, Apr 24, 2017 at 02:16:31PM +, Byczkowski, Jakub wrote: Tested-by: Jakub Byczkowski Are you (and Doug) ok with queueing this up in the PCI tree? We are fine however Doug wants to handle it. -Denny

[PATCH] net: hso: fix module unloading

keep tty driver until usb driver is unregistered rmmod hso produces traces like this without that: [40261.645904] usb 2-2: new high-speed USB device number 2 using ehci-omap [40261.854644] usb 2-2: New USB device found, idVendor=0af0, idProduct=8800 [40261.862609] usb 2-2: New USB device strings:

Re: [PATCH 1/1] net: bcmgenet: fix incorrect return value checks

On 04/24/2017 12:48 PM, David Miller wrote: > From: Pan Bian > Date: Sun, 23 Apr 2017 18:01:05 +0800 > >> From: Pan Bian >> >> Function platform_get_irq() will return a negative value on errors. >> However, in function bcmgenet_probe(), 0 is

Re: [PATCH] net: bridge: suppress broadcast when multicast flood is disabled

On 24/04/17 17:09, Mike Manning wrote: > Flood suppression for packets that are not unicast needs to be handled > consistently by also not flooding broadcast packets. As broadcast is a > special case of multicast, the same kernel parameter should be used to > suppress flooding for both of these

Re: [PATCH 1/1] tipc: check return value of nlmsg_new

From: Pan Bian Date: Sun, 23 Apr 2017 15:09:19 +0800 > Function nlmsg_new() will return a NULL pointer if there is no enough > memory, and its return value should be checked before it is used. > However, in function tipc_nl_node_get_monitor(), the validation of the > return

Re: [PATCH 1/1] wan: pc300too: abort path on failure

From: Pan Bian Date: Sun, 23 Apr 2017 17:38:35 +0800 > From: Pan Bian > > In function pc300_pci_init_one(), on the ioremap error path, function > pc300_pci_remove_one() is called to free the allocated memory. However, > the path is not terminated,

Re: [PATCH 1/1] lwtunnel: check return value of nla_nest_start

From: Pan Bian Date: Sun, 23 Apr 2017 14:28:37 +0800 > Function nla_nest_start() may return a NULL pointer on error. However, > in function lwtunnel_fill_encap(), the return value of nla_nest_start() > is not validated before it is used. This patch checks the return value >

Re: [PATCH 1/1] net: bcmgenet: fix incorrect return value checks

From: Pan Bian Date: Sun, 23 Apr 2017 18:01:05 +0800 > From: Pan Bian > > Function platform_get_irq() will return a negative value on errors. > However, in function bcmgenet_probe(), 0 is considered as a flag of > error. This patch fixes the bug by

[stable] Networking security fixes

Please queue up these fixes for 4.10.y: 8605330aac5a tcp: fix SCM_TIMESTAMPING_OPT_STATS for normal skbs 4ef1b2869447 tcp: mark skbs with SCM_TIMESTAMPING_OPT_STATS If I understand correctly, you are no longer sending Greg fixes for 4.4.y or older stable branches, so I'll send stable requests

Re: Get amount of fast retransmissions from TCP info

On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås wrote: > I'm trying to get amount of congestion events in TCP caused by > DUPACK's (fast retransmissions), and can't seem to find any variable > in the TCP info struct which hold that value. There are three > variables

Re: [PATCH v3 net] net: ipv6: regenerate host route if moved to gc list

On 4/24/17 10:39 AM, Eric Dumazet wrote: > > Very nice changelog ! Thanks. Given my aggressive brain cell recycling program, I needed to write down the analysis. >> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c >> index 80ce478c4851..93f81d9cd85f 100644 >> --- a/net/ipv6/addrconf.c

Re: [PATCH 2/2] ixgbe: add support for XDP_TX action

On 17-04-24 12:29 PM, Jesper Dangaard Brouer wrote: > On Sun, 23 Apr 2017 18:31:36 -0700 > John Fastabend wrote: > >> +static int ixgbe_xmit_xdp_ring(struct ixgbe_adapter *adapter, >> + struct xdp_buff *xdp) >> +{ >> +struct ixgbe_ring

Re: [PATCH 2/2] ixgbe: add support for XDP_TX action

On Sun, 23 Apr 2017 18:31:36 -0700 John Fastabend wrote: > +static int ixgbe_xmit_xdp_ring(struct ixgbe_adapter *adapter, > +struct xdp_buff *xdp) > +{ > + struct ixgbe_ring *ring = adapter->xdp_ring[smp_processor_id()]; I was about to

[PATCH] stmmac: Add support for SIMATIC IOT2000 platform

The IOT2000 is industrial controller platform, derived from the Intel Galileo Gen2 board. The variant IOT2020 comes with one LAN port, the IOT2040 has two of them. They can be told apart based on the board asset tag in the DMI table. Based on patch by Sascha Weisenberger. Signed-off-by: Jan

Re: [Intel-wired-lan] [PATCH 1/2] e1000e: Don't return uninitialized stats

From: Benjamin Poirier Date: Mon, 24 Apr 2017 12:01:51 -0700 > On 2017/04/24 10:23, Paul Menzel wrote: >> Dear Benjamin, >> >> >> Thank you for your fix. >> >> On 04/21/17 23:20, Benjamin Poirier wrote: >> > Some statistics passed to ethtool are garbage because

Re: [PATCH v2] brcmfmac: Make skb header writable before use

On 24-4-2017 15:03, James Hughes wrote: > The driver was making changes to the skb_header without > ensuring it was writable (i.e. uncloned). > This patch also removes some boiler plate header size > checking/adjustment code as that is also handled by the > skb_cow_header function used to make

Re: [Intel-wired-lan] [PATCH 1/2] e1000e: Don't return uninitialized stats

Sasha, please use reply-all to keep everyone in cc (including me...). On 2017/04/24 11:17, Neftin, Sasha wrote: > On 4/23/2017 15:53, Neftin, Sasha wrote: > > -Original Message- > > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > > Behalf Of Benjamin Poirier

Re: [Intel-wired-lan] [PATCH 1/2] e1000e: Don't return uninitialized stats

On 2017/04/24 10:23, Paul Menzel wrote: > Dear Benjamin, > > > Thank you for your fix. > > On 04/21/17 23:20, Benjamin Poirier wrote: > > Some statistics passed to ethtool are garbage because e1000e_get_stats64() > > doesn't write them, for example: tx_heartbeat_errors. This leaks kernel > >

Re: [PATCH] net: bridge: suppress broadcast when multicast flood is disabled

On Mon, 24 Apr 2017 15:09:04 +0100 Mike Manning wrote: > Flood suppression for packets that are not unicast needs to be handled > consistently by also not flooding broadcast packets. As broadcast is a > special case of multicast, the same kernel parameter should be used to

Re: [PATCH v2] brcmfmac: Make skb header writable before use

On 24-4-2017 20:09, Eric Dumazet wrote: > On Mon, 2017-04-24 at 14:03 +0100, James Hughes wrote: >> The driver was making changes to the skb_header without >> ensuring it was writable (i.e. uncloned). >> This patch also removes some boiler plate header size >> checking/adjustment code as that is

Re: [iproute PATCH] man: ip-rule.8: Further clarify how to interpret priority value

On Mon, 24 Apr 2017 17:35:37 +0200 Phil Sutter wrote: > Despite the past changes, users seemed to get confused by the seemingly > contradictory relation of priority value and actual rule priority. > > Signed-off-by: Phil Sutter Makes sense. Applied.

  1   2   3   >