commit a96a03027376264942cc8bfdff864e5a579d7ca7 Author: Greg Kroah-Hartman Date: Sun Apr 19 10:11:24 2015 +0200 Linux 3.19.5 commit 002d8e07776222e55d82a22767afbcc021913815 Author: Igor Mammedov Date: Fri Mar 20 12:21:37 2015 +0000 kvm: avoid page allocation failure in kvm_set_memory_region() commit 744961341d472db6272ed9b42319a90f5a2aa7c4 upstream. KVM guest can fail to startup with following trace on host: qemu-system-x86: page allocation failure: order:4, mode:0x40d0 Call Trace: dump_stack+0x47/0x67 warn_alloc_failed+0xee/0x150 __alloc_pages_direct_compact+0x14a/0x150 __alloc_pages_nodemask+0x776/0xb80 alloc_kmem_pages+0x3a/0x110 kmalloc_order+0x13/0x50 kmemdup+0x1b/0x40 __kvm_set_memory_region+0x24a/0x9f0 [kvm] kvm_set_ioapic+0x130/0x130 [kvm] kvm_set_memory_region+0x21/0x40 [kvm] kvm_vm_ioctl+0x43f/0x750 [kvm] Failure happens when attempting to allocate pages for 'struct kvm_memslots', however it doesn't have to be present in physically contiguous (kmalloc-ed) address space, change allocation to kvm_kvzalloc() so that it will be vmalloc-ed when its size is more then a page. Signed-off-by: Igor Mammedov Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit d5d51dd4db1cc56b72266651c5c37b31088fe862 Author: Daniel Vetter Date: Wed Jan 7 13:54:39 2015 +0100 drm/i915: Push vblank enable/disable past encoder->enable/disable commit f9b61ff6bce9a44555324b29e593fdffc9a115bc upstream. It is platform/output depenedent when exactly the pipe will start running. Sometimes we just need the (cpu) pipe enabled, in other cases the pch transcoder is enough and in yet other cases the (DP) port is sending the frame start signal. In a perfect world we'd put the drm_crtc_vblank_on call exactly where the pipe starts running, but due to cloning and similar things this will get messy. And the current approach of picking the most conservative place for all combinations also doesn't work since that results in legit vblank waits (in encoder->enable hooks, e.g. the 2 vblank waits for sdvo) failing. Completely going back to the old world before commit 51e31d49c89055299e34b8f44d13f70e19aaaad1 Author: Daniel Vetter Date: Mon Sep 15 12:36:02 2014 +0200 drm/i915: Use generic vblank wait isn't great either since screaming when the vblank wait work because the pipe is off is kinda nice. Pick a compromise and move the drm_crtc_vblank_on right before the encoder->enable call. This is a lie on some outputs/platforms, but after the ->enable callback the pipe is guaranteed to run everywhere. So not that bad really. Suggested by Ville. v2: Same treatment for drm_crtc_vblank_off and encoder->disable: I've missed the ibx pipe B select w/a, which also has a vblank wait in the disable function (while the pipe is obviously still running). Cc: Ville Syrjälä Cc: Chris Wilson Acked-by: Ville Syrjälä Signed-off-by: Daniel Vetter Cc: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 363d91b062de645799924f542ec6d9bf7a32e302 Author: Dave Chinner Date: Mon Feb 23 22:37:08 2015 +1100 xfs: ensure truncate forces zeroed blocks to disk commit 5885ebda878b47c4b4602d4b0410cb4b282af024 upstream. A new fsync vs power fail test in xfstests indicated that XFS can have unreliable data consistency when doing extending truncates that require block zeroing. The blocks beyond EOF get zeroed in memory, but we never force those changes to disk before we run the transaction that extends the file size and exposes those blocks to userspace. This can result in the blocks not being correctly zeroed after a crash. Because in-memory behaviour is correct, tools like fsx don't pick up any coherency problems - it's not until the filesystem is shutdown or the system crashes after writing the truncate transaction to the journal but before the zeroed data in the page cache is flushed that the issue is exposed. Fix this by also flushing the dirty data in memory region between the old size and new size when we've found blocks that need zeroing in the truncate process. Reported-by: Liu Bo Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit db8a9ac5f02d100f1a4a81bf6d9864f51a6c78f2 Author: Omar Sandoval Date: Sat Feb 14 20:08:51 2015 -0500 ext4: fix indirect punch hole corruption commit 6f30b7e37a8239f9d27db626a1d3427bc7951908 upstream. Commit 4f579ae7de56 (ext4: fix punch hole on files with indirect mapping) rewrote FALLOC_FL_PUNCH_HOLE for ext4 files with indirect mapping. However, there are bugs in several corner cases. This fixes 5 distinct bugs: 1. When there is at least one entire level of indirection between the start and end of the punch range and the end of the punch range is the first block of its level, we can't return early; we have to free the intervening levels. 2. When the end is at a higher level of indirection than the start and ext4_find_shared returns a top branch for the end, we still need to free the rest of the shared branch it returns; we can't decrement partial2. 3. When a punch happens within one level of indirection, we need to converge on an indirect block that contains the start and end. However, because the branches returned from ext4_find_shared do not necessarily start at the same level (e.g., the partial2 chain will be shallower if the last block occurs at the beginning of an indirect group), the walk of the two chains can end up "missing" each other and freeing a bunch of extra blocks in the process. This mismatch can be handled by first making sure that the chains are at the same level, then walking them together until they converge. 4. When the punch happens within one level of indirection and ext4_find_shared returns a top branch for the start, we must free it, but only if the end does not occur within that branch. 5. When the punch happens within one level of indirection and ext4_find_shared returns a top branch for the end, then we shouldn't free the block referenced by the end of the returned chain (this mirrors the different levels case). Signed-off-by: Omar Sandoval Cc: Chris J Arges Signed-off-by: Greg Kroah-Hartman commit 1a6fe5b612b4f9a18f87b6c2c9e4ee51731caf25 Author: Preeti U Murthy Date: Wed Mar 18 16:19:27 2015 +0530 timers/tick/broadcast-hrtimer: Fix suspicious RCU usage in idle loop commit a127d2bcf1fbc8c8e0b5cf0dab54f7d3ff50ce47 upstream. The hrtimer mode of broadcast queues hrtimers in the idle entry path so as to wakeup cpus in deep idle states. The associated call graph is : cpuidle_idle_call() |____ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, ....)) |_____tick_broadcast_set_event() |____clockevents_program_event() |____bc_set_next() The hrtimer_{start/cancel} functions call into tracing which uses RCU. But it is not legal to call into RCU in cpuidle because it is one of the quiescent states. Hence protect this region with RCU_NONIDLE which informs RCU that the cpu is momentarily non-idle. As an aside it is helpful to point out that the clock event device that is programmed here is not a per-cpu clock device; it is a pseudo clock device, used by the broadcast framework alone. The per-cpu clock device programming never goes through bc_set_next(). Signed-off-by: Preeti U Murthy Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Paul E. McKenney Cc: linuxppc-dev@ozlabs.org Cc: mpe@ellerman.id.au Cc: tglx@linutronix.de Link: http://lkml.kernel.org/r/20150318104705.17763.56668.stgit@preeti.in.ibm.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 6531f38ef9b30acf4c4414da5b2af24a6578e275 Author: Majd Dibbiny Date: Wed Mar 18 16:51:37 2015 +0200 IB/mlx4: Saturate RoCE port PMA counters in case of overflow commit 61a3855bb726cbb062ef02a31a832dea455456e0 upstream. For RoCE ports, we set the u32 PMA values based on u64 HCA counters. In case of overflow, according to the IB spec, we have to saturate a counter to its max value, do that. Fixes: c37791349cc7 ('IB/mlx4: Support PMA counters for IBoE') Signed-off-by: Majd Dibbiny Signed-off-by: Eran Ben Elisha Signed-off-by: Hadar Hen Zion Signed-off-by: Or Gerlitz Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 033dc8f0116892553d4e2561cddf92c089c71e22 Author: Uwe Kleine-König Date: Sat Feb 21 11:40:23 2015 +0100 clk: divider: fix calculation of maximal parent rate for a given divider commit da321133b53caf7889ed3ca1dabe4cc368db2604 upstream. The rate provided at the output of a clk-divider is calculated as: DIV_ROUND_UP(parent_rate, div) since commit b11d282dbea2 (clk: divider: fix rate calculation for fractional rates). So to yield a rate not bigger than r parent_rate must be <= r * div. The effect of choosing a parent rate that is too big as was done before this patch results in wrongly ruling out good dividers. Note that this is not a complete fix as __clk_round_rate might return a value >= its 2nd parameter. Also for dividers with CLK_DIVIDER_ROUND_CLOSEST set the calculation is not accurate. But this fixes the test case by Sascha Hauer that uses a chain of three dividers under a fixed clock. Fixes: b11d282dbea2 (clk: divider: fix rate calculation for fractional rates) Suggested-by: Sascha Hauer Signed-off-by: Uwe Kleine-König Acked-by: Sascha Hauer Signed-off-by: Michael Turquette Signed-off-by: Greg Kroah-Hartman commit 765c20456c868989e179b14640ebe65347f2f57a Author: Uwe Kleine-König Date: Sat Feb 21 11:40:24 2015 +0100 clk: divider: fix selection of divider when rounding to closest commit 26bac95aa88c2b1747808c0b885abe7814c0165d upstream. It's an invalid approach to assume that among two divider values the one nearer the exact divider is the better one. Assume a parent rate of 1000 Hz, a divider with CLK_DIVIDER_POWER_OF_TWO and a target rate of 89 Hz. The exact divider is ~ 11.236 so 8 and 16 are the candidates to choose from yielding rates 125 Hz and 62.5 Hz respectivly. While 8 is nearer to 11.236 than 16 is, the latter is still the better divider as 62.5 is nearer to 89 than 125 is. Fixes: 774b514390b1 (clk: divider: Add round to closest divider) Signed-off-by: Uwe Kleine-König Acked-by: Sascha Hauer Acked-by: Maxime Coquelin Signed-off-by: Michael Turquette Signed-off-by: Greg Kroah-Hartman commit 4858bcfdbcddd3e319f7621bb8044ebec2bacbeb Author: Hans Verkuil Date: Mon Feb 16 07:49:07 2015 -0300 vb2: fix 'UNBALANCED' warnings when calling vb2_thread_stop() commit 0e661006370b7e7fb9ac9d94f9c3500a62cd559b upstream. Stopping the vb2 thread (as used by several DVB devices) can result in an 'UNBALANCED' warning such as this: vb2: counters for queue ffff880407ee9828: UNBALANCED! vb2: setup: 1 start_streaming: 1 stop_streaming: 1 vb2: wait_prepare: 249333 wait_finish: 249334 This is due to a race condition between stopping the thread and calling vb2_internal_streamoff(). While I have not been able to deduce the exact mechanism how this race condition can produce this warning, I can see that the way the stream is stopped is likely to lead to a race somewhere. This patch simplifies how this is done by first ensuring that the thread is completely stopped before cleaning up the vb2 queue. It does that by setting threadio->stop to true, followed by a call to vb2_queue_error() which will wake up the thread. The thread sees that 'stop' is true and it will exit. The call to kthread_stop() waits until the thread has exited, and only then is the queue cleaned up by calling __vb2_cleanup_fileio(). This is a much cleaner sequence and the warning has now disappeared. Reported-by: Jurgen Kramer Tested-by: Jurgen Kramer Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 52c681ce5ea8a05624957824601a2eaa97125132 Author: Sakari Ailus Date: Fri Feb 13 04:42:37 2015 -0300 vb2: Fix dma_dir setting for dma-contig mem type commit 4879785ed511083676f27a016c9ad6c46c8e5737 upstream. The last argument of vb2_dc_get_user_pages() is of type enum dma_data_direction, but the caller, vb2_dc_get_userptr() passes a value which is the result of comparison dma_dir == DMA_FROM_DEVICE. This results in the write parameter to get_user_pages() being zero in all cases, i.e. that the caller has no intent to write there. This was broken by patch "vb2: replace 'write' by 'dma_dir'". Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 2a9a83923e969f02f1ac96e66728a32295596e75 Author: Geert Uytterhoeven Date: Thu Feb 19 06:47:16 2015 -0300 soc-camera: Fix devm_kfree() in soc_of_bind() commit 8e48a2d54c5d74ea3e9dc4c3b9037786bb447f36 upstream. Unlike scan_async_group(), soc_of_bind() doesn't allocate its soc_camera_async_client structure using devm_kzalloc(), but has it embedded inside the soc_of_info structure. Hence on failure, it must free the whole soc_of_info structure, and not just the embedded soc_camera_async_client structure, as the latter causes a warning, and may cause slab corruption: soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at drivers/base/devres.c:887 devm_kfree+0x30/0x40() CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-shmobile-08386-g37feb0d093cb2d8e #128 Hardware name: Generic R8A7791 (Flattened Device Tree) Backtrace: [] (dump_backtrace) from [] (show_stack+0x18/0x1c) r6:c05a923b r5:00000009 r4:00000000 r3:00204140 [] (show_stack) from [] (dump_stack+0x78/0x94) [] (dump_stack) from [] (warn_slowpath_common+0x8c/0xb8) r4:00000000 r3:00000000 [] (warn_slowpath_common) from [] (warn_slowpath_null+0x24/0x2c) r8:ee7d8214 r7:ed83b810 r6:ed83bc20 r5:fffffffa r4:ed83e510 [] (warn_slowpath_null) from [] (devm_kfree+0x30/0x40) [] (devm_kfree) from [] (soc_of_bind.isra.14+0x194/0x1d4) [] (soc_of_bind.isra.14) from [] (soc_camera_host_register+0x208/0x31c) r9:00000070 r8:ee7e05d0 r7:ee153210 r6:00000000 r5:ee7e0218 r4:ed83bc20 [] (soc_camera_host_register) from [] (rcar_vin_probe+0x1f4/0x238) r8:ee153200 r7:00000008 r6:ee153210 r5:ed83bc10 r4:c066319c r3:000000c0 [] (rcar_vin_probe) from [] (platform_drv_probe+0x50/0xa0) r10:00000000 r9:c0662fa8 r8:00000000 r7:c06a3700 r6:c0662fa8 r5:ee153210 r4:00000000 [] (platform_drv_probe) from [] (driver_probe_device+0xc4/0x208) r6:c06a36f4 r5:00000000 r4:ee153210 r3:c025c2e4 [] (driver_probe_device) from [] (__driver_attach+0x70/0x94) r9:c066f9c0 r8:c0624a98 r7:c065b790 r6:c0662fa8 r5:ee153244 r4:ee153210 [] (__driver_attach) from [] (bus_for_each_dev+0x74/0x98) r6:c025b098 r5:c0662fa8 r4:00000000 r3:00000001 [] (bus_for_each_dev) from [] (driver_attach+0x20/0x28) r6:ed83c200 r5:00000000 r4:c0662fa8 [] (driver_attach) from [] (bus_add_driver+0xdc/0x1c4) [] (bus_add_driver) from [] (driver_register+0xa4/0xe8) r7:c0624a98 r6:00000000 r5:c060b010 r4:c0662fa8 [] (driver_register) from [] (__platform_driver_register+0x50/0x64) r5:c060b010 r4:ed8394c0 [] (__platform_driver_register) from [] (rcar_vin_driver_init+0x18/0x20) [] (rcar_vin_driver_init) from [] (do_one_initcall+0x108/0x1b8) [] (do_one_initcall) from [] (kernel_init_freeable+0x11c/0x1e4) r9:c066f9c0 r8:c066f9c0 r7:c062eab0 r6:c06252c4 r5:000000ad r4:00000006 [] (kernel_init_freeable) from [] (kernel_init+0x10/0xec) r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c048c3c0 r4:00000000 [] (kernel_init) from [] (ret_from_fork+0x14/0x34) r4:00000000 r3:ee04e000 ---[ end trace e3a984cc0335c8a0 ]--- rcar_vin e6ef1000.video: group probe failed: -6 Fixes: 1ddc6a6caa94e1e1 ("[media] soc_camera: add support for dt binding soc_camera drivers") Signed-off-by: Geert Uytterhoeven Signed-off-by: Guennadi Liakhovetski Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 5ddff4d7c66c6a72ef745ea3c47a7ea79ff59741 Author: Hans Verkuil Date: Sun Mar 8 23:20:03 2015 -0800 cx23885: fix querycap commit 6b46211f0a3b18b2360275ac29c4d6bfdf7bc015 upstream. cap->device_caps wasn't set in cx23885-417.c causing a warning from the v4l2-core. Reported-by: Joseph Jasi Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit c80fa6bc02c20b574c6c2eba2996546f19fa69e1 Author: Marek Szyprowski Date: Wed Mar 4 05:55:21 2015 -0800 media: s5p-mfc: fix mmap support for 64bit arch commit 05b676ab42f624425d5f6519276e506b812fa058 upstream. TASK_SIZE is depends on the systems architecture (32 or 64 bits) and it should not be used for defining offset boundary for mmaping buffers for CAPTURE and OUTPUT queues. This patch fixes support for MMAP calls on the CAPTURE queue on 64bit architectures (like ARM64). Signed-off-by: Marek Szyprowski Signed-off-by: Kamil Debski Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 8d73f6706ae41206eb23a6c50df324a58d1d4032 Author: Hans Verkuil Date: Wed Dec 10 12:35:34 2014 -0300 sh_veu: v4l2_dev wasn't set commit ab3120300be067a2d41a027c41db0b2c662ab200 upstream. The v4l2_dev field of struct video_device must be set correctly. This was never done for this driver, so no video nodes were created anymore. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit cb32abbc39b14b4c18badf5bcd968a4f497fe762 Author: Mike Christie Date: Fri Apr 10 02:47:27 2015 -0500 iscsi target: fix oops when adding reject pdu commit b815fc12d4dd2b5586184fb4f867caff05a810d4 upstream. This fixes a oops due to a double list add when adding a reject PDU for iscsit_allocate_iovecs allocation failures. The cmd has already been added to the conn_cmd_list in iscsit_setup_scsi_cmd, so this has us call iscsit_reject_cmd. Note that for ERL0 the reject PDU is not actually sent, so this patch is not completely tested. Just verified we do not oops. The problem is the add reject functions return -1 which is returned all the way up to iscsi_target_rx_thread which for ERL0 will drop the connection. Signed-off-by: Mike Christie Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 2cdb954e809a33c13ecb54bf56bee1df30e368f2 Author: Al Viro Date: Mon Apr 6 17:57:44 2015 -0400 ioctx_alloc(): fix vma (and file) leak on failure commit deeb8525f9bcea60f5e86521880c1161de7a5829 upstream. If we fail past the aio_setup_ring(), we need to destroy the mapping. We don't need to care about anybody having found ctx, or added requests to it, since the last failure exit is exactly the failure to make ctx visible to lookups. Reproducer (based on one by Joe Mario ): void count(char *p) { char s[80]; printf("%s: ", p); fflush(stdout); sprintf(s, "/bin/cat /proc/%d/maps|/bin/fgrep -c '/[aio] (deleted)'", getpid()); system(s); } int main() { io_context_t *ctx; int created, limit, i, destroyed; FILE *f; count("before"); if ((f = fopen("/proc/sys/fs/aio-max-nr", "r")) == NULL) perror("opening aio-max-nr"); else if (fscanf(f, "%d", &limit) != 1) fprintf(stderr, "can't parse aio-max-nr\n"); else if ((ctx = calloc(limit, sizeof(io_context_t))) == NULL) perror("allocating aio_context_t array"); else { for (i = 0, created = 0; i < limit; i++) { if (io_setup(1000, ctx + created) == 0) created++; } for (i = 0, destroyed = 0; i < created; i++) if (io_destroy(ctx[i]) == 0) destroyed++; printf("created %d, failed %d, destroyed %d\n", created, limit - created, destroyed); count("after"); } } Found-by: Joe Mario Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit a48078e17aecef5498ba9b61e7354ea0035ac280 Author: Al Viro Date: Wed Apr 8 17:00:32 2015 -0400 ocfs2: _really_ sync the right range commit 64b4e2526d1cf6e6a4db6213d6e2b6e6ab59479a upstream. "ocfs2 syncs the wrong range" had been broken; prior to it the code was doing the wrong thing in case of O_APPEND, all right, but _after_ it we were syncing the wrong range in 100% cases. *ppos, aka iocb->ki_pos is incremented prior to that point, so we are always doing sync on the area _after_ the one we'd written to. Spotted by Joseph Qi back in January; unfortunately, I'd missed his mail back then ;-/ Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 3a79627f0ee10b314e39cf1040a53971adebfa21 Author: John Soni Jose Date: Thu Feb 12 06:45:47 2015 +0530 be2iscsi: Fix kernel panic when device initialization fails commit 2e7cee027b26cbe7e6685a7a14bd2850bfe55d33 upstream. Kernel panic was happening as iscsi_host_remove() was called on a host which was not yet added. Signed-off-by: John Soni Jose Reviewed-by: Mike Christie Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit fe4d073fcb5b399b8ed415be8a1a9ae93d52b19b Author: Ilya Dryomov Date: Thu Apr 2 14:40:58 2015 +0300 Revert "libceph: use memalloc flags for net IO" commit 6d7fdb0ab351b33d4c12d53fe44be030b90fc9d4 upstream. This reverts commit 89baaa570ab0b476db09408d209578cfed700e9f. Dirty page throttling should be sufficient for us in the general case so there is no need to use __GFP_MEMALLOC - it would be needed only in the swap-over-rbd case, which we currently don't support. (It would probably take approximately the commit that is being reverted to add that support, but we would also need the "swap" option to distinguish from the general case and make sure swap ceph_client-s aren't shared with anything else.) See ceph-devel threads [1] and [2] for the details of why enabling pfmemalloc reserves for all cases is a bad thing. On top of potential system lockups related to drained emergency reserves, this turned out to cause ceph lockups in case peers are on the same host and communicating via loopback due to sk_filter() dropping pfmemalloc skbs on the receiving side because the receiving loopback socket is not tagged with SOCK_MEMALLOC. [1] "SOCK_MEMALLOC vs loopback" http://www.spinics.net/lists/ceph-devel/msg22998.html [2] "[PATCH] libceph: don't set memalloc flags in loopback case" http://www.spinics.net/lists/ceph-devel/msg23392.html Conflicts: net/ceph/messenger.c [ context: tcp_nodelay option ] Cc: Mike Christie Cc: Mel Gorman Cc: Sage Weil Signed-off-by: Ilya Dryomov Acked-by: Mike Christie Acked-by: Mel Gorman Signed-off-by: Greg Kroah-Hartman commit eced8033ad208ef95172aa095373819c3a36ca2d Author: Rafael J. Wysocki Date: Tue Apr 7 01:07:39 2015 +0200 Revert "PM / hibernate: avoid unsafe pages in e820 reserved regions" commit f82daee49c09cf6a99c28303d93438a2566e5552 upstream. Commit 84c91b7ae07c (PM / hibernate: avoid unsafe pages in e820 reserved regions) is reported to make resume from hibernation on Lenovo x230 unreliable, so revert it. We will revisit the issue the commit in question was supposed to fix in the future. Link: https://bugzilla.kernel.org/show_bug.cgi?id=96111 Reported-by: rhn Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit bd2c28533d7a9245c4ac5d48fe098a20a31160af Author: Benjamin Herrenschmidt Date: Mon Mar 23 14:16:38 2015 +1100 drivers/of: Add empty ranges quirk for PA-Semi commit 41d9489319f28f06cf51731131bc353d5a6bce59 upstream. The "sdc" node is missing the ranges property, it needs to be treated as having an empty one otherwise translation fails for its children. Fixes 746c9e9f92dd, "of/base: Fix PowerPC address parsing hack" Tested-by: Steven Rostedt Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Grant Likely Signed-off-by: Greg Kroah-Hartman commit b943e69d33fac1e5f6db57868e061096b0aae67a Author: Larry Finger Date: Sat Mar 21 15:16:05 2015 -0500 rtlwifi: Fix IOMMU mapping leak in AP mode commit be0b5e635883678bfbc695889772fed545f3427d upstream. Transmission of an AP beacon does not call the TX interrupt service routine, which usually does the cleanup. Instead, cleanup is handled in a tasklet completion routine. Unfortunately, this routine has a serious bug in that it does not release the DMA mapping before it frees the skb, thus one IOMMU mapping is leaked for each beacon. The test system failed with no free IOMMU mapping slots approximately one hour after hostapd was used to start an AP. This issue was reported and tested at https://github.com/lwfinger/rtlwifi_new/issues/30. Reported-and-tested-by: Kevin Mullican Cc: Kevin Mullican Signed-off-by: Shao Fu Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 60a3b5963a35c17951be477e954652d03c33652e Author: Alex Williamson Date: Wed Mar 4 11:30:10 2015 -0700 iommu/vt-d: Detach domain *only* from attached iommus commit 71684406905f98f86a85e008b51f5c4c5d83af5a upstream. Device domains never span IOMMU hardware units, which allows the domain ID space for each IOMMU to be an independent address space. Therefore we can have multiple, independent domains, each with the same domain->id, but attached to different hardware units. This is also why we need to do a heavy-weight search for VM domains since they can span multiple IOMMUs hardware units and we don't require a single global ID to use for all hardware units. Therefore, if we call iommu_detach_domain() across all active IOMMU hardware units for a non-VM domain, the result is that we clear domain IDs that are not associated with our domain, allowing them to be re-allocated and causing apparent coherency issues when the device cannot access IOVAs for the intended domain. This bug was introduced in commit fb170fb4c548 ("iommu/vt-d: Introduce helper functions to make code symmetric for readability"), but is significantly exacerbated by the more recent commit 62c22167dd70 ("iommu/vt-d: Fix dmar_domain leak in iommu_attach_device") which calls domain_exit() more frequently to resolve a domain leak. Fixes: fb170fb4c548 ("iommu/vt-d: Introduce helper functions to make code symmetric for readability") Signed-off-by: Alex Williamson Cc: Jiang Liu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 5557ec07d2e7f2475dba2d5b27d833a22801d878 Author: Arend van Spriel Date: Fri Mar 20 22:18:17 2015 +0100 brcmfmac: disable MBSS feature for BCM43362 commit f93a25b38cbd840f26c9fd2dd8a6611a57b259b7 upstream. The BCM43362 firmware falsely reports it is capable of providing MBSS. As a result AP mode no longer works for this device. Therefor disable MBSS in the driver for this chipset. Reported-by: Jorg Krause Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Signed-off-by: Arend van Spriel Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit ef812a8a36113b01b7578479773b0f6c76e119b7 Author: David Disseldorp Date: Fri Mar 13 14:20:29 2015 +0100 cifs: fix use-after-free bug in find_writable_file commit e1e9bda22d7ddf88515e8fe401887e313922823e upstream. Under intermittent network outages, find_writable_file() is susceptible to the following race condition, which results in a user-after-free in the cifs_writepages code-path: Thread 1 Thread 2 ======== ======== inv_file = NULL refind = 0 spin_lock(&cifs_file_list_lock) // invalidHandle found on openFileList inv_file = open_file // inv_file->count currently 1 cifsFileInfo_get(inv_file) // inv_file->count = 2 spin_unlock(&cifs_file_list_lock); cifs_reopen_file() cifs_close() // fails (rc != 0) ->cifsFileInfo_put() spin_lock(&cifs_file_list_lock) // inv_file->count = 1 spin_unlock(&cifs_file_list_lock) spin_lock(&cifs_file_list_lock); list_move_tail(&inv_file->flist, &cifs_inode->openFileList); spin_unlock(&cifs_file_list_lock); cifsFileInfo_put(inv_file); ->spin_lock(&cifs_file_list_lock) // inv_file->count = 0 list_del(&cifs_file->flist); // cleanup!! kfree(cifs_file); spin_unlock(&cifs_file_list_lock); spin_lock(&cifs_file_list_lock); ++refind; // refind = 1 goto refind_writable; At this point we loop back through with an invalid inv_file pointer and a refind value of 1. On second pass, inv_file is not overwritten on openFileList traversal, and is subsequently dereferenced. Signed-off-by: David Disseldorp Reviewed-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 7d57ccdfa65f6aa47b8f9a987869978d13ce2ff4 Author: Sachin Prabhu Date: Wed Feb 4 13:10:26 2015 +0000 cifs: smb2_clone_range() - exit on unhandled error commit 2477bc58d49edb1c0baf59df7dc093dce682af2b upstream. While attempting to clone a file on a samba server, we receive a STATUS_INVALID_DEVICE_REQUEST. This is mapped to -EOPNOTSUPP which isn't handled in smb2_clone_range(). We end up looping in the while loop making same call to the samba server over and over again. The proposed fix is to exit and return the error value when encountered with an unhandled error. Signed-off-by: Sachin Prabhu Signed-off-by: Steve French Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit b1ff43a8757d7a57b49231db1713c5ec36477bdf Author: Peter Hurley Date: Fri Jan 16 15:05:39 2015 -0500 n_tty: Fix read buffer overwrite when no newline commit fb5ef9e7da39968fec6d6f37f20a23d23740c75e upstream. In canon mode, the read buffer head will advance over the buffer tail if the input > 4095 bytes without receiving a line termination char. Discard additional input until a line termination is received. Before evaluating for overflow, the 'room' value is normalized for I_PARMRK and 1 byte is reserved for line termination (even in !icanon mode, in case the mode is switched). The following table shows the transform: actual buffer | 'room' value before overflow calc space avail | !I_PARMRK | I_PARMRK -------------------------------------------------- 0 | -1 | -1 1 | 0 | 0 2 | 1 | 0 3 | 2 | 0 4+ | 3 | 1 When !icanon or when icanon and the read buffer contains newlines, normalized 'room' values of -1 and 0 are clamped to 0, and 'overflow' is 0, so read_head is not adjusted and the input i/o loop exits (setting no_room if called from flush_to_ldisc()). No input is discarded since the reader does have input available to read which ensures forward progress. When icanon and the read buffer does not contain newlines and the normalized 'room' value is 0, then overflow and room are reset to 1, so that the i/o loop will process the next input char normally (except for parity errors which are ignored). Thus, erasures, signalling chars, 7-bit mode, etc. will continue to be handled properly. If the input char processed was not a line termination char, then the canon_head index will not have advanced, so the normalized 'room' value will now be -1 and 'overflow' will be set, which indicates the read_head can safely be reset, effectively erasing the last char processed. If the input char processed was a line termination, then the canon_head index will have advanced, so 'overflow' is cleared to 0, the read_head is not reset, and 'room' is cleared to 0, which exits the i/o loop (because the reader now have input available to read which ensures forward progress). Note that it is possible for a line termination to be received, and for the reader to copy the line to the user buffer before the input i/o loop is ready to process the next input char. This is why the i/o loop recomputes the room/overflow state with every input char while handling overflow. Finally, if the input data was processed without receiving a line termination (so that overflow is still set), the pty driver must receive a write wakeup. A pty writer may be waiting to write more data in n_tty_write() but without unthrottling here that wakeup will not arrive, and forward progress will halt. (Normally, the pty writer is woken when the reader reads data out of the buffer and more space become available). Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman (backported from commit fb5ef9e7da39968fec6d6f37f20a23d23740c75e) Signed-off-by: Joseph Salisbury commit 63d7ff2248f302e4b600f72fcbec93318e7fb71b Author: Stefan Agner Date: Fri Mar 13 14:51:51 2015 +0100 tty: serial: fsl_lpuart: clear receive flag on FIFO flush commit 8e4934c6d6c659e22b1b746af4196683e77ce6ca upstream. When the receiver was enabled during startup, a character could have been in the FIFO when the UART get initially used. The driver configures the (receive) watermark level, and flushes the FIFO. However, the receive flag (RDRF) could still be set at that stage (as mentioned in the register description of UARTx_RWFIFO). This leads to an interrupt which won't be handled properly in interrupt mode: The receive interrupt function lpuart_rxint checks the FIFO count, which is 0 at that point (due to the flush during initialization). The problem does not manifest when using DMA to receive characters. Fix this situation by explicitly read the status register, which leads to clearing of the RDRF flag. Due to the flush just after the status flag read, a explicit data read is not to required. Signed-off-by: Stefan Agner Signed-off-by: Greg Kroah-Hartman commit beaa43e9b4ca8cfe4379bb2f849f10e04b85b1d4 Author: Stefan Agner Date: Fri Mar 13 14:51:50 2015 +0100 tty: serial: fsl_lpuart: specify transmit FIFO size commit 4e8f245937091b2c9eebf3d4909c9ceda4f0a78e upstream. Specify transmit FIFO size which might be different depending on LPUART instance. This makes sure uart_wait_until_sent in serial core getting called, which in turn waits and checks if the FIFO is really empty on shutdown by using the tx_empty callback. Without the call of this callback, the last several characters might not yet be transmitted when closing the serial port. This can be reproduced by simply using echo and redirect the output to a ttyLP device. Signed-off-by: Stefan Agner Signed-off-by: Greg Kroah-Hartman commit f43a431c415b34a75382e4ecbda5a533401beb72 Author: Lu Baolu Date: Mon Mar 23 18:27:42 2015 +0200 usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers commit 227a4fd801c8a9fa2c4700ab98ec1aec06e3b44d upstream. When a device with an isochronous endpoint is plugged into the Intel xHCI host controller, and the driver submits multiple frames per URB, the xHCI driver will set the Block Event Interrupt (BEI) flag on all but the last TD for the URB. This causes the host controller to place an event on the event ring, but not send an interrupt. When the last TD for the URB completes, BEI is cleared, and we get an interrupt for the whole URB. However, under Intel xHCI host controllers, if the event ring is full of events from transfers with BEI set, an "Event Ring is Full" event will be posted to the last entry of the event ring, but no interrupt is generated. Host will cease all transfer and command executions and wait until software completes handling the pending events in the event ring. That means xHC stops, but event of "event ring is full" is not notified. As the result, the xHC looks like dead to user. This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And it should be backported to kernels as old as 3.0, that contains the commit 69e848c2090a ("Intel xhci: Support EHCI/xHCI port switching."). Signed-off-by: Lu Baolu Tested-by: Alistair Grant Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 8ca0f4f1f884d73cdcb3c587a3be7e12995e1f02 Author: Lu Baolu Date: Mon Mar 23 18:27:41 2015 +0200 usb: xhci: handle Config Error Change (CEC) in xhci driver commit 9425183d177aa4a2f09d01a74925124f0778b595 upstream. Linux xHCI driver doesn't report and handle port cofig error change. If Port Configure Error for root hub port occurs, CEC bit in PORTSC would be set by xHC and remains 1. This happends when the root port fails to configure its link partner, e.g. the port fails to exchange port capabilities information using Port Capability LMPs. Then the Port Status Change Events will be blocked until all status change bits(CEC is one of the change bits) are cleared('0') (refer to xHCI spec 4.19.2). Otherwise, the port status change event for this root port will not be generated anymore, then root port would look like dead for user and can't be recovered until a Host Controller Reset(HCRST). This patch is to check CEC bit in PORTSC in xhci_get_port_status() and set a Config Error in the return status if CEC is set. This will cause a ClearPortFeature request, where CEC bit is cleared in xhci_clear_port_change_bit(). [The commit log is based on initial Marvell patch posted at http://marc.info/?l=linux-kernel&m=142323612321434&w=2] Reported-by: Gregory CLEMENT Signed-off-by: Lu Baolu Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit e0cb36a7f1174bc7cb23ff4571131af824e66551 Author: Thomas Schlichter Date: Tue Mar 31 20:24:39 2015 +0200 cpuidle: ACPI: do not overwrite name and description of C0 commit c7e8bdf5872c5a8f5a6494e16fe839c38a0d3d3d upstream. Fix a bug that leads to showing the name and description of C-state C0 as "" in sysfs after the ACPI C-states changed (e.g. after AC->DC or DC->AC transition). The function poll_idle_init() in drivers/cpuidle/driver.c initializes the state 0 during cpuidle_register_driver(), so we better do not overwrite it again with '\0' during acpi_processor_cst_has_changed(). Signed-off-by: Thomas Schlichter Reviewed-by: Bartlomiej Zolnierkiewicz Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 67b4228ed87b17801c8822f6d4ebe949493949cc Author: Bartlomiej Zolnierkiewicz Date: Tue Mar 31 20:15:09 2015 +0200 cpuidle: remove state_count field from struct cpuidle_device commit d75e4af14e228bbe3f86e29bcecb8e6be98d4e04 upstream. Thomas Schlichter reports the following issue on his Samsung NC20: "The C-states C1 and C2 to the OS when connected to AC, and additionally provides the C3 C-state when disconnected from AC. However, the number of C-states shown in sysfs is fixed to the number of C-states present at boot. If I boot with AC connected, I always only see the C-states up to C2 even if I disconnect AC. The reason is commit 130a5f692425 (ACPI / cpuidle: remove dev->state_count setting). It removes the update of dev->state_count, but sysfs uses exactly this variable to show the C-states. The fix is to use drv->state_count in sysfs. As this is currently the last user of dev->state_count, this variable can be completely removed." Remove dev->state_count as per the above. Reported-by: Thomas Schlichter Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Kyungmin Park Acked-by: Daniel Lezcano [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit c1caa181eb331c4ae8cddf74d283310c2198a42b Author: Jean Delvare Date: Fri Mar 20 09:59:47 2015 +0100 firmware: dmi_scan: Prevent dmi_num integer overflow commit bfbaafae8519d82d10da6abe75f5766dd5b20475 upstream. dmi_num is a u16, dmi_len is a u32, so this construct: dmi_num = dmi_len / 4; would result in an integer overflow for a DMI table larger than 256 kB. I've never see such a large table so far, but SMBIOS 3.0 makes it possible so maybe we'll see such tables in the future. So instead of faking a structure count when the entry point does not provide it, adjust the loop condition in dmi_table() to properly deal with the case where dmi_num is not set. This bug was introduced with the initial SMBIOS 3.0 support in commit fc43026278b2 ("dmi: add support for SMBIOS 3.0 64-bit entry point"). Signed-off-by: Jean Delvare Cc: Matt Fleming Cc: Ivan Khoronzhuk Acked-by: Ard Biesheuvel Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit 7781f475043500175217e22bd6ad93995fa6e821 Author: Andreas Werner Date: Sun Mar 22 17:35:52 2015 +0100 can: flexcan: Deferred on Regulator return EPROBE_DEFER commit 555828ef45f825d6ee06559f0304163550eed380 upstream. Return EPROBE_DEFER if Regulator returns EPROBE_DEFER If the Flexcan driver is built into kernel and a regulator is used to enable the CAN transceiver, the Flexcan driver may not use the regulator. When initializing the Flexcan device with a regulator defined in the device tree, but not initialized, the regulator subsystem returns EPROBE_DEFER, hence the Flexcan init fails. The solution for this is to return EPROBE_DEFER if regulator is not initialized and wait until the regulator is initialized. Signed-off-by: Andreas Werner Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 6e6c9127315087a0535ab0b5e80f174681ed6b61 Author: Andri Yngvason Date: Tue Mar 17 13:03:09 2015 +0000 can: flexcan: fix bus-off error state handling. commit 258ce80e19211f06c97a562a71308ec21a9ab98f upstream. Making sure that the bus-off state gets passed to can_change_state(). Signed-off-by: Andri Yngvason Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit f3e70953e7ad132ec5cad878f58e7348ad152159 Author: Stefan Lippers-Hollmann Date: Mon Mar 30 22:44:27 2015 +0200 x86/reboot: Add ASRock Q1900DC-ITX mainboard reboot quirk commit 80313b3078fcd2ca51970880d90757f05879a193 upstream. The ASRock Q1900DC-ITX mainboard (Baytrail-D) hangs randomly in both BIOS and UEFI mode while rebooting unless reboot=pci is used. Add a quirk to reboot via the pci method. The problem is very intermittent and hard to debug, it might succeed rebooting just fine 40 times in a row - but fails half a dozen times the next day. It seems to be slightly less common in BIOS CSM mode than native UEFI (with the CSM disabled), but it does happen in either mode. Since I've started testing this patch in late january, rebooting has been 100% reliable. Most of the time it already hangs during POST, but occasionally it might even make it through the bootloader and the kernel might even start booting, but then hangs before the mode switch. The same symptoms occur with grub-efi, gummiboot and grub-pc, just as well as (at least) kernel 3.16-3.19 and 4.0-rc6 (I haven't tried older kernels than 3.16). Upgrading to the most current mainboard firmware of the ASRock Q1900DC-ITX, version 1.20, does not improve the situation. ( Searching the web seems to suggest that other Bay Trail-D mainboards might be affected as well. ) -- Signed-off-by: Stefan Lippers-Hollmann Cc: Matt Fleming Link: http://lkml.kernel.org/r/20150330224427.0fb58e42@mir Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 154cea06a19d6be0a10511191089b0b58ac5c0d9 Author: Felix Fietkau Date: Thu Mar 12 17:17:18 2015 +0100 ath9k: fix tracking of enabled AP beacons commit 1cf48f22c98ae24a49a3f1b6900e4c9a9a0fcc62 upstream. sc->nbcnvifs tracks assigned beacon slots, not enabled beacons. Therefore, it cannot be used to decide if cur_conf->enable_beacon (bool) should be updated, or if beacons have been enabled already. With the current code (depending on the order of calls), beacons often do not get enabled in an AP+STA setup. To fix tracking of enabled beacons, convert cur_conf->enable_beacon to a bitmask of enabled beacon slots. Signed-off-by: Felix Fietkau Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 4acc3ce12dcb60340212059818f7810cdd8e4335 Author: Peter Ujfalusi Date: Fri Mar 27 13:35:52 2015 +0200 dmaengine: omap-dma: Fix memory leak when terminating running transfer commit 02d88b735f5a60f04dbf6d051b76e1877a0d0844 upstream. In omap_dma_start_desc the vdesc->node is removed from the virt-dma framework managed lists (to be precise from the desc_issued list). If a terminate_all comes before the transfer finishes the omap_desc will not be freed up because it is not in any of the lists and we stopped the DMA channel so the transfer will not going to complete. There is no special sequence for leaking memory when using cyclic (audio) transfer: with every start and stop of a cyclic transfer the driver leaks struct omap_desc worth of memory. Free up the allocated memory directly in omap_dma_terminate_all() since the framework will not going to do that for us. Signed-off-by: Peter Ujfalusi CC: Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 56e1c4b3236721b26f059d0f331e2464a5d68fd7 Author: Petr Kulhavy Date: Fri Mar 27 13:35:51 2015 +0200 dmaengine: edma: fix memory leak when terminating running transfers commit 5ca9e7ce6eebec53362ff779264143860ccf68cd upstream. If edma_terminate_all() was called while a transfer was running (i.e. after edma_execute() but before edma_callback()) the echan->edesc was not freed. This was due to the fact that a running transfer is on none of the vchan lists: desc_submitted, desc_issued, desc_completed (edma_execute() removes it from the desc_issued list), so the vchan_dma_desc_free_list() called at the end of edma_terminate_all() didn't find it and didn't free it. This bug was found on an AM1808 based hardware (very similar to da850evm, however using the second MMC/SD controller), where intense operations on the SD card wasted the device 128MB RAM within a couple of days. Peter Ujfalusi: The issue is even more severe since it affects cyclic (audio) transfers as well. In this case starting/stopping audio will results memory leak. Signed-off-by: Petr Kulhavy Signed-off-by: Peter Ujfalusi CC: Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 7f754cc8edfb11d255eb91c823f93aa09ef0f138 Author: Darshana Padmadas Date: Sat Mar 28 12:07:14 2015 +0530 iio: imu: Use iio_trigger_get for indio_dev->trig assignment commit 4ce7ca89d6e8eae9e201cd0e972ba323f33e2fb4 upstream. This patch uses iio_trigger_get to increment the reference count of trigger device, to avoid incorrect assignment. Can result in a null pointer dereference during removal if the trigger has been changed before removal. This patch refers to a similar situation encountered through the following discussion: http://www.spinics.net/lists/linux-iio/msg13669.html Signed-off-by: Darshana Padmadas Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit ecc682b240970786149559f50dac4613e374192d Author: Stefan Agner Date: Tue Mar 24 13:47:47 2015 +0100 iio: adc: vf610: use ADC clock within specification commit f54e9f2be312a4e71b54aea865b2e33ccb95ef0c upstream. Depending on conversion mode used, the ADC clock (ADCK) needs to be below a maximum frequency. According to Vybrid's data sheet this is 20MHz for the low power conversion mode. The ADC clock is depending on input clock, which is the bus clock by default. Vybrid SoC are typically clocked at at 400MHz or 500MHz, which leads to 66MHz or 83MHz bus clock respectively. Hence, a divider of 8 is required to stay below the specified maximum clock of 20MHz. Due to the different bus clock speeds, the resulting sampling frequency is not static. Hence use the ADC clock and calculate the actual available sampling frequency dynamically. This fixes bogous values observed on some 500MHz clocked Vybrid SoC. The resulting value usually showed Bit 9 being stuck at 1, or 0, which lead to a value of +/-512. Signed-off-by: Stefan Agner Acked-by: Fugang Duan Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b45b375615ee2553a617a5e6c3f3f4cde04568ee Author: Sathyanarayanan Kuppuswamy Date: Tue Mar 3 18:17:56 2015 +0200 iio: bmc150: change sampling frequency commit 0ba8da961bd868c67a8dae3dbbee145514515e9c upstream. Currently driver reports device bandwidth list as available sampling frequency. But sampling frequency is actually twice the device bandwidth. This patch fixes this issue. Signed-off-by: Sathyanarayanan Kuppuswamy Signed-off-by: Octavian Purdila Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a8173cd017a912dd333f68bf1c0c31afaf70d4e3 Author: Martin Fuzzey Date: Thu Feb 19 15:17:44 2015 +0100 iio: core: Fix double free. commit c1b03ab5e886760bdd38c9c7a27af149046ffe01 upstream. When an error occurred during event registration memory was freed twice resulting in kernel memory corruption and a crash in unrelated code. The problem was caused by iio_device_unregister_eventset() iio_device_unregister_sysfs() being called twice, once on the error path and then again via iio_dev_release(). Fix this by making these two functions idempotent so they may be called multiple times. The problem was observed before applying 78b33216 iio:core: Handle error when mask type is not separate Signed-off-by: Martin Fuzzey Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6cf22b22f477fc59341d96f1d2a56f2b6f09b5e7 Author: Viorel Suman Date: Wed Feb 18 20:05:21 2015 +0200 iio: inv_mpu6050: Clear timestamps fifo while resetting hardware fifo commit 4dac0a8eefd55bb1f157d1a5a084531334a2d74c upstream. A hardware fifo reset always imply an invalidation of the existing timestamps, so we'll clear timestamps fifo on successfull hardware fifo reset. Signed-off-by: Viorel Suman Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 4729612ec9c0e7ace7611145f0325d01dcb5ee7d Author: Bart Van Assche Date: Wed Mar 4 10:31:47 2015 +0100 Defer processing of REQ_PREEMPT requests for blocked devices commit bba0bdd7ad4713d82338bcd9b72d57e9335a664b upstream. SCSI transport drivers and SCSI LLDs block a SCSI device if the transport layer is not operational. This means that in this state no requests should be processed, even if the REQ_PREEMPT flag has been set. This patch avoids that a rescan shortly after a cable pull sporadically triggers the following kernel oops: BUG: unable to handle kernel paging request at ffffc9001a6bc084 IP: [] mlx4_ib_post_send+0xd2/0xb30 [mlx4_ib] Process rescan-scsi-bus (pid: 9241, threadinfo ffff88053484a000, task ffff880534aae100) Call Trace: [] srp_post_send+0x65/0x70 [ib_srp] [] srp_queuecommand+0x1cf/0x3e0 [ib_srp] [] scsi_dispatch_cmd+0x101/0x280 [scsi_mod] [] scsi_request_fn+0x411/0x4d0 [scsi_mod] [] __blk_run_queue+0x27/0x30 [] blk_execute_rq_nowait+0x82/0x110 [] blk_execute_rq+0x62/0xf0 [] scsi_execute+0xe8/0x190 [scsi_mod] [] scsi_execute_req+0xa3/0x130 [scsi_mod] [] scsi_probe_lun+0x17a/0x450 [scsi_mod] [] scsi_probe_and_add_lun+0x156/0x480 [scsi_mod] [] __scsi_scan_target+0xdf/0x1f0 [scsi_mod] [] scsi_scan_host_selected+0x183/0x1c0 [scsi_mod] [] scsi_scan+0xdb/0xe0 [scsi_mod] [] store_scan+0x13/0x20 [scsi_mod] [] sysfs_write_file+0xcb/0x160 [] vfs_write+0xce/0x140 [] sys_write+0x53/0xa0 [] system_call_fastpath+0x16/0x1b [<00007f611c9d9300>] 0x7f611c9d92ff Reported-by: Max Gurtuvoy Signed-off-by: Bart Van Assche Reviewed-by: Mike Christie Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 364c9d4eb185843bd249cf2e542366deab1ece3f Author: Doug Goldstein Date: Mon Mar 23 20:34:48 2015 -0500 USB: ftdi_sio: Use jtag quirk for SNAP Connect E10 commit b229a0f840f774d29d8fedbf5deb344ca36b7f1a upstream. This patch uses the existing CALAO Systems ftdi_8u2232c_probe in order to avoid attaching a TTY to the JTAG port as this board is based on the CALAO Systems reference design and needs the same fix up. Signed-off-by: Doug Goldstein [johan: clean up probe logic ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 5e2c62839413ad1260cd065f05ca6677c773f618 Author: Doug Goldstein Date: Sun Mar 15 21:56:04 2015 -0500 USB: ftdi_sio: Added custom PID for Synapse Wireless product commit 4899c054a90439477b24da8977db8d738376fe90 upstream. Synapse Wireless uses the FTDI VID with a custom PID of 0x9090 for their SNAP Stick 200 product. Signed-off-by: Doug Goldstein Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ea2f84d13367a8c99dd26c80fc39c3571763b483 Author: Nathaniel W Filardo Date: Mon Mar 16 11:19:55 2015 -0400 USB: keyspan_pda: add new device id commit 5e71fc8629cefae5f3c1a4f498de3fe4f631924a upstream. Add USB VID/PID for Xircom PGMFHUB USB/serial component. (The hub and SCSI bridge on that hardware are recognized out of the box by existing drivers.) Tested VID/PID using new_id and loopback connection and was met with success, but that's all the testing done. Signed-off-by: Nathaniel Wesley Filardo Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit edfd6572d17986f3ba737314cc6a41e20f7a44a6 Author: David Miller Date: Wed Mar 18 23:18:40 2015 -0400 radeon: Do not directly dereference pointers to BIOS area. commit f2c9e560b406f2f6b14b345c7da33467dee9cdf2 upstream. Use readb() and memcpy_fromio() accessors instead. Reviewed-by: Christian König Signed-off-by: David S. Miller Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 19b6da5ab9cd57b348bea9126fab9566d1cd7e18 Author: Martin K. Petersen Date: Fri Mar 27 15:17:21 2015 -0400 libata: Blacklist queued TRIM on Samsung SSD 850 Pro commit 6fc4d97a4987c5d247655a157a9377996626221a upstream. Blacklist queued TRIM on this drive for now. Reported-by: Stefan Keller Signed-off-by: Martin K. Petersen Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 823d64e5e8e4d1db42fbf5028d7fad027b9365c0 Author: Martin K. Petersen Date: Fri Mar 27 15:17:20 2015 -0400 libata: Update Crucial/Micron blacklist commit ff7f53fb82a7801a778e5902bdbbc5e195ab0de0 upstream. Micron has released an updated firmware (MU02) for M510/M550/MX100 drives to fix the issues with queued TRIM. Queued TRIM remains broken on M500 but is working fine on later drives such as M600 and MX200. Tweak our blacklist to reflect the above. Link: https://bugzilla.kernel.org/show_bug.cgi?id=71371 Signed-off-by: Martin K. Petersen Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 7a5c2e551da4e7c9eb06e6d1a927336e07020646 Author: Tejun Heo Date: Mon Mar 23 00:18:48 2015 -0400 writeback: fix possible underflow in write bandwidth calculation commit c72efb658f7c8b27ca3d0efb5cfd5ded9fcac89e upstream. From 1ebf33901ecc75d9496862dceb1ef0377980587c Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Mon, 23 Mar 2015 00:08:19 -0400 2f800fbd777b ("writeback: fix dirtied pages accounting on redirty") introduced account_page_redirty() which reverts stat updates for a redirtied page, making BDI_DIRTIED no longer monotonically increasing. bdi_update_write_bandwidth() uses the delta in BDI_DIRTIED as the basis for bandwidth calculation. While unlikely, since the above patch, the newer value may be lower than the recorded past value and underflow the bandwidth calculation leading to a wild result. Fix it by subtracing min of the old and new values when calculating delta. AFAIK, there hasn't been any report of it happening but the resulting erratic behavior would be non-critical and temporary, so it's possible that the issue is happening without being reported. The risk of the fix is very low, so tagged for -stable. Signed-off-by: Tejun Heo Cc: Jens Axboe Cc: Jan Kara Cc: Wu Fengguang Cc: Greg Thelen Fixes: 2f800fbd777b ("writeback: fix dirtied pages accounting on redirty") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c944f12763623b6c496419fbac23285ef6cc93e9 Author: Tejun Heo Date: Wed Mar 4 10:37:43 2015 -0500 writeback: add missing INITIAL_JIFFIES init in global_update_bandwidth() commit 7d70e15480c0450d2bfafaad338a32e884fc215e upstream. global_update_bandwidth() uses static variable update_time as the timestamp for the last update but forgets to initialize it to INITIALIZE_JIFFIES. This means that global_dirty_limit will be 5 mins into the future on 32bit and some large amount jiffies into the past on 64bit. This isn't critical as the only effect is that global_dirty_limit won't be updated for the first 5 mins after booting on 32bit machines, especially given the auxiliary nature of global_dirty_limit's role - protecting against global dirty threshold's sudden dips; however, it does lead to unintended suboptimal behavior. Fix it. Fixes: c42843f2f0bb ("writeback: introduce smoothed global dirty limit") Signed-off-by: Tejun Heo Acked-by: Jan Kara Cc: Wu Fengguang Cc: Jens Axboe Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ba44e51e994edc3ab7dea8b671272671a79939ae Author: Viresh Kumar Date: Thu Apr 2 10:21:33 2015 +0530 cpufreq: Schedule work for the first-online CPU on resume commit c75de0ac0756d4b442f460e10461720c7c2412c2 upstream. All CPUs leaving the first-online CPU are hotplugged out on suspend and and cpufreq core stops managing them. On resume, we need to call cpufreq_update_policy() for this CPU's policy to make sure its frequency is in sync with cpufreq's cached value, as it might have got updated by hardware during suspend/resume. The policies are always added to the top of the policy-list. So, in normal circumstances, CPU 0's policy will be the last one in the list. And so the code checks for the last policy. But there are cases where it will fail. Consider quad-core system, with policy-per core. If CPU0 is hotplugged out and added back again, the last policy will be on CPU1 :( To fix this in a proper way, always look for the policy of the first online CPU. That way we will be sure that we are calling cpufreq_update_policy() for the only CPU that wasn't hotplugged out. Fixes: 2f0aea936360 ("cpufreq: suspend governors on system suspend/hibernate") Reported-by: Saravana Kannan Signed-off-by: Viresh Kumar Acked-by: Saravana Kannan Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 28d96fb03f9b99146a6f408488861f62efdfad7b Author: Brian Silverman Date: Wed Feb 18 16:23:56 2015 -0800 sched: Fix RLIMIT_RTTIME when PI-boosting to RT commit 746db9443ea57fd9c059f62c4bfbf41cf224fe13 upstream. When non-realtime tasks get priority-inheritance boosted to a realtime scheduling class, RLIMIT_RTTIME starts to apply to them. However, the counter used for checking this (the same one used for SCHED_RR timeslices) was not getting reset. This meant that tasks running with a non-realtime scheduling class which are repeatedly boosted to a realtime one, but never block while they are running realtime, eventually hit the timeout without ever running for a time over the limit. This patch resets the realtime timeslice counter when un-PI-boosting from an RT to a non-RT scheduling class. I have some test code with two threads and a shared PTHREAD_PRIO_INHERIT mutex which induces priority boosting and spins while boosted that gets killed by a SIGXCPU on non-fixed kernels but doesn't with this patch applied. It happens much faster with a CONFIG_PREEMPT_RT kernel, and does happen eventually with PREEMPT_VOLUNTARY kernels. Signed-off-by: Brian Silverman Signed-off-by: Peter Zijlstra (Intel) Cc: austin@peloton-tech.com Link: http://lkml.kernel.org/r/1424305436-6716-1-git-send-email-brian@peloton-tech.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit bc0480036dd927510f87a1a3e1f341ff8bc98e8a Author: Laura Abbott Date: Wed Mar 25 15:55:26 2015 -0700 mm/page_alloc.c: call kernel_map_pages in unset_migrateype_isolate commit cfa869438282be84ad4110bba5027ef1fbbe71e4 upstream. Commit 3c605096d315 ("mm/page_alloc: restrict max order of merging on isolated pageblock") changed the logic of unset_migratetype_isolate to check the buddy allocator and explicitly call __free_pages to merge. The page that is being freed in this path never had prep_new_page called so set_page_refcounted is called explicitly but there is no call to kernel_map_pages. With the default kernel_map_pages this is mostly harmless but if kernel_map_pages does any manipulation of the page tables (unmapping or setting pages to read only) this may trigger a fault: alloc_contig_range test_pages_isolated(ceb00, ced00) failed Unable to handle kernel paging request at virtual address ffffffc0cec00000 pgd = ffffffc045fc4000 [ffffffc0cec00000] *pgd=0000000000000000 Internal error: Oops: 9600004f [#1] PREEMPT SMP Modules linked in: exfatfs CPU: 1 PID: 23237 Comm: TimedEventQueue Not tainted 3.10.49-gc72ad36-dirty #1 task: ffffffc03de52100 ti: ffffffc015388000 task.ti: ffffffc015388000 PC is at memset+0xc8/0x1c0 LR is at kernel_map_pages+0x1ec/0x244 Fix this by calling kernel_map_pages to ensure the page is set in the page table properly Fixes: 3c605096d315 ("mm/page_alloc: restrict max order of merging on isolated pageblock") Signed-off-by: Laura Abbott Cc: Naoya Horiguchi Cc: Mel Gorman Acked-by: Rik van Riel Cc: Yasuaki Ishimatsu Cc: Zhang Yanfei Cc: Xishi Qiu Cc: Vladimir Davydov Acked-by: Joonsoo Kim Cc: Gioh Kim Cc: Michal Nazarewicz Cc: Marek Szyprowski Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c7acc44de07a49d041bca200fe05ce0a90095e00 Author: Gu Zheng Date: Wed Mar 25 15:55:20 2015 -0700 mm/memory hotplug: postpone the reset of obsolete pgdat commit b0dc3a342af36f95a68fe229b8f0f73552c5ca08 upstream. Qiu Xishi reported the following BUG when testing hot-add/hot-remove node under stress condition: BUG: unable to handle kernel paging request at 0000000000025f60 IP: next_online_pgdat+0x1/0x50 PGD 0 Oops: 0000 [#1] SMP ACPI: Device does not support D3cold Modules linked in: fuse nls_iso8859_1 nls_cp437 vfat fat loop dm_mod coretemp mperf crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 pcspkr microcode igb dca i2c_algo_bit ipv6 megaraid_sas iTCO_wdt i2c_i801 i2c_core iTCO_vendor_support tg3 sg hwmon ptp lpc_ich pps_core mfd_core acpi_pad rtc_cmos button ext3 jbd mbcache sd_mod crc_t10dif scsi_dh_alua scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh ahci libahci libata scsi_mod [last unloaded: rasf] CPU: 23 PID: 238 Comm: kworker/23:1 Tainted: G O 3.10.15-5885-euler0302 #1 Hardware name: HUAWEI TECHNOLOGIES CO.,LTD. Huawei N1/Huawei N1, BIOS V100R001 03/02/2015 Workqueue: events vmstat_update task: ffffa800d32c0000 ti: ffffa800d32ae000 task.ti: ffffa800d32ae000 RIP: 0010: next_online_pgdat+0x1/0x50 RSP: 0018:ffffa800d32afce8 EFLAGS: 00010286 RAX: 0000000000001440 RBX: ffffffff81da53b8 RCX: 0000000000000082 RDX: 0000000000000000 RSI: 0000000000000082 RDI: 0000000000000000 RBP: ffffa800d32afd28 R08: ffffffff81c93bfc R09: ffffffff81cbdc96 R10: 00000000000040ec R11: 00000000000000a0 R12: ffffa800fffb3440 R13: ffffa800d32afd38 R14: 0000000000000017 R15: ffffa800e6616800 FS: 0000000000000000(0000) GS:ffffa800e6600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000025f60 CR3: 0000000001a0b000 CR4: 00000000001407e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: refresh_cpu_vm_stats+0xd0/0x140 vmstat_update+0x11/0x50 process_one_work+0x194/0x3d0 worker_thread+0x12b/0x410 kthread+0xc6/0xd0 ret_from_fork+0x7c/0xb0 The cause is the "memset(pgdat, 0, sizeof(*pgdat))" at the end of try_offline_node, which will reset all the content of pgdat to 0, as the pgdat is accessed lock-free, so that the users still using the pgdat will panic, such as the vmstat_update routine. process A: offline node XX: vmstat_updat() refresh_cpu_vm_stats() for_each_populated_zone() find online node XX cond_resched() offline cpu and memory, then try_offline_node() node_set_offline(nid), and memset(pgdat, 0, sizeof(*pgdat)) zone = next_zone(zone) pg_data_t *pgdat = zone->zone_pgdat; // here pgdat is NULL now next_online_pgdat(pgdat) next_online_node(pgdat->node_id); // NULL pointer access So the solution here is postponing the reset of obsolete pgdat from try_offline_node() to hotadd_new_pgdat(), and just resetting pgdat->nr_zones and pgdat->classzone_idx to be 0 rather than the memset 0 to avoid breaking pointer information in pgdat. Signed-off-by: Gu Zheng Reported-by: Xishi Qiu Suggested-by: KAMEZAWA Hiroyuki Cc: David Rientjes Cc: Yasuaki Ishimatsu Cc: Taku Izumi Cc: Tang Chen Cc: Xie XiuQi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 30ecad29ba65f4dea08e2c24fc0ed8ec276fba8d Author: Leon Yu Date: Wed Mar 25 15:55:11 2015 -0700 mm: fix anon_vma->degree underflow in anon_vma endless growing prevention commit 3fe89b3e2a7bbf3e97657104b9b33a9d81b950b3 upstream. I have constantly stumbled upon "kernel BUG at mm/rmap.c:399!" after upgrading to 3.19 and had no luck with 4.0-rc1 neither. So, after looking into new logic introduced by commit 7a3ef208e662 ("mm: prevent endless growth of anon_vma hierarchy"), I found chances are that unlink_anon_vmas() is called without incrementing dst->anon_vma->degree in anon_vma_clone() due to allocation failure. If dst->anon_vma is not NULL in error path, its degree will be incorrectly decremented in unlink_anon_vmas() and eventually underflow when exiting as a result of another call to unlink_anon_vmas(). That's how "kernel BUG at mm/rmap.c:399!" is triggered for me. This patch fixes the underflow by dropping dst->anon_vma when allocation fails. It's safe to do so regardless of original value of dst->anon_vma because dst->anon_vma doesn't have valid meaning if anon_vma_clone() fails. Besides, callers don't care dst->anon_vma in such case neither. Also suggested by Michal Hocko, we can clean up vma_adjust() a bit as anon_vma_clone() now does the work. [akpm@linux-foundation.org: tweak comment] Fixes: 7a3ef208e662 ("mm: prevent endless growth of anon_vma hierarchy") Signed-off-by: Leon Yu Signed-off-by: Konstantin Khlebnikov Reviewed-by: Michal Hocko Acked-by: Rik van Riel Acked-by: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit af075ec107b821539499eab62bf0195f165543cf Author: Johannes Berg Date: Wed Apr 1 14:20:42 2015 +0200 mac80211: fix RX A-MPDU session reorder timer deletion commit 788211d81bfdf9b6a547d0530f206ba6ee76b107 upstream. There's an issue with the way the RX A-MPDU reorder timer is deleted that can cause a kernel crash like this: * tid_rx is removed - call_rcu(ieee80211_free_tid_rx) * station is destroyed * reorder timer fires before ieee80211_free_tid_rx() runs, accessing the station, thus potentially crashing due to the use-after-free The station deletion is protected by synchronize_net(), but that isn't enough -- ieee80211_free_tid_rx() need not have run when that returns (it deletes the timer.) We could use rcu_barrier() instead of synchronize_net(), but that's much more expensive. Instead, to fix this, add a field tracking that the session is being deleted. In this case, the only re-arming of the timer happens with the reorder spinlock held, so make that code not rearm it if the session is being deleted and also delete the timer after setting that field. This ensures the timer cannot fire after ___ieee80211_stop_rx_ba_session() returns, which fixes the problem. Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 7167c574692b3e8f3e46eac1c3f9091da9809d41 Author: Sudip Mukherjee Date: Tue Jan 27 18:08:22 2015 +0530 nbd: fix possible memory leak commit ff6b8090e26ef7649ef0cc6b42389141ef48b0cf upstream. we have already allocated memory for nbd_dev, but we were not releasing that memory and just returning the error value. Signed-off-by: Sudip Mukherjee Acked-by: Paul Clements Signed-off-by: Markus Pargmann Signed-off-by: Greg Kroah-Hartman commit 74b8c182c346ec27594a522e24bb0608d20d8b5a Author: Paul Clarke Date: Fri Feb 20 11:13:33 2015 -0600 powerpc: Re-enable dynticks commit fea559f303567e558bfab9c8ba4a2af5b309205a upstream. Implement arch_irq_work_has_interrupt() for powerpc Commit 9b01f5bf3 introduced a dependency on "IRQ work self-IPIs" for full dynamic ticks to be enabled, by expecting architectures to implement a suitable arch_irq_work_has_interrupt() routine. Several arches have implemented this routine, including x86 (3010279f) and arm (09f6edd4), but powerpc was omitted. This patch implements this routine for powerpc. The symptom, at boot (on powerpc systems) with "nohz_full=" is displayed: NO_HZ: Can't run full dynticks because arch doesn't support irq work self-IPIs after this patch: NO_HZ: Full dynticks CPUs: . Tested against 3.19. powerpc implements "IRQ work self-IPIs" by setting the decrementer to 1 in arch_irq_work_raise(), which causes a decrementer exception on the next timebase tick. We then handle the work in __timer_interrupt(). CC: Frederic Weisbecker Signed-off-by: Paul A. Clarke Reviewed-by: Paul E. McKenney [mpe: Flesh out change log, fix ws & include guards, remove include of processor.h] Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 4ab14323dfb7de200cbb913030e5fa871e6351c8 Author: Jan Stancek Date: Tue Mar 31 18:11:46 2015 +0200 powerpc: fix memory corruption by pnv_alloc_idle_core_states commit d52356e7f48e400ca258c6763a232a92fa82ff68 upstream. Space allocated for paca is based off nr_cpu_ids, but pnv_alloc_idle_core_states() iterates paca with cpu_nr_cores()*threads_per_core, which is using NR_CPUS. This causes pnv_alloc_idle_core_states() to write over memory, which is outside of paca array and may later lead to various panics. Fixes: 7cba160ad789 (powernv/cpuidle: Redesign idle states management) Signed-off-by: Jan Stancek Signed-off-by: Michael Ellerman Signed-off-by: Preet U. Murthy Signed-off-by: Greg Kroah-Hartman commit 511dffb4f4f261ef808679a2711a3781d457421e Author: Jeff Layton Date: Tue Mar 31 12:03:28 2015 -0400 sunrpc: make debugfs file creation failure non-fatal commit f9c72d10d6fbf949558cd088389a42213ed7b12d upstream. We currently have a problem that SELinux policy is being enforced when creating debugfs files. If a debugfs file is created as a side effect of doing some syscall, then that creation can fail if the SELinux policy for that process prevents it. This seems wrong. We don't do that for files under /proc, for instance, so Bruce has proposed a patch to fix that. While discussing that patch however, Greg K.H. stated: "No kernel code should care / fail if a debugfs function fails, so please fix up the sunrpc code first." This patch converts all of the sunrpc debugfs setup code to be void return functins, and the callers to not look for errors from those functions. This should allow rpc_clnt and rpc_xprt creation to work, even if the kernel fails to create debugfs files for some reason. Symptoms were failing krb5 mounts on systems using gss-proxy and selinux. Fixes: 388f0c776781 "sunrpc: add a debugfs rpc_xprt directory..." Signed-off-by: Jeff Layton Acked-by: Greg Kroah-Hartman Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 083b5ebbae9370a00fe79e2b16c94d1e892b5765 Author: J. Bruce Fields Date: Mon Mar 23 11:02:30 2015 -0400 nfsd: return correct lockowner when there is a race on hash insert commit 340f0ba1c6c8412aa35fd6476044836b84361ea6 upstream. alloc_init_lock_stateowner can return an already freed entry if there is a race to put openowners in the hashtable. Noticed by inspection after Jeff Layton fixed the same bug for open owners. Depending on client behavior, this one may be trickier to trigger in practice. Fixes: c58c6610ec24 "nfsd: Protect adding/removing lock owners using client_lock" Cc: Trond Myklebust Acked-by: Jeff Layton Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 6d014bc957343d5454d6e765dc7b89d941088f0d Author: Jeff Layton Date: Mon Mar 23 10:53:42 2015 -0400 nfsd: return correct openowner when there is a race to put one in the hash commit c5952338bfc234e54deda45b7228f610a545e28a upstream. alloc_init_open_stateowner can return an already freed entry if there is a race to put openowners in the hashtable. In commit 7ffb588086e9, we changed it so that we allocate and initialize an openowner, and then check to see if a matching one got stuffed into the hashtable in the meantime. If it did, then we free the one we just allocated and take a reference on the one already there. There is a bug here though. The code will then return the pointer to the one that was allocated (and has now been freed). This wasn't evident before as this race almost never occurred. The Linux kernel client used to serialize requests for a single openowner. That has changed now with v4.0 kernels, and this race can now easily occur. Fixes: 7ffb588086e9 Cc: Trond Myklebust Reported-by: Christoph Hellwig Reviewed-by: Christoph Hellwig Signed-off-by: Jeff Layton Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 188fdb6997c62b466a21ea3984d14c33f334b246 Author: Juergen Gross Date: Fri Mar 20 13:55:39 2015 +0100 xen/balloon: before adding hotplugged memory, set frames to invalid commit 3c56b3a12ce52f361468cbdd2f79b2f3b8da0ea6 upstream. Commit 25b884a83d487fd62c3de7ac1ab5549979188482 ("x86/xen: set regions above the end of RAM as 1:1") introduced a regression. To be able to add memory pages which were added via memory hotplug to a pv domain, the pages must be "invalid" instead of "identity" in the p2m list before they can be added. Suggested-by: David Vrabel Signed-off-by: Juergen Gross Reviewed-by: Daniel Kiper Signed-off-by: David Vrabel Signed-off-by: Greg Kroah-Hartman commit efdb92dc5ecc1faecf6ee26f3edc07b144105571 Author: Juergen Gross Date: Fri Mar 20 13:55:38 2015 +0100 x86/xen: prepare p2m list for memory hotplug commit 633d6f17cd91ad5bf2370265946f716e42d388c6 upstream. Commit 054954eb051f35e74b75a566a96fe756015352c8 ("xen: switch to linear virtual mapped sparse p2m list") introduced a regression regarding to memory hotplug for a pv-domain: as the virtual space for the p2m list is allocated for the to be expected memory size of the domain only, hotplugged memory above that size will not be usable by the domain. Correct this by using a configurable size for the p2m list in case of memory hotplug enabled (default supported memory size is 512 GB for 64 bit domains and 4 GB for 32 bit domains). Signed-off-by: Juergen Gross Reviewed-by: Daniel Kiper Signed-off-by: David Vrabel Signed-off-by: Greg Kroah-Hartman commit b53e7c40642d850ea4a7ca329893ddfab7e79cb0 Author: Emmanuel Grumbach Date: Mon Mar 16 09:08:07 2015 +0200 iwlwifi: dvm: run INIT firmware again upon .start() commit 9c8928f5176766bec79f272bd47b7124e11cccbd upstream. The assumption before this patch was that we don't need to run again the INIT firmware after the system booted. The INIT firmware runs calibrations which impact the physical layer's behavior. Users reported that it may be helpful to run these calibrations again every time the interface is brought up. The penatly is minimal, since the calibrations run fast. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=94341 Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 7f9f20cf0e37f0a2a7dafbd8799f1198e964aa66 Author: Shachar Raindel Date: Wed Mar 18 17:39:08 2015 +0000 IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic commit 8494057ab5e40df590ef6ef7d66324d3ae33356b upstream. Properly verify that the resulting page aligned end address is larger than both the start address and the length of the memory area requested. Both the start and length arguments for ib_umem_get are controlled by the user. A misbehaving user can provide values which will cause an integer overflow when calculating the page aligned end address. This overflow can cause also miscalculation of the number of pages mapped, and additional logic issues. Addresses: CVE-2014-8159 Signed-off-by: Shachar Raindel Signed-off-by: Jack Morgenstein Signed-off-by: Or Gerlitz Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 0187ad2b69a51a23924cd41f730e2d923535db80 Author: David Sterba Date: Fri Jan 2 19:12:57 2015 +0100 btrfs: simplify insert_orphan_item commit 9c4f61f01d269815bb7c37be3ede59c5587747c6 upstream. We can search and add the orphan item in one go, btrfs_insert_orphan_item will find out if the item already exists. Signed-off-by: David Sterba Cc: Chris Mason Cc: Roman Mamedov Signed-off-by: Greg Kroah-Hartman commit e3bb7004125d5c0783da8dcbcf818063cf885912 Author: Daniel Vetter Date: Tue Feb 10 23:12:27 2015 +0100 drm/i915: Align initial plane backing objects correctly commit f37b5c2be8979993efee2da50b51126e3908eb8b upstream. Some bios really like to joke and start the planes at an offset ... hooray! Align start and end to fix this. v2: Fixup calculation of size, spotted by Chris Wilson. v3: Fix serious fumble I've just spotted. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86883 Cc: Johannes W Cc: Chris Wilson Cc: Jani Nikula Reported-and-tested-by: Johannes W Signed-off-by: Daniel Vetter [Jani: split WARN_ONs, rebase on v4.0-rc1] Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 84cb6e93dc425aa643cede2633596734f5e1ecb5 Author: Oded Gabbay Date: Tue Feb 17 11:58:27 2015 +0200 drm/amdkfd: Initialize only amdkfd's assigned pipelines commit 1365aa6266fad0669487240af3f098593796172c upstream. This patch fixes a bug in the initialization of the pipelines. The init_pipelines() function was called with a constant value of 0 in the first_pipe argument. This is an error because amdkfd doesn't handle pipe 0. The correct way is to pass the value that get_first_pipe() returns as the argument for first_pipe. This bug appeared in 3.19 (first version with amdkfd) and it causes around 15% drop in CPU performance of Kaveri (A10-7850). v2: Don't set get_first_pipe() as inline because it calls BUG_ON() Signed-off-by: Oded Gabbay Tested-by: Michel Dänzer Signed-off-by: Greg Kroah-Hartman commit 0f21572a49db635bfdf4767eb648e8f53a6e98d2 Author: Jesse Barnes Date: Wed Apr 1 14:22:58 2015 -0700 drm/i915/vlv: remove wait for previous GFX clk disable request commit 5df0582bf036bb5f9a8ad8db5884fe13a55347d1 upstream. Looks like it was introduced in: commit 650ad970a39f8b6164fe8613edc150f585315289 Author: Imre Deak Date: Fri Apr 18 16:35:02 2014 +0300 drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-of but I'm not sure why. It has caused problems for us in the past (see 85250ddff7a6 "drm/i915/chv: Remove Wait for a previous gfx force-off" and 8d4eee9cd7a1 "drm/i915: vlv: increase timeout when forcing on the GFX clock") and doesn't seem to be required, so let's just drop it. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611 Signed-off-by: Jesse Barnes Tested-by: Darren Hart Reviewed-by: Deepak S Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit a07b73f4155a91cab883da8e436fcd649a1dff74 Author: Jesse Barnes Date: Wed Apr 1 14:22:57 2015 -0700 drm/i915/vlv: save/restore the power context base reg commit 9c25210fd30991e68f93e2ec0857de2d967b5766 upstream. Some BIOSes (e.g. the one on the Minnowboard) don't save/restore this reg. If it's unlocked, we can just restore the previous value, and if it's locked (in case the BIOS re-programmed it for us) the write will be ignored and we'll still have "did it move" sanity check in the PM code to warn us if something is still amiss. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611 Signed-off-by: Jesse Barnes Tested-by: Darren Hart Reviewed-by: Imre Deak Reviewed-by: Deepak S Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 69ee14fd36a1314594a73071675124c904efd19d Author: Deepak S Date: Sat Mar 28 15:23:34 2015 +0530 drm/i915/chv: Remove Wait for a previous gfx force-off commit c9c52e24194a741f9fca96e7aa965f0fa36af504 upstream. On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a sticky bit and it will always be set. So ignore Check for previous Gfx force off during suspend and allow the force clk as part S0ix Sequence Signed-off-by: Deepak S Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit ed1d8d31806ebf4c917ebccc19d8fd5c54127eb6 Author: Christian König Date: Tue Mar 31 17:36:58 2015 +0200 drm/radeon: fix wait in radeon_mn_invalidate_range_start commit 22e2e86560c5fca6f9b9d078f221fcdab9947a5e upstream. We need to wait for all fences, not just the exclusive one. Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit db64474d6bc0613dcd69332e7330b37d77f77fba Author: Christian König Date: Tue Mar 31 17:36:57 2015 +0200 drm/radeon: add extra check in radeon_ttm_tt_unpin_userptr commit 863653fed0f449fb738295255cc834b271cfa088 upstream. We somehow try to free the SG table twice. Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=89734 Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 85bbd720e5ec6cf876bbdc2c8fd46cc4d35da70e Author: Alex Deucher Date: Wed Mar 18 17:05:10 2015 -0400 drm/radeon/dpm: fix 120hz handling harder commit 3899ca844b82fb201fb764f56eec483acb59a29c upstream. Need to expand the check to handle short circuiting if the selected state is the same as current state. bug: https://bugs.freedesktop.org/show_bug.cgi?id=87796 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit f2d95aebb650ca307749c06d8cf97a1ad358d13d Author: Ville Syrjälä Date: Fri Mar 27 19:59:40 2015 +0200 drm/i915: Reject the colorkey ioctls for primary and cursor planes commit 840a1cf0cd533f30da792527ca5ff6a023d4a727 upstream. The legcy colorkey ioctls are only implemented for sprite planes, so reject the ioctl for primary/cursor planes. If we want to support colorkeying with these planes (assuming we have hw support of course) we should just move ahead with the colorkey property conversion. Testcase: kms_legacy_colorkey Cc: Tommi Rantala Reference: http://mid.gmane.org/CA+ydwtr+bCo7LJ44JFmUkVRx144UDFgOS+aJTfK6KHtvBDVuAw@mail.gmail.com Reported-and-tested-by: Tommi Rantala Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 4b62528ff6abee768b458babacca5ae5e71c3442 Author: Jani Nikula Date: Thu Mar 26 10:42:00 2015 +0200 drm/edid: set ELD for firmware and debugfs override EDIDs commit ad692b46dbf122ef90aadce3b389ef64c90e861d upstream. If the user supplies EDID through firmware or debugfs override, the driver callbacks are bypassed and the connector ELD does not get updated, and audio fails. Set ELD for firmware and debugfs EDIDs too. There should be no harm in gratuitously doing this for non HDMI/DP connectors, as it's still up to the driver to use the ELD, if any. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82349 Reference: https://bugs.freedesktop.org/show_bug.cgi?id=80691 Reported-by: Emil Reported-by: Rob Engle Tested-by: Jolan Luff Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 687bef66a10e08deed1dd8effcb18d5d5814f74a Author: Daniel Vetter Date: Fri Feb 27 12:58:13 2015 +0100 drm: Fixup racy refcounting in plane_force_disable commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1 upstream. Originally it was impossible to be dropping the last refcount in this function since there was always one around still from the idr. But in commit 83f45fc360c8e16a330474860ebda872d1384c8c Author: Daniel Vetter Date: Wed Aug 6 09:10:18 2014 +0200 drm: Don't grab an fb reference for the idr we've switched to weak references, broke that assumption but forgot to fix it up. Since we still force-disable planes it's only possible to hit this when racing multiple rmfb with fbdev restoring or similar evil things. As long as userspace is nice it's impossible to hit the BUG_ON. But the BUG_ON would most likely be hit from fbdev code, which usually invovles the console_lock besides all modeset locks. So very likely we'd never get the bug reports if this was hit in the wild, hence better be safe than sorry and backport. Spotted by Matt Roper while reviewing other patches. [airlied: pull this back into 4.0 - the oops happens there] Cc: Matt Roper Reviewed-by: Matt Roper Signed-off-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit eb40b9cdb1626b53843b82f521e057cf572372a1 Author: Mike Snitzer Date: Mon Mar 30 13:39:09 2015 -0400 block: fix blk_stack_limits() regression due to lcm() change commit e9637415a92cf25ad800b7fdeddcd30cce7b44ab upstream. Linux 3.19 commit 69c953c ("lib/lcm.c: lcm(n,0)=lcm(0,n) is 0, not n") caused blk_stack_limits() to not properly stack queue_limits for stacked devices (e.g. DM). Fix this regression by establishing lcm_not_zero() and switching blk_stack_limits() over to using it. DM uses blk_set_stacking_limits() to establish the initial top-level queue_limits that are then built up based on underlying devices' limits using blk_stack_limits(). In the case of optimal_io_size (io_opt) blk_set_stacking_limits() establishes a default value of 0. With commit 69c953c, lcm(0, n) is no longer n, which compromises proper stacking of the underlying devices' io_opt. Test: $ modprobe scsi_debug dev_size_mb=10 num_tgts=1 opt_blks=1536 $ cat /sys/block/sde/queue/optimal_io_size 786432 $ dmsetup create node --table "0 100 linear /dev/sde 0" Before this fix: $ cat /sys/block/dm-5/queue/optimal_io_size 0 After this fix: $ cat /sys/block/dm-5/queue/optimal_io_size 786432 Signed-off-by: Mike Snitzer Acked-by: Martin K. Petersen Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit f2a756bcb4678e804a5231f6c280dfd30270d663 Author: Wenbo Wang Date: Fri Mar 20 01:04:54 2015 -0400 Fix bug in blk_rq_merge_ok commit 7ee8e4f3983c4ff700958a6099c8fd212ea67b94 upstream. Use the right array index to reference the last element of rq->biotail->bi_io_vec[] Signed-off-by: Wenbo Wang Reviewed-by: Chong Yuan Fixes: 66cb45aa41315 ("block: add support for limiting gaps in SG lists") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit f0170f1971d247f924225f5b896edb55ef8c7c5a Author: Sam Bradshaw Date: Wed Mar 18 17:06:18 2015 -0600 blkmq: Fix NULL pointer deref when all reserved tags in commit bc188d818edf325ae38cfa43254a0b10a4defd65 upstream. When allocating from the reserved tags pool, bt_get() is called with a NULL hctx. If all tags are in use, the hw queue is kicked to push out any pending IO, potentially freeing tags, and tag allocation is retried. The problem is that blk_mq_run_hw_queue() doesn't check for a NULL hctx. So we avoid it with a simple NULL hctx test. Tested by hammering mtip32xx with concurrent smartctl/hdparm. Signed-off-by: Sam Bradshaw Signed-off-by: Selvan Mani Fixes: b32232073e80 ("blk-mq: fix hang in bt_get()") Added appropriate comment. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e008be66e703bd64b6cf4d1ec1f19e4cb99d3dd6 Author: Mike Snitzer Date: Thu Mar 12 23:53:26 2015 -0400 blk-mq: fix use of incorrect goto label in blk_mq_init_queue error path commit 9a30b096b543932de218dd3501b5562e00a8792d upstream. If percpu_ref_init() fails the allocated q and hctxs must get cleaned up; using 'err_map' doesn't allow that to happen. Signed-off-by: Mike Snitzer Reviewed-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 630146a4fd63ff241f75ece369784fe6133964a2 Author: Joe Perches Date: Mon Mar 23 18:01:35 2015 -0700 selinux: fix sel_write_enforce broken return value commit 6436a123a147db51a0b06024a8350f4c230e73ff upstream. Return a negative error value like the rest of the entries in this function. Signed-off-by: Joe Perches Acked-by: Stephen Smalley [PM: tweaked subject line] Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 6a6a4631aa3fa4ec66dd8898930a4f05e024dcb5 Author: Chen-Yu Tsai Date: Mon Feb 9 18:23:20 2015 +0800 ARM: sunxi: Have ARCH_SUNXI select RESET_CONTROLLER for clock driver usage commit fdc0074c5fc8c7adb8186cbb123fe2082d9bd05f upstream. As the sunxi usb clocks all contain a reset controller, it is not possible to build the sunxi clock driver without RESET_CONTROLLER enabled. Doing so results in an undefined symbol error: drivers/built-in.o: In function `sunxi_gates_clk_setup': linux/drivers/clk/sunxi/clk-sunxi.c:1071: undefined reference to `reset_controller_register' This is possible if building a minimal kernel without PHY_SUN4I_USB. The dependency issue is made visible at compile time instead of link time by the new A80 mmc clocks, which also use a reset control itself. This patch makes ARCH_SUNXI select ARCH_HAS_RESET_CONTROLLER and RESET_CONTROLLER. Fixes: 559482d1f950 ARM: sunxi: Split the various SoCs support in Kconfig Reported-by: Lourens Rozema Acked-by: Arnd Bergmann Signed-off-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Signed-off-by: Greg Kroah-Hartman commit b3a1f887ac6db0bde39417b11ec86f7c7ed9a5f6 Author: Vineet Gupta Date: Thu Mar 26 11:14:41 2015 +0530 ARC: signal handling robustify commit e4140819dadc3624accac8294881bca8a3cba4ed upstream. A malicious signal handler / restorer can DOS the system by fudging the user regs saved on stack, causing weird things such as sigreturn returning to user mode PC but cpu state still being kernel mode.... Ensure that in sigreturn path status32 always has U bit; any other bogosity (gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms. Reproducer signal handler: void handle_sig(int signo, siginfo_t *info, void *context) { ucontext_t *uc = context; struct user_regs_struct *regs = &(uc->uc_mcontext.regs); regs->scratch.status32 = 0; } Before the fix, kernel would go off to weeds like below: --------->8----------- [ARCLinux]$ ./signal-test Path: /signal-test CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65 task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000 [ECR ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698 [EFA ]: 0x00000010 [BLINK ]: 0x2007c1ee [ERET ]: 0x10698 [STAT32]: 0x00000000 : <-------- BTA: 0x00010680 SP: 0x5ffe7e48 FP: 0x00000000 LPS: 0x20003c6c LPE: 0x20003c70 LPC: 0x00000000 ... --------->8----------- Reported-by: Alexey Brodkin Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit 4538372f57d56ac54e5c149880c9b854458d3566 Author: Vineet Gupta Date: Thu Mar 26 09:25:44 2015 +0530 ARC: SA_SIGINFO ucontext regs off-by-one commit 6914e1e3f63caa829431160f0f7093292daef2d5 upstream. The regfile provided to SA_SIGINFO signal handler as ucontext was off by one due to pt_regs gutter cleanups in 2013. Before handling signal, user pt_regs are copied onto user_regs_struct and copied back later. Both structs are binary compatible. This was all fine until commit 2fa919045b72 (ARC: pt_regs update #2) which removed the empty stack slot at top of pt_regs (corresponding to first pad) and made the corresponding fixup in struct user_regs_struct (the pad in there was moved out of @scratch - not removed altogether as it is part of ptrace ABI) struct user_regs_struct { + long pad; struct { - long pad; long bta, lp_start, lp_end,.... } scratch; ... } This meant that now user_regs_struct was off by 1 reg w.r.t pt_regs and signal code needs to user_regs_struct.scratch to reflect it as pt_regs, which is what this commit does. This problem was hidden for 2 years, because both save/restore, despite using wrong location, were using the same location. Only an interim inspection (reproducer below) exposed the issue. void handle_segv(int signo, siginfo_t *info, void *context) { ucontext_t *uc = context; struct user_regs_struct *regs = &(uc->uc_mcontext.regs); printf("regs %x %x\n", <=== prints 7 8 (vs. 8 9) regs->scratch.r8, regs->scratch.r9); } int main() { struct sigaction sa; sa.sa_sigaction = handle_segv; sa.sa_flags = SA_SIGINFO; sigemptyset(&sa.sa_mask); sigaction(SIGSEGV, &sa, NULL); asm volatile( "mov r7, 7 \n" "mov r8, 8 \n" "mov r9, 9 \n" "mov r10, 10 \n" :::"r7","r8","r9","r10"); *((unsigned int*)0x10) = 0; } Fixes: 2fa919045b72ec892e "ARC: pt_regs update #2: Remove unused gutter at start of pt_regs" Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit 9911f100e690c5684aad0a6bbc334610ea21a63d Author: Matwey V. Kornilov Date: Thu Feb 19 20:41:48 2015 +0300 PCI: spear: Drop __initdata from spear13xx_pcie_driver commit a43f32d647273023edddb0dc8f91c4c6378b252b upstream. Struct spear13xx_pcie_driver was in initdata, but we passed a pointer to it to platform_driver_register(), which can use the pointer at arbitrary times in the future, even after the initdata is freed. That leads to crashes. Move spear13xx_pcie_driver and things referenced by it (spear13xx_pcie_probe() and dw_pcie_host_init()) out of initdata. [bhelgaas: changelog] Fixes: 6675ef212dac ("PCI: spear: Fix Section mismatch compilation warning for probe()") Signed-off-by: Matwey V. Kornilov Signed-off-by: Bjorn Helgaas Acked-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit d771c22315f4fa319a3dc108d02b86c9597c6757 Author: Bjorn Helgaas Date: Tue Mar 24 11:12:45 2015 -0500 PCI: Don't look for ACPI hotplug parameters if ACPI is disabled commit 8647ca9ad5a0065ad53a2ad7e39163592b6ed35e upstream. Booting a v3.18 or newer Xen domU kernel with PCI devices passed through results in an oops (this is a 32-bit 3.13.11 dom0 with a 64-bit 4.4.0 hypervisor and 32-bit domU): BUG: unable to handle kernel paging request at 0030303e IP: [] acpi_ns_validate_handle+0x12/0x1a Call Trace: [] ? acpi_evaluate_object+0x31/0x1fc [] ? pci_get_hp_params+0x111/0x4e0 [] ? xen_force_evtchn_callback+0x17/0x30 [] ? xen_restore_fl_direct_reloc+0x4/0x4 [] ? pci_device_add+0x24/0x450 Don't look for ACPI configuration information if ACPI has been disabled. I don't think this is the best fix, because we can boot plain Linux (no Xen) with "acpi=off", and we don't need this check in pci_get_hp_params(). There should be a better fix that would make Xen domU work the same way. The domU kernel has ACPI support but it has no AML. There should be a way to initialize the ACPI data structures so things fail gracefully rather than oopsing. This is an interim fix to address the regression. Fixes: 6cd33649fa83 ("PCI: Add pci_configure_device() during enumeration") Link: https://bugzilla.kernel.org/show_bug.cgi?id=96301 Reported-by: Michael D Labriola Tested-by: Michael D Labriola Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 701083ba443e3b58514293730f6088077bca998c Author: Bjorn Helgaas Date: Wed Apr 8 10:04:55 2015 -0500 Revert "sparc/PCI: Clip bridge windows to fit in upstream windows" commit d10b730f97a7f1fa58c9ec300828f87157cd6b95 upstream. This reverts commit d63e2e1f3df904bf6bd150bdafb42ddbb3257ea8. David Ahern reported that d63e2e1f3df9 breaks booting on an 8-socket T5 sparc system. He also verified that the system boots with d63e2e1f3df9 reverted. Yinghai has some fixes, but they need a little more polishing than we can do before v4.0. Link: http://lkml.kernel.org/r/5514391F.2030300@oracle.com # report Link: http://lkml.kernel.org/r/1427857069-6789-1-git-send-email-yinghai@kernel.org # patches Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit effe0487bf00d610a536e7beb6f5f4efda28ee10 Author: Dan Carpenter Date: Wed Feb 25 16:23:22 2015 +0300 PCI: cpcihp: Add missing curly braces in cpci_configure_slot() commit bc3b5b47c80da8838758731d423179262c9c36ec upstream. I don't have this hardware but it looks like we weren't adding bridge devices as intended. Maybe the bridge is always the last device? Fixes: 05b125004815 ("PCI: cpcihp: Iterate over all devices in slot, not functions 0-7") Signed-off-by: Dan Carpenter Signed-off-by: Bjorn Helgaas Acked-by: Yijing Wang Signed-off-by: Greg Kroah-Hartman commit 8dcbd92fbb1a0ab7e897f611112f912649d15b64 Author: Rasmus Villemoes Date: Thu Feb 26 09:55:03 2015 +0100 PCI/AER: Avoid info leak in __print_tlp_header() commit a1b7f2f6367944d445c6853035830a35c6343939 upstream. Commit fab4c256a58b ("PCI/AER: Add a TLP header print helper") introduced the helper function __print_tlp_header(), but contrary to the intention, the behaviour did change: Since we're taking the address of the parameter t, the first 4 or 8 bytes printed will be the value of the pointer t itself, and the remaining 12 or 8 bytes will be who-knows-what (something from the stack). We want to show the values of the four members of the struct aer_header_log_regs; that can be done without ugly and error-prone casts. On little-endian this should produce the same output as originally intended, and since no-one has complained about getting garbage output so far, I think big-endian should be ok too. Fixes: fab4c256a58b ("PCI/AER: Add a TLP header print helper") Signed-off-by: Rasmus Villemoes Signed-off-by: Bjorn Helgaas Acked-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit 9275ab868b321af9bc9182ea5e392c7d573c0aec Author: Takashi Iwai Date: Wed Apr 8 20:47:55 2015 +0200 ALSA: hda - Fix headphone pin config for Lifebook T731 commit cc7016ab1a22fb26f388c2fb2b692b89897cbc3e upstream. Some BIOS version of Fujitsu Lifebook T731 seems to set up the headphone pin (0x21) without the assoc number 0x0f while it's set only to the output on the docking port (0x1a). With the recent commit [03ad6a8c93b6: ALSA: hda - Fix "PCM" name being used on one DAC when there are two DACs], this resulted in the weird mixer element mapping where the headphone on the laptop is assigned as a shared volume with the speaker and the docking port is assigned as an individual headphone. This patch improves the situation by correcting the headphone pin config to the more appropriate value. Reported-and-tested-by: Taylor Smock Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c2393a6365ab01913eb89aef3f88b3110ad79860 Author: Kailang Yang Date: Wed Apr 8 16:34:00 2015 +0800 ALSA: hda/realtek - Make more stable to get pin sense for ALC283 commit a59d7199f62b8336570972dcc288321d0ec999fe upstream. Pin sense will active when power pin is wake up. Power pin will not wake up immediately during resume state. Add some delay to wait for power pin activated. Signed-off-by: Kailang Yang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1b0992fcc81e6badca596863e58d37f63e322cb7 Author: Takashi Sakamoto Date: Thu Apr 9 01:15:03 2015 +0900 ALSA: bebob: fix to processing in big-endian machine for sending cue commit a053fc318bc5d28cd25168c948255fd48a29ea26 upstream. Some M-Audio devices require to receive bootup command just after powering on, while codes in BeBoB driver doesn't work properly in big-endian machine because the command should be aligned by little-endian. This commit fixes this bug. This fix should go to stable kernel. Cc: Takayuki Shiroma Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7c9dd3bf65adbc60613364b3f6a2110b75ae720a Author: Dmitry M. Fedin Date: Thu Apr 9 17:37:03 2015 +0300 ALSA: usb - Creative USB X-Fi Pro SB1095 volume knob support commit 3dc8523fa7412e731441c01fb33f003eb3cfece1 upstream. Adds an entry for Creative USB X-Fi to the rc_config array in mixer_quirks.c to allow use of volume knob on the device. Adds support for newer X-Fi Pro card, known as "Model No. SB1095" with USB ID "041e:3237" Signed-off-by: Dmitry M. Fedin Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 78484c327e98a1ad5f773b26b7a69fe541aa0252 Author: Hui Wang Date: Thu Mar 26 17:14:55 2015 +0800 ALSA: hda - Add one more node in the EAPD supporting candidate list commit af95b41426e0b58279f8ff0ebe420df49a4e96b8 upstream. We have a HP machine which use the codec node 0x17 connecting the internal speaker, and from the node capability, we saw the EAPD, if we don't set the EAPD on for this node, the internal speaker can't output any sound. BugLink: https://bugs.launchpad.net/bugs/1436745 Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3b9416495eb97b1471fab75c6586d8074a9d238c Author: Sebastian Wicki Date: Mon Mar 23 17:23:11 2015 +0100 ALSA: hda - Add dock support for Thinkpad T450s (17aa:5036) commit 80b311d3118842eb681397233faa0d588df13f92 upstream. This model uses the same dock port as the previous generation. Signed-off-by: Sebastian Wicki Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman