commit 36b54ba2a114b60bd2c8d5de84d2aa49ec9a64fc Author: Greg Kroah-Hartman Date: Sun Oct 5 13:41:53 2014 -0700 Linux 3.16.4 commit 7fd1a4cc5672a4a92b42516f0d7849295dc46efc Author: Rajendra Nayak Date: Wed Aug 27 19:38:22 2014 -0600 ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() variants commit af438fec6cb99fc2e2faf8b16b865af26ce722e6 upstream. Use the corresponding compatibles to identify the devices. Signed-off-by: Rajendra Nayak Signed-off-by: Lokesh Vutla Acked-by: Nishanth Menon Tested-by: Nishanth Menon Signed-off-by: Paul Walmsley Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit ffbfac661ccbafa336a514df8f0e2eb4ac943be7 Author: Stephen Boyd Date: Tue Jul 15 14:59:21 2014 -0700 clk: qcom: Fix PLL rate configurations commit 5b6b7490af110c2b0df807eddd00ae6290bcf50a upstream. Sometimes we need to program PLLs with a fixed rate configuration during driver probe. Doing this after we register the PLLs with the clock framework causes the common clock framework to assume the rate of the PLLs are 0. This causes all sorts of problems for rate recalculations because the common clock framework caches the rate once at registration time unless a flag is set to always recalculate the rates. Split the qcom_cc_probe() function into two pieces, map and everything else, so that drivers which need to configure some PLL rates or otherwise twiddle bits in the clock controller can do so before registering clocks. This allows us to properly detect the rates of PLLs that are programmed at boot. Fixes: 49fc825f0cc2 "clk: qcom: Consolidate common probe code" Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit a5efefc12e00f33ba875d35d56abbb32e922fbc6 Author: Stephen Boyd Date: Tue Jul 8 18:36:06 2014 -0700 clk: qcom: mdp_lut_clk is a child of mdp_src commit f87dfcabc6f173cc811d185d33327f50a8c88399 upstream. The mdp_lut_clk isn't a child of the mdp_clk. Instead it's the child of the mdp_src clock. Fix it. Fixes: 6d00b56fe "clk: qcom: Add support for MSM8960's multimedia clock controller (MMCC)" Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 67c6eac3d76683a20eaefe7ae8b0cee65a6ae9f3 Author: Stephen Boyd Date: Tue Jul 8 18:36:06 2014 -0700 clk: qcom: Fix MN frequency tables, parent map, and jpegd commit ff20783f7b9f35b29e768d8ecc7076c1ca1a60ca upstream. Clocks that don't have a pre-divider don't list any pre-divider in their frequency tables, but their tables are initialized using aggregate initializers. Use tagged initializers so we properly assign the m and n values for each frequency. Furthermore, the mmcc_pxo_pll8_pll2_pll3 array improperly mapped the second element to pll2 instead of pll8, causing the clock driver to recalculate the wrong rate for any clocks using this array along with a rate that uses pll2. Plus the .num_parents field is 3 instead of 4 so you can't even switch the parent to pll3. Finally I noticed that the jpegd clock improperly indicates that the pre-divider width is only 2, when it's actually 4 bits wide. Fixes: 6d00b56fe "clk: qcom: Add support for MSM8960's multimedia clock controller (MMCC)" Tested-by: Rob Clark Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit a33896f188f56c3cd268d1cf89396a7d01e77de5 Author: Arnd Bergmann Date: Fri Jun 20 14:23:28 2014 +0200 staging/lustre: disable virtual block device for 64K pages commit 0bf22be0da8ea74bc7ccc5b07d7855830be16eca upstream. The lustre virtual block device cannot handle 64K pages and fails at compile time. To avoid running into this error, let's disable the Kconfig option for this driver in cases it doesn't support. Reported-by: Dann Frazier Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit d38b13a56028a1cf9d66b76594e985dcd58a11ef Author: Theodore Ts'o Date: Wed Sep 3 09:33:00 2014 -0400 ext4: avoid trying to kfree an ERR_PTR pointer commit a9cfcd63e8d206ce4235c355d857c4fbdf0f4587 upstream. Thanks to Dan Carpenter for extending smatch to find bugs like this. (This was found using a development version of smatch.) Fixes: 36de928641ee48b2078d3fe9514242aaa2f92013 Reported-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman commit 3f50e517f4e5150fba0d00a97a5a09298cc1e0dd Author: Theodore Ts'o Date: Sat Aug 23 17:47:19 2014 -0400 ext4: propagate errors up to ext4_find_entry()'s callers commit 36de928641ee48b2078d3fe9514242aaa2f92013 upstream. If we run into some kind of error, such as ENOMEM, while calling ext4_getblk() or ext4_dx_find_entry(), we need to make sure this error gets propagated up to ext4_find_entry() and then to its callers. This way, transient errors such as ENOMEM can get propagated to the VFS. This is important so that the system calls return the appropriate error, and also so that in the case of ext4_lookup(), we return an error instead of a NULL inode, since that will result in a negative dentry cache entry that will stick around long past the OOM condition which caused a transient ENOMEM error. Google-Bug-Id: #17142205 Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 7dcde737525d27f9368f80b043806c622c67aa25 Author: Gu Zheng Date: Wed Sep 3 17:45:44 2014 +0800 aio: block exit_aio() until all context requests are completed commit 6098b45b32e6baeacc04790773ced9340601d511 upstream. It seems that exit_aio() also needs to wait for all iocbs to complete (like io_destroy), but we missed the wait step in current implemention, so fix it in the same way as we did in io_destroy. Signed-off-by: Gu Zheng Signed-off-by: Benjamin LaHaise [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 6449fc8c58f607719d3856a8e2fb662ea313cdfc Author: Suman Tripathi Date: Fri Aug 8 21:44:25 2014 +0530 ahci_xgene: Removing NCQ support from the APM X-Gene SoC AHCI SATA Host Controller driver. commit 72f79f9e35bd3f78ee8853f2fcacaa197d23ebac upstream. This patch removes the NCQ support from the APM X-Gene SoC AHCI Host Controller driver as it doesn't support it. Signed-off-by: Loc Ho Signed-off-by: Suman Tripathi Signed-off-by: Tejun Heo [bwh: Backported to 3.16: host flags are passed to ahci_platform_init_host()] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 58c6784f31ebae0a26d9e90b976d3dc8e8de5cf4 Author: Nishanth Menon Date: Mon Aug 18 11:56:54 2014 -0500 clk: ti: divider: Provide error check for incoming parameters in set_rate commit 2f1032517623b70920d99529e5c87c8c680ab8bf upstream. Check for valid parameters in check rate. Else, we end up getting errors like: [ 0.000000] Division by zero in kernel. [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0-rc1 #1 [ 0.000000] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 0.000000] [] (show_stack) from [] (dump_stack+0x78/0x94) [ 0.000000] [] (dump_stack) from [] (Ldiv0+0x8/0x10) [ 0.000000] [] (Ldiv0) from [] (ti_clk_divider_set_rate+0x14/0x14c) [ 0.000000] [] (ti_clk_divider_set_rate) from [] (clk_change_rate+0x138/0x180) [ 0.000000] [] (clk_change_rate) from [] (clk_change_rate+0x108/0x180) This occurs as part of the inital clock tree update of child clock nodes where new_rate could be 0 for non functional clocks. Fixes: b4761198bfaf296 ("CLK: ti: add support for ti divider-clock") Signed-off-by: Nishanth Menon Signed-off-by: Tero Kristo Signed-off-by: Greg Kroah-Hartman commit e8c736166ec62bf3143b5f59ee9326e11009dd55 Author: Tero Kristo Date: Thu Aug 21 16:47:45 2014 +0300 clk: prevent erronous parsing of children during rate change commit 067bb1741c27c8d3b74ac98c0b8fc12b31e67005 upstream. In some cases, clocks can switch their parent with clk_set_rate, for example clk_mux can do this in some cases. Current implementation of clk_change_rate uses un-safe list iteration on the clock children, which will cause wrong clocks to be parsed in case any of the clock children change their parents during the change rate operation. Fixed by using the safe list iterator instead. The problem was detected due to some divide by zero errors generated by clock init on dra7-evm board, see discussion under http://article.gmane.org/gmane.linux.ports.arm.kernel/349180 for details. Fixes: 71472c0c06cf ("clk: add support for clock reparent on set_rate") Signed-off-by: Tero Kristo Reported-by: Nishanth Menon Signed-off-by: Mike Turquette Signed-off-by: Greg Kroah-Hartman commit 5e2c757758986247bf709825201931975dcdf748 Author: Nishanth Menon Date: Mon Aug 18 11:56:55 2014 -0500 clk: ti: dra7-atl: Provide error check for incoming parameters in set_rate commit 20411dad75ece9a613af715df4489e60990c4017 upstream. Check for valid parameters in check rate. Else, we end up getting errors. This occurs as part of the inital clock tree update of child clock nodes where new_rate could be 0 for non functional clocks. Fixes: 9ac33b0ce81fa48 (" CLK: TI: Driver for DRA7 ATL (Audio Tracking Logic)") Signed-off-by: Nishanth Menon Signed-off-by: Tero Kristo Signed-off-by: Greg Kroah-Hartman commit c2125f7261b1c54b726a18825e091e1eb1d53bda Author: Viresh Kumar Date: Tue Sep 30 09:33:17 2014 +0530 cpufreq: update 'cpufreq_suspended' after stopping governors commit b1b12babe3b72cfb08b875245e5a5d7c2747c772 upstream. Commit 8e30444e1530 ("cpufreq: fix cpufreq suspend/resume for intel_pstate") introduced a bug where the governors wouldn't be stopped anymore for ->target{_index}() drivers during suspend. This happens because 'cpufreq_suspended' is updated before stopping the governors during suspend and due to this __cpufreq_governor() would return early due to this check: /* Don't start any governor operations if we are entering suspend */ if (cpufreq_suspended) return 0; Fixes: 8e30444e1530 ("cpufreq: fix cpufreq suspend/resume for intel_pstate") Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 9b117b107be45ede788bf6656766424f67b0dd0f Author: Dan Carpenter Date: Tue Aug 5 11:09:59 2014 +0300 partitions: aix.c: off by one bug commit d97a86c170b4e432f76db072a827fe30b4d6f659 upstream. The lvip[] array has "state->limit" elements so the condition here should be >= instead of >. Fixes: 6ceea22bbbc8 ('partitions: add aix lvm partition support files') Signed-off-by: Dan Carpenter Acked-by: Philippe De Muyter Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 65862be0ad074568447ec9939f79f553e1ac84da Author: Andy Shevchenko Date: Wed Jun 18 12:15:38 2014 +0300 dmaengine: dw: don't perform DMA when dmaengine_submit is called commit dd8ecfcac66b4485416b2d1df0ec4798b198d7d6 upstream. Accordingly to discussion [1] and followed up documentation the DMA controller driver shouldn't start any DMA operations when dmaengine_submit() is called. This patch fixes the workflow in dw_dmac driver to follow the documentation. [1] http://www.spinics.net/lists/arm-kernel/msg125987.html Signed-off-by: Andy Shevchenko Signed-off-by: Vinod Koul Cc: "Petallo, MauriceX R" Signed-off-by: Greg Kroah-Hartman commit 491f27a0c192d8a553dc69b30eeb21b544587c7d Author: Andy Shevchenko Date: Wed Jun 18 12:15:36 2014 +0300 dmaengine: dw: introduce dwc_dostart_first_queued() helper commit e7637c6c0382485f4d2e20715d058dae6f2b6a7c upstream. We have a duplicate code which starts first descriptor in the queue. Let's make this as a separate helper that can be used in future as well. Signed-off-by: Andy Shevchenko Signed-off-by: Vinod Koul Cc: "Petallo, MauriceX R" Signed-off-by: Greg Kroah-Hartman commit 8031b69631d365db146bba288147dba31d991d2d Author: Ulf Hansson Date: Fri Jun 13 13:21:38 2014 +0200 mmc: mmci: Reverse IRQ handling for the arm_variant commit 7878289b269d41c8e611aa6d4519feae706e49f3 upstream. Commit "mmc: mmci: Handle CMD irq before DATA irq", caused an issue when using the ARM model of the PL181 and running QEMU. The bug was reported for the following QEMU version: $ qemu-system-arm -version QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.1), Copyright (c) 2003-2008 Fabrice Bellard To resolve the problem, let's restore the old behavior were the DATA irq is handled prior the CMD irq, but only for the arm_variant, which the problem was reported for. Reported-by: John Stultz Cc: Peter Maydell Cc: Russell King Tested-by: Kees Cook Tested-by: John Stultz Cc: # v3.15+ Signed-off-by: Ulf Hansson [kees: backported to 3.16] Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit e765aed022b94f52e7531d5ee51c98f2c240d129 Author: Pablo Neira Ayuso Date: Tue Aug 5 17:25:59 2014 +0200 netfilter: nf_tables: don't update chain with unset counters commit b88825de8545ad252c31543fef13cadf4de7a2bc upstream. Fix possible replacement of the per-cpu chain counters by null pointer when updating an existing chain in the commit path. Reported-by: Matteo Croce Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 420d3e020dbdc9cb32faffc9307bf85da3e942ec Author: Julian Anastasov Date: Fri Aug 22 17:53:41 2014 +0300 ipvs: fix ipv6 hook registration for local replies commit eb90b0c734ad793d5f5bf230a9e9a4dcc48df8aa upstream. commit fc604767613b6d2036cdc35b660bc39451040a47 ("ipvs: changes for local real server") from 2.6.37 introduced DNAT support to local real server but the IPv6 LOCAL_OUT handler ip_vs_local_reply6() is registered incorrectly as IPv4 hook causing any outgoing IPv4 traffic to be dropped depending on the IP header values. Chris tracked down the problem to CONFIG_IP_VS_IPV6=y Bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349768 Reported-by: Chris J Arges Tested-by: Chris J Arges Signed-off-by: Julian Anastasov Signed-off-by: Simon Horman Signed-off-by: Greg Kroah-Hartman commit 7c6d4f8c86252dc5521c4d3f2341827f701ad5fe Author: Daniel Borkmann Date: Mon Aug 18 15:46:28 2014 +0200 netfilter: x_tables: allow to use default cgroup match commit caa8ad94edf686d02b555c65a6162c0d1b434958 upstream. There's actually no good reason why we cannot use cgroup id 0, so lets just remove this artificial barrier. Reported-by: Alexey Perevalov Signed-off-by: Daniel Borkmann Tested-by: Alexey Perevalov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit d0b41615828b432ec25fd51b05cd3cac50514856 Author: Alex Gartrell Date: Wed Jul 16 15:57:34 2014 -0700 ipvs: Maintain all DSCP and ECN bits for ipv6 tun forwarding commit 76f084bc10004b3050b2cff9cfac29148f1f6088 upstream. Previously, only the four high bits of the tclass were maintained in the ipv6 case. This matches the behavior of ipv4, though whether or not we should reflect ECN bits may be up for debate. Signed-off-by: Alex Gartrell Acked-by: Julian Anastasov Signed-off-by: Simon Horman Signed-off-by: Greg Kroah-Hartman commit 1bc65bdedac3b00955e11041a8b83a827041ccdf Author: Eric Dumazet Date: Thu Jul 24 06:36:50 2014 +0200 netfilter: xt_hashlimit: perform garbage collection from process context commit 7bd8490eef9776ced7632345df5133384b6be0fe upstream. xt_hashlimit cannot be used with large hash tables, because garbage collector is run from a timer. If table is really big, its possible to hold cpu for more than 500 msec, which is unacceptable. Switch to a work queue, and use proper scheduling points to remove latencies spikes. Later, we also could switch to a smoother garbage collection done at lookup time, one bucket at a time... Signed-off-by: Eric Dumazet Cc: Florian Westphal Cc: Patrick McHardy Reviewed-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit f3a221f2c2aef45868a3f191a2fe820b472a18fe Author: NeilBrown Date: Mon Sep 22 10:06:23 2014 +1000 md/raid1: intialise start_next_window for READ case to avoid hang commit f0cc9a057151892b885be21a1d19b0185568281d upstream. r1_bio->start_next_window is not initialised in the READ case, so allow_barrier may incorrectly decrement conf->current_window_requests which can cause raise_barrier() to block forever. Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761 Reported-by: Brassow Jonathan Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit b867dcdf636d5f7f9d0dff78d463aebe6c0c897d Author: NeilBrown Date: Thu Sep 18 11:09:04 2014 +1000 md/raid1: fix_read_error should act on all non-faulty devices. commit b8cb6b4c121e1bf1963c16ed69e7adcb1bc301cd upstream. If a devices is being recovered it is not InSync and is not Faulty. If a read error is experienced on that device, fix_read_error() will be called, but it ignores non-InSync devices. So it will neither fix the error nor fail the device. It is incorrect that fix_read_error() ignores non-InSync devices. It should only ignore Faulty devices. So fix it. This became a bug when we allowed reading from a device that was being recovered. It is suitable for any subsequent -stable kernel. Fixes: da8840a747c0dbf49506ec906757a6b87b9741e9 Reported-by: Alexander Lyakas Tested-by: Alexander Lyakas Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 5c913439772eb6d55dfcdda81b57ac3063def50f Author: NeilBrown Date: Tue Sep 16 12:14:14 2014 +1000 md/raid1: count resync requests in nr_pending. commit 34e97f170149bfa14979581c4c748bc9b4b79d5b upstream. Both normal IO and resync IO can be retried with reschedule_retry() and so be counted into ->nr_queued, but only normal IO gets counted in ->nr_pending. Before the recent improvement to RAID1 resync there could only possibly have been one or the other on the queue. When handling a read failure it could only be normal IO. So when handle_read_error() called freeze_array() the fact that freeze_array only compares ->nr_queued against ->nr_pending was safe. But now that these two types can interleave, we can have both normal and resync IO requests queued, so we need to count them both in nr_pending. This error can lead to freeze_array() hanging if there is a read error, so it is suitable for -stable. Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761 Reported-by: Brassow Jonathan Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit cf3fcd4f32f29171837d26004f9e5c21c1712515 Author: NeilBrown Date: Wed Sep 10 16:01:24 2014 +1000 md/raid1: update next_resync under resync_lock. commit c2fd4c94deedb89ac1746c4a53219be499372c06 upstream. raise_barrier() uses next_resync as part of its calculations, so it really should be updated first, instead of afterwards. next_resync is always used under resync_lock so update it under resync lock to, just before it is used. That is safest. This could cause normal IO and resync IO to interact badly so it suitable for -stable. Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761 Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit fee89f17c252a11e7431cf974e7037966defe0b7 Author: NeilBrown Date: Wed Sep 10 15:56:57 2014 +1000 md/raid1: Don't use next_resync to determine how far resync has progressed commit 235549605eb7f1c5a37cef8b09d12e6d412c5cd6 upstream. next_resync is (approximately) the location for the next resync request. However it does *not* reliably determine the earliest location at which resync might be happening. This is because resync requests can complete out of order, and we only limit the number of current requests, not the distance from the earliest pending request to the latest. mddev->curr_resync_completed is a reliable indicator of the earliest position at which resync could be happening. It is updated less frequently, but is actually reliable which is more important. So use it to determine if a write request is before the region being resynced and so safe from conflict. This error can allow resync IO to interfere with normal IO which could lead to data corruption. Hence: stable. Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761 Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 0fdbd42fb0875cadef70e36f2da221b070f3accb Author: NeilBrown Date: Wed Sep 10 15:01:49 2014 +1000 md/raid1: make sure resync waits for conflicting writes to complete. commit 2f73d3c55d09ce60647b96ad2a9b539c95a530ee upstream. The resync/recovery process for raid1 was recently changed so that writes could happen in parallel with resync providing they were in different regions of the device. There is a problem though: While a write request will always wait for conflicting resync to complete, a resync request will *not* always wait for conflicting writes to complete. Two changes are needed to fix this: 1/ raise_barrier (which waits until it is safe to do resync) must wait until current_window_requests is zero 2/ wait_battier (which waits at the start of a new write request) must update current_window_requests if the request could possible conflict with a concurrent resync. As concurrent writes and resync can lead to data loss, this patch is suitable for -stable. Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761 Cc: majianpeng Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit dd777df4ddcec4e3cac323c22f78eb22591d2c20 Author: NeilBrown Date: Tue Sep 9 13:49:46 2014 +1000 md/raid1: be more cautious where we read-balance during resync. commit c6d119cf1b5a778e9ed60a006e2a434fcc4471a2 upstream. commit 79ef3a8aa1cb1523cc231c9a90a278333c21f761 made it possible for reads to happen concurrently with resync. This means that we need to be more careful where read_balancing is allowed during resync - we can no longer be sure that any resync that has already started will definitely finish. So keep read_balancing to before recovery_cp, which is conservative but safe. This bug makes it possible to read from a device that doesn't have up-to-date data, so it can cause data corruption. So it is suitable for any kernel since 3.11. Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761 Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 3ab661d945090ce254bea99d82989cddb5589e2d Author: NeilBrown Date: Thu Sep 4 16:30:38 2014 +1000 md/raid1: clean up request counts properly in close_sync() commit 669cc7ba77864e7b1ac39c9f2b2afb8730f341f4 upstream. If there are outstanding writes when close_sync is called, the change to ->start_next_window might cause them to decrement the wrong counter when they complete. Fix this by merging the two counters into the one that will be decremented. Having an incorrect value in a counter can cause raise_barrier() to hangs, so this is suitable for -stable. Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761 Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit c5704583ad1f758b46ca91924634f97f731671a4 Author: Zhaowei Yuan Date: Thu Aug 21 23:28:21 2014 -0300 media: vb2: fix plane index sanity check in vb2_plane_cookie() commit a9ae4692eda4b99f85757b15d60971ff78a0a0e2 upstream. It's also invalid when plane_no is equal to vb->num_planes Signed-off-by: Zhaowei Yuan Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 0cc581bb13d8521f4f2f21f647ae5ab6bec060c1 Author: Hans Verkuil Date: Mon Aug 4 07:14:14 2014 -0300 media: vb2: fix vb2 state check when start_streaming fails commit bf3593d939520559774cbfee03ba5f314d909620 upstream. Commit bd994ddb2a12a3ff48cd549ec82cdceaea9614df (vb2: Fix stream start and buffer completion race) broke the buffer state check in vb2_buffer_done. So accept all three possible states there since I can no longer tell the difference between vb2_buffer_done called from start_streaming or from elsewhere. Instead add a WARN_ON at the end of start_streaming that will check whether any buffers were added to the done list, since that implies that the wrong state was used as well. Signed-off-by: Hans Verkuil Acked-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit dac6454d9de81a766513d157f92971299a228957 Author: Hans Verkuil Date: Fri Aug 1 09:18:50 2014 -0300 media: videobuf2-dma-sg: fix for wrong GFP mask to sg_alloc_table_from_pages commit 47bc59c52b005f546343c373370a7eec6a2b0f84 upstream. sg_alloc_table_from_pages() only allocates a sg_table, so it should just use GFP_KERNEL, not gfp_flags. If gfp_flags contains __GFP_DMA32 then mm/sl[au]b.c will call BUG_ON: [ 358.027515] ------------[ cut here ]------------ [ 358.027546] kernel BUG at mm/slub.c:1416! [ 358.027558] invalid opcode: 0000 [#1] PREEMPT SMP [ 358.027576] Modules linked in: mt2131 s5h1409 tda8290 tuner cx25840 cx23885 btcx_risc altera_ci tda18271 altera_stapl videobuf2_dvb tveeprom cx2341x videobuf2_dma_sg dvb_core rc_core videobuf2_memops videobuf2_core nouveau zr36067 videocodec v4l2_common videodev media x86_pkg_temp_thermal cfbfillrect cfbimgblt cfbcopyarea ttm drm_kms_helper processor button isci [ 358.027712] CPU: 19 PID: 3654 Comm: cat Not tainted 3.16.0-rc6-telek #167 [ 358.027723] Hardware name: ASUSTeK COMPUTER INC. Z9PE-D8 WS/Z9PE-D8 WS, BIOS 5404 02/10/2014 [ 358.027741] task: ffff880897c7d960 ti: ffff88089b4d4000 task.ti: ffff88089b4d4000 [ 358.027753] RIP: 0010:[] [] new_slab+0x280/0x320 [ 358.027776] RSP: 0018:ffff88089b4d7ae8 EFLAGS: 00010002 [ 358.027787] RAX: ffff880897c7d960 RBX: 0000000000000000 RCX: ffff88089b4d7b50 [ 358.027798] RDX: 00000000ffffffff RSI: 0000000000000004 RDI: ffff88089f803b00 [ 358.027809] RBP: ffff88089b4d7bb8 R08: 0000000000000000 R09: 0000000100400040 [ 358.027821] R10: 0000160000000000 R11: ffff88109bc02c40 R12: 0000000000000001 [ 358.027832] R13: ffff88089f8000c0 R14: ffff88089f803b00 R15: ffff8810bfcf4be0 [ 358.027845] FS: 00007f83fe5c0700(0000) GS:ffff8810bfce0000(0000) knlGS:0000000000000000 [ 358.027858] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 358.027868] CR2: 0000000001dfd568 CR3: 0000001097d5a000 CR4: 00000000000407e0 [ 358.027878] Stack: [ 358.027885] ffffffff81198860 ffff8810bfcf4be0 ffff880897c7d960 0000000000001b00 [ 358.027905] ffff880897c7d960 0000000000000000 ffff8810bfcf4bf0 0000000000000000 [ 358.027924] 0000000000000000 0000000100000100 ffffffff813ef84a 00000004ffffffff [ 358.027944] Call Trace: [ 358.027956] [] ? __slab_alloc+0x400/0x4e0 [ 358.027973] [] ? sg_kmalloc+0x1a/0x30 [ 358.027985] [] __kmalloc+0x127/0x150 [ 358.027997] [] ? sg_kmalloc+0x1a/0x30 [ 358.028009] [] sg_kmalloc+0x1a/0x30 [ 358.028023] [] __sg_alloc_table+0x74/0x180 [ 358.028035] [] ? sg_kfree+0x20/0x20 [ 358.028048] [] sg_alloc_table+0x1f/0x60 [ 358.028061] [] sg_alloc_table_from_pages+0x84/0x1f0 [ 358.028077] [] vb2_dma_sg_alloc+0x159/0x230 [videobuf2_dma_sg] [ 358.028095] [] __vb2_queue_alloc+0x10a/0x680 [videobuf2_core] [ 358.028113] [] __reqbufs.isra.14+0x220/0x3e0 [videobuf2_core] [ 358.028130] [] __vb2_init_fileio+0xbd/0x380 [videobuf2_core] [ 358.028147] [] __vb2_perform_fileio+0x5b3/0x6e0 [videobuf2_core] [ 358.028164] [] vb2_fop_read+0xb1/0x100 [videobuf2_core] [ 358.028184] [] v4l2_read+0x65/0xb0 [videodev] [ 358.028198] [] vfs_read+0x8f/0x170 [ 358.028210] [] SyS_read+0x41/0xb0 [ 358.028224] [] system_call_fastpath+0x16/0x1b [ 358.028234] Code: 66 90 e9 dc fd ff ff 0f 1f 40 00 41 8b 4d 68 e9 d5 fe ff ff 0f 1f 80 00 00 00 00 f0 41 80 4d 00 40 e9 03 ff ff ff 0f 1f 44 00 00 <0f> 0b 66 0f 1f 44 00 00 44 89 c6 4c 89 45 d0 e8 0c 82 ff ff 48 [ 358.028415] RIP [] new_slab+0x280/0x320 [ 358.028432] RSP [ 358.032208] ---[ end trace 6443240199c706e4 ]--- Signed-off-by: Hans Verkuil Acked-by: Marek Szyprowski Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 8d0622eb9b81ecad3b21055945828dd701c754b5 Author: Mauro Carvalho Chehab Date: Fri Sep 19 13:02:12 2014 -0300 media: em28xx: fix VBI handling logic commit c7854c2c5d692a329b4d9a9a73bcf36ae137ee7c upstream. When both VBI and video are streaming, and video stream is stopped, a subsequent trial to restart it will fail, because S_FMT will return -EBUSY. That prevents applications like zvbi to work properly. Please notice that, while this fix it fully for zvbi, the best is to get rid of streaming_users and res_get logic as a hole. However, this single-line patch is better to be merged at -stable. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit fcdc612e265e02828157152b33184eba96c49e29 Author: Hans Verkuil Date: Fri Sep 12 06:02:02 2014 -0300 media: adv7604: fix inverted condition commit 77639ff2b3404a913b8037d230a384798b854bae upstream. The log_status function should show HDMI information, but the test checking for an HDMI input was inverted. Fix this. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 829a664d1ff8fbd7798db9b0ceddba3a9a0e048d Author: Bimow Chen Date: Mon Aug 4 23:31:46 2014 -0300 media: af9033: update IT9135 tuner inittabs commit 0df6580c5fc115034de29aa52af5cf6bd83d37d8 upstream. Update IT9135 BX tuner config 60 and 61 inittabs. [crope@iki.fi: removed two reg writes from driver init itself] Signed-off-by: Bimow Chen Signed-off-by: Antti Palosaari Signed-off-by: Greg Kroah-Hartman Signed-off-by: Mauro Carvalho Chehab commit 94146fe354d6e5e24a1ac9c5091e28969a96a7bd Author: Hans Verkuil Date: Tue Aug 26 02:59:53 2014 -0300 media: cx18: fix kernel oops with tda8290 tuner commit 6a03dc92cc2edfa2257502557b9f714893987383 upstream. This was caused by an uninitialized setup.config field. Based on a suggestion from Devin Heitmueller. Signed-off-by: Hans Verkuil Thanks-to: Devin Heitmueller Reported-by: Scott Robinson Tested-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 994e79d27522f771fd7cf44e08ce8b9b2ee7f479 Author: Antti Palosaari Date: Sat Aug 9 01:03:14 2014 -0300 media: af9033: feed clock to RF tuner commit 9dc0f3fe3fe6b83b44e5920a0b143b4f96755b59 upstream. IT9135 RF tuner clock is coming from demodulator. We need enable it early in demod init, before any tuner I/O. Currently it is enabled by tuner driver itself, but it is too late and performance will be reduced as some registers are not updated correctly. Clock is disabled automatically when demod is put onto sleep. Cc: Bimow Chen Signed-off-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 5e80de308270994b0b7fcbef92f0da55e4008c6b Author: Malcolm Priestley Date: Tue Aug 5 06:19:16 2014 -0300 media: af9035: new IDs: add support for PCTV 78e and PCTV 79e commit a04646c045cab08a9e62b9be8f01ecbb0632d24e upstream. add the following IDs USB_PID_PCTV_78E (0x025a) for PCTV 78e USB_PID_PCTV_79E (0x0262) for PCTV 79e For these it9135 devices. Signed-off-by: Malcolm Priestley Cc: Antti Palosaari Signed-off-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 7dd9e7dc827eff4227c875d80aa099a988c5f6cd Author: Bimow Chen Date: Tue Aug 5 00:14:47 2014 -0300 media: it913x: init tuner on attach commit 01b461bbe74b89da8941f4c95711777d87b9172e upstream. That register is needed to program very first in order to operate correctly. [crope@iki.fi: returned sequence back, removed sleep, moved reg write earlier to prevent populating tuner ops in case of failure] Signed-off-by: Bimow Chen Signed-off-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 8f91119341c98f7645777985e23e34600957c234 Author: Lan Tianyu Date: Thu Sep 18 15:03:07 2014 +0800 cpufreq: fix cpufreq suspend/resume for intel_pstate commit 8e30444e153008e8eb3e74cbcb7a865bfcfb04a0 upstream. Cpufreq core introduces cpufreq_suspended flag to let cpufreq sysfs nodes across S2RAM/S2DISK. But the flag is only set in the cpufreq_suspend() for cpufreq drivers which have target or target_index callback. This skips intel_pstate driver. This patch is to set the flag before checking target or target_index callback. Fixes: 2f0aea936360 (cpufreq: suspend governors on system suspend/hibernate) Signed-off-by: Lan Tianyu [rjw: Subject] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 168d02c742eca20fabafddf49305a1e254be1a6d Author: Prarit Bhargava Date: Wed Sep 10 10:12:08 2014 -0400 cpufreq: release policy->rwsem on error commit 7106e02baed4a72fb23de56b02ad4d31daa74d95 upstream. While debugging a cpufreq-related hardware failure on a system I saw the following lockdep warning: ========================= [ BUG: held lock freed! ] 3.17.0-rc4+ #1 Tainted: G E ------------------------- insmod/2247 is freeing memory ffff88006e1b1400-ffff88006e1b17ff, with a lock still held there! (&policy->rwsem){+.+...}, at: [] __cpufreq_add_dev.isra.21+0x47d/0xb80 3 locks held by insmod/2247: #0: (subsys mutex#5){+.+.+.}, at: [] subsys_interface_register+0x69/0x120 #1: (cpufreq_rwsem){.+.+.+}, at: [] __cpufreq_add_dev.isra.21+0x73/0xb80 #2: (&policy->rwsem){+.+...}, at: [] __cpufreq_add_dev.isra.21+0x47d/0xb80 stack backtrace: CPU: 0 PID: 2247 Comm: insmod Tainted: G E 3.17.0-rc4+ #1 Hardware name: HP ProLiant MicroServer Gen8, BIOS J06 08/24/2013 0000000000000000 000000008f3063c4 ffff88006f87bb30 ffffffff8171b358 ffff88006bcf3750 ffff88006f87bb68 ffffffff810e09e1 ffff88006e1b1400 ffffea0001b86c00 ffffffff8156d327 ffff880073003500 0000000000000246 Call Trace: [] dump_stack+0x4d/0x66 [] debug_check_no_locks_freed+0x171/0x180 [] ? __cpufreq_add_dev.isra.21+0x427/0xb80 [] kfree+0xab/0x2b0 [] __cpufreq_add_dev.isra.21+0x427/0xb80 [] ? _raw_spin_unlock+0x27/0x40 [] ? pcc_cpufreq_do_osc+0x17f/0x17f [pcc_cpufreq] [] cpufreq_add_dev+0xe/0x10 [] subsys_interface_register+0xc1/0x120 [] cpufreq_register_driver+0x112/0x340 [] ? kfree+0xda/0x2b0 [] ? pcc_cpufreq_do_osc+0x17f/0x17f [pcc_cpufreq] [] pcc_cpufreq_init+0x4af/0xe81 [pcc_cpufreq] [] ? pcc_cpufreq_do_osc+0x17f/0x17f [pcc_cpufreq] [] do_one_initcall+0xd4/0x210 [] ? __vunmap+0xd2/0x120 [] load_module+0x1315/0x1b70 [] ? store_uevent+0x70/0x70 [] ? copy_module_from_fd.isra.44+0x129/0x180 [] SyS_finit_module+0xa6/0xd0 [] system_call_fastpath+0x16/0x1b cpufreq: __cpufreq_add_dev: ->get() failed insmod: ERROR: could not insert module pcc-cpufreq.ko: No such device The warning occurs in the __cpufreq_add_dev() code which does down_write(&policy->rwsem); ... if (cpufreq_driver->get && !cpufreq_driver->setpolicy) { policy->cur = cpufreq_driver->get(policy->cpu); if (!policy->cur) { pr_err("%s: ->get() failed\n", __func__); goto err_get_freq; } If cpufreq_driver->get(policy->cpu) returns an error we execute the code at err_get_freq, which does not up the policy->rwsem. This causes the lockdep warning. Trivial patch to up the policy->rwsem in the error path. After the patch has been applied, and an error occurs in the cpufreq_driver->get(policy->cpu) call we will now see cpufreq: __cpufreq_add_dev: ->get() failed cpufreq: __cpufreq_add_dev: ->get() failed modprobe: ERROR: could not insert 'pcc_cpufreq': No such device Fixes: 4e97b631f24c (cpufreq: Initialize governor for a new policy under policy->rwsem) Signed-off-by: Prarit Bhargava Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 512e6652813ab0ff04d351b6c31a42b8fd46e954 Author: Bjorn Helgaas Date: Fri Sep 19 11:08:40 2014 -0600 Revert "PCI: Make sure bus number resources stay within their parents bounds" commit 12d8706963f073fffad16c7c24160ef20d9aeaff upstream. This reverts commit 1820ffdccb9b ("PCI: Make sure bus number resources stay within their parents bounds") because it breaks some systems with LSI Logic FC949ES Fibre Channel Adapters, apparently by exposing a defect in those adapters. Dirk tested a Tyan VX50 (B4985) with this device that worked like this prior to 1820ffdccb9b: bus: [bus 00-7f] on node 0 link 1 ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-07]) pci 0000:00:0e.0: PCI bridge to [bus 0a] pci_bus 0000:0a: busn_res: can not insert [bus 0a] under [bus 00-07] (conflicts with (null) [bus 00-07]) pci 0000:0a:00.0: [1000:0646] type 00 class 0x0c0400 (FC adapter) Note that the root bridge [bus 00-07] aperture is wrong; this is a BIOS defect in the PCI0 _CRS method. But prior to 1820ffdccb9b, we didn't enforce that aperture, and the FC adapter worked fine at 0a:00.0. After 1820ffdccb9b, we notice that 00:0e.0's aperture is not contained in the root bridge's aperture, so we reconfigure it so it *is* contained: pci 0000:00:0e.0: bridge configuration invalid ([bus 0a-0a]), reconfiguring pci 0000:00:0e.0: PCI bridge to [bus 06-07] This effectively moves the FC device from 0a:00.0 to 07:00.0, which should be legal. But when we enumerate bus 06, the FC device doesn't respond, so we don't find anything. This is probably a defect in the FC device. Possible fixes (due to Yinghai): 1) Add a quirk to fix the _CRS information based on what amd_bus.c read from the hardware 2) Reset the FC device after we change its bus number 3) Revert 1820ffdccb9b Fix 1 would be relatively easy, but it does sweep the LSI FC issue under the rug. We might want to reconfigure bus numbers in the future for some other reason, e.g., hotplug, and then we could trip over this again. For that reason, I like fix 2, but we don't know whether it actually works, and we don't have a patch for it yet. This revert is fix 3, which also sweeps the LSI FC issue under the rug. Link: https://bugzilla.kernel.org/show_bug.cgi?id=84281 Reported-by: Dirk Gouders Tested-by: Dirk Gouders Signed-off-by: Bjorn Helgaas CC: Yinghai Lu Signed-off-by: Greg Kroah-Hartman commit aaf5b838f37899e41a7f3efcde0bda9ac3363c3c Author: Johannes Berg Date: Wed Jul 30 14:55:26 2014 +0200 nl80211: clear skb cb before passing to netlink commit bd8c78e78d5011d8111bc2533ee73b13a3bd6c42 upstream. In testmode and vendor command reply/event SKBs we use the skb cb data to store nl80211 parameters between allocation and sending. This causes the code for CONFIG_NETLINK_MMAP to get confused, because it takes ownership of the skb cb data when the SKB is handed off to netlink, and it doesn't explicitly clear it. Clear the skb cb explicitly when we're done and before it gets passed to netlink to avoid this issue. Reported-by: Assaf Azulay Reported-by: David Spinadel Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit de65ff5b13c766494c6a85c679e82377cf1bea9d Author: Tom Lendacky Date: Fri Sep 5 10:31:09 2014 -0500 crypto: ccp - Check for CCP before registering crypto algs commit c9f21cb6388898bfe69886d001316dae7ecc9a4b upstream. If the ccp is built as a built-in module, then ccp-crypto (whether built as a module or a built-in module) will be able to load and it will register its crypto algorithms. If the system does not have a CCP this will result in -ENODEV being returned whenever a command is attempted to be queued by the registered crypto algorithms. Add an API, ccp_present(), that checks for the presence of a CCP on the system. The ccp-crypto module can use this to determine if it should register it's crypto alogorithms. Reported-by: Scot Doyle Signed-off-by: Tom Lendacky Tested-by: Scot Doyle Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 526d1f369185226566cdc5718650006e8e6fff73 Author: David Hildenbrand Date: Thu Sep 18 11:04:31 2014 +0200 blk-mq: Avoid race condition with uninitialized requests commit 683d0e126232d898a481daa3a4ca032c2b1a9660 upstream. This patch should fix the bug reported in https://lkml.org/lkml/2014/9/11/249. We have to initialize at least the atomic_flags and the cmd_flags when allocating storage for the requests. Otherwise blk_mq_timeout_check() might dereference uninitialized pointers when racing with the creation of a request. Also move the reset of cmd_flags for the initializing code to the point where a request is freed. So we will never end up with pending flush request indicators that might trigger dereferences of invalid pointers in blk_mq_timeout_check(). Signed-off-by: David Hildenbrand Reported-by: Paulo De Rezende Pinatti Tested-by: Paulo De Rezende Pinatti Acked-by: Christian Borntraeger Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c1672332cb58921703d910b647bf9114a410fad7 Author: Anton Altaparmakov Date: Mon Sep 22 01:53:03 2014 +0100 Fix nasty 32-bit overflow bug in buffer i/o code. commit f2d5a94436cc7cc0221b9a81bba2276a25187dd3 upstream. On 32-bit architectures, the legacy buffer_head functions are not always handling the sector number with the proper 64-bit types, and will thus fail on 4TB+ disks. Any code that uses __getblk() (and thus bread(), breadahead(), sb_bread(), sb_breadahead(), sb_getblk()), and calls it using a 64-bit block on a 32-bit arch (where "long" is 32-bit) causes an inifinite loop in __getblk_slow() with an infinite stream of errors logged to dmesg like this: __find_get_block_slow() failed. block=6740375944, b_blocknr=2445408648 b_state=0x00000020, b_size=512 device sda1 blocksize: 512 Note how in hex block is 0x191C1F988 and b_blocknr is 0x91C1F988 i.e. the top 32-bits are missing (in this case the 0x1 at the top). This is because grow_dev_page() is broken and has a 32-bit overflow due to shifting the page index value (a pgoff_t - which is just 32 bits on 32-bit architectures) left-shifted as the block number. But the top bits to get lost as the pgoff_t is not type cast to sector_t / 64-bit before the shift. This patch fixes this issue by type casting "index" to sector_t before doing the left shift. Note this is not a theoretical bug but has been seen in the field on a 4TiB hard drive with logical sector size 512 bytes. This patch has been verified to fix the infinite loop problem on 3.17-rc5 kernel using a 4TB disk image mounted using "-o loop". Without this patch doing a "find /nt" where /nt is an NTFS volume causes the inifinite loop 100% reproducibly whilst with the patch it works fine as expected. Signed-off-by: Anton Altaparmakov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bd1328b42f93fb23ab468fa79cb0caf9d7cffb19 Author: Alex Deucher Date: Fri Sep 12 18:00:53 2014 -0400 drm/radeon/px: fix module unload commit 2e97140dd58cab8772bf77d73eabda213e45202d upstream. Use the new vga_switcheroo_fini_domain_pm_ops function to unregister the pm ops. Based on a patch from: Pali Rohár bug: https://bugzilla.kernel.org/show_bug.cgi?id=84431 Reviewed-by: Ben Skeggs Signed-off-by: Alex Deucher Signed-off-by: Pali Rohár Cc: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 97d30fa3524ff60b43d450012abe8f961d280478 Author: Alex Deucher Date: Fri Sep 12 18:06:56 2014 -0400 drm/nouveau/runpm: fix module unload commit 53beaa01e0fe8e4202f43485a03b32fcf5dfea74 upstream. Use the new vga_switcheroo_fini_domain_pm_ops function to unregister the pm ops. Based on a patch from: Pali Rohár bug: https://bugzilla.kernel.org/show_bug.cgi?id=84431 Reviewed-by: Ben Skeggs Signed-off-by: Alex Deucher Cc: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 4659be275b14d7d865573b9d82c8afdb23f875aa Author: Alex Deucher Date: Fri Sep 12 17:51:29 2014 -0400 vgaswitcheroo: add vga_switcheroo_fini_domain_pm_ops commit 766a53d059d1500c9755c8af017bd411bd8f1b20 upstream. Drivers should call this on unload to unregister pmops. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=84431 Reviewed-by: Ben Skeggs Signed-off-by: Alex Deucher Signed-off-by: Pali Rohár Cc: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 4e3a0d9d0f7497e89870989d7dd94370d585c3f0 Author: Bjorn Helgaas Date: Fri Sep 19 10:56:06 2014 -0600 Revert "PCI: Don't scan random busses in pci_scan_bridge()" commit 7a0b33d4a45d30b9a838fba4efcd80b7b57d4d16 upstream. This reverts commit fc1b253141b3 ("PCI: Don't scan random busses in pci_scan_bridge()") because it breaks CardBus on some machines. David tested a Dell Latitude D505 that worked like this prior to fc1b253141b3: pci 0000:00:1e.0: PCI bridge to [bus 01] pci 0000:01:01.0: CardBus bridge to [bus 02-05] Note that the 01:01.0 CardBus bridge has a bus number aperture of [bus 02-05], but those buses are all outside the 00:1e.0 PCI bridge bus number aperture, so accesses to buses 02-05 never reach CardBus. This is later patched up by yenta_fixup_parent_bridge(), which changes the subordinate bus number of the 00:1e.0 PCI bridge: pci_bus 0000:01: Raising subordinate bus# of parent bus (#01) from #01 to #05 With fc1b253141b3, pci_scan_bridge() fails immediately when it notices that we can't allocate a valid secondary bus number for the CardBus bridge, and CardBus doesn't work at all: pci 0000:01:01.0: can't allocate child bus 01 from [bus 01] I'd prefer to fix this by integrating the yenta_fixup_parent_bridge() logic into pci_scan_bridge() so we fix the bus number apertures up front. But I don't think we can do that before v3.17, so I'm going to revert this to avoid the problem while we're working on the long-term fix. Link: https://bugzilla.kernel.org/show_bug.cgi?id=83441 Link: http://lkml.kernel.org/r/1409303414-5196-1-git-send-email-david.henningsson@canonical.com Reported-by: David Henningsson Tested-by: David Henningsson Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit a4c5f39c22082dd53a95e2c63aa3d4ed9805fad4 Author: Bjorn Helgaas Date: Wed Sep 10 13:45:01 2014 -0600 PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device commit b440bde74f043c8ec31081cb59c9a53ade954701 upstream. Powering off a hot-pluggable device, e.g., with pci_set_power_state(D3cold), normally generates a hot-remove event that unbinds the driver. Some drivers expect to remain bound to a device even while they power it off and back on again. This can be dangerous, because if the device is removed or replaced while it is powered off, the driver doesn't know that anything changed. But some drivers accept that risk. Add pci_ignore_hotplug() for use by drivers that know their device cannot be removed. Using pci_ignore_hotplug() tells the PCI core that hot-plug events for the device should be ignored. The radeon and nouveau drivers use this to switch between a low-power, integrated GPU and a higher-power, higher-performance discrete GPU. They power off the unused GPU, but they want to remain bound to it. This is a reimplementation of f244d8b623da ("ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug") but extends it to work with both acpiphp and pciehp. This fixes a problem where systems with dual GPUs using the radeon drivers become unusable, freezing every few seconds (see bugzillas below). The resume of the radeon device may also fail, e.g., This fixes problems on dual GPU systems where the radeon driver becomes unusable because of problems while suspending the device, as in bug 79701: [drm] radeon: finishing device. radeon 0000:01:00.0: Userspace still has active objects ! radeon 0000:01:00.0: ffff8800cb4ec288 ffff8800cb4ec000 16384 4294967297 force free ... WARNING: CPU: 0 PID: 67 at /home/apw/COD/linux/drivers/gpu/drm/radeon/radeon_gart.c:234 radeon_gart_unbind+0xd2/0xe0 [radeon]() trying to unbind memory from uninitialized GART ! or while resuming it, as in bug 77261: radeon 0000:01:00.0: ring 0 stalled for more than 10158msec radeon 0000:01:00.0: GPU lockup ... radeon 0000:01:00.0: GPU pci config reset pciehp 0000:00:01.0:pcie04: Card not present on Slot(1-1) radeon 0000:01:00.0: GPU reset succeeded, trying to resume *ERROR* radeon: dpm resume failed radeon 0000:01:00.0: Wait for MC idle timedout ! Link: https://bugzilla.kernel.org/show_bug.cgi?id=77261 Link: https://bugzilla.kernel.org/show_bug.cgi?id=79701 Reported-by: Shawn Starr Reported-by: Jose P. Signed-off-by: Bjorn Helgaas Acked-by: Alex Deucher Acked-by: Rajat Jain Acked-by: Rafael J. Wysocki Acked-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit e7a0374e61a8250995270902f5b023ec47f7f1f0 Author: Zhiqiang Zhang Date: Fri Sep 26 15:44:22 2014 +0800 arm: armv7: perf: fix armv7 ref-cycles error ref-cycles event is specially to Intel core, but can still used in arm architecture with the wrong return value with 3.10 stable. this patch fix the bug and make it return NOT SUPPORTED distinctly. In upstream this bug has been fixed by other way, which changes more than one file and more than 1000 lines. the primary commit is 6b7658ec8a100b608e59e3cde353434db51f5be0. besides we can not simply cherry-pick. Signed-off-by: Zhiqiang Zhang Cc: Mark Rutland Cc: Christopher Covington Signed-off-by: Greg Kroah-Hartman commit c850c07897da2b283783033165f6b7ffda82ead5 Author: Cong Wang Date: Tue Sep 2 15:27:20 2014 -0700 perf: Fix a race condition in perf_remove_from_context() commit 3577af70a2ce4853d58e57d832e687d739281479 upstream. We saw a kernel soft lockup in perf_remove_from_context(), it looks like the `perf` process, when exiting, could not go out of the retry loop. Meanwhile, the target process was forking a child. So either the target process should execute the smp function call to deactive the event (if it was running) or it should do a context switch which deactives the event. It seems we optimize out a context switch in perf_event_context_sched_out(), and what's more important, we still test an obsolete task pointer when retrying, so no one actually would deactive that event in this situation. Fix it directly by reloading the task pointer in perf_remove_from_context(). This should cure the above soft lockup. Signed-off-by: Cong Wang Signed-off-by: Cong Wang Signed-off-by: Peter Zijlstra Cc: Paul Mackerras Cc: Arnaldo Carvalho de Melo Cc: Linus Torvalds Link: http://lkml.kernel.org/r/1409696840-843-1-git-send-email-xiyou.wangcong@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit f673015a73e1dab37e67e468e279a62d67b2672b Author: Krzysztof Hałasa Date: Thu Sep 18 15:12:02 2014 +0200 Fix unbalanced mutex in dma_pool_create(). commit 153a9f131f50420b7ce008c94f1c6374cbc460d7 upstream. dma_pool_create() needs to unlock the mutex in error case. The bug was introduced in the 3.16 by commit cc6b664aa26d ("mm/dmapool.c: remove redundant NULL check for dev in dma_pool_create()")/ Signed-off-by: Krzysztof Hałasa Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 30b9f42a25842ddcb389ee917a2f95348cfa550a Author: Qipan Li Date: Tue Sep 2 17:01:03 2014 +0800 spi: sirf: enable RX_IO_DMA_INT interrupt commit f2a08b404691ef3e7be6ce81c185335cfc68b6db upstream. in spi interrupt handler, we need check RX_IO_DMA status to ensure rx fifo have received the specify count data. if not set, the while statement in spi isr function will keep loop, at last, make the kernel hang. [The code is actually there in the interrupt handler but apparently it needs the interrupt unmasking so the handler sees the status -- broonie] Signed-off-by: Qipan Li Signed-off-by: Barry Song Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2ac3e493a3e353d0fc1b69ead7952d436638453f Author: Axel Lin Date: Sun Aug 31 12:47:06 2014 +0800 spi: dw: Don't use devm_kzalloc in master->setup callback commit a97c883a16da7e0691a3be5465926c92a8da4da6 upstream. device_add() expects that any memory allocated via devm_* API is only done in the device's probe function. Fix below boot warning: WARNING: CPU: 1 PID: 1 at drivers/base/dd.c:286 driver_probe_device+0x2b4/0x2f4() Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.16.0-10474-g835c90b-dirty #160 [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [] (show_stack) from [] (dump_stack+0x7c/0x98) [] (dump_stack) from [] (warn_slowpath_common+0x78/0x9c) [] (warn_slowpath_common) from [] (warn_slowpath_null+0x2c/0x34) [] (warn_slowpath_null) from [] (driver_probe_device+0x2b4/0x2f4) [] (driver_probe_device) from [] (__device_attach+0x50/0x54) [] (__device_attach) from [] (bus_for_each_drv+0x54/0x9c) [] (bus_for_each_drv) from [] (device_attach+0x84/0x90) [] (device_attach) from [] (bus_probe_device+0x94/0xb8) [] (bus_probe_device) from [] (device_add+0x434/0x4fc) [] (device_add) from [] (spi_add_device+0x98/0x164) [] (spi_add_device) from [] (spi_register_master+0x598/0x768) [] (spi_register_master) from [] (devm_spi_register_master+0x40/0x80) [] (devm_spi_register_master) from [] (dw_spi_add_host+0x1a8/0x258) [] (dw_spi_add_host) from [] (dw_spi_mmio_probe+0x1d4/0x294) [] (dw_spi_mmio_probe) from [] (platform_drv_probe+0x3c/0x6c) [] (platform_drv_probe) from [] (driver_probe_device+0xec/0x2f4) [] (driver_probe_device) from [] (__driver_attach+0x9c/0xa0) [] (__driver_attach) from [] (bus_for_each_dev+0x64/0x98) [] (bus_for_each_dev) from [] (driver_attach+0x2c/0x30) [] (driver_attach) from [] (bus_add_driver+0xdc/0x1f4) [] (bus_add_driver) from [] (driver_register+0x88/0x104) [] (driver_register) from [] (__platform_driver_register+0x58/0x6c) [] (__platform_driver_register) from [] (dw_spi_mmio_driver_init+0x18/0x20) [] (dw_spi_mmio_driver_init) from [] (do_one_initcall+0x90/0x1d4) [] (do_one_initcall) from [] (kernel_init_freeable+0x178/0x248) [] (kernel_init_freeable) from [] (kernel_init+0x18/0xfc) [] (kernel_init) from [] (ret_from_fork+0x14/0x20) Reported-by: Thor Thayer Signed-off-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit f9078a24a5fd18aef8a90e8964024ff352ad04e2 Author: Axel Lin Date: Sun Aug 31 12:44:09 2014 +0800 spi: fsl: Don't use devm_kzalloc in master->setup callback commit d9f26748128c73ec6bed2846ca52fb1c2edc3ced upstream. device_add() expects that any memory allocated via devm_* API is only done in the device's probe function. Fix below boot warning: [ 3.092348] WARNING: at drivers/base/dd.c:286 [ 3.096637] Modules linked in: [ 3.099697] CPU: 0 PID: 25 Comm: kworker/u2:1 Tainted: G W 3.16.1-s3k-drv-999-svn5771_knld-999 #158 [ 3.109610] Workqueue: deferwq deferred_probe_work_func [ 3.114736] task: c787f020 ti: c790c000 task.ti: c790c000 [ 3.120062] NIP: c01df158 LR: c01df144 CTR: 00000000 [ 3.124983] REGS: c790db30 TRAP: 0700 Tainted: G W (3.16.1-s3k-drv-999-svn5771_knld-999) [ 3.134162] MSR: 00029032 CR: 22002082 XER: 20000000 [ 3.140703] [ 3.140703] GPR00: 00000001 c790dbe0 c787f020 00000044 00000054 00000308 c056da0e 20737069 [ 3.140703] GPR08: 33323736 000ebfe0 00000308 000ebfdf 22002082 00000000 c046c5a0 c046c608 [ 3.140703] GPR16: c046c614 c046c620 c046c62c c046c638 c046c648 c046c654 c046c68c c046c6c4 [ 3.140703] GPR24: 00000000 00000000 00000003 c0401aa0 c0596638 c059662c c054e7a8 c7996800 [ 3.170102] NIP [c01df158] driver_probe_device+0xf8/0x334 [ 3.175431] LR [c01df144] driver_probe_device+0xe4/0x334 [ 3.180633] Call Trace: [ 3.183093] [c790dbe0] [c01df144] driver_probe_device+0xe4/0x334 (unreliable) [ 3.190147] [c790dc10] [c01dd15c] bus_for_each_drv+0x7c/0xc0 [ 3.195741] [c790dc40] [c01df5fc] device_attach+0xcc/0xf8 [ 3.201076] [c790dc60] [c01dd6d4] bus_probe_device+0xb4/0xc4 [ 3.206666] [c790dc80] [c01db9f8] device_add+0x270/0x564 [ 3.211923] [c790dcc0] [c0219e84] spi_add_device+0xc0/0x190 [ 3.217427] [c790dce0] [c021a79c] spi_register_master+0x720/0x834 [ 3.223455] [c790dd40] [c021cb48] of_fsl_spi_probe+0x55c/0x614 [ 3.229234] [c790dda0] [c01e0d2c] platform_drv_probe+0x30/0x74 [ 3.234987] [c790ddb0] [c01df18c] driver_probe_device+0x12c/0x334 [ 3.241008] [c790dde0] [c01dd15c] bus_for_each_drv+0x7c/0xc0 [ 3.246602] [c790de10] [c01df5fc] device_attach+0xcc/0xf8 [ 3.251937] [c790de30] [c01dd6d4] bus_probe_device+0xb4/0xc4 [ 3.257536] [c790de50] [c01de9d8] deferred_probe_work_func+0x98/0xe0 [ 3.263816] [c790de70] [c00305b8] process_one_work+0x18c/0x440 [ 3.269577] [c790dea0] [c0030a00] worker_thread+0x194/0x67c [ 3.275105] [c790def0] [c0039198] kthread+0xd0/0xe4 [ 3.279911] [c790df40] [c000c6d0] ret_from_kernel_thread+0x5c/0x64 [ 3.285970] Instruction dump: [ 3.288900] 80de0000 419e01d0 3b7b0038 3c60c046 7f65db78 38635264 48211b99 813f00a0 [ 3.296559] 381f00a0 7d290278 3169ffff 7c0b4910 <0f000000> 93df0044 7fe3fb78 4bfffd4d Reported-by: leroy christophe Signed-off-by: Axel Lin Tested-by: Christophe Leroy Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e60309c85cdb1b50de7f146e0403d32d5ea40ca3 Author: Matan Barak Date: Tue Sep 2 15:32:34 2014 +0300 IB/core: When marshaling uverbs path, clear unused fields commit a59c5850f09b4c2d6ad2fc47e5e1be8d654529d6 upstream. When marsheling a user path to the kernel struct ib_sa_path, need to zero smac, dmac and set the vlan id to the "no vlan" value. Fixes: dd5f03beb4f7 ("IB/core: Ethernet L2 attributes in verbs/cm structures") Reported-by: Aleksey Senin Signed-off-by: Matan Barak Signed-off-by: Or Gerlitz Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit a85dce19c0e4e78652aa9376754d236096fe1014 Author: Moni Shoua Date: Thu Aug 21 14:28:38 2014 +0300 IB/mlx4: Don't duplicate the default RoCE GID commit f5c4834d9328c4ed9fe5dcbec6128d6da16db69a upstream. When reading the IPv6 addresses from the net-device, make sure to avoid adding a duplicate entry to the GID table because of equality between the default GID we generate and the default IPv6 link-local address of the device. Fixes: acc4fccf4eff ("IB/mlx4: Make sure GID index 0 is always occupied") Signed-off-by: Moni Shoua Signed-off-by: Or Gerlitz Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 23636720912e558ae0078cbd8a384c3790dea831 Author: Moni Shoua Date: Thu Aug 21 14:28:37 2014 +0300 IB/mlx4: Avoid null pointer dereference in mlx4_ib_scan_netdevs() commit e381835cf1b8e3b2857277dbc3b77d8c5350f70a upstream. When Ethernet netdev is not present for a port (e.g. when the link layer type of the port is InfiniBand) it's possible to dereference a null pointer when we do netdevice scanning. To fix that, we move a section of code that needs to run only when netdev is present to a proper if () statement. Fixes: ad4885d279b6 ("IB/mlx4: Build the port IBoE GID table properly under bonding") Reported-by: Dan Carpenter Signed-off-by: Moni Shoua Signed-off-by: Or Gerlitz Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit f59c9cae6a4bc28d9ae4bd05ec1caa5795a231ab Author: Mike Marciniszyn Date: Fri Sep 19 08:32:19 2014 -0400 IB/qib: Correct reference counting in debugfs qp_stats commit 85cbb7c728bf39c45a9789b88c9471c0d7a58b0e upstream. This particular reference count is not needed with the rcu protection, and the current code leaks a reference count, causing a hang in qib_qp_destroy(). Reviewed-by: Dennis Dalessandro Signed-off-by: Mike Marciniszyn Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 778c29354bf7566af2c9a452933618758e32ef83 Author: Al Viro Date: Fri Sep 12 20:56:04 2014 +0100 GFS2: fix d_splice_alias() misuses commit cfb2f9d5c921e38b0f12bb26fed10b877664444d upstream. Callers of d_splice_alias(dentry, inode) don't need iput(), neither on success nor on failure. Either the reference to inode is stored in a previously negative dentry, or it's dropped. In either case inode reference the caller used to hold is consumed. __gfs2_lookup() does iput() in case when d_splice_alias() has failed. Double iput() if we ever hit that. And gfs2_create_inode() ends up not only with double iput(), but with link count dropped to zero - on an inode it has just found in directory. Signed-off-by: Al Viro Signed-off-by: Steven Whitehouse Signed-off-by: Greg Kroah-Hartman commit 60ede3e7d31ef63d8ed1ebc847b0290ad6f3f5f7 Author: Amit Shah Date: Sun Jul 27 07:35:01 2014 +0930 Revert "hwrng: virtio - ensure reads happen after successful probe" commit eeec626366ffe558fc3d5685bd2b49a962acf57d upstream. This reverts commit e052dbf554610e2104c5a7518c4d8374bed701bb. Now that we use the virtio ->scan() function to register with the hwrng core, we will not get read requests till probe is successfully finished. So revert the workaround we had in place to refuse read requests while we were not yet setup completely. Signed-off-by: Amit Shah Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit 5590b04b7a4fa2400f4d6ccec3c4d6166fab52cf Author: Amit Shah Date: Sun Jul 27 07:34:01 2014 +0930 virtio: rng: delay hwrng_register() till driver is ready commit 5c06273401f2eb7b290cadbae18ee00f8f65e893 upstream. Instead of calling hwrng_register() in the probe routing, call it in the scan routine. This ensures that when hwrng_register() is successful, and it requests a few random bytes to seed the kernel's pool at init, we're ready to service that request. This will also enable us to remove the workaround added previously to check whether probe was completed, and only then ask for data from the host. The revert follows in the next commit. There's a slight behaviour change here on unsuccessful hwrng_register(). Previously, when hwrng_register() failed, the probe() routine would fail, and the vqs would be torn down, and driver would be marked not initialized. Now, the vqs will remain initialized, driver would be marked initialized as well, but won't be available in the list of RNGs available to hwrng core. To fix the failures, the procedure remains the same, i.e. unload and re-load the module, and hope things succeed the next time around. Signed-off-by: Amit Shah Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit 6ba3934df8b88f6593da479e1418c8219d4f5396 Author: Richard Larocque Date: Tue Sep 9 18:31:05 2014 -0700 alarmtimer: Lock k_itimer during timer callback commit 474e941bed9262f5fa2394f9a4a67e24499e5926 upstream. Locks the k_itimer's it_lock member when handling the alarm timer's expiry callback. The regular posix timers defined in posix-timers.c have this lock held during timout processing because their callbacks are routed through posix_timer_fn(). The alarm timers follow a different path, so they ought to grab the lock somewhere else. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Richard Cochran Cc: Prarit Bhargava Cc: Sharvil Nanavati Signed-off-by: Richard Larocque Signed-off-by: John Stultz Signed-off-by: Greg Kroah-Hartman commit f11d225925676e7fa5e95caa3c3116bfb2caa0b2 Author: Richard Larocque Date: Tue Sep 9 18:31:04 2014 -0700 alarmtimer: Do not signal SIGEV_NONE timers commit 265b81d23a46c39df0a735a3af4238954b41a4c2 upstream. Avoids sending a signal to alarm timers created with sigev_notify set to SIGEV_NONE by checking for that special case in the timeout callback. The regular posix timers avoid sending signals to SIGEV_NONE timers by not scheduling any callbacks for them in the first place. Although it would be possible to do something similar for alarm timers, it's simpler to handle this as a special case in the timeout. Prior to this patch, the alarm timer would ignore the sigev_notify value and try to deliver signals to the process anyway. Even worse, the sanity check for the value of sigev_signo is skipped when SIGEV_NONE was specified, so the signal number could be bogus. If sigev_signo was an unitialized value (as it often would be if SIGEV_NONE is used), then it's hard to predict which signal will be sent. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Richard Cochran Cc: Prarit Bhargava Cc: Sharvil Nanavati Signed-off-by: Richard Larocque Signed-off-by: John Stultz Signed-off-by: Greg Kroah-Hartman commit bffe42489d9c6a6dc80e323b4134319e1473799a Author: Richard Larocque Date: Tue Sep 9 18:31:03 2014 -0700 alarmtimer: Return relative times in timer_gettime commit e86fea764991e00a03ff1e56409ec9cacdbda4c9 upstream. Returns the time remaining for an alarm timer, rather than the time at which it is scheduled to expire. If the timer has already expired or it is not currently scheduled, the it_value's members are set to zero. This new behavior matches that of the other posix-timers and the POSIX specifications. This is a change in user-visible behavior, and may break existing applications. Hopefully, few users rely on the old incorrect behavior. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Richard Cochran Cc: Prarit Bhargava Cc: Sharvil Nanavati Signed-off-by: Richard Larocque [jstultz: minor style tweak] Signed-off-by: John Stultz Signed-off-by: Greg Kroah-Hartman commit 79b9b729dbe6f0c7e51404ce8298b297ede8c79b Author: John David Anglin Date: Mon Sep 22 20:54:50 2014 -0400 parisc: Only use -mfast-indirect-calls option for 32-bit kernel builds commit d26a7730b5874a5fa6779c62f4ad7c5065a94723 upstream. In spite of what the GCC manual says, the -mfast-indirect-calls has never been supported in the 64-bit parisc compiler. Indirect calls have always been done using function descriptors irrespective of the -mfast-indirect-calls option. Recently, it was noticed that a function descriptor was always requested when the -mfast-indirect-calls option was specified. This caused problems when the option was used in application code and doesn't make any sense because the whole point of the option is to avoid using a function descriptor for indirect calls. Fixing this broke 64-bit kernel builds. I will fix GCC but for now we need the attached change. This results in the same kernel code as before. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 43ed39e4caf1e8ef3e3eae1ea0f1a81c098ec338 Author: Guy Martin Date: Fri Sep 12 18:02:34 2014 +0200 parisc: Implement new LWS CAS supporting 64 bit operations. commit 89206491201cbd1571009b36292af781cef74c1b upstream. The current LWS cas only works correctly for 32bit. The new LWS allows for CAS operations of variable size. Signed-off-by: Guy Martin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 8ed0282d408cc61c469acae6fc89499db7ed8bd2 Author: Al Viro Date: Sat Sep 13 21:55:46 2014 -0400 don't bugger nd->seq on set_root_rcu() from follow_dotdot_rcu() commit 7bd88377d482e1eae3c5329b12e33cfd664fa6a9 upstream. return the value instead, and have path_init() do the assignment. Broken by "vfs: Fix absolute RCU path walk failures due to uninitialized seq number", which was Cc-stable with 2.6.38+ as destination. This one should go where it went. To avoid dummy value returned in case when root is already set (it would do no harm, actually, since the only caller that doesn't ignore the return value is guaranteed to have nd->root *not* set, but it's more obvious that way), lift the check into callers. And do the same to set_root(), to keep them in sync. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit f60133a908dcd92e2a3d8ff1bdd538c4ea049fbf Author: Richard Genoud Date: Wed Sep 3 18:09:26 2014 +0200 tty/serial: at91: BUG: disable interrupts when !UART_ENABLE_MS() commit 35b675b9100fc38f58cb75b30e422ecd342519a8 upstream. In set_termios(), interrupts where not disabled if UART_ENABLE_MS() was false. Tested on at91sam9g35. Signed-off-by: Richard Genoud Reviewed-by: Peter Hurley Acked-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit 4e43bbd4ab386a70bca84000943254f6ccefce77 Author: Michael Ellerman Date: Thu Aug 7 15:36:18 2014 +1000 powerpc: Add smp_mb()s to arch_spin_unlock_wait() commit 78e05b1421fa41ae8457701140933baa5e7d9479 upstream. Similar to the previous commit which described why we need to add a barrier to arch_spin_is_locked(), we have a similar problem with spin_unlock_wait(). We need a barrier on entry to ensure any spinlock we have previously taken is visibly locked prior to the load of lock->slock. It's also not clear if spin_unlock_wait() is intended to have ACQUIRE semantics. For now be conservative and add a barrier on exit to give it ACQUIRE semantics. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 2dd10ce8d0fe59b7171f1709c2592ef70d5f4a1f Author: Michael Ellerman Date: Thu Aug 7 15:36:17 2014 +1000 powerpc: Add smp_mb() to arch_spin_is_locked() commit 51d7d5205d3389a32859f9939f1093f267409929 upstream. The kernel defines the function spin_is_locked(), which can be used to check if a spinlock is currently locked. Using spin_is_locked() on a lock you don't hold is obviously racy. That is, even though you may observe that the lock is unlocked, it may become locked at any time. There is (at least) one exception to that, which is if two locks are used as a pair, and the holder of each checks the status of the other before doing any update. Assuming *A and *B are two locks, and *COUNTER is a shared non-atomic value: The first CPU does: spin_lock(*A) if spin_is_locked(*B) # nothing else smp_mb() LOAD r = *COUNTER r++ STORE *COUNTER = r spin_unlock(*A) And the second CPU does: spin_lock(*B) if spin_is_locked(*A) # nothing else smp_mb() LOAD r = *COUNTER r++ STORE *COUNTER = r spin_unlock(*B) Although this is a strange locking construct, it should work. It seems to be understood, but not documented, that spin_is_locked() is not a memory barrier, so in the examples above and below the caller inserts its own memory barrier before acting on the result of spin_is_locked(). For now we assume spin_is_locked() is implemented as below, and we break it out in our examples: bool spin_is_locked(*LOCK) { LOAD l = *LOCK return l.locked } Our intuition is that there should be no problem even if the two code sequences run simultaneously such as: CPU 0 CPU 1 ================================================== spin_lock(*A) spin_lock(*B) LOAD b = *B LOAD a = *A if b.locked # true if a.locked # true # nothing # nothing spin_unlock(*A) spin_unlock(*B) If one CPU gets the lock before the other then it will do the update and the other CPU will back off: CPU 0 CPU 1 ================================================== spin_lock(*A) LOAD b = *B spin_lock(*B) if b.locked # false LOAD a = *A else if a.locked # true smp_mb() # nothing LOAD r1 = *COUNTER spin_unlock(*B) r1++ STORE *COUNTER = r1 spin_unlock(*A) However in reality spin_lock() itself is not indivisible. On powerpc we implement it as a load-and-reserve and store-conditional. Ignoring the retry logic for the lost reservation case, it boils down to: spin_lock(*LOCK) { LOAD l = *LOCK l.locked = true STORE *LOCK = l ACQUIRE_BARRIER } The ACQUIRE_BARRIER is required to give spin_lock() ACQUIRE semantics as defined in memory-barriers.txt: This acts as a one-way permeable barrier. It guarantees that all memory operations after the ACQUIRE operation will appear to happen after the ACQUIRE operation with respect to the other components of the system. On modern powerpc systems we use lwsync for ACQUIRE_BARRIER. lwsync is also know as "lightweight sync", or "sync 1". As described in Power ISA v2.07 section B.2.1.1, in this scenario the lwsync is not the barrier itself. It instead causes the LOAD of *LOCK to act as the barrier, preventing any loads or stores in the locked region from occurring prior to the load of *LOCK. Whether this behaviour is in accordance with the definition of ACQUIRE semantics in memory-barriers.txt is open to discussion, we may switch to a different barrier in future. What this means in practice is that the following can occur: CPU 0 CPU 1 ================================================== LOAD a = *A LOAD b = *B a.locked = true b.locked = true LOAD b = *B LOAD a = *A STORE *A = a STORE *B = b if b.locked # false if a.locked # false else else smp_mb() smp_mb() LOAD r1 = *COUNTER LOAD r2 = *COUNTER r1++ r2++ STORE *COUNTER = r1 STORE *COUNTER = r2 # Lost update spin_unlock(*A) spin_unlock(*B) That is, the load of *B can occur prior to the store that makes *A visibly locked. And similarly for CPU 1. The result is both CPUs hold their lock and believe the other lock is unlocked. The easiest fix for this is to add a full memory barrier to the start of spin_is_locked(), so adding to our previous definition would give us: bool spin_is_locked(*LOCK) { smp_mb() LOAD l = *LOCK return l.locked } The new barrier orders the store to the lock we are locking vs the load of the other lock: CPU 0 CPU 1 ================================================== LOAD a = *A LOAD b = *B a.locked = true b.locked = true STORE *A = a STORE *B = b smp_mb() smp_mb() LOAD b = *B LOAD a = *A if b.locked # true if a.locked # true # nothing # nothing spin_unlock(*A) spin_unlock(*B) Although the above example is theoretical, there is code similar to this example in sem_lock() in ipc/sem.c. This commit in addition to the next commit appears to be a fix for crashes we are seeing in that code where we believe this race happens in practice. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit cc8dcb6944fd20dffaca942a1235c0f54220232c Author: Anton Blanchard Date: Tue Aug 26 12:44:15 2014 +1000 powerpc/perf: Fix ABIv2 kernel backtraces commit 85101af13bb854a6572fa540df7c7201958624b9 upstream. ABIv2 kernels are failing to backtrace through the kernel. An example: 39.30% readseek2_proce [kernel.kallsyms] [k] find_get_entry | --- find_get_entry __GI___libc_read The problem is in valid_next_sp() where we check that the new stack pointer is at least STACK_FRAME_OVERHEAD below the previous one. ABIv1 has a minimum stack frame size of 112 bytes consisting of 48 bytes and 64 bytes of parameter save area. ABIv2 changes that to 32 bytes with no paramter save area. STACK_FRAME_OVERHEAD is in theory the minimum stack frame size, but we over 240 uses of it, some of which assume that it includes space for the parameter area. We need to work through all our stack defines and rationalise them but let's fix perf now by creating STACK_FRAME_MIN_SIZE and using in valid_next_sp(). This fixes the issue: 30.64% readseek2_proce [kernel.kallsyms] [k] find_get_entry | --- find_get_entry pagecache_get_page generic_file_read_iter new_sync_read vfs_read sys_read syscall_exit __GI___libc_read Reported-by: Aneesh Kumar K.V Signed-off-by: Anton Blanchard Signed-off-by: Greg Kroah-Hartman commit 981b26114255f6908ca0570550b834f9ab71503e Author: Johannes Stezenbach Date: Fri Sep 12 22:36:51 2014 +0200 ath9k_htc: fix random decryption failure commit d21ccfd0a60ea3dece3e1d142f52694abf87a0b1 upstream. In v3.15 the driver stopped to accept network packets after successful authentification, which could be worked around by passing the nohwcrypt=1 module parameter. This was not reproducible by everyone, and showed random behaviour in some tests. It was caused by an uninitialized variable introduced in 4ed1a8d4a257 ("ath9k_htc: use ath9k_cmn_rx_accept") and used in 341b29b9cd2f ("ath9k_htc: use ath9k_cmn_rx_skb_postprocess"). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=78581 Fixes: 341b29b9cd2f ("ath9k_htc: use ath9k_cmn_rx_skb_postprocess") Signed-off-by: Johannes Stezenbach Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 6b2a8bf73fc73732e869865baafdcfcc16d7a9d4 Author: Arend van Spriel Date: Fri Sep 12 16:19:30 2014 +0200 brcmfmac: handle IF event for P2P_DEVICE interface commit 87c4790330810fe5caf0172d9320cf24ef19cebe upstream. The firmware notifies about interface changes through the IF event which has a NO_IF flag that means host can ignore the event. This behaviour was introduced in the driver by: commit 2ee8382fc6c763c76396a6aaff77a27089eed3aa Author: Arend van Spriel Date: Sat Aug 10 12:27:24 2013 +0200 brcmfmac: ignore IF event if firmware indicates it It turns out that the IF event for the P2P_DEVICE also has this flag set, but the event should not be ignored in this scenario. The mentioned commit caused a regression in 3.12 kernel in creation of the P2P_DEVICE interface. Reviewed-by: Hante Meuleman Reviewed-by: Franky (Zhenhui) Lin Reviewed-by: Daniel (Deognyoun) Kim Reviewed-by: Pieter-Paul Giesberts Signed-off-by: Arend van Spriel Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit f99234e13c7cec10453aecbda179c96a5b0778f5 Author: Wanpeng Li Date: Wed Sep 24 16:38:05 2014 +0800 sched: Fix unreleased llc_shared_mask bit during CPU hotplug commit 03bd4e1f7265548832a76e7919a81f3137c44fd1 upstream. The following bug can be triggered by hot adding and removing a large number of xen domain0's vcpus repeatedly: BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: [..] find_busiest_group PGD 5a9d5067 PUD 13067 PMD 0 Oops: 0000 [#3] SMP [...] Call Trace: load_balance ? _raw_spin_unlock_irqrestore idle_balance __schedule schedule schedule_timeout ? lock_timer_base schedule_timeout_uninterruptible msleep lock_device_hotplug_sysfs online_store dev_attr_store sysfs_write_file vfs_write SyS_write system_call_fastpath Last level cache shared mask is built during CPU up and the build_sched_domain() routine takes advantage of it to setup the sched domain CPU topology. However, llc_shared_mask is not released during CPU disable, which leads to an invalid sched domainCPU topology. This patch fix it by releasing the llc_shared_mask correctly during CPU disable. Yasuaki also reported that this can happen on real hardware: https://lkml.org/lkml/2014/7/22/1018 His case is here: == Here is an example on my system. My system has 4 sockets and each socket has 15 cores and HT is enabled. In this case, each core of sockes is numbered as follows: | CPU# Socket#0 | 0-14 , 60-74 Socket#1 | 15-29, 75-89 Socket#2 | 30-44, 90-104 Socket#3 | 45-59, 105-119 Then llc_shared_mask of CPU#30 has 0x3fff80000001fffc0000000. It means that last level cache of Socket#2 is shared with CPU#30-44 and 90-104. When hot-removing socket#2 and #3, each core of sockets is numbered as follows: | CPU# Socket#0 | 0-14 , 60-74 Socket#1 | 15-29, 75-89 But llc_shared_mask is not cleared. So llc_shared_mask of CPU#30 remains having 0x3fff80000001fffc0000000. After that, when hot-adding socket#2 and #3, each core of sockets is numbered as follows: | CPU# Socket#0 | 0-14 , 60-74 Socket#1 | 15-29, 75-89 Socket#2 | 30-59 Socket#3 | 90-119 Then llc_shared_mask of CPU#30 becomes 0x3fff8000fffffffc0000000. It means that last level cache of Socket#2 is shared with CPU#30-59 and 90-104. So the mask has the wrong value. Signed-off-by: Wanpeng Li Tested-by: Linn Crosetto Reviewed-by: Borislav Petkov Reviewed-by: Toshi Kani Reviewed-by: Yasuaki Ishimatsu Cc: David Rientjes Cc: Prarit Bhargava Cc: Steven Rostedt Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1411547885-48165-1-git-send-email-wanpeng.li@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ffa16dcb25fe6813e1eafbb921a0021cdca0a310 Author: Peter Feiner Date: Thu Sep 25 16:05:29 2014 -0700 mm: softdirty: keep bit when zapping file pte commit dbab31aa2ceec2d201966fa0b552f151310ba5f4 upstream. This fixes the same bug as b43790eedd31 ("mm: softdirty: don't forget to save file map softdiry bit on unmap") and 9aed8614af5a ("mm/memory.c: don't forget to set softdirty on file mapped fault") where the return value of pte_*mksoft_dirty was being ignored. To be sure that no other pte/pmd "mk" function return values were being ignored, I annotated the functions in arch/x86/include/asm/pgtable.h with __must_check and rebuilt. The userspace effect of this bug is that the softdirty mark might be lost if a file mapped pte get zapped. Signed-off-by: Peter Feiner Acked-by: Cyrill Gorcunov Cc: Pavel Emelyanov Cc: Jamie Liu Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 152f5bedd152f978feb08c1fd89c4b80ee32b057 Author: Fabian Frederick Date: Thu Sep 25 16:05:27 2014 -0700 fs/cachefiles: add missing \n to kerror conversions commit 6ff66ac77aeaa9c13db28784e1c50c027a1f487b upstream. Commit 0227d6abb378 ("fs/cachefiles: replace kerror by pr_err") didn't include newline featuring in original kerror definition Signed-off-by: Fabian Frederick Reported-by: David Howells Acked-by: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f5eae161fa5737ffa701d267d6f226ca2edb7ada Author: David Rientjes Date: Thu Sep 25 16:05:20 2014 -0700 mm, slab: initialize object alignment on cache creation commit d4a5fca592b9ab52b90bb261a90af3c8f53be011 upstream. Since commit 4590685546a3 ("mm/sl[aou]b: Common alignment code"), the "ralign" automatic variable in __kmem_cache_create() may be used as uninitialized. The proper alignment defaults to BYTES_PER_WORD and can be overridden by SLAB_RED_ZONE or the alignment specified by the caller. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=85031 Signed-off-by: David Rientjes Reported-by: Andrei Elovikov Acked-by: Christoph Lameter Cc: Pekka Enberg Cc: Joonsoo Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a5d969ea051ceb8511ebdc22c885aa25ebb056cf Author: Joseph Qi Date: Thu Sep 25 16:05:16 2014 -0700 ocfs2/dlm: do not get resource spinlock if lockres is new commit 5760a97c7143c208fa3a8f8cad0ed7dd672ebd28 upstream. There is a deadlock case which reported by Guozhonghua: https://oss.oracle.com/pipermail/ocfs2-devel/2014-September/010079.html This case is caused by &res->spinlock and &dlm->master_lock misordering in different threads. It was introduced by commit 8d400b81cc83 ("ocfs2/dlm: Clean up refmap helpers"). Since lockres is new, it doesn't not require the &res->spinlock. So remove it. Fixes: 8d400b81cc83 ("ocfs2/dlm: Clean up refmap helpers") Signed-off-by: Joseph Qi Reviewed-by: joyce.xue Reported-by: Guozhonghua Cc: Joel Becker Cc: Mark Fasheh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1ba8582bd6d21fb7ec4bb3f2dc199f7ccc182e4d Author: Andreas Rohner Date: Thu Sep 25 16:05:14 2014 -0700 nilfs2: fix data loss with mmap() commit 56d7acc792c0d98f38f22058671ee715ff197023 upstream. This bug leads to reproducible silent data loss, despite the use of msync(), sync() and a clean unmount of the file system. It is easily reproducible with the following script: ----------------[BEGIN SCRIPT]-------------------- mkfs.nilfs2 -f /dev/sdb mount /dev/sdb /mnt dd if=/dev/zero bs=1M count=30 of=/mnt/testfile umount /mnt mount /dev/sdb /mnt CHECKSUM_BEFORE="$(md5sum /mnt/testfile)" /root/mmaptest/mmaptest /mnt/testfile 30 10 5 sync CHECKSUM_AFTER="$(md5sum /mnt/testfile)" umount /mnt mount /dev/sdb /mnt CHECKSUM_AFTER_REMOUNT="$(md5sum /mnt/testfile)" umount /mnt echo "BEFORE MMAP:\t$CHECKSUM_BEFORE" echo "AFTER MMAP:\t$CHECKSUM_AFTER" echo "AFTER REMOUNT:\t$CHECKSUM_AFTER_REMOUNT" ----------------[END SCRIPT]-------------------- The mmaptest tool looks something like this (very simplified, with error checking removed): ----------------[BEGIN mmaptest]-------------------- data = mmap(NULL, file_size - file_offset, PROT_READ | PROT_WRITE, MAP_SHARED, fd, file_offset); for (i = 0; i < write_count; ++i) { memcpy(data + i * 4096, buf, sizeof(buf)); msync(data, file_size - file_offset, MS_SYNC)) } ----------------[END mmaptest]-------------------- The output of the script looks something like this: BEFORE MMAP: 281ed1d5ae50e8419f9b978aab16de83 /mnt/testfile AFTER MMAP: 6604a1c31f10780331a6850371b3a313 /mnt/testfile AFTER REMOUNT: 281ed1d5ae50e8419f9b978aab16de83 /mnt/testfile So it is clear, that the changes done using mmap() do not survive a remount. This can be reproduced a 100% of the time. The problem was introduced in commit 136e8770cd5d ("nilfs2: fix issue of nilfs_set_page_dirty() for page at EOF boundary"). If the page was read with mpage_readpage() or mpage_readpages() for example, then it has no buffers attached to it. In that case page_has_buffers(page) in nilfs_set_page_dirty() will be false. Therefore nilfs_set_file_dirty() is never called and the pages are never collected and never written to disk. This patch fixes the problem by also calling nilfs_set_file_dirty() if the page has no buffers attached to it. [akpm@linux-foundation.org: s/PAGE_SHIFT/PAGE_CACHE_SHIFT/] Signed-off-by: Andreas Rohner Tested-by: Andreas Rohner Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 312a707d276502be40f50ba84120c413d428238f Author: Andrey Vagin Date: Tue Sep 9 14:51:06 2014 -0700 fs/notify: don't show f_handle if exportfs_encode_inode_fh failed commit 7e8824816bda16bb11ff5ff1e1212d642e57b0b3 upstream. Currently we handle only ENOSPC. In case of other errors the file_handle variable isn't filled properly and we will show a part of stack. Signed-off-by: Andrey Vagin Acked-by: Cyrill Gorcunov Cc: Alexander Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 009adfc82414e3e9155f97c88522599fa9fdd394 Author: Andrey Vagin Date: Tue Sep 9 14:51:04 2014 -0700 fsnotify/fdinfo: use named constants instead of hardcoded values commit 1fc98d11cac6dd66342e5580cb2687e5b1e9a613 upstream. MAX_HANDLE_SZ is equal to 128, but currently the size of pad is only 64 bytes, so exportfs_encode_inode_fh can return an error. Signed-off-by: Andrey Vagin Acked-by: Cyrill Gorcunov Cc: Alexander Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 67e478a670fd4c949161c16cc3b965d03f701ca8 Author: Rasmus Villemoes Date: Tue Sep 9 14:51:01 2014 -0700 kcmp: fix standard comparison bug commit acbbe6fbb240a927ee1f5994f04d31267d422215 upstream. The C operator <= defines a perfectly fine total ordering on the set of values representable in a long. However, unlike its namesake in the integers, it is not translation invariant, meaning that we do not have "b <= c" iff "a+b <= a+c" for all a,b,c. This means that it is always wrong to try to boil down the relationship between two longs to a question about the sign of their difference, because the resulting relation [a LEQ b iff a-b <= 0] is neither anti-symmetric or transitive. The former is due to -LONG_MIN==LONG_MIN (take any two a,b with a-b = LONG_MIN; then a LEQ b and b LEQ a, but a != b). The latter can either be seen observing that x LEQ x+1 for all x, implying x LEQ x+1 LEQ x+2 ... LEQ x-1 LEQ x; or more directly with the simple example a=LONG_MIN, b=0, c=1, for which a-b < 0, b-c < 0, but a-c > 0. Note that it makes absolutely no difference that a transmogrying bijection has been applied before the comparison is done. In fact, had the obfuscation not been done, one could probably not observe the bug (assuming all values being compared always lie in one half of the address space, the mathematical value of a-b is always representable in a long). As it stands, one can easily obtain three file descriptors exhibiting the non-transitivity of kcmp(). Side note 1: I can't see that ensuring the MSB of the multiplier is set serves any purpose other than obfuscating the obfuscating code. Side note 2: #include #include #include #include #include #include #include enum kcmp_type { KCMP_FILE, KCMP_VM, KCMP_FILES, KCMP_FS, KCMP_SIGHAND, KCMP_IO, KCMP_SYSVSEM, KCMP_TYPES, }; pid_t pid; int kcmp(pid_t pid1, pid_t pid2, int type, unsigned long idx1, unsigned long idx2) { return syscall(SYS_kcmp, pid1, pid2, type, idx1, idx2); } int cmp_fd(int fd1, int fd2) { int c = kcmp(pid, pid, KCMP_FILE, fd1, fd2); if (c < 0) { perror("kcmp"); exit(1); } assert(0 <= c && c < 3); return c; } int cmp_fdp(const void *a, const void *b) { static const int normalize[] = {0, -1, 1}; return normalize[cmp_fd(*(int*)a, *(int*)b)]; } #define MAX 100 /* This is plenty; I've seen it trigger for MAX==3 */ int main(int argc, char *argv[]) { int r, s, count = 0; int REL[3] = {0,0,0}; int fd[MAX]; pid = getpid(); while (count < MAX) { r = open("/dev/null", O_RDONLY); if (r < 0) break; fd[count++] = r; } printf("opened %d file descriptors\n", count); for (r = 0; r < count; ++r) { for (s = r+1; s < count; ++s) { REL[cmp_fd(fd[r], fd[s])]++; } } printf("== %d\t< %d\t> %d\n", REL[0], REL[1], REL[2]); qsort(fd, count, sizeof(fd[0]), cmp_fdp); memset(REL, 0, sizeof(REL)); for (r = 0; r < count; ++r) { for (s = r+1; s < count; ++s) { REL[cmp_fd(fd[r], fd[s])]++; } } printf("== %d\t< %d\t> %d\n", REL[0], REL[1], REL[2]); return (REL[0] + REL[2] != 0); } Signed-off-by: Rasmus Villemoes Reviewed-by: Cyrill Gorcunov "Eric W. Biederman" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit af3d863635f6aa7b3d89ab994ffb412ac956c211 Author: Nicolas Iooss Date: Tue Sep 9 14:50:51 2014 -0700 eventpoll: fix uninitialized variable in epoll_ctl commit c680e41b3a2e944185c74bf60531e3d316d3ecc4 upstream. When calling epoll_ctl with operation EPOLL_CTL_DEL, structure epds is not initialized but ep_take_care_of_epollwakeup reads its event field. When this unintialized field has EPOLLWAKEUP bit set, a capability check is done for CAP_BLOCK_SUSPEND in ep_take_care_of_epollwakeup. This produces unexpected messages in the audit log, such as (on a system running SELinux): type=AVC msg=audit(1408212798.866:410): avc: denied { block_suspend } for pid=7754 comm="dbus-daemon" capability=36 scontext=unconfined_u:unconfined_r:unconfined_t tcontext=unconfined_u:unconfined_r:unconfined_t tclass=capability2 permissive=1 type=SYSCALL msg=audit(1408212798.866:410): arch=c000003e syscall=233 success=yes exit=0 a0=3 a1=2 a2=9 a3=7fffd4d66ec0 items=0 ppid=1 pid=7754 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="dbus-daemon" exe="/usr/bin/dbus-daemon" subj=unconfined_u:unconfined_r:unconfined_t key=(null) ("arch=c000003e syscall=233 a1=2" means "epoll_ctl(op=EPOLL_CTL_DEL)") Remove use of epds in epoll_ctl when op == EPOLL_CTL_DEL. Fixes: 4d7e30d98939 ("epoll: Add a flag, EPOLLWAKEUP, to prevent suspend while epoll events are ready") Signed-off-by: Nicolas Iooss Cc: Alexander Viro Cc: Arve Hjønnevåg Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 254e4530c4ac42dae06adb84903fbd60b1161676 Author: Patrick Palka Date: Tue Sep 9 14:50:48 2014 -0700 kernel/printk/printk.c: fix faulty logic in the case of recursive printk commit 000a7d66ec30898f46869be01ab8205b056385d0 upstream. We shouldn't set text_len in the code path that detects printk recursion because text_len corresponds to the length of the string inside textbuf. A few lines down from the line text_len = strlen(recursion_msg); is the line text_len += vscnprintf(text + text_len, ...); So if printk detects recursion, it sets text_len to 29 (the length of recursion_msg) and logs an error. Then the message supplied by the caller of printk is stored inside textbuf but offset by 29 bytes. This means that the output of the recursive call to printk will contain 29 bytes of garbage in front of it. This defect is caused by commit 458df9fd4815 ("printk: remove separate printk_sched buffers and use printk buf instead") which turned the line text_len = vscnprintf(text, ...); into text_len += vscnprintf(text + text_len, ...); To fix this, this patch avoids setting text_len when logging the printk recursion error. This patch also marks unlikely() the branch leading up to this code. Fixes: 458df9fd4815b478 ("printk: remove separate printk_sched buffers and use printk buf instead") Signed-off-by: Patrick Palka Reviewed-by: Petr Mladek Reviewed-by: Jan Kara Acked-by: Steven Rostedt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d9ecad333f0b4abb6d67f572a9476d34ebdaacc0 Author: Johannes Berg Date: Mon Aug 25 12:08:09 2014 +0200 Revert "mac80211: disable uAPSD if all ACs are under ACM" commit bb512ad0732232f1d2693bb68f31a76bed8f22ae upstream. This reverts commit 24aa11ab8ae03292d38ec0dbd9bc2ac49fe8a6dd. That commit was wrong since it uses data that hasn't even been set up yet, but might be a hold-over from a previous connection. Additionally, it seems like a driver-specific workaround that shouldn't have been in mac80211 to start with. Fixes: 24aa11ab8ae0 ("mac80211: disable uAPSD if all ACs are under ACM") Reviewed-by: Luciano Coelho Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 240f589d340c956acac25d1d027266d1060ab773 Author: Steven Rostedt (Red Hat) Date: Mon Aug 18 13:21:08 2014 -0400 ftrace: Update all ftrace_ops for a ftrace_hash_ops update commit 84261912ebee41269004e8a9f3614ba38ef6b206 upstream. When updating what an ftrace_ops traces, if it is registered (that is, actively tracing), and that ftrace_ops uses the shared global_ops local_hash, then we need to update all tracers that are active and also share the global_ops' ftrace_hash_ops. Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 7f4ad28369a710ad937d10874aa4d43af2fda3b5 Author: Steven Rostedt (Red Hat) Date: Fri Aug 15 17:18:46 2014 -0400 ftrace: Fix function_profiler and function tracer together commit 5f151b240192a1557119d5375af71efc26825bc8 upstream. The latest rewrite of ftrace removed the separate ftrace_ops of the function tracer and the function graph tracer and had them share the same ftrace_ops. This simplified the accounting by removing the multiple layers of functions called, where the global_ops func would call a special list that would iterate over the other ops that were registered within it (like function and function graph), which itself was registered to the ftrace ops list of all functions currently active. If that sounds confusing, the code that implemented it was also confusing and its removal is a good thing. The problem with this change was that it assumed that the function and function graph tracer can never be used at the same time. This is mostly true, but there is an exception. That is when the function profiler uses the function graph tracer to profile. The function profiler can be activated the same time as the function tracer, and this breaks the assumption and the result is that ftrace will crash (it detects the error and shuts itself down, it does not cause a kernel oops). To solve this issue, a previous change allowed the hash tables for the functions traced by a ftrace_ops to be a pointer and let multiple ftrace_ops share the same hash. This allows the function and function_graph tracer to have separate ftrace_ops, but still share the hash, which is what is done. Now the function and function graph tracers have separate ftrace_ops again, and the function tracer can be run while the function_profile is active. Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 6f6ad430e7e090ec3e0bbf02c2a47816aec83c7e Author: Steven Rostedt (Red Hat) Date: Fri Aug 15 17:23:02 2014 -0400 ftrace: Allow ftrace_ops to use the hashes from other ops commit 33b7f99cf003ca6c1d31c42b50e1100ad71aaec0 upstream. Currently the top level debug file system function tracer shares its ftrace_ops with the function graph tracer. This was thought to be fine because the tracers are not used together, as one can only enable function or function_graph tracer in the current_tracer file. But that assumption proved to be incorrect. The function profiler can use the function graph tracer when function tracing is enabled. Since all function graph users uses the function tracing ftrace_ops this causes a conflict and when a user enables both function profiling as well as the function tracer it will crash ftrace and disable it. The quick solution so far is to move them as separate ftrace_ops like it was earlier. The problem though is to synchronize the functions that are traced because both function and function_graph tracer are limited by the selections made in the set_ftrace_filter and set_ftrace_notrace files. To handle this, a new structure is made called ftrace_ops_hash. This structure will now hold the filter_hash and notrace_hash, and the ftrace_ops will point to this structure. That will allow two ftrace_ops to share the same hashes. Since most ftrace_ops do not share the hashes, and to keep allocation simple, the ftrace_ops structure will include both a pointer to the ftrace_ops_hash called func_hash, as well as the structure itself, called local_hash. When the ops are registered, the func_hash pointer will be initialized to point to the local_hash within the ftrace_ops structure. Some of the ftrace internal ftrace_ops will be initialized statically. This will allow for the function and function_graph tracer to have separate ops but still share the same hash tables that determine what functions they trace. Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 2b3a58058b0f7523f0907cfd8f22bbd315335964 Author: Felipe Balbi Date: Thu Sep 4 10:28:10 2014 -0500 usb: dwc3: fix TRB completion when multiple TRBs are started commit 0b93a4c838fa10370d72f86fe712426ac63804de upstream. After commit 2ec2a8be (usb: dwc3: gadget: always enable IOC on bulk/interrupt transfers) we created a situation where it was possible to hang a bulk/interrupt endpoint if we had more than one pending request in our queue and they were both started with a single Start Transfer command. The problems triggers because we had not enabled Transfer In Progress event for those endpoints and we were not able to process early giveback of requests completed without LST bit set. Fix the problem by finally enabling Xfer In Progress event for all endpoint types, except control. Fixes: 2ec2a8be (usb: dwc3: gadget: always enable IOC on bulk/interrupt transfers) Reported-by: Pratyush Anand Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit e8b1e9604f97d8c74c84b3754e8ca9ad7e41b38a Author: Jens Axboe Date: Tue Sep 16 13:38:51 2014 -0600 genhd: fix leftover might_sleep() in blk_free_devt() commit 46f341ffcfb5d8530f7d1e60f3be06cce6661b62 upstream. Commit 2da78092 changed the locking from a mutex to a spinlock, so we now longer sleep in this context. But there was a leftover might_sleep() in there, which now triggers since we do the final free from an RCU callback. Get rid of it. Reported-by: Pontus Fuchs Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 5083d713c57be72c30ea5fc6fad243f69fd60c37 Author: Trond Myklebust Date: Thu Jun 5 11:31:01 2014 -0400 lockdep: Revert lockdep check in raw_seqcount_begin() commit 22fdcf02f6e80d64a927f702dd9d631a927d87d4 upstream. This commit reverts the addition of lockdep checking to raw_seqcount_begin for the following reasons: 1) It violates the naming convention that raw_* functions should not do lockdep checks (a convention that is also followed by the other raw_*_seqcount_begin functions). 2) raw_seqcount_begin does not spin, so it can only be part of an ABBA deadlock in very special circumstances (for instance if a lock is held across the entire raw_seqcount_begin()+read_seqcount_retry() loop while also being taken inside the write_seqcount protected area). 3) It is causing false positives with some existing callers, and there is no non-lockdep alternative for those callers to use. None of the three existing callers (__d_lookup_rcu, netdev_get_name, and the NFS state code) appear to use the function in a manner that is ABBA deadlock prone. Fixes: 1ca7d67cf5d5: seqcount: Add lockdep functionality to seqcount/seqlock Signed-off-by: Trond Myklebust Signed-off-by: Peter Zijlstra Cc: John Stultz Cc: "David S. Miller" Cc: Al Viro Cc: Waiman Long Cc: Stephen Boyd Cc: Linus Torvalds Link: http://lkml.kernel.org/r/CAHQdGtRR6SvEhXiqWo24hoUh9AU9cL82Z8Z-d8-7u951F_d+5g@mail.gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit f12342b1f00b59581eea16879d18ecef0188dcfc Author: J. Bruce Fields Date: Fri Aug 29 16:25:50 2014 -0400 lockd: fix rpcbind crash on lockd startup failure commit 7c17705e77b12b20fb8afb7c1b15dcdb126c0c12 upstream. Nikita Yuschenko reported that booting a kernel with init=/bin/sh and then nfs mounting without portmap or rpcbind running using a busybox mount resulted in: # mount -t nfs 10.30.130.21:/opt /mnt svc: failed to register lockdv1 RPC service (errno 111). lockd_up: makesock failed, error=-111 Unable to handle kernel paging request for data at address 0x00000030 Faulting instruction address: 0xc055e65c Oops: Kernel access of bad area, sig: 11 [#1] MPC85xx CDS Modules linked in: CPU: 0 PID: 1338 Comm: mount Not tainted 3.10.44.cge #117 task: cf29cea0 ti: cf35c000 task.ti: cf35c000 NIP: c055e65c LR: c0566490 CTR: c055e648 REGS: cf35dad0 TRAP: 0300 Not tainted (3.10.44.cge) MSR: 00029000 CR: 22442488 XER: 20000000 DEAR: 00000030, ESR: 00000000 GPR00: c05606f4 cf35db80 cf29cea0 cf0ded80 cf0dedb8 00000001 1dec3086 00000000 GPR08: 00000000 c07b1640 00000007 1dec3086 22442482 100b9758 00000000 10090ae8 GPR16: 00000000 000186a5 00000000 00000000 100c3018 bfa46edc 100b0000 bfa46ef0 GPR24: cf386ae0 c07834f0 00000000 c0565f88 00000001 cf0dedb8 00000000 cf0ded80 NIP [c055e65c] call_start+0x14/0x34 LR [c0566490] __rpc_execute+0x70/0x250 Call Trace: [cf35db80] [00000080] 0x80 (unreliable) [cf35dbb0] [c05606f4] rpc_run_task+0x9c/0xc4 [cf35dbc0] [c0560840] rpc_call_sync+0x50/0xb8 [cf35dbf0] [c056ee90] rpcb_register_call+0x54/0x84 [cf35dc10] [c056f24c] rpcb_register+0xf8/0x10c [cf35dc70] [c0569e18] svc_unregister.isra.23+0x100/0x108 [cf35dc90] [c0569e38] svc_rpcb_cleanup+0x18/0x30 [cf35dca0] [c0198c5c] lockd_up+0x1dc/0x2e0 [cf35dcd0] [c0195348] nlmclnt_init+0x2c/0xc8 [cf35dcf0] [c015bb5c] nfs_start_lockd+0x98/0xec [cf35dd20] [c015ce6c] nfs_create_server+0x1e8/0x3f4 [cf35dd90] [c0171590] nfs3_create_server+0x10/0x44 [cf35dda0] [c016528c] nfs_try_mount+0x158/0x1e4 [cf35de20] [c01670d0] nfs_fs_mount+0x434/0x8c8 [cf35de70] [c00cd3bc] mount_fs+0x20/0xbc [cf35de90] [c00e4f88] vfs_kern_mount+0x50/0x104 [cf35dec0] [c00e6e0c] do_mount+0x1d0/0x8e0 [cf35df10] [c00e75ac] SyS_mount+0x90/0xd0 [cf35df40] [c000ccf4] ret_from_syscall+0x0/0x3c The addition of svc_shutdown_net() resulted in two calls to svc_rpcb_cleanup(); the second is no longer necessary and crashes when it calls rpcb_register_call with clnt=NULL. Reported-by: Nikita Yushchenko Fixes: 679b033df484 "lockd: ensure we tear down any live sockets when socket creation fails during lockd_up" Acked-by: Jeff Layton Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 4b654d5db96392c887804403fdb62fc1e4226aba Author: Larry Finger Date: Sun Aug 24 17:49:43 2014 -0500 rtlwifi: rtl8192cu: Add new ID commit c66517165610b911e4c6d268f28d8c640832dbd1 upstream. The Sitecom WLA-2102 adapter uses this driver. Reported-by: Nico Baggus Signed-off-by: Larry Finger Cc: Nico Baggus Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 5fa0d9cc1bd63272ff585e7b4495b2132b43547e Author: Eliad Peller Date: Wed Jun 11 10:23:35 2014 +0300 regulatory: add NUL to alpha2 commit a5fe8e7695dc3f547e955ad2b662e3e72969e506 upstream. alpha2 is defined as 2-chars array, but is used in multiple places as string (e.g. with nla_put_string calls), which might leak kernel data. Solve it by simply adding an extra char for the NULL terminator, making such operations safe. Signed-off-by: Eliad Peller Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 145f3d4620ed51cabeced1ebf4a233f4592a4b57 Author: Tejun Heo Date: Fri Aug 15 16:06:10 2014 -0400 percpu: perform tlb flush after pcpu_map_pages() failure commit 849f5169097e1ba35b90ac9df76b5bb6f9c0aabd upstream. If pcpu_map_pages() fails midway, it unmaps the already mapped pages. Currently, it doesn't flush tlb after the partial unmapping. This may be okay in most cases as the established mapping hasn't been used at that point but it can go wrong and when it goes wrong it'd be extremely difficult to track down. Flush tlb after the partial unmapping. Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit a3079e438f581d261640558f73e520bb17212155 Author: Tejun Heo Date: Fri Aug 15 16:06:06 2014 -0400 percpu: fix pcpu_alloc_pages() failure path commit f0d279654dea22b7a6ad34b9334aee80cda62cde upstream. When pcpu_alloc_pages() fails midway, pcpu_free_pages() is invoked to free what has already been allocated. The invocation is across the whole requested range and pcpu_free_pages() will try to free all non-NULL pages; unfortunately, this is incorrect as pcpu_get_pages_and_bitmap(), unlike what its comment suggests, doesn't clear the pages array and thus the array may have entries from the previous invocations making the partial failure path free incorrect pages. Fix it by open-coding the partial freeing of the already allocated pages. Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 6baa29b62446f4b79e59494e2a54473c94eb8424 Author: Honggang Li Date: Tue Aug 12 21:36:15 2014 +0800 percpu: free percpu allocation info for uniprocessor system commit 3189eddbcafcc4d827f7f19facbeddec4424eba8 upstream. Currently, only SMP system free the percpu allocation info. Uniprocessor system should free it too. For example, one x86 UML virtual machine with 256MB memory, UML kernel wastes one page memory. Signed-off-by: Honggang Li Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 02a4c4965393b98347f14947fa8d02aeab94be77 Author: Jarkko Nikula Date: Tue Sep 16 16:23:15 2014 +0300 gpio: Fix potential NULL handler data in chained irqchip handler commit 324b0398781e7afb846378dd2d8a4374faaf236b upstream. There is possibility with misconfigured pins that interrupt occurs instantly after setting irq_set_chained_handler() in gpiochip_set_chained_irqchip(). Now if handler gets called before irq_set_handler_data() the handler gets NULL handler data. Fix this by moving irq_set_handler_data() call before irq_set_chained_handler() in gpiochip_set_chained_irqchip(). Reviewed-by: Alexandre Courbot Signed-off-by: Jarkko Nikula Signed-off-by: Greg Kroah-Hartman commit 47155f7c6488dbc3bdb350dbec582037acb7c20d Author: James Ralston Date: Wed Aug 27 14:31:58 2014 -0700 ata_piix: Add Device IDs for Intel 9 Series PCH commit 6cad1376954e591c3c41500c4e586e183e7ffe6d upstream. This patch adds the IDE mode SATA Device IDs for the Intel 9 Series PCH. Signed-off-by: James Ralston Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 35b2412b20d40b6c747eec22e9e0099874c98578 Author: Robert Coulson Date: Thu Aug 28 10:45:43 2014 -0700 hwmon: (ds1621) Update zbits after conversion rate change commit 39c627a084475e8a690a4a9e7601410ca173ddd2 upstream. After the conversion rate is changed, the zbits are not updated, but should be, since they are used later in the set_temp function. Fixes: a50d9a4d9ad3 ("hwmon: (ds1621) Fix temperature rounding operations") Reported-by: Murat Ilsever Signed-off-by: Robert Coulson Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 8b6aeab16bdb8ffa3979146f1951f23e94ff178d Author: Hans de Goede Date: Thu Sep 11 10:10:26 2014 -0700 Input: i8042 - add nomux quirk for Avatar AVIU-145A6 commit d2682118f4bb3ceb835f91c1a694407a31bb7378 upstream. The sys_vendor / product_name are somewhat generic unfortunately, so this may lead to some false positives. But nomux usually does no harm, where as not having it clearly is causing problems on the Avatar AVIU-145A6. https://bugzilla.kernel.org/show_bug.cgi?id=77391 Reported-by: Hugo P Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 9878537d15f7332e1964e70179cb035d25f67c2d Author: Hans de Goede Date: Wed Sep 10 13:53:37 2014 -0700 Input: i8042 - add Fujitsu U574 to no_timeout dmi table commit cc18a69c92d0972bc2fc5a047ee3be1e8398171b upstream. https://bugzilla.kernel.org/show_bug.cgi?id=69731 Reported-by: Jason Robinson Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 51fffae908a8a429a86883abb1a48f296cf62547 Author: Dmitry Torokhov Date: Wed Sep 10 13:50:37 2014 -0700 Input: atkbd - do not try 'deactivate' keyboard on any LG laptops commit c01206796139e2b1feb7539bc72174fef1c6dc6e upstream. We are getting more and more reports about LG laptops not having functioning keyboard if we try to deactivate keyboard during probe. Given that having keyboard deactivated is merely "nice to have" instead of a hard requirement for probing, let's disable it on all LG boxes instead of trying to hunt down particular models. This change is prompted by patches trying to add "LG Electronics"/"ROCKY" and "LG Electronics"/"LW60-F27B" to the DMI list. https://bugzilla.kernel.org/show_bug.cgi?id=77051 Reported-by: Jaime Velasco Juan Reported-by: Georgios Tsalikis Tested-by: Jaime Velasco Juan Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 20d7d7a3fd51dd79450c9971411d011d530abcc8 Author: Hans de Goede Date: Mon Sep 8 14:39:52 2014 -0700 Input: elantech - fix detection of touchpad on ASUS s301l commit 271329b3c798b2102120f5df829071c211ef00ed upstream. Adjust Elantech signature validation to account fo rnewer models of touchpads. Reported-and-tested-by: Màrius Monton Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 99d73cdd95c628464ab883a3e27cfb0ca09321d8 Author: Dmitry Torokhov Date: Sat Aug 30 13:51:06 2014 -0700 Input: synaptics - add support for ForcePads commit 5715fc764f7753d464dbe094b5ef9cffa6e479a4 upstream. ForcePads are found on HP EliteBook 1040 laptops. They lack any kind of physical buttons, instead they generate primary button click when user presses somewhat hard on the surface of the touchpad. Unfortunately they also report primary button click whenever there are 2 or more contacts on the pad, messing up all multi-finger gestures (2-finger scrolling, multi-finger tapping, etc). To cope with this behavior we introduce a delay (currently 50 msecs) in reporting primary press in case more contacts appear. Reviewed-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 78d875e465fbeaa449975254876dc1b6e4a87792 Author: John Sung Date: Tue Sep 9 10:06:51 2014 -0700 Input: serport - add compat handling for SPIOCSTYPE ioctl commit a80d8b02751060a178bb1f7a6b7a93645a7a308b upstream. When running a 32-bit inputattach utility in a 64-bit system, there will be error code "inputattach: can't set device type". This is caused by the serport device driver not supporting compat_ioctl, so that SPIOCSTYPE ioctl fails. Signed-off-by: John Sung Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 868c34cdfdaa215d76acc78204e13799baf118b8 Author: Mikulas Patocka Date: Thu Aug 28 11:09:31 2014 -0400 dm crypt: fix access beyond the end of allocated space commit d49ec52ff6ddcda178fc2476a109cf1bd1fa19ed upstream. The DM crypt target accesses memory beyond allocated space resulting in a crash on 32 bit x86 systems. This bug is very old (it dates back to 2.6.25 commit 3a7f6c990ad04 "dm crypt: use async crypto"). However, this bug was masked by the fact that kmalloc rounds the size up to the next power of two. This bug wasn't exposed until 3.17-rc1 commit 298a9fa08a ("dm crypt: use per-bio data"). By switching to using per-bio data there was no longer any padding beyond the end of a dm-crypt allocated memory block. To minimize allocation overhead dm-crypt puts several structures into one block allocated with kmalloc. The block holds struct ablkcipher_request, cipher-specific scratch pad (crypto_ablkcipher_reqsize(any_tfm(cc))), struct dm_crypt_request and an initialization vector. The variable dmreq_start is set to offset of struct dm_crypt_request within this memory block. dm-crypt allocates the block with this size: cc->dmreq_start + sizeof(struct dm_crypt_request) + cc->iv_size. When accessing the initialization vector, dm-crypt uses the function iv_of_dmreq, which performs this calculation: ALIGN((unsigned long)(dmreq + 1), crypto_ablkcipher_alignmask(any_tfm(cc)) + 1). dm-crypt allocated "cc->iv_size" bytes beyond the end of dm_crypt_request structure. However, when dm-crypt accesses the initialization vector, it takes a pointer to the end of dm_crypt_request, aligns it, and then uses it as the initialization vector. If the end of dm_crypt_request is not aligned on a crypto_ablkcipher_alignmask(any_tfm(cc)) boundary the alignment causes the initialization vector to point beyond the allocated space. Fix this bug by calculating the variable iv_size_padding and adding it to the allocated size. Also correct the alignment of dm_crypt_request. struct dm_crypt_request is specific to dm-crypt (it isn't used by the crypto subsystem at all), so it is aligned on __alignof__(struct dm_crypt_request). Also align per_bio_data_size on ARCH_KMALLOC_MINALIGN, so that it is aligned as if the block was allocated with kmalloc. Reported-by: Krzysztof Kolasa Tested-by: Milan Broz Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 6ac4bc260c4c87d17fc43bf838d3542e62527f71 Author: Anssi Hannula Date: Fri Sep 5 03:11:28 2014 +0300 dm cache: fix race causing dirty blocks to be marked as clean commit 40aa978eccec61347cd47b97c598df49acde8be5 upstream. When a writeback or a promotion of a block is completed, the cell of that block is removed from the prison, the block is marked as clean, and the clear_dirty() callback of the cache policy is called. Unfortunately, performing those actions in this order allows an incoming new write bio for that block to come in before clearing the dirty status is completed and therefore possibly causing one of these two scenarios: Scenario A: Thread 1 Thread 2 cell_defer() . - cell removed from prison . - detained bios queued . . incoming write bio . remapped to cache . set_dirty() called, . but block already dirty . => it does nothing clear_dirty() . - block marked clean . - policy clear_dirty() called . Result: Block is marked clean even though it is actually dirty. No writeback will occur. Scenario B: Thread 1 Thread 2 cell_defer() . - cell removed from prison . - detained bios queued . clear_dirty() . - block marked clean . . incoming write bio . remapped to cache . set_dirty() called . - block marked dirty . - policy set_dirty() called - policy clear_dirty() called . Result: Block is properly marked as dirty, but policy thinks it is clean and therefore never asks us to writeback it. This case is visible in "dmsetup status" dirty block count (which normally decreases to 0 on a quiet device). Fix these issues by calling clear_dirty() before calling cell_defer(). Incoming bios for that block will then be detained in the cell and released only after clear_dirty() has completed, so the race will not occur. Found by inspecting the code after noticing spurious dirty counts (scenario B). Signed-off-by: Anssi Hannula Acked-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit b9dfd48c65affe4c8ee80a9757486de10dc64123 Author: Keith Busch Date: Tue Aug 26 09:05:36 2014 -0600 block: Fix dev_t minor allocation lifetime commit 2da78092dda13f1efd26edbbf99a567776913750 upstream. Releases the dev_t minor when all references are closed to prevent another device from acquiring the same major/minor. Since the partition's release may be invoked from call_rcu's soft-irq context, the ext_dev_idr's mutex had to be replaced with a spinlock so as not so sleep. Signed-off-by: Keith Busch Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 31512f8bea38d31a2f7e0c7a65f3cdb645a2ab5f Author: Thomas Gleixner Date: Thu Sep 11 23:44:35 2014 +0200 futex: Unlock hb->lock in futex_wait_requeue_pi() error path commit 13c42c2f43b19aab3195f2d357db00d1e885eaa8 upstream. futex_wait_requeue_pi() calls futex_wait_setup(). If futex_wait_setup() succeeds it returns with hb->lock held and preemption disabled. Now the sanity check after this does: if (match_futex(&q.key, &key2)) { ret = -EINVAL; goto out_put_keys; } which releases the keys but does not release hb->lock. So we happily return to user space with hb->lock held and therefor preemption disabled. Unlock hb->lock before taking the exit route. Reported-by: Dave "Trinity" Jones Signed-off-by: Thomas Gleixner Reviewed-by: Darren Hart Reviewed-by: Davidlohr Bueso Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1409112318500.4178@nanos Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 051f686ae8c8657ed1266ae66d4f4bf4921338b0 Author: Tejun Heo Date: Sat Sep 13 04:14:30 2014 +0900 workqueue: apply __WQ_ORDERED to create_singlethread_workqueue() commit e09c2c295468476a239d13324ce9042ec4de05eb upstream. create_singlethread_workqueue() is a compat interface for single threaded workqueue which maps to ordered workqueue w/ rescuer in the current implementation. create_singlethread_workqueue() currently implemented by invoking alloc_workqueue() w/ appropriate parameters. 8719dceae2f9 ("workqueue: reject adjusting max_active or applying attrs to ordered workqueues") introduced __WQ_ORDERED to protect ordered workqueues against dynamic attribute changes which can break ordering guarantees but forgot to apply it to create_singlethread_workqueue(). This in itself is okay as nobody currently uses dynamic attribute change on workqueues created with create_singlethread_workqueue(). However, 4c16bd327c ("workqueue: implement NUMA affinity for unbound workqueues") broke singlethreaded guarantee for ordered workqueues through allocating a separate pool_workqueue on each NUMA node by default. A later change 8a2b75384444 ("workqueue: fix ordered workqueues in NUMA setups") fixed it by allocating only one global pool_workqueue if __WQ_ORDERED is set. Combined, the __WQ_ORDERED omission in create_singlethread_workqueue() became critical breaking its single threadedness and ordering guarantee. Let's make create_singlethread_workqueue() wrap alloc_ordered_workqueue() instead so that it inherits __WQ_ORDERED and can implicitly track future ordered_workqueue changes. v2: I missed that __WQ_ORDERED now protects against pwq splitting across NUMA nodes and incorrectly described the patch as a nice-to-have fix to protect against future dynamic attribute usages. Oleg pointed out that this is actually a critical breakage due to 8a2b75384444 ("workqueue: fix ordered workqueues in NUMA setups"). Signed-off-by: Tejun Heo Reported-by: Mike Anderson Cc: Oleg Nesterov Cc: Gustavo Luiz Duarte Cc: Tomas Henzl Fixes: 4c16bd327c ("workqueue: implement NUMA affinity for unbound workqueues") Signed-off-by: Greg Kroah-Hartman commit 96c738c2c8d80765f57e79387c68d68ea5b0bae8 Author: Luciano Coelho Date: Wed Jul 30 15:04:08 2014 +0300 iwlwifi: mvm: set MAC_FILTER_IN_BEACON correctly for STA/P2P client commit 7c8b3bc688bdcfd7789efbd17da4d85b104ad351 upstream. In commit cad3f08c (iwlwifi: mvm: enable MAC_FILTER_IN_BEACON when forced_assoc_off is set) the code to set the MAC_FILTER_IN_BEACON flag was accidentally moved to the main block of the if statement, while it should be in the else block instead. Move it to the right place. Fixes: cad3f08c23de ("iwlwifi: mvm: enable MAC_FILTER_IN_BEACON when forced_assoc_off is set") Reviewed-by: Johannes Berg Signed-off-by: Luciano Coelho Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 4bad9170b2723f5cf38af4a2ffc9cfc91a517351 Author: Eyal Shapira Date: Tue Sep 2 18:39:21 2014 +0300 iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate commit aa11bbf3df026d6b1c6b528bef634fd9de7c2619 upstream. Using the LQ table which is initially set according to the rssi could lead to EAPOLs being sent in high legacy rates like 54mbps. It's better to avoid sending EAPOLs in high rates as it reduces the chances of a successful 4-Way handshake. Avoid this and treat them like other mgmt frames which would initially get sent at the basic rate. Signed-off-by: Eyal Shapira Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit e8ecf80086a9f04c0957977ec8f0f93d2337e111 Author: Eliad Peller Date: Tue Aug 26 11:23:11 2014 +0300 iwlwifi: increase DEFAULT_MAX_TX_POWER commit 22d059a5c7c5de61e53c88e30b65e55fbfd91e91 upstream. The chip is able to transmit up to 22dBm, so set the constant appropriately. Signed-off-by: Eliad Peller Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 3dbf8d067ec53d0da2e139996daf2ae3d2dfe13e Author: Emmanuel Grumbach Date: Thu Jul 31 14:32:37 2014 +0300 iwlwifi: mvm: fix endianity issues with Smart Fifo commands commit 86974bff066dd8b98be46d7c7d3aba89034f0833 upstream. This code was broken on big endian systems. Sparse didn't catch the bug since the firmware command was not tagged as little endian. Fix the bug for big endian systems and tag the field in the firmware command to prevent such issues in the future. Fixes: 1f3b0ff8ec ("iwlwifi: mvm: Add Smart FIFO support") Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 91ee0a8ed50938b5b7fb50a22183a698c929a7be Author: Emmanuel Grumbach Date: Sun Aug 31 22:11:11 2014 +0300 Revert "iwlwifi: dvm: don't enable CTS to self" commit f47f46d7b09cf1d09e4b44b6cc4dd7d68a08028c upstream. This reverts commit 43d826ca5979927131685cc2092c7ce862cb91cd. This commit caused packet loss. Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 8e36f1f3f5561e3d7a450d83512d97334741beb6 Author: Mike Christie Date: Wed Sep 3 00:00:39 2014 -0500 SCSI: libiscsi: fix potential buffer overrun in __iscsi_conn_send_pdu commit db9bfd64b14a3a8f1868d2164518fdeab1b26ad1 upstream. This patches fixes a potential buffer overrun in __iscsi_conn_send_pdu. This function is used by iscsi drivers and userspace to send iscsi PDUs/ commands. For login commands, we have a set buffer size. For all other commands we do not support data buffers. This was reported by Dan Carpenter here: http://www.spinics.net/lists/linux-scsi/msg66838.html Reported-by: Dan Carpenter Signed-off-by: Mike Christie Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 06c286a3612256aaac92dd5f3680e767749fa794 Author: Dan Carpenter Date: Mon Sep 1 20:27:29 2014 +0300 NFC: microread: Potential overflows in microread_target_discovered() commit d07f1e8600ccb885c8f4143402b8912f7d827bcb upstream. Smatch says that skb->data is untrusted so we need to check to make sure that the memcpy() doesn't overflow. Fixes: cfad1ba87150 ('NFC: Initial support for Inside Secure microread') Signed-off-by: Dan Carpenter Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit 82d536030d24831cd2edf39508db2fe56be9bfed Author: Nicholas Bellinger Date: Wed Sep 17 11:45:17 2014 -0700 iscsi-target: Fix memory corruption in iscsit_logout_post_handler_diffcid commit b53b0d99d6fbf7d44330395349a895521cfdbc96 upstream. This patch fixes a bug in iscsit_logout_post_handler_diffcid() where a pointer used as storage for list_for_each_entry() was incorrectly being used to determine if no matching entry had been found. This patch changes iscsit_logout_post_handler_diffcid() to key off bool conn_found to determine if the function needs to exit early. Reported-by: Joern Engel Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 718846f829f17d255d28e9f1df93d8b8e7801f42 Author: Joern Engel Date: Tue Sep 2 17:49:54 2014 -0400 iscsi-target: avoid NULL pointer in iscsi_copy_param_list failure commit 8ae757d09c45102b347a1bc2867f54ffc1ab8fda upstream. In iscsi_copy_param_list() a failed iscsi_param_list memory allocation currently invokes iscsi_release_param_list() to cleanup, and will promptly trigger a NULL pointer dereference. Instead, go ahead and return for the first iscsi_copy_param_list() failure case. Found by coverity. Signed-off-by: Joern Engel Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit e5c5ef30c7fcceb931a4b497f10587a7046837b2 Author: Sebastian Herbszt Date: Mon Sep 1 00:17:53 2014 +0200 target: Fix inverted logic in SE_DEV_ALUA_SUPPORT_STATE_STORE commit 1f0b030c45c781f9fe568e5e2a813d6c8567a051 upstream. Fix inverted logic in SE_DEV_ALUA_SUPPORT_STATE_STORE for setting the supported ALUA access states via configfs, originally introduced in commit b0a382c5. A value of 1 should enable the support, not disable it. Signed-off-by: Sebastian Herbszt Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit eb230e16165414718a6a60f55328cf4ff3b9546e Author: Sagi Grimberg Date: Wed Jul 2 16:19:25 2014 +0300 Target/iser: Don't put isert_conn inside disconnected handler commit 0fc4ea701fcf5bc51ace4e288af5be741465f776 upstream. disconnected_handler is invoked on several CM events (such as DISCONNECTED, DEVICE_REMOVAL, TIMEWAIT_EXIT...). Since multiple events can occur while before isert_free_conn is invoked, we might put all isert_conn references and free the connection too early. Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 29b4f65944a9c771e2edc5c543ee48c0c8b8c638 Author: Sagi Grimberg Date: Wed Jul 2 16:19:24 2014 +0300 Target/iser: Get isert_conn reference once got to connected_handler commit c2f88b17a1d97ca4ecd96cc22333a7a4f1407d39 upstream. In case the connection didn't reach connected state, disconnected handler will never be invoked thus the second kref_put on isert_conn will be missing. Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 5fc61a47c6b95eb329a7d86026f18a213a749a56 Author: Ludovic Desroches Date: Thu Oct 9 15:02:00 2014 +0100 iio: adc: at91: don't use the last converted data register commit d4f51956ac8ad302db9b0c4e4232775b1baa7b44 upstream. If touchscreen mode is enabled and a conversion is requested on another channel, the result in the last converted data register can be a touchscreen relative value. Starting a conversion involves to do a conversion for all active channel. It starts with ADC channels and ends with touchscreen channels. Then if ADC_LCD register is not read quickly, its content may be a touchscreen conversion. To remove this temporal constraint, the conversion value is taken from the channel data register. Signed-off-by: Ludovic Desroches Acked-by: Alexandre Belloni Acked-by: Nicolas Ferre Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 920f880978cb9c50f5eec9447bfbe940bde8adef Author: Subbaraya Sundeep Bhatta Date: Sun Nov 9 09:55:00 2014 +0000 iio: adc: xilinx-xadc: assign auxiliary channels address correctly commit 1887e724e2b6df06847522fe9dc2ab53639516cc upstream. This patch fixes incorrect logic for assigning address to auxiliary channels of xilinx xadc. Signed-off-by: Subbaraya Sundeep Bhatta Acked-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 943a4dceb8fa872d77bc5cf2ffdc37bd11fd9b25 Author: Johannes Pointner Date: Mon Aug 25 09:04:00 2014 +0100 iio:inkern: fix overwritten -EPROBE_DEFER in of_iio_channel_get_by_name commit 872687f626e033b4ddfaec1e410057cfc6636d77 upstream. Fixes: a2c12493ed7e ('iio: of_iio_channel_get_by_name() returns non-null pointers for error legs') which improperly assumes that of_iio_channel_get_by_name must always return NULL and thus now hides -EPROBE_DEFER. Signed-off-by: Johannes Pointner Reviewed-by: Guenter Roeck Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0957e4fde341b137c204b2cea649be2334c0df63 Author: Denis CIOCCA Date: Thu Oct 9 13:55:00 2014 +0100 iio:magnetometer: bugfix magnetometers gain values commit a31d0928999fbf33b3a6042e8bcb7b7f7e07d094 upstream. This patch fix gains values. The first driver was designed using engineering samples, in mass production the values are changed. Signed-off-by: Denis Ciocca Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6058364362ecb6c8f36ed9ceb1681294636e3b53 Author: Srinivas Pandruvada Date: Fri Aug 22 21:48:00 2014 +0100 iio: adc: ad_sigma_delta: Fix indio_dev->trig assignment commit 9e5846be33277802c0c76e5c12825d0e4d27f639 upstream. This can result in wrong reference count for trigger device, call iio_trigger_get to increment reference. Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion with Jonathan. Signed-off-by: Srinivas Pandruvada Acked-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b7d58312f5baee4fc5d5c53258c86b4f00e25104 Author: Srinivas Pandruvada Date: Fri Aug 22 21:48:00 2014 +0100 iio: st_sensors: Fix indio_dev->trig assignment commit f0e84acd7056e6d7ade551c6439531606ae30a46 upstream. This can result in wrong reference count for trigger device, call iio_trigger_get to increment reference. Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion with Jonathan. Signed-off-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 44a5cfb43095c8754ec12c4a0be929e25803f554 Author: Srinivas Pandruvada Date: Fri Aug 22 21:48:00 2014 +0100 iio: meter: ade7758: Fix indio_dev->trig assignment commit 0495081179212b758775df752e657ea71dcae020 upstream. This can result in wrong reference count for trigger device, call iio_trigger_get to increment reference. Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion with Jonathan. Signed-off-by: Srinivas Pandruvada Acked-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 07770e5fe33526ee3acea338ca84527484f5f84a Author: Srinivas Pandruvada Date: Fri Aug 22 21:48:00 2014 +0100 iio: inv_mpu6050: Fix indio_dev->trig assignment commit b07e3b3850b2e1f09c19f54d3ed7210d9f529e2c upstream. This can result in wrong reference count for trigger device, call iio_trigger_get to increment reference. Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion with Jonathan. Signed-off-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 173fb83f5905062d1b8527208ba6e2f6bca030bf Author: Srinivas Pandruvada Date: Fri Aug 22 21:48:00 2014 +0100 iio: gyro: itg3200: Fix indio_dev->trig assignment commit 0b4dce2ee694a991ef38203ec5ff91a738518cb3 upstream. This can result in wrong reference count for trigger device, call iio_trigger_get to increment reference. Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion with Jonathan. Signed-off-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit e43c03e970bc993abf27b8fd1650a40001b852eb Author: Srinivas Pandruvada Date: Fri Aug 22 21:48:00 2014 +0100 iio: hid_sensor_hub: Fix indio_dev->trig assignment commit 55a6f9ddfdea0d2d343cd1b39baf8aa752664b6e upstream. This can result in wrong reference count for trigger device, call iio_trigger_get to increment reference. Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion with Jonathan. Signed-off-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 775033b1f6487da88da1fdbae63c4ac0e72157df Author: Srinivas Pandruvada Date: Fri Aug 22 21:48:00 2014 +0100 iio: accel: bma180: Fix indio_dev->trig assignment commit 0668a4e4d297328ce08b44d91d160537596115e2 upstream. This can result in wrong reference count for trigger device, call iio_trigger_get to increment reference. Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion with Jonathan. Signed-off-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 1c4442a4ed361b5b3a489d5957c349d2c3cdbce5 Author: Srinivas Pandruvada Date: Fri Aug 22 21:48:00 2014 +0100 iio:trigger: modify return value for iio_trigger_get commit f153566570fb9e32c2f59182883f4f66048788fb upstream. Instead of a void function, return the trigger pointer. Whilst not in of itself a fix, this makes the following set of 7 fixes cleaner than they would otherwise be. Signed-off-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c804c77070b537e86e5ecc0dae7df80a1561be67 Author: Steve French Date: Sun Sep 14 23:27:09 2014 -0500 SMB3: Fix oops when creating symlinks on smb3 commit da80659d4aa758dc6935b10ec64513f0b67bc969 upstream. We were not checking for symlink support properly for SMB2/SMB3 mounts so could oops when mounted with mfsymlinks when try to create symlink when mfsymlinks on smb2/smb3 mounts Signed-off-by: Steve French CC: Sachin Prabhu Signed-off-by: Greg Kroah-Hartman commit 1a77f346b0566094bf482a69ed7d6055d03cc572 Author: Peter Ujfalusi Date: Thu Sep 4 10:52:53 2014 +0300 ASoC: davinci-mcasp: Correct rx format unit configuration commit fe0a29e163a5d045c73faab682a8dac71c2f8012 upstream. In case of capture we should not use rotation. The reverse and mask is enough to get the data align correctly from the bus to MCU: Format data from bus after reverse (XRBUF) S16_LE: |LSB|MSB|xxx|xxx| |xxx|xxx|MSB|LSB| S24_3LE: |LSB|DAT|MSB|xxx| |xxx|MSB|DAT|LSB| S24_LE: |LSB|DAT|MSB|xxx| |xxx|MSB|DAT|LSB| S32_LE: |LSB|DAT|DAT|MSB| |MSB|DAT|DAT|LSB| With this patch all supported formats will work for playback and capture. Reported-by: Jyri Sarha (broken S24_3LE capture) Signed-off-by: Peter Ujfalusi Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 839e1c5229882314512cc07a8ed43062e48bb9ce Author: Miklos Szeredi Date: Wed Sep 24 17:56:17 2014 +0200 shmem: fix nlink for rename overwrite directory commit b928095b0a7cff7fb9fcf4c706348ceb8ab2c295 upstream. If overwriting an empty directory with rename, then need to drop the extra nlink. Test prog: #include #include #include #include int main(void) { const char *test_dir1 = "test-dir1"; const char *test_dir2 = "test-dir2"; int res; int fd; struct stat statbuf; res = mkdir(test_dir1, 0777); if (res == -1) err(1, "mkdir(\"%s\")", test_dir1); res = mkdir(test_dir2, 0777); if (res == -1) err(1, "mkdir(\"%s\")", test_dir2); fd = open(test_dir2, O_RDONLY); if (fd == -1) err(1, "open(\"%s\")", test_dir2); res = rename(test_dir1, test_dir2); if (res == -1) err(1, "rename(\"%s\", \"%s\")", test_dir1, test_dir2); res = fstat(fd, &statbuf); if (res == -1) err(1, "fstat(%i)", fd); if (statbuf.st_nlink != 0) { fprintf(stderr, "nlink is %lu, should be 0\n", statbuf.st_nlink); return 1; } return 0; } Signed-off-by: Miklos Szeredi Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 77480b9bafef1d77a99e80b45e222cb7ecfb2aa4 Author: Kees Cook Date: Thu Sep 11 09:19:31 2014 -0700 x86/kaslr: Avoid the setup_data area when picking location commit 0cacbfbeb5077b63d5d3cf6df88b14ac12ad584b upstream. The KASLR location-choosing logic needs to avoid the setup_data list memory areas as well. Without this, it would be possible to have the ASLR position stomp on the memory, ultimately causing the boot to fail. Signed-off-by: Kees Cook Tested-by: Baoquan He Cc: Vivek Goyal Cc: Rafael J. Wysocki Cc: Wei Yongjun Cc: Pavel Machek Cc: Linus Torvalds Link: http://lkml.kernel.org/r/20140911161931.GA12001@www.outflux.net Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 2a26f38e885f599c747d92b4acfd05139cf305f2 Author: Dave Young Date: Tue Aug 26 17:06:41 2014 +0800 x86 early_ioremap: Increase FIX_BTMAPS_SLOTS to 8 commit 3eddc69ffeba092d288c386646bfa5ec0fce25fd upstream. 3.16 kernel boot fail with earlyprintk=efi, it keeps scrolling at the bottom line of screen. Bisected, the first bad commit is below: commit 86dfc6f339886559d80ee0d4bd20fe5ee90450f0 Author: Lv Zheng Date: Fri Apr 4 12:38:57 2014 +0800 ACPICA: Tables: Fix table checksums verification before installation. I did some debugging by enabling both serial and efi earlyprintk, below is some debug dmesg, seems early_ioremap fails in scroll up function due to no free slot, see below dmesg output: WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:116 __early_ioremap+0x90/0x1c4() __early_ioremap(ed00c800, 00000c80) not found slot Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 3.17.0-rc1+ #204 Hardware name: Hewlett-Packard HP Z420 Workstation/1589, BIOS J61 v03.15 05/09/2013 Call Trace: dump_stack+0x4e/0x7a warn_slowpath_common+0x75/0x8e ? __early_ioremap+0x90/0x1c4 warn_slowpath_fmt+0x47/0x49 __early_ioremap+0x90/0x1c4 ? sprintf+0x46/0x48 early_ioremap+0x13/0x15 early_efi_map+0x24/0x26 early_efi_scroll_up+0x6d/0xc0 early_efi_write+0x1b0/0x214 call_console_drivers.constprop.21+0x73/0x7e console_unlock+0x151/0x3b2 ? vprintk_emit+0x49f/0x532 vprintk_emit+0x521/0x532 ? console_unlock+0x383/0x3b2 printk+0x4f/0x51 acpi_os_vprintf+0x2b/0x2d acpi_os_printf+0x43/0x45 acpi_info+0x5c/0x63 ? __acpi_map_table+0x13/0x18 ? acpi_os_map_iomem+0x21/0x147 acpi_tb_print_table_header+0x177/0x186 acpi_tb_install_table_with_override+0x4b/0x62 acpi_tb_install_standard_table+0xd9/0x215 ? early_ioremap+0x13/0x15 ? __acpi_map_table+0x13/0x18 acpi_tb_parse_root_table+0x16e/0x1b4 acpi_initialize_tables+0x57/0x59 acpi_table_init+0x50/0xce acpi_boot_table_init+0x1e/0x85 setup_arch+0x9b7/0xcc4 start_kernel+0x94/0x42d ? early_idt_handlers+0x120/0x120 x86_64_start_reservations+0x2a/0x2c x86_64_start_kernel+0xf3/0x100 Quote reply from Lv.zheng about the early ioremap slot usage in this case: """ In early_efi_scroll_up(), 2 mapping entries will be used for the src/dst screen buffer. In drivers/acpi/acpica/tbutils.c, we've improved the early table loading code in acpi_tb_parse_root_table(). We now need 2 mapping entries: 1. One mapping entry is used for RSDT table mapping. Each RSDT entry contains an address for another ACPI table. 2. For each entry in RSDP, we need another mapping entry to map the table to perform necessary check/override before installing it. When acpi_tb_parse_root_table() prints something through EFI earlyprintk console, we'll have 4 mapping entries used. The current 4 slots setting of early_ioremap() seems to be too small for such a use case. """ Thus increase the slot to 8 in this patch to fix this issue. boot-time mappings become 512 page with this patch. Signed-off-by: Dave Young Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit f50217dd76de8d20ac8ee37ce23b65fe6e9757bc Author: Stefan Bader Date: Tue Sep 2 11:16:01 2014 +0100 x86/xen: don't copy bogus duplicate entries into kernel page tables commit 0b5a50635fc916cf46e3de0b819a61fc3f17e7ee upstream. When RANDOMIZE_BASE (KASLR) is enabled; or the sum of all loaded modules exceeds 512 MiB, then loading modules fails with a warning (and hence a vmalloc allocation failure) because the PTEs for the newly-allocated vmalloc address space are not zero. WARNING: CPU: 0 PID: 494 at linux/mm/vmalloc.c:128 vmap_page_range_noflush+0x2a1/0x360() This is caused by xen_setup_kernel_pagetables() copying level2_kernel_pgt into level2_fixmap_pgt, overwriting many non-present entries. Without KASLR, the normal kernel image size only covers the first half of level2_kernel_pgt and module space starts after that. L4[511]->level3_kernel_pgt[510]->level2_kernel_pgt[ 0..255]->kernel [256..511]->module [511]->level2_fixmap_pgt[ 0..505]->module This allows 512 MiB of of module vmalloc space to be used before having to use the corrupted level2_fixmap_pgt entries. With KASLR enabled, the kernel image uses the full PUD range of 1G and module space starts in the level2_fixmap_pgt. So basically: L4[511]->level3_kernel_pgt[510]->level2_kernel_pgt[0..511]->kernel [511]->level2_fixmap_pgt[0..505]->module And now no module vmalloc space can be used without using the corrupt level2_fixmap_pgt entries. Fix this by properly converting the level2_fixmap_pgt entries to MFNs, and setting level1_fixmap_pgt as read-only. A number of comments were also using the the wrong L3 offset for level2_kernel_pgt. These have been corrected. Signed-off-by: Stefan Bader Signed-off-by: David Vrabel Reviewed-by: Boris Ostrovsky Signed-off-by: Greg Kroah-Hartman commit 2edbf3c6af0f5f1f9d2ef00a15339c10beaff405 Author: Ross Lagerwall Date: Mon Aug 18 10:41:36 2014 +0100 xen/manage: Always freeze/thaw processes when suspend/resuming commit 61a734d305e16944b42730ef582a7171dc733321 upstream. Always freeze processes when suspending and thaw processes when resuming to prevent a race noticeable with HVM guests. This prevents a deadlock where the khubd kthread (which is designed to be freezable) acquires a usb device lock and then tries to allocate memory which requires the disk which hasn't been resumed yet. Meanwhile, the xenwatch thread deadlocks waiting for the usb device lock. Freezing processes fixes this because the khubd thread is only thawed after the xenwatch thread finishes resuming all the devices. Signed-off-by: Ross Lagerwall Signed-off-by: David Vrabel Signed-off-by: Greg Kroah-Hartman commit 52446fb9b34505cb168b5cebe2274b24b69fc7f6 Author: Christian Borntraeger Date: Thu Aug 28 23:44:57 2014 +0200 KVM: s390/mm: Fix guest storage key corruption in ptep_set_access_flags commit 1951497d90d6754201af3e65241a06f9ef6755cd upstream. commit 0944fe3f4a32 ("s390/mm: implement software referenced bits") triggered another paging/storage key corruption. There is an unhandled invalid->valid pte change where we have to set the real storage key from the pgste. When doing paging a guest page might be swapcache or swap and when faulted in it might be read-only and due to a parallel scan old. An do_wp_page will make it writeable and young. Due to software reference tracking this page was invalid and now becomes valid. Signed-off-by: Christian Borntraeger Acked-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 379c54e876e3d4e25e31d4e09c1724458e515c53 Author: Christian Borntraeger Date: Thu Aug 28 21:21:41 2014 +0200 KVM: s390/mm: Fix storage key corruption during swapping commit 3e03d4c46daa849880837d802e41c14132a03ef9 upstream. Since 3.12 or more precisely commit 0944fe3f4a32 ("s390/mm: implement software referenced bits") guest storage keys get corrupted during paging. This commit added another valid->invalid translation for page tables - namely ptep_test_and_clear_young. We have to transfer the storage key into the pgste in that case. Signed-off-by: Christian Borntraeger Acked-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit b44f41fa64679b93f22e184767fccd1311ff04cc Author: Christian Borntraeger Date: Tue Aug 19 16:19:35 2014 +0200 KVM: s390/mm: try a cow on read only pages for key ops commit ab3f285f227fec62868037e9b1b1fd18294a83b8 upstream. The PFMF instruction handler blindly wrote the storage key even if the page was mapped R/O in the host. Lets try a COW before continuing and bail out in case of errors. Signed-off-by: Christian Borntraeger Reviewed-by: Dominik Dingel Signed-off-by: Greg Kroah-Hartman commit 8966cb2bab57936a01e75df15b49f8a469aca58d Author: Christian Borntraeger Date: Wed Aug 6 16:17:58 2014 +0200 KVM: s390: Fix user triggerable bug in dead code commit 614a80e474b227cace52fd6e3c790554db8a396e upstream. In the early days, we had some special handling for the KVM_EXIT_S390_SIEIC exit, but this was gone in 2009 with commit d7b0b5eb3000 (KVM: s390: Make psw available on all exits, not just a subset). Now this switch statement is just a sanity check for userspace not messing with the kvm_run structure. Unfortunately, this allows userspace to trigger a kernel BUG. Let's just remove this switch statement. Signed-off-by: Christian Borntraeger Reviewed-by: Cornelia Huck Reviewed-by: David Hildenbrand Signed-off-by: Greg Kroah-Hartman commit e8c35a7604d19cd4f9b3ff4015faab8acb7b782c Author: Zefan Li Date: Thu Sep 18 17:28:46 2014 +0800 cgroup: fix unbalanced locking commit eb4aec84d6bdf98d00cedb41c18000f7a31e648a upstream. cgroup_pidlist_start() holds cgrp->pidlist_mutex and then calls pidlist_array_load(), and cgroup_pidlist_stop() releases the mutex. It is wrong that we release the mutex in the failure path in pidlist_array_load(), because cgroup_pidlist_stop() will be called no matter if cgroup_pidlist_start() returns errno or not. Fixes: 4bac00d16a8760eae7205e41d2c246477d42a210 Signed-off-by: Zefan Li Signed-off-by: Tejun Heo Acked-by: Cong Wang Signed-off-by: Greg Kroah-Hartman commit 7d73a89ba1408035381e19a0e890a4aaf15d0ec5 Author: Li Zefan Date: Thu Sep 4 14:43:07 2014 +0800 cgroup: delay the clearing of cgrp->kn->priv commit a4189487da1b4f8260c6006b9dc47c3c4107a5ae upstream. Run these two scripts concurrently: for ((; ;)) { mkdir /cgroup/sub rmdir /cgroup/sub } for ((; ;)) { echo $$ > /cgroup/sub/cgroup.procs echo $$ > /cgroup/cgroup.procs } A kernel bug will be triggered: BUG: unable to handle kernel NULL pointer dereference at 00000038 IP: [] cgroup_put+0x9/0x80 ... Call Trace: [] cgroup_kn_unlock+0x39/0x50 [] cgroup_kn_lock_live+0x61/0x70 [] __cgroup_procs_write.isra.26+0x51/0x230 [] cgroup_tasks_write+0x12/0x20 [] cgroup_file_write+0x40/0x130 [] kernfs_fop_write+0xd1/0x160 [] vfs_write+0x98/0x1e0 [] SyS_write+0x4d/0xa0 [] sysenter_do_call+0x12/0x12 We clear cgrp->kn->priv in the end of cgroup_rmdir(), but another concurrent thread can access kn->priv after the clearing. We should move the clearing to css_release_work_fn(). At that time no one is holding reference to the cgroup and no one can gain a new reference to access it. v2: - move RCU_INIT_POINTER() into the else block. (Tejun) - remove the cgroup_parent() check. (Tejun) - update the comment in css_tryget_online_from_dir(). Reported-by: Toralf Förster Signed-off-by: Zefan Li Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 767f5ccd772e406f493e85edcb3503e4ef8d1ca7 Author: Alban Crequy Date: Mon Aug 18 12:20:20 2014 +0100 cgroup: reject cgroup names with '\n' commit 71b1fb5c4473a5b1e601d41b109bdfe001ec82e0 upstream. /proc//cgroup contains one cgroup path on each line. If cgroup names are allowed to contain "\n", applications cannot parse /proc//cgroup safely. Signed-off-by: Alban Crequy Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 6ea8d7ba04553016f90773ca333dc424be8770c6 Author: Mark Brown Date: Wed Aug 27 13:09:12 2014 +0100 regmap: Don't attempt block writes when syncing cache on single_rw devices commit 5c1ebe7f73f9166893c3459915db8a09d6d1d715 upstream. If the device can't support block writes then don't attempt to use raw syncing which will automatically generate block writes for adjacent registers, use the existing _single() block syncing implementation. Reported-by: Jarkko Nikula Tested-by: Jarkko Nikula Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 081f1af7d8481219ee8ba1ef19446565cf707631 Author: Mark Brown Date: Tue Aug 26 12:12:17 2014 +0100 regmap: Fix handling of volatile registers for format_write() chips commit 5844a8b9d98ec11ce1d77610daacf3f0a0e14715 upstream. A previous over-zealous factorisation of code means that we only treat registers as volatile if they are readable. For most devices this is fine since normally most registers can be read and volatility implies readability but for format_write() devices where there is no readback from the hardware and we use volatility to mean simply uncacheability this means that we end up treating all registers as cacheble. A bigger refactoring of the code to clarify this is in order but as a fix make a minimal change and only check readability when checking volatility if there is no format_write() operation defined for the device. Signed-off-by: Mark Brown Tested-by: Lars-Peter Clausen Signed-off-by: Greg Kroah-Hartman commit 9d734ff1dd4e23cd362d21c59bd030302b9178c7 Author: Lars-Peter Clausen Date: Sun Aug 24 15:32:27 2014 +0200 regmap: Fix regcache debugfs initialization commit 5e0cbe78762b5f02986bf9e59a188dad2f6e0be1 upstream. Commit 6cfec04bcc05 ("regmap: Separate regmap dev initialization") moved the regmap debugfs initialization after regcache initialization. This means that the regmap debugfs directory is not created yet when the cache initialization runs and so any debugfs files registered by the regcache are created in the debugfs root directory rather than the debugfs directory of the regmap instance. Fix this by adding a separate callback for the regcache debugfs initialization which will be called after the parent debugfs entry has been created. Fixes: 6cfec04bcc05 (regmap: Separate regmap dev initialization) Signed-off-by: Lars-Peter Clausen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2aa79d56e12145039e1de5508a859ac79f20c5dd Author: Tang Chen Date: Fri Aug 29 15:18:31 2014 -0700 memblock, memhotplug: fix wrong type in memblock_find_in_range_node(). commit 0cfb8f0c3e21e36d4a6e472e4c419d58ba848698 upstream. In memblock_find_in_range_node(), we defined ret as int. But it should be phys_addr_t because it is used to store the return value from __memblock_find_range_bottom_up(). The bug has not been triggered because when allocating low memory near the kernel end, the "int ret" won't turn out to be negative. When we started to allocate memory on other nodes, and the "int ret" could be minus. Then the kernel will panic. A simple way to reproduce this: comment out the following code in numa_init(), memblock_set_bottom_up(false); and the kernel won't boot. Reported-by: Xishi Qiu Signed-off-by: Tang Chen Tested-by: Xishi Qiu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit dcb67d612aa0b3ec1b72b4aafeb4a8f101cea244 Author: Catalin Marinas Date: Fri Aug 29 16:08:02 2014 +0100 arm64: Add brackets around user_stack_pointer() commit 2520d039728b2a3c5ae7f79fe2a0e9d182855b12 upstream. Commit 5f888a1d33 (ARM64: perf: support dwarf unwinding in compat mode) changes user_stack_pointer() to return the compat SP for 32-bit tasks but without brackets around the whole definition, with possible issues on the call sites (noticed with a subsequent fix for KSTK_ESP). Fixes: 5f888a1d33c4 (ARM64: perf: support dwarf unwinding in compat mode) Reported-by: Sudeep Holla Signed-off-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit d1129accd493962045685aff229acfc6ef2501b3 Author: Aaron Lu Date: Fri Sep 19 10:01:18 2014 +0800 ACPI / video: disable native backlight for ThinkPad X201s commit 789eeea128925741e0a105357bebf8855d3bcdee upstream. The ThinkPad X201s has a working ACPI video backlight interface and is shipped before Win8; then there is BIOS update that starts to query _OSI("Windows 2012") and that would make our video module stop creating backlight interface and caused problem for the user. Add it to the DMI table to disable native backlight to fix this problem. Link: https://bugzilla.kernel.org/show_bug.cgi?id=81691 Link: https://bugzilla.kernel.org/show_bug.cgi?id=51231 Reported-and-tested-by: Yves-Alexis Perez Signed-off-by: Aaron Lu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 71f2d795ab0fad48751728c347562486af566c1f Author: Mika Westerberg Date: Fri Sep 12 11:33:10 2014 +0300 ACPI / scan: Correct error return value of create_modalias() commit 98d28d0e59160d2d6cb3f6a9050723ac40f89669 upstream. There is a typo, it should be negative -errno instead. Signed-off-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit fffa93ce4430c0615041067d3db71f61baab0bd8 Author: Rafael J. Wysocki Date: Sun Sep 21 02:58:18 2014 +0200 ACPI / hotplug: Generate online uevents for ACPI containers commit 8ab17fc92e49bc2b8fff9d220c19bf50ec9c1158 upstream. Commit 46394fd01 (ACPI / hotplug: Move container-specific code out of the core) removed the generation of "online" uevents for containers, because "add" uevents are now generated for them automatically when container system devices are registered. However, there are user space tools that need to be notified when the container and all of its children have been enumerated, which doesn't happen any more. For this reason, add a mechanism allowing "online" uevents to be generated for ACPI containers after enumerating the container along with all of its children. Fixes: 46394fd01 (ACPI / hotplug: Move container-specific code out of the core) Reported-and-tested-by: Yasuaki Ishimatsu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit b9d39ba1d4566df3ffc2cc6963efa3a1c3abfc27 Author: Fu Zhonghui Date: Wed Sep 24 22:42:26 2014 +0200 ACPI / platform / LPSS: disable async suspend/resume of LPSS devices commit 457920817e645a7dee42c2a75c81c5ed8e12ee1c upstream. On some systems (Asus T100 in particular) there are strict ordering dependencies between LPSS devices with respect to power management that break if they suspend/resume asynchronously. In theory it should be possible to follow those dependencies in the async suspend/resume case too (the ACPI tables tell as that the dependencies are there), but since we're missing infrastructure for that at the moment, disable async suspend/resume for all of the LPSS devices for the time being. Link: http://marc.info/?l=linux-acpi&m=141158962321905&w=2 Fixes: 8ce62f85a81f (ACPI / platform / LPSS: Enable async suspend/resume of LPSS devices) Signed-off-by: Li Aubrey Signed-off-by: Fu Zhonghui [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit fca4e9a750580dcbf23510f575d059c0b713432e Author: Srinivas Pandruvada Date: Tue Sep 23 10:35:54 2014 +0800 gpio / ACPI: Use pin index and bit length commit c15d821ddb9dac9ac6b5beb75bf942f3bc3a4004 upstream. Fix code when the operation region callback is for an gpio, which is not at index 0 and for partial pins in a GPIO definition. For example: Name (GMOD, ResourceTemplate () { //3 Outputs that define the Power mode of the device GpioIo (Exclusive, PullDown, , , , "\\_SB.GPI2") {10, 11, 12} }) } If opregion callback calls is for: - Set pin 10, then address = 0 and bit length = 1 - Set pin 11, then address = 1 and bit length = 1 - Set for both pin 11 and pin 12, then address = 1, bit length = 2 This change requires updated ACPICA gpio operation handler code to send the pin index and bit length. Fixes: 473ed7be0da0 (gpio / ACPI: Add support for ACPI GPIO operation regions) Signed-off-by: Srinivas Pandruvada Acked-by: Mika Westerberg Acked-by: Linus Walleij Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit e1c00abb4dec4fc1563637b0d59d8f34dea45c74 Author: Bob Moore Date: Tue Sep 23 10:35:47 2014 +0800 ACPICA: Update to GPIO region handler interface. commit 75ec6e55f1384548311a13ce4fcb39c516053314 upstream. Changes to correct several GPIO issues: 1) The update_rule in a GPIO field definition is now ignored; a read-modify-write operation is never performed for GPIO fields. (Internally, this means that the field assembly/disassembly code is completely bypassed for GPIO.) 2) The Address parameter passed to a GPIO region handler is now the bit offset of the field from a previous Connection() operator. Thus, it becomes a "Pin Number Index" into the Connection() resource descriptor. 3) The bit_width parameter passed to a GPIO region handler is now the exact bit width of the GPIO field. Thus, it can be interpreted as "number of pins". Overall, we can now say that the region handler interface to GPIO handlers is a raw "bit/pin" addressed interface, not a byte-addressed interface like the system_memory handler interface. Signed-off-by: Bob Moore Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 51a1a1b93a9d8915df20dbf1fd2fac220434712c Author: Markos Chandras Date: Tue Sep 16 15:55:12 2014 +0100 MIPS: mcount: Adjust stack pointer for static trace in MIPS32 commit 8a574cfa2652545eb95595d38ac2a0bb501af0ae upstream. Every mcount() call in the MIPS 32-bit kernel is done as follows: [...] move at, ra jal _mcount addiu sp, sp, -8 [...] but upon returning from the mcount() function, the stack pointer is not adjusted properly. This is explained in details in 58b69401c797 (MIPS: Function tracer: Fix broken function tracing). Commit ad8c396936e3 ("MIPS: Unbreak function tracer for 64-bit kernel.) fixed the stack manipulation for 64-bit but it didn't fix it completely for MIPS32. Signed-off-by: Markos Chandras Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7792/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 52e43746a7448b504a798da4e0909d645fa15dfb Author: Paul Burton Date: Wed Sep 24 10:45:37 2014 +0100 MIPS: Fix MFC1 & MFHC1 emulation for 64-bit MIPS systems commit c8c0da6bdf0f0d6f59fc23aab6ee373a131df82d upstream. Commit bbd426f542cb "MIPS: Simplify FP context access" modified the SIFROMREG & SIFROMHREG macros such that they return unsigned rather than signed 32b integers. I had believed that to be fine, but inadvertently missed the MFC1 & MFHC1 cases which write to a struct pt_regs regs element. On MIPS32 this is fine, but on 64 bit those saved regs' fields are 64 bit wide. Using unsigned values caused the 32 bit value from the FP register to be zero rather than sign extended as the architecture specifies, causing incorrect emulation of the MFC1 & MFHc1 instructions. Fix by reintroducing the casts to signed integers, and therefore the sign extension. Signed-off-by: Paul Burton Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7848/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 81436c3ec7cc2ded5e94b06c8f95a22b343e8733 Author: Aurelien Jarno Date: Sun Jul 20 19:58:23 2014 +0200 MIPS: ZBOOT: add missing include commit 29593fd5a8149462ed6fad0d522234facdaee6c8 upstream. Commit dc4d7b37 (MIPS: ZBOOT: gather string functions into string.c) moved the string related functions into a separate file, which might cause the following build error, depending on the configuration: | CC arch/mips/boot/compressed/decompress.o | In file included from linux/arch/mips/boot/compressed/../../../../lib/decompress_unxz.c:234:0, | from linux/arch/mips/boot/compressed/decompress.c:67: | linux/arch/mips/boot/compressed/../../../../lib/xz/xz_dec_stream.c: In function 'fill_temp': | linux/arch/mips/boot/compressed/../../../../lib/xz/xz_dec_stream.c:162:2: error: implicit declaration of function 'memcpy' [-Werror=implicit-function-declaration] | cc1: some warnings being treated as errors | linux/scripts/Makefile.build:308: recipe for target 'arch/mips/boot/compressed/decompress.o' failed | make[6]: *** [arch/mips/boot/compressed/decompress.o] Error 1 | linux/arch/mips/Makefile:308: recipe for target 'vmlinuz' failed It does not fail with the standard configuration, as when CONFIG_DYNAMIC_DEBUG is not enabled gets included in include/linux/dynamic_debug.h. There might be other ways for it to get indirectly included. We can't add the include directly in xz_dec_stream.c as some architectures might want to use a different version for the boot/ directory (see for example arch/x86/boot/string.h). Signed-off-by: Aurelien Jarno Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7420/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 3a4e1d1dc714a3ae9bb29b1c4ab605a03d0fa5d7 Author: Nathan Lynch Date: Mon Sep 29 19:11:36 2014 +0100 ARM: 8178/1: fix set_tls for !CONFIG_KUSER_HELPERS commit 9cc6d9e5daaa147a9a3e31557efcb331989e77be upstream. Joachim Eastwood reports that commit fbfb872f5f41 "ARM: 8148/1: flush TLS and thumbee register state during exec" causes a boot-time crash on a Cortex-M4 nommu system: Freeing unused kernel memory: 68K (281e5000 - 281f6000) Unhandled exception: IPSR = 00000005 LR = fffffff1 CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-rc6-00313-gd2205fa30aa7 #191 task: 29834000 ti: 29832000 task.ti: 29832000 PC is at flush_thread+0x2e/0x40 LR is at flush_thread+0x21/0x40 pc : [<2800954a>] lr : [<2800953d>] psr: 4100000b sp : 29833d60 ip : 00000000 fp : 00000001 r10: 00003cf8 r9 : 29b1f000 r8 : 00000000 r7 : 29b0bc00 r6 : 29834000 r5 : 29832000 r4 : 29832000 r3 : ffff0ff0 r2 : 29832000 r1 : 00000000 r0 : 282121f0 xPSR: 4100000b CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-rc6-00313-gd2205fa30aa7 #191 [<2800afa5>] (unwind_backtrace) from [<2800a327>] (show_stack+0xb/0xc) [<2800a327>] (show_stack) from [<2800a963>] (__invalid_entry+0x4b/0x4c) The problem is that set_tls is attempting to clear the TLS location in the kernel-user helper page, which isn't set up on V7M. Fix this by guarding the write to the kuser helper page with a CONFIG_KUSER_HELPERS ifdef. Fixes: fbfb872f5f41 ARM: 8148/1: flush TLS and thumbee register state during exec Reported-by: Joachim Eastwood Tested-by: Joachim Eastwood Signed-off-by: Nathan Lynch Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit e5b83a046d6faaa75788b4e494e70c4d33e107a0 Author: Robin Murphy Date: Thu Sep 25 11:56:19 2014 +0100 ARM: 8165/1: alignment: don't break misaligned NEON load/store commit 5ca918e5e3f9df4634077c06585c42bc6a8d699a upstream. The alignment fixup incorrectly decodes faulting ARM VLDn/VSTn instructions (where the optional alignment hint is given but incorrect) as LDR/STR, leading to register corruption. Detect these and correctly treat them as unhandled, so that userspace gets the fault it expects. Reported-by: Simon Hosie Signed-off-by: Robin Murphy Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 32e8dec8c2d2eec2098e4bc96969077c2a27323d Author: Shawn Guo Date: Tue Sep 16 09:35:33 2014 +0800 ARM: imx: fix .is_enabled() of shared gate clock commit 9e1ac462b982f496ed3b491f02c417dcc8e40347 upstream. Commit 63288b721a80 ("ARM: imx: fix shared gate clock") attempted to fix an issue with particular enable/disable sequence from two shared gate clocks. But unfortunately, while it partially fixed the issue, it also did something wrong in .is_enabled() function hook. In case of shared gate, the function shouldn't really query the hardware state via share_count, because the function is trying to query the enabling state of the clock in question, not the hardware state which is shared by multiple clocks. Fix the issue by returning the enable_count of the clock itself which is maintained by clock core, in case it's a clock sharing hardware gate with others. As the result, the initialization of share_count per hardware state is not needed now. So remove it. Reported-by: Fabio Estevam Fixes: 63288b721a80 ("ARM: imx: fix shared gate clock") Signed-off-by: Shawn Guo Tested-by: Fabio Estevam Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman commit fb69ff7f970d7845532080286b208702280f5f39 Author: Markus Niebel Date: Thu Sep 11 15:56:56 2014 +0800 ARM: DT: imx53: fix lvds channel 1 port commit 1b134c9c4b555342be667f144ee714af1c3f6a9f upstream. using LVDS channel 1 on an i.MX53 leads to following error: imx-ldb 53fa8008.ldb: unable to set di0 parent clock to ldb_di1 This comes from imx_ldb_set_clock with mux = 0. Mux parameter must be "1" for reparenting di1 clock to ldb_di1. The value of the mux param comes from device tree port settings. On i.MX5, the internal two-input-multiplexer is used. Due to hardware limitations, only one port (port@[0,1]) can be used for each channel (lvds-channel@[0,1], respectively) Documentation update suggested by Philipp Zabel Signed-off-by: Markus Niebel Fixes: e05c8c9a790a ("ARM: dts: imx53: Add IPU DI ports and endpoints, move imx-drm node to dtsi") Acked-by: Philipp Zabel Signed-off-by: Shawn Guo Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit db4900c712f47371de6d4e711dc23d7acecd9938 Author: Roger Quadros Date: Wed Sep 10 08:57:11 2014 -0700 ARM: dts: dra7-evm: Fix NAND GPMC timings commit 5990047cef0c6a36eefcb166bd32d99a8f95c75b upstream. The nand timings were scaled down by 2 to account for the 2x rate returned by clk_get_rate(gpmc_fclk). As the clock data got fixed by [1], revert back to actual timings (i.e. scale them up by 2). Without this NAND doesn't work on dra7-evm. [1] - commit dd94324b983afe114ba9e7ee3649313b451f63ce ARM: dts: dra7xx-clocks: Fix the l3 and l4 clock rates Fixes: ff66a3c86e00 ("ARM: dts: dra7: add support for parallel NAND flash") Signed-off-by: Roger Quadros Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 43f51ede5c6b99b34cfdc42c6e198df28f621c70 Author: Stephen Boyd Date: Thu Sep 11 23:25:30 2014 +0100 ARM: 8149/1: perf: Don't sleep while atomic when enabling per-cpu interrupts commit 505013bc9065391f09a51d51cd3bf0b06dfb570a upstream. Rob Clark reports a sleeping while atomic bug when using perf. BUG: sleeping function called from invalid context at ../kernel/locking/mutex.c:583 in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 4828 at ../kernel/locking/mutex.c:479 mutex_lock_nested+0x3a0/0x3e8() DEBUG_LOCKS_WARN_ON(in_interrupt()) Modules linked in: CPU: 2 PID: 4828 Comm: Xorg.bin Tainted: G W 3.17.0-rc3-00234-gd535c45-dirty #819 [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x98/0xb8) [] (dump_stack) from [] (warn_slowpath_common+0x70/0x8c) [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40) [] (warn_slowpath_fmt) from [] (mutex_lock_nested+0x3a0/0x3e8) [] (mutex_lock_nested) from [] (irq_find_host+0x20/0x9c) [] (irq_find_host) from [] (of_irq_get+0x28/0x48) [] (of_irq_get) from [] (platform_get_irq+0x1c/0x8c) [] (platform_get_irq) from [] (cpu_pmu_enable_percpu_irq+0x14/0x38) [] (cpu_pmu_enable_percpu_irq) from [] (flush_smp_call_function_queue+0x88/0x178) [] (flush_smp_call_function_queue) from [] (handle_IPI+0x88/0x160) [] (handle_IPI) from [] (gic_handle_irq+0x64/0x68) [] (gic_handle_irq) from [] (__irq_svc+0x44/0x5c) Exception stack(0xe63ddea0 to 0xe63ddee8) dea0: 00000001 00000001 00000000 c2f3b200 c16db380 c032d4a0 e63ddf40 60010013 dec0: 00000000 001fbfd4 00000100 00000000 00000001 e63ddee8 c0284770 c02a2e30 dee0: 20010013 ffffffff [] (__irq_svc) from [] (ktime_get_ts64+0x1c8/0x200) [] (ktime_get_ts64) from [] (poll_select_set_timeout+0x60/0xa8) [] (poll_select_set_timeout) from [] (SyS_select+0xa8/0x118) [] (SyS_select) from [] (ret_fast_syscall+0x0/0x48) ---[ end trace 0bb583b46342da6f ]--- INFO: lockdep is turned off. We don't really need to get the platform irq again when we're enabling or disabling the per-cpu irq. Furthermore, we don't really need to set and clear bits in the active_irqs bitmask because that's only used in the non-percpu irq case to figure out when the last CPU PMU has been disabled. Just pass the irq directly to the enable/disable functions to clean all this up. This should be slightly more efficient and also fix the scheduling while atomic bug. Fixes: bbd64559376f "ARM: perf: support percpu irqs for the CPU PMU" Reported-by: Rob Clark Acked-by: Will Deacon Signed-off-by: Stephen Boyd Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 6e0a6583f9f6b464e56a33a1722074fd63c8a0b0 Author: Nathan Lynch Date: Thu Sep 11 02:49:08 2014 +0100 ARM: 8148/1: flush TLS and thumbee register state during exec commit fbfb872f5f417cea48760c535e0ff027c88b507a upstream. The TPIDRURO and TPIDRURW registers need to be flushed during exec; otherwise TLS information is potentially leaked. TPIDRURO in particular needs careful treatment. Since flush_thread basically needs the same code used to set the TLS in arm_syscall, pull that into a common set_tls helper in tls.h and use it in both places. Similarly, TEEHBR needs to be cleared during exec as well. Clearing its save slot in thread_info isn't right as there is no guarantee that a thread switch will occur before the new program runs. Just setting the register directly is sufficient. Signed-off-by: Nathan Lynch Acked-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit a47061a121afea42ce3fbe9cc42dba168182529b Author: Sudeep Holla Date: Mon Sep 1 17:14:29 2014 +0100 ARM: 8133/1: use irq_set_affinity with force=false when migrating irqs commit a040803a9d6b8c1876d3487a5cb69602ebcbb82c upstream. Since commit 1dbfa187dad ("ARM: irq migration: force migration off CPU going down") the ARM interrupt migration code on cpu offline calls irqchip.irq_set_affinity() with the argument force=true. At the point of this change the argument had no effect because it was not used by any interrupt chip driver and there was no semantics defined. This changed with commit 01f8fa4f01d8 ("genirq: Allow forcing cpu affinity of interrupts") which made the force argument useful to route interrupts to not yet online cpus without checking the target cpu against the cpu online mask. The following commit ffde1de64012 ("irqchip: gic: Support forced affinity setting") implemented this for the GIC interrupt controller. As a consequence the ARM cpu offline irq migration fails if CPU0 is offlined, because CPU0 is still set in the affinity mask and the validataion against cpu online mask is skipped to the force argument being true. The following first_cpu(mask) selection always selects CPU0 as the target. Solve the issue by calling irq_set_affinity() with force=false from the CPU offline irq migration code so the GIC driver validates the affinity mask against CPU online mask and therefore removes CPU0 from the possible target candidates. Tested on TC2 hotpluging CPU0 in and out. Without this patch the system locks up as the IRQs are not migrated away from CPU0. Signed-off-by: Sudeep Holla Acked-by: Thomas Gleixner Acked-by: Mark Rutland Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 66992f5c7451c32b5bbfbc1319571e3296b961f6 Author: Nishanth Menon Date: Thu Sep 4 08:33:37 2014 -0500 ARM: dts: dra7-evm: Fix spi1 mux documentation commit 68e4d9e58dbae2fb178e8b74806f521adb16f0d3 upstream. While auditing the various pin ctrl configurations using the following command: grep PIN_ arch/arm/boot/dts/dra7-evm.dts|(while read line; do v=`echo "$line" | sed -e "s/\s\s*/|/g" | cut -d '|' -f1 | cut -d 'x' -f2|tr [a-z] [A-Z]`; HEX=`echo "obase=16;ibase=16;4A003400+$v"| bc`; echo "$HEX ===> $line"; done) against DRA75x/74x NDA TRM revision S(SPRUHI2S August 2014), documentation errors were found for spi1 pinctrl. Fix the same. Fixes: 6e58b8f1daaf1af ("ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board") Signed-off-by: Nishanth Menon Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit f5c7b897bed163874913596cdb874e097d770a16 Author: Peter Ujfalusi Date: Mon Aug 4 15:26:56 2014 +0300 ARM: edma: Fix configuration parsing for SoCs with multiple eDMA3 CC commit 929a015b1809a30748d487f9d25b16a41434b61a upstream. The edma_setup_from_hw() should know about the CC number when parsing the CCCFG register - when it reads the register to be precise. The base addresses for CCs stored in an array and we need to provide the correct id to edma_read() in order to read the correct register. Signed-off-by: Peter Ujfalusi Signed-off-by: Sekhar Nori Signed-off-by: Greg Kroah-Hartman commit 81e96655afdadfb73f54da071c6086752f1cf718 Author: Nishanth Menon Date: Mon Aug 25 16:15:34 2014 -0700 ARM: dts: DRA7: fix interrupt-cells for GPIO commit e49d519c456f4fb6f4a0473bc04ba30bb805fce5 upstream. GPIO modules are also interrupt sources. However, they require both the GPIO number and IRQ type to function properly. By declaring that GPIO uses interrupt-cells=<1>, we essentially do not allow users of the nodes to use the interrupt property appropritely. With this change, the following now works: interrupt-parent = <&gpio6>; interrupts = <5 IRQ_TYPE_LEVEL_LOW>; Fixes: 6e58b8f1daaf ('ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board') Signed-off-by: Nishanth Menon Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 2f2b0f4d2654c05e5f757896be623f5768abe968 Author: Rajendra Nayak Date: Wed Aug 27 19:38:23 2014 -0600 ARM: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists commit f7f7a29bf0cf25af23f37e5b5bf1368b85705286 upstream. To deal with IPs which are specific to dra74x and dra72x, maintain seperate ocp interface lists, while keeping the common list for all common IPs. Move USB OTG SS4 to dra74x only list since its unavailable in dra72x and is giving an abort during boot. The dra72x only list is empty for now and a placeholder for future hwmod additions which are specific to dra72x. Fixes: d904b38df0db13 ("ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss") Reported-by: Keerthy Signed-off-by: Rajendra Nayak Signed-off-by: Lokesh Vutla Tested-by: Nishanth Menon [paul@pwsan.com: fixed comment style to conform with CodingStyle] Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit be35ff0f45bf85f0390b3fda3c6df6fc55fa4117 Author: Fabio Estevam Date: Thu Aug 7 15:01:33 2014 -0300 ARM: dts: imx53-qsrb: Fix suspend/resume commit 090727b880ff3c56e333f267cc24ab076f3bc096 upstream. The following error is seen after a suspend/resume cycle on a mx53qsb with a MC34708 PMIC: root@freescale /$ echo mem > /sys/power/state [ 32.630592] PM: Syncing filesystems ... done. [ 32.643924] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 32.652384] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 32.679156] PM: suspend of devices complete after 13.113 msecs [ 32.685128] PM: suspend devices took 0.030 seconds [ 32.696109] PM: late suspend of devices complete after 6.133 msecs [ 33.313032] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 33.322009] PM: noirq suspend of devices complete after 619.667 msecs [ 33.328544] Disabling non-boot CPUs ... [ 33.335031] PM: noirq resume of devices complete after 2.352 msecs [ 33.842940] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 33.976095] [sched_delayed] sched: RT throttling activated [ 33.984804] PM: early resume of devices complete after 642.642 msecs [ 34.352954] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 34.862910] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 34.996595] PM: resume of devices complete after 1005.367 msecs [ 35.372925] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 35.882911] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 35.955707] PM: resume devices took 1.970 seconds [ 35.960445] Restarting tasks ... done. [ 35.993386] fec 63fec000.ethernet eth0: Link is Down [ 36.392980] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 36.902908] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 36.953036] ata1: SATA link down (SStatus 0 SControl 300) [ 37.412922] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 37.922906] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 37.993379] fec 63fec000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 38.432938] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 38.942920] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 39.452933] mc13xxx 0-0008: Failed to read IRQ status: -110 (flood of this error message continues forever) Commit 5169df8be0a432ee ("ARM: dts: i.MX53: add support for MCIMX53-START-R") missed to configure the IOMUX for the PMIC IRQ pin. Configure the PMIC IRQ pin so that the suspend/resume sequence behaves cleanly as expected. Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 25e9a200895398fb8d384ad792bb3190b9787c43 Author: Mark Rutland Date: Fri Aug 15 12:11:50 2014 +0100 ARM: 8129/1: errata: work around Cortex-A15 erratum 830321 using dummy strex commit 2c32c65e3726c773760038910be30cce1b4d4149 upstream. On revisions of Cortex-A15 prior to r3p3, a CLREX instruction at PL1 may falsely trigger a watchpoint exception, leading to potential data aborts during exception return and/or livelock. This patch resolves the issue in the following ways: - Replacing our uses of CLREX with a dummy STREX sequence instead (as we did for v6 CPUs). - Removing the clrex code from v7_exit_coherency_flush and derivatives, since this only exists as a minor performance improvement when non-cached exclusives are in use (Linux doesn't use these). Benchmarking on a variety of ARM cores revealed no measurable performance difference with this change applied, so the change is performed unconditionally and no new Kconfig entry is added. Signed-off-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 6b6957ff82d8faef6cd072f409ce0cce010501d6 Author: Mark Rutland Date: Fri Aug 15 12:11:49 2014 +0100 ARM: 8128/1: abort: don't clear the exclusive monitors commit 85868313177700d20644263a782351262d2aff84 upstream. The ARMv6 and ARMv7 early abort handlers clear the exclusive monitors upon entry to the kernel, but this is redundant: - We clear the monitors on every exception return since commit 200b812d0084 ("Clear the exclusive monitor when returning from an exception"), so this is not necessary to ensure the monitors are cleared before returning from a fault handler. - Any dummy STREX will target a temporary scratch area in memory, and may succeed or fail without corrupting useful data. Its status value will not be used. - Any other STREX in the kernel must be preceded by an LDREX, which will initialise the monitors consistently and will not depend on the earlier state of the monitors. Therefore we have no reason to care about the initial state of the exclusive monitors when a data abort is taken, and clearing the monitors prior to exception return (as we already do) is sufficient. This patch removes the redundant clearing of the exclusive monitors from the early abort handlers. Signed-off-by: Mark Rutland Acked-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit a3e4b7577cc0de761fff82ae3eff6507307c0d1c Author: Andy Shevchenko Date: Wed Aug 27 16:21:12 2014 +0300 spi: dw-pci: fix bug when regs left uninitialized commit c9d5d6fe168fd45a4dfdd0116affe708789b4702 upstream. The commit 04f421e7 "spi: dw: use managed resources" changes drivers to use managed functions, but seems wasn't properly tested in PCI case. The regs field of struct dw_spi left uninitialized. Thus, kernel crashes when tries to access to the SPI controller registers. This patch fixes the issue. Fixes: 04f421e7 (spi: dw: use managed resources) Signed-off-by: Andy Shevchenko Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit f05ef06f31e1c6840f3cc1d69f1d3fef252601c7 Author: Andy Shevchenko Date: Wed Aug 27 19:26:08 2014 +0300 spi: dw: fix kernel crash due to NULL pointer dereference commit 08a707b87874eaaa0f336ab604ecd6e5e9f286dd upstream. The obvious fix after the commit d9c73bb8a3a5 "spi: dw: add support for gpio controlled chip select". This patch fixes the issue by using locally defined temporary variable. Fixes: d9c73bb8a3a5 (spi: dw: add support for gpio controlled chip select) Signed-off-by: Andy Shevchenko Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5f53a1e9cf1f3d44ef269c60ea979d719716d1cf Author: Jorge A. Ventura Date: Sat Aug 9 16:06:58 2014 -0500 spi/omap-mcspi: Fix the spi task hangs waiting dma_rx commit 3d0763c006f8da1b44a9f5f9a21187f5b8f674f4 upstream. The spi hangs waiting the completion of omap2_mcspi_rx_callback. Signed-off-by: Jorge A. Ventura Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 08c01d234b4324df20b4c2d09c6950108f4d0d83 Author: Weston Andros Adamson Date: Mon Sep 15 14:14:45 2014 -0400 nfs: can_coalesce_requests must enforce contiguity commit 78270e8fbc2916bfc8305b8f58f33474cce1ec0e upstream. Commit 6094f83864c1d1296566a282cba05ba613f151ee "nfs: allow coalescing of subpage requests" got rid of the requirement that requests cover whole pages, but it made some incorrect assumptions. It turns out that callers of this interface can map adjacent requests (by file position as seen by req_offset + req->wb_bytes) to different pages, even when they could share a page. An example is the direct I/O interface - iov_iter_get_pages_alloc may return one segment with a partial page filled and the next segment (which is adjacent in the file position) starts with a new page. Reported-by: Toralf Förster Signed-off-by: Weston Andros Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 42e32385b1bf5ebcf54f638220f6c135e775fc73 Author: Weston Andros Adamson Date: Mon Sep 15 14:14:44 2014 -0400 nfs: disallow duplicate pages in pgio page vectors commit bba5c1887a925a9945d22217d38d58d8b3ba1043 upstream. Adjacent requests that share the same page are allowed, but should only use one entry in the page vector. This avoids overruning the page vector - it is sized based on how many bytes there are, not by request count. This fixes issues that manifest as "Redzone overwritten" bugs (the vector overrun) and hangs waiting on page read / write, as it waits on the same page more than once. This also adds bounds checking to the page vector with a graceful failure (WARN_ON_ONCE and pgio error returned to application). Reported-by: Toralf Förster Signed-off-by: Weston Andros Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 274a1dc919c8dc46e4517cee0e7e92e746bf16e7 Author: Weston Andros Adamson Date: Mon Sep 15 14:14:43 2014 -0400 nfs: don't sleep with inode lock in lock_and_join_requests commit 7c3af975257383ece54b83c0505d3e0656cb7daf upstream. This handles the 'nonblock=false' case in nfs_lock_and_join_requests. If the group is already locked and blocking is allowed, drop the inode lock and wait for the group lock to be cleared before trying it all again. This should fix warnings found in peterz's tree (sched/wait branch), where might_sleep() checks are added to wait.[ch]. Reported-by: Fengguang Wu Signed-off-by: Weston Andros Adamson Reviewed-by: Peng Tao Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit ae3f3485448578097a115f341733d938c357c46b Author: Weston Andros Adamson Date: Mon Sep 15 14:14:42 2014 -0400 nfs: fix error handling in lock_and_join_requests commit 94970014c46223cbcdfbfc67b89596a412f9e3dd upstream. This fixes handling of errors from nfs_page_group_lock in nfs_lock_and_join_requests. It now releases the inode lock and the reference to the head request. Reported-by: Peng Tao Signed-off-by: Weston Andros Adamson Reviewed-by: Peng Tao Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 4a2025db17aa8646bdbc318da56e2729d6431b47 Author: Weston Andros Adamson Date: Mon Sep 15 14:14:41 2014 -0400 nfs: use blocking page_group_lock in add_request commit bfd484a5606d6a0379a0a2f04251b1e5c1f8995c upstream. __nfs_pageio_add_request was calling nfs_page_group_lock nonblocking, but this can return -EAGAIN which would end up passing -EIO to the application. There is no reason not to block in this path, so change the two calls to do so. Also, there is no need to check the return value of nfs_page_group_lock when nonblock=false, so remove the error handling code. Signed-off-by: Weston Andros Adamson Reviewed-by: Peng Tao Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 28c86fda6b1d637bac19a72c5db5cce90b043b95 Author: Weston Andros Adamson Date: Mon Sep 15 14:14:40 2014 -0400 nfs: fix nonblocking calls to nfs_page_group_lock commit bc8a309e88a86205fc3e17f06e42a2e56fc6f807 upstream. nfs_page_group_lock was calling wait_on_bit_lock even when told not to block. Fix by first trying test_and_set_bit, followed by wait_on_bit_lock if and only if blocking is allowed. Return -EAGAIN if nonblocking and the test_and_set of the bit was already locked. Signed-off-by: Weston Andros Adamson Reviewed-by: Peng Tao Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 6483253a3f2ce76bee51e0ac7f98d6c0ee8df08d Author: Weston Andros Adamson Date: Mon Sep 15 14:14:39 2014 -0400 nfs: change nfs_page_group_lock argument commit fd2f3a06d30c85a17cf035ebc60c88c2a13a8ece upstream. Flip the meaning of the second argument from 'wait' to 'nonblock' to match related functions. Update all five calls to reflect this change. Signed-off-by: Weston Andros Adamson Reviewed-by: Peng Tao Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 84f8a2dae436503819f5fe28fd2e2c6a630249bb Author: Weston Andros Adamson Date: Mon Sep 15 14:14:38 2014 -0400 nfs: clear_request_commit while holding i_lock commit 411a99adffb4f993eee29759f744de01487044ac upstream. Signed-off-by: Weston Andros Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 31171a0648d6aeddf42d74212cd925742eff9c89 Author: Weston Andros Adamson Date: Mon Sep 15 14:14:37 2014 -0400 pnfs: add pnfs_put_lseg_async commit e6cf82d1830f5e16a10d566f58db70f297ba5da8 upstream. This is useful when lsegs need to be released while holding locks. Signed-off-by: Weston Andros Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 609e951309ef5f66f4d1e20a592644efd342d110 Author: Weston Andros Adamson Date: Mon Sep 15 14:14:36 2014 -0400 nfs: check wait_on_bit_lock err in page_group_lock commit e7029206ff43f6cf7d6fcb741adb126f47200516 upstream. Return errors from wait_on_bit_lock from nfs_page_group_lock. Add a bool argument @wait to nfs_page_group_lock. If true, loop over wait_on_bit_lock until it returns cleanly. If false, return the error from wait_on_bit_lock. Signed-off-by: Weston Andros Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit de4308d1ff92b11b3b5a104884cc4dbdce49a55e Author: Weston Andros Adamson Date: Mon Sep 15 14:14:35 2014 -0400 nfs: remove pgio_header refcount, related cleanup commit 4714fb51fd03a14d8c73001438283e7f7b752f1e upstream. The refcounting on nfs_pgio_header was related to there being (possibly) more than one nfs_pgio_data. Now that nfs_pgio_data has been merged into nfs_pgio_header, there is no reason to do this ref counting. Just call the completion callback on nfs_pgio_release/nfs_pgio_error. Signed-off-by: Weston Andros Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 46af9f153348a5fd7170059b1eeb52d64149ab9b Author: Weston Andros Adamson Date: Mon Sep 15 14:14:34 2014 -0400 nfs: merge nfs_pgio_data into _header commit d45f60c67848b9f19160692581d78e5b4757a000 upstream. struct nfs_pgio_data only exists as a member of nfs_pgio_header, but is passed around everywhere, because there used to be multiple _data structs per _header. Many of these functions then use the _data to find a pointer to the _header. This patch cleans this up by merging the nfs_pgio_data structure into nfs_pgio_header and passing nfs_pgio_header around instead. Reviewed-by: Christoph Hellwig Signed-off-by: Weston Andros Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit b65c35eca4b887e5977bc49a839a8c3bcb276fe5 Author: Weston Andros Adamson Date: Mon Sep 15 14:14:33 2014 -0400 nfs: rename members of nfs_pgio_data commit 823b0c9d9800e712374cda89ac3565bd29f6701b upstream. Rename "verf" to "writeverf" and "pages" to "page_array" to prepare for merge of nfs_pgio_data and nfs_pgio_header. Reviewed-by: Christoph Hellwig Signed-off-by: Weston Andros Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 755304b3320f063ba6ccc18c69b189507f5a35fc Author: Weston Andros Adamson Date: Mon Sep 15 14:14:32 2014 -0400 nfs: move nfs_pgio_data and remove nfs_rw_header commit 1e7f3a485922211b6e4a082ebc6bf05810b0b6ea upstream. nfs_rw_header was used to allocate an nfs_pgio_header along with an nfs_pgio_data, because a _header would need at least one _data. Now there is only ever one nfs_pgio_data for each nfs_pgio_header -- move it to nfs_pgio_header and get rid of nfs_rw_header. Reviewed-by: Christoph Hellwig Signed-off-by: Weston Andros Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit f70054c4468ab3106ac4dcc1e9abd1b1f1bbd1cf Author: J. Bruce Fields Date: Wed Sep 24 16:32:34 2014 -0400 nfsd4: fix corruption of NFSv4 read data commit 15b23ef5d348ea51c5e7573e2ef4116fbc7cb099 upstream. The calculation of page_ptr here is wrong in the case the read doesn't start at an offset that is a multiple of a page. The result is that nfs4svc_encode_compoundres sets rq_next_page to a value one too small, and then the loop in svc_free_res_pages may incorrectly fail to clear a page pointer in rq_respages[]. Pages left in rq_respages[] are available for the next rpc request to use, so xdr data may be written to that page, which may hold data still waiting to be transmitted to the client or data in the page cache. The observed result was silent data corruption seen on an NFSv4 client. We tag this as "fixing" 05638dc73af2 because that commit exposed this bug, though the incorrect calculation predates it. Particular thanks to Andrea Arcangeli and David Gilbert for analysis and testing. Fixes: 05638dc73af2 "nfsd4: simplify server xdr->next_page use" Reported-by: Andrea Arcangeli Tested-by: "Dr. David Alan Gilbert" Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 929c70d0d072ad13871a50bb42f53add05c7447e Author: Trond Myklebust Date: Thu Sep 18 11:51:32 2014 -0400 NFSv4: Fix another bug in the close/open_downgrade code commit cd9288ffaea4359d5cfe2b8d264911506aed26a4 upstream. James Drew reports another bug whereby the NFS client is now sending an OPEN_DOWNGRADE in a situation where it should really have sent a CLOSE: the client is opening the file for O_RDWR, but then trying to do a downgrade to O_RDONLY, which is not allowed by the NFSv4 spec. Reported-by: James Drews Link: http://lkml.kernel.org/r/541AD7E5.8020409@engr.wisc.edu Fixes: aee7af356e15 (NFSv4: Fix problems with close in the presence...) Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit a56862ef5712c7386fb435185a17ed9a1de6e843 Author: Steve Dickson Date: Thu Sep 18 09:13:17 2014 -0400 NFSv4: nfs4_state_manager() vs. nfs_server_remove_lists() commit 080af20cc945d110f9912d01cf6b66f94a375b8d upstream. There is a race between nfs4_state_manager() and nfs_server_remove_lists() that happens during a nfsv3 mount. The v3 mount notices there is already a supper block so nfs_server_remove_lists() called which uses the nfs_client_lock spin lock to synchronize access to the client list. At the same time nfs4_state_manager() is running through the client list looking for work to do, using the same lock. When nfs4_state_manager() wins the race to the list, a v3 client pointer is found and not ignored properly which causes the panic. Moving some protocol checks before the state checking avoids the panic. Signed-off-by: Steve Dickson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 3d5cd32aec76ad53e2aefc72ee67fed7d2819019 Author: Li Zefan Date: Thu Sep 4 14:43:38 2014 +0800 cgroup: check cgroup liveliness before unbreaking kernfs commit aa32362f011c6e863132b16c1761487166a4bad2 upstream. When cgroup_kn_lock_live() is called through some kernfs operation and another thread is calling cgroup_rmdir(), we'll trigger the warning in cgroup_get(). ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1228 at kernel/cgroup.c:1034 cgroup_get+0x89/0xa0() ... Call Trace: [] dump_stack+0x41/0x52 [] warn_slowpath_common+0x7f/0xa0 [] warn_slowpath_null+0x1d/0x20 [] cgroup_get+0x89/0xa0 [] cgroup_kn_lock_live+0x28/0x70 [] __cgroup_procs_write.isra.26+0x51/0x230 [] cgroup_tasks_write+0x12/0x20 [] cgroup_file_write+0x40/0x130 [] kernfs_fop_write+0xd1/0x160 [] vfs_write+0x98/0x1e0 [] SyS_write+0x4d/0xa0 [] sysenter_do_call+0x12/0x12 ---[ end trace 6f2e0c38c2108a74 ]--- Fix this by calling css_tryget() instead of cgroup_get(). v2: - move cgroup_tryget() right below cgroup_get() definition. (Tejun) Reported-by: Toralf Förster Signed-off-by: Zefan Li Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit de8a646c2422cda2e3536f953677cf4b6b92f09e Author: J. Bruce Fields Date: Wed Aug 20 14:49:50 2014 -0400 nfsd4: fix rd_dircount enforcement commit aee3776441461c14ba6d8ed9e2149933e65abb6e upstream. Commit 3b299709091b "nfsd4: enforce rd_dircount" totally misunderstood rd_dircount; it refers to total non-attribute bytes returned, not number of directory entries returned. Bring the code into agreement with RFC 3530 section 14.2.24. Fixes: 3b299709091b "nfsd4: enforce rd_dircount" Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 0203e57c5d70d116d39d5cac8d594a0425e92d51 Author: Olav Haugan Date: Mon Aug 4 19:01:02 2014 +0100 iommu/arm-smmu: fix programming of SMMU_CBn_TCR for stage 1 commit 1fc870c7efa364862c3bc792cfbdb38afea26742 upstream. Stage-1 context banks do not have the SMMU_CBn_TCR[SL0] field since it is only applicable to stage-2 context banks. This patch ensures that we don't set the reserved TCR bits for stage-1 translations. Signed-off-by: Olav Haugan Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit bc13c021564c53278e64be4c2e5c1b8678a792ab Author: Varun Sethi Date: Thu Sep 4 17:08:45 2014 +0530 iommu/fsl: Fix warning resulting from adding PCI device twice commit 5a9137a66b521d667236e95c307b92af532fe600 upstream. iommu_group_get_for_dev determines the iommu group for the PCI device and adds the device to the group. In the PAMU driver we were again adding the device to the same group without checking if the device already had an iommu group. This resulted in the following warning. sysfs: cannot create duplicate filename '/devices/ffe200000.pcie/pci0000:00/0000:00:00.0/iommu_group' ------------[ cut here ]------------ WARNING: at fs/sysfs/dir.c:31 Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc3-00002-g7505cea-dirty #126 task: c0000001fe0a0000 ti: c0000001fe044000 task.ti: c0000001fe044000 NIP: c00000000018879c LR: c000000000188798 CTR: c00000000001ea50 REGS: c0000001fe047040 TRAP: 0700 Not tainted (3.17.0-rc3-00002-g7505cea-dirty) MSR: 0000000080029000 CR: 24ad8e22 XER: 20000000 SOFTE: 1 GPR00: c000000000188798 c0000001fe0472c0 c0000000009a52e0 0000000000000065 GPR04: 0000000000000001 0000000000000000 3a30303a00000000 0000000027000000 GPR08: 2f696f6d00000000 c0000000008d3830 c0000000009b3938 c0000000009bb3d0 GPR12: 0000000028ad8e24 c00000000fff4000 c00000000000205c 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 c0000000008a4c70 GPR24: c0000000007e9010 c0000001fe0140a8 ffffffffffffffef 0000000000000001 GPR28: c0000001fe22ebb8 c0000000007e9010 c00000000090bf10 c0000001fe220000 NIP [c00000000018879c] .sysfs_warn_dup+0x74/0xa4 LR [c000000000188798] .sysfs_warn_dup+0x70/0xa4 Call Trace: [c0000001fe0472c0] [c000000000188798] .sysfs_warn_dup+0x70/0xa4 (unreliable) [c0000001fe047350] [c000000000188d34] .sysfs_do_create_link_sd.clone.2+0x168/0x174 [c0000001fe047400] [c0000000004b3cf8] .iommu_group_add_device+0x78/0x244 [c0000001fe0474b0] [c0000000004b6964] .fsl_pamu_add_device+0x88/0x1a8 [c0000001fe047570] [c0000000004b3960] .iommu_bus_notifier+0xdc/0x15c [c0000001fe047600] [c000000000059848] .notifier_call_chain+0x8c/0xe8 [c0000001fe0476a0] [c000000000059d04] .__blocking_notifier_call_chain+0x58/0x84 [c0000001fe047750] [c00000000036619c] .device_add+0x464/0x5c8 [c0000001fe047820] [c000000000300ebc] .pci_device_add+0x14c/0x17c [c0000001fe0478c0] [c000000000300fbc] .pci_scan_single_device+0xd0/0xf4 [c0000001fe047970] [c00000000030104c] .pci_scan_slot+0x6c/0x18c [c0000001fe047a10] [c00000000030226c] .pci_scan_child_bus+0x40/0x114 [c0000001fe047ac0] [c000000000021974] .pcibios_scan_phb+0x240/0x2c8 [c0000001fe047b70] [c00000000085a970] .pcibios_init+0x64/0xc8 [c0000001fe047c00] [c000000000001884] .do_one_initcall+0xbc/0x224 [c0000001fe047d00] [c000000000852d50] .kernel_init_freeable+0x14c/0x21c [c0000001fe047db0] [c000000000002078] .kernel_init+0x1c/0xfa4 [c0000001fe047e30] [c000000000000884] .ret_from_kernel_thread+0x58/0xd4 Instruction dump: 7c7f1b79 4182001c 7fe4fb78 7f83e378 38a01000 4bffc905 60000000 7c641b78 e87e8008 7fa5eb78 48482ff5 60000000 <0fe00000> 7fe3fb78 4bf7bd39 60000000 Signed-off-by: Varun Sethi Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 45b03a62e3d86c405b9dd21068fe77a9a144971f Author: Joerg Roedel Date: Thu Aug 21 23:06:48 2014 +0200 iommu/vt-d: Check return value of acpi_bus_get_device() commit c0df975f9045d6b2b13d88746e628ac308ff49ea upstream. Checking adev == NULL is not sufficient as acpi_bus_get_device() might not touch the value of this parameter in an error case, so check the return value directly. Fixes: ed40356b5fcf1ce28e026ab39c5b2b6939068b50 Cc: David Woodhouse Signed-off-by: Joerg Roedel Reviewed-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit 7e6db41703b15e883cb4cd7eebfd5175e9adecc3 Author: Bjørn Mork Date: Tue Sep 9 10:45:18 2014 +0200 Revert "ACPI / battery: fix wrong value of capacity_now reported when fully charged" commit 508b3c677601797f2d51df3df5caa436dd235cb9 upstream. This reverts commit 232de5143790 ("ACPI / battery: fix wrong value of capacity_now reported when fully charged") There is nothing wrong or unexpected about 'capacity_now' increasing above the last 'full_charge_capacity' value. Different charging cycles will cause 'full_charge_capacity' to vary, both up and down. Good battery firmwares will update 'full_charge_capacity' when the current charging cycle is complete, increasing it if necessary. It might even go above 'design_capacity' on a fresh and healthy battery. Capping 'capacity_now' to 'full_charge_capacity' is plain wrong, and printing a warning if this doesn't happen to match the 'design_capacity' is both annoying and terribly wrong. This results in bogus warnings on perfectly working systems/firmwares: [Firmware Bug]: battery: reported current charge level (39800) is higher than reported maximum charge level (39800). and wrong values being reported for 'capacity_now' and 'full_charge_capacity' after the warning has been triggered. Fixes: 232de5143790 ("ACPI / battery: fix wrong value of capacity_now reported when fully charged") Signed-off-by: Bjørn Mork Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ffaf87f6ee1cc7e0b0c6fa4f4f1132b53bd3589f Author: Fu Zhonghui Date: Tue Sep 9 16:30:06 2014 +0200 ACPI / LPSS: complete PM entries for LPSS power domain commit f4168b617ac09986c4333accaff5d8ba5a9db7bf upstream. PM entries of LPSS power domain were not implemented correctly in commit c78b0830667a "ACPI / LPSS: custom power domain for LPSS". This patch fixes and completes these PM entries. Fixes: c78b0830667a (ACPI / LPSS: custom power domain for LPSS) Signed-off-by: Li Aubrey Signed-off-by: Mika Westerberg Signed-off-by: Fu Zhonghui Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit e4abe71907e18e967d24d729679fdb814ee6043a Author: Lee, Chun-Yi Date: Thu Sep 4 15:13:39 2014 +0800 ACPI / RTC: Fix CMOS RTC opregion handler accesses to wrong addresses commit 9389f46e9782ea5e56fbd7b2e59ba7c08f3ba86b upstream. The value64 parameter is an u64 point that used to transfer the value for write to CMOS, or used to return the value that's read from CMOS. The value64 is an u64 point, so don't need get address again. It causes acpi_cmos_rtc_space_handler always return 0 to reader and didn't write expected value to CMOS. Signed-off-by: Lee, Chun-Yi Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 3d275c4bc696484bf5972284cfdc6159d2237ca3 Author: Robert Baldyga Date: Tue Sep 9 10:44:13 2014 +0200 usb: dwc2/gadget: avoid disabling ep0 commit 604eac3c0c69e98f2fd0133305f9e777418f1d3b upstream. Endpoint 0 should not be disabled, so we start loop counter from number 1. Signed-off-by: Robert Baldyga Signed-off-by: Greg Kroah-Hartman commit 2ba4b92e8773d8a584ebff4bca870f417bedcdd3 Author: Marek Szyprowski Date: Tue Sep 9 10:44:12 2014 +0200 usb: dwc2/gadget: delay enabling irq once hardware is configured properly commit eb3c56c5ccdd252940cb0ec0541fcdc94894bd8d upstream. This patch fixes kernel panic/interrupt storm/etc issues if bootloader left s3c-hsotg module in enabled state. Now interrupt handler is enabled only after proper configuration of hardware registers. Signed-off-by: Marek Szyprowski Signed-off-by: Robert Baldyga Signed-off-by: Greg Kroah-Hartman commit 5294e5fe70646dc7d5b82f5f631f564bb6fbb82f Author: Marek Szyprowski Date: Tue Sep 9 10:44:11 2014 +0200 usb: dwc2/gadget: do not call disconnect method in pullup commit b510df5a36c066da3a188f4ade3404118b63c6de upstream. This leads to potential spinlock recursion in composite framework, other udc drivers also don't call it directly from pullup method. Signed-off-by: Marek Szyprowski Signed-off-by: Robert Baldyga Signed-off-by: Greg Kroah-Hartman commit a5e10292faafb9a6f470d2be42a7479cef2402a2 Author: Marek Szyprowski Date: Tue Sep 9 10:44:10 2014 +0200 usb: dwc2/gadget: break infinite loop in endpoint disable code commit e0cbe595db72b037260bbda77106f6811a1ebb1d upstream. This patch fixes possible freeze caused by infinite loop in interrupt context. Signed-off-by: Marek Szyprowski Signed-off-by: Robert Baldyga Signed-off-by: Greg Kroah-Hartman commit 93ce959d5de3c9b1ca40b072dbd67cce07d34c5b Author: Kamil Debski Date: Tue Sep 9 10:44:09 2014 +0200 usb: dwc2/gadget: fix phy initialization sequence commit ca2c5ba80f823a38c4aae506e2f03c1afb076b0a upstream. In the Generic PHY Framework a NULL phy is considered to be a valid phy thus the "if (hsotg->phy)" check does not give us the information whether the Generic PHY Framework is used. In addition to the above this patch also removes phy_init from probe and phy_exit from remove. This is not necessary when init/exit is done in the s3c_hsotg_phy_enable/disable functions. Signed-off-by: Kamil Debski Signed-off-by: Marek Szyprowski Signed-off-by: Robert Baldyga Signed-off-by: Greg Kroah-Hartman commit 2290f23673bd5d0863acfdb52665c5f29681ec0b Author: Kamil Debski Date: Tue Sep 9 10:44:08 2014 +0200 usb: dwc2/gadget: fix phy disable sequence commit 0655314be0d9c54ad5f63500219485c6a9d9e5e2 upstream. When the driver is removed s3c_hsotg_phy_disable is called three times instead of once. This results in decreasing of the phy reference counter below zero and thus consecutive inserts of the module fails. This patch removes calls to s3c_hsotg_phy_disable from s3c_hsotg_remove and s3c_hsotg_udc_stop. s3c_hsotg_udc_stop is called from udc-core.c only after usb_gadget_disconnect, which in turn calls s3c_hsotg_pullup, which already calls s3c_hsotg_phy_disable. s3c_hsotg_remove must be called only after udc_stop, so there is no point in disabling phy once again there. Signed-off-by: Kamil Debski Signed-off-by: Marek Szyprowski Signed-off-by: Robert Baldyga Signed-off-by: Greg Kroah-Hartman commit c2b8d9051994463343f8e2ec374f4d5161957436 Author: Felipe Balbi Date: Wed Sep 3 16:42:57 2014 -0500 usb: dwc3: omap: fix ordering for runtime pm calls commit 81a60b7f5c143ab3cdcd9943c9b4b7c63c32fc31 upstream. we don't to gate clocks until our children are done with their remove path. Fixes: af310e9 (usb: dwc3: omap: use runtime API's to enable clocks) Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit cb97274f1c59d9c1b27e5ac007a5156b9ded0600 Author: Felipe Balbi Date: Wed Sep 3 16:13:37 2014 -0500 usb: dwc3: core: fix ordering for PHY suspend commit dc99f16f076559235c92d3eb66d03d1310faea08 upstream. We can't suspend the PHYs before dwc3_core_exit_mode() has been called, that's because the host and/or device sides might still need to communicate with the far end link partner. Fixes: 8ba007a (usb: dwc3: core: enable the USB2 and USB3 phy in probe) Suggested-by: Alan Stern Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit db60b9bce86837ff59d4a4acc5b2b1f851323588 Author: Felipe Balbi Date: Tue Sep 2 14:57:20 2014 -0500 usb: dwc3: core: fix order of PM runtime calls commit fed33afce0eda44a46ae24d93aec1b5198c0bac4 upstream. Currently, we disable pm_runtime before all register accesses are done, this is dangerous and might lead to abort exceptions due to the driver trying to access a register which is clocked by a clock which was long gated. Fix that by moving pm_runtime_put_sync() and pm_runtime_disable() as the last thing we do before returning from our ->remove() method. Fixes: 72246da (usb: Introduce DesignWare USB3 DRD Driver) Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 6bd8ad714f653f11d4483df33a14bab4a92d46fc Author: Alan Stern Date: Wed Sep 17 11:23:54 2014 -0400 USB: EHCI: unlink QHs even after the controller has stopped commit 7312b5ddd47fee2356baa78c5516ef8e04eed452 upstream. Old code in ehci-hcd tries to expedite disabling endpoints after the controller has stopped, by destroying the endpoint's associated QH without first unlinking the QH. This was necessary back when the driver wasn't so careful about keeping track of the controller's state. But now we are careful about it, and the driver knows that when the controller isn't running, no unlinking delay is needed. Furthermore, skipping the unlink step will trigger a BUG() in qh_destroy() when the preceding QH is released, because the link pointer will be non-NULL. Removing the lines that skip the unlinking step and go directly to QH_STATE_IDLE fixes the problem. Signed-off-by: Alan Stern Reported-by: Joe Lawrence Tested-by: Joe Lawrence Signed-off-by: Greg Kroah-Hartman commit b436a4da8d8b3cec6b16ffa51a49139726d182c6 Author: Mark Date: Wed Sep 17 19:15:43 2014 +0100 USB: storage: Add quirks for Entrega/Xircom USB to SCSI converters commit c80b4495c61636edc58fe1ce300f09f24db28e10 upstream. This patch adds quirks for Entrega Technologies (later Xircom PortGear) USB- SCSI converters. They use Shuttle Technology EUSB-01/EUSB-S1 chips. The US_FL_SCM_MULT_TARG quirk is needed to allow multiple devices on the SCSI chain to be accessed. Without it only the (single) device with SCSI ID 0 can be used. The standalone converter sold by Entrega had model number U1-SC25. Xircom acquired Entrega and re-branded the product line PortGear. The PortGear USB to SCSI Converter (model PGSCSI) is internally identical to the Entrega product, but later models may use a different USB ID. The Entrega-branded units have USB ID 1645:0007, as does my Xircom PGSCSI, but the Windows and Macintosh drivers also support 085A:0028. Entrega also sold the "Mac USB Dock", which provides two USB ports, a Mac (8-pin mini-DIN) serial port and a SCSI port. It appears to the computer as a four-port hub, USB-serial, and USB-SCSI converters. The USB-SCSI part may have initially used the same ID as the standalone U1-SC25 (1645:0007), but later production used 085A:0026. My Xircom PortGear PGSCSI has bcdDevice=0x0100. Units with bcdDevice=0x0133 probably also exist. This patch adds quirks for 1645:0007, 085A:0026 and 085A:0028. The Windows driver INF file also mentions 085A:0032 "PortStation SCSI Module", but I couldn't find any mention of that actually existing in the wild; perhaps it was cancelled before release? Signed-off-by: Mark Knibbs Signed-off-by: Greg Kroah-Hartman commit 563b5e8a1ca57880713dd008a177d1711d276d3d Author: Mark Date: Tue Sep 16 16:51:41 2014 +0100 USB: storage: Add quirk for Ariston Technologies iConnect USB to SCSI adapter commit b6a3ed677991558ce09046397a7c4d70530d15b3 upstream. Hi, The Ariston Technologies iConnect 025 and iConnect 050 (also known as e.g. iSCSI-50) are SCSI-USB converters which use Shuttle Technology/SCM Microsystems chips. Only the connectors differ; both have the same USB ID. The US_FL_SCM_MULT_TARG quirk is required to use SCSI devices with ID other than 0. I don't have one of these, but based on the other entries for Shuttle/ SCM-based converters this patch is very likely correct. I used 0x0000 and 0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which bcdDevice value the products use. Signed-off-by: Mark Knibbs Signed-off-by: Greg Kroah-Hartman commit e0fa2192469d0d375896dbdcfc3eefc758e249ef Author: Mark Date: Tue Sep 16 16:22:50 2014 +0100 USB: storage: Add quirk for Adaptec USBConnect 2000 USB-to-SCSI Adapter commit 67d365a57a51fb9dece6a5ceb504aa381cae1e5b upstream. The Adaptec USBConnect 2000 is another SCSI-USB converter which uses Shuttle Technology/SCM Microsystems chips. The US_FL_SCM_MULT_TARG quirk is required to use SCSI devices with ID other than 0. I don't have a USBConnect 2000, but based on the other entries for Shuttle/ SCM-based converters this patch is very likely correct. I used 0x0000 and 0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which bcdDevice value the product uses. Signed-off-by: Mark Knibbs Signed-off-by: Greg Kroah-Hartman commit 8901d579eac8166d33133cd83bcc8c2c0b107503 Author: Mark Date: Thu Sep 11 13:15:45 2014 +0100 storage: Add single-LUN quirk for Jaz USB Adapter commit c66f1c62e85927357e7b3f4c701614dcb5c498a2 upstream. The Iomega Jaz USB Adapter is a SCSI-USB converter cable. The hardware seems to be identical to e.g. the Microtech XpressSCSI, using a Shuttle/ SCM chip set. However its firmware restricts it to only work with Jaz drives. On connecting the cable a message like this appears four times in the log: reset full speed USB device number 4 using uhci_hcd That's non-fatal but the US_FL_SINGLE_LUN quirk fixes it. Signed-off-by: Mark Knibbs Signed-off-by: Greg Kroah-Hartman commit f6c523b67b8d38d5625aed6036f7eab284c36147 Author: Alan Stern Date: Tue Sep 2 15:42:18 2014 -0400 USB: document the 'u' flag for usb-storage quirks parameter commit b6089f19fe0cec625b5963a851a07c3e412c27c8 upstream. Commit d24d481b7d36 (usb-storage: Modify and export adjust_quirks so that it can be used by uas) added the 'u' flag to the quirks module parameter for usb-storage, but neglected to update the documentation. This patch adds the documentation. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 3b16693f0d231d86acdb34ddf29103a282b8374e Author: Joe Lawrence Date: Wed Sep 10 15:07:50 2014 -0400 usb: hub: take hub->hdev reference when processing from eventlist commit c605f3cdff53a743f6d875b76956b239deca1272 upstream. During surprise device hotplug removal tests, it was observed that hub_events may try to call usb_lock_device on a device that has already been freed. Protect the usb_device by taking out a reference (under the hub_event_lock) when hub_events pulls it off the list, returning the reference after hub_events is finished using it. Signed-off-by: Joe Lawrence Suggested-by: David Bulkow for using kref Suggested-by: Alan Stern for placement Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit c14555bfc11e9455272e9c2459197559ea2ad957 Author: Mathias Nyman Date: Thu Sep 11 13:55:50 2014 +0300 xhci: fix oops when xhci resumes from hibernate with hw lpm capable devices commit 96044694b8511bc2b04df0776b4ba295cfe005c0 upstream. Resuming from hibernate (S4) will restart and re-initialize xHC. The device contexts are freed and will be re-allocated later during device reset. Usb core will disable link pm in device resume before device reset, which will try to change the max exit latency, accessing the device contexts before they are re-allocated. There is no need to zero (disable) the max exit latency when disabling hw lpm for a freshly re-initialized xHC. So check that device context exists before doing anything. The max exit latency will be set again after device reset when usb core enables the link pm. Reported-by: Imre Deak Tested-by: Imre Deak Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 714f9e749dd87c07dcf261fdbacb38c578cda0c2 Author: Al Cooper Date: Thu Sep 11 13:55:49 2014 +0300 usb: xhci: Fix OOPS in xhci error handling code commit 0eda06c7c17ae48d7db69beef57f6e2b20bc3c72 upstream. The xhci driver will OOPS on resume from S2/S3 if dma_alloc_coherent() is out of memory. This is a result of two things: 1. xhci_mem_cleanup() in xhci-mem.c free's xhci->lpm_command if it's not NULL, but doesn't set it to NULL after the free. 2. xhci_mem_cleanup() is called twice on resume, once for normal restart and once from xhci_mem_init() if dma_alloc_coherent() fails, resulting in a free of xhci->lpm_command that has already been freed. The fix is to set xhci->lpm_command to NULL after freeing it. Signed-off-by: Al Cooper Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit a8a48a03cf59cacfea21acba190ddc4de77be60b Author: Mathias Nyman Date: Thu Sep 11 13:55:48 2014 +0300 xhci: Fix null pointer dereference if xhci initialization fails commit c207e7c50f31113c24a9f536fcab1e8a256985d7 upstream. If xhci initialization fails before the roothub bandwidth domains (xhci->rh_bw[i]) are allocated it will oops when trying to access rh_bw members in xhci_mem_cleanup(). Reported-by: Manuel Reimer Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit ec712983f29d1e1990c85e175876324a35af0c2e Author: Felipe Balbi Date: Wed Aug 27 16:38:04 2014 -0500 usb: host: xhci: fix compliance mode workaround commit 96908589a8b2584b1185f834d365f5cc360e8226 upstream. Commit 71c731a (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware) implemented a workaround for a known issue with Texas Instruments' USB 3.0 redriver IC but it left a condition where any xHCI host would be taken out of reset if port was placed in compliance mode and there was no device connected to the port. That condition would trigger a fake connection to a non-existent device so that usbcore would trigger a warm reset of the port, thus taking the link out of reset. This has the side-effect of preventing any xHCI host connected to a Linux machine from starting and running the USB 3.0 Electrical Compliance Suite because the port will mysteriously taken out of compliance mode and, thus, xHCI won't step through the necessary compliance patterns for link validation. This patch fixes the issue by just adding a missing check for XHCI_COMP_MODE_QUIRK inside xhci_hub_report_usb3_link_state() when PORT_CAS isn't set. This patch should be backported to all kernels containing commit 71c731a. Fixes: 71c731a (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware) Cc: Alexis R. Cortes Signed-off-by: Felipe Balbi Acked-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 659235150ff367afd36515e1b9bcaaf23ff1b0ba Author: Thomas Pugliese Date: Thu Aug 7 15:45:35 2014 -0500 uwb: init beacon cache entry before registering uwb device commit 675f0ab2fe5a0f7325208e60b617a5f32b86d72c upstream. Make sure the uwb_dev->bce entry is set before calling uwb_dev_add in uwbd_dev_onair so that usermode will only see the device after it is properly initialized. This fixes a kernel panic that can occur if usermode tries to access the IEs sysfs attribute of a UWB device before the driver has had a chance to set the beacon cache entry. Signed-off-by: Thomas Pugliese Signed-off-by: Greg Kroah-Hartman commit fe359c391b06ef69351955458d2d6b7d37a6ab2a Author: Johan Hovold Date: Thu Aug 28 12:46:54 2014 +0200 USB: zte_ev: fix removed PIDs commit 3096691011d01cef56b243a5e65431405c07d574 upstream. Add back some PIDs that were mistakingly remove when reverting commit 73228a0538a7 ("USB: option,zte_ev: move most ZTE CDMA devices to zte_ev"), which apparently did more than its commit message claimed in that it not only moved some PIDs from option to zte_ev but also added some new ones. Fixes: 63a901c06e3c ("Revert "USB: option,zte_ev: move most ZTE CDMA devices to zte_ev"") Reported-by: Lei Liu Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 847576c4b457b9fef6188adffdb70a64764aee50 Author: Johan Hovold Date: Mon Aug 18 18:33:11 2014 +0200 USB: ftdi_sio: add support for NOVITUS Bono E thermal printer commit ee444609dbae8afee420c3243ce4c5f442efb622 upstream. Add device id for NOVITUS Bono E thermal printer. Reported-by: Emanuel Koczwara Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 0f067be44c266ddc35000018bc3602df7fc52858 Author: Taylor Braun-Jones Date: Thu Aug 7 14:25:06 2014 -0400 USB: ftdi_sio: Add support for GE Healthcare Nemo Tracker device commit 9c491c372d677b6420e0f8c6361fe422791662cc upstream. Signed-off-by: Taylor Braun-Jones Cc: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 9ca1ee621f7e5d5b65c10ce684679ec4a6775f3e Author: Ivan T. Ivanov Date: Thu Sep 11 08:19:00 2014 +0800 usb: chipidea: msm: Initialize PHY on reset event commit 233c7daf4eecd1e992dc42591182cd4a892e687c upstream. Initialize USB PHY after every Link controller reset Cc: Tim Bird Signed-off-by: Peter Chen Signed-off-by: Ivan T. Ivanov Signed-off-by: Greg Kroah-Hartman commit 87df459f5f2ea9599c29c9d9d9276e7e0c9c0c8b Author: Ivan T. Ivanov Date: Thu Sep 11 08:18:59 2014 +0800 usb: chipidea: msm: Use USB PHY API to control PHY state commit ea290056d7c46f7781ff13801048ed957b96d1a5 upstream. PHY drivers keep track of the current state of the hardware, so don't change PHY settings under it. Cc: Tim Bird Signed-off-by: Peter Chen Signed-off-by: Ivan T. Ivanov Acked-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit c17f0b7eea3dccd4ff4d233e22a0f27bcdab088a Author: Tony Lindgren Date: Wed Aug 20 12:07:00 2014 -0700 usb: phy: twl4030-usb: Fix regressions to runtime PM on omaps commit 96be39ab34b77c6f6f5cd6ae03aac6c6449ee5c4 upstream. Commit 30a70b026b4cd ("usb: musb: fix obex in g_nokia.ko causing kernel panic") attempted to fix runtime PM handling for PHYs that are on the I2C bus. Commit 3063a12be2b0 ("usb: musb: fix PHY power on/off") then changed things around to enable of PHYs that rely on runtime PM. These changes however broke idling of the PHY and causes at least 100 mW extra power consumption on omaps, which is a lot with the idle power consumption being below 10 mW range on many devices. As calling phy_power_on/off from runtime PM calls in the USB causes complicated issues with I2C connected PHYs, let's just let the PHY do it's own runtime PM as needed. This leaves out the dependency between PHYs and USB controller drivers for runtime PM. Let's fix the regression for twl4030-usb by adding minimal runtime PM support. This allows idling the PHY on disconnect. Note that we are changing to use standard runtime PM handling for twl4030_phy_init() as that function just checks the state and does not initialize the PHY. The PHY won't get initialized until in twl4030_phy_power_on(). Fixes: 30a70b026b4cd ("usb: musb: fix obex in g_nokia.ko causing kernel panic") Fixes: 3063a12be2b0 ("usb: musb: fix PHY power on/off") Acked-by: Felipe Balbi Signed-off-by: Tony Lindgren Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Greg Kroah-Hartman commit ba9a8d9c250262241647879b669bf57c0e27c04f Author: Tony Lindgren Date: Sun Aug 24 17:44:22 2014 +0530 usb: phy: twl4030-usb: Fix lost interrupts after ID pin goes down commit 85601b8d81e24ce9ae2d31e93f35468ab7616b18 upstream. Commit 249751f22380 ("usb: phy: twl4030-usb: poll for ID disconnect") added twl4030_id_workaround_work() to deal with lost interrupts after ID pin goes down. Looks like commit f1ddc24c9e33 ("usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops") changed things around for the generic phy framework, and delayed work no longer got called except initially during boot. The PHY connect and disconnect interrupts for twl4030-usb are not working after disconnecting a USB-A cable from the board, and the deeper idle states for omap are blocked as the USB controller stays busy. The issue can be solved by calling delayed work from twl4030_usb_irq() when ID pin is down and the PHY is not asleep like we already do in twl4030_id_workaround_work(). But as both twl4030_usb_irq() and twl4030_id_workaround_work() already do pretty much the same thing, let's call twl4030_usb_irq() from twl4030_id_workaround_work() instead of adding some more duplicate code. We also must call sysfs_notify() only when we have an interrupt and not from the delayed work as notified by Grazvydas Ignotas . Fixes: f1ddc24c9e33 ("usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops") Acked-by: Felipe Balbi Signed-off-by: Tony Lindgren Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Greg Kroah-Hartman commit f92950479c1217d79beb4a686b8f03e10079a742 Author: Thierry Reding Date: Mon Jul 21 13:37:37 2014 +0200 usb: phy: tegra: Avoid use of sizeof(void) commit 9ce9ec95fb9b82e09b55a52f1bb8a362bf8f74d8 upstream. The PHY configuration is stored in an opaque "config" field, but when allocating the structure, its proper size needs to be known. In the case of UTMI, the proper structure is tegra_utmip_config of which a local variable already exists, so we can use that to obtain the size from. Fixes the following warning from the sparse checker: drivers/usb/phy/phy-tegra-usb.c:882:17: warning: expression using sizeof(void) Fixes: 81d5dfe6d8b3 (usb: phy: tegra: Read UTMIP parameters from device tree) Signed-off-by: Thierry Reding Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 2be927489f32b9afeecf55aeecb716dadcb03547 Author: Bjørn Mork Date: Thu Aug 28 15:08:16 2014 +0200 USB: sierra: add 1199:68AA device ID commit 5b3da69285c143b7ea76b3b9f73099ff1093ab73 upstream. This VID:PID is used for some Direct IP devices behaving identical to the already supported 0F3D:68AA devices. Reported-by: Lars Melin Signed-off-by: Bjørn Mork Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 81f1e78e1dcee66908556058b24458173109b79e Author: Bjørn Mork Date: Thu Aug 28 14:11:23 2014 +0200 USB: sierra: avoid CDC class functions on "68A3" devices commit 049255f51644c1105775af228396d187402a5934 upstream. Sierra Wireless Direct IP devices using the 68A3 product ID can be configured for modes including a CDC ECM class function. The known example uses interface numbers 12 and 13 for the ECM control and data interfaces respectively, consistent with CDC MBIM function interface numbering on other Sierra devices. It seems cleaner to restrict this driver to the ff/ff/ff vendor specific interfaces rather than increasing the already long interface number blacklist. This should be more future proof if Sierra adds more class functions using interface numbers not yet in the blacklist. Signed-off-by: Bjørn Mork Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 534e9138b054476798f02addb2ee21f4c3bce07b Author: Johan Hovold Date: Thu Aug 7 16:00:15 2014 +0200 USB: zte_ev: remove duplicate Qualcom PID commit 754eb21c0bbbbc4b8830a9a864b286323b84225f upstream. Remove dublicate Qualcom PID 0x3197 which is already handled by the moto-modem driver since commit 6986a978eec7 ("USB: add new moto_modem driver for some Morotola phones"). Fixes: 799ee9243d89 ("USB: serial: add zte_ev.c driver") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 5ed69611ab3161ad0fd18263a80a9ff41a8d7603 Author: Johan Hovold Date: Thu Aug 7 16:00:14 2014 +0200 USB: zte_ev: remove duplicate Gobi PID commit 95be5739588c56a9327e477aa0ba3c81c5cf8631 upstream. Remove dublicate Gobi PID 0x9008 which is already handled by the qcserial driver since commit f05932c0caf4 ("USB: qcserial: Add extra device IDs"). Fixes: 799ee9243d89 ("USB: serial: add zte_ev.c driver") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit fd4310fa6e8b06b8def6ea028e8b86af7eac2fe6 Author: Johan Hovold Date: Thu Aug 7 16:00:13 2014 +0200 Revert "USB: option,zte_ev: move most ZTE CDMA devices to zte_ev" commit 63a901c06e3c2c45bd601916fe04e870e9ccae1e upstream. This reverts commit 73228a0538a7 ("USB: option,zte_ev: move most ZTE CDMA devices to zte_ev"). Move the IDs of the devices that were previously driven by the option driver back to that driver. As several users have reported, the zte_ev driver is causing random disconnects as well as reconnect failures. A closer analysis of the zte_ev setup code reveals that it consists of standard CDC requests (SET/GET_LINE_CODING and SET_CONTROL_LINE_STATE) but unfortunately fails to get some of those right. In particular, as reported by Liu Lei, it fails to lower DTR/RTS on close. It also appears that the control requests lack the interface argument. Note that the zte_ev driver is based on code (once) distributed by ZTE that still appears to originally have been reverse-engineered and bolted onto the generic driver. Since line control is already handled properly by the option driver, and the SET/GET_LINE_CODING requests appears to be redundant (amounts to a SET 9600 8N1), this is a first step in ultimately removing the redundant zte_ev driver. Note that AC2726 had already been moved back to option, and that some IDs were in the device table of both drivers prior to the commit being reverted. Reported-by: Lei Liu Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 968aa5f97b1f33a76e2b88ac8ae215deb6db5615 Author: Brennan Ashton Date: Wed Aug 6 08:46:44 2014 -0700 USB: option: add VIA Telecom CDS7 chipset device id commit d77302739d900bbca5e901a3b7ac48c907ee6c93 upstream. This VIA Telecom baseband processor is used is used by by u-blox in both the FW2770 and FW2760 products and may be used in others as well. This patch has been tested on both of these modem versions. Signed-off-by: Brennan Ashton Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 6c60c968283a085bf7c511df8b573e98546be7ec Author: Johan Hovold Date: Tue Jul 29 14:14:55 2014 +0200 USB: option: reduce interrupt-urb logging verbosity commit f0e4cba2534cd88476dff920727c81350130f3c5 upstream. Do not log normal interrupt-urb shutdowns as errors. The option driver has always been logging any nonzero interrupt-urb status as an error, including when the urb is killed during normal operation. Commit 9096f1fbba91 ("USB: usb_wwan: fix potential NULL-deref at resume") moved the interrupt urb submission from port probe and release to open and close, thus potentially increasing the number of these false-positive error messages dramatically. Reported-by: Ed Butler Tested-by: Ed Butler Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 8c63b6a92a5692511e32d8711bc6e5d5e52d2def Author: Johan Hovold Date: Wed Aug 27 11:55:19 2014 +0200 USB: serial: fix potential heap buffer overflow commit 5654699fb38512bdbfc0f892ce54fce75bdc2bab upstream. Make sure to verify the number of ports requested by subdriver to avoid writing beyond the end of fixed-size array in interface data. The current usb-serial implementation is limited to eight ports per interface but failed to verify that the number of ports requested by a subdriver (which could have been determined from device descriptors) did not exceed this limit. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit dad0051635c74f9bf96902cdf67c215fafab9c6e Author: Stephen Hemminger Date: Mon Aug 25 21:07:47 2014 -0700 USB: sisusb: add device id for Magic Control USB video commit 5b6b80aeb21091ed3030b9b6aae597d81326f1aa upstream. I have a j5 create (JUA210) USB 2 video device and adding it device id to SIS USB video gets it to work. Signed-off-by: Stephen Hemminger Signed-off-by: Greg Kroah-Hartman commit eb587be4394fd4a770206d08689f42ca5453692d Author: Johan Hovold Date: Wed Aug 27 11:55:18 2014 +0200 USB: serial: fix potential stack buffer overflow commit d979e9f9ecab04c1ecca741370e30a8a498893f5 upstream. Make sure to verify the maximum number of endpoints per type to avoid writing beyond the end of a stack-allocated array. The current usb-serial implementation is limited to eight ports per interface but failed to verify that the number of endpoints of a certain type reported by a device did not exceed this limit. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 133f1fc755c60a3e4b946e63accb11fe0577be18 Author: Greg KH Date: Fri Aug 15 15:22:21 2014 +0800 USB: serial: pl2303: add device id for ztek device commit 91fcb1ce420e0a5f8d92d556d7008a78bc6ce1eb upstream. This adds a new device id to the pl2303 driver for the ZTEK device. Reported-by: Mike Chu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold commit d5c150ba9c3bbb080a27413dd1a948bf623ae642 Author: Andrzej Pietrasiewicz Date: Tue Jul 1 15:47:47 2014 +0200 usb: gadget: f_rndis: fix interface id for OS descriptors commit 4546527350c3c508554dff53e9086e9d3de0b97b upstream. f->os_desc_table[0].if_id is zero by default. If the actual id happens to be different then no Feature Descriptors will be returned to the host for this interface, so assign if_id as soon as it is known. Acked-by: Michal Nazarewicz Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit c20736252a485809c5b6490c5a0c88569e299a9e Author: Alexey Khoroshilov Date: Tue Sep 2 11:40:17 2014 +0400 ufs: fix deadlocks introduced by sb mutex merge commit 9ef7db7f38d0472dd9c444e42d5c5175ccbe5451 upstream. Commit 0244756edc4b ("ufs: sb mutex merge + mutex_destroy") introduces deadlocks in ufs_new_inode() and ufs_free_inode(). Most callers of that functions acqure the mutex by themselves and ufs_{new,free}_inode() do that via lock_ufs(), i.e we have an unavoidable double lock. The patch proposes to resolve the issue by making sure that ufs_{new,free}_inode() are not called with the mutex held. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit e05f7a049389792dd6decdc3861413a3bcd8f051 Author: Jeff Layton Date: Fri Aug 22 09:58:22 2014 -0400 locks: pass correct "before" pointer to locks_unlink_lock in generic_add_lease commit e0b760ff71be168d4e623f7c3612e98902ab93e9 upstream. The argument to locks_unlink_lock can't be just any pointer to a pointer. It must be a pointer to the fl_next field in the previous lock in the list. Signed-off-by: Jeff Layton Reviewed-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 7e5866d82dc2d896f6af0bc1af33fa007172ae83 Author: Max Filippov Date: Thu Jul 31 22:40:57 2014 +0400 xtensa: fix a6 and a7 handling in fast_syscall_xtensa commit d1b6ba82a50cecf94be540a3a153aa89d97511a0 upstream. Remove restoring a6 on some return paths and instead modify and restore it in a single place, using symbolic name. Correctly restore a7 from PT_AREG7 in case of illegal a6 value. Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit 6bbfb4cad0bd9b6788ff9751fc774a7b501b03c0 Author: Max Filippov Date: Mon Jul 21 22:01:51 2014 +0400 xtensa: fix TLBTEMP_BASE_2 region handling in fast_second_level_miss commit 7128039fe2dd3d59da9e4ffa036f3aaa3ba87b9f upstream. Current definition of TLBTEMP_BASE_2 is always 32K above the TLBTEMP_BASE_1, whereas fast_second_level_miss handler for the TLBTEMP region analyzes virtual address bit (PAGE_SHIFT + DCACHE_ALIAS_ORDER) to determine TLBTEMP region where the fault happened. The size of the TLBTEMP region is also checked incorrectly: not 64K, but twice data cache way size (whicht may as well be less than the instruction cache way size). Fix TLBTEMP_BASE_2 to be TLBTEMP_BASE_1 + data cache way size. Provide TLBTEMP_SIZE that is a greater of doubled data cache way size or the instruction cache way size, and use it to determine if the second level TLB miss occured in the TLBTEMP region. Practical occurence of page faults in the TLBTEMP area is extremely rare, this code can be tested by deletion of all w[di]tlb instructions in the tlbtemp_mapping region. Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit 2ca6012df2209959481cdafae17bd78b4f8a2a00 Author: Max Filippov Date: Sun Jul 27 07:23:41 2014 +0400 xtensa: fix access to THREAD_RA/THREAD_SP/THREAD_DS commit 52247123749cc3cbc30168b33ad8c69515c96d23 upstream. With SMP and a lot of debug options enabled task_struct::thread gets out of reach of s32i/l32i instructions with base pointing at task_struct, breaking build with the following messages: arch/xtensa/kernel/entry.S: Assembler messages: arch/xtensa/kernel/entry.S:1002: Error: operand 3 of 'l32i.n' has invalid value '1048' arch/xtensa/kernel/entry.S:1831: Error: operand 3 of 's32i.n' has invalid value '1040' arch/xtensa/kernel/entry.S:1832: Error: operand 3 of 's32i.n' has invalid value '1044' Change base to point to task_struct::thread in such cases. Don't use a10 in _switch_to to save/restore prev pointer as a2 is not clobbered. Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit e6eb4fdf8e624fe7f7d037fee6c3363f18cb184b Author: Alan Douglas Date: Wed Jul 23 14:06:40 2014 +0400 xtensa: fix address checks in dma_{alloc,free}_coherent commit 1ca49463c44c970b1ab1d71b0f268bfdf8427a7e upstream. Virtual address is translated to the XCHAL_KSEG_CACHED region in the dma_free_coherent, but is checked to be in the 0...XCHAL_KSEG_SIZE range. Change check for end of the range from 'addr >= X' to 'addr > X - 1' to handle the case of X == 0. Replace 'if (C) BUG();' construct with 'BUG_ON(C);'. Signed-off-by: Alan Douglas Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit 2f0871ed208074261e3bd2e2aef53fa54d3c30ea Author: Max Filippov Date: Sun Jul 20 03:38:53 2014 +0400 xtensa: replace IOCTL code definitions with constants commit f61bf8e7d19e0a3456a7a9ed97c399e4353698dc upstream. This fixes userspace code that builds on other architectures but fails on xtensa due to references to structures that other architectures don't refer to. E.g. this fixes the following issue with python-2.7.8: python-2.7.8/Modules/termios.c:861:25: error: invalid application of 'sizeof' to incomplete type 'struct serial_multiport_struct' {"TIOCSERGETMULTI", TIOCSERGETMULTI}, python-2.7.8/Modules/termios.c:870:25: error: invalid application of 'sizeof' to incomplete type 'struct serial_multiport_struct' {"TIOCSERSETMULTI", TIOCSERSETMULTI}, python-2.7.8/Modules/termios.c:900:24: error: invalid application of 'sizeof' to incomplete type 'struct tty_struct' {"TIOCTTYGSTRUCT", TIOCTTYGSTRUCT}, Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit 127e837f479a2fa68f1cca05be739afb3cd3f8f0 Author: Alex Deucher Date: Tue Sep 23 10:20:13 2014 -0400 drm/radeon/cik: use a separate counter for CP init timeout commit 370ce45b5986118fa496dddbcd7039e1aa1a418f upstream. Otherwise we may fail to init the second compute ring. Noticed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 664273c45bd0f9dff8d65b8920df7ae1f1e37fba Author: Alex Deucher Date: Thu Sep 18 11:16:31 2014 -0400 drm/radeon/dpm: fix resume on mullins commit 39da038479a81a35a7f8af3ab2c90effd5c8eff1 upstream. Need to properly disable nb dpm on dpm disable. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b2e8e9cb9979a04703963fd96999e5d6b7380d2d Author: Alex Deucher Date: Thu Sep 18 10:23:04 2014 -0400 drm/radeon: don't reset dma on r6xx-evergreen init commit c1789a2e66a4209fe5035eca11fdd729b2ffdd82 upstream. Otherwise we may lose the DMA golden settings which can lead to hangs, etc. Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 7d102d16c64a0cd8dd98f9d81502292f04643360 Author: Alex Deucher Date: Thu Sep 18 10:18:43 2014 -0400 drm/radeon: don't reset sdma on CIK init commit 799028d5d85384cce140323be633c8d5f079193f upstream. Otherwise we may lose the DMA golden settings which can lead to hangs, etc. Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 63dcd5a8b861b7b447dd49690f1b7a016f203739 Author: Alex Deucher Date: Wed Sep 17 17:41:04 2014 -0400 drm/radeon: don't reset dma on NI/SI init commit 31a25e2caf9367365fcb0e57fd8fa5a42e9b73e4 upstream. Otherwise we may lose the DMA golden settings which can lead to hangs, etc. bug: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=83500 Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit d6ba8818372137f7cabcbf36719eff2138c4addb Author: Alex Deucher Date: Mon Sep 8 13:55:51 2014 -0400 drm/radeon: add connector quirk for fujitsu board commit 1952f24d0fa6292d65f886887af87ba8ac79b3ba upstream. Vbios connector table lists non-existent VGA port. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83184 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ee75424b5bb21945a073e084933b6a6015962ad9 Author: Alex Deucher Date: Mon Sep 8 02:33:32 2014 -0400 drm/radeon/dpm: set the thermal type properly for special configs commit ff4377924f7e587c61bcbc704eafecf6c7bd2e00 upstream. On systems with special thermal configurations make sure we make note of the thermal setup. This is required for proper firmware configuration on these systems. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 007d978abcdbb25bd138aa0f4c075274628a5e5d Author: Christian König Date: Sun Sep 7 12:06:52 2014 +0200 drm/radeon: fix semaphore value init commit f229407da79315c18a2f25f485e1a1b9fdda1e92 upstream. Semaphore values have 64 bits, not 32. This fixes a very subtle bug that disables synchronization when the upper 32bits wasn't zero. Signed-off-by: Christian König Reviewed-By: Grigori Goronzy Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 48b3c2fe612af8c253cee605a4411e3096c555ae Author: Alex Deucher Date: Mon Aug 25 14:52:15 2014 -0400 drm/radeon: handle broken disabled rb mask gracefully (6xx/7xx) (v2) commit 0a5f6e9d60e71e4b6dbeabd97bc887d6b2b0f0c8 upstream. This is a port of cedb655a3a7764c3fd946077944383c9e0e68dd4 to older asics. Fixes a possible divide by 0 if the harvest register is invalid. v2: drop some additional harvest munging. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 907ed7ee43a3fee9759f99f163fe34754e49a006 Author: Alex Deucher Date: Tue Aug 19 11:56:38 2014 -0400 drm/radeon: fix active_cu mask on SI and CIK after re-init (v3) commit 52da51f0f9ea9d213adfc99223630707b26d1d38 upstream. Need to initialize the mask to 0 on init, otherwise it keeps increasing. bug: https://bugzilla.kernel.org/show_bug.cgi?id=82581 v2: also fix cu count v3: split count fix into separate patch Signed-off-by: Alex Deucher Reviewed-by: Michel Dänzer Signed-off-by: Greg Kroah-Hartman commit d78a30804a0d47f16f17d99cc74021030503efbf Author: Alex Deucher Date: Tue Aug 19 11:54:15 2014 -0400 drm/radeon: fix active cu count for SI and CIK commit 6101b3ae94b4f266456308824e9ca4eab1235d1a upstream. This fixes the CU count reported to userspace for OpenCL. bug: https://bugzilla.kernel.org/show_bug.cgi?id=82581 Signed-off-by: Alex Deucher Reviewed-by: Michel Dänzer Signed-off-by: Greg Kroah-Hartman commit 05396d20dc953fb4ed295693afb2095963b1c4c4 Author: Alex Deucher Date: Mon Aug 18 11:57:28 2014 -0400 drm/radeon: fix pm handling in radeon_gpu_reset commit c940b4476f4fb649f6493b6a0ae837474ded8915 upstream. pm_suspend is handled in the radeon_suspend callbacks. pm_resume has special handling depending on whether dpm or legacy pm is enabled. Change radeon_gpu_reset to mirror the behavior in the suspend and resume pathes. Signed-off-by: Alex Deucher Reviewed-by: Christian König Signed-off-by: Greg Kroah-Hartman commit d7df33d81dfede0b5d6fde96cdda40cd17e32921 Author: Christian König Date: Fri Aug 15 11:52:53 2014 +0200 drm/radeon: properly document reloc priority mask commit 701e1e789142042144c8cc10b8f6d1554e960144 upstream. Instead of hard coding the value properly document that this is an userspace interface. No intended functional change. Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 64e33caeb3d86d79c379cc33925b3ea415a7c989 Author: Alex Deucher Date: Thu Aug 14 01:22:31 2014 -0400 drm/radeon/dpm: select the appropriate vce power state for KV/KB/ML commit c83dec3bb6c38629398b65c231c80978b3e00e14 upstream. Compare the clock in the limits table to the requested evclk rather than just taking the first value. Improves vce performance in certain cases. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ac3e0959ede8f70c44eb936c7ea9b83fb41b2826 Author: Oleg Chernovskiy Date: Mon Aug 11 21:53:46 2014 +0400 drm/radeon: Add missing lines to ci_set_thermal_temperature_range commit 6bce8d9772c1c606921a9c99e566eb14202f6669 upstream. Properly set the thermal min and max temp on CI. Otherwise, we end up setting the thermal ranges to 0 on resume and end up in the lowest power state. Signed-off-by: Oleg Chernovskiy Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 76325a92203b7db278a88d4e676de118bd4345f2 Author: Pali Rohár Date: Mon Aug 11 19:01:58 2014 +0200 drm/radeon: Add ability to get and change dpm state when radeon PX card is turned off commit b07a657e3a05b81c8a30d60e3f3746ca5a48ee62 upstream. This fixing commit 4f2f203976964e267dc477de6648bdb3acd2b74b bug: https://bugzilla.kernel.org/show_bug.cgi?id=76321 Signed-off-by: Pali Rohár Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e7d2e5620110eeb6e618bb23b7dc5aad0b7028b4 Author: Thomas Hellstrom Date: Thu Aug 28 11:53:23 2014 +0200 drm/vmwgfx: Fix a potential infinite spin waiting for fifo idle commit f01ea0c3d9db536c64d47922716d8b3b8f21d850 upstream. The code waiting for fifo idle was incorrect and could possibly spin forever under certain circumstances. Signed-off-by: Thomas Hellstrom Reported-by: Mark Sheldon Reviewed-by: Jakob Bornecrantz Reivewed-by: Mark Sheldon Signed-off-by: Greg Kroah-Hartman commit 51d72e1430c2c74f3a665ed87305c4d9e80f27a4 Author: Russell King Date: Mon Sep 1 18:07:38 2014 +0100 imx-drm: imx-ldb: fix NULL pointer in imx_ldb_unbind() commit d9fdb9fba7ec08769594abede8f78523ed3f025a upstream. When trying to unbind imx-drm, the following oops was observed from the imx-ldb driver: Unable to handle kernel NULL pointer dereference at virtual address 0000001c pgd = de954000 [0000001c] *pgd=2e92c831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] SMP ARM Modules linked in: bnep rfcomm bluetooth nfsd exportfs hid_cypress brcmfmac brcmutil snd_soc_fsl_ssi snd_soc_fsl_spdif imx_pcm_fiq imx_pcm_dma imx_ldb(C) imx_thermal imx_sdma imx2_wdt snd_soc_sgtl5000 snd_soc_imx_sgtl5000 snd_soc_imx_spdif snd_soc_imx_audmux CPU: 1 PID: 1228 Comm: bash Tainted: G C 3.16.0-rc2+ #1229 task: ea378d80 ti: de948000 task.ti: de948000 PC is at imx_ldb_unbind+0x1c/0x58 [imx_ldb] LR is at component_unbind+0x38/0x70 pc : [] lr : [] psr: 200f0013 sp : de949da8 ip : de949dc0 fp : de949dbc r10: e9a44b0c r9 : 00000000 r8 : de949f78 r7 : 00000012 r6 : e9b3f400 r5 : e9b133b8 r4 : e9b13010 r3 : 00000000 r2 : e9b3f400 r1 : ea9a0210 r0 : e9b13020 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c53c7d Table: 2e95404a DAC: 00000015 Process bash (pid: 1228, stack limit = 0xde948240) Stack: (0xde949da8 to 0xde94a000) ... Backtrace: [] (imx_ldb_unbind [imx_ldb]) from [] (component_unbind+0x38/0x70) [] (component_unbind) from [] (component_unbind_all+0x94/0xc8) [] (component_unbind_all) from [] (imx_drm_driver_unload+0x34/0x4c) [] (imx_drm_driver_unload) from [] (drm_dev_unregister+0x2c/0xa0) [] (drm_dev_unregister) from [] (drm_put_dev+0x30/0x6c) [] (drm_put_dev) from [] (imx_drm_unbind+0x14/0x18) [] (imx_drm_unbind) from [] (component_master_del+0xbc/0xd8) ... Code: e5904058 e2840010 e2845fea e59430a0 (e593301c) ---[ end trace 4f211c6dbbcd4963 ]--- This is caused by only having one channel out of the pair configured in DT; the second channel remains uninitialised, but upon unbind, the driver attempts to clean up both, thereby dereferencing a NULL pointer. Avoid this by checking that the second channel is initialised. Fixes: 1b3f76756633 ("imx-drm: initialise drm components directly") Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 468d1a79ef0fdcbee1e0d810cd40b5f975efbde5 Author: Russell King Date: Mon Sep 1 18:07:33 2014 +0100 imx-drm: ipuv3-plane: fix ipu_plane_dpms() commit 3a44a2058747d71385eb69691c7f977cb58cc293 upstream. When unbinding imx-drm, the following oops was observed: Unable to handle kernel NULL pointer dereference at virtual address 00000004 pgd = e995c000 [00000004] *pgd=4fea5831 Internal error: Oops: 817 [#1] SMP ARM Modules linked in: bnep rfcomm bluetooth nfsd exportfs hid_cypress brcmfmac brcmutil snd_soc_fsl_ssi snd_soc_fsl_spdif imx_pcm_fiq imx_pcm_dma snd_soc_sgtl5000 imx_sdma imx2_wdt imx_ldb(C) imx_thermal snd_soc_imx_sgtl5000 snd_soc_imx_spdif snd_soc_imx_audmux CPU: 1 PID: 779 Comm: bash Tainted: G C 3.16.0-rc2+ #1230 task: ea9eb180 ti: ea378000 task.ti: ea378000 PC is at ipu_dp_put+0x10/0x18 LR is at ipu_plane_dpms+0x60/0x8c pc : [] lr : [] psr: 200f0013 sp : ea379d80 ip : ea379d90 fp : ea379d8c r10: 00100100 r9 : 00000000 r8 : 00200200 r7 : e9ba0264 r6 : e9ba01f8 r5 : 00000000 r4 : ea34b800 r3 : 00000000 r2 : 00000000 r1 : 0000009b r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c53c7d Table: 3995c04a DAC: 00000015 Process bash (pid: 779, stack limit = 0xea378240) Stack: (0xea379d80 to 0xea37a000) ... Backtrace: [] (ipu_dp_put) from [] (ipu_plane_dpms+0x60/0x8c) [] (ipu_plane_dpms) from [] (ipu_disable_plane+0x2c/0x60) [] (ipu_disable_plane) from [] (ipu_plane_destroy+0x28/0x60) [] (ipu_plane_destroy) from [] (drm_mode_config_cleanup+0x1b8/0x250) [] (drm_mode_config_cleanup) from [] (imx_drm_driver_unload+0x44/0x4c) [] (imx_drm_driver_unload) from [] (drm_dev_unregister+0x2c/0xa0) [] (drm_dev_unregister) from [] (drm_put_dev+0x30/0x6c) [] (drm_put_dev) from [] (imx_drm_unbind+0x14/0x18) [] (imx_drm_unbind) from [] (component_master_del+0xbc/0xd8) ... Code: e1a0c00d e92dd800 e24cb004 e3a03000 (e5c03004) This is caused by a missing check in ipu_plane_dpms for a NULL pointer. Fixes: b8d181e408af ("staging: drm/imx: add drm plane support") Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit c84162d160a44cdd29689d536adc0005e7b740c6 Author: Y.C. Chen Date: Wed Sep 10 12:07:54 2014 +0800 drm/ast: AST2000 cannot be detected correctly commit 83502a5d34386f7c6973bc70e1c423f55f5a2e3a upstream. Type error and cause AST2000 cannot be detected correctly Signed-off-by: Y.C. Chen Reviewed-by: Egbert Eich Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 6064a72983d67dce2a22d78cca21ef0a8d14a8c9 Author: Y.C. Chen Date: Wed Sep 10 12:07:53 2014 +0800 drm/ast: open key before detect chips commit 8f372e250ae5f4a5faf87ca1a629d0ae59db65b6 upstream. Some config settings like 3rd TX chips will not get correctly if the extended reg is protected Signed-off-by: Y.C. Chen Reviewed-by: Egbert Eich Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit bab81730051ce5c6edff8819fb28e6085d79e02c Author: Brad Volkin Date: Mon Sep 22 08:25:21 2014 -0700 drm/i915: Don't leak command parser tables on suspend/resume commit 22cb99af39b5d4aae075a5bc9da615ba245227cd upstream. Ring init and cleanup are not balanced because we re-init the rings on resume without having cleaned them up on suspend. This leads to the driver leaking the parser's hash tables with a kmemleak signature such as this: unreferenced object 0xffff880405960980 (size 32): comm "systemd-udevd", pid 516, jiffies 4294896961 (age 10202.044s) hex dump (first 32 bytes): d0 85 46 c0 ff ff ff ff 00 00 00 00 00 00 00 00 ..F............. 98 60 28 04 04 88 ff ff 00 00 00 00 00 00 00 00 .`(............. backtrace: [] kmemleak_alloc+0x4e/0xb0 [] kmem_cache_alloc_trace+0x168/0x2f0 [] i915_cmd_parser_init_ring+0x2a5/0x3e0 [i915] [] intel_init_ring_buffer+0x202/0x470 [i915] [] intel_init_vebox_ring_buffer+0x1e8/0x2b0 [i915] [] i915_gem_init_hw+0x2f9/0x3a0 [i915] [] i915_gem_init+0x57/0x1d0 [i915] [] i915_driver_load+0xc0a/0x10e0 [i915] [] drm_dev_register+0xad/0x100 [drm] [] drm_get_pci_dev+0x8f/0x200 [drm] [] i915_pci_probe+0x3b/0x60 [i915] [] local_pci_probe+0x45/0xa0 [] pci_device_probe+0xd9/0x130 [] driver_probe_device+0x12d/0x3e0 [] __driver_attach+0x93/0xa0 [] bus_for_each_dev+0x6b/0xb0 This patch extends the current convention of checking whether a resource is already allocated before allocating it during ring init. Longer term it might make sense to only init the rings once. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83794 Tested-by: Kari Suvanto Signed-off-by: Brad Volkin Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 90eebce35adabb7e0a220c36c71a2ebd00dc5e33 Author: Jani Nikula Date: Wed Sep 17 15:34:58 2014 +0300 drm/i915/hdmi: fix hdmi audio state readout commit c84db77010877da6c5da119868ed54c43d59e726 upstream. Check the correct bit for audio. Seems like a copy-paste error from the start: commit 9ed109a7b445e3f073d8ea72f888ec80c0532465 Author: Daniel Vetter Date: Thu Apr 24 23:54:52 2014 +0200 drm/i915: Track has_audio in the pipe config Reported-by: Martin Andersen Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82756 Cc: Daniel Vetter Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit f54bd2d7610032064327098a2da3c623db74722a Author: Ville Syrjälä Date: Mon Sep 8 17:43:01 2014 +0300 drm/i915: Wait for vblank before enabling the TV encoder commit 7a98948f3b536ca9a077e84966ddc0e9f53726df upstream. The vblank waits in intel_tv_detect_type() are timing out for some reason. This is a regression caused removing seemingly useless vblank waits from the modeset seqeuence in: commit 56ef52cad5e37fca89638e4bad598a994ecc3d9f Author: Ville Syrjälä Date: Thu May 8 19:23:15 2014 +0300 drm/i915: Kill vblank waits after pipe enable on gmch platforms So it turns out they weren't all entirely useless. Apparently the pipe has to go through one full frame before we enable the TV port. Add a vblank wait to intel_enable_tv() to make sure that happens. Another approach was attempted by placing the vblank wait just after enabling the port. The theory behind that attempt was that we need to let the port stay enabled for one full frame before disabling it again during load detection. But that didn't work, and we definitely must have the vblank wait before enabling the port. Cc: Alan Bartlett Tested-by: Alan Bartlett Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79311 Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 6f24f542e98850ce4f5d367f6797ec4999aefddc Author: Daniel Vetter Date: Thu Sep 4 09:36:18 2014 +0200 drm/i915: Fix EIO/wedged handling in gem fault handler commit 2232f0315c6688f5ff6b2067ea88d97542034873 upstream. In commit 1f83fee08d625f8d0130f9fe5ef7b17c2e022f3c Author: Daniel Vetter Date: Thu Nov 15 17:17:22 2012 +0100 drm/i915: clear up wedged transitions I've accidentally inverted the EIO/wedged handling in the fault handler: We want to return the EIO as a SIGBUS only if it's not because of the gpu having died, to prevent userspace from unduly dying. In my defence the comment right above is completely misleading, so fix both. v2: Drop the WARN_ON, it's not actually a bug to e.g. receive an -EIO when swap-in fails. v3: Don't remove too much ... oops. Reported-by: Chris Wilson Cc: Chris Wilson Signed-off-by: Daniel Vetter Reviewed-by: Chris Wilson Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 3bcf9780de504719929918efb2155fe47251da8d Author: Ville Syrjälä Date: Tue Sep 2 12:57:22 2014 +0300 drm/i915: Fix lock dropping in intel_tv_detect() commit bbfb44e8b688e778964275ab0862f67463ba4f84 upstream. When intel_tv_detect() fails to do load detection it would forget to drop the locks and clean up the acquire context. Fix it up. This is a regression from: commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44 Author: Ville Syrjälä Date: Mon Aug 11 13:15:35 2014 +0300 drm/i915: Fix locking for intel_enable_pipe_a() v2: Make the code more readable (Chris) v3: Drop WARN_ON(type < 0) (Chris) Cc: Tibor Billes Reported-by: Tibor Billes Tested-by: Tibor Billes Reviewed-by: Chris Wilson Signed-off-by: Ville Syrjälä Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 6760b98619301afd2bde507e756d239a52245595 Author: Mathias Krause Date: Wed Aug 27 18:41:19 2014 +0200 drm/i915: Remove bogus __init annotation from DMI callbacks commit bbe1c2740d3a25aa1dbe5d842d2ff09cddcdde0a upstream. The __init annotations for the DMI callback functions are wrong as this code can be called even after the module has been initialized, e.g. like this: # echo 1 > /sys/bus/pci/devices/0000:00:02.0/remove # modprobe i915 # echo 1 > /sys/bus/pci/rescan The first command will remove the PCI device from the kernel's device list so the second command won't see it right away. But as it registers a PCI driver it'll see it on the third command. If the system happens to match one of the DMI table entries we'll try to call a function in long released memory and generate an Oops, at best. Fix this by removing the bogus annotation. Modpost should have caught that one but it ignores section reference mismatches from the .rodata section. :/ Fixes: 25e341cfc33d ("drm/i915: quirk away broken OpRegion VBT") Fixes: 8ca4013d702d ("CHROMIUM: i915: Add DMI override to skip CRT...") Fixes: 425d244c8670 ("drm/i915: ignore LVDS on intel graphics systems...") Signed-off-by: Mathias Krause Cc: Daniel Vetter Cc: Duncan Laurie Cc: Jarod Wilson Cc: Rusty Russell # Can modpost be fixed? Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 3149c916e42b65aa57155aa294d9cec7ee8a7bf8 Author: Scot Doyle Date: Thu Aug 21 16:08:02 2014 +0000 drm/i915: Ignore VBT backlight presence check on Acer C720 (4005U) commit dfb3d47b2369ad752ab9f7438bbf9949524b46ae upstream. commit c675949ec58ca50d5a3ae3c757892f1560f6e896 Author: Jani Nikula Date: Wed Apr 9 11:31:37 2014 +0300 drm/i915: do not setup backlight if not available according to VBT prevents backlight setup on the Acer C720 (Core i3 4005U CPU), which has a misconfigured VBT. Apply quirk to ignore the VBT backlight presence check during backlight setup. Signed-off-by: Scot Doyle Tested-by: Tyler Cleveland Cc: Jani Nikula Cc: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit d5af5eab57dcde1ae3575bc86f5240d645db27e1 Author: Paulo Zanoni Date: Fri Aug 15 15:59:32 2014 -0300 drm/i915: fix plane/cursor handling when runtime suspended commit d6dd6843ff4a57c662dbc378b9f99a9c034b0956 upstream. If we're runtime suspended and try to use the plane interfaces, we will get a lot of WARNs saying we did the wrong thing. We need to get runtime PM references to pin the objects, and to change the fences. The pin functions are the ideal places for this, but intel_crtc_cursor_set_obj() doesn't call them, so we also have to add get/put calls inside it. There is no problem if we runtime suspend right after these functions are finished, because the registers written are forwarded to system memory. Note: for a complete fix of the cursor-dpms test case, we also need the patch named "drm/i915: Don't try to enable cursor from setplane when crtc is disabled". v2: - Narrow the put/get calls on intel_crtc_cursor_set_obj() (Daniel) v3: - Make get/put also surround the fence and unpin calls (Daniel and Ville). - Merge all the plane changes into a single patch since they're the same fix. - Add the comment requested by Daniel. v4: - Remove spurious whitespace (Ville). v5: - Remove intel_crtc_update_cursor() chunk since Ville did an equivalent fix in another patch (Ville). v6: - Remove unpin chunk: it will be on a separate patch (Ville, Chris, Daniel). v7: - Same thing, new color. Testcase: igt/pm_rpm/cursor Testcase: igt/pm_rpm/cursor-dpms Testcase: igt/pm_rpm/legacy-planes Testcase: igt/pm_rpm/legacy-planes-dpms Testcase: igt/pm_rpm/universal-planes Testcase: igt/pm_rpm/universal-planes-dpms Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81645 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82603 Signed-off-by: Paulo Zanoni Reviewed-by: Ville Syrjälä Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit a81dc68e37edb97cfd6eddbc4b5a594a123519ac Author: Imre Deak Date: Mon Aug 18 14:42:46 2014 +0300 drm/i915: don't try to retrain a DP link on an inactive CRTC commit 1a125d8a2c22b11741fc47d4ffcf7a5ffa044dd3 upstream. Atm we may retrain the DP link even if the CRTC is inactive through HPD work->intel_dp_check_link_status(). This in turn can lock up the PHY (at least on BYT), since the DP port is disabled. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81948 Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit ecc68a4b6e38a818f03db0201c07d3a03e6567ea Author: Ville Syrjälä Date: Mon Aug 11 13:15:35 2014 +0300 drm/i915: Fix locking for intel_enable_pipe_a() commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44 upstream. intel_enable_pipe_a() gets called with all the modeset locks already held (by drm_modeset_lock_all()), so trying to grab the same locks using another drm_modeset_acquire_ctx is going to fail miserably. Move most of the drm_modeset_acquire_ctx handling (init/drop/fini) out from intel_{get,release}_load_detect_pipe() into the callers (intel_{crt,tv}_detect()). Only the actual locking and backoff handling is left in intel_get_load_detect_pipe(). And in intel_enable_pipe_a() we just share the mode_config.acquire_ctx from drm_modeset_lock_all() which is already holding all the relevant locks. It's perfectly legal to lock the same ww_mutex multiple times using the same ww_acquire_ctx. drm_modeset_lock() will convert the returned -EALREADY into 0, so the caller doesn't need to do antyhing special. Fixes a hang on resume on my 830. Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit e77979325d8f613c0fa127b0a9437f003d0dd865 Author: Ville Syrjälä Date: Mon Aug 11 13:15:36 2014 +0300 drm/i915: Skip load detect when intel_crtc->new_enable==true commit a459249c73eaec1daf4e4657ea3564cc3550e66c upstream. During suspend we turn off the crtcs, but leave the staged config in place so that we can restore the display(s) to their previous state on resume. During resume when we attempt to apply the force pipe A quirk we use the load detect mechanism. That doesn't check whether there was an already staged configuration for the crtc since that's not even possible during normal runtime load detection. But during resume it is possible, and if we just blindly go and overwrite the staged crtc configuration for the load detection we can no longer restore the display to the correct state. Even worse, we don't even clear all the staged connector->encoder->crtc links so we may end up using a cloned setup for the load detection, and after we're done we just clear the links related to the VGA output leaving the links for the other outputs in place. This will eventually result in calling intel_set_mode() with mode==NULL but with valid connector->encoder->crtc links which will result in dereferencing the NULL mode since the code thinks it will have to a modeset. To avoid these problems don't use any crtc with new_enabled==true for load detection. Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 4c19ba5c5e943803ff09200fef560546a32bc149 Author: Filipe Brandenburger Date: Fri Aug 29 15:18:51 2014 -0700 xattr: fix check for simultaneous glibc header inclusion commit bfcfd44cce2774f19daeb59fb4e43fc9aa80e7b8 upstream. The guard was introduced in commit ea1a8217b06b ("xattr: guard against simultaneous glibc header inclusion") but it is using #ifdef to check for a define that is either set to 1 or 0. Fix it to use #if instead. * Without this patch: $ { echo "#include "; echo "#include "; } | gcc -E -Iinclude/uapi - >/dev/null include/uapi/linux/xattr.h:19:0: warning: "XATTR_CREATE" redefined [enabled by default] #define XATTR_CREATE 0x1 /* set value, fail if attr already exists */ ^ /usr/include/x86_64-linux-gnu/sys/xattr.h:32:0: note: this is the location of the previous definition #define XATTR_CREATE XATTR_CREATE ^ * With this patch: $ { echo "#include "; echo "#include "; } | gcc -E -Iinclude/uapi - >/dev/null (no warnings) Signed-off-by: Filipe Brandenburger Acked-by: Serge E. Hallyn Cc: Allan McRae Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit af85b8619e6445594df097e713eb222e3b38f45f Author: Benjamin Tissoires Date: Fri Aug 22 16:16:05 2014 -0400 HID: logitech-dj: prevent false errors to be shown commit 5abfe85c1d4694d5d4bbd13ecc166262b937adf0 upstream. Commit "HID: logitech: perform bounds checking on device_id early enough" unfortunately leaks some errors to dmesg which are not real ones: - if the report is not a DJ one, then there is not point in checking the device_id - the receiver (index 0) can also receive some notifications which can be safely ignored given the current implementation Move out the test regarding the report_id and also discards printing errors when the receiver got notified. Fixes: ad3e14d7c5268c2e24477c6ef54bbdf88add5d36 Reported-and-tested-by: Markus Trippelsdorf Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 249b61a6ba71975a83031c06b22013a37619a8b7 Author: Jiri Kosina Date: Wed Aug 27 09:12:24 2014 +0200 HID: magicmouse: sanity check report size in raw_event() callback commit c54def7bd64d7c0b6993336abcffb8444795bf38 upstream. The report passed to us from transport driver could potentially be arbitrarily large, therefore we better sanity-check it so that magicmouse_emit_touch() gets only valid values of raw_id. Reported-by: Steven Vittitoe Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 0db6de5fa66e02a03089d69bdc5db6d6947ed76b Author: Jiri Kosina Date: Wed Aug 27 09:13:15 2014 +0200 HID: picolcd: sanity check report size in raw_event() callback commit 844817e47eef14141cf59b8d5ac08dd11c0a9189 upstream. The report passed to us from transport driver could potentially be arbitrarily large, therefore we better sanity-check it so that raw_data that we hold in picolcd_pending structure are always kept within proper bounds. Reported-by: Steven Vittitoe Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 41549646bc65252c882d2c9d0314089818a38eaf Author: Toshiaki Makita Date: Tue Aug 26 20:56:36 2014 +0900 cfq-iosched: Fix wrong children_weight calculation commit e15693ef18e13e3e6bffe891fe140f18b8ff6d07 upstream. cfq_group_service_tree_add() is applying new_weight at the beginning of the function via cfq_update_group_weight(). This actually allows weight to change between adding it to and subtracting it from children_weight, and triggers WARN_ON_ONCE() in cfq_group_service_tree_del(), or even causes oops by divide error during vfr calculation in cfq_group_service_tree_add(). The detailed scenario is as follows: 1. Create blkio cgroups X and Y as a child of X. Set X's weight to 500 and perform some I/O to apply new_weight. This X's I/O completes before starting Y's I/O. 2. Y starts I/O and cfq_group_service_tree_add() is called with Y. 3. cfq_group_service_tree_add() walks up the tree during children_weight calculation and adds parent X's weight (500) to children_weight of root. children_weight becomes 500. 4. Set X's weight to 1000. 5. X starts I/O and cfq_group_service_tree_add() is called with X. 6. cfq_group_service_tree_add() applies its new_weight (1000). 7. I/O of Y completes and cfq_group_service_tree_del() is called with Y. 8. I/O of X completes and cfq_group_service_tree_del() is called with X. 9. cfq_group_service_tree_del() subtracts X's weight (1000) from children_weight of root. children_weight becomes -500. This triggers WARN_ON_ONCE(). 10. Set X's weight to 500. 11. X starts I/O and cfq_group_service_tree_add() is called with X. 12. cfq_group_service_tree_add() applies its new_weight (500) and adds it to children_weight of root. children_weight becomes 0. Calcularion of vfr triggers oops by divide error. weight should be updated right before adding it to children_weight. Reported-by: Ruki Sekiya Signed-off-by: Toshiaki Makita Acked-by: Tejun Heo Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b6e46ec9a4ace9820d1dd37387f83962d238b0b0 Author: Clemens Ladisch Date: Sun Sep 21 22:50:57 2014 +0200 ALSA: pcm: fix fifo_size frame calculation commit a9960e6a293e6fc3ed414643bb4e4106272e4d0a upstream. The calculated frame size was wrong because snd_pcm_format_physical_width() actually returns the number of bits, not bytes. Use snd_pcm_format_size() instead, which not only returns bytes, but also simplifies the calculation. Fixes: 8bea869c5e56 ("ALSA: PCM midlevel: improve fifo_size handling") Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8538efc10797c5931c9b3c116d311814c502cb4b Author: Huacai Chen Date: Fri Sep 19 14:57:02 2014 +0800 ALSA: hda - Add fixup model name lookup for Lemote A1205 commit 8245b3634516e6b7eb1c94594c0fd41d233502aa upstream. Lemote A1004 is already added in commit a2dd933d01f (ALSA: hda - Add fixup name lookup for CX5051 and 5066 codecs), but Lemote A1205 has missing. Signed-off-by: Huacai Chen Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7d10d26d9e17ddc0781310c9e4cf280fcb29f546 Author: Takashi Iwai Date: Thu Sep 11 12:59:21 2014 +0200 ALSA: hda - Fix invalid pin powermap without jack detection commit 7a9744cb455e6faa287e148394b4b422a6f3c5c4 upstream. When a driver is set up without the jack detection explicitly (either by passing a model option or via a specific fixup), the pin powermap of IDT/STAC codecs is set up wrongly, resulting in the silence output. It's because of a logic failure in stac_init_power_map(). It tries to avoid creating a callback for the pins that have other auto-hp and auto-mic callbacks, but the check is done in a wrong way at a wrong time. The stac_init_power_map() should be called after creating other jack detection ctls, and the jack callback should be created only for jack-detectable widgets. This patch fixes the check in stac_init_power_map() and its callee at the right place, after snd_hda_gen_build_controls(). Reported-by: Adam Richter Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 26f3f4fd6fc4fb2fab8c234475b7380fc09ae828 Author: Takashi Iwai Date: Tue Sep 2 07:21:56 2014 +0200 ALSA: hda - Fix COEF setups for ALC1150 codec commit acf08081adb5e8fe0519eb97bb49797ef52614d6 upstream. ALC1150 codec seems to need the COEF- and PLL-setups just like its compatible ALC882 codec. Some machines (e.g. SunMicro X10SAT) show the problem like too low output volumes unless the COEF setup is applied. Reported-and-tested-by: Dana Goyette Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 288a0603b4295a6841cae1dce945656a8c5454e8 Author: Takashi Iwai Date: Mon Sep 1 14:26:49 2014 +0200 ALSA: hda - Fix digital mic on Acer Aspire 3830TG commit ff50479ad61069f3ee14863225aebe36d598e93e upstream. Acer Aspire 3830TG with CX20588 codec has a digital built-in mic that has the same problem like many others, the inverted signal in stereo. Apply the same fixup to this machine, too. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 329ea7a2beeac482e421c627b7e8d439aeaa0024 Author: Takashi Sakamoto Date: Fri Aug 29 13:40:45 2014 +0900 ALSA: firewire-lib/dice: add arrangements of PCM pointer and interrupts for Dice quirk commit 65845f29bec6bc17f80eff25c3bc39bcf3be9bf9 upstream. In IEC 61883-6, one data block transfers one event. In ALSA, the event equals one PCM frame, hence one data block transfers one PCM frame. But Dice has a quirk at higher sampling rate (176.4/192.0 kHz) that one data block transfers two PCM frames. Commit 10550bea44a8 ("ALSA: dice/firewire-lib: Keep dualwire mode but obsolete CIP_HI_DUALWIRE") moved some codes related to this quirk into Dice driver. But the commit forgot to add arrangements for PCM period interrupts and DMA pointer updates. As a result, Dice driver cannot work correctly at higher sampling rate. This commit adds 'double_pcm_frames' parameter to amdtp structure for this quirk. When this parameter is set, PCM period interrupts and DMA pointer updates occur at double speed than in IEC 61883-6. Reported-by: Daniel Robbins Fixes: 10550bea44a8 ("ALSA: dice/firewire-lib: Keep dualwire mode but obsolete CIP_HI_DUALWIRE") Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c602cc99872e15d12691b0eff18eaa5e7c9ba439 Author: Takashi Sakamoto Date: Fri Aug 29 13:40:44 2014 +0900 ALSA: dice: fix wrong channel mappping at higher sampling rate commit 1033eb5b5aeeb526c22068e0fb0cef9f3c14231e upstream. The channel mapping is initialized by amdtp_stream_set_parameters(), however Dice driver set it before calling this function. Furthermore, the setting is wrong because the index is the value of array, and vice versa. This commit moves codes for channel mapping after the function and set it correctly. Reported-by: Daniel Robbins Fixes: 10550bea44a8 ("ALSA: dice/firewire-lib: Keep dualwire mode but obsolete CIP_HI_DUALWIRE") Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c790a6bd6207d627bf9bbbf51b99c29356e6d48e Author: Clemens Ladisch Date: Thu Aug 21 20:55:21 2014 +0200 ALSA: core: fix buffer overflow in snd_info_get_line() commit ddc64b278a4dda052390b3de1b551e59acdff105 upstream. snd_info_get_line() documents that its last parameter must be one less than the buffer size, but this API design guarantees that (literally) every caller gets it wrong. Just change this parameter to have its obvious meaning. Reported-by: Tommi Rantala Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9486b8c74b5d02f108738e185c41ec39226501b9 Author: Will Deacon Date: Fri Aug 22 14:13:24 2014 +0100 arm64: ptrace: fix compat hardware watchpoint reporting commit 27d7ff273c2aad37b28f6ff0cab2cfa35b51e648 upstream. I'm not sure what I was on when I wrote this, but when iterating over the hardware watchpoint array (hbp_watch_array), our index is off by ARM_MAX_BRP, so we walk off the end of our thread_struct... ... except, a dodgy condition in the loop means that it never executes at all (bp cannot be NULL). This patch fixes the code so that we remove the bp check and use the correct index for accessing the watchpoint structures. Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 599f831a1aea9e85d42a1d0e6c53e193f5d2dd34 Author: Josef Bacik Date: Mon Aug 25 13:59:41 2014 -0400 trace: Fix epoll hang when we race with new entries commit 4ce97dbf50245227add17c83d87dc838e7ca79d0 upstream. Epoll on trace_pipe can sometimes hang in a weird case. If the ring buffer is empty when we set waiters_pending but an event shows up exactly at that moment we can miss being woken up by the ring buffers irq work. Since ring_buffer_empty() is inherently racey we will sometimes think that the buffer is not empty. So we don't get woken up and we don't think there are any events even though there were some ready when we added the watch, which makes us hang. This patch fixes this by making sure that we are actually on the wait list before we set waiters_pending, and add a memory barrier to make sure ring_buffer_empty() is going to be correct. Link: http://lkml.kernel.org/p/1408989581-23727-1-git-send-email-jbacik@fb.com Cc: Martin Lau Signed-off-by: Josef Bacik Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 7d125f0d5baaa8cd21e81d826e8f6553c8bc3b8c Author: Steven Rostedt (Red Hat) Date: Sun Aug 17 20:59:10 2014 -0400 ftrace: Use current addr when converting to nop in __ftrace_replace_code() commit 39b5552cd5090d4c210d278cd2732f493075f033 upstream. In __ftrace_replace_code(), when converting the call to a nop in a function it needs to compare against the "curr" (current) value of the ftrace ops, and not the "new" one. It currently does not affect x86 which is the only arch to do the trampolines with function graph tracer, but when other archs that do depend on this code implement the function graph trampoline, it can crash. Here's an example when ARM uses the trampolines (in the future): ------------[ cut here ]------------ WARNING: CPU: 0 PID: 9 at kernel/trace/ftrace.c:1716 ftrace_bug+0x17c/0x1f4() Modules linked in: omap_rng rng_core ipv6 CPU: 0 PID: 9 Comm: migration/0 Not tainted 3.16.0-test-10959-gf0094b28f303-dirty #52 [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [] (show_stack) from [] (dump_stack+0x78/0x94) [] (dump_stack) from [] (warn_slowpath_common+0x7c/0x9c) [] (warn_slowpath_common) from [] (warn_slowpath_null+0x2c/0x34) [] (warn_slowpath_null) from [] (ftrace_bug+0x17c/0x1f4) [] (ftrace_bug) from [] (ftrace_replace_code+0x80/0x9c) [] (ftrace_replace_code) from [] (ftrace_modify_all_code+0xb8/0x164) [] (ftrace_modify_all_code) from [] (__ftrace_modify_code+0x14/0x1c) [] (__ftrace_modify_code) from [] (multi_cpu_stop+0xf4/0x134) [] (multi_cpu_stop) from [] (cpu_stopper_thread+0x54/0x130) [] (cpu_stopper_thread) from [] (smpboot_thread_fn+0x1ac/0x1bc) [] (smpboot_thread_fn) from [] (kthread+0xe0/0xfc) [] (kthread) from [] (ret_from_fork+0x14/0x20) ---[ end trace dc9ce72c5b617d8f ]--- [ 65.047264] ftrace failed to modify [] asm_do_IRQ+0x10/0x1c [ 65.054070] actual: 85:1b:00:eb Fixes: 7413af1fb70e7 "ftrace: Make get_ftrace_addr() and get_ftrace_addr_old() global" Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 774795454f6f66a6a69c4be2bd98a6631a1113c2 Author: Fan Du Date: Tue Sep 16 17:21:04 2014 +0800 i2c: ismt: use correct length when copy buffer commit 979bbf7b7ae75cfc06e09d09eda38009a3bdc4a4 upstream. In block write mode, when encapsulating dma_buffer, first element is 'command', the rest is data buffer, so only copy actual data buffer starting from block[1] with the size indicating by block[0]. Signed-off-by: Fan Du Acked-by: Neil Horman Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit fa1211988f43466dde7272c8d282605117b6e592 Author: addy ke Date: Mon Sep 8 11:38:25 2014 +0800 i2c: rk3x: fix divisor calculation for SCL frequency commit b4a7bd7a386dc6b0bb49cb47614e06e8295d495a upstream. I2C_CLKDIV register descripted in the previous version of RK3x chip manual is incorrect. Plus 1 is required. The correct formula: - T(SCL_HIGH) = T(PCLK) * (CLKDIVH + 1) * 8 - T(SCL_LOW) = T(PCLK) * (CLKDIVL + 1) * 8 - (SCL Divsor) = 8 * ((CLKDIVL + 1) + (CLKDIVH + 1)) - SCL = PCLK / (CLK Divsor) It will be updated to the latest version of chip manual. Signed-off-by: Addy Ke Reviewed-by: Doug Anderson Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit e6d7136590f75217544858a9f10655447f9c616e Author: Sergei Shtylyov Date: Sat Sep 6 03:34:32 2014 +0400 i2c: rcar: fix RCAR_IRQ_ACK_{RECV|SEND} commit 938916fbb8e8cb67eacb784f4eda17e2950c16c5 upstream. Bits 8-31 of all registers reflect the value of bits 0-7 on reads and should be 0 on writes, according to the manuals. RCAR_IRQ_ACK_{RECV|SEND} macros have all 1's in bits 8-31, thus going against the manuals, so fix them. Signed-off-by: Sergei Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 893c48cfa1993c872f6e2aeb8ee560d62e14924a Author: Sergei Shtylyov Date: Tue Sep 2 01:15:26 2014 +0400 i2c: rcar: fix MNR interrupt handling commit dd318b0df27c582ac0d72a346fd6e693700be23c upstream. Sometimes the MNR and MST interrupts happen simultaneously (stop automatically follows NACK, according to the manuals) and in such case the ID_NACK flag isn't set since the MST interrupt handling precedes MNR and all interrupts are cleared and disabled then, so that MNR interrupt is never noticed -- this causes NACK'ed transfers to be falsely reported as successful. Exchanging MNR and MST handlers fixes this issue, however the MNR bit somehow gets set again even after being explicitly cleared, so I decided to completely suppress handling of all disabled interrupts (which is a good thing anyway)... Signed-off-by: Sergei Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 2fb2af14c2dfcfbe656a3246b167f87e9ca2ff3c Author: Sergei Shtylyov Date: Sun Aug 24 00:44:09 2014 +0400 Revert "i2c: rcar: remove spinlock" commit 91bfe2989af02e709ca01ccf518c4fbda3efc70f upstream. This reverts commit 150b8be3cda54412ad7b54f5392b513b25c0aaa7. The I2C core's per-adapter locks can't protect from IRQs, so the driver still needs a spinlock to protect the register accesses. Signed-off-by: Sergei Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 705ee1e247ee4f99f0a2975d53f14aa037468b8c Author: Simon Lindgren Date: Tue Aug 26 21:13:24 2014 +0200 i2c: at91: Fix a race condition during signal handling in at91_do_twi_xfer. commit 6721f28a26efd6368497abbdef5dcfc59608d899 upstream. There is a race condition in at91_do_twi_xfer when signals arrive. If a signal is recieved while waiting for a transfer to complete wait_for_completion_interruptible_timeout() will return -ERESTARTSYS. This is not handled correctly resulting in interrupts still being enabled and a transfer being in flight when we return. Symptoms include a range of oopses and bus lockups. Oopses can happen when the transfer completes because the interrupt handler will corrupt the stack. If a new transfer is started before the interrupt fires the controller will start a new transfer in the middle of the old one, resulting in confused slaves and a locked bus. To avoid this, use wait_for_completion_io_timeout instead so that we don't have to deal with gracefully shutting down the transfer and disabling the interrupts. Signed-off-by: Simon Lindgren Acked-by: Ludovic Desroches Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit b998a12e678d205ca6c8ba37e2bd7f576877b5bc Author: Marek Roszko Date: Wed Aug 20 21:39:41 2014 -0400 i2c: at91: add bound checking on SMBus block length bytes commit 75b81f339c6af43f6f4a1b3eabe0603321dade65 upstream. The driver was not bound checking the received length byte to ensure it was within the the buffer size that is allocated for SMBus blocks. This resulted in buffer overflows whenever an invalid length byte was received. It also failed to ensure the length byte was not zero. If it received zero, it would end up in an infinite loop as the at91_twi_read_next_byte function returned immediately without allowing RHR to be read to clear the RXRDY interrupt. Tested agaisnt a SMBus compliant battery. Signed-off-by: Marek Roszko Acked-by: Ludovic Desroches Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 1423ca3aa4335d5443dc4919ee089689750501cc Author: Chen-Yu Tsai Date: Mon Sep 1 22:28:13 2014 +0800 i2c: mv64xxx: continue probe when clock-frequency is missing commit 0ce4bc1dbdd911ae1763e2d4ff36bd1b214a59f7 upstream. The "clock-frequency" DT property is listed as optional, However, the current code stores the return value of of_property_read_u32 in the return code of mv64xxx_of_config, but then forgets to clear it after setting the default value of "clock-frequency". It is then passed out to the main probe function, resulting in a probe failure when "clock-frequency" is missing. This patch checks and then throws away the return value of of_property_read_u32, instead of storing it and having to clear it afterwards. This issue was discovered after the property was removed from all sunxi DTs. Fixes: 4c730a06c19bb ("i2c: mv64xxx: Set bus frequency to 100kHz if clock-frequency is not provided") Signed-off-by: Chen-Yu Tsai Acked-by: Andrew Lunn Acked-by: Maxime Ripard Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 9f22bf51ad4e038739697354cb36874e96afa0cc Author: addy ke Date: Sat Aug 23 02:00:52 2014 +0800 i2c: rk3x: fix bug that cause transfer fails in master receive mode commit 5da4309f9e1b4de9c2b69e917912fbb84006d44e upstream. In rk3x SOC, the I2C controller can receive/transmit up to 32 bytes data in one chunk, so the size of data to be write/read to/from TXDATAx/RXDATAx must be less than or equal 32 bytes at a time. Tested on rk3288-pinky board, elan receive 158 bytes data. Signed-off-by: Addy Ke Acked-by: Max Schwarz Reviewed-by: Doug Anderson Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 52e516141bdb784781258ec6a7f4914d8a07a7ed Author: Pranavkumar Sawargaonkar Date: Thu Jul 31 12:23:23 2014 +0530 ARM/ARM64: KVM: Nuke Hyp-mode tlbs before enabling MMU commit f6edbbf36da3a27b298b66c7955fc84e1dcca305 upstream. X-Gene u-boot runs in EL2 mode with MMU enabled hence we might have stale EL2 tlb enteris when we enable EL2 MMU on each host CPU. This can happen on any ARM/ARM64 board running bootloader in Hyp-mode (or EL2-mode) with MMU enabled. This patch ensures that we flush all Hyp-mode (or EL2-mode) TLBs on each host CPU before enabling Hyp-mode (or EL2-mode) MMU. Tested-by: Mark Rutland Reviewed-by: Marc Zyngier Signed-off-by: Pranavkumar Sawargaonkar Signed-off-by: Anup Patel Signed-off-by: Christoffer Dall Signed-off-by: Greg Kroah-Hartman commit 058a178ea61ff8a71d91c0b1dd3965080664d635 Author: Christoffer Dall Date: Tue Aug 26 14:33:02 2014 +0200 arm/arm64: KVM: Complete WFI/WFE instructions commit 05e0127f9e362b36aa35f17b1a3d52bca9322a3a upstream. The architecture specifies that when the processor wakes up from a WFE or WFI instruction, the instruction is considered complete, however we currrently return to EL1 (or EL0) at the WFI/WFE instruction itself. While most guests may not be affected by this because their local exception handler performs an exception returning setting the event bit or with an interrupt pending, some guests like UEFI will get wedged due this little mishap. Simply skip the instruction when we have completed the emulation. Acked-by: Marc Zyngier Cc: Ard Biesheuvel Signed-off-by: Christoffer Dall Signed-off-by: Greg Kroah-Hartman commit 6240c29b124db4a79a68c77dae8f7f3ac47b0c1c Author: Sudeep Holla Date: Tue Sep 2 11:35:24 2014 +0100 arm64: use irq_set_affinity with force=false when migrating irqs commit 3d8afe3099ebc602848aa7f09235cce3a9a023ce upstream. The arm64 interrupt migration code on cpu offline calls irqchip.irq_set_affinity() with the argument force=true. Originally this argument had no effect because it was not used by any interrupt chip driver and there was no semantics defined. This changed with commit 01f8fa4f01d8 ("genirq: Allow forcing cpu affinity of interrupts") which made the force argument useful to route interrupts to not yet online cpus without checking the target cpu against the cpu online mask. The following commit ffde1de64012 ("irqchip: gic: Support forced affinity setting") implemented this for the GIC interrupt controller. As a consequence the cpu offline irq migration fails if CPU0 is offlined, because CPU0 is still set in the affinity mask and the validation against cpu online mask is skipped to the force argument being true. The following first_cpu(mask) selection always selects CPU0 as the target. Commit 601c942176d8("arm64: use cpu_online_mask when using forced irq_set_affinity") intended to fix the above mentioned issue but introduced another issue where affinity can be migrated to a wrong CPU due to unconditional copy of cpu_online_mask. As with for arm, solve the issue by calling irq_set_affinity() with force=false from the CPU offline irq migration code so the GIC driver validates the affinity mask against CPU online mask and therefore removes CPU0 from the possible target candidates. Also revert the changes done in the commit 601c942176d8 as it's no longer needed. Tested on Juno platform. Fixes: 601c942176d8("arm64: use cpu_online_mask when using forced irq_set_affinity") Signed-off-by: Sudeep Holla Acked-by: Mark Rutland Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 5701dedba6faafba0550d7d2a4c5575289f4092c Author: Will Deacon Date: Thu Sep 11 14:38:16 2014 +0100 arm64: flush TLS registers during exec commit eb35bdd7bca29a13c8ecd44e6fd747a84ce675db upstream. Nathan reports that we leak TLS information from the parent context during an exec, as we don't clear the TLS registers when flushing the thread state. This patch updates the flushing code so that we: (1) Unconditionally zero the tpidr_el0 register (since this is fully context switched for native tasks and zeroed for compat tasks) (2) Zero the tp_value state in thread_info before clearing the tpidrr0_el0 register for compat tasks (since this is only writable by the set_tls compat syscall and therefore not fully switched). A missing compiler barrier is also added to the compat set_tls syscall. Acked-by: Nathan Lynch Reported-by: Nathan Lynch Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit a2549411f0119375abc6b5c0b899a24cebc0e4ec Author: Lothar Waßmann Date: Wed Aug 13 15:47:47 2014 +0200 ARM: dts: i.MX53: fix apparent bug in VPU clks commit fa97d2f7448a2f998bca0f4d4e40d6ad49026554 upstream. The VPU on i.MX53 has two distinct clocks for register access and internal function. Signed-off-by: Lothar Waßmann Fixes: fbf970f61eb9 ("ARM: dts: mx53qsb: Enable VPU support") Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 60be4e6aaf0f2e26910bfb06e147550211081758 Author: Bill Pringlemeir Date: Tue Aug 5 13:34:00 2014 -0400 ARM: dts: vf610-twr: Fix pinctrl_esdhc1 pin definitions. commit 0aa4dcb5b730f5da2540926b94d98636fe7d1cbc upstream. Previous version had an extra 'fsl' which made the pins not match any entry. The console message, vf610-pinctrl 40048000.iomuxc: no fsl,pins property in node \ /soc/aips-bus@40000000/iomuxc@40048000/vf610-twr/esdhc1grp is displayed without the fix. The prior version would generally work as u-boot sets the pins properly for sdhc. This change allows Linux sdhc use even if u-boot is built without sdhc support. Signed-off-by: Bill Pringlemeir Acked-by: Stefan Agner Fixes: 0517fe6aa880 ("ARM: dts: vf610-twr: Add support for sdhc1") Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 2a3620a7e260b80bdd4532415157c4d547d9054d Author: Shawn Guo Date: Sat Jul 26 10:33:03 2014 +0800 ARM: imx: fix TLB missing of IOMUXC base address during suspend commit 59d05b518321618177b898a6801503e31b15b25b upstream. After the suspend routine running in OCRAM puts DDR into self-refresh, it will access IOMUXC block to float DDR IO for power saving. A TLB missing of IOMUXC base address may happen in this case, and triggers an access to DDR, and thus hangs the system. The failure is discovered by running suspend/resume on a Cubox-i board. Though the issue is not Cubox-i specific, it can be hit the on the board quite easily with the 3.15 or 3.16 kernel. Fix the issue with a dummy access to IOMUXC block at the beginning of suspend routine, so that the address translation can be filled into TLB before DDR is put into self-refresh. Signed-off-by: Shawn Guo Acked-by: Anson Huang Signed-off-by: Greg Kroah-Hartman commit e7ac34bf5e041dbeb7596d5db91fd7e4c300da96 Author: Jeff Moyer Date: Tue Sep 2 13:17:00 2014 -0400 aio: add missing smp_rmb() in read_events_ring commit 2ff396be602f10b5eab8e73b24f20348fa2de159 upstream. We ran into a case on ppc64 running mariadb where io_getevents would return zeroed out I/O events. After adding instrumentation, it became clear that there was some missing synchronization between reading the tail pointer and the events themselves. This small patch fixes the problem in testing. Thanks to Zach for helping to look into this, and suggesting the fix. Signed-off-by: Jeff Moyer Signed-off-by: Benjamin LaHaise Signed-off-by: Greg Kroah-Hartman commit b1fd18c3caf2439f18c7fd35421371f2e983f3b8 Author: Benjamin LaHaise Date: Sun Aug 24 13:14:05 2014 -0400 aio: fix reqs_available handling commit d856f32a86b2b015ab180ab7a55e455ed8d3ccc5 upstream. As reported by Dan Aloni, commit f8567a3845ac ("aio: fix aio request leak when events are reaped by userspace") introduces a regression when user code attempts to perform io_submit() with more events than are available in the ring buffer. Reverting that commit would reintroduce a regression when user space event reaping is used. Fixing this bug is a bit more involved than the previous attempts to fix this regression. Since we do not have a single point at which we can count events as being reaped by user space and io_getevents(), we have to track event completion by looking at the number of events left in the event ring. So long as there are as many events in the ring buffer as there have been completion events generate, we cannot call put_reqs_available(). The code to check for this is now placed in refill_reqs_available(). A test program from Dan and modified by me for verifying this bug is available at http://www.kvack.org/~bcrl/20140824-aio_bug.c . Reported-by: Dan Aloni Signed-off-by: Benjamin LaHaise Acked-by: Dan Aloni Cc: Kent Overstreet Cc: Mateusz Guzik Cc: Petr Matousek Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 49283d645b077d0a26fb8177062c2be8c19350f8 Author: Anton Blanchard Date: Fri Aug 22 11:36:52 2014 +1000 ibmveth: Fix endian issues with rx_no_buffer statistic commit cbd5228199d8be45d895d9d0cc2b8ce53835fc21 upstream. Hidden away in the last 8 bytes of the buffer_list page is a solitary statistic. It needs to be byte swapped or else ethtool -S will produce numbers that terrify the user. Since we do this in multiple places, create a helper function with a comment explaining what is going on. Signed-off-by: Anton Blanchard Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 45c406dee19d7dbb2fd521b9337ecad4e38849d1 Author: Geert Uytterhoeven Date: Wed Aug 13 17:18:53 2014 +0200 pwm: Fix period and polarity in pwm_get() for non-perfect matches commit d717ea73e36dd5659640fae82605ad85c4117f4d upstream. If pwm_get() finds a look-up entry with a perfect match (both dev_id and con_id match), the loop is aborted, and "p" still points to the correct struct pwm_lookup. If only an entry with a matching dev_id or con_id is found, the loop terminates after traversing the whole list, and "p" now points to arbitrary memory, not part of the pwm_lookup list. Then pwm_set_period() and pwm_set_polarity() will set random values for period resp. polarity. To fix this, save period and polarity when finding a new best match, just like is done for chip (for the provider) and index. This fixes the LCD backlight on r8a7740/armadillo-legacy, which was fed period 0 and polarity -1068821144 instead of 33333 resp. 1. Fixes: 3796ce1d4d4b ("pwm: add period and polarity to struct pwm_lookup") Signed-off-by: Geert Uytterhoeven Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 9e9ab0f7556d7f0f2ff7acb59e0e130bcc9dc634 Author: Murali Karicheri Date: Fri Sep 5 13:21:00 2014 -0400 ahci: add pcid for Marvel 0x9182 controller commit c5edfff9db6f4d2c35c802acb4abe0df178becee upstream. Keystone K2E EVM uses Marvel 0x9182 controller. This requires support for the ID in the ahci driver. Signed-off-by: Murali Karicheri Signed-off-by: Tejun Heo Cc: Santosh Shilimkar Signed-off-by: Greg Kroah-Hartman commit 57205b045c31353ba422f1971f3edf03a7d1cf2e Author: James Ralston Date: Wed Aug 27 14:29:07 2014 -0700 ahci: Add Device IDs for Intel 9 Series PCH commit 1b071a0947dbce5c184c12262e02540fbc493457 upstream. This patch adds the AHCI mode SATA Device IDs for the Intel 9 Series PCH. Signed-off-by: James Ralston Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit c98c2785dd310488e28099b6d9e2a78746893c9d Author: Arjun Sreedharan Date: Sun Aug 17 20:00:09 2014 +0530 pata_scc: propagate return value of scc_wait_after_reset commit 4dc7c76cd500fa78c64adfda4b070b870a2b993c upstream. scc_bus_softreset not necessarily should return zero. Propagate the error code. Signed-off-by: Arjun Sreedharan Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit cf61af0de62b8a15cde8f900c55b9c51a268a447 Author: Tejun Heo Date: Mon Aug 18 17:40:09 2014 -0400 libata: widen Crucial M550 blacklist matching commit 2a13772a144d2956a7fedd18685921d0a9b8b783 upstream. Crucial M550 may cause data corruption on queued trims and is blacklisted. The pattern used for it fails to match 1TB one as the capacity section will be four chars instead of three. Widen the pattern. Signed-off-by: Tejun Heo Reported-by: Charles Reiss Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81071 Signed-off-by: Greg Kroah-Hartman commit 0e3b51917281e6db61825936ae36c58e14983a62 Author: Florian Fainelli Date: Wed Aug 6 13:02:27 2014 -0700 of/irq: Fix lookup to use 'interrupts-extended' property first commit a9ecdc0fdc54aa499604dbd43132988effcac9b4 upstream. In case the Device Tree blob passed by the boot agent supplies both an 'interrupts-extended' and an 'interrupts' property in order to allow for older kernels to be usable, prefer the new-style 'interrupts-extended' property which conveys a lot more information. This allows us to have bootloaders willingly maintaining backwards compatibility with older kernels without entirely deprecating the 'interrupts' property. Update the bindings documentation to describe a situation where both the 'interrupts-extended' and the 'interrupts' property are present, and which one takes precedence over the other. Acked-by: Rob Herring Signed-off-by: Brian Norris Signed-off-by: Florian Fainelli Signed-off-by: Grant Likely Signed-off-by: Greg Kroah-Hartman commit 5b2834f6e2363a13a40166307c285828f1f1778d Author: Al Cooper Date: Wed Aug 6 16:30:04 2014 -0400 of: Allow mem_reserve of memory with a base address of zero commit b5f2a8c02697c3685ccbbb66495465742ffa0dc1 upstream. __reserved_mem_reserve_reg() won't reserve memory if the base address is zero. This change removes the check for a base address of zero and allows it to be reserved. Allowing the first 4K of memory to be reserved will help solve a problem on some ARM systems where the the first 16K of memory is unused and becomes allocable memory. This will prevent this memory from being used for DMA by drivers like the USB OHCI driver which consider a physical address of zero to be illegal. Signed-off-by: Al Cooper Signed-off-by: Grant Likely Signed-off-by: Greg Kroah-Hartman commit 0b44ffc73efd56f7c07276252a0cbf94dbc2fb78 Author: Chris Wilson Date: Tue Jul 8 10:40:29 2014 +0100 drm/i915: Disable RCS flips on Ivybridge commit 2a92d5bca1999b69c78f3c3e97b5484985b094b9 upstream. We currently see random GPU hangs when using RCS flips with multiple pipes on Ivybridge. Now that we have mmio flips, we can fairly cheaply fallback to using CPU driven flips instead. Signed-off-by: Chris Wilson Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77104 Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 2e7c20830d15cb87350d4d2d3b1eb745c5763f6e Author: Jiri Kosina Date: Thu Aug 7 16:29:53 2014 +0200 drm/i915: read HEAD register back in init_ring_common() to enforce ordering commit ece4a17d237a79f63fbfaf3f724a12b6d500555c upstream. Withtout this, ring initialization fails reliabily during resume with [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head ffffff8804 tail 00000000 start 000e4000 This is not a complete fix, but it is verified to make the ring initialization failures during resume much less likely. We were not able to root-cause this bug (likely HW-specific to Gen4 chips) yet. This is therefore used as a ducttape before problem is fully understood and proper fix created, so that people don't suffer from completely unusable systems in the meantime. The discussion and debugging is happening at https://bugs.freedesktop.org/show_bug.cgi?id=76554 Signed-off-by: Jiri Kosina Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 1fee660a28f88ebf9d999d6d3f2f4559a8b5eb9c Author: Rafael Barbalho Date: Thu Jul 24 15:16:12 2014 +0100 drm/i915: Fix crash when failing to parse MIPI VBT commit ed3b6679936801fa2dab47e7a6ef74e383400ed9 upstream. This particular nasty presented itself while trying to register the intelfb device (intel_fbdev.c). During the process of registering the device the driver will disable the crtc via i9xx_crtc_disable. These will also disable the panel using the generic mipi panel functions in dsi_mod_vbt_generic.c. The stale MIPI generic data sequence pointers would cause a crash within those functions. However, all of this is happening while console_lock is held from do_register_framebuffer inside fbcon.c. Which means that you got kernel log and just the device appearing to reboot/hang for no apparent reason. The fault started from the FB_EVENT_FB_REGISTERED event using the fb_notifier_call_chain call in fbcon.c. This regression has been introduced in commit d3b542fcfc72d7724585e3fd2c5e75351bc3df47 Author: Shobhit Kumar Date: Mon Apr 14 11:00:34 2014 +0530 drm/i915: Add parsing support for new MIPI blocks in VBT Cc: Shobhit Kumar Signed-off-by: Rafael Barbalho Reviewed-by: Shobhit Kumar [danvet: Add regression citation.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit af372afef3b8fb41b17c926f4b85de678ad97591 Author: Alex Deucher Date: Fri Aug 1 20:05:30 2014 +0200 drm/radeon: tweak ACCEL_WORKING2 query for hawaii commit 3c64bd26f7e9bd589ebe0d1ebec69ef2f784c12d upstream. Return 2 so we can be sure the kernel has the necessary changes for acceleration to work. Note: This patch depends on these two commits: - drm/radeon: fix cut and paste issue for hawaii. - drm/radeon: use packet2 for nop on hawaii with old firmware Signed-off-by: Alex Deucher Signed-off-by: Andreas Boll Signed-off-by: Greg Kroah-Hartman commit d528dcb9cac01b5ced231134e1efc7e88b4d9b20 Author: Alex Deucher Date: Thu Jul 31 17:57:42 2014 -0400 drm/radeon/atom: add new voltage fetch function for hawaii commit e9f274b2a1bd4ecc569b823b1e7942e9bf92593e upstream. Some hawaii boards use a different method for fetching the voltage information from the vbios. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 2c578f49f19bf59f608a838699c96d0833a32ab1 Author: Christian König Date: Wed Jul 30 17:18:12 2014 +0200 drm/radeon: set VM base addr using the PFP v2 commit f1d2a26b506e9dc7bbe94fae40da0a0d8dcfacd0 upstream. Seems to make VM flushes more stable on SI and CIK. v2: only use the PFP on the GFX ring on CIK Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit f382c2026413f51be6e4f07de16a2ace50a46021 Author: Alex Deucher Date: Sun Jul 27 23:21:50 2014 -0400 drm/radeon: load the lm63 driver for an lm64 thermal chip. commit 5dc355325b648dc9b4cf3bea4d968de46fd59215 upstream. Looks like the lm63 driver supports the lm64 as well. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b47f2102b4862f881c25b3c5e14f179e54413089 Author: Alex Deucher Date: Mon Jul 14 12:01:40 2014 -0400 drm/radeon: re-enable dpm by default on BTC commit c08abf11900e19b14dd3a0cc3d105bd74519cd18 upstream. This patch depends on: e07929810f0a19ddd756558290c7d72827cbfcd9 (drm/radeon/dpm: fix typo in vddci setup for eg/btc) bugs: https://bugs.freedesktop.org/show_bug.cgi?id=73053 https://bugzilla.kernel.org/show_bug.cgi?id=68571 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 79213a332d66e432f8d75897610195dc7cfa4017 Author: Alex Deucher Date: Mon Jul 7 17:13:37 2014 -0400 drm/radeon: re-enable dpm by default on cayman commit 8f500af4efe347d1a8ac674d115220e8caa84559 upstream. This patch depends on: b0880e87c1fd038b84498944f52e52c3e86ebe59 (drm/radeon/dpm: fix vddci setup typo on cayman) bug: https://bugs.freedesktop.org/show_bug.cgi?id=69723 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 88086e07b486d432d5047d12d60f75148c1efeff Author: Alex Deucher Date: Thu Jul 31 18:07:17 2014 -0400 drm/radeon/dpm: handle voltage info fetching on hawaii commit 6b57f20cb5b708415fbab63847f8f8429b051af8 upstream. Some hawaii cards use a different method to fetch the voltage info from the vbios. bug: https://bugs.freedesktop.org/show_bug.cgi?id=74250 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit d5a1560b20bff6a1afadd68934617d630732b5d5 Author: Tetsuo Handa Date: Sun Aug 3 20:02:31 2014 +0900 drm/ttm: Pass GFP flags in order to avoid deadlock. commit a91576d7916f6cce76d30303e60e1ac47cf4a76d upstream. Commit 7dc19d5a "drivers: convert shrinkers to new count/scan API" added deadlock warnings that ttm_page_pool_free() and ttm_dma_page_pool_free() are currently doing GFP_KERNEL allocation. But these functions did not get updated to receive gfp_t argument. This patch explicitly passes sc->gfp_mask or GFP_KERNEL to these functions, and removes the deadlock warning. Signed-off-by: Tetsuo Handa Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit bb719e33aac6fefbe2269a2e49bdfaaf498a45c7 Author: Tetsuo Handa Date: Sun Aug 3 20:02:03 2014 +0900 drm/ttm: Fix possible stack overflow by recursive shrinker calls. commit 71336e011d1d2312bcbcaa8fcec7365024f3a95d upstream. While ttm_dma_pool_shrink_scan() tries to take mutex before doing GFP_KERNEL allocation, ttm_pool_shrink_scan() does not do it. This can result in stack overflow if kmalloc() in ttm_page_pool_free() triggered recursion due to memory pressure. shrink_slab() => ttm_pool_shrink_scan() => ttm_page_pool_free() => kmalloc(GFP_KERNEL) => shrink_slab() => ttm_pool_shrink_scan() => ttm_page_pool_free() => kmalloc(GFP_KERNEL) Change ttm_pool_shrink_scan() to do like ttm_dma_pool_shrink_scan() does. Signed-off-by: Tetsuo Handa Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 8ea0ee504d9aed386066d0f4fe06cdcfa20665f9 Author: Tetsuo Handa Date: Sun Aug 3 20:01:10 2014 +0900 drm/ttm: Use mutex_trylock() to avoid deadlock inside shrinker functions. commit 22e71691fd54c637800d10816bbeba9cf132d218 upstream. I can observe that RHEL7 environment stalls with 100% CPU usage when a certain type of memory pressure is given. While the shrinker functions are called by shrink_slab() before the OOM killer is triggered, the stall lasts for many minutes. One of reasons of this stall is that ttm_dma_pool_shrink_count()/ttm_dma_pool_shrink_scan() are called and are blocked at mutex_lock(&_manager->lock). GFP_KERNEL allocation with _manager->lock held causes someone (including kswapd) to deadlock when these functions are called due to memory pressure. This patch changes "mutex_lock();" to "if (!mutex_trylock()) return ...;" in order to avoid deadlock. Signed-off-by: Tetsuo Handa Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit e0793a4efb813430245a21f0fa9a52d7cb574299 Author: Tetsuo Handa Date: Sun Aug 3 20:00:40 2014 +0900 drm/ttm: Choose a pool to shrink correctly in ttm_dma_pool_shrink_scan(). commit 46c2df68f03a236b30808bba361f10900c88d95e upstream. We can use "unsigned int" instead of "atomic_t" by updating start_pool variable under _manager->lock. This patch will make it possible to avoid skipping when choosing a pool to shrink in round-robin style, after next patch changes mutex_lock(_manager->lock) to !mutex_trylock(_manager->lork). Signed-off-by: Tetsuo Handa Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 283cac7ef32a12bc393f6f0f18f06d9965b810a4 Author: Tetsuo Handa Date: Sun Aug 3 19:59:35 2014 +0900 drm/ttm: Fix possible division by 0 in ttm_dma_pool_shrink_scan(). commit 11e504cc705e8ccb06ac93a276e11b5e8fee4d40 upstream. list_empty(&_manager->pools) being false before taking _manager->lock does not guarantee that _manager->npools != 0 after taking _manager->lock because _manager->npools is updated under _manager->lock. Signed-off-by: Tetsuo Handa Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit fc065a4cecb9d4936afc5d1d083c061a56dc37b4 Author: Christian König Date: Thu Jul 3 09:02:23 2014 +0200 drm/ttm: fix handling of TTM_PL_FLAG_TOPDOWN v2 commit e3f202798aaa808e7a38faa8c3a9f0aa93b85cc0 upstream. bo->mem.placement is not initialized when ttm_bo_man_get_node is called, so the flag had no effect at all. v2: change nouveau and vmwgfx as well Signed-off-by: Christian König Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 9489fbcdee23e6e4cd6b835c43fb03f64e150d5e Author: Guido Martínez Date: Tue Jun 17 11:17:09 2014 -0300 drm/tilcdc: fix double kfree commit c9a3ad25eddfdb898114a9d73cdb4c3472d9dfca upstream. display_timings_release calls kfree on the display_timings object passed to it. Calling kfree after it is wrong. SLUB debug showed the following warning: ============================================================================= BUG kmalloc-64 (Tainted: G W ): Object already free ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in of_get_display_timings+0x2c/0x214 age=601 cpu=0 pid=884 __slab_alloc.constprop.79+0x2e0/0x33c kmem_cache_alloc+0xac/0xdc of_get_display_timings+0x2c/0x214 panel_probe+0x7c/0x314 [tilcdc] platform_drv_probe+0x18/0x48 [..snip..] INFO: Freed in panel_destroy+0x18/0x3c [tilcdc] age=0 cpu=0 pid=907 __slab_free+0x34/0x330 panel_destroy+0x18/0x3c [tilcdc] tilcdc_unload+0xd0/0x118 [tilcdc] drm_dev_unregister+0x24/0x98 [..snip..] Signed-off-by: Guido Martínez Tested-by: Darren Etheridge Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit aeb5d9de01102bde4443045397b4b72f52805d13 Author: Guido Martínez Date: Tue Jun 17 11:17:08 2014 -0300 drm/tilcdc: fix release order on exit commit eb565a2bbadc6a5030a6dbe58db1aa52453e7edf upstream. Unregister resources in the correct order on tilcdc_drm_fini, which is the reverse order they were registered during tilcdc_drm_init. This also means unregistering the driver before releasing its resources. Signed-off-by: Guido Martínez Tested-by: Darren Etheridge Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 29d674c44bb15f150f8999fc82af06eae776a14c Author: Guido Martínez Date: Tue Jun 17 11:17:07 2014 -0300 drm/tilcdc: panel: fix leak when unloading the module commit 3a49012224ca9016658a831a327ff6a7fe5bb4f9 upstream. The driver did not unregister the allocated framebuffer, which caused memory leaks (and memory manager WARNs) when unloading. Also, the framebuffer device under /dev still existed after unloading. Add a call to drm_fbdev_cma_fini when unloading the module to prevent both issues. Signed-off-by: Guido Martínez Tested-by: Darren Etheridge Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit c085fc88bf29aa3a5f4ff6712d6f19b2e3eebe74 Author: Guido Martínez Date: Tue Jun 17 11:17:06 2014 -0300 drm/tilcdc: tfp410: fix dangling sysfs connector node commit 16dcbdef404f4e87dab985494381939fe0a2d456 upstream. Add a drm_sysfs_connector_remove call when we destroy the panel to make sure the connector node in sysfs gets deleted. This is required for proper unload and re-load of this driver, otherwise we will get a warning about a duplicate filename in sysfs. Signed-off-by: Guido Martínez Tested-by: Darren Etheridge Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 47b7b0c66ed3dc992b16254d02f2c5a318193392 Author: Guido Martínez Date: Tue Jun 17 11:17:05 2014 -0300 drm/tilcdc: slave: fix dangling sysfs connector node commit daa15b4cd1eee58eb1322062a3320b1dbe5dc96e upstream. Add a drm_sysfs_connector_remove call when we destroy the panel to make sure the connector node in sysfs gets deleted. This is required for proper unload and re-load of this driver as a module. Without this, we would get a warning at re-load time like so: tda998x 0-0070: found TDA19988 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 825 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x54/0x74() sysfs: cannot create duplicate filename '/class/drm/card0-HDMI-A-1' Modules linked in: [..] CPU: 0 PID: 825 Comm: modprobe Not tainted 3.15.0-rc4-00027-g9dcdef4 #82 [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (warn_slowpath_common+0x68/0x88) [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40) [] (warn_slowpath_fmt) from [] (sysfs_warn_dup+0x54/0x74) [] (sysfs_warn_dup) from [] (sysfs_do_create_link_sd.isra.2+0xb0/0xb8) [] (sysfs_do_create_link_sd.isra.2) from [] (device_add+0x338/0x520) [] (device_add) from [] (device_create_groups_vargs+0xa0/0xc4) [] (device_create_groups_vargs) from [] (device_create+0x24/0x2c) [] (device_create) from [] (drm_sysfs_connector_add+0x64/0x204) [] (drm_sysfs_connector_add) from [] (slave_modeset_init+0x120/0x1bc [tilcdc]) [] (slave_modeset_init [tilcdc]) from [] (tilcdc_load+0x214/0x4c0 [tilcdc]) [] (tilcdc_load [tilcdc]) from [] (drm_dev_register+0xa4/0x104) [..snip..] ---[ end trace 4df8d614936ebdee ]--- [drm:drm_sysfs_connector_add] *ERROR* failed to register connector device: -17 Signed-off-by: Guido Martínez Tested-by: Darren Etheridge Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit d402b324568a68db0c1bcde2c1e7c2cca283d4a0 Author: Guido Martínez Date: Tue Jun 17 11:17:04 2014 -0300 drm/tilcdc: panel: fix dangling sysfs connector node commit e396900e649b0af31161634d87fe37076f46c12b upstream. Add a drm_sysfs_connector_remove call when we destroy the panel to make sure the connector node in sysfs gets deleted. This is required for proper unload and re-load of this driver as a module. Without this, we would get a warning at re-load time like so: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 824 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x54/0x74() sysfs: cannot create duplicate filename '/class/drm/card0-LVDS-1' Modules linked in: [...] CPU: 0 PID: 824 Comm: modprobe Not tainted 3.15.0-rc4-00027-g6484f96-dirty #81 [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (warn_slowpath_common+0x68/0x88) [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40) [] (warn_slowpath_fmt) from [] (sysfs_warn_dup+0x54/0x74) [] (sysfs_warn_dup) from [] (sysfs_do_create_link_sd.isra.2+0xb0/0xb8) [] (sysfs_do_create_link_sd.isra.2) from [] (device_add+0x338/0x520) [] (device_add) from [] (device_create_groups_vargs+0xa0/0xc4) [] (device_create_groups_vargs) from [] (device_create+0x24/0x2c) [] (device_create) from [] (drm_sysfs_connector_add+0x64/0x204) [] (drm_sysfs_connector_add) from [] (panel_modeset_init+0xb8/0x134 [tilcdc]) [] (panel_modeset_init [tilcdc]) from [] (tilcdc_load+0x214/0x4c0 [tilcdc]) [] (tilcdc_load [tilcdc]) from [] (drm_dev_register+0xa4/0x104) [ .. snip .. ] ---[ end trace b2d09cd9578b0497 ]--- [drm:drm_sysfs_connector_add] *ERROR* failed to register connector device: -17 Signed-off-by: Guido Martínez Tested-by: Darren Etheridge Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 873d1515bd276968acce4b6df43593d62cb2583d Author: Stephen Warren Date: Wed Jun 18 16:21:55 2014 -0600 drm/tegra: add MODULE_DEVICE_TABLEs commit ef70728c7a6571a1a7115031e932b811f1740b2e upstream. When tegra-drm.ko is built as a module, these MODULE_DEVICE_TABLEs allow the module to be auto-loaded since the module will match the devices instantiated from device tree. (Notes for stable: in 3.14+, just git rm any conflicting file, since they are added in later kernels. For 3.13 and below, manual merging will be needed) Signed-off-by: Stephen Warren Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 2593ca04d8dccb2b78d5756fbe6903959812c456 Author: Ronald Wahl Date: Thu Aug 7 14:15:50 2014 +0200 carl9170: fix sending URBs with wrong type when using full-speed commit 671796dd96b6cd85b75fba9d3007bcf7e5f7c309 upstream. The driver assumes that endpoint 4 is always an interrupt endpoint. Unfortunately the type differs between high-speed and full-speed configurations while in the former case it is indeed an interrupt endpoint this is not true for the latter case - here it is a bulk endpoint. When sending URBs with the wrong type the kernel will generate a warning message including backtrace. In this specific case there will be a huge amount of warnings which can bring the system to freeze. To fix this we are now sending URBs to endpoint 4 using the type found in the endpoint descriptor. A side note: The carl9170 firmware currently specifies endpoint 4 as interrupt endpoint even in the full-speed configuration but this has no relevance because before this firmware is loaded the endpoint type is as described above and after the firmware is running the stick is not reenumerated and so the old descriptor is used. Signed-off-by: Ronald Wahl Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 84d172d64e2985fcc14b261a2b0312eb1ee4aa23 Author: Stephen Boyd Date: Wed Aug 6 22:04:58 2014 +0200 cpufreq: OPP: Avoid sleeping while atomic commit 3c5445ce3a0c6d6935911212b735772af5115517 upstream. We allocate the cpufreq table after calling rcu_read_lock(), which disables preemption. This causes scheduling while atomic warnings. Use GFP_ATOMIC instead of GFP_KERNEL and update for kcalloc while we're here. BUG: sleeping function called from invalid context at mm/slub.c:1246 in_atomic(): 0, irqs_disabled(): 0, pid: 80, name: modprobe 5 locks held by modprobe/80: #0: (&dev->mutex){......}, at: [] __driver_attach+0x48/0x98 #1: (&dev->mutex){......}, at: [] __driver_attach+0x58/0x98 #2: (subsys mutex#5){+.+.+.}, at: [] subsys_interface_register+0x38/0xc8 #3: (cpufreq_rwsem){.+.+.+}, at: [] __cpufreq_add_dev.isra.22+0x84/0x92c #4: (rcu_read_lock){......}, at: [] dev_pm_opp_init_cpufreq_table+0x18/0x10c Preemption disabled at:[< (null)>] (null) CPU: 2 PID: 80 Comm: modprobe Not tainted 3.16.0-rc3-next-20140701-00035-g286857f216aa-dirty #217 [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x70/0xbc) [] (dump_stack) from [] (__kmalloc+0x124/0x250) [] (__kmalloc) from [] (dev_pm_opp_init_cpufreq_table+0x3c/0x10c) [] (dev_pm_opp_init_cpufreq_table) from [] (cpufreq_init+0x48/0x378 [cpufreq_generic]) [] (cpufreq_init [cpufreq_generic]) from [] (__cpufreq_add_dev.isra.22+0x200/0x92c) [] (__cpufreq_add_dev.isra.22) from [] (subsys_interface_register+0x84/0xc8) [] (subsys_interface_register) from [] (cpufreq_register_driver+0x108/0x2d8) [] (cpufreq_register_driver) from [] (generic_cpufreq_probe+0x50/0x74 [cpufreq_generic]) [] (generic_cpufreq_probe [cpufreq_generic]) from [] (platform_drv_probe+0x18/0x48) [] (platform_drv_probe) from [] (driver_probe_device+0x128/0x370) [] (driver_probe_device) from [] (__driver_attach+0x94/0x98) [] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88) [] (bus_for_each_dev) from [] (bus_add_driver+0xe8/0x204) [] (bus_add_driver) from [] (driver_register+0x78/0xf4) [] (driver_register) from [] (do_one_initcall+0xac/0x1d8) [] (do_one_initcall) from [] (load_module+0x190c/0x21e8) [] (load_module) from [] (SyS_init_module+0xa4/0x110) [] (SyS_init_module) from [] (ret_fast_syscall+0x0/0x48) Fixes: a0dd7b79657b (PM / OPP: Move cpufreq specific OPP functions out of generic OPP library) Signed-off-by: Stephen Boyd Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 61618f301d1103cc565b4b775da3400334605c69 Author: Andy Lutomirski Date: Sat Aug 16 04:13:37 2014 +0930 module: Clean up ro/nx after early module load failures commit ff7e0055bb5ddbbb320cdd8dfd3e18672bddd2ad upstream. The commit 4982223e51e8 module: set nx before marking module MODULE_STATE_COMING. introduced a regression: if a module fails to parse its arguments or if mod_sysfs_setup fails, then the module's memory will be freed while still read-only. Anything that reuses that memory will crash as soon as it tries to write to it. Cc: Rusty Russell Signed-off-by: Andy Lutomirski Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman