commit 8bf3379a74bc9132751bfa685bad2da318fd59d7 Author: Greg Kroah-Hartman Date: Thu Aug 29 09:47:51 2013 -0700 Linux 3.10.10 commit ae61fd4496f9d9290b9e84fc373818b2ee780137 Author: Kent Overstreet Date: Wed Jun 26 17:25:38 2013 -0700 bcache: FUA fixes commit e49c7c374e7aacd1f04ecbc21d9dbbeeea4a77d6 upstream. Journal writes need to be marked FUA, not just REQ_FLUSH. And btree node writes have... weird ordering requirements. Signed-off-by: Kent Overstreet Signed-off-by: Greg Kroah-Hartman commit ba5c60fc8f5f574c7cec70740ca19d358b780c57 Author: Kumar Amit Mehta Date: Tue May 28 00:31:15 2013 -0700 md: bcache: io.c: fix a potential NULL pointer dereference commit 5c694129c8db6d89c9be109049a16510b2f70f6d upstream. bio_alloc_bioset returns NULL on failure. This fix adds a missing check for potential NULL pointer dereferencing. Signed-off-by: Kumar Amit Mehta Signed-off-by: Kent Overstreet Signed-off-by: Greg Kroah-Hartman commit 644f5d570740c90439fdf69e8b47647584c6dc2f Author: Tomas Winkler Date: Wed Jul 17 15:13:17 2013 +0300 mei: me: fix waiting for hw ready commit dab9bf41b23fe700c4a74133e41eb6a21706031e upstream. 1. MEI_INTEROP_TIMEOUT is in seconds not in jiffies so we use mei_secs_to_jiffies macro While cold boot is fast this is relevant in resume 2. wait_event_interruptible_timeout can return with -ERESTARTSYS so do not override it with -ETIMEDOUT 3.Adjust error message Tested-by: Shuah Khan Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 47e1cf336bc708bb59ebfcc01540dffecd16862e Author: Tomas Winkler Date: Wed Jul 17 15:13:16 2013 +0300 mei: don't have to clean the state on power up commit 99f22c4ef24cf87b0dae6aabe6b5e620b62961d9 upstream. When powering up, we don't have to clean up the device state nothing is connected. Tested-by: Shuah Khan Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 7dae89cb15ebdc7e286b884cd79f3a4b94fcdff4 Author: Tomas Winkler Date: Wed Jul 17 15:13:15 2013 +0300 mei: me: fix reset state machine commit 315a383ad7dbd484fafb93ef08038e3dbafbb7a8 upstream. ME HW ready bit is down after hw reset was asserted or on error. Only on error we need to enter the reset flow, additional reset need to be prevented when reset was triggered during initialization , power up/down or a reset is already in progress Tested-by: Shuah Khan Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 061cc2478cdacc2de2e3dd0cdfdd9bfcc5be5d93 Author: David Vrabel Date: Fri Aug 16 15:42:55 2013 +0100 x86/xen: do not identity map UNUSABLE regions in the machine E820 commit 3bc38cbceb85881a8eb789ee1aa56678038b1909 upstream. If there are UNUSABLE regions in the machine memory map, dom0 will attempt to map them 1:1 which is not permitted by Xen and the kernel will crash. There isn't anything interesting in the UNUSABLE region that the dom0 kernel needs access to so we can avoid making the 1:1 mapping and treat it as RAM. We only do this for dom0, as that is where tboot case shows up. A PV domU could have an UNUSABLE region in its pseudo-physical map and would need to be handled in another patch. This fixes a boot failure on hosts with tboot. tboot marks a region in the e820 map as unusable and the dom0 kernel would attempt to map this region and Xen does not permit unusable regions to be mapped by guests. (XEN) 0000000000000000 - 0000000000060000 (usable) (XEN) 0000000000060000 - 0000000000068000 (reserved) (XEN) 0000000000068000 - 000000000009e000 (usable) (XEN) 0000000000100000 - 0000000000800000 (usable) (XEN) 0000000000800000 - 0000000000972000 (unusable) tboot marked this region as unusable. (XEN) 0000000000972000 - 00000000cf200000 (usable) (XEN) 00000000cf200000 - 00000000cf38f000 (reserved) (XEN) 00000000cf38f000 - 00000000cf3ce000 (ACPI data) (XEN) 00000000cf3ce000 - 00000000d0000000 (reserved) (XEN) 00000000e0000000 - 00000000f0000000 (reserved) (XEN) 00000000fe000000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000630000000 (usable) Signed-off-by: David Vrabel [v1: Altered the patch and description with domU's with UNUSABLE regions] Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit ff1a668bc01c811ffcf19a3d43af58d7bd658986 Author: Radu Caragea Date: Wed Aug 21 20:55:59 2013 +0300 x86 get_unmapped_area: Access mmap_legacy_base through mm_struct member commit 41aacc1eea645c99edbe8fbcf78a97dc9b862adc upstream. This is the updated version of df54d6fa5427 ("x86 get_unmapped_area(): use proper mmap base for bottom-up direction") that only randomizes the mmap base address once. Signed-off-by: Radu Caragea Reported-and-tested-by: Jeff Shorey Cc: Andrew Morton Cc: Michel Lespinasse Cc: Oleg Nesterov Cc: Rik van Riel Cc: Ingo Molnar Cc: Adrian Sendroiu Cc: Kamal Mostafa Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bd4b69c1f7f58fc28fb636a3be006770edf58d68 Author: Linus Torvalds Date: Thu Aug 22 09:13:06 2013 -0700 Revert "x86 get_unmapped_area(): use proper mmap base for bottom-up direction" commit 5ea80f76a56605a190a7ea16846c82aa63dbd0aa upstream. This reverts commit df54d6fa54275ce59660453e29d1228c2b45a826. The commit isn't necessarily wrong, but because it recalculates the random mmap_base every time, it seems to confuse user memory allocators that expect contiguous mmap allocations even when the mmap address isn't specified. In particular, the MATLAB Java runtime seems to be unhappy. See https://bugzilla.kernel.org/show_bug.cgi?id=60774 So we'll want to apply the random offset only once, and Radu has a patch for that. Revert this older commit in order to apply the other one. Reported-by: Jeff Shorey Cc: Radu Caragea Cc: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 32b8d5f874e1c6ca88ec4f2d10cd885b3d70cf17 Author: Roland Dreier Date: Mon Aug 5 17:55:01 2013 -0700 SCSI: sg: Fix user memory corruption when SG_IO is interrupted by a signal commit 35dc248383bbab0a7203fca4d722875bc81ef091 upstream. There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances leads to one process writing data into the address space of some other random unrelated process if the ioctl is interrupted by a signal. What happens is the following: - A process issues an SG_IO ioctl with direction DXFER_FROM_DEV (ie the underlying SCSI command will transfer data from the SCSI device to the buffer provided in the ioctl) - Before the command finishes, a signal is sent to the process waiting in the ioctl. This will end up waking up the sg_ioctl() code: result = wait_event_interruptible(sfp->read_wait, (srp_done(sfp, srp) || sdp->detached)); but neither srp_done() nor sdp->detached is true, so we end up just setting srp->orphan and returning to userspace: srp->orphan = 1; write_unlock_irq(&sfp->rq_list_lock); return result; /* -ERESTARTSYS because signal hit process */ At this point the original process is done with the ioctl and blithely goes ahead handling the signal, reissuing the ioctl, etc. - Eventually, the SCSI command issued by the first ioctl finishes and ends up in sg_rq_end_io(). At the end of that function, we run through: write_lock_irqsave(&sfp->rq_list_lock, iflags); if (unlikely(srp->orphan)) { if (sfp->keep_orphan) srp->sg_io_owned = 0; else done = 0; } srp->done = done; write_unlock_irqrestore(&sfp->rq_list_lock, iflags); if (likely(done)) { /* Now wake up any sg_read() that is waiting for this * packet. */ wake_up_interruptible(&sfp->read_wait); kill_fasync(&sfp->async_qp, SIGPOLL, POLL_IN); kref_put(&sfp->f_ref, sg_remove_sfp); } else { INIT_WORK(&srp->ew.work, sg_rq_end_io_usercontext); schedule_work(&srp->ew.work); } Since srp->orphan *is* set, we set done to 0 (assuming the userspace app has not set keep_orphan via an SG_SET_KEEP_ORPHAN ioctl), and therefore we end up scheduling sg_rq_end_io_usercontext() to run in a workqueue. - In workqueue context we go through sg_rq_end_io_usercontext() -> sg_finish_rem_req() -> blk_rq_unmap_user() -> ... -> bio_uncopy_user() -> __bio_copy_iov() -> copy_to_user(). The key point here is that we are doing copy_to_user() on a workqueue -- that is, we're on a kernel thread with current->mm equal to whatever random previous user process was scheduled before this kernel thread. So we end up copying whatever data the SCSI command returned to the virtual address of the buffer passed into the original ioctl, but it's quite likely we do this copying into a different address space! As suggested by James Bottomley , add a check for current->mm (which is NULL if we're on a kernel thread without a real userspace address space) in bio_uncopy_user(), and skip the copy if we're on a kernel thread. There's no reason that I can think of for any caller of bio_uncopy_user() to want to do copying on a kernel thread with a random active userspace address space. Huge thanks to Costa Sapuntzakis for the original pointer to this bug in the sg code. Signed-off-by: Roland Dreier Tested-by: David Milburn Cc: Jens Axboe Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit a271397a97869112f0b77ef7e162f64cf3c55113 Author: Anton Blanchard Date: Thu Aug 8 17:47:34 2013 +1000 SCSI: lpfc: Don't force CONFIG_GENERIC_CSUM on commit f5944daa0a72316077435c18a6571e73ed338332 upstream. We want ppc64 to be able to select between optimised assembly checksum routines in big endian and the generic lib/checksum.c routines in little endian. The lpfc driver is forcing CONFIG_GENERIC_CSUM on which means we are unable to make the decision to enable it in the arch Kconfig. If the option exists it is always forced on. This got introduced in 3.10 via commit 6a7252fdb0c3 ([SCSI] lpfc: fix up Kconfig dependencies). I spoke to Randy about it and the original issue was with CRC_T10DIF not being defined. As such, remove the select of CONFIG_GENERIC_CSUM. Signed-off-by: Anton Blanchard Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit e1a289ee6734dd5f9a81a260f3027ad8010f530a Author: Martin Peschke Date: Thu Aug 22 17:45:37 2013 +0200 SCSI: zfcp: fix schedule-inside-lock in scsi_device list loops commit 924dd584b198a58aa7cb3efefd8a03326550ce8f upstream. BUG: sleeping function called from invalid context at kernel/workqueue.c:2752 in_atomic(): 1, irqs_disabled(): 1, pid: 360, name: zfcperp0.0.1700 CPU: 1 Not tainted 3.9.3+ #69 Process zfcperp0.0.1700 (pid: 360, task: 0000000075b7e080, ksp: 000000007476bc30) Call Trace: ([<00000000001165de>] show_trace+0x106/0x154) [<00000000001166a0>] show_stack+0x74/0xf4 [<00000000006ff646>] dump_stack+0xc6/0xd4 [<000000000017f3a0>] __might_sleep+0x128/0x148 [<000000000015ece8>] flush_work+0x54/0x1f8 [<00000000001630de>] __cancel_work_timer+0xc6/0x128 [<00000000005067ac>] scsi_device_dev_release_usercontext+0x164/0x23c [<0000000000161816>] execute_in_process_context+0x96/0xa8 [<00000000004d33d8>] device_release+0x60/0xc0 [<000000000048af48>] kobject_release+0xa8/0x1c4 [<00000000004f4bf2>] __scsi_iterate_devices+0xfa/0x130 [<000003ff801b307a>] zfcp_erp_strategy+0x4da/0x1014 [zfcp] [<000003ff801b3caa>] zfcp_erp_thread+0xf6/0x2b0 [zfcp] [<000000000016b75a>] kthread+0xf2/0xfc [<000000000070c9de>] kernel_thread_starter+0x6/0xc [<000000000070c9d8>] kernel_thread_starter+0x0/0xc Apparently, the ref_count for some scsi_device drops down to zero, triggering device removal through execute_in_process_context(), while the lldd error recovery thread iterates through a scsi device list. Unfortunately, execute_in_process_context() decides to immediately execute that device removal function, instead of scheduling asynchronous execution, since it detects process context and thinks it is safe to do so. But almost all calls to shost_for_each_device() in our lldd are inside spin_lock_irq, even in thread context. Obviously, schedule() inside spin_lock_irq sections is a bad idea. Change the lldd to use the proper iterator function, __shost_for_each_device(), in combination with required locking. Occurences that need to be changed include all calls in zfcp_erp.c, since those might be executed in zfcp error recovery thread context with a lock held. Other occurences of shost_for_each_device() in zfcp_fsf.c do not need to be changed (no process context, no surrounding locking). The problem was introduced in Linux 2.6.37 by commit b62a8d9b45b971a67a0f8413338c230e3117dff5 "[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit". Reported-by: Christian Borntraeger Signed-off-by: Martin Peschke Signed-off-by: Steffen Maier Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit bda5d1efa09527e443a6990f81459779a313e24d Author: Martin Peschke Date: Thu Aug 22 17:45:36 2013 +0200 SCSI: zfcp: fix lock imbalance by reworking request queue locking commit d79ff142624e1be080ad8d09101f7004d79c36e1 upstream. This patch adds wait_event_interruptible_lock_irq_timeout(), which is a straight-forward descendant of wait_event_interruptible_timeout() and wait_event_interruptible_lock_irq(). The zfcp driver used to call wait_event_interruptible_timeout() in combination with some intricate and error-prone locking. Using wait_event_interruptible_lock_irq_timeout() as a replacement nicely cleans up that locking. This rework removes a situation that resulted in a locking imbalance in zfcp_qdio_sbal_get(): BUG: workqueue leaked lock or atomic: events/1/0xffffff00/10 last function: zfcp_fc_wka_port_offline+0x0/0xa0 [zfcp] It was introduced by commit c2af7545aaff3495d9bf9a7608c52f0af86fb194 "[SCSI] zfcp: Do not wait for SBALs on stopped queue", which had a new code path related to ZFCP_STATUS_ADAPTER_QDIOUP that took an early exit without a required lock being held. The problem occured when a special, non-SCSI I/O request was being submitted in process context, when the adapter's queues had been torn down. In this case the bug surfaced when the Fibre Channel port connection for a well-known address was closed during a concurrent adapter shut-down procedure, which is a rare constellation. This patch also fixes these warnings from the sparse tool (make C=1): drivers/s390/scsi/zfcp_qdio.c:224:12: warning: context imbalance in 'zfcp_qdio_sbal_check' - wrong count at exit drivers/s390/scsi/zfcp_qdio.c:244:5: warning: context imbalance in 'zfcp_qdio_sbal_get' - unexpected unlock Last but not least, we get rid of that crappy lock-unlock-lock sequence at the beginning of the critical section. It is okay to call zfcp_erp_adapter_reopen() with req_q_lock held. Reported-by: Mikulas Patocka Reported-by: Heiko Carstens Signed-off-by: Martin Peschke Signed-off-by: Steffen Maier Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 67bdd3c0dc4dc00fc1e708fc9f326304d88cc8be Author: Emmanuel Grumbach Date: Mon Jul 29 23:05:18 2013 +0300 iwlwifi: pcie: disable L1 Active after pci_enable_device commit eabc4ac5d7606a57ee2b7308cb7323ea8f60183b upstream. As Arjan pointed out, we mustn't do anything related to PCI configuration until the device is properly enabled with pci_enable_device(). Reported-by: Arjan van de Ven Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 753fb619d10ed87c9ab5b75e83dd464244986f82 Author: Stanislaw Gruszka Date: Fri Jul 26 15:29:09 2013 +0200 iwlwifi: dvm: fix calling ieee80211_chswitch_done() with NULL commit 9186a1fd9ed190739423db84bc344d258ef3e3d7 upstream. If channel switch is pending and we remove interface we can crash like showed below due to passing NULL vif to mac80211: BUG: unable to handle kernel paging request at fffffffffffff8cc IP: [] strnlen+0xd/0x40 Call Trace: [] string.isra.3+0x3e/0xd0 [] vsnprintf+0x219/0x640 [] vscnprintf+0x11/0x30 [] vprintk_emit+0x115/0x4f0 [] printk+0x61/0x63 [] ieee80211_chswitch_done+0xaf/0xd0 [mac80211] [] iwl_chswitch_done+0x34/0x40 [iwldvm] [] iwlagn_commit_rxon+0x2a3/0xdc0 [iwldvm] [] ? iwlagn_set_rxon_chain+0x180/0x2c0 [iwldvm] [] iwl_set_mode+0x36/0x40 [iwldvm] [] iwlagn_mac_remove_interface+0x8d/0x1b0 [iwldvm] [] ieee80211_do_stop+0x29d/0x7f0 [mac80211] This is because we nulify ctx->vif in iwlagn_mac_remove_interface() before calling some other functions that teardown interface. To fix just check ctx->vif on iwl_chswitch_done(). We should not call ieee80211_chswitch_done() as channel switch works were already canceled by mac80211 in ieee80211_do_stop() -> ieee80211_mgd_stop(). Resolve: https://bugzilla.redhat.com/show_bug.cgi?id=979581 Reported-by: Lukasz Jagiello Signed-off-by: Stanislaw Gruszka Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 323d5a7b5762c2fac8d1a5bb6d24d6d4e0efbfb3 Author: Terry Suereth Date: Sat Aug 17 15:53:12 2013 -0400 libata: apply behavioral quirks to sil3826 PMP commit 8ffff94d20b7eb446e848e0046107d51b17a20a8 upstream. Fixing support for the Silicon Image 3826 port multiplier, by applying to it the same quirks applied to the Silicon Image 3726. Specifically fixes the repeated timeout/reset process which previously afflicted the 3726, as described from line 290. Slightly based on notes from: https://bugzilla.redhat.com/show_bug.cgi?id=890237 Signed-off-by: Terry Suereth Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 9e50b0dd45dd3a26edf83b3f78117a6765fbe8a2 Author: Dan Carpenter Date: Fri Aug 9 12:52:31 2013 +0300 Hostap: copying wrong data prism2_ioctl_giwaplist() commit 909bd5926d474e275599094acad986af79671ac9 upstream. We want the data stored in "addr" and "qual", but the extra ampersands mean we are copying stack data instead. Signed-off-by: Dan Carpenter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 2650a684ca1c26831ecc552c269ffd7a8def3694 Author: Anthony Foiani Date: Mon Aug 19 19:20:30 2013 -0600 sata_fsl: save irqs while coalescing commit 99bbdfa6bdcb4bdf5be914a48e9b46941bf30819 upstream. Before this patch, I was seeing the following lockdep splat on my MPC8315 (PPC32) target: [ 9.086051] ================================= [ 9.090393] [ INFO: inconsistent lock state ] [ 9.094744] 3.9.7-ajf-gc39503d #1 Not tainted [ 9.099087] --------------------------------- [ 9.103432] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [ 9.109431] scsi_eh_1/39 [HC1[1]:SC0[0]:HE0:SE1] takes: [ 9.114642] (&(&host->lock)->rlock){?.+...}, at: [] sata_fsl_interrupt+0x50/0x250 [ 9.123137] {HARDIRQ-ON-W} state was registered at: [ 9.128004] [] lock_acquire+0x90/0xf4 [ 9.132737] [] _raw_spin_lock+0x34/0x4c [ 9.137645] [] fsl_sata_set_irq_coalescing+0x68/0x100 [ 9.143750] [] sata_fsl_init_controller+0xa8/0xc0 [ 9.149505] [] sata_fsl_probe+0x17c/0x2e8 [ 9.154568] [] driver_probe_device+0x90/0x248 [ 9.159987] [] __driver_attach+0xc4/0xc8 [ 9.164964] [] bus_for_each_dev+0x5c/0xa8 [ 9.170028] [] bus_add_driver+0x100/0x26c [ 9.175091] [] driver_register+0x88/0x198 [ 9.180155] [] do_one_initcall+0x58/0x1b4 [ 9.185226] [] kernel_init_freeable+0x118/0x1c0 [ 9.190823] [] kernel_init+0x18/0x108 [ 9.195542] [] ret_from_kernel_thread+0x64/0x6c [ 9.201142] irq event stamp: 160 [ 9.204366] hardirqs last enabled at (159): [] _raw_spin_unlock_irq+0x30/0x50 [ 9.212469] hardirqs last disabled at (160): [] reenable_mmu+0x30/0x88 [ 9.219867] softirqs last enabled at (144): [] __do_softirq+0x168/0x218 [ 9.227435] softirqs last disabled at (137): [] irq_exit+0xa8/0xb4 [ 9.234481] [ 9.234481] other info that might help us debug this: [ 9.240995] Possible unsafe locking scenario: [ 9.240995] [ 9.246898] CPU0 [ 9.249337] ---- [ 9.251776] lock(&(&host->lock)->rlock); [ 9.255878] [ 9.258492] lock(&(&host->lock)->rlock); [ 9.262765] [ 9.262765] *** DEADLOCK *** [ 9.262765] [ 9.268684] no locks held by scsi_eh_1/39. [ 9.272767] [ 9.272767] stack backtrace: [ 9.277117] Call Trace: [ 9.279589] [cfff9da0] [c0008504] show_stack+0x48/0x150 (unreliable) [ 9.285972] [cfff9de0] [c0447d5c] print_usage_bug.part.35+0x268/0x27c [ 9.292425] [cfff9e10] [c006ace4] mark_lock+0x2ac/0x658 [ 9.297660] [cfff9e40] [c006b7e4] __lock_acquire+0x754/0x1840 [ 9.303414] [cfff9ee0] [c006cdb8] lock_acquire+0x90/0xf4 [ 9.308745] [cfff9f20] [c043ef04] _raw_spin_lock+0x34/0x4c [ 9.314250] [cfff9f30] [c02f4168] sata_fsl_interrupt+0x50/0x250 [ 9.320187] [cfff9f70] [c0079ff0] handle_irq_event_percpu+0x90/0x254 [ 9.326547] [cfff9fc0] [c007a1fc] handle_irq_event+0x48/0x78 [ 9.332220] [cfff9fe0] [c007c95c] handle_level_irq+0x9c/0x104 [ 9.337981] [cfff9ff0] [c000d978] call_handle_irq+0x18/0x28 [ 9.343568] [cc7139f0] [c000608c] do_IRQ+0xf0/0x1a8 [ 9.348464] [cc713a20] [c000fc8c] ret_from_except+0x0/0x14 [ 9.353983] --- Exception: 501 at _raw_spin_unlock_irq+0x40/0x50 [ 9.353983] LR = _raw_spin_unlock_irq+0x30/0x50 [ 9.364839] [cc713af0] [c043db10] wait_for_common+0xac/0x188 [ 9.370513] [cc713b30] [c02ddee4] ata_exec_internal_sg+0x2b0/0x4f0 [ 9.376699] [cc713be0] [c02de18c] ata_exec_internal+0x68/0xa8 [ 9.382454] [cc713c20] [c02de4b8] ata_dev_read_id+0x158/0x594 [ 9.388205] [cc713ca0] [c02ec244] ata_eh_recover+0xd88/0x13d0 [ 9.393962] [cc713d20] [c02f2520] sata_pmp_error_handler+0xc0/0x8ac [ 9.400234] [cc713dd0] [c02ecdc8] ata_scsi_port_error_handler+0x464/0x5e8 [ 9.407023] [cc713e10] [c02ecfd0] ata_scsi_error+0x84/0xb8 [ 9.412528] [cc713e40] [c02c4974] scsi_error_handler+0xd8/0x47c [ 9.418457] [cc713eb0] [c004737c] kthread+0xa8/0xac [ 9.423355] [cc713f40] [c000f6b8] ret_from_kernel_thread+0x64/0x6c This fix was suggested by Bhushan Bharat , and was discussed in email at: http://linuxppc.10917.n7.nabble.com/MPC8315-reboot-failure-lockdep-splat-possibly-related-tp75162.html Same patch successfully tested with 3.9.7. linux-next compiled but not tested on hardware. This patch is based off linux-next tag next-20130819 (which is commit 66a01bae29d11916c09f9f5a937cafe7d402e4a5 ) Signed-off-by: Anthony Foiani Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 2356788f31dee0b3c03b3ef594fd113a861b29c1 Author: Anatolij Gustschin Date: Wed Aug 21 17:43:31 2013 +0200 usb: phy: fix build breakage commit 52d5b9aba1f5790ca3231c262979c2c3e26dd99b upstream. Commit 94ae9843 (usb: phy: rename all phy drivers to phy-$name-usb.c) renamed drivers/usb/phy/otg_fsm.h to drivers/usb/phy/phy-fsm-usb.h but changed drivers/usb/phy/phy-fsm-usb.c to include not existing "phy-otg-fsm.h" instead of new "phy-fsm-usb.h". This breaks building: ... drivers/usb/phy/phy-fsm-usb.c:32:25: fatal error: phy-otg-fsm.h: No such file or directory compilation terminated. make[3]: *** [drivers/usb/phy/phy-fsm-usb.o] Error 1 This commit also missed to modify drivers/usb/phy/phy-fsl-usb.h to include new "phy-fsm-usb.h" instead of "otg_fsm.h" resulting in another build breakage: ... In file included from drivers/usb/phy/phy-fsl-usb.c:46:0: drivers/usb/phy/phy-fsl-usb.h:18:21: fatal error: otg_fsm.h: No such file or directory compilation terminated. make[3]: *** [drivers/usb/phy/phy-fsl-usb.o] Error 1 Fix both issues. Signed-off-by: Anatolij Gustschin Signed-off-by: Greg Kroah-Hartman commit 6797361e99b0103055b26c0a3d1079bf2402a3a0 Author: Daniel Drake Date: Thu Aug 22 16:35:43 2013 -0700 drivers/platform/olpc/olpc-ec.c: initialise earlier commit 93dbc1b3b506e16c1f6d5b5dcfe756a85cb1dc58 upstream. Being a low-level component, various drivers (e.g. olpc-battery) assume that it is ok to communicate with the OLPC Embedded Controller during probe. Therefore the OLPC EC driver must be initialised before other drivers try to use it. This was the case until it was recently moved out of arch/x86 and restructured around commits ac2504151f5a ("Platform: OLPC: turn EC driver into a platform_driver") and 85f90cf6ca56 ("x86: OLPC: switch over to using new EC driver on x86"). Use arch_initcall so that olpc-ec is readied earlier, matching the previous behaviour. Fixes a regression introduced in Linux-3.6 where various drivers such as olpc-battery and olpc-xo1-sci failed to load due to an inability to communicate with the EC. The user-visible effect was a lack of battery monitoring, missing ebook/lid switch input devices, etc. Signed-off-by: Daniel Drake Cc: Andres Salomon Cc: Paul Fox Cc: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 020269d2c629a12856a5413528328fbd4ff71ca9 Author: Vyacheslav Dubeyko Date: Thu Aug 22 16:35:45 2013 -0700 nilfs2: fix issue with counting number of bio requests for BIO_EOPNOTSUPP error detection commit 4bf93b50fd04118ac7f33a3c2b8a0a1f9fa80bc9 upstream. Fix the issue with improper counting number of flying bio requests for BIO_EOPNOTSUPP error detection case. The sb_nbio must be incremented exactly the same number of times as complete() function was called (or will be called) because nilfs_segbuf_wait() will call wail_for_completion() for the number of times set to sb_nbio: do { wait_for_completion(&segbuf->sb_bio_event); } while (--segbuf->sb_nbio > 0); Two functions complete() and wait_for_completion() must be called the same number of times for the same sb_bio_event. Otherwise, wait_for_completion() will hang or leak. Signed-off-by: Vyacheslav Dubeyko Cc: Dan Carpenter Acked-by: Ryusuke Konishi Tested-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b0e01ab2f3f31384dd9e1c660e0c9831e717e73c Author: Vyacheslav Dubeyko Date: Thu Aug 22 16:35:44 2013 -0700 nilfs2: remove double bio_put() in nilfs_end_bio_write() for BIO_EOPNOTSUPP error commit 2df37a19c686c2d7c4e9b4ce1505b5141e3e5552 upstream. Remove double call of bio_put() in nilfs_end_bio_write() for the case of BIO_EOPNOTSUPP error detection. The issue was found by Dan Carpenter and he suggests first version of the fix too. Signed-off-by: Vyacheslav Dubeyko Reported-by: Dan Carpenter Acked-by: Ryusuke Konishi Tested-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit abcdf87c25278b38972e41ca13fffc42b9d1f6f8 Author: Wladislav Wiebe Date: Mon Aug 12 13:06:53 2013 +0200 of: fdt: fix memory initialization for expanded DT commit 9e40127526e857fa3f29d51e83277204fbdfc6ba upstream. Already existing property flags are filled wrong for properties created from initial FDT. This could cause problems if this DYNAMIC device-tree functions are used later, i.e. properties are attached/detached/replaced. Simply dumping flags from the running system show, that some initial static (not allocated via kzmalloc()) nodes are marked as dynamic. I putted some debug extensions to property_proc_show(..) : .. + if (OF_IS_DYNAMIC(pp)) + pr_err("DEBUG: xxx : OF_IS_DYNAMIC\n"); + if (OF_IS_DETACHED(pp)) + pr_err("DEBUG: xxx : OF_IS_DETACHED\n"); when you operate on the nodes (e.g.: ~$ cat /proc/device-tree/*some_node*) you will see that those flags are filled wrong, basically in most cases it will dump a DYNAMIC or DETACHED status, which is in not true. (BTW. this OF_IS_DETACHED is a own define for debug purposes which which just make a test_bit(OF_DETACHED, &x->_flags) If nodes are dynamic kernel is allowed to kfree() them. But it will crash attempting to do so on the nodes from FDT -- they are not allocated via kzmalloc(). Signed-off-by: Wladislav Wiebe Acked-by: Alexander Sverdlin Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit ce04434c6e596b264f92f39d3228883c60262b69 Author: Chris Wilson Date: Tue Aug 6 19:01:14 2013 +0100 drm/i915: Invalidate TLBs for the rings after a reset commit 884020bf3d2a3787a1cc6df902e98e0eec60330b upstream. After any "soft gfx reset" we must manually invalidate the TLBs associated with each ring. Empirically, it seems that a suspend/resume or D3-D0 cycle count as a "soft reset". The symptom is that the hardware would fail to note the new address for its status page, and so it would continue to write the shadow registers and breadcrumbs into the old physical address (now used by something completely different, scary). Whereas the driver would read the new status page and never see any progress, it would appear that the GPU hung immediately upon resume. Based on a patch by naresh kumar kachhi Reported-by: Thiago Macieira Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64725 Signed-off-by: Chris Wilson Tested-by: Thiago Macieira Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 749e7bffd3f71d4fadc0fb54eebce12a28d045e7 Author: Rafał Miłecki Date: Thu Aug 15 18:55:22 2013 +0200 drm/radeon: fix WREG32_OR macro setting bits in a register commit d43a93c8d9bc4e0dc0293b6458c077c3c797594f upstream. This bug (introduced in 3.10) in WREG32_OR made commit d3418eacad403033e95e49dc14afa37c2112c134 "drm/radeon/evergreen: setup HDMI before enabling it" cause a regression. Sometimes audio over HDMI wasn't working, sometimes display was corrupted. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60687 https://bugzilla.kernel.org/show_bug.cgi?id=60709 https://bugs.freedesktop.org/show_bug.cgi?id=67767 Signed-off-by: Rafał Miłecki Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 21779249f05d0ebdd2eaf464673d224f1883b57a Author: Christian König Date: Sun Aug 11 21:27:56 2013 +0200 drm/radeon: fix UVD message buffer validation commit 112a6d0c071808f6d48354fc8834a574e5dcefc0 upstream. When the message buffer is currently moving block until it is idle again. Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 6a33cbd049c293b0c274661d63c8918eb8557086 Author: Alex Deucher Date: Tue Aug 13 15:57:32 2013 -0400 drm/radeon/r7xx: fix copy paste typo in golden register setup commit 022374c02e357ac82e98dd2689fb2efe05723d69 upstream. Uses the wrong array size for some asics which can lead to garbage getting written to registers. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60674 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 6f123e952c4144ddda16ebdac765677ebdf6f37c Author: Ian Abbott Date: Fri Aug 23 12:37:17 2013 +0100 staging: comedi: bug-fix NULL pointer dereference on failed attach commit 3955dfa8216f712bc204a5ad2f4e51efff252fde upstream. Commit dcd7b8bd63cb81c5b973bf86510ca3c80bbbd162 ("staging: comedi: put module _after_ detach" by myself) reversed a couple of calls in `comedi_device_attach()` when recovering from an error returned by the low-level driver's 'attach' handler. Unfortunately, that introduced a NULL pointer dereference bug as `dev->driver` is NULL after the call to `comedi_device_detach()`. We still have a pointer to the low-level comedi driver structure in the `driv` variable, so use that instead. Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 90dbc54a171ca7fd96c35d2858d30baf5d7c6376 Author: Nicolas Pitre Date: Wed Aug 14 22:36:32 2013 +0100 ARM: 7816/1: CONFIG_KUSER_HELPERS: fix help text commit ac124504ecf6b20a2457d873d0728a8b991a5b0c upstream. Commit f6f91b0d9fd9 ("ARM: allow kuser helpers to be removed from the vector page") introduced some help text for the CONFIG_KUSER_HELPERS option which is rather contradictory. Let's fix that, and improve it a little. Signed-off-by: Nicolas Pitre Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 6c6f6c7166e9ee45e545eab850a2862a92c135b2 Author: Will Deacon Date: Tue Aug 20 11:47:40 2013 +0100 arm64: perf: fix event validation for software group leaders commit ee7538a008a45050c8f706d38b600f55953169f9 upstream. This is a port of c95eb3184ea1 ("ARM: 7809/1: perf: fix event validation for software group leaders") to arm64, which fixes a panic in the arm64 perf backend found as a result of Vince's fuzzing tool. Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 975a3cd4cc0dff06a635cb16b8fb25fd3ae88234 Author: Will Deacon Date: Tue Aug 20 11:47:39 2013 +0100 arm64: perf: fix array out of bounds access in armpmu_map_hw_event() commit 868f6fea8fa63f09acbfa93256d0d2abdcabff79 upstream. This is a port of d9f966357b14 ("ARM: 7810/1: perf: Fix array out of bounds access in armpmu_map_hw_event()") to arm64, which fixes an oops in the arm64 perf backend found as a result of Vince's fuzzing tool. Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 805eea0bb13dfded98c2383139b64d0576838b65 Author: Nicolas Ferre Date: Fri Jun 28 10:39:15 2013 +0200 ARM: at91/DT: fix at91sam9n12ek memory node commit a57603ca2871ee0773b00839c1ea35c4a2d3eeb0 upstream. Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit 66ed6f3d16a224dfffda420d7b047a7346c63821 Author: Sekhar Nori Date: Fri Aug 16 14:43:48 2013 +0530 ARM: davinci: nand: specify ecc strength commit acd36357edc08649e85ff15dc4ed62353c912eff upstream. Starting with kernel v3.5, it is mandatory to specify ECC strength when using hardware ECC. Without this, kernel panics with a warning of the sort: Driver must set ecc.strength when using hardware ECC ------------[ cut here ]------------ kernel BUG at drivers/mtd/nand/nand_base.c:3519! Fix this by specifying ECC strength for the boards which were missing this. Reported-by: Holger Freyther Signed-off-by: Sekhar Nori Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit 131cb95fdf390f414163605c997b48cad591a273 Author: David Vrabel Date: Thu Aug 15 13:21:07 2013 +0100 xen/events: mask events when changing their VCPU binding commit 4704fe4f03a5ab27e3c36184af85d5000e0f8a48 upstream. When a event is being bound to a VCPU there is a window between the EVTCHNOP_bind_vpcu call and the adjustment of the local per-cpu masks where an event may be lost. The hypervisor upcalls the new VCPU but the kernel thinks that event is still bound to the old VCPU and ignores it. There is even a problem when the event is being bound to the same VCPU as there is a small window beween the clear_bit() and set_bit() calls in bind_evtchn_to_cpu(). When scanning for pending events, the kernel may read the bit when it is momentarily clear and ignore the event. Avoid this by masking the event during the whole bind operation. Signed-off-by: David Vrabel Signed-off-by: Konrad Rzeszutek Wilk Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman commit d8251a942ff0318fd8fde8e69fac5480b60e26b3 Author: David Vrabel Date: Thu Aug 15 13:21:06 2013 +0100 xen/events: initialize local per-cpu mask for all possible events commit 84ca7a8e45dafb49cd5ca90a343ba033e2885c17 upstream. The sizeof() argument in init_evtchn_cpu_bindings() is incorrect resulting in only the first 64 (or 32 in 32-bit guests) ports having their bindings being initialized to VCPU 0. In most cases this does not cause a problem as request_irq() will set the irq affinity which will set the correct local per-cpu mask. However, if the request_irq() is called on a VCPU other than 0, there is a window between the unmasking of the event and the affinity being set were an event may be lost because it is not locally unmasked on any VCPU. If request_irq() is called on VCPU 0 then local irqs are disabled during the window and the race does not occur. Fix this by initializing all NR_EVENT_CHANNEL bits in the local per-cpu masks. Signed-off-by: David Vrabel Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 8a34139a0c0ab7ed616b3e50f061cac8bc1e0531 Author: Daniel Drake Date: Fri Aug 9 18:14:20 2013 -0400 x86: Don't clear olpc_ofw_header when sentinel is detected commit d55e37bb0f51316e552376ddc0a3fff34ca7108b upstream. OpenFirmware wasn't quite following the protocol described in boot.txt and the kernel has detected this through use of the sentinel value in boot_params. OFW does zero out almost all of the stuff that it should do, but not the sentinel. This causes the kernel to clear olpc_ofw_header, which breaks x86 OLPC support. OpenFirmware has now been fixed. However, it would be nice if we could maintain Linux compatibility with old firmware versions. To do that, we just have to avoid zeroing out olpc_ofw_header. OFW does not write to any other parts of the header that are being zapped by the sentinel-detection code, and all users of olpc_ofw_header are somewhat protected through checking for the OLPC_OFW_SIG magic value before using it. So this should not cause any problems for anyone. Signed-off-by: Daniel Drake Link: http://lkml.kernel.org/r/20130809221420.618E6FAB03@dev.laptop.org Acked-by: Yinghai Lu Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 2bee1e0f280b159ce8f9f01c2f5c9de410231a3b Author: Dan Carpenter Date: Wed Aug 14 12:44:39 2013 +0300 VFS: collect_mounts() should return an ERR_PTR commit 52e220d357a38cb29fa2e29f34ed94c1d66357f4 upstream. This should actually be returning an ERR_PTR on error instead of NULL. That was how it was designed and all the callers expect it. [AV: actually, that's what "VFS: Make clone_mnt()/copy_tree()/collect_mounts() return errors" missed - originally collect_mounts() was expected to return NULL on failure] Signed-off-by: Dan Carpenter Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit b169395145ce013ad1ed3ee25878112f647ffd56 Author: Jussi Kivilinna Date: Tue Aug 6 14:28:42 2013 +0300 zd1201: do not use stack as URB transfer_buffer commit 1206ff4ff9d2ef7468a355328bc58ac6ebf5be44 upstream. Patch fixes zd1201 not to use stack as URB transfer_buffer. URB buffers need to be DMA-able, which stack is not. Patch is only compile tested. Signed-off-by: Jussi Kivilinna Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 0cbf39727e08f58246e763f8af2f8dcb8a9f648f Author: Joern Rennecke Date: Sat Aug 24 12:03:06 2013 +0530 ARC: [lib] strchr breakage in Big-endian configuration commit b0f55f2a1a295c364be012e82dbab079a2454006 upstream. For a search buffer, 2 byte aligned, strchr() was returning pointer outside of buffer (buf - 1) ------------->8---------------- // Input buffer (default 4 byte aigned) char *buffer = "1AA_"; // actual search start (to mimick 2 byte alignment) char *current_line = &(buffer[2]); // Character to search for char c = 'A'; char *c_pos = strchr(current_line, c); printf("%s\n", c_pos) --> 'AA_' as oppose to 'A_' ------------->8---------------- Reported-by: Anton Kolesov Debugged-by: Anton Kolesov Cc: Noam Camus Signed-off-by: Joern Rennecke Signed-off-by: Vineet Gupta Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 51f508721b778bd48d723bed1c4ca4af0855764c Author: Chuck Anderson Date: Tue Aug 6 15:12:19 2013 -0700 xen/smp: initialize IPI vectors before marking CPU online commit fc78d343fa74514f6fd117b5ef4cd27e4ac30236 upstream. An older PVHVM guest (v3.0 based) crashed during vCPU hot-plug with: kernel BUG at drivers/xen/events.c:1328! RCU has detected that a CPU has not entered a quiescent state within the grace period. It needs to send the CPU a reschedule IPI if it is not offline. rcu_implicit_offline_qs() does this check: /* * If the CPU is offline, it is in a quiescent state. We can * trust its state not to change because interrupts are disabled. */ if (cpu_is_offline(rdp->cpu)) { rdp->offline_fqs++; return 1; } Else the CPU is online. Send it a reschedule IPI. The CPU is in the middle of being hot-plugged and has been marked online (!cpu_is_offline()). See start_secondary(): set_cpu_online(smp_processor_id(), true); ... per_cpu(cpu_state, smp_processor_id()) = CPU_ONLINE; start_secondary() then waits for the CPU bringing up the hot-plugged CPU to mark it as active: /* * Wait until the cpu which brought this one up marked it * online before enabling interrupts. If we don't do that then * we can end up waking up the softirq thread before this cpu * reached the active state, which makes the scheduler unhappy * and schedule the softirq thread on the wrong cpu. This is * only observable with forced threaded interrupts, but in * theory it could also happen w/o them. It's just way harder * to achieve. */ while (!cpumask_test_cpu(smp_processor_id(), cpu_active_mask)) cpu_relax(); /* enable local interrupts */ local_irq_enable(); The CPU being hot-plugged will be marked active after it has been fully initialized by the CPU managing the hot-plug. In the Xen PVHVM case xen_smp_intr_init() is called to set up the hot-plugged vCPU's XEN_RESCHEDULE_VECTOR. The hot-plugging CPU is marked online, not marked active and does not have its IPI vectors set up. rcu_implicit_offline_qs() sees the hot-plugging cpu is !cpu_is_offline() and tries to send it a reschedule IPI: This will lead to: kernel BUG at drivers/xen/events.c:1328! xen_send_IPI_one() xen_smp_send_reschedule() rcu_implicit_offline_qs() rcu_implicit_dynticks_qs() force_qs_rnp() force_quiescent_state() __rcu_process_callbacks() rcu_process_callbacks() __do_softirq() call_softirq() do_softirq() irq_exit() xen_evtchn_do_upcall() because xen_send_IPI_one() will attempt to use an uninitialized IRQ for the XEN_RESCHEDULE_VECTOR. There is at least one other place that has caused the same crash: xen_smp_send_reschedule() wake_up_idle_cpu() add_timer_on() clocksource_watchdog() call_timer_fn() run_timer_softirq() __do_softirq() call_softirq() do_softirq() irq_exit() xen_evtchn_do_upcall() xen_hvm_callback_vector() clocksource_watchdog() uses cpu_online_mask to pick the next CPU to handle a watchdog timer: /* * Cycle through CPUs to check if the CPUs stay synchronized * to each other. */ next_cpu = cpumask_next(raw_smp_processor_id(), cpu_online_mask); if (next_cpu >= nr_cpu_ids) next_cpu = cpumask_first(cpu_online_mask); watchdog_timer.expires += WATCHDOG_INTERVAL; add_timer_on(&watchdog_timer, next_cpu); This resulted in an attempt to send an IPI to a hot-plugging CPU that had not initialized its reschedule vector. One option would be to make the RCU code check to not check for CPU offline but for CPU active. As becoming active is done after a CPU is online (in older kernels). But Srivatsa pointed out that "the cpu_active vs cpu_online ordering has been completely reworked - in the online path, cpu_active is set *before* cpu_online, and also, in the cpu offline path, the cpu_active bit is reset in the CPU_DYING notification instead of CPU_DOWN_PREPARE." Drilling in this the bring-up path: "[brought up CPU].. send out a CPU_STARTING notification, and in response to that, the scheduler sets the CPU in the cpu_active_mask. Again, this mask is better left to the scheduler alone, since it has the intelligence to use it judiciously." The conclusion was that: " 1. At the IPI sender side: It is incorrect to send an IPI to an offline CPU (cpu not present in the cpu_online_mask). There are numerous places where we check this and warn/complain. 2. At the IPI receiver side: It is incorrect to let the world know of our presence (by setting ourselves in global bitmasks) until our initialization steps are complete to such an extent that we can handle the consequences (such as receiving interrupts without crashing the sender etc.) " (from Srivatsa) As the native code enables the interrupts at some point we need to be able to service them. In other words a CPU must have valid IPI vectors if it has been marked online. It doesn't need to handle the IPI (interrupts may be disabled) but needs to have valid IPI vectors because another CPU may find it in cpu_online_mask and attempt to send it an IPI. This patch will change the order of the Xen vCPU bring-up functions so that Xen vectors have been set up before start_secondary() is called. It also will not continue to bring up a Xen vCPU if xen_smp_intr_init() fails to initialize it. Orabug 13823853 Signed-off-by Chuck Anderson Acked-by: Srivatsa S. Bhat Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit f05e999f16aed044c0b8b0837bdb084cbeb8cee6 Author: Steven Rostedt (Red Hat) Date: Tue Jul 30 00:04:32 2013 -0400 ftrace: Check module functions being traced on reload commit 8c4f3c3fa9681dc549cd35419b259496082fef8b upstream. There's been a nasty bug that would show up and not give much info. The bug displayed the following warning: WARNING: at kernel/trace/ftrace.c:1529 __ftrace_hash_rec_update+0x1e3/0x230() Pid: 20903, comm: bash Tainted: G O 3.6.11+ #38405.trunk Call Trace: [] warn_slowpath_common+0x7f/0xc0 [] warn_slowpath_null+0x1a/0x20 [] __ftrace_hash_rec_update+0x1e3/0x230 [] ftrace_hash_move+0x28/0x1d0 [] ? kfree+0x2c/0x110 [] ftrace_regex_release+0x8e/0x150 [] __fput+0xae/0x220 [] ____fput+0xe/0x10 [] task_work_run+0x72/0x90 [] do_notify_resume+0x6c/0xc0 [] ? trace_hardirqs_on_thunk+0x3a/0x3c [] int_signal+0x12/0x17 ---[ end trace 793179526ee09b2c ]--- It was finally narrowed down to unloading a module that was being traced. It was actually more than that. When functions are being traced, there's a table of all functions that have a ref count of the number of active tracers attached to that function. When a function trace callback is registered to a function, the function's record ref count is incremented. When it is unregistered, the function's record ref count is decremented. If an inconsistency is detected (ref count goes below zero) the above warning is shown and the function tracing is permanently disabled until reboot. The ftrace callback ops holds a hash of functions that it filters on (and/or filters off). If the hash is empty, the default means to filter all functions (for the filter_hash) or to disable no functions (for the notrace_hash). When a module is unloaded, it frees the function records that represent the module functions. These records exist on their own pages, that is function records for one module will not exist on the same page as function records for other modules or even the core kernel. Now when a module unloads, the records that represents its functions are freed. When the module is loaded again, the records are recreated with a default ref count of zero (unless there's a callback that traces all functions, then they will also be traced, and the ref count will be incremented). The problem is that if an ftrace callback hash includes functions of the module being unloaded, those hash entries will not be removed. If the module is reloaded in the same location, the hash entries still point to the functions of the module but the module's ref counts do not reflect that. With the help of Steve and Joern, we found a reproducer: Using uinput module and uinput_release function. cd /sys/kernel/debug/tracing modprobe uinput echo uinput_release > set_ftrace_filter echo function > current_tracer rmmod uinput modprobe uinput # check /proc/modules to see if loaded in same addr, otherwise try again echo nop > current_tracer [BOOM] The above loads the uinput module, which creates a table of functions that can be traced within the module. We add uinput_release to the filter_hash to trace just that function. Enable function tracincg, which increments the ref count of the record associated to uinput_release. Remove uinput, which frees the records including the one that represents uinput_release. Load the uinput module again (and make sure it's at the same address). This recreates the function records all with a ref count of zero, including uinput_release. Disable function tracing, which will decrement the ref count for uinput_release which is now zero because of the module removal and reload, and we have a mismatch (below zero ref count). The solution is to check all currently tracing ftrace callbacks to see if any are tracing any of the module's functions when a module is loaded (it already does that with callbacks that trace all functions). If a callback happens to have a module function being traced, it increments that records ref count and starts tracing that function. There may be a strange side effect with this, where tracing module functions on unload and then reloading a new module may have that new module's functions being traced. This may be something that confuses the user, but it's not a big deal. Another approach is to disable all callback hashes on module unload, but this leaves some ftrace callbacks that may not be registered, but can still have hashes tracing the module's function where ftrace doesn't know about it. That situation can cause the same bug. This solution solves that case too. Another benefit of this solution, is it is possible to trace a module's function on unload and load. Link: http://lkml.kernel.org/r/20130705142629.GA325@redhat.com Reported-by: Jörn Engel Reported-by: Dave Jones Reported-by: Steve Hodgson Tested-by: Steve Hodgson Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 396dd500521287215d836b84b2ae61cd9163bba5 Author: Steven Rostedt (Red Hat) Date: Wed Jul 3 23:33:51 2013 -0400 tracing/uprobes: Fail to unregister if probe event files are in use commit c6c2401d8bbaf9edc189b4c35a8cb2780b8b988e upstream. Uprobes suffer the same problem that kprobes have. There's a race between writing to the "enable" file and removing the probe. The probe checks for it being in use and if it is not, goes about deleting the probe and the event that represents it. But the problem with that is, after it checks if it is in use it can be enabled, and the deletion of the event (access to the probe) will fail, as it is in use. But the uprobe will still be deleted. This is a problem as the event can reference the uprobe that was deleted. The fix is to remove the event first, and check to make sure the event removal succeeds. Then it is safe to remove the probe. When the event exists, either ftrace or perf can enable the probe and prevent the event from being removed. Link: http://lkml.kernel.org/r/20130704034038.991525256@goodmis.org Acked-by: Oleg Nesterov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 428fbcf9d5d654526a73229d97e76d5d7ac47190 Author: Steven Rostedt (Red Hat) Date: Wed Jul 3 23:33:50 2013 -0400 tracing/kprobes: Fail to unregister if probe event files are in use commit 40c32592668b727cbfcf7b1c0567f581bd62a5e4 upstream. When a probe is being removed, it cleans up the event files that correspond to the probe. But there is a race between writing to one of these files and deleting the probe. This is especially true for the "enable" file. CPU 0 CPU 1 ----- ----- fd = open("enable",O_WRONLY); probes_open() release_all_trace_probes() unregister_trace_probe() if (trace_probe_is_enabled(tp)) return -EBUSY write(fd, "1", 1) __ftrace_set_clr_event() call->class->reg() (kprobe_register) enable_trace_probe(tp) __unregister_trace_probe(tp); list_del(&tp->list) unregister_probe_event(tp) <-- fails! free_trace_probe(tp) write(fd, "0", 1) __ftrace_set_clr_event() call->class->unreg (kprobe_register) disable_trace_probe(tp) <-- BOOM! A test program was written that used two threads to simulate the above scenario adding a nanosleep() interval to change the timings and after several thousand runs, it was able to trigger this bug and crash: BUG: unable to handle kernel paging request at 00000005000000f9 IP: [] probes_open+0x3b/0xa7 PGD 7808a067 PUD 0 Oops: 0000 [#1] PREEMPT SMP Dumping ftrace buffer: --------------------------------- Modules linked in: ipt_MASQUERADE sunrpc ip6t_REJECT nf_conntrack_ipv6 CPU: 1 PID: 2070 Comm: test-kprobe-rem Not tainted 3.11.0-rc3-test+ #47 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007 task: ffff880077756440 ti: ffff880076e52000 task.ti: ffff880076e52000 RIP: 0010:[] [] probes_open+0x3b/0xa7 RSP: 0018:ffff880076e53c38 EFLAGS: 00010203 RAX: 0000000500000001 RBX: ffff88007844f440 RCX: 0000000000000003 RDX: 0000000000000003 RSI: 0000000000000003 RDI: ffff880076e52000 RBP: ffff880076e53c58 R08: ffff880076e53bd8 R09: 0000000000000000 R10: ffff880077756440 R11: 0000000000000006 R12: ffffffff810dee35 R13: ffff880079250418 R14: 0000000000000000 R15: ffff88007844f450 FS: 00007f87a276f700(0000) GS:ffff88007d480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00000005000000f9 CR3: 0000000077262000 CR4: 00000000000007e0 Stack: ffff880076e53c58 ffffffff81219ea0 ffff88007844f440 ffffffff810dee35 ffff880076e53ca8 ffffffff81130f78 ffff8800772986c0 ffff8800796f93a0 ffffffff81d1b5d8 ffff880076e53e04 0000000000000000 ffff88007844f440 Call Trace: [] ? security_file_open+0x2c/0x30 [] ? unregister_trace_probe+0x4b/0x4b [] do_dentry_open+0x162/0x226 [] finish_open+0x46/0x54 [] do_last+0x7f6/0x996 [] ? inode_permission+0x42/0x44 [] path_openat+0x232/0x496 [] do_filp_open+0x3a/0x8a [] ? __alloc_fd+0x168/0x17a [] do_sys_open+0x70/0x102 [] ? trace_hardirqs_on_caller+0x160/0x197 [] SyS_open+0x1e/0x20 [] system_call_fastpath+0x16/0x1b Code: e5 41 54 53 48 89 f3 48 83 ec 10 48 23 56 78 48 39 c2 75 6c 31 f6 48 c7 RIP [] probes_open+0x3b/0xa7 RSP CR2: 00000005000000f9 ---[ end trace 35f17d68fc569897 ]--- The unregister_trace_probe() must be done first, and if it fails it must fail the removal of the kprobe. Several changes have already been made by Oleg Nesterov and Masami Hiramatsu to allow moving the unregister_probe_event() before the removal of the probe and exit the function if it fails. This prevents the tp structure from being used after it is freed. Link: http://lkml.kernel.org/r/20130704034038.819592356@goodmis.org Acked-by: Masami Hiramatsu Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 8169887b694aa3d9632fdd0308aaa1db7c422e75 Author: Oleg Nesterov Date: Mon Jul 29 19:50:33 2013 +0200 tracing: trace_remove_event_call() should fail if call/file is in use commit 2816c551c796ec14620325b2c9ed75b9979d3125 upstream. Change trace_remove_event_call(call) to return the error if this call is active. This is what the callers assume but can't verify outside of the tracing locks. Both trace_kprobe.c/trace_uprobe.c need the additional changes, unregister_trace_probe() should abort if trace_remove_event_call() fails. The caller is going to free this call/file so we must ensure that nobody can use them after trace_remove_event_call() succeeds. debugfs should be fine after the previous changes and event_remove() does TRACE_REG_UNREGISTER, but still there are 2 reasons why we need the additional checks: - There could be a perf_event(s) attached to this tp_event, so the patch checks ->perf_refcount. - TRACE_REG_UNREGISTER can be suppressed by FTRACE_EVENT_FL_SOFT_MODE, so we simply check FTRACE_EVENT_FL_ENABLED protected by event_mutex. Link: http://lkml.kernel.org/r/20130729175033.GB26284@redhat.com Reviewed-by: Masami Hiramatsu Signed-off-by: Oleg Nesterov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 012dc156d6af49e02a30fcba7d688e251608d97c Author: Oleg Nesterov Date: Sun Jul 28 20:35:27 2013 +0200 tracing: Change remove_event_file_dir() to clear "d_subdirs"->i_private commit bf682c3159c4d298d1126a56793ed3f5e80395f7 upstream. Change remove_event_file_dir() to clear ->i_private for every file we are going to remove. We need to check file->dir != NULL because event_create_dir() can fail. debugfs_remove_recursive(NULL) is fine but the patch moves it under the same check anyway for readability. spin_lock(d_lock) and "d_inode != NULL" check are not needed afaics, but I do not understand this code enough. tracing_open_generic_file() and tracing_release_generic_file() can go away, ftrace_enable_fops and ftrace_event_filter_fops() use tracing_open_generic() but only to check tracing_disabled. This fixes all races with event_remove() or instance_delete(). f_op->read/write/whatever can never use the freed file/call, all event/* files were changed to check and use ->i_private under event_mutex. Note: this doesn't not fix other problems, event_remove() can destroy the active ftrace_event_call, we need more changes but those changes are completely orthogonal. Link: http://lkml.kernel.org/r/20130728183527.GB16723@redhat.com Reviewed-by: Masami Hiramatsu Signed-off-by: Oleg Nesterov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit c6febdf258313a120acd1298dd1dd41442131a37 Author: Oleg Nesterov Date: Fri Jul 26 19:25:47 2013 +0200 tracing: Introduce remove_event_file_dir() commit f6a84bdc75b5c11621dec58db73fe102cbaf40cc upstream. Preparation for the next patch. Extract the common code from remove_event_from_tracers() and __trace_remove_event_dirs() into the new helper, remove_event_file_dir(). The patch looks more complicated than it actually is, it also moves remove_subsystem() up to avoid the forward declaration. Link: http://lkml.kernel.org/r/20130726172547.GA3629@redhat.com Reviewed-by: Masami Hiramatsu Signed-off-by: Oleg Nesterov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit b86d0ba62decb830aed2fa525e7557857d3199f2 Author: Oleg Nesterov Date: Fri Jul 26 19:25:43 2013 +0200 tracing: Change f_start() to take event_mutex and verify i_private != NULL commit c5a44a1200c6eda2202434f25325e8ad19533fca upstream. trace_format_open() and trace_format_seq_ops are racy, nothing protects ftrace_event_call from trace_remove_event_call(). Change f_start() to take event_mutex and verify i_private != NULL, change f_stop() to drop this lock. This fixes nothing, but now we can change debugfs_remove("format") callers to nullify ->i_private and fix the the problem. Note: the usage of event_mutex is sub-optimal but simple, we can change this later. Link: http://lkml.kernel.org/r/20130726172543.GA3622@redhat.com Reviewed-by: Masami Hiramatsu Signed-off-by: Oleg Nesterov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 70c91fb9a74e7937ef76a542a86c1551d5df4281 Author: Oleg Nesterov Date: Fri Jul 26 19:25:40 2013 +0200 tracing: Change event_filter_read/write to verify i_private != NULL commit e2912b091c26b8ea95e5e00a43a7ac620f6c94a6 upstream. event_filter_read/write() are racy, ftrace_event_call can be already freed by trace_remove_event_call() callers. 1. Shift mutex_lock(event_mutex) from print/apply_event_filter to the callers. 2. Change the callers, event_filter_read() and event_filter_write() to read i_private under this mutex and abort if it is NULL. This fixes nothing, but now we can change debugfs_remove("filter") callers to nullify ->i_private and fix the the problem. Link: http://lkml.kernel.org/r/20130726172540.GA3619@redhat.com Reviewed-by: Masami Hiramatsu Signed-off-by: Oleg Nesterov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit df89bf77ca930f69ba07fd459f735ec3cac69f8f Author: Oleg Nesterov Date: Fri Jul 26 19:25:36 2013 +0200 tracing: Change event_enable/disable_read() to verify i_private != NULL commit bc6f6b08dee5645770efb4b76186ded313f23752 upstream. tracing_open_generic_file() is racy, ftrace_event_file can be already freed by rmdir or trace_remove_event_call(). Change event_enable_read() and event_disable_read() to read and verify "file = i_private" under event_mutex. This fixes nothing, but now we can change debugfs_remove("enable") callers to nullify ->i_private and fix the the problem. Link: http://lkml.kernel.org/r/20130726172536.GA3612@redhat.com Reviewed-by: Masami Hiramatsu Signed-off-by: Oleg Nesterov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit fdb65fe265a389144db73cca023266dd6d5ff8d9 Author: Oleg Nesterov Date: Fri Jul 26 19:25:32 2013 +0200 tracing: Turn event/id->i_private into call->event.type commit 1a11126bcb7c93c289bf3218fa546fd3b0c0df8b upstream. event_id_read() is racy, ftrace_event_call can be already freed by trace_remove_event_call() callers. Change event_create_dir() to pass "data = call->event.type", this is all event_id_read() needs. ftrace_event_id_fops no longer needs tracing_open_generic(). We add the new helper, event_file_data(), to read ->i_private, it will have more users. Note: currently ACCESS_ONCE() and "id != 0" check are not needed, but we are going to change event_remove/rmdir to clear ->i_private. Link: http://lkml.kernel.org/r/20130726172532.GA3605@redhat.com Reviewed-by: Masami Hiramatsu Signed-off-by: Oleg Nesterov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 29632b10ef02a31dec2918177f6d4244e66d635d Author: Steven Rostedt (Red Hat) Date: Tue Jul 23 22:06:15 2013 -0400 ftrace: Add check for NULL regs if ops has SAVE_REGS set commit 195a8afc7ac962f8da795549fe38e825f1372b0d upstream. If a ftrace ops is registered with the SAVE_REGS flag set, and there's already a ops registered to one of its functions but without the SAVE_REGS flag, there's a small race window where the SAVE_REGS ops gets added to the list of callbacks to call for that function before the callback trampoline gets set to save the regs. The problem is, the function is not currently saving regs, which opens a small race window where the ops that is expecting regs to be passed to it, wont. This can cause a crash if the callback were to reference the regs, as the SAVE_REGS guarantees that regs will be set. To fix this, we add a check in the loop case where it checks if the ops has the SAVE_REGS flag set, and if so, it will ignore it if regs is not set. Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 7272711a2fc64dd6ef980630e129d8731897ee56 Author: Oleg Nesterov Date: Tue Jul 23 17:26:10 2013 +0200 tracing: Change tracing_fops/snapshot_fops to rely on tracing_get_cpu() commit 6484c71cbc170634fa131b6d022d86d61686b88b upstream. tracing_open() and tracing_snapshot_open() are racy, the memory inode->i_private points to can be already freed. Convert these last users of "inode->i_private == trace_cpu" to use "i_private = trace_array" and rely on tracing_get_cpu(). v2: incorporate the fix from Steven, tracing_release() must not blindly dereference file->private_data unless we know that the file was opened for reading. Link: http://lkml.kernel.org/r/20130723152610.GA23737@redhat.com Signed-off-by: Oleg Nesterov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit e5dd03c411713c066b94e1d448359e5216115c1c Author: Oleg Nesterov Date: Tue Jul 23 17:26:06 2013 +0200 tracing: Change tracing_entries_fops to rely on tracing_get_cpu() commit 0bc392ee46d0fd8e6b678457ef71f074f19a03c5 upstream. tracing_open_generic_tc() is racy, the memory inode->i_private points to can be already freed. 1. Change its last user, tracing_entries_fops, to use tracing_*_generic_tr() instead. 2. Change debugfs_create_file("buffer_size_kb", data) callers to pass "data = tr". 3. Change tracing_entries_read() and tracing_entries_write() to use tracing_get_cpu(). 4. Kill the no longer used tracing_open_generic_tc() and tracing_release_generic_tc(). Link: http://lkml.kernel.org/r/20130723152606.GA23730@redhat.com Signed-off-by: Oleg Nesterov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 6dafb0f13798c998ec344bf910b2d89c51961481 Author: Oleg Nesterov Date: Tue Jul 23 17:26:03 2013 +0200 tracing: Change tracing_stats_fops to rely on tracing_get_cpu() commit 4d3435b8a4c3357695e09c5e7a3bf73a19fca5b0 upstream. tracing_open_generic_tc() is racy, the memory inode->i_private points to can be already freed. 1. Change one of its users, tracing_stats_fops, to use tracing_*_generic_tr() instead. 2. Change trace_create_cpu_file("stats", data) to pass "data = tr". 3. Change tracing_stats_read() to use tracing_get_cpu(). Link: http://lkml.kernel.org/r/20130723152603.GA23727@redhat.com Signed-off-by: Oleg Nesterov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 92b6279e284257fb7908bf4d24956f5af13aaa2d Author: Oleg Nesterov Date: Tue Jul 23 17:26:00 2013 +0200 tracing: Change tracing_buffers_fops to rely on tracing_get_cpu() commit 46ef2be0d1d5ccea0c41bb606143586daadd537c upstream. tracing_buffers_open() is racy, the memory inode->i_private points to can be already freed. Change debugfs_create_file("trace_pipe_raw", data) caller to pass "data = tr", tracing_buffers_open() can use tracing_get_cpu(). Change debugfs_create_file("snapshot_raw_fops", data) caller too, this file uses tracing_buffers_open/release. Link: http://lkml.kernel.org/r/20130723152600.GA23720@redhat.com Signed-off-by: Oleg Nesterov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 23b625fa111e7358ce84672c4444c068b2b1e204 Author: Oleg Nesterov Date: Tue Jul 23 17:25:57 2013 +0200 tracing: Change tracing_pipe_fops() to rely on tracing_get_cpu() commit 15544209cb0b5312e5220a9337a1fe61d1a1f2d9 upstream. tracing_open_pipe() is racy, the memory inode->i_private points to can be already freed. Change debugfs_create_file("trace_pipe", data) callers to to pass "data = tr", tracing_open_pipe() can use tracing_get_cpu(). Link: http://lkml.kernel.org/r/20130723152557.GA23717@redhat.com Signed-off-by: Oleg Nesterov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit e2d4dbe02175e54616fe52c4e9c367199f8ecdaa Author: Oleg Nesterov Date: Tue Jul 23 17:25:54 2013 +0200 tracing: Introduce trace_create_cpu_file() and tracing_get_cpu() commit 649e9c70da6bfbeb563193a35d3424a5aa7c0d38 upstream. Every "file_operations" used by tracing_init_debugfs_percpu is buggy. f_op->open/etc does: 1. struct trace_cpu *tc = inode->i_private; struct trace_array *tr = tc->tr; 2. trace_array_get(tr) or fail; 3. do_something(tc); But tc (and tr) can be already freed before trace_array_get() is called. And it doesn't matter whether this file is per-cpu or it was created by init_tracer_debugfs(), free_percpu() or kfree() are equally bad. Note that even 1. is not safe, the freed memory can be unmapped. But even if it was safe trace_array_get() can wrongly succeed if we also race with the next new_instance_create() which can re-allocate the same tr, or tc was overwritten and ->tr points to the valid tr. In this case 3. uses the freed/reused memory. Add the new trivial helper, trace_create_cpu_file() which simply calls trace_create_file() and encodes "cpu" in "struct inode". Another helper, tracing_get_cpu() will be used to read cpu_nr-or-RING_BUFFER_ALL_CPUS. The patch abuses ->i_cdev to encode the number, it is never used unless the file is S_ISCHR(). But we could use something else, say, i_bytes or even ->d_fsdata. In any case this hack is hidden inside these 2 helpers, it would be trivial to change them if needed. This patch only changes tracing_init_debugfs_percpu() to use the new trace_create_cpu_file(), the next patches will change file_operations. Note: tracing_get_cpu(inode) is always safe but you can't trust the result unless trace_array_get() was called, without trace_types_lock which acts as a barrier it can wrongly return RING_BUFFER_ALL_CPUS. Link: http://lkml.kernel.org/r/20130723152554.GA23710@redhat.com Cc: Al Viro Signed-off-by: Oleg Nesterov Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit e899e7e4f83ecd606e85d355410d724ec76542cb Author: Masami Hiramatsu Date: Tue Jul 9 18:35:26 2013 +0900 tracing/kprobe: Wait for disabling all running kprobe handlers commit a232e270dcb55a70ad3241bc6fc160fd9b5c9e6c upstream. Wait for disabling all running kprobe handlers when a kprobe event is disabled, since the caller, trace_remove_event_call() supposes that a removing event is disabled completely by disabling the event. With this change, ftrace can ensure that there is no running event handlers after disabling it. Link: http://lkml.kernel.org/r/20130709093526.20138.93100.stgit@mhiramat-M0-7522 Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit b0cfaffa7e183719436a7a2b1b814afb5748c05c Author: Namhyung Kim Date: Fri Jun 7 15:07:48 2013 +0900 tracing: Do not call kmem_cache_free() on allocation failure commit aaf6ac0f0871cb7fc0f28f3a00edf329bc7adc29 upstream. There's no point calling it when _alloc() failed. Link: http://lkml.kernel.org/r/1370585268-29169-1-git-send-email-namhyung@kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit b460440f81f11175bdc657ee28a2421f8a02d209 Author: Johannes Berg Date: Wed May 15 11:44:49 2013 +0200 iwlwifi: mvm: adjust firmware D3 configuration API commit dfcb4c3aacedee6838e436fb575b31e138505203 upstream. The D3 firmware API changed to include a new field, adjust the driver to it to avoid getting an NMI when configuring. Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit a76139c02f366c601a6895c1a1c1c6d26ec7d469 Author: Johannes Berg Date: Thu Jun 13 16:06:08 2013 +0200 iwlwifi: bump required firmware API version for 3160/7260 commit a2d0909a687b4d250cc2b7481072e361678745ba upstream. As the firmware API has changed significantly and we don't have support code for the old APIs, bump the version to be able to release the version 7 API firmware. Unfortunately this means that the driver in 3.9 and 3.10 can't work, but that's still better than crashing the device/driver there. Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 8351cafff00be058ce4db3753010632e29d104f3 Author: Emmanuel Grumbach Date: Mon Jun 24 15:44:03 2013 +0300 iwlwifi: mvm: unregister leds when registration failed commit b7327d89ae694a89f9934d428bde520b77b3131c upstream. This was missing and prevented any further attempts to load the module. Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 07e915c91b08d06db1e38241bc517e9b2e4fa3bd Author: Emmanuel Grumbach Date: Thu Jun 13 10:07:47 2013 +0300 iwlwifi: mvm: take the seqno from packet if transmit failed commit ebea2f32e814445f94f9e087b646f1cf4d55fa5a upstream. The fw is unreliable in all the cases in which the packet wasn't sent. Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 0710345e2d2eca0c98b75dfe7c1a8a50c04d4829 Author: Emmanuel Grumbach Date: Sun Jun 9 13:00:12 2013 +0300 iwlwifi: mvm: don't set the MCAST queue in STA's queue list commit 837fb69f10588caafc883c4473a864660e1403ce upstream. The MCAST queue should be enabled after DTIM only. According to fw API, the MCAST must not be attached to any station, but should appear in the mcast_qid of the AP's mac context only. Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 06a80c46e85d004a18a51529937049c533e492cd Author: Emmanuel Grumbach Date: Sun Jun 9 12:59:24 2013 +0300 iwlwifi: mvm: properly tell the fw that a STA is awake commit 5af01772ee1d6e96849adf728ff837bd71b119c0 upstream. The firmware API wasn't being used correctly, fix that. Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 21e0f1b26a6ef640c02f09c4390057ee726de389 Author: Emmanuel Grumbach Date: Sun Jun 2 19:54:01 2013 +0300 iwlwifi: mvm: fix MCAST in AP mode commit 9116a3683902583a302ac5dcb283416d504d9bb4 upstream. In multicast, there is no retries nor RTS since there is no specific recipient that can ACK or send CTS. This means that we must not use the rate scale table for multicast frames. This true for any frame that doesn't have a valid ieee80211_sta pointer. Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 446b977ec00db5f4bfb4187bca300dd38bfe7e7d Author: Emmanuel Grumbach Date: Sun May 26 20:47:53 2013 +0300 iwlwifi: mvm: correctly configure MCAST in AP mode commit 86a91ec757338edbce51de5dabd7afb0366f485c upstream. The AP mode needs to use the MCAST fifo for the MCAST frames sent after the DTIM. This fifo needs to be configured with the same parameters as the VOICE FIFO. A separate SCD queue is mapped to this fifo - the cab_queue (cab stands for Content After Beacon). This queue isn't connected to any station, but rather to the MAC context. This queue should (and is already) be set as the MCAST queue - this is part of the of MAC context command. Signed-off-by: Emmanuel Grumbach Reviewed-by: Ilan Peer Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit da989ee1c7702050741a551df6866cc1588f277b Author: Samuel Ortiz Date: Fri May 3 18:29:30 2013 +0200 NFC: llcp: Fix non blocking sockets connections commit b4011239a08e7e6c2c6e970dfa9e8ecb73139261 upstream. Without the new LLCP_CONNECTING state, non blocking sockets will be woken up with a POLLHUP right after calling connect() because their state is stuck at LLCP_CLOSED. That prevents userspace from implementing any proper non blocking socket based NFC p2p client. Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit dfc855921b899a61b9cef8e48d74441a2876e75f Author: Nicolas Ferre Date: Thu Apr 18 10:13:21 2013 +0200 ARM: at91: at91sam9x5 RTC is not compatible with at91rm9200 one commit 23fb05c688a8dcb0cf6a4d8d819cffeca82e5c54 upstream. Due to a bug with RTC IMR, we cannot consider at91sam9x5 RTC compatible with the previous one. Modify DT compatibility string, even if the driver is not yet modified to take it into account. Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit 16a06df257641d466895454f0320b8ccb1583b21 Author: Vineet Gupta Date: Tue Aug 20 13:38:11 2013 +0530 ARC: gdbserver breakage in Big-Endian configuration #2 [Based on mainline commit 352c1d95e3220d0: "ARC: stop using pt_regs->orig_r8"] Stop using orig_r8 as it could get clobbered by ST in trap_with_param, and further it is semantically not needed either. Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit 9b2c750d8e81da33cdf6e16db911faa2008652cd Author: Vineet Gupta Date: Tue Aug 20 13:38:10 2013 +0530 ARC: gdbserver breakage in Big-Endian configuration #1 [Based on mainline commit 502a0c775c7f0a: "ARC: pt_regs update #5"] gdbserver needs @stop_pc, served by ptrace, but fetched from pt_regs differently, based on in_brkpt_traps(), which in turn relies on additional machine state in pt_regs->event bitfield. unsigned long orig_r8:16, event:16; For big endian config, this macro was returning false, despite being in breakpoint Trap exception, causing wrong @stop_pc to be returned to gdb. Issue #1: In BE, @event above is at offset 2 in word, while a STW insn at offset 0 was used to update it. Resort to using ST insn which updates the half-word at right location. Issue #2: The union involving bitfields causes all the members to be laid out at offset 0. So with fix #1 above, ASM was now updating at offset 2, "C" code was still referencing at offset 0. Fixed by wrapping bitfield in a struct. Reported-by: Noam Camus Tested-by: Anton Kolesov Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit 6e4fdb803584635587bd4dc00d1f8c0883a02d3b Author: Rafael J. Wysocki Date: Wed Aug 7 22:55:00 2013 +0200 ACPI: Try harder to resolve _ADR collisions for bridges commit 60f75b8e97daf4a39790a20d962cb861b9220af5 upstream. In theory, under a given ACPI namespace node there should be only one child device object with _ADR whose value matches a given bus address exactly. In practice, however, there are systems in which multiple child device objects under a given parent have _ADR matching exactly the same address. In those cases we use _STA to determine which of the multiple matching devices is enabled, since some systems are known to indicate which ACPI device object to associate with the given physical (usually PCI) device this way. Unfortunately, as it turns out, there are systems in which many device objects under the same parent have _ADR matching exactly the same bus address and none of them has _STA, in which case they all should be regarded as enabled according to the spec. Still, if those device objects are supposed to represent bridges (e.g. this is the case for device objects corresponding to PCIe ports), we can try harder and skip the ones that have no child device objects in the ACPI namespace. With luck, we can avoid using device objects that we are not expected to use this way. Although this only works for bridges whose children also have ACPI namespace representation, it is sufficient to address graphics adapter detection issues on some systems, so rework the code finding a matching device ACPI handle for a given bus address to implement this idea. Introduce a new function, acpi_find_child(), taking three arguments: the ACPI handle of the device's parent, a bus address suitable for the device's bus type and a bool indicating if the device is a bridge and make it work as outlined above. Reimplement the function currently used for this purpose, acpi_get_child(), as a call to acpi_find_child() with the last argument set to 'false' and make the PCI subsystem use acpi_find_child() with the bridge information passed as the last argument to it. [Lan Tianyu notices that it is not sufficient to use pci_is_bridge() for that, because the device's subordinate pointer hasn't been set yet at this point, so use hdr_type instead.] This change fixes a regression introduced inadvertently by commit 33f767d (ACPI: Rework acpi_get_child() to be more efficient) which overlooked the fact that for acpi_walk_namespace() "post-order" means "after all children have been visited" rather than "on the way back", so for device objects without children and for namespace walks of depth 1, as in the acpi_get_child() case, the "post-order" callbacks ordering is actually the same as the ordering of "pre-order" ones. Since that commit changed the namespace walk in acpi_get_child() to terminate after finding the first matching object instead of going through all of them and returning the last one, it effectively changed the result returned by that function in some rare cases and that led to problems (the switch from a "pre-order" to a "post-order" callback was supposed to prevent that from happening, but it was ineffective). As it turns out, the systems where the change made by commit 33f767d actually matters are those where there are multiple ACPI device objects representing the same PCIe port (which effectively is a bridge). Moreover, only one of them, and the one we are expected to use, has child device objects in the ACPI namespace, so the regression can be addressed as described above. References: https://bugzilla.kernel.org/show_bug.cgi?id=60561 Reported-by: Peter Wu Tested-by: Vladimir Lalov Signed-off-by: Rafael J. Wysocki Acked-by: Bjorn Helgaas Cc: Peter Wu Signed-off-by: Greg Kroah-Hartman commit 2ac3b5e4a97cd3c677ea27ce1136c21018e75cbf Author: Jeff Wu Date: Wed May 29 06:31:30 2013 +0000 ACPI: add _STA evaluation at do_acpi_find_child() commit c7d9ca90aa9497f0b6e301ec67c52dd4b57a7852 upstream. Once do_acpi_find_child() has found the first matching handle, it makes the acpi_get_child() loop stop and return that handle. On some platforms, though, there are multiple devices with the same value of "_ADR" in the same namespace scope, and if one of them is enabled, the others will be disabled. For example: Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV0 Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV1 Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV2 If DEV0 and DEV1 are disabled and DEV2 is enabled, the handle of DEV2 should be returned, but actually the function always returns the handle of DEV0. To address that issue, make do_acpi_find_child() evaluate _STA to check the device status. If a matching device object exists, but is disabled, acpi_get_child() will continue to walk the namespace in the hope of finding an enabled one. If one is found, its handle will be returned, but otherwise the function will return the handle of the disabled object found before (in case it is enabled going forward). [rjw: Changelog] Signed-off-by: Jeff Wu Signed-off-by: Rafael J. Wysocki Cc: Peter Wu Signed-off-by: Greg Kroah-Hartman commit e0f23666f0d04cf80c18fdc7ad762d1a55187d9c Author: Johannes Berg Date: Mon Jul 29 23:07:43 2013 +0200 mac80211: don't wait for TX status forever commit cb236d2d713cff83d024a82b836757d9e2b50715 upstream. TX status notification can get lost, or the frames could get stuck on the queue, so don't wait for the callback from the driver forever and instead time out after half a second. Signed-off-by: Johannes Berg Signed-off-by: Luciano Coelho Signed-off-by: Greg Kroah-Hartman commit 6904756d54d4f98a9f835ed9cbc3f149ef7ac678 Author: Dominik Dingel Date: Fri Jul 26 15:04:00 2013 +0200 KVM: s390: move kvm_guest_enter,exit closer to sie commit 2b29a9fdcb92bfc6b6f4c412d71505869de61a56 upstream. Any uaccess between guest_enter and guest_exit could trigger a page fault, the page fault handler would handle it as a guest fault and translate a user address as guest address. Signed-off-by: Dominik Dingel Signed-off-by: Christian Borntraeger Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman