linux-toradex.git/net, branch T30_LinuxImageV2.0Beta2_20130626 Linux kernel for Apalis and Colibri modules bluetooth: hid: make Android code conditional 2012-12-04T20:16:47+00:00 Mursalin Akon makon@nvidia.com 2012-11-29T22:33:57+00:00 8024dfe1ac9035050c3402ceef52475dd59f3237 Commit 7c786ce33a1b4194cb95aa1e68bc38d552eda932 introduced couple of fields, which are not used in standard bluez user space stack. However, Android bluez use them. This CL, conditionally builds the part of the code introduced in the above commit. Bug 1178960 Change-Id: I7254fe83c7fb4bbfd14e00dda3ec3a14afc1b234 Signed-off-by: Mursalin Akon <makon@nvidia.com> (cherry picked from commit e3375fd96fa5e0d7cfcda848d797cd512c12b7a6) Reviewed-on: http://git-master/r/167540 Reviewed-by: Automatic_Commit_Validation_User Reviewed-by: Eric Brower <ebrower@nvidia.com> Reviewed-by: Matthew Pedro <mapedro@nvidia.com> 
Commit 7c786ce33a1b4194cb95aa1e68bc38d552eda932
introduced couple of fields, which are not used
in standard bluez user space stack. However,
Android bluez use them. This CL, conditionally
builds the part of the code introduced in the
above commit.

Bug 1178960

Change-Id: I7254fe83c7fb4bbfd14e00dda3ec3a14afc1b234
Signed-off-by: Mursalin Akon <makon@nvidia.com>
(cherry picked from commit e3375fd96fa5e0d7cfcda848d797cd512c12b7a6)
Reviewed-on: http://git-master/r/167540
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Eric Brower <ebrower@nvidia.com>
Reviewed-by: Matthew Pedro <mapedro@nvidia.com>
mac80211 & nl80211: add support to abort a scan request on tx 2012-07-12T15:28:05+00:00 Wei Ni wni@nvidia.com 2011-11-22T10:17:43+00:00 44713c41b7857936322397eb8f75d14b6e913d4b This fix comes from: https://gerrit.chromium.org/gerrit/#change,5744 https://gerrit.chromium.org/gerrit/#change,5745 So that it can work with the related wpa_supplicant tool. BUG=895591 Change-Id: Ie81f6d6052bd45dab13c936f9f0c5f4eb277496a Original-Signed-off-by: Wei Ni <wni@nvidia.com> Signed-off-by: Rhyland Klein <rklein@nvidia.com> Reviewed-on: http://git-master/r/111333 Reviewed-by: Automatic_Commit_Validation_User Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com> 
This fix comes from:
https://gerrit.chromium.org/gerrit/#change,5744
https://gerrit.chromium.org/gerrit/#change,5745

So that it can work with the related wpa_supplicant tool.

BUG=895591

Change-Id: Ie81f6d6052bd45dab13c936f9f0c5f4eb277496a
Original-Signed-off-by: Wei Ni <wni@nvidia.com>
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Reviewed-on: http://git-master/r/111333
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
cfg80211: fix a crash in nl80211_send_station 2012-06-15T08:45:19+00:00 Felix Fietkau nbd@openwrt.org 2011-08-11T01:00:33+00:00 c1fbf58a26c01b33196d0e4832f2ef742ff1b871 mac80211 leaves sinfo->assoc_req_ies uninitialized, causing a random pointer memory access in nl80211_send_station. Instead of checking if the pointer is null, use sinfo->filled, like the rest of the fields. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
mac80211 leaves sinfo->assoc_req_ies uninitialized, causing a random
pointer memory access in nl80211_send_station.
Instead of checking if the pointer is null, use sinfo->filled, like
the rest of the fields.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ah: Don't return NET_XMIT_DROP on input. 2012-02-10T02:20:28+00:00 Nick Bowler nbowler@elliptictech.com 2011-11-10T09:01:27+00:00 84a4439801e1b6ba9289b893fe083c996d34cc70 commit 4b90a603a1b21d63cf743cc833680cb195a729f6 upstream. When the ahash driver returns -EBUSY, AH4/6 input functions return NET_XMIT_DROP, presumably copied from the output code path. But returning transmit codes on input doesn't make a lot of sense. Since NET_XMIT_DROP is a positive int, this gets interpreted as the next header type (i.e., success). As that can only end badly, remove the check. Signed-off-by: Nick Bowler <nbowler@elliptictech.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Change-Id: Ia5db571c5c73a87397fa10dfb668f85b7942f3b0 Reviewed-on: http://git-master/r/79659 Reviewed-by: Automatic_Commit_Validation_User 
commit 4b90a603a1b21d63cf743cc833680cb195a729f6 upstream.

When the ahash driver returns -EBUSY, AH4/6 input functions return
NET_XMIT_DROP, presumably copied from the output code path.  But
returning transmit codes on input doesn't make a lot of sense.
Since NET_XMIT_DROP is a positive int, this gets interpreted as
the next header type (i.e., success).  As that can only end badly,
remove the check.

Signed-off-by: Nick Bowler <nbowler@elliptictech.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: Ia5db571c5c73a87397fa10dfb668f85b7942f3b0
Reviewed-on: http://git-master/r/79659
Reviewed-by: Automatic_Commit_Validation_User
tcp: md5: using remote adress for md5 lookup in rst packet 2012-02-08T22:31:41+00:00 shawnlu shawn.lu@ericsson.com 2012-01-20T12:22:04+00:00 7e14f410185a53b6112c629c12815b110e6f40c6 [ Upstream commit 8a622e71f58ec9f092fc99eacae0e6cf14f6e742 ] md5 key is added in socket through remote address. remote address should be used in finding md5 key when sending out reset packet. Signed-off-by: shawnlu <shawn.lu@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Change-Id: Ib092cc760c830540564414aa1d400e5eb78208f6 Reviewed-on: http://git-master/r/79697 Reviewed-by: Automatic_Commit_Validation_User 
[ Upstream commit 8a622e71f58ec9f092fc99eacae0e6cf14f6e742 ]

md5 key is added in socket through remote address.
remote address should be used in finding md5 key when
sending out reset packet.

Signed-off-by: shawnlu <shawn.lu@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: Ib092cc760c830540564414aa1d400e5eb78208f6
Reviewed-on: http://git-master/r/79697
Reviewed-by: Automatic_Commit_Validation_User
tcp: fix tcp_trim_head() to adjust segment count with skb MSS 2012-02-08T22:31:34+00:00 Neal Cardwell ncardwell@google.com 2012-01-28T17:29:46+00:00 c6d519412d7ef7ab7fb351b64421876b3b95d88d [ Upstream commit 5b35e1e6e9ca651e6b291c96d1106043c9af314a ] This commit fixes tcp_trim_head() to recalculate the number of segments in the skb with the skb's existing MSS, so trimming the head causes the skb segment count to be monotonically non-increasing - it should stay the same or go down, but not increase. Previously tcp_trim_head() used the current MSS of the connection. But if there was a decrease in MSS between original transmission and ACK (e.g. due to PMTUD), this could cause tcp_trim_head() to counter-intuitively increase the segment count when trimming bytes off the head of an skb. This violated assumptions in tcp_tso_acked() that tcp_trim_head() only decreases the packet count, so that packets_acked in tcp_tso_acked() could underflow, leading tcp_clean_rtx_queue() to pass u32 pkts_acked values as large as 0xffffffff to ca_ops->pkts_acked(). As an aside, if tcp_trim_head() had really wanted the skb to reflect the current MSS, it should have called tcp_set_skb_tso_segs() unconditionally, since a decrease in MSS would mean that a single-packet skb should now be sliced into multiple segments. Signed-off-by: Neal Cardwell <ncardwell@google.com> Acked-by: Nandita Dukkipati <nanditad@google.com> Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Change-Id: I8e7359bbd561e78d0d9be4c3f871b22114504c8b Reviewed-on: http://git-master/r/79696 Reviewed-by: Automatic_Commit_Validation_User 
[ Upstream commit 5b35e1e6e9ca651e6b291c96d1106043c9af314a ]

This commit fixes tcp_trim_head() to recalculate the number of
segments in the skb with the skb's existing MSS, so trimming the head
causes the skb segment count to be monotonically non-increasing - it
should stay the same or go down, but not increase.

Previously tcp_trim_head() used the current MSS of the connection. But
if there was a decrease in MSS between original transmission and ACK
(e.g. due to PMTUD), this could cause tcp_trim_head() to
counter-intuitively increase the segment count when trimming bytes off
the head of an skb. This violated assumptions in tcp_tso_acked() that
tcp_trim_head() only decreases the packet count, so that packets_acked
in tcp_tso_acked() could underflow, leading tcp_clean_rtx_queue() to
pass u32 pkts_acked values as large as 0xffffffff to
ca_ops->pkts_acked().

As an aside, if tcp_trim_head() had really wanted the skb to reflect
the current MSS, it should have called tcp_set_skb_tso_segs()
unconditionally, since a decrease in MSS would mean that a
single-packet skb should now be sliced into multiple segments.

Signed-off-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Nandita Dukkipati <nanditad@google.com>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: I8e7359bbd561e78d0d9be4c3f871b22114504c8b
Reviewed-on: http://git-master/r/79696
Reviewed-by: Automatic_Commit_Validation_User
rds: Make rds_sock_lock BH rather than IRQ safe. 2012-02-08T22:31:29+00:00 David S. Miller davem@davemloft.net 2012-01-24T22:03:44+00:00 fd0ee4525f9cd149b960a1b33e86129eaede864c [ Upstream commit efc3dbc37412c027e363736b4f4c74ee5e8ecffc ] rds_sock_info() triggers locking warnings because we try to perform a local_bh_enable() (via sock_i_ino()) while hardware interrupts are disabled (via taking rds_sock_lock). There is no reason for rds_sock_lock to be a hardware IRQ disabling lock, none of these access paths run in hardware interrupt context. Therefore making it a BH disabling lock is safe and sufficient to fix this bug. Reported-by: Kumar Sanghvi <kumaras@chelsio.com> Reported-by: Josh Boyer <jwboyer@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Change-Id: Ie8ac0fd3307c1d827994aa113764bc3ad96ab1a3 Reviewed-on: http://git-master/r/79695 Reviewed-by: Automatic_Commit_Validation_User 
[ Upstream commit efc3dbc37412c027e363736b4f4c74ee5e8ecffc ]

rds_sock_info() triggers locking warnings because we try to perform a
local_bh_enable() (via sock_i_ino()) while hardware interrupts are
disabled (via taking rds_sock_lock).

There is no reason for rds_sock_lock to be a hardware IRQ disabling
lock, none of these access paths run in hardware interrupt context.

Therefore making it a BH disabling lock is safe and sufficient to
fix this bug.

Reported-by: Kumar Sanghvi <kumaras@chelsio.com>
Reported-by: Josh Boyer <jwboyer@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: Ie8ac0fd3307c1d827994aa113764bc3ad96ab1a3
Reviewed-on: http://git-master/r/79695
Reviewed-by: Automatic_Commit_Validation_User
l2tp: l2tp_ip - fix possible oops on packet receive 2012-02-08T22:31:13+00:00 James Chapman jchapman@katalix.com 2012-01-25T02:39:05+00:00 76844f79d0c9484b132e2dd5542d272329420a7d [ Upstream commit 68315801dbf3ab2001679fd2074c9dc5dcf87dfa ] When a packet is received on an L2TP IP socket (L2TPv3 IP link encapsulation), the l2tpip socket's backlog_rcv function calls xfrm4_policy_check(). This is not necessary, since it was called before the skb was added to the backlog. With CONFIG_NET_NS enabled, xfrm4_policy_check() will oops if skb->dev is null, so this trivial patch removes the call. This bug has always been present, but only when CONFIG_NET_NS is enabled does it cause problems. Most users are probably using UDP encapsulation for L2TP, hence the problem has only recently surfaced. EIP: 0060:[<c12bb62b>] EFLAGS: 00210246 CPU: 0 EIP is at l2tp_ip_recvmsg+0xd4/0x2a7 EAX: 00000001 EBX: d77b5180 ECX: 00000000 EDX: 00200246 ESI: 00000000 EDI: d63cbd30 EBP: d63cbd18 ESP: d63cbcf4 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Call Trace: [<c1218568>] sock_common_recvmsg+0x31/0x46 [<c1215c92>] __sock_recvmsg_nosec+0x45/0x4d [<c12163a1>] __sock_recvmsg+0x31/0x3b [<c1216828>] sock_recvmsg+0x96/0xab [<c10b2693>] ? might_fault+0x47/0x81 [<c10b2693>] ? might_fault+0x47/0x81 [<c1167fd0>] ? _copy_from_user+0x31/0x115 [<c121e8c8>] ? copy_from_user+0x8/0xa [<c121ebd6>] ? verify_iovec+0x3e/0x78 [<c1216604>] __sys_recvmsg+0x10a/0x1aa [<c1216792>] ? sock_recvmsg+0x0/0xab [<c105a99b>] ? __lock_acquire+0xbdf/0xbee [<c12d5a99>] ? do_page_fault+0x193/0x375 [<c10d1200>] ? fcheck_files+0x9b/0xca [<c10d1259>] ? fget_light+0x2a/0x9c [<c1216bbb>] sys_recvmsg+0x2b/0x43 [<c1218145>] sys_socketcall+0x16d/0x1a5 [<c11679f0>] ? trace_hardirqs_on_thunk+0xc/0x10 [<c100305f>] sysenter_do_call+0x12/0x38 Code: c6 05 8c ea a8 c1 01 e8 0c d4 d9 ff 85 f6 74 07 3e ff 86 80 00 00 00 b9 17 b6 2b c1 ba 01 00 00 00 b8 78 ed 48 c1 e8 23 f6 d9 ff <ff> 76 0c 68 28 e3 30 c1 68 2d 44 41 c1 e8 89 57 01 00 83 c4 0c Signed-off-by: James Chapman <jchapman@katalix.com> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Change-Id: I343ca4e0871cd48dfc62ef7d1b45e0be3109688a Reviewed-on: http://git-master/r/79693 
[ Upstream commit 68315801dbf3ab2001679fd2074c9dc5dcf87dfa ]

When a packet is received on an L2TP IP socket (L2TPv3 IP link
encapsulation), the l2tpip socket's backlog_rcv function calls
xfrm4_policy_check(). This is not necessary, since it was called
before the skb was added to the backlog. With CONFIG_NET_NS enabled,
xfrm4_policy_check() will oops if skb->dev is null, so this trivial
patch removes the call.

This bug has always been present, but only when CONFIG_NET_NS is
enabled does it cause problems. Most users are probably using UDP
encapsulation for L2TP, hence the problem has only recently
surfaced.

EIP: 0060:[<c12bb62b>] EFLAGS: 00210246 CPU: 0
EIP is at l2tp_ip_recvmsg+0xd4/0x2a7
EAX: 00000001 EBX: d77b5180 ECX: 00000000 EDX: 00200246
ESI: 00000000 EDI: d63cbd30 EBP: d63cbd18 ESP: d63cbcf4
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Call Trace:
 [<c1218568>] sock_common_recvmsg+0x31/0x46
 [<c1215c92>] __sock_recvmsg_nosec+0x45/0x4d
 [<c12163a1>] __sock_recvmsg+0x31/0x3b
 [<c1216828>] sock_recvmsg+0x96/0xab
 [<c10b2693>] ? might_fault+0x47/0x81
 [<c10b2693>] ? might_fault+0x47/0x81
 [<c1167fd0>] ? _copy_from_user+0x31/0x115
 [<c121e8c8>] ? copy_from_user+0x8/0xa
 [<c121ebd6>] ? verify_iovec+0x3e/0x78
 [<c1216604>] __sys_recvmsg+0x10a/0x1aa
 [<c1216792>] ? sock_recvmsg+0x0/0xab
 [<c105a99b>] ? __lock_acquire+0xbdf/0xbee
 [<c12d5a99>] ? do_page_fault+0x193/0x375
 [<c10d1200>] ? fcheck_files+0x9b/0xca
 [<c10d1259>] ? fget_light+0x2a/0x9c
 [<c1216bbb>] sys_recvmsg+0x2b/0x43
 [<c1218145>] sys_socketcall+0x16d/0x1a5
 [<c11679f0>] ? trace_hardirqs_on_thunk+0xc/0x10
 [<c100305f>] sysenter_do_call+0x12/0x38
Code: c6 05 8c ea a8 c1 01 e8 0c d4 d9 ff 85 f6 74 07 3e ff 86 80 00 00 00 b9 17 b6 2b c1 ba 01 00 00 00 b8 78 ed 48 c1 e8 23 f6 d9 ff <ff> 76 0c 68 28 e3 30 c1 68 2d 44 41 c1 e8 89 57 01 00 83 c4 0c

Signed-off-by: James Chapman <jchapman@katalix.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: I343ca4e0871cd48dfc62ef7d1b45e0be3109688a
Reviewed-on: http://git-master/r/79693
net caif: Register properly as a pernet subsystem. 2012-02-08T22:31:02+00:00 Eric W. Biederman ebiederm@xmission.com 2012-01-26T14:04:53+00:00 ef14c366c8b137b63a045f49448422296d0f15f9 [ Upstream commit 8a8ee9aff6c3077dd9c2c7a77478e8ed362b96c6 ] caif is a subsystem and as such it needs to register with register_pernet_subsys instead of register_pernet_device. Among other problems using register_pernet_device was resulting in net_generic being called before the caif_net structure was allocated. Which has been causing net_generic to fail with either BUG_ON's or by return NULL pointers. A more ugly problem that could be caused is packets in flight why the subsystem is shutting down. To remove confusion also remove the cruft cause by inappropriately trying to fix this bug. With the aid of the previous patch I have tested this patch and confirmed that using register_pernet_subsys makes the failure go away as it should. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Acked-by: Sjur Brændeland <sjur.brandeland@stericsson.com> Tested-by: Sasha Levin <levinsasha928@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Change-Id: I25251a26707c9f6668d3a099c2bfe662f6eddf17 Reviewed-on: http://git-master/r/79691 Reviewed-by: Automatic_Commit_Validation_User 
[ Upstream commit 8a8ee9aff6c3077dd9c2c7a77478e8ed362b96c6 ]

caif is a subsystem and as such it needs to register with
register_pernet_subsys instead of register_pernet_device.

Among other problems using register_pernet_device was resulting in
net_generic being called before the caif_net structure was allocated.
Which has been causing net_generic to fail with either BUG_ON's or by
return NULL pointers.

A more ugly problem that could be caused is packets in flight why the
subsystem is shutting down.

To remove confusion also remove the cruft cause by inappropriately
trying to fix this bug.

With the aid of the previous patch I have tested this patch and
confirmed that using register_pernet_subsys makes the failure go away as
it should.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Acked-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
Tested-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: I25251a26707c9f6668d3a099c2bfe662f6eddf17
Reviewed-on: http://git-master/r/79691
Reviewed-by: Automatic_Commit_Validation_User
netns: fix net_alloc_generic() 2012-02-08T22:30:50+00:00 Eric Dumazet eric.dumazet@gmail.com 2012-01-26T00:41:38+00:00 68b281810aebe0be4e6142e16fb814c00c6b0f21 [ Upstream commit 073862ba5d249c20bd5c49fc6d904ff0e1f6a672 ] When a new net namespace is created, we should attach to it a "struct net_generic" with enough slots (even empty), or we can hit the following BUG_ON() : [ 200.752016] kernel BUG at include/net/netns/generic.h:40! ... [ 200.752016] [<ffffffff825c3cea>] ? get_cfcnfg+0x3a/0x180 [ 200.752016] [<ffffffff821cf0b0>] ? lockdep_rtnl_is_held+0x10/0x20 [ 200.752016] [<ffffffff825c41be>] caif_device_notify+0x2e/0x530 [ 200.752016] [<ffffffff810d61b7>] notifier_call_chain+0x67/0x110 [ 200.752016] [<ffffffff810d67c1>] raw_notifier_call_chain+0x11/0x20 [ 200.752016] [<ffffffff821bae82>] call_netdevice_notifiers+0x32/0x60 [ 200.752016] [<ffffffff821c2b26>] register_netdevice+0x196/0x300 [ 200.752016] [<ffffffff821c2ca9>] register_netdev+0x19/0x30 [ 200.752016] [<ffffffff81c1c67a>] loopback_net_init+0x4a/0xa0 [ 200.752016] [<ffffffff821b5e62>] ops_init+0x42/0x180 [ 200.752016] [<ffffffff821b600b>] setup_net+0x6b/0x100 [ 200.752016] [<ffffffff821b6466>] copy_net_ns+0x86/0x110 [ 200.752016] [<ffffffff810d5789>] create_new_namespaces+0xd9/0x190 net_alloc_generic() should take into account the maximum index into the ptr array, as a subsystem might use net_generic() anytime. This also reduces number of reallocations in net_assign_generic() Reported-by: Sasha Levin <levinsasha928@gmail.com> Tested-by: Sasha Levin <levinsasha928@gmail.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Cc: Sjur Brændeland <sjur.brandeland@stericsson.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Change-Id: Ib8860cb9b393b9b695ceda7b48220ed12dd31c8b Reviewed-on: http://git-master/r/79689 Reviewed-by: Automatic_Commit_Validation_User 
[ Upstream commit 073862ba5d249c20bd5c49fc6d904ff0e1f6a672 ]

When a new net namespace is created, we should attach to it a "struct
net_generic" with enough slots (even empty), or we can hit the following
BUG_ON() :

[  200.752016] kernel BUG at include/net/netns/generic.h:40!
...
[  200.752016]  [<ffffffff825c3cea>] ? get_cfcnfg+0x3a/0x180
[  200.752016]  [<ffffffff821cf0b0>] ? lockdep_rtnl_is_held+0x10/0x20
[  200.752016]  [<ffffffff825c41be>] caif_device_notify+0x2e/0x530
[  200.752016]  [<ffffffff810d61b7>] notifier_call_chain+0x67/0x110
[  200.752016]  [<ffffffff810d67c1>] raw_notifier_call_chain+0x11/0x20
[  200.752016]  [<ffffffff821bae82>] call_netdevice_notifiers+0x32/0x60
[  200.752016]  [<ffffffff821c2b26>] register_netdevice+0x196/0x300
[  200.752016]  [<ffffffff821c2ca9>] register_netdev+0x19/0x30
[  200.752016]  [<ffffffff81c1c67a>] loopback_net_init+0x4a/0xa0
[  200.752016]  [<ffffffff821b5e62>] ops_init+0x42/0x180
[  200.752016]  [<ffffffff821b600b>] setup_net+0x6b/0x100
[  200.752016]  [<ffffffff821b6466>] copy_net_ns+0x86/0x110
[  200.752016]  [<ffffffff810d5789>] create_new_namespaces+0xd9/0x190

net_alloc_generic() should take into account the maximum index into the
ptr array, as a subsystem might use net_generic() anytime.

This also reduces number of reallocations in net_assign_generic()

Reported-by: Sasha Levin <levinsasha928@gmail.com>
Tested-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Sjur Brændeland <sjur.brandeland@stericsson.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: Ib8860cb9b393b9b695ceda7b48220ed12dd31c8b
Reviewed-on: http://git-master/r/79689
Reviewed-by: Automatic_Commit_Validation_User