* [PATCH] net: ethernet: sun: niu set correct packet size in skb
From: Rob Taglang @ 2018-05-03 21:13 UTC (permalink / raw)
To: netdev; +Cc: davem
Currently, skb->len and skb->data_len are set to the page size, not the
packet size. This causes the frame check sequence to not be located at
the "end" of the packet resulting in ethernet frame check errors. The
driver does work currently, but stricter kernel facing networking
solutions like OpenVSwitch will drop these packets as invalid.
These changes set the packet size correctly so that these errors no
longer occur. The length does not include the frame check sequence, so
that subtraction was removed.
Tested on Oracle/SUN Multithreaded 10-Gigabit Ethernet Network
Controller [108e:abcd] and validated in wireshark.
Signed-off-by: Rob Taglang <rob@taglang.io>
---
drivers/net/ethernet/sun/niu.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/sun/niu.c
b/drivers/net/ethernet/sun/niu.c
index f081de4..88c1247 100644
--- a/drivers/net/ethernet/sun/niu.c
+++ b/drivers/net/ethernet/sun/niu.c
@@ -3443,7 +3443,7 @@ static int niu_process_rx_pkt(struct napi_struct
*napi, struct niu *np,
len = (val & RCR_ENTRY_L2_LEN) >>
RCR_ENTRY_L2_LEN_SHIFT;
- len -= ETH_FCS_LEN;
+ append_size = len + ETH_HLEN + ETH_FCS_LEN;
addr = (val & RCR_ENTRY_PKT_BUF_ADDR) <<
RCR_ENTRY_PKT_BUF_ADDR_SHIFT;
@@ -3453,7 +3453,6 @@ static int niu_process_rx_pkt(struct napi_struct
*napi, struct niu *np,
RCR_ENTRY_PKTBUFSZ_SHIFT];
off = addr & ~PAGE_MASK;
- append_size = rcr_size;
if (num_rcr == 1) {
int ptype;
@@ -3466,7 +3465,7 @@ static int niu_process_rx_pkt(struct napi_struct
*napi, struct niu *np,
else
skb_checksum_none_assert(skb);
} else if (!(val & RCR_ENTRY_MULTI))
- append_size = len - skb->len;
+ append_size = append_size - skb->len;
niu_rx_skb_append(skb, page, off, append_size, rcr_size);
if ((page->index + rp->rbr_block_size) - rcr_size == addr) {
^ permalink raw reply related
* Re: [PATCH rdma-next] MAINTAINERS: Remove bouncing @mellanox.com addresses
From: Or Gerlitz @ 2018-05-03 21:11 UTC (permalink / raw)
To: Linux Netdev List, RDMA mailing list; +Cc: Jason Gunthorpe
In-Reply-To: <20180503183746.7629-1-leon@kernel.org>
On Thu, May 3, 2018 at 9:37 PM, LR wrote:
> MELLANOX MLX5 core VPI driver
> M: Saeed Mahameed <saeedm@mellanox.com>
> -M: Matan Barak <matanb@mellanox.com>
Goodbye Matan!
You were a long time developer, maintainer, hacker and a very deeply thinking,
pleasant, nice and open person in our team, enjoy your new adventures and thanks
a lot for your long time contributions to the upstream kernel
Or.
^ permalink raw reply
* Re: DSA switch
From: Andrew Lunn @ 2018-05-03 21:05 UTC (permalink / raw)
To: Ran Shalit; +Cc: netdev
In-Reply-To: <CAJ2oMhK-rMNF=osQ0B9wLoqL+pYEevgmHfbv2vO5Vho0DFpthw@mail.gmail.com>
> I am using kernel 2.6.37, but I think it is not kernel issue, but more
> bad patches done on kernel.
> It is based on TI's kernel, but with some custom modifications on
> driver's switch, to make it work with TI's cpsw switch.
> Seems like someone made some bad patch, I'll continue investigating it.
> You can ignore the question...
>
> Many thanks a lot for the help,
> Ran
There is no DSA driver for the cpsw. Are you just using the cpsw to
pass frames to a switch which is supported by DSA?
In theory, mainline CPSW should just work for passing frames to an
external switch. So why not just use mainline?
Andrew
^ permalink raw reply
* Re: DSA switch
From: Ran Shalit @ 2018-05-03 20:56 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20180503204150.GH17027@lunn.ch>
On Thu, May 3, 2018 at 11:41 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Thu, May 03, 2018 at 11:35:08PM +0300, Ran Shalit wrote:
>> On Wed, May 2, 2018 at 11:56 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> > On Wed, May 02, 2018 at 11:20:05PM +0300, Ran Shalit wrote:
>> >> Hello,
>> >>
>> >> Is it possible to use switch just like external real switch,
>> >> connecting all ports to the same subnet ?
>> >
>> > Yes. Just bridge all ports/interfaces together and put your host IP
>> > address on the bridge.
>>
>> I also noticed that even before making the bridge connection between
>> all "lanX" interfaces, the ports already communicates with each other
>
> That should not happen. They should be isolated.
>
> What kernel version are you using?
>
I am using kernel 2.6.37, but I think it is not kernel issue, but more
bad patches done on kernel.
It is based on TI's kernel, but with some custom modifications on
driver's switch, to make it work with TI's cpsw switch.
Seems like someone made some bad patch, I'll continue investigating it.
You can ignore the question...
Many thanks a lot for the help,
Ran
^ permalink raw reply
* Re: [PATCH] net: ethernet: sun: niu set correct packet size in skb
From: David Miller @ 2018-05-03 20:55 UTC (permalink / raw)
To: rob; +Cc: netdev, netdev-owner
In-Reply-To: <ed59658e880ef62c2304399c90b033fb@taglang.io>
From: rob@taglang.io
Date: Thu, 03 May 2018 16:38:04 -0400
> Ah, gotcha. Should I make a new thread?
Yes, please do.
Thank you.
^ permalink raw reply
* Charity Gift !!!
From: Mrs Mavis L. Wanczyk @ 2018-05-03 12:01 UTC (permalink / raw)
--
This is the second time i am sending you this mail.
I, Mavis Wanczyk donates $ 5 Million Dollars from part of my Powerball
Jackpot Lottery of $ 758 Million Dollars, respond with your details
for claims.
I await your earliest response and God Bless you
Good luck.
Mavis Wanczyk
^ permalink raw reply
* Re: DSA switch
From: Andrew Lunn @ 2018-05-03 20:41 UTC (permalink / raw)
To: Ran Shalit; +Cc: netdev
In-Reply-To: <CAJ2oMhLevtq9MNwQegstO9d69CxFiuRCky+qszbXig=peUFNoA@mail.gmail.com>
On Thu, May 03, 2018 at 11:35:08PM +0300, Ran Shalit wrote:
> On Wed, May 2, 2018 at 11:56 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > On Wed, May 02, 2018 at 11:20:05PM +0300, Ran Shalit wrote:
> >> Hello,
> >>
> >> Is it possible to use switch just like external real switch,
> >> connecting all ports to the same subnet ?
> >
> > Yes. Just bridge all ports/interfaces together and put your host IP
> > address on the bridge.
>
> I also noticed that even before making the bridge connection between
> all "lanX" interfaces, the ports already communicates with each other
That should not happen. They should be isolated.
What kernel version are you using?
Andrew
^ permalink raw reply
* Re: [PATCH] net: ethernet: sun: niu set correct packet size in skb
From: rob @ 2018-05-03 20:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev, netdev-owner
In-Reply-To: <20180503.160455.1091782405023067534.davem@davemloft.net>
Ah, gotcha. Should I make a new thread?
Patch should be properly formatted below.
Thanks,
Rob
Signed-off-by: Rob Taglang <rob@taglang.io>
---
drivers/net/ethernet/sun/niu.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/sun/niu.c
b/drivers/net/ethernet/sun/niu.c
index f081de4..88c1247 100644
--- a/drivers/net/ethernet/sun/niu.c
+++ b/drivers/net/ethernet/sun/niu.c
@@ -3443,7 +3443,7 @@ static int niu_process_rx_pkt(struct napi_struct
*napi, struct niu *np,
len = (val & RCR_ENTRY_L2_LEN) >>
RCR_ENTRY_L2_LEN_SHIFT;
- len -= ETH_FCS_LEN;
+ append_size = len + ETH_HLEN + ETH_FCS_LEN;
addr = (val & RCR_ENTRY_PKT_BUF_ADDR) <<
RCR_ENTRY_PKT_BUF_ADDR_SHIFT;
@@ -3453,7 +3453,6 @@ static int niu_process_rx_pkt(struct napi_struct
*napi, struct niu *np,
RCR_ENTRY_PKTBUFSZ_SHIFT];
off = addr & ~PAGE_MASK;
- append_size = rcr_size;
if (num_rcr == 1) {
int ptype;
@@ -3466,7 +3465,7 @@ static int niu_process_rx_pkt(struct napi_struct
*napi, struct niu *np,
else
skb_checksum_none_assert(skb);
} else if (!(val & RCR_ENTRY_MULTI))
- append_size = len - skb->len;
+ append_size = append_size - skb->len;
niu_rx_skb_append(skb, page, off, append_size, rcr_size);
if ((page->index + rp->rbr_block_size) - rcr_size == addr) {
On 2018-05-03 16:04, David Miller wrote:
> From: Rob Taglang <rob@taglang.io>
> Date: Thu, 03 May 2018 11:06:04 -0400
>
>> Currently, skb->len and skb->data_len are set to the page size, not
>> the packet size. This causes the frame check sequence to not be
>> located at the "end" of the packet resulting in ethernet frame check
>> errors. The driver does work currently, but stricter kernel facing
>> networking solutions like OpenVSwitch will drop these packets as
>> invalid.
>>
>> These changes set the packet size correctly so that these errors no
>> longer occur. The length does not include the frame check sequence, so
>> that subtraction was removed.
>>
>> Tested on Oracle/SUN Multithreaded 10-Gigabit Ethernet Network
>> Controller [108e:abcd].
>>
>> This is a resubmission after subscribing to the list; I think it got
>> caught in a spam filter since I can't see my message in the archive,
>> but if not and this is just pissing off a maintainer I'm really sorry.
>>
>> Signed-off-by: Rob Taglang <rob@taglang.io>
>> ---
>> drivers/net/ethernet/sun/niu.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/sun/niu.c
>> b/drivers/net/ethernet/sun/niu.c
>> index f081de4..88c1247 100644
>> --- a/drivers/net/ethernet/sun/niu.c
>> +++ b/drivers/net/ethernet/sun/niu.c
>> @@ -3443,7 +3443,7 @@ static int niu_process_rx_pkt(struct napi_struct
>> *napi, struct niu *np,
>>
>> len = (val & RCR_ENTRY_L2_LEN) >>
>> RCR_ENTRY_L2_LEN_SHIFT;
>> - len -= ETH_FCS_LEN;
>> + append_size = len + ETH_HLEN + ETH_FCS_LEN;
>
> This patch is severely corrupted by your email client.
>
> Please fix this, send the patch to yourself as a test, and only repost
> the patch here on the list once you can successfully apply the patch
> contained in the test email.
>
> Thanks.
^ permalink raw reply related
* [PATCH net] nsh: fix infinite loop
From: Eric Dumazet @ 2018-05-03 20:37 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet, Jiri Benc
syzbot caught an infinite recursion in nsh_gso_segment().
Problem here is that we need to make sure the NSH header is of
reasonable length.
BUG: MAX_LOCK_DEPTH too low!
turning off the locking correctness validator.
depth: 48 max: 48!
48 locks held by syz-executor0/10189:
#0: (ptrval) (rcu_read_lock_bh){....}, at: __dev_queue_xmit+0x30f/0x34c0 net/core/dev.c:3517
#1: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#1: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#2: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#2: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#3: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#3: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#4: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#4: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#5: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#5: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#6: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#6: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#7: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#7: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#8: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#8: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#9: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#9: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#10: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#10: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#11: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#11: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#12: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#12: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#13: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#13: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#14: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#14: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#15: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#15: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#16: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#16: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#17: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#17: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#18: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#18: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#19: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#19: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#20: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#20: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#21: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#21: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#22: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#22: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#23: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#23: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#24: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#24: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#25: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#25: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#26: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#26: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#27: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#27: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#28: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#28: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#29: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#29: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#30: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#30: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#31: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#31: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
dccp_close: ABORT with 65423 bytes unread
#32: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#32: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#33: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#33: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#34: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#34: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#35: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#35: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#36: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#36: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#37: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#37: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#38: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#38: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#39: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#39: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#40: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#40: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#41: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#41: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#42: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#42: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#43: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#43: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#44: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#44: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#45: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#45: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#46: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#46: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
#47: (ptrval) (rcu_read_lock){....}, at: __skb_pull include/linux/skbuff.h:2080 [inline]
#47: (ptrval) (rcu_read_lock){....}, at: skb_mac_gso_segment+0x221/0x720 net/core/dev.c:2787
INFO: lockdep is turned off.
CPU: 1 PID: 10189 Comm: syz-executor0 Not tainted 4.17.0-rc2+ #26
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
__lock_acquire+0x1788/0x5140 kernel/locking/lockdep.c:3449
lock_acquire+0x1dc/0x520 kernel/locking/lockdep.c:3920
rcu_lock_acquire include/linux/rcupdate.h:246 [inline]
rcu_read_lock include/linux/rcupdate.h:632 [inline]
skb_mac_gso_segment+0x25b/0x720 net/core/dev.c:2789
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
nsh_gso_segment+0x405/0xb60 net/nsh/nsh.c:107
skb_mac_gso_segment+0x3ad/0x720 net/core/dev.c:2792
__skb_gso_segment+0x3bb/0x870 net/core/dev.c:2865
skb_gso_segment include/linux/netdevice.h:4025 [inline]
validate_xmit_skb+0x54d/0xd90 net/core/dev.c:3118
validate_xmit_skb_list+0xbf/0x120 net/core/dev.c:3168
sch_direct_xmit+0x354/0x11e0 net/sched/sch_generic.c:312
qdisc_restart net/sched/sch_generic.c:399 [inline]
__qdisc_run+0x741/0x1af0 net/sched/sch_generic.c:410
__dev_xmit_skb net/core/dev.c:3243 [inline]
__dev_queue_xmit+0x28ea/0x34c0 net/core/dev.c:3551
dev_queue_xmit+0x17/0x20 net/core/dev.c:3616
packet_snd net/packet/af_packet.c:2951 [inline]
packet_sendmsg+0x40f8/0x6070 net/packet/af_packet.c:2976
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:639
__sys_sendto+0x3d7/0x670 net/socket.c:1789
__do_sys_sendto net/socket.c:1801 [inline]
__se_sys_sendto net/socket.c:1797 [inline]
__x64_sys_sendto+0xe1/0x1a0 net/socket.c:1797
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Fixes: c411ed854584 ("nsh: add GSO support")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jiri Benc <jbenc@redhat.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
---
net/nsh/nsh.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/nsh/nsh.c b/net/nsh/nsh.c
index d7da99a0b0b852d7459eed9ac6d3cdf3d49a1a1c..9696ef96b719bf24625adea2a959deac1d2a975f 100644
--- a/net/nsh/nsh.c
+++ b/net/nsh/nsh.c
@@ -57,6 +57,8 @@ int nsh_pop(struct sk_buff *skb)
return -ENOMEM;
nh = (struct nshhdr *)(skb->data);
length = nsh_hdr_len(nh);
+ if (length < NSH_BASE_HDR_LEN)
+ return -EINVAL;
inner_proto = tun_p_to_eth_p(nh->np);
if (!pskb_may_pull(skb, length))
return -ENOMEM;
@@ -90,6 +92,8 @@ static struct sk_buff *nsh_gso_segment(struct sk_buff *skb,
if (unlikely(!pskb_may_pull(skb, NSH_BASE_HDR_LEN)))
goto out;
nsh_len = nsh_hdr_len(nsh_hdr(skb));
+ if (nsh_len < NSH_BASE_HDR_LEN)
+ goto out;
if (unlikely(!pskb_may_pull(skb, nsh_len)))
goto out;
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* Re: DSA switch
From: Ran Shalit @ 2018-05-03 20:35 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20180502205620.GE24748@lunn.ch>
On Wed, May 2, 2018 at 11:56 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Wed, May 02, 2018 at 11:20:05PM +0300, Ran Shalit wrote:
>> Hello,
>>
>> Is it possible to use switch just like external real switch,
>> connecting all ports to the same subnet ?
>
> Yes. Just bridge all ports/interfaces together and put your host IP
> address on the bridge.
I also noticed that even before making the bridge connection between
all "lanX" interfaces, the ports already communicates with each other
(ping between PCs connected to other ports work).
It is only that communication to cpu was not functioning, till I made
the bridge connection.
Is this the normal behavior (or is it that for some reason my switch
behaves different) ? I mean, is it usually by default "flat switch
except cpu" ?
Regards,
Ran
>
> Andrew
^ permalink raw reply
* Re: [PATCH net-next 0/4] net/smc: splice implementation
From: David Miller @ 2018-05-03 20:31 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl
In-Reply-To: <20180503161239.71747-1-ubraun@linux.ibm.com>
From: Ursula Braun <ubraun@linux.ibm.com>
Date: Thu, 3 May 2018 18:12:35 +0200
> From: Ursula Braun <ursula.braun@de.ibm.com>
>
> Dave,
>
> Stefan comes up with an smc implementation for splice(). The first
> three patches are preparational patches, the 4th patch implements
> splice().
Doesn't look too bad :)
Series applied, thanks.
^ permalink raw reply
* RE: [PATCH v6 0/5] PCI: Improve PCIe link status reporting
From: Keller, Jacob E @ 2018-05-03 20:29 UTC (permalink / raw)
To: Bjorn Helgaas, Kirsher, Jeffrey T, Ganesh Goudar, Michael Chan,
Ariel Elior
Cc: linux-pci@vger.kernel.org, everest-linux-l2@cavium.com,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Tal Gilboa, Tariq Toukan,
Jakub Kicinski
In-Reply-To: <152537719056.62474.2571390812509425478.stgit@bhelgaas-glaptop.roam.corp.google.com>
> -----Original Message-----
> This does change the dmesg reporting of link speeds, and in the ixgbe case,
> it changes the reporting from KERN_WARN level to KERN_INFO. If that's an
> issue, let's talk about it. I'm hoping the reduce code size, improved
> functionality, and consistency across drivers is enough to make this
> worthwhile.
>
I personally have no issue with this change, but I don't work on the ixgbe driver much anymore.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH net] macmace: Set platform device coherent_dma_mask
From: Michael Schmitz @ 2018-05-03 20:24 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Geert Uytterhoeven, Finn Thain, David S. Miller, linux-m68k,
netdev, Linux Kernel Mailing List
In-Reply-To: <20180503085120.GA14574@lst.de>
Hi Christoph,
On Thu, May 3, 2018 at 8:51 PM, Christoph Hellwig <hch@lst.de> wrote:
> On Thu, May 03, 2018 at 10:46:56AM +0200, Geert Uytterhoeven wrote:
>> Perhaps you can add a new helper (platform_device_register_simple_dma()?)
>> that takes the DMA mask, too?
>> With people setting the mask to kill the WARNING splat, this may become
>> more common.
>>
>> struct platform_device_info already has a dma_mask field, but
>> platform_device_register_resndata() explicitly sets it to zero.
>
> Yes, that would be useful. The other assumption could be that
> platform devices always allow an all-0xff dma mask.
That's not always true (Atari NCR5380 SCSI and floppy would use a 24
bit DMA mask). We use bounce buffers allocated from a dedicated lowmem
pool there currently, and for all I know don't use the DMA API yet.
I bet that is a rare exception though. Setting the default DMA mask
for platform devices to all-0xff and letting the few odd drivers force
a different setting seems the best way forward.
Cheers,
Michael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2018-05-03 20:21 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Various sockmap fixes from John Fastabend (pinned map handling, blocking
in recvmsg, double page put, error handling during redirect failures, etc.)
2) Fix dead code handling in x86-64 JIT, from Gianluca Borello.
3) Missing device put in RDS IB code, from Dag Moxnes.
4) Don't process fast open during repair mode in TCP< from Yuchung
Cheng.
5) Move address/port comparison fixes in SCTP, from Xin Long.
6) Handle add a bond slave's master into a bridge properly, from
Hangbin Liu.
7) IPv6 multipath code can operate on unitialized memory due to an
assumption that the icmp header is in the linear SKB area. Fix
from Eric Dumazet.
8) Don't invoke do_tcp_sendpages() recursively via TLS, from Dave
Watson.
9) Fix memory leaks in x86-64 JIT, from Daniel Borkmann.
10) RDS leaks kernel memory to userspace, from Eric Dumazet.
11) DCCP can invoke a tasklet on a freed socket, take a refcount.
Also from Eric Dumazet.
Please pull, thanks a lot!
The following changes since commit 3be4aaf4e2d3eb95cce7835e8df797ae65ae5ac1:
Merge branch 'userns-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace (2018-04-24 17:58:51 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
for you to fetch changes up to a8d7aa17bbc970971ccdf71988ea19230ab368b1:
dccp: fix tasklet usage (2018-05-03 15:14:57 -0400)
----------------------------------------------------------------
Alexandre Belloni (1):
net: phy: allow scanning busses with missing phys
Alexei Starovoitov (2):
Merge branch 'x86-bpf-jit-fixes'
Merge branch 'bpf-sockmap-fixes'
Anders Roxell (1):
selftests: net: add in_netns.sh TEST_GEN_PROGS_EXTENDED
Arend Van Spriel (1):
brcmfmac: fix firmware request processing if nvram load fails
Bjørn Mork (1):
qmi_wwan: do not steal interfaces from class drivers
Chris Mi (1):
net/mlx5: Properly deal with flow counters when deleting rules
Colin Ian King (6):
net: systemport: fix spelling mistake: "asymetric" -> "asymmetric"
qed: fix spelling mistake: "checksumed" -> "checksummed"
net: ethernet: ucc: fix spelling mistake: "tx-late-collsion" -> "tx-late-collision"
net/mlx4: fix spelling mistake: "failedi" -> "failed"
net/mlx5e: fix spelling mistake: "loobpack" -> "loopback"
qed: fix spelling mistake: "offloded" -> "offloaded"
Dag Moxnes (1):
rds: ib: Fix missing call to rds_ib_dev_put in rds_ib_setup_qp
Daniel Borkmann (3):
Merge branch 'bpf-sockmap-fixes'
bpf, x64: fix memleak when not converging after image
bpf, x64: fix memleak when not converging on calls
Dave Watson (1):
net/tls: Don't recursively call push_record during tls_write_space callbacks
David S. Miller (7):
Merge git://git.kernel.org/.../bpf/bpf
Merge branch 'mvpp2-fixes'
Merge tag 'wireless-drivers-for-davem-2018-04-26' of git://git.kernel.org/.../kvalo/wireless-drivers
Merge tag 'mlx5-fixes-2018-04-25' of git://git.kernel.org/.../saeed/linux
Merge branch 'sfc-more-ARFS-fixes'
Merge git://git.kernel.org/.../bpf/bpf
Merge branch 'smc-fixes'
Edward Cree (2):
sfc: Use filter index rather than ID for rps_flow_id table
sfc: fix ARFS expiry check on EF10
Eric Dumazet (6):
ipv6: fix uninit-value in ip6_multipath_l3_keys()
tcp: fix TCP_REPAIR_QUEUE bound checking
net_sched: fq: take care of throttled flows before reuse
rds: do not leak kernel memory to user land
tcp: restore autocorking
dccp: fix tasklet usage
Florian Fainelli (1):
net: systemport: Correclty disambiguate driver instances
Gianluca Borello (1):
bpf, x64: fix JIT emission for dead code
Grygorii Strashko (1):
net: ethernet: ti: cpsw: fix packet leaking in dual_mac mode
Haim Dreyfuss (1):
iwlwifi: mvm: query regdb for wmm rule if needed
Hangbin Liu (1):
bridge: check iface upper dev when setting master via ioctl
Huy Nguyen (1):
net/mlx5e: DCBNL fix min inline header size for dscp
Ido Schimmel (2):
mlxsw: spectrum_switchdev: Do not remove mrouter port from MDB's ports list
ipv6: Revert "ipv6: Allow non-gateway ECMP for IPv6"
Ingo Molnar (1):
8139too: Use disable_irq_nosync() in rtl8139_poll_controller()
Israel Rukshin (1):
net/mlx5: Fix mlx5_get_vector_affinity function
Jakub Kicinski (1):
nfp: don't depend on eth_tbl being available
Jianbo Liu (1):
net/mlx5e: Allow offloading ipv4 header re-write for icmp
John Fastabend (10):
bpf: Document sockmap '-target bpf' requirement for PROG_TYPE_SK_MSG
bpf: sockmap sample use clang flag, -target bpf
bpf: sockmap, map_release does not hold refcnt for pinned maps
bpf: sockmap, sk_wait_event needed to handle blocking cases
bpf: sockmap, fix double page_put on ENOMEM error in redirect path
bpf: fix for lex/yacc build error with gcc-5
bpf: fix uninitialized variable in bpf tools
bpf: sockmap, fix scatterlist update on error path in send with apply
bpf: sockmap, zero sg_size on error when buffer is released
bpf: sockmap, fix error handling in redirect failures
John Hurley (1):
nfp: flower: set tunnel ttl value to net default
Jon Maloy (1):
tipc: fix bug in function tipc_nl_node_dump_monitor
Julian Anastasov (1):
ipv4: fix fnhe usage by non-cached routes
Karsten Graul (2):
net/smc: call consolidation
net/smc: handle unregistered buffers
Lance Richardson (1):
net: support compat 64-bit time in {s,g}etsockopt
Luca Coelho (1):
iwlwifi: mvm: fix old scan version sizes
Marcelo Ricardo Leitner (1):
MAINTAINERS: add myself as SCTP co-maintainer
Maxime Chevallier (2):
net: mvpp2: Fix clk error path in mvpp2_probe
net: mvpp2: Fix clock resource by adding missing mg_core_clk
Michael S. Tsirkin (2):
vhost: make msg padding explicit
Revert "vhost: make msg padding explicit"
Neal Cardwell (1):
tcp_bbr: fix to zero idle_restart only upon S/ACKed data
Ping-Ke Shih (1):
rtlwifi: cleanup 8723be ant_sel definition
Roman Gushchin (1):
bpf: disable and restore preemption in __BPF_PROG_RUN_ARRAY
SZ Lin (林上智) (1):
NET: usb: qmi_wwan: add support for ublox R410M PID 0x90b2
Shahar Klein (1):
net/mlx5e: Fix traffic between VF and representor
Song Liu (1):
bpf: minor fix to selftest test_stacktrace_build_id()
Stefan Raspl (1):
smc: fix sendpage() call
Talat Batheesh (1):
net/mlx5: Avoid cleaning flow steering table twice during error flow
Tariq Toukan (1):
net/mlx5e: TX, Use correct counter in dma_map error flow
Thomas Winter (1):
ipv6: Allow non-gateway ECMP for IPv6
Ursula Braun (2):
net/smc: keep clcsock reference in smc_tcp_listen_work()
net/smc: restrict non-blocking connect finish
Vivien Didelot (1):
MAINTAINERS: add davem in NETWORKING DRIVERS
Wenwen Wang (1):
ethtool: fix a potential missing-check bug
William Tu (1):
bpf: clear the ip_tunnel_info.
Xin Long (5):
sctp: handle two v4 addrs comparison in sctp_inet6_cmp_addr
sctp: clear the new asoc's stream outcnt in sctp_stream_update
sctp: init active key for the new asoc in dupcook_a and dupcook_b
sctp: use the old asoc when making the cookie-ack chunk in dupcook_d
sctp: fix the issue that the cookie-ack with auth can't get processed
Yuchung Cheng (1):
tcp: ignore Fast Open on repair mode
Documentation/bpf/bpf_devel_QA.txt | 10 +++++++-
MAINTAINERS | 2 ++
arch/x86/net/bpf_jit_comp.c | 18 +++++++++++---
drivers/infiniband/hw/mlx5/main.c | 2 +-
drivers/net/ethernet/broadcom/bcmsysport.c | 18 ++++++++++----
drivers/net/ethernet/freescale/ucc_geth_ethtool.c | 2 +-
drivers/net/ethernet/marvell/mvpp2.c | 30 ++++++++++++++++------
drivers/net/ethernet/mellanox/mlx4/main.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 8 +++---
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 5 ++--
drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 3 ++-
drivers/net/ethernet/mellanox/mlx5/core/en_tx.c | 20 +++++++--------
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 26 +++++++++++--------
drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 12 ++++-----
drivers/net/ethernet/netronome/nfp/flower/action.c | 10 ++++++--
drivers/net/ethernet/netronome/nfp/flower/cmsg.h | 5 +++-
drivers/net/ethernet/netronome/nfp/flower/main.c | 2 +-
drivers/net/ethernet/netronome/nfp/nfp_app_nic.c | 2 +-
drivers/net/ethernet/netronome/nfp/nfp_main.h | 4 ++-
drivers/net/ethernet/netronome/nfp/nfp_net_main.c | 31 +++++++++++++----------
drivers/net/ethernet/qlogic/qed/qed_ll2.c | 2 +-
drivers/net/ethernet/qlogic/qed/qed_roce.c | 2 +-
drivers/net/ethernet/realtek/8139too.c | 2 +-
drivers/net/ethernet/sfc/ef10.c | 5 ++--
drivers/net/ethernet/sfc/rx.c | 2 ++
drivers/net/ethernet/ti/cpsw.c | 2 ++
drivers/net/phy/phy_device.c | 11 ++++++++-
drivers/net/usb/qmi_wwan.c | 13 ++++++++++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 36 +++++++++++++++------------
drivers/net/wireless/intel/iwlwifi/fw/api/scan.h | 13 ++++------
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 111 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.h | 6 +++--
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 3 ++-
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 15 -----------
drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 11 ++++++---
drivers/net/wireless/realtek/rtlwifi/wifi.h | 5 ++++
include/linux/bpf.h | 4 ++-
include/linux/mlx5/driver.h | 12 +++------
include/net/tls.h | 1 +
kernel/bpf/arraymap.c | 3 ++-
kernel/bpf/sockmap.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------
kernel/bpf/syscall.c | 4 +--
net/bridge/br_if.c | 4 +--
net/compat.c | 6 +++--
net/core/ethtool.c | 5 ++++
net/core/filter.c | 1 +
net/dccp/ccids/ccid2.c | 14 +++++++++--
net/dccp/timer.c | 2 +-
net/ipv4/route.c | 118 +++++++++++++++++++++++++++++++++++++++------------------------------------------------
net/ipv4/tcp.c | 7 +++---
net/ipv4/tcp_bbr.c | 4 ++-
net/ipv6/route.c | 7 +++++-
net/rds/ib_cm.c | 3 ++-
net/rds/recv.c | 1 +
net/sched/sch_fq.c | 37 ++++++++++++++++++---------
net/sctp/inqueue.c | 2 +-
net/sctp/ipv6.c | 3 +++
net/sctp/sm_statefuns.c | 8 +++++-
net/sctp/stream.c | 2 ++
net/smc/af_smc.c | 61 ++++++++++++++++++++++-----------------------
net/smc/smc_core.c | 22 ++++++++++++++---
net/smc/smc_core.h | 3 ++-
net/tipc/node.c | 2 +-
net/tls/tls_main.c | 7 ++++++
samples/sockmap/Makefile | 7 ++++--
tools/bpf/Makefile | 2 ++
tools/bpf/bpf_dbg.c | 7 ++++--
tools/testing/selftests/bpf/test_progs.c | 4 +--
tools/testing/selftests/net/Makefile | 3 ++-
70 files changed, 602 insertions(+), 316 deletions(-)
^ permalink raw reply
* Re: [PATCH] net: ethernet: sun: niu set correct packet size in skb
From: David Miller @ 2018-05-03 20:04 UTC (permalink / raw)
To: rob; +Cc: netdev
In-Reply-To: <1525359964.11695.1@server175.web-hosting.com>
From: Rob Taglang <rob@taglang.io>
Date: Thu, 03 May 2018 11:06:04 -0400
> Currently, skb->len and skb->data_len are set to the page size, not
> the packet size. This causes the frame check sequence to not be
> located at the "end" of the packet resulting in ethernet frame check
> errors. The driver does work currently, but stricter kernel facing
> networking solutions like OpenVSwitch will drop these packets as
> invalid.
>
> These changes set the packet size correctly so that these errors no
> longer occur. The length does not include the frame check sequence, so
> that subtraction was removed.
>
> Tested on Oracle/SUN Multithreaded 10-Gigabit Ethernet Network
> Controller [108e:abcd].
>
> This is a resubmission after subscribing to the list; I think it got
> caught in a spam filter since I can't see my message in the archive,
> but if not and this is just pissing off a maintainer I'm really sorry.
>
> Signed-off-by: Rob Taglang <rob@taglang.io>
> ---
> drivers/net/ethernet/sun/niu.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/sun/niu.c
> b/drivers/net/ethernet/sun/niu.c
> index f081de4..88c1247 100644
> --- a/drivers/net/ethernet/sun/niu.c
> +++ b/drivers/net/ethernet/sun/niu.c
> @@ -3443,7 +3443,7 @@ static int niu_process_rx_pkt(struct napi_struct
> *napi, struct niu *np,
>
> len = (val & RCR_ENTRY_L2_LEN) >>
> RCR_ENTRY_L2_LEN_SHIFT;
> - len -= ETH_FCS_LEN;
> + append_size = len + ETH_HLEN + ETH_FCS_LEN;
This patch is severely corrupted by your email client.
Please fix this, send the patch to yourself as a test, and only repost
the patch here on the list once you can successfully apply the patch
contained in the test email.
Thanks.
^ permalink raw reply
* [PATCH v6 5/5] PCI: Remove unused pcie_get_minimum_link()
From: Bjorn Helgaas @ 2018-05-03 20:00 UTC (permalink / raw)
To: Jeff Kirsher, Ganesh Goudar, Michael Chan, Ariel Elior
Cc: linux-pci, everest-linux-l2, intel-wired-lan, netdev,
linux-kernel, Tal Gilboa, Tariq Toukan, Jacob Keller,
Jakub Kicinski
In-Reply-To: <152537719056.62474.2571390812509425478.stgit@bhelgaas-glaptop.roam.corp.google.com>
From: Bjorn Helgaas <bhelgaas@google.com>
In some cases pcie_get_minimum_link() returned misleading information
because it found the slowest link and the narrowest link without
considering the total bandwidth of the link.
For example, consider a path with these two links:
- 16.0 GT/s x1 link (16.0 * 10^9 * 128 / 130) * 1 / 8 = 1969 MB/s
- 2.5 GT/s x16 link ( 2.5 * 10^9 * 8 / 10) * 16 / 8 = 4000 MB/s
The available bandwidth of the path is limited by the 16 GT/s link to about
1969 MB/s, but pcie_get_minimum_link() returned 2.5 GT/s x1, which
corresponds to only 250 MB/s.
Callers should use pcie_print_link_status() instead, or
pcie_bandwidth_available() if they need more detailed information.
Remove pcie_get_minimum_link() since there are no callers left.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/pci/pci.c | 43 -------------------------------------------
include/linux/pci.h | 2 --
2 files changed, 45 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index e597655a5643..4bafa817c40a 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5069,49 +5069,6 @@ int pcie_set_mps(struct pci_dev *dev, int mps)
}
EXPORT_SYMBOL(pcie_set_mps);
-/**
- * pcie_get_minimum_link - determine minimum link settings of a PCI device
- * @dev: PCI device to query
- * @speed: storage for minimum speed
- * @width: storage for minimum width
- *
- * This function will walk up the PCI device chain and determine the minimum
- * link width and speed of the device.
- */
-int pcie_get_minimum_link(struct pci_dev *dev, enum pci_bus_speed *speed,
- enum pcie_link_width *width)
-{
- int ret;
-
- *speed = PCI_SPEED_UNKNOWN;
- *width = PCIE_LNK_WIDTH_UNKNOWN;
-
- while (dev) {
- u16 lnksta;
- enum pci_bus_speed next_speed;
- enum pcie_link_width next_width;
-
- ret = pcie_capability_read_word(dev, PCI_EXP_LNKSTA, &lnksta);
- if (ret)
- return ret;
-
- next_speed = pcie_link_speed[lnksta & PCI_EXP_LNKSTA_CLS];
- next_width = (lnksta & PCI_EXP_LNKSTA_NLW) >>
- PCI_EXP_LNKSTA_NLW_SHIFT;
-
- if (next_speed < *speed)
- *speed = next_speed;
-
- if (next_width < *width)
- *width = next_width;
-
- dev = dev->bus->self;
- }
-
- return 0;
-}
-EXPORT_SYMBOL(pcie_get_minimum_link);
-
/**
* pcie_bandwidth_available - determine minimum link settings of a PCIe
* device and its bandwidth limitation
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 73178a2fcee0..230615620a4a 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1079,8 +1079,6 @@ int pcie_get_readrq(struct pci_dev *dev);
int pcie_set_readrq(struct pci_dev *dev, int rq);
int pcie_get_mps(struct pci_dev *dev);
int pcie_set_mps(struct pci_dev *dev, int mps);
-int pcie_get_minimum_link(struct pci_dev *dev, enum pci_bus_speed *speed,
- enum pcie_link_width *width);
u32 pcie_bandwidth_available(struct pci_dev *dev, struct pci_dev **limiting_dev,
enum pci_bus_speed *speed,
enum pcie_link_width *width);
^ permalink raw reply related
* [PATCH v6 4/5] ixgbe: Report PCIe link properties with pcie_print_link_status()
From: Bjorn Helgaas @ 2018-05-03 20:00 UTC (permalink / raw)
To: Jeff Kirsher, Ganesh Goudar, Michael Chan, Ariel Elior
Cc: linux-pci, everest-linux-l2, intel-wired-lan, netdev,
linux-kernel, Tal Gilboa, Tariq Toukan, Jacob Keller,
Jakub Kicinski
In-Reply-To: <152537719056.62474.2571390812509425478.stgit@bhelgaas-glaptop.roam.corp.google.com>
From: Bjorn Helgaas <bhelgaas@google.com>
Previously the driver used pcie_get_minimum_link() to warn when the NIC
is in a slot that can't supply as much bandwidth as the NIC could use.
pcie_get_minimum_link() can be misleading because it finds the slowest link
and the narrowest link (which may be different links) without considering
the total bandwidth of each link. For a path with a 16 GT/s x1 link and a
2.5 GT/s x16 link, it returns 2.5 GT/s x1, which corresponds to 250 MB/s of
bandwidth, not the true available bandwidth of about 1969 MB/s for a
16 GT/s x1 link.
Use pcie_print_link_status() to report PCIe link speed and possible
limitations instead of implementing this in the driver itself. This finds
the slowest link in the path to the device by computing the total bandwidth
of each link and compares that with the capabilities of the device.
The dmesg change is:
- PCI Express bandwidth of %dGT/s available
- (Speed:%s, Width: x%d, Encoding Loss:%s)
+ %u.%03u Gb/s available PCIe bandwidth (%s x%d link)
or, if the device is capable of better performance than is available in the
current slot:
- This is not sufficient for optimal performance of this card.
- For optimal performance, at least %dGT/s of bandwidth is required.
- A slot with more lanes and/or higher speed is suggested.
+ %u.%03u Gb/s available PCIe bandwidth, limited by %s x%d link at %s (capable of %u.%03u Gb/s with %s x%d link)
Note that the driver previously used dev_warn() to suggest using a
different slot, but pcie_print_link_status() uses dev_info() because if the
platform has no faster slot available, the user can't do anything about the
warning and may not want to be bothered with it.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 47 +------------------------
1 file changed, 1 insertion(+), 46 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index afadba99f7b8..8990285f6e12 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -270,9 +270,6 @@ static void ixgbe_check_minimum_link(struct ixgbe_adapter *adapter,
int expected_gts)
{
struct ixgbe_hw *hw = &adapter->hw;
- int max_gts = 0;
- enum pci_bus_speed speed = PCI_SPEED_UNKNOWN;
- enum pcie_link_width width = PCIE_LNK_WIDTH_UNKNOWN;
struct pci_dev *pdev;
/* Some devices are not connected over PCIe and thus do not negotiate
@@ -288,49 +285,7 @@ static void ixgbe_check_minimum_link(struct ixgbe_adapter *adapter,
else
pdev = adapter->pdev;
- if (pcie_get_minimum_link(pdev, &speed, &width) ||
- speed == PCI_SPEED_UNKNOWN || width == PCIE_LNK_WIDTH_UNKNOWN) {
- e_dev_warn("Unable to determine PCI Express bandwidth.\n");
- return;
- }
-
- switch (speed) {
- case PCIE_SPEED_2_5GT:
- /* 8b/10b encoding reduces max throughput by 20% */
- max_gts = 2 * width;
- break;
- case PCIE_SPEED_5_0GT:
- /* 8b/10b encoding reduces max throughput by 20% */
- max_gts = 4 * width;
- break;
- case PCIE_SPEED_8_0GT:
- /* 128b/130b encoding reduces throughput by less than 2% */
- max_gts = 8 * width;
- break;
- default:
- e_dev_warn("Unable to determine PCI Express bandwidth.\n");
- return;
- }
-
- e_dev_info("PCI Express bandwidth of %dGT/s available\n",
- max_gts);
- e_dev_info("(Speed:%s, Width: x%d, Encoding Loss:%s)\n",
- (speed == PCIE_SPEED_8_0GT ? "8.0GT/s" :
- speed == PCIE_SPEED_5_0GT ? "5.0GT/s" :
- speed == PCIE_SPEED_2_5GT ? "2.5GT/s" :
- "Unknown"),
- width,
- (speed == PCIE_SPEED_2_5GT ? "20%" :
- speed == PCIE_SPEED_5_0GT ? "20%" :
- speed == PCIE_SPEED_8_0GT ? "<2%" :
- "Unknown"));
-
- if (max_gts < expected_gts) {
- e_dev_warn("This is not sufficient for optimal performance of this card.\n");
- e_dev_warn("For optimal performance, at least %dGT/s of bandwidth is required.\n",
- expected_gts);
- e_dev_warn("A slot with more lanes and/or higher speed is suggested.\n");
- }
+ pcie_print_link_status(pdev);
}
static void ixgbe_service_event_schedule(struct ixgbe_adapter *adapter)
^ permalink raw reply related
* [PATCH v6 3/5] cxgb4: Report PCIe link properties with pcie_print_link_status()
From: Bjorn Helgaas @ 2018-05-03 20:00 UTC (permalink / raw)
To: Jeff Kirsher, Ganesh Goudar, Michael Chan, Ariel Elior
Cc: linux-pci, everest-linux-l2, intel-wired-lan, netdev,
linux-kernel, Tal Gilboa, Tariq Toukan, Jacob Keller,
Jakub Kicinski
In-Reply-To: <152537719056.62474.2571390812509425478.stgit@bhelgaas-glaptop.roam.corp.google.com>
From: Bjorn Helgaas <bhelgaas@google.com>
Previously the driver used pcie_get_minimum_link() to warn when the NIC
is in a slot that can't supply as much bandwidth as the NIC could use.
pcie_get_minimum_link() can be misleading because it finds the slowest link
and the narrowest link (which may be different links) without considering
the total bandwidth of each link. For a path with a 16 GT/s x1 link and a
2.5 GT/s x16 link, it returns 2.5 GT/s x1, which corresponds to 250 MB/s of
bandwidth, not the true available bandwidth of about 1969 MB/s for a
16 GT/s x1 link.
Use pcie_print_link_status() to report PCIe link speed and possible
limitations instead of implementing this in the driver itself. This finds
the slowest link in the path to the device by computing the total bandwidth
of each link and compares that with the capabilities of the device.
The dmesg change is:
- PCIe link speed is %s, device supports %s
- PCIe link width is x%d, device supports x%d
+ %u.%03u Gb/s available PCIe bandwidth (%s x%d link)
or, if the device is capable of better performance than is available in the
current slot:
- A slot with more lanes and/or higher speed is suggested for optimal performance.
+ %u.%03u Gb/s available PCIe bandwidth, limited by %s x%d link at %s (capable of %u.%03u Gb/s with %s x%d link)
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 75 -----------------------
1 file changed, 1 insertion(+), 74 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 24d2865b8806..7328f24ba1dd 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -5042,79 +5042,6 @@ static int init_rss(struct adapter *adap)
return 0;
}
-static int cxgb4_get_pcie_dev_link_caps(struct adapter *adap,
- enum pci_bus_speed *speed,
- enum pcie_link_width *width)
-{
- u32 lnkcap1, lnkcap2;
- int err1, err2;
-
-#define PCIE_MLW_CAP_SHIFT 4 /* start of MLW mask in link capabilities */
-
- *speed = PCI_SPEED_UNKNOWN;
- *width = PCIE_LNK_WIDTH_UNKNOWN;
-
- err1 = pcie_capability_read_dword(adap->pdev, PCI_EXP_LNKCAP,
- &lnkcap1);
- err2 = pcie_capability_read_dword(adap->pdev, PCI_EXP_LNKCAP2,
- &lnkcap2);
- if (!err2 && lnkcap2) { /* PCIe r3.0-compliant */
- if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_8_0GB)
- *speed = PCIE_SPEED_8_0GT;
- else if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_5_0GB)
- *speed = PCIE_SPEED_5_0GT;
- else if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_2_5GB)
- *speed = PCIE_SPEED_2_5GT;
- }
- if (!err1) {
- *width = (lnkcap1 & PCI_EXP_LNKCAP_MLW) >> PCIE_MLW_CAP_SHIFT;
- if (!lnkcap2) { /* pre-r3.0 */
- if (lnkcap1 & PCI_EXP_LNKCAP_SLS_5_0GB)
- *speed = PCIE_SPEED_5_0GT;
- else if (lnkcap1 & PCI_EXP_LNKCAP_SLS_2_5GB)
- *speed = PCIE_SPEED_2_5GT;
- }
- }
-
- if (*speed == PCI_SPEED_UNKNOWN || *width == PCIE_LNK_WIDTH_UNKNOWN)
- return err1 ? err1 : err2 ? err2 : -EINVAL;
- return 0;
-}
-
-static void cxgb4_check_pcie_caps(struct adapter *adap)
-{
- enum pcie_link_width width, width_cap;
- enum pci_bus_speed speed, speed_cap;
-
-#define PCIE_SPEED_STR(speed) \
- (speed == PCIE_SPEED_8_0GT ? "8.0GT/s" : \
- speed == PCIE_SPEED_5_0GT ? "5.0GT/s" : \
- speed == PCIE_SPEED_2_5GT ? "2.5GT/s" : \
- "Unknown")
-
- if (cxgb4_get_pcie_dev_link_caps(adap, &speed_cap, &width_cap)) {
- dev_warn(adap->pdev_dev,
- "Unable to determine PCIe device BW capabilities\n");
- return;
- }
-
- if (pcie_get_minimum_link(adap->pdev, &speed, &width) ||
- speed == PCI_SPEED_UNKNOWN || width == PCIE_LNK_WIDTH_UNKNOWN) {
- dev_warn(adap->pdev_dev,
- "Unable to determine PCI Express bandwidth.\n");
- return;
- }
-
- dev_info(adap->pdev_dev, "PCIe link speed is %s, device supports %s\n",
- PCIE_SPEED_STR(speed), PCIE_SPEED_STR(speed_cap));
- dev_info(adap->pdev_dev, "PCIe link width is x%d, device supports x%d\n",
- width, width_cap);
- if (speed < speed_cap || width < width_cap)
- dev_info(adap->pdev_dev,
- "A slot with more lanes and/or higher speed is "
- "suggested for optimal performance.\n");
-}
-
/* Dump basic information about the adapter */
static void print_adapter_info(struct adapter *adapter)
{
@@ -5750,7 +5677,7 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
}
/* check for PCI Express bandwidth capabiltites */
- cxgb4_check_pcie_caps(adapter);
+ pcie_print_link_status(pdev);
err = init_rss(adapter);
if (err)
^ permalink raw reply related
* [PATCH v6 2/5] bnxt_en: Report PCIe link properties with pcie_print_link_status()
From: Bjorn Helgaas @ 2018-05-03 20:00 UTC (permalink / raw)
To: Jeff Kirsher, Ganesh Goudar, Michael Chan, Ariel Elior
Cc: linux-pci, everest-linux-l2, intel-wired-lan, netdev,
linux-kernel, Tal Gilboa, Tariq Toukan, Jacob Keller,
Jakub Kicinski
In-Reply-To: <152537719056.62474.2571390812509425478.stgit@bhelgaas-glaptop.roam.corp.google.com>
From: Bjorn Helgaas <bhelgaas@google.com>
Previously the driver used pcie_get_minimum_link() to warn when the NIC
is in a slot that can't supply as much bandwidth as the NIC could use.
pcie_get_minimum_link() can be misleading because it finds the slowest link
and the narrowest link (which may be different links) without considering
the total bandwidth of each link. For a path with a 16 GT/s x1 link and a
2.5 GT/s x16 link, it returns 2.5 GT/s x1, which corresponds to 250 MB/s of
bandwidth, not the true available bandwidth of about 1969 MB/s for a
16 GT/s x1 link.
Use pcie_print_link_status() to report PCIe link speed and possible
limitations instead of implementing this in the driver itself. This finds
the slowest link in the path to the device by computing the total bandwidth
of each link and compares that with the capabilities of the device.
The dmesg change is:
- PCIe: Speed %s Width x%d
+ %u.%03u Gb/s available PCIe bandwidth (%s x%d link)
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 19 +------------------
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index f83769d8047b..34fddb48fecc 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -8621,22 +8621,6 @@ static int bnxt_init_mac_addr(struct bnxt *bp)
return rc;
}
-static void bnxt_parse_log_pcie_link(struct bnxt *bp)
-{
- enum pcie_link_width width = PCIE_LNK_WIDTH_UNKNOWN;
- enum pci_bus_speed speed = PCI_SPEED_UNKNOWN;
-
- if (pcie_get_minimum_link(pci_physfn(bp->pdev), &speed, &width) ||
- speed == PCI_SPEED_UNKNOWN || width == PCIE_LNK_WIDTH_UNKNOWN)
- netdev_info(bp->dev, "Failed to determine PCIe Link Info\n");
- else
- netdev_info(bp->dev, "PCIe: Speed %s Width x%d\n",
- speed == PCIE_SPEED_2_5GT ? "2.5GT/s" :
- speed == PCIE_SPEED_5_0GT ? "5.0GT/s" :
- speed == PCIE_SPEED_8_0GT ? "8.0GT/s" :
- "Unknown", width);
-}
-
static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
{
static int version_printed;
@@ -8851,8 +8835,7 @@ static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
netdev_info(dev, "%s found at mem %lx, node addr %pM\n",
board_info[ent->driver_data].name,
(long)pci_resource_start(pdev, 0), dev->dev_addr);
-
- bnxt_parse_log_pcie_link(bp);
+ pcie_print_link_status(pdev);
return 0;
^ permalink raw reply related
* [PATCH v6 1/5] bnx2x: Report PCIe link properties with pcie_print_link_status()
From: Bjorn Helgaas @ 2018-05-03 20:00 UTC (permalink / raw)
To: Jeff Kirsher, Ganesh Goudar, Michael Chan, Ariel Elior
Cc: linux-pci, everest-linux-l2, intel-wired-lan, netdev,
linux-kernel, Tal Gilboa, Tariq Toukan, Jacob Keller,
Jakub Kicinski
In-Reply-To: <152537719056.62474.2571390812509425478.stgit@bhelgaas-glaptop.roam.corp.google.com>
From: Bjorn Helgaas <bhelgaas@google.com>
Previously the driver used pcie_get_minimum_link() to warn when the NIC
is in a slot that can't supply as much bandwidth as the NIC could use.
pcie_get_minimum_link() can be misleading because it finds the slowest link
and the narrowest link (which may be different links) without considering
the total bandwidth of each link. For a path with a 16 GT/s x1 link and a
2.5 GT/s x16 link, it returns 2.5 GT/s x1, which corresponds to 250 MB/s of
bandwidth, not the true available bandwidth of about 1969 MB/s for a
16 GT/s x1 link.
Use pcie_print_link_status() to report PCIe link speed and possible
limitations instead of implementing this in the driver itself. This finds
the slowest link in the path to the device by computing the total bandwidth
of each link and compares that with the capabilities of the device.
The dmesg change is:
- %s (%c%d) PCI-E x%d %s found at mem %lx, IRQ %d, node addr %pM
+ %s (%c%d) PCI-E found at mem %lx, IRQ %d, node addr %pM
+ %u.%03u Gb/s available PCIe bandwidth (%s x%d link)
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 23 ++++++----------------
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index c766ae23bc74..5b1ed240bf18 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13922,8 +13922,6 @@ static int bnx2x_init_one(struct pci_dev *pdev,
{
struct net_device *dev = NULL;
struct bnx2x *bp;
- enum pcie_link_width pcie_width;
- enum pci_bus_speed pcie_speed;
int rc, max_non_def_sbs;
int rx_count, tx_count, rss_count, doorbell_size;
int max_cos_est;
@@ -14091,21 +14089,12 @@ static int bnx2x_init_one(struct pci_dev *pdev,
dev_addr_add(bp->dev, bp->fip_mac, NETDEV_HW_ADDR_T_SAN);
rtnl_unlock();
}
- if (pcie_get_minimum_link(bp->pdev, &pcie_speed, &pcie_width) ||
- pcie_speed == PCI_SPEED_UNKNOWN ||
- pcie_width == PCIE_LNK_WIDTH_UNKNOWN)
- BNX2X_DEV_INFO("Failed to determine PCI Express Bandwidth\n");
- else
- BNX2X_DEV_INFO(
- "%s (%c%d) PCI-E x%d %s found at mem %lx, IRQ %d, node addr %pM\n",
- board_info[ent->driver_data].name,
- (CHIP_REV(bp) >> 12) + 'A', (CHIP_METAL(bp) >> 4),
- pcie_width,
- pcie_speed == PCIE_SPEED_2_5GT ? "2.5GHz" :
- pcie_speed == PCIE_SPEED_5_0GT ? "5.0GHz" :
- pcie_speed == PCIE_SPEED_8_0GT ? "8.0GHz" :
- "Unknown",
- dev->base_addr, bp->pdev->irq, dev->dev_addr);
+ BNX2X_DEV_INFO(
+ "%s (%c%d) PCI-E found at mem %lx, IRQ %d, node addr %pM\n",
+ board_info[ent->driver_data].name,
+ (CHIP_REV(bp) >> 12) + 'A', (CHIP_METAL(bp) >> 4),
+ dev->base_addr, bp->pdev->irq, dev->dev_addr);
+ pcie_print_link_status(bp->pdev);
bnx2x_register_phc(bp);
^ permalink raw reply related
* [PATCH v6 0/5] PCI: Improve PCIe link status reporting
From: Bjorn Helgaas @ 2018-05-03 20:00 UTC (permalink / raw)
To: Jeff Kirsher, Ganesh Goudar, Michael Chan, Ariel Elior
Cc: linux-pci, everest-linux-l2, intel-wired-lan, netdev,
linux-kernel, Tal Gilboa, Tariq Toukan, Jacob Keller,
Jakub Kicinski
This is based on Tal's recent work to unify the approach for reporting PCIe
link speed/width and whether the device is being limited by a slower
upstream link.
The new pcie_print_link_status() interface appeared in v4.17-rc1; see
9e506a7b5147 ("PCI: Add pcie_print_link_status() to log link speed and
whether it's limited").
That's a good way to replace use of pcie_get_minimum_link(), which gives
misleading results when a path contains both a fast, narrow link and a
slow, wide link: it reports the equivalent of a slow, narrow link.
This series removes the remaining uses of pcie_get_minimum_link() and then
removes the interface itself. I'd like to merge them all through the PCI
tree to make the removal easy.
This does change the dmesg reporting of link speeds, and in the ixgbe case,
it changes the reporting from KERN_WARN level to KERN_INFO. If that's an
issue, let's talk about it. I'm hoping the reduce code size, improved
functionality, and consistency across drivers is enough to make this
worthwhile.
---
Bjorn Helgaas (5):
bnx2x: Report PCIe link properties with pcie_print_link_status()
bnxt_en: Report PCIe link properties with pcie_print_link_status()
cxgb4: Report PCIe link properties with pcie_print_link_status()
ixgbe: Report PCIe link properties with pcie_print_link_status()
PCI: Remove unused pcie_get_minimum_link()
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 23 ++-----
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 19 ------
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 75 ----------------------
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 47 --------------
drivers/pci/pci.c | 43 -------------
include/linux/pci.h | 2 -
6 files changed, 9 insertions(+), 200 deletions(-)
^ permalink raw reply
* Re: [PATCH] atm: zatm: Fix potential Spectre v1
From: David Miller @ 2018-05-03 19:25 UTC (permalink / raw)
To: rdunlap; +Cc: gustavo, 3chas3, linux-atm-general, netdev, linux-kernel
In-Reply-To: <98d11d2c-c7c9-e0ae-8a96-320ab9bca765@infradead.org>
From: Randy Dunlap <rdunlap@infradead.org>
Date: Thu, 3 May 2018 12:09:40 -0700
> Just for (my) info: all of these types of patches are to prevent
> what is loaded in cache when the index is out of range, right?
> Not some random pool_info[random], but pool_info[valid, i.e., 0].
>
> Since the value of pool is already sanity checked and -EINVAL is
> returned when it's out of range.
Well, the whole point is that the cpu can speculate execution past the
range check and execute the indexed read anyways. So even if the
value is "sanity checked" the cpu can execute ahead and load things
into the cache, just cancelling the register state updates later when
the range check is fully resolved.
^ permalink raw reply
* Re: KMSAN: uninit-value in strcmp
From: David Miller @ 2018-05-03 19:22 UTC (permalink / raw)
To: syzbot+df0257c92ffd4fcc58cd
Cc: jon.maloy, linux-kernel, netdev, syzkaller-bugs, tipc-discussion,
ying.xue
In-Reply-To: <00000000000059f907056b519603@google.com>
From: syzbot <syzbot+df0257c92ffd4fcc58cd@syzkaller.appspotmail.com>
Date: Thu, 03 May 2018 11:44:02 -0700
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x185/0x1d0 lib/dump_stack.c:53
> kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
> __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
> strcmp+0xf7/0x160 lib/string.c:329
> tipc_nl_node_get_link+0x220/0x6f0 net/tipc/node.c:1881
> genl_family_rcv_msg net/netlink/genetlink.c:599 [inline]
Hmmm, TIPC_NL_LINK_GET uses tipc_nl_policy, which has a proper nesting
entry for TIPC_NLA_LINK. I wonder how the code goes about validating
TIPC_NLA_LINK_NAME in such a case? Does it?
This may be the problem.
^ permalink raw reply
* Re: [PATCH net] dccp: fix tasklet usage
From: David Miller @ 2018-05-03 19:15 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, gerrit, dccp
In-Reply-To: <20180503163920.102035-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Thu, 3 May 2018 09:39:20 -0700
> syzbot reported a crash in tasklet_action_common() caused by dccp.
>
> dccp needs to make sure socket wont disappear before tasklet handler
> has completed.
>
> This patch takes a reference on the socket when arming the tasklet,
> and moves the sock_put() from dccp_write_xmit_timer() to dccp_write_xmitlet()
...
> Fixes: dc841e30eaea ("dccp: Extend CCID packet dequeueing interface")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH] atm: zatm: Fix potential Spectre v1
From: Randy Dunlap @ 2018-05-03 19:09 UTC (permalink / raw)
To: Gustavo A. R. Silva, Chas Williams, David S. Miller
Cc: linux-atm-general, netdev, linux-kernel
In-Reply-To: <20180503181712.GA7443@embeddedor.com>
On 05/03/2018 11:17 AM, Gustavo A. R. Silva wrote:
> pool can be indirectly controlled by user-space, hence leading to
> a potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
>
> drivers/atm/zatm.c:1462 zatm_ioctl() warn: potential spectre issue
> 'zatm_dev->pool_info' (local cap)
>
> Fix this by sanitizing pool before using it to index
> zatm_dev->pool_info
>
> Notice that given that speculation windows are large, the policy is
> to kill the speculation on the first load and not worry if it can be
> completed with a dependent load/store [1].
>
> [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
Hi,
Just for (my) info: all of these types of patches are to prevent
what is loaded in cache when the index is out of range, right?
Not some random pool_info[random], but pool_info[valid, i.e., 0].
Since the value of pool is already sanity checked and -EINVAL is
returned when it's out of range.
Thanks.
> Cc: stable@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> drivers/atm/zatm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/atm/zatm.c b/drivers/atm/zatm.c
> index 1ef67db..9c9a229 100644
> --- a/drivers/atm/zatm.c
> +++ b/drivers/atm/zatm.c
> @@ -28,6 +28,7 @@
> #include <asm/io.h>
> #include <linux/atomic.h>
> #include <linux/uaccess.h>
> +#include <linux/nospec.h>
>
> #include "uPD98401.h"
> #include "uPD98402.h"
> @@ -1458,6 +1459,8 @@ static int zatm_ioctl(struct atm_dev *dev,unsigned int cmd,void __user *arg)
> return -EFAULT;
> if (pool < 0 || pool > ZATM_LAST_POOL)
> return -EINVAL;
> + pool = array_index_nospec(pool,
> + ZATM_LAST_POOL + 1);
> spin_lock_irqsave(&zatm_dev->lock, flags);
> info = zatm_dev->pool_info[pool];
> if (cmd == ZATM_GETPOOLZ) {
>
--
~Randy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox