commit 23356555bacd63fa7c1e96a0cc928a617209d99e Author: Greg Kroah-Hartman Date: Mon Jun 30 20:14:09 2014 -0700 Linux 3.15.3 commit a6d4b786ebfbbb9330b6915b590547d348ec148c Author: Andrzej Zaborowski Date: Mon Jun 9 16:50:40 2014 +0200 efi-pstore: Fix an overflow on 32-bit builds commit 783ee43118dc773bc8b0342c5b230e017d5a04d0 upstream. In generic_id the long int timestamp is multiplied by 100000 and needs an explicit cast to u64. Without that the id in the resulting pstore filename is wrong and userspace may have problems parsing it, but more importantly files in pstore can never be deleted and may fill the EFI flash (brick device?). This happens because when generic pstore code wants to delete a file, it passes the id to the EFI backend which reinterpretes it and a wrong variable name is attempted to be deleted. There's no error message but after remounting pstore, deleted files would reappear. Signed-off-by: Andrew Zaborowski Acked-by: David Rientjes Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit 7f922b1920f7c38a6cf0645aea543b0ec343eb0f Author: Fathi Boudra Date: Sat Apr 12 13:13:24 2014 +0300 builddeb: use $OBJCOPY variable instead of objcopy commit 6b4a144a92ab81a1f45fb9b12aebaaaee0d08120 upstream. In cross-build environment, we expect to use the cross-compiler objcopy instead of the host objcopy. It fixes following build failures: objcopy --only-keep-debug lib/modules/3.14/kernel/net/ipv6/xfrm6_mode_tunnel.ko /srv/build/linux/debian/dbgtmp/usr/lib/debug/lib/modules/3.14/kernel/net/ipv6/xfrm6_mode_tunnel.ko objcopy: Unable to recognise the format of the input file `lib/modules/3.14/kernel/net/ipv6/xfrm6_mode_tunnel.ko' Signed-off-by: Fathi Boudra Fixes: 810e843746b7 ('deb-pkg: split debug symbols in their own package') Reviewed-by: Ben Hutchings Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman commit 02bbff7274ac3f4a08536874a316e055d3be3ff5 Author: Theodore Ts'o Date: Sun Jun 15 21:04:32 2014 -0400 random: fix nasty entropy accounting bug commit e33ba5fa7afce1a9f159704121d4e4d110df8185 upstream. Commit 0fb7a01af5b0 "random: simplify accounting code", introduced in v3.15, has a very nasty accounting problem when the entropy pool has has fewer bytes of entropy than the number of requested reserved bytes. In that case, "have_bytes - reserved" goes negative, and since size_t is unsigned, the expression: ibytes = min_t(size_t, ibytes, have_bytes - reserved); ... does not do the right thing. This is rather bad, because it defeats the catastrophic reseeding feature in the xfer_secondary_pool() path. It also can cause the "BUG: spinlock trylock failure on UP" for some kernel configurations when prandom_reseed() calls get_random_bytes() in the early init, since when the entropy count gets corrupted, credit_entropy_bits() erroneously believes that the nonblocking pool has been fully initialized (when in fact it is not), and so it calls prandom_reseed(true) recursively leading to the spinlock BUG. The logic is *not* the same it was originally, but in the cases where it matters, the behavior is the same, and the resulting code is hopefully easier to read and understand. Fixes: 0fb7a01af5b0 "random: simplify accounting code" Signed-off-by: Theodore Ts'o Cc: Greg Price Signed-off-by: Greg Kroah-Hartman commit faf067b39a509e17682b6276cc54012b67683dc3 Author: Konstantin Khlebnikov Date: Tue Jun 17 06:58:05 2014 +0400 epoll: fix use-after-free in eventpoll_release_file commit ebe06187bf2aec10d537ce4595e416035367d703 upstream. This fixes use-after-free of epi->fllink.next inside list loop macro. This loop actually releases elements in the body. The list is rcu-protected but here we cannot hold rcu_read_lock because we need to lock mutex inside. The obvious solution is to use list_for_each_entry_safe(). RCU-ness isn't essential because nobody can change this list under us, it's final fput for this file. The bug was introduced by ae10b2b4eb01 ("epoll: optimize EPOLL_CTL_DEL using rcu") Signed-off-by: Konstantin Khlebnikov Reported-by: Cyrill Gorcunov Cc: Sasha Levin Cc: Jason Baron Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a8e9e3d06557c580665d1ac5a6059cb7b9b4a01e Author: Andy Lutomirski Date: Mon Jun 23 14:22:15 2014 -0700 x86_32, entry: Do syscall exit work on badsys (CVE-2014-4508) commit 554086d85e71f30abe46fc014fea31929a7c6a8a upstream. The bad syscall nr paths are their own incomprehensible route through the entry control flow. Rearrange them to work just like syscalls that return -ENOSYS. This fixes an OOPS in the audit code when fast-path auditing is enabled and sysenter gets a bad syscall nr (CVE-2014-4508). This has probably been broken since Linux 2.6.27: af0575bba0 i386 syscall audit fast-path Cc: Roland McGrath Reported-by: Toralf Förster Signed-off-by: Andy Lutomirski Link: http://lkml.kernel.org/r/e09c499eade6fc321266dd6b54da7beb28d6991c.1403558229.git.luto@amacapital.net Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 96ae603f57d56daec8f56c83d8d1a71ca2e06162 Author: Greg Kroah-Hartman Date: Tue Jun 24 16:59:01 2014 -0400 lz4: fix another possible overrun commit 4148c1f67abf823099b2d7db6851e4aea407f5ee upstream. There is one other possible overrun in the lz4 code as implemented by Linux at this point in time (which differs from the upstream lz4 codebase, but will get synced at in a future kernel release.) As pointed out by Don, we also need to check the overflow in the data itself. While we are at it, replace the odd error return value with just a "simple" -1 value as the return value is never used for anything other than a basic "did this work or not" check. Reported-by: "Don A. Bailey" Reported-by: Willy Tarreau Signed-off-by: Greg Kroah-Hartman commit 01233a9c832037fc460e278575901a4229f3bb9e Author: Johan Hedberg Date: Thu May 29 19:36:53 2014 +0300 Bluetooth: Fix properly ignoring LTKs of unknown types commit 61b433579b6ffecb1d3534fd482dcd48535277c8 upstream. In case there are new LTK types in the future we shouldn't just blindly assume that != MGMT_LTK_UNAUTHENTICATED means that the key is authenticated. This patch adds explicit checks for each allowed key type in the form of a switch statement and skips any key which has an unknown value. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 8556876847effb03ca33334464c2854bdd3f0ed8 Author: Johan Hedberg Date: Fri May 23 13:19:53 2014 +0300 Bluetooth: Clearly distinguish mgmt LTK type from authenticated property commit d7b2545023ecfde94d3ea9c03c5480ac18da96c9 upstream. On the mgmt level we have a key type parameter which currently accepts two possible values: 0x00 for unauthenticated and 0x01 for authenticated. However, in the internal struct smp_ltk representation we have an explicit "authenticated" boolean value. To make this distinction clear, add defines for the possible mgmt values and do conversion to and from the internal authenticated value. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 28084dbaaffc76e120736740a1e4ede158b71e9b Author: Eric Sandeen Date: Thu Jun 12 00:39:58 2014 -0500 btrfs: fix use of uninit "ret" in end_extent_writepage() commit 3e2426bd0eb980648449e7a2f5a23e3cd3c7725c upstream. If this condition in end_extent_writepage() is false: if (tree->ops && tree->ops->writepage_end_io_hook) we will then test an uninitialized "ret" at: ret = ret < 0 ? ret : -EIO; The test for ret is for the case where ->writepage_end_io_hook failed, and we'd choose that ret as the error; but if there is no ->writepage_end_io_hook, nothing sets ret. Initializing ret to 0 should be sufficient; if writepage_end_io_hook wasn't set, (!uptodate) means non-zero err was passed in, so we choose -EIO in that case. Signed-of-by: Eric Sandeen Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit eed31172a351856ad18081f501946e1670b6a1f6 Author: Liu Bo Date: Mon Jun 9 10:54:07 2014 +0800 Btrfs: fix scrub_print_warning to handle skinny metadata extents commit 6eda71d0c030af0fc2f68aaa676e6d445600855b upstream. The skinny extents are intepreted incorrectly in scrub_print_warning(), and end up hitting the BUG() in btrfs_extent_inline_ref_size. Reported-by: Konstantinos Skarlatos Signed-off-by: Liu Bo Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 6d2a63f3d1bbdf0bcd9201e2826a727261c0becc Author: Liu Bo Date: Sun Jun 8 19:04:13 2014 +0800 Btrfs: use right type to get real comparison commit cd857dd6bc2ae9ecea14e75a34e8a8fdc158e307 upstream. We want to make sure the point is still within the extent item, not to verify the memory it's pointing to. Signed-off-by: Liu Bo Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit efb57277b9df5bcdf99aabd8b4bafe9c4cbd7576 Author: Josef Bacik Date: Thu Jun 5 16:08:45 2014 -0400 Btrfs: don't check nodes for extent items commit 8a56457f5f8fa7c2698ffae8545214c5b96a2cb5 upstream. The backref code was looking at nodes as well as leaves when we tried to populate extent item entries. This is not good, and although we go away with it for the most part because we'd skip where disk_bytenr != random_memory, sometimes random_memory would match and suddenly boom. This fixes that problem. Thanks, Signed-off-by: Josef Bacik Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit e517155065804d25328f9f2d99a8f25e87b42749 Author: Rickard Strandqvist Date: Thu May 22 22:43:43 2014 +0200 fs: btrfs: volumes.c: Fix for possible null pointer dereference commit 8321cf2596d283821acc466377c2b85bcd3422b7 upstream. There is otherwise a risk of a possible null pointer dereference. Was largely found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 80693a87ae519cdab6b4c2a31bbadf55ec8cade9 Author: Jeff Mahoney Date: Tue May 27 12:59:57 2014 -0400 btrfs: allocate raid type kobjects dynamically commit c1895442be01c58449e3bf9272f22062a670e08f upstream. We are currently allocating space_info objects in an array when we allocate space_info. When a user does something like: # btrfs balance start -mconvert=raid1 -dconvert=raid1 /mnt # btrfs balance start -mconvert=single -dconvert=single /mnt -f # btrfs balance start -mconvert=raid1 -dconvert=raid1 / We can end up with memory corruption since the kobject hasn't been reinitialized properly and the name pointer was left set. The rationale behind allocating them statically was to avoid creating a separate kobject container that just contained the raid type. It used the index in the array to determine the index. Ultimately, though, this wastes more memory than it saves in all but the most complex scenarios and introduces kobject lifetime questions. This patch allocates the kobjects dynamically instead. Note that we also remove the kobject_get/put of the parent kobject since kobject_add and kobject_del do that internally. Signed-off-by: Jeff Mahoney Reported-by: David Sterba Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 69a109b2cec03ef6ce93ad08e3c01665213579e3 Author: Filipe Manana Date: Fri May 23 20:15:16 2014 +0100 Btrfs: send, use the right limits for xattr names and values commit 7e3ae33efad1490d01040f552ef50e58ed6376ca upstream. We were limiting the sum of the xattr name and value lengths to PATH_MAX, which is not correct, specially on filesystems created with btrfs-progs v3.12 or higher, where the default leaf size is max(16384, PAGE_SIZE), or systems with page sizes larger than 4096 bytes. Xattrs have their own specific maximum name and value lengths, which depend on the leaf size, therefore use these limits to be able to send xattrs with sizes larger than PATH_MAX. A test case for xfstests follows. Signed-off-by: Filipe David Borba Manana Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 1a7fc2e61a38aeab711e7d74adab235a7cf98219 Author: Filipe Manana Date: Sun May 25 04:49:24 2014 +0100 Btrfs: send, don't error in the presence of subvols/snapshots commit 1af56070e3ef9477dbc7eba3b9ad7446979c7974 upstream. If we are doing an incremental send and the base snapshot has a directory with name X that doesn't exist anymore in the second snapshot and a new subvolume/snapshot exists in the second snapshot that has the same name as the directory (name X), the incremental send would fail with -ENOENT error. This is because it attempts to lookup for an inode with a number matching the objectid of a root, which doesn't exist. Steps to reproduce: mkfs.btrfs -f /dev/sdd mount /dev/sdd /mnt mkdir /mnt/testdir btrfs subvolume snapshot -r /mnt /mnt/mysnap1 rmdir /mnt/testdir btrfs subvolume create /mnt/testdir btrfs subvolume snapshot -r /mnt /mnt/mysnap2 btrfs send -p /mnt/mysnap1 /mnt/mysnap2 -f /tmp/send.data A test case for xfstests follows. Reported-by: Robert White Signed-off-by: Filipe David Borba Manana Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 1b524a36f1d78a8571071c611dcdeb38e656f8a6 Author: Wang Shilong Date: Tue May 13 17:05:06 2014 +0800 Btrfs: set right total device count for seeding support commit 298658414a2f0bea1f05a81876a45c1cd96aa2e0 upstream. Seeding device support allows us to create a new filesystem based on existed filesystem. However newly created filesystem's @total_devices should include seed devices. This patch fix the following problem: # mkfs.btrfs -f /dev/sdb # btrfstune -S 1 /dev/sdb # mount /dev/sdb /mnt # btrfs device add -f /dev/sdc /mnt --->fs_devices->total_devices = 1 # umount /mnt # mount /dev/sdc /mnt --->fs_devices->total_devices = 2 This is because we record right @total_devices in superblock, but @fs_devices->total_devices is reset to be 0 in btrfs_prepare_sprout(). Fix this problem by not resetting @fs_devices->total_devices. Signed-off-by: Wang Shilong Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 8d7293457e87c2424e90d2f893b6a28e68a2189b Author: Liu Bo Date: Mon May 12 12:47:36 2014 +0800 Btrfs: mark mapping with error flag to report errors to userspace commit 5dca6eea91653e9949ce6eb9e9acab6277e2f2c4 upstream. According to commit 865ffef3797da2cac85b3354b5b6050dc9660978 (fs: fix fsync() error reporting), it's not stable to just check error pages because pages can be truncated or invalidated, we should also mark mapping with error flag so that a later fsync can catch the error. Signed-off-by: Liu Bo Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit c6b4616c411942e2e9bba4671627f7faf0a5db6a Author: Liu Bo Date: Sun May 11 23:14:59 2014 +0800 Btrfs: fix NULL pointer crash of deleting a seed device commit 29cc83f69c8338ff8fd1383c9be263d4bdf52d73 upstream. Same as normal devices, seed devices should be initialized with fs_info->dev_root as well, otherwise we'll get a NULL pointer crash. Cc: Chris Murphy Reported-by: Chris Murphy Signed-off-by: Liu Bo Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit add81375ec79d6ecfb959b321a843a608013ef32 Author: Wang Shilong Date: Wed Apr 9 19:23:22 2014 +0800 Btrfs: make sure there are not any read requests before stopping workers commit de348ee022175401e77d7662b7ca6e231a94e3fd upstream. In close_ctree(), after we have stopped all workers,there maybe still some read requests(for example readahead) to submit and this *maybe* trigger an oops that user reported before: kernel BUG at fs/btrfs/async-thread.c:619! By hacking codes, i can reproduce this problem with one cpu available. We fix this potential problem by invalidating all btree inode pages before stopping all workers. Thanks to Miao for pointing out this problem. Signed-off-by: Wang Shilong Reviewed-by: David Sterba Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 7df26ca1d80e22cd080f7a8d9ffc307ef1661d3a Author: Filipe Manana Date: Sat Mar 22 17:15:24 2014 +0000 Btrfs: send, account for orphan directories when building path strings commit c992ec94f24c3e7135d6c23860615f269f0b1d87 upstream. If we have directories with a pending move/rename operation, we must take into account any orphan directories that got created before executing the pending move/rename. Those orphan directories are directories with an inode number higher then the current send progress and that don't exist in the parent snapshot, they are created before current progress reaches their inode number, with a generated name of the form oN-M-I and at the root of the filesystem tree, and later when progress matches their inode number, moved/renamed to their final location. Reproducer: $ mkfs.btrfs -f /dev/sdd $ mount /dev/sdd /mnt $ mkdir -p /mnt/a/b/c/d $ mkdir /mnt/a/b/e $ mv /mnt/a/b/c /mnt/a/b/e/CC $ mkdir /mnt/a/b/e/CC/d/f $ mkdir /mnt/a/g $ btrfs subvolume snapshot -r /mnt /mnt/snap1 $ btrfs send /mnt/snap1 -f /tmp/base.send $ mkdir /mnt/a/g/h $ mv /mnt/a/b/e /mnt/a/g/h/EE $ mv /mnt/a/g/h/EE/CC/d /mnt/a/g/h/EE/DD $ btrfs subvolume snapshot -r /mnt /mnt/snap2 $ btrfs send -p /mnt/snap1 /mnt/snap2 -f /tmp/incremental.send The second receive command failed with the following error: ERROR: rename a/b/e/CC/d -> o264-7-0/EE/DD failed. No such file or directory A test case for xfstests follows soon. Signed-off-by: Filipe David Borba Manana Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 580b02787ebc3f9faf2f2166779f4da657de323b Author: Miao Xie Date: Thu Apr 24 13:31:55 2014 +0800 Btrfs: output warning instead of error when loading free space cache failed commit 32d6b47fe6fc1714d5f1bba1b9f38e0ab0ad58a8 upstream. If we fail to load a free space cache, we can rebuild it from the extent tree, so it is not a serious error, we should not output a error message that would make the users uncomfortable. This patch uses warning message instead of it. Signed-off-by: Miao Xie Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 2e9e31430a45cce7871c4795fea1493d08ca7061 Author: Qu Wenruo Date: Wed Apr 16 17:02:32 2014 +0800 btrfs: Add ctime/mtime update for btrfs device add/remove. commit 5a1972bd9fd4b2fb1bac8b7a0b636d633d8717e3 upstream. Btrfs will send uevent to udev inform the device change, but ctime/mtime for the block device inode is not udpated, which cause libblkid used by btrfs-progs unable to detect device change and use old cache, causing 'btrfs dev scan; btrfs dev rmove; btrfs dev scan' give an error message. Reported-by: Tsutomu Itoh Cc: Karel Zak Signed-off-by: Qu Wenruo Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 2501c4a066e633524791e8ce8dbfe615aca071cf Author: Filipe Manana Date: Sat Apr 26 01:35:31 2014 +0100 Btrfs: read inode size after acquiring the mutex when punching a hole commit a1a50f60a6bf4f861eb94793420274bc1ccd409a upstream. In a previous change, commit 12870f1c9b2de7d475d22e73fd7db1b418599725, I accidentally moved the roundup of inode->i_size to outside of the critical section delimited by the inode mutex, which is not atomic and not correct since the size can be changed by other task before we acquire the mutex. Therefore fix it. Signed-off-by: Filipe David Borba Manana Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit bddf0faccf1dd39ec80059eb5266766e6bf0134c Author: Chris Mason Date: Wed May 21 05:49:54 2014 -0700 Btrfs: fix double free in find_lock_delalloc_range commit 7d78874273463a784759916fc3e0b4e2eb141c70 upstream. We need to NULL the cached_state after freeing it, otherwise we might free it again if find_delalloc_range doesn't find anything. Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 938bdab6783797ff1f70cbb9cefa406889ef5c52 Author: Filipe Manana Date: Tue Apr 29 13:18:40 2014 +0100 Btrfs: fix leaf corruption caused by ENOSPC while hole punching commit fc19c5e73645f95d3eca12b4e91e7b56faf1e4a4 upstream. While running a stress test with multiple threads writing to the same btrfs file system, I ended up with a situation where a leaf was corrupted in that it had 2 file extent item keys that had the same exact key. I was able to detect this quickly thanks to the following patch which triggers an assertion as soon as a leaf is marked dirty if there are duplicated keys or out of order keys: Btrfs: check if items are ordered when a leaf is marked dirty (https://patchwork.kernel.org/patch/3955431/) Basically while running the test, I got the following in dmesg: [28877.415877] WARNING: CPU: 2 PID: 10706 at fs/btrfs/file.c:553 btrfs_drop_extent_cache+0x435/0x440 [btrfs]() (...) [28877.415917] Call Trace: [28877.415922] [] dump_stack+0x4e/0x68 [28877.415926] [] warn_slowpath_common+0x8c/0xc0 [28877.415929] [] warn_slowpath_null+0x1a/0x20 [28877.415944] [] btrfs_drop_extent_cache+0x435/0x440 [btrfs] [28877.415949] [] ? kmem_cache_alloc+0xfe/0x1c0 [28877.415962] [] fill_holes+0x229/0x3e0 [btrfs] [28877.415972] [] ? block_rsv_add_bytes+0x55/0x80 [btrfs] [28877.415984] [] btrfs_fallocate+0xb6b/0xc20 [btrfs] (...) [29854.132560] BTRFS critical (device sdc): corrupt leaf, bad key order: block=955232256,root=1, slot=24 [29854.132565] BTRFS info (device sdc): leaf 955232256 total ptrs 40 free space 778 (...) [29854.132637] item 23 key (3486 108 667648) itemoff 2694 itemsize 53 [29854.132638] extent data disk bytenr 14574411776 nr 286720 [29854.132639] extent data offset 0 nr 286720 ram 286720 [29854.132640] item 24 key (3486 108 954368) itemoff 2641 itemsize 53 [29854.132641] extent data disk bytenr 0 nr 0 [29854.132643] extent data offset 0 nr 0 ram 0 [29854.132644] item 25 key (3486 108 954368) itemoff 2588 itemsize 53 [29854.132645] extent data disk bytenr 8699670528 nr 77824 [29854.132646] extent data offset 0 nr 77824 ram 77824 [29854.132647] item 26 key (3486 108 1146880) itemoff 2535 itemsize 53 [29854.132648] extent data disk bytenr 8699670528 nr 77824 [29854.132649] extent data offset 0 nr 77824 ram 77824 (...) [29854.132707] kernel BUG at fs/btrfs/ctree.h:3901! (...) [29854.132771] Call Trace: [29854.132779] [] setup_items_for_insert+0x2dc/0x400 [btrfs] [29854.132791] [] __btrfs_drop_extents+0xba7/0xdd0 [btrfs] [29854.132794] [] ? trace_hardirqs_on_caller+0x16/0x1d0 [29854.132797] [] ? trace_hardirqs_on+0xd/0x10 [29854.132800] [] ? kmem_cache_alloc+0xfe/0x1c0 [29854.132810] [] insert_reserved_file_extent.constprop.66+0xab/0x310 [btrfs] [29854.132820] [] __btrfs_prealloc_file_range+0x116/0x340 [btrfs] [29854.132830] [] btrfs_prealloc_file_range+0x23/0x30 [btrfs] (...) So this is caused by getting an -ENOSPC error while punching a file hole, more specifically, we get -ENOSPC error from __btrfs_drop_extents in the while loop of file.c:btrfs_punch_hole() when it's unable to modify the btree to delete one or more file extent items due to lack of enough free space. When this happens, in btrfs_punch_hole(), we attempt to reclaim free space by switching our transaction block reservation object to root->fs_info->trans_block_rsv, end our transaction and start a new transaction basically - and, we keep increasing our current offset (cur_offset) as long as it's smaller than the end of the target range (lockend) - this makes use leave the loop with cur_offset == drop_end which in turn makes us call fill_holes() for inserting a file extent item that represents a 0 bytes range hole (and this insertion succeeds, as in the meanwhile more space became available). This 0 bytes file hole extent item is a problem because any subsequent caller of __btrfs_drop_extents (regular file writes, or fallocate calls for e.g.), with a start file offset that is equal to the offset of the hole, will not remove this extent item due to the following conditional in the while loop of __btrfs_drop_extents: if (extent_end <= search_start) { path->slots[0]++; goto next_slot; } This later makes the call to setup_items_for_insert() (at the very end of __btrfs_drop_extents), insert a new file extent item with the same offset as the 0 bytes file hole extent item that follows it. Needless is to say that this causes chaos, either when reading the leaf from disk (btree_readpage_end_io_hook), where we perform leaf sanity checks or in subsequent operations that manipulate file extent items, as in the fallocate call as shown by the dmesg trace above. Without my other patch to perform the leaf sanity checks once a leaf is marked as dirty (if the integrity checker is enabled), it would have been much harder to debug this issue. This change might fix a few similar issues reported by users in the mailing list regarding assertion failures in btrfs_set_item_key_safe calls performed by __btrfs_drop_extents, such as the following report: http://comments.gmane.org/gmane.comp.file-systems.btrfs/32938 Asking fill_holes() to create a 0 bytes wide file hole item also produced the first warning in the trace above, as we passed a range to btrfs_drop_extent_cache that has an end smaller (by -1) than its start. On 3.14 kernels this issue manifests itself through leaf corruption, as we get duplicated file extent item keys in a leaf when calling setup_items_for_insert(), but on older kernels, setup_items_for_insert() isn't called by __btrfs_drop_extents(), instead we have callers of __btrfs_drop_extents(), namely the functions inode.c:insert_inline_extent() and inode.c:insert_reserved_file_extent(), calling btrfs_insert_empty_item() to insert the new file extent item, which would fail with error -EEXIST, instead of inserting a duplicated key - which is still a serious issue as it would make all similar file extent item replace operations keep failing if they target the same file range. Signed-off-by: Filipe David Borba Manana Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 0d81fcdd1447a0d3de5e4126be10734bce3c3468 Author: Pavel Shilovsky Date: Sat May 24 16:42:02 2014 +0400 CIFS: Fix memory leaks in SMB2_open commit 663a962151593c69374776e8651238d0da072459 upstream. Signed-off-by: Pavel Shilovsky Reviewed-by: Shirish Pargaonkar Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 0ea9bb58b2823f74ee99ad9efa63e0be5433354e Author: Benjamin LaHaise Date: Tue Jun 24 13:32:51 2014 -0400 aio: fix kernel memory disclosure in io_getevents() introduced in v3.10 commit edfbbf388f293d70bf4b7c0bc38774d05e6f711a upstream. A kernel memory disclosure was introduced in aio_read_events_ring() in v3.10 by commit a31ad380bed817aa25f8830ad23e1a0480fef797. The changes made to aio_read_events_ring() failed to correctly limit the index into ctx->ring_pages[], allowing an attacked to cause the subsequent kmap() of an arbitrary page with a copy_to_user() to copy the contents into userspace. This vulnerability has been assigned CVE-2014-0206. Thanks to Mateusz and Petr for disclosing this issue. This patch applies to v3.12+. A separate backport is needed for 3.10/3.11. Signed-off-by: Benjamin LaHaise Cc: Mateusz Guzik Cc: Petr Matousek Cc: Kent Overstreet Cc: Jeff Moyer Signed-off-by: Greg Kroah-Hartman commit b34e0e1319b31202eb142dcd9688cf7145a30bf6 Author: Benjamin LaHaise Date: Tue Jun 24 13:12:55 2014 -0400 aio: fix aio request leak when events are reaped by userspace commit f8567a3845ac05bb28f3c1b478ef752762bd39ef upstream. The aio cleanups and optimizations by kmo that were merged into the 3.10 tree added a regression for userspace event reaping. Specifically, the reference counts are not decremented if the event is reaped in userspace, leading to the application being unable to submit further aio requests. This patch applies to 3.12+. A separate backport is required for 3.10/3.11. This issue was uncovered as part of CVE-2014-0206. Signed-off-by: Benjamin LaHaise Cc: Kent Overstreet Cc: Mateusz Guzik Cc: Petr Matousek Signed-off-by: Greg Kroah-Hartman commit a23f966716ec70c47083c06e9ddbf3d4fbc80c33 Author: Thomas Gleixner Date: Thu Mar 7 14:53:45 2013 +0100 genirq: Sanitize spurious interrupt detection of threaded irqs commit 1e77d0a1ed7417d2a5a52a7b8d32aea1833faa6c upstream. Till reported that the spurious interrupt detection of threaded interrupts is broken in two ways: - note_interrupt() is called for each action thread of a shared interrupt line. That's wrong as we are only interested whether none of the device drivers felt responsible for the interrupt, but by calling multiple times for a single interrupt line we account IRQ_NONE even if one of the drivers felt responsible. - note_interrupt() when called from the thread handler is not serialized. That leaves the members of irq_desc which are used for the spurious detection unprotected. To solve this we need to defer the spurious detection of a threaded interrupt to the next hardware interrupt context where we have implicit serialization. If note_interrupt is called with action_ret == IRQ_WAKE_THREAD, we check whether the previous interrupt requested a deferred check. If not, we request a deferred check for the next hardware interrupt and return. If set, we check whether one of the interrupt threads signaled success. Depending on this information we feed the result into the spurious detector. If one primary handler of a shared interrupt returns IRQ_HANDLED we disable the deferred check of irq threads on the same line, as we have found at least one device driver who cared. Reported-by: Till Straumann Signed-off-by: Thomas Gleixner Tested-by: Austin Schuh Cc: Oliver Hartkopp Cc: Wolfgang Grandegger Cc: Pavel Pisa Cc: Marc Kleine-Budde Cc: linux-can@vger.kernel.org Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1303071450130.22263@ionos Signed-off-by: Greg Kroah-Hartman commit 9f6900b6cf1f542bb872a180bb3b21fb2074c1a8 Author: Benjamin Herrenschmidt Date: Mon Jun 16 19:40:20 2014 +1000 Revert "offb: Add palette hack for little endian" commit 68986c9f0f4552c34c248501eb0c690553866d6e upstream. This reverts commit e1edf18b20076da83dd231dbd2146cbbc31c0b14. This patch was a misguided attempt at fixing offb for LE ppc64 kernels on BE qemu but is just wrong ... it breaks real LE/LE setups, LE with real HW, and existing mixed endian systems that did the fight thing with the appropriate device-tree property. Bad reviewing on my part, sorry. The right fix is to either make qemu change its endian when the guest changes endian (working on that) or to use the existing foreign endian support. Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit bc862d297d12807126ec4abf780babc4f6770641 Author: Alex Deucher Date: Sat Jun 7 11:31:25 2014 -0400 Revert "drm/radeon: use variable UVD clocks" commit 0690a229c69f40a6c9c459ab455c85df49822525 upstream. This caused reduced performance for some users with advanced post processing enabled. We need a better method to pick the UVD state based on the amount of post processing required or tune the advanced post processing to fit within the lower power state envelope. This reverts commit 14a9579ddbf15dd1992a9481a4ec80b0b91656d5. Signed-off-by: Greg Kroah-Hartman commit 60ee64fa32a79bd6438cef27836332d58d49d1bf Author: Mike Frysinger Date: Sun May 4 20:43:15 2014 -0400 x86, x32: Use compat shims for io_{setup,submit} commit 7fd44dacdd803c0bbf38bf478d51d280902bb0f1 upstream. The io_setup takes a pointer to a context id of type aio_context_t. This in turn is typed to a __kernel_ulong_t. We could tweak the exported headers to define this as a 64bit quantity for specific ABIs, but since we already have a 32bit compat shim for the x86 ABI, let's just re-use that logic. The libaio package is also written to expect this as a pointer type, so a compat shim would simplify that. The io_submit func operates on an array of pointers to iocb structs. Padding out the array to be 64bit aligned is a huge pain, so convert it over to the existing compat shim too. We don't convert io_getevents to the compat func as its only purpose is to handle the timespec struct, and the x32 ABI uses 64bit times. With this change, the libaio package can now pass its testsuite when built for the x32 ABI. Signed-off-by: Mike Frysinger Link: http://lkml.kernel.org/r/1399250595-5005-1-git-send-email-vapier@gentoo.org Cc: H.J. Lu Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 0d8ab48e3cc886d9d3ba9de66a1212c151c38b11 Author: H. Peter Anvin Date: Wed Apr 30 14:03:25 2014 -0700 x86-32, espfix: Remove filter for espfix32 due to race commit 246f2d2ee1d715e1077fc47d61c394569c8ee692 upstream. It is not safe to use LAR to filter when to go down the espfix path, because the LDT is per-process (rather than per-thread) and another thread might change the descriptors behind our back. Fortunately it is always *safe* (if a bit slow) to go down the espfix path, and a 32-bit LDT stack segment is extremely rare. Signed-off-by: H. Peter Anvin Link: http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-hpa@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 6b4e1805412053a0f7dcb7ae0a2d92c175cd16d4 Author: Will Deacon Date: Wed Jun 18 14:06:27 2014 +0100 arm64: mm: remove broken &= operator from pmd_mknotpresent commit e3a920afc3482e954834a4ed95908c4bc5e4c000 upstream. This should be a plain old '&' and could easily lead to undefined behaviour if the target of a pmd_mknotpresent invocation was the same as the parameter. Fixes: 9c7e535fcc17 (arm64: mm: Route pmd thp functions through pte equivalents) Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 92abb0be9f448c2c7e7d217ba1f8674aa323d31c Author: Suravee Suthikulpanit Date: Fri Jun 6 23:07:16 2014 +0100 arm64/dma: Removing ARCH_HAS_DMA_GET_REQUIRED_MASK macro commit f3a183cb422574014538017b5b291a416396f97e upstream. Arm64 does not define dma_get_required_mask() function. Therefore, it should not define the ARCH_HAS_DMA_GET_REQUIRED_MASK. This causes build errors in some device drivers (e.g. mpt2sas) Signed-off-by: Suravee Suthikulpanit Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 04c4b55db2b88ffd4f2fd0e30e2f0a6d1da3ff4e Author: Will Deacon Date: Mon Jun 2 11:47:29 2014 +0100 arm64: uid16: fix __kernel_old_{gid,uid}_t definitions commit 34c65c43f1518bf85f93526ad373adc6a683b4c5 upstream. Whilst native arm64 applications don't have the 16-bit UID/GID syscalls wired up, compat tasks can still access them. The 16-bit wrappers for these syscalls use __kernel_old_uid_t and __kernel_old_gid_t, which must be 16-bit data types to maintain compatibility with the 16-bit UIDs used by compat applications. This patch defines 16-bit __kernel_old_{gid,uid}_t types for arm64 instead of using the 32-bit types provided by asm-generic. Signed-off-by: Will Deacon Acked-by: Arnd Bergmann Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit a198057408f45226bd970c808bf93010a6e12b32 Author: Jason Cooper Date: Wed Jun 4 13:41:20 2014 +0000 ARM: mvebu: DT: fix OpenBlocks AX3-4 RAM size commit e47043aea3853a74a9aa5726a1faa916d7462ab7 upstream. The OpenBlocks AX3-4 has a non-DT bootloader. It also comes with 1GB of soldered on RAM, and a DIMM slot for expansion. Unfortunately, atags_to_fdt() doesn't work in big-endian mode, so we see the following failure when attempting to boot a big-endian kernel: 686 slab pages 17 pages shared 0 pages swap cached [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name Kernel panic - not syncing: Out of memory and no killable processes... CPU: 1 PID: 351 Comm: kworker/u4:0 Not tainted 3.15.0-rc8-next-20140603 #1 [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x78/0x94) [] (dump_stack) from [] (panic+0x90/0x21c) [] (panic) from [] (out_of_memory+0x320/0x340) [] (out_of_memory) from [] (__alloc_pages_nodemask+0x874/0x930) [] (__alloc_pages_nodemask) from [] (handle_mm_fault+0x744/0x96c) [] (handle_mm_fault) from [] (__get_user_pages+0xd0/0x4c0) [] (__get_user_pages) from [] (get_arg_page+0x54/0xbc) [] (get_arg_page) from [] (copy_strings+0x278/0x29c) [] (copy_strings) from [] (copy_strings_kernel+0x20/0x28) [] (copy_strings_kernel) from [] (do_execve+0x3a8/0x4c8) [] (do_execve) from [] (____call_usermodehelper+0x15c/0x194) [] (____call_usermodehelper) from [] (ret_from_fork+0x14/0x3c) CPU0: stopping CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.0-rc8-next-20140603 #1 [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x78/0x94) [] (dump_stack) from [] (handle_IPI+0x138/0x174) [] (handle_IPI) from [] (armada_370_xp_handle_irq+0xb0/0xcc) [] (armada_370_xp_handle_irq) from [] (__irq_svc+0x40/0x50) Exception stack(0xc0b6bf68 to 0xc0b6bfb0) bf60: e9fad598 00000000 00f509a3 00000000 c0b6a000 c0b724c4 bf80: c0b72458 c0b6a000 00000000 00000000 c0b66da0 c0b6a000 00000000 c0b6bfb0 bfa0: c027bb94 c027bb24 60000313 ffffffff [] (__irq_svc) from [] (cpu_startup_entry+0x54/0x214) [] (cpu_startup_entry) from [] (start_kernel+0x318/0x37c) [] (start_kernel) from [<00208078>] (0x208078) ---[ end Kernel panic - not syncing: Out of memory and no killable processes... A similar failure will also occur if ARM_ATAG_DTB_COMPAT isn't selected. Fix this by setting a sane default (1 GB) in the dts file. Signed-off-by: Jason Cooper Tested-by: Kevin Hilman Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit fecb45f70819ed260fc801c27ef41bf573ee7739 Author: Jaegeuk Kim Date: Thu Apr 24 09:49:52 2014 +0900 f2fs: submit bio at the reclaim path commit 2aea39eca6b68d6ae7eb545332df0695f56a3d3f upstream. If f2fs_write_data_page is called through the reclaim path, we should submit the bio right away. This patch resolves the following issue that Marc Dietrich reported. "It took me a while to bisect a problem which causes my ARM (tegra2) netbook to frequently stall for 5-10 seconds when I enable EXA acceleration (opentegra experimental ddx)." And this patch fixes that. Reported-by: Marc Dietrich Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 7d9710389b7c1f975e290c0f1b557245a3abe0d5 Author: Sagi Grimberg Date: Wed Jun 11 12:09:59 2014 +0300 TARGET/sbc,loopback: Adjust command data length in case pi exists on the wire commit e2a4f55c6498b59a17a85a1bb6db122a993ffe02 upstream. In various areas of the code, it is assumed that se_cmd->data_length describes pure data. In case that protection information exists over the wire (protect bits is are on) the target core re-calculates the data length from the CDB and the backed device block size (instead of each transport peeking in the cdb). Modify loopback device to include protection information in the transferred data length (like other scsi transports). Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 04423ddea30a7fb7232636eda8aed55ea5b972fe Author: Sagi Grimberg Date: Wed Jun 11 12:09:58 2014 +0300 libiscsi, iser: Adjust data_length to include protection information commit d77e65350f2d82dfa0557707d505711f5a43c8fd upstream. In case protection information exists over the wire iscsi header data length is required to include it. Use protection information aware scsi helpers to set the correct transfer length. In order to avoid breakage, remove iser transfer length checks for each task as they are not always true and somewhat redundant anyway. Signed-off-by: Sagi Grimberg Reviewed-by: Mike Christie Acked-by: Mike Christie Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit ff04e8f8acb5ccc792d905b58f5e3353f4e26753 Author: Sagi Grimberg Date: Wed Jun 11 12:09:57 2014 +0300 scsi_cmnd: Introduce scsi_transfer_length helper commit 8846bab180fa2bcfe02d4ba5288fbaba12c8f4f3 upstream. In case protection information exists on the wire scsi transports should include it in the transfer byte count (even if protection information does not exist in the host memory space). This helper will compute the total transfer length from the scsi command data length and protection attributes. Signed-off-by: Sagi Grimberg Signed-off-by: Martin K. Petersen Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 7062995ffa52d527b90f2c5b6379ebd64a00231b Author: Roland Dreier Date: Tue Jun 10 11:07:47 2014 -0700 target: Report correct response length for some commands commit 2426bd456a61407388b6e61fc5f98dbcbebc50e2 upstream. When an initiator sends an allocation length bigger than what its command consumes, the target should only return the actual response data and set the residual length to the unused part of the allocation length. Add a helper function that command handlers (INQUIRY, READ CAPACITY, etc) can use to do this correctly, and use this code to get the correct residual for commands that don't use the full initiator allocation in the handlers for READ CAPACITY, READ CAPACITY(16), INQUIRY, MODE SENSE and REPORT LUNS. This addresses a handful of failures as reported by Christophe with the Windows Certification Kit: http://permalink.gmane.org/gmane.linux.scsi.target.devel/6515 Signed-off-by: Roland Dreier Tested-by: Christophe Vu-Brugier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit cc74a0efa82c7b8ae634e68f20c2b414eed99cee Author: Sagi Grimberg Date: Tue Jun 10 18:27:59 2014 +0300 Target/iscsi: Fix sendtargets response pdu for iser transport commit 22c7aaa57e80853b4904a46c18f97db0036a3b97 upstream. In case the transport is iser we should not include the iscsi target info in the sendtargets text response pdu. This causes sendtargets response to include the target info twice. Modify iscsit_build_sendtargets_response to filter transport types that don't match. Signed-off-by: Sagi Grimberg Reported-by: Slava Shwartsman Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 0df3f92bba2f5c07e6dfdfe72e80bf5f00a34277 Author: Sagi Grimberg Date: Tue Jun 10 13:41:41 2014 +0300 Target/iser: Fix a wrong dereference in case discovery session is over iser commit e0546fc1ba66c90cb38a5764357366267d3e58e4 upstream. In case the discovery session is carried over iser, we can't access the assumed network portal since the default portal is used. In this case we don't really need to allocate the fastreg pool, just prepare to the text pdu that will follow. Signed-off-by: Sagi Grimberg Reported-by: Alex Tabachnik Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 7b93e2d1bc8076a6d9649249397d9e703fa3e2d0 Author: Nicholas Bellinger Date: Tue Jun 10 04:03:54 2014 +0000 iscsi-target: Fix ABORT_TASK + connection reset iscsi_queue_req memory leak commit bbc050488525e1ab1194c27355f63c66814385b8 upstream. This patch fixes a iscsi_queue_req memory leak when ABORT_TASK response has been queued by TFO->queue_tm_rsp() -> lio_queue_tm_rsp() after a long standing I/O completes, but the connection has already reset and waiting for cleanup to complete in iscsit_release_commands_from_conn() -> transport_generic_free_cmd() -> transport_wait_for_tasks() code. It moves iscsit_free_queue_reqs_for_conn() after the per-connection command list has been released, so that the associated se_cmd tag can be completed + released by target-core before freeing any remaining iscsi_queue_req memory for the connection generated by lio_queue_tm_rsp(). Cc: Thomas Glanzmann Cc: Charalampos Pournaris Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit e6a77ef4776bd9c5ed70db30b8835b094442dbd1 Author: Nicholas Bellinger Date: Mon Jun 9 23:36:51 2014 +0000 target: Use complete_all for se_cmd->t_transport_stop_comp commit a95d6511303b848da45ee27b35018bb58087bdc6 upstream. This patch fixes a bug where multiple waiters on ->t_transport_stop_comp occurs due to a concurrent ABORT_TASK and session reset both invoking transport_wait_for_tasks(), while waiting for the associated se_cmd descriptor backend processing to complete. For this case, complete_all() should be invoked in order to wake up both waiters in core_tmr_abort_task() + transport_generic_free_cmd() process contexts. Cc: Thomas Glanzmann Cc: Charalampos Pournaris Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit fef5453a45973229e7b9545c5f88a6654271254d Author: Nicholas Bellinger Date: Mon Jun 9 23:13:20 2014 +0000 target: Set CMD_T_ACTIVE bit for Task Management Requests commit f15e9cd910c4d9da7de43f2181f362082fc45f0f upstream. This patch fixes a bug where se_cmd descriptors associated with a Task Management Request (TMR) where not setting CMD_T_ACTIVE before being dispatched into target_tmr_work() process context. This is required in order for transport_generic_free_cmd() -> transport_wait_for_tasks() to wait on se_cmd->t_transport_stop_comp if a session reset event occurs while an ABORT_TASK is outstanding waiting for another I/O to complete. Cc: Thomas Glanzmann Cc: Charalampos Pournaris Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 5b50bf7e57c68316c1bda049d7b2c101ab7a8dcf Author: Sagi Grimberg Date: Tue May 20 13:28:11 2014 +0300 Target/iser: Gracefully reject T10-PI enabled connect request if not supported commit 5f80ff8eccba50832dcc640ac89add4c7fced963 upstream. In case user chose to set T10-PI enable on the target while the IB device does not support it, gracefully reject the request. Reported-by: Slava Shwartsman Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit d616f6745dbf0b178e8f645a7a0e662ccc4edd0d Author: Sagi Grimberg Date: Mon May 19 17:44:25 2014 +0300 Target/iser: Wait for proper cleanup before unloading commit f5ebec9629cf78eeeea4b8258882a9f439ab2404 upstream. disconnected_handler works are scheduled on system_wq. When attempting to unload, first make sure all works have cleaned up. Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 60acd16827caff96a301edfcac719bc9bd7e060d Author: Sagi Grimberg Date: Mon May 19 17:44:24 2014 +0300 Target/iser: Improve cm events handling commit 88c4015fda6d014392f76d3b1688347950d7a12d upstream. There are 4 RDMA_CM events that all basically mean that the user should teardown the IB connection: - DISCONNECTED - ADDR_CHANGE - DEVICE_REMOVAL - TIMEWAIT_EXIT Only in DISCONNECTED/ADDR_CHANGE it makes sense to call rdma_disconnect (send DREQ/DREP to our initiator). So we keep the same teardown handler for all of them but only indicate calling rdma_disconnect for the relevant events. This patch also removes redundant debug prints for each single event. v2 changes: - Call isert_disconnected_handler() for DEVICE_REMOVAL (Or + Sag) Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 5a1e941c438549d06038184a92cb466969bf0879 Author: Sagi Grimberg Date: Mon May 19 17:44:23 2014 +0300 Target/iser: Fix hangs in connection teardown commit 9d49f5e284e700576f3b65f1e28dea8539da6661 upstream. In ungraceful teardowns isert close flows seem racy such that isert_wait_conn hangs as RDMA_CM_EVENT_DISCONNECTED never gets invoked (no one called rdma_disconnect). Both graceful and ungraceful teardowns will have rx flush errors (isert posts a batch once connection is established). Once all flush errors are consumed we invoke isert_wait_conn and it will be responsible for calling rdma_disconnect. This way it can be sure that rdma_disconnect was called and it won't wait forever. This patch also removes the logout_posted indicator. either the logout completion was consumed and no problem decrementing the post_send_buf_count, or it was consumed as a flush error. no point of keeping it for isert_wait_conn as there is no danger that isert_conn will be accidentally removed while it is running. (Drop unnecessary sleep_on_conn_wait_comp check in isert_cq_rx_comp_err - nab) Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit ec47f51927e9cc67d60362835b26af756a7faded Author: Sagi Grimberg Date: Mon May 19 17:44:22 2014 +0300 Target/iser: Bail from accept_np if np_thread is trying to close commit e346ab343f4f58c12a96725c7b13df9cc2ad56f6 upstream. In case np_thread state is in RESET/SHUTDOWN/EXIT states, no point for isert to stall there as we may get a hang in case no one will wake it up later. Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit dc87ca321a9c8a6d1cb59c0274ce2f251683bb8a Author: Johan Hedberg Date: Mon Jun 2 10:12:44 2014 +0300 Bluetooth: Fix missing check for FIPS security level commit f3fb0b58c85666f73139963a7a04d7878f3d22c9 upstream. When checking whether a legacy link key provides at least HIGH security level we also need to check for FIPS level which is one step above HIGH. This patch fixes a missing check in the hci_link_key_request_evt() function. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 087ad42b882be734e335a5534bb5987fda8aab1a Author: Johan Hedberg Date: Sun Jun 1 09:45:24 2014 +0300 Bluetooth: Fix requiring SMP MITM for outgoing connections commit 79897d2097a629179e142014ecd3cdce6eac7f0e upstream. Due to recent changes to the way that the MITM requirement is set for outgoing pairing attempts we can no longer rely on the hcon->auth_type variable (which is actually good since it was formed from BR/EDR concepts that don't really exist for SMP). To match the logic that BR/EDR now uses simply rely on the local IO capability and/or needed security level to set the MITM requirement for outgoing pairing requests. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit c714b3b6dbe642ee9c9e3c4d4696518aa6b09cc0 Author: Johan Hedberg Date: Fri May 30 14:45:19 2014 +0300 Bluetooth: Fix authentication check for FIPS security level commit 7e3691e13ab51f3491e996e2edaf99b173621288 upstream. When checking whether we need to request authentication or not we should include HCI_SECURITY_FIPS to the levels that always need authentication. This patch fixes check for it in the hci_outgoing_auth_needed() function. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit df065634d8458d1fa5113ca323e9c770295b6d95 Author: Jukka Taimisto Date: Thu May 22 10:02:39 2014 +0000 Bluetooth: Fix L2CAP deadlock commit 8a96f3cd22878fc0bb564a8478a6e17c0b8dca73 upstream. -[0x01 Introduction We have found a programming error causing a deadlock in Bluetooth subsystem of Linux kernel. The problem is caused by missing release_sock() call when L2CAP connection creation fails due full accept queue. The issue can be reproduced with 3.15-rc5 kernel and is also present in earlier kernels. -[0x02 Details The problem occurs when multiple L2CAP connections are created to a PSM which contains listening socket (like SDP) and left pending, for example, configuration (the underlying ACL link is not disconnected between connections). When L2CAP connection request is received and listening socket is found the l2cap_sock_new_connection_cb() function (net/bluetooth/l2cap_sock.c) is called. This function locks the 'parent' socket and then checks if the accept queue is full. 1178 lock_sock(parent); 1179 1180 /* Check for backlog size */ 1181 if (sk_acceptq_is_full(parent)) { 1182 BT_DBG("backlog full %d", parent->sk_ack_backlog); 1183 return NULL; 1184 } If case the accept queue is full NULL is returned, but the 'parent' socket is not released. Thus when next L2CAP connection request is received the code blocks on lock_sock() since the parent is still locked. Also note that for connections already established and waiting for configuration to complete a timeout will occur and l2cap_chan_timeout() (net/bluetooth/l2cap_core.c) will be called. All threads calling this function will also be blocked waiting for the channel mutex since the thread which is waiting on lock_sock() alread holds the channel mutex. We were able to reproduce this by sending continuously L2CAP connection request followed by disconnection request containing invalid CID. This left the created connections pending configuration. After the deadlock occurs it is impossible to kill bluetoothd, btmon will not get any more data etc. requiring reboot to recover. -[0x03 Fix Releasing the 'parent' socket when l2cap_sock_new_connection_cb() returns NULL seems to fix the issue. Signed-off-by: Jukka Taimisto Reported-by: Tommi Mäkilä Signed-off-by: Johan Hedberg Signed-off-by: Greg Kroah-Hartman commit e287dd769cfb223db1bd4bdf1ad3c3936f368c3d Author: Jukka Rissanen Date: Tue May 27 11:33:22 2014 +0300 Bluetooth: 6LoWPAN: Fix MAC address universal/local bit handling commit 62bbd5b35994eaf30519f126765d7f6af9cd3526 upstream. The universal/local bit handling was incorrectly done in the code. So when setting EUI address from BD address we do this: - If BD address type is PUBLIC, then we clear the universal bit in EUI address. If the address type is RANDOM, then the universal bit is set (BT 6lowpan draft chapter 3.2.2) - After this we invert the universal/local bit according to RFC 2464 When figuring out BD address we do the reverse: - Take EUI address from stateless IPv6 address, invert the universal/local bit according to RFC 2464 - If universal bit is 1 in this modified EUI address, then address type is set to RANDOM, otherwise it is PUBLIC Note that 6lowpan_iphc.[ch] does the final toggling of U/L bit before sending or receiving the network packet. Signed-off-by: Jukka Rissanen Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit b29d1fa928a410cb37afc4a7e22aba1ca231bddc Author: Felipe Balbi Date: Wed Apr 23 09:58:26 2014 -0500 bluetooth: hci_ldisc: fix deadlock condition commit da64c27d3c93ee9f89956b9de86c4127eb244494 upstream. LDISCs shouldn't call tty->ops->write() from within ->write_wakeup(). ->write_wakeup() is called with port lock taken and IRQs disabled, tty->ops->write() will try to acquire the same port lock and we will deadlock. Acked-by: Marcel Holtmann Reviewed-by: Peter Hurley Reported-by: Huang Shijie Signed-off-by: Felipe Balbi Tested-by: Andreas Bießmann Signed-off-by: Greg Kroah-Hartman commit d9d4f29b1e0546096112fd9586e700db26af5379 Author: Chander Kashyap Date: Fri May 16 16:21:17 2014 +0530 PM / OPP: fix incorrect OPP count handling in of_init_opp_table commit 086abb58590a4df73e8a6ed71fd418826937cd46 upstream. In of_init_opp_table function, if a failure to add an OPP is detected, the count of OPPs, yet to be added is not updated. Fix this by decrementing this count on failure as well. Signed-off-by: Chander Kashyap Signed-off-by: Inderpal Singh Acked-by: Viresh Kumar Acked-by: Nishanth Menon Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit a1e7be05dd5f0c6f8e98fcbcd5a1a2ee55355e6b Author: Pekon Gupta Date: Mon May 19 16:52:36 2014 +0530 ARM: OMAP2+: gpmc: enable BCH_HW ecc-scheme for AM43xx platforms commit 2e091d13e65d26f21159323b95b426e5bc42670c upstream. Fixes: commit 0611c41934ab35ce84dea34ab291897ad3cbc7be ARM: OMAP2+: gpmc: update gpmc_hwecc_bch_capable() for new platforms and ECC schemes Though the commit log of above commit mentions AM43xx platforms, but code change missed AM43xx. This patch adds AM43xx to list of those SoC which have built-in ELM hardware engine, so that BCH ecc-schemes with hardware error-correction can be enabled on AM43xx devices. Reported-by: Roger Quadros Signed-off-by: Pekon Gupta Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 00d5951b489c8de9f27f335e0c091dfca6683220 Author: Jianguo Wu Date: Thu Apr 24 03:45:56 2014 +0100 ARM: 8037/1: mm: support big-endian page tables commit 86f40622af7329375e38f282f6c0aab95f3e5f72 upstream. When enable LPAE and big-endian in a hisilicon board, while specify mem=384M mem=512M@7680M, will get bad page state: Freeing unused kernel memory: 180K (c0466000 - c0493000) BUG: Bad page state in process init pfn:fa442 page:c7749840 count:0 mapcount:-1 mapping: (null) index:0x0 page flags: 0x40000400(reserved) Modules linked in: CPU: 0 PID: 1 Comm: init Not tainted 3.10.27+ #66 [] (unwind_backtrace+0x0/0x11c) from [] (show_stack+0x10/0x14) [] (show_stack+0x10/0x14) from [] (bad_page+0xd4/0x104) [] (bad_page+0xd4/0x104) from [] (free_pages_prepare+0xa8/0x14c) [] (free_pages_prepare+0xa8/0x14c) from [] (free_hot_cold_page+0x18/0xf0) [] (free_hot_cold_page+0x18/0xf0) from [] (handle_pte_fault+0xcf4/0xdc8) [] (handle_pte_fault+0xcf4/0xdc8) from [] (handle_mm_fault+0xf4/0x120) [] (handle_mm_fault+0xf4/0x120) from [] (do_page_fault+0xfc/0x354) [] (do_page_fault+0xfc/0x354) from [] (do_DataAbort+0x2c/0x90) [] (do_DataAbort+0x2c/0x90) from [] (__dabt_usr+0x34/0x40) The bad pfn:fa442 is not system memory(mem=384M mem=512M@7680M), after debugging, I find in page fault handler, will get wrong pfn from pte just after set pte, as follow: do_anonymous_page() { ... set_pte_at(mm, address, page_table, entry); //debug code pfn = pte_pfn(entry); pr_info("pfn:0x%lx, pte:0x%llxn", pfn, pte_val(entry)); //read out the pte just set new_pte = pte_offset_map(pmd, address); new_pfn = pte_pfn(*new_pte); pr_info("new pfn:0x%lx, new pte:0x%llxn", pfn, pte_val(entry)); ... } pfn: 0x1fa4f5, pte:0xc00001fa4f575f new_pfn:0xfa4f5, new_pte:0xc00000fa4f5f5f //new pfn/pte is wrong. The bug is happened in cpu_v7_set_pte_ext(ptep, pte): An LPAE PTE is a 64bit quantity, passed to cpu_v7_set_pte_ext in the r2 and r3 registers. On an LE kernel, r2 contains the LSB of the PTE, and r3 the MSB. On a BE kernel, the assignment is reversed. Unfortunately, the current code always assumes the LE case, leading to corruption of the PTE when clearing/setting bits. This patch fixes this issue much like it has been done already in the cpu_v7_switch_mm case. Signed-off-by: Jianguo Wu Acked-by: Marc Zyngier Acked-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 31ce3db939c658722d402159af2755a356366740 Author: Russell King Date: Sat May 3 11:03:28 2014 +0100 ARM: stacktrace: avoid listing stacktrace functions in stacktrace commit 3683f44c42e991d313dc301504ee0fca1aeb8580 upstream. While debugging the FEC ethernet driver using stacktrace, it was noticed that the stacktraces always begin as follows: [] save_stack_trace_tsk+0x0/0x98 [] save_stack_trace+0x24/0x28 ... This is because the stack trace code includes the stack frames for itself. This is incorrect behaviour, and also leads to "skip" doing the wrong thing (which is the number of stack frames to avoid recording.) Perversely, it does the right thing when passed a non-current thread. Fix this by ensuring that we have a known constant number of frames above the main stack trace function, and always skip these. Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit ba04d3758729d795c7ffca9f8d7dd1c4e07ac2c8 Author: Hans Verkuil Date: Thu Apr 17 07:24:31 2014 -0300 media: saa7134: fix regression with tvtime commit 17e7f1b515803e1a79b246688aacbddd2e34165d upstream. This solves this bug: https://bugzilla.kernel.org/show_bug.cgi?id=73361 The problem is that when you quit tvtime it calls STREAMOFF, but then it queues a bunch of buffers for no good reason before closing the file descriptor. In the past closing the fd would free the vb queue since that was part of the file handle struct. Since that was moved to the global struct that no longer happened. This wouldn't be a problem, but the extra QBUF calls that tvtime does meant that the buffer list in videobuf (q->stream) contained buffers, so REQBUFS would fail with -EBUSY. The solution is to init the list head explicitly when releasing the file descriptor and to not free the video resource when calling streamoff. The real fix will hopefully go into kernel 3.16 when the vb2 conversion is merged. Basically the saa7134 driver with the old videobuf is so full of holes it ain't funny anymore, so consider this a band-aid for kernels 3.14 and 15. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 8def99cd33c20db5bc9296c1d55ed96c2e12f9ae Author: Pali Rohár Date: Tue Apr 22 12:02:39 2014 -0300 media: radio-bcm2048: fix wrong overflow check commit 5d60122b7e30f275593df93b39a76d3c2663cfc2 upstream. This patch fixes an off by one check in bcm2048_set_region(). Reported-by: Dan Carpenter Signed-off-by: Pali Rohár Signed-off-by: Pavel Machek Signed-off-by: Dan Carpenter Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 4a579221c86dc35646e5c314804c876524a20675 Author: Olivier Langlois Date: Fri Mar 28 02:42:38 2014 -0300 media: uvcvideo: Fix clock param realtime setting commit 3b35fc81e7ec552147a4fd843d0da0bbbe4ef253 upstream. timestamps in v4l2 buffers returned to userspace are updated in uvc_video_clock_update() which uses timestamps fetched from uvc_video_clock_decode() by calling unconditionally ktime_get_ts(). Hence setting the module clock param to realtime has no effect before this patch. This has been tested with ffmpeg: ffmpeg -y -f v4l2 -input_format yuyv422 -video_size 640x480 -framerate 30 -i /dev/video0 \ -f alsa -acodec pcm_s16le -ar 16000 -ac 1 -i default \ -c:v libx264 -preset ultrafast \ -c:a libfdk_aac \ out.mkv and inspecting the v4l2 input starting timestamp. Signed-off-by: Olivier Langlois Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 61078ded4727ee2822a2aaa61ec71b4a1818cc90 Author: Thomas Gleixner Date: Wed Jun 11 18:44:04 2014 +0000 rtmutex: Plug slow unlock race commit 27e35715df54cbc4f2d044f681802ae30479e7fb upstream. When the rtmutex fast path is enabled the slow unlock function can create the following situation: spin_lock(foo->m->wait_lock); foo->m->owner = NULL; rt_mutex_lock(foo->m); <-- fast path free = atomic_dec_and_test(foo->refcnt); rt_mutex_unlock(foo->m); <-- fast path if (free) kfree(foo); spin_unlock(foo->m->wait_lock); <--- Use after free. Plug the race by changing the slow unlock to the following scheme: while (!rt_mutex_has_waiters(m)) { /* Clear the waiters bit in m->owner */ clear_rt_mutex_waiters(m); owner = rt_mutex_owner(m); spin_unlock(m->wait_lock); if (cmpxchg(m->owner, owner, 0) == owner) return; spin_lock(m->wait_lock); } So in case of a new waiter incoming while the owner tries the slow path unlock we have two situations: unlock(wait_lock); lock(wait_lock); cmpxchg(p, owner, 0) == owner mark_rt_mutex_waiters(lock); acquire(lock); Or: unlock(wait_lock); lock(wait_lock); mark_rt_mutex_waiters(lock); cmpxchg(p, owner, 0) != owner enqueue_waiter(); unlock(wait_lock); lock(wait_lock); wakeup_next waiter(); unlock(wait_lock); lock(wait_lock); acquire(lock); If the fast path is disabled, then the simple m->owner = NULL; unlock(m->wait_lock); is sufficient as all access to m->owner is serialized via m->wait_lock; Also document and clarify the wakeup_next_waiter function as suggested by Oleg Nesterov. Reported-by: Steven Rostedt Signed-off-by: Thomas Gleixner Reviewed-by: Steven Rostedt Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20140611183852.937945560@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 2b1f3807ed9cafb59c956ce76a05d25e67103f2e Author: Thomas Gleixner Date: Thu Jun 5 12:34:23 2014 +0200 rtmutex: Handle deadlock detection smarter commit 3d5c9340d1949733eb37616abd15db36aef9a57c upstream. Even in the case when deadlock detection is not requested by the caller, we can detect deadlocks. Right now the code stops the lock chain walk and keeps the waiter enqueued, even on itself. Silly not to yell when such a scenario is detected and to keep the waiter enqueued. Return -EDEADLK unconditionally and handle it at the call sites. The futex calls return -EDEADLK. The non futex ones dequeue the waiter, throw a warning and put the task into a schedule loop. Tagged for stable as it makes the code more robust. Signed-off-by: Thomas Gleixner Cc: Steven Rostedt Cc: Peter Zijlstra Cc: Brad Mouring Link: http://lkml.kernel.org/r/20140605152801.836501969@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit ecb22e03989334008e6f51ea5e3ac5d4b6101f8f Author: Thomas Gleixner Date: Thu Jun 5 11:16:12 2014 +0200 rtmutex: Detect changes in the pi lock chain commit 82084984383babe728e6e3c9a8e5c46278091315 upstream. When we walk the lock chain, we drop all locks after each step. So the lock chain can change under us before we reacquire the locks. That's harmless in principle as we just follow the wrong lock path. But it can lead to a false positive in the dead lock detection logic: T0 holds L0 T0 blocks on L1 held by T1 T1 blocks on L2 held by T2 T2 blocks on L3 held by T3 T4 blocks on L4 held by T4 Now we walk the chain lock T1 -> lock L2 -> adjust L2 -> unlock T1 -> lock T2 -> adjust T2 -> drop locks T2 times out and blocks on L0 Now we continue: lock T2 -> lock L0 -> deadlock detected, but it's not a deadlock at all. Brad tried to work around that in the deadlock detection logic itself, but the more I looked at it the less I liked it, because it's crystal ball magic after the fact. We actually can detect a chain change very simple: lock T1 -> lock L2 -> adjust L2 -> unlock T1 -> lock T2 -> adjust T2 -> next_lock = T2->pi_blocked_on->lock; drop locks T2 times out and blocks on L0 Now we continue: lock T2 -> if (next_lock != T2->pi_blocked_on->lock) return; So if we detect that T2 is now blocked on a different lock we stop the chain walk. That's also correct in the following scenario: lock T1 -> lock L2 -> adjust L2 -> unlock T1 -> lock T2 -> adjust T2 -> next_lock = T2->pi_blocked_on->lock; drop locks T3 times out and drops L3 T2 acquires L3 and blocks on L4 now Now we continue: lock T2 -> if (next_lock != T2->pi_blocked_on->lock) return; We don't have to follow up the chain at that point, because T2 propagated our priority up to T4 already. [ Folded a cleanup patch from peterz ] Signed-off-by: Thomas Gleixner Reported-by: Brad Mouring Cc: Steven Rostedt Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20140605152801.930031935@linutronix.de Signed-off-by: Greg Kroah-Hartman commit da6d600b71f9f8d8bd042015557857e5e68ffc97 Author: Rafael J. Wysocki Date: Fri Jun 13 01:17:03 2014 +0200 ACPI / ia64 / sba_iommu: Restore the working initialization ordering commit 12e27b115472ad0f3b142ddf59d3998305984408 upstream. Commit 66345d5f79fc (ACPI / ia64 / sba_iommu: Use ACPI scan handler for device discovery) changed the ordering of SBA (System Bus Adapter) IOMMU initialization with respect to the PCI host bridge initialization which broke things inadvertently, because the SBA IOMMU initialization code has to run after the PCI host bridge has been initialized. Fix that by reworking the SBA IOMMU ACPI scan handler so that it claims the discovered matching ACPI device objects without attempting to initialize anything and move the entire SBA IOMMU initialization to sba_init() that runs after the PCI bus has been enumerated. Link: https://bugzilla.kernel.org/show_bug.cgi?id=76691 Fixes: 66345d5f79fc (ACPI / ia64 / sba_iommu: Use ACPI scan handler for device discovery) Reported-and-tested-by: Émeric Maschino Cc: Tony Luck Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 46da9df5bee28fcb8ee645226b6420438e806500 Author: Rafael J. Wysocki Date: Tue Jun 10 22:46:35 2014 +0200 ACPI / hotplug / PCI: Add hotplug contexts to PCI host bridges commit 882d18a702c66404fcb62b84748f719f9b47441c upstream. After relatively recent changes in the ACPI-based PCI hotplug (ACPIPHP) code, the acpiphp_check_host_bridge() executed for PCI host bridges via acpi_pci_root_scan_dependent() doesn't do anything useful, because those bridges do not have hotplug contexts. That happens by mistake, so fix it by making acpiphp_enumerate_slots() add hotplug contexts to PCI host bridges too and modify acpiphp_remove_slots() to drop those contexts for host bridges as appropriate. Link: https://bugzilla.kernel.org/show_bug.cgi?id=76901 Fixes: 2d8b1d566a5f (ACPI / hotplug / PCI: Get rid of check_sub_bridges()) Reported-and-tested-by: Gavin Guo Acked-by: Bjorn Helgaas Reviewed-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 582639a51a66dfa233b66cf08619f78fdc2bbf24 Author: Lv Zheng Date: Mon May 12 15:50:16 2014 +0800 ACPI: Fix conflict between customized DSDT and DSDT local copy commit 73577d1df8e1f31f6b1a5eebcdbc334eb0330e47 upstream. This patch fixes the following issue: If DSDT is customized, no local DSDT copy is needed. References: https://bugzilla.kernel.org/show_bug.cgi?id=69711 Signed-off-by: Enrico Etxe Arte Signed-off-by: Lv Zheng [rjw: Subject] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 624bc5368795c20f2de37f5d1a0e6cf8a52f1fe8 Author: David Binderman Date: Fri Apr 4 12:36:55 2014 +0800 ACPICA: utstring: Check array index bound before use. commit 5d42b0fa25df7ef2f575107597c1aaebe2407d10 upstream. ACPICA BZ 1077. David Binderman. References: https://bugs.acpica.org/show_bug.cgi?id=1077 Signed-off-by: David Binderman Signed-off-by: Bob Moore Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit e330441067f61822851ea4f58963525a498a9bde Author: Bjørn Mork Date: Thu May 22 12:47:47 2014 +0200 ACPI: add dynamic_debug support commit 45fef5b88d1f2f47ecdefae6354372d440ca5c84 upstream. Commit 1a699476e258 ("ACPI / hotplug / PCI: Hotplug notifications from acpi_bus_notify()") added debug messages for a few common events. These debug messages are unconditionally enabled if CONFIG_DYNAMIC_DEBUG is defined, contrary to the documented meaning, making the ACPI system spew lots of unwanted noise on any kernel with dynamic debugging. The bug was introduced by commit fbfddae69657 ("ACPI: Add acpi_handle_() interfaces"), which added the CONFIG_DYNAMIC_DEBUG dependency without respecting its meaning. Fix by adding real support for dynamic_debug. Fixes: fbfddae69657 ("ACPI: Add acpi_handle_() interfaces") Signed-off-by: Bjørn Mork Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 079716fe1bb5dd904ecb75b23e8846b45bb116e2 Author: Sylwester Nawrocki Date: Tue Apr 15 14:34:29 2014 -0300 media: exynos4-is: Fix compilation for !CONFIG_COMMON_CLK commit f486e7c3cb9849b6a661931fa8c51a43d477046b upstream. CONFIG_COMMON_CLK is not enabled on S5PV210 platform, so include some clk API data structures conditionally to avoid compilation errors. These #ifdefs will be removed for next kernel release, when the S5PV210 platform moves to DT and the common clk API. Signed-off-by: Sylwester Nawrocki Acked-by: Kyungmin Park Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 30520611a4f41bf1276959ad77f1faabed5c09de Author: Sylwester Nawrocki Date: Thu May 8 14:35:15 2014 -0300 media: exynos4-is: Free FIMC-IS CPU memory only when allocated commit 404a90abc60f60df2757cb272660e003d326881f upstream. Ensure dma_free_coherent() is not called with incorrect arguments and only when the memory was actually allocated. This will prevent possible crashes on error paths of the top level media device driver, when fimc-is device gets unregistered and its driver detached. Signed-off-by: Sylwester Nawrocki Acked-by: Kyungmin Park Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 5a77f6628b73c6fb3d7d092a66f92f5a815dd57a Author: Ezequiel Garcia Date: Thu Apr 17 09:28:20 2014 -0300 media: stk1160: Avoid stack-allocated buffer for control URBs commit 85ac1a1772bb41da895bad83a81f6a62c8f293f6 upstream. Currently stk1160_read_reg() uses a stack-allocated char to get the read control value. This is wrong because usb_control_msg() requires a kmalloc-ed buffer. This commit fixes such issue by kmalloc'ating a 1-byte buffer to receive the read value. While here, let's remove the urb_buf array which was meant for a similar purpose, but never really used. Cc: Alan Stern Reported-by: Sander Eikelenboom Signed-off-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit e84b7ee8356e2df799c6329e0a4994d4a04bcece Author: Takashi Iwai Date: Mon May 5 11:20:05 2014 -0300 media: ivtv: Fix Oops when no firmware is loaded commit deb29e90221a6d4417aa67be971613c353180331 upstream. When ivtv PCM device is accessed at the state where no firmware is loaded, it oopses like: BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 IP: [] try_mailbox.isra.0+0x11/0x50 [ivtv] Call Trace: [] ivtv_api_call+0x160/0x6b0 [ivtv] [] ivtv_api+0x16/0x40 [ivtv] [] ivtv_vapi+0xac/0xc0 [ivtv] [] ivtv_start_v4l2_encode_stream+0x19d/0x630 [ivtv] [] snd_ivtv_pcm_capture_open+0x173/0x1c0 [ivtv_alsa] [] snd_pcm_open_substream+0x51/0x100 [snd_pcm] [] snd_pcm_open+0xb3/0x260 [snd_pcm] [] snd_pcm_capture_open+0x37/0x50 [snd_pcm] [] snd_open+0xa7/0x1e0 [snd] [] chrdev_open+0x88/0x1d0 [] do_dentry_open+0x1de/0x270 [] do_last+0x1c3/0xec0 [] path_openat+0xb6/0x670 [] do_filp_open+0x35/0x80 [] do_sys_open+0x129/0x210 [] system_call_fastpath+0x1a/0x1f This patch adds the check of firmware at PCM open callback like other open callbacks of this driver. Bugzilla: https://apibugzilla.novell.com/show_bug.cgi?id=875440 Signed-off-by: Takashi Iwai Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 79d3d9bcacb8217faae82d501f4b64a163ebd9bb Author: Johan Hovold Date: Mon May 26 19:23:33 2014 +0200 USB: serial: fix potential runtime pm imbalance at device remove commit c14829fad88dbeda57253590695b85ba51270621 upstream. Only call usb_autopm_put_interface() if the corresponding usb_autopm_get_interface() was successful. This prevents a potential runtime PM counter imbalance should usb_autopm_get_interface() fail. Note that the USB PM usage counter is reset when the interface is unbound, but that the runtime PM counter may be left unbalanced. Also add comment on why we don't need to worry about racing resume/suspend on autopm_get failures. Fixes: d5fd650cfc7f ("usb: serial: prevent suspend/resume from racing against probe/remove") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ba0359524c5ac4d9ba609cd4434f428851cba8cf Author: Aleksander Morgado Date: Thu May 29 13:33:27 2014 +0200 usb: qcserial: add additional Sierra Wireless QMI devices commit 0ce5fb58564fd85aa8fd2d24209900e2e845317b upstream. A set of new VID/PIDs retrieved from the out-of-tree GobiNet/GobiSerial Sierra Wireless drivers. Signed-off-by: Aleksander Morgado Link: http://marc.info/?l=linux-usb&m=140136310027293&w=2 Cc: # backport in link above Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit fe9d63e56689bfe3d25fea006a84b7013c308e94 Author: Aleksander Morgado Date: Wed May 28 21:13:51 2014 +0200 usb: qcserial: add Netgear AirCard 341U commit ff1fcd50bc2459744e6f948310bc18eb7d6e8c72 upstream. Signed-off-by: Aleksander Morgado Signed-off-by: Greg Kroah-Hartman commit f7c4c1060e81b80c52ebb9f6bae5d2b55aa34c96 Author: Johan Hovold Date: Mon May 26 19:22:54 2014 +0200 USB: sierra: fix remote wakeup commit 80cc0fcbdaeaf10d04ba27779a2d7ceb73d2717a upstream. Make sure that needs_remote_wake up is always set when there are open ports. Currently close() would unconditionally set needs_remote_wakeup to 0 even though there might still be open ports. This could lead to blocked input and possibly dropped data on devices that do not support remote wakeup (and which must therefore not be runtime suspended while open). Add an open_ports counter (protected by the susp_lock) and only clear needs_remote_wakeup when the last port is closed. Fixes: e6929a9020ac ("USB: support for autosuspend in sierra while online") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit b5079ac77983da7ad613a13fdf70c2d2a8ac3768 Author: Johan Hovold Date: Mon May 26 19:22:53 2014 +0200 USB: sierra: fix urb and memory leak on disconnect commit 014333f77c0b71123d6ef7d31a9724e0699c9548 upstream. The delayed-write queue was never emptied on disconnect, something which would lead to leaked urbs and transfer buffers if the device is disconnected before being runtime resumed due to a write. Fixes: e6929a9020ac ("USB: support for autosuspend in sierra while online") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 79068e639c42d00be314448f88aee9241ca11310 Author: Johan Hovold Date: Mon May 26 19:22:52 2014 +0200 USB: sierra: fix urb and memory leak in resume error path commit 7fdd26a01eb7b6cb6855ff8f69ef4a720720dfcb upstream. Neither the transfer buffer or the urb itself were released in the resume error path for delayed writes. Also on errors, the remainder of the queue was not even processed, which leads to further urb and buffer leaks. The same error path also failed to balance the outstanding-urb counter, something which results in degraded throughput or completely blocked writes. Fix this by releasing urb and buffer and balancing counters on errors, and by always processing the whole queue even when submission of one urb fails. Fixes: e6929a9020ac ("USB: support for autosuspend in sierra while online") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 9a9b33f0d846ab4494279afcf6a916b50a1f760f Author: Johan Hovold Date: Mon May 26 19:22:51 2014 +0200 USB: sierra: fix use after free at suspend/resume commit 8452727de70f6ad850cd6d0aaa18b5d9050aa63b upstream. Fix use after free or NULL-pointer dereference during suspend and resume. The port data may never have been allocated (port probe failed) or may already have been released by port_remove (e.g. driver is unloaded) when suspend and resume are called. Fixes: e6929a9020ac ("USB: support for autosuspend in sierra while online") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ed8f24f670646134021ff6e7393cae2ef44e968b Author: Johan Hovold Date: Mon May 26 19:22:50 2014 +0200 USB: sierra: fix AA deadlock in open error path commit 353fe198602e8b4d1c7bdcceb8e60955087201b1 upstream. Fix AA deadlock in open error path that would call close() and try to grab the already held disc_mutex. Fixes: b9a44bc19f48 ("sierra: driver urb handling improvements") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 8aa440e39e90463ef9792b1903eeafc27f6cdf18 Author: Johan Hovold Date: Mon May 26 19:23:18 2014 +0200 USB: usb_wwan: fix potential blocked I/O after resume commit fb7ad4f93d9f0f7d49beda32f5e7becb94b29a4d upstream. Keep trying to submit urbs rather than bail out on first read-urb submission error, which would also prevent I/O for any further ports from being resumed. Instead keep an error count, for all types of failed submissions, and let USB core know that something went wrong. Also make sure to always clear the suspended flag. Currently a failed read-urb submission would prevent cached writes as well as any subsequent writes from being submitted until next suspend-resume cycle, something which may not even necessarily happen. Note that USB core currently only logs an error if an interface resume failed. Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the option driver") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit b28425635436294f58b18e78e70f04c7b094c8c4 Author: Johan Hovold Date: Mon May 26 19:23:17 2014 +0200 USB: usb_wwan: fix potential NULL-deref at resume commit 9096f1fbba916c2e052651e9de82fcfb98d4bea7 upstream. The interrupt urb was submitted unconditionally at resume, something which could lead to a NULL-pointer dereference in the urb completion handler as resume may be called after the port and port data is gone. Fix this by making sure the interrupt urb is only submitted and active when the port is open. Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the option driver") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 21286f6f66d8ede5b3424de9a33a6dca537161a5 Author: Johan Hovold Date: Mon May 26 19:23:16 2014 +0200 USB: usb_wwan: fix urb leak at shutdown commit 79eed03e77d481b55d85d1cfe5a1636a0d3897fd upstream. The delayed-write queue was never emptied at shutdown (close), something which could lead to leaked urbs if the port is closed before being runtime resumed due to a write. When this happens the output buffer would not drain on close (closing_wait timeout), and after consecutive opens, writes could be corrupted with previously buffered data, transfered with reduced throughput or completely blocked. Note that unbusy_queued_urb() was simply moved out of CONFIG_PM. Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the option driver") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 47909efe223b738d7221aeb9ab6984ddfde0433f Author: Johan Hovold Date: Mon May 26 19:23:15 2014 +0200 USB: usb_wwan: fix write and suspend race commit 170fad9e22df0063eba0701adb966786d7a4ec5a upstream. Fix race between write() and suspend() which could lead to writes being dropped (or I/O while suspended) if the device is runtime suspended while a write request is being processed. Specifically, suspend() releases the susp_lock after determining the device is idle but before setting the suspended flag, thus leaving a window where a concurrent write() can submit an urb. Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the option driver") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 442d460ee58bbdc8319c77c7b41712a9d5cd7a4e Author: xiao jin Date: Mon May 26 19:23:14 2014 +0200 USB: usb_wwan: fix race between write and resume commit d9e93c08d8d985e5ef89436ebc9f4aad7e31559f upstream. We find a race between write and resume. usb_wwan_resume run play_delayed() and spin_unlock, but intfdata->suspended still is not set to zero. At this time usb_wwan_write is called and anchor the urb to delay list. Then resume keep running but the delayed urb have no chance to be commit until next resume. If the time of next resume is far away, tty will be blocked in tty_wait_until_sent during time. The race also can lead to writes being reordered. This patch put play_Delayed and intfdata->suspended together in the spinlock, it's to avoid the write race during resume. Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the option driver") Signed-off-by: xiao jin Signed-off-by: Zhang, Qi1 Reviewed-by: David Cohen Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 21b67b769ee22993a9f77a5e44fd96074fbd3b18 Author: xiao jin Date: Mon May 26 19:23:13 2014 +0200 USB: usb_wwan: fix urb leak in write error path commit db0904737947d509844e171c9863ecc5b4534005 upstream. When enable usb serial for modem data, sometimes the tty is blocked in tty_wait_until_sent because portdata->out_busy always is set and have no chance to be cleared. We find a bug in write error path. usb_wwan_write set portdata->out_busy firstly, then try autopm async with error. No out urb submit and no usb_wwan_outdat_callback to this write, portdata->out_busy can't be cleared. This patch clear portdata->out_busy if usb_wwan_write try autopm async with error. Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the option driver") Signed-off-by: xiao jin Signed-off-by: Zhang, Qi1 Reviewed-by: David Cohen Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit da818b18f1461ca620c2f43bc27003ce057b48c6 Author: Mikulas Patocka Date: Thu May 15 06:58:24 2014 -0400 matroxfb: perform a dummy read of M_STATUS commit 972754cfaee94d6e25acf94a497bc0a864d91b7e upstream. I had occasional screen corruption with the matrox framebuffer driver and I found out that the reason for the corruption is that the hardware blitter accesses the videoram while it is being written to. The matrox driver has a macro WaitTillIdle() that should wait until the blitter is idle, but it sometimes doesn't work. I added a dummy read mga_inl(M_STATUS) to WaitTillIdle() to fix the problem. The dummy read will flush the write buffer in the PCI chipset, and the next read of M_STATUS will return the hardware status. Since applying this patch, I had no screen corruption at all. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman commit feb62c88c9dc4f0ed3e04b1d24fd1812d78b9ddc Author: Maurizio Lombardi Date: Tue May 27 12:48:56 2014 -0400 ext4: fix wrong assert in ext4_mb_normalize_request() commit b5b60778558cafad17bbcbf63e0310bd3c68eb17 upstream. The variable "size" is expressed as number of blocks and not as number of clusters, this could trigger a kernel panic when using ext4 with the size of a cluster different from the size of a block. Signed-off-by: Maurizio Lombardi Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 59bc864486f20859e51b2878686fb86cfd57384c Author: Namjae Jeon Date: Tue May 27 12:48:55 2014 -0400 ext4: fix ZERO_RANGE test failure in data journalling commit e1ee60fd89670da61b0a4bda59f8ffb2b8abea63 upstream. xfstests generic/091 is failing when mounting ext4 with data=journal. I think that this regression is same problem that occurred prior to collapse range issue. So ZERO RANGE also need to call ext4_force_commit as collapse range. Signed-off-by: Namjae Jeon Signed-off-by: Ashish Sangwan Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit f70b5876eb95d2d96c0061f6f32524669f9818ec Author: Jan Kara Date: Tue May 27 12:48:55 2014 -0400 ext4: fix zeroing of page during writeback commit eeece469dedadf3918bad50ad80f4616a0064e90 upstream. Tail of a page straddling inode size must be zeroed when being written out due to POSIX requirement that modifications of mmaped page beyond inode size must not be written to the file. ext4_bio_write_page() did this only for blocks fully beyond inode size but didn't properly zero blocks partially beyond inode size. Fix this. The problem has been uncovered by mmap_11-4 test in openposix test suite (part of LTP). Reported-by: Xiaoguang Wang Fixes: 5a0dc7365c240 Fixes: bd2d0210cf22f CC: stable@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit ba6eb3c3ac56bf4097820f7f54ea562b5c5e018d Author: Namjae Jeon Date: Mon May 12 08:12:25 2014 -0400 ext4: fix data integrity sync in ordered mode commit 1c8349a17137b93f0a83f276c764a6df1b9a116e upstream. When we perform a data integrity sync we tag all the dirty pages with PAGECACHE_TAG_TOWRITE at start of ext4_da_writepages. Later we check for this tag in write_cache_pages_da and creates a struct mpage_da_data containing contiguously indexed pages tagged with this tag and sync these pages with a call to mpage_da_map_and_submit. This process is done in while loop until all the PAGECACHE_TAG_TOWRITE pages are synced. We also do journal start and stop in each iteration. journal_stop could initiate journal commit which would call ext4_writepage which in turn will call ext4_bio_write_page even for delayed OR unwritten buffers. When ext4_bio_write_page is called for such buffers, even though it does not sync them but it clears the PAGECACHE_TAG_TOWRITE of the corresponding page and hence these pages are also not synced by the currently running data integrity sync. We will end up with dirty pages although sync is completed. This could cause a potential data loss when the sync call is followed by a truncate_pagecache call, which is exactly the case in collapse_range. (It will cause generic/127 failure in xfstests) To avoid this issue, we can use set_page_writeback_keepwrite instead of set_page_writeback, which doesn't clear TOWRITE tag. Signed-off-by: Namjae Jeon Signed-off-by: Ashish Sangwan Signed-off-by: "Theodore Ts'o" Reviewed-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 7a3e2bd72aff79dc7d7b8a7ab7dfa3fbd7880fce Author: Krzysztof Kozlowski Date: Tue May 6 08:37:37 2014 +0200 regulator: s2mpa01: Fix accidental enable of buck4 ramp delay commit 51e2fc0a251ba64c68207e4c6f6ac33c891b2465 upstream. S2MPA01 supports enabling/disabling ramp delay only for buck[1234]. Other bucks have ramp delay enabled always. However the bit shift for enabling buck4 ramp delay in register is equal to 0. When ramp delay was set for the bucks unsupporting enable/disable (buck[56789] and buck10), the ramp delay for buck4 was also enabled. Fixes: f7b1a8dc1c1c ("regulator: s2mpa01: Don't check enable_shift before setting enable ramp rate") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 080b4ad880bb5138a5853d71a9c29f28a8980d11 Author: Krzysztof Kozlowski Date: Tue May 6 08:37:36 2014 +0200 regulator: s2mps11: Fix accidental enable of buck6 ramp delay commit b203e0dfe1a2b0ae5e2681e9285056e4ae8560af upstream. S2MPS11 supports enabling/disabling ramp delay only for buck[2346]. Other bucks have ramp delay enabled always. However the bit shift for enabling buck6 ramp delay in register is equal to 0. When ramp delay was set for the bucks unsupporting enable/disable (buck[15789] and buck10), the ramp delay for buck6 was also enabled. Fixes: b96244fad953 ("regulator: s2mps11: Don't check enable_shift before setting enable ramp rate") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Axel Lin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit dc45966c6bda1a78e17aa335b90ae987f6798017 Author: Krzysztof Kozlowski Date: Mon May 26 10:26:46 2014 +0200 regulator: s2mpa01: Use correct register for buck1 ramp delay commit 112da5cb43427b843e49b8710f53ecdbb3471d9f upstream. Fix the register for ramp delay of buck1 regulator. Buck1 and buck6 share the field (offset 4) in ramp delay register S2MPA01_REG_RAMP2. The driver used the same register and field for ramp delay of buck3 and buck1. This lead to updating of ramp delay of buck3 when setting buck1 and actually the ramp delay of buck1 was never set. Fixes: f18792714608 ("regulator: Add support for S2MPA01 regulator") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sachin Kamat Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6991b8dc948b1f40dd5d878ba6282ed289cfd1cc Author: Christian Borntraeger Date: Mon May 26 21:55:08 2014 +0200 s390/lowcore: reserve 96 bytes for IRB in lowcore commit 993072ee67aa179c48c85eb19869804e68887d86 upstream. The IRB might be 96 bytes if the extended-I/O-measurement facility is used. This feature is currently not used by Linux, but struct irb already has the emw defined. So let's make the irb in lowcore match the size of the internal data structure to be future proof. We also have to add a pad, to correctly align the paste. The bigger irb field also circumvents a bug in some QEMU versions that always write the emw field on test subchannel and therefore destroy the paste definitions of this CPU. Running under these QEMU version broke some timing functions in the VDSO and all users of these functions, e.g. some JREs. Signed-off-by: Christian Borntraeger Signed-off-by: Martin Schwidefsky Cc: Heiko Carstens Cc: Sebastian Ott Cc: Cornelia Huck Signed-off-by: Greg Kroah-Hartman commit 457bcc3313662f1671d8135b87981569f68bc076 Author: Martin Schwidefsky Date: Tue May 20 17:21:35 2014 +0200 s390/time: cast tv_nsec to u64 prior to shift in update_vsyscall commit b6f4296279ab3ada554d993d12844272fd86b36a upstream. Analog to git commit 28b92e09e25bdc0ae864b22eacf195a74f861389 first cast tk->wall_to_monotonic.tv_nsec to u64 before doing the shift with tk->shift to avoid loosing relevant bits on a 32-bit kernel. Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit ef88d262bc1e086af31f252350aee708bcdf2726 Author: Lai Jiangshan Date: Fri Jun 6 14:37:10 2014 -0700 idr: fix overflow bug during maximum ID calculation at maximum height commit 3afb69cb5572b3c8c898c00880803cf1a49852c4 upstream. idr_replace() open-codes the logic to calculate the maximum valid ID given the height of the idr tree; unfortunately, the open-coded logic doesn't account for the fact that the top layer may have unused slots and over-shifts the limit to zero when the tree is at its maximum height. The following test code shows it fails to replace the value for id=((1<<27)+42): static void test5(void) { int id; DEFINE_IDR(test_idr); #define TEST5_START ((1<<27)+42) /* use the highest layer */ printk(KERN_INFO "Start test5\n"); id = idr_alloc(&test_idr, (void *)1, TEST5_START, 0, GFP_KERNEL); BUG_ON(id != TEST5_START); TEST_BUG_ON(idr_replace(&test_idr, (void *)2, TEST5_START) != (void *)1); idr_destroy(&test_idr); printk(KERN_INFO "End of test5\n"); } Fix the bug by using idr_max() which correctly takes into account the maximum allowed shift. sub_alloc() shares the same problem and may incorrectly fail with -EAGAIN; however, this bug doesn't affect correct operation because idr_get_empty_slot(), which already uses idr_max(), retries with the increased @id in such cases. [tj@kernel.org: Updated patch description.] Signed-off-by: Lai Jiangshan Acked-by: Tejun Heo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ab275c83f5badf24df5fe3e377922d6fd6633ec9 Author: Victor Kamensky Date: Tue Jun 3 19:21:30 2014 +0100 arm64: ptrace: fix empty registers set in prstatus of aarch32 process core commit 2227901a0230d8fde81ba9c602d649839390f56b upstream. Currently core file of aarch32 process prstatus note has empty registers set. As result aarch32 core files create by V8 kernel are not very useful. It happens because compat_gpr_get and compat_gpr_set functions can copy registers values to/from either kbuf or ubuf. ELF core file collection function fill_thread_core_info calls compat_gpr_get with kbuf set and ubuf set to 0. But current compat_gpr_get and compat_gpr_set function handle copy to/from only ubuf case. Fix is to handle kbuf and ubuf as two separate cases in similar way as other functions like user_regset_copyout, user_regset_copyin do. Signed-off-by: Victor Kamensky Acked-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 993e3e16565178b94d38c20fd1c81eb020b2fe8f Author: Will Deacon Date: Mon Jun 2 11:47:23 2014 +0100 arm64: ptrace: change fs when passing kernel pointer to regset code commit c168870704bcde6bb63d05f7882b620dd3985a46 upstream. Our compat PTRACE_POKEUSR implementation simply passes the user data to regset_copy_from_user after some simple range checking. Unfortunately, the data in question has already been copied to the kernel stack by this point, so the subsequent access_ok check fails and the ptrace request returns -EFAULT. This causes problems tracing fork() with older versions of strace. This patch briefly changes the fs to KERNEL_DS, so that the access_ok check passes even with a kernel address. Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 3d672e43c3dc0549fee9af8b6b6142dfba425d62 Author: Matthew Dempsky Date: Fri Jun 6 14:36:42 2014 -0700 ptrace: fix fork event messages across pid namespaces commit 4e52365f279564cef0ddd41db5237f0471381093 upstream. When tracing a process in another pid namespace, it's important for fork event messages to contain the child's pid as seen from the tracer's pid namespace, not the parent's. Otherwise, the tracer won't be able to correlate the fork event with later SIGTRAP signals it receives from the child. We still risk a race condition if a ptracer from a different pid namespace attaches after we compute the pid_t value. However, sending a bogus fork event message in this unlikely scenario is still a vast improvement over the status quo where we always send bogus fork event messages to debuggers in a different pid namespace than the forking process. Signed-off-by: Matthew Dempsky Acked-by: Oleg Nesterov Cc: Kees Cook Cc: Julien Tinnes Cc: Roland McGrath Cc: Jan Kratochvil Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0077982f8d0fa1f0f32ef5909e28bca0784c34e7 Author: Johannes Weiner Date: Fri Jun 6 14:35:35 2014 -0700 mm: vmscan: clear kswapd's special reclaim powers before exiting commit 71abdc15adf8c702a1dd535f8e30df50758848d2 upstream. When kswapd exits, it can end up taking locks that were previously held by allocating tasks while they waited for reclaim. Lockdep currently warns about this: On Wed, May 28, 2014 at 06:06:34PM +0800, Gu Zheng wrote: > inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage. > kswapd2/1151 [HC0[0]:SC0[0]:HE1:SE1] takes: > (&sig->group_rwsem){+++++?}, at: exit_signals+0x24/0x130 > {RECLAIM_FS-ON-W} state was registered at: > mark_held_locks+0xb9/0x140 > lockdep_trace_alloc+0x7a/0xe0 > kmem_cache_alloc_trace+0x37/0x240 > flex_array_alloc+0x99/0x1a0 > cgroup_attach_task+0x63/0x430 > attach_task_by_pid+0x210/0x280 > cgroup_procs_write+0x16/0x20 > cgroup_file_write+0x120/0x2c0 > vfs_write+0xc0/0x1f0 > SyS_write+0x4c/0xa0 > tracesys+0xdd/0xe2 > irq event stamp: 49 > hardirqs last enabled at (49): _raw_spin_unlock_irqrestore+0x36/0x70 > hardirqs last disabled at (48): _raw_spin_lock_irqsave+0x2b/0xa0 > softirqs last enabled at (0): copy_process.part.24+0x627/0x15f0 > softirqs last disabled at (0): (null) > > other info that might help us debug this: > Possible unsafe locking scenario: > > CPU0 > ---- > lock(&sig->group_rwsem); > > lock(&sig->group_rwsem); > > *** DEADLOCK *** > > no locks held by kswapd2/1151. > > stack backtrace: > CPU: 30 PID: 1151 Comm: kswapd2 Not tainted 3.10.39+ #4 > Call Trace: > dump_stack+0x19/0x1b > print_usage_bug+0x1f7/0x208 > mark_lock+0x21d/0x2a0 > __lock_acquire+0x52a/0xb60 > lock_acquire+0xa2/0x140 > down_read+0x51/0xa0 > exit_signals+0x24/0x130 > do_exit+0xb5/0xa50 > kthread+0xdb/0x100 > ret_from_fork+0x7c/0xb0 This is because the kswapd thread is still marked as a reclaimer at the time of exit. But because it is exiting, nobody is actually waiting on it to make reclaim progress anymore, and it's nothing but a regular thread at this point. Be tidy and strip it of all its powers (PF_MEMALLOC, PF_SWAPWRITE, PF_KSWAPD, and the lockdep reclaim state) before returning from the thread function. Signed-off-by: Johannes Weiner Reported-by: Gu Zheng Cc: Yasuaki Ishimatsu Cc: Tang Chen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ed1c734130f3a7fcfd98fcc6f4e330f392ef4710 Author: Kees Cook Date: Thu Apr 17 13:22:09 2014 -0700 HID: core: fix validation of report id 0 commit 1b15d2e5b8077670b1e6a33250a0d9577efff4a5 upstream. Some drivers use the first HID report in the list instead of using an index. In these cases, validation uses ID 0, which was supposed to mean "first known report". This fixes the problem, which was causing at least the lgff family of devices to stop working since hid_validate_values was being called with ID 0, but the devices used single numbered IDs for their reports: 0x05, 0x01, /* Usage Page (Desktop), */ 0x09, 0x05, /* Usage (Gamepad), */ 0xA1, 0x01, /* Collection (Application), */ 0xA1, 0x02, /* Collection (Logical), */ 0x85, 0x01, /* Report ID (1), */ ... Reported-by: Simon Wood Signed-off-by: Kees Cook Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 693b69e663ce0a9f0b8af7e16498092d62f1031a Author: Hugh Dickins Date: Wed Jun 4 16:05:33 2014 -0700 mm: fix sleeping function warning from __put_anon_vma commit 7f39dda9d86fb4f4f17af0de170decf125726f8c upstream. Trinity reports BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:47 in_atomic(): 0, irqs_disabled(): 0, pid: 5787, name: trinity-c27 __might_sleep < down_write < __put_anon_vma < page_get_anon_vma < migrate_pages < compact_zone < compact_zone_order < try_to_compact_pages .. Right, since conversion to mutex then rwsem, we should not put_anon_vma() from inside an rcu_read_lock()ed section: fix the two places that did so. And add might_sleep() to anon_vma_free(), as suggested by Peter Zijlstra. Fixes: 88c22088bf23 ("mm: optimize page_lock_anon_vma() fast-path") Reported-by: Dave Jones Signed-off-by: Hugh Dickins Cc: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e9198a0b9b519fc5e61cef1f0c5a7e1b0798658e Author: Weijie Yang Date: Wed Jun 4 16:11:06 2014 -0700 zram: correct offset usage in zram_bio_discard commit 38515c73398a4c58059ecf1087e844561b58ee0f upstream. We want to skip the physical block(PAGE_SIZE) which is partially covered by the discard bio, so we check the remaining size and subtract it if there is a need to goto the next physical block. The current offset usage in zram_bio_discard is incorrect, it will cause its upper filesystem breakdown. Consider the following scenario: On some architecture or config, PAGE_SIZE is 64K for example, filesystem is set up on zram disk without PAGE_SIZE aligned, a discard bio leads to a offset = 4K and size=72K, normally, it should not really discard any physical block as it partially cover two physical blocks. However, with the current offset usage, it will discard the second physical block and free its memory, which will cause filesystem breakdown. This patch corrects the offset usage in zram_bio_discard. Signed-off-by: Weijie Yang Cc: Minchan Kim Cc: Nitin Gupta Acked-by: Joonsoo Kim Cc: Sergey Senozhatsky Cc: Bob Liu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 92797cf19e1ad0e1214838d6fdaf67fb3f46a624 Author: Naoya Horiguchi Date: Wed Jun 4 16:11:02 2014 -0700 mm/memory-failure.c: support use of a dedicated thread to handle SIGBUS(BUS_MCEERR_AO) commit 3ba08129e38437561df44c36b7ea9081185d5333 upstream. Currently memory error handler handles action optional errors in the deferred manner by default. And if a recovery aware application wants to handle it immediately, it can do it by setting PF_MCE_EARLY flag. However, such signal can be sent only to the main thread, so it's problematic if the application wants to have a dedicated thread to handler such signals. So this patch adds dedicated thread support to memory error handler. We have PF_MCE_EARLY flags for each thread separately, so with this patch AO signal is sent to the thread with PF_MCE_EARLY flag set, not the main thread. If you want to implement a dedicated thread, you call prctl() to set PF_MCE_EARLY on the thread. Memory error handler collects processes to be killed, so this patch lets it check PF_MCE_EARLY flag on each thread in the collecting routines. No behavioral change for all non-early kill cases. Tony said: : The old behavior was crazy - someone with a multithreaded process might : well expect that if they call prctl(PF_MCE_EARLY) in just one thread, then : that thread would see the SIGBUS with si_code = BUS_MCEERR_A0 - even if : that thread wasn't the main thread for the process. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Naoya Horiguchi Reviewed-by: Tony Luck Cc: Kamil Iskra Cc: Andi Kleen Cc: Borislav Petkov Cc: Chen Gong Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bb3008a2fd7c8c3ced706f46fbf7e724d40f9298 Author: Tony Luck Date: Wed Jun 4 16:11:01 2014 -0700 mm/memory-failure.c: don't let collect_procs() skip over processes for MF_ACTION_REQUIRED commit 74614de17db6fb472370c426d4f934d8d616edf2 upstream. When Linux sees an "action optional" machine check (where h/w has reported an error that is not in the current execution path) we generally do not want to signal a process, since most processes do not have a SIGBUS handler - we'd just prematurely terminate the process for a problem that they might never actually see. task_early_kill() decides whether to consider a process - and it checks whether this specific process has been marked for early signals with "prctl", or if the system administrator has requested early signals for all processes using /proc/sys/vm/memory_failure_early_kill. But for MF_ACTION_REQUIRED case we must not defer. The error is in the execution path of the current thread so we must send the SIGBUS immediatley. Fix by passing a flag argument through collect_procs*() to task_early_kill() so it knows whether we can defer or must take action. Signed-off-by: Tony Luck Signed-off-by: Naoya Horiguchi Cc: Andi Kleen Cc: Borislav Petkov Cc: Chen Gong Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 44dc0863c436aa9c9c3c688cf7cbdcd20d768090 Author: Tony Luck Date: Wed Jun 4 16:10:59 2014 -0700 mm/memory-failure.c-failure: send right signal code to correct thread commit a70ffcac741d31a406c1d2b832ae43d658e7e1cf upstream. When a thread in a multi-threaded application hits a machine check because of an uncorrectable error in memory - we want to send the SIGBUS with si.si_code = BUS_MCEERR_AR to that thread. Currently we fail to do that if the active thread is not the primary thread in the process. collect_procs() just finds primary threads and this test: if ((flags & MF_ACTION_REQUIRED) && t == current) { will see that the thread we found isn't the current thread and so send a si.si_code = BUS_MCEERR_AO to the primary (and nothing to the active thread at this time). We can fix this by checking whether "current" shares the same mm with the process that collect_procs() said owned the page. If so, we send the SIGBUS to current (with code BUS_MCEERR_AR). Signed-off-by: Tony Luck Signed-off-by: Naoya Horiguchi Reported-by: Otto Bruggeman Cc: Andi Kleen Cc: Borislav Petkov Cc: Chen Gong Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cbc3234d2fd730d4c76749a39c23557f4f08248b Author: Mel Gorman Date: Wed Jun 4 16:10:16 2014 -0700 mm: page_alloc: use word-based accesses for get/set pageblock bitmaps commit e58469bafd0524e848c3733bc3918d854595e20f upstream. The test_bit operations in get/set pageblock flags are expensive. This patch reads the bitmap on a word basis and use shifts and masks to isolate the bits of interest. Similarly masks are used to set a local copy of the bitmap and then use cmpxchg to update the bitmap if there have been no other changes made in parallel. In a test running dd onto tmpfs the overhead of the pageblock-related functions went from 1.27% in profiles to 0.5%. In addition to the performance benefits, this patch closes races that are possible between: a) get_ and set_pageblock_migratetype(), where get_pageblock_migratetype() reads part of the bits before and other part of the bits after set_pageblock_migratetype() has updated them. b) set_pageblock_migratetype() and set_pageblock_skip(), where the non-atomic read-modify-update set bit operation in set_pageblock_skip() will cause lost updates to some bits changed in the set_pageblock_migratetype(). Joonsoo Kim first reported the case a) via code inspection. Vlastimil Babka's testing with a debug patch showed that either a) or b) occurs roughly once per mmtests' stress-highalloc benchmark (although not necessarily in the same pageblock). Furthermore during development of unrelated compaction patches, it was observed that frequent calls to {start,undo}_isolate_page_range() the race occurs several thousands of times and has resulted in NULL pointer dereferences in move_freepages() and free_one_page() in places where free_list[migratetype] is manipulated by e.g. list_move(). Further debugging confirmed that migratetype had invalid value of 6, causing out of bounds access to the free_list array. That confirmed that the race exist, although it may be extremely rare, and currently only fatal where page isolation is performed due to memory hot remove. Races on pageblocks being updated by set_pageblock_migratetype(), where both old and new migratetype are lower MIGRATE_RESERVE, currently cannot result in an invalid value being observed, although theoretically they may still lead to unexpected creation or destruction of MIGRATE_RESERVE pageblocks. Furthermore, things could get suddenly worse when memory isolation is used more, or when new migratetypes are added. After this patch, the race has no longer been observed in testing. Signed-off-by: Mel Gorman Acked-by: Vlastimil Babka Reported-by: Joonsoo Kim Reported-and-tested-by: Vlastimil Babka Cc: Johannes Weiner Cc: Jan Kara Cc: Michal Hocko Cc: Hugh Dickins Cc: Dave Hansen Cc: Theodore Ts'o Cc: "Paul E. McKenney" Cc: Oleg Nesterov Cc: Rik van Riel Cc: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fc226822ce1612575a7b69b172f89e3cd9fff359 Author: Michal Hocko Date: Wed Jun 4 16:07:36 2014 -0700 memcg: do not hang on OOM when killed by userspace OOM access to memory reserves commit d8dc595ce3909fbc131bdf5ab8c9808fe624b18d upstream. Eric has reported that he can see task(s) stuck in memcg OOM handler regularly. The only way out is to echo 0 > $GROUP/memory.oom_control His usecase is: - Setup a hierarchy with memory and the freezer (disable kernel oom and have a process watch for oom). - In that memory cgroup add a process with one thread per cpu. - In one thread slowly allocate once per second I think it is 16M of ram and mlock and dirty it (just to force the pages into ram and stay there). - When oom is achieved loop: * attempt to freeze all of the tasks. * if frozen send every task SIGKILL, unfreeze, remove the directory in cgroupfs. Eric has then pinpointed the issue to be memcg specific. All tasks are sitting on the memcg_oom_waitq when memcg oom is disabled. Those that have received fatal signal will bypass the charge and should continue on their way out. The tricky part is that the exit path might trigger a page fault (e.g. exit_robust_list), thus the memcg charge, while its memcg is still under OOM because nobody has released any charges yet. Unlike with the in-kernel OOM handler the exiting task doesn't get TIF_MEMDIE set so it doesn't shortcut further charges of the killed task and falls to the memcg OOM again without any way out of it as there are no fatal signals pending anymore. This patch fixes the issue by checking PF_EXITING early in mem_cgroup_try_charge and bypass the charge same as if it had fatal signal pending or TIF_MEMDIE set. Normally exiting tasks (aka not killed) will bypass the charge now but this should be OK as the task is leaving and will release memory and increasing the memory pressure just to release it in a moment seems dubious wasting of cycles. Besides that charges after exit_signals should be rare. I am bringing this patch again (rebased on the current mmotm tree). I hope we can move forward finally. If there is still an opposition then I would really appreciate a concurrent approach so that we can discuss alternatives. http://comments.gmane.org/gmane.linux.kernel.stable/77650 is a reference to the followup discussion when the patch has been dropped from the mmotm last time. Reported-by: Eric W. Biederman Signed-off-by: Michal Hocko Acked-by: David Rientjes Acked-by: Johannes Weiner Cc: KAMEZAWA Hiroyuki Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f339db5214ffae24cfc66df81266ffe1fab553e7 Author: Mel Gorman Date: Wed Jun 4 16:07:35 2014 -0700 mm: vmscan: do not throttle based on pfmemalloc reserves if node has no ZONE_NORMAL commit 675becce15f320337499bc1a9356260409a5ba29 upstream. throttle_direct_reclaim() is meant to trigger during swap-over-network during which the min watermark is treated as a pfmemalloc reserve. It throttes on the first node in the zonelist but this is flawed. The user-visible impact is that a process running on CPU whose local memory node has no ZONE_NORMAL will stall for prolonged periods of time, possibly indefintely. This is due to throttle_direct_reclaim thinking the pfmemalloc reserves are depleted when in fact they don't exist on that node. On a NUMA machine running a 32-bit kernel (I know) allocation requests from CPUs on node 1 would detect no pfmemalloc reserves and the process gets throttled. This patch adjusts throttling of direct reclaim to throttle based on the first node in the zonelist that has a usable ZONE_NORMAL or lower zone. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bd313c8332ddeecb4a67562b4c252dde5dd81272 Author: Tetsuo Handa Date: Wed Jun 4 16:05:36 2014 -0700 kthread: fix return value of kthread_create() upon SIGKILL. commit 8fe6929cfd43c44834858a53e129ffdc7c166298 upstream. Commit 786235eeba0e ("kthread: make kthread_create() killable") meant for allowing kthread_create() to abort as soon as killed by the OOM-killer. But returning -ENOMEM is wrong if killed by SIGKILL from userspace. Change kthread_create() to return -EINTR upon SIGKILL. Signed-off-by: Tetsuo Handa Cc: Oleg Nesterov Acked-by: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c3dc58b993c5bd5ef1b60b116d2716e3f8e90207 Author: Naoya Horiguchi Date: Wed Jun 4 16:05:35 2014 -0700 hugetlb: restrict hugepage_migration_support() to x86_64 commit c177c81e09e517bbf75b67762cdab1b83aba6976 upstream. Currently hugepage migration is available for all archs which support pmd-level hugepage, but testing is done only for x86_64 and there're bugs for other archs. So to avoid breaking such archs, this patch limits the availability strictly to x86_64 until developers of other archs get interested in enabling this feature. Simply disabling hugepage migration on non-x86_64 archs is not enough to fix the reported problem where sys_move_pages() hits the BUG_ON() in follow_page(FOLL_GET), so let's fix this by checking if hugepage migration is supported in vma_migratable(). Signed-off-by: Naoya Horiguchi Reported-by: Michael Ellerman Tested-by: Michael Ellerman Acked-by: Hugh Dickins Cc: Benjamin Herrenschmidt Cc: Tony Luck Cc: Russell King Cc: Martin Schwidefsky Cc: James Hogan Cc: Ralf Baechle Cc: David Miller Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 99a9ff3961e3b4f33e391e09772a456330e7e109 Author: Konstantin Khlebnikov Date: Wed Jun 4 16:05:30 2014 -0700 tools/vm/page-types.c: catch sigbus if raced with truncate commit 1d46598b7903cd5ec83c49adbd741f43bb0ffcdc upstream. Recently added page-cache dumping is known to be a little bit racy. But after race with truncate it just dies due to unhandled SIGBUS when it tries to poke pages beyond the new end of file. This patch adds handler for SIGBUS which skips the rest of the file. Signed-off-by: Konstantin Khlebnikov Cc: Naoya Horiguchi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5ff2117cf81c53f2b1e3e47a38451c792da4b330 Author: Johan Hovold Date: Mon May 26 19:23:10 2014 +0200 USB: option: fix runtime PM handling commit acf47d4f9c39b1cba467aa9442fc2efe0b1da741 upstream. Fix potential I/O while runtime suspended due to missing PM operations in send_setup. Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the option driver") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit a5be017ea752981645c63e266daa0a7cb9e7ccb1 Author: Alan Stern Date: Tue Jun 3 11:00:27 2014 -0400 USB: EHCI: avoid BIOS handover on the HASEE E200 commit b0a50e92bda3c4aeb8017d4e6c6e92146ebd5c9b upstream. Leandro Liptak reports that his HASEE E200 computer hangs when we ask the BIOS to hand over control of the EHCI host controller. This definitely sounds like a bug in the BIOS, but at the moment there is no way to fix it. This patch works around the problem by avoiding the handoff whenever the motherboard and BIOS version match those of Leandro's computer. Signed-off-by: Alan Stern Reported-by: Leandro Liptak Tested-by: Leandro Liptak Signed-off-by: Greg Kroah-Hartman commit 180cdfa5f8ffd26845537f085fb467e80db08a2e Author: Paul Bolle Date: Fri May 16 12:00:57 2014 +0200 ARM: OMAP: replace checks for CONFIG_USB_GADGET_OMAP commit 77c2f02edbeda9409a7cf3fd66233015820c213a upstream. Commit 193ab2a60700 ("usb: gadget: allow multiple gadgets to be built") apparently required that checks for CONFIG_USB_GADGET_OMAP would be replaced with checks for CONFIG_USB_OMAP. Do so now for the remaining checks for CONFIG_USB_GADGET_OMAP, even though these checks have basically been broken since v3.1. And, since we're touching this code, use the IS_ENABLED() macro, so things will now (hopefully) also work if USB_OMAP is modular. Fixes: 193ab2a60700 ("usb: gadget: allow multiple gadgets to be built") Signed-off-by: Paul Bolle Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 96da12bf4f34917a535cfdc1c435470aab5001c9 Author: Felipe Balbi Date: Wed Apr 16 10:30:33 2014 -0500 usb: dwc3: gadget: clear stall when disabling endpoint commit 687ef9817df7ed960d14575b9033dde3d04631fe upstream. so it seems like DWC3 IP doesn't clear stalls automatically when we disable an endpoint, because of that, we _must_ make sure stalls are cleared before clearing the proper bit in DALEPENA register. Reported-by: Johannes Stezenbach Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 702d5b2b469b648f60c837fd439b6f8c86fc0c22 Author: Paul Bolle Date: Mon May 26 23:37:09 2014 +0200 usb: gadget: rename CONFIG_USB_GADGET_PXA25X commit d30f2065d6da377cc76771aca5a9850cfca8723b upstream. Commit 193ab2a60700 ("usb: gadget: allow multiple gadgets to be built") basically renamed the Kconfig symbol USB_GADGET_PXA25X to USB_PXA25X. It did not rename the related macros in use at that time. Commit c0a39151a405 ("ARM: pxa: fix inconsistent CONFIG_USB_PXA27X") did so for all but one macro. Rename that last macro too now. Fixes: 193ab2a60700 ("usb: gadget: allow multiple gadgets to be built") Signed-off-by: Paul Bolle Signed-off-by: Greg Kroah-Hartman commit c94bdf18b58b9c3aba9f1edcf8ed613bf452d971 Author: Alan Stern Date: Tue Jun 3 11:11:34 2014 -0400 USB: usbtest: add a timeout for scatter-gather tests commit 32b36eeae6a859670d2939a7d6136cb5e9ed64f8 upstream. In usbtest, tests 5 - 8 use the scatter-gather library in usbcore without any sort of timeout. If there's a problem in the gadget or host controller being tested, the test can hang. This patch adds a 10-second timeout to the tests, so that they will fail gracefully with an ETIMEDOUT error instead of hanging. Signed-off-by: Alan Stern Reported-by: Huang Rui Tested-by: Huang Rui Signed-off-by: Greg Kroah-Hartman commit c1bbe8ec4b9030036fbde02f188e2e77f80592fb Author: Huang Rui Date: Mon May 26 10:55:36 2014 +0800 usb: usbtest: fix unlink write error with pattern 1 commit e4d58f5dcb7d7be45df8def31881ebfae99c75da upstream. TEST 12 and TEST 24 unlinks the URB write request for N times. When host and gadget both initialize pattern 1 (mod 63) data series to transfer, the gadget side will complain the wrong data which is not expected. Because in host side, usbtest doesn't fill the data buffer as mod 63 and this patch fixed it. [20285.488974] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Not Ready [20285.489181] dwc3 dwc3.0.auto: ep1out-bulk: reason Transfer Not Active [20285.489423] dwc3 dwc3.0.auto: ep1out-bulk: req ffff8800aa6cb480 dma aeb50800 length 512 last [20285.489727] dwc3 dwc3.0.auto: ep1out-bulk: cmd 'Start Transfer' params 00000000 a9eaf000 00000000 [20285.490055] dwc3 dwc3.0.auto: Command Complete --> 0 [20285.490281] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Not Ready [20285.490492] dwc3 dwc3.0.auto: ep1out-bulk: reason Transfer Active [20285.490713] dwc3 dwc3.0.auto: ep1out-bulk: endpoint busy [20285.490909] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Complete [20285.491117] dwc3 dwc3.0.auto: request ffff8800aa6cb480 from ep1out-bulk completed 512/512 ===> 0 [20285.491431] zero gadget: bad OUT byte, buf[1] = 0 [20285.491605] dwc3 dwc3.0.auto: ep1out-bulk: cmd 'Set Stall' params 00000000 00000000 00000000 [20285.491915] dwc3 dwc3.0.auto: Command Complete --> 0 [20285.492099] dwc3 dwc3.0.auto: queing request ffff8800aa6cb480 to ep1out-bulk length 512 [20285.492387] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Not Ready [20285.492595] dwc3 dwc3.0.auto: ep1out-bulk: reason Transfer Not Active [20285.492830] dwc3 dwc3.0.auto: ep1out-bulk: req ffff8800aa6cb480 dma aeb51000 length 512 last [20285.493135] dwc3 dwc3.0.auto: ep1out-bulk: cmd 'Start Transfer' params 00000000 a9eaf000 00000000 [20285.493465] dwc3 dwc3.0.auto: Command Complete --> 0 Signed-off-by: Huang Rui Signed-off-by: Greg Kroah-Hartman commit fafb27179c287f740920e8dee3c4fc695821e590 Author: Dan Carpenter Date: Fri May 9 14:59:16 2014 +0300 applicom: dereferencing NULL on error path commit 8bab797c6e5724a43b7666ad70860712365cdb71 upstream. This is a static checker fix. The "dev" variable is always NULL after the while statement so we would be dereferencing a NULL pointer here. Fixes: 819a3eba4233 ('[PATCH] applicom: fix error handling') Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman commit 1c2ee2e5fe50c64dc83d7130fb12d85d5092f3b6 Author: Stephen Boyd Date: Fri May 23 17:16:53 2014 -0700 staging/mt29f_spinand: Terminate of match table commit ffd07de65ef5315053ea16356cd533b7f47c17e9 upstream. Failure to terminate this match table can lead to boot failures depending on where the compiler places the match table. Cc: Kamlakant Patel Cc: Mona Anonuevo Cc: linux-mtd@lists.infradead.org Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit f10da0ea0a699fc10947a6730588704b8cffd581 Author: Dan Carpenter Date: Mon Apr 7 09:31:21 2014 +0300 Staging: rtl8188eu: overflow in update_sta_support_rate() commit 9dbd79aeb9842144d9a114a979a12c0949ee11eb upstream. The ->SupportedRates[] array has NDIS_802_11_LENGTH_RATES_EX (16) elements. Since "ie_len" comes from then network and can go up to 255 then it means we should add a range check to prevent memory corruption. Fixes: d6846af679e0 ('staging: r8188eu: Add files for new driver - part 7') Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman commit 4c69bd70a472541caeb173088d2b8a8d14352e21 Author: Paul Bolle Date: Mon May 26 21:47:11 2014 +0200 staging: tidspbridge: check for CONFIG_SND_OMAP_SOC_MCBSP commit d3921a03a89acb1b9ca599590c0131c89f8737d8 upstream. Commit d0f47ff17f29 ("ASoC: OMAP: Build config cleanup for McBSP") removed the Kconfig symbol OMAP_MCBSP. It left two checks for CONFIG_OMAP_MCBSP untouched. Convert these to checks for CONFIG_SND_OMAP_SOC_MCBSP. That must be correct, since that re-enables calls to functions that are all found in sound/soc/omap/mcbsp.c. And that file is built only if CONFIG_SND_OMAP_SOC_MCBSP is defined. Fixes: d0f47ff17f29 ("ASoC: OMAP: Build config cleanup for McBSP") Signed-off-by: Paul Bolle Signed-off-by: Greg Kroah-Hartman commit 451049d57a37f8a676d885a7896494a274687f4a Author: Antoine Ténart Date: Mon May 12 14:56:28 2014 +0200 phy: exynos-mipi-video: fix check on array index commit 98c3b32229f2685c13436b652b8959c99dfc5a31 upstream. The phys array is of size EXYNOS_MIPI_PHYS_NUM. Trying to access the index EXYNOS_MIPI_PHYS_NUM should return an error. Fixes: 069d2e26e9d6 "phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs" Signed-off-by: Antoine Ténart Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Greg Kroah-Hartman commit 13611b46b1658d64b256f18f2a735bfb0d087b9f Author: Stephen Chivers Date: Wed May 14 08:04:39 2014 +1000 printk/of_serial: fix serial console cessation part way through boot. commit 7fa21dd8bd191564a195291161d6b43db5d9c350 upstream. Commit 5f5c9ae56c38942623f69c3e6dc6ec78e4da2076 "serial_core: Unregister console in uart_remove_one_port()" fixed a crash where a serial port was removed but not deregistered as a console. There is a side effect of that commit for platforms having serial consoles and of_serial configured (CONFIG_SERIAL_OF_PLATFORM). The serial console is disabled midway through the boot process. This cessation of the serial console affects PowerPC computers such as the MVME5100 and SAM440EP. The sequence is: bootconsole [udbg0] enabled .... serial8250/16550 driver initialises and registers its UARTS, one of these is the serial console. console [ttyS0] enabled .... of_serial probes "platform" devices, registering them as it goes. One of these is the serial console. console [ttyS0] disabled. The disabling of the serial console is due to: a. unregister_console in printk not clearing the CONS_ENABLED bit in the console flags, even though it has announced that the console is disabled; and b. of_platform_serial_probe in of_serial not setting the port type before it registers with serial8250_register_8250_port. This patch ensures that the serial console is re-enabled when of_serial registers a serial port that corresponds to the designated console. === The above failure was identified in Linux-3.15-rc2. Tested using MVME5100 and SAM440EP PowerPC computers with kernels built from Linux-3.15-rc5 and tty-next. The continued operation of the serial console is vital for computers such as the MVME5100 as that Single Board Computer does not have any grapical/display hardware. Signed-off-by: Stephen Chivers Tested-by: Stephen Chivers Acked-by: Geert Uytterhoeven [unregister_console] Signed-off-by: Greg Kroah-Hartman commit 063579d4c3ed721f5c3f066fcc12b5f176815b4b Author: Alexey Khoroshilov Date: Wed May 7 01:26:04 2014 +0400 w1: do not unlock unheld list_mutex in __w1_remove_master_device() commit a0f104644ec27ce5bbb36e950eb426dba9a3ad44 upstream. w1_process_callbacks() expects to be called with dev->list_mutex held, but it is the fact only in w1_process(). __w1_remove_master_device() calls w1_process_callbacks() after it releases list_mutex. The patch fixes __w1_remove_master_device() to acquire list_mutex for w1_process_callbacks(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Acked-by: David Fries Acked-by: Evgeniy Polyakov Signed-off-by: Greg Kroah-Hartman commit eb5adaa8b70a63e549a02c45570cd255ee0025aa Author: Krzysztof Kozlowski Date: Fri Apr 18 16:47:30 2014 +0200 extcon: max14577: Properly handle regmap_irq_get_virq error commit 369afd4ba22f5b8de0c9229b6e62b3f9e2207034 upstream. The regmap_irq_get_virq may return 0 or -EINVAL on error. Fail the probe in both situations. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Chanwoo Choi Signed-off-by: Greg Kroah-Hartman commit cc5dbe7fcb0db79f405cc780c42f70ce003b5222 Author: Krzysztof Kozlowski Date: Wed Apr 9 11:56:09 2014 +0200 extcon: max14577: Fix probe failure on successful work queue commit 12adef5b49e98eb181b4163c36e2998169e1379b upstream. In probe the driver queued delayed work for cable detection and returned the result of queue_delayed_work() call. However the return value of queue_delayed_work() does not indicate an error and in normal condition it returns true which means successful work queue. This effectively resulted in probe failure: [ 2.088204] max14577-muic: probe of max77836-muic failed with error 1 Signed-off-by: Krzysztof Kozlowski Fixes: 962e56bfcf0b ("extcon: max14577: Add extcon-max14577 driver...") Signed-off-by: Chanwoo Choi Signed-off-by: Greg Kroah-Hartman commit cced34726fcd53b65b4d5483dcf225414b9f4be6 Author: Krzysztof Kozlowski Date: Wed Apr 9 15:20:12 2014 +0200 extcon: max77693: Fix two NULL pointer exceptions on missing pdata commit d5653f2b7304f05eeb45d84f123cf02f840b8537 upstream. Fix NULL pointer exceptions when platform data is not supplied. Trace of one exception: Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = c0004000 [00000008] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.14.0-12045-gead5dd4687a6-dirty #1628 task: eea80000 ti: eea88000 task.ti: eea88000 PC is at max77693_muic_probe+0x27c/0x528 LR is at regmap_write+0x50/0x60 pc : [] lr : [] psr: 20000113 sp : eea89e38 ip : 00000000 fp : c098a834 r10: ee1a5a10 r9 : 00000005 r8 : c098a83c r7 : 0000000a r6 : c098a774 r5 : 00000005 r4 : eeb006d0 r3 : c0697bd8 r2 : 00000000 r1 : 00000001 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 4000404a DAC: 00000015 Process swapper/0 (pid: 1, stack limit = 0xeea88240) Stack: (0xeea89e38 to 0xeea8a000) 9e20: c08499fc eeb006d0 9e40: 00000000 00000000 c0915f98 00000001 00000000 ee1a5a10 c098a730 c09a88b8 9e60: 00000000 c098a730 c0915f98 00000000 00000000 c02d6aa0 c02d6a88 ee1a5a10 9e80: c0a712c8 c02d54e4 00001204 c0628b00 ee1a5a10 c098a730 ee1a5a44 00000000 9ea0: eea88000 c02d57b4 00000000 c098a730 c02d5728 c02d3a24 ee813e5c eeb9d534 9ec0: c098a730 ee22f700 c097c720 c02d4b14 c08174ec c098a730 00000006 c098a730 9ee0: 00000006 c092fd30 c09b8500 c02d5df8 00000000 c093cbb8 00000006 c0008928 9f00: 000000c3 ef7fc785 00000000 ef7fc794 00000000 c08af968 00000072 eea89f30 9f20: ef7fc85e c065f198 000000c3 c003e87c 00000003 00000000 c092fd3c 00000000 9f40: c08af618 c0826d58 00000006 00000006 c0956f58 c093cbb8 00000006 c092fd30 9f60: c09b8500 000000c3 c092fd3c c08e8510 00000000 c08e8bb0 00000006 00000006 9f80: c08e8510 c0c0c0c0 00000000 c0628fac 00000000 00000000 00000000 00000000 9fa0: 00000000 c0628fb4 00000000 c000f038 00000000 00000000 00000000 00000000 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 c0c0c0c0 c0c0c0c0 [] (max77693_muic_probe) from [] (platform_drv_probe+0x18/0x48) [] (platform_drv_probe) from [] (driver_probe_device+0x140/0x384) [] (driver_probe_device) from [] (__driver_attach+0x8c/0x90) [] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88) [] (bus_for_each_dev) from [] (bus_add_driver+0xe8/0x204) [] (bus_add_driver) from [] (driver_register+0x78/0xf4) [] (driver_register) from [] (do_one_initcall+0xc4/0x174) [] (do_one_initcall) from [] (kernel_init_freeable+0xfc/0x1c8) [] (kernel_init_freeable) from [] (kernel_init+0x8/0xec) [] (kernel_init) from [] (ret_from_fork+0x14/0x3c) Code: caffffe7 e59d200c e3550001 b3a05001 (e5923008) ---[ end trace 85db969ce011bde7 ]--- Signed-off-by: Krzysztof Kozlowski Fixes: 190d7cfc8632 Signed-off-by: Chanwoo Choi Signed-off-by: Greg Kroah-Hartman commit 98841cadfdb8e4cecd25eedaaf31f42af982c758 Author: Krzysztof Kozlowski Date: Wed Apr 9 15:20:14 2014 +0200 extcon: max8997: Fix NULL pointer exception on missing pdata commit dfee4111febf3d9ef3a640b2cd6205c75f4e7e3d upstream. Fix NULL pointer exception when platform data is not supplied. The driver dereferenced pdata pointer where it could be NULL. Signed-off-by: Krzysztof Kozlowski Fixes: 810d601f07c Signed-off-by: Chanwoo Choi Signed-off-by: Greg Kroah-Hartman commit ed950366acc7694b514a43878b41a1392d89bd19 Author: Ming Lei Date: Fri May 30 10:49:29 2014 +0800 block: virtio_blk: don't hold spin lock during world switch commit e8edca6f7f92234202d6dd163c118ef495244d7c upstream. Firstly, it isn't necessary to hold lock of vblk->vq_lock when notifying hypervisor about queued I/O. Secondly, virtqueue_notify() will cause world switch and it may take long time on some hypervisors(such as, qemu-arm), so it isn't good to hold the lock and block other vCPUs. On arm64 quad core VM(qemu-kvm), the patch can increase I/O performance a lot with VIRTIO_RING_F_EVENT_IDX enabled: - without the patch: 14K IOPS - with the patch: 34K IOPS fio script: [global] direct=1 bsrange=4k-4k timeout=10 numjobs=4 ioengine=libaio iodepth=64 filename=/dev/vdc group_reporting=1 [f1] rw=randread Cc: Rusty Russell Cc: "Michael S. Tsirkin" Cc: virtualization@lists.linux-foundation.org Signed-off-by: Ming Lei Acked-by: Rusty Russell Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a5ac2ce6897f7e5366042f1d5ea7529113280472 Author: Russell King Date: Fri Apr 18 10:46:45 2014 +0100 imx-drm: fix hdmi hotplug detection initial state commit 98dbeadaf050335df8655d8d9be7a324b6cd896e upstream. The initial state at boot is assumed to be disconnected, and we hope to receive an interrupt to update the status. Let's be more explicit about the current state - reading the PHY status register tells us the current level of the hotplug signal, which we can report back in the _detect() method. Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman