- 05 Feb, 2013 4 commits
-
-
Tom Parkin authored
To allow l2tp_tunnel_delete to be called from an atomic context, place the tunnel socket release calls on a workqueue for asynchronous execution. Tunnel memory is eventually freed in the tunnel socket destructor. Signed-off-by: Tom Parkin <tparkin@katalix.com> Signed-off-by: James Chapman <jchapman@katalix.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller authored
Conflicts: drivers/net/ethernet/intel/e1000e/ethtool.c drivers/net/vmxnet3/vmxnet3_drv.c drivers/net/wireless/iwlwifi/dvm/tx.c net/ipv6/route.c The ipv6 route.c conflict is simple, just ignore the 'net' side change as we fixed the same problem in 'net-next' by eliminating cached neighbours from ipv6 routes. The e1000e conflict is an addition of a new statistic in the ethtool code, trivial. The vmxnet3 conflict is about one change in 'net' removing a guarding conditional, whilst in 'net-next' we had a netdev_info() conversion. The iwlwifi conflict is dealing with a WARN_ON() conversion in 'net-next' vs. a revert happening in 'net'. Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jitendra Kalsaria authored
We recently refactored the driver source, this patch will take care of updating copyright date and adding it to newly added files. Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paul Gortmaker authored
Commit ee873fda "gianfar: Pack struct gfar_priv_grp into three cachelines" causes the following null dereference at driver init on sbc8548: libphy: Freescale PowerQUICC MII Bus: probed Unable to handle kernel paging request for data at address 0x00000000 Faulting instruction address: 0xc01d6a38 Oops: Kernel access of bad area, sig: 11 [#1] [...] NIP [c01d6a38] gfar_parse_group+0x228/0x280 LR [c01d6a34] gfar_parse_group+0x224/0x280 Call Trace: [ef82dd60] [c01d6a34] gfar_parse_group+0x224/0x280 (unreliable) [ef82dd90] [c01d73a4] gfar_probe+0x284/0xfe0 The reason is that the commit also changed the allocation of the Rx and error handling irq structs to be skipped for !MQ_MG_MODE. In the !MQ_MG_MODE case, only the Tx irq struct is allocated. Digging further, we see that MQ_MG_MODE is set only if we find the OF compatible string "fsl,etsec2". A quick grep in the dts directory shows lots of boards that support Rx/Tx/Err, but without this specific compat string. And hence they go after the unallocated Rx/Error structs and cause the above oops. Hence such a change can not be deployed until all the dts files are updated and sufficiently deployed. Further, the optimization is of limited value, since the kmalloc'd struct in question has only a single unsigned int, and an (IFNAMSIZ + 6) sized string. Note that no changes to the freeing code are needed here, as it already did an unconditional free of Rx/Tx/Error gfar_irqinfo. Cc: Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 04 Feb, 2013 28 commits
-
-
David S. Miller authored
This module is namespace aware, netns_ok was just disabled by default for sanity. Signed-off-by: David S. Miller <davem@davemloft.net>
-
Frank Li authored
BUG: spinlock bad magic on CPU#1, swapper/0/1 lock: 0xbfae0f8c, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 Backtrace: [<80011d54>] (dump_backtrace+0x0/0x10c) from [<804e7800>] (dump_stack+0x18/0x1c) r6:bfae0000 r5:bfae0f8c r4:00000000 r3:806c1310 [<804e77e8>] (dump_stack+0x0/0x1c) from [<804e9f20>] (spin_dump+0x80/0x94) [<804e9ea0>] (spin_dump+0x0/0x94) from [<804e9f60>] (spin_bug+0x2c/0x30) r5:805f6f8c r4:bfae0f8c [<804e9f34>] (spin_bug+0x0/0x30) from [<80257984>] (do_raw_spin_lock+0x170/0x1b0 ) r5:806b4950 r4:bfae0f8c [<80257814>] (do_raw_spin_lock+0x0/0x1b0) from [<804ed15c>] (_raw_spin_lock_irqs ave+0x18/0x20) [<804ed144>] (_raw_spin_lock_irqsave+0x0/0x20) from [<8033c694>] (fec_ptp_start_ cyclecounter+0x3c/0x120) r4:bfae0f8c r3:00000002 [<8033c658>] (fec_ptp_start_cyclecounter+0x0/0x120) from [<80339e08>] (fec_resta rt+0x56c/0x5f8) r8:00000000 r7:806e6f48 r6:00000112 r5:806b4950 r4:bfae0000 [<8033989c>] (fec_restart+0x0/0x5f8) from [<8033b9e4>] (fec_probe+0x508/0xa48) Signed-off-by: Frank Li <Frank.Li@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jiri Pirko authored
In case port is leaving the team, set the option "activeport" as changed so the change can be properly propagated to userspace Signed-off-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jiri Pirko authored
In team_port_del(), there is need to be do all the cleanup related things first and netlink event notifiers should be called after that. This fixes two problems: team carrier is now correctly set (port is removed from list first) mode can set option as changed in .port_leave op Signed-off-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jiri Pirko authored
Essentially do the same thing with port list as with option list. Multipart netlink message. Side effect is that port event message can send port which is not longer in team->port_list. Signed-off-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Hadar Hen Zion authored
ip_eth_mc_map function can't be used when CONFIG_INET isn't defined. Fixed compilation error by adding CONFIG_INET define check before using the function. Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Hadar Hen Zion authored
Propagate return value of mlx4_en_ethtool_add_mac_rule_by_ipv4 in case of failure. Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jean Sacren authored
With the loop, don't check 'rv' twice in a row. Without the loop, 'rv' doesn't even need to be checked. Make the comment more grammar-friendly. Signed-off-by: Jean Sacren <sakiwit@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ying Xue authored
As in del_timer() there has already placed a timer_pending() function to check whether the timer to be deleted is pending or not, it's unnecessary to check timer pending state again before del_timer() is called. Signed-off-by: Ying Xue <ying.xue@windriver.com> Cc: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sathya Perla authored
Signed-off-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sathya Perla authored
Currently, when the PF driver is unloaded and re-loaded while VFs are attached to VMs, it loses control of its VFs. The PF driver now uses the newly defined/created GET_IFACE_LIST cmd (available in FW ver >= 4.6) to query the if_id of the VFs (enabled in its previous life). The PF driver then uses the if_id for further VF configuration. The GET_IFACE_MAC_LIST cmd has also implemented in BE3 FW for PF to query pmac-ids used by its VFs. Signed-off-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joe Perches authored
alloc failures already get standardized OOM messages and a dump_stack. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joe Perches authored
alloc failures already get standardized OOM messages and a dump_stack. Convert kzalloc's with multiplies to kcalloc. Convert kmalloc's with multiplies to kmalloc_array. Remove now unused variables. Remove unnecessary memset after kzalloc->kcalloc. Whitespace cleanups for these changes. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joe Perches authored
alloc failures already get standardized OOM messages and a dump_stack. Convert kzalloc's with multiplies to kcalloc. Remove now unused size variables. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joe Perches authored
alloc failures already get standardized OOM messages and a dump_stack. Hoist assigns from if tests. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joe Perches authored
alloc failures already get standardized OOM messages and a dump_stack. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joe Perches authored
alloc failures already get standardized OOM messages and a dump_stack. Convert kzalloc's with multiplies to kcalloc. Convert kmalloc's with multiplies to kmalloc_array. Fix a few whitespace defects. Convert a constant 6 to ETH_ALEN. Use parentheses around sizeof. Convert vmalloc/memset to vzalloc. Remove now unused size variables. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joe Perches authored
alloc failures already get standardized OOM messages and a dump_stack. Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joe Perches authored
alloc failures already get standardized OOM messages and a dump_stack. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daniel Borkmann authored
It seems due to RCU usage, i.e. within SCTP's address binding list, a, say, ``behavioral change'' was introduced which does actually not conform to the RFC anymore. In particular consider the following (fictional) scenario to demonstrate this: do: Two SOCK_SEQPACKET-style sockets are opened (S1, S2) S1 is bound to 127.0.0.1, port 1024 [server] S2 is bound to 127.0.0.1, port 1025 [client] listen(2) is invoked on S1 From S2 we call one sendmsg(2) with msg.msg_name and msg.msg_namelen parameters set to the server's address S1, S2 are closed goto do The first pass of this loop passes successful, while the second round fails during binding of S1 (address still in use). What is happening? In the first round, the initial handshake is being done, and, at the time close(2) is called on S1, a non-graceful shutdown is performed via ABORT since in S1's receive queue an unprocessed packet is present, thus stating an error condition. This can be considered as a correct behavior. During close also all bound addresses are freed, thus nothing *must* be active anymore. In reference to RFC2960: After checking the Verification Tag, the receiving endpoint shall remove the association from its record, and shall report the termination to its upper layer. (9.1 Abort of an Association) Also, no half-open states are supported, thus after an ungraceful shutdown, we leave nothing behind. However, this seems not to be happening though. In a real-world scenario, this is exactly where it breaks the lksctp-tools functional test suite, *for instance*: ./test_sockopt test_sockopt.c 1 PASS : getsockopt(SCTP_STATUS) on a socket with no assoc test_sockopt.c 2 PASS : getsockopt(SCTP_STATUS) test_sockopt.c 3 PASS : getsockopt(SCTP_STATUS) with invalid associd test_sockopt.c 4 PASS : getsockopt(SCTP_STATUS) with NULL associd test_sockopt.c 5 BROK : bind: Address already in use The underlying problem is that sctp_endpoint_destroy() hasn't been triggered yet while the next bind attempt is being done. It will be triggered eventually (but too late) by sctp_transport_destroy_rcu() after one RCU grace period: sctp_transport_destroy() sctp_transport_destroy_rcu() ----. sctp_association_put() [*] <--+--> sctp_packet_free() sctp_association_destroy() [...] sctp_endpoint_put() skb->destructor sctp_endpoint_destroy() sctp_wfree() sctp_bind_addr_free() sctp_association_put() [*] Thus, we move out the condition with sctp_association_put() as well as the sctp_packet_free() invocation and the issue can be solved. We also better free the SCTP chunks first before putting the ref of the association. With this patch, the example above (which simulates a similar scenario as in the implementation of this test case) and therefore also the test suite run successfully through. Tested by myself. Cc: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vipul Pandya authored
Signed-off-by: Divy Le Ray <divy@chelsio.com> Signed-off-by: Vipul Pandya <vipul@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gao feng authored
reduce the permission check of bond device's ioctl. allow the userns root to control the bond device. Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gao feng authored
since the mdb table is belong to bridge device,and the bridge device can only be seen in one netns. So it's safe to allow unprivileged user which is the creator of userns and netns to modify the mdb table. Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gao feng authored
ebt_table is a private resource of netns, operating ebtables in one netns will not affect other netns, we can allow the creator user of userns and netns to change the ebtables. Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Gao feng authored
Right now,only ixgdb,macvlan,vxlan and bridge implement fdb_add/fdb_del operations. these operations only operate the private data of net device. So allowing the unprivileged users who creates the userns and netns to add/del fdb entries will do no harm to other netns. Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
It is normal for minidrivers accumulating frames to return NULL from their tx_fixup function. We do not want to count this as a drop, or log any debug messages. A different exit path is therefore chosen for such drivers, skipping the debug message and the tx_dropped increment. The test for accumulating drivers was however completely bogus, making the exit path selection depend on whether the user had enabled tx_err logging or not. This would arbitrarily mess up accounting for both accumulating and non-accumulating minidrivers, and would result in unwanted debug messages for the accumulating drivers. Fix by testing for FLAG_MULTI_PACKET instead, which probably was the intention from the beginning. This usage match the documented behaviour of this flag: Indicates to usbnet, that USB driver accumulates multiple IP packets. Affects statistic (counters) and short packet handling. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vijay Subramanian authored
This patch updates LINUX_MIB_LISTENDROPS and LINUX_MIB_LISTENOVERFLOWS in tcp_v6_conn_request() and tcp_v6_err(). tcp_v6_conn_request() in particular can drop SYNs for various reasons which are not currently tracked. Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vijay Subramanian authored
This patch updates LINUX_MIB_LISTENDROPS in tcp_v4_conn_request() and tcp_v4_err(). tcp_v4_conn_request() in particular can drop SYNs for various reasons which are not currently tracked. Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 03 Feb, 2013 8 commits
-
-
Phil Sutter authored
When releasing a packet socket, the routine packet_set_ring() is reused to free rings instead of allocating them. But when calling it for the first time, it fills req->tp_block_nr with the value of rb->pg_vec_len which in the second invocation makes it bail out since req->tp_block_nr is greater zero but req->tp_block_size is zero. This patch solves the problem by passing a zeroed auto-variable to packet_set_ring() upon each invocation from packet_release(). As far as I can tell, this issue exists even since 69e3c75f (net: TX_RING and packet mmap), i.e. the original inclusion of TX ring support into af_packet, but applies only to sockets with both RX and TX ring allocated, which is probably why this was unnoticed all the time. Signed-off-by: Phil Sutter <phil.sutter@viprinet.com> Cc: Johann Baudy <johann.baudy@gnu-log.net> Cc: Daniel Borkmann <dborkman@redhat.com> Acked-by: Daniel Borkmann <dborkman@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexey Khoroshilov authored
If stmmac_dvr_probe() fails in stmmac_pci_probe(), it breaks off initialization, deallocates all resources, but returns zero. The patch adds -ENODEV as return value in this case. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pravin B Shelar authored
Use correct inner offset to set inner_network_offset. Found by inspection. Signed-off-by: Pravin B Shelar <pshelar@nicira.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
Commit 9dc27415 (tcp: fix ABC in tcp_slow_start()) uncovered a bug in FRTO code : tcp_process_frto() is setting snd_cwnd to 0 if the number of in flight packets is 0. As Neal pointed out, if no packet is in flight we lost our chance to disambiguate whether a loss timeout was spurious. We should assume it was a proper loss. Reported-by: Pasi Kärkkäinen <pasik@iki.fi> Signed-off-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Cc: Yuchung Cheng <ycheng@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
Since commit 9dc27415 (tcp: fix ABC in tcp_slow_start()), a nul snd_cwnd triggers an infinite loop in tcp_slow_start() Avoid this infinite loop and log a one time error for further analysis. FRTO code is suspected to cause this bug. Reported-by: Pasi Kärkkäinen <pasik@iki.fi> Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Neal Cardwell <ncardwell@google.com> Cc: Yuchung Cheng <ycheng@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linuxDavid S. Miller authored
Paul Gortmaker says: ==================== The removal of wanrouter code was originally listed in the (now gone) feature removal file since May 2012, and an RFC of the deletion was posted[1] in late 2012. The overall concept was given an OK, but defconfig contamination, build failures, etc. meant that it didn't quite make it into mainline for 3.8. Since that time, Dan discovered (via code audit) a runtime bug that proves nobody has been using this for over four years[2]. With that new information, I think it makes sense for someone to follow through on Joe's original RFC and get this done for the 3.9 release. In addition to resolving the build failures of the RFC by keeping stub headers, this also splits the change into two parts, just like the token ring removal did. Part #1 decouples the mainline kernel from the expired subsystem, and part #2 does the large scale deletion of the subsystem content. The advantage of the above, is that a "git blame" will never lead you to a 4000+ line deletion commit. The large scale deletion will never show up in a "git blame" and hence the same advantages that we get from the "--irreversible-delete" in the review stage of "git format-patch" are also embedded into the git history itself. This may seem like a moot point to some, but for those who spend a considerable amount of time data mining in the git history, this is probably worth doing. I have done build tests of all[mod/yes]config for both the stage 1 (Makefile and Kconfig) and stage 2 (full driver delete) as a sanity check, and the issues with the previously posted RFC should be gone. Speaking of "--irreversible-delete" -- these patches were created with that option, so if you want to use them locally, you are going to have to pull (location below) the content instead of doing a "git am" of the mailed out content. [1] http://patchwork.ozlabs.org/patch/198794/ [2] http://www.spinics.net/lists/netdev/msg218670.html ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://gitorious.org/linux-can/linux-canDavid S. Miller authored
Marc Kleine-Budde says: ==================== here's a patch for net for the v3.8 release cycle. Alexander Stein noticed that the c_can hardware has a fixed bit in the IFx_MASK2 register. His patch fixes writing of this register by always setting this bit. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dan Carpenter authored
We actually store the MAC address as well as the board_name here. The longest board_name is 75 characters so there is more than enough room to hold the 17 character MAC and the ": " divider. But making this buffer larger silences a static checker warning. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-By: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-