summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* drivers/net: caif: fix wrong rtnl_is_locked() usageKonstantin Khlebnikov2013-07-091-22/+39
| | | | | | | | | | | | | | rtnl_is_locked() doesn't check who holds this lock, it just tells that it's locked right now. if caif::ldisc_close really can be called under rtrnl_lock then it should release net device in other context because there is no way to grab rtnl_lock without deadlock. This patch adds work which releases these devices. Also this patch fixes calling dev_close/unregister_netdevice without rtnl_lock from caif_ser_exit(). Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Dmitry Tarnyagin <dmitry.tarnyagin@lockless.no> Signed-off-by: David S. Miller <davem@davemloft.net>
* drivers/net: enic: release rtnl_lock on error-pathKonstantin Khlebnikov2013-07-091-0/+2
| | | | | | | | | | | enic_change_mtu_work() must call rtnl_unlock() on all exiting paths. Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Christian Benvenuti <benve@cisco.com> Cc: Roopa Prabhu <roprabhu@cisco.com> Cc: Neel Patel <neepatel@cisco.com> Cc: Nishank Trivedi <nistrive@cisco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* vhost-net: fix use-after-free in vhost_net_flushMichael S. Tsirkin2013-07-091-2/+7
| | | | | | | | | | | | | | | | | vhost_net_ubuf_put_and_wait has a confusing name: it will actually also free it's argument. Thus since commit 1280c27f8e29acf4af2da914e80ec27c3dbd5c01 "vhost-net: flush outstanding DMAs on memory change" vhost_net_flush tries to use the argument after passing it to vhost_net_ubuf_put_and_wait, this results in use after free. To fix, don't free the argument in vhost_net_ubuf_put_and_wait, add an new API for callers that want to free ubufs. Acked-by: Asias He <asias@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: mv643xx_eth: do not use port number as platform device idJonas Gorski2013-07-091-2/+11
| | | | | | | | | | | | The port number is only local to the ethernet block, not global, so there can be two ethernet blocks both using the same port, like kirkwood with both using port 0. Fix this by using the array index offset for the allocated platform devices as the id. Signed-off-by: Jonas Gorski <jogo@openwrt.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: sctp: confirm route during forward progressDaniel Borkmann2013-07-092-0/+15
| | | | | | | | | | | | | | | | | | | | | This fix has been proposed originally by Vlad Yasevich. He says: When SCTP makes forward progress (receives a SACK that acks new chunks, renegs, or answeres 0-window probes) or when HB-ACK arrives, mark the route as confirmed so we don't unnecessarily send NUD probes. Having a simple SCTP client/server that exchange data chunks every 1sec, without this patch ARP requests are sent periodically every 40-60sec. With this fix applied, an ARP request is only done once right at the "session" beginning. Also, when clearing the related ARP cache entry manually during the session, a new request is correctly done. I have only "backported" this to net-next and tested that it works, so full credit goes to Vlad. Signed-off-by: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* virtio_net: fix race in RX VQ processingDavid S. Miller2013-07-093-14/+51
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Michael S. Tsirkin says: ==================== Jason Wang reported a race in RX VQ processing: virtqueue_enable_cb is called outside napi lock, violating virtio serialization rules. The race has been there from day 1, but it got especially nasty in 3.0 when commit a5c262c5fd83ece01bd649fb08416c501d4c59d7 "virtio_ring: support event idx feature" added more dependency on vq state. Please review, and consider for 3.11 and stable. Changes from v1: - Added Jason's Tested-by tag - minor coding style fix ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * virtio_net: fix race in RX VQ processingMichael S. Tsirkin2013-07-091-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | virtio net called virtqueue_enable_cq on RX path after napi_complete, so with NAPI_STATE_SCHED clear - outside the implicit napi lock. This violates the requirement to synchronize virtqueue_enable_cq wrt virtqueue_add_buf. In particular, used event can move backwards, causing us to lose interrupts. In a debug build, this can trigger panic within START_USE. Jason Wang reports that he can trigger the races artificially, by adding udelay() in virtqueue_enable_cb() after virtio_mb(). However, we must call napi_complete to clear NAPI_STATE_SCHED before polling the virtqueue for used buffers, otherwise napi_schedule_prep in a callback will fail, causing us to lose RX events. To fix, call virtqueue_enable_cb_prepare with NAPI_STATE_SCHED set (under napi lock), later call virtqueue_poll with NAPI_STATE_SCHED clear (outside the lock). Reported-by: Jason Wang <jasowang@redhat.com> Tested-by: Jason Wang <jasowang@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * virtio: support unlocked queue pollMichael S. Tsirkin2013-07-092-12/+48
|/ | | | | | | | | | | | | This adds a way to check ring empty state after enable_cb outside any locks. Will be used by virtio_net. Note: there's room for more optimization: caller is likely to have a memory barrier already, which means we might be able to get rid of a barrier here. Deferring this optimization until we do some benchmarking. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net/cadence/macb: fix bug/typo in extracting gem_irq_read_clear bitJongsung Kim2013-07-091-1/+1
| | | | | | Signed-off-by: Jongsung Kim <neidhard.kim@lge.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Documentation: Fix references to defunct linux-net@vger.kernel.orgGeert Uytterhoeven2013-07-092-4/+5
| | | | | | | | linux-net@vger.kernel.org was replaced by netdev@oss.sgi.com was replaced by netdev@vger.kernel.org. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net/fs: change busy poll time accountingEliezer Tamir2013-07-092-48/+38
| | | | | | | | | | | | | | | Suggested by Linus: Changed time accounting for busy-poll: - Make it microsecond based. - Use unsigned longs. - Revert back to use time_after instead of time_in_range. Reorder poll/select busy loop conditions: - Clear busy_flag after one time we can't busy-poll. - Only init busy_end if we actually are going to busy-poll. Added one more missing need_resched() test. Signed-off-by: Eliezer Tamir <eliezer.tamir@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: rename low latency sockets functions to busy pollEliezer Tamir2013-07-087-61/+80
| | | | | | | | | | | | | | Rename functions in include/net/ll_poll.h to busy wait. Clarify documentation about expected power use increase. Rename POLL_LL to POLL_BUSY_LOOP. Add need_resched() testing to poll/select busy loops. Note, that in select and poll can_busy_poll is dynamic and is updated continuously to reflect the existence of supported sockets with valid queue information. Signed-off-by: Eliezer Tamir <eliezer.tamir@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* bridge: fix some kernel warning in multicast timerCong Wang2013-07-062-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Several people reported the warning: "kernel BUG at kernel/timer.c:729!" and the stack trace is: #7 [ffff880214d25c10] mod_timer+501 at ffffffff8106d905 #8 [ffff880214d25c50] br_multicast_del_pg.isra.20+261 at ffffffffa0731d25 [bridge] #9 [ffff880214d25c80] br_multicast_disable_port+88 at ffffffffa0732948 [bridge] #10 [ffff880214d25cb0] br_stp_disable_port+154 at ffffffffa072bcca [bridge] #11 [ffff880214d25ce8] br_device_event+520 at ffffffffa072a4e8 [bridge] #12 [ffff880214d25d18] notifier_call_chain+76 at ffffffff8164aafc #13 [ffff880214d25d50] raw_notifier_call_chain+22 at ffffffff810858f6 #14 [ffff880214d25d60] call_netdevice_notifiers+45 at ffffffff81536aad #15 [ffff880214d25d80] dev_close_many+183 at ffffffff81536d17 #16 [ffff880214d25dc0] rollback_registered_many+168 at ffffffff81537f68 #17 [ffff880214d25de8] rollback_registered+49 at ffffffff81538101 #18 [ffff880214d25e10] unregister_netdevice_queue+72 at ffffffff815390d8 #19 [ffff880214d25e30] __tun_detach+272 at ffffffffa074c2f0 [tun] #20 [ffff880214d25e88] tun_chr_close+45 at ffffffffa074c4bd [tun] #21 [ffff880214d25ea8] __fput+225 at ffffffff8119b1f1 #22 [ffff880214d25ef0] ____fput+14 at ffffffff8119b3fe #23 [ffff880214d25f00] task_work_run+159 at ffffffff8107cf7f #24 [ffff880214d25f30] do_notify_resume+97 at ffffffff810139e1 #25 [ffff880214d25f50] int_signal+18 at ffffffff8164f292 this is due to I forgot to check if mp->timer is armed in br_multicast_del_pg(). This bug is introduced by commit 9f00b2e7cf241fa389733d41b6 (bridge: only expire the mdb entry when query is received). Same for __br_mdb_del(). Tested-by: poma <pomidorabelisima@gmail.com> Reported-by: LiYonghua <809674045@qq.com> Reported-by: Robert Hancock <hancockrwd@gmail.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Stephen Hemminger <stephen@networkplumber.org> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Cong Wang <amwang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* sfc: Fix memory leak when discarding scattered packetsBen Hutchings2013-07-051-7/+20
| | | | | | | | | | | | | | | | | Commit 2768935a4660 ('sfc: reuse pages to avoid DMA mapping/unmapping costs') did not fully take account of DMA scattering which was introduced immediately before. If a received packet is invalid and must be discarded, we only drop a reference to the first buffer's page, but we need to drop a reference for each buffer the packet used. I think this bug was missed partly because efx_recycle_rx_buffers() was not renamed and so no longer does what its name says. It does not change the state of buffers, but only prepares the underlying pages for recycling. Rename it accordingly. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* sit: fix tunnel update via netlinkNicolas Dichtel2013-07-041-2/+2
| | | | | | | | The device can stand in another netns, hence we need to do the lookup in netns tunnel->net. Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* dt:net:stmmac: Add dt specific phy reset callback support.Srinivas Kandagatla2013-07-043-2/+56
| | | | | | | | | | | | | | | | | | | | | | | | This patch adds phy reset callback support for stmmac driver via device trees. It adds three new properties to gmac device tree bindings to define the reset signal via gpio. With this patch users can conveniently pass reset gpio number with pre, pulse and post delay in micro secs via DTs. active low: _________ ____________ <pre-delay> |<pulse-delay> |<post-delay> | | |_______________| active high: ________________ <pre-delay> |<pulse-delay> |<post-delay> | | ________| |___________ Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* dt:net:stmmac: Add support to dwmac version 3.610 and 3.710Srinivas Kandagatla2013-07-042-0/+30
| | | | | | | | | | This patch adds dt support to dwmac version 3.610 and 3.710 these versions are integrated in STiH415 and STiH416 ARM A9 SOCs. To support these IP version, some of the device tree properties are extended. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* dt:net:stmmac: Allocate platform data only if its NULL.Srinivas Kandagatla2013-07-041-3/+3
| | | | | | | | | | | | | In some DT use-cases platform data might be already allocated and passed via AUXDATA. These are the cases where machine level code populates few callbacks in the platform data. This patch adds check and reuses platform_data if its valid, before allocating a new one. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com> Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net:stmmac: fix memleak in the open methodGiuseppe CAVALLARO2013-07-041-10/+10
| | | | | | | | | This patch is to fix a memory leak in the open method, it reviews error conditions freeing the resources previously allocated and not freed in cased of DMA failure. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* ipv6: rt6_check_neigh should successfully verify neigh if no NUD information ↵Hannes Frederic Sowa2013-07-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | are available After the removal of rt->n we do not create a neighbour entry at route insertion time (rt6_bind_neighbour is gone). As long as no neighbour is created because of "useful traffic" we skip this routing entry because rt6_check_neigh cannot pick up a valid neighbour (neigh == NULL) and thus returns false. This change was introduced by commit 887c95cc1da53f66a5890fdeab13414613010097 ("ipv6: Complete neighbour entry removal from dst_entry.") To quote RFC4191: "If the host has no information about the router's reachability, then the host assumes the router is reachable." and also: "A host MUST NOT probe a router's reachability in the absence of useful traffic that the host would have sent to the router if it were reachable." So, just assume the router is reachable and let's rt6_probe do the rest. We don't need to create a neighbour on route insertion time. If we don't compile with CONFIG_IPV6_ROUTER_PREF (RFC4191 support) a neighbour is only valid if its nud_state is NUD_VALID. I did not find any references that we should probe the router on route insertion time via the other RFCs. So skip this route in that case. v2: a) use IS_ENABLED instead of #ifdefs (thanks to Sergei Shtylyov) Reported-by: Pierre Emeriaud <petrus.lt@gmail.com> Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: ipv6: fix wrong ping_v6_sendmsg return valueLorenzo Colitti2013-07-031-1/+4
| | | | | | | | ping_v6_sendmsg currently returns 0 on success. It should return the number of bytes written instead. Signed-off-by: Lorenzo Colitti <lorenzo@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: ipv6: add missing lock in ping_v6_sendmsgLorenzo Colitti2013-07-031-0/+2
| | | | | Signed-off-by: Lorenzo Colitti <lorenzo@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* netem: fix possible NULL deref in netem_dequeue()Eric Dumazet2013-07-031-3/+5
| | | | | | | | | | | | | commit aec0a40a6f7884 ("netem: use rb tree to implement the time queue") added a regression if a child qdisc is attached to netem, as we perform a NULL dereference. Fix this by adding a temporary variable to cache netem_skb_cb(skb)->time_to_send. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: sock: fix TCP_SKB_MIN_TRUESIZEEric Dumazet2013-07-031-1/+1
| | | | | | | | | | | | | | | | | | | | | commit eea86af6b1e18d ("net: sock: adapt SOCK_MIN_RCVBUF and SOCK_MIN_SNDBUF") forgot the sk_buff alignment taken into account in __alloc_skb() : skb->truesize = SKB_TRUESIZE(size); While above commit fixed the sender issue, the receiver is still dropping the second packet (on loopback device), because the receiver socket can not really hold two skbs : First packet truesize already is above sk_rcvbuf, so even TCP coalescing cannot help. On a typical 64bit build, each tcp skb truesize is 2304, instead of 2272 Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Daniel Borkmann <dborkman@redhat.com> Cc: Neal Cardwell <ncardwell@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Tested-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net/mlx4: fix small memory leak on errorDan Carpenter2013-07-031-0/+1
| | | | | | | "work" needs to be freed before returning on this error path. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* core: Copy inner_protocol in copy_skb_header()Joe Stringer2013-07-031-0/+1
| | | | | | | | | | | | inner_protocol was added to struct sk_buff in 0d89d2035fe063461a5ddb609b2c12e7fb006e44 ("MPLS: Add limited GSO support"), which is scheduled to be included in v3.11. That patch did not update __copy_skb_header to copy the inner_protocol. Signed-off-by: Joe Stringer <joe@wand.net.nz> Signed-off-by: Simon Horman <horms@verge.net.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: fec: Add VLAN receive HW support.Jim Baxter2013-07-032-10/+55
| | | | | | | | This enables the driver to take advantage of the FEC VLAN indicator to improve performance. Signed-off-by: Jim Baxter <jim_baxter@mentor.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* alx: remove WoL supportJohannes Berg2013-07-034-323/+15
| | | | | | | | | Unfortunately, WoL is broken and the system will immediately resume after suspending, and I can't seem to figure out why. Remove WoL support until the issue can be found. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2013-07-03262-1270/+2175
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: drivers/net/ethernet/freescale/fec_main.c drivers/net/ethernet/renesas/sh_eth.c net/ipv4/gre.c The GRE conflict is between a bug fix (kfree_skb --> kfree_skb_list) and the splitting of the gre.c code into seperate files. The FEC conflict was two sets of changes adding ethtool support code in an "!CONFIG_M5272" CPP protected block. Finally the sh_eth.c conflict was between one commit add bits set in the .eesr_err_check mask whilst another commit removed the .tx_error_check member and assignments. Signed-off-by: David S. Miller <davem@davemloft.net>
| * Linux 3.10v3.10Linus Torvalds2013-06-301-1/+1
| |
| * Merge branch 'merge' of ↵Linus Torvalds2013-06-301-1/+2
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc Pull another powerpc fix from Benjamin Herrenschmidt: "I mentioned that while we had fixed the kernel crashes, EEH error recovery didn't always recover... It appears that I had a fix for that already in powerpc-next (with a stable CC). I cherry-picked it today and did a few tests and it seems that things now work quite well. The patch is also pretty simple, so I see no reason to wait before merging it." * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: powerpc/eeh: Fix fetching bus for single-dev-PE
| | * powerpc/eeh: Fix fetching bus for single-dev-PEGavin Shan2013-06-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While running Linux as guest on top of phyp, we possiblly have PE that includes single PCI device. However, we didn't return its PCI bus correctly and it leads to failure on recovery from EEH errors for single-dev-PE. The patch fixes the issue. Cc: <stable@vger.kernel.org> # v3.7+ Cc: Steve Best <sbest@us.ibm.com> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| * | Merge tag 'scsi-fixes' of ↵Linus Torvalds2013-06-3011-93/+61
| |\ \ | | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "This is a set of seven bug fixes. Several fcoe fixes for locking problems, initiator issues and a VLAN API change, all of which could eventually lead to data corruption, one fix for a qla2xxx locking problem which could lead to multiple completions of the same request (and subsequent data corruption) and a use after free in the ipr driver. Plus one minor MAINTAINERS file update" (only six bugfixes in this pull, since I had already pulled the fcoe API fix directly from Robert Love) * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: [SCSI] ipr: Avoid target_destroy accessing memory after it was freed [SCSI] qla2xxx: Fix for locking issue between driver ISR and mailbox routines MAINTAINERS: Fix fcoe mailing list libfc: extend ex_lock to protect all of fc_seq_send libfc: Correct check for initiator role libfcoe: Fix Conflicting FCFs issue in the fabric
| | * Merge tag 'fcoe1' into fixesJames Bottomley2013-06-261575-11275/+19854
| | |\ | | | | | | | | | | | | | | | | This patch fixes a critical bug that was introduced in 3.9 related to VLAN tagging FCoE frames.
| | * \ Merge tag 'fcoe' into fixesJames Bottomley2013-06-264-25/+31
| | |\ \ | | | | | | | | | | | | | | | 3.10 fixes
| | | * | MAINTAINERS: Fix fcoe mailing listNeil Horman2013-05-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FCoE mailing list has moved, updte it in the MAINTAINERS file Signed-off-by: Neil Horman <nhorman@tuxdriver.com> CC: Robert Love <robert.w.love@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com>
| | | * | libfc: extend ex_lock to protect all of fc_seq_sendNeil Horman2013-05-101-13/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This warning was reported recently: WARNING: at drivers/scsi/libfc/fc_exch.c:478 fc_seq_send+0x14f/0x160 [libfc]() (Not tainted) Hardware name: ProLiant DL120 G7 Modules linked in: tcm_fc target_core_iblock target_core_file target_core_pscsi target_core_mod configfs dm_round_robin dm_multipath 8021q garp stp llc bnx2fc cnic uio fcoe libfcoe libfc scsi_transport_fc scsi_tgt autofs4 sunrpc pcc_cpufreq ipv6 hpilo hpwdt e1000e microcode iTCO_wdt iTCO_vendor_support serio_raw shpchp ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif pata_acpi ata_generic ata_piix hpsa dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan] Pid: 5464, comm: target_completi Not tainted 2.6.32-272.el6.x86_64 #1 Call Trace: [<ffffffff8106b747>] ? warn_slowpath_common+0x87/0xc0 [<ffffffff8106b79a>] ? warn_slowpath_null+0x1a/0x20 [<ffffffffa025f7df>] ? fc_seq_send+0x14f/0x160 [libfc] [<ffffffffa035cbce>] ? ft_queue_status+0x16e/0x210 [tcm_fc] [<ffffffffa030a660>] ? target_complete_ok_work+0x0/0x4b0 [target_core_mod] [<ffffffffa030a766>] ? target_complete_ok_work+0x106/0x4b0 [target_core_mod] [<ffffffffa030a660>] ? target_complete_ok_work+0x0/0x4b0 [target_core_mod] [<ffffffff8108c760>] ? worker_thread+0x170/0x2a0 [<ffffffff810920d0>] ? autoremove_wake_function+0x0/0x40 [<ffffffff8108c5f0>] ? worker_thread+0x0/0x2a0 [<ffffffff81091d66>] ? kthread+0x96/0xa0 [<ffffffff8100c14a>] ? child_rip+0xa/0x20 [<ffffffff81091cd0>] ? kthread+0x0/0xa0 [<ffffffff8100c140>] ? child_rip+0x0/0x20 It occurs because fc_seq_send can have multiple contexts executing within it at the same time, and fc_seq_send doesn't consistently use the ep->ex_lock that protects this structure. Because of that, its possible for one context to clear the INIT bit in the ep->esb_state field while another checks it, leading to the above stack trace generated by the WARN_ON in the function. We should probably undertake the effort to convert access to the fc_exch structures to use rcu, but that a larger work item. To just fix this specific issue, we can just extend the ex_lock protection through the entire fc_seq_send path Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Reported-by: Gris Ge <fge@redhat.com> CC: Robert Love <robert.w.love@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com>
| | | * | libfc: Correct check for initiator roleMark Rustad2013-05-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The service_params field is being checked against the symbol FC_RPORT_ROLE_FCP_INITIATOR where it really should be checked against FCP_SPPF_INIT_FCN. Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Jack Morgan <jack.morgan@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com>
| | | * | libfcoe: Fix Conflicting FCFs issue in the fabricKrishna Mohan2013-05-101-10/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When multiple FCFs in use, and first FIP Advertisement received is with "Available for Login" i.e A bit set to 0, FCF selection will fail. The fix is to remove the assumption in the code that first FCF is only allowed selectable FCF. Consider the scenario fip->fcfs contains FCF1(fabricname X, marked A=0) FCF2(fabricname Y, marked A=1). list_first_entry(first) points to FCF1 and 1st iteration we ignore the FCF and on 2nd iteration we compare FCF1 & FCF2 fabric name and we fails to perform FCF selection. Signed-off-by: Krishna Mohan <krmohan@cisco.com> Reviewed-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com> Signed-off-by: Robert Love <robert.w.love@intel.com>
| | * | | [SCSI] ipr: Avoid target_destroy accessing memory after it was freedwenxiong@linux.vnet.ibm.com2013-05-122-19/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Defined target_ids,array_ids and vsets_ids as unsigned long to avoid target_destroy accessing memory after it was freed. Signed-off-by: Wen Xiong <wenxiong@linux.vnet.ibm.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| | * | | [SCSI] qla2xxx: Fix for locking issue between driver ISR and mailbox routinesgurinder.shergill@hp.com2013-05-125-49/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The driver uses ha->mbx_cmd_flags variable to pass information between its ISR and mailbox routines, however, it does so without the protection of any locks. Under certain conditions, this can lead to multiple mailbox command completions being signaled, which, in turn, leads to a false mailbox timeout error for the subsequently issued mailbox command. The issue occurs frequently but intermittenly with the Qlogic 8GFC mezz card during card initialization, resulting in card initialization failure. Signed-off-by: Gurinder (Sunny) Shergill <gurinder.shergill@hp.com> Acked-by: Saurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| * | | | Merge branch 'merge' of ↵Linus Torvalds2013-06-292-7/+14
| |\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc Pull powerpc fixes from Ben Herrenschmidt: "We discovered some breakage in our "EEH" (PCI Error Handling) code while doing error injection, due to a couple of regressions. One of them is due to a patch (37f02195bee9 "powerpc/pci: fix PCI-e devices rescan issue on powerpc platform") that, in hindsight, I shouldn't have merged considering that it caused more problems than it solved. Please pull those two fixes. One for a simple EEH address cache initialization issue. The other one is a patch from Guenter that I had originally planned to put in 3.11 but which happens to also fix that other regression (a kernel oops during EEH error handling and possibly hotplug). With those two, the couple of test machines I've hammered with error injection are remaining up now. EEH appears to still fail to recover on some devices, so there is another problem that Gavin is looking into but at least it's no longer crashing the kernel." * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: powerpc/pci: Improve device hotplug initialization powerpc/eeh: Add eeh_dev to the cache during boot
| | * | | | powerpc/pci: Improve device hotplug initializationGuenter Roeck2013-06-301-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 37f02195b (powerpc/pci: fix PCI-e devices rescan issue on powerpc platform) fixes a problem with interrupt and DMA initialization on hot plugged devices. With this commit, interrupt and DMA initialization for hot plugged devices is handled in the pci device enable function. This approach has a couple of drawbacks. First, it creates two code paths for device initialization, one for hot plugged devices and another for devices known during the initial PCI scan. Second, the initialization code for hot plugged devices is only called when the device is enabled, ie typically in the probe function. Also, the platform specific setup code is called each time pci_enable_device() is called, not only once during device discovery, meaning it is actually called multiple times, once for devices discovered during the initial scan and again each time a driver is re-loaded. The visible result is that interrupt pins are only assigned to hot plugged devices when the device driver is loaded. Effectively this changes the PCI probe API, since pci_dev->irq and the device's dma configuration will now only be valid after pci_enable() was called at least once. A more subtle change is that platform specific PCI device setup is moved from device discovery into the driver's probe function, more specifically into the pci_enable_device() call. To fix the inconsistencies, add new function pcibios_add_device. Call pcibios_setup_device from pcibios_setup_bus_devices if device setup is not complete, and from pcibios_add_device if bus setup is complete. With this change, device setup code is moved back into device initialization, and called exactly once for both static and hot plugged devices. [ This also fixes a regression introduced by the above patch which causes dev->irq to be overwritten under some cirumstances after MSIs have been enabled for the device which leads to crashes due to the MSI core "hijacking" dev->irq to store the base MSI number and not the LSI. --BenH ] Cc: Yuanquan Chen <Yuanquan.Chen@freescale.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Hiroo Matsumoto <matsumoto.hiroo@jp.fujitsu.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| | * | | | powerpc/eeh: Add eeh_dev to the cache during bootThadeu Lima de Souza Cascardo2013-06-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit f8f7d63fd96ead101415a1302035137a866f8998 ("powerpc/eeh: Trace eeh device from I/O cache") broke EEH on pseries for devices that were present during boot and have not been hotplugged/DLPARed. eeh_check_failure will get the eeh_dev from the cache, and will get NULL. eeh_addr_cache_build adds the addresses to the cache, but eeh_dev for the giving pci_device is not set yet. Just reordering the call to eeh_addr_cache_insert_dev works fine. The ordering is similar to the one in eeh_add_device_late. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Acked-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| * | | | | ARM: dt: Only print warning, not WARN() on bad cpu map in device treeOlof Johansson2013-06-291-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to recent changes and expecations of proper cpu bindings, there are now cases for many of the in-tree devicetrees where a WARN() will hit on boot due to badly formatted /cpus nodes. Downgrade this to a pr_warn() to be less alarmist, since it's not a new problem. Tested on Arndale, Cubox, Seaboard and Panda ES. Panda hits the WARN without this, the others do not. Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * | | | | Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds2013-06-293-13/+14
| |\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull crypto fix from Herbert Xu: "This fixes a crash in the crypto layer exposed by an SCTP test tool" * git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: algboss - Hold ref count on larval
| | * | | | | crypto: algboss - Hold ref count on larvalHerbert Xu2013-06-253-13/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Thu, Jun 20, 2013 at 10:00:21AM +0200, Daniel Borkmann wrote: > After having fixed a NULL pointer dereference in SCTP 1abd165e ("net: > sctp: fix NULL pointer dereference in socket destruction"), I ran into > the following NULL pointer dereference in the crypto subsystem with > the same reproducer, easily hit each time: > > BUG: unable to handle kernel NULL pointer dereference at (null) > IP: [<ffffffff81070321>] __wake_up_common+0x31/0x90 > PGD 0 > Oops: 0000 [#1] SMP > Modules linked in: padlock_sha(F-) sha256_generic(F) sctp(F) libcrc32c(F) [..] > CPU: 6 PID: 3326 Comm: cryptomgr_probe Tainted: GF 3.10.0-rc5+ #1 > Hardware name: Dell Inc. PowerEdge T410/0H19HD, BIOS 1.6.3 02/01/2011 > task: ffff88007b6cf4e0 ti: ffff88007b7cc000 task.ti: ffff88007b7cc000 > RIP: 0010:[<ffffffff81070321>] [<ffffffff81070321>] __wake_up_common+0x31/0x90 > RSP: 0018:ffff88007b7cde08 EFLAGS: 00010082 > RAX: ffffffffffffffe8 RBX: ffff88003756c130 RCX: 0000000000000000 > RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffff88003756c130 > RBP: ffff88007b7cde48 R08: 0000000000000000 R09: ffff88012b173200 > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000282 > R13: ffff88003756c138 R14: 0000000000000000 R15: 0000000000000000 > FS: 0000000000000000(0000) GS:ffff88012fc60000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 0000000000000000 CR3: 0000000001a0b000 CR4: 00000000000007e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Stack: > ffff88007b7cde28 0000000300000000 ffff88007b7cde28 ffff88003756c130 > 0000000000000282 ffff88003756c128 ffffffff81227670 0000000000000000 > ffff88007b7cde78 ffffffff810722b7 ffff88007cdcf000 ffffffff81a90540 > Call Trace: > [<ffffffff81227670>] ? crypto_alloc_pcomp+0x20/0x20 > [<ffffffff810722b7>] complete_all+0x47/0x60 > [<ffffffff81227708>] cryptomgr_probe+0x98/0xc0 > [<ffffffff81227670>] ? crypto_alloc_pcomp+0x20/0x20 > [<ffffffff8106760e>] kthread+0xce/0xe0 > [<ffffffff81067540>] ? kthread_freezable_should_stop+0x70/0x70 > [<ffffffff815450dc>] ret_from_fork+0x7c/0xb0 > [<ffffffff81067540>] ? kthread_freezable_should_stop+0x70/0x70 > Code: 41 56 41 55 41 54 53 48 83 ec 18 66 66 66 66 90 89 75 cc 89 55 c8 > 4c 8d 6f 08 48 8b 57 08 41 89 cf 4d 89 c6 48 8d 42 e > RIP [<ffffffff81070321>] __wake_up_common+0x31/0x90 > RSP <ffff88007b7cde08> > CR2: 0000000000000000 > ---[ end trace b495b19270a4d37e ]--- > > My assumption is that the following is happening: the minimal SCTP > tool runs under ``echo 1 > /proc/sys/net/sctp/auth_enable'', hence > it's making use of crypto_alloc_hash() via sctp_auth_init_hmacs(). > It forks itself, heavily allocates, binds, listens and waits in > accept on sctp sockets, and then randomly kills some of them (no > need for an actual client in this case to hit this). Then, again, > allocating, binding, etc, and then killing child processes. > > The problem that might be happening here is that cryptomgr requests > the module to probe/load through cryptomgr_schedule_probe(), but > before the thread handler cryptomgr_probe() returns, we return from > the wait_for_completion_interruptible() function and probably already > have cleared up larval, thus we run into a NULL pointer dereference > when in cryptomgr_probe() complete_all() is being called. > > If we wait with wait_for_completion() instead, this panic will not > occur anymore. This is valid, because in case a signal is pending, > cryptomgr_probe() returns from probing anyway with properly calling > complete_all(). The use of wait_for_completion_interruptible is intentional so that we don't lock up the thread if a bug causes us to never wake up. This bug is caused by the helper thread using the larval without holding a reference count on it. If the helper thread completes after the original thread requesting for help has gone away and destroyed the larval, then we get the crash above. So the fix is to hold a reference count on the larval. Cc: <stable@vger.kernel.org> # 3.6+ Reported-by: Daniel Borkmann <dborkman@redhat.com> Tested-by: Daniel Borkmann <dborkman@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | | | | | Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2013-06-291-0/+5
| |\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm/qxl fix from Dave Airlie: "Bad me forgot an access check, possible security issue, but since this is the first kernel with it, should be fine to just put it in now" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/qxl: add missing access check for execbuffer ioctl
| | * | | | | | drm/qxl: add missing access check for execbuffer ioctlDave Airlie2013-06-281-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reported-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | | | | | Fix: kernel/ptrace.c: ptrace_peek_siginfo() missing __put_user() validationMathieu Desnoyers2013-06-291-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This __put_user() could be used by unprivileged processes to write into kernel memory. The issue here is that even if copy_siginfo_to_user() fails, the error code is not checked before __put_user() is executed. Luckily, ptrace_peek_siginfo() has been added within the 3.10-rc cycle, so it has not hit a stable release yet. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Acked-by: Oleg Nesterov <oleg@redhat.com> Cc: Andrey Vagin <avagin@openvz.org> Cc: Roland McGrath <roland@redhat.com> Cc: Paul McKenney <paulmck@linux.vnet.ibm.com> Cc: David Howells <dhowells@redhat.com> Cc: Dave Jones <davej@redhat.com> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: Pedro Alves <palves@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
OpenPOWER on IntegriCloud