commit c13c28207bf7d812d1b310a76013579cdb461b3e Author: Greg Kroah-Hartman Date: Wed Sep 17 10:22:16 2014 -0700 Linux 3.16.3 commit a4b9e45fed010808c2b0c38d243a7a2b4adb512b Author: David Howells Date: Wed Sep 10 22:22:00 2014 +0100 KEYS: Fix termination condition in assoc array garbage collection commit 95389b08d93d5c06ec63ab49bd732b0069b7c35e upstream. This fixes CVE-2014-3631. It is possible for an associative array to end up with a shortcut node at the root of the tree if there are more than fan-out leaves in the tree, but they all crowd into the same slot in the lowest level (ie. they all have the same first nibble of their index keys). When assoc_array_gc() returns back up the tree after scanning some leaves, it can fall off of the root and crash because it assumes that the back pointer from a shortcut (after label ascend_old_tree) must point to a normal node - which isn't true of a shortcut node at the root. Should we find we're ascending rootwards over a shortcut, we should check to see if the backpointer is zero - and if it is, we have completed the scan. This particular bug cannot occur if the root node is not a shortcut - ie. if you have fewer than 17 keys in a keyring or if you have at least two keys that sit into separate slots (eg. a keyring and a non keyring). This can be reproduced by: ring=`keyctl newring bar @s` for ((i=1; i<=18; i++)); do last_key=`keyctl newring foo$i $ring`; done keyctl timeout $last_key 2 Doing this: echo 3 >/proc/sys/kernel/keys/gc_delay first will speed things up. If we do fall off of the top of the tree, we get the following oops: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 IP: [] assoc_array_gc+0x2f7/0x540 PGD dae15067 PUD cfc24067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: xt_nat xt_mark nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_ni CPU: 0 PID: 26011 Comm: kworker/0:1 Not tainted 3.14.9-200.fc20.x86_64 #1 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: events key_garbage_collector task: ffff8800918bd580 ti: ffff8800aac14000 task.ti: ffff8800aac14000 RIP: 0010:[] [] assoc_array_gc+0x2f7/0x540 RSP: 0018:ffff8800aac15d40 EFLAGS: 00010206 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff8800aaecacc0 RDX: ffff8800daecf440 RSI: 0000000000000001 RDI: ffff8800aadc2bc0 RBP: ffff8800aac15da8 R08: 0000000000000001 R09: 0000000000000003 R10: ffffffff8136ccc7 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000070 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff88011fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000018 CR3: 00000000db10d000 CR4: 00000000000006f0 Stack: ffff8800aac15d50 0000000000000011 ffff8800aac15db8 ffffffff812e2a70 ffff880091a00600 0000000000000000 ffff8800aadc2bc3 00000000cd42c987 ffff88003702df20 ffff88003702dfa0 0000000053b65c09 ffff8800aac15fd8 Call Trace: [] ? keyring_detect_cycle_iterator+0x30/0x30 [] keyring_gc+0x75/0x80 [] key_garbage_collector+0x154/0x3c0 [] process_one_work+0x176/0x430 [] worker_thread+0x11b/0x3a0 [] ? rescuer_thread+0x3b0/0x3b0 [] kthread+0xd8/0xf0 [] ? insert_kthread_work+0x40/0x40 [] ret_from_fork+0x7c/0xb0 [] ? insert_kthread_work+0x40/0x40 Code: 08 4c 8b 22 0f 84 bf 00 00 00 41 83 c7 01 49 83 e4 fc 41 83 ff 0f 4c 89 65 c0 0f 8f 5a fe ff ff 48 8b 45 c0 4d 63 cf 49 83 c1 02 <4e> 8b 34 c8 4d 85 f6 0f 84 be 00 00 00 41 f6 c6 01 0f 84 92 RIP [] assoc_array_gc+0x2f7/0x540 RSP CR2: 0000000000000018 ---[ end trace 1129028a088c0cbd ]--- Signed-off-by: David Howells Acked-by: Don Zickus Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit b3c24771aaaa566ba977d67ea22d9758b31efe13 Author: David Howells Date: Tue Sep 2 13:52:20 2014 +0100 KEYS: Fix use-after-free in assoc_array_gc() commit 27419604f51a97d497853f14142c1059d46eb597 upstream. An edit script should be considered inaccessible by a function once it has called assoc_array_apply_edit() or assoc_array_cancel_edit(). However, assoc_array_gc() is accessing the edit script just after the gc_complete: label. Reported-by: Andreea-Cristina Bernat Signed-off-by: David Howells Reviewed-by: Andreea-Cristina Bernat cc: shemming@brocade.com cc: paulmck@linux.vnet.ibm.com Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit c857808daf9f819010731b0e5669d315a623d41f Author: Pavel Shilovsky Date: Mon Aug 18 20:49:57 2014 +0400 CIFS: Fix SMB2 readdir error handling commit 52755808d4525f4d5b86d112d36ffc7a46f3fb48 upstream. SMB2 servers indicates the end of a directory search with STATUS_NO_MORE_FILE error code that is not processed now. This causes generic/257 xfstest to fail. Fix this by triggering the end of search by this error code in SMB2_query_directory. Also when negotiating CIFS protocol we tell the server to close the search automatically at the end and there is no need to do it itself. In the case of SMB2 protocol, we need to close it explicitly - separate close directory checks for different protocols. Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit b5cf3193759f7cd1cfbeef11f5cf067bbce22e55 Author: Linus Torvalds Date: Sat Sep 13 11:30:10 2014 -0700 vfs: fix bad hashing of dentries commit 99d263d4c5b2f541dfacb5391e22e8c91ea982a6 upstream. Josef Bacik found a performance regression between 3.2 and 3.10 and narrowed it down to commit bfcfaa77bdf0 ("vfs: use 'unsigned long' accesses for dcache name comparison and hashing"). He reports: "The test case is essentially for (i = 0; i < 1000000; i++) mkdir("a$i"); On xfs on a fio card this goes at about 20k dir/sec with 3.2, and 12k dir/sec with 3.10. This is because we spend waaaaay more time in __d_lookup on 3.10 than in 3.2. The new hashing function for strings is suboptimal for < sizeof(unsigned long) string names (and hell even > sizeof(unsigned long) string names that I've tested). I broke out the old hashing function and the new one into a userspace helper to get real numbers and this is what I'm getting: Old hash table had 1000000 entries, 0 dupes, 0 max dupes New hash table had 12628 entries, 987372 dupes, 900 max dupes We had 11400 buckets with a p50 of 30 dupes, p90 of 240 dupes, p99 of 567 dupes for the new hash My test does the hash, and then does the d_hash into a integer pointer array the same size as the dentry hash table on my system, and then just increments the value at the address we got to see how many entries we overlap with. As you can see the old hash function ended up with all 1 million entries in their own bucket, whereas the new one they are only distributed among ~12.5k buckets, which is why we're using so much more CPU in __d_lookup". The reason for this hash regression is two-fold: - On 64-bit architectures the down-mixing of the original 64-bit word-at-a-time hash into the final 32-bit hash value is very simplistic and suboptimal, and just adds the two 32-bit parts together. In particular, because there is no bit shuffling and the mixing boundary is also a byte boundary, similar character patterns in the low and high word easily end up just canceling each other out. - the old byte-at-a-time hash mixed each byte into the final hash as it hashed the path component name, resulting in the low bits of the hash generally being a good source of hash data. That is not true for the word-at-a-time case, and the hash data is distributed among all the bits. The fix is the same in both cases: do a better job of mixing the bits up and using as much of the hash data as possible. We already have the "hash_32|64()" functions to do that. Reported-by: Josef Bacik Cc: Al Viro Cc: Christoph Hellwig Cc: Chris Mason Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b80e628657c501dade91cebbf0ce0466702e3b70 Author: Mario Kleiner Date: Wed Aug 6 06:09:44 2014 +0200 drm/nouveau: Bump version from 1.1.1 to 1.1.2 commit 7820e5eef0faa4a5e10834296680827f7ce78a89 upstream. Linux 3.16 fixed multiple bugs in kms pageflip completion events and timestamping, which were originally introduced in Linux 3.13. These fixes have been backported to all stable kernels since 3.13. However, the userspace nouveau-ddx needs to be aware if it is running on a kernel on which these bugs are fixed, or not. Bump the patchlevel of the drm driver version to signal this, so backporting this patch to stable 3.13+ kernels will give the ddx the required info. Signed-off-by: Mario Kleiner Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit a82fd71283780f4026125f647f1b1d39ebfcb7c2 Author: Mario Kleiner Date: Tue Jul 29 02:36:44 2014 +0200 drm/nouveau: Dis/Enable vblank irqs during suspend/resume. commit 9cba5efab5a8145ae6c52ea273553f069c294482 upstream. Vblank irqs don't get disabled during suspend or driver unload, which causes irq delivery after "suspend" or driver unload, at least until the gpu is powered off. This could race with drm_vblank_cleanup() in the case of nouveau and cause a use-after-free bug if the driver is unloaded. More annoyingly during everyday use, at least on nv50 display engine (likely also others), vblank irqs are off after a resume from suspend, but the drm doesn't know this, so all vblank related functionality is dead after a resume. E.g., all windowed OpenGL clients will hang at swapbuffers time, as well as many fullscreen clients in many cases. This makes suspend/resume useless if one wants to use any OpenGL apps after the resume. In Linux 3.16, drm_vblank_on() was added, complementing the older drm_vblank_off() to solve these problems elegantly, so use those calls in nouveaus suspend/resume code. For kernels 3.8 - 3.15, we need to cherry-pick the drm_vblank_on() patch to support this patch. Signed-off-by: Mario Kleiner Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 1b29db8c29dea208525a527a07ccc0ee23b65059 Author: Bart Van Assche Date: Wed Jul 9 15:57:26 2014 +0200 IB/srp: Fix deadlock between host removal and multipathd commit bcc05910359183b431da92713e98eed478edf83a upstream. If scsi_remove_host() is invoked after a SCSI device has been blocked, if the fast_io_fail_tmo or dev_loss_tmo work gets scheduled on the workqueue executing srp_remove_work() and if an I/O request is scheduled after the SCSI device had been blocked by e.g. multipathd then the following deadlock can occur: kworker/6:1 D ffff880831f3c460 0 195 2 0x00000000 Call Trace: [] schedule+0x29/0x70 [] schedule_timeout+0x10f/0x2a0 [] msleep+0x2f/0x40 [] __blk_drain_queue+0x4e/0x180 [] blk_cleanup_queue+0x225/0x230 [] __scsi_remove_device+0x62/0xe0 [scsi_mod] [] scsi_forget_host+0x6f/0x80 [scsi_mod] [] scsi_remove_host+0x7a/0x130 [scsi_mod] [] srp_remove_work+0x95/0x180 [ib_srp] [] process_one_work+0x1ea/0x6c0 [] worker_thread+0x11b/0x3a0 [] kthread+0xed/0x110 [] ret_from_fork+0x7c/0xb0 multipathd D ffff880096acc460 0 5340 1 0x00000000 Call Trace: [] schedule+0x29/0x70 [] schedule_timeout+0x10f/0x2a0 [] io_schedule_timeout+0x9b/0xf0 [] wait_for_completion_io_timeout+0xdc/0x110 [] blk_execute_rq+0x9b/0x100 [] sg_io+0x1a5/0x450 [] scsi_cmd_ioctl+0x2a1/0x430 [] scsi_cmd_blk_ioctl+0x42/0x50 [] sd_ioctl+0xbe/0x140 [sd_mod] [] blkdev_ioctl+0x234/0x840 [] block_ioctl+0x41/0x50 [] do_vfs_ioctl+0x300/0x520 [] SyS_ioctl+0x41/0x80 [] tracesys+0xd0/0xd5 Fix this by scheduling removal work on another workqueue than the transport layer timers. Signed-off-by: Bart Van Assche Reviewed-by: Sagi Grimberg Reviewed-by: David Dillow Cc: Sebastian Parschauer Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 05a095332f281c23f102b567c9c8483565a0e7b0 Author: Jeff Moyer Date: Fri Aug 8 11:03:41 2014 -0400 dm table: propagate QUEUE_FLAG_NO_SG_MERGE commit 200612ec33e555a356eebc717630b866ae2b694f upstream. Commit 05f1dd5 ("block: add queue flag for disabling SG merging") introduced a new queue flag: QUEUE_FLAG_NO_SG_MERGE. This gets set by default in blk_mq_init_queue for mq-enabled devices. The effect of the flag is to bypass the SG segment merging. Instead, the bio->bi_vcnt is used as the number of hardware segments. With a device mapper target on top of a device with QUEUE_FLAG_NO_SG_MERGE set, we can end up sending down more segments than a driver is prepared to handle. I ran into this when backporting the virtio_blk mq support. It triggerred this BUG_ON, in virtio_queue_rq: BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); The queue's max is set here: blk_queue_max_segments(q, vblk->sg_elems-2); Basically, what happens is that a bio is built up for the dm device (which does not have the QUEUE_FLAG_NO_SG_MERGE flag set) using bio_add_page. That path will call into __blk_recalc_rq_segments, so what you end up with is bi_phys_segments being much smaller than bi_vcnt (and bi_vcnt grows beyond the maximum sg elements). Then, when the bio is submitted, it gets cloned. When the cloned bio is submitted, it will end up in blk_recount_segments, here: if (test_bit(QUEUE_FLAG_NO_SG_MERGE, &q->queue_flags)) bio->bi_phys_segments = bio->bi_vcnt; and now we've set bio->bi_phys_segments to a number that is beyond what was registered as queue_max_segments by the driver. The right way to fix this is to propagate the queue flag up the stack. The rules for propagating the flag are simple: - if the flag is set for any underlying device, it must be set for the upper device - consequently, if the flag is not set for any underlying device, it should not be set for the upper device. Signed-off-by: Jeff Moyer Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 20c0fb35f167f18454c522a3c877da0247a3b0e0 Author: Roger Quadros Date: Mon Aug 25 16:15:33 2014 -0700 mtd: nand: omap: Fix 1-bit Hamming code scheme, omap_calculate_ecc() commit 40ddbf5069bd4e11447c0088fc75318e0aac53f0 upstream. commit 65b97cf6b8de introduced in v3.7 caused a regression by using a reversed CS_MASK thus causing omap_calculate_ecc to always fail. As the NAND base driver never checks for .calculate()'s return value, the zeroed ECC values are used as is without showing any error to the user. However, this won't work and the NAND device won't be guarded by any error code. Fix the issue by using the correct mask. Code was tested on omap3beagle using the following procedure - flash the primary bootloader (MLO) from the kernel to the first NAND partition using nandwrite. - boot the board from NAND. This utilizes OMAP ROM loader that relies on 1-bit Hamming code ECC. Fixes: 65b97cf6b8de (mtd: nand: omap2: handle nand on gpmc) Signed-off-by: Roger Quadros Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 711f8bcf1dd5608d2a841f7e1bb471090e53514f Author: Kevin Hao Date: Thu Jul 3 10:35:26 2014 +0800 mtd/ftl: fix the double free of the buffers allocated in build_maps() commit a152056c912db82860a8b4c23d0bd3a5aa89e363 upstream. I got the following panic on my fsl p5020ds board. Unable to handle kernel paging request for data at address 0x7375627379737465 Faulting instruction address: 0xc000000000100778 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=24 CoreNet Generic Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-next-20140613 #145 task: c0000000fe080000 ti: c0000000fe088000 task.ti: c0000000fe088000 NIP: c000000000100778 LR: c00000000010073c CTR: 0000000000000000 REGS: c0000000fe08aa00 TRAP: 0300 Not tainted (3.15.0-next-20140613) MSR: 0000000080029000 CR: 24ad2e24 XER: 00000000 DEAR: 7375627379737465 ESR: 0000000000000000 SOFTE: 1 GPR00: c0000000000c99b0 c0000000fe08ac80 c0000000009598e0 c0000000fe001d80 GPR04: 00000000000000d0 0000000000000913 c000000007902b20 0000000000000000 GPR08: c0000000feaae888 0000000000000000 0000000007091000 0000000000200200 GPR12: 0000000028ad2e28 c00000000fff4000 c0000000007abe08 0000000000000000 GPR16: c0000000007ab160 c0000000007aaf98 c00000000060ba68 c0000000007abda8 GPR20: c0000000007abde8 c0000000feaea6f8 c0000000feaea708 c0000000007abd10 GPR24: c000000000989370 c0000000008c6228 00000000000041ed c0000000fe00a400 GPR28: c00000000017c1cc 00000000000000d0 7375627379737465 c0000000fe001d80 NIP [c000000000100778] .__kmalloc_track_caller+0x70/0x168 LR [c00000000010073c] .__kmalloc_track_caller+0x34/0x168 Call Trace: [c0000000fe08ac80] [c00000000087e6b8] uevent_sock_list+0x0/0x10 (unreliable) [c0000000fe08ad20] [c0000000000c99b0] .kstrdup+0x44/0x90 [c0000000fe08adc0] [c00000000017c1cc] .__kernfs_new_node+0x4c/0x130 [c0000000fe08ae70] [c00000000017d7e4] .kernfs_new_node+0x2c/0x64 [c0000000fe08aef0] [c00000000017db00] .kernfs_create_dir_ns+0x34/0xc8 [c0000000fe08af80] [c00000000018067c] .sysfs_create_dir_ns+0x58/0xcc [c0000000fe08b010] [c0000000002c711c] .kobject_add_internal+0xc8/0x384 [c0000000fe08b0b0] [c0000000002c7644] .kobject_add+0x64/0xc8 [c0000000fe08b140] [c000000000355ebc] .device_add+0x11c/0x654 [c0000000fe08b200] [c0000000002b5988] .add_disk+0x20c/0x4b4 [c0000000fe08b2c0] [c0000000003a21d4] .add_mtd_blktrans_dev+0x340/0x514 [c0000000fe08b350] [c0000000003a3410] .mtdblock_add_mtd+0x74/0xb4 [c0000000fe08b3e0] [c0000000003a32cc] .blktrans_notify_add+0x64/0x94 [c0000000fe08b470] [c00000000039b5b4] .add_mtd_device+0x1d4/0x368 [c0000000fe08b520] [c00000000039b830] .mtd_device_parse_register+0xe8/0x104 [c0000000fe08b5c0] [c0000000003b8408] .of_flash_probe+0x72c/0x734 [c0000000fe08b750] [c00000000035ba40] .platform_drv_probe+0x38/0x84 [c0000000fe08b7d0] [c0000000003599a4] .really_probe+0xa4/0x29c [c0000000fe08b870] [c000000000359d3c] .__driver_attach+0x100/0x104 [c0000000fe08b900] [c00000000035746c] .bus_for_each_dev+0x84/0xe4 [c0000000fe08b9a0] [c0000000003593c0] .driver_attach+0x24/0x38 [c0000000fe08ba10] [c000000000358f24] .bus_add_driver+0x1c8/0x2ac [c0000000fe08bab0] [c00000000035a3a4] .driver_register+0x8c/0x158 [c0000000fe08bb30] [c00000000035b9f4] .__platform_driver_register+0x6c/0x80 [c0000000fe08bba0] [c00000000084e080] .of_flash_driver_init+0x1c/0x30 [c0000000fe08bc10] [c000000000001864] .do_one_initcall+0xbc/0x238 [c0000000fe08bd00] [c00000000082cdc0] .kernel_init_freeable+0x188/0x268 [c0000000fe08bdb0] [c0000000000020a0] .kernel_init+0x1c/0xf7c [c0000000fe08be30] [c000000000000884] .ret_from_kernel_thread+0x58/0xd4 Instruction dump: 41bd0010 480000c8 4bf04eb5 60000000 e94d0028 e93f0000 7cc95214 e8a60008 7fc9502a 2fbe0000 419e00c8 e93f0022 <7f7e482a> 39200000 88ed06b2 992d06b2 ---[ end trace b4c9a94804a42d40 ]--- It seems that the corrupted partition header on my mtd device triggers a bug in the ftl. In function build_maps() it will allocate the buffers needed by the mtd partition, but if something goes wrong such as kmalloc failure, mtd read error or invalid partition header parameter, it will free all allocated buffers and then return non-zero. In my case, it seems that partition header parameter 'NumTransferUnits' is invalid. And the ftl_freepart() is a function which free all the partition buffers allocated by build_maps(). Given the build_maps() is a self cleaning function, so there is no need to invoke this function even if build_maps() return with error. Otherwise it will causes the buffers to be freed twice and then weird things would happen. Signed-off-by: Kevin Hao Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit f586b7680fe5aab76f5f329e50d705fc9ab5d78e Author: Pavel Shilovsky Date: Tue Aug 26 19:04:44 2014 +0400 CIFS: Fix wrong restart readdir for SMB1 commit f736906a7669a77cf8cabdcbcf1dc8cb694e12ef upstream. The existing code calls server->ops->close() that is not right. This causes XFS test generic/310 to fail. Fix this by using server->ops->closedir() function. Signed-off-by: Dan Carpenter Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit be462337ae21b729730565921d13738699e32604 Author: Pavel Shilovsky Date: Fri Aug 22 13:32:11 2014 +0400 CIFS: Fix wrong filename length for SMB2 commit 1bbe4997b13de903c421c1cc78440e544b5f9064 upstream. The existing code uses the old MAX_NAME constant. This causes XFS test generic/013 to fail. Fix it by replacing MAX_NAME with PATH_MAX that SMB1 uses. Also remove an unused MAX_NAME constant definition. Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit cb22458c2d73da305ab4374cc83ae6edec2f259c Author: Pavel Shilovsky Date: Fri Aug 22 13:32:09 2014 +0400 CIFS: Fix directory rename error commit a07d322059db66b84c9eb4f98959df468e88b34b upstream. CIFS servers process nlink counts differently for files and directories. In cifs_rename() if we the request fails on the existing target, we try to remove it through cifs_unlink() but this is not what we want to do for directories. As the result the following sequence of commands mkdir {1,2}; mv -T 1 2; rmdir {1,2}; mkdir {1,2}; echo foo > 2/bar and XFS test generic/023 fail with -ENOENT error. That's why the second mkdir reuses the existing inode (target inode of the mv -T command) with S_DEAD flag. Fix this by checking whether the target is directory or not and calling cifs_rmdir() rather than cifs_unlink() for directories. Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 7454dc809fceb8be5844c0a4d783a832ddb7c083 Author: Pavel Shilovsky Date: Mon Aug 18 20:49:58 2014 +0400 CIFS: Fix wrong directory attributes after rename commit b46799a8f28c43c5264ac8d8ffa28b311b557e03 upstream. When we requests rename we also need to update attributes of both source and target parent directories. Not doing it causes generic/309 xfstest to fail on SMB2 mounts. Fix this by marking these directories for force revalidating. Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit fa7007a59216399b8873f53b5b20e83b698def70 Author: Steve French Date: Sun Aug 17 00:22:24 2014 -0500 CIFS: Possible null ptr deref in SMB2_tcon commit 18f39e7be0121317550d03e267e3ebd4dbfbb3ce upstream. As Raphael Geissert pointed out, tcon_error_exit can dereference tcon and there is one path in which tcon can be null. Signed-off-by: Steve French Reported-by: Raphael Geissert Signed-off-by: Greg Kroah-Hartman commit 09f07a1461fcd0f5e4c613c45b37daeb8a030f6c Author: Pavel Shilovsky Date: Fri Jun 27 10:33:11 2014 +0400 CIFS: Fix async reading on reconnects commit 038bc961c31b070269ecd07349a7ee2e839d4fec upstream. If we get into read_into_pages() from cifs_readv_receive() and then loose a network, we issue cifs_reconnect that moves all mids to a private list and issue their callbacks. The callback of the async read request sets a mid to retry, frees it and wakes up a process that waits on the rdata completion. After the connection is established we return from read_into_pages() with a short read, use the mid that was freed before and try to read the remaining data from the a newly created socket. Both actions are not what we want to do. In reconnect cases (-EAGAIN) we should not mask off the error with a short read but should return the error code instead. Acked-by: Jeff Layton Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit fd6cb8b1ac405cf412e6168d0b501919401ccd23 Author: Pavel Shilovsky Date: Fri Jul 18 18:25:52 2014 +0400 CIFS: Fix STATUS_CANNOT_DELETE error mapping for SMB2 commit 21496687a79424572f46a84c690d331055f4866f upstream. The existing mapping causes unlink() call to return error after delete operation. Changing the mapping to -EACCES makes the client process the call like CIFS protocol does - reset dos attributes with ATTR_READONLY flag masked off and retry the operation. Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 346acdffbb4a12f7f77a3fb0f6453a2bc1454b4f Author: Ilya Dryomov Date: Tue Sep 9 19:39:15 2014 +0400 libceph: do not hard code max auth ticket len commit c27a3e4d667fdcad3db7b104f75659478e0c68d8 upstream. We hard code cephx auth ticket buffer size to 256 bytes. This isn't enough for any moderate setups and, in case tickets themselves are not encrypted, leads to buffer overflows (ceph_x_decrypt() errors out, but ceph_decode_copy() doesn't - it's just a memcpy() wrapper). Since the buffer is allocated dynamically anyway, allocated it a bit later, at the point where we know how much is going to be needed. Fixes: http://tracker.ceph.com/issues/8979 Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit fc65783a2268229666c4e338389d01a597f35a29 Author: Ilya Dryomov Date: Mon Sep 8 17:25:34 2014 +0400 libceph: add process_one_ticket() helper commit 597cda357716a3cf8d994cb11927af917c8d71fa upstream. Add a helper for processing individual cephx auth tickets. Needed for the next commit, which deals with allocating ticket buffers. (Most of the diff here is whitespace - view with git diff -b). Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit 7fa66ee488f03d1aaaff823c260b86327eec4452 Author: Sage Weil Date: Mon Aug 4 07:01:54 2014 -0700 libceph: gracefully handle large reply messages from the mon commit 73c3d4812b4c755efeca0140f606f83772a39ce4 upstream. We preallocate a few of the message types we get back from the mon. If we get a larger message than we are expecting, fall back to trying to allocate a new one instead of blindly using the one we have. Signed-off-by: Sage Weil Reviewed-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit b704f8b1ea48ca150f42847574706605e952facc Author: Ilya Dryomov Date: Fri Aug 8 12:43:39 2014 +0400 libceph: set last_piece in ceph_msg_data_pages_cursor_init() correctly commit 5f740d7e1531099b888410e6bab13f68da9b1a4d upstream. Determining ->last_piece based on the value of ->page_offset + length is incorrect because length here is the length of the entire message. ->last_piece set to false even if page array data item length is <= PAGE_SIZE, which results in invalid length passed to ceph_tcp_{send,recv}page() and causes various asserts to fire. # cat pages-cursor-init.sh #!/bin/bash rbd create --size 10 --image-format 2 foo FOO_DEV=$(rbd map foo) dd if=/dev/urandom of=$FOO_DEV bs=1M &>/dev/null rbd snap create foo@snap rbd snap protect foo@snap rbd clone foo@snap bar # rbd_resize calls librbd rbd_resize(), size is in bytes ./rbd_resize bar $(((4 << 20) + 512)) rbd resize --size 10 bar BAR_DEV=$(rbd map bar) # trigger a 512-byte copyup -- 512-byte page array data item dd if=/dev/urandom of=$BAR_DEV bs=1M count=1 seek=5 The problem exists only in ceph_msg_data_pages_cursor_init(), ceph_msg_data_pages_advance() does the right thing. The size_t cast is unnecessary. Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil Reviewed-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit 2f3219f6e413ee5f9690876f3e8fa9bb0213d9ad Author: Chris Mason Date: Tue Sep 2 12:12:52 2014 +1000 xfs: don't zero partial page cache pages during O_DIRECT writes commit 85e584da3212140ee80fd047f9058bbee0bc00d5 upstream. xfs is using truncate_pagecache_range to invalidate the page cache during DIO reads. This is different from the other filesystems who only invalidate pages during DIO writes. truncate_pagecache_range is meant to be used when we are freeing the underlying data structs from disk, so it will zero any partial ranges in the page. This means a DIO read can zero out part of the page cache page, and it is possible the page will stay in cache. buffered reads will find an up to date page with zeros instead of the data actually on disk. This patch fixes things by using invalidate_inode_pages2_range instead. It preserves the page cache invalidation, but won't zero any pages. [dchinner: catch error and warn if it fails. Comment.] Signed-off-by: Chris Mason Reviewed-by: Dave Chinner Reviewed-by: Brian Foster Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit d2f8462e2213eb237eca50b5c12bc75037f06b87 Author: Dave Chinner Date: Tue Sep 2 12:12:52 2014 +1000 xfs: don't zero partial page cache pages during O_DIRECT writes commit 834ffca6f7e345a79f6f2e2d131b0dfba8a4b67a upstream. Similar to direct IO reads, direct IO writes are using truncate_pagecache_range to invalidate the page cache. This is incorrect due to the sub-block zeroing in the page cache that truncate_pagecache_range() triggers. This patch fixes things by using invalidate_inode_pages2_range instead. It preserves the page cache invalidation, but won't zero any pages. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit 4fa1c311190415539cb9d95027f8100724f13dfc Author: Dave Chinner Date: Tue Sep 2 12:12:51 2014 +1000 xfs: don't dirty buffers beyond EOF commit 22e757a49cf010703fcb9c9b4ef793248c39b0c2 upstream. generic/263 is failing fsx at this point with a page spanning EOF that cannot be invalidated. The operations are: 1190 mapwrite 0x52c00 thru 0x5e569 (0xb96a bytes) 1191 mapread 0x5c000 thru 0x5d636 (0x1637 bytes) 1192 write 0x5b600 thru 0x771ff (0x1bc00 bytes) where 1190 extents EOF from 0x54000 to 0x5e569. When the direct IO write attempts to invalidate the cached page over this range, it fails with -EBUSY and so any attempt to do page invalidation fails. The real question is this: Why can't that page be invalidated after it has been written to disk and cleaned? Well, there's data on the first two buffers in the page (1k block size, 4k page), but the third buffer on the page (i.e. beyond EOF) is failing drop_buffers because it's bh->b_state == 0x3, which is BH_Uptodate | BH_Dirty. IOWs, there's dirty buffers beyond EOF. Say what? OK, set_buffer_dirty() is called on all buffers from __set_page_buffers_dirty(), regardless of whether the buffer is beyond EOF or not, which means that when we get to ->writepage, we have buffers marked dirty beyond EOF that we need to clean. So, we need to implement our own .set_page_dirty method that doesn't dirty buffers beyond EOF. This is messy because the buffer code is not meant to be shared and it has interesting locking issues on the buffer dirty bits. So just copy and paste it and then modify it to suit what we need. Note: the solutions the other filesystems and generic block code use of marking the buffers clean in ->writepage does not work for XFS. It still leaves dirty buffers beyond EOF and invalidations still fail. Hence rather than play whack-a-mole, this patch simply prevents those buffers from being dirtied in the first place. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit 4dbaf782aea389dbdfc645902dfb1cee6d6c42d7 Author: Dave Chinner Date: Mon Aug 4 12:43:26 2014 +1000 xfs: quotacheck leaves dquot buffers without verifiers commit 5fd364fee81a7888af806e42ed8a91c845894f2d upstream. When running xfs/305, I noticed that quotacheck was flushing dquot buffers that did not have the xfs_dquot_buf_ops verifiers attached: XFS (vdb): _xfs_buf_ioapply: no ops on block 0x1dc8/0x1dc8 ffff880052489000: 44 51 01 04 00 00 65 b8 00 00 00 00 00 00 00 00 DQ....e......... ffff880052489010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ffff880052489020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ffff880052489030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ CPU: 1 PID: 2376 Comm: mount Not tainted 3.16.0-rc2-dgc+ #306 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 ffff88006fe38000 ffff88004a0ffae8 ffffffff81cf1cca 0000000000000001 ffff88004a0ffb88 ffffffff814d50ca 000010004a0ffc70 0000000000000000 ffff88006be56dc4 0000000000000021 0000000000001dc8 ffff88007c773d80 Call Trace: [] dump_stack+0x45/0x56 [] _xfs_buf_ioapply+0x3ca/0x3d0 [] ? wake_up_state+0x20/0x20 [] ? xfs_bdstrat_cb+0x55/0xb0 [] xfs_buf_iorequest+0x6b/0xd0 [] xfs_bdstrat_cb+0x55/0xb0 [] __xfs_buf_delwri_submit+0x15b/0x220 [] ? xfs_buf_delwri_submit+0x30/0x90 [] xfs_buf_delwri_submit+0x30/0x90 [] xfs_qm_quotacheck+0x17d/0x3c0 [] xfs_qm_mount_quotas+0x151/0x1e0 [] xfs_mountfs+0x56c/0x7d0 [] xfs_fs_fill_super+0x2c2/0x340 [] mount_bdev+0x194/0x1d0 [] ? xfs_finish_flags+0x170/0x170 [] xfs_fs_mount+0x15/0x20 [] mount_fs+0x39/0x1b0 [] vfs_kern_mount+0x67/0x120 [] do_mount+0x23e/0xad0 [] ? __get_free_pages+0xe/0x50 [] ? copy_mount_options+0x36/0x150 [] SyS_mount+0x83/0xc0 [] tracesys+0xdd/0xe2 This was caused by dquot buffer readahead not attaching a verifier structure to the buffer when readahead was issued, resulting in the followup read of the buffer finding a valid buffer and so not attaching new verifiers to the buffer as part of the read. Also, when a verifier failure occurs, we then read the buffer without verifiers. Attach the verifiers manually after this read so that if the buffer is then written it will be verified that the corruption has been repaired. Further, when flushing a dquot we don't ask for a verifier when reading in the dquot buffer the dquot belongs to. Most of the time this isn't an issue because the buffer is still cached, but when it is not cached it will result in writing the dquot buffer without having the verfier attached. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit 13c22aa34be6c1634e157cfbcf76d0cba54e585b Author: Dave Chinner Date: Mon Aug 4 12:43:06 2014 +1000 xfs: ensure verifiers are attached to recovered buffers commit 67dc288c21064b31a98a53dc64f6b9714b819fd6 upstream. Crash testing of CRC enabled filesystems has resulted in a number of reports of bad CRCs being detected after the filesystem was mounted. Errors such as the following were being seen: XFS (sdb3): Mounting V5 Filesystem XFS (sdb3): Starting recovery (logdev: internal) XFS (sdb3): Metadata CRC error detected at xfs_agf_read_verify+0x5a/0x100 [xfs], block 0x1 XFS (sdb3): Unmount and run xfs_repair XFS (sdb3): First 64 bytes of corrupted metadata buffer: ffff880136ffd600: 58 41 47 46 00 00 00 01 00 00 00 00 00 0f aa 40 XAGF...........@ ffff880136ffd610: 00 02 6d 53 00 02 77 f8 00 00 00 00 00 00 00 01 ..mS..w......... ffff880136ffd620: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 03 ................ ffff880136ffd630: 00 00 00 04 00 08 81 d0 00 08 81 a7 00 00 00 00 ................ XFS (sdb3): metadata I/O error: block 0x1 ("xfs_trans_read_buf_map") error 74 numblks 1 The errors were typically being seen in AGF, AGI and their related btree block buffers some time after log recovery had run. Often it wasn't until later subsequent mounts that the problem was discovered. The common symptom was a buffer with the correct contents, but a CRC and an LSN that matched an older version of the contents. Some debug added to _xfs_buf_ioapply() indicated that buffers were being written without verifiers attached to them from log recovery, and Jan Kara isolated the cause to log recovery readahead an dit's interactions with buffers that had a more recent LSN on disk than the transaction being recovered. In this case, the buffer did not get a verifier attached, and os when the second phase of log recovery ran and recovered EFIs and unlinked inodes, the buffers were modified and written without the verifier running. Hence they had up to date contents, but stale LSNs and CRCs. Fix it by attaching verifiers to buffers we skip due to future LSN values so they don't escape into the buffer cache without the correct verifier attached. This patch is based on analysis and a patch from Jan Kara. Reported-by: Jan Kara Reported-by: Fanael Linithien Reported-by: Grozdan Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit 5126045da70818e576a7e6c8d61667f0257df17b Author: Doug Ledford Date: Tue Aug 12 19:20:11 2014 -0400 RDMA/uapi: Include socket.h in rdma_user_cm.h commit db1044d458a287c18c4d413adc4ad12e92e253b5 upstream. added struct sockaddr_storage to rdma_user_cm.h without also adding an include for linux/socket.h to make sure it is defined. Systemtap needs the header files to build standalone and cannot rely on other files to pre-include other headers, so add linux/socket.h to the list of includes in this file. Fixes: ee7aed4528f ("RDMA/ucma: Support querying for AF_IB addresses") Signed-off-by: Doug Ledford Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit c06a9fa58039bc8fb3231ffc425ee91f38547cc4 Author: Steve Wise Date: Fri Jul 25 09:11:33 2014 -0500 RDMA/iwcm: Use a default listen backlog if needed commit 2f0304d21867476394cd51a54e97f7273d112261 upstream. If the user creates a listening cm_id with backlog of 0 the IWCM ends up not allowing any connection requests at all. The correct behavior is for the IWCM to pick a default value if the user backlog parameter is zero. Lustre from version 1.8.8 onward uses a backlog of 0, which breaks iwarp support without this fix. Signed-off-by: Steve Wise Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit ad70570f0421b69add346133c81755dde0f9ef17 Author: NeilBrown Date: Mon Aug 18 13:59:50 2014 +1000 md/raid10: Fix memory leak when raid10 reshape completes. commit b39685526f46976bcd13aa08c82480092befa46c upstream. When a raid10 commences a resync/recovery/reshape it allocates some buffer space. When a resync/recovery completes the buffer space is freed. But not when the reshape completes. This can result in a small memory leak. There is a subtle side-effect of this bug. When a RAID10 is reshaped to a larger array (more devices), the reshape is immediately followed by a "resync" of the new space. This "resync" will use the buffer space which was allocated for "reshape". This can cause problems including a "BUG" in the SCSI layer. So this is suitable for -stable. Fixes: 3ea7daa5d7fde47cd41f4d56c2deb949114da9d6 Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 62906bc65363e2af506798269d18754f499365ef Author: NeilBrown Date: Mon Aug 18 13:56:38 2014 +1000 md/raid10: fix memory leak when reshaping a RAID10. commit ce0b0a46955d1bb389684a2605dbcaa990ba0154 upstream. raid10 reshape clears unwanted bits from a bio->bi_flags using a method which, while clumsy, worked until 3.10 when BIO_OWNS_VEC was added. Since then it clears that bit but shouldn't. This results in a memory leak. So change to used the approved method of clearing unwanted bits. As this causes a memory leak which can consume all of memory the fix is suitable for -stable. Fixes: a38352e0ac02dbbd4fa464dc22d1352b5fbd06fd Reported-by: mdraid.pkoch@dfgh.net (Peter Koch) Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit ba1f6592cb07d4d7025112e1ffcf279d904c7146 Author: NeilBrown Date: Wed Aug 13 09:57:07 2014 +1000 md/raid6: avoid data corruption during recovery of double-degraded RAID6 commit 9c4bdf697c39805078392d5ddbbba5ae5680e0dd upstream. During recovery of a double-degraded RAID6 it is possible for some blocks not to be recovered properly, leading to corruption. If a write happens to one block in a stripe that would be written to a missing device, and at the same time that stripe is recovering data to the other missing device, then that recovered data may not be written. This patch skips, in the double-degraded case, an optimisation that is only safe for single-degraded arrays. Bug was introduced in 2.6.32 and fix is suitable for any kernel since then. In an older kernel with separate handle_stripe5() and handle_stripe6() functions the patch must change handle_stripe6(). Fixes: 6c0069c0ae9659e3a91b68eaed06a5c6c37f45c8 Cc: Yuri Tikhonov Cc: Dan Williams Reported-by: "Manibalan P" Tested-by: "Manibalan P" Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1090423 Signed-off-by: NeilBrown Acked-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 706d916414bf623b20c4626cc6096bb0839263dc Author: NeilBrown Date: Wed Aug 13 09:48:45 2014 +1000 md/raid5: avoid livelock caused by non-aligned writes. commit a40687ff73a5b14909d6aa522f7d778b158911c5 upstream. If a stripe in a raid6 array received a write to each data block while the array is degraded, and if any of these writes to a missing device are not page-aligned, then a live-lock happens. In this case the P and Q blocks need to be read so that the part of the missing block which is *not* being updated by the write can be constructed. Due to a logic error, these blocks are not loaded, so the update cannot proceed and the stripe is 'handled' repeatedly in an infinite loop. This bug is unlikely as most writes are page aligned. However as it can lead to a livelock it is suitable for -stable. It was introduced in 3.16. Fixed: 67f455486d2ea20b2d94d6adf5b9b783d079e321 Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit ae2a02448818b29a5fe79431530feef286c03a97 Author: NeilBrown Date: Thu Jul 31 10:16:29 2014 +1000 md/raid1,raid10: always abort recover on write error. commit 2446dba03f9dabe0b477a126cbeb377854785b47 upstream. Currently we don't abort recovery on a write error if the write error to the recovering device was triggerd by normal IO (as opposed to recovery IO). This means that for one bitmap region, the recovery might write to the recovering device for a few sectors, then not bother for subsequent sectors (as it never writes to failed devices). In this case the bitmap bit will be cleared, but it really shouldn't. The result is that if the recovering device fails and is then re-added (after fixing whatever hardware problem triggerred the failure), the second recovery won't redo the region it was in the middle of, so some of the device will not be recovered properly. If we abort the recovery, the region being processes will be cancelled (bit not cleared) and the whole region will be retried. As the bug can result in data corruption the patch is suitable for -stable. For kernels prior to 3.11 there is a conflict in raid10.c which will require care. Original-from: jiao hui Reported-and-tested-by: jiao hui Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 3fd72a0eb33d7b391b5bba8f3bd6a9ff1fc65f8c Author: Al Viro Date: Sun Aug 10 03:44:55 2014 -0400 fix copy_tree() regression commit 12a5b5294cb1896e9a3c9fca8ff5a7e3def4e8c6 upstream. Since 3.14 we had copy_tree() get the shadowing wrong - if we had one vfsmount shadowing another (i.e. if A is a slave of B, C is mounted on A/foo, then D got mounted on B/foo creating D' on A/foo shadowed by C), copy_tree() of A would make a copy of D' shadow the the copy of C, not the other way around. It's easy to fix, fortunately - just make sure that mount follows the one that shadows it in mnt_child as well as in mnt_hash, and when copy_tree() decides to attach a new mount, check if the last child it has added to the same parent should be shadowing the new one. And if it should, just use the same logics commit_tree() has - put the new mount into the hash and children lists right after the one that should shadow it. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 0fe6ae39a66c475e5ccb1511155e32a4bd704574 Author: Ilya Dryomov Date: Mon Aug 4 18:04:39 2014 +0400 rbd: rework rbd_request_fn() commit bc1ecc65a259fa9333dc8bd6a4ba0cf03b7d4bf8 upstream. While it was never a good idea to sleep in request_fn(), commit 34c6bc2c919a ("locking/mutexes: Add extra reschedule point") made it a *bad* idea. mutex_lock() since 3.15 may reschedule *before* putting task on the mutex wait queue, which for tasks in !TASK_RUNNING state means block forever. request_fn() may be called with !TASK_RUNNING on the way to schedule() in io_schedule(). Offload request handling to a workqueue, one per rbd device, to avoid calling blocking primitives from rbd_request_fn(). Fixes: http://tracker.ceph.com/issues/8818 Signed-off-by: Ilya Dryomov Tested-by: Eric Eastman Tested-by: Greg Wilson Reviewed-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit 3fecf9a20b3c7dba412339d56d6ec3f2eac12345 Author: Al Viro Date: Fri Aug 8 12:39:16 2014 -0400 __generic_file_write_iter(): fix handling of sync error after DIO commit 60bb45297f7551833346c5cebc6d483ea17ea5f2 upstream. If DIO results in short write and sync write fails, we want to bugger off whether the DIO part has written anything or not; the logics on the return will take care of the right return value. Reported-by: Anton Altaparmakov Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 4156d121fa7b6840a992ccbfa9ea4170a67bb12c Author: Vignesh Raman Date: Tue Jul 22 19:24:25 2014 +0530 Bluetooth: Avoid use of session socket after the session gets freed commit 32333edb82fb2009980eefc5518100068147ab82 upstream. The commits 08c30aca9e698faddebd34f81e1196295f9dc063 "Bluetooth: Remove RFCOMM session refcnt" and 8ff52f7d04d9cc31f1e81dcf9a2ba6335ed34905 "Bluetooth: Return RFCOMM session ptrs to avoid freed session" allow rfcomm_recv_ua and rfcomm_session_close to delete the session (and free the corresponding socket) and propagate NULL session pointer to the upper callers. Additional fix is required to terminate the loop in rfcomm_process_rx function to avoid use of freed 'sk' memory. The issue is only reproducible with kernel option CONFIG_PAGE_POISONING enabled making freed memory being changed and filled up with fixed char value used to unmask use-after-free issues. Signed-off-by: Vignesh Raman Signed-off-by: Vitaly Kuzmichev Acked-by: Dean Jenkins Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 075d3370845a28d0c2f2c7a2077cf5df7887567b Author: Johan Hedberg Date: Thu Jul 17 11:56:33 2014 +0300 Bluetooth: Fix using uninitialized variable when pairing commit 9f743d7499bc2c4dc8c35af33bdb2a29bea663b9 upstream. Commit 6c53823ae0e10e723131055e1e65dd6a328a228e reshuffled the way the authentication requirement gets set in the hci_io_capa_request_evt() function, but at the same time it failed to update an if-statement where cp.authentication is used before it has been initialized. The correct value the code should be looking for in this if-statement is conn->auth_type. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit e6b64634229fb0c0724e9b5f4c0a49656e83f12b Author: Vladimir Davydov Date: Tue Jul 15 12:25:28 2014 +0400 Bluetooth: never linger on process exit commit 093facf3634da1b0c2cc7ed106f1983da901bbab upstream. If the current process is exiting, lingering on socket close will make it unkillable, so we should avoid it. Reproducer: #include #include #define BTPROTO_L2CAP 0 #define BTPROTO_SCO 2 #define BTPROTO_RFCOMM 3 int main() { int fd; struct linger ling; fd = socket(PF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM); //or: fd = socket(PF_BLUETOOTH, SOCK_DGRAM, BTPROTO_L2CAP); //or: fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO); ling.l_onoff = 1; ling.l_linger = 1000000000; setsockopt(fd, SOL_SOCKET, SO_LINGER, &ling, sizeof(ling)); return 0; } Signed-off-by: Vladimir Davydov Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit c8383cb6fd5d8f66fc50319e2d6f8363cecb022b Author: Johan Hedberg Date: Fri Jul 11 15:32:23 2014 +0300 Bluetooth: Fix tracking local SSP authentication requirement commit 6c53823ae0e10e723131055e1e65dd6a328a228e upstream. When we need to make the decision whether to perform just-works or real user confirmation we need to know the exact local authentication requirement that was passed to the controller. So far conn->auth_type (the local requirement) wasn't in one case updated appropriately in fear of the user confirmation being rejected later. The real problem however was not really that conn->auth_type couldn't represent the true value but that we were checking the local MITM requirement in an incorrect way. It's perfectly fine to let auth_type follow what we tell the controller since we're still tracking the target security level with conn->pending_sec_level. This patch updates the check for local MITM requirement in the hci_user_confirm_request_evt function to use the locally requested security level and ensures that auth_type always represents what we tell the controller. All other code in hci_user_confirm_request_evt still uses the auth_type instead of pending_sec_level for determining whether to do just-works or not, since that's the only value that's in sync with what the remote device knows. Signed-off-by: Johan Hedberg Tested-by: Szymon Janc Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 41466215bd7e371a70ece9f4a721f03ccb5cd613 Author: Marcel Holtmann Date: Tue Jul 1 14:11:19 2014 +0200 Bluetooth: Fix merge of advertising data and scan response data commit 42bd6a56ed1ab4b2cb50f4d4e674874da9b47f46 upstream. The advertising data and scan response data are merged in the wrong order. It should be advertsing data first and then scan response data and not the other way around. Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg Signed-off-by: Greg Kroah-Hartman commit ec0c2b9cc4eb0a7a38f02fb18d405906f0ff28ad Author: Chin-Ran Lo Date: Tue Jul 1 14:00:14 2014 -0700 Bluetooth: btmrvl: wait for HOST_SLEEP_ENABLE event in suspend commit 396e04f4bb9afefb0744715dc76d9abe18ee5fb0 upstream. After BT_CMD_HOST_SLEEP_ENABLE command finishes, driver should wait until getting BT_EVENT_HOST_SLEEP_ENABLE event to complete suspend procedure. Without this patch the suspend handler would return success earlier. By the time when the BT_EVENT_HOST_SLEEP_ENABLE event comes in the controller driver could have already turned off the bus clock. This causes kernel crash or system reboot eventually. Signed-off-by: Chin-Ran Lo Signed-off-by: Jeff CF Chen Signed-off-by: Amitkumar Karwar Signed-off-by: Bing Zhao Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit cee789ed6fb0a2d38b77a573a369a9e6b924bc63 Author: Al Viro Date: Sat Aug 30 18:32:05 2014 -0400 fix EBUSY on umount() from MNT_SHRINKABLE commit 81b6b06197606b4bef4e427a197aeb808e8d89e1 upstream. We need the parents of victims alive until namespace_unlock() gets to dput() of the (ex-)mountpoints. However, that screws up the "is it busy" checks in case when we have shrinkable mounts that need to be killed. Solution: go ahead and decrement refcounts of parents right in umount_tree(), increment them again just before dropping rwsem in namespace_unlock() (and let the loop in the end of namespace_unlock() finally drop those references for good, as we do now). Parents can't get freed until we drop rwsem - at least one reference is kept until then, both in case when parent is among the victims and when it is not. So they'll still be around when we get to namespace_unlock(). Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit a14b66064d52fb0061d20f5a2288980a55ab6b73 Author: Al Viro Date: Mon Aug 18 15:09:26 2014 -0400 get rid of propagate_umount() mistakenly treating slaves as busy. commit 88b368f27a094277143d8ecd5a056116f6a41520 upstream. The check in __propagate_umount() ("has somebody explicitly mounted something on that slave?") is done *before* taking the already doomed victims out of the child lists. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 27d2379a682edbf2b4d7e3005c783d1904cab217 Author: Eric W. Biederman Date: Tue Jul 29 15:50:44 2014 -0700 mnt: Add tests for unprivileged remount cases that have found to be faulty commit db181ce011e3c033328608299cd6fac06ea50130 upstream. Kenton Varda discovered that by remounting a read-only bind mount read-only in a user namespace the MNT_LOCK_READONLY bit would be cleared, allowing an unprivileged user to the remount a read-only mount read-write. Upon review of the code in remount it was discovered that the code allowed nosuid, noexec, and nodev to be cleared. It was also discovered that the code was allowing the per mount atime flags to be changed. The first naive patch to fix these issues contained the flaw that using default atime settings when remounting a filesystem could be disallowed. To avoid this problems in the future add tests to ensure unprivileged remounts are succeeding and failing at the appropriate times. Acked-by: Serge E. Hallyn Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 72e946e24012627c160f474e62f07d45428f790d Author: Eric W. Biederman Date: Mon Jul 28 17:36:04 2014 -0700 mnt: Change the default remount atime from relatime to the existing value commit ffbc6f0ead47fa5a1dc9642b0331cb75c20a640e upstream. Since March 2009 the kernel has treated the state that if no MS_..ATIME flags are passed then the kernel defaults to relatime. Defaulting to relatime instead of the existing atime state during a remount is silly, and causes problems in practice for people who don't specify any MS_...ATIME flags and to get the default filesystem atime setting. Those users may encounter a permission error because the default atime setting does not work. A default that does not work and causes permission problems is ridiculous, so preserve the existing value to have a default atime setting that is always guaranteed to work. Using the default atime setting in this way is particularly interesting for applications built to run in restricted userspace environments without /proc mounted, as the existing atime mount options of a filesystem can not be read from /proc/mounts. In practice this fixes user space that uses the default atime setting on remount that are broken by the permission checks keeping less privileged users from changing more privileged users atime settings. Acked-by: Serge E. Hallyn Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 3ed889bb32afa24e5ee77a3b40c7c8088b16eedf Author: Eric W. Biederman Date: Mon Jul 28 17:26:07 2014 -0700 mnt: Correct permission checks in do_remount commit 9566d6742852c527bf5af38af5cbb878dad75705 upstream. While invesgiating the issue where in "mount --bind -oremount,ro ..." would result in later "mount --bind -oremount,rw" succeeding even if the mount started off locked I realized that there are several additional mount flags that should be locked and are not. In particular MNT_NOSUID, MNT_NODEV, MNT_NOEXEC, and the atime flags in addition to MNT_READONLY should all be locked. These flags are all per superblock, can all be changed with MS_BIND, and should not be changable if set by a more privileged user. The following additions to the current logic are added in this patch. - nosuid may not be clearable by a less privileged user. - nodev may not be clearable by a less privielged user. - noexec may not be clearable by a less privileged user. - atime flags may not be changeable by a less privileged user. The logic with atime is that always setting atime on access is a global policy and backup software and auditing software could break if atime bits are not updated (when they are configured to be updated), and serious performance degradation could result (DOS attack) if atime updates happen when they have been explicitly disabled. Therefore an unprivileged user should not be able to mess with the atime bits set by a more privileged user. The additional restrictions are implemented with the addition of MNT_LOCK_NOSUID, MNT_LOCK_NODEV, MNT_LOCK_NOEXEC, and MNT_LOCK_ATIME mnt flags. Taken together these changes and the fixes for MNT_LOCK_READONLY should make it safe for an unprivileged user to create a user namespace and to call "mount --bind -o remount,... ..." without the danger of mount flags being changed maliciously. Acked-by: Serge E. Hallyn Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit daa4314a0c2742fb7b79d7ef7fa308bd76a29264 Author: Eric W. Biederman Date: Mon Jul 28 17:10:56 2014 -0700 mnt: Move the test for MNT_LOCK_READONLY from change_mount_flags into do_remount commit 07b645589dcda8b7a5249e096fece2a67556f0f4 upstream. There are no races as locked mount flags are guaranteed to never change. Moving the test into do_remount makes it more visible, and ensures all filesystem remounts pass the MNT_LOCK_READONLY permission check. This second case is not an issue today as filesystem remounts are guarded by capable(CAP_DAC_ADMIN) and thus will always fail in less privileged mount namespaces, but it could become an issue in the future. Acked-by: Serge E. Hallyn Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 3995f446f4e51fb781467d6da1673cf4631634ff Author: Eric W. Biederman Date: Mon Jul 28 16:26:53 2014 -0700 mnt: Only change user settable mount flags in remount commit a6138db815df5ee542d848318e5dae681590fccd upstream. Kenton Varda discovered that by remounting a read-only bind mount read-only in a user namespace the MNT_LOCK_READONLY bit would be cleared, allowing an unprivileged user to the remount a read-only mount read-write. Correct this by replacing the mask of mount flags to preserve with a mask of mount flags that may be changed, and preserve all others. This ensures that any future bugs with this mask and remount will fail in an easy to detect way where new mount flags simply won't change. Acked-by: Serge E. Hallyn Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 39ed6dfc36293ce24734ec571569a0921d8b0745 Author: Steven Rostedt (Red Hat) Date: Wed Aug 6 15:36:31 2014 -0400 ring-buffer: Up rb_iter_peek() loop count to 3 commit 021de3d904b88b1771a3a2cfc5b75023c391e646 upstream. After writting a test to try to trigger the bug that caused the ring buffer iterator to become corrupted, I hit another bug: WARNING: CPU: 1 PID: 5281 at kernel/trace/ring_buffer.c:3766 rb_iter_peek+0x113/0x238() Modules linked in: ipt_MASQUERADE sunrpc [...] CPU: 1 PID: 5281 Comm: grep Tainted: G W 3.16.0-rc3-test+ #143 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007 0000000000000000 ffffffff81809a80 ffffffff81503fb0 0000000000000000 ffffffff81040ca1 ffff8800796d6010 ffffffff810c138d ffff8800796d6010 ffff880077438c80 ffff8800796d6010 ffff88007abbe600 0000000000000003 Call Trace: [] ? dump_stack+0x4a/0x75 [] ? warn_slowpath_common+0x7e/0x97 [] ? rb_iter_peek+0x113/0x238 [] ? rb_iter_peek+0x113/0x238 [] ? ring_buffer_iter_peek+0x2d/0x5c [] ? tracing_iter_reset+0x6e/0x96 [] ? s_start+0xd7/0x17b [] ? kmem_cache_alloc_trace+0xda/0xea [] ? seq_read+0x148/0x361 [] ? vfs_read+0x93/0xf1 [] ? SyS_read+0x60/0x8e [] ? tracesys+0xdd/0xe2 Debugging this bug, which triggers when the rb_iter_peek() loops too many times (more than 2 times), I discovered there's a case that can cause that function to legitimately loop 3 times! rb_iter_peek() is different than rb_buffer_peek() as the rb_buffer_peek() only deals with the reader page (it's for consuming reads). The rb_iter_peek() is for traversing the buffer without consuming it, and as such, it can loop for one more reason. That is, if we hit the end of the reader page or any page, it will go to the next page and try again. That is, we have this: 1. iter->head > iter->head_page->page->commit (rb_inc_iter() which moves the iter to the next page) try again 2. event = rb_iter_head_event() event->type_len == RINGBUF_TYPE_TIME_EXTEND rb_advance_iter() try again 3. read the event. But we never get to 3, because the count is greater than 2 and we cause the WARNING and return NULL. Up the counter to 3. Fixes: 69d1b839f7ee "ring-buffer: Bind time extend and data events together" Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 1cfa896d6e52e3d9d2cb2133a0c495c816556ca9 Author: Steven Rostedt (Red Hat) Date: Wed Aug 6 14:11:33 2014 -0400 ring-buffer: Always reset iterator to reader page commit 651e22f2701b4113989237c3048d17337dd2185c upstream. When performing a consuming read, the ring buffer swaps out a page from the ring buffer with a empty page and this page that was swapped out becomes the new reader page. The reader page is owned by the reader and since it was swapped out of the ring buffer, writers do not have access to it (there's an exception to that rule, but it's out of scope for this commit). When reading the "trace" file, it is a non consuming read, which means that the data in the ring buffer will not be modified. When the trace file is opened, a ring buffer iterator is allocated and writes to the ring buffer are disabled, such that the iterator will not have issues iterating over the data. Although the ring buffer disabled writes, it does not disable other reads, or even consuming reads. If a consuming read happens, then the iterator is reset and starts reading from the beginning again. My tests would sometimes trigger this bug on my i386 box: WARNING: CPU: 0 PID: 5175 at kernel/trace/trace.c:1527 __trace_find_cmdline+0x66/0xaa() Modules linked in: CPU: 0 PID: 5175 Comm: grep Not tainted 3.16.0-rc3-test+ #8 Hardware name: /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006 00000000 00000000 f09c9e1c c18796b3 c1b5d74c f09c9e4c c103a0e3 c1b5154b f09c9e78 00001437 c1b5d74c 000005f7 c10bd85a c10bd85a c1cac57c f09c9eb0 ed0e0000 f09c9e64 c103a185 00000009 f09c9e5c c1b5154b f09c9e78 f09c9e80^M Call Trace: [] dump_stack+0x4b/0x75 [] warn_slowpath_common+0x7e/0x95 [] ? __trace_find_cmdline+0x66/0xaa [] ? __trace_find_cmdline+0x66/0xaa [] warn_slowpath_fmt+0x33/0x35 [] __trace_find_cmdline+0x66/0xaa^M [] trace_find_cmdline+0x40/0x64 [] trace_print_context+0x27/0xec [] ? trace_seq_printf+0x37/0x5b [] print_trace_line+0x319/0x39b [] ? ring_buffer_read+0x47/0x50 [] s_show+0x192/0x1ab [] ? s_next+0x5a/0x7c [] seq_read+0x267/0x34c [] vfs_read+0x8c/0xef [] ? seq_lseek+0x154/0x154 [] SyS_read+0x54/0x7f [] syscall_call+0x7/0xb ---[ end trace 3f507febd6b4cc83 ]--- >>>> ##### CPU 1 buffer started #### Which was the __trace_find_cmdline() function complaining about the pid in the event record being negative. After adding more test cases, this would trigger more often. Strangely enough, it would never trigger on a single test, but instead would trigger only when running all the tests. I believe that was the case because it required one of the tests to be shutting down via delayed instances while a new test started up. After spending several days debugging this, I found that it was caused by the iterator becoming corrupted. Debugging further, I found out why the iterator became corrupted. It happened with the rb_iter_reset(). As consuming reads may not read the full reader page, and only part of it, there's a "read" field to know where the last read took place. The iterator, must also start at the read position. In the rb_iter_reset() code, if the reader page was disconnected from the ring buffer, the iterator would start at the head page within the ring buffer (where writes still happen). But the mistake there was that it still used the "read" field to start the iterator on the head page, where it should always start at zero because readers never read from within the ring buffer where writes occur. I originally wrote a patch to have it set the iter->head to 0 instead of iter->head_page->read, but then I questioned why it wasn't always setting the iter to point to the reader page, as the reader page is still valid. The list_empty(reader_page->list) just means that it was successful in swapping out. But the reader_page may still have data. There was a bug report a long time ago that was not reproducible that had something about trace_pipe (consuming read) not matching trace (iterator read). This may explain why that happened. Anyway, the correct answer to this bug is to always use the reader page an not reset the iterator to inside the writable ring buffer. Fixes: d769041f8653 "ring_buffer: implement new locking" Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit d52143d85c9c6962f01098935e0cf8a422bbf5b8 Author: David Vrabel Date: Thu Jul 31 16:22:24 2014 +0100 xen/events/fifo: reset control block and local HEADs on resume commit c12784c3d14a2110468ec4d1383f60cfd2665576 upstream. When using the FIFO-based event channel ABI, if the control block or the local HEADs are not reset after resuming the guest may see stale HEAD values and will fail to traverse the FIFO correctly. This may prevent one or more VCPUs from receiving any events following a resume. Signed-off-by: David Vrabel Reviewed-by: Boris Ostrovsky Signed-off-by: Greg Kroah-Hartman commit 062475fc40989d68ddf0a69f6e8cdf3cbaf58610 Author: Hans de Goede Date: Thu Aug 28 10:20:47 2014 +0200 ACPI / video: Disable native_backlight on HP ENVY 15 Notebook PC commit 84c34858a85ecf9dabd72847d860c7d3fb7536e7 upstream. Link: https://bugs.freedesktop.org/show_bug.cgi?id=81515 Reported-and-tested-by: Hohahiu Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 710ea3f575f48a7aa7bd90184d07d5117b1dcabe Author: Hans de Goede Date: Thu Aug 28 10:20:46 2014 +0200 ACPI / video: Add a disable_native_backlight quirk commit 5f24079b021cd3147c8d24ba65833f7a0df7e80d upstream. Some laptops have a working acpi_video backlight control, and using native backlight on these causes a regression where backlight control does not work when userspace is not handling brightness key events. Disable native_backlight on these to fix this. Link: https://bugzilla.kernel.org/show_bug.cgi?id=81691 Reported-and-tested-by: Andre Müller Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 651dd54f1e98964528459fe3242a5fd9e2e4831c Author: Hans de Goede Date: Thu Aug 28 10:20:45 2014 +0200 ACPI / video: Fix use_native_backlight selection logic commit 25294e9f00f03b2b4f4c56e913bc8c573972f33b upstream. Commit 751109aad583 ("ACPI / video: Change the default for video.use_native_backlight to 1") has changed the default for use_native_backlight from 0 to 1, but instead of changing use_native_backlight_dmi to true, and leaving use_native_backlight_param at -1, it has changed use_native_backlight_param to 1. This causes acpi_video_use_native_backlight() to always think that a value was specified through the param, making it impossible to add a dmi based quirk to force 0 now that the default is 1. This fixes this by restoring the use_native_backlight_param default to -1, and instead setting the use_native_backlight_dmi default to true. Fixes: 751109aad583 (ACPI / video: Change the default for video.use_native_backlight to 1) Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit d1c062033bc96b74941a06ffa1922e50c24f1680 Author: Jiri Kosina Date: Wed Sep 3 15:04:28 2014 +0200 ACPI / cpuidle: fix deadlock between cpuidle_lock and cpu_hotplug.lock commit 6726655dfdd2dc60c035c690d9f10cb69d7ea075 upstream. There is a following AB-BA dependency between cpu_hotplug.lock and cpuidle_lock: 1) cpu_hotplug.lock -> cpuidle_lock enable_nonboot_cpus() _cpu_up() cpu_hotplug_begin() LOCK(cpu_hotplug.lock) cpu_notify() ... acpi_processor_hotplug() cpuidle_pause_and_lock() LOCK(cpuidle_lock) 2) cpuidle_lock -> cpu_hotplug.lock acpi_os_execute_deferred() workqueue ... acpi_processor_cst_has_changed() cpuidle_pause_and_lock() LOCK(cpuidle_lock) get_online_cpus() LOCK(cpu_hotplug.lock) Fix this by reversing the order acpi_processor_cst_has_changed() does thigs -- let it first execute the protection against CPU hotplug by calling get_online_cpus() and obtain the cpuidle lock only after that (and perform the symmentric change when allowing CPUs hotplug again and dropping cpuidle lock). Spotted by lockdep. Signed-off-by: Jiri Kosina Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ca16ec3a32087b907e18db2a4af20f4d1bd9d0ed Author: Yasuaki Ishimatsu Date: Wed Sep 3 13:39:13 2014 +0900 ACPI / scan: not cache _SUN value in struct acpi_device_pnp commit a383b68d9fe9864c4d3b86f67ad6488f58136435 upstream. The _SUN device indentification object is not guaranteed to return the same value every time it is executed, so we should not cache its return value, but rather execute it every time as needed. If it is cached, an incorrect stale value may be used in some situations. This issue was exposed by commit 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace). Fix it by avoiding to cache the return value of _SUN. Fixes: 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace) Signed-off-by: Yasuaki Ishimatsu [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 37da49c14422abbdfd6c82266952acf5c35c2ce9 Author: Lv Zheng Date: Thu Aug 21 14:41:26 2014 +0800 ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC commit 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4 upstream. There is platform refusing to respond QR_EC when SCI_EVT isn't set which is Acer Aspire V5-573G. By disallowing QR_EC to be issued before the previous one has been completed we are able to reduce the possibilities to trigger issues on such platforms. Note that this fix can only reduce the occurrence rate of this issue, but this issue may still occur when such a platform doesn't clear SCI_EVT before or immediately after completing the previous QR_EC transaction. This patch cannot fix the CLEAR_ON_RESUME quirk which also relies on the assumption that the platforms are able to respond even when SCI_EVT isn't set. But this patch is still useful as it can help to reduce the number of scheduled QR_EC work items. Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611 Reported-and-tested-by: Alexander Mezin Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 692749e855838c34894d5f336448a93509d339a9 Author: Lv Zheng Date: Thu Aug 21 14:41:13 2014 +0800 ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set commit 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08 upstream. There is a platform refusing to respond QR_EC when SCI_EVT isn't set (Acer Aspire V5-573G). Currently, we rely on the behaviour that the EC firmware can respond something (for example, 0x00 to indicate "no outstanding events") to QR_EC even when SCI_EVT is not set, but the reporter has complained about AC/battery pluging/unpluging and video brightness change delay on that platform. This is because the work item that has issued QR_EC has to wait until timeout in this case, and the _Qxx method evaluation work item queued after QR_EC one is delayed. It sounds reasonable to fix this issue by: 1. Implementing SCI_EVT sanity check before issuing QR_EC in the EC driver's main state machine. 2. Moving QR_EC issuing out of the work queue used by _Qxx evaluation to a seperate IRQ handling thread. This patch fixes this issue using solution 1. By disallowing QR_EC to be issued when SCI_EVT isn't set, we are able to handle such platform in the EC driver's main state machine. This patch enhances the state machine in this way to survive with such malfunctioning EC firmware. Note that this patch can also fix CLEAR_ON_RESUME quirk which also relies on the assumption that the platforms are able to respond even when SCI_EVT isn't set. Fixes: c0d653412fc8 ACPI / EC: Fix race condition in ec_transaction_completed() Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611 Reported-and-tested-by: Alexander Mezin Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit afdd3bcc760e02740b2a375a0ad6447e3da3959f Author: Rafael J. Wysocki Date: Tue Aug 26 01:29:21 2014 +0200 ACPI / scan: Allow ACPI drivers to bind to PNP device objects commit fc2e0a8326d1b21d11ef8213298e5302867fed2c upstream. We generally don't allow ACPI drivers to bind to ACPI device objects that companion "physical" device objects are created for to avoid situations in which two different drivers may attempt to handle one device at the same time. Recent ACPI device enumeration rework extended that approach to ACPI PNP devices by starting to use a scan handler for enumerating them. However, we previously allowed ACPI drivers to bind to ACPI device objects with existing PNP device companions and changing that led to functional regressions on some systems. For this reason, add a special check for PNP devices in acpi_device_probe() so that ACPI drivers can bind to ACPI device objects having existing PNP device companions as before. Fixes: eec15edbb0e1 (ACPI / PNP: use device ID list for PNPACPI device enumeration) Link: https://bugzilla.kernel.org/show_bug.cgi?id=81511 Link: https://bugzilla.kernel.org/show_bug.cgi?id=81971 Reported-by: Gabriele Mazzotta Reported-by: Dirk Griesbach Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit baf705af97bd84b867de7e16016b3be8cfd99b9a Author: Lan Tianyu Date: Tue Aug 26 01:29:24 2014 +0200 ACPI: Run fixed event device notifications in process context commit 236105db632c6279a020f78c83e22eaef746006b upstream. Currently, notify callbacks for fixed button events are run from interrupt context. That is not necessary and after commit 0bf6368ee8f2 (ACPI / button: Add ACPI Button event via netlink routine) it causes netlink routines to be called from interrupt context which is not correct. Also, that is different from non-fixed device events (including non-fixed button events) whose notify callbacks are all executed from process context. For the above reasons, make fixed button device notify callbacks run in process context which will avoid the deadlock when using netlink to report button events to user space. Fixes: 0bf6368ee8f2 (ACPI / button: Add ACPI Button event via netlink routine) Link: https://lkml.org/lkml/2014/8/21/606 Reported-by: Benjamin Block Reported-by: Knut Petersen Signed-off-by: Lan Tianyu [rjw: Function names, subject and changelog.] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 5fcc3510ab989474a379cf0148d68578bfe5a147 Author: Alan Cox Date: Wed Aug 20 13:57:26 2014 +0300 spi/pxa2xx: Add ACPI ID for Intel Braswell commit aca26364689e00e3b2052072424682231bdae6ae upstream. The SPI host controller is the same as used in Baytrail, only the ACPI ID is different so add this new ID to the list. Signed-off-by: Alan Cox Signed-off-by: Mika Westerberg Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 02e9190b3bb4acc95b527539f6ec0f7a0982d6aa Author: Tang Chen Date: Fri Aug 8 10:30:45 2014 +0800 ACPI / hotplug: Check scan handlers in acpi_scan_hot_remove() commit dee1592638ab7ea35a32179b73f9284dead49c03 upstream. When ACPI_HOTPLUG_MEMORY is not configured, memory_device_handler.attach is not set. In acpi_scan_attach_handler(), the acpi_device->handler will not be initialized. In acpi_scan_hot_remove(), it doesn't check if acpi_device->handler is NULL. If we do memory hot-remove without ACPI_HOTPLUG_MEMORY configured, the kernel will panic. BUG: unable to handle kernel NULL pointer dereference at 0000000000000088 IP: [] acpi_device_hotplug+0x1d7/0x4c4 PGD 0 Oops: 0000 [#1] SMP Modules linked in: sd_mod(E) sr_mod(E) cdrom(E) crc_t10dif(E) crct10dif_common(E) ata_piix(E) libata(E) CPU: 0 PID: 41 Comm: kworker/u2:1 Tainted: G E 3.16.0-rc7--3.16-rc7-tangchen+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 Workqueue: kacpi_hotplug acpi_hotplug_work_fn task: ffff8800182436c0 ti: ffff880018254000 task.ti: ffff880018254000 RIP: 0010:[] [] acpi_device_hotplug+0x1d7/0x4c4 RSP: 0000:ffff880018257da8 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff88001cd8d800 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88001e40e6f8 RDI: 0000000000000246 RBP: ffff880018257df0 R08: 0000000000000096 R09: 00000000000011a0 R10: 63735f6970636120 R11: 725f746f685f6e61 R12: 0000000000000003 R13: ffff88001cc1c400 R14: ffff88001e062028 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff88001e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000088 CR3: 000000001a9a2000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000 Stack: 00000000523cab58 ffff88001cd8d9f8 ffff88001852d480 00000000523cab58 ffff88001852d480 ffff880018221e40 ffff88001cc1c400 ffff88001cce2d00 0000000000000040 ffff880018257e08 ffffffff813dc31d ffff88001852d480 Call Trace: [] acpi_hotplug_work_fn+0x1e/0x29 [] process_one_work+0x17b/0x460 [] worker_thread+0x11d/0x5b0 [] ? rescuer_thread+0x3a0/0x3a0 [] kthread+0xe1/0x100 [] ? kthread_create_on_node+0x1a0/0x1a0 [] ret_from_fork+0x7c/0xb0 [] ? kthread_create_on_node+0x1a0/0x1a0 This patch fixes this problem by checking if acpi_device->handler is NULL in acpi_scan_hot_remove(). Fixes: d22ddcbc4fb7 (ACPI / hotplug: Add demand_offline hotplug profile flag) Signed-off-by: Tang Chen [rjw: Subject] Signed-off-by: Rafael J. Wysocki