commit 4250b32591fa333087dbecda0aa079cd88c5a640 Author: Greg Kroah-Hartman Date: Thu Jul 17 16:23:31 2014 -0700 Linux 3.15.6 commit a1e268371e4d454b6c314dfbf8c16f01b59ca7ed Author: Lan Tianyu Date: Mon Jul 7 15:47:12 2014 +0800 ACPI / battery: Retry to get battery information if failed during probing commit 75646e758a0ecbed5024454507d5be5b9ea9dcbf upstream. Some machines (eg. Lenovo Z480) ECs are not stable during boot up and causes battery driver fails to be loaded due to failure of getting battery information from EC sometimes. After several retries, the operation will work. This patch is to retry to get battery information 5 times if the first try fails. [ backport to 3.14.5: removed second parameter in acpi_battery_update(), introduced by the commit 9e50bc14a7f58b5d8a55973b2d69355852ae2dae (ACPI / battery: Accelerate battery resume callback)] [naszar : backport to 3.14.5] Link: https://bugzilla.kernel.org/show_bug.cgi?id=75581 Reported-and-tested-by: naszar Cc: All applicable Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 033c935f3084db4f8c8bb5bac84a6f6fdb39ea68 Author: Roland Dreier Date: Fri May 2 11:18:41 2014 -0700 x86, ioremap: Speed up check for RAM pages commit c81c8a1eeede61e92a15103748c23d100880cc8a upstream. In __ioremap_caller() (the guts of ioremap), we loop over the range of pfns being remapped and checks each one individually with page_is_ram(). For large ioremaps, this can be very slow. For example, we have a device with a 256 GiB PCI BAR, and ioremapping this BAR can take 20+ seconds -- sometimes long enough to trigger the soft lockup detector! Internally, page_is_ram() calls walk_system_ram_range() on a single page. Instead, we can make a single call to walk_system_ram_range() from __ioremap_caller(), and do our further checks only for any RAM pages that we find. For the common case of MMIO, this saves an enormous amount of work, since the range being ioremapped doesn't intersect system RAM at all. With this change, ioremap on our 256 GiB BAR takes less than 1 second. Signed-off-by: Roland Dreier Link: http://lkml.kernel.org/r/1399054721-1331-1-git-send-email-roland@kernel.org Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 9d7e845beffc3a25e139f6c7314555c0bed18448 Author: Guenter Roeck Date: Mon Jun 30 11:45:30 2014 -0700 powerpc: Disable RELOCATABLE for COMPILE_TEST with PPC64 commit fb43e8477ed9006c4f397f904c691a120503038c upstream. powerpc:allmodconfig has been failing for some time with the following error. arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 A number of attempts to fix the problem by moving around code have been unsuccessful and resulted in failed builds for some configurations and the discovery of toolchain bugs. Fix the problem by disabling RELOCATABLE for COMPILE_TEST builds instead. While this is less than perfect, it avoids substantial code changes which would otherwise be necessary just to make COMPILE_TEST builds happy and might have undesired side effects. Signed-off-by: Guenter Roeck Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit c7afbd8efaa726b7469852c0be8654a8dad7bdf7 Author: Chen Gang Date: Sat May 3 13:07:57 2014 +0800 drivers/rtc/rtc-puv3.c: use dev_dbg() instead of dev_debug() for typo issue commit c863810cefc7ffd782e5648a21bfb36a32c8b081 upstream. It is only a typo issue, the related commit: "1fbc4c4 drivers/rtc/rtc-puv3.c: use dev_dbg() instead of pr_debug()" The related error (unicore32 with allmodconfig): CC [M] drivers/rtc/rtc-puv3.o drivers/rtc/rtc-puv3.c: In function 'puv3_rtc_setpie': drivers/rtc/rtc-puv3.c:74: error: implicit declaration of function 'dev_debug' Signed-off-by: Chen Gang Acked-by: Xuetao Guan Signed-off-by: Xuetao Guan Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit a50c9148a63c7322ef5cd14dd781841154461fb0 Author: Chen Gang Date: Sat May 3 13:09:02 2014 +0800 drivers/rtc/rtc-puv3.c: remove "&dev->" for typo issue commit 73fa540618d8b1f8c2266934f23bd84bb9e28d9e upstream. It is only a typo issue, the related commit: "1fbc4c4 drivers/rtc/rtc-puv3.c: use dev_dbg() instead of pr_debug()" The related error (for unicore32 with allmodconfig): CC [M] drivers/rtc/rtc-puv3.o drivers/rtc/rtc-puv3.c: In function 'puv3_rtc_setalarm': drivers/rtc/rtc-puv3.c:143: error: 'struct device' has no member named 'dev' Signed-off-by: Chen Gang Acked-by: Xuetao Guan Signed-off-by: Xuetao Guan Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 3c9979727fa77a3a08eae5938d1ac0e4568d5997 Author: Jaegeuk Kim Date: Sat Jun 28 01:00:41 2014 +0900 f2fs: check bdi->dirty_exceeded when trying to skip data writes commit 2743f865543c0c4a5e12fc13edb2bf89a6e9687c upstream. If we don't check the current backing device status, balance_dirty_pages can fall into infinite pausing routine. This can be occurred when a lot of directories make a small number of dirty dentry pages including files. Reported-by: Brian Chadwick Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 43efa53d4ece1bee219320ce8451a5a211188375 Author: Jaegeuk Kim Date: Wed Apr 16 10:47:06 2014 +0900 f2fs: adjust free mem size to flush dentry blocks commit 6fb03f3a40805a412c9b285010ffdc2e7563f81b upstream. If so many dirty dentry blocks are cached, not reached to the flush condition, we should fall into livelock in balance_dirty_pages. So, let's consider the mem size for the condition. Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 3fa0637a2a027db4a0d31314b0e9e6bd5526bb17 Author: Li Zefan Date: Mon Jun 30 11:50:59 2014 +0800 cgroup: fix a race between cgroup_mount() and cgroup_kill_sb() commit 3a32bd72d77058d768dbb38183ad517f720dd1bc upstream. We've converted cgroup to kernfs so cgroup won't be intertwined with vfs objects and locking, but there are dark areas. Run two instances of this script concurrently: for ((; ;)) { mount -t cgroup -o cpuacct xxx /cgroup umount /cgroup } After a while, I saw two mount processes were stuck at retrying, because they were waiting for a subsystem to become free, but the root associated with this subsystem never got freed. This can happen, if thread A is in the process of killing superblock but hasn't called percpu_ref_kill(), and at this time thread B is mounting the same cgroup root and finds the root in the root list and performs percpu_ref_try_get(). To fix this, we try to increase both the refcnt of the superblock and the percpu refcnt of cgroup root. v2: - we should try to get both the superblock refcnt and cgroup_root refcnt, because cgroup_root may have no superblock assosiated with it. - adjust/add comments. tj: Updated comments. Renamed @sb to @pinned_sb. Signed-off-by: Li Zefan Signed-off-by: Tejun Heo [lizf: Backported to 3.15: - Adjust context - s/percpu_tryget_live/atomic_inc_not_zero/] Signed-off-by: Greg Kroah-Hartman commit f5fc1ec5e8d32bfb559a87800633b0a82a37e640 Author: Li Zefan Date: Mon Jun 30 11:50:28 2014 +0800 kernfs: introduce kernfs_pin_sb() commit 4e26445faad366d67d7723622bf6a60a6f0f5993 upstream. kernfs_pin_sb() tries to get a refcnt of the superblock. This will be used by cgroupfs. v2: - make kernfs_pin_sb() return the superblock. - drop kernfs_drop_sb(). tj: Updated the comment a bit. [ This is a prerequisite for a bugfix. ] Acked-by: Greg Kroah-Hartman Signed-off-by: Li Zefan Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 0b2332fbef1df5db5ed85fb1812aca9d50aa6415 Author: Tejun Heo Date: Wed Apr 9 11:07:30 2014 -0400 kernfs: implement kernfs_root->supers list commit 7d568a8383bbb9c1f5167781075906acb2bb1550 upstream. Currently, there's no way to find out which super_blocks are associated with a given kernfs_root. Let's implement it - the planned inotify extension to kernfs_notify() needs it. Make kernfs_super_info point back to the super_block and chain it at kernfs_root->supers. Signed-off-by: Tejun Heo [lizf: Backported to 3.15: Adjust context] Signed-off-by: Li Zefan Signed-off-by: Greg Kroah-Hartman commit f1a6b5ddc318c0722e70715ef3a53e53981d606c Author: Li Zefan Date: Mon Jun 30 11:49:58 2014 +0800 cgroup: fix mount failure in a corner case commit 970317aa48c6ef66cd023c039c2650c897bad927 upstream. # cat test.sh #! /bin/bash mount -t cgroup -o cpu xxx /cgroup umount /cgroup mount -t cgroup -o cpu,cpuacct xxx /cgroup umount /cgroup # ./test.sh mount: xxx already mounted or /cgroup busy mount: according to mtab, xxx is already mounted on /cgroup It's because the cgroupfs_root of the first mount was under destruction asynchronously. Fix this by delaying and then retrying mount for this case. v3: - put the refcnt immediately after getting it. (Tejun) v2: - use percpu_ref_tryget_live() rather that introducing percpu_ref_alive(). (Tejun) - adjust comment. tj: Updated the comment a bit. Signed-off-by: Li Zefan Signed-off-by: Tejun Heo [lizf: Backported to 3.15: - s/percpu_ref_tryget_live/atomic_inc_not_zero/ - Use goto instead of calling restart_syscall() - Add cgroup_tree_mutex] Signed-off-by: Greg Kroah-Hartman commit 7a072684fbe6d8be0156109ed2954a36d42e53c4 Author: Ted Juan Date: Wed May 28 22:33:06 2014 +0800 mtd: nand: omap: fix omap_calculate_ecc_bch() for-loop error commit 2913aae5f9eae2f857cdeff5388bb22d0751aa08 upstream. Fixes: 2c9f2365d1e1d0e318b068f683f18c99515b80f8 mtd: nand: omap: ecc.calculate: merge omap3_calculate_ecc_bch4 in omap_calculate_ecc_bch Fixes: 7bcd1dca1d587ad29f9825ba4414620440e8c8da mtd: nand: omap: ecc.calculate: merge omap3_calculate_ecc_bch8 in omap_calculate_ecc_bch Signed-off-by: Ted Juan Acked-by: Pekon Gupta Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit d38aa2e6b4ce857b06725b405db19938e594393f Author: Jean Sacren Date: Thu May 1 14:31:18 2014 +0000 i40e: fix passing wrong error code to i40e_open() commit ce9ccb17ef5b5088172f46dd246c92523fd3a524 upstream. The commit 6c167f582ea9 ("i40e: Refactor and cleanup i40e_open(), adding i40e_vsi_open()") introduced a new function i40e_vsi_open() with the regression by a typo. Due to the commit, the wrong error code would be passed to i40e_open(). Fix this error in i40e_vsi_open() by turning the macro into a negative value so that i40e_open() could return the pertinent error code correctly. Fixes: 6c167f582ea9 ("i40e: Refactor and cleanup i40e_open(), adding i40e_vsi_open()") Signed-off-by: Jean Sacren Tested-by: Kavindya Deegala Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit ae2fbe4ff3f3368325629d884fe0d53f23d8f8be Author: Steven Rostedt (Red Hat) Date: Tue Jun 10 09:46:00 2014 -0400 ring-buffer: Check if buffer exists before polling commit 8b8b36834d0fff67fc8668093f4312dd04dcf21d upstream. The per_cpu buffers are created one per possible CPU. But these do not mean that those CPUs are online, nor do they even exist. With the addition of the ring buffer polling, it assumes that the caller polls on an existing buffer. But this is not the case if the user reads trace_pipe from a CPU that does not exist, and this causes the kernel to crash. Simple fix is to check the cpu against buffer bitmask against to see if the buffer was allocated or not and return -ENODEV if it is not. More updates were done to pass the -ENODEV back up to userspace. Link: http://lkml.kernel.org/r/5393DB61.6060707@oracle.com Reported-by: Sasha Levin Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 47c442659ccd7811cbd529f9386613b1f818e2a7 Author: Joonsoo Kim Date: Mon Jun 23 13:22:07 2014 -0700 DMA, CMA: fix possible memory leak commit fe8eea4f4a3f299ef83ed090d5354698ebe4fda8 upstream. We should free memory for bitmap when we find zone mismatch, otherwise this memory will leak. Additionally, I copy code comment from PPC KVM's CMA code to inform why we need to check zone mis-match. Signed-off-by: Joonsoo Kim Acked-by: Zhang Yanfei Reviewed-by: Michal Nazarewicz Reviewed-by: Aneesh Kumar K.V Acked-by: Minchan Kim Cc: "Aneesh Kumar K.V" Cc: Marek Szyprowski Cc: Michal Nazarewicz Cc: Paolo Bonzini Cc: Gleb Natapov Cc: Alexander Graf Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 65252fb777e848282f2eb34e81e47aba34555dfb Author: Ville Syrjälä Date: Thu Jun 5 20:02:59 2014 +0300 drm/i915: Don't clobber the GTT when it's within stolen memory commit f1e1c2129b79cfdaf07bca37c5a10569fe021abe upstream. On most gen2-4 platforms the GTT can be (or maybe always is?) inside the stolen memory region. If that's the case, reduce the size of the stolen memory appropriately to make make sure we don't clobber the GTT. v2: Deal with gen4 36 bit physical address Signed-off-by: Ville Syrjälä Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80151 Acked-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 7b4d4c016fbdbc7a80e451e4cdc74797419d5c61 Author: Scot Doyle Date: Thu Jul 3 23:27:52 2014 +0000 drm/i915: Toshiba CB35 has a controllable backlight commit d4967d8c6d4f52623f2be8eaff0b445dc5863c92 upstream. The Toshiba CB35 Chromebook (with Celeron 2955U CPU) has a controllable backlight although its VBT reports otherwise. Apply quirk to ignore the backlight presence check during backlight setup. Patch tested by author on Toshiba CB35. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813 Signed-off-by: Scot Doyle CC: Jani Nikula Signed-off-by: Jani Nikula [danvet: Add cc: stable because the regressing commit is in 3.15.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 31b66c21cde8100f2ae64600c66bf58c8f5b5d5d Author: Scot Doyle Date: Thu Jul 3 23:27:51 2014 +0000 drm/i915: Acer C720 and C720P have controllable backlights commit 2e93a1aa9ca455aa3ad0294bcd6d66f38bf8b758 upstream. The Acer C720 and C720P Chromebooks (with Celeron 2955U CPU) have a controllable backlight although their VBT reports otherwise. Apply quirk to ignore the backlight presence check during backlight setup. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813 Tested-by: James Duley Tested-by: Michael Mullin Signed-off-by: Scot Doyle CC: Jani Nikula Signed-off-by: Jani Nikula [danvet: Add cc: stable because the regressing commit is in 3.15.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 5cdcf7536f2e4db274fc202f9d25a34e28df3c51 Author: Scot Doyle Date: Thu Jul 3 23:27:50 2014 +0000 drm/i915: quirk asserts controllable backlight presence, overriding VBT commit 9c72cc6f00d24711ef585772396dd1ae180881a6 upstream. commit c675949ec58ca50d5a3ae3c757892f1560f6e896 Author: Jani Nikula Date: Wed Apr 9 11:31:37 2014 +0300 drm/i915: do not setup backlight if not available according to VBT caused a regression on machines with a misconfigured VBT. Add a quirk to assert the presence of a controllable backlight. Use it to ignore the VBT backlight presence check during backlight setup. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813 Tested-by: James Duley Tested-by: Michael Mullin Reviewed-by: Jani Nikula Signed-off-by: Scot Doyle Signed-off-by: Jani Nikula [danvet: Add cc: stable because the regressing commit is in 3.15.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit bef3c4fb49f458f911ecf73cb00dbbade831d671 Author: Christian König Date: Wed Jun 4 15:29:56 2014 +0200 drm/radeon: stop poisoning the GART TLB commit 0986c1a55ca64b44ee126a2f719a6e9f28cbe0ed upstream. When we set the valid bit on invalid GART entries they are loaded into the TLB when an adjacent entry is loaded. This poisons the TLB with invalid entries which are sometimes not correctly removed on TLB flush. For stable inclusion the patch probably needs to be modified a bit. Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit a7bf949883de441a96efa1b5e9754e005eae3b1e Author: Christian König Date: Wed Jul 2 21:28:10 2014 +0200 drm/radeon: page table BOs are kernel allocations commit 7dae77f8809a81b0dc5195debae8fd78cbbcc550 upstream. Userspace shouldn't be able to access them. Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 73ea68288d9143574097dc397559087f3ac4efbe Author: Alex Deucher Date: Mon Jul 7 17:59:37 2014 -0400 drm/radeon: fix typo in golden register setup on evergreen commit 6abafb78f9881b4891baf74ab4e9f090ae45230e upstream. Fixes hangs on driver load on some cards. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76998 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit cd3299ff53b3edad5f4725771c5d8b9d9ec2b633 Author: Alex Deucher Date: Tue Jul 8 18:25:25 2014 -0400 drm/radeon: fix typo in ci_stop_dpm() commit ed96377132e564d797c48a5490fd46bed01c4273 upstream. Need to use the RREG32_SMC() accessor since the register is an smc indirect index. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 4579eade4e21aefc83e7f36e44ac7a31bcd667d6 Author: Alexandre Demers Date: Tue Jul 8 22:27:36 2014 -0400 drm/radeon/dpm: Reenabling SS on Cayman commit 41959341ac7e33dd360c7a881d13566f9eca37b2 upstream. It reverts commit c745fe611ca42295c9d91d8e305d27983e9132ef now that Cayman is stable since VDDCI fix. Spread spectrum was not the culprit. This depends on b0880e87c1fd038b84498944f52e52c3e86ebe59 (drm/radeon/dpm: fix vddci setup typo on cayman). Signed-off-by: Alexandre Demers Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit da17d1e04ff63429b90e5df483fdd70e32d3f968 Author: Theodore Ts'o Date: Sat Jul 12 15:32:24 2014 -0400 ext4: fix a potential deadlock in __ext4_es_shrink() commit 3f1f9b851311a76226140b55b1ea22111234a7c2 upstream. This fixes the following lockdep complaint: [ INFO: possible circular locking dependency detected ] 3.16.0-rc2-mm1+ #7 Tainted: G O ------------------------------------------------------- kworker/u24:0/4356 is trying to acquire lock: (&(&sbi->s_es_lru_lock)->rlock){+.+.-.}, at: [] __ext4_es_shrink+0x4f/0x2e0 but task is already holding lock: (&ei->i_es_lock){++++-.}, at: [] ext4_es_insert_extent+0x71/0x180 which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ei->i_es_lock); lock(&(&sbi->s_es_lru_lock)->rlock); lock(&ei->i_es_lock); lock(&(&sbi->s_es_lru_lock)->rlock); *** DEADLOCK *** 6 locks held by kworker/u24:0/4356: #0: ("writeback"){.+.+.+}, at: [] process_one_work+0x180/0x560 #1: ((&(&wb->dwork)->work)){+.+.+.}, at: [] process_one_work+0x180/0x560 #2: (&type->s_umount_key#22){++++++}, at: [] grab_super_passive+0x44/0x90 #3: (jbd2_handle){+.+...}, at: [] start_this_handle+0x189/0x5f0 #4: (&ei->i_data_sem){++++..}, at: [] ext4_map_blocks+0x132/0x550 #5: (&ei->i_es_lock){++++-.}, at: [] ext4_es_insert_extent+0x71/0x180 stack backtrace: CPU: 0 PID: 4356 Comm: kworker/u24:0 Tainted: G O 3.16.0-rc2-mm1+ #7 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: writeback bdi_writeback_workfn (flush-253:0) ffffffff8213dce0 ffff880014b07538 ffffffff815df0bb 0000000000000007 ffffffff8213e040 ffff880014b07588 ffffffff815db3dd ffff880014b07568 ffff880014b07610 ffff88003b868930 ffff88003b868908 ffff88003b868930 Call Trace: [] dump_stack+0x4e/0x68 [] print_circular_bug+0x1fb/0x20c [] __lock_acquire+0x163e/0x1d00 [] ? retint_restore_args+0xe/0xe [] ? __slab_alloc+0x4a8/0x4ce [] ? __ext4_es_shrink+0x4f/0x2e0 [] lock_acquire+0x87/0x120 [] ? __ext4_es_shrink+0x4f/0x2e0 [] ? ext4_es_free_extent+0x5d/0x70 [] _raw_spin_lock+0x39/0x50 [] ? __ext4_es_shrink+0x4f/0x2e0 [] ? kmem_cache_alloc+0x18b/0x1a0 [] __ext4_es_shrink+0x4f/0x2e0 [] ext4_es_insert_extent+0xc8/0x180 [] ext4_map_blocks+0x1c4/0x550 [] ext4_writepages+0x6d4/0xd00 ... Reported-by: Minchan Kim Signed-off-by: Theodore Ts'o Reported-by: Minchan Kim Cc: Zheng Liu Signed-off-by: Greg Kroah-Hartman commit 9a87ea37bc551c2aecf978b55f8a78f71b7b80da Author: Theodore Ts'o Date: Fri Jul 11 13:55:40 2014 -0400 ext4: revert commit which was causing fs corruption after journal replays commit f9ae9cf5d72b3926ca48ea60e15bdbb840f42372 upstream. Commit 007649375f6af2 ("ext4: initialize multi-block allocator before checking block descriptors") causes the block group descriptor's count of the number of free blocks to become inconsistent with the number of free blocks in the allocation bitmap. This is a harmless form of fs corruption, but it causes the kernel to potentially remount the file system read-only, or to panic, depending on the file systems's error behavior. Thanks to Eric Whitney for his tireless work to reproduce and to find the guilty commit. Fixes: 007649375f6af2 ("ext4: initialize multi-block allocator before checking block descriptors" Reported-by: David Jander Reported-by: Matteo Croce Tested-by: Eric Whitney Suggested-by: Eric Whitney Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 480edc9475b340e0ff9077e3ef8f3e7e0be23196 Author: Eric Sandeen Date: Sat Jul 5 19:18:22 2014 -0400 ext4: disable synchronous transaction batching if max_batch_time==0 commit 5dd214248f94d430d70e9230bda72f2654ac88a8 upstream. The mount manpage says of the max_batch_time option, This optimization can be turned off entirely by setting max_batch_time to 0. But the code doesn't do that. So fix the code to do that. Signed-off-by: Eric Sandeen Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit de10aa240c6115c8a8f9889412cea6d4f63b863e Author: Theodore Ts'o Date: Sat Jul 5 19:15:50 2014 -0400 ext4: clarify ext4_error message in ext4_mb_generate_buddy_error() commit 94d4c066a4ff170a2671b1a9b153febbf36796f6 upstream. We are spending a lot of time explaining to users what this error means. Let's try to improve the message to avoid this problem. Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit fe412959098d4292db0ab215ef3dfb22ae4ec621 Author: Theodore Ts'o Date: Sat Jul 5 18:40:52 2014 -0400 ext4: clarify error count warning messages commit ae0f78de2c43b6fadd007c231a352b13b5be8ed2 upstream. Make it clear that values printed are times, and that it is error since last fsck. Also add note about fsck version required. Signed-off-by: Pavel Machek Signed-off-by: Theodore Ts'o Reviewed-by: Andreas Dilger Signed-off-by: Greg Kroah-Hartman commit 4dc3dd7aceb3d77d14ee798dbf3afde357e4bdb0 Author: Theodore Ts'o Date: Sat Jul 5 16:28:35 2014 -0400 ext4: fix unjournalled bg descriptor while initializing inode bitmap commit 61c219f5814277ecb71d64cb30297028d6665979 upstream. The first time that we allocate from an uninitialized inode allocation bitmap, if the block allocation bitmap is also uninitalized, we need to get write access to the block group descriptor before we start modifying the block group descriptor flags and updating the free block count, etc. Otherwise, there is the potential of a bad journal checksum (if journal checksums are enabled), and of the file system becoming inconsistent if we crash at exactly the wrong time. Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 390cb9cac7aa522386f66edd034720c3a65bcd82 Author: Alex Williamson Date: Tue Jun 17 15:40:13 2014 -0600 PCI: Fix unaligned access in AF transaction pending test commit d066c946a866268c14a120b33e7226e899981998 upstream. pci_wait_for_pending() uses word access, so we shouldn't be passing an offset that is only byte aligned. Use the control register offset instead, shifting the mask to match. Fixes: d0b4cc4e3270 ("PCI: Wrong register used to check pending traffic") Fixes: 157e876ffe0b ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction()) Reported-by: Ben Hutchings Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas Acked-by: Gavin Shan Signed-off-by: Greg Kroah-Hartman commit 1663463de7393253b520dc4351d6d89f0e123b26 Author: Vincent Minet Date: Sat Jul 5 01:51:33 2014 +0200 intel_pstate: Set CPU number before accessing MSRs commit 179e8471673ce0249cd4ecda796008f7757e5bad upstream. Ensure that cpu->cpu is set before writing MSR_IA32_PERF_CTL during CPU initialization. Otherwise only cpu0 has its P-state set and all other cores are left with their values unchanged. In most cases, this is not too serious because the P-states will be set correctly when the timer function is run. But when the default governor is set to performance, the per-CPU current_pstate stays the same forever and no attempts are made to write the MSRs again. Signed-off-by: Vincent Minet Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 01f4763e8fbfa42bfd8d14b5e406cb6b178eecbe Author: Dirk Brandewie Date: Fri Jun 20 07:28:00 2014 -0700 intel_pstate: Update documentation of {max,min}_perf_pct sysfs files commit 41629a8233470325bfbb60377f555f9e8acc879f upstream. Update documentation to make the interpretation of the values clearer Link: https://bugzilla.kernel.org/show_bug.cgi?id=64251 Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit d778076eaefe4ed6b655a1084687cb67d563713e Author: Dirk Brandewie Date: Fri Jun 20 07:27:59 2014 -0700 intel_pstate: don't touch turbo bit if turbo disabled or unavailable. commit dd5fbf70f96dbfd7ee432096a1f979b2b3267856 upstream. If turbo is disabled in the BIOS bit 38 should be set in MSR_IA32_MISC_ENABLE register per section 14.3.2.1 of the SDM Vol 3 document 325384-050US Feb 2014. If this bit is set do *not* attempt to disable trubo via the MSR_IA32_PERF_CTL register. On some systems trying to disable turbo via MSR_IA32_PERF_CTL will cause subsequent writes to MSR_IA32_PERF_CTL not take affect, in fact reading MSR_IA32_PERF_CTL will not show the IDA/Turbo DISENGAGE bit(32) as set. A write of bit 32 to zero returns to normal operation. Also deal with the case where the processor does not support turbo and the BIOS does not report the fact in MSR_IA32_MISC_ENABLE but does report the max and turbo P states as the same value. Link: https://bugzilla.kernel.org/show_bug.cgi?id=64251 Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ba7e404e720e2080808ed793669830907868116a Author: Dirk Brandewie Date: Fri Jun 20 07:27:58 2014 -0700 intel_pstate: Fix setting VID commit c16ed06024a6e699c332831dd50d8276744e3de8 upstream. Commit 21855ff5 (intel_pstate: Set turbo VID for BayTrail) introduced setting the turbo VID which is required to prevent a machine check on some Baytrail SKUs under heavy graphics based workloads. The docmumentation update that brought the requirement to light also changed the bit mask used for enumerating P state and VID values from 0x7f to 0x3f. This change returns the mask value to 0x7f. Tested with the Intel NUC DN2820FYK, BIOS version FYBYT10H.86A.0034.2014.0513.1413 with v3.16-rc1 and v3.14.8 kernel versions. Fixes: 21855ff5 (intel_pstate: Set turbo VID for BayTrail) Link: https://bugzilla.kernel.org/show_bug.cgi?id=77951 Reported-and-tested-by: Rune Reterson Reported-and-tested-by: Eric Eickmeyer Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit d4a671772aeb04d39c2fe2434ac0d3309a080afd Author: Mikulas Patocka Date: Sat Jun 14 13:44:31 2014 -0400 dm: allocate a special workqueue for deferred device removal commit acfe0ad74d2e1bfc81d1d7bf5e15b043985d3650 upstream. The commit 2c140a246dc ("dm: allow remove to be deferred") introduced a deferred removal feature for the device mapper. When this feature is used (by passing a flag DM_DEFERRED_REMOVE to DM_DEV_REMOVE_CMD ioctl) and the user tries to remove a device that is currently in use, the device will be removed automatically in the future when the last user closes it. Device mapper used the system workqueue to perform deferred removals. However, some targets (dm-raid1, dm-mpath, dm-stripe) flush work items scheduled for the system workqueue from their destructor. If the destructor itself is called from the system workqueue during deferred removal, it introduces a possible deadlock - the workqueue tries to flush itself. Fix this possible deadlock by introducing a new workqueue for deferred removals. We allocate just one workqueue for all dm targets. The ability of dm targets to process IOs isn't dependent on deferred removal of unused targets, so a deadlock due to shared workqueue isn't possible. Also, cleanup local_init() to eliminate potential for returning success on failure. Signed-off-by: Mikulas Patocka Signed-off-by: Dan Carpenter Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 99c4b20adc561416adcef18349806d0b8fcd303f Author: Joe Thornber Date: Fri Jun 27 15:29:04 2014 -0400 dm io: fix a race condition in the wake up code for sync_io commit 10f1d5d111e8aed46a0f1179faf9a3cf422f689e upstream. There's a race condition between the atomic_dec_and_test(&io->count) in dec_count() and the waking of the sync_io() thread. If the thread is spuriously woken immediately after the decrement it may exit, making the on stack io struct invalid, yet the dec_count could still be using it. Fix this race by using a completion in sync_io() and dec_count(). Reported-by: Minfei Huang Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Acked-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 2a0dd0a658c48fdbef2a85e58efa601acc6ca150 Author: Jun'ichi Nomura Date: Tue Jul 8 00:55:14 2014 +0000 dm mpath: fix IO hang due to logic bug in multipath_busy commit 7a7a3b45fed9a144dbf766ee842a4c5d0632b81d upstream. Commit e80991773 ("dm mpath: push back requests instead of queueing") modified multipath_busy() to return true if !pg_ready(). pg_ready() checks the current state of the multipath device and may return false even if a new IO is needed to change the state. Bart Van Assche reported that he had multipath IO lockup when he was performing cable pull tests. Analysis showed that the multipath device had a single path group with both paths active, but that the path group itself was not active. During the multipath device state transitions 'queue_io' got set but nothing could clear it. Clearing 'queue_io' only happens in __choose_pgpath(), but it won't be called if multipath_busy() returns true due to pg_ready() returning false when 'queue_io' is set. As such the !pg_ready() check in multipath_busy() is wrong because new IO will not be sent to multipath target and the multipath state change won't happen. That results in multipath IO lockup. The intent of multipath_busy() is to avoid unnecessary cycles of dequeue + request_fn + requeue if it is known that the multipath device will requeue. Such "busy" situations would be: - path group is being activated - there is no path and the multipath is setup to requeue if no path Fix multipath_busy() to return "busy" early only for these specific situations. Reported-by: Bart Van Assche Tested-by: Bart Van Assche Signed-off-by: Jun'ichi Nomura Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit a59683e362bcd79a92ebcff1c9d5fd63780b013e Author: K. Y. Srinivasan Date: Mon Jul 7 16:34:24 2014 -0700 Drivers: hv: vmbus: Fix a bug in the channel callback dispatch code commit affb1aff300ddee54df307812b38f166e8a865ef upstream. Starting with Win8, we have implemented several optimizations to improve the scalability and performance of the VMBUS transport between the Host and the Guest. Some of the non-performance critical services cannot leverage these optimization since they only read and process one message at a time. Make adjustments to the callback dispatch code to account for the way non-performance critical drivers handle reading of the channel. Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman commit 8f0474112dca1de30f28833e4806716f5acce1e0 Author: Stephen Boyd Date: Wed Jun 25 14:44:19 2014 -0700 clk: qcom: HDMI source sel is 3 not 2 commit c556bcddc78096caeb46dbe3ad0314dd951f1665 upstream. The HDMI PLL input to the tv mux is supposed to be 3, not 2. Fix the code so that we can properly select the HDMI PLL. Fixes: 6d00b56fe "clk: qcom: Add support for MSM8960's multimedia clock controller (MMCC)" Reported-by: Rob Clark Signed-off-by: Stephen Boyd Signed-off-by: Mike Turquette Signed-off-by: Greg Kroah-Hartman commit 885b745141c0688f9b0a0655a1e0c5ca5254e9b2 Author: Krzysztof Kozlowski Date: Fri Jun 27 14:21:10 2014 +0200 clk: s2mps11: Fix double free corruption during driver unbind commit 2a96dfa49c83a2a7cbdb11382976aaa6b2636764 upstream. After unbinding the driver memory was corrupted by double free of clk_lookup structure. This lead to OOPS when re-binding the driver again. The driver allocated memory for 'clk_lookup' with devm_kzalloc. During driver removal this memory was freed twice: once by clkdev_drop() and second by devm code. Kernel panic log: [ 30.839284] Unable to handle kernel paging request at virtual address 5f343173 [ 30.846476] pgd = dee14000 [ 30.849165] [5f343173] *pgd=00000000 [ 30.852703] Internal error: Oops: 805 [#1] PREEMPT SMP ARM [ 30.858166] Modules linked in: [ 30.861208] CPU: 0 PID: 1 Comm: bash Not tainted 3.16.0-rc2-00239-g94bdf617b07e-dirty #40 [ 30.869364] task: df478000 ti: df480000 task.ti: df480000 [ 30.874752] PC is at clkdev_add+0x2c/0x38 [ 30.878738] LR is at clkdev_add+0x18/0x38 [ 30.882732] pc : [] lr : [] psr: 60000013 [ 30.882732] sp : df481e78 ip : 00000001 fp : c0700ed8 [ 30.894187] r10: 0000000c r9 : 00000000 r8 : c07b0e3c [ 30.899396] r7 : 00000002 r6 : df45f9d0 r5 : df421390 r4 : c0700d6c [ 30.905906] r3 : 5f343173 r2 : c0700d84 r1 : 60000013 r0 : c0700d6c [ 30.912417] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 30.919534] Control: 10c53c7d Table: 5ee1406a DAC: 00000015 [ 30.925262] Process bash (pid: 1, stack limit = 0xdf480240) [ 30.930817] Stack: (0xdf481e78 to 0xdf482000) [ 30.935159] 1e60: 00001000 df6de610 [ 30.943321] 1e80: df7f4558 c0355650 c05ec6ec c0700eb0 df6de600 df7f4510 dec9d69c 00000014 [ 30.951480] 1ea0: 00167b48 df6de610 c0700e30 c0713518 00000000 c0700e30 dec9d69c 00000006 [ 30.959639] 1ec0: 00167b48 c02c1b7c c02c1b64 df6de610 c07aff48 c02c0420 c06fb150 c047cc20 [ 30.967798] 1ee0: df6de610 df6de610 c0700e30 df6de644 c06fb150 0000000c dec9d690 c02bef90 [ 30.975957] 1f00: dec9c6c0 dece4c00 df481f80 dece4c00 0000000c c02be73c 0000000c c016ca8c [ 30.984116] 1f20: c016ca48 00000000 00000000 c016c1f4 00000000 00000000 b6f18000 df481f80 [ 30.992276] 1f40: df7f66c0 0000000c df480000 df480000 b6f18000 c011094c df47839c 60000013 [ 31.000435] 1f60: 00000000 00000000 df7f66c0 df7f66c0 0000000c df480000 b6f18000 c0110dd4 [ 31.008594] 1f80: 00000000 00000000 0000000c b6ec05d8 0000000c b6f18000 00000004 c000f2a8 [ 31.016753] 1fa0: 00001000 c000f0e0 b6ec05d8 0000000c 00000001 b6f18000 0000000c 00000000 [ 31.024912] 1fc0: b6ec05d8 0000000c b6f18000 00000004 0000000c 00000001 00000000 00167b48 [ 31.033071] 1fe0: 00000000 bed83a80 b6e004f0 b6e5122c 60000010 00000001 ffffffff ffffffff [ 31.041248] [] (clkdev_add) from [] (s2mps11_clk_probe+0x2b4/0x3b4) [ 31.049223] [] (s2mps11_clk_probe) from [] (platform_drv_probe+0x18/0x48) [ 31.057728] [] (platform_drv_probe) from [] (driver_probe_device+0x13c/0x384) [ 31.066579] [] (driver_probe_device) from [] (bind_store+0x88/0xd8) [ 31.074564] [] (bind_store) from [] (drv_attr_store+0x20/0x2c) [ 31.082118] [] (drv_attr_store) from [] (sysfs_kf_write+0x44/0x48) [ 31.090016] [] (sysfs_kf_write) from [] (kernfs_fop_write+0xc0/0x17c) [ 31.098176] [] (kernfs_fop_write) from [] (vfs_write+0xa0/0x1c4) [ 31.105899] [] (vfs_write) from [] (SyS_write+0x40/0x8c) [ 31.112931] [] (SyS_write) from [] (ret_fast_syscall+0x0/0x3c) [ 31.120481] Code: e2842018 e584501c e1a00004 e885000c (e5835000) [ 31.126596] ---[ end trace efad45bfa3a61b05 ]--- [ 31.131181] Kernel panic - not syncing: Fatal exception [ 31.136368] CPU1: stopping [ 31.139054] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 3.16.0-rc2-00239-g94bdf617b07e-dirty #40 [ 31.148697] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 31.156419] [] (show_stack) from [] (dump_stack+0x80/0xcc) [ 31.163622] [] (dump_stack) from [] (handle_IPI+0x130/0x15c) [ 31.170998] [] (handle_IPI) from [] (gic_handle_irq+0x60/0x68) [ 31.178549] [] (gic_handle_irq) from [] (__irq_svc+0x40/0x70) [ 31.186009] Exception stack(0xdf4bdf88 to 0xdf4bdfd0) [ 31.191046] df80: ffffffed 00000000 00000000 00000000 df4bc000 c06d042c [ 31.199207] dfa0: 00000000 ffffffed c06d03c0 00000000 c070c288 00000000 00000000 df4bdfd0 [ 31.207363] dfc0: c0010324 c0010328 60000013 ffffffff [ 31.212402] [] (__irq_svc) from [] (arch_cpu_idle+0x28/0x30) [ 31.219783] [] (arch_cpu_idle) from [] (cpu_startup_entry+0x2c4/0x3f0) [ 31.228027] [] (cpu_startup_entry) from [<400086c4>] (0x400086c4) [ 31.234968] ---[ end Kernel panic - not syncing: Fatal exception Fixes: 7cc560dea415 ("clk: s2mps11: Add support for s2mps11") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Yadwinder Singh Brar Signed-off-by: Mike Turquette Signed-off-by: Greg Kroah-Hartman commit 384af1e60db641c5009e0a863c9572b6fb85703c Author: Thomas Gleixner Date: Thu Jun 19 21:52:23 2014 +0000 clk: spear3xx: Use proper control register offset commit 15ebb05248d025534773c9ef64915bd888f04e4b upstream. The control register is at offset 0x10, not 0x0. This is wreckaged since commit 5df33a62c (SPEAr: Switch to common clock framework). Signed-off-by: Thomas Gleixner Acked-by: Viresh Kumar Signed-off-by: Mike Turquette Signed-off-by: Greg Kroah-Hartman commit ca005c773e4a07b067ac9373150bd440837f5b3c Author: Roger Quadros Date: Thu Jul 10 11:55:02 2014 +0530 phy: core: Fix error path in phy_create() commit e73b49f1c4e75c44d62585cc3e5b9c7894b61c32 upstream. Prevent resources from being freed twice in case device_add() call fails within phy_create(). Also use ida_simple_remove() instead of ida_remove() as we had used ida_simple_get() to allocate the ida. Signed-off-by: Roger Quadros Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Greg Kroah-Hartman commit c476b7d083ded8e6a97ac66a78a68abc78343033 Author: Colin Cross Date: Wed Jun 18 21:10:09 2014 +0100 arm64: implement TASK_SIZE_OF commit fa2ec3ea10bd377f9d55772b1dab65178425a1a2 upstream. include/linux/sched.h implements TASK_SIZE_OF as TASK_SIZE if it is not set by the architecture headers. TASK_SIZE uses the current task to determine the size of the virtual address space. On a 64-bit kernel this will cause reading /proc/pid/pagemap of a 64-bit process from a 32-bit process to return EOF when it reads past 0xffffffff. Implement TASK_SIZE_OF exactly the same as TASK_SIZE with test_tsk_thread_flag instead of test_thread_flag. Signed-off-by: Colin Cross Acked-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit b98b28c488d6d6c3982aa2a7f16ebdaa92bb6503 Author: Cristian Stoica Date: Mon Jul 7 11:52:41 2014 +0300 crypto: caam - fix memleak in caam_jr module commit 0378c9a855bfa395f595fbfb049707093e270f69 upstream. This patch fixes a memory leak that appears when caam_jr module is unloaded. Signed-off-by: Cristian Stoica Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 69c7bd4bf86fea22b8fc3d75e73b2ef7aaa3d9ff Author: Jussi Kivilinna Date: Mon Jun 23 19:41:05 2014 +0300 crypto: sha512_ssse3 - fix byte count to bit count conversion commit cfe82d4f45c7cc39332a2be7c4c1d3bf279bbd3d upstream. Byte-to-bit-count computation is only partly converted to big-endian and is mixing in CPU-endian values. Problem was noticed by sparce with warning: CHECK arch/x86/crypto/sha512_ssse3_glue.c arch/x86/crypto/sha512_ssse3_glue.c:144:19: warning: restricted __be64 degrades to integer arch/x86/crypto/sha512_ssse3_glue.c:144:17: warning: incorrect type in assignment (different base types) arch/x86/crypto/sha512_ssse3_glue.c:144:17: expected restricted __be64 arch/x86/crypto/sha512_ssse3_glue.c:144:17: got unsigned long long Signed-off-by: Jussi Kivilinna Acked-by: Tim Chen Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 1ab236b86d23963d91b96e0c97d8202fa50e49cd Author: Prabhakar Lad Date: Tue Jul 8 16:25:38 2014 +0100 cpufreq: Makefile: fix compilation for davinci platform commit 5a90af67c2126fe1d04ebccc1f8177e6ca70d3a9 upstream. Since commtit 8a7b1227e303 (cpufreq: davinci: move cpufreq driver to drivers/cpufreq) this added dependancy only for CONFIG_ARCH_DAVINCI_DA850 where as davinci_cpufreq_init() call is used by all davinci platform. This patch fixes following build error: arch/arm/mach-davinci/built-in.o: In function `davinci_init_late': :(.init.text+0x928): undefined reference to `davinci_cpufreq_init' make: *** [vmlinux] Error 1 Fixes: 8a7b1227e303 (cpufreq: davinci: move cpufreq driver to drivers/cpufreq) Signed-off-by: Lad, Prabhakar Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 016323cf2e890f04e7e6e3a7a3347890e09b1efd Author: Joel Stanley Date: Tue Jul 8 16:08:22 2014 +0930 powerpc/perf: Clear MMCR2 when enabling PMU commit b50a6c584bb47b370f84bfd746770c0bbe7129b7 upstream. On POWER8 when switching to a KVM guest we set bits in MMCR2 to freeze the PMU counters. Aside from on boot they are then never reset, resulting in stuck perf counters for any user in the guest or host. We now set MMCR2 to 0 whenever enabling the PMU, which provides a sane state for perf to use the PMU counters under either the guest or the host. This was manifesting as a bug with ppc64_cpu --frequency: $ sudo ppc64_cpu --frequency WARNING: couldn't run on cpu 0 WARNING: couldn't run on cpu 8 ... WARNING: couldn't run on cpu 144 WARNING: couldn't run on cpu 152 min: 18446744073.710 GHz (cpu -1) max: 0.000 GHz (cpu -1) avg: 0.000 GHz The command uses a perf counter to measure CPU cycles over a fixed amount of time, in order to approximate the frequency of the machine. The counters were returning zero once a guest was started, regardless of weather it was still running or had been shut down. By dumping the value of MMCR2, it was observed that once a guest is running MMCR2 is set to 1s - which stops counters from running: $ sudo sh -c 'echo p > /proc/sysrq-trigger' CPU: 0 PMU registers, ppmu = POWER8 n_counters = 6 PMC1: 5b635e38 PMC2: 00000000 PMC3: 00000000 PMC4: 00000000 PMC5: 1bf5a646 PMC6: 5793d378 PMC7: deadbeef PMC8: deadbeef MMCR0: 0000000080000000 MMCR1: 000000001e000000 MMCRA: 0000040000000000 MMCR2: fffffffffffffc00 EBBHR: 0000000000000000 EBBRR: 0000000000000000 BESCR: 0000000000000000 SIAR: 00000000000a51cc SDAR: c00000000fc40000 SIER: 0000000001000000 This is done unconditionally in book3s_hv_interrupts.S upon entering the guest, and the original value is only save/restored if the host has indicated it was using the PMU. This is okay, however the user of the PMU needs to ensure that it is in a defined state when it starts using it. Fixes: e05b9b9e5c10 ("powerpc/perf: Power8 PMU support") Signed-off-by: Joel Stanley Acked-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 491add212d0fc3c80719a15a07677331e912afe0 Author: Joel Stanley Date: Tue Jul 8 16:08:21 2014 +0930 powerpc/perf: Add PPMU_ARCH_207S define commit 4d9690dd56b0d18f2af8a9d4a279cb205aae3345 upstream. Instead of separate bits for every POWER8 PMU feature, have a single one for v2.07 of the architecture. This saves us adding a MMCR2 define for a future patch. Signed-off-by: Joel Stanley Acked-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit da083ad34f15805cb4e6f1bc8dca573383a46c3c Author: Anton Blanchard Date: Thu May 29 08:15:38 2014 +1000 powerpc/perf: Never program book3s PMCs with values >= 0x80000000 commit f56029410a13cae3652d1f34788045c40a13ffc7 upstream. We are seeing a lot of PMU warnings on POWER8: Can't find PMC that caused IRQ Looking closer, the active PMC is 0 at this point and we took a PMU exception on the transition from negative to 0. Some versions of POWER8 have an issue where they edge detect and not level detect PMC overflows. A number of places program the PMC with (0x80000000 - period_left), where period_left can be negative. We can either fix all of these or just ensure that period_left is always >= 1. This patch takes the second option. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 3b9ee8b77385bff2129bc37e85ce10ede67526de Author: Joel Stanley Date: Tue Jul 8 16:08:20 2014 +0930 powerpc/kvm: Remove redundant save of SIER AND MMCR2 commit f73128f4f680e8be68cda831f2710214559583cb upstream. These two registers are already saved in the block above. Aside from being unnecessary, by the time we get down to the second save location r8 no longer contains MMCR2, so we are clobbering the saved value with PMC5. MMCR2 primarily consists of counter freeze bits. So restoring the value of PMC5 into MMCR2 will most likely have the effect of freezing counters. Fixes: 72cde5a88d37 ("KVM: PPC: Book3S HV: Save/restore host PMU registers that are new in POWER8") Signed-off-by: Joel Stanley Acked-by: Michael Ellerman Acked-by: Paul Mackerras Reviewed-by: Alexander Graf Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 89e1fc043f560b7c0051fa83a88fef2bafb6963e Author: Lv Zheng Date: Sun Jun 15 08:42:07 2014 +0800 ACPI / EC: Fix race condition in ec_transaction_completed() commit c0d653412fc8450370167a3268b78fc772ff9c87 upstream. There is a race condition in ec_transaction_completed(). When ec_transaction_completed() is called in the GPE handler, it could return true because of (ec->curr == NULL). Then the wake_up() invocation could complete the next command unexpectedly since there is no lock between the 2 invocations. With the previous cleanup, the IBF=0 waiter race need not be handled any more. It's now safe to return a flag from advance_condition() to indicate the requirement of wakeup, the flag is returned from a locked context. The ec_transaction_completed() is now only invoked by the ec_poll() where the ec->curr is ensured to be different from NULL. After cleaning up, the EVT_SCI=1 check should be moved out of the wakeup condition so that an EVT_SCI raised with (ec->curr == NULL) can trigger a QR_SC command. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891 Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931 Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911 Reported-and-tested-by: Gareth Williams Reported-and-tested-by: Hans de Goede Reported-by: Barton Xu Tested-by: Steffen Weber Tested-by: Arthur Chen Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 4d52854ee507003b6592b472f73fc3fc4fd4f50d Author: Lv Zheng Date: Sun Jun 15 08:41:48 2014 +0800 ACPI / EC: Remove duplicated ec_wait_ibf0() waiter commit 9b80f0f73ae1583c22325ede341c74195847618c upstream. After we've added the first command byte write into advance_transaction(), the IBF=0 waiter is duplicated with the command completion waiter implemented in the ec_poll() because: If IBF=1 blocked the first command byte write invoked in the task context ec_poll(), it would be kicked off upon IBF=0 interrupt or timed out and retried again in the task context. Remove this seperate and duplicate IBF=0 waiter. By doing so we can reduce the overall number of times to access the EC_SC(R) status register. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891 Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931 Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911 Reported-and-tested-by: Gareth Williams Reported-and-tested-by: Hans de Goede Reported-by: Barton Xu Tested-by: Steffen Weber Tested-by: Arthur Chen Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 0fcb235fffb964585b9621084acc2db977f95c42 Author: Lv Zheng Date: Sun Jun 15 08:41:35 2014 +0800 ACPI / EC: Add asynchronous command byte write support commit f92fca0060fc4dc9227342d0072d75df98c1e5a5 upstream. Move the first command byte write into advance_transaction() so that all EC register accesses that can affect the command processing state machine can happen in this asynchronous state machine advancement function. The advance_transaction() function then can be a complete implementation of an asyncrhonous transaction for a single command so that: 1. The first command byte can be written in the interrupt context; 2. The command completion waiter can also be used to wait the first command byte's timeout; 3. In BURST mode, the follow-up command bytes can be written in the interrupt context directly, so that it doesn't need to return to the task context. Returning to the task context reduces the throughput of the BURST mode and in the worst cases where the system workload is very high, this leads to the hardware driven automatic BURST mode exit. In order not to increase memory consumption, convert 'done' into 'flags' to contain multiple indications: 1. ACPI_EC_COMMAND_COMPLETE: converting from original 'done' condition, indicating the completion of the command transaction. 2. ACPI_EC_COMMAND_POLL: indicating the availability of writing the first command byte. A new command can utilize this flag to compete for the right of accessing the underlying hardware. There is a follow-up bug fix that has utilized this new flag. The 2 flags are important because it also reflects a key concept of IO programs' design used in the system softwares. Normally an IO program running in the kernel should first be implemented in the asynchronous way. And the 2 flags are the most common way to implement its synchronous operations on top of the asynchronous operations: 1. POLL: This flag can be used to block until the asynchronous operations can happen. 2. COMPLETE: This flag can be used to block until the asynchronous operations have completed. By constructing code cleanly in this way, many difficult problems can be solved smoothly. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891 Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931 Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911 Reported-and-tested-by: Gareth Williams Reported-and-tested-by: Hans de Goede Reported-by: Barton Xu Tested-by: Steffen Weber Tested-by: Arthur Chen Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 62d3d3095f7d4d5830a8639c0794520ae2ba48cb Author: Lv Zheng Date: Sun Jun 15 08:41:17 2014 +0800 ACPI / EC: Avoid race condition related to advance_transaction() commit 66b42b78bc1e816f92b662e8888c89195e4199e1 upstream. The advance_transaction() will be invoked from the IRQ context GPE handler and the task context ec_poll(). The handling of this function is locked so that the EC state machine are ensured to be advanced sequentially. But there is a problem. Before invoking advance_transaction(), EC_SC(R) is read. Then for advance_transaction(), there could be race condition around the lock from both contexts. The first one reading the register could fail this race and when it passes the stale register value to the state machine advancement code, the hardware condition is totally different from when the register is read. And the hardware accesses determined from the wrong hardware status can break the EC state machine. And there could be cases that the functionalities of the platform firmware are seriously affected. For example: 1. When 2 EC_DATA(W) writes compete the IBF=0, the 2nd EC_DATA(W) write may be invalid due to IBF=1 after the 1st EC_DATA(W) write. Then the hardware will either refuse to respond a next EC_SC(W) write of the next command or discard the current WR_EC command when it receives a EC_SC(W) write of the next command. 2. When 1 EC_SC(W) write and 1 EC_DATA(W) write compete the IBF=0, the EC_DATA(W) write may be invalid due to IBF=1 after the EC_SC(W) write. The next EC_DATA(R) could never be responded by the hardware. This is the root cause of the reported issue. Fix this issue by moving the EC_SC(R) access into the lock so that we can ensure that the state machine is advanced consistently. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891 Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931 Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911 Reported-and-tested-by: Gareth Williams Reported-and-tested-by: Hans de Goede Reported-by: Barton Xu Tested-by: Steffen Weber Tested-by: Arthur Chen Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit a972b86e088cd5074e03702e96b9fd80c0974e82 Author: Andy Whitcroft Date: Thu Jun 19 11:19:16 2014 +0100 ACPI / resources: only reject zero length resources based at address zero commit 867f9d463b82462793ea4610e748be0b04b37fc7 upstream. The recently merged change (in v3.14-rc6) to ACPI resource detection (below) causes all zero length ACPI resources to be elided from the table: commit b355cee88e3b1a193f0e9a81db810f6f83ad728b Author: Zhang Rui Date: Thu Feb 27 11:37:15 2014 +0800 ACPI / resources: ignore invalid ACPI device resources This change has caused a regression in (at least) serial port detection for a number of machines (see LP#1313981 [1]). These seem to represent their IO regions (presumably incorrectly) as a zero length region. Reverting the above commit restores these serial devices. Only elide zero length resources which lie at address 0. Fixes: b355cee88e3b (ACPI / resources: ignore invalid ACPI device resources) Signed-off-by: Andy Whitcroft Acked-by: Zhang Rui Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 0a9711172db0aefcb53f9737adcfc0583bee851c Author: Lan Tianyu Date: Mon Jul 7 01:13:46 2014 +0200 Revert "ACPI / AC: Remove AC's proc directory." commit e63f6e28dda6de3de2392ddca321e211fd860925 upstream. Revert commit ab0fd674d6ce (ACPI / AC: Remove AC's proc directory.), because some old tools (e.g. kpowersave from kde 3.5.10) are still using /proc/acpi/ac_adapter. Fixes: ab0fd674d6ce (ACPI / AC: Remove AC's proc directory.) Reported-and-tested-by: Sorin Manolache Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit cdf5c38683e96518f9a14a2baa8eb7b825ca064e Author: Axel Lin Date: Thu Jul 3 22:45:45 2014 +0800 hwmon: (adm1021) Fix cache problem when writing temperature limits commit c024044d4da2c9c3b32933b4235df1e409293b84 upstream. The module test script for the adm1021 driver exposes a cache problem when writing temperature limits. temp_min and temp_max are expected to be stored in milli-degrees C but are stored in degrees C. Reported-by: Guenter Roeck Signed-off-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 3d4509748577892b48bd4b42013fe7917e1149aa Author: Axel Lin Date: Wed Jul 2 08:29:55 2014 +0800 hwmon: (adm1029) Ensure the fan_div cache is updated in set_fan_div commit 1035a9e3e9c76b64a860a774f5b867d28d34acc2 upstream. Writing to fanX_div does not clear the cache. As a result, reading from fanX_div may return the old value for up to two seconds after writing a new value. This patch ensures the fan_div cache is updated in set_fan_div(). Reported-by: Guenter Roeck Signed-off-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 91805e1c63a3954274c897bb376d134a34d106c6 Author: Guenter Roeck Date: Thu Jul 3 13:44:23 2014 -0700 hwmon: (adm1031) Fix writes to limit registers commit 145e74a4e5022225adb84f4e5d4fff7938475c35 upstream. Upper limit for write operations to temperature limit registers was clamped to a fractional value. However, limit registers do not support fractional values. As a result, upper limits of 127.5 degrees C or higher resulted in a rounded limit of 128 degrees C. Since limit registers are signed, this was stored as -128 degrees C. Clamp limits to (-55, +127) degrees C to solve the problem. Value on writes to auto_temp[12]_min and auto_temp[12]_max were not clamped at all, but masked. As a result, out-of-range writes resulted in a more or less arbitrary limit. Clamp those attributes to (0, 127) degrees C for more predictable results. Cc: Axel Lin Reviewed-by: Jean Delvare Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 4059e4de75fceed9729c9d21927a0fd0ad86bbe3 Author: Guenter Roeck Date: Sun Jul 6 11:39:24 2014 -0700 hwmon: (emc2103) Clamp limits instead of bailing out commit f6c2dd20108c35e30e2c1f3c6142d189451a626b upstream. It is customary to clamp limits instead of bailing out with an error if a configured limit is out of the range supported by the driver. This simplifies limit configuration, since the user will not typically know chip and/or driver specific limits. Reviewed-by: Jean Delvare Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 32c191bfd0c75b3ef01a6ae470a0c05100495a99 Author: Axel Lin Date: Wed Jul 2 07:44:44 2014 +0800 hwmon: (amc6821) Fix permissions for temp2_input commit df86754b746e9a0ff6f863f690b1c01d408e3cdc upstream. temp2_input should not be writable, fix it. Reported-by: Guenter Roeck Signed-off-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 664a1d2a3e53518d0a8cdedda4f523612fc6c59b Author: Guenter Roeck Date: Mon Jul 7 07:10:10 2014 -0700 hwmon: (adc128d818) Drop write support on inX_input attributes commit 7fe7381cbdadf16792e733789983690b3fa82880 upstream. Writes into input registers doesn't make sense, even more so since the writes actually ended up writing into the maximum limit registers. Drop it. Reviewed-by: Jean Delvare Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 05deccd11377a6f06d37d9760e2e8daa087bb01f Author: Aaron Lu Date: Wed May 21 16:33:27 2014 +0800 thermal: hwmon: Make the check for critical temp valid consistent commit e8db5d6736a712a3e2280c0e31f4b301d85172d8 upstream. On 05/21/2014 04:22 PM, Aaron Lu wrote: > On 05/21/2014 01:57 PM, Kui Zhang wrote: >> Hello, >> >> I get following error when rmmod thermal. >> >> rmmod thermal >> Killed While dealing with this problem, I found another problem that also results in a kernel crash on thermal module removal: From: Aaron Lu Date: Wed, 21 May 2014 16:05:38 +0800 Subject: thermal: hwmon: Make the check for critical temp valid consistent We used the tz->ops->get_crit_temp && !tz->ops->get_crit_temp(tz, temp) to decide if we need to create the temp_crit attribute file but we just check if tz->ops->get_crit_temp exists to decide if we need to remove that attribute file. Some ACPI thermal zone doesn't have a valid critical trip point and that would result in removing a non-existent device file on thermal module unload. Signed-off-by: Aaron Lu Signed-off-by: Zhang Rui Signed-off-by: Greg Kroah-Hartman commit b91064ad3f7fc0e6067477ebc1b1ff968705b999 Author: Peter Hurley Date: Thu Jul 10 22:36:46 2014 -0400 serial: imx: Fix build breakage commit 8bec751bd63847b4044aab8b215db52aa6abde61 upstream. Fix breakage introduced by commit c557d392fbf5badd693ea1946a4317c87a26a716, 'serial: Test for no tx data on tx restart'. Reported-by: Stephen Rothwell Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman commit 518cca0c375acc0290d303ed9cba74fdf73f86de Author: Guenter Roeck Date: Sat Jun 21 08:08:08 2014 -0700 i8k: Fix non-SMP operation commit 6d827fbcc370ca259a2905309f64161ab7b10596 upstream. Commit f36fdb9f0266 (i8k: Force SMM to run on CPU 0) adds support for multi-core CPUs to the driver. Unfortunately, that causes it to fail loading if compiled without SMP support, at least on 32 bit kernels. Kernel log shows "i8k: unable to get SMM Dell signature", and function i8k_smm is found to return -EINVAL. Testing revealed that the culprit is the missing return value check of set_cpus_allowed_ptr. Fixes: f36fdb9f0266 (i8k: Force SMM to run on CPU 0) Reported-by: Jim Bos Tested-by: Jim Bos Signed-off-by: Guenter Roeck Cc: Andreas Mohr Signed-off-by: Greg Kroah-Hartman commit e7213f98d8789279f2dbc3fbf63d0d5d820390bd Author: Shawn Guo Date: Wed May 28 23:05:39 2014 +0800 ahci: imx: manage only sata_ref_clk in imx_sata_enable[disable] commit e6dd42a917e62d916c6e513dbf87a4dec8cf3a1c upstream. Doing suspend/resume on imx6q and imx53 boards with no SATA disk attached will trigger the following warning. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 661 at drivers/ata/libahci.c:224 ahci_enable_ahci+0x74/0x8) Modules linked in: CPU: 0 PID: 661 Comm: sh Tainted: G W 3.15.0-rc5-next-20140521-000027 Backtrace: [<80011c90>] (dump_backtrace) from [<80011e2c>] (show_stack+0x18/0x1c) r6:803a22f4 r5:00000000 r4:00000000 r3:00000000 [<80011e14>] (show_stack) from [<80661e60>] (dump_stack+0x88/0xa4) [<80661dd8>] (dump_stack) from [<80028fdc>] (warn_slowpath_common+0x70/0x94) r5:00000009 r4:00000000 [<80028f6c>] (warn_slowpath_common) from [<80029024>] (warn_slowpath_null+0x24/) r8:808f68c4 r7:00000000 r6:00000000 r5:00000000 r4:e0810004 [<80029000>] (warn_slowpath_null) from [<803a22f4>] (ahci_enable_ahci+0x74/0x80) [<803a2280>] (ahci_enable_ahci) from [<803a2324>] (ahci_reset_controller+0x24/0) r8:ddcd9410 r7:80351178 r6:ddcd9444 r5:dde8b850 r4:e0810000 r3:ddf35e90 [<803a2300>] (ahci_reset_controller) from [<803a2c68>] (ahci_platform_resume_ho) r7:80351178 r6:ddcd9444 r5:dde8b850 r4:ddcd9410 [<803a2c30>] (ahci_platform_resume_host) from [<803a38f0>] (imx_ahci_resume+0x2) r5:00000000 r4:ddcd9410 [<803a38c4>] (imx_ahci_resume) from [<803511ac>] (platform_pm_resume+0x34/0x54) .... The reason is that the SATA controller has no working clock at this point, and thus ahci_enable_ahci() fails to enable the controller. In case that there is no SATA disk attached, the imx_sata_disable() gets called in ahci_imx_error_handler(), and both sata_clk and sata_ref_clk will be disabled there. Because all the imx_sata_enable() calls afterward will return immediately due to imxpriv->no_device check, the SATA controller working clock sata_clk will never get any chance to be enabled again. This is a regression caused by commit 90870d79d4f2 (ahci-imx: Port to library-ised ahci_platform). Before the commit, only sata_ref_clk is managed by the driver in enable/disable function. But after the commit, all the clocks are enabled/disabled in a row by ahci platform helpers ahci_platform_enable[disable]_clks. Since ahb_clk is a bus clock which does not have gate at all, and i.MX low-power hardware module already manages sata_clk across suspend/resume cycle, the only clock that needs to be managed by software is sata_ref_clk. So instead of using ahci_platform_enable[disable]_clks to manage all the clocks in a row from imx_sata_enable[disable], we should manage only sata_ref_clk in there. Reported-by: Fabio Estevam Fixes: 90870d79d4f2 (ahci-imx: Port to library-ised ahci_platform) Signed-off-by: Shawn Guo Acked-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 319273f4d2d4a74a8f26eab49d9158ad7c415b45 Author: Yasuaki Ishimatsu Date: Mon Jul 7 09:56:48 2014 -0400 workqueue: zero cpumask of wq_numa_possible_cpumask on init commit 5a6024f1604eef119cf3a6fa413fe0261a81a8f3 upstream. When hot-adding and onlining CPU, kernel panic occurs, showing following call trace. BUG: unable to handle kernel paging request at 0000000000001d08 IP: [] __alloc_pages_nodemask+0x9d/0xb10 PGD 0 Oops: 0000 [#1] SMP ... Call Trace: [] ? cpumask_next_and+0x35/0x50 [] ? find_busiest_group+0x113/0x8f0 [] ? deactivate_slab+0x349/0x3c0 [] new_slab+0x91/0x300 [] __slab_alloc+0x2bb/0x482 [] ? copy_process.part.25+0xfc/0x14c0 [] ? load_balance+0x218/0x890 [] ? sched_clock+0x9/0x10 [] ? trace_clock_local+0x9/0x10 [] kmem_cache_alloc_node+0x8c/0x200 [] copy_process.part.25+0xfc/0x14c0 [] ? trace_buffer_unlock_commit+0x4d/0x60 [] ? kthread_create_on_node+0x140/0x140 [] do_fork+0xbc/0x360 [] kernel_thread+0x26/0x30 [] kthreadd+0x2c2/0x300 [] ? kthread_create_on_cpu+0x60/0x60 [] ret_from_fork+0x7c/0xb0 [] ? kthread_create_on_cpu+0x60/0x60 In my investigation, I found the root cause is wq_numa_possible_cpumask. All entries of wq_numa_possible_cpumask is allocated by alloc_cpumask_var_node(). And these entries are used without initializing. So these entries have wrong value. When hot-adding and onlining CPU, wq_update_unbound_numa() is called. wq_update_unbound_numa() calls alloc_unbound_pwq(). And alloc_unbound_pwq() calls get_unbound_pool(). In get_unbound_pool(), worker_pool->node is set as follow: 3592 /* if cpumask is contained inside a NUMA node, we belong to that node */ 3593 if (wq_numa_enabled) { 3594 for_each_node(node) { 3595 if (cpumask_subset(pool->attrs->cpumask, 3596 wq_numa_possible_cpumask[node])) { 3597 pool->node = node; 3598 break; 3599 } 3600 } 3601 } But wq_numa_possible_cpumask[node] does not have correct cpumask. So, wrong node is selected. As a result, kernel panic occurs. By this patch, all entries of wq_numa_possible_cpumask are allocated by zalloc_cpumask_var_node to initialize them. And the panic disappeared. Signed-off-by: Yasuaki Ishimatsu Reviewed-by: Lai Jiangshan Signed-off-by: Tejun Heo Fixes: bce903809ab3 ("workqueue: add wq_numa_tbl_len and wq_numa_possible_cpumask[]") Signed-off-by: Greg Kroah-Hartman commit 55e604757f659afb5a7bbee3c35fae77fd147b87 Author: Gu Zheng Date: Wed Jun 25 09:57:18 2014 +0800 cpuset,mempolicy: fix sleeping function called from invalid context commit 391acf970d21219a2a5446282d3b20eace0c0d7a upstream. When runing with the kernel(3.15-rc7+), the follow bug occurs: [ 9969.258987] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586 [ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name: python [ 9969.441175] INFO: lockdep is turned off. [ 9969.488184] CPU: 26 PID: 160655 Comm: python Tainted: G A 3.15.0-rc7+ #85 [ 9969.581032] Hardware name: FUJITSU-SV PRIMEQUEST 1800E/SB, BIOS PRIMEQUEST 1000 Series BIOS Version 1.39 11/16/2012 [ 9969.706052] ffffffff81a20e60 ffff8803e941fbd0 ffffffff8162f523 ffff8803e941fd18 [ 9969.795323] ffff8803e941fbe0 ffffffff8109995a ffff8803e941fc58 ffffffff81633e6c [ 9969.884710] ffffffff811ba5dc ffff880405c6b480 ffff88041fdd90a0 0000000000002000 [ 9969.974071] Call Trace: [ 9970.003403] [] dump_stack+0x4d/0x66 [ 9970.065074] [] __might_sleep+0xfa/0x130 [ 9970.130743] [] mutex_lock_nested+0x3c/0x4f0 [ 9970.200638] [] ? kmem_cache_alloc+0x1bc/0x210 [ 9970.272610] [] cpuset_mems_allowed+0x27/0x140 [ 9970.344584] [] ? __mpol_dup+0x63/0x150 [ 9970.409282] [] __mpol_dup+0xe5/0x150 [ 9970.471897] [] ? __mpol_dup+0x63/0x150 [ 9970.536585] [] ? copy_process.part.23+0x606/0x1d40 [ 9970.613763] [] ? trace_hardirqs_on+0xd/0x10 [ 9970.683660] [] ? monotonic_to_bootbased+0x2f/0x50 [ 9970.759795] [] copy_process.part.23+0x670/0x1d40 [ 9970.834885] [] do_fork+0xd8/0x380 [ 9970.894375] [] ? __audit_syscall_entry+0x9c/0xf0 [ 9970.969470] [] SyS_clone+0x16/0x20 [ 9971.030011] [] stub_clone+0x69/0x90 [ 9971.091573] [] ? system_call_fastpath+0x16/0x1b The cause is that cpuset_mems_allowed() try to take mutex_lock(&callback_mutex) under the rcu_read_lock(which was hold in __mpol_dup()). And in cpuset_mems_allowed(), the access to cpuset is under rcu_read_lock, so in __mpol_dup, we can reduce the rcu_read_lock protection region to protect the access to cpuset only in current_cpuset_is_being_rebound(). So that we can avoid this bug. This patch is a temporary solution that just addresses the bug mentioned above, can not fix the long-standing issue about cpuset.mems rebinding on fork(): "When the forker's task_struct is duplicated (which includes ->mems_allowed) and it races with an update to cpuset_being_rebound in update_tasks_nodemask() then the task's mems_allowed doesn't get updated. And the child task's mems_allowed can be wrong if the cpuset's nodemask changes before the child has been added to the cgroup's tasklist." Signed-off-by: Gu Zheng Acked-by: Li Zefan Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit d51372dd0114942e5ed98ccf1de5f5cb21ea5a6e Author: Maxime Bizon Date: Mon Jun 23 16:35:35 2014 +0200 workqueue: fix dev_set_uevent_suppress() imbalance commit bddbceb688c6d0decaabc7884fede319d02f96c8 upstream. Uevents are suppressed during attributes registration, but never restored, so kobject_uevent() does nothing. Signed-off-by: Maxime Bizon Signed-off-by: Tejun Heo Fixes: 226223ab3c4118ddd10688cc2c131135848371ab Signed-off-by: Greg Kroah-Hartman commit 7ca4e7f017bc0329bfde30cdf918d91ee1e149a7 Author: Helge Deller Date: Thu Jul 10 18:07:17 2014 +0200 parisc: fix fanotify_mark() syscall on 32bit compat kernel commit ab8a261ba5e2dd9206da640de5870cc31d568a7c upstream. On parisc we can not use the existing compat implementation for fanotify_mark() because for the 64bit mask parameter the higher and lower 32bits are ordered differently than what the compat function expects from big endian architectures. Specifically: It finally turned out, that on hppa we end up with different assignments of parameters to kernel arguments depending on if we call the glibc wrapper function int fanotify_mark (int __fanotify_fd, unsigned int __flags, uint64_t __mask, int __dfd, const char *__pathname); or directly calling the syscall manually syscall(__NR_fanotify_mark, ...) Reason is, that the syscall() function is implemented as C-function and because we now have the sysno as first parameter in front of the other parameters the compiler will unexpectedly add an empty paramenter in front of the u64 value to ensure the correct calling alignment for 64bit values. This means, on hppa you can't simply use syscall() to call the kernel fanotify_mark() function directly, but you have to use the glibc function instead. This patch fixes the kernel in the hppa-arch specifc coding to adjust the parameters in a way as if userspace calls the glibc wrapper function fanotify_mark(). Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 6b8c86af50681e3a11c64cc6aa808426869639f7 Author: Helge Deller Date: Sat Jun 28 17:44:51 2014 +0200 parisc: add serial ports of C8000/1GHz machine to hardware database commit eadcc7208a2237016be7bdff4551ba7614da85c8 upstream. Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit ba9286fc6400b546d940297480a46528555e9304 Author: Peter Hurley Date: Sun Jul 6 11:29:52 2014 -0400 serial: Test for no tx data on tx restart commit c557d392fbf5badd693ea1946a4317c87a26a716 upstream. Commit 717f3bbab3c7628736ef738fdbf3d9a28578c26c, 'serial_core: Fix conditional start_tx on ring buffer not empty' exposes an incorrect assumption in several drivers' start_tx methods; the tx ring buffer can, in fact, be empty when restarting tx while performing flow control. Affected drivers: sunsab.c ip22zilog.c pmac_zilog.c sunzilog.c m32r_sio.c imx.c Other in-tree serial drivers either are not affected or already test for empty tx ring buffer before transmitting. Test for empty tx ring buffer in start_tx() method, after transmitting x_char (if applicable). Reported-by: Aaro Koskinen Cc: Seth Bollinger Cc: "David S. Miller" Cc: Sam Ravnborg Cc: Thomas Bogendoerfer Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman commit e7af190b2becaea9e5b5f6b1321f5bbcb9eaf8f2 Author: Jan Kardell Date: Thu Nov 6 22:18:00 2014 +0000 iio: ti_am335x_adc: Fix: Use same step id at FIFOs both ends commit baa3c65298c089a9014b4e523a14ec2885cca1bc upstream. Since AI lines could be selected at will (linux-3.11) the sending and receiving ends of the FIFO does not agree about what step is used for a line. It only works if the last lines are used, like 5,6,7, and fails if ie 2,4,6 is selected in DT. Signed-off-by: Jan Kardell Tested-by: Zubair Lutfullah Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit ed69bb63d6415fbf95879451c71f7f51af38031a Author: Michal Sojka Date: Thu Jul 10 14:00:34 2014 +0200 USB: serial: ftdi_sio: Add Infineon Triboard commit d8279a40e50ad55539780aa617a32a53d7f0953e upstream. This adds support for Infineon TriBoard TC1798 [1]. Only interface 1 is used as serial line (see [2], Figure 8-6). [1] http://www.infineon.com/cms/de/product/microcontroller/development-tools-software-and-kits/tricore-tm-development-tools-software-and-kits/starterkits-and-evaluation-boards/starter-kit-tc1798/channel.html?channel=db3a304333b8a7ca0133cfa3d73e4268 [2] http://www.infineon.com/dgdl/TriBoardManual-TC1798-V10.pdf?folderId=db3a304412b407950112b409ae7c0343&fileId=db3a304333b8a7ca0133cfae99fe426a Signed-off-by: Michal Sojka Cc: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit fe9689dd404458212d8616665d4479a6feb60a21 Author: Bert Vermeulen Date: Tue Jul 8 14:42:23 2014 +0200 USB: ftdi_sio: Add extra PID. commit 5a7fbe7e9ea0b1b9d7ffdba64db1faa3a259164c upstream. This patch adds PID 0x0003 to the VID 0x128d (Testo). At least the Testo 435-4 uses this, likely other gear as well. Signed-off-by: Bert Vermeulen Cc: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 2d168fa70cc5571fe40ef8b8437d979b43fbfdd0 Author: Andras Kovacs Date: Fri Jun 27 14:50:11 2014 +0200 USB: cp210x: add support for Corsair usb dongle commit b9326057a3d8447f5d2e74a7b521ccf21add2ec0 upstream. Corsair USB Dongles are shipped with Corsair AXi series PSUs. These are cp210x serial usb devices, so make driver detect these. I have a program, that can get information from these PSUs. Tested with 2 different dongles shipped with Corsair AX860i and AX1200i units. Signed-off-by: Andras Kovacs Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ab6a9f94a6db9b4c5af5ba33a5df54ac5633b5ca Author: Bernd Wachter Date: Wed Jul 2 12:36:48 2014 +0300 usb: option: Add ID for Telewell TW-LTE 4G v2 commit 3d28bd840b2d3981cd28caf5fe1df38f1344dd60 upstream. Add ID of the Telewell 4G v2 hardware to option driver to get legacy serial interface working Signed-off-by: Bernd Wachter Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman