commit 352cb8677f83a6cf2139151578c8c79785d2d4bf Author: Greg Kroah-Hartman Date: Mon Aug 10 12:22:34 2015 -0700 Linux 4.1.5 commit ace89c9942b31342c008d26601ad7f89dfeedb06 Author: Arnaldo Carvalho de Melo Date: Mon Jul 13 08:21:57 2015 -0300 perf symbols: Store if there is a filter in place commit 0bc2f2f7d080561cc484d2d0a162a9396bed3383 upstream. When setting yup the symbols library we setup several filter lists, for dsos, comms, symbols, etc, and there is code that, if there are filters, do certain operations, like recalculate the number of non filtered histogram entries in the top/report TUI. But they were considering just the "Zoom" filters, when they need to take into account as well the above mentioned filters (perf top --comms, --dsos, etc). So store in symbol_conf.has_filter true if any of those filters is in place. Cc: Adrian Hunter Cc: Borislav Petkov Cc: David Ahern Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Namhyung Kim Cc: Stephane Eranian Link: http://lkml.kernel.org/n/tip-f5edfmhq69vfvs1kmikq1wep@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Cc: Andre Tomt Signed-off-by: Greg Kroah-Hartman commit d00799670008b9d6745e2b4adb1f7e09b3e71069 Author: Dave Chinner Date: Wed Jul 29 11:48:02 2015 +1000 xfs: remote attributes need to be considered data commit df150ed102baa0e78c06e08e975dfb47147dd677 upstream. We don't log remote attribute contents, and instead write them synchronously before we commit the block allocation and attribute tree update transaction. As a result we are writing to the allocated space before the allcoation has been made permanent. As a result, we cannot consider this allocation to be a metadata allocation. Metadata allocation can take blocks from the free list and so reuse them before the transaction that freed the block is committed to disk. This behaviour is perfectly fine for journalled metadata changes as log recovery will ensure the free operation is replayed before the overwrite, but for remote attribute writes this is not the case. Hence we have to consider the remote attribute blocks to contain data and allocate accordingly. We do this by dropping the XFS_BMAPI_METADATA flag from the block allocation. This means the allocation will not use blocks that are on the busy list without first ensuring that the freeing transaction has been committed to disk and the blocks removed from the busy list. This ensures we will never overwrite a freed block without first ensuring that it is really free. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit ff7f8c6411b43080cd8dc5907e2ef9613934daab Author: Dave Chinner Date: Wed Jul 29 11:48:01 2015 +1000 xfs: remote attribute headers contain an invalid LSN commit e3c32ee9e3e747fec01eb38e6610a9157d44c3ea upstream. In recent testing, a system that crashed failed log recovery on restart with a bad symlink buffer magic number: XFS (vda): Starting recovery (logdev: internal) XFS (vda): Bad symlink block magic! XFS: Assertion failed: 0, file: fs/xfs/xfs_log_recover.c, line: 2060 On examination of the log via xfs_logprint, none of the symlink buffers in the log had a bad magic number, nor were any other types of buffer log format headers mis-identified as symlink buffers. Tracing was used to find the buffer the kernel was tripping over, and xfs_db identified it's contents as: 000: 5841524d 00000000 00000346 64d82b48 8983e692 d71e4680 a5f49e2c b317576e 020: 00000000 00602038 00000000 006034ce d0020000 00000000 4d4d4d4d 4d4d4d4d 040: 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 060: 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d ..... This is a remote attribute buffer, which are notable in that they are not logged but are instead written synchronously by the remote attribute code so that they exist on disk before the attribute transactions are committed to the journal. The above remote attribute block has an invalid LSN in it - cycle 0xd002000, block 0 - which means when log recovery comes along to determine if the transaction that writes to the underlying block should be replayed, it sees a block that has a future LSN and so does not replay the buffer data in the transaction. Instead, it validates the buffer magic number and attaches the buffer verifier to it. It is this buffer magic number check that is failing in the above assert, indicating that we skipped replay due to the LSN of the underlying buffer. The problem here is that the remote attribute buffers cannot have a valid LSN placed into them, because the transaction that contains the attribute tree pointer changes and the block allocation that the attribute data is being written to hasn't yet been committed. Hence the LSN field in the attribute block is completely unwritten, thereby leaving the underlying contents of the block in the LSN field. It could have any value, and hence a future overwrite of the block by log recovery may or may not work correctly. Fix this by always writing an invalid LSN to the remote attribute block, as any buffer in log recovery that needs to write over the remote attribute should occur. We are protected from having old data written over the attribute by the fact that freeing the block before the remote attribute is written will result in the buffer being marked stale in the log and so all changes prior to the buffer stale transaction will be cancelled by log recovery. Hence it is safe to ignore the LSN in the case or synchronously written, unlogged metadata such as remote attribute blocks, and to ensure we do that correctly, we need to write an invalid LSN to all remote attribute blocks to trigger immediate recovery of metadata that is written over the top. As a further protection for filesystems that may already have remote attribute blocks with bad LSNs on disk, change the log recovery code to always trigger immediate recovery of metadata over remote attribute blocks. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit 58e8dcc3d24e8115e8d0d988c8a0c68992a1c8fb Author: Kamil Dudka Date: Wed Jul 15 22:57:43 2015 +0200 drm/nouveau/drm/nv04-nv40/instmem: protect access to priv->heap by mutex commit 7512223b1ece29a5968ed8b67ccb891d21b7834b upstream. This fixes the list_del corruption reported at . Signed-off-by: Kamil Dudka Signed-off-by: Greg Kroah-Hartman commit 53f092abcba808c59ae9d4744175e9c25287a81c Author: Kamil Dudka Date: Wed Jul 15 17:18:15 2015 +0200 drm/nouveau: hold mutex when calling nouveau_abi16_fini() commit ac8c79304280da6ef05c348a9da03ab04898b994 upstream. This was the only access to cli->abi16 without holding the mutex. Signed-off-by: Kamil Dudka Signed-off-by: Greg Kroah-Hartman commit 140d4baa12b22909676ea2be7cfdc12fa1572720 Author: Ben Skeggs Date: Tue Jul 28 17:20:57 2015 +1000 drm/nouveau/kms/nv50-: guard against enabling cursor on disabled heads commit 697bb728d9e2367020aa0c5af7363809d7658e43 upstream. Userspace has started doing this, which upsets the display class hw error checking in various unpleasant ways. Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 49aed64d0a9e9bce6e848440ed8bcce2d8fab558 Author: Ilia Mirkin Date: Mon Jun 29 04:07:20 2015 -0400 drm/nouveau/fbcon/nv11-: correctly account for ring space usage commit d108142c0840ce389cd9898aa76943b3fb430b83 upstream. The RING_SPACE macro accounts how much space is used up so it's important to ask it for the right amount. Incorrect accounting of this can cause page faults down the line as writes are attempted outside of the ring. Signed-off-by: Ilia Mirkin Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit de60f552147f87956aa3a56ecb410e4f583dc99d Author: Roland Dreier Date: Tue Jul 14 16:00:42 2015 -0400 qla2xxx: kill sessions/log out initiator on RSCN and port down events commit b2032fd567326ad0b2d443bb6d96d2580ec670a5 upstream. To fix some issues talking to ESX, this patch modifies the qla2xxx driver so that it never logs into remote ports. This has the side effect of getting rid of the "rports" entirely, which means we never log out of initiators and never tear down sessions when an initiator goes away. This is mostly OK, except that we can run into trouble if we have initiator A assigned FC address X:Y:Z by the fabric talking to us, and then initiator A goes away. Some time (could be a long time) later, initiator B comes along and also gets FC address X:Y:Z (which is available again, because initiator A is gone). If initiator B starts talking to us, then we'll still have the session for initiator A, and since we look up incoming IO based on the FC address X:Y:Z, initiator B will end up using ACLs for initiator A. Fix this by: 1. Handling RSCN events somewhat differently; instead of completely skipping the processing of fcports, we look through the list, and if an fcport disappears, we tell the target code the tear down the session and tell the HBA FW to release the N_Port handle. 2. Handling "port down" events by flushing all of our sessions. The firmware was already releasing the N_Port handle but we want the target code to drop all the sessions too. Signed-off-by: Roland Dreier Signed-off-by: Alexei Potashnik Acked-by: Quinn Tran Signed-off-by: Himanshu Madhani Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 1e6ff894cd9fd295a7447b243c4882749f0a5a0c Author: Kanoj Sarcar Date: Wed Jun 10 11:05:23 2015 -0400 qla2xxx: fix command initialization in target mode. commit 9fce12540cb9f91e7f1f539a80b70f0b388bdae0 upstream. Signed-off-by: Kanoj Sarcar Signed-off-by: Himanshu Madhani Reviewed-by: Nicholas Bellinger Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 6dad361baad76206bb51e9af1814bddb45a99488 Author: Himanshu Madhani Date: Wed Jun 10 11:05:22 2015 -0400 qla2xxx: Remove msleep in qlt_send_term_exchange commit 6bc85dd595a5438b50ec085668e53ef26058bb90 upstream. Remove unnecessary msleep from qlt_send_term_exchange as it adds latency of 250 msec while sending terminate exchange to an aborted task. Signed-off-by: Himanshu Madhani Signed-off-by: Giridhar Malavali Reviewed-by: Nicholas Bellinger Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 117118ea1a8e170b3461105439b563fb7e834fec Author: Quinn Tran Date: Wed Jun 10 11:05:20 2015 -0400 qla2xxx: release request queue reservation. commit 810e30bc4658e9c069577bde52394a5af872803c upstream. Request IOCB queue element(s) is reserved during good path IO. Under error condition such as unable to allocate IOCB handle condition, the IOCB count that was reserved is not released. Signed-off-by: Quinn Tran Signed-off-by: Himanshu Madhani Reviewed-by: Nicholas Bellinger Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit beca4eb65b6f392577ae2a6507eb3b3579f69dd3 Author: Saurav Kashyap Date: Wed Jun 10 11:05:17 2015 -0400 qla2xxx: Fix hardware lock/unlock issue causing kernel panic. commit ba9f6f64a0ff6b7ecaed72144c179061f8eca378 upstream. [ Upstream commit ef86cb2059a14b4024c7320999ee58e938873032 ] This patch fixes a kernel panic for qla2xxx Target core Module driver introduced by a fix in the qla2xxx initiator code. Commit ef86cb2 ("qla2xxx: Mark port lost when we receive an RSCN for it.") introduced the regression for qla2xxx Target driver. Stack trace will have following signature --- --- [ffff88081faa3cc8] _raw_spin_lock_irqsave at ffffffff815b1f03 [ffff88081faa3cd0] qlt_fc_port_deleted at ffffffffa096ccd0 [qla2xxx] [ffff88081faa3d20] qla2x00_schedule_rport_del at ffffffffa0913831[qla2xxx] [ffff88081faa3d50] qla2x00_mark_device_lost at ffffffffa09159c5[qla2xxx] [ffff88081faa3db0] qla2x00_async_event at ffffffffa0938d59 [qla2xxx] [ffff88081faa3e30] qla24xx_msix_default at ffffffffa093a326 [qla2xxx] [ffff88081faa3e90] handle_irq_event_percpu at ffffffff810a7b8d [ffff88081faa3ee0] handle_irq_event at ffffffff810a7d32 [ffff88081faa3f10] handle_edge_irq at ffffffff810ab6b9 [ffff88081faa3f30] handle_irq at ffffffff8100619c [ffff88081faa3f70] do_IRQ at ffffffff815b4b1c --- --- Signed-off-by: Saurav Kashyap Signed-off-by: Himanshu Madhani Reviewed-by: Nicholas Bellinger Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit c97cda421f4d5c34638423fb7e07e7968703e619 Author: Lukasz Anaczkowski Date: Tue Jul 21 10:41:13 2015 +0200 intel_pstate: Add get_scaling cpu_defaults param to Knights Landing commit 69cefc273f942bd7bb347a02e8b5b738d5f6e6f3 upstream. Scaling for Knights Landing is same as the default scaling (100000). When Knigts Landing support was added to the pstate driver, this parameter was omitted resulting in a kernel panic during boot. Fixes: b34ef932d79a (intel_pstate: Knights Landing support) Reported-by: Yasuaki Ishimatsu Signed-off-by: Dasaratharaman Chandramouli Signed-off-by: Lukasz Anaczkowski Acked-by: Kristen Carlson Accardi Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 725dbab305404b65d01d788cee4e5bedc2964150 Author: Nicholas Bellinger Date: Thu Jul 23 22:30:31 2015 +0000 iscsi-target: Fix iser explicit logout TX kthread leak commit 007d038bdf95ccfe2491d0078be54040d110fd06 upstream. This patch fixes a regression introduced with the following commit in v4.0-rc1 code, where an explicit iser-target logout would result in ->tx_thread_active being incorrectly cleared by the logout post handler, and subsequent TX kthread leak: commit 88dcd2dab5c23b1c9cfc396246d8f476c872f0ca Author: Nicholas Bellinger Date: Thu Feb 26 22:19:15 2015 -0800 iscsi-target: Convert iscsi_thread_set usage to kthread.h To address this bug, change iscsit_logout_post_handler_closesession() and iscsit_logout_post_handler_samecid() to only cmpxchg() on ->tx_thread_active for traditional iscsi/tcp connections. This is required because iscsi/tcp connections are invoking logout post handler logic directly from TX kthread context, while iser connections are invoking logout post handler logic from a seperate workqueue context. Cc: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 5f4f44a51d81bba3ce116857a7bdf4f45231ed58 Author: Nicholas Bellinger Date: Wed Jul 22 23:14:19 2015 -0700 iscsi-target: Fix iscsit_start_kthreads failure OOPs commit e54198657b65625085834847ab6271087323ffea upstream. This patch fixes a regression introduced with the following commit in v4.0-rc1 code, where a iscsit_start_kthreads() failure triggers a NULL pointer dereference OOPs: commit 88dcd2dab5c23b1c9cfc396246d8f476c872f0ca Author: Nicholas Bellinger Date: Thu Feb 26 22:19:15 2015 -0800 iscsi-target: Convert iscsi_thread_set usage to kthread.h To address this bug, move iscsit_start_kthreads() immediately preceeding the transmit of last login response, before signaling a successful transition into full-feature-phase within existing iscsi_target_do_tx_login_io() logic. This ensures that no target-side resource allocation failures can occur after the final login response has been successfully sent. Also, it adds a iscsi_conn->rx_login_comp to allow the RX thread to sleep to prevent other socket related failures until the final iscsi_post_login_handler() call is able to complete. Cc: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 00ff0eb11dbddcc2c2ba914f5d89755a43a0aa21 Author: Nicholas Bellinger Date: Wed Jul 22 00:24:09 2015 -0700 iscsi-target: Fix use-after-free during TPG session shutdown commit 417c20a9bdd1e876384127cf096d8ae8b559066c upstream. This patch fixes a use-after-free bug in iscsit_release_sessions_for_tpg() where se_portal_group->session_lock was incorrectly released/re-acquired while walking the active se_portal_group->tpg_sess_list. The can result in a NULL pointer dereference when iscsit_close_session() shutdown happens in the normal path asynchronously to this code, causing a bogus dereference of an already freed list entry to occur. To address this bug, walk the session list checking for the same state as before, but move entries to a local list to avoid dropping the lock while walking the active list. As before, signal using iscsi_session->session_restatement=1 for those list entries to be released locally by iscsit_free_session() code. Reported-by: Sunilkumar Nadumuttlu Cc: Sunilkumar Nadumuttlu Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit d1339ce0bcb285a0756bf9037f49e258b5df636f Author: Jason Gunthorpe Date: Wed Jul 22 14:30:03 2015 -0600 IB/ipoib: Fix CONFIG_INFINIBAND_IPOIB_CM commit efc1eedbf63a194b3b576fc25776f3f1fa55a4d4 upstream. If the above is turned off then ipoib_cm_dev_init unconditionally returns ENOSYS, and the newly added error handling in 0b3957 prevents ipoib from coming up at all: kernel: mlx4_0: ipoib_transport_dev_init failed kernel: mlx4_0: failed to initialize port 1 (ret = -12) Fixes: 0b39578bcde4 (IB/ipoib: Use dedicated workqueues per interface) Signed-off-by: Jason Gunthorpe Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 13e8ae1f4da1386297c2cf65522b38f8e24fa88a Author: Trond Myklebust Date: Mon Jul 27 10:23:19 2015 -0400 NFS: Fix a memory leak in nfs_do_recoalesce commit 03d5eb65b53889fe98a5ecddfe205c16e3093190 upstream. If the function exits early, then we must put those requests that were not processed back onto the &mirror->pg_list so they can be cleaned up by nfs_pgio_error(). Fixes: a7d42ddb30997 ("nfs: add mirroring support to pgio layer") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit c7231368e696a31c78e61189273999c0b5243bbf Author: Trond Myklebust Date: Wed Jul 22 13:46:13 2015 -0400 NFSv4: We must set NFS_OPEN_STATE flag in nfs_resync_open_stateid_locked commit 3c38cbe2ade88240fabb585b408f779ad3b9a31b upstream. Otherwise, nfs4_select_rw_stateid() will always return the zero stateid instead of the correct open stateid. Fixes: f95549cf24660 ("NFSv4: More CLOSE/OPEN races") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit c9bb1d26fe5747a4dbea75fe37e6474f6abbcdad Author: Andy Shevchenko Date: Fri Jul 24 13:49:48 2015 +0300 avr32: handle NULL as a valid clock object commit 5c02a4206538da12c040b51778d310df84c6bf6c upstream. Since NULL is used as valid clock object on optional clocks we have to handle this case in avr32 implementation as well. Fixes: e1824dfe0d8e (net: macb: Adjust tx_clk when link speed changes) Signed-off-by: Andy Shevchenko Acked-by: Hans-Christian Egtvedt Signed-off-by: Greg Kroah-Hartman commit f22d5595d56d15b7aadc0ff5cc47e8811d4c9eb1 Author: Trond Myklebust Date: Sun Jul 5 11:02:53 2015 -0400 NFS: Don't revalidate the mapping if both size and change attr are up to date commit 85a23cee3f2c928475f31777ead5a71340a12fc3 upstream. If we've ensured that the size and the change attribute are both correct, then there is no point in marking those attributes as needing revalidation again. Only do so if we know the size is incorrect and was not updated. Fixes: f2467b6f64da ("NFS: Clear NFS_INO_REVAL_PAGECACHE when...") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit fe7c1d336dff21503aa08bda735519aeed795afb Author: Guenter Roeck Date: Mon Jul 27 10:21:46 2015 -0700 hwmon: (nct7904) Rename pwm attributes to match hwmon ABI commit 0d6aaffc3a6db642e0a165ba4d17d6d7bbaf5201 upstream. pwm attributes have well defined names, which should be used. Cc: Vadim V. Vlasov Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 1c57a6c95d3de1ea32010d88b9b93984d3302e8d Author: Guenter Roeck Date: Sat Jul 4 13:23:42 2015 -0700 hwmon: (nct7802) Fix integer overflow seen when writing voltage limits commit 9200bc4c28cd8992eb5379345abd6b4f0c93df16 upstream. Writing a large value into a voltage limit attribute can result in an overflow due to an auto-conversion from unsigned long to unsigned int. Cc: Constantine Shulyupin Reviewed-by: Jean Delvare Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit fd1a8f57bfd8686709c17cbe878470bd43fb3c4e Author: Marc-André Lureau Date: Fri Jul 17 15:32:03 2015 +0200 vhost: actually track log eventfd file commit 7932c0bd7740f4cd2aa168d3ce0199e7af7d72d5 upstream. While reviewing vhost log code, I found out that log_file is never set. Note: I haven't tested the change (QEMU doesn't use LOG_FD yet). Signed-off-by: Marc-André Lureau Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit f919f7a4d004513372807cedc14fac43f0652c4c Author: Matt Fleming Date: Tue Jul 21 15:55:09 2015 +0100 perf/x86/intel/cqm: Return cached counter value from IRQ context commit 2c534c0da0a68418693e10ce1c4146e085f39518 upstream. Peter reported the following potential crash which I was able to reproduce with his test program, [ 148.765788] ------------[ cut here ]------------ [ 148.765796] WARNING: CPU: 34 PID: 2840 at kernel/smp.c:417 smp_call_function_many+0xb6/0x260() [ 148.765797] Modules linked in: [ 148.765800] CPU: 34 PID: 2840 Comm: perf Not tainted 4.2.0-rc1+ #4 [ 148.765803] ffffffff81cdc398 ffff88085f105950 ffffffff818bdfd5 0000000000000007 [ 148.765805] 0000000000000000 ffff88085f105990 ffffffff810e413a 0000000000000000 [ 148.765807] ffffffff82301080 0000000000000022 ffffffff8107f640 ffffffff8107f640 [ 148.765809] Call Trace: [ 148.765810] [] dump_stack+0x45/0x57 [ 148.765818] [] warn_slowpath_common+0x8a/0xc0 [ 148.765822] [] ? intel_cqm_stable+0x60/0x60 [ 148.765824] [] ? intel_cqm_stable+0x60/0x60 [ 148.765825] [] warn_slowpath_null+0x1a/0x20 [ 148.765827] [] smp_call_function_many+0xb6/0x260 [ 148.765829] [] ? intel_cqm_stable+0x60/0x60 [ 148.765831] [] on_each_cpu_mask+0x28/0x60 [ 148.765832] [] intel_cqm_event_count+0x7f/0xe0 [ 148.765836] [] perf_output_read+0x2a5/0x400 [ 148.765839] [] perf_output_sample+0x31a/0x590 [ 148.765840] [] ? perf_prepare_sample+0x26d/0x380 [ 148.765841] [] perf_event_output+0x47/0x60 [ 148.765843] [] __perf_event_overflow+0x215/0x240 [ 148.765844] [] perf_event_overflow+0x14/0x20 [ 148.765847] [] intel_pmu_handle_irq+0x1d4/0x440 [ 148.765849] [] ? __perf_event_task_sched_in+0x36/0xa0 [ 148.765853] [] ? vunmap_page_range+0x19d/0x2f0 [ 148.765854] [] ? unmap_kernel_range_noflush+0x11/0x20 [ 148.765859] [] ? ghes_copy_tofrom_phys+0x11e/0x2a0 [ 148.765863] [] ? native_apic_msr_write+0x2b/0x30 [ 148.765865] [] ? x2apic_send_IPI_self+0x1d/0x20 [ 148.765869] [] ? arch_irq_work_raise+0x35/0x40 [ 148.765872] [] ? irq_work_queue+0x66/0x80 [ 148.765875] [] perf_event_nmi_handler+0x26/0x40 [ 148.765877] [] nmi_handle+0x79/0x100 [ 148.765879] [] default_do_nmi+0x42/0x100 [ 148.765880] [] do_nmi+0x83/0xb0 [ 148.765884] [] end_repeat_nmi+0x1e/0x2e [ 148.765886] [] ? __perf_event_task_sched_in+0x36/0xa0 [ 148.765888] [] ? __perf_event_task_sched_in+0x36/0xa0 [ 148.765890] [] ? __perf_event_task_sched_in+0x36/0xa0 [ 148.765891] <> [] finish_task_switch+0x156/0x210 [ 148.765898] [] __schedule+0x341/0x920 [ 148.765899] [] schedule+0x37/0x80 [ 148.765903] [] ? do_page_fault+0x2f/0x80 [ 148.765905] [] schedule_user+0x1a/0x50 [ 148.765907] [] retint_careful+0x14/0x32 [ 148.765908] ---[ end trace e33ff2be78e14901 ]--- The CQM task events are not safe to be called from within interrupt context because they require performing an IPI to read the counter value on all sockets. And performing IPIs from within IRQ context is a "no-no". Make do with the last read counter value currently event in event->count when we're invoked in this context. Reported-by: Peter Zijlstra Signed-off-by: Matt Fleming Cc: Thomas Gleixner Cc: Vikas Shivappa Cc: Kanaka Juvva Cc: Will Auld Link: http://lkml.kernel.org/r/1437490509-15373-1-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit d9aa2c20eef957e4b28c4f835bbc749035c4e5ef Author: Arnaldo Carvalho de Melo Date: Mon Jul 13 08:26:35 2015 -0300 perf hists browser: Take the --comm, --dsos, etc filters into account commit 9c0fa8dd3d58de8b688fda758eea1719949c7f0a upstream. At some point: commit 2c86c7ca7606 Author: Namhyung Kim Date: Mon Mar 17 18:18:54 2014 -0300 perf report: Merge al->filtered with hist_entry->filtered We stopped dropping samples for things filtered via the --comms, --dsos, --symbols, etc, i.e. things marked as filtered in the symbol resolution routines (thread__find_addr_map(), perf_event__preprocess_sample(), etc). But then, in: commit 268397cb2a47 Author: Namhyung Kim Date: Tue Apr 22 14:49:31 2014 +0900 perf top/tui: Update nr_entries properly after a filter is applied We don't take into account entries that were filtered in perf_event__preprocess_sample() and friends, which leads to inconsistency in the browser seek routines, that expects the number of hist_entry->filtered entries to match what it thinks is the number of unfiltered, browsable entries. So, for instance, when we do: perf top --symbols ___non_existent_symbol___ the hist_browser__nr_entries() routine thinks there are no filters in place, uses the hists->nr_entries but all entries are filtered, leading to a segfault. Tested with: perf top --symbols malloc,free --percentage=relative Freezing, by pressing 'f', at any time and doing the math on the percentages ends up with 100%, ditto for: perf top --dsos libpthread-2.20.so,libxul.so --percentage=relative Both were segfaulting, all fixed now. More work needed to do away with checking if filters are in place, we should just use the nr_non_filtered_samples counter, no need to conditionally use it or hists.nr_filter, as what the browser does is just show unfiltered stuff. An audit of how it is being accounted is needed, this is the minimal fix. Reported-by: Michael Petlan Fixes: 268397cb2a47 ("perf top/tui: Update nr_entries properly after a filter is applied") Cc: Adrian Hunter Cc: Borislav Petkov Cc: David Ahern Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Namhyung Kim Cc: Stephane Eranian Link: http://lkml.kernel.org/n/tip-6w01d5q97qk0d64kuojme5in@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 3425ebac158abf137ce7dcbe062baeb4c04e0097 Author: Ming Lei Date: Thu Jul 16 19:53:22 2015 +0800 blk-mq: set default timeout as 30 seconds commit e56f698bd0720e17f10f39e8b0b5b446ad0ab22c upstream. It is reasonable to set default timeout of request as 30 seconds instead of 30000 ticks, which may be 300 seconds if HZ is 100, for example, some arm64 based systems may choose 100 HZ. Signed-off-by: Ming Lei Fixes: c76cbbcf4044 ("blk-mq: put blk_queue_rq_timeout together in blk_mq_init_queue()" Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ba3961ad681981dc74fcd519b8f98be8bc3ac381 Author: Peter Hurley Date: Sat Jun 27 09:21:32 2015 -0400 n_tty: signal and flush atomically commit 3b19e032295647b7be2aa3be62510db4aaeda759 upstream. When handling signalling char, claim the termios write lock before signalling waiting readers and writers to prevent further i/o before flushing the echo and output buffers. This prevents a userspace signal handler which may output from racing the terminal flush. Reference: Bugzilla #99351 ("Output truncated in ssh session after...") Fixes: commit d2b6f44779d3 ("n_tty: Fix signal handling flushes") Reported-by: Filipe Brandenburger Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman commit f3ef6ad3e4501dae41b0015a3bd8e179b56bdfd8 Author: Wengang Wang Date: Mon Jul 6 14:35:11 2015 +0800 rds: rds_ib_device.refcount overflow commit 4fabb59449aa44a585b3603ffdadd4c5f4d0c033 upstream. Fixes: 3e0249f9c05c ("RDS/IB: add refcount tracking to struct rds_ib_device") There lacks a dropping on rds_ib_device.refcount in case rds_ib_alloc_fmr failed(mr pool running out). this lead to the refcount overflow. A complain in line 117(see following) is seen. From vmcore: s_ib_rdma_mr_pool_depleted is 2147485544 and rds_ibdev->refcount is -2147475448. That is the evidence the mr pool is used up. so rds_ib_alloc_fmr is very likely to return ERR_PTR(-EAGAIN). 115 void rds_ib_dev_put(struct rds_ib_device *rds_ibdev) 116 { 117 BUG_ON(atomic_read(&rds_ibdev->refcount) <= 0); 118 if (atomic_dec_and_test(&rds_ibdev->refcount)) 119 queue_work(rds_wq, &rds_ibdev->free_work); 120 } fix is to drop refcount when rds_ib_alloc_fmr failed. Signed-off-by: Wengang Wang Reviewed-by: Haggai Eran Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 26121b675728939c515594b2bb866756b7789c16 Author: Vineet Gupta Date: Fri Jul 3 11:26:22 2015 +0530 ARC: Make ARC bitops "safer" (add anti-optimization) commit 80f420842ff42ad61f84584716d74ef635f13892 upstream. ARCompact/ARCv2 ISA provide that any instructions which deals with bitpos/count operand ASL, LSL, BSET, BCLR, BMSK .... will only consider lower 5 bits. i.e. auto-clamp the pos to 0-31. ARC Linux bitops exploited this fact by NOT explicitly masking out upper bits for @nr operand in general, saving a bunch of AND/BMSK instructions in generated code around bitops. While this micro-optimization has worked well over years it is NOT safe as shifting a number with a value, greater than native size is "undefined" per "C" spec. So as it turns outm EZChip ran into this eventually, in their massive muti-core SMP build with 64 cpus. There was a test_bit() inside a loop from 63 to 0 and gcc was weirdly optimizing away the first iteration (so it was really adhering to standard by implementing undefined behaviour vs. removing all the iterations which were phony i.e. (1 << [63..32]) | for i = 63 to 0 | X = ( 1 << i ) | if X == 0 | continue So fix the code to do the explicit masking at the expense of generating additional instructions. Fortunately, this can be mitigated to a large extent as gcc has SHIFT_COUNT_TRUNCATED which allows combiner to fold masking into shift operation itself. It is currently not enabled in ARC gcc backend, but could be done after a bit of testing. Fixes STAR 9000866918 ("unsafe "undefined behavior" code in kernel") Reported-by: Noam Camus Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit 3092e514c62477fa17401667d4ffb4921b14842c Author: Vineet Gupta Date: Tue Mar 31 22:38:21 2015 +0530 ARC: Reduce bitops lines of code using macros commit 04e2eee4b02edcafce96c9c37b31b1a3318291a4 upstream. No semantical changes ! Acked-by: Peter Zijlstra (Intel) Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit e8647ec68feb66acd35b0f7fa3177bb47cc6a94e Author: Dmitry Skorodumov Date: Tue Jul 28 18:38:32 2015 +0400 x86/efi: Use all 64 bit of efi_memmap in setup_e820() commit 7cc03e48965453b5df1cce5062c826189b04b960 upstream. The efi_info structure stores low 32 bits of memory map in efi_memmap and high 32 bits in efi_memmap_hi. While constructing pointer in the setup_e820(), need to take into account all 64 bit of the pointer. It is because on 64bit machine the function efi_get_memory_map() may return full 64bit pointer and before the patch that pointer was truncated. The issue is triggered on Parallles virtual machine and fixed with this patch. Signed-off-by: Dmitry Skorodumov Cc: Denis V. Lunev Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit c54f557fa580989c304cc5c83528efa5a1819a85 Author: Ricardo Neri Date: Wed Jul 15 19:36:03 2015 -0700 efi: Check for NULL efi kernel parameters commit 9115c7589b11349a1c3099758b4bded579ff69e0 upstream. Even though it is documented how to specifiy efi parameters, it is possible to cause a kernel panic due to a dereference of a NULL pointer when parsing such parameters if "efi" alone is given: PANIC: early exception 0e rip 10:ffffffff812fb361 error 0 cr2 0 [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0-rc1+ #450 [ 0.000000] ffffffff81fe20a9 ffffffff81e03d50 ffffffff8184bb0f 00000000000003f8 [ 0.000000] 0000000000000000 ffffffff81e03e08 ffffffff81f371a1 64656c62616e6520 [ 0.000000] 0000000000000069 000000000000005f 0000000000000000 0000000000000000 [ 0.000000] Call Trace: [ 0.000000] [] dump_stack+0x45/0x57 [ 0.000000] [] early_idt_handler_common+0x81/0xae [ 0.000000] [] ? parse_option_str+0x11/0x90 [ 0.000000] [] arch_parse_efi_cmdline+0x15/0x42 [ 0.000000] [] do_early_param+0x50/0x8a [ 0.000000] [] parse_args+0x1e3/0x400 [ 0.000000] [] parse_early_options+0x24/0x28 [ 0.000000] [] ? loglevel+0x31/0x31 [ 0.000000] [] parse_early_param+0x31/0x3d [ 0.000000] [] setup_arch+0x2de/0xc08 [ 0.000000] [] ? vprintk_default+0x1a/0x20 [ 0.000000] [] start_kernel+0x90/0x423 [ 0.000000] [] x86_64_start_reservations+0x2a/0x2c [ 0.000000] [] x86_64_start_kernel+0xeb/0xef [ 0.000000] RIP 0xffffffff81ba2efc This panic is not reproducible with "efi=" as this will result in a non-NULL zero-length string. Thus, verify that the pointer to the parameter string is not NULL. This is consistent with other parameter-parsing functions which check for NULL pointers. Signed-off-by: Ricardo Neri Cc: Dave Young Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit b3525bdf91087473d4490ab7acc31f59821cc04a Author: Ard Biesheuvel Date: Sun Jul 26 14:59:00 2015 +0200 arm64/efi: map the entire UEFI vendor string before reading it commit f91b1feada0b6f0a4d33648155b3ded2c4e0707e upstream. At boot, the UTF-16 UEFI vendor string is copied from the system table into a char array with a size of 100 bytes. However, this size of 100 bytes is also used for memremapping() the source, which may not be sufficient if the vendor string exceeds 50 UTF-16 characters, and the placement of the vendor string inside a 4 KB page happens to leave the end unmapped. So use the correct '100 * sizeof(efi_char16_t)' for the size of the mapping. Signed-off-by: Ard Biesheuvel Fixes: f84d02755f5a ("arm64: add EFI runtime services") Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 07ddeec8a096a8d6e8be2af06703b3e828c15d59 Author: Luck, Tony Date: Tue Jun 30 15:57:51 2015 -0700 efi: Handle memory error structures produced based on old versions of standard commit 4c62360d7562a20c996836d163259c87d9378120 upstream. The memory error record structure includes as its first field a bitmask of which subsequent fields are valid. The allows new fields to be added to the structure while keeping compatibility with older software that parses these records. This mechanism was used between versions 2.2 and 2.3 to add four new fields, growing the size of the structure from 73 bytes to 80. But Linux just added all the new fields so this test: if (gdata->error_data_length >= sizeof(*mem_err)) cper_print_mem(newpfx, mem_err); else goto err_section_too_small; now make Linux complain about old format records being too short. Add a definition for the old format of the structure and use that for the minimum size check. Pass the actual size to cper_print_mem() so it can sanity check the validation_bits field to ensure that if a BIOS using the old format sets bits as if it were new, we won't access fields beyond the end of the structure. Signed-off-by: Tony Luck Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit 5728ec989adce2f303000b84469750579f162c2d Author: Dave Hansen Date: Mon Jul 20 16:01:53 2015 -0700 x86/mm: Add parenthesis for TLB tracepoint size calculation commit bbc03778b9954a2ec93baed63718e4df0192f130 upstream. flush_tlb_info->flush_start/end are both normal virtual addresses. When calculating 'nr_pages' (only used for the tracepoint), I neglected to put parenthesis in. Thanks to David Koufaty for pointing this out. Signed-off-by: Dave Hansen Cc: Andrew Morton Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: dave@sr71.net Link: http://lkml.kernel.org/r/20150720230153.9E834081@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 35c8bade335f6d747f4567cfa5b678b6798a2187 Author: Tomas Winkler Date: Thu Jun 18 11:41:03 2015 +0300 mei: prevent unloading mei hw modules while the device is opened. commit 154322f47376fed6ab1e4b350aa45fffa15a61aa upstream. chrdev_open() increases reference counter on cdev->owner. Instead of assigning the owner to mei subsystem, the owner has to be set to the underlaying HW module (mei_me or mei_txe), so once the device is opened the HW module cannot be unloaded. Signed-off-by: Tomas Winkler Signed-off-by: Alexander Usyskin Signed-off-by: Greg Kroah-Hartman commit 81b75e85593dcbfde8a86cd44bd75cc96a22849e Author: Zhuang Jin Can Date: Tue Jul 21 17:20:31 2015 +0300 xhci: do not report PLC when link is in internal resume state commit aca3a0489ac019b58cf32794d5362bb284cb9b94 upstream. Port link change with port in resume state should not be reported to usbcore, as this is an internal state to be handled by xhci driver. Reporting PLC to usbcore may cause usbcore clearing PLC first and port change event irq won't be generated. Signed-off-by: Zhuang Jin Can Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit c65fd970bbb46be9e517d93e67b5e9f27f5e45a0 Author: Zhuang Jin Can Date: Tue Jul 21 17:20:30 2015 +0300 xhci: prevent bus_suspend if SS port resuming in phase 1 commit fac4271d1126c45ceaceb7f4a336317b771eb121 upstream. When the link is just waken, it's in Resume state, and driver sets PLS to U0. This refers to Phase 1. Phase 2 refers to when the link has completed the transition from Resume state to U0. With the fix of xhci: report U3 when link is in resume state, it also exposes an issue that usb3 roothub and controller can suspend right after phase 1, and this causes a hard hang in controller. To fix the issue, we need to prevent usb3 bus suspend if any port is resuming in phase 1. [merge separate USB2 and USB3 port resume checking to one -Mathias] Signed-off-by: Zhuang Jin Can Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 6f0433c52944a822f338f300fff672fa2fd43ac5 Author: Zhuang Jin Can Date: Tue Jul 21 17:20:29 2015 +0300 xhci: report U3 when link is in resume state commit 243292a2ad3dc365849b820a64868927168894ac upstream. xhci_hub_report_usb3_link_state() returns pls as U0 when the link is in resume state, and this causes usb core to think the link is in U0 while actually it's in resume state. When usb core transfers control request on the link, it fails with TRB error as the link is not ready for transfer. To fix the issue, report U3 when the link is in resume state, thus usb core knows the link it's not ready for transfer. Signed-off-by: Zhuang Jin Can Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit eb9a669517a2eeb2e55fff733191c128b2f55830 Author: Brian Campbell Date: Tue Jul 21 17:20:28 2015 +0300 xhci: Calculate old endpoints correctly on device reset commit 326124a027abc9a7f43f72dc94f6f0f7a55b02b3 upstream. When resetting a device the number of active TTs may need to be corrected by xhci_update_tt_active_eps, but the number of old active endpoints supplied to it was always zero, so the number of TTs and the bandwidth reserved for them was not updated, and could rise unnecessarily. This affected systems using Intel's Patherpoint chipset, which rely on software bandwidth checking. For example, a Lenovo X230 would lose the ability to use ports on the docking station after enough suspend/resume cycles because the bandwidth calculated would rise with every cycle when a suitable device is attached. The correct number of active endpoints is calculated in the same way as in xhci_reserve_bandwidth. Signed-off-by: Brian Campbell Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit df86527517e8cd14f7ebec7302e70590543a49b5 Author: Peter Hurley Date: Sun Jul 12 21:05:26 2015 -0400 serial: core: Fix crashes while echoing when closing commit e144c58cad6667876173dd76977e9e6557e34941 upstream. While closing, new rx data may be received after the input buffers have been flushed but before stop_rx() halts receiving [1]. The new data might not be processed by flush_to_ldisc() until after uart_shutdown() and normal input processing is re-enabled (ie., tty->closing = 0). The race is outlined below: CPU 0 | CPU 1 | uart_close() | tty_port_close_start() | tty->closing = 1 | tty_ldisc_flush() | | => IRQ | while (LSR & data ready) | uart_insert_char() | tty_flip_buffer_push() | <= EOI stop_rx() | . uart_shutdown() | . free xmit.buf | . tty_port_tty_set(NULL) | . tty->closing = 0 | . | flush_to_ldisc() | n_tty_receive_buf_common() | __receive_buf() | ... | commit_echoes() | uart_flush_chars() | __uart_start() | ** OOPS on port.tty deref ** tty_ldisc_flush() | Input processing must be prevented from echoing (tty->closing = 1) until _after_ the input buffers have been flushed again at the end of uart_close(). [1] In fact, some input may actually be buffered _after_ stop_rx() since the rx interrupt may have already triggered but not yet been handled when stop_rx() disables rx interrupts. Fixes: 2e758910832d ("serial: core: Flush ldisc after dropping port mutex in uart_close()") Reported-by: Robert Elliott Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 4eede03b97bf6d89681905668e983f99b5847827 Author: David Jander Date: Fri Jun 26 08:11:30 2015 +0200 Revert "serial: imx: initialized DMA w/o HW flow enabled" commit 907eda32a36fcdb979bdb91ea097abb3dd2c23c9 upstream. This reverts commit 068500e08dc87ea9a453cc4a500cf3ab28d0f936. According to some tests, SDMA support is broken at least for i.MX6 without HW flow control. Different forms of data-corruption appear either with the ROM firmware for the SDMA controller as well as when loading Freescale provided SDMA firmware versions 1.1 or 3.1. Signed-off-by: David Jander Signed-off-by: Greg Kroah-Hartman commit 6cf671f37e11f4b1b32f6cb2c6094dd923bcce4f Author: Oliver Neukum Date: Mon Jul 6 13:12:32 2015 +0200 usb-storage: ignore ZTE MF 823 card reader in mode 0x1225 commit 5fb2c782f451a4fb9c19c076e2c442839faf0f76 upstream. This device automatically switches itself to another mode (0x1405) unless the specific access pattern of Windows is followed in its initial mode. That makes a dirty unmount of the internal storage devices inevitable if they are mounted. So the card reader of such a device should be ignored, lest an unclean removal become inevitable. This replaces an earlier patch that ignored all LUNs of this device. That patch was overly broad. Signed-off-by: Oliver Neukum Reviewed-by: Lars Melin Signed-off-by: Greg Kroah-Hartman commit 33f293b92e35ae208aefccdca05bcc268e03e4d2 Author: Lior Amsalem Date: Tue Jun 30 16:09:49 2015 +0200 ata: pmp: add quirk for Marvell 4140 SATA PMP commit 945b47441d83d2392ac9f984e0267ad521f24268 upstream. This commit adds the necessary quirk to make the Marvell 4140 SATA PMP work properly. This PMP doesn't like SRST on port number 4 (the host port) so this commit marks this port as not supporting SRST. Signed-off-by: Lior Amsalem Reviewed-by: Nadav Haklai Signed-off-by: Thomas Petazzoni Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit e4cadcc1c4595b336d7f9f9b1fb51c5afdf9a6f5 Author: Krzysztof Kozlowski Date: Wed Jun 24 19:48:43 2015 +0900 regulator: s2mps11: Fix GPIO suspend enable shift wrapping bug commit 32c848e33ace75fce388cceff76223d12b46eaa3 upstream. Status of enabling suspend mode for regulator was stored in bitmap-like long integer. However since adding support for S2MPU02 the number of regulators exceeded 32 so on devices with more than 32 regulators (S2MPU02 and S2MPS13) overflow happens when shifting the bit. This could lead to enabling suspend mode for completely different regulator than intended or to switching different regulator to other mode (e.g. from always enabled to controlled by PWRHOLD pin). Both cases could result in larger energy usage and issues when suspending to RAM. Fixes: 00e2573d2c10 ("regulator: s2mps11: Add support S2MPU02 regulator device") Reported-by: Dan Carpenter Signed-off-by: Krzysztof Kozlowski Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1fbb15f220a6740327764b3775566771a4746fe6 Author: Tejun Heo Date: Wed Jul 22 18:05:53 2015 -0400 blkcg: fix gendisk reference leak in blkg_conf_prep() commit 5f6c2d2b7dbb541c1e922538c49fa04c494ae3d7 upstream. When a blkcg configuration is targeted to a partition rather than a whole device, blkg_conf_prep fails with -EINVAL; unfortunately, it forgets to put the gendisk ref in that case. Fix it. Signed-off-by: Tejun Heo Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 106c930a30784cb783b8ad9d4e685fd1d0c0cbe7 Author: Bernhard Bender Date: Thu Jul 23 13:58:08 2015 -0700 Input: usbtouchscreen - avoid unresponsive TSC-30 touch screen commit 968491709e5b1aaf429428814fff3d932fa90b60 upstream. This patch fixes a problem in the usbtouchscreen driver for DMC TSC-30 touch screen. Due to a missing delay between the RESET and SET_RATE commands, the touch screen may become unresponsive during system startup or driver loading. According to the DMC documentation, a delay is needed after the RESET command to allow the chip to complete its internal initialization. As this delay is not guaranteed, we had a system where the touch screen occasionally did not send any touch data. There was no other indication of the problem. The patch fixes the problem by adding a 150ms delay between the RESET and SET_RATE commands. Suggested-by: Jakob Mustafa Signed-off-by: Bernhard Bender Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit bec2057fee79fe271a629c98feb2201faba4ff2c Author: Chris Metcalf Date: Thu Jul 23 14:11:09 2015 -0400 tile: use free_bootmem_late() for initrd commit 3f81d2447b37ac697b3c600039f2c6b628c06e21 upstream. We were previously using free_bootmem() and just getting lucky that nothing too bad happened. Signed-off-by: Chris Metcalf Signed-off-by: Greg Kroah-Hartman commit 56e8479a04db9085278e17e0eac594927d327c5d Author: Sascha Hauer Date: Fri Jul 24 15:01:08 2015 +0200 spi: imx: Fix small DMA transfers commit f6ee9b582d2db652497b73c1f117591dfb6d3a90 upstream. DMA transfers must be greater than the watermark level size. spi_imx->rx_wml and spi_imx->tx_wml contain the watermark level in 32bit words whereas struct spi_transfer contains the transfer len in bytes. Fix the check if DMA is possible for a transfer accordingly. This fixes transfers with sizes between 33 and 128 bytes for which previously was claimed that DMA is possible. Fixes: f62caccd12c17e4 (spi: spi-imx: add DMA support) Signed-off-by: Sascha Hauer Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 19ea7491d0b3555c333ceacaf489c51fa3d6e89e Author: Sifan Naeem Date: Thu Jun 18 13:50:54 2015 +0100 spi: img-spfi: fix support for speeds up to 1/4th input clock commit 6a806a214af42ac951e2d85e64d1bf4463482e16 upstream. Setting the Same Edge bit indicates to the spfi block to receive and transmit data on the same edge of the spfi clock, which in turn doubles the operating frequency of spfi. The maximum supported frequency is limited to 1/4th of the spfi input clock, but without this bit set the maximum would be 1/8th of the input clock. The current driver calculates the divisor with maximum speed at 1/4th of the input clock, this would fail if the requested frequency is higher than 1/8 of the input clock. Any requests for 1/8th of the input clock would still pass. Fixes: 8543d0e72d43 ("spi: img-spfi: Limit bit clock to 1/4th of input clock") Signed-off-by: Sifan Naeem Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4731b65de6b30b7a8e771c51e4fb4a53846f158e Author: NeilBrown Date: Fri Jul 24 09:22:16 2015 +1000 md/raid1: fix test for 'was read error from last working device'. commit 34cab6f42003cb06f48f86a86652984dec338ae9 upstream. When we get a read error from the last working device, we don't try to repair it, and don't fail the device. We simple report a read error to the caller. However the current test for 'is this the last working device' is wrong. When there is only one fully working device, it assumes that a non-faulty device is that device. However a spare which is rebuilding would be non-faulty but so not the only working device. So change the test from "!Faulty" to "In_sync". If ->degraded says there is only one fully working device and this device is in_sync, this must be the one. This bug has existed since we allowed read_balance to read from a recovering spare in v3.0 Reported-and-tested-by: Alexander Lyakas Fixes: 76073054c95b ("md/raid1: clean up read_balance.") Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 5c5aba569ebf67a8bad4bf258af4111e42101654 Author: Emmanuel Grumbach Date: Thu Jun 4 11:09:47 2015 +0300 iwlwifi: pcie: prepare the device before accessing it commit f9e5554cd8ca1d1212ec922755b397a20f737923 upstream. For 8000 series, we need to access the device to know what firmware to load. Before we do so, we need to prepare the device otherwise we might not be able to access the hardware. Fixes: c278754a21e6 ("iwlwifi: mvm: support family 8000 B2/C steps") Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit a8bc0fe729d868ffec8a1050925da446da32a01e Author: Liad Kaufman Date: Wed Jul 1 17:28:34 2015 +0300 iwlwifi: nvm: remove mac address byte swapping in 8000 family commit be88a1ada9b97bb016196b7f4a1fc2fe2f798529 upstream. This fixes the byte order copying in the MAO (Mac Override Section) section from the PNVM, as the byte swapping is not required anymore in the 8000 family. Due to the byte swapping, the driver was reporting an incorrect MAC adddress. Signed-off-by: Liad Kaufman Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit bed0400e01d7ade4be054c909817fd1d3a591012 Author: Emmanuel Grumbach Date: Sun May 31 21:44:22 2015 +0300 iwlwifi: mvm: fix antenna selection when BT is active commit 923a8c1d8069104726bde55c37cec66324ccc328 upstream. When BT is active, we want to avoid the shared antenna for management frame to make sure we don't disturb BT. There was a bug in that code because it chose the antenna BIT(ANT_A) where ANT_A is already a bitmap (0x1). This means that the antenna chosen in the end was ANT_B. While this is not optimal on devices with 2 antennas (it'd disturb BT), it is critical on single antenna devices like 3160 which couldn't connect at all when BT was active. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=97181 Fixes: 34c8b24ff284 ("iwlwifi: mvm: BT Coex - avoid the shared antenna for management frames") Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 103c46c95b48b228c98a8751726ab3bd9e90b525 Author: Antonio Borneo Date: Sun Jun 21 14:20:25 2015 +0800 HID: cp2112: fix to force single data-report reply commit 6debce6f4e787a8eb4cec94e7afa85fb4f40db27 upstream. Current implementation of cp2112_raw_event() only accepts one data report at a time. If last received data report is not fully handled yet, a new incoming data report will overwrite it. In such case we don't guaranteed to propagate the correct incoming data. The trivial fix implemented here forces a single report at a time by requesting in cp2112_read() no more than 61 byte of data, which is the payload size of a single data report. Signed-off-by: Antonio Borneo Tested-by: Ellen Wang Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 5ca991392ffc8fb1aaff9008fb3a2471ce578120 Author: Jingju Hou Date: Thu Jul 23 17:56:23 2015 +0800 mmc: sdhci-pxav3: fix platform_data is not initialized commit 9cd76049f0d90ae241f5ad80e311489824527000 upstream. pdev->dev.platform_data is not initialized if match is true in function sdhci_pxav3_probe. Just local variable pdata is assigned the return value from function pxav3_get_mmc_pdata(). static int sdhci_pxav3_probe(struct platform_device *pdev) { struct sdhci_pxa_platdata *pdata = pdev->dev.platform_data; ... if (match) { ret = mmc_of_parse(host->mmc); if (ret) goto err_of_parse; sdhci_get_of_property(pdev); pdata = pxav3_get_mmc_pdata(dev); } ... } Signed-off-by: Jingju Hou Fixes: b650352dd3df("mmc: sdhci-pxa: Add device tree support") Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit a53ccf3cfe09ff026dd0d38a4211bf5766743ba3 Author: Joakim Tjernlund Date: Wed Jul 22 16:44:26 2015 +0200 mmc: sdhci-esdhc: Make 8BIT bus work commit 8e91125ff3f57f15c6568e2a6d32743b3f7815e4 upstream. Support for 8BIT bus with was added some time ago to sdhci-esdhc but then missed to remove the 8BIT from the reserved bit mask which made 8BIT non functional. Fixes: 66b50a00992d ("mmc: esdhc: Add support for 8-bit bus width and..") Signed-off-by: Joakim Tjernlund Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 7a64ba1a070e33af42f21811886497ee33030670 Author: Peng Fan Date: Mon Jun 22 11:41:23 2015 +0800 mmc: sdhci check parameters before call dma_free_coherent commit 7ac020366b0a436d726408841160b5dc32c19214 upstream. We should not call dma_free_coherent if host->adma_table is NULL, otherwise may trigger panic. Fixes: d1e49f77d7c7 ("mmc: sdhci: convert ADMA descriptors to a...") Signed-off-by: Peng Fan Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 2ebb372240adabb59cc2671e64a85c2cc6f803b8 Author: Kishon Vijay Abraham I Date: Tue Jun 16 16:07:17 2015 +0530 mmc: omap_hsmmc: Fix DTO and DCRC handling commit 408806f740497c5d71f9c305b3d6aad260ff186d upstream. DTO/DCRC errors were not being informed to the mmc core since commit ae4bf788ee9b ("mmc: omap_hsmmc: consolidate error report handling of HSMMC IRQ"). This commit made sure 'end_trans' is never set on DTO/DCRC errors. This is because after this commit 'host->data' is checked after it has been cleared to NULL by omap_hsmmc_dma_cleanup(). Because 'end_trans' is never set, omap_hsmmc_xfer_done() is never invoked making core layer not to be aware of DTO/DCRC errors. Because of this any command invoked after DTO/DCRC error leads to a hang. Fix this by checking for 'host->data' before it is actually cleared. Fixes: ae4bf788ee9b ("mmc: omap_hsmmc: consolidate error report handling of HSMMC IRQ") Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Vignesh R Tested-by: Andreas Fenkart Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 6cbebdadb406e308d845c0b88d79fe3e2275760d Author: Alex Williamson Date: Tue Jul 14 14:48:53 2015 -0600 iommu/vt-d: Fix VM domain ID leak commit 46ebb7af7b93792de65e124e1ab8b89a108a41f2 upstream. This continues the attempt to fix commit fb170fb4c548 ("iommu/vt-d: Introduce helper functions to make code symmetric for readability"). The previous attempt in commit 71684406905f ("iommu/vt-d: Detach domain *only* from attached iommus") overlooked the fact that dmar_domain.iommu_bmp gets cleared for VM domains when devices are detached: intel_iommu_detach_device domain_remove_one_dev_info domain_detach_iommu The domain is detached from the iommu, but the iommu is still attached to the domain, for whatever reason. Thus when we get to domain_exit(), we can't rely on iommu_bmp for VM domains to find the active iommus, we must check them all. Without that, the corresponding bit in intel_iommu.domain_ids doesn't get cleared and repeated VM domain creation and destruction will run out of domain IDs. Meanwhile we still can't call iommu_detach_domain() on arbitrary non-VM domains or we risk clearing in-use domain IDs, as 71684406905f attempted to address. It's tempting to modify iommu_detach_domain() to test the domain iommu_bmp, but the call ordering from domain_remove_one_dev_info() prevents it being able to work as fb170fb4c548 seems to have intended. Caching of unused VM domains on the iommu object seems to be the root of the problem, but this code is far too fragile for that kind of rework to be proposed for stable, so we simply revert this chunk to its state prior to fb170fb4c548. Fixes: fb170fb4c548 ("iommu/vt-d: Introduce helper functions to make code symmetric for readability") Fixes: 71684406905f ("iommu/vt-d: Detach domain *only* from attached iommus") Signed-off-by: Alex Williamson Cc: Jiang Liu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 23713b4de718469da486aca7f27d8983b60d7622 Author: Steven Rostedt (Red Hat) Date: Fri Jul 24 10:38:12 2015 -0400 ftrace: Fix breakage of set_ftrace_pid commit e3eea1404f5ff7a2ceb7b5e7ba412a6fd94f2935 upstream. Commit 4104d326b670 ("ftrace: Remove global function list and call function directly") simplified the ftrace code by removing the global_ops list with a new design. But this cleanup also broke the filtering of PIDs that are added to the set_ftrace_pid file. Add back the proper hooks to have pid filtering working once again. Reported-by: Matt Fleming Reported-by: Richard Weinberger Tested-by: Matt Fleming Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 3af9ac3e2251ef2424bc4745fa27458bf134da3c Author: Eric W. Biederman Date: Fri Jul 17 14:54:27 2015 -0500 mnt: In detach_mounts detach the appropriate unmounted mount commit fe78fcc85a2046c51f1535710996860557eeec20 upstream. The handling of in detach_mounts of unmounted but connected mounts is buggy and can lead to an infinite loop. Correct the handling of unmounted mounts in detach_mount. When the mountpoint of an unmounted but connected mount is connected to a dentry, and that dentry is deleted we need to disconnect that mount from the parent mount and the deleted dentry. Nothing changes for the unmounted and connected children. They can be safely ignored. Fixes: ce07d891a0891d3c0d0c2d73d577490486b809e1 mnt: Honor MNT_LOCKED when detaching mounts Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 4647b34f1a3b08b70f8e20436c7dbec721d47f35 Author: Eric W. Biederman Date: Fri Jul 17 14:15:30 2015 -0500 mnt: Clarify and correct the disconnect logic in umount_tree commit f2d0a123bcf16d1a9cf7942ddc98e0ef77862c2b upstream. rmdir mntpoint will result in an infinite loop when there is a mount locked on the mountpoint in another mount namespace. This is because the logic to test to see if a mount should be disconnected in umount_tree is buggy. Move the logic to decide if a mount should remain connected to it's mountpoint into it's own function disconnect_mount so that clarity of expression instead of terseness of expression becomes a virtue. When the conditions where it is invalid to leave a mount connected are first ruled out, the logic for deciding if a mount should be disconnected becomes much clearer and simpler. Fixes: e0c9c0afd2fc958ffa34b697972721d81df8a56f mnt: Update detach_mounts to leave mounts connected Fixes: ce07d891a0891d3c0d0c2d73d577490486b809e1 mnt: Honor MNT_LOCKED when detaching mounts Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 59366187ef6725cf9c37aec5dd2e6c80aa05a24a Author: Uwe Kleine-König Date: Fri Jul 17 09:38:43 2015 +0200 Subject: pinctrl: imx1-core: Fix debug output in .pin_config_set callback commit 9571b25df1dbf4db17191b54f59734e8b77fd591 upstream. imx1_pinconf_set assumes that the array of pins in struct imx1_pinctrl_soc_info can be indexed by pin id to get the pinctrl_pin_desc for a pin. This used to be correct up to commit 607af165c047 which removed some entries from the array and so made it wrong to access the array by pin id. The result of this bug is a wrong pin name in the output for small pin ids and an oops for the bigger ones. This patch is the result of a discussion that includes patches by Markus Pargmann and Chris Ruehl. Fixes: 607af165c047 ("pinctrl: i.MX27: Remove nonexistent pad definitions") Reported-by: Chris Ruehl Signed-off-by: Uwe Kleine-König Reviewed-by: Markus Pargmann Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 848bd661126da2386b526d3dd0193b6564a2731d Author: Tom Hughes Date: Mon Jun 29 19:41:49 2015 +0100 mac80211: clear subdir_stations when removing debugfs commit 4479004e6409087d1b4986881dc98c6c15dffb28 upstream. If we don't do this, and we then fail to recreate the debugfs directory during a mode change, then we will fail later trying to add stations to this now bogus directory: BUG: unable to handle kernel NULL pointer dereference at 0000006c IP: [] mutex_lock+0x12/0x30 Call Trace: [] start_creating+0x44/0xc0 [] debugfs_create_dir+0x13/0xf0 [] ieee80211_sta_debugfs_add+0x6e/0x490 [mac80211] Signed-off-by: Tom Hughes Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 8cc9a81362527fcd4a7249cbec8feb244b83772a Author: Pankaj Dev Date: Tue Jul 7 09:40:50 2015 +0200 drivers: clk: st: Incorrect register offset used for lock_status commit 56551da9255f20ffd3a9711728a1a3ad4b7100af upstream. Incorrect register offset used for sthi407 clockgenC Signed-off-by: Pankaj Dev Signed-off-by: Gabriel Fernandez Fixes: 51306d56ba81 ("clk: st: STiH407: Support for clockgenC0") Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 679125858bcf81b47a21e10cdcf769c66f8831d7 Author: Gabriel Fernandez Date: Tue Jun 23 16:09:25 2015 +0200 drivers: clk: st: Fix mux bit-setting for Cortex A9 clocks commit 3be6d8ce639d92e60d144fb99dd74a53fe3799bb upstream. This patch fixes the mux bit-setting for ClockgenA9. Signed-off-by: Gabriel Fernandez Fixes: 13e6f2da1ddf ("clk: st: STiH407: Support for A9 MUX Clocks") Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit b7a843d6c3063389a83d3260d6ee53bafdb39ec3 Author: Giuseppe Cavallaro Date: Tue Jun 23 16:09:23 2015 +0200 drivers: clk: st: Fix flexgen lock init commit 0f4f2afd4402883a51ad27a1d9e046643bb1e3cb upstream. While proving lock, the following warning happens and it is fixed after initializing lock in the setup function INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.27-02861-g39df285-dirty #33 [] (unwind_backtrace+0x0/0xf4) from [] (show_stack+0x10/0x14) [] (show_stack+0x10/0x14) from [] (__lock_acquire+0x900/0xb14) [] (__lock_acquire+0x900/0xb14) from [] (lock_acquire+0x68/0x7c) [] (lock_acquire+0x68/0x7c) from [] (_raw_spin_lock_irqsave+0x48/0x5c) [] (_raw_spin_lock_irqsave+0x48/0x5c) from [] (clk_gate_endisable+0x28/0x88) [] (clk_gate_endisable+0x28/0x88) from [] (clk_gate_enable+0xc/0x14) [] (clk_gate_enable+0xc/0x14) from [] (flexgen_enable+0x28/0x40) [] (flexgen_enable+0x28/0x40) from [] (__clk_enable+0x5c/0x9c) [] (__clk_enable+0x5c/0x9c) from [] (clk_enable+0x18/0x2c) [] (clk_enable+0x18/0x2c) from [] (st_lpc_of_register+0xc0/0x248) [] (st_lpc_of_register+0xc0/0x248) from [] (clocksource_of_init+0x34/0x58) [] (clocksource_of_init+0x34/0x58) from [] (sti_timer_init+0x10/0x18) [] (sti_timer_init+0x10/0x18) from [] (time_init+0x20/0x30) [] (time_init+0x20/0x30) from [] (start_kernel+0x20c/0x2e8) [] (start_kernel+0x20c/0x2e8) from [<40008074>] (0x40008074) Signed-off-by: Giuseppe Cavallaro Signed-off-by: Gabriel Fernandez Fixes: b116517055b7 ("clk: st: STiH407: Support for Flexgen Clocks") Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 785807850c4b58522e37efaae4c9329be01aaa46 Author: Seymour, Shane M Date: Thu Jul 2 12:01:10 2015 +0000 st: null pointer dereference panic caused by use after kref_put by st_open commit e7ac6c6666bec0a354758a1298d3231e4a635362 upstream. Two SLES11 SP3 servers encountered similar crashes simultaneously following some kind of SAN/tape target issue: ... qla2xxx [0000:81:00.0]-801c:3: Abort command issued nexus=3:0:2 -- 1 2002. qla2xxx [0000:81:00.0]-801c:3: Abort command issued nexus=3:0:2 -- 1 2002. qla2xxx [0000:81:00.0]-8009:3: DEVICE RESET ISSUED nexus=3:0:2 cmd=ffff882f89c2c7c0. qla2xxx [0000:81:00.0]-800c:3: do_reset failed for cmd=ffff882f89c2c7c0. qla2xxx [0000:81:00.0]-800f:3: DEVICE RESET FAILED: Task management failed nexus=3:0:2 cmd=ffff882f89c2c7c0. qla2xxx [0000:81:00.0]-8009:3: TARGET RESET ISSUED nexus=3:0:2 cmd=ffff882f89c2c7c0. qla2xxx [0000:81:00.0]-800c:3: do_reset failed for cmd=ffff882f89c2c7c0. qla2xxx [0000:81:00.0]-800f:3: TARGET RESET FAILED: Task management failed nexus=3:0:2 cmd=ffff882f89c2c7c0. qla2xxx [0000:81:00.0]-8012:3: BUS RESET ISSUED nexus=3:0:2. qla2xxx [0000:81:00.0]-802b:3: BUS RESET SUCCEEDED nexus=3:0:2. qla2xxx [0000:81:00.0]-505f:3: Link is operational (8 Gbps). qla2xxx [0000:81:00.0]-8018:3: ADAPTER RESET ISSUED nexus=3:0:2. qla2xxx [0000:81:00.0]-00af:3: Performing ISP error recovery - ha=ffff88bf04d18000. rport-3:0-0: blocked FC remote port time out: removing target and saving binding qla2xxx [0000:81:00.0]-505f:3: Link is operational (8 Gbps). qla2xxx [0000:81:00.0]-8017:3: ADAPTER RESET SUCCEEDED nexus=3:0:2. rport-2:0-0: blocked FC remote port time out: removing target and saving binding sg_rq_end_io: device detached BUG: unable to handle kernel NULL pointer dereference at 00000000000002a8 IP: [] __pm_runtime_idle+0x28/0x90 PGD 7e6586f067 PUD 7e5af06067 PMD 0 [1739975.390354] Oops: 0002 [#1] SMP CPU 0 ... Supported: No, Proprietary modules are loaded [1739975.390463] Pid: 27965, comm: ABCD Tainted: PF X 3.0.101-0.29-default #1 HP ProLiant DL580 Gen8 RIP: 0010:[] [] __pm_runtime_idle+0x28/0x90 RSP: 0018:ffff8839dc1e7c68 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff883f0592fc00 RCX: 0000000000000090 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000138 RBP: 0000000000000138 R08: 0000000000000010 R09: ffffffff81bd39d0 R10: 00000000000009c0 R11: ffffffff81025790 R12: 0000000000000001 R13: ffff883022212b80 R14: 0000000000000004 R15: ffff883022212b80 FS: 00007f8e54560720(0000) GS:ffff88407f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00000000000002a8 CR3: 0000007e6ced6000 CR4: 00000000001407f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ABCD (pid: 27965, threadinfo ffff8839dc1e6000, task ffff883592e0c640) Stack: ffff883f0592fc00 00000000fffffffa 0000000000000001 ffff883022212b80 ffff883eff772400 ffffffffa03fa309 0000000000000000 0000000000000000 ffffffffa04003a0 ffff883f063196c0 ffff887f0379a930 ffffffff8115ea1e Call Trace: [] st_open+0x129/0x240 [st] [] chrdev_open+0x13e/0x200 [] __dentry_open+0x198/0x310 [] do_last+0x1f4/0x800 [] path_openat+0xd9/0x420 [] do_filp_open+0x4c/0xc0 [] do_sys_open+0x17f/0x250 [] system_call_fastpath+0x16/0x1b [<00007f8e4f617fd0>] 0x7f8e4f617fcf Code: eb d3 90 48 83 ec 28 40 f6 c6 04 48 89 6c 24 08 4c 89 74 24 20 48 89 fd 48 89 1c 24 4c 89 64 24 10 41 89 f6 4c 89 6c 24 18 74 11 ff 8f 70 01 00 00 0f 94 c0 45 31 ed 84 c0 74 2b 4c 8d a5 a0 RIP [] __pm_runtime_idle+0x28/0x90 RSP CR2: 00000000000002a8 Analysis reveals the cause of the crash to be due to STp->device being NULL. The pointer was NULLed via scsi_tape_put(STp) when it calls scsi_tape_release(). In st_open() we jump to err_out after scsi_block_when_processing_errors() completes and returns the device as offline (sdev_state was SDEV_DEL): 1180 /* Open the device. Needs to take the BKL only because of incrementing the SCSI host 1181 module count. */ 1182 static int st_open(struct inode *inode, struct file *filp) 1183 { 1184 int i, retval = (-EIO); 1185 int resumed = 0; 1186 struct scsi_tape *STp; 1187 struct st_partstat *STps; 1188 int dev = TAPE_NR(inode); 1189 char *name; ... 1217 if (scsi_autopm_get_device(STp->device) < 0) { 1218 retval = -EIO; 1219 goto err_out; 1220 } 1221 resumed = 1; 1222 if (!scsi_block_when_processing_errors(STp->device)) { 1223 retval = (-ENXIO); 1224 goto err_out; 1225 } ... 1264 err_out: 1265 normalize_buffer(STp->buffer); 1266 spin_lock(&st_use_lock); 1267 STp->in_use = 0; 1268 spin_unlock(&st_use_lock); 1269 scsi_tape_put(STp); <-- STp->device = 0 after this 1270 if (resumed) 1271 scsi_autopm_put_device(STp->device); 1272 return retval; The ref count for the struct scsi_tape had already been reduced to 1 when the .remove method of the st module had been called. The kref_put() in scsi_tape_put() caused scsi_tape_release() to be called: 0266 static void scsi_tape_put(struct scsi_tape *STp) 0267 { 0268 struct scsi_device *sdev = STp->device; 0269 0270 mutex_lock(&st_ref_mutex); 0271 kref_put(&STp->kref, scsi_tape_release); <-- calls this 0272 scsi_device_put(sdev); 0273 mutex_unlock(&st_ref_mutex); 0274 } In scsi_tape_release() the struct scsi_device in the struct scsi_tape gets set to NULL: 4273 static void scsi_tape_release(struct kref *kref) 4274 { 4275 struct scsi_tape *tpnt = to_scsi_tape(kref); 4276 struct gendisk *disk = tpnt->disk; 4277 4278 tpnt->device = NULL; <<<---- where the dev is nulled 4279 4280 if (tpnt->buffer) { 4281 normalize_buffer(tpnt->buffer); 4282 kfree(tpnt->buffer->reserved_pages); 4283 kfree(tpnt->buffer); 4284 } 4285 4286 disk->private_data = NULL; 4287 put_disk(disk); 4288 kfree(tpnt); 4289 return; 4290 } Although the problem was reported on SLES11.3 the problem appears in linux-next as well. The crash is fixed by reordering the code so we no longer access the struct scsi_tape after the kref_put() is done on it in st_open(). Signed-off-by: Shane Seymour Signed-off-by: Darren Lavender Reviewed-by: Johannes Thumshirn Acked-by: Kai Mäkisara Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit cb6fd3e6f10bd6c73075dd9a8826e74ed6fffacf Author: Tony Battersby Date: Thu Jul 16 11:40:41 2015 -0400 scsi: fix memory leak with scsi-mq commit 0c958ecc69c277b25f38f72bc6d18ab145e8167c upstream. Fix a memory leak with scsi-mq triggered by commands with large data transfer length. __sg_alloc_table() sets both table->nents and table->orig_nents to the same value. When the scatterlist is DMA-mapped, table->nents is overwritten with the (possibly smaller) size of the DMA-mapped scatterlist, while table->orig_nents retains the original size of the allocated scatterlist. scsi_free_sgtable() should therefore check orig_nents instead of nents, and all code that initializes sdb->table without calling __sg_alloc_table() should set both nents and orig_nents. Fixes: d285203cf647 ("scsi: add support for a blk-mq based I/O path.") Signed-off-by: Tony Battersby Reviewed-by: Christoph Hellwig Reviewed-by: Ewan D. Milne Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit a77aa615ba7c4d7511993ecf4278bd604da49991 Author: Jens Axboe Date: Mon Jul 13 08:24:39 2015 -0600 scsi: fix host max depth checking for the 'queue_depth' sysfs interface commit 1278dd6809b11dc298e19d81ac0916275f7318c1 upstream. Commit 1e6f2416044c0 changed the scsi sysfs 'queue_depth' code to rejects depths higher than the scsi host template setting. But lots of hosts set this to 1, and update the settings in the scsi host when the controller/devices probing happens. This breaks (at least) mpt2sas and mpt3sas runtime setting of queue depth, returning EINVAL for all settings but '1'. And once it's set to 1, there's no way to go back up. Fixes: 1e6f2416044c0 "scsi: don't allow setting of queue_depth bigger than can_queue" Signed-off-by: Jens Axboe Reviewed-by: Martin K. Petersen Reviewed-by: Christoph Hellwig Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit dc59806d397a10f8a7c838f3de4fe0185d4299a3 Author: Marc Zyngier Date: Fri Jul 17 10:46:42 2015 +0100 irqchip/gicv3-its: Fix mapping of LPIs to collections commit 591e5bec13f15feb13fc445b6c9c59954711c4ac upstream. The GICv3 ITS architecture allows a given [DevID, EventID] pair to be translated to a [LPI, Collection] pair, where DevID is the device writing the MSI, EventID is the payload being written, LPI is the actual interrupt number, and Collection is roughly equivalent to a target CPU. Each LPI can be mapped to a separate collection, but the ITS driver insists on maintaining the collection on a device basis, instead of doing it on a per interrupt basis. This is obviously flawed, and this patch fixes it by adding a per interrupt index that indicates which collection number is in use. Reported-by: Ian Campbell Signed-off-by: Marc Zyngier Cc: Cc: Jason Cooper Link: http://lkml.kernel.org/r/1437126402-11677-1-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 9bf9f8b09de63b57c39968491ae9301b8114a43d Author: Mike Snitzer Date: Wed Jul 8 16:08:24 2015 -0400 Revert "dm: only run the queue on completion if congested or no requests pending" commit 621739b00e16ca2d80411dc9b111cb15b91f3ba9 upstream. This reverts commit 9a0e609e3fd8a95c96629b9fbde6b8c5b9a1456a. (Resolved a conflict during revert due to commit bfebd1cdb4 that came after) This revert is motivated by a couple failure reports on request-based DM multipath testbeds: 1) Netapp reported that their multipath fault injection test under heavy IO load can stall longer than 300 seconds. 2) IBM reported elevated lock contention in their testbed (likely due to increased back pressure due to IO not being dispatched as quickly): https://www.redhat.com/archives/dm-devel/2015-July/msg00057.html Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 68b9e67311ca10a0bdce6ab2939ca0ff3ebac91b Author: Peter Zijlstra Date: Thu Jul 9 19:23:38 2015 +0200 x86, perf: Fix static_key bug in load_mm_cr4() commit a833581e372a4adae2319d8dc379493edbc444e9 upstream. Mikulas reported his K6-3 not booting. This is because the static_key API confusion struck and bit Andy, this wants to be static_key_false(). Reported-by: Mikulas Patocka Tested-by: Mikulas Patocka Signed-off-by: Peter Zijlstra (Intel) Cc: Andrea Arcangeli Cc: Andy Lutomirski Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Valdis Kletnieks Cc: Vince Weaver Cc: hillf.zj Fixes: a66734297f78 ("perf/x86: Add /sys/devices/cpu/rdpmc=2 to allow rdpmc for all tasks") Link: http://lkml.kernel.org/r/20150709172338.GC19282@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit dbd7bf9912e6635fe2dbbcb927aecf179afab630 Author: Takashi Iwai Date: Thu Jul 30 22:30:29 2015 +0200 ALSA: hda - Fix MacBook Pro 5,2 quirk commit 649ccd08534ee26deb2e5b08509800d0e95167f5 upstream. MacBook Pro 5,2 with ALC889 codec had already a fixup entry, but this seems not working correctly, a fix for pin NID 0x15 is needed in addition. It's equivalent with the fixup for MacBook Air 1,1, so use this instead. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=102131 Reported-and-tested-by: Jeffery Miller Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 574169a14b5cafe227a41f7a9d9bdf6acaacaae7 Author: Yao-Wen Mao Date: Wed Jul 29 15:13:54 2015 +0800 ALSA: usb-audio: add dB range mapping for some devices commit 2d1cb7f658fb9c3ba8f9dab8aca297d4dfdec835 upstream. Add the correct dB ranges of Bose Companion 5 and Drangonfly DAC 1.2. Signed-off-by: Yao-Wen Mao Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1484f6f9ad42a4acd6755ae2bad5ee75f88bd3cc Author: Takashi Iwai Date: Wed Jul 29 09:04:52 2015 +0200 ALSA: hda - Apply a fixup to Dell Vostro 5480 commit 3a05d12f46cb95a6a685114819363a56e6170996 upstream. Dell Vostro 5480 (1028:069a) needs the very same quirk used for Vostro 5470 model to make bass speakers properly working. Reported-and-tested-by: Paulo Roberto de Oliveira Castro Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 96b9b980c78785631a281c73b3fb3939382b9d26 Author: Takashi Iwai Date: Mon Jul 27 10:13:37 2015 +0200 ALSA: hda - Apply fixup for another Toshiba Satellite S50D commit b9d9c9efc292dd0ffe172780f915ed74eba3556c upstream. Toshiba Satellite S50D has another model with a different PCI SSID (1179:fa93) while the previous fixup was for 1179:fa91. Adjust the fixup entry with SND_PCI_QUIRK_MASK() to match with both devices. Reported-by: Tim Sample Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d1456c439644a6ba93245546e8c2613b0bdef990 Author: David Henningsson Date: Wed Jul 22 10:00:25 2015 +0200 ALSA: hda - Add headset mic pin quirk for a Dell device commit cba59972a1191a0c1647a52fe745eed7a4b34b38 upstream. Without this patch, the headset mic will not work on this machine. BugLink: https://bugs.launchpad.net/bugs/1476987 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e40f560b7faaa362f7c72bc40dde20630d9eab33 Author: Aaron Plattner Date: Mon Jul 20 17:14:14 2015 -0700 ALSA: hda - Add new GPU codec ID 0x10de007d to snd-hda commit 6c3d91193d829bf58a35a10650415b05a736ca6c upstream. Vendor ID 0x10de007d is used by a yet-to-be-named GPU chip. This chip also has the 2-ch audio swapping bug, so patch_nvhdmi is appropriate here. Signed-off-by: Aaron Plattner Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e7e08353d3e6d02d5fb1ae7f7cba775e31bbb478 Author: Maruthi Srinivas Bayyavarapu Date: Mon Jul 20 19:56:18 2015 +0530 ALSA: hda: add new AMD PCI IDs with proper driver caps commit 5022813ddb28b7679e8285812d52aaeb7e1e7657 upstream. Fixes audio problems on newer asics Signed-off-by: Maruthi Bayyavarapu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 291603b69df0e25f48bacdeeb3e4d2f041cf23f0 Author: Mateusz Sylwestrzak Date: Sun Jul 19 17:38:56 2015 +0200 ALSA: hda - Add headset mic support for Acer Aspire V5-573G commit 0420694dddeb9e269a1ab2129a0119a5cea294a4 upstream. Acer Aspire V5 with the ALC282 codec is given the wrong value for the 0x19 PIN by the laptop's BIOS. Overriding it with the correct value adds support for the headset microphone which would not otherwise be visible in the system. The fix is based on commit 7819717b1134 with a similar quirk for Acer Aspire with the ALC269 codec. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96201 Signed-off-by: Mateusz Sylwestrzak Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 898dbc106e50ab6de4106e2415d0f40e260903c4 Author: Takashi Iwai Date: Fri Jul 17 15:22:33 2015 +0200 ALSA: pcm: Fix lockdep warning with nonatomic PCM ops commit 67756e3191c90e7c0b94b8b2fb63de255b6cd337 upstream. With the nonatomic PCM ops, the system may spew lockdep warnings like: ============================================= [ INFO: possible recursive locking detected ] 4.2.0-rc1-jeejaval3 #12 Not tainted --------------------------------------------- aplay/4029 is trying to acquire lock: (snd_pcm_link_rwsem){.+.+.+}, at: [] snd_pcm_stream_lock+0x43/0x60 but task is already holding lock: (snd_pcm_link_rwsem){.+.+.+}, at: [] snd_pcm_action_nonatomic+0x29/0x80 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(snd_pcm_link_rwsem); lock(snd_pcm_link_rwsem); Although this is false-positive as the rwsem is taken always as read-only for these code paths, it's certainly annoying to see this at any occasion. A simple fix is to use down_read_nested() in snd_pcm_stream_lock() that can be called inside another lock. Reported-by: Vinod Koul Reported-by: Jeeja Kp Tested-by: Jeeja Kp Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2b16e01ae6b5c0c5e1f382fcad51a3053270374a Author: Takashi Iwai Date: Tue Jul 14 15:19:37 2015 +0200 ALSA: line6: Fix -EBUSY error during active monitoring commit 4d0e677523a999e1dec28e55cc314c47ba09ca12 upstream. When a monitor stream is active, the next PCM stream access results in EBUSY error because of the check in line6_stream_start(). Fix this by just skipping the submission of pending URBs when the stream is already running instead. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101431 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d1374d7f4f70867f7d0a7b4a89be086a143e5cdd Author: Dominic Sacré Date: Tue Jun 30 17:41:33 2015 +0200 ALSA: usb-audio: Add MIDI support for Steinberg MI2/MI4 commit 0689a86ae814f39af94a9736a0a5426dd82eb107 upstream. The Steinberg MI2 and MI4 interfaces are compatible with the USB class audio spec, but the MIDI part of the devices is reported as a vendor specific interface. This patch adds entries to quirks-table.h to recognize the MIDI endpoints. Audio functionality was already working and is unaffected by this change. Signed-off-by: Dominic Sacré Signed-off-by: Albert Huitsing Acked-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8ee1239a023a9a8bdbb1eaeba4e956204beedacd Author: Thomas Gleixner Date: Thu Jul 16 14:10:17 2015 +0200 genirq: Prevent resend to interrupts marked IRQ_NESTED_THREAD commit 75a06189fc508a2acf470b0b12710362ffb2c4b1 upstream. The resend mechanism happily calls the interrupt handler of interrupts which are marked IRQ_NESTED_THREAD from softirq context. This can result in crashes because the interrupt handler is not the proper way to invoke the device handlers. They must be invoked via handle_nested_irq. Prevent the resend even if the interrupt has no valid parent irq set. Its better to have a lost interrupt than a crashing machine. Reported-by: Uwe Kleine-König Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 39a0ac96dfeeda6e22748be7beac0813a544f511 Author: Haggai Eran Date: Fri Jul 17 16:24:06 2015 -0700 dma-debug: skip debug_dma_assert_idle() when disabled commit c9d120b0b2b5069cb2ae62f8eac0cef31c8544be upstream. If dma-debug is disabled due to a memory error, DMA unmaps do not affect the dma_active_cacheline radix tree anymore, and debug_dma_assert_idle() can print false warnings. Disable debug_dma_assert_idle() when dma_debug_disabled() is true. Signed-off-by: Haggai Eran Fixes: 0abdd7a81b7e ("dma-debug: introduce debug_dma_assert_idle()") Cc: Dan Williams Cc: Joerg Roedel Cc: Vinod Koul Cc: Russell King Cc: James Bottomley Cc: Florian Fainelli Cc: Sebastian Ott Cc: Jiri Kosina Cc: Horia Geanta Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 62a3fb2346044a21c8dc4d43a7812e7a54adb39b Author: Mike Snitzer Date: Wed Jul 1 12:57:40 2015 -0400 bio integrity: do not assume bio_integrity_pool exists if bioset exists commit bb8bd38b9a1685334b73e8c62e128cbedb875867 upstream. bio_integrity_alloc() and bio_integrity_free() assume that if a bio was allocated from a bioset that that bioset also had its bio_integrity_pool allocated using bioset_integrity_create(). This is a very bad assumption given that bioset_create() and bioset_integrity_create() are completely disjoint. Not all callers of bioset_create() have been trained to also call bioset_integrity_create() -- and they may not care to be. Fix this by falling back to kmalloc'ing 'struct bio_integrity_payload' rather than force all bioset consumers to (wastefully) preallocate a bio_integrity_pool that they very likely won't actually need (given the niche nature of the current block integrity support). Otherwise, a NULL pointer "Kernel BUG" with a trace like the following will be observed (as seen on s390x using zfcp storage) because dm-io doesn't use bioset_integrity_create() when creating its bioset: [ 791.643338] Call Trace: [ 791.643339] ([<00000003df98b848>] 0x3df98b848) [ 791.643341] [<00000000002c5de8>] bio_integrity_alloc+0x48/0xf8 [ 791.643348] [<00000000002c6486>] bio_integrity_prep+0xae/0x2f0 [ 791.643349] [<0000000000371e38>] blk_queue_bio+0x1c8/0x3d8 [ 791.643355] [<000000000036f8d0>] generic_make_request+0xc0/0x100 [ 791.643357] [<000000000036f9b2>] submit_bio+0xa2/0x198 [ 791.643406] [<000003ff801f9774>] dispatch_io+0x15c/0x3b0 [dm_mod] [ 791.643419] [<000003ff801f9b3e>] dm_io+0x176/0x2f0 [dm_mod] [ 791.643423] [<000003ff8074b28a>] do_reads+0x13a/0x1a8 [dm_mirror] [ 791.643425] [<000003ff8074b43a>] do_mirror+0x142/0x298 [dm_mirror] [ 791.643428] [<0000000000154fca>] process_one_work+0x18a/0x3f8 [ 791.643432] [<000000000015598a>] worker_thread+0x132/0x3b0 [ 791.643435] [<000000000015d49a>] kthread+0xd2/0xd8 [ 791.643438] [<00000000005bc0ca>] kernel_thread_starter+0x6/0xc [ 791.643446] [<00000000005bc0c4>] kernel_thread_starter+0x0/0xc Signed-off-by: Mike Snitzer Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 32469b1200b97621d0ec24aa0eb675264b95dc7b Author: Michal Marek Date: Wed Jul 1 17:19:30 2015 +0200 kbuild: Allow arch Makefiles to override {cpp,ld,c}flags commit 61754c18752ffb78145671e94f053fb202fff041 upstream. Since commit a1c48bb1 (Makefile: Fix unrecognized cross-compiler command line options), the arch Makefile is included earlier by the main Makefile, preventing the arc architecture to set its -O3 compiler option. Since there might be more use cases for an arch Makefile to fine-tune the options, add support for ARCH_CPPFLAGS, ARCH_AFLAGS and ARCH_CFLAGS variables that are appended to the respective kbuild variables. The user still has the final say via the KCPPFLAGS, KAFLAGS and KCFLAGS variables. Reported-by: Vineet Gupta Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman commit a783168dabf7c681959353b6560da3b0b1370386 Author: Alexey Brodkin Date: Mon Jul 13 10:25:17 2015 +0300 ARC: make sure instruction_pointer() returns unsigned value commit f51e2f1911122879eefefa4c592dea8bf794b39c upstream. Currently instruction_pointer() returns pt_regs->ret and so return value is of type "long", which implicitly stands for "signed long". While that's perfectly fine when dealing with 32-bit values if return value of instruction_pointer() gets assigned to 64-bit variable sign extension may happen. And at least in one real use-case it happens already. In perf_prepare_sample() return value of perf_instruction_pointer() (which is an alias to instruction_pointer() in case of ARC) is assigned to (struct perf_sample_data)->ip (which type is "u64"). And what we see if instuction pointer points to user-space application that in case of ARC lays below 0x8000_0000 "ip" gets set properly with leading 32 zeros. But if instruction pointer points to kernel address space that starts from 0x8000_0000 then "ip" is set with 32 leadig "f"-s. I.e. id instruction_pointer() returns 0x8100_0000, "ip" will be assigned with 0xffff_ffff__8100_0000. Which is obviously wrong. In particular that issuse broke output of perf, because perf was unable to associate addresses like 0xffff_ffff__8100_0000 with anything from /proc/kallsyms. That's what we used to see: ----------->8---------- 6.27% ls [unknown] [k] 0xffffffff8046c5cc 2.96% ls libuClibc-0.9.34-git.so [.] memcpy 2.25% ls libuClibc-0.9.34-git.so [.] memset 1.66% ls [unknown] [k] 0xffffffff80666536 1.54% ls libuClibc-0.9.34-git.so [.] 0x000224d6 1.18% ls libuClibc-0.9.34-git.so [.] 0x00022472 ----------->8---------- With that change perf output looks much better now: ----------->8---------- 8.21% ls [kernel.kallsyms] [k] memset 3.52% ls libuClibc-0.9.34-git.so [.] memcpy 2.11% ls libuClibc-0.9.34-git.so [.] malloc 1.88% ls libuClibc-0.9.34-git.so [.] memset 1.64% ls [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore 1.41% ls [kernel.kallsyms] [k] __d_lookup_rcu ----------->8---------- Signed-off-by: Alexey Brodkin Cc: arc-linux-dev@synopsys.com Cc: linux-kernel@vger.kernel.org Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit bad8eab06cbce7ef086e60a5e5dff3923f831d61 Author: Vineet Gupta Date: Thu Jun 18 13:54:01 2015 +0530 ARC: Override toplevel default -O2 with -O3 commit 97709069214eb75312c14946803b9da4d3814203 upstream. ARC kernels have historically been built with -O3, despite top level Makefile defaulting to -O2. This was facilitated by implicitly ordering of arch makefile include AFTER top level assigned -O2. An upstream fix to top level a1c48bb160f ("Makefile: Fix unrecognized cross-compiler command line options") changed the ordering, making ARC -O3 defunct. Fix that by NOT relying on any ordering whatsoever and use the proper arch override facility now present in kbuild (ARCH_*FLAGS) Depends-on: ("kbuild: Allow arch Makefiles to override {cpp,ld,c}flags") Suggested-by: Michal Marek Cc: Geert Uytterhoeven Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit a2bfecc423b5f96bbf9d5acb22fbceea084cc2d5 Author: Heiko Carstens Date: Mon Jul 27 09:53:49 2015 +0200 s390/cachinfo: add missing facility check to init_cache_level() commit 0b991f5cdcd6201e5401f83ca3a672343c3bfc49 upstream. Stephen Powell reported the following crash on a z890 machine: Kernel BUG at 00000000001219d0 [verbose debug info unavailable] illegal operation: 0001 ilc:3 [#1] SMP Krnl PSW : 0704e00180000000 00000000001219d0 (init_cache_level+0x38/0xe0) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 EA:3 Krnl Code: 00000000001219c2: a7840056 brc 8,121a6e 00000000001219c6: a7190000 lghi %r1,0 #00000000001219ca: eb101000004c ecag %r1,%r0,0(%r1) >00000000001219d0: a7390000 lghi %r3,0 00000000001219d4: e310f0a00024 stg %r1,160(%r15) 00000000001219da: a7080000 lhi %r0,0 00000000001219de: a7b9f000 lghi %r11,-4096 00000000001219e2: c0a0002899d9 larl %r10,634d94 Call Trace: [<0000000000478ee2>] detect_cache_attributes+0x2a/0x2b8 [<000000000097c9b0>] cacheinfo_sysfs_init+0x60/0xc8 [<00000000001001c0>] do_one_initcall+0x98/0x1c8 [<000000000094fdc2>] kernel_init_freeable+0x212/0x2d8 [<000000000062352e>] kernel_init+0x26/0x118 [<000000000062fd2e>] kernel_thread_starter+0x6/0xc The illegal operation was executed because of a missing facility check, which should have made sure that the ECAG execution would only be executed on machines which have the general-instructions-extension facility installed. Reported-and-tested-by: Stephen Powell Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 19d959286d62e07ce0e46c6c65ace822a6dc52e0 Author: Michael Holzheu Date: Thu Jul 23 19:26:15 2015 +0200 s390/bpf: clear correct BPF accumulator register commit 30342fe65e511007672437741158d493472f427f upstream. Currently we assumed the following BPF to eBPF register mapping: - BPF_REG_A -> BPF_REG_7 - BPF_REG_X -> BPF_REG_8 Unfortunately this mapping is wrong. The correct mapping is: - BPF_REG_A -> BPF_REG_0 - BPF_REG_X -> BPF_REG_7 So clear the correct registers and use the BPF_REG_A and BPF_REG_X macros instead of BPF_REG_0/7. Fixes: 054623105728 ("s390/bpf: Add s390x eBPF JIT compiler backend") Signed-off-by: Michael Holzheu Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 36566f6df428262b8ab122e062d72c1a81ad4576 Author: Heiko Carstens Date: Tue Jul 7 08:40:49 2015 +0200 s390/nmi: fix vector register corruption commit cad49cfc44a5160e3fa09b18e4e7f7cacd13f27d upstream. If a machine check happens, the machine has the vector facility installed and the extended save area exists, the cpu will save vector register contents into the extended save area. This is regardless of control register 0 contents, which enables and disables the vector facility during runtime. On each machine check we should validate the vector registers. The current code however tries to validate the registers only if the running task is using vector registers in user space. However even the current code is broken and causes vector register corruption on machine checks, if user space uses them: the prefix area contains a pointer (absolute address) to the machine check extended save area. In order to save some space the save area was put into an unused area of the second prefix page. When validating vector register contents the code uses the absolute address of the extended save area, which is wrong. Due to prefixing the vector instructions will then access contents using absolute addresses instead of real addresses, where the machine stored the contents. If the above would work there is still the problem that register validition would only happen if user space uses vector registers. If kernel space uses them also, this may also lead to vector register content corruption: if the kernel makes use of vector instructions, but the current running user space context does not, the machine check handler will validate floating point registers instead of vector registers. Given the fact that writing to a floating point register may change the upper halve of the corresponding vector register, we also experience vector register corruption in this case. Fix all of these issues, and always validate vector registers on each machine check, if the machine has the vector facility installed and the extended save area is defined. Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 88b7166f0d995edd9884a4641d2a0bca77b52090 Author: Martin Schwidefsky Date: Mon Jul 6 17:58:19 2015 +0200 s390/sclp: clear upper register halves in _sclp_print_early commit f9c87a6f46d508eae0d9ae640be98d50f237f827 upstream. If the kernel is compiled with gcc 5.1 and the XZ compression option the decompress_kernel function calls _sclp_print_early in 64-bit mode while the content of the upper register half of %r6 is non-zero. This causes a specification exception on the servc instruction in _sclp_servc. The _sclp_print_early function saves and restores the upper registers halves but it fails to clear them for the 31-bit code of the mini sclp driver. Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 5e62f6843f4071e5cbb021c00737ebd0673ebf18 Author: Heiko Carstens Date: Mon Jul 6 15:02:37 2015 +0200 s390/process: fix sfpc inline assembly commit e47994dd44bcb4a77b4152bd0eada585934703c0 upstream. The sfpc inline assembly within execve_tail() may incorrectly set bits 28-31 of the sfpc instruction to a value which is not zero. These bits however are currently unused and therefore should be zero so we won't get surprised if these bits will be used in the future. Therefore remove the second operand from the inline assembly. Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit f662ffe3a409bef287c5f0b235d9095b5aa72436 Author: Vutla, Lokesh Date: Thu Jul 2 18:33:28 2015 +0530 crypto: omap-des - Fix unmapping of dma channels commit acb33cc541d7a5495b16a133702d4c401ea4e294 upstream. dma_unmap_sg() is being called twice after completing the task. Looks like this is a copy paste error when creating des driver. With this the following warn appears during boot: [ 4.210457] ------------[ cut here ]------------ [ 4.215114] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1080 check_unmap+0x710/0x9a0() [ 4.222899] omap-des 480a5000.des: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x00000000ab2ce000] [size=8 bytes] [ 4.236785] Modules linked in: [ 4.239860] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.39-02999-g1bc045a-dirty #182 [ 4.247918] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 4.255710] [] (show_stack) from [] (dump_stack+0x84/0xb8) [ 4.262977] [] (dump_stack) from [] (warn_slowpath_common+0x68/0x8c) [ 4.271107] [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40) [ 4.279854] [] (warn_slowpath_fmt) from [] (check_unmap+0x710/0x9a0) [ 4.287991] [] (check_unmap) from [] (debug_dma_unmap_sg+0x90/0x19c) [ 4.296128] [] (debug_dma_unmap_sg) from [] (omap_des_done_task+0x1cc/0x3e4) [ 4.304963] [] (omap_des_done_task) from [] (tasklet_action+0x84/0x124) [ 4.313370] [] (tasklet_action) from [] (__do_softirq+0xf0/0x20c) [ 4.321235] [] (__do_softirq) from [] (irq_exit+0x98/0xec) [ 4.328500] [] (irq_exit) from [] (handle_IRQ+0x50/0xb0) [ 4.335589] [] (handle_IRQ) from [] (gic_handle_irq+0x28/0x5c) Removing the duplicate call to dma_unmap_sg(). Reported-by: Tomi Valkeinen Signed-off-by: Lokesh Vutla Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 6b12a75d0777a320a691a5f7a38aab2f4e80a733 Author: Andrey Ryabinin Date: Thu Jul 2 12:09:36 2015 +0300 x86/kasan: Fix boot crash on AMD processors commit d4f86beacc21d538dc41e1fc75a22e084f547edf upstream. While populating zero shadow wrong bits in upper level page tables used. __PAGE_KERNEL_RO that was used for pgd/pud/pmd has _PAGE_BIT_GLOBAL set. Global bit is present only in the lowest level of the page translation hierarchy (ptes), and it should be zero in upper levels. This bug seems doesn't cause any troubles on Intel cpus, while on AMDs it cause kernel crash on boot. Use _KERNPG_TABLE bits for pgds/puds/pmds to fix this. Reported-by: Borislav Petkov Signed-off-by: Andrey Ryabinin Cc: Alexander Popov Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: Dmitry Vyukov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1435828178-10975-5-git-send-email-a.ryabinin@samsung.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit bcb87bb5a5c1f990e584c6003e50869087bc2646 Author: Andrey Ryabinin Date: Thu Jul 2 12:09:35 2015 +0300 x86/kasan: Flush TLBs after switching CR3 commit 241d2c54c62fa0939fc9a9512b48ac3434e90a89 upstream. load_cr3() doesn't cause tlb_flush if PGE enabled. This may cause tons of false positive reports spamming the kernel to death. To fix this __flush_tlb_all() should be called explicitly after CR3 changed. Signed-off-by: Andrey Ryabinin Cc: Alexander Popov Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: Borislav Petkov Cc: Dmitry Vyukov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1435828178-10975-4-git-send-email-a.ryabinin@samsung.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 2fe36f4f2f2ae489cb7ab431b9a35947d426bbbb Author: Alexander Popov Date: Thu Jul 2 12:09:34 2015 +0300 x86/kasan: Fix KASAN shadow region page tables commit 5d5aa3cfca5cf74cd928daf3674642e6004328d1 upstream. Currently KASAN shadow region page tables created without respect of physical offset (phys_base). This causes kernel halt when phys_base is not zero. So let's initialize KASAN shadow region page tables in kasan_early_init() using __pa_nodebug() which considers phys_base. This patch also separates x86_64_start_kernel() from KASAN low level details by moving kasan_map_early_shadow(init_level4_pgt) into kasan_early_init(). Remove the comment before clear_bss() which stopped bringing much profit to the code readability. Otherwise describing all the new order dependencies would be too verbose. Signed-off-by: Alexander Popov Signed-off-by: Andrey Ryabinin Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: Borislav Petkov Cc: Dmitry Vyukov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1435828178-10975-3-git-send-email-a.ryabinin@samsung.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 16e28fc11cd6a2d04a488486cb7c945168dc2a8d Author: Andrey Ryabinin Date: Thu Jul 2 12:09:33 2015 +0300 x86/init: Clear 'init_level4_pgt' earlier commit d0f77d4d04b222a817925d33ba3589b190bfa863 upstream. Currently x86_64_start_kernel() has two KASAN related function calls. The first call maps shadow to early_level4_pgt, the second maps shadow to init_level4_pgt. If we move clear_page(init_level4_pgt) earlier, we could hide KASAN low level detail from generic x86_64 initialization code. The next patch will do it. Signed-off-by: Andrey Ryabinin Cc: Alexander Popov Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: Borislav Petkov Cc: Dmitry Vyukov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1435828178-10975-2-git-send-email-a.ryabinin@samsung.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 025a294ac3b4e1010f2bb25304aaa3d2d4770389 Author: Al Viro Date: Wed Jul 8 02:42:38 2015 +0100 freeing unlinked file indefinitely delayed commit 75a6f82a0d10ef8f13cd8fe7212911a0252ab99e upstream. Normally opening a file, unlinking it and then closing will have the inode freed upon close() (provided that it's not otherwise busy and has no remaining links, of course). However, there's one case where that does *not* happen. Namely, if you open it by fhandle with cold dcache, then unlink() and close(). In normal case you get d_delete() in unlink(2) notice that dentry is busy and unhash it; on the final dput() it will be forcibly evicted from dcache, triggering iput() and inode removal. In this case, though, we end up with *two* dentries - disconnected (created by open-by-fhandle) and regular one (used by unlink()). The latter will have its reference to inode dropped just fine, but the former will not - it's considered hashed (it is on the ->s_anon list), so it will stay around until the memory pressure will finally do it in. As the result, we have the final iput() delayed indefinitely. It's trivial to reproduce - void flush_dcache(void) { system("mount -o remount,rw /"); } static char buf[20 * 1024 * 1024]; main() { int fd; union { struct file_handle f; char buf[MAX_HANDLE_SZ]; } x; int m; x.f.handle_bytes = sizeof(x); chdir("/root"); mkdir("foo", 0700); fd = open("foo/bar", O_CREAT | O_RDWR, 0600); close(fd); name_to_handle_at(AT_FDCWD, "foo/bar", &x.f, &m, 0); flush_dcache(); fd = open_by_handle_at(AT_FDCWD, &x.f, O_RDWR); unlink("foo/bar"); write(fd, buf, sizeof(buf)); system("df ."); /* 20Mb eaten */ close(fd); system("df ."); /* should've freed those 20Mb */ flush_dcache(); system("df ."); /* should be the same as #2 */ } will spit out something like Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 322023 303843 1131 100% / Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 322023 303843 1131 100% / Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 322023 283282 21692 93% / - inode gets freed only when dentry is finally evicted (here we trigger than by remount; normally it would've happened in response to memory pressure hell knows when). Acked-by: J. Bruce Fields Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 8a5d1e374b59ffaf10bd64c319cdca7560d49c4c Author: Stefan Agner Date: Mon May 18 18:33:27 2015 +0200 can: mcp251x: fix resume when device is down commit 25b401c1816ae64bcc5dcb1d39ab41812522a0ce upstream. If a valid power regulator or a dummy regulator is used (which happens to be the case when no regulator is specified), restart_work is queued no matter whether the device was running or not at suspend time. Since work queues get initialized in the ndo_open callback, resuming leads to a NULL pointer exception. Reverse exactly the steps executed at suspend time: - Enable the power regulator in any case - Enable the transceiver regulator if the device was running, even in case we have a power regulator - Queue restart_work only in case the device was running Fixes: bf66f3736a94 ("can: mcp251x: Move to threaded interrupts instead of workqueues.") Signed-off-by: Stefan Agner Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 23596d7deb0401e36aef49e96d252d8095cdff79 Author: Sergei Shtylyov Date: Sat Jun 20 03:33:53 2015 +0300 can: rcar_can: print signed IRQ # commit c1a4c87b06fa564d6e2760a12d4e5a09badc684b upstream. Printing IRQ # using "%x" and "%u" unsigned formats isn't quite correct as 'ndev->irq' is of type *int*, so the "%d" format needs to be used instead. While fixing this, beautify the dev_info() message in rcar_can_probe() a bit. Fixes: fd1159318e55 ("can: add Renesas R-Car CAN driver") Signed-off-by: Sergei Shtylyov Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 436eacc4992c0b51ebea61a8a7ac81807f44eb6e Author: J.D. Schroeder Date: Wed Jul 8 14:38:12 2015 +0300 can: c_can: Fix default pinmux glitch at init commit 033365191136c97f88c81b7bd0011414db28bb4e upstream. The previous change 3973c526ae9c (net: can: c_can: Disable pins when CAN interface is down) causes a slight glitch on the pinctrl settings when used. Since commit ab78029 (drivers/pinctrl: grab default handles from device core), the device core will automatically set the default pins. This causes the pins to be momentarily set to the default and then to the sleep state in register_c_can_dev(). By adding an optional "enable" state, boards can set the default pin state to be disabled and avoid the glitch when the switch from default to sleep first occurs. If the "enable" state is not available c_can_pinctrl_select_state() falls back to using the "default" pinctrl state. [Roger Q] - Forward port to v4.2 and use pinctrl_get_select(). Signed-off-by: J.D. Schroeder Signed-off-by: Roger Quadros Reviewed-by: Grygorii Strashko Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 78574b4bdc49fb0d7d5d3218beb069d259b2b631 Author: Sergei Shtylyov Date: Sat Jun 20 03:32:46 2015 +0300 can: rcar_can: fix IRQ check commit 5e63e6baa159fa8c787cf783dbf3d77fbea97331 upstream. rcar_can_probe() regards 0 as a wrong IRQ #, despite platform_get_irq() that it calls returns negative error code in that case. This leads to the following being printed to the console when attempting to open the device: error requesting interrupt fffffffa because rcar_can_open() calls request_irq() with a negative IRQ #, and that function naturally fails with -EINVAL. Check for the negative error codes instead and propagate them upstream instead of just returning -ENODEV. Fixes: fd1159318e55 ("can: add Renesas R-Car CAN driver") Signed-off-by: Sergei Shtylyov Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 153fa24b8f6763c51915c59feed10dad045bd880 Author: Oliver Hartkopp Date: Fri Jun 26 11:58:19 2015 +0200 can: replace timestamp as unique skb attribute commit d3b58c47d330de8c29898fe9746f7530408f8a59 upstream. Commit 514ac99c64b "can: fix multiple delivery of a single CAN frame for overlapping CAN filters" requires the skb->tstamp to be set to check for identical CAN skbs. Without timestamping to be required by user space applications this timestamp was not generated which lead to commit 36c01245eb8 "can: fix loss of CAN frames in raw_rcv" - which forces the timestamp to be set in all CAN related skbuffs by introducing several __net_timestamp() calls. This forces e.g. out of tree drivers which are not using alloc_can{,fd}_skb() to add __net_timestamp() after skbuff creation to prevent the frame loss fixed in mainline Linux. This patch removes the timestamp dependency and uses an atomic counter to create an unique identifier together with the skbuff pointer. Btw: the new skbcnt element introduced in struct can_skb_priv has to be initialized with zero in out-of-tree drivers which are not using alloc_can{,fd}_skb() too. Signed-off-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit cea0f568222b53b21242c50445776fccd4a1b8b8 Author: Markos Chandras Date: Thu Jul 16 15:30:04 2015 +0100 MIPS: fpu.h: Allow 64-bit FPU on a 64-bit MIPS R6 CPU commit fcc53b5f6c38acbf5d311ffc3e0da517491c6f7b upstream. Commit 6134d94923d0 ("MIPS: asm: fpu: Allow 64-bit FPU on MIPS32 R6") added support for 64-bit FPU on a 32-bit MIPS R6 processor but it missed the 64-bit CPU case leading to FPU failures when requesting FR=1 mode (which is always the case for MIPS R6 userland) when running a 32-bit kernel on a 64-bit CPU. We also fix the MIPS R2 case. Signed-off-by: Markos Chandras Fixes: 6134d94923d0 ("MIPS: asm: fpu: Allow 64-bit FPU on MIPS32 R6") Reviewed-by: Paul Burton Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10734/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 219485e36468309cc71f7580d633a0b416d8e985 Author: Paul Burton Date: Fri Jul 10 16:00:24 2015 +0100 MIPS: Require O32 FP64 support for MIPS64 with O32 compat commit 4e9d324d4288b082497c30bc55b8ad13acc7cf01 upstream. MIPS32r6 code requires FP64 (ie. FR=1) support. Building a kernel with support for MIPS32r6 binaries but without support for O32 with FP64 is therefore a problem which can lead to incorrectly executed userland. CONFIG_MIPS_O32_FP64_SUPPORT is already selected when the kernel is configured for MIPS32r6, but not when the kernel is configured for MIPS64r6 with O32 compat support. Select CONFIG_MIPS_O32_FP64_SUPPORT in such configurations to prevent building kernels which execute MIPS32r6 userland incorrectly. Signed-off-by: Paul Burton Cc: Markos Chandras Cc: linux-mips@linux-mips.org Cc: Matthew Fortune Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10674/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 7ed06198d9b38b8a6c8e8a0944a4a6c3f03e5a35 Author: Markos Chandras Date: Fri Jul 10 09:29:10 2015 +0100 MIPS: c-r4k: Fix cache flushing for MT cores commit cccf34e9411c41b0cbfb41980fe55fc8e7c98fd2 upstream. MT_SMP is not the only SMP option for MT cores. The MT_SMP option allows more than one VPE per core to appear as a secondary CPU in the system. Because of how CM works, it propagates the address-based cache ops to the secondary cores but not the index-based ones. Because of that, the code does not use IPIs to flush the L1 caches on secondary cores because the CM would have done that already. However, the CM functionality is independent of the type of SMP kernel so even in non-MT kernels, IPIs are not necessary. As a result of which, we change the conditional to depend on the CM presence. Moreover, since VPEs on the same core share the same L1 caches, there is no need to send an IPI on all of them so we calculate a suitable cpumask with only one VPE per core. Signed-off-by: Markos Chandras Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10654/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit a6130c5e14b2f824c0b7e5e9dddd46529616c6af Author: Markos Chandras Date: Wed Jun 24 09:52:01 2015 +0100 MIPS: Fix erroneous JR emulation for MIPS R6 commit 143fefc8f315cd10e046e6860913c421c3385cb1 upstream. Commit 5f9f41c474befb4ebbc40b27f65bb7d649241581 ("MIPS: kernel: Prepare the JR instruction for emulation on MIPS R6") added support for emulating the JR instruction on MIPS R6 cores but that introduced a bug which could be triggered when hitting a JALR opcode because the code used the wrong field in the 'r_format' struct to determine the instruction opcode. This lead to crashes because an emulated JALR instruction was treated as a JR one when the R6 emulator was turned off. Fixes: 5f9f41c474be ("MIPS: kernel: Prepare the JR instruction for emulation on MIPS R6") Signed-off-by: Markos Chandras Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10583/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 9af14dc3d33cba85698bbfea62bcf8fee56a7c76 Author: Lucas Stach Date: Tue Jun 30 14:48:24 2015 +0200 ARM: imx6: gpc: always enable PU domain if CONFIG_PM is not set commit d438462c20a300139c2e5e65b96cadaa21b58d9a upstream. If CONFIG_PM is not set the PU power domain needs to be enabled always, otherwise there are two failure scenarios which will hang the system if one of the devices in the PU domain is accessed. 1. New DTs (4.1+) drop the "always-on" property from the PU regulator, so if it isn't properly enabled by the GPC code it will be disabled at the end of boot. 2. If the bootloader already disabled the PU domain the GPC explicitly needs to enable it again, even if the kernel doesn't do any power management. This is a bit hypothetical, as it requires to boot a mainline kernel on a downstream bootloader, as no mainline bootloader disables the PM domains. Signed-off-by: Lucas Stach Acked-by: Philipp Zabel Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 50c301372e86ce52a897ead3f55044811a9ebb57 Author: Marek Szyprowski Date: Wed Jul 8 13:21:55 2015 +0100 ARM: 8404/1: dma-mapping: fix off-by-one error in bitmap size check commit 462859aa7bbe1ac83ec4377a0a06fe60778f3f27 upstream. nr_bitmaps member of mapping structure stores the number of already allocated bitmaps and it is interpreted as loop iterator (it starts from 0 not from 1), so a comparison against number of possible bitmap extensions should include this fact. This patch fixes this by changing the extension failure condition. This issue has been introduced by commit 4d852ef8c2544ce21ae41414099a7504c61164a0 ("arm: dma-mapping: Add support to extend DMA IOMMU mappings"). Reported-by: Hyungwon Hwang Signed-off-by: Marek Szyprowski Reviewed-by: Hyungwon Hwang Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 0784a0b533fc6526b2f899ce9fe50d745f791fba Author: Roger Quadros Date: Wed Jun 17 17:52:43 2015 +0300 ARM: dts: am57xx-beagle-x15: Provide supply for usb2_phy2 commit 9ab402aed38b95d9ce453108622be0fc6f167568 upstream. Without this USB2 breaks if USB1 is disabled or USB1 initializes after USB2 e.g. due to deferred probing. Fixes: 5a0f93c6576a ("ARM: dts: Add am57xx-beagle-x15") Signed-off-by: Roger Quadros Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit c0c4945b2c39ca6a543664cbccce26b400d66562 Author: Roger Quadros Date: Tue Jul 7 17:27:57 2015 +0300 ARM: dts: dra7x-evm: Prevent glitch on DCAN1 pinmux commit 2acb5c301edf39ab6d066687ce70da1166e4de9e upstream. Driver core sets "default" pinmux on on probe and CAN driver sets "sleep" pinmux during register. This causes a small window where the CAN pins are in "default" state with the DCAN module being disabled. Change the "default" state to be like sleep so this glitch is avoided. Add a new "active" state that is used by the driver when CAN is actually active. Signed-off-by: Roger Quadros Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 7185dab0dbe1f8e2cae26dd759475aa146e1f071 Author: Robert Jarzmik Date: Sat Jul 11 21:33:06 2015 +0200 ARM: pxa: fix dm9000 platform data regression commit a927ef895e288e79f1bfed221f27d7bfa37e907f upstream. Since dm9000 driver added support for a vcc regulator, platform data based platforms have their ethernet broken, as the regulator claiming returns -EPROBE_DEFER and prevents dm9000 loading. This patch fixes this for all pxa boards using dm9000, by using the specific regulator_has_full_constraints() function. This was discovered and tested on the cm-x300 board. Fixes: 7994fe55a4a2 ("dm9000: Add regulator and reset support to dm9000") Signed-off-by: Robert Jarzmik Acked-by: Igor Grinberg Signed-off-by: Greg Kroah-Hartman commit 0ab58712e54f3a3258072feb15ab14bfbc42fa02 Author: Christophe Jaillet Date: Mon Jul 13 11:32:43 2015 +0200 parisc: mm: Fix a memory leak related to pmd not attached to the pgd commit 4c4ac9a48ac512c6b5a6cca06cfad2ad96e8caaa upstream. Commit 0e0da48dee8d ("parisc: mm: don't count preallocated pmds") introduced a memory leak. After this commit, the 'return' statement in pmd_free is executed in all cases. Even for pmd that are not attached to the pgd. So 'free_pages' can never be called anymore, leading to a memory leak. Signed-off-by: Christophe JAILLET Acked-by: Kirill A. Shutemov Acked-by: Mikulas Patocka Acked-by: Helge Deller Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 78eb5efb6f79ca8fbd03cd0082e6bb22ca37fb48 Author: John David Anglin Date: Wed Jul 1 17:18:37 2015 -0400 parisc: Fix some PTE/TLB race conditions and optimize __flush_tlb_range based on timing results commit 01ab60570427caa24b9debc369e452e86cd9beb4 upstream. The increased use of pdtlb/pitlb instructions seemed to increase the frequency of random segmentation faults building packages. Further, we had a number of cases where TLB inserts would repeatedly fail and all forward progress would stop. The Haskell ghc package caused a lot of trouble in this area. The final indication of a race in pte handling was this syslog entry on sibaris (C8000): swap_free: Unused swap offset entry 00000004 BUG: Bad page map in process mysqld pte:00000100 pmd:019bbec5 addr:00000000ec464000 vm_flags:00100073 anon_vma:0000000221023828 mapping: (null) index:ec464 CPU: 1 PID: 9176 Comm: mysqld Not tainted 4.0.0-2-parisc64-smp #1 Debian 4.0.5-1 Backtrace: [<0000000040173eb0>] show_stack+0x20/0x38 [<0000000040444424>] dump_stack+0x9c/0x110 [<00000000402a0d38>] print_bad_pte+0x1a8/0x278 [<00000000402a28b8>] unmap_single_vma+0x3d8/0x770 [<00000000402a4090>] zap_page_range+0xf0/0x198 [<00000000402ba2a4>] SyS_madvise+0x404/0x8c0 Note that the pte value is 0 except for the accessed bit 0x100. This bit shouldn't be set without the present bit. It should be noted that the madvise system call is probably a trigger for many of the random segmentation faults. In looking at the kernel code, I found the following problems: 1) The pte_clear define didn't take TLB lock when clearing a pte. 2) We didn't test pte present bit inside lock in exception support. 3) The pte and tlb locks needed to merged in order to ensure consistency between page table and TLB. This also has the effect of serializing TLB broadcasts on SMP systems. The attached change implements the above and a few other tweaks to try to improve performance. Based on the timing code, TLB purges are very slow (e.g., ~ 209 cycles per page on rp3440). Thus, I think it beneficial to test the split_tlb variable to avoid duplicate purges. Probably, all PA 2.0 machines have combined TLBs. I dropped using __flush_tlb_range in flush_tlb_mm as I realized all applications and most threads have a stack size that is too large to make this useful. I added some comments to this effect. Since implementing 1 through 3, I haven't had any random segmentation faults on mx3210 (rp3440) in about one week of building code and running as a Debian buildd. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit d474669e907ea28024def319bfcdef6a2c21d6ac Author: Dmitry Torokhov Date: Fri Jul 10 10:11:07 2015 -0700 Revert "Input: synaptics - allocate 3 slots to keep stability in image sensors" commit dbf3c370862d73fcd2c74ca55e254bb02143238d upstream. This reverts commit 63c4fda3c0bb841b1aad1298fc7fe94058fc79f8 as it causes issues with detecting 3-finger taps. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100481 Acked-by: Benjamin Tissoires commit 5f0f854a0a8185240c934c77e8c9092313ba932e Author: Shreyas B. Prabhu Date: Tue Jul 7 01:39:23 2015 +0530 powerpc/powernv: Fix race in updating core_idle_state commit b32aadc1a8ed84afbe924cd2ced31cd6a2e67074 upstream. core_idle_state is maintained for each core. It uses 0-7 bits to track whether a thread in the core has entered fastsleep or winkle. 8th bit is used as a lock bit. The lock bit is set in these 2 scenarios- - The thread is first in subcore to wakeup from sleep/winkle. - If its the last thread in the core about to enter sleep/winkle While the lock bit is set, if any other thread in the core wakes up, it loops until the lock bit is cleared before proceeding in the wakeup path. This helps prevent race conditions w.r.t fastsleep workaround and prevents threads from switching to process context before core/subcore resources are restored. But, in the path to sleep/winkle entry, we currently don't check for lock-bit. This exposes us to following race when running with subcore on- First thread in the subcorea Another thread in the same waking up core entering sleep/winkle lwarx r15,0,r14 ori r15,r15,PNV_CORE_IDLE_LOCK_BIT stwcx. r15,0,r14 [Code to restore subcore state] lwarx r15,0,r14 [clear thread bit] stwcx. r15,0,r14 andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS stw r15,0(r14) Here, after the thread entering sleep clears its thread bit in core_idle_state, the value is overwritten by the thread waking up. In such cases when the core enters fastsleep, code mistakes an idle thread as running. Because of this, the first thread waking up from fastsleep which is supposed to resync timebase skips it. So we can end up having a core with stale timebase value. This patch fixes the above race by looping on the lock bit even while entering the idle states. Signed-off-by: Shreyas B. Prabhu Fixes: 7b54e9f213f76 'powernv/powerpc: Add winkle support for offline cpus' Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 4a0c377cda3533ff80c60c4fd46f787aff4715c3 Author: Daniel Axtens Date: Fri Jul 10 09:04:25 2015 +1000 cxl: Check if afu is not null in cxl_slbia commit 2c069a118fe1d80c47dca84e1561045fc7f3cc9e upstream. The pointer to an AFU in the adapter's list of AFUs can be null if we're in the process of removing AFUs. The afu_list_lock doesn't guard against this. Say we have 2 slices, and we're in the process of removing cxl. - We remove the AFUs in order (see cxl_remove). In cxl_remove_afu for AFU 0, we take the lock, set adapter->afu[0] = NULL, and release the lock. - Then we get an slbia. In cxl_slbia we take the lock, and set afu = adapter->afu[0], which is NULL. - Therefore our attempt to check afu->enabled will blow up. Therefore, check if afu is a null pointer before dereferencing it. Signed-off-by: Daniel Axtens Acked-by: Michael Neuling Acked-by: Ian Munsie Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit bbf9f2c9cf06ccb1543c23501f77f6d34868d009 Author: Ian Munsie Date: Tue Jul 7 15:45:45 2015 +1000 cxl: Fix off by one error allowing subsequent mmap page to be accessed commit 10a5894f2dedd8a26b3132497445b314c0d952c4 upstream. It was discovered that if a process mmaped their problem state area they were able to access one page more than expected, potentially allowing them to access the problem state area of an unrelated process. This was due to a simple off by one error in the mmap fault handler introduced in 0712dc7e73e59d79bcead5d5520acf4e9e917e87 ("cxl: Fix issues when unmapping contexts"), which is fixed in this patch. Fixes: 0712dc7e73e5 ("cxl: Fix issues when unmapping contexts") Signed-off-by: Ian Munsie Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman