Stable Archive on lore.kernel.org
 help / Atom feed
* [PATCHES] Networking
@ 2019-05-21  6:37 David Miller
  2019-05-22  6:36 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2019-05-21  6:37 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 105 bytes --]


Please queue up the following networking bug fixes for v5.0 and v5.1
-stable, respectively.

Thank you!

[-- Attachment #2: net_50.mbox --]
[-- Type: Application/Octet-Stream, Size: 45296 bytes --]

[-- Attachment #3: net_51.mbox --]
[-- Type: Application/Octet-Stream, Size: 57390 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-05-21  6:37 [PATCHES] Networking David Miller
@ 2019-05-22  6:36 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2019-05-22  6:36 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Mon, May 20, 2019 at 11:37:45PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v5.0 and v5.1
> -stable, respectively.

All now queued up, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-06-09  7:26 ` Greg KH
@ 2019-06-09 19:42   ` David Miller
  0 siblings, 0 replies; 213+ messages in thread
From: David Miller @ 2019-06-09 19:42 UTC (permalink / raw)
  To: greg; +Cc: stable

From: Greg KH <greg@kroah.com>
Date: Sun, 9 Jun 2019 09:26:10 +0200

> On Sat, Jun 08, 2019 at 04:27:22PM -0700, David Miller wrote:
>> 
>> Please queue up the following networking bug fixes for v4.19 and v5.2
>> -stable, respectively.
> 
> All now queued up, except for the duplicate sparc64 patch that you sent
> last week which I already applied :)

Oops, my bad!

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-06-08 23:27 David Miller
@ 2019-06-09  7:26 ` Greg KH
  2019-06-09 19:42   ` David Miller
  0 siblings, 1 reply; 213+ messages in thread
From: Greg KH @ 2019-06-09  7:26 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Sat, Jun 08, 2019 at 04:27:22PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.19 and v5.2
> -stable, respectively.

All now queued up, except for the duplicate sparc64 patch that you sent
last week which I already applied :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2019-06-08 23:27 David Miller
  2019-06-09  7:26 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2019-06-08 23:27 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 106 bytes --]


Please queue up the following networking bug fixes for v4.19 and v5.2
-stable, respectively.

Thank you.

[-- Attachment #2: net_419.mbox --]
[-- Type: Application/Octet-Stream, Size: 44248 bytes --]

[-- Attachment #3: net_51.mbox --]
[-- Type: Application/Octet-Stream, Size: 52487 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-05-14 19:58 David Miller
@ 2019-05-15  6:02 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2019-05-15  6:02 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, May 14, 2019 at 12:58:49PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v5.0 and v5.1
> -stable, respectively.
> 
> Thank you.


All now queued up, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2019-05-14 19:58 David Miller
  2019-05-15  6:02 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2019-05-14 19:58 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 105 bytes --]


Please queue up the following networking bug fixes for v5.0 and v5.1
-stable, respectively.

Thank you.

[-- Attachment #2: net_50.mbox --]
[-- Type: Application/Octet-Stream, Size: 52897 bytes --]

[-- Attachment #3: net_51.mbox --]
[-- Type: Application/Octet-Stream, Size: 52902 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-05-04  7:01 David Miller
@ 2019-05-04  7:34 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2019-05-04  7:34 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Sat, May 04, 2019 at 03:01:18AM -0400, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.19 and
> v5.0 -stable, respectively.
> 
> Thank you.

Thanks for these, all now queued up.

greg k-h


^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2019-05-04  7:01 David Miller
  2019-05-04  7:34 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2019-05-04  7:01 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 106 bytes --]


Please queue up the following networking bug fixes for v4.19 and
v5.0 -stable, respectively.

Thank you.

[-- Attachment #2: net_419.mbox --]
[-- Type: Application/Octet-Stream, Size: 53539 bytes --]

[-- Attachment #3: net_50.mbox --]
[-- Type: Application/Octet-Stream, Size: 78372 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-04-30  2:06 David Miller
@ 2019-04-30  7:53 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2019-04-30  7:53 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Mon, Apr 29, 2019 at 10:06:29PM -0400, David Miller wrote:
> 
> Please queue up the following neworking bug fixes for
> v4.19 and v5.0 -stable, respectively.

Thanks for these, all now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2019-04-30  2:06 David Miller
  2019-04-30  7:53 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2019-04-30  2:06 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 105 bytes --]


Please queue up the following neworking bug fixes for
v4.19 and v5.0 -stable, respectively.

Thank you!

[-- Attachment #2: net_419.mbox --]
[-- Type: Application/Octet-Stream, Size: 52424 bytes --]

[-- Attachment #3: net_50.mbox --]
[-- Type: Application/Octet-Stream, Size: 55989 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-04-18 22:53 David Miller
@ 2019-04-23 20:06 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2019-04-23 20:06 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Apr 18, 2019 at 03:53:40PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.19 and
> v5.0 -stable, respectively.

Thanks for these, all now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2019-04-18 22:53 David Miller
  2019-04-23 20:06 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2019-04-18 22:53 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 106 bytes --]


Please queue up the following networking bug fixes for v4.19 and
v5.0 -stable, respectively.

Thank you!

[-- Attachment #2: net_419.mbox --]
[-- Type: Application/Octet-Stream, Size: 54295 bytes --]

[-- Attachment #3: net_50.mbox --]
[-- Type: Application/Octet-Stream, Size: 102211 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-04-10  3:55 David Miller
@ 2019-04-10 15:35 ` Sasha Levin
  0 siblings, 0 replies; 213+ messages in thread
From: Sasha Levin @ 2019-04-10 15:35 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, Apr 09, 2019 at 08:55:38PM -0700, David Miller wrote:
>
>Please queue up the following networking bug fixes for v4.19 and v5.0
>stable respectively.
>
>Thank you!

Queued both, thank you!

--
Thanks,
Sasha



^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2019-04-10  3:55 David Miller
  2019-04-10 15:35 ` Sasha Levin
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2019-04-10  3:55 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 104 bytes --]


Please queue up the following networking bug fixes for v4.19 and v5.0
stable respectively.

Thank you!

[-- Attachment #2: net_419.mbox --]
[-- Type: Application/Octet-Stream, Size: 97002 bytes --]

[-- Attachment #3: net_50.mbox --]
[-- Type: Application/Octet-Stream, Size: 106427 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-03-28 23:18     ` David Miller
@ 2019-03-29  6:18       ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2019-03-29  6:18 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Mar 28, 2019 at 04:18:14PM -0700, David Miller wrote:
> From: Greg KH <gregkh@linuxfoundation.org>
> Date: Thu, 28 Mar 2019 22:51:49 +0100
> 
> > On Thu, Mar 28, 2019 at 09:55:25PM +0100, Greg KH wrote:
> >> On Thu, Mar 28, 2019 at 12:24:07PM -0700, David Miller wrote:
> >> > 
> >> > Please queue up the following networking bug fixes for v4.19 and v5.0
> >> > -stable, respectively.
> >> 
> >> Now queued up, thanks.
> > 
> > Hm, looks like the tun patch needs a call to rcu_read_unlock() in the
> > error path.  Should I drop that patch for now until a fix hits Linus's
> > tree, or just leave it as-is for now and take the fix later?
> 
> Hmmm, I thought I included the:
> 
> >From 9180bb4f046064dfa4541488102703b402bb04e1 Mon Sep 17 00:00:00 2001
> From: Eric Dumazet <edumazet@google.com>
> Date: Sat, 16 Mar 2019 13:09:53 -0700
> Subject: [PATCH] tun: add a missing rcu_read_unlock() in error path
> 
> [ Upstream commit 9180bb4f046064dfa4541488102703b402bb04e1 ]
> 
> In my latest patch I missed one rcu_read_unlock(), in case
> device is down.
> 
> Fixes: 4477138fa0ae ("tun: properly test for IFF_UP")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>  drivers/net/tun.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 0d343359f647..e9ca1c088d0b 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1960,6 +1960,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
>  	rcu_read_lock();
>  	if (unlikely(!(tun->dev->flags & IFF_UP))) {
>  		err = -EIO;
> +		rcu_read_unlock();
>  		goto drop;
>  	}
>  
> -- 
> 2.20.1

Wonderful, thanks for this, now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-03-28 21:51   ` Greg KH
@ 2019-03-28 23:18     ` David Miller
  2019-03-29  6:18       ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2019-03-28 23:18 UTC (permalink / raw)
  To: gregkh; +Cc: stable

From: Greg KH <gregkh@linuxfoundation.org>
Date: Thu, 28 Mar 2019 22:51:49 +0100

> On Thu, Mar 28, 2019 at 09:55:25PM +0100, Greg KH wrote:
>> On Thu, Mar 28, 2019 at 12:24:07PM -0700, David Miller wrote:
>> > 
>> > Please queue up the following networking bug fixes for v4.19 and v5.0
>> > -stable, respectively.
>> 
>> Now queued up, thanks.
> 
> Hm, looks like the tun patch needs a call to rcu_read_unlock() in the
> error path.  Should I drop that patch for now until a fix hits Linus's
> tree, or just leave it as-is for now and take the fix later?

Hmmm, I thought I included the:

From 9180bb4f046064dfa4541488102703b402bb04e1 Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet@google.com>
Date: Sat, 16 Mar 2019 13:09:53 -0700
Subject: [PATCH] tun: add a missing rcu_read_unlock() in error path

[ Upstream commit 9180bb4f046064dfa4541488102703b402bb04e1 ]

In my latest patch I missed one rcu_read_unlock(), in case
device is down.

Fixes: 4477138fa0ae ("tun: properly test for IFF_UP")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/tun.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 0d343359f647..e9ca1c088d0b 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1960,6 +1960,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
 	rcu_read_lock();
 	if (unlikely(!(tun->dev->flags & IFF_UP))) {
 		err = -EIO;
+		rcu_read_unlock();
 		goto drop;
 	}
 
-- 
2.20.1


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-03-28 20:55 ` Greg KH
@ 2019-03-28 21:51   ` Greg KH
  2019-03-28 23:18     ` David Miller
  0 siblings, 1 reply; 213+ messages in thread
From: Greg KH @ 2019-03-28 21:51 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Mar 28, 2019 at 09:55:25PM +0100, Greg KH wrote:
> On Thu, Mar 28, 2019 at 12:24:07PM -0700, David Miller wrote:
> > 
> > Please queue up the following networking bug fixes for v4.19 and v5.0
> > -stable, respectively.
> 
> Now queued up, thanks.

Hm, looks like the tun patch needs a call to rcu_read_unlock() in the
error path.  Should I drop that patch for now until a fix hits Linus's
tree, or just leave it as-is for now and take the fix later?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-03-28 19:24 David Miller
@ 2019-03-28 20:55 ` Greg KH
  2019-03-28 21:51   ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: Greg KH @ 2019-03-28 20:55 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Mar 28, 2019 at 12:24:07PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.19 and v5.0
> -stable, respectively.

Now queued up, thanks.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2019-03-28 19:24 David Miller
  2019-03-28 20:55 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2019-03-28 19:24 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 103 bytes --]


Please queue up the following networking bug fixes for v4.19 and v5.0
-stable, respectively.

Thanks!

[-- Attachment #2: net_419.mbox --]
[-- Type: Application/Octet-Stream, Size: 64759 bytes --]

[-- Attachment #3: net_50.mbox --]
[-- Type: Application/Octet-Stream, Size: 71305 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-03-15  6:30 ` Greg KH
@ 2019-03-19 13:03   ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2019-03-19 13:03 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Mar 14, 2019 at 11:30:46PM -0700, Greg KH wrote:
> On Thu, Mar 14, 2019 at 06:47:45PM -0700, David Miller wrote:
> > 
> > Please queue up the following bug fixes for v4.20 and v5.0 -stable,
> > respectively.
> 
> All queued up, thanks!

Note, 4.20 is now end-of-life, so no need for any 4.20.y patches
anymore, thanks.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-03-15  1:47 David Miller
@ 2019-03-15  6:30 ` Greg KH
  2019-03-19 13:03   ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: Greg KH @ 2019-03-15  6:30 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Mar 14, 2019 at 06:47:45PM -0700, David Miller wrote:
> 
> Please queue up the following bug fixes for v4.20 and v5.0 -stable,
> respectively.

All queued up, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2019-03-15  1:47 David Miller
  2019-03-15  6:30 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2019-03-15  1:47 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 95 bytes --]


Please queue up the following bug fixes for v4.20 and v5.0 -stable,
respectively.

Thank you!

[-- Attachment #2: net_420.mbox --]
[-- Type: Application/Octet-Stream, Size: 133006 bytes --]

[-- Attachment #3: net_50.mbox --]
[-- Type: Application/Octet-Stream, Size: 111029 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-03-07 22:47 David Miller
@ 2019-03-08  6:38 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2019-03-08  6:38 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Mar 07, 2019 at 02:47:03PM -0800, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.20 and v5.0
> -stable, respectively.

Thanks for these, they are all now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2019-03-07 22:47 David Miller
  2019-03-08  6:38 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2019-03-07 22:47 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 106 bytes --]


Please queue up the following networking bug fixes for v4.20 and v5.0
-stable, respectively.

Thank you.

[-- Attachment #2: net_420.mbox --]
[-- Type: Application/Octet-Stream, Size: 104377 bytes --]

[-- Attachment #3: net_50.mbox --]
[-- Type: Application/Octet-Stream, Size: 32841 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-02-24  5:18 David Miller
@ 2019-02-24  7:52 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2019-02-24  7:52 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Sat, Feb 23, 2019 at 09:18:00PM -0800, David Miller wrote:
> 
> Please queue up the following networking bug fixes to v4.19 and v4.20
> respectively.

Now queued up, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2019-02-24  5:18 David Miller
  2019-02-24  7:52 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2019-02-24  5:18 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 97 bytes --]


Please queue up the following networking bug fixes to v4.19 and v4.20
respectively.

Thank you!

[-- Attachment #2: net_419.mbox --]
[-- Type: Application/Octet-Stream, Size: 62891 bytes --]

[-- Attachment #3: net_420.mbox --]
[-- Type: Application/Octet-Stream, Size: 66644 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-02-20 20:42 David Miller
  2019-02-21  3:08 ` Sasha Levin
@ 2019-02-21  7:21 ` Greg KH
  1 sibling, 0 replies; 213+ messages in thread
From: Greg KH @ 2019-02-21  7:21 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Wed, Feb 20, 2019 at 12:42:52PM -0800, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.19 and v4.20
> -stable, respectively.

Thanks for these, Sasha queued them up and I'll go through them for
older kernels as well.

Note, commit 2c4cc9712364 ("tcp: tcp_v4_err() should be more careful")
was backported a bit oddly, the later lines were not removed, so I fixed
that up by hand now.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-02-20 20:42 David Miller
@ 2019-02-21  3:08 ` Sasha Levin
  2019-02-21  7:21 ` Greg KH
  1 sibling, 0 replies; 213+ messages in thread
From: Sasha Levin @ 2019-02-21  3:08 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Wed, Feb 20, 2019 at 12:42:52PM -0800, David Miller wrote:
>
>Please queue up the following networking bug fixes for v4.19 and v4.20
>-stable, respectively.
>
>Thank you.

Now queued, thank you.

--
Thanks,
Sasha

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2019-02-20 20:42 David Miller
  2019-02-21  3:08 ` Sasha Levin
  2019-02-21  7:21 ` Greg KH
  0 siblings, 2 replies; 213+ messages in thread
From: David Miller @ 2019-02-20 20:42 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 107 bytes --]


Please queue up the following networking bug fixes for v4.19 and v4.20
-stable, respectively.

Thank you.

[-- Attachment #2: net_419.mbox --]
[-- Type: Application/Octet-Stream, Size: 45340 bytes --]

[-- Attachment #3: net_420.mbox --]
[-- Type: Application/Octet-Stream, Size: 46729 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-02-09 23:21 David Miller
@ 2019-02-10 12:21 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2019-02-10 12:21 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Sat, Feb 09, 2019 at 03:21:32PM -0800, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.19 and
> v4.20 -stable, respectively.

Thanks for these, all now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2019-02-09 23:21 David Miller
  2019-02-10 12:21 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2019-02-09 23:21 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 104 bytes --]


Please queue up the following networking bug fixes for v4.19 and
v4.20 -stable, respectively.

Thanks!

[-- Attachment #2: net_419.mbox --]
[-- Type: Application/Octet-Stream, Size: 51076 bytes --]

[-- Attachment #3: net_420.mbox --]
[-- Type: Application/Octet-Stream, Size: 56396 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-02-01 21:45 David Miller
@ 2019-02-02  9:55 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2019-02-02  9:55 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Fri, Feb 01, 2019 at 01:45:13PM -0800, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.19 and v4.20
> -stable, respectively.

All now applied, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2019-02-01 21:45 David Miller
  2019-02-02  9:55 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2019-02-01 21:45 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 104 bytes --]


Please queue up the following networking bug fixes for v4.19 and v4.20
-stable, respectively.

Thanks!

[-- Attachment #2: net_419.mbox --]
[-- Type: Application/Octet-Stream, Size: 90181 bytes --]

[-- Attachment #3: net_420.mbox --]
[-- Type: Application/Octet-Stream, Size: 95130 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-01-26  0:18 David Miller
@ 2019-01-26  9:29 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2019-01-26  9:29 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Fri, Jan 25, 2019 at 04:18:32PM -0800, David Miller wrote:
> 
> Please queue up the following bug fixes for 4.19 and 4.20 -stable,
> respectively.
> 
> Thanks!



All now queued up, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2019-01-26  0:18 David Miller
  2019-01-26  9:29 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2019-01-26  0:18 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 91 bytes --]


Please queue up the following bug fixes for 4.19 and 4.20 -stable,
respectively.

Thanks!

[-- Attachment #2: net_419.mbox --]
[-- Type: Application/Octet-Stream, Size: 63006 bytes --]

[-- Attachment #3: net_420.mbox --]
[-- Type: Application/Octet-Stream, Size: 63042 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-01-21 23:28 David Miller
  2019-01-22  7:18 ` Greg KH
@ 2019-01-23  7:33 ` Greg KH
  1 sibling, 0 replies; 213+ messages in thread
From: Greg KH @ 2019-01-23  7:33 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Mon, Jan 21, 2019 at 03:28:01PM -0800, David Miller wrote:
> 
> Another day, another batch of networking fixes.
> 
> Please queue up for v4.19 and v4.20 -stable, respectively.

All now queued up, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-01-21 23:28 David Miller
@ 2019-01-22  7:18 ` Greg KH
  2019-01-23  7:33 ` Greg KH
  1 sibling, 0 replies; 213+ messages in thread
From: Greg KH @ 2019-01-22  7:18 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Mon, Jan 21, 2019 at 03:28:01PM -0800, David Miller wrote:
> 
> Another day, another batch of networking fixes.
> 
> Please queue up for v4.19 and v4.20 -stable, respectively.

Thanks for these, I'll queue them up in a few days.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2019-01-21 23:28 David Miller
  2019-01-22  7:18 ` Greg KH
  2019-01-23  7:33 ` Greg KH
  0 siblings, 2 replies; 213+ messages in thread
From: David Miller @ 2019-01-21 23:28 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 118 bytes --]


Another day, another batch of networking fixes.

Please queue up for v4.19 and v4.20 -stable, respectively.

Thanks!

[-- Attachment #2: net_419.mbox --]
[-- Type: Application/Octet-Stream, Size: 23451 bytes --]

[-- Attachment #3: net_420.mbox --]
[-- Type: Application/Octet-Stream, Size: 30570 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-01-20 19:12 David Miller
@ 2019-01-21  8:00 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2019-01-21  8:00 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Sun, Jan 20, 2019 at 11:12:06AM -0800, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.19
> and v4.20 -stable, respectively.
> 
> Thank you.


All now queued up, thanks.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2019-01-20 19:12 David Miller
  2019-01-21  8:00 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2019-01-20 19:12 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 107 bytes --]


Please queue up the following networking bug fixes for v4.19
and v4.20 -stable, respectively.

Thank you.

[-- Attachment #2: net_419.mbox --]
[-- Type: Application/Octet-Stream, Size: 26049 bytes --]

[-- Attachment #3: net_420.mbox --]
[-- Type: Application/Octet-Stream, Size: 35487 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2019-01-04 18:17 David Miller
@ 2019-01-04 18:48 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2019-01-04 18:48 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Fri, Jan 04, 2019 at 10:17:20AM -0800, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.19 and v4.20
> -stable, respectively.

All now queued up, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2019-01-04 18:17 David Miller
  2019-01-04 18:48 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2019-01-04 18:17 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 104 bytes --]


Please queue up the following networking bug fixes for v4.19 and v4.20
-stable, respectively.

Thanks!

[-- Attachment #2: net_419.mbox --]
[-- Type: Application/Octet-Stream, Size: 145563 bytes --]

[-- Attachment #3: net_420.mbox --]
[-- Type: Application/Octet-Stream, Size: 48817 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-12-12  6:31 David Miller
@ 2018-12-13  9:53 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-12-13  9:53 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, Dec 11, 2018 at 10:31:38PM -0800, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.14 and
> v4.19 -stable, respectively.

All now queued up, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-12-12  6:31 David Miller
  2018-12-13  9:53 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-12-12  6:31 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 107 bytes --]


Please queue up the following networking bug fixes for v4.14 and
v4.19 -stable, respectively.

Thank you.

[-- Attachment #2: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 47310 bytes --]

[-- Attachment #3: net_419.mbox --]
[-- Type: Application/Octet-Stream, Size: 66948 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-12-03  7:01 David Miller
@ 2018-12-03  9:13 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-12-03  9:13 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Sun, Dec 02, 2018 at 11:01:21PM -0800, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.14 and
> v4.19 -stable, respectively.

All queued up, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-12-03  7:01 David Miller
  2018-12-03  9:13 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-12-03  7:01 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 104 bytes --]


Please queue up the following networking bug fixes for v4.14 and
v4.19 -stable, respectively.

Thanks!

[-- Attachment #2: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 30794 bytes --]

[-- Attachment #3: net_419.mbox --]
[-- Type: Application/Octet-Stream, Size: 52873 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-11-21  3:49 David Miller
@ 2018-11-21 17:49 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-11-21 17:49 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, Nov 20, 2018 at 07:49:49PM -0800, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.18 and
> v4.19 -stable, respectively.

Thanks for the patches, now queued up.

Note, 4.18 is now end-of-life, so no need to be making patches for that
anymore.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-11-21  3:49 David Miller
  2018-11-21 17:49 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-11-21  3:49 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 104 bytes --]


Please queue up the following networking bug fixes for v4.18 and
v4.19 -stable, respectively.

Thanks!

[-- Attachment #2: net_418.mbox --]
[-- Type: Application/Octet-Stream, Size: 84873 bytes --]

[-- Attachment #3: net_419.mbox --]
[-- Type: Application/Octet-Stream, Size: 110004 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-11-02  3:55 David Miller
@ 2018-11-02  5:27 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-11-02  5:27 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Nov 01, 2018 at 08:55:15PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.18 and
> v4.19 -stable, respectively.


Now queued up, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-11-02  3:55 David Miller
  2018-11-02  5:27 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-11-02  3:55 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 95 bytes --]


Please queue up the following networking bug fixes for v4.18 and
v4.19 -stable, respectively.

[-- Attachment #2: net_418.mbox --]
[-- Type: Application/Octet-Stream, Size: 104994 bytes --]

[-- Attachment #3: net_419.mbox --]
[-- Type: Application/Octet-Stream, Size: 55918 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-09-24 16:46 David Miller
@ 2018-09-26  9:32 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-09-26  9:32 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Mon, Sep 24, 2018 at 09:46:40AM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.14.x and
> v4.18.x -stable, respectively.

All now queued up, thanks.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-09-24 16:46 David Miller
  2018-09-26  9:32 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-09-24 16:46 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 111 bytes --]


Please queue up the following networking bug fixes for v4.14.x and
v4.18.x -stable, respectively.

Thank you!

[-- Attachment #2: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 33655 bytes --]

[-- Attachment #3: net_418.mbox --]
[-- Type: Application/Octet-Stream, Size: 66853 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-09-18 16:14 David Miller
@ 2018-09-20  5:25 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-09-20  5:25 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, Sep 18, 2018 at 09:14:58AM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.14.x and
> v4.18.x -stable, respectively.

Thanks for these, all now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-09-18 16:14 David Miller
  2018-09-20  5:25 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-09-18 16:14 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 111 bytes --]


Please queue up the following networking bug fixes for v4.14.x and
v4.18.x -stable, respectively.

Thank you!

[-- Attachment #2: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 29504 bytes --]

[-- Attachment #3: net_418.mbox --]
[-- Type: Application/Octet-Stream, Size: 39626 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-09-11  6:15 David Miller
@ 2018-09-11  8:29 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-09-11  8:29 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Mon, Sep 10, 2018 at 11:15:08PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.17
> and v4.18 -stable, respectively.

Thanks for these, I've queued up the 4.18 patches now.

Unfortunatly 4.17 is end-of-life, but I will use that mbox as a basis
for what should be looked at for 4.14.  No need to do anything for 4.17
anymore if you don't want to.

thanks again,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-09-11  6:15 David Miller
  2018-09-11  8:29 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-09-11  6:15 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 104 bytes --]


Please queue up the following networking bug fixes for v4.17
and v4.18 -stable, respectively.

Thanks!

[-- Attachment #2: net_417.mbox --]
[-- Type: Application/Octet-Stream, Size: 87521 bytes --]

[-- Attachment #3: net_418.mbox --]
[-- Type: Application/Octet-Stream, Size: 101970 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-08-17 19:32 David Miller
@ 2018-08-18  9:43 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-08-18  9:43 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Fri, Aug 17, 2018 at 12:32:37PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes up for 4.17 and
> 4.18 -stable, respectively.

All now queued up, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-08-17 19:32 David Miller
  2018-08-18  9:43 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-08-17 19:32 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 105 bytes --]


Please queue up the following networking bug fixes up for 4.17 and
4.18 -stable, respectively.

Thanks!

[-- Attachment #2: net_417.mbox --]
[-- Type: Application/Octet-Stream, Size: 64756 bytes --]

[-- Attachment #3: net_418.mbox --]
[-- Type: Application/Octet-Stream, Size: 17393 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-08-04  5:05 David Miller
@ 2018-08-04  7:33 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-08-04  7:33 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Fri, Aug 03, 2018 at 10:05:23PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.14.x
> and v4.17.x -stable, respectively.

All now applied, thanks.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-08-04  5:05 David Miller
  2018-08-04  7:33 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-08-04  5:05 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 111 bytes --]


Please queue up the following networking bug fixes for v4.14.x
and v4.17.x -stable, respectively.

Thank you.

[-- Attachment #2: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 19775 bytes --]

[-- Attachment #3: net_417.mbox --]
[-- Type: Application/Octet-Stream, Size: 22966 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-08-01  5:32 David Miller
@ 2018-08-01  6:20 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-08-01  6:20 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, Jul 31, 2018 at 10:32:19PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 4.14.x and
> 4.17.x -stable, respectively.

All now applied, thanks.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-08-01  5:32 David Miller
  2018-08-01  6:20 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-08-01  5:32 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 106 bytes --]


Please queue up the following networking bug fixes for 4.14.x and
4.17.x -stable, respectively.

Thanks!

[-- Attachment #2: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 31040 bytes --]

[-- Attachment #3: net_417.mbox --]
[-- Type: Application/Octet-Stream, Size: 53786 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-07-26 23:50 David Miller
  2018-07-27  0:06 ` Eric Dumazet
@ 2018-07-27  6:34 ` Greg KH
  1 sibling, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-07-27  6:34 UTC (permalink / raw)
  To: David Miller; +Cc: stable, edumazet

On Thu, Jul 26, 2018 at 04:50:51PM -0700, David Miller wrote:
> 
> [ Eric please double check my TCP backports, thank you... ]
> 
> Please queue up the following networking fixes for v4.14.x and v4.17.x
> -stable, respectively.

All now queued up, many thanks for these.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-07-26 23:50 David Miller
@ 2018-07-27  0:06 ` Eric Dumazet
  2018-07-27  6:34 ` Greg KH
  1 sibling, 0 replies; 213+ messages in thread
From: Eric Dumazet @ 2018-07-27  0:06 UTC (permalink / raw)
  To: David Miller; +Cc: stable

Hi David

SGTM for TCP patches.

Thanks !

On Thu, Jul 26, 2018 at 4:51 PM David Miller <davem@davemloft.net> wrote:
>
>
> [ Eric please double check my TCP backports, thank you... ]
>
> Please queue up the following networking fixes for v4.14.x and v4.17.x
> -stable, respectively.
>
> Thank you!

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-07-26 23:50 David Miller
  2018-07-27  0:06 ` Eric Dumazet
  2018-07-27  6:34 ` Greg KH
  0 siblings, 2 replies; 213+ messages in thread
From: David Miller @ 2018-07-26 23:50 UTC (permalink / raw)
  To: stable; +Cc: edumazet

[-- Attachment #1: Type: Text/Plain, Size: 168 bytes --]


[ Eric please double check my TCP backports, thank you... ]

Please queue up the following networking fixes for v4.14.x and v4.17.x
-stable, respectively.

Thank you!

[-- Attachment #2: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 76177 bytes --]

[-- Attachment #3: net_417.mbox --]
[-- Type: Application/Octet-Stream, Size: 101773 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-07-23  3:51 David Miller
@ 2018-07-23  6:21 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-07-23  6:21 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Sun, Jul 22, 2018 at 08:51:17PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixxes for 4.14.x and
> 4.17.x -stable, respectively.
> 
> Thanks!

All now applied, thanks.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-07-23  3:51 David Miller
  2018-07-23  6:21 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-07-23  3:51 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 107 bytes --]


Please queue up the following networking bug fixxes for 4.14.x and
4.17.x -stable, respectively.

Thanks!

[-- Attachment #2: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 34759 bytes --]

[-- Attachment #3: net_417.mbox --]
[-- Type: Application/Octet-Stream, Size: 63061 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-07-18 23:35 David Miller
@ 2018-07-19  6:33 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-07-19  6:33 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Jul 19, 2018 at 08:35:57AM +0900, David Miller wrote:
> 
> ====================
> READ ME.  I have this stale email in my outgoing draft folder, and I
> have no idea if I actually sent this out successfully or not.
> 
> Please double check, thanks!

Nope, I have not seen these patches before at all.  Thanks for them, all
now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-07-18 23:35 David Miller
  2018-07-19  6:33 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-07-18 23:35 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 310 bytes --]


====================
READ ME.  I have this stale email in my outgoing draft folder, and I
have no idea if I actually sent this out successfully or not.

Please double check, thanks!
====================

Please queue up the following networking bug fixes for v4.14 and v4.17
-stable, repectively.

Thank you!

[-- Attachment #2: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 98576 bytes --]

[-- Attachment #3: net_417.mbox --]
[-- Type: Application/Octet-Stream, Size: 144824 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-07-05 16:15     ` Greg KH
@ 2018-07-05 16:42       ` Ido Schimmel
  0 siblings, 0 replies; 213+ messages in thread
From: Ido Schimmel @ 2018-07-05 16:42 UTC (permalink / raw)
  To: Greg KH; +Cc: Jiri Slaby, David Miller, stable, jiri

On Thu, Jul 05, 2018 at 06:15:34PM +0200, Greg KH wrote:
> On Thu, Jun 07, 2018 at 01:47:34PM +0300, Ido Schimmel wrote:
> > On Thu, Jun 07, 2018 at 09:00:12AM +0200, Jiri Slaby wrote:
> > > On 09/15/2017, 06:57 AM, David Miller wrote:
> > > > Please queue up the following networking bug fixes for v4.9, v4.12, and
> > > > v4.13 -stable, respectively.
> > > 
> > > Hi,
> > > 
> > > while walking through some fixes, I wonder, whether backports of
> > > 25cc72a33835 (mlxsw: spectrum: Forbid linking to devices that have
> > >  uppers) to 4.9 and 4.12 are correct.
> > 
> > [...]
> > 
> > > 
> > > 
> > > Did I miss something or is this a mistake?
> > 
> > Your analysis looks correct to me. How do you want to proceed? Do you
> > want me to send you fixed backports for 4.9.y and 4.12.y?
> 
> Yes, can you send a fix for this?  4.12.y is end-of-life, so it doesn't
> matter, but 4.9.y does.

Yes, sure, will do that now. Sorry

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-06-07 10:47   ` Ido Schimmel
  2018-06-07 10:52     ` Greg KH
@ 2018-07-05 16:15     ` Greg KH
  2018-07-05 16:42       ` Ido Schimmel
  1 sibling, 1 reply; 213+ messages in thread
From: Greg KH @ 2018-07-05 16:15 UTC (permalink / raw)
  To: Ido Schimmel; +Cc: Jiri Slaby, David Miller, stable, jiri

On Thu, Jun 07, 2018 at 01:47:34PM +0300, Ido Schimmel wrote:
> On Thu, Jun 07, 2018 at 09:00:12AM +0200, Jiri Slaby wrote:
> > On 09/15/2017, 06:57 AM, David Miller wrote:
> > > Please queue up the following networking bug fixes for v4.9, v4.12, and
> > > v4.13 -stable, respectively.
> > 
> > Hi,
> > 
> > while walking through some fixes, I wonder, whether backports of
> > 25cc72a33835 (mlxsw: spectrum: Forbid linking to devices that have
> >  uppers) to 4.9 and 4.12 are correct.
> 
> [...]
> 
> > 
> > 
> > Did I miss something or is this a mistake?
> 
> Your analysis looks correct to me. How do you want to proceed? Do you
> want me to send you fixed backports for 4.9.y and 4.12.y?

Yes, can you send a fix for this?  4.12.y is end-of-life, so it doesn't
matter, but 4.9.y does.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-06-21 21:10 ` Greg KH
@ 2018-06-24 11:20   ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-06-24 11:20 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Fri, Jun 22, 2018 at 06:10:19AM +0900, Greg KH wrote:
> On Wed, Jun 20, 2018 at 09:37:12PM +0900, David Miller wrote:
> > 
> > Please queue up the following networking bug fixes for 4.16 and
> > 4.17 -stable, respectively.
> 
> 
> All now queued up, thanks.

Also, no need for you to care about 4.16 anymore, unless there is
something very serious, as I should only be doing one more release of
that kernel tree, in a day or so.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-06-20 12:37 David Miller
@ 2018-06-21 21:10 ` Greg KH
  2018-06-24 11:20   ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: Greg KH @ 2018-06-21 21:10 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Wed, Jun 20, 2018 at 09:37:12PM +0900, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 4.16 and
> 4.17 -stable, respectively.


All now queued up, thanks.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-06-20 12:37 David Miller
  2018-06-21 21:10 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-06-20 12:37 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 93 bytes --]


Please queue up the following networking bug fixes for 4.16 and
4.17 -stable, respectively.

[-- Attachment #2: net_416.mbox --]
[-- Type: Application/Octet-Stream, Size: 39039 bytes --]

[-- Attachment #3: net_417.mbox --]
[-- Type: Application/Octet-Stream, Size: 43591 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-06-08  2:18 David Miller
@ 2018-06-08  4:52 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-06-08  4:52 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Jun 07, 2018 at 10:18:39PM -0400, David Miller wrote:
> 
> Please queue up the following netwokring bug fixes for
> v4.16 and v4.17 -stable, respectively.

Thanks so much for these, all now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-06-08  2:18 David Miller
  2018-06-08  4:52 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-06-08  2:18 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 107 bytes --]


Please queue up the following netwokring bug fixes for
v4.16 and v4.17 -stable, respectively.

Thank you.

[-- Attachment #2: net_416.mbox --]
[-- Type: Application/Octet-Stream, Size: 130447 bytes --]

[-- Attachment #3: net_417.mbox --]
[-- Type: Application/Octet-Stream, Size: 44189 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-06-07 10:47   ` Ido Schimmel
@ 2018-06-07 10:52     ` Greg KH
  2018-07-05 16:15     ` Greg KH
  1 sibling, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-06-07 10:52 UTC (permalink / raw)
  To: Ido Schimmel; +Cc: Jiri Slaby, David Miller, stable, jiri

On Thu, Jun 07, 2018 at 01:47:34PM +0300, Ido Schimmel wrote:
> On Thu, Jun 07, 2018 at 09:00:12AM +0200, Jiri Slaby wrote:
> > On 09/15/2017, 06:57 AM, David Miller wrote:
> > > Please queue up the following networking bug fixes for v4.9, v4.12, and
> > > v4.13 -stable, respectively.
> > 
> > Hi,
> > 
> > while walking through some fixes, I wonder, whether backports of
> > 25cc72a33835 (mlxsw: spectrum: Forbid linking to devices that have
> >  uppers) to 4.9 and 4.12 are correct.
> 
> [...]
> 
> > 
> > 
> > Did I miss something or is this a mistake?
> 
> Your analysis looks correct to me. How do you want to proceed? Do you
> want me to send you fixed backports for 4.9.y and 4.12.y?

4.12.y is long gone end-of-life, so there's nothing we can do there.

But I'll gladly take a fix-up patch for 4.9.y, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-06-07  7:00 ` Jiri Slaby
  2018-06-07  9:21   ` Greg KH
@ 2018-06-07 10:47   ` Ido Schimmel
  2018-06-07 10:52     ` Greg KH
  2018-07-05 16:15     ` Greg KH
  1 sibling, 2 replies; 213+ messages in thread
From: Ido Schimmel @ 2018-06-07 10:47 UTC (permalink / raw)
  To: Jiri Slaby; +Cc: David Miller, stable, Greg KH, jiri

On Thu, Jun 07, 2018 at 09:00:12AM +0200, Jiri Slaby wrote:
> On 09/15/2017, 06:57 AM, David Miller wrote:
> > Please queue up the following networking bug fixes for v4.9, v4.12, and
> > v4.13 -stable, respectively.
> 
> Hi,
> 
> while walking through some fixes, I wonder, whether backports of
> 25cc72a33835 (mlxsw: spectrum: Forbid linking to devices that have
>  uppers) to 4.9 and 4.12 are correct.

[...]

> 
> 
> Did I miss something or is this a mistake?

Your analysis looks correct to me. How do you want to proceed? Do you
want me to send you fixed backports for 4.9.y and 4.12.y?

Thanks for noticing this.

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-06-07  7:00 ` Jiri Slaby
@ 2018-06-07  9:21   ` Greg KH
  2018-06-07 10:47   ` Ido Schimmel
  1 sibling, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-06-07  9:21 UTC (permalink / raw)
  To: Jiri Slaby; +Cc: David Miller, stable, idosch, jiri

On Thu, Jun 07, 2018 at 09:00:12AM +0200, Jiri Slaby wrote:
> On 09/15/2017, 06:57 AM, David Miller wrote:
> > Please queue up the following networking bug fixes for v4.9, v4.12, and
> > v4.13 -stable, respectively.
> 
> Hi,
> 
> while walking through some fixes, I wonder, whether backports of
> 25cc72a33835 (mlxsw: spectrum: Forbid linking to devices that have
>  uppers) to 4.9 and 4.12 are correct.
> 
> Part of the original commit:
> --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
> @@ -4139,6 +4139,8 @@ static int
> mlxsw_sp_netdevice_port_upper_event(struct net_device *lower_dev,
>                         return -EINVAL;
>                 if (!info->linking)
>                         break;
> +               if (netdev_has_any_upper_dev(upper_dev))
> +                       return -EINVAL;
>                 if (netif_is_lag_master(upper_dev) &&
>                     !mlxsw_sp_master_lag_check(mlxsw_sp, upper_dev,
>                                                info->upper_info))
> @@ -4258,6 +4260,10 @@ static int
> mlxsw_sp_netdevice_port_vlan_event(struct net_device *vlan_dev,
>                 upper_dev = info->upper_dev;
>                 if (!netif_is_bridge_master(upper_dev))
>                         return -EINVAL;
> +               if (!info->linking)
> +                       break;
> +               if (netdev_has_any_upper_dev(upper_dev))
> +                       return -EINVAL;
>                 break;
>         case NETDEV_CHANGEUPPER:
>                 upper_dev = info->upper_dev;
> 
> 
> 
> It changes mlxsw_sp_netdevice_port_upper_event and
> mlxsw_sp_netdevice_port_vlan_event.
> 
> 
> 
> 
> 4.9 backport (73ee5a73e75):
> --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
> @@ -4172,6 +4172,8 @@ static int
> mlxsw_sp_netdevice_port_upper_event(struct net_device *dev,
>                         return -EINVAL;
>                 if (!info->linking)
>                         break;
> +               if (netdev_has_any_upper_dev(upper_dev))
> +                       return -EINVAL;
>                 /* HW limitation forbids to put ports to multiple
> bridges. */
>                 if (netif_is_bridge_master(upper_dev) &&
>                     !mlxsw_sp_master_bridge_check(mlxsw_sp, upper_dev))
> @@ -4185,6 +4187,10 @@ static int
> mlxsw_sp_netdevice_port_upper_event(struct net_device *dev,
>                 if (netif_is_lag_port(dev) && is_vlan_dev(upper_dev) &&
>                     !netif_is_lag_master(vlan_dev_real_dev(upper_dev)))
>                         return -EINVAL;
> +               if (!info->linking)
> +                       break;
> +               if (netdev_has_any_upper_dev(upper_dev))
> +                       return -EINVAL;
>                 break;
>         case NETDEV_CHANGEUPPER:
>                 upper_dev = info->upper_dev;
> 
> 
> 
> 
> It changes mlxsw_sp_netdevice_port_upper_event *twice* instead of
> mlxsw_sp_netdevice_port_vlan_event, which was named
> mlxsw_sp_netdevice_vport_event in 4.9 yet.
> 
> 
> 
> 
> 
> 4.12 backport (2f4232ba8001):
> --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
> @@ -4110,6 +4110,8 @@ static int
> mlxsw_sp_netdevice_port_upper_event(struct net_device *dev,
>                         return -EINVAL;
>                 if (!info->linking)
>                         break;
> +               if (netdev_has_any_upper_dev(upper_dev))
> +                       return -EINVAL;
>                 /* HW limitation forbids to put ports to multiple
> bridges. */
G>                 if (netif_is_bridge_master(upper_dev) &&
>                     !mlxsw_sp_master_bridge_check(mlxsw_sp, upper_dev))
> @@ -4274,6 +4276,10 @@ static int mlxsw_sp_netdevice_bridge_event(struct
> net_device *br_dev,
>                 if (is_vlan_dev(upper_dev) &&
>                     br_dev != mlxsw_sp->master_bridge.dev)
>                         return -EINVAL;
> +               if (!info->linking)
> +                       break;
> +               if (netdev_has_any_upper_dev(upper_dev))
> +                       return -EINVAL;
>                 break;
>         case NETDEV_CHANGEUPPER:
>                 upper_dev = info->upper_dev;
> 
> 
> 
> It changes mlxsw_sp_netdevice_port_upper_event (OK) and
> mlxsw_sp_netdevice_bridge_event (not OK) instead of
> mlxsw_sp_netdevice_vport_event.
> 
> 
> Did I miss something or is this a mistake?

Looks odd to me, want me to revert this from 4.9?  Without the hardware,
I doubt anyone has noticed this issue.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-09-15  4:57 David Miller
  2017-09-15  6:24 ` Greg KH
@ 2018-06-07  7:00 ` Jiri Slaby
  2018-06-07  9:21   ` Greg KH
  2018-06-07 10:47   ` Ido Schimmel
  1 sibling, 2 replies; 213+ messages in thread
From: Jiri Slaby @ 2018-06-07  7:00 UTC (permalink / raw)
  To: David Miller, stable, Greg KH, idosch, jiri

On 09/15/2017, 06:57 AM, David Miller wrote:
> Please queue up the following networking bug fixes for v4.9, v4.12, and
> v4.13 -stable, respectively.

Hi,

while walking through some fixes, I wonder, whether backports of
25cc72a33835 (mlxsw: spectrum: Forbid linking to devices that have
 uppers) to 4.9 and 4.12 are correct.

Part of the original commit:
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -4139,6 +4139,8 @@ static int
mlxsw_sp_netdevice_port_upper_event(struct net_device *lower_dev,
                        return -EINVAL;
                if (!info->linking)
                        break;
+               if (netdev_has_any_upper_dev(upper_dev))
+                       return -EINVAL;
                if (netif_is_lag_master(upper_dev) &&
                    !mlxsw_sp_master_lag_check(mlxsw_sp, upper_dev,
                                               info->upper_info))
@@ -4258,6 +4260,10 @@ static int
mlxsw_sp_netdevice_port_vlan_event(struct net_device *vlan_dev,
                upper_dev = info->upper_dev;
                if (!netif_is_bridge_master(upper_dev))
                        return -EINVAL;
+               if (!info->linking)
+                       break;
+               if (netdev_has_any_upper_dev(upper_dev))
+                       return -EINVAL;
                break;
        case NETDEV_CHANGEUPPER:
                upper_dev = info->upper_dev;



It changes mlxsw_sp_netdevice_port_upper_event and
mlxsw_sp_netdevice_port_vlan_event.




4.9 backport (73ee5a73e75):
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -4172,6 +4172,8 @@ static int
mlxsw_sp_netdevice_port_upper_event(struct net_device *dev,
                        return -EINVAL;
                if (!info->linking)
                        break;
+               if (netdev_has_any_upper_dev(upper_dev))
+                       return -EINVAL;
                /* HW limitation forbids to put ports to multiple
bridges. */
                if (netif_is_bridge_master(upper_dev) &&
                    !mlxsw_sp_master_bridge_check(mlxsw_sp, upper_dev))
@@ -4185,6 +4187,10 @@ static int
mlxsw_sp_netdevice_port_upper_event(struct net_device *dev,
                if (netif_is_lag_port(dev) && is_vlan_dev(upper_dev) &&
                    !netif_is_lag_master(vlan_dev_real_dev(upper_dev)))
                        return -EINVAL;
+               if (!info->linking)
+                       break;
+               if (netdev_has_any_upper_dev(upper_dev))
+                       return -EINVAL;
                break;
        case NETDEV_CHANGEUPPER:
                upper_dev = info->upper_dev;




It changes mlxsw_sp_netdevice_port_upper_event *twice* instead of
mlxsw_sp_netdevice_port_vlan_event, which was named
mlxsw_sp_netdevice_vport_event in 4.9 yet.





4.12 backport (2f4232ba8001):
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -4110,6 +4110,8 @@ static int
mlxsw_sp_netdevice_port_upper_event(struct net_device *dev,
                        return -EINVAL;
                if (!info->linking)
                        break;
+               if (netdev_has_any_upper_dev(upper_dev))
+                       return -EINVAL;
                /* HW limitation forbids to put ports to multiple
bridges. */
                if (netif_is_bridge_master(upper_dev) &&
                    !mlxsw_sp_master_bridge_check(mlxsw_sp, upper_dev))
@@ -4274,6 +4276,10 @@ static int mlxsw_sp_netdevice_bridge_event(struct
net_device *br_dev,
                if (is_vlan_dev(upper_dev) &&
                    br_dev != mlxsw_sp->master_bridge.dev)
                        return -EINVAL;
+               if (!info->linking)
+                       break;
+               if (netdev_has_any_upper_dev(upper_dev))
+                       return -EINVAL;
                break;
        case NETDEV_CHANGEUPPER:
                upper_dev = info->upper_dev;



It changes mlxsw_sp_netdevice_port_upper_event (OK) and
mlxsw_sp_netdevice_bridge_event (not OK) instead of
mlxsw_sp_netdevice_vport_event.


Did I miss something or is this a mistake?

thanks,
-- 
js
suse labs

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-05-15 20:50 David Miller
@ 2018-05-16  8:40 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-05-16  8:40 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, May 15, 2018 at 04:50:36PM -0400, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.14 and v4.16
> -stable, respectively.

Thanks for these, all now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-05-15 20:50 David Miller
  2018-05-16  8:40 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-05-15 20:50 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 104 bytes --]


Please queue up the following networking bug fixes for v4.14 and v4.16
-stable, respectively.

Thanks!

[-- Attachment #2: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 121278 bytes --]

[-- Attachment #3: net_416.mbox --]
[-- Type: Application/Octet-Stream, Size: 154383 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-04-26 18:38 David Miller
@ 2018-04-26 18:50 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-04-26 18:50 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Apr 26, 2018 at 02:38:48PM -0400, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.14 and
> v4.16 -stable, respectively.

All now queued up, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-04-26 18:38 David Miller
  2018-04-26 18:50 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-04-26 18:38 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 107 bytes --]


Please queue up the following networking bug fixes for v4.14 and
v4.16 -stable, respectively.

Thank you.

[-- Attachment #2: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 112995 bytes --]

[-- Attachment #3: net_416.mbox --]
[-- Type: Application/Octet-Stream, Size: 170289 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-04-13 17:47 David Miller
@ 2018-04-14 14:04 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-04-14 14:04 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Fri, Apr 13, 2018 at 01:47:16PM -0400, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.4 and
> v4.16 -stable, respectively.
> 
> Note, you may wish to take patch "vhost: fix vhost_vq_access_ok() log check"
> (upsteam d14d2b78090c7de0557362b26a4ca591aa6a9faa) for v4.15 as well
> because the change it is fixing went into v4.15.17

Thanks, all now queued up.  I threw all of the 4.16 patches into 4.15,
as they looked good :)

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-04-13 17:47 David Miller
  2018-04-14 14:04 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-04-13 17:47 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 301 bytes --]


Please queue up the following networking bug fixes for v4.4 and
v4.16 -stable, respectively.

Note, you may wish to take patch "vhost: fix vhost_vq_access_ok() log check"
(upsteam d14d2b78090c7de0557362b26a4ca591aa6a9faa) for v4.15 as well
because the change it is fixing went into v4.15.17

Thanks!

[-- Attachment #2: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 11356 bytes --]

[-- Attachment #3: net_416.mbox --]
[-- Type: Application/Octet-Stream, Size: 27715 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-04-10 19:39 David Miller
@ 2018-04-10 21:26 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-04-10 21:26 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, Apr 10, 2018 at 03:39:19PM -0400, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.14,
> v4.15, and v4.16 -stable, respectively.

Many thanks for all of these, now queued up.

No need to worry about 4.15 anymore, it will probably go end-of-life
late next week, so unless there is something "major" needed for it, I
wouldn't worry about making patches up for it anymore.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-04-10 19:39 David Miller
  2018-04-10 21:26 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-04-10 19:39 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 115 bytes --]


Please queue up the following networking bug fixes for v4.14,
v4.15, and v4.16 -stable, respectively.

Thank you!

[-- Attachment #2: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 110394 bytes --]

[-- Attachment #3: net_415.mbox --]
[-- Type: Application/Octet-Stream, Size: 127546 bytes --]

[-- Attachment #4: net_416.mbox --]
[-- Type: Application/Octet-Stream, Size: 40361 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-03-28 15:35 David Miller
  2018-03-28 15:40 ` Willy Tarreau
@ 2018-03-28 16:49 ` Greg KH
  1 sibling, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-03-28 16:49 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Wed, Mar 28, 2018 at 11:35:10AM -0400, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.14 and v4.15
> -stable, respecetively.

Thanks so much for these, now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-03-28 15:46   ` David Miller
@ 2018-03-28 16:36     ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-03-28 16:36 UTC (permalink / raw)
  To: David Miller; +Cc: w, stable

On Wed, Mar 28, 2018 at 11:46:05AM -0400, David Miller wrote:
> From: Willy Tarreau <w@1wt.eu>
> Date: Wed, 28 Mar 2018 17:40:15 +0200
> 
> > Hi David,
> > 
> > On Wed, Mar 28, 2018 at 11:35:10AM -0400, David Miller wrote:
> >> 
> >> Please queue up the following networking bug fixes for v4.14 and v4.15
> >> -stable, respecetively.
> > 
> > I don't know if you saw my e-mail last week about this patch that's
> > part of the 4.14 queue :
> > 
> >    [linux-stable-4.14] tcp: reset sk_send_head in tcp_write_queue_purge
> > 
> > There are some typos in commit IDs referenced in the commit message
> > which I think should be edited before being merged (especially since
> > this one is stable-only and not in mainline) :
> > 
> >     "27fid7a8ed38"  => "a27fd7a8ed38"
> >     "a27fid7a8ed38" => "a27fd7a8ed38"  (Fixes: line)
> > 
> > Greg, maybe it's better to edit this before applying ?
> 
> Greg, feel free to correct this.

Now fixed up, thanks.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-03-28 15:40 ` Willy Tarreau
@ 2018-03-28 15:46   ` David Miller
  2018-03-28 16:36     ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-03-28 15:46 UTC (permalink / raw)
  To: w; +Cc: stable

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 28 Mar 2018 17:40:15 +0200

> Hi David,
> 
> On Wed, Mar 28, 2018 at 11:35:10AM -0400, David Miller wrote:
>> 
>> Please queue up the following networking bug fixes for v4.14 and v4.15
>> -stable, respecetively.
> 
> I don't know if you saw my e-mail last week about this patch that's
> part of the 4.14 queue :
> 
>    [linux-stable-4.14] tcp: reset sk_send_head in tcp_write_queue_purge
> 
> There are some typos in commit IDs referenced in the commit message
> which I think should be edited before being merged (especially since
> this one is stable-only and not in mainline) :
> 
>     "27fid7a8ed38"  => "a27fd7a8ed38"
>     "a27fid7a8ed38" => "a27fd7a8ed38"  (Fixes: line)
> 
> Greg, maybe it's better to edit this before applying ?

Greg, feel free to correct this.

Thanks Willy.

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-03-28 15:35 David Miller
@ 2018-03-28 15:40 ` Willy Tarreau
  2018-03-28 15:46   ` David Miller
  2018-03-28 16:49 ` Greg KH
  1 sibling, 1 reply; 213+ messages in thread
From: Willy Tarreau @ 2018-03-28 15:40 UTC (permalink / raw)
  To: David Miller; +Cc: stable

Hi David,

On Wed, Mar 28, 2018 at 11:35:10AM -0400, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.14 and v4.15
> -stable, respecetively.

I don't know if you saw my e-mail last week about this patch that's
part of the 4.14 queue :

   [linux-stable-4.14] tcp: reset sk_send_head in tcp_write_queue_purge

There are some typos in commit IDs referenced in the commit message
which I think should be edited before being merged (especially since
this one is stable-only and not in mainline) :

    "27fid7a8ed38"  => "a27fd7a8ed38"
    "a27fid7a8ed38" => "a27fd7a8ed38"  (Fixes: line)

Greg, maybe it's better to edit this before applying ?

Thanks,
Willy

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-03-28 15:35 David Miller
  2018-03-28 15:40 ` Willy Tarreau
  2018-03-28 16:49 ` Greg KH
  0 siblings, 2 replies; 213+ messages in thread
From: David Miller @ 2018-03-28 15:35 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 108 bytes --]


Please queue up the following networking bug fixes for v4.14 and v4.15
-stable, respecetively.

Thank you!

[-- Attachment #2: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 105642 bytes --]

[-- Attachment #3: net_415.mbox --]
[-- Type: Application/Octet-Stream, Size: 116494 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-03-07  2:28 David Miller
@ 2018-03-07  3:30 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-03-07  3:30 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, Mar 06, 2018 at 09:28:33PM -0500, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.14 and
> v4.15 -stable, respectively.

Many thanks for these, all now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-03-07  2:28 David Miller
  2018-03-07  3:30 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-03-07  2:28 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 107 bytes --]


Please queue up the following networking bug fixes for v4.14 and
v4.15 -stable, respectively.

Thank you.

[-- Attachment #2: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 116820 bytes --]

[-- Attachment #3: net_415.mbox --]
[-- Type: Application/Octet-Stream, Size: 163008 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-02-06 20:19 David Miller
@ 2018-02-07 19:39 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-02-07 19:39 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, Feb 06, 2018 at 03:19:49PM -0500, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 4.9.x, 4.14.x,
> and 4.15.x -stable, respectively.

Many thanks for all of these, now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-02-06 20:19 David Miller
  2018-02-07 19:39 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-02-06 20:19 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 114 bytes --]


Please queue up the following networking bug fixes for 4.9.x, 4.14.x,
and 4.15.x -stable, respectively.

Thanks!

[-- Attachment #2: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 36882 bytes --]

[-- Attachment #3: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 44815 bytes --]

[-- Attachment #4: net_415.mbox --]
[-- Type: Application/Octet-Stream, Size: 62943 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-01-28 16:22 David Miller
@ 2018-01-28 16:39 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-01-28 16:39 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Sun, Jan 28, 2018 at 11:22:33AM -0500, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.9
> and v4.14 -stable, respectively.

Thanks so much, all now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-01-28 16:22 David Miller
  2018-01-28 16:39 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-01-28 16:22 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 106 bytes --]


Please queue up the following networking bug fixes for v4.9
and v4.14 -stable, respectively.

Thank you.

[-- Attachment #2: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 57900 bytes --]

[-- Attachment #3: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 88875 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2018-01-12 21:12 David Miller
@ 2018-01-13  9:54 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2018-01-13  9:54 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Fri, Jan 12, 2018 at 04:12:07PM -0500, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.9 and
> v4.14 -stable, respecetively.

Thanks for these, now all queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2018-01-12 21:12 David Miller
  2018-01-13  9:54 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2018-01-12 21:12 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 107 bytes --]


Please queue up the following networking bug fixes for v4.9 and
v4.14 -stable, respecetively.

Thank you!

[-- Attachment #2: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 21035 bytes --]

[-- Attachment #3: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 42218 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-12-31  4:15 David Miller
@ 2017-12-31 10:14 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-12-31 10:14 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Sat, Dec 30, 2017 at 11:15:02PM -0500, David Miller wrote:
> 
> Thought you'd make it into 2018 without some more networking
> bug fixes?  Think again! :-)
> 
> Please queue up the following networking bug fixes for 4.9.x
> and 4.14.x -stable, respectively.

Nice!

Thanks for all of these, now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-12-31  4:15 David Miller
  2017-12-31 10:14 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-12-31  4:15 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 196 bytes --]


Thought you'd make it into 2018 without some more networking
bug fixes?  Think again! :-)

Please queue up the following networking bug fixes for 4.9.x
and 4.14.x -stable, respectively.

Thanks!

[-- Attachment #2: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 98232 bytes --]

[-- Attachment #3: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 157183 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-12-12 15:44 David Miller
@ 2017-12-14 17:51 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-12-14 17:51 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, Dec 12, 2017 at 10:44:45AM -0500, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.9 and v4.14 -stable,
> respectively.

Now both applied, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-12-12 15:44 David Miller
  2017-12-14 17:51 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-12-12 15:44 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 106 bytes --]


Please queue up the following networking bug fixes for v4.9 and v4.14 -stable,
respectively.

Thank you!

[-- Attachment #2: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 48430 bytes --]

[-- Attachment #3: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 111700 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-11-20 11:47 David Miller
@ 2017-11-21 14:04 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-11-21 14:04 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Mon, Nov 20, 2017 at 08:47:27PM +0900, David Miller wrote:
> 
> Please queue up the following networking fixes for 4.9.x,
> 4.13.x, and 4.14.x -stable, respectively.

Wonderful, thanks for these, they are all now queued up.

Note, you don't have to do anything for 4.13.x anymore, I'll be marking
it end-of-life in a few days or so.

thanks again,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-11-20 11:47 David Miller
  2017-11-21 14:04 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-11-20 11:47 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 113 bytes --]


Please queue up the following networking fixes for 4.9.x,
4.13.x, and 4.14.x -stable, respectively.

Thank you.

[-- Attachment #2: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 32991 bytes --]

[-- Attachment #3: net_413.mbox --]
[-- Type: Application/Octet-Stream, Size: 56871 bytes --]

[-- Attachment #4: net_414.mbox --]
[-- Type: Application/Octet-Stream, Size: 13827 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-11-14  6:36 David Miller
@ 2017-11-16 14:12 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-11-16 14:12 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, Nov 14, 2017 at 03:36:24PM +0900, David Miller wrote:
> 
> Please queue up the following bug fixes to 4.9.x and
> 4.13.x -stable, respectively.

All now queued up, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-11-14  6:36 David Miller
  2017-11-16 14:12 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-11-14  6:36 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 96 bytes --]


Please queue up the following bug fixes to 4.9.x and
4.13.x -stable, respectively.

Thank you!

[-- Attachment #2: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 80884 bytes --]

[-- Attachment #3: net_413.mbox --]
[-- Type: Application/Octet-Stream, Size: 110300 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-10-09 22:54         ` David Miller
@ 2017-10-10 14:10           ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-10-10 14:10 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Mon, Oct 09, 2017 at 03:54:34PM -0700, David Miller wrote:
> From: Greg KH <greg@kroah.com>
> Date: Mon, 9 Oct 2017 21:04:20 +0200
> 
> > On Mon, Oct 09, 2017 at 09:55:02AM -0700, David Miller wrote:
> >> From: Greg KH <greg@kroah.com>
> >> Date: Mon, 9 Oct 2017 09:56:48 +0200
> >> 
> >> > On Mon, Oct 09, 2017 at 09:34:06AM +0200, Greg KH wrote:
> >> >> On Sun, Oct 08, 2017 at 09:02:19PM -0700, David Miller wrote:
> >> >> > 
> >> >> > Please queue up the following bug fixes for 4.13.x -stable.
> >> >> 
> >> >> Thanks for the patches, all now queued up.
> >> > 
> >> > Oh, just curious, are you going to have a mbox of patches for 4.9-stable
> >> > as well?  If not, no worries, I'll do the backporting, just didn't want
> >> > to duplicate any work here.
> >> 
> >> Let me see if I can cook that up today, otherwise I'll let you know that
> >> I won't be able to do it.
> >> 
> >> You know what actually happened?  I got confused by the ordering of the
> >> stable trees on www.kernel.org, I think it should be ordered by release
> >> number rather than trying to group 'stable' vs. 'longterm'.
> > 
> > Ah, crap, that's my fault, let me go fix the website, it should be
> > ordered that way, I messed up when I marked 3.4 as EOL, but forgot to do
> > it in the scripts so the front page would be correct.
> > 
> > Should be resolved in 30 minutes or so, whenever the backend syncs to
> > the front-facing servers.
> 
> Thanks a lot.
> 
> Attached are the 4.9 networking -stable backports:

Many thanks for these, all now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-10-09 19:04       ` Greg KH
@ 2017-10-09 22:54         ` David Miller
  2017-10-10 14:10           ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-10-09 22:54 UTC (permalink / raw)
  To: greg; +Cc: stable

[-- Attachment #1: Type: Text/Plain, Size: 1367 bytes --]

From: Greg KH <greg@kroah.com>
Date: Mon, 9 Oct 2017 21:04:20 +0200

> On Mon, Oct 09, 2017 at 09:55:02AM -0700, David Miller wrote:
>> From: Greg KH <greg@kroah.com>
>> Date: Mon, 9 Oct 2017 09:56:48 +0200
>> 
>> > On Mon, Oct 09, 2017 at 09:34:06AM +0200, Greg KH wrote:
>> >> On Sun, Oct 08, 2017 at 09:02:19PM -0700, David Miller wrote:
>> >> > 
>> >> > Please queue up the following bug fixes for 4.13.x -stable.
>> >> 
>> >> Thanks for the patches, all now queued up.
>> > 
>> > Oh, just curious, are you going to have a mbox of patches for 4.9-stable
>> > as well?  If not, no worries, I'll do the backporting, just didn't want
>> > to duplicate any work here.
>> 
>> Let me see if I can cook that up today, otherwise I'll let you know that
>> I won't be able to do it.
>> 
>> You know what actually happened?  I got confused by the ordering of the
>> stable trees on www.kernel.org, I think it should be ordered by release
>> number rather than trying to group 'stable' vs. 'longterm'.
> 
> Ah, crap, that's my fault, let me go fix the website, it should be
> ordered that way, I messed up when I marked 3.4 as EOL, but forgot to do
> it in the scripts so the front page would be correct.
> 
> Should be resolved in 30 minutes or so, whenever the backend syncs to
> the front-facing servers.

Thanks a lot.

Attached are the 4.9 networking -stable backports:

[-- Attachment #2: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 76262 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-10-09 16:55     ` David Miller
@ 2017-10-09 19:04       ` Greg KH
  2017-10-09 22:54         ` David Miller
  0 siblings, 1 reply; 213+ messages in thread
From: Greg KH @ 2017-10-09 19:04 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Mon, Oct 09, 2017 at 09:55:02AM -0700, David Miller wrote:
> From: Greg KH <greg@kroah.com>
> Date: Mon, 9 Oct 2017 09:56:48 +0200
> 
> > On Mon, Oct 09, 2017 at 09:34:06AM +0200, Greg KH wrote:
> >> On Sun, Oct 08, 2017 at 09:02:19PM -0700, David Miller wrote:
> >> > 
> >> > Please queue up the following bug fixes for 4.13.x -stable.
> >> 
> >> Thanks for the patches, all now queued up.
> > 
> > Oh, just curious, are you going to have a mbox of patches for 4.9-stable
> > as well?  If not, no worries, I'll do the backporting, just didn't want
> > to duplicate any work here.
> 
> Let me see if I can cook that up today, otherwise I'll let you know that
> I won't be able to do it.
> 
> You know what actually happened?  I got confused by the ordering of the
> stable trees on www.kernel.org, I think it should be ordered by release
> number rather than trying to group 'stable' vs. 'longterm'.

Ah, crap, that's my fault, let me go fix the website, it should be
ordered that way, I messed up when I marked 3.4 as EOL, but forgot to do
it in the scripts so the front page would be correct.

Should be resolved in 30 minutes or so, whenever the backend syncs to
the front-facing servers.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-10-09  7:56   ` Greg KH
@ 2017-10-09 16:55     ` David Miller
  2017-10-09 19:04       ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-10-09 16:55 UTC (permalink / raw)
  To: greg; +Cc: stable

From: Greg KH <greg@kroah.com>
Date: Mon, 9 Oct 2017 09:56:48 +0200

> On Mon, Oct 09, 2017 at 09:34:06AM +0200, Greg KH wrote:
>> On Sun, Oct 08, 2017 at 09:02:19PM -0700, David Miller wrote:
>> > 
>> > Please queue up the following bug fixes for 4.13.x -stable.
>> 
>> Thanks for the patches, all now queued up.
> 
> Oh, just curious, are you going to have a mbox of patches for 4.9-stable
> as well?  If not, no worries, I'll do the backporting, just didn't want
> to duplicate any work here.

Let me see if I can cook that up today, otherwise I'll let you know that
I won't be able to do it.

You know what actually happened?  I got confused by the ordering of the
stable trees on www.kernel.org, I think it should be ordered by release
number rather than trying to group 'stable' vs. 'longterm'.

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-10-09  7:34 ` Greg KH
@ 2017-10-09  7:56   ` Greg KH
  2017-10-09 16:55     ` David Miller
  0 siblings, 1 reply; 213+ messages in thread
From: Greg KH @ 2017-10-09  7:56 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Mon, Oct 09, 2017 at 09:34:06AM +0200, Greg KH wrote:
> On Sun, Oct 08, 2017 at 09:02:19PM -0700, David Miller wrote:
> > 
> > Please queue up the following bug fixes for 4.13.x -stable.
> 
> Thanks for the patches, all now queued up.

Oh, just curious, are you going to have a mbox of patches for 4.9-stable
as well?  If not, no worries, I'll do the backporting, just didn't want
to duplicate any work here.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-10-09  4:02 David Miller
@ 2017-10-09  7:34 ` Greg KH
  2017-10-09  7:56   ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: Greg KH @ 2017-10-09  7:34 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Sun, Oct 08, 2017 at 09:02:19PM -0700, David Miller wrote:
> 
> Please queue up the following bug fixes for 4.13.x -stable.

Thanks for the patches, all now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-10-09  4:02 David Miller
  2017-10-09  7:34 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-10-09  4:02 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 73 bytes --]


Please queue up the following bug fixes for 4.13.x -stable.

Thank you!

[-- Attachment #2: net_413.mbox --]
[-- Type: Application/Octet-Stream, Size: 117776 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-09-15  4:57 David Miller
@ 2017-09-15  6:24 ` Greg KH
  2018-06-07  7:00 ` Jiri Slaby
  1 sibling, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-09-15  6:24 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Sep 14, 2017 at 09:57:40PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.9, v4.12, and
> v4.13 -stable, respectively.

Many thanks for these, all now queued up.

No need to worry about 4.12 anymore, I'll only be doing one more release
of it.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-09-15  4:57 David Miller
  2017-09-15  6:24 ` Greg KH
  2018-06-07  7:00 ` Jiri Slaby
  0 siblings, 2 replies; 213+ messages in thread
From: David Miller @ 2017-09-15  4:57 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 114 bytes --]


Please queue up the following networking bug fixes for v4.9, v4.12, and
v4.13 -stable, respectively.

Thank you.

[-- Attachment #2: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 68612 bytes --]

[-- Attachment #3: net_412.mbox --]
[-- Type: Application/Octet-Stream, Size: 109712 bytes --]

[-- Attachment #4: net_413.mbox --]
[-- Type: Application/Octet-Stream, Size: 27421 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-08-24  3:24 David Miller
@ 2017-08-25  0:55 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-08-25  0:55 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Wed, Aug 23, 2017 at 08:24:49PM -0700, David Miller wrote:
> 
> Please queue up the following networking fixes for v4.9 and v4.12
> -stable, respectively.

All queued up, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-08-24  3:24 David Miller
  2017-08-25  0:55 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-08-24  3:24 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 102 bytes --]


Please queue up the following networking fixes for v4.9 and v4.12
-stable, respectively.

Thank you!

[-- Attachment #2: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 106165 bytes --]

[-- Attachment #3: net_412.mbox --]
[-- Type: Application/Octet-Stream, Size: 110306 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-08-11  5:25 David Miller
@ 2017-08-11 16:22 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-08-11 16:22 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Aug 10, 2017 at 10:25:42PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.9 and
> v4.12 -stable, respectively.

All now queued up, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-08-11  5:25 David Miller
  2017-08-11 16:22 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-08-11  5:25 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 106 bytes --]


Please queue up the following networking bug fixes for v4.9 and
v4.12 -stable, respectively.

Thank you!

[-- Attachment #2: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 33331 bytes --]

[-- Attachment #3: net_412.mbox --]
[-- Type: Application/Octet-Stream, Size: 43841 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-08-08 23:21 David Miller
@ 2017-08-08 23:30 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-08-08 23:30 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, Aug 08, 2017 at 04:21:26PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 4.9.x
> and 4.12.x -stable, respectively.

All queued up, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-08-08 23:21 David Miller
  2017-08-08 23:30 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-08-08 23:21 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 105 bytes --]


Please queue up the following networking bug fixes for 4.9.x
and 4.12.x -stable, respectively.

Thanks!

[-- Attachment #2: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 64761 bytes --]

[-- Attachment #3: net_412.mbox --]
[-- Type: Application/Octet-Stream, Size: 112411 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-07-17 19:23 ` Greg KH
@ 2017-07-19 10:27   ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-07-19 10:27 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Mon, Jul 17, 2017 at 09:23:15PM +0200, Greg KH wrote:
> On Mon, Jul 17, 2017 at 09:44:28AM -0700, David Miller wrote:
> > 
> > Please queue up the following networking bug fixes for v4.11 and
> > v4.12 -stable, respectively.
> 
> Applied to both trees, thanks!

Note, this is going to be the last 4.11.y kernel that I release, so no
need to make patches up for that tree anymore.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-07-17 16:44 David Miller
@ 2017-07-17 19:23 ` Greg KH
  2017-07-19 10:27   ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: Greg KH @ 2017-07-17 19:23 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Mon, Jul 17, 2017 at 09:44:28AM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.11 and
> v4.12 -stable, respectively.

Applied to both trees, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-07-17 16:44 David Miller
  2017-07-17 19:23 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-07-17 16:44 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 107 bytes --]


Please queue up the following networking bug fixes for v4.11 and
v4.12 -stable, respectively.

Thank you.

[-- Attachment #2: net_411.mbox --]
[-- Type: Application/Octet-Stream, Size: 84305 bytes --]

[-- Attachment #3: net_412.mbox --]
[-- Type: Application/Octet-Stream, Size: 54565 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-06-29 16:19 David Miller
@ 2017-06-29 17:34 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-06-29 17:34 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Jun 29, 2017 at 12:19:07PM -0400, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.9 and v4.11
> -stable, respectively.
> 
> Thank you!


Thanks for these, all now queued up!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-06-29 16:19 David Miller
  2017-06-29 17:34 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-06-29 16:19 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 106 bytes --]


Please queue up the following networking bug fixes for v4.9 and v4.11
-stable, respectively.

Thank you!

[-- Attachment #2: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 54035 bytes --]

[-- Attachment #3: net_411.mbox --]
[-- Type: Application/Octet-Stream, Size: 111327 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-05-30 23:14 David Miller
@ 2017-05-31  0:18 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-05-31  0:18 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, May 30, 2017 at 07:14:13PM -0400, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.9 and
> v4.11 -stable, respectively.

Thanks for these, all now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-05-30 23:14 David Miller
  2017-05-31  0:18 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-05-30 23:14 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 103 bytes --]


Please queue up the following networking bug fixes for v4.9 and
v4.11 -stable, respectively.

Thanks!

[-- Attachment #2: net_490.mbox --]
[-- Type: Application/Octet-Stream, Size: 104800 bytes --]

[-- Attachment #3: net_411.mbox --]
[-- Type: Application/Octet-Stream, Size: 130161 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-05-11  2:41 David Miller
  2017-05-11 13:10 ` Greg KH
@ 2017-05-22 10:16 ` Greg KH
  1 sibling, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-05-22 10:16 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Wed, May 10, 2017 at 10:41:30PM -0400, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 4.10
> and 4.11 -stable, respectively.

FWY, 4.10 is now dead, so no need to send me any more patches for that
tree.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-05-11  2:41 David Miller
@ 2017-05-11 13:10 ` Greg KH
  2017-05-22 10:16 ` Greg KH
  1 sibling, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-05-11 13:10 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Wed, May 10, 2017 at 10:41:30PM -0400, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 4.10
> and 4.11 -stable, respectively.

All queued up, thanks.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-05-11  2:41 David Miller
  2017-05-11 13:10 ` Greg KH
  2017-05-22 10:16 ` Greg KH
  0 siblings, 2 replies; 213+ messages in thread
From: David Miller @ 2017-05-11  2:41 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 105 bytes --]


Please queue up the following networking bug fixes for 4.10
and 4.11 -stable, respectively.

Thank you.

[-- Attachment #2: net_410.mbox --]
[-- Type: Application/Octet-Stream, Size: 53863 bytes --]

[-- Attachment #3: net_411.mbox --]
[-- Type: Application/Octet-Stream, Size: 61975 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-04-28 19:41 David Miller
@ 2017-04-29  6:23 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-04-29  6:23 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Fri, Apr 28, 2017 at 03:41:15PM -0400, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.9
> and v4.10 -stable, respectively.

Many thanks for these, all now applied.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-04-28 19:41 David Miller
  2017-04-29  6:23 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-04-28 19:41 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 103 bytes --]


Please queue up the following networking bug fixes for v4.9
and v4.10 -stable, respectively.

Thanks!

[-- Attachment #2: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 80505 bytes --]

[-- Attachment #3: net_410.mbox --]
[-- Type: Application/Octet-Stream, Size: 102818 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-03-25 17:38   ` David Miller
  2017-03-26 18:47     ` Thomas Backlund
@ 2017-03-27 16:19     ` Greg KH
  1 sibling, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-03-27 16:19 UTC (permalink / raw)
  To: David Miller; +Cc: tmb, stable

On Sat, Mar 25, 2017 at 10:38:59AM -0700, David Miller wrote:
> From: Thomas Backlund <tmb@mageia.org>
> Date: Sat, 25 Mar 2017 11:26:13 +0200
> 
> > Den 25.03.2017 kl. 09:53, skrev David Miller:
> >>
> >> Please queue up the following bug fixes for v4.9 and v4.10 -stable,
> >> respectively.
> >>
> >> Thanks!
> >>
> > 
> > The net_49.mbox is messed up...
> > 
> > besided the network related patches, it seems to contain every stable
> > patch from the 4.9.16 -> 4.9.17 update...
> 
> My bad, this one should be better:


Thanks for this, and the 4.10 mbox, all now applied.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-03-25 17:38   ` David Miller
@ 2017-03-26 18:47     ` Thomas Backlund
  2017-03-27 16:19     ` Greg KH
  1 sibling, 0 replies; 213+ messages in thread
From: Thomas Backlund @ 2017-03-26 18:47 UTC (permalink / raw)
  To: David Miller; +Cc: stable



Den 25.03.2017 kl. 19:38, skrev David Miller:
> From: Thomas Backlund <tmb@mageia.org>
> Date: Sat, 25 Mar 2017 11:26:13 +0200
>
>> Den 25.03.2017 kl. 09:53, skrev David Miller:
>>> Please queue up the following bug fixes for v4.9 and v4.10 -stable,
>>> respectively.
>>>
>>> Thanks!
>>>
>> The net_49.mbox is messed up...
>>
>> besided the network related patches, it seems to contain every stable
>> patch from the 4.9.16 -> 4.9.17 update...
> My bad, this one should be better:

That works, thanks!

--
Thomas

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-03-25  9:26 ` Thomas Backlund
@ 2017-03-25 17:38   ` David Miller
  2017-03-26 18:47     ` Thomas Backlund
  2017-03-27 16:19     ` Greg KH
  0 siblings, 2 replies; 213+ messages in thread
From: David Miller @ 2017-03-25 17:38 UTC (permalink / raw)
  To: tmb; +Cc: stable

[-- Attachment #1: Type: Text/Plain, Size: 426 bytes --]

From: Thomas Backlund <tmb@mageia.org>
Date: Sat, 25 Mar 2017 11:26:13 +0200

> Den 25.03.2017 kl. 09:53, skrev David Miller:
>>
>> Please queue up the following bug fixes for v4.9 and v4.10 -stable,
>> respectively.
>>
>> Thanks!
>>
> 
> The net_49.mbox is messed up...
> 
> besided the network related patches, it seems to contain every stable
> patch from the 4.9.16 -> 4.9.17 update...

My bad, this one should be better:

[-- Attachment #2: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 44435 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-03-25  7:53 David Miller
@ 2017-03-25  9:26 ` Thomas Backlund
  2017-03-25 17:38   ` David Miller
  0 siblings, 1 reply; 213+ messages in thread
From: Thomas Backlund @ 2017-03-25  9:26 UTC (permalink / raw)
  To: David Miller; +Cc: stable

Den 25.03.2017 kl. 09:53, skrev David Miller:
>
> Please queue up the following bug fixes for v4.9 and v4.10 -stable,
> respectively.
>
> Thanks!
>

The net_49.mbox is messed up...

besided the network related patches, it seems to contain every stable 
patch from the 4.9.16 -> 4.9.17 update...

--
Thomas

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-03-25  7:53 David Miller
  2017-03-25  9:26 ` Thomas Backlund
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-03-25  7:53 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 92 bytes --]


Please queue up the following bug fixes for v4.9 and v4.10 -stable,
respectively.

Thanks!

[-- Attachment #2: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 409918 bytes --]

[-- Attachment #3: net_410.mbox --]
[-- Type: Application/Octet-Stream, Size: 71179 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-03-17  1:48 David Miller
@ 2017-03-18 14:13 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-03-18 14:13 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Mar 16, 2017 at 06:48:04PM -0700, David Miller wrote:
> 
> Please queue up the following bug fixes for v4.9 and v4.10 -stable,
> respectively.

Many thanks for these, all now queued up!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-03-17  1:48 David Miller
  2017-03-18 14:13 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-03-17  1:48 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 95 bytes --]


Please queue up the following bug fixes for v4.9 and v4.10 -stable,
respectively.

Thank you!

[-- Attachment #2: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 123038 bytes --]

[-- Attachment #3: net_410.mbox --]
[-- Type: Application/Octet-Stream, Size: 127979 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-02-23 19:54 David Miller
@ 2017-02-23 20:19 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-02-23 20:19 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Feb 23, 2017 at 02:54:47PM -0500, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 4.4.x, 4.9.x,
> and 4.10.x -stable, respectively.

Wonderful, thanks so much for these, all now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-02-23 19:54 David Miller
  2017-02-23 20:19 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-02-23 19:54 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 113 bytes --]


Please queue up the following networking bug fixes for 4.4.x, 4.9.x,
and 4.10.x -stable, respectively.

Thanks!

[-- Attachment #2: net_44.mbox --]
[-- Type: Application/Octet-Stream, Size: 19842 bytes --]

[-- Attachment #3: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 37296 bytes --]

[-- Attachment #4: net_410.mbox --]
[-- Type: Application/Octet-Stream, Size: 7899 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-02-13 17:15 David Miller
@ 2017-02-15 17:21 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-02-15 17:21 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Mon, Feb 13, 2017 at 12:15:46PM -0500, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.4 and v4.9
> -stable, respectively.

All now applied, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-02-13 17:15 David Miller
  2017-02-15 17:21 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-02-13 17:15 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 102 bytes --]


Please queue up the following networking bug fixes for v4.4 and v4.9
-stable, respectively.

Thanks!

[-- Attachment #2: net_44.mbox --]
[-- Type: Application/Octet-Stream, Size: 57820 bytes --]

[-- Attachment #3: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 102372 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] networking
  2017-01-31 21:50 [PATCHES] networking David Miller
@ 2017-02-01  8:10 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-02-01  8:10 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, Jan 31, 2017 at 04:50:51PM -0500, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 4.4.x and
> 4.9.x -stable, respectively.

Many thanks for these, all now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] networking
@ 2017-01-31 21:50 David Miller
  2017-02-01  8:10 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-01-31 21:50 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 104 bytes --]


Please queue up the following networking bug fixes for 4.4.x and
4.9.x -stable, respectively.

Thanks!

[-- Attachment #2: net_44.mbox --]
[-- Type: Application/Octet-Stream, Size: 48703 bytes --]

[-- Attachment #3: net_49.mbox --]
[-- Type: Application/Octet-Stream, Size: 86650 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2017-01-12 18:55 [PATCHES] Networking David Miller
@ 2017-01-12 20:40 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2017-01-12 20:40 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Jan 12, 2017 at 01:55:10PM -0500, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 4.4.x and
> 4.9.x -stable, respectively.

All now queued up, many thanks for these.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2017-01-12 18:55 David Miller
  2017-01-12 20:40 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2017-01-12 18:55 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 104 bytes --]


Please queue up the following networking bug fixes for 4.4.x and
4.9.x -stable, respectively.

Thanks!

[-- Attachment #2: net_44.mbox --]
[-- Type: Application/Octet-Stream, Size: 39840 bytes --]

[-- Attachment #3: net_49.mbox --]
[-- Type: Text/Plain, Size: 74373 bytes --]

>From 501cfa4d001500e50ce519512616a2442093e13d Mon Sep 17 00:00:00 2001
From: David Ahern <dsa@cumulusnetworks.com>
Date: Wed, 14 Dec 2016 11:06:18 -0800
Subject: [PATCH 01/37] net: vrf: Fix NAT within a VRF

[ Upstream commit a0f37efa82253994b99623dbf41eea8dd0ba169b ]

Connection tracking with VRF is broken because the pass through the VRF
device drops the connection tracking info. Removing the call to nf_reset
allows DNAT and MASQUERADE to work across interfaces within a VRF.

Fixes: 73e20b761acf ("net: vrf: Add support for PREROUTING rules on vrf device")
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/vrf.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index 820de6a..5b995c4 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -850,8 +850,6 @@ static struct sk_buff *vrf_rcv_nfhook(u8 pf, unsigned int hook,
 {
 	struct net *net = dev_net(dev);
 
-	nf_reset(skb);
-
 	if (NF_HOOK(pf, hook, net, NULL, skb, dev, NULL, vrf_rcv_finish) < 0)
 		skb = NULL;    /* kfree_skb(skb) handled by nf code */
 
-- 
2.7.4


>From 9e335a84c686a198a10d7170f8c694a4bf1cbc2d Mon Sep 17 00:00:00 2001
From: David Ahern <dsa@cumulusnetworks.com>
Date: Wed, 14 Dec 2016 14:31:11 -0800
Subject: [PATCH 02/37] net: vrf: Drop conntrack data after pass through VRF
 device on Tx

[ Upstream commit eb63ecc1706b3e094d0f57438b6c2067cfc299f2 ]

Locally originated traffic in a VRF fails in the presence of a POSTROUTING
rule. For example,

    $ iptables -t nat -A POSTROUTING -s 11.1.1.0/24  -j MASQUERADE
    $ ping -I red -c1 11.1.1.3
    ping: Warning: source address might be selected on device other than red.
    PING 11.1.1.3 (11.1.1.3) from 11.1.1.2 red: 56(84) bytes of data.
    ping: sendmsg: Operation not permitted

Worse, the above causes random corruption resulting in a panic in random
places (I have not seen a consistent backtrace).

Call nf_reset to drop the conntrack info following the pass through the
VRF device.  The nf_reset is needed on Tx but not Rx because of the order
in which NF_HOOK's are hit: on Rx the VRF device is after the real ingress
device and on Tx it is is before the real egress device. Connection
tracking should be tied to the real egress device and not the VRF device.

Fixes: 8f58336d3f78a ("net: Add ethernet header for pass through VRF device")
Fixes: 35402e3136634 ("net: Add IPv6 support to VRF device")
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/vrf.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index 5b995c4..3cb3588 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -371,6 +371,8 @@ static int vrf_finish_output6(struct net *net, struct sock *sk,
 	struct in6_addr *nexthop;
 	int ret;
 
+	nf_reset(skb);
+
 	skb->protocol = htons(ETH_P_IPV6);
 	skb->dev = dev;
 
@@ -552,6 +554,8 @@ static int vrf_finish_output(struct net *net, struct sock *sk, struct sk_buff *s
 	u32 nexthop;
 	int ret = -EINVAL;
 
+	nf_reset(skb);
+
 	/* Be paranoid, rather than too clever. */
 	if (unlikely(skb_headroom(skb) < hh_len && dev->header_ops)) {
 		struct sk_buff *skb2;
-- 
2.7.4


>From 4960643b24acd5f1ac693b0eb6a9252538a76483 Mon Sep 17 00:00:00 2001
From: Xin Long <lucien.xin@gmail.com>
Date: Thu, 15 Dec 2016 23:05:52 +0800
Subject: [PATCH 03/37] sctp: sctp_transport_lookup_process should
 rcu_read_unlock when transport is null

[ Upstream commit 08abb79542c9e8c367d1d8e44fe1026868d3f0a7 ]

Prior to this patch, sctp_transport_lookup_process didn't rcu_read_unlock
when it failed to find a transport by sctp_addrs_lookup_transport.

This patch is to fix it by moving up rcu_read_unlock right before checking
transport and also to remove the out path.

Fixes: 1cceda784980 ("sctp: fix the issue sctp_diag uses lock_sock in rcu_read_lock")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/sctp/socket.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index f23ad91..ca12aa3 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4479,9 +4479,10 @@ int sctp_transport_lookup_process(int (*cb)(struct sctp_transport *, void *),
 
 	rcu_read_lock();
 	transport = sctp_addrs_lookup_transport(net, laddr, paddr);
-	if (!transport || !sctp_transport_hold(transport))
+	if (!transport || !sctp_transport_hold(transport)) {
+		rcu_read_unlock();
 		goto out;
-
+	}
 	rcu_read_unlock();
 	err = cb(transport, p);
 	sctp_transport_put(transport);
-- 
2.7.4


>From 44dec74396881da932e5d50ffac7e7b9bdcda86c Mon Sep 17 00:00:00 2001
From: Willem de Bruijn <willemb@google.com>
Date: Thu, 22 Dec 2016 18:19:16 -0500
Subject: [PATCH 04/37] inet: fix IP(V6)_RECVORIGDSTADDR for udp sockets

[ Upstream commit 39b2dd765e0711e1efd1d1df089473a8dd93ad48 ]

Socket cmsg IP(V6)_RECVORIGDSTADDR checks that port range lies within
the packet. For sockets that have transport headers pulled, transport
offset can be negative. Use signed comparison to avoid overflow.

Fixes: e6afc8ace6dd ("udp: remove headers from UDP packets before queueing")
Reported-by: Nisar Jagabar <njagabar@cloudmark.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/ip_sockglue.c | 2 +-
 net/ipv6/datagram.c    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index b8a2d63..e869773 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -137,7 +137,7 @@ static void ip_cmsg_recv_dstaddr(struct msghdr *msg, struct sk_buff *skb)
 	const struct iphdr *iph = ip_hdr(skb);
 	__be16 *ports = (__be16 *)skb_transport_header(skb);
 
-	if (skb_transport_offset(skb) + 4 > skb->len)
+	if (skb_transport_offset(skb) + 4 > (int)skb->len)
 		return;
 
 	/* All current transport protocols have the port numbers in the
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index ccf4055..8616d17 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -700,7 +700,7 @@ void ip6_datagram_recv_specific_ctl(struct sock *sk, struct msghdr *msg,
 		struct sockaddr_in6 sin6;
 		__be16 *ports = (__be16 *) skb_transport_header(skb);
 
-		if (skb_transport_offset(skb) + 4 <= skb->len) {
+		if (skb_transport_offset(skb) + 4 <= (int)skb->len) {
 			/* All current transport protocols have the port numbers in the
 			 * first four bytes of the transport header and this function is
 			 * written with this assumption in mind.
-- 
2.7.4


>From 234fdeb0974828952d834f4f9e0737ec9fa61fe1 Mon Sep 17 00:00:00 2001
From: Dave Jones <davej@codemonkey.org.uk>
Date: Thu, 22 Dec 2016 11:16:22 -0500
Subject: [PATCH 05/37] ipv6: handle -EFAULT from skb_copy_bits

[ Upstream commit a98f91758995cb59611e61318dddd8a6956b52c3 ]

By setting certain socket options on ipv6 raw sockets, we can confuse the
length calculation in rawv6_push_pending_frames triggering a BUG_ON.

RIP: 0010:[<ffffffff817c6390>] [<ffffffff817c6390>] rawv6_sendmsg+0xc30/0xc40
RSP: 0018:ffff881f6c4a7c18  EFLAGS: 00010282
RAX: 00000000fffffff2 RBX: ffff881f6c681680 RCX: 0000000000000002
RDX: ffff881f6c4a7cf8 RSI: 0000000000000030 RDI: ffff881fed0f6a00
RBP: ffff881f6c4a7da8 R08: 0000000000000000 R09: 0000000000000009
R10: ffff881fed0f6a00 R11: 0000000000000009 R12: 0000000000000030
R13: ffff881fed0f6a00 R14: ffff881fee39ba00 R15: ffff881fefa93a80

Call Trace:
 [<ffffffff8118ba23>] ? unmap_page_range+0x693/0x830
 [<ffffffff81772697>] inet_sendmsg+0x67/0xa0
 [<ffffffff816d93f8>] sock_sendmsg+0x38/0x50
 [<ffffffff816d982f>] SYSC_sendto+0xef/0x170
 [<ffffffff816da27e>] SyS_sendto+0xe/0x10
 [<ffffffff81002910>] do_syscall_64+0x50/0xa0
 [<ffffffff817f7cbc>] entry_SYSCALL64_slow_path+0x25/0x25

Handle by jumping to the failure path if skb_copy_bits gets an EFAULT.

Reproducer:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

#define LEN 504

int main(int argc, char* argv[])
{
	int fd;
	int zero = 0;
	char buf[LEN];

	memset(buf, 0, LEN);

	fd = socket(AF_INET6, SOCK_RAW, 7);

	setsockopt(fd, SOL_IPV6, IPV6_CHECKSUM, &zero, 4);
	setsockopt(fd, SOL_IPV6, IPV6_DSTOPTS, &buf, LEN);

	sendto(fd, buf, 1, 0, (struct sockaddr *) buf, 110);
}

Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv6/raw.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index 054a1d8..869ffc7 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -589,7 +589,11 @@ static int rawv6_push_pending_frames(struct sock *sk, struct flowi6 *fl6,
 	}
 
 	offset += skb_transport_offset(skb);
-	BUG_ON(skb_copy_bits(skb, offset, &csum, 2));
+	err = skb_copy_bits(skb, offset, &csum, 2);
+	if (err < 0) {
+		ip6_flush_pending_frames(sk);
+		goto out;
+	}
 
 	/* in case cksum was not initialized */
 	if (unlikely(csum))
-- 
2.7.4


>From e55e6ccbfa137bcdb750561ba6c281752a24fc1b Mon Sep 17 00:00:00 2001
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Wed, 21 Dec 2016 18:04:11 +0100
Subject: [PATCH 06/37] net, sched: fix soft lockup in tc_classify

[ Upstream commit 628185cfddf1dfb701c4efe2cfd72cf5b09f5702 ]

Shahar reported a soft lockup in tc_classify(), where we run into an
endless loop when walking the classifier chain due to tp->next == tp
which is a state we should never run into. The issue only seems to
trigger under load in the tc control path.

What happens is that in tc_ctl_tfilter(), thread A allocates a new
tp, initializes it, sets tp_created to 1, and calls into tp->ops->change()
with it. In that classifier callback we had to unlock/lock the rtnl
mutex and returned with -EAGAIN. One reason why we need to drop there
is, for example, that we need to request an action module to be loaded.

This happens via tcf_exts_validate() -> tcf_action_init/_1() meaning
after we loaded and found the requested action, we need to redo the
whole request so we don't race against others. While we had to unlock
rtnl in that time, thread B's request was processed next on that CPU.
Thread B added a new tp instance successfully to the classifier chain.
When thread A returned grabbing the rtnl mutex again, propagating -EAGAIN
and destroying its tp instance which never got linked, we goto replay
and redo A's request.

This time when walking the classifier chain in tc_ctl_tfilter() for
checking for existing tp instances we had a priority match and found
the tp instance that was created and linked by thread B. Now calling
again into tp->ops->change() with that tp was successful and returned
without error.

tp_created was never cleared in the second round, thus kernel thinks
that we need to link it into the classifier chain (once again). tp and
*back point to the same object due to the match we had earlier on. Thus
for thread B's already public tp, we reset tp->next to tp itself and
link it into the chain, which eventually causes the mentioned endless
loop in tc_classify() once a packet hits the data path.

Fix is to clear tp_created at the beginning of each request, also when
we replay it. On the paths that can cause -EAGAIN we already destroy
the original tp instance we had and on replay we really need to start
from scratch. It seems that this issue was first introduced in commit
12186be7d2e1 ("net_cls: fix unconfigured struct tcf_proto keeps chaining
and avoid kernel panic when we use cls_cgroup").

Fixes: 12186be7d2e1 ("net_cls: fix unconfigured struct tcf_proto keeps chaining and avoid kernel panic when we use cls_cgroup")
Reported-by: Shahar Klein <shahark@mellanox.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Tested-by: Shahar Klein <shahark@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/sched/cls_api.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index b05d4a2..c1a4b5d 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -148,13 +148,15 @@ static int tc_ctl_tfilter(struct sk_buff *skb, struct nlmsghdr *n)
 	unsigned long cl;
 	unsigned long fh;
 	int err;
-	int tp_created = 0;
+	int tp_created;
 
 	if ((n->nlmsg_type != RTM_GETTFILTER) &&
 	    !netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN))
 		return -EPERM;
 
 replay:
+	tp_created = 0;
+
 	err = nlmsg_parse(n, sizeof(*t), tca, TCA_MAX, NULL);
 	if (err < 0)
 		return err;
-- 
2.7.4


>From 46e7b8c9f109e91e6a0447e0ab6ad7937ae9a6e9 Mon Sep 17 00:00:00 2001
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 27 Dec 2016 18:23:06 -0800
Subject: [PATCH 07/37] net: stmmac: Fix race between stmmac_drv_probe and
 stmmac_open

[ Upstream commit 5701659004d68085182d2fd4199c79172165fa65 ]

There is currently a small window during which the network device registered by
stmmac can be made visible, yet all resources, including and clock and MDIO bus
have not had a chance to be set up, this can lead to the following error to
occur:

[  473.919358] stmmaceth 0000:01:00.0 (unnamed net_device) (uninitialized):
                stmmac_dvr_probe: warning: cannot get CSR clock
[  473.919382] stmmaceth 0000:01:00.0: no reset control found
[  473.919412] stmmac - user ID: 0x10, Synopsys ID: 0x42
[  473.919429] stmmaceth 0000:01:00.0: DMA HW capability register supported
[  473.919436] stmmaceth 0000:01:00.0: RX Checksum Offload Engine supported
[  473.919443] stmmaceth 0000:01:00.0: TX Checksum insertion supported
[  473.919451] stmmaceth 0000:01:00.0 (unnamed net_device) (uninitialized):
                Enable RX Mitigation via HW Watchdog Timer
[  473.921395] libphy: PHY stmmac-1:00 not found
[  473.921417] stmmaceth 0000:01:00.0 eth0: Could not attach to PHY
[  473.921427] stmmaceth 0000:01:00.0 eth0: stmmac_open: Cannot attach to
                PHY (error: -19)
[  473.959710] libphy: stmmac: probed
[  473.959724] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 0 IRQ POLL
                (stmmac-1:00) active
[  473.959728] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 1 IRQ POLL
                (stmmac-1:01)
[  473.959731] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 2 IRQ POLL
                (stmmac-1:02)
[  473.959734] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 3 IRQ POLL
                (stmmac-1:03)

Fix this by making sure that register_netdev() is the last thing being done,
which guarantees that the clock and the MDIO bus are available.

Fixes: 4bfcbd7abce2 ("stmmac: Move the mdio_register/_unregister in probe/remove")
Reported-by: Kweh, Hock Leong <hock.leong.kweh@intel.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 23 +++++++++++++----------
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index caf069a..b2893fb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3349,12 +3349,6 @@ int stmmac_dvr_probe(struct device *device,
 	spin_lock_init(&priv->lock);
 	spin_lock_init(&priv->tx_lock);
 
-	ret = register_netdev(ndev);
-	if (ret) {
-		pr_err("%s: ERROR %i registering the device\n", __func__, ret);
-		goto error_netdev_register;
-	}
-
 	/* If a specific clk_csr value is passed from the platform
 	 * this means that the CSR Clock Range selection cannot be
 	 * changed at run-time and it is fixed. Viceversa the driver'll try to
@@ -3376,15 +3370,24 @@ int stmmac_dvr_probe(struct device *device,
 		if (ret < 0) {
 			pr_debug("%s: MDIO bus (id: %d) registration failed",
 				 __func__, priv->plat->bus_id);
-			goto error_mdio_register;
+			goto error_napi_register;
 		}
 	}
 
-	return 0;
+	ret = register_netdev(ndev);
+	if (ret) {
+		pr_err("%s: ERROR %i registering the device\n", __func__, ret);
+		goto error_netdev_register;
+	}
+
+	return ret;
 
-error_mdio_register:
-	unregister_netdev(ndev);
 error_netdev_register:
+	if (priv->hw->pcs != STMMAC_PCS_RGMII &&
+	    priv->hw->pcs != STMMAC_PCS_TBI &&
+	    priv->hw->pcs != STMMAC_PCS_RTBI)
+		stmmac_mdio_unregister(ndev);
+error_napi_register:
 	netif_napi_del(&priv->napi);
 error_hw_init:
 	clk_disable_unprepare(priv->pclk);
-- 
2.7.4


>From 8941acf18f6391e66edfd0fbb349545d593b70da Mon Sep 17 00:00:00 2001
From: Paul Blakey <paulb@mellanox.com>
Date: Wed, 28 Dec 2016 14:54:47 +0200
Subject: [PATCH 08/37] net/sched: cls_flower: Fix missing addr_type in
 classify

[ Upstream commit 0df0f207aab4f42e5c96a807adf9a6845b69e984 ]

Since we now use a non zero mask on addr_type, we are matching on its
value (IPV4/IPV6). So before this fix, matching on enc_src_ip/enc_dst_ip
failed in SW/classify path since its value was zero.
This patch sets the proper value of addr_type for encapsulated packets.

Fixes: 970bfcd09791 ('net/sched: cls_flower: Use mask for addr_type')
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Reviewed-by: Hadar Hen Zion <hadarh@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/sched/cls_flower.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index 9044424..eee299b 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -149,10 +149,14 @@ static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,
 
 		switch (ip_tunnel_info_af(info)) {
 		case AF_INET:
+			skb_key.enc_control.addr_type =
+				FLOW_DISSECTOR_KEY_IPV4_ADDRS;
 			skb_key.enc_ipv4.src = key->u.ipv4.src;
 			skb_key.enc_ipv4.dst = key->u.ipv4.dst;
 			break;
 		case AF_INET6:
+			skb_key.enc_control.addr_type =
+				FLOW_DISSECTOR_KEY_IPV6_ADDRS;
 			skb_key.enc_ipv6.src = key->u.ipv6.src;
 			skb_key.enc_ipv6.dst = key->u.ipv6.dst;
 			break;
-- 
2.7.4


>From 0e3eacd0148368b59477d83881e9165ff7ec594f Mon Sep 17 00:00:00 2001
From: Noa Osherovich <noaos@mellanox.com>
Date: Wed, 28 Dec 2016 14:58:32 +0200
Subject: [PATCH 09/37] net/mlx5: Check FW limitations on log_max_qp before
 setting it

[ Upstream commit 883371c453b937f9eb581fb4915210865982736f ]

When setting HCA capabilities, set log_max_qp to be the minimum
between the selected profile's value and the HCA limitation.

Fixes: 938fe83c8dcb ('net/mlx5_core: New device capabilities...')
Signed-off-by: Noa Osherovich <noaos@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/mellanox/mlx5/core/main.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index ada24e1..332769c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -468,6 +468,13 @@ static int handle_hca_cap(struct mlx5_core_dev *dev)
 	MLX5_SET(cmd_hca_cap, set_hca_cap, pkey_table_size,
 		 to_fw_pkey_sz(dev, 128));
 
+	/* Check log_max_qp from HCA caps to set in current profile */
+	if (MLX5_CAP_GEN_MAX(dev, log_max_qp) < profile[prof_sel].log_max_qp) {
+		mlx5_core_warn(dev, "log_max_qp value in current profile is %d, changing it to HCA capability limit (%d)\n",
+			       profile[prof_sel].log_max_qp,
+			       MLX5_CAP_GEN_MAX(dev, log_max_qp));
+		profile[prof_sel].log_max_qp = MLX5_CAP_GEN_MAX(dev, log_max_qp);
+	}
 	if (prof->mask & MLX5_PROF_MASK_QP_SIZE)
 		MLX5_SET(cmd_hca_cap, set_hca_cap, log_max_qp,
 			 prof->log_max_qp);
-- 
2.7.4


>From efeec3a3f5504fc1947488337a62c7c0d16dd1a7 Mon Sep 17 00:00:00 2001
From: Daniel Jurgens <danielj@mellanox.com>
Date: Wed, 28 Dec 2016 14:58:33 +0200
Subject: [PATCH 10/37] net/mlx5: Cancel recovery work in remove flow

[ Upstream commit 689a248df83b6032edc57e86267b4e5cc8d7174e ]

If there is pending delayed work for health recovery it must be canceled
if the device is being unloaded.

Fixes: 05ac2c0b7438 ("net/mlx5: Fix race between PCI error handlers and health work")
Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/mellanox/mlx5/core/main.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 332769c..15b7e60 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -1159,6 +1159,8 @@ static int mlx5_unload_one(struct mlx5_core_dev *dev, struct mlx5_priv *priv,
 {
 	int err = 0;
 
+	mlx5_drain_health_wq(dev);
+
 	mutex_lock(&dev->intf_state_mutex);
 	if (test_bit(MLX5_INTERFACE_STATE_DOWN, &dev->intf_state)) {
 		dev_warn(&dev->pdev->dev, "%s: interface is down, NOP\n",
@@ -1319,10 +1321,9 @@ static pci_ers_result_t mlx5_pci_err_detected(struct pci_dev *pdev,
 
 	mlx5_enter_error_state(dev);
 	mlx5_unload_one(dev, priv, false);
-	/* In case of kernel call save the pci state and drain health wq */
+	/* In case of kernel call save the pci state */
 	if (state) {
 		pci_save_state(pdev);
-		mlx5_drain_health_wq(dev);
 		mlx5_pci_disable_device(dev);
 	}
 
-- 
2.7.4


>From dda931a2cffceb97eae26545c2f8b72d75c724a0 Mon Sep 17 00:00:00 2001
From: Eli Cohen <eli@mellanox.com>
Date: Wed, 28 Dec 2016 14:58:34 +0200
Subject: [PATCH 11/37] net/mlx5: Avoid shadowing numa_node

[ Upstream commit d151d73dcc99de87c63bdefebcc4cb69de1cdc40 ]

Avoid using a local variable named numa_node to avoid shadowing a public
one.

Fixes: db058a186f98 ('net/mlx5_core: Set irq affinity hints')
Signed-off-by: Eli Cohen <eli@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/mellanox/mlx5/core/main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 15b7e60..92bd13d 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -547,7 +547,6 @@ static int mlx5_irq_set_affinity_hint(struct mlx5_core_dev *mdev, int i)
 	struct mlx5_priv *priv  = &mdev->priv;
 	struct msix_entry *msix = priv->msix_arr;
 	int irq                 = msix[i + MLX5_EQ_VEC_COMP_BASE].vector;
-	int numa_node           = priv->numa_node;
 	int err;
 
 	if (!zalloc_cpumask_var(&priv->irq_info[i].mask, GFP_KERNEL)) {
@@ -555,7 +554,7 @@ static int mlx5_irq_set_affinity_hint(struct mlx5_core_dev *mdev, int i)
 		return -ENOMEM;
 	}
 
-	cpumask_set_cpu(cpumask_local_spread(i, numa_node),
+	cpumask_set_cpu(cpumask_local_spread(i, priv->numa_node),
 			priv->irq_info[i].mask);
 
 	err = irq_set_affinity_hint(irq, priv->irq_info[i].mask);
-- 
2.7.4


>From 6bd939c40912e6eec51d52ef251b785333df6b18 Mon Sep 17 00:00:00 2001
From: Maor Gottlieb <maorg@mellanox.com>
Date: Wed, 28 Dec 2016 14:58:35 +0200
Subject: [PATCH 12/37] net/mlx5: Mask destination mac value in ethtool
 steering rules

[ Upstream commit 077b1e8069b9b74477b01d28f6b83774dc19a142 ]

We need to mask the destination mac value with the destination mac
mask when adding steering rule via ethtool.

Fixes: 1174fce8d1410 ('net/mlx5e: Support l3/l4 flow type specs in ethtool flow steering')
Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/mellanox/mlx5/core/en_fs_ethtool.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_fs_ethtool.c b/drivers/net/ethernet/mellanox/mlx5/core/en_fs_ethtool.c
index d17c242..90e81ae 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_fs_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_fs_ethtool.c
@@ -247,6 +247,7 @@ static int set_flow_attrs(u32 *match_c, u32 *match_v,
 	}
 	if (fs->flow_type & FLOW_MAC_EXT &&
 	    !is_zero_ether_addr(fs->m_ext.h_dest)) {
+		mask_spec(fs->m_ext.h_dest, fs->h_ext.h_dest, ETH_ALEN);
 		ether_addr_copy(MLX5_ADDR_OF(fte_match_set_lyr_2_4,
 					     outer_headers_c, dmac_47_16),
 				fs->m_ext.h_dest);
-- 
2.7.4


>From c83b1b583a985fe44ece2ca24abea71611393114 Mon Sep 17 00:00:00 2001
From: Mohamad Haj Yahia <mohamad@mellanox.com>
Date: Wed, 28 Dec 2016 14:58:37 +0200
Subject: [PATCH 13/37] net/mlx5: Prevent setting multicast macs for VFs

[ Upstream commit ccce1700263d8b5b219359d04180492a726cea16 ]

Need to check that VF mac address entered by the admin user is either
zero or unicast mac.
Multicast mac addresses are prohibited.

Fixes: 77256579c6b4 ('net/mlx5: E-Switch, Introduce Vport administration functions')
Signed-off-by: Mohamad Haj Yahia <mohamad@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index be1f733..c7011ef 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -1703,7 +1703,7 @@ int mlx5_eswitch_set_vport_mac(struct mlx5_eswitch *esw,
 
 	if (!ESW_ALLOWED(esw))
 		return -EPERM;
-	if (!LEGAL_VPORT(esw, vport))
+	if (!LEGAL_VPORT(esw, vport) || is_multicast_ether_addr(mac))
 		return -EINVAL;
 
 	mutex_lock(&esw->state_lock);
-- 
2.7.4


>From 4ea5db6017b45457d2c50a42e067b20968a6720c Mon Sep 17 00:00:00 2001
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Wed, 28 Dec 2016 14:58:41 +0200
Subject: [PATCH 14/37] net/mlx5e: Don't sync netdev state when not registered

[ Upstream commit 610e89e05c3f28a7394935aa6b91f99548c4fd3c ]

Skip setting netdev vxlan ports and netdev rx_mode on driver load
when netdev is not yet registered.

Synchronizing with netdev state is needed only on reset flow where the
netdev remains registered for the whole reset period.

This also fixes an access before initialization of net_device.addr_list_lock
- which for some reason initialized on register_netdev - where we queued
set_rx_mode work on driver load before netdev registration.

Fixes: 26e59d8077a3 ("net/mlx5e: Implement mlx5e interface attach/detach callbacks")
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Reported-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Reviewed-by: Mohamad Haj Yahia <mohamad@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 246d98e..307b270 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -3773,14 +3773,7 @@ static void mlx5e_nic_enable(struct mlx5e_priv *priv)
 
 	mlx5_lag_add(mdev, netdev);
 
-	if (mlx5e_vxlan_allowed(mdev)) {
-		rtnl_lock();
-		udp_tunnel_get_rx_info(netdev);
-		rtnl_unlock();
-	}
-
 	mlx5e_enable_async_events(priv);
-	queue_work(priv->wq, &priv->set_rx_mode_work);
 
 	if (MLX5_CAP_GEN(mdev, vport_group_manager)) {
 		mlx5_query_nic_vport_mac_address(mdev, 0, rep.hw_id);
@@ -3790,6 +3783,18 @@ static void mlx5e_nic_enable(struct mlx5e_priv *priv)
 		rep.priv_data = priv;
 		mlx5_eswitch_register_vport_rep(esw, 0, &rep);
 	}
+
+	if (netdev->reg_state != NETREG_REGISTERED)
+		return;
+
+	/* Device already registered: sync netdev system state */
+	if (mlx5e_vxlan_allowed(mdev)) {
+		rtnl_lock();
+		udp_tunnel_get_rx_info(netdev);
+		rtnl_unlock();
+	}
+
+	queue_work(priv->wq, &priv->set_rx_mode_work);
 }
 
 static void mlx5e_nic_disable(struct mlx5e_priv *priv)
-- 
2.7.4


>From c078e5909b40fdf6ac4294ce493600498825f709 Mon Sep 17 00:00:00 2001
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Wed, 28 Dec 2016 14:58:42 +0200
Subject: [PATCH 15/37] net/mlx5e: Disable netdev after close

[ Upstream commit 37f304d10030bb425c19099e7b955d9c3ec4cba3 ]

Disable netdev should come after it was closed, although no harm of doing it
before -hence the MLX5E_STATE_DESTROYING bit- but it is more natural this way.

Fixes: 26e59d8077a3 ("net/mlx5e: Implement mlx5e interface attach/detach callbacks")
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Reviewed-by: Mohamad Haj Yahia <mohamad@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 307b270..5dc3e24 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -3942,10 +3942,6 @@ void mlx5e_detach_netdev(struct mlx5_core_dev *mdev, struct net_device *netdev)
 	const struct mlx5e_profile *profile = priv->profile;
 
 	set_bit(MLX5E_STATE_DESTROYING, &priv->state);
-	if (profile->disable)
-		profile->disable(priv);
-
-	flush_workqueue(priv->wq);
 
 	rtnl_lock();
 	if (netif_running(netdev))
@@ -3953,6 +3949,10 @@ void mlx5e_detach_netdev(struct mlx5_core_dev *mdev, struct net_device *netdev)
 	netif_device_detach(netdev);
 	rtnl_unlock();
 
+	if (profile->disable)
+		profile->disable(priv);
+	flush_workqueue(priv->wq);
+
 	mlx5e_destroy_q_counter(priv);
 	profile->cleanup_rx(priv);
 	mlx5e_close_drop_rq(priv);
-- 
2.7.4


>From b6484b1c5e7ad5191307b45f41a3bba917123ada Mon Sep 17 00:00:00 2001
From: Mathias Krause <minipli@googlemail.com>
Date: Wed, 28 Dec 2016 17:52:15 +0100
Subject: [PATCH 16/37] rtnl: stats - add missing netlink message size checks

[ Upstream commit 4775cc1f2d5abca894ac32774eefc22c45347d1c ]

We miss to check if the netlink message is actually big enough to contain
a struct if_stats_msg.

Add a check to prevent userland from sending us short messages that would
make us access memory beyond the end of the message.

Fixes: 10c9ead9f3c6 ("rtnetlink: add new RTM_GETSTATS message to dump...")
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/core/rtnetlink.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index a6196cf..b7f9ae7 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -3886,6 +3886,9 @@ static int rtnl_stats_get(struct sk_buff *skb, struct nlmsghdr *nlh)
 	u32 filter_mask;
 	int err;
 
+	if (nlmsg_len(nlh) < sizeof(*ifsm))
+		return -EINVAL;
+
 	ifsm = nlmsg_data(nlh);
 	if (ifsm->ifindex > 0)
 		dev = __dev_get_by_index(net, ifsm->ifindex);
@@ -3935,6 +3938,9 @@ static int rtnl_stats_dump(struct sk_buff *skb, struct netlink_callback *cb)
 
 	cb->seq = net->dev_base_seq;
 
+	if (nlmsg_len(cb->nlh) < sizeof(*ifsm))
+		return -EINVAL;
+
 	ifsm = nlmsg_data(cb->nlh);
 	filter_mask = ifsm->filter_mask;
 	if (!filter_mask)
-- 
2.7.4


>From 1c0bd98c345cb615972a9f8ce5bbad53ea880132 Mon Sep 17 00:00:00 2001
From: Wei Zhang <asuka.com@163.com>
Date: Thu, 29 Dec 2016 16:45:04 +0800
Subject: [PATCH 17/37] net: fix incorrect original ingress device index in
 PKTINFO

[ Upstream commit f0c16ba8933ed217c2688b277410b2a37ba81591 ]

When we send a packet for our own local address on a non-loopback
interface (e.g. eth0), due to the change had been introduced from
commit 0b922b7a829c ("net: original ingress device index in PKTINFO"), the
original ingress device index would be set as the loopback interface.
However, the packet should be considered as if it is being arrived via the
sending interface (eth0), otherwise it would break the expectation of the
userspace application (e.g. the DHCPRELEASE message from dhcp_release
binary would be ignored by the dnsmasq daemon, since it come from lo which
is not the interface dnsmasq bind to)

Fixes: 0b922b7a829c ("net: original ingress device index in PKTINFO")
Acked-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: Wei Zhang <asuka.com@163.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/ip_sockglue.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index e869773..f226f408 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1202,8 +1202,14 @@ void ipv4_pktinfo_prepare(const struct sock *sk, struct sk_buff *skb)
 		 * which has interface index (iif) as the first member of the
 		 * underlying inet{6}_skb_parm struct. This code then overlays
 		 * PKTINFO_SKB_CB and in_pktinfo also has iif as the first
-		 * element so the iif is picked up from the prior IPCB
+		 * element so the iif is picked up from the prior IPCB. If iif
+		 * is the loopback interface, then return the sending interface
+		 * (e.g., process binds socket to eth0 for Tx which is
+		 * redirected to loopback in the rtable/dst).
 		 */
+		if (pktinfo->ipi_ifindex == LOOPBACK_IFINDEX)
+			pktinfo->ipi_ifindex = inet_iif(skb);
+
 		pktinfo->ipi_spec_dst.s_addr = fib_compute_spec_dst(skb);
 	} else {
 		pktinfo->ipi_ifindex = 0;
-- 
2.7.4


>From c2736efebfed992e05763f1ec50ecd9cd4b804ac Mon Sep 17 00:00:00 2001
From: David Ahern <dsa@cumulusnetworks.com>
Date: Thu, 29 Dec 2016 15:29:03 -0800
Subject: [PATCH 18/37] net: ipv4: dst for local input routes should use l3mdev
 if relevant

[ Upstream commit f5a0aab84b74de68523599817569c057c7ac1622 ]

IPv4 output routes already use l3mdev device instead of loopback for dst's
if it is applicable. Change local input routes to do the same.

This fixes icmp responses for unreachable UDP ports which are directed
to the wrong table after commit 9d1a6c4ea43e4 because local_input
routes use the loopback device. Moving from ingress device to loopback
loses the L3 domain causing responses based on the dst to get to lost.

Fixes: 9d1a6c4ea43e4 ("net: icmp_route_lookup should use rt dev to
		       determine L3 domain")
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/route.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 2a57566..8197b06 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1902,7 +1902,8 @@ out:	return err;
 		}
 	}
 
-	rth = rt_dst_alloc(net->loopback_dev, flags | RTCF_LOCAL, res.type,
+	rth = rt_dst_alloc(l3mdev_master_dev_rcu(dev) ? : net->loopback_dev,
+			   flags | RTCF_LOCAL, res.type,
 			   IN_DEV_CONF_GET(in_dev, NOPOLICY), false, do_cache);
 	if (!rth)
 		goto e_nobufs;
-- 
2.7.4


>From 5a132f59f6fe185a85b168ee11136f7862111eeb Mon Sep 17 00:00:00 2001
From: Reiter Wolfgang <wr0112358@gmail.com>
Date: Sat, 31 Dec 2016 21:11:57 +0100
Subject: [PATCH 19/37] drop_monitor: add missing call to genlmsg_end

[ Upstream commit 4200462d88f47f3759bdf4705f87e207b0f5b2e4 ]

Update nlmsg_len field with genlmsg_end to enable userspace processing
using nlmsg_next helper. Also adds error handling.

Signed-off-by: Reiter Wolfgang <wr0112358@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/core/drop_monitor.c | 33 ++++++++++++++++++++++++---------
 1 file changed, 24 insertions(+), 9 deletions(-)

diff --git a/net/core/drop_monitor.c b/net/core/drop_monitor.c
index 72cfb0c..5de61aa 100644
--- a/net/core/drop_monitor.c
+++ b/net/core/drop_monitor.c
@@ -80,6 +80,7 @@ static struct sk_buff *reset_per_cpu_data(struct per_cpu_dm_data *data)
 	struct nlattr *nla;
 	struct sk_buff *skb;
 	unsigned long flags;
+	void *msg_header;
 
 	al = sizeof(struct net_dm_alert_msg);
 	al += dm_hit_limit * sizeof(struct net_dm_drop_point);
@@ -87,17 +88,31 @@ static struct sk_buff *reset_per_cpu_data(struct per_cpu_dm_data *data)
 
 	skb = genlmsg_new(al, GFP_KERNEL);
 
-	if (skb) {
-		genlmsg_put(skb, 0, 0, &net_drop_monitor_family,
-				0, NET_DM_CMD_ALERT);
-		nla = nla_reserve(skb, NLA_UNSPEC,
-				  sizeof(struct net_dm_alert_msg));
-		msg = nla_data(nla);
-		memset(msg, 0, al);
-	} else {
-		mod_timer(&data->send_timer, jiffies + HZ / 10);
+	if (!skb)
+		goto err;
+
+	msg_header = genlmsg_put(skb, 0, 0, &net_drop_monitor_family,
+				 0, NET_DM_CMD_ALERT);
+	if (!msg_header) {
+		nlmsg_free(skb);
+		skb = NULL;
+		goto err;
+	}
+	nla = nla_reserve(skb, NLA_UNSPEC,
+			  sizeof(struct net_dm_alert_msg));
+	if (!nla) {
+		nlmsg_free(skb);
+		skb = NULL;
+		goto err;
 	}
+	msg = nla_data(nla);
+	memset(msg, 0, al);
+	genlmsg_end(skb, msg_header);
+	goto out;
 
+err:
+	mod_timer(&data->send_timer, jiffies + HZ / 10);
+out:
 	spin_lock_irqsave(&data->lock, flags);
 	swap(data->skb, skb);
 	spin_unlock_irqrestore(&data->lock, flags);
-- 
2.7.4


>From e606a46798f5b6829d535877671e988e9e0e02c8 Mon Sep 17 00:00:00 2001
From: Reiter Wolfgang <wr0112358@gmail.com>
Date: Tue, 3 Jan 2017 01:39:10 +0100
Subject: [PATCH 20/37] drop_monitor: consider inserted data in genlmsg_end

[ Upstream commit 3b48ab2248e61408910e792fe84d6ec466084c1a ]

Final nlmsg_len field update must reflect inserted net_dm_drop_point
data.

This patch depends on previous patch:
"drop_monitor: add missing call to genlmsg_end"

Signed-off-by: Reiter Wolfgang <wr0112358@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/core/drop_monitor.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/net/core/drop_monitor.c b/net/core/drop_monitor.c
index 5de61aa..ca2c9c8 100644
--- a/net/core/drop_monitor.c
+++ b/net/core/drop_monitor.c
@@ -107,7 +107,6 @@ static struct sk_buff *reset_per_cpu_data(struct per_cpu_dm_data *data)
 	}
 	msg = nla_data(nla);
 	memset(msg, 0, al);
-	genlmsg_end(skb, msg_header);
 	goto out;
 
 err:
@@ -117,6 +116,13 @@ static struct sk_buff *reset_per_cpu_data(struct per_cpu_dm_data *data)
 	swap(data->skb, skb);
 	spin_unlock_irqrestore(&data->lock, flags);
 
+	if (skb) {
+		struct nlmsghdr *nlh = (struct nlmsghdr *)skb->data;
+		struct genlmsghdr *gnlh = (struct genlmsghdr *)nlmsg_data(nlh);
+
+		genlmsg_end(skb, genlmsg_data(gnlh));
+	}
+
 	return skb;
 }
 
-- 
2.7.4


>From 64e0f8601bf0e45f088f8879df8f79944451394f Mon Sep 17 00:00:00 2001
From: Ian Kumlien <ian.kumlien@gmail.com>
Date: Mon, 2 Jan 2017 09:18:35 +0100
Subject: [PATCH 21/37] flow_dissector: Update pptp handling to avoid null
 pointer deref.

[ Upstream commit d0af683407a26a4437d8fa6e283ea201f2ae8146 ]

__skb_flow_dissect can be called with a skb or a data packet, either
can be NULL. All calls seems to have been moved to __skb_header_pointer
except the pptp handling which is still calling skb_header_pointer.

skb_header_pointer will use skb->data and thus:
[  109.556866] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
[  109.557102] IP: [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0
[  109.557263] PGD 0
[  109.557338]
[  109.557484] Oops: 0000 [#1] SMP
[  109.557562] Modules linked in: chaoskey
[  109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 #79
[  109.557867] Hardware name: Supermicro A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 1.0c 11/04/2015
[  109.557957] task: ffff94085c27bc00 task.stack: ffffb745c0068000
[  109.558041] RIP: 0010:[<ffffffff88dc02f8>]  [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0
[  109.558203] RSP: 0018:ffff94087fc83d40  EFLAGS: 00010206
[  109.558286] RAX: 0000000000000130 RBX: ffffffff8975bf80 RCX: ffff94084fab6800
[  109.558373] RDX: 0000000000000010 RSI: 000000000000000c RDI: 0000000000000000
[  109.558460] RBP: 0000000000000b88 R08: 0000000000000000 R09: 0000000000000022
[  109.558547] R10: 0000000000000008 R11: ffff94087fc83e04 R12: 0000000000000000
[  109.558763] R13: ffff94084fab6800 R14: ffff94087fc83e04 R15: 000000000000002f
[  109.558979] FS:  0000000000000000(0000) GS:ffff94087fc80000(0000) knlGS:0000000000000000
[  109.559326] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  109.559539] CR2: 0000000000000080 CR3: 0000000281809000 CR4: 00000000001026e0
[  109.559753] Stack:
[  109.559957]  000000000000000c ffff94084fab6822 0000000000000001 ffff94085c2b5fc0
[  109.560578]  0000000000000001 0000000000002000 0000000000000000 0000000000000000
[  109.561200]  0000000000000000 0000000000000000 0000000000000000 0000000000000000
[  109.561820] Call Trace:
[  109.562027]  <IRQ>
[  109.562108]  [<ffffffff88dfb4fa>] ? eth_get_headlen+0x7a/0xf0
[  109.562522]  [<ffffffff88c5a35a>] ? igb_poll+0x96a/0xe80
[  109.562737]  [<ffffffff88dc912b>] ? net_rx_action+0x20b/0x350
[  109.562953]  [<ffffffff88546d68>] ? __do_softirq+0xe8/0x280
[  109.563169]  [<ffffffff8854704a>] ? irq_exit+0xaa/0xb0
[  109.563382]  [<ffffffff8847229b>] ? do_IRQ+0x4b/0xc0
[  109.563597]  [<ffffffff8902d4ff>] ? common_interrupt+0x7f/0x7f
[  109.563810]  <EOI>
[  109.563890]  [<ffffffff88d57530>] ? cpuidle_enter_state+0x130/0x2c0
[  109.564304]  [<ffffffff88d57520>] ? cpuidle_enter_state+0x120/0x2c0
[  109.564520]  [<ffffffff8857eacf>] ? cpu_startup_entry+0x19f/0x1f0
[  109.564737]  [<ffffffff8848d55a>] ? start_secondary+0x12a/0x140
[  109.564950] Code: 83 e2 20 a8 80 0f 84 60 01 00 00 c7 04 24 08 00
00 00 66 85 d2 0f 84 be fe ff ff e9 69 fe ff ff 8b 34 24 89 f2 83 c2
04 66 85 c0 <41> 8b 84 24 80 00 00 00 0f 49 d6 41 8d 31 01 d6 41 2b 84
24 84
[  109.569959] RIP  [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0
[  109.570245]  RSP <ffff94087fc83d40>
[  109.570453] CR2: 0000000000000080

Fixes: ab10dccb1160 ("rps: Inspect PPTP encapsulated by GRE to get flow hash")
Signed-off-by: Ian Kumlien <ian.kumlien@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/core/flow_dissector.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index c6d8207..32e4e01 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -445,8 +445,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
 			if (hdr->flags & GRE_ACK)
 				offset += sizeof(((struct pptp_gre_header *)0)->ack);
 
-			ppp_hdr = skb_header_pointer(skb, nhoff + offset,
-						     sizeof(_ppp_hdr), _ppp_hdr);
+			ppp_hdr = __skb_header_pointer(skb, nhoff + offset,
+						     sizeof(_ppp_hdr),
+						     data, hlen, _ppp_hdr);
 			if (!ppp_hdr)
 				goto out_bad;
 
-- 
2.7.4


>From 0d094f9e59706a3046b2eaf551732038866dd928 Mon Sep 17 00:00:00 2001
From: Michal Tesar <mtesar@redhat.com>
Date: Mon, 2 Jan 2017 14:38:36 +0100
Subject: [PATCH 22/37] igmp: Make igmp group member RFC 3376 compliant

[ Upstream commit 7ababb782690e03b78657e27bd051e20163af2d6 ]

5.2. Action on Reception of a Query

 When a system receives a Query, it does not respond immediately.
 Instead, it delays its response by a random amount of time, bounded
 by the Max Resp Time value derived from the Max Resp Code in the
 received Query message.  A system may receive a variety of Queries on
 different interfaces and of different kinds (e.g., General Queries,
 Group-Specific Queries, and Group-and-Source-Specific Queries), each
 of which may require its own delayed response.

 Before scheduling a response to a Query, the system must first
 consider previously scheduled pending responses and in many cases
 schedule a combined response.  Therefore, the system must be able to
 maintain the following state:

 o A timer per interface for scheduling responses to General Queries.

 o A per-group and interface timer for scheduling responses to Group-
   Specific and Group-and-Source-Specific Queries.

 o A per-group and interface list of sources to be reported in the
   response to a Group-and-Source-Specific Query.

 When a new Query with the Router-Alert option arrives on an
 interface, provided the system has state to report, a delay for a
 response is randomly selected in the range (0, [Max Resp Time]) where
 Max Resp Time is derived from Max Resp Code in the received Query
 message.  The following rules are then used to determine if a Report
 needs to be scheduled and the type of Report to schedule.  The rules
 are considered in order and only the first matching rule is applied.

 1. If there is a pending response to a previous General Query
    scheduled sooner than the selected delay, no additional response
    needs to be scheduled.

 2. If the received Query is a General Query, the interface timer is
    used to schedule a response to the General Query after the
    selected delay.  Any previously pending response to a General
    Query is canceled.
--8<--

Currently the timer is rearmed with new random expiration time for
every incoming query regardless of possibly already pending report.
Which is not aligned with the above RFE.
It also might happen that higher rate of incoming queries can
postpone the report after the expiration time of the first query
causing group membership loss.

Now the per interface general query timer is rearmed only
when there is no pending report already scheduled on that interface or
the newly selected expiration time is before the already pending
scheduled report.

Signed-off-by: Michal Tesar <mtesar@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/igmp.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 15db786..32a08bc 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -219,9 +219,14 @@ static void igmp_start_timer(struct ip_mc_list *im, int max_delay)
 static void igmp_gq_start_timer(struct in_device *in_dev)
 {
 	int tv = prandom_u32() % in_dev->mr_maxdelay;
+	unsigned long exp = jiffies + tv + 2;
+
+	if (in_dev->mr_gq_running &&
+	    time_after_eq(exp, (in_dev->mr_gq_timer).expires))
+		return;
 
 	in_dev->mr_gq_running = 1;
-	if (!mod_timer(&in_dev->mr_gq_timer, jiffies+tv+2))
+	if (!mod_timer(&in_dev->mr_gq_timer, exp))
 		in_dev_hold(in_dev);
 }
 
-- 
2.7.4


>From 936a42dd615006e49e9f0b6014330b86f692ae6c Mon Sep 17 00:00:00 2001
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Mon, 2 Jan 2017 13:32:54 -0800
Subject: [PATCH 23/37] ipv4: Do not allow MAIN to be alias for new LOCAL w/
 custom rules

[ Upstream commit 5350d54f6cd12eaff623e890744c79b700bd3f17 ]

In the case of custom rules being present we need to handle the case of the
LOCAL table being intialized after the new rule has been added.  To address
that I am adding a new check so that we can make certain we don't use an
alias of MAIN for LOCAL when allocating a new table.

Fixes: 0ddcf43d5d4a ("ipv4: FIB Local/MAIN table collapse")
Reported-by: Oliver Brunel <jjk@jjacky.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/fib_frontend.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 161fc0f..3e4f183 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -85,7 +85,7 @@ struct fib_table *fib_new_table(struct net *net, u32 id)
 	if (tb)
 		return tb;
 
-	if (id == RT_TABLE_LOCAL)
+	if (id == RT_TABLE_LOCAL && !net->ipv4.fib_has_custom_rules)
 		alias = fib_new_table(net, RT_TABLE_MAIN);
 
 	tb = fib_trie_table(id, alias);
-- 
2.7.4


>From e888a3b2b419b4d7729b35f5ed83dda17939f7ee Mon Sep 17 00:00:00 2001
From: David Ahern <dsa@cumulusnetworks.com>
Date: Tue, 3 Jan 2017 09:37:55 -0800
Subject: [PATCH 24/37] net: vrf: Add missing Rx counters

[ Upstream commit 926d93a33e59b2729afdbad357233c17184de9d2 ]

The move from rx-handler to L3 receive handler inadvertantly dropped the
rx counters. Restore them.

Fixes: 74b20582ac38 ("net: l3mdev: Add hook in ip and ipv6")
Reported-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/vrf.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index 3cb3588..809a796 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -968,6 +968,7 @@ static struct sk_buff *vrf_ip6_rcv(struct net_device *vrf_dev,
 	 */
 	need_strict = rt6_need_strict(&ipv6_hdr(skb)->daddr);
 	if (!ipv6_ndisc_frame(skb) && !need_strict) {
+		vrf_rx_stats(vrf_dev, skb->len);
 		skb->dev = vrf_dev;
 		skb->skb_iif = vrf_dev->ifindex;
 
@@ -1009,6 +1010,8 @@ static struct sk_buff *vrf_ip_rcv(struct net_device *vrf_dev,
 		goto out;
 	}
 
+	vrf_rx_stats(vrf_dev, skb->len);
+
 	skb_push(skb, skb->mac_len);
 	dev_queue_xmit_nit(skb, vrf_dev);
 	skb_pull(skb, skb->mac_len);
-- 
2.7.4


>From 6753205ca80ed9a0aa3cb983f92cd9ac33c1e1b0 Mon Sep 17 00:00:00 2001
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Sat, 7 Jan 2017 00:26:33 +0100
Subject: [PATCH 25/37] bpf: change back to orig prog on too many passes

[ Upstream commit 9d5ecb09d525469abd1a10c096cb5a17206523f2 ]

If after too many passes still no image could be emitted, then
swap back to the original program as we do in all other cases
and don't use the one with blinding.

Fixes: 959a75791603 ("bpf, x86: add support for constant blinding")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 arch/x86/net/bpf_jit_comp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index fe04a04..15f7436 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -1172,6 +1172,8 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
 		set_memory_ro((unsigned long)header, header->pages);
 		prog->bpf_func = (void *)image;
 		prog->jited = 1;
+	} else {
+		prog = orig_prog;
 	}
 
 out_addrs:
-- 
2.7.4


>From d8bb61086e84956d2b6bc146471c0c12fe73729a Mon Sep 17 00:00:00 2001
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Sat, 7 Jan 2017 21:01:56 -0800
Subject: [PATCH 26/37] net: dsa: bcm_sf2: Do not clobber b53_switch_ops

[ Upstream commit a4c61b92b3a4cbda35bb0251a5063a68f0861b2c ]

We make the bcm_sf2 driver override ds->ops which points to
b53_switch_ops since b53_switch_alloc() did the assignent. This is all
well and good until a second b53 switch comes in, and ends up using the
bcm_sf2 operations. Make a proper local copy, substitute the ds->ops
pointer and then override the operations.

Fixes: f458995b9ad8 ("net: dsa: bcm_sf2: Utilize core B53 driver when possible")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/dsa/bcm_sf2.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 9ec33b5..2f9f910 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -982,6 +982,7 @@ static int bcm_sf2_sw_probe(struct platform_device *pdev)
 	const char *reg_names[BCM_SF2_REGS_NUM] = BCM_SF2_REGS_NAME;
 	struct device_node *dn = pdev->dev.of_node;
 	struct b53_platform_data *pdata;
+	struct dsa_switch_ops *ops;
 	struct bcm_sf2_priv *priv;
 	struct b53_device *dev;
 	struct dsa_switch *ds;
@@ -995,6 +996,10 @@ static int bcm_sf2_sw_probe(struct platform_device *pdev)
 	if (!priv)
 		return -ENOMEM;
 
+	ops = devm_kzalloc(&pdev->dev, sizeof(*ops), GFP_KERNEL);
+	if (!ops)
+		return -ENOMEM;
+
 	dev = b53_switch_alloc(&pdev->dev, &bcm_sf2_io_ops, priv);
 	if (!dev)
 		return -ENOMEM;
@@ -1014,6 +1019,8 @@ static int bcm_sf2_sw_probe(struct platform_device *pdev)
 	ds = dev->ds;
 
 	/* Override the parts that are non-standard wrt. normal b53 devices */
+	memcpy(ops, ds->ops, sizeof(*ops));
+	ds->ops = ops;
 	ds->ops->get_tag_protocol = bcm_sf2_sw_get_tag_protocol;
 	ds->ops->setup = bcm_sf2_sw_setup;
 	ds->ops->get_phy_flags = bcm_sf2_sw_get_phy_flags;
-- 
2.7.4


>From 9af108aef47c3ba6869a2fdb87bfe910f52c79cd Mon Sep 17 00:00:00 2001
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Sat, 7 Jan 2017 21:01:57 -0800
Subject: [PATCH 27/37] net: dsa: bcm_sf2: Utilize nested MDIO read/write

[ Upstream commit 2cfe8f8290bd28cf1ee67db914a6e76cf8e6437b ]

We are implementing a MDIO bus which is behind another one, so use the
nested version of the accessors to get lockdep annotations correct.

Fixes: 461cd1b03e32 ("net: dsa: bcm_sf2: Register our slave MDIO bus")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/dsa/bcm_sf2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 2f9f910..2ce7ae9 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -393,7 +393,7 @@ static int bcm_sf2_sw_mdio_read(struct mii_bus *bus, int addr, int regnum)
 	if (addr == BRCM_PSEUDO_PHY_ADDR && priv->indir_phy_mask & BIT(addr))
 		return bcm_sf2_sw_indir_rw(priv, 1, addr, regnum, 0);
 	else
-		return mdiobus_read(priv->master_mii_bus, addr, regnum);
+		return mdiobus_read_nested(priv->master_mii_bus, addr, regnum);
 }
 
 static int bcm_sf2_sw_mdio_write(struct mii_bus *bus, int addr, int regnum,
@@ -407,7 +407,7 @@ static int bcm_sf2_sw_mdio_write(struct mii_bus *bus, int addr, int regnum,
 	if (addr == BRCM_PSEUDO_PHY_ADDR && priv->indir_phy_mask & BIT(addr))
 		bcm_sf2_sw_indir_rw(priv, 0, addr, regnum, val);
 	else
-		mdiobus_write(priv->master_mii_bus, addr, regnum, val);
+		mdiobus_write_nested(priv->master_mii_bus, addr, regnum, val);
 
 	return 0;
 }
-- 
2.7.4


>From c006857a93c7c5022d3c881c879d93ecd674b9a1 Mon Sep 17 00:00:00 2001
From: hayeswang <hayeswang@realtek.com>
Date: Tue, 10 Jan 2017 17:04:06 +0800
Subject: [PATCH 28/37] r8152: split rtl8152_suspend function

[ Upstream commit 8fb280616878b81c0790a0c33acbeec59c5711f4 ]

Split rtl8152_suspend() into rtl8152_system_suspend() and
rtl8152_rumtime_suspend().

Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/usb/r8152.c | 57 ++++++++++++++++++++++++++++++++++---------------
 1 file changed, 40 insertions(+), 17 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index efb84f0..1d1fc37 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3576,39 +3576,62 @@ static bool delay_autosuspend(struct r8152 *tp)
 		return false;
 }
 
-static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
+static int rtl8152_rumtime_suspend(struct r8152 *tp)
 {
-	struct r8152 *tp = usb_get_intfdata(intf);
 	struct net_device *netdev = tp->netdev;
 	int ret = 0;
 
-	mutex_lock(&tp->control);
-
-	if (PMSG_IS_AUTO(message)) {
-		if (netif_running(netdev) && delay_autosuspend(tp)) {
+	if (netif_running(netdev) && test_bit(WORK_ENABLE, &tp->flags)) {
+		if (delay_autosuspend(tp)) {
 			ret = -EBUSY;
 			goto out1;
 		}
 
-		set_bit(SELECTIVE_SUSPEND, &tp->flags);
-	} else {
-		netif_device_detach(netdev);
+		clear_bit(WORK_ENABLE, &tp->flags);
+		usb_kill_urb(tp->intr_urb);
+		napi_disable(&tp->napi);
+		rtl_stop_rx(tp);
+		tp->rtl_ops.autosuspend_en(tp, true);
+		napi_enable(&tp->napi);
 	}
 
+	set_bit(SELECTIVE_SUSPEND, &tp->flags);
+
+out1:
+	return ret;
+}
+
+static int rtl8152_system_suspend(struct r8152 *tp)
+{
+	struct net_device *netdev = tp->netdev;
+	int ret = 0;
+
+	netif_device_detach(netdev);
+
 	if (netif_running(netdev) && test_bit(WORK_ENABLE, &tp->flags)) {
 		clear_bit(WORK_ENABLE, &tp->flags);
 		usb_kill_urb(tp->intr_urb);
 		napi_disable(&tp->napi);
-		if (test_bit(SELECTIVE_SUSPEND, &tp->flags)) {
-			rtl_stop_rx(tp);
-			tp->rtl_ops.autosuspend_en(tp, true);
-		} else {
-			cancel_delayed_work_sync(&tp->schedule);
-			tp->rtl_ops.down(tp);
-		}
+		cancel_delayed_work_sync(&tp->schedule);
+		tp->rtl_ops.down(tp);
 		napi_enable(&tp->napi);
 	}
-out1:
+
+	return ret;
+}
+
+static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
+{
+	struct r8152 *tp = usb_get_intfdata(intf);
+	int ret;
+
+	mutex_lock(&tp->control);
+
+	if (PMSG_IS_AUTO(message))
+		ret = rtl8152_rumtime_suspend(tp);
+	else
+		ret = rtl8152_system_suspend(tp);
+
 	mutex_unlock(&tp->control);
 
 	return ret;
-- 
2.7.4


>From 52746c2fe0aee121081e4ce28766cbccb1aaf25a Mon Sep 17 00:00:00 2001
From: hayeswang <hayeswang@realtek.com>
Date: Tue, 10 Jan 2017 17:04:07 +0800
Subject: [PATCH 29/37] r8152: fix rx issue for runtime suspend

[ Upstream commit 75dc692eda114cb234a46cb11893a9c3ea520934 ]

Pause the rx and make sure the rx fifo is empty when the autosuspend
occurs.

If the rx data comes when the driver is canceling the rx urb, the host
controller would stop getting the data from the device and continue
it after next rx urb is submitted. That is, one continuing data is
split into two different urb buffers. That let the driver take the
data as a rx descriptor, and unexpected behavior happens.

Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/usb/r8152.c | 31 ++++++++++++++++++++++++++++---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 1d1fc37..4b5cb16 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3582,17 +3582,42 @@ static int rtl8152_rumtime_suspend(struct r8152 *tp)
 	int ret = 0;
 
 	if (netif_running(netdev) && test_bit(WORK_ENABLE, &tp->flags)) {
+		u32 rcr = 0;
+
 		if (delay_autosuspend(tp)) {
 			ret = -EBUSY;
 			goto out1;
 		}
 
+		if (netif_carrier_ok(netdev)) {
+			u32 ocp_data;
+
+			rcr = ocp_read_dword(tp, MCU_TYPE_PLA, PLA_RCR);
+			ocp_data = rcr & ~RCR_ACPT_ALL;
+			ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, ocp_data);
+			rxdy_gated_en(tp, true);
+			ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA,
+						 PLA_OOB_CTRL);
+			if (!(ocp_data & RXFIFO_EMPTY)) {
+				rxdy_gated_en(tp, false);
+				ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, rcr);
+				ret = -EBUSY;
+				goto out1;
+			}
+		}
+
 		clear_bit(WORK_ENABLE, &tp->flags);
 		usb_kill_urb(tp->intr_urb);
-		napi_disable(&tp->napi);
-		rtl_stop_rx(tp);
+
 		tp->rtl_ops.autosuspend_en(tp, true);
-		napi_enable(&tp->napi);
+
+		if (netif_carrier_ok(netdev)) {
+			napi_disable(&tp->napi);
+			rtl_stop_rx(tp);
+			rxdy_gated_en(tp, false);
+			ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, rcr);
+			napi_enable(&tp->napi);
+		}
 	}
 
 	set_bit(SELECTIVE_SUSPEND, &tp->flags);
-- 
2.7.4


>From 597031f66434870163bcf5fac8c29f6d0db5c06a Mon Sep 17 00:00:00 2001
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 9 Jan 2017 11:58:34 -0800
Subject: [PATCH 30/37] net: dsa: Ensure validity of dst->ds[0]

[ Upstream commit faf3a932fbeb77860226a8323eacb835edc98648 ]

It is perfectly possible to have non zero indexed switches being present
in a DSA switch tree, in such a case, we will be deferencing a NULL
pointer while dsa_cpu_port_ethtool_{setup,restore}. Be more defensive
and ensure that dst->ds[0] is valid before doing anything with it.

Fixes: 0c73c523cf73 ("net: dsa: Initialize CPU port ethtool ops per tree")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/dsa/dsa2.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index 5fff951..da38621 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -394,9 +394,11 @@ static int dsa_dst_apply(struct dsa_switch_tree *dst)
 			return err;
 	}
 
-	err = dsa_cpu_port_ethtool_setup(dst->ds[0]);
-	if (err)
-		return err;
+	if (dst->ds[0]) {
+		err = dsa_cpu_port_ethtool_setup(dst->ds[0]);
+		if (err)
+			return err;
+	}
 
 	/* If we use a tagging format that doesn't have an ethertype
 	 * field, make sure that all packets from this point on get
@@ -433,7 +435,8 @@ static void dsa_dst_unapply(struct dsa_switch_tree *dst)
 		dsa_ds_unapply(dst, ds);
 	}
 
-	dsa_cpu_port_ethtool_restore(dst->ds[0]);
+	if (dst->ds[0])
+		dsa_cpu_port_ethtool_restore(dst->ds[0]);
 
 	pr_info("DSA: tree %d unapplied\n", dst->tree);
 	dst->applied = false;
-- 
2.7.4


>From ebcb2f33f7258ad041003398b854744371fd61a9 Mon Sep 17 00:00:00 2001
From: "Anna, Suman" <s-anna@ti.com>
Date: Mon, 9 Jan 2017 21:48:56 -0600
Subject: [PATCH 31/37] net: add the AF_QIPCRTR entries to family name tables

[ Upstream commit 5d722b3024f6762addb8642ffddc9f275b5107ae ]

Commit bdabad3e363d ("net: Add Qualcomm IPC router") introduced a
new address family. Update the family name tables accordingly so
that the lockdep initialization can use the proper names for this
family.

Cc: Courtney Cavin <courtney.cavin@sonymobile.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/core/sock.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/core/sock.c b/net/core/sock.c
index 00a074d..bc6543f 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -222,7 +222,7 @@ static const char *const af_family_key_strings[AF_MAX+1] = {
   "sk_lock-AF_RXRPC" , "sk_lock-AF_ISDN"     , "sk_lock-AF_PHONET"   ,
   "sk_lock-AF_IEEE802154", "sk_lock-AF_CAIF" , "sk_lock-AF_ALG"      ,
   "sk_lock-AF_NFC"   , "sk_lock-AF_VSOCK"    , "sk_lock-AF_KCM"      ,
-  "sk_lock-AF_MAX"
+  "sk_lock-AF_QIPCRTR", "sk_lock-AF_MAX"
 };
 static const char *const af_family_slock_key_strings[AF_MAX+1] = {
   "slock-AF_UNSPEC", "slock-AF_UNIX"     , "slock-AF_INET"     ,
@@ -239,7 +239,7 @@ static const char *const af_family_slock_key_strings[AF_MAX+1] = {
   "slock-AF_RXRPC" , "slock-AF_ISDN"     , "slock-AF_PHONET"   ,
   "slock-AF_IEEE802154", "slock-AF_CAIF" , "slock-AF_ALG"      ,
   "slock-AF_NFC"   , "slock-AF_VSOCK"    ,"slock-AF_KCM"       ,
-  "slock-AF_MAX"
+  "slock-AF_QIPCRTR", "slock-AF_MAX"
 };
 static const char *const af_family_clock_key_strings[AF_MAX+1] = {
   "clock-AF_UNSPEC", "clock-AF_UNIX"     , "clock-AF_INET"     ,
@@ -256,7 +256,7 @@ static const char *const af_family_clock_key_strings[AF_MAX+1] = {
   "clock-AF_RXRPC" , "clock-AF_ISDN"     , "clock-AF_PHONET"   ,
   "clock-AF_IEEE802154", "clock-AF_CAIF" , "clock-AF_ALG"      ,
   "clock-AF_NFC"   , "clock-AF_VSOCK"    , "clock-AF_KCM"      ,
-  "clock-AF_MAX"
+  "clock-AF_QIPCRTR", "clock-AF_MAX"
 };
 
 /*
-- 
2.7.4


>From 232ef16cd693ffd121cb5dba2aef7d66c350779d Mon Sep 17 00:00:00 2001
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 10 Jan 2017 12:24:01 -0800
Subject: [PATCH 32/37] gro: Enter slow-path if there is no tailroom

[ Upstream commit 1272ce87fa017ca4cf32920764d879656b7a005a ]

The GRO path has a fast-path where we avoid calling pskb_may_pull
and pskb_expand by directly accessing frag0.  However, this should
only be done if we have enough tailroom in the skb as otherwise
we'll have to expand it later anyway.

This patch adds the check by capping frag0_len with the skb tailroom.

Fixes: cb18978cbf45 ("gro: Open-code final pskb_may_pull")
Reported-by: Slava Shwartsman <slavash@mellanox.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/core/dev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 6666b28..7b4fa1e 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4453,7 +4453,8 @@ static void skb_gro_reset_offset(struct sk_buff *skb)
 	    pinfo->nr_frags &&
 	    !PageHighMem(skb_frag_page(frag0))) {
 		NAPI_GRO_CB(skb)->frag0 = skb_frag_address(frag0);
-		NAPI_GRO_CB(skb)->frag0_len = skb_frag_size(frag0);
+		NAPI_GRO_CB(skb)->frag0_len = min(skb_frag_size(frag0),
+						  skb->end - skb->tail);
 	}
 }
 
-- 
2.7.4


>From d6a3b358455606aa77f865c8ed66a1b4bfeacada Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet@google.com>
Date: Tue, 10 Jan 2017 19:52:43 -0800
Subject: [PATCH 33/37] gro: use min_t() in skb_gro_reset_offset()

[ Upstream commit 7cfd5fd5a9813f1430290d20c0fead9b4582a307 ]

On 32bit arches, (skb->end - skb->data) is not 'unsigned int',
so we shall use min_t() instead of min() to avoid a compiler error.

Fixes: 1272ce87fa01 ("gro: Enter slow-path if there is no tailroom")
Reported-by: kernel test robot <fengguang.wu@intel.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/core/dev.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 7b4fa1e..e1d731f 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4453,8 +4453,9 @@ static void skb_gro_reset_offset(struct sk_buff *skb)
 	    pinfo->nr_frags &&
 	    !PageHighMem(skb_frag_page(frag0))) {
 		NAPI_GRO_CB(skb)->frag0 = skb_frag_address(frag0);
-		NAPI_GRO_CB(skb)->frag0_len = min(skb_frag_size(frag0),
-						  skb->end - skb->tail);
+		NAPI_GRO_CB(skb)->frag0_len = min_t(unsigned int,
+						    skb_frag_size(frag0),
+						    skb->end - skb->tail);
 	}
 }
 
-- 
2.7.4


>From bfb32bc40b9716b5e7029f72ddab52de04aae347 Mon Sep 17 00:00:00 2001
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 10 Jan 2017 12:24:15 -0800
Subject: [PATCH 34/37] gro: Disable frag0 optimization on IPv6 ext headers

[ Upstream commit 57ea52a865144aedbcd619ee0081155e658b6f7d ]

The GRO fast path caches the frag0 address.  This address becomes
invalid if frag0 is modified by pskb_may_pull or its variants.
So whenever that happens we must disable the frag0 optimization.

This is usually done through the combination of gro_header_hard
and gro_header_slow, however, the IPv6 extension header path did
the pulling directly and would continue to use the GRO fast path
incorrectly.

This patch fixes it by disabling the fast path when we enter the
IPv6 extension header path.

Fixes: 78a478d0efd9 ("gro: Inline skb_gro_header and cache frag0 virtual address")
Reported-by: Slava Shwartsman <slavash@mellanox.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 include/linux/netdevice.h | 9 +++++++--
 net/ipv6/ip6_offload.c    | 1 +
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index e16a2a9..d83590e 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2502,14 +2502,19 @@ static inline int skb_gro_header_hard(struct sk_buff *skb, unsigned int hlen)
 	return NAPI_GRO_CB(skb)->frag0_len < hlen;
 }
 
+static inline void skb_gro_frag0_invalidate(struct sk_buff *skb)
+{
+	NAPI_GRO_CB(skb)->frag0 = NULL;
+	NAPI_GRO_CB(skb)->frag0_len = 0;
+}
+
 static inline void *skb_gro_header_slow(struct sk_buff *skb, unsigned int hlen,
 					unsigned int offset)
 {
 	if (!pskb_may_pull(skb, hlen))
 		return NULL;
 
-	NAPI_GRO_CB(skb)->frag0 = NULL;
-	NAPI_GRO_CB(skb)->frag0_len = 0;
+	skb_gro_frag0_invalidate(skb);
 	return skb->data + offset;
 }
 
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index 89c59e6..fc7b401 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -191,6 +191,7 @@ static struct sk_buff **ipv6_gro_receive(struct sk_buff **head,
 	ops = rcu_dereference(inet6_offloads[proto]);
 	if (!ops || !ops->callbacks.gro_receive) {
 		__pskb_pull(skb, skb_gro_offset(skb));
+		skb_gro_frag0_invalidate(skb);
 		proto = ipv6_gso_pull_exthdrs(skb, proto);
 		skb_gro_pull(skb, -skb_transport_offset(skb));
 		skb_reset_transport_header(skb);
-- 
2.7.4


>From 4dc62f9bfa1aab5b763c90a70aa69bb81f226cf0 Mon Sep 17 00:00:00 2001
From: Gil Rockah <gilr@mellanox.com>
Date: Tue, 10 Jan 2017 22:33:38 +0200
Subject: [PATCH 35/37] net/mlx5e: Remove WARN_ONCE from adaptive moderation
 code

[ Upstream commit 0bbcc0a8fc394d01988fe0263ccf7fddb77a12c3 ]

When trying to do interface down or changing interface configuration
under heavy traffic, some of the adaptive moderation corner cases can
occur and leave a WARN_ONCE call trace in the kernel log.

Those WARN_ONCE are meant for debug only, and should have been inserted
only under debug. We avoid such call traces by removing those WARN_ONCE.

Fixes: cb3c7fd4f839 ("net/mlx5e: Support adaptive RX coalescing")
Signed-off-by: Gil Rockah <gilr@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/mellanox/mlx5/core/en_rx_am.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx_am.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx_am.c
index 1fffe48..cbfac06 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx_am.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx_am.c
@@ -109,7 +109,6 @@ static bool mlx5e_am_on_top(struct mlx5e_rx_am *am)
 	switch (am->tune_state) {
 	case MLX5E_AM_PARKING_ON_TOP:
 	case MLX5E_AM_PARKING_TIRED:
-		WARN_ONCE(true, "mlx5e_am_on_top: PARKING\n");
 		return true;
 	case MLX5E_AM_GOING_RIGHT:
 		return (am->steps_left > 1) && (am->steps_right == 1);
@@ -123,7 +122,6 @@ static void mlx5e_am_turn(struct mlx5e_rx_am *am)
 	switch (am->tune_state) {
 	case MLX5E_AM_PARKING_ON_TOP:
 	case MLX5E_AM_PARKING_TIRED:
-		WARN_ONCE(true, "mlx5e_am_turn: PARKING\n");
 		break;
 	case MLX5E_AM_GOING_RIGHT:
 		am->tune_state = MLX5E_AM_GOING_LEFT;
@@ -144,7 +142,6 @@ static int mlx5e_am_step(struct mlx5e_rx_am *am)
 	switch (am->tune_state) {
 	case MLX5E_AM_PARKING_ON_TOP:
 	case MLX5E_AM_PARKING_TIRED:
-		WARN_ONCE(true, "mlx5e_am_step: PARKING\n");
 		break;
 	case MLX5E_AM_GOING_RIGHT:
 		if (am->profile_ix == (MLX5E_PARAMS_AM_NUM_PROFILES - 1))
@@ -282,10 +279,8 @@ static void mlx5e_am_calc_stats(struct mlx5e_rx_am_sample *start,
 	u32 delta_us = ktime_us_delta(end->time, start->time);
 	unsigned int npkts = end->pkt_ctr - start->pkt_ctr;
 
-	if (!delta_us) {
-		WARN_ONCE(true, "mlx5e_am_calc_stats: delta_us=0\n");
+	if (!delta_us)
 		return;
-	}
 
 	curr_stats->ppms =            (npkts * USEC_PER_MSEC) / delta_us;
 	curr_stats->epms = (MLX5E_AM_NEVENTS * USEC_PER_MSEC) / delta_us;
-- 
2.7.4


>From d1b76429e5c66febb75939f050619f82d25b5361 Mon Sep 17 00:00:00 2001
From: David Ahern <dsa@cumulusnetworks.com>
Date: Tue, 10 Jan 2017 14:37:35 -0800
Subject: [PATCH 36/37] net: ipv4: Fix multipath selection with vrf

[ Upstream commit 7a18c5b9fb31a999afc62b0e60978aa896fc89e9 ]

fib_select_path does not call fib_select_multipath if oif is set in the
flow struct. For VRF use cases oif is always set, so multipath route
selection is bypassed. Use the FLOWI_FLAG_SKIP_NH_OIF to skip the oif
check similar to what is done in fib_table_lookup.

Add saddr and proto to the flow struct for the fib lookup done by the
VRF driver to better match hash computation for a flow.

Fixes: 613d09b30f8b ("net: Use VRF device index for lookups on TX")
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/vrf.c        | 2 ++
 net/ipv4/fib_semantics.c | 9 +++++++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index 809a796..12b8085 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -263,7 +263,9 @@ static netdev_tx_t vrf_process_v4_outbound(struct sk_buff *skb,
 		.flowi4_iif = LOOPBACK_IFINDEX,
 		.flowi4_tos = RT_TOS(ip4h->tos),
 		.flowi4_flags = FLOWI_FLAG_ANYSRC | FLOWI_FLAG_SKIP_NH_OIF,
+		.flowi4_proto = ip4h->protocol,
 		.daddr = ip4h->daddr,
+		.saddr = ip4h->saddr,
 	};
 	struct net *net = dev_net(vrf_dev);
 	struct rtable *rt;
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 388d3e2..a8508b7 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -1617,8 +1617,13 @@ void fib_select_multipath(struct fib_result *res, int hash)
 void fib_select_path(struct net *net, struct fib_result *res,
 		     struct flowi4 *fl4, int mp_hash)
 {
+	bool oif_check;
+
+	oif_check = (fl4->flowi4_oif == 0 ||
+		     fl4->flowi4_flags & FLOWI_FLAG_SKIP_NH_OIF);
+
 #ifdef CONFIG_IP_ROUTE_MULTIPATH
-	if (res->fi->fib_nhs > 1 && fl4->flowi4_oif == 0) {
+	if (res->fi->fib_nhs > 1 && oif_check) {
 		if (mp_hash < 0)
 			mp_hash = get_hash_from_flowi4(fl4) >> 1;
 
@@ -1628,7 +1633,7 @@ void fib_select_path(struct net *net, struct fib_result *res,
 #endif
 	if (!res->prefixlen &&
 	    res->table->tb_num_default > 1 &&
-	    res->type == RTN_UNICAST && !fl4->flowi4_oif)
+	    res->type == RTN_UNICAST && oif_check)
 		fib_select_default(fl4, res);
 
 	if (!fl4->saddr)
-- 
2.7.4


>From be6eb70b61aa2cbaf772ef53cfe0706ecf904aea Mon Sep 17 00:00:00 2001
From: David Ahern <dsa@cumulusnetworks.com>
Date: Tue, 10 Jan 2017 15:22:25 -0800
Subject: [PATCH 37/37] net: vrf: do not allow table id 0

[ Upstream commit 24c63bbc18e25d5d8439422aa5fd2d66390b88eb ]

Frank reported that vrf devices can be created with a table id of 0.
This breaks many of the run time table id checks and should not be
allowed. Detect this condition at create time and fail with EINVAL.

Fixes: 193125dbd8eb ("net: Introduce VRF device driver")
Reported-by: Frank Kellermann <frank.kellermann@atos.net>
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/vrf.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index 12b8085..95cf1d8 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -1239,6 +1239,8 @@ static int vrf_newlink(struct net *src_net, struct net_device *dev,
 		return -EINVAL;
 
 	vrf->tb_id = nla_get_u32(data[IFLA_VRF_TABLE]);
+	if (vrf->tb_id == RT_TABLE_UNSPEC)
+		return -EINVAL;
 
 	dev->priv_flags |= IFF_L3MDEV_MASTER;
 
-- 
2.7.4


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2016-12-07 23:43 David Miller
@ 2016-12-08  6:34 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2016-12-08  6:34 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Wed, Dec 07, 2016 at 06:43:29PM -0500, David Miller wrote:
> 
> Please queue up the following bug fixes for 4.4.x and 4.8.x
> -stable, repectively.

Thanks for these, all queued up!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2016-12-07 23:43 David Miller
  2016-12-08  6:34 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2016-12-07 23:43 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 92 bytes --]


Please queue up the following bug fixes for 4.4.x and 4.8.x
-stable, repectively.

Thanks!

[-- Attachment #2: net_44.mbox --]
[-- Type: Application/Octet-Stream, Size: 56962 bytes --]

[-- Attachment #3: net_48.mbox --]
[-- Type: Application/Octet-Stream, Size: 104368 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2016-11-18  2:59 David Miller
@ 2016-11-18 10:36 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2016-11-18 10:36 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Nov 17, 2016 at 09:59:01PM -0500, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 4.4.x and 4.8.x
> -stable, respectively.

All now queued up, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2016-11-18  2:59 David Miller
  2016-11-18 10:36 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2016-11-18  2:59 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 104 bytes --]


Please queue up the following networking bug fixes for 4.4.x and 4.8.x
-stable, respectively.

Thanks!

[-- Attachment #2: net_44.mbox --]
[-- Type: Application/Octet-Stream, Size: 35259 bytes --]

[-- Attachment #3: net_48.mbox --]
[-- Type: Application/Octet-Stream, Size: 66492 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2016-11-09 17:19 David Miller
@ 2016-11-10 15:50 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2016-11-10 15:50 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Wed, Nov 09, 2016 at 12:19:39PM -0500, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 4.4.x and 4.8.x
> -stable, respectively.

Thanks for these, all now applied.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2016-11-09 17:19 David Miller
  2016-11-10 15:50 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2016-11-09 17:19 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 110 bytes --]


Please queue up the following networking bug fixes for 4.4.x and 4.8.x
-stable, respectively.

Thanks a lot!

[-- Attachment #2: net_44.mbox --]
[-- Type: Application/Octet-Stream, Size: 87205 bytes --]

[-- Attachment #3: net_48.mbox --]
[-- Type: Application/Octet-Stream, Size: 114209 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2016-09-21  5:07 David Miller
@ 2016-09-21  9:23 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2016-09-21  9:23 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Wed, Sep 21, 2016 at 01:07:13AM -0400, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v4.7 -stable.

Now applied thanks.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2016-09-21  5:07 David Miller
  2016-09-21  9:23 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2016-09-21  5:07 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 79 bytes --]


Please queue up the following networking bug fixes for v4.7 -stable.

Thanks!

[-- Attachment #2: net_47.mbox --]
[-- Type: Text/Plain, Size: 104586 bytes --]

From ac464d5c964037be50735da8c2626f99992d6997 Mon Sep 17 00:00:00 2001
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Tue, 2 Aug 2016 16:12:14 +0100
Subject: [PATCH 01/31] bpf: fix method of PTR_TO_PACKET reg id generation

[ Upstream commit 1f415a74b0ca64b5bfacbb12d71ed2ec050a8cfb ]

Using per-register incrementing ID can lead to
find_good_pkt_pointers() confusing registers which
have completely different values.  Consider example:

0: (bf) r6 = r1
1: (61) r8 = *(u32 *)(r6 +76)
2: (61) r0 = *(u32 *)(r6 +80)
3: (bf) r7 = r8
4: (07) r8 += 32
5: (2d) if r8 > r0 goto pc+9
 R0=pkt_end R1=ctx R6=ctx R7=pkt(id=0,off=0,r=32) R8=pkt(id=0,off=32,r=32) R10=fp
6: (bf) r8 = r7
7: (bf) r9 = r7
8: (71) r1 = *(u8 *)(r7 +0)
9: (0f) r8 += r1
10: (71) r1 = *(u8 *)(r7 +1)
11: (0f) r9 += r1
12: (07) r8 += 32
13: (2d) if r8 > r0 goto pc+1
 R0=pkt_end R1=inv56 R6=ctx R7=pkt(id=0,off=0,r=32) R8=pkt(id=1,off=32,r=32) R9=pkt(id=1,off=0,r=32) R10=fp
14: (71) r1 = *(u8 *)(r9 +16)
15: (b7) r7 = 0
16: (bf) r0 = r7
17: (95) exit

We need to get a UNKNOWN_VALUE with imm to force id
generation so lines 0-5 make r7 a valid packet pointer.
We then read two different bytes from the packet and
add them to copies of the constructed packet pointer.
r8 (line 9) and r9 (line 11) will get the same id of 1,
independently.  When either of them is validated (line
13) - find_good_pkt_pointers() will also mark the other
as safe.  This leads to access on line 14 being mistakenly
considered safe.

Fixes: 969bf05eb3ce ("bpf: direct packet access")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 kernel/bpf/verifier.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index eec9f90..6d011c6 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -194,6 +194,7 @@ struct verifier_env {
 	struct verifier_state_list **explored_states; /* search pruning optimization */
 	struct bpf_map *used_maps[MAX_USED_MAPS]; /* array of map's used by eBPF program */
 	u32 used_map_cnt;		/* number of used maps */
+	u32 id_gen;			/* used to generate unique reg IDs */
 	bool allow_ptr_leaks;
 };
 
@@ -1277,7 +1278,7 @@ add_imm:
 		/* dst_reg stays as pkt_ptr type and since some positive
 		 * integer value was added to the pointer, increment its 'id'
 		 */
-		dst_reg->id++;
+		dst_reg->id = ++env->id_gen;
 
 		/* something was added to pkt_ptr, set range and off to zero */
 		dst_reg->off = 0;
-- 
2.1.0


From 586e42298b0b4f821b45e4e86df567ed4cd67578 Mon Sep 17 00:00:00 2001
From: David Forster <dforster@brocade.com>
Date: Wed, 3 Aug 2016 15:13:01 +0100
Subject: [PATCH 02/31] ipv4: panic in leaf_walk_rcu due to stale node pointer

[ Upstream commit 94d9f1c5906b20053efe375b6d66610bca4b8b64 ]

Panic occurs when issuing "cat /proc/net/route" whilst
populating FIB with > 1M routes.

Use of cached node pointer in fib_route_get_idx is unsafe.

 BUG: unable to handle kernel paging request at ffffc90001630024
 IP: [<ffffffff814cf6a0>] leaf_walk_rcu+0x10/0xe0
 PGD 11b08d067 PUD 11b08e067 PMD dac4b067 PTE 0
 Oops: 0000 [#1] SMP
 Modules linked in: nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscac
 snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep virti
 acpi_cpufreq button parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd
tio_ring virtio floppy uhci_hcd ehci_hcd usbcore usb_common libata scsi_mod
 CPU: 1 PID: 785 Comm: cat Not tainted 4.2.0-rc8+ #4
 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
 task: ffff8800da1c0bc0 ti: ffff88011a05c000 task.ti: ffff88011a05c000
 RIP: 0010:[<ffffffff814cf6a0>]  [<ffffffff814cf6a0>] leaf_walk_rcu+0x10/0xe0
 RSP: 0018:ffff88011a05fda0  EFLAGS: 00010202
 RAX: ffff8800d8a40c00 RBX: ffff8800da4af940 RCX: ffff88011a05ff20
 RDX: ffffc90001630020 RSI: 0000000001013531 RDI: ffff8800da4af950
 RBP: 0000000000000000 R08: ffff8800da1f9a00 R09: 0000000000000000
 R10: ffff8800db45b7e4 R11: 0000000000000246 R12: ffff8800da4af950
 R13: ffff8800d97a74c0 R14: 0000000000000000 R15: ffff8800d97a7480
 FS:  00007fd3970e0700(0000) GS:ffff88011fd00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: ffffc90001630024 CR3: 000000011a7e4000 CR4: 00000000000006e0
 Stack:
  ffffffff814d00d3 0000000000000000 ffff88011a05ff20 ffff8800da1f9a00
  ffffffff811dd8b9 0000000000000800 0000000000020000 00007fd396f35000
  ffffffff811f8714 0000000000003431 ffffffff8138dce0 0000000000000f80
 Call Trace:
  [<ffffffff814d00d3>] ? fib_route_seq_start+0x93/0xc0
  [<ffffffff811dd8b9>] ? seq_read+0x149/0x380
  [<ffffffff811f8714>] ? fsnotify+0x3b4/0x500
  [<ffffffff8138dce0>] ? process_echoes+0x70/0x70
  [<ffffffff8121cfa7>] ? proc_reg_read+0x47/0x70
  [<ffffffff811bb823>] ? __vfs_read+0x23/0xd0
  [<ffffffff811bbd42>] ? rw_verify_area+0x52/0xf0
  [<ffffffff811bbe61>] ? vfs_read+0x81/0x120
  [<ffffffff811bcbc2>] ? SyS_read+0x42/0xa0
  [<ffffffff81549ab2>] ? entry_SYSCALL_64_fastpath+0x16/0x75
 Code: 48 85 c0 75 d8 f3 c3 31 c0 c3 f3 c3 66 66 66 66 66 66 2e 0f 1f 84 00 00
a 04 89 f0 33 02 44 89 c9 48 d3 e8 0f b6 4a 05 49 89
 RIP  [<ffffffff814cf6a0>] leaf_walk_rcu+0x10/0xe0
  RSP <ffff88011a05fda0>
 CR2: ffffc90001630024

Signed-off-by: Dave Forster <dforster@brocade.com>
Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/fib_trie.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index d07fc07..febca0f 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -2452,9 +2452,7 @@ struct fib_route_iter {
 static struct key_vector *fib_route_get_idx(struct fib_route_iter *iter,
 					    loff_t pos)
 {
-	struct fib_table *tb = iter->main_tb;
 	struct key_vector *l, **tp = &iter->tnode;
-	struct trie *t;
 	t_key key;
 
 	/* use cache location of next-to-find key */
@@ -2462,8 +2460,6 @@ static struct key_vector *fib_route_get_idx(struct fib_route_iter *iter,
 		pos -= iter->pos;
 		key = iter->key;
 	} else {
-		t = (struct trie *)tb->tb_data;
-		iter->tnode = t->kv;
 		iter->pos = 0;
 		key = 0;
 	}
@@ -2504,12 +2500,12 @@ static void *fib_route_seq_start(struct seq_file *seq, loff_t *pos)
 		return NULL;
 
 	iter->main_tb = tb;
+	t = (struct trie *)tb->tb_data;
+	iter->tnode = t->kv;
 
 	if (*pos != 0)
 		return fib_route_get_idx(iter, *pos);
 
-	t = (struct trie *)tb->tb_data;
-	iter->tnode = t->kv;
 	iter->pos = 0;
 	iter->key = 0;
 
-- 
2.1.0


From cdd3411db299037e14050acf692099c257c3d843 Mon Sep 17 00:00:00 2001
From: Lance Richardson <lrichard@redhat.com>
Date: Tue, 9 Aug 2016 15:29:42 -0400
Subject: [PATCH 03/31] vti: flush x-netns xfrm cache when vti interface is
 removed

[ Upstream commit a5d0dc810abf3d6b241777467ee1d6efb02575fc ]

When executing the script included below, the netns delete operation
hangs with the following message (repeated at 10 second intervals):

  kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

This occurs because a reference to the lo interface in the "secure" netns
is still held by a dst entry in the xfrm bundle cache in the init netns.

Address this problem by garbage collecting the tunnel netns flow cache
when a cross-namespace vti interface receives a NETDEV_DOWN notification.

A more detailed description of the problem scenario (referencing commands
in the script below):

(1) ip link add vti_test type vti local 1.1.1.1 remote 1.1.1.2 key 1

  The vti_test interface is created in the init namespace. vti_tunnel_init()
  attaches a struct ip_tunnel to the vti interface's netdev_priv(dev),
  setting the tunnel net to &init_net.

(2) ip link set vti_test netns secure

  The vti_test interface is moved to the "secure" netns. Note that
  the associated struct ip_tunnel still has tunnel->net set to &init_net.

(3) ip netns exec secure ping -c 4 -i 0.02 -I 192.168.100.1 192.168.200.1

  The first packet sent using the vti device causes xfrm_lookup() to be
  called as follows:

      dst = xfrm_lookup(tunnel->net, skb_dst(skb), fl, NULL, 0);

  Note that tunnel->net is the init namespace, while skb_dst(skb) references
  the vti_test interface in the "secure" namespace. The returned dst
  references an interface in the init namespace.

  Also note that the first parameter to xfrm_lookup() determines which flow
  cache is used to store the computed xfrm bundle, so after xfrm_lookup()
  returns there will be a cached bundle in the init namespace flow cache
  with a dst referencing a device in the "secure" namespace.

(4) ip netns del secure

  Kernel begins to delete the "secure" namespace.  At some point the
  vti_test interface is deleted, at which point dst_ifdown() changes
  the dst->dev in the cached xfrm bundle flow from vti_test to lo (still
  in the "secure" namespace however).
  Since nothing has happened to cause the init namespace's flow cache
  to be garbage collected, this dst remains attached to the flow cache,
  so the kernel loops waiting for the last reference to lo to go away.

<Begin script>
ip link add br1 type bridge
ip link set dev br1 up
ip addr add dev br1 1.1.1.1/8

ip netns add secure
ip link add vti_test type vti local 1.1.1.1 remote 1.1.1.2 key 1
ip link set vti_test netns secure
ip netns exec secure ip link set vti_test up
ip netns exec secure ip link s lo up
ip netns exec secure ip addr add dev lo 192.168.100.1/24
ip netns exec secure ip route add 192.168.200.0/24 dev vti_test
ip xfrm policy flush
ip xfrm state flush
ip xfrm policy add dir out tmpl src 1.1.1.1 dst 1.1.1.2 \
   proto esp mode tunnel mark 1
ip xfrm policy add dir in tmpl src 1.1.1.2 dst 1.1.1.1 \
   proto esp mode tunnel mark 1
ip xfrm state add src 1.1.1.1 dst 1.1.1.2 proto esp spi 1 \
   mode tunnel enc des3_ede 0x112233445566778811223344556677881122334455667788
ip xfrm state add src 1.1.1.2 dst 1.1.1.1 proto esp spi 1 \
   mode tunnel enc des3_ede 0x112233445566778811223344556677881122334455667788

ip netns exec secure ping -c 4 -i 0.02 -I 192.168.100.1 192.168.200.1

ip netns del secure
<End script>

Reported-by: Hangbin Liu <haliu@redhat.com>
Reported-by: Jan Tluka <jtluka@redhat.com>
Signed-off-by: Lance Richardson <lrichard@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/ip_vti.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index a917903..cc701fa 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -557,6 +557,33 @@ static struct rtnl_link_ops vti_link_ops __read_mostly = {
 	.get_link_net	= ip_tunnel_get_link_net,
 };
 
+static bool is_vti_tunnel(const struct net_device *dev)
+{
+	return dev->netdev_ops == &vti_netdev_ops;
+}
+
+static int vti_device_event(struct notifier_block *unused,
+			    unsigned long event, void *ptr)
+{
+	struct net_device *dev = netdev_notifier_info_to_dev(ptr);
+	struct ip_tunnel *tunnel = netdev_priv(dev);
+
+	if (!is_vti_tunnel(dev))
+		return NOTIFY_DONE;
+
+	switch (event) {
+	case NETDEV_DOWN:
+		if (!net_eq(tunnel->net, dev_net(dev)))
+			xfrm_garbage_collect(tunnel->net);
+		break;
+	}
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block vti_notifier_block __read_mostly = {
+	.notifier_call = vti_device_event,
+};
+
 static int __init vti_init(void)
 {
 	const char *msg;
@@ -564,6 +591,8 @@ static int __init vti_init(void)
 
 	pr_info("IPv4 over IPsec tunneling driver\n");
 
+	register_netdevice_notifier(&vti_notifier_block);
+
 	msg = "tunnel device";
 	err = register_pernet_device(&vti_net_ops);
 	if (err < 0)
@@ -596,6 +625,7 @@ xfrm_proto_ah_failed:
 xfrm_proto_esp_failed:
 	unregister_pernet_device(&vti_net_ops);
 pernet_dev_failed:
+	unregister_netdevice_notifier(&vti_notifier_block);
 	pr_err("vti init: failed to register %s\n", msg);
 	return err;
 }
@@ -607,6 +637,7 @@ static void __exit vti_fini(void)
 	xfrm4_protocol_deregister(&vti_ah4_protocol, IPPROTO_AH);
 	xfrm4_protocol_deregister(&vti_esp4_protocol, IPPROTO_ESP);
 	unregister_pernet_device(&vti_net_ops);
+	unregister_netdevice_notifier(&vti_notifier_block);
 }
 
 module_init(vti_init);
-- 
2.1.0


From 7889c7c4ec971899856c105ee9837a7448e8a2c3 Mon Sep 17 00:00:00 2001
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Thu, 11 Aug 2016 21:38:37 +0200
Subject: [PATCH 04/31] bpf: fix write helpers with regards to non-linear parts

[ Upstream commit 0ed661d5a48fa6df0b50ae64d27fe759a3ce42cf ]

Fix the bpf_try_make_writable() helper and all call sites we have in BPF,
it's currently defect with regards to skbs when the write_len spans into
non-linear parts, no matter if cloned or not.

There are multiple issues at once. First, using skb_store_bits() is not
correct since even if we have a cloned skb, page frags can still be shared.
To really make them private, we need to pull them in via __pskb_pull_tail()
first, which also gets us a private head via pskb_expand_head() implicitly.

This is for helpers like bpf_skb_store_bytes(), bpf_l3_csum_replace(),
bpf_l4_csum_replace(). Really, the only thing reasonable and working here
is to call skb_ensure_writable() before any write operation. Meaning, via
pskb_may_pull() it makes sure that parts we want to access are pulled in and
if not does so plus unclones the skb implicitly. If our write_len still fits
the headlen and we're cloned and our header of the clone is not writable,
then we need to make a private copy via pskb_expand_head(). skb_store_bits()
is a bit misleading and only safe to store into non-linear data in different
contexts such as 357b40a18b04 ("[IPV6]: IPV6_CHECKSUM socket option can
corrupt kernel memory").

For above BPF helper functions, it means after fixed bpf_try_make_writable(),
we've pulled in enough, so that we operate always based on skb->data. Thus,
the call to skb_header_pointer() and skb_store_bits() becomes superfluous.
In bpf_skb_store_bytes(), the len check is unnecessary too since it can
only pass in maximum of BPF stack size, so adding offset is guaranteed to
never overflow. Also bpf_l3/4_csum_replace() helpers must test for proper
offset alignment since they use __sum16 pointer for writing resulting csum.

The remaining helpers that change skb data not discussed here yet are
bpf_skb_vlan_push(), bpf_skb_vlan_pop() and bpf_skb_change_proto(). The
vlan helpers internally call either skb_ensure_writable() (pop case) and
skb_cow_head() (push case, for head expansion), respectively. Similarly,
bpf_skb_proto_xlat() takes care to not mangle page frags.

Fixes: 608cd71a9c7c ("tc: bpf: generalize pedit action")
Fixes: 91bc4822c3d6 ("tc: bpf: add checksum helpers")
Fixes: 3697649ff29e ("bpf: try harder on clones when writing into skb")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/core/filter.c | 70 ++++++++++++++-----------------------------------------
 1 file changed, 18 insertions(+), 52 deletions(-)

diff --git a/net/core/filter.c b/net/core/filter.c
index e759d90..bca32d6 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -1353,54 +1353,33 @@ static inline int bpf_try_make_writable(struct sk_buff *skb,
 {
 	int err;
 
-	if (!skb_cloned(skb))
-		return 0;
-	if (skb_clone_writable(skb, write_len))
-		return 0;
-	err = pskb_expand_head(skb, 0, 0, GFP_ATOMIC);
-	if (!err)
-		bpf_compute_data_end(skb);
+	err = skb_ensure_writable(skb, write_len);
+	bpf_compute_data_end(skb);
+
 	return err;
 }
 
 static u64 bpf_skb_store_bytes(u64 r1, u64 r2, u64 r3, u64 r4, u64 flags)
 {
-	struct bpf_scratchpad *sp = this_cpu_ptr(&bpf_sp);
 	struct sk_buff *skb = (struct sk_buff *) (long) r1;
-	int offset = (int) r2;
+	unsigned int offset = (unsigned int) r2;
 	void *from = (void *) (long) r3;
 	unsigned int len = (unsigned int) r4;
 	void *ptr;
 
 	if (unlikely(flags & ~(BPF_F_RECOMPUTE_CSUM | BPF_F_INVALIDATE_HASH)))
 		return -EINVAL;
-
-	/* bpf verifier guarantees that:
-	 * 'from' pointer points to bpf program stack
-	 * 'len' bytes of it were initialized
-	 * 'len' > 0
-	 * 'skb' is a valid pointer to 'struct sk_buff'
-	 *
-	 * so check for invalid 'offset' and too large 'len'
-	 */
-	if (unlikely((u32) offset > 0xffff || len > sizeof(sp->buff)))
+	if (unlikely(offset > 0xffff))
 		return -EFAULT;
 	if (unlikely(bpf_try_make_writable(skb, offset + len)))
 		return -EFAULT;
 
-	ptr = skb_header_pointer(skb, offset, len, sp->buff);
-	if (unlikely(!ptr))
-		return -EFAULT;
-
+	ptr = skb->data + offset;
 	if (flags & BPF_F_RECOMPUTE_CSUM)
 		skb_postpull_rcsum(skb, ptr, len);
 
 	memcpy(ptr, from, len);
 
-	if (ptr == sp->buff)
-		/* skb_store_bits cannot return -EFAULT here */
-		skb_store_bits(skb, offset, ptr, len);
-
 	if (flags & BPF_F_RECOMPUTE_CSUM)
 		skb_postpush_rcsum(skb, ptr, len);
 	if (flags & BPF_F_INVALIDATE_HASH)
@@ -1423,12 +1402,12 @@ static const struct bpf_func_proto bpf_skb_store_bytes_proto = {
 static u64 bpf_skb_load_bytes(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
 {
 	const struct sk_buff *skb = (const struct sk_buff *)(unsigned long) r1;
-	int offset = (int) r2;
+	unsigned int offset = (unsigned int) r2;
 	void *to = (void *)(unsigned long) r3;
 	unsigned int len = (unsigned int) r4;
 	void *ptr;
 
-	if (unlikely((u32) offset > 0xffff))
+	if (unlikely(offset > 0xffff))
 		goto err_clear;
 
 	ptr = skb_header_pointer(skb, offset, len, to);
@@ -1456,20 +1435,17 @@ static const struct bpf_func_proto bpf_skb_load_bytes_proto = {
 static u64 bpf_l3_csum_replace(u64 r1, u64 r2, u64 from, u64 to, u64 flags)
 {
 	struct sk_buff *skb = (struct sk_buff *) (long) r1;
-	int offset = (int) r2;
-	__sum16 sum, *ptr;
+	unsigned int offset = (unsigned int) r2;
+	__sum16 *ptr;
 
 	if (unlikely(flags & ~(BPF_F_HDR_FIELD_MASK)))
 		return -EINVAL;
-	if (unlikely((u32) offset > 0xffff))
-		return -EFAULT;
-	if (unlikely(bpf_try_make_writable(skb, offset + sizeof(sum))))
+	if (unlikely(offset > 0xffff || offset & 1))
 		return -EFAULT;
-
-	ptr = skb_header_pointer(skb, offset, sizeof(sum), &sum);
-	if (unlikely(!ptr))
+	if (unlikely(bpf_try_make_writable(skb, offset + sizeof(*ptr))))
 		return -EFAULT;
 
+	ptr = (__sum16 *)(skb->data + offset);
 	switch (flags & BPF_F_HDR_FIELD_MASK) {
 	case 0:
 		if (unlikely(from != 0))
@@ -1487,10 +1463,6 @@ static u64 bpf_l3_csum_replace(u64 r1, u64 r2, u64 from, u64 to, u64 flags)
 		return -EINVAL;
 	}
 
-	if (ptr == &sum)
-		/* skb_store_bits guaranteed to not return -EFAULT here */
-		skb_store_bits(skb, offset, ptr, sizeof(sum));
-
 	return 0;
 }
 
@@ -1510,20 +1482,18 @@ static u64 bpf_l4_csum_replace(u64 r1, u64 r2, u64 from, u64 to, u64 flags)
 	struct sk_buff *skb = (struct sk_buff *) (long) r1;
 	bool is_pseudo = flags & BPF_F_PSEUDO_HDR;
 	bool is_mmzero = flags & BPF_F_MARK_MANGLED_0;
-	int offset = (int) r2;
-	__sum16 sum, *ptr;
+	unsigned int offset = (unsigned int) r2;
+	__sum16 *ptr;
 
 	if (unlikely(flags & ~(BPF_F_MARK_MANGLED_0 | BPF_F_PSEUDO_HDR |
 			       BPF_F_HDR_FIELD_MASK)))
 		return -EINVAL;
-	if (unlikely((u32) offset > 0xffff))
+	if (unlikely(offset > 0xffff || offset & 1))
 		return -EFAULT;
-	if (unlikely(bpf_try_make_writable(skb, offset + sizeof(sum))))
+	if (unlikely(bpf_try_make_writable(skb, offset + sizeof(*ptr))))
 		return -EFAULT;
 
-	ptr = skb_header_pointer(skb, offset, sizeof(sum), &sum);
-	if (unlikely(!ptr))
-		return -EFAULT;
+	ptr = (__sum16 *)(skb->data + offset);
 	if (is_mmzero && !*ptr)
 		return 0;
 
@@ -1546,10 +1516,6 @@ static u64 bpf_l4_csum_replace(u64 r1, u64 r2, u64 from, u64 to, u64 flags)
 
 	if (is_mmzero && !*ptr)
 		*ptr = CSUM_MANGLED_0;
-	if (ptr == &sum)
-		/* skb_store_bits guaranteed to not return -EFAULT here */
-		skb_store_bits(skb, offset, ptr, sizeof(sum));
-
 	return 0;
 }
 
-- 
2.1.0


From ca5448acf5b54b56193d53a6b5bef5080838231f Mon Sep 17 00:00:00 2001
From: Vegard Nossum <vegard.nossum@oracle.com>
Date: Fri, 12 Aug 2016 10:29:13 +0200
Subject: [PATCH 05/31] net/irda: handle iriap_register_lsap() allocation
 failure

[ Upstream commit 5ba092efc7ddff040777ae7162f1d195f513571b ]

If iriap_register_lsap() fails to allocate memory, self->lsap is
set to NULL. However, none of the callers handle the failure and
irlmp_connect_request() will happily dereference it:

    iriap_register_lsap: Unable to allocated LSAP!
    ================================================================================
    UBSAN: Undefined behaviour in net/irda/irlmp.c:378:2
    member access within null pointer of type 'struct lsap_cb'
    CPU: 1 PID: 15403 Comm: trinity-c0 Not tainted 4.8.0-rc1+ #81
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org
    04/01/2014
     0000000000000000 ffff88010c7e78a8 ffffffff82344f40 0000000041b58ab3
     ffffffff84f98000 ffffffff82344e94 ffff88010c7e78d0 ffff88010c7e7880
     ffff88010630ad00 ffffffff84a5fae0 ffffffff84d3f5c0 000000000000017a
    Call Trace:
     [<ffffffff82344f40>] dump_stack+0xac/0xfc
     [<ffffffff8242f5a8>] ubsan_epilogue+0xd/0x8a
     [<ffffffff824302bf>] __ubsan_handle_type_mismatch+0x157/0x411
     [<ffffffff83b7bdbc>] irlmp_connect_request+0x7ac/0x970
     [<ffffffff83b77cc0>] iriap_connect_request+0xa0/0x160
     [<ffffffff83b77f48>] state_s_disconnect+0x88/0xd0
     [<ffffffff83b78904>] iriap_do_client_event+0x94/0x120
     [<ffffffff83b77710>] iriap_getvaluebyclass_request+0x3e0/0x6d0
     [<ffffffff83ba6ebb>] irda_find_lsap_sel+0x1eb/0x630
     [<ffffffff83ba90c8>] irda_connect+0x828/0x12d0
     [<ffffffff833c0dfb>] SYSC_connect+0x22b/0x340
     [<ffffffff833c7e09>] SyS_connect+0x9/0x10
     [<ffffffff81007bd3>] do_syscall_64+0x1b3/0x4b0
     [<ffffffff845f946a>] entry_SYSCALL64_slow_path+0x25/0x25
    ================================================================================

The bug seems to have been around since forever.

There's more problems with missing error checks in iriap_init() (and
indeed all of irda_init()), but that's a bigger problem that needs
very careful review and testing. This patch will fix the most serious
bug (as it's easily reached from unprivileged userspace).

I have tested my patch with a reproducer.

Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/irda/iriap.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/net/irda/iriap.c b/net/irda/iriap.c
index 4a7ae32a..1138eaf 100644
--- a/net/irda/iriap.c
+++ b/net/irda/iriap.c
@@ -185,8 +185,12 @@ struct iriap_cb *iriap_open(__u8 slsap_sel, int mode, void *priv,
 
 	self->magic = IAS_MAGIC;
 	self->mode = mode;
-	if (mode == IAS_CLIENT)
-		iriap_register_lsap(self, slsap_sel, mode);
+	if (mode == IAS_CLIENT) {
+		if (iriap_register_lsap(self, slsap_sel, mode)) {
+			kfree(self);
+			return NULL;
+		}
+	}
 
 	self->confirm = callback;
 	self->priv = priv;
-- 
2.1.0


From c93fa8978873e5a6a2e74c42ad1be6b57563d517 Mon Sep 17 00:00:00 2001
From: Vegard Nossum <vegard.nossum@oracle.com>
Date: Fri, 12 Aug 2016 09:50:51 +0200
Subject: [PATCH 06/31] net/sctp: always initialise sctp_ht_iter::start_fail

[ Upstream commit 54236ab09e9696a27baaae693c288920a26e8588 ]

sctp_transport_seq_start() does not currently clear iter->start_fail on
success, but relies on it being zero when it is allocated (by
seq_open_net()).

This can be a problem in the following sequence:

    open() // allocates iter (and implicitly sets iter->start_fail = 0)
    read()
     - iter->start() // fails and sets iter->start_fail = 1
     - iter->stop() // doesn't call sctp_transport_walk_stop() (correct)
    read() again
     - iter->start() // succeeds, but doesn't change iter->start_fail
     - iter->stop() // doesn't call sctp_transport_walk_stop() (wrong)

We should initialize sctp_ht_iter::start_fail to zero if ->start()
succeeds, otherwise it's possible that we leave an old value of 1 there,
which will cause ->stop() to not call sctp_transport_walk_stop(), which
causes all sorts of problems like not calling rcu_read_unlock() (and
preempt_enable()), eventually leading to more warnings like this:

    BUG: sleeping function called from invalid context at mm/slab.h:388
    in_atomic(): 0, irqs_disabled(): 0, pid: 16551, name: trinity-c2
    Preemption disabled at:[<ffffffff819bceb6>] rhashtable_walk_start+0x46/0x150

     [<ffffffff81149abb>] preempt_count_add+0x1fb/0x280
     [<ffffffff83295892>] _raw_spin_lock+0x12/0x40
     [<ffffffff819bceb6>] rhashtable_walk_start+0x46/0x150
     [<ffffffff82ec665f>] sctp_transport_walk_start+0x2f/0x60
     [<ffffffff82edda1d>] sctp_transport_seq_start+0x4d/0x150
     [<ffffffff81439e50>] traverse+0x170/0x850
     [<ffffffff8143aeec>] seq_read+0x7cc/0x1180
     [<ffffffff814f996c>] proc_reg_read+0xbc/0x180
     [<ffffffff813d0384>] do_loop_readv_writev+0x134/0x210
     [<ffffffff813d2a95>] do_readv_writev+0x565/0x660
     [<ffffffff813d6857>] vfs_readv+0x67/0xa0
     [<ffffffff813d6c16>] do_preadv+0x126/0x170
     [<ffffffff813d710c>] SyS_preadv+0xc/0x10
     [<ffffffff8100334c>] do_syscall_64+0x19c/0x410
     [<ffffffff83296225>] return_from_SYSCALL_64+0x0/0x6a
     [<ffffffffffffffff>] 0xffffffffffffffff

Notice that this is a subtly different stacktrace from the one in commit
5fc382d875 ("net/sctp: terminate rhashtable walk correctly").

Cc: Xin Long <lucien.xin@gmail.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Acked-By: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/sctp/proc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/sctp/proc.c b/net/sctp/proc.c
index 4cb5aed..ef8ba77 100644
--- a/net/sctp/proc.c
+++ b/net/sctp/proc.c
@@ -293,6 +293,7 @@ static void *sctp_transport_seq_start(struct seq_file *seq, loff_t *pos)
 		return ERR_PTR(err);
 	}
 
+	iter->start_fail = 0;
 	return sctp_transport_get_idx(seq_file_net(seq), &iter->hti, *pos);
 }
 
-- 
2.1.0


From d649313ee57596fa6712c33d707d87dea3f997ea Mon Sep 17 00:00:00 2001
From: Mike Manning <mmanning@brocade.com>
Date: Fri, 12 Aug 2016 12:02:38 +0100
Subject: [PATCH 07/31] net: ipv6: Do not keep IPv6 addresses when IPv6 is
 disabled

[ Upstream commit bc561632dddd5af0c4444d919f01cbf6d553aa0a ]

If IPv6 is disabled when the option is set to keep IPv6
addresses on link down, userspace is unaware of this as
there is no such indication via netlink. The solution is to
remove the IPv6 addresses in this case, which results in
netlink messages indicating removal of addresses in the
usual manner. This fix also makes the behavior consistent
with the case of having IPv6 disabled first, which stops
IPv6 addresses from being added.

Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
Signed-off-by: Mike Manning <mmanning@brocade.com>
Acked-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv6/addrconf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 047c75a..355b6da 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3469,7 +3469,7 @@ static int addrconf_ifdown(struct net_device *dev, int how)
 	/* combine the user config with event to determine if permanent
 	 * addresses are to be removed from address hash table
 	 */
-	keep_addr = !(how || _keep_addr <= 0);
+	keep_addr = !(how || _keep_addr <= 0 || idev->cnf.disable_ipv6);
 
 	/* Step 2: clear hash table */
 	for (i = 0; i < IN6_ADDR_HSIZE; i++) {
@@ -3525,7 +3525,7 @@ restart:
 	/* re-combine the user config with event to determine if permanent
 	 * addresses are to be removed from the interface list
 	 */
-	keep_addr = (!how && _keep_addr > 0);
+	keep_addr = (!how && _keep_addr > 0 && !idev->cnf.disable_ipv6);
 
 	INIT_LIST_HEAD(&del_list);
 	list_for_each_entry_safe(ifa, tmp, &idev->addr_list, if_list) {
-- 
2.1.0


From 1304bb55632d300c260d11a216ce84d142962374 Mon Sep 17 00:00:00 2001
From: Vegard Nossum <vegard.nossum@oracle.com>
Date: Sat, 23 Jul 2016 08:15:04 +0200
Subject: [PATCH 08/31] tipc: fix NULL pointer dereference in shutdown()

[ Upstream commit d2fbdf76b85bcdfe57b8ef2ba09d20e8ada79abd ]

tipc_msg_create() can return a NULL skb and if so, we shouldn't try to
call tipc_node_xmit_skb() on it.

    general protection fault: 0000 [#1] PREEMPT SMP KASAN
    CPU: 3 PID: 30298 Comm: trinity-c0 Not tainted 4.7.0-rc7+ #19
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    task: ffff8800baf09980 ti: ffff8800595b8000 task.ti: ffff8800595b8000
    RIP: 0010:[<ffffffff830bb46b>]  [<ffffffff830bb46b>] tipc_node_xmit_skb+0x6b/0x140
    RSP: 0018:ffff8800595bfce8  EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003023b0e0
    RDX: 0000000000000000 RSI: dffffc0000000000 RDI: ffffffff83d12580
    RBP: ffff8800595bfd78 R08: ffffed000b2b7f32 R09: 0000000000000000
    R10: fffffbfff0759725 R11: 0000000000000000 R12: 1ffff1000b2b7f9f
    R13: ffff8800595bfd58 R14: ffffffff83d12580 R15: dffffc0000000000
    FS:  00007fcdde242700(0000) GS:ffff88011af80000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fcddde1db10 CR3: 000000006874b000 CR4: 00000000000006e0
    DR0: 00007fcdde248000 DR1: 00007fcddd73d000 DR2: 00007fcdde248000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000090602
    Stack:
     0000000000000018 0000000000000018 0000000041b58ab3 ffffffff83954208
     ffffffff830bb400 ffff8800595bfd30 ffffffff8309d767 0000000000000018
     0000000000000018 ffff8800595bfd78 ffffffff8309da1a 00000000810ee611
    Call Trace:
     [<ffffffff830c84a3>] tipc_shutdown+0x553/0x880
     [<ffffffff825b4a3b>] SyS_shutdown+0x14b/0x170
     [<ffffffff8100334c>] do_syscall_64+0x19c/0x410
     [<ffffffff83295ca5>] entry_SYSCALL64_slow_path+0x25/0x25
    Code: 90 00 b4 0b 83 c7 00 f1 f1 f1 f1 4c 8d 6d e0 c7 40 04 00 00 00 f4 c7 40 08 f3 f3 f3 f3 48 89 d8 48 c1 e8 03 c7 45 b4 00 00 00 00 <80> 3c 30 00 75 78 48 8d 7b 08 49 8d 75 c0 48 b8 00 00 00 00 00
    RIP  [<ffffffff830bb46b>] tipc_node_xmit_skb+0x6b/0x140
     RSP <ffff8800595bfce8>
    ---[ end trace 57b0484e351e71f1 ]---

I feel like we should maybe return -ENOMEM or -ENOBUFS, but I'm not sure
userspace is equipped to handle that. Anyway, this is better than a GPF
and looks somewhat consistent with other tipc_msg_create() callers.

Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/tipc/socket.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index c49b8df..f9f5f3c 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -2180,7 +2180,8 @@ restart:
 					      TIPC_CONN_MSG, SHORT_H_SIZE,
 					      0, dnode, onode, dport, oport,
 					      TIPC_CONN_SHUTDOWN);
-			tipc_node_xmit_skb(net, skb, dnode, tsk->portid);
+			if (skb)
+				tipc_node_xmit_skb(net, skb, dnode, tsk->portid);
 		}
 		tsk->connected = 0;
 		sock->state = SS_DISCONNECTING;
-- 
2.1.0


From d6c651b75ad1be18148af6bc38bfd4722914334f Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet@google.com>
Date: Wed, 17 Aug 2016 05:56:26 -0700
Subject: [PATCH 09/31] tcp: fix use after free in tcp_xmit_retransmit_queue()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

[ Upstream commit bb1fceca22492109be12640d49f5ea5a544c6bb4 ]

When tcp_sendmsg() allocates a fresh and empty skb, it puts it at the
tail of the write queue using tcp_add_write_queue_tail()

Then it attempts to copy user data into this fresh skb.

If the copy fails, we undo the work and remove the fresh skb.

Unfortunately, this undo lacks the change done to tp->highest_sack and
we can leave a dangling pointer (to a freed skb)

Later, tcp_xmit_retransmit_queue() can dereference this pointer and
access freed memory. For regular kernels where memory is not unmapped,
this might cause SACK bugs because tcp_highest_sack_seq() is buggy,
returning garbage instead of tp->snd_nxt, but with various debug
features like CONFIG_DEBUG_PAGEALLOC, this can crash the kernel.

This bug was found by Marco Grassi thanks to syzkaller.

Fixes: 6859d49475d4 ("[TCP]: Abstract tp->highest_sack accessing & point to next skb")
Reported-by: Marco Grassi <marco.gra@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 include/net/tcp.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 0bcc70f..7254051 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1522,6 +1522,8 @@ static inline void tcp_check_send_head(struct sock *sk, struct sk_buff *skb_unli
 {
 	if (sk->sk_send_head == skb_unlinked)
 		sk->sk_send_head = NULL;
+	if (tcp_sk(sk)->highest_sack == skb_unlinked)
+		tcp_sk(sk)->highest_sack = NULL;
 }
 
 static inline void tcp_init_send_head(struct sock *sk)
-- 
2.1.0


From a904ec89a39538141a0106dd490cec057ba175ba Mon Sep 17 00:00:00 2001
From: Mohamad Haj Yahia <mohamad@mellanox.com>
Date: Thu, 18 Aug 2016 21:09:04 +0300
Subject: [PATCH 10/31] net/mlx5: Fix pci error recovery flow

[ Upstream commit 1061c90f524963a0a90e7d2f9a6bfa666458af51 ]

When PCI error is detected we should save the state of the pci prior to
disabling it.

Also when receiving pci slot reset call we need to verify that the
device is responsive.

Fixes: 89d44f0a6c73 ('net/mlx5_core: Add pci error handlers to mlx5_core
driver')
Signed-off-by: Mohamad Haj Yahia <mohamad@mellanox.com>

Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/mellanox/mlx5/core/main.c | 59 +++++++++++++-------------
 1 file changed, 29 insertions(+), 30 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 6695893..e782d0f 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -1392,36 +1392,12 @@ static pci_ers_result_t mlx5_pci_err_detected(struct pci_dev *pdev,
 	dev_info(&pdev->dev, "%s was called\n", __func__);
 	mlx5_enter_error_state(dev);
 	mlx5_unload_one(dev, priv);
+	pci_save_state(pdev);
 	mlx5_pci_disable_device(dev);
 	return state == pci_channel_io_perm_failure ?
 		PCI_ERS_RESULT_DISCONNECT : PCI_ERS_RESULT_NEED_RESET;
 }
 
-static pci_ers_result_t mlx5_pci_slot_reset(struct pci_dev *pdev)
-{
-	struct mlx5_core_dev *dev = pci_get_drvdata(pdev);
-	int err = 0;
-
-	dev_info(&pdev->dev, "%s was called\n", __func__);
-
-	err = mlx5_pci_enable_device(dev);
-	if (err) {
-		dev_err(&pdev->dev, "%s: mlx5_pci_enable_device failed with error code: %d\n"
-			, __func__, err);
-		return PCI_ERS_RESULT_DISCONNECT;
-	}
-	pci_set_master(pdev);
-	pci_set_power_state(pdev, PCI_D0);
-	pci_restore_state(pdev);
-
-	return err ? PCI_ERS_RESULT_DISCONNECT : PCI_ERS_RESULT_RECOVERED;
-}
-
-void mlx5_disable_device(struct mlx5_core_dev *dev)
-{
-	mlx5_pci_err_detected(dev->pdev, 0);
-}
-
 /* wait for the device to show vital signs by waiting
  * for the health counter to start counting.
  */
@@ -1449,21 +1425,44 @@ static int wait_vital(struct pci_dev *pdev)
 	return -ETIMEDOUT;
 }
 
-static void mlx5_pci_resume(struct pci_dev *pdev)
+static pci_ers_result_t mlx5_pci_slot_reset(struct pci_dev *pdev)
 {
 	struct mlx5_core_dev *dev = pci_get_drvdata(pdev);
-	struct mlx5_priv *priv = &dev->priv;
 	int err;
 
 	dev_info(&pdev->dev, "%s was called\n", __func__);
 
-	pci_save_state(pdev);
-	err = wait_vital(pdev);
+	err = mlx5_pci_enable_device(dev);
 	if (err) {
+		dev_err(&pdev->dev, "%s: mlx5_pci_enable_device failed with error code: %d\n"
+			, __func__, err);
+		return PCI_ERS_RESULT_DISCONNECT;
+	}
+
+	pci_set_master(pdev);
+	pci_restore_state(pdev);
+
+	if (wait_vital(pdev)) {
 		dev_err(&pdev->dev, "%s: wait_vital timed out\n", __func__);
-		return;
+		return PCI_ERS_RESULT_DISCONNECT;
 	}
 
+	return PCI_ERS_RESULT_RECOVERED;
+}
+
+void mlx5_disable_device(struct mlx5_core_dev *dev)
+{
+	mlx5_pci_err_detected(dev->pdev, 0);
+}
+
+static void mlx5_pci_resume(struct pci_dev *pdev)
+{
+	struct mlx5_core_dev *dev = pci_get_drvdata(pdev);
+	struct mlx5_priv *priv = &dev->priv;
+	int err;
+
+	dev_info(&pdev->dev, "%s was called\n", __func__);
+
 	err = mlx5_load_one(dev, priv);
 	if (err)
 		dev_err(&pdev->dev, "%s: mlx5_load_one failed with error code: %d\n"
-- 
2.1.0


From 9136473f16ce95a07f0939fbddb37960fe5caa53 Mon Sep 17 00:00:00 2001
From: Paul Blakey <paulb@mellanox.com>
Date: Thu, 18 Aug 2016 21:09:05 +0300
Subject: [PATCH 11/31] net/mlx5: Added missing check of msg length in
 verifying its signature

[ Upstream commit 2c0f8ce1b584a4d7b8ff53140d21dfed99834940 ]

Set and verify signature calculates the signature for each of the
mailbox nodes, even for those that are unused (from cache). Added
a missing length check to set and verify only those which are used.

While here, also moved the setting of msg's nodes token to where we
already go over them. This saves a pass because checksum is disabled,
and the only useful thing remaining that set signature does is setting
the token.

Fixes: e126ba97dba9 ('mlx5: Add driver for Mellanox Connect-IB
adapters')
Signed-off-by: Paul Blakey <paulb@mellanox.com>

Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 85 +++++++++++++++++----------
 1 file changed, 54 insertions(+), 31 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
index d6e2a1c..c2ec01a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
@@ -143,13 +143,14 @@ static struct mlx5_cmd_layout *get_inst(struct mlx5_cmd *cmd, int idx)
 	return cmd->cmd_buf + (idx << cmd->log_stride);
 }
 
-static u8 xor8_buf(void *buf, int len)
+static u8 xor8_buf(void *buf, size_t offset, int len)
 {
 	u8 *ptr = buf;
 	u8 sum = 0;
 	int i;
+	int end = len + offset;
 
-	for (i = 0; i < len; i++)
+	for (i = offset; i < end; i++)
 		sum ^= ptr[i];
 
 	return sum;
@@ -157,41 +158,49 @@ static u8 xor8_buf(void *buf, int len)
 
 static int verify_block_sig(struct mlx5_cmd_prot_block *block)
 {
-	if (xor8_buf(block->rsvd0, sizeof(*block) - sizeof(block->data) - 1) != 0xff)
+	size_t rsvd0_off = offsetof(struct mlx5_cmd_prot_block, rsvd0);
+	int xor_len = sizeof(*block) - sizeof(block->data) - 1;
+
+	if (xor8_buf(block, rsvd0_off, xor_len) != 0xff)
 		return -EINVAL;
 
-	if (xor8_buf(block, sizeof(*block)) != 0xff)
+	if (xor8_buf(block, 0, sizeof(*block)) != 0xff)
 		return -EINVAL;
 
 	return 0;
 }
 
-static void calc_block_sig(struct mlx5_cmd_prot_block *block, u8 token,
-			   int csum)
+static void calc_block_sig(struct mlx5_cmd_prot_block *block)
 {
-	block->token = token;
-	if (csum) {
-		block->ctrl_sig = ~xor8_buf(block->rsvd0, sizeof(*block) -
-					    sizeof(block->data) - 2);
-		block->sig = ~xor8_buf(block, sizeof(*block) - 1);
-	}
+	int ctrl_xor_len = sizeof(*block) - sizeof(block->data) - 2;
+	size_t rsvd0_off = offsetof(struct mlx5_cmd_prot_block, rsvd0);
+
+	block->ctrl_sig = ~xor8_buf(block, rsvd0_off, ctrl_xor_len);
+	block->sig = ~xor8_buf(block, 0, sizeof(*block) - 1);
 }
 
-static void calc_chain_sig(struct mlx5_cmd_msg *msg, u8 token, int csum)
+static void calc_chain_sig(struct mlx5_cmd_msg *msg)
 {
 	struct mlx5_cmd_mailbox *next = msg->next;
-
-	while (next) {
-		calc_block_sig(next->buf, token, csum);
+	int size = msg->len;
+	int blen = size - min_t(int, sizeof(msg->first.data), size);
+	int n = (blen + MLX5_CMD_DATA_BLOCK_SIZE - 1)
+		/ MLX5_CMD_DATA_BLOCK_SIZE;
+	int i = 0;
+
+	for (i = 0; i < n && next; i++)  {
+		calc_block_sig(next->buf);
 		next = next->next;
 	}
 }
 
 static void set_signature(struct mlx5_cmd_work_ent *ent, int csum)
 {
-	ent->lay->sig = ~xor8_buf(ent->lay, sizeof(*ent->lay));
-	calc_chain_sig(ent->in, ent->token, csum);
-	calc_chain_sig(ent->out, ent->token, csum);
+	ent->lay->sig = ~xor8_buf(ent->lay, 0,  sizeof(*ent->lay));
+	if (csum) {
+		calc_chain_sig(ent->in);
+		calc_chain_sig(ent->out);
+	}
 }
 
 static void poll_timeout(struct mlx5_cmd_work_ent *ent)
@@ -222,12 +231,17 @@ static int verify_signature(struct mlx5_cmd_work_ent *ent)
 	struct mlx5_cmd_mailbox *next = ent->out->next;
 	int err;
 	u8 sig;
+	int size = ent->out->len;
+	int blen = size - min_t(int, sizeof(ent->out->first.data), size);
+	int n = (blen + MLX5_CMD_DATA_BLOCK_SIZE - 1)
+		/ MLX5_CMD_DATA_BLOCK_SIZE;
+	int i = 0;
 
-	sig = xor8_buf(ent->lay, sizeof(*ent->lay));
+	sig = xor8_buf(ent->lay, 0, sizeof(*ent->lay));
 	if (sig != 0xff)
 		return -EINVAL;
 
-	while (next) {
+	for (i = 0; i < n && next; i++) {
 		err = verify_block_sig(next->buf);
 		if (err)
 			return err;
@@ -656,7 +670,6 @@ static void cmd_work_handler(struct work_struct *work)
 		spin_unlock_irqrestore(&cmd->alloc_lock, flags);
 	}
 
-	ent->token = alloc_token(cmd);
 	cmd->ent_arr[ent->idx] = ent;
 	lay = get_inst(cmd, ent->idx);
 	ent->lay = lay;
@@ -766,7 +779,8 @@ static u8 *get_status_ptr(struct mlx5_outbox_hdr *out)
 static int mlx5_cmd_invoke(struct mlx5_core_dev *dev, struct mlx5_cmd_msg *in,
 			   struct mlx5_cmd_msg *out, void *uout, int uout_size,
 			   mlx5_cmd_cbk_t callback,
-			   void *context, int page_queue, u8 *status)
+			   void *context, int page_queue, u8 *status,
+			   u8 token)
 {
 	struct mlx5_cmd *cmd = &dev->cmd;
 	struct mlx5_cmd_work_ent *ent;
@@ -783,6 +797,8 @@ static int mlx5_cmd_invoke(struct mlx5_core_dev *dev, struct mlx5_cmd_msg *in,
 	if (IS_ERR(ent))
 		return PTR_ERR(ent);
 
+	ent->token = token;
+
 	if (!callback)
 		init_completion(&ent->done);
 
@@ -854,7 +870,8 @@ static const struct file_operations fops = {
 	.write	= dbg_write,
 };
 
-static int mlx5_copy_to_msg(struct mlx5_cmd_msg *to, void *from, int size)
+static int mlx5_copy_to_msg(struct mlx5_cmd_msg *to, void *from, int size,
+			    u8 token)
 {
 	struct mlx5_cmd_prot_block *block;
 	struct mlx5_cmd_mailbox *next;
@@ -880,6 +897,7 @@ static int mlx5_copy_to_msg(struct mlx5_cmd_msg *to, void *from, int size)
 		memcpy(block->data, from, copy);
 		from += copy;
 		size -= copy;
+		block->token = token;
 		next = next->next;
 	}
 
@@ -949,7 +967,8 @@ static void free_cmd_box(struct mlx5_core_dev *dev,
 }
 
 static struct mlx5_cmd_msg *mlx5_alloc_cmd_msg(struct mlx5_core_dev *dev,
-					       gfp_t flags, int size)
+					       gfp_t flags, int size,
+					       u8 token)
 {
 	struct mlx5_cmd_mailbox *tmp, *head = NULL;
 	struct mlx5_cmd_prot_block *block;
@@ -978,6 +997,7 @@ static struct mlx5_cmd_msg *mlx5_alloc_cmd_msg(struct mlx5_core_dev *dev,
 		tmp->next = head;
 		block->next = cpu_to_be64(tmp->next ? tmp->next->dma : 0);
 		block->block_num = cpu_to_be32(n - i - 1);
+		block->token = token;
 		head = tmp;
 	}
 	msg->next = head;
@@ -1352,7 +1372,7 @@ static struct mlx5_cmd_msg *alloc_msg(struct mlx5_core_dev *dev, int in_size,
 	}
 
 	if (IS_ERR(msg))
-		msg = mlx5_alloc_cmd_msg(dev, gfp, in_size);
+		msg = mlx5_alloc_cmd_msg(dev, gfp, in_size, 0);
 
 	return msg;
 }
@@ -1377,6 +1397,7 @@ static int cmd_exec(struct mlx5_core_dev *dev, void *in, int in_size, void *out,
 	int err;
 	u8 status = 0;
 	u32 drv_synd;
+	u8 token;
 
 	if (pci_channel_offline(dev->pdev) ||
 	    dev->state == MLX5_DEVICE_STATE_INTERNAL_ERROR) {
@@ -1395,20 +1416,22 @@ static int cmd_exec(struct mlx5_core_dev *dev, void *in, int in_size, void *out,
 		return err;
 	}
 
-	err = mlx5_copy_to_msg(inb, in, in_size);
+	token = alloc_token(&dev->cmd);
+
+	err = mlx5_copy_to_msg(inb, in, in_size, token);
 	if (err) {
 		mlx5_core_warn(dev, "err %d\n", err);
 		goto out_in;
 	}
 
-	outb = mlx5_alloc_cmd_msg(dev, gfp, out_size);
+	outb = mlx5_alloc_cmd_msg(dev, gfp, out_size, token);
 	if (IS_ERR(outb)) {
 		err = PTR_ERR(outb);
 		goto out_in;
 	}
 
 	err = mlx5_cmd_invoke(dev, inb, outb, out, out_size, callback, context,
-			      pages_queue, &status);
+			      pages_queue, &status, token);
 	if (err)
 		goto out_out;
 
@@ -1476,7 +1499,7 @@ static int create_msg_cache(struct mlx5_core_dev *dev)
 	INIT_LIST_HEAD(&cmd->cache.med.head);
 
 	for (i = 0; i < NUM_LONG_LISTS; i++) {
-		msg = mlx5_alloc_cmd_msg(dev, GFP_KERNEL, LONG_LIST_SIZE);
+		msg = mlx5_alloc_cmd_msg(dev, GFP_KERNEL, LONG_LIST_SIZE, 0);
 		if (IS_ERR(msg)) {
 			err = PTR_ERR(msg);
 			goto ex_err;
@@ -1486,7 +1509,7 @@ static int create_msg_cache(struct mlx5_core_dev *dev)
 	}
 
 	for (i = 0; i < NUM_MED_LISTS; i++) {
-		msg = mlx5_alloc_cmd_msg(dev, GFP_KERNEL, MED_LIST_SIZE);
+		msg = mlx5_alloc_cmd_msg(dev, GFP_KERNEL, MED_LIST_SIZE, 0);
 		if (IS_ERR(msg)) {
 			err = PTR_ERR(msg);
 			goto ex_err;
-- 
2.1.0


From ccfe53b5533ff2a9edd34a56a24eef28bfcf5e7a Mon Sep 17 00:00:00 2001
From: Hadar Hen Zion <hadarh@mellanox.com>
Date: Thu, 18 Aug 2016 21:09:07 +0300
Subject: [PATCH 12/31] net/mlx5e: Use correct flow dissector key on flower
 offloading

[ Upstream commit 1dbd0d373ac338903d27fab5204b13122cc5accd ]

The wrong key is used when extracting the address type field set by
the flower offload code. We have to use the control key and not the
basic key, fix that.

Fixes: e3a2b7ed018e ('net/mlx5e: Support offload cls_flower with drop action')
Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 704c3d3..0db51cc 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -150,7 +150,7 @@ static int parse_cls_flower(struct mlx5e_priv *priv,
 	if (dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_CONTROL)) {
 		struct flow_dissector_key_control *key =
 			skb_flow_dissector_target(f->dissector,
-						  FLOW_DISSECTOR_KEY_BASIC,
+						  FLOW_DISSECTOR_KEY_CONTROL,
 						  f->key);
 		addr_type = key->addr_type;
 	}
-- 
2.1.0


From 192f936598c93f60a1465e67233f8260794f0481 Mon Sep 17 00:00:00 2001
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Mon, 22 Aug 2016 07:10:20 -0400
Subject: [PATCH 13/31] net sched: fix encoding to use real length

[ Upstream commit 28a10c426e81afc88514bca8e73affccf850fdf6 ]

Encoding of the metadata was using the padded length as opposed to
the real length of the data which is a bug per specification.
This has not been an issue todate because all metadatum specified
so far has been 32 bit where aligned and data length are the same width.
This also includes a bug fix for validating the length of a u16 field.
But since there is no metadata of size u16 yes we are fine to include it
here.

While at it get rid of magic numbers.

Fixes: ef6980b6becb ("net sched: introduce IFE action")
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/sched/act_ife.c | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/net/sched/act_ife.c b/net/sched/act_ife.c
index ea4a2fe..5c4cdea 100644
--- a/net/sched/act_ife.c
+++ b/net/sched/act_ife.c
@@ -52,7 +52,7 @@ int ife_tlv_meta_encode(void *skbdata, u16 attrtype, u16 dlen, const void *dval)
 	u32 *tlv = (u32 *)(skbdata);
 	u16 totlen = nla_total_size(dlen);	/*alignment + hdr */
 	char *dptr = (char *)tlv + NLA_HDRLEN;
-	u32 htlv = attrtype << 16 | totlen;
+	u32 htlv = attrtype << 16 | dlen;
 
 	*tlv = htonl(htlv);
 	memset(dptr, 0, totlen - NLA_HDRLEN);
@@ -134,7 +134,7 @@ EXPORT_SYMBOL_GPL(ife_release_meta_gen);
 
 int ife_validate_meta_u32(void *val, int len)
 {
-	if (len == 4)
+	if (len == sizeof(u32))
 		return 0;
 
 	return -EINVAL;
@@ -143,8 +143,8 @@ EXPORT_SYMBOL_GPL(ife_validate_meta_u32);
 
 int ife_validate_meta_u16(void *val, int len)
 {
-	/* length will include padding */
-	if (len == NLA_ALIGN(2))
+	/* length will not include padding */
+	if (len == sizeof(u16))
 		return 0;
 
 	return -EINVAL;
@@ -652,12 +652,14 @@ static int tcf_ife_decode(struct sk_buff *skb, const struct tc_action *a,
 		u8 *tlvdata = (u8 *)tlv;
 		u16 mtype = tlv->type;
 		u16 mlen = tlv->len;
+		u16 alen;
 
 		mtype = ntohs(mtype);
 		mlen = ntohs(mlen);
+		alen = NLA_ALIGN(mlen);
 
-		if (find_decode_metaid(skb, ife, mtype, (mlen - 4),
-				       (void *)(tlvdata + 4))) {
+		if (find_decode_metaid(skb, ife, mtype, (mlen - NLA_HDRLEN),
+				       (void *)(tlvdata + NLA_HDRLEN))) {
 			/* abuse overlimits to count when we receive metadata
 			 * but dont have an ops for it
 			 */
@@ -666,8 +668,8 @@ static int tcf_ife_decode(struct sk_buff *skb, const struct tc_action *a,
 			ife->tcf_qstats.overlimits++;
 		}
 
-		tlvdata += mlen;
-		ifehdrln -= mlen;
+		tlvdata += alen;
+		ifehdrln -= alen;
 		tlv = (struct meta_tlvhdr *)tlvdata;
 	}
 
-- 
2.1.0


From 30d4aecea7fcc5448fb4170590e71d7e3f6cf61d Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet@google.com>
Date: Tue, 23 Aug 2016 13:59:33 -0700
Subject: [PATCH 14/31] udp: fix poll() issue with zero sized packets

[ Upstream commit e83c6744e81abc93a20d0eb3b7f504a176a6126a ]

Laura tracked poll() [and friends] regression caused by commit
e6afc8ace6dd ("udp: remove headers from UDP packets before queueing")

udp_poll() needs to know if there is a valid packet in receive queue,
even if its payload length is 0.

Change first_packet_length() to return an signed int, and use -1
as the indication of an empty queue.

Fixes: e6afc8ace6dd ("udp: remove headers from UDP packets before queueing")
Reported-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Tested-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/udp.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index e61f7cd..00d18c5 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1182,13 +1182,13 @@ out:
  *	@sk: socket
  *
  *	Drops all bad checksum frames, until a valid one is found.
- *	Returns the length of found skb, or 0 if none is found.
+ *	Returns the length of found skb, or -1 if none is found.
  */
-static unsigned int first_packet_length(struct sock *sk)
+static int first_packet_length(struct sock *sk)
 {
 	struct sk_buff_head list_kill, *rcvq = &sk->sk_receive_queue;
 	struct sk_buff *skb;
-	unsigned int res;
+	int res;
 
 	__skb_queue_head_init(&list_kill);
 
@@ -1203,7 +1203,7 @@ static unsigned int first_packet_length(struct sock *sk)
 		__skb_unlink(skb, rcvq);
 		__skb_queue_tail(&list_kill, skb);
 	}
-	res = skb ? skb->len : 0;
+	res = skb ? skb->len : -1;
 	spin_unlock_bh(&rcvq->lock);
 
 	if (!skb_queue_empty(&list_kill)) {
@@ -1232,7 +1232,7 @@ int udp_ioctl(struct sock *sk, int cmd, unsigned long arg)
 
 	case SIOCINQ:
 	{
-		unsigned int amount = first_packet_length(sk);
+		int amount = max_t(int, 0, first_packet_length(sk));
 
 		return put_user(amount, (int __user *)arg);
 	}
@@ -2184,7 +2184,7 @@ unsigned int udp_poll(struct file *file, struct socket *sock, poll_table *wait)
 
 	/* Check for false positives due to checksum errors */
 	if ((mask & POLLRDNORM) && !(file->f_flags & O_NONBLOCK) &&
-	    !(sk->sk_shutdown & RCV_SHUTDOWN) && !first_packet_length(sk))
+	    !(sk->sk_shutdown & RCV_SHUTDOWN) && first_packet_length(sk) == -1)
 		mask &= ~(POLLIN | POLLRDNORM);
 
 	return mask;
-- 
2.1.0


From 379bc549817f312645c8e7884a67acb7ca50a32e Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet@google.com>
Date: Mon, 22 Aug 2016 11:31:10 -0700
Subject: [PATCH 15/31] tcp: properly scale window in
 tcp_v[46]_reqsk_send_ack()

[ Upstream commit 20a2b49fc538540819a0c552877086548cff8d8d ]

When sending an ack in SYN_RECV state, we must scale the offered
window if wscale option was negotiated and accepted.

Tested:
 Following packetdrill test demonstrates the issue :

0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0

+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0

// Establish a connection.
+0 < S 0:0(0) win 20000 <mss 1000,sackOK,wscale 7, nop, TS val 100 ecr 0>
+0 > S. 0:0(0) ack 1 win 28960 <mss 1460,sackOK, TS val 100 ecr 100, nop, wscale 7>

+0 < . 1:11(10) ack 1 win 156 <nop,nop,TS val 99 ecr 100>
// check that window is properly scaled !
+0 > . 1:1(0) ack 1 win 226 <nop,nop,TS val 200 ecr 100>

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/tcp_ipv4.c | 8 +++++++-
 net/ipv6/tcp_ipv6.c | 8 +++++++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 3708de2..ba7ce3f 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -814,8 +814,14 @@ static void tcp_v4_reqsk_send_ack(const struct sock *sk, struct sk_buff *skb,
 	u32 seq = (sk->sk_state == TCP_LISTEN) ? tcp_rsk(req)->snt_isn + 1 :
 					     tcp_sk(sk)->snd_nxt;
 
+	/* RFC 7323 2.3
+	 * The window field (SEG.WND) of every outgoing segment, with the
+	 * exception of <SYN> segments, MUST be right-shifted by
+	 * Rcv.Wind.Shift bits:
+	 */
 	tcp_v4_send_ack(sock_net(sk), skb, seq,
-			tcp_rsk(req)->rcv_nxt, req->rsk_rcv_wnd,
+			tcp_rsk(req)->rcv_nxt,
+			req->rsk_rcv_wnd >> inet_rsk(req)->rcv_wscale,
 			tcp_time_stamp,
 			req->ts_recent,
 			0,
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 2255d2b..889acc4 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -937,9 +937,15 @@ static void tcp_v6_reqsk_send_ack(const struct sock *sk, struct sk_buff *skb,
 	/* sk->sk_state == TCP_LISTEN -> for regular TCP_SYN_RECV
 	 * sk->sk_state == TCP_SYN_RECV -> for Fast Open.
 	 */
+	/* RFC 7323 2.3
+	 * The window field (SEG.WND) of every outgoing segment, with the
+	 * exception of <SYN> segments, MUST be right-shifted by
+	 * Rcv.Wind.Shift bits:
+	 */
 	tcp_v6_send_ack(sk, skb, (sk->sk_state == TCP_LISTEN) ?
 			tcp_rsk(req)->snt_isn + 1 : tcp_sk(sk)->snd_nxt,
-			tcp_rsk(req)->rcv_nxt, req->rsk_rcv_wnd,
+			tcp_rsk(req)->rcv_nxt,
+			req->rsk_rcv_wnd >> inet_rsk(req)->rcv_wscale,
 			tcp_time_stamp, req->ts_recent, sk->sk_bound_dev_if,
 			tcp_v6_md5_do_lookup(sk, &ipv6_hdr(skb)->daddr),
 			0, 0);
-- 
2.1.0


From e9787127f87471cbed3abce44c69a90e625ee4de Mon Sep 17 00:00:00 2001
From: Lance Richardson <lrichard@redhat.com>
Date: Tue, 23 Aug 2016 11:40:52 -0400
Subject: [PATCH 16/31] sctp: fix overrun in sctp_diag_dump_one()

[ Upstream commit 232cb53a45965f8789fbf0a9a1962f8c67ab1a3c ]

The function sctp_diag_dump_one() currently performs a memcpy()
of 64 bytes from a 16 byte field into another 16 byte field. Fix
by using correct size, use sizeof to obtain correct size instead
of using a hard-coded constant.

Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file")
Signed-off-by: Lance Richardson <lrichard@redhat.com>
Reviewed-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/sctp/sctp_diag.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/sctp/sctp_diag.c b/net/sctp/sctp_diag.c
index f69edcf..10bae22 100644
--- a/net/sctp/sctp_diag.c
+++ b/net/sctp/sctp_diag.c
@@ -418,11 +418,13 @@ static int sctp_diag_dump_one(struct sk_buff *in_skb,
 		paddr.v4.sin_family = AF_INET;
 	} else {
 		laddr.v6.sin6_port = req->id.idiag_sport;
-		memcpy(&laddr.v6.sin6_addr, req->id.idiag_src, 64);
+		memcpy(&laddr.v6.sin6_addr, req->id.idiag_src,
+		       sizeof(laddr.v6.sin6_addr));
 		laddr.v6.sin6_family = AF_INET6;
 
 		paddr.v6.sin6_port = req->id.idiag_dport;
-		memcpy(&paddr.v6.sin6_addr, req->id.idiag_dst, 64);
+		memcpy(&paddr.v6.sin6_addr, req->id.idiag_dst,
+		       sizeof(paddr.v6.sin6_addr));
 		paddr.v6.sin6_family = AF_INET6;
 	}
 
-- 
2.1.0


From e529ad1119e14ed467ae7587602f6645899b2622 Mon Sep 17 00:00:00 2001
From: Soheil Hassas Yeganeh <soheil@google.com>
Date: Tue, 23 Aug 2016 18:22:33 -0400
Subject: [PATCH 17/31] tun: fix transmit timestamp support

[ Upstream commit 7b996243fab46092fb3a29c773c54be8152366e4 ]

Instead of using sock_tx_timestamp, use skb_tx_timestamp to record
software transmit timestamp of a packet.

sock_tx_timestamp resets and overrides the tx_flags of the skb.
The function is intended to be called from within the protocol
layer when creating the skb, not from a device driver. This is
inconsistent with other drivers and will cause issues for TCP.

In TCP, we intend to sample the timestamps for the last byte
for each sendmsg/sendpage. For that reason, tcp_sendmsg calls
tcp_tx_timestamp only with the last skb that it generates.
For example, if a 128KB message is split into two 64KB packets
we want to sample the SND timestamp of the last packet. The current
code in the tun driver, however, will result in sampling the SND
timestamp for both packets.

Also, when the last packet is split into smaller packets for
retranmission (see tcp_fragment), the tun driver will record
timestamps for all of the retransmitted packets and not only the
last packet.

Fixes: eda297729171 (tun: Support software transmit time stamping.)
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: Francis Yan <francisyyan@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/tun.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index e16487c..34259bd 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -878,11 +878,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
 	if (unlikely(skb_orphan_frags(skb, GFP_ATOMIC)))
 		goto drop;
 
-	if (skb->sk && sk_fullsock(skb->sk)) {
-		sock_tx_timestamp(skb->sk, skb->sk->sk_tsflags,
-				  &skb_shinfo(skb)->tx_flags);
-		sw_tx_timestamp(skb);
-	}
+	skb_tx_timestamp(skb);
 
 	/* Orphan the skb - required as we might hang on to it
 	 * for indefinite time.
-- 
2.1.0


From a99335b01779ec415aaee126e4edcbe1d5f74373 Mon Sep 17 00:00:00 2001
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 24 Aug 2016 11:01:20 -0700
Subject: [PATCH 18/31] net: dsa: bcm_sf2: Fix race condition while unmasking
 interrupts

[ Upstream commit 4f101c47791cdcb831b3ef1f831b1cc51e4fe03c ]

We kept shadow copies of which interrupt sources we have enabled and
disabled, but due to an order bug in how intrl2_mask_clear was defined,
we could run into the following scenario:

CPU0					CPU1
intrl2_1_mask_clear(..)
sets INTRL2_CPU_MASK_CLEAR
					bcm_sf2_switch_1_isr
					read INTRL2_CPU_STATUS and masks with stale
					irq1_mask value
updates irq1_mask value

Which would make us loop again and again trying to process and interrupt
we are not clearing since our copy of whether it was enabled before
still indicates it was not. Fix this by updating the shadow copy first,
and then unasking at the HW level.

Fixes: 246d7f773c13 ("net: dsa: add Broadcom SF2 switch driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/dsa/bcm_sf2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/dsa/bcm_sf2.h b/drivers/net/dsa/bcm_sf2.h
index 200b1f5..71b1e52 100644
--- a/drivers/net/dsa/bcm_sf2.h
+++ b/drivers/net/dsa/bcm_sf2.h
@@ -189,8 +189,8 @@ static inline void name##_writeq(struct bcm_sf2_priv *priv, u64 val,	\
 static inline void intrl2_##which##_mask_clear(struct bcm_sf2_priv *priv, \
 						u32 mask)		\
 {									\
-	intrl2_##which##_writel(priv, mask, INTRL2_CPU_MASK_CLEAR);	\
 	priv->irq##which##_mask &= ~(mask);				\
+	intrl2_##which##_writel(priv, mask, INTRL2_CPU_MASK_CLEAR);	\
 }									\
 static inline void intrl2_##which##_mask_set(struct bcm_sf2_priv *priv, \
 						u32 mask)		\
-- 
2.1.0


From 9468133455b45fcc91f330dd2cb38ff96a4cb8cd Mon Sep 17 00:00:00 2001
From: Xander Huff <xander.huff@ni.com>
Date: Wed, 24 Aug 2016 16:47:53 -0500
Subject: [PATCH 19/31] Revert "phy: IRQ cannot be shared"

[ Upstream commit c3e70edd7c2eed6acd234627a6007627f5c76e8e ]

This reverts:
  commit 33c133cc7598 ("phy: IRQ cannot be shared")

On hardware with multiple PHY devices hooked up to the same IRQ line, allow
them to share it.

Sergei Shtylyov says:
  "I'm not sure now what was the reason I concluded that the IRQ sharing
  was impossible... most probably I thought that the kernel IRQ handling
  code exited the loop over the IRQ actions once IRQ_HANDLED was returned
  -- which is obviously not so in reality..."

Signed-off-by: Xander Huff <xander.huff@ni.com>
Signed-off-by: Nathan Sullivan <nathan.sullivan@ni.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/phy/phy.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index c5dc2c36..c6f6683 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -722,8 +722,10 @@ phy_err:
 int phy_start_interrupts(struct phy_device *phydev)
 {
 	atomic_set(&phydev->irq_disable, 0);
-	if (request_irq(phydev->irq, phy_interrupt, 0, "phy_interrupt",
-			phydev) < 0) {
+	if (request_irq(phydev->irq, phy_interrupt,
+				IRQF_SHARED,
+				"phy_interrupt",
+				phydev) < 0) {
 		pr_warn("%s: Can't get IRQ %d (PHY)\n",
 			phydev->mdio.bus->name, phydev->irq);
 		phydev->irq = PHY_POLL;
-- 
2.1.0


From cf4d945d79563ef8ca88a6e8cdbf5c60cd7c7b1a Mon Sep 17 00:00:00 2001
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Sat, 27 Aug 2016 17:33:03 +0100
Subject: [PATCH 20/31] net: smc91x: fix SMC accesses

[ Upstream commit 2fb04fdf30192ff1e2b5834e9b7745889ea8bbcb ]

Commit b70661c70830 ("net: smc91x: use run-time configuration on all ARM
machines") broke some ARM platforms through several mistakes.  Firstly,
the access size must correspond to the following rule:

(a) at least one of 16-bit or 8-bit access size must be supported
(b) 32-bit accesses are optional, and may be enabled in addition to
    the above.

Secondly, it provides no emulation of 16-bit accesses, instead blindly
making 16-bit accesses even when the platform specifies that only 8-bit
is supported.

Reorganise smc91x.h so we can make use of the existing 16-bit access
emulation already provided - if 16-bit accesses are supported, use
16-bit accesses directly, otherwise if 8-bit accesses are supported,
use the provided 16-bit access emulation.  If neither, BUG().  This
exactly reflects the driver behaviour prior to the commit being fixed.

Since the conversion incorrectly cut down the available access sizes on
several platforms, we also need to go through every platform and fix up
the overly-restrictive access size: Arnd assumed that if a platform can
perform 32-bit, 16-bit and 8-bit accesses, then only a 32-bit access
size needed to be specified - not so, all available access sizes must
be specified.

This likely fixes some performance regressions in doing this: if a
platform does not support 8-bit accesses, 8-bit accesses have been
emulated by performing a 16-bit read-modify-write access.

Tested on the Intel Assabet/Neponset platform, which supports only 8-bit
accesses, which was broken by the original commit.

Fixes: b70661c70830 ("net: smc91x: use run-time configuration on all ARM machines")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 arch/arm/mach-pxa/idp.c                    |  3 +-
 arch/arm/mach-pxa/xcep.c                   |  3 +-
 arch/arm/mach-realview/core.c              |  3 +-
 arch/arm/mach-sa1100/pleb.c                |  2 +-
 arch/blackfin/mach-bf561/boards/cm_bf561.c |  3 +-
 arch/blackfin/mach-bf561/boards/ezkit.c    |  3 +-
 drivers/net/ethernet/smsc/smc91x.c         |  7 ++++
 drivers/net/ethernet/smsc/smc91x.h         | 65 +++++++++++++++++++++---------
 include/linux/smc91x.h                     | 10 +++++
 9 files changed, 73 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-pxa/idp.c b/arch/arm/mach-pxa/idp.c
index c410d84..66070ac 100644
--- a/arch/arm/mach-pxa/idp.c
+++ b/arch/arm/mach-pxa/idp.c
@@ -83,7 +83,8 @@ static struct resource smc91x_resources[] = {
 };
 
 static struct smc91x_platdata smc91x_platdata = {
-	.flags = SMC91X_USE_32BIT | SMC91X_USE_DMA | SMC91X_NOWAIT,
+	.flags = SMC91X_USE_8BIT | SMC91X_USE_16BIT | SMC91X_USE_32BIT |
+		 SMC91X_USE_DMA | SMC91X_NOWAIT,
 };
 
 static struct platform_device smc91x_device = {
diff --git a/arch/arm/mach-pxa/xcep.c b/arch/arm/mach-pxa/xcep.c
index 3f06cd9..056369e 100644
--- a/arch/arm/mach-pxa/xcep.c
+++ b/arch/arm/mach-pxa/xcep.c
@@ -120,7 +120,8 @@ static struct resource smc91x_resources[] = {
 };
 
 static struct smc91x_platdata xcep_smc91x_info = {
-	.flags	= SMC91X_USE_32BIT | SMC91X_NOWAIT | SMC91X_USE_DMA,
+	.flags	= SMC91X_USE_8BIT | SMC91X_USE_16BIT | SMC91X_USE_32BIT |
+		  SMC91X_NOWAIT | SMC91X_USE_DMA,
 };
 
 static struct platform_device smc91x_device = {
diff --git a/arch/arm/mach-realview/core.c b/arch/arm/mach-realview/core.c
index baf1745..a0ead0a 100644
--- a/arch/arm/mach-realview/core.c
+++ b/arch/arm/mach-realview/core.c
@@ -93,7 +93,8 @@ static struct smsc911x_platform_config smsc911x_config = {
 };
 
 static struct smc91x_platdata smc91x_platdata = {
-	.flags = SMC91X_USE_32BIT | SMC91X_NOWAIT,
+	.flags = SMC91X_USE_8BIT | SMC91X_USE_16BIT | SMC91X_USE_32BIT |
+		 SMC91X_NOWAIT,
 };
 
 static struct platform_device realview_eth_device = {
diff --git a/arch/arm/mach-sa1100/pleb.c b/arch/arm/mach-sa1100/pleb.c
index 1525d7b..88149f8 100644
--- a/arch/arm/mach-sa1100/pleb.c
+++ b/arch/arm/mach-sa1100/pleb.c
@@ -45,7 +45,7 @@ static struct resource smc91x_resources[] = {
 };
 
 static struct smc91x_platdata smc91x_platdata = {
-	.flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
+	.flags = SMC91X_USE_16BIT | SMC91X_USE_8BIT | SMC91X_NOWAIT,
 };
 
 static struct platform_device smc91x_device = {
diff --git a/arch/blackfin/mach-bf561/boards/cm_bf561.c b/arch/blackfin/mach-bf561/boards/cm_bf561.c
index c6db52b..10c5777 100644
--- a/arch/blackfin/mach-bf561/boards/cm_bf561.c
+++ b/arch/blackfin/mach-bf561/boards/cm_bf561.c
@@ -146,7 +146,8 @@ static struct platform_device hitachi_fb_device = {
 #include <linux/smc91x.h>
 
 static struct smc91x_platdata smc91x_info = {
-	.flags = SMC91X_USE_32BIT | SMC91X_NOWAIT,
+	.flags = SMC91X_USE_8BIT | SMC91X_USE_16BIT | SMC91X_USE_32BIT |
+		 SMC91X_NOWAIT,
 	.leda = RPC_LED_100_10,
 	.ledb = RPC_LED_TX_RX,
 };
diff --git a/arch/blackfin/mach-bf561/boards/ezkit.c b/arch/blackfin/mach-bf561/boards/ezkit.c
index f35525b..57d1c43 100644
--- a/arch/blackfin/mach-bf561/boards/ezkit.c
+++ b/arch/blackfin/mach-bf561/boards/ezkit.c
@@ -134,7 +134,8 @@ static struct platform_device net2272_bfin_device = {
 #include <linux/smc91x.h>
 
 static struct smc91x_platdata smc91x_info = {
-	.flags = SMC91X_USE_32BIT | SMC91X_NOWAIT,
+	.flags = SMC91X_USE_8BIT | SMC91X_USE_16BIT | SMC91X_USE_32BIT |
+		 SMC91X_NOWAIT,
 	.leda = RPC_LED_100_10,
 	.ledb = RPC_LED_TX_RX,
 };
diff --git a/drivers/net/ethernet/smsc/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c
index 18ac52d..b69d0e1 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -2269,6 +2269,13 @@ static int smc_drv_probe(struct platform_device *pdev)
 	if (pd) {
 		memcpy(&lp->cfg, pd, sizeof(lp->cfg));
 		lp->io_shift = SMC91X_IO_SHIFT(lp->cfg.flags);
+
+		if (!SMC_8BIT(lp) && !SMC_16BIT(lp)) {
+			dev_err(&pdev->dev,
+				"at least one of 8-bit or 16-bit access support is required.\n");
+			ret = -ENXIO;
+			goto out_free_netdev;
+		}
 	}
 
 #if IS_BUILTIN(CONFIG_OF)
diff --git a/drivers/net/ethernet/smsc/smc91x.h b/drivers/net/ethernet/smsc/smc91x.h
index 1a55c79..e17671c 100644
--- a/drivers/net/ethernet/smsc/smc91x.h
+++ b/drivers/net/ethernet/smsc/smc91x.h
@@ -37,6 +37,27 @@
 #include <linux/smc91x.h>
 
 /*
+ * Any 16-bit access is performed with two 8-bit accesses if the hardware
+ * can't do it directly. Most registers are 16-bit so those are mandatory.
+ */
+#define SMC_outw_b(x, a, r)						\
+	do {								\
+		unsigned int __val16 = (x);				\
+		unsigned int __reg = (r);				\
+		SMC_outb(__val16, a, __reg);				\
+		SMC_outb(__val16 >> 8, a, __reg + (1 << SMC_IO_SHIFT));	\
+	} while (0)
+
+#define SMC_inw_b(a, r)							\
+	({								\
+		unsigned int __val16;					\
+		unsigned int __reg = r;					\
+		__val16  = SMC_inb(a, __reg);				\
+		__val16 |= SMC_inb(a, __reg + (1 << SMC_IO_SHIFT)) << 8; \
+		__val16;						\
+	})
+
+/*
  * Define your architecture specific bus configuration parameters here.
  */
 
@@ -55,10 +76,30 @@
 #define SMC_IO_SHIFT		(lp->io_shift)
 
 #define SMC_inb(a, r)		readb((a) + (r))
-#define SMC_inw(a, r)		readw((a) + (r))
+#define SMC_inw(a, r)							\
+	({								\
+		unsigned int __smc_r = r;				\
+		SMC_16BIT(lp) ? readw((a) + __smc_r) :			\
+		SMC_8BIT(lp) ? SMC_inw_b(a, __smc_r) :			\
+		({ BUG(); 0; });					\
+	})
+
 #define SMC_inl(a, r)		readl((a) + (r))
 #define SMC_outb(v, a, r)	writeb(v, (a) + (r))
+#define SMC_outw(v, a, r)						\
+	do {								\
+		unsigned int __v = v, __smc_r = r;			\
+		if (SMC_16BIT(lp))					\
+			__SMC_outw(__v, a, __smc_r);			\
+		else if (SMC_8BIT(lp))					\
+			SMC_outw_b(__v, a, __smc_r);			\
+		else							\
+			BUG();						\
+	} while (0)
+
 #define SMC_outl(v, a, r)	writel(v, (a) + (r))
+#define SMC_insb(a, r, p, l)	readsb((a) + (r), p, l)
+#define SMC_outsb(a, r, p, l)	writesb((a) + (r), p, l)
 #define SMC_insw(a, r, p, l)	readsw((a) + (r), p, l)
 #define SMC_outsw(a, r, p, l)	writesw((a) + (r), p, l)
 #define SMC_insl(a, r, p, l)	readsl((a) + (r), p, l)
@@ -66,7 +107,7 @@
 #define SMC_IRQ_FLAGS		(-1)	/* from resource */
 
 /* We actually can't write halfwords properly if not word aligned */
-static inline void SMC_outw(u16 val, void __iomem *ioaddr, int reg)
+static inline void __SMC_outw(u16 val, void __iomem *ioaddr, int reg)
 {
 	if ((machine_is_mainstone() || machine_is_stargate2() ||
 	     machine_is_pxa_idp()) && reg & 2) {
@@ -416,24 +457,8 @@ smc_pxa_dma_insw(void __iomem *ioaddr, struct smc_local *lp, int reg, int dma,
 
 #if ! SMC_CAN_USE_16BIT
 
-/*
- * Any 16-bit access is performed with two 8-bit accesses if the hardware
- * can't do it directly. Most registers are 16-bit so those are mandatory.
- */
-#define SMC_outw(x, ioaddr, reg)					\
-	do {								\
-		unsigned int __val16 = (x);				\
-		SMC_outb( __val16, ioaddr, reg );			\
-		SMC_outb( __val16 >> 8, ioaddr, reg + (1 << SMC_IO_SHIFT));\
-	} while (0)
-#define SMC_inw(ioaddr, reg)						\
-	({								\
-		unsigned int __val16;					\
-		__val16 =  SMC_inb( ioaddr, reg );			\
-		__val16 |= SMC_inb( ioaddr, reg + (1 << SMC_IO_SHIFT)) << 8; \
-		__val16;						\
-	})
-
+#define SMC_outw(x, ioaddr, reg)	SMC_outw_b(x, ioaddr, reg)
+#define SMC_inw(ioaddr, reg)		SMC_inw_b(ioaddr, reg)
 #define SMC_insw(a, r, p, l)		BUG()
 #define SMC_outsw(a, r, p, l)		BUG()
 
diff --git a/include/linux/smc91x.h b/include/linux/smc91x.h
index 76199b7..e302c44 100644
--- a/include/linux/smc91x.h
+++ b/include/linux/smc91x.h
@@ -1,6 +1,16 @@
 #ifndef __SMC91X_H__
 #define __SMC91X_H__
 
+/*
+ * These bits define which access sizes a platform can support, rather
+ * than the maximal access size.  So, if your platform can do 16-bit
+ * and 32-bit accesses to the SMC91x device, but not 8-bit, set both
+ * SMC91X_USE_16BIT and SMC91X_USE_32BIT.
+ *
+ * The SMC91x driver requires at least one of SMC91X_USE_8BIT or
+ * SMC91X_USE_16BIT to be supported - just setting SMC91X_USE_32BIT is
+ * an invalid configuration.
+ */
 #define SMC91X_USE_8BIT (1 << 0)
 #define SMC91X_USE_16BIT (1 << 1)
 #define SMC91X_USE_32BIT (1 << 2)
-- 
2.1.0


From 33b8e38d6b3e8557167f7672b89e7e48c99872b4 Mon Sep 17 00:00:00 2001
From: Davide Caratti <dcaratti@redhat.com>
Date: Wed, 31 Aug 2016 14:16:44 +0200
Subject: [PATCH 21/31] bridge: re-introduce 'fix parsing of MLDv2 reports'

[ Upstream commit 9264251ee2a55bce8fb93826b3f581fb9eb7e2c2 ]

commit bc8c20acaea1 ("bridge: multicast: treat igmpv3 report with
INCLUDE and no sources as a leave") seems to have accidentally reverted
commit 47cc84ce0c2f ("bridge: fix parsing of MLDv2 reports"). This
commit brings back a change to br_ip6_multicast_mld2_report() where
parsing of MLDv2 reports stops when the first group is successfully
added to the MDB cache.

Fixes: bc8c20acaea1 ("bridge: multicast: treat igmpv3 report with INCLUDE and no sources as a leave")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/bridge/br_multicast.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 4384414..d3abdae 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1121,7 +1121,7 @@ static int br_ip6_multicast_mld2_report(struct net_bridge *br,
 		} else {
 			err = br_ip6_multicast_add_group(br, port,
 							 &grec->grec_mca, vid);
-			if (!err)
+			if (err)
 				break;
 		}
 	}
-- 
2.1.0


From 4d9f8ac74dccd62f4735fec67d6c49702b5a82c6 Mon Sep 17 00:00:00 2001
From: WANG Cong <xiyou.wangcong@gmail.com>
Date: Sun, 28 Aug 2016 21:28:26 -0700
Subject: [PATCH 22/31] kcm: fix a socket double free

[ Upstream commit c0338aff2260ea6c092806312dbb154cec07a242 ]

Dmitry reported a double free on kcm socket, which could
be easily reproduced by:

	#include <unistd.h>
	#include <sys/syscall.h>

	int main()
	{
	  int fd = syscall(SYS_socket, 0x29ul, 0x5ul, 0x0ul, 0, 0, 0);
	  syscall(SYS_ioctl, fd, 0x89e2ul, 0x20a98000ul, 0, 0, 0);
	  return 0;
	}

This is because on the error path, after we install
the new socket file, we call sock_release() to clean
up the socket, which leaves the fd pointing to a freed
socket. Fix this by calling sys_close() on that fd
directly.

Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Tom Herbert <tom@herbertland.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/kcm/kcmsock.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/kcm/kcmsock.c b/net/kcm/kcmsock.c
index 0b68ba7..48613f5 100644
--- a/net/kcm/kcmsock.c
+++ b/net/kcm/kcmsock.c
@@ -13,6 +13,7 @@
 #include <linux/socket.h>
 #include <linux/uaccess.h>
 #include <linux/workqueue.h>
+#include <linux/syscalls.h>
 #include <net/kcm.h>
 #include <net/netns/generic.h>
 #include <net/sock.h>
@@ -2035,7 +2036,7 @@ static int kcm_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
 			if (copy_to_user((void __user *)arg, &info,
 					 sizeof(info))) {
 				err = -EFAULT;
-				sock_release(newsock);
+				sys_close(info.fd);
 			}
 		}
 
-- 
2.1.0


From afbfcc709655ed21b3c8197ed3988b683c0bebf5 Mon Sep 17 00:00:00 2001
From: Mahesh Bandewar <maheshb@google.com>
Date: Thu, 1 Sep 2016 22:18:34 -0700
Subject: [PATCH 23/31] bonding: Fix bonding crash

[ Upstream commit 24b27fc4cdf9e10c5e79e5923b6b7c2c5c95096c ]

Following few steps will crash kernel -

  (a) Create bonding master
      > modprobe bonding miimon=50
  (b) Create macvlan bridge on eth2
      > ip link add link eth2 dev mvl0 address aa:0:0:0:0:01 \
	   type macvlan
  (c) Now try adding eth2 into the bond
      > echo +eth2 > /sys/class/net/bond0/bonding/slaves
      <crash>

Bonding does lots of things before checking if the device enslaved is
busy or not.

In this case when the notifier call-chain sends notifications, the
bond_netdev_event() assumes that the rx_handler /rx_handler_data is
registered while the bond_enslave() hasn't progressed far enough to
register rx_handler for the new slave.

This patch adds a rx_handler check that can be performed right at the
beginning of the enslave code to avoid getting into this situation.

Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/bonding/bond_main.c |  7 ++++---
 include/linux/netdevice.h       |  1 +
 net/core/dev.c                  | 16 ++++++++++++++++
 3 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 4d79819..70dac73 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1341,9 +1341,10 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
 			    slave_dev->name);
 	}
 
-	/* already enslaved */
-	if (slave_dev->flags & IFF_SLAVE) {
-		netdev_dbg(bond_dev, "Error: Device was already enslaved\n");
+	/* already in-use? */
+	if (netdev_is_rx_handler_busy(slave_dev)) {
+		netdev_err(bond_dev,
+			   "Error: Device is in use and cannot be enslaved\n");
 		return -EBUSY;
 	}
 
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index da4b33b..4f0e6fb 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3225,6 +3225,7 @@ static inline void napi_free_frags(struct napi_struct *napi)
 	napi->skb = NULL;
 }
 
+bool netdev_is_rx_handler_busy(struct net_device *dev);
 int netdev_rx_handler_register(struct net_device *dev,
 			       rx_handler_func_t *rx_handler,
 			       void *rx_handler_data);
diff --git a/net/core/dev.c b/net/core/dev.c
index 904ff43..97fb3da 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3979,6 +3979,22 @@ sch_handle_ingress(struct sk_buff *skb, struct packet_type **pt_prev, int *ret,
 }
 
 /**
+ *	netdev_is_rx_handler_busy - check if receive handler is registered
+ *	@dev: device to check
+ *
+ *	Check if a receive handler is already registered for a given device.
+ *	Return true if there one.
+ *
+ *	The caller must hold the rtnl_mutex.
+ */
+bool netdev_is_rx_handler_busy(struct net_device *dev)
+{
+	ASSERT_RTNL();
+	return dev && rtnl_dereference(dev->rx_handler);
+}
+EXPORT_SYMBOL_GPL(netdev_is_rx_handler_busy);
+
+/**
  *	netdev_rx_handler_register - register receive handler
  *	@dev: device to register a handler for
  *	@rx_handler: receive handler to register
-- 
2.1.0


From a7c161f2c3028d90b8481968f718420dcad7c96c Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu, 1 Sep 2016 14:56:49 -0700
Subject: [PATCH 24/31] Revert "af_unix: Fix splice-bind deadlock"

[ Upstream commit 38f7bd94a97b542de86a2be9229289717e33a7a4 ]

This reverts commit c845acb324aa85a39650a14e7696982ceea75dc1.

It turns out that it just replaces one deadlock with another one: we can
still get the wrong lock ordering with the readlock due to overlayfs
calling back into the filesystem layer and still taking the vfs locks
after the readlock.

The proper solution ends up being to just split the readlock into two
pieces: the bind lock (taken *outside* the vfs locks) and the IO lock
(taken *inside* the filesystem locks).  The two locks are independent
anyway.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/unix/af_unix.c | 66 +++++++++++++++++++++---------------------------------
 1 file changed, 26 insertions(+), 40 deletions(-)

diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 735362c..b791b69 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -953,20 +953,32 @@ fail:
 	return NULL;
 }
 
-static int unix_mknod(struct dentry *dentry, const struct path *path, umode_t mode,
-		      struct path *res)
+static int unix_mknod(const char *sun_path, umode_t mode, struct path *res)
 {
-	int err;
+	struct dentry *dentry;
+	struct path path;
+	int err = 0;
+	/*
+	 * Get the parent directory, calculate the hash for last
+	 * component.
+	 */
+	dentry = kern_path_create(AT_FDCWD, sun_path, &path, 0);
+	err = PTR_ERR(dentry);
+	if (IS_ERR(dentry))
+		return err;
 
-	err = security_path_mknod(path, dentry, mode, 0);
+	/*
+	 * All right, let's create it.
+	 */
+	err = security_path_mknod(&path, dentry, mode, 0);
 	if (!err) {
-		err = vfs_mknod(d_inode(path->dentry), dentry, mode, 0);
+		err = vfs_mknod(d_inode(path.dentry), dentry, mode, 0);
 		if (!err) {
-			res->mnt = mntget(path->mnt);
+			res->mnt = mntget(path.mnt);
 			res->dentry = dget(dentry);
 		}
 	}
-
+	done_path_create(&path, dentry);
 	return err;
 }
 
@@ -977,12 +989,10 @@ static int unix_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
 	struct unix_sock *u = unix_sk(sk);
 	struct sockaddr_un *sunaddr = (struct sockaddr_un *)uaddr;
 	char *sun_path = sunaddr->sun_path;
-	int err, name_err;
+	int err;
 	unsigned int hash;
 	struct unix_address *addr;
 	struct hlist_head *list;
-	struct path path;
-	struct dentry *dentry;
 
 	err = -EINVAL;
 	if (sunaddr->sun_family != AF_UNIX)
@@ -998,34 +1008,14 @@ static int unix_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
 		goto out;
 	addr_len = err;
 
-	name_err = 0;
-	dentry = NULL;
-	if (sun_path[0]) {
-		/* Get the parent directory, calculate the hash for last
-		 * component.
-		 */
-		dentry = kern_path_create(AT_FDCWD, sun_path, &path, 0);
-
-		if (IS_ERR(dentry)) {
-			/* delay report until after 'already bound' check */
-			name_err = PTR_ERR(dentry);
-			dentry = NULL;
-		}
-	}
-
 	err = mutex_lock_interruptible(&u->readlock);
 	if (err)
-		goto out_path;
+		goto out;
 
 	err = -EINVAL;
 	if (u->addr)
 		goto out_up;
 
-	if (name_err) {
-		err = name_err == -EEXIST ? -EADDRINUSE : name_err;
-		goto out_up;
-	}
-
 	err = -ENOMEM;
 	addr = kmalloc(sizeof(*addr)+addr_len, GFP_KERNEL);
 	if (!addr)
@@ -1036,11 +1026,11 @@ static int unix_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
 	addr->hash = hash ^ sk->sk_type;
 	atomic_set(&addr->refcnt, 1);
 
-	if (dentry) {
-		struct path u_path;
+	if (sun_path[0]) {
+		struct path path;
 		umode_t mode = S_IFSOCK |
 		       (SOCK_INODE(sock)->i_mode & ~current_umask());
-		err = unix_mknod(dentry, &path, mode, &u_path);
+		err = unix_mknod(sun_path, mode, &path);
 		if (err) {
 			if (err == -EEXIST)
 				err = -EADDRINUSE;
@@ -1048,9 +1038,9 @@ static int unix_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
 			goto out_up;
 		}
 		addr->hash = UNIX_HASH_SIZE;
-		hash = d_real_inode(dentry)->i_ino & (UNIX_HASH_SIZE - 1);
+		hash = d_real_inode(path.dentry)->i_ino & (UNIX_HASH_SIZE - 1);
 		spin_lock(&unix_table_lock);
-		u->path = u_path;
+		u->path = path;
 		list = &unix_socket_table[hash];
 	} else {
 		spin_lock(&unix_table_lock);
@@ -1073,10 +1063,6 @@ out_unlock:
 	spin_unlock(&unix_table_lock);
 out_up:
 	mutex_unlock(&u->readlock);
-out_path:
-	if (dentry)
-		done_path_create(&path, dentry);
-
 out:
 	return err;
 }
-- 
2.1.0


From f5fe2922d4d6117bce857b8ecc2317200004041f Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu, 1 Sep 2016 14:43:53 -0700
Subject: [PATCH 25/31] af_unix: split 'u->readlock' into two: 'iolock' and
 'bindlock'

[ Upstream commit 6e1ce3c3451291142a57c4f3f6f999a29fb5b3bc ]

Right now we use the 'readlock' both for protecting some of the af_unix
IO path and for making the bind be single-threaded.

The two are independent, but using the same lock makes for a nasty
deadlock due to ordering with regards to filesystem locking.  The bind
locking would want to nest outside the VSF pathname locking, but the IO
locking wants to nest inside some of those same locks.

We tried to fix this earlier with commit c845acb324aa ("af_unix: Fix
splice-bind deadlock") which moved the readlock inside the vfs locks,
but that caused problems with overlayfs that will then call back into
filesystem routines that take the lock in the wrong order anyway.

Splitting the locks means that we can go back to having the bind lock be
the outermost lock, and we don't have any deadlocks with lock ordering.

Acked-by: Rainer Weikusat <rweikusat@cyberadapt.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 include/net/af_unix.h |  2 +-
 net/unix/af_unix.c    | 45 +++++++++++++++++++++++----------------------
 2 files changed, 24 insertions(+), 23 deletions(-)

diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index 9b4c418..fd60ecc 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -52,7 +52,7 @@ struct unix_sock {
 	struct sock		sk;
 	struct unix_address     *addr;
 	struct path		path;
-	struct mutex		readlock;
+	struct mutex		iolock, bindlock;
 	struct sock		*peer;
 	struct list_head	link;
 	atomic_long_t		inflight;
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index b791b69..e444fa4 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -661,11 +661,11 @@ static int unix_set_peek_off(struct sock *sk, int val)
 {
 	struct unix_sock *u = unix_sk(sk);
 
-	if (mutex_lock_interruptible(&u->readlock))
+	if (mutex_lock_interruptible(&u->iolock))
 		return -EINTR;
 
 	sk->sk_peek_off = val;
-	mutex_unlock(&u->readlock);
+	mutex_unlock(&u->iolock);
 
 	return 0;
 }
@@ -778,7 +778,8 @@ static struct sock *unix_create1(struct net *net, struct socket *sock, int kern)
 	spin_lock_init(&u->lock);
 	atomic_long_set(&u->inflight, 0);
 	INIT_LIST_HEAD(&u->link);
-	mutex_init(&u->readlock); /* single task reading lock */
+	mutex_init(&u->iolock); /* single task reading lock */
+	mutex_init(&u->bindlock); /* single task binding lock */
 	init_waitqueue_head(&u->peer_wait);
 	init_waitqueue_func_entry(&u->peer_wake, unix_dgram_peer_wake_relay);
 	unix_insert_socket(unix_sockets_unbound(sk), sk);
@@ -847,7 +848,7 @@ static int unix_autobind(struct socket *sock)
 	int err;
 	unsigned int retries = 0;
 
-	err = mutex_lock_interruptible(&u->readlock);
+	err = mutex_lock_interruptible(&u->bindlock);
 	if (err)
 		return err;
 
@@ -894,7 +895,7 @@ retry:
 	spin_unlock(&unix_table_lock);
 	err = 0;
 
-out:	mutex_unlock(&u->readlock);
+out:	mutex_unlock(&u->bindlock);
 	return err;
 }
 
@@ -1008,7 +1009,7 @@ static int unix_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
 		goto out;
 	addr_len = err;
 
-	err = mutex_lock_interruptible(&u->readlock);
+	err = mutex_lock_interruptible(&u->bindlock);
 	if (err)
 		goto out;
 
@@ -1062,7 +1063,7 @@ static int unix_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
 out_unlock:
 	spin_unlock(&unix_table_lock);
 out_up:
-	mutex_unlock(&u->readlock);
+	mutex_unlock(&u->bindlock);
 out:
 	return err;
 }
@@ -1954,17 +1955,17 @@ static ssize_t unix_stream_sendpage(struct socket *socket, struct page *page,
 	if (false) {
 alloc_skb:
 		unix_state_unlock(other);
-		mutex_unlock(&unix_sk(other)->readlock);
+		mutex_unlock(&unix_sk(other)->iolock);
 		newskb = sock_alloc_send_pskb(sk, 0, 0, flags & MSG_DONTWAIT,
 					      &err, 0);
 		if (!newskb)
 			goto err;
 	}
 
-	/* we must acquire readlock as we modify already present
+	/* we must acquire iolock as we modify already present
 	 * skbs in the sk_receive_queue and mess with skb->len
 	 */
-	err = mutex_lock_interruptible(&unix_sk(other)->readlock);
+	err = mutex_lock_interruptible(&unix_sk(other)->iolock);
 	if (err) {
 		err = flags & MSG_DONTWAIT ? -EAGAIN : -ERESTARTSYS;
 		goto err;
@@ -2031,7 +2032,7 @@ alloc_skb:
 	}
 
 	unix_state_unlock(other);
-	mutex_unlock(&unix_sk(other)->readlock);
+	mutex_unlock(&unix_sk(other)->iolock);
 
 	other->sk_data_ready(other);
 	scm_destroy(&scm);
@@ -2040,7 +2041,7 @@ alloc_skb:
 err_state_unlock:
 	unix_state_unlock(other);
 err_unlock:
-	mutex_unlock(&unix_sk(other)->readlock);
+	mutex_unlock(&unix_sk(other)->iolock);
 err:
 	kfree_skb(newskb);
 	if (send_sigpipe && !(flags & MSG_NOSIGNAL))
@@ -2108,7 +2109,7 @@ static int unix_dgram_recvmsg(struct socket *sock, struct msghdr *msg,
 	timeo = sock_rcvtimeo(sk, flags & MSG_DONTWAIT);
 
 	do {
-		mutex_lock(&u->readlock);
+		mutex_lock(&u->iolock);
 
 		skip = sk_peek_offset(sk, flags);
 		skb = __skb_try_recv_datagram(sk, flags, &peeked, &skip, &err,
@@ -2116,14 +2117,14 @@ static int unix_dgram_recvmsg(struct socket *sock, struct msghdr *msg,
 		if (skb)
 			break;
 
-		mutex_unlock(&u->readlock);
+		mutex_unlock(&u->iolock);
 
 		if (err != -EAGAIN)
 			break;
 	} while (timeo &&
 		 !__skb_wait_for_more_packets(sk, &err, &timeo, last));
 
-	if (!skb) { /* implies readlock unlocked */
+	if (!skb) { /* implies iolock unlocked */
 		unix_state_lock(sk);
 		/* Signal EOF on disconnected non-blocking SEQPACKET socket. */
 		if (sk->sk_type == SOCK_SEQPACKET && err == -EAGAIN &&
@@ -2188,7 +2189,7 @@ static int unix_dgram_recvmsg(struct socket *sock, struct msghdr *msg,
 
 out_free:
 	skb_free_datagram(sk, skb);
-	mutex_unlock(&u->readlock);
+	mutex_unlock(&u->iolock);
 out:
 	return err;
 }
@@ -2283,7 +2284,7 @@ static int unix_stream_read_generic(struct unix_stream_read_state *state)
 	/* Lock the socket to prevent queue disordering
 	 * while sleeps in memcpy_tomsg
 	 */
-	mutex_lock(&u->readlock);
+	mutex_lock(&u->iolock);
 
 	if (flags & MSG_PEEK)
 		skip = sk_peek_offset(sk, flags);
@@ -2325,7 +2326,7 @@ again:
 				break;
 			}
 
-			mutex_unlock(&u->readlock);
+			mutex_unlock(&u->iolock);
 
 			timeo = unix_stream_data_wait(sk, timeo, last,
 						      last_len);
@@ -2336,7 +2337,7 @@ again:
 				goto out;
 			}
 
-			mutex_lock(&u->readlock);
+			mutex_lock(&u->iolock);
 			goto redo;
 unlock:
 			unix_state_unlock(sk);
@@ -2439,7 +2440,7 @@ unlock:
 		}
 	} while (size);
 
-	mutex_unlock(&u->readlock);
+	mutex_unlock(&u->iolock);
 	if (state->msg)
 		scm_recv(sock, state->msg, &scm, flags);
 	else
@@ -2480,9 +2481,9 @@ static ssize_t skb_unix_socket_splice(struct sock *sk,
 	int ret;
 	struct unix_sock *u = unix_sk(sk);
 
-	mutex_unlock(&u->readlock);
+	mutex_unlock(&u->iolock);
 	ret = splice_to_pipe(pipe, spd);
-	mutex_lock(&u->readlock);
+	mutex_lock(&u->iolock);
 
 	return ret;
 }
-- 
2.1.0


From b3b354081e90a0a9a882cfd73a4a9eec161b207a Mon Sep 17 00:00:00 2001
From: Dave Jones <davej@codemonkey.org.uk>
Date: Fri, 2 Sep 2016 14:39:50 -0400
Subject: [PATCH 26/31] ipv6: release dst in ping_v6_sendmsg

[ Upstream commit 03c2778a938aaba0893f6d6cdc29511d91a79848 ]

Neither the failure or success paths of ping_v6_sendmsg release
the dst it acquires.  This leads to a flood of warnings from
"net/core/dst.c:288 dst_release" on older kernels that
don't have 8bf4ada2e21378816b28205427ee6b0e1ca4c5f1 backported.

That patch optimistically hoped this had been fixed post 3.10, but
it seems at least one case wasn't, where I've seen this triggered
a lot from machines doing unprivileged icmp sockets.

Cc: Martin Lau <kafai@fb.com>
Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv6/ping.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/net/ipv6/ping.c b/net/ipv6/ping.c
index 3ee3e44..4086604 100644
--- a/net/ipv6/ping.c
+++ b/net/ipv6/ping.c
@@ -122,8 +122,10 @@ static int ping_v6_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
 	rt = (struct rt6_info *) dst;
 
 	np = inet6_sk(sk);
-	if (!np)
-		return -EBADF;
+	if (!np) {
+		err = -EBADF;
+		goto dst_err_out;
+	}
 
 	if (!fl6.flowi6_oif && ipv6_addr_is_multicast(&fl6.daddr))
 		fl6.flowi6_oif = np->mcast_oif;
@@ -160,6 +162,9 @@ static int ping_v6_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
 	}
 	release_sock(sk);
 
+dst_err_out:
+	dst_release(dst);
+
 	if (err)
 		return err;
 
-- 
2.1.0


From 34037b34784d2a8cf918e826b0165f85face272f Mon Sep 17 00:00:00 2001
From: Michael Chan <michael.chan@broadcom.com>
Date: Mon, 5 Sep 2016 01:57:35 -0400
Subject: [PATCH 27/31] bnxt_en: Fix TX push operation on ARM64.

[ Upstream commit 9d13744bb75078175ab49408f2abb980e4dbccc9 ]

There is a code path where we are calling __iowrite64_copy() on
an address that is not 64-bit aligned.  This causes an exception on
some architectures such as arm64.  Fix that code path by using
__iowrite32_copy().

Reported-by: JD Zheng <jiandong.zheng@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index c777cde..e655b76 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -293,8 +293,8 @@ static netdev_tx_t bnxt_start_xmit(struct sk_buff *skb, struct net_device *dev)
 		push_len = (length + sizeof(*tx_push) + 7) / 8;
 		if (push_len > 16) {
 			__iowrite64_copy(txr->tx_doorbell, tx_push_buf, 16);
-			__iowrite64_copy(txr->tx_doorbell + 4, tx_push_buf + 1,
-					 push_len - 16);
+			__iowrite32_copy(txr->tx_doorbell + 4, tx_push_buf + 1,
+					 (push_len - 16) << 1);
 		} else {
 			__iowrite64_copy(txr->tx_doorbell, tx_push_buf,
 					 push_len);
-- 
2.1.0


From 9e243d4cac8a0cb7c7b64f1819f00729bc8d544e Mon Sep 17 00:00:00 2001
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Mon, 5 Sep 2016 16:06:31 +0800
Subject: [PATCH 28/31] ipv6: addrconf: fix dev refcont leak when DAD failed

[ Upstream commit 751eb6b6042a596b0080967c1a529a9fe98dac1d ]

In general, when DAD detected IPv6 duplicate address, ifp->state
will be set to INET6_IFADDR_STATE_ERRDAD and DAD is stopped by a
delayed work, the call tree should be like this:

ndisc_recv_ns
  -> addrconf_dad_failure        <- missing ifp put
     -> addrconf_mod_dad_work
       -> schedule addrconf_dad_work()
         -> addrconf_dad_stop()  <- missing ifp hold before call it

addrconf_dad_failure() called with ifp refcont holding but not put.
addrconf_dad_work() call addrconf_dad_stop() without extra holding
refcount. This will not cause any issue normally.

But the race between addrconf_dad_failure() and addrconf_dad_work()
may cause ifp refcount leak and netdevice can not be unregister,
dmesg show the following messages:

IPv6: eth0: IPv6 duplicate address fe80::XX:XXXX:XXXX:XX detected!
...
unregister_netdevice: waiting for eth0 to become free. Usage count = 1

Cc: stable@vger.kernel.org
Fixes: c15b1ccadb32 ("ipv6: move DAD and addrconf_verify processing
to workqueue")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv6/addrconf.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 355b6da..82e367b 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1906,6 +1906,7 @@ errdad:
 	spin_unlock_bh(&ifp->lock);
 
 	addrconf_mod_dad_work(ifp, 0);
+	in6_ifa_put(ifp);
 }
 
 /* Join to solicited addr multicast group.
@@ -3771,6 +3772,7 @@ static void addrconf_dad_work(struct work_struct *w)
 		addrconf_dad_begin(ifp);
 		goto out;
 	} else if (action == DAD_ABORT) {
+		in6_ifa_hold(ifp);
 		addrconf_dad_stop(ifp, 1);
 		goto out;
 	}
-- 
2.1.0


From 6cf0ee7696851b9bee1f0074af866a26db7ad0dd Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet@google.com>
Date: Wed, 7 Sep 2016 08:34:11 -0700
Subject: [PATCH 29/31] tcp: fastopen: avoid negative sk_forward_alloc

[ Upstream commit 76061f631c2ea4ab9c4d66f3a96ecc5737f5aaf7 ]

When DATA and/or FIN are carried in a SYN/ACK message or SYN message,
we append an skb in socket receive queue, but we forget to call
sk_forced_mem_schedule().

Effect is that the socket has a negative sk->sk_forward_alloc as long as
the message is not read by the application.

Josh Hunt fixed a similar issue in commit d22e15371811 ("tcp: fix tcp
fin memory accounting")

Fixes: 168a8f58059a ("tcp: TCP Fast Open Server - main code path")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Josh Hunt <johunt@akamai.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/tcp_fastopen.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
index 54d9f9b..478114b 100644
--- a/net/ipv4/tcp_fastopen.c
+++ b/net/ipv4/tcp_fastopen.c
@@ -150,6 +150,7 @@ void tcp_fastopen_add_skb(struct sock *sk, struct sk_buff *skb)
 	tp->segs_in = 0;
 	tcp_segs_in(tp, skb);
 	__skb_pull(skb, tcp_hdrlen(skb));
+	sk_forced_mem_schedule(sk, skb->truesize);
 	skb_set_owner_r(skb, sk);
 
 	TCP_SKB_CB(skb)->seq++;
-- 
2.1.0


From 202d1426b5c4db7c271521958697ad19e55ec64d Mon Sep 17 00:00:00 2001
From: Gal Pressman <galp@mellanox.com>
Date: Wed, 7 Sep 2016 19:08:01 +0300
Subject: [PATCH 30/31] net/mlx5e: Fix parsing of vlan packets when updating
 lro header

[ Upstream commit cd17d230dd060a12f7451c0caeedb3fd5158eaf9 ]

Currently vlan tagged packets were not parsed correctly
and assumed to be regular IPv4/IPv6 packets.
We should check for 802.1Q/802.1ad tags and update the lro header
accordingly.
This fixes the use case where LRO is on and rxvlan is off
(vlan stripping is off).

Fixes: e586b3b0baee ('net/mlx5: Ethernet Datapath files')
Signed-off-by: Gal Pressman <galp@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 22 +++++++++++++++-------
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index 9f2a16a..e41a066 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
@@ -648,24 +648,32 @@ bool mlx5e_post_rx_wqes(struct mlx5e_rq *rq)
 static void mlx5e_lro_update_hdr(struct sk_buff *skb, struct mlx5_cqe64 *cqe,
 				 u32 cqe_bcnt)
 {
-	struct ethhdr	*eth	= (struct ethhdr *)(skb->data);
-	struct iphdr	*ipv4	= (struct iphdr *)(skb->data + ETH_HLEN);
-	struct ipv6hdr	*ipv6	= (struct ipv6hdr *)(skb->data + ETH_HLEN);
+	struct ethhdr	*eth = (struct ethhdr *)(skb->data);
+	struct iphdr	*ipv4;
+	struct ipv6hdr	*ipv6;
 	struct tcphdr	*tcp;
+	int network_depth = 0;
+	__be16 proto;
+	u16 tot_len;
 
 	u8 l4_hdr_type = get_cqe_l4_hdr_type(cqe);
 	int tcp_ack = ((CQE_L4_HDR_TYPE_TCP_ACK_NO_DATA  == l4_hdr_type) ||
 		       (CQE_L4_HDR_TYPE_TCP_ACK_AND_DATA == l4_hdr_type));
 
-	u16 tot_len = cqe_bcnt - ETH_HLEN;
+	skb->mac_len = ETH_HLEN;
+	proto = __vlan_get_protocol(skb, eth->h_proto, &network_depth);
 
-	if (eth->h_proto == htons(ETH_P_IP)) {
-		tcp = (struct tcphdr *)(skb->data + ETH_HLEN +
+	ipv4 = (struct iphdr *)(skb->data + network_depth);
+	ipv6 = (struct ipv6hdr *)(skb->data + network_depth);
+	tot_len = cqe_bcnt - network_depth;
+
+	if (proto == htons(ETH_P_IP)) {
+		tcp = (struct tcphdr *)(skb->data + network_depth +
 					sizeof(struct iphdr));
 		ipv6 = NULL;
 		skb_shinfo(skb)->gso_type = SKB_GSO_TCPV4;
 	} else {
-		tcp = (struct tcphdr *)(skb->data + ETH_HLEN +
+		tcp = (struct tcphdr *)(skb->data + network_depth +
 					sizeof(struct ipv6hdr));
 		ipv4 = NULL;
 		skb_shinfo(skb)->gso_type = SKB_GSO_TCPV6;
-- 
2.1.0


From a21cbecb60330ffa00d84cccac654b03176fed7b Mon Sep 17 00:00:00 2001
From: Artem Germanov <agermanov@anchorfree.com>
Date: Wed, 7 Sep 2016 10:49:36 -0700
Subject: [PATCH 31/31] tcp: cwnd does not increase in TCP YeAH

[ Upstream commit db7196a0d0984b933ccf2cd6a60e26abf466e8a3 ]

Commit 76174004a0f19785a328f40388e87e982bbf69b9
(tcp: do not slow start when cwnd equals ssthresh )
introduced regression in TCP YeAH. Using 100ms delay 1% loss virtual
ethernet link kernel 4.2 shows bandwidth ~500KB/s for single TCP
connection and kernel 4.3 and above (including 4.8-rc4) shows bandwidth
~100KB/s.
   That is caused by stalled cwnd when cwnd equals ssthresh. This patch
fixes it by proper increasing cwnd in this case.

Signed-off-by: Artem Germanov <agermanov@anchorfree.com>
Acked-by: Dmitry Adamushko <d.adamushko@anchorfree.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/tcp_yeah.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/tcp_yeah.c b/net/ipv4/tcp_yeah.c
index 028eb04..9c5fc97 100644
--- a/net/ipv4/tcp_yeah.c
+++ b/net/ipv4/tcp_yeah.c
@@ -76,7 +76,7 @@ static void tcp_yeah_cong_avoid(struct sock *sk, u32 ack, u32 acked)
 	if (!tcp_is_cwnd_limited(sk))
 		return;
 
-	if (tp->snd_cwnd <= tp->snd_ssthresh)
+	if (tcp_in_slow_start(tp))
 		tcp_slow_start(tp, acked);
 
 	else if (!yeah->doing_reno_now) {
-- 
2.1.0


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2016-08-12  0:50 David Miller
@ 2016-08-12  7:37 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2016-08-12  7:37 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Aug 11, 2016 at 05:50:41PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 4.4.x, 4.6.x,
> and 4.7.x -stable, respectively.
> 
> Thanks!


Thanks so much for these, all now applied.

Note, this will be the last 4.6.x kernel released, so no need to do any
more patches for that release, unless something really serious comes
along.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2016-08-12  0:50 David Miller
  2016-08-12  7:37 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2016-08-12  0:50 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 112 bytes --]


Please queue up the following networking bug fixes for 4.4.x, 4.6.x,
and 4.7.x -stable, respectively.

Thanks!

[-- Attachment #2: net_44.mbox --]
[-- Type: Text/Plain, Size: 19689 bytes --]

>From a0d876bf464ea9abeb3f74aaf6737b6bcfd650c2 Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet@google.com>
Date: Sun, 10 Jul 2016 10:04:02 +0200
Subject: [PATCH 1/8] tcp: make challenge acks less predictable

[ Upstream commit 75ff39ccc1bd5d3c455b6822ab09e533c551f758 ]

Yue Cao claims that current host rate limiting of challenge ACKS
(RFC 5961) could leak enough information to allow a patient attacker
to hijack TCP sessions. He will soon provide details in an academic
paper.

This patch increases the default limit from 100 to 1000, and adds
some randomization so that the attacker can no longer hijack
sessions without spending a considerable amount of probes.

Based on initial analysis and patch from Linus.

Note that we also have per socket rate limiting, so it is tempting
to remove the host limit in the future.

v2: randomize the count of challenge acks per second, not the period.

Fixes: 282f23c6ee34 ("tcp: implement RFC 5961 3.2")
Reported-by: Yue Cao <ycao009@ucr.edu>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/tcp_input.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index d4c5115..05f10df 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -89,7 +89,7 @@ int sysctl_tcp_adv_win_scale __read_mostly = 1;
 EXPORT_SYMBOL(sysctl_tcp_adv_win_scale);
 
 /* rfc5961 challenge ack rate limiting */
-int sysctl_tcp_challenge_ack_limit = 100;
+int sysctl_tcp_challenge_ack_limit = 1000;
 
 int sysctl_tcp_stdurg __read_mostly;
 int sysctl_tcp_rfc1337 __read_mostly;
@@ -3427,7 +3427,7 @@ static void tcp_send_challenge_ack(struct sock *sk, const struct sk_buff *skb)
 	static u32 challenge_timestamp;
 	static unsigned int challenge_count;
 	struct tcp_sock *tp = tcp_sk(sk);
-	u32 now;
+	u32 count, now;
 
 	/* First check our per-socket dupack rate limit. */
 	if (tcp_oow_rate_limited(sock_net(sk), skb,
@@ -3435,13 +3435,18 @@ static void tcp_send_challenge_ack(struct sock *sk, const struct sk_buff *skb)
 				 &tp->last_oow_ack_time))
 		return;
 
-	/* Then check the check host-wide RFC 5961 rate limit. */
+	/* Then check host-wide RFC 5961 rate limit. */
 	now = jiffies / HZ;
 	if (now != challenge_timestamp) {
+		u32 half = (sysctl_tcp_challenge_ack_limit + 1) >> 1;
+
 		challenge_timestamp = now;
-		challenge_count = 0;
+		WRITE_ONCE(challenge_count, half +
+			   prandom_u32_max(sysctl_tcp_challenge_ack_limit));
 	}
-	if (++challenge_count <= sysctl_tcp_challenge_ack_limit) {
+	count = READ_ONCE(challenge_count);
+	if (count > 0) {
+		WRITE_ONCE(challenge_count, count - 1);
 		NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPCHALLENGEACK);
 		tcp_send_ack(sk);
 	}
-- 
2.1.0


>From 308b416124e42860984b23f37dac89b5e841a630 Mon Sep 17 00:00:00 2001
From: Jason Baron <jbaron@akamai.com>
Date: Thu, 14 Jul 2016 11:38:40 -0400
Subject: [PATCH 2/8] tcp: enable per-socket rate limiting of all 'challenge
 acks'

[ Upstream commit 083ae308280d13d187512b9babe3454342a7987e ]

The per-socket rate limit for 'challenge acks' was introduced in the
context of limiting ack loops:

commit f2b2c582e824 ("tcp: mitigate ACK loops for connections as tcp_sock")

And I think it can be extended to rate limit all 'challenge acks' on a
per-socket basis.

Since we have the global tcp_challenge_ack_limit, this patch allows for
tcp_challenge_ack_limit to be set to a large value and effectively rely on
the per-socket limit, or set tcp_challenge_ack_limit to a lower value and
still prevents a single connections from consuming the entire challenge ack
quota.

It further moves in the direction of eliminating the global limit at some
point, as Eric Dumazet has suggested. This a follow-up to:
Subject: tcp: make challenge acks less predictable

Cc: Eric Dumazet <edumazet@google.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Yue Cao <ycao009@ucr.edu>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/tcp_input.c | 39 ++++++++++++++++++++++-----------------
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 05f10df..12b98e2 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3390,6 +3390,23 @@ static int tcp_ack_update_window(struct sock *sk, const struct sk_buff *skb, u32
 	return flag;
 }
 
+static bool __tcp_oow_rate_limited(struct net *net, int mib_idx,
+				   u32 *last_oow_ack_time)
+{
+	if (*last_oow_ack_time) {
+		s32 elapsed = (s32)(tcp_time_stamp - *last_oow_ack_time);
+
+		if (0 <= elapsed && elapsed < sysctl_tcp_invalid_ratelimit) {
+			NET_INC_STATS_BH(net, mib_idx);
+			return true;	/* rate-limited: don't send yet! */
+		}
+	}
+
+	*last_oow_ack_time = tcp_time_stamp;
+
+	return false;	/* not rate-limited: go ahead, send dupack now! */
+}
+
 /* Return true if we're currently rate-limiting out-of-window ACKs and
  * thus shouldn't send a dupack right now. We rate-limit dupacks in
  * response to out-of-window SYNs or ACKs to mitigate ACK loops or DoS
@@ -3403,21 +3420,9 @@ bool tcp_oow_rate_limited(struct net *net, const struct sk_buff *skb,
 	/* Data packets without SYNs are not likely part of an ACK loop. */
 	if ((TCP_SKB_CB(skb)->seq != TCP_SKB_CB(skb)->end_seq) &&
 	    !tcp_hdr(skb)->syn)
-		goto not_rate_limited;
-
-	if (*last_oow_ack_time) {
-		s32 elapsed = (s32)(tcp_time_stamp - *last_oow_ack_time);
-
-		if (0 <= elapsed && elapsed < sysctl_tcp_invalid_ratelimit) {
-			NET_INC_STATS_BH(net, mib_idx);
-			return true;	/* rate-limited: don't send yet! */
-		}
-	}
-
-	*last_oow_ack_time = tcp_time_stamp;
+		return false;
 
-not_rate_limited:
-	return false;	/* not rate-limited: go ahead, send dupack now! */
+	return __tcp_oow_rate_limited(net, mib_idx, last_oow_ack_time);
 }
 
 /* RFC 5961 7 [ACK Throttling] */
@@ -3430,9 +3435,9 @@ static void tcp_send_challenge_ack(struct sock *sk, const struct sk_buff *skb)
 	u32 count, now;
 
 	/* First check our per-socket dupack rate limit. */
-	if (tcp_oow_rate_limited(sock_net(sk), skb,
-				 LINUX_MIB_TCPACKSKIPPEDCHALLENGE,
-				 &tp->last_oow_ack_time))
+	if (__tcp_oow_rate_limited(sock_net(sk),
+				   LINUX_MIB_TCPACKSKIPPEDCHALLENGE,
+				   &tp->last_oow_ack_time))
 		return;
 
 	/* Then check host-wide RFC 5961 rate limit. */
-- 
2.1.0


>From 9cee84ffee983b4a98838832cce4534a0b0f4b71 Mon Sep 17 00:00:00 2001
From: Julian Anastasov <ja@ssi.bg>
Date: Sun, 10 Jul 2016 21:11:55 +0300
Subject: [PATCH 3/8] ipv4: reject RTNH_F_DEAD and RTNH_F_LINKDOWN from user
 space

[ Upstream commit 80610229ef7b26615dbb6cb6e873709a60bacc9f ]

Vegard Nossum is reporting for a crash in fib_dump_info
when nh_dev = NULL and fib_nhs == 1:

Pid: 50, comm: netlink.exe Not tainted 4.7.0-rc5+
RIP: 0033:[<00000000602b3d18>]
RSP: 0000000062623890  EFLAGS: 00010202
RAX: 0000000000000000 RBX: 000000006261b800 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000024 RDI: 000000006245ba00
RBP: 00000000626238f0 R08: 000000000000029c R09: 0000000000000000
R10: 0000000062468038 R11: 000000006245ba00 R12: 000000006245ba00
R13: 00000000625f96c0 R14: 00000000601e16f0 R15: 0000000000000000
Kernel panic - not syncing: Kernel mode fault at addr 0x2e0, ip 0x602b3d18
CPU: 0 PID: 50 Comm: netlink.exe Not tainted 4.7.0-rc5+ #581
Stack:
 626238f0 960226a02 00000400 000000fe
 62623910 600afca7 62623970 62623a48
 62468038 00000018 00000000 00000000
Call Trace:
 [<602b3e93>] rtmsg_fib+0xd3/0x190
 [<602b6680>] fib_table_insert+0x260/0x500
 [<602b0e5d>] inet_rtm_newroute+0x4d/0x60
 [<60250def>] rtnetlink_rcv_msg+0x8f/0x270
 [<60267079>] netlink_rcv_skb+0xc9/0xe0
 [<60250d4b>] rtnetlink_rcv+0x3b/0x50
 [<60265400>] netlink_unicast+0x1a0/0x2c0
 [<60265e47>] netlink_sendmsg+0x3f7/0x470
 [<6021dc9a>] sock_sendmsg+0x3a/0x90
 [<6021e0d0>] ___sys_sendmsg+0x300/0x360
 [<6021fa64>] __sys_sendmsg+0x54/0xa0
 [<6021fac0>] SyS_sendmsg+0x10/0x20
 [<6001ea68>] handle_syscall+0x88/0x90
 [<600295fd>] userspace+0x3fd/0x500
 [<6001ac55>] fork_handler+0x85/0x90

$ addr2line -e vmlinux -i 0x602b3d18
include/linux/inetdevice.h:222
net/ipv4/fib_semantics.c:1264

Problem happens when RTNH_F_LINKDOWN is provided from user space
when creating routes that do not use the flag, catched with
netlink fuzzer.

Currently, the kernel allows user space to set both flags
to nh_flags and fib_flags but this is not intentional, the
assumption was that they are not set. Fix this by rejecting
both flags with EINVAL.

Reported-by: Vegard Nossum <vegard.nossum@oracle.com>
Fixes: 0eeb075fad73 ("net: ipv4 sysctl option to ignore routes when nexthop link is down")
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Cc: Andy Gospodarek <gospo@cumulusnetworks.com>
Cc: Dinesh Dutt <ddutt@cumulusnetworks.com>
Cc: Scott Feldman <sfeldma@gmail.com>
Reviewed-by: Andy Gospodarek <gospo@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/fib_semantics.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 2b68418..ffe95d9 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -479,6 +479,9 @@ static int fib_get_nhs(struct fib_info *fi, struct rtnexthop *rtnh,
 		if (!rtnh_ok(rtnh, remaining))
 			return -EINVAL;
 
+		if (rtnh->rtnh_flags & (RTNH_F_DEAD | RTNH_F_LINKDOWN))
+			return -EINVAL;
+
 		nexthop_nh->nh_flags =
 			(cfg->fc_flags & ~0xFF) | rtnh->rtnh_flags;
 		nexthop_nh->nh_oif = rtnh->rtnh_ifindex;
@@ -1003,6 +1006,9 @@ struct fib_info *fib_create_info(struct fib_config *cfg)
 	if (fib_props[cfg->fc_type].scope > cfg->fc_scope)
 		goto err_inval;
 
+	if (cfg->fc_flags & (RTNH_F_DEAD | RTNH_F_LINKDOWN))
+		goto err_inval;
+
 #ifdef CONFIG_IP_ROUTE_MULTIPATH
 	if (cfg->fc_mp) {
 		nhs = fib_count_nexthops(cfg->fc_mp, cfg->fc_mp_len);
-- 
2.1.0


>From d18b5b20c5dd68da8199dc859d711cd0af921057 Mon Sep 17 00:00:00 2001
From: Beniamino Galvani <bgalvani@redhat.com>
Date: Wed, 13 Jul 2016 18:25:08 +0200
Subject: [PATCH 4/8] bonding: set carrier off for devices created through
 netlink

[ Upstream commit 005db31d5f5f7c31cfdc43505d77eb3ca5cf8ec6 ]

Commit e826eafa65c6 ("bonding: Call netif_carrier_off after
register_netdevice") moved netif_carrier_off() from bond_init() to
bond_create(), but the latter is called only for initial default
devices and ones created through sysfs:

 $ modprobe bonding
 $ echo +bond1 > /sys/class/net/bonding_masters
 $ ip link add bond2 type bond
 $ grep "MII Status" /proc/net/bonding/*
 /proc/net/bonding/bond0:MII Status: down
 /proc/net/bonding/bond1:MII Status: down
 /proc/net/bonding/bond2:MII Status: up

Ensure that carrier is initially off also for devices created through
netlink.

Signed-off-by: Beniamino Galvani <bgalvani@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/bonding/bond_netlink.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/bonding/bond_netlink.c b/drivers/net/bonding/bond_netlink.c
index db760e8..b8df0f5 100644
--- a/drivers/net/bonding/bond_netlink.c
+++ b/drivers/net/bonding/bond_netlink.c
@@ -446,7 +446,11 @@ static int bond_newlink(struct net *src_net, struct net_device *bond_dev,
 	if (err < 0)
 		return err;
 
-	return register_netdevice(bond_dev);
+	err = register_netdevice(bond_dev);
+
+	netif_carrier_off(bond_dev);
+
+	return err;
 }
 
 static size_t bond_get_size(const struct net_device *bond_dev)
-- 
2.1.0


>From a13baae73d6c93fd4bfc2802e7494a8a21da92f2 Mon Sep 17 00:00:00 2001
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri, 15 Jul 2016 15:42:52 -0700
Subject: [PATCH 5/8] net: bgmac: Fix infinite loop in bgmac_dma_tx_add()

[ Upstream commit e86663c475d384ab5f46cb5637e9b7ad08c5c505 ]

Nothing is decrementing the index "i" while we are cleaning up the
fragments we could not successful transmit.

Fixes: 9cde94506eacf ("bgmac: implement scatter/gather support")
Reported-by: coverity (CID 1352048)
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/broadcom/bgmac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index 28f7610..c32f5d3 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -219,7 +219,7 @@ err_dma:
 	dma_unmap_single(dma_dev, slot->dma_addr, skb_headlen(skb),
 			 DMA_TO_DEVICE);
 
-	while (i > 0) {
+	while (i-- > 0) {
 		int index = (ring->end + i) % BGMAC_TX_RING_SLOTS;
 		struct bgmac_slot_info *slot = &ring->slots[index];
 		u32 ctl1 = le32_to_cpu(ring->cpu_base[index].ctl1);
-- 
2.1.0


>From a0a4d274c777f91ff92c0b5f509728fc71117158 Mon Sep 17 00:00:00 2001
From: Vegard Nossum <vegard.nossum@oracle.com>
Date: Sat, 23 Jul 2016 07:43:50 +0200
Subject: [PATCH 6/8] net/irda: fix NULL pointer dereference on memory
 allocation failure

[ Upstream commit d3e6952cfb7ba5f4bfa29d4803ba91f96ce1204d ]

I ran into this:

    kasan: CONFIG_KASAN_INLINE enabled
    kasan: GPF could be caused by NULL-ptr deref or user memory access
    general protection fault: 0000 [#1] PREEMPT SMP KASAN
    CPU: 2 PID: 2012 Comm: trinity-c3 Not tainted 4.7.0-rc7+ #19
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    task: ffff8800b745f2c0 ti: ffff880111740000 task.ti: ffff880111740000
    RIP: 0010:[<ffffffff82bbf066>]  [<ffffffff82bbf066>] irttp_connect_request+0x36/0x710
    RSP: 0018:ffff880111747bb8  EFLAGS: 00010286
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000069dd8358
    RDX: 0000000000000009 RSI: 0000000000000027 RDI: 0000000000000048
    RBP: ffff880111747c00 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000069dd8358 R11: 1ffffffff0759723 R12: 0000000000000000
    R13: ffff88011a7e4780 R14: 0000000000000027 R15: 0000000000000000
    FS:  00007fc738404700(0000) GS:ffff88011af00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fc737fdfb10 CR3: 0000000118087000 CR4: 00000000000006e0
    Stack:
     0000000000000200 ffff880111747bd8 ffffffff810ee611 ffff880119f1f220
     ffff880119f1f4f8 ffff880119f1f4f0 ffff88011a7e4780 ffff880119f1f232
     ffff880119f1f220 ffff880111747d58 ffffffff82bca542 0000000000000000
    Call Trace:
     [<ffffffff82bca542>] irda_connect+0x562/0x1190
     [<ffffffff825ae582>] SYSC_connect+0x202/0x2a0
     [<ffffffff825b4489>] SyS_connect+0x9/0x10
     [<ffffffff8100334c>] do_syscall_64+0x19c/0x410
     [<ffffffff83295ca5>] entry_SYSCALL64_slow_path+0x25/0x25
    Code: 41 89 ca 48 89 e5 41 57 41 56 41 55 41 54 41 89 d7 53 48 89 fb 48 83 c7 48 48 89 fa 41 89 f6 48 c1 ea 03 48 83 ec 20 4c 8b 65 10 <0f> b6 04 02 84 c0 74 08 84 c0 0f 8e 4c 04 00 00 80 7b 48 00 74
    RIP  [<ffffffff82bbf066>] irttp_connect_request+0x36/0x710
     RSP <ffff880111747bb8>
    ---[ end trace 4cda2588bc055b30 ]---

The problem is that irda_open_tsap() can fail and leave self->tsap = NULL,
and then irttp_connect_request() almost immediately dereferences it.

Cc: stable@vger.kernel.org
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/irda/af_irda.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/net/irda/af_irda.c b/net/irda/af_irda.c
index 923abd6..8d2f7c9 100644
--- a/net/irda/af_irda.c
+++ b/net/irda/af_irda.c
@@ -1024,8 +1024,11 @@ static int irda_connect(struct socket *sock, struct sockaddr *uaddr,
 	}
 
 	/* Check if we have opened a local TSAP */
-	if (!self->tsap)
-		irda_open_tsap(self, LSAP_ANY, addr->sir_name);
+	if (!self->tsap) {
+		err = irda_open_tsap(self, LSAP_ANY, addr->sir_name);
+		if (err)
+			goto out;
+	}
 
 	/* Move to connecting socket, start sending Connect Requests */
 	sock->state = SS_CONNECTING;
-- 
2.1.0


>From e51820b246d30c8b4a29910fb9474a265d8fd75c Mon Sep 17 00:00:00 2001
From: Manish Chopra <manish.chopra@qlogic.com>
Date: Mon, 25 Jul 2016 19:07:46 +0300
Subject: [PATCH 7/8] qed: Fix setting/clearing bit in completion bitmap

[ Upstream commit 59d3f1ceb69b54569685d0c34dff16a1e0816b19 ]

Slowpath completion handling is incorrectly changing
SPQ_RING_SIZE bits instead of a single one.

Fixes: 76a9a3642a0b ("qed: fix handling of concurrent ramrods")
Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/qlogic/qed/qed_spq.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_spq.c b/drivers/net/ethernet/qlogic/qed/qed_spq.c
index 3dd548a..40365cb 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_spq.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_spq.c
@@ -794,13 +794,12 @@ int qed_spq_completion(struct qed_hwfn *p_hwfn,
 			 * in a bitmap and increasing the chain consumer only
 			 * for the first successive completed entries.
 			 */
-			bitmap_set(p_spq->p_comp_bitmap, pos, SPQ_RING_SIZE);
+			__set_bit(pos, p_spq->p_comp_bitmap);
 
 			while (test_bit(p_spq->comp_bitmap_idx,
 					p_spq->p_comp_bitmap)) {
-				bitmap_clear(p_spq->p_comp_bitmap,
-					     p_spq->comp_bitmap_idx,
-					     SPQ_RING_SIZE);
+				__clear_bit(p_spq->comp_bitmap_idx,
+					    p_spq->p_comp_bitmap);
 				p_spq->comp_bitmap_idx++;
 				qed_chain_return_produced(&p_spq->chain);
 			}
-- 
2.1.0


>From 2471ebe21d69b9dcd981532d0bfddcd1197c210c Mon Sep 17 00:00:00 2001
From: Soheil Hassas Yeganeh <soheil@google.com>
Date: Fri, 29 Jul 2016 09:34:02 -0400
Subject: [PATCH 8/8] tcp: consider recv buf for the initial window scale

[ Upstream commit f626300a3e776ccc9671b0dd94698fb3aa315966 ]

tcp_select_initial_window() intends to advertise a window
scaling for the maximum possible window size. To do so,
it considers the maximum of net.ipv4.tcp_rmem[2] and
net.core.rmem_max as the only possible upper-bounds.
However, users with CAP_NET_ADMIN can use SO_RCVBUFFORCE
to set the socket's receive buffer size to values
larger than net.ipv4.tcp_rmem[2] and net.core.rmem_max.
Thus, SO_RCVBUFFORCE is effectively ignored by
tcp_select_initial_window().

To fix this, consider the maximum of net.ipv4.tcp_rmem[2],
net.core.rmem_max and socket's initial buffer space.

Fixes: b0573dea1fb3 ("[NET]: Introduce SO_{SND,RCV}BUFFORCE socket options")
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Suggested-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/tcp_output.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 7c9883a..660c967 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -239,7 +239,8 @@ void tcp_select_initial_window(int __space, __u32 mss,
 		/* Set window scaling on max possible window
 		 * See RFC1323 for an explanation of the limit to 14
 		 */
-		space = max_t(u32, sysctl_tcp_rmem[2], sysctl_rmem_max);
+		space = max_t(u32, space, sysctl_tcp_rmem[2]);
+		space = max_t(u32, space, sysctl_rmem_max);
 		space = min_t(u32, space, *window_clamp);
 		while (space > 65535 && (*rcv_wscale) < 14) {
 			space >>= 1;
-- 
2.1.0


[-- Attachment #3: net_46.mbox --]
[-- Type: Text/Plain, Size: 27698 bytes --]

>From 9509f0f1ebffa31c3864d8ab5c3fd52ee6614a99 Mon Sep 17 00:00:00 2001
From: WANG Cong <xiyou.wangcong@gmail.com>
Date: Tue, 5 Jul 2016 22:12:36 -0700
Subject: [PATCH 01/13] ppp: defer netns reference release for ppp channel

[ Upstream commit 205e1e255c479f3fd77446415706463b282f94e4 ]

Matt reported that we have a NULL pointer dereference
in ppp_pernet() from ppp_connect_channel(),
i.e. pch->chan_net is NULL.

This is due to that a parallel ppp_unregister_channel()
could happen while we are in ppp_connect_channel(), during
which pch->chan_net set to NULL. Since we need a reference
to net per channel, it makes sense to sync the refcnt
with the life time of the channel, therefore we should
release this reference when we destroy it.

Fixes: 1f461dcdd296 ("ppp: take reference on channels netns")
Reported-by: Matt Bennett <Matt.Bennett@alliedtelesis.co.nz>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linux-ppp@vger.kernel.org
Cc: Guillaume Nault <g.nault@alphalink.fr>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ppp/ppp_generic.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index f572b31..9ab88e1 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -2404,8 +2404,6 @@ ppp_unregister_channel(struct ppp_channel *chan)
 	spin_lock_bh(&pn->all_channels_lock);
 	list_del(&pch->list);
 	spin_unlock_bh(&pn->all_channels_lock);
-	put_net(pch->chan_net);
-	pch->chan_net = NULL;
 
 	pch->file.dead = 1;
 	wake_up_interruptible(&pch->file.rwait);
@@ -2999,6 +2997,9 @@ ppp_disconnect_channel(struct channel *pch)
  */
 static void ppp_destroy_channel(struct channel *pch)
 {
+	put_net(pch->chan_net);
+	pch->chan_net = NULL;
+
 	atomic_dec(&channel_count);
 
 	if (!pch->file.dead) {
-- 
2.1.0


>From fe76d1a9b2674634d17553f8eead09c6a7f34d18 Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet@google.com>
Date: Sun, 10 Jul 2016 10:04:02 +0200
Subject: [PATCH 02/13] tcp: make challenge acks less predictable

[ Upstream commit 75ff39ccc1bd5d3c455b6822ab09e533c551f758 ]

Yue Cao claims that current host rate limiting of challenge ACKS
(RFC 5961) could leak enough information to allow a patient attacker
to hijack TCP sessions. He will soon provide details in an academic
paper.

This patch increases the default limit from 100 to 1000, and adds
some randomization so that the attacker can no longer hijack
sessions without spending a considerable amount of probes.

Based on initial analysis and patch from Linus.

Note that we also have per socket rate limiting, so it is tempting
to remove the host limit in the future.

v2: randomize the count of challenge acks per second, not the period.

Fixes: 282f23c6ee34 ("tcp: implement RFC 5961 3.2")
Reported-by: Yue Cao <ycao009@ucr.edu>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/tcp_input.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index c124c3c..593b141 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -87,7 +87,7 @@ int sysctl_tcp_adv_win_scale __read_mostly = 1;
 EXPORT_SYMBOL(sysctl_tcp_adv_win_scale);
 
 /* rfc5961 challenge ack rate limiting */
-int sysctl_tcp_challenge_ack_limit = 100;
+int sysctl_tcp_challenge_ack_limit = 1000;
 
 int sysctl_tcp_stdurg __read_mostly;
 int sysctl_tcp_rfc1337 __read_mostly;
@@ -3460,7 +3460,7 @@ static void tcp_send_challenge_ack(struct sock *sk, const struct sk_buff *skb)
 	static u32 challenge_timestamp;
 	static unsigned int challenge_count;
 	struct tcp_sock *tp = tcp_sk(sk);
-	u32 now;
+	u32 count, now;
 
 	/* First check our per-socket dupack rate limit. */
 	if (tcp_oow_rate_limited(sock_net(sk), skb,
@@ -3468,13 +3468,18 @@ static void tcp_send_challenge_ack(struct sock *sk, const struct sk_buff *skb)
 				 &tp->last_oow_ack_time))
 		return;
 
-	/* Then check the check host-wide RFC 5961 rate limit. */
+	/* Then check host-wide RFC 5961 rate limit. */
 	now = jiffies / HZ;
 	if (now != challenge_timestamp) {
+		u32 half = (sysctl_tcp_challenge_ack_limit + 1) >> 1;
+
 		challenge_timestamp = now;
-		challenge_count = 0;
+		WRITE_ONCE(challenge_count, half +
+			   prandom_u32_max(sysctl_tcp_challenge_ack_limit));
 	}
-	if (++challenge_count <= sysctl_tcp_challenge_ack_limit) {
+	count = READ_ONCE(challenge_count);
+	if (count > 0) {
+		WRITE_ONCE(challenge_count, count - 1);
 		NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPCHALLENGEACK);
 		tcp_send_ack(sk);
 	}
-- 
2.1.0


>From 26032523d8333c6ca39897f1c1eac4440443e9f6 Mon Sep 17 00:00:00 2001
From: Jason Baron <jbaron@akamai.com>
Date: Thu, 14 Jul 2016 11:38:40 -0400
Subject: [PATCH 03/13] tcp: enable per-socket rate limiting of all 'challenge
 acks'

[ Upstream commit 083ae308280d13d187512b9babe3454342a7987e ]

The per-socket rate limit for 'challenge acks' was introduced in the
context of limiting ack loops:

commit f2b2c582e824 ("tcp: mitigate ACK loops for connections as tcp_sock")

And I think it can be extended to rate limit all 'challenge acks' on a
per-socket basis.

Since we have the global tcp_challenge_ack_limit, this patch allows for
tcp_challenge_ack_limit to be set to a large value and effectively rely on
the per-socket limit, or set tcp_challenge_ack_limit to a lower value and
still prevents a single connections from consuming the entire challenge ack
quota.

It further moves in the direction of eliminating the global limit at some
point, as Eric Dumazet has suggested. This a follow-up to:
Subject: tcp: make challenge acks less predictable

Cc: Eric Dumazet <edumazet@google.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Yue Cao <ycao009@ucr.edu>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/tcp_input.c | 39 ++++++++++++++++++++++-----------------
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 593b141..e2e7884 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3423,6 +3423,23 @@ static int tcp_ack_update_window(struct sock *sk, const struct sk_buff *skb, u32
 	return flag;
 }
 
+static bool __tcp_oow_rate_limited(struct net *net, int mib_idx,
+				   u32 *last_oow_ack_time)
+{
+	if (*last_oow_ack_time) {
+		s32 elapsed = (s32)(tcp_time_stamp - *last_oow_ack_time);
+
+		if (0 <= elapsed && elapsed < sysctl_tcp_invalid_ratelimit) {
+			NET_INC_STATS_BH(net, mib_idx);
+			return true;	/* rate-limited: don't send yet! */
+		}
+	}
+
+	*last_oow_ack_time = tcp_time_stamp;
+
+	return false;	/* not rate-limited: go ahead, send dupack now! */
+}
+
 /* Return true if we're currently rate-limiting out-of-window ACKs and
  * thus shouldn't send a dupack right now. We rate-limit dupacks in
  * response to out-of-window SYNs or ACKs to mitigate ACK loops or DoS
@@ -3436,21 +3453,9 @@ bool tcp_oow_rate_limited(struct net *net, const struct sk_buff *skb,
 	/* Data packets without SYNs are not likely part of an ACK loop. */
 	if ((TCP_SKB_CB(skb)->seq != TCP_SKB_CB(skb)->end_seq) &&
 	    !tcp_hdr(skb)->syn)
-		goto not_rate_limited;
-
-	if (*last_oow_ack_time) {
-		s32 elapsed = (s32)(tcp_time_stamp - *last_oow_ack_time);
-
-		if (0 <= elapsed && elapsed < sysctl_tcp_invalid_ratelimit) {
-			NET_INC_STATS_BH(net, mib_idx);
-			return true;	/* rate-limited: don't send yet! */
-		}
-	}
-
-	*last_oow_ack_time = tcp_time_stamp;
+		return false;
 
-not_rate_limited:
-	return false;	/* not rate-limited: go ahead, send dupack now! */
+	return __tcp_oow_rate_limited(net, mib_idx, last_oow_ack_time);
 }
 
 /* RFC 5961 7 [ACK Throttling] */
@@ -3463,9 +3468,9 @@ static void tcp_send_challenge_ack(struct sock *sk, const struct sk_buff *skb)
 	u32 count, now;
 
 	/* First check our per-socket dupack rate limit. */
-	if (tcp_oow_rate_limited(sock_net(sk), skb,
-				 LINUX_MIB_TCPACKSKIPPEDCHALLENGE,
-				 &tp->last_oow_ack_time))
+	if (__tcp_oow_rate_limited(sock_net(sk),
+				   LINUX_MIB_TCPACKSKIPPEDCHALLENGE,
+				   &tp->last_oow_ack_time))
 		return;
 
 	/* Then check host-wide RFC 5961 rate limit. */
-- 
2.1.0


>From 7f39c9a67c446fc870f511b1f2774f54a1b97ac1 Mon Sep 17 00:00:00 2001
From: Beniamino Galvani <bgalvani@redhat.com>
Date: Wed, 13 Jul 2016 18:25:08 +0200
Subject: [PATCH 04/13] bonding: set carrier off for devices created through
 netlink

[ Upstream commit 005db31d5f5f7c31cfdc43505d77eb3ca5cf8ec6 ]

Commit e826eafa65c6 ("bonding: Call netif_carrier_off after
register_netdevice") moved netif_carrier_off() from bond_init() to
bond_create(), but the latter is called only for initial default
devices and ones created through sysfs:

 $ modprobe bonding
 $ echo +bond1 > /sys/class/net/bonding_masters
 $ ip link add bond2 type bond
 $ grep "MII Status" /proc/net/bonding/*
 /proc/net/bonding/bond0:MII Status: down
 /proc/net/bonding/bond1:MII Status: down
 /proc/net/bonding/bond2:MII Status: up

Ensure that carrier is initially off also for devices created through
netlink.

Signed-off-by: Beniamino Galvani <bgalvani@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/bonding/bond_netlink.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/bonding/bond_netlink.c b/drivers/net/bonding/bond_netlink.c
index db760e8..b8df0f5 100644
--- a/drivers/net/bonding/bond_netlink.c
+++ b/drivers/net/bonding/bond_netlink.c
@@ -446,7 +446,11 @@ static int bond_newlink(struct net *src_net, struct net_device *bond_dev,
 	if (err < 0)
 		return err;
 
-	return register_netdevice(bond_dev);
+	err = register_netdevice(bond_dev);
+
+	netif_carrier_off(bond_dev);
+
+	return err;
 }
 
 static size_t bond_get_size(const struct net_device *bond_dev)
-- 
2.1.0


>From a2de40b1b24b9b34cb66ccadd3ed2bb3a7ba3e33 Mon Sep 17 00:00:00 2001
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri, 15 Jul 2016 15:42:52 -0700
Subject: [PATCH 05/13] net: bgmac: Fix infinite loop in bgmac_dma_tx_add()

[ Upstream commit e86663c475d384ab5f46cb5637e9b7ad08c5c505 ]

Nothing is decrementing the index "i" while we are cleaning up the
fragments we could not successful transmit.

Fixes: 9cde94506eacf ("bgmac: implement scatter/gather support")
Reported-by: coverity (CID 1352048)
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/broadcom/bgmac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index 38db2e4..832401b 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -231,7 +231,7 @@ err_dma:
 	dma_unmap_single(dma_dev, slot->dma_addr, skb_headlen(skb),
 			 DMA_TO_DEVICE);
 
-	while (i > 0) {
+	while (i-- > 0) {
 		int index = (ring->end + i) % BGMAC_TX_RING_SLOTS;
 		struct bgmac_slot_info *slot = &ring->slots[index];
 		u32 ctl1 = le32_to_cpu(ring->cpu_base[index].ctl1);
-- 
2.1.0


>From b8564b8f1c7b994d1f708237d24ecee97400cab9 Mon Sep 17 00:00:00 2001
From: Paolo Abeni <pabeni@redhat.com>
Date: Thu, 14 Jul 2016 18:00:10 +0200
Subject: [PATCH 06/13] vlan: use a valid default mtu value for vlan over
 macsec

[ Upstream commit 18d3df3eab23796d7f852f9c6bb60962b8372ced ]

macsec can't cope with mtu frames which need vlan tag insertion, and
vlan device set the default mtu equal to the underlying dev's one.
By default vlan over macsec devices use invalid mtu, dropping
all the large packets.
This patch adds a netif helper to check if an upper vlan device
needs mtu reduction. The helper is used during vlan devices
initialization to set a valid default and during mtu updating to
forbid invalid, too bit, mtu values.
The helper currently only check if the lower dev is a macsec device,
if we get more users, we need to update only the helper (possibly
reserving an additional IFF bit).

Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 include/linux/netdevice.h |  7 +++++++
 net/8021q/vlan_dev.c      | 10 ++++++----
 net/8021q/vlan_netlink.c  |  7 +++++--
 3 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 78181a8..54355a7 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -4156,6 +4156,13 @@ static inline void netif_keep_dst(struct net_device *dev)
 	dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE | IFF_XMIT_DST_RELEASE_PERM);
 }
 
+/* return true if dev can't cope with mtu frames that need vlan tag insertion */
+static inline bool netif_reduces_vlan_mtu(struct net_device *dev)
+{
+	/* TODO: reserve and use an additional IFF bit, if we get more users */
+	return dev->priv_flags & IFF_MACSEC;
+}
+
 extern struct pernet_operations __net_initdata loopback_net_ops;
 
 /* Logging, debugging and troubleshooting/diagnostic helpers. */
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index e7e6257..3a573a2 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -146,10 +146,12 @@ static netdev_tx_t vlan_dev_hard_start_xmit(struct sk_buff *skb,
 
 static int vlan_dev_change_mtu(struct net_device *dev, int new_mtu)
 {
-	/* TODO: gotta make sure the underlying layer can handle it,
-	 * maybe an IFF_VLAN_CAPABLE flag for devices?
-	 */
-	if (vlan_dev_priv(dev)->real_dev->mtu < new_mtu)
+	struct net_device *real_dev = vlan_dev_priv(dev)->real_dev;
+	unsigned int max_mtu = real_dev->mtu;
+
+	if (netif_reduces_vlan_mtu(real_dev))
+		max_mtu -= VLAN_HLEN;
+	if (max_mtu < new_mtu)
 		return -ERANGE;
 
 	dev->mtu = new_mtu;
diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c
index c92b52f..1270207 100644
--- a/net/8021q/vlan_netlink.c
+++ b/net/8021q/vlan_netlink.c
@@ -118,6 +118,7 @@ static int vlan_newlink(struct net *src_net, struct net_device *dev,
 {
 	struct vlan_dev_priv *vlan = vlan_dev_priv(dev);
 	struct net_device *real_dev;
+	unsigned int max_mtu;
 	__be16 proto;
 	int err;
 
@@ -144,9 +145,11 @@ static int vlan_newlink(struct net *src_net, struct net_device *dev,
 	if (err < 0)
 		return err;
 
+	max_mtu = netif_reduces_vlan_mtu(real_dev) ? real_dev->mtu - VLAN_HLEN :
+						     real_dev->mtu;
 	if (!tb[IFLA_MTU])
-		dev->mtu = real_dev->mtu;
-	else if (dev->mtu > real_dev->mtu)
+		dev->mtu = max_mtu;
+	else if (dev->mtu > max_mtu)
 		return -EINVAL;
 
 	err = vlan_changelink(dev, tb, data);
-- 
2.1.0


>From ff7b8b968430b3dc6aba39c0e38bd2a8e7353fba Mon Sep 17 00:00:00 2001
From: Ido Schimmel <idosch@mellanox.com>
Date: Fri, 22 Jul 2016 14:56:20 +0300
Subject: [PATCH 08/13] bridge: Fix incorrect re-injection of LLDP packets

[ Upstream commit baedbe55884c003819f5c8c063ec3d2569414296 ]

Commit 8626c56c8279 ("bridge: fix potential use-after-free when hook
returns QUEUE or STOLEN verdict") caused LLDP packets arriving through a
bridge port to be re-injected to the Rx path with skb->dev set to the
bridge device, but this breaks the lldpad daemon.

The lldpad daemon opens a packet socket with protocol set to ETH_P_LLDP
for any valid device on the system, which doesn't not include soft
devices such as bridge and VLAN.

Since packet sockets (ptype_base) are processed in the Rx path after the
Rx handler, LLDP packets with skb->dev set to the bridge device never
reach the lldpad daemon.

Fix this by making the bridge's Rx handler re-inject LLDP packets with
RX_HANDLER_PASS, which effectively restores the behaviour prior to the
mentioned commit.

This means netfilter will never receive LLDP packets coming through a
bridge port, as I don't see a way in which we can have okfn() consume
the packet without breaking existing behaviour. I've already carried out
a similar fix for STP packets in commit 56fae404fb2c ("bridge: Fix
incorrect re-injection of STP packets").

Fixes: 8626c56c8279 ("bridge: fix potential use-after-free when hook returns QUEUE or STOLEN verdict")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Cc: Florian Westphal <fw@strlen.de>
Cc: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/bridge/br_input.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 1607977..b32f5a4 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -213,6 +213,16 @@ drop:
 }
 EXPORT_SYMBOL_GPL(br_handle_frame_finish);
 
+static void __br_handle_local_finish(struct sk_buff *skb)
+{
+	struct net_bridge_port *p = br_port_get_rcu(skb->dev);
+	u16 vid = 0;
+
+	/* check if vlan is allowed, to avoid spoofing */
+	if (p->flags & BR_LEARNING && br_should_learn(p, skb, &vid))
+		br_fdb_update(p->br, p, eth_hdr(skb)->h_source, vid, false);
+}
+
 /* note: already called with rcu_read_lock */
 static int br_handle_local_finish(struct net *net, struct sock *sk, struct sk_buff *skb)
 {
@@ -279,6 +289,14 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
 		case 0x01:	/* IEEE MAC (Pause) */
 			goto drop;
 
+		case 0x0E:	/* 802.1AB LLDP */
+			fwd_mask |= p->br->group_fwd_mask;
+			if (fwd_mask & (1u << dest[5]))
+				goto forward;
+			*pskb = skb;
+			__br_handle_local_finish(skb);
+			return RX_HANDLER_PASS;
+
 		default:
 			/* Allow selective forwarding for most other protocols */
 			fwd_mask |= p->br->group_fwd_mask;
-- 
2.1.0


>From d4282053091319b7eef8b622bea72df7ea1457dd Mon Sep 17 00:00:00 2001
From: Mike Manning <mmanning@brocade.com>
Date: Fri, 22 Jul 2016 18:32:11 +0100
Subject: [PATCH 09/13] net: ipv6: Always leave anycast and multicast groups on
 link down

[ Upstream commit ea06f7176413e2538d13bb85b65387d0917943d9 ]

Default kernel behavior is to delete IPv6 addresses on link
down, which entails deletion of the multicast and the
subnet-router anycast addresses. These deletions do not
happen with sysctl setting to keep global IPv6 addresses on
link down, so every link down/up causes an increment of the
anycast and multicast refcounts. These bogus refcounts may
stop these addrs from being removed on subsequent calls to
delete them. The solution is to leave the groups for the
multicast and subnet anycast on link down for the callflow
when global IPv6 addresses are kept.

Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
Signed-off-by: Mike Manning <mmanning@brocade.com>
Acked-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv6/addrconf.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 8ec4b30..e3fc0cd 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3563,6 +3563,10 @@ restart:
 		if (state != INET6_IFADDR_STATE_DEAD) {
 			__ipv6_ifa_notify(RTM_DELADDR, ifa);
 			inet6addr_notifier_call_chain(NETDEV_DOWN, ifa);
+		} else {
+			if (idev->cnf.forwarding)
+				addrconf_leave_anycast(ifa);
+			addrconf_leave_solict(ifa->idev, &ifa->addr);
 		}
 
 		write_lock_bh(&idev->lock);
-- 
2.1.0


>From e1d101289eddb944d1b55d05443f26ca7df1e5fa Mon Sep 17 00:00:00 2001
From: Vegard Nossum <vegard.nossum@oracle.com>
Date: Sat, 23 Jul 2016 07:43:50 +0200
Subject: [PATCH 10/13] net/irda: fix NULL pointer dereference on memory
 allocation failure

[ Upstream commit d3e6952cfb7ba5f4bfa29d4803ba91f96ce1204d ]

I ran into this:

    kasan: CONFIG_KASAN_INLINE enabled
    kasan: GPF could be caused by NULL-ptr deref or user memory access
    general protection fault: 0000 [#1] PREEMPT SMP KASAN
    CPU: 2 PID: 2012 Comm: trinity-c3 Not tainted 4.7.0-rc7+ #19
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    task: ffff8800b745f2c0 ti: ffff880111740000 task.ti: ffff880111740000
    RIP: 0010:[<ffffffff82bbf066>]  [<ffffffff82bbf066>] irttp_connect_request+0x36/0x710
    RSP: 0018:ffff880111747bb8  EFLAGS: 00010286
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000069dd8358
    RDX: 0000000000000009 RSI: 0000000000000027 RDI: 0000000000000048
    RBP: ffff880111747c00 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000069dd8358 R11: 1ffffffff0759723 R12: 0000000000000000
    R13: ffff88011a7e4780 R14: 0000000000000027 R15: 0000000000000000
    FS:  00007fc738404700(0000) GS:ffff88011af00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fc737fdfb10 CR3: 0000000118087000 CR4: 00000000000006e0
    Stack:
     0000000000000200 ffff880111747bd8 ffffffff810ee611 ffff880119f1f220
     ffff880119f1f4f8 ffff880119f1f4f0 ffff88011a7e4780 ffff880119f1f232
     ffff880119f1f220 ffff880111747d58 ffffffff82bca542 0000000000000000
    Call Trace:
     [<ffffffff82bca542>] irda_connect+0x562/0x1190
     [<ffffffff825ae582>] SYSC_connect+0x202/0x2a0
     [<ffffffff825b4489>] SyS_connect+0x9/0x10
     [<ffffffff8100334c>] do_syscall_64+0x19c/0x410
     [<ffffffff83295ca5>] entry_SYSCALL64_slow_path+0x25/0x25
    Code: 41 89 ca 48 89 e5 41 57 41 56 41 55 41 54 41 89 d7 53 48 89 fb 48 83 c7 48 48 89 fa 41 89 f6 48 c1 ea 03 48 83 ec 20 4c 8b 65 10 <0f> b6 04 02 84 c0 74 08 84 c0 0f 8e 4c 04 00 00 80 7b 48 00 74
    RIP  [<ffffffff82bbf066>] irttp_connect_request+0x36/0x710
     RSP <ffff880111747bb8>
    ---[ end trace 4cda2588bc055b30 ]---

The problem is that irda_open_tsap() can fail and leave self->tsap = NULL,
and then irttp_connect_request() almost immediately dereferences it.

Cc: stable@vger.kernel.org
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/irda/af_irda.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/net/irda/af_irda.c b/net/irda/af_irda.c
index 923abd6..8d2f7c9 100644
--- a/net/irda/af_irda.c
+++ b/net/irda/af_irda.c
@@ -1024,8 +1024,11 @@ static int irda_connect(struct socket *sock, struct sockaddr *uaddr,
 	}
 
 	/* Check if we have opened a local TSAP */
-	if (!self->tsap)
-		irda_open_tsap(self, LSAP_ANY, addr->sir_name);
+	if (!self->tsap) {
+		err = irda_open_tsap(self, LSAP_ANY, addr->sir_name);
+		if (err)
+			goto out;
+	}
 
 	/* Move to connecting socket, start sending Connect Requests */
 	sock->state = SS_CONNECTING;
-- 
2.1.0


>From 815358664017fe5df6143e3e6431e7cb81776e08 Mon Sep 17 00:00:00 2001
From: Manish Chopra <manish.chopra@qlogic.com>
Date: Mon, 25 Jul 2016 19:07:46 +0300
Subject: [PATCH 11/13] qed: Fix setting/clearing bit in completion bitmap

[ Upstream commit 59d3f1ceb69b54569685d0c34dff16a1e0816b19 ]

Slowpath completion handling is incorrectly changing
SPQ_RING_SIZE bits instead of a single one.

Fixes: 76a9a3642a0b ("qed: fix handling of concurrent ramrods")
Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/qlogic/qed/qed_spq.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_spq.c b/drivers/net/ethernet/qlogic/qed/qed_spq.c
index 89469d5..40e6f6c 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_spq.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_spq.c
@@ -791,13 +791,12 @@ int qed_spq_completion(struct qed_hwfn *p_hwfn,
 			 * in a bitmap and increasing the chain consumer only
 			 * for the first successive completed entries.
 			 */
-			bitmap_set(p_spq->p_comp_bitmap, pos, SPQ_RING_SIZE);
+			__set_bit(pos, p_spq->p_comp_bitmap);
 
 			while (test_bit(p_spq->comp_bitmap_idx,
 					p_spq->p_comp_bitmap)) {
-				bitmap_clear(p_spq->p_comp_bitmap,
-					     p_spq->comp_bitmap_idx,
-					     SPQ_RING_SIZE);
+				__clear_bit(p_spq->comp_bitmap_idx,
+					    p_spq->p_comp_bitmap);
 				p_spq->comp_bitmap_idx++;
 				qed_chain_return_produced(&p_spq->chain);
 			}
-- 
2.1.0


>From 7c8329ff8570b38edcd61066b2032cf4e4edab24 Mon Sep 17 00:00:00 2001
From: Beniamino Galvani <bgalvani@redhat.com>
Date: Tue, 26 Jul 2016 12:24:53 +0200
Subject: [PATCH 12/13] macsec: ensure rx_sa is set when validation is disabled

[ Upstream commit e3a3b626010a14fe067f163c2c43409d5afcd2a9 ]

macsec_decrypt() is not called when validation is disabled and so
macsec_skb_cb(skb)->rx_sa is not set; but it is used later in
macsec_post_decrypt(), ensure that it's always initialized.

Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
Signed-off-by: Beniamino Galvani <bgalvani@redhat.com>
Acked-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/macsec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index 8f3c55d..f58858b 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -914,7 +914,6 @@ static struct sk_buff *macsec_decrypt(struct sk_buff *skb,
 	}
 
 	macsec_skb_cb(skb)->req = req;
-	macsec_skb_cb(skb)->rx_sa = rx_sa;
 	skb->dev = dev;
 	aead_request_set_callback(req, 0, macsec_decrypt_done, skb);
 
@@ -1141,6 +1140,8 @@ static rx_handler_result_t macsec_handle_frame(struct sk_buff **pskb)
 		}
 	}
 
+	macsec_skb_cb(skb)->rx_sa = rx_sa;
+
 	/* Disabled && !changed text => skip validation */
 	if (hdr->tci_an & MACSEC_TCI_C ||
 	    secy->validate_frames != MACSEC_VALIDATE_DISABLED)
-- 
2.1.0


>From a9dcbd02cba7ef6c20f8555edcb0b9b55469924c Mon Sep 17 00:00:00 2001
From: Soheil Hassas Yeganeh <soheil@google.com>
Date: Fri, 29 Jul 2016 09:34:02 -0400
Subject: [PATCH 13/13] tcp: consider recv buf for the initial window scale

[ Upstream commit f626300a3e776ccc9671b0dd94698fb3aa315966 ]

tcp_select_initial_window() intends to advertise a window
scaling for the maximum possible window size. To do so,
it considers the maximum of net.ipv4.tcp_rmem[2] and
net.core.rmem_max as the only possible upper-bounds.
However, users with CAP_NET_ADMIN can use SO_RCVBUFFORCE
to set the socket's receive buffer size to values
larger than net.ipv4.tcp_rmem[2] and net.core.rmem_max.
Thus, SO_RCVBUFFORCE is effectively ignored by
tcp_select_initial_window().

To fix this, consider the maximum of net.ipv4.tcp_rmem[2],
net.core.rmem_max and socket's initial buffer space.

Fixes: b0573dea1fb3 ("[NET]: Introduce SO_{SND,RCV}BUFFORCE socket options")
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Suggested-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/tcp_output.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 79a03b8..7b8e903 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -236,7 +236,8 @@ void tcp_select_initial_window(int __space, __u32 mss,
 		/* Set window scaling on max possible window
 		 * See RFC1323 for an explanation of the limit to 14
 		 */
-		space = max_t(u32, sysctl_tcp_rmem[2], sysctl_rmem_max);
+		space = max_t(u32, space, sysctl_tcp_rmem[2]);
+		space = max_t(u32, space, sysctl_rmem_max);
 		space = min_t(u32, space, *window_clamp);
 		while (space > 65535 && (*rcv_wscale) < 14) {
 			space >>= 1;
-- 
2.1.0


[-- Attachment #4: net_47.mbox --]
[-- Type: Text/Plain, Size: 24179 bytes --]

>From feff53ceeb01f37c4298612e1c84fcdfb4dcd99f Mon Sep 17 00:00:00 2001
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Mon, 25 Jul 2016 18:06:12 +0200
Subject: [PATCH 01/10] udp: use sk_filter_trim_cap for udp{,6}_queue_rcv_skb

[ Upstream commit ba66bbe5480a012108958a71cff88b23dce84956 ]

After a612769774a3 ("udp: prevent bugcheck if filter truncates packet
too much"), there followed various other fixes for similar cases such
as f4979fcea7fd ("rose: limit sk_filter trim to payload").

Latter introduced a new helper sk_filter_trim_cap(), where we can pass
the trim limit directly to the socket filter handling. Make use of it
here as well with sizeof(struct udphdr) as lower cap limit and drop the
extra skb->len test in UDP's input path.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Willem de Bruijn <willemb@google.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/udp.c | 4 +---
 net/ipv6/udp.c | 4 +---
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 4aed8fc..e61f7cd 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1581,9 +1581,7 @@ int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
 	    udp_lib_checksum_complete(skb))
 			goto csum_error;
 
-	if (sk_filter(sk, skb))
-		goto drop;
-	if (unlikely(skb->len < sizeof(struct udphdr)))
+	if (sk_filter_trim_cap(sk, skb, sizeof(struct udphdr)))
 		goto drop;
 
 	udp_csum_pull_header(skb);
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index acc09705..42a2edf 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -618,9 +618,7 @@ int udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
 	    udp_lib_checksum_complete(skb))
 		goto csum_error;
 
-	if (sk_filter(sk, skb))
-		goto drop;
-	if (unlikely(skb->len < sizeof(struct udphdr)))
+	if (sk_filter_trim_cap(sk, skb, sizeof(struct udphdr)))
 		goto drop;
 
 	udp_csum_pull_header(skb);
-- 
2.1.0


>From f8561e442d29f3a00ab657c275f1bc68c9dab6bb Mon Sep 17 00:00:00 2001
From: Mark Bloch <markb@mellanox.com>
Date: Thu, 21 Jul 2016 11:52:55 +0300
Subject: [PATCH 02/10] net/bonding: Enforce active-backup policy for IPoIB
 bonds

[ Upstream commit 1533e77315220dc1d5ec3bd6d9fe32e2aa0a74c0 ]

When using an IPoIB bond currently only active-backup mode is a valid
use case and this commit strengthens it.

Since commit 2ab82852a270 ("net/bonding: Enable bonding to enslave
netdevices not supporting set_mac_address()") was introduced till
4.7-rc1, IPoIB didn't support the set_mac_address ndo, and hence the
fail over mac policy always applied to IPoIB bonds.

With the introduction of commit 492a7e67ff83 ("IB/IPoIB: Allow setting
the device address"), that doesn't hold and practically IPoIB bonds are
broken as of that. To fix it, lets go to fail over mac if the device
doesn't support the ndo OR this is IPoIB device.

As a by-product, this commit also prevents a stack corruption which
occurred when trying to copy 20 bytes (IPoIB) device address
to a sockaddr struct that has only 16 bytes of storage.

Signed-off-by: Mark Bloch <markb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Acked-by: Andy Gospodarek <gospo@cumulusnetworks.com>
Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/bonding/bond_main.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index a2afa3b..4d79819 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1422,7 +1422,16 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
 		return -EINVAL;
 	}
 
-	if (slave_ops->ndo_set_mac_address == NULL) {
+	if (slave_dev->type == ARPHRD_INFINIBAND &&
+	    BOND_MODE(bond) != BOND_MODE_ACTIVEBACKUP) {
+		netdev_warn(bond_dev, "Type (%d) supports only active-backup mode\n",
+			    slave_dev->type);
+		res = -EOPNOTSUPP;
+		goto err_undo_flags;
+	}
+
+	if (!slave_ops->ndo_set_mac_address ||
+	    slave_dev->type == ARPHRD_INFINIBAND) {
 		netdev_warn(bond_dev, "The slave device specified does not support setting the MAC address\n");
 		if (BOND_MODE(bond) == BOND_MODE_ACTIVEBACKUP &&
 		    bond->params.fail_over_mac != BOND_FOM_ACTIVE) {
-- 
2.1.0


>From f0e152b3f0b9ab321d69ccc7359eb7371be1d163 Mon Sep 17 00:00:00 2001
From: Ido Schimmel <idosch@mellanox.com>
Date: Fri, 22 Jul 2016 14:56:20 +0300
Subject: [PATCH 03/10] bridge: Fix incorrect re-injection of LLDP packets

[ Upstream commit baedbe55884c003819f5c8c063ec3d2569414296 ]

Commit 8626c56c8279 ("bridge: fix potential use-after-free when hook
returns QUEUE or STOLEN verdict") caused LLDP packets arriving through a
bridge port to be re-injected to the Rx path with skb->dev set to the
bridge device, but this breaks the lldpad daemon.

The lldpad daemon opens a packet socket with protocol set to ETH_P_LLDP
for any valid device on the system, which doesn't not include soft
devices such as bridge and VLAN.

Since packet sockets (ptype_base) are processed in the Rx path after the
Rx handler, LLDP packets with skb->dev set to the bridge device never
reach the lldpad daemon.

Fix this by making the bridge's Rx handler re-inject LLDP packets with
RX_HANDLER_PASS, which effectively restores the behaviour prior to the
mentioned commit.

This means netfilter will never receive LLDP packets coming through a
bridge port, as I don't see a way in which we can have okfn() consume
the packet without breaking existing behaviour. I've already carried out
a similar fix for STP packets in commit 56fae404fb2c ("bridge: Fix
incorrect re-injection of STP packets").

Fixes: 8626c56c8279 ("bridge: fix potential use-after-free when hook returns QUEUE or STOLEN verdict")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Cc: Florian Westphal <fw@strlen.de>
Cc: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/bridge/br_input.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 43d2cd8..28d5ec2 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -288,6 +288,14 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
 		case 0x01:	/* IEEE MAC (Pause) */
 			goto drop;
 
+		case 0x0E:	/* 802.1AB LLDP */
+			fwd_mask |= p->br->group_fwd_mask;
+			if (fwd_mask & (1u << dest[5]))
+				goto forward;
+			*pskb = skb;
+			__br_handle_local_finish(skb);
+			return RX_HANDLER_PASS;
+
 		default:
 			/* Allow selective forwarding for most other protocols */
 			fwd_mask |= p->br->group_fwd_mask;
-- 
2.1.0


>From 0993829fe12ff067e16673660be2f799e1f842ae Mon Sep 17 00:00:00 2001
From: Mike Manning <mmanning@brocade.com>
Date: Fri, 22 Jul 2016 18:32:11 +0100
Subject: [PATCH 04/10] net: ipv6: Always leave anycast and multicast groups on
 link down

[ Upstream commit ea06f7176413e2538d13bb85b65387d0917943d9 ]

Default kernel behavior is to delete IPv6 addresses on link
down, which entails deletion of the multicast and the
subnet-router anycast addresses. These deletions do not
happen with sysctl setting to keep global IPv6 addresses on
link down, so every link down/up causes an increment of the
anycast and multicast refcounts. These bogus refcounts may
stop these addrs from being removed on subsequent calls to
delete them. The solution is to leave the groups for the
multicast and subnet anycast on link down for the callflow
when global IPv6 addresses are kept.

Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
Signed-off-by: Mike Manning <mmanning@brocade.com>
Acked-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv6/addrconf.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 47f837a..047c75a 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3562,6 +3562,10 @@ restart:
 		if (state != INET6_IFADDR_STATE_DEAD) {
 			__ipv6_ifa_notify(RTM_DELADDR, ifa);
 			inet6addr_notifier_call_chain(NETDEV_DOWN, ifa);
+		} else {
+			if (idev->cnf.forwarding)
+				addrconf_leave_anycast(ifa);
+			addrconf_leave_solict(ifa->idev, &ifa->addr);
 		}
 
 		write_lock_bh(&idev->lock);
-- 
2.1.0


>From 9809c8e278461bc4367e6b09018cfcf87943efe0 Mon Sep 17 00:00:00 2001
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Sat, 23 Jul 2016 00:32:48 -0300
Subject: [PATCH 05/10] sctp: fix BH handling on socket backlog

[ Upstream commit eefc1b1d105ee4d2ce907833ce675f1e9599b5e3 ]

Now that the backlog processing is called with BH enabled, we have to
disable BH before taking the socket lock via bh_lock_sock() otherwise
it may dead lock:

sctp_backlog_rcv()
                bh_lock_sock(sk);

                if (sock_owned_by_user(sk)) {
                        if (sk_add_backlog(sk, skb, sk->sk_rcvbuf))
                                sctp_chunk_free(chunk);
                        else
                                backloged = 1;
                } else
                        sctp_inq_push(inqueue, chunk);

                bh_unlock_sock(sk);

while sctp_inq_push() was disabling/enabling BH, but enabling BH
triggers pending softirq, which then may try to re-lock the socket in
sctp_rcv().

[  219.187215]  <IRQ>
[  219.187217]  [<ffffffff817ca3e0>] _raw_spin_lock+0x20/0x30
[  219.187223]  [<ffffffffa041888c>] sctp_rcv+0x48c/0xba0 [sctp]
[  219.187225]  [<ffffffff816e7db2>] ? nf_iterate+0x62/0x80
[  219.187226]  [<ffffffff816f1b14>] ip_local_deliver_finish+0x94/0x1e0
[  219.187228]  [<ffffffff816f1e1f>] ip_local_deliver+0x6f/0xf0
[  219.187229]  [<ffffffff816f1a80>] ? ip_rcv_finish+0x3b0/0x3b0
[  219.187230]  [<ffffffff816f17a8>] ip_rcv_finish+0xd8/0x3b0
[  219.187232]  [<ffffffff816f2122>] ip_rcv+0x282/0x3a0
[  219.187233]  [<ffffffff810d8bb6>] ? update_curr+0x66/0x180
[  219.187235]  [<ffffffff816abac4>] __netif_receive_skb_core+0x524/0xa90
[  219.187236]  [<ffffffff810d8e00>] ? update_cfs_shares+0x30/0xf0
[  219.187237]  [<ffffffff810d557c>] ? __enqueue_entity+0x6c/0x70
[  219.187239]  [<ffffffff810dc454>] ? enqueue_entity+0x204/0xdf0
[  219.187240]  [<ffffffff816ac048>] __netif_receive_skb+0x18/0x60
[  219.187242]  [<ffffffff816ad1ce>] process_backlog+0x9e/0x140
[  219.187243]  [<ffffffff816ac8ec>] net_rx_action+0x22c/0x370
[  219.187245]  [<ffffffff817cd352>] __do_softirq+0x112/0x2e7
[  219.187247]  [<ffffffff817cc3bc>] do_softirq_own_stack+0x1c/0x30
[  219.187247]  <EOI>
[  219.187248]  [<ffffffff810aa1c8>] do_softirq.part.14+0x38/0x40
[  219.187249]  [<ffffffff810aa24d>] __local_bh_enable_ip+0x7d/0x80
[  219.187254]  [<ffffffffa0408428>] sctp_inq_push+0x68/0x80 [sctp]
[  219.187258]  [<ffffffffa04190f1>] sctp_backlog_rcv+0x151/0x1c0 [sctp]
[  219.187260]  [<ffffffff81692b07>] __release_sock+0x87/0xf0
[  219.187261]  [<ffffffff81692ba0>] release_sock+0x30/0xa0
[  219.187265]  [<ffffffffa040e46d>] sctp_accept+0x17d/0x210 [sctp]
[  219.187266]  [<ffffffff810e7510>] ? prepare_to_wait_event+0xf0/0xf0
[  219.187268]  [<ffffffff8172d52c>] inet_accept+0x3c/0x130
[  219.187269]  [<ffffffff8168d7a3>] SYSC_accept4+0x103/0x210
[  219.187271]  [<ffffffff817ca2ba>] ? _raw_spin_unlock_bh+0x1a/0x20
[  219.187272]  [<ffffffff81692bfc>] ? release_sock+0x8c/0xa0
[  219.187276]  [<ffffffffa0413e22>] ? sctp_inet_listen+0x62/0x1b0 [sctp]
[  219.187277]  [<ffffffff8168f2d0>] SyS_accept+0x10/0x20

Fixes: 860fbbc343bf ("sctp: prepare for socket backlog behavior change")
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/sctp/input.c   | 2 ++
 net/sctp/inqueue.c | 2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/sctp/input.c b/net/sctp/input.c
index 47cf460..f093322 100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -328,6 +328,7 @@ int sctp_backlog_rcv(struct sock *sk, struct sk_buff *skb)
 		 */
 
 		sk = rcvr->sk;
+		local_bh_disable();
 		bh_lock_sock(sk);
 
 		if (sock_owned_by_user(sk)) {
@@ -339,6 +340,7 @@ int sctp_backlog_rcv(struct sock *sk, struct sk_buff *skb)
 			sctp_inq_push(inqueue, chunk);
 
 		bh_unlock_sock(sk);
+		local_bh_enable();
 
 		/* If the chunk was backloged again, don't drop refs */
 		if (backloged)
diff --git a/net/sctp/inqueue.c b/net/sctp/inqueue.c
index 9d87bba..b335ffc 100644
--- a/net/sctp/inqueue.c
+++ b/net/sctp/inqueue.c
@@ -89,12 +89,10 @@ void sctp_inq_push(struct sctp_inq *q, struct sctp_chunk *chunk)
 	 * Eventually, we should clean up inqueue to not rely
 	 * on the BH related data structures.
 	 */
-	local_bh_disable();
 	list_add_tail(&chunk->list, &q->in_chunk_list);
 	if (chunk->asoc)
 		chunk->asoc->stats.ipackets++;
 	q->immediate.func(&q->immediate);
-	local_bh_enable();
 }
 
 /* Peek at the next chunk on the inqeue. */
-- 
2.1.0


>From 4e76e1c6648ac314ba982866a292dccbf93cab6c Mon Sep 17 00:00:00 2001
From: Vegard Nossum <vegard.nossum@oracle.com>
Date: Sat, 23 Jul 2016 07:43:50 +0200
Subject: [PATCH 06/10] net/irda: fix NULL pointer dereference on memory
 allocation failure

[ Upstream commit d3e6952cfb7ba5f4bfa29d4803ba91f96ce1204d ]

I ran into this:

    kasan: CONFIG_KASAN_INLINE enabled
    kasan: GPF could be caused by NULL-ptr deref or user memory access
    general protection fault: 0000 [#1] PREEMPT SMP KASAN
    CPU: 2 PID: 2012 Comm: trinity-c3 Not tainted 4.7.0-rc7+ #19
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    task: ffff8800b745f2c0 ti: ffff880111740000 task.ti: ffff880111740000
    RIP: 0010:[<ffffffff82bbf066>]  [<ffffffff82bbf066>] irttp_connect_request+0x36/0x710
    RSP: 0018:ffff880111747bb8  EFLAGS: 00010286
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000069dd8358
    RDX: 0000000000000009 RSI: 0000000000000027 RDI: 0000000000000048
    RBP: ffff880111747c00 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000069dd8358 R11: 1ffffffff0759723 R12: 0000000000000000
    R13: ffff88011a7e4780 R14: 0000000000000027 R15: 0000000000000000
    FS:  00007fc738404700(0000) GS:ffff88011af00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fc737fdfb10 CR3: 0000000118087000 CR4: 00000000000006e0
    Stack:
     0000000000000200 ffff880111747bd8 ffffffff810ee611 ffff880119f1f220
     ffff880119f1f4f8 ffff880119f1f4f0 ffff88011a7e4780 ffff880119f1f232
     ffff880119f1f220 ffff880111747d58 ffffffff82bca542 0000000000000000
    Call Trace:
     [<ffffffff82bca542>] irda_connect+0x562/0x1190
     [<ffffffff825ae582>] SYSC_connect+0x202/0x2a0
     [<ffffffff825b4489>] SyS_connect+0x9/0x10
     [<ffffffff8100334c>] do_syscall_64+0x19c/0x410
     [<ffffffff83295ca5>] entry_SYSCALL64_slow_path+0x25/0x25
    Code: 41 89 ca 48 89 e5 41 57 41 56 41 55 41 54 41 89 d7 53 48 89 fb 48 83 c7 48 48 89 fa 41 89 f6 48 c1 ea 03 48 83 ec 20 4c 8b 65 10 <0f> b6 04 02 84 c0 74 08 84 c0 0f 8e 4c 04 00 00 80 7b 48 00 74
    RIP  [<ffffffff82bbf066>] irttp_connect_request+0x36/0x710
     RSP <ffff880111747bb8>
    ---[ end trace 4cda2588bc055b30 ]---

The problem is that irda_open_tsap() can fail and leave self->tsap = NULL,
and then irttp_connect_request() almost immediately dereferences it.

Cc: stable@vger.kernel.org
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/irda/af_irda.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/net/irda/af_irda.c b/net/irda/af_irda.c
index 923abd6..8d2f7c9 100644
--- a/net/irda/af_irda.c
+++ b/net/irda/af_irda.c
@@ -1024,8 +1024,11 @@ static int irda_connect(struct socket *sock, struct sockaddr *uaddr,
 	}
 
 	/* Check if we have opened a local TSAP */
-	if (!self->tsap)
-		irda_open_tsap(self, LSAP_ANY, addr->sir_name);
+	if (!self->tsap) {
+		err = irda_open_tsap(self, LSAP_ANY, addr->sir_name);
+		if (err)
+			goto out;
+	}
 
 	/* Move to connecting socket, start sending Connect Requests */
 	sock->state = SS_CONNECTING;
-- 
2.1.0


>From 716cc6f0afc29f7f5f1dccb8ac4ff6b08b83f425 Mon Sep 17 00:00:00 2001
From: Vegard Nossum <vegard.nossum@oracle.com>
Date: Sat, 23 Jul 2016 09:42:35 +0200
Subject: [PATCH 07/10] net/sctp: terminate rhashtable walk correctly

[ Upstream commit 5fc382d87517707ad77ea4c9c12e2a3fde2c838a ]

I was seeing a lot of these:

    BUG: sleeping function called from invalid context at mm/slab.h:388
    in_atomic(): 0, irqs_disabled(): 0, pid: 14971, name: trinity-c2
    Preemption disabled at:[<ffffffff819bcd46>] rhashtable_walk_start+0x46/0x150

     [<ffffffff81149abb>] preempt_count_add+0x1fb/0x280
     [<ffffffff83295722>] _raw_spin_lock+0x12/0x40
     [<ffffffff811aac87>] console_unlock+0x2f7/0x930
     [<ffffffff811ab5bb>] vprintk_emit+0x2fb/0x520
     [<ffffffff811aba6a>] vprintk_default+0x1a/0x20
     [<ffffffff812c171a>] printk+0x94/0xb0
     [<ffffffff811d6ed0>] print_stack_trace+0xe0/0x170
     [<ffffffff8115835e>] ___might_sleep+0x3be/0x460
     [<ffffffff81158490>] __might_sleep+0x90/0x1a0
     [<ffffffff8139b823>] kmem_cache_alloc+0x153/0x1e0
     [<ffffffff819bca1e>] rhashtable_walk_init+0xfe/0x2d0
     [<ffffffff82ec64de>] sctp_transport_walk_start+0x1e/0x60
     [<ffffffff82edd8ad>] sctp_transport_seq_start+0x4d/0x150
     [<ffffffff8143a82b>] seq_read+0x27b/0x1180
     [<ffffffff814f97fc>] proc_reg_read+0xbc/0x180
     [<ffffffff813d471b>] __vfs_read+0xdb/0x610
     [<ffffffff813d4d3a>] vfs_read+0xea/0x2d0
     [<ffffffff813d615b>] SyS_pread64+0x11b/0x150
     [<ffffffff8100334c>] do_syscall_64+0x19c/0x410
     [<ffffffff832960a5>] return_from_SYSCALL_64+0x0/0x6a
     [<ffffffffffffffff>] 0xffffffffffffffff

Apparently we always need to call rhashtable_walk_stop(), even when
rhashtable_walk_start() fails:

 * rhashtable_walk_start - Start a hash table walk
 * @iter:       Hash table iterator
 *
 * Start a hash table walk.  Note that we take the RCU lock in all
 * cases including when we return an error.  So you must always call
 * rhashtable_walk_stop to clean up.

otherwise we never call rcu_read_unlock() and we get the splat above.

Fixes: 53fa1036 ("sctp: fix some rhashtable functions using in sctp proc/diag")
See-also: 53fa1036 ("sctp: fix some rhashtable functions using in sctp proc/diag")
See-also: f2dba9c6 ("rhashtable: Introduce rhashtable_walk_*")
Cc: Xin Long <lucien.xin@gmail.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: stable@vger.kernel.org
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/sctp/socket.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 67154b8..7f5689a 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4301,6 +4301,7 @@ int sctp_transport_walk_start(struct rhashtable_iter *iter)
 
 	err = rhashtable_walk_start(iter);
 	if (err && err != -EAGAIN) {
+		rhashtable_walk_stop(iter);
 		rhashtable_walk_exit(iter);
 		return err;
 	}
-- 
2.1.0


>From a1dc5a3ce16bab0f568cbb0a68bc68da63a664ef Mon Sep 17 00:00:00 2001
From: Manish Chopra <manish.chopra@qlogic.com>
Date: Mon, 25 Jul 2016 19:07:46 +0300
Subject: [PATCH 08/10] qed: Fix setting/clearing bit in completion bitmap

[ Upstream commit 59d3f1ceb69b54569685d0c34dff16a1e0816b19 ]

Slowpath completion handling is incorrectly changing
SPQ_RING_SIZE bits instead of a single one.

Fixes: 76a9a3642a0b ("qed: fix handling of concurrent ramrods")
Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/ethernet/qlogic/qed/qed_spq.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_spq.c b/drivers/net/ethernet/qlogic/qed/qed_spq.c
index b122f60..03601df 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_spq.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_spq.c
@@ -809,13 +809,12 @@ int qed_spq_completion(struct qed_hwfn *p_hwfn,
 			 * in a bitmap and increasing the chain consumer only
 			 * for the first successive completed entries.
 			 */
-			bitmap_set(p_spq->p_comp_bitmap, pos, SPQ_RING_SIZE);
+			__set_bit(pos, p_spq->p_comp_bitmap);
 
 			while (test_bit(p_spq->comp_bitmap_idx,
 					p_spq->p_comp_bitmap)) {
-				bitmap_clear(p_spq->p_comp_bitmap,
-					     p_spq->comp_bitmap_idx,
-					     SPQ_RING_SIZE);
+				__clear_bit(p_spq->comp_bitmap_idx,
+					    p_spq->p_comp_bitmap);
 				p_spq->comp_bitmap_idx++;
 				qed_chain_return_produced(&p_spq->chain);
 			}
-- 
2.1.0


>From d7d53adcacbbbe2a3f6bfb4d6ea6a482e028d495 Mon Sep 17 00:00:00 2001
From: Beniamino Galvani <bgalvani@redhat.com>
Date: Tue, 26 Jul 2016 12:24:53 +0200
Subject: [PATCH 09/10] macsec: ensure rx_sa is set when validation is disabled

[ Upstream commit e3a3b626010a14fe067f163c2c43409d5afcd2a9 ]

macsec_decrypt() is not called when validation is disabled and so
macsec_skb_cb(skb)->rx_sa is not set; but it is used later in
macsec_post_decrypt(), ensure that it's always initialized.

Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
Signed-off-by: Beniamino Galvani <bgalvani@redhat.com>
Acked-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/macsec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index 8bcd78f..a70b6c4 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -942,7 +942,6 @@ static struct sk_buff *macsec_decrypt(struct sk_buff *skb,
 	}
 
 	macsec_skb_cb(skb)->req = req;
-	macsec_skb_cb(skb)->rx_sa = rx_sa;
 	skb->dev = dev;
 	aead_request_set_callback(req, 0, macsec_decrypt_done, skb);
 
@@ -1169,6 +1168,8 @@ static rx_handler_result_t macsec_handle_frame(struct sk_buff **pskb)
 		}
 	}
 
+	macsec_skb_cb(skb)->rx_sa = rx_sa;
+
 	/* Disabled && !changed text => skip validation */
 	if (hdr->tci_an & MACSEC_TCI_C ||
 	    secy->validate_frames != MACSEC_VALIDATE_DISABLED)
-- 
2.1.0


>From fc4814047308a5d3beb2f6284ed7cfb73c032e9d Mon Sep 17 00:00:00 2001
From: Soheil Hassas Yeganeh <soheil@google.com>
Date: Fri, 29 Jul 2016 09:34:02 -0400
Subject: [PATCH 10/10] tcp: consider recv buf for the initial window scale

[ Upstream commit f626300a3e776ccc9671b0dd94698fb3aa315966 ]

tcp_select_initial_window() intends to advertise a window
scaling for the maximum possible window size. To do so,
it considers the maximum of net.ipv4.tcp_rmem[2] and
net.core.rmem_max as the only possible upper-bounds.
However, users with CAP_NET_ADMIN can use SO_RCVBUFFORCE
to set the socket's receive buffer size to values
larger than net.ipv4.tcp_rmem[2] and net.core.rmem_max.
Thus, SO_RCVBUFFORCE is effectively ignored by
tcp_select_initial_window().

To fix this, consider the maximum of net.ipv4.tcp_rmem[2],
net.core.rmem_max and socket's initial buffer space.

Fixes: b0573dea1fb3 ("[NET]: Introduce SO_{SND,RCV}BUFFORCE socket options")
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Suggested-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv4/tcp_output.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index e00e972..700b72c 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -236,7 +236,8 @@ void tcp_select_initial_window(int __space, __u32 mss,
 		/* Set window scaling on max possible window
 		 * See RFC1323 for an explanation of the limit to 14
 		 */
-		space = max_t(u32, sysctl_tcp_rmem[2], sysctl_rmem_max);
+		space = max_t(u32, space, sysctl_tcp_rmem[2]);
+		space = max_t(u32, space, sysctl_rmem_max);
 		space = min_t(u32, space, *window_clamp);
 		while (space > 65535 && (*rcv_wscale) < 14) {
 			space >>= 1;
-- 
2.1.0


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2016-07-13 21:43 David Miller
@ 2016-07-13 22:38 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2016-07-13 22:38 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Wed, Jul 13, 2016 at 02:43:00PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 4.4.x and 4.6.x
> -stable, respectively.

Thanks, all now queued up!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2016-07-13 21:43 David Miller
  2016-07-13 22:38 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2016-07-13 21:43 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 104 bytes --]


Please queue up the following networking bug fixes for 4.4.x and 4.6.x
-stable, respectively.

Thanks!

[-- Attachment #2: net_44.mbox --]
[-- Type: Application/Octet-Stream, Size: 11625 bytes --]

[-- Attachment #3: net_46.mbox --]
[-- Type: Application/Octet-Stream, Size: 14450 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2016-07-06  5:02 David Miller
@ 2016-07-07  0:35 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2016-07-07  0:35 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, Jul 05, 2016 at 10:02:12PM -0700, David Miller wrote:
> 
> Please queue up the following bug fixes for 4.4.x and 4.6.x -stable,
> respectively.

Now applied, thanks so much for these.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2016-07-06  5:02 David Miller
  2016-07-07  0:35 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2016-07-06  5:02 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 93 bytes --]


Please queue up the following bug fixes for 4.4.x and 4.6.x -stable,
respectively.

Thanks!

[-- Attachment #2: net_44.mbox --]
[-- Type: Application/Octet-Stream, Size: 40237 bytes --]

[-- Attachment #3: net_46.mbox --]
[-- Type: Application/Octet-Stream, Size: 31585 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2016-06-17  7:03 David Miller
@ 2016-06-18  1:01 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2016-06-18  1:01 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Fri, Jun 17, 2016 at 12:03:46AM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 4.4, 4.5,
> and 4.6 -stable, respectively.

Unfortunately 4.5 is now end-of-life, but thanks for those patches
anyway, hopefully someone can use them if they depend on that tree.

I've queued up the 4.4 and 4.6 patch sets.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2016-06-17  7:03 David Miller
  2016-06-18  1:01 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2016-06-17  7:03 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 106 bytes --]


Please queue up the following networking bug fixes for 4.4, 4.5,
and 4.6 -stable, respectively.

Thanks!

[-- Attachment #2: net_44.mbox --]
[-- Type: Application/Octet-Stream, Size: 49457 bytes --]

[-- Attachment #3: net_45.mbox --]
[-- Type: Application/Octet-Stream, Size: 74822 bytes --]

[-- Attachment #4: net_46.mbox --]
[-- Type: Application/Octet-Stream, Size: 58099 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2016-05-16 16:35 David Miller
@ 2016-05-16 21:50 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2016-05-16 21:50 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Mon, May 16, 2016 at 12:35:13PM -0400, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 4.1.x, 4.4.x, and 4.5.x -stable,
> respectively.

Many thanks, patches for 4.4.x and 4.5.x now applied, and a few
cherry-picked for 3.14 where needed.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2016-05-16 16:35 David Miller
  2016-05-16 21:50 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2016-05-16 16:35 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 112 bytes --]


Please queue up the following networking bug fixes for 4.1.x, 4.4.x, and 4.5.x -stable,
respectively.

Thanks!

[-- Attachment #2: net_41.mbox --]
[-- Type: Application/Octet-Stream, Size: 80887 bytes --]

[-- Attachment #3: net_44.mbox --]
[-- Type: Application/Octet-Stream, Size: 123083 bytes --]

[-- Attachment #4: net_45.mbox --]
[-- Type: Application/Octet-Stream, Size: 139280 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2016-04-15  4:45 David Miller
@ 2016-04-16 17:49 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2016-04-16 17:49 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Fri, Apr 15, 2016 at 12:45:04AM -0400, David Miller wrote:
> 
> Please queue up the following bug fixes for 4.1, 4.4, and 4.5 -stable,
> respectively.

Thanks for these, I've queued up the 4.4 and 4.5-stable ones now.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2016-04-15  4:45 David Miller
  2016-04-16 17:49 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2016-04-15  4:45 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 95 bytes --]


Please queue up the following bug fixes for 4.1, 4.4, and 4.5 -stable,
respectively.

Thanks!

[-- Attachment #2: net_41.mbox --]
[-- Type: Application/Octet-Stream, Size: 90994 bytes --]

[-- Attachment #3: net_44.mbox --]
[-- Type: Application/Octet-Stream, Size: 143988 bytes --]

[-- Attachment #4: net_45.mbox --]
[-- Type: Application/Octet-Stream, Size: 107010 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2016-02-29 21:56 David Miller
@ 2016-02-29 22:45 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2016-02-29 22:45 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Mon, Feb 29, 2016 at 04:56:15PM -0500, David Miller wrote:
> 
> Please queue up the following bug fixes for 4.1.x and 4.4.x -stable,
> respectively.

All now applied for 4.4.y, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2016-02-29 21:56 David Miller
  2016-02-29 22:45 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2016-02-29 21:56 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 93 bytes --]


Please queue up the following bug fixes for 4.1.x and 4.4.x -stable,
respectively.

Thanks!

[-- Attachment #2: net_41.mbox --]
[-- Type: Application/Octet-Stream, Size: 95022 bytes --]

[-- Attachment #3: net_44.mbox --]
[-- Type: Application/Octet-Stream, Size: 132632 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2016-01-27  2:00 David Miller
@ 2016-01-27  6:35 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2016-01-27  6:35 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, Jan 26, 2016 at 06:00:44PM -0800, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 4.4.x, 4.3.1, 4.1.x, and
> 3.18.x -stable, respectively.

All queued up now, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2016-01-27  2:00 David Miller
  2016-01-27  6:35 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2016-01-27  2:00 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 120 bytes --]


Please queue up the following networking bug fixes for 4.4.x, 4.3.1, 4.1.x, and
3.18.x -stable, respectively.

Thanks!

[-- Attachment #2: net_44.mbox --]
[-- Type: Application/Octet-Stream, Size: 69799 bytes --]

[-- Attachment #3: net_43.mbox --]
[-- Type: Application/Octet-Stream, Size: 120439 bytes --]

[-- Attachment #4: net_41.mbox --]
[-- Type: Application/Octet-Stream, Size: 122371 bytes --]

[-- Attachment #5: net_318.mbox --]
[-- Type: Application/Octet-Stream, Size: 62825 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2016-01-19 17:39       ` Greg KH
@ 2016-01-19 17:41         ` Josh Boyer
  0 siblings, 0 replies; 213+ messages in thread
From: Josh Boyer @ 2016-01-19 17:41 UTC (permalink / raw)
  To: Greg KH; +Cc: David Miller, stable

On Tue, Jan 19, 2016 at 12:39 PM, Greg KH <greg@kroah.com> wrote:
> On Tue, Jan 19, 2016 at 08:29:48AM -0500, Josh Boyer wrote:
>> On Tue, Jan 19, 2016 at 7:00 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> > On Tue, Jan 19, 2016 at 12:20 AM, Greg KH <greg@kroah.com> wrote:
>> >> On Tue, Dec 22, 2015 at 04:51:57PM -0500, David Miller wrote:
>> >>>
>> >>> Please queue up the following bug fixes for 3.18.x, 4.1.x, and
>> >>> 4.3.x -stable, respectively.
>> >>>
>> >>> Thanks!
>> >>
>> >> Thanks for the patches, now queued up to the trees I care about.
>> >
>> > Hi Greg.  Looks like you only queued up patches in the 3.10 and 3.14
>> > trees.  Does that mean you aren't going to do another 4.3.y release?
>> > You have patches sitting in the queue from Dave's last set, and you
>> > didn't add these so I'm confused.
>>
>> OK, I am confused and I sorted it out sort of.  The patches in
>> stable-queue/queue-4.3 are this set, not the previous set.  My mistake
>> and my apologies.
>>
>> I am still curious if 4.3.y is going to get another release though
>> given 4.4.1 should be coming out relatively soon.
>
> 4.4.1 can't come out until 4.5-rc1 is out, so yes, I'll be doing at
> least one more 4.3.y release, if not a few more.

Thanks.  Good to know.

josh

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2016-01-19 13:29     ` Josh Boyer
@ 2016-01-19 17:39       ` Greg KH
  2016-01-19 17:41         ` Josh Boyer
  0 siblings, 1 reply; 213+ messages in thread
From: Greg KH @ 2016-01-19 17:39 UTC (permalink / raw)
  To: Josh Boyer; +Cc: David Miller, stable

On Tue, Jan 19, 2016 at 08:29:48AM -0500, Josh Boyer wrote:
> On Tue, Jan 19, 2016 at 7:00 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > On Tue, Jan 19, 2016 at 12:20 AM, Greg KH <greg@kroah.com> wrote:
> >> On Tue, Dec 22, 2015 at 04:51:57PM -0500, David Miller wrote:
> >>>
> >>> Please queue up the following bug fixes for 3.18.x, 4.1.x, and
> >>> 4.3.x -stable, respectively.
> >>>
> >>> Thanks!
> >>
> >> Thanks for the patches, now queued up to the trees I care about.
> >
> > Hi Greg.  Looks like you only queued up patches in the 3.10 and 3.14
> > trees.  Does that mean you aren't going to do another 4.3.y release?
> > You have patches sitting in the queue from Dave's last set, and you
> > didn't add these so I'm confused.
> 
> OK, I am confused and I sorted it out sort of.  The patches in
> stable-queue/queue-4.3 are this set, not the previous set.  My mistake
> and my apologies.
> 
> I am still curious if 4.3.y is going to get another release though
> given 4.4.1 should be coming out relatively soon.

4.4.1 can't come out until 4.5-rc1 is out, so yes, I'll be doing at
least one more 4.3.y release, if not a few more.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2016-01-19 12:00   ` Josh Boyer
@ 2016-01-19 13:29     ` Josh Boyer
  2016-01-19 17:39       ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: Josh Boyer @ 2016-01-19 13:29 UTC (permalink / raw)
  To: Greg KH; +Cc: David Miller, stable

On Tue, Jan 19, 2016 at 7:00 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Tue, Jan 19, 2016 at 12:20 AM, Greg KH <greg@kroah.com> wrote:
>> On Tue, Dec 22, 2015 at 04:51:57PM -0500, David Miller wrote:
>>>
>>> Please queue up the following bug fixes for 3.18.x, 4.1.x, and
>>> 4.3.x -stable, respectively.
>>>
>>> Thanks!
>>
>> Thanks for the patches, now queued up to the trees I care about.
>
> Hi Greg.  Looks like you only queued up patches in the 3.10 and 3.14
> trees.  Does that mean you aren't going to do another 4.3.y release?
> You have patches sitting in the queue from Dave's last set, and you
> didn't add these so I'm confused.

OK, I am confused and I sorted it out sort of.  The patches in
stable-queue/queue-4.3 are this set, not the previous set.  My mistake
and my apologies.

I am still curious if 4.3.y is going to get another release though
given 4.4.1 should be coming out relatively soon.

josh

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2016-01-19  5:20 ` Greg KH
@ 2016-01-19 12:00   ` Josh Boyer
  2016-01-19 13:29     ` Josh Boyer
  0 siblings, 1 reply; 213+ messages in thread
From: Josh Boyer @ 2016-01-19 12:00 UTC (permalink / raw)
  To: Greg KH; +Cc: David Miller, stable

On Tue, Jan 19, 2016 at 12:20 AM, Greg KH <greg@kroah.com> wrote:
> On Tue, Dec 22, 2015 at 04:51:57PM -0500, David Miller wrote:
>>
>> Please queue up the following bug fixes for 3.18.x, 4.1.x, and
>> 4.3.x -stable, respectively.
>>
>> Thanks!
>
> Thanks for the patches, now queued up to the trees I care about.

Hi Greg.  Looks like you only queued up patches in the 3.10 and 3.14
trees.  Does that mean you aren't going to do another 4.3.y release?
You have patches sitting in the queue from Dave's last set, and you
didn't add these so I'm confused.

josh

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-12-22 21:51 David Miller
@ 2016-01-19  5:20 ` Greg KH
  2016-01-19 12:00   ` Josh Boyer
  0 siblings, 1 reply; 213+ messages in thread
From: Greg KH @ 2016-01-19  5:20 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, Dec 22, 2015 at 04:51:57PM -0500, David Miller wrote:
> 
> Please queue up the following bug fixes for 3.18.x, 4.1.x, and
> 4.3.x -stable, respectively.
> 
> Thanks!

Thanks for the patches, now queued up to the trees I care about.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2015-12-22 21:51 David Miller
  2016-01-19  5:20 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2015-12-22 21:51 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 102 bytes --]


Please queue up the following bug fixes for 3.18.x, 4.1.x, and
4.3.x -stable, respectively.

Thanks!

[-- Attachment #2: net_318.mbox --]
[-- Type: Application/Octet-Stream, Size: 32638 bytes --]

[-- Attachment #3: net_41.mbox --]
[-- Type: Application/Octet-Stream, Size: 56001 bytes --]

[-- Attachment #4: net_43.mbox --]
[-- Type: Application/Octet-Stream, Size: 72084 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-12-10 19:37 David Miller
@ 2015-12-11 16:49 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2015-12-11 16:49 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Thu, Dec 10, 2015 at 02:37:58PM -0500, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 3.18, 4.1, 4.2,
> and 4.3 -stable, respectively.

All queued up now, thanks.

Note, this is going to be the last 4.2-stable kernel release, so no need
to do any more networking stable patches for it.

thanks again,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2015-12-10 19:37 David Miller
  2015-12-11 16:49 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2015-12-10 19:37 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 112 bytes --]


Please queue up the following networking bug fixes for 3.18, 4.1, 4.2,
and 4.3 -stable, respectively.

Thanks!

[-- Attachment #2: net_318.mbox --]
[-- Type: Application/Octet-Stream, Size: 83293 bytes --]

[-- Attachment #3: net_41.mbox --]
[-- Type: Application/Octet-Stream, Size: 96593 bytes --]

[-- Attachment #4: net_42.mbox --]
[-- Type: Application/Octet-Stream, Size: 122630 bytes --]

[-- Attachment #5: net_43.mbox --]
[-- Type: Application/Octet-Stream, Size: 143618 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-11-13 21:38 David Miller
  2015-11-14 15:59 ` Jiri Slaby
@ 2015-12-06  5:25 ` Greg KH
  1 sibling, 0 replies; 213+ messages in thread
From: Greg KH @ 2015-12-06  5:25 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Fri, Nov 13, 2015 at 04:38:08PM -0500, David Miller wrote:
> 
> Please queue up the following bug fixes to 4.3.x, 4.2.x, 4.1.x, and
> 3.18.x -stable, respectively.

All queued up, thanks for these.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-11-14 15:59 ` Jiri Slaby
@ 2015-11-15 17:55   ` David Miller
  0 siblings, 0 replies; 213+ messages in thread
From: David Miller @ 2015-11-15 17:55 UTC (permalink / raw)
  To: jslaby; +Cc: stable

From: Jiri Slaby <jslaby@suse.cz>
Date: Sat, 14 Nov 2015 16:59:34 +0100

> On 11/13/2015, 10:38 PM, David Miller wrote:
>> 
>> Please queue up the following bug fixes to 4.3.x, 4.2.x, 4.1.x, and
>> 3.18.x -stable, respectively.
> 
> Hi,
> 
> it looks like 3.18 backport of 4ece9009774596ee3df0acba65a324b7ea79387c
> is missing removal of ipip6_tunnel_clone_6rd call, right?

Indeed, good catch.

The following should be more correct:

====================
>From 7cc46fa7d5de9f253615f887522a18bb621737dc Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet@google.com>
Date: Mon, 2 Nov 2015 17:08:19 -0800
Subject: [PATCH] sit: fix sit0 percpu double allocations

[ Upstream commit 4ece9009774596ee3df0acba65a324b7ea79387c ]

sit0 device allocates its percpu storage twice :
- One time in ipip6_tunnel_init()
- One time in ipip6_fb_tunnel_init()

Thus we leak 48 bytes per possible cpu per network namespace dismantle.

ipip6_fb_tunnel_init() can be much simpler and does not
return an error, and should be called after register_netdev()

Note that ipip6_tunnel_clone_6rd() also needs to be called
after register_netdev() (calling ipip6_tunnel_init())

Fixes: ebe084aafb7e ("sit: Use ipip6_tunnel_init as the ndo_init function.")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/ipv6/sit.c | 27 ++++-----------------------
 1 file changed, 4 insertions(+), 23 deletions(-)

diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index a24557a..45eae1e 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1394,34 +1394,20 @@ static int ipip6_tunnel_init(struct net_device *dev)
 	return 0;
 }
 
-static int __net_init ipip6_fb_tunnel_init(struct net_device *dev)
+static void __net_init ipip6_fb_tunnel_init(struct net_device *dev)
 {
 	struct ip_tunnel *tunnel = netdev_priv(dev);
 	struct iphdr *iph = &tunnel->parms.iph;
 	struct net *net = dev_net(dev);
 	struct sit_net *sitn = net_generic(net, sit_net_id);
 
-	tunnel->dev = dev;
-	tunnel->net = dev_net(dev);
-
 	iph->version		= 4;
 	iph->protocol		= IPPROTO_IPV6;
 	iph->ihl		= 5;
 	iph->ttl		= 64;
 
-	dev->tstats = netdev_alloc_pcpu_stats(struct pcpu_sw_netstats);
-	if (!dev->tstats)
-		return -ENOMEM;
-
-	tunnel->dst_cache = alloc_percpu(struct ip_tunnel_dst);
-	if (!tunnel->dst_cache) {
-		free_percpu(dev->tstats);
-		return -ENOMEM;
-	}
-
 	dev_hold(dev);
 	rcu_assign_pointer(sitn->tunnels_wc[0], tunnel);
-	return 0;
 }
 
 static int ipip6_validate(struct nlattr *tb[], struct nlattr *data[])
@@ -1831,23 +1817,18 @@ static int __net_init sit_init_net(struct net *net)
 	 */
 	sitn->fb_tunnel_dev->features |= NETIF_F_NETNS_LOCAL;
 
-	err = ipip6_fb_tunnel_init(sitn->fb_tunnel_dev);
-	if (err)
-		goto err_dev_free;
-
-	ipip6_tunnel_clone_6rd(sitn->fb_tunnel_dev, sitn);
-
 	if ((err = register_netdev(sitn->fb_tunnel_dev)))
 		goto err_reg_dev;
 
+	ipip6_tunnel_clone_6rd(sitn->fb_tunnel_dev, sitn);
+	ipip6_fb_tunnel_init(sitn->fb_tunnel_dev);
+
 	t = netdev_priv(sitn->fb_tunnel_dev);
 
 	strcpy(t->parms.name, sitn->fb_tunnel_dev->name);
 	return 0;
 
 err_reg_dev:
-	dev_put(sitn->fb_tunnel_dev);
-err_dev_free:
 	ipip6_dev_free(sitn->fb_tunnel_dev);
 err_alloc_dev:
 	return err;
-- 
2.1.0


^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-11-13 21:38 David Miller
@ 2015-11-14 15:59 ` Jiri Slaby
  2015-11-15 17:55   ` David Miller
  2015-12-06  5:25 ` Greg KH
  1 sibling, 1 reply; 213+ messages in thread
From: Jiri Slaby @ 2015-11-14 15:59 UTC (permalink / raw)
  To: David Miller, stable

On 11/13/2015, 10:38 PM, David Miller wrote:
> 
> Please queue up the following bug fixes to 4.3.x, 4.2.x, 4.1.x, and
> 3.18.x -stable, respectively.

Hi,

it looks like 3.18 backport of 4ece9009774596ee3df0acba65a324b7ea79387c
is missing removal of ipip6_tunnel_clone_6rd call, right?

thanks,
-- 
js
suse labs

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2015-11-13 21:38 David Miller
  2015-11-14 15:59 ` Jiri Slaby
  2015-12-06  5:25 ` Greg KH
  0 siblings, 2 replies; 213+ messages in thread
From: David Miller @ 2015-11-13 21:38 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 108 bytes --]


Please queue up the following bug fixes to 4.3.x, 4.2.x, 4.1.x, and
3.18.x -stable, respectively.

Thanks!

[-- Attachment #2: net_43.mbox --]
[-- Type: Application/Octet-Stream, Size: 45935 bytes --]

[-- Attachment #3: net_42.mbox --]
[-- Type: Application/Octet-Stream, Size: 71031 bytes --]

[-- Attachment #4: net_41.mbox --]
[-- Type: Application/Octet-Stream, Size: 50878 bytes --]

[-- Attachment #5: net_318.mbox --]
[-- Type: Application/Octet-Stream, Size: 45587 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-10-21  3:51 David Miller
@ 2015-10-23 16:25 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2015-10-23 16:25 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, Oct 20, 2015 at 08:51:10PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 3.14, 3.18, 4.1,
> and 4.2 -stable, respectively.

All queued up for the stable trees I manage, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2015-10-21  3:51 David Miller
  2015-10-23 16:25 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2015-10-21  3:51 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 113 bytes --]


Please queue up the following networking bug fixes for 3.14, 3.18, 4.1,
and 4.2 -stable, respectively.

Thanks!

[-- Attachment #2: net_314.mbox --]
[-- Type: Application/Octet-Stream, Size: 22500 bytes --]

[-- Attachment #3: net_318.mbox --]
[-- Type: Application/Octet-Stream, Size: 24472 bytes --]

[-- Attachment #4: net_41.mbox --]
[-- Type: Application/Octet-Stream, Size: 37768 bytes --]

[-- Attachment #5: net_42.mbox --]
[-- Type: Application/Octet-Stream, Size: 41782 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-09-29  4:54 David Miller
@ 2015-09-30  3:33 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2015-09-30  3:33 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Mon, Sep 28, 2015 at 09:54:08PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v3.14, v3.18,
> v4.1, and v4.2 -stable, respectively.

ALl now queued up for 3.14, 4.1, and 4.2, thanks!

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2015-09-29  4:54 David Miller
  2015-09-30  3:33 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2015-09-29  4:54 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 117 bytes --]


Please queue up the following networking bug fixes for v3.14, v3.18,
v4.1, and v4.2 -stable, respectively.

Thanks!

[-- Attachment #2: net_314.mbox --]
[-- Type: Application/Octet-Stream, Size: 24549 bytes --]

[-- Attachment #3: net_318.mbox --]
[-- Type: Application/Octet-Stream, Size: 32017 bytes --]

[-- Attachment #4: net_41.mbox --]
[-- Type: Application/Octet-Stream, Size: 85559 bytes --]

[-- Attachment #5: net_42.mbox --]
[-- Type: Application/Octet-Stream, Size: 97439 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-08-27 16:34   ` David Miller
@ 2015-09-28 14:04     ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2015-09-28 14:04 UTC (permalink / raw)
  To: David Miller; +Cc: luis.henriques, stable

On Thu, Aug 27, 2015 at 09:34:44AM -0700, David Miller wrote:
> From: Luis Henriques <luis.henriques@canonical.com>
> Date: Thu, 27 Aug 2015 14:35:57 +0100
> 
> > Hi David,
> > 
> > On Wed, Aug 26, 2015 at 11:05:12PM -0700, David Miller wrote:
> >> 
> >> Please queue up the following networking bug fixes for v3.12, v3.14, v3.18,
> >> and v4.1 -stable, respectively.
> >> 
> >> Thanks!
> > 
> > While going through these patches to pick those applicable to the 3.16
> > kernel, I believe I found an issue with the backport of 1c1bf34951e8
> > ("net/mlx4_core: Fix wrong index in propagating port change event to
> > VFs") into 3.14.
> > 
> > The 2nd hunk has the following:
> > 
> > @@ -583,7 +583,7 @@ static int mlx4_eq_int(struct mlx4_dev *dev, struct mlx4_eq *eq)
> >  					for (i = 0; i < dev->num_slaves; i++) {
> >  						if (i == mlx4_master_func_num(dev))
> >  							continue;
> > -						s_info = &priv->mfunc.master.vf_oper[slave].vport[port].state;
> > +						s_info = &priv->mfunc.master.vf_oper[slave].vport[i].state;
> > 
> > It should be:
> > 
> > -						s_info = &priv->mfunc.master.vf_oper[slave].vport[port].state;
> > +						s_info = &priv->mfunc.master.vf_oper[i].vport[port].state;
> > 
> > (the 'slave' index should be changed by 'i', not 'port').
> 
> Sorry, you are definitely correct.  I hope the v3.14 -stable maintain
> catches this, thanks!

Now fixed, thanks.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-08-27  6:05 David Miller
  2015-08-27  7:29 ` Jiri Slaby
  2015-08-27 13:35 ` Luis Henriques
@ 2015-09-26 19:21 ` Greg KH
  2 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2015-09-26 19:21 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Wed, Aug 26, 2015 at 11:05:12PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v3.12, v3.14, v3.18,
> and v4.1 -stable, respectively.
> 
> Thanks!




Sorry for the long delay, my fault, now queued up, thanks.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-08-27 13:35 ` Luis Henriques
@ 2015-08-27 16:34   ` David Miller
  2015-09-28 14:04     ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2015-08-27 16:34 UTC (permalink / raw)
  To: luis.henriques; +Cc: stable

From: Luis Henriques <luis.henriques@canonical.com>
Date: Thu, 27 Aug 2015 14:35:57 +0100

> Hi David,
> 
> On Wed, Aug 26, 2015 at 11:05:12PM -0700, David Miller wrote:
>> 
>> Please queue up the following networking bug fixes for v3.12, v3.14, v3.18,
>> and v4.1 -stable, respectively.
>> 
>> Thanks!
> 
> While going through these patches to pick those applicable to the 3.16
> kernel, I believe I found an issue with the backport of 1c1bf34951e8
> ("net/mlx4_core: Fix wrong index in propagating port change event to
> VFs") into 3.14.
> 
> The 2nd hunk has the following:
> 
> @@ -583,7 +583,7 @@ static int mlx4_eq_int(struct mlx4_dev *dev, struct mlx4_eq *eq)
>  					for (i = 0; i < dev->num_slaves; i++) {
>  						if (i == mlx4_master_func_num(dev))
>  							continue;
> -						s_info = &priv->mfunc.master.vf_oper[slave].vport[port].state;
> +						s_info = &priv->mfunc.master.vf_oper[slave].vport[i].state;
> 
> It should be:
> 
> -						s_info = &priv->mfunc.master.vf_oper[slave].vport[port].state;
> +						s_info = &priv->mfunc.master.vf_oper[i].vport[port].state;
> 
> (the 'slave' index should be changed by 'i', not 'port').

Sorry, you are definitely correct.  I hope the v3.14 -stable maintain
catches this, thanks!

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-08-27  6:05 David Miller
  2015-08-27  7:29 ` Jiri Slaby
@ 2015-08-27 13:35 ` Luis Henriques
  2015-08-27 16:34   ` David Miller
  2015-09-26 19:21 ` Greg KH
  2 siblings, 1 reply; 213+ messages in thread
From: Luis Henriques @ 2015-08-27 13:35 UTC (permalink / raw)
  To: David Miller; +Cc: stable

Hi David,

On Wed, Aug 26, 2015 at 11:05:12PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for v3.12, v3.14, v3.18,
> and v4.1 -stable, respectively.
> 
> Thanks!

While going through these patches to pick those applicable to the 3.16
kernel, I believe I found an issue with the backport of 1c1bf34951e8
("net/mlx4_core: Fix wrong index in propagating port change event to
VFs") into 3.14.

The 2nd hunk has the following:

@@ -583,7 +583,7 @@ static int mlx4_eq_int(struct mlx4_dev *dev, struct mlx4_eq *eq)
 					for (i = 0; i < dev->num_slaves; i++) {
 						if (i == mlx4_master_func_num(dev))
 							continue;
-						s_info = &priv->mfunc.master.vf_oper[slave].vport[port].state;
+						s_info = &priv->mfunc.master.vf_oper[slave].vport[i].state;

It should be:

-						s_info = &priv->mfunc.master.vf_oper[slave].vport[port].state;
+						s_info = &priv->mfunc.master.vf_oper[i].vport[port].state;

(the 'slave' index should be changed by 'i', not 'port').

Cheers,
--
Lu�s

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-08-27  6:05 David Miller
@ 2015-08-27  7:29 ` Jiri Slaby
  2015-08-27 13:35 ` Luis Henriques
  2015-09-26 19:21 ` Greg KH
  2 siblings, 0 replies; 213+ messages in thread
From: Jiri Slaby @ 2015-08-27  7:29 UTC (permalink / raw)
  To: David Miller, stable

On 08/27/2015, 08:05 AM, David Miller wrote:
> Please queue up the following networking bug fixes for v3.12, v3.14, v3.18,
> and v4.1 -stable, respectively.

Great, applied to 3.12. Thanks!

-- 
js
suse labs

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2015-08-27  6:05 David Miller
  2015-08-27  7:29 ` Jiri Slaby
                   ` (2 more replies)
  0 siblings, 3 replies; 213+ messages in thread
From: David Miller @ 2015-08-27  6:05 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 118 bytes --]


Please queue up the following networking bug fixes for v3.12, v3.14, v3.18,
and v4.1 -stable, respectively.

Thanks!

[-- Attachment #2: net_312.mbox --]
[-- Type: Application/Octet-Stream, Size: 57876 bytes --]

[-- Attachment #3: net_314.mbox --]
[-- Type: Application/Octet-Stream, Size: 67661 bytes --]

[-- Attachment #4: net_318.mbox --]
[-- Type: Application/Octet-Stream, Size: 82034 bytes --]

[-- Attachment #5: net_41.mbox --]
[-- Type: Application/Octet-Stream, Size: 111930 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-07-03 22:31 David Miller
@ 2015-07-04  3:04 ` Greg KH
  0 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2015-07-04  3:04 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Fri, Jul 03, 2015 at 03:31:36PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 3.14, 3.18,
> 4.0, and 4.1 -stable, respectively.

All queued up for the kernels I care about thanks.

Oh, no need to do any more 4.0-stable patches anymore, after this kernel
it's going to be end-of-life.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2015-07-03 22:31 David Miller
  2015-07-04  3:04 ` Greg KH
  0 siblings, 1 reply; 213+ messages in thread
From: David Miller @ 2015-07-03 22:31 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 113 bytes --]


Please queue up the following networking bug fixes for 3.14, 3.18,
4.0, and 4.1 -stable, respectively.

Thanks!

[-- Attachment #2: net_314.mbox --]
[-- Type: Application/Octet-Stream, Size: 33801 bytes --]

[-- Attachment #3: net_318.mbox --]
[-- Type: Application/Octet-Stream, Size: 55616 bytes --]

[-- Attachment #4: net_40.mbox --]
[-- Type: Application/Octet-Stream, Size: 64817 bytes --]

[-- Attachment #5: net_41.mbox --]
[-- Type: Application/Octet-Stream, Size: 64778 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-06-10  3:01 David Miller
  2015-06-10 13:26 ` Jiri Slaby
@ 2015-06-19 18:03 ` Greg KH
  1 sibling, 0 replies; 213+ messages in thread
From: Greg KH @ 2015-06-19 18:03 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, Jun 09, 2015 at 08:01:04PM -0700, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 3.12.x, 3.14.x,
> 3.18.x, and 4.0.x -stable, respectively.

All queued up, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe stable" in

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-06-10  3:01 David Miller
@ 2015-06-10 13:26 ` Jiri Slaby
  2015-06-19 18:03 ` Greg KH
  1 sibling, 0 replies; 213+ messages in thread
From: Jiri Slaby @ 2015-06-10 13:26 UTC (permalink / raw)
  To: David Miller, stable

On 06/10/2015, 05:01 AM, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 3.12.x, 3.14.x,
> 3.18.x, and 4.0.x -stable, respectively.

Applied to 3.12. Thanks!

-- 
js
suse labs

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2015-06-10  3:01 David Miller
  2015-06-10 13:26 ` Jiri Slaby
  2015-06-19 18:03 ` Greg KH
  0 siblings, 2 replies; 213+ messages in thread
From: David Miller @ 2015-06-10  3:01 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 128 bytes --]


Please queue up the following networking bug fixes for 3.12.x, 3.14.x,
3.18.x, and 4.0.x -stable, respectively.

Thanks a lot!

[-- Attachment #2: net_312.mbox --]
[-- Type: Application/Octet-Stream, Size: 20361 bytes --]

[-- Attachment #3: net_314.mbox --]
[-- Type: Application/Octet-Stream, Size: 33194 bytes --]

[-- Attachment #4: net_318.mbox --]
[-- Type: Application/Octet-Stream, Size: 69475 bytes --]

[-- Attachment #5: net_40.mbox --]
[-- Type: Application/Octet-Stream, Size: 72303 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] NETWORKING
  2015-05-05 17:34 [PATCHES] NETWORKING David Miller
  2015-05-06  6:57 ` Jiri Slaby
  2015-05-08 11:14 ` Greg KH
@ 2015-05-08 14:42 ` Greg KH
  2 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2015-05-08 14:42 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, May 05, 2015 at 01:34:00PM -0400, David Miller wrote:
> 
> Greg, I know you said to skip v3.19 going forward, but the ping unhashing crash
> fix might justify one more release so I present it here for your consideration.
> 
> Please queue up the following networking bug fixes for v3.12, v3.14, v3.18,
> v3.19, and v4.0, respectively.

Applied to the trees I care about.  No need to do 3.19 patches anymore,
this really is going to be the last one I release for that branch :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] NETWORKING
  2015-05-05 17:34 [PATCHES] NETWORKING David Miller
  2015-05-06  6:57 ` Jiri Slaby
@ 2015-05-08 11:14 ` Greg KH
  2015-05-08 14:42 ` Greg KH
  2 siblings, 0 replies; 213+ messages in thread
From: Greg KH @ 2015-05-08 11:14 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Tue, May 05, 2015 at 01:34:00PM -0400, David Miller wrote:
> 
> Greg, I know you said to skip v3.19 going forward, but the ping unhashing crash
> fix might justify one more release so I present it here for your consideration.

Thanks, I've included the 3.19 patches in a last release now.

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] NETWORKING
  2015-05-05 17:34 [PATCHES] NETWORKING David Miller
@ 2015-05-06  6:57 ` Jiri Slaby
  2015-05-08 11:14 ` Greg KH
  2015-05-08 14:42 ` Greg KH
  2 siblings, 0 replies; 213+ messages in thread
From: Jiri Slaby @ 2015-05-06  6:57 UTC (permalink / raw)
  To: David Miller, stable

On 05/05/2015, 07:34 PM, David Miller wrote:
> Please queue up the following networking bug fixes for v3.12, v3.14, v3.18,
> v3.19, and v4.0, respectively.

Thanks, now applied to 3.12.

-- 
js
suse labs

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] NETWORKING
@ 2015-05-05 17:34 David Miller
  2015-05-06  6:57 ` Jiri Slaby
                   ` (2 more replies)
  0 siblings, 3 replies; 213+ messages in thread
From: David Miller @ 2015-05-05 17:34 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 284 bytes --]


Greg, I know you said to skip v3.19 going forward, but the ping unhashing crash
fix might justify one more release so I present it here for your consideration.

Please queue up the following networking bug fixes for v3.12, v3.14, v3.18,
v3.19, and v4.0, respectively.

Thanks a lot!

[-- Attachment #2: net_312.mbox --]
[-- Type: Application/Octet-Stream, Size: 1041 bytes --]

[-- Attachment #3: net_314.mbox --]
[-- Type: Application/Octet-Stream, Size: 1041 bytes --]

[-- Attachment #4: net_318.mbox --]
[-- Type: Application/Octet-Stream, Size: 7287 bytes --]

[-- Attachment #5: net_319.mbox --]
[-- Type: Application/Octet-Stream, Size: 11950 bytes --]

[-- Attachment #6: net_40.mbox --]
[-- Type: Application/Octet-Stream, Size: 11950 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-04-27  9:23 ` Jiri Slaby
@ 2015-05-04 19:53   ` Ben Hutchings
  0 siblings, 0 replies; 213+ messages in thread
From: Ben Hutchings @ 2015-05-04 19:53 UTC (permalink / raw)
  To: Jiri Slaby; +Cc: stable, David Miller

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

On Mon, 2015-04-27 at 11:23 +0200, Jiri Slaby wrote:
> On 04/21/2015, 08:30 PM, David Miller wrote:
> > 
> > Please queue up the following networking bug fixes for 3.12, 3.14, 3.18,
> > 3.19, and 4.0 -stable, respectively.
> 
> FWIW if anyone else wants to put there the missing "commit upstream"
> tags for some patches too, I dug them out:
[...]

Thanks for these.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-04-29  4:48 [PATCHES] Networking David Miller
  2015-04-29 11:09 ` Greg KH
@ 2015-04-30 12:25 ` Jiri Slaby
  1 sibling, 0 replies; 213+ messages in thread
From: Jiri Slaby @ 2015-04-30 12:25 UTC (permalink / raw)
  To: David Miller, stable

On 04/29/2015, 06:48 AM, David Miller wrote:
> 
> Please queue up the following networking bug fixes for
> 3.12, 3.14, 3.18, 3.19, and 4.0 -stable, respectively.

Thanks, now applied to 3.12.

-- 
js
suse labs

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-04-29 11:09 ` Greg KH
@ 2015-04-29 16:03   ` David Miller
  0 siblings, 0 replies; 213+ messages in thread
From: David Miller @ 2015-04-29 16:03 UTC (permalink / raw)
  To: gregkh; +Cc: stable

From: Greg KH <gregkh@linuxfoundation.org>
Date: Wed, 29 Apr 2015 13:09:50 +0200

> No need to make up 3.19 patches anymore, this is going to be the last
> 3.19 kernel I release.

Ok thanks for the info.

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
  2015-04-29  4:48 [PATCHES] Networking David Miller
@ 2015-04-29 11:09 ` Greg KH
  2015-04-29 16:03   ` David Miller
  2015-04-30 12:25 ` Jiri Slaby
  1 sibling, 1 reply; 213+ messages in thread
From: Greg KH @ 2015-04-29 11:09 UTC (permalink / raw)
  To: David Miller; +Cc: stable

On Wed, Apr 29, 2015 at 12:48:05AM -0400, David Miller wrote:
> 
> Please queue up the following networking bug fixes for
> 3.12, 3.14, 3.18, 3.19, and 4.0 -stable, respectively.

I've queued up the 3.14, 3.19, and 4.0 patches, and took a few for 3.10
that looked "safe".

No need to make up 3.19 patches anymore, this is going to be the last
3.19 kernel I release.

thanks again,

greg k-h

^ permalink raw reply	[flat|nested] 213+ messages in thread

* [PATCHES] Networking
@ 2015-04-29  4:48 David Miller
  2015-04-29 11:09 ` Greg KH
  2015-04-30 12:25 ` Jiri Slaby
  0 siblings, 2 replies; 213+ messages in thread
From: David Miller @ 2015-04-29  4:48 UTC (permalink / raw)
  To: stable

[-- Attachment #1: Type: Text/Plain, Size: 126 bytes --]


Please queue up the following networking bug fixes for
3.12, 3.14, 3.18, 3.19, and 4.0 -stable, respectively.

Thanks a lot!

[-- Attachment #2: net_312.mbox --]
[-- Type: Application/Octet-Stream, Size: 16831 bytes --]

[-- Attachment #3: net_314.mbox --]
[-- Type: Application/Octet-Stream, Size: 16810 bytes --]

[-- Attachment #4: net_318.mbox --]
[-- Type: Application/Octet-Stream, Size: 19297 bytes --]

[-- Attachment #5: net_319.mbox --]
[-- Type: Application/Octet-Stream, Size: 25055 bytes --]

[-- Attachment #6: net_40.mbox --]
[-- Type: Application/Octet-Stream, Size: 29319 bytes --]

^ permalink raw reply	[flat|nested] 213+ messages in thread

* Re: [PATCHES] Networking
       [not found] <20150421.143012.2106864724544609194.davem@davemloft.net>
@ 2015-04-27  9:23 ` Jiri Slaby
  2015-05-04 19:53   ` Ben Hutchings
  0 siblings, 1 reply; 213+ messages in thread
From: Jiri Slaby @ 2015-04-27  9:23 UTC (permalink / raw)
  To: stable; +Cc: David Miller

On 04/21/2015, 08:30 PM, David Miller wrote:
> 
> Please queue up the following networking bug fixes for 3.12, 3.14, 3.18,
> 3.19, and 4.0 -stable, respectively.

FWIW if anyone else wants to put there the missing "commit upstream"
tags for some patches too, I dug them out:
    gianfar: Carefully free skbs in functions called by netpoll.
    commit c9974ad4aeb36003860100221a594f3c0ccc3f78 upstream.

    benet: Call dev_kfree_skby_any instead of kfree_skb.
    commit d8ec2c02caa3515f35d6c33eedf529394c419298 upstream.

    ixgb: Call dev_kfree_skby_any instead of dev_kfree_skb.
    commit f7e79913a1d6a6139211ead3b03579b317d25a1f upstream.

    tg3: Call dev_kfree_skby_any instead of dev_kfree_skb.
    commit 497a27b9e1bcf6dbaea7a466cfcd866927e1b431 upstream.

    bnx2: Call dev_kfree_skby_any instead of dev_kfree_skb.
    commit f458b2ee93ee3606c83f76213fbe49e026bac754 upstream.

    bonding: Call dev_kfree_skby_any instead of kfree_skb.
    commit 2bb77ab42a6a40162a367b80394b96bb756ad5f1 upstream.

    r8169: Call dev_kfree_skby_any instead of dev_kfree_skb.
    commit 989c9ba104d9ce53c1ca918262f3fdfb33aca12a upstream.

    8139too: Call dev_kfree_skby_any instead of dev_kfree_skb.
    commit a2ccd2e4bd70122523a7bf21cec4dd6e34427089 upstream.

    8139cp: Call dev_kfree_skby_any instead of kfree_skb.
    commit 508f81d517ed1f3f0197df63ea7ab5cd91b6f3b3 upstream.


thanks,
-- 
js
suse labs

^ permalink raw reply	[flat|nested] 213+ messages in thread

end of thread, back to index

Thread overview: 213+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-21  6:37 [PATCHES] Networking David Miller
2019-05-22  6:36 ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2019-06-08 23:27 David Miller
2019-06-09  7:26 ` Greg KH
2019-06-09 19:42   ` David Miller
2019-05-14 19:58 David Miller
2019-05-15  6:02 ` Greg KH
2019-05-04  7:01 David Miller
2019-05-04  7:34 ` Greg KH
2019-04-30  2:06 David Miller
2019-04-30  7:53 ` Greg KH
2019-04-18 22:53 David Miller
2019-04-23 20:06 ` Greg KH
2019-04-10  3:55 David Miller
2019-04-10 15:35 ` Sasha Levin
2019-03-28 19:24 David Miller
2019-03-28 20:55 ` Greg KH
2019-03-28 21:51   ` Greg KH
2019-03-28 23:18     ` David Miller
2019-03-29  6:18       ` Greg KH
2019-03-15  1:47 David Miller
2019-03-15  6:30 ` Greg KH
2019-03-19 13:03   ` Greg KH
2019-03-07 22:47 David Miller
2019-03-08  6:38 ` Greg KH
2019-02-24  5:18 David Miller
2019-02-24  7:52 ` Greg KH
2019-02-20 20:42 David Miller
2019-02-21  3:08 ` Sasha Levin
2019-02-21  7:21 ` Greg KH
2019-02-09 23:21 David Miller
2019-02-10 12:21 ` Greg KH
2019-02-01 21:45 David Miller
2019-02-02  9:55 ` Greg KH
2019-01-26  0:18 David Miller
2019-01-26  9:29 ` Greg KH
2019-01-21 23:28 David Miller
2019-01-22  7:18 ` Greg KH
2019-01-23  7:33 ` Greg KH
2019-01-20 19:12 David Miller
2019-01-21  8:00 ` Greg KH
2019-01-04 18:17 David Miller
2019-01-04 18:48 ` Greg KH
2018-12-12  6:31 David Miller
2018-12-13  9:53 ` Greg KH
2018-12-03  7:01 David Miller
2018-12-03  9:13 ` Greg KH
2018-11-21  3:49 David Miller
2018-11-21 17:49 ` Greg KH
2018-11-02  3:55 David Miller
2018-11-02  5:27 ` Greg KH
2018-09-24 16:46 David Miller
2018-09-26  9:32 ` Greg KH
2018-09-18 16:14 David Miller
2018-09-20  5:25 ` Greg KH
2018-09-11  6:15 David Miller
2018-09-11  8:29 ` Greg KH
2018-08-17 19:32 David Miller
2018-08-18  9:43 ` Greg KH
2018-08-04  5:05 David Miller
2018-08-04  7:33 ` Greg KH
2018-08-01  5:32 David Miller
2018-08-01  6:20 ` Greg KH
2018-07-26 23:50 David Miller
2018-07-27  0:06 ` Eric Dumazet
2018-07-27  6:34 ` Greg KH
2018-07-23  3:51 David Miller
2018-07-23  6:21 ` Greg KH
2018-07-18 23:35 David Miller
2018-07-19  6:33 ` Greg KH
2018-06-20 12:37 David Miller
2018-06-21 21:10 ` Greg KH
2018-06-24 11:20   ` Greg KH
2018-06-08  2:18 David Miller
2018-06-08  4:52 ` Greg KH
2018-05-15 20:50 David Miller
2018-05-16  8:40 ` Greg KH
2018-04-26 18:38 David Miller
2018-04-26 18:50 ` Greg KH
2018-04-13 17:47 David Miller
2018-04-14 14:04 ` Greg KH
2018-04-10 19:39 David Miller
2018-04-10 21:26 ` Greg KH
2018-03-28 15:35 David Miller
2018-03-28 15:40 ` Willy Tarreau
2018-03-28 15:46   ` David Miller
2018-03-28 16:36     ` Greg KH
2018-03-28 16:49 ` Greg KH
2018-03-07  2:28 David Miller
2018-03-07  3:30 ` Greg KH
2018-02-06 20:19 David Miller
2018-02-07 19:39 ` Greg KH
2018-01-28 16:22 David Miller
2018-01-28 16:39 ` Greg KH
2018-01-12 21:12 David Miller
2018-01-13  9:54 ` Greg KH
2017-12-31  4:15 David Miller
2017-12-31 10:14 ` Greg KH
2017-12-12 15:44 David Miller
2017-12-14 17:51 ` Greg KH
2017-11-20 11:47 David Miller
2017-11-21 14:04 ` Greg KH
2017-11-14  6:36 David Miller
2017-11-16 14:12 ` Greg KH
2017-10-09  4:02 David Miller
2017-10-09  7:34 ` Greg KH
2017-10-09  7:56   ` Greg KH
2017-10-09 16:55     ` David Miller
2017-10-09 19:04       ` Greg KH
2017-10-09 22:54         ` David Miller
2017-10-10 14:10           ` Greg KH
2017-09-15  4:57 David Miller
2017-09-15  6:24 ` Greg KH
2018-06-07  7:00 ` Jiri Slaby
2018-06-07  9:21   ` Greg KH
2018-06-07 10:47   ` Ido Schimmel
2018-06-07 10:52     ` Greg KH
2018-07-05 16:15     ` Greg KH
2018-07-05 16:42       ` Ido Schimmel
2017-08-24  3:24 David Miller
2017-08-25  0:55 ` Greg KH
2017-08-11  5:25 David Miller
2017-08-11 16:22 ` Greg KH
2017-08-08 23:21 David Miller
2017-08-08 23:30 ` Greg KH
2017-07-17 16:44 David Miller
2017-07-17 19:23 ` Greg KH
2017-07-19 10:27   ` Greg KH
2017-06-29 16:19 David Miller
2017-06-29 17:34 ` Greg KH
2017-05-30 23:14 David Miller
2017-05-31  0:18 ` Greg KH
2017-05-11  2:41 David Miller
2017-05-11 13:10 ` Greg KH
2017-05-22 10:16 ` Greg KH
2017-04-28 19:41 David Miller
2017-04-29  6:23 ` Greg KH
2017-03-25  7:53 David Miller
2017-03-25  9:26 ` Thomas Backlund
2017-03-25 17:38   ` David Miller
2017-03-26 18:47     ` Thomas Backlund
2017-03-27 16:19     ` Greg KH
2017-03-17  1:48 David Miller
2017-03-18 14:13 ` Greg KH
2017-02-23 19:54 David Miller
2017-02-23 20:19 ` Greg KH
2017-02-13 17:15 David Miller
2017-02-15 17:21 ` Greg KH
2017-01-31 21:50 [PATCHES] networking David Miller
2017-02-01  8:10 ` Greg KH
2017-01-12 18:55 [PATCHES] Networking David Miller
2017-01-12 20:40 ` Greg KH
2016-12-07 23:43 David Miller
2016-12-08  6:34 ` Greg KH
2016-11-18  2:59 David Miller
2016-11-18 10:36 ` Greg KH
2016-11-09 17:19 David Miller
2016-11-10 15:50 ` Greg KH
2016-09-21  5:07 David Miller
2016-09-21  9:23 ` Greg KH
2016-08-12  0:50 David Miller
2016-08-12  7:37 ` Greg KH
2016-07-13 21:43 David Miller
2016-07-13 22:38 ` Greg KH
2016-07-06  5:02 David Miller
2016-07-07  0:35 ` Greg KH
2016-06-17  7:03 David Miller
2016-06-18  1:01 ` Greg KH
2016-05-16 16:35 David Miller
2016-05-16 21:50 ` Greg KH
2016-04-15  4:45 David Miller
2016-04-16 17:49 ` Greg KH
2016-02-29 21:56 David Miller
2016-02-29 22:45 ` Greg KH
2016-01-27  2:00 David Miller
2016-01-27  6:35 ` Greg KH
2015-12-22 21:51 David Miller
2016-01-19  5:20 ` Greg KH
2016-01-19 12:00   ` Josh Boyer
2016-01-19 13:29     ` Josh Boyer
2016-01-19 17:39       ` Greg KH
2016-01-19 17:41         ` Josh Boyer
2015-12-10 19:37 David Miller
2015-12-11 16:49 ` Greg KH
2015-11-13 21:38 David Miller
2015-11-14 15:59 ` Jiri Slaby
2015-11-15 17:55   ` David Miller
2015-12-06  5:25 ` Greg KH
2015-10-21  3:51 David Miller
2015-10-23 16:25 ` Greg KH
2015-09-29  4:54 David Miller
2015-09-30  3:33 ` Greg KH
2015-08-27  6:05 David Miller
2015-08-27  7:29 ` Jiri Slaby
2015-08-27 13:35 ` Luis Henriques
2015-08-27 16:34   ` David Miller
2015-09-28 14:04     ` Greg KH
2015-09-26 19:21 ` Greg KH
2015-07-03 22:31 David Miller
2015-07-04  3:04 ` Greg KH
2015-06-10  3:01 David Miller
2015-06-10 13:26 ` Jiri Slaby
2015-06-19 18:03 ` Greg KH
2015-05-05 17:34 [PATCHES] NETWORKING David Miller
2015-05-06  6:57 ` Jiri Slaby
2015-05-08 11:14 ` Greg KH
2015-05-08 14:42 ` Greg KH
2015-04-29  4:48 [PATCHES] Networking David Miller
2015-04-29 11:09 ` Greg KH
2015-04-29 16:03   ` David Miller
2015-04-30 12:25 ` Jiri Slaby
     [not found] <20150421.143012.2106864724544609194.davem@davemloft.net>
2015-04-27  9:23 ` Jiri Slaby
2015-05-04 19:53   ` Ben Hutchings

Stable Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/stable/0 stable/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 stable stable/ https://lore.kernel.org/stable \
		stable@vger.kernel.org stable@archiver.kernel.org
	public-inbox-index stable


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.stable


AGPL code for this site: git clone https://public-inbox.org/ public-inbox