commit a3308b5d8b56d8622316afc198334666f5211ff4 Author: Greg Kroah-Hartman Date: Thu Sep 26 17:22:44 2013 -0700 Linux 3.11.2 commit 459c331dc57b47a3983322caa37c605bf99faea3 Author: Miklos Szeredi Date: Tue Sep 3 14:28:38 2013 +0200 fuse: readdir: check for slash in names commit efeb9e60d48f7778fdcad4a0f3ad9ea9b19e5dfd upstream. Userspace can add names containing a slash character to the directory listing. Don't allow this as it could cause all sorts of trouble. Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 125fe73b6a1e9be5014b6199f479ccb3c8d1b479 Author: Maxim Patlasov Date: Fri Aug 30 17:06:04 2013 +0400 fuse: hotfix truncate_pagecache() issue commit 06a7c3c2781409af95000c60a5df743fd4e2f8b4 upstream. The way how fuse calls truncate_pagecache() from fuse_change_attributes() is completely wrong. Because, w/o i_mutex held, we never sure whether 'oldsize' and 'attr->size' are valid by the time of execution of truncate_pagecache(inode, oldsize, attr->size). In fact, as soon as we released fc->lock in the middle of fuse_change_attributes(), we completely loose control of actions which may happen with given inode until we reach truncate_pagecache. The list of potentially dangerous actions includes mmap-ed reads and writes, ftruncate(2) and write(2) extending file size. The typical outcome of doing truncate_pagecache() with outdated arguments is data corruption from user point of view. This is (in some sense) acceptable in cases when the issue is triggered by a change of the file on the server (i.e. externally wrt fuse operation), but it is absolutely intolerable in scenarios when a single fuse client modifies a file without any external intervention. A real life case I discovered by fsx-linux looked like this: 1. Shrinking ftruncate(2) comes to fuse_do_setattr(). The latter sends FUSE_SETATTR to the server synchronously, but before getting fc->lock ... 2. fuse_dentry_revalidate() is asynchronously called. It sends FUSE_LOOKUP to the server synchronously, then calls fuse_change_attributes(). The latter updates i_size, releases fc->lock, but before comparing oldsize vs attr->size.. 3. fuse_do_setattr() from the first step proceeds by acquiring fc->lock and updating attributes and i_size, but now oldsize is equal to outarg.attr.size because i_size has just been updated (step 2). Hence, fuse_do_setattr() returns w/o calling truncate_pagecache(). 4. As soon as ftruncate(2) completes, the user extends file size by write(2) making a hole in the middle of file, then reads data from the hole either by read(2) or mmap-ed read. The user expects to get zero data from the hole, but gets stale data because truncate_pagecache() is not executed yet. The scenario above illustrates one side of the problem: not truncating the page cache even though we should. Another side corresponds to truncating page cache too late, when the state of inode changed significantly. Theoretically, the following is possible: 1. As in the previous scenario fuse_dentry_revalidate() discovered that i_size changed (due to our own fuse_do_setattr()) and is going to call truncate_pagecache() for some 'new_size' it believes valid right now. But by the time that particular truncate_pagecache() is called ... 2. fuse_do_setattr() returns (either having called truncate_pagecache() or not -- it doesn't matter). 3. The file is extended either by write(2) or ftruncate(2) or fallocate(2). 4. mmap-ed write makes a page in the extended region dirty. The result will be the lost of data user wrote on the fourth step. The patch is a hotfix resolving the issue in a simplistic way: let's skip dangerous i_size update and truncate_pagecache if an operation changing file size is in progress. This simplistic approach looks correct for the cases w/o external changes. And to handle them properly, more sophisticated and intrusive techniques (e.g. NFS-like one) would be required. I'd like to postpone it until the issue is well discussed on the mailing list(s). Changed in v2: - improved patch description to cover both sides of the issue. Signed-off-by: Maxim Patlasov Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit d3ab0e6f61a15081e844000f621bcb29220cb656 Author: Anand Avati Date: Tue Aug 20 02:21:07 2013 -0400 fuse: invalidate inode attributes on xattr modification commit d331a415aef98717393dda0be69b7947da08eba3 upstream. Calls like setxattr and removexattr result in updation of ctime. Therefore invalidate inode attributes to force a refresh. Signed-off-by: Anand Avati Reviewed-by: Brian Foster Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 5063ec3063f977a1262e846bea578987aff40b8d Author: Maxim Patlasov Date: Mon Aug 12 20:39:30 2013 +0400 fuse: postpone end_page_writeback() in fuse_writepage_locked() commit 4a4ac4eba1010ef9a804569058ab29e3450c0315 upstream. The patch fixes a race between ftruncate(2), mmap-ed write and write(2): 1) An user makes a page dirty via mmap-ed write. 2) The user performs shrinking truncate(2) intended to purge the page. 3) Before fuse_do_setattr calls truncate_pagecache, the page goes to writeback. fuse_writepage_locked fills FUSE_WRITE request and releases the original page by end_page_writeback. 4) fuse_do_setattr() completes and successfully returns. Since now, i_mutex is free. 5) Ordinary write(2) extends i_size back to cover the page. Note that fuse_send_write_pages do wait for fuse writeback, but for another page->index. 6) fuse_writepage_locked proceeds by queueing FUSE_WRITE request. fuse_send_writepage is supposed to crop inarg->size of the request, but it doesn't because i_size has already been extended back. Moving end_page_writeback to the end of fuse_writepage_locked fixes the race because now the fact that truncate_pagecache is successfully returned infers that fuse_writepage_locked has already called end_page_writeback. And this, in turn, infers that fuse_flush_writepages has already called fuse_send_writepage, and the latter used valid (shrunk) i_size. write(2) could not extend it because of i_mutex held by ftruncate(2). Signed-off-by: Maxim Patlasov Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 107bef8649a420ff3ea657afb254a094ea119494 Author: Mark Brown Date: Thu Aug 29 12:21:01 2013 +0100 clk: wm831x: Initialise wm831x pointer on init commit 08442ce993deeb15a070c14cc3f3459e87d111e0 upstream. Otherwise any attempt to interact with the hardware will crash. This is what happens when drivers get written blind. Signed-off-by: Mark Brown Signed-off-by: Mike Turquette Signed-off-by: Greg Kroah-Hartman commit e8247a339d36fc31b5dbf26cdea21d79f3cffa01 Author: Brian Norris Date: Thu Jul 18 01:17:02 2013 -0700 mtd: nand: fix NAND_BUSWIDTH_AUTO for x16 devices commit 68e8078072e802e77134664f11d2ffbfbd2f8fbe upstream. The code for NAND_BUSWIDTH_AUTO is broken. According to Alexander: "I have a problem with attach NAND UBI in 16 bit mode. NAND works fine if I specify NAND_BUSWIDTH_16 option, but not working with NAND_BUSWIDTH_AUTO option. In second case NAND chip is identifyed with ONFI." See his report for the rest of the details: http://lists.infradead.org/pipermail/linux-mtd/2013-July/047515.html Anyway, the problem is that nand_set_defaults() is called twice, we intend it to reset the chip functions to their x16 buswidth verions if the buswidth changed from x8 to x16; however, nand_set_defaults() does exactly nothing if called a second time. Fix this by hacking nand_set_defaults() to reset the buswidth-dependent functions if they were set to the x8 version the first time. Note that this does not do anything to reset from x16 to x8, but that's not the supported use case for NAND_BUSWIDTH_AUTO anyway. Signed-off-by: Brian Norris Reported-by: Alexander Shiyan Tested-by: Alexander Shiyan Cc: Matthieu Castet Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 763532e99224fec0693197a4b67386eced519d05 Author: Grant Likely Date: Wed Aug 28 21:24:17 2013 +0100 of: Fix missing memory initialization on FDT unflattening commit 0640332e073be9207f0784df43595c0c39716e42 upstream. Any calls to dt_alloc() need to be zeroed. This is a temporary fix, but the allocation function itself needs to zero memory before returning it. This is a follow up to patch 9e4012752, "of: fdt: fix memory initialization for expanded DT" which fixed one call site but missed another. Signed-off-by: Grant Likely Acked-by: Wladislav Wiebe Signed-off-by: Greg Kroah-Hartman commit 4963c59acdce47f2b15c49c58a8579f66cfa3ea7 Author: Sergei Shtylyov Date: Sat Aug 24 23:38:15 2013 -0400 mmc: tmio_mmc_dma: fix PIO fallback on SDHI commit f936f9b67b7f8c2eae01dd303a0e90bd777c4679 upstream. I'm testing SH-Mobile SDHI driver in DMA mode with a new DMA controller using 'bonnie++' and getting DMA error after which the tmio_mmc_dma.c code falls back to PIO but all commands time out after that. It turned out that the fallback code calls tmio_mmc_enable_dma() with RX/TX channels already freed and pointers to them cleared, so that the function bails out early instead of clearing the DMA bit in the CTL_DMA_ENABLE register. The regression was introduced by commit 162f43e31c5a376ec16336e5d0ac973373d54c89 (mmc: tmio: fix a deadlock). Moving tmio_mmc_enable_dma() calls to the top of the PIO fallback code in tmio_mmc_start_dma_{rx|tx}() helps. Signed-off-by: Sergei Shtylyov Acked-by: Guennadi Liakhovetski Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit 3ed52a384f887bb1dbd2f457bb35b8d7c1511523 Author: Josh Durgin Date: Mon Aug 26 17:55:38 2013 -0700 rbd: fix I/O error propagation for reads commit 17c1cc1d9293a568a00545469078e29555cc7f39 upstream. When a request returns an error, the driver needs to report the entire extent of the request as completed. Writes already did this, since they always set xferred = length, but reads were skipping that step if an error other than -ENOENT occurred. Instead, rbd would end up passing 0 xferred to blk_end_request(), which would always report needing more data. This resulted in an assert failing when more data was required by the block layer, but all the object requests were done: [ 1868.719077] rbd: obj_request read result -108 xferred 0 [ 1868.719077] [ 1868.719518] end_request: I/O error, dev rbd1, sector 0 [ 1868.719739] [ 1868.719739] Assertion failure in rbd_img_obj_callback() at line 1736: [ 1868.719739] [ 1868.719739] rbd_assert(more ^ (which == img_request->obj_request_count)); Without this assert, reads that hit errors would hang forever, since the block layer considered them incomplete. Fixes: http://tracker.ceph.com/issues/5647 Signed-off-by: Josh Durgin Reviewed-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit c36008fe66507bd7efa124b0d0c8254531a9ccde Author: majianpeng Date: Tue Jul 16 19:36:21 2013 +0800 ceph: Don't forget the 'up_read(&osdc->map_sem)' if met error. commit 494ddd11be3e2621096bb425eed2886f8e8446d4 upstream. Signed-off-by: Jianpeng Ma Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit bc2a02319530276f4c26b7c219111aae37b8dc1b Author: Sage Weil Date: Wed Aug 28 17:17:29 2013 -0700 libceph: use pg_num_mask instead of pgp_num_mask for pg.seed calc commit 9542cf0bf9b1a3adcc2ef271edbcbdba03abf345 upstream. Fix a typo that used the wrong bitmask for the pg.seed calculation. This is normally unnoticed because in most cases pg_num == pgp_num. It is, however, a bug that is easily corrected. Signed-off-by: Sage Weil Reviewed-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit d0bafacccd5ca14013c4935e8d44dc3c0d3672f7 Author: majianpeng Date: Tue Jul 16 15:45:48 2013 +0800 libceph: unregister request in __map_request failed and nofail == false commit 73d9f7eef3d98c3920e144797cc1894c6b005a1e upstream. For nofail == false request, if __map_request failed, the caller does cleanup work, like releasing the relative pages. It doesn't make any sense to retry this request. Signed-off-by: Jianpeng Ma Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit 1e354b6b4b0cb05d1666c0f8c3a13a164aec70c3 Author: Richard Weinberger Date: Sat Aug 17 18:46:00 2013 +0200 um: Implement probe_kernel_read() commit f75b1b1bedfb498cc43a992ce4d7ed8df3b1e770 upstream. UML needs it's own probe_kernel_read() to handle kernel mode faults correctly. The implementation uses mincore() on the host side to detect whether a page is owned by the UML kernel process. This fixes also a possible crash when sysrq-t is used. Starting with 3.10 sysrq-t calls probe_kernel_read() to read details from the kernel workers. As kernel worker are completely async pointers may turn NULL while reading them. Signed-off-by: Richard Weinberger Cc: Cc: Signed-off-by: Greg Kroah-Hartman commit 61bc17595c5a036931473347856ae5a44f9b01ab Author: Alex Deucher Date: Mon Aug 12 11:04:29 2013 -0400 drm/edid: add quirk for Medion MD30217PG commit 118bdbd86b39dbb843155054021d2c59058f1e05 upstream. This LCD monitor (1280x1024 native) has a completely bogus detailed timing (640x350@70hz). User reports that 1280x1024@60 has waves so prefer 1280x1024@75. Manufacturer: MED Model: 7b8 Serial#: 99188 Year: 2005 Week: 5 EDID Version: 1.3 Analog Display Input, Input Voltage Level: 0.700/0.700 V Sync: Separate Max Image Size [cm]: horiz.: 34 vert.: 27 Gamma: 2.50 DPMS capabilities: Off; RGB/Color Display First detailed timing is preferred mode redX: 0.645 redY: 0.348 greenX: 0.280 greenY: 0.605 blueX: 0.142 blueY: 0.071 whiteX: 0.313 whiteY: 0.329 Supported established timings: 720x400@70Hz 640x480@60Hz 640x480@72Hz 640x480@75Hz 800x600@56Hz 800x600@60Hz 800x600@72Hz 800x600@75Hz 1024x768@60Hz 1024x768@70Hz 1024x768@75Hz 1280x1024@75Hz Manufacturer's mask: 0 Supported standard timings: Supported detailed timing: clock: 25.2 MHz Image Size: 337 x 270 mm h_active: 640 h_sync: 688 h_sync_end 784 h_blank_end 800 h_border: 0 v_active: 350 v_sync: 350 v_sync_end 352 v_blanking: 449 v_border: 0 Monitor name: MD30217PG Ranges: V min: 56 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 145 MHz Serial No: 501099188 EDID (in hex): 00ffffffffffff0034a4b80774830100 050f010368221b962a0c55a559479b24 125054afcf00310a0101010101018180 000000000000d60980a0205e63103060 0200510e1100001e000000fc004d4433 3032313750470a202020000000fd0038 4c1e530e000a202020202020000000ff 003530313039393138380a2020200078 Signed-off-by: Alex Deucher Reported-by: friedrich@mailstation.de Signed-off-by: Greg Kroah-Hartman commit dd311a3ca3b1d6a829644aeab7d37edb6ccda95e Author: Borislav Petkov Date: Tue Jul 23 20:01:23 2013 +0200 amd64_edac: Fix single-channel setups commit f0a56c480196a98479760862468cc95879df3de0 upstream. It can happen that configurations are running in a single-channel mode even with a dual-channel memory controller, by, say, putting the DIMMs only on the one channel and leaving the other empty. This causes a problem in init_csrows which implicitly assumes that when the second channel is enabled, i.e. channel 1, the struct dimm hierarchy will be present. Which is not. So always allocate two channels unconditionally. This provides for the nice side effect that the data structures are initialized so some day, when memory hotplug is supported, it should just work out of the box when all of a sudden a second channel appears. Reported-and-tested-by: Roger Leigh Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit 77ad400fd46a05871d065cba6904233fdf5f57f3 Author: Jan Kara Date: Thu Jul 25 11:49:11 2013 +0200 isofs: Refuse RW mount of the filesystem instead of making it RO commit 17b7f7cf58926844e1dd40f5eb5348d481deca6a upstream. Refuse RW mount of isofs filesystem. So far we just silently changed it to RO mount but when the media is writeable, block layer won't notice this change and thus will think device is used RW and will block eject button of the drive. That is unexpected by users because for non-writeable media eject button works just fine. Userspace mount(8) command handles this just fine and retries mounting with MS_RDONLY set so userspace shouldn't see any regression. Plus any tool mounting isofs is likely confronted with the case of read-only media where block layer already refuses to mount the filesystem without MS_RDONLY set so our behavior shouldn't be anything new for it. Reported-by: Hui Wang Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 43be3c13b8d9cd9c3b9820baff6b6e108d00aeb5 Author: Eric W. Biederman Date: Mon Mar 25 19:57:10 2013 -0700 proc: Restrict mounting the proc filesystem commit aee1c13dd0f6c2fc56e0e492b349ee8ac655880f upstream. Don't allow mounting the proc filesystem unless the caller has CAP_SYS_ADMIN rights over the pid namespace. The principle here is if you create or have capabilities over it you can mount it, otherwise you get to live with what other people have mounted. Andy pointed out that this is needed to prevent users in a user namespace from remounting proc and specifying different hidepid and gid options on already existing proc mounts. Reported-by: Andy Lutomirski Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit edf125ced1bf525546c22ad3fd7cf8a6d6cd3339 Author: Libin Date: Wed Sep 11 14:20:38 2013 -0700 mm/huge_memory.c: fix potential NULL pointer dereference commit a8f531ebc33052642b4bd7b812eedf397108ce64 upstream. In collapse_huge_page() there is a race window between releasing the mmap_sem read lock and taking the mmap_sem write lock, so find_vma() may return NULL. So check the return value to avoid NULL pointer dereference. collapse_huge_page khugepaged_alloc_page up_read(&mm->mmap_sem) down_write(&mm->mmap_sem) vma = find_vma(mm, address) Signed-off-by: Libin Acked-by: Kirill A. Shutemov Reviewed-by: Wanpeng Li Reviewed-by: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4b699f4816c81533b7a1ce2169ae223cca1393cf Author: Greg Thelen Date: Wed Sep 11 14:23:08 2013 -0700 memcg: fix multiple large threshold notifications commit 2bff24a3707093c435ab3241c47dcdb5f16e432b upstream. A memory cgroup with (1) multiple threshold notifications and (2) at least one threshold >=2G was not reliable. Specifically the notifications would either not fire or would not fire in the proper order. The __mem_cgroup_threshold() signaling logic depends on keeping 64 bit thresholds in sorted order. mem_cgroup_usage_register_event() sorts them with compare_thresholds(), which returns the difference of two 64 bit thresholds as an int. If the difference is positive but has bit[31] set, then sort() treats the difference as negative and breaks sort order. This fix compares the two arbitrary 64 bit thresholds returning the classic -1, 0, 1 result. The test below sets two notifications (at 0x1000 and 0x81001000): cd /sys/fs/cgroup/memory mkdir x for x in 4096 2164264960; do cgroup_event_listener x/memory.usage_in_bytes $x | sed "s/^/$x listener:/" & done echo $$ > x/cgroup.procs anon_leaker 500M v3.11-rc7 fails to signal the 4096 event listener: Leaking... Done leaking pages. Patched v3.11-rc7 properly notifies: Leaking... 4096 listener:2013:8:31:14:13:36 Done leaking pages. The fixed bug is old. It appears to date back to the introduction of memcg threshold notifications in v2.6.34-rc1-116-g2e72b6347c94 "memcg: implement memory thresholds" Signed-off-by: Greg Thelen Acked-by: Michal Hocko Acked-by: Kirill A. Shutemov Acked-by: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f0fbb71f202e38e38c10d865b8b7cb6e4933b8b1 Author: Jie Liu Date: Wed Sep 11 14:20:05 2013 -0700 ocfs2: fix the end cluster offset of FIEMAP commit 28e8be31803b19d0d8f76216cb11b480b8a98bec upstream. Call fiemap ioctl(2) with given start offset as well as an desired mapping range should show extents if possible. However, we somehow figure out the end offset of mapping via 'mapping_end -= cpos' before iterating the extent records which would cause problems if the given fiemap length is too small to a cluster size, e.g, Cluster size 4096: debugfs.ocfs2 1.6.3 Block Size Bits: 12 Cluster Size Bits: 12 The extended fiemap test utility From David: https://gist.github.com/anonymous/6172331 # dd if=/dev/urandom of=/ocfs2/test_file bs=1M count=1000 # ./fiemap /ocfs2/test_file 4096 10 start: 4096, length: 10 File /ocfs2/test_file has 0 extents: # Logical Physical Length Flags ^^^^^ <-- No extent is shown In this case, at ocfs2_fiemap(): cpos == mapping_end == 1. Hence the loop of searching extent records was not executed at all. This patch remove the in question 'mapping_end -= cpos', and loops until the cpos is larger than the mapping_end as usual. # ./fiemap /ocfs2/test_file 4096 10 start: 4096, length: 10 File /ocfs2/test_file has 1 extents: # Logical Physical Length Flags 0: 0000000000000000 0000000056a01000 0000000006a00000 0000 Signed-off-by: Jie Liu Reported-by: David Weber Tested-by: David Weber Cc: Sunil Mushran Cc: Mark Fashen Cc: Joel Becker Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f230d52714f57e8154703e402d6d5afbba0f18fe Author: Oleg Nesterov Date: Wed Sep 11 14:19:38 2013 -0700 pidns: fix vfork() after unshare(CLONE_NEWPID) commit e79f525e99b04390ca4d2366309545a836c03bf1 upstream. Commit 8382fcac1b81 ("pidns: Outlaw thread creation after unshare(CLONE_NEWPID)") nacks CLONE_VM if the forking process unshared pid_ns, this obviously breaks vfork: int main(void) { assert(unshare(CLONE_NEWUSER | CLONE_NEWPID) == 0); assert(vfork() >= 0); _exit(0); return 0; } fails without this patch. Change this check to use CLONE_SIGHAND instead. This also forbids CLONE_THREAD automatically, and this is what the comment implies. We could probably even drop CLONE_SIGHAND and use CLONE_THREAD, but it would be safer to not do this. The current check denies CLONE_SIGHAND implicitely and there is no reason to change this. Eric said "CLONE_SIGHAND is fine. CLONE_THREAD would be even better. Having shared signal handling between two different pid namespaces is the case that we are fundamentally guarding against." Signed-off-by: Oleg Nesterov Reported-by: Colin Walters Acked-by: Andy Lutomirski Reviewed-by: "Eric W. Biederman" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cbe0a23a4e32d3c5fbec85b25eb4dfca6b219bd1 Author: Eric W. Biederman Date: Thu Aug 29 13:56:50 2013 -0700 pidns: Fix hang in zap_pid_ns_processes by sending a potentially extra wakeup commit a606488513543312805fab2b93070cefe6a3016c upstream. Serge Hallyn writes: > Since commit af4b8a83add95ef40716401395b44a1b579965f4 it's been > possible to get into a situation where a pidns reaper is > , reparented to host pid 1, but never reaped. How to > reproduce this is documented at > > https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1168526 > (and see > https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1168526/comments/13) > In short, run repeated starts of a container whose init is > > Process.exit(0); > > sysrq-t when such a task is playing zombie shows: > > [ 131.132978] init x ffff88011fc14580 0 2084 2039 0x00000000 > [ 131.132978] ffff880116e89ea8 0000000000000002 ffff880116e89fd8 0000000000014580 > [ 131.132978] ffff880116e89fd8 0000000000014580 ffff8801172a0000 ffff8801172a0000 > [ 131.132978] ffff8801172a0630 ffff88011729fff0 ffff880116e14650 ffff88011729fff0 > [ 131.132978] Call Trace: > [ 131.132978] [] schedule+0x29/0x70 > [ 131.132978] [] do_exit+0x6e1/0xa40 > [ 131.132978] [] ? signal_wake_up_state+0x1e/0x30 > [ 131.132978] [] do_group_exit+0x3f/0xa0 > [ 131.132978] [] SyS_exit_group+0x14/0x20 > [ 131.132978] [] tracesys+0xe1/0xe6 > > Further debugging showed that every time this happened, zap_pid_ns_processes() > started with nr_hashed being 3, while we were expecting it to drop to 2. > Any time it didn't happen, nr_hashed was 1 or 2. So the reaper was > waiting for nr_hashed to become 2, but free_pid() only wakes the reaper > if nr_hashed hits 1. The issue is that when the task group leader of an init process exits before other tasks of the init process when the init process finally exits it will be a secondary task sleeping in zap_pid_ns_processes and waiting to wake up when the number of hashed pids drops to two. This case waits forever as free_pid only sends a wake up when the number of hashed pids drops to 1. To correct this the simple strategy of sending a possibly unncessary wake up when the number of hashed pids drops to 2 is adopted. Sending one extraneous wake up is relatively harmless, at worst we waste a little cpu time in the rare case when a pid namespace appropaches exiting. We can detect the case when the pid namespace drops to just two pids hashed race free in free_pid. Dereferencing pid_ns->child_reaper with the pidmap_lock held is safe without out the tasklist_lock because it is guaranteed that the detach_pid will be called on the child_reaper before it is freed and detach_pid calls __change_pid which calls free_pid which takes the pidmap_lock. __change_pid only calls free_pid if this is the last use of the pid. For a thread that is not the thread group leader the threads pid will only ever have one user because a threads pid is not allowed to be the pid of a process, of a process group or a session. For a thread that is a thread group leader all of the other threads of that process will be reaped before it is allowed for the thread group leader to be reaped ensuring there will only be one user of the threads pid as a process pid. Furthermore because the thread is the init process of a pid namespace all of the other processes in the pid namespace will have also been already freed leading to the fact that the pid will not be used as a session pid or a process group pid for any other running process. Acked-by: Serge Hallyn Tested-by: Serge Hallyn Reported-by: Serge Hallyn Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 33d979ef579c0786beb27115d427cf6693e57981 Author: Alex Williamson Date: Sat Jun 15 10:27:19 2013 -0600 intel-iommu: Fix leaks in pagetable freeing commit 3269ee0bd6686baf86630300d528500ac5b516d7 upstream. At best the current code only seems to free the leaf pagetables and the root. If you're unlucky enough to have a large gap (like any QEMU guest with more than 3G of memory), only the first chunk of leaf pagetables are freed (plus the root). This is a massive memory leak. This patch re-writes the pagetable freeing function to use a recursive algorithm and manages to not only free all the pagetables, but does it without any apparent performance loss versus the current broken version. Signed-off-by: Alex Williamson Reviewed-by: Marcelo Tosatti Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 7c0f09b99b7c8947d255c511677480cae9fd4582 Author: Gera Kazakov Date: Mon Sep 9 15:47:06 2013 -0700 target: Fix >= v3.9+ regression in PR APTPL + ALUA metadata write-out commit f730f9158f6ee7b5c4d892af6b51a72194445ea4 upstream. This patch fixes a >= v3.9+ regression in __core_scsi3_write_aptpl_to_file() + core_alua_write_tpg_metadata() write-out, where a return value of -EIO was incorrectly being returned upon success. This bug was originally introduced in: commit 0e9b10a90f1c30f25dd6f130130240745ab14010 Author: Al Viro Date: Sat Feb 23 15:22:43 2013 -0500 target: writev() on single-element vector is pointless However, given that the return of core_scsi3_update_and_write_aptpl() was not used to determine if a command should be returned with non GOOD status, this bug was not being triggered in PR logic until v3.11-rc1 by commit: commit 459f213ba162bd13e113d6f92a8fa6c780fd67ed Author: Andy Grover Date: Thu May 16 10:41:02 2013 -0700 target: Allocate aptpl_buf inside update_and_write_aptpl() So, go ahead and only return -EIO if kernel_write() returned a negative value. Reported-by: Gera Kazakov Signed-off-by: Gera Kazakov Cc: Al Viro Cc: Andy Grover Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 2e7120add8f30650e99ab397bd03de2d4b8c1b35 Author: Felix Fietkau Date: Wed Aug 28 10:41:42 2013 +0200 MIPS: ath79: Fix ar933x watchdog clock commit a1191927ace7e6f827132aa9e062779eb3f11fa5 upstream. The watchdog device on the AR933x is connected to the AHB clock, however the current code uses the reference clock. Due to the wrong rate, the watchdog driver can't calculate correct register values for a given timeout value and the watchdog unexpectedly restarts the system. The code uses the wrong value since the initial commit 04225e1d227c8e68d685936ecf42ac175fec0e54 (MIPS: ath79: add AR933X specific clock init) The patch fixes the code to use the correct clock rate to avoid the problem. Signed-off-by: Felix Fietkau Signed-off-by: Gabor Juhos Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/5777/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit e4ff584fe9746102279015d7dd364685108f1799 Author: Mark Brown Date: Thu Aug 29 07:18:14 2013 -0700 leds: wm831x-status: Request a REG resource commit 61abeba5222895d6900b13115f5d8eba7988d7d6 upstream. The wm831x-status driver was not converted to use a REG resource when they were introduced and the rest of the wm831x drivers converted, causing it to fail to probe due to requesting the wrong resource type. Signed-off-by: Mark Brown Signed-off-by: Bryan Wu Signed-off-by: Greg Kroah-Hartman commit 003386069c5be7067c98172549780f428702d5b9 Author: Oleg Nesterov Date: Wed Sep 11 17:47:26 2013 +0200 uprobes: Fix utask->depth accounting in handle_trampoline() commit 878b5a6efd38030c7a90895dc8346e8fb1e09b4c upstream. Currently utask->depth is simply the number of allocated/pending return_instance's in uprobe_task->return_instances list. handle_trampoline() should decrement this counter every time we handle/free an instance, but due to typo it does this only if ->chained == T. This means that in the likely case this counter is never decremented and the probed task can't report more than MAX_URETPROBE_DEPTH events. Reported-by: Mikhail Kulemin Reported-by: Hemant Kumar Shaw Signed-off-by: Oleg Nesterov Acked-by: Anton Arapov Cc: masami.hiramatsu.pt@hitachi.com Cc: srikar@linux.vnet.ibm.com Cc: systemtap@sourceware.org Link: http://lkml.kernel.org/r/20130911154726.GA8093@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit cc321317742a40f067481dcc4077392305d76054 Author: Stefan Behrens Date: Mon Aug 19 18:51:13 2013 +0200 Btrfs: don't allow the replace procedure on read only filesystems commit bbb651e469d99f0088e286fdeb54acca7bb4ad4e upstream. If you start the replace procedure on a read only filesystem, at the end the procedure fails to write the updated dev_items to the chunk tree. The problem is that this error is not indicated except for a WARN_ON(). If the user now thinks that everything was done as expected and destroys the source device (with mkfs or with a hammer). The next mount fails with "failed to read chunk root" and the filesystem is gone. This commit adds code to fail the attempt to start the replace procedure if the filesystem is mounted read-only. Signed-off-by: Stefan Behrens Signed-off-by: Josef Bacik Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit f118b54803039546620476f4766ec591919131b0 Author: Bjørn Mork Date: Wed Aug 14 05:24:39 2013 -0300 media: siano: fix divide error on 0 counters commit ec532503209053bbee0c7dac410031e50835e01a upstream. GIT_AUTHOR_DATE=1376465691 I took a quick look at the code and wonder if the problem is caused by an initial zero statistics message? This is all just a wild guess, but if it is correct, then the attached untested patch might fix it... Bjørn >From d78a0599d5b5d4da384eae08bf7da316389dfbe5 Mon Sep 17 00:00:00 2001 ts_packets and ets_packets counters can be 0. Don't fall over if they are. Fixes: [ 846.851711] divide error: 0000 [#1] SMP [ 846.851806] Modules linked in: smsdvb dvb_core ir_lirc_codec lirc_dev ir_sanyo_decoder ir_mce_kbd_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder rc_hauppauge smsusb smsmdtv rc_core pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) parport_pc ppdev lp parport cpufreq_userspace cpufreq_powersave cpufreq_stats cpufreq_conservative rfcomm bnep binfmt_misc uinput nfsd auth_rpcgss oid_registry nfs_acl nfs lockd dns_resolver fscache sunrpc ext4 jbd2 fuse tp_smapi(O) thinkpad_ec(O) loop firewire_sbp2 dm_crypt snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm thinkpad_acpi nvram snd_page_alloc hid_generic snd_seq_midi snd_seq_midi_event arc4 usbhid snd_rawmidi uvcvideo hid iwldvm coretemp kvm_intel mac8021 1 cdc_wdm [ 846.853477] cdc_acm snd_seq videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media kvm radeon r852 ttm joydev cdc_ether usbnet pcmcia mii sm_common nand btusb drm_kms_helper tpm_tis acpi_cpufreq bluetooth iwlwifi nand_ecc drm nand_ids i2c_i801 mtd snd_seq_device iTCO_wdt iTCO_vendor_support r592 memstick lpc_ich mperf tpm yenta_socket pcmcia_rsrc pcmcia_core cfg80211 snd_timer snd pcspkr i2c_algo_bit crc16 i2c_core tpm_bios processor mfd_core wmi psmouse mei_me rfkill mei serio_raw soundcore evdev battery button video ac microcode ext3 mbcache jbd md_mod dm_mirror dm_region_hash dm_log dm_mod sg sr_mod sd_mod cdrom crc_t10dif firewire_ohci sdhci_pci sdhci mmc_core firewire_core crc_itu_t thermal thermal_sys ahci libahci ehci_pci uhci_hcd ehci_hcd libata scsi_mod usbcore e1000 e usb_common [ 846.855310] ptp pps_core [ 846.855356] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 3.10-2-amd64 #1 Debian 3.10.5-1 [ 846.855490] Hardware name: LENOVO 4061WFA/4061WFA, BIOS 6FET92WW (3.22 ) 12/14/2011 [ 846.855609] task: ffffffff81613400 ti: ffffffff81600000 task.ti: ffffffff81600000 [ 846.855636] RIP: 0010:[] [] smsdvb_onresponse+0x264/0xa86 [smsdvb] [ 846.863906] RSP: 0018:ffff88013bc03cf0 EFLAGS: 00010046 [ 846.863906] RAX: 0000000000000000 RBX: ffff880133bf6000 RCX: 0000000000000000 [ 846.863906] RDX: 0000000000000000 RSI: ffff88005d3b58c0 RDI: ffff880133bf6000 [ 846.863906] RBP: ffff88005d1da000 R08: 0000000000000058 R09: 0000000000000015 [ 846.863906] R10: 0000000000001a0d R11: 000000000000021a R12: ffff88005d3b58c0 [ 846.863906] R13: ffff88005d1da008 R14: 00000000ffffff8d R15: ffff880036cf5060 [ 846.863906] FS: 0000000000000000(0000) GS:ffff88013bc00000(0000) knlGS:0000000000000000 [ 846.863906] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 846.863906] CR2: 00007f3a4b69ae50 CR3: 0000000036dac000 CR4: 00000000000407f0 [ 846.863906] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 846.863906] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 846.863906] Stack: [ 846.863906] ffff88007a102000 ffff88005d1da000 ffff88005d3b58c0 0000000000085824 [ 846.863906] ffffffffa08c5aa3 ffff88005d1da000 ffff8800a6907390 ffff8800a69073b0 [ 846.863906] ffff8800a6907000 ffffffffa08b642c 000000000000021a ffff8800a69073b0 [ 846.863906] Call Trace: [ 846.863906] [ 846.863906] [ 846.863906] [] ? smscore_onresponse+0x1d5/0x353 [smsmdtv] [ 846.863906] [] ? smsusb_onresponse+0x146/0x192 [smsusb] [ 846.863906] [] ? usb_hcd_giveback_urb+0x6c/0xac [usbcore] [ 846.863906] [] ? ehci_urb_done+0x62/0x72 [ehci_hcd] [ 846.863906] [] ? qh_completions+0x91/0x364 [ehci_hcd] [ 846.863906] [] ? ehci_work+0x8a/0x68e [ehci_hcd] [ 846.863906] [] ? timekeeping_get_ns.constprop.10+0xd/0x31 [ 846.863906] [] ? update_cfs_rq_blocked_load+0xde/0xec [ 846.863906] [] ? run_posix_cpu_timers+0x25/0x575 [ 846.863906] [] ? ehci_irq+0x211/0x23d [ehci_hcd] [ 846.863906] [] ? usb_hcd_irq+0x31/0x48 [usbcore] [ 846.863906] [] ? handle_irq_event_percpu+0x49/0x1a4 [ 846.863906] [] ? handle_irq_event+0x32/0x4b [ 846.863906] [] ? handle_fasteoi_irq+0x80/0xb6 [ 846.863906] [] ? handle_irq+0x18/0x20 [ 846.863906] [] ? do_IRQ+0x40/0x95 [ 846.863906] [] ? common_interrupt+0x6d/0x6d [ 846.863906] [ 846.863906] [ 846.863906] [] ? arch_local_irq_enable+0x4/0x8 [ 846.863906] [] ? cpuidle_enter_state+0x52/0xc1 [ 846.863906] [] ? cpuidle_idle_call+0xd4/0x143 [ 846.863906] [] ? arch_cpu_idle+0x5/0x17 [ 846.863906] [] ? cpu_startup_entry+0x10d/0x187 [ 846.863906] [] ? start_kernel+0x3e8/0x3f3 [ 846.863906] [] ? repair_env_string+0x54/0x54 [ 846.863906] [] ? x86_64_start_kernel+0xf2/0xfd [ 846.863906] Code: 25 09 00 00 c6 83 da 08 00 00 03 8b 45 54 48 01 83 b6 08 00 00 8b 45 50 48 01 83 db 08 00 00 8b 4d 18 69 c1 ff ff 00 00 03 4d 14 <48> f7 f1 89 83 a8 09 00 00 e9 68 fe ff ff 48 8b 7f 10 e8 79 92 [ 846.863906] RIP [] smsdvb_onresponse+0x264/0xa86 [smsdvb] [ 846.863906] RSP Reference: http://bugs.debian.org/719623 Reported-by: Johannes Rohr Signed-off-by: Bjørn Mork Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 7c33812d06bf03d8225fa854e5a609141bf7a528 Author: Mauro Carvalho Chehab Date: Fri Aug 9 08:53:26 2013 -0300 media: mb86a20s: Fix TS parallel mode commit 9d32069faacdc81fe1dcb5d297c32a3ac81da8f0 upstream. changeset 768e6dadd74 caused a regression on using mb86a20s in parallel mode, as the parallel mode selection got overriden by mb86a20s_init2. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 1e4508a37512de3bcbc8475cd56bf2b887ae59f8 Author: Hans Verkuil Date: Tue Aug 27 04:27:57 2013 -0300 media: cx88: Fix regression: CX88_AUDIO_WM8775 can't be 0 commit f66b2a1c7f2ae3fb0d5b67d07ab4f5055fd3cf16 upstream. Cards using the wm8775 specify that in their card struct. Those that do not use it leave the audio_chip field to 0. Unfortunately, the CX88_AUDIO_WM8775 enum is 0 as well, so boards that do not have the wm8775 still try to load and use that driver. Change it to 1 to fix this. This regression was introduced in commit facd23664f1d63c33fbc6da52261c8548ed3fbd4. Signed-off-by: Hans Verkuil Reported-by: Knut Petersen Tested-by: Knut Petersen Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 098b05d9e286a59b74e6102992aa4c76dc7098dd Author: Sylwester Nawrocki Date: Mon Jul 29 06:53:59 2013 -0300 media: exynos4-is: Fix entity unregistration on error path commit d2b903b4427e417a73863cef36ad0796ea6b7404 upstream. This patch corrects media entities unregistration order to make sure the fimc.N.capture and fimc-lite video nodes are unregistered with fimc->lock mutex held. This prevents races between video device open() and defered probing and NULL pointer dereference in open() callback as follows: [ 77.645000] Unable to handle kernel NULL pointer dereference at virtual address 00000290t [ 77.655000] pgd = ee7a8000 [ 77.660000] [00000290] *pgd=6e13c831, *pte=00000000, *ppte=00000000 [ 77.665000] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [ 77.670000] Modules linked in: s5p_fimc ipv6 exynos_fimc_is exynos_fimc_lite s5p_csis v4l2_mem2mem videobuf2_dma_contig videobuf2_memops exynos4_is_common videobuf2_core [last unloaded: s5p_fimc] [ 77.685000] CPU: 0 PID : 2998 Comm: v4l_id Tainted: G W 3.10.0-next-20130709-00039-g39f491b-dirty #1548 [ 77.695000] task: ee084000 ti: ee46e000 task.ti: ee46e000 [ 77.700000] PC is at __mutex_lock_slowpath+0x54/0x368 [ 77.705000] LR is at __mutex_lock_slowpath+0x24/0x368 [ 77.710000] pc : [] lr : [] psr: 60000093 [ 77.710000] sp : ee46fd70 ip : 000008c8 fp : c054e34c [ 77.725000] r10: ee084000 r9 : 00000000 r8 : ee439480 [ 77.730000] r7 : ee46e000 r6 : 60000013 r5 : 00000290 r4 : 0000028c [ 77.735000] r3 : 00000000 r2 : 00000000 r1 : 20000093 r0 : 00000001 [ 77.740000] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [ 77.750000] Control: 10c5387d Table: 6e7a804a DAC: 00000015 [ 77.755000] Process v4l_id (pid: 2998, stack limit = 0xee46e238) [ 77.760000] Stack: (0xee46fd70 to 0xee470000) ... [ 77.935000] [] (__mutex_lock_slowpath+0x54/0x368) from [] (mutex_lock+0xc/0x24) [ 77.945000] [] (mutex_lock+0xc/0x24) from [] (fimc_lite_open+0x12c/0x2bc [exynos_fimc_lite]) [ 77.955000] [] (fimc_lite_open+0x12c/0x2bc [exynos_fimc_lite]) from [] (v4l2_open+0xa0/0xe0) [ 77.965000] [] (v4l2_open+0xa0/0xe0) from [] (chrdev_open+0x88/0x170) [ 77.975000] [] (chrdev_open+0x88/0x170) from [] (do_dentry_open.isra.14+0x1d8/0x258) [ 77.985000] [] (do_dentry_open.isra.14+0x1d8/0x258) from [] (finish_open+0x20/0x38) [ 77.995000] [] (finish_open+0x20/0x38) from [] (do_last.isra.43+0x538/0xb1c) [ 78.000000] [] (do_last.isra.43+0x538/0xb1c) from [] (path_openat+0xb4/0x5c4) [ 78.010000] [] (path_openat+0xb4/0x5c4) from [] (do_filp_open+0x2c/0x80) [ 78.020000] [] (do_filp_open+0x2c/0x80) from [] (do_sys_open+0xf4/0x1a8) [ 78.025000] [] (do_sys_open+0xf4/0x1a8) from [] (ret_fast_syscall+0x0/0x30) [ 78.035000] Code: 1a000093 e10f6000 f10c0080 e2845004 (e1953f9f) Reported-by: Andrzej Hajda Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 51a94c0a3514b2c528163c416cedd3e07b53c658 Author: Arun Kumar K Date: Fri Jul 26 07:28:01 2013 -0300 media: exynos-gsc: Register v4l2 device commit d0b1c31349969973204fad21a076aecf131cc5e4 upstream. Gscaler video device registration was happening without reference to a parent v4l2_dev causing probe to fail. The patch creates a parent v4l2 device and uses it for the gsc m2m video device registration. This fixes regression introduced with comit commit 1c1d86a1ea07506 [media] v4l2: always require v4l2_dev, rename parent to dev_parent Signed-off-by: Arun Kumar K Signed-off-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 04d49c323237a3e9ed15b13808ea55ec06310ba7 Author: Arun Kumar K Date: Mon Jul 15 07:51:23 2013 -0300 media: exynos4-is: Fix fimc-lite bayer formats commit 3396b096c54a84603c51bd705effa88f7f5b0d76 upstream. The 10-bit and 12-bit Bayer output formats supported by FIMC-LITE actually use 16 bits where the extra bits are padded with zeros. The patch corrects buffer allocation for these two formats by modifying the depth field. This prevents memory corruption by the output DMA due to insufficient buffer size. Signed-off-by: Arun Kumar K Signed-off-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit c2bb0ac102c4d80963c26a68aabd78faa173652e Author: Vasily Titskiy Date: Fri Aug 30 18:25:04 2013 -0400 HID: usbhid: quirk for N-Trig DuoSense Touch Screen commit 9e0bf92c223dabe0789714f8f85f6e26f8f9cda4 upstream. The DuoSense touchscreen device causes a 10 second timeout. This fix removes the delay. Signed-off-by: Vasily Titskiy Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit b78f205047ea6dadfe560b696d99e374d0c497c0 Author: Kees Cook Date: Wed Aug 28 22:32:01 2013 +0200 HID: check for NULL field when setting values commit be67b68d52fa28b9b721c47bb42068f0c1214855 upstream. Defensively check that the field to be worked on is not NULL. Signed-off-by: Kees Cook Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 11c32876ee1e04043f251b4ffadae2e639f5bfdf Author: Manoj Chourasia Date: Mon Jul 22 15:33:13 2013 +0530 HID: hidraw: correctly deallocate memory on device disconnect commit 212a871a3934beccf43431608c27ed2e05a476ec upstream. This changes puts the commit 4fe9f8e203f back in place with the fixes for slab corruption because of the commit. When a device is unplugged, wait for all processes that have opened the device to close before deallocating the device. This commit was solving kernel crash because of the corruption in rb tree of vmalloc. The rootcause was the device data pointer was geting excessed after the memory associated with hidraw was freed. The commit 4fe9f8e203f was buggy as it was also freeing the hidraw first and then calling delete operation on the list associated with that hidraw leading to slab corruption. Signed-off-by: Manoj Chourasia Tested-by: Peter Wu Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit f0c298af1d7ac27bef191a8593c14244341efb01 Author: Jiri Kosina Date: Mon Sep 2 13:43:00 2013 +0200 HID: battery: don't do DMA from stack commit 6c2794a2984f4c17a58117a68703cc7640f01c5a upstream. Instead of using data from stack for DMA in hidinput_get_battery_property(), allocate the buffer dynamically. Reported-by: Richard Ryniker Reported-by: Alan Stern Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 6794022829cf3bea51a4dc9c4e1ca94a42aaa677 Author: Bruno Prémont Date: Sat Aug 31 14:07:48 2013 +0200 HID: picolcd: Prevent NULL pointer dereference on _remove() commit 1cde501bb4655e98fb832194beb88ac73be5a05d upstream. When picolcd is switched into bootloader mode (for FW flashing) make sure not to try to dereference NULL-pointers of feature-devices during unplug/unbind. This fixes following BUG: BUG: unable to handle kernel NULL pointer dereference at 00000298 IP: [] picolcd_exit_framebuffer+0x1b/0x80 [hid_picolcd] *pde = 00000000 Oops: 0000 [#1] Modules linked in: hid_picolcd syscopyarea sysfillrect sysimgblt fb_sys_fops CPU: 0 PID: 15 Comm: khubd Not tainted 3.11.0-rc7-00002-g50d62d4 #2 EIP: 0060:[] EFLAGS: 00010292 CPU: 0 EIP is at picolcd_exit_framebuffer+0x1b/0x80 [hid_picolcd] Call Trace: [] picolcd_remove+0xcb/0x120 [hid_picolcd] [] hid_device_remove+0x59/0xc0 [] __device_release_driver+0x5a/0xb0 [] device_release_driver+0x1f/0x30 [] bus_remove_device+0x9d/0xd0 [] device_del+0xd5/0x150 [] hid_destroy_device+0x24/0x60 [] usbhid_disconnect+0x1b/0x40 ... Signed-off-by: Bruno Prémont Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit fced5cedf4b0b2bc79413ac3c9498bbe2f98f7ba Author: Kees Cook Date: Wed Aug 28 22:31:28 2013 +0200 HID: ntrig: validate feature report details commit 875b4e3763dbc941f15143dd1a18d10bb0be303b upstream. A HID device could send a malicious feature report that would cause the ntrig HID driver to trigger a NULL dereference during initialization: [57383.031190] usb 3-1: New USB device found, idVendor=1b96, idProduct=0001 ... [57383.315193] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030 [57383.315308] IP: [] ntrig_probe+0x25e/0x420 [hid_ntrig] CVE-2013-2896 Signed-off-by: Kees Cook Signed-off-by: Rafi Rubin Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit b6381b665759c46c1d0676b934a6129a20df7eef Author: Kees Cook Date: Wed Aug 28 22:31:52 2013 +0200 HID: picolcd_core: validate output report details commit 1e87a2456b0227ca4ab881e19a11bb99d164e792 upstream. A HID device could send a malicious output report that would cause the picolcd HID driver to trigger a NULL dereference during attr file writing. [jkosina@suse.cz: changed report->maxfield < 1 to report->maxfield != 1 as suggested by Bruno]. CVE-2013-2899 Signed-off-by: Kees Cook Reviewed-by: Bruno Prémont Acked-by: Bruno Prémont Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit eedeac300ac807db2f7b035b93b4644e894656d7 Author: Kees Cook Date: Wed Aug 28 22:29:55 2013 +0200 HID: validate HID report id size commit 43622021d2e2b82ea03d883926605bdd0525e1d1 upstream. The "Report ID" field of a HID report is used to build indexes of reports. The kernel's index of these is limited to 256 entries, so any malicious device that sets a Report ID greater than 255 will trigger memory corruption on the host: [ 1347.156239] BUG: unable to handle kernel paging request at ffff88094958a878 [ 1347.156261] IP: [] hid_register_report+0x2a/0x8b CVE-2013-2888 Signed-off-by: Kees Cook Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 0c268dc93631a821dc5cc323e77b8be51bc58ea5 Author: Kees Cook Date: Wed Aug 28 22:31:44 2013 +0200 HID: sensor-hub: validate feature report details commit 9e8910257397372633e74b333ef891f20c800ee4 upstream. A HID device could send a malicious feature report that would cause the sensor-hub HID driver to read past the end of heap allocation, leaking kernel memory contents to the caller. CVE-2013-2898 Signed-off-by: Kees Cook Reviewed-by: Mika Westerberg Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 2a767434dc7cd4cc3e188c20ba53a2f4ecd3f413 Author: Stefan Kriwanek Date: Sun Aug 25 10:46:13 2013 +0200 HID: Fix Speedlink VAD Cezanne support for some devices commit 06bb5219118fb098f4b0c7dcb484b28a52bf1c14 upstream. Some devices of the "Speedlink VAD Cezanne" model need more aggressive fixing than already done. I made sure through testing that this patch would not interfere with the proper working of a device that is bug-free. (The driver drops EV_REL events with abs(val) >= 256, which are not achievable even on the highest laser resolution hardware setting.) Signed-off-by: Stefan Kriwanek Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 1e21323805fe0c851c3182d68bf2130e30fe92ed Author: David Herrmann Date: Sun Aug 4 18:50:10 2013 +0200 HID: wiimote: work around broken DRM_KAI on GEN10 commit a6be8569b6705cbc26e7ae1a8be476067cc5a78b upstream. GEN10 and earlier devices seem to not support DRM_KAI if we run in basic IR mode. Use DRM_KAIE instead. This might increases overhead slightly as the extension port is read and streamed but we stream accelerometer data constantly, too, so this is negligible. Note that our parsers are hardcoded on IR-formats, so we cannot actually use 96-bit IR DRMs for basic IR data. We would have to adjust the parsers. But as only GEN20 and newer support this, we simply avoid mixed DRMs. This fixes a bug where GEN10 devices didn't provide IR data if accelerometer and IR are enabled simultaneously. As a workaround, you can enable DRM_KAIE without this patch via (disables device power-management): echo "37" >/sys/kernel/debug/hid//drm Signed-off-by: David Herrmann Reported-by: Nicolas Adenis-Lamarre Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 41570c0dd9cd83f10bf6bb7d4c25614ed5f0a93e Author: Benjamin Tissoires Date: Mon Jul 15 10:12:18 2013 +0200 HID: kye: Add report fixup for Genius Gx Imperator Keyboard commit 0adb9c2c5ed42f199cb2a630c37d18dee385fae2 upstream. Genius Gx Imperator Keyboard presents the same problem in its report descriptors than Genius Gila Gaming Mouse. Use the same fixup for both. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=928561 Reported-and-tested-by: Honza Brazdil Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit b4a080ec8caf2f4b941d0513c5603bf71e929344 Author: Kees Cook Date: Wed Aug 28 22:30:49 2013 +0200 HID: pantherlord: validate output report details commit 412f30105ec6735224535791eed5cdc02888ecb4 upstream. A HID device could send a malicious output report that would cause the pantherlord HID driver to write beyond the output report allocation during initialization, causing a heap overflow: [ 310.939483] usb 1-1: New USB device found, idVendor=0e8f, idProduct=0003 ... [ 315.980774] BUG kmalloc-192 (Tainted: G W ): Redzone overwritten CVE-2013-2892 Signed-off-by: Kees Cook Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 8e6c614e73ca485f53e4a29d7b02d5e55f6fa0f7 Author: Henrik Rydberg Date: Sun Sep 1 15:31:44 2013 +0200 HID: Correct the USB IDs for the new Macbook Air 6 commit 8c89cc17b91992845bd635813cd162fe8dfcec6e upstream. A recent patch (9d9a04ee) added support for the new machine, but got the sequence of USB ids wrong. Reports from both Ian and Linus T show that the 0x0291 id is for ISO, not ANSI, which should have the missing number 0x0290. This patchs moves the three numbers accordingly, fixing the problem. Reported-and-tested-by: Ian Munsie Tested-by: Linus G Thiel Signed-off-by: Henrik Rydberg Acked-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 5025e680a6cb1a1b61852ba1ae26a3049085d2f0 Author: Thomas Petazzoni Date: Wed Sep 4 16:21:18 2013 +0200 net: mvneta: properly disable HW PHY polling and ensure adjust_link() works commit 714086029116b6b0a34e67ba1dd2f0d1cf26770c upstream. This commit fixes a long-standing bug that has been reported by many users: on some Armada 370 platforms, only the network interface that has been used in U-Boot to tftp the kernel works properly in Linux. The other network interfaces can see a 'link up', but are unable to transmit data. The reports were generally made on the Armada 370-based Mirabox, but have also been given on the Armada 370-RD board. The network MAC in the Armada 370/XP (supported by the mvneta driver in Linux) has a functionality that allows it to continuously poll the PHY and directly update the MAC configuration accordingly (speed, duplex, etc.). The very first versions of the driver submitted for review were using this hardware mechanism, but due to this, the driver was not integrated with the kernel phylib. Following reviews, the driver was changed to use the phylib, and therefore a software based polling. In software based polling, Linux regularly talks to the PHY over the MDIO bus, and sees if the link status has changed. If it's the case then the adjust_link() callback of the driver is called to update the MAC configuration accordingly. However, it turns out that the adjust_link() callback was not configuring the hardware in a completely correct way: while it was setting the speed and duplex bits correctly, it wasn't telling the hardware to actually take into account those bits rather than what the hardware-based PHY polling mechanism has concluded. So, in fact the adjust_link() callback was basically a no-op. However, the network happened to be working because on the network interfaces used by U-Boot for tftp on Armada 370 platforms because the hardware PHY polling was enabled by the bootloader, and left enabled by Linux. However, the second network interface not used for tftp (or both network interfaces if the kernel is loaded from USB, NAND or SD card) didn't had the hardware PHY polling enabled. This patch fixes this situation by: (1) Making sure that the hardware PHY polling is disabled by clearing the MVNETA_PHY_POLLING_ENABLE bit in the MVNETA_UNIT_CONTROL register in the driver ->probe() function. (2) Making sure that the duplex and speed selections made by the adjust_link() callback are taken into account by clearing the MVNETA_GMAC_AN_SPEED_EN and MVNETA_GMAC_AN_DUPLEX_EN bits in the MVNETA_GMAC_AUTONEG_CONFIG register. This patch has been tested on Armada 370 Mirabox, and now both network interfaces are usable after boot. [ Problem introduced by commit c5aff18 ("net: mvneta: driver for Marvell Armada 370/XP network unit") ] Signed-off-by: Thomas Petazzoni Cc: Willy Tarreau Cc: Jochen De Smet Cc: Peter Sanford Cc: Ethan Tuttle Cc: Chény Yves-Gael Cc: Ryan Press Cc: Simon Guinot Cc: vdonnefort@lacie.com Acked-by: Jason Cooper Tested-by: Vincent Donnefort Tested-by: Yves-Gael Cheny Tested-by: Gregory CLEMENT Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c661b37a34b6449d533c109472e19c7b005d164b Author: Felix Fietkau Date: Tue Aug 13 12:33:28 2013 +0200 ath9k: avoid accessing MRC registers on single-chain devices commit a1c781bb20ac1e03280e420abd47a99eb8bbdd3b upstream. They are not implemented, and accessing them might trigger errors Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 452c0dc821996470f847ac57dd3ca51a34a4c017 Author: Felix Fietkau Date: Sat Aug 10 15:59:15 2013 +0200 ath9k: fix rx descriptor related race condition commit e96542e55a2aacf4bdeccfe2f17b77c4895b4df2 upstream. Similar to a race condition that exists in the tx path, the hardware might re-read the 'next' pointer of a descriptor of the last completed frame. This only affects non-EDMA (pre-AR93xx) devices. To deal with this race, defer clearing and re-linking a completed rx descriptor until the next one has been processed. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 6b8aad8df84daa0175627f36b2f299ba8e7b55e6 Author: Felix Fietkau Date: Tue Aug 6 14:18:10 2013 +0200 ath9k: always clear ps filter bit on new assoc commit 026d5b07c03458f9c0ccd19c3850564a5409c325 upstream. Otherwise in some cases, EAPOL frames might be filtered during the initial handshake, causing delays and assoc failures. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 1bb32952f9ec5a841d199d82a8c70328b0ee5cb6 Author: John W. Linville Date: Fri Aug 9 13:36:21 2013 -0400 brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error() commit 67d0cf50bd32b66eab709871714e55725ee30ce4 upstream. The driver fails to check the results of DMA mapping in twp places, which results in the following warning: [ 28.078515] ------------[ cut here ]------------ [ 28.078529] WARNING: at lib/dma-debug.c:937 check_unmap+0x47e/0x930() [ 28.078533] bcma-pci-bridge 0000:0e:00.0: DMA-API: device driver failed to check map error[device address=0x00000000b5d60d6c] [size=1876 bytes] [mapped as single] [ 28.078536] Modules linked in: bnep bluetooth vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 b43 brcmsmac rtl8192cu rtl8192c_common rtlwifi mac802 11 brcmutil cfg80211 snd_hda_codec_conexant rng_core snd_hda_intel kvm_amd snd_hda_codec ssb kvm mmc_core snd_pcm snd_seq snd_timer snd_seq_device snd k8temp cordic joydev serio_raw hwmon sr_mod sg pcmcia pcmcia_core soundcore cdrom i2c_nforce2 i2c_core forcedeth bcma snd_page_alloc autofs4 ext4 jbd2 mbcache crc1 6 scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic pata_amd [ 28.078602] CPU: 1 PID: 2570 Comm: NetworkManager Tainted: G O 3.10.0-rc7-wl+ #42 [ 28.078605] Hardware name: Hewlett-Packard HP Pavilion dv2700 Notebook PC/30D6, BIOS F.27 11/27/2008 [ 28.078607] 0000000000000009 ffff8800bbb03ad8 ffffffff8144f898 ffff8800bbb03b18 [ 28.078612] ffffffff8103e1eb 0000000000000002 ffff8800b719f480 ffff8800b7b9c010 [ 28.078617] ffffffff824204c0 ffffffff81754d57 0000000000000754 ffff8800bbb03b78 [ 28.078622] Call Trace: [ 28.078624] [] dump_stack+0x19/0x1b [ 28.078634] [] warn_slowpath_common+0x6b/0xa0 [ 28.078638] [] warn_slowpath_fmt+0x41/0x50 [ 28.078650] [] check_unmap+0x47e/0x930 [ 28.078655] [] debug_dma_unmap_page+0x5c/0x70 [ 28.078679] [] dma64_getnextrxp+0x10c/0x190 [brcmsmac] [ 28.078691] [] dma_rx+0x62/0x240 [brcmsmac] [ 28.078707] [] brcms_c_dpc+0x211/0x9d0 [brcmsmac] [ 28.078717] [] ? brcms_dpc+0x27/0xf0 [brcmsmac] [ 28.078731] [] brcms_dpc+0x47/0xf0 [brcmsmac] [ 28.078736] [] tasklet_action+0x6c/0xf0 --snip-- [ 28.078974] [] SyS_sendmsg+0xd/0x20 [ 28.078979] [] tracesys+0xdd/0xe2 [ 28.078982] ---[ end trace 6164d1a08148e9c8 ]--- [ 28.078984] Mapped at: [ 28.078985] [] debug_dma_map_page+0x9d/0x150 [ 28.078989] [] dma_rxfill+0x102/0x3d0 [brcmsmac] [ 28.079001] [] brcms_c_init+0x87d/0x1100 [brcmsmac] [ 28.079010] [] brcms_init+0x21/0x30 [brcmsmac] [ 28.079018] [] brcms_c_up+0x150/0x430 [brcmsmac] As the patch adds a new failure mechanism to dma_rxfill(). When I changed the comment at the start of the routine to add that information, I also polished the wording. Signed-off-by: Larry Finger Cc: Brett Rudley Cc: Franky (Zhenhui) Lin Cc: Hante Meuleman Cc: brcm80211-dev-list@broadcom.com Acked-by: Arend van Spriel Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit b8e8ff4906a7c2fd69121bbb3c82f1775d6c6c63 Author: Johannes Berg Date: Fri Aug 23 15:48:48 2013 +0200 mac80211: ignore (E)CSA in probe response frames commit d70b7616d9080ec9f868fbd31db5fd4341435d61 upstream. Seth reports that some APs, notably the Netgear WNDAP360, send invalid ECSA IEs in probe response frames with the operating class and channel number both set to zero, even when no channel switch is being done. As a result, any scan while connected to such an AP results in the connection being dropped. Fix this by ignoring any channel switch announcment in probe response frames entirely, since we're connected to the AP we will be receiving a beacon (and maybe even an action frame) if a channel switch is done, which is sufficient. Reported-by: Seth Forshee Tested-by: Seth Forshee Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit aaa79361dbf324fa25a277061be24e2769b5af89 Author: Jan Kara Date: Sat Aug 17 10:07:17 2013 -0400 ext4: simplify truncation code in ext4_setattr() commit 5208386c501276df18fee464e21d3c58d2d79517 upstream. Merge conditions in ext4_setattr() handling inode size changes, also move ext4_begin_ordered_truncate() call somewhat earlier because it simplifies error recovery in case of failure. Also add error handling in case i_disksize update fails. Signed-off-by: Jan Kara Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 666ee8c487d27e27e3b215cf1b8d79e2b16944c6 Author: Jan Kara Date: Sat Aug 17 10:02:33 2013 -0400 ext4: fix ext4_writepages() in presence of truncate commit 5f1132b2ba8c873f25982cf45917e8455fb6c962 upstream. Inode size can arbitrarily change while writeback is in progress. When ext4_writepages() has prepared a long extent for mapping and truncate then reduces i_size, mpage_map_and_submit_buffers() will always map just one buffer in a page instead of all of them due to lblk < blocks check. So we end up not using all blocks we've allocated (thus leaking them) and also delalloc accounting goes wrong manifesting as a warning like: ext4_da_release_space:1333: ext4_da_release_space: ino 12, to_free 1 with only 0 reserved data blocks Note that the problem can happen only when blocksize < pagesize because otherwise we have only a single buffer in the page. Fix the problem by removing the size check from the mapping loop. We have an extent allocated so we have to use it all before checking for i_size. We also rename add_page_bufs_to_extent() to mpage_process_page_bufs() and make that function submit the page for IO if all buffers (upto EOF) in it are mapped. Reported-by: Dave Jones Reported-by: Zheng Liu Signed-off-by: Jan Kara Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 2a73161d42a658393f0a4dbb2286c125b516670e Author: Jan Kara Date: Sat Aug 17 09:57:56 2013 -0400 ext4: move test whether extent to map can be extended to one place commit 09930042a2e94cf8ee79d22943915612c1e4ba51 upstream. Currently the logic whether the current buffer can be added to an extent of buffers to map is split between mpage_add_bh_to_extent() and add_page_bufs_to_extent(). Move the whole logic to mpage_add_bh_to_extent() which makes things a bit more straightforward and make following i_size fixes easier. Signed-off-by: Jan Kara Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 67f6e3082f2c3b1d94da9adba7a14e5b0b3e2c26 Author: Boris BREZILLON Date: Tue Aug 27 15:19:21 2013 +0200 pinctrl: at91: fix get_pullup/down function return commit 05d3534a321d7fe4524b3b83bb20318282f3ec2c upstream. In PIO_PUSR and PIO_PPDSR register if a given bit is set 1 this means the pullup/down for this pin (pin is represented as a bit position) is disabled. Signed-off-by: Boris BREZILLON Acked-by: Nicolas Ferre Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 071687718992ce8045e70972a17e7ae340743a7c Author: Takashi Iwai Date: Mon Sep 9 10:20:48 2013 +0200 ALSA: hda - Add Toshiba Satellite C870 to MSI blacklist commit 83f72151352791836a1b9c1542614cc9bf71ac61 upstream. Toshiba Satellite C870 shows interrupt problems occasionally when certain mixer controls like "Mic Switch" is toggled. This seems worked around by not using MSI. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=833585 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d06d635202fa635fe24d4a80670251d2a8f9a0ee Author: Anssi Hannula Date: Sun Sep 1 14:36:47 2013 +0300 ALSA: hda - hdmi: Fallback to ALSA allocation when selecting CA commit 18e391862cceaf43ddb8eb5cca05e1a83abdebaa upstream. hdmi_channel_allocation() tries to find a HDMI channel allocation that matches the number channels in the playback stream and contains only speakers that the HDMI sink has reported as available via EDID. If no such allocation is found, 0 (stereo audio) is used. Using CA 0 causes the audio causes the sink to discard everything except the first two channels (front left and front right). However, the sink may be capable of receiving more channels than it has speakers (and then perform downmix or discard the extra channels), in which case it is preferable to use a CA that contains extra channels than to use CA 0 which discards all the non-stereo channels. Additionally, it seems that HBR (HD) passthrough output does not work on Intel HDMI codecs when CA is set to 0 (possibly the codec zeroes channels not present in CA). This happens with all receivers that report a 5.1 speaker mask since a HBR stream is carried on 8 channels to the codec. Add a fallback in the CA selection so that the CA channel count at least matches the stream channel count, even if the stream contains channels not present in the sink speaker descriptor. Thanks to GrimGriefer at OpenELEC forums for discovering that changing the sink speaker mask allowed HBR output. Reported-by: GrimGriefer Reported-by: Ashecrow Reported-by: Frank Zafka Reported-by: Peter Frühberger Signed-off-by: Anssi Hannula Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 78a852327766de4378d55ac241e0d098703df4f8 Author: Takashi Iwai Date: Mon Sep 2 12:33:02 2013 +0200 ALSA: hda - Re-setup HDMI pin and audio infoframe on stream switches commit b054087dbacee30a9dddaef2c9a96312146be04e upstream. When the transcoder:port mapping on Haswell HDMI/DP audio is changed during the stream playback, the sound gets lost. Typically this problem is seen when the user switches the graphics mode from eDP+DP to DP-only configuration, where CRTC 1 is used for DP in the former while CRTC 0 is used for the latter. The graphics controller notifies the change via the normal ELD update procedure, so we get the intrinsic event. For enabling the sound again, the HDMI audio driver needs to reset the pin and set up the audio infoframe again. This patch achieves it by: - keep the current status of channels and info frame setup in per_pin struct, - check the reconnection in the intrinsic event handler, - reset the pin and the re-invoke hdmi_setup_audio_infoframe() accordingly. The hdmi_setup_audio_infoframe() function has been changed, too, so that it can be invoked without passing the substream instance. The patch is mostly based on the work by Mengdong Lin. Cc: Mengdong Lin Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3bf030f755a2be92e6bd8b74743f01a57643db74 Author: Rik van Riel Date: Wed Jul 31 22:14:21 2013 -0400 sched/x86: Optimize switch_mm() for multi-threaded workloads commit 8f898fbbe5ee5e20a77c4074472a1fd088dc47d1 upstream. Dick Fowles, Don Zickus and Joe Mario have been working on improvements to perf, and noticed heavy cache line contention on the mm_cpumask, running linpack on a 60 core / 120 thread system. The cause turned out to be unnecessary atomic accesses to the mm_cpumask. When in lazy TLB mode, the CPU is only removed from the mm_cpumask if there is a TLB flush event. Most of the time, no such TLB flush happens, and the kernel skips the TLB reload. It can also skip the atomic memory set & test. Here is a summary of Joe's test results: * The __schedule function dropped from 24% of all program cycles down to 5.5%. * The cacheline contention/hotness for accesses to that bitmask went from being the 1st/2nd hottest - down to the 84th hottest (0.3% of all shared misses which is now quite cold) * The average load latency for the bit-test-n-set instruction in __schedule dropped from 10k-15k cycles down to an average of 600 cycles. * The linpack program results improved from 133 GFlops to 144 GFlops. Peak GFlops rose from 133 to 153. Reported-by: Don Zickus Reported-by: Joe Mario Tested-by: Joe Mario Signed-off-by: Rik van Riel Reviewed-by: Paul Turner Acked-by: Linus Torvalds Link: http://lkml.kernel.org/r/20130731221421.616d3d20@annuminas.surriel.com [ Made the comments consistent around the modified code. ] Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 04111416b44ffb1140ff7801de5dd31d2b7fe207 Author: Tony Luck Date: Wed Jul 24 13:54:20 2013 -0700 x86/mce: Pay no attention to 'F' bit in MCACOD when parsing 'UC' errors commit 0ca06c0857aee11911f91621db14498496f2c2cd upstream. The 0x1000 bit of the MCACOD field of machine check MCi_STATUS registers is only defined for corrected errors (where it means that hardware may be filtering errors see SDM section 15.9.2.1). For uncorrected errors it may, or may not be set - so we should mask it out when checking for the architecturaly defined recoverable error signatures (see SDM 15.9.3.1 and 15.9.3.2) Acked-by: Naveen N. Rao Signed-off-by: Tony Luck Signed-off-by: Greg Kroah-Hartman commit 669a1604d600fa72355e0404bbdf38789f7fc651 Author: Aravind Gopalakrishnan Date: Fri Aug 2 17:43:03 2013 -0500 x86, amd_nb: Clarify F15h, model 30h GART and L3 support commit 7d64ac6422092adbbdaa279ab32f9d4c90a84558 upstream. F15h, models 0x30 and later don't have a GART. Note that. Also check CPUID leaf 0x80000006 for L3 prescence because there are models which don't sport an L3 cache. Signed-off-by: Aravind Gopalakrishnan [ Boris: rewrite commit message, cleanup comments. ] Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit 76f14df36fee7c53c414e5b7e7d5a3d80af60834 Author: Aravind Gopalakrishnan Date: Fri Aug 2 17:43:02 2013 -0500 pci_ids: Add PCI device ID functions 3 and 4 for newer F15h models. commit 6bdaa63c2957ac04e8d596880f732b79f9c06c3c upstream. Add PCI device IDs for AMD F15h, model 30h. They will be used in amd_nb.c and amd64_edac.c Signed-off-by: Aravind Gopalakrishnan Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit 462a44f4919fc83a948ce5c88c2c1d216d8b5bf4 Author: Al Viro Date: Sun Sep 1 20:35:01 2013 +0100 Introduce [compat_]save_altstack_ex() to unbreak x86 SMAP commit bd1c149aa9915b9abb6d83d0f01dfd2ace0680b5 upstream. For performance reasons, when SMAP is in use, SMAP is left open for an entire put_user_try { ... } put_user_catch(); block, however, calling __put_user() in the middle of that block will close SMAP as the STAC..CLAC constructs intentionally do not nest. Furthermore, using __put_user() rather than put_user_ex() here is bad for performance. Thus, introduce new [compat_]save_altstack_ex() helpers that replace __[compat_]save_altstack() for x86, being currently the only architecture which supports put_user_try { ... } put_user_catch(). Reported-by: H. Peter Anvin Signed-off-by: Al Viro Signed-off-by: H. Peter Anvin Link: http://lkml.kernel.org/n/tip-es5p6y64if71k8p5u08agv9n@git.kernel.org Signed-off-by: Greg Kroah-Hartman commit 727e55b113cd0b4500303dd7c0dbaccd01dad8d3 Author: H. Peter Anvin Date: Fri Aug 30 15:43:03 2013 -0700 x86, smap: Handle csum_partial_copy_*_user() commit 7263dda41b5a28ae6566fd126d9b06ada73dd721 upstream. Add SMAP annotations to csum_partial_copy_to/from_user(). These functions legitimately access user space and thus need to set the AC flag. TODO: add explicit checks that the side with the kernel space pointer really points into kernel space. Signed-off-by: H. Peter Anvin Link: http://lkml.kernel.org/n/tip-2aps0u00eer658fd5xyanan7@git.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1a07de8cbda2a4f612523591232e8bee97d33287 Author: Steffen Trumtrar Date: Mon Sep 9 18:09:12 2013 +0200 ASoC: mc13783: add spi errata fix commit 9f6f0afbb9fdabf6dcac642dfec457f28981e3f8 upstream. The MC13783 Chip Errata, Rev. 4 says, that depending on SPI clock and main audio clock speed, the Audio Codec or Stereo DAC do sometimes not start when programmed to do so. This is due to an internal clock timing issue related to the loading of the SPI bits into the audio block. On an i.MX27 based system, this issue lead to switched audio channels under certain circumstances: RTC + Touch + Audio are used and loaded at startup. The mentioned workaround of writing registers 40 and 41 two times is implemented here. Signed-off-by: Steffen Trumtrar Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1784e4e86b93dc75cda0d28e60030c721d92a926 Author: Mike Dyer Date: Fri Aug 16 18:36:28 2013 +0100 ASoC: wm8960: Fix PLL register writes commit 85fa532b6ef920b32598df86b194571a7059a77c upstream. Bit 9 of PLL2,3 and 4 is reserved as '0'. The 24bit fractional part should be split across each register in 8bit chunks. Signed-off-by: Mike Dyer Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit eb1b33dfbc0d52c691258a10665c26b4bade3925 Author: Tejun Heo Date: Fri Jun 28 10:34:48 2013 -0700 rculist: list_first_or_null_rcu() should use list_entry_rcu() commit c34ac00caefbe49d40058ae7200bd58725cebb45 upstream. list_first_or_null() should test whether the list is empty and return pointer to the first entry if not in a RCU safe manner. It's broken in several ways. * It compares __kernel @__ptr with __rcu @__next triggering the following sparse warning. net/core/dev.c:4331:17: error: incompatible types in comparison expression (different address spaces) * It doesn't perform rcu_dereference*() and computes the entry address using container_of() directly from the __rcu pointer which is inconsitent with other rculist interface. As a result, all three in-kernel users - net/core/dev.c, macvlan, cgroup - are buggy. They dereference the pointer w/o going through read barrier. * While ->next dereference passes through list_next_rcu(), the compiler is still free to fetch ->next more than once and thus nullify the "__ptr != __next" condition check. Fix it by making list_first_or_null_rcu() dereference ->next directly using ACCESS_ONCE() and then use list_entry_rcu() on it like other rculist accessors. v2: Paul pointed out that the compiler may fetch the pointer more than once nullifying the condition check. ACCESS_ONCE() added on ->next dereference. v3: Restored () around macro param which was accidentally removed. Spotted by Paul. Signed-off-by: Tejun Heo Reported-by: Fengguang Wu Cc: Dipankar Sarma Cc: "Paul E. McKenney" Cc: "David S. Miller" Cc: Li Zefan Cc: Patrick McHardy Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett Signed-off-by: Greg Kroah-Hartman commit 4d425b4eb684168380ab3fc959b2c418c0c3d44d Author: Lan Tianyu Date: Wed Jul 3 22:17:54 2013 +0800 usb: don't check pm qos NO_POWER_OFF flag in usb_port_suspend() commit 98a4f1ff7bea8002ab79d6776e30d27932e88244 upstream. The pm qos NO_POWER_OFF flag is checked twice during usb device suspend to see if the usb port power off condition is met. This is redundant and also will prevent the port from being powered off if the NO_POWER_OFF flag is changed to 1 from 0 after the device was already suspended. More detail in the following link. http://marc.info/?l=linux-usb&m=136543949130865&w=2 This patch should be backported to kernels as old as 3.7, that contain the commit f7ac7787ad361e31a7972e2854ed8dc2eedfac3b "usb/acpi: Use ACPI methods to power off ports." Signed-off-by: Lan Tianyu Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit ee04f90d8a21f96edd0c2207e2b1040874307fd6 Author: Alan Stern Date: Tue Jul 30 15:39:02 2013 -0400 USB: handle LPM errors during device suspend correctly commit aa5ceae24bf8dff1d6fe87c6c4b08e69c6d33550 upstream. The hub driver's usb_port_suspend() routine doesn't handle errors related to Link Power Management properly. It always returns failure, it doesn't try to clean up the wakeup setting, (in the case of system sleep) it doesn't try to go ahead with the port suspend regardless, and it doesn't try to apply the new power-off mechanism. This patch fixes these problems. Note: Sarah fixed this patch to apply against 3.11, since the original commit (4fae6f0fa86f92e6bc7429371b1e177ad0aaac66 "USB: handle LPM errors during device suspend correctly") called usb_disable_remote_wakeup, which won't be added until 3.12. This patch should be backported to kernels as old as 3.5, that contain the commit 8306095fd2c1100e8244c09bf560f97aca5a311d "USB: Disable USB 3.0 LPM in critical sections.". There will be merge conflicts, since LTM wasn't added until 3.6. Signed-off-by: Alan Stern Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 6a60f9edfff43606eb9b574082b8d242f9977e8f Author: Hans de Goede Date: Sat Aug 3 16:37:48 2013 +0200 usb: config->desc.bLength may not exceed amount of data returned by the device commit b4f17a488ae2e09bfcf95c0e0b4219c246f1116a upstream. While reading the config parsing code I noticed this check is missing, without this check config->desc.wTotalLength can end up with a value larger then the dev->rawdescriptors length for the config, and when userspace then tries to get the rawdescriptors bad things may happen. Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 6d454f588f7256c13cd477c22dc360aa906682aa Author: Alan Stern Date: Fri Aug 30 10:46:00 2013 -0400 USB: fix build error when CONFIG_PM_SLEEP isn't enabled commit 9d8924297cd9c256c23c02abae40202563452453 upstream. This patch fixes a build error that occurs when CONFIG_PM is enabled and CONFIG_PM_SLEEP isn't: >> drivers/usb/host/ohci-pci.c:294:10: error: 'usb_hcd_pci_pm_ops' undeclared here (not in a function) .pm = &usb_hcd_pci_pm_ops Since the usb_hcd_pci_pm_ops structure is defined and used when CONFIG_PM is enabled, its declaration should not be protected by CONFIG_PM_SLEEP. Signed-off-by: Alan Stern Reported-by: kbuild test robot Signed-off-by: Greg Kroah-Hartman commit 7db4ad4c9faa61112c01c78e2dc978209e10f907 Author: Sarah Sharp Date: Mon Aug 5 18:58:15 2013 -0700 usb: Don't fail port power resume on device disconnect. commit d49dad3e11638f66be4e16573ffaa8c46a09e3b3 upstream. Userspace can tell the kernel to power off any USB port, including ones that are visible and connectible to users. When an attached USB device goes into suspend, the port will be powered off if the pm_qos_no_port_poweroff file for its port is set to 0, the device does not have remote wakeup enabled, and the device is marked as persistent. If the user disconnects the USB device while the port is powered off, the current code does not handle that properly. If you disconnect a device, and then run `lsusb -v -s` for the device, the device disconnect does not get handled by the USB core. The runtime resume of the port fails, because hub_port_debounce_be_connected() returns -ETIMEDOUT. This means the port resume fails and khubd doesn't handle the USB device disconnect. This leaves the device listed in lsusb, and the port's runtime_status will be permanently marked as "error". Fix this by ignoring the return value of hub_port_debounce_be_connected. Users can disconnect USB devices while the ports are powered off, and we must be able to handle that. This patch should be backported to kernels as old as 3.9, that contain the commit ad493e5e580546e6c3024b76a41535476da1546a "usb: add usb port auto power off mechanism" Signed-off-by: Sarah Sharp Cc: Lan Tianyu Cc: Alan Stern Cc: Rafael J. Wysocki Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 4c620592bad05c5bcf8e071cd208353ba4c3db75 Author: Laurent Pinchart Date: Mon Apr 29 22:18:01 2013 +0200 usb: gadget: uvc: Fix error handling in uvc_queue_buffer() commit ebe864a6cb8e087ede047fa1fa6b6d06fcb9a9e4 upstream. The conversion to videobuf2 failed to check the return value of vb2_qbuf(). Fix it. Reported-by: Michael Grzeschik Signed-off-by: Laurent Pinchart Tested-By: Michael Grzeschik Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit be8eba8d6628460ca512ec0c9ac16add66829671 Author: Oliver Neukum Date: Tue Aug 6 14:22:59 2013 +0200 USB: cdc-wdm: fix race between interrupt handler and tasklet commit 6dd433e6cf2475ce8abec1b467720858c24450eb upstream. Both could want to submit the same URB. Some checks of the flag intended to prevent that were missing. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit 7a9355a0296b4bae100b5a16b55a1838bb13982e Author: Daniel Mack Date: Wed Aug 21 11:17:21 2013 +0200 usb: ehci-mxc: check for pdata before dereferencing commit f375fc520d4df0cd9fcb570f33c103c6c0311f9e upstream. Commit 7e8d5cd93fac ("USB: Add EHCI support for MX27 and MX31 based boards") introduced code that could potentially lead to a NULL pointer dereference on driver removal. Fix this by checking for the value of pdata before dereferencing it. Signed-off-by: Daniel Mack Reported-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman commit 023d9816a618f64c6cbfe0ad5b2d2db268f9becc Author: Johan Hovold Date: Mon Aug 19 13:05:45 2013 +0200 USB: mos7720: fix big-endian control requests commit 3b716caf190ccc6f2a09387210e0e6a26c1d81a4 upstream. Fix endianess bugs in parallel-port code which caused corrupt control-requests to be issued on big-endian machines. Reported-by: kbuild test robot Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit e1aa5e2804828c1d8ba117eca4f40131cff3040d Author: Dan Carpenter Date: Fri Aug 16 10:16:59 2013 +0300 USB: mos7720: use GFP_ATOMIC under spinlock commit d0bd9a41186e076ea543c397ad8a67a6cf604b55 upstream. The write_parport_reg_nonblock() function shouldn't sleep because it's called with spinlocks held. Signed-off-by: Dan Carpenter Acked-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit d7f6125f1bd95ccfd7fb66ab1acc56962b07db33 Author: Mika Westerberg Date: Mon Sep 2 13:30:25 2013 +0300 ACPI / LPSS: don't crash if a device has no MMIO resources commit af65cfe9aeae03e0682bebdf4db94582d75562dd upstream. Intel LPSS devices that are enumerated from ACPI have both MMIO and IRQ resources returned in their _CRS method. However, Apple Macbook Air with Haswell has LPSS devices enumerated from PCI bus instead and _CRS method returns only an interrupt number (but the device has _HID set that causes the scan handler to match it). The current ACPI / LPSS code sets pdata->dev_desc only when MMIO resource is found for the device and in case of Macbook Air it is never found. That leads to a NULL pointer dereference in register_device_clock(). Correct this by always setting the pdata->dev_desc. Reported-and-tested-by: Imre Kaloz Signed-off-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 8a9ac8e2bf006e6c3e9eb5787aba262a12bb45e9 Author: Neil Horman Date: Thu Aug 29 16:17:05 2013 -0400 PCI/ACPI: Fix _OSC ordering to allow PCIe hotplug use when available commit 3dc48af310709b85d07c8b0d3aa8f1ead02829d3 upstream. This fixes the problem of acpiphp claiming slots that should be managed by pciehp, which may keep ExpressCard slots from working. The acpiphp driver claims PCIe slots unless the BIOS has granted us control of PCIe native hotplug via _OSC. Prior to v3.10, the acpiphp .add method (add_bridge()) was always called *after* we had requested native hotplug control with _OSC. But after 3b63aaa70e ("PCI: acpiphp: Do not use ACPI PCI subdriver mechanism"), which appeared in v3.10, acpiphp initialization is done during the bus scan via the pcibios_add_bus() hook, and this happens *before* we request native hotplug control. Therefore, acpiphp doesn't know yet whether the BIOS will grant control, and it claims slots that we should be handling with native hotplug. This patch requests native hotplug control earlier, so we know whether the BIOS granted it to us before we initialize acpiphp. To avoid reintroducing the ASPM issue fixed by b8178f130e ('Revert "PCI/ACPI: Request _OSC control before scanning PCI root bus"'), we run _OSC earlier but defer the actual ASPM calls until after the bus scan is complete. Tested successfully by myself. [bhelgaas: changelog, mark for stable] Reference: https://bugzilla.kernel.org/show_bug.cgi?id=60736 Signed-off-by: Neil Horman Signed-off-by: Bjorn Helgaas Acked-by: Yinghai Lu CC: Len Brown CC: "Rafael J. Wysocki" Signed-off-by: Greg Kroah-Hartman commit 2e5ca3973e694ba0bf117323a8501cfc982de165 Author: Dan Carpenter Date: Tue Aug 20 11:57:35 2013 +0300 staging: comedi: dt282x: dt282x_ai_insn_read() always fails commit 2c4283ca7cdcc6605859c836fc536fcd83a4525f upstream. In dt282x_ai_insn_read() we call this macro like: wait_for(!mux_busy(), comedi_error(dev, "timeout\n"); return -ETIME;); Because the if statement doesn't have curly braces it means we always return -ETIME and the function never succeeds. Signed-off-by: Dan Carpenter Acked-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 6bcda1654a21aef4165158ae81e6e4ea3d137c06 Author: Lars-Peter Clausen Date: Wed Aug 28 17:55:07 2013 +0200 regmap: debugfs: Fix continued read from registers file commit 26ee47411ae22caa07d3f3b63ca6d097cba6681b upstream. The regmap_debugfs_get_dump_start() function maps from a file offset to the register that can be found at that position in the file. This is done using a look-up table. Commit d6814a7d ("regmap: debugfs: Suppress cache for partial register files") added a check to bypass the look-up table for partial register files, since the offsets in that table are only correct for the full register file. The check incorrectly uses the file offset instead of the register base address and returns it. This will cause the file offset to be interpreted as a register address which will result in a incorrect output from the registers file for all reads except at position 0. The issue can easily be reproduced by doing small reads the registers file, e.g. `dd if=registers bs=10 count=5`. Signed-off-by: Lars-Peter Clausen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ba2c8d61de2f980eff2f2195cc048139cb012ae0 Author: Alan Stern Date: Mon Aug 26 15:01:40 2013 -0400 USB: OHCI: Allow runtime PM without system sleep commit 69820e01aa756b8d228143d997f71523c1e97984 upstream. Since ohci-hcd supports runtime PM, the .pm field in its pci_driver structure should be protected by CONFIG_PM rather than CONFIG_PM_SLEEP. Without this change, OHCI controllers won't do runtime suspend if system suspend or hibernation isn't enabled. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit ab14cb0cae996a6b1e5bcaa801135e3c37391efe Author: Pavel Shilovsky Date: Thu Sep 5 15:00:07 2013 +0400 CIFS: Fix missing lease break commit 933d4b36576c951d0371bbfed05ec0135d516a6e upstream. If a server sends a lease break to a connection that doesn't have opens with a lease key specified in the server response, we can't find an open file to send an ack. Fix this by walking through all connections we have. Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 189b939d6c6e3b4c430c7d679649e9007e55f500 Author: Pavel Shilovsky Date: Thu Sep 5 15:04:04 2013 +0400 CIFS: Fix a memory leak when a lease break comes commit 1a05096de82f3cd672c76389f63964952678506f upstream. This happens when we receive a lease break from a server, then find an appropriate lease key in opened files and schedule the oplock_break slow work. lw pointer isn't freed in this case. Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 62d627e47b5161b000a03db6599a67359a14cf44 Author: Jeff Layton Date: Thu Sep 5 08:38:10 2013 -0400 cifs: ensure that srv_mutex is held when dealing with ssocket pointer commit 73e216a8a42c0ef3d08071705c946c38fdbe12b0 upstream. Oleksii reported that he had seen an oops similar to this: BUG: unable to handle kernel NULL pointer dereference at 0000000000000088 IP: [] sock_sendmsg+0x93/0xd0 PGD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: ipt_MASQUERADE xt_REDIRECT xt_tcpudp iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables carl9170 ath usb_storage f2fs nfnetlink_log nfnetlink md4 cifs dns_resolver hid_generic usbhid hid af_packet uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev rfcomm btusb bnep bluetooth qmi_wwan qcserial cdc_wdm usb_wwan usbnet usbserial mii snd_hda_codec_hdmi snd_hda_codec_realtek iwldvm mac80211 coretemp intel_powerclamp kvm_intel kvm iwlwifi snd_hda_intel cfg80211 snd_hda_codec xhci_hcd e1000e ehci_pci snd_hwdep sdhci_pci snd_pcm ehci_hcd microcode psmouse sdhci thinkpad_acpi mmc_core i2c_i801 pcspkr usbcore hwmon snd_timer snd_page_alloc snd ptp rfkill pps_core soundcore evdev usb_common vboxnetflt(O) vboxdrv(O)Oops#2 Part8 loop tun binfmt_misc fuse msr acpi_call(O) ipv6 autofs4 CPU: 0 PID: 21612 Comm: kworker/0:1 Tainted: G W O 3.10.1SIGN #28 Hardware name: LENOVO 2306CTO/2306CTO, BIOS G2ET92WW (2.52 ) 02/22/2013 Workqueue: cifsiod cifs_echo_request [cifs] task: ffff8801e1f416f0 ti: ffff880148744000 task.ti: ffff880148744000 RIP: 0010:[] [] sock_sendmsg+0x93/0xd0 RSP: 0000:ffff880148745b00 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff880148745b78 RCX: 0000000000000048 RDX: ffff880148745c90 RSI: ffff880181864a00 RDI: ffff880148745b78 RBP: ffff880148745c48 R08: 0000000000000048 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff880181864a00 R13: ffff880148745c90 R14: 0000000000000048 R15: 0000000000000048 FS: 0000000000000000(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000088 CR3: 000000020c42c000 CR4: 00000000001407b0 Oops#2 Part7 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: ffff880148745b30 ffffffff810c4af9 0000004848745b30 ffff880181864a00 ffffffff81ffbc40 0000000000000000 ffff880148745c90 ffffffff810a5aab ffff880148745bc0 ffffffff81ffbc40 ffff880148745b60 ffffffff815a9fb8 Call Trace: [] ? finish_task_switch+0x49/0xe0 [] ? lock_timer_base.isra.36+0x2b/0x50 [] ? _raw_spin_unlock_irqrestore+0x18/0x40 [] ? try_to_del_timer_sync+0x4f/0x70 [] ? _raw_spin_unlock_bh+0x1f/0x30 [] kernel_sendmsg+0x37/0x50 [] smb_send_kvec+0xd0/0x1d0 [cifs] [] smb_send_rqst+0x83/0x1f0 [cifs] [] cifs_call_async+0xec/0x1b0 [cifs] [] ? free_rsp_buf+0x40/0x40 [cifs] Oops#2 Part6 [] SMB2_echo+0x8e/0xb0 [cifs] [] cifs_echo_request+0x79/0xa0 [cifs] [] process_one_work+0x173/0x4a0 [] worker_thread+0x121/0x3a0 [] ? manage_workers.isra.27+0x2b0/0x2b0 [] kthread+0xc0/0xd0 [] ? kthread_create_on_node+0x120/0x120 [] ret_from_fork+0x7c/0xb0 [] ? kthread_create_on_node+0x120/0x120 Code: 84 24 b8 00 00 00 4c 89 f1 4c 89 ea 4c 89 e6 48 89 df 4c 89 60 18 48 c7 40 28 00 00 00 00 4c 89 68 30 44 89 70 14 49 8b 44 24 28 90 88 00 00 00 3d ef fd ff ff 74 10 48 8d 65 e0 5b 41 5c 41 RIP [] sock_sendmsg+0x93/0xd0 RSP CR2: 0000000000000088 The client was in the middle of trying to send a frame when the server->ssocket pointer got zeroed out. In most places, that we access that pointer, the srv_mutex is held. There's only one spot that I see that the server->ssocket pointer gets set and the srv_mutex isn't held. This patch corrects that. The upstream bug report was here: https://bugzilla.kernel.org/show_bug.cgi?id=60557 Reported-by: Oleksii Shevchuk Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit fe812e6fa9c7c47ee1e40c468fe2b38e07fe7df1 Author: Oleg Nesterov Date: Sun Sep 15 17:50:26 2013 +0200 tty: disassociate_ctty() sends the extra SIGCONT commit 03e1261778cca782d41a3d8e3945ca88cf93e01e upstream. Starting from v3.10 (probably commit f91e2590410b: "tty: Signal foreground group processes in hangup") disassociate_ctty() sends SIGCONT if tty && on_exit. This breaks LSB test-suite, in particular test8 in _exit.c and test40 in sigcon5.c. Put the "!on_exit" check back to restore the old behaviour. Review by Peter Hurley: "Yes, this regression was introduced by me in that commit. The effect of the regression is that ptys will receive a SIGCONT when, in similar circumstances, ttys would not. The fact that two test vectors accidentally tripped over this regression suggests that some other apps may as well. Thanks for catching this" Signed-off-by: Oleg Nesterov Reported-by: Karel Srot Reviewed-by: Peter Hurley Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7af69d3574095ab88d199a248669c9f50bb29528 Author: Felipe Balbi Date: Thu Jun 27 10:00:18 2013 +0300 usb: dwc3: gadget: don't request IRQs in atomic commit b0d7ffd44ba9cd2dfbf299674418193a5f9ed21a upstream. We cannot request an IRQ with spinlocks held as that would trigger a sleeping inside spinlock warning. Reported-by: Stephen Boyd Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 1783b401e4add34045e15ffb2b901c1cbd8d4930 Author: Mathias Nyman Date: Wed Aug 21 18:50:09 2013 +0300 xhci: fix port BESL LPM capability checking commit dcf06a036848b4e8e6c8220f2e00b9adf6f84918 upstream. Wrong capability bit was checked for best effort service latency. bit 20 indicate port is BESL LPM capable (BLC), bit 19 is hardware LPM capable (HLC) This patch should be backported to kernels as old as 3.11, that contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci: add USB2 Link power management BESL support" Signed-off-by: Mathias Nyman Signed-off-by: Sarah Sharp Reported-by: Steve Cotton Signed-off-by: Greg Kroah-Hartman commit 4a73a6d159fb3c6606c2145956cffe6f01e73fb7 Author: Shawn Nematbakhsh Date: Mon Aug 19 10:36:13 2013 -0700 usb: xhci: Disable runtime PM suspend for quirky controllers commit c8476fb855434c733099079063990e5bfa7ecad6 upstream. If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend, a reset will be performed upon runtime resume. Any previously suspended devices attached to the controller will be re-enumerated at this time. This will cause problems, for example, if an open system call on the device triggered the resume (the open call will fail). Note that this change is only relevant when persist_enabled is not set for USB devices. This patch should be backported to kernels as old as 3.0, that contain the commit c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9 "xhci: Add reset on resume quirk for asrock p67 host". Signed-off-by: Shawn Nematbakhsh Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 7641d4cacf73f385905bd8553970d903d04dbec6 Author: Sarah Sharp Date: Thu Aug 8 10:08:34 2013 -0700 xhci-plat: Don't enable legacy PCI interrupts. commit 52fb61250a7a132b0cfb9f4a1060a1f3c49e5a25 upstream. The xHCI platform driver calls into usb_add_hcd to register the irq for its platform device. It does not want the xHCI generic driver to register an interrupt for it at all. The original code did that by setting the XHCI_BROKEN_MSI quirk, which tells the xHCI driver to not enable MSI or MSI-X for a PCI host. Unfortunately, if CONFIG_PCI is enabled, and CONFIG_USB_DW3 is enabled, the xHCI generic driver will attempt to register a legacy PCI interrupt for the xHCI platform device in xhci_try_enable_msi(). This will result in a bogus irq being registered, since the underlying device is a platform_device, not a pci_device, and thus the pci_device->irq pointer will be bogus. Add a new quirk, XHCI_PLAT, so that the xHCI generic driver can distinguish between a PCI device that can't handle MSI or MSI-X, and a platform device that should not have its interrupts touched at all. This quirk may be useful in the future, in case other corner cases like this arise. This patch should be backported to kernels as old as 3.9, that contain the commit 00eed9c814cb8f281be6f0f5d8f45025dc0a97eb "USB: xhci: correctly enable interrupts". Signed-off-by: Sarah Sharp Reported-by: Yu Y Wang Tested-by: Yu Y Wang Reviewed-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit b4bb81d482f30ee9a4c7a01e6cb93a14bdcd7d85 Author: Paul Mackerras Date: Tue Aug 6 14:13:44 2013 +1000 KVM: PPC: Book3S: Fix compile error in XICS emulation commit 7bfa9ad55d691f2b836b576769b11eca2cf50816 upstream. Commit 8e44ddc3f3 ("powerpc/kvm/book3s: Add support for H_IPOLL and H_XIRR_X in XICS emulation") added a call to get_tb() but didn't include the header that defines it, and on some configs this means book3s_xics.c fails to compile: arch/powerpc/kvm/book3s_xics.c: In function ‘kvmppc_xics_hcall’: arch/powerpc/kvm/book3s_xics.c:812:3: error: implicit declaration of function ‘get_tb’ [-Werror=implicit-function-declaration] Signed-off-by: Paul Mackerras Signed-off-by: Alexander Graf Signed-off-by: Greg Kroah-Hartman commit 9e3a6577af8d47d238e64922bd2cf05fa06fd955 Author: Peter Maydell Date: Thu Aug 22 17:47:50 2013 +0100 ARM: PCI: versatile: Fix SMAP register offsets commit 99f2b130370b904ca5300079243fdbcafa2c708b upstream. The SMAP register offsets in the versatile PCI controller code were all off by four. (This didn't have any observable bad effects because on this board PHYS_OFFSET is zero, and (a) writing zero to the flags register at offset 0x10 has no effect and (b) the reset value of the SMAP register is zero anyway, so failing to write SMAP2 didn't matter.) Signed-off-by: Peter Maydell Reviewed-by: Linus Walleij Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit a5805578dad9da3303ea5068c254be12180aded9 Author: Peter Maydell Date: Thu Aug 22 17:47:49 2013 +0100 ARM: PCI: versatile: Fix PCI I/O commit 829f9fedee30cde2ec15e88d57ec11074db791e2 upstream. The versatile PCI controller code was confused between the PCI I/O window (at 0x43000000) and the first PCI memory window (at 0x44000000). Pass the correct base address to pci_remap_io() so that PCI I/O accesses work. Since the first PCI memory window isn't used at all (it's an odd size), rename the associated variables and labels so that it's clear that it isn't related to the I/O window. This has been tested and confirmed to fix PCI I/O accesses both on physical PB926+PCI backplane hardware and on QEMU. Signed-off-by: Peter Maydell Reviewed-by: Linus Walleij Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit e1b2c804f50939abb141970b6804072818cfd898 Author: Peter Maydell Date: Thu Aug 22 17:47:48 2013 +0100 ARM: PCI: versatile: Fix map_irq function to match hardware commit f9b71fef12f0d6ac5c7051cfd87f7700f78c56b6 upstream. The PCI controller code for the Versatile board has never had the correct IRQ mapping for hardware. For many years it had an odd mapping ("all interrupts are int 27") which aligned with the equivalent bug in QEMU. However as of commit 1bc39ac5dab265 the mapping changed and no longer matched either hardware or QEMU, with the result that any PCI card beyond the first in QEMU would not have functioning interrupts; for example a boot with a SCSI controller would time out as follows: ------------ sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 92 sym0: SCSI BUS has been reset. scsi0 : sym-2.2.3 [...] scsi 0:0:0:0: ABORT operation started scsi 0:0:0:0: ABORT operation timed-out. scsi 0:0:0:0: DEVICE RESET operation started scsi 0:0:0:0: DEVICE RESET operation timed-out. scsi 0:0:0:0: BUS RESET operation started scsi 0:0:0:0: BUS RESET operation timed-out. scsi 0:0:0:0: HOST RESET operation started sym0: SCSI BUS has been reset ------------ Fix the mapping so that it matches real hardware (checked against the schematics for PB926 and backplane, and tested against the hardware). This allows PCI cards using interrupts to work on hardware for the first time; this change will also work with QEMU 1.5 or later, where the equivalent bugs in the modelling of the hardware have been fixed. Although QEMU will attempt to autodetect whether the kernel is expecting the long-standing "everything is int 27" mapping or the one hardware has, for certainty we force it into "definitely behave like hardware mode"; this will avoid unexpected surprises later if we implement sparse irqs. This is harmless on hardware. Thanks to Paul Gortmaker for bisecting the problem and finding an initial solution, to Russell King for providing the correct interrupt mapping, and to Guenter Roeck for providing an initial version of this patch and prodding me into relocating the hardware and retesting everything. Signed-off-by: Peter Maydell Reviewed-by: Linus Walleij Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit 2acd475ac3b38805c4efcbd34c3e2f62ec41c4de Author: Will Deacon Date: Tue Aug 20 11:47:42 2013 +0100 arm64: perf: fix ARMv8 EVTYPE_MASK to include NSH bit commit 178cd9ce377232518ec17ff2ecab2e80fa60784c upstream. This is a port of f2fe09b055e2 ("ARM: 7663/1: perf: fix ARMv7 EVTYPE_MASK to include NSH bit") to arm64, which fixes the broken evtype mask to include the NSH bit, allowing profiling at EL2. Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit bb2876c28af9124e585714cdda7469974ebc3e67 Author: Will Deacon Date: Tue Aug 20 11:47:41 2013 +0100 arm64: perf: fix group validation when using enable_on_exec commit 8455e6ec70f33b0e8c3ffd47067e00481f09f454 upstream. This is a port of cb2d8b342aa0 ("ARM: 7698/1: perf: fix group validation when using enable_on_exec") to arm64, which fixes the event validation checking so that events in the OFF state are still considered when enable_on_exec is true. Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 720693367c1b2af0c6c529a5c291087179f477a1 Author: Colin Cross Date: Fri Aug 23 12:45:12 2013 -0700 cpuidle: coupled: fix race condition between pokes and safe state commit 9e19b73c30a5fa42a53583a1f7817dd857126156 upstream. The coupled cpuidle waiting loop clears pending pokes before entering the safe state. If a poke arrives just before the pokes are cleared, but after the while loop condition checks, the poke will be lost and the cpu will stay in the safe state until another interrupt arrives. This may cause the cpu that sent the poke to spin in the ready loop with interrupts off until another cpu receives an interrupt, and if no other cpus have interrupts routed to them it can spin forever. Change the return value of cpuidle_coupled_clear_pokes to return if a poke was cleared, and move the need_resched() checks into the callers. In the waiting loop, if a poke was cleared restart the loop to repeat the while condition checks. Reported-by: Neil Zhang Signed-off-by: Colin Cross Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit faf9fa93122fa18f6040c103207f8d4b6e1b0868 Author: Colin Cross Date: Wed Aug 28 18:41:47 2013 -0700 cpuidle: coupled: abort idle if pokes are pending commit f983827bcb9d2c34c4d8935861a1e9128aec2baf upstream. Joseph Lo reported a lockup on Tegra20 caused by a race condition in coupled cpuidle. When two or more cpus enter idle at the same time, the first cpus to arrive may go to the ready loop without processing pending pokes from the last cpu to arrive. This patch adds a check for pending pokes once all cpus have been synchronized in the ready loop and resets the coupled state and retries if any cpus failed to handle their pending poke. Retrying on all cpus may trigger the same issue again, so this patch also adds a check to ensure that each cpu has received at least one poke between when it enters the waiting loop and when it moves on to the ready loop. Reported-and-tested-by: Joseph Lo Tested-by: Stephen Warren Signed-off-by: Colin Cross Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit a4ec97d085ea2f9197e91b0d57c0daf6454c901e Author: Rob Herring Date: Thu Aug 29 07:43:52 2013 -0500 ARM: xen: only set pm function ptrs for Xen guests commit 9dd4b2944c46e1fdbd0a516c221c8a2670cbf005 upstream. xen_pm_init was unconditionally setting pm_power_off and arm_pm_restart function pointers. This breaks multi-platform kernels. Make this conditional on running as a Xen guest and make it a late_initcall to ensure it is setup after platform code for Dom0. Signed-off-by: Rob Herring Signed-off-by: Stefano Stabellini Signed-off-by: Greg Kroah-Hartman commit 6e3829c790a25e20b61c917903168260072b2177 Author: Roger Pau Monne Date: Wed Jul 31 17:00:42 2013 +0200 xen-gnt: prevent adding duplicate gnt callbacks commit 5f338d9001094a56cf87bd8a280b4e7ff953bb59 upstream. With the current implementation, the callback in the tail of the list can be added twice, because the check done in gnttab_request_free_callback is bogus, callback->next can be NULL if it is the last callback in the list. If we add the same callback twice we end up with an infinite loop, were callback == callback->next. Replace this check with a proper one that iterates over the list to see if the callback has already been added. Signed-off-by: Roger Pau Monné Cc: Konrad Rzeszutek Wilk Cc: David Vrabel Signed-off-by: Konrad Rzeszutek Wilk Acked-by: Matt Wilson Reviewed-by: David Vrabel Signed-off-by: Greg Kroah-Hartman commit c74b90b3bd7d7f0660144bc578b3e0f7211145c7 Author: Vaidyanathan Srinivasan Date: Fri Sep 6 00:25:06 2013 +0530 powerpc: Default arch idle could cede processor on pseries commit 363edbe2614aa90df706c0f19ccfa2a6c06af0be upstream. When adding cpuidle support to pSeries, we introduced two regressions: - The new cpuidle backend driver only works under hypervisors supporting the "SLPLAR" option, which isn't the case of the old POWER4 hypervisor and the HV "light" used on js2x blades - The cpuidle driver registers fairly late, meaning that for a significant portion of the boot process, we end up having all threads spinning. This slows down the boot process and increases the overall resource usage if the hypervisor has shared processors. This fixes both by implementing a "default" idle that will cede to the hypervisor when possible, in a very simple way without all the bells and whisles of cpuidle. Reported-by: Paul Mackerras Signed-off-by: Vaidyanathan Srinivasan Acked-by: Deepthi Dharwar Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit de68bdcc45f558cd4e47a1f376e1bf65377ccb35 Author: Anton Blanchard Date: Wed Aug 7 02:01:19 2013 +1000 powerpc: Handle unaligned ldbrx/stdbrx commit 230aef7a6a23b6166bd4003bfff5af23c9bd381f upstream. Normally when we haven't implemented an alignment handler for a load or store instruction the process will be terminated. The alignment handler uses the DSISR (or a pseudo one) to locate the right handler. Unfortunately ldbrx and stdbrx overlap lfs and stfs so we incorrectly think ldbrx is an lfs and stdbrx is an stfs. This bug is particularly nasty - instead of terminating the process we apply an incorrect fixup and continue on. With more and more overlapping instructions we should stop creating a pseudo DSISR and index using the instruction directly, but for now add a special case to catch ldbrx/stdbrx. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit ae797590117c1631e61af6d9c580c3ca2c397716 Author: Heiko Carstens Date: Mon Sep 2 13:08:25 2013 +0200 s390/bpf,jit: fix address randomization commit 4784955a5270f30c569fa95899979fd1805caf6c upstream. Add misssing braces to hole calculation. This resulted in an addition instead of an substraction. Which in turn means that the jit compiler could try to write out of bounds of the allocated piece of memory. This bug was introduced with aa2d2c73 "s390/bpf,jit: address randomize and write protect jit code". Fixes this one: [ 37.320956] Unable to handle kernel pointer dereference at virtual kernel address 000003ff80231000 [ 37.320984] Oops: 0011 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 37.320993] Modules linked in: dm_multipath scsi_dh eadm_sch dm_mod ctcm fsm autofs4 [ 37.321007] CPU: 28 PID: 6443 Comm: multipathd Not tainted 3.10.9-61.x.20130829-s390xdefault #1 [ 37.321011] task: 0000004ada778000 ti: 0000004ae3304000 task.ti: 0000004ae3304000 [ 37.321014] Krnl PSW : 0704c00180000000 000000000012d1de (bpf_jit_compile+0x198e/0x23d0) [ 37.321022] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3 Krnl GPRS: 000000004350207d 0000004a00000001 0000000000000007 000003ff80231002 [ 37.321029] 0000000000000007 000003ff80230ffe 00000000a7740000 000003ff80230f76 [ 37.321032] 000003ffffffffff 000003ff00000000 000003ff0000007d 000000000071e820 [ 37.321035] 0000004adbe99950 000000000071ea18 0000004af3d9e7c0 0000004ae3307b80 [ 37.321046] Krnl Code: 000000000012d1d0: 41305004 la %r3,4(%r5) 000000000012d1d4: e330f0f80021 clg %r3,248(%r15) #000000000012d1da: a7240009 brc 2,12d1ec >000000000012d1de: 50805000 st %r8,0(%r5) 000000000012d1e2: e330f0f00004 lg %r3,240(%r15) 000000000012d1e8: 41303004 la %r3,4(%r3) 000000000012d1ec: e380f0e00004 lg %r8,224(%r15) 000000000012d1f2: e330f0f00024 stg %r3,240(%r15) [ 37.321074] Call Trace: [ 37.321077] ([<000000000012da78>] bpf_jit_compile+0x2228/0x23d0) [ 37.321083] [<00000000006007c2>] sk_attach_filter+0xfe/0x214 [ 37.321090] [<00000000005d2d92>] sock_setsockopt+0x926/0xbdc [ 37.321097] [<00000000005cbfb6>] SyS_setsockopt+0x8a/0xe8 [ 37.321101] [<00000000005ccaa8>] SyS_socketcall+0x264/0x364 [ 37.321106] [<0000000000713f1c>] sysc_nr_ok+0x22/0x28 [ 37.321113] [<000003fffce10ea8>] 0x3fffce10ea8 [ 37.321118] INFO: lockdep is turned off. [ 37.321121] Last Breaking-Event-Address: [ 37.321124] [<000000000012d192>] bpf_jit_compile+0x1942/0x23d0 [ 37.321132] [ 37.321135] Kernel panic - not syncing: Fatal exception: panic_on_oops Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 0d94095b253fe39fc3ca4bb56637fef8b4f5c8b2 Author: Herbert Xu Date: Sun Sep 8 14:33:50 2013 +1000 crypto: api - Fix race condition in larval lookup commit 77dbd7a95e4a4f15264c333a9e9ab97ee27dc2aa upstream. crypto_larval_lookup should only return a larval if it created one. Any larval created by another entity must be processed through crypto_larval_wait before being returned. Otherwise this will lead to a larval being killed twice, which will most likely lead to a crash. Reported-by: Kees Cook Tested-by: Kees Cook Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 9ed42ce59457ba8df30d345278f3c079ca61b595 Author: Alan Stern Date: Fri Sep 6 11:49:51 2013 -0400 SCSI: sd: Fix potential out-of-bounds access commit 984f1733fcee3fbc78d47e26c5096921c5d9946a upstream. This patch fixes an out-of-bounds error in sd_read_cache_type(), found by Google's AddressSanitizer tool. When the loop ends, we know that "offset" lies beyond the end of the data in the buffer, so no Caching mode page was found. In theory it may be present, but the buffer size is limited to 512 bytes. Signed-off-by: Alan Stern Reported-by: Dmitry Vyukov Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit adb34ef814140689c6996e511cec807145774ff9 Author: Richard Weinberger Date: Mon Aug 19 08:48:12 2013 +0200 UBI: Fix PEB leak in wear_leveling_worker() commit 5ef4414f4bc26a19cfd5cd11aee9697a863e4d51 upstream. get_peb_for_wl() removes the PEB from the free list. If the WL subsystem detects that no wear leveling is needed it cancels the operation and drops the gained PEB. In this case we have to put the PEB back into the free list. This issue was introduced with commit ed4b7021c (UBI: remove PEB from free tree in get_peb_for_wl()). Signed-off-by: Richard Weinberger Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit f81a982fa83db673ab2fa725b1410ee22e8ee4d3 Author: Minchan Kim Date: Mon Aug 12 15:13:56 2013 +0900 zram: don't grab mutex in zram_slot_free_noity commit a0c516cbfc7452c8cbd564525fef66d9f20b46d1 upstream. [1] introduced down_write in zram_slot_free_notify to prevent race between zram_slot_free_notify and zram_bvec_[read|write]. The race could happen if somebody who has right permission to open swap device is reading swap device while it is used by swap in parallel. However, zram_slot_free_notify is called with holding spin_lock of swap layer so we shouldn't avoid holing mutex. Otherwise, lockdep warns it. This patch adds new list to handle free slot and workqueue so zram_slot_free_notify just registers slot index to be freed and registers the request to workqueue. If workqueue is expired, it holds mutex_lock so there is no problem any more. If any I/O is issued, zram handles pending slot-free request caused by zram_slot_free_notify right before handling issued request because workqueue wouldn't be expired yet so zram I/O request handling function can miss it. Lastly, when zram is reset, flush_work could handle all of pending free request so we shouldn't have memory leak. NOTE: If zram_slot_free_notify's kmalloc with GFP_ATOMIC would be failed, the slot will be freed when next write I/O write the slot. [1] [57ab0485, zram: use zram->lock to protect zram_free_page() in swap free notify path] * from v2 * refactoring * from v1 * totally redesign Cc: Nitin Gupta Cc: Jiang Liu Signed-off-by: Minchan Kim Signed-off-by: Greg Kroah-Hartman commit b45ecf2f8df7899154c7d03865d064a38f87a6d0 Author: Minchan Kim Date: Mon Aug 12 15:13:55 2013 +0900 zram: fix invalid memory access commit 2b86ab9cc29fcd435cde9378c3b9ffe8b5c76128 upstream. [1] tried to fix invalid memory access on zram->disk but it didn't fix properly because get_disk failed during module exit path. Actually, we don't need to reset zram->disk's capacity to zero in module exit path so that this patch introduces new argument "reset_capacity" on zram_reset_divice and it only reset it when reset_store is called. [1] 6030ea9b, zram: avoid invalid memory access in zram_exit() Cc: Nitin Gupta Cc: Jiang Liu Signed-off-by: Minchan Kim Signed-off-by: Greg Kroah-Hartman commit cbeb658e686182d20238d714a2ff6d372bdd4582 Author: Maxime Bizon Date: Thu Aug 29 20:28:13 2013 +0200 firmware loader: fix pending_fw_head list corruption commit 1eeeef153c02f5856ec109fa532eb5f31c39f85c upstream. Got the following oops just before reboot: Unable to handle kernel NULL pointer dereference at virtual address 00000000 [<8028d300>] (__list_del_entry+0x44/0xac) [<802e3320>] (__fw_load_abort.part.13+0x1c/0x50) [<802e337c>] (fw_shutdown_notify+0x28/0x50) [<80034f80>] (notifier_call_chain.isra.1+0x5c/0x9c) [<800350ec>] (__blocking_notifier_call_chain+0x44/0x58) [<80035114>] (blocking_notifier_call_chain+0x14/0x18) [<80035d64>] (kernel_restart_prepare+0x14/0x38) [<80035d94>] (kernel_restart+0xc/0x50) The following race condition triggers here: _request_firmware_load() device_create_file(...) kobject_uevent(...) (schedule) (resume) firmware_loading_store(1) firmware_loading_store(0) list_del_init(&buf->pending_list) (schedule) (resume) list_add(&buf->pending_list, &pending_fw_head); wait_for_completion(&buf->completion); causing an oops later when walking pending_list after the firmware has been released. The proposed fix is to move the list_add() before sysfs attribute creation. Signed-off-by: Maxime Bizon Acked-by: Ming Lei Signed-off-by: Greg Kroah-Hartman commit cc0ffca95bf3e8cd393327c444c5bf4493deda90 Author: Imre Deak Date: Tue Jul 30 13:36:32 2013 +0300 drm/i915: make user mode sync polarity setting explicit commit 2960bc9cceecb5d556ce1c07656a6609e2f7e8b0 upstream. Userspace can pass a mode with an unspecified vsync/hsync polarity setting. All encoders in the Intel driver take this to mean a negative polarity setting. The HW readout/state checker code on the other hand needs these flags to be explicitly set, otherwise the state checker will WARN about the mismatch. Get rid of the WARN by making the polarity setting explicit in the adjusted mode flags based on the requested mode flags. This will keep the existing behavior otherwise. Note that we could guess from the other timing parameters whether the user wanted a VESA or other standard mode and set the polarity accordingly. This is what the NV driver does (drivers/gpu/drm/nouveau/dispnv04/crtc.c), but I think that's not very exact and would change the existing behavior of the Intel driver. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65442 Signed-off-by: Imre Deak Tested-by: cancan,feng Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 97bd47aaaeff070e7907a6a0be78329e8c783feb Author: Greg Kroah-Hartman Date: Tue Sep 3 15:00:11 2013 -0700 SCSI: Allow MPT Fusion SAS 3.0 driver to be built into the kernel commit 9807b4d94911be4e4efb9a08481b24292a9edf8a upstream. Right now the Makefile for the mpt3sas driver does not even allow the driver to be built into the kernel. So fix that up, as there doesn't seem to be any obvious reason why this shouldn't be done. Signed-off-by: Greg Kroah-Hartman Acked-by: Sreekanth Reddy Signed-off-by: James Bottomley commit c1de625eadb792468774b6b46d71b1cb246cb868 Author: Guenter Roeck Date: Tue Aug 27 21:06:37 2013 -0700 xtensa: Fix broken allmodconfig build commit 8872366df396444d7655287c79ed182d8f47cba6 upstream. xtansa allmodbuild fails with: arch/xtensa/kernel/xtensa_ksyms.c:129:1: error: '_mcount' undeclared here (not in a function) make[2]: *** [arch/xtensa/kernel/xtensa_ksyms.o] Error 1 make[1]: *** [arch/xtensa/kernel] Error 2 The breakage is due to commit 478ba61af (xtensa: add static function tracer support) which exports _mcount without declaring it. Cc: Max Filippov Signed-off-by: Guenter Roeck Signed-off-by: Chris Zankel Signed-off-by: Greg Kroah-Hartman commit f33e422584bed14b9f194f6a7bf61db68dd95e12 Author: Manfred Spraul Date: Tue Sep 3 16:00:08 2013 +0200 ipc/msg.c: Fix lost wakeup in msgsnd(). commit bebcb928c820d0ee83aca4b192adc195e43e66a2 upstream. The check if the queue is full and adding current to the wait queue of pending msgsnd() operations (ss_add()) must be atomic. Otherwise: - the thread that performs msgsnd() finds a full queue and decides to sleep. - the thread that performs msgrcv() first reads all messages from the queue and then sleeps, because the queue is empty. - the msgrcv() calls do not perform any wakeups, because the msgsnd() task has not yet called ss_add(). - then the msgsnd()-thread first calls ss_add() and then sleeps. Net result: msgsnd() and msgrcv() both sleep forever. Observed with msgctl08 from ltp with a preemptible kernel. Fix: Call ipc_lock_object() before performing the check. The patch also moves security_msg_queue_msgsnd() under ipc_lock_object: - msgctl(IPC_SET) explicitely mentions that it tries to expunge any pending operations that are not allowed anymore with the new permissions. If security_msg_queue_msgsnd() is called without locks, then there might be races. - it makes the patch much simpler. Reported-and-tested-by: Vineet Gupta Acked-by: Rik van Riel Signed-off-by: Manfred Spraul Signed-off-by: Linus Torvalds Cc: Sedat Dilek Signed-off-by: Greg Kroah-Hartman commit 4e96b8f08b2b67effc19b28bad73deec6c62248a Author: Noam Camus Date: Thu Sep 12 13:07:39 2013 +0530 ARC: SMP failed to boot due to missing IVT setup commit c3567f8a359b7917dcffa442301f88ed0a75211f upstream. Commit 05b016ecf5e7a "ARC: Setup Vector Table Base in early boot" moved the Interrupt vector Table setup out of arc_init_IRQ() which is called for all CPUs, to entry point of boot cpu only, breaking booting of others. Fix by adding the same to entry point of non-boot CPUs too. read_arc_build_cfg_regs() printing IVT Base Register didn't help the casue since it prints a synthetic value if zero which is totally bogus, so fix that to print the exact Register. [vgupta: Remove the now stale comment from header of arc_init_IRQ and also added the commentary for halt-on-reset] Cc: Gilad Ben-Yossef Signed-off-by: Noam Camus Signed-off-by: Vineet Gupta Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman