* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2016-05-05 0:30 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Kangjie Lu, Nicolas Dichtel
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/core/rtnetlink.c
between commit:
5f8e44741f9f ("net: fix infoleak in rtnetlink")
from the net tree and commit:
270cb4d05b29 ("rtnl: align nlattr properly when needed")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/core/rtnetlink.c
index 65763c29f845,d471f097c739..000000000000
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@@ -1180,17 -1173,15 +1173,17 @@@ static noinline_for_stack int rtnl_fill
static int rtnl_fill_link_ifmap(struct sk_buff *skb, struct net_device *dev)
{
- struct rtnl_link_ifmap map = {
- .mem_start = dev->mem_start,
- .mem_end = dev->mem_end,
- .base_addr = dev->base_addr,
- .irq = dev->irq,
- .dma = dev->dma,
- .port = dev->if_port,
- };
+ struct rtnl_link_ifmap map;
+
+ memset(&map, 0, sizeof(map));
+ map.mem_start = dev->mem_start;
+ map.mem_end = dev->mem_end;
+ map.base_addr = dev->base_addr;
+ map.irq = dev->irq;
+ map.dma = dev->dma;
+ map.port = dev->if_port;
+
- if (nla_put(skb, IFLA_MAP, sizeof(map), &map))
+ if (nla_put_64bit(skb, IFLA_MAP, sizeof(map), &map, IFLA_PAD))
return -EMSGSIZE;
return 0;
^ permalink raw reply
* Re: [RESEND PATCH 2/3] fs: poll/select/recvmmsg: use timespec64 for timeout events
From: John Stultz @ 2016-05-05 0:01 UTC (permalink / raw)
To: Andrew Morton
Cc: Eliezer Tamir, Arnd Bergmann, y2038 Mailman List, netdev, lkml,
Oleg Nesterov, Arjan van de Ven, Alexander Viro,
linux-fsdevel@vger.kernel.org, Thomas Gleixner, Linus Torvalds,
David S. Miller, Deepa Dinamani
In-Reply-To: <20160504165115.e0247881921fdcd0af4a394c@linux-foundation.org>
On Wed, May 4, 2016 at 4:51 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 04 May 2016 23:08:11 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>
>> > But I'm less comfortable making the call on this one. It looks
>> > relatively straight forward, but it would be good to have maintainer
>> > acks before I add it to my tree.
>>
>> Agreed. Feel free to add my
>>
>> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
>>
>> at least (whoever picks it up).
>
> In reply to [1/3] John said
>
> : Looks ok at the first glance. I've queued these up for testing,
> : however I only got #1 and #3 of the set. Are you hoping these two
> : patches will go through tip/timers/core or are you looking for acks so
> : they can go via another tree?
>
> However none of the patches are in linux-next.
>
> John had qualms about [2/3], but it looks like a straightforward
> substitution in areas which will get plenty of testing
Yea. My main concern is just not stepping on any other maintainers toes.
> I'll grab the patches for now to get them some external testing.
I'd be just as happy if the set went through you Andrew.
For the set: Acked-by: John Stultz <john.stultz@linaro.org>
thanks
-john
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* [PATCH net-next] cnic: call cp->stop_hw() in cnic_start_hw() on allocation failure
From: Jon Maxwell @ 2016-05-04 23:55 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, jmaxwell, ivecera, Jon Maxwell
We recently had a system crash in the cnic module. Vmcore analysis confirmed
that "ip link up" was executed which failed due to an allocation failure
because of memory fragmentation. Futher analysis revealed that the cnic irq
vector was still allocated after the "ip link up" that failed. When
"ip link down" was executed it called free_msi_irqs() which crashed the system
because the cnic irq was still inuse.
PANIC: "kernel BUG at drivers/pci/msi.c:411!"
The code execution was:
cnic_netdev_event()
if (event == NETDEV_UP) {
.
.
▹ if (!cnic_start_hw(dev))
cnic_start_hw()
calls cnic_cm_open() which failed with -ENOMEM
cnic_start_hw() then took the err1 path:
err1:↩
cp->free_resc(dev);↩ <---- frees resources but not irq vector
pci_dev_put(dev->pcidev);↩
return err;↩
}↩
This returns control back to cnic_netdev_event() but now the cnic irq vector
is still allocated even although cnic_cm_open() failed. The next
"ip link down" while trigger the crash.
The cnic_start_hw() routine is not handling the allocation failure correctly.
Fix this by checking whether CNIC_DRV_STATE_HANDLES_IRQ flag is set indicating
that the hardware has been started in cnic_start_hw(). If it has then call
cp->stop_hw() which frees the cnic irq vector and cnic resources. Otherwise
just maintain the previous behaviour and free cnic resources.
I reproduced this by injecting an ENOMEM error into cnic_cm_alloc_mem()s return
code.
# ip link set dev enpX down
# ip link set dev enpX up <--- hit's allocation failure
# ip link set dev enpX down <--- crashes here
With this patch I confirmed there was no crash in the reproducer.
Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
---
drivers/net/ethernet/broadcom/cnic.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/cnic.c b/drivers/net/ethernet/broadcom/cnic.c
index b69dc58..b1d2ac8 100644
--- a/drivers/net/ethernet/broadcom/cnic.c
+++ b/drivers/net/ethernet/broadcom/cnic.c
@@ -5350,7 +5350,10 @@ static int cnic_start_hw(struct cnic_dev *dev)
return 0;
err1:
- cp->free_resc(dev);
+ if (ethdev->drv_state & CNIC_DRV_STATE_HANDLES_IRQ)
+ cp->stop_hw(dev);
+ else
+ cp->free_resc(dev);
pci_dev_put(dev->pcidev);
return err;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [RESEND PATCH 2/3] fs: poll/select/recvmmsg: use timespec64 for timeout events
From: Andrew Morton @ 2016-05-04 23:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arjan van de Ven, Eliezer Tamir, y2038, netdev, lkml,
Oleg Nesterov, John Stultz, Deepa Dinamani,
linux-fsdevel@vger.kernel.org, Thomas Gleixner, Linus Torvalds,
David S. Miller, Alexander Viro
In-Reply-To: <4256673.7Gok2HNpOM@wuerfel>
On Wed, 04 May 2016 23:08:11 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
> > But I'm less comfortable making the call on this one. It looks
> > relatively straight forward, but it would be good to have maintainer
> > acks before I add it to my tree.
>
> Agreed. Feel free to add my
>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
>
> at least (whoever picks it up).
In reply to [1/3] John said
: Looks ok at the first glance. I've queued these up for testing,
: however I only got #1 and #3 of the set. Are you hoping these two
: patches will go through tip/timers/core or are you looking for acks so
: they can go via another tree?
However none of the patches are in linux-next.
John had qualms about [2/3], but it looks like a straightforward
substitution in areas which will get plenty of testing
I'll grab the patches for now to get them some external testing.
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions
From: John Stultz @ 2016-05-04 23:45 UTC (permalink / raw)
To: Dean Jenkins
Cc: Guodong Xu, lkml, Mark Craske, David S. Miller, YongQin Liu,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Ivan Vecera, David B. Robins
In-Reply-To: <5728837D.60702-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
On Tue, May 3, 2016 at 3:54 AM, Dean Jenkins <Dean_Jenkins-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org> wrote:
> On 03/05/16 11:04, Guodong Xu wrote:
>>
>> did you test on ARM 64-bit system or ARM 32-bit? I ask because HiKey
>> is an ARM 64-bit system. I suggest we should be careful on that. I saw
>> similar issues when transferring to a 64-bit system in other net
>> drivers.
>
> We used 32-bit ARM and never tested on 64-bit ARM so I suggest that the
> commits need to be reviewed with 64-bit OS in mind.
>>
>>
>> Do you have any suggestion on this regard?
>
> Try testing on a Linux PC x86 32-bit OS which has has a kernel containing my
> ASIX commits. This will help to confirm whether the failure is related to
> 32-bit or 64-bit OS. Then try with Linux PC x86 64-bit OS, this should fail
> otherwise it points to something specific in your ARM 64-bit platform.
Just as a sample point, I have managed to reproduce exactly this issue
on an x86_64 system by simply scp'ing a large file.
[ 417.819276] asix 1-5:1.0 eth1: asix_rx_fixup() Data Header
synchronisation was lost, remaining 988
[ 417.823415] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
0xef830347, offset 4
[ 417.827502] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
0x31e2b348, offset 4
[ 417.843779] asix 1-5:1.0 eth1: asix_rx_fixup() Data Header
synchronisation was lost, remaining 988
[ 417.847921] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
0x8af91035, offset 4
[ 417.852004] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
0x8521fa03, offset 4
[ 418.273394] asix 1-5:1.0 eth1: asix_rx_fixup() Data Header
synchronisation was lost, remaining 988
[ 418.277532] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
0x33cd9c7c, offset 4
[ 418.281683] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
0x3d850896, offset 4
[ 418.286227] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
0x86443357, offset 4
[ 418.290319] asix 1-5:1.0 eth1: asix_rx_fixup() Bad Header Length
0xee6c81d1, offset 4
I don't have any 32bit x86 installs around so I'm not sure I can easly
test there, but its clear its not arm64 specific.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [net-next] MAINTAINERS: Cleanup Intel Wired LAN maintainers list
From: Jeff Kirsher @ 2016-05-04 22:49 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
With the recent "retirements" and other changes, make the maintainers
list a lot less confusing and a bit more straight forward.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Acked-by: Shannon Nelson <sln@onemain.com>
---
MAINTAINERS | 7 -------
1 file changed, 7 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2b74fde..e425912 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5748,13 +5748,6 @@ F: drivers/char/hw_random/ixp4xx-rng.c
INTEL ETHERNET DRIVERS
M: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-R: Jesse Brandeburg <jesse.brandeburg@intel.com>
-R: Shannon Nelson <shannon.nelson@intel.com>
-R: Carolyn Wyborny <carolyn.wyborny@intel.com>
-R: Don Skidmore <donald.c.skidmore@intel.com>
-R: Bruce Allan <bruce.w.allan@intel.com>
-R: John Ronciak <john.ronciak@intel.com>
-R: Mitch Williams <mitch.a.williams@intel.com>
L: intel-wired-lan@lists.osuosl.org (moderated for non-subscribers)
W: http://www.intel.com/support/feedback.htm
W: http://e1000.sourceforge.net/
--
2.5.5
^ permalink raw reply related
* [PATCH net-next] tcp: two more missing bh disable
From: Eric Dumazet @ 2016-05-04 22:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20160504.170641.134283593327091145.davem@davemloft.net>
From: Eric Dumazet <edumazet@google.com>
percpu_counter only have protection against preemption.
TCP stack uses them possibly from BH, so we need BH protection
in contexts that could be run in process context
Fixes: c10d9310edf5 ("tcp: do not assume TCP code is non preemptible")
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/inet_connection_sock.c | 2 ++
net/ipv4/tcp_ipv4.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 7ce112aa3a7b50c8c2c97b4e59e86128f90fd7f6..fa8c39804bdbae867dd5c08f1e308202c1aa1c52 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -706,7 +706,9 @@ void inet_csk_destroy_sock(struct sock *sk)
sk_refcnt_debug_release(sk);
+ local_bh_disable();
percpu_counter_dec(sk->sk_prot->orphan_count);
+ local_bh_enable();
sock_put(sk);
}
EXPORT_SYMBOL(inet_csk_destroy_sock);
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 761bc492c5e3070212efe91c3940e4712d9d6ef6..a7ab9472d64560d86ea24ac1b6e1a7800f89989d 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1839,7 +1839,9 @@ void tcp_v4_destroy_sock(struct sock *sk)
tcp_free_fastopen_req(tp);
tcp_saved_syn_free(tp);
+ local_bh_disable();
sk_sockets_allocated_dec(sk);
+ local_bh_enable();
if (mem_cgroup_sockets_enabled && sk->sk_memcg)
sock_release_memcg(sk);
^ permalink raw reply related
* Re: [PATC net-next] tcp: must block bh in __inet_twsk_hashdance()
From: Eric Dumazet @ 2016-05-04 22:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20160504.170641.134283593327091145.davem@davemloft.net>
On Wed, 2016-05-04 at 17:06 -0400, David Miller wrote:
> I pushed them in by hand, they should really be there now.
>
> Thanks for letting me know.
Thanks David
Further tests show two additional missing local_bh_disable() protections
around percpu_counter_dec() and one sk_sockets_allocated_dec()
Will send the patch in few minutes.
^ permalink raw reply
* Re: [net-next 00/14][pull request] 10GbE Intel Wired LAN Driver Updates 2016-05-04
From: David Miller @ 2016-05-04 21:48 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene, john.ronciak
In-Reply-To: <1462379208-3997-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 4 May 2016 09:26:34 -0700
> This series contains updates to ixgbe, ixgbevf and traffic class helpers.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net 0/2] bnxt_en: 2 bug fixes.
From: David Miller @ 2016-05-04 21:12 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1462395404-21875-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Wed, 4 May 2016 16:56:42 -0400
> Fix crash on ppc64 due to missing memory barrier and restore multicast
> after reset.
Looks good, series applied, thanks.
^ permalink raw reply
* Re: [Y2038] [RESEND PATCH 2/3] fs: poll/select/recvmmsg: use timespec64 for timeout events
From: Arnd Bergmann @ 2016-05-04 21:08 UTC (permalink / raw)
To: y2038
Cc: John Stultz, Deepa Dinamani, netdev, lkml, Alexander Viro,
linux-fsdevel@vger.kernel.org, Thomas Gleixner, David S. Miller,
Linus Torvalds, Andrew Morton, Eliezer Tamir, Arjan van de Ven,
Oleg Nesterov
In-Reply-To: <CALAqxLVB8XiRrFKxK3GzBxw-CfEmC=Dh-CrTOEqT144ngZg-Dw@mail.gmail.com>
On Wednesday 04 May 2016 13:04:37 John Stultz wrote:
> On Wed, May 4, 2016 at 12:24 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> > struct timespec is not y2038 safe.
> > Even though timespec might be sufficient to represent
> > timeouts, use struct timespec64 here as the plan is to
> > get rid of all timespec reference in the kernel.
> >
> > The patch transitions the common functions:
> > poll_select_set_timeout() and select_estimate_accuracy()
> > to use timespec64. And, all the syscalls that use these
> > functions are transitioned in the same patch.
> >
> > The restart block parameters for poll uses monotonic time.
> > Use timespec64 here as well to assign timeout value. This
> > parameter in the restart block need not change because
> > this only holds the monotonic timestamp at which timeout
> > should occur. And, unsigned long data type should be big
> > enough for this timestamp.
> >
> > The system call interfaces will be handled in a separate
> > series.
> >
> > Compat interfaces need not change as timespec64 is an
> > alias to struct timespec on a 64 bit system.
> >
> > Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
> > Cc: Alexander Viro <viro@zeniv.linux.org.uk>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: netdev@vger.kernel.org
> > ---
> > Resending to include John and Thomas on this patch as well.
> > This is to include this patch also in John's tree.
> > This will let all 3 patches in the series to merged through the same tree.
> >
> > fs/eventpoll.c | 12 +++++-----
> > fs/select.c | 67 +++++++++++++++++++++++++++++-----------------------
> > include/linux/poll.h | 11 +++++----
> > net/socket.c | 8 ++++---
> > 4 files changed, 54 insertions(+), 44 deletions(-)
>
>
> So with the other two patches, I'm more comfortable queueing and
> sending through to Thomas.
Note that of course patch 3 depends on patch 2, otherwise it would
be a simple rename.
> But I'm less comfortable making the call on this one. It looks
> relatively straight forward, but it would be good to have maintainer
> acks before I add it to my tree.
Agreed. Feel free to add my
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
at least (whoever picks it up). The file hasn't changed much in the past
decade, these are all the people who did more than 1 patch for fs/select.c
in git history:
7 Al Viro
6 Eliezer Tamir
6 Arjan van de Ven
4 Andrew Morton
3 Linus Torvalds
3 Heiko Carstens
2 Vadim Lobanov
2 Roland McGrath
2 Oleg Nesterov
2 Jiri Slaby
2 Guillaume Knispel
2 Eric Dumazet
2 Dipankar Sarma
2 Alexey Dobriyan
adding a few more to Cc, maybe someone else finds the time to take a
second look.
Arnd
^ permalink raw reply
* Re: [PATCH next] drivers: fix dev->trans_start removal fallout
From: David Miller @ 2016-05-04 21:07 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <1462395367-16704-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Wed, 4 May 2016 22:56:07 +0200
> kbuild test robot reported a build failure on s390.
> While at it, also fix missing conversion in the tilera driver.
>
> Fixes: 9b36627acecd5792 ("net: remove dev->trans_start")
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied.
^ permalink raw reply
* Re: [PATCH next] bonding: update documentation section after dev->trans_start removal
From: David Miller @ 2016-05-04 21:07 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <1462395107-18703-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Wed, 4 May 2016 22:51:47 +0200
> Drivers that use LLTX need to update trans_start of the netdev_queue.
> (Most drivers don't use LLTX; stack does this update if .ndo_start_xmit
> returned TX_OK).
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied.
^ permalink raw reply
* Re: [PATC net-next] tcp: must block bh in __inet_twsk_hashdance()
From: David Miller @ 2016-05-04 21:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1462386131.5535.353.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 04 May 2016 11:22:11 -0700
> On Wed, 2016-05-04 at 00:54 -0400, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Tue, 03 May 2016 17:10:50 -0700
>>
>> > From: Eric Dumazet <edumazet@google.com>
>> >
>> > __inet_twsk_hashdance() might be called from process context,
>> > better block BH before acquiring bind hash and established locks
>> >
>> > Fixes: c10d9310edf5 ("tcp: do not assume TCP code is non preemptible")
>> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>>
>> Applied.
>
> David, I do not see these two patches in net-next ?
>
> (This one, and the "tcp: fix lockdep splat in tcp_snd_una_update()" one)
I pushed them in by hand, they should really be there now.
Thanks for letting me know.
^ permalink raw reply
* Re: [patch] usbnet: smsc95xx: silence an uninitialized variable warning
From: David Miller @ 2016-05-04 21:00 UTC (permalink / raw)
To: dan.carpenter; +Cc: steve.glendinning, netdev, linux-usb
In-Reply-To: <20160504062201.GF22064@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 4 May 2016 09:22:01 +0300
> If the call to fn() fails then "buf" is uninitialized. Just return the
> error code in that case.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
Please, in the future, use a consistent subsystem prefixing scheme. In these
two patches you used "x/y:"" and "x: y:"
Thanks.
^ permalink raw reply
* Re: [patch] usbnet/smsc75xx: silence uninitialized variable warning
From: David Miller @ 2016-05-04 20:59 UTC (permalink / raw)
To: dan.carpenter; +Cc: steve.glendinning, netdev, linux-usb
In-Reply-To: <20160504062102.GE22064@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 4 May 2016 09:21:02 +0300
> If the fn() calls fail then "buf" is uninitialized. Just return early
> in that situation.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* [PATCH net 1/2] bnxt_en: Need memory barrier when processing the completion ring.
From: Michael Chan @ 2016-05-04 20:56 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1462395404-21875-1-git-send-email-michael.chan@broadcom.com>
The code determines if the next ring entry is valid before proceeding
further to read the rest of the entry. The CPU can re-order and read
the rest of the entry first, possibly reading a stale entry, if DMA
of a new entry happens right after reading it. This issue can be
readily seen on a ppc64 system, causing it to crash.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 72eb29e..f33ff20 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -1388,6 +1388,10 @@ static int bnxt_poll_work(struct bnxt *bp, struct bnxt_napi *bnapi, int budget)
if (!TX_CMP_VALID(txcmp, raw_cons))
break;
+ /* The valid test of the entry must be done first before
+ * reading any further.
+ */
+ rmb();
if (TX_CMP_TYPE(txcmp) == CMP_TYPE_TX_L2_CMP) {
tx_pkts++;
/* return full budget so NAPI will complete. */
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 2/2] bnxt_en: Setup multicast properly after resetting device.
From: Michael Chan @ 2016-05-04 20:56 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1462395404-21875-1-git-send-email-michael.chan@broadcom.com>
The multicast/all-multicast internal flags are not properly restored
after device reset. This could lead to unreliable multicast operations
after an ethtool configuration change for example.
Call bnxt_mc_list_updated() and setup the vnic->mask in bnxt_init_chip()
to fix the issue.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index f33ff20..9d4e8e1 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -4042,9 +4042,11 @@ static int bnxt_alloc_rfs_vnics(struct bnxt *bp)
}
static int bnxt_cfg_rx_mode(struct bnxt *);
+static bool bnxt_mc_list_updated(struct bnxt *, u32 *);
static int bnxt_init_chip(struct bnxt *bp, bool irq_re_init)
{
+ struct bnxt_vnic_info *vnic = &bp->vnic_info[0];
int rc = 0;
if (irq_re_init) {
@@ -4100,13 +4102,22 @@ static int bnxt_init_chip(struct bnxt *bp, bool irq_re_init)
netdev_err(bp->dev, "HWRM vnic filter failure rc: %x\n", rc);
goto err_out;
}
- bp->vnic_info[0].uc_filter_count = 1;
+ vnic->uc_filter_count = 1;
- bp->vnic_info[0].rx_mask = CFA_L2_SET_RX_MASK_REQ_MASK_BCAST;
+ vnic->rx_mask = CFA_L2_SET_RX_MASK_REQ_MASK_BCAST;
if ((bp->dev->flags & IFF_PROMISC) && BNXT_PF(bp))
- bp->vnic_info[0].rx_mask |=
- CFA_L2_SET_RX_MASK_REQ_MASK_PROMISCUOUS;
+ vnic->rx_mask |= CFA_L2_SET_RX_MASK_REQ_MASK_PROMISCUOUS;
+
+ if (bp->dev->flags & IFF_ALLMULTI) {
+ vnic->rx_mask |= CFA_L2_SET_RX_MASK_REQ_MASK_ALL_MCAST;
+ vnic->mc_list_count = 0;
+ } else {
+ u32 mask = 0;
+
+ bnxt_mc_list_updated(bp, &mask);
+ vnic->rx_mask |= mask;
+ }
rc = bnxt_cfg_rx_mode(bp);
if (rc)
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 0/2] bnxt_en: 2 bug fixes.
From: Michael Chan @ 2016-05-04 20:56 UTC (permalink / raw)
To: davem; +Cc: netdev
Fix crash on ppc64 due to missing memory barrier and restore multicast
after reset.
Michael Chan (2):
bnxt_en: Need memory barrier when processing the completion ring.
bnxt_en: Setup multicast properly after resetting device.
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH next] drivers: fix dev->trans_start removal fallout
From: Florian Westphal @ 2016-05-04 20:56 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
kbuild test robot reported a build failure on s390.
While at it, also fix missing conversion in the tilera driver.
Fixes: 9b36627acecd5792 ("net: remove dev->trans_start")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
diff --git a/drivers/net/ethernet/tile/tilepro.c b/drivers/net/ethernet/tile/tilepro.c
index 0bb98bc..922a443 100644
--- a/drivers/net/ethernet/tile/tilepro.c
+++ b/drivers/net/ethernet/tile/tilepro.c
@@ -2026,7 +2026,7 @@ static void tile_net_tx_timeout(struct net_device *dev)
{
PDEBUG("tile_net_tx_timeout()\n");
PDEBUG("Transmit timeout at %ld, latency %ld\n", jiffies,
- jiffies - dev->trans_start);
+ jiffies - dev_trans_start(dev));
/* XXX: ISSUE: This doesn't seem useful for us. */
netif_wake_queue(dev);
diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c
index 7871537..b7b7477 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -3481,7 +3481,7 @@ static void qeth_flush_buffers(struct qeth_qdio_out_q *queue, int index,
}
}
- queue->card->dev->trans_start = jiffies;
+ netif_trans_update(queue->card->dev);
if (queue->card->options.performance_stats) {
queue->card->perf_stats.outbound_do_qdio_cnt++;
queue->card->perf_stats.outbound_do_qdio_start_time =
--
2.7.3
^ permalink raw reply related
* [PATCH next] bonding: update documentation section after dev->trans_start removal
From: Florian Westphal @ 2016-05-04 20:51 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
Drivers that use LLTX need to update trans_start of the netdev_queue.
(Most drivers don't use LLTX; stack does this update if .ndo_start_xmit
returned TX_OK).
Signed-off-by: Florian Westphal <fw@strlen.de>
---
Documentation/networking/bonding.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 334b49e..57f52cd 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -1880,8 +1880,8 @@ or more peers on the local network.
The ARP monitor relies on the device driver itself to verify
that traffic is flowing. In particular, the driver must keep up to
-date the last receive time, dev->last_rx, and transmit start time,
-dev->trans_start. If these are not updated by the driver, then the
+date the last receive time, dev->last_rx. Drivers that use NETIF_F_LLTX
+flag must also update netdev_queue->trans_start. If they do not, then the
ARP monitor will immediately fail any slaves using that driver, and
those slaves will stay down. If networking monitoring (tcpdump, etc)
shows the ARP requests and replies on the network, then it may be that
--
2.7.3
^ permalink raw reply related
* Re: pull request (net): ipsec 2016-05-04
From: David Miller @ 2016-05-04 20:48 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <1462340454-27922-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Wed, 4 May 2016 07:40:51 +0200
> 1) The flowcache can hit an OOM condition if too
> many entries are in the gc_list. Fix this by
> counting the entries in the gc_list and refuse
> new allocations if the value is too high.
>
> 2) The inner headers are invalid after a xfrm transformation,
> so reset the skb encapsulation field to ensure nobody tries
> access the inner headers. Otherwise tunnel devices stacked
> on top of xfrm may build the outer headers based on wrong
> informations.
>
> 3) Add pmtu handling to vti, we need it to report
> pmtu informations for local generated packets.
>
> Please pull or let me know if there are problems.
Pulled, thanks Steffen.
While build testing this I was worried that it might be possible
to create a situation where IP_VTI=y yet IPV6=m and therefore have
a unresolvable reference to icmpv6_send().
However I was not able to create such a configuration, as hard as
I tried. :-)
^ permalink raw reply
* Re: pull request: batman-adv 20160504
From: David Miller @ 2016-05-04 20:30 UTC (permalink / raw)
To: a
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1462314230-16257-1-git-send-email-a-2CpIooy/SPIKlTDg6p0iyA@public.gmane.org>
From: Antonio Quartulli <a@unstable.cc>
Date: Wed, 4 May 2016 06:23:35 +0800
> this is a pull request intended for net-next.
>
> In this batch you don't have any patch that depends on our fixes,
> therefore you can safely merge it even if the net tree has not been
> merged yet.
>
> In this patchset you basically have some cleanup work, code refactoring,
> style fixes and two updates for the MAINTAINERS file.
>
> Please pull or let me know of any problem!
Pulled, thanks Antonio.
^ permalink raw reply
* Re: [PATCH] fix infoleak in rtnetlink
From: David Miller @ 2016-05-04 20:20 UTC (permalink / raw)
To: kangjielu; +Cc: sfeldma, roopa, jiri, netdev, linux-kernel, taesoo, insu, kjlu
In-Reply-To: <1462308384-6315-1-git-send-email-kjlu@gatech.edu>
From: Kangjie Lu <kangjielu@gmail.com>
Date: Tue, 3 May 2016 16:46:24 -0400
> The stack object “map” has a total size of 32 bytes. Its last 4
> bytes are padding generated by compiler. These padding bytes are
> not initialized and sent out via “nla_put”.
>
> Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Applied.
^ permalink raw reply
* Re: [PATCH] fix infoleak in llc
From: David Miller @ 2016-05-04 20:20 UTC (permalink / raw)
To: kangjielu; +Cc: acme, netdev, linux-kernel, taesoo, insu, kjlu
In-Reply-To: <1462307705-5882-1-git-send-email-kjlu@gatech.edu>
From: Kangjie Lu <kangjielu@gmail.com>
Date: Tue, 3 May 2016 16:35:05 -0400
> The stack object “info” has a total size of 12 bytes. Its last byte
> is padding which is not initialized and leaked via “put_cmsg”.
>
> Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox